用 Responses API 设计可复核的多代理工作流

结果

得到一条可审计的长任务流程：模型负责需要判断的部分，程序负责确定性处理；每个子代理、工具调用和缓存边界都有输入、输出、耗时与失败状态。这里是根据 OpenAI 构建指南整理的工作流，不是声称 Tabbit 能直接执行的按钮。

前置条件

• 已确认使用 Responses API，并列出允许调用的工具及其 schema。

• 把任务拆成可独立验收的判断步骤和确定性步骤。

• 定义人工批准点、最大重试次数、预算上限和最终验收标准。

• 准备可重复的代表性任务，不用一次成功推断生产成功率。

步骤

1. 先用最小模型和提示完成任务分流，记录为什么需要 Sol，以及预期质量、成本和延迟。

2. 把数据库查询、文件处理和格式转换交给程序化工具调用；不要让模型重复搬运大段工具结果。

3. 只把相互独立且有明确交付物的工作并行交给子代理；为每个子代理设置输入范围、输出 schema 和超时。

4. 汇总时保留来源、工具状态、失败原因和人工复核点，再生成最终结果。

5. 将稳定的系统提示、工具 schema 和不变背景放在缓存前缀，记录命中情况、成本和延迟变化。

输出验收

• 每个阶段都有结构化输出，能回溯到输入、工具结果和来源。

• 失败的调用不会被静默当作成功；汇总结果明确列出缺口。

• 并行任务之间没有重复写入或互相覆盖，重试不会产生重复副作用。

• 记录模型、reasoning effort、工具、样本数、成本和延迟；没有实测的数据标为未知。

• 人工批准点和停止条件在流程中可见，最终产物通过预先定义的验收标准。

失败处理

• 工具返回空值或格式错误时，保留原始状态并重试一次；仍失败则转人工或走明确的降级路径。

• 子代理输出不符合 schema 时，不要让汇总代理猜测，要求修复输出或标记失败。

• 缓存命中率下降时，检查前缀是否被动态内容打断，不要为追求命中率隐藏必要的版本信息。

• 成本或延迟超过上限时，缩小上下文、减少并行范围或降低非关键步骤的 reasoning effort。

边界

• 官方指南的生产案例和成本图表不等于你的 harness 结果，不能直接承诺价格、成功率或延迟。

• 多代理并行会增加协调和失败面；没有独立交付物时不应为了“多代理”拆分。

• 工具调用只表示准备执行或请求执行，不代表获得了权限，也不替代高风险操作的人工审批。