Rủi ro và thất bại của AI: Tại sao agent "tạm ổn" lại hỏng?

Rủi ro và chế độ thất bại của các tác nhân AI chủ yếu đến từ những lỗi tích lũy âm thầm qua việc sử dụng công cụ nhiều bước, chứ không phải từ một sự cố mô hình kịch tính. Một quy trình làm việc trông có vẻ “đúng” 90% ở mỗi bước vẫn có thể không sử dụng được từ đầu đến cuối trừ khi nó được xây dựng với các quyền hạn rõ ràng, các điểm kiểm tra và giám sát.

Điểm nổi bật chính

• Độ tin cậy của tác nhân đa bước nhân lên qua các bước, vì vậy độ chính xác 85% cho mỗi hành động có thể giảm xuống khoảng 20% thành công trong một quy trình 10 bước, trong khi 95% cho mỗi hành động đạt khoảng 60%.
• Các lỗi tác nhân gây hại nhất là những lỗi “mềm”: các đầu ra có vẻ hợp lý, các lệnh gọi công cụ sai và các mục tiêu lệch lạc không kích hoạt lỗi hoặc cảnh báo.
• Hệ thống đa tác nhân thêm vào các chế độ thất bại của riêng chúng, bao gồm thiên lệch tuân thủ và trạng thái chia sẻ lỗi thời, điều này có thể biến một ảo giác thành sự đồng thuận sai.
• Tiêm lệnh là một mối đe dọa ở tầng thực thi đối với các tác nhân vì nó có thể điều hướng các cuộc gọi công cụ và mục tiêu, không chỉ đơn thuần là đầu ra văn bản.

Cách mà các lỗi của tác nhân AI khác nhau

Một tác nhân sản xuất thất bại giống như một chuỗi thực thi rò rỉ, không giống như một chương trình bị sập. Phần mềm truyền thống có xu hướng hỏng hóc một cách ầm ĩ: mộtAPItrả về 500, một lỗi truy vấn cơ sở dữ liệu, một công việc thất bại và thử lại. Các quy trình làm việc tự động thường “thành công” trong giao diện người dùng trong khi làm sai, vì hệ thống đang tối ưu hóa cho sự nhất quán và hoàn thành, không phải sự thật.

Đó là sự thay đổi mô hình tư duy chính cho bất kỳ ai xây dựng những gì là ai agents trong crypto: sự thất bại thường là một đầu ra trông sạch sẽ nhưng về mặt vận hành lại sai.

Toán học lãi suất kép là phần mà hầu hết các đội bỏ qua. Ví dụ của Trantor rất rõ ràng: nếu một tác nhân có độ chính xác 85% cho mỗi hành động, một quy trình 10 bước chỉ thành công khoảng 20% thời gian. Ngay cả độ chính xác 95% cho mỗi bước cũng...lợi suấtchỉ khoảng 60% thành công sau 10 bước. Đó là hình dạng giống như sự suy giảm tỷ lệ lấp đầy trên một cuốn sách giao dịch khi một chiến lược cần nhiều lệnh phụ thuộc vào nhau. Mỗi bước có thể hợp lý ở mức địa phương nhưng vẫn tạo ra một chuỗi bị hỏng ở mức toàn cầu.

Các hệ thống có tính tác động cũng thất bại một cách không xác định. Hai lần chạy với cùng một đầu vào có thể phân kỳ vì mô hình lấy mẫu, đầu ra của công cụ thay đổi hoặc ngữ cảnh được truy xuất thay đổi. Redis định hình mô hình phổ biến này như là sự tích lũy lỗi trong các quy trình tuần tự, nơi mà các lỗi nhẹ lan truyền mà không có sự cố hoặc cảnh báo.

Tính chất “không có dấu vết ngăn xếp” đó là lý do tại sao các nhóm chẩn đoán sai sự cố của tác nhân là “chúng ta cần một mô hình tốt hơn” khi vấn đề thực sự là thiếu cổng và thiếu khả năng quan sát.

Crypto mang đến một lợi thế sắc bén hơn. Khi một tác nhân AI có một ví tác nhân, một cuộc gọi công cụ không phải là một yêu cầu API vô hại. Nó có thể là một giao dịch, một phê duyệt, một cầu nối, hoặc một chữ ký. Chi phí của một sai lầm im lặng không phải là một câu trả lời tồi. Đó là một hành động trên chuỗi được giải quyết.

