Harness Engineering: Cách xây dựng AI Agents hoạt động hiệu quả

Hầu hết mọi người đang cố sửa AI agent ở sai tầng.

Khi một agent thất bại, họ viết lại prompt. Khi nó lại thất bại, họ thêm nhiều chỉ dẫn hơn, đổi model, tăng context window hoặc kết nối thêm một công cụ khác.

Rồi những vấn đề cũ lại quay về.

Agent quên mất một quyết định quan trọng. Nó dùng sai công cụ. Nó không nhớ nổi chuyện gì đã xảy ra cách đó ba bước. Nó tuyên bố task đã xong mà chẳng thèm kiểm tra kết quả. Nó lặp đi lặp lại một hành động thất bại cho đến khi cạn sạch ngân sách.

Vấn đề không phải lúc nào cũng nằm ở model.

Vấn đề nằm ở môi trường xung quanh nó.

Môi trường đó chính là harness.

Harness Engineering (Kỹ thuật xây dựng Harness) là quá trình xây dựng hệ thống bao quanh một model để quyết định nó được thấy gì, được làm gì, ghi nhớ điều gì, thế nào là thành công và chuyện gì sẽ xảy ra khi có lỗi.

Một prompt tốt hơn có thể cải thiện một câu trả lời.

Một harness tốt hơn sẽ cải thiện mọi lần chạy.

Theo dõi Substack của tôi để đọc thêm các bài phân tích thực tế về AI agent, tự động hóa và hệ thống production:

substack.com/@lunarresearcher

1. Model Không Phải Là Agent

Một model có thể suy luận, tạo nội dung, so sánh và lựa chọn.

Điều đó không biến nó thành một agent đáng tin cậy.

Một agent thực thụ còn cần tìm đúng context, sử dụng công cụ, duy trì state, tuân thủ quyền hạn, tự kiểm tra kết quả của mình và phục hồi khi môi trường hoạt động khác với dự kiến.

Model chỉ là bộ máy suy luận.

Harness là toàn bộ phần còn lại giúp biến suy luận đó thành hành động thực tế.

1YÊU CẦU CỦA NGƯỜI DÙNG
2      |
3      v
4+-----------------------------+
5|           HARNESS           |
6|                             |
7| contract      context       |
8| tools         state         |
9| policy        verification  |
10| traces        recovery      |
11+-----------------------------+
12      |
13      v
14    MODEL
15      |
16      v
17MÔI TRƯỜNG THỰC TẾ

Đặt cùng một model vào khung chat, nó sẽ trả lời câu hỏi.

Đặt nó vào một repository có quyền truy cập terminal, test, công cụ trình duyệt, bộ nhớ dự án, quyền hạn được kiểm soát và vòng lặp review, nó có thể hoàn thành công việc thực sự.

Model không hề thay đổi.

Chỉ có harness thay đổi.

2. Biến Mọi Yêu Cầu Thành Một Bản Hợp Đồng

Ngôn ngữ tự nhiên rất linh hoạt.

Nhưng việc thực thi tự động thì không nên như vậy.

Một yêu cầu kiểu:

Cải thiện luồng onboarding.

thì ổn nếu có người ngồi cạnh model.

Nhưng nó cực kỳ tệ nếu dùng làm chỉ thị trong production.

Trước khi agent hành động, hãy biến yêu cầu đó thành một bản hợp đồng task có giới hạn rõ ràng.

1objective: giảm tỷ lệ rời bỏ ở bước onboarding
2
3inputs:
4  - tài liệu tóm tắt sản phẩm
5  - dữ liệu analytics
6  - repository
7
8constraints:
9  - giữ nguyên cơ chế xác thực
10  - không thay đổi schema database
11  - giữ nguyên hành vi hiện tại trên mobile
12
13deliverable:
14  - pull request có thể review
15
16done_when:
17  - test chạy qua
18  - event analytics kích hoạt đúng
19  - luồng desktop qua vòng review
20  - luồng mobile qua vòng review
21
22approval_required:
23  - triển khai lên production

