企业官网建设流程全解析

openai-agents-python 实现最终评审协议：独立评审员简报（reviewer-brief）与指纹轮次账本全解析

【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python

本篇技术指南围绕 openai-agents-python 仓库内置的implementation-final-review技能（位于 .agents/skills/implementation-final-review/）展开，深度解读其高风险评审路径中的核心文档——独立评审员简报（reviewer-brief.md）。该简报定义了评审员如何基于"指纹轮次 + 任务全局账本"机制，对一个冻结的代码快照执行一次只读、独立、可机器验证的评审。读完本文，你将掌握该仓库高严格度评审协议中的快照数据包（snapshot packet）结构、三类校验 CLI（packet/receipt/reviewer-output）、账本轮次与预算状态机、三类覆盖库存（contract / await-boundary / authority-data-flow）的填写规范，以及评审员 JSON 输出契约与 clean 判定的精确条件。

评审简报在整个实施最终评审流程中的位置

在 SKILL.md 定义的评审分级中，变更按语义影响被划分为三个等级：

reviewer-brief.md 正是高风险路径下评审员收到的唯一简报：SKILL.md 明确要求"不要为 lightweight 或 ordinary 变更准备 packet、receipt 或组件库存"。因此，本简报是仓库内机器可读评审协议的权威定义，与其配套的两个脚本 review_state.py（生成确定性指纹）和 review_protocol.py（校验 packet / 评审输出 / 收据）共同构成完整闭环。

第一性原理：指纹轮次与任务全局账本

简报开篇即给出整个协议的基石：

账本包含一个与数据包组合内容指纹相等的round_fingerprint。同轮重试必须保留不可变先前快照的round_fingerprint与已授权预算历史；指纹变更或新授权预算则要求恰好前进一轮。

这意味着每一轮评审都绑定一个确定性内容指纹。该指纹由 review_state.py 计算：_content_fingerprint(base, workspace)将{"base": base, "workspace": workspace}以sort_keys=True、紧凑分隔符序列化后做 SHA-256（见 review_state.py），其中 workspace 是任务拥有的每个文件的类型化条目（file/symlink/gitlink/directory/missing），每个条目只含path、kind、executable、sha256或head等精确字段（见 review_state.py）。

在 review_protocol.py 的validate_packet中，这一约束被机械化为硬校验（见 review_protocol.py）：

• ledger.round_fingerprint必须等于数据包指纹（即review_state.content_fingerprint）；
• ledger.current_round加上ledger.remaining_budget必须等于authorized_round_budgets（正整数数组）之和；
• 当前预算历史必须保留先前快照的前缀；
• 当前轮次必须等于先前轮次（同轮重试）或恰好加一；
• 同轮重试必须保留先前的round_fingerprint；
• 先前所有规范根原因（canonical root cause）及其所有权与摘要绑定必须仍然存在。

测试夹具 test_review_protocol.py 中给出了账本的典型形态：authorized_round_budgets: [6]、current_round: 1、remaining_budget: 5，对应高风险初始周期默认 6 轮预算；而 high-risk-review.md 第 21 步规定：初始实现周期绝对上限为 6 个指纹轮次，完成后反馈周期追加默认 2 轮，且永不重置轮次计数器。账本在暂停、压缩、交接、改名、恢复工作与完成后反馈之间保持同一个文件，这就是"任务全局"（task-global）的含义。

文件身份与路径安全：防 TOCTOU 的读取契约

简报第二段要求所有数据包、账本、清单、收据、评审输出与证据路径都必须解析为有限普通文件（finite regular file）：

• 打开前先规范化（canonicalize）每个路径；
• 打开后验证文件类型，并从同一个文件描述符读取内容；
• 路径级stat不得授权后续重新打开（即禁止"先 stat 后 reopen"的 TOCTOU 窗口）；
• 证据工件与已记账收据必须具有唯一的已打开文件设备号与 inode 身份，当前与先前账本必须具有不同身份；
• 在接受评审输出或可复用收据前，验证器会重新读取数据包与当前/先前账本，要求其已验证摘要保持不变；报告收据可复用时也会重读该收据；
• 设备、FIFO、套接字或生成流必须在验证前物化为普通文件。

该契约在 review_protocol.py 中体现为_read_bytes（要求绝对路径、resolve(strict=True)、通过_read_regular_file读取并以(st_dev, st_ino)作为FileIdentity，见 review_protocol.py）与_revalidate_control_files（用_read_unchanged按先前摘要重读数据包与账本，任何字节变化都抛出ProtocolError，见 review_protocol.py）。

