Khung tác tử là gì? Nghiên cứu, dự án mã nguồn mở và thực tiễn trong ngành

Hai tác tử có thể dùng chính xác cùng một mô hình nhưng đạt điểm rất khác nhau trên cùng một benchmark. OpenAI đã đo lường điều này trực tiếp: trên SWE-bench Lite, GPT-4 đạt 2,7% với một khung tác tử và 28,3% với khung khác — chênh lệch gấp 10 lần hoàn toàn do khung tác tử tạo ra. Khi ngành chuyển từ câu hỏi "mô hình nào thông minh nhất" sang "tác tử nào thực sự hoàn thành công việc", khung tác tử đã trở thành lớp quyết định độ tin cậy. Hãy đọc tiếp để tìm hiểu khung tác tử là gì, các bài báo và benchmark mới nhất nói gì về thiết kế khung tác tử, những khung mã nguồn mở nào đáng để bạn đầu tư thời gian, và cách các phòng thí nghiệm AI lớn tự xây dựng khung của họ — bao gồm Kimi K3.1 Pro, mô hình trọng số mở mà Moonshot AI kết hợp với các khung tác tử riêng.

Khung tác tử là hạ tầng bao quanh, cho phép một mô hình ngôn ngữ lớn hoạt động như tác tử trong môi trường thực. Trong khi mô hình tạo ra token, khung tác tử đảm nhiệm mọi việc còn lại: xây dựng prompt ở mỗi bước, xác định các công cụ hiện có và cách gọi chúng, thực thi hành động trong sandbox hoặc terminal, đưa các quan sát trở lại cho mô hình, áp đặt giới hạn bước và chi phí, đồng thời ghi nhật ký toàn bộ quỹ đạo để đánh giá hoặc gỡ lỗi.

Thuật ngữ này xuất phát từ lĩnh vực đánh giá — một "test harness" là bộ khung dùng để vận hành một hệ thống trong các điều kiện được kiểm soát. Trong AI tác tử, ý tưởng này được mở rộng sang môi trường vận hành thực tế: khung tác tử vừa là bộ khung dùng để đo lường một tác tử (như trong SWE-bench hoặc Terminal-Bench), vừa là khung dùng để chạy một tác tử (như trong SWE-agent, OpenHands hoặc Claude Code).

Nghiên cứu SWE-bench của chính Anthropic diễn đạt rõ ràng: benchmark "không chỉ đánh giá riêng lẻ mô hình AI, mà đánh giá cả một hệ thống 'tác tử' hoàn chỉnh", trong đó tác tử là "sự kết hợp giữa một mô hình AI và lớp khung phần mềm bao quanh nó". Claude 3.5 Sonnet được nâng cấp của họ đạt 49% trên SWE-bench Verified không nhờ một framework phức tạp, mà nhờ một khung tối giản gồm một prompt và hai công cụ đa dụng (công cụ Bash và công cụ Edit).

Trong nhiều năm, mức tăng trên bảng xếp hạng được quy cho quy mô mô hình. Các nghiên cứu gần đây đã phá vỡ giả định đó theo hai hướng.

Đầu tiên là kết quả "ít hơn lại hiệu quả hơn": vào tháng 7 năm 2025, nhóm SWE-bench phát hành mini-SWE-agent, một khung gồm khoảng 100 dòng Python, không có công cụ nào ngoài bash, lịch sử tin nhắn hoàn toàn tuyến tính và mọi hành động đều được thực thi dưới dạng lệnh gọi subprocess.run độc lập. Nó đạt điểm benchmark cạnh tranh với các framework phức tạp hơn nhiều (được trình bày trong phần nghiên cứu bên dưới). Bài học khá đáng chú ý: khi mô hình đủ mạnh, một khung cực kỳ đơn giản, dễ dự đoán có thể vượt qua một khung nặng nề. Nó đã được Meta, NVIDIA, IBM, Princeton và Stanford sử dụng làm mốc cơ sở.

Thứ hai là kết quả "càng nhiều càng ít": một bộ khung vận hành kém — đầu ra công cụ nhiễu, vòng lặp không giới hạn, khôi phục lỗi kém — có thể khiến một mô hình tiên tiến trông chỉ ở mức tầm thường. OpenAI nhận thấy rằng việc làm sạch các tác vụ lỗi của SWE-bench (được trình bày chi tiết trong phần OpenAI bên dưới) đã tăng hơn gấp đôi hiệu năng đo được của mô hình.

Đó là lý do kỹ thuật xây dựng bộ khung vận hành đã trở thành một lĩnh vực riêng. Bộ khung này quyết định:

