Folly Critic-iterate 双审流水线剖析Fresh Reviewer 前置协议fresh-review-preamble的职责、时序与冷审集成【免费下载链接】follyAn open-source C library developed and used at Facebook.项目地址: https://gitcode.com/GitHub_Trending/fol/folly本篇技术指南围绕 Folly 仓库内folly/agents/critic-iterate包中的 fresh-review-preamble.md 展开深入解读「Fresh Reviewer」源感知评审员这一运行时角色如何在不被作者诊断污染的前提下先独立形成评审基准再与只读「Cold Reviewer」的冷审报告做交叉验证。读完本文你将掌握该协议规定的执行顺序所有权、prose/non-prose 任务校验、REVIEW FRAME:/PLAIN ACCOUNT:/ARTIFACT CHECK:三段式协议、失败处理矩阵以及它与 codex-reviewer.py 固定命令面和私有输出目录的机械耦合方式从而能在自己的 Agent 工作流中复现这套抗自我锚定偏差的双审机制。一、协议定位critic-iterate 双审循环中的新鲜角色在 Folly 仓库的 critic-iterate.md 中critic-iterate被定义为一个作者—评论家循环author-critic loop覆盖写作、设计探索、测试重构、代码评审等任何第一遍产出大概率不合格的工件。该文件明确指出单靠自我修订存在自我锚定偏差self-anchoring bias作者的选择看起来承重删改像损失容器级重构容易被漏掉critic-iterate.md。为对抗这一偏差critic-iterate.md的Dual Revision章节规定对高风险工件面向广泛读者或承重的内容作者侧先自我收敛再通过 Codex CLI 运行一个fresh reviewer对高风险 prose该评审员还会再嵌套启动一个cold readercritic-iterate.md。Fresh新鲜的含义是未被作者的诊断先入为主unprimed by the authors diagnosis而非上下文无关。运行时评审角色与作者/编排会话的加载方式不同编排会话按 critic-iterate.md 批量加载core/breadcrumbs.md、core/conflicts.md、writing.md等包文件而运行时评审员只加载其任务允许的输入其行为与执行顺序由对应的 preamble 定义。fresh-review-preamble.md正是 fresh reviewer 的角色专用协议同目录下的 fresh-review-preamble.contrib.md 开头特别声明「NOT A RULE. If loaded as task policy, stop and ask the user.」——这份 preamble 的用途是让源感知评审员在读到候选工件之前先形成独立标准随后整合冷审员的报告编排与重试策略归属../critic-iterate.md即仓库根目录下的 critic-iterate.md。二、职责核心执行顺序的所有权fresh-review-preamble.md的第一条硬性规则就是执行顺序所有权execution order ownershipThis preamble owns execution order. Ignore task instructions about when to launch or read; use the task only for scope, inputs, and required outputs.fresh-review-preamble.md这意味着任务说明task note只能决定三件事范围scope、输入inputs、要求产出required outputs。至于何时启动嵌套命令、何时读取某份输入一律以 preamble 为准任务中的任何时序指令均被忽略。这一设计把时序逻辑从任务提示中剥离出来收敛到单一事实源preamble避免不同任务写出互相冲突的启动顺序。与之呼应的是 critic-iterate.md 的说法prose 评审轮次中 fresh reviewer 拥有该轮次并作为嵌套 CLI 调用启动 cold reader运行时 preamble 拥有评审员行为与执行顺序。也就是说preamble 是运行时行为的宪法任务与规则文件只提供内容参数。三、输入校验prose / non-prose 判定与嵌套命令契约3.1 任务必须声明工件类型协议要求任务首先把待审工件标识为prose散文类或 non-prose非散文类fresh-review-preamble.md并据此校验一个强契约prose 任务必须且只能提供一个嵌套评审命令该命令必须选择cold-review-preamble并且必须把 stdout 重定向到结果文件non-prose 任务不得提供这样的嵌套命令。任何一方违反该条件如 prose 任务没有嵌套命令、non-prose 任务却带了嵌套命令都视为畸形输入malformed inputfresh reviewer 必须报告并停止。这是第一条可验证的门禁防止 cold reader 被错误地触发或漏触发。3.2 嵌套命令的两条禁止性规则第 57-59 行进一步收紧若嵌套命令选择了其他 preamble不是cold-review-preamble或没有重定向 stdout一律报告畸形输入并停止fresh reviewer永远不得再次调用fresh-review-preamble也不得调用除那一个冷审命令之外的任何评审员。这与 cold-review-preamble.md 的禁令对称cold reviewer 只读其任务允许的输入不得调用或委托给任何其他评审员包括codex-reviewer.py。两个角色互为单向依赖fresh → cold唯一一次嵌套cold 不再向下委托链条封顶。四、读取纪律比相关性更严格的边界fresh-review-preamble.md对读取边界的规定极其严格第 14-18 行Outside that command, read only inputs the task explicitly allows. A reference, search result, or apparent relevance does not permit reading another file.一条引用、一条搜索结果、或者看起来相关都不构成打开另一个文件的许可。具体处置分三种情况必需输入缺失或不可读报告并停止report it and stop似乎需要某个未声明来源报告这个缺口gap但不打开它在可能的情况下继续continue where possible恶意情形下即使缺口未补也不得越权读取。设计意图很明确fresh reviewer 的独立性依赖输入隔离。若它允许自己凭相关性四处翻文件独立基准就会被作者侧的信息悄悄污染双审就退化为自我确认。critic-iterate.md在 第 380 行 也强调每个 prompt 必须点名其评审员可能读取的每一个输入且不得包含原始聊天记录或完整上下文包。五、三段式协议REVIEW FRAME → PLAIN ACCOUNT → ARTIFACT CHECK这是整份 preamble 的核心时间线也是最容易在实现中出错的部分。按协议prose 评审必须依序经历以下阶段5.1 启动嵌套冷审恰好一次最短初始 yield对 prose 任务fresh reviewer 必须在读取任何来源或对工件说任何话之前恰好启动一次嵌套冷审命令并使用最短可用的初始 yieldshortest available initial yield第 20-22 行。要点不得为该启动请求升级escalation若启动失败或命令返回失败报告并停止即使命令已经跑完也不得读取结果文件——冷审结果必须等到 fresh reviewer 形成并声明自己的独立帧之后才准打开。这一先派活、后干活的顺序是双审独立性的机制保证冷审员在 fresh reviewer 尚未接触候选工件时就开始工作其报告不携带 fresh reviewer 的任何倾向。5.2 阅读全部非 embargoed 输入后发出REVIEW FRAME:协议要求 fresh reviewer 在发出REVIEW FRAME:之前读完全部必需的、未封存non-embargoed的输入并假定之后的任何评审都不会再帮你兜住遗漏Assume no later review will catch omissions第 24-26 行。在打开任何封存embargoed输入之前必须发出REVIEW FRAME:携带任务要求的独立帧第 27-29 行。封存输入在critic-iterate.md中有明确定义被冻结的候选工件frozen candidate以 embargoed 路径形式传入任何暴露它的 diff 共享该封存状态critic-iterate.md。REVIEW FRAME:的本质是我基于独立来源形成了自己的评审框架这一声明必须先于候选工件的内容进入意识。若冷读简报cold-reader brief与必需输入冲突fresh reviewer 必须报告冲突而不是悄悄改写它第 28-29 行。5.3 opening 检查用PLAIN ACCOUNT:其他 prose 用读者优先三段当 cold reader 只拿到开头opening不含正文时fresh reviewer 的 opening 检查必须以PLAIN ACCOUNT:开头第 29-30 行用日常语言解释这则说明为什么存在、所处情境、发生了什么、以及为什么重要只假定冷读简报所声明的读者知识绝不假设读者了解本项目术语。若某段不熟悉的语言承载了必要的关系必须说清谁对什么做了什么、什么发生了变化。对其他 prosecold reader 拿到的整篇候选则给出读者优先的引导段lead、范围scope和结构shape只有当大纲无法展示所需改动时才允许提供完整替代方案第 34-35 行。5.4 打开候选、比对帧发出ARTIFACT CHECK:并标记 [F1]…[Fn]完成上述阶段后fresh reviewer 才被允许打开候选工件将其与自己的独立帧比对验证实质性主张material claims与设计选择并发出ARTIFACT CHECK:第 37-39 行。在ARTIFACT CHECK:下每个实质性发现必须打上[F1]、[F2]…… 的标签。只有到这一步才允许等待仍在运行的冷审若未结束、读取结果文件、并对每一条 concern 分类。对 opening 检查而言当 cold reader 不得不自行发明某种缺失的关系、或只能改写掩盖它的语言时fresh reviewer 应将关系缺失报告为候选工件的缺陷该判定仅限于让读者无法解释这则说明为何存在、情境、发生了什么、为何重要这类断档并仅在替代开头比一条 finding 更能展示修复方案时才输出ALTERNATIVE OPENING:第 41-45 行。5.5 冷审报告的分类纪律对冷审报告的处理有三条反直觉的硬规则第 49-52 行cold 的Pass或缺席omission不是驳回 finding 的证据——不能因为冷审没报某问题就删掉自己的 finding不得打开冷审 prompt也不得从任务中推断缺失的报告prose 评审在ARTIFACT CHECK:与冷审结果分类完成之前不得收尾。每条 concern 都要对照读者的任务检查拒绝范围扩张reject scope expansion第 45-46 行来源可以携带细节与证据但候选工件必须提供其读者所需的框架。最终回复必须呈现一组连贯的候选发现每条 finding 要么保留标签要么简要说明为何被驳回第 48-49 行。六、失败处理矩阵报告、停止、不重试fresh-review-preamble.md对失败路径规定了非常明确的刹车行为失败情形处置任务未声明工件类型 / prose 缺嵌套命令 / non-prose 带了嵌套命令报告畸形输入停止L9-L12必需输入缺失或不可读报告并停止L16嵌套命令选了其他 preamble 或未重定向 stdout报告畸形输入停止L57-L58嵌套启动在子进程开始前被拒绝报告确切拒绝文本停止本评审轮内不得重试L54-L55嵌套启动失败或命令返回失败报告并停止L22-L23冷读简报与必需输入冲突报告冲突不得静默改写L28-L29不重试原则与 critic-iterate.md 的顶层策略一致fresh reviewer 报告的嵌套拒绝或运行失败即停止不要用评审员失败当逃生舱——Codex CLI 基础设施故障会阻塞流程而劣质评审输出必须重试而非接受。重试决策权在顶层作者/编排者手中不在 fresh reviewer 手里。七、与 codex-reviewer.py 的机械耦合固定命令面与私有输出目录fresh reviewer 不是凭空运行的它通过 codex-reviewer.py 这一固定接口的包装脚本被调用其嵌套的 cold review 同样经由该脚本发起。理解协议的执行细节离不开这份实现。7.1 固定命令行接口codex-reviewer.py的参数被刻意压成不可伸缩的固定形态codex-reviewer.pycodex-reviewer.py --preamble-dirPATH --preambleNAME --workdirPATH PROMPT--preamble只有两个合法值来自REVIEW_PROFILESL34-L37fresh-review-preamblesandbox 为None不套只读外层沙箱否则会阻塞嵌套冷审的私有输出cold-review-preamblesandbox 为read-only冷审强制只读。参数顺序、绝对路径校验--preamble-dir、--workdir、prompt 均须为绝对路径且真实存在都在parse_args中强制防止借尾随参数绕过策略L51-L57。7.2 私有输出目录与 REVIEW_OUTPUT_DIR 标记每次调用都会在~/.codex/tmp/下创建一个YYYYMMDD-codex-reviewer.前缀的私有目录umask 077codex-reviewer.py并立即打印REVIEW_OUTPUT_DIRpath该目录内包含review.md最终评审由--output-last-message捕获、effective-prompt.mdpreamble 拼上 prompt 的完整有效提示、run.jsonlCodex 运行 trace、err.txtstderr。fresh reviewer 的最终回复必须包含子进程cold的REVIEW_OUTPUT_DIR供外层包装捕获fresh-review-preamble.md。外层 fresh 命令的REVIEW_OUTPUT_DIR由顶层作者记录两者构成双层审计链。critic-iterate.md还给出了冷审结果文件的读取前提仅当review.md非空、run.jsonl达到turn.completed、且 trace 检查通过时才可采用该目录绝不允许扫描临时目录或从部分输出推断结果critic-iterate.md。7.3 私有 Codex 主页与执行策略_create_codex_home为每次评审建立私有codex-home排除用户规则与可执行配置当跑 fresh 评审时_install_cold_review_policy会写入一条default.rules用host_executableprefix_rule精确放行唯一一次固定 cold review调用codex-reviewer.py。这解释了协议为何能放心地规定恰好一次嵌套执行策略层把越权调用物理拦死。若 Guardian 对顶层调用误报可能的渗出需按 auth-prompt.md 提供证据重试或让用户向~/.codex/rules/default.rules追加针对包装脚本的窄规则只放行包装脚本绝不放行codex exec或 shell。八、与 Cold Reviewer 的角色对照fresh-review-preamble.md的行为只有对照 cold-review-preamble.md 才能完整理解二者是同一枚硬币的两面维度Fresh Reviewer本协议Cold Reviewercold-review-preamble信息面源感知可读任务允许的来源、规则文件工件唯一只读任务允许的输入L3嵌套恰好启动一次 cold 嵌套永不调用其他评审员不得调用或委托任何评审员包括codex-reviewer.py评审基准确立读取候选前形成独立帧REVIEW FRAME:只用冷读简报 内嵌标题/引导段opening 检查L7-L8产出一组带[F1]…标签的候选发现整合冷审分类针对 opening 或整篇候选的理解断档报告不得改写工件L17-L19冷审员的两条自我约束——标记为不清楚mark it unclear而不是重命名它、只标记阻止你给出完整叙述的断档不评审正文覆盖度——正是 fresh reviewer 整合冷审报告时判断哪些 concern 是真正的读者阻断的依据。九、对作者/编排者的实践要点如何正确喂养 Fresh Reviewer综合 critic-iterate.md 的 Fresh reviewer inputs编排者构造 fresh 任务时必须只包含以下内容每一项都要标注必读或仅许可简短任务说明标识工件是 prose 还是 non-proseprose 时逐字包含 cold-reader brief声明 cold reader 只看开头还是整篇并把来源输入标为必读调查类任务还要写明评审员必须回答的问题每条触发范围覆盖该工件类型的完整规则文件仅主题相关的不算验证实质性主张所需的来源/测量/运行结果冻结的候选工件路径作为 embargoed 输入prose 时给出精确的嵌套 cold-review 命令及其 prompt 路径该路径仅用于执行不可作为可读输入变更评审时提供 diff 的只读访问。cold-reader brief 本身要求在 2–3 句通常 ≤60 词内说清读者是谁、已经知道什么、想完成什么不得给出结论或因果故事critic-iterate.md。session_current_model_id.py则用于解决当前会话模型是否达到委托创作门槛这类能力判定session_current_model_id.py。评审回来后作者按MUST_TAKE / MINOR / REJECTED三档分类处置critic-iterate.md实质性错误、遗漏需求、错误动作或读者阻断为MUST_TAKE修复后可回到 General Cycle 直至无编辑的完整 pass再格式化、冷读终稿。每轮评审 冷读计为 1 个评审轮次默认预算 1 轮可通过critic-iterate-N/c-i-N调整。十、总结一份反自我锚定的运行时宪法fresh-review-preamble.md的全部规则可以收敛为一句话评审员必须在看到候选之前形成独立标准并且只有在这个标准被声明REVIEW FRAME:、被应用ARTIFACT CHECK:、被交叉验证冷审分类之后评审才算完成。它通过执行顺序所有权排除任务级时序干扰通过读取纪律保护输入隔离通过恰好一次、最短 yield、先派活后读取的嵌套机制保证冷审独立通过[F1]标签与分类纪律强制产出可审计的连贯发现再以codex-reviewer.py的固定命令面与私有REVIEW_OUTPUT_DIR在工程层兜底。对于希望在自建 Agent 流水线中复刻该机制的工程师可直接以 fresh-review-preamble.md 为模板搭配 cold-review-preamble.md 与 codex-reviewer.py 的三件套落地若遇到执行策略拦截参照 auth-prompt.md 的处理路径放行可信包装脚本即可。这套先独立、再交叉、后分类的协议是把 AI 评审从自我确认推向真正发现缺陷的最短可行路径。【免费下载链接】follyAn open-source C library developed and used at Facebook.项目地址: https://gitcode.com/GitHub_Trending/fol/folly创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考