vincent/EnterpriseArchitect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

初始提交：多智能体协作体系总体方案及各子项目详细方案

Browse Source 
- BIZ-11: 组织架构与岗位职责体系建设方案
- BIZ-12: 文档存储、命名与索引规范方案
- BIZ-13: 运行稳定性保障方案（任务停滞与429速率限制）
- BIZ-14: 知识库体系建设方案
- BIZ-15: 配置文件持续优化机制方案

所有方案均为初稿，待刘总审阅。
This commit is contained in:
陆怀瑾 (COO)
2026-06-22 02:45:51 +08:00
commit 38b21d7adb
6 changed files with 1966 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plans/2026-06-22_多智能体协作体系总体方案.md
+243
View File
@@ -0,0 +1,243 @@
# 多智能体协作体系总体方案
> 文档版本：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 仓库。
plans/BIZ-11_组织架构与岗位职责体系建设方案.md
+257
View File
@@ -0,0 +1,257 @@
# BIZ-11 组织架构与岗位职责体系建设方案
> 版本：v1.0
> 编制：陆怀瑾（COO）
> 日期：2026-06-22
> 状态：待审阅
---
## 一、目标
建立清晰的多智能体组织架构，明确各 Agent 的岗位职责、协作流程和能力边界，确保团队协作高效、责任清晰。
---
## 二、现有团队盘点
### 2.1 核心管理层
| Agent | 角色 | 核心职能 | 工作模式 |
|-------|------|----------|----------|
| 刘诗妮 (secretary) | 专职秘书 | 业务入口、进度跟进、飞书对接 | 不进项目，专职支持 Vincent |
| 陆怀瑾 (coo) | COO 运营总监 | 全局运营、资源协调、风险监控、流程优化 | 监控所有业务线 |
| 程伯予 (cvexpert) | 求职助理 | 简历投递服务 | 不进项目，专职服务 |
### 2.2 产研中心
| Agent | 角色 | 核心职能 |
|-------|------|----------|
| 胡蓉 (projectmanager) | 项目经理 | 项目拆解、开发计划、进度管理 |
| 沈路明 (productmanager) | 产品经理 | PRD 撰写、需求分析 |
| 梁思筑 (architect) | 系统架构师 | 架构设计、技术方案评审 |
| 徐聪 (costcodev) | 全栈开发工程师 | 代码开发、单元测试 |
| 苏锦绘 (designer) | UI/UX设计师 | 界面设计、用户体验优化 |
| 严维序 (opengineer) | 运维工程师 | 部署、监控、基础设施维护 |
### 2.3 运营中心
| Agent | 角色 | 核心职能 |
|-------|------|----------|
| 陆云帆 (taobaospecialist) | 淘宝运营专员 | 淘宝店铺运营、自动化系统开发 |
| 文墨言 (contentspecialist) | 内容运营专员 | 内容文案、小红书运营 |
| 钟帧韵 (mediaspecialist) | 视频媒体专员 | 视频制作、媒体内容 |
### 2.4 待补充岗位
| 角色 | 必要性 | 说明 |
|------|--------|------|
| 市场分析师 | 高 | 商业分析业务线需要专业市场分析能力 |
| 法务顾问 | 中 | 电商合规、合同审查风险需要 |
| 财务/数据分析师 | 中 | 成本分析、ROI 计算、业务数据报表 |
---
## 三、组织架构设计
```
Vincent（刘总）
│
┌──────────────┼──────────────┐
│ │ │
刘诗妮 (秘书) 陆怀瑾 (COO) 程伯予 (求职)
│
┌───────────────────┼───────────────────┐
│ │ │
运营中心 产研中心 商业分析中心 (待建)
┌───┴───┐ ┌──────┴──────┐ ┌────┴────┐
│ │ │ │ │ │
陆云帆 文墨言 胡蓉 (PM) 钟帧韵 市场分析师 法务顾问
(淘宝) (内容) │ (视频) (待招聘) (待招聘)
│
┌─────┼─────┐
│ │ │
沈路明 梁思筑 苏锦绘
(产品) (架构) (设计)
│
徐聪 (开发)
│
严维序 (运维)
```
---
## 四、岗位职责说明书模板
### 4.1 模板结构
```markdown
# 岗位说明书：{岗位名称}
## 基本信息
- **岗位 ID**: {agent_id}
- **汇报对象**: {上级 agent}
- **下属岗位**: {如有}
- **协作岗位**: {平级协作 agent}
## 核心职责
1. {职责 1}
2. {职责 2}
3. {职责 3}
## 工作流程
- **输入**: {接收什么任务/信息}
- **处理**: {执行什么操作}
- **输出**: {交付什么成果}
## 权限范围
- **自主决策**: {可以自主决定的事项}
- **需要审批**: {需要上级审批的事项}
- **无权处理**: {超出权限的事项}
## 绩效指标
- {KPI 1}
- {KPI 2}
- {KPI 3}
## 升级机制
- **阻塞 > 4h**: 通知 COO
- **严重风险**: 直接汇报 Vincent
```
### 4.2 示例：COO 岗位说明书
```markdown
# 岗位说明书：COO 运营总监
## 基本信息
- **岗位 ID**: coo
- **汇报对象**: Vincent
- **下属岗位**: 所有业务 Agent
- **协作岗位**: secretary（信息互通）
## 核心职责
1. 全局监控所有业务线进展
2. 资源协调与负载均衡
3. 风险识别与升级
4. 流程优化与 SOP 制定
5. 运营效率报告
## 工作流程
- **输入**: WorkBoard 任务、各 Agent 进度报告
- **处理**: 监控、分析、协调、优化
- **输出**: 运营报告、风险预警、资源调度决策
## 权限范围
- **自主决策**: 任务重新分配、流程优化、资源调度
- **需要审批**: 新岗位设立、重大流程变更
- **无权处理**: 战略方向、预算审批
## 绩效指标
- 运营效率 ≥ 95%
- 风险识别率 ≥ 90%
- 团队满意度 ≥ 4.5/5
## 升级机制
- **阻塞 > 4h**: 通知 secretary
- **严重风险**: 直接汇报 Vincent
```
---
## 五、协作流程 SOP
### 5.1 开发项目 SOP
```
Vincent/secretary 提出需求
↓
COO 评估资源
↓
projectmanager 拆解任务
↓
productmanager 撰写 PRD
↓
architect 设计架构
↓
costcodev 开发
↓
designer UI 设计
↓
opengineer 部署
↓
COO 验收确认
```
### 5.2 运营业务 SOP
```
业务需求提出
↓
COO 分配任务
↓
运营专员执行
↓
COO 检查质量
↓
Vincent 确认
```
### 5.3 紧急事项处理 SOP
```
发现风险/阻塞
↓
COO 评估影响
↓
┌─────┴─────┐
│ │
一般阻塞 严重风险
(>4h) (影响收入/客户)
│ │
通知 直接汇报
secretary Vincent
```
---
## 六、实施步骤
### 阶段 1：文档化（本周）
- [ ] 完成所有现有 Agent 的岗位说明书
- [ ] 建立协作流程图
- [ ] 制定紧急事项处理 SOP
### 阶段 2：工具化（下周）
- [ ] 在 WorkBoard 中配置岗位标签
- [ ] 建立 Agent 能力矩阵文档
- [ ] 配置自动负载均衡机制
### 阶段 3：优化迭代（持续）
- [ ] 每周回顾协作效率
- [ ] 收集 Agent 反馈
- [ ] 持续优化 SOP
---
## 七、风险与对策
| 风险 | 影响 | 对策 |
|------|------|------|
| 职责边界模糊 | 推诿扯皮 | 明确书面职责 + 定期回顾 |
| 流程过于复杂 | 效率降低 | 保持 SOP 简洁，定期简化 |
| 新岗位招聘延迟 | 业务瓶颈 | 优先自动化 + 临时外包 |
---
## 八、交付物清单
- [ ] 所有 Agent 岗位说明书（Markdown 格式）
- [ ] 组织架构图（可视化）
- [ ] 协作流程 SOP 文档
- [ ] 紧急事项处理流程
- [ ] 岗位能力矩阵表
---
> ⚠️ 本方案需 Vincent 审阅后方可实施。审阅前不修改任何 Agent 配置文件。
plans/BIZ-12_文档存储命名与索引规范方案.md
+270
View File
@@ -0,0 +1,270 @@
# BIZ-12 文档存储、命名与索引规范方案
> 版本：v1.0
> 编制：陆怀瑾（COO）
> 日期：2026-06-22
> 状态：待审阅
---
## 一、目标
建立统一的文档存储规范，确保所有智能体能够规范地存储、命名、检索文档，避免信息孤岛和文档混乱。
---
## 二、核心原则
1. **分层存储**：按文档类型和用途分层存放
2. **统一命名**：所有文档遵循一致的命名规则
3. **索引可查**：建立文档索引，支持快速检索
4. **版本可控**：重要文档保留版本历史
---
## 三、目录结构设计
### 3.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}/ # 按项目分目录
│ ├── README.md
│ ├── requirements.md
│ └── design.md
│
├── plans/ # 方案文档目录
│ └── YYYY-MM-DD_{topic}.md
│
├── reports/ # 运营报告目录
│ └── YYYY-QN_{type}.md # 按季度/类型归档
│
├── knowledge/ # 知识库目录
│ └── {domain}/ # 按领域分目录
│ └── {topic}.md
│
└── assets/ # 资源文件目录
├── images/
├── attachments/
└── templates/
```
### 3.2 各目录用途说明
| 目录 | 用途 | 维护者 | 更新频率 |
|------|------|--------|----------|
| 根目录配置文件 | Agent 核心配置 | 各 Agent | 按需 |
| memory/ | 短期记忆归档 | 各 Agent | 每日 |
| docs/ | 项目文档 | projectmanager | 按项目 |
| plans/ | 方案文档 | COO | 按需 |
| reports/ | 运营报告 | COO | 每周/每月 |
| knowledge/ | 知识库 | 各 Agent | 持续 |
| assets/ | 资源文件 | 各 Agent | 按需 |
---
## 四、命名规则
### 4.1 通用命名格式
```
{日期}_{主题}_{版本}.{扩展名}
```
### 4.2 日期格式
- 统一使用 `YYYY-MM-DD` 格式
- 示例：`2026-06-22`
### 4.3 主题命名
- 使用下划线分隔中文主题
- 避免特殊字符（`/ \ : * ? " < > |`）
- 示例：`多智能体协作体系`
### 4.4 版本标识
- 初稿：`v1.0`
- 修订：`v1.1`, `v1.2`
- 重大变更：`v2.0`
### 4.5 命名示例
| 类型 | 示例 |
|------|------|
| 记忆归档 | `memory/2026-06-22.md` |
| 方案文档 | `plans/2026-06-22_多智能体协作体系总方案_v1.0.md` |
| 运营报告 | `reports/2026-Q2_运营效率报告_v1.0.md` |
| 知识库 | `knowledge/电商/淘宝运营 SOP_v1.0.md` |
| 项目文档 | `docs/自动化运营系统/requirements_v1.0.md` |
---
## 五、索引机制
### 5.1 索引层级
```
Level 1: MEMORY.md（总索引）
↓
Level 2: 各目录 README.md（分类索引）
↓
Level 3: 具体文档（内容）
```
### 5.2 MEMORY.md 索引表格式
```markdown
## 文档索引
### 方案文档
| 日期 | 主题 | 路径 | 状态 |
|------|------|------|------|
| 2026-06-22 | 多智能体协作体系 | plans/2026-06-22_多智能体协作体系总方案.md | 待审阅 |
### 运营报告
| 周期 | 类型 | 路径 | 状态 |
|------|------|------|------|
| 2026-Q2 | 效率报告 | reports/2026-Q2_运营效率报告.md | 已完成 |
### 知识库
| 领域 | 主题 | 路径 | 更新时间 |
|------|------|------|----------|
| 电商 | 淘宝 SOP | knowledge/电商/淘宝运营 SOP.md | 2026-06-22 |
```
### 5.3 检索工具
- **memory_search**: 跨文档语义检索
- **wiki_search**: 知识库检索
- **memory_get**: 精确读取特定文档
- **web_fetch**: 外部文档获取
---
## 六、Agent 文档操作规范
### 6.1 写入规范
```python
# 伪代码示例
def write_document(path, content, agent_id):
# 1. 检查文件是否存在
if exists(path):
# 2. 如存在，增加版本号
version = get_next_version(path)
path = add_version(path, version)
# 3. 写入文件
write(path, content)
# 4. 更新索引
update_index(path, agent_id, timestamp())
```
### 6.2 读取规范
```python
# 伪代码示例
def read_document(query, agent_id):
# 1. 先查索引
results = search_index(query)
# 2. 如未找到，用语义检索
if not results:
results = memory_search(query)
# 3. 记录读取日志
log_access(query, agent_id, timestamp())
return results
```
### 6.3 更新规范
- 小改动：直接覆盖原文件
- 大改动：创建新版本，保留旧版本
- 删除：移动到 `archive/` 目录，不直接删除
---
## 七、版本管理策略
### 7.1 版本类型
| 类型 | 标识 | 说明 |
|------|------|------|
| 初稿 | v1.0 | 首次创建 |
| 小修订 | v1.1, v1.2 | 内容微调，不改变结构 |
| 大修订 | v2.0, v3.0 | 结构性变更 |
| 归档 | archive/v1.0 | 已废弃的旧版本 |
### 7.2 版本保留策略
- 当前版本：始终保留
- 上一版本：保留最近 1 个
- 历史版本：归档到 `archive/` 子目录
### 7.3 版本命名示例
```
plans/
├── 2026-06-22_多智能体协作体系总方案.md # 当前版本
├── archive/
│ └── 2026-06-22_多智能体协作体系总方案_v1.0.md # 历史版本
```
---
## 八、实施步骤
### 阶段 1：规范化（本周）
- [ ] 制定完整的命名规则文档
- [ ] 创建各目录 README.md
- [ ] 更新 MEMORY.md 索引表
### 阶段 2：迁移（下周）
- [ ] 整理现有文档，按新规范重命名
- [ ] 移动到正确目录
- [ ] 建立归档目录
### 阶段 3：工具化（持续）
- [ ] 开发文档索引自动更新脚本
- [ ] 建立文档健康检查机制
- [ ] 定期清理过期文档
---
## 九、风险与对策
| 风险 | 影响 | 对策 |
|------|------|------|
| Agent 不按规范命名 | 文档混乱 | 增加命名检查工具 |
| 索引更新不及时 | 检索失败 | 自动更新索引 |
| 版本过多占用空间 | 存储压力 | 定期清理归档 |
---
## 十、交付物清单
- [ ] 文档存储规范文档（本文档）
- [ ] 各目录 README.md 模板
- [ ] MEMORY.md 索引表模板
- [ ] 文档命名检查工具
- [ ] 文档迁移脚本
---
> ⚠️ 本方案需 Vincent 审阅后方可实施。审阅前不修改任何 Agent 配置文件。
plans/BIZ-13_运行稳定性保障方案.md
+345
View File
@@ -0,0 +1,345 @@
# BIZ-13 智能体运行稳定性保障方案
> 版本：v1.0
> 编制：陆怀瑾（COO）
> 日期：2026-06-22
> 状态：待审阅
---
## 一、目标
解决智能体运行中的两大核心问题：
1. **任务停滞**：智能体未完成任务便停滞不前
2. **429 限流**：API 速率限制（当前 40 RPM）导致任务延迟
确保智能体系统稳定、可靠、持续运行。
---
## 二、任务停滞问题分析
### 2.1 根因分析
| 根因 | 表现 | 发生频率 |
|------|------|----------|
| 超时无响应 | 执行到某一步后卡住，无输出 | 高 |
| 依赖缺失 | 等待前置条件，但条件永不满足 | 中 |
| 无限循环 | 反复执行相同逻辑，无进展 | 中 |
| 上下文溢出 | Token 超限，无法继续 | 低 |
| 工具调用失败 | 工具返回错误，未处理 | 中 |
| 等待用户确认 | 错误地等待人类输入 | 高 |
### 2.2 典型案例
```
案例 1：等待用户确认
问题：Agent 发现任务后，向用户请示"要不要做"
影响：用户不在线时，任务卡死数小时
对策：HEARTBEAT.md 明确规定"禁止请示"
案例 2：依赖循环等待
问题：Agent A 等 Agent B，Agent B 等 Agent A
影响：双方永远无法推进
对策：依赖图检测 + 超时自动降级
案例 3：工具调用失败未处理
问题：工具返回错误，Agent 未检查，继续执行
影响：后续步骤全部失败
对策：强制错误检查 + 重试机制
```
---
## 三、任务停滞解决方案
### 3.1 心跳超时检测
**机制**：每个 Agent 配置 HEARTBEAT.md，定期执行检查清单
**超时阈值**：
- 高频 Agent（secretary/coo）：10 分钟
- 开发 Agent：15 分钟
- 业务 Agent：15 分钟
**超时处理**：
```
检测到超时
↓
检查任务状态
↓
┌─────┴─────┐
│ │
有进展 无进展
│ │
延长超时 自动恢复
(通知 COO) (重新调度)
```
### 3.2 依赖检查前置
**规则**：任务开始前，检查所有依赖是否满足
```python
def check_dependencies(task):
for dep in task.depends_on:
if not is_complete(dep):
return False, f"依赖 {dep} 未完成"
return True, "依赖满足"
# 任务启动前强制检查
ready, reason = check_dependencies(task)
if not ready:
set_status(task, "blocked", reason)
notify_co()
```
### 3.3 最大轮次限制
**规则**：单任务最大执行轮次限制
| Agent 类型 | 最大轮次 | 超限处理 |
|------------|----------|----------|
| 高频 Agent | 50 | 自动暂停，通知 COO |
| 开发 Agent | 100 | 自动暂停，记录日志 |
| 业务 Agent | 30 | 自动暂停，通知创建者 |
### 3.4 上下文控制
**策略**：引用代替填塞
```
错误做法：
- AGENTS.md 中嵌入全部 Agent 信息（3000+ tokens）
正确做法：
- AGENTS.md 只保留核心协作协议
- 详细信息存 docs/agent-roster.md
- 通过引用链接访问
```
**上下文清理**：
- 每轮对话前清理过期信息
- 工具调用结果仅保留必要部分
- 长文档分块读取
---
## 四、429 限流问题分析
### 4.1 当前限制
| 模型 | RPM 限制 | 当前使用 | 风险等级 |
|------|----------|----------|----------|
| 主模型 (qwen3.5-397b) | 40 | ~30 | 中 |
| 备用模型 (deepseek-v4-pro) | 40 | ~10 | 低 |
### 4.2 限流影响
```
触发 429 限流
↓
任务延迟执行
↓
┌─────┴─────┐
│ │
等待恢复 任务失败
(分钟级) (小时级)
```
---
## 五、429 限流解决方案
### 5.1 请求队列 + 优先级调度
**队列设计**：
```
请求队列（FIFO + 优先级）
┌─────────────────────────────────────┐
│ 优先级 1 (紧急): Vincent 直接任务 │
│ 优先级 2 (高): 阻塞性任务 │
│ 优先级 3 (正常): 常规任务 │
│ 优先级 4 (低): 后台优化任务 │
└─────────────────────────────────────┘
↓
令牌桶限流
↓
模型 API
```
**调度算法**：
```python
def schedule_request(request):
# 1. 加入优先级队列
priority_queue.add(request)
# 2. 检查令牌桶
if token_bucket.has_tokens():
token_bucket.consume()
send_to_api(request)
else:
# 3. 等待或降级
if request.priority >= 2:
wait_for_token()
else:
fallback_to_backup_model(request)
```
### 5.2 多模型负载均衡
**模型池**：
| 模型 | 用途 | 优先级 |
|------|------|--------|
| qwen3.5-397b | 主模型，复杂推理 | 高 |
| deepseek-v4-pro | 备用模型，常规任务 | 中 |
| 本地模型 | 简单任务，成本优化 | 低 |
**负载均衡策略**：
```
主模型可用且 RPM 充裕
↓
使用主模型
↓
主模型 RPM 不足
↓
切换到备用模型
↓
备用模型也不足
↓
降级到本地模型或等待
```
### 5.3 智能重试机制
**指数退避 + Jitter**：
```python
def retry_with_backoff(api_call, max_retries=3):
for i in range(max_retries):
try:
return api_call()
except RateLimitError:
delay = (2 ** i) * 1000 + random(0, 1000) # ms
sleep(delay)
raise Exception("重试失败")
```
**重试策略**：
| 重试次数 | 延迟时间 | 说明 |
|----------|----------|------|
| 第 1 次 | 1-2 秒 | 快速重试，应对短暂波动 |
| 第 2 次 | 2-4 秒 | 指数退避 |
| 第 3 次 | 4-8 秒 | 切换备用模型 |
### 5.4 请求合并与缓存
**合并策略**：
```
错误做法：
- 每个 Agent 独立轮询 WorkBoard（40 RPM × N Agent）
正确做法：
- COO 统一轮询，广播结果
- 减少轮询频率（10 分钟 → 15 分钟）
- 合并相似查询
```
**缓存策略**：
```
查询请求
↓
检查缓存
↓
┌─────┴─────┐
│ │
缓存命中 缓存未命中
│ │
返回缓存 调用 API → 更新缓存
```
**缓存有效期**：
| 数据类型 | 有效期 | 说明 |
|----------|--------|------|
| WorkBoard 状态 | 5 分钟 | 高频变化 |
| Agent 配置 | 1 小时 | 低频变化 |
| 知识库内容 | 1 天 | 基本不变 |
| 用户信息 | 1 天 | 基本不变 |
---
## 六、监控与告警
### 6.1 监控指标
| 指标 | 阈值 | 告警级别 |
|------|------|----------|
| 任务停滞时长 | > 1h | 警告 |
| 任务停滞时长 | > 4h | 严重 |
| 429 错误率 | > 5% | 警告 |
| 429 错误率 | > 20% | 严重 |
| Agent 响应延迟 | > 30s | 警告 |
### 6.2 告警流程
```
监控系统检测到异常
↓
记录日志
↓
┌─────┴─────┐
│ │
警告 严重
│ │
通知 COO 通知 Vincent
```
### 6.3 监控工具
- Prometheus + Grafana（基础设施监控）
- 自定义 Agent 健康检查脚本
- WorkBoard 诊断工具
---
## 七、实施步骤
### 阶段 1：心跳机制落地（本周）
- [ ] 更新所有 Agent 的 HEARTBEAT.md
- [ ] 配置定时任务（10 分钟）
- [ ] 测试超时检测
### 阶段 2：限流优化（下周）
- [ ] 实现请求队列
- [ ] 配置多模型负载均衡
- [ ] 实现智能重试
### 阶段 3：监控体系（持续）
- [ ] 搭建监控面板
- [ ] 配置告警规则
- [ ] 定期健康检查
---
## 八、风险与对策
| 风险 | 影响 | 对策 |
|------|------|------|
| 心跳任务本身卡死 | 监控失效 | 独立监控进程 |
| 请求队列过长 | 延迟增加 | 动态扩容 |
| 缓存数据过期 | 决策错误 | 设置 TTL + 主动刷新 |
---
## 九、交付物清单
- [ ] HEARTBEAT.md 更新模板
- [ ] 请求队列实现代码
- [ ] 多模型负载均衡配置
- [ ] 智能重试机制实现
- [ ] 监控面板 URL
- [ ] 告警规则配置
---
> ⚠️ 本方案需 Vincent 审阅后方可实施。审阅前不修改任何 Agent 配置文件。
plans/BIZ-14_知识库体系建设方案.md
+387
View File
@@ -0,0 +1,387 @@
# BIZ-14 智能体知识库体系建设方案
> 版本：v1.0
> 编制：陆怀瑾（COO）
> 日期：2026-06-22
> 状态：待审阅
---
## 一、目标
建立独立于 Agent 配置的知识库体系，实现：
1. **知识与配置解耦**：知识不进入 Token，避免配置膨胀
2. **可维护可扩展**：人类可通过 Web UI 审查、编辑、优化
3. **主动查询能力**：Agent 能在需要时主动查询知识库
4. **零 Token 增长**：知识库内容不计入 Agent 上下文
---
## 二、架构设计
### 2.1 整体架构
```
┌─────────────────────────────────────────────────────┐
│ Agent 层 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │secretary│ │ coo │ │ PM │ │ dev │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ └──────────┴──────────┴──────────┘ │
│ │ │
│ memory_search / wiki_search │
└────────────────────────┼──────────────────────────┘
│
┌────────────────────────┼──────────────────────────┐
│ 知识库层 │
│ ┌───────────────────┴───────────────────┐ │
│ │ 编译型 Wiki 系统 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │wiki_get │ │wiki_ │ │wiki_ │ │ │
│ │ │ │ │search │ │apply │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └───────────────────────────────────────┘ │
│ │ │
│ Markdown 文件系统 │
│ ┌───────────────────┴───────────────────┐ │
│ │ knowledge/ │ │
│ │ ├── 电商/淘宝运营 SOP.md │ │
│ │ ├── 电商/抖店运营 SOP.md │ │
│ │ ├── 内容/小红书运营指南.md │ │
│ │ ├── 产品/PRD 模板.md │ │
│ │ └── 技术/开发规范.md │ │
│ └───────────────────────────────────────┘ │
└───────────────────────────────────────────────────┘
│
┌────────────────────────┼──────────────────────────┐
│ 人类交互层 │
│ ┌───────────────────┴───────────────────┐ │
│ │ Obsidian Web UI │ │
│ │ 或 飞书文档同步 │ │
│ └───────────────────────────────────────┘ │
└───────────────────────────────────────────────────┘
```
### 2.2 核心原则
| 原则 | 说明 |
|------|------|
| 解耦 | 知识库与 Agent 配置完全独立 |
| 按需查询 | Agent 只在需要时查询，不预加载 |
| 人类可审 | Web UI 支持人类审查、编辑 |
| 版本可控 | 知识变更保留历史版本 |
---
## 三、技术选型
### 3.1 现有工具利用
OpenClaw 已提供完整的 Wiki 工具链：
| 工具 | 用途 | 说明 |
|------|------|------|
| `wiki_search` | 知识检索 | 按标题/路径/内容搜索 |
| `wiki_get` | 精确读取 | 读取特定页面 |
| `wiki_apply` | 知识写入 | 创建/更新知识条目 |
| `wiki_lint` | 质量检查 | 检查知识库完整性 |
| `wiki_status` | 状态检查 | 查看 Wiki 系统健康度 |
### 3.2 与记忆系统的关系
```
┌─────────────────────────────────────┐
│ 记忆系统 (Memory) │
│ - MEMORY.md：长期记忆 │
│ - memory/*.md：短期记忆归档 │
│ - 用途：Agent 个性化记忆、决策历史 │
└─────────────────────────────────────┘
│
语义检索
↓
┌─────────────────────────────────────┐
│ 知识库系统 (Wiki) │
│ - knowledge/*.md：领域知识 │
│ - 用途：SOP、模板、规范、最佳实践 │
└─────────────────────────────────────┘
```
**区别**：
- **Memory**：Agent 个性化、决策历史、经验教训
- **Wiki**：通用知识、SOP、模板、规范
---
## 四、知识库目录设计
### 4.1 目录结构
```
knowledge/
├── README.md # 知识库索引
│
├── 电商/ # 电商运营知识
│ ├── 淘宝运营 SOP.md
│ ├── 抖店运营 SOP.md
│ ├── 微信小店 SOP.md
│ └── 客服话术模板.md
│
├── 内容/ # 内容运营知识
│ ├── 小红书运营指南.md
│ ├── 标题写作技巧.md
│ ├── 内容排期模板.md
│ └── 爆款内容分析.md
│
├── 产品/ # 产品管理知识
│ ├── PRD 模板.md
│ ├── 需求分析方法.md
│ ├── 用户故事模板.md
│ └── 版本规划指南.md
│
├── 技术/ # 技术开发知识
│ ├── 开发规范.md
│ ├── 代码审查清单.md
│ ├── 部署流程.md
│ └── 故障排查手册.md
│
├── 设计/ # 设计资源知识
│ ├── UI 设计规范.md
│ ├── 品牌元素使用指南.md
│ └── 设计评审清单.md
│
├── 运营/ # 通用运营知识
│ ├── 活动策划模板.md
│ ├── 数据分析方法.md
│ └── KPI 指标定义.md
│
└── 行政/ # 行政支持知识
├── 合同模板.md
├── 报销流程.md
└── 供应商管理指南.md
```
### 4.2 知识条目格式
```markdown
# {知识标题}
> 领域：{所属领域}
> 最后更新：{日期}
> 维护者：{责任人}
---
## 概述
{简短说明知识的用途和价值}
## 适用范围
{说明在什么场景下使用此知识}
## 核心内容
{知识的主体内容，可以是 SOP、模板、规范等}
## 操作步骤
1. {步骤 1}
2. {步骤 2}
3. {步骤 3}
## 质量检查
- [ ] {检查项 1}
- [ ] {检查项 2}
## 常见问题
**Q**: {问题}
**A**: {答案}
## 相关资源
- [相关链接 1](url)
- [相关链接 2](url)
## 版本历史
| 版本 | 日期 | 变更内容 | 作者 |
|------|------|----------|------|
| v1.0 | 2026-06-22 | 初稿 | 陆怀瑾 |
```
---
## 五、Agent 查询流程
### 5.1 查询触发条件
Agent 在以下场景应主动查询知识库：
| 场景 | 查询内容 | 工具 |
|------|----------|------|
| 执行新类型任务 | SOP、模板 | `wiki_search` |
| 遇到未知问题 | 故障排查手册 | `wiki_search` |
| 撰写文档 | 文档模板 | `wiki_get` |
| 制定计划 | 最佳实践 | `wiki_search` |
| 质量检查 | 检查清单 | `wiki_get` |
### 5.2 查询流程
```
Agent 需要知识
↓
构造查询语句
↓
调用 wiki_search(query)
↓
┌─────┴─────┐
│ │
找到结果 未找到
│ │
读取内容 记录需求
│ (通知 COO)
用于决策
↓
不进入配置文件
```
### 5.3 查询示例
```python
# 示例：淘宝运营 Agent 需要查询"淘宝活动报名 SOP"
query = "淘宝 活动报名 SOP"
results = wiki_search(query)
if results:
# 获取最相关的条目
best_match = results[0]
content = wiki_get(best_match.path)
# 使用内容指导操作
follow_sop(content)
else:
# 记录知识缺口
log_knowledge_gap(query)
notify_coo("缺少知识库：淘宝活动报名 SOP")
```
---
## 六、人类审查机制
### 6.1 Web UI 访问
**Obsidian Web UI**：
- 浏览知识库目录结构
- 搜索知识条目
- 编辑知识内容
- 查看版本历史
**飞书文档同步**（可选）：
- 知识库自动同步到飞书文档
- 支持多人协作编辑
- 支持评论和批注
### 6.2 知识审核流程
```
Agent 发现知识缺口
↓
创建知识草稿
↓
通知 COO 审核
↓
COO 审核（通过/修改/拒绝）
↓
发布到知识库
↓
通知相关 Agent
```
### 6.3 质量检查
定期运行 `wiki_lint` 检查：
- 断裂链接
- 缺失引用
- 矛盾信息
- 过时内容
---
## 七、知识创建流程
### 7.1 创建触发
| 触发源 | 场景 | 处理流程 |
|--------|------|----------|
| Agent 发现缺口 | 查询无结果 | 记录缺口 → 通知 COO |
| 人类审查发现 | 知识结构不完整 | 直接创建/编辑 |
| 项目总结 | 项目完成后 | 沉淀经验到知识库 |
| 流程优化 | SOP 更新 | 版本化更新 |
### 7.2 创建规范
```python
def create_knowledge_entry(title, domain, content):
# 1. 检查是否已存在
existing = wiki_search(title)
if existing:
# 已存在，走更新流程
return update_knowledge_entry(existing[0].id, content)
# 2. 创建新条目
path = f"knowledge/{domain}/{title}.md"
wiki_apply(
op="create_synthesis",
title=title,
body=content,
sourceIds=[]
)
# 3. 更新索引
update_knowledge_index(domain, title, path)
# 4. 通知相关方
notify_coo(f"新知识库条目：{path}")
```
---
## 八、实施步骤
### 阶段 1：初始化（本周）
- [ ] 创建 knowledge/ 目录结构
- [ ] 编写各领域 README.md
- [ ] 建立初始知识条目（SOP、模板）
### 阶段 2：填充（下周）
- [ ] 迁移现有 SOP 到知识库
- [ ] 补充各领域核心知识
- [ ] 测试 Agent 查询流程
### 阶段 3：优化（持续）
- [ ] 建立知识审核机制
- [ ] 定期 wiki_lint 检查
- [ ] 收集 Agent 反馈，补充缺口
---
## 九、风险与对策
| 风险 | 影响 | 对策 |
|------|------|------|
| 知识库内容过期 | Agent 决策错误 | 定期审核 + 版本管理 |
| 查询结果不相关 | Agent 找不到知识 | 优化检索 + 关键词标签 |
| 人类审查不及时 | 知识积压 | 设置 SLA（48h 内审核） |
| 知识与 Memory 混淆 | 概念混乱 | 明确分工 + Agent 培训 |
---
## 十、交付物清单
- [ ] knowledge/ 目录结构
- [ ] 初始知识条目（至少 10 个）
- [ ] Agent 查询指南
- [ ] 人类审查 Web UI URL
- [ ] 知识审核 SOP
- [ ] 质量检查脚本
---
> ⚠️ 本方案需 Vincent 审阅后方可实施。审阅前不修改任何 Agent 配置文件。
plans/BIZ-15_配置文件持续优化方案.md
+464
View File
@@ -0,0 +1,464 @@
# BIZ-15 智能体配置文件持续优化方案
> 版本：v1.0
> 编制：陆怀瑾（COO）
> 日期：2026-06-22
> 状态：待审阅
---
## 一、目标
建立配置文件持续优化机制，通过定时任务每周检查并优化所有智能体的配置文件，核心策略是**"引用代替填塞"**，避免 Token 无谓增长。
---
## 二、问题分析
### 2.1 当前配置文件的 Token 浪费
| 文件 | 典型问题 | Token 浪费 |
|------|----------|----------|
| AGENTS.md | 嵌入全部 Agent 详细信息 | 3000+ tokens |
| SOUL.md | 嵌入完整的 SOP 模板 | 2000+ tokens |
| TOOLS.md | 嵌入工具使用详情 | 1500+ tokens |
| MEMORY.md | 未归档的历史记忆堆积 | 5000+ tokens |
**总计浪费**：~11,500 tokens/Agent
### 2.2 根本原因
1. **内联而非引用**：详细内容直接写入配置文件，而非引用外部文档
2. **缺乏归档机制**：历史记忆不断累积，从不归档清理
3. **无优化检查**：没有定期检查和优化机制
---
## 三、核心策略：引用代替填塞
### 3.1 优化前后对比
**优化前（错误做法）**：
```markdown
# AGENTS.md
## 团队成员详情
### 刘诗妮（secretary）
- Feishu ID: ou_6201fa2f987300046ca659cf231f1d3f
- 核心职能：业务入口、进度跟进、飞书对接
- 工作模式：不进项目，专职支持 Vincent
- 可用时间：工作日 9:00-18:00
- 技能清单：...
- 联系方式：...
（每个 Agent 都有 300+ tokens 的详细信息）
### 陆怀瑾（coo）
...
（共 12 个 Agent，总计 3600+ tokens）
```
**优化后（正确做法）**：
```markdown
# AGENTS.md
## 团队成员详情
完整 Agent 信息请参阅：[docs/agent-roster.md](docs/agent-roster.md)
核心协作协议：
| Agent | 核心职能 | 何时联系 |
|-------|----------|----------|
| secretary | 业务入口/进度跟进 | 任务接收、结果汇报 |
| coo | 资源协调/风险 | 资源协调、风险识别 |
...
（仅保留核心协作表，200 tokens）
```
### 3.2 可外部化的内容
| 配置文件 | 可外部化内容 | 外部文档路径 |
|----------|--------------|--------------|
| AGENTS.md | Agent 详细信息 | docs/agent-roster.md |
| AGENTS.md | 协作流程图 | docs/collaboration-flow.md |
| SOUL.md | SOP 模板 | docs/sop-templates/ |
| SOUL.md | 个性描述详情 | docs/persona-details/ |
| TOOLS.md | 工具使用详情 | docs/tools-reference.md |
| MEMORY.md | 超过 30 天的记忆 | memory/archive/YYYY-MM/ |
---
## 四、每周优化流程
### 4.1 流程概览
```
定时任务触发（每周日凌晨 2:00）
↓
扫描所有 Agent 配置文件
↓
检测内联冗余内容
↓
生成优化建议报告
↓
┌─────┴─────┐
│ │
自动优化 需人工审批
(低风险) (高风险)
↓ ↓
执行优化 COO 审批 → 执行
↓
更新优化日志
↓
通知 COO
```
### 4.2 检测规则
#### 规则 1：大段内联内容检测
```python
def detect_inline_blocks(file_path):
"""检测超过 N 行的内联内容块"""
with open(file_path) as f:
lines = f.readlines()
blocks = []
current_block = []
in_code_block = False
for i, line in enumerate(lines):
if line.startswith('```'):
in_code_block = not in_code_block
continue
if in_code_block:
continue
# 检测密集内容（无空行的连续行）
if line.strip() and (not current_block or lines[i-1].strip()):
current_block.append((i+1, line))
else:
if len(current_block) >= 20: # 20 行阈值
blocks.append({
'start': current_block[0][0],
'end': current_block[-1][0],
'lines': len(current_block),
'preview': ''.join([l for _, l in current_block[:5]])
})
current_block = []
return blocks
```
#### 规则 2：重复内容检测
```python
def detect_duplicates(config_files):
"""检测多个配置文件中的重复内容"""
content_hashes = {}
duplicates = []
for file_path in config_files:
with open(file_path) as f:
content = f.read()
# 分块计算 hash
blocks = split_into_blocks(content)
for block in blocks:
h = hash(block)
if h in content_hashes:
duplicates.append({
'content': block[:100] + '...',
'files': [content_hashes[h], file_path]
})
else:
content_hashes[h] = file_path
return duplicates
```
#### 规则 3：引用缺失检测
```python
def detect_missing_refs(file_path, docs_dir):
"""检测应该引用但未引用的外部文档"""
known_externalizable = [
'SOP 模板', '岗位说明书', '工具详情', '流程图', '检查清单'
]
with open(file_path) as f:
content = f.read()
missing = []
for keyword in known_externalizable:
if keyword in content and 'docs/' not in content:
missing.append({
'keyword': keyword,
'suggestion': f'建议创建 docs/{keyword_to_filename(keyword)}.md 并引用'
})
return missing
```
### 4.3 优化建议报告格式
```markdown
# 配置文件优化报告
**检查时间**: 2026-06-22 02:00
**检查范围**: 所有 Agent 配置文件
---
## 概览
| 指标 | 数值 |
|------|------|
| 检查文件数 | 7 × 12 Agent = 84 |
| 发现冗余块 | 23 |
| 可优化 Token | 15,000 |
| 高风险变更 | 3 |
---
## 详细建议
### AGENTS.md (coo)
#### 建议 1：外部化 Agent 详情
- **位置**: 第 15-230 行
- **内容**: 12 个 Agent 的详细信息
- **建议**: 移动到 docs/agent-roster.md，AGENTS.md 仅保留协作表
- **节省**: 3,400 tokens
- **风险**: 低（只读引用）
#### 建议 2：外部化协作流程
- **位置**: 第 245-300 行
- **内容**: 开发 SOP 详细流程
- **建议**: 移动到 docs/sop-development.md，AGENTS.md 仅保留引用
- **节省**: 800 tokens
- **风险**: 低
---
### SOUL.md (secretary)
#### 建议 3：外部化 SOP 模板
- **位置**: 第 50-150 行
- **内容**: 完整 SOP 模板
- **建议**: 移动到 docs/sop-template.md，SOUL.md 仅保留引用
- **节省**: 1,500 tokens
- **风险**: 中（其他 Agent 可能引用）
---
## 自动优化建议
以下建议可自动执行（低风险）：
- [ ] 建议 1：外部化 Agent 详情
- [ ] 建议 2：外部化协作流程
以下建议需人工审批（中高风险）：
- [ ] 建议 3：外部化 SOP 模板（需确认无其他引用）
---
## 执行日志
执行后将在此处记录：
- 执行的优化项
- 跳过的优化项及原因
- Token 节省统计
```
---
## 五、优化工具实现
### 5.1 扫描脚本
```bash
#!/bin/bash
# optimize-configs.sh - 配置文件优化扫描脚本
WORKSPACE="/home/vincent/.openclaw/workspace/coo"
REPORT_FILE="$WORKSPACE/reports/$(date +%Y-%m-%d)_配置优化报告.md"
echo "# 配置文件优化报告" > "$REPORT_FILE"
echo "" >> "$REPORT_FILE"
echo "**检查时间**: $(date '+%Y-%m-%d %H:%M')" >> "$REPORT_FILE"
# 扫描所有 Agent 目录
for agent_dir in "$WORKSPACE"/agent-*/; do
agent_name=$(basename "$agent_dir")
echo "扫描 $agent_name..."
# 检查各配置文件
for config in AGENTS.md SOUL.md TOOLS.md MEMORY.md; do
if [ -f "$agent_dir/$config" ]; then
# 运行检测规则
python3 detect_redundancy.py "$agent_dir/$config" >> "$REPORT_FILE"
fi
done
done
echo "报告已生成：$REPORT_FILE"
```
### 5.2 自动优化脚本
```python
#!/usr/bin/env python3
# auto-optimize.py - 自动执行低风险优化
import sys
import os
def extract_and_replace(file_path, start_line, end_line, external_doc_path):
"""提取内容到外部文档，并替换为引用"""
# 读取原文件
with open(file_path, 'r') as f:
lines = f.readlines()
# 提取内容
extracted = ''.join(lines[start_line-1:end_line])
# 写入外部文档
os.makedirs(os.path.dirname(external_doc_path), exist_ok=True)
with open(external_doc_path, 'w') as f:
f.write(extracted)
# 替换为引用
ref_line = f"\n详细内容请参阅：[{external_doc_path}]({external_doc_path})\n"
new_lines = lines[:start_line-1] + [ref_line] + lines[end_line:]
with open(file_path, 'w') as f:
f.writelines(new_lines)
return len(extracted.split()) # 返回节省的字数估算
```
---
## 六、定时任务配置
### 6.1 Cron 配置
```cron
# 每周日凌晨 2:00 执行配置文件优化检查
0 2 * * 0 /home/vincent/.openclaw/workspace/coo/scripts/optimize-configs.sh
```
### 6.2 任务执行流程
```
Cron 触发
↓
运行扫描脚本
↓
生成优化报告
↓
检查是否有低风险优化项
↓
┌─────┴─────┐
│ │
有 无
│ │
自动执行 仅通知
↓
更新报告
↓
通知 COO（飞书）
```
---
## 七、Token 节省估算
### 7.1 预期效果
| 配置文件 | 优化前 | 优化后 | 节省 |
|----------|--------|--------|------|
| AGENTS.md | 4,000 | 500 | 87.5% |
| SOUL.md | 3,500 | 800 | 77% |
| TOOLS.md | 2,500 | 400 | 84% |
| MEMORY.md | 5,000 | 2,000 | 60% |
| **总计/Agent** | **15,000** | **3,700** | **75%** |
### 7.2 全局影响
- **12 个 Agent** × 11,300 tokens = **135,600 tokens** 节省
- **每次对话** 节省上下文，提升响应速度
- **降低成本**：减少 Token 使用量
---
## 八、风险控制
### 8.1 风险等级划分
| 等级 | 标准 | 处理方式 |
|------|------|----------|
| 低 | 仅影响当前 Agent 的只读引用 | 自动执行 |
| 中 | 可能影响其他 Agent 的共享内容 | COO 审批 |
| 高 | 核心配置变更 | Vincent 审批 |
### 8.2 回滚机制
```bash
# 每次优化前自动备份
backup_file="$file_path.backup.$(date +%Y%m%d%H%M%S)"
cp "$file_path" "$backup_file"
# 如需回滚
cp "$backup_file" "$file_path"
```
### 8.3 变更日志
```markdown
# 配置文件优化日志
| 日期 | Agent | 文件 | 优化项 | 节省 Token | 执行者 |
|------|-------|------|--------|------------|--------|
| 2026-06-22 | coo | AGENTS.md | 外部化 Agent 详情 | 3,400 | auto |
| 2026-06-22 | coo | AGENTS.md | 外部化协作流程 | 800 | auto |
```
---
## 九、实施步骤
### 阶段 1：工具开发（本周）
- [ ] 编写检测规则脚本
- [ ] 编写自动优化脚本
- [ ] 编写报告生成脚本
- [ ] 测试工具链
### 阶段 2：首次优化（下周）
- [ ] 运行首次全面扫描
- [ ] 生成基线报告
- [ ] 人工审批后执行首批优化
- [ ] 验证优化效果
### 阶段 3：自动化（持续）
- [ ] 配置 Cron 定时任务
- [ ] 配置飞书通知
- [ ] 建立回滚和审计机制
---
## 十、交付物清单
- [ ] 配置文件优化检测脚本
- [ ] 自动优化工具
- [ ] 优化报告模板
- [ ] Cron 定时任务配置
- [ ] 变更日志模板
- [ ] 回滚脚本
---
> ⚠️ 本方案需 Vincent 审阅后方可实施。审阅前不修改任何 Agent 配置文件。