把 AI Agent 放进生产环境，难的从来不是写 prompt

Agent 从”能跑”到”敢上线”，中间隔的从来不是一个更好的 prompt，而是一整套从地基到天花板的 evaluation 和 audit。

模型一定会错，这是前提，不是意外。你要做的不是让它不犯错，而是保证它犯错时，错误落在能承受的范围内。

普通 SaaS 做到漂移检测基本够用；可一旦进了受监管领域，可追溯的审计链路就不再是加分项，而是准入门槛。

某天你的 agent 突然开始乱答。你排查了半天,代码没人动过,prompt 没人改过,最后发现:是 LLM 供应商在同一个 API 后面,悄悄换了模型版本。这种事在 demo 里无所谓,刷新一下就过去了;可在生产环境,尤其是投资和金融这类领域,它就是一起事故。

Agent 从”能跑”到”敢上线”,中间隔的不是一个更好的 prompt,而是一整套 evaluation 和 audit。这套东西到底长什么样?下面是我们实际在用的分层做法,从地基往上,一层一层说。

Layer 0:Tracing / Observability,这是地基。 每一次调用的 context、tool calls、reasoning、final output,全部记下来。这一层本身不产出任何结论,但后面所有的评估和审计,都长在它上面。地基没打好,上面全是空中楼阁。

Layer 1:Offline Evaluation,上线前先跑一遍。

• Golden set:和领域专家一起,手工攒 200 到 500 个真实场景,从输入到期望输出。之后你每改一次 prompt、每换一次模型、每动一次 retrieval,都得拿它重跑一遍。但要记住,它不是一次性资产。上线后线上抓到的真实失败(见 Layer 3)要持续归类、回灌进来,否则它永远比真实流量慢半拍,还容易在反复重跑的老 case 上过拟合。
• 选型即评估:同一个任务,用不同档位、不同版本的模型各跑一遍 golden set,把分数、单位成本、延迟这三个数摆在一起看。挑的不是默认最大的那个,而是性价比拐点上的那个。贵的模型,只留给真正吃能力的环节。
• Slice metrics:只看聚合分数会骗你。一个总分 90 的系统,可能在某一类基金上只有 60,只是被其他切片的高分给摊平了。所以必须同时按问题类型、基金类型、时间窗、用户角色切开看。
• Component-level eval:每一环单独评。检索看 recall@k、precision@k;工具调用看选对工具没、参数对没;最终答案看 factuality、citation correctness、output format。哪一环掉链子,一眼就看得出来。
• Refusal calibration:该拒的真拒了吗(比如索取 MNPI、越权操作)?该答的又真答了吗?一个什么都拒的系统,和一个什么都答的系统,一样没法用。

Layer 2:Online Evaluation,放进真实流量里验。 先灰度:新版本只吃一小撮真实流量,盯着线上指标(失败分类、用户行为、人工抽检),稳住了再一点点加大。

但灰度只是第一道。更关键的是在它上面再压一道独立 verifier:一个和主模型解耦的检查器,在结果返回用户前、或者高风险动作执行前,做三件事。一,verify citation,引用的文档真存在、真说了这话吗?二,verify response based on citation,答案确实是从引用里推出来的,还是在引用之外自己编的?三,verify 这个问题该不该答,越权的、索取 MNPI 的、超出能力边界的,直接拦掉。它独立于主链路,所以主模型错了,后面还有人兜着。

Layer 3:Failure Taxonomy,给错误建一套分类。 光知道”它有时会错”没用,你得知道它怎么错、往哪儿修。所以要把失败模式一条条列清楚,再跟踪每一类的频率随时间怎么变:幻觉(编了不存在的事实)、找错文档、找对了没用对、用错工具或传错参数、前提对但结论错、格式违规、该拒不拒或不该拒却拒、被构造输入带偏(也就是 prompt injection,检索到的文档或用户输入里夹带的指令把它带跑)。没有这套分类法,你手里就只有一句模糊的”它不太稳”,修起来无从下手。而且这套分类不只是拿来统计频率的:每一类里挑出有代表性的真实失败,清洗成”输入到期望输出”补进 golden set(回到 Layer 1),线下评估才追得上线上流量。

Layer 4:Drift Detection,就是开头那个场景。 但第一道防线其实不是检测,是锁版本:能 pin 住带日期的模型快照就 pin 住,并把模型版本绑进 provenance(见 Layer 5),别让供应商在你不知情的时候无声替换。检测是兜底,管那些锁不住的漂移,比如供应商在同一个版本号底下做的 silent update,或者你自己 retrieval 语料的变化。兜底的做法是定期自动跑一遍 golden set,分数一掉就报警。但要清楚它的盲区:每天跑只盖得住 golden set 覆盖到的切片,长尾 slice 上的退化它根本看不见。所以覆盖面得跟着线上失败一起长,golden set 越全,这道防线才越严。

Layer 5:Regulatory-Grade Audit Trail,这是投资领域和普通 SaaS 的分水岭。 你得做到完整的 provenance:哪个 prompt 版本、哪个模型版本、检索了哪些文档、哪个用户、什么时间,每一条都可追溯。普通 SaaS 出了问题,顶多复盘;受监管领域出了问题,监管会让你把当时的每一步都还原出来,还不出来,那就是你的责任。

几条实战补充

边界设计:就当模型一定会错。 模型必然犯错,这是前提,不是意外。所以设计的时候,目标不是让它不犯错,而是保证即使它错了,错误也落在可接受的范围内。具体就是把动作关进 sandbox、收紧权限、给每个工具调用设上限和回滚,把错误的爆炸半径压到能承受的程度。

这也是我对 prompt injection 的回答:你拦不住所有被构造的输入,但你可以让”即使注入成功,它能造成的最大破坏”也在可接受范围内。不过 sandbox 只管住了动作那一侧。注入还能污染答案,再借着答案把数据带出去,这部分得靠前面那道独立 verifier(grounding 检查加该不该答)来接。sandbox 收爆炸半径,verifier 接被污染的输出,再把检索来的内容一律当成不可信数据,这套组合拳,比试图穷举所有恶意输入现实得多。说到底,这事没有银弹。

普通 SaaS,做到 Layer 4 基本就够用了。可一旦进了受监管的领域,Layer 5 就不再是加分项,而是准入门槛。这一整套东西看着繁琐,但它的意义只有一个:让你敢把 agent 一直开着,而不是每天提心吊胆它今天又会怎么错。