Loop 解决“继续”， Graph 解决“协作”，那“完成”由谁负责？

Exia2

从 Loop 到 Graph ，然后呢？

2026 年 7 月，Peter Steinberger 发了一条很短的帖子：

Are we still talking loops or did we shift to graphs yet?

这句话引发了近期关于 Loop 与 Graph Engineering 的讨论。

AnyPal 是一个面向软件工程的 Agent Harness ，目标是让 AI 参与需求拆解、任务执行、代码修改、测试验证、问题处理以及最终交付。 在实际开发过程中，我们逐渐发现，当 Agent 开始承担更长、更复杂的工程任务后，单纯让它“继续运行”并不能解决所有问题。

这个问题也正好对应了我们开发时遇到的一个实际问题：让 Agent 持续运行，与让复杂软件工程真正完成，并不是一回事。

Loop 解决持续行动，Graph 解决多个执行单元的拆分、并行与协作。但当任务跨越多个文件、模块和会话后，还需要处理依赖、状态、验证、冲突以及“什么才算完成”等问题。

AnyPal 的实践因此逐渐形成了一套分层机制：Loop 负责局部行动，Goal 负责会话内工作，Graph 负责运行时编排，而 Plan 、Issue 、依赖关系、Session 、Nudge 、Adversary 和验证证据负责维护更长期的工程状态。

本文不讨论 Loop 和 Graph 谁更先进，也不给 Graph Engineering 下行业定义，而是讨论：

如果 Loop 解决了“继续做”，Graph 解决了“怎么协作”，那么复杂软件工程中的“完成”，应该由什么来保证？

AnyPal：面向复杂工程的确定性交付体系

助推器、软件工程级逐级分解、依赖并行、会话隔离，以及与 Graph Engineering 的对照

摘要

传统智能体编程常围绕 loop 、goal 或近来流行的 graph 运转。Loop 直接应对的一个问题，是大语言模型输出 EOS 的时机具有随机性：任务明明未完成，模型却可能在阶段性总结后结束。最简单的 loop 会追加一句“继续”，机械地让模型续跑。Goal 加入动态目标与会话内 Todo ，但它仍是一组随实时上下文变化的提示词状态。Graph 则把多个 agent 画成节点与边：拆任务、并行派活、汇总合成，并预先画好失败跳转。任务越长，系统越需要压缩上下文；压缩是有损的，早期细节、隐含约束、失败经验和验收边界会逐步丢失。

AnyPal 推出的“计划与敏捷”解决的不是“怎样让模型多输出几轮”或“怎样把更多 agent 画成一张跑得起来的图”，而是“怎样用确定性状态推动复杂工程真正完成”。用户只需向 AI 工程经理描述大局需求；工单、依赖关系与 Sprint 由 Lead 与系统整理，用户不编写看板。工单内 Todo 是任务级拆解，Sprint 是工程级拆解。它以 助推器（ Nudge Fixture ，由 AnyPal 提出） 为推进器：根据待办是否收敛、依赖是否满足、验证是否通过、评审 block 是否关闭、隔离变更是否合并等机器可观察事实触发定向提醒。同时，它把长期目标外化为 Plan 、Issue 、Sprint 、依赖图、角色责任、会话链接、检查项和交付证据，让每一个被锁定的执行会话尽可能少做有损压缩。

一、背景与现状

1.1 智能体编程为何需要被续跑

大语言模型每轮生成必须在某处输出 EOS 。这个结束时机不像普通程序的 return 那样由完备业务条件严格决定，而受到采样、措辞、当前注意力与模型习惯影响。同一个未完成任务，模型有时会继续调用工具，有时却在写完一段貌似完整的总结后停止。Agent loop 最早、最直接的价值，就是发现这次输出不应成为整个任务终点，再开启下一轮生成。

对于搜索函数、修改一处代码、运行一次测试等短任务，这种补偿简单有效。Loop 还允许模型根据工具观察实时调整路径：测试失败后读日志，搜索无结果后换关键词，用户补充要求后改变下一步。它把 LLM 从一次性回答器变成持续行动者。

1.2 当前主流做法：Loop 、Goal 与 Graph

当前智能体工具大多仍把 loop 、goal 或 graph 作为组织复杂任务的主路径。Loop 补偿随机 EOS ，让模型在阶段性输出后还能继续行动； Goal 把目标、实施步骤、验证步骤和当前状态注入会话，结构化 Todo 可以标记未开始、进行中、完成或阻塞，完成时要求提供证据。Graph 则宣称把单个全能员工换成一家公司：节点只干一件事，边负责交接，最常见的是菱形拓扑——派发、归约、合成。这比裸循环可靠，因为下一轮不再只是模糊“继续”；但它们仍没有把工程事实从一次运行的提示词或编排脚本里拿出来。

许多产品进一步把这些概念暴露给用户：选择循环次数、查看每一轮推理、手工点“继续”、自己维护目标清单，乃至自己决定拆分点、合并点和失败边。终端式 agent 往往强调每一轮推理、每一次续跑和每一个目标状态都由用户观察或干预。表面上自动化程度提高了，用户却很容易被迫成为 agent 的项目经理。计划与敏捷 的前提相反：用户只对 AI 工程经理说清大局需求，工程级拆分由系统完成。

