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

BIZ-24 HEARTBEAT.md 增强模板方案

Phase 1 of BIZ-13 运行稳定性保障方案 版本：v1.1（2026-06-22 优化：增加全任务源统一监控） 编制：陆怀瑾（COO） 日期：2026-06-22 状态：待审阅 关联：BIZ-13 运行稳定性保障方案

---

一、目标

为所有 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 只监控其中一部分会导致工作任务被永久遗漏。

规则文本：

## 📋 全任务源统一监控（每次心跳必检）

> **核心原则：发现任何来源的任务都必须立即执行，不得遗漏。**
> 你的工作任务可能存在于三个地方：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 发现任务后向用户请示"要不要做"，用户不在线时任务卡死数小时。

规则文本：

## ⚠️ 禁止请示规则（最高优先级）

你在心跳中发现任何来源的任务后，必须立即执行，绝对禁止向用户请示！

原因：
- 用户在大多数时候并不在线，请示会导致任务卡死数小时
- 心跳是后台自动行为，用户没有义务实时响应你的请示
- 你的职责是"主动完成交付"，而不是"等待指令"

正确做法：
1. 发现任何来源的待办任务（WorkBoard / Multica / 待办文档）
2. 立即认领并执行
3. 如遇信息不足，先按自己的最佳理解执行，执行中再调整
4. 任务完成后，通过对应平台汇报结果

错误做法（绝对禁止）：
- ❌ "我发现了一个任务，要不要做？"
- ❌ "这个任务需要更多信息，请告诉我..."
- ❌ "任务已完成，请确认是否符合要求"

规则 2：超时检测规则

问题：Agent 执行到某一步后卡住，长时间无输出，无任何监告。

规则文本：

高频 Agent 版：

## ⏱️ 超时检测规则

### 心跳频率：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 版（差异部分）：

### 心跳频率：15 分钟
每次心跳执行以下检测：
1. 检查所有平台进行中任务的最新更新时间（WorkBoard + Multica）
2. 如超过 30 分钟无进展 → 标记为"疑似超时"

业务 Agent 版（差异部分）：

### 心跳频率：15 分钟
每次心跳执行以下检测：
1. 检查所有平台进行中任务的最新更新时间（WorkBoard + Multica）
2. 如超过 30 分钟无进展 → 标记为"疑似超时"

规则 3：自动恢复规则

问题：检测到无进展后没有自动恢复手段，任务永久停滞。

规则文本：

## 🔄 自动恢复规则

### 恢复流程

检测到超时（跨平台无进展超阈值） ↓ 步骤 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 时间，且可能导致循环等待。

规则文本：

## 🔗 依赖检查前置规则

### 任务启动前强制检查
每次认领或启动任务前，必须执行依赖检查：

**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 版：

## 🛑 最大轮次限制

### 限制值：50 轮
单次任务执行不得超过 50 个对话轮次。

### 检测机制
- 每次心跳记录已消耗轮次
- 接近上限（80%）时发出预警
- 达到上限时自动暂停

### 超限处理

达到最大轮次 ↓

1. 暂停任务执行
2. 记录已完成的步骤和未完成的部分
3. 通知 COO，附当前进度
4. COO 决定：重新分配 / 拆分任务 / 人工介入

### 跨平台轮次跟踪
- **WorkBoard**：通过 workboard_heartbeat 的 note 记录轮次
- **Multica**：通过 issue comment 记录轮次进度
- **待办文档**：在工作日志中记录

### 计数器维护
\```bash
# 每次心跳更新轮次计数
# 轮次数据存储在任务 metadata 或 comment 中
\```

开发 Agent 版（差异部分）：

### 限制值：100 轮
单次任务执行不得超过 100 个对话轮次。

业务 Agent 版（差异部分）：

### 限制值：30 轮
单次任务执行不得超过 30 个对话轮次。

---

四、HEARTBEAT.md 完整增强模板

4.1 高频 Agent 完整模板（secretary / coo）

# 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）

# 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）

# 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	用于 issue list --assignee-id
secretary	secretary	待收集	待收集
coo	coo	1c38b437-b54d-4784-bda3-29ce4c8a6722	✅
projectmanager	projectmanager	待收集	待收集
productmanager	productmanager	待收集	待收集
architect	architect	待收集	待收集
costcodev	costcodev	待收集	待收集
designer	designer	待收集	待收集
opengineer	opengineer	待收集	待收集
taobaospecialist	taobaospecialist	待收集	待收集
contentspecialist	contentspecialist	待收集	待收集
mediaspecialist	mediaspecialist	待收集	待收集
cvexpert	cvexpert	待收集	待收集
marketanalysis	marketanalysis	待收集	待收集
lawyer	lawyer	待收集	待收集

---

六、交付物

• HEARTBEAT.md 增强模板方案 v1.0（初始版本）
• HEARTBEAT.md 增强模板方案 v1.1（优化：增加全任务源统一监控）
• 各 Agent Multica UUID 映射表
• 14 个 Agent 的独立 HEARTBEAT.md 文件（v1.1，待审阅后生成）
• 心跳 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/ 目录。