Tác nhân ReAct: hướng dẫn thực tế cho các nhóm sản xuất

Liên kết nội bộ:

• Phát triển tác nhân AI
• BI tác nhân và báo cáo
• Nghiên cứu tình huống về tác nhân nghiên cứu tự chủ
• Tác nhân AI có sự đánh giá của con người
• Cẩm nang vận hành tác nhân AI Liên kết bên ngoài:
• Bài viết ReAct gốc
• Tổng quan về Google Research ReAct
• Tài liệu gọi hàm OpenAI
• Quy ước ngữ nghĩa GenAI của OpenTelemetry

---

Tác nhân ReAct là một mẫu quy trình công việc kết nối lý luận, hành động, quan sát và đánh giá để hệ thống AI có thể chuyển từ mục tiêu người dùng sang sử dụng công cụ được kiểm soát. Thử thách sản xuất không phải là nhãn mác; nó đang thiết kế dữ liệu, rào chắn, nhật ký và các điểm kiểm tra của con người để làm cho quy trình làm việc trở nên đáng tin cậy.

Hầu hết các nhóm không cần bản demo tác nhân khác hoạt động một lần. Họ cần một hệ thống có thể kiểm tra bằng chứng, chọn cách gọi công cụ tiếp theo, rút ​​kinh nghiệm từ kết quả và dừng lại khi bằng chứng yếu.

Priya, người đứng đầu hoạt động tại một công ty B2B SaaS, đã gặp phải vấn đề đó. Nhóm của cô muốn có bản tóm tắt hàng tuần về đối thủ cạnh tranh, nhưng mỗi bản tóm tắt đều mất sáu giờ kiểm tra nguồn thủ công. Đại lý ReAct có thể trợ giúp, nhưng chỉ khi nó thu thập các nguồn, đánh dấu những mâu thuẫn và chuyển những tuyên bố không chắc chắn đến người đánh giá trước khi bản tóm tắt đến tay lãnh đạo.

Hướng dẫn dành cho tác nhân ReAct này giải thích quy trình làm việc, ví dụ, các bước triển khai, cách thực hành tốt nhất, lỗi và tiêu chí đánh giá quan trọng trước khi sản xuất.

Ý chính

• Tác nhân ReAct hoạt động tốt nhất khi tác vụ cần suy luận, dùng công cụ, quan sát và lặp lại.
• Thiết kế vận hành quan trọng hơn mẫu câu lệnh: cần xác định công cụ, giới hạn, điều kiện dừng, nhật ký và đường chuyển cấp.
• Các trường hợp phù hợp gồm bản tin nghiên cứu, tóm tắt báo cáo, kiểm tra dữ liệu và quy trình vận hành.
• Cần có người duyệt khi rủi ro kinh doanh, độ không chắc chắn của dữ liệu hoặc hành động không thể đảo ngược ở mức cao.
• Hãy đánh giá toàn bộ quy trình, không chỉ câu trả lời cuối: độ chính xác khi dùng công cụ, chất lượng bằng chứng, khả năng khôi phục, chi phí và công sức duyệt đều quan trọng.

Xây dựng điều này xung quanh một quy trình làm việc thực sự? Bắt đầu với mẫu AI Agent Development: ánh xạ công việc, công cụ, phê duyệt và các chế độ lỗi trước khi chọn ngăn xếp.

Tác nhân ReAct là gì?

Vòng lặp ReAct cơ bản dễ đánh giá nhất khi mỗi bước được hiển thị:

Tác nhân ReAct là tác nhân AI xen kẽ giữa lý luận về một nhiệm vụ, thực hiện hành động thông qua một công cụ hoặc môi trường, quan sát kết quả và quyết định việc cần làm tiếp theo. Thuật ngữ này xuất phát từ "lý luận" cộng với "diễn xuất", được mô tả trong bài viết ReAct gốc và được mở rộng trong tổng quan về ReAct của Google Research.

Bài viết này nói về ReAct như một mẫu quy trình làm việc của tác nhân AI. Nó không phải về React, thư viện JavaScript front-end.

Quy trình làm việc của tác nhân ReAct đơn giản trông như thế này:

1. Người dùng đưa ra mục tiêu
2. Tác nhân xác định bước hữu ích tiếp theo
3. Tác nhân gọi một công cụ, truy xuất dữ liệu hoặc truy vấn môi trường
4. Đại lý quan sát kết quả
5. Đại lý quyết định tiếp tục, trả lời, yêu cầu xem xét hay dừng

