Harness Engineering (Phần 2): Cẩm nang hiện thực

Đọc thêm:

Harness Engineering (Phần 1): Tầm quan trọng của Harness Engineering trong kiến trúc Agentic

Ở phần 1, chúng ta đã tìm hiểu lý do vì sao Harness ra đời và đóng vai trò then chốt trong hạ tầng AI Agent. Trong phần 2, hãy cùng nhau 'tháo rời' nó thành từng mảnh ghép cụ thể, bao gồm: cẩm nang dẫn đường (Guides), bộ giám sát bắt lỗi (Sensors), phương thức phối hợp, và quan trọng nhất là khi nào nên chọn giải pháp nào.

Harness Engineering gồm những gì?

Kỷ nguyên AI làm thay đổi cách phát triển phần mềm, vị thế của lập trình viên cũng đang có sự chuyển dịch sâu sắc. Chúng ta không còn đơn thuần là Coder cặm cụi gọt giũa từng dòng lệnh, mà đang dần trở thành một Kiến trúc sư điều khiển Agent (Agent Orchestrator/Architect).

Harness Engineering chính là lớp hạ tầng giúp bạn hiện thực hóa sự chuyển dịch đó, biến một Agent mang tính xác suất thành một hệ thống vận hành ổn định và đáng tin cậy.

Hãy hình dung: nếu nối tiếp 10 Agent có độ chính xác 95%, hệ thống tổng thể sẽ có tỷ lệ thành công chỉ còn khoảng 59.9%. Lúc này, Harness đóng vai trò như một 'cầu chì' bảo vệ, ngăn chặn sự suy giảm chất lượng theo hiệu ứng domino.

Tuy nhiên, Harness không phải là một khối bí ẩn hay 'hộp đen' phức tạp. Nó là tập hợp các thành phần rời rạc có vai trò, thời điểm can thiệp và cách triển khai rõ ràng. Để dễ dàng áp dụng vào thực tế, chúng ta sẽ chia Harness thành hai nhóm công cụ cơ bản:

• Guides (Cẩm nang dẫn đường): Can thiệp trước khi Agent thực hiện tác vụ
• Sensors (Bộ giám sát): Can thiệp và đánh giá sau khi Agent đã tạo ra kết quả

Framework 4 tổ hợp

Trước khi đi sâu vào chi tiết, hãy cùng điểm qua một khung phân loại tổng quan để nắm trọn bức tranh kiến trúc. Chuyên gia Birgitta Böckeler phân loại các thành phần của Harness theo hai trục độc lập:

Thời điểm can thiệp:

• Feedforward (Dẫn đường): Can thiệp trước khi Agent bắt đầu viết code hoặc thực thi tác vụ
• Feedback (Giám sát): Can thiệp sau khi Agent đã hoàn thành output để đánh giá kết quả

Phương thức thực thi:

• Computational (Tính toán): Mang tính xác định tuyệt đối, tốc độ cực nhanh, chi phí siêu rẻ, chạy trực tiếp bằng các công cụ CPU truyền thống
• Inferential (Suy diễn): Mang tính bất định, tốc độ chậm hơn, chi phí cao hơn vì phải gọi đến các mô hình LLM

Phân loại các thành phần của Harness. Nguồn: Martin Fowler

Sự kết hợp giữa hai trục này tạo ra bốn tổ hợp quản lý hạ tầng:

Nguyên lý vận hành cốt lõi:

Các công cụ thuộc nhóm Computational rẻ, nhanh và xác định tuyệt đối, do đó nên được tận dụng tối đa ở mọi giai đoạn.

Các giải pháp nhóm Inferential vừa đắt vừa bất định, chỉ nên được sử dụng ở bước cuối cùng khi ngữ nghĩa phức tạp là thước đo duy nhất.

Ma trận trên giúp chúng ta phân loại thành phần, nhưng khi thực sự bắt tay vào lập trình, bạn cần một công thức mang tính vận hành cụ thể hơn. Harness chính là toàn bộ môi trường và tài nguyên cần thiết để một model có thể hoạt động hiệu quả trong một domain xác định:

Trong đó, Harness bao gồm:

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions

• Model ra quyết định: Harness chịu trách nhiệm thực thi
• Model suy luận: Harness cung cấp đầy đủ ngữ cảnh

