AI Agent 这一年：进展体现在哪

判断一个 AI Agent 有没有进步，别看你看到的演示，看你自己那个任务返工了几次。这一年真正变化的，是执行链路：同样一句指令，它能连续调用工具、在失败后换路径、把中间结果留给下一步。模型本身的分数提升有限，链路工程补上了不少短板，这才是演示效果和真实可用之间被缩短的距离。

进步发生在执行链路，不在智商

把 Agent 拆开看，一次任务要过四道关：理解目标、拆步骤、调工具、判断结果对不对。早两年的产品多在前两步用力，靠一段更长的提示词让模型想清楚；这一年的变化集中在后两步——工具调用的参数校验、失败后的重试策略、执行过程的可回放。这三项不提升模型的推理上限，却直接决定一个任务能不能走完。

可带走的一个判断：如果你的任务只需要一次生成、不需要外部信息，Agent 相比普通对话没有优势，多出来的步骤只是多出来的出错点。它的收益来自必须动手的环节，比如查库、改文件、发请求。

任务变长，代价是每一步都可能偏

从单步到多步，成功率按乘法衰减。假设单步正确率九成，十步串联只剩约三成五。这就是为什么演示里十步完成任务很惊艳，放进你的业务流程却经常卡在第 6 步。产品端的应对是加检查点：每完成若干步做一次自检，或者把长任务拆成几个可交付的小段，每段结束让人确认。

对使用者来说，这个机制的含义很实际：把长任务切成短任务交给它，比要求它一次做完更可靠。你要的是每一步的产物都能被检查、被退回，而不是一口气跑完。

工具变多，选择本身成了难点

工具数量上去之后，新的问题不是能不能调，而是该调哪个。同一件事，检索、代码执行、浏览器操作都能做，选错工具的结果往往是白跑一轮再重来。这一年的产品普遍在工具描述和选择策略上做细化：给每个工具写清适用条件、参数范围、返回结构，让模型在调用前先做一次匹配。

这也解释了为什么很多 Agent 在演示环境表现好、接进内部系统就变差：演示里的工具有清晰说明和稳定返回，内部接口的报错信息含糊、字段命名混乱，模型只能靠猜。接内部系统前，先把错误码和字段说明整理成人能读懂的程度，收益比换一个模型更大。

失败恢复：能重试不等于能纠错

重试是机械动作，纠错需要判断。接口超时，重试有用；参数填错，重试一百次还是错。判断一个 Agent 的恢复能力，看它失败后会不会改变策略——换工具、换检索词、缩小范围，或者直接承认做不到并交回给人。

可观测性是这里的基础设施。执行过程如果只给一个最终答案，你无法知道它错在哪一步；能给出每一步的输入、输出、耗时和报错，才谈得上定位。Agent 可观测性盯的到底是什么讲的就是这套记录该怎么读。多 Agent 协作时还要多一层交接记录，Agent 之间的交接与汇报里有一套字段可以照搬。

用四个维度判断你的任务能不能交出去

这张表建议倒着看：先看常见坑那一列，你的任务踩中哪一条，就先解决那一条，再谈上线时间。

它做不到什么

Agent 处理不了目标本身模糊的任务。“帮我提升用户满意度”这类指令，人也不知道从哪下手，交给它只会得到一堆看起来合理的动作。目标必须能被拆成有完成定义的步骤，否则它做的每一步都在猜。

它也承担不了后果。涉及付款、对外发送、删除数据这类不可逆动作，必须保留人工确认环节。很多事故的根因是权限给多了，模型判断反而没错——把能执行和该执行分开，是部署时的基本设置。

成本方面要有预期：多步任务的 token 消耗按步数累加，一次长任务的花费可能是单轮问答的几十倍。计费口径在 API 和订阅之间差别不小，API 计费与订阅计费的差别值得先算清楚再放量。另外，长任务的上下文会不断累积，接近窗口上限时早期信息被挤掉，表现就是忘了前面说过的约束。

试跑一个 Agent 任务前的检查

• 目标能写成一句可验收的话，写不出就先别交
• 步骤超过十步，切成两段分别跑
• 先给只读权限，跑稳再给写权限
• 每一步留输入输出记录，否则无法定位错误
• 不可逆动作之前必须有人确认

三个还没被讲透的问题

• 同一个任务今天能跑通、明天失败，是模型变差了吗？：多数情况是外部条件变了——接口返回格式、网页结构、检索结果都在变。把外部依赖的版本固定下来，波动会小很多。
• 多步任务该不该让它自己决定什么时候停？：给它一个明确的终止条件，比如找到三条满足条件的记录就停，比让它自由判断更可控。没有终止条件的 Agent 容易在循环里打转。
• 小团队没有工程资源，能直接用吗？：可以用，但要把范围压到单点任务，比如固定格式的信息抽取。跨系统的流程编排需要有人维护接口，没有这个人力就先别铺开。

如果还在选模型，先分清满血版与蒸馏版的能力差，参数变少之后差在哪里会直接影响你能交给它多复杂的任务；任务里涉及代码执行时，代码语料与自然语言语料的差别也值得看一眼。