关于《Mission Driver：Loop Engineering 的一种通用参考实现》的补充说明

在我此前的文章《Mission Driver：Loop Engineering 的一种通用参考实现》中，我介绍了 Mission Driver 的设计原理与使用方式。它是吸引子引导工程（Attractor-Guided Engineering, AGE）在控制层的核心实现，负责 7×24 小时 AI 全自主运行。

但在实际应用中，我发现很多人习惯把它映射为自己熟知的概念------更复杂的工作流编排、Agent 编排器，或另一套 Harness 控制。这种理解没有真正触及 Mission Driver 的独特之处：网上常见的 Loop Engineering 实现大多是某种黑箱模型------AI 的内部状态对使用者不可见、不可控，人工介入只能停止循环并修改提示词；而 Mission Driver 把核心运行状态显性化为 roadmap 与 plan 文件（文件就是 AI 的认知），人工介入是异步的------可以直接修改 roadmap 或投放新的 plan，下一轮循环自动拾取。人机分工界面因此可以更加灵活：人可以审核 roadmap，AI 也能自主在 roadmap 中引入 audit 审计工作项。

另一个更根本的区别是，目前大部分 AI 工程都是面向单次任务的------包括 goal 驱动在内，都是针对单项任务进行组织。信息容器就是任务本身，任务完成、会话结束，信息便随之失效，这对长期演化运行来说是信息不充分的。AI 长时间（周甚至月）自主运行所依赖的方向引导，不能来自外部用户输入和用户监控，只能来源于项目自身的 Owner Doc 体系。AGE 的文档体系不是针对单个任务构建，而是面向整个领域结构空间：它定义系统长期应保持什么结构（期望吸引子）、哪个工件对什么问题拥有权威（Precedence）、什么证据证明什么承诺（Proof）、历史上做过什么关键决策（轨迹记忆），以及信息是否仍足以支撑自主行动（Freshness）。这些关系跨任务、跨会话持续有效------任何新的开发主体只依赖当前仓库，就能恢复同一套事实、权威、方向与轨迹，这正是 Mission Driver 能够长时间全自主运行的信息基础。

没有理解这些，就很难让 Mission Driver 全自主地运行起来，也难以用它实现超越 goal 驱动等 coding CLI 工具内置目标驱动机制的效果。本文是一份概念澄清，说明 Mission Driver 所在的概念体系（Loop Engineering / Attractor-Guided Engineering），回答它解决什么问题，以及为什么这样设计。

"文件就是 AI 的认知"并不是说文件等于AI运行的全部内部状态，而是说： 只有被外化、能够跨 Session 恢复并继续约束后续行动的认识，才构成长期自主系统可继承的项目认知。 Mission Driver 维持的不是某个 Agent 实例的连续存在，而是项目认知的持续可恢复性。

一、概念体系定位：Loop Engineering vs. Attractor Guided Engineering

1.1 Loop Engineering：业内的概括性表达，但没有回答"为什么能收敛"

Loop Engineering 是业内对 AI 自主运行当前能达到的阶段的概括性表达。Andrew Ng 的三层 Loop 模型（Agentic Coding 分钟级、Developer Feedback 小时级、External Feedback 天/周级）、Boris Cherny 的"我不再写 prompt 了，我改成设计写 prompt 的系统------我在写 Loop"，共同把 loop 认定为自主运行的核心机制。

这个概括本身没有问题。但它只描述了"自主运行需要采用什么执行形态"，没有回答两个更深的问题：

loop 为什么能稳定存在，以致趋于收敛？ 在 loop 持续运行期间，人与 AI 如何交互？

这两个问题在实际工程中暴露得很直接。很多号称 loop 驱动的系统，方向、裁决、纠偏其实都来自循环外的人------用户一边看输出一边做决定，跟 vibe coding 并没有本质区别。而当人需要介入时，又往往面对一个黑箱：不知道 AI 当前处于什么状态、依据什么做出当前判断。想调整行为，通常只能停止循环、修改提示词，然后重来。

这两个缺口来自同一个根源：loop 只是一个执行结构。方向、状态、轨迹------这些让系统能够自我校正的东西，不在 loop 的范畴之内。

1.2 AGE：回答"loop 为什么能稳定存在以致收敛"

AGE（Attractor-Guided Engineering，吸引子引导工程）是为回答上一节那两个缺口而建立的概念体系。它的核心是四个概念：状态空间（系统演化过程所有可能出现的结构）、吸引子（系统长期应稳定趋向的结构）、轨迹（系统实际上怎样走到了现在）、控制（测量与纠偏机制如何把轨迹拉回吸引子附近）。

AGE的详细介绍参见 Attractor Before Harness: AI 大规模开发的方法论

在这个概念体系中，"持续运行"不再是目的，而是方向已经被外化后的自然结果。loop 之所以能稳定存在并趋于收敛，不是因为循环设计得有多精巧，而是因为三个时间维度上的机制已经就位：

• 运行之前，docs 体系已经建立------明确区分规范性文档与时效性文档，确保 AI 面对的信息源具有明确的权威定义和更新策略：规范性文档（architecture / design 等稳定 Owner Docs）定义"系统长期应该是什么"------期望吸引子与权威归属，不带日期、原地更新，其有效性不随时间衰减；时效性文档（plans / logs / audits / analysis 等过程记录）描述"某个时间窗口内实际发生了什么、当前状态如何"------带日期、只在有效窗口内可信，过期后必须重新验证（freshness）才能继续支撑自主行动；两者之间以及规范性文档相互之间的冲突，都以 Precedence 定义的权威归属为准------按 Owner 与作用域规定的优先级裁决，而非按更新时间或取用便利性裁决；
• 运行之中，AI 的内部状态和认知被显性化------roadmap / plan / audits 文件就是它的认知，人不需要猜 AI 在想什么；人的介入有标准方案：直接修改 roadmap 或增删 plan，下一轮循环自动拾取，无需停止 loop 或修改提示词；logs 同步记录每轮执行的关键决策与验证结果，沉淀为可追溯的轨迹。介入不再是黑箱，也不需要打断运行。
• 运行之后，经验被提炼并反哺------AI 可以从 logs / plans / audits 中挖掘本轮经验：人工纠正的模式沉淀为 skill，审计遗漏的维度补入审计提示词，重复失败提升为 lessons（nop-app-erp 展示了具体的实践案例）；Mission Driver 的 postmortem 复盘还会把报告写入 memory，后续同模块 mission 自动加载。循环因此不只是重复执行，而是持续学习。

