如何构建 AI Agent 团队：从首个 Agent 到生产级团队的 9 个阶段

大多数试图构建“AI Agent 团队”的人，最后都变成了一个 Agent 在五个标签页里自言自语。9 成的多 Agent 项目永远无法走出演示模式。

这些 Agent 不共享上下文、不分担工作、不知道其他 Agent 在干什么。下面这份 9 阶段路线图，能把这种混乱变成 一个真正协作的团队。

关注我的 Substack，获取新鲜 AI 前沿资讯：

movez.substack.com

一个 AI Agent 团队听起来很简单：几个 Agent，各司其职，协同完成单个 Agent 无法独立完成的任务。但当你真正尝试时，就会发现那些演示从未展示过的问题。

关键在于结构。下面这 9 个阶段就是结构——它基于 Anthropic 官方工程文档中关于 Claude Agent SDK 的论述、其多 Agent 研究蓝图中的模式，以及那些在 2026 年交付真实 Agent 系统的团队与仍在演示模式中挣扎的团队之间的差异。

三个层级：先让单个 Agent 正确运行，再让它们协同工作，最后让整个团队达到生产级。

9 个阶段。3 个层级。一个在你睡觉时就能完成工作的团队。

第一部分 · 单个 Agent

01. 定义 Agent 循环

在进入第一阶段之前最常见的错误：把智能聊天机器人当成 Agent。聊天是一次对话回合。Agent 是一个循环——模型接收目标，选择动作，执行动作，观察结果，然后决定下一步做什么。它会一直持续，直到目标完成或循环达到停止条件。

本文后续所有内容都假设你在代码中有一个真正的循环。伪代码能让结构一目了然：

注意其中包含：审批关卡、日志钩子，以及清晰的停止条件。如果你的“Agent”就是一个大提示词，要求模型一次性完成所有操作，那么你并没有 Agent——你只有一个冗长的补全。本文后面的所有内容都需要一个真正的循环作为基础。

专业提示： 停止条件比人们想象中更重要。没有明确终点的循环会烧钱。常见的停止条件：目标达成、达到最大迭代次数（通常为 30-50 次）、用户明确暂停、错误阈值超过上限。务必设置 max_iterations。一个失控的 Agent 比一个慢的 Agent 更糟糕。

02. 设计上下文：写入、选择、压缩、隔离

上下文是 Agent 中最昂贵也最脆弱的部分。大多数 Agent 失败——那些看起来像是“模型太笨”的情况——实际上是上下文失败：模型从未获得所需信息，或者信息过多导致分心，又或者信息已经过时。

根据 Anthropic 官方工程文档，有四个关键操作：

• 写入——每一步要添加到上下文的内容。要精心设计。每一行都会消耗 token 和注意力。
• 选择——从记忆或文件中提取什么。是检索，而不是倾倒。
• 压缩——当上下文填满时，总结旧部分，同时保留关键决策。
• 隔离——子 Agent 在自己的上下文窗口中工作，使主线程保持干净。

在实践中，这意味着一个结构化的上下文对象，而不是自由格式的字符串拼接。一个工作正常的 Agent 上下文应具有以下形态：

这里最大的单一收益是隔离子 Agent 上下文。当主 Agent 将研究任务委托给子 Agent 时，子 Agent 获得一个全新的窗口，只包含任务和相关文件。它返回一个摘要，而不是原始的完整记录。主 Agent 永远看不到那些噪音。这个模式正是子 Agent 能够工作的关键。

03. 编写模型能正确选择的工具

如果没有类型化的工具模式，模型每次调用都会即兴发挥消息格式、参数结构和权限。

这种即兴发挥正是大多数生产故障的来源。 不是模型不能调用工具，而是它猜错了格式，发送了错误的参数，或者做了它没有权限做的事情。

一个类型化的模式将任务从“猜怎么调用”转变为“填写这些字段”。并且它让执行器能够强制实施模型无法绕过的规则：

除了基本类型之外，这些字段使其达到生产级：preconditions 是调用运行前必须满足的条件；side_effects 告诉下游读者会发生什么；requires_approval 将调用路由到人工检查点；blocked_targets 是执行器强制执行的硬约束，无论模型决定什么。

第二部分 · 协作层

04. 在隔离上下文中生成子 Agent

子 Agent 不是主 Agent 的副本。它是一个拥有自己上下文、自己工具集、通常还有自己模型的专家。当编排器决定“这部分是研究”时，它会生成一个研究子 Agent——只给它相关的目标，只让它使用相关的工具，让它运行在更便宜的模型（如 Haiku）上，然后等待摘要返回。主线程永远不会看到原始的研究内容。

在 Claude Agent SDK 中，这是 Task 工具。在代码中，调用看起来像这样：