Phần quan trọng nhất là done_when.

Không có nó, agent có thể giải quyết một phiên bản dễ hơn của bài toán rồi vẫn tự tin báo rằng task đã xong.

Có nó, việc hoàn thành mới trở nên đo lường được.

Agent không nên hỏi:

Tôi nên làm gì tiếp theo?

Nó nên hỏi:

Hành động nào đưa môi trường hiện tại tiến gần hơn đến kết quả đã cam kết trong hợp đồng?

Đó mới là một vòng lặp vững chắc hơn nhiều.

3. Cho Agent Một Tấm Bản Đồ, Đừng Nhét Cả Context Window Khổng Lồ

Phản xạ thường thấy khi agent mắc lỗi là nhồi thêm context cho model.

Thêm tài liệu.

Thêm lịch sử hội thoại.

Thêm file.

Thêm output từ công cụ.

Cuối cùng, agent nhận được mọi thứ nhưng lại hiểu ít đi.

Context không phải nơi lưu trữ.

Nó là ngân sách chú ý.

Thay vì đổ cả dự án vào mỗi lần chạy, hãy cho agent một tấm bản đồ nhỏ chỉ ra thông tin hữu ích nằm ở đâu.

1BẢN ĐỒ DỰ ÁN
2
3quy tắc sản phẩm -> docs/product/
4kiến trúc        -> docs/architecture.md
5frontend         -> apps/web/
6backend          -> services/api/
7test             -> tests/
8câu lệnh         -> docs/commands.md
9bảo mật          -> docs/security.md

Sau đó chỉ mở rộng khi thực sự cần.

1TASK
2  |
3  v
4BẢN ĐỒ DỰ ÁN
5  |
6  v
7HỆ THỐNG LIÊN QUAN
8  |
9  v
10FILE CỤ THỂ
11  |
12  v
13CHỈ THỊ NỘI BỘ

Tài liệu gốc gọi đây là progressive disclosure (tiết lộ dần dần): harness chỉ nên tải thêm thông tin vì task cần đến nó, chứ không phải chỉ vì thông tin đó tồn tại.

Mục tiêu không phải là context tối đa.

Mục tiêu là tín hiệu hữu ích tối đa.

4. Đặt Một Cổng Kiểm Soát Giữa Model Và Các Công Cụ

Một model có hai mươi công cụ không tự động mạnh gấp hai mươi lần.

Nó có thể chỉ có thêm hai mươi cách để thất bại.

Mỗi công cụ đều cần một bản hợp đồng.

1CÔNG CỤ: edit_file
2
3INPUTS
4path
5patch
6
7ĐIỀU KIỆN TIÊN QUYẾT
8path tồn tại
9path nằm trong workspace
10
11THÀNH CÔNG
12patch được áp dụng
13trả về diff
14
15THẤT BẠI
16lỗi có cấu trúc
17không ghi đè một phần
18
19RỦI RO
20có thể đảo ngược

Khi đó, luồng thực thi sẽ trở thành:

1MODEL ĐỀ XUẤT
2      |
3      v
4CỔNG KIỂM TRA XÁC THỰC
5      |
6      v
7POLICY PHÊ DUYỆT
8      |
9      v
10CÔNG CỤ THỰC THI
11      |
12      v
13HARNESS GHI NHẬN KẾT QUẢ

Model quyết định nó muốn làm gì.

Harness quyết định hành động đó có hợp lệ, được phép và an toàn hay không.

Sự phân biệt này trở nên sống còn khi công cụ có thể gửi tin nhắn, thay đổi production, tiêu tiền hoặc xóa dữ liệu.

Một cổng kiểm soát công cụ tốt còn có thể thêm timeout, xác thực tham số, giới hạn đường dẫn file, chuẩn hóa lỗi và giúp việc thử lại trở nên an toàn.

Công cụ tốt sẽ giảm bớt số thứ mà model phải đoán.

5. Đưa Bộ Nhớ Ra Khỏi Cuộc Hội Thoại

