智能体的可靠性工程：完成了，不等于做对了

这周我连续写了三篇关于智能体的文章：从”替你办事”到”记得你”，再到”组团协作”。今天想聊一个更基础、也更扎心的问题——智能体确实能完成任务了，但它能把事情做对吗？

一、”完成了”和”做对了”是两件事

过去一年，我们对智能体的期待经历了两次升级。第一次升级，是从”会聊天”到”能干活”——它不再只是回答你的问题，而是帮你拆任务、调工具、跑流程；第二次升级，是从”一个人干活”到”一群人干活”——多智能体开始分工协作，像一个小型团队。这两次升级都很真实，也确实解决了大量单点问题。

但我在评测和实测了数十个智能体应用之后，越来越确信一件事：行业对”任务完成率”的关注，远远超过了对”任务正确率”的关注。这两者之间的差距，正是智能体从玩具走向生产力之间，最容易被忽视的那道坎。

举个最简单的例子。你让一个智能体”帮我查一下竞品本周的新动态，并整理成一份简报”。它大概率会做这几件事：搜索网页、抓取文章、提取要点、生成简报。单看流程，它”完成”了。但你逐条核对就会发现：它可能把上周的新闻当成本周的，可能把甲公司的产品发布会安到了乙公司头上，也可能在找不到权威信息时，用模型”脑补”了一段看起来合理的内容补进去。

流程走完了，结果却经不起推敲。这就是”完成”与”做对”之间的鸿沟。前者考验的是任务编排能力，后者考验的是事实核验、约束遵守和自我纠错能力——而这三种能力，恰恰是当前智能体最薄弱的环节。

二、执行失败的三个典型场景

我把实测中遇到的执行失败做了归类，最常见的是这三类。

第一类：工具调用出错，但智能体不自知。智能体的能力边界很大程度取决于它能调用的工具——搜索、数据库、API、文件系统。工具返回异常时，模型有时会忽略错误码，继续按照”预期应该成功”的路径往下走；更隐蔽的是，工具调用成功了，但返回的是空数据或旧数据，模型没有做合理性校验就拿来用了。这类错误的危险在于，它不会报错，而是”安静地错”。

第二类：环境假设错误。智能体对运行环境的认知，往往来自训练数据中的”平均情况”。它假设文件系统里有一个叫 output 的目录，假设 API 的鉴权方式没变，假设网络是通的——但当这些假设不成立时，它不会停下来确认，而是硬着头皮执行，最后产出一个基于错误假设的结果。做过工程的人都知道，这类错误最磨人，因为问题不在代码里，而在代码的”前提”里。

第三类：验收标准缺失导致的”自说自话”。这是最普遍的一类。你让智能体完成一个开放任务，它完成了，但它理解的”完成”和你期待的”完成”可能根本不是一回事。它以为写一份五百字的摘要就够了，你要的是带数据出处、带风险提示的分析。没有明确的验收标准，智能体就只能按它自己的模板交差——然后你会觉得它”不靠谱”，它也会觉得你”没讲清楚”。

三、可靠性工程：智能体需要的三块补丁

好消息是，这三类问题都有对应的工程解法，而且正在成为行业共识。

第一块补丁是”验证前置”。在让智能体执行一个多步任务之前，先把每一步的验收标准定义清楚：这一步产出什么、格式是什么、谁来校验、错了怎么办。把验收标准写进任务描述里，比事后人工核对高效得多——因为智能体在每一步都有一面”镜子”可以照自己。我见过不少团队把这个环节做成了”任务模板库”，把高频任务的验收标准沉淀成可复用的约束，效果立竿见影。

第二块补丁是”工具结果校验”。对工具返回的数据做二次校验：数据是否为空、时间是否在预期窗口内、来源是否可信、数值是否在合理区间。这些校验规则不需要多复杂，往往是几条简单的 if 判断，但它们能把”安静地错”变成”大声地报”。真正的分水岭，是让智能体在数据异常时敢于停下来，而不是硬着头皮继续。

第三块补丁是”可回滚的执行链”。把智能体的执行过程拆成有状态的步骤链，每一步记录输入、输出和中间产物。一旦发现某一步出错，可以定位到具体环节、回滚到最近的可靠状态，而不是推倒重来。这听起来像工程常识，但绝大多数智能体应用至今还是”黑箱式执行”——成功则已，失败只能从头再来。

四、行业进展：方向对了，差距还很大

值得高兴的是，主流厂商已经开始往这个方向发力。多智能体框架普遍加入了”规划-执行-反思”的循环，模型在每轮执行后会自我检查；一些平台推出了”工具调用追踪”和”可观测性面板”，把智能体的每一步动作记录下来供人工审计；还有团队在做”置信度校准”——让模型在不确定的时候主动说”我不确定”。

但客观地说，这些能力目前还停留在”框架级”和”平台级”，距离”开箱即用的可靠性”还有相当距离。自我反思的深度有限，模型常常在反思环节”自我肯定”——它检查自己的产出，就像让作者自己校对自己的文章，容易形成”盲区”；可观测性工具解决了”看得见”的问题，却没有解决”看得懂”和”改得快”的问题。可靠性不是靠一两个组件就能补齐的，它需要一套完整的工程体系。

还有一个容易被忽略的进展方向是”评测体系”。过去我们评测智能体，看的几乎都是”单轮任务完成率”——给它一个任务，看它能不能跑完。但真正决定可靠性的，是”长链路、多约束、含干扰”的评测：任务中途被中断能不能恢复？输入数据里混入噪音会不会被误导？验收标准写得模糊时，它是追问还是瞎猜？这些评测维度，比单点任务的完成率更能反映一个智能体”靠不靠谱”。已经有机构在发布类似的基准测试，虽然标准还不统一，但至少说明行业开始正视这个问题了。

五、写在最后

如果把智能体比作一个新员工，行业现在的状态是：招到了人，教会了流程，但还没有建立起质量体系和审计制度。新员工能不能干活，取决于流程；能不能把活干好，取决于标准、复核和纠错机制。

智能体的下一场竞赛，不是比谁的模型更聪明，而是比谁更能把”完成”变成”做对”。这不会是一个靠模型迭代就能自动解决的问题，它需要工程师、产品经理和一线用户一起，把可靠性当成一个真正的工程问题来对待。

明天我想继续聊聊，当智能体真的能把事情做对了，企业敢不敢让它”上岗”——那将是另一道坎。