1.3 工程交付的现实约束

真实工程任务很少停在单文件、单会话。一个需求可能修改十个模块、解决三条依赖、等待两个评审、处理一组合并冲突。行业现状是：短任务上 loop/goal 足够好用； graph 能把拆分、并行和汇总画出来，却仍把组织状态留在一次运行的编排脚本里。一旦跨文件、跨模块、跨角色、跨会话，系统既缺少路线图、交通规则、检查站和竣工验收，也缺少抵抗上下文压缩与并发覆盖的外部事实层。这正是 计划与敏捷 要进入的现场。

二、相关概念与理论

2.1 Loop：生成控制与持续行动

Loop 的理论对象是生成过程，不是工程组织。它回答的是“这次输出应否成为任务终点”，通过再开启一轮生成补偿随机 EOS 。它的单位是一次生成。续跑本身并不创造所有权、接口契约或完成门禁，因此应被视为局部动作引擎，而不是软件工程治理机制。

2.2 Goal：会话内工作集

Goal 的理论对象是一个会话。它把目标、实施步骤、验证步骤和状态做成可注入提示词，并要求会话结束前事项收敛。Goal 适合一个会话内的局部执行：步骤可见、依赖可声明、完成需证据。它的单位是一个会话目标，仍属于随实时上下文变化的提示词状态。

2.3 Graph Engineering：一次运行的编排形状

2026 年 7 月，OpenClaw 创始人 Peter Steinberger 问：我们还在聊 loop ，还是已经切到 graph ？随后“Graph Engineering”的定义引起了较大争议。微信文章《 Loop 已死，Graph 永生》把它说成：别让一个人干完所有事，开一家公司。节点是只干一件事的员工，边是写明交接的单据，状态是本次跑的账本，失败路由是应急预案。最常见的拓扑是菱形：拆任务、并行干活、汇总。手册还强调许多交接其实是免费的边——压平、去重这类事该交给代码，不该再花 token 。验证器专门试图推翻结果；没有失败边的图只是流程图。

Graph 的理论对象是一次运行的控制流。它回答“拆分点在哪、合并点在哪、失败后控制权去哪”，单位是节点与边组成的编排图。Claude 的 dynamic workflows 进一步让模型按目标现场画图，官方 /deep-research 也按定范围、并行搜索、抓取、对抗验证、合成这一骨架运行。这对检索、调研和可并行子查询有效。它仍然把组织状态留在本次编排里：节点完成不等于 Issue 完成，边交接不等于契约先行，账本清零不等于证据、评审和隔离合并同时收敛。

2.4 助推器：确定性推进器

Nudge 的字面意思是轻推，但 助推器 不是随便追加一句“请继续”。Fixture 表示稳定、可重复检查的结构化条件。系统先读取权威状态，再生成针对当前缺口的提醒。机械 loop 的触发依据是“模型输出了 EOS ，但系统猜测还没完”；助推器 的依据是“权威状态中存在具体、可枚举、尚未满足的完成条件”。前者只能说继续，后者能说继续什么、为什么继续、完成后拿什么证明。

一个成熟 fixture 至少包含触发条件、诊断内容、允许动作和解除条件。触发条件例如“存在非终态根任务”；诊断内容列出具体任务 ID 、当前状态和缺失证据；允许动作要求继续执行、取消并给出理由，或在需要用户决策时明确阻塞；解除条件则是所有工作项进入完成、取消或合法阻塞状态。四部分缺一不可，否则 nudge 仍可能退化为情绪化催促。

2.5 Plan 、Issue 与依赖图

Plan 是独立于会话存在的工程事实层，保存看板泳道、Sprint 、Issue 、优先级、依赖、关联会话、评论、评审和流水线状态。Issue 是最小可治理交付单元。高质量工单不仅写“实现导出”，还写明背景、范围、非目标、影响面、交互闭环和完成定义。超大任务被逐级分解：产品愿景成为 Epic ，Epic 分成 Feature ，Feature 再分成可独立实现、验证和合并的 Issue 。依赖用有向无环图表达：节点是工单，边表示必须先满足的条件，只有所有上游完成或提供稳定契约，节点才进入 ready 。

2.6 角色、隔离与冲突

Engineering Lead 负责把用户的大局需求转化为 Plan 、Sprint 和 Issue ，并整理依赖图；用户不编写工单。Coder 对工单端到端结果负责，并在工单内用 Todo 做任务级拆解； Adversary 独立寻找需求遗漏、正确性错误、安全风险和伪完成。Git 仓库可为会话建立独立 worktree 和分支，相关工单可通过共享 isolation key 附着到同一隔离分支。冲突至少有五类：文本冲突、结构冲突、行为冲突、计划冲突和资源冲突。协调消息分为普通 queued 与紧急 steer 。这些概念共同构成 计划与敏捷 的理论骨架：Loop 是局部动作引擎，Goal 是单会话工作集，Graph 是一次运行的编排形状，Nudge 是确定性收敛推进器，Plan 是持久化元数据，Issue 是可提交单元，依赖图是调度约束，隔离工作区是并发控制，Adversary 是独立一致性检查，合并与验收是提交协议。

