Agent production cần bản vẽ tầng lớp

Multi-agent không đáng tin vì có nhiều agent, mà vì workflow, state và guardrail được vẽ rõ. Đây là playbook mổ lớp trước khi đưa vào production.

“Cho em thêm 3 agent nữa chắc ổn anh ạ.”

Nếu câu này vang lên trong standup, mình thường nghe tiếp tiếng ghế kéo nhẹ của tech lead. Không phải vì multi-agent sai. Mà vì nhiều team đang coi agent như thêm người vào công trường: thấy chậm thì gọi thêm thợ, nhưng bản vẽ chưa có, giàn giáo chưa dựng, đường điện nước chưa chốt.

Luận điểm của mình hôm nay hơi khô nhưng cứu ví tiền: hệ thống agent chỉ đáng tin khi orchestration và guardrail rõ ràng; số lượng agent không phải bằng chứng của độ thông minh.

Nói thẳng ra thì, sau bài này bạn nên đổi một cách nghĩ: đừng hỏi “nên dùng framework nào để build multi-agent?”, hãy hỏi “workflow này cần những lớp kiểm soát nào trước khi framework trở nên đáng tiền?”.

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

Mục tiêu: mổ hệ thống agent theo lớp, không theo logo

Một tutorial build multi-agent bằng Python thuần rồi chuyển sang LangGraph rất đáng xem vì nó đặt đúng câu hỏi: không framework thì bạn thật sự cần bao nhiêu code, có framework thì bạn mua được điều gì?

Với builder, câu trả lời không nằm ở “LangGraph tốt hơn Python thuần” hay ngược lại. Câu trả lời nằm ở mức độ production của bài toán.

• Python thuần cho bạn thấy lõi của multi-agent: nhiều prompt chuyên trách, truyền kết quả qua từng bước.
• LangGraph cho bạn nodes, edges và shared state — tức là cách biểu diễn workflow có trạng thái, có nhánh, có điểm dừng.
• Strands Agents / Bedrock AgentCore trong case social intelligence cho thấy một tầng khác: orchestration chạy trên cloud, có governance, scoring, phân vai theo nguồn dữ liệu.
• Câu chuyện agentic ransomware thì nhắc rất đau: ngay cả khi agent tự chạy phần kỹ thuật, con người vẫn có thể là người dựng hạ tầng, chọn mục tiêu, cấp credential.

Orchestration ở đây nghĩa là cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc. Trong production, orchestration không phải lớp trang trí. Nó là khung kèo chịu lực.

Checklist trước khi thêm agent thứ hai

Trước khi split một prompt thành 3 agent, thử trả lời 7 câu này. Nếu câu trả lời còn mơ hồ, thêm agent chỉ làm hệ thống khó debug hơn.

| Câu hỏi | Nếu chưa trả lời được thì sao? |
|---|---|
| Agent này chịu trách nhiệm đúng một việc gì? | Prompt sẽ phình ra, lỗi khó quy trách nhiệm |
| Input/output của agent có schema không? | Kết quả bước sau dễ vỡ vì nhận text lỏng lẻo |
| State nào được chia sẻ? | Agent có thể dùng dữ liệu cũ, thiếu hoặc sai ngữ cảnh |
| Ai được gọi tool nào? | Một agent “hiền” vẫn có thể làm việc nguy hiểm nếu tool mở quá rộng |
| Điểm dừng ở đâu? | Workflow dễ loop, retry vô tội vạ hoặc tốn tài nguyên |
| Khi agent bất đồng, ai quyết? | Kết quả cuối có thể là trung bình cộng của sự lẫn lộn |
| Có log đủ để replay không? | Production incident sẽ biến thành buổi bói toán |

Guardrail là lớp rào kiểm soát hành vi: giới hạn quyền gọi tool, kiểm tra dữ liệu vào/ra, chặn hành động nguy hiểm, hoặc yêu cầu human approval ở bước nhạy cảm.

