Harness Engineering: Hướng dẫn toàn diện về cách xây dựng các AI Agent bền vững

Hầu hết mọi người đang cố gắng cải thiện 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 hướng dẫn hơn.

Trước khi chúng ta bắt đầu:

Theo dõi Substack của tôi để nhận thông tin mới nhất về AI, quy trình làm việc của agent và hướng dẫn từng bước trước khi chúng được đăng lên X: [https://substack.com/@lunarresearcher

Sau đó, họ chuyển đổi mô hình, thêm nhiều công cụ hơn, tăng cửa sổ ngữ cảnh và hy vọng lần chạy tiếp theo sẽ hoạt động khác đi.

Nhưng nhiều thất bại của agent không phải là thất bại về lý luận.

Chúng là thất bại về môi trường.

Agent không biết tệp nào quan trọng.

Nó đã sử dụng đúng công cụ nhưng sai vị trí.

Nó đã đánh mất các quyết định được đưa ra trong phiên trước đó.

Nó tuyên bố thành công mà không chạy các bước kiểm tra.

Nó lặp lại một hành động sau một thất bại một phần.

Nó có quyền làm điều gì đó đáng lẽ phải cần sự chấp thuận.

Mô hình không nhất thiết là vấn đề. Hệ thống xung quanh mô hình chưa hoàn chỉnh.

Hệ thống đó là harness.

Và thiết kế nó đang trở thành một ngành kỹ thuật riêng.

Kỹ thuật Harness là việc xây dựng môi trường biến trí thông minh của mô hình thành công việc đáng tin cậy.

Một prompt thay đổi một lần thử.

Một harness thay đổi mọi lần thử.

Hướng dẫn này giải thích cách xây dựng một harness.

1. Mô Hình Không Phải Là Agent

Một mô hình có thể lý luận, tạo ra, so sánh và lựa chọn.

Nhưng một agent cũng phải tương tác với một môi trường thực tế.

Nó cần phải:

• hiểu nhiệm vụ
• tìm ngữ cảnh liên quan
• chọn và sử dụng công cụ
• duy trì trạng thái
• tuân thủ quyền hạn
• kiểm tra kết quả
• phục hồi sau thất bại
• chứng minh rằng công việc đã hoàn thành

Mô hình là động cơ lý luận bên trong hệ thống đó.

Harness là tất cả những thứ làm cho khả năng lý luận đó hoạt động được.

1yêu cầu người dùng
2     |
3     v
4+-----------------------------+
5|           HARNESS           |
6| hợp đồng | ngữ cảnh | chính sách |
7| công cụ  | trạng thái | kiểm tra |
8| dấu vết  | phục hồi            |
9+-----------------------------+
10     |
11     v
12    mô hình
13     |
14     v
15môi trường thực tế

Một mô hình mạnh mẽ bên trong một harness yếu vẫn là một agent yếu.

Nó có thể tạo ra các phản hồi riêng lẻ ấn tượng, nhưng nó sẽ hoạt động không nhất quán trong các tác vụ dài, môi trường thay đổi và các thất bại một phần.

Mục tiêu của kỹ thuật harness không phải là loại bỏ sự không chắc chắn khỏi mô hình.

Mà là chứa đựng sự không chắc chắn đó bên trong một hệ thống có thể quan sát, xác minh và phục hồi.

2. Bắt Đầu Với Một Hợp Đồng Nhiệm Vụ

Hầu hết các nhiệm vụ của agent bắt đầu như một ý định mơ hồ:

Cải thiện luồng đăng ký.

Câu nói đó có thể đủ cho một cuộc trò chuyện.

Nó không đủ để thực thi tự động.

Trước khi agent hành động, harness nên chuyển đổi yêu cầu thành một hợp đồng nhiệm vụ.

Một hợp đồng hữu ích trả lời năm câu hỏi:

1. Kết quả nào phải tồn tại?
2. Những gì nằm trong phạm vi?
3. Những gì không được thay đổi?
4. Bằng chứng nào chứng minh sự hoàn thành?
5. Hành động nào yêu cầu sự chấp thuận của con người?

1mục_tiêu: giảm tỷ lệ bỏ cuộc khi đăng ký
2
3phạm_vi:
4  - luồng đăng ký
5  - phân tích đăng ký
6
7ràng_buộc:
8  - không thay đổi xác thực
9  - giữ nguyên hành vi trên thiết bị di động hiện tại
10
11chấp_nhận:
12  - các bài kiểm tra đều đạt
13  - sự kiện phân tích được phát ra
14  - ảnh chụp màn hình bao gồm cả desktop và di động
15
16yêu_cầu_chấp_thuận:
17  - triển khai lên production
18  - di chuyển cơ sở dữ liệu

Điều này thay đổi câu hỏi của agent từ:

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

thành:

Hành động nào đưa môi trường đến gần hơn với kết quả đã hợp đồng?

Nếu không có hợp đồng, agent sẽ tối ưu hóa cho các hoạt động có vẻ hợp lý.

Với hợp đồng, nó có thể tối ưu hóa cho việc hoàn thành đã được xác minh.

3. Cung Cấp Cho Agent Một Bản Đồ, Không Phải Một Cuốn Sách Hướng Dẫn

Đổ toàn bộ kho lưu trữ, bộ tài liệu và lịch sử hội thoại vào ngữ cảnh không phải là kỹ thuật ngữ cảnh tốt.

Đó là làm ngập ngữ cảnh.

Harness nên cung cấp một bản đồ nhỏ trước, sau đó để agent truy xuất chi tiết khi chúng trở nên phù hợp.

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/
7kiểm thử             -> tests/
8lệnh                 -> docs/commands.md
9quy tắc phát hành    -> docs/release.md

Đây là sự tiết lộ dần dần:

1nhiệm vụ
2  -> bản đồ dự án
3      -> hệ thống con liên quan
4          -> các tệp chính xác
5              -> hướng dẫn cục bộ

Ngữ cảnh nên mở rộng vì nhiệm vụ yêu cầu, không phải vì thông tin tồn tại.

Một trình biên dịch ngữ cảnh tốt quyết định:

• cái gì luôn cần thiết
• cái gì có thể truy xuất sau
• cái gì đã trở nên lỗi thời
• cái gì có thể tóm tắt
• cái gì phải giữ nguyên văn

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

Mà là tín hiệu tối đa trên mỗi token.

4. Xây Dựng Một Cổng Công Cụ, Không Phải Một Đống Công Cụ

Cung cấp cho agent hai mươi công cụ không làm cho nó có năng lực hơn.

Nó cho agent hai mươi cách để phạm sai lầm.

Mọi công cụ nên có một hợp đồng rõ ràng:

1CÔNG CỤ: edit_file
2
3đầu vào:
4  đường_dẫn
5  bản_vá
6
7điều_kiện_tiên_quyết:
8  đường_dẫn tồn tại
9  đường_dẫn nằm trong không gian làm việc được phép
10
11bằng_chứng_thành_công:
12  bản_vá được áp dụng
13  diff kết quả được trả về
14
15hành_vi_khi_thất_bại:
16  không ghi đè một phần
17  lỗi có cấu trúc được trả về
18
19lớp_rủi_ro:
20  có thể đảo ngược

Harness nên kiểm soát cách các công cụ được hiển thị và sử dụng.

Nó có thể:

• ẩn các công cụ không liên quan
• xác thực đối số
• hạn chế đường dẫn và tên miền
• đính kèm thời gian chờ
• làm cho các lần thử lại có tính chất lũy đẳng (idempotent)
• chuẩn hóa đầu ra
• yêu cầu xác nhận cho các hành động rủi ro
• trả về bằng chứng, không chỉ "thành công"

Điều này tạo ra một sự tách biệt quan trọng:

1mô hình quyết định ý định
2cổng xác thực hành động
3công cụ thay đổi môi trường
4cảm biến quan sát kết quả

Mô hình có thể đề xuất một hành động.

Cổng công cụ quyết định xem hành động đó có đủ hợp lệ để thực thi hay không.

5. Tách Biệt Bộ Não, Đôi Tay và Lịch Sử

Nhiều agent mong manh trộn lẫn mọi thứ vào một bản ghi ngày càng dài.

Lý luận, lệnh gọi công cụ, tệp, quyết định, lỗi và các quan sát cũ đều cạnh tranh cho cùng một cửa sổ ngữ cảnh.

Một hệ thống mạnh mẽ hơn sẽ tách biệt ba trách nhiệm:

1BỘ NÃO
2lập kế hoạch, lý luận, lựa chọn
3
4ĐÔI TAY
5thực thi các công cụ trong một môi trường được kiểm soát
6
7LỊCH SỬ
8lưu trữ các sự kiện, quyết định và trạng thái chạy bền vững

Mô hình không cần mọi sự kiện thô trong ngữ cảnh hoạt động.

Nó cần trạng thái hiện tại phù hợp.

Sandbox không cần hiểu toàn bộ mục tiêu.

Nó cần thực thi an toàn một hành động có giới hạn.

Nhật ký phiên không cần phải lý luận.

Nó cần bảo tồn những gì đã xảy ra sau khi ngữ cảnh hiện tại biến mất.

Sự tách biệt này làm cho các agent chạy dài dễ dàng tiếp tục, kiểm tra và sửa chữa hơn.

Nó cũng cho phép bạn thay thế một phần mà không cần xây dựng lại toàn bộ hệ thống.

6. Bộ Nhớ Phải Trở Thành Trạng Thái Bền Vững

Lịch sử hội thoại không phải là bộ nhớ đáng tin cậy.

Nó là một luồng sự kiện.

Bộ nhớ hữu ích nên được chuyển đổi thành trạng thái rõ ràng.

Tối thiểu, hãy bảo tồn bốn loại:

1SỰ KIỆN
2thông tin ổn định được khám phá về môi trường
3
4QUYẾT ĐỊNH
5các lựa chọn đã được đưa ra và lý do đằng sau chúng
6
7TIẾN ĐỘ
8công việc đã hoàn thành, đang hoạt động, bị chặn và còn lại
9
10BÀI HỌC
11những thất bại sẽ thay đổi hành vi trong tương lai

Ví dụ:

1sự_kiện:
2  - logic xác thực thanh toán nằm trong services/orders
3
4quyết_định:
5  - tái sử dụng pipeline xác thực hiện có
6  - lý_do: tránh nguồn sự thật thứ hai
7
8tiến_độ:
9  đã_hoàn_thành:
10    - thêm quy tắc phía máy chủ
11  còn_lại:
12    - cập nhật kiểm thử tích hợp
13
14bài_học:
15  - lệnh kiểm thử cục bộ yêu cầu TEST_DB_URL

Điều này hữu ích hơn nhiều so với việc phát lại năm mươi trang bản ghi và hy vọng mô hình chú ý đến dòng quan trọng.

Lưu trữ lịch sử thô để kiểm toán.

Biên dịch trạng thái bền vững để thực thi.

7. Hoàn Thành Yêu Cầu Bằng Chứng

Một agent nói "xong" không phải là bằng chứng cho thấy nhiệm vụ đã hoàn thành.

Nó chỉ là một đầu ra khác của mô hình.

Sự hoàn thành phải được quyết định bởi những thay đổi có thể quan sát được trong môi trường.

1tuyên bố                         bằng chứng
2--------------------------------------------------
3"lỗi đã được sửa"               bài kiểm tra thất bại bây giờ đã đạt
4"trang hoạt động"               luồng trình duyệt đã hoàn thành
5"việc di chuyển an toàn"        chạy thử và rollback đều đạt
6"báo cáo chính xác"             các giá trị khớp với dữ liệu nguồn
7"nhiệm vụ đã hoàn thành"        mọi kiểm tra chấp nhận đều đạt

Harness nên chạy các kiểm tra xác định rẻ nhất trước.

1cú pháp
2  -> kiểu dữ liệu
3      -> kiểm thử tập trung
4          -> kiểm thử tích hợp
5              -> đánh giá trực quan hoặc ngữ nghĩa
6                  -> phê duyệt của con người

Đừng sử dụng một mô hình khác khi trình biên dịch, lược đồ, tổng kiểm tra, truy vấn hoặc bài kiểm tra có thể trả lời câu hỏi.

Sử dụng mô hình cho sự mơ hồ.

Sử dụng mã cho các kết nối hệ thống.

Một mô hình có thể đề xuất rằng nhiệm vụ đã hoàn thành.

Chỉ có môi trường mới có thể chứng minh điều đó.

8. Việc Xác Minh Nên Tấn Công Kết Quả

Người thực hiện và người đánh giá không nên chia sẻ cùng một mục tiêu.

Người thực hiện cố gắng tạo ra giải pháp mạnh nhất.

Người đánh giá cố gắng tìm ra lý do tại sao nó nên bị từ chối.

1người thực hiện
2  -> tạo ra ứng viên
3
4người xác minh
5  -> kiểm tra hợp đồng
6  -> tìm kiếm các trường hợp còn thiếu
7  -> kiểm tra các tuyên bố không được hỗ trợ
8  -> cố gắng phá vỡ kết quả
9
10sống sót
11  -> chấp nhận
12
13thất bại
14  -> trả về bằng chứng có mục tiêu

Sự bất đối xứng này rất quan trọng.

Nếu bạn yêu cầu cùng một agent, trong cùng một ngữ cảnh, "kiểm tra lại công việc của nó", nó thường giữ nguyên các giả định đã tạo ra sai lầm.

Một giai đoạn xác minh hữu ích nên có:

• một tiêu chí từ chối rõ ràng
• quyền truy cập vào sản phẩm đã tạo
• quyền truy cập vào hợp đồng chấp nhận
• các công cụ độc lập hoặc ngữ cảnh mới khi cần
• quyền từ chối mà không cần sửa chữa

Xác minh không phải là một ý kiến thứ hai.

Nó là một nỗ lực bác bỏ.

9. Mô Hình Đề Xuất, Chính Sách Cho Phép

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

1không bao giờ xuất bản nếu không có sự chấp thuận
2không bao giờ để lộ bí mật
3không bao giờ ghi bên ngoài không gian làm việc
4không bao giờ vượt quá giới hạn chi tiêu
5không bao giờ đánh dấu bài kiểm tra là đạt trừ khi chúng đã chạy

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

Chúng là chính sách.

Thiết kế an toàn nhất giữ chính sách bên ngoài vòng lặp lý luận.

1RỦI RO THẤP
2đọc tệp, tìm kiếm, kiểm tra
3-> tự động
4
5THAY ĐỔI CÓ THỂ ĐẢO NGƯỢC
6chỉnh sửa không gian làm việc, chạy kiểm thử
7-> tự động với dấu vết
8
9TÁC ĐỘNG BÊN NGOÀI
10gửi tin nhắn, triển khai, mua hàng
11-> phê duyệt rõ ràng
12
13KHÔNG THỂ ĐẢO NGƯỢC HOẶC NHẠY CẢM
14xóa dữ liệu, xoay vòng thông tin xác thực, xuất bản toàn cầu
15-> cổng cứng hoặc bị cấm

Hậu quả càng lớn, cổng càng khó.

Tự chủ không phải là không có kiểm soát.

Đó là khả năng hoạt động tự do bên trong một ranh giới được thực thi rõ ràng.

10. Phục Hồi Nên Nhắm Vào Lớp Thất Bại

Chiến lược phục hồi phổ biến nhất là:

Điều gì đó đã thất bại. Thử lại.

Đó không phải là phục hồi.

Đó là sự lặp lại.

Harness nên phân loại thất bại trước khi chọn hành động tiếp theo.

1công cụ hết thời gian chờ
2-> thử lại với backoff
3
4đối số không hợp lệ
5-> sửa lệnh gọi công cụ
6
7thiếu ngữ cảnh
8-> truy xuất nguồn cụ thể
9
10kiểm thử thất bại
11-> kiểm tra hành vi thất bại
12
13từ chối quyền
14-> yêu cầu phê duyệt hoặc chọn đường đi an toàn
15
16yêu cầu mâu thuẫn
17-> chuyển lên con người
18
19thất bại lặp lại không thay đổi
20-> dừng vòng lặp

Một lần thử lại nên thay đổi ít nhất một điều kiện liên quan.

Nếu không, hệ thống đang trả tiền để tái tạo cùng một thất bại.

Một vòng lặp agent có giới hạn trông như thế này:

1quan sát
2  -> quyết định
3      -> hành động
4          -> đo lường
5              -> chấp nhận
6              -> sửa chữa
7              -> chuyển lên
8              -> dừng

Mọi vòng lặp cần một ngân sách:

• số lần thử tối đa
• thời gian tối đa
• chi tiêu tối đa
• phạm vi phá hủy tối đa
• điều kiện chuyển lên

Các agent đáng tin cậy biết cách tiếp tục.

Chúng cũng biết khi nào việc tiếp tục không còn hợp lý nữa.

11. Hướng Dẫn Nên Trở Thành Cơ Sở Hạ Tầng

Hướng dẫn cho agent rất hữu ích khi chúng giải thích thực tế cục bộ.

Nhưng chỉ riêng hướng dẫn là sự thực thi yếu.

Nếu một quy tắc quan trọng lặp đi lặp lại, hãy di chuyển nó xuống dưới ngăn xếp.

1"sử dụng trình định dạng"
2-> chạy trình định dạng tự động
3
4"không import qua các tầng"
5-> thêm kiểm thử kiến trúc
6
7"bao gồm một rollback di chuyển"
8-> yêu cầu tệp rollback trong CI
9
10"không sửa đổi các tệp được tạo ra"
11-> chặn ghi vào các đường dẫn được tạo ra
12
13"trích dẫn mọi tuyên bố bên ngoài"
14-> xác thực phạm vi trích dẫn

Điều này tạo ra một bậc thang hướng dẫn:

1giải thích
2  -> danh sách kiểm tra
3      -> mẫu
4          -> kiểm tra tự động
5              -> chính sách được thực thi

Di chuyển kiến thức quan trọng càng xa xuống bậc thang đó càng thực tế.

Prompt nên giải thích sự phán xét.

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

12. Quan Sát Quá Trình Chạy, Không Chỉ Kết Quả Cuối Cùng

Một sản phẩm cuối cùng sạch sẽ có thể che giấu một quy trình tồi tệ.

Agent có thể đã:

• truy cập sai dữ liệu
• bỏ qua một lệnh thất bại
• thử lại một hành động bên ngoài hai lần
• tiêu thụ gấp mười lần ngân sách dự kiến
• đạt được câu trả lời đúng vì lý do sai

Bạn cần các dấu vết làm cho quá trình chạy có thể tái tạo lại được.

109:14  hợp đồng được tạo
209:15  nguồn ngữ cảnh đã tải: architecture.md
309:17  tệp đã chỉnh sửa: checkout.ts
409:18  kiểm thử tập trung thất bại: phiếu giảm giá trùng lặp
509:21  triển khai đã được sửa chữa
609:22  kiểm thử tập trung đã đạt
709:24  kiểm thử tích hợp đã đạt
809:25  triển khai bên ngoài bị chặn: yêu cầu phê duyệt

Một dấu vết hữu ích ghi lại:

• chuyển đổi trạng thái
• nguồn ngữ cảnh
• đầu vào và đầu ra của công cụ
• thay đổi môi trường
• kết quả xác minh
• lý do thử lại
• quyết định phê duyệt
• chi phí và độ trễ

Mục tiêu không phải là giám sát.

Mục tiêu là sửa chữa cục bộ.

Khi một lần chạy thất bại ở bước 18, bạn sẽ có thể khởi động lại từ một điểm kiểm tra đáng tin cậy thay vì phát lại toàn bộ nhiệm vụ.

13. Mọi Lần Chạy Cần Một Biên Lai Thay Đổi

Các bản ghi agent dài rất khó để xem xét.

Khi kết thúc một lần chạy, harness nên biên dịch một biên lai thay đổi nhỏ.

1MỤC TIÊU
2Sửa lỗi áp dụng phiếu giảm giá trùng lặp trong quá trình thanh toán.
3
4ĐÃ THAY ĐỔI
5- logic xác thực thanh toán
6- kiểm thử hồi quy tập trung
7
8ĐÃ XÁC MINH
9- lint đã đạt
10- kiểm thử đơn vị đã đạt
11- kiểm thử tích hợp thanh toán đã đạt
12
13CHƯA XÁC MINH
14- nhà cung cấp thanh toán production
15
16QUYẾT ĐỊNH
17- giữ nguyên thứ tự ưu tiên phiếu giảm giá hiện có
18
19RỦI RO
20- ứng dụng di động cũ không có sẵn ở môi trường cục bộ
21
22CẦN PHÊ DUYỆT
23- triển khai lên staging

Biên lai không phải là bản tóm tắt những gì mô hình đã nói.

Nó là bản tóm tắt những gì hệ thống có thể chứng minh.

Điều này cung cấp cho con người một bề mặt xem xét nhỏ gọn và cung cấp cho phiên agent tiếp theo một điểm khởi đầu đáng tin cậy.

Sự bàn giao tốt nhất không phải là "đây là cuộc trò chuyện."

Nó là "đây là trạng thái, bằng chứng và rủi ro chưa được giải quyết."

14. Mọi Thất Bại Nên Nâng Cấp Harness

Các nhóm yếu nhất sửa đầu ra thất bại.

Các nhóm mạnh nhất cũng sửa hệ thống đã cho phép nó.

Sau một thất bại, hãy hỏi:

1Hợp đồng nhiệm vụ có mơ hồ không?
2Ngữ cảnh quan trọng có bị vô hình không?
3Công cụ sai có được hiển thị không?
4Một điều kiện tiên quyết có bị thiếu không?
5Kết quả có không thể xác minh được không?
6Chính sách có bị bỏ lại trong prompt không?
7Việc phục hồi có quá rộng không?
8Dấu vết có không đủ không?

Sau đó, chuyển đổi bài học thành một cải tiến có thể tái sử dụng.

1thất bại
2  -> chẩn đoán
3      -> cảm biến, quy tắc, bản đồ, kiểm thử hoặc hợp đồng công cụ mới
4          -> các lần chạy trong tương lai tự động cải thiện

Đây là bánh đà của harness.

Hệ thống trở nên đáng tin cậy hơn vì các thất bại để lại cơ sở hạ tầng phía sau.

Một câu trả lời được sửa chữa giúp ích cho một lần chạy.

Một harness được sửa chữa giúp ích cho mọi lần chạy trong tương lai.

15. Harness Cũng Suy Thoái

Nhiều harness hơn không phải lúc nào cũng tốt hơn.

Các mô hình cải thiện. Các công cụ cải thiện. Các nhiệm vụ thay đổi. Các biện pháp bảo vệ cũ có thể trở thành ma sát không cần thiết.

Một giải pháp thay thế được tạo ra cho mô hình của ngày hôm qua có thể ngăn mô hình của ngày hôm nay sử dụng một chiến lược tốt hơn.

Điều này tạo ra sự suy thoái harness:

1hạn chế của mô hình cũ
2  -> giải pháp thay thế của harness
3      -> mô hình cải thiện
4          -> giải pháp thay thế vẫn còn
5              -> hệ thống trở nên chậm hơn hoặc kém năng lực hơn

Hãy đối xử với các thành phần của harness như mã production.

Đo lường xem chúng có còn mang lại lợi ích hay không.

Đối với mọi bộ định tuyến, người đánh giá, lớp bộ nhớ và quy tắc thử lại, hãy hỏi:

• Thất bại nào mà điều này ngăn chặn?
• Thất bại đó vẫn xảy ra thường xuyên như thế nào?
• Điều này thêm độ trễ và độ phức tạp nào?
• Kết quả tương tự có thể đạt được một cách đơn giản hơn bây giờ không?
• Điều gì xảy ra nếu chúng ta loại bỏ nó?

Harness tốt nhất không phải là cái lớn nhất.

Nó là hệ thống nhỏ nhất thu hẹp khoảng cách giữa ý định và bằng chứng một cách đáng tin cậy.

Xây dựng để xóa bỏ.

16. Harness Khả Thi Tối Thiểu

Bạn không cần một nền tảng điều phối để bắt đầu.

Xây dựng harness theo từng lớp.

Cấp độ 1: Một nhiệm vụ có giới hạn

• mục tiêu
• phạm vi
• ràng buộc
• kiểm tra chấp nhận

Cấp độ 2: Một môi trường dễ đọc

• bản đồ dự án
• lệnh
• hướng dẫn cục bộ
• các phụ thuộc đã biết

Cấp độ 3: Các hành động được kiểm soát

• công cụ có kiểu dữ liệu
• xác thực đối số
• ranh giới đường dẫn và quyền
• kết quả có cấu trúc

Cấp độ 4: Thực thi bền vững

• trạng thái chạy rõ ràng
• điểm kiểm tra
• quyết định
• bài học

Cấp độ 5: Bằng chứng

• kiểm tra xác định
• xác minh đối nghịch
• biên lai thay đổi

Cấp độ 6: Phục hồi và học hỏi

• phân loại thất bại
• thử lại có giới hạn
• chuyển lên
• cập nhật harness từ các thất bại tái diễn

Xây dựng lớp nhỏ nhất loại bỏ thất bại mà bạn thực sự gặp phải.

Đừng bắt đầu với một kiến trúc đa agent vì một prompt đơn lẻ thỉnh thoảng cần làm rõ.

Sự phức tạp nên được kiếm được bằng thất bại quan sát được.

17. Một Đặc Tả Harness Có Thể Tái Sử Dụng

Trước khi trao cho agent quyền tự chủ có ý nghĩa, hãy xác định điều này:

1ĐẶC TẢ HARNESS AGENT
2
31. HỢP ĐỒNG
4   mục tiêu:
5   phạm vi:
6   ràng buộc:
7   bằng chứng chấp nhận:
8
92. NGỮ CẢNH
10   bản đồ luôn tải:
11   nguồn truy xuất:
12   hướng dẫn cục bộ:
13   quy tắc tươi mới:
14
153. CÔNG CỤ
16   công cụ được phép:
17   điều kiện tiên quyết:
18   tác dụng phụ:
19   bằng chứng thành công:
20   chính sách thời gian chờ và thử lại:
21
224. TRẠNG THÁI
23   sự kiện:
24   quyết định:
25   tiến độ:
26   bài học:
27   định dạng điểm kiểm tra:
28
295. CHÍNH SÁCH
30   hành động tự động:
31   hành động yêu cầu phê duyệt:
32   hành động bị cấm:
33   giới hạn ngân sách:
34
356. XÁC MINH
36   kiểm tra xác định:
37   kiểm tra đối nghịch:
38   quy tắc chấp nhận:
39
407. PHỤC HỒI
41   các lớp thất bại:
42   giới hạn thử lại:
43   điều kiện chuyển lên:
44   rollback an toàn:
45
468. KHẢ NĂNG QUAN SÁT
47   sự kiện dấu vết:
48   số liệu:
49   biên lai thay đổi cuối cùng:

Nếu các trường này không được xác định, agent không phải là tự động.

Nó đang ứng biến.

18. Đo Lường Hệ Thống Ở Cấp Độ Phù Hợp

Số lượng token không phải là thước đo cuối cùng.

Số lượng nhiệm vụ đã thử cũng vậy.

Đơn vị hữu ích là công việc được chấp nhận.

Một thước đo thực tế là:

1đầu ra được chấp nhận
2------------------------------
3số phút xem xét của con người + chi phí chạy

Cũng theo dõi:

• tỷ lệ chấp nhận lần đầu
• tỷ lệ phục hồi sau thất bại công cụ
• tỷ lệ thất bại lặp lại
• sự can thiệp của con người trên mỗi nhiệm vụ
• tuyên bố hoàn thành không được hỗ trợ
• thời gian từ yêu cầu đến kết quả đã xác minh
• chi phí harness theo thành phần

Điều này ngăn chặn một ảo tưởng phổ biến:

Một agent có thể trông rất năng suất trong khi tạo ra công việc xem xét tốn kém.

Mục tiêu không phải là nhiều hoạt động agent hơn.

Mà là nhiều kết quả đáng tin cậy hơn trên mỗi đơn vị sự chú ý của con người.

19. Khi Nào Bạn Không Cần Một Harness Nặng

Không phải mọi lệnh gọi mô hình đều cần một hệ điều hành.

Sử dụng một prompt đơn giản khi:

• nhiệm vụ ngắn
• đầu ra dễ kiểm tra
• thất bại rẻ
• không có tác dụng phụ bên ngoài nào xảy ra
• người dùng vẫn ở trong vòng lặp

Thêm một harness khi:

• công việc kéo dài nhiều công cụ hoặc phiên
• môi trường có thể thay đổi
• hành động có hậu quả thực tế
• khó đánh giá sự hoàn thành bằng tay
• cùng một thất bại xuất hiện lặp đi lặp lại
• việc xem xét của con người trở thành nút thắt cổ chai

Mục đích của một harness không phải là làm cho một bản demo trông tinh vi.

Nó là để làm cho công việc thực tế trở nên đáng tin cậy.

Sự Thay Đổi Thực Sự

Thế hệ sản phẩm AI đầu tiên được xây dựng xung quanh các prompt.

Thế hệ tiếp theo đang được xây dựng xung quanh các môi trường.

Câu hỏi không còn chỉ là:

Làm thế nào để chúng ta làm cho câu trả lời của mô hình tốt hơn?

Nó là:

Làm thế nào để chúng ta xây dựng một hệ thống nơi các hành động tốt là dễ dàng, các hành động nguy hiểm được kiểm soát, các thất bại có thể nhìn thấy và sự hoàn thành có thể chứng minh được?

Đó là sự chuyển đổi từ kỹ thuật prompt sang kỹ thuật harness.

Mô hình cung cấp trí thông minh.

Harness cung cấp cấu trúc.

Cùng nhau, chúng tạo ra sự thực thi đáng tin cậy.

Nếu agent của bạn cứ liên tục thất bại, hãy ngừng thêm các tính từ vào prompt.

Hãy xây dựng môi trường mà nó cần để thành công.

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

Đánh dấu hướng dẫn này.

Theo dõi @LunarResearcher trên X

Đăng ký Substack của tôi

Hãy gửi bài viết này cho ai đó vẫn đang cố gắng sửa mọi thất bại của agent bằng một prompt dài hơn.