Claude Opus 5.5 不仅仅用于聊天。

开发者正用它来管理AI代理团队、撰写内容、进行审核并真正赚取收益。

以下是从头开始构建您的第一个AI代理团队的方法。https://t.co/0yssII21AE

如何使用 Claude Opus 5.5 构建您的第一个 AI 代理团队

每个人都在谈论 AI 代理。

请收藏此内容 :)

构建一个代理。部署一个代理。代理这个，代理那个。

在 Anthropic 随 Claude Opus 5.5 发布的提示指南中，埋藏着一个几乎没有被任何发布会报道提及的结果。

当 Anthropic 给一个代理团队设定时间预算时，该团队在保持与单个代理相当的答案质量的同时，显著更快地完成了任务。

请再读一遍，因为它悄然重新定义了两年来每个开发者一直在问的问题。这个问题始终是关于选择哪个模型。Opus 5.5 给出了令人信服的答案：它在 Terminal-Bench 4.0 上的得分为 66.4%，而体积大得多的 Claude Fable 5.1 得分为 55.8%；在典型工作负载下运行成本比 Opus 5 低约 40%；一位早期测试者用它在一天内完成了一次 68 万行代码的迁移。但对于您接下来构建的东西，真正重要的结果与模型本身无关。它关乎当你停止运行单个代理并开始运行一个协同工作的团队时会发生什么。

问题就在这里。现在大多数构建“多代理系统”的人，实际上是在构建昂贵的混乱。五个角色模糊、拥有全部权限、没有支出上限的代理，互相传递半成品的上下文，并行返回看似自信的垃圾结果。演示效果极佳，但在生产环境中失败，而失败通常被归咎于模型。

模型不是问题所在。架构才是。

本课程将引导您构建一个真正有效的团队：一个负责规划和分配任务的协调者（orchestrator）、拥有狭隘职责和更严格权限的专家（specialists）、一个将不合格工作退回的批评者（critic），以及防止整个系统失控的预算、上限和停止条件。这里所有内容均使用 Claude Agent SDK 和 Anthropic 记录的真实 Opus 5.5 行为，而非上一个模型时代的老生常谈。

让我们开始构建。

为什么需要团队，以及 Opus 5.5 如何改变计算方式

在编写任何代码之前，先理解一个团队实际能为你带来什么。Anthropic 的 Agent SDK 文档列举了委派给子代理的四个具体好处，每一条都是实实在在的理由，而非感觉。

上下文隔离。 每个子代理在自己独立的全新对话中运行。它的中间工具调用和结果保留在其内部；只有最终消息返回给父代理。一个研究子代理可以阅读五十页内容，而无需让这些内容膨胀协调者的上下文。协调者收到的是一个干净的摘要，而不是完整的对话记录。

并行化。 独立的子任务完成时间取决于最慢的那个，而不是所有任务时间的总和。同时进行三个研究角度的调查，所花时间与最耗时的那个相同，而不是三倍。

专门化的指令。 每个子代理都获得为其专业知识和约束量身定制的系统提示，而不会给协调者的指令增加噪音。

工具限制。 每个子代理可以被限制为仅使用特定工具。一个永远不应编辑文件的审核者，根本不会收到编辑工具。

现在说说 Opus 5.5 的部分。其三个有据可查的行为使这个模型特别适合运行团队。

首先是成本。Opus 5.5 的定价为每百万输入 token 4 美元，每百万输出 token 20 美元，低于 Opus 5 的 5 美元和 25 美元，缓存读取价格为每百万 0.20 美元。团队会增加你的 token 消耗，因此更便宜的前沿模型会改变哪些团队在经济上是可行的。

其次是努力程度。Opus 5.5 默认为中等努力程度，而 Anthropic 报告称，在中等努力下，它在编码和知识工作评估中的表现达到或超过了高努力程度下的 Opus 5。Anthropic 的努力程度文档明确将子代理列为低努力程度的典型使用场景。这意味着你的工作者可以精简运行，而你的协调者则保持所需的推理深度。

第三是时间感知。Anthropic 的提示指南指出，Opus 5.5 “密切关注关于经过时间的信息”，并可利用它来优化代理团队中的并行化。这就是本文开头那个发现，你将在步骤 10 中使用它。

第一条规则：大多数任务不需要团队

这是炒作所忽略的部分，也是能为你节省最多资金的部分。

团队增加了协调开销、更多的 API 调用、更多的 token 以及新的失败方式。如果你的任务是一项工作，并且有明确的检查方法，那么一个配置良好的单个代理每次都会比一个团队更快、更便宜。

只在上述四个好处中至少有一个能真正发挥作用时才使用团队。这项工作自然分成可以同时运行的独立部分。或者，某个子任务会用后续没人需要的材料淹没主上下文。或者，工作的某一部分确实需要与其他部分不同的专业知识或不同的权限。

如果这些都不适用，关闭这个标签页，构建一个单个代理。如果适用，请继续阅读。

