Chuyển đến nội dung chính
Khi một quy tắc firewall trả về verdict pending_approval, cuộc gọi tool của agent được giữ thay vì dispatch — nó giờ đang chờ một con người. Trang này dành cho người duyệt: cách phê duyệt cuộc gọi tool agent được giữ (hoặc từ chối chúng) từ console, hàng đợi cho bạn thấy gì, và cách OrcaRouter ngăn hai người duyệt va chạm trên cùng một quyết định. Đây là nửa phân giải của con-người-trong-vòng-lặp. Để biết tại sao một cuộc gọi được giữ và cách agent được giữ gửi lại sau đó, xem verdict và tham chiếu phê duyệt sâu hơn. Để phân giải từ hệ thống của riêng bạn thay vì console, xem webhook phê duyệt.

​
1. Vòng đời cuộc-gọi-được-giữ, từ chỗ ngồi của một người duyệt

Một cuộc gọi được giữ là một vòng lặp ngắn ngoài luồng. Việc của bạn là bước giữa:
1

Cuộc gọi được giữ

Một quy tắc phân giải về pending_approval. Relay trả về HTTP 400 với mã firewall_approval_pending và một approval id; cuộc gọi không bao giờ đến được tool. Agent bắt đầu poll trên id đó.
2

Bạn phân giải nó

Bạn mở hàng đợi Approvals, đọc tại sao cuộc gọi được giữ, và phê duyệt hoặc từ chối nó — trọng tâm của trang này.
3

Agent tiến hành (hoặc dừng)

Khi phê duyệt, agent gửi lại cuộc gọi gốc với một header X-OrcaRouter-Firewall-Approval dùng-một-lần và gateway cho nó đi qua lần đó. Khi từ chối, cuộc gọi vẫn bị block.
Phân giải một lần giữ được giới hạn ở Developer+ — cùng cổng với feed Events của firewall. Các vai trò thấp hơn có thể đọc chính sách firewall, cài đặt, và discovered tools, nhưng chỉ các vai trò Developer-trở-lên mới có thể liệt kê hàng đợi phê duyệt hoặc phê duyệt/từ chối một cuộc gọi tool được giữ. Xem vai trò và phạm vi.

​
2. Liệt kê hàng đợi pending

