管理长任务
Goal 是 Agent 可调用的任务状态工具，适合在多轮工作中保存一个明确目标。输入 /goal ... 会作为文本提示触发内置 skill，再由 Agent 决定是否调用 goal 工具；它不是 TUI 本地实现的严格命令解析器。
创建一个可验证目标
Section titled “创建一个可验证目标”直接用自然语言说明目标和验收条件：
创建一个目标：把 src/auth 下的回调式接口迁移为 async/await。验收条件：现有 API 行为不变；目标测试通过；列出没有运行的测试。之后可以说：
查看当前目标。根据工作区证据完成当前目标。当前缺少私有 registry 凭据，把目标标记为阻塞并记录原因。清除当前目标。同一进程内同一会话只有一个 active goal。新的目标与旧目标冲突时，先完成或清除旧目标。
完成验证怎样工作
Section titled “完成验证怎样工作”当辅助模型可用时，完成动作会用目标描述和最近 20 条非 System 消息生成验证判断。因此：
- 在接近完成时重新给出测试结果、关键 diff 和未验证项。
- 不要假设很久以前的一条消息仍在验证窗口内。
- 把“测试通过”写成具体命令与结果，不要只写结论。
如果没有配置辅助模型，当前实现会直接完成目标，不执行这一步模型验证。无论界面显示什么，工作区、测试和外部系统仍是最终事实源。
“会话可以继续”与“任务运行时状态仍存在”是两件事。后台任务、cron 和其他进程内状态也应分别检查，不能只根据历史消息判断。
当前一次 Agent 执行循环的默认上限是 500 个 iteration。它是防止单次循环无限运行的内部上限，不是跨天项目的总轮次承诺，也不表示 Agent 会在无人值守时自动工作到 500 轮。
大任务更适合分成可独立验证的阶段：
- 先确认范围和基线测试。
- 每一阶段只修改一组明确边界。
- 阶段结束运行目标测试并记录剩余风险。
- 需要新进程时，重新声明下一阶段 goal。
适合 Goal：需要多轮工具调用、验收标准明确、过程中可能需要补充信息的任务。
不适合 Goal：单次解释、简单只读查询，或依赖外部时间触发的工作。后者应使用可靠的外部调度系统，而不是把 Goal 当守护进程。