Chunlin 的论文科普

AI 智能体的「上下文工作台」越堆越满，怎么办？——子代理模式为什么能扛住长任务

LLM 与智能体

你用 AI 助手做一个复杂项目——查资料、写代码、跑测试、改 bug。做到第 10 步时，它突然忘了第 3 步的结论，或者被前面的信息干扰犯了低级错。不是模型不够聪明，是它的「工作台」堆不下了。

长程任务里，智能体该怎么管理可复用的技能，才能既不被上下文压垮，又能稳定完成任务？最近一篇名为 Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks 的论文 [1] 系统对比了两种思路，结论比你想的更反直觉。

为什么长任务里 AI 会「越做越糊涂」

你可以把大模型的上下文窗口（context window）想象成一张工作台：所有正在处理的信息、之前的对话历史、技能说明书，都得摊在这张桌子上。桌子面积有限，东西堆得越多，找东西越慢，也越容易看错行。

短任务还好，三五步就结束了，桌子上还清爽。但长程任务不一样——要调用十几个技能、经历几十步推理，每一步的中间结果、错误日志、工具返回值都会留在工作台上。到了后期，模型要从几万字的历史里找出当前需要的那条信息，出错概率自然飙升。这就是所谓的「上下文过载」。

过去大家的思路是「把桌子做大点」——更长的上下文窗口、更好的注意力机制。但桌子再大，堆东西的速度总能超过扩容的速度。一个合理的猜测是，上下文越长，模型对中间信息的提取准确率反而越低，不是线性下降，而是中间部分掉得特别厉害。

另一条思路是「别什么都往主桌上堆」。既然有些技能是可复用的，能不能换一种方式用它们？目前主要有两种方向：一种是把技能说明书直接摊在主桌上，由主模型自己照着做；另一种是把每个技能拿到单独的小桌子上去做，做完只把结果拿回来 [1]。

这两种模式到底谁更能扛长任务？论文 [1] 做了一组非常扎实的对比实验。

两种技能用法：摊在主桌上 vs 拿到小桌子做

先把两个核心概念说清楚。

第一种叫 智能体技能（agent skill） 模式：当需要调用某个技能时，把技能的说明文档（比如一份 SKILL.md）直接加载进主智能体的上下文窗口，由主 LLM 自己照着说明书一步步执行。好处是简单直接，技能怎么写的、主模型就怎么看；坏处是每用一个技能，工作台上就多一摞说明书，越堆越乱 [1]。

第二种叫 子代理（subagent） 模式：调用技能时，不开主桌的说明书，而是新开一个独立的上下文窗口，用技能指令初始化一个「子代理」，让它在自己的小桌子上独立完成任务，做完之后只把最终结果返回给主代理。主桌上始终只放任务目标和子代理返回的结果，保持清爽 [1]。

听到这儿你可能会问：子代理拿到任务后，不会理解错吗？主代理怎么知道该给它传什么参数、它又会返回什么东西？

这就是关键设计：输入输出契约（input-output contract）。论文把每个技能包结构化地拆成三部分：用途摘要（这个技能是干什么的）、输入契约（调用时需要提供哪些信息）、输出契约（执行完会返回什么格式的结果）[1]。

你可以把它类比成编程里的函数调用：你不用知道函数内部怎么实现的，只要知道传什么参数、返回什么值，就能放心调用。子代理模式本质上就是把「技能」从一段需要主模型逐行阅读的说明书，变成了一个有明确接口的黑盒函数 [1]。

当然，实际情况比这个比喻更复杂——函数的内部逻辑是确定的，而子代理本身还是 LLM，它也会犯错。但契约的存在，把「主模型要同时理解任务+理解技能+执行技能」的三重负担，简化成了「主模型只需要理解任务、正确调用技能接口」。

为了公平对比，研究者基于 OpenHands 代理框架，用同一份技能包分别在两种模式下测试，唯一的区别就是执行方式 [1]。

什么时候子代理模式更能打？——实验证据告诉你

论文的核心结论可以用一句话概括：子代理模式好不好用，完全取决于技能包有没有明确的契约和程序化的步骤 [1]。

先看正面情况。当技能包是「程序化 + 明确 I/O 契约」的时候，子代理模式全面占优：

但反过来，如果技能包是人工编写的、没有明确契约的松散描述，子代理模式反而不如直接加载技能 [1]。原因也很好理解：接口都没说清楚，主代理不知道该传什么、子代理也不知道该返回什么，两边猜来猜去，错误率反而更高。

还有一个必须正视的代价：子代理模式的总 token 消耗显著更高 [1]。因为主代理和子代理之间需要通信——描述任务、传递输入、返回结果，这些都要额外花 token。相当于你把活分给小桌子做，得来回跑腿传话，通信成本是跑不掉的。

