设个目标让 AI 干到完：四家 goal mode 机制对照，「做完了」大多是模型自己报的
goal mode（目标模式）是给 AI 编程助手设一个持续有效的目标：工具把目标存下来，一轮做完由工具决定要不要接着开下一轮，直到判断完成为止。Codex、DeepSeek Harness（下文叫 DSH）、ZCode、TRAE 都有这个入口。我把能读的源码对照下来，结论是：goal mode 解决的是「谁接着干」，不解决「怎么算干好」；持续运行要配上清楚的边界和可检查的证据，否则可能一直跑、一直偏。
最要紧的差异在「做完了」由谁说了算。Codex 和 DSH 是执行任务的模型自己收集证据、自己报告完成；ZCode 启用核验时会另发一次不带工具的模型请求专门判断是否完成；TRAE 官方只说「自我评估」，内部是否另发请求没有公开。
先说清材料来源：Codex、DSH、ZCode 三家读的是固定提交的源码；TRAE 产品核心源码未公开。
会一直干，和干得对，是两回事
「把这个应用做好，直到能上线」这类目标容易出事：哪些功能必需、什么算做好、要不要真的发布，全都没有答案。Agent 可能提前宣布完成，也可能不停往里加功能。goal mode 拉长了运行时间，替不了你做产品判断。
顺带解释一个词：harness（运行外壳），指包在模型外面、提供工具、维护会话、安排下一轮的系统。四家都有 goal 入口，但外壳里面怎么实现续跑、怎么判断完成、怎么管预算，各走各的路。
目标存在哪，下一轮谁发起
先看目标存在哪、谁能改。Codex 把目标存成线程状态，提供读和改的工具，新建目标不能直接覆盖未完成的目标。DSH 拆成四件：一个服务存状态，一套工具给模型用，一组命令给人用，一个驱动安排回合；更新目标必须带版本号，旧版本的写入会被拒绝，创建和编辑只认人类的直接输入。
ZCode 把目标存进本地 SQLite 数据库，桌面端和命令行都能操作。TRAE 的操作岛台可以查看、编辑、暂停、删除目标，内部怎么存没有公开资料，不能当成与前三家相同的结构。
再看下一轮是谁发起的。这里有个常见误会：不是模型自己在后台不停思考。Codex 在会话空闲时检查目标是否仍然激活，条件满足才请求新一轮。DSH 要求三个条件同时成立：目标进行中、当前进程被授权续跑（源码里叫 armed）、Agent 已空闲，然后才预留下一回合。ZCode 用命令队列承接循环，有排队的工作就先让出。TRAE 官方说法是每轮结束后自评，未达标就继续，由什么事件触发下一轮没有公开。
目标存下来了，不代表重开窗口就会自动续跑；你在目标里提到的计划文件，也不代表每轮都会自动加载。让 Agent 先报告它实际读到了哪个文件，比反复强调「不要停」有用。
「做完了」由谁说了算
这是四家差异最大的一环。Codex 的续跑指令要求模型依据当前文件、测试和日志审核目标，达成后调用工具报告完成；这条主路径里，没有看到另发一次独立的核验请求。DSH 的文档写得更直白：没有独立的评审者（evaluator），模型自己拿证据、自己报告完成。这两家，完成与否主要是执行模型自报。
ZCode 走了另一条路：启用核验时，另发一次不带任何工具的模型请求，只读当前历史，输出是否通过和下一步动作；通过后由运行时写入完成状态，未通过但给出了下一步就继续干，失败或给不出下一步就停止自动推进。TRAE 官方用「自我评估」描述，是否另发请求没有说明，不能归进任何一边。
对「独立」这个词要作两点限定。第一，独立请求不等于换了更强的模型，更不等于权威认证。第二，这次请求不带工具，不能重新跑测试，只能评估已有记录；执行过程没留下可信证据的话，多一次判断也补不出来。四家通用的做法是一样的：要求交付可检查的证据，自动停止只是一条完成信号。
卡住、超支、重开之后
阻塞的门槛，两家路数不同。Codex 的工具说明要求同一阻塞连续至少三轮才能标记 blocked（阻塞），但这是写给模型的要求，实现代码里没看到同等的硬检查。DSH 相反，代码里硬性检查阻塞轮数是否达到阈值，默认值 3（源码默认值，可配置）。写给模型的要求不等于系统里的硬检查；反过来，有硬检查也不等于什么都拦得住，轮数挡得住草率报阻塞，挡不住把不同问题误判成同一个。
预算怎么计量，四家也不通用。Codex 按目标核算 token（模型读写的计费单位）用量，子任务的消耗计入根目标，这是源码测试覆盖的场景，但它不是精确到最后一个 token 的账单开关。DSH 按回合计数，默认上限 256 轮，token、金额、时长归别的策略管，「最多 256 轮」换算不出「最多花多少钱」。
ZCode 的目标带 token 预算字段，累计到阈值会转入限额状态，但你装的界面有没有设置入口要自己确认。TRAE 没有确认到目标级的硬预算，GitHub 上开源版 trae-agent 的步数上限不能搬到产品上用。
重开之后各家更不一样。DSH 在会话恢复或分叉后，即使目标仍在进行也保持待授权状态，等人发话。Codex 会重新登记进行中的目标，后续仍受续跑条件约束。ZCode 明确保留用户的暂停状态，不会擅自改回进行中。恢复前先问三件事：现在目标是什么，当初为什么停，剩余工作和预算还剩多少。
五步用起来，附一条可抄的指令
- 让 Agent 复述需求：读项目现状，列出本次交付、明确不做的事、待确认的问题，这一步不改代码。它若把你「导入待办」的需求理解成重做账号系统，当场纠正。
- 审一份计划：每阶段写清交付物、验收场景、项目已有的检查方式，先给你审再执行。「修改导入代码」不是验收，「合法文件导入后能看到正确任务，错误行不会静默进列表」才是。
- 用实际文件路径启动目标，指令见下方。
- 按证据干预，别只催「继续」，下一节展开。
- 逐条验收：已满足、未满足、未验证分开报告，附证据位置，最后你亲自走一遍最核心的用户操作。
而其中关键的第三步的指令可以这样写：
/goal 完成 PLAN.md 中「本次范围」的全部阶段，以其中验收清单为完成依据。先确认读取到的文件和范围，再按依赖推进；阶段验证失败先处理，不扩大需求，不削弱检查。结束时逐项提供证据和未完成项。
启动命令四家不通用。DSH 的 /goal 可以带 pause、resume、edit 子命令，Codex 官方指南也提供暂停、恢复、清除的入口，ZCode 文档列出 /goal 及 pause、resume、replace、clear，TRAE 在输入框敲 / 选 Goal、再到操作岛台管理。发出后看返回的目标状态，别把消息发出去当成启动成功。
它开始原地打转时
要警惕的信号是：没有新证据，却不断说「进一步优化」。这时候暂停新增改动，让它列出最近的尝试、每次结果和下一种有依据的不同办法。
拿两个常见需求举例。「给待办应用加个好用的导入」，要先变成「两列文件、先预览分类、确认后写入、重复不新增、原功能回归」这样的可检查清单；「刷新后任务丢失」，要先固定复现条件、找到写入或读取失败的证据再动手，不能接受「已优化存储，应当解决」这种说法。
依据与来源
调研日期 2026-10-23。源码均绑定固定提交：openai/codex（d681745 开头）、deepseek-ai/deepseek-harness（687f282 开头）、zai-org/ZCode（3c5b227 开头）。TRAE 依据 docs.trae.cn 官方工作流页；GitHub 上的 bytedance/trae-agent 是独立的命令行项目，不能当产品实现。四个工具未做实际运行对测，文中使用建议是综合判断，教学场景是演示写法不是实测。
带行号的源码出处、完整的七维对照表和全部可复制指令，放在飞书长文《Goal mode 的机制差异与实用指南：Codex、DeepSeek Harness、ZCode、TRAE 横向比较》里：kcnmp9q51uc0.feishu.cn/wiki/VT77wT…
