Claude Code · Agent 架构与核心链路

Claude Code 的产品形态是「会用工具的 agent」。它的机制其实就两件事:一条不停转的 核心链路(agentic loop), 以及在链路里随时能 把活外包给子 agent 的能力 —— 后者就是所谓「agent team」的底座。下面把这两件事拆开走给你看。

依据 Claude Code 官方文档(code.claude.com/docs)整理 · 场景与数字为示意,机制(阶段顺序 / 隔离规则 / 循环条件)属实
PART 1 — THE CORE LOOP

核心链路:一个回合怎么转

模型不是「问一句答一句」,而是在一条循环里反复:装配上下文 → 推理 → 过权限 → 执行工具 → 把结果回灌 → 判定要不要再来一圈。唯一的退出条件:模型这次的输出里不再有 tool_use。

↻ 继续:本次响应里有 tool_use
STAGE 1
装配上下文
gather context
STAGE 2
模型推理
inference
STAGE 3
权限闸门
permission
STAGE 4
工具执行 / 派发
execute
STAGE 5
结果回灌
tool_result
STAGE 6
判定:继续 / 收尾
loop · stop
↻ 继续 = 响应里有 tool_use,回到 Stage 1 增量装配 ✓ 收尾 = 没有 tool_use,退出循环、把最终文本交还用户
步骤 1/1 · 回合 1
STAGE

父 agent 上下文窗口(示意)

实际占用0

若把子 agent 的中间读取都塞进父

反事实对照0
委派的意义:子 agent 读 90 个文件的过程留在它自己的窗口里,父这边只 +几段最终结论。条值为示意,非真实 token。
PART 2 — DELEGATION (FAN-OUT · FAN-IN)

子 agent 派发:把活外包出去

Stage 4 执行的工具如果是 Agent,父就在一条消息里同时发出多个,fan-out 成并行的子 agent。每个子 agent 是个带全新上下文窗口的独立 worker —— 这正是「agent team」的底层原语。跑到上面时间线的派发步骤,这块会亮起来。

◆ 主 agent(orchestrator) 等待 Stage 4 的 Agent 调用…
fan-in: 3 个子 agent 各自读了几十个文件,但只把【最终结论】当作一个 tool_result 交回父。 它们的中间过程(读取、试错、迭代)不进入父的上下文 —— 这就是委派省 context 的根源。
INVARIANTS — 这些是机制本身

子 agent 的隔离(接缝)

  • 全新上下文窗口:不带父的对话历史,只拿到父给的那段任务 prompt。
  • 自己的系统提示 / 工具子集 / 模型:由 .claude/agents/*.md 的 frontmatter(name·description·tools·model)定义。
  • 只回最终消息:子 agent 的完整 transcript 不回父,父只收到它的最后一条消息当 tool_result。
  • 不能再派子 agent:层级只有一层,子 agent 内部不能再开 Agent。

循环与上下文(机制)

  • 退出条件唯一:模型某次响应里没有 tool_use → 收尾;有则继续。
  • 并行 fan-out:一条消息里多个 Agent 调用并发执行(运行时最多 16 并发)。
  • 委派省 context:父保留「结论」,不保留「翻了哪些文件」。
  • 压缩兜底:上下文逼近上限时自动 compact —— 先丢旧工具输出,再摘要对话,保留 CLAUDE.md 与近期请求。
PARALLELISM — 四种并行原语

「agent team」其实有四档

从一次性 worker 到长期协作会话,按规模和协作强度递进。子 agent 是底座,其余三档在它之上加东西。

子 agent(Agent 工具)· 底座
一次性 worker,各自独立窗口,只把最终消息回父,不能再派子。研究 / 校验 / 专项任务的默认选择。
CLI + SDK 核心能力
worktree 隔离
子 agent 各跑在自己的 git worktree 里,并行改文件互不打架,跑完自动清理。
isolation: worktree
Agent Teams(实验)
多个长期 peer 会话,共享一张任务表、能互相喊话,由 team lead 协调 —— 适合要互相讨论的活(如安全 vs 性能评审对辩)。
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
动态工作流
用一段 JS 脚本编排,单次最多上千 agent / 16 并发,中间结果留在脚本变量里。适合 10+ agent、可复用的编排计划(审计 / 迁移 / 交叉验证)。
/effort ultracode · 内置 /deep-research
BOUNDARY — 边界守则

哪些是真的,哪些是为了讲清楚编的

属实(可以放心讲):六阶段的顺序与含义、循环的退出条件(有无 tool_use)、子 agent 的隔离(独立窗口 / 自带系统提示·工具·模型 / 只回最终消息 / 不能再派子)、fan-out·fan-in 并行、worktree 隔离、委派省 context、deferred 工具 schema、压缩兜底策略,以及四种并行原语的区别。

示意(不要当真实计量):上下文条的数值、子 agent 读了几个文件、Grep/Edit 这套具体场景、各步骤的措辞,都是为讲解编的例子。真实的 token 计量、调度细节、模型选择由运行时决定。并发上限 16、工作流上千是文档数,场景里其余数字是编的。