• Những gì mô hình nhìn thấy: cấu trúc prompt, lược đồ công cụ, lượng trạng thái môi trường và lịch sử được đưa vào cửa sổ ngữ cảnh.

• Những gì mô hình có thể làm: những công cụ sẵn có (shell, trình sửa tệp, trình duyệt, tìm kiếm), cũng như cách các hành động được phân tích và xác thực trước khi thực thi.

• Cách xử lý thất bại: thử lại, thời gian chờ, nén ngữ cảnh khi cửa sổ đầy và kết thúc một cách ổn thỏa.

• Cách đo lường công việc: ghi nhật ký quỹ đạo, chấm điểm và hạch toán chi phí — thiếu những điều này thì không thể đánh giá hay tạo vòng lặp cải tiến.

Dù là thiết lập benchmark phục vụ nghiên cứu hay trợ lý lập trình dùng trong môi trường thực tế, gần như mọi bộ khung vận hành tác tử đều triển khai cùng một vòng lặp cốt lõi:

1. Tiếp nhận tác vụ: đọc issue, chỉ dẫn hoặc mục tiêu, rồi khởi tạo một môi trường cô lập (thường là vùng chứa Docker hoặc ảnh chụp nhanh VM).

2. Tập hợp prompt: kết hợp prompt hệ thống, định nghĩa công cụ, mô tả tác vụ cùng lịch sử liên tục của các hành động và quan sát.

3. Phân tích hành động: chuyển đầu ra của mô hình thành một lệnh gọi công cụ cụ thể — một lệnh bash, một chỉnh sửa tệp, một yêu cầu API — và từ chối các hành động sai định dạng.

4. Thực thi và quan sát: chạy hành động trong môi trường, thu thập stdout/stderr hoặc trạng thái UI, rồi cắt bớt để vừa với ngân sách ngữ cảnh.

5. Luồng điều khiển: áp dụng giới hạn số bước, giới hạn chi phí và điều kiện dừng; quyết định khi nào cần hỏi con người hoặc kết thúc phiên xử lý.

6. Ghi nhận và chấm điểm: lưu toàn bộ quỹ đạo và đánh giá trạng thái cuối cùng — chẳng hạn bằng cách chạy bộ kiểm thử của kho mã trong SWE-bench.

Các lựa chọn thiết kế ở từng bước sẽ cộng dồn tác động. Chỉ riêng chiến lược cắt bớt cũng có thể làm điểm số chênh lệch đáng kể ở các tác vụ dài hạn, vì vậy các nhóm nghiêm túc coi bộ khung này là phần mềm có phiên bản và có thể kiểm thử, thay vì mã kết dính.

Tài liệu học thuật về bộ khung vận hành tác tử đã quy tụ quanh một số ít kết luận khó đạt được. Thay vì liệt kê mọi benchmark, phần này lần theo những câu hỏi nghiên cứu đã buộc lĩnh vực phải xem trọng bộ khung vận hành.

Trước khi đi vào các bài báo, hãy điểm qua khái niệm cơ bản. Benchmark là một tập tác vụ cố định kèm quy tắc chấm điểm, được thiết kế để so sánh các hệ thống khác nhau trên cùng một mặt bằng. Trong đánh giá tác tử, một benchmark có ba thành phần biến đổi: một tập tác vụ (issue GitHub thực tế, lệnh terminal, tác vụ web), một môi trường thực thi (vùng chứa Docker, trình duyệt, terminal) và một bộ chấm (bộ kiểm thử, kiểm tra trạng thái, đánh giá của con người). Bộ khung vận hành nằm giữa mô hình và cả ba thành phần này — đó là biến số quyết định liệu năng lực của mô hình có thể hiện trong điểm số hay không.

Cách đo điểm thực tế quan trọng hơn con số nổi bật. Trong SWE-bench, một tác tử tạo ra bản vá mã; benchmark sau đó chạy hai bộ kiểm thử: FAIL_TO_PASS (các kiểm thử đã lỗi trước khi sửa và giờ phải chạy qua) và PASS_TO_PASS (các kiểm thử đã hoạt động trước đó và không được lỗi). Chỉ khi cả hai đều chạy qua, tác vụ mới được tính là đã giải quyết. Vì vậy, các tính năng của bộ khung vận hành như chạy kiểm thử và tạo diff không phải phần bổ sung tùy chọn — đó là nơi điểm số được hoặc mất.

Ba quy tắc để đọc bất kỳ điểm benchmark nào:

