⚙️Đào sâu kỹ thuật triển khai AI Agent: Giải bài toán “tự chủ – giao thức – quản trị” trong kỷ nguyên Copilot/Agent Studio bằng kiến trúc

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

AI agent là một kiến trúc thực thi khép kín (closed-loop) giúp “ngoại hóa” suy luận của LLM ra các thành phần: “dữ liệu nghiệp vụ (RAG/Graph)”, “thực thi công cụ (API/Workflows)”, “quản lý trạng thái (memory ngắn hạn/dài hạn)”, và “kiểm soát an toàn (Policy/kiểm toán)”, từ đó đi đến hoàn tất tác vụ. Các thiết kế tối ưu cho doanh nghiệp như Microsoft 365 Copilot/Agent 365 cung cấp “mức tự chủ có thể vận hành trong nội bộ doanh nghiệp” dựa trên ID, phân quyền và audit log. Đồng thời, với sự phát triển của các giao thức như MCP và A2A, tính tương tác (interoperability) và phân chia trách nhiệm giữa các agent đã trở thành lời giải thực tế. Bài viết này mổ xẻ các quyết định thiết kế theo góc nhìn triển khai, hiệu năng, bảo mật và khả năng mở rộng, kèm các con số cụ thể.

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

“Chatbot + RAG” truyền thống thường tạo được câu trả lời nhưng lại không hoàn tất được nghiệp vụ. Lý do quy về 4 điểm: (1) ủy quyền thực thi không rõ ràng, (2) thiếu retry và xử lý ngoại lệ khi thất bại, (3) yếu về kiểm toán và trách nhiệm giải trình, (4) tích hợp nhiều hệ thống dễ biến thành “mì spaghetti” do triển khai rời rạc. Ba lớp mà Copilot/Studio nhấn mạnh—“đối tượng biết (data/memory)”, “đối tượng xử lý (suy luận/lập kế hoạch)”, “nội dung thực thi (action)”—chính là cách phân rã để lấp các khoảng trống này.

Luồng kỹ thuật (diễn giải từ sơ đồ) 🔧: chỉ dẫn người dùng → (A) thu thập ngữ cảnh (Graph/RAG/lịch sử/policy) → (B) tạo kế hoạch (phân rã, ưu tiên, điều kiện dừng) → (C) chọn và chạy công cụ (cập nhật CRM/tạo ticket/đề nghị hoàn ứng…) → (D) kiểm chứng kết quả (schema/nhất quán/policy) → (E) audit log + cập nhật memory → nếu cần thì xin phê duyệt của con người → hoàn tất. Điểm then chốt: LLM không phải “bộ điều khiển trung tâm”, mà chỉ là một phần của orchestration.

[User]
  |
  v
[Agent Orchestrator]
  |--(A) Context Builder: RAG + Graph + Memory + Policy
  |--(B) Planner: task decomposition / stop conditions
  |--(C) Tool Router: MCP/REST/Workflow
  |--(D) Verifier: schema + business rules + safety
  |--(E) Audit+Telemetry: traces/PII redaction
  v
[Systems: M365/CRM/ERP/ITSM/Data Lake]

Các điểm đau hiện hữu⚙️: phụ thuộc prompt (đặc tả bị chôn trong ngôn ngữ tự nhiên), ranh giới quyền hạn mơ hồ (quá quyền/giả mạo), thiếu khả năng quan sát (khó truy vết nguyên nhân lỗi), bùng nổ chi phí và độ trễ (context khổng lồ + gọi tool nhiều tầng). Xu hướng 2025 cho thấy “context engineering”, “MCP”, và “tính năng governance” đang trở thành nền tảng mặc định.

3. Phần kỹ thuật ①: Phân tách trách nhiệm của agent（Orchestrator/Planner/Tools/Memory）

3.1 Tách hệ tham chiếu và hệ thực thi

