我之前一直觉得，做Agent这事，无非就是搭个loop，把function call接上，让模型一边推理一边调工具，跑就完了。

模型那么聪明，剩下的它自己处理就行了吧。

直到前段时间，我自己手搓了一个agent。

特别朴素的设计，给模型配几个工具，让它去做一个具体任务。我满怀期待按下回车。

结果跑出来什么样呢？

模型咔咔写了一个function call，工具返回了结果，它瞄了一眼结果，然后。。。就结束了。

任务根本没做完。中间各种小错误它也不处理，遇到一个看不懂的报错就当没看见，继续往下走。最后给我交付了一坨四不像。

我盯着terminal懵了好一会儿。

这跟我平时用Claude Code、用Codex的时候那种「它在认真干活」的感觉，完全是两回事啊。

一样是LLM，一样是工具调用，差距怎么能这么大？

我就很想搞明白一件事，那些做出来好用的Agent，背后到底做对了什么。

于是我去翻了一堆Agent的源码，又把这两年的相关论文挨个读了一遍。还跟AI来回讨论了好几轮，最后归纳出来评价一个Agent的三个核心维度，也是现在主流agent benchmark在用的核心指标。

我先把这三个维度直接放在这。

讲实话，我第一眼看到这三个维度的时候，是有点震惊的。

我本来以为评价Agent，会是那种很「机器人」的指标，比如任务完成率、token消耗速度、学习速度、推理延迟、tokens per second。

结果一看，根本不是。

是这三个东西。

第一个，零干预任务闭环率（Zero-Shot Autonomous Completion Rate）。

学术上的定义是，在长序列决策中维持目标一致性、收敛至终止状态的宏观能力。

翻译成人话就是，你交给它一个活，它能不能从头到尾把它干完，中间不忘记自己在做啥，最后给你交付一个能看的东西。

你想想这不就是你管一个新人时最常焦虑的事？这小子接到活，能不能干完，会不会干一半就不知道该做啥，会不会跑过来一脸茫然问你「然后呢」？

第二个，异常纠偏与系统韧性（Error Recovery Efficacy & System Resilience）。

学术上的定义是，跳出退化循环、动态重规划的微观认知能力。

翻译成人话，就是出错了能不能爬起来。命令打错、文件找不到、API超时，这些事agent干活的时候每天都在发生。问题是出错之后它怎么办，是傻乎乎接着错下去，还是知道这地方不对，换个路子再试。

这不就是你看一个新人成不成熟最关键的指标？踩坑了能不能自己爬起来，还是一遇到问题就只会过来找你救场？

第三个，动作信噪比与轨迹效率（Action SNR & Trajectory Efficiency）。

学术上的定义是，在受限上下文窗口下最大化推进任务的有效操作占比。

翻译成人话，就是说话效率高不高，干活有没有废动作。模型上下文就那么大，每一句话、每一个工具结果、每一个错误信息，都在抢这个空间。设计得好的Agent，每一个token都用在刀刃上。设计得拉的，跑着跑着就把上下文撑爆了，然后疯狂失忆。

这又跟你看一个员工的成熟度一样吧？同样一个活，有的人三句话讲清楚就开干，有的人废话十分钟还在拉会拉群确认，最后效果还差。

我盯着这三个维度看了半天。

这帮做Agent的人，做的根本不是什么神秘的科技工程。他们做的是HR的活儿。

而且管的还是同一个员工，因为底层的模型就是Claude、就是GPT。AI公司发给我们的是「员工」，做Agent的事情，是教这个员工怎么把活干漂亮。

这个视角一旦切过来，后面学术圈所有的论文，读起来都顺了。

接着说这三道题的另一个骚的地方，它们是互相打架的。

你想让员工别提前撂挑子，那就告诉他「干完为止」。结果他真就一根筋干到底，遇到什么问题都不停，把事情搞得一团糟。

你想让员工韧性强，遇到错误就重试。结果他陷入死循环，对着同一个错误磕了五十遍。

你想让员工汇报简洁，砍掉所有不必要的废话。结果关键信息也没传到，老板彻底懵逼，刚才在干啥来着？

所以做Agent这事，从来不是「哪个维度做到极致就赢了」，是「怎么在这个三角里找到一个不那么糟的平衡」。

下面我们一道题一道题来看，学术圈给了什么答案。

先看第一道题，闭环率。

学术圈最早的一条线，是2022年Yao他们提的ReAct（《ReAct: Synergizing Reasoning and Acting in Language Models》）。思路特别朴素，让模型每一步都先想一下再动手，Reason一下，Act一下，交错来。

听着很对吧。但ReAct很快就遇到一个让人头大的问题，叫「漂移」。

模型每走一步，都倾向于觉得「我已经做了不少了，差不多可以停了吧」。一个十步的任务，它可能走到第四步就开始发自内心地觉得自己干完了。

我自己手搓那个agent的失败，本质就是死在这上面。

所以学术圈又出了第二条线，Plan-and-Execute（Wang 2023他们一系列工作）。先让模型生成一个完整的计划，再分步执行。计划是个外部对象，每一步都对着计划走，不让模型自己瞎判断进度。

