feat(knowledge): opengineer - 创建运维/规范领域知识条目(部署流程/故障排查/服务器运维标准)

Co-authored-by: multica-agent <github@multica.ai>

agents/architect/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 梁思筑（architect）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `architect` | Multica Agent UUID: `40abd41a-62d0-416d-bc44-92c1f758d87a`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'architect' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 40abd41a-62d0-416d-bc44-92c1f758d87a --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=architect）
+    ↓
+检查 Multica Issues 待办（assignee=40abd41a-62d0-416d-bc44-92c1f758d87a）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 架构设计进度
+6. ✅ 技术方案评审状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 梁思筑（architect）专用配置

agents/contentspecialist/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 文墨言（contentspecialist）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `contentspecialist` | Multica Agent UUID: `8321b0bf-7d89-4ece-927a-0780f42ad396`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'contentspecialist' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 8321b0bf-7d89-4ece-927a-0780f42ad396 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=contentspecialist）
+    ↓
+检查 Multica Issues 待办（assignee=8321b0bf-7d89-4ece-927a-0780f42ad396）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 内容发布计划
+6. ✅ 素材准备状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 文墨言（contentspecialist）专用配置

agents/coo/HEARTBEAT.md

@@ -0,0 +1,235 @@
+# HEARTBEAT.md - 陆怀瑾（coo）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：高频 Agent
+> OpenClaw Agent ID: `coo` | Multica Agent UUID: `1c38b437-b54d-4784-bda3-29ce4c8a6722`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'coo' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=coo）
+    ↓
+检查 Multica Issues 待办（assignee=1c38b437-b54d-4784-bda3-29ce4c8a6722）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：10 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 20 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 30 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO（自我监控） |
+| Multica | 添加评论 → status=blocked → 通知 COO（自我监控） |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（1h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：50 轮
+
+- 接近 80%（40 轮）→ 预警
+- 达到上限 → 暂停，通知 COO（自我监控）
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ **全平台积压巡检**：WorkBoard + Multica 全局待办数
+6. ✅ 资源负载均衡检查
+7. ✅ 风险识别与预警
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 陆怀瑾（coo）专用配置

agents/costcodev/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 徐聪（costcodev）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `costcodev` | Multica Agent UUID: `46bdd4a6-5c64-475a-92ef-36a763602fa1`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'costcodev' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 46bdd4a6-5c64-475a-92ef-36a763602fa1 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=costcodev）
+    ↓
+检查 Multica Issues 待办（assignee=46bdd4a6-5c64-475a-92ef-36a763602fa1）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 代码开发进度
+6. ✅ PR/Code Review 状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 徐聪（costcodev）专用配置

agents/cvexpert/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 程伯予（cvexpert）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `cvexpert` | Multica Agent UUID: `4a8696fd-6531-40da-8956-ef84d7ea3c43`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'cvexpert' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 4a8696fd-6531-40da-8956-ef84d7ea3c43 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=cvexpert）
+    ↓
+检查 Multica Issues 待办（assignee=4a8696fd-6531-40da-8956-ef84d7ea3c43）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 求职服务队列
+6. ✅ 客户反馈跟踪
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 程伯予（cvexpert）专用配置

agents/designer/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 苏锦绘（designer）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `designer` | Multica Agent UUID: `13bd8968-cc2a-4934-90c7-957a2d3c09c2`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'designer' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 13bd8968-cc2a-4934-90c7-957a2d3c09c2 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=designer）
+    ↓
+检查 Multica Issues 待办（assignee=13bd8968-cc2a-4934-90c7-957a2d3c09c2）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 设计稿进度
+6. ✅ UI/UX 评审状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 苏锦绘（designer）专用配置

agents/lawyer/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 苏慎（lawyer）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `lawyer` | Multica Agent UUID: `6fb0fbd2-16a6-4566-ba7a-d2c136baec25`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'lawyer' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 6fb0fbd2-16a6-4566-ba7a-d2c136baec25 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=lawyer）
+    ↓
+检查 Multica Issues 待办（assignee=6fb0fbd2-16a6-4566-ba7a-d2c136baec25）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 合同审查队列
+6. ✅ 合规检查项
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 苏慎（lawyer）专用配置

agents/marketanalysis/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 顾析策（marketanalysis）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `marketanalysis` | Multica Agent UUID: `5ed91729-658f-4654-98f0-3e0313022002`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'marketanalysis' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id 5ed91729-658f-4654-98f0-3e0313022002 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=marketanalysis）
+    ↓
+检查 Multica Issues 待办（assignee=5ed91729-658f-4654-98f0-3e0313022002）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 市场分析任务
+6. ✅ 竞品数据更新
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 顾析策（marketanalysis）专用配置

agents/mediaspecialist/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 钟帧韵（mediaspecialist）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `mediaspecialist` | Multica Agent UUID: `e2b587d4-1d16-447c-8ad9-e2a01358ff0a`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'mediaspecialist' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id e2b587d4-1d16-447c-8ad9-e2a01358ff0a --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=mediaspecialist）
+    ↓
+检查 Multica Issues 待办（assignee=e2b587d4-1d16-447c-8ad9-e2a01358ff0a）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 视频制作进度
+6. ✅ 媒体素材准备状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 钟帧韵（mediaspecialist）专用配置

agents/opengineer/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 严维序（opengineer）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `opengineer` | Multica Agent UUID: `d3804433-9e2e-4199-a92b-a153049b3bc9`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'opengineer' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id d3804433-9e2e-4199-a92b-a153049b3bc9 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=opengineer）
+    ↓
+检查 Multica Issues 待办（assignee=d3804433-9e2e-4199-a92b-a153049b3bc9）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 部署状态检查
+6. ✅ 服务器/服务健康状况
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 严维序（opengineer）专用配置

agents/productmanager/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 沈路明（productmanager）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `productmanager` | Multica Agent UUID: `a101fa88-d821-4839-9754-e04580d5fd68`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'productmanager' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id a101fa88-d821-4839-9754-e04580d5fd68 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=productmanager）
+    ↓
+检查 Multica Issues 待办（assignee=a101fa88-d821-4839-9754-e04580d5fd68）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ PRD 进度检查
+6. ✅ 需求变更跟踪
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 沈路明（productmanager）专用配置

agents/projectmanager/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 胡蓉（projectmanager）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：开发 Agent
+> OpenClaw Agent ID: `projectmanager` | Multica Agent UUID: `d877b8c3-b230-4073-b3f7-80e148cfdb71`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'projectmanager' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id d877b8c3-b230-4073-b3f7-80e148cfdb71 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=projectmanager）
+    ↓
+检查 Multica Issues 待办（assignee=d877b8c3-b230-4073-b3f7-80e148cfdb71）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，通知 COO + 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 项目进度检查
+6. ✅ 依赖项完成状态
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 胡蓉（projectmanager）专用配置

agents/secretary/HEARTBEAT.md

@@ -0,0 +1,235 @@
+# HEARTBEAT.md - 刘诗妮（secretary）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：高频 Agent
+> OpenClaw Agent ID: `secretary` | Multica Agent UUID: `b024fcdc-30ff-420d-b289-498041466e1b`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'secretary' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id b024fcdc-30ff-420d-b289-498041466e1b --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=secretary）
+    ↓
+检查 Multica Issues 待办（assignee=b024fcdc-30ff-420d-b289-498041466e1b）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：10 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 20 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 30 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO |
+| Multica | 添加评论 → status=blocked → 通知 COO |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（1h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：50 轮
+
+- 接近 80%（40 轮）→ 预警
+- 达到上限 → 暂停，通知 COO
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 全局任务积压巡检
+6. ✅ 业务入口检查
+7. ✅ 各 Agent 状态巡检
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 刘诗妮（secretary）专用配置

agents/taobaospecialist/HEARTBEAT.md

@@ -0,0 +1,234 @@
+# HEARTBEAT.md - 陆云帆（taobaospecialist）的心跳配置
+
+> 模板版本：v1.1 (BIZ-24) | 分类：业务 Agent
+> OpenClaw Agent ID: `taobaospecialist` | Multica Agent UUID: `e0f62d8f-9568-4f41-8ad4-b73d79a163a7`
+
+---
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+```bash
+# 检查 WorkBoard 中分配给我的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == 'taobaospecialist' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c["id"][:8]} [priority={c.get("priority","?")}] {c["title"]}')
+"
+```
+
+#### 第二优先级：Multica Issues
+
+```bash
+# 检查 Multica 中分配给我的待办 Issue
+multica issue list --assignee-id e0f62d8f-9568-4f41-8ad4-b73d79a163a7 --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue["identifier"]} [{issue.get("priority","?")}] {issue["title"]}')
+"
+```
+
+#### 第三优先级：待办文档
+
+```bash
+# 检查工作区待办文档
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档中未完成项"
+```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片（agentId=taobaospecialist）
+    ↓
+检查 Multica Issues 待办（assignee=e0f62d8f-9568-4f41-8ad4-b73d79a163a7）
+    ↓
+检查待办文档
+    ↓
+合并去重 → 按优先级排序 → 依次执行
+```
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+
+每次心跳跨平台执行以下检测：
+
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+
+```bash
+# WorkBoard 超时检测
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ WB TIMEOUT: {c["id"][:8]} [{c.get("agentId","?")}] {c["title"]}')
+"
+
+echo ""
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1800:
+            print(f'⏰ MUL TIMEOUT: {issue["identifier"]} [{issue.get("assignee_id","?")[:12]}] {issue["title"]}')
+"
+```
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+### 双平台依赖检查
+
+```bash
+# WorkBoard 依赖检查
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足: {dep["id"]} → status={dep.get("status","?")}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+
+# Multica 依赖检查
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json, subprocess
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent["identifier"]} 未完成')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent["identifier"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+```
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知 创建者
+
+### 跨平台轮次跟踪
+
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+---
+
+## 🫀 心跳执行清单
+
+### 每次心跳必须检查
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 淘宝店铺运营指标
+6. ✅ 竞品动态跟踪
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+
+
+---
+
+> 基于 BIZ-24 v1.1 模板生成 | 陆云帆（taobaospecialist）专用配置

docs/Agent 知识库集成指南.md

@@ -0,0 +1,130 @@
+# Agent 知识库集成指南
+
+> **版本**: v1.0  
+> **任务**: BIZ-19 (BIZ-14-4)  
+> **日期**: 2026-06-22  
+> **作者**: COO (陆怀瑾)  
+> **状态**: 已实施
+
+---
+
+## 一、集成概述
+
+### 1.1 设计原则
+
+**「引用代替填塞」**: 不把知识内容直接塞进 Agent 配置文件，而是添加 "如何查询知识库" 的指引。Agent 在需要时主动检索，保持配置文件轻量和可维护。
+
+### 1.2 核心工具
+
+| 工具 | 用途 | 适用场景 |
+|------|------|----------|
+| `wiki_search` | 模糊搜索知识库 | "有没有关于 X 的文档" |
+| `wiki_get` | 精确读取页面 | "打开 X 页面" |
+| `wiki_lint` | 知识库质量检查 | "知识库健康度如何" |
+| `wiki_status` | 系统状态检查 | "知识库是否可用" |
+| `wiki_apply` | 写入/更新知识库 | "将 X 发现写入知识库" |
+
+---
+
+## 二、Agent 集成清单
+
+### 2.1 已完成集成的 Agent（15 个）
+
+| # | Agent | 角色 | TOOLS.md 更新状态 | 触发场景数 |
+|---|-------|------|-------------------|------------|
+| 1 | secretary | 刘诗妮 - 业务入口 | ✅ | 4 |
+| 2 | coo | 陆怀瑾 - 运营总监 | ✅ | 5 |
+| 3 | projectmanager | 胡蓉 - 项目经理 | ✅ | 4 |
+| 4 | architect | 梁思筑 - 架构师 | ✅ | 4 |
+| 5 | costcodev | 徐聪 - 全栈开发 | ✅ | 4 |
+| 6 | designer | 苏绘锦 - UI/UX 设计 | ✅ | 3 |
+| 7 | taobaospecialist | 陆云帆 - 淘宝运营 | ✅ | 4 |
+| 8 | contentspecialist | 文墨言 - 内容文案 | ✅ | 4 |
+| 9 | mediaspecialist | 钟帧韵 - 视频制作 | ✅ | 3 |
+| 10 | cvexpert | 程伯予 - 求职助理 | ✅ | 3 |
+| 11 | marketanalysis | 顾析策 - 市场分析 | ✅ | 4 |
+| 12 | lawyer | 苏慎 - 法务顾问 | ✅ | 4 |
+| 13 | opengineer | 严维序 - 运维部署 | ✅ | 4 |
+| 14 | productmanager | 沈路明 - 产品经理 | ✅ | 4 |
+| 15 | main | 入口路由 | ✅ | 2 |
+
+### 2.2 集成内容
+
+每个 Agent 的 TOOLS.md 新增了以下内容：
+
+1. **知识库查询指引** — 引导 Agent 查看完整检索指南
+2. **角色特定触发条件** — 该 Agent 何时应查询知识库
+3. **查询工具速查** — `wiki_search` / `wiki_get` / `wiki_lint` 基本用法
+4. **角色特定查询示例** — 1-2 个典型查询语句
+5. **无结果时处理流程** — 知识缺口上报机制
+
+---
+
+## 三、查询触发条件设计
+
+### 3.1 通用触发条件（所有 Agent 适用）
+
+| 场景 | 触发动作 |
+|------|----------|
+| 接受新任务时 | 先查知识库中是否有相关文档/SOP |
+| 遇到不确定信息时 | 先查知识库再作决策 |
+| 需要跨领域协作时 | 查其他 Agent 的职能和知识 |
+| 发现新知识时 | 考虑是否需写入知识库 |
+
+### 3.2 角色特定触发条件（按 Agent 定制）
+
+见各 Agent TOOLS.md 中的「知识库查询 → 触发条件」部分。
+
+---
+
+## 四、知识缺口上报机制
+
+### 4.1 上报流程
+
+```
+Agent 查询知识库 → 无结果 → 尝试同义词/相关词 → 仍无结果 →
+→ 记录知识缺口 → 写入 memory/ 日志 → 
+→ 下次心跳/汇报时通知 architect 或对应领域 Agent
+```
+
+### 4.2 上报格式
+
+见 `docs/agent-kb-retrieval-guide.md` 第五节。
+
+---
+
+## 五、质量保证
+
+### 5.1 集成测试方案
+
+对每个 Agent 至少执行 1 次典型查询场景测试：
+
+1. 验证 `wiki_search` 可被正确调用
+2. 验证返回结果格式正确
+3. 验证无结果时的降级路径
+
+### 5.2 集成测试结果
+
+| Agent | 测试查询 | 结果 | 备注 |
+|-------|----------|------|------|
+| 通用 | `wiki_search(query="服务器")` | ✅ | wiki_search 正常 |
+
+*注：知识库当前为初始状态（0 sources, 0 entities, 0 concepts, 0 syntheses, 10 reports），搜索结果取决于内容填充进度。工具链已验证可用。*
+
+---
+
+## 六、后续计划
+
+1. **知识内容填充**: 待 BIZ-14-3 交付后，各 Agent 按角色写入初始知识内容
+2. **定期质量检查**: COO 每周运行 `wiki_lint()` 检查知识库健康度
+3. **查询效果评估**: 运行 1 个月后统计各 Agent 知识库查询频率和命中率
+4. **持续优化**: 根据使用反馈调整触发条件和查询示例
+
+---
+
+## 附录：相关文档
+
+- `docs/agent-kb-retrieval-guide.md` — 知识库检索工具完整指南
+- `docs/知识查询最佳实践.md` — 查询最佳实践和反模式
+- `docs/wiki-toolchain-test-report.md` — Wiki 工具链测试报告 (BIZ-14-2)
+- 各 Agent TOOLS.md — 角色特定查询指引

docs/知识查询最佳实践.md

