Xây dựng AI Agent production: 12 nguyên tắc

Trả lời nhanh: xây dựng AI Agent production là biến vòng lặp model-tool thành một hệ thống có giới hạn, đo được và phục hồi được. Cần bắt đầu từ workflow hẹp, tool có schema, state bền vững, idempotency, eval theo task, trace, least privilege, human approval, budget và canary. Model đưa ra quyết định xác suất; hạ tầng phải bảo vệ invariant.

Cập nhật lần cuối: 20/08/2026

Demo agent thường chạy theo happy path: một người dùng, dữ liệu sạch, tool phản hồi nhanh và không có quyền nguy hiểm. Production thì ngược lại:

người dùng mô tả thiếu;
prompt có thể độc hại;
API timeout;
tool trả schema khác;
model gọi lặp;
state bị cập nhật đồng thời;
người duyệt rời màn hình;
workflow phải resume sau nhiều giờ;
chi phí tăng ở p99;
hành động sai phải đảo được.

Khoảng cách giữa demo và production không nằm ở một prompt dài hơn. Nó nằm ở kiến trúc, đo lường và kỷ luật vận hành.

Xây dựng AI Agent production là gì?

Xây dựng AI Agent production là thiết kế, triển khai và vận hành một hệ thống trong đó mô hình có thể lập kế hoạch hoặc chọn công cụ, nhưng mọi hành động diễn ra trong contract, quyền hạn, trạng thái và guardrail được kiểm soát.

Một agent production có ít nhất sáu lớp:

Task contract: mục tiêu, input, output và điều kiện thành công.
Agent loop: model, state và logic tiếp tục/dừng.
Tool layer: API, schema, permission và side effect.
Control layer: policy, approval, budget, timeout, sandbox.
Reliability layer: durable state, retry, idempotency, recovery.
Evidence layer: trace, eval, monitoring và audit.

Nếu thiếu một lớp, hệ thống có thể vẫn hoạt động trong demo nhưng không chứng minh được độ tin cậy khi traffic và rủi ro tăng.

Khi nào thực sự cần Agent?

Không phải workflow AI nào cũng cần loop tự chủ.

Dùng một model call khi

input và output rõ;
không cần tool;
không cần branching;
lỗi có thể kiểm tra ngay;
nhiệm vụ hoàn thành trong một lượt.

Dùng workflow xác định khi

các bước cố định;
business rule rõ;
chỉ một vài bước cần model;
audit và predictability quan trọng.

Dùng agent khi

đường đi phụ thuộc dữ liệu mới;
model phải chọn tool hoặc chiến lược;
số bước thay đổi;
cần tìm và kiểm chứng thông tin;
môi trường trả feedback để điều chỉnh.

Agent nên giải phần bất định. Những gì biết chắc nên viết thành code, rule hoặc state machine.

Mười hai nguyên tắc xây AI Agent production

1. Bắt đầu từ tác vụ hẹp và kiểm chứng được

“Trợ lý vận hành toàn công ty” quá rộng để đánh giá. “Phân loại ticket, lấy ba nguồn liên quan và tạo draft trả lời” có ranh giới rõ.

Task contract nên ghi:

input bắt buộc;
output schema;
nguồn được phép;
tool được phép;
action nào chỉ tạo draft;
success criterion;
timeout và budget;
trường hợp phải chuyển người.

Một tác vụ hẹp giúp xây eval trước khi tăng quyền.

2. Giữ orchestration đơn giản nhất có thể

Mỗi agent, handoff và tool thêm state cùng failure mode. Bắt đầu bằng một agent với ít tool. Chỉ tách specialist khi trace cho thấy một prompt và toolset chung tạo xung đột rõ.

Multi-agent không tự động tăng chất lượng. Nó có thể tăng:

số model call;
routing error;
context copy;
ownership mơ hồ;
vòng lặp giữa agent;
khó truy vết.

