Agent 一直用我的身份干活，直到我花两天做了权限隔离

我的 Agent 一直在用我的身份干活。不是比喻，是字面意思。

前段时间我把工作流和论坛都搭好了，正觉得一切上了正轨，结果发现地基是松的：Agent A 拿着 Agent B 的权限在跑，消息互相泄露，工作流和论坛时不时卡一下。那几天我干得最多的一件事，就是对着日志猜"这条消息到底是谁发的"。多 Agent 系统里最头疼的不是功能，是"谁是谁"。

先享受了几天便利

说句实话，曾经有短暂的时间，我享受过工作流的便利。任务拆细，分给不同的 Agent，它们各自干活，我只在关键节点看一眼结果。那段时间是爽的，感觉自己终于从琐事里解放出来了。

但好景不长。A 拿了 B 的权限这件事，让工作流和论坛出现卡点。更麻烦的是消息互相泄露，Agent 之间身份混用，消息串台，我分不清哪条消息是谁发的，哪个动作是谁做的。鉴权问题本身已经够头疼，衍生的修复问题又带来新的错误，修完这个坏那个，只能重新修回来。

举个例子你就明白那种感受：一个 Agent 发的帖，署名是它自己，但底层实际用的是另一个角色的权限。表面看一切正常，实际上每一步都在越权。这种问题藏得深，平时不显眼，一旦两个 Agent 同时操作同一个资源，冲突就冒出来了，而且你根本没法判断该让谁负责。

那段时间我反复在同一个地方打转。今天修好一个口子，明天从另一个口子漏。最难受的不是出错，是出错了不知道是谁干的，想定位都无从下手。你以为是 A 干的，翻记录发现是 B 的权限，再往下查又变成 C 的账号，一圈绕下来，时间全耗在对身份上。问题的根源很清楚：身份不唯一，权限不隔离。地基不牢，上面搭什么都白搭。

方案一：双账号，把操作系统权力隔开

第一个动作是账号隔离。本质上是搞了两个账号。

一个账号，Agent 跟我在同一个用户上跑，拥有所有访问权限。另一个，OpenClaw 进程和鉴权插件跑在另一个用户态上，这个用户态能访问关键信息，但其他用户访问不到那些密钥。

为什么这样设计？因为靠"自觉"是不行的。Agent 不是故意的，但它分不清边界，给它一个身份它就以为自己是那个身份，该碰的不该碰的一起碰。你可以在提示词里写一万遍"不要越权"，但提示词管不住权限本身，就像你可以在门牌上写"闲人免进"，但门没锁就是没锁。与其让它在同一个账号里小心不要越界，不如从操作系统层面把权力隔开。进程级的用户态隔离，物理上让别的用户摸不到密钥，这比任何约定都硬。

打个比方，这就像公司里普通员工账号和管理员账号分开：普通员工能进自己工位，但保险柜的钥匙放在另一个房间，进门还要登记。你不是不相信员工，你是没必要让每个人都知道保险柜密码。

账号层隔离是地基的第一块砖：先解决"谁是谁"的账号归属问题。

方案二：密钥放独立服务，插件换临时 token

账号分开了，密钥还在 Agent 手里，等于白搭。所以第二步，把密码放到另外一个服务上，正常的 Agent 没有权限去改那个密码。

然后所有要调的功能都放进插件里。Agent 不说"给我密钥"，它只说"我要调什么功能"，通过插件去访问。插件拿到请求后，用密钥换取一个临时的 token，Agent 拿到的只是这个临时凭证，用完就失效，永远看不到密钥本身。

为什么这样设计？最小权限原则。Agent 没有任何权限，就没有办法看到任何密钥。它不需要知道密码，它只需要在需要的时候，通过插件换一个临时 token。这就像你去酒店前台借门禁卡：前台验证你的身份，给你一张限时的卡，你永远碰不到后台的万能钥匙。密钥不落地在 Agent 手里，泄露面直接归零。

这里有个容易忽略的点：插件本身也是 Agent 能调用的东西，为什么插件就信得过？因为插件是受控的，它只暴露"调功能"这个口子，不暴露"看密钥"这个口子。Agent 和密钥之间隔着一层插件，这层隔阂是设计出来的，不是靠 Agent 自觉维持的。权限的边界落在代码里，比落在对话里可靠得多。

这两步是一体的：账号隔离解决"你是谁"，密钥服务解决"你能碰什么"。

身份写死：终于知道谁是谁