1> spawn_subagent(
2    role="research",
3    model="claude-haiku-4-5",
4    goal="找到 src/ 中所有缺少身份验证的 API 端点",
5    tools=["grep", "read_file"],
6    return_format="summary + file list"
7  )
8
9▲ subagent_a  在隔离上下文中启动…
10  - 扫描 142 个文件
11  - 标记了 11 个端点
12✓ 完成 · 返回了 1.2K token 的摘要，完整记录未加载到父进程

子 Agent 的 return_format 字段比任何提示词都重要。如果你让子 Agent 返回自由文本，编排器会被淹没。

强制结构化返回——一个摘要字符串加上事实列表、文件列表、发现列表。然后编排器将这些结构化返回组合成下一步决策，而无需读取噪音。

05. 设计编排器：规划、委派、绝不执行

编排器是树顶端的 Agent。它唯一的工作就是规划、委派和收集。它不写代码、不运行查询、也不直接与 API 对话——如果它做了这些，就会用本应属于子 Agent 的细节污染自己的上下文。编排器要保持轻量，以便能够全面把握整个任务。

一个工作正常的编排器在主 Agent 循环内部嵌套了三个循环：

1def orchestrator_loop(goal):
2    plan = make_plan(goal)                  # 步骤 1：规划
3    results = []
4
5    for step in plan:
6        subagent = pick_specialist(step)    # 步骤 2：委派
7        result   = run_subagent(subagent, step)
8        results.append(result)
9
10        if plan_needs_revision(result):
11            plan = revise_plan(plan, result) # 中途调整
12
13    return synthesize(results)             # 步骤 3：收集

编排器通常使用最强大的模型（2026 年的 Opus）。它下面的子 Agent 通常是 Sonnet 或 Haiku。

这就是成本数学的妙处：昂贵模型运行计划，廉价模型执行工作。按照这种模式，一个团队可以比单个 Opus 设置多处理 5-10 倍的任务，而且总成本更低。

06. 构建共享任务列表

没有共享状态，你的“团队”就是并行的工作单元。两个子 Agent 从同一个步骤开始。一个完成了某一步，但没人知道。编排器忘记了把什么分配给了谁。解决办法是一个所有 Agent 都能读写、结构化的共享任务列表——不是创意文档，而是结构化文件。

1{
2  "goal": "为所有未受保护的端点添加身份验证",
3  "tasks": [
4    {
5      "id": "t1",
6      "description": "找到未受保护的端点",
7      "status": "done",
8      "assignee": "subagent_a",
9      "result": "src/routes/*.ts 中有 11 个端点"
10    },
11    {
12      "id": "t2",
13      "description": "为每个端点添加 JWT 中间件",
14      "status": "in_progress",
15      "assignee": "subagent_b",
16      "depends_on": ["t1"]
17    },
18    {
19      "id": "t3",
20      "description": "编写集成测试",
21      "status": "pending",
22      "assignee": null,
23      "depends_on": ["t2"]
24    }
25  ]
26}

有三点让这种结构比纯记忆更有效：明确的负责人意味着两个 Agent 永远不会选择同一个任务。明确的依赖关系阻止子 Agent 在其输入尚未准备好的情况下运行步骤。明确的状态让编排器无需推理记录就能检查进度。

第三部分 · 生产级团队

07. 添加记忆、持久性和沙箱

演示级 Agent 在会话结束时就会遗忘。生产级团队会记住该记住的，忘记该忘记的。按顺序需要接入三件事：

• 记忆——一个 Agent 主动写入的结构化存储。不是对话记录；那太嘈杂了。每个事实、决策或值得保留的约定都单独放在一个文件或数据库行中。例如 memory/decisions.md、memory/conventions.md、memory/known_failures.md。下一个会话会明确加载这些内容。
• 持久性——每一步在继续之前，都会将其操作和结果写入磁盘。如果进程在循环中途崩溃，下次启动时会读取轨迹并恢复。没有这一点，一个 50 步的任务在第 47 步失败，就会从头开始。这是 Agent 工程中最被忽视的细节。
• 沙箱——Agent 在容器或受限子进程中运行，无法访问任何未经明确授予的内容。不会因为某个人的提示词跑偏而读取你的主目录。不会在项目文件夹外写入。沙箱是“帮助你 的 Agent”和“让你破财的 Agent”之间的墙。

1# 决策日志
2
3## 2026-05-22
4- 选择了 JWT 而非会话 cookie（移动端客户端驱动）
5- 身份验证代码位于 src/auth/，不重复到每个路由
6- /api/admin 下的所有端点需要角色检查，而不仅仅是登录
7
8## 2026-05-29
9- 采用了共享任务列表模式（state/tasks.json）
10- 编排器使用 Opus，子 Agent 使用 Sonnet/Haiku
11- max_iterations = 30 每循环，由执行器强制执行硬上限