Hai khái niệm này luôn bổ trợ cho nhau: ma trận giúp bạn phân loại thành phần, còn công thức vận hành mang lại một khung lắp ráp hoàn chỉnh. Tiếp theo, chúng ta hãy cùng đi sâu vào Guides - nhóm thành phần đầu tiên của vòng lặp.

Guides - Cẩm nang dẫn đường

Thế nào là Guides tốt?

Guides là tập hợp những chỉ thị, quy tắc và công cụ bạn cung cấp cho Agent trước khi nó gõ dòng code đầu tiên, nhằm tăng tối đa xác suất làm đúng ngay từ lần thử đầu tiên. Điểm khác biệt lớn nhất giữa một Guide tốt và một Guide kém nằm ở độ cụ thể và khả năng kiểm tra tự động.

Các dạng Guide phổ biến và điểm tựa từ công cụ hằng ngày

• AGENTS.md ở thư mục gốc: Khai báo quy định chung cho toàn bộ dự án. Nếu bạn đã quen thuộc với file .cursorrules trong Cursor, Custom Instructions trong Claude Code, hay quy tắc cấu hình như .clinerules (Cline) và .windsurfrules (Windsurf)... thì AGENTS.md chính là dạng chuẩn hóa tổng quát của chúng ở cấp độ hạ tầng dự án: "Ngôn ngữ TypeScript strict mode, cấm sử dụng any, tuân thủ kiến trúc layered, mọi API bắt buộc trả về một cấu trúc ErrorEnvelope duy nhất".
• conventions.md trong từng Skill: Cụ thể hóa quy tắc cho từng domain riêng biệt: đối với backend-service-builder, yêu cầu "Integration client phải inject qua Dependency Injection, không dùng static factory"; với frontend-project-builder, quy định "Chỉ hooks mới được coi là public API của data layer".
• Policy (Rego): Mã hóa quy tắc kiến trúc thành code kiểm tra xác định. Loại này chạy trong vài mili giây, không tốn token và không phụ thuộc vào LLM.
• playbook.yaml: Định nghĩa luồng vận hành theo giai đoạn: phase nào dùng model giá rẻ để tiết kiệm, phase nào dùng model đắt tiền; đặt ra các cổng kiểm soát (gates) nghiêm ngặt - ví dụ nếu typecheck không sạch thì pipeline dừng ngay lập tức (STALLED).

Bảng so sánh dưới đây minh họa rõ khoảng cách giữa một Guide mơ hồ và một Guide chuẩn mực:

Quy tắc kiểm thử Guide:

Một Guide chất lượng phải là một Guide có thể kiểm tra được bằng script. Ví dụ:

• Với chỉ thị "cấm any" trong AGENTS.md, bạn có thể kiểm tra ngay bằng lệnh rg "any" src --type ts.
• Với quy tắc "phải có outputEvents", bạn dễ dàng verify bằng 15 dòng code Rego.

Nếu không thể chuyển hóa hướng dẫn thành một phép kiểm tra máy móc, đó chỉ là lời khuyên suông và khả năng Agent bỏ qua là rất cao.

Sau khi Agent đã nhận đủ chỉ dẫn và tiến hành hành động, câu hỏi tiếp theo sẽ là: làm sao để kiểm tra kết quả? Đó là lúc nhóm bộ giám sát (Sensors) phát huy vai trò.

Sensor - Bộ giám sát

Bộ giám sát là hệ thống gác cổng đặt ở phía sau Agent, có nhiệm vụ ghi nhận kết quả và cung cấp phản hồi để Agent tự sửa lỗi. Tuy nhiên, một sensor chuẩn mực không chỉ báo lỗi rồi bỏ đó, nó cần cung cấp phản hồi có cấu trúc và đính kèm chỉ thị sửa lỗi cụ thể.

Birgitta Böckeler gọi đây là kỹ thuật constructive prompt injection: Agent nhận được hướng dẫn khắc phục rõ ràng thay vì một lời trách mắng chung chung.

[SENSOR_FEEDBACK]
TYPECHECK_FAIL: 3 errors in src/api/handler.ts
- line 12: 'User' is not assignable to 'UserDTO'
FIX INSTRUCTION: Add mapper in src/api/mapper.ts, see AGENTS.md §3.2 (one error envelope).