1. Hãy hỏi điểm số che giấu điều gì. Một mô hình được huấn luyện trên dữ liệu GitHub công khai có thể đã thấy chính những issue mà nó đang được kiểm tra — ô nhiễm dữ liệu có thể làm tăng điểm mà không hề mang lại năng lực thực sự. Môi trường có thể tái lập và tập tác vụ được giữ lại để kiểm tra là giải pháp khắc phục.

2. Cẩn trọng với định luật Goodhart: khi một thước đo trở thành mục tiêu, nó không còn là thước đo tốt. Một bộ khung vận hành được tinh chỉnh để đạt điểm cao ở một benchmark có thể đang học các mẹo riêng của benchmark thay vì năng lực tổng quát — đó là lý do các nhóm nghiêm túc đánh giá trên nhiều benchmark.

3. Kiểm tra bộ khung vận hành, không chỉ mô hình. Như phần còn lại sẽ cho thấy, cùng một mô hình có thể đạt 2,7% hoặc 28,3% tùy vào khung hỗ trợ. Điểm số không nêu tên bộ khung vận hành chỉ là giai thoại, không phải phép đo.

Bài báo SWE-bench đầu tiên ("Liệu mô hình ngôn ngữ có thể giải quyết các issue GitHub trong thực tế?") đã giới thiệu cách đánh giá nay đã trở thành chuẩn mực: cung cấp cho mô hình một issue GitHub thực tế và toàn bộ kho mã, rồi chấm xem bản vá của nó có làm các kiểm thử lỗi chạy qua hay không. Kết quả được trích dẫn nhiều nhất của bài báo này thường bị hiểu sai: mô hình tốt nhất vào thời điểm đó, Claude 2, chỉ giải quyết được 1,96% tác vụ. Cách các tác giả diễn giải là benchmark này kiểm tra "lập luận phức tạp vượt xa việc sinh mã truyền thống" — nhưng các công trình tiếp theo cho thấy phần lớn khoảng cách không nằm ở năng lực lập luận mà ở sự thiếu vắng một bộ khung vận hành có thể điều hướng kho mã, chạy kiểm thử và lặp lại. Nói cách khác, SWE-bench không chỉ đo lường mô hình; nó còn cho thấy bộ khung vận hành xung quanh mô hình là mảnh ghép còn thiếu.

Bài báo SWE-agent ("Giao diện Tác tử-Máy tính cho phép tự động hóa kỹ thuật phần mềm") là tài liệu nền tảng của lĩnh vực về thiết kế bộ khung vận hành. Luận điểm cốt lõi là thiết kế giao diện là biến số bậc một: các tác giả đưa ra thuật ngữ Giao diện Tác tử-Máy tính (ACI) và chỉ ra rằng một giao diện được thiết kế chuyên biệt — trình sửa tệp có linter bảo vệ, phản hồi shell súc tích, các cơ chế bảo vệ trước lệnh sai định dạng — đã nâng pass@1 trên SWE-bench từ mức một chữ số thấp lên 12,5%, mức cao nhất vào thời điểm đó. Đóng góp lâu dài của bài báo là lập luận rằng "các tác tử LM là một nhóm người dùng cuối mới", cần phần mềm được xây dựng riêng cho mình, cũng như con người cần IDE. Mọi bài báo về bộ khung vận hành sau đó đều trích dẫn kết quả này.

Hai bài báo năm 2024 đã mở rộng nghiên cứu về bộ khung vận hành từ kho mã sang toàn bộ máy tính. OSWorld xây dựng môi trường máy tính thực đầu tiên có thể mở rộng trên Ubuntu, Windows và macOS, với 369 tác vụ trải rộng trên ứng dụng web và máy tính để bàn. Con số nổi bật của nghiên cứu — con người hoàn thành 72,36% tác vụ, mô hình tốt nhất đạt 12,24% — xác định neo bám GUI (chuyển đầu ra mô hình thành các thao tác nhấp chuột và gõ phím chính xác) là chế độ thất bại chủ đạo, một vấn đề của bộ khung vận hành chứ không phải vấn đề kiến thức. WebArena tiếp cận theo hướng khác: một môi trường web tự lưu trữ, có thể tái lập hoàn toàn (thương mại điện tử, diễn đàn, GitLab, CMS), nơi GPT-4 chỉ đạt 14,41% thành công từ đầu đến cuối, so với 78,24% ở con người. Cả hai bài báo đều xác lập rằng đánh giá bộ khung vận hành phải dựa trên thực thi (kiểm tra trạng thái cuối cùng của môi trường), thay vì đối sánh mẫu với đầu ra mô hình.

