从零到一：我如何用对抗式方法设计并实现了一个 AI 任务引擎

一天之内，从一张白板到 3838 行代码上线，这大概是我做过最疯狂的 side project 了。

这一切是怎么开始的？

事情要从一个尴尬的时刻说起。

那天我让 AI 帮我处理一个任务，它花了三分钟，洋洋洒洒写了一大篇，结果我一看——方向全错了。它把简单问题当复杂问题处理，把需要多步协作的任务用一个 prompt 就打发了。

我心想：不行，得让这个 AI 学会判断任务难度，再用不同的方式去处理。

这个想法并不新鲜——很多工程系统都有类似的任务分级。但我的需求有点特殊：我需要 AI 自己判断任务的复杂度，然后在每次调用 LLM 的时候，都注入相应的提示词来做规范。不是让一个子代理完成整个流程，而是每次只让它完成流程中的一步。

对抗式解题法给了我这个思路——把一个复杂问题拆解成多个步骤，每个步骤由不同的”角色”来完成，环环相扣，层层把关。

于是，一个疯狂的想法诞生了：我要在一天之内，完成从设计到上线的全流程。

第一站：复杂度分类器

任何任务引擎的第一步，都是判断”这个任务有多难”。

我设计了一套两段式架构：

Phase 1（预分类）：任务刚进来时，通过文本特征分析快速判断是简单、中等还是复杂。这一阶段不依赖任何工具调用，纯文本分析，几十毫秒出结果。
Phase 2（动态监测）：任务执行过程中，EngineMonitor 持续观察进展。如果发现任务其实比预想更难（比如 solver 卡住了、结果质量不达标），自动触发升级信号，把任务从”简单”升级到”中等”或”复杂”。

三级分类表如下：

等级	典型任务	处理方式
🟢 简单	查询信息、格式化输出、翻译	单次 LLM 调用
🟡 中等	代码编写、文案创作、数据分析	Solver + Discriminator 两步
🔴 复杂	跨领域问题、多步骤推理、系统设计	完整对抗式解题法流程

关键设计决策：置信度阈值三档制（≥0.8 直接判定 / 0.6~0.8 软判定 / <0.6 兜底），以及误分类容错机制——分类错了不要紧，Phase 2 的动态监测会把你拉回来。

第二站：管道执行引擎

分类完了，任务该怎么执行？这是我设计的三条管道：

1
2
3

简单任务 → SimplePipeline: [单次LLM调用] → 直接输出
中等任务 → MediumPipeline: [Solver解题] → [Discriminator评审] → 输出
复杂任务 → ComplexPipeline: [拆解] → [Solver×N] → [聚合] → [Discriminator] → 输出

每条管道的每一步，都在调用 LLM 之前注入特定的角色提示词。比如 Solver 步骤注入架构师提示词，Discriminator 步骤注入现实检验者提示词。

这里有个关键设计：角色提示词分层继承体系。

_base.prompt（根级模板）
├── physics_executor/（物理执行者基础）
│   └── physics_executor.prompt.md
├── solver/（解题者家族）
│   ├── solver_architect.prompt.md
│   └── solver_writer.prompt.md
├── discriminator/（判别者家族）
│   └── discriminator_reality_checker.prompt.md
├── orchestrator/（编排者家族）
│   ├── task_analyzer.prompt.md
│   └── arena_architect.prompt.md
├── simple/（简单任务角色）
│   └── simple_llm.prompt.md
└── meta/（元角色）
    └── task_classifier.prompt.md

总共 16 个角色提示词文件，每个都有 frontmatter（role_id、name、extends、version 等字段），支持模板继承和占位符渲染。

第三站：交付与质量闭环

任务执行完了，不能就算完。我需要一个质量闭环：

QualityGate（质量门禁）：每次 pipeline 输出都要经过自动化质量检查。如果质量不达标，触发重新执行或升级。
EngineMonitor（引擎监控器）：持续监测任务执行状态，检测”是否需要升级处理”或”是否陷入死循环”。
FeedbackCollector（反馈收集）：记录每次任务执行的指标——耗时、完成率、失败原因、升级事件。
MetricsAggregator（指标聚合）：把原始数据变成可行动的洞察。
AuditLogger（审计日志）：所有事件不可篡改地记录，方便事后复盘。

这个设计让我在后续的数据驱动优化中尝到了甜头——没有数据，优化就是盲人摸象。

三场硬仗：对抗式评审

设计稿写出来了，但我问了自己一个问题：这些设计真的能落地吗？

为了回答这个问题，我引入了判别者角色——让我自己的 AI 切换视角，像审计员一样审视设计文档。

第一次评审，发现了 8 个问题——包括 P1 级的”分类接口未定义”和”Phase2 执行主体不明确”。

修。修完了再审。

第二次评审，又发现了 9 个跨站一致性问题——比如目录结构冲突（prompts/ vs engine/roles/）、数据流定义缺失（PipelineResult 没定义）、状态管理分歧（state.json vs ExecutionContext）。

再修。修完再审。

第三次评审——17/17 修复全部通过验证。

整个过程让我深刻体会到：写代码容易，做对设计难；做对设计容易，让多个设计保持一致难。

这就是对抗式解题法的威力——你既是解题者，也是判别者。自己给自己把关，比等人来骂你效率高多了。

实施编码：从 0 到 3838 行

设计通过评审后，我开始编码。但有意思的是，评审阶段我发现代码已经写了很大一部分——因为设计文档里包含了大量伪代码和实现思路，很多直接转化成了 Python 代码。

最终成果：

36 个 Python 文件 — 3838 行代码
16 个角色提示词文件
9 个 Markdown 文档
85 个文件总计
4 个核心模块：classifier / pipeline / delivery / roles

核心架构如下：

任务输入
    │
    ▼
┌─────────────┐
│ Complexity  │ ← Phase 1 预分类
│ Classifier  │ ← Phase 2 动态监测
└──────┬──────┘
       │ 分类结果
       ▼
┌─────────────┐
│  Pipeline   │ ← 根据复杂度路由
│  Executor   │ ← 角色注入执行
└──────┬──────┘
       │ 执行结果
       ▼
┌─────────────┐
│  Delivery   │ ← QualityGate 质量检查
│  & Feedback │ ← EngineMonitor 升级检测
└─────────────┘    ← FeedbackCollector 记录
       │
       ▼
    输出 + 审计日志 + 指标