Tách theo trách nhiệm và quyền, không theo mong muốn kiến trúc đẹp.

3. Thiết kế tool như public API

Tool description là contract cho model. Tool tốt có:

tên thể hiện động từ và domain;
mô tả khi nào dùng và khi nào không;
schema chặt với enum, range, format;
output nhỏ, có cấu trúc;
error code máy đọc được;
timeout rõ;
idempotency cho write;
permission tối thiểu;
audit event.

Không trả stack trace hoặc payload khổng lồ cho model. Trả lỗi như:

{
  "code": "CUSTOMER_NOT_FOUND",
  "retryable": false,
  "message": "No customer matched the supplied external_id"
}

Model có cơ hội phục hồi tốt hơn khi lỗi ổn định và có semantics.

4. Tách read tool và write tool

Tool manage_customer vừa đọc, sửa, xóa tạo quyền quá rộng và schema khó hiểu. Tách:

get_customer;
list_customer_orders;
update_customer_address;
close_customer_account.

Read có thể chạy song song và không cần approval trong nhiều use case. Write phải có scope, expected version, idempotency key và đôi khi human approval.

Phân tách giúp policy engine dễ kiểm tra hơn model.

5. Dùng state bền vững và có version

Agent dài hơi không thể dựa hoàn toàn vào conversation text trong RAM. Cần lưu:

run ID;
current step;
input đã chuẩn hóa;
decisions;
tool call và output tham chiếu;
approval state;
resource IDs đã tạo;
budget đã dùng;
checkpoint và version;
final outcome.

Cập nhật state bằng optimistic concurrency hoặc transaction. Nếu hai worker resume cùng run, expected version ngăn cả hai cùng tiếp tục.

Conversation history là bằng chứng, không phải state machine duy nhất.

6. Làm mọi side effect retry an toàn

Timeout không cho biết tool đã thất bại. Mỗi logical action cần operation ID ổn định. Tool write dùng idempotency key và ràng buộc database.

Ví dụ:

run_id:step_id:action_name

Nếu agent resume, nó dùng lại key cho cùng ý định. Nếu payload đổi, tạo action version mới và approval mới.

Xem Idempotency là gì? để thiết kế fingerprint, trạng thái processing và response replay.

7. Đặt điều kiện dừng và ngân sách cứng

Agent có thể loop khi tool lỗi, không tìm đủ bằng chứng hoặc tự mâu thuẫn. Mỗi run cần:

max model turns;
max tool calls;
max input/output token;
deadline;
max chi phí;
max retry mỗi dependency;
max dữ liệu đọc;
stop reason chuẩn hóa.

Khi hết budget, hệ thống nên trả partial result có provenance hoặc chuyển người, không biến mất với lỗi chung chung.

8. Áp least privilege và least agency

OWASP khuyến nghị giới hạn quyền và không giao kiểm soát authorization cho LLM. Mỗi tool và agent dùng credential riêng, scope nhỏ, thời hạn ngắn.

Least agency nghĩa là không chỉ giảm quyền truy cập mà còn giảm tự chủ:

draft trước khi send;
dry-run trước khi apply;
đề xuất trước khi xóa;
giới hạn recipient và domain;
approval cho tiền, dữ liệu và quyền;
sandbox cho code và file.

Model không cần làm thay đổi để chứng minh nó có thể đề xuất thay đổi đúng.

9. Xây eval trước khi scale traffic

OpenAI Docs nhấn mạnh trace grading để tìm lỗi ở cấp workflow. Một trace ghi model call, tool call, guardrail và handoff end-to-end.

Bộ eval cần gồm:

happy path;
dữ liệu thiếu;
tool timeout;
schema error;
user đổi yêu cầu;
prompt injection;
quyền không đủ;
duplicate và retry;
long-tail domain;
ca phải từ chối hoặc escalate.

Chấm cả final answer và trajectory. Agent có thể ra đáp án đúng bằng con đường nguy hiểm hoặc quá đắt.