τ-bench của Sierra ("Một chuẩn đánh giá tương tác giữa công cụ, tác tử và người dùng trong các lĩnh vực thực tế") nêu ra một điểm tinh tế hơn: trong môi trường production, harness không chỉ bao bọc mô hình và môi trường — mà còn điều phối cả người dùng. Chuẩn đánh giá này mô phỏng các cuộc trò chuyện động giữa một người dùng mô hình ngôn ngữ và một tác tử có API theo miền cùng các hướng dẫn chính sách, rồi chấm điểm trạng thái cuối cùng của cơ sở dữ liệu. Chỉ số chính của nó, pass^k (thành công qua k lần thử độc lập), cho thấy các tác tử thiếu nhất quán đến mức nào: GPT-4o giải được chưa đến 50% số tác vụ trong một lần thử, còn pass^8 giảm xuống dưới 25% trong lĩnh vực bán lẻ. Bài học dành cho người xây dựng harness là độ tin cậy là một thuộc tính của phân phối, không phải thuộc tính của một lần chạy đơn lẻ — một harness chỉ hoạt động được một lần thì không phải là harness hoạt động được.

"Đo lường khả năng của AI trong việc hoàn thành các tác vụ phần mềm dài" của METR đã đưa ra khái niệm thời hạn hoàn thành tác vụ ở mức 50%: độ dài tác vụ (đo bằng thời gian con người hoàn thành) mà mô hình hoàn tất với độ tin cậy 50%. Các mô hình tiên phong đã tăng từ vài phút lên xấp xỉ một giờ trong giai đoạn 2019–2025, gần như tăng gấp đôi sau mỗi bảy tháng. Với kỹ thuật harness, đây là phát hiện hệ quả nhất của thập kỷ: harness kìm hãm một mô hình năm 2024 sẽ trở thành gánh nặng vô ích đối với mô hình năm 2026. Theo cách diễn giải của Anthropic, mọi thành phần trong harness đều mã hóa một giả định về những gì mô hình không thể làm — và các giả định đó nhanh chóng lỗi thời khi mô hình được cải thiện.

Chuẩn đánh giá ban đầu đã phát triển thành một hệ sinh thái hiện thực hóa các bài học này:

• SWE-bench Verified (cùng OpenAI, 2024): tập con 500 mẫu do con người sàng lọc, loại bỏ các tác vụ thiếu đặc tả hoặc bị chấm điểm không công bằng — 68,3% tập ban đầu đã bị loại, khiến điểm số đo được tăng hơn gấp đôi và trở thành bảng xếp hạng mặc định.

• SWE-smith (2025): một pipeline tạo tác vụ huấn luyện tổng hợp để mô hình có thể được huấn luyện cho các harness tác tử, thay vì chỉ được đánh giá trên chúng.

• mini-SWE-agent (2025): harness khoảng 100 dòng hiện đạt trên 74% trên SWE-bench Verified, cho thấy một vòng lặp tối giản chỉ dùng bash với lịch sử tuyến tính là đủ khi mô hình đủ mạnh — đồng thời trở thành mốc cơ sở mặc định của cộng đồng.

• Terminal-Bench (Stanford × Laude, 2025): đánh giá tác vụ terminal dựa trên framework Harbor, đưa harness vượt ra ngoài việc chỉnh sửa mã để tiến sang quản trị hệ thống.

• CodeClash (2025) và ProgramBench (2026): tạo phần mềm hướng mục tiêu và từ đầu, mở rộng harness từ các bản sửa lỗi đơn lẻ sang phát triển mở.

Xuyên suốt mọi nghiên cứu này là một thông điệp nhất quán: harness không phải hạ tầng phụ trợ, mà là đối tượng nghiên cứu. Hãy báo cáo harness cùng với điểm số, duy trì môi trường có thể tái lập và nghi ngờ mọi kết quả có harness không thể kiểm tra.

Harness mã nguồn mở là nơi hầu hết các nhóm bắt đầu. Những dự án dưới đây kết hợp cộng đồng GitHub lớn (các dự án dẫn đầu có hàng chục nghìn sao) với hoạt động bảo trì tích cực:

Khi lựa chọn giữa các khung này, kinh nghiệm chung của cộng đồng là: dùng khung tối giản nhất có thể biểu đạt tác vụ của bạn (triết lý mini-SWE-agent), và chỉ tăng độ phức tạp khi một lỗi đã được đo lường đòi hỏi điều đó. DeepSeek Harness nằm ở đầu đối diện của phổ này — một nền tảng hoàn toàn dựa trên plugin dành cho các nhóm muốn mọi lớp đều có thể thay thế — nhưng cả hai cùng tuân theo một nguyên tắc: nhật ký phiên bền vững, chỉ ghi thêm là nguồn sự thật duy nhất về những gì mô hình đã thấy.

