智能体生态观察 · 第 21 篇｜智能体的身份体系：数字身份、DID 与「谁为行为负责」

生态位：智能体要做事，先要「被认出来」

一个智能体要真正替人干活，绕不开一个朴素的问题：对方系统怎么知道你是谁。打开购物网站下单、登录企业内部系统拉取数据、调用第三方 API、替老板给同事发一封邮件——每一个动作的背后，都有一个身份在流动。人类用户的世界里，身份体系已经运转了几十年：账号密码、手机验证码、单点登录、多因素认证、设备指纹，层层叠叠地织成一张信任之网。但智能体进入这张网时，尴尬立刻显现：它不是人，拿不出指纹和刷脸；它也不是传统的程序，不能像服务与服务之间那样用一串 API 密钥礼貌地打招呼。它是一种「像人的程序」，夹在两套身份体系之间——人的体系收不下它，程序的体系又不完全接纳它。

身份是智能体生态真正的底层缺口。工具协议再完善，权限模型再精巧，只要「对方是谁、凭什么信你」这个问题没有答案，智能体的每一次跨界操作都是一次身份冒险。本库此前关于凭据安全的散篇，讨论的是密钥怎么失守、怎么保管；本篇关心的则是更上游的问题——身份的架构怎么搭、行为的责任怎么归属。这不是纯理论问题：浏览器智能体替用户登录邮箱时，用的是谁的账号？自动化抓取内容的爬虫，亮的是什么身份？两家企业各自的智能体互相通信时，如何确认对面不是一台伪装的机器？这些问题的答案，直接决定了智能体能被授权多少、敢走多远，也决定了事故发生后有没有人能被问责。

目前整个行业在身份问题上仍处于「能跑就行」的粗糙状态。多数智能体产品借用了人类的身份体系，少数走了封闭生态的服务账号路线，真正为智能体设计的原生身份基础设施还停留在协议草案与试点阶段。这个缺口既是风险，也是机会——谁先把智能体身份做成可验证、可审计的基础设施，谁就可能成为智能体经济里的认证机构与信任枢纽。

冒充与亮牌：身份呈现的两难

两难的由来

智能体的身份呈现面临一个根本性的两难。一边是亮明身份：坦率告诉对方「我是 AI，代表某位用户来办事」。这在道德上正当，在很多法域也正在变成义务——欧盟人工智能法案的透明度条款要求人在与 AI 系统交互时应当被告知，中国 2025 年起施行的智能体生成合成内容标识相关规定，同样在推动「机器行为可识别」。但亮明身份有实实在在的代价：大量网站对自动化访问采取封禁策略，验证码体系专门拦截机器，电商与票务平台会差别对待非人类会话。一个诚实的智能体可能寸步难行，而一个伪装成主流浏览器、伪造请求头、甚至预置了指纹规避脚本的智能体却畅通无阻。竞争压力天然把产品推向冒充：你不冒充，你的竞品冒充，用户感受到的就是你的产品更难用。

另一边是冒充的系统性风险。冒充人类用户意味着行为无法被正确归因：风控系统把智能体的异常操作算到用户头上，反欺诈体系把正常的委托判定为盗号，出现纠纷时网站甚至不知道该向谁追责。反爬虫产业也在同步升级——Cloudflare 这样的网络基础设施厂商已经把「区分人类与机器人」做成了核心生意，验证码、行为分析、指纹识别层层加码。冒充军备竞赛的结果是双输：网站的反爬成本越来越高，智能体的伪装成本也越来越高，而整条链路的信任基础却在持续流失。

2024 年加拿大航空的聊天机器人赔偿案之所以成为标志性事件，正因为判决触及了这个两难的深层逻辑。一名乘客依据航空公司官网聊天机器人给出的退票承诺行事，事后公司拒绝兑现，并在仲裁中辩称聊天机器人是「一个独立的法律实体」，要为自己的错误承诺单独负责。裁决方明确拒绝了这一说法：企业部署的智能体说了错话，企业担责，乘客最终获得了赔偿。这个案子的深层含义值得每个从业者记住——当你享受智能体冒充人类带来的交互便利，就要接受它的行为被当作你的行为来追责。身份可以伪装，责任伪装不掉。

平台的三种处理

