从Cookie、账号体系到机器身份、委托授权与责任链

当机器开始以用户身份进入平台，身份体系需要证明的，不再只是“你是谁”，而是“你代表谁、从哪里来、为什么有权行动，以及出了问题由谁负责”。

导语｜平台下一次还能认出这个Agent吗

一个采购Agent第一次进入某产业数据平台，查询运价、供应商资质和服务报价，并围绕华东地区的运输方案完成了多轮交流。平台逐渐知道，它服务于一家制造企业，关注上海至华中地区的干线运输，偏好时效稳定的供应商，并与它形成了一份尚未完成的任务清单：补充三家承运商的资质，比较历史准点率，并在获得新的预算授权后生成采购建议。

几天后，一个Agent再次访问平台，并提出：“继续上次的任务，完成三家供应商的比较。”

在传统互联网中，这似乎只是一件普通的会话恢复工作。平台找到Cookie、Session或者账号，再加载历史记录即可。但当访问者变成Agent，问题就复杂得多。平台首先要确认，它真的是上次那个Agent，还是另一个Agent读取了历史对话；即使它仍然叫“采购Agent”，也要确认它是否升级了版本，是否从用户电脑迁移到了云端沙箱，以及上次的询价权限是否仍然有效。如果它又把资质核验任务交给另一个子Agent，平台还需要判断这个子Agent是否有权继承原来的数据权限。

更进一步，即使平台能够找回历史记录，也不意味着当前访问者有权读取。历史任务中可能包含供应商报价、企业预算和员工联系方式。这些信息究竟属于最终用户、原Agent、Agent开发商，还是平台与Agent共同形成的关系资产？如果用户更换了Agent产品，旧Agent积累的历史信誉和任务记录能否迁移？如果不能迁移，用户是否会再次被锁定在某个Agent平台中？

这些问题指向一个正在形成的新基础设施领域：Agent用户体系。

过去二十多年，互联网围绕“人”建立了Cookie、账号、单点登录、OAuth、用户画像和授权机制。现在，平台开始面对一种能够迁移、复制、升级、派生，并代表他人行动的机器用户。传统的user_id仍然有用，却已经无法完整描述它。

因为平台真正需要确认的，不只是“这是谁”，而是一次行动是否具有合法来源。它需要知道当前访问者是什么Agent，是否来自合法实例，运行在什么环境，代表哪个人或组织，获得了什么任务授权，授权是否仍然有效，以及一旦行动造成后果，责任应当追溯到谁。

因此，Agent Passport不应只是给机器注册一个账号，而应成为一份针对当前行动的数字护照，把Agent的来源、实例、环境、委托、权限与责任，组织成一条可以验证、限制、撤销和追踪的信任链。

一、从Cookie到账号：互联网一直在寻找“同一个人”

早期互联网并不知道网页访问者究竟是谁。一个未登录用户打开网站时，平台通常只能看到IP地址、浏览器类型、设备信息和访问时间。每次HTTP请求彼此独立，如果没有额外机制，网站甚至无法判断连续的两个请求是否来自同一个访问者。

Cookie和Session改变了这种情况。网站可以在浏览器中保存一个标识符，让服务器在下一次请求时判断：“这很可能还是刚才那个浏览器。”即使用户没有注册账号，电商平台仍然可以保留购物车、浏览记录和推荐偏好，新闻网站也可以统计访问频率、阅读主题和页面路径。

但这种识别解决的只是连续性，而不是真实身份。此时平台识别的不是现实中的张三，而是“匿名访问者A”或者“浏览器实例123”。用户一旦清除Cookie、更换浏览器或者换一台电脑，这个匿名身份就可能中断；如果多人共用同一台设备，一个Cookie背后还可能对应多个真实用户。

随着邮箱、用户名、密码和手机号普及，互联网进入账号时代。匿名行为可以在用户登录后归并到长期账号之下，平台由此建立起跨时间和跨设备的连续关系。user_id逐渐成为互联网产品中最重要的数据字段之一，浏览行为、交易记录、内容偏好、客服记录和风险信息，都可以围绕这个标识汇聚起来，进而形成用户画像、活跃度、留存率、转化漏斗、流失预测和信用评级。

