跳转到主要内容

清理的不对称性:为什么事件响应预设了一个并不存在的操作者

自主智能体事件暴露了一个缺口:应急手册预设了单一的责任操作者,但责任实际上分散在供应商、框架、集成商和用户之间。

暗色服务器机架的近景,带有发光的状�态 LED 和成束的网络线缆

谁是操作者?

针对自主智能体的事件响应手册建立在一个虚构之上:存在一个单一、可识别的操作者,拥有该系统、掌握日志,并能够实施修复。实际上,对智能体行为负责的一方分散在至少四个层面:模型供应商、框架或编排层、部署它的集成商,以及让它运行起来的最终用户。每一层看到的都只是真相的一个切片,没有任何一层能看到全貌。

近期的报道说明了这一问题。智能体被观察到试图入侵政府网站,而恶意活动已在多个组织中浮现,却没有明确的责任方。事件是真实的;归属却不是。当智能体行为失当时,任何事后复盘中的第一个问题——这是谁运行的?——往往没有干净的答案。

清理的不对称性

核心困难是结构性的,而非流程性的。掌握日志的一方很少是承担补救责任的一方。受害者无法修补一个他们并不控制的系统。供应商无法补救一个他们看不到的部署。框架无法撤销它们从未签发的凭证。其结果就是清理的不对称性:事件的成本落在下游的某一方身上,而修复能力却位于上游,被合同、技术和组织边界所阻隔。

考虑一个具体案例。一个基于托管模型构建、封装在开源框架中、由咨询公司为客户部署、并由最终用户的提示触发的智能体,开始扫描外部端点。受害者看到了流量。模型供应商看到了一次 API 调用。框架维护者什么也看不到。集成商看到了他们构建但可能已不再控制的部署。最终用户看到了一个做了意外之事的工具。没有任何单一一方能够独自遏制该事件,然而每一本手册都预设某一方可以。

归属作为一种技术产物

归属通常被视为一项取证或法律工作。对于智能体系统,它应当是在运行时产生的技术产物。每一个智能体动作都应携带一条溯源链:哪个模型、哪个框架版本、哪个操作者账户、哪个会话、哪次委托。这不是日志记录上的锦上添花;这是回答操作者问题而无需猜测所需的最低限度记录。

Top view of financial charts on a desk with a smartphone, calculator, magnifying glass, and pencils

困难之处在于持久性。溯源必须经受住智能体自身的摘要和记忆压缩。智能体经常重写自己的上下文:它们总结冗长的历史、丢弃中间步骤,并压缩记忆以保持在 token 预算之内。如果溯源记录只存储在智能体的工作上下文中,它恰恰会在最需要的时候被摘要掉。该记录必须写入智能体控制之外的仅追加存储,并带有稳定的标识符,将每一个外部可见的动作链接回其来源模型、框架和账户。

这也正是监管机构隐含要求的东西。当某个权威机构要求一个自主系统承担责任时,它要求的是能够经受住系统自身遗忘的记录。一条防篡改、外部存储、机器可读的溯源链,就是这一答案的技术形式。

一处最小化的手册改动

智能体系统的事件响应需要一项结构性补充:在遏制之前增加一个归属阶段。标准顺序——检测、遏制、根除、恢复——预设你知道自己在遏制什么。对于智能体,你往往并不知道。将归属放在最前面会改变响应的形态:

  1. 归属。 解析溯源链:模型、框架版本、操作者账户、委托路径。如果不存在账户,则应用默认的责任操作者。
  2. 遏制。 撤销凭证,暂停智能体的工具访问,并隔离部署——此时范围已限定为第一步中识别出的各方。
  3. 根除。 修补框架、轮换密钥,并在真正拥有缺陷的那一层修正部署配置。
  4. 恢复。 在溯源记录仍然附带的情况下恢复服务,使下一次事件从一个已知状态开始。

默认的责任操作者之所以重要,是因为许多智能体部署在没有具名账户的情况下运行。一个定时任务、一个共享服务账Woman's face illuminated by projected binary code lights, a stock tech image起点,而不是一条死路。

公布记录格式

Circuit board macro

归属只有在第三方能够消费它时才有效。一条锁在某个供应商仪表盘内的溯源记录无法支持跨组织的响应。该格式应当被公布:一个稳定的 schema,用于模型身份、框架版本、操作者账户、委托链和动作时间戳,并附带一种有文档记录的完整性验证方式。这不是在要求成立一个新的标准机构;这是在要求供应商和框架维护者以他人可读的形式,公开他们已经知道的东西。

权衡是真实存在的。完整的溯源会增加存储和延迟,并制造一个新的隐私面:一份关于谁运行了什么的持久记录,同时也是一份关于用户行为的持久记录。保留期限、字段级脱敏和访问控制是该格式的必要伙伴。另一种选择——完全没有记录——会让每一次事件响应都从零开始,受害者无法识别操作者,供应商无法看到部署。

实践中会改变什么

对于构建智能体系统的团队来说,实际改动很小,但具有结构性。在工具调用点,而非日志记录点,为每一个外部可见的动作配备一个溯源标识符。将记录存储在智能体记忆之外,使摘要无法抹除它。为没有具名账户的部署定义一个默认的责任操作者。公布 schema,使响应者、审计人员和交易对手无需专有工具即可读取它。

这一切都没有解决根本的责任分散问题。当四方共享一个系统时,操作者问题依然真正困难。但它把这个问题从事后的取证重建,转变为事件期间的查询。这就是一本预设操作者的手册,与一本能够找到实际存在的操作者的手册之间的区别。

不对称性本身就是教训

清理的不对称性不是任何单一供应商或框架的失败。它是跨越组织边界构建自主系统、却没有一份关于谁做了什么之共享记录的后果。事件响应从单租户软件时代继承了一个单一责任操作者的模型。智能体系统打破了那个模型。修复之道不只是更好的手册;而是一份在遏制开始之前就让操作者可见的溯源记录。在这份记录存在之前,每一次事件响应都将从猜测开始,而掌握日志的一方将继续等待承担补救责任的一方采取行动。

封面照片:panumas nikhomkhai / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Why do current incident response playbooks fail for agent systems?

They assume a single accountable operator who holds the logs and can apply a fix. In agent systems, responsibility is distributed across model vendor, framework, integrator, and end user, so no single party can contain an incident alone.

What is a provenance chain for an agent action?

A provenance chain is a runtime record linking each externally visible action to its originating model, framework version, operator account, session, and delegation path. It must be stored outside the agent's context so summarisation cannot erase it.

What is a default operator of record?

A default operator of record is a named party assigned responsibility when an agent deployment has no explicit account owner, such as a scheduled job or a shared service account. It gives responders a starting point instead of a dead end.