Vòng lặp đó rất hữu ích vì nhiều câu hỏi vận hành không thể được trả lời chỉ bằng một lời nhắc. Yêu cầu báo cáo có thể cần số liệu kho. Một nhiệm vụ nghiên cứu có thể cần kiểm tra nguồn. Một tác vụ hỗ trợ có thể cần tra cứu lịch sử yêu cầu và chính sách.

Trong quá trình sản xuất, khung tác nhân ReAct cần nhiều hơn vòng lặp. Nó cần có quyền công cụ rõ ràng, quan sát có cấu trúc, giới hạn thử lại, điều kiện dừng, nhật ký và điểm kiểm tra xem xét. Nếu không có những biện pháp kiểm soát đó, khả năng làm cho tác nhân trở nên hữu ích cũng gây ra rủi ro.

Tại sao tác nhân ReAct lại quan trọng trong sản xuất

Tác nhân ReAct quan trọng khi câu trả lời tĩnh là không đủ. Mẫu này hữu ích khi tác vụ phụ thuộc vào thông tin bên ngoài, các quyết định gồm nhiều bước hoặc lệnh gọi công cụ làm thay đổi những gì tác nhân nên làm tiếp theo.

Các trường hợp sử dụng phổ biến bao gồm:

• Nghiên cứu quy trình thu thập nguồn và gắn cờ các xác nhận quyền sở hữu không được hỗ trợ
• Quy trình báo cáo kiểm tra số liệu và giải thích các điểm bất thường
• Nhiệm vụ xác thực dữ liệu so sánh các bản ghi với quy tắc
• Quy trình hoạt động nội bộ tuân theo danh sách kiểm tra
• Nhiệm vụ hỗ trợ quyết định cần bằng chứng trước khi đưa ra khuyến nghị

Ví dụ: một giám đốc điều hành hỏi: "Tại sao chuyển đổi quy trình lại giảm vào tuần trước?" Một chatbot bình thường có thể tóm tắt các nguyên nhân chung. Tác nhân ReAct có thể kiểm tra số liệu CRM, so sánh các phân đoạn, kiểm tra nhật ký triển khai, quan sát xem một lần tích hợp không thành công và soạn thảo báo cáo kèm theo bằng chứng.

Đó cũng là lý do tại sao khuôn mẫu cần có kỷ luật. Một tác nhân sử dụng công cụ có thể hoạt động trên các hệ thống trực tiếp. Nó có thể truy vấn dữ liệu nhạy cảm, gửi tin nhắn, cập nhật hồ sơ hoặc tạo báo cáo mà mọi người tin tưởng. Hồ sơ rủi ro khác với việc tạo nội dung.

Đối với các nhóm xây dựng BI tác nhân và báo cáo, sự khác biệt này rất quan trọng. Mục tiêu không phải là một bảng điều khiển biết nói. Mục tiêu là quy trình báo cáo nhằm kiểm tra các con số, giải thích chuyển động, báo cáo các điểm bất thường và để lại dấu vết kiểm tra.

Cách sử dụng quy hoạch tác nhân ReAct mà không cần xây dựng quá mức

Mặt phẳng điều khiển có phạm vi giúp tác nhân ReAct không trở thành trợ lý rộng rãi với thẩm quyền không rõ ràng:

Cách an toàn nhất để tiếp cận việc triển khai tác nhân ReAct là xác định phạm vi quy trình công việc trước khi chọn khung. Một công việc hẹp với những công cụ rõ ràng sẽ đánh bại một trợ lý rộng rãi với khả năng tiếp cận mơ hồ.

Sử dụng trình tự lập kế hoạch này:

1. Xác định công việc mà đại lý nên thực hiện
2. Xác định các công cụ và nguồn dữ liệu nó có thể sử dụng
3. Viết quy tắc hành động và điều kiện dừng
4. Thêm kiểm tra xác thực trước đầu ra cuối cùng
5. Ghi lại các cuộc gọi công cụ, quan sát, lỗi và nhãn quyết định
6. Thêm đánh giá của con người đối với các trường hợp có tác động lớn hoặc không chắc chắn
7. Kiểm tra các kịch bản dự kiến, trường hợp đặc biệt và lỗi

Quy trình nghiên cứu thực tế có thể bắt đầu bằng yêu cầu của đối thủ cạnh tranh hàng tuần. Người đại diện thu thập các nguồn công khai, kiểm tra xem mỗi tuyên bố có được hỗ trợ hay không, đánh dấu những mâu thuẫn và soạn thảo một bản tóm tắt có cấu trúc. Nếu thiếu bằng chứng, nó sẽ đưa ra yêu cầu bồi thường thay vì che giấu sự không chắc chắn.

