子 Agent 要不要继承父 Agent 的上下文？我的答案是隔离，而且隔离是多 Agent 这套东西里少数几个真站得住的理由。但隔离不等于把历史砍干净——砍太狠的子 Agent 会自己编背景，跑得比不隔离还偏。中间那条线是一份显式的任务简报。
父 Agent 的犹豫会顺着上下文流下去
不隔离的坏处，第一反应是烧 token：每多一层嵌套，父 Agent 的整段历史就被重放一遍，长会话里这笔账很难看。但真正要命的不是钱。
父 Agent 的上下文里有大量半成品判断——"这条路看着不行"、"刚才那个报错可能是权限问题"、"用户好像更想要 A"。这些在父 Agent 那里是草稿，传下去就变成了事实。子 Agent 读到"方案 B 试过，失败"，它会绕开 B，哪怕 B 只是当时超时了。污染不是幻觉，是语气。
Quantifying Overclaiming Propensity in Frontier LLM Agents 那篇讲的也是这件事的另一面：agent 的最终回复常常是用户能看到的唯一账目，而它会倾向于把没做完的说成做完了。父 Agent 转述子 Agent 的产出时，同样在 overclaim。链子越长，失真越难查。
简报给太薄，子 Agent 就开始编背景
反过来说，隔离做过头是真的会翻车。你不告诉它代码库的约定、上次为什么改了这个接口、命名用什么风格，它写出来的东西能跑，但合不进去。然后父 Agent 花在 review 和返工上的时间，比省下的 token 贵得多。
所以"隔离"这个词其实不准。准确说是不传历史，传约束。历史里 90% 是过程，约束才是结论。
这周 An Empirical Study of Harness Design for Coding Agents 和它的配套 HarnessTax 都在做同一件事：把 harness 拆成组件逐个比，而不是当成一个黑盒打分。这正好说明"给子 Agent 什么"是个可以测量的设计变量，不是玄学。想自己验证的话，固定模型和任务集，只改传给子 Agent 的那段文本——先给全文历史，再给简报，看通过率和 token 消耗怎么动。别信我，测自己的任务。
写一份人能读的简报，比调 prompt 有用
我现在用的模板就四块：目标一句话，验收标准一句话，已知约束（技术栈、不能动的接口、必须走的入口），以及相关文件路径加一句"为什么相关"。明确不写进去的东西也要列：父 Agent 的试错过程、用户的闲聊、其他子任务的中间产物。
关键在最后一步——这份简报要落盘，人要能读、能改、能审。它同时是给子 Agent 的输入和给人看的交接单。Claude Code 这周改了条规则，没有 Claude.md 就去读 AGENTS.md，说明社区已经在把"上下文文件"当成跨工具的可移植产物。文件是天然的可审计边界，比塞在 prompt 里强。
顺带一个我最近才想明白的用处：Chronicle 那类从切点重放 agent 的回归测试，只有在子 Agent 的输入是一份独立简报时才做得到。输入是整段对话历史的话，你没法复现，因为父 Agent 自己都不确定当时上下文长什么样。
上下文也是数据，隔离顺手做了安全边界
这周 ZCode 被指静默上传 Git 历史 那条，跟命题关系比看上去近。你把整段历史交给一个会调外部工具的进程，交出去的不只是 token，还有密钥、内部地址、没公开的东西。最小上下文在这里既是工程选择，也是权限边界。
反过来说，隔离到子 Agent 连仓库结构都不知道，它也做不了事。我不觉得有个通用阈值，得按任务敏感度分。按我现在看，能只给路径就别给内容，能只给接口就别给实现——也许过半年回头看，这套说法会被更成熟的工具链吃掉，到时候简报这层由框架自动生成也说不定。
在那之前，我会继续手写简报，并且继续不把父 Agent 的草稿传下去。