Giải phẫu một Agent Harness

Agents11/03/2026

Agent = Model + Harness. Nếu một thứ không phải là model, thì nó thuộc về harness.

Harness là toàn bộ đoạn code, cấu hình và logic thực thi không nằm trong bản thân model. Một model thô không phải là agent. Nó chỉ trở thành agent khi có một harness cấp cho nó trạng thái (state), khả năng thực thi tool, feedback loop và các ràng buộc có thể ép buộc thực thi.

Cụ thể, một harness thường bao gồm:

• System prompt
• Tool, Skill, MCP và phần mô tả đi kèm chúng
• Hạ tầng đi kèm (filesystem, sandbox, trình duyệt)
• Logic điều phối (spawn subagent, handoff giữa các agent, định tuyến model)
• Hook/middleware để thực thi tất định (compaction, continuation, kiểm tra lint)

Có rất nhiều cách chia ranh giới lộn xộn giữa model và harness trong một hệ thống agent. Nhưng theo LangChain, đây là định nghĩa gọn nhất, vì nó buộc ta phải nghĩ về việc thiết kế hệ thống xoay quanh trí tuệ của model.

Phần còn lại của bài viết đi qua các thành phần cốt lõi của harness, và suy ngược lý do vì sao mỗi thành phần tồn tại, xuất phát từ nguyên tố gốc là model.

Vì sao cần harness - nhìn từ góc độ của model

Có những việc ta muốn một agent làm được mà bản thân model không làm được ngay khi lấy ra dùng. Đây chính là chỗ harness bước vào.

Model (phần lớn) chỉ nhận vào dữ liệu như văn bản, hình ảnh, âm thanh, video, và sinh ra văn bản. Chỉ vậy thôi. Mặc định, model không thể:

• Duy trì trạng thái bền vững xuyên suốt nhiều lượt tương tác
• Thực thi code
• Truy cập kiến thức theo thời gian thực
• Thiết lập môi trường và cài đặt package để hoàn thành công việc

Tất cả đều là tính năng ở cấp harness. Cấu trúc của LLM đòi hỏi phải có một loại “máy móc” nào đó bao bọc quanh nó để làm được việc hữu ích. Ví dụ, để có trải nghiệm sản phẩm kiểu “chat”, ta bọc model trong một vòng lặp while để lưu lại các tin nhắn trước đó và nối thêm tin nhắn mới của người dùng vào. Ai đọc bài này cũng đã từng dùng qua loại harness này rồi. Ý tưởng cốt lõi là: ta muốn biến một hành vi agent mong muốn thành một tính năng thực sự trong harness.

Suy ngược từ hành vi mong muốn của agent đến harness engineering

Harness engineering giúp con người cài cắm các “prior” (giả định nền) hữu ích để định hướng hành vi của agent. Và khi model ngày càng mạnh hơn, harness được dùng để mở rộng và chỉnh sửa model một cách tinh vi, giúp hoàn thành những tác vụ trước đây bất khả thi.

Bài viết không liệt kê hết mọi tính năng harness có thể có. Mục tiêu là suy ra một tập tính năng, xuất phát từ điểm gốc: giúp model làm việc hữu ích. Khuôn mẫu chung sẽ là:

Hành vi ta muốn (hoặc muốn sửa) → Thiết kế harness giúp model đạt được hành vi đó.

Filesystem cho lưu trữ bền vững và quản lý ngữ cảnh

Ta muốn agent có nơi lưu trữ bền vững để làm việc với dữ liệu thật, đẩy bớt thông tin không vừa trong ngữ cảnh ra ngoài, và duy trì công việc xuyên suốt nhiều phiên.

Model chỉ có thể thao tác trực tiếp trên kiến thức nằm trong cửa sổ ngữ cảnh của nó. Trước khi có filesystem, người dùng phải copy/paste nội dung trực tiếp vào model, một trải nghiệm cồng kềnh và không hoạt động được với agent tự chủ. Thế giới vốn đã dùng filesystem để làm việc từ trước, nên model tự nhiên được huấn luyện trên hàng tỷ token dạy cách dùng chúng. Giải pháp tự nhiên trở thành:

