是否需要给每一个 OpenClaw 智能体发一张身份证？先把这 3 层身份分清

戴斯特你
0 阅读9分钟

这两个月，关于 Agent 的讨论里有一个问题越来越常见：当 OpenClaw 不再只是单个聊天助手，而是开始跑 workflow、调用工具、分发子智能体、接飞书和浏览器，甚至替你操作文件、日历、文档时，我们是不是该像管理员工账号一样，给每个智能体都发一张“身份证”？

我的判断很直接：**要做身份，但不是所有 OpenClaw 智能体都要一上来就做成 DID。**很多团队一听到“智能体身份”，第一反应就是上 did:key、did:web、Verifiable Credentials，甚至想把所有 Agent 都注册成可验证主体。这个方向不算错，但对绝大多数本地自动化、个人工作流、单团队协作来说，第一步往往做重了。

真正该先补上的，不是“花哨的身份证”，而是 身份分层：

  1. 人格身份：这个智能体对外叫什么、以什么语气出现、扮演什么角色
  2. 系统身份：这个智能体到底是谁，能调用什么工具，签过哪些动作，属于哪个 Runtime
  3. 可验证身份：当它要跨组织、跨系统、跨平台协作时，外部凭什么相信“它真的是它”

只要这 3 层没拆开，你后面无论是接 MCP、接消息渠道、做多 Agent 编排，还是做审计追踪，都会越来越乱。

先分清：人格身份、系统身份、可验证身份不是一回事

先说一个很常见的混淆点。在 OpenClaw 体系里，很多人会把 IDENTITY.md、Agent 名称、头像、SOUL/USER 设定，误认为已经完成了“身份系统”。其实那更接近 人格身份，解决的是呈现和一致性，不是权限和可信度。

第一层：人格身份，解决“你看起来是谁”

这一层更像名片。比如：

  • 名字叫“图文小研”还是“研究助手”
  • 说话偏教程风还是偏运营风
  • 默认处理内容选题、写稿、排期，还是偏代码、自动化、报表

这层当然重要，因为它决定用户跟 Agent 的交互体验，也影响上下文稳定性。但它没有解决下面这些更关键的问题：

  • 这个 Agent 的真实 agent_id 是什么
  • 它当前挂在哪个 workspace、哪个 Runtime、哪个 session
  • 它能不能调 exec、browser、feishu_calendar_event 这类高权限工具
  • 一次删除、一次发消息、一次日程修改，到底是谁发起的

所以，人格身份是前台，不是底盘。

第二层：系统身份，解决“系统内部怎么认出它”

这一层才是 OpenClaw 真正离不开的部分。当你有主 Agent、子 Agent、heartbeat、cron、browser automation、Feishu 渠道、文档发布链路时，系统至少要能稳定回答四个问题：

  1. 这个动作是谁发起的
  2. 它拥有什么权限边界
  3. 它和哪个 run / session / trace_id 绑定
  4. 出事后能不能审计和追责

换句话说，系统身份至少要有这些元素：

  • agent_id：稳定标识
  • session_id / trace_id：知道一次请求从哪里进来、经过了谁
  • 工具权限边界：哪些工具能调用，哪些必须人工确认
  • 签名密钥或等价凭据：让关键动作能留下可验证的签名痕迹
  • 审计日志：把工具调用、参数、结果、时间戳串起来

如果这层没有，智能体越多，系统越像“谁都能代替谁讲话”。这时候你先遇到的不是技术炫技问题，而是排查问题：到底是主 Agent 改了文档，还是子 Agent 改的？是哪个 workflow 发出了那条飞书消息？一次异常的 exec，是合法任务，还是提示词注入后触发的越权动作？

第三层：可验证身份，解决“系统外部为什么信它”

到了这一步，DID 才开始变得有意义。

如果你的 OpenClaw 智能体要做这些事情：

  • 跨团队协作
  • 连接外部 SaaS 或第三方 Agent 网络
  • 在不同组织之间交换任务和结果
  • 需要携带可验证资质，比如“这个 Agent 代表谁”“它是否被授权发文档、发通知、写数据库”

那光有本地 agent_id 已经不够了。你需要一个 能被系统外部解析和验证的身份表达，这时 DID 和 VC 才是合适的那层：

  • DID 负责声明一个去中心化标识及其公钥、服务端点等元数据
  • VC 负责声明某个主体拥有某些被签发的能力或属性

可以把它理解成：

  • agent_id 像公司里的工号
  • DID 像对外可验证的证件号
  • VC 像岗位授权书或资质证明

这三者并不冲突，只是解决的问题不同。

真要落地：给 OpenClaw 智能体配一套轻量身份栈

如果你现在就要在 OpenClaw 里把身份问题做起来，我更建议从“够用、可追踪”出发，而不是一步到位做大一统身份平台。

第一步：先给每个智能体一个稳定的系统 ID

先别碰 DID，先把本地身份做稳。一套够用的做法是：

  1. 每个 Agent 固定一个 agent_id
  2. 每次任务固定一个 run_id
  3. 每个会话和子任务带 session_id / trace_id
  4. 所有工具调用都把这几个字段写进日志

哪怕只是 JSON 日志，也会比“靠上下文猜是谁干的”强很多。

一个轻量的身份记录结构，可以长这样：

