谁该为模型的错误买单：在智能体产品中设计责任机制

一个智能体订错了机票。它给错误的客户发送了道歉邮件。它编写了一个数据库迁移脚本，删掉了一个仍有三个服务在读取的列。在每种情况下，模型都生成了一个看起来合理的动作，执行了它，然后继续运行。而在每种情况下，都有人承担了真实的代价——改签费、受损的关系，或是凌晨 2 点的故障排查。

令人不安的地方在于：大多数 AI 产品对于“谁来承担代价”这个问题没有答案。在设计评审中，这个问题从未被提及。它在以后才会显现，以支持工单的形式，一个接一个地出现在支持队列中——因为客户听起来很生气，而客服代表没有可以遵循的政策，只能即兴提供 40 美元的额度。将此乘以每月几千张工单，单位经济效益就会悄然腐烂——不是因为一次戏剧性的失败，而是因为一个无人关注的缓慢漏洞。

“模型犯了错”不只是一个支持升级。它是一个计费事件。而在智能体时代生存下来的产品，将是那些在收到第一张愤怒的工单之前就为这类事件做好了设计的产品，而不是那些靠感觉即兴退款，直到毛利变为负值的产品。

你在 MVP 阶段就应该构建的责任模型

首先要理解的是，“智能体犯错”并不是一种单一的失效模式。它至少有四种，且分别对应不同的责任方和成本。

• 用户错误。 用户给了智能体错误的指令——日期错误、姓名歧义、或是一个他们实际上并不拥有的账户。智能体完全按照指示行事。
• 模型错误。 指令很清晰，工具也可用，但模型推理能力不足：它幻觉出了一项政策，选错了工具，或者误读了结果。
• 工具错误。 模型的计划是合理的，但下游 API 返回了陈旧的数据、超时了，或者静默更改了接口契约。
• 歧义指令。 准确地说，没人犯错。请求确实支持两种解读，而智能体选择了用户不想要的那个。

责任模型是一个书面规则，针对这四类情况中的每一类，将成本分配给一方：用户承担、公司承担、工具供应商承担（通过 SLA 额度），或者是共同分担。这不只是一份法律文件，更是一份产品规格。它应该与你的定价层级出现在同一份文档中，并且应该在发布之前就存在。

大多数团队在 MVP 阶段会跳过这一点，因为业务量还很小，逐案即兴处理还行得通。但这正是陷阱所在。即兴处理感觉是免费的，因为每笔单独的退款都很小。但它实际上的作用是让你的支持团队习惯于将每个错误都视为一场谈判，这意味着你的退款率现在取决于客户的坚持程度，而不是实际出了什么问题。你无法为此定价。你无法对此进行预测。你也无法告诉投资者你真实的利润率是多少。

这种分类还必须具备“可恢复性意识”，而不仅仅是“过错意识”。在 24 小时取消窗口期内发现的订错机票几乎没有成本。而两天后才发现的同样错误则需要支付全额票价。同样的过错，成本却相差两个数量级。你的责任模型需要一个可恢复性轴，否则它会对一半的案例定错价。

让责任处理变得可行的产品维度

责任模型是一项政策。只有当产品能够提供应用该政策的证据时，它才具有可操作性。以下三个维度承担了大部分工作。

动作级的溯源追踪。 当纠纷发生时，必须有人重建现场——而“智能体做了某事”并不是现场重建。你需要一份带时间戳的结构化记录，记录智能体采取的每一个动作，按任务分组，包括它看到的输入、调用的工具、得到的结果以及连接它们的推理轨迹。没有这些，每一场纠纷都会默认退款，因为关闭一个无法重建现场的工单，最廉价的方式就是赔钱。溯源是让你能说出“用户提供了这个账号”并拒绝退款的依据。它将争论转化为查询。

可逆性层级。 并非所有动作都应该让智能体同样容易地执行。根据撤销动作的难易程度对智能体可以调用的每个工具进行分类：琐碎可逆（草拟消息、暂存更改）、费力可逆（在窗口期内取消预订、发起补偿交易）以及实际上不可逆（发送外部邮件、转账、运行破坏性迁移）。层级应该改变产品的行为——不可逆的动作需要确认步骤、人工审批或硬上限。你可以回滚的错误只是一个麻烦。你无法回滚的错误则是一项债务。将它们统一定价会导致一个 0.02 美元的推理调用变成一笔 400 美元的拒付扣款。