Harness đi kèm các lớp trừu tượng filesystem và tool để thao tác file.

Filesystem có thể coi là nguyên tố nền tảng nhất của harness, vì những gì nó mở khoá:

• Agent có một không gian làm việc để đọc dữ liệu, code và tài liệu.
• Công việc có thể được bổ sung và đẩy bớt ra ngoài dần dần thay vì phải giữ hết trong ngữ cảnh. Agent có thể lưu kết quả trung gian và duy trì trạng thái tồn tại lâu hơn một phiên làm việc đơn lẻ.
• Filesystem là một bề mặt cộng tác tự nhiên. Nhiều agent và con người có thể phối hợp thông qua các file dùng chung. Các kiến trúc như multi-agent team dựa vào chính điều này.

Git bổ sung khả năng quản lý phiên bản cho filesystem, giúp agent theo dõi công việc, rollback lỗi, và tạo nhánh để thử nghiệm. Filesystem sẽ còn quay lại nhiều lần trong bài, vì nó là nguyên tố harness then chốt cho nhiều tính năng khác.

Bash + code như một tool đa năng

Ta muốn agent tự giải quyết vấn đề mà không cần con người phải thiết kế trước từng tool một.

Mẫu hình thực thi phổ biến nhất của agent hiện nay là vòng lặp ReAct, nơi model lý luận, thực hiện một hành động qua tool call, quan sát kết quả, rồi lặp lại trong một vòng lặp while. Nhưng harness chỉ có thể thực thi những tool mà nó có logic xử lý sẵn. Thay vì bắt người dùng phải xây tool cho từng hành động có thể xảy ra, giải pháp tốt hơn là cho agent một tool đa năng như bash.

Harness đi kèm tool bash để model có thể tự giải quyết vấn đề bằng cách viết và thực thi code.

Bash cộng với khả năng thực thi code là một bước tiến lớn hướng tới việc trao cho model một chiếc máy tính rồi để nó tự tìm cách xử lý phần còn lại. Model có thể tự thiết kế tool của riêng nó ngay tại chỗ thông qua code, thay vì bị bó buộc trong một tập tool định sẵn.

Harness vẫn đi kèm các tool khác, nhưng thực thi code đã trở thành chiến lược đa năng mặc định cho việc tự chủ giải quyết vấn đề.

Sandbox và tool để thực thi & kiểm chứng công việc

Agent cần một môi trường có cấu hình mặc định phù hợp để có thể hành động an toàn, quan sát kết quả, và tiến triển công việc.

Ta đã cho model khả năng lưu trữ và thực thi code, nhưng tất cả những điều đó cần diễn ra ở đâu đó. Chạy code do agent sinh ra trực tiếp trên máy cục bộ là rủi ro, và một môi trường cục bộ đơn lẻ không mở rộng được cho khối lượng công việc agent lớn.

Sandbox cho agent một môi trường vận hành an toàn. Thay vì thực thi cục bộ, harness có thể kết nối tới một sandbox để chạy code, kiểm tra file, cài đặt dependency, và hoàn thành tác vụ. Điều này tạo ra sự thực thi code cô lập, bảo mật. Để tăng bảo mật hơn nữa, harness có thể giới hạn danh sách lệnh được phép và áp đặt cô lập mạng. Sandbox cũng mở khoá khả năng mở rộng quy mô, vì môi trường có thể được tạo theo yêu cầu, chạy song song trên nhiều tác vụ, và huỷ đi khi công việc hoàn tất.

Môi trường tốt đi kèm bộ công cụ mặc định tốt. Harness có trách nhiệm cấu hình sẵn công cụ để agent làm được việc hữu ích. Điều này bao gồm cài sẵn runtime ngôn ngữ và package, CLI cho git và testing, trình duyệt để tương tác và kiểm chứng trên web.

