> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w33-cong-agent-team-kan-wei-lai-gong-zuo-fan-shi-de-5-ge-tai-jie.md).

# W33-从 Agent Team 看未来工作范式的 5 个台阶

最近，Claude Code 负责人 Boris Cherny 发布了一张名为 [Steps of AI Adoption](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit) 的表格。

他在[原帖](https://x.com/bcherny/status/2077929379661844559)里提到一个反复出现的现象。团队里有一个人借助 Claude 获得了数量级的产出提升，组织里的其他人却没有跟上。

这个观察很接近我最近的体感。AI 带来的差距已经不只是工具熟练度的差距。不同的人正在使用完全不同的工作范式。

Boris 把 AI adoption 分成 L0 到 L4 五个等级。更准确地说，这是五种状态和四次跃迁。我更愿意把它理解为未来工作范式的五个台阶。

## 五个台阶

| 层级       | 人的角色    | 工作方式                        | 主要瓶颈     |
| -------- | ------- | --------------------------- | -------- |
| L0 受限    | 旁观者     | 想用 AI，但真正有能力的模型被挡在工作之外      | 访问权限     |
| L1 辅助    | 结对者     | 你和一个 Agent 配合，它执行，你逐步检查     | 人的注意力    |
| L2 并行    | 编排者     | 你同时组织多个 Agent，它们执行和自检，你验收结果 | 评审能力     |
| L3 受监督自治 | 管理者的管理者 | 定时任务或事件主动触发工作，人审批例外         | 信任和决策吞吐量 |
| L4 AI 原生 | 意图定义者   | 数百或上千个 Agent 按目标运行，人按异常管理   | 价值判断和治理  |

Boris 在表中给出的 Agent 数量从 0、1、10、100 一直到 1000 以上。这些数字更像数量级，不是升级指标。真正重要的变化是人的角色。

在 L1，人仍然坐在每个任务的驾驶位上。Agent 更像一名速度很快的助手。

到了 L2，人开始设计分工、控制上下文、设置验收标准。工作过程由多个 Agent 并行推进，人的注意力主要放在结果和例外上。

L3 又跨了一步。任务不再全部由人逐次发起。系统开始监听事件、按计划运行、发现问题并主动创建工作。人不再管理每一个 Agent，而是管理 Agent 组成的工作系统。

## 多个 Agent 不等于 Agent Team

过去，我们一直关心怎样让单个 Agent 变得更强，怎样让它完成更长、更复杂的任务。单个 Agent 的能力总有边界，于是越来越多人开始同时使用多个 Agent。

Agent 多了，新的问题也随之出现。单个 Agent 的能力不再是唯一瓶颈，组织方式开始决定整体上限。

如果每项工作仍然要由人选择入口、整理背景、搬运 Context，再把一个 Agent 的结果交给另一个 Agent，那么这些 Agent 本质上仍是一组独立工具。人依然是整个系统里唯一的 Router，也是事实上的瓶颈。

我理解的 Agent Team 有三个特征。

第一，每个 Agent 长期负责自己的 Domain。它知道自己应该处理什么，边界在哪里，也知道哪些问题不属于自己。

第二，一部分协作责任从人转移给 Agent。它们在明确的责任关系里完成路由、交接和结果回流，不再要求人串联每一个步骤。

第三，人仍在 Team 里，只是位置发生了变化。人会在方向、事实、选择、Review 和授权的位置回来，不再盯住全部执行过程。

但当人不再参与每一步，另一个问题会立刻出现。我怎么知道这支 Team 到底运行得怎么样？

所以 Agent Team 还必须能够被观察、理解和持续调整。否则我只是从亲自调度每个 Agent，变成看不见它们在做什么。

## 第一次感受到一支 Agent Team

我对 L2 最深的一次体验来自 Multica。

我最初在 Multica 里建立了一个 Engineering Squad，用它构建一套连接公司内网代码托管平台的 MCP。早期版本里，Claude 负责策略、拆解和路由，Codex 负责实现，Gemini 负责探索和独立验收。我保留产品意图、优先级、取舍和最终批准。

这个组合第一次给了我很强的团队感。我把目标和边界说清楚以后，Leader 会继续拆分任务，选择合适的 Agent 完成探索、实现和验收。只有遇到需要判断的事情，我才会收到通知，再回到任务里做决定。

一次任务开始时，两份材料对接口风格和鉴权方式的描述互相冲突。Leader 没有马上让 Codex 写代码，而是先派出一个有边界的 Spike。任务只回答几个事实问题，要求真实请求作为证据，同时明确禁止实现 MCP。几分钟的探索避免了一次完整的错误实现。

后面的验收也暴露了 Agent Team 真正的价值。有份报告用无效 Token 返回 401 证明某种鉴权机制不存在。结论碰巧正确，推理却无效。另一轮测试全部通过，但真实 fixture 只有一个空数组，根本没有验证非空数据的字段结构。

这些报告没有造假。它们只是正确但不完整。Leader 需要换一个目标函数再次看证据，实现者和验收者也不能共享同一套自证逻辑。

这个任务最后形成了几条稳定规则。有界探索先于实现。作者不能成为高风险改动的唯一 Reviewer。证据必须同时说明证明了什么和没有证明什么。对外可见、不可逆或涉及身份背书的动作停下来交给人。

这就是 L2 给我的直接感受。一个人开始拥有一支协调成本很低的交付团队。

## 从一次配置到一套运行模型

之后，我开始把 Multica 的用法从临时配置变成一套可以维护的运行模型，并把它整理进 Git 仓库。

这里最关键的做法，是把四个对象分开。

| 对象                 | 负责什么                    | 变化速度      |
| ------------------ | ----------------------- | --------- |
| Profession Profile | 角色职责、判断边界、工具和证据契约       | 稳定，可版本化   |
| Agent Instance     | 具体 Runtime、模型、权限和并发     | 可以替换      |
| Squad              | 持久化使命、路由规则和成员关系         | 随稳定工作队列调整 |
| Issue Run          | 一次任务的目标、Context、证据和剩余风险 | 每次任务都不同   |

它的核心价值在于把稳定契约和可变部署分开。

角色职责应该稳定。Delivery Lead 长期负责拆解、路由、冲突裁决和证据收口。Implementation Engineer 长期负责实现和测试。Challenger 长期寻找反例并做只读 Review。Explorer-Validator 长期负责大上下文探索、影响面分析和独立验收。

具体 Runtime 和模型可以变化。今天的 Delivery Lead 可以部署在 Claude 上，Implementation Engineer 可以部署在 Codex 上，Challenger 使用 Grok，Explorer-Validator 通过 Antigravity 使用 Gemini。以后模型发生变化，可以替换实例，但不必同时重写 Team 的责任关系。

这不等于模型可以无成本互换。不同 Runtime 的权限、工具、会话和错误模式都需要重新验证。可替换指的是组织契约不绑定某个模型品牌，不是跳过部署验收。

## 现在的 Multica 配置

写这篇文章时，我在 Multica 中管理 8 个 Agent Instance 和 4 个持久化 Squad。

四个跨 Squad 的主力角色是 Delivery Lead、Implementation Engineer、Challenger 和 Explorer-Validator。另有 Product Architect、Market Researcher、Ops Engineer 和 Data Analyst，分别服务研究、架构和可靠性任务。

四个 Squad 按稳定工作队列划分。

| Squad                   | 进入条件                  | 默认路径                                     |
| ----------------------- | --------------------- | ---------------------------------------- |
| Engineering             | 日常功能、重构、普通 bug 和工程交付  | Claude 路由，Codex 单写，Gemini 验收，必要时 Grok 挑战 |
| Reliability & Incident  | 根因不明、跨模块、难复现或线上可靠性问题  | 多路只读取证，Claude 收敛假设，Codex 单写修复，非作者回归      |
| Research & Architecture | 技术选型、产品取舍、迁移或有限 Spike | Gemini 取证，Grok 攻击假设，Codex 只做有边界的实验       |
| Frontend Experience     | 用户流程、视觉、响应式、无障碍和浏览器验收 | Gemini 建立基线，Codex 实现，Gemini 在真实页面验收      |

Squad 不按仓库划分，也不因为出现一个新模型就新增。新仓库只是新的 Project 资源。已知该由谁负责的任务直接 Assign 给对应 Agent。只有工作需要多种能力，而且创建 Issue 时无法确定具体 Owner，才进入 Squad。

这套配置也有明确的硬边界。每个任务只有一个当前 Owner。每个 Worktree 只有一个 Writer。写入型 Agent 的并发为 1，非写入角色可以为 2，本机 Daemon 的总并发上限是 3。生产、凭据、发布、外部发送和不可逆动作始终由我批准。

## 每次只唤起最小必要角色

Agent Team 很容易被误解成每次让所有模型一起工作。这样做通常只会增加 Context、Token 和协调成本。

Multica 的 Squad 本身只是路由对象。Issue 分给 Squad 后，系统先唤醒 Leader。Leader 读取 Context，再决定下一步应该交给谁。Squad 不会自动运行所有成员，也不会增加并发。

所以我的默认规则是，每次只唤起足够完成任务的最小角色集合。

一个边界清楚的小修复，可以直接交给 Codex，不需要启动 Squad。陌生大仓库或 UI 任务，先让 Gemini 建立影响面和验收基线，再交给 Codex。难复现故障或高风险 Diff，才增加 Grok 的对抗性 Review。

默认同时激活不超过两个执行成员。并行只用于互不依赖的调查、同一个稳定 Commit 上的独立 Review，或文件范围完全不重叠的 Worktree。多个 Agent 同时修改同一份状态，速度看似提高，最后通常会变成冲突和返工。

Agent 数量不是 Team 成熟度。能否在正确时刻唤起正确角色，才是编排能力。

## DoD 是 Agent 之间的接口

Agent 之间能够直接协作，不代表可以只说一句你接着做。

我要求每次委派都写清四件事。

```
outcome: 最终可观察结果
evidence: 证明结果的测试、命令、截图、数据或链接
verification: 由谁、用什么方式验收
max_rounds: 最多返工轮数，默认 2
```

这就是 Definition of Done。它定义结果被接受前必须满足的证据契约。

Implementation Engineer 交付的不只是代码，还要返回变更范围、Commit、测试命令和原始结果。独立 Reviewer 读取的是目标、Diff 和测试，不接受作者的完成声明作为证据。Leader 收口时要列出实际结果、未验证项、剩余风险和需要人决定的事项。

`max_rounds` 同样重要。Agent 可以互相 Mention，但系统无法替我判断协作应该在什么时候结束。两轮返工后仍然证据冲突，Team 必须停止循环，把分歧交给人。

在 Multica 里，一个 Task 显示 `completed`，只说明这次 Agent Run 正常结束，不代表 Issue 的目标已经完成。真正决定任务能否进入 Review 的，是 DoD 和证据。这条区分让 Agent 的运行状态和工作的完成状态分离开来。

## Agent Team 也需要配置工程

角色 Prompt 写得再好，也不能证明 Team 在真实环境里可以运行。

我把 Git 仓库设为配置事实源。`config/agents/` 保存角色契约，`config/squad-*.md` 保存路由规则，`config/topology.json` 保存 Agent、Runtime、权限、并发和 Squad 拓扑。Multica 线上对象只是这套声明的运行副本。

同步器默认只输出变更计划。人工检查后才应用，再运行一次，结果必须是 `No changes.`。未纳管对象只报告，不自动删除。Workspace ID、Agent ID、Token、Webhook 和本机路径都留在仓库外。

这套机制解决的是配置漂移。角色和路由发生变化时，我可以看到 Diff，可以 Review，也可以把线上状态重新对账到预期状态。

实际接入过程也让我看到，Agent Team 远不只是几段 Prompt。Leader 既要操作 Multica 控制面，又不能写项目文件。Grok 需要只读 Review，却不能继承过宽的网络和写入能力。桌面 Runtime 还会受到代理、沙箱、命令参数和本机环境影响。

这些问题先后暴露后，我连续修正了控制面直连、沙箱边界和 CLI 子命令匹配。配置文件里写着允许，不代表运行时真的健康。每个关键角色都需要真实的正向和负向烟测。

## 从 Agent Team 再看五个台阶

从 Agent Team 的视角看，未来工作范式的五个台阶，本质上是路由、协作和验收责任逐步从人转移到系统。

| 层级 | Agent 的组织方式                 | 人的主要工作                |
| -- | --------------------------- | --------------------- |
| L0 | Agent 无法进入真实工作              | 继续使用原有流程              |
| L1 | 多个独立工具，人是唯一 Router          | 逐次提供 Context，检查每个结果   |
| L2 | 角色和 Squad 持久化，Leader 选择最小团队 | 定义目标和 DoD，验收证据，处理关键选择 |
| L3 | 日程或事件主动触发 Agent Team        | 管理例外、权限、预算和停止条件       |
| L4 | 多支 Team 按意图运行，组织结构可以动态调整    | 决定方向、价值和不可委托的边界       |

我目前处在 L2 到 L3 之间。现在这套 Multica 配置解决了角色、路由、证据和可观察性问题，但大多数任务仍由我主动创建。

L3 的关键变化是触发权。Multica 的 [Autopilot](https://multica.ai/docs/autopilots)可以让周期任务或 Webhook 事件自动创建 Issue，再交给 Agent 或 Squad。此前我在[《Builder 的 Mac，也需要一个 Sweeper》](https://weekly-essay.mikey.wang/zh/2026-nian/w32builder-de-mac-ye-xu-yao-yi-ge-sweeper)里写过每天治理 Skills、每周检查 Mac 环境的 Routines。这类工作更接近 L3。

但触发权不能走在验证能力前面。没有 DoD、证据、权限、停止条件和可观察记录，自动唤醒更多 Agent 只会让错误更早发生，也更难被发现。

团队整体仍以 L1 为主，大多数人处在 L1 向 L2 过渡的阶段。大家已经会使用 Agent，下一步要把角色、路由、验收和权限变成共同的工作系统。