Bộ giám sát kém vs. Bộ giám sát tốt

Tương tự như Guides, Sensors cũng được chia làm hai tầng:

• Tầng Computational chạy trước để đảm bảo tính tuyệt đối và tiết kiệm chi phí.
• Tầng Inferential chạy sau nhằm xử lý các lỗi phức tạp về mặt ngữ nghĩa.

Tầng Computational: Đúng sai rõ ràng, không có khái niệm "có lẽ"

Ở tầng tính toán, bạn sử dụng các công cụ truyền thống như Linter, Type checker, Unit test framework, ArchUnit, dependency-cruiser hay OPA (với ngôn ngữ Rego). Kết quả trả về luôn tuyệt đối và mang tính rạch ròi.

Ví dụ về một đợt OPA audit thực tế trên codebase minh họa rõ sức mạnh của tầng này:

Toàn bộ quá trình kiểm tra này phát hiện ra 84 vi phạm kiến trúc nhưng tiêu tốn đúng 0 LLM call. Việc 5 policy bị fail cảnh báo ngay lập tức rằng codebase đang vi phạm các quy chuẩn cốt lõi mà không cần tốn một đồng chi phí token nào.

Một dạng đặc biệt hiệu quả của computational sensor là build harness: tự động chạy lệnh compile, typecheck hoặc lint trên đoạn code Agent vừa tạo ra. Nếu code không thể compile, hệ thống lập tức ném lỗi bắt Agent phải sửa. Compiler là người phán xử khách quan nhất, và nó không bao giờ đưa ra nhận định cảm tính.

Tầng Inferential: Tốc độ chậm hơn nhưng xử lý được lỗi ngữ nghĩa

Ở tầng Inferential, pipeline review thường bao gồm nhiều auditor xếp tầng. Output của lớp trước sẽ trở thành input cho lớp tiếp theo, ví dụ như quy trình kiểm tra tài liệu thiết kế sau:

• R0 (review-inventory): Kiểm tra xem có file nào bị thiếu không. Nếu thiếu file gốc, quy trình review bị dừng ngay lập tức (STALLED).
• R1 (review-document): Audit từng tài liệu dựa trên 8 tiêu chí chất lượng và chấm điểm chi tiết.
• R2a (review-consistency): Đối chiếu thuật ngữ xuyên suốt các file, phát hiện mâu thuẫn giữa tài liệu quyết định (DECISIONS) và yêu cầu (REQUIREMENTS), hoặc giữa dữ liệu (DATA) và ước lượng (ESTIMATION).
• R2b (review-arithmetic): Dùng lệnh Bash để tính toán lại toàn bộ con số PERT, tuyệt đối không tin tưởng vào các con số có sẵn trong tài liệu gốc. (R2a và R2b được cho chạy song song vì kiểm tra logic và kiểm tra số liệu là hai việc độc lập).
• R3 (review-synthesis): Tổng hợp toàn bộ phát hiện từ các bước trước, chấm điểm hệ thống theo 3 chiều (Quality/Consistency/Correctness) và đưa ra phán quyết cuối cùng.

Cảnh báo quan trọng:

Bộ giám sát Inferential bản chất vẫn là các LLM nên nó hoàn toàn có thể mắc sai lầm như Agent chính.

Böckeler đưa ra lời khuyên: tuyệt đối không tạo ra một vòng phản hồi inferential khép kín 100%. Luôn phải đặt ra ngưỡng can thiệp của con người (Human-in-the-loop) khi điểm số đánh giá quá thấp hoặc khi các judge bất đồng ý kiến.

Đến đây, bạn đã nắm rõ cả hai nhóm công cụ: Guides (dẫn đường trước) và Sensors (giám sát sau). Nhưng câu hỏi tiếp theo là: chúng ta sử dụng những công cụ này để kiểm soát khía cạnh nào của phần mềm?

3 mục tiêu kiểm soát của Harness

Böckeler phân chia Harness thành 3 mục tiêu kiểm soát, sắp xếp theo thứ tự độ khó tăng dần: bảo trì (dễ nhất), kiến trúc (trung bình), và hành vi (khó nhất).

Mục tiêu 1: Harness bảo trì (Cấp độ dễ)

