01
背景与个人贡献
源于华为实习中的代码检视工作。这里展示的是交付后的个人整理／重构版：以 Codex 原生 Skill 编排 Agent，以 Python 执行确定性校验。它不是独立运行的大模型服务，也不等同于原实习交付版本。
- 设计 Reviewer、Adversary、Synthesizer 的职责边界与维度路由，控制并行审查范围。
- 组织固定版本的代码上下文，绑定任务身份、角色回执与候选发现。
- 实现精确行锚点、Defect Proof、完整性校验与报告／发布准入规则。
02
系统流程
- 01上下文快照
固定版本与范围
- 02预扫描与路由
分配规则和职责
- 03并行审查与对抗
候选发现、挑战条件
- 04调用链深度检视
可选的工作区分析
- 05事实综合
证明与完整性校验
- 06受控输出与反馈
发布门控、经验回流
03
设计取舍
先固定审查对象，再并行推理
审查期间代码可能继续变化。快照固定版本与范围：PR／diff 模式绑定精确新增行，全仓模式绑定快照纳入范围的当前行。快照缺失、过期或不完整时，不允许直接发布。
角色完成，需要可核对的回执
任务分配记录绑定实际执行者、任务和修订版本，捕获的角色输出再接受完整性校验。模型写下“已经检查”，不等于对应角色确实完成了指定任务。
不确定的发现，不自动变成结论
对抗角色挑战触发条件，事实综合阶段检查缺陷证明、去重并校准严重度。证据不充分的结果停留在报告或审计层，不越过发布门控；GitHub 提交默认 dry-run。
04
离线契约示例
下面是现有测试中的人工构造候选，用于验证定位准入规则；不是模型发现的真实漏洞，也未经过完整 Defect Proof 或发布流程。
通过：候选与允许的行锚点一致
- 输入：候选 F1，a.py 第 1 行，规则 PY-SEC-001，置信度 8。
- 约束：允许文件 a.py，允许的精确新增行锚点为 {1}。
- 校验：检查必填字段、规则绑定、文件范围与行锚点。
validate_finding → true，仅表示通过候选结构与范围检查。
拒绝：候选引用范围外的行号
- 对照输入：保留同一候选的其他字段，只把行号改为第 2 行。
- 约束不变：允许的精确新增行锚点仍为 {1}。
- 校验：第 2 行不在当前快照允许的位置中。
validate_finding → false，原因：行锚点不匹配。
05
验证与下一步
当前验证范围
- 2026.09.05：22 项离线测试通过。覆盖快照、角色回执、候选准入、证明与发布门控等契约。
- 上面的对照来自 IntegrityAdmissionTests.test_admission_exact_anchor_rules_proof_and_verdicts。
- 这些检查使用本地样例与模拟接口，不代表真实多 Agent 端到端运行、线上缺陷检出率或远程发布已验证。
下一步
- 补齐对应版本的真实运行报告，独立评估有效发现、误报与遗漏。
- 保存输入版本、人工判定口径和完整执行记录，再比较质量与耗时。
继续读这项工作的技术笔记
阅读相关笔记