Vòng lặp tác tử AI: quan sát, dùng công cụ và biết dừng

Đăng ngày 27/10/2026

Vòng lặp cần tạo tiến triển có thể kiểm

Vòng lặp tác tử AI là chu trình trong đó hệ thống đọc trạng thái công việc, chọn bước tiếp theo, gọi công cụ rồi dùng kết quả nhận được để quyết định tiếp tục hay dừng. Trong doanh nghiệp, điều cần thiết kế trước là kết quả được phép tạo và bằng chứng xác nhận kết quả ấy. Một tác tử nói đã kiểm hồ sơ không đồng nghĩa hồ sơ đã đủ, nguồn còn hiệu lực hoặc thao tác cập nhật thật sự thành công.

ReAct nghiên cứu cách xen kẽ suy luận và hành động để thu thêm thông tin từ môi trường, cập nhật kế hoạch và xử lý ngoại lệ trong những tác vụ thử cụ thể [1]. Bài nghiên cứu cung cấp một cơ chế đáng chú ý, không phải bảo chứng rằng mọi tác tử dùng vòng lặp đều đáng tin. Khi đưa vào công việc, cần thêm trạng thái có cấu trúc, ranh giới quyền và phép kiểm ngoài lời tự mô tả của mô hình.

Bài viết dùng ca giả định về trợ lý kiểm hồ sơ mua sắm nội bộ để đề xuất hai công cụ: phiếu điều kiện trước và sau mỗi hành động; sổ tiến triển để phát hiện vòng lặp không thêm bằng chứng. Các bước, tiêu chí và tình huống là thiết kế biên tập, chưa được thử tại một doanh nghiệp Việt Nam. Mục tiêu là giúp chủ nghiệp vụ giao phạm vi rõ và nhận lại kết quả có thể xem xét.

Việc nào cần vòng lặp, việc nào nên đi theo bước cố định?

Trong Building effective agents, Anthropic phân biệt luồng được định sẵn bằng mã với tác tử để mô hình linh hoạt chọn tiến trình, đồng thời khuyến nghị tăng độ phức tạp khi có nhu cầu thực [2]. Đây là quan điểm thiết kế của nhà cung cấp, công bố năm 2024; trang hiện cũng lưu ý bối cảnh công cụ đã thay đổi. Bài này dùng sự phân biệt kiến trúc ấy, không khẳng định một bộ công cụ hiện hành là lựa chọn tốt nhất.

Nếu hồ sơ luôn có cùng các trường và quy tắc kiểm rõ, một quy trình cố định có thể đủ: nhận tệp, kiểm trường, đối chiếu dữ liệu và lập danh sách thiếu. Vòng lặp linh hoạt có ích hơn khi cần chọn tài liệu để đọc tiếp hoặc làm rõ một mâu thuẫn chưa biết trước. Dù dùng cách nào, phần kiểm số tiền, điều kiện bắt buộc và quyền cập nhật vẫn nên được biểu đạt rõ, không giao hết cho diễn giải tự do.

Một hệ thống có thể kết hợp hai cách. Các điểm đầu vào, xác thực quyền, lưu bản nháp và bàn giao được điều khiển theo luồng đã định; trong khoảng giữa, mô hình chọn câu hỏi hoặc nguồn cần xem. Chủ nghiệp vụ nên biết chỗ nào có đường đi cố định và chỗ nào có lựa chọn linh hoạt. Khi có lỗi, bản đồ này giúp tìm xem cần sửa quy tắc điều phối, mô tả công cụ hay cách mô hình diễn giải bằng chứng.

Mục tiêu ổn định, kế hoạch được phép đổi

Toolformer nghiên cứu việc học cách chọn công cụ, thời điểm gọi, tham số và cách sử dụng kết quả; phiên bản nghiên cứu cũng nêu hạn chế trong sử dụng công cụ theo chuỗi và tương tác [3]. Khả năng chọn một lời gọi vì vậy khác với khả năng hoàn thành công việc nhiều bước. Trong ca mua sắm, tìm thấy báo giá chưa đồng nghĩa đã so được điều kiện giao hàng, xác định đúng phiên bản hồ sơ hoặc có quyền đánh dấu hoàn tất.

