Agent lên production — playbook dựng orchestration không dựa vào may mắn

Agent lên production — playbook dựng orchestration không dựa vào may mắn

Agent chạy demo thì ai cũng giỏi. Bài này là playbook giúp bạn dựng lớp orchestration và guardrail để agent không biến thành rủi ro khi lên production.

Bao nhiêu lần bạn demo agent cho sếp xong, ai cũng gật gù — rồi tuần sau deploy lên staging, nó gọi sai tool, loop vô hạn, và tốn hết credit API trong một đêm?

Mình đã thấy pattern này lặp lại ở ít nhất ba team Việt Nam trong hai tháng qua. Vấn đề không nằm ở model kém hay prompt tệ. Vấn đề nằm ở chỗ: agent không có ai "giám sát hiện trường" — không orchestration rõ ràng, không guardrail, không cơ chế dừng.

Playbook này giúp bạn dựng đủ lớp điều phối để agent đáng tin trên production, không phải chỉ trên máy dev.

Bài này giải quyết gì

Một hiểu lầm phổ biến: "Agent tự chủ nghĩa là thả nó chạy tự do." Sai. Agent tự chủ (autonomous agent) — hệ thống có khả năng tự quyết định bước tiếp theo — chỉ đáng tin khi có ba thứ đi kèm:

Nếu thiếu một trong ba, bạn đang deploy một "thám tử" ra hiện trường mà không cho họ biết ranh giới vụ án nằm đâu.

Checklist trước khi chạm code

| # | Câu hỏi | Nếu chưa trả lời được → dừng |
|---|---------|-------------------------------|
| 1 | Agent được phép gọi những tool nào? | Whitelist cụ thể, không dùng wildcard |
| 2 | Budget tối đa mỗi lần chạy? | Token limit + API call limit |
| 3 | Khi nào agent phải dừng và hỏi người? | Định nghĩa rõ exit condition |
| 4 | Log lưu ở đâu, format gì? | Structured JSON, không phải print() |
| 5 | Ai review output trước khi action thật? | Human-in-the-loop hay auto-approve? |

Giả sử team bạn 4 người, đang build agent OSINT nội bộ để tự động kiểm tra domain và email khách hàng. Nếu không trả lời được câu 3, agent có thể chạy sherlock trên 300 platform trong khi bạn chỉ cần check 5 platform nội địa — tốn tiền, tốn thời gian, và có thể vi phạm policy.

Bốn bước dựng orchestration layer

Bước 1 — Định nghĩa tool registry có schema

Mỗi tool agent được phép gọi phải có JSON schema mô tả input/output. Đây không phải "nice to have" — đây là cách duy nhất để orchestrator validate trước khi thực thi.

tools = [
    {
        "name": "check_email_breach",
        "description": "Kiểm tra email trong danh sách rò rỉ",
        "input_schema": {
            "type": "object",
            "properties": {"email": {"type": "string"}},
            "required": ["email"]
        }
    }
]

Không có schema → agent có thể truyền bất kỳ input nào → lỗi âm thầm.

Bước 2 — Thêm dispatch loop có ceiling

Tool dispatch loop — vòng lặp nhận quyết định từ model rồi gọi tool tương ứng — cần có hai ceiling:

for i in range(MAX_ITERATIONS):
    response = llm.call(messages, tools=tools)
    if response.stop_reason == "end_turn":
        break
    if total_tokens > TOKEN_BUDGET:
        log_and_halt("Budget exceeded")
        break
    # execute tool, append result

Bước 3 — Structured memory thay vì nhồi context

Nhiều team nhồi toàn bộ kết quả tool vào context window rồi thắc mắc tại sao agent "quên" bước trước. Cách đúng: tách memory thành hai tầng.

Hermes Agent của Nous Research dùng đúng pattern này: snapshot ngắn hạn + FTS5 full-text search cho lịch sử session + skill files cho logic tái sử dụng. Bạn không cần copy y hệt, nhưng nguyên tắc hai tầng là bắt buộc nếu agent chạy quá 5 bước.

Bước 4 — Guardrail layer: rào trước khi sập

Guardrail không phải "thêm sau khi lên production". Nó phải có từ ngày một:

Bẫy mà team nào cũng dẫm ít nhất một lần

Bẫy 1: "Để agent tự quyết hết cho nhanh."

Một team fintech mình biết đã cho agent tự gọi API thanh toán trong môi trường staging mà quên rằng staging đang trỏ vào gateway thật. Kết quả: agent chạy 47 transaction test lên production. Như một thám tử được phát súng thật thay vì súng tập — hiện trường sẽ rất khó dọn.

Bài học: môi trường sandbox phải tách biệt hoàn toàn, và agent không bao giờ được auto-approve action có side effect tài chính.

Bẫy 2: "Model mới nhất chắc tốt nhất."

Không nhất thiết. OpenClaw dùng kiến trúc WebSocket Gateway tối ưu cho reach (phủ nhiều kênh), Hermes Agent tối ưu cho depth (tự học qua mỗi lần chạy). Chọn sai kiến trúc cho use case của bạn thì model xịn cỡ nào cũng không cứu được.

Câu hỏi đúng không phải "model nào mới nhất?" mà là "orchestration pattern nào khớp với workflow của team mình?"

Bẫy 3: Log kiểu print debug.

Khi agent chạy 15 bước rồi ra kết quả sai, bạn cần trace lại từng bước như đọc hồ sơ vụ án. Nếu log chỉ là print(result) thì bạn sẽ mất hàng giờ reconstruct. Dùng structured logging (JSON lines) với mỗi entry chứa: timestamp, tool name, input, output, token count.

Hành động tiếp theo

  1. Chiều nay: mở repo agent hiện tại, kiểm tra xem dispatch loop có ceiling chưa. Nếu chưa → thêm MAX_ITERATIONS và TOKEN_BUDGET.
  2. Trong tuần: viết guardrail layer riêng — tách khỏi logic chính, dễ test độc lập.
  3. Trước khi merge: chạy agent 50 lần với input đa dạng, đếm xem bao nhiêu lần nó vượt ceiling. Con số đó cho bạn biết guardrail đang chặt hay lỏng.

Framework OpenOSINT (MIT license) là reference tốt nếu bạn muốn xem cách một agent Python thực tế tổ chức tool registry + dispatch loop. Hermes Agent cũng open-source (MIT) nếu bạn quan tâm pattern memory ba tầng.

Điều mình muốn bạn mang về: agent không fail vì model ngu — agent fail vì không ai vẽ ranh giới cho nó. Orchestration và guardrail chính là ranh giới đó.

---

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

Nguồn tham khảo