三、存在的问题与缺陷分析

3.1 Loop 的能力边界

Loop 主要补偿随机 EOS ，而不是证明工程完成。机械续跑没有可靠回答“为什么未完成、下一轮具体完成什么、哪些证据满足后才允许停止”。若判断仍依赖模型自己的自述，系统只是用模型上一轮的话决定是否让同一个模型再说一轮。续跑只增加生成轮次，并不增加工程组织结构。循环一百轮也不会自动得到清晰所有权、稳定接口和完成门禁。Loop 可以让车继续行驶，却没有路线图、交通规则、检查站和竣工验收。“没有停止”不等于“朝正确终点推进”。

更机械的 loop 往往只发送模糊的“继续”或重放上一轮提示。若模型卡在错误假设上，这只会让错误路径延长；若依赖尚未满足，续跑会诱使模型编造接口；若真实验证需要外部环境，loop 可能反复总结静态代码。普通“继续”在每次注入后都可能被模型重新解释，产生重复编辑、重复测试甚至把已完成方案改坏。因此 EOS 重试是一种生成控制技术，不是软件工程治理机制。

3.2 Goal 与有损上下文

Goal 仍是一种实时变化的提示词状态。Todo 之外的大量解释仍在对话里：为什么采用方案甲，方案乙因何被否决；一个字段为什么必须向后兼容；某条错误路径为何必须真实运行；哪些文件是其他会话的边界。随着工具输出、源码、构建日志和新决策不断进入窗口，系统不得不压缩早期内容。

上下文压缩本质上是有损编码。摘要可以保留“正在实现登录”，却可能丢失“刷新令牌必须单次使用”“移动端入口与桌面端不同”“错误需在表单内联反馈”等细节。多轮压缩还会累积损失：十条约束变五条，五条再变三条，最后只剩目标大意。最危险的是模型不知道自己忘了什么，它会在残留摘要上生成连贯方案，并把偏离包装成合理完成。会话被压缩、结束、切换模型或迁移工作区后，依赖聊天解释的细节会断裂。把一个大 Goal 复制给多个会话更危险：每个会话形成自己的局部真相，可能同时修改公共文件或基于不同接口假设并行推进。

3.3 Graph 的能力边界

Graph 主要解决“谁先做、谁能同时做、做坏了往哪走”等运行时编排问题；而工程上的完成通常还需要独立的状态、验收和验证机制。节点与边通常活在一次运行的编排脚本里：账本是本次派活的进度，不是跨会话的看板、检查项和交付证据。菱形拓扑擅长把调研或检索拆成互不干扰的子任务再合成；软件交付里，子任务往往共享接口、公共文件、权限语义和测试夹具。三条并行边不会自动产生所有权切分，也不会自动发现文件重叠。失败路由若只写成“退回上一步、换备用节点、转人工”，仍缺少未收敛 Todo 、未关闭 block 、未合并隔离变更等可观察门禁。

文章自己也写清了代价：Graph 在引入多个执行单元后，通常也会增加上下文、token 和协调成本，问题定位还可能从单个执行过程扩展到整个编排过程。它更适合被理解为一种不同层次的组织方式，而不是简单的 loop 升级版。动态工作流让模型现场画图，只是把编排从人手交给同一次运行的模型，脚本仍会随压缩、换模型和会话结束而消失。嵌套 worker 用子智能体腾上下文，却把项目事实再次塞进短命报告。验证器若只是图内另一个节点，实现者与质疑者仍共享同一次编排假设。用户若被要求决定拆分点、合并点和失败边，就会再次变成 agent 的项目经理。

3.4 并行、冲突与伪完成

任务拆开并不自动获得并行能力。若 B 使用 A 的新接口，C 依赖 B 的数据结构，三个会话同时按各自猜测实现，只会放大返工。两个工单没有业务依赖，却可能都修改公共路由文件；它们逻辑上可并行，文件上却冲突。多个 Coder 直接写同一个工作树，可能被彼此的未完成代码、构建产物、依赖安装和格式化影响；修改同一文件时甚至会无声覆盖。传统流程常在最终 Git 合并时才发现文本冲突，而结构冲突、行为冲突、计划冲突和资源冲突往往更晚、更贵。

单 agent 主要依赖自我修正，实现者倾向维护自己的方案。模型可以声称“已完成”，但缺少构建、测试、真实运行或合并证据时，系统如果仍接受，就会把伪完成固化下来。许多智能体工具表面上提高了自动化程度，实际却创造了新的管理负担：用户要拆任务、重发上下文、监督模型是否偷懒、反复点击继续、协调多个 agent 、检查每个分支是否冲突。用户从写代码的人变成照看 AI 的人。若完成一项工作需要持续盯着 agent ，那么自动化只是把劳动换了形态。

3.5 治理本身也会失效

错误分解会制造更多冲突，缺失依赖会让下游过早启动，过度保守又会损失并行度；隔离工作区占用磁盘、缓存和端口；低质量 Adversary 会制造噪声；过期 Plan 会从外部记忆变成外部垃圾。文本冲突的自动合并成功只证明文本可组合，不证明行为正确。协调若只追求“冲突标记消失”，Git 虽干净，组织状态仍可能分裂。