长期连续性来自认知恢复，而不是 Session 延续

单个 Session 的认知不是时间平移不变的。时刻 t 形成的临时认识，不能被假定为在时刻 t+1 的新 Session 中自然存在。

长期自主运行必须满足更严格的条件：

在任意合理的中断点启动一个新的执行主体，它都能够仅依据当前项目状态，恢复继续同一条工程轨迹所需的认知。

其过程可以表示为：
$$Ct\to Actiont\to Validatet\to \; Rt+1\; \to Recover\to \; Ct+1\; C\_t\backslash rightarrow\; Action\_t\; \backslash rightarrow\; Validate\_t\; \backslash rightarrow\; R\_\{t+1\}\; \backslash rightarrow\; Recover\; \backslash rightarrow\; C\_\{t+1\}$$ Ct→Actiont→Validatet→Rt+1→Recover→Ct+1

其中：

• $Ct\; C\_t$ Ct 是当前 Session 恢复出的临时认知；
• $Rt+1\; R\_\{t+1\}$ Rt+1 是经过验证和写回后的项目认知结构；
• $Ct+1\; C\_\{t+1\}$ Ct+1 不是对 $Ct\; C\_t$ Ct 的直接复制，而是新 Session 根据 $Rt+1\; R\_\{t+1\}$ Rt+1 重新形成的行动认知。

因此，AGE 不要求保存每个 Session 的完整推理过程，也不要求回放全部历史。它要求当前仓库保存对后续行动足够的认知结构。

1.3 Mission Driver：对 Loop Engineering 的通用实现，在 AGE 概念体系下定义状态与演化

Mission Driver 落实了 Loop Engineering 的核心主张：不写 prompt，而是写一个 loop，让它不断产生 prompt。它可以看作是对 Loop Engineering 的一种通用实现------底层是一个通用的 Flow DSL 运行引擎，每一轮循环为下一个 AI 步骤重新构建 prompt，占位符（{{planGuide}}、{{roadmapPath}}、{{plansDir}}、{{testCmd}}）从配置变量表注入实际值。换一个 flow 文件就能适配不同场景，人不再逐个手写提示词，而是设计、配置和监控 loop 本身。

在概念体系上，Mission Driver 是 AGE 框架下的一种全自动运行机制。两者的分工很清楚：loop 的执行结构由 Loop Engineering 提供，状态管理和演化规则由 AGE 定义。Mission Driver 运行于由 docs 体系承载的吸引子定义之上（期望吸引子由 docs 体系外化承载，Mission Driver 依赖而非自行定义方向），并驱动 Plan 走完从审查、执行、验证到审计的完整生命周期。它不是一般意义上的 Harness，而是在吸引子引导下根据 roadmap 执行的持续编排器。这也是它区别于"只实现了 loop 结构"的其他引擎的地方。从运行形式看，Mission Driver 编排的是 work item 与 plan------DRAFT_PLANS 把 roadmap 中的 work item 投影为 plan，EXEC_PLANS 驱动 plan 走过执行、检查、审计的完整闭环；而这个闭环在 AGE 中承载的正是 Harness 的功能（测量与纠偏）。

Mission Driver 与 Harness、AGE 的界限是：

• Harness（Agent = Model + Harness）。在 Harness Engineering 的理解中，harness 是模型之外的一切------引导文件（AGENTS.md 等指令）、上下文工程（任务相关的信息供给）、传感器（lint / typecheck / 安全扫描等自动检查）、护栏（Guardrail：文件名规范、"不准绕过 ORM 直接写 SQL"等边界规则）、验证闸门（测试与构建门禁）、监控（人工审查）与反馈循环（把纠正工程化，使同一错误结构性不可再犯）。在 AGE 中，Plan Loop、测试、Closure Gates、独立审计、DEEP_AUDIT 与轨迹纠偏扮演的就是 Harness 的角色------它们测量实际轨迹、判断偏差、并把偏离拉回。Harness 解决"当前轨迹是否偏离、如何纠偏"，但 Harness 本身不定义"应该回到哪里"。
• AGE 定义了吸引子，并赋予 Harness 长期演化方向与收敛标准 ------收敛机制（Closure Gates、独立审计、DEEP_AUDIT、轨迹纠偏）在结构上就是 Harness。AGE 的增量不在机制本身，而在两层 Harness 自身不携带的信息：其一是方向依据------期望吸引子定义"应该回到哪里"，它不是某一条规则，而是由少数高价值结构约束共同界定的允许结构区域（如 nop-app-erp 的"每域一份 <domain>/model/*.orm.xml 是持久化模型唯一真相源"、"模块依赖为单向 DAG、跨域引用走 R/S/P 契约"、"docStatus × approveStatus × posted 三轴正交状态分离"等约束共同界定），Attractor Before Harness 意味着先有它，才能决定 Harness 测什么、拒绝什么、把偏离拉回哪里；其二是收敛定义------收敛不是静态合规，而是动力学性质：系统在持续扰动（需求变化、AI 生成扩张、重构、外部反馈）下，长期轨迹反复回到吸引子定义的结构区域附近（"关键不是永远停在 X，而是偏离后仍能回到 X 附近"）；判定依据不是单次截面合规------一次检查通过只说明当前截面没暴露问题，只有偏离被识别、记录为未关闭义务、后续工作持续推动回归，才能说明系统具备收敛。

