最近圈里聊得最凶的话题就是个人 Agent 的入口战。一边是 Amazon 把 Muse 摆到台前试图用它在用户和各种 Agent 服务之间当一道门另一边是 Manus 直接给 Agent 发“身份证”让每个智能体都有一个可以被验证、被吊销的正式身份。两个动作看起来不是一个方向其实争的是同一件事个人 Agent 到底从哪扇门进谁说了算。这篇文章我打算把这股“入口热”拆开讲清楚Muse 和 Manus 各自在布什么局Agent 的“身份证”在技术上到底是什么、怎么实现以及一个普通开发者怎么在这波入口战里选边、搭一个带身份机制的个人 Agent。适合正在做 AI Agent 开发、想搭个人智能助手、或者被各种 Agent 平台搞得选择困难的朋友看。1. 个人 Agent 入口战到底在抢什么1.1 入口为什么突然值钱了以前我们说入口说的是浏览器、App Store、微信小程序这类东西核心逻辑是谁掌握入口谁就掌握流量分发和商业变现。现在 Agent 起来了入口的逻辑没有变但载体变了Agent 不是一个页面也不是一个 App而是一个能连续执行任务、能调用工具、能记住上下文的东西。用户把需求交给 AgentAgent 代替用户去查、去订、去写、去操作这个过程中所有数据都从入口流过。入口在这个时候就变成了两层含义。第一层是用户和 Agent 之间的交互入口比如一个语音助手、一个桌面客户端、一个智能眼镜第二层是 Agent 和服务之间的权限入口也就是 Agent 能不能代表用户去操作第三方系统。谁能同时把这两层拿住谁就拿到了个人 Agent 生态里最值钱的位子。所以 Amazon 用 Muse 去占交互入口Manus 用“身份证”去占权限入口本质上是同一场战争的两条战线。1.2 Amazon 用 Muse 守门是个什么打法从公开信息看Muse 是 Amazon 在 AI 助手这条线上放出来的新棋子。它的优势非常明显Amazon 手里有庞大的商品库、成熟的账号体系还有 Echo 这类硬件入口。Muse 站的位置不是自己把所有事情干完而是挡在用户和第三方 Agent 之间先接住用户的请求再调度后面的技能和服务。这个思路有点像以前的总机接线员你打电话进来它帮你转接给对应的人但所有通话记录都从它这里过。这个打法的好处是用户门槛极低你不需要会装 Agent、不需要理解配置只要在 Amazon 的生态里说一句话Muse 就帮你去跑后面的流程。坏处也很明显Amazon 生态的边界就是 Muse 的天花板它更擅长帮你下单、查物流、控制智能家居这种“原生场景”一旦用户想把 Agent 用到购物之外的地方比如写代码、做数据分析、处理私有文档Muse 这扇门就显得不够宽。而且入口做守门人意味着它必须保持中立如果 Amazon 把第三方 Agent 和自家服务放在不对等的位置上开发者迟早会用脚投票。1.3 Manus 给 Agent 发“身份证”解决了什么问题Manus 的打法和 Amazon 正好互补。它不太强调自己是一个入口而是强调自己给 Agent 发“身份证”。这里说的身份证不是让你上传证件照片而是给 Agent 一个可验证、可追溯、可吊销的技术身份。一个 Agent 在云上跑、在本地跑、在别人的平台里跑它怎么证明自己是“我的 Agent”它调用了我的数据平台怎么确认这次操作是经过我授权的出了问题又怎么把某个 Agent 的权限收回这就是身份证要解决的事。我理解 Manus 的动作是在做标准以后个人 Agent 不再是一个匿名的脚本而是一个绑定了持有者、有权限范围、有过期时间、可以被撤销的实体。这听起来不起眼但对 Agent 生态非常关键。没有身份机制的时候Agent 就是一个有了钥匙的自动程序钥匙能开哪扇门、能不能复制、丢了怎么挂失全部是糊的。有了身份证Agent 才从“工具”变成了“数字世界的合法受托人”。1.4 守门员和发证员哪个更接近终局现在把两种路线放在一起看其实各有各的命门。守门员路线的短板是中立性Muse 如果深度绑定 Amazon 的商品和服务第三方 Agent 就很难真心实意地接入发证员路线的问题是生态启动慢身份证再规范如果没有足够多的平台承认它它就是一张没人验的证件。表格里列一下我现在的判断对比维度Amazon Muse 路线Manus 身份证路线核心资产用户场景、硬件设备、账号体系身份协议、任务执行、开发者生态主要优势即开即用绑定购物与家庭场景通用性更强适合复杂任务和跨平台协作主要风险生态封闭中立性存疑标准落地慢需要平台配合验证对开发者意义接入成本低但有平台依赖可以做独立 Agent但要自己构建身份层我个人更看好两者最后会走向融合入口者必须开放身份协议发证者也需要一个默认的入口来承接用户。真正决定胜负的是谁能先让用户形成“我的 Agent 就在那里”的习惯。2. 给 Agent 发一张能用能吊销的“身份证”技术拆解与最小实现2.1 身份证里到底该装哪些信息先澄清一件事Agent 的“身份证”不是把现实身份证号变成 token也不是让用户上传证件照。它在工程上是一个身份档案通常包含这几个字段agent_idAgent 的唯一标识类似身份证号但只在数字空间有效。holder持有者标识也就是这个 Agent 属于哪个用户或哪个组织。public_keyAgent 的密码学公钥用于验证这个 Agent 发出的请求真正来自它。scope权限范围比如“能读日历”“能发邮件”还是“只能查天气”。expires_at凭证过期时间防止一个身份的寿命无限延长。revocation吊销状态被取消的 Agent 不能再代表用户操作。关键点是 public_key 和 scope 这两个字段。public_key 解决的是“你证明你是你”scope 解决的是“即使你是你你也不能什么都干”。两者配合身份机制才有意义。在设计的时候还要注意不要把私钥、用户隐私数据这类敏感内容塞进身份证里。身份证只负责证明身份不负责存储你的秘密。2.2 用代码实现一个最小可用身份组件我按自己常用的方式写了一个极简的 Agent 身份组件。没有依赖复杂框架只用 Python 标准库加上 cryptography 库。它做的事情很简单创建 Agent 身份、生成身份凭证、对请求签名、验签。import json import time import uuid from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import serialization class AgentIdentity: def __init__(self, agent_name: str, holder: str, scope: list[str]): self.agent_id str(uuid.uuid4()) self.agent_name agent_name self.holder holder self.scope scope self.private_key rsa.generate_private_key(public_exponent65537, key_size2048) self.public_key self.private_key.public_key() self.created_at int(time.time()) self.expires_at self.created_at 3600 # 默认1小时有效 def profile(self) - dict: return { agent_id: self.agent_id, agent_name: self.agent_name, holder: self.holder, scope: self.scope, public_key: self.public_key.public_bytes( encodingserialization.Encoding.PEM, formatserialization.PublicFormat.SubjectPublicKeyInfo ).decode(), created_at: self.created_at, expires_at: self.expires_at, } def sign(self, request: dict) - dict: payload json.dumps(request, sort_keysTrue).encode() signature self.private_key.sign( payload, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256() ) return { request: request, agent_id: self.agent_id, signature: signature.hex(), timestamp: int(time.time()), } def verify_request(signed: dict, profile: dict) - bool: if signed[agent_id] ! profile[agent_id]: return False if profile[expires_at] int(time.time()): return False public_key serialization.load_pem_public_key(profile[public_key].encode()) payload json.dumps(signed[request], sort_keysTrue).encode() try: public_key.verify( bytes.fromhex(signed[signature]), payload, padding.PSS(mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.MAX_LENGTH), hashes.SHA256() ) return True except Exception: return False这个代码的核心逻辑是Agent 在发请求之前用自己的私钥对请求内容签名别人拿到请求后用身份档案里的公钥验签。只要验签通过就能确定请求确实来自这个持有私钥的 Agent而且内容没有被篡改。timestamp 和 expires_at 用来防止一个签名被无限重放。我实测下来的一个坑是签名必须对序列化后的完整请求内容进行不能只签一个 id 或哈希。否则请求里的某个字段被人改了验签依然通过身份机制就白做了。另一个坑是时间同步本机时间和服务器时间差太多签名明明是对的也会被当成过期建议部署时统一通过 NTP 校准。2.3 为什么不能只靠 API Key 或 OAuth有人会问这事不是早就有了吗API Key 就是一把钥匙OAuth 也允许用户授权第三方应用访问数据Agent 直接用这两样不就够了问题在于API Key 和 OAuth 都是为人设计的不是为 Agent 设计的。API Key 是静态的只要 Key 不泄露它永远有效。Agent 一旦被攻击者拿到 Key攻击者就能一直冒充这个 Agent而且你根本不知道是哪一步泄露的。OAuth 解决了用户授权的问题但授权对象是“应用”不是一个持续运行的 Agent 实例。Agent 和普通应用的区别在于它会主动做决策会一步一步调用多个工具每一步都需要向目标系统证明“我现在代表谁、拥有哪些权限”。说个生活化的类比API Key 相当于家门钥匙谁拿了钥匙都能进门你不会知道是本人、是朋友还是小偷用的OAuth 相当于业主写了一张门条“允许张三进客厅”但张三进客厅之后干什么或者张三把门条给了李四你都管不到。Agent 身份证更像是“钥匙 指纹锁 访客登记”锁只认 Agent 本人的签名每次进门都有记录访客权限到点自动失效。2.4 安全边界和隐私风险怎么划身份机制是安全的基础但只做身份不做权限控制等于只确认了“来人是谁”却没规定“来人能碰什么”。我建议在个人 Agent 项目里把权限控制分成三层来解决。第一层是声明权限范围。Agent 启动时就只能声明它需要的 scope比如“读日历”和“写日历”是两个不同的权限绝不为了省事直接给“全部权限”。第二层是运行时检查。Agent 每调用一个工具身份组件都先检查这次调用是否落在 scope 里不在就拒绝。第三层是敏感操作二次授权。涉及支付、删除、对外发布这类动作即使 Agent 有权限也应该弹一个人工确认避免模型幻觉导致不可逆操作。隐私方面最容易翻车的是把 Agent 记忆和身份凭证放在同一个文件里。Agent 会记住用户的日程、聊天记录、工作文档这些都是高敏信息身份凭证一旦和记忆一起被拖库等于连“你的 Agent 是谁”和“它替你记住了什么”一起泄露。我在自己的项目里把两者分开存放身份凭据放独立的密钥目录记忆进单独的数据库至少做到泄露其中一个不会全盘失守。3. 自己动手做一个带“身份证”的个人 Agent选型与落地3.1 先问清楚自己到底要哪种入口动手之前先别急着下代码把需求想清楚比什么都重要。个人 Agent 的入口目前有三种比较典型的形态各有各的适用场景。第一种是设备入口。你希望 Agent 长在某个硬件或系统里比如智能音箱、车机、眼镜、桌面客户端。优点是触发自然缺点是换设备就换入口身份和记忆跟设备绑定换机成本很高。适合追求“喊一声就能用”的人。第二种是任务入口。你希望 Agent 解决的是“帮我做完一整件事”比如收集资料生成周报、管理日程并预订会议室、定时监控网页变化并输出摘要。这种形态对入口设备不敏感重点在任务编排能力和工具调用链Manus 这类通用执行型 Agent 就是典型。第三种是身份入口。你希望自己有一个统一的 Agent 身份无论它跑在哪个平台上都能代表你操作其他系统。这种形态最适合重度用户和开发者但需要自己投入不少技术成本。我的建议很简单如果你只想用选一个体验顺手的任务入口先把日常两三个高频流程跑起来如果你想认真做别选纯黑盒选能导出身份和配置的宁可初期麻烦一点也不要三个月后被一个入口锁死。3.2 做一个能跑通的最小 Agent 骨架抛开各家平台一个自带身份机制的 Agent 骨架其实不复杂。核心就三块身份模块、技能注册表、任务调度循环。下面是我在本地跑通的一个最小实现模型部分我用的是 OpenAI 兼容接口方便切换不同供应商。import asyncio from agent_identity import AgentIdentity # 技能注册表每个技能都声明自己的权限范围 SKILLS {} def register_skill(name: str, scope: str): def decorator(func): SKILLS[name] {func: func, scope: scope} return func return decorator register_skill(read_notes, read:notes) async def read_notes(path: str): with open(path, r, encodingutf-8) as f: return f.read() register_skill(save_markdown, write:notes) async def save_markdown(path: str, content: str): with open(path, w, encodingutf-8) as f: f.write(content) return fsaved {path} register_skill(summarize, run:llm) async def summarize(text: str): # 这里替换成你自己的模型调用 return fsummary of {len(text)} chars任务调度循环就是每次从输入里解析出要调用的技能和参数先查权限再执行。权限检查我放到调用之前不是放在注册时原因是同一个技能可能在运行中改变使用场景每次调用都检查更安全。我实际跑下来的最大教训是给 Agent 建模时应把每一次任务看成“行程”而不是“一次性函数调用”。一个任务可能需要多次调用技能、中间失败重试、最后汇总结果。如果只写一个简单的循环遇到中间某一步返回异常整个任务就断了。可靠的写法是给任务一个状态机明确记录 pending、running、retrying、done、failed 五种状态并把任务状态持久化到本地这样进程重启后还能接着跑。3.3 记忆、工具调用和权限模型怎么设计没有记忆的 Agent 是记性不好的临时工干完活就忘。但记忆也是最容易失控的部分。我建议把记忆分成两层会话级短期记忆只用于当前任务任务结束就清掉长期记忆按主题存储例如“用户偏好”“项目背景”“常用地址”并且长期记忆的写入要经过规则审核避免模型把幻觉内容当成事实存下来。工具调用的核心是模块化。我常看有人把 Agent 的所有能力写在一个大函数里代码越堆越长最后连自己都不知道它会干出什么事。正确的做法是像上面代码里那样每类能力做成独立技能每个技能声明自己的权限 scope。模型只负责决策调哪个技能、传什么参数技能内部怎么做由开发者控制。这其实也是 agent skill 机制最值得学的地方把能力边界显式化比事后补救安全得多。权限模型要结合具体场景。我的一个简单实现是把操作分为三类只读类比如读文件、查网页Agent 可以直接执行写入类比如保存笔记、更新文档执行前记录日志危险类比如发邮件、删除文件、调用付费 API必须通过人工确认。这里有个细节人工确认不能放在技能内部要放在调度层统一处理否则每个技能都要写一遍确认逻辑很快就乱套。3.4 并发和可靠性个人 Agent 也要扛并发很多人觉得个人 Agent 一个人用根本不需要考虑并发。这个想法我踩过坑。一个人用的 Agent 也会同时面临多个异步任务正在等一个大模型返回又来了一个定时任务要处理或者用户同时发了好几个请求Agent 必须决定先做哪个。如果没有并发控制轻则请求超时重则任务互相写同一个文件。我给个人 Agent 采用的最简单可靠方案是任务队列加有限并发 worker。具体做法是用 asyncio.Queue 收集任务一组 worker 从队列里取任务执行同时限制最大并发数。async def run_with_limit(tasks, limit3): semaphore asyncio.Semaphore(limit) async def wrapped(task): async with semaphore: return await task return await asyncio.gather(*[wrapped(t) for t in tasks])这里信号量限制的是并发数量不是请求频率。如果你调的模型 API 有每分钟请求限额还要在调用侧做速率限制。另外每个外部调用必须设置超时我用模型调用和工具调用统一加超时默认 30 秒重试一次。没有超时的任务最危险一次网络抖动就能让整个 Agent 卡死。可靠性方面我强烈推荐把任务队列持久化。最简单的做法是每来一个新任务就把它以 JSON 形式写进本地队列文件执行完再标记完成。这样即使进程崩溃重启后还能从断点继续不会出现用户以为任务已经完成、实际上根本没跑的情况。3.5 本地部署、云 API 还是混合方案关于部署我分三种情况说说自己的测试结果。纯本地方案用的是本地大模型比如用 Ollama 跑一个小参数模型。优点是隐私好、离线可用、没有按量计费缺点是模型能力有限复杂任务表现不稳定。个人 Agent 如果只需要做信息整理、文件操作这类轻任务本地模型完全够用。纯云 API 方案用 Claude、GPT 这类云端模型能力强但按 token 计费而且你的所有请求内容都会经过第三方。个人 Agent 如果处理的是公开信息问题不大如果涉及私人笔记和公司文档至少要做脱敏。混合方案是我现在最推荐的本地模型处理日常简单任务云 API 处理需要强推理能力的复杂任务敏感数据只在本地处理脱敏后的摘要才发给云端。身份模块一定放在本地私钥不出本机。成本上我实测下来个人日常使用混合方案每月大概几十块人民币主要是云 API 的零星调用费比纯云方案省很多也比纯本地方案好用很多。4. 个人 Agent 落地时的常见问题与排查实录4.1 身份凭证校验失败卡在“进门”这步这是自建身份机制以后最常遇到的问题。现象很直接Agent 明明用自己的私钥签好名对方系统却返回验签失败。按我自己的排查顺序先看三个地方。第一看时间。签名里带的时间戳和对方服务器时间差超过允许范围就直接拒绝。这个问题在本地测试时经常出现因为笔记本可能长时间没开机系统时间漂了。第二看公钥格式。发出去的 profile 里 public_key 是 PEM 文本从数据库读出来时可能被加了空格或换行符导致反序列化失败。第三看请求内容。签名是对排序后的 JSON 做的如果发送端和接收端对请求的序列化规则不一致哪怕差一个空格验签都会失败。我建议一开始就给身份组件写几个自测用例用同一个 AgentIdentity 签名后立刻验签、篡改请求后验签失败、过期后验签失败。全部跑通再往上接业务能省很多半夜排查的时间。注意身份凭证的有效期不要设太长。个人 Agent 本地跑的时候设 12 小时差不多超出就重新签发。设太长会让吊销机制失去意义设太短又会影响长任务执行。4.2 Agent 任务执行到一半就中断了任务中断的原因五花八门最常见的是模型调用超时、工具返回格式不符合预期、进程崩溃。我遇到过最离谱的一次是Agent 在写月报时调用了一个网页转 Markdown 的技能网页结构里有一个超大表格模型在解析时直接输出超长文本把上下文窗口塞满整个任务就好似“断片”了。处理思路就一条把任务从“一次函数执行”改成“可恢复的状态流”。每个任务拆成多个步骤每完成一步就记录状态和结果。中断后重新启动读取状态从上次失败的步骤继续。我给技能调用加了三步重试逻辑第一次失败只是警告第二次失败自动换一个等价技能第三次才放弃并把错误写进任务报告。数据方面也做了保护技能本身不直接写业务文件而是先把结果写到临时目录全部成功后再原子替换。这个习惯帮我少丢了很多数据。4.3 工具调用越权与敏感操作保护Agent 权限把关再严也会出现越权场景。一次实测里我让 Agent 汇总一下某个项目的资料它看完文档后顺手调用了“发送邮件”技能打算把汇总结果发给项目成员。单独看每一步都在合理范围但整体行为已经超出用户预期。这就是模型幻觉叠加工具自主调用的典型风险。后来我把敏感操作全部改成了“先斩后奏”的反面先问后做。调度层识别到 Monza 里带有“send”“delete”“pay”“publish”这类动作词时强制进入确认流程。最好用的办法不是自己在代码里做语义判断而是在模型 prompt 里明确说明哪些技能需要用户确认同时在调度层硬编码一份危险技能白名单。Prompt 管住大多数情况白名单兜底双保险。4.4 多 Agent 协作时身份互认怎么处理一个 Agent 不够用的时候自然会想上多 Agent一个负责资料收集一个负责写作一个负责质检。这时每个子 Agent 都得有自己的身份但它们的身份和主 Agent 的身份不能是独立的否则没有归属关系出了事不知道追到谁头上。我给自己的多 Agent 设计用的是父子身份模型。主 Agent 有一个根身份每个子 Agent 的身份在创建时携带一个 parent_id 字段指向主 Agent。验签的时候不仅验子 Agent 自己的公钥还会向上验证它是否属于一个合法的父身份。这个模型实现的成本很低但排查问题的时候非常有用一旦某个子 Agent 出错立刻能定位到它属于哪条任务链、由谁创建、声明的权限范围是什么。暂时不需要用太复杂的去中心化身份协议本地项目里一个 parent_id 加一张信任表就足够了。4.5 现在到底该选 Muse、Manus 还是自研这是后台被问得最多的问题。我给不出一个标准答案因为选择取决于你自己属于哪类人。如果你完全不写代码核心诉求就是把日常任务交给 Agent我建议先用 Muse 这类生态内入口。它把购物、订票、家居控制这类高频场景做得足够顺滑先让它替你扛下 80% 的场景比折腾自研踏实得多。等真正出现了它做不了的事再补别的工具。如果你愿意写一点代码又想省事Manus 这类通用 Agent 值得认真用起来。它更像一个通用执行层配合身份体系适合把跨平台的流程串起来。我目前的用法是让它在“收集资料—整理初稿—调用本地技能保存”这类任务里当主力。如果你是开发者或者想长期把个人 Agent 握在自己手里别犹豫自研一个小骨架是最好的投资。不需要做得多大身份管理、技能注册、任务调度这三块跑通你就已经比 90% 的 Agent 用户更理解这场入口战在争什么。最核心的资产不是入口本身而是你对 Agent 身份的掌控力。最后分享一点我自己的体会这次把身份机制和个人 Agent 骨架一起搭下来我最深的感受是身份体系这种东西一开始越嫌麻烦后面越要加倍还债。我第一次做的时候图省事直接用了一个固定 token 当身份凭证后来想加权限作用域、想支持多个设备同时使用、想吊销某个设备上的 Agent才发现固定 token 让所有改造都很难办最后只能推倒重来。如果你也想自己搭个人 Agent请一定从第一天就把 agent_id、公钥、scope 这一套设计进去。入口战谁来当最终赢家现在下结论太早。Amazon 有场景Manus 有身份但真正决定你体验的还是你自己对 Agent 的控制方式。先把手头一个流程跑通再把身份和权限想清楚剩下的交给时间就好。