
当AI开始自由发挥谁来兜底【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python你让客服Agent回答账单问题它却一本正经地帮用户解起了二元一次方程——用户没问它偏要乐于助人。openai-agents-python 里有个专门治这个问题的机制Guardrail防护机制也就是本文说的输入输出校验。它不替你做业务逻辑只负责在关键位置说停。本文讲两件事这套并行校验是怎么工作的以及怎么把校验规则挂到 Agent 和工具上。主流程旁边挂了一个并行校验器先说结论Guardrail 不是拦在请求入口的过滤器而是主流程旁边多挂的一个并行校验器。以输入防护为例用户输入先交给主Agent开始执行同时同一份输入被丢给一个轻量校验Agent通常是 fast/cheap 模型。校验方一旦返回 tripwire_triggeredTruerunner 立刻抛出 InputGuardrailTripwireTriggered 并中止执行。默认 run_in_parallelTrue延迟最低换成 False 就是阻塞模式校验不过主Agent压根不启动——官方文档给的理由很直白省 token也避免工具调用产生副作用。换输出防护来看触发时机和校验对象都变了它不碰用户输入只校验主Agent产出的最终输出且总是等主Agent跑完之后执行所以没有并行参数不过时抛 OutputGuardrailTripwireTriggered。还有个容易忽略的点Agent 级输入防护只对链上第一个 Agent 生效输出防护只对产出最终输出的那个 Agent 生效handoff 接力链中间的节点不检查工具调用则要靠工具级防护补位。规则写在 Agent 上而不是 Runner 上是因为不同 Agent 本来就该配不同的校验规则。详细行为定义见 docs/guardrails.md。如何把一条输入校验规则挂到Agent上最小可运行版本大概长这样from pydantic import BaseModel from agents import Agent, GuardrailFunctionOutput, Runner from agents.decorators import input_guardrail class MathHomeworkOutput(BaseModel): is_math_homework: bool reasoning: str input_guardrail async def math_guardrail(ctx, agent, input): result await Runner.run(check_agent, input, contextctx.context) return GuardrailFunctionOutput( output_inforesult.final_output, tripwire_triggeredresult.final_output.is_math_homework, ) agent Agent( name客服Agent, instructions处理账单与售后问题, input_guardrails[math_guardrail], )几个关键参数tripwire_triggered是熔断开关True 即中止本次运行output_info携带校验方的结构化判断这里带了 reasoning方便排查为什么被拦check_agent本身可以是个小模型 Agent专门输出 Pydantic 结构体。输出防护的写法几乎对称用output_guardrail装饰、挂到output_guardrails即可。完整带运行循环的版本在 examples/agent_patterns/input_guardrails.py被拦后它会往对话里追加一条拒答消息而不是直接断开。防护强度怎么配三个场景对照场景防护侧重推荐组合可调参数客服对话拦无关/越界请求输入防护 输出防护run_in_parallel、校验Agent的output_type金融分析工具调用权限工具级输入/输出防护配阻塞执行tool_input_guardrails、tool_output_guardrails内容生成长文本质量与合规流式周期校验每 N 个 token 查一次检查间隔如 300 字符没有万能配置防护强度应该匹配业务风险等级高风险动作宁可阻塞换确定低风险场景用并行模式换延迟。流式校验的现成写法见 examples/agent_patterns/streaming_guardrails.py。高频坑点正常提问也被拦原因校验Agent的提示词写得太宁可错杀模糊输入倾向判 True。 解法从output_info的 reasoning 抽查误判样本收紧判定指令必要时把判定从是否相关改成是否明确违规。挂上了但一次都没触发原因规则挂在 handoff 链中间的 Agent 上而输入防护只在链首生效。 解法输入防护挂到入口 Agent对每个工具调用都要查的诉求改用tool_input_guardrail/tool_output_guardrail挂在 function tool 上它们对该工具的每次调用都生效。延迟账没算清原因并行模式下tripwire 触发时昂贵模型可能已经消耗了一部分 token。 解法高成本或带副作用的工具流输入防护设run_in_parallelFalse校验不过则主Agent零执行。轻量、声明式、可中断Guardrail 的定位很清晰用一次轻量模型调用做独立裁判声明式挂载、默认并行、熔断即中断主工作流代码基本不用改。进阶有两个方向一是流式防护输出边生成边查发现苗头立即终止二是把校验下沉到工具级管住每一次 function tool 的入参和出参。深度细节可以看 docs/guardrails.md 里 Execution modes 和 Tool guardrails 两节。下一步动作也很具体先在入口 Agent 上挂一条输入防护把拒答文案准备好用合规输入 越界输入各跑一遍再决定要不要加严。【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考