Nebutra 技术博客
把 1000 个 Agent 放进一个任务：Claude 子代理与工作流背后的工程逻辑
当 AI 执行深度研究时，答案背后往往不是一个聊天机器人，而是一支临时组建、并行工作的 AI 团队。本文解释 Claude 子代理、工作流、上下文隔离、并行工具调用、结构化输出、可靠性与 token 经济学。
Tseka Luk21 分钟阅读
当 AI 执行深度研究时，答案背后往往不是一个聊天机器人，而是一支临时组建、并行工作的 AI 团队。本文解释 Claude 子代理、工作流、上下文隔离、并行工具调用、结构化输出、可靠性与 token 经济学。
Tseka Luk21 分钟阅读Nebutra Originals
当你让 AI「深度研究」一个问题、几分钟后拿回一份带引用的报告时，背后往往不是一个 AI，而是一支由 AI 临时组建、并行作业的「团队」。这篇文章用尽量少的黑话讲清楚：它是怎么运转的，以及为什么它的成败最终写在一本 token 账本上。
先说一个直觉性的结论：今天最强的 AI 产品，正在从「一个聊天机器人回答你」，悄悄变成「一个 AI 当项目负责人，临时雇一队 AI 帮它干活」。Claude 网页端的「研究」功能、各家的「Deep Research」，背后都是这套东西——业内把它叫多智能体(Multi-Agent)系统。
为什么 AI 工具爱好者、投资人和初创团队都该关心它？因为它同时决定了两件事:产品能力的天花板(能不能让 AI 真正自主完成复杂任务)，和单位经济模型的地板(每完成一个任务要烧多少钱)。这两件事，恰恰是「demo 惊艳、商业化却很难」的根源。读懂它，你就读懂了一类 AI 产品为什么强、又为什么贵。
这篇文章分两段走：先用尽量少的黑话，讲清这套系统在底层到底怎么跑——架构、记忆、并发、成本、可靠性;再回答你最关心的两个问题：它什么时候值得用，又该怎么稳稳地落到生产里。过程中会穿插一个真实的 Claude Code 用例，帮你把抽象的原理落到具体代码上。
读前小词典
Token —— AI 处理文字的最小计费单位，可粗略理解成「字数」。烧 token ≈ 烧钱，这是后文一切成本讨论的基础。
上下文窗口(Context Window) —— 一个 AI 一次能「记在脑子里」的内容上限，可以理解成它的工作记忆;装满了就会开始遗忘或被迫截断。
智能体(Agent) —— 不只是回答问题，还能自己调用工具(搜索、读网页、写文件)、一步步把任务做完的 AI。
太长不看
Anthropic 在《Building effective agents》里划了一条关键的架构分界线。[1]两者都属于「agentic systems」，但:
| 维度 | Workflow（工作流） | Agent（智能体） |
|---|---|---|
| 控制权 | LLM 与工具被预定义代码路径编排，你拥有「管道」 | LLM 自己决定流程与工具调用，模型拥有「管道」 |
| 子任务 | 在写代码时就已固定 | 由编排者根据具体输入动态拆分 |
| 适用场景 | 边界清晰、要可预测可复现的任务 | 需要灵活性与模型自主决策、且要规模化时 |
那段开头的脚本，本质上是 Workflow：每一步在哪调用模型、并发几路、何时进入确认阶段，都由代码写死。而 Claude 网页端的「研究(Research)」功能——模型自己决定派几个子智能体、各干什么——才是真正的 Agent。Anthropic 给的工程箴言很简单:先找最简单的方案，只在必要时才增加复杂度。[1]
官方把工作流归纳为五种递进模式:提示链(固定步骤 + 可选程序化「闸门」)、路由(分类后分流到专用处理，例如简单问题走 Haiku、难题走 Opus)、并行化(分片 sectioning / 投票 voting)、编排者–工作者，以及评估者–优化器(一个生成、一个批判，循环改进)。其中编排者–工作者与单纯并行化的区别在于:子任务不是预先定义的，而是编排者临场决定的。[1]
《How we built our multi-agent research system》是最硬核的一手资料。[2]整条链路是这样的:
这套设计的内核思想,Anthropic 用一句话点破:
搜索的本质是压缩——从庞大语料里把洞见蒸馏出来。[2]
子智能体之所以有用，正是因为它们能并行地、各自在独立窗口里探索问题的不同侧面，再把最关键的 token 浓缩给主智能体。性能上，以 Opus 4 为主、Sonnet 4 为子的多智能体系统，在内部研究评测中比单体 Opus 4 高出 90.2%。[2]开源的编排者提示词也写得很直白：主智能体的职责是协调、引导与综合，而非自己下场做一手研究。[11]
在《Effective context engineering for AI agents》里,Anthropic 把上下文当成有限资源来工程化。Transformer 对 n 个 token 会产生 n² 的两两关系，注意力会被「摊薄」，于是出现所谓的 context rot(上下文腐烂)[3]。结论是：好的上下文工程，就是找到能最大化目标达成概率的、最小的高信噪比 token 集合。[3]
按 Agent SDK 的子智能体文档：每个子智能体跑在全新的会话里，中间的工具调用与结果都留在子智能体内部,只有它的最终消息回到父级。父子之间唯一的通道，就是 Agent 工具的那个 prompt 字符串。子智能体拿不到父级的对话历史、工具结果或系统提示——没有共享内存。[6]父级的上下文只增长那一段摘要，而不是整段子任务的流水。
NOTES.md)，需要时再读回。Claude 玩宝可梦时，就靠这招在数千步之间维持计数与状态。API 层也把这些能力产品化了:context editing 在接近上限时自动清理陈旧的工具调用/结果;memory 工具把信息存到窗口外的文件目录(客户端侧执行);更进一步的服务端压缩会在逼近上限时自动总结较早的上下文。Anthropic 的评测里,memory 工具 + context editing 让智能体检索性能比基线提升 39%[5];在一个 100 轮的网页检索评测里,context editing 把 token 消耗压低了 84%。[5]
并行发生在两个层级：主智能体一次拉起 3–5 个子智能体，而每个子智能体又能一次发起 3+ 个并行工具调用。Anthropic 称这把复杂查询的研究时间最多压缩了 90%。[2]
| 指标 | 含义 |
|---|---|
| 3–5 | 主智能体一次并行拉起的子智能体数(默认推荐 3 个，上限 20) |
| 16 | Dynamic Workflows 的最大并发智能体数(硬上限) |
| 1000 | Dynamic Workflows 单次运行的智能体总数上限 |
在 API 层,Claude 会在同一轮里吐出多个 tool_use 块，应用需要把所有结果放进同一条 user 消息、各自一个 tool_result 块返回(拆成多条会削弱后续的并行度)。[8]同一轮里的工具调用无序，可以直接 Promise.all / asyncio.gather 跑掉。
python
# 主智能体在一轮里发起多个 tool_use；应用并行执行后
# 把全部结果塞进同一条 user 消息回传
results = await asyncio.gather(*[
run_tool(call) for call in assistant_turn.tool_use_blocks
])
messages.append({
"role": "user",
"content": [tool_result(c.id, r) for c, r in zip(calls, results)]
})关于「能跑多少」:API 级别的多智能体系统没有模型强加的子智能体硬上限，约束来自你的 API 速率限制与基础设施。Anthropic 按组织分三个维度限流——RPM、每分钟输入 token(ITPM)、每分钟输出 token(OTPM)，用令牌桶算法，超限返回 429(带 retry-after)，与表示 Anthropic 容量不足的 529 区分开。Dynamic Workflows(2026 年 5 月随 Opus 4.8 进入研究预览)则把硬上限写死成 16 并发 / 1000 总量:Claude 写一段 JS 编排脚本交给后台运行时执行,计划活在脚本变量里、而非 Claude 的上下文里，只有最终答案回流——这正是你那段脚本对应的官方形态。[12]
Agent SDK(原名 Claude Code SDK)把驱动 Claude Code 的那套「智能体外壳」开放出来:智能体循环、内置工具、子智能体派生、MCP 集成。核心循环就一句话——收集上下文 → 采取行动 → 验证结果 → 重复，直到任务完成。[4]
python
# 用更便宜的 Sonnet 当 worker，Opus 只做严格复核
agents = {
"researcher": AgentDefinition(
description="按单一目标做一手检索", # Claude 据此决定何时调用
prompt=SUBAGENT_SYSTEM_PROMPT,
tools=["WebSearch", "Read"], # 收窄工具面
model="sonnet",
max_turns=8,
),
"reviewer": AgentDefinition(
prompt=ADVERSARIAL_VERIFY_PROMPT, # 对抗性复核
model="opus",
),
}
# 把 Agent 放进 allowedTools，委派即自动批准；子智能体不能再派生子智能体query() 的 agents 参数、.claude/agents/ 下的 markdown 文件，或内置 general-purpose 来定义。Claude 通过 Agent 工具(在 Claude Code 里由 Task 改名而来)发起调用。一条铁律：子智能体不能再派生自己的子智能体。[6]session_id + agentId 后可 resume，保留完整历史;子智能体的流水存在独立文件里，能挺过主会话的压缩。default / acceptEdits / plan / bypassPermissions / dontAsk;评估顺序是 PreToolUse 钩子 → 拒绝规则 → 允许规则 → 询问规则 → 权限模式 → 回调 → PostToolUse。拒绝规则即便在 bypass 模式下也最高优先。[7]子智能体继承父级的宽松模式，不能逐个覆盖。子智能体回传的东西要能被下游代码可靠 JSON.parse，靠的是 Structured Outputs / 严格工具调用。机制是语法约束解码(constrained decoding):API 编译你的 schema、缓存 24 小时，在生成每一个 token 时都施加约束[9]，从而保证工具名一定在你给的工具里、工具入参一定符合 input_schema。
没有严格模式时，模型可能把 2 返回成 "2"、漏掉必填字段、或吐出非法枚举值。这正是那段脚本里 RESEARCH_SCHEMA 用 additionalProperties:false + 全量 required 的意义——它不是写给人看的注释，而是喂给约束解码器的契约。代价是首次请求有约 100–300ms 的语法编译延迟;数值范围、字符串长度这类约束 schema 不强校验，仍需事后验证。
多智能体之所以有效，主要是因为它帮你「花掉了足够多的 token」去解决问题。[2]
在 BrowseComp 评测的归因分析里，三个因素解释了 95% 的性能方差，而其中仅 token 用量本身就解释了约 80%[2]，另外两个是工具调用次数与模型选择。成本侧：智能体大约是普通对话的 4× token，多智能体系统约 15×。[2]
什么时候值得上多智能体?
值得:高价值、可重并行、信息量超出单个上下文窗口、需要对接大量复杂工具的任务(典型如深度研究)。
不值得:要求所有智能体共享同一上下文、或彼此强依赖的任务。大多数编码任务就属于这一类——真正可并行的部分，比研究少得多。
一个好用的拇指规则(来自 Barry Zhang)：约 10 美分/任务的预算 ≈ 3–5 万 token，大致是工作流的地盘;只有当任务模糊到无法预先画出决策树、又值钱到能摊掉 token 成本时，才升级到智能体。
Anthropic 把这句话当成核心警句:智能体是有状态的，错误会复合。[2]对智能体而言，一个微小的系统故障都可能是灾难性的。生产化要点:
Anthropic 一句话点题:最好的提示不是死板的指令，而是「协作框架」[2]——它定义分工、解题路径与「努力预算」。几条最实用的:
前面都是原理，这里给一个具体的落点。下面这段是在 Claude Code 里实际跑过的一个编排脚本(workflow)的节选，任务很朴素：给一份机构清单做现状核查——逐家确认是否还在活跃、有没有改名换网址。它值得一看，是因为短短几行就把前面几节讲的几件事一次性用上了:
javascript
phase('Research')
const researched = (await parallel(
funds.map((f) => async () => {
const r = await agent(prompt(f), { schema: RESEARCH_SCHEMA })
return r ? { id: f.id, name: f.name, ...r } : null // id/name 由脚本拼回，不问模型
}),
)).filter(Boolean) // 失败的 agent 返回 null，过滤掉parallel(funds.map(…)) 让一家机构一个 AI、同时开跑，而不是排队。id / name 由脚本拼回、绝不问模型，从根上避免张冠李戴和凭空捏造。schema 把 AI 的回答锁成一张固定的「填空表」，下游才好解析。null 再过滤掉，不让一个点拖垮整批。脚本后半段还会只挑出「查出有变化」的少数几家、另派一个 AI 做对抗性复核——也就是前面说的职责分离。一个并不复杂的真实需求，就能把这套架构的大半用上;真正的难处不在写出它，而在让它在生产里稳定、可控、可追溯地跑起来——这正是下面要谈的。
注:90.2% / 15× / 80% 等数据来自 2025 年中期 Opus 4 + Sonnet 4 配置下的特定评测(内部研究评测、BrowseComp)，未必可外推到你的任务或更新的模型;Dynamic Workflows 及部分上下文能力处于 beta / 研究预览阶段，可用性随平台不同而异。
| 可控、便宜、可调试 |
| 更贵、非确定、更难调试，但天花板更高 |
0
讨论
使用 Nebutra 账号参与评论。评论会先进入审核队列。