Mission Driver：AI 任务驱动引擎的通用实现

问题：从凭感觉编程到自主运作

当前主流的 AI 辅助开发仍然是凭感觉编程：人提示、AI 回应、人修正、AI 再次回应。这可以称为"人在循环中"模式。每个输出都需要人类确认和修正；人和 AI 交替工作。

这种模式有两个问题。

首先是质量控制的丧失。AI 执行本质上是一个概率采样过程。没有外部控制结构干预，AI 很容易偏离轨道——例如执行任务途中改动其他代码、忘记做出改动后运行测试、遇到失败时陷入无限循环，或崩溃后丧失状态且必须重新开始。更危险的是自我宣布完成——声称某事已完成但实际未实现。

其次是容量限制。当人在循环中时，最终的瓶颈仍然是人类的工作时间和精力。一个人一天工作 8 小时；即使 AI 辅助将效率提高三倍，上限也只是 24 人工小时。要真正释放 AI 生产力，我们必须转向"人在循环上"：AI 完全自主运行 7×24，人走出循环，变成按需干预的控制因素。

这不仅仅是操作模式的转变，更是成本结构的变化。当 AI 能够自主运行 7×24 时，工作小时数不再是约束。一个较弱的模型可能需要更长时间并消耗更多 token 来完成工作，但它足够便宜，可以在夜间运行而不占用人类时间。多个任务可以并行处理不同的路线图工作项。成本核算从"每人工小时输出"转变为"每美元智能输出"。

Mission Driver 是一个实现这一转变的具体控制结构。

Mission Driver 是什么（一分钟版本）

Mission Driver 是一个声明式的任务驱动引擎。你给它一个目标（通过路线图描述），它自动进入循环：

检查健康状态（初始，仅一次） → 审查计划 → 执行计划 → 起草新计划 → （回到审查计划） → 当无法起草新计划时 → 深度审计 → （回到审查计划）...

循环运行到目标达成或审计预算耗尽。每个步骤是一个独立的 AI 子流程或脚本函数；单个步骤的失败不会影响整个循环。

它是上下文工程（Attractor-Guided Engineering，开源仓库链接在文章末尾）的一个组件，且不限于软件开发。通过配置自定义流程、提示和命令，它可以自然地推广到数据处理和文档分析等场景——一个用于完全自主 AI 运作的通用机制。

它适合需要长运行时间执行、清晰的验收标准和多步迭代的复杂任务。

循环工程是 AI 工程领域快速涌现的设计方法——使用循环结构而非线性提示让 AI 系统自主运行直到目标达成。它不是任何特定工具的专有功能，而是一个可独立于特定工具设计的工程模式。Mission Driver 是循环工程的通用参考实现。

它如何工作：循环嵌套与局部容错

如果将凭感觉编程视为一个单一的无限循环，Mission Driver 的核心是将那个单一循环分解为嵌套的多层循环——Mission Driver 的主循环（五步闭环）是外层，其中嵌入了内层：计划循环（EXEC_PLANS 子流中的执行 → 检查 → 审计 → 验证循环）和可选的审计循环（DEEP_AUDIT 子流中的多维审计循环）。理解这个嵌套结构是理解它为什么能稳定长期运行的关键。

假设有 3 个活跃计划，plan-002 的执行遇到阻塞：

EXEC_PLANS:
  ├── plan-001: EXECUTE ✓ → CHECK ✓ → BUILD ✓ → 已完成 ✓
  ├── plan-002: EXECUTE ✗ → 重试 3 次仍失败 → 子流失败
  │              → 执行代理发现前置条件未满足
  │              → 将阻塞项移至"延迟但已判决"，记录触发条件
  │              → 剩余阶段继续 → 已完成（带后续项）
  └── plan-003: EXECUTE ✓ → CHECK ✓ → BUILD ✓ → 已完成 ✓

plan-002 的执行阻塞对 plan-001 和 plan-003 没有影响。阻塞被限制在子流内，不会传播到兄弟子流或父循环。这就是循环嵌套带来的局部容错。

计划执行期间，AI 根据实际情况决策：局部阻塞的项被移至"延迟但已判决"并记录后续触发条件，而其余范围正常完成；如果整个计划方向被否决，则标记为被取代或取消。计划的 .md 文件状态始终由 AI 代理管理。

