你的AI agent在生产环境翻车之后,那些报错日志最后去哪了? Madrigal Pharmaceuticals的做法是:直接变成下一版的考题。

LangChain官网这周发了篇博客,讲这家生物制药公司怎么搭多智能体平台。架构本身没什么新鲜——编排器路由、并行代理、共享工作区,都是标准套路。真正让我停下滑动的是质量保证板块里的一句话:

打开网易新闻 查看精彩图片

「生产故障会自动回流到我们的LangSmith数据集。每个有意义的错误都会变成新测试用例。评估套件从真实故障中生长,而非合成场景。」

这就是现在生产环境AI里最被低估的模式:用验证失败当评估数据集。

合成测试的盲区

大多数团队搭agent评估套件,起手姿势一模一样:写50-100条合成测试用例,跑一遍agent,算通过率。上线v1够用了。

然后agent进生产环境,你开始发现合成测试根本没覆盖到的失效模式——因为你根本想象不到。

发票agent所有测试都过,但偶尔漏掉货币字段,只因源数据用了它没见过的ISO 4217代码。合同提取agent处理英文完美,遇到双语文档却默默返回空数组。代码审查agent安全检测准确率98%,但只要变量名里带"eval"的字符串比较就报误报。

这些才是真正要紧的故障,而且只在生产环境现身。Madrigal的洞察是自动捕获它们,喂回评估数据集。他们的测试套件不止测"以为会出错的",还测"实际出过错的"。

Madrigal的流水线长什么样

根据LangChain那篇博客,他们的 setup 大致这样:

Agent在生产环境处理任务 → LangSmith追踪每次工具调用、检索、决策 → 出现有意义错误时捕获并加入LangSmith数据集 → 该数据集成为后续agent迭代的测试用例 → 大模型作为评判员(LLM-as-judge)给完整agent运行打分,评分标准"镜像真实终端用户的业务反馈表"

这套方法扎实,LangSmith的追踪让他们看清agent决策全链条。但有两点值得注意:

第一,评估主要靠大模型。他们用"LLM-as-judge评分器"打结果分。博客里没提确定性验证——schema检查、类型强制、业务规则评估——在LLM评判之前有没有先跑一遍。

第二,故障捕获似乎在追踪层发生。出问题的时候,trace抓下来。但trace什么都抓,它天生分不清"agent调错了工具"和"agent最终输出违反业务约束"。两者进同一个数据集,得有人手动筛选哪些故障真能当测试用例用。

Flow的解法:让约束检查前置

我们建Flow的时候,脑子里想的就是这类问题。

Flow的核心设计是约束即代码(Constraints-as-Code)。不是等agent跑完再让大模型判分,而是在执行流程里嵌入确定性检查点。schema验证、类型强制、业务规则——这些在LLM生成输出之前就拦住问题。

这和Madrigal的LLM-as-judge不是互斥,是分层。确定性检查抓"硬错误":输出格式不对、必填字段缺失、数值超范围。这些不需要大模型评判,规则写死就行。LLM-as-judge处理"软质量":语气是否合适、建议是否有用、推理是否连贯。

关键区别在于:当约束检查失败时,Flow自动把失败场景结构化归档。不是丢进一个原始trace池子等人工捞,而是按失败类型分类——schema违规、业务规则冲突、类型不匹配——直接生成可复用的测试用例。

Madrigal得手动筛选trace里哪些故障值得进数据集。Flow的用户拿到的是已经分类好的、可直接回归测试的失败样本。

为什么"真实故障当测试"这么难普及

这个模式听起来像常识,实际落地阻力不小。

技术债是头号障碍。很多团队的生产监控和评估基础设施是割裂的。故障在A系统报警,测试用例存在B系统,中间靠人工搬运。Madrigal能自动化,是因为LangSmith把追踪和数据集打通了。没这个基础设施的,只能干瞪眼。

组织惯性是二号障碍。QA团队习惯写合成用例,觉得"真实故障太脏、太随机、不好控制"。确实,生产故障带着各种上下文噪音,直接当测试用例会 flaky。但这不是放弃的理由,是设计过滤机制的信号。Madrigal的做法是只收"meaningful errors",标准是人定的。

第三个障碍更隐蔽:失败羞耻。团队不愿意把生产事故摊开当教材,尤其是涉及客户数据的。Madrigal是药企,合规要求极严,他们敢这么做,说明找到了脱敏和结构化的方法。

从"防故障"到"养故障"

传统软件测试的思路是消灭故障。AI agent测试的新思路是:把故障当资产养起来。

合成测试覆盖的是已知未知(known unknowns)——你意识到可能出问题的地方。生产故障暴露的是未知未知(unknown unknowns)——你根本想不到的 corner case。后者的价值随时间指数增长,因为agent的失效模式会漂移。今天的大模型版本和明天的,犯错方式不一样。

Madrigal的模式本质是建立组织记忆。每个生产故障都是付费买来的认知,不能用完就扔。变成测试用例,才能确保下一代agent不再踩同一个坑。

