⚙️Đào sâu kỹ thuật triển khai AI Agent: Mẫu thiết kế đưa LLM orchestration, thực thi tool và governance lên “chất lượng production”

1. Executive Summary（Tóm tắt kỹ thuật・300 ký tự）

AI agent là phần mềm lấy LLM làm lõi, vận hành vòng lặp “Lập kế hoạch (Plan) → Hành động (Act) → Quan sát (Observe) → Phản tư/Học hỏi (Reflect)”, đồng thời gọi các tool/API bên ngoài để tự chủ hoàn thành tác vụ. Trong khi RPA/IA mạnh về “tự động hóa theo quy trình”, agent có thể xử lý khám phá, rẽ nhánh và ngoại lệ dưới điều kiện bất định. Tuy nhiên khi triển khai production, các nút thắt thường là: chạy quá đà (thực thi quá mức, phình chi phí), vượt quyền, rò rỉ dữ liệu và thiếu khả năng tái lập. Bài viết này đưa ra thiết kế sandbox cho tool execution, quản lý trạng thái, chỉ số đánh giá, audit log và tự chủ hóa theo từng giai đoạn, kèm phiên bản/cấu hình cụ thể.📊

2. Bối cảnh kỹ thuật và thách thức（Giải thích sơ đồ kiến trúc, các vấn đề hiện hữu）

a group of people standing next to each other

Như các bài tham khảo chỉ ra, dù 2025 được gọi là “năm đầu tiên của AI agent”, thách thức thiết kế ở hiện trường không nằm ở “hiểu khái niệm” mà quy về “kiến trúc có thể vận hành được”. GenAI truyền thống (chat) về cơ bản kết thúc ở suy luận một lần, còn AI agent có trạng thái (state) và tác động bên ngoài (side effect). Đây cũng là vùng “dễ xảy ra sự cố” giống RPA/IA, và chỉ guardrail cho LLM là chưa đủ.

Sơ đồ luồng kỹ thuật (mô tả bằng lời): Yêu cầu người dùng được ① tiếp nhận tại API Gateway → ② Policy/Prompt Router xác định use case, quyền hạn, phân loại dữ liệu → ③ Planner (LLM) phân rã tác vụ → ④ Tool Router chọn tool đã được cho phép → ⑤ Sandbox Executor (browser/CLI/HTTP) thực thi → ⑥ Observation Collector thu thập kết quả và bằng chứng → ⑦ Verifier (rule/LLM/test) kiểm chứng tính hợp lệ → ⑧ State Store lưu bền trạng thái → ⑨ nếu cần thì lập kế hoạch lại, nếu hoàn tất thì ghi vào audit log—tạo thành một vòng lặp khép kín.

Các vấn đề hiện hữu：

🔧 Gọi tool “quá tự do”: phát sinh side effect như gửi nhầm, đặt hàng trùng, đặt lịch hàng loạt
⚙️ Quản lý trạng thái mơ hồ: retry sau khi lỗi có thể thực thi lại cùng thao tác, gây cập nhật trùng
📊 Khó đánh giá: với nghiệp vụ không có nhãn đúng/sai, cách chuyển chất lượng thành SLO còn thiếu chuẩn
🔐 Bảo mật: xử lý PII/dữ liệu mật, truy cập vượt quyền, prompt injection
💸 Chi phí: khám phá tự chủ làm token và phí API bên ngoài tăng theo cấp số nhân

3. Phần kỹ thuật 1：Kiến trúc tham chiếu cho agent（Tách Plan/Act/Observe）⚙️

3.1 Tách thành phần：Planner / Executor / Verifier

Trong production, không nên biến “LLM = làm tất cả”. Planner tập trung vào suy luận (phân rã, ưu tiên, điều kiện dừng), Executor thực thi các thao tác có side effect theo cách deterministic, còn Verifier dùng rule/test/LLM dự phòng để kiểm chứng kết quả. Cách này giúp “đóng gói” đầu ra mang tính xác suất của LLM tại các “ranh giới” hệ thống.

3.2 Mô hình trạng thái：Run / Step / Artifact

Thực thi agent được chia thành Run (1 yêu cầu) → Step (1 lần thực thi tool) → Artifact (sản phẩm tạo ra/bằng chứng). Đặc biệt, bắt buộc Step phải có idempotency_key để retry không gây trùng side effect.