每个步骤的执行状态被持久化到磁盘（计划文件中的复选框）。进程崩溃并重启后，引擎扫描磁盘上的复选框标记并从断点恢复，无需重放历史。

Mission Driver 的源项目在 AGE 模板项目中。通常，我们在自己的项目中添加一个 tools/mission-driver.sh 脚本来代理调用 Mission Driver，并通过 MISSION_DRIVER_HOME 环境变量指向 Mission Driver 源目录。

入门流程：

下载 AGE 模板，让 AI 读取并将其调整到你的项目（调整文档结构、配置命令、初始化路线图）

确保测试命令可执行（npm test / mvn test / Playwright）

在日常 AI 对话中，根据计划指南将计划起草到 plans 目录中，积累计划和日志

# 生成 mission 配置 + 路线图
./tools/mission-driver.sh draft "你的目标描述"

# 验证配置
node $MISSION_DRIVER_HOME/src/mission-check.mjs missions/<name>.json .

# 干运行以验证流程编排
./tools/mission-driver.sh run <name> --dry-run --no-monitor

# 正式运行
./tools/mission-driver.sh run <name>

Mission Driver 有一个内置的可视化监控页面。

open http://localhost:9300              # 浏览器仪表板
cat _tmp/<runDir>/run-state.json        # 读取状态
tail -f _tmp/<runDir>/<mission>.log     # 跟踪日志

中断与恢复：

# Ctrl-C 安全中断（引擎捕获信号，清理子进程）
# 重新运行自动恢复
./tools/mission-driver.sh run <name>

# 从特定步骤恢复
./tools/mission-driver.sh run <name> --from-step EXEC_PLANS

# 快速模式（跳过 DEEP_AUDIT）
./tools/mission-driver.sh run <name> --fast

./tools/mission-driver.sh analyze           # 分析最近的运行
./tools/mission-driver.sh analyze <runId>   # 分析特定运行

事后分析扫描所有事件和日志，运行事后分析代理，并将结构化报告写入内存目录。同一模块的后续任务将自动加载这些经验教训。

四层定义系统

Mission Driver 由四层定义组成，通过配置而非编程来使用。

4.1 Mission 配置（missions/<name>.json）

纯静态配置，声明做什么、在哪里做以及如何验证：

{
  "name": "medical-qa",
  "description": "从医学论文生成 QA 训练数据集",
  "roadmapPath": "docs/backlog/medical-qa-roadmap.md",
  "plansDir": "docs/plans/medical-qa",
  "commands": {
    "test": "python scripts/check_quality.py --min-records 500",
    "typecheck": "python -c \"import dataflow\" && echo OK"
  },
  "promptsDir": "missions/prompts/data-processing"
}

commands.test 是必需字段；CHECK 和 BUILD_VERIFY 都会运行它。build/lint/typecheck 是可选的，如果缺失则跳过。运行时状态在 _tmp/<runId>/run-state.json 中，不写入 mission.json。

引擎核心是一个通用状态机 DSL 执行器（FlowEngine，零项目特定逻辑）。流定义声明步骤如何编排、转换如何发生以及错误时如何处理。引擎根据流描述推进状态机，不绑定到任何固定步骤。

简化的流结构：

{
  "name": "my-flow",
  "entry": "CHECK",
  "steps": {
    "CHECK": {
      "type": "agent",
      "promptPath": "prompts/health-check.md",
      "transitions": {
        "pass": { "goto": "NEXT_STEP" },
        "fail": { "done": "failed" }
      }
    },
    "NEXT_STEP": {
      "type": "subflow",
      "flow": "my-subflow",
      "forEach": "activePlans()",
      "transitions": {
        "all_complete": { "done": "completed" }
      }
    }
  }
}

步骤类型：agent（AI 子进程）、script（JS 函数）、subflow（嵌套子流程）、group（分组步骤）

控制流：transitions 定义步骤间的跳转（goto/done/retry）；forEach 遍历集合并为每个元素启动一个子流程；when/otherwise 用于条件跳过

