Vì sao AI Agent cần một platform, không chỉ một prompt?

Trả lời nhanh: Prompt quyết định agent nghĩ gì. Platform quyết định agent làm được gì, đi được bao xa, và chuyện gì xảy ra khi nó làm sai. Prompt đủ khi tác vụ một lượt, chỉ đọc, có người duyệt. Cần runtime khi agent phải giữ state, gọi tool có rủi ro, hoặc phục hồi sau lỗi.

Khi mình nhìn một agent hoàn tiền chạy ngoài production, chỗ hỏng hiếm khi nằm ở câu chữ trong prompt. Nó quên đã xác minh đơn, gọi API lần hai, hoặc không giải thích được vì sao hoàn sai.

Vậy khi nào prompt còn đủ, khi nào nên dùng workflow tất định, và khi nào thật sự cần runtime? Mình tách từng kiểu hỏng của ca hoàn tiền ra đúng lớp hệ thống ngay dưới đây.

Khi nào prompt là đủ?

Prompt thường là đủ khi tác vụ nằm gọn trong một lần suy luận và kết quả chưa trực tiếp tạo tác động ra bên ngoài.

Cụ thể hơn, prompt đơn thuần thường phù hợp khi:

• Đầu vào đã được cung cấp sẵn, agent không phải tự đi tìm dữ liệu.
• Tác vụ kết thúc trong một hoặc hai lượt, không cần nhớ gì qua lần chạy sau.
• Không có hành động ghi dữ liệu, gửi thông tin ra ngoài hay chuyển tiền.
• Luôn có người đọc và duyệt kết quả trước khi dùng.

Tóm tắt tài liệu, phân loại phản hồi khách hàng, viết bản nháp email, gợi ý tiêu đề: đây là địa hạt của prompt. Với các tác vụ này, lớp vận hành phức tạp thường chưa mang lại lợi ích tương xứng với chi phí.

Có một lựa chọn trung gian hay bị bỏ qua: workflow tất định. Anthropic phân biệt rõ hai thứ trong bài viết về xây dựng agent hiệu quả: workflow là hệ thống trong đó LLM (Large Language Model) và tool được điều phối theo các đường dẫn đã được code định sẵn, còn agent là hệ thống trong đó LLM tự định hướng quá trình và cách sử dụng tool. Anthropic khuyến nghị bắt đầu từ giải pháp đơn giản nhất và chỉ tăng độ phức tạp khi kết quả thực sự tốt hơn, vì hệ thống agentic đánh đổi độ trễ và chi phí để lấy hiệu quả trên tác vụ khó.

Nếu đường đi từ input đến output đã biết trước, và business rule biểu diễn được bằng code, thì một workflow tất định gọi LLM ở vài điểm sẽ dễ kiểm chứng hơn một agent tự lập kế hoạch. Anthropic cũng mô tả khối xây dựng cơ bản là augmented LLM: model được bổ sung khả năng truy xuất, sử dụng tool và ghi nhớ. Đó là điểm xuất phát tự nhiên trước khi nghĩ tới bất cứ kiến trúc nào phức tạp hơn.

Microsoft mô tả cùng một ý dưới dạng nấc thang trong tài liệu về design pattern cho AI agent: đi từ gọi model trực tiếp, lên single agent, rồi mới tới multi-agent. Mỗi nấc chỉ nên leo khi nấc dưới không còn đáp ứng được.

Sáu dấu hiệu bạn đã vượt khỏi phạm vi của prompt

Hãy đưa agent hoàn tiền vào vận hành thật. Nhiệm vụ mô tả trong prompt nghe rất gọn: kiểm tra đơn hàng, đối chiếu chính sách, xác nhận lý do với khách, hoàn tiền nếu đủ điều kiện.

Ngoài production, cùng nhiệm vụ ấy trở thành một chuỗi hành động: xác thực người yêu cầu, lấy đơn hàng, tra đúng phiên bản chính sách, kiểm tra giao dịch đã từng hoàn chưa, tính số tiền, xin phê duyệt nếu vượt ngưỡng, gọi API (Application Programming Interface) thanh toán, ghi nhận kết quả, thông báo cho khách, và xử lý khi một bước bất kỳ thất bại.