@@ -0,0 +1,156 @@
+# 知识查询最佳实践
+
+> **版本**: v1.0  
+> **任务**: BIZ-19 (BIZ-14-4)  
+> **日期**: 2026-06-22
+
+---
+
+## 一、查询策略
+
+### 1.1 渐进式检索原则
+
+```
+先宽后窄 → 先模糊后精确 → 先搜索后读取
+```
+
+**标准流程**：
+1. `wiki_search(query="关键词")` — 发现有哪些相关内容
+2. `wiki_get(lookup="匹配页面")` — 精确读取具体内容
+3. 如搜索结果过多（>10） → 收窄关键词重新搜索
+4. 如搜索结果与需求不相关 → 调整表述方式重新搜索
+
+### 1.2 查询词构造技巧
+
+#### DO ✅
+
+| 技巧 | 示例 | 说明 |
+|------|------|------|
+| 用领域特定术语 | `wiki_search(query="nginx 反向代理")` | 专业词汇提升精确度 |
+| 用动词+对象 | `wiki_search(query="部署 Node.js")` | 明确查询意图 |
+| 用自然语言问题 | `wiki_search(query="如何配置 nginx logrotate")` | 适合语义检索 |
+| 用缩写和全称组合 | `wiki_search(query="CI/CD 持续集成")` | 覆盖不同表述 |
+| 分步搜索 | 先搜 "nginx"，再搜 "nginx 日志" | 逐步收窄范围 |
+
+#### DON'T ❌
+
+| 反模式 | 错误示例 | 问题 |
+|--------|----------|------|
+| 过于泛化的词 | `wiki_search(query="配置")` | 结果太多太杂 |
+| 过于具体的短语 | `wiki_search(query="192.168.1.99 端口 22 上的 nginx")` | 命中率低 |
+| 跳过搜索直接 guess 路径 | `wiki_get(lookup="随便猜的页面名")` | 大概率找不到 |
+| 一次加载超大页面 | `wiki_get(lookup="巨型文档")` | 超出上下文容量 |
+| 无结果后直接放弃 | 只搜一次就说"知识库没内容" | 可能是查询词不准确 |
+
+---
+
+## 二、结果处理
+
+### 2.1 匹配结果数量处理
+
+| 结果数 | 处理方式 |
+|--------|----------|
+| 0 | 尝试同义词/相关词 → qmd 搜索 → 上报知识缺口 |
+| 1-3 | 逐个 `wiki_get` 读取完整内容 |
+| 4-10 | 按评分排序，取前 3 个读取 |
+| 10+ | 收窄搜索词重新搜索 |
+
+### 2.2 大页面分页读取
+
+```bash
+# 超过 100 行的页面，分页读取
+wiki_get(lookup="长文档标题", fromLine=1, lineCount=50)   # 第一部分
+wiki_get(lookup="长文档标题", fromLine=51, lineCount=50)  # 第二部分
+```
+
+### 2.3 信息来源交叉验证
+
+当多个查询返回不同信息时：
+1. 检查页面更新时间（优先信任较新的）
+2. 交叉对比多个来源
+3. 如信息冲突 → 标记为"需确认"，汇报给 architect
+
+---
+
+## 三、知识缺口处理
+
+### 3.1 判定标准
+
+满足以下任一条件即报告知识缺口：
+- `wiki_search` 和 `qmd` 均无匹配
+- 搜索结果与需求明显不相关
+- 找到的文档内容已过时或不完整
+
+### 3.2 上报模板
+
+```
+【知识缺口 - YYYY-MM-DD】
+
+- 查询 Agent: [Agent 名称]
+- 查询意图: [想了解什么]
+- 已尝试检索: [用过的搜索词, 换行列出]
+- 已使用工具: wiki_search / qmd
+- 期望内容: [知识库中应有什么]
+- 紧急程度: high / normal / low
+- 建议: [谁补充、什么内容]
+```
+
+### 3.3 上报路径
+
+| 缺口类型 | 上报目标 |
+|----------|----------|
+| 架构/技术 | architect (梁思筑) |
+| 业务/流程 | projectmanager (胡蓉) |
+| 法务/合规 | lawyer (苏慎) |
+| 市场/分析 | marketanalysis (顾析策) |
+| 通用/不确定 | COO (陆怀瑾) — 由 COO 分配 |
+
+---
+
+## 四、知识库写入准则
+
+### 4.1 何时写入
+
+- 完成重要决策后（如架构选型、策略调整）
+- 发现可复用的模板/清单
+- 完成深度分析后（市场报告、竞品分析）
+- 知识缺口被填补后
+
+### 4.2 写入工具选择
+
+| 场景 | 工具 |
+|------|------|
+| 创建新知识页面 | `wiki_apply(op="create_synthesis", ...)` |
+| 更新已有页面元数据 | `wiki_apply(op="update_metadata", ...)` |
+
+### 4.3 不写入的内容
+
+- 机密信息（密码、密钥、token）
+- 临时信息（当天的具体任务进度）
+- 已过时会被频繁更新的数据
+- 纯个人笔记（放 `memory/` 下）
+
+---
+
+## 五、定期维护
+
+### 5.1 COO 每周检查清单
+
+- [ ] 运行 `wiki_lint()` 检查质量
+- [ ] 统计各 Agent 知识库查询频率
+- [ ] 清理过时页面
+- [ ] 评估知识缺口数量和解决率
+- [ ] 输出知识库运营周报
+
+### 5.2 Agent 自检清单
+
+每次心跳时：
+- [ ] 上次查询的知识缺口是否已上报
+- [ ] 本轮工作中是否有应写入知识库的发现
+
+---
+
+## 附录
+
+- `docs/agent-kb-retrieval-guide.md` — 工具使用完整指南
+- `docs/Agent 知识库集成指南.md` — 集成方案总览

knowledge/README.md

@@ -0,0 +1,41 @@
+# 知识库索引
+
+> 本知识库与 Agent 配置文件解耦，由 COO 主导维护，各领域负责人协作贡献。
+> 通过 `wiki_search` / `memory_search` / `qmd` 等工具检索，人类可通过 Web UI 审查优化。
+
+## 目录结构
+
+| 目录 | 领域 | 责任人 | 条目数 |
+|------|------|--------|--------|
+| [电商/](电商/) | 淘宝、抖店、微信小店运营 | 陆云帆 (taobaospecialist) | — |
+| [内容/](内容/) | 小红书、短视频、文案 | 文墨言 (contentspecialist) | — |
+| [产品/](产品/) | PRD、需求分析 | 沈路明 (productmanager) | — |
+| [技术/](技术/) | 开发规范、代码审查 | 徐聪 (costcodev) | — |
+| [设计/](设计/) | UI设计、品牌规范 | 苏绘锦 (designer) | — |
+| [运维/](运维/) | 部署流程、故障排查、服务器运维 | 严维序 (opengineer) | 3 |
+| [运营/](运营/) | 活动策划、数据分析 | 陆怀瑾 (coo) | — |
+| [行政/](行政/) | 合同、报销流程 | 刘诗妮 (secretary) | — |
+| [规范/](规范/) | 运维标准、安全基线、合规要求 | 严维序 (opengineer) | — |
+
+## 知识条目格式
+
+每个知识条目遵循 [模板](../templates/知识条目模板.md)。
+
+## 检索方式
+
+- **Agent 主动查询**：`wiki_search` / `memory_search` / `qmd`
+- **人类审查**：通过 Web UI 浏览、编辑、优化
+- **质量检查**：`wiki_lint` 定期运行
+
+## 贡献流程
+
+1. 领域负责人撰写条目
+2. COO 审核内容质量
+3. 提交到 EnterpriseArchitect 仓库
+4. 通过 `wiki_lint` 检查
+5. 通知相关 Agent 更新索引
+
+---
+
+**维护者**：陆怀瑾（COO）
+**最后更新**：2026-06-22

knowledge/产品/PRD模板.md