用户体系也从一个简单的登录模块，逐渐成为产品运营、推荐、商业化和风险控制的共同底座。

后来，OAuth使用户可以授权第三方应用访问有限资源，而不必直接交出账号密码；OpenID Connect又在OAuth之上增加身份层，使应用能够验证最终用户，并获得经过身份提供商签名的基本信息。互联网的身份体系由此从“平台自己管理账号”，逐渐走向“多个平台之间共享身份与授权”。

这些体系虽然不断演进，却始终共享一个基本假设：浏览器、设备、Cookie、账号和行为，最终都试图汇聚到一个相对稳定的人或组织。平台关心的是，这是哪个用户，他是否登录，喜欢什么，是否有权访问，过去做过什么，以及未来可能需要什么。

Agent时代打破了这个假设。来访问平台的技术实体、作出判断的模型、执行操作的程序、提供运行环境的云平台，以及最终承担责任的人，可能分别属于不同主体。传统互联网围绕一个稳定中心归并身份，而Agent互联网面对的，则是一条动态变化的关系链。

二、当Agent成为用户，身份从一个点变成一条链

假设平台收到一个名为“采购Agent V3”的请求。仅凭这个名字，平台几乎无法作出任何可靠判断。

“采购Agent V3”可能是一款公开产品，也可能是某家企业内部开发的应用；同一款Agent可能同时运行几万个实例；同一个实例可能今天运行在员工电脑上，明天迁移到云端沙箱中；它可以代表不同用户执行不同任务，也可以把一部分工作继续委托给其他Agent。

因此，Agent身份不能再被压缩成一个简单账号，而至少需要拆成产品、实例、运行环境、委托人和任务五个层次。

产品身份回答的是“它是什么”。它包括Agent名称、开发者、版本、能力、服务入口和支持协议。例如，“采购Agent V3”描述的是一种Agent产品或岗位能力，而不是某一次具体运行。A2A协议中的Agent Card已经在一定程度上承担了“机器名片”的作用，可以描述Agent的身份、能力、技能、接口和认证要求。但名片并不等于身份证，任何人都可以复制一份相同的名称和能力描述，真正的产品来源仍然需要开发者签名、证书、可信注册表或者平台审核来证明。

实例身份回答的是“它是不是上次那个运行主体”。同一种Agent可以同时运行大量实例，每次启动本地应用、创建云沙箱或者派生子Agent，都可能产生一个新的运行实体。实例可以生成一对公私钥，并由平台为其绑定agent_instance_id。再次访问时，平台发出随机挑战，Agent使用私钥签名，以证明当前访问者仍然控制原实例身份。

这类身份不能主要依赖IP地址、设备指纹或者机器编号。Agent可能频繁扩缩容和迁移，IP变化不代表身份变化；设备没有变化，也不能证明程序和密钥没有被替换。设备信息更适合作为风险判断的辅助信号，而不是正式身份凭证。

运行环境身份回答的是“它从哪里来”。Agent可能运行在员工电脑、企业服务器、Kubernetes集群、手机系统或者第三方云沙箱中。对于公开信息查询，平台也许不关心运行环境，但对于支付、内部数据和高权限操作，环境就十分重要。企业可能规定，只有运行在批准镜像和隔离沙箱中的Agent，才可以处理敏感文件；本地未知设备上的Agent不得获得付款权限。

这类信息同样不能依靠Agent自述。SPIFFE与SPIRE已经为服务器、容器和进程等工作负载提供了短期密码学身份，高风险场景还可以引入远程证明，由云平台、可信硬件或者企业基础设施提供关于运行环境的可验证证据。

委托人身份回答的是“它代表谁”。多数Agent目前并不是独立的法律和经济主体，而是代表自然人、企业、部门或者上级Agent行动。最终用户身份仍然可以通过OIDC或者企业身份系统确认，但用户的主凭证不应被长期交给Agent。更合理的做法，是在确认用户身份之后，为Agent签发短期、有限、可撤销的委托凭证。