到了2023年又出来一篇特别有意思的，《Voyager: An Open-Ended Embodied Agent with LLMs》。这篇文章本来是讲怎么让一个Agent在Minecraft里活下去的，但它提出了一个核心思想，长程任务必须靠「外部状态」抗漂移，不能靠模型自己记。

总结一下学术圈在闭环率这件事上的共识，光靠模型自己规划是不行的，必须给它一个它能看见但改不了的外部状态对象，让这个对象时刻提醒它「活还没干完」。

这个思想在管人上其实非常直觉。你带新人，光口头说「这周要做完那三件事」是没用的，必须给他建一个todo list，每天对着checklist过一遍，他才不会忘。

工业上是怎么做的？

最简单的版本是给Agent配一个todo工具，每轮把当前的todo列表注入到上下文里，已完成的勾掉，没完成的标红。Claude Code里那个TodoWriteTool就是干这个的。

但学术圈这条线还有一个更狠的玩法，叫Plan-and-Execute加Human-in-the-Loop，强制让用户在「计划」和「执行」之间过一道关。

这个思想在论文里基本是一句话提一下，但工业上有人真把它做成了状态机的硬约束。Claude Code的PlanMode就是这么干的，模型在PlanMode里只能调读工具，写工具全锁死，模型自己也没法退出PlanMode，必须等用户点确认。

我之所以觉得这个设计特别值得讲，是因为它揭示了一个学术paper和工业产品的根本差距。

学术paper说「先规划再执行」，几乎所有论文里的实现，都是在system prompt里写一句话「请先规划再执行」。听不听全凭模型心情。

工业上要把这个pattern真的兑现，你得做一个状态机，要锁住写工具，要管退出条件，要处理各种边界情况。

每一步都不难。但每一步都很重要。

闭环率这道题讲完了，看第二道，韧性。

韧性这条学术线最经典的论文是2023年Shinn他们的《Reflexion: Language Agents with Verbal Reinforcement Learning》。

Reflexion的核心思想一句话能讲完，模型失败了之后，不能让它默默接受这个失败。要让它生成一段「自然语言反思」，把这次失败变成下一次尝试时的提示。

听着很哲学是吧。但它解决的是一个非常具体的问题，模型对失败的「沉默接受」，是退化循环的根源。如果错误信息没有被结构化地喂回模型，模型会忘记，会继续犯同样的错。

后面跟着一系列工作，Self-Refine、RCI（Recursive Criticism and Improvement）、还有2023年Zhou他们的LATS（Language Agent Tree Search）。LATS这篇特别有意思，它说不光要反思，失败了还应该能回溯到上一个决策点，像下棋一样能悔棋。

学术圈在韧性这件事上的共识其实就两点。

第一，错误反馈必须结构化。不能是一个模糊的「失败了」，要告诉员工为什么失败，失败在哪一步，下一步应该怎么调整。

第二，要有反退化循环的机制。员工陷入死循环的时候，外部得有人能拍他一下「停一下，换个思路」。

工业上这两点是怎么落的？

第一点，结构化的错误反馈。Reflexion论文里推荐的格式是XML块包装，让错误信息有一个清晰的结构。Claude Code里所有的工具错误都用<tool_use_error>...</tool_use_error>包起来，这就是Reflexion那篇paper推荐的格式。

但这里有个反例特别值得说，Codex沙箱拒绝命令的时候，给模型返回的就是一个纯文本「aborted」。模型完全不知道是命令越权了，还是参数错了，还是路径不对。下一轮可能换个等价的命令再被拒绝，再被拒绝，再被拒绝。

这就是典型的Reflexion反例，你以为你给了反馈，但因为反馈缺乏信息，员工根本无法从中学习。

第二点，反退化循环。

学术上LATS给的方案是树搜索回溯，理论上很优雅，但工程上太重。所以工业上几乎没人真的实现完整的LATS，大家都做了一个降级版，叫退化循环检测。

你只需要监控两件事就够了，同一个工具加同一个参数失败了多少次，幂等的工具返回了多少次相同的结果。超过一个阈值，硬停。

这个看起来很简单的机制，能解决SWE-bench上Agent最常见的失败模式之一，反复调同一个grep搜同一个字符串。

韧性这道题里我特别想多讲一句的是Reflexion和工程实践的关系。

Reflexion是一个特别理想化的pattern，它假设员工自己能从错误中反思出有用的东西。在论文的benchmark里这是成立的，因为环境干净。但在真实生产里，员工经常对着一个rate limit错误反思半天，得出一个「我应该换个方式调用API」的结论，然后继续撞rate limit。

所以工业上演化出了一个新东西，叫错误分类决策表。

这玩意特别有意思，思路是这样的，反思这事别让员工干，让HR提前帮他分好类。把所有可能的错误类型枚举出来，每一类配一个处理策略，是重试还是切credentials，是压缩还是降级，全部预定义好。员工遇到错误，主循环根据分类自动选策略，员工自己根本不需要反思。

这相当于把Reflexion paper里的「verbal feedback」工程化成了一张决策表。一个有8层优先级的错误分类表能覆盖90%以上的真实错误场景。

