单 Agent 的天花板

在用单个 AI 助手处理日常工作时，几个问题会反复出现：

  • 上下文混乱：同时处理代码开发、文档整理、技术调研，所有对话混在一个会话里，AI 很容易搞混当前任务
  • 缺乏专业分工：一个 AI 什么都做，但什么都做不精
  • 长对话后的"人格分裂"：对话过长后，AI 可能忘记之前的角色定位，出现前后矛盾的回复
  • 无法并行处理：多个任务只能串行推进，效率低下

多 Agent 系统正是为了解决这些问题：每个 Agent 专注一个领域，拥有独立上下文，可以并行工作，角色定位稳定。

团队架构：四个角色，各司其职

整个团队设计了 4 个角色，借鉴了中心化管理的思路：

卡卡西（Main Agent）— 总指挥

负责任务调度与分配、Discord 看板管理、团队协调、验收和质量把控。接收用户需求后，评估复杂度，决定自己处理还是分配给执行 Agent。它是用户和执行 Agent 之间的唯一沟通桥梁。

鸣人（Code Agent）— 代码执行

模型选择：GPT-5.3 Codex High。Codex 专为代码任务优化，对编程语言、API、框架的理解更深入。负责代码开发、Bug 修复、技术方案设计和代码审查。

佐助（Researcher Agent）— 深度思考

模型选择：Claude Opus 4.6。Opus 是目前推理深度最强的模型，适合复杂分析和方案设计。负责技术调研、方案评估、策略分析。配置了 tavily-search、context7、browser-use、youtube-ultimate、openviking、github 等技能。

小樱（Obsidian Agent）— 知识管家

模型选择：Claude Sonnet 4.6。负责文档整理归档、知识库管理、内容创作发布、笔记同步。配置了 obsidian、notion、wechat-gzh、twitter-sync、youtube-ultimate、openviking 等技能。

模型选择的逻辑

不同角色用不同模型，核心考量是三个维度：

  • 专业性：Codex 在代码任务上比通用模型表现更好
  • 推理深度：Opus 推理能力最强，适合需要深度思考的调研分析
  • 成本效益：Sonnet 性价比高，文档处理这类任务不需要最强推理能力

让专业的模型做专业的事，同时控制总成本。

协作协议：防止多 Agent 混乱的关键

这是整个系统设计中最重要的部分。没有明确的协作协议，多 Agent 系统很容易出现用户被多个 Agent 同时轰炸、Agent 之间互相调用形成无限循环导致 token 爆炸、任务状态混乱等问题。

核心规则：

  1. 执行 Agent 永远不直接联系用户——所有与用户的沟通都必须通过 Main
  2. Main 是唯一的沟通枢纽——接收需求、分配任务、验收工作、汇报结果
  3. 执行 Agent 之间不直接沟通——需要多 Agent 协作时，由 Main 逐个召集协调
  4. 标签管理统一由 Main 负责——执行 Agent 不能自己更新 Discord 任务状态

这个设计借鉴了传统公司的管理模式：清晰的汇报线、避免越级沟通、统一的信息出口。虽然去中心化听起来很酷，但在实际运行中，中心化协调带来的效率和流程清晰度要高得多。

需求不明确时的处理流程也很关键：

简单讨论时，Agent 在 thread 内提出方案选项，然后通知 Main 评估决策。复杂协作时，Agent 说明需要哪些角色参与，Main 作为协调者逐个召集，讨论完成后由用户审核方案。只有系统故障、安全问题、或 Main 超过 2 小时未响应且任务紧急时，才允许执行 Agent 直接联系用户。

配置文件设计：简洁配置 + LLM 智能

OpenClaw 的配置文件体现了一个核心理念——不要试图用详细指令控制 LLM 的每一步行为，而是定义清晰的框架，让它在框架内自主决策。

SOUL.md — Agent 的灵魂

用自然语言描述 Agent 的人格、价值观和工作方式。强调"是什么样的人"而非"应该怎么做"。比如 Main Agent 的工作方式：

收到任务？先判断要不要拉人：