Quyết định đầu tiên khi thiết kế agent doanh nghiệp là tách tham chiếu (read) và thực thi (write). Hệ read dùng RAG/Graph để “nắm hiện trạng”; hệ write tạo tác dụng phụ như cập nhật CRM hay tạo ticket. Nếu cấp cùng quyền tool cho cả hai, prompt injection có thể dẫn đến sự cố ngay lập tức. Khuyến nghị là cấu trúc 3 tầng: (a) nhóm tool read-only, (b) nhóm tool write (có điều kiện/cần phê duyệt), (c) nhóm rủi ro cao (chuyển tiền/hợp đồng) tách sang luồng riêng.

3.2 Không biến Planner thành “vạn năng”

Planner tạo “phân rã”, “thứ tự”, “điều kiện dừng”, nhưng nếu giao toàn bộ cho LLM, độ dao động của kế hoạch sẽ phá chất lượng vận hành. Khi triển khai, template cố định + sinh có ràng buộc ổn định hơn. Ví dụ: định nghĩa Plan JSON Schema, validate đầu ra của LLM rồi mới thực thi. Tư duy này gần với thiết kế flow (topic/flow) của Copilot Studio: các nhánh quan trọng được giữ ở dạng khai báo (declarative).

3.3 Memory cần tách theo “mục đích”

Memory không chỉ là “lịch sử hội thoại”. Khuyến nghị tách: (1) ngắn hạn theo phiên (Redis… TTL=30–120 phút), (2) sở thích/vai trò người dùng (từ Directory/Graph, lưu bền), (3) trạng thái tác vụ (workflow state, lưu bền), (4) tri thức (vector DB). Trộn lẫn sẽ khiến yêu cầu xóa dữ liệu (GDPR/quy định nội bộ) xung đột với yêu cầu kiểm toán.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AgentPlan",
  "type": "object",
  "required": ["goal", "steps", "stop_conditions"],
  "properties": {
    "goal": {"type": "string"},
    "steps": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "tool", "input", "risk"],
        "properties": {
          "id": {"type": "string"},
          "tool": {"type": "string"},
          "input": {"type": "object"},
          "risk": {"type": "string", "enum": ["read", "write", "high"]}
        }
      }
    },
    "stop_conditions": {"type": "array", "items": {"type": "string"}}
  }
}

3. Phần kỹ thuật ②: Context Engineering（RAG＋Graph＋đầu vào theo ngữ cảnh）

3.1 Ưu tiên “context chuẩn hóa” hơn “context dài”

Dù context cỡ triệu token đã trở nên khả thi, trong hệ thống doanh nghiệp thứ tạo khác biệt không phải “độ dài” mà là “chuẩn hóa”. Cụ thể: (a) gom các căn cứ tham chiếu kèm ID, (b) nêu rõ vai trò/quyền hạn/ranh giới tenant, (c) chuẩn hóa hạn chót, đơn vị, tiền tệ. Nhờ vậy, thay vì bị chi phối bởi ảo giác của LLM, hệ thống được thiết kế để lỗi chủ yếu đến từ không nhất quán dữ liệu (có thể debug).

3.2 Chiến lược truy xuất ưu tiên Graph

Trong ngữ cảnh Microsoft 365, hiệu quả nhất là lấy Graph trước như dữ liệu có cấu trúc (user, group, tài liệu, lịch, email). Vector search mạnh về khớp mơ hồ, nhưng các ràng buộc như kế thừa quyền, chủ sở hữu, thời điểm cập nhật… thì Graph vượt trội. Chiến lược khuyến nghị: “lọc tập ứng viên bằng Graph → bổ sung căn cứ nội dung bằng RAG”.

3.3 Tối thiểu hóa context（kiểm soát Cost/Latency）

Agent thường tăng số lần gọi tool, khiến phình context tác động trực tiếp đến chi phí và độ trễ. Khi triển khai, kiểm soát theo tầng ổn định hơn: (1) cố định “memory tóm tắt” ở 1–2KB, (2) giới hạn tài liệu căn cứ tối đa N (ví dụ N=5) + cắt mỗi tài liệu 200–400 token, (3) chỉ lấy thêm khi thất bại. Trước khi tăng context, ưu tiên đóng chặt schema đầu vào.

