vincent
1561c2eaeb
变更： - 新增「规则 0: 全任务源统一监控」（规则从 5 项扩展为 6 项） - 三源监控脚本：WorkBoard、Multica issues、待办文档 - 超时检测扩展为跨平台（WorkBoard + Multica） - 自动恢复增加 Multica 恢复流程 - 依赖检查增加 Multica parent_issue_id - 心跳清单从 4 项扩展为 6 项 - 全局规则从 6 条扩展为 7 条 - 新增 Agent Multica UUID 映射表 - COO 专属全平台积压巡检脚本 Addresses Vincent's review feedback: 智能体监控应覆盖 Multica issues，避免工作遗漏 Co-authored-by: multica-agent <github@multica.ai>
835 lines
28 KiB
Markdown
835 lines
28 KiB
Markdown
# 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 | 用于 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 | 待收集 | 待收集 |
|
||
|
||
---
|
||
|
||
## 六、交付物
|
||
|
||
- [x] HEARTBEAT.md 增强模板方案 v1.0（初始版本）
|
||
- [x] 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/ 目录。 |