Kỹ thuật Harness cho Agent

Một tác nhân mã (coding agent) là mô hình cộng với mọi thứ được xây dựng xung quanh nó. Kỹ thuật bộ khung (harness engineering) coi phần giàn giáo đó như một tạo tác sống, thắt chặt nó mỗi khi tác nhân mắc lỗi.

Nói đơn giản: bất cứ khi nào một tác nhân thất bại, bạn hãy thiết kế một giải pháp vĩnh viễn để nó không bao giờ mắc lại lỗi chính xác đó nữa.

Trong hai năm qua, ngành công nghiệp đã tranh luận về các mô hình: mô hình nào thông minh nhất, mô hình nào viết React sạch nhất, hay mô hình nào ảo giác ít nhất. Dù cuộc thảo luận đó có giá trị, nó đã bỏ qua nửa còn lại của hệ thống.

Mô hình chỉ là một đầu vào của một tác nhân đang chạy. Phần còn lại là bộ khung: các prompt, công cụ, chính sách ngữ cảnh, hook, hộp cát, tác nhân phụ, vòng phản hồi và đường dẫn khôi phục được bọc quanh mô hình để nó thực sự có thể hoàn thành nhiệm vụ.

Một mô hình tạm ổn với bộ khung tuyệt vời luôn đánh bại một mô hình tuyệt vời với bộ khung tồi. Ngày càng nhiều, công việc kỹ thuật thú vị nhất không nằm ở việc chọn mô hình, mà là thiết kế giàn giáo xung quanh nó.

Ngành học đó giờ đã có tên gọi. @Vtrivedy10 đã đặt ra thuật ngữ kỹ thuật bộ khung, đưa ra một phân tích rõ ràng về bộ khung thực sự là gì và tại sao từng phần lại tồn tại. Những tiếng nói khác trong ngành như @dexhorthy theo dõi các mẫu hình mới nổi, HumanLayer coi các lỗi của tác nhân là "vấn đề kỹ năng" cấu hình, nhóm kỹ thuật của Anthropic xuất bản hướng dẫn về thiết kế ứng dụng chạy dài, và Birgitta Böckeler khám phá trải nghiệm phía người dùng – tất cả đều hội tụ về cùng một ý tưởng.

Bài viết này kết nối những luồng suy nghĩ đó lại với nhau.

Bộ Khung Thực Sự Là Gì?

Định nghĩa cốt lõi của Trivedy đã làm phần lớn công việc nặng nhọc:

Tác nhân = Mô hình + Bộ khung. Nếu bạn không phải là mô hình, bạn là bộ khung.

Một bộ khung bao gồm mọi phần mã, cấu hình và logic thực thi không phải là bản thân mô hình. Một mô hình thô không phải là một tác nhân. Nó chỉ trở thành tác nhân khi một bộ khung cung cấp cho nó trạng thái, thực thi công cụ, vòng phản hồi và các ràng buộc có thể thực thi.

Cụ thể, một bộ khung bao gồm:

• Các prompt hệ thống, CLAUDE.md, AGENTS.md, tệp kỹ năng và hướng dẫn cho tác nhân phụ.
• Các công cụ, kỹ năng, máy chủ MCP và mô tả kỹ thuật của chúng.
• Hạ tầng đi kèm, như hệ thống tệp, hộp cát và trình duyệt không đầu.
• Logic điều phối để sinh ra tác nhân phụ, xử lý bàn giao và định tuyến mô hình.
• Hook và middleware để thực thi xác định, như kiểm tra lint hoặc nén ngữ cảnh.
• Công cụ quan sát cho log, trace, chi phí và đo độ trễ.

Về cốt lõi, một tác nhân là một hệ thống chạy các công cụ trong một vòng lặp để đạt được mục tiêu. Kỹ năng thực sự nằm ở việc thiết kế cả công cụ lẫn vòng lặp đó.

Mặc dù đây là một bề mặt rộng lớn, nhưng đó là bề mặt của bạn, không phải của nhà cung cấp mô hình. Claude Code, Cursor, Codex, Aider và Cline đều là các bộ khung. Mô hình bên dưới có thể giống hệt nhau trên các nền tảng, nhưng hành vi bạn trải nghiệm bị chi phối bởi bộ khung.

Hãy Định Nghĩa Lại "Vấn Đề Kỹ Năng"

Thường thấy các kỹ sư đổ lỗi cho mô hình khi một tác nhân làm điều vô nghĩa, thường gác vấn đề đó lại để "chờ phiên bản tiếp theo" sửa.