# context-policy.yaml
context:
  max_documents: 5
  max_tokens_per_doc: 350
  session_summary_max_tokens: 300
  prefer_sources:
    - graph
    - rag
  pii_redaction: true
  citation_required: true

3. Phần kỹ thuật ③: Tích hợp tool và giao thức（MCP/A2A）

3.1 Ý nghĩa của việc “ngoại hóa định nghĩa tool” bằng MCP

MCP (Model Context Protocol) cung cấp một “bề mặt kết nối chung” để LLM/agent truy cập tool và nguồn dữ liệu bên ngoài. Điểm hiệu quả về mặt kỹ thuật: (a) làm rõ schema input/output của tool, (b) dễ thay thế backend kết nối, (c) đẩy audit/authorization về phía gateway. Kết quả: triển khai agent dịch chuyển từ “nghề thủ công prompt” sang “kiến trúc tích hợp”.

3.2 Cố định phân chia trách nhiệm bằng A2A（Agent-to-Agent）

Một agent đơn khổng lồ sẽ tăng lỗi routing khi số tool tăng. Theo hướng A2A, tách các miền như SDR (phát triển kinh doanh), kế toán, ITSM thành các domain agent, và để một router cấp trên ủy thác. Quan trọng là khi ủy thác phải nêu rõ “thao tác được phép”, “schema đầu ra kỳ vọng”, và “deadline”, tránh tích hợp kiểu hộp đen.

3.3 Ví dụ: công bố CRM nội bộ qua MCP server

// mcp-tooling.json（ví dụ khái niệm）
{
  "tools": [
    {
      "name": "crm.search_leads",
      "description": "Search leads by firmographics and last activity",
      "input_schema": {
        "type": "object",
        "properties": {
          "industry": {"type": "string"},
          "min_score": {"type": "number"},
          "updated_after": {"type": "string", "format": "date-time"}
        },
        "required": ["min_score"]
      },
      "output_schema": {
        "type": "object",
        "properties": {
          "leads": {"type": "array", "items": {"type": "object"}}
        },
        "required": ["leads"]
      }
    }
  ]
}

3. Phần kỹ thuật ④: Kiểm soát thực thi（phê duyệt, idempotency, xử lý ngoại lệ, retry）

3.1 “Con người tham gia” là điểm kiểm soát, không chỉ là tính năng

Lời giải thực tế khi triển khai doanh nghiệp thường là tự chủ theo từng giai đoạn, thay vì “tự chủ hoàn toàn”. Với thao tác write, cần quyết định theo từng loại thao tác: (a) tự động chạy, (b) thông báo sau khi chạy, (c) phê duyệt trước, (d) cấm. Copilot/Studio nhấn mạnh “tối ưu nghiệp vụ” và “bảo vệ bảo mật” vì có thể nối các điểm kiểm soát này vào hệ ID/audit sẵn có.

3.2 Idempotency key và trạng thái workflow

Agent sẽ retry khi gọi tool. Để tránh tạo trùng khi cập nhật CRM hay tạo ticket, cần truyền idempotency_key (ví dụ: hash(user, task_id, step_id)) cho mọi write API. Đồng thời, lưu bền trạng thái theo bước (PENDING/RUNNING/SUCCEEDED/FAILED) để có thể resume. Nếu thiếu, khi “rơi giữa chừng” con người sẽ phải dọn dẹp.

3.3 Không để LLM “diễn giải” ngoại lệ

Ngoại lệ cần trả về dạng cấu trúc (HTTP 409/422…). Nếu chuyển nguyên “thông báo lỗi dạng tự nhiên”, LLM có thể hiểu sai và tự nghĩ ra cách né tránh nguy hiểm. Khuyến nghị: error code → handler (logic cố định) → nếu cần thì mới dùng LLM để tạo lời giải thích.

# pseudo-code
try:
    res = tool.call(input, idempotency_key=key)
except ToolError as e:
    if e.code in {409, 429}:
        retry_with_backoff()
    elif e.code == 403:
        request_human_approval(reason="permission")
    else:
        fail_fast_and_log(e.to_struct())