四、AnyPal 的策略

4.1 总体思路：把完成从自述改成可观察状态

AnyPal 的“计划与敏捷”并不试图替代 loop 、goal 或 graph ，而是将它们放在不同层次。Loop 负责局部行动，Goal 负责会话内工作，Graph 主要承担运行时的派发、并行与汇总，Plan 则负责跨会话的工程状态。推进依据也从模型自述逐渐转向可观察、可检查的工程状态。系统不根据模型主观叙述判断是否继续，而根据待办是否收敛、依赖是否满足、验证是否通过、评审 block 是否关闭、隔离变更是否合并等机器可观察事实触发定向提醒。长期目标由 AI 工程经理外化为 Plan 、Issue 、Sprint 、依赖图、角色责任、会话链接、检查项和交付证据。用户只描述大局需求，不维护看板。



这些机制并不需要暴露给普通用户。用户只需要描述目标、查看进展并接收结果，任务拆解、状态监督、依赖调度和验证由系统负责。用户不需要先学习 agent loop 、选择循环次数、在模型随机 EOS 后手工点击“继续”，画拆分点与失败边，掌握上下文窗口、工具调用、压缩策略和验证层级。只需要像平常一样向 AI 工程经理描述目标、补充要求、查看进展和接收结果。技术复杂性应该尽可能由系统吸收，而不是要求用户理解内部运行机制。

一个实际案例

下面是 AnyPal 数据库插件的开发过程。

https://www.bilibili.com/video/BV1K2uD6jEcc

4.2 用 助推器编码工程政策

助推器 具有阶段性。计划阶段检查每个非终态任务是否预先写明实施步骤与 验证步骤，防止先编码后补验收；执行阶段检查当前项是否及时更新状态，防止 Todo 显示零完成而代码已漂移；验证阶段检查证据层级是否匹配，真实运行不能用单元测试冒充；收尾阶段检查所有事项是否 completed 、cancelled 或因真实用户输入 blocked 。不同阶段使用不同 fixture ，避免用一条万能“继续”覆盖所有失败类型。



确定性不等于僵化。Coder 仍可根据搜索与测试实时调整实现，用户也可改变目标；但目标变化必须更新计划，新增任务必须写清步骤与验证，取消任务必须记录原因。Nudge 约束的是状态转换完整性，而不是把实现路线写死。Fixture 还使流程具备幂等性：同一条件重复检查不会凭空创建新的工作，也不会把已经完成的事项重新打开；只有权威状态发生变化，下一次 nudge 才改变内容。

这种设计还允许把工程政策编码为确定性规则。例如，源代码修改后必须构建；大范围变更必须检查完整差异；隔离会话写入文件后必须合并；高风险 block 未解决不得完成；用户需求发生转向时必须就地更新计划而不能静默删除旧任务。这些规则不会因为模型在某轮“感觉差不多了”而失效。Nudge 与 Plan 的关系类似运行时检查与持久数据模型：Plan 提供事实，fixture 对事实执行约束，nudge 把违规状态转译为下一轮可行动指令。

4.3 与 Graph Engineering 对照

微信文章《 Loop 已死，Graph 永生》把 Graph 归结为一张可跑的派发图：节点是员工，边是交接，账本记录进度，失败路由预先画好。手册作者 Codez 已说明：Graph 不是 loop 的升级版，是 loop 的组织方式。AnyPal 的“计划与敏捷”并不否定这种组织方式，但不把“画得起来”当成交付。我们把拆分、并行与汇总写进持久 Plan 、Issue 与依赖图，把失败后的下一步写进助推器，把验证器写进独立 Adversary 与证据门禁，而不是再起一个同一跑内的对抗节点。用户向 AI 工程经理描述大局需求； Sprint 是工程级拆解，工单内 Todo 才是任务级拆解。



对照可以写成一组固定差异。Graph 的节点是一次运行里的 agent ，Plan 的节点是跨会话的 Issue ； Graph 的边是本次派活的交接单，Plan 的边是可计算的 dependsOn 与影响面； Graph 的状态是本次跑的账本，Plan 的状态是看板、检查项和交付证据； Graph 的失败路由是预画边，Plan 的推进是针对未满足门禁的 fixture ； Graph 的验证器是图内另一个节点，Plan 的 Adversary 是独立会话且带 topic key 与撤回协议； Graph 常用嵌套 worker 拔上下文，Plan 用会话级隔离与 worktree 。产品已将嵌套 run_subagent 永久禁用：不在当前会话里再生成一队隐藏子智能体，而是为叶子工单建独立 Session ，使每个被锁定的会话只装当前所需，尽可能少做有损压缩。



因此，计划与敏捷 不跟随“图不用人画了”。Claude 的 dynamic workflows 可以按目标现场生成一张图，但那仍是本次运行的编排脚本。我们要的是：拆分可追溯、依赖可计算、并行有所有权、完成有证据、恢复能从 Plan 重建现场。检查项、会话链接、隔离分支与合并门禁都不在一条边上。Graph 可以说明一次派发如何形成菱形； Plan 说明的是项目为什么还没完成。

4.4 计划外化与逐级分解

