大模型智能体的下一步

过去两年，智能体（agent）的能力边界被反复重新定义。最初大家兴奋于「模型能调用工具了」，接着是「能连续调用多个工具完成一条任务链」，现在则开始讨论「能不能自己提出假设并验证」。如果把这几个阶段放在一起看，会发现真正的分水岭不在于工具数量，而在于闭环。

一、工具调用解决的是「接口」，不是「判断」

一个能查天气、能读文件、能跑代码的 agent，本质上已经把模型接到了一个可执行的世界里。但接口只保证「能做事」，不保证「知道该做什么」。在真实任务中，绝大部分失败并不是因为 API 调不通，而是因为：

目标没有被拆成可验证的子目标；
中间结果没有被正确地判断为「成功」或「失败」；
失败之后没有改变策略，而是重复同一种尝试。

这也是为什么很多 demo 在简单任务上惊艳，一旦任务步数变长就迅速退化：误差会沿着链路累积，而模型缺少一个稳定的「自我检查」环节。

二、反思机制的价值与代价

让模型在每一步之后对自己提问——「这一步达成了什么？下一步的前提是否满足？」——听起来很朴素，但它把隐式的推理变成了显式的文本状态，使得错误更早暴露。代价也很直接：更长的上下文、更高的延迟与成本，以及一种新的失败模式，即过度反思：模型在无关紧要的细节上反复打转。

反思不是让模型想得更多，而是让它想得更「可检验」。

我比较看好的方向是把反思绑定到可执行的验证信号上：单元测试、检索到的事实、数值一致性检查。能跑通的代码比「我觉得应该没问题」可靠得多；能被检索验证的陈述比模型自述可靠得多。

三、长期记忆：难点在「该忘什么」

记忆系统通常被描述成「把重要信息存起来，需要时取出来」。但工程实践里，检索精度往往不是瓶颈， 写入策略才是。什么值得记、以什么粒度记、什么时候该让旧信息失效，这些问题没有统一答案。一个实用的折中是：把记忆分为三层——任务内的短期状态、项目级的结构化笔记、以及长期的知识条目，每层的写入与淘汰规则都不同。

四、评测：别只看最终答案

如果只用「最终答案对不对」来评测 agent，就会得到一个非常不稳定的指标：同一个模型同一套提示，跑两次结果可能差很多。我更倾向于记录过程指标：

步数效率：完成任务用了多少步，其中多少步是无效的；
错误恢复率：遇到失败后，有多少比例能自行纠正；
可复现性：同样的任务重复多次，成功率的方差有多大。

这些指标不漂亮，但它们更接近真实使用中的体验，也更容易定位问题出在规划、工具还是记忆。

写在最后

「会做研究」是一个很高的标准：它要求提出有价值的问题、设计能证伪的实验、并且诚实地报告失败。目前的能力离这个标准还有距离，但路径是清晰的——把更多的判断交给可验证的信号，把更多的过程暴露成可检查的记录。这大概也是我为什么一边做研究，一边写这些笔记的原因。

本文为示例文章，观点仅代表个人，欢迎交流讨论。