这家药企把AI事故变成了测试题库

你的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的评估，不是写完测试用例就结束的事，是持续从现实中学习的系统。你的下一个测试用例，可能正藏在昨天的报错日志里。