Signal #19：AI 工具越来越多，团队要开始管起来了

过去一年，AI Coding 的讨论大多围绕一个问题展开：哪个工具更好用？

有人选择 Cursor，有人用 Claude Code，有人用 GitHub Copilot，也有人把 Codex 接进自己的工作流。这个阶段里，工具选择更多是个人习惯问题：谁的补全更顺，谁的上下文理解更好，谁改代码更稳，谁更适合命令行，谁更适合 IDE。

但这周的一组动态放在一起看，问题开始变了。

GitHub Copilot 接入了更多模型，并把 Kimi K2.7 Code 作为首个 open-weight model 放进 Copilot 模型选择器；GitHub Copilot CLI 和 SDK 支持设置 AI credit session limits，用来限制一次 Agent session 的花费；Anthropic 的 Fable 5 恢复访问，则提醒我们模型能力之外，还有区域、合规和供应商可用性问题；Vercel AI Gateway 继续强调 provider routing、observability、spend controls、BYOK 和 fallback，把不同模型调用收敛到统一网关里管理。（原文：GitHub / GitHub / Anthropic / Vercel）

这些看起来是不同公司的产品更新，但背后其实是同一个问题：AI 工具越来越多之后，研发团队不能只靠个人选择来使用它们了。

从“选工具”，走向“管能力”，可能是 AI Coding 接下来很关键的一步。

最早大家讨论 AI Coding，问题很简单：要不要用？用哪个？

那时候，一个团队里可能只有 Copilot，或者只有 Cursor。开发者自己试，觉得好用就用，不好用就关掉。AI 工具更像个人效率插件，组织层面最多关心两件事：有没有开通账号，大家有没有在用。

现在情况不一样了。

一个研发团队可能同时面对很多选择：IDE 里的 Copilot，独立 IDE 里的 Cursor，终端里的 Claude Code 或 Codex，云端任务型 Agent，浏览器自动化工具，模型网关，企业内部的 Agent 平台，甚至还有各种开源 Agent 工作台、模型代理和 MCP 工具。单看每一个工具都能解释得通，放在一起就会变成管理问题。

工具多不是坏事。问题在于，工具一多，团队就不能只问“哪个最好用”，还要问：哪些模型可以访问私有代码？哪些 Agent 可以执行命令？哪些任务允许自动跑？一次任务最多能花多少钱？模型不可用时怎么降级？执行结果如何进入 Review、审计和成本归因？

这些问题听起来不像普通开发者最关心的问题，但一旦 AI Coding 从个人试用进入团队流程，它们就绕不开。

因为 AI 工具越强，越不只是一个聊天窗口。它可能读仓库、跑命令、打开浏览器、生成 PR、调用外部工具，也可能持续消耗模型额度。到了这个阶段，团队真正需要的就不只是“更强的工具”，而是能统一管理这些能力的位置。

也就是一个调度台。

这周 GitHub Copilot 引入 Kimi K2.7 Code，是一个很有意思的信号。GitHub 在官方说明里强调，它是 Copilot 模型选择器中的首个 open-weight model，并且是一个更低成本的 coding workflow 选择。GitHub

这件事本身不只是“Copilot 又多了一个模型”。更重要的是，Copilot 正在从一个固定助手，变成一个模型选择入口。过去用户可能默认使用某个模型，现在不同模型会以不同成本、不同能力、不同可用范围进入同一个工作流。对个人开发者来说，这是选择更多了；对团队来说，这是管理对象变多了。

GitHub Copilot CLI 和 SDK 支持 AI credit session limits，也是在同一个方向上补能力。官方文档里说，AI credit session limit 可以限制 Copilot 在一次 session 中消耗的 AI Credits，尤其适合自动化场景，因为 Agent 工作时不一定有人在旁边盯着。GitHub / GitHub Docs

这说明成本控制已经不是后台账单问题，而开始进入 Agent 执行过程本身。一个 Agent session 可以跑多久、最多花多少钱、到达限制后怎么停止，这些都开始变成系统能力。

Anthropic 的 Fable 5 恢复访问，则从另一个角度说明模型选择不只是技术比较。Anthropic 在官方公告里提到，Fable 5 将恢复面向 Claude Platform、Claude.ai、Claude Code、Claude Cowork 的全球访问，也会尽快在 AWS、Google Cloud、Microsoft Foundry 上重新启用。Anthropic

这提醒我们，模型可用性会受到合规、区域、云平台和供应商策略影响。企业如果把关键研发链路绑定在单一模型上，就必须面对模型不可用、替换、降级和合规开关的问题。

所以，未来团队不是选一个最强模型，而是维护一组模型池：有的适合高风险代码修改，有的适合低成本总结，有的适合长上下文分析，有的适合本地或开源部署，有的只能在特定区域、特定云平台或特定数据边界内使用。

这已经不是个人偏好，而是团队能力管理。

模型变多之后，Agent 也在变多。

过去我们说 Agent，很多时候指一个具体工具：Claude Code、Codex、Cursor Agent、GitHub Copilot Agent。用户打开它，给它任务，它帮忙完成一段工作。但现在，一个团队里可能同时存在多个 Agent，而且它们不是简单替代关系。