Các phòng thí nghiệm tiên phong coi kỹ thuật khung vận hành là tài sản trí tuệ cốt lõi, và một số đã công bố tư duy của họ với mức độ chi tiết hiếm thấy.

Anthropic đã công bố tư liệu công khai đầy đủ nhất về kỹ thuật khung vận hành, và kiến trúc của họ — được trình bày chi tiết trong Building Effective Agents (2024), bài viết về khung SWE-bench (2024), và Managed Agents (2026) — có thể được hiểu như ba lớp đồng tâm.

Lớp thực thi được cố ý giữ ở mức tối giản: một công cụ Bash để chạy lệnh và một công cụ Edit để xem, sửa đổi tệp. Nỗ lực thiết kế tập trung vào việc khiến các công cụ này khó phát sinh lỗi — yêu cầu đường dẫn tuyệt đối, cắt ngắn đầu ra dài và chỉ áp dụng chỉnh sửa khi có một chuỗi khớp duy nhất — để mô hình hiếm khi phải khắc phục những lỗi công cụ có thể tránh được.

Lớp phiên là nhật ký sự kiện bền vững, chỉ ghi thêm, tồn tại bên ngoài cửa sổ ngữ cảnh của mô hình. Mọi hành động và quan sát đều được ghi lại ở đó; ngữ cảnh của mô hình là hình chiếu của nhật ký này, chứ không phải chính nhật ký. Sự tách biệt này cho phép một tiến trình khung vận hành bị lỗi được khởi động lại và tiếp tục giữa chừng tác vụ, đồng thời khiến khung vận hành trở thành "gia súc" có thể thay thế thay vì thú cưng.

Lớp điều phối — thứ Anthropic gọi là "siêu khung vận hành" — tách rời "bộ não" (mô hình và vòng lặp của nó) khỏi "đôi tay" (sandbox và công cụ) thông qua các giao diện tường minh. Vì bộ não không còn nằm trong vùng chứa thực thi, sandbox có thể được cấp phát theo nhu cầu và thông tin xác thực có thể được lưu trong kho bí mật mà sandbox không bao giờ chạm tới. Lợi ích mà họ báo cáo mang tính cấu trúc, không chỉ là bề ngoài: thời gian p50 đến token đầu tiên giảm khoảng 60% và p95 giảm hơn 90%, vì các phiên không còn phải chờ những vùng chứa mà chúng có thể không bao giờ dùng đến.

Ba tài liệu ghi lại quá trình phát triển này: Building Effective Agents (2024), bài viết về khung SWE-bench (2024) và Managed Agents (2026).

OpenAI hợp tác với nhóm SWE-bench để tạo ra phân tách Verified được con người xác thực, chính vì các khung vận hành cần những tác vụ sạch: chiến dịch chú giải của họ (93 lập trình viên, 1.699 mẫu) phát hiện 68,3% tác vụ trong benchmark gốc có vấn đề, và việc loại bỏ chúng đã giúp hiệu năng đo được tăng hơn gấp đôi. Bài viết này cũng lưu ý rằng chỉ riêng lựa chọn khung vận hành đã đưa GPT-4 từ 2,7% lên 28,3% trên SWE-bench Lite — một chênh lệch mà họ viện dẫn để lập luận rằng các đánh giá phải tính đến tiến bộ trong những khung vận hành do cộng đồng xây dựng.

Ở phía mã nguồn mở, Codex CLI được phát hành như một khung tham chiếu hoàn chỉnh. Kiến trúc của nó được phân lớp theo cách phản chiếu các hệ thống khác trong phần này: một vòng lặp tác tử cốt lõi xử lý việc lập kế hoạch và gọi công cụ; một lớp sandbox cô lập việc thực thi bằng chính sách có thể cấu hình theo từng tác vụ; một lớp phiên duy trì hội thoại để có thể tiếp tục, phân nhánh hoặc cô đọng; và một lớp công cụ cung cấp cả quyền truy cập shell cục bộ lẫn các công cụ bên ngoài dựa trên MCP. Thay vì cố định một giao diện duy nhất, cùng một động cơ được cung cấp qua ba bề mặt — giao diện terminal cho công việc tương tác, máy chủ ứng dụng JSON-RPC cho các ứng dụng khách phong phú như VS Code, và dịch vụ thực thi mã từ xa cho sandbox trên đám mây — để khung vận hành có thể chạy cục bộ hoặc được điều khiển bằng lập trình. Thiết kế này đưa ra những đánh đổi giống như tài liệu nghiên cứu khuyến nghị: vòng lặp tối giản, sandbox mạnh, quản lý ngữ cảnh tường minh và ranh giới rõ ràng giữa mô hình với thế giới bên ngoài.