Mục tiêu giao cho trợ lý có thể là lập bản rà soát các giấy tờ còn thiếu, kèm căn cứ cho từng kết luận, để người phụ trách mua sắm duyệt. Kế hoạch ban đầu là đọc đề nghị, đọc báo giá rồi đối chiếu yêu cầu. Nếu gặp hai báo giá mang cùng tên nhưng khác ngày, trợ lý cần đổi kế hoạch để xác định bản đang có hiệu lực. Nó không được tự đổi mục tiêu thành chọn nhà cung cấp chỉ vì đã có đủ thông tin để đưa ra một gợi ý.

Nên định nghĩa hoàn thành bằng vật bàn giao. Một bản rà soát cần nêu giấy tờ đã thấy, phần còn thiếu, mâu thuẫn chưa giải quyết và nguồn cho các nhận định. Nếu một yêu cầu vượt quyền, kết quả có thể là bàn giao phần đã kiểm cùng câu hỏi cụ thể cho người có trách nhiệm. Hành vi này vẫn hữu ích nếu được ghi đúng trạng thái. Gắn hoàn thành cho cả phần chưa thể kiểm sẽ che mất việc đang chờ quyết định.

Mỗi lần đổi kế hoạch cần ghi lý do ngắn gắn với nguồn: báo giá có ngày mới hơn nên phải xác nhận bản hiệu lực. Nhật ký ưu tiên điều kiện, quyết định và kết quả kiểm được. Không coi toàn bộ lời suy luận do mô hình sinh là bằng chứng.

Quan sát phải giữ được nguồn và trạng thái chưa biết

ToolEmu khảo sát rủi ro khi tác tử thực hiện yêu cầu thiếu chi tiết hoặc mơ hồ bằng một môi trường công cụ được mô phỏng; chính thiết lập ấy có giới hạn cần kiểm bằng người [4]. Liên hệ thực hành là tác tử không nên lấp khoảng trống quan trọng bằng suy đoán để giữ đà chạy. Nếu yêu cầu kiểm hồ sơ không xác định đơn vị, bản tài liệu hoặc phạm vi quyền, cần nhận ra phần nào có thể làm tiếp và phần nào phải làm rõ.

Một quan sát hữu ích gồm nội dung được đọc, nguồn, phiên bản hoặc thời điểm nếu có, quyền truy cập và lỗi trả về. Không tìm thấy tệp khác với không có tệp. Công cụ trả không đủ quyền khác với hồ sơ không hợp lệ. Khi các trạng thái ấy bị gom thành một câu không có dữ liệu, mô hình có thể kết luận sai nguyên nhân và lặp lại những lần tìm kiếm không giải quyết được vấn đề thật sự.

Nội dung báo giá, thư trao đổi hoặc ghi chú trong tệp là dữ liệu để xét theo nhiệm vụ, không tự có quyền đổi chỉ dẫn vận hành. Nếu tệp có câu yêu cầu bỏ qua kiểm tra hoặc gửi hồ sơ tới địa chỉ khác, hệ thống cần giữ nó trong phạm vi nội dung tài liệu. Đường quyết định quyền phải nằm ngoài nội dung vừa đọc. Bài này chỉ nêu ranh giới cần thiết; phép kiểm tấn công và cơ chế bảo vệ phải được thiết kế riêng theo hệ thống cụ thể.

Trạng thái chưa biết cần được lưu như một kết quả hợp lệ. Ví dụ, chưa xác định báo giá mới đã được chủ hồ sơ chấp thuận thì đánh dấu chờ xác nhận, không mặc định lấy bản mới nhất làm bản chính. Khi bằng chứng thay đổi, cập nhật trạng thái có dẫn nguồn và giữ lý do. Cách làm này giúp người xem phân biệt kết luận đã xác minh, giả thuyết đang kiểm và thông tin đơn thuần được chép từ tài liệu.