Cuộc hội thoại không nên là nơi lưu trữ dữ liệu gốc của hệ thống.

Các agent chạy dài cuối cùng sẽ chạm giới hạn context, sập, khởi động lại hoặc chuyển giao công việc sang session khác.

Nếu mọi quyết định quan trọng chỉ tồn tại trong đoạn chat, workflow đó cực kỳ mong manh.

Hãy lưu state bền vững ở nơi khác.

1{
2  "task_id": "feature_042",
3  "status": "đang xác minh",
4  "current_step": "kiểm_tra_mobile",
5
6  "completed": [
7    "triển khai",
8    "unit_tests",
9    "kiểm_tra_desktop"
10  ],
11
12  "decisions": [
13    "tái sử dụng endpoint export hiện có",
14    "giữ nguyên định dạng ngày tháng hiện tại"
15  ],
16
17  "artifacts": [
18    "export.csv",
19    "desktop-after.png"
20  ],
21
22  "open_risks": [
23    "thanh công cụ trên mobile có thể bị tràn"
24  ],
25
26  "next_action": "hiển thị viewport mobile"
27}

Một hệ thống hữu ích sẽ chia bộ nhớ thành bốn loại:

1DỮ KIỆN
2kiến thức ổn định
3
4QUYẾT ĐỊNH
5đã chọn gì và tại sao
6
7STATE
8lần chạy hiện tại đang ở đâu
9
10BÀI HỌC
11những lỗi cần ảnh hưởng đến các lần chạy sau

Session agent tiếp theo nên kế thừa trạng thái công việc, chứ không phải một câu chuyện tóm tắt về cuộc hội thoại trước đó.

6. Lấy Bằng Chứng Làm Điều Kiện Để Hoàn Thành

Agent nói "xong rồi" không có nghĩa là việc đã xong.

Đó chỉ là một output khác của model.

Harness cần bằng chứng quan sát được.

1TUYÊN BỐ                  BẰNG CHỨNG
2
3"đã sửa bug"              test từng lỗi giờ đã chạy qua
4
5"trang hoạt động"         luồng trình duyệt đã hoàn tất
6
7"dữ liệu chính xác"       giá trị khớp với nguồn
8
9"migration an toàn"       dry run + rollback thành công
10
11"task hoàn tất"           mọi bước kiểm tra chấp nhận đều đạt

Hãy dùng các bước kiểm tra tất định trước.

1cú pháp
2  |
3  v
4kiểu dữ liệu
5  |
6  v
7test cục bộ
8  |
9  v
10integration test
11  |
12  v
13review trực quan / ngữ nghĩa
14  |
15  v
16con người phê duyệt

Đừng bắt một model khác trả lời thứ mà compiler, test, schema hay câu query database có thể chứng minh.

Dùng model để phán đoán.

Dùng hệ thống tất định để xác minh dữ kiện.

Model tạo ra artifact.

Môi trường tạo ra bằng chứng về artifact đó.

Harness quyết định xem bằng chứng đã đủ chưa.

7. Tách Người Xây Dựng Khỏi Người Kiểm Tra

Việc tự review còn một vấn đề nữa.

Agent tạo ra lỗi thường mang chính những giả định đó vào bước review.

Một kiến trúc vững chắc hơn sẽ tách riêng worker và verifier.

1BUILDER
2   |
3   v
4tạo ra bản nháp
5   |
6   v
7VERIFIER
8   |
9   +-- kiểm tra hợp đồng
10   +-- tìm các trường hợp bị thiếu
11   +-- kiểm chứng các tuyên bố chưa có căn cứ
12   +-- cố gắng phá vỡ kết quả
13   |
14   +------ ĐẠT ------> CHẤP NHẬN
15   |
16   +------ LỖI ------> TRẢ VỀ BẰNG CHỨNG

Verifier không nên hỏi:

Nhìn ổn chưa?

Nó nên hỏi:

Điều gì sẽ khiến thứ này không thể chấp nhận được?

Điều đó biến việc review từ xác nhận thành nỗ lực bác bỏ.

