
Guardrail 实战openai-agents-python 的输入输出校验最小配置【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python客服机器人按用户指令批量修改了真实工单多智能体流水线把上游检索到的密钥原样写进了交付报告高价值模型在诱导输入上烧掉了整月 token 预算。这几类失控现场的共同点是主 agent 与外部世界之间没有一道独立于模型自身的检查。openai-agents-python 提供的 Guardrail防护机制就是补这个缺口的把输入校验、输出校验和工具调用校验挂在 agent 上用独立的轻量判定在越界行为到达外部世界之前拦截构成 AI 智能体防护的最后一道闸。Guardrail 定位与主流程并行的校验机制Guardrail 是一种挂载在 Agent 上的并行校验机制它与主流程同时启动由轻量模型完成判定命中 tripwire 时抛出专用异常中止执行。机制上有三个要点。第一判定载体是一个返回GuardrailFunctionOutput的函数tripwire_triggered字段为 True 即视为命中判定逻辑放在独立的小模型 agent 里不占用主 agent 的上下文。第二输入防护有两种执行模式默认并行模式run_in_parallelTrue延迟最低但命中时主 agent 可能已消耗 token、甚至执行过工具阻塞模式run_in_parallelFalse让校验先于主 agent 完成命中时主流程完全不启动适合成本敏感或工具带副作用的场景。第三命中后的行为是可编程的输入/输出防护抛出对应 tripwire 异常工具防护则支持放行、拒绝并回注提示、直接中止三种处置。执行边界与模式细节见 docs/guardrails.md结果数据结构定义在 src/agents/guardrail.py。最小防护接入定义与挂载输入校验以下示例给客服 agent 加一道作业代做拦截判定 agent、防护函数与异常捕获构成完整闭环。input_guardrail(run_in_parallelFalse) async def math_guardrail(ctx, agent, input): r await Runner.run(guard_agent, input) out r.final_output_as(MathHomeworkOutput) return GuardrailFunctionOutput( output_infoout, tripwire_triggeredout.is_math_homework) agent Agent(name客服, input_guardrails[math_guardrail]) try: await Runner.run(agent, user_input) except InputGuardrailTripwireTriggered as e: print(e.guardrail_result.output.output_info.reasoning)两个关键点防护函数与主 agent 共享RunContextWrapper可直接复用上下文里的用户会话信息挂载只需在 Agent 构造参数里声明input_guardrails防护函数对 Runner 透明。输出防护改用output_guardrail装饰器签名把input换成 agent 最终输出即可。可运行版本见 examples/agent_patterns/input_guardrails.py 与 examples/agent_patterns/output_guardrails.py。输入/输出/工具三层防护配置对照对比维度输入防护输出防护工具防护触发时机首轮用户输入到达时链首 agent最终 agent 产出结果之后每次自定义函数工具调用前后各一次校验对象用户原始输入主 agent 的最终输出工具入参 JSON 与工具返回内容典型检查项诱导请求、话题白名单、内容合规敏感信息泄露、违规结论、格式校验危险参数拦截、返回值脱敏命中处置抛异常中止主流程可不启动抛异常候选输出被拒且不落会话放行、拒绝并回注提示、中止三选一适用场景成本保护与恶意输入过滤对外交付前的最后一道闸工具权限管控与数据出口管控分层依据是执行边界输入防护只作用于链首 agent输出防护只作用于产出最终结果的 agent带 manager、handoff 或委托子 agent 的流程里中间环节的工具调用完全绕过这两者必须显式配置工具级防护。工具防护只覆盖function_tool创建的自定义工具托管工具与内置执行工具不走这条管线配置时容易误判覆盖面相关规则集中在 src/agents/tool_guardrails.py。常见坑清单与部署自检并行模式的代价常被低估run_in_parallelTrue下命中 tripwire 时主 agent 的 token 消耗与工具调用可能已经发生。涉及写库、外发邮件等有副作用的工具时改用阻塞模式。误报需要可观测出口命中时异常对象携带guardrail_resultoutput_info存判定理由。将其写入日志与打点才有数据支撑阈值和提示词迭代误报率只能靠猜。多语言输入直接决定判定质量判定 agent 的 instructions 只覆盖单语言时跨语言变体会静默漏检。按业务语言覆盖面写全判定提示词并在测试样本中混入非主语言输入。工具防护并非全量覆盖托管工具与内置执行工具不生效需要审批的工具默认在批准后才跑输入防护要求提前校验需配置RunConfig.tool_execution。流式场景注意落盘语义输出 tripwire 会持久化已完成的工具调用记录但候选最终输出被剔除并替换为固定占位文本防护运行期间调用cancel()会取消在途校验且不写入最终轮会话依赖会话回放的业务需按此语义设计。部署自检清单对照工作流确认挂载点输入防护在链首、输出防护在末端、工具防护在每次调用处缺一层即存在未校验出口。明确每条防护的执行模式并将 P95 延迟纳入接口预算。核对输入/输出两组 tripwire 异常的捕获分支与降级话术。用历史输入回放记录误报与漏报再迭代判定 agent 的提示词与字段语义。验证流式路径下 tripwire 命中、防护异常、主动取消三种终止方式的会话落盘是否符合预期。防护机制的价值不在挂载动作本身而在每次命中后日志里沉淀的判定理由。先跑通闭环再谈收敛误报率。【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考