当智能体自主行动，责任该由谁承担？

在企业软件的大部分历史里，问责相对容易理解。一个人登录，一个人拥有一组权限，一个人采取行动。出了问题，通常可以顺着这条线往回查。

智能体AI改变了这一点。我们正从“建议某人该做什么”的系统，转向“能够真正去做”的系统。智能体可以访问工具、调用其他系统、跨多个步骤做决策，并且越来越多地在没有人类逐项批准的情况下运行。这当然正是要点所在。一个每一步决策都需要有人盯着看的系统，算不上真正自主。

但我们交出去的行动越多，一个看似简单的问题就越重要：当智能体做了某件事，到底是谁做的？

这不是哲学问题，而是操作问题。它用的是谁的授权？它被允许触碰什么？谁授予了这些权限？如果出了问题，谁来承担结果？

责任从身份开始

第一个问题是：在你的组织内部，一个智能体究竟是什么？它是否应当始终被视为某个人的代理，代表那个人行动，并继承其某种形式的权限？

这种模型让问责相对直接：如果我的智能体做了某件事，这个行动可以追溯到我。但随着智能体变得更具持久性和自主性，这个模型越来越难以维持。

一个智能体可能会持续运行，也可能服务整个团队而不只是一个人。它执行的那项业务职能，可能在最初配置它的人早已调离之后仍长期延续。在这些情况下，智能体是否应当拥有自己的身份？如果有，谁来创建这个身份，谁拥有它，谁授予它的权限，这些权限又该持续多久？

身份是问责的起点，因为如果你无法可靠地回答“这个智能体是谁”，后续的一切都会变得更难推理。

权限不能是一张静态清单

身份与权限密切相关，但两者并非一回事。设想一个被设计为使用公开信息做研究的智能体。对它来说，使用公共模型、外部工具或公开的模型上下文协议（MCP）服务器，可能完全合理。现在，把同样的能力指向内部财务数据。

智能体本身并没有本质变化，变化的是它所处的环境。

忽然之间，把信息发送给外部模型可能变得不可接受；某些工具需要从它的触达范围内消失；原本可以自由流动的数据，如今落在一个截然不同的合规边界之内。所以权限不能只是挂在智能体身上的一张静态清单。它们需要反映这个智能体是谁、它试图做什么，以及它在什么上下文中运行。

当智能体可以选择不同的工具、在解决问题时走不同路径，而不是遵循完全可预测的工作流时，这一点就更加重要。

委派链会迅速变复杂

现在再加上子智能体。

一个智能体接到目标后，会创建另外几个智能体来完成各部分工作。这些子智能体是否继承父级身份？是否继承其权限？它们的授权是否应当根据所分配的任务而更窄？而它们所做的事最终归谁所有？

可能并不存在一个普适答案，但企业内部必须有一个答案。更重要的是，必须有一条贯穿始终的线索。

一个智能体可以把执行委派给另一个智能体，后者再把任务的一部分委派下去。这不意味着责任可以在传递途中消失。自主性可以分叉，责任不能消失。

企业需要保留最初授权、参与其中的每个智能体、各自携带的权限，以及它们最终采取的行动之间的关联。否则一旦出事，所有人都能参与一场代价高昂的“这是谁的智能体”游戏。

同样的问题也会随时间出现，而不只是横跨智能体链条。设想一个长期运行、持续监控工单并采取行动的智能体。它最终成了日常运营的一部分。然后，创建它的人离开了公司。

智能体留了下来。

现在它归谁？责任是否自动转给了这个人的上级？是否指定了继任者？归团队？归企业？还有那些原本绑定在一个已不在组织中的人身上的权限，又会怎样？

我们已经在管理员工、服务账号和企业应用的生命周期。智能体也需要同等的严肃对待。它们需要一条所有权生命周期，而不仅仅是一条部署生命周期。

责任必须落在系统里

定义所有权，只有在你能重建“实际发生了什么”时才有用。这意味着要把智能体的身份与它的权限、行动、工具、子智能体以及最终结果串联起来。

如果某个环节失败，组织应当能够理解发生了什么、为什么这个智能体被允许这么做、哪些权限使得该行动成为可能、究竟是哪个智能体执行的，以及控制在哪一环失效。正是这些让补救成为可能。

这就是为什么身份、授权和执行追踪不能只存在于政策文件里。写下谁拥有某个智能体，与把这种所有权编码进治理它的系统，不是一回事。告诉智能体不要去访问某样东西，与阻止它访问，不是一回事。让团队在事后拼凑一起事件，与在系统运行时追踪执行过程，也不是一回事。

目标并不是在每个智能体动作前都插一道人工审批。那会抹掉自主性的大部分价值。目标是让人往上走一层：从做每一个具体决策，转为界定自主系统可以做出决策的边界。

随着智能体承担更多工作，企业需要知道它们能做什么、归谁所有、授权如何被委派，以及每一个动作如何被追溯。

因为问题不再是智能体能否行动。而是当它行动时，组织是否还能回答：是谁。