跳转到内容

人机协作

本指南介绍 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
},
});
  1. 工具调用即将执行时,SDK 会评估其审批规则(needsApproval 或对应的托管 MCP 规则)。
  2. 如果需要审批且尚未存储相关决定,工具调用不会执行。运行会改为记录一个 RunToolApprovalItem
  3. 在该轮次结束时,运行会暂停,并在执行结果interruptions 数组中返回所有待处理审批。这包括嵌套 agent.asTool() 运行中产生的审批。
  4. 使用 result.state.approve(interruption)result.state.reject(interruption) 处理每个待处理项目。如果希望在本次运行的剩余时间内始终批准或拒绝同一工具,请传入 { alwaysApprove: true }{ alwaysReject: true }。拒绝时,您还可以传入 { message: '...' },控制针对该特定工具调用发送回模型的拒绝文本。
  5. 将更新后的 result.state 传回 runner.run(agent, state) 以恢复运行,其中 agent 是本次运行的原始顶层智能体。SDK 会从中断点继续,包括嵌套的智能体工具执行。

默认情况下,函数工具的输入护栏仅在审批后、工具执行前立即运行。如果希望在显示待处理审批之前,让相同的输入护栏验证本地函数工具调用,请向 run()Runner 传入 toolExecution: { preApprovalInputGuardrails: true }。如果审批前护栏拒绝调用,SDK 会将护栏消息作为工具输出返回给模型,而不会创建审批中断。如果护栏允许调用,运行仍会暂停以等待审批,并且输入护栏会在审批后再次运行,以防工具调用在等待期间变得不安全。

needsApproval 是函数时,SDK 仅会在工具参数解析为可检查对象后调用它。格式错误的 JSON 和非对象值会以安全失败方式处理:SDK 会请求审批,但不会调用回调或执行工具。即使批准该调用,工具仍不会执行,而是继续进入常规的参数解析错误流程。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: truealwaysReject: true 创建的持久决定,会作为之后对同一工具调用的默认决定。针对某个调用 ID 的精确决定优先于该持久默认值:在默认持久批准的情况下,您可以拒绝某次调用;在默认持久拒绝的情况下,也可以批准某次调用,而无需更改其他调用的默认值。如果之后替换该精确决定,新决定会应用于该调用,而持久默认值仍会应用于其他调用。

当运行暂停期间收到新的用户输入,并且应在下一次恢复后的模型调用前将其纳入处理时,请使用 RunState.addInput()。请先添加输入,再处理审批,并将同一状态传回 Runner.run()。暂存输入属于序列化状态的一部分,因此即使未处理的审批或本地工具工作延迟了模型调用,它仍可保留在 toString() / fromString() 的序列化和反序列化过程中。

读取 state.pendingInput 可以检查暂存项目的克隆快照;也可以在恢复前调用 state.clearPendingInput() 将其全部移除。addInput() 接受字符串或输入项目数组。如果状态无法安全地执行另一次模型调用,例如状态已终止、没有剩余轮次,或者某个中断的工具结果可能结束运行,它会抛出 UserError

纳入处理后,每个暂存输入实例都会成为运行的 newItems 中的一个 RunInputItem,其原始输入项目则会包含在 history 中。使用本地 session 时,SDK 会在开始模型请求前持久化一次已纳入的输入。使用 conversationIdpreviousResponseId 时,该输入会保持待处理状态,直到服务器接受响应,因此,如果确认失败发生在接受之前,便可恢复运行而不会丢失输入。如果提供方报告请求可能已被接受,SDK 会为该输入实例创建检查点并以安全失败方式停止,而不会在没有提示的情况下将其重放。有关单独且明确的不安全重放覆盖选项,请参阅模型重试

手动处理 interruptions 是适用范围最广的模式,但不是唯一方式:

  • 本地 shellTool()applyPatchTool() 可以使用 onApproval,直接在代码中批准或拒绝。
  • 托管 MCP 工具可以结合使用 requireApprovalonApproval,实现同类程序化决策。
  • 普通函数工具使用本页介绍的手动中断流程。

当这些回调返回决定时,运行会继续,而无需暂停等待人工响应。对于 Realtime 会话 API,请参阅构建语音智能体中的审批流程。

相同的中断流程也适用于流式运行。流式运行暂停后,请等待 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 });
});

如需可运行的端到端版本,请参阅完整示例脚本

人机协作流程允许长时间中断,无需让服务器持续运行。如果您需要结束请求并在之后继续,可以序列化状态,稍后再恢复。

您可以使用 result.state.toString()(或 JSON.stringify(result.state))序列化状态,之后再将序列化状态传入 RunState.fromString(agent, serializedState) 以恢复运行,其中 agent 是触发整个运行的智能体实例。

当已获批准的函数工具结果可能成为运行的最终输出时,输出护栏会施加更严格的恢复边界。当 SDK 能够确认归属关系时,当前的 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 })

这样,您就可以将序列化状态存储在数据库中,或与请求一起存储。

如果审批请求耗时较长,并且您计划对智能体定义进行实质性的版本管理,或升级 Agents SDK 版本,目前建议您通过包别名并行安装两个版本的 Agents SDK,并实现自己的分支逻辑。

在实践中,这意味着为自己的代码分配版本号,将其与序列化状态一起存储,并引导反序列化过程使用正确版本的代码。