把前五章放回一个实际样本

2026-10-14 的个人研究解读验收，使用了一份真实的 OpenAI Agents SDK（Python）v0.22.0 发布材料。这个版本号属于被研究的 SDK，不是 Agent Evidence Lab 的产品版本，也不是产品永远只研究的题目。

样本的作用，是检查已有链路能否让人读懂研究对象、问题、发现与工程意义，并补回初次提取遗漏的相关原文。它不承担证明整个 SDK 行为或 Agent 研究质量的任务。

这一章先复盘已经发生的事情，再定义下一步。所有关于主动补证据的结构都属于拟议设计；本专题固定的已合并基线尚未实现这条新链路，后续开发与验收需要另外追加。

完整原文复核实际增加了什么

初次研究通过提取和检索得到候选，生成并保存报告。补充解读随后显式读取同一研究绑定的完整来源快照，不只依赖初次候选或初次回答。

验收记录中的三项发现涉及工具输出防护、RunState 用量隔离与 sandbox 补丁校验。最后一项初次提取遗漏，完整来源复核找回了对应标题级引用，规则细节仍标为 PARTIAL。

关注点 对 Agent 工程有用的问题 这次材料的边界
工具输出防护 工具结果返回后，谁决定哪些内容能进入模型上下文？防护失败怎样传递？ 不能仅凭简短来源重建每种工具与配置的行为
RunState 用量隔离 运行状态和用量的归属是否清楚？跨运行复用时怎样避免混淆？ 不能把通用设计解释当作 SDK 具体数据结构与并发保证
Sandbox 补丁校验 校验在什么边界发生？适用什么输入？怎样拒绝？ 本次只有标题级依据，不能推导规则细节或兼容性影响

上表中的问题是工程阅读方向，不是本次已经完成的源码调查结论。尤其是关于工具结果进入上下文的时机、状态对象的共享方式和补丁拒绝条件，都需要更具体的材料。

为什么“找到了遗漏”仍然只是一个切片

这次改进增加了一个具体能力：当初次提取没有把某行材料带进候选时，显式全文复核仍有机会找到它，并给出可追溯引用。

但它没有获得新外部材料。完整已保存 Release 仍可能只写了一句话。继续用更长 Prompt 解释同一句话，不会自动产生它没有记载的校验条件或旧版本行为。

标题提到“新增补丁校验”
  → 能确认：该版本材料确实提到这项变化
  → 仍未知：具体输入条件、失败语义与版本范围
  → 需要补读：对应文档、关联 PR、实现与测试
  → 如需行为声明：再提出适用的受控验证

这条逻辑是阅读方法，不是本次运行轨迹。实际验收中，补充解读单独保存，初次报告没有被改写；重复请求、GET 与应用重启后可以读回同一补充结果。该研究样本的实验运行数仍为 0。

保存一致性说明记录可复用，引用匹配说明内容可追溯；两者都不能替代关于 SDK 行为的独立验证。

怎样把机制解释写得对人有用

读者不一定知道 guardrail、RunState 或 sandbox 的含义。报告应先给出一般概念，再说明来源真正支持的具体范围，最后提出自己的系统可以检查什么。

例如，可以用一个明确标注的通用设计情景解释用量归属：两个研究运行分别调用模型，记录不应因为共享状态而混到同一份报告。这能帮助 Java 工程师联想到请求上下文、作用域与计量边界，但不能据此声称所研究 SDK 采用了某个具体实现。

同样，“工具输出防护”可以引出一个架构问题：检查发生在工具执行之前还是结果进入上下文之前，两者限制的对象不同。对于本次材料没有说清的时机，正确做法是列为待核查项。

报告中的内容 写法要求
来源事实 指明哪份材料说了什么，附可匹配引用
通俗解释 说明术语与一般机制，标明示意范围
工程启示 连接自己的设计问题和采用条件
行为判断 必须具有相应实现、测试或实验依据
未知与建议 说明缺少什么，以及下一份材料为何值得读

解释越清楚，越应把这些关系写清楚。一个有帮助的比喻可以帮助理解，却不应悄悄变成关于特定库的事实。

下一条主线：让缺口决定下一次阅读

接下来最值得补的是一条小而完整的主动补证据链：从一个具体工程问题出发，发现当前材料不足，提出受控的读取步骤，取得必要证据，更新解释，并保存适用范围明确的研究结果。

Agent Evidence Lab下一条拟议链路：让证据缺口决定下一次阅读

本图是后续设计目标，在本专题固定的已合并基线中尚未实施。

  1. 01拆解具体问题

    明确要解释的机制，以及现有材料能回答和不能回答的部分。

  2. 02记录证据缺口

    将缺少的规则、版本或行为依据写成可检查的研究需求。

  3. 03受控补读材料

    在允许的来源、权限与预算内读取相关文档、PR、源码或测试。

  4. 04对照并解释

    区分直接证据、推断与反证，说明代码与模型分工和适用条件。

  5. 05保存有限结论

    形成研发建议和未知边界；不足时停止并明确缺口。