错误处理：每个步骤都可以配置 maxRetries、onMaxRetries、onError、onUnknown；引擎还提供全局无限循环检测（ping_pong + max_cycles + max_total_steps）

内置默认流程（flows/mission-driver.json）就是我们一直讨论的循环。其实际结构是：CHECK 仅在入口运行一次，然后进入循环体 REVIEW_PLANS → EXEC_PLANS → DRAFT_PLANS；当 DRAFT_PLANS 没有新的 plan 要起草时，进入 DEEP_AUDIT，然后返回循环体。它不是硬编码的，只是一个默认配置。EXEC_PLANS 和 DEEP_AUDIT 本身是子流程（plan-execution.json / deep-audit-loop.json），可以独立替换。

这意味着可以设计全新的工作流——例如，一个不需要 Plan 编排的代码审查工作流可以写成四步流程：FETCH_PR → RUN_LINT → AI_REVIEW → POST_COMMENT。将自定义流程 JSON 放在 missions/flows/ 目录中，并在 mission.json 中设置 "flowName": "<custom>"；引擎保持不变。

Plan 是最小工作单位，由 AI 按特定格式自动生成。其核心不仅仅是定义待办事项列表，而是定义如何判断完成的闭包协议。其标准结构如下：

# 01 采购订单审批工作流集成

> Plan 状态：草稿
> 最后审查：2026-07-25
> 来源：路线图项 "核心业务逻辑 M1"

## 当前基线
- ErpPurOrder 实体已建模，CRUD 已生成
- 暂无审批逻辑

## 目标
- 采购订单支持 提交→审批→拒绝/批准 状态转换
- 审批后触发库存过账

## 非目标
- 无多级审批
- 无审批委托

### 第 1 阶段 - 审批状态机
状态：已规划

- [ ] 实现 submitForApproval / approve / reject 方法
- [ ] 状态验证：仅 DRAFT 可提交

退出标准：
- [ ] 提交→批准后，posted=true
- [ ] 单元测试覆盖所有状态转换

## 闭包门槛
- [ ] 端到端：完整链路 提交→批准→过账→冲销 已验证
- [ ] 独立子智能体闭包审计已通过
- [ ] mvn test 全部通过

前三行为状态标记，Goals + Non-Goals（防止范围蔓延），每个 Phase 包含 Status + 复选框 + Exit Criteria，Closure Gates 是 plan 级最终检查。复选框是机器可读的持久状态；引擎通过扫描复选框从断点恢复。标记为完成前，所有复选框必须勾选。

在 AGE 实践中，人类通常不需要阅读 Plan；它们完全由 AI 自主创建和更新。

Roadmap 是人类可读的、可控的宏观计划。根据 docs/backlog/00-roadmap-authoring-guide.md 规范，工作项按里程碑分组，仅包含三种状态：todo/ready/done；里程碑本身不包含状态：

# 核心业务路线图

> 前置条件：所有 CRUD 已完成

## 工作项状态

### 里程碑 M1 — 核心业务循环

- 采购申请审批→转订单逻辑：`done`
- 销售报价审批→转订单逻辑：`done`
- 采购订单 BizModel（审批/收货触发/过账）：`done`
- 销售订单 BizModel（审批/发货触发/过账）：`done`
- 三角验证逻辑：`done`

### 里程碑 M2 — 业财一体化端到端

- 采购到付款完整链路（PO→收货→发票→付款）：`done`
- 订单到现金完整链路（SO→交付→发票→收款）：`done`
- 期末结账完整流程：`todo`
- 退货到退款完整链路：`todo`

### 里程碑 M3 — 扩展领域业务逻辑

- HR 班次排期引擎：`todo`
- 薪资计算：`todo`
- APS 生产排期：`todo`

DRAFT_PLANS 启动一个 AI 智能体：读取完整 roadmap + 历史 plan 中的待处理项 → 读取项目上下文和 planGuide → 选择后续 1–3 个工作项 → 起草 plan 草稿（Status: draft）→ 调用独立子智能体审查；批准后标记为活跃。当无法再起草工作时，返回空值，引擎根据此决定是否进入审计轮次。

6. 配置和自定义

