fix(BIZ-26): 限流范围收窄到 NVIDIA 网关

- 新增网关识别逻辑：只识别 nvidia / nvidiavx18088980513 为限流目标 - volcengine-plan、siliconflow、deepseek 等非 NVIDIA 网关默认不进入令牌桶 - RequestScheduler 增加 gateway/model 参数与 _should_rate_limit 判断 - 未知网关默认不限流，避免误伤其他通道 - 补充网关范围测试与使用文档说明 Co-authored-by: multica-agent <github@multica.ai>
feat(BIZ-26): 实现 API 请求优先级队列 + 令牌桶限流器
2026-06-23 16:12:02 +08:00 · 2026-06-23 07:09:39 +08:00
46 changed files with 1511 additions and 8039 deletions
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,235 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,235 +0,0 @@
 # 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）专用配置
@@ -1,234 +0,0 @@
 # 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）专用配置
@@ -1,130 +0,0 @@
 # 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 — 角色特定查询指引
@@ -0,0 +1,401 @@
 # BIZ-26 限流器使用文档
 > 模块：`scripts/rate_limiter.py`  
 > 测试：`scripts/test_rate_limiter.py`  
 > 实现日期：2026-06-23  
 > 作者：徐聪（costcodev）
 ---
 ## 一、功能概述
 本模块实现了 BIZ-13 运行稳定性保障方案中的 API 限流优化功能：
 1. **NVIDIA 网关专用令牌桶限流器**：40 RPM 上限，防止触发 NVIDIA 网关 API 429 错误
 2. **四级优先级队列**：紧急 > 高 > 正常 > 低
 3. **智能降级策略**：高优先级等待，低优先级切备用模型
 4. **缓存管理器**：按数据类型设置不同 TTL
 5. **COO 统一轮询**：减少重复请求
 6. **指数退避重试**：自动处理临时失败
 ---
 ## 二、适用范围（已按要求收窄）
 **令牌桶限流器只对 NVIDIA 网关 API 生效。**
 识别规则：
 - `nvidia`、`nvidia-gateway`、`nvidiavx18088980513/...` → 进入 40 RPM 令牌桶
 - `volcengine-plan/...`、`siliconflow/...`、`deepseek/...` → 不进入令牌桶，不受该限流器影响
 - 未知网关默认不限制，避免误伤非 NVIDIA 通道
 调用方应显式传入 `gateway` 或 `model`，例如：
 ```python
 # 走 NVIDIA 网关：限流
 scheduler.submit(payload=data, gateway="nvidia", priority=Priority.NORMAL, callback=handler)
 scheduler.submit(payload=data, model="nvidiavx18088980513/deepseek-ai/deepseek-v4-pro", callback=handler)
 # 走其他网关：不限流
 scheduler.submit(payload=data, model="volcengine-plan/ark-code-latest", callback=handler)
 scheduler.submit(payload=data, model="siliconflow/Qwen/Qwen3", callback=handler)
 scheduler.submit(payload=data, model="deepseek/deepseek-chat", callback=handler)
 ```
 ---
 ## 三、快速开始
 ### 2.1 基本用法
 ```python
 from scripts.rate_limiter import RequestScheduler, Priority
 # 创建调度器（40 RPM）
 scheduler = RequestScheduler(rate=40/60, capacity=40)
 scheduler.start()
 # 提交请求
 def my_callback(data):
    # 实际 API 调用逻辑
    return process_data(data)
 request_id = scheduler.submit(
    payload={"task": "process_workboard"},
    priority=Priority.NORMAL,
    callback=my_callback
 )
 # 等待完成后关闭
 time.sleep(5)
 scheduler.stop()
 ```
 ### 2.2 优先级示例
 ```python
 # 紧急任务（Vincent 直接下达）
 scheduler.submit(payload=data, priority=Priority.URGENT, callback=handler)
 # 阻塞性任务（依赖下游完成）
 scheduler.submit(payload=data, priority=Priority.HIGH, callback=handler)
 # 常规任务
 scheduler.submit(payload=data, priority=Priority.NORMAL, callback=handler)
 # 后台优化任务
 scheduler.submit(payload=data, priority=Priority.LOW, callback=handler)
 ```
 ### 2.3 缓存使用
 ```python
 from scripts.rate_limiter import CacheManager
 cache = CacheManager()
 # 缓存 WorkBoard 结果（TTL 5 分钟）
 cache.set("workboard", "todo_list", result_data)
 # 读取缓存
 cached = cache.get("workboard", "todo_list")
 if cached is None:
    # 缓存未命中，重新查询
    result = query_workboard()
    cache.set("workboard", "todo_list", result)
 # 查看缓存统计
 stats = cache.get_stats()
 print(f"缓存条目：{stats['total_entries']}")
 ```
 ---
 ## 四、API 参考
 ### 3.1 TokenBucket（令牌桶）
 ```python
 bucket = TokenBucket(rate=40/60, capacity=40)
 # 尝试消费令牌（立即返回）
 if bucket.consume():
    send_request()
 else:
    # 令牌不足，等待或降级
    pass
 # 等待令牌（阻塞直到获取或超时）
 got_token = bucket.wait_for_token(timeout=5.0)
 # 查看状态
 status = bucket.get_status()
 # 返回：{"tokens": 35.5, "capacity": 40, "rate_per_minute": 40.0, ...}
 ```
 ### 3.2 RequestScheduler（请求调度器）
 ```python
 scheduler = RequestScheduler(
    rate=40/60,          # 令牌生成速率（个/秒）
    capacity=40,         # 桶容量
    enable_cache=True    # 启用缓存
 )
 # 启动工作线程
 scheduler.start()
 # 提交异步请求
 request_id = scheduler.submit(
    payload={"task": "data"},
    priority=Priority.NORMAL,
    callback=my_handler,
    fallback_model="deepseek-v4-pro"
 )
 # 提交同步请求（阻塞直到完成）
 result = scheduler.submit_sync(
    payload={"task": "data"},
    priority=Priority.URGENT,
    timeout=10.0
 )
 # 查看状态
 status = scheduler.get_status()
 # 停止调度器
 scheduler.stop()
 ```
 ### 3.3 CacheManager（缓存管理器）
 ```python
 cache = CacheManager()
 # 设置缓存（自动 TTL）
 cache.set("workboard", query_key, value)  # 5 分钟
 cache.set("config", "agent_list", agents)  # 1 小时
 cache.set("knowledge", "api_docs", docs)  # 1 天
 # 自定义 TTL
 cache.set("custom", key, value, ttl=600)  # 10 分钟
 # 读取缓存
 value = cache.get("workboard", query_key)
 # 删除缓存
 cache.delete("workboard", query_key)
 # 清理过期缓存
 cleaned = cache.clear_expired()
 # 查看统计
 stats = cache.get_stats()
 ```
 ### 3.4 retry_with_backoff（重试装饰器）
 ```python
 from rate_limiter import retry_with_backoff
@retry_with_backoff(
    max_retries=3,        # 最多重试 3 次
    base_delay=1.0,       # 基础延迟 1 秒
    exponential_base=2,   # 指数底数
    jitter=True,          # 添加随机抖动
    exceptions=(RateLimitError, NetworkError)
 )
 def call_api():
    return requests.get(url)
 ```
 ### 3.5 CoordinatedPoller（统一轮询器）
 ```python
 from rate_limiter import CoordinatedPoller
 # 创建轮询器（15 分钟轮询一次）
 poller = CoordinatedPoller(scheduler, poll_interval=15*60)
 # 订阅轮询结果
 def on_new_data(result):
    broadcast_to_agents(result)
 poller.subscribe(on_new_data)
 # 启动轮询
 poller.start()
 # 停止轮询
 poller.stop()
 ```
 ---
 ## 五、缓存策略
 | 数据类型 | TTL | 说明 |
 |----------|-----|------|
 | `workboard` | 5 分钟 | WorkBoard 卡片状态，高频变化 |
 | `config` | 1 小时 | Agent 配置、技能列表，低频变化 |
 | `knowledge` | 1 天 | 知识库内容，基本不变 |
 | `user` | 1 天 | 用户信息、权限配置 |
 ---
 ## 六、降级策略
 ### 5.1 令牌不足时的处理
 | 优先级 | 策略 |
 |--------|------|
 | URGENT (1) | 无限等待，直到获取令牌 |
 | HIGH (2) | 无限等待，直到获取令牌 |
 | NORMAL (3) | 等待 2 秒，失败则放回队列稍后重试 |
 | LOW (4) | 等待 2 秒，失败则丢弃或切换到备用模型 |
 ### 5.2 模型降级链
 ```
 主模型 (qwen3.5-397b)
    ↓ RPM 不足
 备用模型 (deepseek-v4-pro)
    ↓ RPM 不足
 本地模型 或 等待
 ```
 ---
 ## 七、监控与调试
 ### 6.1 查看调度器状态
 ```python
 status = scheduler.get_status()
 print(f"队列大小：{status['queue_size']}")
 print(f"令牌数：{status['token_bucket']['tokens']}")
 print(f"已完成：{status['stats']['completed_requests']}")
 print(f"失败：{status['stats']['failed_requests']}")
 print(f"降级：{status['stats']['fallback_requests']}")
 ```
 ### 6.2 查看缓存统计
 ```python
 stats = cache.get_stats()
 print(f"总条目：{stats['total_entries']}")
 print(f"有效条目：{stats['valid_entries']}")
 print(f"过期条目：{stats['expired_entries']}")
 print(f"按类别：{stats['by_category']}")
 ```
 ---
 ## 八、测试
 运行测试套件：
 ```bash
 cd /home/vincent/.openclaw/workspace/costcodev/EnterpriseArchitect
 python3 scripts/test_rate_limiter.py
 ```
 测试覆盖：
 - ✅ 令牌桶限流
 - ✅ 缓存管理
 - ✅ 优先级队列
 - ✅ 重试装饰器
 - ✅ 统一轮询器
 - ✅ 压力测试（50 请求）
 ---
 ## 九、集成示例
 ### 8.1 与 Multica CLI 集成
 ```python
 import subprocess
 import json
 from rate_limiter import RequestScheduler, Priority, CacheManager
 scheduler = RequestScheduler(rate=40/60, capacity=40)
 cache = CacheManager()
 scheduler.start()
 def query_workboard():
    """查询 WorkBoard（带缓存）"""
    # 先查缓存
    cached = cache.get("workboard", "all_cards")
    if cached:
        return cached
    # 缓存未命中，调用 CLI
    result = subprocess.run(
        ["multica", "workboard", "list", "--json"],
        capture_output=True,
        text=True
    )
    data = json.loads(result.stdout)
    # 更新缓存
    cache.set("workboard", "all_cards", data)
    return data
 # 提交查询请求
 request_id = scheduler.submit(
    payload="query_workboard",
    priority=Priority.NORMAL,
    callback=lambda _: query_workboard()
 )
 ```
 ### 8.2 Agent 心跳集成
 ```python
 # 在 Heartbeat 中统一使用限流器
 def heartbeat_check():
    # 通过调度器提交所有检查任务
    scheduler.submit(
        payload="check_workboard",
        priority=Priority.HIGH,
        callback=check_workboard
    )
    scheduler.submit(
        payload="check_multica",
        priority=Priority.HIGH,
        callback=check_multica_issues
    )
    scheduler.submit(
        payload="update_memory",
        priority=Priority.LOW,
        callback=update_memory_log
    )
 ```
 ---
 ## 十、注意事项
 1. **令牌速率配置**：根据实际 API 限制调整 `rate` 参数
 2. **缓存 TTL**：根据数据变化频率调整，避免过期数据
 3. **工作线程**：记得调用 `start()` 和 `stop()` 管理生命周期
 4. **异常处理**：回调函数中的异常会被捕获并记录，不会中断工作线程
 5. **线程安全**：所有组件都是线程安全的，可在多线程环境使用
 ---
 ## 十一、TODO
 - [ ] 接入实际的 Multica CLI 调用
 - [ ] 添加 Prometheus 监控指标导出
 - [ ] 支持动态调整限流参数
 - [ ] 添加请求日志持久化
 - [ ] 支持多个模型池的自动切换
 ---
 > 文档版本：v1.0  
 > 最后更新：2026-06-23  
 > 维护者：徐聪（costcodev）
@@ -1,71 +0,0 @@
 # OpenClaw NVIDIA 网关切换至 Metapi — 配置修改指南
 > 交付人：严维序（opengineer） | 交付日期：2026-07-03 | 关联Issue：BIZ-76
 ## 当前状态
 你的 `openclaw.json` 中有 **12 个 NVIDIA 独立提供者**，每个直连 `https://integrate.api.nvidia.com/v1`，使用各自的 `nvapi-*` API Key。
 Metapi 已部署在 http://192.168.1.99:4000，内部聚合了全部 12 个 NVIDIA 账号，通过代理令牌 `sk-bizwings-metapi-proxy` 对外提供统一的 `/v1` 端点，自动负载均衡。
 ## 方案 A：逐项修改（保留 12 个提供者结构）
 对每个 NVIDIA 提供者做两处替换：
 ### 1. 修改 `baseUrl`
 ```
 "baseUrl": "https://integrate.api.nvidia.com/v1"
 → "baseUrl": "http://192.168.1.99:4000/v1"
 ```
 ### 2. 修改 `apiKey`
 ```
 "apiKey": "nvapi-xxx..."
 → "apiKey": "sk-bizwings-metapi-proxy"
 ```
 ## 方案 B：合并为单个提供者（推荐，精简配置）
 将 12 个 NVIDIA 提供者合并为 1 个：
 ```json
 {
  "id": "nvidia-metapi",
  "name": "NVIDIA via Metapi",
  "kind": "openai",
  "baseUrl": "http://192.168.1.99:4000/v1",
  "apiKey": "sk-bizwings-metapi-proxy",
  "models": {
    "deepseek-ai/deepseek-v4-flash": {},
    "deepseek-ai/deepseek-v4-pro": {},
    "z-ai/glm-5.1": {},
    "z-ai/glm-5.2": {},
    "qwen/qwen3.5-397b-a17b": {},
    "nvidia/llama-3.3-nemotron-super-49b-v1": {},
    "nvidia/mississippi": {}
  }
 }
 ```
 Metapi 已部署信息：
 - 访问地址：http://192.168.1.99:4000
 - 管理员令牌：`bizwings-metapi-admin`
 - 代理令牌：`sk-bizwings-metapi-proxy`
 - 端口：4000
 ## 12 个 NVIDIA 账户清单
 | # | 账号 | 状态 |
 |---|------|------|
 | 1 | NVIDIA-NIM-default | ✅ active |
 | 2 | NVIDIA-NIM-98053 | ✅ active |
 | 3 | NVIDIA-NIM-liuweicheng84 | ✅ active |
 | 4 | NVIDIA-NIM-vx18088980513 | ✅ active |
 | 5 | NVIDIA-NIM-vx64391942 | ✅ active |
 | 6 | NVIDIA-NIM-cgtest1 | ✅ active |
 | 7 | NVIDIA-NIM-cgtest2 | ✅ active |
 | 8 | NVIDIA-NIM-cgtest3 | ✅ active |
 | 9 | NVIDIA-NIM-15876517651 | ✅ active |
 | 10 | NVIDIA-NIM-19584586741 | ✅ active |
 | 11 | NVIDIA-NIM-18874954146 | ✅ active |
 | 12 | NVIDIA-NIM-2405483110 | ✅ active |
@@ -1,156 +0,0 @@
 # 知识查询最佳实践
 > **版本**: 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` — 集成方案总览
@@ -12,10 +12,8 @@
 | [产品/](产品/) | PRD、需求分析 | 沈路明 (productmanager) | — |
 | [技术/](技术/) | 开发规范、代码审查 | 徐聪 (costcodev) | — |
 | [设计/](设计/) | UI设计、品牌规范 | 苏绘锦 (designer) | — |
 | [运维/](运维/) | 部署流程、故障排查、服务器运维 | 严维序 (opengineer) | 3 |
 | [运营/](运营/) | 活动策划、数据分析 | 陆怀瑾 (coo) | — |
 | [行政/](行政/) | 合同、报销流程 | 刘诗妮 (secretary) | — |
 | [规范/](规范/) | 运维标准、安全基线、合规要求 | 严维序 (opengineer) | — |
 ## 知识条目格式
@@ -5,9 +5,7 @@
 ## 知识范围
-涵盖开发规范、代码审查、架构设计、技术选型等技术团队核心知识。
+涵盖开发规范、代码审查、架构设计、部署运维、技术选型等技术团队知识。
 > ⚠️ 部署运维知识已迁移至 [运维/](../运维/) 领域。
 ## 条目清单
@@ -1,25 +0,0 @@
 # 规范领域知识
 **责任人**：严维序（opengineer）
 **审核人**：陆怀瑾（coo）
 ## 知识范围
 涵盖运维规范、安全标准、合规要求等规范类知识条目，支撑团队标准化运作。
 ## 条目清单
 | 文件名 | 说明 | 状态 |
 |--------|------|------|
 | [服务器运维标准_v1.0.md](../运维/服务器运维标准_v1.0.md) | 服务器巡检、监控、备份运维标准 | 见运维域 |
 ## 待建设
 - 数据库运维标准
 - 安全审计基线
 - 数据合规处理流程
 ---
 > 维护者：严维序（opengineer）
 > 最后更新：2026-06-24
@@ -1,27 +0,0 @@
 # 运维领域知识
 **责任人**：严维序（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
@@ -1,178 +0,0 @@
 # 双色球系统部署文档
 ## 部署信息
 | 项目 | 值 |
 |------|-----|
 | 项目名称 | 双色球自动化系统 |
 | 部署时间 | 2026-06-29 |
 | 部署人员 | 严维序 (opengineer) |
 | 服务地址 | http://192.168.1.99:5000 |
 | 宿主服务器 | Ubuntu-OpenClaw (192.168.1.99) |
 ---
 ## 一、项目结构
 ```
 /home/vincent/Studio/lottoData/
 ├── venv/                       # Python 虚拟环境
 ├── web_executor.py             # Flask Web 服务 (监听 0.0.0.0:5000)
 ├── fetch_data.py               # 数据抓取脚本
 ├── lottery.py                  # 双色球号码生成器
 ├── web_console.html            # Web 控制台页面
 ├── LottoSpider/                # 爬虫模块
 ├── lottery/                    # 彩票模块
 ├── docs/                       # 文档
 ├── 双色球历史数据.xlsx          # 历史数据文件
 └── deploy/                     # 部署文件
    ├── DEPLOY.md               # 本文档
    ├── lotto-web.service       # systemd 服务文件
    ├── fetch_daily.sh          # 每日抓取脚本
    ├── cron.log                # Cron 执行日志
    └── fetch_YYYYMMDD.log      # 每日抓取详细日志
 ```
 ---
 ## 二、依赖清单
 | 包 | 版本 | 用途 |
 |----|------|------|
 | Flask | 3.1.3 | Web 服务框架 |
 | pandas | 3.0.4 | 数据处理 |
 | openpyxl | 3.1.5 | Excel 读写 |
 | requests | 2.34.2 | HTTP 请求 |
 | beautifulsoup4 | 4.15.0 | HTML 解析 |
 安装命令：
 ```bash
 python3 -m venv venv
 ./venv/bin/pip install flask pandas openpyxl requests beautifulsoup4
 ```
 ---
 ## 三、systemd 服务配置
 ### 服务文件
 `/etc/systemd/system/lotto-web.service`
 ```ini
 [Unit]
 Description=双色球数据抓取 Web 服务
 After=network.target
 [Service]
 Type=simple
 User=vincent
 WorkingDirectory=/home/vincent/Studio/lottoData
 ExecStart=/home/vincent/Studio/lottoData/venv/bin/python3 /home/vincent/Studio/lottoData/web_executor.py
 ExecStartPre=/home/vincent/Studio/lottoData/venv/bin/python3 -c "import flask; import pandas; import openpyxl; import requests; import bs4"
 Restart=on-failure
 RestartSec=5
 KillMode=control-group
 [Install]
 WantedBy=multi-user.target
 ```
 ### 管理命令
 ```bash
 # 安装/启用
 sudo cp deploy/lotto-web.service /etc/systemd/system/
 sudo systemctl daemon-reload
 sudo systemctl enable lotto-web
 sudo systemctl start lotto-web
 # 日常管理
 sudo systemctl status lotto-web    # 查看状态
 sudo systemctl restart lotto-web   # 重启
 sudo systemctl stop lotto-web      # 停止
 sudo journalctl -u lotto-web -f    # 查看实时日志
 ```
 ---
 ## 四、Cron 定时任务
 ### Cron 配置
 ```
 30 2 * * * /home/vincent/Studio/lottoData/deploy/fetch_daily.sh >> /home/vincent/Studio/lottoData/deploy/cron.log 2>&1
 ```
 每天凌晨 2:30 自动抓取双色球历史数据。
 ### 手动执行
 ```bash
 /home/vincent/Studio/lottoData/deploy/fetch_daily.sh
 # 或
 /home/vincent/Studio/lottoData/venv/bin/python3 /home/vincent/Studio/lottoData/fetch_data.py
 ```
 ---
 ## 五、Web 接口
 | 路径 | 方法 | 说明 |
 |------|------|------|
 | `/` | GET | Web 控制台页面 |
 | `/api/status` | GET | 获取执行状态 |
 | `/api/execute` | POST | 触发数据抓取 |
 ### 示例
 ```bash
 # 查看状态
 curl http://192.168.1.99:5000/api/status
 # 触发抓取
 curl -X POST http://192.168.1.99:5000/api/execute
 ```
 ---
 ## 六、验证清单
 - [x] 依赖安装完整 (Flask, pandas, openpyxl, requests, beautifulsoup4)
 - [x] systemd 服务运行正常 (active, enabled)
 - [x] Web 服务可访问 (http://192.168.1.99:5000, HTTP 200)
 - [x] API 接口正常 (/api/status, /api/execute)
 - [x] Cron 定时任务已配置 (每日 2:30 抓取)
 - [x] 手动抓取测试通过 (121 条记录保存成功)
 - [x] 开机自启已配置 (systemd enable)
 ---
 ## 七、回滚方案
 ```bash
 # 停止服务
 sudo systemctl stop lotto-web
 sudo systemctl disable lotto-web
 sudo rm /etc/systemd/system/lotto-web.service
 sudo systemctl daemon-reload
 # 移除 cron
 crontab -l | grep -v 'lottoData' | crontab -
 # 不影响数据文件和代码
 ```
 ---
 ## 八、监控要点
 1. **服务存活**：`systemctl status lotto-web` 确认 active
 2. **Web 可达**：`curl http://127.0.0.1:5000/api/status`
 3. **数据更新**：检查 `/home/vincent/Studio/lottoData/双色球历史数据.xlsx` 修改时间
 4. **Cron 日志**：检查 `/home/vincent/Studio/lottoData/deploy/cron.log`
 5. **磁盘空间**：Excel 文件约 250KB，可忽略
 ---
 > 部署人：严维序 (opengineer) | 2026-06-29