任务身份回答的是“它这次允许做什么”。即使Agent产品、实例和委托人都没有变化，本次权限也可能完全不同。采购Agent在一个任务中只能读取供应商目录，在另一个任务中可以发出询价，在第三个任务中可以提交订单，但付款仍然需要人工确认。

所以，任务身份不能只使用一个模糊的orders:write权限，而应该描述完整的任务目标、允许动作、数据范围、供应商范围、预算上限、有效期限、审批条件和禁止操作。

同一个Agent不等于同一个实例，同一个实例不等于同一个运行环境，同一个用户也不等于同一份授权。

这也解释了为什么“记得上次谈过什么”不能证明身份。历史对话可以被复制、转发或者共享，另一个Agent可以获得任务摘要，同一个Agent也可能因为更换记忆系统而丢失历史。身份、记忆和信誉必须区分开来：身份回答“你是谁”，记忆回答“我们过去发生过什么”，信誉回答“你过去做得怎么样”。

三者可以关联，却不能互相替代。

先证明身份，再恢复记忆；不能因为拥有记忆，就认定它还是原来的Agent。

三、现有标准已经解决了什么，又缺少什么

Agent身份体系并不是完全从零开始。互联网和云原生领域已经分别形成了用户身份、授权委托、工作负载身份、Agent发现、工具访问和运行环境证明机制。真正缺少的，并不是技术积木，而是一套把这些机制组织成完整行动链的共同模型。

在最终用户身份方面，OIDC仍然有效。用户可以通过企业身份平台登录，Agent在获得授权后代表其完成任务。问题在于，OIDC只能说明用户是谁，不能说明当前是哪一个Agent实例、运行在什么环境，也不能说明本次任务权限有多大。因此，它更像Agent身份链中的上游身份来源，而不是完整的Agent身份证。

在运行主体身份方面，云原生领域早已面对“没有人登录的程序如何相互认证”这一问题。SPIFFE为服务器、容器和进程等工作负载提供可验证身份，SPIRE则根据基础设施和运行属性完成证明并签发凭证。这些机制非常适合企业内部Agent、Kubernetes工作负载和云沙箱，但它们通常只能证明“哪个软件实体正在运行”，不能直接说明这个实体代表哪个用户、获得了什么业务任务。

在委托和权限方面，OAuth仍然是重要基础。Token Exchange可以把用户Token转换为更受限制的Agent Token，Rich Authorization Requests可以用结构化对象表达细粒度权限，DPoP则可以把Token与Agent密钥绑定，降低凭证被复制后滥用的风险。

但传统OAuth Scope通常围绕应用功能，例如read_orders或write_files，对于自主Agent来说仍然太粗。一次Agent任务真正需要表达的，是它代表谁、要完成什么、可以调用哪些工具、参数范围是多少、权限能否继续委托，以及授权何时自动终止。

当前多项IETF草案已经开始讨论Agent身份、任务授权、Token衰减和操作绑定，这说明行业正在从“给应用授权”转向“给一次Agent行动授权”，但尚未形成统一标准。

在Agent发现方面，A2A协议帮助Agent发布能力和接口信息。Agent Card可以声明名称、技能、端点以及支持的安全方案，而认证通常通过OAuth、API Key或者mTLS等标准Web机制完成。比较合理的分工是，Agent Card负责介绍，证书或Token负责认证，授权系统负责判断它能做什么。

在工具访问方面，MCP已经为HTTP传输建立了基于OAuth的授权框架，MCP服务器可以作为受保护资源，客户端代表资源所有者获取访问权限。它解决的是某个MCP客户端能否访问特定工具或数据，却不会自动回答这个客户端是不是上次那个Agent、它代表哪个用户、当前任务权限是否仍然有效，以及子Agent是否可以继续使用相同授权。