Sáu dấu hiệu dưới đây cho biết bạn đã bước ra khỏi vùng mà prompt còn giải quyết được. Mỗi dấu hiệu đi kèm lớp hệ thống chịu trách nhiệm, và phần sau của bài sẽ mở từng lớp ra.

Điểm chung của sáu dòng trên: không dòng nào sửa được bằng cách viết lại câu chữ. Bạn có thể ghi đừng hoàn tiền hai lần trong prompt, nhưng câu đó không tạo ra một khóa chống trùng.

Platform là gì: prompt, harness và runtime

Platform ở đây không nhất thiết là một sản phẩm SaaS (Software as a Service). Nó là tập hợp năng lực dùng chung giúp agent tồn tại được bên ngoài một lần gọi model.

Một cách tách ba lớp dễ nhớ:

• Prompt trả lời: agent nên làm gì trong lượt này, theo nguyên tắc nào, xuất ra định dạng gì.
• Harness (lớp điều khiển hành vi agent): nạp context nào, cho phép tool nào, chạy vòng lặp ra sao, khi nào dừng.
• Runtime duy trì hoạt động: agent chạy ở đâu, giữ trạng thái thế nào, phục hồi ra sao, được quan sát bằng gì.

Ranh giới giữa harness và runtime lấy từ tài liệu Cloudflare Agents: harness lo model call, xây dựng prompt, chọn tool và chiến lược memory; runtime cung cấp state, session, routing, scheduling, thực thi bền vững và observability. Đây là cách phân lớp của Cloudflare, không nên xem là một chuẩn thuật ngữ phổ quát. Giá trị của cách chia này nằm ở việc nó buộc bạn hỏi phần này thuộc lớp nào, chứ không nằm ở bản thân từ ngữ. Mình tách riêng lớp hành vi quanh model trong Harness Engineering là gì, vì nó hay bị nhầm với việc chọn model mạnh hơn.

Prompt vẫn là thành phần bắt buộc, không phải thứ bị thay thế. OpenAI mô tả trong hướng dẫn thực hành xây dựng agent rằng một agent có ba thành phần cốt lõi: model, tools và instructions. Prompt chính là nơi chứa phần lớn instructions. Vấn đề chỉ phát sinh khi ta kỳ vọng prompt kiêm luôn vai trò của database, hệ thống phân quyền, hàng đợi, log và bộ kiểm thử.

Sáu phần tiếp theo là sáu năng lực tối thiểu để một agent hành động thật đứng vững.

1. Trạng thái bền vững và idempotency

Đây là lớp trả lời câu hỏi: agent có tiếp tục được qua thời gian, lỗi và restart không?

Một yêu cầu hoàn tiền hiếm khi kết thúc trong vài giây. Nó có thể phải chờ khách bổ sung ảnh chụp sản phẩm, chờ quản lý duyệt khoản vượt ngưỡng, chờ cổng thanh toán phản hồi. Trong khoảng chờ đó, tiến trình có thể bị restart, deploy đè lên, hoặc timeout.

Nếu toàn bộ tiến độ chỉ nằm trong context của model, tiến trình bị mất thì agent không có một bản ghi bền vững để tiếp tục. Vì vậy tác vụ chạy dài cần lưu state và kết quả trung gian bên ngoài bộ nhớ tiến trình.

Cũng nên tách rõ context và memory. Context window là dữ liệu bạn gửi vào một lần suy luận. Memory là cơ chế quyết định thông tin nào được lưu, lấy lại khi nào, trong phạm vi của ai, và giữ bao lâu. Trong ca hoàn tiền, ít nhất ba loại trạng thái nên nằm riêng:

• Trạng thái run: đã xác minh đơn hàng, đang chờ duyệt. Cần chính xác và có checkpoint.
• Lịch sử hội thoại: lý do khách đưa ra. Cần giới hạn theo session và theo user.
• Memory dài hạn: kênh liên lạc khách ưa dùng. Cần consent, thời hạn lưu và khả năng xoá.

Nối tất cả lịch sử vào prompt là cách làm dễ nhất và tệ nhất: chi phí tăng, nhiễu tăng, quyền riêng tư khó kiểm soát.

