Agent production: đừng giao quyền trước khi dựng quầy

Agent production: đừng giao quyền trước khi dựng quầy

Một playbook cho team builder: thử agent trong một buổi, đặt guardrail, đo failure mode, rồi mới quyết định scale hay dừng.

Bạn có dám cho một agent tự điều tra giao dịch bất thường, gọi tool nội bộ, ghi báo cáo, rồi đề xuất hành động tiếp theo mà không có ai nhìn qua không?

Nếu câu trả lời là “còn tùy”, chúc mừng, bạn vẫn còn phản xạ sinh tồn của người vận hành hệ thống.

Mấy tuần này mình thấy nhiều team nói về agent theo kiểu: model mới mạnh hơn, framework mới nhiều node hơn, CLI chạy được non-interactive rồi, MCP đổi spec rồi, vậy chắc cứ nối tool vào là thành automation. Nhưng triển khai production không giống pha một ly cold brew để chụp ảnh. Nó giống mở quầy lúc đông khách: ai nhận order, ai pha, ai kiểm bill, ai được phép chạm vào máy POS — thiếu một vai là loạn.

Luận điểm của mình: agent chỉ đáng tin khi orchestration và guardrail được thiết kế trước quyền tự chủ. Đừng hỏi “agent này thông minh không?” trước. Hỏi “khi nó sai, hệ thống dừng ở đâu?” đã.

Sơ đồ minh họa cho bài Agent production: đừng giao quyền trước khi dựng quầy

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu của buổi thử: không phải làm demo, mà bắt lỗi vận hành

Playbook này dành cho team builder muốn thử agent workflow trong một buổi chiều, không phải dựng nguyên nền tảng enterprise.

Ta lấy cảm hứng từ một pattern đang rõ dần: dùng orchestration — lớp điều phối nhiều bước, nhiều tool, nhiều agent — để chia việc; dùng agent reasoning ở từng node; rồi bọc bằng persistence, checkpoint, human review và observability.

Trong bài về market surveillance, AWS mô tả cách ghép LangGraph cho workflow cấp cao với Strands cho reasoning ở từng node, chạy trên AgentCore. Điểm đáng học không nằm ở tên framework. Điểm đáng học là cách họ tách vai:

Dịch sang tiếng người: đừng để một bartender vừa nhận order, tự pha, tự thu tiền, tự sửa menu, rồi tự khóa cửa quán.

Checklist trước khi cho agent gọi tool thật

Trước khi viết prompt dài ba trang, team nên trả lời 7 câu này. Nếu câu nào mù mờ, agent chưa nên chạm production.

1. Task có ranh giới rõ chưa?
Ví dụ: “phân tích giao dịch đáng ngờ và tạo draft báo cáo” rõ hơn nhiều so với “giám sát thị trường”.

2. State nằm ở đâu?
State là trạng thái trung gian của workflow: dữ liệu đầu vào, kết quả từng bước, quyết định đã qua. Nếu state chỉ nằm trong chat history, bạn đang đặt log vận hành vào trí nhớ ngắn hạn của model.

3. Có checkpoint không?
Checkpoint là điểm lưu để quay lại khi lỗi. Nếu agent xử lý 8 bước và chết ở bước 7, bạn muốn chạy lại từ đầu hay phục hồi từ bước 6?

4. Tool nào là read-only, tool nào có side effect?
Tool đọc dữ liệu khác hoàn toàn tool gửi email, tạo ticket, cập nhật DB, hay xoá file. Quyền phải chia tầng.

5. Điểm nào bắt buộc human-in-the-loop?
Human-in-the-loop là chốt duyệt của người thật trong workflow. Không phải vì mình thiếu tin AI, mà vì có những hành động nếu sai thì hậu quả vượt quá tiền gọi API.

6. Log có đủ để điều tra không?
Observability là khả năng nhìn lại hệ thống đã chạy thế nào. Với agent, log nên có prompt version, tool call, input/output đã redact, quyết định route, lỗi, latency, cost tương đối.

7. Tiêu chí dừng là gì?
Không có stop condition thì mọi thử nghiệm đều có xu hướng biến thành “thử thêm chút nữa”. Và chút nữa thường là nơi hóa đơn cloud bắt đầu nhăn mặt.

Thử trong một buổi: workflow 4 node, quyền tối thiểu

Ví dụ cụ thể: giả sử team bạn muốn làm agent hỗ trợ kiểm tra incident trong repo nội bộ. Mục tiêu không phải để agent tự fix mọi thứ, mà để tạo bản điều tra có chứng cứ.

Thiết kế thử nhỏ:

[Ingest] -> [Investigate] -> [Draft] -> [Review]

Node 1: Ingest
Nhận ticket, log snippet, commit range, tài liệu liên quan. Node này không gọi model phức tạp cũng được. Việc chính là chuẩn hóa input.

Output nên có dạng có cấu trúc:

{
  "ticket_id": "INC-123",
  "scope": ["service-a", "service-b"],
  "time_window": "example-only",
  "allowed_tools": ["read_logs", "search_repo"]
}

Node 2: Investigate
Agent được phép gọi tool read-only: search repo, đọc log, xem runbook. Cấm ghi file, cấm mở PR, cấm gọi endpoint có side effect.

Nếu dùng CLI agent non-interactive như các workflow Kimi CLI mô tả, hãy bật output dạng JSONL streaming — mỗi dòng là một event JSON — để máy đọc được từng bước agent đang làm. Không chỉ xem final answer.

