Framework xây dựng AI Agent từ Zero đến Hero #50

Trả lời ngắn: Đây là lộ trình xây agent theo từng bậc có kiểm tra. Chốt việc và cách chấm, làm bản đơn giản, rồi mới thêm thông tin, công cụ, trí nhớ và vòng lặp; mỗi bậc cần bằng chứng, người chịu trách nhiệm và cách quay lại.

Đọc xong, bạn sẽ hiểu:

• Chọn workflow deterministic, single agent hay multi-agent đúng lúc.
• Biết artifact và gate bắt buộc ở từng bậc.
• Mở quyền từ read-only đến approved write theo evidence.
• Release bằng offline eval, shadow, canary, monitor và rollback.

Lưu ý giáo dục: Bài tập local-only, không gọi model/API/tool thật. Đây là framework engineering, không phải lời hứa agent “tự trị”. Authentication, authorization, privacy, secrets và software security phải được code/hạ tầng thực thi ngoài prompt.

1. Framework Zero to Hero là gì?

a. “Hero” không có nghĩa là tự động mọi thứ

Một agent trưởng thành không phải agent có nhiều tool, nhiều memory hay nhiều subagent nhất. Nó là hệ thống hoàn thành một job cụ thể trong giới hạn quality, latency, cost và risk; biết từ chối, biết dừng và biết chuyển người.

OpenAI gợi ý dùng agent cho workflow có quyết định phức tạp, rule khó bảo trì hoặc dữ liệu phi cấu trúc; nếu logic deterministic đủ giải quyết, một giải pháp thông thường có thể phù hợp hơn. Anthropic cũng nhấn mạnh bắt đầu bằng thiết kế đơn giản nhất rồi chỉ tăng complexity khi kết quả chứng minh cần.

b. Năm phase ghép thành một runtime

• Prompt Engineering: định nghĩa role, goal, constraint và output.
• Context Engineering: cung cấp đúng evidence trong token budget.
• Harness Engineering: nối tools, state, routing, guardrails và retry.
• Agentic Loop: plan, act, observe, verify, checkpoint và stop.
• AI System: eval, SLO, observability, human operations và release.

Các phase không phải năm hộp tách rời. Prompt đọc context; harness cấp tool; loop quản state; system kiểm quyền, đo outcome và xử lý sự cố.

c. Công thức capstone

Use-case Contract → Eval Set → Deterministic Baseline → Prompt/Output Contract → Context → Tools → State/Loop → Guardrails/HITL → Observability → Staged Release.

Mỗi mũi tên là decision gate. Không pass thì sửa bậc hiện tại, không che lỗi bằng việc thêm agent.

Hình 1 — Năng lực và quyền chỉ tăng sau khi bậc trước có artifact cùng evidence đạt gate.

2. Mười bậc build ladder và artifact bắt buộc

Bậc 1–3: Problem, eval và baseline

1. Use-case Contract: user, job, outcome, non-goal, risk tier, SLO, owner. “Trợ lý hỗ trợ khách hàng” quá rộng; “giúp agent CS tìm policy còn hiệu lực và soạn câu trả lời có nguồn, không gửi tự động” test được.

2. Eval Set: tạo case happy, edge, adversarial và incident trước khi chọn model. Mỗi case có input, expected behavior, evidence và scorer.

3. Deterministic Baseline: thử search/rule/template. Baseline vừa tạo giá trị sớm vừa cho biết agent phải thắng cái gì. Nếu FAQ rules đúng 92% case và latency thấp, có thể chỉ cần retrieval cùng fallback.

Bậc 4–6: Prompt, context và tools

4. Prompt/Output Contract: role, goal, constraints, routine, edge cases và JSON/Markdown schema. Few-shot chỉ thêm khi eval cho thấy lỗi pattern.

5. Context Contract: source allowlist, selection, provenance, freshness, compression và token budget. Memory không phải dump toàn history; chỉ lưu state hữu ích theo retention/privacy.

