Agent 练了十几个才明白：能跑通和敢上线隔着四件事

我练手写的 Agent 项目攒到十几个，能在一个下午跑通的有大半，敢放在机器上连续跑一周的没几个。

卡住的从来不是「模型会不会调工具」。是跑起来之后才暴露的东西：输出格式偶尔坏一次、循环停不下来、过两天没人说得清它为什么变慢、半夜触发失败没人知道。

把这些项目按上线门槛重排一遍，其实是四层能力。每一层都能单独找个项目练，顺序别倒着来。

第一层：输出可靠，而不是「大部分时候对」

最该先做的一个：让模型的每一条结构化输出都过一遍 schema 校验，工具返回的内容也先校验再塞回上下文。解析失败不要吞掉，把错误信息带回给模型重试一次；再失败就记下来。

坑在这里：合法 JSON 不等于对的答案。schema 只管形状。金额是负数、起止时间写反、引用了一个不存在的订单号，这些看起来都规规矩矩。

所以校验得写三层。形状之外加领域约束（这个字段的取值范围、那两个字段的先后关系）；失败时带错误信息修一次；最后留一个升级阈值，两次修不回来就别硬撑，返回「不确定」或者转人工。

别只看成功率。失败集中在哪里比失败率高低更重要，前者能改，后者只能焦虑。

第二层：循环可控，别让它自己转

只要用了「观察—思考—行动—反思」这种循环，三样东西必须设：迭代次数上限、整体时间预算、重复动作检测。同一个工具用几乎一样的参数连着调两次，基本可以判定它困住了。直接跳出，比等它自己觉悟靠谱。

写细一点还要加降级路径：循环被掐断时返回已经拿到的部分结果，并且说清楚缺了哪一步。这比抛异常或者返回半截答案都好收拾。

无限循环最麻烦的地方是它不报错。日志里每一步都正常，账单在涨，你看着以为任务在干活。

第三层：记忆和状态，得当真事办

短期窗口加长期召回是标配，真正费劲的是另外两件。一是压缩：上下文快满的时候要摘要掉旧的，同时保留最近几轮的原文，不然模型会忘掉刚刚确认过的细节。二是时效：写进记忆的内容要能过期、能被新结论覆盖，否则用户改了口，你会拿着旧偏好一直跑下去。

召回也得打分。不是把所有相关记忆都塞回去，而是按相关度取前几条，剩下的留在库里。塞得越多，注意力越散。

有跨会话需求的话，把「上次停在哪儿」「哪些结论是用户确认过的」「哪些只是他自己猜的」分开存，用起来省心很多。

第四层：成本和故障，得在账上也在图上

这一层决定它是个项目还是个玩具。

成本靠路由。简单的判断交给小模型，复杂任务再往上抬；每个任务给一个 token 预算，模型自己给出高置信度就提前收尾。记账按「每次决策多少钱」算，别按「每百万 token 多少钱」，后者跟你的实际支出关系不大。

故障先靠可观测。每一步都留 trace：调了哪个工具、花了多久、烧了多少 token。然后挂两个告警，一个盯循环，一个盯连续失败。上线走灰度和回滚，这是把事故控制在自己手里的唯一办法。

事件触发的还要额外管三件事：幂等（同一个事件重复到达只处理一次）、重试退避、死信队列。少一条，就会在某天凌晨集中爆发。

需要人拍板的流程，把「检测到不确定 → 暂停 → 人确认 → 带着确认过的上下文继续」做成固定环节，全程留痕。这比事后追责便宜太多。

多 Agent 和自动评测，先别急

让几个角色分别提方案、一个角色挑刺、再投票或者汇总，这类多 Agent 结构确实能提高难任务的通过率，代价是成本翻几倍。只有「答错一次的代价很高」的场景值得这么干。

自动评测也差不多：模型执行完自己打分、指出推理里的问题、带着约束重新生成，把改进了多少记下来。它有用，但裁判本身会偏，得定期人工抽检校准。

这两样都排在四层之后。单 Agent 的循环和观测没打牢，多 Agent 只会让失败更难查。

从哪里开始

只练一个项目，就练结构化输出加校验重试。它改完，你会发现自己其他项目都跟着稳了一截。

第二个练带工具循环的，重点不在功能多少，在于上限和降级路径都写出来了。

第三个再加 trace 和成本面板。走到这一步，你才算开始知道它在干什么。

记忆、人机协同、多 Agent 放最后。不是它们不高级，是它们都得靠前面几层撑着。

三个容易翻车的地方

把「跑通一次」当成功率。本地连着试三次都过，不代表它能连着跑一百次。

只看平均延迟。平均值盖住的恰恰是最要命的那几次：卡死不动、重试了八遍还在重试。

拿本地 mock 测完就上线。触发、幂等、超时退避这些只在真实环境里露馅，mock 里永远测不出来。

说到底，练手项目最不值钱的是数量。跑得通的 demo 一天能写三个，敢让它在半夜自己跑的，才是真正要练的东西。

以上都是本机实践里的取舍，正式上线前请以你所用框架的官方文档为准。