Prompt, context, loop và graph engineering hóa ra đều là những mảnh ghép của cùng một cỗ máy. Harness chính là nơi chúng cuối cùng cũng được kết hợp lại với nhau.
Mỗi giai đoạn phát triển trong lĩnh vực xây dựng ứng dụng AI đều có một chức danh riêng. Prompt engineering xuất hiện đầu tiên, khi toàn bộ nghệ thuật này chỉ xoay quanh việc tìm ra câu lệnh phù hợp.
Context engineering theo sau đó, khi mọi người nhận ra rằng câu lệnh không quan trọng bằng tất cả những gì được nạp xung quanh nó. Mùa hè năm nay là thời của loops, và chỉ vài tuần sau, graphs bắt đầu nổi lên.
Cái tên đang lan rộng bây giờ là harness engineering, và đây là khái niệm đầu tiên giải thích được tất cả các khái niệm trước đó.
Harness bao gồm mọi thứ xung quanh mô hình: các công cụ mà nó có thể gọi, các tệp tin nó đọc trước bất kỳ điều gì khác, các thư mục nó được phép ghi vào, các bước kiểm tra mà đầu ra phải vượt qua, lịch trình đánh thức nó và quy tắc kết thúc quá trình chạy.
Mỗi kỷ luật kỹ thuật trước đó hóa ra chỉ là một thành phần đơn lẻ của khung hệ thống này, được xây dựng riêng biệt và đặt tên riêng.
Tôi bắt đầu chú ý đến vấn đề này vì một lý do thực tế. Mô hình nền tảng liên tục thay đổi, đôi khi nhảy tới 17 bậc trên bảng xếp hạng chỉ trong một bản cập nhật, và harness là phần duy nhất của hệ thống thuộc về bạn.
1/ Bảy Kỹ Thuật, Một Cỗ Máy
Kỷ luật
Câu hỏi nó giải quyết
Vị trí trong harness
Prompt engineering
Chính xác thì tôi đang yêu cầu điều gì?
SKILL.md, đặc tả tác vụ được nạp đầu tiên
Context engineering
Mô hình thấy gì ở mỗi bước?
Trình lắp ráp ngữ cảnh: ràng buộc, schema, trang truy xuất
Tool engineering
Nó có thể chạm vào những gì, dưới dạng nào?
Định nghĩa công cụ với input/output có kiểu dữ liệu rõ ràng
Loop engineering
Điều gì khởi động và kết thúc một lần chạy?
Trình chạy (runner): trigger, điều kiện dừng, ngân sách
Graph engineering
Nó nhớ những gì và mọi thứ liên kết như thế nào?
Lớp bộ nhớ: nodes, edges có kiểu dữ liệu, aliases
Eval engineering
Kết quả bị từ chối như thế nào?
Trình xác minh (verifier), nằm ngoài sự kiểm soát của agent
Harness engineering
Điều gì giữ tất cả những thứ trên gắn kết với nhau?
Khung hệ thống, quyền hạn và hooks
Đọc bảng từ trên xuống dưới, đó là một lịch sử. Đọc từ dưới lên trên, đó là một kiến trúc: harness engineering là công việc quyết định vị trí của sáu kỹ thuật còn lại, để không cái nào bị ẩn nấp trong prompt.
Điểm cuối cùng mang sức nặng lớn nhất.
Prompt là nơi dễ nhất để đặt mọi thứ, nên mọi thứ đều trôi dạt vào đó: định dạng đầu ra, quy tắc dừng, những chỉnh sửa của tuần trước, danh sách những thứ agent không bao giờ được đụng vào. Nó hoạt động hoàn hảo trên mô hình bạn viết cho, nhưng rồi mô hình tiếp theo đọc cùng đoạn văn đó theo cách khác.
2/ Giải Phẫu Của Một Harness
Thói quen hữu ích nhất tôi học được là viết toàn bộ harness thành một tệp cấu hình duy nhất, để không điều quan trọng nào bị ngầm định:
1# harness.yaml2model: kimi-k3 # một dòng. mọi thứ bên dưới vẫn sống sót sau khi đổi model3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # hàng đêm, trong khi bạn ngủ12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Ba dòng trong tệp đó làm phần lớn công việc.
model: cố tình chỉ là một dòng. Mọi thứ khác được viết sao cho không quan tâm dòng đó nói gì. Đó chính là toàn bộ câu chuyện về tính di động (portability).
permissions: quan trọng hơn tools:, mặc dù nó nằm thấp hơn trong tệp. Ghi rõ những gì agent được phép thay đổi và những gì nó phải hỏi trước là điều phân biệt giữa một hệ thống bạn để chạy qua đêm và một hệ thống bạn phải ngồi canh chừng.
verify: có hai mục vì một lý do. Script không tốn chi phí và bắt được mọi lỗi cơ học. Reviewer là một agent thứ hai chưa bao giờ thấy agent đầu tiên làm việc, bởi vì một agent tự chấm điểm đầu ra của chính mình sẽ luôn tìm ra lý do để phê duyệt.
Trên đĩa, harness là một thư mục, và mỗi kỹ thuật từ bảng trên đều có địa chỉ riêng trong đó.
3/ Tại Sao Kimi K3 Là Động Cơ Tôi Muốn Đặt Vào Nó
Những gì harness cần
Những gì Kimi K3 mang lại
Một runner có khả năng mở rộng quy mô (fan out)
Agent Swarm: lên tới 300 agents xử lý cùng một vấn đề đồng thời, mà không cần viết orchestrator
Code đủ mạnh để tự viết các bước kiểm tra
Hạng #1 trên Frontend Code Arena với 1.679 điểm, dẫn trước Fable 5 (1.631) và GPT-5.6 Sol (1.618), đứng đầu 6 trong 7 lĩnh vực
Một động cơ cải thiện ngay bên dưới bạn
Từ #18 lên #1 chỉ trong một bản cập nhật tháng Bảy
Dòng đầu tiên quan trọng hơn vẻ ngoài của nó. Hầu hết các harness tự chế đều phát sinh một orchestrator thủ công tại một thời điểm nào đó, và đó thường là tệp dễ vỡ nhất trong thư mục. Với swarm, fan-out trở thành một dòng ngân sách, agents: 300, và harness chỉ cần xử lý những gì quay trở lại.
Dòng thứ hai quan trọng vì harness chủ yếu là code mà mô hình viết cho bạn: hook scripts, schema checks, dashboard nhỏ đọc từ 40-runs. Một động cơ dẫn đầu arena frontend sẽ làm đúng những thứ đó ngay lần thử đầu tiên thường xuyên hơn nhiều.
Dòng thứ ba là lý lẽ cho harness engineering trong một điểm dữ liệu. Khi một mô hình leo 17 bậc qua đêm, harness biến sự leo thang đó thành hiệu quả ngay trong ngày, vì dòng duy nhất cần thay đổi là model.
4/ Hooks: Các Phản Xạ
Hook là một script ngắn mà harness chạy tại một thời điểm cố định, bất kể mô hình quyết định làm gì. Hooks là nơi harness ngừng là một bố cục thư mục và bắt đầu hành xử như một hệ thống an toàn.
Hook
Khi nào kích hoạt
Nó làm gì
pre_tool
Trước bất kỳ lệnh gọi tool nào
Chặn các thao tác ghi ngoài danh sách quyền
post_tool
Sau mỗi lần trả về
Chạy kiểm tra schema và từ chối đầu ra sai định dạng ngay lập tức
pre_send
Trước khi bất cứ thứ gì rời khỏi máy
Giữ nó trong hàng đợi cho đến khi bạn phê duyệt
on_fail
Sau một kết quả bị từ chối
Gắn lý do thất bại vào lần thử lại
post_run
Khi điều kiện dừng đạt được
Thêm hồ sơ chạy vào 40-runs và so sánh đồ thị
Hook pre_tool từ dòng đầu tiên vừa vặn trong năm dòng:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Chỉ riêng hook on_fail đã thay đổi kinh tế học của một vòng lặp. Một lần thử lại mang theo lý do lần thử trước thất bại là một sự sửa chữa. Không có lý do đó, vòng lặp trả giá cho cùng một sai lầm lần thứ hai.
5/ Một Đêm Trông Như Thế Nào
Ghép tất cả các mảnh lại với nhau và harness hành xử như một ca đêm tuân theo các quy tắc. Lúc 02:00, trigger kích hoạt và truy vấn khởi động chọn mọi node cần xử lý. Swarm mở rộng quy mô, một agent cho mỗi node.
Các kết quả trả về không khớp schema bị post_tool từ chối trước khi chúng đến được đồ thị, và mỗi node bị từ chối sẽ thử lại một lần với lý do thất bại được đính kèm. Khi một agent cố gắng ghi ra ngoài thư mục của nó, pre_tool chặn nó mà không đánh thức ai.
Các node đã hợp nhất và edges có kiểu dữ liệu được đưa vào 20-graph. Một email dự thảo đến pre_send và chờ đợi. post_run thêm hồ sơ, và vòng lặp tự dừng theo điều kiện của nó, nằm gọn trong ngân sách 45 phút từ tệp cấu hình.
Lúc 07:30, bạn đọc một tệp và đưa ra hai quyết định. Đó là toàn bộ chi phí buổi sáng cho việc vận hành loop engineering và graph engineering theo cách này, và đó chính là mục đích của harness: mọi thứ có thể chạy mà không cần bạn đều đã chạy xong, và một vài thứ cần bạn đang chờ đợi ở một chỗ.
6/ Bài Kiểm Tra Hoán Đổi (Swap Test)
Cách kiểm toán nhanh nhất cho bất kỳ thiết lập agent nào: thay đổi dòng model và chạy lại. Bất cứ thứ gì hỏng hóc đều là harness đang sống ở sai chỗ.
Điều gì hỏng sau khi hoán đổi
Nó đã ẩn nấp ở đâu
Nó thuộc về đâu
Định dạng đầu ra bị lệch
"luôn trả lời bằng JSON" trong prompt
Một return schema cộng với một script từ chối mọi thứ khác
Các lần chạy ngừng tự kết thúc
"cứ tiếp tục cho đến khi nó kỹ lưỡng"
Một điều kiện dừng dựa trên số đếm
Những chỉnh sửa của tuần trước biến mất
Lịch sử chat
CONSTRAINTS.md, được nạp mỗi lần chạy
Công ty giống nhau xuất hiện ba lần
Phán đoán của mô hình
aliases.csv, được kiểm tra trước khi hợp nhất
Nó ghi vào nơi nó không nên
Một câu lịch sự trong prompt
Một danh sách quyền và một hook pre_tool
Một thiết lập vượt qua bài kiểm tra hoán đổi là có tính di động, và tính di động là thứ khiến nó đáng tiền.
Chi Phí Và Lợi Nhuận
Các công ty dành nguyên quý để xây dựng nền tảng agent nội bộ. Một harness hoạt động tốt chỉ là một thư mục, một tệp cấu hình và năm script ngắn, và nó chạy trên gói đăng ký Kimi. Khoảng cách đó chính là cơ hội.
Kênh
Nó mang lại lợi nhuận
Bạn cần gì trước tiên
Thiết lập harness cho nhóm nhỏ
Phí một lần ở mức bốn chữ số cho cấu hình, hooks và verifier xung quanh quy trình làm việc của họ
Một harness của riêng bạn, chạy theo lịch trình
Dịch vụ retainer ngày phát hành
Phí hàng tháng để chạy bài kiểm tra hoán đổi trên mỗi bản phát hành mô hình lớn và chuyển đội ngũ sang mô hình dẫn đầu
Một khách hàng có các lần chạy đã được ghi log vào 40-runs
Mẫu harness chuyên biệt
Thư mục và yaml được đóng gói cho một ngành: nghiên cứu, tuyển dụng, tuân thủ
Cùng một harness đã được chứng minh ở hai thị trường khác nhau
Kênh thứ hai là kênh tôi sẽ xây dựng đầu tiên. Mỗi bản phát hành lớn đều xáo trộn bảng xếp hạng, riêng K3 đã di chuyển 17 bậc trong một bản cập nhật, và mọi đội ngũ có harness đều cần một người mà công việc là chạy bài kiểm tra hoán đổi vào ngày phát hành.
Phiên Bản Ngắn Gọn
Prompt, context, tool, loop, graph và eval engineering hóa ra đều là các thành phần của một cỗ máy, và harness engineering là việc quyết định vị trí của từng thành phần đó.
Đặt mô hình phía sau một dòng, ưu tiên permissions hơn tools và đặt verifier bên ngoài agent. Khi đó, bước nhảy vọt tiếp theo trên bảng xếp hạng sẽ chỉ là một thay đổi cấu hình thay vì phải xây dựng lại từ đầu.
Và nếu bạn thấy bài viết này hữu ích:
- Đánh dấu trang bài viết này. Các liên kết thay đổi và các repo mới xuất hiện hàng tuần, bạn sẽ cần nó như một tài liệu tham khảo
- Để có các phân tích sâu hàng tuần về kiến trúc AI, giao dịch định lượng và kinh tế agent, hãy theo dõi tôi: @polydao
- Tham gia Kênh TG: Buzzoni Notes - ở đây tôi chia sẻ các prompt thô, skills tùy chỉnh và alpha còn quá sớm cho X
