最近这段时间，AI圈里最不缺的就是新品发布，但真正让我愿意花时间反复琢磨的，是围绕"个人Agent入口"的一场暗战。一边是Amazon这样的大平台在筑墙，想挡住Muse这类新锐Agent进入用户视线；另一边是Manus这种通用Agent在做身份体系建设，相当于给Agent发"身份证"。一个在堵门，一个在发证，两件事放在一起看，入口战的真实规则就浮出水面了——争的不是谁的对话框更好看，而是谁掌握用户的信任，谁决定Agent能被谁用、能在哪儿跑。这篇文章我会从入口形态的变化、Agent身份认证的技术逻辑、开发者如何把身份落地，以及混战中的生存策略四个角度展开。如果你正在做Agent开发，或者准备把业务接进Agent生态，这篇值得看完。
1. 入口战在抢什么：从URL到对话框，入口已经换了三次形态
要理解"Amazon挡住Muse"为什么是个大事，先得退一步，看看入口这个东西是怎么演变的。入口从来不只是"用户从哪进来"的技术细节，它决定了谁先生成流量、谁分配流量、谁从流量里抽成，本质上是经济权力的分配机制。
1.1 三次变道：网页、App、Agent
先说Web时代。那时候入口是URL，门票是SEO和内容质量。任何人注册个域名，做出有价值的内容，就能被搜索引擎捞出来，流量天然是开放的。你不需要向任何人申请存在资格，只要能被人搜到，就有机会。这个时代的特点是低门槛、弱控制、去中心化。
到了移动互联网时代，入口变成了应用商店和超级App。分发权从"搜索引擎"转移到了"应用商店+超级App"，随之而来的是审核、抽成、排名、限流。你做一个App做得再好，上不了架、不被推荐，基本就凉了。更典型的是超级App里的"小程序生态"——表面上你开发的是自己的产品，实际上你的生杀大权捏在平台手里，平台想给你一个入口就是一个入口，想关你的入口也是一个规则调整的事。入口不再免费，而是变成了税，这一步大家都有深切体会。
现在到了Agent时代，入口又变了。用户越来越少直接去点按钮、逛页面，而是开口说一句话：帮我订机票、帮我查资料、帮我比价、帮我整理会议纪要。谁接住这句话，谁就掌握了用户接下来的所有操作链路。对话框，或者说"智能体会话"，正在成为新一代入口。而且Agent入口和前两次有个本质区别：网页时代用户自己逛，App时代用户自己选，Agent时代用户是"委托"——用户并没有明确点开某个服务，而是让Agent替自己决定调谁、用什么、怎么执行。这意味着入口的"话事权"进一步前移了。
1.2 Amazon挡住的不是Muse，是"流量改道"
想明白入口形态，再回头看"挡住"这件事就清楚了。
Amazon这类平台最怕的不是多一个竞争对手的产品，而是用户的操作起点被截走。过去用户要买东西，打开App，搜索，浏览，下单，整个链路都在平台内，平台可以推荐、可以加购、可以赚佣金和广告费。但如果用户的日常操作变成了"先跟Muse说，让Muse决定调哪家服务"，那Amazon就从一个"用户主动逛的地方"降级成了"被Agent调用的一个接口"，甚至可能被直接跳过。这不是多了一个渠道的问题，而是整个流量入口被绕过的问题。
所以大厂会筑墙：不开放搜索接口、限制Agent调用频率、在审核上针对性设卡、对自家Agent给更多权限和更低费率。这些动作在移动互联网时代也发生过，本质上都是同一个逻辑——谁掌握入口，谁就掌握经济分配权。唯一不同的是，Agent时代的大厂筑墙难度更高了，因为Agent的调用是程序化的、可编排的、可动态切换的。你封了一个端点，Agent可以换一个服务商；你今天限制了这个能力，明天用户就改用另一个Agent。
1.3 会话、能力、信任：入口战有三个战场
入口战并不是单一维度，至少要分三层来看。
第一层是会话入口。用户默认找谁聊天、让谁代理自己的任务。这一层拼的是Agent本身的能力、响应速度和口碑，很残酷但也最容易被追赶。今天你觉得某个Agent好用，明天另一个Agent推理能力更强，用户就迁走了。会话入口的忠诚度极低，因为切换成本几乎为零。
第二层是能力入口。Agent能调用多少服务、能调多深，取决于平台开放了多少API、接入了多少工具和第三方插件。这一层拼的是生态厚度，谁的工具多、数据全、接口稳，Agent就好用。这也是为什么各家都拼命做Plugin、Skill、Tool生态——能力入口就是Agent世界的"基建配套"。
第三层是信任入口。用户敢不敢让Agent帮自己付钱、发邮件、改订单、访问隐私数据。这一层拼的是安全体系、身份认证、责任追溯、赔付承诺。三层里面，前两层已经打得白热化，但第三层才是决定性的——因为如果没有信任，用户根本不敢把关键任务交给Agent，场子再热闹也只是玩具。这也是为什么我会特别关注"发身份证"这件事，它恰恰打的是信任这一层。
2. 为什么"身份证"会成为入口战的胜负手：Agent天生没有"脸"
Manus给Agent发身份证这个动作，如果只看表面，会觉得是个品牌营销动作；往深了看，它碰触的是Agent生态最要命的问题——信任从哪儿来。
2.1 Agent天然没有"脸"，所以必须靠证明
人和人打交道，靠的是脸、声音、历史信誉、社会关系。App之间打交道，靠的是账号体系和登录态。但Agent是什么？Agent是一段持续运行的程序，它可以半夜替你做事情，可以同时跑在多个平台上，可以一个实例服务多个用户，也可以多个实例代表同一个用户。它没有物理面孔，没有客服工号，没有信用历史，它的存在本身就是一串代码。
问题就出来了：当Agent跑到某个第三方平台面前说"我要替我的用户下单"，平台怎么知道这句话是真的？它怎么知道这个Agent确实是用户委托的，而不是某个黑客写的钓鱼程序？它怎么知道Agent拿到了多少授权，有没有权限下单超过一定金额？这些问题的答案，靠的不是Agent自称是啥，而是靠一套可验证的身份机制和凭证体系。这就是"身份证"的用途。
2.2 "身份证"的技术底座：标识符、密钥、可验证凭证
把Agent身份证拆开看，核心是三样东西。
第一样是唯一标识符，业内标准做法是用DID（去中心化标识符）这类格式，给Agent一个全球唯一、不依赖任何单一平台的身份编号。这个编号相当于身份证号，代表"这个Agent确实存在、可被寻址、可被验证"。DID的优势在于它不是某一家平台发的号，而是基于公钥体系的全局标识，平台想注销它也注销不了，只能选择信或不信。
第二样是公私钥对。Agent持有一把私钥，对外公布公钥。每次Agent对外发起请求时，用私钥给消息签名，对方用公钥验证签名，就能确认这条消息确实来自这个Agent、没有被篡改。这相当于身份证上的照片和防伪水印——你没法把别人的照片贴到自己的身份证上，因为一验就穿帮。
第三样是可验证凭证。凭证由权威机构签发，声明"这个Agent属于某某用户，被授权做某某事，授权有效期到什么时候"。对方收到凭证后可以验签，确认凭证真的由签发机构发出，然后决定是否放行。这相当于身份证上的"签发机关"和"有效期限"。
这三层加在一起，才构成一张完整的"身份证"：标识符回答"你是谁"，签名回答"你怎么证明是你"，凭证回答"你有权做什么"。缺任何一层，都只是残缺的身份方案。
2.3 三种身份方案对比：从账号冒充到可验证凭证
我在实际项目里见过团队用不同的方式解决Agent身份问题，效果天差地别，可以先做个对比：
| 方案 | 信任来源 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 简单账号模拟 | 平台登录态 | 实现快 | 无法证明请求方是哪个Agent，极易伪造 | 内部Demo |
| API Key/Token | 调用方持有密钥 | 集成简单 | 粗粒度、难吊销、泄露难追溯具体会话 | 早期SaaS接口 |
| 可验证凭证（VC+DID） | 密码学签名+权威签发 | 可验证、可撤销、跨平台 | 实现成本高，需要身份服务支撑 | Agent生态、开放平台 |
从表格能看出来，前两种方案不是不能用，但都缺一个东西：可审计性。API Key泄露了你只能改Key，但你说不清到底是哪个Agent、哪个用户、哪次调用造成的问题。可验证凭证的方案，让每一次调用都有签名记录、有凭证背书，出了事能追溯到源头。入口战越激烈，第三方平台对"可追溯"的要求只会越高，这也是为什么"身份证"会成为关键棋子——它不是锦上添花，是开放生态的门禁。
3. 给Agent办"身份证"的落地设计：注册、授权、验证一整套链路
聊完道理，说说怎么干活。如果你正在做一个Agent项目，身份这块可以按下面的链路来设计，每一步都有实际要处理的技术细节。
3.1 Agent身份的生命周期：从注册到吊销
第一步是注册。为每个Agent实例生成唯一ID和公私钥对，把公钥、Agent元信息（名字、版本、所属方）登记到一个身份服务里。这步看起来简单，容易被忽略的是：ID要全局唯一、密钥要存储在安全模块或密钥管理服务里，而不是写在配置文件里然后提交到代码仓库。我见过不止一个团队把私钥硬编码进Docker镜像，这种问题一旦出一次，信任就全完了。
第二步是绑定。Agent必须和用户建立授权关系，常见做法是走OAuth 2.0的授权码流程：用户先登录自己的账号，看到Agent申请的权限列表，点击同意，系统给Agent签发一个授权令牌和身份凭证。这样第三方平台看到这个Agent请求时，能明确知道：Agent是A，用户是B，B授权了A做C事。这个模型在很多大厂内部已经跑通，关键是你要把"Agent身份"和"用户身份"分开建模，不要混在一个Token里。
第三步是运行期验证。Agent每次调用第三方API，都携带签名后的请求、授权令牌、身份凭证。第三方先验Agent身份，再查授权范围，通过才执行。这里建议引入时间戳和nonce（随机数），防止重放攻击——攻击者把Agent的一次合法请求复制一遍再发出去，如果没有nonce和时间窗校验，就相当于拿到了免死金牌。
第四步是轮换与吊销。密钥要定期轮换，权限要能动态调整，用户要能随时撤销某个Agent的全部授权。吊销机制在设计时就要预留好，否则上线后再补，改造代价非常大。很多系统上线时只做了"发证"没做"销证"，结果Agent被换掉之后旧身份还在飘，这是非常常见的隐患。
3.2 授权模型：不要让Agent变成脱缰的野马
给Agent授权，最容易犯的错误是"图省事——给一个全量授权"，让Agent可以访问用户所有资源。结果一旦Agent被注入恶意指令，或者模型幻觉导致操作偏差，后果是灾难性的。你想想，如果一个Agent能读你所有邮件、能删你所有云盘文件、能替你支付任意金额，那它一次犯错就足以让你崩溃。
正确做法是最小权限原则，按操作类型做Scope。这块的Scope建议用结构化格式描述，例如：
{ "agent_id": "did:agent:example:abc123", "user_id": "user_001", "scopes": [ "email:read", "calendar:read", "email:send:confirm", "payment:single:under500" ], "issued_at": "2025-06-01T00:00:00Z", "expires_at": "2025-06-30T00:00:00Z" }每个Scope都要有独立的授权确认和审计记录。还有一个细节：高风险操作尽量引入即时确认，Agent执行支付类操作时，弹给用户一个二次确认，而不是让Agent默默搞定一切。这会让体验稍微繁琐一点，但在信任建立的早期阶段，值得。
3.3 跨平台互认：入口战真正的终局牌
身份系统单独在自己平台里跑通，只能算是内部工具。真正有价值的是跨平台互认：一个Agent在Manus体系里拿到的身份凭证，到了其他平台也能被验证、被信任。这件事的难度不在于技术，而在于各方愿不愿意接受统一的信任锚。
实现上需要两样东西：一个公共的DID解析服务，让任何平台都能查到某个Agent的公钥和状态；一个受信任的凭证签发体系，让凭证具备跨平台的可验证性。验证流程大概是：第三方平台收到Agent请求 → 解析DID → 获取公钥 → 验签 → 查凭证 → 比对Scope → 记录审计。这七个步骤每一步都有现成的开源库可参考，难点在工程化地把它们串起来、做到低延迟高可用。
我看到有些团队的架构是：自己做Agent产品，同时再搭一层身份适配层，对外统一输出DID、凭证和验证API。这样无论入口平台怎么换，Agent的身份是稳定的。你想想，如果用户的一个Agent，带着身份证，能在Amazon、在第三方工具、在垂直服务商那里畅通无阻，那谁还关得住它？这才是"发身份证"真正的战略意图——用身份打破入口封锁，让Agent成为用户自带的"通行证"，而不是某家平台的"住户"。
4. 入口混战下开发者的生存法则：四件事先想清楚
最后聊聊在这个混战局面里，开发者应该怎么办。我自己接触过想做Agent产品的团队，也接触过想接入Agent生态的SaaS服务商，有几条经验可以分享，都是踩过坑换来的。
4.1 先定位：你是做Agent本身，还是做Agent的"身份证"
第一件事，团队要非常清醒地定位自己。入口战最忌讳的就是什么都想要，最后什么都没占到。
如果你做的是Agent产品，你的命根子是单次会话的质量和用户口碑，你的竞争维度是"会话入口"。那你必须时刻关注各大平台的政策变化，比如Amazon这类平台一旦收紧API，你的Agent能力就会受限，要有Plan B，甚至Plan C。你的护城河是用户习惯和场景覆盖，而不是某个平台给你的接口权限。
如果你做的是中间层——身份服务、凭证签发、适配层、审计服务，你的命根子恰恰是"不站队"。你服务所有Agent，不管它是哪个生态的，你反而能在入口战里以中立方身份活下来，而且活得越久越值钱，因为信任基础设施需要时间积累和事故检验。
两种定位没有优劣，但最怕的是混着做。要么押注一个生态冲入口，要么做所有人需要的信任基础设施，两头都想占的结果通常是两头都做不深。
4.2 四件必做的基础设施清单
不管哪种定位，下面四件事都是Agent项目的安全底线，建议在动手写业务逻辑之前先搭好框架：
第一，身份服务。至少做到能注册Agent ID、签发密钥对、验证签名。这是"发身份证"的最小闭环。优先用现成的开源DID方案，别自己发明一套ID格式，否则后面互认的时候会很痛苦。
第二，授权与审计。授权要有Scope，审计要记录每次调用的主体、对象、操作、结果和令牌指纹。出事能追溯，这是和第三方平台谈判的底气。审计日志要防篡改，最好是只追加、不可删除的存储方案。
第三，多入口适配层。别只适配一个平台的协议。做一个统一的协议转换层，把外部平台的消息协议、鉴权方式、工具调用格式，映射到自己的内部模型。这样换平台只是加一个适配器的事，不用重写Agent。我见过团队因为只适配了一个平台，平台改版后整个Agent瘫痪了两周。
第四，数据最小化与日志脱敏。Agent在处理用户数据时，只提取完成任务必需的最小字段；日志里不要记录完整令牌和敏感原文。这既是安全要求，也是跨平台信任的基础——第三方平台审核你的Agent时，第一件事就是看你的数据边界是不是清晰。
4.3 五个坑，每个都有人替你踩过
第一个坑是把身份等同于登录。登录解决的是"用户是谁"，Agent身份解决的是"这段程序是谁、替谁干事、有什么权限"，两者不是一回事。我见过团队做完了完整登录系统，结果Agent一被攻击，第三方根本定位不到具体是哪个Agent干的，因为日志里只有用户名没有Agent标识。
第二个坑是权限给得太粗。一上来就给Agent全量API权限，省事一时，出事一世。最小权限+细分Scope+动态调整，才是真正的省事。记住，权限收得越紧，Agent被恶意利用时的爆炸半径越小。
第三个坑是密钥不轮换。Agent实例长期跑着，密钥长期不变，生命周期越长，泄露概率越大。定个策略，比如每90天轮换，并做好无缝切换，别因为怕麻烦而省略。密钥轮换这件事，做一次就觉得麻烦，做三次就成了习惯，不做就是一个定时炸弹。
第四个坑是只适配一个入口。今天押注A平台，明天A平台改政策，你整个产品就被动。多入口适配不是锦上添花，是生存必需。哪怕你只主攻一个入口，也要留好适配层的扩展点。
第五个坑是没有审计就直接上线。很多团队觉得审计是"以后再说"的事，但等到真出问题时，没有审计记录就等于没有证据。大平台在接入你的Agent前一定会审核这个能力，到时候临时补审计系统，既仓促又容易出现数据盲区。
我个人这两年最大的体会是：入口战短期看产品，中期看生态，长期看信任。Agent的对话框谁都能做，但让用户放心把"数字分身"交出去、让第三方平台愿意信任你的Agent，才是真正的护城河。在实际操作中，我建议你哪怕从一个小Agent做起，也先花两天把"这个Agent是谁"的问题想清楚。注册身份、日志留痕、最小权限这三件事，比接几个花哨API重要得多。等入口风向变了，手里有可信身份的Agent，走到哪儿都有门进。