学术paper说「让员工自己反思」，工业产品说「我替你反思好了，你照着SOP做就行」。前者优雅，后者管用。

第三道题，信噪比。

这道题对应的论文是这两年最热的一条学术线。

最早是2023年Packer他们的《MemGPT: Towards LLMs as Operating Systems》，把上下文窗口当虚拟内存，主动管理「工作集」和「长期记忆」之间的分页。

紧接着是2024年Xiao他们的StreamingLLM，attention sink加滑动窗口，让模型能处理超长上下文。

然后是Jiang他们的LLMLingua，主动做token级的prompt压缩，根据语义重要性决定哪些token可以扔。

我个人最喜欢的是2023年Xu他们的《ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models》。ReWOO的思想特别聪明，把plan和execute解耦开，规划阶段不要让具体的observation污染上下文，所有observation只在execute阶段用一次。

但要论这两年最有冲击力的，是2024年Wang他们的《CodeAct: Executable Code Actions Elicit Better LLM Agents》。CodeAct的核心思想颠覆了传统的工具调用范式。

传统的ReAct是这样的，模型每一步生成一个工具调用JSON，工具返回结果，结果进上下文，模型基于结果再生成下一个调用。一个十步的任务，可能要十次API调用，十个工具结果全都进上下文。

CodeAct说，为啥不让员工直接写一段Python代码呢？这段代码内部把所有的grep、read、edit、bash全跑一遍，最后只返回一个总结性的stdout。

这就好比你交待一个员工去做一件复杂的活，你是希望他每做一步都跑过来跟你汇报一次，还是希望他自己搞定之后给你一个一句话的总结？

CodeAct论文里的数据，token节省30到50%，多步任务的成功率提升20%左右。

听起来骚不骚？

工业上有人把这个思想真的做出来了，Hermes里面有个东西叫PTC（Programmatic Tool Calling）。Hermes还在CodeAct的基础上加了一个学术paper没解决的工程问题，子工具调用不消耗主循环预算，相当于把「省token」扩展到「省迭代」。

信噪比这条线，工业上还有一个我觉得特别值得说的设计，叫工具结果磁盘溢出。

学术上MemGPT讲的是把上下文当内存。但工业上有人把这个思想用得特别巧妙，超大的工具结果（比如一个500KB的git diff），不进上下文，写到磁盘上，上下文里只放一个文件路径。员工需要的时候，自己用FileReadTool去精确读取相关部分。

类比到管人，就是「别什么资料都堆在你桌上，归档到柜子里，需要的时候自己去翻」。

这就是MemGPT思想的工业化版本，但比论文版更接地气。论文里讲的是抽象的内存分页，工业上是具体到「git diff超过30KB就写文件」这种细节。

讲完三道题，我想再聊一个更上层的东西。

这两年读了一堆agent论文之后，我有一个感受越来越强烈。

学术圈和工业界，其实是两拨人在解同一个问题。

学术圈擅长的是「找到正确的方向」。Plan-and-Execute、Reflexion、MemGPT、CodeAct，这些pattern的提出，是真正的智识贡献。它们告诉你「往这个方向走是对的」。

但学术圈不擅长的是「把方向变成产品」。

学术paper说「先规划再执行」，工业产品要做成状态机。 学术paper说「让员工反思错误」，工业产品要做错误分类表，要做断路器，要做指数退避加jitter。 学术paper说「虚拟内存式上下文管理」，工业产品要做磁盘溢出，要做压缩失败的容错。

每一步都不难。但每一步都很重要。

我有时候觉得，最好的Agent，从来不是某个学术上最先进的Agent，而是把所有已知的pattern都老老实实做完的Agent。

学术圈三年前就把答案写在论文里了，只是大部分做产品的人没去读。

所以如果你正在做Agent，我有一个不太成熟的建议。

不用追最新的论文，去把2022到2024年这几篇基础paper认认真真读一遍。ReAct、Plan-and-Execute、Voyager、Reflexion、LATS、MemGPT、ReWOO、CodeAct。八篇，一个周末能读完。

读完之后你会发现，市面上几乎所有Agent的设计决策，都能在这些paper里找到原型。

而你接下来要做的，就是把这些paper里讲的东西，老老实实在工程上兑现一遍，每一个paper没写到的角落里，都加一个「以防万一」。

这就是做Agent的全部秘密。

最后回到最开始那三道题。

这三道题之所以让我一开始很震撼，是因为它跟我以为的那种冰冷的「机器指标」完全不一样。它评价的根本不是机器，是一个被你雇来干活的员工。

它能不能跑完事？背后是Plan-and-Execute和Voyager。

出错了能不能爬起来？背后是Reflexion和LATS。

说话效率高不高？背后是MemGPT、ReWOO和CodeAct。

学术圈早就把功课做完了。剩下的，就看做产品的人愿不愿意把这功课认真兑现了。

而我们用户，下次再评价一个Agent好不好用，也可以拿这三道题去问。

它能不能跑完事？

出错了能不能爬起来？

说话效率高不高？

把它当一个员工去看，比当一个工具去看，可能更接近事情的真相。