08. 接入评估和轨迹检查

大多数团队更改他们的 Agent 系统后，不知道更改是好是坏。他们在熟悉的任务上运行两次，感觉“更好了”，然后就发布了。六周后，他们在忘记检查的案例上得到了比原版更差的系统。评估解决了这个问题。

生产级团队需要的三个测量层：

• 评估集——20-100 个固定任务，带有已知的正确输出。每次有意义的更改后都运行它们。追踪通过率随时间的变化。
• 轨迹检查——不仅仅是“是否完成”，还要检查“是否大致按正确的顺序调用了正确的工具”。通过错误路径得到正确答案，是未来的回归隐患。
• CI 回归门禁——评估集在 PR 上自动运行。如果通过率低于阈值，PR 被阻止。与代码测试相同的纪律。

<code-code-segment id="seg_4" lang="json">

{

"id": "auth_refactor_001",

"input": "为所有未受保护的 /api/* 端点添加 JWT 身份验证",

"expected": {

"endpoints_protected": 11,

"files_touched": ["src/auth/jwt.ts", "src/routes/*.ts"],

"tests_added": "每个端点至少一个测试",

"no_changes_to": ["src/db/", "src/email/"]

},

"trajectory_must_include": [

"grep_for_unprotected_endpoints",

"read_existing_auth_module",

"apply_middleware_to_each_endpoint",

"run_tests"

],

"max_iterations": 30

}

</code-code-segment>

trajectory_must_include 列表是秘密武器。两个 Agent 可能通过截然不同的路径产生相同的答案——一条安全，另一条离灾难只差一次糟糕的批准。

轨迹检查会在不安全路径发布前将其捕获。配合生产运行期间的匿名日志记录，你可以从已经发生的案例中自动构建评估集。

09. 带权限和人工检查点发布

最后一个阶段是让你能安心睡觉的阶段。一个权限文件声明了团队可以未经许可做什么、需要人工批准做什么、以及永远不允许做什么。执行器在每个工具调用前都会读取这个文件。模型无法绕过它，因为规则存在于模型之外。

1## 始终允许（无需批准）
2- 读取项目目录中的任何文件
3- 运行测试
4- 创建分支
5- 写入 memory/ 和 skills/ 目录
6- 创建草稿 Pull Request
7
8## 需要批准
9- 合并 Pull Request
10- 部署到任何环境
11- 删除 memory/working/ 之外的文件
12- 安装新依赖
13- 修改 CI/CD 配置
14
15## 永远不允许
16- 强制推送到 main、production 或 staging 分支
17- 直接访问密钥或凭证
18- 发送不在批准域名列表中的 HTTP 请求
19- 修改 permissions.md（只有人类可以编辑此文件）
20- 禁用或绕过 pre_tool_call 钩子
21
22## 批准的外部域名
23- api.github.com
24- registry.npmjs.org
25- pypi.org

这个文件是整个生产栈中最重要的工件。它决定了 Agent 团队是可以整夜运行，还是需要你全程看护。在生成第一个子 Agent 之前就写好它，而不是等到第一次事故之后。

§ 让团队卡在演示模式的错误

• 没有真正的循环。 一个写着“逐步思考”的长提示词不是 Agent。没有迭代，没有观察，没有恢复。
• 自由格式的上下文。 把所有东西都塞进窗口。模型被干扰，错过了重要的信息。
• 未类型化的工具。 自由文本参数，没有前置条件。模型猜测，有时是错的，有时是破坏性的。
• 没有隔离的子 Agent。 当子 Agent 与编排器共享上下文时，你得到的是五个话多的 Agent，而不是一个专注的团队。
• 编排器自己执行。 主 Agent 自己写代码，沉溺于本应由专家处理的细节中。
• 没有共享任务列表。 “团队”退化为并行工作，重复劳动。
• 没有持久性。 一个 50 步的任务在第 47 步崩溃，然后从头开始。烧钱，浪费时间。
• 没有评估。 “更好”只是一种感觉。六周后你无法解释为什么某些事情能工作或失败。
• 没有权限文件。 高速但没有安全网。离真实事故只差一次糟糕的批准。

结论：

一个 AI Agent 团队不是更多模型。它是更多结构。

这个路线图中的一切都是基础设施。没有什么是花哨的。没有什么是需要世界上其他人没有的前沿模型的。在 2026 年交付真正多 Agent 系统的团队，使用的模型和别人一样。他们拥有而演示模式团队没有的，是 Agent 之间那 9 个阶段的结构。

如果你读到这里，并且之前尝试过多 Agent 设置，那么“为什么行不通”的答案可能就在这里。找出你跳过的那个阶段——通常是共享状态或权限——明天就加上它。然后下一个。一个能发布的团队是一步步建立的，而不是凭一个周末的感觉。