AI Agent的真正瓶颈,99%的人都搞错了

   一、一个被严重低估的问题：什么是Harness？  

   聊Agent时，大家最爱问：“你家用的是什么模型？”GPT-4、Claude、Qwen，还是自研模型？但真正落地过Agent系统的人会告诉你——模型只是故事的一半。  

   另一半是什么？是把一个裸模型变成能干活儿的Agent，所需要的那整套“操作系统”：提示词怎么写、工具什么时候调用、记忆存哪里、失败怎么恢复、上下文如何拼接、安全边界怎么划、输出怎么验证……  

   这套系统，学术界和工程界把它叫做Harness（运行时框架）。  

   模型像“大脑”，Harness像“操作系统”。大脑再强，如果操作系统不给它正确的输入、工具和反馈，它也会频繁宕机。  

   举个现实中的例子：把同一个GPT-4模型放进两个不同的Agent框架里，一个可能表现得像个资深工程师助手，另一个却可能陷入无限工具调用循环，或者产出一堆格式错误的垃圾输出。差距从哪儿来？大部分来自Harness的设计差异。  

   传统做法里，这套Harness完全靠人手工搭建和调整。模型升级了，要改；工具换了，要改；任务变了，又要改。每一次修改都依赖工程师的经验和直觉，没人能准确预测一个改动会影响多少其他任务。这几乎是一种不可持续的工程负债。  

   HarnessX这篇论文的核心洞察就是一句话：不要只训练模型，也要让Agent的运行时自己进化。  

   二、把运行时拆成“积木”：组件化设计的第一步  

   HarnessX做的第一件事，是把整个Agent运行时拆解为一组类型化的Processor（处理器）。每个Processor只负责Agent生命周期中的某一小段行为。  

• 任务开始时，某个Processor可以调整系统提示词；
• 模型调用前，另一个Processor可以修改用户最后一条消息；
• 工具调用前，专门检查参数的Processor会介入；
• 工具返回后，改写处理器负责优化返回结果；
• 任务结束时，只读处理器负责读取结果，不能再修改任何状态。

   这种限制看起来很繁琐，但实际上极其关键。它让每一次修改都有了明确的边界：这次改的是提示词、工具调用、还是控制流逻辑？作用在哪个阶段？会不会跟已有组件发生冲突？这些问题不再靠经验和猜测来回答，而是由类型定义和Hook约束提前暴露出来。  

   这就好比把一块浑然一体的巨石，切割成了标准的乐高积木块——每块的功能和接口都一目了然，替换和组合变得安全且可控。  

   三、真正的创新：让Harness从失败中学习  

   能拆还不够。HarnessX真正让人眼前一亮的，是它能让这些“积木”根据真实执行轨迹自动调整。这部分由一个叫AEGIS的系统完成。  

   AEGIS不看简单的“成功/失败”标签，而是看完整的执行轨迹：模型看到了什么输入、思考了什么内容、调用了哪个工具、工具返回了什么结果、在哪一步走偏了、最终验证器给了什么评分。  

   这非常重要。因为一个任务失败，可能是模型推理错误，也可能是网页抓取返回了空内容，可能是工具参数格式不对，也可能是上下文裁剪把关键信息给丢了。只盯着一个最终分数看，根本不知道该改哪里。  

   AEGIS把演化过程拆成了四步清晰的动作：  