Công cụ một: phiếu điều kiện trước và sau hành động

Phiếu được đề xuất có năm ô: việc định làm, điều kiện phải đúng trước khi làm, công cụ được phép dùng, bằng chứng cần thấy sau khi làm và cách xử lý khi chưa biết kết quả. Nó biến câu gọi công cụ thành một hành động có thể xem xét. Với đọc tài liệu, điều kiện có thể đơn giản. Với cập nhật trạng thái hồ sơ, phiếu phải chỉ rõ đối tượng, phạm vi quyền và điều gì được coi là cập nhật đúng.

Trước thao tác đọc, kiểm rằng đúng hồ sơ và tài liệu thuộc phạm vi được phép. Sau thao tác, kiểm nội dung đủ để trả lời câu hỏi đang xét, thay vì chỉ ghi công cụ chạy thành công. Trước thao tác tạo bản nháp, xác định nơi lưu và nguồn cần gắn. Sau đó đọc lại bản nháp để kiểm đối tượng, thiếu sót và đường dẫn căn cứ. Mỗi bước cần hậu kiểm tương xứng với ảnh hưởng của hành động ấy.

Với cập nhật có tác dụng bên ngoài, kết quả trả về cần phân biệt đã làm, bị từ chối và chưa rõ đã làm hay chưa. Một lần hết thời gian chờ không chứng minh thao tác thất bại. Tác tử phải kiểm trạng thái hiện hành bằng đường được phép trước khi thử lại, nếu công cụ và quy trình hỗ trợ. Nếu không thể xác định, hãy bàn giao trạng thái không chắc chắn thay vì gửi lại lệnh có thể tạo thay đổi trùng.

Phiếu cũng làm rõ quyền suy nghĩ về hành động khác với quyền thực hiện nó. Trợ lý có thể đề xuất bổ sung một tài liệu mà chưa được phép gửi yêu cầu cho nhà cung cấp; có thể nêu hồ sơ đủ để người duyệt xem mà chưa được phép phê duyệt mua. Bộ điều phối và công cụ cần chặn thao tác vượt quyền. Một câu nhắc trong lời giao việc là hữu ích, nhưng không thay cho ranh giới quyền thực thi được kiểm ở hệ thống.

Công cụ hai: sổ tiến triển thay cho đếm bước đơn thuần

Tài liệu Graph API của LangGraph mô tả trạng thái, nút, cạnh và giới hạn số bước của một lần chạy; chạm giới hạn có thể dẫn tới lỗi thực thi riêng của nền tảng [5]. Đây là ví dụ triển khai cho việc kiểm soát vòng lặp, không phải quy tắc chung của mọi tác tử. Giới hạn số bước cũng không tự giới hạn thời gian, chi phí hoặc hậu quả của từng lời gọi; các giới hạn ấy cần được thiết kế thêm theo công việc.

Sổ tiến triển được đề xuất ghi sau mỗi hành động: câu hỏi đang giải quyết, bằng chứng mới thu được, việc còn thiếu và lý do bước sau khác bước trước. Nếu đọc lại cùng một tài liệu không làm rõ được mâu thuẫn, cần nhận ra việc chưa tiến triển. Không nhất thiết cấm đọc lại: lần đọc mới có thể cần một phần khác. Điều cần kiểm là lần thử có thay đổi câu hỏi hoặc bổ sung căn cứ, thay vì lặp nguyên thao tác và mong kết quả tự khác.

Ngân sách vòng lặp nên tách số lần gọi, thời gian chờ và chi phí đã phát sinh. Một lời gọi đọc kho hồ sơ chậm có thể dùng hết thời gian dù số bước ít. Nhiều lời gọi rẻ vẫn có thể tạo tải không phù hợp cho hệ thống nội bộ. Người thiết kế cần chốt hành vi khi gần hết ngân sách: lưu phần đã xác minh, chỉ rõ việc còn thiếu và chuyển đúng người. Không chờ tới lúc tiến trình bị ngắt mới tìm cách giải thích kết quả dở dang.