用户向 AI 工程经理描述大局需求后，Lead 与系统把核心需求写进工单，把顺序写进依赖图，把风险写进检查项，把证据写进完成记录。Sprint 是工程级拆解：哪些工单进入本轮交付、关键路径如何排布；工单内 Todo 才是任务级拆解：当前会话要实施和验证的步骤。上下文压缩只影响某个执行会话的短期认知，不再决定项目事实是否存在。执行者可以调整局部实现，但不能静默改写验收契约。

好的分解必须纵向可追溯，并由 AI 整理而不是交给用户手写卡片。前端入口、API 、持久化、权限和测试共同组成“发现—操作—系统响应—用户反馈”的闭环。一个 API 工单通过只能证明接口层完成，所有必要子项完成且父级真实场景可运行后，Feature 才能完成。合适的叶子工单边界清晰、依赖有限、验证独立、合并可控。若同时跨越多个子系统、修改大量共享契约，应继续拆分；若两个改变必须原子出现且无法独立验证，则应保留为同一工单内的实施步骤。目标不是卡片最多，而是每个被工程锁产生的会话只装当前叶子所需。父级保存业务结果，叶子任务足够小，相关文件、接口、测试和决策能稳定放入上下文，使该会话尽可能少做有损压缩；即使叶子会话压缩，也不会丢失它在整体中的位置。

4.5 依赖调度与契约先行

计划与敏捷 用有向无环图把隐藏在聊天中的顺序变成可计算事实。系统可以识别关键路径、可执行节点和被阻塞节点，优先给 ready 项分配会话。未满足条件的任务不会为了“保持 agent 忙碌”而提前启动，也不会逼迫模型发明尚未确定的接口。还必须区分逻辑依赖与资源冲突：成熟调度同时观察依赖图和影响面图。

契约先行能够释放并行度。前后端、插件与宿主可先定稿接口、类型、事件和错误语义，随后在隔离工作区分别实现。契约必须是可验证的真实交付，不是空接口占位。并行度由架构边界、测试与评审容量决定，而不是由能启动多少会话决定。

4.6 角色制衡：规划、执行、质疑与裁决

Lead 的产物不是某段代码，而是一个可运行的交付组织：边界清楚、顺序合理、责任明确、冲突可升级、完成可证明。Coder 读取项目约定和既有模式，在会话内建立 Todo ，修改代码，补充测试，运行构建或真实场景，并回写证据。若现场事实与工单冲突，它应升级而不是静默扩大或缩小范围。会话关联工单后，状态应自动从待办进入进行中，保证看板与真实执行一致。

Adversary 每个问题用文件路径、类别、严重度和证据形成去重检查项。Concern 是建议，Block 是完成前必须解决的门禁；问题经历 open 、acked 、resolved 或 dropped 生命周期，不能因一条聊天消息被压缩而遗忘。角色分离用于对抗确认偏差：实现者倾向维护自己的方案，Adversary 以寻找反例为目标，Lead 以全局依赖和产品结果为目标。

4.7 对抗编程：从第二意见到可执行质量协议

对抗编程不是让两个模型自由争论，也不是在实现结束后追加一次泛化代码审查。AnyPal 把质疑变成一条有状态、可去重、可追责的工程协议：Coder 对实现和证据负责，Adversary 专门寻找反例、遗漏与伪完成，Lead 在需求契约、依赖关系和产品结果之间裁决。三者目标函数不同，因而不会把“实现者重新读一遍自己的代码”误当成独立验证。实现会话可以结束，但未关闭的质疑必须作为外部事实继续存在。



协议的第一步不是发消息，而是登记检查项。Adversary 每轮先通过 manage_check_list 读取既有事项，再为新问题写入 severity 、category 、summary 和 evidence 。topic_key 采用“文件路径|问题类别”的稳定键，同一根因再次出现时由账本去重，而不是换一种措辞重复消耗 Coder 上下文。evidence 最多保存若干条可定位引用，可指向源码、测试、需求或运行结果； Concern 表示建议改进，Block 表示完成前必须消除的门禁。只有登记成功后，挑战才允许注入 Coder ，从而保证聊天消息与可审计账本一一对应。

消息交付也区分紧迫性与消费状态。普通问题可以排队并在合适的继续轮次进入上下文；影响安全、正确性或当前实现方向的 Block 使用 urgent steer 。紧急注入只有在 flushPartnerInject 真正把消息放入 Coder 交付路径后才算成功，不能在消息仍停留于合并定时器时提前报告完成。若后续复核发现 Coder 已独立修复，而挑战尚未被消费，Adversary 可以用 recall_message_from_coder 撤回消息，避免过期质疑污染下一轮；消息一旦被消费，撤回只返回无操作，历史仍保持可解释。

检查项具有 open 、acked 、resolved 、dropped 四态生命周期。open 表示问题已经提出但尚未确认； Coder 回复“同意”或说明准备处理，只能把它推进到 acked ，不能等同于修复。只有代码、测试或真实运行证据证明问题已消失，Adversary 才将其标记为 resolved ，并记录 Coder 的确认消息；若证据表明问题不成立、已被其他权威约束取代或属于明确非目标，才能 dropped ，且必须留下原因。这一状态机把“聊天里说过了”与“工程上解决了”分开，也使上下文压缩后仍能准确恢复哪些反例尚未关闭。