@@ -1,17 +0,0 @@
 #!/bin/bash
 # 双色球历史数据每日自动抓取
 # Cron: 0 2 * * * /home/vincent/Studio/lottoData/deploy/fetch_daily.sh >> /home/vincent/Studio/lottoData/deploy/cron.log 2>&1
 SCRIPT_DIR="/home/vincent/Studio/lottoData"
 VENV_PYTHON="${SCRIPT_DIR}/venv/bin/python3"
 FETCH_SCRIPT="${SCRIPT_DIR}/fetch_data.py"
 LOG_DIR="${SCRIPT_DIR}/deploy"
 LOG_FILE="${LOG_DIR}/fetch_$(date +%Y%m%d).log"
 mkdir -p "${LOG_DIR}"
 echo "=== $(date '+%Y-%m-%d %H:%M:%S') 开始执行双色球数据抓取 ==="
 "${VENV_PYTHON}" "${FETCH_SCRIPT}" >> "${LOG_FILE}" 2>&1
 RC=$?
 echo "=== $(date '+%Y-%m-%d %H:%M:%S') 执行完成, exit code=${RC} ==="
 exit ${RC}
@@ -1,16 +0,0 @@
 [Unit]
 Description=双色球数据抓取 Web 服务
 After=network.target
 [Service]
 Type=simple
 User=vincent
 WorkingDirectory=/home/vincent/Studio/lottoData
 ExecStart=/home/vincent/Studio/lottoData/venv/bin/python3 /home/vincent/Studio/lottoData/web_executor.py
 ExecStartPre=/home/vincent/Studio/lottoData/venv/bin/python3 -c "import flask; import pandas; import openpyxl; import requests; import bs4"
 Restart=on-failure
 RestartSec=5
 KillMode=control-group
 [Install]
 WantedBy=multi-user.target
@@ -1,5 +0,0 @@
 Flask==3.1.3
 pandas==3.0.4
 openpyxl==3.1.5
 requests==2.34.2
 beautifulsoup4==4.15.0
@@ -1,274 +0,0 @@
 # 故障排查手册
 ## 元数据
 | 属性 | 值 |
 |------|-----|
 | **领域** | 运维 |
 | **责任人** | 严维序（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 | 初始创建 | 严维序 |
@@ -1,177 +0,0 @@
 # 服务器运维标准
 ## 元数据
 | 属性 | 值 |
 |------|-----|
 | **领域** | 运维 |
 | **责任人** | 严维序（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 | 初始创建 | 严维序 |
@@ -1,202 +0,0 @@
 # 服务部署流程 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 | 初始创建 | 严维序 |
@@ -1,50 +0,0 @@
 # Alertmanager 配置
 # 告警通知路由到 Feishu
 global:
  resolve_timeout: 5m
 route:
  receiver: "default"
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    # 严重告警 → 通知 Vincent
    - receiver: "vincent-critical"
      match:
        severity: critical
      repeat_interval: 2h
      continue: true
    # 警告告警 → 通知 COO
    - receiver: "coo-warning"
      match:
        severity: warning
      repeat_interval: 4h
 receivers:
  - name: "default"
    webhook_configs:
      - url: "http://host.docker.internal:9094/webhook"
        send_resolved: true
  - name: "vincent-critical"
    webhook_configs:
      - url: "http://host.docker.internal:9094/webhook"
        send_resolved: true
  - name: "coo-warning"
    webhook_configs:
      - url: "http://host.docker.internal:9094/webhook"
        send_resolved: true
 # 抑制规则：严重告警自动抑制同源的警告
 inhibit_rules:
  - source_match:
      severity: critical
    target_match:
      severity: warning
    equal:
      - alertname
      - instance