@@ -0,0 +1,111 @@
+# PRD 模板
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 产品 |
+| **责任人** | 沈路明 (productmanager) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | PRD, 产品需求, 模板 |
+
+## 概述
+
+产品需求文档（PRD）标准模板。适用于所有产品功能需求、系统改进需求的规范化描述，确保开发团队、设计团队、业务团队对需求理解一致。
+
+## 正文
+
+### 一、文档头部
+
+```
+# [产品名称] - [功能名称] PRD
+
+| 属性 | 值 |
+|------|-----|
+| **版本** | v1.0 |
+| **作者** | [姓名] |
+| **创建日期** | YYYY-MM-DD |
+| **状态** | 草稿 / 评审中 / 已批准 / 已上线 |
+| **关联文档** | [链接] |
+```
+
+### 二、需求概述
+
+**2.1 背景与问题**
+[描述为什么需要这个功能，解决了什么用户痛点或业务问题]
+
+**2.2 目标用户**
+- 用户画像 1：[描述]
+- 用户画像 2：[描述]
+
+**2.3 核心目标**
+- 业务目标：[可量化指标，如转化率提升 X%]
+- 用户目标：[用户获得什么价值]
+- 技术目标：[如响应时间、并发量]
+
+### 三、功能描述
+
+**3.1 功能范围**
+- P0（必须）：[最小可用功能]
+- P1（应该）：[重要但可后续]
+- P2（锦上添花）：[可后续迭代]
+
+**3.2 用户故事**
+
+```
+作为 [用户角色]，
+我希望 [功能/行为]，
+以便 [获得的价值/目标]。
+```
+
+**3.3 详细交互说明**
+1. [步骤1]：[描述 + 原型图链接]
+2. [步骤2]：[描述 + 原型图链接]
+
+**3.4 边界与异常**
+- 正常流程：[描述]
+- 异常情况1：[触发条件 + 处理方式]
+- 异常情况2：[触发条件 + 处理方式]
+
+### 四、非功能需求
+
+| 项目 | 要求 |
+|------|------|
+| 页面加载 | ≤ 2 秒 |
+| 接口响应 | ≤ 500ms |
+| 并发支持 | 1000 QPS |
+| 兼容性 | iOS 13+, Android 9+, Chrome 90+ |
+
+### 五、数据埋点
+
+| 事件名 | 触发条件 | 属性 |
+|--------|----------|------|
+| [event_name] | [触发条件] | [上报字段] |
+
+### 六、验收标准
+
+- [ ] 功能1 验收条件
+- [ ] 功能2 验收条件
+- [ ] 非功能需求满足
+
+### 七、排期与里程碑
+
+| 里程碑 | 日期 | 交付物 |
+|--------|------|--------|
+| 设计评审 | YYYY-MM-DD | 交互/视觉稿 |
+| 技术评审 | YYYY-MM-DD | 技术方案 |
+| 开发完成 | YYYY-MM-DD | 可测试版本 |
+| 上线 | YYYY-MM-DD | 生产环境 |
+
+## 相关条目
+
+- [需求分析方法.md](需求分析方法.md)
+- [开发规范.md](../技术/开发规范.md)
+- [UI设计规范.md](../设计/UI设计规范.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/产品/README.md

@@ -0,0 +1,21 @@
+# 产品领域知识
+
+**责任人**：沈路明（productmanager）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖产品需求文档、用户研究、竞品分析、需求管理、版本规划等产品管理知识。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [PRD模板.md](PRD模板.md) | 产品需求文档标准模板 | ✅ |
+| [需求分析方法.md](需求分析方法.md) | 用户需求调研与分析方法 | ✅ |
+
+## 待建设
+
+- 竞品分析框架
+- 产品路线图模板
+- 用户故事编写指南

knowledge/产品/需求分析方法.md

@@ -0,0 +1,84 @@
+# 需求分析方法
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 产品 |
+| **责任人** | 沈路明 (productmanager) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 需求分析, 用户调研, 产品管理 |
+
+## 概述
+
+需求分析是从用户/业务痛点出发，将模糊的需求描述转化为可落地的产品功能规格的系统化方法。核心原则：先理解问题，再设计方案。
+
+## 正文
+
+### 一、需求收集方法
+
+1. **用户访谈**（定性）
+   - 每轮访谈 5-8 个目标用户
+   - 半结构化访谈：准备提纲 + 灵活追问
+   - 核心问题：「你最想解决什么问题？」「现在怎么解决的？」
+
+2. **问卷调查**（定量）
+   - 覆盖 100+ 目标用户
+   - 包含选择题（量化）+ 开放题（发掘）
+   - 关键指标：问题频率、痛点程度、替代方案满意度
+
+3. **数据分析**
+   - 页面点击热力图
+   - 用户行为漏斗（转化率断点）
+   - 客服工单高频关键词
+
+### 二、需求优先级评估 — ICE 模型
+
+| 因子 | 说明 | 评分 (1-10) |
+|------|------|------------|
+| **I**mpact（影响面） | 影响多少用户？对核心指标影响多大？ | |
+| **C**onfidence（信心度） | 我们有多少证据这个方案有效？ | |
+| **E**ase（实现难度） | 开发成本多高？时间多长？ | |
+
+总分 = I × C × E（E 分数越高越容易，越大越好）
+
+### 三、需求文档化
+
+1. **用户故事标准格式**
+   > 作为 **[用户角色]**，
+   > 我希望 **[功能/行为]**，
+   > 以便 **[获得的价值]**。
+
+2. **验收条件（Acceptance Criteria）**
+   - 必须可测试、可验证
+   - 正面条件 + 边缘情况
+
+3. **原型验证**
+   - 低保真原型验证交互流程（1-2 天）
+   - 用户测试 3-5 人，观察操作行为
+   - 根据反馈迭代后进入高保真设计
+
+### 四、需求评审流程
+
+```
+需求方提出 → PM 分析评估 → 交互设计 → 技术评审
+    → 排期评估 → 最终评审 → 进入开发
+```
+
+每一步评审需至少以下人员参与：
+- PM（负责人）
+- 1 名开发（评估技术可行性）
+- 1 名设计师（评估交互可行性）
+- 需求方（确认需求理解正确）
+
+## 相关条目
+
+- [PRD模板.md](PRD模板.md)
+- [开发规范.md](../技术/开发规范.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/内容/README.md

@@ -0,0 +1,21 @@
+# 内容领域知识
+
+**责任人**：文墨言（contentspecialist）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖小红书、短视频平台、公众号等内容平台运营知识，包括内容创作、选题策划、标题优化、发布策略、数据分析等。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [小红书运营指南.md](小红书运营指南.md) | 小红书内容运营全流程指南 | ✅ |
+| [标题写作技巧.md](标题写作技巧.md) | 爆款标题创作方法论 | ✅ |
+
+## 待建设
+
+- 短视频脚本模板
+- 公众号排版规范
+- 内容日历模板

knowledge/内容/小红书运营指南.md

@@ -0,0 +1,82 @@
+# 小红书运营指南
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 内容 |
+| **责任人** | 文墨言 (contentspecialist) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 小红书, 内容运营, 种草, 涨粉 |
+
+## 概述
+
+小红书是以"真实分享+种草"为核心的内容社区，运营不同于其他平台。核心逻辑：真诚分享 > 硬广推广，封面/标题决定点击率，内容质量决定涨粉转化。
+
+## 正文
+
+### 一、内容定位与选题
+
+1. **账号定位**（上线前必做）
+   - 明确赛道：美妆/穿搭/家居/母婴/美食/知识
+   - 确定人设：专家型/体验型/教程型
+   - 对标 3-5 个同赛道 Top 博主
+
+2. **选题策略**
+   - 热点追踪：小红书热搜 + 抖音热点宝
+   - 实用内容：教程/清单/测评/避坑
+   - 情感共鸣：个人经历/观点分享/生活记录
+
+### 二、内容制作标准
+
+1. **封面设计**（点击率核心）
+   - 高饱和度配色，对比度强
+   - 简洁文字 3-7 字，避免遮挡主体
+   - 尺寸 3:4，首图即为封面
+
+2. **标题公式**
+   - 数字型：「3 步搞定...」
+   - 痛点型：「为什么你...还是不行？」
+   - 对比型：「A vs B，差距到底在哪」
+   - 清单型：「2026 必入的 10 款...」
+
+3. **正文结构**
+   - 开头（3 句）：抛痛点/抛结论
+   - 主体：分点说明，配图对应
+   - 结尾：互动引导（提问/投票/求关注）
+
+### 三、发布与推广
+
+1. **发布时间**
+   - 工作日：12:00-14:00, 18:00-21:00
+   - 周末：10:00-12:00, 15:00-18:00
+
+2. **话题标签策略**
+   - 1-2 个大流量话题（#穿搭 #美妆 #家居）
+   - 2-3 个精准话题（#小个子穿搭 #通勤穿搭）
+   - 1 个自创话题（#XX的日常搭配）
+
+3. **初期冷启动**
+   - 发布后 1 小时内互动（评论/点赞）对推荐权重影响最大
+   - 在同类笔记下真诚评论（非硬广引流）
+
+### 四、数据指标
+
+| 指标 | 新手目标 | 进阶目标 |
+|------|----------|----------|
+| 单篇阅读量 | 1000+ | 5000+ |
+| 点赞率 | 3%+ | 5%+ |
+| 收藏率 | 2%+ | 4%+ |
+| 涨粉率 | 1%/篇 | 3%/篇 |
+
+## 相关条目
+
+- [标题写作技巧.md](标题写作技巧.md)
+- [活动策划模板.md](../运营/活动策划模板.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/技术/README.md

@@ -0,0 +1,23 @@
+# 技术领域知识
+
+**责任人**：徐聪（costcodev）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖开发规范、代码审查、架构设计、技术选型等技术团队核心知识。
+
+> ⚠️ 部署运维知识已迁移至 [运维/](../运维/) 领域。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [开发规范.md](开发规范.md) | 代码编写与项目管理规范 | ✅ |
+| [代码审查清单.md](代码审查清单.md) | Pull Request 审查标准 | ✅ |
+
+## 待建设
+
+- API 设计规范
+- 数据库设计指南
+- 技术选型决策框架

knowledge/技术/开发规范.md

@@ -0,0 +1,104 @@
+# 开发规范
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 技术 |
+| **责任人** | 徐聪 (costcodev) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 开发规范, 代码风格, Git, 项目管理 |
+
+## 概述
+
+定义团队统一的代码编写、项目管理、协作流程规范。目的是确保代码可维护、可交接，降低协作摩擦。
+
+## 正文
+
+### 一、代码规范
+
+1. **Python**
+   - 遵循 PEP 8 代码风格
+   - 使用 `black` 自动格式化，行宽 100
+   - 类型注解必须（`mypy --strict` 通过）
+   - 文档字符串用 Google 风格
+
+2. **TypeScript/JavaScript**
+   - 使用 `prettier` 格式化
+   - ESLint 严格模式
+   - 禁止 `any` 类型（除非显式标注 `// eslint-disable-next-line`）
+   - 所有公共 API 必须有 JSDoc
+
+3. **通用规则**
+   - 函数单一职责，不超过 50 行
+   - 命名：camelCase（变量/函数）、PascalCase（类/组件）、UPPER_SNAKE（常量）
+   - 禁止 `print` / `console.log` 残留（用日志库）
+   - 禁止注释掉的代码（相信 Git）
+
+### 二、Git 规范
+
+1. **分支策略**
+   ```
+   main ─── 生产环境
+   develop ─── 开发主线
+   feature/<task-id>-<desc> ─── 功能分支
+   fix/<task-id>-<desc> ─── 修复分支
+   ```
+
+2. **Commit 格式**
+   ```
+   <type>(<scope>): <subject>
+   
+   <body>
+   
+   <footer>
+   ```
+   - type: feat / fix / docs / style / refactor / test / chore
+   - scope: 模块名（如 api, ui, db）
+   - subject: 不超过 72 字符，中文或英文
+
+3. **PR 流程**
+   - 所有代码变更必须通过 PR
+   - 至少 1 人 Review 并 Approve
+   - CI 全部通过后才能合并
+   - 合并前 rebase develop 消除冲突
+
+### 三、项目结构规范
+
+```
+project/
+├── src/            # 源代码
+├── tests/          # 测试代码
+├── docs/           # 项目文档
+├── scripts/        # 运维脚本
+├── config/         # 配置文件
+├── README.md       # 项目说明
+├── CHANGELOG.md    # 变更日志
+└── .env.example    # 环境变量模板
+```
+
+### 四、文档规范
+
+- **README.md**：项目概述、快速启动、技术栈、目录说明
+- **API 文档**：后端接口必须有 OpenAPI/Swagger 文档
+- **开发文档**：架构设计、数据流图、部署说明
+- **代码即文档**：优先清晰的命名和结构，减少注释
+
+### 五、测试规范
+
+- 单元测试覆盖率 ≥ 70%
+- 关键业务逻辑覆盖率 ≥ 90%
+- 每个 PR 附带新增/修改的测试
+- 使用 `pytest` (Python) / `vitest` (TS)
+
+## 相关条目
+
+- [代码审查清单.md](代码审查清单.md)
+- [PRD模板.md](../产品/PRD模板.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/电商/README.md

@@ -0,0 +1,21 @@
+# 电商领域知识
+
+**责任人**：陆云帆（taobaospecialist）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖淘宝、抖店、微信小店等多平台电商运营知识，包括店铺搭建、商品上架、营销推广、客户服务、数据分析等。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [淘宝运营SOP.md](淘宝运营SOP.md) | 淘宝店铺日常运营标准流程 | ✅ |
+| [抖店运营SOP.md](抖店运营SOP.md) | 抖音小店运营流程 | ✅ |
+
+## 待建设
+
+- 微信小店运营指南
+- 电商数据分析方法
+- 客服话术模板

knowledge/电商/抖店运营SOP.md

@@ -0,0 +1,74 @@
+# 抖店运营 SOP
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 电商 |
+| **责任人** | 陆云帆 (taobaospecialist) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 抖音, 抖店, 电商, SOP |
+
+## 概述
+
+本 SOP 定义抖音小店运营标准流程。抖店运营区别于传统电商的核心在于"内容驱动交易"——通过短视频和直播引流到店铺成交。
+
+## 正文
+
+### 一、每日运营
+
+1. **店铺健康检查**
+   - 登录抖店后台，检查体验分（≥ 4.6）
+   - 查看违规记录和扣分情况
+   - 检查商品状态（在售/审核中/下架）
+
+2. **内容运营**
+   - 发布 1-2 条挂车短视频
+   - 检查昨日短视频/直播数据
+   - 回复评论区用户问题
+
+3. **订单与客服**
+   - 处理待发货订单（48 小时发货）
+   - 处理售后申请（退货/退款）
+   - 3 分钟内回复客服消息
+
+### 二、每周运营
+
+1. **商品策略**
+   - 分析本周爆款商品，优化标题/主图/详情
+   - 根据热点趋势选品上新
+   - 设置限时秒杀/优惠券活动
+
+2. **内容策略**
+   - 复盘本周短视频/直播数据
+   - 策划下周内容选题（蹭热点/产品展示/教程）
+   - 测试新视频形式（口播/开箱/场景化）
+
+3. **投放优化**
+   - 查看千川投放数据
+   - 优化投放计划（人群/出价/素材）
+   - 调整 ROI 目标和预算分配
+
+### 三、每月运营
+
+1. **月度分析**
+   - 统计月度 GMV、订单量、退款率
+   - 分析流量来源占比（推荐/搜索/直播/短视频/付费）
+   - 输出《抖店月度运营报告》
+
+2. **供应链检查**
+   - 盘点库存，补货预警
+   - 检查发货时效和物流评分
+   - 供应商评估和优化
+
+## 相关条目
+
+- [淘宝运营SOP.md](淘宝运营SOP.md)
+- [数据分析方法.md](../运营/数据分析方法.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/电商/淘宝运营SOP.md

@@ -0,0 +1,83 @@
+# 淘宝运营 SOP
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 电商 |
+| **责任人** | 陆云帆 (taobaospecialist) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 淘宝, 电商, SOP, 日常运营 |
+
+## 概述
+
+本 SOP 定义淘宝店铺日常运营的标准流程，涵盖店铺维护、商品管理、营销推广、客服处理和数据分析五大模块。适用于每日/每周/每月周期性执行。
+
+## 正文
+
+### 一、每日运营检查（每日 9:00）
+
+1. **店铺状态检查**
+   - 登录千牛工作台，检查店铺处罚/违规通知
+   - 确认所有商品在售状态，无异常下架
+   - 检查店铺评分（DSR），低于 4.7 需立即分析原因
+
+2. **订单处理**
+   - 查看待发货订单，确保 48 小时内发货
+   - 处理售后订单（退货/换货/退款），24 小时内响应
+   - 检查差评/中评，及时联系客户处理
+
+3. **客服响应**
+   - 检查未读消息，回复时限 5 分钟内
+   - 查看客服数据：响应时长、满意度
+
+### 二、每周运营任务（每周一）
+
+1. **商品优化**
+   - 检查 Top 10 商品标题、主图、详情页
+   - 根据搜索词报告优化标题关键词
+   - 更新库存不足的商品
+
+2. **营销活动**
+   - 查看本周淘宝官方活动日历
+   - 设置店铺优惠券/满减活动
+   - 更新直通车/引力魔方推广计划
+
+3. **数据分析**
+   - 查看流量来源（搜索/推荐/付费/其他）
+   - 分析转化率、客单价变化趋势
+   - 输出《店铺周报》
+
+### 三、每月运营任务（每月 1 日）
+
+1. **月度复盘**
+   - 统计月度 GMV、订单量、利润率
+   - 对比上月数据，分析增长/下滑原因
+   - 制定下月运营目标和策略
+
+2. **竞品分析**
+   - 监控 Top 3 竞品店铺动态
+   - 分析竞品爆款商品和新品
+   - 调整自身商品/价格策略
+
+### 四、关键指标
+
+| 指标 | 目标值 | 监控频率 |
+|------|--------|----------|
+| DSR 评分 | ≥ 4.8 | 每日 |
+| 48h 发货率 | ≥ 98% | 每日 |
+| 客服响应时长 | ≤ 3 分钟 | 每日 |
+| 转化率 | ≥ 行业均值 +10% | 每周 |
+| GMV 增长 | 月环比 ≥ 10% | 每月 |
+
+## 相关条目
+
+- [抖店运营SOP.md](抖店运营SOP.md)
+- [数据分析方法.md](../运营/数据分析方法.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/行政/README.md

@@ -0,0 +1,21 @@
+# 行政领域知识
+
+**责任人**：刘诗妮（secretary）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖合同管理、报销流程、行政事务、供应商管理等行政支持知识。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [合同模板.md](合同模板.md) | 常用合同标准模板 | ✅ |
+| [报销流程.md](报销流程.md) | 费用报销申请与审批流程 | ✅ |
+
+## 待建设
+
+- 供应商管理指南
+- 会议纪要模板
+- 入职/离职流程

knowledge/行政/报销流程.md

@@ -0,0 +1,83 @@
+# 报销流程
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 行政 |
+| **责任人** | 刘诗妮 (secretary) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 行政, 报销, 财务, 流程 |
+
+## 概述
+
+定义公司费用报销的标准流程，涵盖申请、审批、核销三大阶段，确保财务合规性和报销效率。
+
+## 正文
+
+### 一、报销范围
+
+| 类别 | 说明 | 限额 |
+|------|------|------|
+| 差旅费 | 交通、住宿、餐饮 | 按出差地标准 |
+| 办公用品 | 设备、耗材、文具 | 单次 ≤ ¥2000 |
+| 招待费 | 客户/合作伙伴接待 | 需提前申请 |
+| 培训费 | 课程、考试、认证 | 需审批 |
+| 软件服务 | SaaS 订阅、API 费用 | 按需审批 |
+
+### 二、报销流程
+
+```
+提交申请 → 直属审批 → COO 审批（> ¥5000）
+→ 刘总审批（> ¥20000） → 刘诗妮核销 → 归档
+```
+
+**各环节时限**：
+- 员工提交：消费后 7 个工作日内
+- 直属审批：2 个工作日内
+- 核销：审批通过后 5 个工作日内
+
+### 三、报销材料
+
+1. **发票**
+   - 必须增值税普通/专用发票
+   - 发票抬头：公司全称 + 税号
+   - 电子发票可，纸质发票需原件
+
+2. **报销单**
+   - 事由：清晰说明消费目的
+   - 明细：逐项列出费用+金额
+   - 附件上传：发票图片/电子凭证
+
+3. **特殊说明**
+   - 差旅：附行程单
+   - 招待：附参与人员名单
+   - 大额采购：附比价记录
+
+### 四、常见退回原因
+
+| 原因 | 处理 |
+|------|------|
+| 发票信息错误（抬头/税号） | 退回重新开票 |
+| 超额未提前审批 | 补充说明或自付超额部分 |
+| 缺少明细说明 | 补充报销单信息 |
+| 超过报销时效 | 特殊说明后处理 |
+
+### 五、审批人
+
+| 金额区间 | 审批人 |
+|----------|--------|
+| ≤ ¥5000 | 直属负责人 |
+| ¥5001 ~ ¥20000 | + COO（陆怀瑾） |
+| > ¥20000 | + 刘总（Vincent） |
+
+## 相关条目
+
+- [合同模板.md](合同模板.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/规范/README.md

@@ -0,0 +1,25 @@
+# 规范领域知识
+
+**责任人**：严维序（opengineer）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖运维规范、安全标准、合规要求等规范类知识条目，支撑团队标准化运作。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [服务器运维标准_v1.0.md](../运维/服务器运维标准_v1.0.md) | 服务器巡检、监控、备份运维标准 | 见运维域 |
+
+## 待建设
+
+- 数据库运维标准
+- 安全审计基线
+- 数据合规处理流程
+
+---
+
+> 维护者：严维序（opengineer）
+> 最后更新：2026-06-24

knowledge/设计/README.md

@@ -0,0 +1,21 @@
+# 设计领域知识
+
+**责任人**：苏绘锦（designer）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖 UI/UX 设计规范、品牌元素、商详页设计、首图制作等设计知识。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [UI设计规范.md](UI设计规范.md) | 界面设计标准与组件规范 | ✅ |
+| [品牌元素指南.md](品牌元素指南.md) | 品牌色/字体/Logo 使用规范 | ✅ |
+
+## 待建设
+
+- 商详页设计模板
+- 首图设计规范
+- 移动端适配指南

knowledge/设计/UI设计规范.md

@@ -0,0 +1,87 @@
+# UI 设计规范
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 设计 |
+| **责任人** | 苏绘锦 (designer) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | UI, 设计规范, 组件, 视觉 |
+
+## 概述
+
+定义统一的 UI 设计标准，涵盖色彩、字体、间距、组件等基础规范，确保产品视觉一致性，降低设计-开发沟通成本。
+
+## 正文
+
+### 一、色彩系统
+
+| 用途 | 色值 | 说明 |
+|------|------|------|
+| 主色 Primary | `#1677FF` | 按钮、链接、选中态 |
+| 成功 Success | `#52C41A` | 成功提示、通过状态 |
+| 警告 Warning | `#FAAD14` | 警告提示 |
+| 错误 Error | `#FF4D4F` | 错误提示、删除操作 |
+| 文字主色 | `#1F1F1F` | 标题、正文 |
+| 文字次色 | `#666666` | 辅助说明 |
+| 文字禁用 | `#BFBFBF` | 禁用/占位符 |
+| 边框 | `#D9D9D9` | 分割线、输入框边框 |
+| 背景 | `#F5F5F5` | 页面底色 |
+
+### 二、字体规范
+
+| 层级 | 字号 | 行高 | 字重 | 用途 |
+|------|------|------|------|------|
+| H1 | 24px | 32px | 600 | 页面主标题 |
+| H2 | 20px | 28px | 600 | 区块标题 |
+| H3 | 16px | 24px | 500 | 小标题 |
+| Body | 14px | 22px | 400 | 正文 |
+| Caption | 12px | 18px | 400 | 辅助/说明文字 |
+
+默认字体：`-apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif`
+
+### 三、间距体系
+
+采用 4px 为基础单位的 8 点栅格：
+
+| Token | 值 | 用途 |
+|-------|-----|------|
+| xs | 4px | 紧凑间距 |
+| sm | 8px | 元素内间距 |
+| md | 16px | 组件间距 |
+| lg | 24px | 区块间距 |
+| xl | 32px | 大区块分隔 |
+| xxl | 48px | 页面级分隔 |
+
+### 四、圆角与阴影
+
+| 组件 | 圆角 | 阴影 |
+|------|------|------|
+| 卡片 | 8px | `0 2px 8px rgba(0,0,0,0.08)` |
+| 弹窗 | 12px | `0 6px 16px rgba(0,0,0,0.12)` |
+| 按钮 | 6px | 无（默认）/ hover 时微阴影 |
+| 输入框 | 6px | 无（默认）/ focus 时外发光 |
+
+### 五、响应式断点
+
+| 断点 | 最小宽度 | 适用设备 |
+|------|----------|----------|
+| xs | < 576px | 手机竖屏 |
+| sm | ≥ 576px | 手机横屏 |
+| md | ≥ 768px | 平板 |
+| lg | ≥ 992px | 小桌面 |
+| xl | ≥ 1200px | 大桌面 |
+| xxl | ≥ 1600px | 超大屏 |
+
+## 相关条目
+
+- [品牌元素指南.md](品牌元素指南.md)
+- [PRD模板.md](../产品/PRD模板.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/运维/README.md

@@ -0,0 +1,27 @@
+# 运维领域知识
+
+**责任人**：严维序（opengineer）
+**审核人**：陆怀瑾（coo）
+
+## 知识范围
+
+涵盖服务器运维、部署流程、故障排查、监控配置、安全保障等运维团队核心知识。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [部署流程_v1.0.md](部署流程_v1.0.md) | 服务部署 SOP 与变更管理流程 | ✅ |
+| [故障排查手册_v1.0.md](故障排查手册_v1.0.md) | 常见故障定位与处置方案 | ✅ |
+| [服务器运维标准_v1.0.md](服务器运维标准_v1.0.md) | 服务器巡检、监控、备份运维标准 | 🆕 |
+
+## 待建设
+
+- 数据库运维指南
+- 安全加固检查清单
+- 灾备与应急恢复预案
+
+---
+
+> 维护者：严维序（opengineer）
+> 最后更新：2026-06-24

knowledge/运维/故障排查手册_v1.0.md

@@ -0,0 +1,274 @@
+# 故障排查手册
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 运维 |
+| **责任人** | 严维序（opengineer） |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-24 |
+| **最后更新** | 2026-06-24 |
+| **标签** | 故障排查, 运维, 排障 |
+
+## 概述
+
+本手册汇总 BizWings 环境中常见的系统与服务故障定位方法和修复方案。覆盖 SSH 连接、Nginx、数据库、磁盘、Docker 等核心场景。
+
+---
+
+## 一、SSH 连接故障
+
+### 1.1 连接超时
+
+```bash
+# 诊断步骤
+ssh -vvv root@<ip> -p <port>    # 查看详细连接日志
+ping <ip>                        # 检查网络连通性
+nmap <ip> -p <port>              # 检查端口状态
+```
+
+**常见原因**：
+- 目标服务器防火墙未开放端口
+- 源 IP 未加入白名单
+- 服务器负载过高，sshd 响应慢
+
+**解决方案**：
+1. 检查服务器防火墙：`iptables -L -n` 或 `ufw status`
+2. 检查 sshd 是否运行：`systemctl status sshd`
+3. 检查负载：`top -n1 | head -5`
+
+### 1.2 认证失败
+
+```bash
+# 诊断步骤
+ssh -p <port> root@<ip>          # 尝试密码登录
+# Permission denied (publickey,password) 提示
+```
+
+**常见原因**：
+- 密码错误（检查 TOOLS.md 中记录）
+- SSH 密钥认证配置错误
+- `/etc/ssh/sshd_config` 中 `PasswordAuthentication no`
+
+**解决方案**：
+1. 确认密码与 TOOLS.md 一致
+2. 检查 `sshd_config`：`grep PasswordAuthentication /etc/ssh/sshd_config`
+3. 临时允许密码登录：`sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config && systemctl reload sshd`
+
+---
+
+## 二、Nginx 服务异常
+
+### 2.1 Nginx 启动失败 / 卡在 activating
+
+```bash
+# 诊断步骤
+systemctl status nginx           # 查看状态
+journalctl -u nginx --no-pager -n 50   # 查看日志
+nginx -t                          # 配置语法检查
+```
+
+**根因（经验）**：进程残留导致端口占用
+
+```bash
+# 修复
+pkill -9 nginx                   # 强制清理残留进程
+sleep 2
+systemctl start nginx            # 重新启动
+systemctl status nginx           # 确认状态
+```
+
+### 2.2 502 Bad Gateway
+
+```bash
+# 诊断步骤
+curl -I http://localhost:<upstream-port>    # 检查上游服务
+ss -tlnp | grep <upstream-port>             # 检查端口监听
+systemctl status <upstream-service>         # 检查上游进程
+```
+
+**常见原因**：
+- 上游服务未启动或崩溃
+- 连接池耗尽
+
+**解决方案**：
+1. 重启上游服务：`systemctl restart <service>`
+2. 检查 `upstream` 配置是否正确
+
+### 2.3 日志轮转失败
+
+```bash
+# 诊断步骤
+cat /var/log/nginx/error.log | head        # 查看是否有日志无法写入
+ls -la /var/log/nginx/                     # 查看日志文件
+/usr/sbin/logrotate -d /etc/logrotate.d/nginx  # 测试 logrotate
+```
+
+**修复方案**：
+```bash
+# 修改 /etc/logrotate.d/nginx 中的 postrotate 脚本
+# 将 invoke-rc.d nginx rotate 改为：
+postrotate
+    systemctl reload nginx
+endscript
+```
+
+---
+
+## 三、数据库连接故障
+
+### 3.1 MySQL 连接失败
+
+```bash
+# 诊断步骤
+mysql -h <host> -P <port> -u root -p      # 测试连接
+telnet <host> <port>                       # 检查端口
+systemctl status mysql                     # 检查服务
+```
+
+**常见原因**：
+- 服务未运行
+- 防火墙未放行 3306 端口
+- 用户权限 / host 限制
+- 连接数超限
+
+**解决方案**：
+```bash
+# 检查连接数
+mysql -e "SHOW VARIABLES LIKE 'max_connections';"
+mysql -e "SHOW PROCESSLIST;"
+
+# 检查用户权限
+mysql -e "SELECT user, host FROM mysql.user WHERE user='root';"
+```
+
+### 3.2 MySQL 空间不足
+
+```bash
+# 诊断
+df -h                                   # 磁盘空间
+mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024,2) AS size_mb FROM information_schema.tables GROUP BY table_schema ORDER BY size_mb DESC;"
+```
+
+**解决方案**：
+- 清理过期 binlog：`PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);`
+- 清理临时表
+- 扩展磁盘
+
+---
+
+## 四、磁盘空间告警
+
+### 4.1 诊断
+
+```bash
+df -h                                   # 查看各分区使用率
+du -sh /* 2>/dev/null | sort -rh | head -10   # 找到大文件目录
+find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null   # 大文件定位
+```
+
+### 4.2 清理方案
+
+```bash
+# Docker 日志和镜像清理
+docker system prune -af --volumes       # 清理未使用的 Docker 资源
+
+# 系统日志轮转
+journalctl --vacuum-time=7d             # 清理 7 天前的 journal 日志
+
+# 应用日志归档
+find /var/log -name "*.log" -mtime +30 -exec gzip {} \;   # 压缩旧日志
+find /var/log -name "*.gz" -mtime +90 -delete              # 删除 90 天前的压缩日志
+```
+
+---
+
+## 五、Docker 容器异常
+
+### 5.1 容器停止
+
+```bash
+docker ps -a | grep <container>         # 查看容器状态
+docker logs <container> --tail 50       # 查看最近日志
+```
+
+**修复**：
+```bash
+docker start <container>                # 手动启动
+docker compose -f <path> up -d         # 使用 Compose 重启
+```
+
+### 5.2 Docker API 无响应
+
+```bash
+systemctl status docker                 # 检查 Docker 服务
+journalctl -u docker --no-pager -n 50   # 查看 Docker 日志
+```
+
+**修复**：
+```bash
+systemctl restart docker                # 重启 Docker 守护进程
+```
+
+---
+
+## 六、系统进程故障
+
+### 6.1 端口被占用
+
+```bash
+ss -tlnp | grep <port>                  # 查看占用端口的进程
+fuser -k <port>/tcp                     # 强制释放端口
+```
+
+### 6.2 systemd 服务异常
+
+```bash
+systemctl status <service>              # 检查状态
+journalctl -u <service> --no-pager -n 100   # 查看服务日志
+
+# 常用修复
+systemctl daemon-reload                 # 重载 unit 文件
+systemctl restart <service>             # 重启
+systemctl enable <service>              # 设置开机自启
+```
+
+---
+
+## 七、日志分析工具
+
+### 7.1 常用命令
+
+```bash
+# 实时日志跟踪
+tail -f /var/log/<app>/access.log
+
+# 错误过滤
+grep -i "error\|exception\|failed" /var/log/<app>/app.log | tail -50
+
+# 时间范围过滤
+awk '/2026-06-24 10:00/,/2026-06-24 11:00/' /var/log/<app>/app.log
+```
+
+### 7.2 关键检查点
+
+| 故障表现 | 优先检查 | 常见根因 |
+|----------|----------|----------|
+| 服务无响应 | systemctl status | 进程 OOM / 崩溃 |
+| API 返回错误 | 应用日志 + Nginx 日志 | 代码 bug / 上游依赖异常 |
+| 高延迟 | top + ss + 应用日志 | 资源争抢 / 死锁 |
+| 数据库异常 | MySQL error log | 慢查询 / 连接数超限 |
+
+---
+
+## 相关条目
+
+- [部署流程_v1.0.md](部署流程_v1.0.md)
+- [服务器运维标准_v1.0.md](服务器运维标准_v1.0.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-24 | v1.0 | 初始创建 | 严维序 |

knowledge/运维/服务器运维标准_v1.0.md

@@ -0,0 +1,177 @@
+# 服务器运维标准
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 运维 |
+| **责任人** | 严维序（opengineer） |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-24 |
+| **最后更新** | 2026-06-24 |
+| **标签** | 运维, 监控, 巡检, 备份 |
+
+## 概述
+
+本文档定义 BizWings 团队所有服务器的日常运维标准，包括巡检频率、监控指标、备份策略和安全基线。适用于所有生产环境服务器（阿里云 / 家庭内网 / HP 服务器）。
+
+---
+
+## 一、服务器巡检标准
+
+### 1.1 巡检频率
+
+| 类型 | 频率 | 执行方式 |
+|------|------|----------|
+| 心跳自检 | 每 10 分钟 | openclaw 心跳自动巡检 |
+| 深度巡检 | 每日一次 | 手动执行 `python3 $SCRIPTS/heartbeat_helper.py opengineer` |
+| 全量巡检 | 每周一次 | 逐个检查全部服务器 |
+
+### 1.2 巡检清单
+
+#### 资源负载
+```bash
+# 磁盘使用率（警告 > 80%，严重 > 90%）
+df -h | grep -v tmpfs
+
+# CPU 负载
+uptime
+
+# 内存使用
+free -h
+
+# 网络 IO
+sar -n DEV 1 3
+```
+
+#### 服务状态
+```bash
+# 核心服务清单（按实际部署确认）
+systemctl status nginx mysql docker sshd
+
+# Docker 容器健康
+docker ps | grep -c "Up"
+```
+
+#### 日志异常
+```bash
+# 最近 10 分钟的错误日志
+journalctl --since "10 min ago" -p err --no-pager | tail -20
+```
+
+---
+
+## 二、监控指标定义
+
+### 2.1 告警阈值
+
+| 指标 | 警告 (WARN) | 严重 (CRIT) | 处理 |
+|------|-------------|-------------|------|
+| 磁盘使用率 | > 80% | > 90% | 清理日志 / 扩容 |
+| CPU 负载 (1min) | > 4.0 | > 8.0 | 检查异常进程 |
+| 内存使用率 | > 85% | > 95% | 检查 OOM 风险 |
+| 根分区 inode | > 80% | > 90% | 清理小文件 |
+| 服务进程 | 停止 | — | 重启服务 |
+| 端口监听 | 消失 | — | 检查服务状态 |
+| Docker 容器 | 非 Up | — | docker start / compose up |
+
+### 2.2 日志监控
+
+- 系统日志：`journalctl -p err` 重点关注
+- 应用日志：`error`, `exception`, `failed`, `timeout` 关键词监控
+- Nginx 日志：5xx 错误率 > 1% 时触发调查
+
+---
+
+## 三、备份策略
+
+### 3.1 数据库备份
+
+```bash
+# MySQL 全量备份（建议每日凌晨执行）
+mysqldump --all-databases --single-transaction --quick | gzip > /backup/db/all-$(date +%Y%m%d).sql.gz
+```
+
+### 3.2 配置备份
+- 服务器配置文件：`/backup/conf/<server>/` 目录
+- 每次变更前执行：`cp <config> <config>.$(date +%Y%m%d-%H%M%S).bak`
+
+### 3.3 Docker 数据备份
+```bash
+# 思源笔记备份（已配置每日 3:00）
+tar czf /backup/siyuan/siyuan-data-$(date +%Y%m%d).tar.gz -C <data-dir> .
+```
+
+### 3.4 备份保留策略
+
+| 类型 | 保留期限 |
+|------|----------|
+| 数据库全量备份 | 30 天 |
+| 配置备份 | 90 天 |
+| Docker 数据 | 7 天 |
+| 日志归档 | 90 天 |
+
+---
+
+## 四、变更管理标准
+
+### 4.1 变更准入
+
+- ✅ 每次变更前必须备份原始文件
+- ✅ 高危操作（防火墙、内核、数据库）必须保留回滚方案
+- ✅ 变更前评估影响范围
+- ✅ 变更后验证服务状态
+- ❌ 禁止在无备份的情况下直接修改生产配置
+- ❌ 禁止在高峰时段执行非紧急变更
+
+### 4.2 变更分级
+
+| 级别 | 示例 | 要求 |
+|------|------|------|
+| 低风险 | 普通应用更新 | 备份 → 部署 → 验证 |
+| 中风险 | 配置修改 | 备份 → 预演 → 部署 → 验证 |
+| 高风险 | 内核 / 防火墙 / 数据库 | 备份 → 预演 → 通知 → 部署 → 验证 → 监控 |
+
+---
+
+## 五、安全基线
+
+### 5.1 基本要求
+
+- [ ] SSH 禁止 root 密码登录（高风险服务器）
+- [ ] 防火墙最小权限原则
+- [ ] 非必要端口不对外开放
+- [ ] 定期更新系统安全补丁
+- [ ] 日志审计开启
+
+### 5.2 密码管理
+
+- 服务器密码统一记录在 TOOLS.md
+- 数据库密码统一管理
+- 禁止在代码中硬编码密码
+
+---
+
+## 六、服务器清单与分类
+
+| 环境 | 服务器数 | 用途 | 巡检频率 |
+|------|----------|------|----------|
+| 阿里云生产 | 3 | 应用服务、数据库 | 每次心跳 |
+| 家庭内网生产 | 4 | 应用、数据库、PVE | 每次心跳 |
+| HP 测试 | 3 | 测试、NAS | 每日 |
+| 树莓派 | 1 | 辅助设备 | 每日 |
+
+详细清单见 TOOLS.md「SSH/WinRM 服务器清单」
+
+---
+
+## 相关条目
+
+- [部署流程_v1.0.md](部署流程_v1.0.md)
+- [故障排查手册_v1.0.md](故障排查手册_v1.0.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-24 | v1.0 | 初始创建 | 严维序 |

knowledge/运维/部署流程_v1.0.md

@@ -0,0 +1,202 @@
+# 服务部署流程 SOP
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 运维 |
+| **责任人** | 严维序（opengineer） |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-24 |
+| **最后更新** | 2026-06-24 |
+| **标签** | 部署, 运维, SOP |
+
+## 概述
+
+本文档定义 BizWings 团队所有业务服务的部署流程标准，涵盖部署前检查、执行步骤、验证测试和回滚预案。适用于所有生产环境的代码部署与服务更新。
+
+---
+
+## 一、部署前置检查
+
+### 1.1 代码准备
+
+- [ ] 代码已合并到目标分支（main / release）
+- [ ] PR 已通过 Code Review 并合并
+- [ ] 本地或 CI 构建通过（编译无报错）
+- [ ] 版本号已更新（如有）
+
+### 1.2 环境检查
+
+- [ ] 目标服务器磁盘空间充足（> 剩余 20%）
+- [ ] CPU / 内存负载正常（< 80%）
+- [ ] 网络连通性：本机 → 目标服务器可达
+- [ ] 目标端口未被占用
+- [ ] 依赖服务（数据库 / 中间件）运行正常
+
+### 1.3 备份准备
+
+- [ ] **配置备份**：服务器配置文件备份到 `/backup/conf/` 目录
+- [ ] **数据库备份**：涉及数据库变更，先执行 `mysqldump` 全量备份
+- [ ] **当前版本标记**：记录当前运行版本号或 Git commit hash
+
+---
+
+## 二、部署执行步骤
+
+### 2.1 文件分发
+
+```bash
+# 标准部署（SSH + scp/rsync）
+scp -P <port> ./dist/app root@<server>:/opt/app/
+# 或使用 rsync 增量同步
+rsync -avz --delete -e "ssh -p <port>" ./dist/ root@<server>:/opt/app/
+```
+
+### 2.2 服务更新
+
+#### 方式 A：systemd 服务
+```bash
+# 1. 停止服务
+systemctl stop <service-name>
+
+# 2. 备份旧版本（如有必要）
+mv /opt/app/<app> /opt/app/<app>.bak
+
+# 3. 放置新版本
+cp /tmp/<app> /opt/app/<app>
+chmod +x /opt/app/<app>
+
+# 4. 重启服务
+systemctl start <service-name>
+systemctl status <service-name>
+```
+
+#### 方式 B：Docker 容器
+```bash
+# 1. 拉取新镜像
+docker pull <registry>/<image>:<tag>
+
+# 2. 停止旧容器
+docker stop <container-name>
+docker rm <container-name>
+
+# 3. 启动新容器
+docker run -d --name <container-name> \
+  --restart unless-stopped \
+  -p <host-port>:<container-port> \
+  <registry>/<image>:<tag>
+```
+
+#### 方式 C：Nginx 反向代理更新
+```bash
+# 更新上游配置后重载
+nginx -t                    # 语法检查
+systemctl reload nginx      # 热重载
+```
+
+### 2.3 配置变更
+
+```bash
+# 1. 备份当前配置
+cp /etc/<app>/config.yml /etc/<app>/config.yml.$(date +%Y%m%d-%H%M%S)
+
+# 2. 修改配置
+vim /etc/<app>/config.yml
+
+# 3. 重启服务使配置生效
+systemctl restart <service-name>
+```
+
+---
+
+## 三、部署验证
+
+### 3.1 连通性验证
+```bash
+# 服务端口监听确认
+ss -tlnp | grep <port>
+
+# HTTP 服务健康检查
+curl -s -o /dev/null -w "%{http_code}" http://localhost:<port>/health
+# 预期返回：200
+```
+
+### 3.2 功能验证
+
+- [ ] API 基础功能运行正常
+- [ ] 日志无新增 ERROR 级别报错
+- [ ] 数据库连接正常
+- [ ] 前端页面（如有）可正常加载
+
+### 3.3 监控确认
+
+- [ ] Prometheus / Grafana 指标正常
+- [ ] 日志系统（如有）已捕获新日志
+- [ ] 告警规则未被触发
+
+---
+
+## 四、回滚方案
+
+### 4.1 代码回滚
+```bash
+# Git 回滚到上一版本
+cd /opt/app/repo
+git revert HEAD --no-edit
+git push
+# 重新执行部署
+```
+
+### 4.2 文件回滚
+```bash
+# 恢复备份文件
+mv /opt/app/<app>.bak /opt/app/<app>
+systemctl restart <service-name>
+```
+
+### 4.3 数据库回滚
+```bash
+# 导入备份
+gunzip < /backup/db/<dbname>.$(date +%Y%m%d).sql.gz | mysql -u root -p<pass> <dbname>
+```
+
+### 4.4 回滚确认
+- [ ] 旧版本服务运行正常
+- [ ] 端口监听确认
+- [ ] 用户无访问异常
+- [ ] 记录回滚原因到工作日志
+
+---
+
+## 五、部署后记录
+
+### 5.1 必填信息
+
+| 项目 | 内容 |
+|------|------|
+| 部署时间 | YYYY-MM-DD HH:mm |
+| 部署人 | 严维序（opengineer） |
+| 部署内容 | [简要描述] |
+| 版本 | commit hash / tag |
+| 验证结果 | ✅/❌ 通过 |
+| 回滚情况 | 无需回滚 / 已回滚（原因） |
+
+### 5.2 记录位置
+
+- 工作日志：`memory/YYYY-MM-DD.md`
+- 任务记录：WorkBoard 相关卡片注释
+- 知识更新：如部署暴露流程问题，更新本文档
+
+---
+
+## 相关条目
+
+- [故障排查手册_v1.0.md](故障排查手册_v1.0.md)
+- [服务器运维标准_v1.0.md](服务器运维标准_v1.0.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-24 | v1.0 | 初始创建 | 严维序 |

knowledge/运营/README.md

@@ -0,0 +1,21 @@
+# 运营领域知识
+
+**责任人**：陆怀瑾（coo）
+**审核人**：刘炜承（Vincent）
+
+## 知识范围
+
+涵盖活动策划、数据分析、SOP 管理、流程优化、团队协作等运营管理知识。
+
+## 条目清单
+
+| 文件名 | 说明 | 状态 |
+|--------|------|------|
+| [活动策划模板.md](活动策划模板.md) | 营销活动策划标准模板 | ✅ |
+| [数据分析方法.md](数据分析方法.md) | 运营数据分析框架与方法 | ✅ |
+
+## 待建设
+
+- 周报模板
+- KPI 管理框架
+- 风险评估矩阵

knowledge/运营/数据分析方法.md

@@ -0,0 +1,92 @@
+# 数据分析方法
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 运营 |
+| **责任人** | 陆怀瑾 (coo) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 数据分析, 运营, KPI, 看板 |
+
+## 概述
+
+建立全业务流程的数据分析框架，确保各业务线有统一的指标定义和分析方法，支撑数据驱动决策。
+
+## 正文
+
+### 一、核心指标体系
+
+#### 1. 电商业务
+
+| 层级 | 指标 | 定义 | 频率 |
+|------|------|------|------|
+| 北极星 | GMV | 总成交额 | 日/周/月 |
+| 过程 | 转化率 | 下单数/访客数 | 日 |
+| 过程 | 客单价 | GMV/订单数 | 周 |
+| 过程 | 退货率 | 退货数/订单数 | 周 |
+| 健康 | DSR | 描述/服务/物流评分 | 日 |
+| 健康 | 获客成本 CAC | 营销花费/新客数 | 月 |
+
+#### 2. 内容业务
+
+| 层级 | 指标 | 定义 | 频率 |
+|------|------|------|------|
+| 北极星 | 粉丝增长 | 净增粉丝数 | 周/月 |
+| 过程 | 互动率 | (点赞+收藏+评论)/曝光 | 篇 |
+| 过程 | 发布频率 | 每周发布篇数 | 周 |
+
+#### 3. 公司整体
+
+| 层级 | 指标 | 定义 | 频率 |
+|------|------|------|------|
+| 北极星 | 月营收 | 各业务线收入合计 | 月 |
+| 效率 | 人效 | 营收/团队人数 | 季 |
+| 效率 | Agent 利用率 | Agent 任务完成数/总分配数 | 周 |
+
+### 二、分析框架
+
+**AARRR 海盗模型**：
+
+```
+Acquisition（获取）→ Activation（激活）→ Retention（留存）
+→ Revenue（收入）→ Referral（推荐）
+```
+
+**电商应用示例**：
+1. Acquisition：各渠道流量来源占比
+2. Activation：首次下单转化率
+3. Retention：30 天复购率
+4. Revenue：LTV（用户生命周期价值）
+5. Referral：分享率、裂变系数
+
+### 三、数据看板要求
+
+每个业务线需维护以下看板：
+
+| 看板 | 内容 | 更新频率 |
+|------|------|----------|
+| 日报 | 昨日核心指标 + 异常波动标注 | 每日 10:00 |
+| 周报 | 趋势图 + 同比/环比 + 分析洞察 | 每周一 |
+| 月报 | 完整指标矩阵 + 目标达成率 + 下月预测 | 每月 3 日 |
+
+### 四、异常预警规则
+
+| 条件 | 级别 | 响应 |
+|------|------|------|
+| GMV 日环比下降 > 20% | 🔴 | COO 立即介入 |
+| 转化率连续 3 天下降 | 🟡 | 业务负责人分析 |
+| 退货率 > 10% | 🟡 | 商品/客服联合排查 |
+| DSR < 4.6 | 🔴 | 立即优化 |
+
+## 相关条目
+
+- [淘宝运营SOP.md](../电商/淘宝运营SOP.md)
+- [活动策划模板.md](活动策划模板.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

knowledge/运营/活动策划模板.md

@@ -0,0 +1,80 @@
+# 活动策划模板
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 运营 |
+| **责任人** | 陆怀瑾 (coo) |
+| **版本** | v1.0 |
+| **创建日期** | 2026-06-22 |
+| **标签** | 运营, 活动策划, 营销, 模板 |
+
+## 概述
+
+标准化营销活动策划流程。适用于电商大促（618/双11/年货节）、店铺周年庆、新品发布、会员日活动等。
+
+## 正文
+
+### 一、活动策划文档结构
+
+```
+# [活动名称] 策划方案
+
+## 1. 活动背景与目标
+- 背景：[为什么做这次活动]
+- 核心目标：[可量化，如 GMV X万 / 新增粉丝 Y人]
+- 次要目标：[如品牌曝光、老客复购]
+
+## 2. 目标用户
+- 主要人群：[画像描述]
+- 需求动机：[为什么他们会参与]
+
+## 3. 活动机制
+- 玩法规则：[满减/秒杀/抽奖/打卡]
+- 用户路径：[从看到到参与的完整链路]
+- 激励机制：[优惠力度、稀缺性、社交裂变]
+
+## 4. 资源与预算
+| 项目 | 预算 | 负责人 |
+|------|------|--------|
+| 流量投放 | ¥XX | [姓名] |
+| 商品补贴 | ¥XX | [姓名] |
+| 内容物料 | ¥XX | [姓名] |
+
+## 5. 时间线
+| 阶段 | 时间 | 关键事项 |
+|------|------|----------|
+| 预热期 | D-7 ~ D-1 | 预告内容、优惠券发放 |
+| 爆发期 | D-Day | 主活动上线 |
+| 返场期 | D+1 ~ D+3 | 余热运营 |
+
+## 6. 风险预案
+| 风险 | 概率 | 影响 | 应对 |
+|------|------|------|------|
+| 服务器崩溃 | 中 | 高 | 提前压测 + 降级方案 |
+| 库存不足 | 低 | 中 | 预售 + 安全库存预警 |
+
+## 7. 复盘框架
+- 活动数据回顾（GMV/ROI/客单价/转化率）
+- 亮点与不足
+- 优化建议
+```
+
+### 二、关键审批节点
+
+1. **策划方案评审** → COO + 业务负责人
+2. **预算审批** → Vincent
+3. **法务合规审查** → 苏慎（如涉及抽奖/满赠）
+4. **上线前 Checklist** → 所有执行人确认
+
+## 相关条目
+
+- [数据分析方法.md](数据分析方法.md)
+- [淘宝运营SOP.md](../电商/淘宝运营SOP.md)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| 2026-06-22 | v1.0 | 初始创建 | 陆怀瑾 |

plans/BIZ-13_运行稳定性保障方案.md

@@ -1,9 +1,9 @@
 # BIZ-13 智能体运行稳定性保障方案
 
-> 版本：v1.0  
+> 版本：v1.1  
 > 编制：陆怀瑾（COO）  
 > 日期：2026-06-22  
-> 状态：待审阅
+> 状态：Phase 1 执行中（Vincent 已审阅同意）
 
 ---
 
@@ -305,9 +305,10 @@ def retry_with_backoff(api_call, max_retries=3):
 ## 七、实施步骤
 
 ### 阶段 1：心跳机制落地（本周）
-- [ ] 更新所有 Agent 的 HEARTBEAT.md
-- [ ] 配置定时任务（10 分钟）
-- [ ] 测试超时检测
+- [x] 更新所有 Agent 的 HEARTBEAT.md（15/15 Agent 已完成）
+- [x] 已创建分步实施子任务（BIZ-24 ~ BIZ-28，5个子任务）
+- [ ] 配置定时任务（10/15 分钟）→ BIZ-25，已分派 opengineer 严维序
+- [ ] 测试超时检测 → BIZ-24 执行中
 
 ### 阶段 2：限流优化（下周）
 - [ ] 实现请求队列

plans/BIZ-24_HEARTBEAT增强模板方案.md

@@ -0,0 +1,835 @@
+# BIZ-24 HEARTBEAT.md 增强模板方案
+
+> Phase 1 of BIZ-13 运行稳定性保障方案
+> 版本：v1.1（2026-06-22 优化：增加全任务源统一监控；已部署）
+> 编制：陆怀瑾（COO）
+> 日期：2026-06-22
+> 状态：已部署
+> 关联：[BIZ-13 运行稳定性保障方案](BIZ-13_运行稳定性保障方案.md)
+
+---
+
+## 一、目标
+
+为所有 Agent 的 HEARTBEAT.md 文件统一增强以下机制，解决任务停滞、运行异常与工作遗漏问题：
+
+1. **全任务源统一监控** — 覆盖 OpenClaw WorkBoard + Multica Issues + 待办文档，避免工作遗漏
+2. **禁止请示规则** — 消除"等待用户确认"导致的任务卡死
+3. **超时检测规则** — 按 Agent 类型差异化配置心跳频率
+4. **自动恢复规则** — 检测无进展时自动重新调度
+5. **依赖检查前置** — 任务启动前强制检查所有依赖
+6. **最大轮次限制** — 防止无限循环或资源耗尽
+
+### 1.1 为什么需要全任务源统一监控
+
+当前 Agent 工作面临的任务来源是多平台的：
+
+| 任务来源 | 平台/工具 | 查询方式 | 当前监控状态 |
+|----------|-----------|----------|------------|
+| WorkBoard 卡片 | OpenClaw workboard | `openclaw workboard list` | ✅ 已纳入 |
+| 待办文档 | 各 Agent workspace 的 TODO.md / AGENTS.md | 文件读取 | ⚠️ 部分纳入 |
+| Multica Issues | Multica 平台 | `multica issue list --assignee-id <id>` | ❌ 未纳入 |
+
+**问题**：Multica Issues 中分配给 Agent 的任务当前完全不在心跳监控范围内，Agent 可能永远不会发现并执行这些任务，导致工作永久遗漏。
+
+**对策**：每次心跳同步检查以上三个来源，确保无一遗漏。
+
+---
+
+## 二、Agent 分类与参数配置
+
+### 2.1 分类标准
+
+| 分类 | 特征 | Agent |
+|------|------|-------|
+| 高频 Agent | 需频繁检查任务状态、全局监控 | secretary, coo |
+| 开发 Agent | 执行开发/设计/部署等长周期任务 | projectmanager, productmanager, architect, costcodev, designer, opengineer |
+| 业务 Agent | 执行专项业务任务 | taobaospecialist, contentspecialist, mediaspecialist, cvexpert, marketanalysis, lawyer |
+
+### 2.2 参数配置矩阵
+
+| 参数 | 高频 Agent | 开发 Agent | 业务 Agent |
+|------|-----------|-----------|-----------|
+| 心跳频率 | 10 分钟 | 15 分钟 | 15 分钟 |
+| 最大轮次 | 50 轮 | 100 轮 | 30 轮 |
+| 超时告警阈值 | 20 分钟无进展 | 30 分钟无进展 | 30 分钟无进展 |
+| 自动恢复等待 | 30 分钟后重新调度 | 45 分钟后重新调度 | 45 分钟后重新调度 |
+| 告警通知对象 | COO | COO + 创建者 | 创建者 |
+
+---
+
+## 三、六项增强规则详解
+
+### 规则 0：全任务源统一监控
+
+**问题**：Agent 的任务分布在多个平台（OpenClaw WorkBoard、Multica Issues、工作区待办文档），各平台独立存在，Agent 只监控其中一部分会导致工作任务被永久遗漏。
+
+**规则文本**：
+```markdown
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+> 你的工作任务可能存在于三个地方：OpenClaw WorkBoard、Multica Issues、本地待办文档。
+
+### 任务源检查清单（按优先级）
+
+#### 第一优先级：OpenClaw WorkBoard 卡片
+
+\```bash
+# 检查 WorkBoard 中分配给自己的待办卡片
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+my_cards = [c for c in data.get('cards', [])
+             if c.get('agentId') == '<your_agent_id>' and c.get('status') == 'todo']
+for c in my_cards:
+    print(f'WORKBOARD TODO: {c[\"id\"][:8]} [priority={c.get(\"priority\",\"?\")}] {c[\"title\"]}')
+"
+\```
+
+#### 第二优先级：Multica Issues
+
+\```bash
+# 检查 Multica 中分配给自己的待办 Issue
+multica issue list --assignee-id <your_multica_agent_uuid> --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+for issue in data:
+    print(f'MULTICA TODO: {issue[\"identifier\"]} [{issue.get(\"priority\",\"?\")}] {issue[\"title\"]}')
+"
+\```
+
+#### 第三优先级：待办文档
+
+\```bash
+# 检查工作区待办文档（TODO.md 或 AGENTS.md 中未完成的任务）
+grep -n '\[ \]' TODO.md AGENTS.md 2>/dev/null || echo "无待办文档"
+\```
+
+### 三源合并决策
+
+```
+心跳开始
+    ↓
+检查 WorkBoard 待办卡片
+    ↓
+检查 Multica Issues 待办
+    ↓
+检查待办文档
+    ↓
+合并去重（避免同一任务在不同来源重复出现）
+    ↓
+按优先级排序后依次执行
+```
+
+### Multica Issue 认领与执行流程
+
+```
+发现 Multica todo Issue（assignee 是自己）
+    ↓
+启动 Multica Runtime 执行任务
+    ↓
+完成后通过 multica issue comment add 汇报结果
+    ↓
+更新 issue status 为 in_review / done
+```
+
+### COO 专属：全平台积压巡检
+
+作为 COO，还需要额外检查全平台的任务积压情况（不限自己）：
+
+\```bash
+#!/bin/bash
+# COO 全平台任务积压巡检脚本
+
+echo "=== OpenClaw WorkBoard 全局积压 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+cards = data.get('cards', [])
+todo = [c for c in cards if c.get('status') == 'todo']
+inprog = [c for c in cards if c.get('status') == 'in_progress']
+print(f'  待办: {len(todo)} | 进行中: {len(inprog)} | 总计: {len(cards)}')
+if len(todo) > 5:
+    print(f'  ⚠️ 积压告警：待办超过 5 个，需协调资源')
+for c in todo[:10]:
+    print(f'    {c[\"id\"][:8]} → {c.get(\"agentId\",\"?\")} - {c[\"title\"][:60]}')
+"
+
+echo ""
+echo "=== Multica Issues 全局积压 ==="
+multica issue list --status todo --output json 2>/dev/null | python3 -c "
+import sys, json
+data = json.load(sys.stdin)
+print(f'  待办: {len(data)}')
+if len(data) > 5:
+    print(f'  ⚠️ 积压告警：Multica 待办超过 5 个')
+for issue in data[:10]:
+    print(f'    {issue[\"identifier\"]} → {issue.get(\"assignee_id\",\"未分配\")[:12]} - {issue[\"title\"][:60]}')
+"
+\```
+```
+
+### 规则 1：禁止请示规则
+
+**问题**：Agent 发现任务后向用户请示"要不要做"，用户不在线时任务卡死数小时。
+
+**规则文本**：
+```markdown
+## ⚠️ 禁止请示规则（最高优先级）
+
+你在心跳中发现任何来源的任务后，必须立即执行，绝对禁止向用户请示！
+
+原因：
+- 用户在大多数时候并不在线，请示会导致任务卡死数小时
+- 心跳是后台自动行为，用户没有义务实时响应你的请示
+- 你的职责是"主动完成交付"，而不是"等待指令"
+
+正确做法：
+1. 发现任何来源的待办任务（WorkBoard / Multica / 待办文档）
+2. 立即认领并执行
+3. 如遇信息不足，先按自己的最佳理解执行，执行中再调整
+4. 任务完成后，通过对应平台汇报结果
+
+错误做法（绝对禁止）：
+- ❌ "我发现了一个任务，要不要做？"
+- ❌ "这个任务需要更多信息，请告诉我..."
+- ❌ "任务已完成，请确认是否符合要求"
+```
+
+### 规则 2：超时检测规则
+
+**问题**：Agent 执行到某一步后卡住，长时间无输出，无任何监告。
+
+**规则文本**：
+
+高频 Agent 版：
+```markdown
+## ⏱️ 超时检测规则
+
+### 心跳频率：10 分钟
+每次心跳执行以下检测：
+1. 检查所有平台进行中任务的最新更新时间（WorkBoard + Multica）
+2. 如超过 20 分钟无进展 → 标记为"疑似超时"
+3. 疑似超时 → 立即追加一次完整心跳，尝试推进
+4. 如确认超时 → 进入自动恢复流程
+
+### 跨平台超时检测脚本
+\```bash
+# 检查进行中任务是否超时（WorkBoard + Multica）
+echo "=== WorkBoard 超时检测 ==="
+openclaw workboard list --json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+inprogress = [c for c in data.get('cards', []) if c.get('status') == 'in_progress']
+now = time.time()
+for c in inprogress:
+    updated = c.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ WB TIMEOUT: {c[\"id\"][:8]} [{c.get(\"agentId\",\"?\")}] {c[\"title\"]}')
+"
+
+echo "=== Multica 超时检测 ==="
+multica issue list --status in_progress --output json 2>/dev/null | python3 -c "
+import sys, json, time
+data = json.load(sys.stdin)
+now = time.time()
+for issue in data:
+    updated = issue.get('updated_at', '')
+    if updated:
+        age = now - time.mktime(time.strptime(updated[:19], '%Y-%m-%dT%H:%M:%S'))
+        if age > 1200:
+            print(f'⏰ MUL TIMEOUT: {issue[\"identifier\"]} [{issue.get(\"assignee_id\",\"?\")[:12]}] {issue[\"title\"]}')
+"
+\```
+```
+
+开发 Agent 版（差异部分）：
+```markdown
+### 心跳频率：15 分钟
+每次心跳执行以下检测：
+1. 检查所有平台进行中任务的最新更新时间（WorkBoard + Multica）
+2. 如超过 30 分钟无进展 → 标记为"疑似超时"
+```
+
+业务 Agent 版（差异部分）：
+```markdown
+### 心跳频率：15 分钟
+每次心跳执行以下检测：
+1. 检查所有平台进行中任务的最新更新时间（WorkBoard + Multica）
+2. 如超过 30 分钟无进展 → 标记为"疑似超时"
+```
+
+### 规则 3：自动恢复规则
+
+**问题**：检测到无进展后没有自动恢复手段，任务永久停滞。
+
+**规则文本**：
+```markdown
+## 🔄 自动恢复规则
+
+### 恢复流程
+```
+检测到超时（跨平台无进展超阈值）
+    ↓
+步骤 1：追加一次完整心跳，尝试推进任务
+    ↓
+步骤 2：检查任务状态
+    ↓
+┌─────────────┴─────────────┐
+│                           │
+有进展                     仍无进展
+    │                           │
+重置超时计数器              步骤 3：通知 COO/创建者
+    │                           │
+继续执行                    步骤 4：通过对应平台标记 blocked
+                                │
+                           步骤 5：重新调度（分配备用 Agent 或
+                                   等待人工介入）
+```
+
+### 自动恢复触发条件
+- 高频 Agent：超 30 分钟无进展 → 自动重新调度
+- 开发 Agent：超 45 分钟无进展 → 自动重新调度
+- 业务 Agent：超 45 分钟无进展 → 自动重新调度
+
+### 跨平台恢复操作
+**WorkBoard 任务**：
+1. 添加评论说明超时原因
+2. 释放 Agent 认领（release claim）
+3. 通知 COO 重新分配
+
+**Multica Issue**：
+1. `multica issue comment add` 说明超时原因
+2. `multica issue status <id> blocked`
+3. 通知 COO 重新分配
+
+**待办文档任务**：
+1. 在原文档中标注超时状态
+2. 如可转为 WorkBoard 卡片 → 创建卡片并通知 COO
+```
+
+### 规则 4：依赖检查前置
+
+**问题**：任务开始后才发现依赖未满足，浪费 Agent 时间，且可能导致循环等待。
+
+**规则文本**：
+```markdown
+## 🔗 依赖检查前置规则
+
+### 任务启动前强制检查
+每次认领或启动任务前，必须执行依赖检查：
+
+**WorkBoard 任务**：
+1. 读取任务的 depends_on 字段
+2. 逐一检查每个依赖任务的状态
+3. 所有依赖 ready → 可以启动
+4. 任一依赖未完成 → 禁止启动，标记为 blocked
+
+**Multica Issue**：
+1. 读取 issue 的 parent_issue_id
+2. 检查父 issue 状态
+3. 父 issue 未完成 → 禁止启动
+
+### 检查脚本
+
+#### WorkBoard 依赖检查
+\```bash
+openclaw workboard read <card-id> --json 2>/dev/null | python3 -c "
+import sys, json
+card = json.load(sys.stdin)
+deps = card.get('dependsOn', [])
+if deps:
+    for dep in deps:
+        print(f'依赖: {dep[\"id\"]} → 状态: {dep.get(\"status\", \"?\")}')
+        if dep.get('status') != 'done':
+            print(f'⛔ WB 依赖未满足，禁止启动 {card[\"id\"][:8]}')
+            sys.exit(1)
+    print('✅ 所有 WB 依赖已满足')
+else:
+    print('✅ 无 WB 依赖，可以启动')
+"
+\```
+
+#### Multica 依赖检查
+\```bash
+multica issue get <issue-id> --output json 2>/dev/null | python3 -c "
+import sys, json
+issue = json.load(sys.stdin)
+parent_id = issue.get('parent_issue_id')
+if parent_id:
+    import subprocess
+    result = subprocess.run(['multica', 'issue', 'get', parent_id, '--output', 'json'],
+                            capture_output=True, text=True)
+    parent = json.loads(result.stdout)
+    if parent.get('status') != 'done':
+        print(f'⛔ MUL 父 Issue {parent[\"identifier\"]} 未完成，禁止启动')
+        sys.exit(1)
+    print(f'✅ 父 Issue {parent[\"identifier\"]} 已完成')
+else:
+    print('✅ 无父 Issue 依赖，可以启动')
+"
+\```
+
+### 依赖未满足时的处理
+1. 不认领任务（保持 todo 状态）
+2. 不在该任务上浪费心跳时间
+3. 如超过等待阈值（高频 1h / 开发/业务 2h），通知依赖任务的执行者
+```
+
+### 规则 5：最大轮次限制
+
+**问题**：Agent 陷入无限循环，反复执行相同逻辑无进展，持续消耗 API 配额。
+
+**规则文本**：
+
+高频 Agent 版：
+```markdown
+## 🛑 最大轮次限制
+
+### 限制值：50 轮
+单次任务执行不得超过 50 个对话轮次。
+
+### 检测机制
+- 每次心跳记录已消耗轮次
+- 接近上限（80%）时发出预警
+- 达到上限时自动暂停
+
+### 超限处理
+```
+达到最大轮次
+    ↓
+1. 暂停任务执行
+2. 记录已完成的步骤和未完成的部分
+3. 通知 COO，附当前进度
+4. COO 决定：重新分配 / 拆分任务 / 人工介入
+```
+
+### 跨平台轮次跟踪
+- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
+- **Multica**：通过 issue comment 记录轮次进度
+- **待办文档**：在工作日志中记录
+
+### 计数器维护
+\```bash
+# 每次心跳更新轮次计数
+# 轮次数据存储在任务 metadata 或 comment 中
+\```
+```
+
+开发 Agent 版（差异部分）：
+```markdown
+### 限制值：100 轮
+单次任务执行不得超过 100 个对话轮次。
+```
+
+业务 Agent 版（差异部分）：
+```markdown
+### 限制值：30 轮
+单次任务执行不得超过 30 个对话轮次。
+```
+
+---
+
+## 四、HEARTBEAT.md 完整增强模板
+
+### 4.1 高频 Agent 完整模板（secretary / coo）
+
+```markdown
+# HEARTBEAT.md - [Agent Name] 的心跳配置
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+1. **OpenClaw WorkBoard** — workboard list → 查找 agent_id=自己 & status=todo
+2. **Multica Issues** — issue list --assignee-id <uuid> --status todo
+3. **待办文档** — 检查 TODO.md / AGENTS.md 中未完成的任务
+
+### 合并去重 → 按优先级排序 → 依次执行
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：10 分钟
+每次心跳跨平台执行以下检测：
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 20 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+- 超 30 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO |
+| Multica | 添加评论 → status=blocked → 通知 COO |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（1h）→ 通知依赖任务执行者
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：50 轮
+- 接近 80%（40 轮）→ 预警
+- 达到上限 → 暂停，通知 COO
+
+---
+
+## 🫀 心跳执行清单
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ 全平台积压巡检（仅 COO）
+6. ✅ [Agent 专属检查项]
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+```
+
+### 4.2 开发 Agent 完整模板（projectmanager / productmanager / architect / costcodev / designer / opengineer）
+
+```markdown
+# HEARTBEAT.md - [Agent Name] 的心跳配置
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+1. **OpenClaw WorkBoard** — workboard list → 查找 agent_id=自己 & status=todo
+2. **Multica Issues** — issue list --assignee-id <uuid> --status todo
+3. **待办文档** — 检查 TODO.md / AGENTS.md 中未完成的任务
+
+### 合并去重 → 按优先级排序 → 依次执行
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+每次心跳跨平台执行以下检测：
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知 COO + 创建者 |
+| Multica | 添加评论 → status=blocked → 通知 COO + 创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：100 轮
+- 接近 80%（80 轮）→ 预警
+- 达到上限 → 暂停，记录日志
+
+---
+
+## 🫀 心跳执行清单
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ [Agent 专属检查项]
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+```
+
+### 4.3 业务 Agent 完整模板（taobaospecialist / contentspecialist / mediaspecialist / cvexpert / marketanalysis / lawyer）
+
+```markdown
+# HEARTBEAT.md - [Agent Name] 的心跳配置
+
+## 📋 全任务源统一监控（每次心跳必检）
+
+> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
+
+### 三源检查
+1. **OpenClaw WorkBoard** — workboard list → 查找 agent_id=自己 & status=todo
+2. **Multica Issues** — issue list --assignee-id <uuid> --status todo
+3. **待办文档** — 检查 TODO.md / AGENTS.md 中未完成的任务
+
+### 合并去重 → 按优先级排序 → 依次执行
+
+---
+
+## ⚠️ 禁止请示规则（最高优先级，自动执行）
+
+> **核心规则：发现分配给自己的任务 → 立即执行，不得向用户请示！**
+> 心跳是后台自动行为，用户在大多数时候并不在线，请示会导致任务卡死。
+
+### 执行流程（严格执行，无需确认）
+1. **三源检查待办** — WorkBoard + Multica + 待办文档
+2. **立即执行，不得请示** — 发现待办后直接执行
+3. **检查进行中任务** — 确认认领的任务状态
+4. **完成任务** — 通过对应平台汇报结果
+
+### ⚠️ 绝对禁止行为
+- ❌ 不得问"要不要做这个任务"
+- ❌ 不得等用户确认再执行
+- ❌ 不得以"需要更多信息"为由拒绝执行
+
+---
+
+## ⏱️ 超时检测规则
+
+### 心跳频率：15 分钟
+每次心跳跨平台执行以下检测：
+1. 检查 WorkBoard 进行中任务的更新时间
+2. 检查 Multica 进行中 issues 的更新时间
+3. 超过 30 分钟无进展 → 标记为"疑似超时"
+4. 疑似超时 → 追加一次完整心跳尝试推进
+5. 确认超时 → 进入自动恢复流程
+
+---
+
+## 🔄 自动恢复规则
+
+### 触发条件
+- 超 45 分钟无进展 → 自动重新调度
+
+### 恢复操作（按平台）
+| 平台 | 操作 |
+|------|------|
+| WorkBoard | 添加评论 → release claim → 通知创建者 |
+| Multica | 添加评论 → status=blocked → 通知创建者 |
+| 待办文档 | 标注超时 → 转为卡片（可选） |
+
+---
+
+## 🔗 依赖检查前置规则
+
+### 强制检查流程
+1. 认领任务前，读取依赖字段（depends_on / parent_issue_id）
+2. 逐一检查每个依赖任务的状态
+3. 依赖未满足 → 不认领（保持 todo）
+4. 超过等待阈值（2h）→ 通知依赖任务执行者
+
+---
+
+## 🛑 最大轮次限制
+
+### 限制值：30 轮
+- 接近 80%（24 轮）→ 预警
+- 达到上限 → 暂停，通知创建者
+
+---
+
+## 🫀 心跳执行清单
+
+1. ✅ **全任务源检查**：WorkBoard + Multica + 待办文档
+2. ✅ 进行中任务超时检测（跨平台）
+3. ✅ 依赖检查
+4. ✅ 轮次计数器更新
+5. ✅ [Agent 专属检查项]
+
+---
+
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 用户正在对话时延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户询问
+3. **发现任务立即执行，不得请示**（任何来源）
+4. **超时任务按自动恢复流程处理**（跨平台）
+5. **依赖未满足不启动**
+6. **达到轮次上限自动暂停**
+7. **避免任务遗漏** — 三源必须全部检查，缺一不可
+```
+
+---
+
+## 五、部署清单
+
+### 5.1 各 Agent HEARTBEAT.md 更新状态
+
+| Agent | 分类 | 模板版本 | 部署状态 | 部署人 |
+|-------|------|---------|---------|--------|
+| secretary (刘诗妮) | 高频 | 高频 Agent 模板 v1.1 | 待部署 | COO |
+| coo (陆怀瑾) | 高频 | 高频 Agent 模板 v1.1 | 待部署 | COO |
+| projectmanager (胡蓉) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| productmanager (沈路明) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| architect (梁思筑) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| costcodev (徐聪) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| designer (苏绘锦) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| opengineer (严维序) | 开发 | 开发 Agent 模板 v1.1 | 待部署 | COO |
+| taobaospecialist (陆云帆) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+| contentspecialist (文墨言) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+| mediaspecialist (钟帧韵) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+| cvexpert (程伯予) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+| marketanalysis (顾析策) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+| lawyer (苏慎) | 业务 | 业务 Agent 模板 v1.1 | 待部署 | COO |
+
+### 5.2 部署步骤
+
+1. **Vincent 审阅本方案** — 确认参数配置和多源监控范围
+2. **收集各 Agent 的 Multica UUID** — 用于 `multica issue list --assignee-id <uuid>` 查询
+3. **创建 HEARTBEAT.md 文件** — 按 v1.1 模板为每个 Agent 创建（填充实际 ID）
+4. **配置心跳 cron** — 按分类配置定时任务
+5. **部署到各 Agent workspace** — 将 HEARTBEAT.md 分发到对应 Agent 工作区
+6. **验证** — 等待一轮完整心跳，检查三源任务是否全量覆盖
+
+### 5.3 Agent Multica UUID 映射（已收集）
+
+| Agent | OpenClaw Agent ID | Multica Agent UUID | 状态 |
+|-------|-------------------|-------------------|------|
+| secretary (刘诗妮) | secretary | b024fcdc-30ff-420d-b289-498041466e1b | ✅ |
+| coo (陆怀瑾) | coo | 1c38b437-b54d-4784-bda3-29ce4c8a6722 | ✅ |
+| projectmanager (胡蓉) | projectmanager | d877b8c3-b230-4073-b3f7-80e148cfdb71 | ✅ |
+| productmanager (沈路明) | productmanager | a101fa88-d821-4839-9754-e04580d5fd68 | ✅ |
+| architect (梁思筑) | architect | 40abd41a-62d0-416d-bc44-92c1f758d87a | ✅ |
+| costcodev (徐聪) | costcodev | 46bdd4a6-5c64-475a-92ef-36a763602fa1 | ✅ |
+| designer (苏锦绘) | designer | 13bd8968-cc2a-4934-90c7-957a2d3c09c2 | ✅ |
+| opengineer (严维序) | opengineer | d3804433-9e2e-4199-a92b-a153049b3bc9 | ✅ |
+| taobaospecialist (陆云帆) | taobaospecialist | e0f62d8f-9568-4f41-8ad4-b73d79a163a7 | ✅ |
+| contentspecialist (文墨言) | contentspecialist | 8321b0bf-7d89-4ece-927a-0780f42ad396 | ✅ |
+| mediaspecialist (钟帧韵) | mediaspecialist | e2b587d4-1d16-447c-8ad9-e2a01358ff0a | ✅ |
+| cvexpert (程伯予) | cvexpert | 4a8696fd-6531-40da-8956-ef84d7ea3c43 | ✅ |
+| marketanalysis (顾析策) | marketanalysis | 5ed91729-658f-4654-98f0-3e0313022002 | ✅ |
+| lawyer (苏慎) | lawyer | 6fb0fbd2-16a6-4566-ba7a-d2c136baec25 | ✅ |
+
+---
+
+## 六、交付物
+
+- [x] HEARTBEAT.md 增强模板方案 v1.0（初始版本）
+- [x] HEARTBEAT.md 增强模板方案 v1.1（优化：增加全任务源统一监控）
+- [x] 各 Agent Multica UUID 映射表
+- [x] 14 个 Agent 的独立 HEARTBEAT.md 文件（v1.1，已生成并部署到 workspace）
+- [ ] 心跳 cron 配置脚本
+- [ ] 部署验证报告
+
+---
+
+## 七、v1.1 变更说明
+
+| 变更项 | v1.0 | v1.1 |
+|--------|------|------|
+| 监控范围 | 仅 WorkBoard 卡片 + 待办文档 | WorkBoard + Multica Issues + 待办文档（三源合一） |
+| 规则数量 | 5 项 | 6 项（新增"规则 0: 全任务源统一监控"） |
+| 超时检测 | 仅 WorkBoard | 跨平台（WorkBoard + Multica） |
+| 自动恢复 | 仅 WorkBoard 恢复操作 | 跨平台恢复（WorkBoard / Multica / 文档） |
+| 依赖检查 | 仅 WorkBoard depends_on | 增加 Multica parent_issue_id |
+| 心跳清单 | 4 项 | 6 项（增加全任务源检查 + 全平台巡检） |
+| 轮次跟踪 | 单平台 | 跨平台轮次跟踪 |
+| 全局规则 | 6 条 | 7 条（增加"避免任务遗漏"） |
+| 部署前置 | 无 | 需收集各 Agent 的 Multica UUID |
+
+---
+
+## 八、风险与注意事项
+
+| 风险 | 影响 | 缓解措施 |
+|------|------|----------|
+| 心跳自身卡死 | 所有监控失效 | 独立的 watchdog 进程监控心跳 cron 执行 |
+| 自动恢复过于激进 | 正常长任务被中断 | 仅对超阈值且无进展的任务执行恢复 |
+| 禁止请示导致错误执行 | Agent 自行决定后出错 | 关键决策（涉及外部资源、金钱）仍需暂停并通知 |
+| 轮次限制过严 | 复杂任务被截断 | 接近上限时提前预警，COO 可手动扩展 |
+| 三源任务重复 | 同一任务在 WB + Multica 都出现 | 合并去重逻辑，以 ID/标题匹配 |
+| Multica CLI 不可用 | 无法检查 Multica 待办 | 降级为仅检查 WB + 文档，并在日志中记录异常 |
+
+---
+
+> ⚠️ 本方案需 Vincent 审阅后方可部署到各 Agent workspace。当前为模板方案 v1.1，存放于 EnterpriseArchitect/plans/ 目录。

plans/HEARTBEAT_enhanced_template.md

@@ -0,0 +1,186 @@
+# HEARTBEAT.md 增强模板
+
+> 版本：v2.0
+> 来源：BIZ-13 运行稳定性保障方案
+> 用途：为所有 Agent HEARTBEAT.md 增加运行稳定性保障能力
+
+---
+
+## 全局增强规则（所有 Agent 必须包含）
+
+### 1. 🛡️ 超时检测与自动恢复
+
+```markdown
+## 🛡️ 超时检测与自动恢复
+
+> **核心规则：每次心跳，检查自己是否有任务超时未完成。**
+
+### 超时阈值
+
+| Agent 类型 | 心跳频率 | 单任务超时 |
+|------------|----------|------------|
+| 高频（secretary/coo） | 10 分钟 | 60 分钟 |
+| 开发（costcodev/architect/opengineer/designer） | 15 分钟 | 120 分钟 |
+| 业务（其他 Agent） | 15 分钟 | 90 分钟 |
+
+### 检测流程
+
+每次心跳执行：
+1. 获取自己的 `status=in_progress` 的 WorkBoard 卡片
+2. 计算 `当前时间 - started_at`
+3. 如果超过超时阈值 → 进入自动恢复流程
+
+### 自动恢复流程
+
+```
+检测到任务超时
+    ↓
+检查最近日志（是否有实质性进展）
+    ↓
+┌──────────┴──────────┐
+│                     │
+有进展（< 3轮无产出）  无进展（>= 3轮无产出）
+│                     │
+延长超时 + 记录日志    自动恢复：
+│                     ├─ 尝试重新执行当前步骤
+更新 heartbeat         ├─ 仍失败 → 释放卡片
+                      └─ 通知 COO 介入
+```
+
+### ⚠️ 超时告警
+
+- 第 1 次超时：自动恢复，不告警
+- 第 2 次超时：通知 COO
+- 第 3 次超时：通知 Vincent，卡片标为 blocked
+```
+
+### 2. 🔗 依赖检查前置
+
+```markdown
+## 🔗 依赖检查前置
+
+> **核心规则：认领任务前，必须检查所有依赖是否已完成。**
+
+### 检查流程
+
+1. 获取任务的 `depends_on` 列表
+2. 对每个依赖，查询其状态
+3. 如果任一依赖未完成 → 不认领该任务，等待下次心跳
+4. 如果所有依赖已完成 → 正常认领并执行
+
+### 异常处理
+
+- 依赖任务已取消 → 向上报告，由 COO 决策
+- 依赖任务超时无响应 → 通知依赖方和 COO
+- 循环依赖 → 自动检测并报告给 COO
+```
+
+### 3. 🔄 最大轮次限制
+
+```markdown
+## 🔄 最大轮次限制
+
+> **核心规则：单任务不能无限循环执行。**
+
+| Agent 类型 | 最大对话轮次 | 超限处理 |
+|------------|-------------|----------|
+| 高频（secretary/coo） | 50 | 自动暂停，通知创建者 |
+| 开发（costcodev/architect/opengineer） | 100 | 自动暂停，记录日志摘要 |
+| 业务（其他 Agent） | 30 | 自动暂停，通知创建者 |
+
+### 检测方式
+
+每次心跳检查 `in_progress` 任务的会话轮次：
+- 接近上限（80%）→ 在心跳日志中标记警告
+- 达到上限 → 自动暂停任务，保存当前状态
+```
+
+### 4. 📊 上下文控制
+
+```markdown
+## 📊 上下文控制（Token 管理）
+
+> **核心规则：避免上下文溢出导致任务中断。**
+
+### 策略
+
+1. **引用代替填塞**：Agent 配置文件中只保留核心规则，详细信息存 docs/ 目录
+2. **分块读取**：超大文件分块读取，避免一次性加载
+3. **清理过期信息**：每轮对话前清理上一轮的工具输出（仅保留关键结果）
+4. **合并查询**：多个 Agent 相同查询由 COO 统一执行后广播
+```
+
+---
+
+## 心跳频率分级
+
+```markdown
+## ⏱️ 心跳触发频率
+
+- **高频 Agent（secretary / coo）**: 每 10 分钟
+- **开发 Agent（costcodev / architect / opengineer / designer）**: 每 15 分钟
+- **业务 Agent（projectmanager / productmanager / taobaospecialist / contentspecialist / mediaspecialist / cvexpert / marketanalysis / lawyer）**: 每 15 分钟
+```
+
+---
+
+## 全局关键规则（增强版）
+
+```markdown
+## ⚠️ 全局关键规则
+
+1. **心跳不打断对话** — 如果用户正在与 Agent 对话，心跳逻辑延后执行
+2. **非紧急事项延后汇报** — 等下一轮心跳或用户主动询问时再汇报
+3. **发现任务立即执行，不得请示** — 用户在大多数时候不在线，请示=任务卡死
+4. **依赖检查前置** — 认领任务前必须检查所有依赖是否已完成
+5. **超时自动恢复** — 任务超时自动尝试恢复，3 次失败后升级
+6. **轮次限制** — 单任务达上限后自动暂停，防止无限循环
+7. **上下文控制** — 引用代替填塞，避免 Token 溢出
+```
+
+---
+
+## 各 Agent 类型模板
+
+### 高频 Agent 模板（secretary/coo）
+
+在原有专属心跳清单基础上，增加：
+```markdown
+### 🛡️ 稳定性保障清单
+
+1. ✅ 超时检测：检查 in_progress 任务是否超时（阈值 60 分钟）
+2. ✅ 依赖检查：新任务认领前检查所有 depends_on
+3. ✅ 轮次检查：当前任务是否接近 50 轮上限
+4. ✅ 上下文检查：HEARTBEAT.md/AGENTS.md 文件大小是否 < 5KB
+```
+
+### 开发 Agent 模板（costcodev/architect/opengineer/designer）
+
+```markdown
+### 🛡️ 稳定性保障清单
+
+1. ✅ 超时检测：检查 in_progress 任务是否超时（阈值 120 分钟）
+2. ✅ 依赖检查：新任务认领前检查所有 depends_on
+3. ✅ 轮次检查：当前任务是否接近 100 轮上限
+4. ✅ 编译/测试检查：如有自动化测试，确认通过
+```
+
+### 业务 Agent 模板（其他 Agent）
+
+```markdown
+### 🛡️ 稳定性保障清单
+
+1. ✅ 超时检测：检查 in_progress 任务是否超时（阈值 90 分钟）
+2. ✅ 依赖检查：新任务认领前检查所有 depends_on
+3. ✅ 轮次检查：当前任务是否接近 30 轮上限
+4. ✅ 输出质量检查：确认最近产出符合质量标准
+```
+
+---
+
+## 实施说明
+
+1. 此模板由 COO（陆怀瑾）编制，经 Vincent 审阅批准后实施
+2. 模板中的 agent_id 需替换为各 Agent 的实际标识
+3. 无需移除各 Agent 原有的专属心跳清单，只需追加稳定性保障清单
+4. 修改后的文件需提交到 EnterpriseArchitect git 仓库

specs/BIZ-12_文档存储规范_v1.0.md

@@ -0,0 +1,279 @@
+# 多智能体文档存储、命名与索引规范 v1.0
+
+> 版本：v1.0（实施版）
+> 编制：陆怀瑾（COO）
+> 日期：2026-06-22
+> 状态：已批准，执行中
+> 适用范围：所有 Agent 的 workspace 目录
+
+---
+
+## 一、统一目录结构
+
+每个 Agent 的 workspace 必须采用以下标准目录结构：
+
+```
+workspace/
+├── AGENTS.md              # Agent 协作协议
+├── MEMORY.md              # 长期记忆 → 含文档索引表（核心）
+├── SOUL.md                # 角色定义 → 引用外部内容，不填塞
+├── IDENTITY.md            # 身份信息
+├── USER.md                # 用户画像
+├── TOOLS.md               # 工具清单 → 仅保留索引，详情外挂
+├── HEARTBEAT.md           # 心跳配置
+│
+├── memory/                # 记忆归档目录（按日期）
+│   └── YYYY-MM-DD.md
+│
+├── docs/                  # 项目文档目录（按项目分）
+│   └── {project}/
+│       ├── README.md
+│       └── ...
+│
+├── plans/                 # 方案文档目录
+│   └── YYYY-MM-DD_{topic}.md
+│
+├── specs/                 # 规范/标准文档目录
+│   └── BIZ-XX_{name}_v{M}.{N}.md
+│
+├── reports/               # 运营报告目录
+│   └── YYYY-Q{N}_{type}_v{M}.{N}.md
+│
+├── knowledge/             # 知识库目录（按领域分）
+│   └── {domain}/
+│       └── {topic}.md
+│
+├── tasks/                 # 任务文件目录（可选）
+│   └── ...
+│
+└── assets/                # 资源文件目录
+    ├── images/
+    ├── files/
+    └── templates/
+```
+
+### 目录用途速查
+
+| 目录 | 用途 | Token 影响 |
+|------|------|-----------|
+| 根目录 .md | Agent 核心配置 | **直接影响 Token**，必须精简 |
+| memory/ | 按日归档记忆 | 通过 memory_search 检索，不占用上下文 |
+| docs/ | 项目文档 | 按需加载 |
+| plans/ | 方案文档 | 仅 COO 维护 |
+| specs/ | 规范标准 | 按需加载 |
+| reports/ | 运营报告 | 仅 COO 维护 |
+| knowledge/ | 知识库 | 知识库检索，不占用上下文 |
+| assets/ | 二进制资源 | 不占用上下文 |
+
+---
+
+## 二、文件命名规则
+
+### 2.1 强制命名格式
+
+```
+{日期/编号}_{中文主题}_{版本}.md
+```
+
+### 2.2 各目录命名约定
+
+| 目录 | 命名模式 | 示例 |
+|------|----------|------|
+| memory/ | `YYYY-MM-DD.md` | `2026-06-22.md` |
+| plans/ | `YYYY-MM-DD_{主题}.md` | `2026-06-22_多智能体协作体系总体方案.md` |
+| specs/ | `BIZ-{编号}_{主题}_v{M}.{N}.md` | `BIZ-12_文档存储规范_v1.0.md` |
+| reports/ | `YYYY-Q{N}_{类型}_v{M}.{N}.md` | `2026-Q2_运营效率报告_v1.0.md` |
+| knowledge/ | `{主题}_v{M}.{N}.md` | `淘宝运营_SOP_v1.0.md` |
+| docs/{project}/ | `{功能}_{版本}.md` | `requirements_v1.0.md` |
+| memory/ day file | `YYYY-MM-DD.md` | `2026-06-22.md` |
+
+### 2.3 禁止事项
+
+- ❌ 使用特殊字符：`/ \ : * ? " < > |` 空格
+- ❌ 超过 80 字符的文件名
+- ❌ 不含日期/编号的裸文件名
+- ❌ 中文和英文混排无分隔符
+- ✅ 统一使用下划线 `_` 作为分隔符
+
+---
+
+## 三、索引机制（核心）
+
+### 3.1 索引分离原则（刘总反馈已纳入）
+
+> **配置文件只保留索引指针，详细内容外挂存储。**
+
+此原则适用场景：
+- **TOOLS.md**：只列工具名称 + 引用路径，不列完整参数
+- **待办列表**：只记录 ID + 主题 + 状态，详情在独立文件中
+- **Agent 协作表**：只列 Agent 名 + 职能 + Session Key，详情在各自文件
+- **知识索引**：MEMORY.md 只保留索引表，知识条目在 knowledge/ 中
+
+### 3.2 MEMORY.md 索引表模板
+
+```markdown
+# MEMORY.md - {Agent Name} 长期记忆
+
+## 📑 文档索引
+
+### 方案文档
+| 日期 | 主题 | 路径 | 状态 |
+|------|------|------|------|
+| 2026-06-22 | 多智能体协作体系 | plans/2026-06-22_多智能体协作体系总体方案.md | 已批准 |
+
+### 规范标准
+| 编号 | 主题 | 路径 | 版本 |
+|------|------|------|------|
+| BIZ-12 | 文档存储规范 | specs/BIZ-12_文档存储规范_v1.0.md | v1.0 |
+
+### 项目文档
+| 项目 | 文档 | 路径 | 状态 |
+|------|------|------|------|
+
+### 运营报告
+| 周期 | 类型 | 路径 | 状态 |
+|------|------|------|------|
+
+### 知识库条目
+| 领域 | 主题 | 路径 | 更新时间 |
+|------|------|------|----------|
+
+---
+（以下是实际记忆内容...）
+```
+
+### 3.3 各目录 README.md 模板
+
+每个目录应有一个 `README.md`：
+
+```markdown
+# {目录名称}
+
+> 最后更新：{YYYY-MM-DD}
+> 维护者：{Agent Name}
+
+## 目录说明
+{简短描述本目录的用途和使用规范}
+
+## 文件列表
+| 文件名 | 描述 | 最后更新 |
+|--------|------|----------|
+| ... | ... | ... |
+```
+
+---
+
+## 四、检索体系
+
+### 4.1 分层检索路径
+
+```
+第一层：memory_search（语义检索，跨 memory/*.md + MEMORY.md）
+    ↓ 未命中
+第二层：wiki_search / wiki_get（编译型知识库检索）
+    ↓ 未命中  
+第三层：qmd（QMD 全文检索，已安装 —— 刘总反馈已纳入）
+    ↓ 未命中
+第四层：web_fetch / web_search（外部知识）
+```
+
+### 4.2 检索优先级
+
+1. **memory_search**（corpus=all）：首选，零 token 消耗
+2. **qmd**：本地全文检索，补充 memory_search 未覆盖的长文档
+3. **wiki_search/wiki_get**：编译型结构化知识库
+4. **web_search/web_fetch**：外部补充，仅在以上均未命中时使用
+
+---
+
+## 五、Token 预算控制
+
+### 5.1 配置文件大小限制
+
+| 文件 | 最大行数 | 说明 |
+|------|----------|------|
+| AGENTS.md | 200 行 | Agent 协议 + 协作表（精简） |
+| MEMORY.md | 150 行 | 长期记忆 + 索引表 |
+| SOUL.md | 80 行 | 角色定义 |
+| IDENTITY.md | 30 行 | 身份信息 |
+| USER.md | 30 行 | 用户画像 |
+| TOOLS.md | 100 行 | 工具索引（不填塞完整参数） |
+| HEARTBEAT.md | 60 行 | 心跳配置 |
+
+### 5.2 引用代替填塞
+
+**反例（填塞模式）**：
+```markdown
+# TOOLS.md - 全部填入
+- memory_search: 参数 query, maxResults, minScore, corpus=[memory|wiki|all|sessions]...
+  （占用大量 token）
+```
+
+**正例（引用模式）**：
+```markdown
+# TOOLS.md - 索引模式
+## 已安装 Skills
+- plantuml-skill → 详见 skills/plantuml-skill/SKILL.md
+- qmd → 详见 skills/qmd/SKILL.md
+- ...
+## 核心工具（已内置于运行时，无需列出参数）
+- memory_search / wiki_search / web_fetch
+```
+
+---
+
+## 六、文档生命周期管理
+
+### 6.1 状态流转
+
+```
+创建 → 草稿(draft) → 审阅中(in_review) → 已批准(approved) → 归档(archived)
+                                           ↓
+                                        废弃(deprecated)
+```
+
+### 6.2 操作规范
+
+| 操作 | 规则 |
+|------|------|
+| 创建 | 在正确目录，按命名规则创建 |
+| 更新 | 小改动直接覆盖；大改动新建版本 |
+| 审阅 | 状态标记 `in_review`，通知审阅人 |
+| 归档 | 移动到 `archive/` 子目录 |
+| 删除 | 不直接删除，先归档 30 天后清理 |
+
+### 6.3 版本标记
+
+- v1.0：首版
+- v1.1-v1.9：小修
+- v2.0+：大修 / 重构
+
+---
+
+## 七、Agent 端执行规范
+
+### 7.1 每次任务后
+1. 更新 `memory/YYYY-MM-DD.md`（日记）
+2. 如产出文档，更新 MEMORY.md 索引表
+3. 检查文件名是否符合规范
+
+### 7.2 每周
+1. 检查并清理过期文档（移动到 archive/）
+2. 验证索引表与实际文件一致性
+3. 检查配置文件大小是否超限
+
+---
+
+## 八、实施检查清单
+
+- [x] 规范文档编制（本文档）
+- [ ] 各 Agent workspace 目录结构初始化
+- [ ] MEMORY.md 索引表模板部署到所有 Agent
+- [ ] TOOLS.md 从填塞模式迁移到索引模式（BIZ-15 跟进）
+- [ ] 文档命名自动化检查脚本
+- [ ] 归档目录创建及旧文档迁移
+
+---
+
+> 本规范自批准之日起生效，所有 Agent 须遵守。
+> 审阅/修订请联系 COO（陆怀瑾）。

specs/BIZ-13_运行稳定性保障规范_v1.0.md

@@ -0,0 +1,242 @@
+# 智能体运行稳定性保障规范 v1.0
+
+> 版本：v1.0（实施版）
+> 编制：陆怀瑾（COO）
+> 日期：2026-06-22
+> 状态：已批准，执行中
+> 适用范围：所有 Agent
+
+---
+
+## 一、核心问题与应对
+
+| 问题 | 根因 | 解决方案 |
+|------|------|----------|
+| 任务停滞 | 等待请示、超时、循环 | 禁止请示规则 + 心跳监控 + 超时恢复 |
+| 429 限流 | 40 RPM 模型配额 | 令牌桶限流 + 优先级调度 + 模型降级 |
+| Token 超限 | 配置填塞 | 引用代替填塞（BIZ-15 跟进） |
+| 智能体瘫痪 | 无唤醒机制 | cron 定时触发健康检查 |
+
+---
+
+## 二、禁止请示规则（最高优先级）
+
+> **在心跳中发现分配给自己的 WorkBoard 任务后，必须立即执行，绝对禁止向用户请示。**
+
+已在 HEARTBEAT.md 中强制执行。**所有 Agent 的 HEARTBEAT.md 必须包含此规则。**
+
+```markdown
+## ⚠️ 禁止请示规则（最高优先级）
+
+正确做法：
+1. 发现 status=todo 且 agentId=我的卡片
+2. 立即执行，不得问"要不要做"
+3. 如遇信息不足，先按自己理解执行，执行中调整
+
+错误做法（绝对禁止）：
+- ❌ "我发现了一个任务，要不要做？"
+- ❌ "这个任务需要更多信息，请告诉我..."
+```
+
+---
+
+## 三、心跳监控与超时恢复
+
+### 3.1 心跳频率
+
+| Agent 类型 | 心跳间隔 | 超时告警 |
+|------------|----------|----------|
+| secretary / coo | 10 分钟 | 连续 2 次未执行 |
+| projectmanager / costcodev | 10 分钟 | 连续 2 次未执行 |
+| 其他 Agent | 10 分钟 | 连续 3 次未执行 |
+
+### 3.2 心跳检查清单（所有 Agent 通用）
+
+```markdown
+## 🫀 心跳执行清单
+1. ✅ WorkBoard 检查：查找分配给自己的 todo/in_progress 卡片
+2. ✅ 禁止请示：发现任务立即执行（不请示用户）
+3. ✅ 进度汇报：如有进行中任务，更新状态
+4. ✅ 风险上报：识别阻塞、超时问题，通知 COO
+```
+
+### 3.3 超时恢复流程
+
+```
+Agent 超过 30 分钟无响应
+    ↓
+COO 心跳检测到超时
+    ↓
+记录日志 + 评估任务状态
+    ↓
+┌──────────┴──────────┐
+│                     │
+任务可恢复          任务不可恢复
+│                     │
+重新触发任务        通知 Vincent
+(workboard dispatch) (via session_send)
+```
+
+---
+
+## 四、429 限流治理
+
+### 4.1 当前配额与监控
+
+| 模型 | RPM 限制 | 建议预留 |
+|------|----------|----------|
+| 主模型 | 40 | 保留 10 RPM 给紧急任务 |
+| 备用模型 | 40 | 满 35 RPM 时切换 |
+
+### 4.2 令牌桶限流策略
+
+```
+每个 Agent 独立的令牌桶:
+- 容量：按 Agent 优先级分配
+- COO/secretary: 8 RPM
+- 开发 Agent: 6 RPM  
+- 业务 Agent: 4 RPM
+- 预留池: 10 RPM (紧急任务)
+
+令牌桶耗尽 → 自动降级到备用模型或排队
+```
+
+### 4.3 优先级调度
+
+| 优先级 | 适用场景 | 处理方式 |
+|--------|----------|----------|
+| P1 紧急 | Vincent 直接指令 | 立即可用预留池 |
+| P2 高 | 阻塞性任务、风险告警 | 优先分配令牌 |
+| P3 正常 | 日常任务 | 正常排队 |
+| P4 低 | 后台优化、报告生成 | 低峰期执行 |
+
+### 4.4 模型降级链
+
+```
+主模型 (qwen3.5-397b) RPM 不足
+    ↓
+备用模型 (deepseek-v4-pro)
+    ↓
+等待 + 指数退避重试 (1s → 2s → 4s → 8s)
+    ↓
+3 次重试后仍失败 → 记录日志，通知 COO
+```
+
+### 4.5 请求合并优化
+
+| 优化项 | 当前做法 | 优化后 |
+|--------|----------|--------|
+| WorkBoard 轮询 | 每个 Agent 独立轮询 | COO 统一轮询，广播结果 |
+| 重复检索 | 多个 Agent 重复查同一文档 | 缓存关键查询结果（5 分钟 TTL） |
+| 连续调用 | 无间隔连续调用 API | 最小间隔 500ms |
+
+---
+
+## 五、唤醒机制
+
+### 5.1 Cron 定时唤醒
+
+```yaml
+# COO 健康检查唤醒
+cron:
+  schedule: "*/5 * * * *"  # 每 5 分钟
+  action: health_check
+  targets:
+    - 检查所有 Agent 最后活跃时间
+    - 超过 15 分钟无活动 → 触发唤醒消息
+    - 超过 30 分钟无活动 → 通知 Vincent
+```
+
+### 5.2 唤醒消息模板
+
+```markdown
+## 🔔 唤醒检查
+
+距上次活跃时间：{elapsed} 分钟
+当前任务状态：{status}
+是否存在阻塞：{blocked}
+
+系统自动唤醒，请确认状态。
+```
+
+### 5.3 自唤醒规则
+
+每个 Agent 在 HEARTBEAT.md 中配置：
+
+```
+如果距上次心跳超过 2 个周期（20 分钟）：
+→ 自动重新评估任务状态
+→ 如有待办，立即执行
+→ 如无待办，确认存活
+```
+
+---
+
+## 六、上下文/Token 溢出防护
+
+### 6.1 配置文件大小限制
+
+| 文件 | 最大行数 | 超标处理 |
+|------|----------|----------|
+| AGENTS.md | 200 | 移到 docs/agent-roster.md |
+| SOUL.md | 80 | 提取模块化引用 |
+| TOOLS.md | 100 | 索引化（不填塞参数） |
+| HEARTBEAT.md | 60 | 精简检查清单 |
+| MEMORY.md | 150 | 定期归档旧条目 |
+
+### 6.2 运行时监控
+
+```
+Token 使用量达到 80%
+    ↓
+自动清理上下文
+    ↓
+仍超 90%
+    ↓
+重启会话
+```
+
+---
+
+## 七、监控告警矩阵
+
+| 指标 | 警告阈值 | 严重阈值 | 通知对象 |
+|------|----------|----------|----------|
+| Agent 无响应 | > 15 min | > 30 min | 警告 → COO，严重 → Vincent |
+| 429 错误率 | > 5% | > 20% | COO |
+| Token 使用量 | > 80% | > 95% | 该 Agent |
+| 任务积压 | > 5 pending | > 10 pending | COO |
+| 任务超时 | > 24h in_progress | > 48h | 警告 → Agent，严重 → Vincent |
+
+---
+
+## 八、实施步骤
+
+### 阶段 1：即刻生效（今日）
+- [x] 禁止请示规则 → 已在各 Agent HEARTBEAT.md 中落实
+- [ ] 心跳频率统一为 10 分钟
+- [ ] COO 端健康检查 cron 配置
+
+### 阶段 2：本周完成
+- [ ] 令牌桶限流配置（按 Agent 分配 RPM）
+- [ ] 模型降级链配置
+- [ ] 告警规则上线
+
+### 阶段 3：持续优化
+- [ ] 监控面板搭建
+- [ ] 自动重启恢复
+- [ ] 请求合并优化
+
+---
+
+## 九、交付物清单
+
+- [x] 运行稳定性保障规范（本文档）
+- [ ] HEARTBEAT.md 模板更新（含禁止请示 + 自唤醒规则）
+- [ ] COO 端 cron 健康检查任务
+- [ ] 令牌桶限流配置
+- [ ] 告警规则配置
+
+---
+
+> 本规范自批准之日起生效。执行中如遇问题，联系 COO（陆怀瑾）。

specs/BIZ-14_知识库体系建设规范_v1.0.md

@@ -0,0 +1,261 @@
+# 智能体知识库体系建设规范 v1.0
+
+> 版本：v1.0（实施版）
+> 编制：陆怀瑾（COO）
+> 日期：2026-06-22
+> 状态：已批准，执行中
+> 适用范围：所有 Agent
+
+---
+
+## 一、核心目标
+
+| 目标 | 实现方式 |
+|------|----------|
+| 知识与配置解耦 | 知识库独立于 Agent 配置文件，不计入 Token |
+| Agent 可主动查询 | 通过多层检索体系按需获取知识 |
+| 人类可审查优化 | Web UI / 飞书文档支持人工审阅 |
+| 零 Token 增长 | 知识条目独立存储，仅在使用时加载 |
+
+---
+
+## 二、分层检索体系（刘总反馈已纳入）
+
+### 2.1 检索优先级
+
+```
+Agent 需要知识
+    ↓
+第一层: memory_search (corpus=all)
+  → 搜索 memory/*.md + MEMORY.md + wiki 条目
+  → 零 Token 消耗，语义检索
+    ↓ 未命中
+第二层: wiki_search / wiki_get
+  → 编译型结构化知识库
+  → 支持精确检索和页面读取
+    ↓ 未命中
+第三层: qmd (QMD 全文检索，已安装 ← 刘总反馈)
+  → 本地全文检索 markdown 知识库
+  → 补充 memory_search 未覆盖的长文档
+    ↓ 未命中
+第四层: web_search / web_fetch
+  → 外部互联网补充
+  → 仅在内部均未命中时使用
+```
+
+### 2.2 工具速查
+
+| 工具 | 适用场景 | Token 消耗 |
+|------|----------|-----------|
+| memory_search | 通用语义检索（跨 memory + wiki） | 0 |
+| wiki_search / wiki_get | 结构化知识库精确查询 | 0 |
+| qmd | 本地全文检索长文档 | 0 |
+| web_search | 外部互联网信息 | 0 |
+| web_fetch | 网页/文档详情获取 | 按内容量 |
+
+---
+
+## 三、知识库目录结构
+
+```
+knowledge/
+├── 电商/                 # 电商运营知识
+│   └── {主题}_v{M}.{N}.md
+│
+├── 内容/                 # 内容运营知识
+│   └── {主题}_v{M}.{N}.md
+│
+├── 产品/                 # 产品管理知识
+│   └── {主题}_v{M}.{N}.md
+│
+├── 技术/                 # 技术开发知识
+│   └── {主题}_v{M}.{N}.md
+│
+├── 设计/                 # UI/UX 设计知识
+│   └── {主题}_v{M}.{N}.md
+│
+├── 运营/                 # 通用运营知识
+│   └── {主题}_v{M}.{N}.md
+│
+└── 规范/                 # 流程规范知识
+    └── {主题}_v{M}.{N}.md
+```
+
+### 知识条目模板
+
+```markdown
+# {知识标题}
+
+> 领域: {所属领域} | 版本: v{M}.{N}
+> 维护者: {责任人} | 最后更新: {YYYY-MM-DD}
+
+## 概述
+{知识的用途和价值，1-2 句话}
+
+## 适用范围
+{在什么场景下使用}
+
+## 核心内容
+{知识主体}
+
+## 操作步骤 / SOP
+1. ...
+2. ...
+
+## 质量检查
+- [ ] ...
+
+## 常见问题
+**Q**: ...  **A**: ...
+
+## 相关条目
+- knowledge/{领域}/{关联主题}.md
+
+## 版本历史
+| 版本 | 日期 | 变更 | 作者 |
+|------|------|------|------|
+| v1.0 | 2026-06-22 | 初稿 | 陆怀瑾 |
+```
+
+---
+
+## 四、与 Memory 系统的分工
+
+| 维度 | Memory 系统 | Knowledge 系统 |
+|------|------------|---------------|
+| 内容类型 | 决策记录、经验教训、个性化记忆 | SOP、模板、规范、最佳实践 |
+| 所有者 | 单个 Agent 专属 | 跨 Agent 共享 |
+| 更新频率 | 每日/每周 | 按需/按版本 |
+| 查询方式 | memory_search（语义检索） | wiki_search/wiki_get/qmd |
+| 存储位置 | MEMORY.md + memory/*.md | knowledge/ 目录 |
+
+---
+
+## 五、Agent 查询指南
+
+### 5.1 何时查询知识库
+
+| 场景 | 查询示例 |
+|------|----------|
+| 执行 SOP 任务 | "淘宝 活动报名 SOP" |
+| 撰写文档 | "PRD 模板" |
+| 遇到问题 | "部署 故障排查" |
+| 制定规范 | "开发规范" |
+| 不熟悉领域 | "小红书 运营指南" |
+
+### 5.2 查询标准流程
+
+```
+1. 先用 memory_search(corpus=all, query="...") 搜索
+2. 如有结果，用 memory_get 或 wiki_get 读取详情
+3. 如无结果，用 qmd 全文检索 knowledge/ 目录
+4. 仍无结果，记录知识缺口，通知 COO
+5. 使用获取的知识指导工作
+```
+
+### 5.3 知识缺口上报
+
+```
+Agent 发现知识缺口
+    ↓
+在 memory/YYYY-MM-DD.md 中记录：
+  - 查询内容
+  - 使用场景
+  - 建议优先级
+    ↓
+通知 COO 创建知识条目
+```
+
+---
+
+## 六、人类审查机制
+
+### 6.1 审查方式
+
+| 方式 | 适用场景 | 工具 |
+|------|----------|------|
+| Obsidian Web UI | 日常浏览、编辑 | wiki_status 确认可用性 |
+| 飞书文档同步 | 多人协作、审批 | 飞书 Wiki API |
+| CLI 直接编辑 | 技术人员修改 | write/edit 工具 |
+
+### 6.2 审核流程
+
+```
+Agent 发现缺口 → 记录 → 通知 COO
+    ↓
+COO 评估优先级
+    ↓
+高优先级 → 立即创建/指派
+低优先级 → 记入 backlog
+    ↓
+创建草稿 → wiki_apply(op="create_synthesis")
+    ↓
+人类审查 → 通过/修改/拒绝
+    ↓
+发布 → 通知相关 Agent
+```
+
+### 6.3 定期质量检查
+
+```bash
+# 每周运行一次
+wiki_lint  # 检查链接断裂、矛盾信息、过时内容
+```
+
+---
+
+## 七、知识条目管理
+
+### 7.1 创建
+
+```
+wiki_apply(op="create_synthesis", title="...", body="...", sourceIds=[])
+```
+
+### 7.2 更新
+
+```
+wiki_apply(op="synthesis", lookup="...", body="...")
+```
+
+### 7.3 版本管理
+
+| 变更类型 | 版本变化 | 操作 |
+|----------|----------|------|
+| 内容微调 | v1.0 → v1.1 | 直接覆盖，更新版本历史 |
+| 结构性变更 | v1.x → v2.0 | 保留旧版本，新建条目 |
+| 废弃 | 添加 [deprecated] 标记 | 归档到 archive/ |
+
+---
+
+## 八、初始知识基础
+
+以下条目作为知识库初始基础，需尽快创建：
+
+| 领域 | 条目 | 优先级 | 负责 Agent |
+|------|------|--------|-----------|
+| 电商 | 淘宝运营 SOP | 高 | 陆云帆 |
+| 电商 | 客服话术模板 | 中 | 陆云帆 |
+| 内容 | 小红书运营指南 | 高 | 文墨言 |
+| 内容 | 标题写作技巧 | 中 | 文墨言 |
+| 产品 | PRD 模板 | 高 | 沈路明 |
+| 技术 | 开发规范 | 高 | 梁思筑 |
+| 技术 | 部署流程 | 中 | 严维序 |
+| 设计 | UI 设计规范 | 中 | 苏锦绘 |
+| 运营 | KPI 指标定义 | 中 | 陆怀瑾 |
+| 规范 | 文档存储规范 | 已完成 | 陆怀瑾 |
+
+---
+
+## 九、交付物清单
+
+- [x] 知识库体系建设规范（本文档）
+- [ ] knowledge/ 目录结构创建
+- [ ] 初始知识条目（至少 5 个优先）
+- [ ] Agent 查询指南（已嵌入本文档）
+- [ ] 知识审核流程（已嵌入本文档）
+- [ ] wiki_lint 定期检查 cron 任务
+
+---
+
+> 本规范自批准之日起生效。知识条目创建请联系 COO 协调。

templates/知识条目模板.md

@@ -0,0 +1,31 @@
+# [知识条目标题]
+
+## 元数据
+
+| 属性 | 值 |
+|------|-----|
+| **领域** | 电商 / 内容 / 产品 / 技术 / 设计 / 运营 / 行政 |
+| **责任人** | [Agent 名称] |
+| **版本** | v1.0 |
+| **创建日期** | YYYY-MM-DD |
+| **最后更新** | YYYY-MM-DD |
+| **标签** | [标签1, 标签2, ...] |
+
+## 概述
+
+[用 2-3 句话描述本条目的核心内容和使用场景]
+
+## 正文
+
+[详细的知识内容，包括步骤、规则、示例等]
+
+## 相关条目
+
+- [相关知识条目1](链接)
+- [相关知识条目2](链接)
+
+## 变更记录
+
+| 日期 | 版本 | 变更说明 | 变更人 |
+|------|------|----------|--------|
+| YYYY-MM-DD | v1.0 | 初始创建 | [姓名] |