Howie2099

Claude Code子智能体：上下文隔离与任务委派

子智能体用独立上下文消化噪声任务，主对话只回收摘要，保住信噪比与注意力

2026-07-21
AgentAIClaude

🎯 核心主张（一句话）

子智能体的本质是给主对话装舱壁：把"输入巨大、结论很小"的任务丢进独立上下文执行，主对话只收回压缩后的摘要——保护的是信噪比和注意力，不只是 Token。

📖 正文

问题：长任务会把主上下文变成垃圾场

Claude 的上下文窗口约 20 万 Token，但大不等于好用。500 行错误日志里真正有价值的可能只有 3 行错误栈，200 行测试输出你要的只是"3 个失败、47 个通过"一句话。噪声塞进主对话后不会安静待着——它们持续稀释注意力，于是出现典型的"注意力漂移"：模型遗忘早前发现的关键错误码、把无关的失败项误判成核心问题、甚至引用不存在的函数名。

这是大模型时代的"内存泄漏"。操作系统用进程隔离防止野指针搞崩系统，微服务用故障舱壁防止级联雪崩，回答的都是同一个问题：怎么防止任务互相干扰。开新对话不是答案——那等于把桌子连同有用的文件一起扔进碎纸机，项目背景全丢。

CEO 委派模型

正确姿势是换角色：主智能体不当埋头干活的职员，当 CEO。财务审计交给财务总监，故障排查交给 SRE，自己只读提炼后的汇报、做决策。

子智能体 = 一个拥有独立上下文窗口 + 受限工具白名单 + 明确任务范围的 Claude 实例。它带来三层价值：

  1. 隔离：子智能体读的文件、跑的命令输出、中间推理，全部留在自己的上下文里，随子进程终止一起释放。主对话只收到一句"根因：charge.ts
    缺少空值检查"。
  2. 约束：工具白名单是物理边界，不是"请不要修改文件"式的劝告。审查智能体只给 Read/Grep/Glob，即使模型误判意图也写不了文件——最小权限原则。
  3. 复用：定义就是一个 Markdown 文件，可进 Git、随项目分发，新人克隆即用。

委派的判断标准是输入输出体量比：输入远大于输出（分析几百行日志换 5 行结论）才值得委派；输入约等于输出（改一个函数、写段注释）时，隔离开销比收益大，直接在主对话做。

怎么定义一个子智能体

在项目 .claude/agents/ 下放 Markdown 文件，YAML frontmatter 定义"是什么"，正文定义"怎么做"：

---
name: code-reviewer
description: 审查代码质量、安全漏洞和性能问题；用户要求代码审查或安全审计时使用
tools: [Read, Grep, Glob]        # 白名单外的工具不可见、不可调用
model: sonnet                     # 简单任务配 haiku，深度推理配 sonnet/opus
permissionMode: plan              # 系统级只读，比白名单更硬的保险
---
你是资深代码审查专家。按【审查摘要/发现的问题/改进建议】固定格式输出，
问题必须标注 file_path:line_number。

各字段的门道：

  • name：唯一标识，日志和调用链里的身份证。
  • description：路由广告牌。主智能体拿用户意图和所有已注册智能体的 description 做语义匹配，命中即自动委派，不需要用户点名。写得越具体（"何时使用"），路由越准。
  • tools：安全价值最高的字段。执行型可以放开 Bash，但能进一步收窄成 Bash(npm test:*) 这种前缀限制。
  • model：被低估的成本杠杆——跑测试、过滤日志这种模式化任务用 Haiku 就够，不必请首席架构师做单元测试。
  • 高级字段 skills（预加载知识包）和 hooks（绑定事件检查）见后文。

另一个关键设计：用输出格式约束逼子智能体做压缩。在正文里写死"严禁包含完整测试日志，仅输出摘要"，回传主对话的才是结论而非原始噪声——这是外观模式（Facade）：复杂子系统藏在里面，只暴露简化接口。

三种协作形态：并行、流水线、团队

只读型和执行型是单兵模式，覆盖大多数日常场景。任务变复杂后有三种协作形态，各有严格的适用前提和代价。

并行型：多专家同时开工。像同时派三个侦探查物证、人证、监控——安全审计、质量检查、性能分析各自在隔离空间跑，最后主智能体汇总成综合报告。这就是 MapReduce：主智能体做任务分发（Map）和结论聚合（Reduce）。硬性前提是子任务完全独立、无共享状态；一旦存在"先定位才能修复"这类依赖，强行并行只会产出垃圾。收益是省时间加专业化——三个 90 分的专才优于一个 70 分的全能选手。Ctrl+B 可把子智能体转入后台，实现真并行。

