mm_ai 1.0.0

package/example/common/knowledge/agent/agent_collaboration_standards/knowledge.json

@@ -0,0 +1,7 @@
+{
+  "name": "agent_collaboration_standards",
+  "title": "智能体协作规范",
+  "description": "智能体间协作的通信协议、数据流转标准和协作规范",
+  "group": "agent",
+  "tags": ["call_agent", "call_agents", "master", "tool_maker", "project_manager", "task_manager", "skill_teacher"]
+}

package/example/common/knowledge/agent/agent_collaboration_standards/knowledge.md

@@ -0,0 +1,157 @@
+# 智能体协作规范
+
+## 1. 智能体间通信基本原则
+
+### 1.1 通信发起规范
+
+| 原则 | 说明 | 示例 |
+|:-----|:------|:------|
+| **谁发起谁负责** | 发起呼叫的智能体需明确说明任务目标、期望输出和截止要求 | Master → ToolMaker：`请为 project_a 创建数据库表结构工具` |
+| **一次一任务** | 每次 `call_agent` / `call_agents` 只委派一个明确任务，避免多个任务混在一起 | ✅ 正确：`请创建用户管理模块的API接口`<br>❌ 错误：`请创建API接口，顺便把前端页面也写了，再看看数据库有没有问题` |
+| **上下文完备** | 发起者必须在 content 中提供当前项目、任务背景、前置结果等必要上下文 | 参见下方 §1.3 |
+| **指定接收者** | 明确指定接收的智能体名称（receiver），避免模糊指派 | `receiver: "tool_maker"` ✅ / `receiver: "某个会开发的智能体"` ❌ |
+
+### 1.2 通信响应规范
+
+| 原则 | 说明 |
+|:-----|:------|
+| **及时确认** | 接收者收到呼叫后，应尽快响应。若正忙，通过 `get_agent_status` 返回忙闲状态 |
+| **明确结果** | 响应内容需明确告知：任务是否完成、输出物位置、遇到的问题 |
+| **结果格式化** | 结果使用 Markdown 结构化输出，包含：任务名、完成状态、输出文件路径、异常说明 |
+
+### 1.3 上下文传递规范
+
+发起者呼叫其他智能体时，content 消息应包含以下结构：
+
+```markdown
+## 📋 上下文信息
+- **项目名称**：{project_name}
+- **任务名称**：{task_name}
+- **前置结果**：{已完成的前置任务及输出物}
+- **当前进度**：{任务当前执行阶段}
+
+## 📝 任务内容
+{具体要执行的任务描述，包括输入参数、期望输出、约束条件等}
+```
+
+## 2. 数据流转规范
+
+### 2.1 文件传递格式
+
+| 数据类型 | 推荐格式 | 说明 |
+|:---------|:---------|:------|
+| 结构化数据 | JSON | 用于配置、结果、状态等结构化信息交换 |
+| 文档报告 | Markdown | 用于方案、报告、说明文档等 |
+| 代码文件 | 源码原格式 | 使用文件路径传递，不嵌入消息体中 |
+| 图片/素材 | 文件路径 + 格式说明 | 通过 files 参数传递路径 |
+
+### 2.2 路径约定
+
+| 场景 | 路径规范 | 示例 |
+|:-----|:---------|:------|
+| 项目文件 | `./project/{project_name}/` | `./project/system_optimization/` |
+| 工具文件 | `./tool/{group}/{tool_name}/` | `./tool/agent/call_agents/` |
+| 技能文件 | `./skill/{group}/{skill_name}/` | `./skill/agent/innovation_skill/` |
+| 工作提示词 | `./work/{group}/{work_name}/` | `./work/agent/write_skill_prompt/` |
+| 常识知识 | `./knowledge/{group}/{name}/` | `./knowledge/agent/collaboration_standards/` |
+| 临时结果 | `./project/{project_name}/.temp/` | `./project/system_optimization/.temp/` |
+
+### 2.3 文件传递协议
+
+1. **小数据**（< 10KB）：直接嵌入 content 消息体
+2. **中数据**（10KB ~ 100KB）：通过 files 参数传递文件路径
+3. **大数据**（> 100KB）：写入项目临时目录，传递路径 + 摘要说明
+
+## 3. 协作失败处理机制
+
+### 3.1 超时处理
+
+| 超时类型 | 阈值 | 处理方式 |
+|:---------|:-----|:---------|
+| 响应超时 | 30秒 | 发起者重试一次，若仍无响应则标记为"无响应" |
+| 执行超时 | 5分钟（默认） | 发起者检查智能体状态，决定是否继续等待或切换方案 |
+| 整体超时 | 项目自定义 | 由 master 根据项目计划设定整体超时阈值 |
+
+### 3.2 重试机制
+
+```
+重试策略（指数退避）：
+  第1次失败 → 立即重试
+  第2次失败 → 等待 10秒 后重试
+  第3次失败 → 等待 30秒 后重试
+  第4次失败 → 标记为"重试耗尽"，进入升级流程
+```
+
+### 3.3 升级流程
+
+当重试耗尽或出现严重错误时，按以下流程升级处理：
+
+```
+Level 1：发起者自行处理
+  → 尝试更换接收者（如 tool_maker 忙，改找 developer）
+  → 或简化任务要求
+
+Level 2：通知 master
+  → 发起者向 master 报告失败详情
+  → 包括：任务描述、失败的智能体、失败原因、已尝试的补救措施
+
+Level 3：人工介入
+  → master 评估是否需人工处理
+  → 或调整项目计划，跳过/推迟该任务
+```
+
+### 3.4 错误码规范
+
+| 错误码 | 含义 | 说明 |
+|:-------|:-----|:------|
+| `E_TIMEOUT` | 响应/执行超时 | 智能体未在预期时间内响应或完成 |
+| `E_BUSY` | 智能体正忙 | 目标智能体当前正在执行其他任务 |
+| `E_INVALID_PARAMS` | 参数错误 | 发起者传入的参数不符合要求 |
+| `E_EXECUTION_FAILED` | 执行失败 | 智能体执行任务过程中出现异常 |
+| `E_NOT_FOUND` | 资源不存在 | 指定的项目/任务/文件不存在 |
+| `E_PERMISSION_DENIED` | 权限不足 | 当前智能体无权限执行该操作 |
+
+## 4. 多智能体协作时的上下文隔离规则
+
+### 4.1 会话隔离
+
+| 规则 | 说明 |
+|:-----|:------|
+| **每个智能体独立会话** | 每个被呼叫的智能体使用独立的 session_id 执行任务，互不干扰 |
+| **会话生命周期** | 会话从 `call_agent` 开始，到智能体返回结果后结束 |
+| **状态隔离** | 智能体 A 的待办事项、临时文件不影响智能体 B |
+
+### 4.2 数据隔离
+
+| 数据类型 | 隔离策略 |
+|:---------|:---------|
+| 项目文件 | 共享读写，通过路径约定避免冲突 |
+| 临时文件 | 每个智能体使用独立临时目录：`./project/{project_name}/.temp/{agent_name}/` |
+| 待办事项 | 每个智能体仅能读写自己的待办事项 |
+| 会话上下文 | 每个会话独立，不跨会话共享 |
+
+### 4.3 并行协作规则
+
+当使用 `call_agents` 并行呼叫多个智能体时：
+
+1. **任务分割**：发起者需明确划分各智能体的工作边界，避免职责重叠
+2. **依赖声明**：若智能体 B 依赖智能体 A 的输出，应在任务描述中声明依赖关系
+3. **结果合并**：发起者负责收集各智能体的结果，进行冲突检测和合并
+4. **锁机制**：同一文件在同一时刻只能被一个智能体写入，通过临时锁定文件 `{file}.lock` 实现
+
+### 4.4 上下文传递链
+
+```
+Master
+  ├── call_agent → Agent_A（项目初始化）
+  │     └── 返回结果：项目目录结构、配置文件
+  ├── call_agent → Agent_B（数据库设计）← 依赖 Agent_A 的输出
+  │     └── 返回结果：数据库表结构、SQL脚本
+  └── call_agent → Agent_C（API开发）← 依赖 Agent_B 的输出
+        └── 返回结果：API接口代码、路由配置
+```
+
+**上下文传递规则**：
+- 每个后继智能体的 content 中需包含前置智能体的关键输出摘要
+- 完整输出文件通过 files 参数传递，不嵌入消息体
+- 发起者（通常是 master）负责维护上下文链的完整性

