OpenClaw 多 Agent 实战：一人一个 AI 助手

一、问题：团队的 AI 助手，不该是"公用一台"

给团队引入 AI 助手，最常见的做法是买一个账号、大家共用。刚开始没问题，人一多就出问题了：

• 上下文互相污染——A 的对话历史里混着 B 的业务内容，AI 时不时"记错人"
• 权限无法区分——财务数据、客户名单，谁问都能拿到
• 无法定制——蔬菜岗需要价格日报，水产岗需要周报，共用一个助手只能迁就通用能力
• 追责困难——出了问题不知道是谁问的、哪一步错的

更实际的问题是：**不同岗位需要的东西根本不一样**。让所有人共用一个"什么都懂一点"的助手，等于让所有人都不好用。

我们最终采用的方案是：一人一个 Agent。目前团队里跑着 12 个 Agent，其中 6 个是同事的专属助手。

二、方案：一人一个 Agent，微信直达

核心思路很简单——每个同事配一个独立 Agent，绑定他自己的微信。他在微信里发消息，就是跟自己的助手对话。

这种方式的好处是零学习成本：不用装 App、不用记网址、不用学新界面。同事本来就在用微信，现在只是多了一个联系人。

三、怎么建：一条命令

OpenClaw 的 Agent 创建走官方默认配置就够了，不需要手写配置文件：

openclaw agents add zhangsan-agent --workspace ~/.openclaw/workspace-zhangsan-agent

系统会自动完成这些事：

• 创建独立工作区目录
• 生成基础文件：AGENTS.md、SOUL.md、IDENTITY.md、USER.md、TOOLS.md、HEARTBEAT.md、BOOTSTRAP.md
• 建立会话与状态目录
• 模型继承全局默认，不用单独指定

想要中文显示名，补一条：

openclaw agents set-identity --agent zhangsan-agent --name "张三的Agent"

然后是绑定微信——这一步必须在网关所在机器的真实终端里跑，因为要现场出二维码让同事扫：

openclaw channels login --channel openclaw-weixin
openclaw agents bind --agent zhangsan-agent --bind openclaw-weixin:xxxxxxxx-im-bot
openclaw gateway restart

一个微信号只能绑定一个 Agent。新同事必须用自己的微信，不能复用别人已绑的号——这既是技术限制，也是隔离的前提。

四、关键设计：技能该共享还是该独占

Agent 建好之后，真正需要想清楚的是技能怎么放。这不是小事，放错了要么同事用不上，要么凭据泄露。

OpenClaw 的技能发现是目录扫描，位置决定可见范围：

这里有一条硬规矩：

含凭据的技能一律放同事自己的 workspace 里，绝不放进共享目录。

原因很直接：共享目录里的技能，全部 12 个 Agent 都能读到——包括里面的邮箱密码、API Key、数据库连接串。放进共享目录，等于把凭据发给了所有人。

技能的目录名就是技能 id，每个技能是一个目录，核心是 SKILL.md 加辅助文件。写技能时有两个要点值得强调：

• 绝对路径写死——Agent 不做相对路径推断，脚本、配置、日志全部写全路径
• description 写触发词——比如"发蔬菜日报""今天蔬菜价格"，让 Agent 能对号入座

另外技能里要明确写上"禁止编造数据，取不到就显示无数据"这类约束——不写的话，Agent 在拿不到数据时会倾向于编一个出来。

五、从"能用"到"好用"：技能迁移的实践

我们做的事，本质上是把通用能力裁剪成岗位能力。

比如原本有一套"农产品价格报告"的通用技能，迁给具体同事时要做的不是复制粘贴，而是：

• 裁剪掉不属于该岗位的部分——蔬菜岗不需要水产周报的段落，留着只会让 Agent 困惑
• 沿用该岗位已有的命名习惯——同事原有技能叫某个系列，新技能就顺着命名，保持一致
• 先验证数据链路，再谈发送——调取数函数确认能拿到数据就够了，真实发信留到同事首次使用时。给同事邮箱发测试信之前，一定先问一声

最后一条尤其重要。自动化流程最容易出的事故就是"测试邮件发给了真实收件人"——在同事眼里，那封测试邮件就是一次系统故障。

六、最容易被忽略的：人设文件

每个 Agent 的工作区里那几个文件（SOUL.md、IDENTITY.md）不是摆设，它们决定了助手怎么说话。

这带来一个很实际的好处：同一个能力底座，可以有不同的"性格"。

• 给严谨岗位的助手，说话简洁、只给结论、附数据来源
• 给需要沟通的岗位，可以更耐心，把步骤拆开讲
• 甚至可以按同事的偏好调整——有人喜欢一次给全，有人喜欢一步步来

这是"一人一个 Agent"相比"共用账号"最大的隐性价值：不只是隔离，还可以定制。

七、小结

回到最初的问题——团队怎么用 AI？

我的答案是：不要给团队一个 AI，要给每个人一个 AI。

这套方案在真实团队里跑下来，几条经验值得记下：

• 零门槛接入比功能强大更重要——微信直达让同事真的会用，再强的能力藏在网页里也没人点
• 技能位置决定可见范围——共享目录图省事，但含凭据的技能必须隔离
• 权限靠架构保证，不靠自觉——一人一 Agent、一个微信绑一个号，隔离是结构性的
• 人设文件值得花时间——它决定了同事愿不愿意继续用

实施这类方案时，最忌讳的是"先建个共用的试试"。一旦大家习惯了共用，后面再拆分的成本要高得多——历史对话、使用习惯、技能归属全都要重新理。要建就一开始建对。