这种定义在运行中表现为四个可观察的机制设计：

1. 状态显性化：roadmap / plan / audits 等文件显性化 AI 的内部运行状态与认知------人不需要猜 AI 在想什么，文件就是它的认知。这正是对"黑箱介入"的回答。
2. 不停循环的介入：人工介入可以在不停止 loop 的情况下直接修改或新增 plan、修改 roadmap------REVIEW_PLANS 自动拾取任何 Status=draft 的 Plan，DRAFT_PLANS 读取最新路线图。这正是对"必须停 loop 改 prompt"的回答。
3. 轨迹的充分统计量：通过 logs 可以在不依赖 git 历史的情况下记录核心轨迹信息------所有关键决策都可以通过少量类似"充分统计量"的记录快速归档，新主体不必考古历史提交就能恢复关键演化认知。
4. 审计反哺：审计历史可以反向抽取各种 skill，改进后续工作------每一轮深度审计的发现都会沉淀为后续循环可加载的经验。

AGE 的完整机制链可以压缩为：

期望吸引子定义长期结构
Trajectory 记录实际演化
Plan 关闭局部轨迹
Harness 提供测量和纠偏
Mission Driver 自动编排 Plan
仓库承载跨会话事实与记忆

nop-app-erp 就是这套机制运行的明确示例：22 天（06-22 → 07-13）、187 份 Plan（07-01 起计）全部双审计通过，人工介入从早期的高频平台机制纠正（06-22 单日 7 条）衰减至 07-14 后为零。这是一个典型的知识转移过程：用户介入分三类------A 类（明确指明 Nop 平台机制，集中在早期 06-22 ~ 06-26）、B 类（指明工程原则方向，如过账引擎 DDD 原则与架构文档元规则，集中在中期 06-29 ~ 07-01）、C 类（只要求 AI 自查对比、不暗示答案，后期 07-04 之后占绝大多数）；A 类频次下降与 AI 自主度上升两条曲线在 06-29 ~ 07-01 交叉，此后 AI 自主成为主要工作模式。被转移的知识沉淀在 19 个可复用 skill、docs-for-ai 补充与 lessons 教训中，构成自运转的知识基座------正如项目复盘所言："用户不是在写代码，而是在转移平台知识，一旦知识转移完成，介入频率自动归零"，介入归零不是因为 AI 学会了写代码，而是因为吸引子已经定义好了。

把 Mission Driver 当成普通的 Agent 编排器，就丢失了它在 AGE 中的方向依据。但它本身也不拥有方向定义权，它只是控制层的执行机制，必须和外部的 docs 体系协同工作。

二、它解决什么问题

2.1 Vibe Coding 的两个结构性困境

Mission Driver 要解决的问题，始于 Vibe Coding 的困境。当前主流的 AI 辅助开发模式------人提示、AI 响应、人纠正、AI 再响应------本质上是一个没有退出条件的无限循环。这个模式有两个问题（细节见《Mission Driver：Loop Engineering 的一种通用参考实现》第一部分）。

第一个是质量失控。AI 的执行本质上是概率采样过程，在没有外部控制结构介入时，AI 很容易走上岔路：改到一半跑去改别的代码，改完忘记跑测试，失败了陷入死循环，进程崩溃后状态丢失只能从头再来。更危险的是自我宣称完成------跳过实际实现直接声称做完了。

第二个是产能限制。人在环中时，每一步都依赖人的触发和判断，最终瓶颈仍然是人的工作时间和精力。而 AI 可以 7×24 运行时，工时不再是制约因素------较弱的模型虽然慢，但足够便宜，可以夜间跑。成本结构从"每小时人时产出"变为"每美元智能产出"。要真正释放这一潜力，人必须从 loop 中退出，变成按需介入的控制因子，而不是每一步都参与的执行者。

2.2 从 Human In The Loop 到 Human On The Loop

Mission Driver 的目标不是"替代人"，而是"让人可以在任意时间点介入，但不需要在每一步都介入"。它把人的介入从"必须"变成了"可选"。

在 Vibe Coding 中，环中的每一步都依赖人的触发。Plan Loop 本身可以构成一张 Plan 从起草、审查、执行到关闭的最小自主闭环；但在只有 Plan Loop 的形态下，"下一步做什么"的编排问题（排序、状态推进、空档发现、深度审计触发）仍然依赖人。Mission Driver 的设计是把编排层架构在 Plan Loop 之上：Plan Loop 解决"一次变更如何可靠关闭"，Mission Driver Loop 解决"接下来该关闭哪一次变更"------人在 Mission Driver 中可以选择参与，但系统在没有人的干预下，也能从路线图的第一项走到最后一项。

这种可选参与直接回应了 1.1 指出的两个缺口：介入不面对黑箱（AI 的当前运行状态、认知与判断依据都显性化在 roadmap / plan / audits 文件中），介入也不需要停止 loop（直接改文件，下一轮循环自动拾取）------而不是"看不到状态、只能停循环改 prompt"。

这种可选参与的机制是异步的：plans/ 目录就是文件系统上的共享队列。人可以随时自己起草一张 Plan 放进队列，或修改某张 Plan 的状态（比如把误标为 active 的改回 draft）、调整路线图的优先级------下一轮循环的 REVIEW_PLANS 会自动拾取并审查，不区分 Plan 是机器起草的还是人手工创建的。人和 Mission Driver 在不同的时间尺度上工作（人可能每天集中处理一次，Mission Driver 每 4-12 小时自动完成一个完整循环），通过文件系统而不是即时通信交换状态。

这意味着它需要自动解决编排问题的四个子问题：