Một tiêu chí dừng khác là không còn hành động được phép nào có thể bổ sung bằng chứng cần thiết. Khi đó, tác tử nên kết thúc với trạng thái chờ dữ liệu hoặc chờ người quyết định, kèm yêu cầu cụ thể. Đây khác với kết luận công việc không thể làm trong mọi hoàn cảnh. Sổ tiến triển giúp người tiếp nhận biết cần mở quyền nào, cung cấp tài liệu gì hoặc giải quyết mâu thuẫn nào để vòng làm việc sau có thể tiếp tục hữu ích.

Dừng đúng trạng thái và bàn giao phần còn thiếu

NIST AI 600-1 nêu các rủi ro của AI tạo sinh, trong đó có việc dữ liệu truy xuất mang chỉ dẫn ngoài ý muốn, và đề xuất kiểm, giám sát cùng quyết định quản lý rủi ro theo bối cảnh [6]. Đây là hướng dẫn kỹ thuật tự nguyện, không xác nhận một ứng dụng đã an toàn hay tuân thủ pháp luật Việt Nam. Với vòng lặp tác tử, việc dừng cần có trạng thái, người nhận và bằng chứng đủ để điều tra hoặc tiếp tục.

Nên phân biệt hoàn thành đã kiểm, hoàn thành một phần, chờ dữ liệu, chờ quyền và dừng vì lỗi hoặc rủi ro. Một hồ sơ có thể đã được rà soát đầy đủ trong phạm vi đọc, nhưng chưa được cập nhật vì thiếu quyền ghi. Báo hai điều đó riêng giúp tránh đánh giá sai năng lực và tránh người nhận tưởng thao tác cuối đã xảy ra. Trạng thái kết thúc phải được hệ thống lưu, không chỉ nằm trong đoạn văn cuối của tác tử.

Gói bàn giao nên có định danh hồ sơ, phiên bản đã kiểm, kết luận có nguồn, thay đổi đã thực hiện và danh sách việc chưa làm. Nếu một thao tác đang ở trạng thái chưa rõ, đặt nó ở vị trí dễ thấy cùng cách kiểm tiếp theo. Tránh đưa toàn bộ hội thoại hoặc dữ liệu cá nhân vào báo cáo chỉ để chứng minh đã làm nhiều bước. Bằng chứng cần đủ cho mục đích nhận việc và được giữ trong phạm vi truy cập thích hợp.

Tình huống giả định: rà soát hồ sơ mua sắm nội bộ

Giả sử một công ty dịch vụ tại Việt Nam giao trợ lý đọc đề nghị mua thiết bị, báo giá và danh mục giấy tờ nội bộ để lập bản rà soát cho nhân viên mua sắm. Quyền ban đầu chỉ gồm đọc các tài liệu đã chỉ định và tạo bản nháp trong nơi riêng. Không có quyền chọn nhà cung cấp, gửi đơn đặt hàng hoặc phê duyệt chi. Đây là tình huống giả định, không phải quy định hay kết quả triển khai đã xác minh của một doanh nghiệp.

Vòng đầu xác định đúng mã hồ sơ và danh sách tệp. Trợ lý thấy hai báo giá cùng tên nhà cung cấp, một bản có điều kiện giao hàng khác bản còn lại. Phiếu hành động yêu cầu chỉ đọc và đối chiếu, chưa được thay bản chính. Quan sát mới khiến kế hoạch chuyển sang tìm dấu xác nhận của chủ hồ sơ trong nguồn được phép. Nếu nguồn ấy không có hoặc ngoài quyền, bản rà soát phải nêu mâu thuẫn và câu hỏi cần xác nhận.

