人机协作
本指南介绍 SDK 基于审批的人工干预流程。当工具调用需要审批时,SDK 会暂停运行,返回 interruptions,并允许您稍后从同一个 RunState 恢复运行。
该审批范围覆盖整个运行,并不限于当前顶层智能体。无论工具属于当前智能体、通过交接到达的智能体,还是嵌套的 agent.asTool() 执行,都适用相同的模式。在嵌套的 agent.asTool() 场景中,中断仍会呈现在外层运行中,因此您需要在外层的 result.state 上批准或拒绝该中断,然后恢复原始根运行。
使用 agent.asTool() 时,审批可能发生在两个不同层级:智能体工具本身可以通过 asTool({ needsApproval }) 要求审批;嵌套智能体开始运行后,其内部工具也可能提出自己的审批请求。两者都通过同一个外层运行中断流程处理。
本页重点介绍通过 interruptions 实现的手动审批流程。如果您的应用可以在代码中作出决定,部分工具类型还支持程序化审批回调,使运行无需暂停即可继续。如果您正在设置 agent.asTool() 本身,请参阅工具;本页介绍该运行层级中的任何工具需要审批后会发生什么。
您可以将 needsApproval 选项设置为 true,或者设置为返回布尔值的异步函数,以定义需要审批的工具。
import { tool } from '@openai/agents';import z from 'zod';
const sensitiveTool = tool({ name: 'cancelOrder', description: 'Cancel order', parameters: z.object({ orderId: z.number(), }), // always requires approval needsApproval: true, execute: async ({ orderId }, args) => { // prepare order return },});
const sendEmail = tool({ name: 'sendEmail', description: 'Send an email', parameters: z.object({ to: z.string(), subject: z.string(), body: z.string(), }), needsApproval: async (_context, { subject }) => { // check if the email is spam return subject.includes('spam'); }, execute: async ({ to, subject, body }, args) => { // send email },});- 工具调用即将执行时,SDK 会评估其审批规则(
needsApproval或托管 MCP 的对应机制)。 - 如果需要审批且尚未存储决定,工具调用不会执行。运行会改为记录一个
RunToolApprovalItem。 - 在该轮结束时,运行会暂停,并在执行结果的
interruptions数组中返回所有待处理的审批。这包括嵌套agent.asTool()运行内部提出的审批。 - 使用
result.state.approve(interruption)或result.state.reject(interruption)处理每个待处理项。如果希望同一工具在该运行的剩余时间内始终被批准或拒绝,请传入{ alwaysApprove: true }或{ alwaysReject: true }。拒绝时,您还可以传入{ message: '...' },以控制针对该特定工具调用返回给模型的拒绝文本。 - 将更新后的
result.state传回runner.run(agent, state)以恢复运行,其中agent是该运行原始的顶层智能体。SDK 会从中断点继续,包括嵌套的智能体工具执行。
默认情况下,函数工具输入护栏仅在审批完成后、工具即将执行前运行。如果您希望在显示待处理审批之前,使用相同的输入护栏验证本地函数工具调用,请将 toolExecution: { preApprovalInputGuardrails: true } 传给 run() 或 Runner。当审批前护栏拒绝调用时,SDK 会将护栏消息作为工具输出返回给模型,而不会创建审批中断。当护栏允许调用时,运行仍会暂停以等待审批;审批完成后,输入护栏会再次运行,以防工具调用在等待期间变得不安全。
当 needsApproval 是函数时,SDK 仅会在工具参数解析为可检查的对象后调用它。格式错误的 JSON 和非对象值会出于安全考虑直接要求审批,而不会调用回调或执行工具。即使批准该调用,工具仍不会执行;调用将继续进入常规的参数解析错误流程。Realtime 函数工具遵循相同规则,并会为无效调用发出 tool_approval_requested。
使用 { alwaysApprove: true } 或 { alwaysReject: true } 创建的持久决定会存储在运行状态中,因此稍后恢复同一个暂停的运行时,这些决定可通过 toString() / fromString() 保留。
在 GA 模型中,计算机工具中断可以表示一次 computer_call 中的一批操作。SDK 会在执行前逐项评估各操作的 needsApproval,因此一个待处理审批可以涵盖移动和点击等一系列操作。如果您通过检查 interruption.rawItem 来呈现 UI,请同时处理 GA 版本的 actions 数组和旧版的单个 action 字段。
序列化的 RunState 还会同时保留当前 computer 工具名称和旧版 computer_use_preview 名称对应的计算机操作审批,因此在从预览版迁移到 GA 版本期间,暂停的运行也能顺利恢复。
如果您未提供 message,SDK 会依次回退到已配置的 toolErrorFormatter(如有)和默认拒绝文本。
您无需在同一轮处理中解决所有待处理审批。如果只批准或拒绝部分项目后重新运行,已处理的调用可以继续,而未处理的调用仍会保留在 interruptions 中,并再次暂停运行。
使用 alwaysApprove: true 或 alwaysReject: true 创建的持久决定,会作为之后调用同一工具时的默认值。针对某个调用 ID 的精确决定优先于该持久默认值:您可以在持久批准的情况下拒绝某次调用,也可以在持久拒绝的情况下批准某次调用,而不会更改其他调用的默认值。如果之后替换该精确决定,新决定将应用于该调用,而持久默认值仍可用于其余调用。
恢复前的输入添加
Section titled “恢复前的输入添加”当运行暂停期间收到新的用户输入,且应在下一次恢复后的模型调用之前接纳该输入时,请使用 RunState.addInput()。请先添加输入,再处理审批,并将同一状态传回 Runner.run()。暂存输入属于序列化状态的一部分,因此即使未处理的审批或本地工具工作延迟了该模型调用,它也能通过 toString() / fromString() 保留。
读取 state.pendingInput 可检查暂存项的克隆快照,也可以在恢复前调用 state.clearPendingInput() 将它们全部移除。addInput() 接受字符串或输入项数组。当状态无法安全到达另一次模型调用时,例如状态已终止、没有剩余轮次,或某项中断的工具结果可能结束运行,它会引发 UserError。
接纳后,每个暂存输入实例都会成为运行的 newItems 中的一个 RunInputItem,其原始输入项则会包含在 history 中。使用本地 session 时,SDK 会在开始模型请求前持久化一次已接纳的输入。使用 conversationId 或 previousResponseId 时,该输入会保持待处理状态,直到服务器接受响应,因此,如果已知故障发生在接受之前,便可以在不丢失输入的情况下恢复。如果提供商报告请求可能已被接受,SDK 会为该输入实例创建检查点,并出于安全考虑停止处理,而不是在未提示的情况下重放。有关单独且显式的不安全重放覆盖选项,请参阅模型重试。
自动审批决策
Section titled “自动审批决策”手动处理 interruptions 是最通用的模式,但并非唯一模式:
- 本地
shellTool()和applyPatchTool()可以使用onApproval,立即在代码中批准或拒绝。 - 远程 MCP 服务器工具可以同时使用
requireApproval和onApproval,实现相同类型的程序化决策。 - 普通函数工具使用本页介绍的手动中断流程。
当这些回调返回决定时,运行会继续,无需暂停并等待人工响应。有关 Realtime 会话 API,请参阅构建语音智能体中的审批流程。
流式传输与会话
Section titled “流式传输与会话”相同的中断流程也适用于流式运行。流式运行暂停后,请等待 stream.completed,读取 stream.interruptions 并进行处理;如果希望恢复后的输出继续使用流式传输,请使用 { stream: true } 再次调用 run()。有关该模式的流式版本,请参阅流式传输中的人工干预。
如果您还使用了 session,通过 RunState 恢复时请继续传入同一个 session。恢复后的轮次随后会追加到会话记忆中,而无需重新准备输入。有关会话生命周期的详细信息,请参阅会话。
下面是一个更完整的人工干预流程示例,它会在终端中请求审批,并将状态临时存储在文件中。
import { z } from 'zod';import readline from 'node:readline/promises';import fs from 'node:fs/promises';import { Agent, run, tool, RunState, RunResult } from '@openai/agents';
const getWeatherTool = tool({ name: 'get_weather', description: 'Get the weather for a given city', parameters: z.object({ location: z.string(), }), needsApproval: async (_context, { location }) => { // forces approval to look up the weather in San Francisco return location === 'San Francisco'; }, execute: async ({ location }) => { return `The weather in ${location} is sunny`; },});
const dataAgentTwo = new Agent({ name: 'Data agent', instructions: 'You are a data agent', handoffDescription: 'You know everything about the weather', tools: [getWeatherTool],});
const agent = new Agent({ name: 'Basic test agent', instructions: 'You are a basic agent', handoffs: [dataAgentTwo],});
async function confirm(question: string) { const rl = readline.createInterface({ input: process.stdin, output: process.stdout, });
const answer = await rl.question(`${question} (y/n): `); const normalizedAnswer = answer.toLowerCase(); rl.close(); return normalizedAnswer === 'y' || normalizedAnswer === 'yes';}
async function main() { let result: RunResult<unknown, Agent<unknown, any>> = await run( agent, 'What is the weather in Oakland and San Francisco?', ); let hasInterruptions = result.interruptions?.length > 0; while (hasInterruptions) { // Store the current run state await fs.writeFile( 'result.json', JSON.stringify(result.state, null, 2), 'utf-8', );
// At this point, another process could review the saved state
// Read the saved state later const storedState = await fs.readFile('result.json', 'utf-8'); const state = await RunState.fromString(agent, storedState);
for (const interruption of result.interruptions) { const confirmed = await confirm( `Agent ${interruption.agent.name} would like to use the tool ${interruption.name} with "${interruption.arguments}". Do you approve?`, );
if (confirmed) { state.approve(interruption); } else { state.reject(interruption); } }
// Resume execution from the restored state result = await run(agent, state); hasInterruptions = result.interruptions?.length > 0; }
console.log(result.finalOutput);}
main().catch((error) => { console.dir(error, { depth: null });});请参阅完整示例脚本,了解可运行的端到端版本。
长时间审批的处理
Section titled “长时间审批的处理”人工干预流程可以长时间保持可中断状态,而无需让您的服务器持续运行。如果您需要结束请求并在稍后继续,可以序列化状态并在之后恢复。
您可以使用 result.state.toString()(或 JSON.stringify(result.state))序列化状态,之后将序列化状态传入 RunState.fromString(agent, serializedState) 以恢复运行,其中 agent 是触发整体运行的智能体实例。
当已批准的函数工具结果可能成为运行的最终输出时,输出护栏会施加更严格的恢复边界。实时的 RunState 可以保留序列化后无法获取的输出归属信息。如果序列化检查点无法确定待处理输出属于哪个响应,或者在附加了会话的情况下恢复存在歧义且包含输出的检查点,SDK 会在产生进一步的模型、工具或会话副作用之前引发 UserError,并出于安全考虑停止处理。发生这种情况时,请使用安全输入开始新的运行。请重新构建相同的智能体图并保留原始 toolUseBehavior;不要假定每个包含输出的部分审批都能通过序列化状态完成往返转换。
序列化 RunState 时,SDK 会为交接和 Agent.asTool() 图记录稳定的智能体标识。只要恢复运行的进程重新构建相同的智能体图,即使不同智能体具有相同的 name,暂停的运行也能恢复。
传给 RunState.fromString(agent, serializedState) 的 agent 是重新构建的图的根节点。反序列化期间,SDK 会遍历该智能体的交接和 Agent.asTool() 引用,然后根据重新构建的图解析状态中每个已序列化的智能体引用。这包括当前智能体,以及生成项、已处理的模型响应和排队的后续步骤中保存的嵌套引用。
如果您需要使用替代图恢复运行,例如智能体的模型或工具已由另一个运行时封装,请先使用原始图反序列化状态,再次将其序列化,然后使用替代的根智能体反序列化该字符串。调用 state.setCurrentAgent(agent) 只会更改活动智能体,不会重写反序列化期间已经解析的嵌套引用。
如果恢复运行的进程需要注入新的上下文对象,请改用 RunState.fromStringWithContext(agent, serializedState, context, { contextStrategy })。
contextStrategy: 'merge'(默认)会保留提供的RunContext,合并序列化的审批状态,并在新上下文尚未定义toolInput时恢复序列化的toolInput。contextStrategy: 'replace'会按原样使用提供的RunContext重新构建运行。
序列化运行状态包含您的应用上下文,以及由 SDK 管理的运行时元数据,例如审批、用量、嵌套的 toolInput 和待处理的嵌套智能体工具恢复信息。如果您计划存储或传输序列化状态,请将 runContext.context 视为持久化数据;除非您有意让密钥随状态一起传输,否则请避免将密钥放入其中。
默认情况下,序列化状态会省略追踪 API 密钥,以免您意外持久化密钥。仅当确实需要让追踪凭据随状态一起转移时,才传入 result.state.toString({ includeTracingApiKey: true })。
这样,您就可以将序列化状态存储在数据库中,或与请求一起存储。
待处理任务的版本管理
Section titled “待处理任务的版本管理”如果您的审批请求需要较长时间,并且您计划以实质性方式对智能体定义进行版本管理,或升级 Agents SDK 版本,我们目前建议您使用软件包别名并行安装两个版本的 Agents SDK,以实现自己的分支逻辑。
实际做法是为您自己的代码分配版本号,将其与序列化状态一起存储,并引导反序列化过程使用正确版本的代码。