10. Trace mọi bước nhưng bảo vệ dữ liệu

Trace nên nối:

request -> agent turn -> model response -> tool call
        -> tool result -> guardrail -> approval -> final outcome

Trường nên có:

trace/run/step ID;
model và prompt version;
tool version;
token, latency, cost;
retry và error class;
decision/stop reason;
policy và approval result;
final task label.

Redact secret và PII, phân quyền log, có retention. Không dùng observability như lý do lưu mọi dữ liệu vô thời hạn.

11. Human-in-the-loop phải là một workflow thật

Một nút “Approve” không đủ. Người duyệt cần thấy:

hành động cụ thể;
trước và sau;
dữ liệu nguồn;
lý do agent đề xuất;
rủi ro;
phạm vi quyền;
payload hash;
thời hạn approval;
cách từ chối hoặc chỉnh sửa.

Approval phải gắn với action payload. Nếu model thay người nhận hoặc số tiền sau khi duyệt, approval cũ hết hiệu lực.

12. Triển khai như một thay đổi rủi ro cao

Version model, prompt, tool, policy, eval và data connector. Dùng offline replay, shadow, canary rồi mới tăng traffic.

Mỗi release có:

baseline score;
expected improvement;
guardrail metric;
rollback threshold;
owner;
runbook;
change log.

Model upgrade không phải thay dependency vô hại. Hành vi tool use và từ chối có thể đổi dù prompt giữ nguyên.

Kiến trúc tham chiếu cho một production agent

Thành phần	Trách nhiệm
API Gateway	Auth, rate limit, tenant context
Task Service	Chuẩn hóa input, tạo run, SLA
Agent Runtime	Loop, context, tool routing, stop
State Store	Durable checkpoint, version, approval
Tool Gateway	Schema, authz, timeout, idempotency
Policy Engine	Rule xác định và risk tier
Human Review	Approve, edit, reject, escalate
Trace/Eval	Quan sát, grading, regression
Queue/Scheduler	Retry, resume, concurrency, deadline

Không nhất thiết tách thành chín microservice. Đây là chín trách nhiệm cần có owner; MVP có thể triển khai trong một service modular.

State machine nên có những trạng thái nào?

Một state machine tối thiểu:

CREATED
  -> RUNNING
  -> WAITING_TOOL
  -> WAITING_APPROVAL
  -> RUNNING
  -> SUCCEEDED | FAILED | CANCELLED | EXPIRED

Mỗi transition phải:

kiểm tra expected version;
lưu actor và timestamp;
ghi nguyên nhân;
có action idempotent;
xác định có retry được không;
phát event sau commit qua outbox nếu cần.

State machine giúp trả lời “run đang ở đâu?” mà không cần đọc lại toàn bộ chat.

Memory của Agent nên chia thế nào?

Working memory

Context của run hiện tại: mục tiêu, bước gần nhất, tool output cần dùng. Vòng đời ngắn.

Episodic memory

Lịch sử những run liên quan: quyết định, outcome, feedback. Chỉ truy xuất khi phù hợp.

Semantic memory

Kiến thức, policy, tài liệu và entity tương đối bền. Thường qua RAG hoặc database.

Procedural memory

Instruction, skill, workflow và tool contract.

Mọi memory cần provenance, quyền, TTL và cơ chế sửa/xóa. Không ghi mọi response thành sự thật lâu dài. Chỉ promote thông tin đã kiểm chứng.

Eval một Agent khác eval chatbot ra sao?

Chatbot thường chấm output. Agent cần chấm trajectory và environment outcome.

Lớp	Câu hỏi
Outcome	Tác vụ có hoàn thành đúng không?
Path	Có dùng đúng tool và đúng thứ tự không?
Efficiency	Có vòng lặp, token hoặc tool thừa không?
Safety	Có vượt quyền hay gửi dữ liệu không?
Recovery	Tool lỗi thì agent xử lý ra sao?
Human	Có yêu cầu duyệt đúng lúc không?