Mô hình đó gần giống với quy trình làm việc đằng sau [nghiên cứu điển hình về tác nhân nghiên cứu tự trị](/vi/portfolio/autonomous-research-agent-stack của Van Data Team): giá trị đến từ việc xử lý, cấu trúc và xem xét bằng chứng, chứ không phải từ việc giả vờ rằng tác nhân hoàn toàn tự chủ.

Thiết kế công cụ là quyết định tiếp theo. Một công cụ phải có một hợp đồng hẹp: lược đồ đầu vào, hành động được phép, lược đồ đầu ra, thời gian chờ, chính sách thử lại và phản hồi lỗi. Tài liệu gọi hàm OpenAI là tài liệu tham khảo hữu ích để xem các công cụ dưới dạng lệnh gọi có cấu trúc thay vì văn bản rời rạc.

Không sử dụng văn bản lý luận riêng tư làm dấu vết kiểm tra. Ghi lại những gì người vận hành có thể xác minh: mục tiêu của người dùng, công cụ đã chọn, đầu vào công cụ, đầu ra công cụ, tóm tắt quan sát, nhãn tin cậy, kết quả xác thực và trạng thái leo thang.

Ví dụ về tác nhân ReAct cho quy trình làm việc thực tế

Các ví dụ về tác nhân ReAct tốt được căn cứ vào công việc có thể lặp lại. Tác nhân phải có một công việc, không gian hành động có giới hạn và định dạng câu trả lời rõ ràng.

Đại lý nghiên cứu

Đại lý nghiên cứu nhận được yêu cầu như "Chuẩn bị bản tóm tắt đối thủ cạnh tranh hàng tuần để dẫn đầu sản phẩm". Nó lý giải rằng nó cần đưa tin về nguồn, gọi các công cụ tìm kiếm hoặc kiến ​​thức nội bộ, quan sát những tuyên bố nào được hỗ trợ và gắn cờ các khoảng trống.

Bước xem xét quan trọng. Nếu một tuyên bố có một nguồn yếu hoặc bằng chứng mâu thuẫn, người đại diện nên đánh dấu nó để con người xem xét thay vì trau chuốt nó thành văn xuôi tự tin.

Đại lý báo cáo

Đại lý báo cáo xem xét số liệu kho hàng, so sánh giá trị hiện tại với các kỳ trước và soạn thảo bản tóm tắt tường thuật. Nếu nhận thấy điểm bất thường, nó sẽ kiểm tra các sự kiện đã biết như chiến dịch, hoạt động triển khai hoặc làm mới dữ liệu.

Marcus, trưởng nhóm RevOps, đã thử nghiệm điều này bằng quy trình làm việc dùng thử. Vào sáng thứ Hai, người đại diện nhận thấy số lượng khách hàng tiềm năng đủ điều kiện đã giảm 17%. Lời giải thích đầu tiên không phải là “nhu cầu giảm”. Quan sát cho thấy một nguồn biểu mẫu đã ngừng đồng bộ hóa vào thứ Sáu. Báo cáo cuối cùng tiết kiệm thời gian vì quy trình làm việc đã kiểm tra bằng chứng trước khi viết tường thuật.

Trợ lý vận hành

Trợ lý vận hành tuân theo danh sách kiểm tra trên các hệ thống nội bộ. Nó có thể soạn thảo bản cập nhật CRM, chuẩn bị bản tóm tắt Slack hoặc đề xuất hành động tiếp theo. Đối với các hành động không thể đảo ngược, nó phải yêu cầu phê duyệt.

Điều đó làm cho quy trình làm việc của tác nhân ReAct trở nên hữu ích mà không cần cấp cho nó quyền không được kiểm tra. Hành động dự thảo và hành động được phê duyệt phải ở trạng thái riêng biệt.

Cách làm hiệu quả với tác nhân ReAct cho nhóm vận hành

Các phương pháp hay nhất về tác nhân ReAct tốt nhất đang hoạt động. Chúng làm cho quy trình làm việc dễ dàng hơn trong việc gỡ lỗi, xem xét và cải thiện.

