子代理拆分任务为什么要用上下文隔离保护 Agent 的思路清晰很多人第一次看到子代理注意力会先落在“一个 Agent 还能再叫出另一个 Agent”这件事上。这个现象当然有意思但如果只停在这里很容易错过s04真正想解决的问题。真正的问题是:主 Agent 一旦做长任务上下文会越来越臃肿思路也会越来越容易被中间过程带偏。读几个文件、跑几次命令、试几轮编辑这些动作本身没问题。问题在于它们都会变成对话历史的一部分。时间一长主 Agent 不但要记住任务目标还要背着一大堆探索痕迹继续往前走负担会越来越重。agents/s04_subagent.py给出的办法很直接:把容易产生大量中间过程的子任务拆到一个全新的上下文里去做主 Agent 只接收最后的结果摘要。这就是这篇文章想讲清楚的重点。链接 s04_subagent.py先说结论s04最值得学的不是多了一个task工具而是下面这句话:上下文隔离不是为了炫技而是为了保护模型的思路清晰度。如果说s03解决的是“任务一复杂怎么别丢计划”那s04更像是在解决:当某个子任务会制造很多噪音时怎么别让这些噪音继续污染主线思考为什么主 Agent 越做越容易乱只要 Agent 开始持续调用工具这种问题几乎一定会出现。第一探索过程天然很啰嗦。找测试框架这件事最后答案可能只是“项目在用pytest”。但模型为了得出这个结论可能会读README.md、扫目录、打开多个py文件、再跑一条 shell 命令。真正有价值的结论只有一句中间痕迹却可能有十几段。第二主 Agent 不一定需要知道全部细节。如果一个子任务只是“帮我摸清情况”那主 Agent 往往只需要拿到结论再决定下一步怎么做。把全部中间过程塞回主上下文很多时候是在增加负担而不是增加能力。第三长上下文会让模型越来越像“边翻聊天记录边工作”。上下文越长模型越容易被最近的工具结果吸住注意力。它不是突然不会做了而是更难始终抓住主线。所以s04的核心思路不是“多开一个助手”而是把探索过程和主线决策拆开。task真正带来的不只是一个新工具表面上看父 Agent 比前一个版本多了一个task工具:PARENT_TOOLSCHILD_TOOLS[{name:task,description:Spawn a subagent with fresh context. It shares the filesystem but not conversation history.,input_schema:{type:object,properties:{prompt:{type:string},description:{type:string}},required:[prompt]}},]但这一行背后其实同时发生了三件事:父 Agent 多了一个“委派子任务”的动作。子 Agent 拿到的是全新消息上下文不继承父 Agent 的对话历史。子 Agent 干完活后只把摘要带回父 Agent而不是把整段工作记录原样带回。也就是说task的价值不在“能不能调用”而在它重新定义了信息流。整体结构图先看整体关系会比较容易抓住重点:直接调用基础工具task prompt读文件 / 改文件 / 跑命令返回结果摘要最终回答用户请求父 Agent 主循环共享工作区子 Agent 循环这张图里最关键的地方有两个。父 Agent 和子 Agent 共享同一个工作区所以它们看到的是同一批文件。父 Agent 和子 Agent 不共享消息历史所以子任务内部的探索过程不会回流到主上下文。这也是s04最有意思的地方:共享外部环境隔离内部思路。哪些东西共享哪些东西隔离很多人会把“子代理”想成一个完全独立的新系统其实这里更准确的理解是: 它像是给任务临时开了一个干净的工作脑区。项目父 Agent子 Agent含义会话历史保留完整主线从一条任务提示开始子任务不会继承主对话包袱工作目录共享共享两边都能读写同一批文件工具集合基础工具 task只有基础工具防止无限套娃返回内容继续主线决策输出摘要只把压缩后的结果带回去这一点非常像团队协作中的分工方式:主负责人保留整体目标和当前进度被委派的人拿到一个清晰任务自行探索最后回来汇报结论而不是把所有过程录音都交上来子 Agent 是怎么“新开一个脑子”的run_subagent()这段实现非常关键因为它把“上下文隔离”这件事写得很直白:defrun_subagent(prompt:str)-str:sub_messages[{role:user,content:prompt}]for_inrange(30):responseclient.messages.create(modelMODEL,systemSUBAGENT_SYSTEM,messagessub_messages,toolsCHILD_TOOLS,max_tokens8000,)这里最重要的不是for _ in range(30)这个循环而是这一句:sub_messages[{role:user,content:prompt}]它的意思很明确:子 Agent 没有继承父 Agent 的聊天记录子 Agent 只拿到一条任务说明子 Agent 从自己的局部上下文开始思考和调用工具这就是“上下文隔离”的真实落点。它不是抽象口号而是直接把消息历史重置为一条新任务。它不是并发更像是同步委派s04还有一个很容易被忽略的点: 这里的子代理并不是并发运行的它本质上还是主程序里的一次同步调用。关键逻辑就在这里:ifblock.nametask:outputrun_subagent(block.input[prompt])也就是说父 Agent 一旦决定委派就会立刻进入run_subagent()。子 Agent 在自己的循环里把事情做完返回摘要之后父 Agent 再继续。所以这个例子强调的重点不是“并行提速”而是“隔离思路”。这也是为什么我觉得它特别值得学: 它提醒我们子代理首先是一种上下文管理手段其次才是协作手段。一次委派到底是怎么流转的把这段流程画成时序图会更容易看懂:共享工作区子 AgentPython Harness父 Agent用户共享工作区子 AgentPython Harness父 Agent用户loop[子 Agent 内部循环]提出任务task(prompt...)新建 sub_messages读文件 / 跑命令 / 改文件工具结果返回总结文本tool_result(summary)继续主线回答从这个时序里可以看出父 Agent 眼里看到的其实只有两件事:我发起了一次task我收到了一段tool_result至于子 Agent 中间读了几个文件、试了几轮命令、有没有走弯路这些过程都被封装在子上下文里了。为什么最后只返回摘要run_subagent()结尾这段代码几乎就是s04的灵魂:return.join(b.textforbinresponse.contentifhasattr(b,text))or(no summary)这段实现说明了一件很重要的事:子 Agent 的输出不是完整历史而是最后一轮文本结果。这样设计有三个直接好处。第一主上下文更干净。父 Agent 不需要反复咀嚼子任务里的试探过程只需要接住结论继续往前走。第二信息密度更高。原本几十段中间记录最后被压缩成几句有用结论主 Agent 的注意力更容易留在关键点上。第三委派边界更清晰。父 Agent 决定“做什么”子 Agent 负责“怎么摸清楚”返回时再把“摸清楚了什么”交回来。当然这也意味着它不是万能方案。如果主 Agent 后面必须依赖子任务的完整推理轨迹或者要审计子任务的每一步那只返回摘要就不够了。换句话说s04适合的是可以被压缩成结论的子任务。为什么子 Agent 不继续拥有task代码里专门把父子工具做了区分:父 Agent 有task子 Agent 没有task这个限制很克制但很合理。如果子 Agent 也继续拥有task那它就可以再叫出新的子 Agent系统很快就会变成无限套娃。教学示例里先把层级收住只保留“一层委派”更方便把核心问题讲透。这也能看出s04的设计态度: 先把信息边界做稳再谈更复杂的协作拓扑。它和s03的关系正好是两个方向我很喜欢把s03和s04放在一起看因为它们解决的是两种完全不同的失控风险。s03处理的是“任务很多时模型容易忘记做到哪了”s04处理的是“探索很多时主上下文容易越来越脏”前者是在补“进度管理”后者是在补“上下文管理”。换句话说:s03让 Agent 更会盯住计划s04让 Agent 更会保护主线思考这两个能力一前一后接起来整个系统就开始有点像真正能长期工作的智能体了。什么样的任务适合交给子 Agent从这份实现出发我觉得下面几类任务尤其适合拆出去:需要读很多文件才能得出一句结论的任务带有明显探索性质、可能会走几轮弯路的任务只需要返回摘要不需要完整过程回放的任务主 Agent 当前只想保留决策主线不想被细节淹没的任务反过来说如果任务本身非常短或者主 Agent 后续必须直接依赖中间细节那就没必要硬拆。子代理不是默认更高级而是在“上下文已经开始变脏”的时候提供了一种很实用的减负方式。最后总结s04_subagent.py看起来是在讲“怎么让 Agent 调用子 Agent”但我觉得更本质的主题其实是:当一个系统开始变复杂时光让它会做事还不够还要学会把不同层次的思考隔离开。父 Agent 保留主线子 Agent 负责探索两边共享工作区但不共享整段对话历史子任务做完之后只把压缩后的结论带回来。这套设计不花哨却非常像真实工程里的经验:不是所有细节都应该进入主决策面能局部消化的信息就尽量局部消化。这也是我理解s04时最有价值的一点:子代理的价值不只是“多一个帮手”更是“给主 Agent 留出一块干净的思考空间”。致谢学习主线参考并受益于shareAI-lab/learn-claude-code