Tư duy kỹ thuật bộ khung bác bỏ mặc định này. Các lỗi thường có thể hiểu được ở một mức độ nào đó. Nếu tác nhân bỏ qua một quy ước, hãy thêm nó vào AGENTS.md. Nếu nó chạy một lệnh phá hoại, hãy viết một hook để chặn nó. Nếu nó bị lạc trong một nhiệm vụ 40 bước, hãy tách kiến trúc thành một bộ lập kế hoạch và một bộ thực thi. Nếu nó luôn kết thúc với mã hỏng, hãy gắn một tín hiệu phản hồi kiểm tra kiểu vào vòng lặp.

Như HumanLayer đã nói: "Đó không phải là vấn đề của mô hình. Đó là vấn đề cấu hình." Hãy xem xét các điểm chuẩn hiệu suất: một mô hình hàng đầu chạy bên trong một framework có sẵn thường đạt điểm thấp hơn đáng kể so với chính mô hình đó chạy trong một bộ khung tùy chỉnh, được tinh chỉnh cao. Di chuyển một mô hình vào một môi trường có công cụ mã nguồn tốt hơn, prompt chặt chẽ hơn và phản hồi sắc bén hơn có thể mở khóa các khả năng mà thiết lập ban đầu bỏ lại phía sau.

Khoảng cách giữa những gì các mô hình ngày nay có thể làm về mặt lý thuyết và những gì bạn thực sự thấy chúng làm phần lớn là khoảng cách về bộ khung.

Cái Bánh Cóc: Mỗi Sai Lầm Trở Thành Một Quy Tắc

Thói quen quan trọng nhất trong kỹ thuật bộ khung là coi các lỗi của tác nhân như những tín hiệu vĩnh viễn – không phải là những sự cố nhất thời để thử lại và quên đi.