有的 Agent 擅长在终端里长期执行任务，有的更适合 IDE 内代码修改，有的可以跑在云端，有的可以连接浏览器，有的可以被嵌入 Notion、Jira、Slack 这类协作系统，有的则被包装成开源工作台或统一编排层。

开源趋势里也能看到类似变化。Omnigent 把自己定位为一个 open-source meta-harness，目标是在 Claude Code、Codex、Cursor、OpenCode、Hermes、Pi 等 Agent 之上提供共同编排层，支持替换或组合不同 harness，并提供 policy、sandbox 和跨端协作能力。Omnigent

Orca 则把自己称为面向并行 Agent fleet 的 ADE，也就是 Agent Development Environment。它强调的不是单个 Agent 对话，而是在桌面和移动端管理一组并行 Agent。Orca

这些开源项目未必都成熟，但它们共同说明一个趋势：开发者不再满足于打开一个 Agent 工具，而是开始思考如何管理一组 Agent。

这也和我们这周讨论的 Multica 很接近。Multica 这类产品之所以值得关注，不是因为它又提供了一个 Agent，而是因为它试图成为 Agent 执行管理台：任务来了以后，决定交给哪个 Agent、哪个模型、哪个工具、在哪个环境里跑、花多少钱、权限多大、失败怎么降级、结果怎么回流。

这正是“调度台”要解决的问题。

当 Agent 数量变多之后，真正的挑战不是每个 Agent 都多聪明，而是团队能不能把它们变成稳定的研发能力。如果每个工具都很强，但任务、权限、成本、结果各自散落，最后组织拿到的仍然是一堆个人效率提升，而不是可管理、可复用、可度量的系统能力。

如果说 IDE、CLI、Chat 面板是用户能看到的入口，那 Gateway、Harness、调度台就是后面逐渐变重要的中间层。

Vercel AI Gateway 是这周最直接的例子。Vercel 在实时语音 Agent 的更新里说，audio 调用和其他模型调用一样，可以使用 provider routing、observability、spend controls 和 BYOK。AI Gateway 文档里也强调，它可以在多个 AI provider 之间路由请求，不同 provider 有不同模型、价格和性能特征，用户可以控制 routing order 和 fallback behavior。Vercel / Vercel Docs

这里的重点不是语音，而是统一入口。无论文本、代码、图像、语音，最终都可以放进一个网关里管理：谁来处理、怎么路由、如何观测、花多少钱、失败时怎么切换、是否使用自己的 provider key。

开源项目 OmniRoute 也在做类似事情。它把自己定位为 AI Gateway，强调 one endpoint、多个 providers、auto-fallback、MCP / A2A、多模态 API，并可以连接 Claude Code、Codex、Cursor、Cline、Copilot 等工具。OmniRoute

这类项目的出现说明，模型调用和 Agent 调用正在从分散集成，走向统一管理。开发者不希望每个工具都单独配置一套模型、密钥、预算和 fallback，也不希望企业里的成本和调用记录散在不同工具里。

如果再往深一点看，这有点像软件工程里的新供应链。过去我们管理依赖、包、镜像、CI、云资源，现在还要管理模型、Agent、工具、运行环境和调用成本。这些东西都会影响交付效率、系统安全和团队成本。

但在对外表达上，不一定要先讲“供应链”。对大多数团队来说，更容易理解的说法是：

AI 能力越来越多，需要一个调度台。

这件事对研发团队的影响，不是马上搭一个复杂平台，而是思考方式要变。

过去团队引入 AI Coding，常见动作是买工具、开账号、培训使用、看采纳率。这个阶段的问题是“大家会不会用 AI”。接下来更关键的问题会变成“团队能不能管好 AI 能力”。

哪些模型可以访问私有代码？哪些 Agent 可以执行命令？哪些工具可以连接生产环境或内部系统？哪些任务允许低成本模型处理，哪些任务必须使用更强模型？一次自动化任务最多花多少钱？模型不可用时有没有替代方案？结果要不要进入 PR Review？日志和成本算给个人、团队还是项目？

这些问题不是管理洁癖，而是 AI 真正进入研发系统后的基本盘。

因为越强的 Agent，越接近真实执行者。它不是只回答问题，而是在消耗预算、读取上下文、调用工具、修改产物、影响交付。这样的能力如果只靠个人自由选择，很难沉淀成团队能力，也很难解释投入产出。

所以，AI Coding 的下一阶段，不是谁拥有最多工具，而是谁能把这些工具调度成稳定、可控、可度量的研发能力。

这也是为什么我觉得这周的 Signal 可以压成一句话：

从“选工具”，走向“管能力”。

AI 工具会继续变多，模型会继续变多，Agent 形态也会继续变多。真正拉开差距的，可能不是某个人用哪个工具更顺手，而是一个研发系统能不能把这些 AI 能力管理起来：可替换、可路由、可限额、可降级、可审计、可回流。

调度台不是为了显得复杂，而是因为 AI 能力开始进入真实研发工作之后，复杂性已经客观存在。

问题不再只是“哪个 AI 更好用”。

而是：团队如何把一组 AI，变成一套可靠的研发能力。