Metric gợi ý:

task success;
tool selection accuracy;
argument validity;
unauthorized action rate;
average turns/tool calls;
cost per successful task;
recovery success;
escalation precision/recall;
human acceptance;
regression theo segment.

Không dùng một LLM judge duy nhất làm ground truth cho hành động tài chính hoặc pháp lý. Kết hợp rule, environment verifier và human review.

Observability cần trả lời những câu hỏi nào?

Trong sự cố, team phải trả lời nhanh:

người dùng yêu cầu gì;
context nào được đưa vào model;
model version và prompt version nào;
tool nào được gọi với payload gì;
credential và policy nào cho phép;
side effect nào đã xảy ra;
retry có tạo trùng không;
con người đã duyệt gì;
run còn có thể tiếp tục không;
cần thu hồi hoặc đảo điều gì.

Nếu trace không nối logical action với business resource ID, điều tra sẽ dừng ở “model đã gọi tool” mà không biết dữ liệu nào thật sự đổi.

Reliability pattern nào quan trọng nhất?

Timeout theo tầng

Model, từng tool và toàn run có timeout khác nhau. Deadline phải được truyền xuống dependency.

Retry có backoff và jitter

Chỉ retry lỗi tạm thời. Giữ idempotency key. Không retry vô hạn validation error.

Circuit breaker

Khi downstream lỗi diện rộng, dừng gọi để tránh agent loop đốt chi phí.

Checkpoint và resume

Lưu sau bước có ý nghĩa. Resume từ state, không chạy lại toàn bộ prompt và side effect.

Compensation

Nếu workflow nhiều write không thể transaction chung, định nghĩa action đảo hoặc quy trình review thủ công.

Fallback

Chuyển sang model khác, workflow xác định, read-only mode hoặc human queue. Fallback phải được eval, không chỉ tồn tại trên sơ đồ.

Bảo mật production agent nên bắt đầu từ đâu?

Tối thiểu:

threat model theo từng tool;
phân loại dữ liệu;
tenant isolation;
authorization ngoài model;
input và retrieved content là không đáng tin;
output validation;
least privilege credential;
network egress allowlist;
sandbox;
approval action rủi ro;
secret scanning và redaction;
kill switch.

OWASP Top 10 for Agentic Applications 2026 là điểm tham khảo để rà soát threat. Đọc Bảo mật LLM để xem bề mặt tấn công đầy đủ.

Chi phí nên được kiểm soát ở đâu?

Chi phí agent gồm model, tool trả phí, storage, retrieval, queue, review và lỗi. Guardrail nên tồn tại ở nhiều mức:

budget mỗi turn;
budget mỗi run;
quota mỗi user/tenant;
giới hạn concurrency;
context và output cap;
tool rate limit;
spend alert;
daily hard cap;
degrade path khi vượt ngưỡng.

Theo dõi cost per successful task, không chỉ tổng token. Bài Tối ưu Agent Loop giải thích cách giảm vòng lặp và context lãng phí.

Quy trình 10 bước đưa Agent lên production

Bước 1: Chọn use case hẹp

Ưu tiên giá trị cao, dữ liệu sẵn, output kiểm chứng được và blast radius thấp.

Bước 2: Vẽ workflow hiện tại

Ghi input, quyết định, tool, handoff, SLA và exception của con người.

Bước 3: Xây baseline không agent

Một prompt hoặc workflow xác định cho biết agent có thật sự tạo thêm giá trị không.

Bước 4: Định nghĩa contract và state

Output schema, state machine, stop, budget, permission và escalation.

Bước 5: Xây tool read-only trước

Kiểm tra retrieval, trace và tool selection khi chưa có side effect.

Bước 6: Tạo eval set và failure injection