另外一个有趣的发现是：子代理模式下，每个任务的平均技能调用次数反而更多 [1]。一个合理的猜测是，主代理因为上下文清爽、不容易混乱，反而更愿意频繁调用技能，而不是硬着头皮自己瞎试。

所以结论的边界非常清晰：子代理不是万能的银弹，它的优势成立有严格前提——技能得是程序化的、有明确输入输出契约的，而且任务得是长周期、上下文容易膨胀的场景 [1]。

从「单一大脑」到「分工协作」：智能体架构的演进之路

子代理模式不是凭空冒出来的，它其实是智能体架构从「单一大脑」走向「分工协作」这条路上的又一步。

最早的智能体是「全栈式」的——规划、执行、记忆全在一个 LLM 上下文里完成。很快大家就发现效率太低，于是有了第一波「解耦」思路：把智能体的创建阶段和执行阶段分开。比如 LLD-Agent 平台就提出，先用 LLM 把工作流规划好、写成 App Script 存下来，执行阶段就不用每次都重新规划和选工具了，运行效率显著提升 [6]。

解耦之后，下一步自然是模块化。既然能力可以拆开，那每个模块能不能有标准化的接口？AgentForge 框架就把技能抽象成了带正式输入输出契约的模块，技能之间可以通过有向无环图（DAG，即一个没有循环路径的任务依赖图）组合，开发时间比 LangChain 减少 62%，编排延迟还不到 100 毫秒 [7]。这其实已经为子代理模式铺好了路——当每个技能都有明确契约时，把它放在本地执行还是作为独立子代理调用，只是部署方式的区别。

再往前走一步，就是递归分解。既然一个任务可以拆成几个子任务交给子代理，子任务能不能继续拆？ROMA 框架就是这么做的：它用 Atomizer（雾化器）角色判断任务要不要继续分解，Planner（规划者）规划、Executor（执行者）执行、Aggregator（聚合者）聚合结果，形成一棵递归的子任务树，既能并行执行，又能通过聚合控制上下文增长 [8]。

你可以看到一条清晰的脉络：从「什么都塞在一个上下文里」，到「创建和执行分开」，到「模块化技能 + 标准化契约」，再到「递归分解的子代理树」——核心思路都是一句话：别让一个大脑干所有事 [1][6][7][8]。

子代理不是万能药：还有哪些问题没解决

说了这么多子代理的好处，得老实讲清楚它目前的局限。论文作者自己也承认了好几个开放问题 [1]。

第一个最直接：通信开销怎么降。子代理模式总 token 更高，这是实打实的成本问题。主代理和子代理之间怎么高效沟通？能不能用更精简的格式传递信息？能不能让子代理返回结构化结果而不是大段自然语言？这些都还没定论 [1]。

第二个问题：技能库怎么组织。当技能只有十几个的时候，平铺就行；但如果有几百上千个技能，怎么分类、怎么索引、怎么让主代理快速找到正确的技能？论文只初步探索了层级结构，发现「路由节点用 agent skill、叶子节点用子代理」的混合模式效果最好 [1]。但更深的层级有没有用？几千个技能的规模下组织方式会不会变？都还不知道。

第三个问题：更深的层级有没有收益。论文里没观察到更深层级带来进一步提升，但作者也说，可能是因为当前技能库还不够大 [1]。等技能库规模上去了，更深的递归分解也许才能体现出优势。

最后还有一个很实际的问题：现在效果最好的其实是混合模式——不是全用子代理，也不是全用 agent skill，而是根据技能的特点灵活选择 [1]。边界清晰、程序化的技能用子代理；松散的、需要和主上下文深度交互的知识型技能，还是直接加载更好。怎么自动判断一个技能该用哪种模式？这也是未来要解决的问题。

如果你只记住一件事

当技能有明确的输入输出契约时，把任务「外包」给独立上下文的子代理，比把所有技能说明书都摊在主桌上更能扛长程任务的上下文过载。

参考文献

  1. Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks（arXiv、2026、全文精读）
  2. The Failure Happens Before the Drift: The Social Dynamics of Values in LLM Agent Societies（arXiv、2026、全文精读）
  3. When Do Large Language Models Exhibit Unsolicited Deception?（arXiv、2026、全文精读）
  4. OpenDiscoveryTrace: Process Traces for Evaluating AI Scientist Workflows（arXiv、2026、全文精读）
  5. Beyond Accuracy: ARIA-Rubrics for Evaluating Audio Reasoning in Large Audio Language Models（arXiv、2026、全文精读）
  6. LLD-Agent: Enhance the runtime efficiency of agents with decoupling the execution phase from the creation phase（2025、仅摘要）
  7. A Lightweight Modular Framework for Constructing Autonomous Agents Driven by Large Language Models: Design, Implementation, and Applications in AgentForge（ArXiv.org、2026、仅摘要）
  8. ROMA: Recursive Open Meta-Agent Framework for Long-Horizon Multi-Agent Systems（arXiv (Cornell University)、2026、仅摘要）