聊聊 AI Agent 到底有多大创新？

目前各个大厂都相继推出了AI agent构建服务，类似于gpts，但是使用下来并没有感受到和10年前的task bot有很大的差别。甚至体验还更差。

给我带来这些主观感受的原因主要是

1，planing阶段带来了巨大的耗时，当tool变多后，turbo系列模型的准确率堪忧，因此不得不使用旗舰模型，这让延时进一步增加。

2，planing的质量不够高，原来的task bot做任务所使用的workflow是人工决定的，现在改成了模型自助决定，从目前的测试来看，由模型构建的复杂工作流的可用率远远不及人类水平。简单工作流使用判别式小模型反而性能更好。

3，reflection是一种时间换准确度的策略，然而这个策略非常容易重复进行自我内耗，和死循环。

这几个问题，确实是目前AI Agent技术的通病。如果把Agent当成"LLM+工具调用"的简单组合，没有认真处理工程细节，实际的效果也确实未必比工作流编排就更好。主要结合看到一些论文，和一点实际经验，按题主说到的三点谈一下自己的看法。

Planning慢的本质原因

这个问题的核心在于工具发现和参数对齐的成本被严重低估了。工作流的工具编排可以认为是编译时确定的，调用路径是硬编码的，现在agent改成运行时动态选择，将更多的自主权放给模型，模型需要理解几十上百个工具的语义和适用场景，同时把自然语言意图映射到正确的工具+参数组合，并处理工具间的依赖关系和执行顺序，这个过程本质上是个复杂的组合优化问题。

当工具数量从5个涨到50个，搜索空间是指数级膨胀的。弱推理模型在这种场景下准确率确实堪忧，但强推理模型又因为推理token长、串行链路多，延时就会拉的很高。针对这个问题，看到的一些思路是工具层缩小范围进行分层治理，同时做好执行子任务的并行化，有相关的方案可参考:

1.别让模型直接面对上百个工具，先用意图分类器把请求路由到具体域（比如"数据查询""文档处理""代码生成"），每个域只暴露5-10个核心工具，mas不同的子agent分配不同的工具列表也是这个思路。另外MCP很适合实施这个方案，每个server可以按分组域暴露不同的工具。

2.把串行改成DAG并行：很多工具调用其实没有强依赖关系。LLMCompiler支持把调用计划编译成有向无环图，OpenAI的agents SDK提供并行化与并发执行能力,可并行的节点同时执行。这个在自己项目上做过试验，对于调研搜索任务，对于不存在依赖关系的多个搜索工具调用，串行改为并行，整体链路耗时缩短20%。

3.将路由策略引入工程中：在项目开始节点增加一个路由，简单、标准化的子任务（比如格式转换、参数校验）直接路由给SLM或专用执行器，复杂的规划和异常处理才上强推理模型。RouteLLM和MoMA的论文都证明了路由设计方案的可行性，实践的关键在于任务难度的合理划分。

接下来看下Planning质量不高的问题

这个问题的的本质原因是模型生成的"文字描述计划"，对于现阶段的模型理解而言，还缺乏可执行性和全局约束。

传统workflow是人类用流程图或状态机设计的，有明确的分支条件、循环边界、异常处理和资源约束。模型自然语言生成的计划往往只是"先做A，再做B，最后做C"这种线性描述，遇到复杂场景就存在hold不住的可能。

虽然模型本身的长程推理能力也在提升，可以处理越来越复杂的问题，但现阶段哪怕用top强推理模型，在长程任务中成功率依然不高，整体上还比较脆弱，但也有相关的方案来提升agent复杂任务处理的成功率可参考。

1.HiPlan的思路：把计划拆成"里程碑+局部提示"两层。高层规划只管战略目标和依赖关系，低层执行器负责战术细节。这种解耦让规划更稳定，而且里程碑可以离线积累成库，下次遇到类似任务直接复用。

2.Routine的实践：提供结构化的计划框架（类似DSL），强制模型输出符合语法的计划，而不是自由文本，论文显示这能把企业场景的工具调用准确率提升平均20多个百分点。

3.搜索式规划：LATS把MCTS引入Agent，把"想-做-评"统一到树搜索框架里。遇到分支决策时不是一次性赌对，而是展开多条路径，用Verifier评分，选最优的继续。HyperTree和Graph-of-Thoughts进一步支持非树形的图结构。

4.多轮RL直接学策略：最近半年，基于强化学习的多轮训练成为非常有效的agent长程任务性能提升方案，有很多相关的研究，例如RAGEN、LMRL-Gym，经过RL训练，让agent在多轮任务的性能指标都实现明显提升。

再看看一下Reflection的死循环问题

Reflection容易自耗的根本原因是：缺少细粒度的可计算信号和明确的停机条件。

模型自己反思时，只能靠"我觉得这里不对"，这种信号太弱，而且容易陷入主观偏见，多轮之后不是在修正错误，而是在强化某个错误的假设。

这个问题看到有两篇论文在研究，分别从何时反馈和从失败中学习的角度来修复这个问题。

UFO（Unary Feedback as Observation）：只用"Try again"这种最简单的一元反馈做多轮RL。不需要详细的错误诊断，只要告诉模型"这次不行，再来一次"，就能通过RL学会自我改进。

Tool-Reflection-Bench（结构化反思）：将"从错误到修复"的过程变成一个明确的、可控的、可训练的动作。不是简单提示模型"多想想"，而是让模型学会：(1) 基于前一步的证据诊断错误，(2) 提出正确且可执行的后续调用。通过结合DAPO和GSPO的目标函数，以及针对工具调用定制的奖励机制，优化"反思→调用→完成"的分步策略。

上面提到的两个研究都需要做rl让模型学会正确理解失败，在工程层面的也有一些可参考方法：max_rounds（硬性上限）、no-progress-k（连续k轮没改进就停）、state-hash去重（检测状态重复就退出）、cost-budget（预算耗尽就终止）。AutoGen和Agents SDK都提供了可编程的终止钩子，这些也是生产环境的必需品。

从上面提到的各种方法可以看到，agent现阶段存在的问题，只从基础模型的通用推理能力和工程化优化都缺乏有效手段，比较可行的方向就是结合强化学习，构建多轮交互的特定环境，让模型从特定环境中学到稳定的agent推理和执行能力。端到端RL的思路是把整个Agent当成一个策略网络，直接从环境反馈学习，让模型自己涌现出规划、工具使用、反思等能力，这也是未来agent的技术发展趋势，从模块化逐渐走向端到端。

所以就agent本身的架构设计而言，确实不算多大的创新，但是基于llm驱动的agent同时降低了应用下限，提升了能力上限。现阶段agent使用存在的多种问题，会随着基于rl训练的agent模型能力提升逐步解决，但不会完全解决。工程化的生产业务架构设计仍然很重要，agent系统的记忆模块也需要工程化优化维护，还包括human in loop的持续推进优化，这些都不是靠模型能力提升能解决的。

也可以说AI agent是llm在现实场景业务落地最有价值的技术应用方向了，agent本身在逐步在内化为模型能力，而RL非常契合agent在各个垂直领域（逐步扩张到通用领域）现实环境各种问题的模拟复现，工具的高度封装化和运行环境的可迁移性（部分），让sim2real的难题没有成为掣肘，通过rl训练的agent模型具备很高的实用价值，并且价值在持续扩大，这应该算比较大的创新了吧。