package/example/common/knowledge/agent/agent_config_registration_standards/knowledge.json

@@ -0,0 +1,7 @@
+{
+  "name": "agent_config_registration_standards",
+  "title": "智能体配置注册规范",
+  "description": "智能体agent.json配置文件的注册规范，确保提示词文件被正确加载",
+  "group": "agent",
+  "tags": ["master", "skill_teacher", "hr_manager", "agent_development"]
+}

package/example/common/knowledge/agent/agent_config_registration_standards/knowledge.md

@@ -0,0 +1,294 @@
+# 智能体配置注册规范
+
+## 1. agent.json 中 prompt_files 字段的配置规则
+
+### 1.1 配置文件位置
+
+每个智能体的配置文件位于智能体根目录下的 `agent.json`：
+
+```
+./agent/{agent_name}/
+├── agent.json          # 智能体配置文件（核心）
+├── prompt/             # 提示词文件目录
+│   ├── role.md         # 角色定义
+│   ├── soul.md         # 核心人格
+│   ├── can.md          # 能力说明
+│   ├── should.md       # 职责权限
+│   ├── ability.md      # 技能列表
+│   ├── stakeholder.md  # 干系人
+│   └── workflow.md     # 工作流程
+└── ...                 # 其他资源文件
+```
+
+### 1.2 prompt_files 字段结构
+
+```json
+{
+  "prompt_files": {
+    "role": "./prompt/role.md",
+    "soul": "./prompt/soul.md",
+    "can": "./prompt/can.md",
+    "should": "./prompt/should.md",
+    "ability": "./prompt/ability.md",
+    "stakeholder": "./prompt/stakeholder.md",
+    "workflow": "./prompt/workflow.md"
+  }
+}
+```
+
+### 1.3 路径填写规则
+
+| 规则 | 说明 | ✅ 正确 | ❌ 错误 |
+|:-----|:------|:---------|:---------|
+| **相对路径** | 相对于 agent.json 所在目录 | `./prompt/role.md` | `/absolute/path/role.md` |
+| **以 ./ 开头** | 路径必须以 `./` 开头 | `./prompt/role.md` | `prompt/role.md` |
+| **小写 + 蛇形** | 文件名全小写，用下划线连接 | `./prompt/my_role.md` | `./prompt/MyRole.md` |
+| **后缀为 .md** | 提示词文件必须为 Markdown 格式 | `./prompt/role.md` | `./prompt/role.txt` |
+| **无空格** | 路径和文件名中不能包含空格 | `./prompt/workflow.md` | `./prompt/work flow.md` |
+
+---
+
+## 2. 7个必需提示词文件的注册要求
+
+### 2.1 文件清单
+
+| 序号 | 键名 | 文件名 | 说明 | 是否必需 |
+|:-----|:-----|:-------|:-----|:---------|
+| 1 | `role` | `role.md` | **角色定义**：智能体的身份、名称、核心定位 | ✅ 必需 |
+| 2 | `soul` | `soul.md` | **核心人格**：智能体的性格特征、表达风格、价值观 | ✅ 必需 |
+| 3 | `can` | `can.md` | **能力说明**：智能体可以做什么，掌握的工具列表 | ✅ 必需 |
+| 4 | `should` | `should.md` | **职责权限**：应该做的事、不该做的事、能自己决定的事、不能碰的事 | ✅ 必需 |
+| 5 | `ability` | `ability.md` | **技能列表**：智能体掌握的技能名称和简要说明 | ✅ 必需 |
+| 6 | `stakeholder` | `stakeholder.md` | **干系人**：智能体的协作关系、谁能帮谁、谁能找谁 | ✅ 必需 |
+| 7 | `workflow` | `workflow.md` | **工作流程**：智能体的标准工作流程和步骤 | ✅ 必需 |
+
+### 2.2 各文件内容要求
+
+#### role.md（角色定义）
+
+```markdown
+你的英文名称是{agent_name}，中文名称是{agent_title}。
+{核心定位描述，1-2句话说明智能体是什么、主要干什么}
+```
+
+#### soul.md（核心人格）
+
+```markdown
+# 人格特征
+{智能体的性格特征、沟通风格、决策偏好}
+
+# 价值观
+{智能体的核心价值观和行为准则}
+
+# 表达风格
+{语言风格偏好，如简洁/详细、正式/轻松等}
+```
+
+#### can.md（能力说明）
+
+```markdown
+# 掌握的工具
+{列出智能体可以调用的工具列表及简要说明}
+
+# 掌握的知识
+{列出智能体已学习的常识知识领域}
+```
+
+#### should.md（职责权限）
+
+```markdown
+## 职责权限
+
+### ✅ 应该做的事
+{列举智能体的核心职责}
+
+### ❌ 不该做的事
+{列举智能体的禁止行为}
+
+### 🟢 能自己决定的事
+{列举智能体可自主决策的事项}
+
+### 🔴 绝对不能碰的事
+{列举智能体绝对不能触碰的高风险事项}
+
+### 🟡 要先问过 master 的事
+{列举需要请示 master 的事项}
+```
+
+#### ability.md（技能列表）
+
+```markdown
+## 掌握的技能
+
+{技能名称}({技能英文名}): {技能描述，含触发关键词}
+```
+
+#### stakeholder.md（干系人）
+
+```markdown
+## 干系人协作关系
+
+### 🤝 你能帮什么人干什么
+{列出你能帮助的智能体/角色，以及你能提供的帮助}
+
+### 🔍 你能找什么人帮你做什么
+{列出你能求助的智能体/角色，以及他们能提供的帮助}
+```
+
+#### workflow.md（工作流程）
+
+```markdown
+# 工作流程
+
+{标准工作流程的步骤描述，通常包含：接需求 → 分析 → 执行 → 检查 → 交付}
+```
+
+### 2.3 完整配置示例
+
+```json
+{
+  "name": "skill_teacher",
+  "title": "技能导师",
+  "description": "负责智能体技能提示词的创作与优化",
+  "prompt_files": {
+    "role": "./prompt/role.md",
+    "soul": "./prompt/soul.md",
+    "can": "./prompt/can.md",
+    "should": "./prompt/should.md",
+    "ability": "./prompt/ability.md",
+    "stakeholder": "./prompt/stakeholder.md",
+    "workflow": "./prompt/workflow.md"
+  }
+}
+```
+
+---
+
+## 3. 常见配置错误及排查方法
+
+### 3.1 常见错误清单
+
+| 错误类型 | 错误现象 | 原因 | 排查方法 |
+|:---------|:---------|:-----|:---------|
+| **文件缺失** | 启动时报 `ENOENT: no such file or directory` | prompt_files 中配置的文件实际不存在 | 检查 `./agent/{name}/prompt/` 目录下是否有对应文件 |
+| **路径错误** | 智能体加载时提示文件找不到 | prompt_files 中的路径写错了 | 检查路径是否以 `./` 开头，文件名是否拼写正确 |
+| **键名缺失** | 智能体行为异常，缺少某方面提示词 | prompt_files 中缺少某个必需键（如 `soul`） | 对照 §2.1 的7个必需键逐一核对 |
+| **格式错误** | 智能体无法解析配置文件 | agent.json 不是合法 JSON 格式 | 使用 JSON 校验工具检查，注意末尾不能有多余逗号 |
+| **编码问题** | 提示词中的中文显示为乱码 | 文件编码不是 UTF-8 | 将文件编码改为 UTF-8（无 BOM） |
+| **空文件** | 智能体加载成功但相关功能无响应 | prompt_files 指向的文件内容为空 | 检查文件是否包含有效内容 |
+| **键名拼写** | 某方面提示词未生效 | prompt_files 中的键名拼写错误（如 `stakeholder` 写成 `stakeholder`） | 对照 §2.1 的键名列表逐字核对 |
+
+### 3.2 快速排查流程
+
+```
+智能体配置异常
+    │
+    ├── 检查 agent.json 是否存在
+    │   └── ❌ 不存在 → 创建 agent.json
+    │
+    ├── 检查 agent.json 是否为合法 JSON
+    │   └── ❌ 不合法 → 修复 JSON 格式（注意逗号、引号）
+    │
+    ├── 检查 prompt_files 字段是否存在
+    │   └── ❌ 不存在 → 添加 prompt_files 字段
+    │
+    ├── 检查 7 个必需键是否齐全
+    │   └── ❌ 缺少 → 补充缺失的键和对应的文件
+    │
+    ├── 检查每个文件路径是否正确
+    │   └── ❌ 路径错误 → 修正为正确相对路径
+    │
+    ├── 检查每个文件是否存在
+    │   └── ❌ 不存在 → 创建缺失的提示词文件
+    │
+    ├── 检查每个文件编码是否为 UTF-8
+    │   └── ❌ 编码错误 → 转换为 UTF-8（无 BOM）
+    │
+    └── 检查每个文件内容是否非空
+        └── ❌ 空文件 → 写入有效提示词内容
+```
+
+### 3.3 诊断命令参考
+
+```bash
+# 1. 检查 agent.json 是否存在
+ls -la ./agent/{agent_name}/agent.json
+
+# 2. 检查 JSON 格式
+cat ./agent/{agent_name}/agent.json | python -m json.tool
+
+# 3. 检查 prompt_files 中配置的文件是否存在
+cat ./agent/{agent_name}/agent.json | grep -o '"[^"]*\.md"' | xargs -I {} sh -c 'test -f "./agent/{agent_name}/{}" && echo "✅ {} 存在" || echo "❌ {} 不存在"'
+
+# 4. 检查文件编码
+file -i ./agent/{agent_name}/prompt/role.md
+
+# 5. 检查文件是否为空
+wc -l ./agent/{agent_name}/prompt/*.md
+```
+
+---
+
+## 4. 配置修改后的生效机制
+
+### 4.1 生效规则
+
+| 修改类型 | 生效时机 | 说明 |
+|:---------|:---------|:-----|
+| **修改 agent.json** | 重启服务后生效 | agent.json 在服务启动时加载，修改后需重启 |
+| **修改 prompt/*.md** | 下次会话生效 | 提示词文件在每次会话开始时重新加载 |
+| **新增 prompt/*.md 文件** | 需更新 agent.json 并重启 | 新增文件需先在 agent.json 中注册路径 |
+| **删除 prompt/*.md 文件** | 需更新 agent.json 并重启 | 删除文件后需从 agent.json 中移除对应键 |
+
+### 4.2 配置修改流程
+
+```
+修改配置 → 验证配置 → 重启/重载 → 功能测试
+```
+
+**详细步骤**：
+
+1. **修改配置**
+   - 编辑 agent.json 或 prompt/*.md 文件
+   - 确保修改内容符合规范
+
+2. **验证配置**
+   - 检查 JSON 格式是否合法
+   - 检查所有文件路径是否存在
+   - 检查文件编码是否为 UTF-8
+
+3. **重启/重载**
+   - 修改 agent.json → 需要重启服务
+   - 仅修改 prompt/*.md → 新会话自动生效，无需重启
+
+4. **功能测试**
+   - 发起一个测试会话，验证修改是否生效
+   - 检查智能体的行为是否符合预期
+
+### 4.3 热重载说明
+
+当前系统不支持热重载 agent.json。修改 agent.json 后必须重启服务才能生效。
+
+对于 prompt/*.md 文件的修改，虽然无需重启服务，但需要注意：
+- 当前正在进行的会话不会重新加载提示词
+- 新发起的会话会自动加载最新的提示词内容
+- 如果修改涉及核心行为逻辑，建议重启服务确保一致性
+
+### 4.4 版本管理建议
+
+```json
+{
+  "name": "agent_name",
+  "version": "1.0.0",
+  "last_modified": "2026-06-30",
+  "changelog": [
+    {
+      "date": "2026-06-30",
+      "version": "1.0.0",
+      "changes": ["初始创建 agent.json 和 7 个提示词文件"]
+    }
+  ]
+}
+```
+
+建议在 agent.json 中维护版本信息和变更日志，方便追溯配置修改历史。

package/example/common/knowledge/project/project_management_basics/knowledge.json

@@ -0,0 +1,7 @@
+{
+  "name": "project_management_basics",
+  "title": "项目管理常识",
+  "description": "项目全生命周期各阶段的产出物标准和文档规范",
+  "group": "project",
+  "tags": ["master", "project_manager", "task_manager", "skill_teacher", "tool_maker", "hr_manager"]
+}

package/example/common/knowledge/project/project_management_basics/knowledge.md

@@ -0,0 +1,202 @@
+# 项目管理常识
+
+## 1. 项目各阶段的标准产出物
+
+### 1.1 启动阶段（Initiation）
+
+| 产出物 | 格式 | 说明 | 负责人 |
+|:-------|:-----|:------|:-------|
+| 项目章程（Project Charter） | Markdown | 项目名称、背景、目标、范围、关键干系人 | Master |
+| 项目需求文档（Requirements） | Markdown | 用户需求、功能需求、非功能需求清单 | Project Manager |
+| 干系人登记册（Stakeholder Register） | Markdown/JSON | 项目参与人员/智能体列表、角色、职责 | HR Manager |
+
+**文件路径**：`./project/{project_name}/charter.md`
+
+### 1.2 规划阶段（Planning）
+
+| 产出物 | 格式 | 说明 | 负责人 |
+|:-------|:-----|:------|:-------|
+| 项目计划书（Project Plan） | Markdown | 里程碑、任务分解、时间线、资源分配 | Project Manager |
+| 任务分解结构（WBS） | Markdown/JSON | 将项目分解为可执行的任务单元 | Task Manager |
+| 技能需求清单（Skill Requirements） | Markdown | 项目所需的智能体技能列表 | HR Manager / Skill Teacher |
+| 风险评估报告（Risk Assessment） | Markdown | 识别风险、评估影响、制定应对措施 | Project Manager |
+| 工具需求清单（Tool Requirements） | Markdown | 项目所需的工具列表 | Tool Maker |
+
+**文件路径**：`./project/{project_name}/plan/`
+
+### 1.3 执行阶段（Execution）
+
+| 产出物 | 格式 | 说明 | 负责人 |
+|:-------|:-----|:------|:-------|
+| 任务执行记录（Task Logs） | Markdown/JSON | 每个任务的执行过程、决策记录 | 各执行智能体 |
+| 代码/设计产出（Deliverables） | 按类型定 | 实际的代码、设计稿、文档等产出物 | 各执行智能体 |
+| 进度报告（Progress Report） | Markdown | 定期（每日/每周）汇报执行进度 | Task Manager |
+
+**文件路径**：`./project/{project_name}/execution/`
+
+### 1.4 监控阶段（Monitoring & Controlling）
+
+| 产出物 | 格式 | 说明 | 负责人 |
+|:-------|:-----|:------|:-------|
+| 质量检查报告（Quality Report） | Markdown | 对产出物进行质量检查的结果 | 相关执行智能体 |
+| 变更请求（Change Request） | Markdown | 需求/范围/计划的变更申请 | Project Manager |
+| 问题日志（Issue Log） | Markdown | 记录项目执行过程中遇到的问题和解决方案 | Task Manager |
+
+**文件路径**：`./project/{project_name}/monitor/`
+
+### 1.5 收尾阶段（Closure）
+
+| 产出物 | 格式 | 说明 | 负责人 |
+|:-------|:-----|:------|:-------|
+| 项目总结报告（Project Summary） | Markdown | 项目成果、经验教训、数据统计 | Project Manager |
+| 验收报告（Acceptance Report） | Markdown | 项目交付物的验收结果 | Master |
+| 知识归档（Knowledge Archive） | Markdown | 项目中沉淀的知识、规范、最佳实践 | 全体参与智能体 |
+| 使用指南（Usage Guide） | Markdown | 项目产出物的使用说明文档 | Tool Maker / Developer |
+
+**文件路径**：`./project/{project_name}/closure/`
+
+---
+
+## 2. 项目文档命名和组织规范
+
+### 2.1 文档命名规则
+
+| 规则 | 说明 | ✅ 正确 | ❌ 错误 |
+|:-----|:------|:---------|:---------|
+| **小写蛇形** | 全小写，单词间用下划线连接 | `project_plan.md` | `ProjectPlan.md` |
+| **语义化** | 名称体现文档用途 | `risk_assessment.md` | `doc1.md` |
+| **版本可选** | 多版本时加 v{数字} | `design_v2.md` | `design_final_v3_really.md` |
+| **日期可选** | 按日期归档时用 YYYY-MM-DD | `report_2026-06-30.md` | `0630_report.md` |
+
+### 2.2 目录组织规范
+
+```
+./project/{project_name}/
+├── charter.md                    # 项目章程
+├── plan/                         # 规划阶段文档
+│   ├── project_plan.md           # 项目计划书
+│   ├── wbs.md                    # 任务分解结构
+│   ├── skill_requirements.md     # 技能需求清单
+│   ├── risk_assessment.md        # 风险评估报告
+│   └── tool_requirements.md      # 工具需求清单
+├── execution/                    # 执行阶段产出
+│   ├── task_logs/                # 任务执行记录
+│   └── deliverables/             # 交付物
+├── monitor/                      # 监控阶段文档
+│   ├── quality_report.md         # 质量检查报告
+│   ├── change_requests/          # 变更请求
+│   └── issue_log.md              # 问题日志
+├── closure/                      # 收尾阶段文档
+│   ├── project_summary.md        # 项目总结
+│   ├── acceptance_report.md      # 验收报告
+│   ├── knowledge_archive/        # 知识归档
+│   └── usage_guide.md            # 使用指南
+├── .temp/                        # 临时文件（不提交）
+└── test/                         # 测试相关
+    ├── test_report.md            # 测试报告
+    └── test_scripts/             # 测试脚本
+```
+
+### 2.3 文档头信息规范
+
+每个项目文档应在开头包含元数据块：
+
+```markdown
+# 文档标题
+
+> **编制人**：{智能体名称}
+> **编制日期**：{YYYY-MM-DD}
+> **版本**：v{主版本}.{次版本}
+> **状态**：草稿 / 评审中 / 已定稿 / 已归档
+> **关联文档**：[项目计划](./plan/project_plan.md)、[需求文档](./charter.md)
+
+---
+```
+
+---
+
+## 3. 项目路径规范
+
+### 3.1 统一根路径
+
+所有项目文件统一存放在 `./project/{project_name}/` 目录下。
+
+| 规则 | 说明 |
+|:-----|:------|
+| **根路径** | `./project/{project_name}/` |
+| **项目名称** | 小写蛇形，如 `system_optimization`、`ai_secretary` |
+| **路径分隔符** | 统一使用 `/`（正斜杠），不使用 `\` |
+| **绝对路径** | 在代码和配置中使用绝对路径，如 `E:\\gitee\\mm_modules_ok\\mm_ai\\example\\project\\system_optimization\\` |
+
+### 3.2 跨项目引用
+
+当需要引用其他项目的产出物时：
+
+```
+引用格式：[项目名:文件路径]
+示例：[system_optimization:plan/project_plan.md]
+```
+
+跨项目引用需确保被引用的项目已完成并归档。
+
+### 3.3 临时文件规范
+
+| 规则 | 说明 |
+|:-----|:------|
+| **临时目录** | `./project/{project_name}/.temp/` |
+| **生命周期** | 项目收尾时清理，不进入最终交付物 |
+| **命名规则** | `{智能体名}_{用途}_{时间戳}.{格式}` |
+| **清理策略** | 项目收尾阶段自动清理超过7天的临时文件 |
+
+---
+
+## 4. 项目质量验收标准
+
+### 4.1 文档质量要求
+
+| 检查项 | 标准 | 严重程度 |
+|:-------|:-----|:---------|
+| 完整性 | 文档包含所有必要章节，无缺失必填内容 | 🔴 阻塞 |
+| 准确性 | 文档中的数据、路径、名称与实际一致 | 🔴 阻塞 |
+| 可读性 | 使用 Markdown 格式，有标题层级、表格、代码块等 | 🟡 建议 |
+| 一致性 | 术语、命名风格、格式在项目内保持一致 | 🟡 建议 |
+| 可追溯 | 关键决策有依据，引用有出处 | 🟢 可选 |
+
+### 4.2 代码/工具质量要求
+
+| 检查项 | 标准 | 严重程度 |
+|:-------|:-----|:---------|
+| 功能正确 | 代码实现的功能与需求一致，通过功能测试 | 🔴 阻塞 |
+| 无错误 | 无语法错误、运行时异常、安全漏洞 | 🔴 阻塞 |
+| 命名规范 | 遵循项目的命名规范（蛇形/驼峰） | 🟡 建议 |
+| 注释完整 | 关键逻辑有注释，对外接口有说明 | 🟡 建议 |
+| 错误处理 | 有合理的错误捕获和异常处理逻辑 | 🟡 建议 |
+| 测试覆盖 | 核心功能有测试用例覆盖 | 🟢 可选 |
+
+### 4.3 验收流程
+
+```
+1. 自检（Self-Check）
+   → 执行智能体自行检查产出物是否符合质量标准
+   → 记录自检结果
+
+2. 互检（Peer Review）
+   → 由其他智能体进行交叉检查
+   → 重点关注功能正确性和一致性
+
+3. 验收（Acceptance）
+   → Master 或 Project Manager 最终验收
+   → 验收通过后更新文档状态为"已定稿"
+
+4. 归档（Archive）
+   → 将验收通过的产出物归档到 closure/ 目录
+   → 更新项目知识库
+```
+
+### 4.4 验收判断标准
+
+| 状态 | 定义 | 后续动作 |
+|:-----|:------|:---------|
+| ✅ 通过 | 所有 🔴 阻塞项通过，🟡 建议项完成 80% 以上 | 进入归档流程 |
+| ⚠️ 有条件通过 | 所有 🔴 阻塞项通过，🟡 建议项完成 60%~80% | 记录待改进项，进入归档流程 |
+| ❌ 不通过 | 存在 🔴 阻塞项未通过 | 退回修改，重新提交验收 |