给桌面编码 Agent 加上分阶段验收

编码代理说「完成了」，你敢直接交付吗？OpenDaemon 作者想解决的就是这个落差：不靠 CLI 脚本调度，而是在 Claude、Codex 桌面应用和 Antigravity IDE 里，分阶段指挥代理干活，再检查报告、运行结果和截图。

这套做法值得看的地方，是它把「完成」变成了需要验收的状态。但原文只是简短的产品介绍，没有对照实验，不能据此认定桌面自动化比 CLI 更可靠。

先写计划，再让每个阶段交出能运行的东西

OpenDaemon 的流程从计划开始。用户描述一次应用需求，规划器拆出阶段和检查清单，既覆盖明确提出的要求，也补充这类应用通常应该具备的内容。计划形成前，不写代码。

随后，每个阶段都会生成完整任务说明，发送到编码应用中的一个新会话。这样做的意图，是让代理拿着当前阶段的明确任务开工。不过，新会话如何获得此前的架构决策、接口约定和项目状态，原文没有展开。

真正关键的是验收：

代理提交成功报告，不等于阶段可以结束。

OpenDaemon 会读取报告和截图。如果阶段产物打不开或跑不起来，就退回修复，不标记完成。作者称，要求每个阶段都交出可以打开的东西，消除了大部分虚假的「完成」。这是作者报告的使用经验，没有给出样本量、失败率或对照数据。

最后还有一次试玩验收（Playtest）：运行最终产物，逐项核对清单，保存截图，把无法检查的项目单独列出来。它没有承诺检查所有东西，而是要求把未验证部分交代清楚。

桌面里看得见，是否就更值得信任

作者选择桌面应用，有两个理由：很多人已经在那里工作；看着代理在屏幕上操作，有助于建立信任。因此，OpenDaemon 面向的是 Claude desktop app、Codex desktop app 和 Antigravity IDE，而不是通常用于自动化的 CLI。

控制权也被放进流程里。用户可以逐阶段批准，或者通过 Full trust 一次批准计划。代理遇到不确定的问题，应当把问题交回用户，而不是自行猜测。每个项目有独立文件夹，「Continue conversation」用于从停止的位置继续。

按原文说明，OpenDaemon 在 Microsoft Store 免费提供，支持 Windows 10/11，可以使用 NVIDIA 的免费模型或用户自己的 key。AI Developer 需要 Chrome，以及上述三个编码应用之一。Chrome 具体承担什么角色、模型支持范围和免费额度如何，原文没说清。

这些条件决定了它更适合已有对应桌面环境、愿意观看执行过程的人。原文没有提供无人值守运行、执行稳定性或接入持续集成的细节。

我的判断

我赞同它对「完成」的处理：把计划、阶段产物、最终清单和未验证项连起来，比只听代理汇报更容易发现遗漏。尤其是要求产物真的能打开，至少能挡住一部分明显的交付失败。

但截图只能证明某个时刻的界面状态。页面能显示，不代表交互分支、异常处理和数据逻辑都正确。原文也没有说明是否结合自动化测试，不能把这套验收直接当成完整质量保障。

桌面优于 CLI，则更像作者的产品取舍。桌面操作便于用户观察；CLI 通常更方便留下命令记录、重复执行和接入现有流水线。原文没有比较两者的成本和成功率，「看得见」能帮助理解过程，却不能单独证明结果正确。

还有一个容易忽略的边界：规划器补充的「用户通常会期待什么」也是推断。清单应该由用户审核，否则代理可能很认真地完成了一个并非你想要的范围。

能拿来做什么

• 给前端页面任务先写验收清单，明确哪些页面要能打开、哪些交互必须走通，再让代理开始编码。
• 把大任务拆成可运行的阶段，每阶段要求提供启动方式、可检查的产物和验证结果，发现跑不起来就先修复。
• 最终验收时逐项记录已验证与无法验证的内容，截图用于辅助检查，涉及行为和逻辑的部分继续用实际操作或测试确认。
• 把需求歧义留给用户决策；如果采用一次批准计划的方式，先确认规划器补充的需求确实属于本次范围。