grok-build 目标模式执行纪律goals 任务完成规范goal_task_discipline深度解析【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-build导读在 grok-buildSpaceXAI 的 coding agent harness 与 TUI中/goal objective开启的多轮目标模式goal mode会让模型跨多个回合持续工作直到验证通过。实践中最常见的失败并非模型能力不足而是纪律缺失叙述了动作却没调用工具、在任务明显进行中时向用户请示下一步、或者留下容易收尾的工作提前交还回合。本篇文章以仓库内实际注入系统提示的模板 goal_task_discipline.md 为骨架结合其渲染代码与配套模板逐条讲解这四条任务完成纪律的意图、实现位置与配套机制帮助你理解、调优或复用这套目标模式执行规范。一、这套纪律是什么一条被逐字注入系统提示的模板goal_task_discipline.md是 xai-grok-shell 会话层的一份 Markdown 模板文件位于 crates/codegen/xai-grok-shell/src/session/templates/goal_task_discipline.md。它的定位非常明确只在目标goal处于活跃状态期间生效正文开篇即声明 These rules apply for the duration of an active goal.从源码结构看该模板通过include_str!被编译进二进制在 acp_session.rs 中定义为常量GOAL_TASK_DISCIPLINE_TEMPLATE在 goal_support.rs 的render_goal_task_discipline()中把占位符{TODO_TOOL}替换为实际 todo 工具名后返回。模板末尾的换行是有意设计的——注释明确说明 Template must end with\nso{DISCIPLINE_BLOCK}TRACKING:glues correctly模板必须以换行结尾使{DISCIPLINE_BLOCK}与后文TRACKING:正确拼接。也就是说这段纪律文本不是孤立的它最终被拼进更完整的目标规则块中。渲染链路从/goal到系统提醒调用链如下用户输入/goal objective会话 actor 调用setup_goalsetup_goal在 goal.rs 中创建 goal 记录、运行可选的 planner受GROK_GOAL_PLANNER控制、解析工具名然后调用render_goal_rules()或 legacy 版本渲染完整提醒render_goal_rules()goal_support.rs执行{DISCIPLINE_BLOCK}占位符替换把render_goal_task_discipline()的产物拼入 goal_rules.md 模板最终提醒以system-reminder\n{body}\nStart now.\n/system-reminder的形式成为首轮推理的输入。同样的渲染路径也出现在/goal resumegoal.rs和 continuation nudge回合未完成时推送的继续工作指令中三个渲染位点都统一走goal_reminder_plan_path()这道闸门避免规则漂移。二、核心内容四条任务完成纪律逐条拆解模板正文以task_completion_discipline为语义标签包裹四条规则。下面逐条说明其含义与配套实现。规则 1先工具调用后叙述Tool-call first, narration second任何用过去时或现在进行时描述动作的叙述我已经启动了……我正在读取……子代理正在处理……必须在同一 assistant 回复中伴随对应的工具调用。如果你以这样的句子结束回合却没有工具调用那么这个动作并未发生。只有工具调用出现在同一回复中之后才写启动声明——绝不单独出现。这条规则直指多步目标工作最典型的假动作失败模型在文本里描述了一个行为但没有真正执行。实现上的关键点是同一回复same assistant response这一约束——它要求工具调用与叙述同帧出现从而让说了就是做了的幻觉无法成立。规则 2不请求许可继续进行中的任务Dont ask permission to continue a task in flight面向用户的问题只留给真正会改变方案的歧义例如两种都合理的架构、缺失的需求。它不是用于节奏协商要不要我每 30 分钟汇报一次、对显然的下一步做确认我该继续修这些问题吗或让用户重新确认一个已经授权的计划。当下一步由你的 todo 列表或目标本身决定时直接做。这条规则划清了值得问与不该问的边界真正的歧义才值得打断用户节奏协商与显而易见的下一个动作则是纪律问题。仓库的配套机制中连续多轮无进展的 continuation nudge 会在达到阈值后触发自动暂停见下文第四节与这条规则形成呼应——反复向用户确认本身就是没在干活的信号。规则 3用 todo 列表跟踪多步工作Track multi-step work with a todo list对较长任务todo 列表是实用的草稿本——列出步骤大致保持一个in_progress完成后立即更新条目。它是帮你记忆的辅助工具不是交付物不要过度拆分也不要把回合花在记账上而牺牲实际工作。关键定性是 NOT a deliverable不是交付物。配套实现中占位符{TODO_TOOL}会在渲染时被替换为实际工具名——从 goal.rs 的resolve_goal_tool_names()可见todo 工具来自工具桥的ToolKind::Plan默认回退为todo_write目标更新工具默认回退为update_goal子代理工具默认回退为spawn_subagent。也就是说模板里写的不是硬编码工具名而是根据当前会话实际注册的工具动态填充。配套的 goal_rules.md 对 TRACKING 有更细的要求keep ≥1in_progresswith a present-tenseactiveForm, and mark each done immediately (do not batch)至少保持一个进行中条目activeForm用现在时完成后立即标记不要批量处理。如果启用了 plannergoal_plan_block.md 还会要求先从计划的验收标准播种 todos。规则 4不要留下容易收尾的工作提前停手Dont stop with easy work left undone结束回合前检查是否存在没有阻塞的、明显剩余的工作。如果有继续做而不是提前交还——目标循环反正会在验证通过前重新拉起你提前停止只是浪费一轮。合理的停止时机是你确实在等待一个实时后台任务、你需要用户在真正歧义上做决定、或你撞上硬性外部阻塞凭据缺失、网络断开、权限被拒——此时要明确陈述阻塞原因。这条规则配合 harness 的自动验证循环运行每轮模型回合结束后harness 会自动评估完成度未完成就继续推进goal loop因此提前交还只会浪费一轮。合法停止的三类情形等待后台任务、真实歧义、硬性外部阻塞都在模板中明确列出且要求显式陈述阻塞。三、它不是孤立文本与整个目标规则体系的配合goal_task_discipline.md只承载 Rules 1–4从源码注释 Goal-onlytask_completion_discipline(Rules 1-4) 可见而完整的目标模式还包含更多配套模板同目录 templates 下还有goal_rules.md完整目标规则块{DISCIPLINE_BLOCK}拼入本纪律后还包含 WORKING自己实现并在真实用户路径上测试、NO TEST THEATER测试必须证明真实交付代码在真实路径上工作禁止硬编码期望值、跳过被测对象、在测试里重写被测代码、VERIFY AS YOU GO、SCRATCH私有 scratch 目录纪律绝不使用共享/tmp/...绝不把HOME、CARGO_HOME、RUSTUP_HOME等指向 scratchscratch 在目标结束时会删除、TEST PROACTIVELY每步改动后立即测试等goal_rules_legacy.mdlegacy 路径下的同构模板同样拼入{DISCIPLINE_BLOCK}goal_plan_block.mdplanner 启用且计划存在时注入的计划即完成标准块要求按## Task checklist顺序执行、把偏差记入唯一的## Deviations一节、在声明完成前亲自运行计划的## Verification plan并保存持久证据goal_continuation_directive.md回合未完成时的续作指令固定包含哨兵串 Goal NOT complete — continue working. Next step:并内联 verifier 的差距清单、策略建议与 re-verify 块。从代码路径看render_goal_task_discipline()同时被render_goal_rules()与render_goal_rules_legacy()调用goal_support.rs而这两者分别在setup_goal、resume_goal处按goal_runs_on_workflow_engine()选择使用保证新旧路径下纪律完全一致。四、纪律失效时的兜底自动暂停与续作机制模板强调目标循环会在验证通过前重新拉起你而 harness 侧确实有对应的强制机制。从 goal_support.rs 可见/// Number of consecutive non-completing goal-mode turns before the goal auto-pauses with GoalPauseReason::BackOff. pub(super) const GOAL_CONTINUATION_BACKOFF_THRESHOLD: u32 3;即连续 3 轮未完成目标模式回合后harness 会用GoalPauseReason::BackOff自动暂停目标见 turn.rs 附近的goal_continuation_streak计数与阈值判断。这既是对规则 2/4 的强制执行——反复确认、反复空转都会消耗续作机会——也避免模型无限空转烧 token。配套的续作指令还会根据情况注入额外内容全部实现在 goal_support.rsrender_goal_reverify_block()目标曾被验证拒绝且自上次验证已运行超过阈值默认GOAL_REVERIFY_AFTER_DEFAULT 8轮可用GROK_GOAL_REVERIFY_AFTER覆盖时注入 Re-run the verification plan before continuing.超过 3 倍阈值则升级为 STOP DRIFTING — VERIFY THE REMAINING GAP NOW.直指修单一具体差距不要做表面改动render_verifier_gaps_block()内联对抗性 skeptic 面板拒绝完成声明时给出的差距清单要求优先修复后再声称完成render_strategist_note()当模型每轮标记的差距各不相同疑似原地打转时由 strategist 角色给出结构性建议用不可猜测的 nonce 围栏包裹并显式声明这是 advisory 而非 harness 指令。这些机制与四条纪律形成闭环纪律管住模型的主观意愿兜底机制管住客观结果——不遵守纪律导致的空转会被计数、暂停并重新引导。五、如何在项目中使用与观察这套规范触发路径在会话中输入/goal objective开启目标模式或在目标暂停后用/goal resume恢复。首次启动的提醒以system-reminder注入正文包含Objective:、计划块若 planner 启用、纪律块Rules 1–4与 TRACKING/WORKING/VERIFY/SCRATCH 等段落。动态工具名模板中的{TODO_TOOL}会在渲染时替换为当前会话注册的 Plan 工具名默认回退todo_write。如果要在自定义 agent 配置中替换 todo 工具只需保证该工具在工具桥中注册为ToolKind::Plan。观察纪律是否生效harness 在每轮回合后评估完成度未完成则产生 continuation directive含哨兵串 Goal NOT complete — continue working.连续 3 轮未完成后自动暂停并提示/goal resume。这些提示与暂停原因都可以在会话输出与 goal 状态中直接观察到。调优常量GOAL_CONTINUATION_BACKOFF_THRESHOLD连续未完成轮数阈值、GOAL_REVERIFY_AFTER_DEFAULT可经GROK_GOAL_REVERIFY_AFTER环境变量覆盖等均为编译期/配置常量位于 goal_support.rs调整它们可以控制目标模式的激进程度。结语goal_task_discipline.md看起来只是四条朴素的行为规则但它在 grok-build 中承担着目标模式防止模型假装工作的核心约束先调用后叙述、不请示明显下一步、用 todo 记账而非交付、不留下易做的工作提前停手。配合自动验证循环、连续未完成自动暂停、skeptic 差距清单与 strategist 建议这套规范让多轮目标工作既能自主推进又不会失控空转。理解它的渲染链路include_str!→render_goal_task_discipline→render_goal_rules→ system-reminder与兜底机制是深入 grok-build 目标模式乃至复用到其他 agent harness 的良好起点。【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-build创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考