流水线型：串行处理链。经典案例是 bug 修复流水线：定位 → 修复 → 验证 → 影响报告，每阶段输出是下一阶段输入，即 Unix 管道 cat log | grep ERROR | sort 的 Agent 版。两个关键设计：一是交接契约——上游输出格式必须严格匹配下游输入要求（bug-locator 输出"根本原因文件 + 修复方向"，恰好是 bug-fixer 的启动输入）；二是各阶段权限动态收放——locator 只读、fixer 读写加 Bash、verify 只读加 Bash 禁改代码、report 纯只读，每一环只持有履职必需的最小权限。

团队型：多会话自组织。前几种模式里子智能体都是一次性的，任务完成即销毁；团队型的成员长期存续，靠 Team Lead（分解调度）+ Teammates（专业分工）+ 共享设施（Task List 同步进度、Mailbox 异步通信）持续协作。适合竞争假设调查（多方向并行验证再择优）、对抗式方案审批（一个提案、一个专挑毛病）、大型重构按模块分田到户等场景。代价是长期维持的上下文意味着持续 Token 消耗，判断标准：子智能体之间需要多轮通信和深度协调才上团队型，一次性任务用并行或流水线就够。

模式可以组合（流水线某一环内嵌并行），但嵌套别超过两层——需要三层以上通常说明任务分解本身有问题，应该扁平化重构而不是加深。

Skills 与子智能体的组合：身份归智能体，方法归 Skill

子智能体解决了隔离，但没回答"专业知识从哪来"。bug-fixer 有全套工具，却不知道项目用 Result 模式还是 try-catch。答案是组合，只有两种原子模式：

  • 方向 A：子智能体预加载 Skill（frontmatter 加 skills: [secure-coding]）。子智能体是执行者，Skill 是它手里的操作手册。适合流水线里需要持续运用领域知识的角色。System Prompt 由智能体定义文件提供，Skill 内容作为领域知识注入。
  • 方向 B：Skill 派生子智能体（SKILL.md 里设 context: fork + agent: general-purpose）。Skill 是主角，子智能体只是为隔离而临时生成的执行容器。适合一次性的重型标准流程，如全库健康检查。

判断标准就一句：谁是主角。需要维持角色状态、多轮协作 → 方向 A；重点是复用一套标准流程且需要隔离 → 方向 B。这个分工让 Skill 成为可复用知识模块——同一个 secure-coding，bug-fixer 拿来修代码，code-reviewer 拿来查合规。

何时不该用子智能体

  • 输入 ≈ 输出的小任务：隔离开销大于收益，主对话直接做。
  • Token 账并不总是划算：API 无状态，主对话里的噪声每轮都重发，隔离确实省钱；但 Prompt Caching 让缓存命中只收 10% 价格，书中案例的节省率从 6.8% 缩到 1-2%。子智能体的真正价值是窗口保护（避免提前触发压缩丢关键信息）和响应质量（纯净上下文减少注意力稀释），省钱是副产品。
  • 子智能体间是报文传输，不是共享内存：它们看不到主对话历史，也感知不到彼此，全靠主智能体提取上游结论、嵌进下游任务描述。所以每阶段输出必须高度结构化，否则转发就会失真。
  • 中断即失忆：子进程被打断，中间成果全丢。长任务应让子智能体把进度持久化到文件（如 .claude-work/log-analysis.md），重启后先读文件接续断点。

🧭 业界视角（书外补充）

  • Shrivu Shankar 的"看守上下文"警告（How I Use Every Claude Code Feature）：自定义子智能体会把上下文"看守"起来——如果建一个 PythonTests 子智能体，主 agent 就看不到任何测试相关上下文，无法对改动做整体推理。子智能体只适合"结论可压缩"的任务（搜索、调研、验证），不要把核心工程上下文切走。这是对本章 CEO 模型的重要修正：有些事 CEO 必须亲自看细节。
  • Anthropic 上下文工程指南：上下文是稀缺资源，性能随填充度衰减；三大手段是 compaction、just-in-time retrieval、structured note-taking。子智能体 + 中间产物写文件，正是后两者的工程化组合。
  • 分层选型的社区共识：提示词模板 → slash command；有领域逻辑 → Skill；需要隔离上下文的并行工作 → 子智能体；必须 100% 执行 → Hook。最常见的错误不是不会用，而是把该丢给子智能体的检索任务留在主会话里刷满日志。
  • Vercel 团队：删掉 80% 的 Agent 工具后流程更快、Token 更省。这印证了工具白名单的另一层价值——工具越少，模型的选择越准，白名单既是安全边界也是性能优化。

🔗 知识网络