底层读取函数位于 review_state.py：_read_regular_file使用O_NONBLOCK打开，随后os.fstat(file.fileno())检查stat.S_ISREG，从同一描述符读出全部字节。而"证据、收据、当前与先前账本不得互为别名"的规则，则通过比较打开的(st_dev, st_ino)实现：_evidence_artifacts拒绝文件身份重复的证据工件（见 review_protocol.py），validate_packet拒绝"先前账本与当前账本身份相同"（见 review_protocol.py）。

证据与库存 ID 的新颖性规则

简报第三段定义了"新"与"所有权"的精确语义：

• 对某个规范根（canonical root）而言，证据或库存 ID 仅在其内容摘要缺失于该根先前的所有权时才算新；
• 账本通过contract_evidence_sha256绑定每个规范根拥有的证据 ID，通过inventory_sha256绑定每个库存 ID；先前的绑定不可变；
• 库存摘要计算时只排除 ID 自身（其余字段参与摘要），因此重命名一个复制的行并不会使其变新；
• 新根提案要求证据摘要不存在于任何规范根且不存在于同一输出中提出的任何其他不同根；在实施者提升（promotion）之前，新提案不得复用规范库存；
• 已记账收据的内容摘要与确切命令必须唯一。

源码侧，_inventory_digest将行中除id外的字段做规范化 JSON 后取 SHA-256（见 review_protocol.py），恰好印证"排除 ID 自身"；_digest_map要求摘要映射键集合与当前拥有的 ID 集合精确一致（缺失或多余都报错，见 review_protocol.py）；根原因条目中的证据与库存 ID 必须分别解析到evidence_artifacts[].id与inventory[].id，否则报 "unknown"（见 review_protocol.py）。评审员的根 ID 规则是：复用简报提供的规范 ID，或提出NEW:<lowercase-slug>（正则NEW:[a-z0-9]+(?:-[a-z0-9]+)*，见 review_protocol.py）；新提案在实施者提升前inventory数组必须为空。一个已关闭的根只能在拥有内容全新的证据或语义库存时才可重开。

JSON 与数值严格性

每个 JSON 对象都必须使用唯一键与标准有限数字：

• 重复键非法；
• JavaScript 风格的NaN、Infinity、-Infinity常量非法；
• 溢出到无穷的数值指数非法；
• 运行时数值规模与嵌套深度失败必须转为协议错误，而不是泄漏原始解析器异常。

实现位于_json_bytes：json.loads传入object_pairs_hook=unique_object（遇到重复键抛ProtocolError）、parse_constant=reject_constant（拒绝三个非有限常量）、parse_float=finite_float（math.isfinite检查）；RecursionError、UnicodeError、ValueError全部归一化为ProtocolError（见 review_protocol.py）。这也是"协议错误而非原始解析器异常"的字面实现。

评审状态的两次连续观测

仅从两次连续相同的仓库观测生成评审状态。HEAD、status、diff、任务或仓库工作区、组件工作区任何一处变化都会使捕获失效。Git 无法表示为有限 blob 的任务自有 FIFO、套接字、设备等条目非法。

review_state.py 的review_state()在捕获前后各做一次_require_reviewable_index与_require_clean_submodules检查，并连续两次_capture_snapshot；若final_head != head或final_snapshot != snapshot，直接抛出 "Repository changed while review state was captured."（见 review_state.py）。

其中_require_reviewable_index会拒绝以下索引状态（见 review_state.py）：assume-unchanged路径、已物化的skip-worktree路径、unmerged（存在未解决的合并阶段）；_require_clean_submodules要求每个初始化子模块（含嵌套）HEAD 与父索引记录一致、工作树干净，并拒绝循环或别名化的子模块工作树图（见 review_state.py）。工作区条目类型检查则落实"Git 无法表示成有限 blob 的条目非法"：_workspace_entry对非符号链接、非文件、非目录、非 gitlink 且存在的路径报 "Unsupported workspace file type"（见 review_state.py）。

快照数据包模板：一份共享主体，多个评审员

简报要求"每个指纹轮次准备一个自包含、事实性的快照数据包"，并遵循三条纪律：