Các công cụ như trình duyệt, log, screenshot và test runner cho agent cách quan sát và phân tích công việc của chính nó. Điều này giúp agent tạo ra vòng lặp tự kiểm chứng, nơi nó có thể viết code ứng dụng, chạy test, kiểm tra log, và tự sửa lỗi.

Model không tự cấu hình môi trường thực thi của chính nó. Quyết định agent chạy ở đâu, có công cụ gì, được truy cập gì, và kiểm chứng công việc ra sao, tất cả đều là các quyết định thiết kế ở cấp harness.

Memory & tìm kiếm cho việc học liên tục

Agent nên nhớ những gì nó đã thấy, và truy cập được thông tin chưa tồn tại vào lúc nó được huấn luyện.

Model không có kiến thức nào ngoài các trọng số (weight) của nó và những gì nằm trong ngữ cảnh hiện tại. Không có quyền chỉnh sửa trọng số model, cách duy nhất để “thêm kiến thức” là thông qua context injection (bơm thông tin vào ngữ cảnh).

Với memory, filesystem một lần nữa là nguyên tố cốt lõi. Harness hỗ trợ các chuẩn file memory như AGENTS.md, được nạp vào ngữ cảnh khi agent khởi động. Khi agent thêm và sửa file này, harness sẽ nạp bản cập nhật vào ngữ cảnh. Đây là một dạng học liên tục (continual learning), nơi agent lưu bền vững kiến thức từ một phiên và bơm kiến thức đó vào các phiên tương lai.

Việc có knowledge cutoff (giới hạn kiến thức theo thời điểm huấn luyện) nghĩa là model không thể tự truy cập dữ liệu mới như phiên bản thư viện mới nhất, trừ khi người dùng trực tiếp cung cấp. Để có kiến thức cập nhật, Web Search và các tool MCP như Context7 giúp agent truy cập thông tin vượt ra ngoài knowledge cutoff, ví dụ phiên bản thư viện mới hoặc dữ liệu hiện tại chưa tồn tại lúc huấn luyện dừng lại.

Web Search và các tool truy vấn ngữ cảnh cập nhật là những nguyên tố hữu ích để tích hợp vào harness.

Chống lại context rot

Hiệu năng của agent không nên xuống cấp trong quá trình làm việc.

Context rot (ngữ cảnh mục ruỗng dần) mô tả việc model trở nên tệ hơn trong lý luận và hoàn thành tác vụ khi cửa sổ ngữ cảnh của nó dần đầy lên. Ngữ cảnh là tài nguyên quý và khan hiếm, nên harness cần có chiến lược quản lý nó.

Harness ngày nay phần lớn là cơ chế để đưa context engineering tốt vào thực tế.

Compaction giải quyết câu hỏi: phải làm gì khi cửa sổ ngữ cảnh sắp đầy? Không có compaction, điều gì xảy ra khi một cuộc hội thoại vượt quá cửa sổ ngữ cảnh? Một lựa chọn là API báo lỗi, điều đó không tốt. Harness phải có một chiến lược cho trường hợp này. Vì vậy, compaction tóm tắt và đẩy bớt ngữ cảnh hiện có một cách thông minh, để agent có thể tiếp tục làm việc.

Đẩy bớt kết quả tool call (tool call offloading) giúp giảm tác động của các output tool lớn, vốn có thể làm ngữ cảnh nhiễu loạn mà không cung cấp thông tin hữu ích. Harness giữ lại phần đầu và phần cuối của token trong output tool khi vượt một ngưỡng số token nhất định, và đẩy phần output đầy đủ ra filesystem để model truy cập lại khi cần.

