Phân biệt Agent & Harness và tư duy giải cấu trúc

Mình thấy Agent và Harness mọi người có vẻ thường bị nhầm lẫn, vì khi dùng một công cụ AI, hai thứ này thường xuất hiện cùng nhau.

Ta gọi Codex App, Claude Code là Agent - đúng. Mà gọi là Harness cũng đúng luôn.

Agent và Harness khác nhau ở đâu?

Thật ra chúng không giống nhau. Nếu bạn chỉ là người dùng, bạn có thể gọi nhầm Agent và Harness nhưng nếu bạn làm hệ thống thì việc nhầm lẫn là cực kỳ không nên.

Lấy ví dụ giao cho AI một việc: "Tìm và sửa lỗi đăng nhập".

• Agent chọn bước tiếp theo: đọc file nào, tìm lỗi ở đâu, sửa gì, rồi dựa vào kết quả test để quyết định có cần sửa tiếp không.
• Harness đảm bảo cho quá trình đó chạy được: thực thi lời gọi công cụ, kiểm tra quyền, giữ ngữ cảnh và đưa kết quả trở lại để Agent tiếp tục.

Mặc dù ở thời điểm hiện tại, các app/cli/system Agent hiển nhiên phải có Harness. Nên dễ tạo sự khó phân biệt này.

Nếu chúng vốn đi cùng nhau thì tại sao phải phân biệt?

Như mình từng chia sẻ khá nhiều lần. Để làm được hệ thống (dù nhỏ hay lớn), chúng ta phải biết giải cấu trúc và phân biệt được từng cấu trúc nhỏ hơn, thậm chí là tới thành phần cụ thể. Mỗi cái có nhiệm vụ riêng không nên nhầm lẫn.

Bạn có thể lựa chọn nhập vào hoặc tách ra tùy bài toán cụ thể. Nhưng ít ra bạn luôn biết với mỗi problem thì đâu là nơi cần quan tâm, đâu là nơi chả liên quan.

Tách Agent khỏi Harness ngay trong workflow

Thậm chí trong một workflow, bạn có thể tách phần đề xuất của Agent khỏi phần kiểm soát và thực thi của Harness.

Ví dụ Agent Node chỉ chạy một loop vài turn, được cấp các công cụ read-only để research, scout, đọc file, search, fetch web...

Đầu ra là một đề xuất có cấu trúc: muốn update/edit gì, ở đâu, với tham số nào. Các hành động thay đổi hệ thống chưa được thực thi tại đây.

Đề xuất đi qua các node kiểm tra quyền, kiểm tra điều kiện nghiệp vụ hoặc xin con người phê duyệt. Hành động được duyệt mới chuyển sang node thực thi. Nếu bị từ chối hoặc thực thi thất bại, phản hồi có thể quay lại Agent để điều chỉnh.

Các node kiểm soát và thực thi này là những phần của Harness được tách ra trong workflow. Bản thân loop read-only của Agent vẫn cần một lớp điều phối tối thiểu.

Nhờ vậy, mình có thể kiểm tra và thay đổi phần Agent tương đối độc lập, còn quyền tác động lên hệ thống được quản lý tại một nơi rõ ràng.

Giải cấu trúc: chia để trị hiệu quả

Tới đây nếu bạn vẫn chưa nhìn ra được mức độ hiệu quả của việc phân tách này thì mình nói luôn:

Vì tách ra như vậy, nhiệm vụ của Agent Node bây giờ rất gọn, rất dễ kiểm tra và lựa chọn stack.

Bạn không cần phải cố gắng lắp 1 con all-in-one có cả Agent và Harness vào rồi sau đó đau đầu vì nó chạy không đúng, không hiểu hệ thống của bạn, không inject các quyền của hệ thống,...

Cái gì của hệ thống bạn khác biệt, thì vẫn phải làm. Nhưng cái Agent cơ bản thì rất nhìu. Thậm chí bạn tự build để nó ít tools, tối ưu context, focus đúng việc hơn.

Và đó là sức mạnh của "giải cấu trúc". Đây là một mindset, một skill cực kỳ quan trọng mà ít ai để ý.

Học cơ chế, đừng chỉ học chiêu thức

Người mới học kiến trúc sẽ thường lao vào phối ghép, lắp này lắp nọ để xây hệ thống. Họ sợ hệ thống xây không đủ lớn.

Nhưng người làm lâu năm với mindset chuẩn sẽ lo lắng rằng liệu tôi có giải cấu trúc đủ chi tiết và hiểu cơ chế của chúng chưa. Giải được càng nhỏ, hiểu được càng chi tiết thì tôi có thể tự do tái tạo lại bất kỳ cấu trúc mong muốn nào cho từng bài toán cụ thể.

Và đó mới được gọi là Solution Architecture (kiến trúc giải pháp) cho bài toán cụ thể.

Do nhiều người thấy các kiến trúc sư hệ thống thi triển "chiêu thức" nên họ đi học "chiêu thức". Cái đó thiên biến vạn hóa, học hoài không hết.