主流智能体产品在身份问题上大致走了三条路。第一条是浏览器代理路线：OpenAI 的 Operator、Anthropic 的 computer use、Google 的 Project Mariner，都是让模型直接操作一个托管浏览器，在真实网页上像人一样点击、填表。此时身份呈现基本沿用老套路——用户的登录态加上对自动化痕迹的隐藏，厂商在用户协议里把越权与违规的责任转回用户。这条路走得最快，覆盖面最广，但身份最浑浊：网站看到的是一个「像人但不是人」的访问者。

第二条是显式应用身份路线：GitHub App、Slack Bot、各类企业系统集成，走的是传统的服务账号体系。智能体以应用身份出现，权限由安装方一次性授予，行为有独立的审计日志，出问题可以精确吊销。这是最干净的一条路，也最符合企业级的合规要求，但适用面窄——它只覆盖有 API、有开发者生态的封闭场景，而现实世界的大量操作（填一张政务表格、查一个没有 API 的内部系统）恰恰发生在没有 API 的地方。

第三条是正在成形的智能体原生身份路线：把「这是一个智能体、它代表谁、它的授权范围是什么、它由谁担责」做成一等公民信息，让服务方在拒绝或放行之前能读到完整的身份声明。目前这条路线还停留在协议设计与早期试点，但它代表了方向——身份不再是需要隐藏的东西，而是可以出示、可以验证的凭证。

DID 与可验证凭据能否救场

密码学界为身份问题准备了很多年的 W3C DID（分布式标识符）与可验证凭据规范，理论上非常适合智能体场景。设想一下完整的形态：每个智能体持有一个自主控制的标识符，由签发方——企业、平台或用户本人——签发可验证凭据，声明「这是张三的采购助理智能体，授权范围为查询与比价，不得下单，有效期至本季度末」。任何服务方都可以用密码学方式验证凭据真伪，而无需依赖任何中心化的账户数据库。这解决了几个老问题：身份可以跨平台携带，授权范围可以被机器读取，凭据可以在出事前即时吊销，责任链上的每一环都写在了凭据里。

但工程落地远比规范设计骨感。DID 体系需要签发方、持有方、验证方三方同时在场才能形成闭环，而今天绝大多数网站根本不是「验证方」——它们只想粗粒度地拦住机器人，没有动力去精细区分「这个机器人替谁办事、权限多大」。智能体场景还提出了新要求：委托链（用户授权给企业智能体、企业智能体再委托给执行子智能体）需要凭据支持多级委派与作用域逐级收敛；长期运行的智能体需要凭据自动轮换与离线验证；跨法域的服务还需要凭据声明与当地法律责任的映射。这些都超出了可验证凭据规范最初为「人的自主数字身份」设计的想象力。规范的完备性掩盖不了生态的冷启动困境：没有网站要求智能体出示凭据，就没有智能体愿意接入；没有智能体接入，网站也没有验证的必要。这个死结，可能要靠少数巨头先在自家生态内把验证做成强制来打破。

OAuth 的 Agent 扩展尝试

比 DID 更现实的是在既有 OAuth 体系上做扩展。OAuth 已经统治了互联网授权二十年，智能体没必要另起炉灶。MCP 的授权规范就建立在 OAuth 之上，让智能体作为标准的 OAuth 客户端获取受作用域限制的访问令牌；行业内也在推进为智能体引入独立的客户端身份——不再冒充用户，而是「用户加智能体」的双主体授权：令牌里同时记录委托人与受托智能体，服务方可以据此做细粒度风控，区分「张三本人在操作」与「张三的智能体在操作」。

支付方向走得更远，因为金钱场景对问责的要求最迫切。Google 牵头的智能体支付协议联合了多家卡组织与支付平台，试图为「智能体替人付款」设计带意图凭证、认证与争议处理机制的专用流程；Coinbase 推出的 x402 协议则尝试用 HTTP 原生的支付状态码让智能体按次付费；专门做智能体支付的创业公司也在涌现。这些尝试的共同思路是一致的：不重建信任体系，把智能体塞进企业世界已经验证过的授权与支付框架，让它成为框架里的一种新客户端类型。这条路能否走通，取决于服务方是否愿意为「智能体客户端」维护单独的信任策略——例如对智能体客户端降低额度、增加确认环节、保留更长的审计窗口。而这又回到了商业动机：只有智能体带来的增量交易足够大，服务方才值得为它做专门的工程。

谁为行为负责：法律与产品的责任链

法律现状

