很多团队把 Agent 从 demo 搬上生产，第一道坎不是模型效果，是基础设施。demo 里跑通一次不代表能天天跑。我们帮不少团队踩过这个坑，缺的往往是几个基础设置。
超时：别让一个慢接口拖死整条链
Agent 调一个工具，对方没反应，不能无限等。每个调用得有超时，到了时间要么换路要么报错。我们见过一个 Agent，因为一个第三方接口半死不活，主链路卡了四十分钟，用户以为系统挂了，其实只是卡在一个没设超时的调用上。
重试与断路：失败要退避，连续失败要熔断
工具偶尔失败正常，自动重试几次没问题。但同一个接口连续失败，就得断掉，别还在一个已经挂掉的服务上死磕。我们见过一个 Agent 因为下游一瞬间抖，重试了几十次把额度打光。好的做法是重试带退避，连续失败到一定次数就熔断，过一会儿再试探。
状态：重启了能从断点续上
长任务跑一半机器重启了，能不能从断点续上，而不是从头再来。这要求每一步的状态被记下来，不是只存在内存里。我们之前写事件流那篇，讲的就是这个底层的同步办法。状态不落地，重启一次等于重跑一次，长任务根本不敢上生产。
追踪：一步慢了能一条线拉出来看
一个 Agent 跑了十几步，哪一步慢、哪一步错了，得能一条线拉出来看。没有追踪，线上出问题只能靠猜。我们给客户接生产环境，第一件事往往是先把追踪补上。有一次客户投诉某次回答特别慢，我们拉出追踪，一眼看到是其中一个检索工具慢了八秒，不是模型的问题，定位就花了十秒。
架构：有状态编排层 + 无状态工具层
这几样单拿出来都不难，难的是它们得作为一个整体存在，而且最好由平台提供，别让每个业务团队自己造一遍。我们倾向的架构是分两层：编排层有状态，记得住任务进行到哪，重启了能续；工具层无状态，随时可以被拉起和替换，挂了换一个就行。两层之间靠前面说的那几个原语通信。一个工具挂了，编排层换一个接着跑，用户那头可能只多等了两秒。我们给一个金融客户做核对 Agent，工具层挂过两次，都是编排层秒级换备用的，业务那头完全没感知。
Agent 上生产，拼的不是模型多聪明，是它崩了之后能不能自己爬起来。原语齐全，崩了能恢复，用户基本无感；原语缺失，一次抖动就变成一次事故。
一次真实故障里，怎么起作用
举个具体的。一个做核对的 Agent，工具层挂了检索服务。编排层在调用前就设了超时，八秒没回就标记失败，同时启动断路，不再往这个已经挂掉的服务上发请求。编排层从备用路径换了一个检索实例，十秒内恢复，那次核对任务全程没中断，业务那头完全没感知。事后拉追踪看，整条链路里只有检索那一段耗时从平时的两秒跳到了八秒超时，其余步骤照常。没有超时，这一次调用会卡到用户那边转圈；没有断路，重试会把这个挂掉的服务打得更死。两个原语一起，才把一次故障变成一次无感切换。
我们给客户接生产环境，第一件事就是把这四个原语默认打开，不是让他自己选装。demo 阶段想不到这些，等线上真出事才补，代价就大了。
这四点我们内部叫生产就绪四件套。一个新客户接入，我们先用一套检查脚本扫一遍他的 Agent，缺哪个原语直接标红，按优先级排好补的顺序，不让他自己摸黑。等四个都绿了，我们才敢说这个 Agent 能上生产。demo 能跑和能天天跑，差的就是这四个原语齐不齐。
去年我们接手一个金融客户，上线前扫出来缺状态落地和追踪两项，补完之后他们的告警平均定位时间从两小时降到十分钟。原语看着不起眼，缺一个就是一场事故。
我们给每个接入的客户做一次生产就绪检查，超时、重试、状态、追踪四项缺哪个，先补哪个。这些原语我们也把机制写进文档给客户看，不是黑盒，信任来自透明。