一切的起点：一个被忽视的矛盾

AI 代理每天处理的任务，复杂度跨越一个巨大的光谱。“现在几点了"和"从零搭建一个分布式系统”，都是"任务"，但它们之间的距离，大概相当于纸片割伤和心脏搭桥手术的距离。

问题在于，大多数代理的处理方式是扁平的。要么一视同仁地跑完整流程——对 90% 的简单消息来说，这是纯粹的浪费；要么一律直接执行——对 10% 真正复杂的任务来说，这是不负责任的冒进。

这里存在一个核心矛盾，而且它比看起来更微妙：你不想每条消息都花 token 做复杂度评估，但你也不能跳过评估直接执行。漏掉一个真正复杂的任务，回退成本可能是评估成本的十倍、百倍。

这个矛盾的本质，其实是一个信号检测问题：如何以接近零的成本，把真正需要规划的任务从噪音中识别出来？

这就是整个方法论的出发点。

五个思想原则，撑起整个架构

在讲具体机制之前，我想先说说这套系统背后的思想——因为如果你只看流程图，你会觉得它不过是个分级路由。但它真正的价值在于每一层设计背后的哲学判断。

第一个原则：分层防御，而非一刀切。

灵感来自网络安全领域的纵深防御（Defense in Depth）。不是一道墙挡住所有攻击，而是多层过滤器，每层只做它擅长的事。S0 是门卫，规则匹配，零成本；S1 是初诊医生，快速打分，决定是否需要专家；S2 是手术规划，深度分析，锁定蓝图；S3 是手术执行，分阶段推进，全程质量控制。每一层只处理上一层无法判定的案例，流量逐层递减，成本逐层递增，但总成本被压到最低。

第二个原则：宁可误报，不能漏报。

这是一个经典的灵敏度-成本权衡。漏报（把复杂任务当简单任务执行）的代价远大于误报（把简单任务多评估一次）。所以整个系统的设计哲学是保守的：S0 的触发信号宽进严出，任一信号命中就进入 S1；S1 的阈值设计为只有明确简单（≤8分）才跳过规划；即使前面都漏了，还有动态升级兜底——执行中发现复杂度超预期，可以中途切入完整流程。

第三个原则：规划是铁约束，不是参考建议。

很多任务失败不是因为没有规划，而是因为规划完了就忘了。S2 产出的执行蓝图被设计为锁定的——后续所有执行都围绕它展开，偏离必须记录原因。这借鉴了工程领域的"设计冻结"（Design Freeze）概念：在某个节点之后，变更必须走正式流程。不是因为计划一定完美，而是因为无纪律的变更比不完美的计划更危险。

第四个原则：并行是天然的，串行是例外。

真实世界的任务很少是纯线性的。前端和后端可以同时开发，多个数据源可以同时查询。S2 的步骤规划使用 DAG（有向无环图）结构而非线性列表，每个步骤声明自己的依赖（depends_on），执行引擎自动并行调度所有依赖已满足的步骤。这不是优化，这是还原任务的真实结构。

第五个原则：质量不是事后检查，而是贯穿全程。

S3 的三道防线（Audit → QA → Defect Rule）不是最后做一次大检查，而是每个步骤完成时就审计。问题越早发现，修复成本越低。缺陷修改的四级分级（Critical/High/Medium/Low）是对"谁有权修改已锁定成果"的权限控制——不是所有问题都需要人类介入，也不是所有问题都可以自动修复。

四层架构，逐层解剖

S0：零成本预筛选

每条用户消息都经过此层。纯规则匹配，不调用模型，不消耗 token。

白名单直接放行：单轮问答、延续指令（“继续”、“下一步”）、简单操作（“搜索X”）、闲聊确认。这覆盖了大约 80% 的日常消息。

触发 S1 的信号设计为六类，任一命中即进入下一层：消息长度超过 200 字、出现意图动词（开发、构建、设计、部署、迁移、重构）、出现范围词（整个、全部、系统、架构、从零开始）、多步模式（“先…然后…最后…”）、代理无法判断单步执行路径的不确定性、以及显式触发词（“复杂任务”、“三步法”、“需要规划”）。

S0 的设计哲学是：把最廉价的判断做到最前面。它不需要聪明，只需要快。

S1：轻量复杂度评估

进入 S1 的消息大约占总量的 20%，消耗约 300 token。