1. 填满每个字段，或明确标注none/not applicable，禁止派发不完整的数据包；
2. 只填写一次，为每位评审员逐字节复用共享主体，仅最终的专业分配（specialty assignment）不同；
3. 控制平面简报保持约 12 KB（源码常量PACKET_SOFT_LIMIT_BYTES = 12 * 1024，见 review_protocol.py），更大证据存入索引文件并按确切路径与 SHA-256 摘要引用；不得为迎合软目标而省略决策相关证据。

数据包不得包含实施者结论、疑似 bug、先前发现或计划中的修复——评审员的判断必须来自事实性证据。

共享证据（Shared evidence）清单共 17 项，构成每个数据包的标准内容：

1. 原始需求（Original requirement）；
2. 实施范围契约（Implementation scope contract）：必需行为、兼容性要求、有意不支持的用例与失败行为、受支持的替代方案或none；
3. 预期目标（Intended target）；
4. 已解析的合并基（Resolved merge base）；
5. HEAD；
6. 相关时的最新发布边界（Latest release boundary）；
7. 风险等级与理由（高风险需将task.risk_tier编码为"elevated"）；
8. 任务全局账本路径、任务身份、当前轮次与剩余授权预算；
9. 规范根原因账本（ID | open/closed | inventory IDs | contract evidence IDs）；
10. 规范任务清单（确切的规范化文件条目即使被忽略规则匹配也保持权威；目录与 glob 条目不会提升被忽略的文件）；
11. 组件清单（Component manifests）；
12. 语义组件依赖映射（component | exact base pathspecs | invalidation reason）；
13. 组合、组件与仓库指纹；
14. 精确的指纹重验证命令；
15. 未过滤的仓库状态工件与任务清单之外的显式排除项；
16. 使用review_state.py --complete-diff-output的完整三点 diff 命令（以确保任务自有的未跟踪文件被包含）；
17. 索引证据清单（ID | role | exact path | SHA-256 | purpose）。

此外还有：聚焦预检命令与结果（含与精确可执行钩子检查命令的幂等提交钩子一致性，以及本次指纹冻结前每个内容重写步骤的第二遍结果）、已记账的同指纹验证或none、已记账检查的验证收据路径与 SHA-256 描述符或none、合格并发最终门命令none（必需，因为广泛最终门只能在干净评审后启动）、推迟到干净评审后的广泛最终门、以及选定的架构参考或精确相关摘录。

机器可读预检：packet 命令与包索引

简报要求将共享数据包索引存储为一个 JSON 对象并在派发前验证：

python scripts/review_protocol.py packet --packet <packet.json> --task-id <task-id> --ledger <ledger.json> --prior-ledger <prior-ledger.json> --prior-ledger-sha256 <sha256>

（从技能目录执行；命令行的--prior-ledger与--prior-ledger-sha256在轮次 1 之后必须提供。）数据包对象使用整数schema_version: 1，顶层必须包含：packet_overage_reason、task、scope_contract、repository、ledger、manifests、review_state、verification、architecture_references、evidence_artifacts、inventory、selected_high_risk_dimensions、reviewer_assignments。

信任边界：活动的实施控制平面（active implementation control plane）负责记录真实的评审员派发、等待、输出与验证执行；本地 helper 只对这些记录做完整性、摘要、身份、状态迁移与复用校验，不提供针对伪造一切输入之恶意控制平面的密码学证明。平台签发的执行溯源被明确视为不支持，需另行使用受信任服务。

数据包内部还有一组精确的编码约束（均有源码校验对应）：

• verification.preflight_results必须是精确、唯一的command+result对象数组；无聚焦预检时为空数组；
• verification.eligible_concurrent_gates必须恰为字符串none（源码直接!= "none"即报错，见 review_protocol.py）；仓库级 lint、typecheck、test、build、examples、integration 门列在verification.deferred_gates；
• 证据工件中恰好一个role: "review-state"（未修改的review_state.pyJSON）、恰好一个role: "complete-diff"（由同一命令的--complete-diff-output生成）、恰好一个role: "repository-status"（未过滤的 porcelain-v1-z状态输出）——源码_evidence_artifacts对三个 role 各强制恰好一个（见 review_protocol.py）；
• review_state对象只含evidence_id（指向 review-state 工件）与精确重验证命令，额外复制指纹或状态字段非法（见 review_protocol.py）；
• repository对象以status_evidence_id命名状态工件，并在exclusions中为任务清单之外的每个变更路径给出具体理由；
• manifests.dependency_map的键必须与组件名完全一致，值为非空数组，元素为pathspec+reason记录且 pathspec 唯一（见_dependency_map，review_protocol.py）；每个 pathspec 必须覆盖能使组件失效的语义、生成表面、钩子或构建/测试配置输入，纯文字或空依赖声明无法支撑后续的 base-advance closure；
• 恰有两个评审员分配，其 ID 组合覆盖每个库存行与每个选定的高风险维度；主专业与高风险专业在裁剪与大小写折叠后不得重叠；每位评审员必须获得每个组件边界与全部三个控制工件（源码reviewer_components != set(components)或控制工件未全覆盖即报错，见 review_protocol.py）。