完成门禁由账本而不是语气控制。高严重度 Block 未 resolved 时，Coder 即使构建通过、Todo 全部勾选，也不能宣告工单完成； Lead 必须同时检查需求验收、验证证据、隔离变更合并和对抗检查项收敛。对抗编程因此形成闭环：Adversary 寻找可证伪命题，账本保存问题身份与证据，消息通道把挑战送达实现者，Coder 用可运行变更回应，Adversary 独立复核后关闭，Lead 再依据全局契约放行。它不是额外的一轮“意见”，而是把确认偏差转化为显式状态、把反例转化为完成条件。

4.8 代码层：检查项与消息如何形成闭环

运行时把协议编码进固定顺序：先 list 未关闭事项，再 add 带稳定 topic_key 与 evidence 的检查项； add 返回 deduped 时不得换键重试。只有登记成功，才调用 inject_steer_to_coder ，并把同一 topic_key 带入消息，使挑战与账本可直接关联。

Coder 的文字回应与工程关闭是两个动作。收到回复后只能先进入 acked ；只有修复落盘并出现匹配层级的验证证据，才进入 resolved 。问题若不成立或被权威决策废弃，则 dropped 必须携带 resolution_note 。ack_coder_message_id 把状态变化关联到具体 Coder 回复。

消息撤回只作用于尚未被 Coder 消费的 pending 队列。复核发现问题已被独立修复时，可用注入返回的 message_id 调用 recall_message_from_coder ；若消息已消费，接口返回不可撤回的无操作结果，Adversary 仍须根据证据更新检查项，不能改写历史。

代码层保证问题有稳定身份、重复挑战可去重、送达与消费可区分、确认与解决可分离；组织层再由 Lead 将检查项状态与需求验收、构建测试、真实运行和隔离合并共同裁决。前者负责不丢失事实，后者负责解释事实并决定是否放行。

4.9 隔离写入与冲突前移

隔离不能通过 stash 、reset 、移动或清空用户修改来制造干净环境，主工作区已有成果必须原样保留。是否共享隔离由所有权和依赖决定，而不是为了减少分支数量。隔离只解决物理覆盖，不能解决语义冲突。两个分支都能构建，却可能对同一字段、权限、状态机或错误语义作出不兼容决定。

Lead 创建工单时标注预计子系统、公共契约和高冲突文件。Coder 准备编辑共享模块时，先查询其他进行中会话的 changed-file 列表。只有路径重叠时才读取具体 hunks 和近期上下文。若区域与语义独立，双方采用窄小编辑并记录边界；若修改同一契约，Lead 应暂停一方、重新划分所有权，或让双方共享隔离分支并确定顺序。紧急 steer 必须真正进入对方交付路径后才算发送完成。Stop 清空 UI 徽标时，还要保留丢弃标记，确保未消费旧消息不会在后续会话复活。

Adversary 每轮先读取已有检查项，避免重复挑战。新问题先登记唯一 topic key 和证据，再注入 Coder ；若 Coder 已独立修复而消息尚未消费，可撤回。Coder 回复“同意”只表示 acked ，只有修复落地并通过验证才 resolved 。合并前先看相对基础分支的 diffstat ；主工作区若有重叠修改，应将其无损复制到隔离工作区解决。文本冲突的裁决回到工单契约，语义冲突则通过跨模块测试或真实运行裁决。

文本重叠但业务语义独立时，优先重新划分编辑区域或按顺序落地，不必停止全部并行。共享接口尚未定稿时，应暂停消费者，先由契约工单完成接口和兼容策略。两个工单目标重复时，应由 Lead 合并范围并保留一个权威交付单元。行为假设冲突时，不能靠 Git 选择版本，而要回到验收标准。资源冲突则采用预约、端口分配、独立数据集或串行发布窗口。冲突严重度取决于影响半径、可逆性和发现阶段：治理强度与风险匹配。解决后必须确认两边意图均得到保留或有一边被明确废弃，依赖图已更新，受影响会话已收到新边界，评审检查项已关闭，合并后验证覆盖原始冲突场景。

4.10 端到端闭环与双重收敛

需求首先被写成工程契约，包含背景、范围、非目标、交互闭环和完成定义。大工单逐级分解，Lead 标记关键路径、共享契约、风险和影响面，选择 ready 节点进入 Sprint 。Coder 在叶子工单内使用 Goal 保持局部敏捷，但范围或公共接口变化必须同步回 Plan 。验证优先采用真实运行：Web 用浏览器操作和 DOM 断言，桌面用原生自动化，CLI 与服务用真实命令或 HTTP 。无法真实运行才降级到集成、单元或静态检查，并说明实际阻塞。证据必须匹配层级，不能用“代码看起来正确”替代运行结果。

完成采用双重收敛。会话内 Todo 必须全部完成、取消或因真实用户输入阻塞；组织层 Issue 又必须满足验收、关闭 block 、合并隔离变更并更新看板。助推器 持续检查这两层状态，只要仍有确定性缺口，就给出针对性推进；当所有 fixture 都满足，系统才允许 EOS 成为真正终点。