• 排序（Ordering）：大量变更的执行顺序。这不是可以静态预计算的调度表------每次变更完成后可能揭示新的依赖关系，使后面的顺序需要调整。排序需要的是一个可动态查询的路线图结构，而非一次性确定的甘特图。
• 状态（State）：每张 Plan 当前处于什么阶段------draft、active、执行中、completed？状态需要持久化在 Plan 文件自身中，使任何读取仓库的人（或下一轮循环）都能独立判断。
• 推进（Advancement）：谁来选择下一个工作项？谁来起草新的 Plan 并标记为 active？这个动作需要能自动执行，但执行结果的接受又需要独立审查来把关------推进和审计不能是同一个主体。
• 审计（Audit） ：路线图工作项耗尽（DRAFT_PLANS 返回 nothing）时，谁来触发深度审查？深度审计只有在执行主循环无新工作时介入，避免与正在推进的变更抢道。

在只有 Plan Loop、没有编排层的模式下，这四个问题都由人来回答。Mission Driver 的设计目标是把它们从人脑转移到机器------但它不替代 Plan Loop：它驱动并编排 Plan Loop，让每个最小自主闭环持续、有序地运转（嵌套关系见 3.4）。

关于"排序"所依赖的路线图，需要澄清它的性质：roadmap 只是 work 规划，不是 execution plan，也不是设计契约------work item 的粒度等于"一个 execution plan 的合理交付范围"，具体 work 依赖的信息（立项材料、设计契约、范围裁定）由 docs 体系中单独定义，而非塞进 roadmap 正文。roadmap 在运行中会动态演化：状态由 plan 生命周期回写、review gate 修正项回写，由人和 AI 共同维护；而且工作项并不需要在运行前全部确定------例如可以先行安排调研工作项，再根据调研报告拟制后续 work item。需要注意，不同任务类型允许的演化程度由各自的 roadmap guide 约束：一般情况下 guide 会明确要求 AI 不得跳序或新增 work item，以保证执行稳定；而对探索性任务，guide 可以允许 AI 根据中间产出（如调研报告）动态补充后续工作项。

2.3 与普通工作流引擎的区别

一个常见的误解是：Mission Driver 不过是一个自动化 Agent 编排器。这两者确实都是状态机引擎------步骤、转换、状态推进，形式上是同构的。但本质区别在于执行单元的性质和运行内容：普通工作流引擎执行确定性的既定步骤，Mission Driver 编排的是概率性 AI 步骤与动态生成的规划。

普通工作流引擎与 Mission Driver 在架构层面有三个根本区别：

维度	普通工作流引擎	Mission Driver
运行内容	设计时已确定的既定任务，流程定义即任务，无复杂规划层	roadmap 动态规划 work item，plan 定义单次变更的关闭契约，均在运行中生成
状态位置	引擎内部（运行时/引擎数据库），需查询引擎	仓库文件中（plan 的 status 与 checkbox），读仓库即可恢复，恢复逻辑也是 AI 智能判断执行
运行形态	一次运行消费一个确定实例，结束即止	面向 7×24 持续运行，可随时中断，重启后扫盘恢复而非 replay

三个区别中最根本的是执行单元的性质。普通工作流引擎编排的是确定性步骤：每一步是预先写好的代码或命令，输入确定、执行确定、成败确定，失败是异常，需要中断或人工介入。

Mission Driver 的 Flow DSL 有五种步骤类型：tool（shell 命令）和 script（JS 函数）是确定性的，group（子步骤的带轮次循环）和 subflow（递归子流程）是结构性编排，而 agent（spawn opencode 子进程）天然不确定 ------同一个 prompt 在不同 session 可能走不同路径、产生不同结果。正因为概率性步骤的存在，引擎的设计目标从"确定性执行"变为"在概率性执行中保证收敛"。这种收敛靠三层容错：

• 每个调用都是微循环 ：agent 步骤内部，marker（AI 输出中的 <AI_STEP_RESULT> 标签，引擎靠它驱动状态转换）提取失败不会直接判定失败------解析子代理（runParseAgent）会推断缺失的标签、调用 markerAliases 归一化容忍近义词，仍不匹配则 spawn 修正子进程输出合法值（最多 2 次）；进程被杀后走 onError 重试（默认 3 次）；瞬时 provider 错误（429/限流）走独立的指数退避重试预算。
• loop 嵌套 loop ：主循环（五步闭环）在外，内嵌 group（如 CLOSURE_VERIFY 的 script-check → AI-audit → 重检，最多 3 轮）与 subflow（EXEC_PLANS 的 plan-execution、DEEP_AUDIT 的 deep-audit-loop）；subflow 在同进程内递归创建新的 FlowEngine 实例，各自持有独立的 flowVars / visitCounts / retryCounts------整体结构上更接近递归的调用堆栈，而不是一条流水线。
• 容错是结构性的 ：每个步骤有独立的 maxRetries / onError / onMaxRetries；全局有 ping-pong 检测、maxCycleVisits、maxTotalSteps 防死循环；子流边界就是容错边界------一个 plan 的失败不传播到兄弟 plan。

两相对比：普通工作流引擎把失败当作异常（中断或人工介入），Mission Driver 把失败当作预期输入（重试、降级、隔离是默认路径）；前者追求确定性执行，后者追求在不确定性中维持收敛。

因此，Mission Driver 的准确定位是：

它是在吸引子引导下、按 roadmap 持续编排 work item 与 plan 生命周期的引擎，plan 的审查、执行、验证、审计闭环承载的正是 Harness 的功能，使这些控制过程脱离人的同步参与而长期运行。

最后，方向的位置也不同：普通工作流引擎的方向就在流程定义里（流程即任务）；Mission Driver 的通用 Flow DSL 只是执行骨架，方向外化于 docs 体系（期望吸引子），roadmap 则是吸引子的任务化投影而非方向本身。它不会凭自身定义：项目应该成为什么、哪份 Owner Doc 有权修改结构基线、哪个 Proof Relation 才是正确的、某个偏离应当修实现还是修正 Attractor。如果这些关系尚未外化，Mission Driver 只能持续制造文件变化，不能保证这些变化属于同一条可接受轨迹（完整论述见 4.1）。

