InputGuardrailTripwireTriggered 已经抛出，为什么工具还是执行了

收到 InputGuardrailTripwireTriggered 后，界面显示请求被拒绝，但后台工具日志里仍能看到执行记录。若输入 guardrail 使用默认并行模式，这可能是执行时序造成的。

先看 guardrail 是否阻塞 agent

默认的输入检查与 agent 同时开始。检查完成前，模型可能已经生成内容，甚至发起工具调用。后来触发 tripwire，并不能撤销已发生的动作。

这个问题在 Agents SDK #991 中有明确报告，环境包含 0.1.0。后来合并的 #1986 增加了 run_in_parallel 参数；默认值仍为 True，因此升级不会自动让现有检查变成阻塞模式。

如果要求“输入验证通过后才允许调用模型和工具”，应使用阻塞输入检查。例如：

from agents import GuardrailFunctionOutput, input_guardrail

@input_guardrail(run_in_parallel=False)
async def reject_blank_request(ctx, agent, user_input):
    rejected = isinstance(user_input, str) and not user_input.strip()
    return GuardrailFunctionOutput(
        output_info={"blank_request": rejected},
        tripwire_triggered=rejected,
    )

把这个 guardrail 放到首个 agent 的 input_guardrails 中。例子只演示执行模式和空输入判断，不能代替真实业务的权限或内容校验。

哪些检查还要放到工具边界

输入 guardrail 只在流程首个 agent 的输入边界运行。一次输入验证通过后，后续 handoff 或工具调用仍可能涉及不同资源、参数与权限。

对于每次工具调用都必须满足的条件，应在适当的工具执行边界再检查。官方 guardrails 文档 说明了工具级 guardrail 的范围；不能假定所有 hosted tool、handoff 和函数工具都走同一条检查管线。

怎样验证没有抢跑

让测试 guardrail 故意慢一点，并用一个只增加计数器的本地测试工具代替真实外部动作。对拒绝输入，断言工具执行次数为零；需要完全阻断模型调用时，也检查模型调用计数。

流式入口同样测试：判定拒绝前不应泄露正文片段，消费事件时应走到预期的 tripwire 异常分支。合法输入则应能继续完成，避免把所有请求一起拦下。

对已经执行过的付款、写库或发送消息，不能靠捕获 tripwire 自动回滚。此时应按业务记录核对真实结果，再决定补偿或人工处理。