完整时序是：Lead 拆分并标影响面；系统建立依赖； Coder 关联工单并进入进行中；高风险任务启用隔离；编辑前查询活跃会话；发现重叠后检查差异； Lead 用 queued 或 steer 明确所有权； Coder 实现并验证； Adversary 持续评审；完成后审计 diff ；在隔离区解决重叠；合并后再次验证；最后迁移工单到完成。

4.11 案例：跨端会话恢复

假设要实现“应用重启后恢复未完成交互”，涉及后端持久化、桌面宿主、前端消息列表、事件屏障、会话切换和测试。若只用一个大 Goal ，随着多模块代码与日志进入上下文，早期约束——切换期间实时事件可能丢失、异步补拉返回后必须重新校验会话 ID——很容易被压缩成模糊的“恢复 pending 状态”。Loop 即使继续十轮，也可能在错误摘要上完成一个存在竞态的实现。

计划与敏捷 先建立 Feature 和三个可观察验收场景：正常恢复、屏障期间事件丢失后的权威补拉、旧会话响应晚到时不得污染新会话。再拆成后端权威状态、宿主时序、前端过期响应保护、集成测试四个 Issue 。契约先定稿，宿主与前端并行，测试依赖两者；共享聊天页的不同发布镜像写入影响面。前端 Coder 编辑前发现另一会话正在修改同一聊天脚本。Lead 查看 changed files 与必要 hunks ，把所有权切开并规定顺序。Adversary 又提出 block：请求虽捕获开始时 session ID ，但 await 后未重新校验。Coder 补充 epoch guard 和旧响应晚到测试，证据通过后 block 关闭。整个过程中，即使任何会话压缩，三条验收、依赖、文件重叠和评审风险都存在于外部状态，nudge 会继续推动未满足项。

4.12 适用边界与落地顺序

计划与敏捷 不是所有任务的默认答案。改一个已知字符串、解释一段代码或运行一次命令，直接 loop 最有效；小而明确的多步骤任务使用 Goal 和 Todo 即可；跨文件、跨模块、跨角色、跨会话，存在依赖、并行、评审或高风险合并时，计划与敏捷 的收益才明显超过成本。

落地可分五步：先要求中型任务使用带实施、验证和证据的 Todo ；再建立持久 Issue 与 Session 绑定；随后引入依赖图和有限并行；对高影响任务启用隔离和 changed-file 审计；最后增加独立 Adversary 与构建、真实运行、评审关闭、隔离合并门禁。不要一开始追求最大并发，先证明分解与收敛规则可靠。Lead 必须维护信息卫生，并用周期时间、阻塞时长、冲突率、返工率、block 命中率和证据完整率持续优化。

4.13 产品原则：不追随，不暴露复杂性

理解 计划与敏捷，还必须理解 AnyPal 的产品出发点。AnyPal 从来不是为了跟随行业热点，也不是为了复制 Claude Code 的交互范式。市场上出现一种流行概念，并不意味着所有产品都必须把同样的名词、按钮和工作流暴露给用户。AnyPal 更关心一个根本问题：普通用户怎样以自己原本熟悉的方式提出需求，同时让 AI 在背后把需求可靠地完成。

在 AnyPal 中，用户看到的是简单而符合习惯的交互，后台运行的却是一套严格机制。任务被结构化拆解，依赖关系被计算，可并行工作被隔离，会话冲突被发现，评审问题被追踪，验证证据被检查，未收敛状态由 助推器 主动推进。用户不必知道某次 EOS 是否过早，也不必判断某个 Todo 是否遗漏； agent 与运行时在暗中完成监督、纠偏和继续执行。

“暗中监督和推进”并不意味着黑箱或剥夺用户控制，而是把控制放在正确层级。用户控制目标、优先级、关键决策和最终接受；系统控制执行完整性、依赖顺序、验证门禁和恢复机制。需要用户做产品选择、提供不可替代信息或批准高风险操作时，系统才以清晰、结构化方式请求输入；其余工程性重复劳动由后台自动完成。Loop 把模型停止暴露成用户问题；助推器 把随机停止吸收为内部运行细节。用户感知到的是任务持续向完成收敛，而不是一连串需要人工维护的生成回合。

人擅长表达意图、判断价值和作出高层选择； AI 擅长检索、执行、验证和处理大量工程细节；运行时擅长维护状态、约束顺序、发现冲突和保证收敛。AnyPal 不是先接受“所有 agent 都必须有 loop 、goal 或 graph”这个前提，再围绕它堆功能；而是从用户任务是否真正完成出发，逐步形成 Todo 收敛、助推器、持久 Plan 、依赖调度、会话级隔离、Adversary 和冲突协调。用户只向 AI 工程经理描述大局需求，不编写看板。概念服务于问题，而不是让问题迁就流行概念。

五、总结与展望

5.1 从随机续跑到可审计交付