Node 3: Draft
Agent tạo báo cáo gồm: giả thuyết, chứng cứ, file/log liên quan, mức tự tin, câu hỏi còn thiếu. Tuyệt đối tách “suy đoán” khỏi “đã kiểm chứng”.

Node 4: Review
Người thật duyệt. Nếu muốn agent đề xuất action, action chỉ ở dạng draft: “nên rollback commit X” hoặc “nên thêm alert Y”, chưa tự thực thi.

Một cấu hình thử nghiệm đơn giản có thể như sau:

agent_trial:
  max_steps: 12
  tool_policy:
    read_logs: allow
    search_repo: allow
    create_pr: deny
    deploy: deny
  review_required:
    - external_message
    - code_change
    - production_action
  stop_on:
    - missing_evidence
    - tool_error_repeated
    - scope_expansion_detected

Điểm quan trọng: max_steps không phải để tiết kiệm token cho đẹp. Nó là dây chặn khi agent bắt đầu đi vòng vòng.

Guardrail không chỉ là filter độc hại

Nhiều team nghe “guardrail” là nghĩ tới chặn từ nhạy cảm hoặc policy safety. Với agent production, guardrail rộng hơn: luật vận hành giới hạn agent được làm gì, khi nào phải dừng, và bằng chứng nào đủ để đi tiếp.

Hình dung thế này: quầy pha có menu, định lượng, khu vực nhân viên, camera, và ca trưởng. Không ai gọi mấy thứ đó là “làm giảm sáng tạo của bartender”. Đó là lý do ly thứ 200 trong ngày vẫn uống được.

Một bộ guardrail tối thiểu nên có 5 lớp:

| Lớp | Câu hỏi cần trả lời | Ví dụ |
|---|---|---|
| Scope | Agent được xử lý phạm vi nào? | Chỉ repo A, không quét toàn org |
| Tool permission | Tool nào được gọi? | Read-only trước, write sau khi duyệt |
| Evidence | Khi nào kết luận hợp lệ? | Phải dẫn log/file/trace cụ thể |
| Escalation | Khi nào gọi người? | Thiếu dữ liệu, tác động production, nghi ngờ security |
| Recovery | Hỏng thì quay lại đâu? | Checkpoint sau mỗi node |

Nguồn về incident agent intrusion của Hugging Face là lời nhắc khá lạnh gáy: agent có thể tối ưu mục tiêu theo cách vượt khỏi ý định ban đầu, nhất là khi môi trường và reward khiến nó suy luận “đi tìm câu trả lời ở chỗ khác”. Đây không phải chuyện agent “ác”. Đây là chuyện objective, quyền truy cập và boundary bị lệch nhau.

Vậy nên với builder, câu hỏi đúng không phải “model có ngoan không?” mà là: nếu model suy luận sai nhưng rất quyết tâm, hệ thống có khóa cửa nào không?

MCP mới: tốt cho gateway, không thay thế thiết kế quyền

MCP — Model Context Protocol, giao thức để agent kết nối tool/context theo cách chuẩn hơn — đang đi về hướng stateless trên HTTP. Stateless nghĩa là mỗi request không phụ thuộc vào session server giữ sẵn, giúp scale và vận hành quen thuộc hơn với hạ tầng web.

Đây là tín hiệu tốt cho production: gateway dễ quản trị hơn, versioning rõ hơn, authorization gần enterprise hơn. Nhưng MCP không tự quyết định tool nào nên mở cho agent. Gateway giống quầy order gọn gàng hơn; còn menu nào bán, ai được gọi món đặc biệt, món nào cần quản lý duyệt — vẫn là việc của bạn.

Nếu team bạn đang có nhiều tool nội bộ, hãy bắt đầu bằng policy matrix:

Tool              Risk        Default     Requires review
search_docs       low         allow       no
read_logs         medium      allow       no, if scoped
create_ticket     medium      allow       yes for external team
create_pr         high        deny        yes
deploy_service    critical    deny        always
rotate_secret     critical    deny        always

Sau đó mới bàn tới framework.

Dấu hiệu nên scale, và dấu hiệu nên dừng

Sau một buổi thử, đừng hỏi “agent trả lời hay không?”. Hỏi các câu vận hành này:

Nên scale khi:

Nên dừng hoặc thu hẹp khi:

Có một dấu hiệu mình đặc biệt để ý: nếu team phải nói “lần sau chắc nó sẽ hiểu” quá nhiều, workflow đang thiếu constraint. Agent không cần được mắng yêu. Agent cần đường ray.

Sau bài này, nên nghĩ khác điều gì?

Đừng xem agent production là bài toán chọn model hay chọn framework trước. Hãy xem nó là bài toán thiết kế quyền tự chủ có kiểm soát.

Trong một buổi chiều, bạn có thể dựng workflow 4 node, chỉ mở tool read-only, log bằng JSONL/event stream, đặt checkpoint, bắt human review ở action nguy hiểm, rồi đo xem agent có giảm tải thật không. Nếu không qua được vòng này, chưa cần scale. Nếu qua, bạn có cơ sở để mở thêm quyền từng nấc.

Agent giỏi là chuyện tốt. Nhưng agent biết dừng đúng chỗ mới là thứ giúp team ngủ được. Quầy pha đông khách không sợ người pha nhanh; chỉ sợ người pha nhanh mà tự ý đổi công thức, thu tiền, rồi khóa luôn máy tính tiền.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo