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

发布时间:2026/9/12 11:25:17
openai-agents-python 实现最终评审协议:独立评审员简报(reviewer-brief)与指纹轮次账本全解析 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结构、三类校验 CLIpacket/receipt/reviewer-output、账本轮次与预算状态机、三类覆盖库存contract / await-boundary / authority-data-flow的填写规范以及评审员 JSON 输出契约与 clean 判定的精确条件。评审简报在整个实施最终评审流程中的位置在 SKILL.md 定义的评审分级中变更按语义影响被划分为三个等级等级边界所需评审Lightweight轻量仅拼写、注释、格式不改变执行、公共契约、测试预期、配置或文档含义自查完整 diff 并运行适用的聚焦检查独立评审可选Ordinary普通既有契约内的局部行为变更、常规测试新增、无高风险边界的行为文档一位独立评审员使用全新上下文High risk高风险安全、凭据、敏感数据处理、信任、持久化/恢复、耐久状态、并发/取消/共享生命周期所有权、已发布兼容性、包/运行时导出、协议所有权、跨提供方生命周期或任何出现已验证 P0/P1 的评审周期两位具备互补专长的独立评审员遵循 high-risk-review.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_keysTrue、紧凑分隔符序列化后做 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.pyledger.round_fingerprint必须等于数据包指纹即review_state.content_fingerprintledger.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(strictTrue)、通过_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.pyvalidate_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_bytesjson.loads传入object_pairs_hookunique_object遇到重复键抛ProtocolError、parse_constantreject_constant拒绝三个非有限常量、parse_floatfinite_floatmath.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.pyassume-unchanged路径、已物化的skip-worktree路径、unmerged存在未解决的合并阶段_require_clean_submodules要求每个初始化子模块含嵌套HEAD 与父索引记录一致、工作树干净并拒绝循环或别名化的子模块工作树图见 review_state.py。工作区条目类型检查则落实Git 无法表示成有限 blob 的条目非法_workspace_entry对非符号链接、非文件、非目录、非 gitlink 且存在的路径报 Unsupported workspace file type见 review_state.py。快照数据包模板一份共享主体多个评审员简报要求每个指纹轮次准备一个自包含、事实性的快照数据包并遵循三条纪律填满每个字段或明确标注none/not applicable禁止派发不完整的数据包只填写一次为每位评审员逐字节复用共享主体仅最终的专业分配specialty assignment不同控制平面简报保持约 12 KB源码常量PACKET_SOFT_LIMIT_BYTES 12 * 1024见 review_protocol.py更大证据存入索引文件并按确切路径与 SHA-256 摘要引用不得为迎合软目标而省略决策相关证据。数据包不得包含实施者结论、疑似 bug、先前发现或计划中的修复——评审员的判断必须来自事实性证据。共享证据Shared evidence清单共 17 项构成每个数据包的标准内容原始需求Original requirement实施范围契约Implementation scope contract必需行为、兼容性要求、有意不支持的用例与失败行为、受支持的替代方案或none预期目标Intended target已解析的合并基Resolved merge baseHEAD相关时的最新发布边界Latest release boundary风险等级与理由高风险需将task.risk_tier编码为elevated任务全局账本路径、任务身份、当前轮次与剩余授权预算规范根原因账本ID | open/closed | inventory IDs | contract evidence IDs规范任务清单确切的规范化文件条目即使被忽略规则匹配也保持权威目录与 glob 条目不会提升被忽略的文件组件清单Component manifests语义组件依赖映射component | exact base pathspecs | invalidation reason组合、组件与仓库指纹精确的指纹重验证命令未过滤的仓库状态工件与任务清单之外的显式排除项使用review_state.py --complete-diff-output的完整三点 diff 命令以确保任务自有的未跟踪文件被包含索引证据清单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必须是精确、唯一的commandresult对象数组无聚焦预检时为空数组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.pyreview_state对象只含evidence_id指向 review-state 工件与精确重验证命令额外复制指纹或状态字段非法见 review_protocol.pyrepository对象以status_evidence_id命名状态工件并在exclusions中为任务清单之外的每个变更路径给出具体理由manifests.dependency_map的键必须与组件名完全一致值为非空数组元素为pathspecreason记录且 pathspec 唯一见_dependency_mapreview_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_roundremaining_budget必须等于正整数预算历史之和当前预算历史必须保留先前前缀当前轮次等于先前轮次同轮重试或恰好加一同轮重试必须保留先前round_fingerprint且预算历史与先前快照一致每个先前的规范根及其所有权与摘要绑定必须仍然存在当前账本文件的 JSON 对象必须与数据包内的账本完全一致。每个ledger.root_causes条目包含id、statusopen/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数组以绝对pathsha256摘要加入数据包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-slugroot_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 sha256validate_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_reasonsibling 扫描的根必须在规范根或本次输出提案根集合内。专业分配与双人互补简报末尾的专业分配模板包含主维度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.py1832 行以 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_fingerprintbase 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_TEXT20 个必填点路径、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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询