Follow-up to #5330: recommended guardrail pattern verified on 0.23.1 (results + one output_info papercut)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- ai-infra-agents, tooling
Hướng nghiên cứu
Read the ToolGuardrailFunctionOutput.raise_exception() implementation in agents/tool_guardrails.py and compare it with reject_content(). Reproduce the reported behavior by passing output_info to both methods and inspecting their behavior values; done means the hard-stop path either preserves the reason or warns that the argument is unused. The issue does not name a test file, so locate the relevant guardrail tests before adding coverage.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
cc @jbeckwith-oai — following up from #5330. The results were also posted as a comment on the closed thread for the record; reposting here since a closed thread is easy to miss. You suggested the shared-context pattern and the serial configuration — we implemented both on 0.23.1 and verified everything. Results below, plus one small papercut.
-
Shared state via Runner.run(..., context=state) — confirmed. The plan, halt flag, and observed-call log persist across tool calls and handoffs via data.context.context; no globals needed.
-
Hard-stop / soft-reject semantics — confirmed, both finer points:
- Out-of-plan call → raise_exception() → run stops with ToolInputGuardrailTripwireTriggered.
- Soft-reject: the out-of-plan call sets the halt flag and returns reject_content(); the run completes and the model reports which calls succeeded and which were blocked. Later calls (even in-plan ones) are rejected by the halt-flag check while the model wraps up.
- Fresh-object-per-run isolation confirmed: a second run with a fresh state object runs clean after a first run halted; reusing the halted state object keeps blocking.
- The race window, quantified. We injected 6 tool calls (4 in-plan, 2 out-of-plan) directly into the batch executor Runner.run uses internally — no LLM, n=30 per configuration:
- max_function_tool_concurrency=1: execution order matched submission order, zero timeline overlap in 30/30 runs; at tripwire time only 3/6 calls had started — the window cannot open under serial execution.
- Default concurrent setting: timeline overlap in 30/30 runs; all 6 calls had already started at tripwire time — the window does reproduce.
- Worst case: 5 high-risk out-of-plan calls (money transfer, file deletion, log purge, bank wire, DB drop) → 5/5 vetoed with zero side-effect leakage in both serial and concurrent settings (n=30 each).
-
One papercut for anyone implementing this: a hard-stop tripwire can't carry its reason —
from agents.tool_guardrails import ToolGuardrailFunctionOutput
out = ToolGuardrailFunctionOutput.raise_exception(output_info={"rule": "R1_plan_breach"})
print(out.behavior) # {'type': 'raise_exception'} — output_info droppedok = ToolGuardrailFunctionOutput.reject_content(message="blocked", output_info={"rule": "R1"})
print(ok.behavior) # {'type': 'reject_content', 'message': 'blocked'} — message kept
We pass the veto reason through the shared context object instead; either surfacing output_info in the behavior, or warning on the unused kwarg, would fix it.
- Coverage boundary (documented explicitly on our side): tool input guardrails don't intercept hosted tools or handoffs — coverage claims are scoped to local function tools.
Environment: openai-agents 0.23.1 (latest release), Python 3.12.13, Debian 13. Repro scripts and full result artifacts: https://github.com/lsy1533133/phm-agent-verifier-tests
- Ngôn ngữ chính
- Python
- Star
- 30k
- Fork
- 4.9k
- Merge trung bình
- 18 giờ 13 phút
- Pull request đã merge (30 ngày)
- 215
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của openai/openai-agents-python
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
openai/openai-agents-python#5348 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Support the OpenAI Decisions APIĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
openai/openai-agents-python#5353 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 70/100
openai/openai-agents-python#5342 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
openai/openai-agents-python#5336 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Finished tool call is dropped when a parallel tool's guardrail tripsCó thể đã có người làm @jbeckwith-oai đã nhận 7 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
openai/openai-agents-python#5327 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của openai/openai-agents-python
Issue tương tự
-
Agentic
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Imbad0202/academic-research-skills#979 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
reflex-dev/reflex#7561 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
prometheus-community/ansible#906 · 2 bình luận ·