这套系统最初要解决的，不是让多个机器人同时说话，而是让不同工作上下文互不干扰。Amazon 日常运营、广告关键词和日常交流需要的资料、规则与判断方式完全不同；如果都塞进同一个 Agent，记忆越多，边界反而越模糊。
最终落地的是四个 Agent：Main 负责接收、判断和审阅，amazon-work 处理通用 Amazon 运营任务，ad-keyword 专注广告与关键词，casual-chat 则保留一个轻量的日常交流空间。三个飞书群分别绑定到后三个 Agent，每个 Agent 使用自己的 Workspace、Agent 目录和运行状态。
先划边界，再增加 Agent
单 Agent 的问题并不是能力不够，而是上下文会互相借位。一次补货讨论里出现的库存假设，不应该顺手进入关键词分析；日常聊天形成的语气，也不适合影响业务交付。继续堆 Prompt 只能让规则越来越长，却不能真正分开文件、记忆和状态。
多 Agent 的第一步不是写更多 Prompt，而是先决定哪些上下文永远不该混在一起。
因此，拆分依据不是模型，也不是为了凑出几个角色，而是任务边界：输入从哪里来、允许读取什么、需要输出什么，以及结果由谁审阅。
最终采用 OpenClaw 原生 Agent 与 Binding
最初设想过单独写一层群路由器，真正实现时发现 OpenClaw 已经提供了更直接的结构：在 agents.list 中登记 Agent，再用 bindings 把飞书群映射到对应的 agentId。路由关系留在一份配置里，后续新增或调整职责时也更容易检查。
{
"agents": {
"list": [
{
"id": "amazon-work",
"workspace": "~/.openclaw/workspaces/amazon-work",
"agentDir": "~/.openclaw/agents/amazon-work/agent"
},
{
"id": "ad-keyword",
"workspace": "~/.openclaw/workspaces/ad-keyword",
"agentDir": "~/.openclaw/agents/ad-keyword/agent"
},
{
"id": "casual-chat",
"workspace": "~/.openclaw/workspaces/casual-chat",
"agentDir": "~/.openclaw/agents/casual-chat/agent"
}
]
},
"bindings": [
{
"agentId": "amazon-work",
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_group_amazon" }
}
},
{
"agentId": "ad-keyword",
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_group_keywords" }
}
},
{
"agentId": "casual-chat",
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_group_chat" }
}
}
]
}一条群消息如何找到正确的 Agent
- 飞书事件进入 OpenClaw，消息携带 channel 与群聊 peer 信息。
- Binding 用 channel + peer 匹配群聊，并选中对应的 agentId。
- OpenClaw 加载该 Agent 的 Workspace、角色规则、工具说明与记忆。
- 消息在对应 Agent 的状态中继续，不借用其他 Agent 的业务上下文。
- 需要跨领域处理时，由 Main 委派给专业 Agent，再接收产物和证据进行审阅。
这里最重要的一点是：群聊只负责把消息送到入口，业务边界并不写在飞书群名称里。真正决定 Agent 如何工作的，是它自己的 Workspace 和 worker contract。
真正的隔离发生在 Workspace
每个 Agent 都有独立目录，并维护自己的 AGENTS.md、SOUL.md、TOOLS.md 与 MEMORY.md。这样做比在一个总 Prompt 里反复强调“切换角色”更稳定，因为身份、操作规则、工具边界和长期记忆从文件层面就已经分开。
- AGENTS.md：定义职责、工作流程、交付要求和禁止越界的任务。
- SOUL.md：保留表达方式与判断原则，避免每次对话重新塑造角色。
- TOOLS.md：说明可用工具及其使用约束，让能力边界保持可检查。
- MEMORY.md：只沉淀本 Agent 值得长期保留的上下文，不与其他领域混写。
- Agent state：各自保存运行状态，使连续对话仍然停留在正确的工作上下文里。
三个 Agent，不是三份换名字的 Prompt
amazon-work：承接通用运营执行
补货、发货、领星导出、补货编排、工时规划、本地脚本和系统工具任务都进入 amazon-work。它负责把任务真正做完，同时保留输入、输出与处理证据；关键词清洗、反查词映射等工作不会在这里顺手处理。
ad-keyword：把关键词工作做深
ad-keyword 只处理 Amazon 关键词相关任务，包括后台搜索词清洗与分类、自有 ASIN 反查词映射、竞品反查词筛选分级，以及关键词规则与投放建议。范围收窄后，规则文件可以写得更具体，输出也能固定为状态、产物路径、关键统计、证据和异常项。
casual-chat：保留轻量交流空间
casual-chat 不需要背负 Amazon 业务上下文。它保持轻量、直接和自然，日常讨论不会被业务规则打断，也不会把聊天内容带回运营 Agent。这个角色看似简单，却让整套系统的边界更完整。
专业 Agent 负责执行，Main 负责收口
两个业务 Agent 都有明确的 worker contract：接受 Main 委派，在自己的范围内完成实质执行，再把产物和证据交回 Main 审阅。这样既保留专业 Agent 的深度，也避免多个 Agent 同时向最终结果写入不同版本。
Worker contract
接收任务后先判断是否属于自己的职责范围。执行时保留输入、产物、关键统计、异常与证据；信息不足时返回缺失项，不假装完成；任务越界时交回 Main，由 Main 决定是否转交其他 Agent。
任务不完整时，Agent 不会假装已经完成，而是返回缺少的输入、当前状态和下一步；任务越界时，则交给职责对应的 Agent。这里的协作不是让所有 Agent 自由讨论，而是一条有交接标准的工作链。
这套结构带来的变化
- 飞书群本身成为稳定入口，群里的使用方式没有额外学习成本。
- 业务规则可以针对一个领域持续细化，不必担心影响其他对话。
- 每个 Agent 的文件、记忆和状态都能单独检查，问题更容易定位。
- 新增领域时，只需新增 Agent、Workspace 与 Binding，不必重写整条消息入口。
- Main 与专业 Agent 之间通过产物和证据交接，最终结果更容易复核。
回头看，最有价值的并不是同时运行了几个 Agent，而是每个 Agent 都知道自己该做什么、在哪里工作，以及什么时候应该把任务交出去。多 Agent 只有在边界可见、状态独立、交接清楚时，才真正比一个不断膨胀的总 Prompt 更可靠。