AI 智能体做长任务总翻车？问题可能不在模型，而在「技能怎么装」
你有没有过这种体验：让 AI 助手做个多步骤的复杂任务，开头还好好的，越到后面越健忘、越混乱——是模型不够聪明，还是我们把太多东西都塞给它了？
很多人第一反应是换更大的模型、开更长的上下文窗口。但最近的研究发现，长任务里智能体”越做越糊涂”，很多时候锅不在模型本身，而在我们给它装技能的方式。智能体要做好长周期任务，可复用的知识技能到底应该「堆在主上下文里自己翻」，还是「封装成独立子代理去执行」？这两种模式的选择，正在成为长周期智能体性能的关键分水岭。
为什么长任务里的智能体容易「越做越糊涂」？
想象你在一张桌子上做项目：一开始只有任务说明，桌面清爽，思路清晰；做到第十步，桌上摊满了说明书、中间草稿、工具手册、聊天记录，你想找个参数得翻半天，还经常把之前的结论记错。
AI 智能体的上下文窗口就是这张桌子。任务越长、步骤越多，上下文里塞的东西就越杂：系统提示、历史对话、工具描述、中间结果、技能说明……每多一样东西，模型准确找到关键信息的概率就下降一分。这不是模型”笨”，而是信息过载下的自然现象。
一个很反直觉的佐证来自数据库代理领域的研究：在对 40 个模型、8199 次运行的统计中，小模型做数据库任务失败的原因里，真正”不会调用工具”的能力类失败只占 17.3%，而调用了工具却因为接口传输问题没拿到结果的”传输失败”占了 36.2% [3]。很多时候模型思路是对的，只是被混乱的接口契约、错位的字段名给绊住了——就像你明明会做题，却因为答题卡格式太绕填错了位置。
这给了我们一个重要启发：长任务的性能瓶颈，可能不全在模型的推理能力，而在于知识和技能怎么组织、怎么交付给模型。
两种技能用法：「摊开说明书」 vs 「找个帮手单独干」
目前给智能体装可复用技能，主要有两种思路。
第一种叫 agent skill（智能体技能），就是把技能说明书直接摊在主工作台上。调用技能时，把技能的指令文件、脚本、资源一股脑加载进主代理的上下文窗口，让主代理自己照着说明书一步步做。好处是简单直接，不用额外协调；坏处是每用一个技能，桌子上就多一摞材料，越堆越乱。
第二种叫 subagent（子代理），相当于给每个技能配一个独立帮手。调用技能时，不开新的说明书堆在主桌上，而是把任务交给一个专门干这件事的小助手——小助手有自己的小桌子、自己的说明书，干完之后只把最终结果递回主桌。主桌始终保持清爽，不用管中间细节。
你大概已经看出来了：这就像编程里的两种风格——一种是把所有函数体都内联写在主流程里，代码越写越长；另一种是把功能封装成函数，主流程只负责调用。当然，实际情况比这个比喻更复杂，因为智能体的”函数调用”不是精确的程序跳转，而是靠自然语言协调的。
哪种更好？答案没那么简单，它取决于一个关键条件。
子代理什么时候更好？关键在「输入输出契约」
核心论文《Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks》给出了一个清晰的结论：子代理模式优于直接加载技能的前提，是技能包必须有明确的输入输出契约 [1]。
什么是”输入输出契约”？简单说就是技能包得写得像一个正经函数：明确告诉调用者「你得给我什么输入」「我会返回什么输出」「什么时候可以调用我」，至于内部具体怎么干，调用者不用管 [1]。这就像你找帮手干活，得先讲清楚”你帮我把这堆数据整理成表格返回给我”，而不是扔给他一本手册说”你自己看着办”。
为什么契约这么重要？因为子代理模式的核心优势是”上下文隔离”——主代理不用知道技能内部的细节，只需要传输入、收结果。但如果技能本身没有清晰的边界，输入输出含糊不清，子代理干完的东西主代理接不住、用不好，隔离反而成了信息损失。
反过来，只要契约明确，子代理的优势就会随着任务变长、上下文变挤而越来越明显。这也和模块化设计的直觉一致：AgentForge 这类模块化智能体框架，早就把”带正式输入输出契约的可组合技能抽象”作为核心设计，用有向无环图（DAG，一种由节点和有向边组成、不存在闭环的结构，用来表示任务之间的先后依赖关系）组织技能组合 [7]。子代理模式，可以看作是这种模块化思想在运行时的自然延伸。
证据怎么来的：64 个任务、多模型对照的实测结果
这个结论不是拍脑袋想出来的，而是基于 OpenHands 代理框架、在 SkillsBench 基准上实打实测出来的 [1]。
实验的基本设计很严谨：同一份技能包，用两种方式各跑一遍，对比效果。研究者先从 87 个长周期任务里，用成功轨迹合成了 64 个带明确契约的程序化技能包，然后在多个模型上做了对照测试 [1]。
最有意思的是结果反转：用原始的、没有明确契约的人工技能包时，直接加载（agent skill）模式在所有测试模型上都持平或优于子代理；但一旦换成带契约的程序化技能包，趋势立刻反转——子代理模式全面胜出，而且模型越小、上下文带宽越受限，提升幅度越大 [1]。
另一个关键测试是上下文压力测试。研究者往环境里不断加入没用的干扰工具描述，从 0 个加到 263 个，模拟上下文越来越拥挤的情况。结果是：直接加载技能的模式，准确率随着干扰增加掉得很快；而子代理模式因为技能藏在自己的小窗口里，受干扰小得多，下降曲线平缓很多 [1]。这就好比你工作时把无关的浏览器标签页都关掉，只留当前任务需要的，效率自然更高。
当然，子代理不是没有代价。论文也明确指出：子代理模式的总 token 消耗显著更高，因为主代理和子代理之间要通信、要传输入输出，这些都要额外花 token [1]。它换来的是更短的峰值上下文——在强模型上，超过 80% 的任务用子代理时峰值上下文更短 [1]。简单说就是：总花费更高，但主流程的脑子更清醒。
还有一个有趣的发现：子代理模式下，每个任务的平均技能调用次数反而更多。作者推测，直接加载模式下上下文变长后，模型会”懒得思考”、更少主动调用技能；而子代理模式因为主上下文清爽，模型反而更愿意用技能 [1]。
别只怪模型笨：接口和契约才是隐形大坑
说到契约设计的重要性，数据库代理那篇论文提供了一个非常生动的注脚。
在那项研究里，传输失败的具体原因千奇百怪：有的模型把完整的工具调用写在了聊天文本里而不是工具调用通道，JSON 格式有点瑕疵就直接被判零分；有的值全对但放错了字段名，比如把 statement 放到了 change 字段、把 rationale 叫成了 reason；还有的更离谱——一个工具要求必须带 presentation 字段，它的兄弟工具却禁止这个字段还提示”删掉它”，模型明明凑齐了完整答案，却被两头堵死 [3]。
这些问题看起来像是”模型不够聪明”，但本质上都是工具契约设计得烂。字段名不统一、兄弟工具互相矛盾、错误提示模糊——这些都是工程问题，不是模型推理能力的问题。研究者做了 5 项纯服务器端的修复，不改模型、不改提示、不改采样，6 个模型的通过单元格数就提升了 6 到 21 个（满分 30），有的模型直接从 0/30 蹦到了 21/30 [3]。
这和子代理论文的结论形成了漂亮的呼应：技能/工具的接口契约质量，对智能体表现的影响，可能比模型本身还大。很多时候你以为是模型笨，其实是你给它的工具接口设计得太坑。
从单技能到技能库：记忆组织也在跟着进化
如果只有一两个技能，平铺直叙也够用。但当技能库里有几十个、上百个技能的时候，怎么组织它们本身就成了新问题——这已经不是单个技能的契约设计了，而是整个技能库的结构设计。
子代理论文里也做了初步探索：在 Qwen3.5-9B 模型上，层级化的技能库（尤其是图结构和按任务分的两层树）比扁平库效果更好；而混合执行模式——路由节点用直接加载，叶子技能用子代理——效果始终最优 [1]。这说明技能库不是越扁平越好，也不是全都塞给子代理就完事，而是需要根据技能的抽象层级灵活选择执行方式。
多智能体记忆的研究也指向了同一个方向。MACE 框架提出的 MemGoG”图中图”结构，把协作经验拆成一个个”功能记忆单元”（每个单元是包含条件、动作、输出的子图），单元之间再通过支持、冲突、修复等关系连接起来 [2]。这种结构既保留了每个单元内部的依赖关系，又支持跨经验的关联检索——就像把经验整理成带目录的工具箱，每个工具自己带使用说明，工具之间还标了”搭配用""别一起用""坏了用这个修”的标签 [2]。
更有意思的是 MACE 的一个反直觉发现：同样的记忆内容，给智能体看”操作指南”时，只取相关单元效果更好；但换成”检查清单”时，多取一些支持单元反而效果更好 [2]。记忆好不好用，居然和”怎么呈现给智能体”强相关，不能分开评价。这也从另一个角度说明：知识的组织方式和交付方式，本身就是性能的关键变量。
这条路从哪来：智能体从「全栈式」到「模块化」的演变
子代理模式不是凭空冒出来的，它是整个智能体领域从”全栈式”向”模块化""分治式”演进的一环。
早期的智能体基本是”一个大模型包打天下”——规划、执行、反思全在同一个上下文里完成。很快大家就发现这种方式又慢又不稳定，于是开始拆。
先是创建与执行解耦：LLD-Agent 提出把智能体的构建阶段和运行阶段分开，用 App Script 预先定义好工作流并持久化，执行阶段就不用反复让大模型做规划和工具选择，大幅提升了运行效率和确定性 [6]。这相当于先把菜谱写死，炒菜的时候就不用一边想一边做了。
然后是模块化技能组合：AgentForge 这类框架把技能做成可组合的模块，每个模块有正式的输入输出契约，用 DAG 组织起来，开发时间比 LangChain 减少 62%，编排延迟不到 100 毫秒 [7]。这相当于把常用菜做成预制菜，需要的时候直接组合，不用从零切菜。
再进一步就是递归分解长任务：ROMA 框架把目标递归拆成带依赖关系的子任务树，可以并行执行，再把中间结果压缩聚合回来，控制上下文增长 [8]。这就像项目经理把大项目拆成小任务，分给不同的人做，最后自己只汇总结果。
子代理模式，就是这条演进路径上的最新一步：不仅任务要拆，连技能的执行上下文也要隔离。从”一个大脑干所有事”到”分层分模块协作”，智能体的架构正在越来越像人类的组织方式。
还没解决的问题：开销、库规模与边界
当然，子代理模式远不是银弹。论文自己也坦承了不少局限和开放问题 [1]。
首先是通信开销。子代理要传输入、传输出，还要做协调，这些都要额外花 token。总 token 消耗显著高于直接加载模式，这在大规模部署时是实打实的成本问题。怎么设计更高效的通信协议、能不能让子代理用更小的专用模型，都是还没解决的问题 [1]。
其次是技能库的规模问题。现在的实验只有 64 个技能，层级化的优势已经显现，但如果技能库涨到几百上千个，怎么组织、怎么检索、怎么动态重构，都还是未知数。更深层级、更大规模的技能库效果如何，目前没有验证 [1]。MACE 的记忆进化机制虽然提供了一些思路，但它的实验也主要在基准测试上，缺少真实部署中长期进化的验证 [2]。
第三个问题是松散知识怎么办。子代理模式只对有明确契约的程序化技能有效，如果是松散的、描述性的知识，比如行业背景、最佳实践笔记，反而直接加载效果更好 [1]。现实中的技能库往往是混合的，既有明确的操作流程，也有模糊的经验知识，怎么处理这种混合场景，还需要更多研究。
最后，现有结论的适用边界也需要注意：实验只在 SkillsBench 这一个基准上做，领域覆盖有限；层级化库的实验只在一个模型上跑了；所有实验都用同一套 LLM 同时做主代理和子代理，没有探索异构模型组合的成本收益 [1]。这些都是未来需要填补的空白。
如果你只记住一件事
长任务里智能体”越做越糊涂”，很多时候不是模型不够强，而是我们把所有东西都塞进了同一个上下文窗口。技能是直接摊开在主工作台上，还是封装成带明确契约的子代理单独干，取决于你的场景：当技能有清晰的输入输出边界、任务足够长、上下文压力足够大时，子代理的隔离优势就会盖过它的通信开销；反过来，技能边界模糊、任务短时，直接加载更划算。
参考文献
- Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks（arXiv (Cornell University)、2026、全文精读）
- MACE: Memory-Agent Co-Evolution with Adaptive Memory Graphs for Multi-Agent Systems（arXiv、2026、全文精读）
- What Stops a Small Language Model From Driving a Database Agent（arXiv、2026、全文精读）
- From Agent-Based Models to LLM-Based Financial Agents: A PRISMA-Based Systematic Review, Multidimensional Taxonomy, and Future Research Agenda（SSRN、2026、仅摘要）
- AI Agents and Minds（SSRN、2026、仅摘要）
- LLD-Agent: Enhance the runtime efficiency of agents with decoupling the execution phase from the creation phase（2025、仅摘要）
- A Lightweight Modular Framework for Constructing Autonomous Agents Driven by Large Language Models: Design, Implementation, and Applications in AgentForge（ArXiv.org、2026、仅摘要）
- ROMA: Recursive Open Meta-Agent Framework for Long-Horizon Multi-Agent Systems（arXiv (Cornell University)、2026、仅摘要）