Loop 的历史价值，是补偿 LLM 随机 EOS ，让模型在阶段性输出后还能继续行动；它的局限也正在这里：机械续跑只能增加轮次，不能给出工程完成依据。Goal 提供会话内方向，但仍受上下文压缩和局部真相限制。Graph 把拆分、并行与汇总画成一次运行的编排形状，却把组织状态留在脚本、账本和嵌套 worker 里。计划与敏捷 通过 助推器 把推进依据从模型自述迁移到确定性状态，通过持久计划抵抗遗忘，通过逐级分解控制上下文规模，通过依赖关系释放安全并行，通过会话级隔离减少物理干扰，通过协调处理剩余语义冲突，通过独立评审和证据门禁抵抗伪完成。

在记忆上，Loop/Goal/Graph 依赖短期上下文或本次编排账本，Plan 把需求、依赖、状态、责任和证据变成持久事实；在推进上，loop 用模糊“继续”补偿随机 EOS ，graph 用预画失败边换控制权，助推器 用未收敛状态给出确定性下一步；在分解上，Goal 多是线性步骤，Graph 多是菱形派发，Plan 支持父子层级与依赖图，且 Sprint 是工程级拆解、工单内 Todo 才是任务级拆解；在并行上，传统方法复制目标或嵌套 worker ，Plan 先切分所有权再根据依赖和影响面调度独立 Session 。在质量上，单 agent 或图内验证器主要依赖同一编排假设，Plan 引入独立 Adversary ；在完成上，传统对话以不再生成作为终点，Graph 以节点跑完作为终点，Plan 以证据、评审和合并共同收敛为终点；在恢复上，Loop 依赖摘要“继续聊天”，Graph 依赖重跑一张图，Plan 则从 Issue 读取契约，从 Session 读取历史，从 changed files 和 hunks 读取进度，从检查项读取风险，从依赖图读取下一步。恢复的是工程现场，不是语言风格或本次编排。

三种单位层层包含：Plan 调度 Issue ，Issue 绑定 Session ，Session 内运行 Goal ，Goal 通过 loop 调用工具，而 助推器 在每一层的边界上检查是否允许结束。这种层次结构把大规模任务从“要求一个模型记住全部”改写为“要求系统让每个模型只记住当前所需”。工作分解降低单会话认知负担，依赖图避免过早加载不相关上下文，隔离减少并发噪声，检查项保存反例，证据保存完成事实。上下文有限不再只是模型缺陷，而成为指导架构设计的约束。

这套设计提高了工程推进过程的可预测性。团队不再赌模型是否碰巧继续、是否碰巧记得、是否碰巧自查到问题，而是知道：只要计划仍有缺口，fixture 就会识别；只要依赖满足，调度器就会释放并行；只要文件重叠，协调机制就能发现；只要评审存在 block ，完成门禁就会拒绝；只要隔离变更未落地，交付就不会被宣告结束。可预测性正是工程系统区别于演示脚本的标志。

5.2 责任转移与产品展望

AnyPal 的目标是让责任真正转移。用户提出需求后，系统负责把自然语言意图转化为可执行结构，负责在上下文压缩后恢复细节，负责在随机 EOS 后依据 fixture 判断是否继续，负责在依赖允许时并行，负责隔离写入并协调冲突，负责以构建、测试、真实运行和评审证明完成。只有无法替用户作出的决定才返回用户。

这不是承诺 AI 永远不犯错，而是通过制度让错误可发现、可定位、可阻断、可恢复。单个 agent 可能遗漏，Adversary 可以发现；单个会话可能忘记，Plan 可以恢复；一个分支可能冲突，隔离和 Lead 可以协调；模型可能提前 EOS ，助推器 可以推进。可靠性来自多层防线，而不是来自对单一模型能力的神化。

真正可扩展的智能体工程，不需要假设存在一个永不输出 EOS 、永不遗忘、永不犯错的超级模型。它需要一套即使模型会随机停止、局部上下文会压缩、多个会话会并发修改，整体仍能知道缺什么、为何继续、怎样验证、何时真正完成的系统。助推器 提供确定性推进，计划与敏捷 提供持久组织；两者结合，才使超大规模任务从“多跑几轮”升级为符合工程严谨性的可审计交付。

我们并不打算照着其他 Agent 产品的方式做一遍。Loop 、Goal 这些东西当然有用，也会存在于系统内部，但没必要让用户为了使用 AI 去学习这些概念。

我们更希望把这些事情留在后台。任务怎么拆、哪些任务可以同时做、会不会互相冲突、做完以后怎么验证，这些应该尽量由系统处理。用户还是按照原来的方式提需求，剩下的事情交给 AI 去完成。

所以 AnyPal 真正在意的，也不是有没有 Loop 、Graph 这样的新概念，而是用户把需求交给 AI 之后，AI 能不能少让用户操心一些，把事情真正做完。

从这个角度看，技术方案本身并没有那么重要。Loop 、Graph 、Plan ，甚至以后出现新的方法，都只是实现手段。最后还是要看一件事：需求有没有做对，过程中有没有漏掉东西，改完有没有验证，以及最终结果能不能交付。

关于 AnyPal

面向软件工程的 Agent Harness

全功能免费

支持主流 AI 协议、第三方模型服务、自定义端点

面向软件工程场景，支持 Agent 、Git 、IDE 、数据库、转储分析等能力

不需要绑定特定模型或服务，已有 API / 中转服务也可以直接使用。

https://anypal.pome.net/

欢迎入群交流

709597997