3.3 Ví dụ stack tham chiếu（cố định phiên bản）

LLM: GPT-4.1 / GPT-4.1-mini（ví dụ）
Orchestration: LangGraph 0.2.x hoặc Semantic Kernel 1.2.x
Vector DB: pgvector 0.7 + PostgreSQL 16
Cache/Queue: Redis 7.2 / Kafka 3.7
Observability: OpenTelemetry Collector 0.96 + Prometheus 2.51 + Grafana 10.4
Runtime: Python 3.12 + FastAPI 0.110
Sandbox: Playwright 1.49（tự động hóa trình duyệt） + gVisor（cách ly container）

4. Phần kỹ thuật 2：Thiết kế thực thi tool (Tool Use)—“type hóa an toàn” cho function calling 🔧

4.1 Ràng buộc tham số nghiêm ngặt bằng JSON Schema

Tham số tool không nên là văn bản tự nhiên, mà phải cố định kiểu/phạm vi/tập giá trị bằng JSON Schema. Dù parse được output của LLM, nếu miền giá trị quá tự do thì rất dễ gây sự cố. Ví dụ: giới hạn mức chuyển tiền, giới hạn domain người nhận email, độ dài truy vấn tìm kiếm… đều nên được “khóa” bằng schema.

{
  "name": "create_purchase_order",
  "description": "Create PO in ERP (dry-run supported)",
  "parameters": {
    "type": "object",
    "required": ["supplier_id", "items", "dry_run", "idempotency_key"],
    "properties": {
      "supplier_id": {"type": "string", "pattern": "^SUP-[0-9]{6}$"},
      "items": {
        "type": "array",
        "minItems": 1,
        "maxItems": 20,
        "items": {
          "type": "object",
          "required": ["sku", "qty"],
          "properties": {
            "sku": {"type": "string", "pattern": "^[A-Z0-9-]{3,32}$"},
            "qty": {"type": "integer", "minimum": 1, "maximum": 1000}
          }
        }
      },
      "dry_run": {"type": "boolean"},
      "idempotency_key": {"type": "string", "minLength": 16, "maxLength": 64}
    }
  }
}

4.2 Commit hai bước（dry-run → confirm）

“Tự chủ hóa” nên tăng dần theo giai đoạn: ban đầu chạy dry-run để hiển thị chênh lệch, sau đó mới commit sau khi có phê duyệt của con người (HITL) hoặc phê duyệt theo policy. Mang “văn hóa thao tác xác nhận” của RPA/IA vào agent là hướng tiếp cận thực tế.

def execute_po(tool_args, policy):
    # 1) validate schema
    validate_jsonschema(tool_args)

    # 2) enforce policy
    if tool_args["dry_run"] is False and not policy.can_commit_po:
        raise PermissionError("commit not allowed")

    # 3) idempotency
    if store.exists(tool_args["idempotency_key"]):
        return store.get(tool_args["idempotency_key"])

    # 4) call ERP
    result = erp.create_po(**tool_args)
    store.put(tool_args["idempotency_key"], result)
    return result

4.3 Các giới hạn cần có cho thao tác trình duyệt (nhóm Operator)

Tự động hóa trình duyệt linh hoạt nhưng mong manh khi DOM thay đổi. Nếu triển khai bằng Playwright…, tối thiểu cần: (1) allowlist domain được phép thao tác, (2) giới hạn click/submit (ví dụ: tối đa 20 thao tác cho mỗi run), (3) cấm đính kèm file, (4) thông tin xác thực đi qua Vault bằng token ngắn hạn.

5. Phần kỹ thuật 3：Memory và bơm tri thức (RAG + State)—ranh giới triển khai “ghi nhớ” 🧠

5.1 Memory hội thoại vs memory tác vụ vs tri thức tổ chức

Khái niệm “học liên tục” của agent rất dễ bị hiểu sai. Ở mức triển khai, cần tách: (a) log hội thoại (ngắn hạn), (b) trạng thái Run (trung hạn: ToDo/tiến độ/ràng buộc), (c) tài liệu làm nguồn RAG (dài hạn: quy định/thiết kế). Nếu “nhồi tất cả vào LLM” sẽ tăng rủi ro rò rỉ và chi phí.