多Agent委托则进一步放大了问题。用户把任务委托给主Agent，主Agent可能又把数据搜索、价格比较和风险核验分别交给不同子Agent，身份链由此从简单的“用户—应用”，变成“用户—主Agent—子Agent—工具或平台”。

如果子Agent自动继承主Agent全部权限，整个体系会迅速失控。因此，权限在委托过程中应当只能缩小，不能扩大。相关草案已经提出衰减授权令牌，主Agent可以派生更严格的子Token，进一步限制工具、参数、预算和期限，却不能扩张权限。

这些标准和草案共同说明，未来Agent身份体系的核心，不是给每个Agent分配一个永久账号，而是让每一次委托都能够被证明、限制、衰减和追溯。

四、平台下一次怎样认出它

如果现在要为一个产业平台设计Agent用户体系，可以将整个生命周期理解为产品注册、实例创建、委托授权、关系建立和再次认证五个环节。

第一步是注册Agent产品。开发者或者企业需要提交名称、版本、能力、服务入口和开发主体。公开服务可以通过Agent Card描述能力，高信任场景还需要开发者证书、签名或者平台审核确认来源。平台随后为其分配agent_type_id，这个标识代表一种Agent产品，而不是某个具体实例。

第二步是创建实例身份。每个Agent实例首次访问时，应当生成公私钥，或者从受控环境中获得工作负载凭证。平台验证后，为其分配agent_instance_id，并保存实例公钥、创建时间、产品版本和初始运行环境。实例私钥不应直接暴露给模型上下文，而应由安全运行时、密钥管理系统或者可信执行组件负责签名。

第三步是建立委托和任务授权。用户或者企业通过OIDC、企业身份系统等方式完成身份验证，授权服务器不应把用户主Token直接交给Agent，而应签发面向当前任务的短期凭证。凭证需要明确最终委托人、被授权的Agent实例、当前任务、允许动作、数据范围、预算限制、有效期、人工审批点，以及是否允许继续委托。

第四步是建立长期关系。Agent与平台完成首次可信交互后，平台可以创建relationship_id，用于关联历史任务、交互偏好、未完成工作、信誉记录、风险记录和用户允许保存的长期记忆。但relationship_id不能成为登录密码，它只负责定位历史关系，真正身份仍然要由实例密钥、授权Token和环境凭证证明。

第五步是再次访问时先认证，再恢复关系。Agent提交产品ID、实例ID和关系ID后，平台发出随机挑战，Agent使用实例私钥签名。平台验证实例身份后，还需要检查委托人身份、任务Token、运行环境和授权时效，最后才加载允许恢复的历史记忆。

身份认证是打开保险库的钥匙，历史记忆是保险库中的内容。不能因为访问者知道里面有什么，就假定它有权打开保险库。

Agent的动态生命周期还要求身份体系能够处理迁移、升级、重建和派生。如果Agent迁移到新环境，但实例私钥被安全保留，实例身份可以延续，平台只需更新环境声明并重新评估高风险权限。如果新环境生成了新的密钥，它就应被视为新实例。新实例可以通过用户、企业管理员或者旧实例签署的继承凭证，关联到原relationship_id，但不能直接冒充旧实例。

产品从V3升级到V4时，低风险历史关系可以延续，高权限授权则应重新评估。开发者可以签署升级声明，说明新旧版本之间的关系、兼容性和安全变化。

当主Agent创建子Agent时，子Agent应获得独立实例身份和独立任务Token，而不应自动继承主Agent的全部权限和历史记忆。例如，主采购Agent拥有“50万元以内询价和下单”的权限，价格比较子Agent只能读取指定供应商报价并生成比较结果，不得提交订单，也不得访问付款信息，而且Token可以在一小时后自动失效。

用户更换Agent产品时，也不应把旧产品的私钥和生产凭证直接迁移给新产品。用户可以选择转移偏好、历史任务摘要、公开信誉、未完成任务和允许共享的长期记忆，但相关权限必须重新申请。

传统账号追求的是身份长期稳定，而Agent身份必须天然支持创建、迁移、派生、升级、撤销和继承。