2.4 与业内同类实现（LoopX）的对比：共识与差异

LoopX, https://github.com/huangruiteng/loopx 是一个面向长周期 AI agent 的本地控制平面（local control plane），slogan 是"Keep the loop moving. Keep the judgment human."。它不替代 agent 运行时，而是以 agent-agnostic 的旁路控制层包围 Codex / Claude Code / Cursor 等外部运行时，用一个持久状态内核承载 lifetime goal、gates、todos、evidence、quota 与 handoff------让目标、判断、证据和成本在多轮、多 agent 之间不漂移。它明确声明自己不是 autonomous production controller，危险权限与最终所有权始终属于人类。

它同样是 Loop Engineering 的一种具体实现，与 Mission Driver 一样都尝试解决"让 AI 长时间运行可治理"这一问题。两者在 Loop Engineering 的工程层面高度一致，差异集中在理论层、自动化边界与架构取向。

工程层共识（LoopX 与 Mission Driver 相同的判断）：

共识	LoopX 的表述	Mission Driver 的表述
聊天记忆不是长期任务的事实源	"Chat memory and a timer are not enough to govern that"	logs 在不依赖 git 历史的情况下记录核心轨迹，"文件就是它的认知"
Human On The Loop：人的介入从"必须"变成"可选"	"Human-in-the-loop 不应该等价于每隔几分钟让用户确认一次"	人可以选择参与，但系统在没有人的干预下也能从路线图第一项走到最后一项
有界回合 + 验证后写回才算完成	"Validate and write durable state before spending"；反对把"旁路有进展"写成"gate 已解决"	Closure Gates 拒绝"Checkbox 全勾"式的虚假完成，DEEP_AUDIT 可推翻已完成结论
更长的运行不等于更好的产品	"没有更好状态管理的长 loop，只会制造更大的漂移"	"固定目标、固定反馈且不能改写自身结构的 Loop 只是伺服机构"
证据要紧凑、可检查、可恢复、可接手	compact artifact、run index、handoff，让"下一轮 agent 能恢复上下文"	Plan 关闭契约定义"从哪开始、允许什么、在哪闭合、什么证据足以证明闭合"

差异集中在三点：

1. 理论层：AGE 的吸引子体系是理论上的独特增量 。LoopX 自我定位为控制平面而非方向来源：quota should-run 是 compute guard 而非 strategy selector------目标、边界与验收由用户在 goal 文本中给出，控制层只负责让这些目标在多轮、多 agent、多运行时之间不漂移。LoopX 认同方向基线的缺口是真实的，但选择以最小合同方式补充（如绑定 authority material revision 到 admission/checkpoint），保持 provider-neutral（仓库 owner docs 只是 provider 之一）。Mission Driver 所在的概念体系则前进一步：期望吸引子定义长期结构、Trajectory 记录实际演化、Harness 提供测量与纠偏，方向前提被外化为仓库结构（Owner Docs 中的结构不变量等）。Andrew Ng 的三层 Loop 模型中 External Feedback 对应的是 Mission Loop 层（天/周级信号响应），LoopX 的 quota/gate 机制也是信号响应层，二者都没有显式的、外化为仓库结构的期望吸引子定义和收敛机制。

2. 自动化边界的设计不同。LoopX 在架构层面把人的判断做成一等公民------人的判断（reward、gate、quota、注意力成本）保留在运行层的每个环节，"Quota 保护的不只是算力，也是人的注意力"；同时 LoopX 明确反对默认提交完整 reasoning、prompt、raw trajectory------担心隐私泄露、仓库膨胀和双重状态权威，Todo/claim/gate/receipt 保持 kernel-owned。Mission Driver 则把人类治理限定在方向层（期望吸引子、Owner Docs），执行与编排层追求无人值守：7×24 运行、每 4-12 小时自动完成一个完整循环、人工介入从早期高频衰减至后期为零，所有状态（plan/log/audit/skill）全部文件化在仓库中。但两者并非实质冲突：LoopX 的"判断贯穿运行层"对应的是 Mission Driver 概念体系中"不定义方向"的边界（第四章），而"自动执行与编排"对应可自动化前两层（第五章）------差别在于人类判断在运行链中的保留位置。

3. 架构取向不同。LoopX 是 agent-agnostic 的旁路控制层：以 in_loop / wrapper / passive_posthoc 三种适配深度包围外部运行时，用 append-only 事件 ledger 作为真相、当前状态只是投影，并引入 quota 分配与 peer claim/lease 多 agent 协作；方向基线保持 provider-neutral（仓库 docs、私有 wiki、本地 owner docs 均可），状态保持 kernel-owned。Mission Driver 是自包含的 Flow DSL 引擎 + 编排器：文件系统即唯一真相层、零 IPC、断点恢复靠磁盘扫描，子代理以 Fresh Session 隔离，但无事件 ledger 与 peer/lease 概念。两者解决同一类问题的不同子集------LoopX 侧重多运行时、多 agent 的资源治理，Mission Driver 侧重单项目内闭环的可靠推进与方向一致性。

小结：两者在 Loop Engineering 的工程层（状态持久化、有界回合、证据可恢复）高度一致；差异在于 AGE 把方向外化为仓库结构并定义收敛机制，Mission Driver 以全文件化路线追求无人值守自主运行。

三、为什么这样设计：内部设计思想

如果只看执行形式，Mission Driver 的五个步骤和任意一个任务编排器没有区别。它的设计价值在于每一层机制都对应一个必须解决的问题。下面按"从局部到整体"的顺序展开。

3.1 Plan 是关闭契约，也是中间状态合法性的管理器

解决的问题：Vibe Coding 没有退出条件。

Plan Loop 的核心是 Plan。Plan 不是任务清单------它是 AI 自主执行的基本单位，是一份关闭契约。它包含三个核心要素和一个辅助项：