Đây là mục tiêu dễ triển khai nhất vì đã có sẵn rất nhiều công cụ hỗ trợ, nơi các giải pháp computational phát huy tối đa sức mạnh. Lỗi trùng lặp code, độ phức tạp cyclomatic quá cao, thiếu unit test, sai quy chuẩn style, hay import sai ranh giới module... đều có thể quét sạch bằng các thuật toán heuristic thuần túy.

Bốn bộ giám sát quét tự động (Sweep Sensors) thường được vận hành bao gồm:

• Complexity sensor: Cảnh báo hàm dài quá 60 dòng, vòng lặp lồng nhau sâu hơn 4 tầng, hoặc truyền quá 5 tham số.
• Performance sensor: Bắt lỗi truy vấn N+1, thực hiện I/O bên trong vòng lặp.
• Duplication sensor: Phát hiện các đoạn code bị trùng lặp cấu trúc thông qua thuật toán hash.
• Deadcode sensor: Quét các hàm hoặc biến đã export nhưng không còn nơi nào sử dụng.

Tất cả các sensor này đều chạy bằng tính toán thuần túy, zero token, zero LLM call.

Trong thực tế, complexity sensor là thứ dễ cài đặt nhất: chỉ cần dùng lệnh rg -c "for|while|if" src là bạn đã có ngay biểu đồ phân bố độ phức tạp trên toàn bộ dự án để đánh fail các commit vượt ngưỡng.

Mục tiêu 2: Harness kiến trúc (Cấp độ trung bình)

Böckeler gọi đây là các Fitness Functions - những phép đo khách quan giúp kiểm tra xem kiến trúc hệ thống có giữ đúng các đặc tính mong đợi theo thời gian hay không.

Ví dụ, bộ arch-conflict-rules với 14 quy tắc cross-document có thể bắt trúng các lỗi bất hợp lý như: "Tài liệu DECISIONS chọn mô hình Serverless nhưng REQUIREMENTS lại đòi hỏi độ trễ cực thấp", hoặc "ESTIMATION tính toán mất 40 giờ nhưng BALLPARK chỉ cấp ngân sách 20 giờ".

Tương tự, bộ 12 Rego policy sẽ tự động kiểm tra xem "Agent có khai báo outputEvents hay không", hay "Handler có gọi hàm resolveTenant hay không". Cả quy tắc YAML lẫn policy Rego đều đóng vai trò là các hàm fitness dạng computational: YAML kiểm tra tính nhất quán trong thiết kế, còn Rego kiểm tra sự tuân thủ giữa code và quy ước kiến trúc.

Điểm khác biệt của Fitness Functions là chúng mang tính theo dõi dài hạn: bạn chạy chúng trên mọi commit, ghi lại xu hướng (trend) và phát cảnh báo khi chất lượng hệ thống có dấu hiệu đi xuống, thay vì chỉ báo lỗi thụ động.

Mục tiêu 3: Harness hành vi (Cấp độ khó nhất)

Böckeler ví mục tiêu này như "the elephant in the room".

Rất nhiều đội ngũ kỹ thuật hiện nay phó mặc hoàn toàn việc kiểm thử cho các bộ test do AI tự sinh. Tuy nhiên, Böckeler cảnh báo: "Đặt quá nhiều niềm tin vào bài test do AI tạo ra là một giải pháp chưa đủ an toàn ở thời điểm hiện tại."

Để kiểm soát hành vi bất định của Agent, hệ thống cần phối hợp 4 cơ chế hạ tầng (toàn bộ đều là computational):

• Optimistic locking (Khóa lạc quan): Bảo vệ tính toàn vẹn dữ liệu khi nhiều Agent cùng làm việc. Mỗi Agent đọc một bản chụp trạng thái (State Snapshot JSONB), thực hiện ghi dữ liệu kèm theo kiểm tra version. Nếu xảy ra xung đột, Agent sẽ tự động retry với snapshot mới, giúp giảm tỷ lệ xung đột xuống dưới 2%.
• Scenario tests (Kịch bản E2E cố định): Xây dựng hơn 100 kịch bản kiểm thử cố định để mã hóa các hành vi nghiệp vụ quan trọng. Nếu Agent sinh code làm sai lệch luồng hành vi này, pipeline sẽ lập tức báo lỗi.
• Audit immutability (Nhật ký bất biến): Sử dụng Database Trigger để chặn hoàn toàn các lệnh UPDATE/DELETE trên bảng audit_logs, đồng thời thu hồi quyền sửa xóa từ ứng dụng. Nhờ đó, một khi log đã ghi nhận thì không Agent nào có thể 'xóa vết' nếu lỡ làm sai.
• Atomic claim pattern (Cơ chế tranh chấp nguyên tử): Ngăn chặn tình trạng hai Agent xử lý trùng một tác vụ thông qua lệnh SQL nguyên tử: UPDATE tasks SET status = 'claimed', claimed_by = $1 WHERE status = 'pending'.