6. Tool Registry: typed input/output, timeout, error taxonomy, permission, side-effect class và idempotency. Mở read trước write; reversible trước irreversible. Tool description không phải security boundary.

Bậc 7–10: Runtime, safety, evidence và release

7. State/Loop Contract: state machine, next-action policy, checkpoint, budget, retry và terminal states done/failed/blocked/escalated. Không dùng while not done mơ hồ.

8. Guardrails + HITL: input/output/tool/action gates, least privilege, approval cho high-risk và payload bàn giao cho human. Guardrail phải layered, không phụ thuộc một classifier.

9. Observability: request/task ID, model/prompt/context/tool/config version, latency, cost, errors và outcome. Trace phải trả lời “vì sao agent làm vậy?” mà không log secret hoặc chain-of-thought riêng tư.

10. Staged Release: offline eval → prototype → shadow → canary → production. Mỗi stage có promote/rollback rule; incident trở thành regression eval.

3. Ví dụ end-to-end: xây Support Copilot read-only

a. Contract và baseline

Use case: nhân viên CS hỏi policy hoàn tiền và trạng thái đơn hàng giả. Copilot chỉ soạn nháp; không gửi tin, không refund. SLO: grounded answer ≥95% trên fixture, citation đúng 100%, p95 dưới 4 giây, không external write.

Eval có năm case: policy mới, policy hết hạn, không có nguồn, prompt injection trong ticket và order không tồn tại. Baseline là keyword search + template. Nó pass 3/5: tìm được policy dễ nhưng không hiểu cách diễn đạt khác.

b. Thêm model và context

Retriever chỉ lấy KB đã duyệt, lọc effective_at/expired_at, trả source ID. Model nhận context cùng output schema:

{
  "draft": "...",
  "sources": ["policy-v3"],
  "reason": "approved source",
  "state": "human-review"
}

Nếu retrieval rỗng, shell bắt state=needs-human; không cho model tự nhớ. Output validator kiểm mọi claim chính được citation hỗ trợ.

c. Thêm một tool read-only

Tool get_order_status(order_id) xác minh auth/tenant, chỉ trả enum typed và timestamp. Model tạo tool intent; authority gate mới quyết gọi. Timeout retry tối đa hai lần; trạng thái unknown chuyển human.

Chưa thêm refund_order. Evidence hiện tại chỉ chứng minh lookup an toàn, không chứng minh write action. Quyền không tăng theo sự tự tin của model.

d. State, trace và release

State machine: received → context_ready → draft_ready → human_review → done, cùng nhánh needs_human/blocked. Shadow chạy trên ticket đã giải quyết nhưng không ảnh hưởng user. Canary cho 5% nhân viên thấy draft; đo edit distance, resolution, citation, latency và cost.

Nếu quality pass nhưng cost vượt SLO, rollback model route/config, không nhất thiết bỏ toàn feature. Đây là lợi ích của component contract.

4. Sai lầm, decision gates và checklist production

a. Tám kiểu “nhảy bậc”

1. Agent-first: chưa có job/outcome đã chọn framework.
2. No baseline: không biết complexity tạo thêm có đáng.
3. Prompt-only security: ghi “không làm xấu” thay access control.
4. Memory dump: nhét toàn history, tăng noise/privacy risk.
5. Broad tools: một credential cho read/write/delete.
6. Infinite loop: reflection/retry không budget hay terminal state.
7. Multi-agent sớm: thêm handoff trước khi single agent baseline ổn.
8. Big-bang release: production toàn bộ, không shadow/canary/rollback.

b. Chọn deterministic, single hay multi-agent

Multi-agent thêm token, latency, shared-state và coordination failure. Chỉ tách khi eval chỉ ra prompt/tool overload hoặc nhánh thật sự độc lập.

c. Production checklist

