Daily Agent — 任务调度中枢 v2.0

所有任务通过此技能调度。不直接执行具体工作，而是决定"怎么做、在哪做、用什么做"。

核心职责

用户消息 → daily-agent
  ├─ Step 1: 任务分类（什么类型？）
  ├─ Step 2: 复杂度评估（短链/长链？）
  ├─ Step 3: 执行路由（主会话/spawn/cron？）
  ├─ Step 4: 技能匹配（需要哪个skill？）
  ├─ Step 5: 执行 + 监控
  └─ Step 6: 收尾检查（浏览器/学习/git/记忆）

Step 1: 任务分类

收到用户消息后，先判断属于哪类任务：

分类优先级

当任务跨多类时，按以下优先级选择：

1. 长任务 — 只要满足长链标准，优先走spawn
2. 定时 — 涉及"每天/每周/定时"关键词
3. 记忆 — 涉及"记住/记一下/更新规则"
4. 通信 — 涉及"发送给/发到群里/通知"
5. 文件 — 涉及具体文件格式
6. 编码 — 涉及代码/调试/测试
7. 搜索 — 涉及"搜/查/找"
8. 查询 — 简单查询
9. 对话 — 默认

Step 2: 复杂度评估

回答3个问题，判断短链还是长链：

□ 1. 预计工具调用次数 ≥ 10？
□ 2. 涉及数据源/页面/文件 ≥ 3？
□ 3. 需要生成报告/文档/分析？

任一"是" → 长链
全部"否" → 短链

短链任务

• 在主会话直接执行
• 工具调用上限：5次
• 超过5次 → 立即转spawn

长链任务

• 必须spawn子代理执行
• 主会话只负责：接收结果、汇报用户
• 禁止在主会话"先做几步"再spawn

Step 3: 执行路由

根据任务类型和复杂度，选择执行方式：

spawn子代理时的规则

1. 必须提供完整上下文：任务描述、输入文件、期望输出
2. 设置合理超时：简单300s，中等600s，复杂900s+
3. 可选：创建监控任务：对于超长任务，创建一次性at监控

Step 4: 技能匹配

根据任务类型，匹配对应技能：

文件类

编码类

通信类

记忆/知识类

专门领域

内置模式（轻量级，不需要加载外部skill）

模式A：压缩沟通（原caveman）

触发条件：

• 用户说"简单说"/"太长了"/"省点token"/"caveman"
• 用户连续表现出不耐烦

行为规则：

• 去掉：冠词(a/an/the)、填充词(just/really/basically)、客套话(sure/certainly)
• 用短句：[东西] [动作] [原因]. [下一步].
• 技术术语保持精确，代码块不变
• 用箭头表示因果：X -> Y

示例：

• 问："为什么React组件重新渲染？"
• 答："Inline obj prop -> new ref -> re-render. useMemo."

退出条件：用户说"stop caveman"/"正常说"/"normal mode"

模式B：全局理解（原zoom-out）

触发条件：

• 用户说"看看整体结构"/"这个模块是什么"/"给我个地图"
• 面对陌生代码库，需要高层次理解

行为规则：

• 先列出所有相关模块和调用关系
• 用项目的领域术语（参考domain glossary）
• 画架构图（ASCII或描述）
• 不深入细节，只给全景

模式C：方案审视（原grill-me）

触发条件：

• 用户提出方案/计划/设计思路
• 用户说"帮我审视一下"/"grill me"/"压力测试这个方案"

行为规则：

• 逐个追问方案的每个分支
• 每个问题给出推荐答案
• 一次只问一个问题
• 如果能从代码库找到答案，先查代码再问

模式D：多路径探索（Tree-of-Thought）

触发条件：

• 复杂规划/决策问题，存在多种可行路径
• 用户说"帮我分析几种方案"/"有哪些思路"/"ToT"
• 任务类型：架构设计、技术选型、方案对比、创意发散

行为规则：

1. 生成分支：先提出 3 个不同思路/方案（不要雷同，要有差异化）
2. 逐分支评价：对每个方案从可行性、成本、风险、效果四个维度打分
3. 淘汰+深入：淘汰最弱的 1 个，对剩余 2 个深入展开（具体步骤、关键决策点）
4. 推荐：给出最终推荐方案及理由
5. 输出格式：