有效团队的解剖结构

每个可靠的代理团队都是三种角色的某种组合。

协调者（The orchestrator） 接收目标，将其分解为子任务，将每个子任务分配给合适的专家，并组装结果。它负责规划和整合。它不亲自做深入的工作。在一个构建良好的团队中，它是你唯一需要对话的代理。

专家（The specialists） 每个都极其出色地完成一项狭隘的工作。一个只收集和验证事实的研究员。一个只根据已验证材料起草的作家。一个只处理数字的分析师。角色越狭隘，输出越好，因为一个专注的指令每次都能胜过一个模糊的指令。

批评者（The critic） 是几乎每个人都跳过的角色，也是区分专业系统和演示系统的关键。它唯一的工作是根据标准审核输出，如果不达标就将其退回。没有批评者的团队会快速产出自信的垃圾。有批评者的团队则能产出可发布的工作。

正确把握这三点，你就掌握了每个值得构建的团队的骨架。

步骤 1：设置 Agent SDK

Claude Agent SDK 提供了与驱动 Claude Code 相同的代理循环、工具和上下文管理，可通过 Python 和 TypeScript 编程。它是你自己运行团队的正确工具。

你需要 Python 3.10 或更新版本，或者 Node.js 18 或更新版本，以及从 Claude Console 获取的 API 密钥。

python3 -m venv .venv
source .venv/bin/activate
pip install claude-agent-sdk
export ANTHROPIC_API_KEY=your-api-key

对于 TypeScript：

npm install @anthropic-ai/claude-agent-sdk

SDK 从运行你的代理的进程环境中读取密钥。它不会自动加载 .env 文件，所以如果你将密钥保存在 .env 文件中，需要在调用 SDK 前自行加载。

如果你正在为其他人构建产品，有一点需要注意：Anthropic 不允许第三方开发者在未经事先批准的情况下在他们的产品中提供 claude.ai 登录或速率限制。请使用 API 密钥身份验证。

步骤 2：首先单独构建协调者

最常见的错误是在一个代理单独工作之前就设计整个团队。不要这样做。从协调者单独运行开始，证明任务是可行的，然后才开始委派其中的部分任务。

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, ResultMessage

async def main():
    async for message in query(
        prompt="Research the three most-discussed AI agent frameworks this month and write a one-page briefing to drafts/briefing.md.",
        options=ClaudeAgentOptions(
            model="claude-opus-5-5",
            allowed_tools=["WebSearch", "WebFetch", "Write"],
            permission_mode="acceptEdits",
        ),
    ):
        if isinstance(message, ResultMessage):
            print(f"{message.subtype}: ${message.total_cost_usd}")

asyncio.run(main())

运行它。阅读输出。注意它在哪里遇到困难，在哪里花费了最多的 token，以及哪些部分彼此之间真正独立。这些记录就是你的团队设计。那些独立的子任务变成并行的专家。质量不稳定的部分变成批评者的工作。

步骤 3：定义你的第一个专家

专家使用 AgentDefinition 定义，并通过 agents 选项传递。有两个必填字段，其中一个的重要性远超人们所意识到的。

from claude_agent_sdk import AgentDefinition

researcher = AgentDefinition(
    description="Gathers and verifies facts on one focused question. Use for any research subtask.",
    prompt="""You research exactly one question and return verified findings.
For every claim, include the source URL.
If you cannot verify a claim, mark it UNVERIFIED instead of dropping it or guessing.
Return a numbered list: claim, source, confidence (high, medium, low).
Do not write prose.""",
    tools=["WebSearch", "WebFetch"],
    effort="low",
)

prompt 是专家的系统提示。给它一个角色、一个标准、一个输出格式和边界，就像你向承包商做简报一样。

description 是大多数人低估的字段，它决定了你的团队是否能正常工作。协调者读取每个专家的描述来决定何时委派给它。模糊的描述意味着协调者要么从不使用该专家，要么用在错误的事情上。把它写成调用此代理时的精确规则。如果你需要保证某个特定专家运行，请在你的提示中直接命名它，例如 “Use the researcher agent to check each claim.”

还有一个让所有人都头疼的问题：你的协调者的 allowed_tools 必须包括 Agent，因为子代理是通过 Agent 工具调用的。

步骤 4：赋予每个角色最小的必要权限

这是将脆弱的演示转变为可以持续运行的系统的关键步骤。

从你专家的工具列表中排除的工具，完全不会出现在其会话中。Claude 在没有它的情况下也能工作，没有权限提示，也没有错误。这使得工具限制成为你拥有的最干净的安全控制措施。

Anthropic 的文档建议以下组合作为起点：

• 只读分析： Read, Grep, Glob。可以检查但不能修改或执行。
• 测试执行： Bash, Read, Grep。可以运行命令和分析输出。
• 代码修改： Read, Edit, Write, Grep, Glob。完全读写，但不能执行命令。

