EnterpriseArchitect/plans/2026-06-22_多智能体协作体系总体方案.md

多智能体协作体系总体方案

文档版本：v1.0（初稿） 编制人：陆怀瑾（COO） 日期：2026-06-22 状态：待刘总审阅

---

一、背景与目标

1.1 公司当前业务线

业务线	当前状态	负责Agent
开市客电商店铺运营	淘宝店铺运营中，需开发自动化运营系统	陆云帆（taobaospecialist）
内容运营	即将启动小红书内容运营	文墨言（contentspecialist）
系统开发	待启动系列软件开发项目	胡蓉（projectmanager）→产研团队
商业分析	市场深度分析/商业模式/BP撰写	待组建
专职秘书	刘诗妮（secretary），不进项目	刘诗妮
求职投递	程伯予（cvexpert），不进项目	程伯予

1.2 COO 核心目标

在一堆智能体中建立合理秩序，确保多智能体顺利、稳定协同并持续运行。

---

二、五大子项目概览

编号	子项目	Multica Issue	状态
1	组织架构与岗位职责体系建设	BIZ-11	backlog
2	文档存储、命名与索引规范	BIZ-12	backlog
3	配置文件持续优化机制	BIZ-15	backlog
4	知识库体系建设	BIZ-14	backlog
5	运行稳定性保障（任务停滞/429限流）	BIZ-13	backlog

---

三、组织架构方案（子项目1：BIZ-11）

3.1 现有Agent团队

Agent	角色	职能域
陆怀瑾	COO	全局运营、资源协调、风险监控
刘诗妮	秘书	业务入口、进度跟进、飞书对接
胡蓉	项目经理	项目拆解、开发计划、进度管理
沈路明	产品经理	PRD撰写、需求分析
梁思筑	系统架构师	架构设计、技术方案
徐聪	全栈开发工程师	代码开发
苏锦绘	UI/UX设计师	设计交付
严维序	运维工程师	部署、运维、基础设施
陆云帆	淘宝运营专员	淘宝店铺运营
文墨言	内容运营专员	内容文案、小红书运营
钟帧韵	视频媒体专员	视频制作
程伯予	求职助理	简历投递（不进项目）

3.2 组织架构设计

                        Vincent（刘总）
                             │
              ┌──────────────┼──────────────┐
              │              │              │
         刘诗妮(秘书)   陆怀瑾(COO)    程伯予(求职)
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
    运营中心            产研中心            商业分析中心(待建)
    ┌───┴───┐        ┌──────┴──────┐        ┌────┴────┐
    │       │        │             │        │         │
  陆云帆  文墨言   胡蓉(PM)    钟帧韵   市场分析师  法务顾问
 (淘宝)  (内容)     │          (视频)   (待招聘)   (待招聘)
                    │
              ┌─────┼─────┐
              │     │     │
           沈路明  梁思筑  苏锦绘
           (产品) (架构) (设计)
              │
           徐聪(开发)
              │
           严维序(运维)

3.3 团队缺口评估

角色	必要性	说明
市场分析师	高	商业分析业务线需要专业市场分析能力
法务顾问	中	电商合规、合同审查风险需要
财务/数据分析师	中	成本分析、ROI计算需要

3.4 业务标准规范SOP框架

• 开发SOP：Vincent/secretary → PM拆解 → PRD → 架构 → 开发 → UI → 部署
• 运营SOP：业务需求 → COO分配 → 专员执行 → COO检查 → 刘总确认
• 紧急SOP：风险识别 → COO评估 → 升级通知（>4h阻塞通知secretary，严重风险直接汇报刘总）

---

四、文档存储规范方案（子项目2：BIZ-12）

4.1 推荐的目录结构

