Vì sao bạn cần vòng lặp Claude Opus agent loop chủ động, không chỉ là chatbot
Vòng lặp Agent chủ động trên Claude Opus 5.5 là kiến trúc giúp mô hình tự thức dậy theo lịch, chỉ đọc phần dữ liệu đã thay đổi, tóm tắt thành thông tin cô đọng, quyết định xem có việc nào đáng cho con người xử lý hay không, đề xuất hành động cụ thể rồi dừng lại chờ phê duyệt, thay vì chỉ trả lời câu hỏi khi được gọi. Quan điểm thẳng thắn: nếu bạn vẫn dùng Claude Opus như một chatbot trả lời theo yêu cầu, bạn đang bỏ lỡ 80% giá trị của nó trong proactive agent automation. Điều khó chịu là phần thú vị của Claude Opus agent loop không nằm trong lời gọi mô hình, mà nằm ở kiến trúc xung quanh: lập lịch, tổng hợp, đề xuất có kiểu, cổng phê duyệt và bộ thực thi. Anthropic đã phát hành một phiên bản vòng lặp này dưới tên Claude Duet, nhưng không có API công khai và không thể trỏ sang hệ thống riêng của bạn, nên nếu bạn muốn vòng lặp chứ không phải ứng dụng, bạn buộc phải tự xây dựng. Năm giai đoạn chạy tuần tự, và giai đoạn cuối chỉ xảy ra sau khi con người đồng ý. Đây không phải bài toán kỹ thuật thuần túy; đây là bài toán thiết kế quyền lực giữa máy và người.
Giai đoạn 1: Bộ lập lịch – đừng biến agent thành máy đốt tiền
Bước đầu tiên của bất kỳ vòng lặp Claude Opus agent loop nào là bộ lập lịch kích hoạt vài giờ một lần, chứ không phải thăm dò liên tục. Sai lầm phổ biến nhất là lập trình agent kiểm tra mọi nguồn dữ liệu mỗi phút vì… thấy ngầu. Kết quả là bạn trả chi phí ngữ cảnh đầy đủ hàng nghìn lần mỗi ngày để nhận câu trả lời “không có gì mới”. Tài liệu Claude Duet giải thích rõ: kiểm tra không ngừng sẽ ăn hết hạn mức gói nhanh hơn rất nhiều, và đó là câu trả lời đúng cho bài toán chi phí, không phải lời khuyên marketing. Về mặt kiến trúc, mỗi lượt quét là một ngữ cảnh đầy đủ: hướng dẫn, định nghĩa công cụ, tài liệu đã kéo vào và mọi lập luận mô hình thực hiện trên đó. Với nhịp một phút, bạn có 1.440 ngữ cảnh mỗi ngày; với nhịp ba giờ, bạn chỉ có tám, và tỷ lệ giữa phát hiện và chi phí trở nên có thể biện hộ với người ký hóa đơn. Vì vậy, bộ lập lịch nên là một bộ hẹn giờ kiểu cron với mức sàn cho khoảng thời gian tối thiểu, chứ không phải một luồng sự kiện. Sự kiện nghe hấp dẫn vì phản ứng ngay khi có việc xảy ra, nhưng chúng kéo bạn trở lại với công việc liên tục và khiến chi phí của một ngày bận rộn không còn trần trên. Quan điểm rõ ràng: nếu bạn không dám đặt trần chi phí bằng cron, bạn chưa sẵn sàng cho proactive agent automation.
Giai đoạn 2–3: cached prompt optimization và tổng hợp delta – tối ưu chi phí, không tối ưu độ hoành tráng
Ở giai đoạn hai, bạn phải chấp nhận một sự thật: mọi byte ổn định trong prompt là một byte bạn không phải trả giá đầy đủ cho nó nữa. System prompt và tool schema cần được lắp ráp một lần tại thời điểm triển khai và không bao giờ được tạo lại cho mỗi lần quét. Điều này là cốt lõi của cached prompt optimization: tiền tố gửi vào Claude Opus 5.5 phải giống hệt từng byte giữa các lượt quét, để có thể đọc từ bộ nhớ đệm với chi phí thấp hơn nhiều so với token đầu vào mới. Sai lầm thứ hai mà các nhóm thường mắc phải là để một lớp trừu tượng “tiện lợi” tự động chèn mã định danh lần chạy, dấu thời gian hoặc danh sách tài khoản kết nối vào phần đầu prompt, phá vỡ tính ổn định từng byte. Kết quả: bạn tưởng mình đang tối ưu cached prompt, nhưng hệ thống lại trả chi phí ngữ cảnh đầy đủ mỗi lần. Giai đoạn ba là bước tổng hợp: mỗi hệ thống được kết nối (email, CRM, kho mã…) phải được rút gọn thành một delta – phần thay đổi kể từ lần quét trước. Đây là nơi Claude Opus 5.5 bắt đầu thể hiện sức mạnh proactive agent automation: nó không đọc lại toàn bộ thế giới, mà chỉ đọc những gì mới, rồi tóm tắt thành digest có cấu trúc để chuẩn bị cho quyết định.
Giai đoạn 4: typed proposal structure – buộc agent nói bằng đối tượng, không bằng văn xuôi
Nếu bạn để Claude Opus 5.5 trả về văn bản tự do, bạn đang tự phá hỏng approval gate workflow của mình. Giai đoạn bốn yêu cầu một bước quyết định xuất ra một đối tượng, không phải văn xuôi. Bước quyết định phải trả về một đề xuất hành động có kiểu: tên hành động từ một danh sách đóng, mục tiêu mà nó áp dụng, các tham số, lý do một dòng và cờ độ tin cậy hoặc leo thang rõ ràng. Danh sách hành động đóng không phải quan liêu; đó là cơ chế khiến cổng phê duyệt có thể thực thi được, vì một cổng chỉ có thể xác thực những hành động mà nó có thể liệt kê. Khi đề xuất là một đối tượng typed proposal structure, bạn có thể định tuyến nó đến các cổng khác nhau: phê duyệt của quản lý, phê duyệt bảo mật, hay tự động chấp nhận cho các hành động rủi ro thấp. Một lỗi văn hóa thường gặp là coi sự im lặng là thất bại: các vòng lặp như vậy sẽ tạo ra khối lượng công việc giả để trông có ích. Một agent tự tạo việc còn tệ hơn một agent báo cáo rằng không có gì thay đổi. Quan điểm thẳng: nếu bạn không chấp nhận "không có hành động" là kết quả hợp lệ, bạn sẽ biến typed proposals thành spam có cấu trúc.
Giai đoạn 5: approval gate workflow và bộ thực thi – giữ quyền lực cuối cùng cho con người
Giai đoạn năm là nơi bạn quyết định liệu Claude Opus agent loop là công cụ hỗ trợ hay là nguồn rủi ro: một cổng phê duyệt thực sự có thể nói không. Cổng phải là một dịch vụ riêng, không phải một nhánh bên trong mã của chính agent; đây là quyết định cấu trúc quan trọng nhất khi xây dựng. Một cổng chỉ ghi một dòng vào nhật ký không ai đọc thì không phải cổng, đó chỉ là biên lai. Cổng kiểm soát bảo vệ chống lại sai sót, trong khi danh sách cấm bảo vệ chống lại một người vận hành đã bị xâm phạm, kể cả người vận hành là con người. Nếu bộ thực thi chỉ chấp nhận một đề xuất đã được cổng ký, thì điều tệ nhất agent có thể làm là đề xuất một điều gì đó sai, và sự từ chối của cổng có hiệu lực thực tế. Dưới năm giai đoạn này còn hai vấn đề nan giải: bộ nhớ, thông tin xác thực và hai bề mặt mà bạn không thể né bằng kiểm thử. Nhưng điểm mấu chốt vẫn rõ ràng: khi vòng lặp kết thúc, bạn có một hệ thống proactive agent automation biết tự theo dõi, tóm tắt và đề xuất hành động, trong khi quyền thực thi cuối cùng vẫn nằm trong tay con người. Nếu bạn không thiết kế cổng phê duyệt như một dịch vụ độc lập, bạn đang trao quyền quá mức cho mô hình mà không có phanh.