Hình dung thế này: bạn build agent nghiên cứu lead bán hàng. Một agent đọc Reddit, một agent xem GitHub, một agent kiểm tra Hacker News, rồi agent tổng hợp viết email. Nghe hợp lý. Nhưng nếu không có schema cho “tín hiệu mua hàng”, agent tổng hợp sẽ trộn lẫn “repo tăng sao” với “người dùng than phiền” như cùng một mức intent. Production không chết vì model ngu; nó chết vì tín hiệu không được chuẩn hóa.

Bước 1: dựng bản Python thuần để thấy móng

Đừng bắt đầu bằng framework nếu team chưa hiểu workflow tối thiểu. Một bản Python thuần giúp bạn nhìn rõ: agent nào nhận gì, trả gì, và lỗi nằm ở đâu.

Ví dụ minh họa:

from typing import TypedDict, Literal

class AgentResult(TypedDict):
    role: str
    status: Literal["ok", "needs_review", "failed"]
    summary: str
    evidence: list[str]


def researcher(task: str) -> AgentResult:
    return {
        "role": "researcher",
        "status": "ok",
        "summary": "Tìm thấy 3 tín hiệu liên quan đến nhu cầu tích hợp AI.",
        "evidence": ["github_issue", "forum_thread", "pricing_page_change"],
    }


def analyst(result: AgentResult) -> AgentResult:
    if not result["evidence"]:
        return {"role": "analyst", "status": "needs_review", "summary": "Thiếu bằng chứng", "evidence": []}
    return {
        "role": "analyst",
        "status": "ok",
        "summary": "Lead có intent vừa, chưa nên auto-send email.",
        "evidence": result["evidence"],
    }

Điểm quan trọng không phải đoạn code này “xịn”. Điểm quan trọng là bạn ép mỗi agent trả về schema — khuôn dữ liệu có cấu trúc. Khi có schema, bạn mới viết test, log, retry, dashboard được.

Nếu bản Python thuần đã rối, đưa vào framework chỉ là đổ bê tông lên nền chưa nén.

Bước 2: chuyển sang graph khi workflow bắt đầu có nhánh

Khi workflow có điều kiện kiểu “nếu thiếu bằng chứng thì quay lại research”, “nếu confidence thấp thì yêu cầu review”, “nếu tool lỗi thì fallback”, graph bắt đầu đáng tiền.

Trong LangGraph, bạn có thể nghĩ theo ba khái niệm:

• Node: một bước xử lý, ví dụ research, score, draft_email.
• Edge: đường chuyển giữa các bước, có thể cố định hoặc theo điều kiện.
• Shared state: trạng thái chung được truyền qua workflow, ví dụ danh sách evidence, điểm confidence, lịch sử lỗi.

Một khung tối giản:

from typing import TypedDict, List, Literal

class LeadState(TypedDict):
    query: str
    evidence: List[str]
    score: int
    decision: Literal["continue", "review", "stop"]


def route_after_score(state: LeadState) -> str:
    if state["score"] >= 80:
        return "draft"
    if state["score"] >= 50:
        return "human_review"
    return "stop"

Ở đây, graph không làm model thông minh hơn. Nó làm workflow nhìn thấy được. Builder có thể chỉ vào bản vẽ và nói: “Lỗi nằm ở node score, không phải ở draft.” Đó là khác biệt rất lớn khi incident xảy ra lúc 11 giờ đêm.

Bước 3: thêm guardrail theo quyền, không theo niềm tin

Pitfall phổ biến: vì agent chỉ “viết email” nên team cho nó đọc mọi nguồn, gọi mọi tool, thậm chí ghi thẳng vào CRM. Đây là chỗ câu chuyện agentic ransomware đáng để lạnh gáy. Agent có thể tự thực hiện nhiều bước kỹ thuật, nhưng ai đó vẫn có thể chuẩn bị hạ tầng, credential và mục tiêu cho nó. Vậy vấn đề production không chỉ là “model có tự làm không”, mà là ai cấp quyền cho workflow làm gì.