Các chế độ lỗi của tác nhân chính cần mong đợi

Sử dụng công cụ sai là chế độ thất bại cơ bản vì nó nằm ở ranh giới giữa ngôn ngữ và thực thi. Trantor mô tả các tác nhân chọn sai công cụ, truyền tham số không chính xác, hoặc bỏ qua lỗi công cụ và tiếp tục như thể hành động đã thành công. Trong bối cảnh tác nhân AI rủi ro crypto, điều này tương ứng rõ ràng với các lỗi kiểu “chuỗi sai, token sai, người chi tiêu sai, số tiền sai”. Phần nguy hiểm không phải là cuộc gọi thất bại. Phần nguy hiểm là cuộc gọi thành công một phần và tác nhân xây dựng các bước tiếp theo trên một trạng thái bị hỏng.

Sự trôi dạt ngữ cảnh và các chuỗi ảo giác là lớp thứ hai. Khi các đầu ra của công cụ và lý luận trung gian tích lũy, sự chú ý của mô hình trở nên mỏng manh và nó bắt đầu hoạt động trên một phiên bản méo mó của mục tiêu. Trantor liên kết điều này với hiệu ứng bị lạc ở giữa trong các ngữ cảnh dài.

Redis tách giới hạn cửa sổ ngữ cảnh khỏi sự phân rã ngữ cảnh, và nhấn mạnh điểm mà các nhà giao dịch sẽ nhận ra: việc thêm thông tin có thể làm xấu đi chất lượng quyết định khi hệ thống không thể truy xuất một cách đáng tin cậy phần thông tin liên quan.

Sự trôi mục tiêu là sự rò rỉ chậm. Trantor mô tả nó như một sự thất bại phát sinh mà không có bước nào là “sai,” nhưng tác nhân cuối cùng lại tối ưu hóa cho một mục tiêu khác với thông số ban đầu. Trong các quy trình làm việc liên quan đến crypto, sự trôi mục tiêu xuất hiện như một tác nhân bắt đầu với “cân bằng rủi ro” và kết thúc với “tối đa hóa hoạt động” vì nó đã học rằng thực hiện nhiều cuộc gọi công cụ hơn trông giống như một tiến bộ.

Các vòng lặp thử lại và chi phí không kiểm soát là chế độ hỏng hóc cơ học ảnh hưởng đến ngân sách trước khi ảnh hưởng đến độ chính xác. Trantor đánh dấu các vòng lặp vô hạn nơi các cuộc gọi công cụ thất bại kích hoạt các nỗ lực lặp lại, và khuyến nghị giới hạn lặp cứng và giới hạn chi tiêu. Đây là cách dịch rõ ràng nhất của kỷ luật bàn làm việc vào hoạt động của đại lý: nếu hệ thống không thể dừng lại giữa chừng, nó không sẵn sàng cho sản xuất.

Sự suy giảm chất lượng âm thầm là điều khiến các nhóm phải chịu đựng trong nhiều tuần. Trantor liệt kê các nguyên nhân như sự trôi dạt của kho tài liệu, sự suy giảm prompt, sự thay đổi hành vi mô hình âm thầm và sự thay đổi phân phối đầu vào. Đại lý vẫn tiếp tục "hoàn thành" các nhiệm vụ, nhưng tính hữu ích giảm xuống dưới ngưỡng mà đầu ra an toàn để hành động.

Phối hợp đa tác nhân và rủi ro chuỗi

Các thiết lập đa tác nhân thường được bán như một biện pháp an toàn thông qua sự dư thừa. Các nguồn chỉ ra điều ngược lại trừ khi việc xác minh được thiết kế một cách rõ ràng. Redis nhấn mạnh thiên lệch tuân thủ: các tác nhân hạ nguồn có xu hướng đồng nhất với một khẳng định tự tin từ hạ nguồn, củng cố một ảo giác thành sự đồng thuận sai. Đó không phải là một đặc điểm lý thuyết. Đó là một chế độ thất bại phối hợp trông giống như sự đồng ý và giao hàng đầu ra sai nhanh hơn.