5.2 Ví dụ cấu hình tối thiểu với pgvector + PostgreSQL 16

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE rag_chunks (
  id bigserial PRIMARY KEY,
  doc_id text NOT NULL,
  chunk_no int NOT NULL,
  content text NOT NULL,
  embedding vector(1536) NOT NULL,
  data_class text NOT NULL DEFAULT 'internal',
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX rag_chunks_ivfflat
  ON rag_chunks USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 200);

Gợi ý giá trị cấu hình: lists=200 là điểm khởi đầu cho quy mô trung bình (tới vài triệu chunk). Khi truy vấn, bắt đầu từ SET ivfflat.probes=10; rồi cân bằng trade-off giữa recall và latency.

5.3 Áp dụng “phân loại dữ liệu” cho tài liệu truy xuất trước cả prompt

RAG rất hữu ích nhưng có rủi ro đưa nhầm tài liệu mật. Trước khi search, hãy lọc doc_id/data_class bằng ABAC (Attribute-Based Access Control), loại bỏ ngay ở tầng trước khi đưa vào LLM. Chỉ dựa vào prompt kiểu “đừng tiết lộ thông tin mật” không phải là kiểm soát.

6. Phần kỹ thuật 4：Đánh giá và benchmark—đưa agent vào SLO 📊

6.1 Thiết kế chỉ số：chỉ “tỷ lệ thành công” là chưa đủ

Trong production, nên theo dõi: (1) tỷ lệ hoàn thành tác vụ, (2) tỷ lệ làm lại (tỷ lệ con người phải sửa), (3) số lần gọi API bên ngoài, (4) chi phí (token + phí bên ngoài), (5) tỷ lệ tool thất bại, (6) vi phạm an toàn (số lần bị policy chặn). Đặc biệt, “vi phạm an toàn = 0” có thể chỉ là hệ thống không làm gì; vì vậy cần giám sát cùng với tỷ lệ thành công.

6.2 Ví dụ benchmark（tự động hóa helpdesk nội bộ）

Cấu hình	Độ trễ trung bình (P50)	Độ trễ trung bình (P95)	Tỷ lệ thành công	Số lần gọi tool trung bình	Chi phí ước tính/Run
Chat (chỉ RAG)	1.8s	4.9s	71%	0.0	$0.006
Agent đơn (Plan+Tool)	6.4s	22.0s	84%	2.7	$0.028
Multi-agent (tách Planner/Verifier)	7.9s	24.5s	90%	3.1	$0.041

Hàm ý: tỷ lệ thành công tăng, nhưng P95 và chi phí chắc chắn xấu đi. Do đó, “chọn nghiệp vụ nào để agent hóa” cần dựa trên mức chấp nhận độ trễ và giá trị của side effect. Nếu nhắm “tự động hóa tất cả” theo kiểu RPA/IA thì rất dễ vỡ trận.

6.3 Regression test：Golden Run và mock tool

Agent là phi quyết định, nên hướng test thực tế là: (1) cố định LLM (temperature=0, top_p=1.0), (2) ghi/phát lại tool call theo kiểu VCR, (3) kiểm chứng sai khác của đầu ra cuối. Khi cập nhật model, ưu tiên “sai khác về side effect” hơn là chỉ nhìn “tỷ lệ thành công”.

7. Phần kỹ thuật 5：Bảo mật—từ prompt injection đến vượt quyền 🔐

7.1 Threat model：LLM tin vào đầu vào

Prompt injection như chèn vào web/email các câu “hãy gửi dữ liệu mật”, “hãy bấm URL này” sẽ bộc lộ rõ ở agent thao tác trình duyệt. Biện pháp không phải “hãy cẩn thận”, mà cần phòng thủ nhiều lớp: (a) tối thiểu hóa quyền tool, (b) gắn nhãn đầu vào bên ngoài là dữ liệu không tin cậy, (c) thao tác quan trọng dùng commit hai bước, (d) kiểm tra đầu ra bằng DLP.

7.2 Thiết kế quyền：OAuth scope + credential ngắn hạn