3. Phần kỹ thuật ⑤: Thiết kế hiệu năng（độ trễ, chi phí, chất lượng）

3.1 Critical path không phải “LLM” mà là “I/O”

Độ trễ của agent nghiệp vụ thường bị chi phối bởi tổng thời gian gọi Graph/DB/API hơn là suy luận LLM. Thiết kế hiệu quả gồm: (1) song song hóa read, (2) cache kết quả tool (TTL 30–300 giây), (3) đặt trần số bước (ví dụ: max_steps=8). Ngoài ra, chọn model theo độ khó: phân loại/trích xuất dùng model nhẹ, quyết định cuối dùng model cao hơn.

3.2 Benchmark (giá trị tham khảo) 📊

Dưới đây là benchmark tham khảo cho luồng “agent SDR (lọc lead → phác thảo email → cập nhật CRM)” (cùng mạng, API p95=250ms, LLM cùng region). Trong môi trường thực, cộng thêm 10–30% do security gateway/audit.

Cấu hình	Model	Số lần gọi tool	Độ trễ p50	Độ trễ p95	Chi phí ước tính/tác vụ	Tỷ lệ thành công (tự hoàn tất)
RAG đơn phát (chỉ trả lời)	Cỡ GPT-4.1	2	3.8s	7.2s	$0.06	— (không thực thi)
Agent (không phê duyệt)	Cỡ GPT-4.1 + trích xuất nhẹ	6	9.5s	18.4s	$0.14	78%
Agent (phê duyệt trước cho write)	Như trên	6	10.2s	20.1s	$0.15	92% (sau phê duyệt)

3.3 Dịch chuyển chỉ số chất lượng từ “độ đúng” sang “KPI nghiệp vụ”

Đánh giá agent không nên dùng chỉ số NLP như BLEU, mà nên đo bằng: (a) tỷ lệ hoàn tất đúng hạn, (b) tỷ lệ làm lại (rework), (c) tỷ lệ bị audit nhắc nhở, (d) tỷ lệ cập nhật sai (tai nạn write). Giá trị của Copilot không nằm ở “tạo sản phẩm đầu ra” mà ở “thực thi quy trình”, nên trục đánh giá cũng phải dịch chuyển.

3. Phần kỹ thuật ⑥: Bảo mật & Governance（ID, phân quyền, kiểm toán, ranh giới dữ liệu）

3.1 Nguyên tắc tối thiểu quyền + ủy quyền (On-behalf-of)

Ngay từ đầu cần chốt agent chạy theo quyền của người dùng hay quyền service account. Khuyến nghị là On-behalf-of (OBO): giữ ranh giới quyền của người dùng, đồng thời cấp cho agent token sống ngắn. Token sống dài hoặc shared secret gây thiệt hại lớn khi rò rỉ.

3.2 “Khóa chặt” prompt injection thay vì chỉ “phát hiện”

Phát hiện có giới hạn. Để khóa chặt cần: (1) validate schema cho input của tool, (2) đánh giá policy trước khi chạy tool (DLP/phân loại mật/kiểm soát đích đến), (3) bắt buộc trích dẫn căn cứ (citation) trong output, (4) sanitize nội dung bên ngoài (email/HTML). Đặc biệt, phải cắt đường lan truyền nơi “chỉ dẫn bị nhúng trong email” đi vào thực thi tool.

3.3 Audit log không chỉ để “hậu kiểm” mà để “tái lập”

Kiểm toán cần không chỉ “đã làm gì” mà còn phải tái lập được “vì sao quyết định như vậy”. Tối thiểu lưu: (a) input (mask PII), (b) ID nguồn dữ liệu đã tham chiếu, (c) Plan đã sinh, (d) tool đã chạy và tham số (tokenize phần mật), (e) người phê duyệt và thời điểm, (f) phiên bản model/prompt/policy. Nếu yếu ở đây, khi sự cố xảy ra sẽ “không thể chạy lại để điều tra”.

