Nexus Goal 与 Codex Goal 有什么区别？长任务续跑机制对比
Nexus Goal 与 Codex Goal 有什么区别？基于公开资料比较两种长任务目标模型的持续执行、验证条件、责任结构和完成判断。
本文内容
图 1：两种 Goal 都服务于长时间工作，但比较时需要区分公开可见的使用行为和系统内部的实现对象。图中为 Nexus 示例界面。
Nexus Goal 和 Codex Goal 都在解决同一个表面问题：AI Agent 不应该在一个回答结束后就忘记正在做什么。
但两者的设计重点不同。Codex 的公开文档把 /goal 描述为让 Codex 跨多个轮次持续工作，直到达到可验证的停止条件；Nexus Goal 则把目标、目标版本、续跑控制和 Execution/WorkGraph 的责任链放进产品自己的领域模型。
本文只比较公开资料可以确认的 Codex 使用行为，不推断 Codex 未公开的内部数据库、调度器或状态机实现。
Codex Goal 公开解决什么问题？
OpenAI 官方文档建议在任务需要 Codex 跨多个交互持续推进，并且拥有明确成功条件和验证循环时使用 /goal。官方示例强调：目标应该包含可验证的结束状态，而不是只有“按这个计划实现”的模糊要求。
公开可见的使用方式包括：
- 使用
/goal <objective>开始一个持久目标； - 使用
/goal查看当前目标； - 使用
/goal pause、/goal resume和/goal clear控制目标； - 让 Codex 在多个小时内持续工作，并在认为达到停止条件时结束；
- 在目标中写清范围、约束、验证命令和完成条件。
这是一种面向长时间编码工作的目标控制体验。它的价值在于把一次普通对话变成有停止条件的持续任务。
同一个需求，两种 Goal 入口会怎样被理解？
假设用户提出同一个要求：把一个数据库迁移完成，补齐兼容性测试，并在没有证据时不要宣布结束。两种产品都可以从目标、约束和验证条件开始，但读者需要区分它们公开承诺的范围。
| 执行问题 | Codex Goal 的公开使用方式 | Nexus 的对应对象 |
|---|---|---|
| 保存最终要求 | /goal 中写清 objective 和停止条件 | Goal objective 与 completion criteria |
| 组织工作 | 目标里可以写计划、里程碑和验证命令 | Execution 中保存 Plan revision 和 Work Item |
| 记录一次尝试 | 公开页面强调持续工作与检查点 | Attempt 记录本次责任执行，失败可形成新 Attempt |
| 处理交付反馈 | 由持续任务继续迭代 | Submission、Review 和 Acceptance 形成明确门槛 |
| 多人或多 Agent 协作 | 需要结合公开资料中对应的工作流能力理解 | Assignment、Reviewer 和 ReviewBinding 有独立归属 |
| 最终停止 | 达到目标中定义的可验证停止条件 | 先收口工作图，再由 Goal 做完成审计 |
这张表的重点是对比“用户可以怎样使用”和“Nexus 还把哪些责任保存成领域状态”。它不声称知道 Codex 内部如何存储每个对象，也不把 Nexus 的实现细节投射到 Codex 的产品行为上。
Nexus Goal 额外保存什么？
Nexus 的 Goal 不只作为持续执行的指令，还作为产品领域中的长期目标对象。它关注：
- 当前 objective 和 objective revision；
- completion criteria 与目标对齐；
- 是否绑定某个明确的 Execution；
- 续跑的安排、领取、启动和结束事实；
- 当前 blocker、用量、期限和继续条件；
- 工作图交付是否足以进入 Goal completion audit。
Nexus 的 Goal 可以单独使用，也可以和 WorkGraph 明确绑定。绑定后，Goal 负责最终方向和完成审计，WorkGraph 负责 Work Item、Assignment、Attempt、Submission、Review 和 Acceptance。
核心差异在哪里？
| 比较维度 | Codex Goal：公开可见范围 | Nexus Goal |
|---|---|---|
| 主要入口 | /goal 与 Goal 控制 | Goal 对象、Composer 和结构化命令 |
| 主要目的 | 让 Codex 跨轮次推进到可验证停止条件 | 保存长期目标，并与执行责任和交付证据对齐 |
| 计划关系 | 官方文档强调目标、计划、里程碑和验证 | Plan 是 Execution 中不可变的责任结构版本 |
| 任务结构 | 公开资料展示工作循环和检查点 | Work Item、Assignment、Attempt 具有独立持久身份 |
| 多 Agent 责任 | Codex 公开资料可以描述子智能体和工作流，但不在 Goal 页面定义 WorkGraph 合同 | Subagent、Worker、Reviewer 和 ReviewBinding 有明确责任边界 |
| 完成判断 | 达到目标中定义的可验证停止条件 | WorkGraph 交付通过 Acceptance，再由 Goal 做完成审计 |
| 外部未知状态 | 公开 Goal 文档未定义通用 Submission/Acceptance 合同 | unknown、receipt 和 reconciliation 是执行恢复的一部分 |
这张表不是在比较哪个产品“更强”。它说明两种设计解决的问题层次不同：Codex Goal 是长时间工作的一种持续目标入口；Nexus Goal 是围绕目标、责任、交付和恢复组织系统状态的领域对象。
为什么 Nexus 还需要 WorkGraph？
如果任务只是一个 Agent 在同一代码库里持续迁移，并且目标中已经写清了验证命令，Goal 加计划文件可能足够。
但当任务出现以下情况时，单独的持续目标不够表达责任关系：
- 服务端、客户端和验证可以并行；
- 下游必须等待某一份已经验收的结果；
- 独立 Reviewer 需要检查具体 Submission；
- 第一次结果被退回，但旧结果仍然需要保留；
- 用户补充目标后，需要区分旧版本和新版本；
- 外部副作用超时，需要先确认状态再决定是否继续。
WorkGraph 负责把这些关系变成系统可以读取的结构。Goal 负责回答“最终要达成什么”，WorkGraph 负责回答“谁正在完成哪一份可验收的责任”。
两种模型可以怎样互相理解？
可以把它们抽象成两个层次：
持续目标层：目标是什么，何时继续，何时停止
↓
责任执行层：谁负责什么，交付是否验收，依赖是否解锁
↓
运行层：这一轮调用了哪些工具，产生了哪些观察结果
Codex 的公开长任务资料也强调目标、约束、里程碑、验证和状态记录的重要性。Nexus 的设计继续向下拆分，把执行责任和交付证据变成独立的持久对象。
因此，Nexus Goal 与 Codex Goal 的关系更适合被描述为：相似的长任务目标体验，不同的责任建模深度。
用朴素的话说，Nexus 多做了一层什么？
如果只看界面，两者都可以表现成“告诉 Agent 一个目标，然后让它继续做”。Nexus 的内部路线是把这件事拆成三步：
- 先保存目标。 用户要什么、什么算完成、要求改过几次，先成为 Goal 的当前版本。
- 再保存责任。 这一次执行拆成哪些 Work Item，谁接手，哪份 Submission 正在等待 Review，都落在动态工作图里。
- 最后保存证据。 运行结果不会直接改写目标状态；它要经过提交、评审和 Acceptance，Goal 才能对照这些事实决定是否收口。
这样做的代价是模型入口和数据结构更复杂，换来的好处是任务中断、返工、换负责人或用户改要求时，系统仍然能说清楚当前状态。对于只需要一次回答的小任务，这一层结构可能没有必要；对于跨多个 Agent、需要独立复核的交付，它决定了系统能不能恢复而不靠猜。
阅读边界与官方资料
本文关于 Codex 的描述依据 OpenAI 当前公开资料：
如果要了解 Nexus 自身的执行链，可以继续阅读AI Agent 如何执行长任务和AI Agent 执行循环怎么运行。
Codex 的公开产品行为可能继续变化；本文的比较只对应页面访问时能够确认的官方资料。Nexus 部分依据当前项目的 Goal 与 WorkGraph 设计。