Dùng case thật đã ẩn danh, lỗi tool, prompt injection, duplicate và concurrent update.

Bước 7: Thêm write có approval

Idempotency, expected version, dry-run, diff và payload-bound approval.

Bước 8: Shadow và canary

Shadow quan sát đề xuất không thực thi. Canary cho một nhóm nhỏ với kill switch.

Bước 9: Thiết lập SLO và runbook

Success, latency, cost, policy violation, alert, owner và rollback.

Bước 10: Tạo improvement loop

Trace lỗi -> human feedback -> eval case -> sửa harness -> regression -> canary. Không sửa prompt dựa trên một screenshot đơn lẻ.

Những anti-pattern cần tránh

Agent có quyền admin mặc định

Nhanh cho demo, nguy hiểm cho production. Dùng credential theo task và scope.

Prompt vừa là policy vừa là authorization

Model có thể bỏ qua hoặc hiểu sai. Policy quan trọng phải chạy trong code xác định.

Không lưu version của prompt và tool

Khi lỗi xảy ra, không tái lập được. Version mọi artifact hành vi.

Chỉ test output cuối

Agent có thể ra đáp án đúng sau khi đọc dữ liệu trái quyền hoặc gọi tool thừa. Chấm trace.

Resume bằng cách replay toàn bộ

Side effect có thể lặp. Resume từ checkpoint và operation ID.

Multi-agent quá sớm

Routing và handoff che vấn đề task contract. Chứng minh một agent trước.

FAQ - Câu hỏi thường gặp

Xây dựng AI Agent production mất bao lâu?

Tùy use case và rủi ro. Một agent read-only hẹp có thể nhanh; agent có tiền, dữ liệu nhạy cảm hoặc nhiều hệ thống cần nhiều thời gian cho eval, approval, security và runbook.

Có cần multi-agent không?

Không mặc định. Chỉ tách khi specialist có instruction, tool, quyền hoặc eval khác rõ ràng và lợi ích vượt chi phí phối hợp.

Evals bao nhiêu case là đủ?

Không có con số chung. Bắt đầu từ failure taxonomy và use-case segments. Ưu tiên case đại diện, long-tail quan trọng và mọi sự cố production thành regression case.

Agent có nên tự sửa lỗi của mình không?

Có thể tự phục hồi trong phạm vi giới hạn như sửa argument hoặc thử nguồn khác. Không nên tự tăng quyền, bỏ policy hay retry write không idempotent.

Khi nào bỏ human approval?

Chỉ sau khi action có blast radius thấp, eval mạnh, monitoring tốt, rollback rõ và dữ liệu thực chứng minh tỷ lệ lỗi đủ nhỏ. Có thể giảm duyệt theo risk tier.

KPI quan trọng nhất là gì?

Task success có guardrail an toàn, latency và cost. Nếu phải chọn một chỉ số tổng hợp, dùng cost per successful task nhưng luôn theo dõi policy violation riêng.

Tóm lại

Xây dựng AI Agent production là đưa tính linh hoạt của model vào một hệ thống có invariant. Model được phép suy luận và đề xuất; code, state, policy và con người quyết định ranh giới.

Mười hai nguyên tắc có thể rút thành năm trụ cột:

workflow hẹp, contract và success rõ;
tool nhỏ, schema chặt, quyền tối thiểu;
state bền, version và retry idempotent;
trace cùng eval ở cấp trajectory;
approval, budget, canary và rollback.

Đọc Tối ưu Agent Loop để giảm chi phí, Bảo mật LLM để hoàn thiện threat model, và Idempotency là gì? để bảo vệ side effect khi retry.

Nguồn tham khảo

Best Practices for Building AI Agents That Work in Production, ByteByteGo.
Evaluate agent workflows, OpenAI Docs.
Running agents, OpenAI Docs.
OWASP Top 10 for Agentic Applications 2026, OWASP.
Measuring AI agent autonomy in practice, Anthropic.