{
  "trace_id": "01J...",
  "model": "gpt-4.1",
  "policy_version": "2026-01-15",
  "user": {"id": "aad:...", "role": "Sales"},
  "citations": ["doc:sharepoint:123", "crm:lead:889"],
  "plan": {"goal": "...", "steps": ["..."]},
  "actions": [
    {"tool": "crm.update_lead", "idempotency_key": "...", "status": "SUCCEEDED"}
  ]
}

3. Phần kỹ thuật ⑦: Khả năng mở rộng & vận hành（multi-tenant, observability, đánh giá）

3.1 Kẻ thù của scale là “trạng thái” và “rate limit của hệ tích hợp”

Agent dễ trở nên stateful. Để scale, nên đẩy orchestrator về hướng stateless, và đưa trạng thái ra external store (Redis/PostgreSQL/Cosmos DB…). Tiếp theo, rate limit của Graph/CRM/ITSM… thường là nút thắt, vì vậy cần queue (ví dụ: Azure Service Bus) để làm phẳng tải, và tách slot thực thi theo mức ưu tiên (P0/P1).

3.2 Observability: thống nhất trace bằng OpenTelemetry

Khi đưa LLM call, tool call, thời gian chờ phê duyệt và retry vào cùng một trace, bạn sẽ thấy ngay nguyên nhân làm xấu p95. Bộ metric tối thiểu: (a) tool_call_count, (b) tokens_in/out, (c) retry_count, (d) policy_denied_rate, (e) human_approval_rate. Khi đủ, cải tiến chuyển từ “cảm tính” sang “kỹ nghệ”.

3.3 Đánh giá liên tục (Evals) là một phần của production

Từ 2025 trở đi, model cập nhật thường xuyên khiến tối ưu hôm qua có thể thành thoái lui hôm nay. Khuyến nghị: (1) cố định bộ golden task (50–200 case), (2) kiểm chứng cấu trúc output + kiểm chứng rule nghiệp vụ, (3) với write thì replay trong sandbox, (4) nếu điểm số dưới ngưỡng thì tự động rollback, tích hợp vào CI/CD. Agent là ứng dụng; không chỉ MLOps mà cần AgentOps.

# otel-collector.yaml（trích đoạn ví dụ）
receivers:
  otlp:
    protocols:
      http:
exporters:
  otlphttp:
    endpoint: "https://otel-gateway.internal/v1/traces"
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp]

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

Tiền đề “tối ưu nghiệp vụ + bảo mật mặc định” của Microsoft 365 Copilot/Agent Studio rất mạnh, nhưng không bắt buộc phải đóng toàn bộ trong một vendor. Có thể chia lựa chọn thiết kế thành 3 nhóm: ① tích hợp sẵn trong suite, ② tích hợp low-code, ③ orchestration tùy biến.

Lựa chọn	Ví dụ tiêu biểu	Điểm mạnh	Điểm yếu	Phạm vi áp dụng	Mức phù hợp governance
① Tích hợp sẵn trong suite	Microsoft 365 Copilot + Agents	🔧Dễ tích hợp ID/audit/ranh giới dữ liệu. Bề mặt nghiệp vụ phong phú	Tích hợp sâu với SaaS ngoài cần thiết kế mở rộng. Độ tự do bị giới hạn	Tự động hóa nghiệp vụ/tri thức xoay quanh M365	Cao (dễ nối với kiểm soát hiện hữu)
② Tích hợp low-code	Copilot Studio/các iPaaS	⚙️Triển khai nhanh trong ngắn hạn. Bộ phận nghiệp vụ dễ chạy vòng cải tiến	Khó “độ” sâu các phần phức tạp như idempotency/xử lý ngoại lệ/đánh giá	Luồng chuẩn hóa, dựa trên connector sẵn có	Trung bình (phụ thuộc thiết kế)
③ Orchestration tùy biến	Agent Orchestrator nội bộ + MCP + OTel	📊Tối ưu hiệu năng/kiểm soát/kiểm toán theo yêu cầu. Dễ phân chia trách nhiệm bằng A2A	Chi phí ban đầu cao. Bắt buộc có vận hành (AgentOps)	Nghiệp vụ lõi, đa domain, kiểm soát nghiêm ngặt	Cao nhất (định hướng “làm kỹ”)

