Xây dựng AI agent hiệu quả

• Các đội ngũ triển khai thành công agent dựa trên LLM có xu hướng dùng những mẫu đơn giản, có thể kết hợp thay vì framework phức tạp
• Cần hiểu rõ khác biệt về cấu trúc giữa workflow và agent, đồng thời nên ưu tiên chỉ đưa vào mức độ phức tạp tối thiểu để có được giải pháp tối ưu
• Nhiều mẫu agent khác nhau như prompt chaining, routing, parallelization, orchestrator-workers, vòng lặp evaluator-optimizer... đang được dùng trong môi trường production, và mỗi mẫu đều có trường hợp sử dụng cùng ưu/nhược điểm riêng
• Khi triển khai agent, các nguyên tắc cốt lõi là tính đơn giản, tính minh bạch, thiết kế giao diện, đồng thời cần chú ý đến thiết kế công cụ và prompt engineering
• Ngày càng có nhiều trường hợp agent thực sự mang lại giá trị trong hỗ trợ khách hàng hoặc môi trường phát triển phần mềm

---

Tổng quan

Trong một năm qua, Anthropic đã xây dựng agent dựa trên mô hình ngôn ngữ lớn (LLM) cùng với các đội ngũ ở nhiều lĩnh vực công nghiệp khác nhau. Trên thực tế, những trường hợp triển khai agent thành công thường có xu hướng dựa trên các mẫu đơn giản, có thể kết hợp, thay vì framework phức tạp hay thư viện chuyên biệt. Bài viết này chia sẻ những insight rút ra từ quá trình hợp tác với khách hàng và kinh nghiệm phát triển nội bộ, cùng với lời khuyên thực tiễn để xây dựng agent hiệu quả.

Agent là gì

Agent có thể được định nghĩa theo nhiều cách khác nhau.

• Một số người định nghĩa đó là hệ thống hoàn toàn tự trị, có thể dùng công cụ bên ngoài để tự mình hoàn thành các tác vụ phức tạp
• Một số khác hiểu đó là cách triển khai mang tính quy định sẵn, đi theo workflow giới hạn hoặc quy trình đã được xác định trước

Anthropic xếp cả hai vào nhóm hệ thống mang tính agentic, nhưng vẫn phân biệt rõ sự khác nhau quan trọng về kiến trúc giữa workflow và agent.

• Workflow: cấu trúc trong đó LLM và công cụ được điều phối theo một đường đi mã đã được định nghĩa trước
• Agent: LLM tự quyết định một cách động việc sử dụng công cụ và quy trình, đồng thời nắm quyền kiểm soát cách hoàn thành nhiệm vụ

Bài viết này sẽ giải thích chi tiết cả hai dạng hệ thống, còn các ví dụ áp dụng thực tế được đề cập trong phụ lục 1.

Khi nào nên dùng agent (và khi nào không nên)

Khi phát triển ứng dụng, nên lấy mức độ phức tạp tối thiểu làm nguyên tắc và chỉ bổ sung thêm độ phức tạp một cách dần dần khi thực sự cần.

• Hệ thống agentic có thể cải thiện hiệu suất tác vụ dù phải đánh đổi một phần độ trễ/chi phí
• Nếu không thật sự cần tới độ phức tạp, rất nhiều trường hợp có thể giải quyết đầy đủ chỉ bằng một lần gọi LLM, few-shot prompting, tích hợp retrieval...
• Workflow phù hợp khi tính dự đoán được và tính nhất quán là quan trọng, còn agent phù hợp khi cần tính linh hoạt và khả năng mở rộng

Khi nào và cách dùng framework

Có nhiều framework giúp việc triển khai hệ thống agentic trở nên dễ dàng hơn.

