Xây dựng AI agent hiệu quả
(anthropic.com)- Theo kinh nghiệm thực tế của Anthropic, các LLM agent thành công thường bắt đầu từ những mẫu đơn giản, có thể kết hợp, hơn là các framework phức tạp
- Hệ thống dạng agent được chia thành workflow, nơi đi theo các đường dẫn mã được định sẵn, và agent, nơi LLM tự quyết định linh hoạt quy trình và cách dùng công cụ
- Với nhiều ứng dụng LLM, chỉ cần một lệnh gọi LLM đơn lẻ kết hợp tìm kiếm và ví dụ trong ngữ cảnh là đủ; chỉ nên tăng độ phức tạp khi đánh giá cho thấy có hiệu quả
- Framework giúp khởi đầu nhanh hơn, nhưng lớp trừu tượng che khuất prompt và phản hồi có thể khiến việc debug trở nên khó khăn
- Agent tự chủ mạnh trong các bài toán mở, nhưng có rủi ro tăng chi phí và tích lũy lỗi, nên cần kiểm thử trong sandbox, guardrail và thiết kế công cụ rõ ràng
Phân loại cơ bản của hệ thống dạng agent
- Hệ thống dạng agent là thuật ngữ được dùng rộng, từ các hệ thống hoàn toàn tự chủ hoạt động độc lập trong thời gian dài cho đến các triển khai đi theo workflow được định nghĩa trước
- Anthropic xem tất cả các biến thể này là hệ thống dạng agent, nhưng chia thành hai loại về mặt kiến trúc
- Workflow: LLM và công cụ được điều phối theo các đường dẫn mã được định nghĩa trước
- Agent: LLM tự chỉ đạo và kiểm soát linh hoạt cách thực hiện tác vụ, quy trình và việc sử dụng công cụ
Tiêu chí quyết định khi nào nên dùng agent
- Ứng dụng LLM được khuyến nghị bắt đầu từ giải pháp đơn giản nhất có thể, và chỉ tăng độ phức tạp khi cần
- Hệ thống dạng agent là cấu trúc chấp nhận độ trễ và chi phí để đổi lấy hiệu năng tác vụ tốt hơn, nên trước tiên cần xác nhận sự đánh đổi này có thật sự cần thiết hay không
- Ngay cả khi cần độ phức tạp, tiêu chí lựa chọn cũng khác nhau
- Với tác vụ được định nghĩa rõ, workflow mang lại tính dự đoán và nhất quán
- Với tác vụ cần mức độ linh hoạt lớn và ra quyết định do mô hình dẫn dắt, agent phù hợp hơn
- Nhiều ứng dụng chỉ cần tối ưu một lệnh gọi LLM đơn lẻ bằng tìm kiếm và ví dụ trong ngữ cảnh là đủ
Tiêu chí sử dụng framework
- Các công cụ triển khai hệ thống dạng agent được giới thiệu gồm Claude Agent SDK, Strands Agents SDK by AWS, Rivet, Vellum
- Những framework này đơn giản hóa các tác vụ chuẩn ở mức thấp như gọi LLM, định nghĩa và phân tích cú pháp công cụ, nối các lệnh gọi, giúp bắt đầu nhanh hơn
- Tuy nhiên, lớp trừu tượng bổ sung có thể che khuất prompt và phản hồi thực tế, khiến việc debug khó hơn
- Chúng cũng có thể thúc đẩy việc thêm độ phức tạp không cần thiết ngay cả khi cấu hình đơn giản đã đủ
- Nhà phát triển nên bắt đầu bằng cách dùng trực tiếp LLM API
- Nhiều mẫu có thể triển khai chỉ bằng vài dòng mã
- Dù dùng framework, vẫn cần hiểu cách mã bên trong hoạt động
- Giả định sai về cơ chế nội bộ là nguyên nhân phổ biến gây lỗi ở khách hàng
- Có thể xem triển khai mẫu trong cookbook
Khối xây dựng cơ bản: LLM tăng cường
- Khối xây dựng cơ bản của hệ thống dạng agent là LLM tăng cường bằng các năng lực như tìm kiếm, công cụ và bộ nhớ
- Các mô hình hiện nay có thể chủ động dùng những năng lực này bằng cách tự tạo truy vấn tìm kiếm, chọn công cụ phù hợp và quyết định thông tin nào cần giữ lại
- Khi triển khai, cần tập trung vào hai điểm
- Điều chỉnh năng lực cho phù hợp với use case
- Cung cấp giao diện được tài liệu hóa, dễ dùng cho LLM
- Model Context Protocol được giới thiệu như một cách triển khai
- Nhà phát triển có thể tích hợp với hệ sinh thái công cụ bên thứ ba thông qua một client implementation đơn giản
Các mẫu workflow
-
Prompt chaining
- Prompt chaining là cách chia tác vụ thành các bước tuần tự, trong đó mỗi lệnh gọi LLM xử lý đầu ra của lệnh gọi trước
- Có thể chèn kiểm tra bằng chương trình ở từng bước trung gian để xác nhận quy trình vẫn đi đúng hướng
- Phù hợp khi tác vụ có thể được phân rã gọn gàng thành các tác vụ con cố định
- Đánh đổi chính là chấp nhận độ trễ để giảm độ khó của từng lệnh gọi LLM, từ đó tăng độ chính xác
- Ví dụ
- Tạo nội dung marketing rồi dịch sang ngôn ngữ khác
- Viết dàn ý tài liệu, kiểm tra có đáp ứng tiêu chí hay không, rồi viết tài liệu dựa trên dàn ý
-
Routing
- Routing là cách phân loại đầu vào rồi gửi đến tác vụ tiếp theo đã được chuyên biệt hóa
- Có thể tách biệt các mối quan tâm và tạo prompt chuyên biệt hơn
- Nếu không có cấu trúc này, việc tối ưu cho một loại đầu vào có thể làm giảm hiệu năng với đầu vào khác
- Phù hợp khi các danh mục khác nhau thích hợp để xử lý riêng, và LLM hoặc mô hình/thuật toán phân loại truyền thống có thể phân loại chính xác
- Ví dụ
- Chuyển các truy vấn dịch vụ khách hàng như câu hỏi chung, yêu cầu hoàn tiền, hỗ trợ kỹ thuật sang các quy trình, prompt và công cụ khác nhau
- Route câu hỏi dễ hoặc phổ biến đến mô hình nhỏ hơn, tiết kiệm chi phí hơn như Claude Haiku 4.5; câu hỏi khó hoặc bất thường đến mô hình mạnh hơn như Claude Sonnet 4.5
-
Song song hóa
- Song song hóa là cách để LLM xử lý đồng thời một tác vụ và tổng hợp đầu ra bằng chương trình
- Có hai biến thể chính
- Chia phần: Chia tác vụ thành các tác vụ con độc lập và chạy song song
- Bỏ phiếu: Chạy cùng một tác vụ nhiều lần để thu được nhiều đầu ra đa dạng
- Hiệu quả khi có thể chia tác vụ con để tăng tốc, hoặc khi cần nhiều góc nhìn hay nhiều lần thử để đạt độ tin cậy cao hơn
- Trong tác vụ phức tạp, nếu mỗi lệnh gọi LLM phụ trách một khía cạnh cần cân nhắc riêng, nó có thể tập trung hơn vào khía cạnh đó
- Ví dụ
- Guardrail trong đó một instance mô hình xử lý truy vấn người dùng, còn instance khác kiểm tra nội dung hoặc yêu cầu không phù hợp
- Trong đánh giá hiệu năng LLM, mỗi lệnh gọi đánh giá một khía cạnh khác nhau của hiệu năng mô hình
- Nhiều prompt rà soát lỗ hổng mã và gắn cờ nếu phát hiện vấn đề
- Trong đánh giá mức độ không phù hợp của nội dung, dùng nhiều prompt và ngưỡng bỏ phiếu để cân bằng false positive và false negative
-
Orchestrator-worker
- Orchestrator-worker là cách một LLM trung tâm phân rã tác vụ một cách linh hoạt, giao cho các LLM worker rồi tổng hợp kết quả
- Phù hợp với các tác vụ phức tạp mà không thể dự đoán trước các tác vụ con cần thiết
- Trông giống song song hóa, nhưng khác biệt cốt lõi là tính linh hoạt
- Song song hóa có tác vụ con được định nghĩa trước
- Orchestrator-worker để orchestrator quyết định tác vụ con dựa trên đầu vào
- Ví dụ
- Sản phẩm coding thực hiện các thay đổi phức tạp trên nhiều file mỗi lần
- Tác vụ tìm kiếm thu thập và phân tích thông tin có khả năng liên quan từ nhiều nguồn
-
Evaluator-optimizer
- Evaluator-optimizer là cấu trúc vòng lặp trong đó một lệnh gọi LLM tạo phản hồi, còn một lệnh gọi LLM khác đưa ra đánh giá và phản hồi góp ý
- Đặc biệt hiệu quả khi có tiêu chí đánh giá rõ ràng và cải thiện lặp lại mang lại giá trị đo được
- Có hai tín hiệu cho thấy phù hợp
- Khi con người diễn đạt rõ phản hồi góp ý, phản hồi của LLM thực sự được cải thiện
- LLM có thể cung cấp dạng phản hồi góp ý đó
- Tương tự quá trình viết lặp lại mà nhà văn con người trải qua để tạo ra tài liệu được trau chuốt
- Ví dụ
- Dịch văn học, trong đó LLM đánh giá phê bình các sắc thái mà LLM dịch có thể bỏ sót lúc đầu
- Tác vụ tìm kiếm phức tạp, trong đó evaluator quyết định có cần tìm kiếm bổ sung hay không
Agent tự chủ
- Agent bắt đầu được dùng trong production khi LLM có khả năng hiểu đầu vào phức tạp, suy luận và lập kế hoạch, dùng công cụ ổn định và phục hồi lỗi
- Tác vụ bắt đầu từ lệnh hoặc cuộc trò chuyện của con người
- Khi tác vụ đã rõ, agent lập kế hoạch và hoạt động độc lập
- Nếu cần thêm thông tin hoặc phán đoán, agent có thể quay lại hỏi con người
- Trong khi thực thi, điều quan trọng là ở mỗi bước phải nhận được tín hiệu xác minh thực tế từ môi trường
- Ví dụ: kết quả gọi công cụ, kết quả chạy mã
- Qua đó đánh giá tiến độ
- Agent có thể dừng lại ở checkpoint hoặc khi bị kẹt để nhận phản hồi từ con người
- Tác vụ thường kết thúc khi hoàn thành, nhưng cũng phổ biến việc đặt điều kiện dừng như số vòng lặp tối đa để duy trì kiểm soát
- Bản thân triển khai thường đơn giản
- Agent thường là một LLM dùng công cụ trong vòng lặp dựa trên phản hồi từ môi trường
- Vì vậy cần thiết kế bộ công cụ và tài liệu rõ ràng, cẩn trọng
- Điều kiện sử dụng
- Bài toán mở mà số bước cần thiết khó hoặc không thể dự đoán
- Tác vụ không thể hard-code theo một đường dẫn cố định
- Tình huống LLM có thể hoạt động qua nhiều lượt và cần mức độ tin cậy nhất định trong ra quyết định
- Hạn chế
- Tự chủ đi kèm chi phí cao hơn và khả năng tích lũy lỗi
- Khuyến nghị kiểm thử rộng trong môi trường sandbox và thiết lập guardrail phù hợp
- Ví dụ
- Coding agent giải quyết SWE-bench tasks cần chỉnh sửa nhiều file
- Triển khai tham chiếu “computer use”, nơi Claude dùng máy tính để thực hiện tác vụ
Kết hợp mẫu và tùy biến
- Các khối xây dựng được trình bày không phải đơn thuốc cố định, mà là những mẫu chung nhà phát triển có thể điều chỉnh và kết hợp theo use case
- Chìa khóa thành công, giống như với các năng lực LLM nói chung, là đo lường hiệu năng và cải tiến triển khai theo vòng lặp
- Chỉ nên thêm độ phức tạp khi kết quả thực sự được cải thiện
Nguyên tắc triển khai
- Thành công trong lĩnh vực LLM không nằm ở việc tạo ra hệ thống tinh vi nhất, mà ở việc tạo ra hệ thống đúng với nhu cầu
- Thứ tự khuyến nghị như sau
- Bắt đầu với prompt đơn giản
- Tối ưu prompt bằng đánh giá toàn diện
- Chỉ thêm hệ thống dạng agent nhiều bước khi giải pháp đơn giản chưa đủ
- Khi triển khai agent, có ba nguyên tắc quan trọng
- Duy trì sự đơn giản trong thiết kế
- Ưu tiên tính minh bạch bằng cách hiển thị rõ bước lập kế hoạch của agent
- Thiết kế agent-computer interface, tức ACI, một cách cẩn trọng thông qua tài liệu hóa và kiểm thử công cụ kỹ lưỡng
- Framework giúp khởi đầu nhanh, nhưng khi chuyển sang production, cũng cần cách giảm lớp trừu tượng và xây dựng từ các thành phần cơ bản
Lĩnh vực áp dụng thực tế
-
Hỗ trợ khách hàng
- Hỗ trợ khách hàng kết hợp giao diện chatbot quen thuộc với mở rộng năng lực thông qua tích hợp công cụ
- Có những lý do khiến lĩnh vực này tự nhiên phù hợp với các agent mở hơn
- Tương tác hỗ trợ đi theo luồng hội thoại, đồng thời cần truy cập thông tin và tác vụ bên ngoài
- Công cụ có thể được tích hợp để lấy dữ liệu khách hàng, lịch sử đơn hàng, tài liệu knowledge base
- Các tác vụ như xử lý hoàn tiền hoặc cập nhật ticket có thể được xử lý bằng chương trình
- Thành công có thể được đo rõ ràng bằng việc giải quyết vấn đề do người dùng xác định
- Nhiều công ty đã chứng minh tính khả thi của cách tiếp cận này bằng mô hình giá dựa trên mức sử dụng, chỉ tính phí cho các trường hợp được giải quyết thành công
-
Coding agent
- Lĩnh vực phát triển phần mềm đã cho thấy tiềm năng lớn khi năng lực LLM tiến hóa từ hoàn thành mã đến giải quyết vấn đề tự chủ
- Có những lý do khiến agent hiệu quả
- Giải pháp mã có thể được xác minh bằng kiểm thử tự động
- Agent có thể dùng kết quả kiểm thử làm phản hồi để cải thiện giải pháp theo vòng lặp
- Không gian vấn đề được định nghĩa và có cấu trúc rõ
- Chất lượng đầu ra có thể được đo khách quan
- Trong triển khai của Anthropic, agent có thể giải quyết các issue GitHub thực tế trong benchmark SWE-bench Verified chỉ từ mô tả pull request
- Dù kiểm thử tự động giúp xác minh chức năng, review của con người vẫn quan trọng để đảm bảo giải pháp phù hợp với các yêu cầu hệ thống rộng hơn
Prompt engineering cho công cụ
- Trong bất kỳ hệ thống dạng agent nào, công cụ nhiều khả năng là một thành phần quan trọng
- Tools cho phép Claude tương tác với dịch vụ và API bên ngoài
- Chỉ định cấu trúc và định nghĩa chính xác trong API
- Khi Claude lên kế hoạch gọi công cụ, phản hồi API sẽ chứa tool use block
- Định nghĩa và đặc tả công cụ cần nhận được mức độ chú ý về prompt engineering ngang với toàn bộ prompt
-
Chọn định dạng công cụ
- Cùng một tác vụ có thể được chỉ định theo nhiều cách
- Chỉnh sửa file có thể được viết dưới dạng diff hoặc được chỉ định bằng cách viết lại toàn bộ file
- Đầu ra có cấu trúc có thể được trả về dưới dạng mã trong Markdown hoặc mã trong JSON
- Từ góc nhìn kỹ thuật phần mềm, các khác biệt định dạng này có thể chuyển đổi qua lại mà không mất mát, nhưng với LLM, một số định dạng khó dùng hơn rất nhiều
- Viết diff đòi hỏi phải biết có bao nhiêu dòng thay đổi trong chunk header trước khi viết mã mới
- Viết mã trong JSON đòi hỏi thêm việc escape xuống dòng và dấu ngoặc kép
- Khi chọn định dạng công cụ, cần tránh khiến mô hình mắc kẹt trong gánh nặng định dạng không cần thiết
- Cung cấp đủ token để suy nghĩ trước khi đi vào định dạng cụt đường
- Giữ định dạng gần với những dạng mô hình đã thấy tự nhiên trên văn bản Internet
- Loại bỏ overhead về định dạng như đếm chính xác số dòng của hàng nghìn dòng mã hoặc escape chuỗi mã
- Cùng một tác vụ có thể được chỉ định theo nhiều cách
-
Thiết kế ACI
- Cần đầu tư vào thiết kế agent-computer interface (ACI) tương đương công sức dành cho giao diện người-máy (HCI)
- Định nghĩa công cụ tốt thường bao gồm ví dụ sử dụng, edge case, yêu cầu về định dạng đầu vào và ranh giới rõ ràng với các công cụ khác
- Tên và mô tả tham số nên được điều chỉnh để mô hình dễ hiểu hơn
- Tương tự việc viết docstring xuất sắc cho lập trình viên junior trong nhóm
- Đặc biệt quan trọng khi có nhiều công cụ tương tự
- Cần kiểm thử cách mô hình dùng công cụ
- Khi tạo agent cho SWE-bench, nhóm đã dành nhiều thời gian tối ưu công cụ hơn toàn bộ prompt
- Từng có vấn đề agent mắc lỗi với công cụ dùng đường dẫn file tương đối sau khi di chuyển ra ngoài thư mục gốc
- Khi đổi công cụ để luôn yêu cầu đường dẫn file tuyệt đối, mô hình đã dùng cách này mà không lỗi
1 bình luận
Ý kiến trên Hacker News
Tôi cho rằng bài viết này vẫn là một trong những bài hay về chủ đề này. Đặc biệt tôi thích việc ngay từ đầu tác giả đã định nghĩa rõ AI agent được dùng theo nghĩa nào
Ở đây, nó được định nghĩa là “một hệ thống trong đó LLM tự động chỉ đạo quá trình xử lý và việc sử dụng công cụ của chính mình, đồng thời duy trì quyền kiểm soát cách hoàn thành tác vụ”
Ngoài ra, tôi cũng thích cách bài viết phân biệt “agent” và “workflow”, rồi giải thích nhiều mẫu workflow hữu ích
Khi bài này mới ra, tôi đã ghi chú lại về nó: https://simonwillison.net/2024/Dec/20/building-effective-age...
Một bài gần đây hơn của Anthropic là https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system”, bài này cũng rất thú vị nên tôi đã tổng hợp ghi chú: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...
Nếu vì mục đích học tập thì có vẻ ổn, nhưng lợi ích đầu tiên của một framework tốt là có thể dễ dàng thử nghiệm LLM từ các nhà cung cấp khác nhau
Có vẻ đây là nỗ lực định nghĩa lại workflow để phân biệt, nhưng phần lớn agent chỉ là các workflow lặp, gọi thứ gì đó một cách động tùy theo phản hồi của LLM. Các workflow engine hiện đại rất linh hoạt
Lời khuyên “các framework giúp khởi đầu dễ dàng bằng cách đơn giản hóa những tác vụ cấp thấp tiêu chuẩn như gọi LLM, định nghĩa và phân tích cú pháp công cụ, nối các lời gọi với nhau, nhưng thường tạo thêm một lớp trừu tượng che khuất prompt và phản hồi gốc, khiến việc debug khó hơn. Chúng cũng dễ khiến ta muốn thêm độ phức tạp ngay cả khi cấu hình đơn giản hơn là đủ. Khuyến nghị các nhà phát triển nên bắt đầu bằng cách dùng trực tiếp LLM API” theo tôi là phần hay nhất trong cả bài
Về bản chất, việc dùng một framework khổng lồ chỉ để gửi một mảng chuỗi lên web service là vô lý
Trong dự án của công ty, chúng tôi cũng đã loại bỏ LangChain và LangGraph; thực tế chúng không mang lại giá trị mà chỉ làm tăng độ phức tạp. Vì phải xử lý boilerplate của framework, rốt cuộc lại viết nhiều code hơn so với khi không dùng
Bạn có thể tự chạy toàn bộ các bước tạo ảnh bằng Stable Diffusion hoặc tự viết shader code, nhưng nếu có nhiều hơn một luồng hoặc tác vụ và đang thử nghiệm, dùng comfy-UI hoặc shader graph sẽ gọn gàng hơn nhiều
Đã nửa năm trôi qua, mà trong lĩnh vực AI thì cảm giác đó là một quãng thời gian khá dài. Vài tháng trước tôi đã đọc đi đọc lại bài này, nhưng giờ thì phát triển agent rõ ràng có vẻ đã chạm nút thắt
Ngay cả Gemini mới nhất cũng trông như đang thụt lùi
Điều phối đa agent rất khó kiểm soát, và khi hiệu năng mô hình tốt hơn thì nhu cầu dùng đa agent giảm xuống. Ngược lại, mô hình càng kém thì AI phạm vi hẹp càng hợp lý hơn về mặt kinh doanh
Có ví dụ nào về agent trong môi trường vận hành thực tế giúp công ty tiết kiệm chi phí và làm những việc thật sự có giá trị không? Ý là không phải kiểu viết văn bản để lấp khoảng trống trên bao bì khoai tây chiên
https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
Vẫn đang ở beta
Theo thông cáo báo chí, chatbot của Rukaya Johaadien cung cấp hỗ trợ dạng hội thoại cho sinh viên và nhà nghiên cứu có dữ liệu đa dạng sinh học nhưng mới công bố dữ liệu lần đầu hoặc hiếm khi làm việc này. Nó giúp dọn dẹp và chuẩn hóa bảng tính, tạo metadata cơ bản, và hướng dẫn xuất bản các bộ dữ liệu có cấu trúc tốt dưới dạng Darwin Core Archive lên GBIF.org
Từ trước đến nay, việc xuất bản ở quy mô lớn các dữ liệu chất lượng cao đến từ nghiên cứu tiến sĩ, thạc sĩ hoặc các nghiên cứu đa dạng sinh học quy mô nhỏ là rất khó. Lý do là chuẩn hóa dữ liệu thường đòi hỏi kiến thức về ngôn ngữ lập trình, kỹ thuật quản lý dữ liệu và phần mềm chuyên dụng
Quy trình truy cập Integrated Publishing Toolkit(IPT), ứng dụng cốt lõi để chia sẻ dữ liệu trong mạng lưới GBIF, cũng khá khó với người mới. Do thời gian và nguồn lực của các quản trị viên node có hạn, còn người dùng không thường xuyên thì dễ quên quy trình và chi tiết chính xác qua từng năm, nên chỉ đào tạo thôi khó vượt qua các rào cản về logistics và ngôn ngữ
Họ giải thích rằng: “Chuẩn hóa dữ liệu là việc khó, và các nhà sinh học không trở thành nhà sinh học vì họ thích coding hay Excel, nên rất nhiều dữ liệu có giá trị tiềm năng bị bỏ phí. Nhìn thấy các mô hình ngôn ngữ lớn đã trở nên rất giỏi trong sinh mã và xử lý dữ liệu, chúng tôi đã tạo một công cụ hướng dẫn người dùng không chuyên kỹ thuật bằng các câu hỏi thường ngày, xử lý dữ liệu lộn xộn nhiều nhất có thể, rồi xuất bản lên GBIF một cách nhanh chóng và tự động”
Với mọi cảnh báo hoặc ticket đi vào, agent thực hiện điều tra trước trên các API, cơ sở dữ liệu liên quan, v.v. để xác định false positive và cung cấp thêm ngữ cảnh cho các vấn đề thật. Việc này giảm thời gian của con người và tăng tốc độ xử lý
Họ cũng dùng cùng kiểu suy luận agent cho các tác vụ khám phá, vượt ra ngoài text-to-SQL đơn giản, để LLM điều tra thay người dùng trong 2–10 phút trên Splunk, Databricks, v.v.
Nội bộ họ có các công cụ như lớp ngữ nghĩa trên cơ sở dữ liệu, bộ phân tích log quy mô lớn, văn bản và dataframe
Tôi đã thử dùng một workflow n8n tự làm với cấu hình gần như giống bài viết. Để nhận câu trả lời cho một câu hỏi đơn giản, tôi tốn 3 đô la và ít nhất 3 phút
Trong thời gian tới tôi vẫn sẽ tiếp tục dùng tìm kiếm thông thường
Bài này nhắc rất đúng rằng hãy bắt đầu từ thứ đơn giản nhất có thể hoạt động, và chỉ thêm độ phức tạp khi thật sự cần
Chỉ vài lời gọi LLM được định nghĩa rõ ràng cùng một chút logic kết nối nhẹ thường đã tạo ra một hệ thống ổn định hơn, dễ debug hơn và chi phí chạy rẻ hơn nhiều. Các agent hào nhoáng, nhiều tính năng thường tạo ra nhiều vấn đề hơn số vấn đề chúng giải quyết
Với tư cách là người làm ở một công ty có agent thật trong môi trường vận hành thực tế, chứ không phải workflow, tôi hoàn toàn không đồng ý với câu đầu ở đây là “hãy dùng framework agent như LangGraph”
Chúng tôi cũng đã làm đúng như vậy rồi phải vứt bỏ toàn bộ chỉ sau một tháng, sau đó xây lại từ đầu và giờ hệ thống mở rộng khá tốt
Công bằng mà nói, có thể vẫn có chỗ cho các framework agent. Nhưng lĩnh vực agent vẫn còn quá sơ khai để có một framework đủ tốt
Ở một mức độ nào đó tôi còn có suy nghĩ ngược lại: lĩnh vực agent di chuyển quá nhanh nên có thể sẽ không bao giờ có một framework đủ tốt
Framework giúp khởi đầu dễ hơn, nhưng các tầng trừu tượng bổ sung có thể che khuất prompt và response, khiến debug khó hơn, đồng thời thêm độ phức tạp ngay cả khi một cấu hình đơn giản hơn đã đủ. Vì vậy bài viết khuyên nên bắt đầu bằng cách dùng trực tiếp LLM API, vì nhiều pattern có thể triển khai chỉ bằng vài dòng code
Tôi đã thấy nhiều bình luận nói rằng hầu hết các đội thực dụng đều bỏ LangChain, LangGraph, Haystack, Crew và chuyển sang code nội bộ đơn giản hơn, nhưng vẫn chưa hình dung rõ trong thực tế những phần như gọi tool được triển khai như thế nào
Nếu có link hoặc tài liệu nào bạn dùng làm nền tảng cho công việc này thì có thể chia sẻ không
Bài từ tháng 12/2024, nhưng kỳ lạ là cảm giác như đã rất lâu rồi
Đây là bài khiến tôi nhìn lại Anthropic như một “đối tác thực dụng” trong phát triển công cụ AI
https://news.ycombinator.com/item?id=44260988
Có vẻ giờ agent hype đã hạ nhiệt phần nào
Câu “hãy dùng các pattern đơn giản, có thể kết hợp” nghe an tâm đến lạ
Tôi thích việc châm ngôn “hãy làm tốt một việc” vẫn còn đúng sau mấy chục năm. Khả năng kết hợp là tuyệt nhất