Phần khó nhất của lớp này là idempotency (chạy lại không tạo thêm một hành động). Không có nó, mọi cơ chế retry đều trở thành nguồn rủi ro: agent thử lại một lệnh hoàn tiền tưởng như thất bại, trong khi giao dịch đầu đã thành công.

Về mặt năng lực cụ thể, tài liệu persistence của LangGraph là một ví dụ đọc được: nó mô tả checkpoint lưu lại state tại từng bước, khả năng chịu lỗi và resume từ điểm gần nhất, cùng human-in-the-loop (có người duyệt trong vòng lặp) dựa trên chính cơ chế checkpoint đó. Bạn không cần dùng đúng thư viện này. Thứ đáng giữ là hình dung về việc một run có thể tạm dừng và tiếp tục trông như thế nào trong thiết kế.

2. Danh tính và quyền ở lớp tool

Model chỉ sinh ra dự đoán. Agent trở nên hữu ích khi đọc được dữ liệu thật và tác động được vào hệ thống thật qua API, function, database hay các tool khác.

Nhưng có tool chưa phải là có kiểm soát. Platform còn phải trả lời được:

• Tool nhận input và trả output theo schema nào.
• Người dùng đang được phục vụ có quyền kích hoạt tool đó không.
• Hành động là chỉ đọc, hay có ghi và khó hoàn tác.
• Credential được cấp, giới hạn phạm vi và thu hồi ra sao.
• Lỗi tạm thời khác lỗi nghiệp vụ thế nào.

Prompt có thể nhắc model tôn trọng quyền hạn. Nhưng quyền thật phải được thực thi ở nơi model không sửa được luật. Hướng dẫn kiến trúc agentic AI của AWS xếp identity, authorization và audit trail vào ngay trong lớp agent, cùng với circuit breaker để ngắt khi hành vi vượt ngưỡng an toàn. Tức là coi chúng là thành phần kiến trúc, không phải một đoạn văn trong instructions.

Với agent hoàn tiền, điều này có nghĩa rất cụ thể: tool refund không chạy dưới một credential vạn năng dùng chung, mà chạy dưới danh tính có phạm vi giới hạn, có audit trail ghi lại ai đã kích hoạt, cho đơn hàng nào, ở thời điểm nào.

Google nhấn mạnh cùng hướng trong tài liệu về core concept của AI agent: bảo mật là một trong những mối quan tâm nền tảng khi đưa agent lên production, bên cạnh runtime, trace và evaluation.

3. Orchestration có giới hạn

Orchestration là lớp quyết định bước nào chạy trước, output nào chuyển tiếp cho bước sau, khi nào rẽ nhánh, khi nào thử lại, khi nào kết thúc và khi nào giao lại cho người.

JetBrains mô tả vòng lặp này trong bài về orchestration cho AI agent như chu trình lập kế hoạch, định tuyến, thực thi, quan sát và điều chỉnh, và lưu ý rằng orchestration cần thiết ngay cả với một agent duy nhất, chứ không phải chỉ khi có nhiều agent. OpenAI cũng mô tả agent vận hành theo một run loop chạy tới khi đạt điều kiện thoát, và khuyến nghị bắt đầu bằng single agent trước khi nghĩ đến kiến trúc nhiều agent.

Prompt chaining cố định chỉ chạy được A → B → C. Một orchestration loop thật phải xử lý được tình huống hệ thống trả về đơn hàng này đã được hoàn một phần: nghĩa là rẽ nhánh sang một quy trình khác, chứ không phải đi tiếp bước C như kế hoạch ban đầu.

Phần quan trọng nhất là các giới hạn được thực thi. Đây là nơi bạn chặn vòng lặp vô hạn và chi phí mất kiểm soát bằng những điều kiện nằm trong code:

• Số bước tối đa của một run.
• Ngân sách token và chi phí.
• Số lần gọi mỗi tool.
• Thời gian chạy tối đa.
• Số lần retry trước khi bàn giao cho người.

Microsoft nêu thẳng giới hạn số vòng lặp như một biện pháp thiết kế cần thiết, chứ không phải tùy chọn nâng cao. Một câu đừng thử quá nhiều lần đặt cuối prompt không có hiệu lực cưỡng chế nào.

4. Guardrail nhiều lớp và phê duyệt của người

Quyền của agent càng lớn, một quyết định sai càng đắt. Vì vậy guardrail (hàng rào an toàn) không nên là một lớp đơn.

