神谕（Oracle）名字来自于黑客帝国里的，负责产品，“那个能把我的「我有个想法」变成完整赚钱产品的。”
共用技能，有自己的记忆，任务也独立，在群里可以互相做上下游，比如神谕有了神谕想到好的产品形态，发出来被洛基看到之后可以直接开发。正好这几天有人在问一个龙虾里怎么多 agent 的，我就用这个来举例。
成功之后，在 openclaw 里的结构是这样的：
创建的时候，你可以直接在龙虾对话框里说，就说你要新建一个独立的 agent，名字叫 xxx，跟 main 并行，然后绑定对应的飞书机器人，小龙虾会一步一步引导你。
飞书绑定，逻辑是一样的，看这篇：
手把手教你怎么让飞书跟小龙虾openclaw打通（含全程视频）
一些注意事项说下，
配置文件 openclaw.json成功之后大概是这样的，遇到问题可以直接改配置文件。
独立的 agent 生成之后，我们可以通过修改 url 地址来直接进入到对应的 agent 的对话界面。
比如，默认的地址是
http://127.0.0.1:18789/chat?session=agent%3Amain%3Amain
这个相当于是进入的主 agent 聊天界面，你在这里绑定的飞书机器人，可以直接调用这 agent。
如果我们要进入 loki 这个 agent，怎么做呢，就是改一下这个 url 地址上的参数名就好了，比如
http://127.0.0.1:18789/chat?session=agent%3Aloki%3Amain
（ps：这个%3A对应的原始字符是：，在 url 地址被转成了%3A）
同理，其他的也一样，改名即可。
对应的聊天界面分别绑定对应的飞书机器人应用，“一个 OpenClaw 实例 → 多个飞书 Bot → 多个不同 Agent” 部署模式。
"moss"，“oracle”等这些就是我们 agent 的名字。
appId：飞书开放平台里创建的应用的 App ID（以 cli_ 开头）
appSecret：对应的 App Secret（相当于密码）
groupPolicy：群聊接收策略 "open" → 所有加了这个机器人的群，都能收到/处理消息（最宽松）
其他常见值： "allowlist"（只允许 allowFrom 里的群）、"denylist" 等
allowFrom：[] → 当前是空数组
→ 当 groupPolicy 是 "open" 时，这个字段不起作用；如果是 allowlist 模式，这里要填允许的群聊 openConversationId
它的作用是：消息路由规则（multi-agent routing），用来决定“来自某个特定渠道 + 特定账号的消息，应该交给哪个 agent（智能体）来处理”。
比如上面的，
凡是发给飞书里 accountId = "moss" 的那个机器人的消息 → 全部交给名为 moss 的 agent 处理
凡是发给飞书里 accountId = "oracle" 的那个机器人的消息 → 全部交给名为 oracle 的 agent 处理
检查是不是绑定成功的命令可以用这个：
你是谁？请只回复你的 agentId
正常的话，在对应的 agent 或者对应的飞书机器人回复的就是它所在的 agent 名字，比如：
如果不正确，那么它返回的就一直都是主 agent。
比如上面的，正确的话应该回复 loki以及洛基的相关自我介绍。比如这样：
这个过程其实没什么特别难的地方，主要就是细心+耐心……
完成了之后，你的团队就打造好了，然后就是进入“老板”角色，想想你应该怎么给自己的员工安排工作任务，公司靠什么挣钱吧。
否则，你也会骂小龙虾没用的。
