1. Slack Code: Where Your Team and Agents Build Together

推荐理由： 这是一个很值得关注的 AI-native developer workspace 方向：coding agent 不再只存在于某个工程师自己的 terminal、IDE 或浏览器 tab 里，而是进入团队共享的 project space。Slack Code 把对话、Agent plan、code diff、live preview、审批和最终结果放在同一个 code channel 里，让“Agent 正在做什么”本身成为团队可观察、可干预、可追溯的工作状态，而不是最后才出现一个 PR。

核心要点：

  • 一个复杂任务会创建独立的 code channel，任务相关人员和 Agent 都在其中协作；完成后 channel 自动归档，但保留为可搜索的 audit trail。Slack 的产品判断是：长周期 Agent 工作需要独立 workspace，而普通 thread 对多轮执行已经不够。
  • Plan、diff、live HTML preview 都直接成为共享界面。团队成员可以在 Agent 执行过程中补充约束、暂停或重定向，而不是等 Agent 完成后再被动 review。高风险动作仍可路由到人工审批，Agent 自动化和 human gate 被放在同一工作流里。
  • Slack 称内部已有 超过 70% 的 code channels 在一天内从创建走到关闭/merged PR。更重要的设计信号不是这个单一产品指标，而是开发协作的 unit 正从“一个人与一个 Agent 的 session”迁移到 team-visible agent workspace；Claude、Devin、GitHub Copilot、Vercel 等不同 Agent 可以共享这种协作表面。

2. Optimal Skill Selection for LLM Agents with Provable Bicriteria Guarantees

推荐理由： 这篇直接对应 Agent Skills 规模化后的 context engineering 问题：skill library 变大以后，不能简单按 semantic relevance 做 top-k。两个 skill 可能高度重复，也可能只有组合起来才能覆盖任务需要；另外每多塞一份 skill 文档都会占用 token，甚至干扰 executor。论文把 skill routing 建模成“有限 context budget 下选择最佳 skill set”的组合优化问题。

核心要点：

  • 作者将每个 skill 看成提供一组能力，将任务看成对能力的需求，并用 submodular benefit + context penalty 表达互补、冗余与 token 成本。这样选择目标不再是“找最相关文档”，而是“找整体最有价值的一组文档”。
  • 提出的 Best Prefix Selection（BPS） 会从小型 seed 出发，按单位 token 的边际收益扩展候选集合，同时检查中间 prefix，而不是默认越加 skill 越好。论文给出 (1-1/e, 1) bicriteria approximation guarantee，说明 skill selection 可以从经验式 router 进一步走向有明确目标与约束的系统算法。
  • 在 contamination-controlled BigCodeBench variant 上，BPS 的 measured task success 达到 0.73，对比 released skill routers、text retrievers 和 executor 自选的 0.20–0.52；同时比最强 released router 少用 28% tokens。这说明 skill routing 的核心优化目标应该是 set quality / marginal utility，而不只是单条 skill 的 retrieval score。