Tài liệu gốc đặc biệt khuyến nghị việc cung cấp cho khâu xác minh bộ tiêu chí từ chối riêng và đủ sự độc lập để thách thức các giả định đã tạo ra kết quả ban đầu.

8. Đưa Quyền Hạn Ra Khỏi Model

Một số quy tắc không bao giờ nên phụ thuộc vào việc model có nhớ chúng hay không.

1không bao giờ publish khi chưa được duyệt
2không bao giờ để lộ secret
3không bao giờ vượt hạn mức chi tiêu
4không bao giờ ghi file ngoài workspace
5không bao giờ nhận bừa là test đã chạy qua nếu chưa chạy

Đây không phải gợi ý trong prompt.

Đây là policy.

Một thang phân quyền đơn giản:

1RỦI RO THẤP
2
3đọc
4tìm kiếm
5kiểm tra
6
7-> tự động
8
9CÓ THỂ ĐẢO NGƯỢC
10
11chỉnh sửa workspace
12chạy test
13tạo bản nháp
14
15-> tự động + ghi log
16
17CÓ TÁC ĐỘNG RA BÊN NGOÀI
18
19gửi
20deploy
21mua hàng
22
23-> cần phê duyệt
24
25KHÔNG THỂ ĐẢO NGƯỢC / NHẠY CẢM
26
27xóa dữ liệu
28xoay vòng credential
29publish toàn cầu
30
31-> chặn cứng hoặc cấm hoàn toàn

Hậu quả càng lớn, kiểm soát càng chặt.

Model có thể đề xuất hành động.

Harness phê duyệt hành động đó.

Công cụ thực thi nó.

Tự chủ không có nghĩa là thiếu kiểm soát.

Nó là sự tự do bên trong một ranh giới được thực thi nghiêm ngặt.

9. Ngừng Thử Lại Một Cách Mù Quáng

Một trong những chính sách phục hồi tệ nhất là:

Có lỗi xảy ra. Thử lại đi.

Nếu không có gì thay đổi, hệ thống chỉ đang trả tiền để tái tạo lại đúng lỗi đó.

Lỗi cần được phân loại trước.

1TOOL TIMEOUT
2-> thử lại với backoff
3
4THAM SỐ KHÔNG HỢP LỆ
5-> sửa lại lệnh gọi tool
6
7THIẾU CONTEXT
8-> lấy thêm nguồn dữ liệu bị thiếu
9
10TEST THẤT BẠI
11-> kiểm tra hành vi gây lỗi
12
13BỊ TỪ CHỐI QUYỀN
14-> yêu cầu phê duyệt
15
16YÊU CẦU MÂU THUẪN NHAU
17-> leo thang xử lý
18
19LỖI LẶP LẠI KHÔNG THAY ĐỔI
20-> dừng

Một vòng lặp agent hữu ích sẽ trông như thế này:

1QUAN SÁT
2   |
3   v
4QUYẾT ĐỊNH
5   |
6   v
7HÀNH ĐỘNG
8   |
9   v
10ĐO LƯỜNG
11   |
12   +---- CHẤP NHẬN
13   |
14   +---- SỬA LỖI
15   |
16   +---- LEO THANG
17   |
18   +---- DỪNG

Mỗi vòng lặp đều cần giới hạn về số lần thử, thời gian, chi phí và phạm vi tác động.

Một agent đáng tin cậy cần biết cách tiếp tục.

Nó cũng cần biết khi nào việc thử thêm không còn đáng nữa.

10. Biến Chỉ Dẫn Lặp Đi Lặp Lại Thành Hạ Tầng

Giả sử prompt có dòng:

Luôn chạy formatter.

Quy tắc đó sẽ mạnh hơn nhiều nếu formatter tự động chạy.

Giả sử chỉ dẫn ghi:

Code UI không được truy cập trực tiếp vào database.

Điều đó sẽ mạnh hơn nếu biến thành một architecture test tự báo lỗi khi quy tắc bị vi phạm.

Quá trình tiến hóa diễn ra như sau:

1GIẢI THÍCH
2      |
3      v
4CHECKLIST
5      |
6      v
7TEMPLATE
8      |
9      v
10KIỂM TRA TỰ ĐỘNG
11      |
12      v
13POLICY BẮT BUỘC

Prompt nên giải thích cách phán đoán.

Harness nên thực thi các bất biến.

Mỗi lỗi lặp đi lặp lại nên được đẩy xuống một bậc trong thang này.

Cuối cùng, model không cần phải nhớ bài học đó nữa.

Môi trường sẽ nhớ thay cho model.

11. Ghi Lại Quá Trình Chạy

Một artifact cuối cùng hoàn hảo có thể che giấu một luồng thực thi thảm họa.

Có thể agent đã truy cập sai nguồn.

Có thể nó phớt lờ một lệnh bị lỗi.

Có thể nó lặp lại một hành động bên ngoài tới hai lần.

Có thể nó tiêu tốn gấp mười lần ngân sách dự kiến.

Có thể nó ra đáp án đúng nhưng vì lý do sai.

Hãy ghi lại đủ thông tin để dựng lại những gì đã xảy ra.

109:14  tạo hợp đồng task
209:15  tải architecture.md
309:17  chỉnh sửa checkout.ts
409:18  test cục bộ thất bại
509:21  sửa lại phần triển khai
609:22  test cục bộ đạt
709:24  integration test đạt
809:25  deploy bị chặn: cần phê duyệt

Log hữu ích bao gồm nguồn context, lệnh gọi tool, thay đổi state, kết quả xác minh, lý do thử lại, quyết định phê duyệt, chi phí và độ trễ.

Mục đích không phải là thu thập log cho vui.

Mục đích là khoanh vùng lỗi.

Nếu bước 18 hỏng, bạn phải sửa được bước 18.

Bạn không nên phải chạy lại toàn bộ quá trình.

12. Cấp Biên Lai Cho Mỗi Lần Chạy

Đừng ép con người phải đọc lại đoạn chat dài bốn mươi tin nhắn.

Hãy tổng hợp kết quả thành một biên lai ngắn gọn.

1MỤC TIÊU
2
3Sửa lỗi áp dụng coupon trùng lặp.
4
5ĐÃ THAY ĐỔI
6
7xác thực checkout
8regression test
9
10ĐÃ XÁC MINH
11
12lint đạt
13unit test đạt
14integration test đạt
15
16CHƯA XÁC MINH
17
18nhà cung cấp thanh toán trên production
19
20RỦI RO
21
22client mobile đời cũ không khả dụng
23
24CẦN PHÊ DUYỆT
25
26deploy lên staging

Đây không phải bản tóm tắt những gì model tự nhận là đã làm.

Đây là bản tóm tắt những gì harness có thể chứng minh là đã xảy ra.

Chính sự khác biệt đó giúp biên lai trở nên hữu ích cho việc review, bàn giao và các session agent sau này.

13. Để Mỗi Thất Bại Giúp Harness Tốt Hơn

Hầu hết các team chỉ sửa output bị lỗi.

Cách tốt hơn là sửa cái hệ thống đã để lỗi đó xảy ra.

1THIẾU CONTEXT
2-> cải thiện bản đồ dự án
3
4SAI CÔNG CỤ
5-> cải thiện routing hoặc hợp đồng tool
6
7OUTPUT TỆ
8-> thêm validator
9
10VÒNG LẶP VÔ TẬN
11-> thêm giới hạn retry
12
13HÀNH ĐỘNG KHÔNG AN TOÀN
14-> thêm cổng kiểm soát quyền
15
16MẤT QUYẾT ĐỊNH
17-> lưu state bền vững
18
19LỖI CHƯA RÕ NGUYÊN NHÂN
20-> cải thiện tracing

Đây là lúc Harness Engineering bắt đầu phát huy sức mạnh cộng gộp.

Sửa một output chỉ giúp được một lần chạy.

Sửa một harness sẽ cải thiện mọi lần chạy sau đó.