Flow的基础设施设计围绕这个理念:约束检查失败自动入库,按类型标签化,支持一键导入回归测试套件。你不需要像Madrigal那样手动从trace里捞故障,系统帮你结构化归档。

落地 checklist

想复制Madrigal模式,先问自己几个问题:

生产监控能不能自动识别"有意义的错误"?不是所有异常都值得进数据集,需要业务规则过滤。

错误捕获和测试基础设施是否连通?如果中间需要导CSV、写脚本、人工审核,摩擦成本会杀死这个流程。

失败样本是否可复现?生产故障带着特定上下文,脱敏后还能不能跑通?需要环境隔离和mock机制。

团队有没有"养故障"的文化?从追责转向学习,需要管理层表态。

LLM-as-judge 的边界

回到Madrigal的具体实现,他们的评分全靠大模型当裁判。这省事,但有天花板。

大模型评判的稳定性是个老问题。同样输出,换个大模型版本,分数可能飘。更麻烦的是,评判标准"镜像真实终端用户的业务反馈表"——用户反馈本身是主观的、时变的、可能互相矛盾的。

Flow的做法是混合评分:确定性检查给硬指标,LLM-as-judge处理软质量,人工抽检兜底。不是不信大模型,是不全押在它身上。

另一个细节:Madrigal的评判对象是"完整agent运行"。这很合理,agent的价值在端到端。但调试的时候,你需要知道是哪一步出的问题。LangSmith的追踪给了这个能力,但评分是整体打的。Flow支持分层评分——子任务可独立评估,方便定位。

基础设施决定方法论

Madrigal能实践"故障即测试",前提是LangSmith提供了追踪-数据集闭环。没有这个基础设施,理念就是空话。

这解释了为什么这个模式至今小众。大多数团队的生产监控和ML实验管理是两套系统,数据流断了。Madrigal是LangChain生态的深度用户,天然享受这个红利。

Flow的定位是把这个能力泛化。不管你用什么agent框架,约束检查、失败捕获、测试生成是一体化的。不绑死特定追踪工具,但提供同等的数据闭环。

换句话说,Madrigal证明了模式可行,Flow想降低复制门槛。

药企场景的启示

Madrigal是生物制药公司,这个背景不是偶然。

药企对合规和可追溯性的要求,倒逼他们建立严格的评估体系。AI agent处理的是研发文档、监管申报、临床数据,出错成本极高。他们的"故障即测试"模式,是在高压环境下进化出来的。

这对其他行业有参考价值。金融、法律、医疗——任何容错率低的场景,都需要类似的严肃评估。不是"差不多能用",是每次迭代都有回归测试背书。

反过来,消费级应用可能觉得这套太重。但Madrigal的案例说明:一旦业务关键,评估基础设施的投资回报率极高。一个生产故障的代价,可能远超建测试体系的投入。

从个案到模式

LangChain这篇博客的价值,是把Madrigal的实践结构化呈现。以前"故障当测试"是口口相传的野路子,现在有了可参照的架构图。

但参照不等于复制。Madrigal的具体实现有依赖:LangSmith追踪、LLM-as-judge评分、人工筛选meaningful errors。每一点替换都需要重新设计。

Flow的出发点是:把模式抽象,基础设施下沉。约束检查、失败归档、测试生成——这些能力应该框架层解决,让每个团队都能低门槛实践。

这不是说Madrigal的做法过时。恰恰相反,他们验证了需求真实存在。Flow想做的是让更多人不必从头造轮子。

下一步会怎么演化

Madrigal模式还有优化空间。

自动分类是 obvious 的方向。现在靠人工标"meaningful",未来可以用小模型做初筛。失败模式聚类,相似故障合并,减少测试套件膨胀。

另一个方向是主动探索。被动等生产故障效率太低,可以用对抗生成或模糊测试主动造故障,补全覆盖盲区。

还有跨组织共享。同行业的故障模式有共性,脱敏后能否建立行业基准测试集?这比各自闭门造车高效得多。

Flow的路线图包含这些方向。约束检查失败的数据结构已经标准化,为后续分析打好基础。

给技术负责人的 takeaway

如果你正在或计划上生产级AI agent,三点建议:

第一,评估套件必须从第一天就设计"自生长"机制。合成测试起步可以,但要有管道接生产反馈。否则三个月后,测试和实际脱节,评估变成安慰剂。

第二,分层评估比单一评分可靠。确定性检查抓硬错误,LLM-as-judge处理软质量,人工兜底。别把一切都押在大模型裁判上。

第三,基础设施选型看闭环能力。追踪、监控、测试、迭代是否连通?数据能不能自动流动?这比单个功能点更重要。

Madrigal的案例是个提醒:生产AI的评估,不是写完测试用例就结束的事,是持续从现实中学习的系统。你的下一个测试用例,可能正藏在昨天的报错日志里。