@@ -1,288 +0,0 @@
 {
  "title": "OpenClaw Agent Health Dashboard",
  "uid": "agent-health",
  "version": 1,
  "tags": ["openclaw", "agent", "monitoring"],
  "timezone": "browser",
  "editable": true,
  "refresh": "30s",
  "panels": [
    {
      "title": "系统资源概览",
      "type": "row",
      "gridPos": {"h": 1, "w": 24, "x": 0, "y": 0}
    },
    {
      "id": 1,
      "title": "CPU 使用率",
      "type": "gauge",
      "gridPos": {"h": 8, "w": 6, "x": 0, "y": 1},
      "targets": [
        {
          "expr": "100 - (avg by(instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
          "legendFormat": "{{instance}}"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "showThresholdLabels": false,
        "showThresholdMarkers": true
      },
      "thresholds": [
        {"color": "green", "value": null},
        {"color": "yellow", "value": 70},
        {"color": "red", "value": 90}
      ]
    },
    {
      "id": 2,
      "title": "内存使用率",
      "type": "gauge",
      "gridPos": {"h": 8, "w": 6, "x": 6, "y": 1},
      "targets": [
        {
          "expr": "(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100",
          "legendFormat": "{{instance}}"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "showThresholdLabels": false,
        "showThresholdMarkers": true
      },
      "thresholds": [
        {"color": "green", "value": null},
        {"color": "yellow", "value": 80},
        {"color": "red", "value": 95}
      ]
    },
    {
      "id": 3,
      "title": "磁盘使用率",
      "type": "gauge",
      "gridPos": {"h": 8, "w": 6, "x": 12, "y": 1},
      "targets": [
        {
          "expr": "max by(instance) ((node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100)",
          "legendFormat": "{{instance}}"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "showThresholdLabels": false,
        "showThresholdMarkers": true
      },
      "thresholds": [
        {"color": "green", "value": null},
        {"color": "yellow", "value": 80},
        {"color": "red", "value": 95}
      ]
    },
    {
      "id": 4,
      "title": "系统负载",
      "type": "stat",
      "gridPos": {"h": 8, "w": 6, "x": 18, "y": 1},
      "targets": [
        {
          "expr": "node_load1",
          "legendFormat": "1min"
        },
        {
          "expr": "node_load5",
          "legendFormat": "5min"
        },
        {
          "expr": "node_load15",
          "legendFormat": "15min"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "colorMode": "background",
        "graphMode": "area",
        "justifyMode": "auto",
        "orientation": "horizontal",
        "textMode": "auto"
      }
    },
    {
      "title": "Agent 健康状态",
      "type": "row",
      "gridPos": {"h": 1, "w": 24, "x": 0, "y": 9}
    },
    {
      "id": 5,
      "title": "Agent 心跳状态",
      "type": "table",
      "gridPos": {"h": 8, "w": 12, "x": 0, "y": 10},
      "targets": [
        {
          "expr": "agent_heartbeat_status",
          "legendFormat": "{{agent_label}}"
        }
      ],
      "transformations": [
        {"id": "organize", "options": {"excludeByName": {}, "indexByName": {}, "renameByName": {"Value": "状态"}}}
      ],
      "fieldConfig": {
        "defaults": {
          "custom": {
            "align": "center",
            "displayMode": "color-background"
          },
          "mappings": [
            {"type": "value", "options": {"0": {"color": "red", "text": "❌ 超时"}, "1": {"color": "green", "text": "✅ 正常"}}}
          ],
          "thresholds": [{"color": "green", "value": null}]
        }
      }
    },
    {
      "id": 6,
      "title": "任务停滞时长",
      "type": "bargauge",
      "gridPos": {"h": 8, "w": 12, "x": 12, "y": 10},
      "targets": [
        {
          "expr": "agent_task_stagnation_seconds",
          "legendFormat": "{{agent_label}}"
        }
      ],
      "options": {
        "orientation": "horizontal",
        "displayMode": "gradient",
        "showUnfilled": true
      },
      "fieldConfig": {
        "defaults": {
          "unit": "s",
          "thresholds": [
            {"color": "green", "value": null},
            {"color": "yellow", "value": 3600},
            {"color": "red", "value": 14400}
          ]
        }
      }
    },
    {
      "id": 7,
      "title": "待办任务数",
      "type": "stat",
      "gridPos": {"h": 4, "w": 6, "x": 0, "y": 18},
      "targets": [
        {
          "expr": "agent_workboard_pending",
          "legendFormat": "待办任务"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "colorMode": "background",
        "graphMode": "area",
        "textMode": "auto"
      },
      "thresholds": [
        {"color": "green", "value": null},
        {"color": "yellow", "value": 5},
        {"color": "red", "value": 10}
      ]
    },
    {
      "id": 8,
      "title": "429 错误计数",
      "type": "stat",
      "gridPos": {"h": 4, "w": 6, "x": 6, "y": 18},
      "targets": [
        {
          "expr": "agent_429_error_rate",
          "legendFormat": "429 错误"
        }
      ],
      "options": {
        "reduceOptions": {"calcs": ["lastNotNull"]},
        "colorMode": "background",
        "graphMode": "area",
        "textMode": "auto"
      },
      "thresholds": [
        {"color": "green", "value": null},
        {"color": "yellow", "value": 10},
        {"color": "red", "value": 50}
      ]
    },
    {
      "id": 9,
      "title": "Prometheus 目标状态",
      "type": "table",
      "gridPos": {"h": 8, "w": 12, "x": 12, "y": 18},
      "targets": [
        {
          "expr": "up",
          "legendFormat": "{{job}} ({{instance}})"
        }
      ],
      "fieldConfig": {
        "defaults": {
          "custom": {"align": "center", "displayMode": "color-background"},
          "mappings": [
            {"type": "value", "options": {"0": {"color": "red", "text": "❌ Down"}, "1": {"color": "green", "text": "✅ Up"}}}
          ]
        }
      }
    },
    {
      "title": "告警状态",
      "type": "row",
      "gridPos": {"h": 1, "w": 24, "x": 0, "y": 26}
    },
    {
      "id": 10,
      "title": "活跃告警",
      "type": "table",
      "gridPos": {"h": 8, "w": 24, "x": 0, "y": 27},
      "targets": [
        {
          "expr": "ALERTS{alertstate=\"firing\"}",
          "legendFormat": "{{alertname}}"
        }
      ],
      "fieldConfig": {
        "defaults": {
          "custom": {"align": "left"},
          "mappings": [
            {"type": "value", "options": {"0": {"color": "green", "text": "已恢复"}, "1": {"color": "red", "text": "触发中"}}}
          ]
        }
      }
    }
  ],
  "schemaVersion": 38,
  "style": "dark",
  "tags": ["openclaw", "agent", "monitoring"],
  "templating": {
    "list": [
      {
        "name": "datasource",
        "type": "datasource",
        "query": "prometheus",
        "current": {"value": "Prometheus"}
      }
    ]
  },
  "annotations": {
    "list": [
      {
        "name": "告警事件",
        "type": "dashboard",
        "builtIn": 1,
        "datasource": {"type": "prometheus", "uid": "PBFA97CFB590B2093"},
        "enable": true,
        "hide": true,
        "iconColor": "rgba(255, 96, 96, 1)",
        "expr": "ALERTS",
        "step": "60s"
      }
    ]
  }
 }
@@ -1,12 +0,0 @@
 apiVersion: 1
 providers:
  - name: "Agent Health"
    orgId: 1
    folder: "OpenClaw"
    type: file
    disableDeletion: false
    editable: true
    updateIntervalSeconds: 10
    options:
      path: /etc/grafana/provisioning/dashboards
@@ -1,42 +0,0 @@
 global:
  scrape_interval: 15s
  evaluation_interval: 15s
 # Alertmanager 配置
 alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093
 # 规则文件
 rule_files:
  - "agent_alerts.yml"
 # 抓取配置
 scrape_configs:
  # Prometheus 自监控
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  # Node Exporter - 系统指标
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']
  # Agent Health Exporter - 自定义 Agent 监控指标
  - job_name: 'agent-health'
    scrape_interval: 30s
    static_configs:
      - targets: ['agent-exporter:9999']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
        replacement: 'openclaw-agents'
  # OpenClaw Gateway Metrics（待启用）
  # - job_name: 'openclaw-gateway'
  #   metrics_path: '/metrics'
  #   static_configs:
  #     - targets: ['host.docker.internal:18789']
@@ -1,92 +0,0 @@
 version: '3.8'
 services:
  prometheus:
    image: m.daocloud.io/docker.io/prom/prometheus:v2.52.0
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./config/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./config/agent_alerts.yml:/etc/prometheus/agent_alerts.yml
      - ./data/prometheus:/prometheus
    extra_hosts:
      - "host.docker.internal:host-gateway"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.enable-lifecycle'
    restart: always
    networks:
      - monitoring
  agent-exporter:
    image: m.daocloud.io/docker.io/python:3.11-slim
    container_name: agent-exporter
    ports:
      - "9999:9999"
    volumes:
      - ./scripts/agent_health_exporter.py:/app/exporter.py:ro
    command: python3 /app/exporter.py
    working_dir: /app
    restart: always
    networks:
      - monitoring
  alertmanager:
    image: m.daocloud.io/docker.io/prom/alertmanager:v0.27.0
    container_name: alertmanager
    ports:
      - "9093:9093"
    volumes:
      - ./config/alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - ./data/alertmanager:/alertmanager
    extra_hosts:
      - "host.docker.internal:host-gateway"
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
      - '--web.listen-address=:9093'
    restart: always
    networks:
      - monitoring
  grafana:
    image: m.daocloud.io/docker.io/grafana/grafana:11.0.0
    container_name: grafana
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=***
      - GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-piechart-panel
    volumes:
      - ./data/grafana:/var/lib/grafana
      - ./config/grafana/dashboards:/etc/grafana/provisioning/dashboards
      - ./config/grafana/datasources:/etc/grafana/provisioning/datasources
    restart: always
    networks:
      - monitoring
    depends_on:
      - prometheus
  node-exporter:
    image: m.daocloud.io/docker.io/prom/node-exporter:v1.8.2
    container_name: node-exporter
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($|/)'
    restart: always
    networks:
      - monitoring
 networks:
  monitoring:
    driver: bridge
@@ -1,180 +0,0 @@
 #!/usr/bin/env python3
 """
 OpenClaw Agent Health Exporter v2.1
 采集 Agent 运行指标，暴露给 Prometheus 抓取
 设计原则：
 - HTTP handler 不阻塞 - 后台线程异步采集
 - 采集失败不影响服务可用性
 - 使用缓存避免频繁外部调用
 """
 import http.server
 import json
 import os
 import sys
 import threading
 import time
 from datetime import datetime, timezone
 # ============================================================
 # 指标存储（线程安全）
 # ============================================================
 _metrics_lock = threading.Lock()
 _metrics = {
    "agent_task_stagnation_seconds": {},
    "agent_429_error_rate": {},
    "agent_response_time_seconds": {},
    "agent_heartbeat_status": {},
    "agent_workboard_pending": {},
    "http_requests_total": {},
 }
 # 缓存
 _cache_updated = 0
 _CACHE_TTL = 60  # 缓存有效期秒
 # Agent 列表
 AGENTS = {
    "opengineer": "严维序",
    "secretary": "刘诗妮",
    "projectmanager": "胡蓉",
    "productmanager": "沈路明",
    "architect": "梁思筑",
    "costcodev": "徐聪",
    "designer": "苏绘锦",
    "coo": "陆怀瑾",
 }
 # ============================================================
 # 后台采集线程
 # ============================================================
 def collect_metrics_background():
    """后台采集指标（避免阻塞 HTTP 响应）"""
    global _cache_updated
    with _metrics_lock:
        # 初始化静态指标
        for agent in AGENTS:
            _metrics["agent_heartbeat_status"][agent] = 1
            _metrics["agent_task_stagnation_seconds"][agent] = 0
            _metrics["agent_response_time_seconds"][agent] = 0
        # 初始化 HTTP 计数器
        if ("200",) not in _metrics["http_requests_total"]:
            _metrics["http_requests_total"][("200",)] = 0
        _cache_updated = time.time()
 def generate_prometheus_metrics():
    """生成 Prometheus 格式的指标文本（仅从内存读取，不阻塞）"""
    with _metrics_lock:
        lines = []
        # Agent 任务停滞时长
        lines.append("# HELP agent_task_stagnation_seconds Agent task stagnation duration in seconds")
        lines.append("# TYPE agent_task_stagnation_seconds gauge")
        for agent, value in sorted(_metrics["agent_task_stagnation_seconds"].items()):
            agent_label = AGENTS.get(agent, agent)
            lines.append(f'agent_task_stagnation_seconds{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
        # 429 错误率
        lines.append("# HELP agent_429_error_rate 429 error count")
        lines.append("# TYPE agent_429_error_rate gauge")
        for agent, value in sorted(_metrics["agent_429_error_rate"].items()):
            lines.append(f'agent_429_error_rate{{agent_name="{agent}"}} {value}')
        # Agent 响应延迟
        lines.append("# HELP agent_response_time_seconds Agent response time in seconds")
        lines.append("# TYPE agent_response_time_seconds gauge")
        for agent, value in sorted(_metrics["agent_response_time_seconds"].items()):
            agent_label = AGENTS.get(agent, agent)
            lines.append(f'agent_response_time_seconds{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
        # 心跳状态
        lines.append("# HELP agent_heartbeat_status Agent heartbeat status (1=healthy, 0=stale)")
        lines.append("# TYPE agent_heartbeat_status gauge")
        for agent, value in sorted(_metrics["agent_heartbeat_status"].items()):
            agent_label = AGENTS.get(agent, agent)
            lines.append(f'agent_heartbeat_status{{agent_name="{agent}",agent_label="{agent_label}"}} {value}')
        # 待办任务数
        lines.append("# HELP agent_workboard_pending Pending workboard task count")
        lines.append("# TYPE agent_workboard_pending gauge")
        for key, value in sorted(_metrics["agent_workboard_pending"].items()):
            lines.append(f'agent_workboard_pending{{type="{key}"}} {value}')
        # HTTP 请求计数
        lines.append("# HELP http_requests_total Total HTTP requests")
        lines.append("# TYPE http_requests_total counter")
        for key, value in sorted(_metrics["http_requests_total"].items()):
            status = key[0]
            lines.append(f'http_requests_total{{status="{status}"}} {value}')
        return "\n".join(lines) + "\n"
 # ============================================================
 # HTTP Handler（不阻塞）
 # ============================================================
 class MetricsHandler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/metrics":
            # 只更新请求计数（轻量操作）
            with _metrics_lock:
                _metrics["http_requests_total"][("200",)] = \
                    _metrics["http_requests_total"].get(("200",), 0) + 1
            response = generate_prometheus_metrics().encode("utf-8")
            self.send_response(200)
            self.send_header("Content-Type", "text/plain; charset=utf-8")
            self.send_header("Content-Length", len(response))
            self.end_headers()
            self.wfile.write(response)
        elif self.path == "/health":
            self.send_response(200)
            self.send_header("Content-Type", "application/json")
            response = json.dumps({
                "status": "ok",
                "cache_age": time.time() - _cache_updated,
                "timestamp": datetime.now(timezone.utc).isoformat()
            }).encode()
            self.send_header("Content-Length", len(response))
            self.end_headers()
            self.wfile.write(response)
        else:
            self.send_response(404)
            self.end_headers()
    def log_message(self, format, *args):
        pass
 # ============================================================
 # 启动
 # ============================================================
 if __name__ == "__main__":
    port = int(os.environ.get("EXPORTER_PORT", 9999))
    # 初始化指标
    collect_metrics_background()
    # 启动后台线程：每 60 秒主动刷新
    def refresh_loop():
        while True:
            time.sleep(60)
            collect_metrics_background()
    t = threading.Thread(target=refresh_loop, daemon=True)
    t.start()
    # 启动 HTTP 服务
    server = http.server.HTTPServer(("0.0.0.0", port), MetricsHandler)
    print(f"Agent Health Exporter v2.1 started on port {port}")
    print(f"  - Agents: {len(AGENTS)}")
    print(f"  - Refresh interval: 60s")
    server.serve_forever()
@@ -1,179 +0,0 @@
 #!/usr/bin/env python3
 """
 Alertmanager → Feishu Webhook Bridge v2
 将 Prometheus Alertmanager 告警转发到飞书消息
 运行在宿主机（非容器内），以便使用 openclaw CLI 发送飞书消息。
 路由规则：
 - severity=critical → 通知 Vincent（飞书 ou_8782990ad09c2bd7732a5ef6b23b8508）
 - severity=warning  → 通知 COO（飞书 ou_9f73b4e54af59f038e2b754793ea0908）
 """
 import http.server
 import json
 import os
 import subprocess
 import sys
 import urllib.request
 from datetime import datetime, timezone
 # 飞书 Webhook URL（通过环境变量配置，可选）
 FEISHU_WEBHOOK_CRITICAL = os.environ.get("FEISHU_WEBHOOK_CRITICAL", "")
 FEISHU_WEBHOOK_WARNING = os.environ.get("FEISHU_WEBHOOK_WARNING", "")
 # 接收人 Open ID
 VINCENT_OPEN_ID = "ou_8782990ad09c2bd7732a5ef6b23b8508"
 COO_OPEN_ID = "ou_9f73b4e54af59f038e2b754793ea0908"
 # Grafana 面板 URL
 GRAFANA_URL = "http://192.168.1.99:3001/d/agent-health"
 def send_feishu_message_via_openclaw(open_id, title, content_block, severity):
    """通过 OpenClaw 飞书通道发送消息"""
    card = build_feishu_card(title, content_block, severity)
    payload = json.dumps({
        "receive_id": open_id,
        "msg_type": "interactive",
        "content": json.dumps(card),
    })
    try:
        result = subprocess.run(
            ["openclaw", "message", "send",
             "--channel", "feishu",
             "--target", open_id,
             "--message", payload],
            capture_output=True, text=True, timeout=10
        )
        if result.returncode == 0:
            print(f"[bridge] Feishu sent to {open_id[:20]}...")
        else:
            print(f"[bridge] Feishu error: {result.stderr[:200]}", file=sys.stderr)
    except Exception as e:
        print(f"[bridge] Feishu exception: {e}", file=sys.stderr)
 def send_feishu_webhook(webhook_url, title, content_block, severity):
    """通过飞书 Webhook URL 发送"""
    if not webhook_url:
        return
    card = build_feishu_card(title, content_block, severity)
    payload = json.dumps({"msg_type": "interactive", "content": json.dumps(card)}).encode("utf-8")
    try:
        req = urllib.request.Request(
            webhook_url,
            data=payload,
            headers={"Content-Type": "application/json"},
            method="POST"
        )
        with urllib.request.urlopen(req, timeout=10) as resp:
            print(f"[bridge] Webhook sent: {resp.status}")
    except Exception as e:
        print(f"[bridge] Webhook error: {e}", file=sys.stderr)
 def build_feishu_card(title, content, severity):
    """构建飞书消息卡片"""
    color_map = {
        "critical": "red",
        "warning": "yellow",
        "info": "blue",
    }
    color = color_map.get(severity, "blue")
    return {
        "config": {"wide_screen_mode": True},
        "header": {
            "title": {"tag": "plain_text", "content": f"🚨 {title}"},
            "template": color,
        },
        "elements": [
            {"tag": "markdown", "content": content},
            {
                "tag": "note",
                "elements": [
                    {"tag": "plain_text", "content": f"BIZ-28 监控告警 | {datetime.now(timezone.utc).strftime('%Y-%m-%d %H:%M:%S UTC')}"}
                ]
            }
        ]
    }
 def handle_alert(alert_data):
    """处理告警并发通知"""
    alerts = alert_data.get("alerts", [])
    for alert in alerts:
        labels = alert.get("labels", {})
        annotations = alert.get("annotations", {})
        status = alert.get("status", "firing")
        severity = labels.get("severity", "warning")
        alertname = labels.get("alertname", "Unknown")
        summary = annotations.get("summary", alertname)
        description = annotations.get("description", "")
        title = f"[{severity.upper()}] {summary}"
        content = (
            f"**告警名称**: {alertname}\n"
            f"**状态**: {'🔥 触发中' if status == 'firing' else '✅ 已恢复'}\n"
            f"**严重级别**: {severity}\n"
            f"**详情**: {description}\n\n"
            f"**监控面板**: {GRAFANA_URL}\n"
            f"**告警时间**: {alert.get('startsAt', '')}"
        )
        if severity == "critical":
            # 严重告警 → 通知 Vincent
            if FEISHU_WEBHOOK_CRITICAL:
                send_feishu_webhook(FEISHU_WEBHOOK_CRITICAL, title, content, severity)
            send_feishu_message_via_openclaw(VINCENT_OPEN_ID, title, content, severity)
        elif severity == "warning":
            # 警告告警 → 通知 COO
            if FEISHU_WEBHOOK_WARNING:
                send_feishu_webhook(FEISHU_WEBHOOK_WARNING, title, content, severity)
            send_feishu_message_via_openclaw(COO_OPEN_ID, title, content, severity)
 class WebhookHandler(http.server.BaseHTTPRequestHandler):
    def do_POST(self):
        content_length = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(content_length)
        try:
            alert_data = json.loads(body)
            handle_alert(alert_data)
            self.send_response(200)
            self.send_header("Content-Type", "application/json")
            response = json.dumps({"status": "ok"}).encode()
            self.send_header("Content-Length", len(response))
            self.end_headers()
            self.wfile.write(response)
        except Exception as e:
            print(f"[bridge] Handler error: {e}", file=sys.stderr)
            self.send_response(500)
            self.end_headers()
    def do_GET(self):
        if self.path == "/health":
            self.send_response(200)
            self.send_header("Content-Type", "application/json")
            response = json.dumps({"status": "ok"}).encode()
            self.send_header("Content-Length", len(response))
            self.end_headers()
            self.wfile.write(response)
        else:
            self.send_response(404)
            self.end_headers()
    def log_message(self, format, *args):
        pass
 if __name__ == "__main__":
    port = int(os.environ.get("WEBHOOK_PORT", 9094))
    server = http.server.HTTPServer(("0.0.0.0", port), WebhookHandler)
    print(f"[bridge] Alert Webhook Bridge started on port {port}")
    server.serve_forever()
@@ -1,9 +1,9 @@
 # BIZ-13 智能体运行稳定性保障方案
-> 版本：v1.1  
+> 版本：v1.0  
 > 编制：陆怀瑾（COO）  
 > 日期：2026-06-22  
-> 状态：Phase 1 执行中（Vincent 已审阅同意）
+> 状态：待审阅
 ---
@@ -305,10 +305,9 @@ def retry_with_backoff(api_call, max_retries=3):
 ## 七、实施步骤
 ### 阶段 1：心跳机制落地（本周）
- [x] 更新所有 Agent 的 HEARTBEAT.md（15/15 Agent 已完成）
+- [ ] 更新所有 Agent 的 HEARTBEAT.md
- [x] 已创建分步实施子任务（BIZ-24 ~ BIZ-28，5个子任务）
+- [ ] 配置定时任务（10 分钟）
- [ ] 配置定时任务（10/15 分钟）→ BIZ-25，已分派 opengineer 严维序
+- [ ] 测试超时检测
 - [ ] 测试超时检测 → BIZ-24 执行中
 ### 阶段 2：限流优化（下周）
 - [ ] 实现请求队列
@@ -1,835 +0,0 @@
 # 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/ 目录。
@@ -1,210 +0,0 @@
 # BIZ-25 定时心跳检查 cron 任务部署方案
 > **版本：** v1.0  
 > **编制：** 严维序（opengineer）  
 > **日期：** 2026-06-24  
 > **状态：** 已部署  
 > **父方案：** [BIZ-13 运行稳定性保障方案](./BIZ-13_运行稳定性保障方案.md)
 ---
 ## 一、概述
 本方案是 BIZ-13 Phase1 的执行层方案，负责将 HEARTBEAT.md 模板+共享脚本部署为可运行的定时心跳检查机制。
 ### 部署架构
 ```
 ┌─────────────────────────────────────────────────────┐
 │                OpenClaw Gateway Cron                 │
 │  ┌────────────┐ ┌────────────┐ ┌──────────────┐    │
 │  │ Agent A    │ │ Agent B    │ │ Agent C      │    │
 │  │ 心跳(10/15m)│ │ 心跳(15m) │ │ 心跳(15m)    │    │
 │  └─────┬──────┘ └─────┬──────┘ └──────┬───────┘    │
 │        │              │               │            │
 │        ▼              ▼               ▼            │
 │  ┌──────────────────────────────────────────┐      │
 │  │      shared/scripts/heartbeat_helper.py   │      │
 │  │      + multica_proxy.py                  │      │
 │  │      + rate_limiter.py                   │      │
 │  └──────────────────────────────────────────┘      │
 │        │              │               │            │
 │        ▼              ▼               ▼            │
 │  ┌──────────────────────────────────────────┐      │
 │  │  三源任务检查: WorkBoard + Multica + 文档 │      │
 │  └──────────────────────────────────────────┘      │
 └─────────────────────────────────────────────────────┘
 ```
 ---
 ## 二、Agent 心跳频率分类
 根据 BIZ-13 方案定义：
 | 分类 | 频率 | Agent | 数量 |
 |------|------|-------|------|
 | **高频** | **10 分钟** | 陆怀瑾 (coo), 刘诗妮 (secretary) | 2 |
 | **常规** | **15 分钟** | 严维序 (opengineer), 沈路明 (productmanager), 胡蓉 (projectmanager), 梁思筑 (architect), 苏锦绘 (designer), 徐聪 (costcodev), 文墨言 (contentspecialist), 程伯予 (cvexpert), 许言 (prompt-engineer), 钟帧韵 (mediaspecialist), 陆云帆 (taobaospecialist), 顾析策 (marketanalysis), 苏慎 (lawyer) | 13 |
 ---
 ## 三、部署清单
 ### 3.1 ✅ 已完成 — HEARTBEAT.md 模板
 所有 15 个 Agent 的工作区均已部署 HEARTBEAT.md：
 | 工作区 | 频率 | 核心内容 |
 |--------|------|----------|
 | `coo/` | 10 min | BIZ-38 模板 + 全局积压巡检 |
 | `secretary/` | 10 min | BIZ-38 模板 |
 | `opengineer/` | 10 min | BIZ-38 模板 + 三源检查 |
 | `projectmanager/` | 10 min | BIZ-38 模板 |
 | `costcodev/` | 10 min | BIZ-38 模板 |
 | 其余 10 个 Agent | 15 min | 标准模板 + 三源检查 |
 ### 3.2 ✅ 已完成 — 共享心跳脚本
 路径：`shared/scripts/`
 | 文件 | 用途 | 状态 |
 |------|------|------|
 | `rate_limiter.py` | 缓存管理 + 请求调度 + 协调轮询 | ✅ 已部署 |
 | `multica_proxy.py` | Multica CLI 代理 + 缓存封装 | ✅ 已部署 |
 | `heartbeat_helper.py` | 三源任务检查 + 超时检测 + 心跳入口 | ✅ 已部署 |
 ### 3.3 ⬜ 本次部署 — OpenClaw Cron 任务
 使用 OpenClaw Gateway cron 系统创建定时任务，通过 `agentTurn` 隔离会话实现各 Agent 的周期性心跳触发。
 #### Cron Job 规格
 ```yaml
 每个 Agent:
  schedule:
    kind: cron
    expr: "*/10 * * * *"  # 高频 Agent
    # expr: "*/15 * * * *"  # 常规 Agent
    tz: "Asia/Shanghai"
  sessionTarget: "isolated"
  payload:
    kind: "agentTurn"
    message: "运行心跳检查。执行你的 HEARTBEAT.md 中的三源任务检查。"
 ```
 ---
 ## 四、部署执行记录
 ### 执行时间：2026-06-24 00:14 CST
 #### 创建的 Cron Job 清单
 | Agent | 频率 | Cron Session | 状态 |
 |-------|------|-------------|------|
 | coo (陆怀瑾) | 10 min | isolated agentTurn | ✅ |
 | secretary (刘诗妮) | 10 min | isolated agentTurn | ✅ |
 | opengineer (严维序) | 10 min | isolated agentTurn | ✅ |
 | projectmanager (胡蓉) | 10 min | isolated agentTurn | ✅ |
 | costcodev (徐聪) | 10 min | isolated agentTurn | ✅ |
 | productmanager (沈路明) | 15 min | isolated agentTurn | ✅ |
 | architect (梁思筑) | 15 min | isolated agentTurn | ✅ |
 | designer (苏锦绘) | 15 min | isolated agentTurn | ✅ |
 | contentspecialist (文墨言) | 15 min | isolated agentTurn | ✅ |
 | cvexpert (程伯予) | 15 min | isolated agentTurn | ✅ |
 | prompt-engineer (许言) | 15 min | isolated agentTurn | ✅ |
 | mediaspecialist (钟帧韵) | 15 min | isolated agentTurn | ✅ |
 | taobaospecialist (陆云帆) | 15 min | isolated agentTurn | ✅ |
 | marketanalysis (顾析策) | 15 min | isolated agentTurn | ✅ |
 | lawyer (苏慎) | 15 min | isolated agentTurn | ✅ |
 ---
 ## 五、心跳检查内容
 每次心跳触发后，Agent 在隔离会话中执行以下检查：
 ### 5.1 三源任务检查
 ```mermaid
 flowchart TD
    A[心跳触发] --> B[检查 WorkBoard 待办卡片]
    A --> C[检查 Multica 待办 Issues]
    A --> D[检查本地待办文档]
    B --> E{有待办?}
    C --> E
    D --> E
    E -->|有| F[自动执行任务]
    E -->|无| G[结束心跳]
    F --> H[任务完成?]
    H -->|是| I[更新状态]
    H -->|否| J[通知 COO]
 ```
 ### 5.2 超时检测
 - 进行中任务超过 20 分钟无进展 → 标记"疑似超时"
 - 确认超时 → 自动恢复流程
 ### 5.3 依赖检查
 - 认领任务前检查 `depends_on`
 - 依赖未满足 → 保持 todo，不认领
 ### 5.4 轮次控制
 - 单任务最大 50 轮
 - 接近 80%（40 轮）→ 预警
 - 达到上限 → 暂停，通知 COO
 ---
 ## 六、风险与规避
 | 风险 | 影响 | 应对 |
 |------|------|------|
 | 心跳任务自身卡死 | 监控失效 | rate_limiter.py 缓存 + 超时保护 |
 | 新增 Agent 未配心跳 | 遗漏 | 本方案作为部署 SOP 参考 |
 | 会话隔离导致上下文丢失 | 心跳重复 | 心跳仅做检查，不承担复杂任务 |
 | Agent 不在线 | 心跳无响应 | 系统事件 fallback，COO 巡检兜底 |
 ---
 ## 七、验证方法
 ```bash
 # 检查 cron job 列表
 openclaw cron list
 # 手动触发一次心跳 for a specific agent
 openclaw cron run <job-id>
 # 检查心跳脚本健康状态
 python3 shared/scripts/heartbeat_helper.py <agent_id> --health
 ```
 ---
 ## 八、修复记录
 ### v1.1 — 2026-06-24
 | 问题 | 修复 |
 |------|------|
 | cron delivery 报 Feishu 投递错误 | delivery 从 `announce` 改为 `none`（原方案未指定 delivery，不影响功能） |
 | Multica workspace_id 未传递 | `multica_proxy.py` 新增 `_inject_workspace_id()`，自动在所有 multica CLI 调用注入 `--workspace-id` |
 | AGENT_CONFIGS 仅 5 个 Agent | `heartbeat_helper.py` 扩展至全部 15 个 Agent |
 | COO HEARTBEAT 显示未部署 | 更新 BIZ-38 集成清单表 |
 ## 九、后续优化方向
 - [ ] 监控面板集成（BIZ-28 Phase3）
 - [ ] 心跳结果聚合展示
 - [ ] Agent 健康状态告警
 - [ ] 自动 Agent 发现（新增 Agent 自动配置心跳）
 ---
 > **运维记录**：严维序 2026-06-24  
 > 所有 15 个 Agent 的 HEARTBEAT.md 已部署，共享脚本已就位，cron 定时器已配置。
@@ -1,186 +0,0 @@
 # 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 仓库
@@ -1,446 +0,0 @@
 # 石斛固态食品与烘焙全品类扩展可行性分析报告
 **编号**：BIZ-65  
 **报告类型**：产品扩展可行性分析  
 **分析日期**：2026年6月26日  
 **分析人**：顾析策（市场分析师）  
 **参考文档**：石斛食品饮料全品类产品方向详细文档、BIZ-53 品斛堂企业情报调研报告、BIZ-55 电商调研  
 ---
 ## 摘要
 **核心结论**：品斛堂以石斛为根基向固态食品扩展具备明确可行性。5个子品类中，**膏滋蜜炼和压片糖果为最高优先级**——前者依托品斛堂石斛浸膏技术壁垒和中药膏方100亿+市场，后者复用现有石斛精片基础切入全球485亿美元功能性糖果赛道。OEM/ODM模式是核心实现路径——品斛堂已有为近100家企业代工石斛精片/饼干/面条/果冻/浸膏的经验，固态食品扩展应优先走"自有品牌试水+OEM/ODM双轨并行"策略。
 **关键数据**：
 - 功能性压片糖果亚太区CAGR 12.6%，中国本土企业TOP5市占率39.4%
 - 中药膏滋/煎膏剂100亿+市场（2024），补气补血类占50%+，院内市场同比增长17.2%
 - 中国烘焙市场2595亿元（2025欧睿），人均消费25.5美元仅为日本1/6
 - 果冻市场200-250亿元，功能型果冻增速最快
 - **品斛堂OEM能力已覆盖石斛精片/饼干/面条/果冻/浸膏全品类**
 **TOP5推荐**：①膏滋蜜炼（石斛膏方→差异化壁垒）②压片糖果/含片（高频+功能性+复用基础）③烘焙饼干/节日烘焙（高潜力+代工成熟）④休闲零食（坚果蜜饯→OEM快起量）⑤果冻布丁（功能型差异化切入）
 ---
 ## 一、压片糖果/咀嚼片
 ### 1.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 全球压片糖果市场 | $485亿（2025）→ $512亿（2026E） | ZVZO消费观察 |
 | 中国市场占比 | 22.7%，约$110亿（¥780亿） | ZVZO消费观察 |
 | 中国糖果市场总规模 | ¥930亿（2024） | 华经产业研究院 |
 | 功能性糖果CAGR | 12.6%（亚太区） | ZVZO消费观察 |
 | 药用糖果全球市场 | $63.9亿（2025）→ $91.6亿（2035E） | Global Growth Insights |
 | 中国增速 | 8.3%以上，显著高于全球4.1% | ZVZO消费观察 |
 | 功能性品类占比预测 | 将超过55%（2030E） | ZVZO消费观察 |
 **核心趋势**：
 - 63%消费者将"健康属性"列为购买第一考虑因素，免疫力提升（34%）、口腔清新（27%）、能量补充（21%）为TOP3诉求
 - 无糖/低糖产品渗透率将突破70%
 - 线上销售占比44.6%，直播电商+社区团购贡献线上增量57%
 - 年轻化："零食化+功效化"方向，年轻群体对便携小包装接受度71%
 ### 1.2 竞争格局
 | 梯队 | 代表品牌 | 定位 | 核心优势 |
 |------|------|------|------|
 | 🥇 功能型龙头 | 金嗓子、西瓜霜 | 润喉利咽 | 渠道铺货广，OTC背书 |
 | 🥇 药企延伸 | 同仁堂、修正、江中 | 中药功能含片 | 品牌信任，药房渠道 |
 | 🥈 保健品跨界 | 汤臣倍健、养生堂 | 维C/益生菌咀嚼片 | 品牌力+电商运营强 |
 | 🥉 新锐品牌 | 各OEM代工品牌 | 差异化功能 | 直播电商切入快 |
 **竞争特点**：
 - 传统龙头金嗓子/西瓜霜品牌老化，市场增长缓慢（传统甜味压片2.1%增速）
 - 功能性细分增速远超传统品类
 - 中国TOP5企业市占率39.4%，格局相对分散，新品牌仍有空间
 - OEM产能充沛：全国300+压片糖果代工厂，仙乐健康/会昌等龙头覆盖全剂型
 ### 1.3 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐⭐⭐⭐⭐ | 已有石斛精片产品，可直接升级为石斛含片/咀嚼片 |
 | **原料优势** | ⭐⭐⭐⭐⭐ | 自有石斛全产业链，提取物/多糖/干粉三种形态可做配方核心 |
 | **技术门槛** | ⭐⭐ | 压片工艺标准化，OEM代工成熟（MOQ≈3万包起订） |
 | **渠道匹配** | ⭐⭐⭐⭐ | 复用天猫/京东旗舰店+药房渠道，精准触达咽喉不适/养生人群 |
 | **品牌差异化** | ⭐⭐⭐⭐ | "石斛含片"定位对标金嗓子"咽炎"场景，差异化明显 |
 | **毛利率预估** | ⭐⭐⭐⭐ | 60-70%（压片糖果制造成本低，石斛原料自有优势加成） |
 **可行性：★★★★★ 高**
 **落地路径**：
 - 短期（1-3月）：将现有"石斛精片"升级为"石斛含片"（润喉利咽）+ "石斛西洋参咀嚼片"（补气提神），复用天猫元斛旗舰店渠道
 - 中期（3-6月）：开发"石斛维C咀嚼片"卡位功能维C赛道（对标汤臣倍健）
 - 代工策略：片剂生产线品斛堂已有基础（中药饮片GMP车间），可自主生产；如需扩产，珠三角/长三角OEM厂产能充裕
 ---
 ## 二、休闲零食（坚果炒货+蜜饯果干+纤维饼干）
 ### 2.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国休闲零食市场 | ¥1.3万亿（2020），近¥3万亿（2025E） | 商务部/中国食品工业协会 |
 | 2024年主流电商零食销售额 | ¥3080亿，同比+11% | Flywheel白皮书 [1] |
 | 坚果炒货13-18年CAGR | 11.0% | 欧睿国际 |
 | 人均消费量 | 2.15kg（2015），vs英国9.53kg/美国13.03kg | 商务部 |
 | 抖音零食销售额增长 | 23%，线上第一渠道（份额54%） | 知行咨询2025报告 |
 | 2024肉类零食占三只松鼠销售额 | 20.14% | 知行咨询2025报告 |
 **核心趋势**：
 - 消费者要求"美味与营养兼得"——健康化零食复合增长率远超传统品类
 - 抖音超越淘系成为线上第一零食渠道
 - 渠道型品牌（三只松鼠/B2C）增长见顶，制造型品牌（洽洽/大单品）利润更优
 - 功能性/健康概念零食增速领先：益生菌、高纤维、低GI
 ### 2.2 竞争格局
 | 梯队 | 代表品牌 | 2022年营收 | 模式 | 核心品类 |
 |------|------|:---:|------|------|
 | 🥇 | 三只松鼠 | ¥72.9亿 | B2C电商全品类 | 坚果+肉类零食 |
 | 🥇 | 良品铺子 | ¥66.2亿 | 线上线下双渠道 | 全品类+高端定位 |
 | 🥈 | 百草味 | ~¥40亿 | 百事旗下B2C | 坚果+果脯蜜饯 |
 | 🥈 | 洽洽食品 | ¥68.8亿 | 制造型大单品 | 瓜子+坚果 |
 | 🥉 | 来伊份 | ~¥40亿 | 线下门店 | 全品类 |
 **进入壁垒**：
 - 三巨头线上份额CR3≈33%，渠道垄断性强
 - 坚果炒货品类大厂规模效应显著，价格竞争激烈
 - 蜜饯果干品类CR3低，区域品牌众多，差异化空间大
 ### 2.3 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐⭐⭐ | 已有石斛纤维饼（功能零食），缺少坚果/蜜饯加工能力 |
 | **原料优势** | ⭐⭐⭐ | 石斛粉/提取物可作为调味添加，但坚果/果干需外采 |
 | **技术门槛** | ⭐ | 坚果炒货、蜜饯果干标准化程度高，无技术壁垒 |
 | **渠道匹配** | ⭐⭐⭐ | 天猫/京东零食类目流量大，但需从零建立零食消费者认知 |
 | **品牌差异化** | ⭐⭐⭐ | "石斛+零食"概念有独特性，但需验证消费者接受度 |
 | **毛利率预估** | ⭐⭐ | 30-40%（代工成本高+坚果原料波动，自有品牌溢价有限） |
 **可行性：★★★☆☆ 中**
 **差异化切入策略**：
 - **不推荐**直接进入坚果炒货红海（三只松鼠/洽洽成本碾压）
 - **推荐**：石斛纤维饼升级为"石斛健康零食系列"（复用已有基础）
  - 石斛纤维饼→升级配方，推低GI/高纤维版本
  - 石斛山楂条→开胃消食+石斛养胃（蜜饯OEM成熟）
  - 石斛味坚果→轻添加概念（巴旦木/核桃+石斛粉涂层）
 - 代工策略：蜜饯果干OEM遍布云南/福建（鲜花饼供应链可复用），坚果OEM广东/安徽产能充裕
 ---
 ## 三、谷物主食（挂面+方便面+粥料）
 ### 3.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国挂面市场规模 | 419.92万吨产量（2021），预估>500万吨（2025E） | 中金企信/欧睿 |
 | 挂面市场销售额 | CAGR 10.72%（24家头部企业） | 中金企信 |
 | 方便速食市场 | ¥2500亿（2021）→ ¥6300亿（2025E） | 国信证券 |
 | 中国方便面市场 | 422亿包/年（2023），销量-2.3% CAGR | 勤策消费研究 |
 | 方便食品市场规模 | 2026年将突破万亿 | 勤策消费研究 |
 | 一人食经济 | 1.8万亿（2025，一二线55%宅家烹饪） | Flywheel白皮书 [1] |
 | 外卖市场规模 | 1.27万亿（2024），用户5.92亿 | 美团/行业数据 |
 **核心趋势**：
 - 挂面量增价不增（产量>销量连续10年），利润转向高端化/功能化
 - 方便面传统品类承压（外卖+预制菜挤压），中高端增速17.1%（2016-20）为低端4.2倍
 - "一人食经济"驱动速食向品质化/健康化升级
 - 非油炸/零添加/功能性面条是增长方向
 - 高铁站停售方便面（广东2025）标志性事件→传统场景收窄
 ### 3.2 竞争格局
 | 梯队 | 挂面 | 市场份额 | 方便面 | 市场份额 |
 |------|------|:---:|------|:---:|
 | 🥇 | 金沙河 | 22% | 康师傅 | ~45% |
 | 🥈 | 克明食品 | 8% | 统一 | — |
 | 🥉 | 想念食品 | 4% | 白象 | — |
 | 其他 | 200+中小厂 | 66% | 今麦郎/三养等 | CR5=84% |
 **关键特点**：
 - 挂面CR3仅34%，极度分散，但整合趋势加速（2009年4000+家→2020年200+家）
 - 方便面CR5=84%高集中度，入局极难
 - 康师傅红烧牛肉味被大量仿制，品类同质化严重
 ### 3.3 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐ | 无面条制造经验，需完全依赖OEM |
 | **原料优势** | ⭐⭐ | 石斛粉可添加至面条配方，但小麦/面粉无优势 |
 | **技术门槛** | ⭐ | 挂面制造标准化，方便面需大量设备投入 |
 | **渠道匹配** | ⭐⭐ | 挂面以商超/粮油店为主，与品斛堂现有健康品渠道不匹配 |
 | **品牌差异化** | ⭐⭐ | "石斛养胃挂面"有概念吸引力，但消费者为功能性面条买单意愿待验证 |
 | **毛利率预估** | ⭐ | 15-25%（挂面毛利低，克明毛利率15.87%，想念14.19%） |
 **可行性：★★☆☆☆ 低**
 **判断**：谷物主食不是品斛堂当前优先级最高的扩展方向。理由：
 1. 挂面行业利润薄（克明食品2021年净利仅6700万，收入43亿），石斛添加只会进一步压缩毛利
 2. 渠道完全不匹配——挂面走商超/粮油店，品斛堂现有天猫+药房+酒类渠道
 3. 金沙河/克明双寡头成本碾压，新进入者无规模优势
 4. 唯一有吸引力的场景是"石斛面条"作为**品牌形象产品**（非利润产品）在旗舰店上架，配合石斛粥料做养生主食组合
 **如仍需进入的建议**：OEM代工石斛养生粥料（谷物+石斛预拌包）→低风险入场，石斛面条作为品牌配套产品而非主推
 ---
 ## 四、半固态/凝胶食品（膏滋蜜炼+果冻布丁）
 ### 4.1 膏滋蜜炼（膏方）
 #### 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中成药浸膏/煎膏剂三大终端 | ¥100亿+（2024） | 米内网 |
 | 院内市场增速 | +17.20%（2025，逆势上扬） | 米内网 |
 | 补气补血类占比 | >50%市场份额 | 米内网 |
 | 中国阿胶市场 | ¥580亿（2025）→ 千亿（2030E, CAGR 10.4%） | 知乎/东阿阿胶年报 |
 | 东阿阿胶2025年营收 | ¥67亿（+13.17%），阿胶系列61.9亿 | 东阿阿胶年报 |
 | 药食同源市场 | ¥3800亿→¥7500亿（2030E, CAGR 10.8%） | 雪球/药食同源研报 [2] |
 **核心趋势**：
 - 膏方从传统中医药向"新中式滋补"演化，消费场景从治病转向日常养生
 - 阿胶品类"零食化+便携化"趋势显著——阿胶糕/速溶粉/阿胶奶茶跨界
 - 东阿阿胶线上营收占比19.79%（2025Q1），膏方电商化仍在早期
 - 90后/00后买走60%阿胶产品，养生年轻化是确定性趋势
 #### 竞争格局
 | 梯队 | 品牌 | 膏方优势 | 2025年表现 |
 |------|------|------|------|
 | 🥇 | 东阿阿胶 | 阿胶膏/桃花姬 | ¥61.9亿阿胶系列 |
 | 🥇 | 同仁堂 | 传统膏方/秋梨膏 | 院外膏方TOP3 |
 | 🥈 | 胡庆余堂 | 江南膏方 | — |
 | 🥈 | 福牌阿胶 | 阿胶膏方 | 院外膏方TOP3 |
 | 🥉 | 白云山潘高寿 | 蜜炼川贝枇杷膏/养阴清肺膏 | 院内膏方第1 |
 | 🔑 | **品斛堂机会** | **石斛膏方=品类空白** | 已有石斛浸膏技术 |
 #### 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐⭐⭐⭐⭐ | 已有石斛浸膏OEM能力，"铁皮石斛膏/秋梨石斛膏"配方有技术储备 |
 | **原料优势** | ⭐⭐⭐⭐⭐ | 石斛全产业链+石斛多糖提取物，膏方核心原料自有 |
 | **技术门槛** | ⭐⭐⭐⭐ | 中药浸膏制造有GMP门槛，品斛堂中药饮片/保健食品净化车间齐全 |
 | **渠道匹配** | ⭐⭐⭐⭐⭐ | 天猫健康品+药房+送礼场景→完美匹配膏方消费场景 |
 | **品牌差异化** | ⭐⭐⭐⭐⭐ | "石斛膏"品类无强势品牌占据，"秋梨石斛膏"对标"秋梨膏"差异明显 |
 | **毛利率预估** | ⭐⭐⭐⭐⭐ | 65-80%（膏方高毛利，东阿阿胶毛利率73.47%，石斛自有原料加成更高） |
 **可行性：★★★★★ 高（最高优先级）**
 **落地路径**：
 - 短期（1-3月）：复用现有石斛浸膏生产线，推出"铁皮石斛膏"（¥199-399/300g）+"秋梨石斛膏"（¥59-99），天猫旗舰店首发
 - 中期（3-6月）：开发"阿胶石斛膏"（女性气血）+石斛膏方礼盒（春节/中秋送礼）
 - 差异化定位：品斛堂膏方=石斛为核心（vs同仁堂/东阿阿胶以阿胶/人参为核心），开辟"石斛膏方"新品类
 ---
 ### 4.2 果冻布丁
 #### 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国果冻市场 | ¥200-250亿（2023） | 中研普华/百度百科 |
 | 生产企业数量 | 2000+家（其中规模企业300+家） | 中研普华 |
 | 喜之郎年销售额 | ¥15亿+ | MBA智库百科 |
 | 功能型果冻趋势 | 乳酸菌/益生菌/代餐果冻增速最快 | 头豹研究院 |
 | 中国新式茶饮市场 | 突破4000亿（2028E） | 行业报告 |
 **核心趋势**：
 - 果冻从"儿童零食"向"全年龄健康零食"转型
 - 益生菌果冻、蒟蒻果冻（低热量）、代餐果冻是三大增长方向
 - 女性消费者占食品网购65%，果冻天然受女性青睐
 #### 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐⭐ | 品斛堂百度百科列有石斛果冻OEM能力，但无自有品牌产品 |
 | **原料优势** | ⭐⭐⭐ | 石斛多糖/提取物可添加至果冻配方，功能差异化 |
 | **技术门槛** | ⭐ | 果冻OEM极度成熟（全国386+食品代工厂可做果冻） |
 | **渠道匹配** | ⭐⭐⭐ | 天猫零食/女性健康品类目可覆盖 |
 | **品牌差异化** | ⭐⭐⭐ | "石斛仙草冻""石斛益生菌果冻"有差异化概念 |
 | **毛利率预估** | ⭐⭐⭐ | 40-55%（功能性果冻有溢价，但喜之郎量价优势明显） |
 **可行性：★★★☆☆ 中（可作配套品类）**
 **判断**：果冻布丁适合作为"石斛健康零食矩阵"的配套品类而非主力。石斛仙草冻（对标烧仙草）和石斛益生菌果冻有差异化概念，但品类天花板200-250亿且喜之郎品牌统治力极强。建议OEM少量试水，作为健康零食线的补充。
 ---
 ## 五、烘焙食品（面包吐司+饼干曲奇+节日烘焙）
 ### 5.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国烘焙市场（欧睿口径） | ¥2595亿（2025），CAGR 7.22% | 欧睿国际/桃李年报 |
 | 中国烘焙市场（广义） | ¥6110.7亿（2024），+8.8% | 广告门2025报告 |
 | 中国面包市场 | ¥1574亿（2024） | 华经产业研究院 |
 | 全球烘焙市场 | $5165亿（2025） | 桃李年报 |
 | 中国人均烘焙消费 | $25.5（vs日本$150+，美国$200+） | 欧睿国际 |
 | 短保面包龙头份额 | 桃李35%（2023） | 短保面包白皮书 |
 | 全国烘焙门店 | 33.8万家（2025年5月） | 红餐大数据 |
 **核心趋势**：
 - 中国烘焙人均消费仅为日本1/6，增长空间可观
 - 烘焙糕点被Flywheel白皮书列为"电商四大高潜力品类"——线上负增长但社媒高热，**供需错配蕴藏机会**
 - 短保面包向正餐化发展，桃李2025年营收54.48亿但下滑10.5%→行业竞争加剧
 - 节日烘焙是利润中心：月饼/粽子季节爆发，高端礼盒毛利50-70%
 - 功能性烘焙方向：全麦/高纤维/益生菌/低GI
 ### 5.2 竞争格局
 | 梯队 | 品牌 | 品类 | 2025年营收/表现 |
 |------|------|------|:---:|
 | 🥇 | 桃李面包 | 短保面包 | ¥54.48亿（-10.5%） |
 | 🥇 | 达利园 | 长保面包+糕点 | CR3≈3.9% |
 | 🥈 | 盼盼/曼可顿/美焙辰 | 短保/中保面包 | — |
 | 🥈 | 美心/杏花楼 | 月饼/节日烘焙 | — |
 | 🥉 | 33.8万家烘焙门店 | 现制烘焙 | 49.3%品牌5-30家门店 |
 **行业特点**：
 - CR3仅8.9%，极度分散
 - 桃李"中央工厂+批发"模式面临现制烘焙门店冲击（33.8万家）
 - 外资品牌份额从28%（2023）降至20%（2025），本土品牌崛起
 ### 5.3 品斛堂可行性评估
 | 维度 | 评估 | 说明 |
 |------|:---:|------|
 | **产品基础** | ⭐⭐ | 有石斛纤维饼（饼干类），无面包/烘焙经验 |
 | **原料优势** | ⭐⭐ | 石斛粉可作烘焙添加，但面粉/黄油无优势 |
 | **技术门槛** | ⭐ | 饼干/糕点OEM全国成熟（386+代工厂含烘焙） |
 | **渠道匹配** | ⭐⭐⭐ | 饼干→天猫零食类目；月饼→送礼渠道与酒类渠道复用 |
 | **品牌差异化** | ⭐⭐⭐ | "石斛养生月饼""石斛苏打饼干（养胃概念）"有差异化 |
 | **毛利率预估** | ⭐⭐⭐ | 40-55%（饼干/月饼毛利较高，桃李短保面包毛利更低） |
 **可行性：★★★★☆ 中高**
 **推荐路径**：
 - 饼干线（优先）：石斛苏打饼干（养胃概念）+石斛黄油曲奇→OEM代工，天猫零食线首发
 - 节日烘焙（高潜力）：石斛月饼（中秋）+"石斛粽子"（端午）→复用酒类送礼渠道+企业福利渠道
 - 面包吐司：**不推荐**——短保面包配送半径限制+桃李/曼可顿成本碾压+全国化物流投入巨大
 ---
 ## 六、OEM/ODM 可行性分析
 ### 6.1 品斛堂现有OEM能力
 根据百度百科及什么值得买OEM评测，品斛堂**已具备以下品类的OEM/ODM代工能力**：
 | 已覆盖品类 | 与本报告品类匹配 | 代工形式 | 备注 |
 |------|:---:|------|------|
 | 石斛精片 | ✅ 压片糖果 | OEM/ODM | 现有成熟产线 |
 | 石斛饼干 | ✅ 休闲零食/烘焙 | OEM/ODM | 现有成熟产线 |
 | 石斛面条 | ✅ 谷物主食 | OEM/ODM | 现有产线 |
 | 石斛果冻 | ✅ 凝胶食品 | OEM/ODM | 现有产线 |
 | 石斛浸膏 | ✅ 膏滋蜜炼 | OEM/ODM | 核心技术壁垒 |
 | 石斛原浆 | — | ODM | 品类开创者 |
 ### 6.2 双轨并行策略
 品斛堂固态食品扩展的最佳路径是**"自有品牌试水 + OEM/ODM双轨并行"**：
 | 策略方向 | 实施路径 | 适用品类 |
 |------|------|------|
 | **自有品牌试水** | 天猫/京东旗舰店先上2-3款爆品测试市场反应 | 膏方、含片、饼干 |
 | **OEM为品牌代工** | 以"石斛原料+制造"服务其他健康食品品牌 | 坚果、果冻、挂面 |
 | **ODM输出方案** | 为渠道品牌提供石斛食品整体ODM方案 | 全品类 |
 **"卖铲子给掘金者"策略逻辑**：
 - 品斛堂全产业链石斛原料+三重生产资质（药品/保健食品/食品）→天然具备为其他品牌代工的优势
 - 固态食品扩展中，不必每条线都自建品牌——挂面/坚果/果冻的自有品牌投入产出比不高
 - **核心策略**：高价值品类自建品牌（膏方/含片）+低壁垒品类做OEM/ODM服务商
 ---
 ## 七、综合评估与TOP5推荐
 ### 7.1 5个子品类综合评分
 | 评估维度（权重） | 压片糖果 | 休闲零食 | 谷物主食 | 膏滋蜜炼 | 烘焙食品 |
 |------|:---:|:---:|:---:|:---:|:---:|
 | 市场规模（15%） | 9 | 10 | 7 | 7 | 9 |
 | 市场增速（10%） | 8 | 6 | 5 | 9 | 7 |
 | 品斛堂产品基础（20%） | 9 | 6 | 2 | 10 | 5 |
 | 原料/技术优势（15%） | 9 | 5 | 3 | 10 | 4 |
 | 品牌差异化（15%） | 8 | 6 | 4 | 10 | 6 |
 | 渠道匹配度（10%） | 8 | 5 | 2 | 10 | 6 |
 | OEM实现难度（5%） | 10 | 9 | 8 | 6 | 8 |
 | 毛利率预期（10%） | 8 | 5 | 3 | 10 | 7 |
 | **加权总分** | **8.45** | **6.45** | **3.90** | **9.35** | **6.35** |
 ### 7.2 TOP5推荐排序
 | 排名 | 品类方向 | 推荐产品 | 优先级 | 建议策略 | 预期毛利率 | 风险等级 |
 |:---:|------|------|:---:|------|:---:|:---:|
 | 🥇 | **膏滋蜜炼** | 铁皮石斛膏/秋梨石斛膏/阿胶石斛膏 | 🔴极高 | 自有品牌首发，复用浸膏产线 | 65-80% | 🟢 低 |
 | 🥈 | **压片糖果** | 石斛含片/石斛西洋参咀嚼片/石斛维C咀嚼片 | 🔴极高 | 升级石斛精片，复用天猫旗舰店 | 60-70% | 🟢 低 |
 | 🥉 | **烘焙饼干** | 石斛苏打饼干/石斛黄油曲奇/石斛月饼 | 🟡高 | OEM代工，饼干日常+月饼节日双线 | 40-55% | 🟡 中低 |
 | 4 | **休闲零食** | 石斛山楂条/石斛纤维饼升级/石斛味坚果 | 🟡中 | OEM代工，轻资产试水 | 30-40% | 🟡 中 |
 | 5 | **果冻布丁** | 石斛仙草冻/石斛益生菌果冻 | 🟢中 | OEM代工，作为零食线配套 | 40-55% | 🟡 中 |
 ### 7.3 不推荐进入的品类
 | 品类 | 原因 |
 |------|------|
 | 挂面/方便面 | 利润极薄+渠道不匹配+金沙河/克明成本碾压 |
 | 石斛面包吐司 | 短保配送半径限制+桃李/曼可顿竞争+全国物流投入巨大 |
 | 大规模坚果炒货 | 三只松鼠/洽洽成本碾压+原料无优势 |
 ---
 ## 八、数据来源与假设说明
 ### 数据来源
 | 编号 | 来源 | 覆盖数据项 |
 |:---:|------|------|
 | [1] | Flywheel《2025零食饮料趋势白皮书》 | 电商零食3080亿、一人食1.8万亿 |
 | [2] | ZVZO消费观察《全球及中国压片糖果市场趋势深度分析报告2026》 | 压片糖果全球$485亿、功能性CAGR 12.6% |
 | [3] | 华经产业研究院《2025年中国糖果行业分析》 | 中国糖果930亿 |
 | [4] | Global Growth Insights 药用糖果市场报告 | 药用糖果$63.9亿 |
 | [5] | 头豹研究院《大杯什锦果冻行业分析》 | 果冻市场200-250亿 |
 | [6] | 米内网《中成药浸膏剂/煎膏剂数据分析》 | 膏滋100亿+、同比增长17.2% |
 | [7] | 东阿阿胶2025年报 / 证券时报 | 东阿阿胶67亿、阿胶市场580亿 |
 | [8] | 欧睿国际 / 桃李面包2025年报 | 中国烘焙2595亿、人均$25.5 |
 | [9] | 中金企信 / 想念食品招股书 | 挂面市场500万吨、金沙河22%/克明8% |
 | [10] | 国信证券 / 勤策消费研究 | 方便速食2500-6300亿 |
 | [11] | 品斛堂百度百科 | OEM品类覆盖：精片/饼干/面条/果冻/浸膏 |
 | [12] | 什么值得买"品斛堂OEM评测" | OEM实操经验验证 |
 | [13] | 知行咨询《2025休闲零食行业年度洞察》 | 抖音零食份额54%、三只松鼠品类结构 |
 | [14] | 雪球/药食同源研报 [2] | 药食同源3800→7500亿 |
 | [15] | 品斛堂企业情报调研报告（BIZ-53） | 品斛堂产品线、DSR、电商数据 |
 ### 关键假设
 1. 品斛堂现有石斛精片/纤维饼/浸膏OEM产线可快速转自有品牌生产——基于百度百科及OEM评测信息，假设成立
 2. 石斛膏方/含片毛利率估计基于中药行业同类产品（东阿阿胶73.47%毛利率、片剂保健食品60-80%），剔除石斛自有原料带来的成本优势后估算
 3. 饼干/坚果/果冻毛利率为行业平均水平，考虑规模劣势后下调5-10%
 4. 市场规模数据时效性：核心数据来源为2024-2026年报告，时效性满足当前分析需求
 5. 所有预测类数据已标注为"E"（预估），误差范围±15%
 ### 更新频率建议
 - 核心市场数据（糖果/零食/烘焙）：年度更新
 - 竞品动态（三只松鼠/桃李/东阿阿胶）：季度追踪
 - 品斛堂自有品牌试水数据：月度复盘
 ---
 *报告完成：顾析策 🔍 | 市场分析师 | 2026年6月26日*  
 *数据截至：2026年6月*  
 *本报告基于公开市场数据和行业研究报告编制，品斛堂内部产能数据来源于公开信息（百度百科、什么值得买评测）*
@@ -1,420 +0,0 @@
 # 石斛功能保健食品、礼品礼盒、创新跨界品类扩展可行性分析报告
 **报告编号**：BIZ-66  
 **报告类型**：高毛利/差异化品类扩展可行性分析  
 **分析日期**：2026年6月26日  
 **分析人**：顾析策（市场分析师）  
 **参考文档**：石斛食品饮料全品类产品方向详细文档、BIZ-53 企业情报调研报告、BIZ-64/BIZ-65 分析报告  
 ---
 ## 一、摘要
 **核心结论**：品斛堂在功能保健食品、礼品礼盒、创新跨界三大方向上存在明确的扩展机会，但需按"合规门槛→市场爆发力→品斛堂能力匹配"三维度排序——**蓝帽子保健食品是长期壁垒最高的方向，但需接受12-36个月审批周期；礼品礼盒是短期最容易变现的方向，可复用现有产品基础和渠道；创新跨界品类的ROI不确定性最高，适合小批量试水**。
 **关键数据**：
 - 中国保健食品市场规模2024年达2308亿元（中商），2025年预计2447亿元；功能性食品市场2025年突破3700亿元（含食品化方向）
 - 2025年Q1蓝帽子获批504款（含备案），注册类新产品141款，保健食品零食化趋势加速
 - 中国礼物经济市场2025年预计达14498亿元，健康礼赠搜索量年增200%，天猫健康礼盒成交增长40%+
 - 全球植物基食品市场2026年预计945亿美元，中国占全球植物基奶市场34%
 - 药食同源市场3800亿元（2024）→7500亿元（2030），CAGR 10.8%；石斛淘系Q1线上销售额1.25亿元，同比+42%
 **TOP5推荐排序**：
 | 排名 | 品类 | 优先级 | 预期毛利率 | 核心逻辑 |
 |:---:|------|:---:|:---:|------|
 | 🥇 | **石斛礼品礼盒**（原浆+酒+枫斗） | ⭐⭐⭐⭐⭐ | 55-70% | 现有产品复用、节日脉冲、渠道成熟、极速落地 |
 | 🥈 | **石斛普通功能食品**（胶原蛋白肽饮/钙片） | ⭐⭐⭐⭐ | 50-65% | 备案制快速上市、无需蓝帽子审批、石斛成分差异化 |
 | 🥉 | **石斛蓝帽子保健食品**（胃黏膜保护片/增强免疫力胶囊） | ⭐⭐⭐⭐ | 65-80% | 长期壁垒最高、毛利率最高、品斛堂已有三重生产资质+功效实验数据 |
 | 4 | **石斛功能性口腔食品**（润喉糖/口香糖） | ⭐⭐⭐ | 45-55% | 高频快消、护喉需求爆发、OEM成熟 |
 | 5 | **石斛植物基食品**（石斛植物奶/豆腐） | ⭐⭐ | 35-50% | 趋势正确但品斛堂能力匹配度低、需新建产能 |
 ---
 ## 二、蓝帽子保健食品（需注册·高毛利高壁垒）
 ### 2.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国保健食品市场规模（2024） | 2308亿元，同比+6.9% | 中商产业研究院 [1] |
 | 2025年预测规模 | 2447亿元 | 中商 [1] |
 | 养生保健食品市场（2023） | 3282亿元，同比+8.29% | 新营养 [2] |
 | 药食同源市场（2024→2030） | 3800亿→7500亿，CAGR 10.8% | 雪球/行业研报 [3] |
 | 2024年获批国产注册类保健食品 | 391款（其中新注册329款） | 中商 [1] |
 | 2025年Q1获批保健食品 | 504款（含备案），注册类141款 | 新营养 [2] |
 | 2025年Q1获批TOP功能 | 血糖、脂肪控制、润肠通便 | 新营养 [2] |
 | 2024年获批国产备案凭证 | 4307款 | 中商 [1] |
 | 头部品牌毛利率 | 60-75%（汤臣倍健66.7%，健合60.7%） | 头豹 [4] |
 | 保健食品零食化剂型 | 软糖/爆珠等新剂型进入批文 | 新营养 [2] |
 **趋势信号**：
 - 2025年Q1植物性营养素占比47.82%，传统中药类（灵芝、西洋参、酸枣仁）占主导，石斛注册产品目前稀缺——**蓝海窗口**
 - 药食同源目录已覆盖106种，石斛认知度加速提升
 - 2025年进口保健食品注册通道重启，6款进口获批——国内竞争加剧信号
 - 保健食品零食化趋势：糖果糕点类出现在批文中，打破"胶囊片剂"固有印象
 - 2025年3月政策："完善特殊食品注册许可制度，对符合条件的重点品种实施优先审评审批"——新《意见》利好创新品类
 ### 2.2 合规路径与时间成本
 | 路径 | 适用条件 | 审批周期 | 审批级别 | 适合品斛堂的产品 |
 |------|----------|:---:|------|------|
 | **注册制** | 目录外原料/首次进口/新功能声称 | 12-36个月 | 国家市场监管总局 | 石斛胃黏膜保护片、增强免疫力胶囊、缓解疲劳口服液 |
 | **备案制** | 原料已列入保健食品原料目录 | 1-3个月 | 省级市场监管局 | 石斛营养素补充剂（若石斛进入目录后） |
 | **普通功能食品** | 无功能声称、按普通食品管理 | 无需审批 | — | 石斛胶原蛋白肽饮、石斛钙片 |
 **品斛堂合规优势**：
 - ✅ 已具备药品+保健食品+食品三重生产资质
 - ✅ 已有斑马鱼功效实验数据（胃黏膜保护、免疫力方向）
 - ✅ 紫皮石斛全产业链控制（种植→加工→提取）
 - ⚠️ 需补充：注册制产品完整的毒理学试验+功能学试验+人体试食试验
 **时间线建议**：
 - **短期（0-6个月）**：启动注册制申报资料准备（配方定型+安全性评价+功能学评价），同步上线普通功能食品
 - **中期（6-18个月）**：完成注册资料提交，进入技术审评阶段
 - **长期（18-36个月）**：获批蓝帽子批文，正式上市
 ### 2.3 品斛堂匹配度评估
 | 维度 | 评分 | 说明 |
 |------|:---:|------|
 | 原料优势 | ⭐⭐⭐⭐⭐ | 自有千亩有机石斛基地，原料成本可控，多糖含量≥2200mg/100g |
 | 生产技术 | ⭐⭐⭐⭐ | 酶解+低温浓缩+超临界CO₂萃取技术已成熟，可支撑功能因子高保留 |
 | 合规资质 | ⭐⭐⭐⭐ | 已具备三重生产资质，但蓝帽子注册批文需从零申请 |
 | 研发能力 | ⭐⭐⭐ | 已有斑马鱼功效数据，但需补充完整GLP毒理+临床功能学试验 |
 | 品牌信任 | ⭐⭐⭐ | 石斛原浆第一品牌认知可转化，但"保健品"心智尚未建立 |
 ### 2.4 具体产品评估
 #### A. 石斛胃黏膜保护片（蓝帽子注册制）
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 胃黏膜损伤人群、慢性胃炎患者、长期服药人群 |
 | 市场规模 | 胃肠健康保健食品市场超200亿，TOP10胃肠功能产品年销过亿 |
 | 竞争格局 | 江中药业（健胃消食片年销20亿+）、修正药业、葵花药业主导，石斛差异化切入尚属空白 |
 | 预期毛利率 | 65-80%（对标江中药业毛利率67%） |
 | 品斛堂优势 | 斑马鱼实验已验证石斛多糖胃黏膜保护功效，紫皮石斛多糖含量行业领先 |
 | 时间成本 | 注册制审批12-36个月，申报资料准备3-6个月 |
 | 风险 | 审批不确定性；市场竞争激烈，品牌认知需长期建设 |
 #### B. 石斛增强免疫力胶囊（蓝帽子注册制）
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 免疫力低下人群、术后恢复、老年人群 |
 | 市场规模 | 增强免疫力为保健食品申报功能TOP1，2024年获批产品中免疫类占最大份额 |
 | 竞争格局 | 汤臣倍健蛋白粉、无限极增健口服液等已占据主流心智，但石斛+免疫是差异化组合 |
 | 预期毛利率 | 65-80% |
 | 品斛堂优势 | 石斛多糖增强免疫的文献研究充分，斑马鱼实验可支持功效声称 |
 | 时间成本 | 同上，注册制12-36个月 |
 | 风险 | 免疫力声称已是红海；需要差异化功效定位 |
 #### C. 石斛缓解疲劳口服液（蓝帽子注册制）
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 易疲劳人群、熬夜加班族、运动人群 |
 | 市场规模 | 缓解体力疲劳为保健食品TOP3申报功能，市场规模超150亿 |
 | 竞争格局 | 红牛（170亿+）、东鹏特饮、无限极主导；草本抗疲劳方向尚存差异化空间 |
 | 预期毛利率 | 65-75% |
 | 品斛堂优势 | 石斛西洋参复配属传统补气养阴经典组合，配方壁垒较高 |
 | 时间成本 | 同上 |
 | 风险 | 与红牛等功能饮料品类边界模糊，需明确"保健食品"而非"饮料"定位 |
 ---
 ## 三、普通功能食品（无需蓝帽子·快速上市）
 ### 3.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国功能性食品市场（2025） | 突破3700亿元，增长率12-15% | 知乎/行业研报 [5] |
 | 全球功能性食品（2024→2034） | $3322亿→$6380亿，CAGR 6.9% | GMInsights [6] |
 | 胶原蛋白肽市场 | 中国口服美容市场2024年超250亿元，CAGR 15%+ |
 | 钙补充剂市场 | 中国钙制剂市场2024年约180亿元，50+人群渗透率持续提升 |
 | 零食化养生趋势 | 72%的90后用功能性零食替代传统保健品 | 美团/小红书 [7] |
 ### 3.2 合规路径
 普通功能食品的**核心合规策略**：
 - ✅ 按普通食品标准管理，上市无需审批
 - ✅ 可在包装标注"含石斛多糖""添加XX成分"（成分声称，不涉及功能声称）
 - ✅ 可通过小红书/抖音等渠道做成分科普和食疗内容（KOL种草+达人推荐）
 - ❌ 不得宣传任何保健功能（如"保护胃黏膜""增强免疫力"）
 - ❌ 产品名称不得含保健功能暗示
 ### 3.3 具体产品评估
 #### A. 石斛胶原蛋白肽饮
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 25-45岁女性，美容养颜+日常滋养 |
 | 市场规模 | 口服美容市场250亿+，胶原蛋白肽为核心品类 |
 | 对标品牌 | 汤臣倍健Yep、姿美堂、Swisse |
 | 预期毛利率 | 55-65% |
 | 差异化 | 石斛多糖"滋阴养胃+胶原蛋白美容"双重复配，传统滋养与现代功能性结合 |
 | 上市周期 | 3-6个月（配方定型+稳定性测试+备案上市） |
 | 渠道匹配 | 现有电商渠道可直接复用（天猫+抖音+视频号） |
 #### B. 石斛钙片/钙咀嚼片
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 中老年人群、骨健康关注者 |
 | 市场规模 | 钙制剂市场180亿+ |
 | 对标品牌 | 钙尔奇、迪巧、汤臣倍健 |
 | 预期毛利率 | 50-60% |
 | 差异化 | 钙+石斛多糖"补钙+养胃"，减少传统钙片对胃的刺激感 |
 | 上市周期 | 3-6个月 |
 | 渠道匹配 | 药店+电商+商超 |
 #### C. 石斛益生菌粉/软糖
 | 评估维度 | 内容 |
 |------|------|
 | 目标人群 | 肠胃不适人群、年轻养生族 |
 | 市场规模 | 益生菌市场2025年全球770亿美元，中国占25%，年增20%+ |
 | 对标品牌 | 合生元、妈咪爱、wonderlab |
 | 预期毛利率 | 50-65% |
 | 差异化 | 益生菌+石斛多糖"双重养胃"，肠道+胃黏膜协同保护 |
 | 趋势红利 | 保健食品零食化（软糖/爆珠剂型）——符合年轻化消费趋势 |
 | 上市周期 | 3-6个月 |
 ---
 ## 四、礼品礼盒（高毛利·节日爆发）
 ### 4.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国礼物经济市场（2025E） | 14498亿元，持续增长 | 艾媒咨询 [8] |
 | 2027年预测 | 16197亿元 | 艾媒 [8] |
 | 健康礼赠搜索量增长 | 年增200% | 天猫健康 [9] |
 | 天猫健康礼盒成交增长 | FY24同比增长40%+，3万+款礼盒 | 天猫健康 [9] |
 | 诞生千万单品数 | FY24期间27款 | 天猫健康 [9] |
 | 年轻人选健康类年礼比例 | 近70% | TMIC白皮书 [9] |
 | 近30%消费者送过最成功的礼品 | 与健康相关 | TMIC白皮书 [9] |
 | 春节/中秋销售额占比 | 全年约25% | Flywheel白皮书 |
 | 礼品行业复合增长率 | 7% | 凯度/励展华博 [10] |
 **关键趋势**：
 - 送礼从"面子工程"转向"价值感+情绪表达"，健康礼赠成为确定性增长极
 - 天猫推出"送礼"功能，淘宝App全量上线——降低送礼决策成本
 - 燕之屋（燕窝礼盒）、小仙炖（燕窝礼盒）、东阿阿胶（阿胶礼盒）已在礼赠赛道验证——石斛礼盒尚未被头部品牌锁定
 - 一线品牌春节礼盒案例：燕之屋携手法国设计师，小仙炖联名非遗艺术家——**包装设计本身就是传播媒介**
 ### 4.2 品斛堂现有礼盒基础
 | 现有产品 | 价格带 | 基础评价 |
 |------|:---:|------|
 | 紫皮石斛原浆至臻礼盒 | ¥900+ | 已有高端礼盒经验，原浆作为送礼主形态已验证 |
 | 石斛酒礼盒 | ¥300-900 | CIC认证"石斛酒中国销量第一"，酒礼盒天然适配商务送礼 |
 | 铁皮石斛原浆礼盒 | ¥499-799 | 中高端送礼定位，可扩展至年节礼盒 |
 ### 4.3 礼盒扩展建议
 #### A. 石斛原浆礼盒体系化（首推）
 | 维度 | 内容 |
 |------|------|
 | 策略 | 建立"原浆礼盒金字塔"——入门级(¥299-399)→中端(¥499-799)→高端(¥999-2999) |
 | 产品线 | 紫皮原浆入门礼盒、铁皮原浆中端礼盒、霍山米斛原浆高端礼盒、复合原浆组合礼盒 |
 | 场景匹配 | 春节全家福礼盒、中秋商务礼盒、日常拜访养生礼盒、长辈祝寿礼盒 |
 | 包装策略 | 联名非遗/IP设计师打造限定包装，强化"云南龙陵·道地石斛"产地叙事 |
 | 预期毛利率 | 55-70%（礼盒溢价+包装附加值） |
 | 竞争优势 | 石斛原浆第一品牌背书+全产业链透明溯源 |
 | 渠道 | 天猫健康礼赠会场+视频号礼赠营销+企业团购福利+线下药店铺货 |
 #### B. 石斛酒礼盒升级
 | 维度 | 内容 |
 |------|------|
 | 策略 | 围绕"中国石斛露酒开创者"身份，打造商务宴请+节日送礼双场景 |
 | 产品线 | 石斛西洋参灵芝酒礼盒（蓝帽子）、石斛米香白酒礼盒（云南特色）、石斛+原浆组合礼盒（酒+滋补） |
 | 预期毛利率 | 55-75%（蓝帽子酒礼盒毛利最高） |
 | 礼盒策略 | 云南民族文化元素包装+产地溯源二维码+限量版工艺 |
 #### C. 石斛枫斗礼盒（传统高端）
 | 维度 | 内容 |
 |------|------|
 | 策略 | 面向传统滋补送礼人群，强调"道地基源+手工精选" |
 | 产品线 | 铁皮石斛枫斗礼盒(¥599-999)、紫皮石斛枫斗礼盒(¥299-599)、霍山米斛枫斗礼盒(¥1299-2999) |
 | 预期毛利率 | 55-65% |
 | 适合人群 | 传统养生认知强的中老年送礼场景、高端商务馈赠 |
 ---
 ## 五、创新跨界品类（差异化·爆品潜力）
 ### 5.1 功能性口腔食品
 #### 5.1.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 中国口香糖市场 | 约120亿元，增速放缓但功能性方向增长 |
 | 中国润喉糖/含片市场 | 约80亿元，后疫情时代护喉需求持续 |
 | 口腔护理食品趋势 | "清新口气+口腔健康"双功能融合，益生菌口香糖/含片兴起 |
 | 对标产品 | 金嗓子喉宝（年销20亿+）、王老吉润喉糖、绿箭/益达 |
 #### 5.1.2 具体产品评估
 | 产品 | 目标人群 | 价格带 | 预期毛利率 | 品斛堂匹配度 | 结论 |
 |------|----------|:---:|:---:|:---:|------|
 | 石斛润喉糖 | 用嗓过度、咽喉不适人群 | ¥12.9-22.9/盒 | 45-55% | ⭐⭐⭐⭐ | **首推**——石斛清咽利喉传统认知强，制造工艺成熟，OEM快启动 |
 | 石斛口香糖 | 口腔异味人群 | ¥9.9-19.9/盒 | 40-50% | ⭐⭐⭐ | 可试水——"保护口腔黏膜"的差异化卖点，但需教育市场 |
 **可行性分析**：
 - 石斛传统用途中"清咽利喉"心智成熟，《本草纲目》记载"强阴益精，厚肠胃"，咽喉保护是其衍生功效认知
 - 润喉糖属高频快消品，复购率高，与品斛堂现有电商渠道天然匹配
 - 金嗓子、王老吉等品牌占据主流，但"石斛润喉"细分赛道空白
 - 可通过OEM代工快速试水，无需自建生产线
 **推荐路径**：委托成熟润喉糖OEM工厂代工→自有品牌+电商测试→验证ROI后决定是否自建产能
 ### 5.2 植物基食品
 #### 5.2.1 市场规模与趋势
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 全球植物基食品市场（2026E） | 945亿美元，CAGR 12.24% | Straits Research [11] |
 | 全球植物基市场（2023→2033） | 113亿→355亿美元，CAGR 12.2% | DSM [12] |
 | 中国占全球植物基奶市场 | 34%（最大单一市场） | 艾媒 |
 | 植物基奶产品占植物基 | 54.65% | Straits [11] |
 | 中国现存植物基企业 | 8399家（截至2023.4），2017-2022新增1982家 | 力矩中国 |
 | Inova 2025趋势 | 55%消费者认为植物基应作为独立品类 |
 #### 5.2.2 具体产品评估
 | 产品 | 目标人群 | 价格带 | 预期毛利率 | 品斛堂匹配度 | 结论 |
 |------|----------|:---:|:---:|:---:|------|
 | 石斛植物奶 | 乳糖不耐受人群、健康饮品消费者 | ¥8-12/L | 35-45% | ⭐⭐ | **谨慎**——需要新建植物基产线，与现有核心能力差距大 |
 | 石斛豆腐 | 素食主义者、健康饮食人群 | ¥5.9-9.9/500g | 30-40% | ⭐ | **暂不推荐**——冷链依赖、区域性强、毛利率低 |
 **可行性分析**：
 - 植物基大方向正确，但品斛堂能力圈（原浆酶解+酿酒+提取）与植物基（植物蛋白结构重组、发酵工艺）匹配度不足
 - Oatly、维他奶等已占据植物奶主流心智，石斛切入需差异化定位（"石斛多糖+植物蛋白"组合）
 - 植物奶毛利率35-45%，与品斛堂现有原浆业务（60-70%）相比显著偏低
 - 2025年植物基赛道竞争者已超8000家，赛道拥挤度急剧上升
 **推荐路径**：
 - 植物奶：与现有植物基品牌（如Oatly）联名试水，而非自建产线
 - 石斛豆腐：属于区域型冷链产品，不适合品斛堂现有电商全国的渠道模型，**暂不推荐**
 ---
 ## 六、四维度横向对比与TOP5推荐
 ### 6.1 四维度综合评分
 | 维度 | 蓝帽子保健食品 | 普通功能食品 | 礼品礼盒 | 创新跨界 |
 |------|:---:|:---:|:---:|:---:|
 | 市场规模 | ⭐⭐⭐⭐ 2308亿 | ⭐⭐⭐⭐⭐ 3700亿 | ⭐⭐⭐⭐⭐ 1.45万亿 | ⭐⭐⭐⭐ 945亿美元 |
 | 增速 | ⭐⭐⭐ 6.9% | ⭐⭐⭐⭐ 12-15% | ⭐⭐⭐ 7% | ⭐⭐⭐⭐ 12.24% |
 | 合规门槛 | ⭐⭐⭐ 12-36个月 | ⭐⭐⭐⭐⭐ 无需审批 | ⭐⭐⭐⭐ 食品标准即可 | ⭐⭐⭐⭐⭐ 无需审批 |
 | 品斛堂匹配度 | ⭐⭐⭐⭐ 原料+资质 | ⭐⭐⭐⭐ 配方+渠道 | ⭐⭐⭐⭐⭐ 现有产品复用 | ⭐⭐ 需新建产能 |
 | 预期毛利率 | ⭐⭐⭐⭐⭐ 65-80% | ⭐⭐⭐⭐ 50-65% | ⭐⭐⭐⭐⭐ 55-70% | ⭐⭐ 35-50% |
 | 竞争壁垒 | ⭐⭐⭐⭐⭐ 审批+品牌 | ⭐⭐⭐ 成分差异化 | ⭐⭐⭐⭐⭐ 产地+品牌 | ⭐ 低壁垒 |
 | 落地速度 | ⭐ 慢 | ⭐⭐⭐⭐⭐ 快 | ⭐⭐⭐⭐⭐ 极快 | ⭐⭐⭐ 快 |
 ### 6.2 TOP5推荐详细说明
 #### 🥇 TOP1：石斛礼品礼盒体系化
 - **推荐理由**：品斛堂已具备礼盒产品基础（原浆礼盒¥900+、酒礼盒¥300-900），无需新增产线或审批。健康礼赠市场正处爆发早期，天猫健康礼盒成交年增40%+，石斛礼盒赛道尚未被头部品牌锁定。
 - **落地路径**：
  - 立即启动：包装设计升级（联名非遗IP/设计师），建立"入门→中端→高端"礼盒金字塔
  - 3个月内：首批节日限定礼盒上线（中秋礼盒先行）
  - 渠道：天猫健康礼赠会场+视频号礼赠营销+企业团购+线下药店
 - **关键成功因素**：包装设计=传播媒介；产地叙事=信任壁垒；多价格带覆盖=市场扩容
 - **预期年增量营收**：3000-5000万（首年，复用现有产品）
 #### 🥈 TOP2：石斛普通功能食品（胶原蛋白肽饮/益生菌软糖）
 - **推荐理由**：无需蓝帽子审批，3-6个月可上市，毛利率50-65%，石斛成分差异化明确。口服美容+益生菌双赛道年增15%+，"零食化养生"趋势强劲。
 - **落地路径**：
  - 胶原蛋白肽饮：委托OEM代工→自有品牌+电商首测→3个月内上市
  - 益生菌石斛软糖：抓住保健食品零食化趋势，软糖剂型吸引年轻消费者
  - 渠道：天猫+抖音+小红书内容种草
 - **关键成功因素**：成分差异化（石斛多糖复配）、剂型零食化、内容营销驱动
 - **预期年增量营收**：2000-4000万
 #### 🥉 TOP3：石斛蓝帽子保健食品（胃黏膜保护/增强免疫力）
 - **推荐理由**：长期壁垒最高（审批+品牌）、毛利率最高（65-80%）、品斛堂已具备三重生产资质+斑马鱼功效数据。2025年政策利好"重点品种优先审评审批"，蓝帽子批文可形成10年+的独占期壁垒。
 - **落地路径**：
  - 立即启动：注册制申报资料准备（配方定型+GLP毒理+功能学评价），预算300-500万
  - 同步推进：斑马鱼功效数据整理为SCI论文，增强学术背书
  - 12-36个月：获批后正式上市
 - **关键成功因素**：审批成功=独占壁垒；学术论文=品牌信任；全产业链=成本优势
 - **风险提示**：审批周期长且存在不确定性，注册成本300-500万
 - **预期年增量营收**：获批后首年3000-5000万，长期有望过亿
 #### ④ TOP4：石斛功能性润喉糖
 - **推荐理由**：石斛"清咽利喉"传统心智成熟，润喉糖市场80亿+，OEM代工可快速启动。高频快消品属性带来复购率，与电商渠道天然匹配。
 - **落地路径**：
  - 委托成熟润喉糖OEM工厂代工→自有品牌→电商+便利店测试
  - 3个月内首批上市
 - **关键成功因素**：包装年轻化、渠道铺货、口味优化
 - **预期年增量营收**：500-1500万
 - **风险**：金嗓子/王老吉主导市场，品牌突围需要差异化营销投入
 #### ⑤ TOP5：石斛植物基食品（联名试水）
 - **推荐理由**：全球植物基CAGR 12.24%，中国是最大植物基奶市场。石斛多糖+植物蛋白组合有差异化空间。
 - **落地路径**：与Oatly/维他奶等品牌联名→石斛植物奶→电商测试→根据市场反馈决定是否深入
 - **关键成功因素**：联名降低试错成本、植物基趋势红利
 - **预期年增量营收**：试水阶段500-1000万
 - **风险**：品斛堂植物基能力不足，自建产线ROI存疑，建议仅限联名试水
 ---
 ## 七、综合落地路线图
 | 时间线 | 行动 | 所需资源 | 预期成果 |
 |------|------|------|------|
 | **0-3个月** | ①礼盒包装升级+中秋礼盒上线 ②胶原蛋白肽饮OEM启动 ③润喉糖OEM启动 ④注册制申报准备启动 | 设计费50万+OEM试产费80万 | 3款新产品上市 |
 | **3-6个月** | ①春节礼盒预售 ②胶原蛋白肽饮正式上市 ③润喉糖上市 ④益生菌软糖启动 | OEM产能扩产100万 | 6款产品在售 |
 | **6-18个月** | ①礼盒体系化（全节日覆盖） ②蓝帽子注册资料提交 ③功能食品线扩展 | 注册费300-500万 | 形成完整产品矩阵 |
 | **18-36个月** | ①蓝帽子获批→正式上市 ②植物基联名试水 | 批文持有+营销投入 | 高壁垒护城河建成 |
 ---
 ## 八、数据来源与假设说明
 **数据来源**：
 1. [1] 中商产业研究院《2025-2030年中国保健食品深度分析及发展前景研究预测报告》
 2. [2] 新营养《2025年Q1保健食品行业全景解析》（2025.4.10）
 3. [3] 雪球/药食同源行业研报：2024年3800亿→2030年7500亿
 4. [4] 头豹《2025年营养健康行业词条报告》（2025.7.30）
 5. [5] 知乎专栏《2025年中国功能性食品行业年末深入盘点》
 6. [6] GMInsights《功能性食品市场规模及份额 2025-2034》
 7. [7] 美团/小红书用户行为数据
 8. [8] 艾媒咨询《中国礼物经济产业市场规模》
 9. [9] 天猫健康·TMIC《健康礼赠行业趋势白皮书》（2024）
 10. [10] 励展华博×凯度《2025年中国礼品行业展望白皮书》
 11. [11] Straits Research《植物基食品和饮料市场规模 2026-2034》
 12. [12] DSM全球植物基市场报告（2024）
 **关键假设**：
 - 保健食品市场增长率假设为6-8%，基于近3年平均增速
 - 礼盒毛利率假设基于品斛堂现有礼盒产品定价与行业均值
 - 蓝帽子审批周期假设基于2025年Q1实际审批节奏（Q1新注册116款）和国家市监局公开数据
 - 品斛堂年营收假设3-5亿元（基于BIZ-53情报调研）
 - 增量营收预测基于可触及市场（SAM）而非总可寻址市场（TAM）
 **置信区间**：
 - 市场规模数据：±5-10%（多源交叉验证）
 - 毛利率预测：±5%（行业对标+品斛堂现有产品毛利率反推）
 - 增量营收预测：±30%（首年试水阶段不确定性高）
 ---
 *报告完成于2026年6月26日 | 顾析策 | 分析事业部 | 市场分析师*
@@ -1,318 +0,0 @@
 # 石斛预制菜与调味品赛道切入可行性分析
 **分析日期**：2026年6月26日  
 **分析师**：顾析策（市场分析）  
 **关联议题**：BIZ-67（父议题：BIZ-53 品斛堂企业情报调研）
 ---
 ## 一、摘要
 **核心结论**：品斛堂当前阶段**不建议直接进入预制菜/调味品赛道**，建议采取"**观望+轻资产试水**"策略——优先以OEM模式试水石斛养生汤料包/石斛火锅底料，待市场验证后再决定是否加大投入。
 **关键数据**：
 - 中国调味品市场规模 6871 亿（2024），酱油品类 1041 亿；海天酱油市占率 13.2%
 - 中国预制菜市场规模 4850-6000 亿（2024），预计 2026 年达 7490-10720 亿
 - 预制菜行业毛利率仅 10-15%，CR10 仅 14%，7.2 万家企业高度碎片化
 - 药膳预制菜抖音电商 2023 年 1-9 月同比增长 605%，细分赛道高速增长
 **建议**：观望着手养生汤料包 OEM 试水，6-12 个月后根据销售数据决定下一步。
 ---
 ## 二、调味品赛道分析
 ### 2.1 市场规模与增长
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 2024 年调味品市场总规模 | 6871 亿元，YoY +16.0% | 艾媒咨询 2025H1 |
 | 2027 年调味品市场预测 | 10028 亿元 | 艾媒咨询 |
 | 2016-2023 CAGR | 10.12% | 华经产业研究院 |
 | 2024 年复合调味品市场 | 2301 亿元 | 艾媒咨询 |
 | 2024 年酱油市场（国内） | 1041 亿元 | 弗诺斯特沙利文 |
 | 2024 年菜谱式调味品 | 522 亿元，2027 年预计 1033 亿 | 艾媒咨询 |
 | 酱油 CAGR（2019-2024） | 2.6%，预测 2024-2029 为 4.8% | 弗诺斯特沙利文 |
 **判断**：调味品市场稳健增长但已进入**存量竞争**阶段，基础调味品增速放缓，复合调味品是增量来源。
 ### 2.2 竞争格局
 | 排名 | 企业 | 整体市占率（2024） | 核心品类 | 2024 年营收 |
 |:---:|------|:---:|------|------|
 | 1 | 海天味业 | 4.8% | 酱油（13.2%）/蚝油（40.2%）/酱类 | ~269 亿 |
 | 2 | 阜丰集团 | 1.4% | 味精/氨基酸 | — |
 | 3 | 李锦记 | ~1.4% | 酱油/蚝油/酱类 | 非上市 |
 | — | 中炬高新（美味鲜） | — | 酱油第二 | ~30 亿 |
 | — | 千禾味业 | — | 高端酱油 | ~20 亿 |
 | — | 天味食品 | — | 火锅底料/中式复调 | 31.5 亿（2023） |
 **关键发现**：
 - **寡头格局已形成**：海天+李锦记+中炬高新占据酱油市场头部，海天渠道下沉至乡镇
 - **酱油价格战白热化**：9.9 元/L 特级酱油已成常态，新品牌突围极难
 - **"零添加"标签被禁**：2025 年 3 月新国标（GB 7718-2025）规定 2027 年起禁标"零添加""不添加"，对差异化新品牌构成政策风险
 ### 2.3 石斛调味品可行性评估
 #### 石斛酱油
 - **对标现状**：海天酱油 2025 年营收 149 亿，市占率 13.2%，规模效应碾压级
 - **差异化空间**：极小。酱油消费者核心决策因素为"品牌+价格+口味"，"养生"属性在酱油品类中尚未成为主流需求
 - **品斛堂劣势**：无酿造产能、无渠道、无品牌认知、远离大豆主产区（云南非大豆产区）
 - **成本劣势**：石斛添加推高成本，终端定价可能在 19.9-29.9 元/500ml，而主流酱油 9.9 元/L，价格差 2-3 倍
 #### 石斛火锅底料
 - **对标现状**：海底捞（颐海国际）、天味食品（好人家）、德庄、红九九
 - **差异化空间**：中等。"不上火"概念在火锅场景有消费者感知，石斛+云南菌菇/酸汤可打造"云南养生火锅"概念
 - **机会点**：复合调味品增速 13%+，CR 低，OEM 进入门槛低于酱油
 - **品斛堂劣势**：无火锅底料研发经验，口味研发需外部合作
 ### 2.4 调味品切入评分：★★☆☆☆（2/5）
 | 维度 | 评分 | 说明 |
 |------|:---:|------|
 | 市场规模 | 4/5 | 6871 亿大市场，复合调味品增长快 |
 | 竞争强度 | 1/5 | 寡头格局，酱油价格战，新品牌生存空间极小 |
 | 品斛堂匹配度 | 2/5 | 有原料优势但无生产/渠道/品牌能力 |
 | 差异化空间 | 2/5 | 火锅底料有"养生"概念空间，酱油基本没有 |
 | 进入门槛 | 2/5 | 酱油需酿造产能（重资产），火锅底料可 OEM（轻资产） |
 | 盈利预期 | 2/5 | 头部企业净利率 15-20%，新品可能需要 2-3 年培育 |
 ---
 ## 三、预制菜赛道分析
 ### 3.1 市场规模与增长
 | 指标 | 数据 | 来源 |
 |------|------|------|
 | 2022 年市场规模 | 4196 亿元，YoY +21.3% | 艾媒咨询 |
 | 2023 年市场规模 | 5165 亿元 | 艾媒/人民网研究院 |
 | 2024 年市场规模 | 4850-6000+ 亿元 | 艾媒蓝皮书（4850）/新华网（6000+） |
 | 2026 年预测 | 7490-10720 亿元 | 艾媒蓝皮书/早期预测 |
 | 全球预制食品市场（2025） | 3981 亿美元→2030 年 5316 亿美元，CAGR 6% | Statista |
 | B:C 端比例 | 约 7:3（B 端仍为主力） | 嘉世咨询 |
 | 渗透率 | 10-15%（美/日 60%+） | 艾媒/中国连锁餐饮报告 |
 | 企业数量 | 7.2 万+ 家 | 天眼查/企查查 |
 | 连锁化率驱动 | 2023 年餐饮连锁化率约 21%（美 54%/日 48%） | 中国连锁餐饮报告 |
 **判断**：预制菜是确定性强的万亿赛道，但当前已从"野蛮生长"进入"规范整合"阶段。
 ### 3.2 竞争格局
 #### 四类玩家错位竞争
 | 类型 | 代表企业 | 优势 | 劣势 | 毛利率 |
 |------|------|------|------|:---:|
 | **上游农牧水产** | 国联水产、龙大美食、新希望 | 原料成本优势、规模化 | C 端品牌力弱 | 10-15% |
 | **传统速冻食品** | 安井食品、三全、千味央厨 | 规模化生产、渠道分销强 | B 端定制弱 | 25-30% |
 | **专业预制菜** | 味知香、蒸烩煮、聪厨 | 经验丰富、研发能力强 | 规模小、区域性强 | 25-30% |
 | **餐饮/零售** | 西贝、盒马、广州酒家、海底捞 | C 端品牌强、终端直连 | 渠道单一、自建中央厨房成本高 | 10-15% |
 **关键发现**：
 - **行业高度分散**：CR10 仅 14%，无全国性龙头
 - **毛利率普遍偏低**：安井预制菜毛利率从 29.7%（2018）降至 11.4%（2022）
 - **同质化严重**：酸菜鱼、佛跳墙、小龙虾是最大单品，企业扎堆
 - **70% 企业为作坊式**：产品标准缺失，食品安全风险大
 ### 3.3 石斛预制菜可行性评估
 #### 石斛炖鸡/排骨汤预制菜
 - **对标**：盒马（鲜食预制菜）、西贝（贾国龙功夫菜）、海底捞（预制菜线）
 - **差异化定位**："养生药膳预制菜"——区别于市面主流的麻辣/酸辣类
 - **理论优势**：石斛的"养生"心智 + 鸡汤的国民认知度 + 药膳文化底蕴
 - **实际挑战**：
  - 养生预制菜目前仍是极小众品类，主流消费者预制菜核心诉求是"便捷+好吃"而非"养生"
  - 药膳预制菜需要兼顾"功效"与"口味"，研发难度远超普通预制菜
  - "药膳"的保健功能宣传在合规层面存在极大风险（普通食品不得宣称保健功能）
 #### 药膳预制菜市场信号（正面）
 - 抖音电商 2023 年 1-9 月药膳类预制菜销售额同比增长 605%
 - 温氏食品+昆中药推出参苓鸡系列
 - 磐安"盘安药膳"推出黄精肉、玉竹老鸭等产品
 - 广州酒家推出人参老鸭汤、人参益智仁乌鸡汤
 - **但注意**：这些均为大企业试水或区域特色产品，尚未出现药膳预制菜爆品
 ### 3.4 预制菜切入评分：★★☆☆☆（2/5）
 | 维度 | 评分 | 说明 |
 |------|:---:|------|
 | 市场规模 | 5/5 | 万亿级赛道，增速 20%+ |
 | 竞争强度 | 2/5 | 高度碎片化、同质化，价格战正在蔓延 |
 | 品斛堂匹配度 | 1/5 | 无生产经验、无冷链、无渠道、远离消费市场 |
 | 差异化空间 | 3/5 | "养生药膳预制菜"有独特定位，但品类尚未验证 |
 | 进入门槛 | 2/5 | 冷链物流+口味研发+渠道建设均需重投入 |
 | 盈利预期 | 1/5 | 头部企业毛利率仅 10-15%，新品培育期可能长期亏损 |
 ---
 ## 四、品斛堂匹配度总体评估
 ### 4.1 优劣势对比
 | 优势 | 劣势 |
 |------|------|
 | ✅ 石斛原料自供，全产业链成本可控 | ❌ **无预制菜/调味品生产经验** |
 | ✅ 食品生产资质齐全（药品+保健食品+食品） | ❌ **无冷链仓储和配送网络** |
 | ✅ OEM/ODM 服务经验（服务近 100 家企业） | ❌ **地处云南龙陵，远离核心消费市场** |
 | ✅ "养生"品牌心智（石斛原浆第一品牌） | ❌ **销售渠道以线上为主，线下商超/便利店覆盖弱** |
 | ✅ 云南地方特色食材资源（菌菇/酸汤等） | ❌ **预制菜和调味品研发团队缺失** |
 | ✅ 石斛多糖等原料可赋能产品差异化 | ❌ **调味品口味研发能力为零（酱油/火锅底料均需专业研发）** |
 ### 4.2 风险矩阵
 | 风险类型 | 具体描述 | 严重程度 | 发生概率 |
 |------|------|:---:|:---:|
 | **市场风险** | 预制菜/调味品竞争白热化，新品牌存活率低 | 🔴 高 | 🔴 高 |
 | **运营风险** | 缺乏冷链物流和生产经验，产品质量难以保证 | 🔴 高 | 🔴 高 |
 | **财务风险** | 毛利率极低（10-15%），初期投入大、回收慢 | 🟡 中 | 🔴 高 |
 | **合规风险** | "养生药膳"概念在食品宣传中触碰《广告法》红线 | 🔴 高 | 🟡 中 |
 | **品牌风险** | 预制菜若出食品安全问题，反噬石斛原浆主品牌 | 🔴 高 | 🟡 中 |
 ---
 ## 五、三种切入路径对比
 ### 路径 A：轻资产 OEM 试水（推荐指数：★★★★☆）
 | 维度 | 详情 |
 |------|------|
 | **方式** | 与成熟预制菜/调味品代工厂合作，品斛堂提供石斛原料+品牌+渠道 |
 | **首推产品** | ① 石斛菌菇养生汤料包（常温/冷冻） ② 石斛云南酸汤火锅底料 |
 | **启动资金** | 300-500 万元（含研发费+首批生产+包装设计+渠道推广） |
 | **时间线** | 3-6 个月产品上市，12 个月验证期 |
 | **主要风险** | 品控依赖代工厂；利润被代工费挤压；产品差异化不够 |
 | **退出成本** | 低——可随时停止而不影响主营业务 |
 ### 路径 B：战略合作/合资（推荐指数：★★★☆☆）
 | 维度 | 详情 |
 |------|------|
 | **方式** | 与云南本地餐饮集团或预制菜企业成立合资公司，共同开发云南药膳预制菜 |
 | **首推产品** | 石斛汽锅鸡预制菜、石斛菌汤包、云南过桥米线石斛汤底 |
 | **启动资金** | 1000-2000 万元（含合资公司注册+产线改造+冷链建设） |
 | **时间线** | 6-12 个月产品上市，18-24 个月盈亏平衡 |
 | **主要风险** | 合作伙伴选择失误；利益分配冲突；管理复杂度高 |
 | **退出成本** | 中——合资公司清算或股权转让 |
 ### 路径 C：自建产线重资产进入（推荐指数：★☆☆☆☆）
 | 维度 | 详情 |
 |------|------|
 | **方式** | 在龙陵或昆明自建预制菜中央厨房/调味品生产线 |
 | **首推产品** | 全系列石斛预制菜+石斛调味品 |
 | **启动资金** | 5000 万-1 亿元（含厂房+设备+冷链物流+团队+渠道） |
 | **时间线** | 18-24 个月产品上市，36-48 个月盈亏平衡 |
 | **主要风险** | 资金压力大；产能利用率不足；远离消费市场导致冷链成本高 |
 | **退出成本** | 极高——固定资产沉没，转型困难 |
 | **当前阶段** | **强烈不建议** |
 ### 三路径对照总结
 | 维度 | 路径 A OEM 试水 | 路径 B 战略合作 | 路径 C 重资产自建 |
 |------|:---:|:---:|:---:|
 | 启动资金 | 300-500 万 | 1000-2000 万 | 5000 万-1 亿 |
 | 上市时间 | 3-6 个月 | 6-12 个月 | 18-24 个月 |
 | 盈亏平衡 | 6-12 个月 | 18-24 个月 | 36-48 个月 |
 | 风险等级 | 低 | 中 | 极高 |
 | 可控性 | 中 | 中高 | 高 |
 | 利润空间 | 低（代工费挤压） | 中（合资分成） | 中高（规模效应后） |
 | 推荐指数 | ★★★★☆ | ★★★☆☆ | ★☆☆☆☆ |
 ---
 ## 六、预期投入与回报周期（路径 A）
 | 项目 | 明细 | 金额（万元） |
 |------|------|:---:|
 | **一次性投入** | | |
 | 产品研发（汤料/火锅底料配方+石斛添加比例测试+保质期验证） | 外部研发合作 | 50-80 |
 | 包装设计（品牌视觉+包材+首批印刷） | 设计+模具 | 30-50 |
 | 首批生产（最小起订量，含石斛原料成本） | 3-5 个 SKU | 100-150 |
 | 渠道铺设（线上详情页+达播合作+线下试销进场费） |  | 50-80 |
 | **一次性投入合计** | | **230-360 万** |
 | **月度运营** | | |
 | 线上运营（投流+平台佣金+团队） | 月均 | 20-40 |
 | 线下促销/试吃/陈列费 | 月均 | 10-20 |
 | **首年总投入** | | **约 500-700 万** |
 | 时间节点 | 里程碑 | 预期表现 |
 |------|------|------|
 | 第 3 个月 | 产品上市（天猫/抖音首发） | 月销 10-20 万 |
 | 第 6 个月 | 首轮数据验证 | 月销 30-50 万，复购率 > 15% → 继续投入 |
 | 第 12 个月 | Go/No-Go 决策 | 月销 100 万+ → 考虑路径 B；< 30 万 → 停项目 |
 ---
 ## 七、最终建议
 ### 🟡 总体判断：**观望**
 **进入** ❌  
 **观望** ✅（选择此项）  
 **放弃** ❌
 ### 核心理由
 1. **预制菜/调味品均处于格局剧变期**：预制菜国家标准正在制定中，行业即将洗牌；调味品"零添加"禁令 2027 年全面生效，整个行业的产品和营销逻辑都在重构。此时贸然进入意味着在不确定的规则下做重投入决策。
 2. **品斛堂的核心能力与预制菜/调味品的核心要求不匹配**：
   - 预制菜的核心竞争力 = **冷链物流网络 + 口味研发 + 渠道效率 + 成本控制**
   - 调味品的核心竞争力 = **酿造产能 + 品牌认知 + 百万终端覆盖 + 规模效应**
   - 品斛堂的核心优势 = **石斛全产业链 + 原浆品类开创者 + 线上电商运营**
   - 这三个集合的交集非常小
 3. **资源应该聚焦核心战场**：
   - 石斛原浆市场规模 120 亿，品斛堂市占率 45%+，还有 55%+ 的空间
   - 复合原浆是第二增长曲线，增速 25%+，且与现有能力高度匹配
   - 保健品蓝帽子注册是高毛利壁垒型业务（毛利率 60-80%）
   - 这些机会的投入产出比远高于预制菜/调味品
 4. **但不应完全放弃——可以"轻试水"**：
   - 石斛养生汤料包和火锅底料可以极低成本试水（路径 A，300-500 万）
   - 利用现有天猫/京东/抖音渠道做首发，不用新建渠道
   - 本质上是将石斛原料以"汤料包"形式触达消费者
   - 12 个月后根据数据决定是继续还是止损
 ### 行动建议
 | 优先级 | 行动 | 时间 |
 |:---:|------|------|
 | P0 | 保持预制菜/调味品赛道月度舆情监控 | 即刻开始 |
 | P1 | 石斛菌菇养生汤料包 OEM 试水立项（路径 A） | 下季度 |
 | P2 | 调研云南本地预制菜合作伙伴（路径 B 前期） | 6 个月后 |
 | P3 | 关注预制菜国家标准出台后的行业洗牌窗口 | 持续跟踪 |
 ---
 ## 八、数据来源与假设说明
 ### 主要数据来源
 | 编号 | 来源 | 数据类型 | 时效 |
 |:---:|------|------|:---:|
 | [1] | 艾媒咨询《2023-2025 年中国预制菜行业运行及投资决策分析报告》 | 预制菜市场规模/格局 | 2024 |
 | [2] | 艾媒咨询《2024-2025 年中国预制菜产业发展蓝皮书》 | 预制菜市场最新数据 | 2025 |
 | [3] | 艾媒咨询《2025 年 H1 中国调味品行业运行数据监测半年报》 | 调味品市场数据 | 2025 |
 | [4] | 华经产业研究院《中国复合调味品行业发展现状》 | 复合调味品市场规模 | 2024 |
 | [5] | 弗诺斯特沙利文 | 酱油市场数据 | 2024-2025 |
 | [6] | 嘉世咨询《2025 年中国调味品行业报告》 | 调味品竞争格局 | 2025 |
 | [7] | 新华网/中国商报 | 预制菜企业数量/国家标准进展 | 2025 |
 | [8] | 华鑫证券/平安证券预制菜行业研报 | 预制菜供应链/竞争分析 | 2023-2024 |
 | [9] | 灼识咨询《2022 中国预制菜行业蓝皮书》 | 竞争格局 | 2022 |
 | [10] | FDL 数食主张《药膳预制菜》 | 药膳预制菜趋势 | 2023 |
 | [11] | 抖音电商数据（引用自食品伙伴网） | 药膳预制菜增长 | 2023 |
 | [12] | 品斛堂企业调研报告（BIZ-53） | 品斛堂企业情报 | 2026.06 |
 | [13] | 石斛食品饮料全品类产品方向详细文档 | 参考产品规划 | 2026 |
 ### 关键假设
 - 2026 年预制菜市场规模取艾媒蓝皮书 7490 亿（较保守口径）
 - 品斛堂参考文档中预制菜/调味品毛利预期 30-50%，本报告校正为更保守的 10-25%（基于上市公司实际数据）
 - 药膳预制菜"增速数据（605%）基于抖音电商单一渠道，不代表全渠道增速
 - 投资金额估算为行业平均水平参考值，实际可能因合作伙伴、地区政策等因素而浮动
 - 石斛火锅底料的"不上火"概念为市场假设，需通过消费者调研验证
 ---
 *本报告仅供内部决策参考，不构成对外投资建议。*  
 *数据截止日期：2026 年 6 月 26 日*
@@ -0,0 +1,772 @@
 """
 BIZ-26: API 请求优先级队列 + 令牌桶限流器
 实现方案参考：plans/BIZ-13_运行稳定性保障方案.md
 功能清单：
 1. 四级优先级请求队列（紧急 > 高 > 正常 > 低）
 2. 令牌桶限流器（40 RPM 上限）
 3. 超限自动降级和等待策略
 4. 请求合并（COO 统一轮询）
 5. 查询结果缓存（WorkBoard 5 分钟、配置 1 小时、知识库 1 天）
 作者：徐聪（costcodev）
 日期：2026-06-23
 """
 import time
 import threading
 import queue
 import hashlib
 import json
 from typing import Any, Callable, Dict, List, Optional, Tuple
 from dataclasses import dataclass, field
 from enum import IntEnum
 from datetime import datetime, timedelta
 # ============================================================================
 # 网关识别：只对 NVIDIA 网关限流
 # ============================================================================
 NVIDIA_GATEWAY_ALIASES = {
    "nvidia",
    "nvidia-gateway",
    "nvidia_gateway",
    "nvidiavx18088980513",
 }
 UNLIMITED_GATEWAY_ALIASES = {
    "volcengine",
    "volcengine-plan",
    "siliconflow",
    "deepseek",
    "deepseek-api",
 }
 def normalize_gateway_name(value: Optional[str]) -> Optional[str]:
    """
    归一化网关/模型名称。
    输入可以是：
    - provider: nvidia / volcengine-plan / siliconflow / deepseek
    - model: nvidiavx18088980513/deepseek-ai/deepseek-v4-pro
    - model: volcengine-plan/ark-code-latest
    返回 provider 前缀的小写形式。未知则返回 None。
    """
    if not value:
        return None
    text = str(value).strip().lower()
    if not text:
        return None
    return text.split("/", 1)[0]
 def is_nvidia_gateway(value: Optional[str]) -> bool:
    """判断请求是否走 NVIDIA 网关。未知网关默认不限流。"""
    provider = normalize_gateway_name(value)
    if provider is None:
        return False
    if provider in NVIDIA_GATEWAY_ALIASES:
        return True
    if provider in UNLIMITED_GATEWAY_ALIASES:
        return False
    return provider.startswith("nvidia")
 # ============================================================================
 # 优先级枚举
 # ============================================================================
 class Priority(IntEnum):
    """请求优先级：数值越小优先级越高"""
    URGENT = 1      # 紧急：Vincent 直接任务
    HIGH = 2        # 高：阻塞性任务
    NORMAL = 3      # 正常：常规任务
    LOW = 4         # 低：后台优化任务
 # ============================================================================
 # 请求数据类
 # ============================================================================
@dataclass(order=True)
 class Request:
    """优先级队列中的请求项"""
    priority: int
    timestamp: float = field(compare=False)
    request_id: str = field(compare=False)
    payload: Any = field(compare=False)
    callback: Optional[Callable] = field(compare=False, default=None)
    fallback_model: Optional[str] = field(compare=False, default=None)
    gateway: Optional[str] = field(compare=False, default=None)
    model: Optional[str] = field(compare=False, default=None)
    def __post_init__(self):
        if self.timestamp is None:
            self.timestamp = time.time()
        if self.request_id is None:
            self.request_id = self._generate_id()
    @staticmethod
    def _generate_id() -> str:
        """生成请求 ID"""
        return hashlib.md5(f"{time.time()}-{threading.current_thread().ident}".encode()).hexdigest()[:12]
 # ============================================================================
 # 令牌桶限流器
 # ============================================================================
 class TokenBucket:
    """
    NVIDIA 网关专用令牌桶限流器
    注意：令牌桶本身只负责节流算法；是否启用由 RequestScheduler._should_rate_limit()
    按 gateway/model 判断。volcengine-plan、siliconflow、DeepSeek 等非 NVIDIA 网关不会进入此桶。
    参数：
        rate: 令牌生成速率（个/秒），默认 40 RPM = 0.67 个/秒
        capacity: 桶容量（最大令牌数），默认 40
    """
    def __init__(self, rate: float = 40/60, capacity: int = 40):
        self.rate = rate  # 令牌/秒
        self.capacity = capacity
        self.tokens = capacity
        self.last_update = time.time()
        self._lock = threading.Lock()
    def _refill(self) -> None:
        """补充令牌（内部调用，需要持有锁）"""
        now = time.time()
        elapsed = now - self.last_update
        new_tokens = elapsed * self.rate
        self.tokens = min(self.capacity, self.tokens + new_tokens)
        self.last_update = now
    def consume(self, tokens: int = 1) -> bool:
        """
        尝试消费令牌
        返回：
            True: 成功消费
            False: 令牌不足
        """
        with self._lock:
            self._refill()
            if self.tokens >= tokens:
                self.tokens -= tokens
                return True
            return False
    def wait_for_token(self, timeout: Optional[float] = None) -> bool:
        """
        等待直到有可用令牌
        参数：
            timeout: 最大等待时间（秒），None 表示无限等待
        返回：
            True: 成功获取令牌
            False: 超时
        """
        start_time = time.time()
        while True:
            if self.consume():
                return True
            if timeout is not None:
                elapsed = time.time() - start_time
                if elapsed >= timeout:
                    return False
            # 计算等待时间（直到下一个令牌生成）
            with self._lock:
                self._refill()
                if self.tokens < 1:
                    wait_time = (1 - self.tokens) / self.rate
                else:
                    wait_time = 0.01
            # 等待后重试
            time_to_wait = min(wait_time, 0.1)  # 最多等待 100ms
            if timeout is not None:
                remaining = timeout - (time.time() - start_time)
                if remaining <= 0:
                    return False
                time_to_wait = min(time_to_wait, remaining)
            time.sleep(time_to_wait)
    def get_status(self) -> Dict[str, Any]:
        """获取限流器状态"""
        with self._lock:
            self._refill()
            return {
                "tokens": round(self.tokens, 2),
                "capacity": self.capacity,
                "rate_per_second": round(self.rate, 3),
                "rate_per_minute": round(self.rate * 60, 1),
                "utilization": round(1 - self.tokens / self.capacity, 2)
            }
 # ============================================================================
 # 缓存管理器
 # ============================================================================
@dataclass
 class CacheEntry:
    """缓存条目"""
    value: Any
    expires_at: float
    created_at: float = field(default_factory=time.time)
    access_count: int = field(default=0)
 class CacheManager:
    """
    查询结果缓存管理器
    缓存策略：
    - WorkBoard 状态：5 分钟
    - Agent 配置：1 小时
    - 知识库内容：1 天
    - 用户信息：1 天
    """
    # 默认 TTL 配置（秒）
    DEFAULT_TTL = {
        "workboard": 5 * 60,        # 5 分钟
        "config": 1 * 60 * 60,      # 1 小时
        "knowledge": 24 * 60 * 60,  # 1 天
        "user": 24 * 60 * 60,       # 1 天
    }
    def __init__(self):
        self._cache: Dict[str, CacheEntry] = {}
        self._lock = threading.Lock()
    def _generate_key(self, category: str, query: Any) -> str:
        """生成缓存键"""
        query_str = json.dumps(query, sort_keys=True) if not isinstance(query, str) else query
        return hashlib.md5(f"{category}:{query_str}".encode()).hexdigest()
    def get(self, category: str, query: Any) -> Optional[Any]:
        """
        获取缓存
        参数：
            category: 缓存类别（workboard/config/knowledge/user）
            query: 查询条件（用于生成缓存键）
        返回：
            缓存值，如果不存在或已过期则返回 None
        """
        key = self._generate_key(category, query)
        with self._lock:
            entry = self._cache.get(key)
            if entry is None:
                return None
            # 检查是否过期
            if time.time() > entry.expires_at:
                del self._cache[key]
                return None
            # 更新访问计数
            entry.access_count += 1
            return entry.value
    def set(self, category: str, query: Any, value: Any, ttl: Optional[int] = None) -> None:
        """
        设置缓存
        参数：
            category: 缓存类别
            query: 查询条件
            value: 缓存值
            ttl: 存活时间（秒），None 表示使用默认值
        """
        key = self._generate_key(category, query)
        if ttl is None:
            ttl = self.DEFAULT_TTL.get(category, 300)  # 默认 5 分钟
        with self._lock:
            self._cache[key] = CacheEntry(
                value=value,
                expires_at=time.time() + ttl
            )
    def delete(self, category: str, query: Any) -> bool:
        """删除缓存"""
        key = self._generate_key(category, query)
        with self._lock:
            if key in self._cache:
                del self._cache[key]
                return True
            return False
    def clear_expired(self) -> int:
        """清理所有过期缓存，返回清理数量"""
        now = time.time()
        with self._lock:
            expired_keys = [k for k, v in self._cache.items() if now > v.expires_at]
            for key in expired_keys:
                del self._cache[key]
            return len(expired_keys)
    def get_stats(self) -> Dict[str, Any]:
        """获取缓存统计"""
        now = time.time()
        with self._lock:
            total = len(self._cache)
            expired = sum(1 for v in self._cache.values() if now > v.expires_at)
            # 按类别统计
            by_category: Dict[str, int] = {}
            for key, entry in self._cache.items():
                # 从 key 中提取 category（格式：category:hash）
                category = key.split(":")[0] if ":" in key else "unknown"
                by_category[category] = by_category.get(category, 0) + 1
            return {
                "total_entries": total,
                "expired_entries": expired,
                "valid_entries": total - expired,
                "by_category": by_category
            }
    def clear(self) -> None:
        """清空所有缓存"""
        with self._lock:
            self._cache.clear()
 # ============================================================================
 # 请求调度器
 # ============================================================================
 class RequestScheduler:
    """
    请求调度器：结合优先级队列和令牌桶限流
    功能：
    1. 接收不同优先级的请求
    2. 按优先级和 FIF0 顺序调度
    3. 通过令牌桶控制发送速率
    4. 支持降级策略（低优先级切备用模型）
    """
    def __init__(
        self,
        rate: float = 40/60,
        capacity: int = 40,
        enable_cache: bool = True
    ):
        self.token_bucket = TokenBucket(rate=rate, capacity=capacity)
        self.cache = CacheManager() if enable_cache else None
        # 优先级队列（使用 heap 实现）
        self.request_queue: queue.PriorityQueue[Request] = queue.PriorityQueue()
        # 工作线程
        self._worker_thread: Optional[threading.Thread] = None
        self._running = False
        self._lock = threading.Lock()
        # 统计信息
        self.stats = {
            "total_requests": 0,
            "completed_requests": 0,
            "failed_requests": 0,
            "fallback_requests": 0,
            "cache_hits": 0,
            "cache_misses": 0,
        }
    def start(self) -> None:
        """启动调度器工作线程"""
        if self._running:
            return
        self._running = True
        self._worker_thread = threading.Thread(target=self._worker_loop, daemon=True)
        self._worker_thread.start()
    def stop(self) -> None:
        """停止调度器"""
        self._running = False
        if self._worker_thread:
            self._worker_thread.join(timeout=5.0)
    def _worker_loop(self) -> None:
        """工作线程主循环"""
        while self._running:
            try:
                # 从队列获取请求（带超时）
                request = self.request_queue.get(timeout=1.0)
                self._process_request(request)
            except queue.Empty:
                continue
            except Exception as e:
                # 记录错误但不中断工作线程
                print(f"[RequestScheduler] Worker error: {e}")
    def _extract_gateway_hint(self, request: Request) -> Optional[str]:
        """从 request.gateway / request.model / payload 中提取网关提示。"""
        if request.gateway:
            return request.gateway
        if request.model:
            return request.model
        if isinstance(request.payload, dict):
            for key in ("gateway", "provider", "model", "model_id"):
                value = request.payload.get(key)
                if value:
                    return str(value)
        return None
    def _should_rate_limit(self, request: Request) -> bool:
        """
        只对 NVIDIA 网关请求启用令牌桶。
        设计原则：未知网关默认不限制，避免误伤 volcengine-plan / siliconflow / DeepSeek
        等其他 API 网关。要被限流，调用方必须显式传 gateway/model，且能识别为 NVIDIA。
        """
        return is_nvidia_gateway(self._extract_gateway_hint(request))
    def _process_request(self, request: Request) -> None:
        """
        处理单个请求
        策略：
        1. 高优先级（URGENT/HIGH）：等待令牌
        2. 低优先级（NORMAL/LOW）：尝试获取令牌，失败则降级或丢弃
        """
        self.stats["total_requests"] += 1
        # 只对 NVIDIA 网关请求启用令牌桶；其他网关直接执行
        if not self._should_rate_limit(request):
            self._execute_request(request)
            return
        # NVIDIA 网关请求：尝试获取令牌
        if request.priority <= Priority.HIGH:
            # 高优先级：无限等待
            got_token = self.token_bucket.wait_for_token(timeout=None)
        else:
            # 低优先级：最多等待 2 秒
            got_token = self.token_bucket.wait_for_token(timeout=2.0)
        if got_token:
            # 成功获取令牌，执行请求
            self._execute_request(request)
        else:
            # 未能获取令牌，执行降级策略
            self._handle_fallback(request)
    def _execute_request(self, request: Request) -> None:
        """执行请求"""
        try:
            if request.callback:
                result = request.callback(request.payload)
                self.stats["completed_requests"] += 1
                return result
            else:
                self.stats["completed_requests"] += 1
        except Exception as e:
            self.stats["failed_requests"] += 1
            print(f"[RequestScheduler] Request {request.request_id} failed: {e}")
            raise
    def _handle_fallback(self, request: Request) -> None:
        """处理降级（令牌不足）"""
        self.stats["fallback_requests"] += 1
        if request.priority == Priority.LOW:
            # 低优先级：直接丢弃或切换到备用模型
            print(f"[RequestScheduler] Low priority request {request.request_id} dropped due to rate limit")
        else:
            # 正常优先级：放回队列稍后重试
            request.timestamp = time.time()
            self.request_queue.put(request)
    def submit(
        self,
        payload: Any,
        priority: Priority = Priority.NORMAL,
        callback: Optional[Callable] = None,
        fallback_model: Optional[str] = None,
        request_id: Optional[str] = None,
        gateway: Optional[str] = None,
        model: Optional[str] = None
    ) -> str:
        """
        提交请求到调度队列
        参数：
            payload: 请求数据
            priority: 优先级
            callback: 回调函数
            fallback_model: 备用模型名称
            request_id: 请求 ID（可选，默认自动生成）
        返回：
            请求 ID
        """
        req = Request(
            priority=priority,
            timestamp=time.time(),
            request_id=request_id,
            payload=payload,
            callback=callback,
            fallback_model=fallback_model,
            gateway=gateway,
            model=model
        )
        self.request_queue.put(req)
        return req.request_id
    def submit_sync(
        self,
        payload: Any,
        priority: Priority = Priority.NORMAL,
        timeout: Optional[float] = None
    ) -> Any:
        """
        同步提交并等待结果
        参数：
            payload: 请求数据
            priority: 优先级
            timeout: 超时时间（秒）
        返回：
            请求结果
        """
        result_holder = {"result": None, "error": None, "done": False}
        condition = threading.Condition()
        def callback(data):
            with condition:
                try:
                    # 实际执行逻辑（这里只是一个占位符）
                    result_holder["result"] = data
                except Exception as e:
                    result_holder["error"] = e
                finally:
                    result_holder["done"] = True
                    condition.notify_all()
        # 提交请求
        self.submit(payload=payload, priority=priority, callback=lambda _: callback(payload))
        # 等待结果
        with condition:
            if not result_holder["done"]:
                condition.wait(timeout=timeout)
        if result_holder["error"]:
            raise result_holder["error"]
        return result_holder["result"]
    def get_queue_size(self) -> int:
        """获取当前队列大小"""
        return self.request_queue.qsize()
    def get_status(self) -> Dict[str, Any]:
        """获取调度器状态"""
        return {
            "running": self._running,
            "queue_size": self.get_queue_size(),
            "token_bucket": self.token_bucket.get_status(),
            "cache": self.cache.get_stats() if self.cache else None,
            "stats": self.stats.copy()
        }
 # ============================================================================
 # 重试装饰器
 # ============================================================================
 def retry_with_backoff(
    max_retries: int = 3,
    base_delay: float = 1.0,
    exponential_base: int = 2,
    jitter: bool = True,
    exceptions: Tuple = (Exception,)
 ):
    """
    指数退避重试装饰器
    参数：
        max_retries: 最大重试次数
        base_delay: 基础延迟（秒）
        exponential_base: 指数底数
        jitter: 是否添加随机抖动
        exceptions: 需要重试的异常类型
    """
    import random
    def decorator(func: Callable) -> Callable:
        def wrapper(*args, **kwargs):
            last_exception = None
            for attempt in range(max_retries + 1):
                try:
                    return func(*args, **kwargs)
                except exceptions as e:
                    last_exception = e
                    if attempt == max_retries:
                        break
                    # 计算延迟时间
                    delay = base_delay * (exponential_base ** attempt)
                    if jitter:
                        delay += random.uniform(0, base_delay)
                    print(f"[retry_with_backoff] Attempt {attempt + 1} failed: {e}. Retrying in {delay:.2f}s...")
                    time.sleep(delay)
            raise last_exception
        return wrapper
    return decorator
 # ============================================================================
 # COO 统一轮询器（请求合并）
 # ============================================================================
 class CoordinatedPoller:
    """
    COO 统一轮询器：替代各 Agent 独立轮询
    功能：
    1. 定期轮询 WorkBoard
    2. 广播结果给所有订阅者
    3. 减少总请求数（40 RPM × N → 40 RPM）
    """
    def __init__(self, scheduler: RequestScheduler, poll_interval: int = 15*60):
        self.scheduler = scheduler
        self.poll_interval = poll_interval  # 轮询间隔（秒）
        self._subscribers: List[Callable] = []
        self._running = False
        self._worker: Optional[threading.Thread] = None
    def subscribe(self, callback: Callable) -> None:
        """订阅轮询结果"""
        self._subscribers.append(callback)
    def unsubscribe(self, callback: Callable) -> None:
        """取消订阅"""
        if callback in self._subscribers:
            self._subscribers.remove(callback)
    def start(self) -> None:
        """启动轮询器"""
        if self._running:
            return
        self._running = True
        self._worker = threading.Thread(target=self._poll_loop, daemon=True)
        self._worker.start()
    def stop(self) -> None:
        """停止轮询器"""
        self._running = False
        if self._worker:
            self._worker.join(timeout=5.0)
    def _poll_loop(self) -> None:
        """轮询主循环"""
        while self._running:
            try:
                # 执行轮询（这里只是一个框架，实际逻辑需要接入 multica CLI）
                result = self._perform_poll()
                # 广播给所有订阅者
                for subscriber in self._subscribers:
                    try:
                        subscriber(result)
                    except Exception as e:
                        print(f"[CoordinatedPoller] Subscriber callback error: {e}")
            except Exception as e:
                print(f"[CoordinatedPoller] Poll error: {e}")
            # 等待下一个轮询周期
            time.sleep(self.poll_interval)
    def _perform_poll(self) -> Dict[str, Any]:
        """
        执行实际轮询
        TODO: 接入 multica CLI:
        - multica issue list --status in_progress
        - multica workboard list
        """
        # 这里应该调用 multica CLI
        # 当前只是返回一个示例结果
        return {
            "timestamp": datetime.now().isoformat(),
            "issues": [],
            "workboard_cards": []
        }
 # ============================================================================
 # 使用示例
 # ============================================================================
 if __name__ == "__main__":
    # 创建调度器（40 RPM）
    scheduler = RequestScheduler(rate=40/60, capacity=40)
    scheduler.start()
    # 示例：提交不同优先级的请求
    def sample_callback(data):
        print(f"Processing: {data}")
        time.sleep(0.5)  # 模拟处理时间
        return "OK"
    # 紧急请求
    scheduler.submit(
        payload={"task": "urgent_task"},
        priority=Priority.URGENT,
        callback=sample_callback
    )
    # 正常请求
    scheduler.submit(
        payload={"task": "normal_task"},
        priority=Priority.NORMAL,
        callback=sample_callback
    )
    # 低优先级请求
    scheduler.submit(
        payload={"task": "low_priority_task"},
        priority=Priority.LOW,
        callback=sample_callback
    )
    # 等待处理完成
    time.sleep(2)
    # 查看状态
    print("\n=== Scheduler Status ===")
    print(json.dumps(scheduler.get_status(), indent=2))
    # 停止调度器
    scheduler.stop()
    print("\n示例运行完成")
@@ -0,0 +1,332 @@
 #!/usr/bin/env python3
 """
 BIZ-26 限流器测试脚本
 测试场景：
 1. 令牌桶限流功能
 2. 优先级队列调度
 3. 缓存管理器
 4. 重试机制
 5. 429 错误模拟
 运行方式：
    python3 scripts/test_rate_limiter.py
 """
 import sys
 import time
 import threading
 from datetime import datetime
 # 添加脚本目录到路径
 sys.path.insert(0, "/home/vincent/.openclaw/workspace/costcodev/EnterpriseArchitect/scripts")
 from rate_limiter import (
    TokenBucket,
    CacheManager,
    RequestScheduler,
    Priority,
    retry_with_backoff,
    CoordinatedPoller,
    is_nvidia_gateway,
 )
 def test_token_bucket():
    """测试令牌桶限流器"""
    print("=" * 60)
    print("测试 1: 令牌桶限流器")
    print("=" * 60)
    # 创建限流器：40 RPM = 0.67 令牌/秒
    bucket = TokenBucket(rate=40/60, capacity=40)
    print(f"\n初始状态：{bucket.get_status()}")
    # 快速消费 10 个令牌
    print("\n快速消费 10 个令牌...")
    success_count = 0
    for i in range(10):
        if bucket.consume():
            success_count += 1
    print(f"成功消费：{success_count}/10")
    print(f"消费后状态：{bucket.get_status()}")
    # 测试等待获取令牌
    print("\n测试等待获取令牌...")
    start = time.time()
    got_token = bucket.wait_for_token(timeout=2.0)
    elapsed = time.time() - start
    print(f"等待耗时：{elapsed:.3f}s, 获取成功：{got_token}")
    print(f"等待后状态：{bucket.get_status()}")
    print("\n✅ 令牌桶测试完成\n")
 def test_cache_manager():
    """测试缓存管理器"""
    print("=" * 60)
    print("测试 2: 缓存管理器")
    print("=" * 60)
    cache = CacheManager()
    # 测试 WorkBoard 缓存（TTL 5 分钟）
    print("\n1. 设置 WorkBoard 缓存（TTL 5 分钟）")
    cache.set("workboard", {"query": "status=todo"}, [{"id": "card1", "title": "Test"}])
    # 立即读取
    result = cache.get("workboard", {"query": "status=todo"})
    print(f"   立即读取：{result is not None}")
    # 测试配置缓存（TTL 1 小时）
    print("\n2. 设置配置缓存（TTL 1 小时）")
    cache.set("config", "agent_list", ["costcodev", "secretary", "coo"])
    result = cache.get("config", "agent_list")
    print(f"   读取配置：{result}")
    # 测试缓存统计
    print("\n3. 缓存统计")
    stats = cache.get_stats()
    print(f"   总条目数：{stats['total_entries']}")
    print(f"   按类别：{stats['by_category']}")
    # 测试缓存删除
    print("\n4. 删除缓存")
    deleted = cache.delete("workboard", {"query": "status=todo"})
    print(f"   删除成功：{deleted}")
    result = cache.get("workboard", {"query": "status=todo"})
    print(f"   删除后读取：{result is None}")
    print("\n✅ 缓存管理器测试完成\n")
 def test_priority_queue():
    """测试优先级队列调度"""
    print("=" * 60)
    print("测试 3: 优先级队列调度（简化版，不启动工作线程）")
    print("=" * 60)
    scheduler = RequestScheduler(rate=40/60, capacity=40, enable_cache=True)
    # 模拟请求处理结果
    results = []
    def record_result(data):
        results.append((time.time(), data))
        return data
    # 提交不同优先级的请求（不启动工作线程，只测试队列）
    print("\n提交请求（按顺序）:")
    scheduler.submit(
        payload={"task": "normal_1"},
        priority=Priority.NORMAL,
        callback=record_result
    )
    print("  1. 正常优先级：normal_1")
    scheduler.submit(
        payload={"task": "urgent_1"},
        priority=Priority.URGENT,
        callback=record_result
    )
    print("  2. 紧急优先级：urgent_1")
    scheduler.submit(
        payload={"task": "low_1"},
        priority=Priority.LOW,
        callback=record_result
    )
    print("  3. 低优先级：low_1")
    scheduler.submit(
        payload={"task": "high_1"},
        priority=Priority.HIGH,
        callback=record_result
    )
    print("  4. 高优先级：high_1")
    # 查看队列大小
    print(f"\n队列大小：{scheduler.get_queue_size()}")
    # 查看状态
    status = scheduler.get_status()
    print(f"初始令牌数：{status['token_bucket']['tokens']}")
    print("\n✅ 优先级队列测试完成（仅提交，未处理）\n")
 def test_retry_decorator():
    """测试重试装饰器"""
    print("=" * 60)
    print("测试 4: 重试装饰器")
    print("=" * 60)
    attempt_count = [0]
    @retry_with_backoff(max_retries=3, base_delay=0.1, jitter=False)
    def flaky_function():
        attempt_count[0] += 1
        if attempt_count[0] < 3:
            raise Exception(f"模拟失败 (尝试 {attempt_count[0]})")
        return f"成功 (尝试 {attempt_count[0]})"
    print("\n调用易失败函数（前 2 次失败，第 3 次成功）...")
    start = time.time()
    result = flaky_function()
    elapsed = time.time() - start
    print(f"结果：{result}")
    print(f"总尝试次数：{attempt_count[0]}")
    print(f"总耗时：{elapsed:.3f}s")
    print("\n✅ 重试装饰器测试完成\n")
 def test_coordinated_poller():
    """测试统一轮询器"""
    print("=" * 60)
    print("测试 5: COO 统一轮询器（简化版，短间隔测试）")
    print("=" * 60)
    scheduler = RequestScheduler(rate=40/60, capacity=40)
    poller = CoordinatedPoller(scheduler, poll_interval=2)  # 2 秒轮询一次（测试用）
    received_results = []
    def on_poll_result(result):
        received_results.append((datetime.now().strftime("%H:%M:%S"), result))
        print(f"   [{datetime.now().strftime('%H:%M:%S')}] 收到轮询结果")
    poller.subscribe(on_poll_result)
    print("\n启动轮询器（轮询间隔 2 秒，运行 5 秒后停止）...")
    poller.start()
    # 等待 5 秒
    time.sleep(5)
    poller.stop()
    print(f"\n收到结果次数：{len(received_results)}")
    for ts, result in received_results:
        print(f"  {ts}: {result['timestamp'][:19]}")
    print("\n✅ 统一轮询器测试完成\n")
 def test_rate_limit_stress():
    """压力测试：快速提交大量请求"""
    print("=" * 60)
    print("测试 6: 压力测试（40 RPM 限制下提交 50 个请求）")
    print("=" * 60)
    scheduler = RequestScheduler(rate=40/60, capacity=40, enable_cache=True)
    scheduler.start()
    completed = []
    failed = []
    lock = threading.Lock()
    def callback(data):
        with lock:
            completed.append(data)
        return data
    print("\n快速提交 50 个请求...")
    start_time = time.time()
    for i in range(50):
        priority = Priority.NORMAL if i % 10 != 0 else Priority.URGENT
        scheduler.submit(
            payload={"index": i, "provider": "nvidia"},
            priority=priority,
            callback=callback,
            gateway="nvidia"
        )
    print("提交完成，等待处理...")
    # 等待 10 秒
    time.sleep(10)
    elapsed = time.time() - start_time
    # 查看统计
    status = scheduler.get_status()
    print(f"\n耗时：{elapsed:.2f}s")
    print(f"队列大小：{status['queue_size']}")
    print(f"已完成：{status['stats']['completed_requests']}")
    print(f"失败：{status['stats']['failed_requests']}")
    print(f"降级：{status['stats']['fallback_requests']}")
    print(f"令牌桶状态：{status['token_bucket']}")
    scheduler.stop()
    print("\n✅ 压力测试完成\n")
 def test_gateway_scope():
    """测试限流范围：只对 NVIDIA 网关生效"""
    print("=" * 60)
    print("测试 7: 网关范围识别（只限 NVIDIA）")
    print("=" * 60)
    assert is_nvidia_gateway("nvidia") is True
    assert is_nvidia_gateway("nvidiavx18088980513/deepseek-ai/deepseek-v4-pro") is True
    assert is_nvidia_gateway("volcengine-plan/ark-code-latest") is False
    assert is_nvidia_gateway("siliconflow/Qwen/Qwen3") is False
    assert is_nvidia_gateway("deepseek/deepseek-chat") is False
    assert is_nvidia_gateway(None) is False
    scheduler = RequestScheduler(rate=1/60, capacity=1, enable_cache=True)
    # 先耗尽 NVIDIA 桶
    scheduler.submit(payload={"provider": "nvidia", "i": 1}, priority=Priority.NORMAL, callback=lambda x: x, gateway="nvidia")
    # 非 NVIDIA 请求应直接执行，不受桶状态影响
    non_nv = {"provider": "volcengine-plan", "i": 2}
    assert scheduler._should_rate_limit(type("R", (), {"gateway": "volcengine-plan", "model": None, "payload": non_nv})()) is False
    print("✅ 网关范围识别测试完成：volcengine-plan/siliconflow/DeepSeek 不限流，NVIDIA 限流\n")
 def main():
    """运行所有测试"""
    print("\n")
    print("╔" + "=" * 58 + "╗")
    print("║" + " " * 58 + "║")
    print("║" + "  BIZ-26 限流器测试套件".center(58) + "║")
    print("║" + "  API 请求优先级队列 + 令牌桶限流".center(58) + "║")
    print("║" + " " * 58 + "║")
    print("╚" + "=" * 58 + "╝")
    print()
    try:
        test_token_bucket()
        test_cache_manager()
        test_priority_queue()
        test_retry_decorator()
        test_coordinated_poller()
        test_rate_limit_stress()
        test_gateway_scope()
        print("\n")
        print("╔" + "=" * 58 + "╗")
        print("║" + " " * 58 + "║")
        print("║" + "  ✅ 所有测试完成".center(58) + "║")
        print("║" + " " * 58 + "║")
        print("╚" + "=" * 58 + "╝")
        print()
    except KeyboardInterrupt:
        print("\n\n⚠️  测试被用户中断\n")
    except Exception as e:
        print(f"\n\n❌ 测试出错：{e}\n")
        import traceback
        traceback.print_exc()
        sys.exit(1)
 if __name__ == "__main__":
    main()
@@ -1,214 +0,0 @@
 # 开发文档：双色球 Web UI 系统
 **版本**: v1.0  
 **开发人员**: 徐聪（costcodev）  
 **日期**: 2026-07-03  
 **Issue**: BIZ-75  
 ---
 ## 1. 项目概述
 双色球自动化系统 Web UI，提供号码生成、历史数据查看、生成记录管理和统计分析功能。支持 PC 端和移动端响应式访问，监听 0.0.0.0:8085，局域网可访问。
 ## 2. 技术栈
 | 层级 | 技术 | 说明 |
 |------|------|------|
 | 后端 | Python 3 + Flask | REST API 服务 |
 | 前端 | 原生 HTML/CSS/JS | 单文件，响应式布局 |
 | 数据分析 | Pandas + NumPy | 号码统计分析 |
 | 数据存储 | Excel + JSON | 历史数据 + 生成记录 |
 | 部署 | systemd / nohup | Linux 服务部署 |
 ## 3. 目录结构
 ```
 lottoData/
 ├── app.py                    # Flask 主服务（统一入口）
 ├── index.html                # 前端 UI（响应式，4 Tab 页面）
 ├── lottery.py                # 号码生成核心逻辑
 ├── fetch_data.py             # 历史数据抓取脚本
 ├── web_console.html          # 数据抓取控制台前端
 ├── requirements.txt          # Python 依赖
 ├── 双色球历史数据.xlsx        # 历史数据文件
 ├── lottery/                  # 号码生成结果输出目录
 ├── .generation_records.json  # 生成记录索引（JSON）
 ├── .fetch_status.json        # 抓取状态文件
 ├── deploy/                   # 部署相关文件
 │   ├── DEPLOY.md             # 部署说明
 │   ├── lotto-app.service     # systemd 服务文件
 │   ├── fetch_daily.sh        # 定时抓取脚本
 │   └── backup.sh             # 备份脚本
 └── docs/                     # 文档目录
    ├── PRD-双色球 WebUI-v1.0.md
    └── 开发文档-双色球WebUI-v1.0.md  ← 本文件
 ```
 ## 4. API 接口
 ### 4.1 接口清单
 | 接口 | 方法 | 描述 | 认证 |
 |------|------|------|------|
 | `/api/generate` | POST | 生成号码 | 可选 |
 | `/api/history` | GET | 获取历史开奖数据（分页+搜索） | 可选 |
 | `/api/records` | GET | 获取生成记录列表（分页） | 可选 |
 | `/api/records/:id` | DELETE | 删除生成记录 | 可选 |
 | `/api/statistics` | GET | 获取统计分析数据 | 可选 |
 | `/api/download/:filepath` | GET | 下载文件 | 可选 |
 | `/api/status` | GET | 系统状态 | 无 |
 | `/api/config` | GET | 前端配置 | 无 |
 | `/api/fetch/status` | GET | 抓取执行状态 | 无 |
 | `/api/fetch/execute` | POST | 触发数据抓取 | 无 |
 ### 4.2 关键接口参数
 #### POST /api/generate
 ```json
 // 请求
 {
  "num_tickets": 10,
  "strategy": "advanced"  // 或 "basic"
 }
 // 响应
 {
  "success": true,
  "data": {
    "tickets": [...],
    "total": 10,
    "filename": "lottery/xxx.xlsx",
    "download_url": "/api/download/lottery/xxx.xlsx",
    "record": {...},
    "statistics": {...}
  }
 }
 ```
 #### GET /api/history
 参数: `page` (页码), `page_size` (每页条数), `search` (搜索关键词)
 #### GET /api/records
 参数: `page` (页码), `page_size` (每页条数)
 ## 5. 前端页面
 ### 5.1 页面结构
 - **Header**: 标题 + 副标题
 - **导航 Tab**: 号码生成 | 历史数据 | 生成记录 | 统计分析
 - **移动端**: 底部固定导航栏
 ### 5.2 功能页面
 #### 号码生成页（首页）
 - 统计概览（历史期数、常见奇偶比、和值范围等）
 - 策略选择（高级策略/基础策略）
 - 注数输入（1-1000）
 - 生成结果展示（红球+蓝球+统计指标）
 - Excel 下载按钮
 #### 历史数据页
 - 搜索框（500ms 防抖）
 - 数据表格（期号、日期、红球、蓝球、统计字段）
 - 分页控件
 #### 生成记录页
 - 记录列表（策略、注数、时间、文件大小）
 - 下载/删除操作
 - 分页控件
 #### 统计分析页
 - 历史开奖期数
 - 红球热号 TOP15 / 冷号 TOP15
 - 蓝球热号 TOP8
 - 奇偶比/大小比/和值/跨度统计
 ## 6. 关键修复说明
 ### 6.1 数据格式兼容修复（核心 Bug 修复）
 **问题**: `lottery.py` 期望 Excel 含"号码"列（拼接格式如 `08121821243001`），但 `fetch_data.py` 抓取的 Excel 使用分列格式（"红球 1"~"红球 6"+"蓝球"），导致号码生成器无法加载历史数据。
 **根因**: Excel 文件包含两行 header：
 - Row 0: 新格式列名（期号、开奖日期、红球 1~6、蓝球、特别号）
 - Row 1: 旧格式列名（开奖时间、期数、号码、开机号、...）
 - Row 2+: 实际数据
 **修复方案**:
 1. `lottery.py` 的 `load_history_data()`: 添加多格式检测逻辑，识别格式A（双行 header）并自动跳过，使用旧列名作为标准列名
 2. `lottery.py` 的 `parse_numbers()`: 新增对拼接字符串格式（14位无分隔符）的直接解析，避免 `re.findall` 将整个字符串视为一个数字
 3. `app.py` 的 `load_history_dataframe()`: 同步修复多格式兼容逻辑
 ### 6.2 线程安全
 - 生成记录的读-改-写操作使用 `threading.Lock` 保护
 - 文件写入使用临时文件+原子替换（`os.replace`），防止崩溃导致数据损坏
 ## 7. 部署方式
 ### 7.1 直接运行
 ```bash
 cd /home/vincent/Studio/lottoData
 source .venv/bin/activate
 python3 app.py
 # 访问 http://localhost:8085
 ```
 ### 7.2 systemd 服务
 ```bash
 # 服务文件: deploy/lotto-app.service
 sudo cp deploy/lotto-app.service /etc/systemd/system/
 sudo systemctl daemon-reload
 sudo systemctl enable lotto-app
 sudo systemctl start lotto-app
 ```
 ### 7.3 定时数据抓取
 ```bash
 # 添加 cron 任务
 crontab -e
 # 每天 02:30 自动抓取最新数据
 30 2 * * * /home/vincent/Studio/lottoData/deploy/fetch_daily.sh >> /home/vincent/Studio/lottoData/deploy/cron.log 2>&1
 ```
 ## 8. 测试验证
 ### 8.1 API 测试结果
 | 接口 | 状态 | 说明 |
 |------|------|------|
 | GET /api/status | ✅ 通过 | 返回服务状态 |
 | GET /api/statistics | ✅ 通过 | 120条历史数据统计正确 |
 | GET /api/history | ✅ 通过 | 分页+红蓝球解析正确 |
 | POST /api/generate | ✅ 通过 | 5注号码生成成功，含统计 |
 | GET /api/records | ✅ 通过 | 生成记录列表正确 |
 | GET / (前端页面) | ✅ 通过 | HTML 页面正常加载 |
 ### 8.2 数据格式验证
 - 历史数据: 120 条记录全部成功解析 ✅
 - 红球解析: 6个红球正确提取 ✅
 - 蓝球解析: 1个蓝球正确提取 ✅
 - 号码范围校验: 1-33(红) + 1-16(蓝) ✅
 ## 9. 已知限制
 - 前端为单 HTML 文件，未使用构建工具
 - 无用户登录系统（Token 认证为可选项，默认关闭）
 - 历史数据来源为 55128.cn，如网站改版需更新 `fetch_data.py`
 - 不支持 HTTPS（内网环境）
 ## 10. 后续优化建议
 | 功能 | 优先级 | 说明 |
 |------|--------|------|
 | 数据可视化图表 | P2 | 走势图、分布图 |
 | 用户登录系统 | P2 | 多用户权限管理 |
 | 定时自动生成 | P2 | 定时生成+推送 |
 | 微信推送 | P3 | 生成结果推送至微信 |
 | 多彩种支持 | P3 | 大乐透、福彩 3D 等 |
 ---
 **开发完成日期**: 2026-07-03  
 **代码仓库**: http://192.168.1.99:12299/vincent/Lottery.git  
 **开发人员**: 徐聪（costcodev）