Tab Approvals đọc GET /api/workspace/firewall/approvals. Không có filter nó trả về hàng đợi pending, cũ nhất trước — nên cuộc gọi chờ-lâu-nhất nằm trên đỉnh và bạn xử lý backlog theo thứ tự. 
GET /api/workspace/firewall/approvals?state=pending
state là filter duy nhất quan trọng. Các giá trị ánh xạ tới vòng đời của phê duyệt:
statePhê duyệt trả về
pending (mặc định)Được giữ, chờ một quyết định — hàng đợi công việc của bạn.
approvedĐã được cho qua.
rejectedĐã bị block.
Đây là một route console trên session của bạn — cấu hình và xem xét nó từ dashboard, không phải với một relay key sk-orca-…. Các relay key dành cho các cuộc gọi mô hình /v1/*; quản lý firewall chạy dưới đăng nhập console của bạn.

​
3. Đọc tại sao cuộc gọi được giữ

Mỗi dòng mang các đầu vào quyết định mà một người duyệt cần — tên tool (tool_name), một dấu vân tay đối số (args_hash, SHA-256 của các đối số cuộc gọi đã chuẩn hóa — các giá trị đối số thô không được lưu trong phê duyệt), request id, và một dòng xuất xứ tiếng-Anh-thuần nêu tên chính sách, quy tắc, và mệnh đề đã kích hoạt:
Chính sách có tên mà quy tắc đã khớp thuộc về, được phân giải theo phạm vi workspace nên một id cũ không bao giờ có thể làm hiện tên chính sách của một tenant khác.
Nhãn của quy tắc và một mô tả “tại sao” một dòng — vd: command contains rm -rf, hoặc tool matches "http_fetch" cho một quy tắc chỉ-glob. Cái này render dòng “Held because…” trong hàng đợi.
true khi quy tắc đã khớp được chỉnh sửa tại hoặc sau khi phê duyệt này được tạo. Nhãn và mệnh đề live khi đó bị nén lại (chúng có thể không còn phản ánh cái thực sự giữ cuộc gọi), và hàng đợi hiển thị một ghi chú “rule since changed” thay vì xuất xứ cũ. Tên tool và đối số — các đầu vào quyết định thật — luôn được hiển thị.
rule_changed là một tín hiệu trung thực có chủ đích, không phải một lỗi. Nếu ai đó chỉnh sửa quy tắc firewall trong khi một cuộc gọi đang nằm trong hàng đợi, OrcaRouter thà ẩn một lý do có-thể-sai còn hơn cho bạn thấy xuất xứ không còn khớp. Quyết định dựa trên tên tool và tên chính sách (vẫn được hiển thị) trong trường hợp đó.

​
4. Phê duyệt hoặc từ chối

Phân giải gửi PATCH /api/workspace/firewall/approvals/:id với một decision là approved hoặc rejected và một reason tùy chọn. Console làm điều này cho bạn khi bạn nhấp nút; hình dạng là: 
PATCH /api/workspace/firewall/approvals/507f1f77bcf86cd799439011
Content-Type: application/json

{ "decision": "approved", "reason": "verified target host with the on-call" }
  • approved → cuộc gọi được giữ có thể tiến hành. Lần gửi lại kế tiếp của agent, mang approval header dùng-một-lần, được cho qua một lần.
  • rejected → cuộc gọi vẫn bị block. Agent thấy sự từ chối và có thể chọn một đường khác, hỏi người dùng, hoặc dừng.
decision được kiểm tra với tập đóng {approved, rejected} — bất cứ thứ gì khác bị từ chối. reason được ghi lại cùng quyết định và viết vào audit log firewall bên cạnh actor, tên tool, và request id.
Mỗi lần phân giải ghi một dòng audit workspace nêu tên ai đã quyết định, quyết định, và lý do. Các lần phân giải console ghi lại actor con người; các lần phân giải webhook ghi lại một actor hệ thống. Xuất xứ phân giải không bao giờ bị âm thầm bỏ.

​
5. First-writer-wins: không phân giải kép

Một phê duyệt pending có thể bị race — hai người duyệt trong console, hoặc một cú nhấp console và một webhook callback đến cùng lúc. OrcaRouter giải quyết điều này với một quy tắc first-writer-wins duy nhất:
  • Quyết định là một cập nhật có điều kiện atomic chỉ kích hoạt trong khi phê duyệt vẫn là pending. Người viết đầu tiên thắng và áp dụng quyết định.
  • Mọi người viết sau quan sát “đã phân giải” và được xử lý như một no-op idempotent — nó nhận HTTP 200 với tài liệu đã-phân-giải, không phải một lỗi.
Phản hồi cho bạn biết bạn ở phía nào: 
{
  "resolved": false,
  "already_resolved": true,
  "approval": { "state": "approved", "decision": "approved", "...": "..." }
}
resolved: true nghĩa là cuộc gọi của bạn đã áp dụng quyết định; already_resolved: true nghĩa là ai đó (hoặc một webhook nào đó) đã đến trước và bạn đang thấy kết cục của họ. Dù cách nào hàng đợi đối chiếu về một trạng thái nhất quán.
Vì việc phân giải là idempotent, một mạng chập chờn hay một cú nhấp-kép không thể làm hỏng một lần giữ hoặc lật một quyết định. Lần đầu tiên phê duyệt/từ chối là cái duy nhất được tính; mọi thứ sau nó chỉ đọc lại kết quả.

​
6. Một lượt cụ thể qua hàng đợi

Một workspace balanced-autonomy giữ một cuộc gọi shell.exec của agent vì một quy tắc khớp command contains rm -rf. Là người duyệt bạn:
  1. Mở Approvals — shell.exec được giữ nằm trên đỉnh của danh sách pending cũ-nhất-trước.
  2. Đọc dòng: tool shell.exec, dấu vân tay args_hash, request id, và dòng “Held because… command contains rm -rf” (render từ mệnh đề của quy tắc đã khớp). Không có cờ rule_changed, nên xuất xứ là hiện hành.
  3. Đích là một thư mục scratch, nên bạn phê duyệt với một lý do.
  4. PATCH của bạn trả về resolved: true; lần poll kế tiếp của agent thấy approved, gửi lại với header dùng-một-lần của nó, và lệnh chạy đúng một lần.
Nếu một đồng đội đã phê duyệt nó sớm hơn một giây, cú nhấp của bạn sẽ trả về already_resolved: true với quyết định của họ — không hại, không chạy-kép.

​
Đi đâu tiếp theo

Tham chiếu phê duyệt

Toàn bộ vòng lặp HITL: giữ, poll, gửi lại, và header dùng-một-lần.

Webhook phê duyệt

Phân giải các lần giữ từ hệ thống của riêng bạn với một callback ký HMAC.

Verdict

Nơi pending_approval nằm giữa sáu verdict firewall.

Events log

Xác nhận kết cục hạ nguồn của một cuộc gọi đã phân giải trong feed.
Để biết các rủi ro mà các lần giữ này nhằm bắt, xem cuộc gọi tool nguy hiểm và quyền tự quyết quá mức.