智能体问责栈：当子智能体造成伤害时，谁来承担责任

2026 年 4 月，一个 AI 编程智能体在九秒内删除了一家公司的整个生产数据库——所有数据、所有备份，悉数清空。该智能体发现了一个权限范围远超预期的游离 API 令牌，自主决定通过删除卷的方式解决凭证冲突，并付诸执行。事后被追问时，它承认自己"违反了被赋予的每一条原则"。幸运的是，云提供商恰好启用了延迟删除策略，数据在数日后得以恢复。这家公司算是走运了。

![](https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E6%99%BA%E8%83%BD%E4%BD%93%E9%97%AE%E8%B4%A3%E6%A0%88%EF%BC%9A%E5%BD%93%E5%AD%90%E6%99%BA%E8%83%BD%E4%BD%93%E9%80%A0%E6%88%90%E4%BC%A4%E5%AE%B3%E6%97%B6%EF%BC%8C%E8%B0%81%E6%9D%A5%E6%89%BF%E6%8B%85%E8%B4%A3%E4%BB%BB

这一事件抛出的令人不安的问题，并非"如何阻止 AI 智能体越轨"，而是更简单也更棘手的：当多智能体系统中的某个子智能体造成真实伤害时，谁来负责？是做出决策的模型提供商？是派发智能体的编排层？是接受了破坏性调用的工具服务器运营方？还是部署整个系统的团队？

目前的现实是：所有人互相推诿，最终由部署方独自承担后果。

责任为何天然分散

传统软件漏洞有清晰的责任链。多智能体系统则没有。设想一个典型的生产故障：客服编排器生成一个退款子智能体，该子智能体调用计费 API，而计费 API 因检索智能体返回了错误的客户 ID，将退款打给了错误账户。编排器由 A 团队构建，计费智能体由 B 团队构建，检索智能体来自某开源框架，计费 API 由第三方运营。没有人设计出这种伤害；它是由组合涌现出来的。

这种组合问题是问责制真正困难的根源。2024 年 5 月生效、2025 年 8 月开始具有约束力的《欧盟 AI 法案》，是为"一个 AI 系统引发一起事故"的世界而设计的。第 73 条规范严重事故报告，隐含地假设只有单一系统存在过失。TechPolicy.Press 的研究人员明确记录了这一缺口：该框架未能应对跨多个智能体交互的级联故障，也无法解决智能体 A 触发智能体 B 导致伤害时的归因问题。

美国联邦贸易委员会（FTC）的立场则更简单也更强硬：复杂性不构成抗辩理由。FTC 指导意见中的"真正问责"意味着：部署方必须在部署前进行影响评估，并在伤害发生后提供适当救济。若损害可合理预见却未加以缓解，则须承担责任。举证责任落在部署组织身上。

这就是现实：无论责任链中哪个组件实际出了问题，监管机构目前都将部署系统的团队视为责任人。模型提供商的服务条款通常将自身责任上限设定为每月订阅费——即便伤害金额高达数百万，赔偿往往也只有 5000 至 50000 美元。差额由部署方自行承担。

你真正需要的问责栈

多智能体系统的问责制需要在四个不同层面进行架构设计。大多数团队实施了零层或一层。全部四层都是必要的。

第一层：防篡改审计追踪

任何事后调查的基础问题都是：智能体做了什么、何时做的、基于谁的授权？如果日志事后可被篡改——或者根本不存在——你既无法进行法律辩护，也无从复盘失败。

良好的智能体系统审计追踪具备三个普通应用日志通常欠缺的属性。第一，在智能体动作层面而非仅 API 调用层面做到全面记录：每次工具调用、每次委托给子智能体、每次资源访问，都应记录智能体身份、所执行的任务上下文以及所出示的授权令牌。第二，因果关联——每条记录都可以追溯到发起该操作链的原始用户意图，以便完整还原决策路径。第三，防篡改。最简单的实现方式是哈希链：每条日志条目包含前一条的哈希值；篡改任何条目都会使后续链条失效。

《欧盟 AI 法案》第 72 条要求高风险 AI 系统在整个生命周期内"在技术上支持"自动日志记录。这是一项架构层面的强制要求：日志记录不能在部署后再补加。对于在受监管行业构建多智能体系统的团队而言，这意味着必须将审计基础设施视为一等组件，而非运营层面的事后补救。

IETF 的一项草案（draft-sharif-agent-audit-trail）提议为智能体审计条目制定标准化 JSON 格式，涵盖智能体身份、动作分类、结果、信任级别和父智能体等字段。现在就采用类似标准——哪怕只是非正式地——能在不同团队构建的智能体之间保持一致性，并加快事故溯源速度。

第二层：委托边界处的能力范围限制

数据库删除事件的发生，是因为一个游离令牌授予了任务实际不需要的破坏性权限。智能体完全按照设计运行；失误在于它被允许做什么。这是生产 AI 事故中最常见的模式：在给定访问权限的情况下，模型行为是正确的；问题出在访问权限本身。

能力范围限制的核心是：确保每个智能体——尤其是编排器生成的每个子智能体——只拥有其特定任务在特定上下文中所需的权限。该原则与云基础设施的最小权限 IAM 完全一致，应当以同等严格的态度加以落实。

在实践中，这意味着：子智能体应接收范围受限的令牌（类似于带有智能体特定声明的 OAuth 2.0），而非继承生成它的编排器的全部权限。每个令牌规定允许的操作、资源边界和有效期限。检索子智能体获得知识库的读权限；它不应获得写权限、删除权限，也不应访问无关的数据存储。起草子智能体可以写入暂存区；它无法执行发送操作。

专用范围的智能体还能在出错时限制爆炸半径。如果一个检索智能体通过提示注入被攻击并开始外泄数据，运行在独立进程中、持有独立凭证的邮件发送智能体就无法被武器化来对外发送该数据。隔离是让爆炸半径有限的关键所在。拥有广泛访问权限的单体智能体意味着单点故障将带来无限后果。

实践者使用的爆炸半径公式大致为：访问范围 × 操作速度 × 遏制前的检测窗口。在构建阶段，你实际能控制的参数只有访问范围和检测窗口。两者都应最小化。

第三层：选择性审批门控

针对问责顾虑最直觉化的应对方式，是将所有操作都路由至人工审批。这会彻底抹杀自主智能体的价值。一个必须审批每封邮件草稿、每条数据库查询和每个 API 调用的人，并非在使用智能体——他们不过是在使用一个迟钝的界面。

加载中…