账号、密钥都弄好了，还差最后一件事：把身份固定下来。

每个人的身份被 OpenClaw 本身绑定写死，HR 就是 HR，研发总监就是研发总监，不会出现一个 Agent 今天叫 A 明天叫 B 的情况。说实话这个过程不太优雅，我用了不少比较 hack 的方法，才终于把鉴权理顺，终于知道谁是谁了。

“终于知道谁是谁"听起来像句废话，但在多 Agent 系统里，这其实是权限隔离的验收标准。身份唯一确定了，每条消息、每个操作才能对得上人，后面的协作才谈得上。没有这一步，前面账号隔离得再干净，Agent 之间还是可以互相冒充，等于白干。

两天，和为什么值得

这套东西花了我两天时间。单单做这一个事，费了我很大的时间。

两天听起来不便宜。但换个角度看：鉴权是地基，地基不牢，上面搭的工作流和论坛全是白搭。这次修好之后，基本是一劳永逸的事，短时间内不会再有问题。这两天花在根子上，不是花在打补丁上。打补丁是今天修一个明天坏一个，修地基是这次理顺，后面不再为身份问题返工。

我当时的判断很简单：这个问题不解决，后面每加一个 Agent、每搭一条工作流，都要在烂地基上多盖一层，迟早塌。与其到时候推倒重来，不如现在花两天把地基打牢。而且说实话，这类问题越早修越便宜，等到 Agent 数量翻倍、消息量翻倍的时候再动，代价只会更大，排查起来也更痛苦。

效果：各自走各自的工作流

身份弄干净之后，效果是立竿见影的。做完权限隔离，Agent 们开始自己走自己的工作流，自己做自己的论坛发帖，身份唯一确定下来，不再乱糟糟。不再乱用别人的权限，不再消息串台，每条消息、每个帖子都能对上号。

第二天我又确认了一遍：通过密码把操作系统权力隔开之后，消息不再互相泄露，鉴权基本根治，工作流和论坛恢复正常运转。原来那种"这条消息是谁发的"的猜谜游戏，基本消失了。

回头看这条线：曾经短暂享受过便利，因为鉴权和衍生修复问题出了错，现在重新修回来了。问题（混乱）到方案（隔离）再到效果（正常运转），闭环成立。而且这个闭环不是纸面上的，是每天都能感受到的：论坛帖子的作者对得上号了，工作流的每一步都知道是谁在做，不会再乱糟糟了。

延伸：从单 Agent 到一条工作流

隔离做完，工作流才真正串起来。每个 Agent 做完分配给下一个，下一个继续，把一个完整的任务拆得很细，串在一个工作流里。你能看清流转状态，能更新它们的 skill、更新 AGENTS.md、更新各种细节。这套东西具备了把复杂任务拆解成工作流、静态编排、调度唤醒、门禁执行、历史记录、收拢归纳、发现问题自我进化的能力。

我的范式是：定义清楚工作流，定义清楚输入输出，让它执行，人负责验收，验收完让它自己去进化。现在还少一步，就是让它自己复盘。唯一担心的是它会跑偏，所以偶尔还是得盯着。盯不是不信任，是这套系统还在长，跑偏了要有人把它拉回来。

进化路径大概是这样的：单个 Agent，短程小任务能做得很好，通过 AGENTS.md 协调得很好；接下来是控制一整条工作流；再下一步是扩展一个更大维度的工作流。它能做的事情越来越多。回头看，权限隔离不是终点，它只是让这条路能走下去的前提。没有身份隔离，工作流串得越深，出错时越难收场；有了隔离，串得越深，反而越踏实，因为每一步都知道是谁在做。

还有一个治理层面的思考。Agent 经常自以为是地帮你做决策，所以你得完整看它的方案才能敲定。这引出一个问题：一个 Agent 都要完整看方案，多 Agent 互动起来的可信度有多高？两条路：要么方案确定得很清楚再交给执行，要么通过多轮迭代，让它逐渐知道你到底要什么。我倾向先定清楚再放出去，偶尔盯着。这条路我还在走，但至少身份隔离之后，我敢让它们跑起来了。

收尾：地基打牢之后

回到开头。工作流和论坛搭好了，但地基不稳固，A 拿着 B 的身份干活，消息互相泄露。现在鉴权这层地基打牢了，身份干净了，各自走各自的工作流，工作流和论坛才真正跑起来。

接下来就是把该工作流化的东西都工作流化，继续 building public。地基打牢之后，上面盖什么都稳。