Những hệ thống agent tốt nhất ngày càng đáng tin cậy vì mỗi lỗi để lại một mảnh hạ tầng phía sau.

14. Bắt Đầu Với Harness Hữu Ích Nhỏ Nhất

Bạn không cần một nền tảng orchestration khổng lồ để bắt đầu.

Hãy xây dựng theo từng lớp.

1LEVEL 0
2
3prompt
4model
5
6LEVEL 1
7
8hợp đồng task
9bản đồ dự án
10công cụ
11
12LEVEL 2
13
14state có cấu trúc
15xác minh
16vòng lặp có giới hạn
17
18LEVEL 3
19
20quyền hạn
21log vết
22phục hồi
23cổng kiểm soát của con người

Một task nghiên cứu ngắn có thể chỉ cần prompt và một lần review.

Một task code kéo dài sáu tiếng có quyền truy cập file, mạng và khả năng deploy thì cần nhiều hơn thế.

Chỉ thêm độ phức tạp khi bề mặt lỗi đòi hỏi điều đó.

Chứ không phải vì kiến trúc agent trông có vẻ ngầu.

Checklist Harness Engineering

Trước khi trao cho agent quyền tự chủ thực sự, hãy tự hỏi:

1[ ] Tiêu chí thành công đã được định nghĩa trước khi thực thi chưa?
2
3[ ] Agent có tìm được đúng context
4    mà không cần tải mọi thứ không?
5
6[ ] Mỗi công cụ có mục đích,
7    schema và trạng thái lỗi rõ ràng không?
8
9[ ] Các quyết định quan trọng có được lưu
10    ngoài cuộc hội thoại không?
11
12[ ] Việc hoàn thành có yêu cầu bằng chứng không?
13
14[ ] Các hành động rủi ro có được bảo vệ bởi policy không?
15
16[ ] Mỗi vòng lặp có giới hạn retry không?
17
18[ ] Quá trình chạy có thể tiếp tục sau khi bị gián đoạn không?
19
20[ ] Bạn có thể dựng lại mọi hành động quan trọng không?
21
22[ ] Thất bại có giúp cải thiện quy tắc, công cụ,
23    test, bản đồ hay quyền hạn không?
24
25[ ] Thay đổi cuối cùng có thể rollback không?

Nếu nhiều câu trả lời là không, một model mạnh hơn sẽ không tự động làm agent đáng tin cậy hơn.

Nó có thể chỉ khiến lỗi xảy ra nhanh hơn và tốn kém hơn.

Sự Chuyển Dịch Thực Sự

Prompt engineering hỏi:

Tôi nên nói gì với model?

Context engineering hỏi:

Model nên biết gì ngay lúc này?

Harness engineering hỏi:

Hệ thống nào cho phép model hành động, xác minh công việc, phục hồi sau lỗi và vận hành an toàn?

1PROMPT
2-> chỉ thị
3
4CONTEXT
5-> góc nhìn làm việc
6
7HARNESS
8-> môi trường vận hành
9
10LOOP
11-> điều chỉnh cục bộ
12
13GRAPH
14-> phối hợp

Các model sẽ liên tục thay đổi.

Lợi thế bền vững nằm ở phần bao quanh chúng.

Hợp đồng của bạn tốt hơn.

Công cụ của bạn tốt hơn.

Test của bạn tốt hơn.

State của bạn sạch hơn.

Quyền hạn của bạn an toàn hơn.

Logic phục hồi của bạn thông minh hơn.

Thất bại của bạn biến thành hạ tầng.

Đó là cách các model mạnh mẽ trở thành agent đáng tin cậy.

Đó chính là Harness Engineering.

Nếu Bạn Đã Đọc Đến Đây

Hãy lưu lại hướng dẫn này.

Theo dõi tôi trên X: x.com/0xjmori

Đăng ký Substack của tôi: substack.com/@lunarresearcher

Gửi bài viết này cho ai đó vẫn đang cố sửa mọi lỗi của agent bằng một prompt dài hơn.