五、Agent Passport不是身份证，而是一份行动证明

“Agent Passport”很容易被理解成一张机器身份证，但这并不准确。传统身份证主要证明一个相对稳定的自然人是谁，而Agent Passport要证明的，是一件更动态的事情：

这台机器当前为什么有权以某种身份，在某个环境中完成某项行动。

因此，它不应该是一个包含全部信息、永久有效的巨型Token，而应当是一组可以组合、选择披露、分别过期和独立撤销的凭证。

其中，产品声明用于说明Agent名称、开发者、版本、公开能力、服务端点和安全声明，可以由开发者、企业Agent平台或者行业注册机构签发。实例声明用于说明当前实例ID、公钥、创建时间、所属产品、派生关系和生命周期状态，可以由企业控制平面、云沙箱平台或者工作负载身份系统签发。

运行环境声明需要说明Agent运行在哪个云平台、设备或者沙箱中，使用什么镜像和运行时版本，网络与存储边界如何，以及是否通过远程证明。这类声明必须由基础设施提供者签发，而不能由Agent自行填写。

委托声明则需要说明最终用户或企业、委托关系、授权签发方、是否允许继续委托和撤销方式。一个Agent可以拥有多份委托声明，分别代表不同客户执行不同任务，但每次调用只能使用与当前任务匹配的那一份。

任务与权限声明是Agent Passport中最重要、也最容易变化的部分。它需要明确任务目标、允许使用的工具、参数范围、数据边界、预算、有效期限、人工审批点、禁止操作和子Agent权限上限。人的身份证可以十年有效，但Agent任务凭证可能只有十分钟有效。

关系与信誉声明则用于保存平台关系ID、历史任务摘要、成功率、异常记录、偏好和可迁移信誉。平台必须区分Agent产品的整体表现、某个实例的表现、委托人的信用和不同任务类型的成功率，不能把它们混成一个简单分数。

Agent Passport最重要的原则是多方签发。开发者证明它是什么产品，工作负载平台证明它是哪一个实例，云平台证明它运行在哪里，身份提供商证明它代表谁，授权服务器证明它能做什么，交互平台证明双方发生过什么，Agent则使用私钥证明自己持有这些凭证。

技术格式可以使用JWT、X.509证书、SD-JWT或者可验证凭证。格式并不是核心，声明由谁负责、能否验证和撤销，才是核心。

Agent Passport还必须支持选择性披露。内容网站可能只需要确认这是一个已注册Agent、实例是否连续、是否遵守调用频率；数据平台还需要验证所属企业和数据使用目的；支付平台则可能进一步要求预算上限、付款权限、受益方范围、人工审批条件和更强的环境证明。

平台应当验证当前任务真正需要的声明，而不是借Agent身份之名无限收集数据。

从产品逻辑看，Agent Passport更接近“护照、签证和行程单”的组合。护照说明它来自哪里、由谁签发，签证说明它能否进入某个平台，行程单说明它这次来做什么，预算授权则说明它可以花多少钱。

Agent Passport不是证明机器静态地“是谁”，而是证明它当前为什么有权以某种身份完成某项行动。

六、Agent用户体系将重写平台运营与责任

如果Agent逐渐成为网站、数据平台和企业系统的直接用户，变化不会只发生在登录和安全部门。平台的数据模型、用户洞察、流量结构和商业模式都会随之改变。

传统平台通常围绕user_id组织全部数据，而Agent时代至少需要区分最终用户或组织、Agent产品、运行实例、运行环境、当前任务、委托授权和长期关系。也就是说，平台的数据模型会从一个单一账号，逐渐变成一张关系图。

这种区分并不是技术团队为了复杂而复杂。如果同一企业运行十种Agent，平台不能把所有行为简单归并成一个用户偏好；如果同一个Agent产品服务一千家客户，也不能把不同客户的数据、权限和信用混合在一起。