Dù vậy, 4 cơ chế trên vẫn có những giới hạn nhất định: Optimistic lock chỉ giải quyết xung đột ghi chứ không hiểu được xung đột logic; Scenario test không thể phủ hết mọi ngóc ngách nghiệp vụ. Khi các quy tắc kinh doanh vượt quá khả năng mã hóa của Rego và đòi hỏi sự đánh giá của con người, Harness phải biết dừng lại để gọi nhân sự can thiệp.

Một Harness giỏi là một Harness biết rõ ranh giới và giới hạn của chính nó.

Bố trí Guides & Sensors theo nguyên lý Keep Quality Left

Bài học kinh điển từ Continuous Delivery (CD) chỉ ra rằng: phát hiện lỗi càng sớm thì chi phí sửa lỗi càng rẻ. Nguyên lý này lại càng đúng đối với các coding Agent, nơi một sai lầm phát hiện muộn sẽ tiêu tốn chi phí rất lớn vì Agent đã kịp tạo thêm hàng trăm dòng code dựa trên một nền tảng sai trái.

Khác với con người, Agent không biết mệt mỏi và không ngại làm lại. Bạn hoàn toàn có thể vận hành một mạng lưới giám sát dày đặc ở mọi công đoạn, miễn là chúng rẻ.

Vòng đời kiểm soát được chia làm 3 giai đoạn chính:

Nguyên tắc mấu chốt: Mỗi khi Agent vi phạm một quy tắc ở bộ giám sát phía sau, hãy tìm cách 'đẩy' quy tắc đó về giai đoạn bên trái hơn.

• Nếu Agent lặp lại lỗi typecheck 3 lần: Thêm ngay chỉ thị vào AGENTS.md (hoặc .cursorrules).
• Nếu Agent vi phạm một pattern kiến trúc: Mã hóa nó thành một luật trong arch-conflict-rules.yaml.

Chất lượng không phải là thứ để kiểm tra ở công đoạn cuối cùng. Bạn phải đẩy nó về nơi có chi phí khắc phục rẻ nhất.

Khả năng gắn Harness & khái niệm Ambient Affordances

Böckeler chỉ ra rằng: một codebase được viết bằng các ngôn ngữ kiểm kiểu mạnh (statically typed) đã sở hữu sẵn Type Checker. Các dự án có cấu trúc module phân thiệp rõ ràng sẽ dễ dàng tích hợp ArchUnit. Những framework như Spring giúp trừu tượng hóa hạ tầng, khiến Agent không phải bận tâm đến các chi tiết vụn vặt. Ned Letcher gọi những đặc tính nội tại này là ambient affordances - những 'ưu đãi môi trường' mà bản thân codebase tự mang lại.

Với các dự án mới (greenfield), bạn nên thiết kế hệ thống để thừa hưởng tối đa các 'ưu đãi' này ngay từ ngày đầu: áp dụng Typed snapshot qua Zod schema, cài đặt Optimistic lock, chuẩn bị sẵn conventions.md và AGENTS.md. Trong một môi trường như vậy, mọi Agent sẽ buộc phải tuân thủ kỷ luật một cách tự nhiên: sai kiểu dữ liệu sẽ bị Zod từ chối, ghi đè dữ liệu sẽ bị Lock ngăn chặn.

Ngược lại, các dự án cũ (legacy) thường thiếu vắng những lớp bảo vệ này. Bạn sẽ phải xây dựng lại từng lớp hạ tầng và ghép nối từng bộ giám sát vào những vị trí không ai ngờ tới. Một dự án được trang bị Harness tốt sẽ giúp Agent sửa lỗi nhanh hơn, ít bị lỗi dây chuyền (regression) hơn. Sau mỗi lần sửa đổi, chính Harness đó lại càng trở nên hoàn thiện hơn.