Trong một nhánh khác, tài liệu được phép đọc chứa bảng giá rõ nhưng đơn vị tính giữa đề nghị và báo giá khác nhau. Trợ lý không nên tự kết luận giá vượt ngưỡng khi chưa biết cách quy đổi đúng. Nó có thể lập danh sách trường cần làm rõ và dẫn tới hai ô liên quan. Khi người nghiệp vụ cung cấp quy tắc quy đổi được chấp thuận, vòng tiếp theo mới tính theo quy tắc ấy, ghi cách tính và kiểm kết quả bằng công cụ phù hợp.

Nếu đủ căn cứ, vật bàn giao là bản nháp rà soát, không phải quyết định mua. Người kiểm có thể mở từng nguồn và thấy lý do một giấy tờ được đánh dấu đủ hoặc thiếu. Phần chưa xác nhận vẫn hiện rõ. Nếu công cụ lưu bản nháp trả lỗi không xác định, trợ lý kiểm nơi lưu theo quyền trước khi tạo lại. Ca giả định này cho thấy kết thúc hữu ích có thể là một bản nháp có giới hạn rõ, thay vì cố làm tiếp tới một quyết định vượt nhiệm vụ.

Phạm vi vận hành theo năng lực của đội

Đội nhỏ nên bắt đầu với một loại hồ sơ và ít công cụ có mục đích rõ. Một người phụ trách nghiệp vụ giữ danh mục kiểm; một người kỹ thuật thiết kế quyền và trạng thái; người nhận bản rà soát thử khả năng kiểm căn cứ. Không cần nhiều tác tử để có vòng lặp tốt. Nếu tài liệu chưa có chủ nguồn hoặc quy tắc chưa thống nhất, bước chuẩn bị nghiệp vụ có thể quan trọng hơn việc chọn mô hình linh hoạt hơn.

Với nhiều phòng ban, cần mô tả phạm vi hiệu lực của quy tắc theo đơn vị và loại mua sắm. Một trạng thái có thể mang nghĩa khác giữa hệ thống đề nghị và hệ thống kế toán. Đừng cho phép mô hình suy rằng cùng tên trường thì cùng quyền cập nhật. Người vận hành cần biết nơi nào giữ trạng thái chính và ai xử lý khi hai nơi lệch nhau. Vòng lặp chỉ đáng mở rộng khi có thể truy lại một kết luận tới đúng hồ sơ và nguồn quy tắc.

Các chỉ số nên gồm tỷ lệ công việc có vật bàn giao được chấp nhận, phần kết luận thiếu nguồn, số hành động vượt phạm vi bị chặn và phần việc phải mở lại. Đo cả thời gian người kiểm đọc, sửa và làm rõ, cùng chi phí gọi công cụ và mô hình. Không lấy số bước đã chạy làm thành tích. Một vòng ít bước nhưng bỏ điều kiện bắt buộc không tốt hơn vòng dừng sớm và chỉ rõ điều còn thiếu.

Phép thử phải xem cả trạng thái cuối lẫn đường đi

τ-bench dùng hội thoại với người dùng mô phỏng, công cụ và quy tắc ngành, đồng thời so sánh trạng thái dữ liệu cuối với kết quả được chú giải; tác giả lưu ý kết quả cuối đúng vẫn có thể chưa đủ nếu đường đi vi phạm quy tắc [7]. Đây là benchmark nghiên cứu trong các miền đã thiết kế, không phải chứng nhận mua sắm. Bài học hữu ích là kiểm vật bàn giao và các hành động đã xảy ra, không chấm chỉ theo câu trả lời cuối nghe hợp lý.

AgentBench đánh giá tác tử trong nhiều môi trường tương tác và phân tích các kiểu thất bại, bao gồm vượt giới hạn tác vụ trong thiết lập nghiên cứu [8]. Không chuyển tỷ lệ hay thứ hạng của những mô hình được thử thành dự đoán cho ứng dụng hiện hành. Với ca mua sắm, hãy tự thiết kế các hồ sơ đủ, hồ sơ thiếu, nguồn mâu thuẫn, công cụ từ chối quyền và công cụ trả kết quả chưa rõ để xem vòng lặp xử lý từng nhánh.

