Các kiểm soát của AI agent gateway là các quy tắc vận hành quyết định agent có thể gọi những gì, có thể chi tiêu bao nhiêu, bằng chứng nào phải được ghi lại, và khi nào quá trình chạy phải tạm dừng, chuyển sang phương án dự phòng, hoặc dừng lại. Nếu không có các kiểm soát đó, một agent gateway sẽ trở thành một cách nhanh hơn để che giấu sự bành trướng của công cụ, chi tiêu token không kiểm soát, và các lỗi sản xuất không rõ ràng.
Mục tiêu không phải là gói gọn mọi agent vào một quy trình. Mục tiêu là làm cho hành vi của agent có thể kiểm tra được trước khi đến tay người dùng sản xuất. Một agent hỗ trợ có thể tra cứu đơn hàng, một agent lập trình có thể chỉnh sửa tệp, và một agent tài chính có thể so sánh hóa đơn không nên chia sẻ cùng một quyền truy cập công cụ, ngân sách, ghi log, hoặc chính sách dừng.
Sử dụng hướng dẫn này để thiết kế các kiểm soát của AI agent gateway dưới dạng chính sách, các trường bằng chứng, và các bài kiểm tra chấp nhận. Sau đó, xác thực mô hình Flatkey hiện tại, định tuyến, sử dụng, và bằng chứng thanh toán trên trang giá của Flatkey trước khi triển khai.
Các kiểm soát của AI agent gateway bắt đầu với một ranh giới chính sách
Một agent gateway nằm giữa các môi trường thực thi của agent, API của mô hình, công cụ nội bộ, và bộ phận đánh giá tài chính. Điều này làm cho nó trở thành một nơi tốt để tiêu chuẩn hóa bốn quyết định:
| Lĩnh vực kiểm soát | Câu hỏi của Gateway | Bằng chứng sản xuất |
|---|---|---|
| Sử dụng công cụ | Luồng công việc này có thể gọi những công cụ nào, với những đối số nào, và dưới sự chấp thuận của ai? | Tên công cụ, phiên bản schema, đối số, trạng thái phê duyệt, trạng thái kết quả |
| Ngân sách | Chi tiêu cho đầu vào, đầu ra, suy luận, công cụ, thử lại, và dự phòng được phép là bao nhiêu? | Số lượng token, chi phí yêu cầu, khóa chủ sở hữu, kết quả ngân sách, chi tiêu dự phòng |
| Log | Điều gì đã xảy ra, tuyến đường nào đã phục vụ nó, và những gì có thể được xem xét lại sau này? | ID yêu cầu, luồng công việc, mô hình, tuyến đường, các lệnh gọi công cụ, lý do dừng, mã lỗi |
| Điều kiện dừng | Khi nào quá trình chạy nên kết thúc, thử lại, yêu cầu phê duyệt, chuyển sang dự phòng, hoặc thất bại và đóng lại? | Điều kiện dừng, lý do chuyển sang dự phòng, quyết định của người xem xét, trạng thái cuối cùng |
Các kiểm soát của AI agent gateway này nên được xem xét giống như chính sách cơ sở hạ tầng, chứ không phải là bản sao của prompt. Prompt có thể giải thích ý định, nhưng chính sách của gateway nên thực thi những gì xảy ra khi mô hình yêu cầu một công cụ nhạy cảm, vượt quá ngân sách, nhận được kết quả công cụ không mong muốn, hoặc lặp lại.
Kiểm soát sử dụng công cụ: cho phép ít công cụ hơn những gì agent biết
Gọi công cụ rất mạnh mẽ vì nó kết nối các mô hình với các hệ thống thực. Đây cũng là nơi một agent chuyển từ đề xuất sang hành động. Tài liệu về gọi hàm của OpenAI mô tả các lệnh gọi công cụ như một luồng đa bước: mô hình yêu cầu một công cụ, ứng dụng của bạn thực thi nó, và đầu ra của công cụ được trả về cho mô hình. Tài liệu về sử dụng công cụ của Anthropic cũng tương tự khi Claude trả về các khối tool_use, với mã ứng dụng chịu trách nhiệm thực thi. Việc gọi hàm của Google Gemini cũng phụ thuộc vào các hàm đã khai báo và các lệnh gọi hàm do mô hình tạo ra.
Mô hình chung đó rất quan trọng đối với các kiểm soát của AI agent gateway: mô hình không nên thực thi công cụ một cách trực tiếp. Gateway hoặc môi trường thực thi của bạn nên quyết định liệu công cụ được yêu cầu có được phép hay không, liệu các đối số có khớp với chính sách hay không, liệu có cần phê duyệt hay không, và liệu kết quả của công cụ có an toàn để gửi lại hay không.
Sử dụng chính sách công cụ ba lớp:
- Danh mục công cụ: tập hợp đầy đủ các công cụ tồn tại trong tổ chức.
- Danh sách cho phép của luồng công việc: tập hợp nhỏ hơn các công cụ mà một tuyến agent cụ thể có thể gọi.
- Hạn chế ở cấp độ lượt: các công cụ có sẵn cho yêu cầu này sau khi kiểm tra vai trò, đối tượng thuê, môi trường, ngân sách và rủi ro.
Ví dụ, một agent hỗ trợ khách hàng có thể có quyền truy cập vào lookup_order, search_policy, và open_ticket ở chế độ bình thường. Nó không nên nhận được issue_refund, cancel_contract, hoặc delete_account cho đến khi luồng công việc đạt đến một lộ trình leo thang đã được phê duyệt.
Việc kiểm soát phải rõ ràng:
workflow: support_resolution_agent
tool_policy:
default_mode: deny
allowed_tools:
- lookup_order
- search_policy
- open_ticket
approval_required:
- issue_refund
- cancel_subscription
blocked_tools:
- export_customer_database
schema_rules:
require_strict_arguments: true
reject_unknown_fields: true
log_redacted_arguments: true
on_violation:
action: stop
user_message: ask_for_human_reviewHướng dẫn gọi hàm của OpenAI khuyến nghị mô tả hàm rõ ràng, schema JSON, chế độ nghiêm ngặt ở những nơi được hỗ trợ, và giữ cho số lượng hàm có sẵn ban đầu ở mức nhỏ. Đó không chỉ là lời khuyên về hiệu suất của mô hình. Đó còn là một kiểm soát của agent gateway: càng ít công cụ được phơi bày thì càng có ít trạng thái không hợp lệ cần xem xét sau một sự cố.
Kiểm soát ngân sách: giới hạn toàn bộ quá trình chạy, không chỉ một lệnh gọi mô hình
Chi phí của agent hiếm khi đến từ một yêu cầu đơn lẻ, sạch sẽ. Nó đến từ schema công cụ, lịch sử hội thoại, ngữ cảnh truy xuất, token suy luận, kết quả công cụ, các lần thử lại, các mô hình dự phòng, và các nỗ lực lặp đi lặp lại sau những thất bại một phần.
Các kiểm soát ngân sách của AI agent gateway nên bao quát toàn bộ quá trình chạy:
| Bề mặt ngân sách | Giới hạn cái gì | Tại sao nó quan trọng |
|---|---|---|
| Ngân sách yêu cầu | token đầu vào, token đầu ra, token suy luận, số lần gọi model tối đa | Ngăn một lượt trở thành một sự kiện chi tiêu bất ngờ |
| Ngân sách công cụ | số lần gọi công cụ, kích thước kết quả công cụ, chi tiêu API bên ngoài | Ngăn chặn các vòng lặp công cụ và việc lấy dữ liệu tốn kém |
| Ngân sách thử lại | số lần thử lại, mã trạng thái có thể thử lại, cửa sổ lùi | Tách biệt khả năng phục hồi khỏi sự lặp lại không kiểm soát |
| Ngân sách dự phòng | số lượng model dự phòng, trần chi phí dự phòng, lý do dự phòng | Giữ cho độ tin cậy không che giấu một tuyến chính bị hỏng |
| Ngân sách chủ sở hữu | giới hạn dự án, nhóm, khách hàng, môi trường, khóa hoặc quy trình làm việc | Làm cho chi tiêu có thể được xem xét bởi bộ phận tài chính và kỹ thuật |
Gateway nên thất bại đóng (fail closed) khi vượt quá giới hạn cứng. Nó có thể tóm tắt, yêu cầu giảm phạm vi, đưa vào hàng đợi để con người xem xét, hoặc trả về một lỗi được kiểm soát. Nó không nên âm thầm gửi một prompt lớn hơn, chuyển sang một tuyến đắt tiền hơn, hoặc tiếp tục thử lại.
Sử dụng hình dạng ngân sách này:
budget_policy:
workflow: invoice_reconciliation_agent
owner_key: finance_ops
per_request:
max_input_tokens: 32000
max_output_tokens: 4000
max_model_calls: 4
max_tool_calls: 5
per_session:
max_total_tokens: 90000
max_total_cost_usd: reviewed_threshold
retry:
max_attempts: 2
retryable_statuses: [408, 409, 429, 500, 502, 503, 504]
fallback:
max_fallbacks: 1
require_reason: true
on_over_budget:
action: stop_or_request_scope_reductionĐây là nơi bề mặt sản phẩm công khai của Flatkey trở nên phù hợp. Trang chủ Flatkey hiện tại định vị nền tảng xoay quanh việc truy cập model thống nhất, định tuyến, thanh toán, phân tích sử dụng và các kiểm soát vận hành. Trang giá hiện tại mô tả việc nạp tiền trả trước, phân tích sử dụng, kiểm soát chi phí, log yêu cầu, một hóa đơn duy nhất cho tất cả các nhà cung cấp và các lộ trình mua sắm cho nhóm. Hãy coi đó là bằng chứng lập kế hoạch công khai hiện tại, sau đó chạy thử nghiệm của riêng bạn trong dashboard trước khi đưa vào sản xuất.
Log: ghi lại bằng chứng, không chỉ là các prompt thô
Log của agent cần trả lời hai câu hỏi: điều gì đã xảy ra lúc chạy, và ai có thể chứng minh chính sách đã hoạt động?
Tài liệu về khả năng quan sát của Vercel's AI Gateway mô tả các log của gateway cho chi tiêu, sử dụng model, các chỉ số quan sát, tóm tắt yêu cầu, khóa API và log yêu cầu. Tài liệu về khả năng quan sát của OpenAI's Agents SDK mô tả các dấu vết (traces) có thể bao gồm các lệnh gọi model, lệnh gọi công cụ, chuyển giao, lan can bảo vệ (guardrails) và các khoảng tùy chỉnh (custom spans). Những ví dụ đó chỉ ra cùng một yêu cầu vận hành: các gateway của agent cần các log kết nối hành vi của model với các quyết định về tuyến, công cụ, ngân sách và dừng.
Đối với các kiểm soát của AI agent gateway, hãy ghi lại tối thiểu các trường sau:
| Trường | Ví dụ | Tại sao nó quan trọng |
|---|---|---|
request_id | UUID do gateway tạo | Kết nối các bản ghi của model, công cụ, thanh toán và hỗ trợ |
workflow_class | support_agent, code_agent, finance_agent | Nhóm các chính sách và kiểm thử chấp nhận |
owner_key | nhóm, ứng dụng, khách hàng, môi trường | Hỗ trợ phân bổ chi tiêu và xem xét lạm dụng |
requested_model | bí danh model hoặc tên tuyến | Hiển thị những gì ứng dụng đã yêu cầu |
served_model | nhà cung cấp/model thực tế | Hiển thị những gì gateway đã phục vụ |
tool_calls | tên, phiên bản schema, các đối số đã được biên tập, trạng thái | Chứng minh hành vi của chính sách công cụ |
usage | token đầu vào, đầu ra, suy luận, bộ nhớ đệm, tổng số token | Kết nối hành vi với chi phí |
budget_result | được phép, cảnh báo, bị chặn | Chứng minh cổng chi phí đã chạy |
stop_condition | hoàn thành, số bước tối đa, vượt ngân sách, cần phê duyệt | Giải thích cách lần chạy kết thúc |
fallback_reason | hết thời gian, 429, lỗi nhà cung cấp, cổng chất lượng | Tách biệt việc phục hồi khỏi sự trôi dạt (drift) |
Đừng ghi lại mọi thứ mãi mãi chỉ vì nó dễ dàng. Dữ liệu khách hàng, prompt, kết quả công cụ và các tệp có thể chứa thông tin nhạy cảm. Một thiết kế log bền vững nên xác định việc biên tập, lưu giữ, xem xét truy cập, nhu cầu xuất dữ liệu và các quy trình xử lý sự cố. Gateway nên lưu trữ đủ bằng chứng để gỡ lỗi và đối chiếu việc sử dụng mà không biến mọi yêu cầu thành một kho lưu trữ dữ liệu không kiểm soát.
Điều kiện dừng: xác định điểm kết thúc của lần chạy trước khi model bắt đầu
Điều kiện dừng không chỉ là các chuỗi dừng của model. Chúng là các quy tắc kết thúc một lần chạy của agent một cách an toàn.
Các API của nhà cung cấp hiển thị các bề mặt phản hồi và dừng khác nhau. API Messages của Anthropic hiển thị các trường stop_reason như sử dụng công cụ, kết thúc lượt, số token tối đa và các chuỗi dừng trong tài liệu của họ. Tài liệu về lan can bảo vệ (guardrails) của OpenAI's Agents SDK định hình lan can bảo vệ và việc xem xét của con người như các kiểm soát quyết định khi nào một lần chạy tiếp tục, tạm dừng hoặc dừng lại. Trong môi trường sản xuất, gateway của bạn nên chuẩn hóa các trạng thái cụ thể của nhà cung cấp đó thành một trạng thái quy trình làm việc mà nhóm của bạn hiểu được.
Sử dụng ma trận dừng:
| Điều kiện dừng | Hành động của Gateway | Hành vi đối với người dùng | Bằng chứng yêu cầu |
|---|---|---|---|
| Hoàn thành | Trả về câu trả lời cuối cùng | Phản hồi bình thường | mô hình cuối cùng, mức sử dụng, không có công cụ chưa được giải quyết |
| Yêu cầu phê duyệt công cụ | Tạm dừng | "Hành động này cần được xem xét" | lệnh gọi công cụ, đối số, người phê duyệt, quyết định |
| Vượt ngân sách | Dừng hoặc yêu cầu giảm phạm vi | "Thu hẹp yêu cầu" | trường ngân sách, ngưỡng, khóa chủ sở hữu |
| Đạt số bước tối đa | Dừng | "Không thể hoàn thành trong lần chạy này" | số bước, hành động cuối, tín hiệu lặp |
| Lỗi công cụ | Thử lại, dự phòng, hoặc dừng | Lộ trình thất bại rõ ràng | trạng thái công cụ, loại lỗi, số lần thử lại |
| Nhà cung cấp hết thời gian chờ | Thử lại hoặc dự phòng | Phản hồi bị suy giảm nhưng có kiểm soát | tuyến, thời gian chờ, lý do dự phòng |
| Vi phạm chính sách | Dừng | Từ chối hoặc chuyển cho người | chính sách bị kích hoạt, mẫu đã biên tập |
| Độ tin cậy thấp hoặc thiếu bằng chứng | Hỏi thêm hoặc chuyển cấp | "Cần thêm thông tin" | trường bị thiếu, kết quả đánh giá |
Điểm quan trọng là mỗi trạng thái kết thúc đều có một tên. Nếu các trạng thái duy nhất là "thành công" và "lỗi", các nhóm không thể biết được liệu agent có tuân thủ chính sách hay chỉ đơn giản là dừng lại một cách tình cờ.
Một mẫu kiểm soát AI agent gateway thực tế
Sử dụng một tệp chính sách mà các bộ phận kỹ thuật, bảo mật, tài chính và sản phẩm có thể cùng nhau xem xét:
policy_name: ai_agent_gateway_controls_v1
owner:
team: ai_platform
reviewers:
- engineering
- finance
- security
workflow_classes:
support_agent:
route: balanced_text_tool_route
allowed_tools: [lookup_order, search_policy, open_ticket]
approval_tools: [issue_refund, cancel_subscription]
max_tool_calls: 5
max_model_calls: 4
code_agent:
route: code_review_route
allowed_tools: [read_repo, search_repo, propose_patch]
approval_tools: [apply_patch, run_shell_command]
max_tool_calls: 12
max_model_calls: 8
budget_rules:
require_owner_key: true
block_when_owner_budget_exceeded: true
require_fallback_reason: true
log_rules:
capture_request_id: true
capture_requested_and_served_model: true
capture_tool_call_status: true
redact_sensitive_arguments: true
stop_rules:
max_steps: 12
max_retries_per_tool: 1
on_policy_violation: stop
on_approval_required: pause
acceptance_tests:
- blocked_tool_is_not_executed
- over_budget_request_fails_closed
- approval_tool_pauses_run
- fallback_records_reason
- request_log_contains_usage_and_stop_conditionTệp này không thay thế mã ứng dụng. Nó cung cấp cho mã một hợp đồng để thực thi và cung cấp cho người đánh giá một tạo tác cụ thể để kiểm tra.
Kiểm thử chấp nhận trước khi đưa vào sản xuất
Chạy các kiểm thử chấp nhận đối với từng lớp quy trình công việc trước khi lưu lượng truy cập hoạt động:
- Gửi một yêu cầu bình thường và xác nhận chỉ các công cụ được phép mới được hiển thị.
- Yêu cầu một công cụ bị chặn và xác nhận công cụ đó không được thực thi.
- Yêu cầu một công cụ cần phê duyệt và xác nhận quá trình chạy tạm dừng với trạng thái có thể tiếp tục.
- Gửi một prompt quá lớn và xác nhận gateway dừng lại hoặc yêu cầu giảm phạm vi.
- Kích hoạt lỗi công cụ và xác nhận số lần thử lại, lý do dự phòng và trạng thái cuối cùng được ghi lại.
- Buộc nhà cung cấp hết thời gian chờ và xác nhận phương án dự phòng vẫn nằm trong ngân sách dự phòng.
- Kích hoạt số bước tối đa và xác nhận quá trình chạy không bị lặp.
- Xác nhận log yêu cầu hiển thị khóa chủ sở hữu, mô hình được yêu cầu, mô hình đã phục vụ, mức sử dụng, trạng thái công cụ, kết quả ngân sách và điều kiện dừng.
- Lấy mẫu đối chiếu tài chính từ log yêu cầu đến hóa đơn hoặc biến động số dư trả trước.
- Chạy lại cùng một bài kiểm thử sau khi thay đổi mô hình, công cụ, prompt hoặc chính sách định tuyến.
Kết hợp bài viết này với các hướng dẫn của Flatkey về kiến trúc AI API gateway, kiến trúc LLM API gateway, cân bằng tải và chuyển đổi dự phòng AI API, và thiết kế chính sách định tuyến mô hình. Kiến trúc gateway quyết định nơi đặt các kiểm soát; các kiểm thử chấp nhận chứng minh chúng hoạt động.
Vai trò của Flatkey
Flatkey không nên là nơi duy nhất tồn tại chính sách agent của bạn. Hãy giữ chính sách trong mã nguồn, cấu hình hoặc một kho lưu trữ kiểm soát nội bộ. Sử dụng Flatkey làm bề mặt gateway nơi các nhóm có thể tập trung hóa quyền truy cập mô hình, xem xét định tuyến, khả năng hiển thị mức sử dụng, log yêu cầu, kiểm soát chi phí, số dư trả trước và xem xét thanh toán.
Một quy trình triển khai Flatkey thực tế sẽ như sau:
- Chọn một quy trình công việc của agent với các công cụ và chủ sở hữu đã biết.
- Xác định các công cụ được phép, công cụ cần phê duyệt, mức trần ngân sách, các trường log và điều kiện dừng.
- Kiểm tra các tùy chọn mô hình và giá hiện tại trên bảng giá Flatkey.
- Chạy các kiểm thử chấp nhận với một khóa không dùng cho sản xuất.
- Xem xét log để biết mô hình được yêu cầu, mô hình đã phục vụ, mức sử dụng, quyết định định tuyến, lý do dự phòng và điều kiện dừng.
- Chỉ chuyển quy trình công việc đã được kiểm thử sang môi trường sản xuất.
- Thêm các công cụ mới và các tuyến dự phòng từng dòng chính sách một.
Khi bằng chứng được thông qua, hãy lấy một khóa và giữ cho lần triển khai đầu tiên có phạm vi hẹp. Các kiểm soát AI agent gateway mạnh mẽ nhất là những kiểm soát nhàm chán trong môi trường sản xuất: mọi lệnh gọi công cụ đều có lý do, mọi quyết định về ngân sách đều có dấu vết, mọi thất bại đều có một điều kiện dừng được đặt tên, và mọi người đánh giá đều có thể thấy những gì đã xảy ra.
Câu hỏi thường gặp
Các kiểm soát của AI agent gateway là gì?
Các kiểm soát của AI agent gateway là các chính sách quản lý quyền truy cập công cụ, ngân sách, log, hành vi dự phòng và các điều kiện dừng cho các luồng công việc của agent gọi các mô hình và công cụ thông qua một gateway.
Các kiểm soát của AI agent gateway có giống như định tuyến mô hình không?
Không. Định tuyến mô hình quyết định mô hình hoặc nhà cung cấp nào sẽ phục vụ một yêu cầu. Các kiểm soát của AI agent gateway quyết định liệu agent có thể gọi một công cụ, chi tiêu thêm ngân sách, thử lại, dự phòng, tạm dừng để chờ phê duyệt, hay dừng lại.
Những gì nên được ghi log cho việc sử dụng công cụ của agent?
Ghi log ID yêu cầu, lớp luồng công việc, khóa chủ sở hữu, mô hình được yêu cầu, mô hình đã phục vụ, tên công cụ, phiên bản schema, các đối số đã được biên tập lại, trạng thái kết quả, mức sử dụng, kết quả ngân sách, lý do dự phòng và điều kiện dừng.
Các công cụ nhạy cảm có nên luôn sẵn có cho mô hình không?
Không. Giữ danh mục công cụ đầy đủ tách biệt khỏi danh sách cho phép của luồng công việc. Các công cụ nhạy cảm nên yêu cầu sự phê duyệt, phạm vi hẹp hơn, hoặc một lộ trình leo thang riêng biệt.
Việc vượt ngân sách nên được xử lý như thế nào?
Việc vượt ngân sách cứng nên được xử lý theo cơ chế fail-closed (thất bại an toàn). Gateway có thể yêu cầu giảm phạm vi, tóm tắt, xếp hàng đợi để xem xét, hoặc trả về một lỗi có kiểm soát, nhưng không nên âm thầm chuyển sang một lộ trình tốn kém hơn.
Flatkey giúp ích như thế nào với các kiểm soát của AI agent gateway?
Flatkey cung cấp cho các nhóm một bề mặt gateway duy nhất cho quyền truy cập mô hình, xem xét định tuyến, khả năng hiển thị mức sử dụng, log yêu cầu, kiểm soát chi phí, số dư trả trước và xem xét thanh toán. Sử dụng bề mặt đó cùng với policy-as-code (chính sách dưới dạng mã) và các bài kiểm tra chấp nhận cho các luồng công việc của agent trong môi trường production.
