主体漂移：企业智能体架构中的身份、权限与问责危机

在过去一年中，我审阅了大约二十多家企业的智能体架构，包括银行、零售商、医疗系统以及几家监管机构。这些架构图无一例外地令人印象深刻：MCP网关、工具注册表、向量存储、编排器、策略引擎、可观测性堆栈等模块一应俱全，箭头标识着智能体如何相互发现、共享上下文以及跨网格调用工具。按照2026年的标准，这些图景是任何严肃的智能体部署所必备的。但所有这些图都没有显示：这些智能体是谁？它们代表谁的权威？当它们出错时，谁负责？

这个缺失有一个值得命名的称谓：主体漂移——在任何足够大的智能体系统中，人类权威与实际行动者之间逐渐脱钩。在你部署第一个智能体时看似合理的身份态势，随着智能体的倍增、组合以及寿命超过原始初衷而悄然退化。主体漂移并非三个独立的故障模式，而是一个级联：身份首先崩塌；接着是权限侵蚀，因为不再有稳定的主体来绑定策略；最后是问责消失，因为智能体错误造成的成本落到了事故复盘时谈判地位最弱的团队头上。要阻止这个级联，必须在第一环就进行干预，但目前几乎没有企业智能体平台能做到这一点。

要观察这个级联的运行，我们来看一个最普通的退款智能体。一名客服代表在处理聊天时要求智能体为一件损坏商品处理48美元的退款。智能体检查资格、执行退款并发布更新。审计日志记录了动作由类似"refund-agent-prod-03"的实体执行，该实体运行于客服平台团队拥有的服务主体下。这条记录是真实的，但毫无用处。智能体并非以"refund-agent-prod-03"的身份行动，而是以客服代表的身份，代表客户，沿着一条无人记录的委托链。在构造良好的系统中，客户、客服代表、智能体身份和服务主体应同时记录，可作为链式查询，且持久化于会话之外。但当今大多数生产系统并非如此。这是级联的第一环：身份坍缩为泛化的服务主体，再也没有可绑定的“谁”。

权限侵蚀随之而来。退款智能体拥有一个理论上可退款任何订单的"issue_refund"工具。其权限本应更窄（退款不超过200美元、订单不满90天、信誉良好的客户、超过50美元自动升级），但该权限存在于提示词、YAML文件或团队最近一次在策略变更后便未更新的Notion页面中。运行时强制能力，但无人真正强制权限。当中毒输入或混淆的推理链导致智能体向错误客户退款1800美元时，事后问题“谁批准了此策略”得不到清晰答案，因为策略从未作为工件存在。在高风险场景下情况更糟：想象一个拥有保护分支合并权限的编码智能体，被嵌入代码注释的提示词指示“记录配置值用于调试”，却静默地将秘密外泄到外部监控服务。

接着问责消失。构建智能体的团队声称其遵循策略；编写策略的团队声称未预料到该输入；运营平台的团队表示智能体以服务主体运行，其行为不由他们负责。审计日志可能记录了动作，但未记录产生该动作的推理、塑造推理的检索上下文，以及构建检索的提示历史。事后复盘变成了考古学，成本最终由会议结束时谈判地位最弱的团队承担。

这一切是新的吗？我们有IAM、身份治理、策略即代码、审计追踪、SIEM以及30年的合规实践。为何这不只是IAM的适当实施？因为IAM围绕智能体会违反的假设而构建。IAM和IGA假设主体群体在人类时间尺度上变化：人员入职、离职，服务账户每季度轮换。智能体按会话生成并组合成链，一个智能体调用另一个，后者再调用第三个，通过委托令牌模拟用户，而传统IGA根本无法将之表示为链。策略引擎在动作发生时刻触发，作用于API、数据库和网络。智能体在到达这些执行点之前就已做出最关键的决策——选择调用哪个工具及参数。成熟的审计日志假设重放输入可重现输出，但对于智能体，重放提示和检索可能产生不同动作，因为模型本身贡献了日志未捕获的状态。仪器触发，仪表盘变绿，但静默外泄秘密的智能体依然在运行。审计日志记录动作由"agent-service-01"执行，这同样既真实又无用。

这也正是销售统一堆栈的供应商希望你跳过的地方。微软的Entra Agent ID（当前处于公开预览阶段）是迄今为止最成熟的方案，将为人类和工作负载使用的条件访问、身份治理和身份保护扩展至AI智能体这一新身份类型。谷歌和Salesforce也在构建这一层。营销话术是智能体将获得与劳动力其他成员相同的身份驱动保护。这在解决级联第一环上迈出了实际的一步，但它并非治理——它是一个控制平面，却有着治理平面的营销。条件访问能告知你智能体的访问尝试是否被允许，但它无法告知你智能体在访问尝试之前所做的决策是否在其权限内，为何做出该决策，或者哪个业务单元拥有该决策应遵循的策略。