Skill giải quyết vấn đề có quá nhiều tool hoặc MCP server được nạp vào ngữ cảnh khi agent khởi động, làm giảm hiệu năng trước cả khi agent bắt đầu làm việc. Skill là một nguyên tố ở cấp harness giải quyết việc này thông qua progressive disclosure (tiết lộ dần dần). Model không tự chọn việc chỉ nạp phần front-matter của Skill vào ngữ cảnh lúc khởi động, nhưng harness có thể hỗ trợ điều này để bảo vệ model khỏi context rot.

Thực thi tự chủ trên chân trời dài (long horizon)

Ta muốn agent hoàn thành công việc phức tạp, một cách tự chủ, chính xác, xuyên suốt một khoảng thời gian dài.

Tự động tạo ra phần mềm một cách tự chủ là chén thánh của coding agent. Nhưng model ngày nay vẫn gặp vấn đề dừng sớm, khó phân rã bài toán phức tạp, và mất mạch lạc khi công việc kéo dài qua nhiều cửa sổ ngữ cảnh. Một harness tốt phải được thiết kế để xử lý tất cả những điều này.

Đây là lúc các nguyên tố harness đã nói ở trên bắt đầu cộng dồn tác dụng với nhau. Công việc dài hơi đòi hỏi trạng thái bền vững, lập kế hoạch, quan sát, và kiểm chứng để duy trì tiến triển xuyên suốt nhiều cửa sổ ngữ cảnh.

Filesystem và git để theo dõi công việc xuyên suốt các phiên. Agent sinh ra hàng triệu token qua một tác vụ dài, nên filesystem lưu bền vững công việc để theo dõi tiến độ theo thời gian. Thêm git cho phép agent mới nhanh chóng nắm bắt công việc và lịch sử mới nhất của dự án. Với nhiều agent làm việc cùng nhau, filesystem cũng đóng vai trò như một sổ cái (ledger) dùng chung để cộng tác.

Ralph Loop để tiếp tục công việc. Ralph Loop là một mẫu hình harness chặn lại nỗ lực thoát của model thông qua một hook, rồi bơm lại prompt gốc vào một cửa sổ ngữ cảnh sạch, buộc agent phải tiếp tục công việc hướng tới mục tiêu hoàn thành. Filesystem là điều kiện để làm được việc này, vì mỗi vòng lặp bắt đầu với ngữ cảnh mới nhưng đọc trạng thái từ vòng lặp trước.

Lập kế hoạch và tự kiểm chứng để bám sát mục tiêu. Lập kế hoạch (planning) là khi model phân rã một mục tiêu thành một chuỗi bước. Harness hỗ trợ việc này thông qua prompting tốt và bơm các nhắc nhở về cách dùng một file kế hoạch trong filesystem. Sau khi hoàn thành mỗi bước, agent được lợi từ việc kiểm tra tính đúng đắn của công việc thông qua tự kiểm chứng. Hook trong harness có thể chạy một bộ test định sẵn và quay lại model khi thất bại kèm thông báo lỗi, hoặc model có thể được nhắc để tự đánh giá code của mình một cách độc lập. Việc kiểm chứng neo giải pháp vào các test thật và tạo ra tín hiệu phản hồi để tự cải thiện.

Tương lai của harness

Sự gắn kết giữa huấn luyện model và thiết kế harness

Các sản phẩm agent ngày nay như Claude Code và Codex được post-train với cả model lẫn harness cùng nằm trong vòng lặp. Điều này giúp model cải thiện ở những hành động mà người thiết kế harness cho rằng model nên giỏi sẵn, như thao tác filesystem, thực thi bash, lập kế hoạch, hay song song hoá công việc với subagent.

Điều này tạo ra một vòng phản hồi. Các nguyên tố hữu ích được phát hiện, thêm vào harness, rồi được dùng khi huấn luyện thế hệ model tiếp theo. Khi chu trình này lặp lại, model ngày càng giỏi hơn trong phạm vi harness mà nó được huấn luyện cùng.