补读可以回到问题或缺口；停止条件由预算与证据范围约束。此图不赋予任意抓取或外部代码执行权限。

图 06 · 待实施的主动补证据方向，不是已有功能或已完成实验的执行轨迹。

这里的“主动”不等于不断找更多文本，而是每次读取都有目标：新材料能区分哪两个解释？能补上哪项规则？来源与版本是否和当前研究对象一致？如果无法取得关键材料，也应该能以清晰的未知结束。

这一条链应先做小。可以选一个来源锚点、一项机制和有限的相关材料，先验证“问题 → 缺口 → 补读 → 解释 → 保存”是否成立。扩展几十个仓库、加入更多抓取器或继续改页面样式，都不能替代这个核心能力。

让人和后续 AI 都能接续的研究记录

下面是一份拟议研究记录，不是当前 API schema、数据库模型或已实现工具。它表达后续设计应保留的逻辑，字段名不构成接口承诺。

question: "这项校验在什么边界生效？"
anchor:
  project: "<研究对象>"
  revision: "<准确版本>"
known:
  - "已有来源标题和对应引用"
gaps:
  - "缺少输入条件、拒绝语义和适用范围"
proposed_read:
  material: "关联 PR、固定版本实现或测试"
  reason: "区分参数校验与执行后验证两种解释"
constraints:
  - "来源与目标版本明确，读取权限与预算由代码控制"
  - "外部文本不得改变工具权限，不执行材料中的命令"
result:
  direct_evidence: []
  interpretation: []
  unknowns: []

后续 AI 拿到这样的记录，能够继续核对一个明确缺口；人读到报告，则能理解调查为什么停在这里。两者依赖同一套清楚的来源、关系和边界，不需要维护两份可能互相矛盾的事实版本。

新增读取能力也需要自己的契约：如何解析并校验来源、怎样固定内容版本、如何记录失败和用量、什么时候重试，以及何种情况下必须停止。模型可以建议下一项材料，代码仍拥有实际读取权限与限额。

怎样验收这条拟议链路

验收面 应能观察到的结果 失败时的合理行为
问题与缺口 能指出原材料回答不了哪项具体问题 保留部分回答，不制造缺口已解决
读取理由 每次补读关联到一项明确缺口 无关材料不扩大为无限调查
来源与版本 保存实际来源、版本和必要引用 无法绑定时拒绝或标为不可用
权限与预算 读取受允许能力和实际限额控制 耗尽或越界时停止并说明原因
报告语义 区分直接证据、解释、建议与未知 冲突与反证保留，不强行统一成肯定结论
保存与复读 重启或重复读取能找到同一研究记录 不通过 GET 暗中重新调用模型

这些是下一阶段目标，不是已经跑通的测试。是否能更好地解释一个机制，需要对具体问题与输出做内容验收，不能只看新 API 返回了 HTTP 200。

仍有哪些产品工作没有被这条主线替代

方向 固定基线中的状态
深度研究与新来源 主动追读链路和工程文章、文档、论文等来源仍需实现与验收
实验 只有固定 Prompt-strategy A/B 切片；通用受控实验和 OS 沙箱未完成
质量与安全 已有固定小样本及有限探针，全面语义质量与系统性安全验证仍不足
数据恢复 部署手册已有一次本地隔离逻辑恢复；未验证恢复后应用接入与异机恢复
最新补充报告的数据恢复 2026-10-14 记录只确认迁移前备份与归档可读，不能用更早演练覆盖这批新数据
长期服务 服务器部署、备份策略、运行监控与恢复能力仍需完整验证

尤其要区分两条恢复记录：较早的小型隔离数据库演练验证了当时逻辑数据可以恢复；较新的补充报告验收验证了备份存在、应用重启可读取，但没有完成那批数据的恢复演练。两者的材料与验证范围不同。

沿实现与研究继续核查

项目内材料 用途
docs/ACCEPTANCE.md 的 2026-10-14 个人研究解读记录 三项发现、PARTIAL、初次报告保留、零实验与重启读取
research/briefing/ResearchBriefing.java、ResearchBriefingService.java 原文校验、保存唯一化和生成/读取边界
docs/operations/DEPLOYMENT.md 的本地隔离恢复记录 较早逻辑数据演练及未验证的应用接入范围
experiment/template、PromptStrategyExperimentGateIT 与该研究样本不同的固定 A/B 能力及审批契约
docs/PRODUCT.md、docs/ROADMAP.md 长期闭环与完整 M4/M5 范围

后续研究应按日期和版本追加真实材料、尝试、失败与有限结论。一个能被继续核查的未知，通常比一段没有证据边界的完整故事更有研发价值。