| Thực hành | Tại sao nó quan trọng | Ghi chú sản xuất | | ------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------- | | Thu hẹp công việc | Đại lý rộng rãi trôi dạt | Bắt đầu với một quy trình làm việc và một đầu ra | | Công cụ giới hạn | Truy cập quá nhiều làm tăng rủi ro | Chỉ cấp những công cụ cần thiết cho nhiệm vụ | | Quan sát cấu trúc | Khó xác thực các quan sát văn bản tự do | Trả về JSON hoặc bản ghi đã nhập nếu có thể | | Thêm cổng đánh giá | Các quyết định có tác động cao cần được giám sát | Sử dụng sự tự tin, độ nhạy cảm của dữ liệu và rủi ro hành động làm yếu tố kích hoạt | | Ghi nhật ký cuộc gọi công cụ | Thất bại cần có dấu vết | Nắm bắt đầu vào, đầu ra, độ trễ và lỗi | | Xác định điều kiện dừng | Vòng lặp có thể chạy quá lâu | Đặt giới hạn bước, thời gian chờ và phản hồi dự phòng | | Tách bản nháp khỏi bản thực thi | Đề xuất an toàn hơn hành động | Yêu cầu phê duyệt trước khi viết, gửi hoặc xóa | | Kiểm tra đường dẫn lỗi | Các bản demo con đường hạnh phúc bỏ lỡ rủi ro thực sự | Mô phỏng dữ liệu bị thiếu, công cụ xấu và bằng chứng mâu thuẫn |

Thiết kế đánh giá phải tương xứng. Đừng ép buộc con người phải phê duyệt mọi tra cứu vô hại. Yêu cầu xem xét khi đại lý chạm vào tiền, hồ sơ khách hàng, hệ thống sản xuất, khiếu nại pháp lý hoặc báo cáo điều hành.

Để biết các mẫu đánh giá sâu hơn, hãy xem hướng dẫn về Tác nhân AI có đánh giá của con người. Nó bao gồm vị trí đặt các điểm kiểm tra để việc xem xét bảo vệ quy trình làm việc mà không làm chậm từng bước.

Khả năng quan sát cũng là một phần của thiết kế. Quy ước ngữ nghĩa GenAI của OpenTelemetry cho thấy ngành đang hướng tới việc theo dõi rõ ràng hơn các lệnh gọi mô hình, lệnh gọi công cụ và phạm vi tác nhân. Ngay cả khi ngăn xếp của bạn đơn giản hơn, nguyên tắc vẫn giữ nguyên: nếu bạn không thể kiểm tra quá trình chạy, bạn không thể vận hành tác nhân.

Bạn đã sẵn sàng mở rộng quy trình sản xuất chưa? Hãy sử dụng Sách hướng dẫn hoạt động của tác nhân AI để xác định các yếu tố kích hoạt, giám sát và quyền sở hữu leo thang trước khi triển khai.

Những lỗi thường gặp của tác nhân ReAct cần tránh

Tác nhân ReAct không thành công khi các nhóm coi nó như một lời nhắc thông minh thay vì một mô hình vận hành. Vấn đề nhanh chóng, nhưng hành vi sản xuất phụ thuộc vào các hợp đồng xung quanh.

| Sai lầm | Tại sao nó quan trọng | Cách tiếp cận tốt hơn | | ---------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ | | Bắt đầu quá rộng | Đại lý không thể lựa chọn đáng tin cậy | Phạm vi một công việc và một đầu ra trước | | Thêm quá nhiều công cụ | Lựa chọn công cụ trở nên ồn ào | Chỉ thêm công cụ sau khi trường hợp thử nghiệm cần chúng | | Bỏ qua đánh giá | Hành động rủi ro tiếp cận người dùng quá nhanh | Chuyển các trường hợp không chắc chắn hoặc có tác động cao đến con người | | Không có điều kiện dừng | Đại lý có thể lặp lại hoặc chi tiêu quá mức | Đặt số bước tối đa, thời gian chờ và phản hồi dự phòng | | Quy tắc bằng chứng yếu | Các xác nhận quyền sở hữu không được hỗ trợ trông có vẻ bóng bẩy | Yêu cầu ghi nhãn nguồn và kiểm tra mâu thuẫn | | Đăng nhập kém | Lỗi không thể sửa được | Ghi lại các cuộc gọi công cụ, quan sát và kết quả xác thực | | Chỉ đo câu trả lời cuối cùng | Độ tin cậy của quy trình làm việc vẫn vô hình | Đánh giá việc sử dụng công cụ, leo thang, phục hồi và chi phí |

Một lỗi phổ biến xuất hiện trong quy trình nghiên cứu. Người đại diện thu thập năm nguồn, nhưng hai nguồn mâu thuẫn với nhau. Nếu lời nhắc chỉ nói "viết báo cáo", câu trả lời cuối cùng có thể che giấu xung đột. Việc triển khai tác nhân ReAct tốt hơn sẽ đánh dấu sự mâu thuẫn, yêu cầu xem xét hoặc đưa ra đề xuất đủ điều kiện.