• LangGraph (LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum v.v.

Các framework này giúp đơn giản hóa những công việc ở tầng thấp như gọi LLM, định nghĩa/phân tích công cụ, cấu thành chuỗi gọi. Tuy nhiên, do mức độ trừu tượng hóa quá cao, luồng prompt/phản hồi thực tế có thể trở nên thiếu minh bạch, hoặc làm độ phức tạp tăng lên không cần thiết.

• Tác giả khuyến nghị nhà phát triển nên bắt đầu bằng cách dùng trực tiếp LLM API tối đa có thể
• Ngay cả khi dùng framework, vẫn cần hiểu chính xác cách nó vận hành bên trong

Có thể xem các ví dụ triển khai tại anthropic-cookbook.

Building block, workflow và các mẫu agent

Anthropic giới thiệu các mẫu hệ thống agentic thường được dùng trong môi trường vận hành thực tế.

Building block: LLM tăng cường

Cốt lõi của hệ thống agentic là LLM được tăng cường bằng các chức năng như retrieval, công cụ, bộ nhớ.

• Mô hình có thể tự thực hiện tạo truy vấn tìm kiếm, chọn công cụ phù hợp và lưu trữ thông tin
• Điểm quan trọng khi triển khai là tùy biến các chức năng cho phù hợp với trường hợp sử dụng và cung cấp cho LLM một giao diện rõ ràng, được tài liệu hóa đầy đủ

Thông qua Model Context Protocol mới được công bố, có thể tích hợp đơn giản với nhiều công cụ bên thứ ba khác nhau.

Giải thích theo từng loại workflow

Prompt chaining

• Phân tách tác vụ thành một chuỗi bước, trong đó mỗi lần gọi LLM xử lý tiếp dựa trên kết quả trước đó
• Có thể quản lý quy trình bằng cách thêm kiểm tra mang tính lập trình (gate) ở từng bước
• Ví dụ áp dụng: tạo nội dung marketing rồi dịch, thiết kế dàn ý tài liệu → kiểm chứng → viết nội dung

Routing

• Phân loại đầu vào rồi rẽ nhánh sang tác vụ tiếp theo phù hợp
• Có thể dùng prompt và công cụ chuyên biệt cho từng danh mục
• Ví dụ áp dụng: phân luồng yêu cầu khách hàng (hoàn tiền, hỗ trợ kỹ thuật...), chọn mô hình theo độ khó...

Parallelization

• Chia tác vụ thành các phần nhỏ, xử lý song song rồi tổng hợp kết quả
• Sectioning: xử lý độc lập từng phần
• Voting: lặp lại cùng một tác vụ với nhiều góc nhìn/prompt khác nhau rồi dùng đa số phiếu hoặc cách tương tự
• Ví dụ áp dụng: lọc câu hỏi người dùng và tách phản hồi, đánh giá tự động, review code...

Orchestrator-workers

• Một LLM trung tâm động phân tách/phân công tác vụ, nhiều worker LLM xử lý từng phần rồi kết hợp lại
• Phù hợp với các subtasks không được xác định trước mà thay đổi theo đầu vào
• Ví dụ áp dụng: chỉnh sửa code trên nhiều file, tìm kiếm thông tin phức tạp...

Vòng lặp evaluator-optimizer

• Dùng lặp đi lặp lại một LLM phản hồi và một LLM đánh giá
• Phù hợp trong những tình huống có tiêu chí đánh giá rõ ràng và việc cải thiện dựa trên phản hồi là có giá trị
• Ví dụ áp dụng: đánh giá sắc thái tinh tế trong dịch văn học, tìm kiếm thông tin qua nhiều vòng...

Agent

• Cùng với sự phát triển của LLM, đã xuất hiện các agent trong dịch vụ thực tế có khả năng xử lý đầu vào phức tạp, suy luận/lập kế hoạch, sử dụng công cụ, phục hồi lỗi

• Bắt đầu từ lệnh/cuộc hội thoại của người dùng → làm rõ tác vụ rồi tự chủ thực thi → có thể nhận phản hồi tại các checkpoint trung gian → kết thúc khi hoàn tất hoặc khi đạt điều kiện dừng

• Trong triển khai thực tế, LLM sẽ lặp lại dựa trên phản hồi từ môi trường (kết quả công cụ, thực thi code), và bộ công cụ cùng tài liệu hóa là yếu tố cốt lõi

• Ví dụ áp dụng: coding agent để giải các tác vụ SWE-bench, tự động hóa thao tác máy tính dựa trên Claude

• Phạm vi áp dụng: các bài toán mở không thể dự đoán trước đường đi hay các bước cố định, hoặc những tình huống cần độ tin cậy trong ra quyết định

• Cần cân nhắc chi phí và khả năng lỗi phức hợp do mức độ tự chủ tăng lên, đồng thời bắt buộc có kiểm thử sandbox và guardrail

Kết hợp và tùy biến mẫu

• Các building block được giới thiệu không phải là quy tắc cứng nhắc mà có thể kết hợp để phù hợp với nhiều tình huống khác nhau
• Điều quan trọng là chọn được cấu trúc tối ưu thông qua đo lường kết quả/cải tiến lặp lại và chỉ bổ sung độ phức tạp một cách dần dần

Tóm tắt và nguyên tắc khuyến nghị

Thành công của hệ thống LLM không nằm ở độ phức tạp hay công nghệ mới, mà ở việc tìm được cách tiếp cận chính xác phù hợp với mục tiêu.

• Bắt đầu bằng prompt đơn giản, đánh giá kết quả và tối ưu lặp lại, rồi mở rộng độ phức tạp theo từng bước

• 3 nguyên tắc lớn trong thiết kế agent

  1. Giữ sự đơn giản
  2. Ưu tiên tính minh bạch (làm rõ ngay từ giai đoạn thiết kế)
  3. Coi trọng tài liệu hóa/kiểm thử công cụ và giao diện

• Framework có thể giúp khởi đầu nhanh, nhưng trên thực tế việc tối thiểu hóa lớp trừu tượng và năng lực tự triển khai trực tiếp mới là yếu tố quyết định độ tin cậy và khả năng bảo trì

Phụ lục 1: Các trường hợp áp dụng agent trong thực tế

Hỗ trợ khách hàng

Lĩnh vực hỗ trợ khách hàng kết hợp giao diện chatbot và tích hợp công cụ, nên rất phù hợp một cách tự nhiên để áp dụng agent.

• Đồng thời tồn tại nhu cầu về giao diện hội thoại và xử lý công việc/dữ liệu bên ngoài
• Có thể kết nối qua công cụ với thông tin khách hàng, lịch sử đơn hàng, knowledge base...
• Tự động hóa các công việc như hoàn tiền/xử lý ticket
• Có thể thiết lập rõ ràng tiêu chí giải quyết

Những trường hợp áp dụng thành công đã xác minh hiệu quả của agent bằng mô hình tính phí dựa trên mức sử dụng (theo tiêu chí giải quyết thành công).

Coding agent

Ngay trong môi trường phát triển phần mềm, mức độ hữu dụng của agent như tự động giải quyết vấn đề cũng đang tăng mạnh.

• Có thể xác minh kết quả code bằng kiểm thử tự động
• Có thể cải thiện lặp lại dựa trên kết quả kiểm thử
• Bài toán được định nghĩa rõ ràng và chất lượng đầu ra cũng có thể đo lường khách quan

Trường hợp triển khai nội bộ của Anthropic: trên benchmark SWE-bench Verified, hệ thống giải quyết các GitHub issue thực tế chỉ với phần mô tả pull request. Bên cạnh kiểm thử tự động, đánh giá của con người vẫn quan trọng để xác nhận toàn bộ hệ thống có đáp ứng yêu cầu tổng thể hay không.

Phụ lục 2: Cách làm prompt engineering cho công cụ

Trong mọi hệ thống agentic, công cụ là yếu tố cốt lõi.

• LLM như Claude có thể tương tác với dịch vụ bên ngoài qua API theo đúng cấu trúc và định nghĩa đã xác định
• Phản hồi có thể bao gồm tool use block
• Bản thân định nghĩa và đặc tả công cụ cũng cần được thiết kế tỉ mỉ như prompt engineering

Mẹo thiết kế format công cụ

• Dành đủ token để mô hình không rơi vào các “bẫy” khi soạn nội dung

• Khuyến nghị dùng format tự nhiên mà mô hình thường gặp nhiều trên Internet

• Giảm thiểu overhead format không cần thiết (ví dụ: đếm số dòng code, escape chuỗi...)

• Cũng như khi đầu tư thiết kế giao diện người-máy (HCI), cần dành sự chăm chút tương tự cho giao diện agent-máy tính (ACI)

• Từ góc nhìn của mô hình, cách hiểu và sử dụng công cụ phải thật ‘rõ ràng’, bao gồm cả ví dụ sử dụng, điều kiện biên, format đầu vào...

• Tên tham số và mô tả cũng nên được thiết kế như viết tài liệu (docstring), dùng thuật ngữ trực quan

• Kiểm thử cách dùng thực tế với nhiều giá trị đầu vào khác nhau và cải tiến lặp lại

• Thiết kế argument theo hướng giảm sai sót (Poka-yoke)

Khi xây dựng agent SWE-bench thực tế, nhóm đã dành nhiều thời gian tối ưu thiết kế công cụ hơn cả prompt tổng thể. Ví dụ: để giảm lỗi sai đường dẫn file sau khi rời khỏi thư mục gốc, họ đổi sang chỉ nhận đường dẫn tuyệt đối và hệ thống hoạt động hoàn hảo.

[GN⁺]

Ý kiến trên Hacker News

• Có ý kiến cho rằng điều đặc biệt ấn tượng là bài viết bắt đầu bằng việc làm rõ định nghĩa về "AI agents". Định nghĩa được dùng ở đây là "một hệ thống trong đó LLM tự động quản lý quy trình và việc sử dụng công cụ, đồng thời tự kiểm soát cách thực hiện công việc". Người này cũng thích cách bài viết phân biệt giữa ‘agent’ và ‘workflow’, cũng như cách giới thiệu nhiều mẫu workflow thực tiễn. Khi bài này mới xuất hiện, họ cũng đã tự viết một bài tổng hợp: ghi chú về building-effective-agents. Ngoài ra, gần đây họ cũng thấy thú vị với bài hành trình xây dựng hệ thống nghiên cứu multi-agent của Anthropic, và cũng có thêm ghi chú về chủ đề này: ghi chú về multi-agent research system

  • Có ý kiến cho rằng định nghĩa workflow trong bài này không thật sự chính xác. Các workflow engine hiện nay thường không đi theo những nhánh mã được định sẵn từ trước, mà trong nhiều trường hợp hoạt động gần như giống hệt agent. Theo người này, tác giả đã định nghĩa lại workflow để tạo sự phân biệt, nhưng trên thực tế thì agent cũng chỉ là một dạng workflow theo vòng lặp, gọi động dựa trên phản hồi của LLM. Họ cho rằng các workflow engine hiện đại cũng rất động

  • Một trong các đồng tác giả của Building Effective Agents cũng đã có một buổi thuyết trình về bài viết này tại AIE, và phản hồi nhận được rất tốt: video YouTube

  • Có ý kiến cho rằng bài viết về nghiên cứu multi-agent thật sự rất hay, nhưng họ không đồng ý với lập luận trong Building Effective AI Agents rằng "xây dựng hệ thống từ đầu mà không dùng framework là tốt hơn về mặt giáo dục". Lợi ích đầu tiên của việc dùng một framework tốt là có thể dễ dàng thử nghiệm nhiều LLM khác nhau, kể cả từ nhiều nhà cung cấp

  • Có người đặt câu hỏi không biết Anthropic đang sử dụng AI agent framework nào. Họ cho rằng có vẻ như công ty này chưa từng công khai framework nội bộ của mình

  • Có phản hồi cảm ơn vì các ghi chú bổ sung, đồng thời nói rằng gần đây chủ đề này cũng là một vấn đề rất quan trọng với bản thân họ

• Có cảm nhận rằng trong lĩnh vực AI, nửa năm đã là một quãng thời gian rất dài. Người này nói rằng vài tháng trước họ đã đọc đi đọc lại bài này nhiều lần, nhưng giờ cảm thấy việc phát triển agent rõ ràng đang chạm tới nút thắt cổ chai. Họ còn cho rằng ngay cả Gemini mới nhất dường như cũng bị thụt lùi về hiệu năng

  • Việc chạy nhiều agent cùng lúc rất tốn kém, làm giảm RoI. Ví dụ, DeepSearch agent cho chứng khoán dùng 6 agent và tốn khoảng 2 USD cho mỗi truy vấn. Việc điều phối multi-agent rất khó kiểm soát, và nếu mô hình mạnh hơn thì nhu cầu multi-agent lại giảm đi. Ngược lại, mô hình càng yếu thì giá trị kinh doanh của các AI chuyên biệt, phạm vi hẹp lại càng tăng. Đây là chia sẻ từ trải nghiệm thực tế

  • Có người hỏi vì sao lại có cảm giác agent đang thoái lui. Họ thắc mắc tại sao agent không thể просто tự tạo ra nhiều bản sao của chính mình để làm việc song song 24/7, tự kiểm chứng và tiếp tục cải thiện

  • Có ý kiến cho rằng việc giải quyết vấn đề prompt injection là cực kỳ khó, và đây đang trở thành một nút thắt nghiêm trọng

• Có người tò mò agent xử lý task queueing, race condition và các vấn đề đồng thời khác như thế nào. Trong các bài viết về xây dựng workflow multi-agent, thường thấy nói rằng orchestrator agent sẽ quản lý toàn bộ, nhưng họ luôn tự hỏi liệu trên thực tế có cần thiết kế phức tạp hơn và glue code thông minh hơn không. Hay tất cả những thứ này thật sự hoạt động như một kiểu “phép màu tự động”

  • Có lời giải thích rằng tiêu chuẩn của agent là các công cụ được chạy tuần tự, nên không cần quá lo về vấn đề đồng thời. Hiện nay nhiều mô hình đã hỗ trợ gọi tool song song, nên khi mô hình yêu cầu “chạy ba công cụ này”, harness sẽ thực thi song song hoặc tuần tự rồi chuyển kết quả sang bước tiếp theo. Anthropic đang tận dụng mạnh hơn mô hình multi-agent, trong đó agent cấp trên ủy quyền công việc song song cho các agent cấp dưới. Mẹo này đang được áp dụng trong Claude Code, và cũng được giải thích thêm trong ghi chú reverse engineering liên quan (claude-trace) cũng như bài viết về cách Claude Research hoạt động (multi-agent-research-system). Giai đoạn khám phá các mẫu sử dụng tool của LLM vẫn còn rất sớm, và việc mô hình thật sự trở nên giỏi dùng tool cũng chỉ mới là chuyện của 6 tháng gần đây, nên tiềm năng phát triển phía trước còn lớn

  • Vì vậy, có người nói rằng họ dần thích hướng để LLM tự viết code xử lý tool call hơn là biến mọi thứ thành JSON. Thư viện smolagents của Huggingface dùng cách để LLM tạo mã gọi hàm python. Nếu muốn gọi tool song song thì chỉ cần ghi rõ trong prompt, và LLM cũng phải tự xử lý đồng bộ hóa. Tất nhiên vẫn có vấn đề khi thực thi đoạn mã do LLM tạo ra, nhưng đã có nhiều cách giải quyết

  • Có chia sẻ về trường hợp dùng giao diện web Codex. Họ có một kế hoạch refactor quá dài để làm trong một lần, nên dùng tính năng “ask” để chia nhỏ thành nhiều việc và gom các việc có thể làm song song. LLM đã chia việc khá giống cách một nhóm thực tế phân công, nhưng vì không có giả định về giao tiếp giữa các tác vụ nên thất thoát ngữ cảnh rất lớn. Dù mất nhiều thời gian hơn tự làm, họ vẫn thử theo hướng xử lý tuần tự bằng cách mở nhiều session và cung cấp prompt chi tiết cho từng việc, gồm mục tiêu, phương pháp, xác minh, tài liệu hóa, v.v. Tóm lại, theo trải nghiệm thực tế này, orchestrator agent có thể dùng cho những việc rất đơn giản, nhưng phạm vi áp dụng hẹp hơn tưởng tượng nhiều

  • Có quan điểm rằng không có gì thật sự vận hành như phép màu tự động. Những đặc tính vận hành cần quan tâm trong các hệ thống truyền thống thì với AI agent cũng vẫn phải được phát triển đầy đủ. Nếu chỉ nhìn demo AI agent rồi nghĩ rằng có thể thay toàn bộ mã của một đội viết spaghetti code bằng vài prompt AI gọn gàng thì rất dễ bị đánh lừa. Thực tế có thể chạy được trong một số ít trường hợp, nhưng rốt cuộc mọi đoạn mã đều tồn tại trong hệ thống vì một lý do nào đó, và nếu cuối cùng lại phải dịch toàn bộ đống mã ấy vào cho LLM thì đó là dấu hiệu đã mất phương hướng

  • Với coding agent, một mẫu đang nổi lên là dùng container để cô lập công việc, rồi dùng git để review và merge kết quả. Ví dụ có trường hợp dùng container và MCP tại đây: container-use, khá hữu ích cho công việc viết mã song song. Ngoài ra, trong các công việc khác thì những workflow builder như n8n, Zapier, CrewAI vẫn còn được dùng rất thường xuyên

• Có ý kiến cho rằng bài viết này nhắc lại thông điệp hãy bắt đầu từ “thứ đơn giản nhất”, rồi chỉ thêm độ phức tạp khi thật sự cần. Họ đề cập khả năng xây dựng một hệ thống ổn định hơn, dễ debug hơn và rẻ hơn chỉ với những lời gọi LLM được định nghĩa rõ ràng cùng một chút glue logic đơn giản. Ngược lại, các hệ thống agent trông hào nhoáng thường lại gây ra nhiều vấn đề hơn

• Có lời bày tỏ hy vọng rằng AI sẽ trở thành thứ thật sự giúp ích cho con người

• Có ý kiến cho rằng thật tốt khi Anthropic cung cấp những thông tin kỹ thuật như vậy, nhưng công ty cũng nên có một phiên bản hướng dẫn dễ hiểu cho người không chuyên. Ví dụ, nếu bộ phận marketing muốn đưa agent vào sử dụng thì họ cần một hướng dẫn ở mức cơ bản để có thể xác định đặc tả. Dù phần cuối bài và phụ lục có nhắc đến điều này, nhưng vẫn bị chỉ ra rằng nội dung vẫn đang dừng ở khía cạnh triển khai, tức là “xây như thế nào”

• (Tháng 12 năm 2024 - một thời điểm mà bây giờ nghĩ lại thấy như đã rất lâu rồi)

  • Á á á, giờ lại phải dùng não và quay về thời kỳ tháng 12 năm 2024, tự viết 100% mã như người tiền sử vậy sao — một phản hồi đùa vui bình luận liên quan

  • Có ý kiến cho rằng bài viết này đang đứng vững rất tốt. Cá nhân họ vẫn liên tục dùng nó làm tài liệu tham khảo và không hề thấy nó lỗi thời theo thời gian. Họ đánh giá đây là bài viết đã mang lại cho Anthropic một hình ảnh mới như một "đối tác thực tế trong việc xây dựng công cụ AI"

• Có nhận định rằng làn sóng cường điệu (hype) quanh agent hiện giờ đã lắng xuống khá nhiều

  • Giờ thì mọi người lại bắt đầu quan tâm đến AI Agency

• Có chia sẻ thông tin rằng bài này khi đó cũng đã từng được thảo luận: thảo luận HN bản gốc

• Có ý kiến thích cách bài viết tiếp cận thực tế, không cường điệu hay chạy theo trào lưu. Họ cũng phê phán xu hướng nhiều người cứ theo mốt xây hệ thống agent mà không tự hỏi liệu công việc đó có thật sự cần agent hay không