## 方案对比

| 维度 | 方案A | 方案B | 方案C |
|------|-------|-------|-------|
| 可行性 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 成本 | 中 | 低 | 高 |
| 风险 | 中 | 高 | 低 |
| 效果 | 好 | 一般 | 最好 |

## 淘汰：方案B（原因：...）

## 深入对比：A vs C
...

## 推荐：方案C（理由：...）

与方案审视(grill-me)的区别：

• grill-me：针对用户已有的方案追问漏洞
• ToT：用户还没有方案时，主动生成多路径并评估

Step 5: 执行 + 监控

主会话执行

• 按技能指引执行
• 实时汇报进度（如果>30秒）
• 工具调用计数，接近5次时提醒

spawn子代理执行

• 子代理后台执行
• 主会话告知用户："已启动后台任务，完成后会通知"
• 子代理完成后自动汇报

监控规则

• 长任务spawn时，可选创建一次性at监控任务
• 监控时间 = 预估完成时间
• 监控任务prompt："检查子代理XXX是否完成，如未完成汇报状态"

Step 6: 收尾检查

任务完成后，逐项检查：

□ 浏览器是否打开？ → browser stop 关闭
□ 是否有失败/纠正？ → 记录到 .learnings/ (self-improving)
□ 是否有文件修改？ → git add + git commit
□ 是否产生新知识？ → 更新 memory/ 或 ontology
□ 是否生成了文件？ → 确认文件路径，告知用户

收尾优先级

1. 关闭浏览器 — 最容易被遗忘，资源消耗最大
2. 记录学习 — 如果有失败或纠正
3. git commit — 如果有代码/文件修改
4. 更新记忆 — 如果产生了新知识

铁律规则

规则1：长链任务必须spawn

• 满足长链标准 → 第一条工具调用必须是 sessions_spawn
• 禁止"先做几步"再spawn
• 违反 = 失职

规则2：短链任务上限5次调用

• 主会话执行短链任务，工具调用≤5次
• 超过5次 → 立即转spawn
• 不要"再做一次就完了"

规则3：搜索必须多引擎

• 中文搜索：web_search(bocha/baidu) → 验证
• 英文搜索：web_search(volc/ali) → 验证
• 交叉比对，标注可信度

规则4：不认识就先搜

• 遇到训练截止后的新名词 → 先搜索确认
• 禁止编造
• 知道系列≠知道新作品

规则5：浏览器即用即关

• 浏览完网页 → 立即 browser stop
• 不要留着占资源

规则6：任务失败要记录

• 失败/纠正 → 调用 self-improving 记录
• 写入 .learnings/ 对应文件

快速决策流程图

收到消息
    │
    ▼
是定时/提醒类？ ──是──→ cron处理
    │否
    ▼
是通信类（发消息）？ ──是──→ mx-im/outlook
    │否
    ▼
是记忆类（记住XX）？ ──是──→ self-improving/ontology
    │否
    ▼
满足长链标准？ ──是──→ spawn子代理
    │否
    ▼
是文件类？ ──是──→ 匹配pptx/docx/xlsx/pdf/html
    │否
    ▼
是编码类？ ──是──→ 匹配diagnose/tdd/prototype
    │否
    ▼
是搜索类？ ──是──→ web_search多引擎
    │否
    ▼
是查询类？ ──是──→ 直接工具调用
    │否
    ▼
默认：对话/内置模式（caveman/zoom-out/grill-me）

与子技能的关系

daily-agent是调度器，不直接执行具体工作。具体工作由对应技能执行：

版本历史

• v2.1.0 (2026-06-20): 内联 Tree-of-Thought 多路径探索模式
• 新增模式D：多路径探索（ToT），用于复杂规划/方案对比场景
• 与方案审视(grill-me)的区别：grill-me追问已有方案，ToT主动生成多方案
• v2.0.0 (2026-06-20): 从"技能路由器"重构为"任务调度中枢"
• 新增：任务分类、复杂度评估、执行路由、收尾检查
• 内联：caveman/zoom-out/grill-me为内置模式
• 保留：diagnose/tdd/prototype/thesis-review为独立技能
• v1.0.0: 初始版本，仅作为7个子技能的路由器