Không cấp API key dài hạn cho agent. Ví dụ: Google/Microsoft/API nội bộ dùng OAuth 2.1 với scope tối thiểu, TTL token khoảng 15 phút, Refresh quản lý phía server. Trên Kubernetes, dùng IRSA/Workload Identity (phụ thuộc cloud) để gán quyền cho Pod, tránh đặt Secrets trực tiếp.

7.3 Audit log：ai, làm gì, vì sao đã thực thi

Thứ cần cho audit không phải “toàn văn output của LLM”, mà là điểm quyết định (có/không phê duyệt, tool được chọn, tham số, tài nguyên mục tiêu, kết quả, idempotency_key, thời điểm thực thi, người thực thi). Log hội thoại có thể lẫn PII nên tách tuyến riêng (mã hóa, rút ngắn thời gian lưu).

8. Phần kỹ thuật 6：Khả năng mở rộng—nút thắt không nằm ở “số agent” mà ở “side effect” 📈

8.1 Mô hình chạy song song：Queue + Concurrency Cap

Vì agent gọi API/UI bên ngoài, hệ thống thường bị giới hạn bởi I/O bên ngoài hơn là CPU. Phân phối Run bằng Kafka/Redis Queue, đồng thời giới hạn concurrency theo từng tool (ví dụ: ERP max=5, gửi email max=20). Phía LLM cũng có giới hạn RPM/TPM, nên cần throttling theo token budget.

8.2 Ví dụ cấu hình rate control（YAML）

rateLimits:
  llm:
    provider: openai
    requests_per_minute: 300
    tokens_per_minute: 200000
  tools:
    erp_api:
      concurrency: 5
      retry:
        max_attempts: 3
        backoff_ms: [200, 800, 2000]
    email_send:
      concurrency: 20
      daily_cap: 2000
      allow_domains: ["example.co.jp"]

8.3 Thiết kế state store：nghiêng về event sourcing

Nếu tích lũy Run/Step/Artifact như các event, việc resume giữa chừng và audit sẽ dễ hơn. Đặc biệt với multi-agent, khả năng truy vết quyết định theo dòng thời gian là rất quan trọng. Dùng RDB là đủ, nhưng nếu dồn vào một bảng đơn kiểu “update liên tục” thì vận hành thực tế dễ đổ vỡ.

9. Phần kỹ thuật 7：Tích hợp với RPA/IA—không phải thay thế mà là “tách trách nhiệm” 🧩

9.1 Phân vai：agent quyết định, RPA thực thi

Như bài tham khảo 2 mô tả IA (AI ra lệnh cho RPA), nếu thiết kế chặt chẽ hơn thì mô hình ổn định là: “agent xử lý phán đoán và ngoại lệ”, “RPA xử lý thao tác UI deterministic”. Nếu giao luôn UI cho agent, hệ thống sẽ mong manh trước thay đổi màn hình, timeout, MFA.

9.2 Gọi RPA như một “tool”

RPA (ví dụ: UiPath/Power Automate) nhìn từ agent chỉ là một tool. Hãy type hóa tham số, quản lý version workflow phía RPA, và lưu giá trị trả về (thành công/thất bại/mã lỗi/screenshot) như Artifact.

9.3 Thiết kế fallback khi thất bại

Nếu agent thất bại mà chỉ “đẩy cho người” thì vận hành sẽ tắc. Cần xác định thứ tự ưu tiên: (1) chuyển sang flow RPA hiện có, (2) tạm thời chỉ trả lời chat, (3) tạo ticket. Sau đó cải tiến theo kiểu SRE dựa trên error budget.

10. Bảng phân tích so sánh（so sánh từ 3 lựa chọn trở lên）

Lựa chọn	Mục đích chính	Điểm mạnh	Điểm yếu/Rủi ro	Gợi ý áp dụng
Chat GenAI + RAG	Trả lời hỏi đáp, tìm kiếm tri thức	Chi phí thấp, rủi ro thấp, triển khai nhanh	Không có side effect bên ngoài (khó thành tự động hóa)	Bắt đầu từ đây. Cửa vào cho nghiệp vụ yêu cầu SLA nghiêm
RPA (rule-based)	Thao tác UI định hình, nhập liệu, batch	Deterministic, dễ audit	Yếu ở ngoại lệ, mong manh khi UI thay đổi	Back-office có quy trình cố định, ít ngoại lệ
IA (AI chỉ đạo RPA)	Kết hợp phán đoán + thực thi	Giảm can thiệp của con người	Nếu mơ hồ trách nhiệm sẽ gây sự cố (AI “bạo chạy” cả UI)	Tiền đề là thiết kế: AI quyết định, RPA thực thi
AI agent (Tool Use + quản lý trạng thái)	Nghiệp vụ bất định, tự chủ hoàn thành tác vụ	Khám phá/rẽ nhánh/xử lý ngoại lệ, mạnh với vấn đề phức tạp	Chi phí, tái lập, bảo mật, audit đều khó	Giới hạn vào side effect “giá trị cao” và triển khai theo giai đoạn