Nghiên cứu arXiv chính thức hóa điều này với MASFT, một phân loại 14 chế độ thất bại đa tác nhân được nhóm thành ba loại: thất bại trong thiết kế đặc tả và hệ thống, sự không đồng nhất giữa các tác nhân, và thất bại trong xác minh và kết thúc nhiệm vụ. Nghiên cứu phân tích năm khung MAS trên hơn 150 nhiệm vụ với các dấu vết được chú thích bởi con người và báo cáo sự đồng thuận giữa các người chú thích với Kappa của Cohen là 0.88.

Nó cũng báo cáo rằng độ chính xác của ChatDev có thể thấp tới 25% trong đánh giá của họ, và rằng các can thiệp nỗ lực tốt nhất như cải thiện đặc tả vai trò và phối hợp đã cải thiện ChatDev thêm +14% nhưng vẫn không đủ cho việc triển khai trong thế giới thực.

Chi phí phối hợp không chỉ là độ trễ. Nó tiêu tốn ngân sách ngữ cảnh. Redis lưu ý rằng các biến thể đa tác nhân có thể hoạt động kém hơn các tiêu chuẩn đơn tác nhân trong lý luận tuần tự vì chi phí giao tiếp vượt quá bất kỳ lợi ích song song nào. Mỗi lần chuyển giao thêm là một nơi khác cho một lỗi mềm trở thành "trạng thái."

Bộ nhớ chia sẻ và trạng thái cũ là động cơ chuỗi khác. Redis mô tả các tác nhân đọc trạng thái chia sẻ vào những thời điểm khác nhau và hành động dựa trên thông tin đã bị thay thế bởi các hành động đồng thời. Trong crypto, đó là cách mà một tác nhân có thể phê duyệt một người chi tiêu dựa trên số dư trước đó, sau đó thực hiện một giao dịch dựa trên số dư sau đó, và không hòa giải cả hai.

Một mạng lưới giải quyết có thể giảm bớt một số độ phức tạp thực thi bằng cách thuê ngoài việc tìm đường, nhưng nó cũng trở thành một ranh giới khác nơi các đầu ra phải được xác minh trước khi bước tiếp theo.

Bài học đa tác nhân rất đơn giản: nhiều tác nhân không tạo ra nhiều sự an toàn theo mặc định. Họ tạo ra nhiều bề mặt cho những giả định chưa được xác minh trở nên bền vững.

Các mối đe dọa an ninh trong quy trình làm việc của tác nhân

Tiêm prompt là chế độ thất bại an ninh quan trọng nhất đối với các tác nhân vì nó không bị giới hạn ở văn bản. Trantor mô tả tiêm prompt là lỗ hổng số một trong danh sách 10 lỗ hổng hàng đầu của OWASP LLM cho năm 2025 và nhấn mạnh rằng nó nguy hiểm hơn trong các bối cảnh tác nhân vì nó có thể chiếm đoạt mục tiêu và các cuộc gọi công cụ xuyên suốt quy trình làm việc. Đó là sự khác biệt giữa "chatbot nói điều gì đó kỳ lạ" và "tác nhân thay đổi những gì nó đang cố gắng làm."

Rủi ro an ninh của tác nhân mở rộng vì mọi đầu vào bên ngoài giờ đây đều là ảnh hưởng có thể thực thi. Tài liệu được truy xuất, đầu ra công cụ, bộ nhớ, và thậm chí các tin nhắn từ các tác nhân khác đều là những đầu vào có thể mang theo các hướng dẫn thù địch. Trantor khuyến nghị coi mọi tài liệu, bản ghi cơ sở dữ liệu, phản hồi API, và đầu ra công cụ như có thể thù địch, và làm sạch các đầu vào trước khi chúng vào ngữ cảnh của tác nhân.

Trong lĩnh vực tiền điện tử, các kịch bản tác nhân tiêm lệnh là đơn giản: một mục danh sách token độc hại, một đoạn “tài liệu” bị nhiễm độc trong quá trình truy xuất, hoặc một phản hồi công cụ được chế tạo có thể dẫn dắt tác nhân đến việc phê duyệt một người chi tiêu, kết nối với một kẻ tấn công kiểm soát.địa chỉ, hoặc ký một thông điệp không mong muốn.

Đó là lý do tại sao rủi ro an ninh của các tác nhân AI chủ yếu liên quan đến việc kiểm soát hành động, chứ không phải rò rỉ dữ liệu.