Một policy đơn giản nên có dạng allowlist:

agents:
  researcher:
    can_call:
      - search_public_sources
      - read_github_metadata
    cannot_call:
      - send_email
      - write_crm

  analyst:
    can_call:
      - score_lead
    requires_input:
      - evidence

  outreach_writer:
    can_call:
      - draft_email
    requires_human_approval_for:
      - send_email
      - update_crm_stage

Đừng để guardrail chỉ nằm trong prompt kiểu “hãy cẩn thận”. Prompt là lời nhắc dán trên tường; policy enforcement mới là ổ khóa cửa.

Với team Việt Nam quy mô nhỏ, mình sẽ ưu tiên 3 guardrail trước:

1. Tool allowlist theo agent: agent nào được gọi tool nào, không dùng chung một bộ quyền.
2. Human approval ở hành động có tác động ngoài hệ thống: gửi email, ghi database, xóa file, đổi trạng thái deal.
3. Audit log có thể replay: lưu input, output, tool call, version prompt, model, thời điểm chạy.

Bước 4: đo hệ thống bằng failure mode, không chỉ demo path

Demo path là luồng đẹp: input sạch, model hiểu đúng, tool trả kết quả, email nhìn ổn. Production path thì hay gặp mấy ca này:

• Nguồn A trả dữ liệu thiếu, nguồn B trả trùng, agent tổng hợp tưởng là hai tín hiệu độc lập.
• Model local nhỏ hơn xử lý prompt dài kém ổn định hơn, nhất là khi một prompt phải ôm quá nhiều trách nhiệm.
• Agent retry cùng một tool lỗi 5 lần nhưng không đổi chiến lược.
• State bị ghi đè, bước sau dùng nhầm evidence của lead trước.
• Human review có nhưng reviewer không thấy đủ context để quyết.

Bạn không cần benchmark hoành tráng ngay. Trong một buổi, hãy tạo 10 test case thủ công:

• 3 case dữ liệu sạch.
• 3 case thiếu dữ liệu.
• 2 case dữ liệu mâu thuẫn.
• 1 case tool timeout.
• 1 case yêu cầu hành động nhạy cảm.

Mỗi case chỉ cần ghi: expected route, expected decision, allowed tools, log cần có. Nếu graph đi sai route, sửa orchestration trước khi đổ lỗi cho model.

Nếu là mình, mình sẽ chọn đường này

Với một team đang build hệ thống agent thật, mình không bắt đầu bằng “framework nào hot”. Mình sẽ đi theo thứ tự:

1. Python thuần cho workflow tối thiểu: chứng minh phân vai agent có ích thật, không chỉ tách prompt cho vui.
2. Graph khi có nhánh và state: dùng LangGraph hoặc framework tương tự khi cần route, retry, checkpoint, quan sát luồng chạy.
3. Cloud orchestration khi bài toán có governance: nhiều nguồn dữ liệu, nhiều quyền truy cập, nhiều người vận hành, cần kiểm soát chi phí và audit.
4. Guardrail trước automation toàn phần: hành động càng gần production data hoặc khách hàng thật, càng cần approval và policy cứng.

Điều đáng giữ từ làn sóng multi-agent không phải cảm giác “AI team tự chạy”. Điều đáng giữ là cách chia một bài toán lớn thành các bước có trách nhiệm, có state, có quyền hạn, có điểm dừng.

Còn điều dễ bị thổi quá mức là niềm tin rằng cứ thêm agent thì hệ thống sẽ tự thông minh lên. Nhà cao không vững vì có nhiều phòng; nó vững vì móng, khung và đường chịu lực được tính trước.

Chốt gọn: agent production không cần đông như đội thi công ngày bàn giao; nó cần bản vẽ đủ rõ để khi tường nứt, bạn biết phải đập chỗ nào.

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