Mission Driver 引擎完全通用。自定义可通过配置和提示覆盖实现，完全无需修改代码。一般来说，你只需在自己的项目中添加一个 mission-driver.sh 脚本；它通过环境变量中配置的路径调用 AGE 模板项目中的 Mission Driver 实现。

流程加载优先级：项目 missions/flows/<flowName>.json → 引擎内置 tools/mission-driver/flows/<flowName>.json。项目中同名文件优先级更高。子流程遵循相同链路。

promptsDir 配置允许不同任务指向不同的提示子目录，使同一引擎能使用不同的提示集：

{
  "promptsDir": "missions/prompts/analysis",
  "flowName": "mission-driver"
}

引擎提示加载链路：promptsDir（任务类型级）→ missionsDir/prompts（项目级）→ 内置默认。未设置 promptsDir 时行为不变。

内置的 CHECK→REVIEW→EXEC→DRAFT→AUDIT 适用于大多数软件开发场景。但对于数据处理和文档分析等任务，可以完全通过不同的流程进行适配——引擎不变，只需交换流程文件。

上述自定义方法充分体现了可逆计算理论中的 Delta 定制理念，是非侵入式定制的具体实现。关于 Delta 定制的详细介绍，见《如何实现不修改基础产品源代码的定制开发》

7. 循环作为智能

Mission Driver 的有效性不仅来自单个 AI 调用的质量，而是主要来自通过循环的迭代反馈改进。每轮执行生成的反馈（测试结果、审计发现、人工修正）应被记录并用于改进下一轮。

AGE 使用两条并行改进轨道：

做事提示（DRAFT/EXECUTE）：当 AI 生成的 plan 或代码被人类修正时，修正记录由子智能体分析，提取通用规则并写入技能库。AI 下次自动加载。

检查提示（CLOSURE_AUDIT/DEEP_AUDIT）：当审计漏掉问题时，补充审计提示增加检查维度。

AI 生成第一版
  → 人类修改（修改过程已记录）
  → 独立子智能体比对原始版本和修改版本
  → 提取"为什么要修改"的通用规则
  → 写入技能库或编码标准
  → AI 下次自动加载

nop-app-erp 项目积累了 19 个可复用技能，全部源于这种基于循环的改进。

8. AI 自动生成 E2E 测试

E2E 测试的手工编写和维护成本极高；以前很少有团队能长期广泛维护它们。现在 AI 可以自动生成。关键是降低难度：封装 PageObject 模式，提供简化的操作如 getFieldValue(containerLocator, fieldName)，这样 AI 无需为每个页面反复处理复杂的 DOM 选择器。

例如，在 Nop 平台的 AMIS 页面中，每个字段都有在 view.xml 中通过 <cell id="customerName"> 定义的稳定业务标识符，它被渲染为 AMIS 组件的 name 属性。AI 只需按业务名称查找字段：

# AI 专注于意图"获取客户名称"，不用关心 DOM 路径
value = getFieldValue(page, "customerName")
# 封装层在内部通过 name 属性按对应 AMIS 组件定位输入元素

这种封装使 AI 生成的测试脚本更稳定——页面布局变化时，仅需更新 PageObject 封装层；现有测试用例无需逐个修改。

nop-app-erp 从 0 到 260+ 个 spec；早期阶段需要频繁人工修正，但后期基本由 AI 自动生成或自动修改。

9. nop-app-erp：22 天内 154 个模块

nop-app-erp 提供了一个可公开审计的案例：多层循环嵌套如何驱动 AI 从一个空骨架逐步演进为生产级 ERP。在这个项目中，logs/audits/plans 等目录记录了所有关键决策的执行过程和原因，使其完全可被 AI 分析以回答任何有关项目演进历史的问题。这是 AGE 对"项目本身是唯一真实来源"这一明确要求的必然结果：没有信息被遗留在人脑中、聊天窗口或临时对话中；项目文档和源代码包含了最新的项目状态及其完整的演变轨迹。

## 规模指标（独立审计）

08:00 CHECK — mvn all green 08:05 REVIEW — 4 drafts → independent review → all active 09:30 EXEC — 4 plans executed, all green 16:00 DRAFT — all roadmap work items done 16:05 DEEP_AUDIT — auto-triggered deep audit

