最近，很多团队都在讨论 AI 编程工具的使用率。
有人关心每个人每天发了多少次请求，有人统计代码生成量，也有人开始要求团队把 AI 使用率做成指标。可当我们把视角从单次对话拉长，会发现一个更实际的问题：
团队使用 AI 的成熟度，不取决于接入了多少模型，而取决于能否建立一套可信、可控、可持续扩张的工程闭环。
从一个工程师配一个智能体，到一个人编排十几个智能体，再到智能体持续处理维护任务，这中间不是简单地把并发数从 1 调到 10、再调到 1000。
每向前走一步，团队都会遇到新的瓶颈。真正需要扩张的，不是会话数量，而是验证、治理和协作能力。
有些团队仍停留在非常受限的阶段。
模型只能使用较旧或更轻量的版本；访问 AI 工具需要层层申请；网关、鉴权、网络策略不断叠加；生成的代码没有明确的托管路径，最终只能停在个人电脑上。
这类问题看上去像基础设施问题，实质上是组织没有形成对 AI 工程实践的共识。
如果团队讨论的重点始终是每个 Token 花了多少钱，而不是一个需求从提出到验证上线到底缩短了多少时间，那么 AI 很容易被当成一个需要严加控制的成本项，而不是提升研发吞吐的能力。
从这里走出来，需要的并不是更复杂的提示词，而是让技术、管理和安全团队对几个基本问题达成一致：哪些数据可以进入模型，哪些代码可以由 AI 生成，生成结果如何进入现有的审查、测试和发布流程，以及谁为最终结果负责。AI 不是绕过治理，而是要进入治理。
当一名工程师开始稳定地使用一个智能体协作时，变化通常很明显。
过去要占满一个下午的小改动，现在可能在两场会议之间就能做完。写样板代码、补测试、梳理调用链、定位熟悉模块里的问题，这些任务往往都能获得直接收益。
但这个阶段仍然是同步协作。工程师要盯着每次回答，检查每一处修改，决定每一个权限提示是否通过。模型在工作，人也很难切换到别的任务上。看起来是人机协作，实际更像一个速度很快、但还需要全程带教的新同事。
这里的瓶颈不是生成速度，而是审查注意力。
如果每次生成的结果都要逐行阅读、逐个命令确认，那么 AI 只是把写代码的时间转移成了看代码的时间。效率会提升，但上限很快出现。
所以，团队从单智能体走向多智能体之前，先要解决一个关键问题：什么样的验证结果，能够让我们放心地不再逐行盯着它。
当一个工程师开始同时处理多个智能体任务时，工作方式会发生变化。
这时，工程师不再主要扮演代码作者，而更像一个编排者。不同智能体可以在独立的 worktree 中处理不同需求：一个补测试，一个修缺陷，一个做依赖升级，一个处理文档或配置。
人不再关注每一次敲键盘，而是关注最终差异、测试结果和风险边界。这听上去很美，但也最容易踩坑。
如果多个智能体共享同一份不完整的上下文，或者同时改动彼此依赖的模块，最终只会得到更多冲突、更长的审查队列，以及更难追踪的质量问题。并发不会自动带来吞吐，缺乏隔离和验证的并发，只会放大混乱。
这个阶段至少要具备几项基础能力：
这里有一个很容易被忽视的事实：智能体越多，人工审查压力不一定越小。
过去你只审一条代码流，现在可能同时面对六条、十条甚至更多。于是瓶颈从写代码变成了判断哪一条结果值得信任、哪一条需要介入、哪一条应该直接终止。
这也是为什么自动化验证比提示词技巧更重要。
很多团队卡在多智能体阶段，并不是模型不够聪明，而是没有建立可信的闭环。
所谓闭环，不是让智能体跑完测试就结束，而是让它能够完成一轮相对完整的工程判断：
需求是否理解正确，改动是否符合现有架构，测试是否覆盖核心路径，构建和静态检查是否通过，风险是否落在允许范围内，失败后该继续修复还是交给人处理。
当这个闭环足够可靠，团队才可能从监督式协作走向受监督的自主化。此时，人的问题也会变化：过去我们会问，这段代码你看过了吗？之后更应该问，模型为什么没有拿到这段代码背后的上下文？这个问题是提示词不够清楚、知识库缺失、规则没有沉淀，还是测试无法识别真正的风险？
这是一种很重要的转变。
如果每次错误都靠人工在审查阶段兜底，团队永远只能增加更多审查者。如果把错误反推到上下文、规则、测试和权限设计上，下一次同类任务就可能不再犯同样的问题。
智能体的可靠性不是一次性买来的，而是通过一次次失败被工程化出来的。
当智能体可以持续运行时，它们处理的就不再只是临时任务。
依赖升级、陈旧代码清理、测试缺口补齐、反馈修复、代码迁移、文档同步，这些过去总是排在需求后面的维护工作，开始有机会被持续处理。
这时，技术负责人不可能再逐个任务审批。真正需要管理的是意图、优先级、预算、风险和异常。
例如，一个团队可以让智能体定期扫描依赖漏洞，但不能让它在没有约束的情况下自动升级所有组件。因为升级带来的兼容性风险，需要结合业务优先级、测试覆盖率和发布窗口判断。
同样，智能体可以自动补充测试，但不能因为覆盖率指标而生成大量没有断言价值的测试代码。
规模化自动化的核心，不是让智能体做得更多，而是让每类工作都匹配合适的护栏。不同任务的护栏应该不同：
如果所有任务都使用同一种权限和同一套流程，团队最终不是过度保守，就是失去控制。
从 1 个智能体到 1000 个智能体，不是一条必须走完的升级路线。
对很多团队来说，能够稳定地让几个智能体并行处理低风险、可验证的任务，就已经能带来很高价值。特别是测试、构建、代码审查、依赖维护这类工作，本身就适合被拆成明确的验证环节。
真正值得投入的，不是一个看起来很壮观的智能体数量，而是下面几件事：
AI 采用的成熟度，最终不是看团队有多少个会话窗口，而是看团队能不能把智能体产生的速度转化为可验证的工程产出，并在效率提升的同时守住质量、成本和责任边界。
当我们不再把 AI 当成聊天工具，而是当成需要进入研发体系的执行单元，真正的变化才刚刚开始。
相关阅读
##### FunTester 名片｜万粉千文，百无一用