Với Agent Development Kit (ADK) và giao thức Agent2Agent (A2A) — ra mắt vào tháng 4 năm 2025 cùng hơn 50 đối tác công nghệ, gồm Atlassian, Salesforce, SAP và ServiceNow — Google đang sản phẩm hóa lớp harness. A2A chuẩn hóa cách các tác tử công bố năng lực (qua các "Agent Card" JSON), quản lý tác vụ chạy dài, trao đổi tạo phẩm và thương lượng định dạng UI, để harness trở thành hạ tầng có khả năng tương tác thay vì phần kết nối chắp vá riêng lẻ. Nó được thiết kế rõ ràng để bổ sung cho Model Context Protocol (MCP) của Anthropic, vốn chuẩn hóa phía công cụ của harness.

AutoGen và Magentic-One của Microsoft cung cấp các harness trong đó một tác tử điều phối quản lý sổ theo dõi các dữ kiện và tiến độ — một thiết kế đã được công bố nhằm ngăn các vòng lặp vô hạn thường gặp ở những harness đơn giản. GAIA của Meta và Hugging Face tạo ra một benchmark trợ lý tổng quát, với harness chấm điểm các câu hỏi thực tế đòi hỏi điều hướng web và xử lý tệp; Open Agent Leaderboard của Hugging Face tiếp tục thúc đẩy các bảng xếp hạng có thể so sánh, có xét đến harness.

DeepSeek Harness (dsh) phát triển ý tưởng meta-harness theo hướng có thể kết hợp linh hoạt. Kiến trúc của nó được xây dựng trên framework Cordis, với luận điểm cốt lõi là mọi bộ phận của harness đều là plugin có thể thay thế — bao gồm adapter mô hình, sổ đăng ký công cụ, nhật ký phiên và cả vòng lặp tác tử.

Thiết kế này dựa trên ba thành phần nền tảng. Thứ nhất, nhật ký phiên bền vững là nguồn dữ liệu duy nhất về những gì mô hình đã thấy; mọi thứ đến được mô hình đều phải có thể tái dựng từ nhật ký, và điều này được áp đặt như một bất biến khi chạy. Thứ hai, điểm nối năng lực: một giao diện nhà cung cấp có thể hoán đổi giữa tác tử và thế giới bên ngoài, để khi trỏ nhà cung cấp hệ thống tệp và tiến trình con vào một sandbox từ xa thì quyền truy cập Bash, terminal và language server cũng được chuyển theo, mà không cần phân nhánh harness. Thứ ba, một vòng đời lượt/bước tường minh với các sự kiện mở rộng có tên (agent/pre-step, tools/execute, agent/turn-stopping), cho phép plugin chặn hoặc viết lại vòng lặp mà không sửa mã lõi.

Kết quả là hiện thực mã nguồn mở gần nhất với meta-harness của Anthropic: một harness mà cấu trúc không phải framework cố định, mà là tổ hợp các plugin có thể hoán đổi bằng cấu hình. Với hơn 170 nghìn sao GitHub chỉ trong những tháng đầu, nó cho thấy agent harness đang trở thành một danh mục sản phẩm độc lập.

Mẫu số chung của tất cả: giữ vòng lặp đơn giản, cô lập mọi thứ trong sandbox, ghi nhật ký từng bước, và đừng bao giờ tin vào một điểm số nếu không có harness tạo ra nó.

Mọi thứ trong phần này đến nay — các vòng lặp tối giản, nhật ký phiên bền vững, thực thi trong sandbox, kiến trúc plugin — đều có chung một giả định: môi trường của tác tử là một máy tính. Một terminal, trình duyệt, hệ thống tệp, kho mã. Harness tồn tại để tác tử có thể vận hành chiếc máy đó một cách đáng tin cậy.

Nhưng hướng nghiên cứu được phác họa ở trên lại chỉ đến một nơi khác. τ-bench đưa người dùng vào bên trong harness. METR cho thấy các tác tử đảm nhận công việc kéo dài nhiều ngày thay vì vài phút. OSWorld và WebArena chuyển môi trường từ một kho mã sạch sẽ sang thế giới thực đầy lộn xộn. Xu hướng nhất quán: khi tác tử chuyển từ công cụ lập trình thành trợ lý thực sự cho công việc, môi trường chúng phải điều hướng không còn chỉ là silicon — mà là con người. Người dùng có kỳ vọng, nhóm có lịch sử, tổ chức có quyền hạn và tri thức thể chế.