将这个原则应用到每个角色。你的批评者得到只读工具，因为一个能编辑的批评者会悄悄“修复”问题而不是报告它们。你的研究员得到搜索和获取工具，没有写入功能。只有负责生成文件的代理才拥有 Write。

Opus 5.5 也使这比以前更安全。在 Anthropic 的隔离测试中，Opus 5.5 试图规避边界的情况比 Opus 5 少了约 85%。声明的限制比以往更具约束力。这是需要清晰陈述它们的理由，而不是跳过它们的理由。

步骤 5：解决交接问题

这是那个会悄然破坏大多数初次构建团队的细节。

子代理从全新的上下文开始。它看不到父代理的对话历史、父代理的工具结果或父代理的系统提示。Anthropic 的文档明确指出：从父代理传递给子代理的唯一内容是 Agent 工具的提示字符串。

这意味着，如果你的协调者委派时说“现在把它写出来”，作者根本不知道“它”是什么。专家需要的每一个文件路径、每一个决定、每一个约束、每一份证据都必须包含在委派消息本身中。

将此直接放入你的协调者指令中：

当你委派任务时，为每个子代理撰写一份完整的简报。包括它需要的所有文件路径、
发现、决定和约束。假设它从未见过此次对话的任何内容。需要猜测的子代理是一个
会猜错的子代理。

反之亦然。父代理接收子代理的最终消息，但可能会对其进行摘要。如果你需要完整保留专家的输出，请指示协调者逐字保留。

步骤 6：并行运行独立工作

只有当工作真正同时进行时，团队的速度优势才会显现。

多个子代理可以并发运行，并且子代理默认在后台运行，因此协调者可以同时调度多个并继续工作。实际的做法是将你的子任务设计为独立的。三个研究员各自调查不同的框架可以同时运行。一个需要所有三个报告的作家则必须等待它们完成。

明确告诉协调者哪些部分可以一起运行：

这三个框架调查是独立的。同时派出所有三个研究员，
然后等待每份报告，再让作家开始工作。

如果你为团队构建了自定义工具，还有一个额外的控制点。将工具标记为 readOnlyHint=True 告诉 SDK 它没有副作用，这允许它与其他只读工具并行调用。只标记那些确实不修改任何内容的工具。

步骤 7：添加批评者

现在是让输出值得信赖的角色。

critic = AgentDefinition(
    description="Reviews a finished draft against the research findings it was written from. Use after every draft, before anything is final.",
    prompt="""You review a draft against the findings it was written from.
Check that every factual claim appears in the findings.
Check that nothing marked UNVERIFIED is stated as fact.
Check that the structure matches the brief.
Return PASS, or FAIL followed by a numbered list of specific fixes.
You never edit the draft yourself.""",
    tools=["Read"],
    effort="medium",
)

然后将此循环连接到协调者的指令中：每份草稿都送给批评者，FAIL 的草稿将附带批评者的具体修正清单返回给作者，如此循环直到得到 PASS。

给这个循环设置上限。一个永远意见不合的工作者和批评者会争论到让你预算耗尽。告诉协调者在三轮后停止，并附上批评者尚未解决的异议，返回最佳草稿。明确的退出机制是系统与循环的区别。

步骤 8：为每个角色设置努力程度

这是 Opus 5.5 提供的最大成本控制杠杆之一，而大多数人却置之不理。

努力程度有五个级别：低、中、高、非常高和最大。它控制模型在整个响应中投入的工作量，包括思考的频率和深度。在 Opus 5.5 上，思考始终开启且无法禁用，因此努力程度是控制模型推理程度的主要手段。

AgentDefinition 接受一个 effort 字段，因此你可以独立调整每个角色：

• 研究员和简单工作者： 低。Anthropic 的努力程度文档将子代理列为典型的低努力用例。
• 作家和批评者： 中。默认值，并且在 Opus 5.5 上，它在编码和知识工作中的表现达到或超过了高努力程度下的 Opus 5。
• 协调者： 中等起步，如果你的评估显示规划质量有所提高，可以设为高。

将 xhigh 保留给大约 30 分钟以上的长期代理工作，max 则用于你测量到有真实质量提升的任务。Anthropic 的指导是在你自己的评估上进行努力程度扫描，而不是沿用早期模型的设置。

步骤 9：限制深度、并发度和花费

Claude 自己决定何时生成子代理以及生成多少。子代理可以生成它们自己的子代理。没有限制的话，一个提示可能演变成一棵代理树和一张你未曾计划的账单。

SDK 为你提供了三个限制：

• 深度（Depth）： CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH。默认为 3 层。将其设为 1，这样你的专家就无法生成自己的子代理。
• 并发度（Concurrency）： CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS。默认为一次运行 20 个。
• 花费（Spend）： Python 中为 max_budget_usd，TypeScript 中为 maxBudgetUsd。默认无限制。

最后这个默认值值得你关注。你的第一次团队运行没有支出上限，除非你设置一个。在运行前设置一个。