一个循环周期耗时约 8 小时。整个 22 天的路线图通过数十个循环完成。

## 编码前缺陷截获

在 07-10，一批计划的独立草案审查截获了 4 个 P0 级缺陷：代码值冲突、BUDGET 污染实际财务、GlBalance 中错误的架构前提以及维度歧义。所有缺陷都在编码之前被截获。没有计划循环，这些缺陷只会在实现或甚至运行时才显现。

## 知识转移曲线

人工干预被分为三种类型：A 类（显式指定平台机制，集中在早期）、B 类（指示工程原理方向）、C 类（仅要求 AI 自我检查和比较，主要在后期）。

![knowledge-transfer](https://cos.poetries.top/aiMonitor/1785540889798.webp)

两条曲线在 06-29 ~ 07-01 左右交叉；之后，AI 自主性成为主要工作模式。

"后期人工干预归零不是因为 AI 学会了编程，而是因为吸引子已被定义（吸引子的形式化定义见 §12）。方向正确后，AI 能自动推进。"

人力关注应该花在定义吸引子上，而不是监督执行。Mission Driver 处理后者。整个 22 天期间，只有 28 次人工干预，集中在项目早期。之后，随着吸引子稳定，人工干预降至零，AI 完全自主推进。

## 10. 循环工程原理

传统流水线假设每个步骤都是确定性的，但 AI 执行的本质是概率性的——同一个提示在不同会话中可能产生不同结果。

循环嵌套的优势：失败是可预期的（循环原生支持重试和跳过）、质量是迭代的（审计发现导致改进）、恢复是自然的（检查点是磁盘上的复选框）、隔离是结构性的（子流边界 = 容错边界）。

循环工程的三个基本原则是：轨迹可恢复性（持久化到磁盘，通过磁盘扫描崩溃恢复）、局部容错性（子任务失败不传播到父循环）和独立验证（完成由独立子智能体审计，不由执行者自检）。

恢复不是重放（不重新执行历史步骤），而是磁盘扫描（扫描磁盘标记）。启动时，引擎扫描 plansDir 中的 .md 文件，找到 Status: active 的计划，读取复选框（[x] skipped，[ ] resumed）。run-state.json 中的步骤历史仅用于审计查看，不驱动恢复。

## 11. 计划循环和验证系统

每个计划的执行都有自己的内部控制循环——计划循环。

![plan-loop](https://cos.poetries.top/aiMonitor/1785540889943.webp)

核心原则：生成和验证必须分离。草案审查和关闭审计都由独立子智能体在新会话中执行；审计者不继承执行者的上下文，从全新的仓库读开始。

验证系统：脚本检查 + AI 自动改进

对计划是否完成的审计验证不是简单的机械检查或纯 AI 审计，而是两者的配对协作。脚本自动检测问题；发现问题时，AI 自动诊断和修复，然后重新运行检测。

EXECUTE (agent: AI executes plan) ↓ CLOSURE_SCRIPT_CHECK (script: checks checkboxes + evidence) ├── pass → BUILD_VERIFY └── fail → CLOSURE_AUDIT (independent sub-agent review) ├── fixable → back to EXECUTE └── not fixable → blocked items moved to Deferred/Follow-up rest of plan continues → completed BUILD_VERIFY (agent: AI runs test/build/lint) ├── failure → AI auto-diagnosis → fix → re-run └── pass → plan completed ✓

机器充当裁判，AI 充当改进者。

## 12. AGE 理论：吸引子与动力系统

Mission Driver 是 AGE（吸引子引导工程）理论在工具层面的核心实现：

State Space = repository/project 的所有可能状态 Attractor = 文档系统（设计/架构等标准化文档） 定义"系统长期应收敛到的稳定结构" Trajectory = 记录"我们如何到达当前状态"的计划、日志、审计 Control = 健康检查 + 执行验证 + 独立审计纠正偏差

注意路线图不是吸引子。路线图是人工可控的宏观计划，是吸引子的面向任务的投影；真正的吸引子是 docs 中的文档系统。

## 吸引子的形成

吸引子一开始并不清晰。它们经历一个从模糊到清晰的过程：

On