Sự chuyển dịch đó tác động đến một phân hệ harness hơn bất kỳ phân hệ nào khác: quản lý ngữ cảnh. Một phiên terminal có một người vận hành và lịch sử hữu hạn; một đợt hợp tác dài hạn có mười bên liên quan, nhiều tháng quyết định và một kho mã không ngừng phát triển. Hệ thống tệp là thụ động; quan hệ cộng tác là dòng chảy của các cam kết ngầm, suy nghĩ còn dang dở và những lựa chọn được đưa ra tình cờ. Tất cả đều phải được tóm tắt, nén gọn hoặc loại bỏ trước khi đến mô hình, và mỗi quyết định như vậy đều là nơi tác tử đánh mất điều mà tác vụ cần.

Harness có thể nén, nhưng không thể nén tùy ý. Đó là lý do kích thước cửa sổ ngữ cảnh không còn chỉ là thông số kỹ thuật của mô hình mà đã trở thành tham số thiết kế của harness.

Danh mục harness của Moonshot AI ánh xạ cấu trúc đã xác định trước đó trong bài viết này vào một ngăn xếp được quản lý. Với bài toán Tác tử × Máy tính, các harness của hãng mở rộng vòng lặp tiêu chuẩn: Kimi Browser Extension điều khiển một phiên trình duyệt thực qua Chrome DevTools Protocol thay vì sandbox vô trùng, điểm nối Hỏi trước khi hành động đảm bảo sự đồng ý ở cấp hệ thống tệp, và Agent Swarm mở rộng điều phối lên 300 tác tử con cho các tác vụ dài hạn.

Vận hành vòng lặp đó là Kimi K3.1 Pro — mô hình đầu tiên trong dòng K3.1 và là mô hình trọng số mở thuộc lớp 3T mạnh nhất của Moonshot AI cho đến nay, với cửa sổ ngữ cảnh 1.048.576 token. Ba đặc tính của nó liên quan trực tiếp đến thiết kế harness:

• Cửa sổ đủ lớn để trì hoãn việc nén gọn. Một triệu token có thể chứa đồng thời một kho mã đang làm việc, quỹ đạo đang chạy và các tài liệu tham chiếu. Harness vẫn phải cắt bớt — luôn là vậy — nhưng ngưỡng mà việc tóm tắt bắt đầu làm mất thông tin được đẩy ra đủ xa để các tác vụ dài hạn không còn âm thầm suy giảm giữa chừng.

• Mức độ suy luận là một nút điều chỉnh của harness. K3.1 Pro luôn suy luận, và reasoning_effort nhận low, high hoặc max, trong đó max là mặc định. Điều này biến chi phí suy luận của mô hình thành ngân sách theo từng tác vụ do harness đặt ra, thay vì một mức phí cố định để bắt đầu.

• Công cụ xuất hiện giữa phiên. Tải công cụ động cho phép harness chèn một định nghĩa công cụ hoàn chỉnh vào trong thông điệp hệ thống, nhờ đó công cụ khả dụng từ thông điệp đó trở đi — không cần khởi động lại và không phải trả chi phí cho schema của nó ở mọi lượt trong một cuộc trò chuyện không bao giờ dùng đến nó.

Moonshot báo cáo cả harness cùng với mô hình, đúng theo nguyên tắc mà phần còn lại của bài viết này lập luận. Trên Terminal-Bench 4.0 — benchmark chấm điểm các tác tử lập trình qua những tác vụ terminal thực tế, bị giới hạn tài nguyên và có kiểm thử nghiêm ngặt theo từng tác vụ — K3.1 Pro đạt 65,7%, vượt GPT-6 Astra (58,2%) và chỉ đứng sau Claude Opus 5.5 (66,4%). Trên Kimi Code Bench 3.0 Long-horizon, benchmark nội bộ dành cho thực thi nhiều bước, sử dụng công cụ và giải quyết vấn đề đầu cuối, mô hình đạt 61,2% so với 55,95% của K3. Tài liệu cũng nêu rõ chiều phụ thuộc ngược lại: các tham số lấy mẫu như temperature và top_p được cố định, phải bỏ khỏi yêu cầu; đồng thời, thông điệp trợ lý hoàn chỉnh phải được trả về nguyên vẹn qua các lượt — harness viết lại thông điệp sẽ làm mất phần suy luận mà lần gọi công cụ tiếp theo phụ thuộc vào.

Cùng một mô hình vận hành toàn bộ bề mặt này. Bạn có thể thử phiên bản web được quản lý qua Kimi Agent, chạy harness cục bộ đầy đủ với Kimi Work, làm việc trong terminal bằng Kimi Code, hoặc gọi trực tiếp kimi-k3.1-pro qua Kimi API. Biến thể kimi-k3.1-pro-highspeed đổi mức giá token cao gần gấp đôi để lấy tốc độ đầu ra nhanh gấp hai đến ba lần.

