解读下这个文章https://x.com/langchain_oss/status/2097372136247902519

这篇讲的是一个具体问题：主 Agent 派活时，子 Agent 应该从零开始，还是继承主 Agent 已经读过、讨论过的上下文？ LangChain 在 Deep Agents 中提供了两种模式：isolated 和 fork。核心不是“多开几个 Agent”，而是按任务关系决定怎么分配上下文。 先看一个例子 主 Agent 排查请求超时，已经读过几个文件、分析过日志，确定问题出在重试逻辑，现在要派一个子 Agent 修改并补测试。 isolated：子 Agent 只收到任务说明。如果主 Agent 没把证据交代清楚，它就得重新读文件、查日志，重复调查。 fork：子 Agent 继承主 Agent 的对话和当前状态，再收到“根据刚才确认的超时问题修改重试逻辑，并补回归测试”的新任务，可以接着已有调查往下做。 两者完成后，都只把最终结果返回主 Agent，子任务的中间过程不灌回主对话。 所以 fork 的意义是：向下继承上下文，向上仍然收敛结果。不是让所有 Agent 共享一个持续同步的聊天窗口。 为什么代码审查反而推荐 isolated？ 假设主 Agent 已经反复解释：“问题一定在重试逻辑，这个修改肯定能解决。” 如果审查 Agent 继承整段对话，就可能被这套判断带偏，顺着原来的思路确认，而不是独立检查。 因此，文章建议给 verifier 一份明确的审查任务、代码 diff 和必要材料，让它独立判断正确性、兼容性和测试覆盖。 注意，isolated 不是“不提供背景”，而是不继承整段前序对话。需求和验收标准仍然要交代，否则审查也没有依据。 文章给出的选择逻辑 执行者 worker：接着已经调查清楚的工作做，适合 fork，减少重新发现问题的成本。 审查者 verifier：需要独立判断，适合 isolated，减少被前面结论锚定的风险。 研究者 researcher：如果问题能独立描述，比如查某个库两个版本之间的 API 变化，适合 isolated，不必把主对话全塞过去。 记忆 Agent：任务本身就是提取对话里的偏好、决策和约束，适合 fork，因为整段对话就是它的分析材料。文章还强调，可以额外限制它能修改哪些文件。 fork 为什么可能更便宜？ 乍看继承整段历史会更贵，但文章的理由是：复用主 Agent 的对话，可以利用 prompt caching，同时省掉重复读文件和搜集信息的工具调用。 不过原文说的是“可能更快、更便宜”，不是保证。它没有提供量化 benchmark。 我的理解是：如果任务高度依赖之前的调查，继承上下文很划算；如果只是查一个独立问题，把长历史带过去就未必值得。缓存也不意味着历史免费，更不意味着无关内容不会干扰判断。 实现上具体做了什么？ 主 Agent 调用子 Agent 工具时，fork 模式会把当前状态和对话历史传过去，移除末尾那条派活工具调用，再把任务说明转换成新的用户消息，并加上角色说明。 子 Agent 执行结束后，它的最终消息作为原工具调用的结果返回主 Agent。 这里的 fork 指上下文分叉，不等于 Git 分支、独立 worktree，也不能据此认为文件系统和执行环境自动隔离。文章没有给出这种保证。 我认为最值得借鉴的一点 多 Agent 不应该统一采用“全部从零开始”，也不应该“全部继承完整历史”。 需要延续调查的任务，让它继承；需要独立判断的任务，让它隔离。 执行者需要知道“前面查到了什么”，审查者需要知道“要验收什么”，这两种上下文不是一回事。本文真正有价值的地方，就是把这个区别变成了可配置的机制。