Chuyển đến nội dung chính
Bạn gắn một chính sách firewall vào một key, mô hình stream một cuộc gọi tool trở lại, và stage response bóc hoặc viết lại nó trước khi agent của bạn hành động trên nó. Quyết định thực thi giống hệt trên mọi provider — cùng quy tắc, cùng verdict, cùng event. Cái khác là hình dạng đường truyền mà client của bạn thấy một khi firewall đã hành động trên một cuộc gọi tool được stream, vì OpenAI chat, OpenAI Responses API, và native Claude /v1/messages mỗi cái đóng khung các cuộc gọi tool khác nhau. Trang này là ghi chú tập trung về những khác biệt quan-sát-được-bởi-khách-hàng đó. Nó không ghi lại ngôn ngữ quy tắc — xem Quy tắc Firewall — hay mô hình stage, được đề cập trong Stage. Để biết cơ chế giữ-và-tái-lắp nội bộ mà cả ba chia sẻ, đọc Nội bộ streaming.

​
1. Tại sao firewall provider streaming khác nhau theo đường truyền

Trên một phản hồi không-stream firewall thấy cả câu trả lời cùng lúc và quyết định. Trên một stream, cuộc gọi tool của mô hình đến dưới dạng một chuỗi mảnh — một tên trong một frame, JSON đối số nhỏ giọt trên nhiều cái nữa. Một verdict cần cuộc gọi đầy đủ (tên và đối số đầy đủ), và một mảnh tool-call, một khi đã chuyển tiếp, không thể bị thu hồi. Nên trên mọi provider gateway làm cùng một việc: nó để content thông thường stream qua live, và giữ các frame tool-call cho đến khi cuộc gọi được lắp ráp đầy đủ. Ở cuối-stream nó đánh giá mỗi cuộc gọi đã lắp ráp và chỉ phát ra các cái sống sót — trong hình dạng event riêng của provider đó.
Văn bản của bạn không bao giờ đình trệ. Chỉ các frame tool-call bị giữ. Content assistant, reasoning, và các frame role stream live và không đổi. Lần giữ áp dụng từ mảnh tool-call đầu tiên đến cuối lượt đó — nên một phản hồi chỉ-chat stream đúng như thể không có firewall nào được gắn.

​
2. OpenAI chat completions

Trên /v1/chat/completions, các cuộc gọi tool stream dưới dạng các mảnh delta.tool_calls khóa theo index. Cổng giữ những cái đó (và hình dạng delta.function_call legacy) và, ở frame đóng, phát ra các cuộc gọi sống sót được re-index từ không, theo sau bởi một frame finish:
Kết cụcCái client của bạn nhận
allowCác frame được giữ gốc, byte-cho-byte — passthrough thực sự.
sanitizeMột delta tool_calls với đối số được viết lại, rồi finish_reason: "tool_calls".
deny (một số cuộc gọi)Chỉ các cuộc gọi sống sót, rồi finish_reason: "tool_calls".
deny (mọi cuộc gọi)Không cuộc gọi tool, rồi finish_reason: "stop" — lượt trông như mô hình chọn trả lời bằng văn bản.
Dòng cuối đó là dấu hiệu để test: khi một firewall bóc mọi cuộc gọi tool khỏi một lượt OpenAI chat, agent của bạn thấy một finish_reason: "stop" sạch, không phải một frame lỗi. Xây vòng lặp của bạn để xử lý “không cuộc gọi tool lượt này” như một kết cục hợp lệ.

​
3. OpenAI Responses API

Stream /v1/responses native có mô hình event riêng — một cuộc gọi tool là một item function_call mở với response.output_item.added, stream các mảnh response.function_call_arguments.delta, và hoàn tất ở response.output_item.done. Firewall đánh giá ở done, điểm đầu tiên cuộc gọi toàn vẹn:
Các event added / argument-delta / done của item được phát ra không đổi một khi cuộc gọi qua.
Vỏ added stream, rồi một done mà đối số là phiên bản đã che — các mảnh argument-delta gốc bị bỏ nên giá trị chưa-che không bao giờ đến bạn.
Các event được buffer bị bỏ, và item bị deny cũng bị lọc ra khỏi đối tượng response.completed cuối mà client của bạn xây trạng thái cuối từ đó — không tham chiếu lủng lẳng tới một cuộc gọi không bao giờ chạy.
Các delta văn bản và reasoning stream live xuyên suốt, đúng như trên chat completions.