Một thất bại khác là việc sử dụng quá mức công cụ. Các nhóm kết nối các công cụ email, CRM, kho hàng, tìm kiếm và quản lý dự án cùng một lúc. Sau đó, họ không thể biết liệu đầu ra kém đến từ mô hình, dữ liệu, hợp đồng công cụ hay lớp điều phối. Bắt đầu nhỏ hơn.

Cách đánh giá tác nhân ReAct trước khi sản xuất

Trước khi sản xuất, tác nhân ReAct phải được xem xét theo các tiêu chí ở cấp độ quy trình công việc:

Bạn nên đánh giá tác nhân ReAct như một quy trình công việc chứ không phải dưới dạng một câu trả lời duy nhất. Phản hồi cuối cùng chỉ là một đầu ra của hệ thống.

Theo dõi các tiêu chí này trong quá trình thử nghiệm:

• Chất lượng hoàn thành nhiệm vụ
• Độ chính xác của công cụ sử dụng
• Chất lượng bằng chứng
• Hành vi leo thang
• Khôi phục lỗi
• Tính nhất quán trong các lần chạy lặp lại
• Nỗ lực đánh giá con người
• Thời gian chu kỳ
• Chi phí mỗi lần chạy
• Tỷ lệ thất bại theo công cụ

Số liệu phân phối nội bộ ban đầu là tùy chọn, nhưng chúng trở nên quan trọng khi quy trình làm việc chạy lặp đi lặp lại. Tỷ lệ leo thang cho bạn biết liệu đại lý quá thận trọng hay quá tự tin. Nỗ lực đánh giá cho thấy liệu con người đang phê duyệt công việc hữu ích hay đang sửa chữa những sai sót có thể phòng ngừa được. Chi phí mỗi lần chạy giúp bạn quyết định nơi lưu vào bộ nhớ đệm, đơn giản hóa hoặc di chuyển logic xác định ra khỏi mô hình.

Một bộ thử nghiệm tốt bao gồm các trường hợp dự kiến, các trường hợp đặc biệt và các trường hợp thất bại. Đối với đại lý báo cáo, điều đó có nghĩa là chuyển động số liệu bình thường, thiếu dữ liệu kho, hồ sơ trùng lặp, nhập chậm và sự bất thường không có nguyên nhân rõ ràng.

Mục tiêu không phải là quyền tự chủ hoàn hảo. Mục tiêu là một quy trình làm việc có thể dự đoán được, yêu cầu trợ giúp khi cần và cung cấp cho người vận hành đủ bằng chứng để tin tưởng hoặc từ chối đầu ra.

Kết luận: chạy tác nhân ReAct như một quy trình làm việc có trách nhiệm

Tác nhân ReAct rất hữu ích vì lý luận, sử dụng công cụ, quan sát và đánh giá phối hợp với nhau. Mẫu này giúp các nhóm xây dựng hệ thống kiểm tra thông tin trước khi trả lời, điều chỉnh sau khi gọi công cụ và dừng lại khi bằng chứng không đủ mạnh.

Bài học sản xuất rất đơn giản: quy trình làm việc chỉ đáng tin cậy khi có ranh giới. Xác định công việc. Hạn chế các công cụ Quan sát cấu trúc. Thêm xác nhận. Đặt đánh giá của con người ở nơi có chi phí sai sót cao. Đăng nhập đủ chi tiết để người vận hành gỡ lỗi quá trình chạy.

Đối với một nhóm nhỏ, bước tiếp theo tốt nhất không phải là một trợ lý tự chủ rộng rãi. Chọn một quy trình làm việc có nhu cầu lặp lại và các chế độ lỗi có thể nhìn thấy được. Xây dựng tác nhân ReAct xung quanh công việc đó, kiểm tra nó trước các trường hợp lỗi và chỉ mở rộng sau khi vòng lặp hoạt động đáng tin cậy.

Nhóm Van Data giúp các nhóm biến các khái niệm về tổng đài viên thành AI sản xuất và quy trình làm việc về dữ liệu với các biện pháp bảo vệ, leo thang, khả năng quan sát và quyền sở hữu rõ ràng. Bắt đầu với quy trình làm việc của tác nhân AI sản xuất khi mục tiêu là một hệ thống mà nhóm của bạn có thể chạy sau khi ra mắt.