验证器（validator）的派生与一致性校验包括：从已摘要的 review-state 工件派生指纹；要求仓库base与head与之一致；要求任务/组件清单与其 pathspecs 精确匹配；要求complete_diff_paths与任务工作区精确相等；要求 complete-diff 工件摘要等于其complete_diff_sha256；要求状态工件摘要等于其未过滤状态指纹；要求exclusions精确覆盖任务工作区之外的每一个未过滤变更路径（见 review_protocol.py）。成功时它会报告数据包实际路径、字节大小、数据包与当前账本的 SHA-256、review-state 路径、指纹、组件、库存 ID 与评审员 ID——将该输出复制进派发记录。若数据包超过 12 KiB，必须把packet_overage_reason从"none"替换为决策相关的无法继续拆分理由（源码对超限且理由为哨兵值直接报错，见 review_protocol.py）。

账本状态机：轮次、预算与根原因所有权

账本（ledger）包含：task_id、round_fingerprint、authorized_round_budgets、current_round、remaining_budget、root_causes、contract_evidence_sha256、inventory_sha256。

校验时，任务 ID 与绝对任务全局账本路径必须在每次验证器调用时独立提供；轮次 1 之后还必须提供紧邻前一轮的不可变账本快照及其来自控制平面的 SHA-256 摘要，且两个参数绝不能从被验证的数据包推导；不可变快照必须是独立文件，不能把可变的当前账本当作先前的快照传入（源码通过 FileIdentity 比较强制"先前账本必须与当前账本不同"）。

validate_packet对账本的完整约束（见 review_protocol.py）：

• 数据包、当前账本与先前账本身份必须匹配控制平面参数；
• round_fingerprint必须匹配数据包指纹；
• current_round+remaining_budget必须等于正整数预算历史之和；
• 当前预算历史必须保留先前前缀；当前轮次等于先前轮次（同轮重试）或恰好加一；
• 同轮重试必须保留先前round_fingerprint，且预算历史与先前快照一致；
• 每个先前的规范根及其所有权与摘要绑定必须仍然存在；
• 当前账本文件的 JSON 对象必须与数据包内的账本完全一致。

每个ledger.root_causes条目包含id、status（open/closed）、inventory_ids、contract_evidence_ids。每个根必须拥有至少一个库存 ID，且每个库存 ID 有恰好一个规范根所有者；两个摘要映射必须精确绑定当前拥有的 ID，并与索引工件字节及语义库存行匹配；每个契约证据 ID 必须解析到evidence_artifacts[].id——账本不能以未索引的字符串确立证据权威。实施者拥有规范 ID；评审员复用提供的 ID 或提出NEW:<lowercase-slug>（证据内容不得已被任何规范根或同输出中不同的提案根拥有）；评审员不得铸造重命名的裸 ID，也不得为新提案复用规范库存；只有实施者能将提案提升（promote）进账本。

此外，源码还强制：已关闭根的重开必须有内容全新证据或语义库存（content_new_inventory or content_new_evidence均为空即报错，见 review_protocol.py）；先前根的库存/证据所有权不得回退（regressed）；先前绑定的摘要不得改变。

验证收据：可复用的聚焦检查信用

每个已记账验证收据（verification receipt）包含：整数schema_version: 1、整数exit_status: 0、command、environment、non_mutation_basis，以及精确的before与after对象，每个对象含combined、components、repository三个指纹。未知字段非法；协议意义上 JSON 布尔值不是整数。

收据通过verification.credited_receipts数组以绝对path+sha256摘要加入数据包；packet 预检拒绝：替换、失败的命令、任务或仓库状态漂移、before/after 漂移。独立检查只接受已被验证数据包索引的收据路径，不会把任意同指纹文件当作信用。源码validate_receipt_data还要求收据命令恰好出现在verification.preflight_results中——无关的成功命令没有继承信用的资格（见 review_protocol.py 与 review_protocol.py）。

