oh-my-openagent ulw-loop 目标定义指南如何把 brief 变成可审计、可交付的注册目标【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读在 oh-my-openagent 的 ulw-loop 组件中目标Goal是整个持续执行循环的绑定契约——目标注册得有多好整个 run 的质量上限就有多高。本文以 define-goal.md 为核心系统讲解如何把一段简短的 brief 转化为可注册、可执行、可证明完成的目标从五问质量门槛、outcome-first 的目标解剖结构到 LIGHT/HEAVY 分级成功标准、量化阈值、弱目标修复、注册协议与完成诚实性。读完后你将掌握一套在调用create_goal之前必须走完的目标设计流程并能结合 ulw-loop 源码理解successCriteria的真实数据结构和校验规则。ulw-loop 中的目标先理解它为什么如此重要ulw-loopskill 名为ulw-loop见 SKILL.md把工作分解为系统化、以证据为边界的 ultrawork 步骤。在这个循环里目标不是一个待办项而是整个 run 的绑定契约目标是对执行它的 Agent 的一条 prompt包括压缩上下文之后的未来之你目标的每一分 token 都必须挣得只携带 run 之后无法重新推导的东西——outcome结果、proof证据、bounds边界、stop state停止状态其余一切都是噪音会偷走那些真正决定是否完成的部分所需的注意力。因此该文档要求在调用create_goal之前必须先读这篇 reference。注册的目标质量直接决定 run 的质量上限the runs quality is capped by the quality of this objective。在仓库实现中这条契约被落实为create-goals子命令根据 brief 生成目标并打印 handoff 文本随后由 Agent 调用 Codex 侧的create_goal注册见 cli-subcommands.ts 与 codex-goal-instruction.ts——payload 只有objective一个字段。也就是说目标定义文档塑造的是create-goals时刻每个 goal 的 objective 与 successCriteria这正是本文要展开的核心技能。质量门槛注册前必须能回答的五个问题在注册任何目标之前目标必须能回答以下全部五个问题完成时什么具体的东西为 TRUE是一个结果outcome绝不是一项活动activity。什么证据能证明它命令、校验器、他人可以打开的产物artifact。什么量化或二值阈值定义成功哪些范围边界重要什么包含在内什么被明确排除在外。什么情况应该让 Agent 停下来提问而不是硬磨下去任何一个问题无法回答目标就没有准备好。应该先修复见修复薄弱目标一节再调用工具。目标解剖Objective Anatomyoutcome-first 的五要素顺序撰写目标时必须以结果优先outcome-first按以下顺序组织Outcome结果用一句话说明完成后什么将为 TRUE点名涉及的产物、系统、仓库或面向用户的行为。Deliverables交付物工作落地的具名表面——文件、端点、包、环境。必须使用字面路径和名称执行 Agent 会字面地解释目标不会推断你没有点名的交付表面。Success criteria成功标准按 tier 分级见下节每一条都是可二值观察的且必须在定义时就把场景和证据点名。Constraints and scope bounds约束与范围边界把用户明确表述的约束逐字记录包括任何会让 run 膨胀的歧义处的明确排除项。当用户在某个会分叉的边界上保持沉默时由你自己设定从仓库证据和最佳实践中推导最清晰、最可辩护的边界已在用的技术栈、兼容表面、代码需服务的规模、仓库隐含的受众或合规要求并在目标内记录为assumed: 约束 — 理由, 可逆?该假设在用户否决之前一直有效。未言明的边界不存在——这正是你要把它们写下来的原因。WHEN TO STOP何时停止一行话——当 精确的可观察状态 成立时我会立即停止。这一行是绑定性的一旦它成立run 立即交付并停止越过它继续工作不是勤奋而是缺陷。另外两条撰写原则只有当动机改变执行方式时才写动机例如p95 重要因为 checkout 的 SLA 是 300ms否则省略肯定句优于禁令verify against staging 比 do not touch production 携带更多信号。成功标准的构造按 tier 分级计数成功标准的数量要对齐 run 的 tier 分流tier triageLIGHT已知模式无悬而未决的设计决策12 条标准happy path 加上风险最高的边缘用例。HEAVY新模块或抽象、认证或安全、外部集成、schema 或迁移、并发、跨域重构或用户明确要求谨慎3 条以上标准覆盖happy path边缘用例边界、空、畸形、并发相邻表面的回归按文件和函数点名这次改动真正引入的对抗性风险adversarial risk。每条标准在定义时而不是工作完成后就必须携带一个二值通过条件例如 returns 200 and the body matches the schema绝不写 works correctly精确场景能证明它的字面命令、请求、页面操作或 payload它将捕获的证据产物transcript、status body、截图路径、diff、解析后的 dump失败优先证明failing-first proof在实现之前就先捕获 RED 状态的测试 id 或场景。一条不会失败的标准不是标准。如果没有任何输入能让该场景失败它就什么都衡量不了——重写到失败成为可能为止。源码印证成功标准的数据结构ulw-loop 源码把上述要求固化成了真实的类型与校验逻辑每个successCriteria条目包含id、scenario、userModel、expectedEvidence、essential、capturedEvidence、status等字段见 domain-types.tsscenario与expectedEvidence都是必填非空文本userModel必须是happy/edge/regression/adversarial之一essential必须是布尔值见 success-criteria-input.ts标准 id 自动生成为C001、C002式编号criterionId(index)未提供自定义成功标准时工厂会按 brief 自动播种三条占位标准happy pathessential、edge caseessential、相邻表面回归non-essential并给出revise_criterion的替换指引见 plan-goal-factory.ts。这意味着文档中要求的二值通过条件 精确场景 证据产物在工程上对应scenarioexpectedEvidence两个必填字段而必须在实现前写死则由status: pending初始状态与capturedEvidence: null初始空值来承载——直到真正捕获证据前标准都处于未证明状态。让它可量化六类领域的量化方式优先选择能代表真实成功的数字而不是装饰性精度。一个没有人会根据它采取不同行动的阈值就是噪音。领域量化方式Bug 修复先复现、后修复失败的用例先捕获为 RED然后同一个校验器转绿测试精确命令 必需的通过条件易 flake 的套件还要加上运行次数性能指标、目标阈值、测量方法、运行次数例如 p95 在 3 次连续本地运行中均低于 250ms质量类工作可观察的验收门槛lint、typecheck、test 通过已评审的示例用户批准的产物研究研究必须支撑的决策、范围内的来源或系统、每条主张的证据标准运维健康状态、监控窗口、故障阈值以及回滚或升级触发条件修复薄弱目标Repair Weak Goals拒绝纯活动型目标make progress、keep investigating、improve things、work on X。它们不可能失败因此也不可能结束。当本地上下文允许时把模糊目标重写为可测量目标。只有当缺失细节是 OWNER-DECISION所有者决策时才问一个窄问题——即不可逆、有破坏性、安全攸关或属于跨切面产品决策真实预算或支出、公共表面、外部依赖、数据形态、目标受众——且该细节会改变预期结果或其验证方式。问题应围绕缺失的校验器或边界来构造这里定义成功的指标是什么延迟、成本、准确率还是用户可见行为我要在哪个环境验证本地、staging还是 production这个目标标记完成之前你想要的最低证据是什么除此之外的所有缺失约束都遵循目标解剖第 4 条采用最清晰、最可辩护的默认值在目标中以assumed:记录让用户否决。当用户提供不了指标时提出最诚实的可用二值校验器将其写入目标并继续。两个经典的修复示范弱Make checkout faster.修复后Reduce checkout API p95 below 250ms on the documented slow path with the smallest safe server-side change; prove it withnpm run test:checkoutgreen plus the local latency benchmark showing p95 under 250ms across 3 consecutive runs; out of scope: client-side changes and new caching layers.弱Keep investigating the PR comments.修复后Resolve every open change-requesting review comment on PR 123 touching only the affected auth files and their tests; prove it with the targeted auth test command green plusgh pr view 123showing zero unresolved change-request threads.注意两个修复示例都完整包含了四个要素可二值判断的结果、具名交付表面、精确的验证命令与证据、显式的 out-of-scope 边界——这正是目标解剖五要素的直接应用。注册协议Registration Protocol第一步先get_goal再按状态行动get_goal 显示行动无活动目标用create_goal注册只传objective。绝不传status之类的生命周期字段绝不把目标注册到一段散文、一个记事本或一份计划里来代替工具调用。有匹配此意图的活动目标继续它。绝不注册重复目标。有与此意图冲突的活动目标停下并浮出冲突由用户决定是完成它、终结它还是分叉。三条硬性规则目标是无限的。绝不凭空发明用户没说过的话费预算、token 上限或截止时间——这条禁令覆盖 run 配额目标解剖第 4 条的assumed:工作约束与它不同是必须要有的。在 ulw-loop run 中loop CLI 拥有每个 goal 的状态.omo/ulw-loop/goals.jsoncreate_goal注册的是打印出的 handoff 中的聚合目标而这篇 reference 同时塑造该目标以及create-goals时刻每个 goal 的successCriteria。源码印证状态与会话边界目标状态的完整枚举为pending / in_progress / complete / failed / blocked / review_blocked / needs_user_decision成功标准状态为pending / pass / fail / blocked见 constants.ts状态文件按会话隔离存放于.omo/ulw-loop/session-id/goals.jsonledger 为ledger.jsonl并有.state.lock保护并发见 paths.ts每个 ulw-loop 命令都必须携带会话作用域传--session-id id或依赖环境变量OMO_ULW_LOOP_SESSION_ID、CODEX_SESSION_ID、CODEX_THREAD_ID、PI_SESSION_ID。缺少作用域时 CLI 会以ULW_LOOP_SESSION_SCOPE_REQUIRED拒绝而不是去触碰共享的.omo/ulw-loop根目录见 cli-commands.tsulw-loop 的 CLI 子命令全集为create-goals、status、complete-goals、checkpoint、steer、add-goal、criteria、record-evidence、record-review-blockers见 cli-commands.ts其中complete-goals会打印create_goal的精确 payload 作为 handoff见 codex-goal-instruction.ts——Use the create_goal payload exactly as rendered: objective only。与 Codex 目标的两种集成模式Codex 线程里的目标对 loop 而言是一个DRIVER驱动器loop 给它下指令但从不拿它当门禁checkpoint只接受可选的--codex-goal-json快照、逐字记录进 ledger并且不因目标状态或 objective 而拒绝。目标集成有两种模式codexGoalMode见 goal-status.tsper_story默认每个 OMO goal 对应一个 Codex 目标create_goal的 objective 就是该 goal 的 objectiveaggregate整个 ulw-loop run 对应一个 Codex 聚合目标create_goal的 objective 是聚合目标Complete the durable ulw-loop plan in .../goals.json ... under the original brief constraints; use .../ledger.jsonl as the audit trail.见 goal-status.tsOMO 的各 goal 只是 ledger 中的故事stories。无论哪种模式目标都是无限的handoff 指令明确写着 Goals are unlimited. Do not add numeric limits.见 codex-goal-instruction.ts。完成诚实性Completion Honesty只有在你针对本次 run 中捕获的证据逐条审计完每条标准之后才把update_goal报为 complete。一套绿色的测试套件是辅助证据单独它永远不是完成证明。等待不等于阻塞Waiting is not blocked只要 monitor、后台子任务或定时续跑还能唤醒 run就结束当前回合让它触发。Blocked 必须是一个真正的死局没有存活的恢复通道且同一个阻塞在连续多个回合重复出现。WHEN TO STOP 那行一旦在证据到手的情况下成立就立即交付并停止。在源码侧这一要求由hasAllCriteriaPass/hasEssentialCriteriaPass/firstUnresolvedCriterion等函数支撑所有标准通过或至少所有 essential 标准通过才认为 goal 可完成且essentialCriteriaOf在未显式标记 essential 时退回到 happy-path 标准见 goal-status.ts。此外Codex 侧update_goal只在最后一个 story 且强制质量门manualQa 通过、gateReview 批准、iteration 通过、criteriaCoverage 完整之后才允许调用中途 story 只 checkpoint不update_goal见 codex-goal-instruction.ts。反模式清单反模式为什么失败应该怎么做活动型目标investigate X不可能失败因此不可能结束run 会游荡点名该活动必须产出的结果及其证据实现后才补标准契约迁就了工作什么都没被证明在注册时、任何编辑之前就写标准与场景装饰性精度没人测量的 99.97% uptime没有校验器检查的阈值就是穿着西装的噪音只写命名校验器会真正检查的阈值填充型目标角色散文、复述上下文、废话每个多余 token 都在和标准争夺注意力只有 outcome、deliverables、criteria、bounds、stop line别无其他用散文或记事本注册目标没有任何东西绑定 run完成变成一种感觉只要工具存在每次都用create_goal携带 objective 注册同一意图注册重复目标两份契约没有一份有权威性继续活动目标或浮出冲突快速自查清单注册前的最后一遍检查在调用create_goal之前对照这份清单过一遍你的目标文本Outcome 是否一句话说明了完成后什么为 TRUE而不是描述了要做的活动Deliverables 是否点名了字面路径与名字文件、端点、包、环境没有任何让 Agent 去推断的表面每条 success criterion 是否都有二值通过条件、精确场景命令/请求/payload、证据产物、实现前的 RED 证明标准数量是否匹配 tierLIGHT 12 条HEAVY 3 条且覆盖 happy/edge/adjacent/adversarial用户没说而会分叉的边界是否已写成assumed: 约束 — 理由, 可逆?WHEN TO STOP 是否是一行精确的可观察状态是否已get_goal检查过活动目标避免重复注册或静默冲突是否没有任何用户未声明的数字预算、token 上限或截止时间结语目标定义是 ulw-loop 整条证据链的起点一篇好的define-goal.md实践让 brief 变成可注册的目标让目标变成可执行的契约让契约在完成审计时可以被逐条证明。本文的全部规则都可以在你自己的 ulw-loop run 中直接套用——注册前先过五问按五要素写目标按 tier 定标准把每个阈值交给命名校验器然后在证据到手时诚实收尾。完整的循环流程还可以继续阅读同目录下的 full-workflow.md以及承载目标状态的goals.json与审计轨迹ledger.jsonl路径规则见 paths.ts把目标定义与执行、证据、质量门完整地串成一体。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent ulw-loop 目标定义指南：如何把 brief 变成可审计、可交付的注册目标
oh-my-openagent ulw-loop 目标定义指南如何把 brief 变成可审计、可交付的注册目标【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读在 oh-my-openagent 的 ulw-loop 组件中目标Goal是整个持续执行循环的绑定契约——目标注册得有多好整个 run 的质量上限就有多高。本文以 define-goal.md 为核心系统讲解如何把一段简短的 brief 转化为可注册、可执行、可证明完成的目标从五问质量门槛、outcome-first 的目标解剖结构到 LIGHT/HEAVY 分级成功标准、量化阈值、弱目标修复、注册协议与完成诚实性。读完后你将掌握一套在调用create_goal之前必须走完的目标设计流程并能结合 ulw-loop 源码理解successCriteria的真实数据结构和校验规则。ulw-loop 中的目标先理解它为什么如此重要ulw-loopskill 名为ulw-loop见 SKILL.md把工作分解为系统化、以证据为边界的 ultrawork 步骤。在这个循环里目标不是一个待办项而是整个 run 的绑定契约目标是对执行它的 Agent 的一条 prompt包括压缩上下文之后的未来之你目标的每一分 token 都必须挣得只携带 run 之后无法重新推导的东西——outcome结果、proof证据、bounds边界、stop state停止状态其余一切都是噪音会偷走那些真正决定是否完成的部分所需的注意力。因此该文档要求在调用create_goal之前必须先读这篇 reference。注册的目标质量直接决定 run 的质量上限the runs quality is capped by the quality of this objective。在仓库实现中这条契约被落实为create-goals子命令根据 brief 生成目标并打印 handoff 文本随后由 Agent 调用 Codex 侧的create_goal注册见 cli-subcommands.ts 与 codex-goal-instruction.ts——payload 只有objective一个字段。也就是说目标定义文档塑造的是create-goals时刻每个 goal 的 objective 与 successCriteria这正是本文要展开的核心技能。质量门槛注册前必须能回答的五个问题在注册任何目标之前目标必须能回答以下全部五个问题完成时什么具体的东西为 TRUE是一个结果outcome绝不是一项活动activity。什么证据能证明它命令、校验器、他人可以打开的产物artifact。什么量化或二值阈值定义成功哪些范围边界重要什么包含在内什么被明确排除在外。什么情况应该让 Agent 停下来提问而不是硬磨下去任何一个问题无法回答目标就没有准备好。应该先修复见修复薄弱目标一节再调用工具。目标解剖Objective Anatomyoutcome-first 的五要素顺序撰写目标时必须以结果优先outcome-first按以下顺序组织Outcome结果用一句话说明完成后什么将为 TRUE点名涉及的产物、系统、仓库或面向用户的行为。Deliverables交付物工作落地的具名表面——文件、端点、包、环境。必须使用字面路径和名称执行 Agent 会字面地解释目标不会推断你没有点名的交付表面。Success criteria成功标准按 tier 分级见下节每一条都是可二值观察的且必须在定义时就把场景和证据点名。Constraints and scope bounds约束与范围边界把用户明确表述的约束逐字记录包括任何会让 run 膨胀的歧义处的明确排除项。当用户在某个会分叉的边界上保持沉默时由你自己设定从仓库证据和最佳实践中推导最清晰、最可辩护的边界已在用的技术栈、兼容表面、代码需服务的规模、仓库隐含的受众或合规要求并在目标内记录为assumed: 约束 — 理由, 可逆?该假设在用户否决之前一直有效。未言明的边界不存在——这正是你要把它们写下来的原因。WHEN TO STOP何时停止一行话——当 精确的可观察状态 成立时我会立即停止。这一行是绑定性的一旦它成立run 立即交付并停止越过它继续工作不是勤奋而是缺陷。另外两条撰写原则只有当动机改变执行方式时才写动机例如p95 重要因为 checkout 的 SLA 是 300ms否则省略肯定句优于禁令verify against staging 比 do not touch production 携带更多信号。成功标准的构造按 tier 分级计数成功标准的数量要对齐 run 的 tier 分流tier triageLIGHT已知模式无悬而未决的设计决策12 条标准happy path 加上风险最高的边缘用例。HEAVY新模块或抽象、认证或安全、外部集成、schema 或迁移、并发、跨域重构或用户明确要求谨慎3 条以上标准覆盖happy path边缘用例边界、空、畸形、并发相邻表面的回归按文件和函数点名这次改动真正引入的对抗性风险adversarial risk。每条标准在定义时而不是工作完成后就必须携带一个二值通过条件例如 returns 200 and the body matches the schema绝不写 works correctly精确场景能证明它的字面命令、请求、页面操作或 payload它将捕获的证据产物transcript、status body、截图路径、diff、解析后的 dump失败优先证明failing-first proof在实现之前就先捕获 RED 状态的测试 id 或场景。一条不会失败的标准不是标准。如果没有任何输入能让该场景失败它就什么都衡量不了——重写到失败成为可能为止。源码印证成功标准的数据结构ulw-loop 源码把上述要求固化成了真实的类型与校验逻辑每个successCriteria条目包含id、scenario、userModel、expectedEvidence、essential、capturedEvidence、status等字段见 domain-types.tsscenario与expectedEvidence都是必填非空文本userModel必须是happy/edge/regression/adversarial之一essential必须是布尔值见 success-criteria-input.ts标准 id 自动生成为C001、C002式编号criterionId(index)未提供自定义成功标准时工厂会按 brief 自动播种三条占位标准happy pathessential、edge caseessential、相邻表面回归non-essential并给出revise_criterion的替换指引见 plan-goal-factory.ts。这意味着文档中要求的二值通过条件 精确场景 证据产物在工程上对应scenarioexpectedEvidence两个必填字段而必须在实现前写死则由status: pending初始状态与capturedEvidence: null初始空值来承载——直到真正捕获证据前标准都处于未证明状态。让它可量化六类领域的量化方式优先选择能代表真实成功的数字而不是装饰性精度。一个没有人会根据它采取不同行动的阈值就是噪音。领域量化方式Bug 修复先复现、后修复失败的用例先捕获为 RED然后同一个校验器转绿测试精确命令 必需的通过条件易 flake 的套件还要加上运行次数性能指标、目标阈值、测量方法、运行次数例如 p95 在 3 次连续本地运行中均低于 250ms质量类工作可观察的验收门槛lint、typecheck、test 通过已评审的示例用户批准的产物研究研究必须支撑的决策、范围内的来源或系统、每条主张的证据标准运维健康状态、监控窗口、故障阈值以及回滚或升级触发条件修复薄弱目标Repair Weak Goals拒绝纯活动型目标make progress、keep investigating、improve things、work on X。它们不可能失败因此也不可能结束。当本地上下文允许时把模糊目标重写为可测量目标。只有当缺失细节是 OWNER-DECISION所有者决策时才问一个窄问题——即不可逆、有破坏性、安全攸关或属于跨切面产品决策真实预算或支出、公共表面、外部依赖、数据形态、目标受众——且该细节会改变预期结果或其验证方式。问题应围绕缺失的校验器或边界来构造这里定义成功的指标是什么延迟、成本、准确率还是用户可见行为我要在哪个环境验证本地、staging还是 production这个目标标记完成之前你想要的最低证据是什么除此之外的所有缺失约束都遵循目标解剖第 4 条采用最清晰、最可辩护的默认值在目标中以assumed:记录让用户否决。当用户提供不了指标时提出最诚实的可用二值校验器将其写入目标并继续。两个经典的修复示范弱Make checkout faster.修复后Reduce checkout API p95 below 250ms on the documented slow path with the smallest safe server-side change; prove it withnpm run test:checkoutgreen plus the local latency benchmark showing p95 under 250ms across 3 consecutive runs; out of scope: client-side changes and new caching layers.弱Keep investigating the PR comments.修复后Resolve every open change-requesting review comment on PR 123 touching only the affected auth files and their tests; prove it with the targeted auth test command green plusgh pr view 123showing zero unresolved change-request threads.注意两个修复示例都完整包含了四个要素可二值判断的结果、具名交付表面、精确的验证命令与证据、显式的 out-of-scope 边界——这正是目标解剖五要素的直接应用。注册协议Registration Protocol第一步先get_goal再按状态行动get_goal 显示行动无活动目标用create_goal注册只传objective。绝不传status之类的生命周期字段绝不把目标注册到一段散文、一个记事本或一份计划里来代替工具调用。有匹配此意图的活动目标继续它。绝不注册重复目标。有与此意图冲突的活动目标停下并浮出冲突由用户决定是完成它、终结它还是分叉。三条硬性规则目标是无限的。绝不凭空发明用户没说过的话费预算、token 上限或截止时间——这条禁令覆盖 run 配额目标解剖第 4 条的assumed:工作约束与它不同是必须要有的。在 ulw-loop run 中loop CLI 拥有每个 goal 的状态.omo/ulw-loop/goals.jsoncreate_goal注册的是打印出的 handoff 中的聚合目标而这篇 reference 同时塑造该目标以及create-goals时刻每个 goal 的successCriteria。源码印证状态与会话边界目标状态的完整枚举为pending / in_progress / complete / failed / blocked / review_blocked / needs_user_decision成功标准状态为pending / pass / fail / blocked见 constants.ts状态文件按会话隔离存放于.omo/ulw-loop/session-id/goals.jsonledger 为ledger.jsonl并有.state.lock保护并发见 paths.ts每个 ulw-loop 命令都必须携带会话作用域传--session-id id或依赖环境变量OMO_ULW_LOOP_SESSION_ID、CODEX_SESSION_ID、CODEX_THREAD_ID、PI_SESSION_ID。缺少作用域时 CLI 会以ULW_LOOP_SESSION_SCOPE_REQUIRED拒绝而不是去触碰共享的.omo/ulw-loop根目录见 cli-commands.tsulw-loop 的 CLI 子命令全集为create-goals、status、complete-goals、checkpoint、steer、add-goal、criteria、record-evidence、record-review-blockers见 cli-commands.ts其中complete-goals会打印create_goal的精确 payload 作为 handoff见 codex-goal-instruction.ts——Use the create_goal payload exactly as rendered: objective only。与 Codex 目标的两种集成模式Codex 线程里的目标对 loop 而言是一个DRIVER驱动器loop 给它下指令但从不拿它当门禁checkpoint只接受可选的--codex-goal-json快照、逐字记录进 ledger并且不因目标状态或 objective 而拒绝。目标集成有两种模式codexGoalMode见 goal-status.tsper_story默认每个 OMO goal 对应一个 Codex 目标create_goal的 objective 就是该 goal 的 objectiveaggregate整个 ulw-loop run 对应一个 Codex 聚合目标create_goal的 objective 是聚合目标Complete the durable ulw-loop plan in .../goals.json ... under the original brief constraints; use .../ledger.jsonl as the audit trail.见 goal-status.tsOMO 的各 goal 只是 ledger 中的故事stories。无论哪种模式目标都是无限的handoff 指令明确写着 Goals are unlimited. Do not add numeric limits.见 codex-goal-instruction.ts。完成诚实性Completion Honesty只有在你针对本次 run 中捕获的证据逐条审计完每条标准之后才把update_goal报为 complete。一套绿色的测试套件是辅助证据单独它永远不是完成证明。等待不等于阻塞Waiting is not blocked只要 monitor、后台子任务或定时续跑还能唤醒 run就结束当前回合让它触发。Blocked 必须是一个真正的死局没有存活的恢复通道且同一个阻塞在连续多个回合重复出现。WHEN TO STOP 那行一旦在证据到手的情况下成立就立即交付并停止。在源码侧这一要求由hasAllCriteriaPass/hasEssentialCriteriaPass/firstUnresolvedCriterion等函数支撑所有标准通过或至少所有 essential 标准通过才认为 goal 可完成且essentialCriteriaOf在未显式标记 essential 时退回到 happy-path 标准见 goal-status.ts。此外Codex 侧update_goal只在最后一个 story 且强制质量门manualQa 通过、gateReview 批准、iteration 通过、criteriaCoverage 完整之后才允许调用中途 story 只 checkpoint不update_goal见 codex-goal-instruction.ts。反模式清单反模式为什么失败应该怎么做活动型目标investigate X不可能失败因此不可能结束run 会游荡点名该活动必须产出的结果及其证据实现后才补标准契约迁就了工作什么都没被证明在注册时、任何编辑之前就写标准与场景装饰性精度没人测量的 99.97% uptime没有校验器检查的阈值就是穿着西装的噪音只写命名校验器会真正检查的阈值填充型目标角色散文、复述上下文、废话每个多余 token 都在和标准争夺注意力只有 outcome、deliverables、criteria、bounds、stop line别无其他用散文或记事本注册目标没有任何东西绑定 run完成变成一种感觉只要工具存在每次都用create_goal携带 objective 注册同一意图注册重复目标两份契约没有一份有权威性继续活动目标或浮出冲突快速自查清单注册前的最后一遍检查在调用create_goal之前对照这份清单过一遍你的目标文本Outcome 是否一句话说明了完成后什么为 TRUE而不是描述了要做的活动Deliverables 是否点名了字面路径与名字文件、端点、包、环境没有任何让 Agent 去推断的表面每条 success criterion 是否都有二值通过条件、精确场景命令/请求/payload、证据产物、实现前的 RED 证明标准数量是否匹配 tierLIGHT 12 条HEAVY 3 条且覆盖 happy/edge/adjacent/adversarial用户没说而会分叉的边界是否已写成assumed: 约束 — 理由, 可逆?WHEN TO STOP 是否是一行精确的可观察状态是否已get_goal检查过活动目标避免重复注册或静默冲突是否没有任何用户未声明的数字预算、token 上限或截止时间结语目标定义是 ulw-loop 整条证据链的起点一篇好的define-goal.md实践让 brief 变成可注册的目标让目标变成可执行的契约让契约在完成审计时可以被逐条证明。本文的全部规则都可以在你自己的 ulw-loop run 中直接套用——注册前先过五问按五要素写目标按 tier 定标准把每个阈值交给命名校验器然后在证据到手时诚实收尾。完整的循环流程还可以继续阅读同目录下的 full-workflow.md以及承载目标状态的goals.json与审计轨迹ledger.jsonl路径规则见 paths.ts把目标定义与执行、证据、质量门完整地串成一体。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考