目前各法域的基本共识是：智能体是工具，工具没有独立人格，行为责任归于使用与部署它的人或组织。加航案是这个共识的最近一次确认，也堵住了企业用「机器人是独立实体」来推责的口子。欧盟人工智能法案从透明度与风险分级入手，要求 AI 交互可被识别、高风险场景配置相应义务；中国的生成式人工智能管理办法与内容标识规定，则在训练数据合规与合成内容标注两个方向上划线。真正悬而未决的是委托深度问题：当用户授权智能体「自行判断」执行一系列操作，而智能体的自主决策造成了损害，责任是否随授权深度递减？雇主为员工职务行为担责有成熟的代理法理可依，但智能体不是员工——它没有注意义务，不能被纪律处分，也没有可供执行的财产。法律界的临时方案是类推适用现有框架（产品责任、代理关系、平台服务条款），正式的「电子代理人」立法讨论才刚刚开始。可以预期的是，随着智能体造成的真实损害累积，专门立法会在未来几年内出现，而立法前夜的司法个案将扮演事实上的规则供给者。

产品侧的责任设计

法律没到位的地方，产品设计必须先行。一个负责任的智能体产品至少要回答四个问题。第一，委托范围是什么——权限按任务最小化配置，一次任务一次授权，而不是把用户的全部凭据一次性交出长期持有。第二，哪些动作必须过人工闸门——付款、删除、对外发送、合同签署这类不可逆操作，应当保留显式确认，确认界面要真实呈现将要发生什么，而不是一句「确认执行」糊弄过去。第三，出了事能不能还原——完整的审计日志要记录每一步以什么身份、做了什么、依据的是哪条指令，日志本身要有防篡改保护。第四，损害发生了谁兜底——企业级产品需要明确的责任条款与赔偿安排，而不是把一切推给用户协议里的免责段落。

身份体系的设计目标不是「让智能体看起来像人」，而是「让智能体的每一步都可归因、可审计、可追责」。做到这三点，冒充与否反而降格为一个次要的工程选择。反过来说，如果身份架构做不到归因与审计，产品越成功、跑量越大，累积的责任敞口就越大——今天省掉的每一个确认环节，都是明天索赔函上的一行证据。

从业者判断清单

把本篇的观察压缩成几条可操作的判断。第一，审视你的智能体产品走的是哪条身份路线：浏览器冒充走得快但责任风险大、平台依赖深，应用身份走得慢但干净可审计，能走第二条就不要走第一条。第二，把不可逆动作的人工确认做进架构而不是做进设置项，授权范围按任务动态收敛，宁可多一次点击，不留一处敞口。第三，为智能体会话设计独立的标识与审计通道，别让它寄生在用户的普通会话里——这既是安全需要，也是未来合规的必然要求。第四，跟踪双主体授权与智能体支付协议的演进，服务方越早支持「显式智能体客户端」，越能在新一轮渠道洗牌里占据主动。第五，警惕冒充军备竞赛的长期代价：指纹规避带来的短期便利，最终会以全网验证升级、所有智能体都更难做的形式反噬整个生态。第六，留存好委托证据——用户的授权指令、智能体的执行轨迹、人工确认的记录，出了纠纷，这套证据链就是你的全部辩护。

小结

智能体的身份问题，表面是技术问题，实质是整个生态的信任地基。工具再多、模型再强，如果每一次跨界操作都靠伪装混过去，智能体就永远进不了企业级的正式流程，也永远担不起真正的责任。身份基建的缺位，是当前智能体落地故事里最被低估的一环。

本文梳理了三条现实路径：浏览器代理的冒充路线、封闭生态的应用身份路线、以及 DID 与 OAuth 扩展代表的智能体原生路线。前两条是当下的现实，第三条是方向。原生路线的冷启动困境没有捷径，大概率要靠巨头先在自己生态内强制验证来破局，再逐步外溢成行业惯例。

加航案的判例逻辑值得每个从业者记住：谁部署智能体获利，谁就为它的错误担责，没有人能把责任推给一段代码。身份体系的终极目标不是让机器更像人，而是让机器的行为在数字世界里有一个清晰的、可验证的署名——有署名，才谈得上信用积累；有信用积累，智能体之间的大规模交易才有可能。

下一阶段的分水岭，可能不在模型能力的进步，而在身份基础设施的成熟。当「出示智能体凭据」像今天网站之间「出示 HTTPS 证书」一样成为默认配置，智能体经济才算真正有了地基。在那一天到来之前，从业者的最优策略是：按最严的标准设计自己的产品，等风来的时候，你已经合规。