Trước khi chạy thử, chốt kết quả mong đợi, hành động cấm, ngân sách và người chấm. Trong môi trường thử không tác động hệ thống thật, ghi trạng thái đầu, các lời gọi và kết quả quan sát. Lặp lại những ca quan trọng để thấy hệ thống có xử lý ổn định không. Nếu chỉ một lần thành công, báo đúng một lần thử; không suy rằng đường chạy ấy sẽ luôn lặp lại hoặc rằng các ca chưa thử đã được bao phủ.

Dừng mở rộng khi xuất hiện thao tác vượt quyền, kết luận quan trọng không có nguồn hoặc không biết một thay đổi đã xảy ra chưa. Sau sửa, kiểm lại cả ca từng lỗi và ca liên quan cần bảo toàn. Nếu muốn dùng thử có người kiểm, giới hạn phạm vi và giữ đường quay về cách làm thủ công. Điều kiện mở rộng là bằng chứng về nhiệm vụ cụ thể, không phải tác tử có thể kể một kế hoạch dài và trình diễn nhiều lời gọi liên tiếp.

Hỏi đáp về vòng lặp tác tử AI

Có cần cho tác tử tự do lập mọi bước không? Không. Có thể giữ các điểm kiểm quyền, lưu kết quả và bàn giao theo luồng cố định, chỉ cho mô hình lựa chọn trong khoảng công việc đã giới hạn. Phạm vi linh hoạt nên gắn với nhu cầu thật như tìm tài liệu tiếp theo hoặc hỏi thêm thông tin. Khi quy tắc đã rõ và đường đi ổn định, một quy trình định sẵn có thể dễ kiểm và vận hành hơn.

Giới hạn số bước có làm công việc bị bỏ dở không? Có thể, nên thiết kế cách kết thúc có ích trước khi chạm giới hạn. Tác tử cần lưu phần đã xác minh, việc còn thiếu và trạng thái thao tác chưa rõ nếu có. Giới hạn là rào kiểm soát tài nguyên, không phải tiêu chí duy nhất về chất lượng. Chủ nghiệp vụ cần chọn ngân sách phù hợp với hậu quả và khả năng tiếp nhận công việc dở dang.

Có nên lưu mọi lời suy luận để dễ điều tra không? Không cần coi toàn bộ văn bản suy luận là bằng chứng vận hành. Ưu tiên lưu nguồn đã đọc, điều kiện được kiểm, lý do quyết định ngắn, lời gọi và kết quả cần thiết. Nội dung lưu phải phù hợp mục đích, quyền truy cập và thời hạn giữ. Một lời giải thích nghe mạch lạc vẫn cần được đối chiếu với trạng thái hệ thống và căn cứ nghiệp vụ.

Tác tử nói đã xong nhưng công cụ báo chưa rõ thì tin đâu? Chưa chấp nhận kết luận hoàn thành. Dùng đường kiểm được phép để xác minh trạng thái thực tế, đồng thời tránh lặp thao tác có thể tạo thay đổi trùng. Nếu chưa xác minh được, bàn giao rõ phần không chắc chắn và người cần tiếp nhận. Lời tự báo của mô hình không thay biên nhận công cụ, phép đọc lại hoặc sự chấp nhận của người chịu trách nhiệm.

Nguồn, phương pháp và giới hạn suy luận

Bài có hỗ trợ AI từ tám nguồn gốc đã đọc ngày 27/10/2026, gồm nghiên cứu, tài liệu công cụ và hướng dẫn NIST. Quan điểm của nhà cung cấp được ghi rõ, không coi là kiểm chứng độc lập hay bảo chứng sản phẩm. Phiếu hành động, sổ tiến triển và ca mua sắm là tổng hợp biên tập giả định; chưa có thử thực địa, thẩm định chuyên gia hoặc kết luận pháp lý. Benchmark được dùng để giải thích cách kiểm, không chuyển điểm số sang dự báo hiệu quả tại Việt Nam.