保险式缓冲池。 一旦你能估算出预期的错误成本——见下一节——你就可以将其计入价格。一个按席位或按动作收取的微小缓冲区，用于资助“错误池”，将退款项从不可预测的利润流失转变为预算内、可预测的销货成本。这正是支付处理器和货运公司已经在做的事情。缓冲池还为支持团队提供了一个真实的工具：他们是根据既定政策从定义的池中支出，而不是在拿公司的毛利进行谈判。

估算错误的预期成本

你的 eval 套件可能在报告准确率。但准确率是针对这个问题错误的指标，因为它把每个错误都视为平等的。2% 的拼写错误率没问题。但 2% 的错误率如果是把钱汇到了错误的账户，那就是一个存亡威胁。在准确率仪表盘上，这两者是无法区分的。

你真正需要的指标是每类任务的预期错误成本：对于 Agent 执行的每种任务，其失败概率乘以失败时的美元成本。这将评估从一项及格/不及格的练习转变为一项风险定价练习，并改变你处理结果的方式。

它会告诉你该把可靠性预算花在哪里——不是花在错误最多的任务类别上，而是花在预期成本最高的类别上，而这通常是那些没人关注的低频类别。它会告诉你哪些任务类别还不应该完全自动化，因为它们的预期成本超过了任何缓冲区所能承受的范围。它还为定价提供了真实输入：如果一个任务类别带有 40 美分的预期错误成本，那么定价必须先覆盖这部分成本。

这也是“评估到生产环境”差距影响最深的地方。错误成本不是固定不变的。一次定价调整、一个新的集成、或者客户群体的变化，都可能在不改变失败率的情况下，将特定失败的成本提高一个数量级。预期成本数值必须根据实时流量定期重新计算，否则它会悄然变成虚构的数字——对一个已经发生变化的风险进行的陈旧估计。

法律缝隙：当错误变成他人的法律责任时

内部成本分配是常见情况。但一旦 Agent 的输出影响到金钱或合同，问题就不再是“哪个预算来消化它”，而是“我们是否要承担法律责任”，而答案已经比大多数开发者意识到的更加明确。

在 Moffatt v. Air Canada 案中，一家航空公司的聊天机器人告诉一位悲伤的客户，他可以追溯申请哀悼折扣——而这项政策并不存在。加拿大航空辩称，该聊天机器人是一个独立实体，应对其自身言论负责。审判庭断然拒绝了这一说法：该聊天机器人是加拿大航空网站的一部分，公司对其所说的一切负责。赔偿金额很小，但先例并非如此。你不能免除对 Agent 的责任。如果它代表你发言，它就是你。

对于开发者来说，实际的后果是：任何涉及价格、退款、合同条款或受监管索赔的 Agent 行为，都需要一套足以经受外部审查（而不仅仅是内部调试）的证据链。这比可观测性日志的要求更高。这意味着溯源记录是持久的、防篡改的，并且足够完整，以便第三方在不信任你的话的情况下也能重建决策过程。像支付公司对待交易账本那样对待它，因为从功能上讲，它已经变成了账本。

这也重新定义了“人在回路（human-in-the-loop）”的决策。确认步骤不仅仅是为了减少用户体验摩擦或作为安全网。它是责任转移的时刻。当用户明确批准一个不可逆的操作时，审计追踪记录了谁承担了风险。为了让演示更流畅而跳过这一步，你并没有消除法律责任——你只是悄悄地把所有责任都揽到了自己身上。

错误是一个计费事件

这种心态的转变说起来简单，实施起来却很宏大：停止将 Agent 错误视为客户支持升级，开始将其视为具有明确负责人、记录成本和预算资金来源的计费事件。

具体来说，这意味着在发布前，而非在第一个糟糕的月份之后，要在产品中加入四件事：一份将失败按过错和可恢复性分类的书面责任模型；足以重建任何争议行为的详细溯源追踪；让 Agent 难以独立执行不可逆操作的可逆性层级；以及一个根据实时流量刷新的预期错误成本估算，用于指导定价和资助退款的缓冲资金。

这些工作都不够光鲜，也不会出现在发布演示中。但这决定了你的产品利润率是可以预测的，还是被客户的愤怒程度悄悄决定的。能够持久存在的 Agent 产品，是那些在白板上就回答了“谁来为模型的错误买单”的产品——而不是在队列中通过一次次即兴赔付来被动回答这个问题。