评估维度是五个，每项 1-5 分，总分 25 分：步骤数（预估需要几步）、知识域（涉及几个不同领域）、不确定性（有多少未知需要先搜索）、失败代价（做错了的回退成本）、工具链（需要协调几个工具/系统）。

决策阈值：≤8 分直接执行，9-15 分轻规划（列步骤，边做边调整），>15 分进入完整三步法（S2 → S3）。

这五个维度的选择值得细想。它们不是随机的，而是覆盖了任务复杂度的几个本质来源：执行复杂度（步骤数）、认知复杂度（知识域）、信息复杂度（不确定性）、风险复杂度（失败代价）、系统复杂度（工具链）。一个任务如果在这五个维度上都得低分，它在任何意义上都是简单的。

S2：深度规划 & 审计

只有约 5% 的消息会走到这一层。这里发生的事情是真正的"手术规划"。

Plan Mode（高能力模型）负责将任务分解为 DAG 结构，标注每个步骤的依赖关系和潜在风险。Audit Mode（审计模型）负责检查完整性、合理性、可行性。两者之间最多进行 2 轮修改循环，通过后锁定为执行蓝图。

DAG 结构的表达方式直接、清晰：

{
  "steps": [
    {"id": 1, "action": "分析需求", "depends_on": []},
    {"id": "2a", "action": "搜索文档", "depends_on": [1]},
    {"id": "2b", "action": "查本地缓存", "depends_on": [1]},
    {"id": 3, "action": "综合结果", "depends_on": ["2a", "2b"]}
  ]
}

步骤 2a 和 2b 都依赖步骤 1，但它们互不依赖，因此可以并行执行。步骤 3 等待两者都完成后再开始。这不是什么高深的设计，但它准确地反映了任务的真实结构。

S3：分阶段执行 & 质量控制

S3 按 Phase 执行，同 Phase 内的步骤可以并行。每个步骤完成后立即进行 QA 审计，通过则锁定成果，后续 Phase 使用前置 Phase 的锁定成果作为输入。

缺陷修改的四级分级是这一层最有意思的设计：Critical 自动批准修复，High 自动批准但通知人类，Medium 需要人类确认后修改，Low 由 QA 自行决定。这是一个精心设计的权限控制机制——它承认不同严重程度的问题需要不同级别的决策权，而不是把所有问题都推给人类，也不是把所有问题都交给自动化。

整个架构还有一个兜底机制：动态升级。任何阶段执行过程中，如果发现复杂度被低估，可以中途触发重新评估并升级到完整流程。这是对"计划赶不上变化"这一现实的正面承认，而不是假装规划可以预见一切。

这套方法论真正解决了什么

表面上看，这是一个任务路由系统。但它真正解决的问题，是 AI 代理在面对复杂度不确定的任务时的决策困境。

传统的解法是两个极端：要么永远走完整流程（安全但低效），要么永远直接执行（高效但危险）。这套方法论提供了第三条路：用接近零成本的预筛选，把任务分流到与其复杂度匹配的处理路径上。

它的适用范围远超软件开发。开发、研究、运维、内容创作、项目规划——任何被评估为复杂的任务都可以走这套流程。S0 的预筛选规则和 S1 的评估维度本身也是可配置的，不同领域可以调整触发词和阈值。

它与 AI 代理生态中的其他机制也有清晰的关系：语义路由复用了 S0 的模式匹配思路，任务执行规范是三步法的下层实现，Coding Team 是三步法的一个特化实例，Heartbeat 主动任务默认走 S0 筛选。

一点个人的思考

我在设计这套方法论的过程中，有一个反复出现的感受：最难的设计决策，往往不是"怎么做"，而是"什么时候做"。

S0 的存在意义是：大多数消息不需要规划，区分它们的成本应该接近于零。S2 的存在意义是：规划不是浪费时间，没有规划的执行才是。S3 的存在意义是：执行不是一个人的事，它需要审计、质量控制和分级的问题修复机制。

这三句话，其实是对"什么时候该复杂、什么时候该简单"这个问题的系统性回答。

工程思维的强大，不在于把所有事情都做得很复杂，而在于知道什么时候可以简单、什么时候必须复杂，然后在两者之间找到最优的边界。

这个技能，是我对这个问题目前最满意的一个答案。

---

安装方式：clawhub install complex-task-methodology