5. Best Practices & Anti-patterns（dạng gạch đầu dòng）

Best practices ✅

⚙️ Tách read/write/high-risk theo quyền, tuyến thực thi và cơ chế phê duyệt
🔧 Cố định Plan/Tool I/O bằng JSON Schema và bắt buộc validation
📊 Lưu audit log gồm “model/policy/citation ID/tham số thực thi (mask)” để đảm bảo khả năng tái lập
Áp dụng idempotency key cho mọi write API để tránh chạy trùng khi retry
Tìm kiếm hai tầng Graph→RAG để vừa đảm bảo ràng buộc quyền vừa hỗ trợ khớp mơ hồ
Dùng OpenTelemetry để gom LLM/tool/chờ phê duyệt vào một trace thống nhất

Anti-patterns ❌

“Cứ viết prompt thật dài” để nhét đặc tả (khó thay đổi, không kiểm toán được)
Gán toàn quyền cho service account để chạy agent
Đưa lỗi dạng tự nhiên cho LLM và để nó tự thực thi “cách né” tùy tiện
Đổ kết quả RAG không giới hạn, làm tăng chi phí/độ trễ/rủi ro rò rỉ
Đánh giá bằng việc kiểm tra “văn bản nghe có vẻ đúng”, bỏ sót tai nạn write

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

Phase 0: Định nghĩa yêu cầu (1–2 tuần)

Phân loại nghiệp vụ mục tiêu là “read là chính” hay “write là chính”
Văn bản hóa điều kiện cấm/phê duyệt cho thao tác rủi ro cao (chuyển tiền/hợp đồng/gửi ra ngoài)
Định nghĩa tiêu chí thành công theo KPI nghiệp vụ (tỷ lệ hoàn tất, tỷ lệ làm lại, tỷ lệ bị audit nhắc)

Phase 1: Agent tối thiểu (2–4 tuần)

🔧 Chuẩn hóa schema Tool I/O (JSON Schema)
Giới hạn nguồn RAG/Graph (ví dụ max_documents=5)
Triển khai audit log (trace_id, citations, policy_version)

Phase 2: Tăng cường kiểm soát thực thi (4–8 tuần)

⚙️ Idempotency key, quản lý trạng thái workflow, cơ chế resume
Luồng phê duyệt (phê duyệt trước/phê duyệt hai người) và kết nối policy engine
Giảm tác động rate limit (queue, backoff, circuit breaker)

Phase 3: Cộng tác và scale (liên tục)

Phân tách domain bằng A2A (Sales/Kế toán/ITSM)
📊 Tích hợp OpenTelemetry + Evals vào CI/CD (phát hiện thoái lui)
Ngoại hóa định nghĩa tool bằng MCP để dễ thay thế hệ tích hợp

Checklist cuối

Authorization: OBO/token sống ngắn, đảm bảo nguyên tắc tối thiểu quyền
Dữ liệu: mask PII, DLP, thiết kế ranh giới tenant
Thực thi: idempotency, xử lý ngoại lệ, điều kiện dừng (max_steps…)
Kiểm toán: truy được citation ID, phiên bản policy/model, người phê duyệt
Vận hành: tự động hóa p95 latency, trần chi phí, test thoái lui

7. Tài nguyên tham khảo & bước tiếp theo

Microsoft 365 Copilot Agents / Agent 365 (nắm tư tưởng sản phẩm và lộ trình triển khai)
Copilot Studio (thiết kế flow low-code, thêm action, kiểm thử lặp)
Nền tảng trace: OpenTelemetry Collector v0.103+ (thống nhất observability nội bộ)
Nền tảng dữ liệu: PostgreSQL 16 / Redis 7.2 (tách trạng thái và memory ngắn hạn)
Bước tiếp theo: ① bắt đầu với agent read-only để chốt audit/citation → ② mở write kèm phê duyệt → ③ tách domain bằng A2A → ④ chuẩn hóa bề mặt tích hợp bằng MCP