{
  "agent_id": "agent.content.ops-01",
  "role": "content-operator",
  "workspace": "douyin-ops-assistant",
  "session_id": "sess_20260324_xxx",
  "trace_id": "trace_publish_001",
  "tool_policy": ["browser", "feishu_create_doc", "feishu_update_doc"],
  "approval_mode": "human-required-on-sensitive-actions"
}

这一步看起来不酷，但它是整个身份栈里很值得先做的一步。

第二步：给关键动作留下签名或不可抵赖痕迹

如果你的 OpenClaw 智能体会做发消息、改日程、发文档、执行命令这类动作，只靠文本日志还不够。至少要让关键动作附带一层签名或摘要哈希，方便后续审计。

你不一定非要上区块链，也不一定非要接复杂 PKI。对很多团队来说，一个更现实的方案是：

  • Agent 持有自己的密钥对
  • 高风险动作输出 action_id、时间戳、参数摘要
  • 日志里记录签名结果和验签信息
  • 网关层统一汇总 tool call audit log

这样做的价值很直接：以后看到一条异常消息，不是只能问“像不像它发的”，而是可以验证“是不是它的密钥发的”。

第三步：把权限边界和身份绑定，而不是只绑账号

很多系统把权限直接绑在 API token 上，但 Agent 时代这会越来越不够用。因为一个 token 可能被多个 workflow 复用，一个 Runtime 里也可能跑多个角色不同的智能体。

更稳的方式是：

  1. 给每个 Agent 定义角色
  2. 给角色定义工具 allowlist / denylist
  3. 对敏感工具额外要求人工确认
  4. 让权限校验同时看 agent_id、角色、session、来源渠道

比如：

  • 写稿 Agent 可以调 feishu_create_doc，但不能直接调高风险 exec
  • 排期 Agent 可以读日历，但不能删任务
  • 报警 Agent 可以发通知，但不能改正文档内容

这样做的核心，不是“多一层配置”，而是让身份真正和能力对应起来。

第四步：跨系统协作时，再把 DID / VC 接上去

只有到了跨系统协作，你才需要把本地身份抬升成外部可验证身份。

一个相对合理的顺序是：

  1. 单机或单团队阶段：先用本地 agent_id + 审计日志
  2. 多 Agent 编排阶段：补 trace_id、provenance、签名
  3. 跨系统调用阶段：引入 did:key 或 did:web
  4. 跨组织授权阶段：再补 VC，表达“谁授予了什么能力”

这样做的好处，是你不会在第一天就为一个本地写稿 Agent 设计过度复杂的身份基础设施。

哪些场景必须做，哪些场景先别折腾

很多人问这个问题，其实是在问预算该花在哪里。我更建议直接按场景判断。

这几种场景，建议尽快补系统身份

  • 一个 OpenClaw workspace 里同时跑多个 Agent
  • 有子智能体、定时任务、Heartbeat、Cron、Browser 自动化
  • 会调用飞书、日历、文档、消息发送这类外部动作
  • 需要做故障排查、审计、权限隔离

这些场景下，你不一定立刻需要 DID，但一定需要稳定的 agent_id、trace_id、日志和权限边界。

这几种场景，再考虑 DID / VC

  • Agent 要被第三方系统识别
  • 需要跨公司协作
  • 需要在多套 Runtime、多个环境间迁移身份
  • 需要把“它是谁、它能做什么”交给外部系统验证

这时候可以认真看 W3C DID 和 VC 模型，而不是只把它们当概念标签。

这几种场景，先别做重

  • 你只有一个本地 Agent，主要帮你写稿或做摘要
  • 还没有多智能体协作
  • 高风险动作本来就都靠人工确认
  • 连基础的 tool audit log 都还没建起来

这种情况下，优先级应该是：先把 Runtime、权限、日志、审批做扎实，而不是先给 Agent 发一张“外部世界根本不会验证”的证件。

一个更实用的判断标准：你是在做展示身份，还是做可信执行

“要不要给每个 OpenClaw 智能体发身份证”这个问题，一个常见误区是把它当成品牌设计题。好像重点是给每个 Agent 起名字、配头像、挂一个 DID，就完成现代化升级了。

但落到真实系统里，身份从来不是展示系统，而是 可信执行系统。它至少要解决三件事：

  1. 识别：系统知道是谁在行动
  2. 授权：系统知道它能做什么
  3. 审计：系统知道它做过什么

如果这三件事还没做好，DID 只是把问题换了一种更复杂的方式重述。如果这三件事已经做好，那么 DID / VC 才会变成加分项，而不是负担。

参考链接

  • OpenClaw 官网：openclaw.ai/
  • W3C DID Core：www.w3.org/TR/did-core…
  • W3C Verifiable Credentials Data Model 2.0：www.w3.org/TR/vc-data-… OpenClaw 智能体都要先发一张身份证，但每一个会真实执行动作的智能体，都应该尽快拥有可识别、可授权、可审计的系统身份。**

把这件事的先后顺序排对了，你后面接 MCP、做多 Agent workflow、接飞书渠道、接外部服务时，成本会低很多；顺序排错了，系统只会越来越像一群“会做事，但说不清是谁在做事”的黑盒。

avatar
文章
阅读
粉丝