真正的治理平面必须捕获决策，而非仅捕获动作。一个推理级的审计记录是缺失层的承载基元，它大致如下：

{ "event_id": "refund-2026-05-17-08431", "triggered_by": { "human_principal": "rep:[email protected]", "delegated_via": "support-console-session-9c2a", "customer_principal": "cust:7741289" }, "agent": { "identity": "refund-agent", "version": "v4.7.2", "policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)" }, "task": "Process refund for order 88812204", "retrieved_context": [ {"doc": "order:88812204", "fetched": "2026-05-17T08:43:11Z"}, {"doc": "policy:refund-eligibility", "chunk": 4, "fetched": "2026-05-17T08:43:12Z"} ], "reasoning_trace": "...", "tool_calls": [ {"tool": "check_eligibility", "input": "...", "output": "eligible"}, {"tool": "issue_refund", "input": {"amount": 48.00}, "output": "ok"} ], "action": "refund:48.00", "principal_chain_hash": "0x9e7b3f..." }

并非所有智能体都需要此记录。一个安排会议时间的调度智能体不需要。但移动资金、部署代码或做出监管者最终会过问的决策的智能体则需要，这正是应设置的门槛，因为其关联成本高。推理级审计更接近飞行记录器而非系统日志馈送。存储和查询这些数据成本高昂，且涉及真实隐私问题，因为这些日志包含智能体所见的一切，包括智能体有权读取但审计系统本不应保留的数据。可通过按比例保留来承担成本：高爆炸半径智能体（面向监管、客户资金、合同重大、修改生产）进行完整推理捕获；内部辅助工具进行轻量捕获。

这引出了架构图中未提出的问题：谁构建并运行这些？安全团队可强制策略但无法制定策略；了解退款智能体应被允许做什么的人拥有退款业务而非防火墙；IT可配置身份但无法起草“信誉良好”或编写升级规则。MCP和A2A协议社区在传输级身份和委托方面做了实际工作：MCP提供工具调用溯源，是Entra Agent ID及大多数供应商框架构建的标准；A2A正在趋近跨智能体委托原语。两者都重要，但均不制定策略。连接器由标准而非机构推动。

企业需要一个位于拥有策略的业务单元与运行时的平台团队之间的新职能：称之为智能体运营——一个通常4-8人的小组，嵌入而非集中，向CIO或CISO汇报（取决于内部政治），明确负责维护每台生产智能体的注册表、其命名的人类所有者、版本化的权限规范、推理级审计的保留策略及其生命周期状态。每个智能体经过签署策略的上线审核，按实际节奏审查，并在其初始目标结束时真正退役，而非像当前这样静默地存活于其发起人之后。设计时需防范故障模式，如审查节奏僵化为形式、策略工件滞后于智能体部署速度、或该职能成为智能体被委员会否决而死亡的地方。该职能必须跟上平台团队的速度，否则一个季度内就会被绕过。

这项工作艰巨且早该进行，而监管的时钟正在滴答作响。欧盟AI法案高风险条款今年将进入执行阶段，监管机构会要求可解释性、可追溯性、生命周期记录以及命名的人类问责——这正是智能体运营职能产出的工件。Tyler Akidou在其四月的Radar文章中称此为缺失的HR层；Artur Huk更近期的《从能力到责任》从运行时角度得出了相似结论。标签不如工作重要。本文涉及组织内部的治理；更困难的是跨组织治理，即智能体在不同信任体制下运作。这严格来说更糟，值得另文探讨。

在你自己的四墙之内，诊断一下午即可完成：选取一个生产智能体，尝试用证据回答：它承载谁的权威——从动作回溯到命名的人类？它的权限在哪里说明，谁签署了当前版本？明天它做错事时，谁付出代价，如何决定，以及有什么推理级记录支持该决定？大多数诚实进行此练习的架构师都会得到三个空白和内心的不安。这就是主体漂移——被命名并可见的漂移。

你构建的网格是真实且必要的，但不够充分。其余的架构是其上的制度：注册表、签署的策略、推理级审计、每条链条末端的命名人类。在大多数企业中，它尚不存在，并且不会通过购买另一个平台而到来。你必须自己起草它。