• 当前基线（Current Baseline）：从仓库读，不靠记忆。这是 Plan 的起点锚点，让审查者可以独立判断 Plan 承诺的变更量是否与仓库现状匹配。
• 目标集（Goals + Non-Goals）：明确做什么，更重要的，不做什么。Non-Goals 防止执行中 Scope Creep，也防止审查者用 Plan 未承诺的标准来评估交付。
• 退出标准（Exit Criteria + Closure Gates）：可观察的完成条件，每项之后都有一个小方框等待被打勾。不是"功能做完"这种无法判定的描述。
• 辅助项：审查记录（Draft Review Record）：独立审查迭代的过程记录，使 Plan 的演化过程可追溯。

在跨会话场景中 Plan 同时管理着中间状态的合法性：

一次迁移进行到一半时，仓库可能同时存在旧接口、新接口、兼容层、临时测试、部分迁移模块和过渡文档。原执行者知道这些是中间状态，但下一个 Session 只能读取当前仓库。如果没有显式 Plan，下一个主体很可能把这些临时结构理解成正式架构------于是，中间状态无需经过任何裁决，就能通过后续扩张逐渐获得长期合法性。

Closure Plan 正是为了阻止这种无声升级。它回答的不是"要做哪些事情"，而是：

这一段局部轨迹从哪里开始，允许发生什么变化，必须在哪里闭合，以及什么证据足以证明闭合。

普通任务列表关注"做了什么"；Plan 关注"当前仓库中的哪些现实仍然只是过渡状态，尚未获得成为长期基线的资格"。因此，Plan 的核心不是管理工作量，而是管理对中间状态合法性的裁决。

3.2 生成与验收分离：重建认识独立性，而不是重复检查

解决的问题：同一个上下文生成的证据会逐步偏向某一概率分布。 （上下文中包含的错误信息多了之后甚至可能诱导 AI 误以为你要生成错误样本）

AI 可以在同一个上下文中生成代码、测试、文档、Plan 更新、完成说明和自我审查结论。如果最初理解发生偏差，这些产出可以彼此一致，却共同指向错误方向------它们不会互相矛盾，却可能共同偏离真实需求或长期结构。

因此，Fresh Session 和独立 Audit 的意义不是"再看一遍"，而是切断验收对生成者完成叙事的直接继承。验收者必须重新读取 live repository、当前 Owner Docs、Plan 义务、Proof Evidence 和未关闭冲突，从外部证据开始判断。

但独立会话不等于最终真理。Fresh Session 仍然不是绝对客观的第三方------相同模型、相同资料和相似 Prompt 仍可能产生相关错误。可靠性还需要来自可执行检查、属性测试、E2E、真实运行证据、不同模型或不同工具、领域专家和用户反馈的证据层次。

这里还必须指出一个更隐蔽的陷阱：测试通过不等于语义承诺已经被证明。测试只有在与某项承诺保持有效关系时，才构成 Proof。假设系统的真实承诺是"Spreadsheet 在任意数据规模下正确呈现当前可见行"，旧实现一次挂载全部行，因此测试写成"断言 30 个 row headers 同时存在"。当实现改为虚拟化后，这个测试可能仍然稳定、清晰，却已经不再证明原始行为------它开始保护旧实现细节。这就是 Proof Drift：

测试仍然存在
测试可能仍然通过
但测试与原始语义承诺之间的证明关系已经断裂

AGE 要维护的不是简单的"代码 ↔ 测试"，而是"语义承诺 → 可观察后果 → 证明证据"。

3.3 工程实现：文件化、断点恢复与子流隔离

2.3 已概括了文件化状态与循环嵌套的结构特征。这里补充三个 2.3 未展开的工程细节。

注入机制------跨项目复用。 Prompt 模板包含 {{planGuide}}、{{roadmapPath}}、{{plansDir}}、{{testCmd}} 等占位符，引擎从 mission 配置变量表注入实际值。换项目时只需修改 JSON 配置，不需修改 prompt 逻辑------"项目结构"与"prompt 结构"两个关注点被分离。

断点恢复------disk scan，不是 replay。 进程崩溃后重启，引擎不回放历史步骤，而是扫描磁盘上 Plan 的 status 行和 checkbox 标记，直接跳到断点继续。这也是主流程步骤之间不传参数的原因：各步骤只依赖 plan 文件传递信息，CHECK 不知道 REVIEW_PLANS 发现了几张 Plan，每个步骤从磁盘读取输入、写回输出。

零 IPC------可观测性。 没有进程间通信、消息队列或数据库。要判断"系统当前处于什么状态"，只需读文件------执行和审计共享同一个真相层。

子流隔离的具体表现。 假设有 3 个 active plan，plan-002 执行重试 3 次仍失败------执行 agent 发现某个前提不成立，将阻塞项移至 Deferred But Adjudicated 并记录触发条件，其余 Phase 继续完成。plan-002 的阻塞完全不传播到 plan-001 和 plan-003。重试通常续用同一会话以保留执行上下文，与 3.2 的"审计者必须开新会话从零读仓库"是两种不同场景。

3.4 循环即智能：多时间尺度、结构记忆与递归闭环

"循环即智能"不是说机械重复会产生智能------固定目标、固定反馈和固定控制规则的单一 Loop，只是一个伺服机构。

智能的本质，是一个系统围绕某种组织同一性，在不确定环境中运行多时间尺度的感知---预测---行动闭环，将反馈沉淀为结构记忆，并递归修正自身模型、控制方式和结构边界的能力。

在 AGE 中，这表现为不同时间尺度的闭环层叠：

• 执行级 Loop（秒至分钟）：捕获错误、诊断、修复和重试；
• Plan Loop（小时至天）：通过审查、执行、Proof 和 Closure Audit，判断一次变更能否有效关闭；
• Mission Loop（天至周）：编排多个 Plan，识别跨模块缺口和累积偏离；
• Attractor 演化 Loop（更长周期）：根据长期轨迹判断应修正实现、Harness，还是 Attractor 本身。