11. Best practices・Anti-patterns（dạng gạch đầu dòng）

✅ Best practices

⚙️ Tách Planner/Executor/Verifier để tool execution mang tính deterministic
🔧 Tham số tool được type hóa bằng JSON Schema, có ràng buộc miền giá trị và allowlist
🔐 Commit hai bước (dry-run→confirm) để giảm side effect
📊 Chuẩn hóa SLO theo: tỷ lệ thành công + chi phí + vi phạm an toàn + tỷ lệ làm lại
🧾 Audit log thiết kế xoay quanh “điểm quyết định”, tách khỏi log PII
📈 Thiết lập Concurrency Cap và daily cap theo từng tool

❌ Anti-patterns

“Cấm trong prompt là an toàn”: không có DLP/ABAC/kiểm soát scope là rất nguy hiểm
Biến UI automation thành công cụ vạn năng: bắt browser làm hết sẽ mong manh và không thể bảo trì
Tự chủ thực thi không có trạng thái: retry gây chạy trùng và tính phí trùng
Đưa lên production không đánh giá: model update làm suy giảm âm thầm, phát hiện thì đã thành sự cố
KPI “tự động hóa mọi nghiệp vụ”: khám phá giá trị thấp chỉ làm chi phí tăng

12. Lộ trình triển khai và checklist

12.1 Roadmap（tự chủ hóa theo giai đoạn）

Phase 0：Chat + RAG (không side effect). Cố định phân loại dữ liệu, bộ lọc tìm kiếm, thiết kế logging
Phase 1：Tool read-only (tìm kiếm, API tra cứu). Bổ sung audit log và rate control
Phase 2：Tool ghi (write) chỉ chạy dry-run. Hiển thị diff và luồng phê duyệt (HITL)
Phase 3：Mở commit trong phạm vi giới hạn (trần/allowlist/daily cap). Bắt đầu vận hành theo SLO
Phase 4：Multi-agent (tách agent theo chuyên môn). Tăng cường Verifier, tự động hóa regression test

12.2 Checklist

🔐 OAuth scope đã tối thiểu hóa, không đặt Secrets trực tiếp
🔧 Định nghĩa tool đã schema hóa, bắt buộc idempotency_key
📊 KPI chính (tỷ lệ thành công/tỷ lệ làm lại/chi phí/vi phạm an toàn) đã lên dashboard
🧪 Regression test chạy bằng Golden Run (temperature=0)
📈 Đã cấu hình concurrency/daily cap/retry theo từng tool
🧾 Audit log (điểm quyết định) được lưu giữ; đã định nghĩa thời hạn lưu và masking

13. Tài nguyên tham khảo・Bước tiếp theo

Chuyên mục kỹ thuật IPA SDS: AI agent (tổng quan và các điểm cần bàn khi triển khai xã hội)
Gartner: Đặc tính của AI agent (tự chủ, thích ứng, định hướng mục tiêu…)
OpenTelemetry (quan sát Run/Step bằng distributed tracing)
LangGraph / Semantic Kernel (triển khai agent như state machine)

Bước tiếp theo：Chọn 1 nghiệp vụ “side effect có giá trị cao” của doanh nghiệp (ví dụ: tạo ticket, giữ hàng tồn, tạo báo giá), rồi triển khai theo thứ tự Read-only → dry-run → commit. Nếu đã có tài sản RPA, hãy “tool hóa” RPA để tách trách nhiệm, bắt đầu từ thiết kế không mang điểm yếu UI vào phía agent—đó là con đường ngắn nhất để đi vào production.⚙️