OpenAI khuyến nghị tiếp cận layered defense: kết hợp nhiều loại guardrail thay vì dựa vào một cơ chế duy nhất, cùng với authentication, authorization và các biện pháp bảo mật phần mềm thông thường. Các lớp thường gặp gồm kiểm tra dữ liệu đầu vào, lọc thông tin nhạy cảm, giới hạn phạm vi hành động, tách quyền đọc khỏi quyền ghi, và kiểm tra đầu ra trước khi nó biến thành hành động.

Lớp cuối cùng là can thiệp của con người. OpenAI nêu hai tình huống kích hoạt rõ ràng: khi agent vượt ngưỡng lỗi hoặc thất bại lặp lại, và khi hành động thuộc nhóm rủi ro cao. Với agent hoàn tiền, ranh giới đó vẽ được rất cụ thể. Khoản dưới ngưỡng chính sách thì agent tự xử lý; khoản vượt ngưỡng thì dừng lại và chờ người duyệt.

Điểm mấu chốt phân biệt guardrail với prompt: prompt định hướng hành vi, còn guardrail phải có khả năng chặn hành vi. Nếu một cơ chế chỉ hoạt động khi model chịu hợp tác, nó không phải guardrail.

Đây cũng là lý do human-in-the-loop cần được thiết kế ở lớp runtime chứ không phải lớp giao diện. Một điểm chờ phê duyệt chỉ hoạt động được nếu run có thể tạm dừng, giữ nguyên state, và tiếp tục sau khi người duyệt trả lời. Đó chính là cơ chế checkpoint đã nói ở phần 1.

5. Observability và trace

Khi một khoản hoàn tiền sai xảy ra, câu hỏi đầu tiên là vì sao. Nếu bạn chỉ log câu trả lời cuối, câu hỏi đó không có lời đáp.

Observability (khả năng quan sát hệ thống) ở đây nghĩa là team đọc được toàn bộ run, không chỉ output. Một trace đủ dùng cho agent thường ghi lại:

• Phiên bản model và phiên bản prompt.
• Context hoặc tài liệu đã truy xuất.
• Từng tool call: tham số, kết quả, độ trễ.
• Các lần retry và các lần bàn giao.
• Token, chi phí, thời gian.
• Quyết định phê duyệt hoặc từ chối.
• Trạng thái cuối của run.

Giá trị lớn nhất của trace là giúp phân biệt bốn nguyên nhân dễ bị nhầm lẫn: lỗi model, lỗi truy xuất context, lỗi tool, và lỗi workflow. Trong ca hoàn tiền, agent hoàn sai số tiền có thể là model tính sai, có thể là tool trả về đơn hàng cũ, cũng có thể là workflow bỏ qua bước kiểm tra hoàn một phần. Ba nguyên nhân đó cần ba cách sửa hoàn toàn khác nhau, và không cái nào đoán được nếu chỉ nhìn output.

Google xếp trace cùng nhóm với runtime, bảo mật và evaluation trong các mối quan tâm khi vận hành agent ở production. Tức là hạ tầng quan sát không phải thứ thêm sau, mà là điều kiện để agent vận hành được.

6. Evals chạy trước và sau mỗi thay đổi

Prompt thường được tinh chỉnh bằng vài lần thử tay. Cách này nhanh ở giai đoạn đầu và mù ở giai đoạn sau: bạn sửa một câu để xử lý tốt hơn ca hoàn trễ hạn, rồi không biết mình vừa làm hỏng ca đơn đã hoàn một phần.

Bộ eval cho agent nên bao gồm:

• Tập tình huống đại diện, kèm các edge case đã từng gây lỗi thật.
• Tiêu chí thành công cho từng bước, không chỉ cho kết quả cuối.
• Kiểm tra tất định với schema, quyền và business rule.
• Đánh giá bằng người hoặc bằng model khi tiêu chí mang tính ngữ nghĩa.
• So sánh giữa các phiên bản prompt, model, tool và workflow.

Điểm cần nhấn: đánh giá agent khác đánh giá một câu trả lời. Một run có thể cho ra kết quả đúng qua một chuỗi bước sai, ví dụ hoàn đúng số tiền nhưng đã bỏ qua bước kiểm tra trùng lặp. Chỉ chấm output cuối sẽ cho điểm cao cho một hành vi nguy hiểm.