python scripts/review_protocol.py receipt --packet <packet.json> --receipt <receipt.json> --task-id <task-id> --ledger <ledger.json> --prior-ledger <prior-ledger.json> --prior-ledger-sha256 <sha256>

值得强调的是，聚焦检查信用不等于最终门信用：干净评审通过的指纹仍必须完整通过仓库要求的最终验证堆栈（make lint、make typecheck、make tests-review、make tests等，全部推迟到干净评审之后）。

契约表面库存

给每行一个稳定 ID。每个变更的公共符号、配置字段、事件、序列化字段、线值或文档化行为占一行。

列模板为：

ID | surface | producers/constructors | consumers/forwarding branches/adapters | default/missing/invalid behavior | package exports/generated public surfaces | adjacent docs/examples | caller-visible tests

在kind: "contract"库存对象中编码为：surface、producers、consumers、behavior、exports、adjacent、tests。每个字段必须是非空字符串，仅在显式评审值确为none或not applicable时使用哨兵值。

还必须覆盖当前 diff 之外的相邻表面（adjacent surfaces）：若发现必需的更新缺失，应在冻结评审前将其加入任务清单；但docs/内容若按仓库的文档发布时机（Documentation Release Timing）政策被有意推迟，则例外——推迟的文档在库存与证据中记录为独立定时的工作，不得加入当前任务清单或 findings，也不得阻塞干净评审。该政策在 AGENTS.md 中有明确定义：当特性尚未进入最新已发布版本时，描述该未发布行为的docs/内容应在单独的纯文档 PR 中处理。源码INVENTORY_FIELDS["contract"]与该七字段集合逐字对应（见 review_protocol.py）。

等待边界与权威数据流库存

对于并发、取消、可重入或生命周期状态，使用：

ID | operation | state snapshot | await/blocking point | events/operations possible while suspended | monotonic evidence retained | revalidation | side effects/invariant

编码为kind: "await-boundary"对象的字段：operation、state_snapshot、blocking_point、suspended_events、monotonic_evidence、revalidation、side_effects_invariant。

需要覆盖的支持状态包括：源完成、已知或未知身份的更新活跃操作、挂起期间启动并完成的新操作、被等待动作的失败或取消。若契约依赖"某事件是否曾经发生过"，必须指明单调证据或串行化证明——当前活跃状态不足以证明"从未发生"。

对于协议、安全或持久化，改用：

ID | input/authority | validation | in-memory state | persisted/serialized state | retry/replay | output | exception/log/telemetry exposure | cleanup/revocation

编码为kind: "authority-data-flow"对象的字段：input_authority、validation、in_memory_state、persisted_state、retry_replay、output、exception_exposure、cleanup_revocation。每个 kind 专属字段必须是非空字符串，以便预检在派发前拒绝仅含摘要的行（源码对缺失 kind 字段直接报 "missing contract fields"，见 review_protocol.py）。测试夹具中的INV-2行即authority-data-flow类型的完整示例（输入权威为控制平面的任务 ID 与账本路径，输出为校验摘要等）。

评审员指令：一次只读轮次与精确输出契约

执行约束：评审员在冻结指纹上执行恰好一轮只读评审；上下文不得继承实施者对话（分发器在可用时使用fork_turns: "none"）。流程为：先运行提供的重验证命令并计算合并基；然后检查完整原始 diff、周边源码、测试与提供的参考；验证每个被分配的库存行而不是信任实施者；返回预检报告的 packet SHA-256（使验证器在任何数据包字段或证据描述符变化后拒绝信用）；可以报告专业之外的 blocker。

禁止项：编辑或暂存文件、递归调用评审工作流、派生另一个评审员、运行广泛仓库验证、检查内存、重新发现工作流技能、重跑实施策略、搜索指纹 helper、重新发现发布标签。评审员继承提供的实施范围契约；若契约不一致或留下决策相关的歧义，应把不确定性报告给实施者，而不是发起策略通过。任何必填数据包字段既未填充也未显式标注none/not applicable时，报告缺失字段且不返回可获信用的干净裁决。仅当提供的证据不一致或留下决策相关不确定性时，才允许重新打开主源码或已发布证据——重开不能替代缺失的数据包内容；只运行解决此类不确定性所需的聚焦、非变异探针。