• Digester：把海量执行轨迹压缩成任务级别的失败原因摘要；
• Planner：判断哪些失败模式持续出现、哪些可能的改进方向还没被尝试过；
• Evolver：根据摘要和规划，生成候选的Harness修改；
• Critic+确定性门控：审核候选修改，决定是否允许它真正上线。

   这里有一个极其重要的设计原则：LLM可以负责提出想法，但不能自己决定什么能上线。真正决定一个改动能否发布的，是类型约束、回归测试、烟测和确定性门控这些硬规则。  

   线索即状态。编辑即动作。轨迹加评分即反馈。新版本即更新。这就是HarnessX所谓的"Operational Mirror"：在符号空间里把Harness演化映射成一种类似强化学习的优化过程。  

   四、结果太反直觉了：弱模型反而提升最大  

   论文在五类完全不同的任务上做了实验：GAIA（多步检索）、ALFWorld（具身规划）、WebShop（网页购物）、τ3-Bench（多轮客服对话）、SWE-bench Verified（软件工程）。  

   结果很直接：15个模型-基准组合中，14个获得了提升；平均绝对提升14.5%，最高提升达到44.0%。  

   但最让人意外的不是这个数字，而是谁受益最大。在ALFWorld任务上，Qwen3.5-9B这个基础能力不算强的模型，准确率从53.0%一下子飙升到97.0%，提升了整整44个百分点。而那些原本就更强的模型，提升反而相对有限。  

   这说明了一个隐藏很深的事实：很多弱模型不是“不会”，而是不知道该如何稳定地使用工具、拆解任务、控制步骤。给它们换一套更好的Harness，把任务变成更适合它们执行的形态，表现就会脱胎换骨。  

   这是一个对工程实践极具启发的发现：当一个小模型表现不佳时，第一反应不应该是“换更大的模型”。不妨先检查一下Harness——工具有没有充分暴露？上下文有没有组织好？任务有没有拆成它能驾驭的粒度？失败有没有被正确恢复？这些调整，成本远低于升级模型，但收益可能更高。  

   五、最危险的陷阱：单一Harness会自己退化  

   论文里最值得产品团队和工程管理者警惕的，不是那些漂亮提升数字，而是失败案例。  

   尤其是在GAIA这种高度异构的任务集上，单一全局Harness会出现明显的退化现象：早期几轮优化后表现提升，但继续优化下去就开始下降，最后甚至低于峰值很多。  

   原因很朴素：一个改动可能对检索类任务有好处，却同时伤害了视觉推理或表格处理任务。一个控制规则可能让客服对话更合规，却让代码生成任务变得笨重不堪。任务类型越多元，单一Harness就越容易陷入“左右互搏”的困境。  

   HarnessX给出的解法是变体隔离：同时维护多个Harness版本，把不同类型的任务路由给最适合它的那个版本。针对某一类任务的优化不会污染另一类任务。  

   未来Agent平台不应该只有一个“万能工作流”。更合理的产品形态是按任务类型、工具环境、风险等级和用户场景，动态选择不同的Harness变体。  

   六、再往前一步：Harness和模型一起进化  

   HarnessX还探索了一个更具前瞻性的方向：Harness-Model Co-evolution（运行时与模型共同演化）。  

   单独优化Harness迟早会遇到天花板：工具和流程已经打磨得足够好，剩下那些问题大概率是模型本身不太会推理。反过来，单独训练模型也有天花板：如果Harness从不暴露某些工具和上下文信息，模型也永远学不会如何利用它们。  

   论文的做法是共享一个轨迹缓冲区。每一轮Agent运行产生的完整轨迹，一边送给AEGIS用来改良Harness，另一边送给模型做强化学习训练。不同Harness版本在同一个任务上的成功策略，会自动变成模型的训练信号。  

   实验显示，这种共同演化比仅优化Harness又额外提升了大约4.7%。数字不算惊人，但方向极其重要：Agent的未来训练，很可能不是“只训模型”或者“只调Prompt”的二选一，而是让模型和运行时同时、持续地吸收真实任务中的经验。  

   七、这对企业Agent平台意味着什么？  

   把HarnessX的思路放到企业场景里，意义会更加清晰。企业Agent面对的不是某个单一的Benchmark，而是大量异构的实际流程：搜索、审批、代码编写、文档生成、会议纪要、邮件回复、客户支持、内部系统API调用……  

   这些任务不可能靠一个万能Prompt来解决，也不适合每次都靠工程师手工调整工作流。更合理的平台形态应该是：  

• 组件化：提示词、工具、记忆、控制流、安全策略全部可以独立替换；
• 可观测：每次失败都能追溯到具体的执行步骤和组件；
• 可演化：系统能根据真实轨迹提出结构性的修改建议，而不是只能微调提示词；
• 可治理：任何自动修改都必须有审计记录、回滚机制、回归测试和明确的人工审批边界。

   这种平台能力，未来可能会成为企业级Agent产品的分水岭。  

   八、冷静一下：这东西还不是银弹  

   当然，别急着把所有工程资源都砸进去。HarnessX并不是已经解决了Agent工程的所有问题，论文自己也坦诚承认了几个重要的局限性。  

   第一，实验主要是在同一任务集上做演化和评估，对全新任务的泛化能力还没有被充分证明。第二，系统严重依赖一个很强的元智能体——它需要能读懂复杂轨迹、编写代码、做规划、验证候选修改，这个门槛本身就很高。第三，确定性门控也不能捕捉所有的隐性退化，多个看似无害的小改动积累起来，仍然可能酿成大问题。  

   尤其是自动演化带来的治理风险，怎么强调都不过分。一个能修改自己提示词、工具调用和控制流的系统，本质上是在不断改变自己的行为边界。生产环境里，审计、回滚、权限分级和人工审批不是可选项，而是必选项。