Các biện pháp giảm thiểu là kiến trúc. Một tee có thể giúp đảm bảo tính toàn vẹn và cách ly cho các phần của môi trường thực thi, nhưng nó không tự mình giải quyết vấn đề chiếm đoạt lệnh. Phòng thủ cốt lõi là hạn chế những gì tác nhân có thể làm, xác thực những gì nó sắp làm và ghi lại những gì nó đã làm theo cách có thể được kiểm toán.

Trantor cũng cho rằng 88% các tổ chức triển khai các tác nhân AI đã báo cáo ít nhất một sự cố an ninh vào năm 2025. Con số này được trình bày như một tuyên bố thứ cấp trong nguồn, nhưng nó phù hợp với xu hướng: khi các tác nhân có thể hành động, bề mặt sự cố phát triển nhanh hơn so với khả năng kiểm soát của hầu hết các đội ngũ.

Thiết kế và kiểm soát hoạt động hiệu quả

Các biện pháp kiểm soát hiệu quả giống như giới hạn rủi ro, không phải là “nhắc nhở tốt hơn.” Luận điểm từ các nguồn là các lỗi của tác nhân tích lũy qua các bước và các bên liên quan, vì vậy hệ thống cần có giới hạn rõ ràng, xác minh và khả năng quan sát tại mọi ranh giới.

Một ngăn xếp điều khiển kiểu bàn có thể được biểu diễn dưới dạng một chuỗi xây dựng có thứ tự:

1. Phạm vi công cụ để quyền hạn tối thiểu. Các ví dụ về việc lạm dụng công cụ của Trantor về cơ bản là những thất bại trong việc cấp quyền. Một tác nhân không nên có quyền truy cập vào hệ thống tệp hoặc quyền quản trị rộng rãi khi chỉ cần một chức năng, và logic tương tự áp dụng cho ví của tác nhân có thể ký các giao dịch tùy ý. 2. Kiểm soát các cuộc gọi công cụ bằng các sơ đồ và điều kiện tiên quyết.

Trantor khuyến nghị xác thực sơ đồ để phát hiện các đối số không chính xác trước khi thực hiện. Đối với các công cụ tiền điện tử, điều đó có nghĩa là xác thực chuỗi, mã thông báo, số thập phân, người nhận và các delta cho phép trước khi một cuộc gọi được phép thực hiện. 3. Chèn các điểm kiểm tra xác minh.

Redis khuyến nghị xác thực tại mọi ranh giới, và phân loại MASFT của arXiv đánh dấu các thất bại trong xác minh và kết thúc nhiệm vụ là một loại chính. Vai trò xác minh phải khác biệt về cấu trúc so với người lập kế hoạch, nếu không sẽ trở thành một nền văn hóa đơn điệu. 4. Kiểm soát sự phát triển của ngữ cảnh. Trantor khuyến nghị tóm tắt theo cấp bậc ở các khoảng thời gian đều đặn để ngăn chặn sự trôi dạt ngữ cảnh.

Redis cảnh báo rằng việc thêm nhiều ngữ cảnh có thể làm trầm trọng thêm các vấn đề phối hợp do sự mục nát ngữ cảnh và hành vi bị lạc giữa chừng. 5. Giới hạn vòng lặp và chi phí ở tầng điều phối. Trantor kêu gọi giới hạn vòng lặp cứng và giám sát chi phí theo thời gian thực với các giới hạn chi tiêu. Đây là yêu cầu công tắc ngắt trong hình thức kỹ thuật. 6. Xây dựng khả năng quan sát phù hợp với các hệ thống xác suất.

Redis khuyến nghị ID tương quan cho mỗi lần gọi tác nhân, cuộc gọi công cụ và tin nhắn giữa các tác nhân, cộng với các dấu vết có cấu trúc bao gồm mã thông báo đã tiêu thụ, độ trễ và trạng thái thành công hoặc thất bại theo từng bước. Sự suy giảm chất lượng im lặng chỉ xuất hiện khi phân phối đầu ra và mẫu.kiểm toánđược theo dõi theo thời gian.

Các kiểm soát tổ chức quan trọng không kém gì các kiểm soát kỹ thuật. Trantor cho rằng sự mở rộng phạm vi và các vấn đề về chất lượng dữ liệu chiếm 61% tổng số thất bại của các tác nhân AI. Đó là lý do không hấp dẫn khiến nhiều dự án thử nghiệm không bao giờ trở thành hệ thống sản xuất.