工具预算：约 12 次源码检查工具调用为软预算；当决策相关不确定性需要更多证据时可超支，但必须记录简洁理由；不得为迎合预算而跳过证据或降低评审质量。

输出契约：返回恰好一个JSON 对象，外部不得有任何散文：

{ "verdict": "clean | findings require fixes | complexity reset required | incomplete packet", "reviewed_fingerprints": { "packet": "...", "combined": "...", "components": {"component-name": "..."} }, "checked_inventory_ids": ["..."], "unchecked_inventory_ids": [{"id": "...", "reason": "..."}], "high_risk_dimensions_checked": ["..."], "focused_probes": [{"command": "...", "result": "..."}], "remaining_uncertainty": ["..."], "findings": [ { "priority": "P0 | P1 | P2 | P3", "title": "...", "location": "path:line or symbol", "failure_scenario": "...", "user_consequence": "...", "support_basis": "...", "baseline_patch_evidence": "... | not applicable", "smallest_safe_correction": "...", "root_cause_id": "CANONICAL_ID | NEW:<lowercase-slug>", "root_cause_evidence": { "new_contract_evidence_ids": ["..."], "new_inventory_ids": ["..."] } } ], "sibling_scenario_scan": [{"root_cause_id": "...", "inventory_ids": ["..."], "result": "..."}], "inspection_call_count": 0, "inspection_budget_reason": "none | ..." }

补充规则：

• focused_probes、remaining_uncertainty、findings、sibling_scenario_scan无内容时使用空数组；
• 每个被分配的库存 ID 必须出现在checked_inventory_ids或unchecked_inventory_ids之一；
• 每个 sibling-scenario 扫描必须复用规范根 ID 或同输出中由 finding 提出的NEW:根，且每个扫描库存 ID 必须解析到索引库存行；
• clean裁决要求unchecked_inventory_ids、remaining_uncertainty、findings三个数组全部为空（源码直接强制，见 review_protocol.py）；
• 评审输出、每个 finding、根原因证据、unchecked-inventory 与 sibling-scenario 对象必须使用恰好如上的字段，未知字段非法而非忽略（源码_require_exact_fields对REVIEWER_OUTPUT_FIELDS与FINDING_FIELDS逐字段比对，见 review_protocol.py）；
• 每个focused_probes[].command必须包含实际运行的确切可执行命令；非 shell 工具调用需提供完整工具名与参数；纯文字标签、省略参数、<focused probe>之类占位符不完整、不得换取干净信用；若命令过大，在执行前把探针代码放入索引证据工件，返回其路径、SHA-256 摘要与确切执行命令（源码以PLACEHOLDER_TOKEN正则<(?!\s)...>拒绝占位符，见 review_protocol.py）；
• 每个 finding 复用数据包提供的规范根 ID 或提出NEW:<lowercase-slug>；root_cause_evidence两个数组都必须填充（无新证据时为空数组）；提交的契约证据 ID 必须命名索引的evidence_artifacts[].id，提交的库存 ID 必须命名索引的inventory[].id；规范根的提交 ID 必须是当前账本相对先前不可变快照新增的该根所有权，其他根拥有的库存 ID 不能被重分配为 finding 证据；新提案要求索引证据内容不被任何规范根或同输出不同提案根拥有，且其库存数组在实施者提升前保持为空；
• 若评审员发现冻结数据包中缺失的证据，需将该证据加入数据包并摘要、在同一指纹轮次重跑 packet 预检，然后重新提交输出；
• 裸clean或通用检查清单不完整，不换取干净信用；畸形 JSON 对象或缺失必填字段同样不完整。

实施者使用以下命令验证每个已保存响应后才接受 findings 或干净信用：

python scripts/review_protocol.py reviewer-output --packet <packet.json> --reviewer <reviewer-id> --output <output.json> --task-id <task-id> --ledger <ledger.json> --prior-ledger <prior-ledger.json> --prior-ledger-sha256 <sha256>

validate_reviewer_output的实现要点（见 review_protocol.py）：先整体validate_packet，再重验证控制文件；reviewed_fingerprints必须与 packet 摘要、组合指纹、组件指纹精确相等；checked | unchecked集合必须等于该评审员的分配库存集合且互不重叠；high_risk_dimensions_checked必须等于分配的维度；"findings require fixes / complexity reset required" 裁决必须至少携带一个 finding；检查计数超过 12 必须提供非哨兵inspection_budget_reason；sibling 扫描的根必须在规范根或本次输出提案根集合内。