Decision Framework: Lựa chọn thành phần nào?

Khi đối mặt với một dự án thực tế, câu hỏi quan trọng nhất đối với lập trình viên vẫn là: Bắt đầu từ đâu?

3 câu hỏi định hướng triển khai

1. Vấn đề cần giải quyết thuộc mục tiêu nào?

• Lỗi bảo trì → Dùng Sweep Sensors với các ngưỡng heuristic
• Lỗi kiến trúc → Dùng Rego policy và arch-conflict-rules
• Lỗi hành vi → Dùng các cơ chế hạ tầng như Optimistic lock, Scenario test, Audit immutability, Atomic claim

2. Thời điểm can thiệp phù hợp là khi nào?

• Cần định hướng trước khi Agent code → Dùng Feedforward (Guides)
• Cần kiểm tra sau khi Agent làm xong → Dùng Feedback (Sensors)

3. Mức độ chính xác yêu cầu là gì?

• Cần sự tuyệt đối, tốc độ nhanh, chi phí rẻ → Dùng giải pháp Computational (Typecheck, Rego, Script)
• Cần sự linh hoạt và đánh giá ngữ nghĩa → Dùng giải pháp Inferential (LLM Review, Intent-based guide)

Bảng tra cứu quyết định nhanh

Nguyên tắc tổng quát:

Hãy luôn bắt đầu từ ô Computational + Feedforward (rẻ nhất và an toàn nhất). Sau đó mở rộng sang ô Computational + Feedback (Build harness, OPA).

Chỉ khi hai ô computational đã được khai thác triệt để, bạn mới tiếp tục bổ sung các giải pháp Inferential. Và cuối cùng, luôn giữ con người ở vị trí phán xử cuối cùng đối với các quyết định vượt quá ngưỡng an toàn.

Bản đồ thành phần hoàn chỉnh

Nhìn lại toàn bộ hệ thống, bạn sẽ thấy Harness Engineering đã trang bị cho bạn một bộ kỹ năng quản trị AI trọn vẹn:

• 4 tổ hợp ma trận mang lại không gian thiết kế
• 2 nhóm điều khiển (Feedforward/Feedback) cho bạn điểm can thiệp
• 2 tầng công nghệ (Computational/Inferential) giúp bạn cân bằng chi phí và hiệu năng

Tất cả được đặt trên 3 mục tiêu kiểm soát (Bảo trì/Kiến trúc/Hành vi) và vận hành bởi 3 câu hỏi định hướng -chiếc la bàn giúp bạn tự tin làm chủ mọi bài toán kỹ thuật.

Khi làm chủ Harness Engineering, vị thế của bạn không còn dừng lại ở một Coder cặm cụi sửa từng lỗi cú pháp hay viết đi viết lại từng dòng prompt. Bạn chính thức bước lên vị trí của một Kiến trúc sư điều khiển Agent (Agent Orchestrator) - người thiết kế nên một 'nhà máy' chuẩn mực để các AI Agent tự do vận hành mà không gây ra thảm họa cho hệ thống.

Cầm trên tay bản đồ này, bạn sẽ nhận ra ngay những điểm 'hổng' trong dự án: nơi thì thiếu dẫn đường, nơi lại phụ thuộc LLM quá đà, hoặc bỏ quên các mục tiêu kiểm soát cốt lõi.

Ở bài viết tiếp theo, chúng ta sẽ đi sâu vào các kỹ thuật lắp ráp thực tế: từ chuỗi Middleware chain, Steering loop, đến cách duy trì Harness theo thời gian - biến những linh kiện rời rạc này thành một dây chuyền sản xuất phần mềm thực sự đáng tin cậy.

Tham khảo

• Birgitta Böckeler & Nicola Gasparro, "Harness engineering for coding agent users"
• Open Policy Agent, "Policy-based control for cloud native environments"
• Neal Ford, Rebecca Parsons & Patrick Kua, "Building Evolutionary Architectures", xem thêm về khái niệm Fitness Functions
• Unit test your Java architecture
• Harness Engineering