资料整理已经可以通过工具读取、按字段提取并生成报告，接下来的问题是执行过程：读取第三份资料时发生超时，前两份是否需要重读；提取结果不符合约定，报告是否还应生成；新对话继续任务时，怎样知道哪些文件属于当前版本。自动化需要把这些判断落实为阶段前提、保存状态和停止条件，才能减少人工重复安排步骤的负担。
本文是“大模型应用方法与实践”系列的第八篇专题，接续工具调用与 MCP。本篇组织读取—提取—核验—生成的执行过程，重点讲步骤依赖、检查点、有限重试、恢复和人工确认。资料与字段语义沿用第五至七篇；复杂框架、服务部署和系统评估分别留给后续方向与第九篇。
实践条件：能够创建文件、使用终端和阅读简单 JSON。配套程序需要 Python 3.10+，只使用标准库，无需 API 密钥、MCP 连接或调度服务。可先用普通聊天完成手动提取，再在具备文件和终端能力的宿主中观察单 Agent 如何执行同一任务。官方资料核对日期为 2026 年 10 月 5 日。产品说明与实验记录为教学模拟；故障由程序主动注入，程序运行证据与模型自主执行记录分别保存。
1. 工作流与动态决策
固定步骤与条件分支
工作流预先规定步骤及其依赖。资料读取成功才允许提取，字段检查通过才允许生成待审稿，人工核对后才进行本次本地交付。流程可以包含条件分支，例如“还有未完成来源则继续读取”“候选不合格则停止并等待新版本”。有分支的程序仍可以是固定工作流，不必因此引入模型。
Agent 则在任务约束内，根据当前状态与实际返回选择行动。例如发现许可证没有依据后补读指定来源，或者判断工具返回的片段不足以支持冲突处理，再读取上下文。模型选择出的下一步仍需经过宿主与工具的参数、范围和执行检查，不能仅因计划里写了一个动作就视为已执行。
| 组织方式 | 本例中的安排 | 需要保留的证据 |
|---|---|---|
| 人工阶段流程 | 读者提交提取任务、保存结果、执行核验 | 每阶段输入、原输出和检查结论 |
| 固定工作流 | 程序管理读取顺序、状态和交付前提 | 状态、日志、文件与摘要 |
| 单 Agent 与工作流 | 模型解释来源并形成候选，程序控制边界 | 模型真实调用、候选及程序检查 |
本篇采用第三种分工的最小形式：程序提供已保存的证据与明确状态，提取任务可以交给一个 Agent，也可以由普通聊天返回文本。程序本身不会调用模型，不会选择检索词，也不会解决来源冲突。这样可以分别观察内容判断和执行控制的结果。
计划与实际状态
计划说明准备做什么，状态说明什么已经完成。两者可以关联，但不能互相替代。“已计划生成报告”不应记为生成成功；模型说“已经恢复”也需要实际文件、调用记录或状态变化支持。
最小计划应列明阶段、输入、产物、前提、允许动作和停止条件。例如，提取阶段需要完整证据包和字段契约，产物是一个候选 JSON；缺少必要来源就不能假设单位，且不能进入交付。计划不需要展开模型的内部推理，只需给出可检查的依据与行动安排。
配套 08-01-plan.txt 只要求读取现有运行并形成恢复计划。它和后续执行任务分开，便于核对模型是否把失败阶段、已完成阶段和未获授权的动作混在一起。
多 Agent 的适用条件
当不同阶段需要明显不同的工具、权限或专业能力，且各自输入输出能够清楚划分时，可以考虑多个 Agent。把一个 12 条记录的提取任务机械拆成三个“专家”，则会增加任务传递、上下文重复、协调和验收成本；多个模型认可同一结论，也不等于取得了独立证据。
OpenAI Agents SDK 区分控制权转交的 handoff 与由主 Agent 调用专门能力的 agents as tools；官方建议先从一个 Agent 开始，只有分工确实改善能力或约束隔离等方面时再增加。这里仅用于理解组织方式，本篇不安装或运行多 Agent 框架。编排与任务转交
2. 输入输出与阶段依赖
固定资料与字段契约
本例继续整理 LogBrief 1.2、BatchTrace 0.9、RunSheet 2.0 的三个属性，以及三条模拟耗时，共 12 条记录。输入包含 S1、S2、S3、S5、P5、E5，保留第五篇的 D5-v1：
- BatchTrace 的同版本文件上限存在冲突，不能自行选择 8 或 4。
- 未提供的许可证和输入保护信息保留缺失，不能补成常见值。
- P5 定义原始耗时单位和破折号；RUN-02 的未记录与 RUN-03 的已知零值分别处理。
- 三个最终文件来自同一主记录，不扩展为性能排名或其他属性。
完整资料和契约随第八篇练习包提供，不要求先运行前篇项目。实际 JSON 使用 record_id、tool、version、field、value、unit、state、source_refs、note；state 是 known、missing、conflict。不要把早期规划大纲中的抽象字段名带入当前运行。
阶段前提与产物
固定输入与运行版本
↓
六份来源读取检查点 → evidence.txt
↓
模型或读者提取 → inbox/candidate-v1.json
↓
结构与定位存在检查 → verify.json
↓
三个待审文件 → waiting_review
↓ 人工核对来源含义与本次摘要
三个本地交付文件 → completed
| 阶段 | 必要前提 | 保存产物 | 进入下一阶段的条件 |
|---|---|---|---|
| 读取 | 固定版本，累计次数未耗尽 | 每份来源缓存、证据包 | 六份必要来源齐全 |
| 提取 | 证据包与 12 条契约 | 原始候选和规范化主记录 | 候选能够通过结构检查 |
| 核验 | 完整候选与原文定位 | 程序核验记录 | 字段、类型、集合与定位存在 |
| 待审 | 程序结构通过 | JSON、TSV、Markdown | 人工确认语义和具体版本 |
| 交付 | 当前摘要匹配，确认有效 | output 三文件、确认记录 | 写入实际完成 |
阶段产物同时是下游输入。报告生成不能拿另一对话里的旧表格替代本次已接受候选；恢复也不能把“某个文件存在”直接解释为“它符合当前输入”。本例用固定输入与代码摘要、产物摘要和运行标识建立关联。
结构核验与事实核验
沿用第五篇的检查器，程序能发现重复标识、缺少记录、类型错误、缺失值契约错误、不存在的来源定位和文件之间不一致。这些检查具有确定规则，适合程序执行。
如果 RS-LICENSE 被写成 MIT / known，且引用一个实际存在的 S3 行，结构检查仍可能通过。标签存在只说明能定位到这行，不能证明这行支持 MIT。因此 verify.json 记录的是 structure_passed 和 facts: pending_human_review，流程先停在待审稿，由读者核对原文含义。人工确认另存于状态记录，不把程序检查结果改写成自动事实证明。
资料本来包含的缺失或冲突可以按契约完成交付；它们不是工具失败。相反，必要来源没有取得时，应报告未完成范围，不能补造证据让记录看似完整。前篇解释的资料中指令干扰同样适用：来源内容不能更改字段契约或授权范围。
3. 状态、运行标识与检查点
运行目录与版本关联
run_id 标识一次具有固定输入和执行版本的运行。本例使用 demo-01，所有新文件在 runs/demo-01/ 内生成；原资料、其他运行和博客源码不作为输出位置。目录已经存在时，start 会拒绝初始化覆盖。
运行中的部分目录如下。它是预期结构，各文件在相应阶段成功后才出现，不是下载包已经带有的结果：
runs/demo-01/
├── state.json # 当前阶段、累计次数、输入与产物摘要
├── events.jsonl # 追加的真实程序事件
├── read/ # S1、S2、S3、S5、P5、E5 原文检查点
├── evidence.txt # 六份已完成来源的合并文本
├── inbox/ # 读者或模型保存的新候选
├── extract/ # 接受的原始候选与规范化记录
├── verify.json # 程序检查范围
├── preview/ # 三个待审文件
└── output/ # 本次确认后的三个交付文件
同一次失败恢复继续使用原 run_id；输入、脚本或已接受候选需要修改时，另开运行。两个候选版本的语义不同，不能用旧版的确认摘要交付新版报告。
阶段状态与完成范围
| 状态 | 本例含义 | 下一步 |
|---|---|---|
running |
正在安排当前阶段 | 查看实际调用和结果 |
failed |
来源读取暂时失败，仍有累计次数 | 检查错误后有限恢复 |
waiting_input |
六份来源齐全，等待候选 | 提取并保存新文件 |
blocked |
契约错误、累计耗尽等前提不满足 | 修订候选或处理具体原因 |
waiting_review |
待审稿已生成，事实仍待人工核对 | 查看文件后确认或修订 |
completed |
当前版本已确认并完成本地交付 | 验收三文件与实际范围 |
本例的状态名是教学程序约定，不是通用 Agent 标准。其他宿主可能用不同事件与状态。OpenAI Agents SDK 也将最终输出、历史、待确认动作和可恢复状态分别提供；一个为人工检查而暂停的结果可以没有最终答案，需要保存相应状态后继续。结果与状态
检查点与实际文件
检查点至少需要记录已完成阶段、输入版本、产物位置、核验结果和未完成项。本例每读完一份来源，就保存原文与摘要，并把该来源记为 done。恢复时先复核输入和执行代码，再核对已登记产物；通过后才跳过这些来源。
状态是可更新的索引，事件日志按行追加，来源与阶段产物只创建。程序先写状态临时文件、落盘后替换索引，减少普通中断留下半个 JSON 的机会。但本例没有多机事务或完整断电保障，硬退出可能留下锁或未登记文件。
若一个尚未登记的文件已经存在，程序只在它与应生成内容完全一致时复用；内容不同或部分写入则停止并保留现场。已登记文件摘要变化也会停止，不通过覆盖来掩盖问题。摘要用于发现变化，不是可信身份、数字签名或权限隔离。
4. 故障注入与恢复实践
独立环境与首次读取
下载练习包，解压到博客仓库和真实资料目录之外的新目录，进入 08-agent-workflow/。包中没有答案、候选或已完成运行；逐文件职责与 Bash 等价路径见项目 README。
初始状态：当前目录是新解压项目，Python 3.10+ 可用，没有 runs/demo-01/。以下 PowerShell 命令顺序执行；不用安装第三方库，也不用修改用户级配置。
python workflow.py start demo-01 --fault S3:once
操作目的：观察部分成功之后的失败，验证前两份来源能否保留。程序依次缓存 S1、S2；到 S3 第一次调用时主动抛出超时，尚未写入 S3 缓存。
预期结果：退出码为 1，状态为 failed，阶段为 read；S1/S2 为 done、累计各 1 次，S3 为 failed、累计 1 次，后续来源为 pending。没有候选、待审稿或交付报告。这个错误是读取接口的教学注入，没有实际断开 MCP、阻断网络或制造磁盘故障。
查看 state.json 与 events.jsonl，并记录 S1/S2 文件摘要和修改时间。可提交计划任务，观察模型是否准确解释当前状态；计划任务不执行恢复。文件存在、状态标记和日志事件应能互相对应，缺少证据的项目保留未知。
有限重试与来源恢复
在同一项目继续执行：
python workflow.py resume demo-01
python workflow.py status demo-01
恢复前会核对原输入、代码和检查点摘要。S1/S2 通过后直接复用，从 S3 第二次调用继续，随后读取 S5、P5、E5，形成 evidence.txt。预期状态为 waiting_input、阶段为 extract；S3 累计 2 次，其余来源各 1 次，S1/S2 文件没有改写。
具备终端能力的单 Agent 也可执行恢复任务。该任务先检查实际状态，只有教学超时且次数仍可用时才继续；读完后停在 waiting_input。模型若没有工具，只能返回计划，不能填成实际恢复成功。
每份来源的累计上限固定为 3 次，跨命令保存。--read-attempts 只规定本次命令最多安排几次调用，默认 1，不重置累计计数。第一次失败后的重试等待为 0.2 秒，再次为 0.4 秒，是便于练习的退避值。
下面是两个独立实验，分别新建运行，不能替代原 demo-01 的恢复记录：
# 同一个命令中安排最多两次读取，第一次注入失败后自动重试。
python workflow.py start retry-01 --fault S3:once --read-attempts 2
# 每次 S3 读取都失败，累计第三次后停止。
python workflow.py start stop-01 --fault S3:always --read-attempts 3
python workflow.py resume stop-01
retry-01 预期完成读取后等待候选；stop-01 预期 blocked，后续 resume 不再调用 S3。这样可以检查自动重试、人工重新启动和总次数限制的关系。
错误分类与重试范围
| 情况 | 处理方式 | 原因 |
|---|---|---|
| 已知临时超时 | 检查结果后退避，限制次数 | 稍后可能恢复 |
| 来源不存在 | 核对标识或补充资料 | 重复请求不会生成证据 |
| 参数或 JSON 错误 | 修正输入，另存候选版本 | 错误内容仍然错误 |
| 权限或凭据缺失 | 报告具体缺口 | 重试不创造授权 |
| 输入或产物变化 | 停止复用，检查版本 | 旧检查点前提失效 |
| 累计预算耗尽 | 停止并报告 | 不能无限循环 |
| 外部写入结果未知 | 查询已有结果再判断 | 超时可能发生在成功之后 |
本地程序只自动重试明确注入的 TimeoutError。其他文件、参数和摘要错误会停止，不把所有异常归为临时问题。在线接口的重试等待还要尊重服务要求、截止时间和限额。OpenAI 官方恢复指引同样要求先检查已有结果与副作用，再做有限重试；断开的响应流并不能证明最终执行失败。错误与恢复
重复执行与幂等性
幂等性关注相同操作重复执行后的可观察结果是否保持一致。本例再次恢复已完成阶段不会重复追加主记录；再次以同一摘要确认已完成运行不会改写 output。它依赖本地状态、内容比较和单进程锁，是本例范围内的重复执行控制。
如果一个外部发送接口已经成功，但客户端收到超时，仅保留本地检查点不能保证再次发送不会重复。需要服务端支持的去重标识、状态查询或人工核对，且同一标识只能对应同一动作内容。不能把本例的文件摘要当成所有工具都支持的幂等键，也不能声称实现了外部动作“恰好一次”。
5. 提取、核验与本地交付
候选提取与单 Agent 任务
前置状态：demo-01 已完成六份读取，status 检查通过，状态为 waiting_input。提交完整提取任务，只允许读取当前证据、契约和相关执行说明，创建一个新候选文件并执行导入。
模型需要处理的内容与前文相同，但输入现在来自本次已完成的来源检查点。提取后保存为 runs/demo-01/inbox/candidate-v1.json。具备文件工具的宿主可实际创建；普通聊天读者另存完整 JSON 文本，UTF-8 无 BOM，不包含 Markdown 围栏。已有同名文件就停止，不覆盖第一版。
python workflow.py resume demo-01 --candidate inbox/candidate-v1.json
程序先做结构检查。缺少记录、重复标识或值类型不合格会得到 blocked，不创建待审稿。读者保留失败候选，在 inbox 另存修订版本再导入。通过后保存原始候选与规范化记录、核验说明，再从同一主记录生成三个 preview 文件，停在 waiting_review。
已经接受的候选不在原运行中修改。人工发现事实错误时，保留当前待审稿和问题记录，用新 run_id 重做修订；这一限制便于核对哪个版本曾通过哪些检查，不把修订覆盖成“第一次就成功”。
人工核对与具体确认
查看 preview 与 evidence，逐条核对 12 条记录，而非只看摘要是否流畅。尤其检查冲突的双方值和替代关系、未提供信息、原始单位、破折号与零值。完成自己的结果后，再读取独立核对依据；答案不进入被检查模型的输入。
本例确认绑定固定输入与代码摘要、三个待审文件摘要。以下命令由读者完成上述核对后执行；提取任务不允许 Agent 自行运行 approve，也不把模型生成的“审核通过”文本当成批准。
$reviewDigest = (Get-Content -LiteralPath .\runs\demo-01\state.json -Raw | ConvertFrom-Json).review_digest
python workflow.py approve demo-01 --digest $reviewDigest
python validate_output.py .\runs\demo-01\output
这里从本次状态中取得实际摘要，不需要填写示例中的假摘要。程序再次核对输入与待审文件，匹配后在 output 中创建 JSON、TSV、Markdown，并记录显式本地确认。预期状态为 completed，独立检查器显示三文件通过。
这一步只在隔离练习目录交付文件，没有发送邮件、提交代码或发布网站。人工确认也不能让错误内容自动正确；它记录操作者认可了哪个具体版本。批准入口的可信性仍依赖宿主限制与实际操作者，文件摘要不能阻止拥有写权限的人改程序或状态。
OpenAI Agents SDK 的人工检查路径是在敏感工具执行前暂停，保存待确认动作和可恢复状态，应用处理决定后继续。本文借鉴“具体动作与状态绑定”的原则，CLI 名称和状态格式均为本例自定义，没有实测 SDK 的批准接口。约束与人工检查
验收与记录范围
验收需要同时核对运行状态与实际文件：三文件确实存在且一致，12 条记录齐全，必要来源可定位，语义人工检查有记录，重复命令不会改写已完成成果。completed 只描述本次程序约定的本地交付，不代表资料陈述已成为真实产品能力。
填写空白执行记录，保存失败与恢复证据、模型原始候选和人工修订。程序的故障注入是人为样例，不能统计为模型失败；使用独立答案验证程序，也不能写成模型已经提取正确。
本章的实际程序验证记录单独列出隔离运行与未完成范围。暂未运行独立模型、真实在线重试、远端写入或定时调度；模型自主决策与原生宿主行为需按读者的实际环境另行验证。
6. 停止条件与定时执行
完成、阻塞与预算
停止既可以表示任务完成，也可以表示继续前提不满足。流程应返回具体状态、已完成范围、未完成项和下一步，而不是统一输出“处理结束”。本例等待候选、等待人工核对和累计次数耗尽的后续动作不同。
对于接入模型的流程，除了工具累计次数，还可限制模型循环次数、token 或费用、单次超时和整体截止时间。达到上限后保存已有结果，说明尚未完成范围；若要扩大预算，应由任务操作者决定，不能在恢复时悄悄清零。费用不可得时保留不可得，不从输出长度推算实际账单。完整成本与版本比较在第九篇展开。
本地 .lock 防止两个工作流命令同时操作同一运行。遇到锁冲突先检查是否仍有进程；硬退出后留下的锁需人工核对现场，程序不自动删除。依赖文件丢失、摘要变化或不完整写入同样不能通过绕过检查继续交付。
长任务、定时任务与协作
长任务是一次执行持续较久；定时任务是到达时间或事件条件后触发新执行；多 Agent 协作是工作如何划分。它们可以组合，但各自需要不同机制。保存检查点不会自动唤醒机器，增加 Agent 也不会自动建立定时器。
本篇不创建真实定时任务。准备把流程交给具体宿主或调度器时，先明确以下配置，再核对其官方支持范围：
| 配置 | 需要落实的内容 |
|---|---|
| 执行环境 | 主机、工作目录、依赖与可用账户 |
| 唤醒条件 | 时间/事件、时区、离线与休眠时的行为 |
| 运行标识 | 触发事件与输入版本的关联，重复触发去重 |
| 并发与恢复 | 上次仍运行时如何处理，失败是否有限继续 |
| 权限与确认 | 预授权范围、待审结果、外部动作的确认机制 |
| 通知条件 | 有意义的变化、完成、失败或需要人工动作 |
| 暂停与取消 | 停止未来触发，当前执行如何处理，产物如何保留 |
例如每天整理新增资料，可以先产出待审稿，只有新增内容、失败或需要人工核对时通知。没有变化时的重复通知不应被当成任务收益。取消未来触发也不等于回滚已经产生的文件或外部动作；具体暂停、漏跑补偿和取消入口必须按所用宿主验证。
过程观察与问题定位
本地 events.jsonl 记录调用安排、成功、故障、候选拒绝、待审稿和交付事件。它帮助区分“没有执行”“执行失败”“等待人工”和“已经完成”。日志与状态不是完整审计系统，仍需结合文件和实际工具返回。
接入模型后还应保存模型调用、参数、原始返回、token 和耗时等可得信息。OpenAI Agents SDK 的 tracing 可以记录模型调用、工具调用、转交与检查等过程，适合定位具体运行的问题。本例仅用本地事件日志，没有连接官方 tracing 服务或上传运行资料。集成与过程观察
7. 常见问题与操作速查
常见问题
| 问题 | 排查方向 |
|---|---|
| start 提示目录已存在 | 失败恢复用原 run_id 的 resume，新实验换标识 |
| resume 仍 blocked | 查看具体原因和累计次数，不用重启清零 |
| waiting_input 没有报告 | 缺少模型/读者候选，这是正常等待 |
| JSON 合法却导入失败 | 核对字段、类型、顺序、定位与缺失规则 |
| waiting_review 却被描述为完成 | 事实检查与确认尚未完成，核对模型结束语 |
| 原文标签存在但值不受支持 | 回到原文含义，保留问题并新开修订运行 |
| 旧摘要无法确认 | 当前版本、待审文件或输入已变化 |
| 输入变化后恢复拒绝 | 检查变化，保留旧运行，新开 run_id |
| 同一运行出现锁 | 核对进程与现场，不能自动删锁绕过 |
| 外部超时后想重复发送 | 先查询真实结果与去重支持，本例不覆盖该机制 |
命令速查
以下命令均在独立练习目录执行；候选保存与人工核对的前提见正文，不把速查作为跳过阶段的连续脚本。
| 目的 | 命令 |
|---|---|
| 新建故障实验 | python workflow.py start demo-01 --fault S3:once |
| 恢复未完成读取 | python workflow.py resume demo-01 |
| 只读复核状态 | python workflow.py status demo-01 |
| 导入新候选 | python workflow.py resume demo-01 --candidate inbox/candidate-v1.json |
| 核对完成后的三文件 | python validate_output.py runs/demo-01/output |
实践练习
- 流程分工：对同一 D5-v1 任务列出固定步骤和模型判断。验收标准：格式检查、状态控制和事实含义分别有负责人，不用模型自述证明工具执行。
- 故障恢复：完成 demo-01 首次读取与恢复。验收标准：失败、恢复均有事件，S1/S2 摘要与修改时间不变，S3 累计 2 次，后续六份来源齐全。
- 错误阻断：从自己的候选复制一个新版本，移除一条记录后导入新运行。验收标准：契约失败保留错误候选，没有待审稿或 output，不计为模型实际失败。
- 事实复核：核对冲突、缺失和耗时来源。验收标准：12 条正确，单位依据齐全，RUN-03 零值保留；结构通过没有替代人工语义检查。
- 重复与版本：完成本地交付后再次 resume、同摘要 approve；另在独立项目副本改变已登记文件再检查。验收标准：前两项不重复生成或改写，变化副本停止恢复，不自动覆盖。
- 预算与调度：完成 stop-01，填写一个只产出待审稿的定时配置表。验收标准：累计 3 次后不再调用，时区、离线行为、并发、通知和取消均明确；未创建的调度标为未执行。
参考资料
以下官方资料用于概念和行为核对，日期为 2026-10-05；本例没有调用其 SDK 或托管运行接口，实际接入须核对当时版本与账户能力。
- Orchestration and handoffs：单 Agent 起点、任务转交与受主流程管理的专门能力。
- Results and state：最终结果、历史与可恢复暂停状态。
- Errors and recovery：已有结果复核、有限重试与断流恢复。
- Guardrails and human review：执行前的检查与具体确认。
- Integrations and observability：调用过程记录与定位。
- 本系列配套资料：独立项目、分阶段任务、空白记录与参考依据。
上一篇：工具调用与 MCP；导读：大模型应用基础与学习路径；系列入口：大模型应用方法与实践；下一篇：结果评估与成本控制。