不跑偏才是长程 Agent 的关键

AI 写代码越来越快，人却未必更轻松。一个任务还在运行，另一个任务已经返回结果，人又在等待间隙开启第三件事。等几个结果同时到来，检查、补充背景和决定下一步的工作会集中回到同一个人身上。

机器容易并行，人的注意力却不能按同样的比例扩张。这是我们讨论长程 Agent 时反复遇到的问题：减少编码时间，不等于减少交付所需的判断。

编码提速之后，瓶颈去了哪里

代码生成只是交付的一段。前面有目标和范围需要对齐，后面有测试、评审、发布与观察。提高一个环节的速度，可能只是把更多工作推到后面的队列里。

因此，我更愿意把“提效”拆开看：生成代码更快了吗？验收更容易了吗？人需要切换多少次上下文？最后拿到的是可检查的产物，还是更多需要人工判断的文字？

如果这些问题没有答案，同时启动更多 Agent 可能增加吞吐，也可能只是增加协调负担。

反馈环路比运行时长更重要

圆桌讨论过我做的一次长时间事件采集任务。它有效的部分，是先跑通了最小链路：修改代码、操作测试页面、查询接收端，再根据结果修复。

这使 Agent 不再仅凭代码推测完成状态。它能区分“已经增加调用”和“已经观察到记录”，并在缺少证据时继续检查。任务完成后，人仍然复核结果；后续合入和发布没有因此自动变成无人流程。

这段经验适用的范围是有明确反馈和受控工具边界的开发任务。它不能单独证明 Agent 已具备完整的生产交付能力。

Loop 应该怎样设计

我更愿意把 Loop 看成一个有状态、有反馈、有退出条件的执行协议。它可以拆成五个相互连接的部分：

目标与验收。 开始之前明确交付物、约束和证据来源。例如“完成一个演示页面的事件采集，并在接收端验证事件与字段”，比“把采集做好”更容易判断。可量化的目标也需要范围和停止条件，不能把一个可以无限优化的指标当成唯一终点。
计划与拆解。 先选择一条最小链路跑通，再扩展到其他任务。把依赖、已尝试路径和未完成事项写入持久状态，避免会话压缩之后重新规划同一件事。
执行与反馈。 每轮选择一个可推进的动作，操作工具，读取真实结果，再决定修复、继续还是调整计划。执行记录需要区分“做了什么”和“验证了什么”。
完成与退出判断。 把本轮证据与最初的验收条件核对，同时检查目标偏移、阻塞、重复失败和预算。通过验证才算完成；没有进展时应报告原因，而不是再发送一次“继续”。
经验回写。 结束后复盘轨迹，把可复用的失败原因、验证方法和有效约束沉淀下来。下一次运行应能用到这些经验，而不必重走同一段弯路。

这里可以区分内外两层循环：内层围绕一个具体动作做“执行—验证—修复”，外层负责检查整个任务的方向、依赖和退出条件。局部测试通过，只能说明一个环节成立，不能直接把整个目标标为完成。

例如，一个演示功能已经通过单元测试，但浏览器里的交互还未验证，下一轮就应该补齐交互证据；如果验证需要暂时无法取得的权限，就记录缺失的证据和具体问题。仍有独立且已授权的任务时可以先推进，不能把绕过权限当成恢复策略。

这是一组从讨论中整理出的设计原则，并不意味着一次长时间执行已经验证了所有机制。跨会话恢复、多人协作和预算控制，仍需要各自的真实任务检验。

把目标与状态放在会话之外

长任务可能跨越上下文压缩、会话重启或执行者交接。如果成功条件、已尝试路径和阻塞项只存在于聊天记录里，接手者就需要重新猜测任务状态。

可以先用一份很简单的记录：

字段	要回答的问题
目标	最终要交付什么？
验收条件	哪些检查必须通过？
证据	到哪里查看实际结果？
当前状态	已完成、失败、阻塞、未验证分别有哪些？
下一步	现在最值得推进的动作是什么？
边界	哪些动作需要人决定？预算何时耗尽？

Markdown、Issue 或结构化状态文件都可以。关键是持久、可读，而且能够与真实产物核对。状态文件不能仅仅复制 Agent 的“已完成”声明。

复核要同时检查正确性和方向

测试通过并不意味着任务没有跑偏。评审还需要检查：实现是否回答了原始需求，是否引入了不必要的复杂度，是否超出了授权范围。

独立 Reviewer 可以提供不同视角，但其结论仍需证据。把注意力优先放在阻塞交付、影响正确性或安全边界的问题上，避免让低价值的偏好争论驱动无限返工。

人在过程中补充背景时，也应把新约束写回任务状态，明确哪些旧假设失效。否则不同执行者可能按照不同版本的目标继续工作。

停止是一种正常结果

成功、阻塞和预算耗尽是不同状态。遇到无法取得的权限、缺失的依赖或需要人类判断的问题，任务应清楚报告，而不是用重复尝试掩盖没有进展。

除了最大重试次数、时长和成本预算，还可以记录最近几轮是否产生了有效变化：新证据、新的可验证修复，或一个被排除的假设。反复生成相同计划，不应该被当作进展。

如果仍有独立且已授权的工作可以推进，系统可以继续处理；涉及关键决策的分支则应停在明确的问题上。

LoopX：把长程控制放到执行 Agent 之外

圆桌里提到的 LoopX，就是把上述约束落到工程中的一个开源参考。它在执行 Agent 之外维护持久状态和控制层：运行时提供模型与工具，控制层保存目标、决策、证据和交接信息，让任务能够跨会话继续推进。

从这次讨论的角度看，我关注四件事：

目标不依赖聊天记忆。 验收标准和任务状态保存在会话之外，每轮执行后写回结果和证据。换会话或交接时，接手者能找到同一份目标。
人的判断有明确入口。 将需要决策的问题显式记录为 gate，说明缺什么判断、影响哪个分支。等待决策时，只有独立且已授权的工作才能继续。
继续执行需要理由。 在下一轮开始前检查剩余预算、阻塞和有效进展。新证据、可验证的修复或被排除的假设，才是值得继续的信号；反复复述计划不是。
完成需要证据回写。 执行 Agent 的自述只是输入，控制层还要核对验收结果和未尽事项，保留可以恢复、复核和交接的记录。

这些是我希望通过 LoopX 说明的控制层设计，而不是某个版本的接口承诺。状态一致性、重复执行和恢复后的副作用仍需单独处理。把状态存下来是基础；让恢复后的下一步仍然正确，才是更难的部分。

每次运行都应该留下可复用的经验

复盘不只是保存完整日志。更有用的是指出哪一步反复失败、验证器漏掉了什么，以及下一次需要增加哪一条最小约束。

模型和工具会变化，旧流程也应重新评估。不要为了延续已经建立的流程而保留无效步骤，也不要因为模型升级就未经验证地删除所有门禁。

长程 Agent 的价值，最终体现在可确认的结果和更少的人工协调上：知道自己在做什么，知道如何验证，有问题能够纠正，做不到时能够明确停下。跑得久只是现象，不跑偏才是目标。