• Contract có outcome, non-goal, risk, SLO, owner?
• Eval có happy/edge/adversarial/incident và task outcome?
• Baseline đơn giản đã được đo?
• Prompt/output/context có schema, provenance, freshness?
• Tool typed, least privilege, idempotent và có approval?
• State có version, checkpoint, budget, terminal states?
• Guardrails bao input/output/tool/action/privacy?
• Human queue có payload, SLA và quyền quyết định?
• Trace đủ debug mà không lộ secret/sensitive data?
• Shadow/canary có promote, rollback, incident và decommission?

NIST AI RMF dùng Govern, Map, Measure, Manage xuyên lifecycle. Framework này cũng phải lặp: context, risk và kỳ vọng đổi thì contract/eval/control phải đổi.

5. Bài tập 15 phút: tạo Agent Build Card của bạn

a. Chuẩn bị

Dùng Markdown hoặc Sheet. Chọn Support Copilot giả chỉ đọc KB và order fixture. Không API, không model call, không multi-agent.

b. Agent Build Card

Điền tám ô:

1. Outcome/non-goal/risk/owner.
2. Năm eval cases và expected behavior.
3. Deterministic baseline cùng score.
4. Prompt/output schema.
5. Context sources/freshness/token budget.
6. Tools + authority + side-effect class.
7. State/stop/retry/human.
8. Trace/SLO/release/rollback.

Hình 2 — Một canvas nhỏ giúp lộ ngay bậc nào chưa có contract hoặc evidence.

c. Mẫu đối chiếu

d. Điểm dừng

Bài tập hoàn tất khi bạn chỉ rõ bậc hiện tại và một next experiment nhỏ nhất. Không viết “thêm memory/multi-agent cho mạnh”. Nếu eval chưa rõ, quay lại bậc 1–2.

6. Tổng kết series: build nhỏ, đo thật, mở quyền dần

a. Năm ý chính

• Không phải mọi bài toán cần agent; baseline là bắt buộc.
• Prompt, context, harness và loop phải có contract chung.
• Quyền tăng theo evidence: read trước write, reversible trước irreversible.
• Evals và observability quyết định promote, không phải demo.
• Production cần owner, HITL, incident, rollback và decommission.

Hình 3 — Maturity tăng cùng evidence; production không phải cú nhảy một lần.

b. Câu hỏi tự kiểm tra

• Vì sao viết eval trước chọn model?
• Khi nào chưa nên thêm write tool?
• Multi-agent chỉ đáng dùng khi nào?
• Incident phải tạo ra artifact gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Eval định nghĩa “tốt”, tạo baseline và giúp so model theo quality, latency, cost, risk thay vì cảm giác. Xem mục 2.

Xem gợi ý câu 2

Khi read-only outcome chưa ổn, auth/approval/idempotency/audit chưa pass hoặc impact write chưa có rollback. Xem mục 2–3.

Xem gợi ý câu 3

Khi ranh giới chuyên môn/quyền và parallelism thật sự rõ, còn single-agent eval cho thấy giới hạn đo được. Xem mục 4.

Xem gợi ý câu 4

Trace/evidence, root-cause fix, regression eval và cập nhật runbook/control. Xem mục 2 và 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• OpenAI — A practical guide to building agents
• Anthropic — Building effective agents
• NIST — AI RMF Core
• Microsoft Azure — Design Principles for AI Workloads

f. Đi tiếp sau bài #50

Bạn có thể quay lại AI System Design #49 để dựng System Card, rồi chọn một use case read-only nhỏ và chạy Build Card ở mục 5. Đừng học thêm framework trước khi hoàn tất một eval set và baseline.

Nhắc lại giáo dục: Zero to Hero không phải tăng autonomy nhanh nhất. Đó là năng lực biến uncertainty thành contract, evidence và control: build nhỏ, đo thật, mở quyền dần, dừng an toàn và luôn có con người chịu trách nhiệm.