子 Agent 实战：场景、机制、context 影响、框架实现

子 Agent 实战手册

从场景出发：什么时候用、怎么用、底下发生了什么

场景一：写代码 + 自动 Review
自己审自己容易放水 → 拆成两个角色
一个 Agent 写完代码后自己 Review，倾向于认为自己写的没问题——就像学生自己批自己的作业。需要一个独立的"第二双眼睛"。
主 Agent
接收任务+协调
→
子 Agent A
写代码
→
📄 代码文件
→
子 Agent B
Review 代码
→
主 Agent
汇总结果
底层发生了什么
主 Agent
收到你的指令"重构 auth 模块"
判断需要写+Review → 决定拉两个子 Agent
主 Agent
调用 delegate_task：
goal="重构 auth 模块" · toolsets=["file","terminal","code_execution"]
子 A
获得独立 context + 独立终端
只收到 goal + 指定的工具，不继承主 Agent 的对话历史
子 A
在隔离环境中读文件、写代码、跑测试
过程中消耗的是子 Agent 自己的 context，不占主 Agent 的
子 A
完成 → 返回一段摘要给主 Agent
"已重构 auth.ts、user.ts、test 3/3 通过"（只传摘要，不传全文）
主 Agent
收到子 A 的摘要 → 再拉子 B 做 Review
goal="Review auth 模块的改动" · context="子 A 的摘要"
子 B
又一个全新的独立 context
只看到被改动的文件 + 子 A 的摘要，不知道主 Agent 之前聊了什么
子 B
发现 2 个问题 → 返回 Review 结果给主 Agent
主 Agent
汇总：重构完成，Review 有 2 个问题需要修复
报告给你，或者再派子 Agent 去修
对 context 的影响：
不用子 Agent
系统+规范
15%
对话历史
30%
代码文件
35%
Review
20%
写代码+Review 全挤在一个 context 里 = 快满了
用子 Agent
主 Agent 的 context：
系统+规范
15%
对话历史
20%
子 A 摘要
5%
子 B 摘要
5%
大量代码细节留在子 Agent 的独立 context 里，主 Agent 只收摘要 = 空间充裕
Claude Code
Agent Teams：主 Agent 拉起"writer"和"reviewer"两个子 Agent，各自在独立分支工作
/agent-team create writer reviewer
Hermes
delegate_task 串行调用：先 delegate 给写代码的 profile，再 delegate 给 review 的 profile
delegate_task(goal="...", toolsets=[...])
Codex
子代理自动派生：Codex 自动判断是否需要拆分，用内置的 subagent 机制
自动触发，无需手动配置
场景二：批量处理 10 个文件
串行做太慢 → 并行扇出
你有 10 个 CSV 文件，每个都需要做同样的分析+出图。一个 Agent 串行做要 20 分钟，而且做到第 7 个时 context 已经被前 6 个的结果撑满了。
主 Agent
分配任务
→
子 1 → 文件 1-2
子 2 → 文件 3-4
子 3 → 文件 5-6
子 4 → 文件 7-8
子 5 → 文件 9-10
→
主 Agent
汇总 10 份
底层发生了什么
主 Agent
扫描 data/ 目录发现 10 个 CSV
判断：同一个操作重复 10 次 → 适合并行扇出
主 Agent
调用 delegate_task(tasks=[...]) 批量模式
同时拉起 5 个子 Agent，每个分 2 个文件
子 1-5
5 个子 Agent 同时开工，各自独立 context
子 1 只看到文件 1-2，子 2 只看到文件 3-4…互不干扰
子 1-5
各自完成 → 各自返回摘要
"文件 1：Q1 收入 ¥342 万↑12%，文件 2：Q2 收入 ¥428 万↑25%"
主 Agent
收到 5 份摘要 → 合并成总报告
主 Agent 的 context 里只有 5 段摘要，不是 10 个文件的全部内容
✅ 速度
串行 20 分钟 → 并行 4 分钟（5 倍提速）
✅ Context
主 Agent 只存 5 段摘要（~500 token），不是 10 个文件的完整分析（~50,000 token）
⚠ 成本
5 个子 Agent 同时跑 = 5 倍的 token 消耗速率。但总量可能更少（因为每个子 Agent 的 context 更小更精准）
⚠ 上限
受 max_concurrent_children 限制（默认 3-5）。10 个文件不会拉 10 个子 Agent，而是分批跑
Hermes
delegate_task batch 模式：传入 tasks 数组，自动并行
delegate_task(tasks=[{goal:"分析file1"}, {goal:"分析file2"}, ...])
Codex
子代理自动并行 + Cloud 模式可跨容器
codex cloud exec --parallel
Hermes Kanban
decompose 自动拆成子任务卡片，分配给 worker profiles
/kanban create → /kanban decompose
场景三：超长文档分析
一个 context 装不下 → 拆成分段读取
一份 200 页的 PDF 报告，单个 Agent 的 context 放不下全部内容（或者放进去后质量严重下降）。需要拆分处理。
主 Agent
拆文档+汇总
→
子 A → 第 1-50 页
子 B → 第 51-100 页
子 C → 第 101-150 页
子 D → 第 151-200 页
→
主 Agent
综合四段摘要
生成完整分析
关键机制：摘要压缩
每个子 Agent 读 50 页，生成一段 500 字的摘要返回给主 Agent。主 Agent 拿到 4 段摘要（共 2000 字）就能综合出对 200 页文档的整体理解。

200 页全文 ≈ 100,000 token → 4 段摘要 ≈ 3,000 token。压缩比 30:1。这就是子 Agent 解决 context 瓶颈的核心原理。
但要注意：摘要过程中必然会丢失细节。如果主 Agent 后续需要某个具体细节（比如"第 87 页那个表格"），它需要再派一个子 Agent 去专门读那一段。这就是"摘要→按需深入"的两级模式。
所有框架
通用做法：主 Agent 用 bash 把 PDF 分段（按页），每段交给子 Agent 读取+摘要
pdftk input.pdf cat 1-50 output part1.pdf
Hermes Kanban
自动分解"分析 200 页 PDF" → 4 个子任务，每个负责 50 页
/kanban decompose → 自动拆 4 个
Gemini 3.1
2M context 可能直接装下全文——但质量在中间段仍然下降。拆分依然更可靠
不拆也行，但效果不如拆
子 Agent 的核心原理：用"摘要"换"空间"
三个场景都在做同一件事：让子 Agent 处理大量细节，只把摘要传回给主 Agent。
没有子 Agent
所有细节挤在一个 context 里：
代码全文 + Review 全文 + 10 个文件的数据 + 200 页 PDF
→ context 爆炸，质量崩塌
有子 Agent
细节在子 Agent 的独立 context 里处理：
主 Agent 只收到摘要 → context 轻量、精准
→ 每个 Agent 都在舒适区内工作
代价：摘要意味着信息损失。子 Agent 决定"什么值得汇报给主 Agent"——如果它漏了关键信息，主 Agent 就不知道。所以子 Agent 的摘要质量取决于它的 Skill 和指令写得好不好。"返回时包含所有数字和关键结论"比"总结一下结果"好得多。