workspace/
├── AGENTS.md          # Agent协作协议
├── MEMORY.md           # 长期记忆
├── SOUL.md             # 角色定义
├── IDENTITY.md         # 身份信息
├── USER.md             # 用户画像
├── TOOLS.md            # 工具清单
├── HEARTBEAT.md        # 心跳配置
├── memory/             # 记忆归档
│   └── YYYY-MM-DD.md  # 按日期归档
├── docs/               # 项目文档
│   └── {project-name}/ # 按项目分目录
├── plans/              # 方案文档
│   └── {YYYY-MM-DD}_{topic}.md
├── reports/            # 运营报告
│   └── {YYYY-QN}_{type}.md
└── knowledge/          # 知识库文件
    └── {domain}/       # 按领域分目录

4.2 命名规则

• 日期格式：YYYY-MM-DD
• 文档命名：{日期}{主题}{版本}.{扩展名}
• 记忆归档：memory/YYYY-MM-DD.md
• 方案文档：plans/YYYY-MM-DD_{topic}.md

4.3 索引机制

• 每个Agent的 MEMORY.md 中维护文档索引表
• 支持 memory_search / wiki_search 跨文档检索

---

五、配置文件优化方案（子项目3：BIZ-15）

5.1 核心策略：「引用代替填塞」

当前问题：配置文件（AGENTS.md等）中嵌入了大量重复内容，Token快速增长。

解决方案：通过引用（文件路径/URL）引用外部内容，而非内联。

示例：

• AGENTS.md 中的Agent协作表 → 引用 docs/agent-roster.md
• SOUL.md 中的SOP模板 → 引用 docs/sop-template.md
• TOOLS.md 中的工具详情 → 引用 docs/tools-reference.md

5.2 每周优化流程

1. 定时任务（cron）每周执行
2. 扫描所有Agent配置文件
3. 检测内联冗余内容（超过N行的非核心块）
4. 生成优化建议报告
5. 人工审批后执行迁移

---

六、知识库体系方案（子项目4：BIZ-14）

6.1 架构原则

• 知识库与Agent配置完全解耦
• Agent通过工具调用查询，知识不进入Token
• 人类可通过Web UI审查/编辑

6.2 技术方案

利用OpenClaw现有的 memory_search / wiki_search / wiki_get 工具体系：

• 编译型Wiki：通过 wiki_apply / wiki_search 体系管理结构化知识
• 知识目录：按业务领域分目录的 Markdown 文件
• 人类审查：Obsidian Web UI 或飞书文档同步

6.3 Agent查询流程

Agent需要知识 → memory_search/wik_search → 获取相关段落 → 用于决策
                                                    ↓
                                              不进入配置文件

---

七、运行稳定性方案（子项目5：BIZ-13）

7.1 任务停滞问题

根因	解决方案
超时无响应	心跳超时检测（HEARTBEAT.md），超时自动恢复
依赖缺失	依赖检查前置，未满足时自动 blocked
无限循环	最大 Token/轮次限制
上下文溢出	引用代替填塞，控制上下文大小

7.2 429限流问题（40 RPM）

Agent类型	当前RPM	优化方向
高频Agent（secretary/coo）	40	合并查询、批量操作、缓存
开发Agent	40	限流队列、优先级调度
业务Agent	40	错峰调度、降低轮询频率

限流策略：

1. 请求队列（FIFO + 优先级）
2. 令牌桶限流（每Agent独立桶）
3. 模型降级（限流时自动切换到备用模型）
4. 智能重试（指数退避 + Jitter）

---

八、实施路线图

Phase 1（第1-2周）：方案制定与审阅
├── 组织架构方案（BIZ-11）
├── 文档存储规范（BIZ-12）
├── 配置文件优化方案（BIZ-15）
├── 知识库体系方案（BIZ-14）
└── 运行稳定性方案（BIZ-13）

Phase 2（第3-4周）：刘总审阅通过后逐步实施
├── 先实施文档规范（基础）
├── 再实施配置文件优化
├── 同步推进知识库搭建
└── 最后实施运行稳定性保障

Phase 3（第5周+）：持续优化迭代
├── 每周定时检查配置文件
├── 监控运行稳定性指标
└── 定期汇报运营报告

---

⚠️ 以上所有方案均为初稿，需刘总审阅后方可进入实施阶段。 审阅前，不修改任何Agent配置文件。 方案最终版将提交到 EnterpriseArchitect git 仓库。