多时间尺度解决了稳定与适应之间的矛盾。只有快速 Loop，系统会把所有问题都当作局部异常，不断堆积补丁；只有慢速 Loop，系统又无法及时吸收扰动。较快闭环处理当前偏差，较慢闭环判断这些偏差长期累积后意味着什么。

同一个信号在不同层次上可能具有不同含义：

测试失败
→ 可能是实现错误
→ 可能是 Plan 前提错误
→ 可能是 Harness 测错了对象
→ 也可能是 Attractor 本身需要修正

Loop 从"重复"变成"学习"的关键是结构记忆。一轮闭环不能只留下成功或失败，而要把认识写回当前仓库，改变后续闭环的目标、约束和可选路径：

发现偏差
→ 修复当前实现
→ 将通用认识写入 Logs、Bugs、Audits、Skills 或 Owner Docs
→ 更新测试、Plan Guide 或审计规则
→ 后续 Loop 在新的结构条件下运行

Owner Docs、Logs、Plans、Bugs、Audits 和 Analysis 不是附属文档，而是不同时间尺度之间传递认知结果的结构记忆。经验如果只留在一次对话中，系统只是完成了一次反应；经验进入仓库并改变后续控制条件，系统才发生了学习。

Loop 只保证系统在给定反馈下趋向稳态，并不保证反馈和目标正确。因此，智能系统还需要：多个相对独立的评估信号进行交叉验证；Fresh Session 和独立审计降低同源偏差；Meta-Loop 检查测试、Plan、Harness 和 Owner Docs 是否已经漂移；可中断机制允许较慢 Loop 暂停、推翻或重新定义较快 Loop 的目标。

Attractor 也不在 Loop 之外。它与闭环层叠形成递归关系：Attractor 约束较快 Loop → Loop 产生实际轨迹 → 轨迹沉淀为结构记忆 → 较慢 Loop 读取长期积累 → 必要时修正 Harness 或 Attractor → 新的结构条件进入下一轮执行。

从 AGE 的视角看，智能不是一个固定目标下的单层 Loop，而是受 Attractor 引导、跨多个时间尺度运行、能够自我修正并积累结构记忆的递归闭环层叠。固定目标、固定反馈且不能改写自身结构的 Loop 只是伺服机构；当不同层次的闭环能够交叉验证反馈，并将经验写回模型、控制规则与结构边界时，系统才从重复执行走向学习、适应和演化。

四、它的边界：Mission Driver 不能做什么

4.1 它不定义方向

主流程每一步是否有意义，取决于它们在读取什么方向：

• REVIEW 根据什么判断 Plan 是否合理？
• EXEC 根据什么选择实现结构？
• CLOSURE_AUDIT（EXEC_PLANS 子流中的结束审计）根据什么判断完成？
• DEEP_AUDIT 根据什么识别系统性偏离？
• DRAFT 根据什么把 Roadmap 投影为下一轮工作？

如果答案只是"根据当前代码和现有测试"，那么 Mission Driver 可能只是高效复制当前基线。如果当前基线本身已经偏离，它会更快地固化错误。

Mission Driver 能保证 Loop 持续推进，但不能单独保证轨迹方向正确。

4.2 写入 Owner Docs 不等于拥有吸引子：期望吸引子与实际吸引子

"系统应该收敛到哪里"和"系统实际上会收敛到哪里"实际上是有区别的。

期望吸引子回答"系统在持续演化中，应该反复保持或重新回到什么结构附近？"它由少量高价值的结构关系定义（某个模型是领域事实的唯一来源、Template 与 Instance 分离、Data 与 Capability 正交、模块遵守明确的依赖方向、核心原语形成闭集......）。期望吸引子通常由 Owner Docs 承载，但 Owner Docs 不是吸引子本身------文档只是把这些结构关系变成可版本化、可路由、可审计和可修改的工程表示。

实际吸引子回答另一个问题："在当前代码基线、开发习惯、测试、CI、Plan、Review、Agent 行为和组织激励共同作用下，项目实际上会反复回到什么结构？"实际吸引子不是当前代码------当前代码只是状态空间中的一个状态；实际吸引子是一种通过长期轨迹才能识别的演化倾向。

例如，Owner Docs 可能规定"领域模型必须拥有唯一事实来源"。但如果各模块复制模型最方便、测试只验证模块内部自洽、Review 不检查跨模块语义重复、计划按局部功能关闭、复制产生的成本被推迟到未来------那么项目的实际吸引结构可能是"每个模块都维护一套局部模型"。

因此，AGE 的目标是让二者逐步对齐：定义期望吸引子 → 将其外化为仓库语义结构 → 根据它设计 Harness → Harness 改变实际演化规则 → 观察长期轨迹 → 判断实际吸引子是否接近期望吸引子 → 修正实现、Harness 或期望吸引子。

当前状态符合 Owner Docs，不足以证明实际吸引子已经对齐。一次检查通过只说明当前截面没有暴露问题；只有经过持续扰动、偏离和纠偏之后，系统仍能反复恢复关键结构，才能说明期望吸引子正在成为有效的工程吸引子。

4.3 它不是中性执行器

Mission Driver 不定义期望吸引子，但它会显著影响实际吸引子。原因在于，它决定哪些行为会被反复执行：哪类 Plan 会被优先处理、哪些证据足以关闭任务、何时启动深度审计、哪类问题会被重新送回执行队列、哪些失败会触发升级而不是自动修补。