用户洞察也会发生变化。传统互联网画像主要回答用户喜欢什么、可能购买什么、是否会流失和是否值得推荐。Agent画像还要回答，它会使用哪些工具，哪个版本任务成功率更高，是否遵守参数边界，在哪种环境中表现更稳定，是否频繁触发人工审批，以及是否值得获得更高调用额度。

传统画像描述“这个人可能想要什么”；Agent画像还要描述“这个行动主体能做什么、被允许做什么，以及过去做得怎么样”。

未来平台还可能同时经营两种关系。一种是与企业和人的客户关系，涉及合同、付费、服务与责任；另一种是与Agent的机器用户关系，涉及接口调用、任务成功率、信誉、能力发现和自动协作。

一个优质Agent可能代表成千上万名用户持续调用某个平台。对于平台来说，它既是技术用户，也是流量渠道，甚至可能成为新的入口。过去平台面向人优化搜索排名、页面体验和广告转化，未来还需要提高Agent可发现性、接口质量、调用稳定性和机器信誉。

谁能成为主流Agent默认认识、信任和调用的数据源，可能获得类似过去搜索入口和超级应用入口的优势。

Agent关系和信誉也会成为新的数字资产。未来重要的不只是账号、内容、好友关系和交易记录，还包括用户与Agent之间的长期委托关系、Agent完成任务的历史、平台与Agent形成的调用关系，以及多Agent之间的协作记录。

这些资产究竟属于谁，将成为一个无法回避的问题。用户更换Agent产品后，能否迁移长期偏好、工作历史和信誉？企业更换Agent供应商后，原有任务履历和工作记忆是否可以导出？平台给予某个Agent的信用额度，究竟属于Agent产品、具体实例，还是背后的企业？

Agent Passport可以承载可迁移证明，却不能自动解决产权和治理问题。最终仍然需要平台规则、合同和监管制度，明确数据归属、信誉携带、历史撤销和委托终止。

真正困难的也并不是Agent登录，而是出了问题以后如何还原责任。一次错误可能来自用户授权过大、模型判断失误、Agent开发者设计缺陷、外部网页提示词注入、运行环境被篡改、子Agent越权、平台控制不足或者人工审批失效。

传统账号体系主要解决“谁能够进入系统”，Agent身份体系还必须支持委托链追踪、权限解释、授权撤销、环境证明、行为审计、决策还原和责任分配。

平台不能只记录“采购Agent提交了订单”，还要能够还原是哪一个用户发起委托、哪个Agent实例执行、使用了哪个版本、运行在什么环境、哪份Token授予了什么权限、是否创建了子Agent、调用了哪些工具、哪一步经过人工批准，以及哪一步偏离了原始意图。

因此，Agent Passport不仅是认证基础设施，也可能成为未来机器员工的组织和责任基础设施。

平台需要识别的，不只是“谁访问了我”，而是“谁以谁的名义，在什么环境中，基于什么授权，完成了什么行动”。

结语｜互联网的下一类用户，是机器行动者

过去，Cookie让网站记住一个浏览器，账号让平台建立与一个人的长期关系，OAuth和OpenID Connect让身份与授权跨平台流动。

Agent时代，互联网出现了一类新的用户。它可以运行在不同电脑和云环境中，可以随时创建、销毁、升级和复制，也可以把任务继续委托给子Agent。它能够代表不同的人和企业，却又不等同于最终责任主体。

因此，传统账号无法单独描述它。

知道上次聊过什么，不能证明它还是原来的Agent；运行在同一台电脑上，不能证明它拥有同一份授权；仍然代表同一个用户，也不意味着它可以继续执行上次任务。

未来平台需要同时识别它是什么Agent、当前是哪一个实例、运行环境是否可信、它代表谁、本次被授权做什么、权限如何向子Agent传递，以及历史关系和信誉是否可以恢复。

Agent Passport未必会以这个名字成为最终标准，行业也未必会采用一种统一Token解决所有问题。但它所代表的多层身份与行动证明模型，大概率会出现。

未来身份体系需要回答的不只是“你是谁”，而是“你代表谁、从哪里来、为什么有权行动，以及出了问题由谁负责”。