Dù đang đánh giá mô hình hay đưa sản phẩm ra thị trường, bạn đều nên áp dụng cùng một danh sách kiểm tra:

1. Bắt đầu từ tác vụ, không phải framework. Nếu tác tử của bạn chỉnh sửa mã, harness Bash kèm trình soạn thảo như ACI của SWE-agent đã được kiểm chứng. Nếu chúng điều khiển GUI hoặc web trực tiếp, bạn cần quan sát phiên thực và các hành động ở cấp độ nhấp chuột.

2. Bảo đảm môi trường có thể tái lập. Ảnh Docker, phần phụ thuộc được cố định phiên bản và dữ liệu có seed là khác biệt giữa một benchmark và một giai thoại.

3. Chủ động phân bổ cửa sổ ngữ cảnh. Cắt bớt quan sát, tóm tắt lịch sử và nén gọn là những tính năng của harness tác động trực tiếp đến điểm số và chi phí — cũng là lý do các mô hình ngữ cảnh dài làm giảm lượng thông tin mà harness phải loại bỏ.

4. Áp đặt giới hạn cứng. Giới hạn số bước, thời gian chờ theo thời gian thực và ngân sách tiền cho mỗi phiên giúp tác tử an toàn và các đánh giá có thể so sánh.

5. Ghi nhật ký toàn bộ quỹ đạo ngay từ ngày đầu. Mọi vòng lặp cải tiến nghiêm túc — đánh giá của con người, phân cụm lỗi, tinh chỉnh — đều sử dụng dữ liệu quỹ đạo. Managed Agents của Anthropic và DeepSeek Harness còn tiến xa hơn: lưu nhật ký phiên bên ngoài vòng lặp harness dưới dạng luồng sự kiện chỉ nối thêm, để bản thân harness có thể thay thế và ngữ cảnh của mô hình luôn có thể tái dựng.

6. Đánh giá trên nhiều harness. Nếu tác tử của bạn chỉ hoạt động trong một harness, bạn đã xây dựng hành vi đặc thù harness, chứ không phải năng lực.

7. Không để thông tin xác thực trong sandbox — hoặc hoàn toàn không đưa chúng lên đám mây. Hãy coi môi trường thực thi của tác tử là không đáng tin cậy; lưu token trong kho bảo mật và chèn chúng qua proxy, hoặc chạy toàn bộ phiên cục bộ để thông tin xác thực và nội dung trang không bao giờ rời khỏi thiết bị — cách Kimi áp dụng với các harness cục bộ của mình.

Agent harness đã âm thầm trở thành tầng quan trọng nhất trong hệ công nghệ tác tử. Nghiên cứu từ SWE-bench, mini-SWE-agent, Terminal-Bench và METR cho thấy thiết kế harness có thể tạo ra tác động ngang với việc nâng cấp mô hình; các dự án mã nguồn mở như DeepSeek Harness, OpenHands, SWE-agent và Aider đưa những harness đạt chuẩn vận hành thực tế đến gần hơn với mọi người; còn Anthropic, OpenAI, Google, Microsoft và Moonshot AI hiện đều xem kỹ thuật harness là công việc cốt lõi.

Nhưng sự thay đổi sâu sắc hơn nằm ở khái niệm. Thế hệ harness đầu tiên giải quyết bài toán Tác tử × Máy tính: trao cho mô hình những “đôi tay” đáng tin cậy để làm việc với terminal, trình duyệt và hệ thống tệp. Thế hệ tiếp theo đang giải quyết vấn đề ngữ cảnh do các môi trường đó tạo ra — công việc kéo dài nhiều ngày, liên quan đến các bên liên quan và kho mã mà không công cụ tóm tắt nào có thể nén mà không mất mát. Harness đang chuyển từ lớp khung hỗ trợ thành môi trường vận hành, và ranh giới giữa những gì harness phải quản lý với những gì mô hình có thể tự lưu giữ vẫn liên tục dịch chuyển. Cửa sổ một triệu token của Kimi K3.1 Pro là ví dụ rõ nhất hiện nay: một thay đổi ở mô hình giúp loại bỏ phần việc mà trước đây harness phải thực hiện.

Dù tự xây dựng, áp dụng một framework mã nguồn mở hay vận hành harness trong môi trường thực tế, những đội ngũ xem harness là phần mềm được thiết kế bài bản, quản lý phiên bản và đo lường được mới là những đội có tác tử thực sự hoàn thành công việc.