如果 Mission Driver 只奖励"测试通过 + Checkbox 完成 + 当前任务关闭"，那么它可能把项目拉向"局部完成最大化"的实际吸引子。如果它持续读取 Owner Docs、Proof Relation、Closure Gates、Freshness、Independent Audit 和未关闭的轨迹义务，那么它才可能帮助实际吸引子逐渐接近期望吸引子。nop-app-erp 中独立审计曾多次推翻虚假完成声明（如 07-20 EXEC_PLANS 子流内第二轮审计 FAIL------执行者声称已补救"编辑生成文件"的违规，git diff 为空证明未发生任何修改）------正是独立审计这个偏置源，把局部完成最大化拉回向真实结构收敛，才使得实际吸引子没有漂向"完成任务的数量"。

这也意味着 Mission Driver 自身必须接受 Meta-Audit：

• 它是否长期偏好容易关闭的任务？
• 它是否忽略难以自动证明的结构问题？
• 它是否把当前测试误当成最终标准？
• 它是否不断复制当前基线？
• 它是否能够识别 Harness Drift？
• 它是否在信息不新鲜时降低自主度？

4.4 它是对 AGE 完整性的压力测试

虽然 Mission Driver 不是 AGE 的理论起点，它却能快速暴露 AGE 是否真正落地。

在人工协作中，许多缺口可以被人的临时解释掩盖：文档冲突时，人知道该听谁的；Plan 不完整时，人会口头补充；测试过时时，人知道暂时忽略；中间状态未记录时，人记得后续清理；Owner 不明确时，架构师可以现场裁决。

Mission Driver 持续运行后，这些隐性补丁会消失，系统会暴露：路由不完整、Owner 不明确、Precedence 无法裁决、Plan 与 live repo 基线不符、Closure 只是 Checkbox、Proof 与语义承诺脱节、历史材料被误当成当前规范、临时结构没有退出义务、Freshness 不足却仍允许自动扩张。nop-app-erp 的 07-12 竞争杠杆审计是一个相关例子（该审计由人触发而非 Mission Driver 自动发起，但揭示的缺口相同）：子代理核实承诺的 8 个竞争优势，发现 2 个夸大、2 个缺口------从 Plan Loop 和 Mission Driver 的角度，每条对应的 Plan 都通过了审查，控制层没有失败；失败的是外化不足的方向定义层。它说明这类缺口最终只能靠方向定义层的持续外化被暴露和拦截，无论触发者是人是机。

因此，Mission Driver 不只是提高效率。它还在检验：

项目是否已经将足够多的方向、权威、证明和轨迹记忆外化，使其不再依赖某个同步在场的人进行解释。

如果答案是否定的，Mission Driver 越自动，漂移可能越快。

五、如何理解"AI 全自动开发"

"全自动"至少有三个不同层次。

1. 执行自动化：给定明确 Plan，AI 可以自主修改代码、编写测试、运行验证、修复失败并提交审计证据。
2. 编排自动化：给定 Roadmap 和 Attractor，Mission Driver 可以自主起草 Plan、审查、排队执行、关闭任务、发现空档、启动深度审计并生成整改工作。
3. 方向自治：系统能够自主澄清模糊目标、提出新的结构语言、比较竞争性 Attractor、处理组织利益冲突并决定产品战略。

前两层已可实现高度自动化，第三层仍需明确的人类治理。nop-app-erp 案例中的"全自动"更准确地应理解为：方向和关键结构明确后，执行与编排层进入高自主运行，人从同步执行节点转变为异步方向与异常治理者。

六、总结

传统软件工程本质上是以人为核心的工程。人所扮演的角色相当于一个随时可以降临、随时可以打断、随时可以注入"正确答案"的全知全能的上帝。系统本身没有方向，没有自律，没有记忆。项目之所以不跑偏，不是因为系统具有内在的秩序，而是因为人一直在场，不断裁决、纠正、补充。每一次偏离，都靠上帝降下的神谕，把项目拉回轨道。

但 AI 7×24 小时自主运行，意味着上帝必须退场。人不可能永远站在系统旁边做那个隐形的架构师。于是，系统必须戒断对神谕的依赖，自己拥有内在的运行规律，成为一个物理世界中真实运行的物理系统：一个在状态空间中演化、受自身规律约束、可以被观测和控制的动力学系统。它的稳定性、收敛性、抗扰动能力，成为真实的动力系统演化问题，不再依赖上帝的临场判断。

在这个转变中，知识外化不是"能不能做到"的问题，而是必要的前提。因为 AI 大模型是无状态的，跨会话、跨进程、跨子代理的自主运行，必须依赖外部持久化的状态与规则。方向、权威、证明、轨迹、新鲜度------这些关键信息如果不写进仓库，它们就不存在；如果它们不存在，系统就退化为等待神谕的空壳。外化或许不充分，但没有外化，就没有真正意义上的 AI 全自动运行。

而且，不能幻想更强的模型能替代外部知识。更强的模型能提供更多世界知识和单次对话中更多的判断与选择，但弱模型也能依靠更长的计算过程和外部 docs 补齐。对于一般工作而言，deepseek-v4-flash级别的智力水平已经基本足够，不同模型最终能实现的能力差异并不大，成本却可以大幅降低。世界知识本身会漂移，领域约束会变化，长期自主系统必须把外部 docs 作为可注入新知识的接口，让新的事实、新的边界、新的教训能源源不断地进入系统。因此，AI 掌握外部知识的能力，比模型内部记住了多少世界知识更重要。

Mission Driver 就是这个过程的执行器，也是一个检验器。它检验的不是"AI 能不能完成任务"，而是：当最后一个 session 结束、最后一个执行者离开之后，这个项目是否还知道自己是谁、要往哪里去、偏了怎么回来。方向、证明、记忆、裁决结构是否已经完整到足以让项目作为同一个项目继续演化下去。

不是让某个 Agent 记住项目，而是让项目本身不再遗忘自己。
曾经的问题：如何让 Agent 更稳定地长期工作。
真实的问题：如何让项目本身------文档、代码以及运行其上的 Mission Driver等工具------构成一个持续演化的主体