提示词设计与 Skeptic 评审机制)
深入解析 grok-build 的对抗性验证器Adversarial Verifier提示词设计与 Skeptic 评审机制【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-buildxAI Grok Buildgrok-build是一个全屏、鼠标交互、可扩展的 coding agent harness 与 TUI其目标模式goal mode内置了一套由 harness 自主掌控的对抗性验证阶段当 agent 自认为完成某个目标时不会直接收工而是由多个独立的怀疑者skeptic子代理并行审查尝试驳倒目标已达成这一结论。本文以仓库中 goal_verifier_prompt.md 为核心骨架结合 goal_classifier.rs 等源码完整讲解该提示词的角色设定、输入证据包、审计规则、决策规则、严格输出契约以及它在 skeptic 面板聚合、防卡死anti-ratchet与 fail-open 机制中的落地方式。读完本文你将掌握这套验证者提示词 多评委表决闭环的原理与工程实现可直接对照源码定位每一个规则对应的代码位置。一、为什么需要对抗性验证器目标模式的默认不信在 grok-build 的目标模式下agent 每轮迭代都会产出完成声明FINAL_RESPONSE。经验表明一个自信满满但未经检验的总结极可能掩盖未完成的验收标准、跳过的测试甚至伪造的改动清单。因此验证阶段的核心设计哲学是验证者不是产出工作的 agent而是独立的对抗者adversarial verifier任务不是确认目标已达成而是尽可能驳倒refute这一结论不确定时默认refuted: true——放行一个坏结果false-positive会错误地终结循环代价远高于多迭代一轮。这一默认不信的偏差被刻意编码在提示词第一段并在源码中多处落实例如 parse_skeptic_terminal_response 规定只有响应精确等于Refuted或Not Refuted才被识别为有效票其余任何内容含代码围栏、多余文字一律视为无效read_skeptic_verdict 在 JSON 缺失或损坏时以refuted: true合成一票即缺失证据按失败计。验证阶段在运行时的入口是 run_verification_stage它会并发派生出N个 skeptic 子代理每个子代理收到渲染好的提示词即本文主题模板并把各自的 JSON 判决写回 verdict 文件最终由聚合函数 aggregate_skeptic_verdicts 决出是否通过。二、输入证据包Skeptic 审什么提示词明确列出每个 skeptic 的六类输入。这些字段不是空泛的占位符而是由 evidence.rs 中 build_classifier_evidence_packet 以严格格式拼装的证据包字段说明源码中的证据来源OBJECTIVE用户目标的逐字原文是不可变契约由调用方传入原样嵌入不做任何清洗PLAN_FILEMarkdown 计划文件路径含编号验收标准缺失时为(unavailable)PLAN_UNAVAILABLE 哨兵值PLAN_CHANGESagent 在运行期间编辑 PLAN_FILE 的 diff未编辑为(none)capture_plan_changes 通过git diff --no-index对比计划基线快照与当前计划CHANGES_FILE统一的 diff 变更日志作用域指针 诚实性校验锚点不是唯一证据可能被截断capture_changes_diff三层回退记录基线 → 惰性 git 基线 → walkdir mtime 合成 diffCHANGED_FILES本目标创建/修改的完整文件清单skeptic 必须读取其当前内容extract_changed_files 从完整 diff 头提取最多渲染 300 条超出以(… and N more)提示FINAL_RESPONSEagent 自己的总结对code-change类型散文不是证据只用来找攻击点sanitize_final_response 清洗控制标记后再嵌入PRIOR_GAPS上一轮验证要求实现者修复的缺口清单首轮为(none)sanitize_prior_gaps 清洗后填充{PRIOR_GAPS}占位符证据包的设计有几个关键点值得注意CHANGED_FILES 是首要锚点验证不依赖 diff 本身而是要求 skeptic 读取这些文件的当前磁盘内容——防止 agent 用改完又改回去的方式骗过 diff计划篡改本身就是驳倒理由如果PLAN_CHANGES显示 agent 弱化、删除或自利性修改了验收标准提示词判定其本身即可构成 refute控制标记注入防护模型/工作区派生的文本FINAL_RESPONSE、skeptic 的 evidence在嵌入提醒框架前会被 neutralize_reminder_tags 用零宽空格打断system-reminder/goal-state字面标签防止模型输出反向劫持提示框架变更文件路径中的换行控制字符则被替换为UFFFD见 sanitize_path_control_chars。三、Anti-ratchet收敛而非反复翻旧账重验轮PRIOR_GAPS非空是这套机制防止目标永远无法完成的关键规则。提示词要求首要任务是核对每个先前缺口是否被真正修复轮与轮之间的标准不得抬升仅当新反对意见是已交付行为的可证明缺陷或计划中未满足的门槛标准时才允许作为 refute 理由风格偏好、测试构造偏好一律不算每轮提出全新 nitpick 而标准全部成立正是目标无法收尾的失败模式当所有先前缺口修复、所有门槛标准成立时必须返回Not Refuted。这一防棘轮约束在实现层面有配套机制skeptic 0 被设计为跨轮次持久化的拒绝看门人reject-gatekeeper在N 1时通过 goal_verifier_resume_prompt.md 的增量复检提示词跨轮恢复其会话——它带着上一轮指出的缺口继续审查避免冷启动的新 skeptic 每轮引入全新反对意见。若恢复派生失败会话丢失run_one_skeptic 会回退到冷启动。另外缺口指纹gap fingerprint机制用于检测卡死循环见 gap_fingerprint它从原始证据中提取去重、排序、小写化的path:line引用并把/tmp/等每次尝试都会变化的 scratch 路径归一化为scratch从而让相同缺口在多次尝试中产生相同指纹连续命中停滞阈值GOAL_CLASSIFIER_STALL_THRESHOLD 默认 2 次即触发策略师strategist介入。四、Audit, dont author审计而非重写提示词要求 skeptic 采用审计者而非作者姿态只审计实现者已经产出的证据不自己构建一套并行测试套件定位测试与捕获输出{IMPLEMENTER_SCRATCH}目录以及## Verification plan点名的任何路径是主要证据来源判断测试是否 HONEST诚实而非 HACKY花架子真实驱动线上代码路径的测试是诚实的硬编码期望值、mock 掉被测单元、从被测物之后开始的场景、对重实现断言、#[ignore]/todo!()、用生成/伪造产物充当证明都是不诚实测试环境边界注入是允许的在时钟、RNG、网络/文件/输出汇等环境边界注入 fake使单元真实逻辑可观察、可确定是标准做法且属诚实只做廉价抽查读关键文件仅在便宜时才自己运行代码优先复用实现者捕获的运行结果明确禁止为 skeptic 构建独立测试套件或自行生成证据作为主要证明。在仓库实现中这个不越俎代庖的边界由输出契约强制skeptic 唯一的写操作是{DETAILS_FILE}与{VERDICT_FILE}其余一律只读提示词还明确do NOT modify the workspace。skeptic 的只读工具集由 RoleToolNames 渲染进{READ_TOOL}、{SEARCH_TOOL}、{LIST_TOOL}等占位符确保它具备读文件、grep、列目录的核验能力。五、决策规则九条铁律提示词第 38-46 行的决策规则是判定行为的核心法典逐条梳理如下OBJECTIVE 与具名工件是不可变契约先枚举 OBJECTIVE 的每一条显式要求检查其点名的每个 URL、文件、工单、文档或图片若某个必须检查的具名工件无法查看则refuted: true且blocking: unverifiable。CI/流水线/Actions/远程任务/部署等外部检查系统本身即具名工件其自己最新的裁决才是唯一充分证据——本地重跑仅作佐证因为本地状态工具链版本、gitignore 文件、未提交文件常与远端不一致。PLAN_FILE只是派生清单其编号标准可澄清但不可收窄或覆盖OBJECTIVE## Implementation approach与## Task checklist是实现指引偏离它们本身绝不构成 refute 理由。analysis/research类型例外交付物是书面散文空 diff 也合法直接按磁盘工件或 FINAL_RESPONSE 评判内容。禁止在契约之外发明要求——每项标准都满足时返回Not Refuted即便你能想象作者还能做得更多。诚实性检查FINAL_RESPONSE 声称改了某文件而 CHANGED_FILES 中没有该文件即伪造refute。遗留品检查TODO/FIXME/unimplemented!()/todo!()、跳过的测试、#[ignore]/pytest.mark.skip——refute。code-change 必须有诚实测试缺少驱动已交付改动的仓库内测试即 refute 理由这个测试本可以更强属于建议而非 refute仅当测试不诚实时才 refute。无法通过测试脚手架证明的端到端结果UI、浏览器、长交互会话不构成 refute——计划中定义的静态/结构性回退满足即可。CHANGES_FILE 不可用时的自救自行用git log/status/diff、读文件调查规则 1-4 仍然适用完全无证据 ⇒ refute规则 6。证据真正模棱两可CHANGES_FILE 可用⇒ refute。验证计划要求捕获证据实现者必须已产出存在于{IMPLEMENTER_SCRATCH}或仓库中并显示所列观察缺失或不充分 ⇒ refute 并要求实现者补交skeptic 不得自己生成。生成/伪造的工件不算证据。refute 分类blocking: none普通模型可修、contradiction目标/计划内部自相矛盾、unverifiable当前环境无法取证。后两者意味着目标需要用户决策而非重试。## Goal kind决定审查镜头计划中的## Goal kind标签被 parse_goal_kind 解析分别注入不同镜头模板code-change注入 goal_verifier_kind_lens_code_change.md资深工程师对抗式代码审查主动猎杀可演示的真实缺陷research注入 goal_verifier_kind_lens_research.md逐条核对引用源、打击编造与过期信息、要求呈现来源冲突analysis注入 goal_verifier_kind_lens_analysis.md结论必须有证据支撑且可推导。镜头通过{KIND_LENS}占位符拼入主模板见 kind_lens。六、Scratch 目录与输出契约提示词为 skeptic 提供了明确的目录分工{IMPLEMENTER_SCRATCH}实现者的输出与捕获证据主要来源只读{SKEPTIC_SCRATCH}skeptic 自己的目录仅用于廉价抽查重跑## Verification plan时{SCRATCH}占位符解析到此{SCRATCH_STATUS}由渲染器根据目录是否真实创建替换为 Both dirs have been created for you. 或 Create your own scratch dir withmkdir -pif it is missing.见 render_verifier_prompt。这些目录在运行时由 goal_tracker.rs 的 goal_scratch_root 与 ensure_goal_scratch_root 管理每个目标的 scratch 根目录以0700权限创建owner-only并派生implementer/与skeptic-{idx}/子目录L411-L418。安全上有明确的防 symlink 攻击设计分类器工件绝不落在裸/tmp因为其文件名可被预测公开可写目录会让本地攻击者预埋符号链接劫持 harness 写入见 GOAL_CLASSIFIER_DETAILS_PATH_TEMPLATE 的注释路径校验器 validate_details_path_in_root 还会拒绝..、NUL 字节、/etc、/proc、/sys、/dev、~前缀及未解析的替换占位符。输出契约是三重的JSON 判决 →{VERDICT_FILE}固定 schema必填refuted、evidence、confidence可选blocking、details_md、findingsfindings数组是实现者实际执行的首要输出每项含kindbug/gap/todo、locationpath:line或位置描述、detail一行具体描述详情 →{DETAILS_FILE}同一批 findings 的人类可读 Markdown 渲染终端 token输出必须恰好是Refuted或Not Refuted之一不允许任何散文、围栏或标点。这三重契约在 harness 侧有严格对应parse_verdict_json 要求refuted/evidence/confidence三字段齐全、evidence非空否则返回None防橡皮图章缺失或空 evidence 直接触发 skeptic 级refuted: true合成票parse_skeptic_terminal_response 对终端 token 的解析容忍围栏与尾点号但响应中只能有token 本身。七、面板聚合多数决、Variant-C 与决定性 refute验证阶段默认并行派出3 个 skepticGOAL_VERIFIER_SKEPTIC_COUNT可通过环境变量或远程设置调整配置项环境变量远程设置默认取值范围源码位置每轮 skeptic 数量GROK_GOAL_VERIFIER_Ngoal_verifier_count31..5clampresolve_goal_verifier_count每目标验证轮数上限GROK_GOAL_CLASSIFIER_MAXgoal_classifier_max_runs10≥1有下限无上限resolve_goal_classifier_max_runs选择 3 的默认值有明确动机见 GOAL_VERIFIER_SKEPTIC_COUNT 注释⌈3/2⌉ 2的not refuted多数才能通过单一离群者无论是一张橡皮图章还是一个误 refute都无法左右结果而 N2 时 1:1 平局会让一个宽容 skeptic 放行一个严格 skeptic 会否决的工作。聚合逻辑 aggregate_skeptic_verdicts 实现了Variant-C规则total 1唯一裁判时孤票即定案面板扇出total 1时skeptic 0 的不否决票不计入通过需要冷面板skeptic_idx 1的严格多数needed cold_count / 2 1skeptic 0 的否决票仍然计入refuted_count、缺口摘要和暂停摘要运输/取消/运行时/格式错误等所有降级路径都在每个 skeptic 层面合成refuted: true见 skeptic_failure聚合器只数票——偏向失败被刻意放在证据缺失的上游。此外还有升级式面板见 run_verification_stage 注释N 1时先单独跑 skeptic 0若它以高置信 refute 且非 blocking则决定性短路跳过其余 N-1 个派生若其 refute 是 blocking矛盾/不可验证则仍扇出全面板以区分需要用户决策的 Blocked与存在可修缺口的 NotAchieved。最终achieved quorum_achieved !decisive_refute。当所有 refute 都是非模型可修 blockercontradiction/unverifiable时结果路由为Blocked并自动暂停目标等待用户决策见 run_verification_stage只要存在一个可修缺口就保持NotAchieved继续迭代。缺口摘要按置信度从高到低渲染进拒绝提醒build_gaps_summary并分为Model-fixable gaps / Contradictions / Unverifiable in this environment三组生成暂停消息build_pause_summary。八、Fail-open内部失败永不阻塞用户进展当 harness 自身无法取得 verdict 时基础设施级故障而非判定为未达成验证阶段执行fail-open见 record_fail_open把目标当作FailOpenAchieved处理写入占位详情文件说明验证未产生 verdict、原因、未捕获任何 skeptic 分析并发射GoalClassifierFailOpen遥测事件。这对应提示词中的分类学PARSE 级结果子代理产出了可用 verdict才是Achieved/NotAchieved而 PARSE 级失败关闭终端 token 格式错误、详情文件缺失映射到NotAchievedINFRA 级失败则走 fail-open。文件写入失败路径同样 fail-open如 run_verification_stage 中详情路径或 patch 路径校验/写入失败时。九、从提示词到代码完整调用链把以上机制串起来一次验证的完整生命周期是目标创建setup_goal尽力捕获 git 基线git rev-parse HEAD预算 1 秒失败不阻塞目标创建见 capture_git_baseline并创建 per-goal scratch 根目录agent 迭代实现者产出改动、测试与捕获证据到{IMPLEMENTER_SCRATCH}证据捕获capture_changes_diff 按三层回退生成 diff记录基线 → 惰性 git 基线 → walkdirmtime 合成diff 正文上限 GOAL_CLASSIFIER_DIFF_MAX_BYTES256 KiB截断并带显式标记计划变更 diff 由 capture_plan_changes 用git diff --no-index计算提示词渲染render_verifier_prompt 把模板中的{KIND_LENS}、{DETAILS_FILE}、{VERDICT_FILE}、{SKEPTIC_SCRATCH}、{IMPLEMENTER_SCRATCH}、{SCRATCH_STATUS}、{PRIOR_GAPS}全部替换并追加证据包作为用户提示并发派生ChannelSpawner 通过子代理协调器通道直接派生 skeptic不走task工具调用父模型转录保持干净支持按索引的模型/工具集覆盖与 fail-open 重试判决回收read_skeptic_verdict 以 JSON verdict 文件为准缺失/损坏时回退终端 token两者都不可用则合成 refute聚合与路由aggregate_skeptic_verdicts 计算 quorum结合决定性 refute 得出Achieved/NotAchieved/Blocked写入聚合详情文件上限 GOAL_VERIFIER_PANEL_MAX_BYTES512 KiB并向 TUI 推送含verifying_completion徽标的GoalUpdated状态更新见 build_goal_updated下一轮若NotAchieved缺口摘要与指纹进入下一轮{PRIOR_GAPS}skeptic 0 会话 id 被持久化以便恢复用户暂停/恢复时尝试计数重置但看门人保留。十、最佳实践如何自定义与调优对照模板与源码使用方可以这样调整验证行为调整怀疑强度默认 3 个 skeptic 已保证多数决追求极致审查可设GROK_GOAL_VERIFIER_N5上限追求速度可设 1唯一裁判无恢复语义控制迭代上限GROK_GOAL_CLASSIFIER_MAX默认 10 次验证尝试有下限无上限配合 stall 阈值连续相同缺口指纹 2 次触发策略师介入防止无限空转为不同目标类型启用镜头在计划文件中书写## Goal kind标签code-change/research/analysis即可自动切换对抗式代码审查、事实核查或论证健全性审查镜头理解 fail-open 语义内部故障会以达成放行并留痕占位详情 遥测这是刻意的权衡——内部失败绝不阻塞用户进展代价是放弃本轮审查。这套默认不信 → 多评委表决 → 防棘轮收敛 → 可恢复暂停的验证闭环是 grok-build 目标模式在长任务可靠性上的核心工程手段本文所讲的模板正是驱动它的行为宪法所有规则都能在 goal_classifier.rs、goal_classifier/evidence.rs 与 goal_verifier_resume_prompt.md 等文件中找到一一对应的实现与测试。【免费下载链接】grok-buildSpaceXAIs coding agent harness and TUI. Fullscreen, mouse interactive, extensible.项目地址: https://gitcode.com/gh_mirrors/gr/grok-build创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考