Nếu một tác nhân gửi một PR với một bài kiểm tra bị comment và vô tình được hợp nhất, đó là một đầu vào. Lần lặp tiếp theo của AGENTS.md phải nêu: "Không bao giờ comment các bài kiểm tra; hãy xóa hoặc sửa chúng." Hook pre-commit tiếp theo phải tự động gắn cờ .skip( trong diff. Tác nhân phụ đánh giá phải được cập nhật để chặn các bài kiểm tra bị comment.

Các ràng buộc chỉ nên được thêm vào khi bạn quan sát thấy một lỗi thực tế, và chỉ được loại bỏ khi một mô hình có năng lực khiến chúng trở nên dư thừa. Mỗi dòng trong một prompt hệ thống tốt nên truy ngược về một lỗi lịch sử cụ thể.

Bởi vì điều này, kỹ thuật bộ khung là một ngành học chứ không phải là một framework một kích cỡ phù hợp tất cả. Bộ khung phù hợp cho một mã nguồn cụ thể hoàn toàn được định hình bởi lịch sử lỗi riêng của nó.

Làm Việc Ngược Từ Hành Vi

Cách hiệu quả nhất để thiết kế một bộ khung là bắt đầu với hành vi mong muốn và xây dựng thành phần mang lại nó: Hành vi chúng ta muốn → Thiết kế bộ khung để đạt được nó.

Mọi phần của bộ khung phải có một công việc riêng biệt. Nếu bạn không thể đặt tên cho hành vi cụ thể mà một thành phần tồn tại để mang lại, nó nên được loại bỏ.

Hệ thống tệp và Git – trạng thái bền vững

Hệ thống tệp là nền tảng. Các mô hình chỉ có thể hoạt động trên những gì vừa với cửa sổ ngữ cảnh của chúng. Một hệ thống tệp cung cấp một không gian làm việc để đọc dữ liệu, một nơi để chuyển tải công việc trung gian và một bề mặt để nhiều tác nhân phối hợp.

Thêm Git cung cấp phiên bản miễn phí, cho phép tác nhân theo dõi tiến độ, phân nhánh thử nghiệm và khôi phục lỗi.

Bash và Thực thi mã: công cụ đa năng

Hầu hết các tác nhân hoạt động trên vòng lặp ReAct: suy luận, hành động thông qua một lệnh gọi công cụ, quan sát, lặp lại. Thay vì xây dựng trước một công cụ cho mọi hành động có thể tưởng tượng, việc cho tác nhân quyền truy cập bash cho phép nó xây dựng những gì cần thiết ngay tại chỗ.

Các tác nhân thường xuất sắc với các lệnh shell, khiến bash và thực thi mã trở thành chiến lược mặc định cho việc giải quyết vấn đề tự động.

Hộp cát và Công cụ mặc định

Bash chỉ hữu ích nếu nó chạy an toàn. Hộp cát cung cấp cho tác nhân một môi trường biệt lập để chạy mã, kiểm tra tệp và xác minh công việc mà không gây rủi ro cho máy chủ.

Một hộp cát tốt đi kèm với các mặc định mạnh mẽ: môi trường chạy ngôn ngữ được cài đặt sẵn, CLI kiểm tra và trình duyệt không đầu, cho phép tác nhân quan sát công việc của chính nó và khép kín vòng lặp tự xác minh.

Bộ nhớ và Tìm kiếm: Học tập liên tục

Các mô hình không có kiến thức nào ngoài trọng số huấn luyện và ngữ cảnh hiện tại. Bộ khung thu hẹp khoảng cách này bằng cách sử dụng các tệp bộ nhớ (như AGENTS.md) để tiêm kiến thức vào mỗi phiên.

Đối với thông tin thời gian thực như phiên bản thư viện mới hoặc dữ liệu trực tiếp, tìm kiếm web và công cụ MCP được tích hợp trực tiếp vào bộ khung.

Chống lại sự suy giảm ngữ cảnh

Các mô hình suy giảm khả năng suy luận khi cửa sổ ngữ cảnh của chúng đầy lên. Bộ khung quản lý sự khan hiếm này bằng ba kỹ thuật chính:

• Nén: Tóm tắt thông minh và chuyển tải ngữ cảnh cũ hơn để ngăn lỗi API.
• Chuyển tải lệnh gọi công cụ: Lưu trữ các đầu ra công cụ lớn (như log 2.000 dòng) trong hệ thống tệp trong khi chỉ giữ các tiêu đề và chân trang thiết yếu trong ngữ cảnh.
• Tiết lộ dần dần: Chỉ tiết lộ hướng dẫn và công cụ khi một nhiệm vụ yêu cầu chúng một cách rõ ràng, thay vì tải mọi thứ khi khởi động.

Thực thi tầm nhìn dài hạn

Công việc tự động, chạy dài bị ảnh hưởng bởi việc dừng sớm và phân rã vấn đề kém. Bộ khung chống lại điều này thông qua thiết kế cấu trúc:

• Vòng lặp: Chặn nỗ lực thoát của mô hình và buộc nó tiếp tục hướng tới một mục tiêu hoàn thành trong một cửa sổ ngữ cảnh mới.
• Lập kế hoạch: Buộc mô hình phân rã các mục tiêu thành một tệp kế hoạch từng bước, kiểm tra công việc của nó thông qua các hook tự xác minh sau mỗi bước.
• Tách biệt: Tách biệt việc tạo sinh và đánh giá thành các tác nhân riêng biệt, ngăn chặn sự thiên vị tích cực vốn có của các mô hình khi tự chấm điểm công việc của mình.

Hook là lớp thực thi của bạn

Hook thu hẹp khoảng cách giữa việc yêu cầu một hành động và thực thi nó. Chúng chạy tại các vòng đời cụ thể: trước một lệnh gọi công cụ, sau một chỉnh sửa tệp hoặc trước một commit. Hook chặn các lệnh phá hoại, thực thi tự động định dạng để tiết kiệm token và chạy bộ kiểm tra.

Lý tưởng nhất là thành công im lặng và thất bại dài dòng. Nếu một kiểm tra kiểu vượt qua, tác nhân không nghe thấy gì; nếu nó thất bại, lỗi được tiêm trực tiếp trở lại vòng lặp để tự sửa lỗi.

Đây là sổ tay quy tắc và lựa chọn công cụ

Một tệp markdown phẳng tại thư mục gốc của kho lưu trữ vẫn là điểm cấu hình có đòn bẩy cao nhất. Tuy nhiên, nó phải được coi như danh sách kiểm tra của phi công, không phải hướng dẫn phong cách. Giữ nó ngắn gọn và đảm bảo mọi quy tắc đều được kiếm được thông qua một lỗi trong quá khứ.

Nguyên tắc tương tự áp dụng cho các công cụ. Mười công cụ tập trung cao độ sẽ luôn vượt trội hơn năm mươi công cụ chồng chéo.

Hơn nữa, vì mô tả công cụ điền vào prompt, các tích hợp bên ngoài độc hại hoặc cẩu thả (như máy chủ MCP chưa được xác minh) có thể tiêm các prompt xấu vào tác nhân trước khi nó bắt đầu làm việc.

Điều này trông như thế nào trong sản xuất

Bức tranh công khai rõ ràng nhất mà tôi từng thấy về một bộ khung trưởng thành là phân tích (ước tính) của Fareed Khan về kiến trúc của Claude Code.

Hầu như mọi khái niệm từ phần trước đều xuất hiện trên sơ đồ này như một thành phần được đặt tên. Tiêm ngữ cảnh là lớp kiến thức. Trạng thái vòng lặp nằm trong kho lưu trữ bộ nhớ và bộ cách ly cây làm việc. Hook hành động phá hoại nằm sau cổng quyền. Tường lửa ngữ cảnh của tác nhân phụ là toàn bộ lớp đa tác nhân. Sổ đăng ký phân phối công cụ là nơi cả máy chủ MCP và bash đều kết nối. Quỹ đạo của Claude Code nói về bộ khung ít nhất cũng nhiều như về mô hình bên dưới nó.

Bộ Khung Không Thu Nhỏ Lại, Chúng Di Chuyển

Khi các mô hình cải thiện, nhu cầu về bộ khung không biến mất – nó dịch chuyển.

Thật dễ để cho rằng các mô hình tốt hơn làm cho giàn giáo trở nên lỗi thời. Ví dụ, các nâng cấp mô hình gần đây đã giảm đáng kể nhu cầu về các biện pháp giảm thiểu "lo lắng về ngữ cảnh". Nhưng khi sàn nhà nâng lên, trần nhà cũng nâng theo. Các nhiệm vụ trước đây không thể đạt được giờ đây nằm trong tầm với, mang đến những chế độ lỗi hoàn toàn mới.

Mọi thành phần trong một bộ khung đều mã hóa một giả định về những gì mô hình không thể tự làm. Khi mô hình cải thiện, giàn giáo lỗi thời nên được loại bỏ và giàn giáo mới phải được xây dựng để đạt đến chân trời tiếp theo.

Còn về vòng lặp huấn luyện thì sao?

Có một vòng phản hồi tích cực giữa thiết kế bộ khung và huấn luyện mô hình.

Các mô hình ngày nay thường được hậu huấn luyện với các bộ khung cụ thể trong vòng lặp, tạo ra một mức độ quá khớp. Mô hình trở nên đặc biệt giỏi ở các hành động cụ thể mà các nhà thiết kế bộ khung ưu tiên (ví dụ: thao tác hệ thống tệp, bash, điều phối tác nhân phụ).

Điều này làm cho bộ khung trở thành một hệ thống sống, không phải một tệp cấu hình tĩnh, và chứng minh rằng bộ khung "tốt nhất" là bộ khung được tối ưu hóa cụ thể cho các nhiệm vụ và quy trình làm việc riêng biệt của bạn.

Bộ Khung Như Một Dịch Vụ (HaaS)

Ngành công nghiệp đang chuyển từ xây dựng trên API LLM (cung cấp các hoàn chỉnh) sang xây dựng trên API Bộ khung (cung cấp một môi trường chạy). Các SDK giờ đây cung cấp vòng lặp, công cụ, quản lý ngữ cảnh, hook và hộp cát ngay khi xuất xưởng.

Thay vì xây dựng điều phối từ đầu, mặc định hiện đại là chọn một framework bộ khung, cấu hình các trụ cột cốt lõi của nó và tập trung hoàn toàn vào thiết kế prompt và công cụ theo miền cụ thể.

Đây là điều làm cho việc khắc phục sự cố có thể mở rộng: bạn đang tinh chỉnh một bề mặt cấu hình được phân chia tốt thay vì phát minh lại toàn bộ kiến trúc tác nhân.

Hướng Đi Này Sẽ Đi Đâu

Nếu bạn nhìn vào các tác nhân mã hàng đầu hiện nay, chúng trông giống nhau hơn là các mô hình bên dưới của chúng. Các mô hình khác nhau, nhưng các mẫu bộ khung đang hội tụ. Ngành công nghiệp đang nhanh chóng xác định giàn giáo chịu lực cần thiết để biến văn bản tạo sinh thành phần mềm có thể giao hàng.

Các vấn đề mở thú vị nhất đang vượt ra ngoài các tác nhân đơn lẻ: điều phối nhiều tác nhân song song, cho phép tác nhân phân tích các trace của chính chúng để sửa các lỗi cấp bộ khung và xây dựng các môi trường lắp ráp công cụ động đúng lúc.

Cuối cùng, đây là giai đoạn mà các bộ khung không còn là các tệp cấu hình tĩnh và bắt đầu hoạt động giống như các trình biên dịch hơn.

Nếu bạn đang tìm kiếm một framework bộ khung tác nhân mã tuyệt vời, @FredKSchott đã viết Flue. Nó rất vững chắc và dường như được lấy cảm hứng từ một phiên bản trước đó của bài viết này!