Khi cả Anthropic cũng phải rút mạng khỏi eval: bài học về kiểm soát agent và độ tin cậy của benchmark

Một dấu hiệu đáng ngại về trạng thái hiện tại của AI agent: Anthropic công bố đã tắt truy cập Internet trực tiếp cho toàn bộ các đánh giá nội bộ (internal evals) cho đến khi có thông báo mới. Lý do nêu ra thẳng thắn đến mức hiếm thấy — công ty thừa nhận rằng họ không thể kiểm soát agent của chính mình một cách đáng tin cậy.

Anthropic cắt mạng khỏi eval: thừa nhận giới hạn kiểm soát

Theo TechCrunch, Anthropic đã "turned off live internet access" cho mọi internal evaluation. Đây không phải một tối ưu hiệu năng hay một tính năng mới — đó là một biện pháp phòng thủ, khi mà đường biên giới tin cậy nhất của bạn với một agent không kiểm soát nổi lại là mạng lan (air gap).

Xét ở góc độ kiến trúc, đây là lựa chọn kinh điển trong security engineering: khi bạn không thể đảm bảo độ tin cậy của lớp quyết định (agent), bạn siết khả năng tác động của nó lên thế giới thực (surface area). Nguyên tắc least privilege áp dụng không chỉ cho con người mà cả cho hệ thống tự trị. Việc Anthropic — một trong những lab đi đầu về an toàn AI — phải áp dụng biện pháp này với chính sản phẩm của họ, cho thấy khoảng cách giữa cam kết kiểm soát và thực tế vận hành agent vẫn còn lớn.

Giá trị thực tiễn cho developer: nếu bạn đang cho agent coding truy cập mạng nội bộ, API production hay CI/CD, hãy xem lại thiết kế. Mô hình đáng theo đuổi hiện nay là sandboxed agent: môi trường thực thi cô lập, mạng deny-by-default, mọi lượt ra ngoài phải qua proxy có log và whitelist. Đừng thiết kế hệ thống với giả định rằng agent sẽ làm đúng những gì được yêu cầu — thiết kế cho trường hợp nó làm điều khác.

Đưa benchmark lên Kaggle: bug đầu tiên tìm thấy là bug của chính mình

Bài viết trên DEV Community của Arjun Shah kể lại quá trình port cli-bench — một benchmark mã nguồn mở cho coding agent chạy trong terminal — lên nền tảng Kaggle Benchmarks, với 6 task được chuyển đổi.

Điểm đáng chú ý nhất không nằm ở kết quả benchmark, mà ở thiết kế verification. Mỗi task là một repository nhỏ với một bug cần sửa, một feature cần xây, hoặc một hàm cần tối ưu — kèm một verifier script quyết định pass/fail. Tác giả nói rõ: không có gì được chấm điểm bởi một model khác. Test pass thì pass, fail thì fail.

Tiêu đề bài viết — "những bug đầu tiên tôi tìm thấy là của chính mình" — lại là một minh họa trung thực cho quy luật mà ai từng xây benchmark đều biết: chạy hệ thống đánh giá của bạn trên hạ tầng mới, môi trường mới, và ngay lập tức bạn phát hiện lỗi trong chính benchmark trước cả lỗi của agent. Đây chính là lý do eval pipeline cần được kiểm thử như mọi hệ thống production khác.

Giá trị thực tiễn: nếu team bạn đang tự xây eval cho agent/tool nội bộ, hãy ưu tiên ba nguyên tắc: (1) verifier là code xác định, không phải LLM-as-judge — chấm điểm bằng model khác đưa vào nhiễu từ chính sự thiên lệch của model; (2) port eval sang ít nhất hai môi trường chạy khác nhau để phát hiện bug infra; (3) mỗi task nên có một phạm vi nhỏ, có thể xác minh độc lập. Nếu bạn định tham gia các cuộc thi benchmark như Kaggle Benchmarking Challenge, đây là một template kiến trúc đáng tham khảo trực tiếp từ repo mở của cli-bench.

System prompt của Claude Code: 1.044 token và câu hỏi về cấu hình rỗng

Bài thứ ba trên DEV Community của rulestack đào sâu vào hành vi của cấu hình keep-coding-instructions: true trong Claude Code 2.1.289 chạy Opus 5.5. Kết quả đo được rất cụ thể: cờ này quyết định việc một đoạn # Doing tasks nặng 1.044 token có nằm trong system prompt hay không — nhưng chỉ khi Claude Code gửi full prompt. Ở phiên bản prompt ngắn mà tài khoản đó nhận mặc định, một custom style có cờ và một style không có cờ tạo ra request giống hệt nhau.

Nghiêm trọng hơn về mặt kết luận thực nghiệm: trên một task sửa bug một dòng, 18/18 lần chạy trên ba style khác nhau đều đưa ra cùng một edit, không thêm comment, và đều kiểm tra kết quả sau khi sửa. Tác dụng chính quan sát được của custom style là... làm gấp đôi độ dài thông điệp kết thúc.

Đây là một phát hiện về kiến trúc prompt pipeline hơn là về chất lượng model: cùng một cờ cấu hình, hai đường dẫn prompt khác nhau, hai hành vi hoàn toàn khác. Người dùng tưởng mình đang cấu hình, thực tế cờ có thể không có tác dụng gì trên đường dẫn prompt mà tài khoản của mình đang dùng.

Giá trị thực tiễn: nếu bạn đang tùy biến output styles hay system prompt cho Claude Code trong workflow của team, đừng tin rằng cấu hình có hiệu lực — hãy xác minh bằng cách so sánh request thực tế gửi đi (như bài viết đã làm). Công việc đáng làm tiếp theo: đo token count của system prompt ở các chế độ prompt khác nhau, chạy cùng một task nhiều lần với A/B configuration, và ghi lại số lần chạy. Việc một thay đổi cấu hình không tác động đến 18/18 kết quả giống nhau là dấu hiệu bạn đang tối ưu phần không liên quan đến kết quả — token và effort nên chuyển sang nơi khác.

Nhận định kiến trúc

Ba mảnh tin này ghép lại thành một bức tranh nhất quán: hệ sinh thái agent đang ở giai đoạn mà cơ chế kiểm soát và đo lường quan trọng hơn năng lực model. Anthropic dùng air gap vì runtime control chưa đủ tin cậy; cli-bench chọn deterministic verifier vì model-judge không đủ tin cậy; thí nghiệm Claude Code cho thấy chính configuration layer của agent cũng cần được treat như hệ thống cần kiểm chứng, không phải thứ được tin theo mặc định.

Điều developer nên thử nghiệm tiếp theo: dựng một harness tối thiểu cho agent của mình — sandbox không mạng, verifier dạng script test, và instrumentation ghi lại toàn bộ request thực tế. Rủi ro cần phòng tránh là đo lường sai lớp: bạn tối ưu prompt và style trong khi biến số thật sự quyết định nằm ở đường dẫn hệ thống mà bạn không kiểm chứng được. Kiểm soát agent bắt đầu từ việc kiểm soát được chính hệ thống đo lường của bạn.

Nguồn tham khảo

• Anthropic can't reliably control its AI agents. It's cutting off its internal evals from the live internet instead
• I ported my coding-agent benchmark to Kaggle, and the first bugs I found were mine
• Claude Code's keep-coding-instructions kept 1,044 tokens in the full prompt, 0 in the short one, and 18 of 18 fixes matched