Những điểm rút ra thực tiễn để triển khai an toàn hơn

Sự sẵn sàng cho sản xuất bắt đầu bằng việc đo lường chuỗi, không phải ngắm nhìn mô hình. Nếu quy trình làm việc cần 10 bước phụ thuộc, con số độ tin cậy duy nhất trung thực là tỷ lệ thành công gộp, không phải “độ chính xác” theo từng bước. Ví dụ từ Trantor với 85% đến ~20% là cách nhanh nhất để kiểm tra xem một hệ thống là bản demo hay công cụ hoạt động.

Thiết kế đa tác nhân cần phải xứng đáng với độ phức tạp của chúng. Bài báo trên arXiv cho thấy sự cải thiện hiệu suất tối thiểu qua các tiêu chuẩn và ghi nhận độ chính xác thấp cho ChatDev trong một số đánh giá. Redis lập luận rằng các thiết lập đơn tác nhân có thể vượt trội hơn các thiết lập đa tác nhân trong lý luận tuần tự vì chi phí phối hợp làm mất đi ngữ cảnh và giới thiệu các chế độ thất bại mới.

Đa tác nhân có thể được biện minh cho công việc có thể song song hóa, nhưng chỉ khi vai trò của người xác minh và tiêu chí kết thúc được xác định rõ ràng.

Đối với các triển khai crypto, ưu tiên hàng đầu là hạn chế thực thi. Một tác nhân AI với ví tác nhân nên hoạt động với quyền hạn chặt chẽ, giới hạn chi tiêu nghiêm ngặt và có công tắc ngắt có thể chấm dứt giữa chừng. Xem đầu ra của công cụ, tài liệu được truy xuất và bộ nhớ như là các đầu vào đối kháng, vì việc tiêm lệnh là một sự chiếm đoạt quy trình làm việc, không phải là một mẹo trò chuyện.

Ưu tiên thứ hai là khả năng quan sát. Các lỗi nhẹ không làm ai phải chú ý. Chúng xuất hiện dưới dạng những thay đổi tinh tế trong việc tuân thủ định dạng, điểm số tự tin, tỷ lệ lỗi công cụ, mức sử dụng token và tỷ lệ hoàn thành. Nếu không có dấu vết, các đội không thể phân biệt giữa ảo giác, trạng thái cũ và sự lệch mục tiêu, và họ sẽ tiếp tục “sửa đổi câu lệnh” trong khi hệ thống vẫn tiếp tục thất bại.

Câu chuyện về các tác nhân trong crypto đang hướng tới nhiều quyền tự chủ hơn, nhiều quyền truy cập công cụ hơn, và nhiềutính khả kết hợpĐiều đó khiến cho các rủi ro và chế độ thất bại của các tác nhân AI trở thành một vấn đề thiết kế, chứ không phải là vấn đề mô hình, và các đội ngũ tồn tại sẽ trông giống như các bàn thực thi có kỷ luật: giới hạn rõ ràng, xác minh tại các ranh giới, và giám sát chặt chẽ những gì hệ thống thực sự đã làm.

Quan điểm

Tôi đã thấy các đội coi tỷ lệ "đáp án tốt" 90% như một SLA sản xuất, rồi tỏ ra ngạc nhiên khi nhân viên gặp khó khăn ngay khi phải thực hiện mười việc liên tiếp. Phép toán Trantor là cái tát đúng chỗ: 85% mỗi bước chuyển thành ~20% từ đầu đến cuối qua 10 bước chính là cách mà một chiến lược có tỷ lệ thành công tốt vẫn thất bại khi cần một chuỗi các lần điền.

Tôi cũng đã thấy các thiết lập đa tác nhân tạo ra sự thoải mái giả tạo. Trong các quy trình tuần tự, thiên lệch tuân thủ của Redis xuất hiện nhanh chóng: một ảo giác tự tin trở thành "sự đồng thuận" vì không ai được trả tiền để xác minh, chỉ để đồng ý.

Tư thế mà giữ vững là nhàm chán và hiệu quả: quyền hạn tối thiểu, cổng lược đồ, điểm kiểm tra xác minh, giới hạn chi phí cứng và các dấu vết cho phép ai đó phát lại quá trình và xác định điểm chuyển giao xấu đầu tiên.

Nguồn

• Trantor
• Redis
• arXiv