Về mặt triển khai, tài liệu evaluate và monitor GenAI app của Databricks (cập nhật 2026-07-28) là một ví dụ về cách nối vòng đời này: dùng trace làm đơn vị dữ liệu chung, chấm điểm bằng scorer trong giai đoạn phát triển, rồi tiếp tục chấm trên lưu lượng production để phát hiện suy giảm chất lượng. Đây chỉ là một cách hiện thực hóa. Thứ nên giữ lại là nguyên tắc dùng cùng một bộ tiêu chí ở cả development lẫn production, để tốt hơn là một kết luận đo được chứ không phải cảm giác.

Ba mức trưởng thành

Yêu cầu một platform không có nghĩa phải mở đầu bằng Kubernetes, multi-agent và một dashboard lớn. Ba mức dưới đây là ba điểm dừng hợp lý khác nhau.

Mức 1: Prompted feature

Tác vụ một lượt, chỉ đọc dữ liệu được đưa sẵn, không tạo tác động bên ngoài, luôn có người kiểm tra output. Đủ dùng: quản lý phiên bản prompt và một tập test nhỏ.

Mức 2: Agent runtime tối thiểu

Tác vụ nhiều bước, gọi vài tool, cần giữ trạng thái xuyên suốt một run: đúng ca hoàn tiền. Cần: run ID và state store, tool schema kèm permission, timeout và giới hạn vòng lặp, structured logs, phê duyệt trước hành động rủi ro, eval cho các luồng quan trọng. Đây thường là điểm dừng hợp lý cho một team nhỏ.

Trong mã nguồn mở, GoClaw minh họa khá rõ cách phân lớp này: prompt chỉ là một stage trong agent pipeline, còn history, tool, memory, multi-agent orchestration và tracing được xử lý như các thành phần riêng. Đây nên được xem là một ví dụ kiến trúc để tham khảo, không phải lý do để team nhỏ bê nguyên cả stack.

Mức 3: Shared agent platform

Nhiều agent hoặc nhiều team lặp lại cùng nhu cầu: registry cho agent và tool, identity và policy dùng chung, secrets, quota và cost control tập trung, deployment kèm versioning và rollback, observability ở cấp tổ chức. IBM mô tả nhu cầu này trong bài về AI agent management: khi số lượng agent tăng lên, tổ chức cần một control plane (lớp điều khiển nền tảng) dùng chung để quản lý và giám sát chúng một cách nhất quán, thay vì để mỗi agent tự mang theo cơ chế riêng.

Nếu bạn mới có đúng một use case, dựng hạ tầng mức 3 trước thường tốn nhiều hơn giá trị nó mang lại.

Kiến trúc tối thiểu cho một team nhỏ

Gọn hơn bạn nghĩ. Một platform mức 2 đủ cho agent hoàn tiền có thể chỉ gồm bảy thành phần:

1. API nhận goal và tạo run_id.
2. Orchestrator có giới hạn chạy agent loop với số bước và ngân sách rõ ràng.
3. Tool registry nhỏ khai báo schema, quyền, timeout và mức rủi ro của từng tool.
4. Database lưu trạng thái run, checkpoint và kết quả tool quan trọng.
5. Approval queue cho các hành động ghi, gửi hoặc chuyển tiền.
6. Trace store ghi model, prompt version, tool call, latency, cost và lỗi.
7. Eval suite chạy trước mỗi lần đổi prompt, model hoặc workflow.

Bảy thứ này đã là một platform theo nghĩa kiến trúc: một đường chạy chuẩn, có policy và có khả năng quan sát. Chúng hoàn toàn có thể nằm gọn trong một codebase, dùng hạ tầng sẵn có, và phục vụ đúng một agent.

Nguyên tắc nên giữ: chuẩn hóa những gì lặp lại, đừng trừu tượng hóa những gì chưa tồn tại. Đến khi agent thứ hai cần đúng cơ chế tool permission hoặc tracing đó, hãy tách nó thành capability dùng chung.

Checklist quyết định

Trước khi viết dòng code đầu tiên, chạy qua sáu câu hỏi này:

1. Đường đi từ input đến output đã biết trước chưa? Nếu rồi, dùng workflow tất định, không cần agent.
2. Agent có thực hiện hành động khó hoàn tác không? Nếu có, cần tool schema, permission và bước phê duyệt cho đúng hành động đó.
3. Một run có thể bị gián đoạn hoặc phải chờ bên khác không? Nếu có, cần state bền vững, checkpoint và idempotency.
4. Hành động có nguy cơ lặp lại gây hậu quả kép không? Nếu có, cần khóa chống trùng ở lớp tool, không phải ghi chú trong prompt.
5. Khi sự cố xảy ra, team có giải thích được agent đã làm gì không? Nếu không, cần trace chi tiết theo bước.
6. Bạn có cách chứng minh phiên bản mới không làm hỏng ca cũ không? Nếu không, cần eval chạy trước và sau thay đổi.

Câu trả lời không ở câu 1 và có ở bất kỳ câu nào từ 2 đến 6 đều chỉ tới một lớp hệ thống cụ thể cần bổ sung, không phải một prompt cần viết lại.

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

Những câu dưới đây hay xuất hiện khi team đã có prompt khá ổn nhưng chưa chắc đang thiếu lớp nào. Trả lời ngắn, rồi mới quyết định có cần thêm harness hay runtime.

Prompt engineering có còn quan trọng khi đã có platform không?

Có. Prompt vẫn định nghĩa mục tiêu, nguyên tắc và cách model sử dụng context. Platform không sửa được một chỉ dẫn mơ hồ; nó chỉ đảm bảo chỉ dẫn ấy nhận đúng dữ liệu, chạy trong giới hạn và được đo qua từng phiên bản.

Dùng framework agent có nghĩa là đã có platform chưa?

Không hẳn. Framework thường giúp dựng agent loop, tool calling hoặc workflow. Hệ thống production còn cần state bền vững, identity, permission, secrets, deployment, tracing, eval, approval và quy trình xử lý sự cố. Hãy đối chiếu danh sách năng lực thực tế thay vì nhìn nhãn.

Một agent duy nhất có cần orchestration không?

Có, nếu nó chạy nhiều bước. Orchestration ở đây là cơ chế theo dõi state, gọi tool, xử lý kết quả, giới hạn retry và quyết định điểm dừng. Multi-agent chỉ là một topology phức tạp hơn, không phải điều kiện để có orchestration.

Có nên bắt đầu bằng multi-agent không?

Thường là không. Cả OpenAI lẫn Microsoft đều khuyến nghị tối ưu single agent trước. Chỉ tách nhiều agent khi một agent không còn xử lý đáng tin cậy vì prompt quá phức tạp, tool quá tải, hoặc cần cô lập quyền giữa các domain thật sự khác nhau.

Có tiêu chí số nào quyết định lúc nào được phép xây platform không?

Không. Chỉ một hành động tạo tác động thật cũng đã có thể cần schema, permission, guardrail và approval. Ngược lại, một agent chạy mười bước nhưng chỉ đọc dữ liệu công khai thì rủi ro thấp hơn nhiều. Rủi ro của hành động, chứ không phải số bước, mới là thứ quyết định.

Việc nên làm tiếp theo

Đừng bắt đầu bằng việc chọn platform. Hãy bắt đầu bằng một bài tập cụ thể, làm được trong một buổi:

Lấy agent bạn đang có. Viết ra chuỗi bước thật của nó khi chạy ngoài production, kèm mọi lần nó chạm vào hệ thống bên ngoài. Với mỗi bước, trả lời ba câu: bước này có ghi dữ liệu không, bước này có thể bị gián đoạn không, và nếu bước này sai thì tôi biết bằng cách nào?

Bước đầu tiên trả lời có cho câu 1 hoặc câu 2, hoặc không biết cho câu 3, chính là failure mode đầu tiên prompt không giải quyết được. Thêm đúng lớp hệ thống cho bước đó: một khóa chống trùng, một điểm phê duyệt, một trace, rồi dừng lại. Lặp lại khi bước tiếp theo cần đến.

Đó là cách một platform hình thành: từ các rủi ro có thật, không phải từ một sơ đồ kiến trúc vẽ trước.

Bạn có thể đọc thêm các bài về ứng dụng AI thực tế tại nguyennlt.com.