Nhưng sự đồng tiến hoá này có những tác dụng phụ thú vị đối với khả năng tổng quát hoá. Nó thể hiện qua việc thay đổi logic tool có thể khiến hiệu năng model tệ đi. Một ví dụ tốt được mô tả trong tài liệu prompting của Codex-5.3, với logic tool apply_patch để sửa file. Một model thực sự thông minh lẽ ra không gặp khó khăn gì khi chuyển đổi giữa các phương pháp patch khác nhau, nhưng việc huấn luyện với harness nằm trong vòng lặp tạo ra hiện tượng overfitting này.

Nhưng điều đó không có nghĩa harness tốt nhất cho tác vụ của bạn là harness mà model đã được post-train cùng. Bảng xếp hạng Terminal Bench 2.0 là một ví dụ điển hình. Opus 4.6 chạy trong Claude Code có điểm số thấp hơn hẳn Opus 4.6 chạy trong các harness khác. Trong một bài viết trước, LangChain cho thấy họ đã cải thiện coding agent của mình từ Top 30 lên Top 5 trên Terminal Bench 2.0 chỉ bằng cách thay đổi harness. Vẫn còn rất nhiều dư địa để khai thác bằng cách tối ưu harness cho đúng tác vụ của bạn.

Harness engineering đang đi về đâu

Khi model ngày càng giỏi hơn, một phần những gì đang nằm trong harness hôm nay sẽ được hấp thụ vào model. Model sẽ giỏi hơn trong việc lập kế hoạch, tự kiểm chứng, và duy trì mạch lạc trên chân trời dài một cách tự nhiên, nhờ đó cần ít context injection hơn.

Điều đó gợi ý rằng harness sẽ ngày càng bớt quan trọng theo thời gian. Nhưng cũng giống như prompt engineering vẫn còn giá trị cho tới hôm nay, nhiều khả năng harness engineering sẽ tiếp tục hữu ích cho việc xây dựng agent tốt.

Đúng là harness ngày nay vá lại các khiếm khuyết của model, nhưng chúng cũng thiết kế hệ thống xoay quanh trí tuệ của model để làm nó hiệu quả hơn. Một môi trường được cấu hình tốt, đúng bộ công cụ, trạng thái bền vững, và vòng lặp kiểm chứng khiến bất kỳ model nào cũng hiệu quả hơn, bất kể trí tuệ nền tảng của nó ra sao.

Harness engineering là một lĩnh vực nghiên cứu rất năng động, được LangChain dùng để cải thiện thư viện xây dựng harness của họ, deepagents. Dưới đây là vài bài toán mở, thú vị mà họ đang khám phá:

• Điều phối hàng trăm agent làm việc song song trên cùng một codebase
• Agent tự phân tích trace của chính nó để phát hiện và sửa các lỗi ở cấp harness
• Harness tự động lắp ráp đúng bộ tool và ngữ cảnh ngay tại thời điểm cần, thay vì được cấu hình sẵn từ trước

Bài viết này là một bài tập định nghĩa harness là gì, và nó được định hình ra sao bởi công việc mà ta muốn model thực hiện.

Model chứa trí tuệ, còn harness là hệ thống khiến trí tuệ đó trở nên hữu ích.

Ghi chú của người dịch

Bài này và bài “AI Agent Harness là gì” trên trang Khái niệm bổ trợ tốt cho nhau: trang Khái niệm cho định nghĩa tham chiếu trung lập, còn bài này là góc nhìn kỹ thuật sâu hơn của đội LangChain, người trực tiếp xây dựng harness cho agent (deepagents) - đáng chú ý là cách họ suy ngược từng thành phần harness từ một hành vi cụ thể muốn có, thay vì liệt kê danh sách tính năng.

Nguồn

Bài viết được chuyển thể từ bài viết “The Anatomy of an Agent Harness” trên blog chính thức của LangChain. Các hình ảnh trong bài được lấy lại từ bài viết gốc.

← Xem tất cả bài viết