专业分配与双人互补

简报末尾的专业分配模板包含：主维度（Primary dimensions）、必需库存行（Required inventory rows）、预期组件边界（Expected component boundaries）、预期充分的证据项（Evidence items expected to be sufficient）、互补评审员分配（Complementary reviewer assignment, if any）、机器可读数据包中的评审员 ID、规范根原因 ID 与关闭状态。

机器可读侧的双人约束（validate_packet中）为：reviewer_assignments必须恰好两个评审员；两位的主专业（primary_dimensions）在strip().casefold()规范化后不得重叠；各自的高风险专业（high_risk_dimensions）同样不得重叠；每位评审员必须拥有非空库存与主专业；所有分配的库存并集必须恰好等于数据包库存全集，所有分配的高风险维度并集必须恰好等于selected_high_risk_dimensions（见 review_protocol.py）。这与 high-risk-review.md 第 12 步"同一指纹上并发派发两位独立评审员、互补高风险专长、每位都看到完整原始 diff"的要求一一对应。

与最终验证堆栈的关系：步骤 20 的两个窄例外

简报明确：由 high-risk-review.md 第 20 步定义的已验证最终门类型擦除闭包（type-erasure closure）与基推进闭包（base-advance closure）不产生指纹轮次、评审员数据包或评审员分配。

• 类型擦除闭包：在任务全局账本与最终验证证据中记录确切 delta、前后指纹、最终门失败、运行时身份依据（typing.cast原样返回值）与聚焦验证；
• 基推进闭包：记录新旧 base、head、指纹、逐字节相同的任务与组件工作区证据、相同的已跟踪 diff 摘要、完整上游变更路径列表与 diff 摘要、确切依赖输入 pathspecs、聚焦集成检查。

若适用例外的每个条件未被机械确立，则必须准备常规 delta 评审数据包（fall through）。两个闭包都不授予最终验证信用：结果指纹上仍须重跑完整的最终验证堆栈。这一设计让"干净的评审证据"能够安全延续到仅typing.cast包装或上游基推进这类窄变更，同时把评审轮次与预算严格绑定在真正的语义变化上。

测试与实现佐证

• test_review_protocol.py（1832 行）以 unittest 形式覆盖validate_packet、validate_reviewer_output、validate_receipt_data、_validate_credited_receipt与_workspace_entries，其setUp中构造的完整 packet 夹具（task、scope_contract、repository、ledger、manifests、review_state、verification、evidence_artifacts、inventory、reviewer_assignments）是理解字段形状的最佳参考；test_review_state.py覆盖指纹与工作区条目语义；
• review_state.py 是全部指纹的来源：_content_fingerprint（base + workspace 的规范化 JSON SHA-256）、_repository_fingerprint（组合内容指纹 + head + status/tracked-diff/complete-diff 摘要 + 未过滤状态与未过滤内容指纹）、workspace 五类条目（file/symlink/gitlink/directory/missing）的精确字段集；
• review_protocol.py 中PACKET_SOFT_LIMIT_BYTES = 12 * 1024、SENTINELS = {"none", "not applicable"}、REQUIRED_PACKET_TEXT（20 个必填点路径）、INVENTORY_FIELDS三字典、_read_unchanged/_revalidate_control_files共同构成"简报每一条规则都有代码落点"的可审计闭环；
• 仓库 AGENTS.md 将本技能授权为运行时代码、测试、示例、构建/测试行为与行为影响文档的最终评审入口，并规定计划、调查与纯报告类任务不启动本工作流。

小结

openai-agents-python 的implementation-final-review技能通过 reviewer-brief.md 定义了一套罕见的、可机器验证的独立评审协议：以确定性内容指纹绑定每一轮、以任务全局账本承载预算与根原因所有权、以严格 JSON schema 约束数据包与评审输出、以文件身份与摘要重读防御 TOCTOU、以三类覆盖库存（契约表面 / 等待边界 / 权威数据流）保证评审的机械完整性。对于任何需要在多代理工作流 SDK 上维护发布兼容性与安全边界的高风险变更，这套协议提供了从"冻结快照"到"双人干净评审"再到"最终验证堆栈"的完整证据链。理解它，就等于掌握了该仓库最高严格度变更门禁的完整心智模型与全部落地命令。

【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python