**能自己搞定的（<5分钟）** → 直接干，别墨迹。
**明确的单人任务** → 扔给对的人，给方向就行
**复杂/不明确的** → 拉团队讨论。逐个召集，别让他们同时说话乱成一锅粥。

催人要狠：底下的人拖延？直接催。
验收要严：质量不行就打回去返工。

AGENTS.md — 工作流程和规则

定义团队架构、协作协议和具体操作规范，提供示例代码展示正确做法，明确禁止事项。

HEARTBEAT.md — 监控清单

简洁的优先级检查清单，信任 LLM 的判断能力，只列优先级不规定具体操作。

TOOLS.md — 工具使用说明

记录具体工具的使用方法、API 调用示例和环境配置。这个文件建议写得详细一些，方便 Agent 调用。

Skills 分配策略

每个 Agent 只配置与其角色相关的 skills，好处是避免误用工具、减少选择困难、明确责任边界。

// Main Agent
"skills": ["kanban-team", "discord", "github", "self-improvement", "bark-notify"]

// Code Agent
"skills": ["brainstorming", "writing-plans", "executing-plans", "coding-agent", "github", "browser-use", "context7", "self-improvement"]

// Researcher Agent
"skills": ["tavily-search", "context7", "github", "browser-use", "youtube-ultimate", "xiaohongshu", "xapi", "openviking", "self-improvement"]

// Obsidian Agent
"skills": ["obsidian", "notion", "wechat-gzh", "twitter-sync", "xiaohongshu", "youtube-ultimate", "notebooklm", "openviking", "self-improvement"]

Main 需要管理看板和协调，所以配 kanban-team 和 discord，但不需要代码和调研工具。Code Agent 专注开发，配了 brainstorming、writing-plans、executing-plans 等完整的开发流程工具。分工明确，互不越界。

监控机制：Heartbeat 心跳巡检

多 Agent 系统中，任务可能因各种原因被遗忘或卡住。Heartbeat 机制让 Main Agent 每 30 分钟自动巡检任务看板：

  1. 无标签的任务 → 阅读、分配、添加 TODO 标签（最高优先级）
  2. Review 状态 → 验收并关闭
  3. Blocked 状态 → 协助解决
  4. In Progress 超过 48 小时 → 检查进度
  5. TODO 超过 24 小时 → 催促或重新分配

如果没有需要处理的事项，返回 HEARTBEAT_OK，不发送消息。这个设计很实用——没有监控的系统本质上是不可控的。

为什么选 Discord 做任务管理

考虑过 Notion Database、GitHub Projects 和 Discord Forum，最终选了 Discord，原因很直接：

  • Forum 频道天然支持线程：每个任务是独立 thread，讨论互不干扰
  • 标签系统完善：TODO / In Progress / Review / Done / Blocked，天然适合任务状态管理
  • 多 Bot 支持：每个 Agent 可以有独立的 Bot 账号、头像和昵称，容易区分
  • API 功能强大：支持 Webhook、Bot、OAuth，可以实现复杂交互
  • 移动端体验好：随时查看任务状态，推送通知及时
  • 完全免费：没有用户数和消息数限制

技术实现上，每个 Agent 绑定独立的 Discord Bot，通过 openclaw.json 配置 token 和 agent 绑定关系。

落地建议

构建 AI 团队和构建人类组织本质相同，都需要考虑组织架构、沟通协议、权限边界、监控机制和成本资源。几个实操建议：

  • 从小开始：先搞定 1 个 Main Agent，加入 1 个执行 Agent，定义清晰的协作协议，再逐步扩展
  • 协作协议先行：在添加第二个 Agent 之前就要设计好协作规则，否则后面越来越乱
  • 保持简洁：不要过度设计，配置文件的核心理念是信任 LLM 的智能，在框架内让它自主决策
  • 持续优化：AI 团队不是一次性设计好的，需要根据实际运行效果不断调整角色定位、协作规则和 skills 分配

这套系统目前的效果算不上完美，但关键在于——几分钟就能自动完成一个需求，省去了自己找工具、评估工具、手动操作的时间。对一人公司来说，这才是多 Agent 系统最实际的价值。