- Tác nhân AI khác biệt với Quy trình làm việc: Trong khi quy trình làm việc có các bước cố định được lập trình trước, tác nhân AI cho phép mô hình ngôn ngữ lớn (LLM) tự quyết định số lần lặp lại và hành động để tìm ra giải pháp.
- Mặc dù bị thổi phồng, các tác nhân AI hiệu quả nhất hiện nay hoạt động trong các tác vụ phức tạp, có giá trị và có thể kiểm chứng được như lập trình và tìm kiếm, nơi chi phí lỗi thấp.
- Để phát triển tác nhân AI hiệu quả, điều quan trọng là phải "đồng cảm" với AI, cung cấp ngữ cảnh đầy đủ, câu lệnh chi tiết và các công cụ được mô tả rõ ràng, đảm bảo mô hình có đủ thông tin để hoạt động.
Tips for building AI agents
- Phân biệt rõ ràng: Một "Quy trình làm việc" là chuỗi các lệnh gọi LLM theo các bước cố định (A -> B -> C), trong khi một "Tác nhân AI" là khi LLM tự quyết định số lần chạy và lặp lại cho đến khi tìm ra giải pháp.
- Thiết kế câu lệnh (prompt) linh hoạt cho Tác nhân AI: Câu lệnh của tác nhân AI nên mở hơn, cung cấp cho mô hình các công cụ (tìm kiếm web, chỉnh sửa mã, chạy mã) và hướng dẫn nó tiếp tục thực hiện cho đến khi có câu trả lời.
- Cấu trúc câu lệnh theo luồng cho Quy trình làm việc: Các câu lệnh trong quy trình làm việc thường rất cụ thể, lấy đầu vào và biến đổi thành đầu ra cho bước tiếp theo, với mã bổ sung để kiểm tra kết quả trung gian.
- "Đặt mình vào vị trí của mô hình AI": Khi thiết kế tác nhân, hãy tưởng tượng bạn là mô hình AI và xem xét những hướng dẫn, ngữ cảnh, mô tả công cụ và môi trường nào sẽ phù hợp và rõ ràng nhất.
- Mô tả công cụ chi tiết: Đừng quên rằng mô tả công cụ cũng là một phần của câu lệnh. Các công cụ cần có tài liệu rõ ràng và tham số được đặt tên hợp lý để mô hình AI có thể sử dụng chúng hiệu quả.
- Ưu tiên các tác vụ có thể kiểm chứng: Tác nhân AI mã hóa rất hiệu quả vì mã có thể được kiểm thử, cung cấp tín hiệu phản hồi rõ ràng (kiểm thử pass/fail) cho tác nhân để hội tụ về giải pháp đúng.
- Tích hợp vòng lặp phản hồi: Để cải thiện hiệu suất, đặc biệt trong lập trình, cần nhúng các cơ chế xác minh và kiểm thử (ví dụ: kiểm thử đơn vị tự động) để tác nhân biết liệu hành động của nó là đúng hay sai trước khi trả về cho con người.
- Sử dụng Tác nhân AI phù hợp: Tác nhân AI phù hợp nhất cho các tác vụ phức tạp, có giá trị cao, nhưng chi phí lỗi hoặc chi phí giám sát lỗi tương đối thấp. Tránh dùng tác nhân AI cho các vấn đề đơn giản mà hệ thống AI cổ điển có thể xử lý.
AI Agent— Tác nhân AIWorkflow— Quy trình làm việcLarge Language Model (LLM)— Mô hình ngôn ngữ lớn (LLM)Prompt— Câu lệnhTool— Công cụPrompt Engineering— Thiết kế câu lệnhContext Window— Cửa sổ ngữ cảnhAnti-pattern— Chống mẫuFeedback Loop— Vòng lặp phản hồiVerification— Xác minh
Giới thiệu: Định nghĩa Tác nhân AI và Quy trình làm việc
Tôi cảm thấy các Tác nhân AI (agents) dành cho người dùng đang được quảng bá quá mức. Hôm nay chúng ta sẽ tìm hiểu sâu hơn về một trong những bài đăng blog gần đây của chúng tôi: "Xây dựng các Tác nhân AI hiệu quả". Tôi là Alex, trưởng bộ phận Quan hệ Claude tại Anthropic. Tôi là Eric, thuộc nhóm nghiên cứu tại Anthropic. Tôi là Barry, thuộc nhóm AI ứng dụng. Tôi sẽ bắt đầu bằng cách hỏi những người xem mới tham gia: Phiên bản tóm tắt về Tác nhân AI là gì? Có hàng triệu định nghĩa về nó. Và tại sao một nhà phát triển, một người thực sự đang xây dựng bằng AI, lại nên quan tâm đến những điều này? Eric, có lẽ chúng ta có thể bắt đầu với bạn.
Chắc chắn rồi. Vâng, tôi nghĩ điều chúng tôi đã khám phá trong bài đăng blog là, trước hết, rất nhiều người đã nói "mọi thứ đều là một Tác nhân AI", ám chỉ hầu hết mọi thứ nhiều hơn chỉ một lần gọi Mô hình ngôn ngữ lớn (LLM) duy nhất. Một trong những điều chúng tôi cố gắng làm trong bài đăng blog là thực sự tách biệt điều này ra: có các quy trình làm việc (workflows), nơi bạn có một vài lệnh gọi Mô hình ngôn ngữ lớn (LLM) được xâu chuỗi lại với nhau. Và thực sự, điều chúng tôi nghĩ một Tác nhân AI là nơi bạn cho phép Mô hình ngôn ngữ lớn (LLM) tự quyết định số lần chạy. Bạn để nó tiếp tục lặp lại cho đến khi tìm thấy một giải pháp. Và điều đó có thể là nói chuyện với khách hàng để hỗ trợ khách hàng, hoặc lặp đi lặp lại các thay đổi mã. Nhưng một thứ mà bạn không biết sẽ mất bao nhiêu bước để hoàn thành, đó thực sự là điều chúng tôi coi là một Tác nhân AI.
Thật thú vị. Vậy theo định nghĩa của Tác nhân AI, chúng ta đang để Mô hình ngôn ngữ lớn (LLM) tự định đoạt số phận của mình và quyết định những gì nó muốn làm, những hành động nào cần thực hiện. Thay vì chúng ta định trước một lộ trình cho nó. Chính xác. Nó mang tính tự chủ hơn. Trong khi quy trình làm việc, bạn có thể nghĩ nó giống như một quy trình làm việc hoặc giống như nó đang chạy trên đường ray qua một số bước cố định. Tôi hiểu rồi.
Sự phân biệt giữa Quy trình làm việc và Tác nhân AI
Vậy sự phân biệt này, tôi cho rằng đây là kết quả của rất nhiều cuộc trò chuyện với khách hàng, làm việc với các nhóm khác nhau và thậm chí tự mình thử nghiệm mọi thứ. Barry, bạn có thể nói thêm về việc này trông như thế nào khi chúng ta tạo ra sự phân chia giữa quy trình làm việc và Tác nhân AI và những chống mẫu (anti-pattern) nào đã khiến bạn ngạc nhiên nhất khi thực hiện điều này không? Chắc chắn rồi. Ngoài ra, tôi nghĩ tất cả những điều đó đều phát triển khi mô hình AI (model) trở nên tốt hơn và các nhóm trở nên tinh vi hơn. Chúng tôi đều làm việc với một số lượng lớn khách hàng rất tinh vi và chúng tôi đã chuyển từ việc có một Mô hình ngôn ngữ lớn (LLM) duy nhất sang có nhiều Mô hình ngôn ngữ lớn (LLM) và cuối cùng là có các Tác nhân AI tự điều phối.
Vì vậy, bạn biết đấy, một trong những lý do chúng tôi quyết định tạo ra sự phân biệt này là vì chúng tôi bắt đầu thấy hai mẫu hình riêng biệt này: nơi bạn có các quy trình làm việc được điều phối trước bằng mã (code). Và sau đó bạn cũng có, bạn biết đấy, Tác nhân AI (agent) đơn giản hơn nhưng, bạn biết đấy, phức tạp theo nghĩa khác, một hình dạng khác mà chúng tôi bắt đầu thấy. Thực sự, tôi nghĩ rằng khi các mô hình AI và tất cả các công cụ (tools) bắt đầu trở nên tốt hơn, các Tác nhân AI đang trở nên ngày càng phổ biến và ngày càng có năng lực. Và đó là lúc chúng tôi quyết định: "Này, đây có lẽ là thời điểm thích hợp để chúng ta đưa ra một định nghĩa chính thức".
Triển khai thực tế: Câu lệnh cho Tác nhân AI và Quy trình làm việc
Trong thực tế, nếu bạn đang phát triển và triển khai một trong những thứ này, điều đó sẽ trông như thế nào trong mã của bạn khi bạn bắt đầu xây dựng sự khác biệt này, có lẽ chúng ta thực sự đi sâu vào cấp độ câu lệnh (prompt) ở đây. Câu lệnh của Tác nhân AI trông như thế nào hoặc luồng và quy trình làm việc trông như thế nào? Vâng.
Vì vậy, tôi nghĩ câu lệnh của một quy trình làm việc trông như thế này: bạn có một câu lệnh A, bạn lấy đầu ra của nó, bạn đưa nó vào câu lệnh B, lấy đầu ra của đó, đưa nó vào câu lệnh C, và sau đó bạn đã hoàn thành. Kiểu như có một đường thẳng với số bước cố định, bạn biết chính xác điều gì sẽ xảy ra. Và có thể bạn có một số mã bổ sung để kiểm tra các kết quả trung gian này và đảm bảo chúng ổn. Nhưng bạn biết chính xác điều gì sẽ xảy ra trong một trong những đường dẫn này. Và mỗi câu lệnh đó là một loại câu lệnh rất cụ thể, chỉ để lấy một đầu vào và biến đổi nó thành một đầu ra khác. Ví dụ, một trong những câu lệnh này có thể lấy câu hỏi của người dùng và phân loại nó vào một trong năm loại để câu lệnh tiếp theo có thể cụ thể hơn cho điều đó.
Tôi hiểu rồi. Ngược lại, một câu lệnh của Tác nhân AI sẽ có tính mở hơn nhiều và thường cung cấp cho mô hình AI các công cụ hoặc nhiều thứ để kiểm tra và nói: "Này, đây là câu hỏi, và bạn có thể tìm kiếm trên web hoặc bạn có thể chỉnh sửa các tệp mã này hoặc chạy mã và tiếp tục làm điều này cho đến khi bạn có câu trả lời." Tôi hiểu rồi. Vậy có một vài trường hợp sử dụng khác nhau ở đó. Điều đó có ý nghĩa khi chúng ta bắt đầu đi đến những kết luận khác nhau này.
Những câu chuyện phía sau và lời khuyên cho nhà phát triển
Tôi tò mò, khi chúng ta đã đề cập ở cấp độ cao về cách chúng ta đang suy nghĩ về các quy trình làm việc và Tác nhân AI này và nói về bài đăng trên blog, tôi muốn đi sâu hơn nữa vào hậu trường. Barry, có câu chuyện vui nào về những điều kỳ lạ bạn đã thấy từ khách hàng mà thú vị hoặc đơn giản là quá xa vời về cách mọi người đang thực sự sử dụng những thứ này trong sản xuất không?
Vâng, đây thực sự là từ kinh nghiệm của riêng tôi khi xây dựng các Tác nhân AI. Tôi tham gia khoảng một tháng trước khi phiên bản Sonnet 4.5 được làm mới và một trong những tác vụ (tasks) đầu tiên của tôi là chạy OS World, một điểm chuẩn về việc sử dụng máy tính. Trong cả tuần, tôi và một kỹ sư khác chỉ nhìn chằm chằm vào quỹ đạo Tác nhân AI này, chúng tôi cảm thấy nó phản trực giác. Chúng tôi không chắc tại sao mô hình AI lại đưa ra quyết định đó. Bạn biết đấy, nó đã được cung cấp các hướng dẫn mà chúng tôi đã đưa cho nó. Vì vậy, chúng tôi quyết định sẽ hành động như Claude và đặt mình vào môi trường đó. Vì vậy, chúng tôi sẽ làm điều rất ngớ ngẩn này. Chúng tôi nhắm mắt lại trong một phút rồi chớp mắt nhìn màn hình trong một giây. Chúng tôi lại nhắm mắt và chỉ nghĩ: "Chà, tôi phải viết mã Python để hoạt động trong môi trường này. Tôi sẽ làm gì?" Đột nhiên mọi thứ trở nên có ý nghĩa hơn rất nhiều.
Tôi cảm thấy rất nhiều thiết kế Tác nhân AI xoay quanh điều này. Có rất nhiều ngữ cảnh (context) và rất nhiều kiến thức mà mô hình AI có thể không có, và chúng ta phải thông cảm với mô hình AI. Chúng ta phải làm rõ rất nhiều điều đó trong câu lệnh, trong mô tả công cụ, trong môi trường. Tôi hiểu rồi. Một mẹo dành cho các nhà phát triển ở đây là gần như hành động như thể bạn đang nhìn qua lăng kính của chính mô hình AI về những hướng dẫn nào sẽ phù hợp nhất ở đây. Tôi là mô hình AI nhìn thế giới, điều này rất khác với cách chúng ta hoạt động như một con người, tôi đoán vậy, về ngữ cảnh bổ sung.
Eric, tôi tò mò nếu bạn có bất kỳ câu chuyện nào khác mà bạn đã thấy. Vâng, tôi nghĩ thực ra theo một cách rất giống nhau, tôi nghĩ rất nhiều người thực sự quên làm điều này. Tôi nghĩ những điều hài hước nhất tôi thấy là mọi người sẽ bỏ rất nhiều công sức để tạo ra những câu lệnh thực sự đẹp và chi tiết, và sau đó các công cụ mà họ tạo ra để cung cấp cho mô hình AI lại vô cùng cơ bản. Không có tài liệu, các tham số được đặt tên là A và B, và kiểu như một kỹ sư sẽ không thể làm việc với điều này nếu đây là một hàm mà họ phải sử dụng vì không có tài liệu, làm sao bạn có thể mong đợi Claude sử dụng điều này tốt được. Nó giống như việc thiếu đặt mình vào vị trí của mô hình AI. Tôi nghĩ rất nhiều người khi họ bắt đầu thử sử dụng tool use (sử dụng công cụ) và gọi hàm (function calling), họ quên rằng họ cũng phải đưa ra câu lệnh và họ nghĩ về mô hình AI như một hệ thống AI lập trình cổ điển hơn, nhưng nó vẫn là một mô hình AI và bạn cần phải prompt engineering (thiết kế câu lệnh) trong các mô tả về chính các công cụ của bạn.
Vâng, đúng vậy, tôi đã nhận thấy điều đó. Giống như mọi người quên rằng tất cả đều là một phần của cùng một câu lệnh. Tất cả đều được đưa vào cùng một câu lệnh trong cửa sổ ngữ cảnh (context window) và việc viết một mô tả công cụ tốt cũng ảnh hưởng đến các phần khác của câu lệnh. Vì vậy, đó là một khía cạnh cần xem xét.
Tại sao bây giờ là thời điểm thích hợp để nói về Tác nhân AI?
Tác nhân AI là một thuật ngữ đang rất hot hiện nay. Rất nhiều người đang nói về nó và có rất nhiều bài báo và video được thực hiện về chủ đề này. Điều gì đã khiến các bạn nghĩ rằng bây giờ là thời điểm thích hợp để tự mình viết một cái gì đó và nói thêm một chút về chi tiết của các Tác nhân AI? Chắc chắn rồi. Vâng, tôi nghĩ một trong những điều quan trọng nhất đối với chúng tôi là có thể giải thích mọi thứ một cách rõ ràng. Tôi nghĩ đó là một phần lớn động lực của chúng tôi, đó là khi chúng tôi bước vào các cuộc họp với khách hàng, mọi thứ đều được gọi bằng một thuật ngữ khác mặc dù chúng có cùng hình dạng. Vì vậy, chúng tôi nghĩ rằng sẽ thực sự hữu ích nếu chúng tôi có thể có một bộ định nghĩa và một bộ sơ đồ và mã để giải thích những điều này cho khách hàng của chúng tôi. Và chúng tôi đang đạt đến điểm mà mô hình AI có khả năng thực hiện nhiều quy trình làm việc có tính Tác nhân AI mà chúng tôi đang thấy. Và đó dường như là thời điểm thích hợp để chúng tôi có một số định nghĩa hoặc chỉ để làm cho các cuộc trò chuyện này dễ dàng hơn.
Tôi thấy rằng có rất nhiều sự hào hứng xung quanh các Tác nhân AI nhưng cũng có rất nhiều người thực sự không biết điều đó có nghĩa gì trong thực tế. Và vì vậy, họ đang cố gắng đưa các Tác nhân AI vào bất kỳ vấn đề nào họ gặp phải ngay cả khi các hệ thống AI đơn giản hơn nhiều cũng có thể hoạt động. Và vì vậy, tôi thấy đó là một trong những lý do chúng tôi nên viết bài này: để hướng dẫn mọi người về cách tạo các Tác nhân AI nhưng cũng để biết khi nào Tác nhân AI là phù hợp. Và rằng bạn không nên dùng súng bazooka để bắn một con ruồi. Tôi hiểu rồi, tôi hiểu rồi.
Tác nhân AI bị thổi phồng quá mức và chưa được đánh giá đúng mức
Vậy đó là một phần hoàn hảo cho câu hỏi tiếp theo của tôi ở đây. Có rất nhiều cuộc nói chuyện về tiềm năng của các Tác nhân AI và mọi nhà phát triển cũng như mọi công ty khởi nghiệp và doanh nghiệp đều đang cố gắng nghĩ cách họ có thể xây dựng phiên bản Tác nhân AI của riêng mình cho công ty hoặc sản phẩm của họ. Nhưng các bạn đang bắt đầu thấy điều gì thực sự hiệu quả trong sản xuất. Vì vậy, chúng ta sẽ chơi một trò chơi ở đây. Tôi muốn biết một điều bị thổi phồng quá mức về các Tác nhân AI hiện nay và cả một điều chưa được đánh giá đúng mức chỉ về các triển khai hoặc cách sử dụng thực tế trong sản xuất hoặc tiềm năng ở đây nữa. Vậy Eric, chúng ta hãy bắt đầu với bạn trước.
Tôi cảm thấy điều chưa được đánh giá đúng mức là những thứ giúp mọi người tiết kiệm thời gian ngay cả khi đó là một lượng thời gian rất nhỏ. Tôi nghĩ rất nhiều lần nếu bạn chỉ nhìn vào bề mặt, bạn sẽ nghĩ: "Ồ, đây là thứ mất của tôi một phút. Và ngay cả khi bạn có thể tự động hóa hoàn toàn, nó cũng chỉ là một phút. Điều đó giúp ích gì?" Nhưng thực sự điều đó làm thay đổi động lực của việc bạn có thể làm điều đó nhiều hơn một trăm lần so với trước đây. Vì vậy, tôi nghĩ tôi hào hứng nhất với những điều mà nếu dễ dàng hơn, có thể được mở rộng rất nhiều. Vâng, tôi không biết liệu điều này có nhất thiết liên quan đến sự thổi phồng hay không. Nhưng tôi nghĩ hiện tại rất khó để xác định chính xác khi nào thực sự cần Tác nhân AI.
Tôi nghĩ có một điểm giao thoa là điểm lý tưởng để sử dụng Tác nhân AI và đó là một tập hợp các tác vụ có giá trị và phức tạp. Nhưng cũng có thể chi phí lỗi hoặc chi phí giám sát lỗi tương đối thấp. Tập hợp các tác vụ đó không quá rõ ràng và hiển nhiên trừ khi, bạn biết đấy, chúng ta thực sự xem xét các quy trình làm việc hiện có. Tôi nghĩ mã (coding) và tìm kiếm (search) là hai ví dụ kinh điển mà các Tác nhân AI rất hữu ích. Chẳng hạn, lấy tìm kiếm làm ví dụ: bạn biết đấy, đó là một tác vụ thực sự có giá trị. Rất khó để thực hiện tìm kiếm sâu, lặp đi lặp lại. Nhưng bạn luôn có thể đánh đổi một số độ chính xác để lấy độ phủ và sau đó chỉ nhận được nhiều tài liệu hơn hoặc nhiều thông tin hơn mà bạn cần lọc bớt. Vì vậy, chúng tôi đã thấy rất nhiều thành công với tìm kiếm Tác nhân AI.
Tác nhân AI mã hóa: Kiểm chứng được
Một Tác nhân AI mã hóa trông như thế nào hiện nay? Các Tác nhân AI mã hóa tôi nghĩ là siêu thú vị vì chúng có thể kiểm chứng được, ít nhất là một phần. Bạn biết đấy, mã có thuộc tính tuyệt vời này là bạn có thể viết các bài kiểm tra (tests) cho nó và sau đó bạn chỉnh sửa mã và các bài kiểm tra hoặc vượt qua hoặc không vượt qua. Bây giờ điều đó giả định rằng bạn có các bài kiểm tra đơn vị tốt mà tôi nghĩ, bạn biết đấy, mọi kỹ sư trên thế giới đều có thể nói rằng chúng tôi không có. Vâng. Nhưng ít nhất nó tốt hơn nhiều so với rất nhiều thứ khác.
Tầm quan trọng của phản hồi trong phát triển tác nhân AI
Thật sự không có cách nào tương đương để thực hiện điều này trong nhiều lĩnh vực khác. Vì vậy, ít nhất, điều này mang lại cho một tác nhân AI lập trình một cách để nhận được nhiều tín hiệu hơn mỗi khi nó chạy qua vòng lặp. Mỗi lần chạy lại các kiểm thử, nó đều thấy được lỗi hoặc đầu ra. Điều đó khiến tôi nghĩ rằng mô hình AI có thể dần hội tụ về câu trả lời đúng bằng cách nhận phản hồi này. Và nếu bạn không có một cơ chế nào để nhận phản hồi khi đang lặp lại, bạn sẽ không tiêm thêm bất kỳ tín hiệu nào mà chỉ có nhiễu. Và như vậy, không có lý do gì mà một tác nhân AI có thể hội tụ về câu trả lời đúng nếu không có một cơ chế như vậy.
Tôi hiểu rồi. Vậy những trở ngại lớn nhất hiện tại trong việc cải thiện hiệu suất tác nhân AI trong lập trình là gì?
Thách thức xác minh và kiểm thử tự động
Vâng. Tôi nghĩ đối với lập trình, chúng ta đã thấy trong năm qua, ví dụ trên SweetBench, các kết quả đã tăng từ rất thấp lên hơn 50% hiện tại, điều này thực sự đáng kinh ngạc. Vì vậy, các mô hình AI đang trở nên rất giỏi trong việc viết mã để giải quyết các vấn đề này. Tôi có một quan điểm hơi gây tranh cãi ở đây là tôi nghĩ yếu tố hạn chế tiếp theo sẽ quay trở lại xác minh. Nó rất tốt cho những trường hợp chúng ta có kiểm thử đơn vị hoàn hảo và điều đó đang bắt đầu hoạt động. Nhưng đối với các trường hợp trong thế giới thực, chúng ta thường không có kiểm thử đơn vị hoàn hảo cho chúng. Và đó là lý do tôi đang nghĩ bây giờ là tìm cách để chúng ta có thể xác minh và thêm kiểm thử cho những điều bạn thực sự quan tâm, để chính mô hình AI có thể kiểm thử điều này và biết liệu nó đúng hay sai trước khi trả về cho con người.
Tôi hiểu. Vậy là đảm bảo rằng chúng ta có thể nhúng một vòng lặp phản hồi vào các quy trình.
Chính xác. Để biết đúng hay sai. Được rồi.
Tương lai của đa tác nhân AI
Tương lai của Tác nhân AI sẽ như thế nào vào năm 2025? Tôi hỏi bạn.
Vâng, tôi nghĩ đó là một câu hỏi thực sự khó. Đây có lẽ không phải là một điều thực tế. Nhưng một điều tôi thực sự quan tâm là một môi trường đa tác nhân sẽ trông như thế nào. Tôi nghĩ tôi đã cho Eric xem cái này rồi, một môi trường xây dựng nơi một nhóm Claude có thể tạo ra các Claude khác và cùng nhau chơi Ma Sói. Và đó hoàn toàn là... Ma Sói là gì? Ma Sói là một trò chơi suy luận xã hội nơi tất cả người chơi cố gắng tìm ra vai trò của nhau. Nó rất giống Mafia. Nó hoàn toàn dựa trên văn bản, điều này rất tốt cho Claude để chơi.
Tôi hiểu. Vậy chúng ta có nhiều Claude khác nhau đóng các vai trò khác nhau trong trò chơi này, tất cả đều giao tiếp với nhau.
Đúng vậy. Và sau đó bạn thấy rất nhiều tương tác thú vị ở đó mà bạn chưa từng thấy trước đây. Và đó là điều tôi thực sự hào hứng khi nghĩ đến, rất giống cách chúng ta đã chuyển từ một LLM sang nhiều LLM. Tôi nghĩ vào cuối năm nay, chúng ta có thể thấy mình chuyển từ tác nhân AI sang đa tác nhân AI. Và có một số câu hỏi nghiên cứu thú vị cần tìm hiểu trong lĩnh vực đó. Về cách các tác nhân AI tương tác với nhau, hành vi bất ngờ này sẽ trông như thế nào khi bạn điều phối giữa các tác nhân AI thực hiện các nhiệm vụ khác nhau.
Chính xác. Và liệu điều này thực sự sẽ hữu ích hay tốt hơn so với một tác nhân AI có quyền truy cập vào nhiều tài nguyên hơn. Chúng ta có thấy bất kỳ phương pháp đa tác nhân AI nào đang thực sự hoạt động trong môi trường sản xuất không?
Tôi cảm thấy trong môi trường sản xuất, chúng ta thậm chí còn chưa thấy nhiều tác nhân AI đơn lẻ thành công.
Được, thú vị. Nhưng điều này là một tiềm năng mở rộng của các tác nhân AI thành công với khả năng được cải thiện của các thế hệ mô hình AI tiếp theo. Vâng, vì vậy đây không phải là lời khuyên mà mọi người nên đi khám phá về môi trường tác nhân AI. Tôi nghĩ điều này cung cấp cho chúng ta một cách tốt hơn để hiểu hành vi của mô hình AI.
Tôi hiểu. Được rồi, Eric. Tương lai của Tác nhân AI là gì?
Triển vọng và thách thức của tác nhân AI trong kinh doanh và tiêu dùng
Vâng, tôi cảm thấy vào năm 2025, chúng ta sẽ thấy nhiều ứng dụng trong kinh doanh của Tác nhân AI, bắt đầu tự động hóa nhiều tác vụ lặp đi lặp lại và thực sự mở rộng quy mô rất nhiều thứ mà mọi người muốn làm nhiều hơn trước đây nhưng quá tốn kém. Bây giờ bạn có thể làm những việc này gấp 10 hoặc 100 lần. Tôi đang hình dung những thứ như mỗi yêu cầu kéo (pull request) kích hoạt một tác nhân AI lập trình để bình luận và cập nhật tất cả tài liệu của bạn. Những điều như vậy sẽ quá tốn kém để làm trước đây, nhưng một khi bạn coi Tác nhân AI gần như miễn phí, bạn có thể bắt đầu làm những điều này, thêm các tính năng bổ sung ở khắp mọi nơi.
Tôi nghĩ có lẽ có một điều chưa xảy ra, quay lại với những gì bị cường điệu hóa. Vâng, tôi cảm thấy tác nhân AI cho người tiêu dùng còn khá sơ khai. Được rồi, đây là một quan điểm nóng. Bởi vì tôi nghĩ rằng, như chúng ta đã nói về khả năng xác minh. Tôi nghĩ đối với nhiều tác vụ tiêu dùng, việc chỉ định đầy đủ sở thích của bạn và tác vụ là gì cũng tốn gần như công sức bằng việc tự làm và việc xác minh rất tốn kém. Vì vậy, việc cố gắng có một tác nhân AI đặt toàn bộ một kỳ nghỉ cho bạn, mô tả chính xác những gì bạn muốn cho kỳ nghỉ của mình và sở thích của bạn thì gần như khó bằng việc tự mình đi đặt. Thú vị. Và nó có rủi ro rất cao, bạn không muốn tác nhân AI thực sự đặt một chuyến bay. Thú vị. Mà không có sự chấp nhận của bạn trước.
Có phải có một ngữ cảnh nào đó mà chúng ta đang thiếu ở đây không, từ việc các mô hình AI có thể suy ra thông tin này về một người mà không cần phải hỏi trực tiếp và học hỏi sở thích theo thời gian?
Vâng, tôi nghĩ những điều này sẽ đạt được, nhưng trước tiên bạn cần xây dựng ngữ cảnh này để mô hình AI đã biết sở thích của bạn và tôi nghĩ điều đó cần thời gian.
Tôi hiểu, và chúng ta sẽ cần một số bước đệm để đạt được những tác vụ lớn hơn như lên kế hoạch cho cả một kỳ nghỉ. Tôi hiểu, được rồi, rất thú vị. Câu hỏi cuối cùng, bạn có lời khuyên nào cho một nhà phát triển đang khám phá lĩnh vực này ngay bây giờ, về việc bắt đầu xây dựng hay chỉ suy nghĩ về nó từ khía cạnh chống lỗi thời trong tương lai nói chung không?
Lời khuyên cho nhà phát triển: Đo lường, Đơn giản hóa và Tận dụng sự phát triển của mô hình AI
Tôi cảm thấy lời khuyên tốt nhất của mình là hãy đảm bảo rằng bạn có cách để đo lường kết quả của mình. Bởi vì tôi đã thấy rất nhiều người sẽ đi và xây dựng một cách biệt lập mà không có cách nào để nhận phản hồi về việc sản phẩm của họ có hoạt động hay không, và bạn có thể xây dựng rất nhiều mà không nhận ra rằng nó không hoạt động hoặc có lẽ một cái gì đó đơn giản hơn rất nhiều đã thực sự làm tốt công việc tương tự.
Vâng, tôi nghĩ rất giống vậy, hãy bắt đầu đơn giản nhất có thể và có kết quả có thể đo lường được khi bạn xây dựng thêm độ phức tạp vào nó. Một điều tôi thực sự ấn tượng là tôi làm việc với một số startup rất tháo vát và họ chỉ làm mọi thứ trong một cuộc gọi LLM duy nhất, và việc điều phối xung quanh mã sẽ tồn tại ngay cả khi mô hình AI trở nên tốt hơn, đó là một loại thị trường ngách của họ. Và tôi luôn rất vui khi thấy những điều như vậy bởi vì tôi nghĩ họ có thể gặt hái lợi ích từ những cải tiến khả năng trong tương lai. Và vâng, tôi nghĩ thực tế là chúng ta không biết trường hợp sử dụng nào sẽ tuyệt vời cho Tác nhân AI và bối cảnh sẽ thay đổi, nhưng đây có lẽ là thời điểm tốt để bắt đầu xây dựng một số khả năng đó để tư duy theo tác nhân và chỉ để hiểu khả năng của nó tốt hơn.
Vâng, tôi nghĩ tôi muốn nhấn mạnh điều bạn nói về việc hào hứng khi các mô hình AI trở nên tốt hơn. Tôi nghĩ rằng nếu bạn nhìn vào startup hoặc sản phẩm của mình và nghĩ "Ôi không, nếu các mô hình AI trở nên thông minh hơn, tất cả lợi thế cạnh tranh của chúng ta sẽ biến mất", điều đó có nghĩa là bạn đang xây dựng sai thứ. Thay vào đó, bạn nên xây dựng một thứ gì đó để khi các mô hình AI trở nên thông minh hơn, sản phẩm của bạn sẽ ngày càng tốt hơn.
Đúng vậy. Đó là lời khuyên tuyệt vời. Eric, Barry, cảm ơn các bạn. Đây là Xây dựng Tác nhân AI hiệu quả. Cảm ơn các bạn.
TL;DR
- Tác nhân AI khác biệt với Quy trình làm việc: Trong khi quy trình làm việc có các bước cố định được lập trình trước, tác nhân AI cho phép mô hình ngôn ngữ lớn (LLM) tự quyết định số lần lặp lại và hành động để tìm ra giải pháp.
- Mặc dù bị thổi phồng, các tác nhân AI hiệu quả nhất hiện nay hoạt động trong các tác vụ phức tạp, có giá trị và có thể kiểm chứng được như lập trình và tìm kiếm, nơi chi phí lỗi thấp.
- Để phát triển tác nhân AI hiệu quả, điều quan trọng là phải "đồng cảm" với AI, cung cấp ngữ cảnh đầy đủ, câu lệnh chi tiết và các công cụ được mô tả rõ ràng, đảm bảo mô hình có đủ thông tin để hoạt động.
Điểm chính
- Phân biệt rõ ràng: Một "Quy trình làm việc" là chuỗi các lệnh gọi LLM theo các bước cố định (A -> B -> C), trong khi một "Tác nhân AI" là khi LLM tự quyết định số lần chạy và lặp lại cho đến khi tìm ra giải pháp.
- Thiết kế câu lệnh (prompt) linh hoạt cho Tác nhân AI: Câu lệnh của tác nhân AI nên mở hơn, cung cấp cho mô hình các công cụ (tìm kiếm web, chỉnh sửa mã, chạy mã) và hướng dẫn nó tiếp tục thực hiện cho đến khi có câu trả lời.
- Cấu trúc câu lệnh theo luồng cho Quy trình làm việc: Các câu lệnh trong quy trình làm việc thường rất cụ thể, lấy đầu vào và biến đổi thành đầu ra cho bước tiếp theo, với mã bổ sung để kiểm tra kết quả trung gian.
- "Đặt mình vào vị trí của mô hình AI": Khi thiết kế tác nhân, hãy tưởng tượng bạn là mô hình AI và xem xét những hướng dẫn, ngữ cảnh, mô tả công cụ và môi trường nào sẽ phù hợp và rõ ràng nhất.
- Mô tả công cụ chi tiết: Đừng quên rằng mô tả công cụ cũng là một phần của câu lệnh. Các công cụ cần có tài liệu rõ ràng và tham số được đặt tên hợp lý để mô hình AI có thể sử dụng chúng hiệu quả.
- Ưu tiên các tác vụ có thể kiểm chứng: Tác nhân AI mã hóa rất hiệu quả vì mã có thể được kiểm thử, cung cấp tín hiệu phản hồi rõ ràng (kiểm thử pass/fail) cho tác nhân để hội tụ về giải pháp đúng.
- Tích hợp vòng lặp phản hồi: Để cải thiện hiệu suất, đặc biệt trong lập trình, cần nhúng các cơ chế xác minh và kiểm thử (ví dụ: kiểm thử đơn vị tự động) để tác nhân biết liệu hành động của nó là đúng hay sai trước khi trả về cho con người.
- Sử dụng Tác nhân AI phù hợp: Tác nhân AI phù hợp nhất cho các tác vụ phức tạp, có giá trị cao, nhưng chi phí lỗi hoặc chi phí giám sát lỗi tương đối thấp. Tránh dùng tác nhân AI cho các vấn đề đơn giản mà hệ thống AI cổ điển có thể xử lý.
Từ vựng
AI Agent— Tác nhân AIWorkflow— Quy trình làm việcLarge Language Model (LLM)— Mô hình ngôn ngữ lớn (LLM)Prompt— Câu lệnhTool— Công cụPrompt Engineering— Thiết kế câu lệnhContext Window— Cửa sổ ngữ cảnhAnti-pattern— Chống mẫuFeedback Loop— Vòng lặp phản hồiVerification— Xác minh
Nội dung chi tiết
Giới thiệu: Định nghĩa Tác nhân AI và Quy trình làm việc
Tôi cảm thấy các Tác nhân AI (agents) dành cho người dùng đang được quảng bá quá mức. Hôm nay chúng ta sẽ tìm hiểu sâu hơn về một trong những bài đăng blog gần đây của chúng tôi: "Xây dựng các Tác nhân AI hiệu quả". Tôi là Alex, trưởng bộ phận Quan hệ Claude tại Anthropic. Tôi là Eric, thuộc nhóm nghiên cứu tại Anthropic. Tôi là Barry, thuộc nhóm AI ứng dụng. Tôi sẽ bắt đầu bằng cách hỏi những người xem mới tham gia: Phiên bản tóm tắt về Tác nhân AI là gì? Có hàng triệu định nghĩa về nó. Và tại sao một nhà phát triển, một người thực sự đang xây dựng bằng AI, lại nên quan tâm đến những điều này? Eric, có lẽ chúng ta có thể bắt đầu với bạn.
Chắc chắn rồi. Vâng, tôi nghĩ điều chúng tôi đã khám phá trong bài đăng blog là, trước hết, rất nhiều người đã nói "mọi thứ đều là một Tác nhân AI", ám chỉ hầu hết mọi thứ nhiều hơn chỉ một lần gọi Mô hình ngôn ngữ lớn (LLM) duy nhất. Một trong những điều chúng tôi cố gắng làm trong bài đăng blog là thực sự tách biệt điều này ra: có các quy trình làm việc (workflows), nơi bạn có một vài lệnh gọi Mô hình ngôn ngữ lớn (LLM) được xâu chuỗi lại với nhau. Và thực sự, điều chúng tôi nghĩ một Tác nhân AI là nơi bạn cho phép Mô hình ngôn ngữ lớn (LLM) tự quyết định số lần chạy. Bạn để nó tiếp tục lặp lại cho đến khi tìm thấy một giải pháp. Và điều đó có thể là nói chuyện với khách hàng để hỗ trợ khách hàng, hoặc lặp đi lặp lại các thay đổi mã. Nhưng một thứ mà bạn không biết sẽ mất bao nhiêu bước để hoàn thành, đó thực sự là điều chúng tôi coi là một Tác nhân AI.
Thật thú vị. Vậy theo định nghĩa của Tác nhân AI, chúng ta đang để Mô hình ngôn ngữ lớn (LLM) tự định đoạt số phận của mình và quyết định những gì nó muốn làm, những hành động nào cần thực hiện. Thay vì chúng ta định trước một lộ trình cho nó. Chính xác. Nó mang tính tự chủ hơn. Trong khi quy trình làm việc, bạn có thể nghĩ nó giống như một quy trình làm việc hoặc giống như nó đang chạy trên đường ray qua một số bước cố định. Tôi hiểu rồi.
Sự phân biệt giữa Quy trình làm việc và Tác nhân AI
Vậy sự phân biệt này, tôi cho rằng đây là kết quả của rất nhiều cuộc trò chuyện với khách hàng, làm việc với các nhóm khác nhau và thậm chí tự mình thử nghiệm mọi thứ. Barry, bạn có thể nói thêm về việc này trông như thế nào khi chúng ta tạo ra sự phân chia giữa quy trình làm việc và Tác nhân AI và những chống mẫu (anti-pattern) nào đã khiến bạn ngạc nhiên nhất khi thực hiện điều này không? Chắc chắn rồi. Ngoài ra, tôi nghĩ tất cả những điều đó đều phát triển khi mô hình AI (model) trở nên tốt hơn và các nhóm trở nên tinh vi hơn. Chúng tôi đều làm việc với một số lượng lớn khách hàng rất tinh vi và chúng tôi đã chuyển từ việc có một Mô hình ngôn ngữ lớn (LLM) duy nhất sang có nhiều Mô hình ngôn ngữ lớn (LLM) và cuối cùng là có các Tác nhân AI tự điều phối.
Vì vậy, bạn biết đấy, một trong những lý do chúng tôi quyết định tạo ra sự phân biệt này là vì chúng tôi bắt đầu thấy hai mẫu hình riêng biệt này: nơi bạn có các quy trình làm việc được điều phối trước bằng mã (code). Và sau đó bạn cũng có, bạn biết đấy, Tác nhân AI (agent) đơn giản hơn nhưng, bạn biết đấy, phức tạp theo nghĩa khác, một hình dạng khác mà chúng tôi bắt đầu thấy. Thực sự, tôi nghĩ rằng khi các mô hình AI và tất cả các công cụ (tools) bắt đầu trở nên tốt hơn, các Tác nhân AI đang trở nên ngày càng phổ biến và ngày càng có năng lực. Và đó là lúc chúng tôi quyết định: "Này, đây có lẽ là thời điểm thích hợp để chúng ta đưa ra một định nghĩa chính thức".
Triển khai thực tế: Câu lệnh cho Tác nhân AI và Quy trình làm việc
Trong thực tế, nếu bạn đang phát triển và triển khai một trong những thứ này, điều đó sẽ trông như thế nào trong mã của bạn khi bạn bắt đầu xây dựng sự khác biệt này, có lẽ chúng ta thực sự đi sâu vào cấp độ câu lệnh (prompt) ở đây. Câu lệnh của Tác nhân AI trông như thế nào hoặc luồng và quy trình làm việc trông như thế nào? Vâng.
Vì vậy, tôi nghĩ câu lệnh của một quy trình làm việc trông như thế này: bạn có một câu lệnh A, bạn lấy đầu ra của nó, bạn đưa nó vào câu lệnh B, lấy đầu ra của đó, đưa nó vào câu lệnh C, và sau đó bạn đã hoàn thành. Kiểu như có một đường thẳng với số bước cố định, bạn biết chính xác điều gì sẽ xảy ra. Và có thể bạn có một số mã bổ sung để kiểm tra các kết quả trung gian này và đảm bảo chúng ổn. Nhưng bạn biết chính xác điều gì sẽ xảy ra trong một trong những đường dẫn này. Và mỗi câu lệnh đó là một loại câu lệnh rất cụ thể, chỉ để lấy một đầu vào và biến đổi nó thành một đầu ra khác. Ví dụ, một trong những câu lệnh này có thể lấy câu hỏi của người dùng và phân loại nó vào một trong năm loại để câu lệnh tiếp theo có thể cụ thể hơn cho điều đó.
Tôi hiểu rồi. Ngược lại, một câu lệnh của Tác nhân AI sẽ có tính mở hơn nhiều và thường cung cấp cho mô hình AI các công cụ hoặc nhiều thứ để kiểm tra và nói: "Này, đây là câu hỏi, và bạn có thể tìm kiếm trên web hoặc bạn có thể chỉnh sửa các tệp mã này hoặc chạy mã và tiếp tục làm điều này cho đến khi bạn có câu trả lời." Tôi hiểu rồi. Vậy có một vài trường hợp sử dụng khác nhau ở đó. Điều đó có ý nghĩa khi chúng ta bắt đầu đi đến những kết luận khác nhau này.
Những câu chuyện phía sau và lời khuyên cho nhà phát triển
Tôi tò mò, khi chúng ta đã đề cập ở cấp độ cao về cách chúng ta đang suy nghĩ về các quy trình làm việc và Tác nhân AI này và nói về bài đăng trên blog, tôi muốn đi sâu hơn nữa vào hậu trường. Barry, có câu chuyện vui nào về những điều kỳ lạ bạn đã thấy từ khách hàng mà thú vị hoặc đơn giản là quá xa vời về cách mọi người đang thực sự sử dụng những thứ này trong sản xuất không?
Vâng, đây thực sự là từ kinh nghiệm của riêng tôi khi xây dựng các Tác nhân AI. Tôi tham gia khoảng một tháng trước khi phiên bản Sonnet 4.5 được làm mới và một trong những tác vụ (tasks) đầu tiên của tôi là chạy OS World, một điểm chuẩn về việc sử dụng máy tính. Trong cả tuần, tôi và một kỹ sư khác chỉ nhìn chằm chằm vào quỹ đạo Tác nhân AI này, chúng tôi cảm thấy nó phản trực giác. Chúng tôi không chắc tại sao mô hình AI lại đưa ra quyết định đó. Bạn biết đấy, nó đã được cung cấp các hướng dẫn mà chúng tôi đã đưa cho nó. Vì vậy, chúng tôi quyết định sẽ hành động như Claude và đặt mình vào môi trường đó. Vì vậy, chúng tôi sẽ làm điều rất ngớ ngẩn này. Chúng tôi nhắm mắt lại trong một phút rồi chớp mắt nhìn màn hình trong một giây. Chúng tôi lại nhắm mắt và chỉ nghĩ: "Chà, tôi phải viết mã Python để hoạt động trong môi trường này. Tôi sẽ làm gì?" Đột nhiên mọi thứ trở nên có ý nghĩa hơn rất nhiều.
Tôi cảm thấy rất nhiều thiết kế Tác nhân AI xoay quanh điều này. Có rất nhiều ngữ cảnh (context) và rất nhiều kiến thức mà mô hình AI có thể không có, và chúng ta phải thông cảm với mô hình AI. Chúng ta phải làm rõ rất nhiều điều đó trong câu lệnh, trong mô tả công cụ, trong môi trường. Tôi hiểu rồi. Một mẹo dành cho các nhà phát triển ở đây là gần như hành động như thể bạn đang nhìn qua lăng kính của chính mô hình AI về những hướng dẫn nào sẽ phù hợp nhất ở đây. Tôi là mô hình AI nhìn thế giới, điều này rất khác với cách chúng ta hoạt động như một con người, tôi đoán vậy, về ngữ cảnh bổ sung.
Eric, tôi tò mò nếu bạn có bất kỳ câu chuyện nào khác mà bạn đã thấy. Vâng, tôi nghĩ thực ra theo một cách rất giống nhau, tôi nghĩ rất nhiều người thực sự quên làm điều này. Tôi nghĩ những điều hài hước nhất tôi thấy là mọi người sẽ bỏ rất nhiều công sức để tạo ra những câu lệnh thực sự đẹp và chi tiết, và sau đó các công cụ mà họ tạo ra để cung cấp cho mô hình AI lại vô cùng cơ bản. Không có tài liệu, các tham số được đặt tên là A và B, và kiểu như một kỹ sư sẽ không thể làm việc với điều này nếu đây là một hàm mà họ phải sử dụng vì không có tài liệu, làm sao bạn có thể mong đợi Claude sử dụng điều này tốt được. Nó giống như việc thiếu đặt mình vào vị trí của mô hình AI. Tôi nghĩ rất nhiều người khi họ bắt đầu thử sử dụng tool use (sử dụng công cụ) và gọi hàm (function calling), họ quên rằng họ cũng phải đưa ra câu lệnh và họ nghĩ về mô hình AI như một hệ thống AI lập trình cổ điển hơn, nhưng nó vẫn là một mô hình AI và bạn cần phải prompt engineering (thiết kế câu lệnh) trong các mô tả về chính các công cụ của bạn.
Vâng, đúng vậy, tôi đã nhận thấy điều đó. Giống như mọi người quên rằng tất cả đều là một phần của cùng một câu lệnh. Tất cả đều được đưa vào cùng một câu lệnh trong cửa sổ ngữ cảnh (context window) và việc viết một mô tả công cụ tốt cũng ảnh hưởng đến các phần khác của câu lệnh. Vì vậy, đó là một khía cạnh cần xem xét.
Tại sao bây giờ là thời điểm thích hợp để nói về Tác nhân AI?
Tác nhân AI là một thuật ngữ đang rất hot hiện nay. Rất nhiều người đang nói về nó và có rất nhiều bài báo và video được thực hiện về chủ đề này. Điều gì đã khiến các bạn nghĩ rằng bây giờ là thời điểm thích hợp để tự mình viết một cái gì đó và nói thêm một chút về chi tiết của các Tác nhân AI? Chắc chắn rồi. Vâng, tôi nghĩ một trong những điều quan trọng nhất đối với chúng tôi là có thể giải thích mọi thứ một cách rõ ràng. Tôi nghĩ đó là một phần lớn động lực của chúng tôi, đó là khi chúng tôi bước vào các cuộc họp với khách hàng, mọi thứ đều được gọi bằng một thuật ngữ khác mặc dù chúng có cùng hình dạng. Vì vậy, chúng tôi nghĩ rằng sẽ thực sự hữu ích nếu chúng tôi có thể có một bộ định nghĩa và một bộ sơ đồ và mã để giải thích những điều này cho khách hàng của chúng tôi. Và chúng tôi đang đạt đến điểm mà mô hình AI có khả năng thực hiện nhiều quy trình làm việc có tính Tác nhân AI mà chúng tôi đang thấy. Và đó dường như là thời điểm thích hợp để chúng tôi có một số định nghĩa hoặc chỉ để làm cho các cuộc trò chuyện này dễ dàng hơn.
Tôi thấy rằng có rất nhiều sự hào hứng xung quanh các Tác nhân AI nhưng cũng có rất nhiều người thực sự không biết điều đó có nghĩa gì trong thực tế. Và vì vậy, họ đang cố gắng đưa các Tác nhân AI vào bất kỳ vấn đề nào họ gặp phải ngay cả khi các hệ thống AI đơn giản hơn nhiều cũng có thể hoạt động. Và vì vậy, tôi thấy đó là một trong những lý do chúng tôi nên viết bài này: để hướng dẫn mọi người về cách tạo các Tác nhân AI nhưng cũng để biết khi nào Tác nhân AI là phù hợp. Và rằng bạn không nên dùng súng bazooka để bắn một con ruồi. Tôi hiểu rồi, tôi hiểu rồi.
Tác nhân AI bị thổi phồng quá mức và chưa được đánh giá đúng mức
Vậy đó là một phần hoàn hảo cho câu hỏi tiếp theo của tôi ở đây. Có rất nhiều cuộc nói chuyện về tiềm năng của các Tác nhân AI và mọi nhà phát triển cũng như mọi công ty khởi nghiệp và doanh nghiệp đều đang cố gắng nghĩ cách họ có thể xây dựng phiên bản Tác nhân AI của riêng mình cho công ty hoặc sản phẩm của họ. Nhưng các bạn đang bắt đầu thấy điều gì thực sự hiệu quả trong sản xuất. Vì vậy, chúng ta sẽ chơi một trò chơi ở đây. Tôi muốn biết một điều bị thổi phồng quá mức về các Tác nhân AI hiện nay và cả một điều chưa được đánh giá đúng mức chỉ về các triển khai hoặc cách sử dụng thực tế trong sản xuất hoặc tiềm năng ở đây nữa. Vậy Eric, chúng ta hãy bắt đầu với bạn trước.
Tôi cảm thấy điều chưa được đánh giá đúng mức là những thứ giúp mọi người tiết kiệm thời gian ngay cả khi đó là một lượng thời gian rất nhỏ. Tôi nghĩ rất nhiều lần nếu bạn chỉ nhìn vào bề mặt, bạn sẽ nghĩ: "Ồ, đây là thứ mất của tôi một phút. Và ngay cả khi bạn có thể tự động hóa hoàn toàn, nó cũng chỉ là một phút. Điều đó giúp ích gì?" Nhưng thực sự điều đó làm thay đổi động lực của việc bạn có thể làm điều đó nhiều hơn một trăm lần so với trước đây. Vì vậy, tôi nghĩ tôi hào hứng nhất với những điều mà nếu dễ dàng hơn, có thể được mở rộng rất nhiều. Vâng, tôi không biết liệu điều này có nhất thiết liên quan đến sự thổi phồng hay không. Nhưng tôi nghĩ hiện tại rất khó để xác định chính xác khi nào thực sự cần Tác nhân AI.
Tôi nghĩ có một điểm giao thoa là điểm lý tưởng để sử dụng Tác nhân AI và đó là một tập hợp các tác vụ có giá trị và phức tạp. Nhưng cũng có thể chi phí lỗi hoặc chi phí giám sát lỗi tương đối thấp. Tập hợp các tác vụ đó không quá rõ ràng và hiển nhiên trừ khi, bạn biết đấy, chúng ta thực sự xem xét các quy trình làm việc hiện có. Tôi nghĩ mã (coding) và tìm kiếm (search) là hai ví dụ kinh điển mà các Tác nhân AI rất hữu ích. Chẳng hạn, lấy tìm kiếm làm ví dụ: bạn biết đấy, đó là một tác vụ thực sự có giá trị. Rất khó để thực hiện tìm kiếm sâu, lặp đi lặp lại. Nhưng bạn luôn có thể đánh đổi một số độ chính xác để lấy độ phủ và sau đó chỉ nhận được nhiều tài liệu hơn hoặc nhiều thông tin hơn mà bạn cần lọc bớt. Vì vậy, chúng tôi đã thấy rất nhiều thành công với tìm kiếm Tác nhân AI.
Tác nhân AI mã hóa: Kiểm chứng được
Một Tác nhân AI mã hóa trông như thế nào hiện nay? Các Tác nhân AI mã hóa tôi nghĩ là siêu thú vị vì chúng có thể kiểm chứng được, ít nhất là một phần. Bạn biết đấy, mã có thuộc tính tuyệt vời này là bạn có thể viết các bài kiểm tra (tests) cho nó và sau đó bạn chỉnh sửa mã và các bài kiểm tra hoặc vượt qua hoặc không vượt qua. Bây giờ điều đó giả định rằng bạn có các bài kiểm tra đơn vị tốt mà tôi nghĩ, bạn biết đấy, mọi kỹ sư trên thế giới đều có thể nói rằng chúng tôi không có. Vâng. Nhưng ít nhất nó tốt hơn nhiều so với rất nhiều thứ khác.
Tầm quan trọng của phản hồi trong phát triển tác nhân AI
Thật sự không có cách nào tương đương để thực hiện điều này trong nhiều lĩnh vực khác. Vì vậy, ít nhất, điều này mang lại cho một tác nhân AI lập trình một cách để nhận được nhiều tín hiệu hơn mỗi khi nó chạy qua vòng lặp. Mỗi lần chạy lại các kiểm thử, nó đều thấy được lỗi hoặc đầu ra. Điều đó khiến tôi nghĩ rằng mô hình AI có thể dần hội tụ về câu trả lời đúng bằng cách nhận phản hồi này. Và nếu bạn không có một cơ chế nào để nhận phản hồi khi đang lặp lại, bạn sẽ không tiêm thêm bất kỳ tín hiệu nào mà chỉ có nhiễu. Và như vậy, không có lý do gì mà một tác nhân AI có thể hội tụ về câu trả lời đúng nếu không có một cơ chế như vậy.
Tôi hiểu rồi. Vậy những trở ngại lớn nhất hiện tại trong việc cải thiện hiệu suất tác nhân AI trong lập trình là gì?
Thách thức xác minh và kiểm thử tự động
Vâng. Tôi nghĩ đối với lập trình, chúng ta đã thấy trong năm qua, ví dụ trên SweetBench, các kết quả đã tăng từ rất thấp lên hơn 50% hiện tại, điều này thực sự đáng kinh ngạc. Vì vậy, các mô hình AI đang trở nên rất giỏi trong việc viết mã để giải quyết các vấn đề này. Tôi có một quan điểm hơi gây tranh cãi ở đây là tôi nghĩ yếu tố hạn chế tiếp theo sẽ quay trở lại xác minh. Nó rất tốt cho những trường hợp chúng ta có kiểm thử đơn vị hoàn hảo và điều đó đang bắt đầu hoạt động. Nhưng đối với các trường hợp trong thế giới thực, chúng ta thường không có kiểm thử đơn vị hoàn hảo cho chúng. Và đó là lý do tôi đang nghĩ bây giờ là tìm cách để chúng ta có thể xác minh và thêm kiểm thử cho những điều bạn thực sự quan tâm, để chính mô hình AI có thể kiểm thử điều này và biết liệu nó đúng hay sai trước khi trả về cho con người.
Tôi hiểu. Vậy là đảm bảo rằng chúng ta có thể nhúng một vòng lặp phản hồi vào các quy trình.
Chính xác. Để biết đúng hay sai. Được rồi.
Tương lai của đa tác nhân AI
Tương lai của Tác nhân AI sẽ như thế nào vào năm 2025? Tôi hỏi bạn.
Vâng, tôi nghĩ đó là một câu hỏi thực sự khó. Đây có lẽ không phải là một điều thực tế. Nhưng một điều tôi thực sự quan tâm là một môi trường đa tác nhân sẽ trông như thế nào. Tôi nghĩ tôi đã cho Eric xem cái này rồi, một môi trường xây dựng nơi một nhóm Claude có thể tạo ra các Claude khác và cùng nhau chơi Ma Sói. Và đó hoàn toàn là... Ma Sói là gì? Ma Sói là một trò chơi suy luận xã hội nơi tất cả người chơi cố gắng tìm ra vai trò của nhau. Nó rất giống Mafia. Nó hoàn toàn dựa trên văn bản, điều này rất tốt cho Claude để chơi.
Tôi hiểu. Vậy chúng ta có nhiều Claude khác nhau đóng các vai trò khác nhau trong trò chơi này, tất cả đều giao tiếp với nhau.
Đúng vậy. Và sau đó bạn thấy rất nhiều tương tác thú vị ở đó mà bạn chưa từng thấy trước đây. Và đó là điều tôi thực sự hào hứng khi nghĩ đến, rất giống cách chúng ta đã chuyển từ một LLM sang nhiều LLM. Tôi nghĩ vào cuối năm nay, chúng ta có thể thấy mình chuyển từ tác nhân AI sang đa tác nhân AI. Và có một số câu hỏi nghiên cứu thú vị cần tìm hiểu trong lĩnh vực đó. Về cách các tác nhân AI tương tác với nhau, hành vi bất ngờ này sẽ trông như thế nào khi bạn điều phối giữa các tác nhân AI thực hiện các nhiệm vụ khác nhau.
Chính xác. Và liệu điều này thực sự sẽ hữu ích hay tốt hơn so với một tác nhân AI có quyền truy cập vào nhiều tài nguyên hơn. Chúng ta có thấy bất kỳ phương pháp đa tác nhân AI nào đang thực sự hoạt động trong môi trường sản xuất không?
Tôi cảm thấy trong môi trường sản xuất, chúng ta thậm chí còn chưa thấy nhiều tác nhân AI đơn lẻ thành công.
Được, thú vị. Nhưng điều này là một tiềm năng mở rộng của các tác nhân AI thành công với khả năng được cải thiện của các thế hệ mô hình AI tiếp theo. Vâng, vì vậy đây không phải là lời khuyên mà mọi người nên đi khám phá về môi trường tác nhân AI. Tôi nghĩ điều này cung cấp cho chúng ta một cách tốt hơn để hiểu hành vi của mô hình AI.
Tôi hiểu. Được rồi, Eric. Tương lai của Tác nhân AI là gì?
Triển vọng và thách thức của tác nhân AI trong kinh doanh và tiêu dùng
Vâng, tôi cảm thấy vào năm 2025, chúng ta sẽ thấy nhiều ứng dụng trong kinh doanh của Tác nhân AI, bắt đầu tự động hóa nhiều tác vụ lặp đi lặp lại và thực sự mở rộng quy mô rất nhiều thứ mà mọi người muốn làm nhiều hơn trước đây nhưng quá tốn kém. Bây giờ bạn có thể làm những việc này gấp 10 hoặc 100 lần. Tôi đang hình dung những thứ như mỗi yêu cầu kéo (pull request) kích hoạt một tác nhân AI lập trình để bình luận và cập nhật tất cả tài liệu của bạn. Những điều như vậy sẽ quá tốn kém để làm trước đây, nhưng một khi bạn coi Tác nhân AI gần như miễn phí, bạn có thể bắt đầu làm những điều này, thêm các tính năng bổ sung ở khắp mọi nơi.
Tôi nghĩ có lẽ có một điều chưa xảy ra, quay lại với những gì bị cường điệu hóa. Vâng, tôi cảm thấy tác nhân AI cho người tiêu dùng còn khá sơ khai. Được rồi, đây là một quan điểm nóng. Bởi vì tôi nghĩ rằng, như chúng ta đã nói về khả năng xác minh. Tôi nghĩ đối với nhiều tác vụ tiêu dùng, việc chỉ định đầy đủ sở thích của bạn và tác vụ là gì cũng tốn gần như công sức bằng việc tự làm và việc xác minh rất tốn kém. Vì vậy, việc cố gắng có một tác nhân AI đặt toàn bộ một kỳ nghỉ cho bạn, mô tả chính xác những gì bạn muốn cho kỳ nghỉ của mình và sở thích của bạn thì gần như khó bằng việc tự mình đi đặt. Thú vị. Và nó có rủi ro rất cao, bạn không muốn tác nhân AI thực sự đặt một chuyến bay. Thú vị. Mà không có sự chấp nhận của bạn trước.
Có phải có một ngữ cảnh nào đó mà chúng ta đang thiếu ở đây không, từ việc các mô hình AI có thể suy ra thông tin này về một người mà không cần phải hỏi trực tiếp và học hỏi sở thích theo thời gian?
Vâng, tôi nghĩ những điều này sẽ đạt được, nhưng trước tiên bạn cần xây dựng ngữ cảnh này để mô hình AI đã biết sở thích của bạn và tôi nghĩ điều đó cần thời gian.
Tôi hiểu, và chúng ta sẽ cần một số bước đệm để đạt được những tác vụ lớn hơn như lên kế hoạch cho cả một kỳ nghỉ. Tôi hiểu, được rồi, rất thú vị. Câu hỏi cuối cùng, bạn có lời khuyên nào cho một nhà phát triển đang khám phá lĩnh vực này ngay bây giờ, về việc bắt đầu xây dựng hay chỉ suy nghĩ về nó từ khía cạnh chống lỗi thời trong tương lai nói chung không?
Lời khuyên cho nhà phát triển: Đo lường, Đơn giản hóa và Tận dụng sự phát triển của mô hình AI
Tôi cảm thấy lời khuyên tốt nhất của mình là hãy đảm bảo rằng bạn có cách để đo lường kết quả của mình. Bởi vì tôi đã thấy rất nhiều người sẽ đi và xây dựng một cách biệt lập mà không có cách nào để nhận phản hồi về việc sản phẩm của họ có hoạt động hay không, và bạn có thể xây dựng rất nhiều mà không nhận ra rằng nó không hoạt động hoặc có lẽ một cái gì đó đơn giản hơn rất nhiều đã thực sự làm tốt công việc tương tự.
Vâng, tôi nghĩ rất giống vậy, hãy bắt đầu đơn giản nhất có thể và có kết quả có thể đo lường được khi bạn xây dựng thêm độ phức tạp vào nó. Một điều tôi thực sự ấn tượng là tôi làm việc với một số startup rất tháo vát và họ chỉ làm mọi thứ trong một cuộc gọi LLM duy nhất, và việc điều phối xung quanh mã sẽ tồn tại ngay cả khi mô hình AI trở nên tốt hơn, đó là một loại thị trường ngách của họ. Và tôi luôn rất vui khi thấy những điều như vậy bởi vì tôi nghĩ họ có thể gặt hái lợi ích từ những cải tiến khả năng trong tương lai. Và vâng, tôi nghĩ thực tế là chúng ta không biết trường hợp sử dụng nào sẽ tuyệt vời cho Tác nhân AI và bối cảnh sẽ thay đổi, nhưng đây có lẽ là thời điểm tốt để bắt đầu xây dựng một số khả năng đó để tư duy theo tác nhân và chỉ để hiểu khả năng của nó tốt hơn.
Vâng, tôi nghĩ tôi muốn nhấn mạnh điều bạn nói về việc hào hứng khi các mô hình AI trở nên tốt hơn. Tôi nghĩ rằng nếu bạn nhìn vào startup hoặc sản phẩm của mình và nghĩ "Ôi không, nếu các mô hình AI trở nên thông minh hơn, tất cả lợi thế cạnh tranh của chúng ta sẽ biến mất", điều đó có nghĩa là bạn đang xây dựng sai thứ. Thay vào đó, bạn nên xây dựng một thứ gì đó để khi các mô hình AI trở nên thông minh hơn, sản phẩm của bạn sẽ ngày càng tốt hơn.
Đúng vậy. Đó là lời khuyên tuyệt vời. Eric, Barry, cảm ơn các bạn. Đây là Xây dựng Tác nhân AI hiệu quả. Cảm ơn các bạn.