我为什么开始做 codex-auto：我不想再反复对 AI 说“继续”

做 codex-auto 的起点，是我不想再反复对 AI 说“继续”。Agent 已经能读项目、写代码、处理报错和运行验证，但一次回答结束，经常只是当前小步骤结束。产品还有明显缺口，下一步也能从现状里判断，却仍需要我回来推一下。

我想交出去的，不只是执行某条指令的劳动，还有在既定目标和授权内判断下一步的劳动。这是我做这个尝试的动机，不是已经证明它能独立完成所有项目的结论。持续执行也不会自动带来正确方向。

每一步都由人安排，会留下什么工作

逐步交互有它的价值：问题还模糊、动作影响很大时，人需要参与。但如果连修改后运行检查、检查失败后定位原因、修好后重新验证，都要用户逐项指定，用户实际仍在充当调度器。AI 写代码快了，安排工作的成本却留在原处。

还有一种更隐蔽的情况：Agent 完成了一个页面，就把它当成交付；用户试用后说仍然粗糙，它又问要不要继续完善。我后来在 codex-auto 的演进里，把“可运行的候选”和“足以交付的产品”分开。能打开是事实，方向是否有用、核心是否成熟，是另外的问题。

这不是要求 Agent 永不结束回答。我希望它结束的理由来自目标、证据或边界，而不是恰好写完当前清单。若还有明确、低风险且能改善核心体验的工作，继续推进通常比把“下一步怎么办”重新交回给我更合理。

从任务列表转向一个持续的目标

我现在用 Mission 表达要达到的结果，同时保留约束和重要未知。它与一张固定任务图的区别，在于行动可以随着观察改变：实现暴露了原先假设不成立，下一步就可能是验证需求，而非机械进入下一个功能。

我把这个关系理解为 Observe、Decide、Execute、Verify、Evidence，再选择 Next Best Action。观察仓库和真实行为，判断目前最大的缺口，做一项相称的行动，验证结果，留下会影响后续判断的证据，然后决定下一步。这些词说明工作的联系，不要求每次都写六份报告。

“下一步最好做什么”也不是“还能加什么”。有时是修复失败路径，有时是补一个能区分原因的观察，也可能是停止新增功能，等待真实用户使用。功能数量最容易计数，却不一定最接近目标。

演进中让我改变判断的地方

codex-auto 的 Git 历史保留了几次明确调整：成熟交付的证据处理、由 Agent 自主综合产品方向，以及对核心体验是否过于普通的审视。它们反映一个问题：自动推进即使在工程上完整，也可能只是更连续地产出一个没有吸引力的产品。

所以我不想把“所有检查通过”直接等同于“方向已被接受”。用户对实际体验的反馈，需要辨明究竟在评价哪个产品、哪个方向。夸技术实现，不等于认可核心体验；说“可以打开”，也不能被记录成满意。反过来，用户确认方向以后，Agent 仍应继续完成可靠性和正常使用里的缺口。

服务器维护提供了一段具体的使用材料：在目标和边界已经给定后，静态内容、Ansible 差异、部署、公网验证与记录可以连起来推进。它说明这种方式能用于这类有清楚结果的工作，但没有构成与普通交互的效率对照实验，更不能外推到所有产品开发。

人应留下哪些决定

我希望人保留意图、真正主观的取舍和真实风险承诺。产品是否值得做、实际体验是否符合自己、是否接受不可逆影响，不能由 Agent 为了保持运行而替人决定。已经授权的日常可逆动作，则不需要每次再问一遍。

这里需要区分缺少信息和缺少权限。Agent 可以调查的信息，先调查；能做成具体候选的方案，先做成可评估的体验。到了确实只能由人判断的地方，再把背景、证据、推荐和代价一起交出来。具体边界，我另写在自动化运维的人工决策记录里。

这也解释了它与 Praxis 环境原则的关系。我希望保留目标与下一步责任，并不想要求每个任务经过一条固定阶段链。原生 Agent 已经能处理的局部工作，直接完成就好；缺上下文先补上下文，缺现实观察就去观察。只有持续推进确实需要跨会话记忆时，才保存相应状态。调用了某个 Skill 本身，不应成为产出更多报告或扩张工作范围的理由。

现在还不能承诺什么

codex-auto 是依托原生 Agent 的指导和项目记忆，不是一个在会话之外持续运行的后台服务。它也没有因为能恢复状态，就获得无限预算、生产权限或用户的偏好。任务换了、证据过期了，原来的判断仍需重审。

我还不知道这种方式在不同项目里能节省多少人的注意力，是否会因过度研究而增加成本。我的当前选择是让它承担更多已授权的推进责任，同时让每次停止都有具体理由。比起让 AI 一直忙下去，我更关心它能否知道什么时候还有价值可做，什么时候确实该把决定交还给人。