​
4. Native Claude /v1/messages

Một stream Anthropic native là một con thú khác: content đến dưới dạng các khối có index — content_block_start → content_block_delta (các mảnh input_json_delta) → content_block_stop — đóng bởi một message_delta mang stop_reason. Firewall giữ từ khối tool_use đầu tiên, đánh giá mỗi cái, và tái dựng các khối sống sót với index liền kề nên một khối bị bóc không để lại khoảng trống index. Dấu hiệu đặc thù-Claude là stop_reason. Nếu mọi khối tool_use bị deny, một stop_reason tool_use sẽ hứa với client của bạn một cuộc gọi tool không bao giờ đến — nên gateway viết lại nó thành end_turn: 
upstream:  content_block_start (tool_use) … message_delta {stop_reason: "tool_use"}
            ↓ firewall denies the only tool_use
client:    (no tool_use block)            … message_delta {stop_reason: "end_turn"}
Một lần bóc một phần giữ các khối tool_use sống sót, re-index liền kề, và để stop_reason: "tool_use" nguyên vẹn.
Điều này áp dụng cho các stream Claude native. Một mô hình Claude được gọi qua các endpoint format-OpenAI được thực thi trên đường truyền OpenAI chat thay vào (§2), nên nó hiển thị finish_reason: "stop", không phải stop_reason: "end_turn". Khớp việc xử lý cuối-lượt của bạn với format đường truyền bạn đã gọi, không phải mô hình bên dưới.

​
5. Một ví dụ cụ thể

Cùng quy tắc tạo ra cùng quyết định trên mọi provider — chỉ hình dạng đường truyền mà client của bạn đọc là khác. Soạn nó một lần, trên stage response: 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs\"}]}"
}
Stream cùng prompt ba cách và firewall deny cuộc gọi rm -rf mỗi lần. Cái client của bạn quan sát:
Đường truyềnTín hiệu cuối sau một lần bóc đầy đủ
OpenAI chatfinish_reason: "stop"
OpenAI Responsesitem vắng khỏi response.completed
Native Claudestop_reason: "end_turn"
Cuộc gọi đã-khớp-và-deny hiện ra giống hệt trong event firewall bất kể đường truyền, nên khả năng quan sát của bạn không-phụ-thuộc-provider dù stream thì có.

​
6. Cái gì giữ nguyên trên các provider

Đường truyền khác; hợp đồng thì không:
  • Verdict và quy tắc không-phụ-thuộc-đường-truyền. allow / audit / deny / sanitize nghĩa như nhau trên mọi provider. Xem Verdict.
  • Sanitize chỉ động đến đối số cuộc gọi tool, không bao giờ nội dung mà một tool trả về — trên mọi đường truyền. Xem Sanitize phản hồi.
  • Allow là passthrough thực sự. Khi firewall không hành động, các frame được giữ được phát lại như đúng các byte thượng nguồn — không re-batch, không mất các trường đặc thù-provider.
  • Shadow mode áp dụng ở mọi nơi. Bật nó và các cuộc gọi tool được giữ luôn sống sót (hạ cấp thành audit) nên bạn có thể đo tác động của một chính sách trên các provider trước khi nó thay đổi traffic. Xem Shadow mode.

​
7. Cái này khớp vào đâu

Nội bộ streaming

Cơ chế giữ-lắp ráp-tái-lắp mà mọi provider chia sẻ.

Stage

Tại sao thực thi cuộc-gọi-tool được stream sống trên bề mặt response.

Verdict

Các quyết định không-phụ-thuộc-provider mà một cuộc gọi được stream phân giải về.

Lọc response

Quản trị các cuộc gọi tool mà một mô hình phát ra, stream hay không.
Để biết các mối đe dọa mà các kiểm tra được stream này giải quyết, xem Cuộc gọi tool nguy hiểm và Rò rỉ dữ liệu; để biết nơi thực thi stream nằm trên đường request, xem Độ trễ đường thực thi.