TL;DR

3 team hàng đầu implement Harness Engineering theo 3 triết lý khác nhau: Anthropic tập trung vào multi-agent collaboration và structured handoffs; OpenAI tái cấu trúc toàn bộ môi trường dev để AI có thể đọc và verify trực tiếp; Nous Research tự động hóa cả quá trình tối ưu Harness. Phần cuối series này cũng đúc kết 3 nguyên tắc ngược trực giác quan trọng nhất.

Anthropic - Claude Code: Kiến trúc GAN cho software engineering

Anthropic tiếp cận harness design bằng cách mô phỏng vòng đời phát triển phần mềm qua multi-agent lấy cảm hứng từ GAN (Generative Adversarial Networks).

Hệ thống 3 agent:

  • Planner: Nhận prompt 1-4 câu, expand thành full product spec chi tiết. Được cấu hình để ambitious về scope, tập trung vào product context và kiến trúc cao cấp - tránh specify technical detail quá sớm vì lỗi ở planning stage sẽ cascade xuống implementation.

  • Generator: Làm việc theo sprint, mỗi sprint pick 1 feature từ spec. Cuối mỗi sprint tự đánh giá trước khi handoff cho QA. Tech stack: React, Vite, FastAPI, SQLite/PostgreSQL.

  • Evaluator: Dùng Playwright MCP click qua app theo đúng path của user thực, test UI features, API endpoints, database states. Mỗi sprint graded theo sprint contract - bộ tiêu chí đã được Generator và Evaluator thỏa thuận trước khi code một dòng nào.

Sprint contract là điểm đặc biệt: trước mỗi sprint, Generator đề xuất nó sẽ build gì và success sẽ được verify thế nào. Evaluator review proposal. Hai bên đàm phán cho đến khi đồng thuận - chỉ sau đó mới code. Điều này bridge gap giữa user story cao cấp và testable implementation.

Kết quả thực tế: Claude Sonnet 4.5 cần "context resets" (xóa sạch context, pass handoff artifact cho agent mới) vì hay bị "context anxiety" - tự wrap up sớm khi sắp hết token. Khi upgrade lên Opus 4.6, sprint decomposition không còn cần thiết - model code liên tục 2+ giờ không cần scaffolding.

Lesson từ Anthropic: Mỗi component trong harness encode một assumption về limitation của model. Khi model mới ra, stress test lại assumptions đó - nhiều cái đã expired.

OpenAI - Codex: "Codex Legibility" - Môi trường AI-readable

OpenAI đặt ra khái niệm "Codex Legibility" - codebase không chỉ phải readable với người, mà phải readable với Agent. Toàn bộ dev infrastructure phải được redesign cho AI có thể dùng trực tiếp.

Vercel d0 trong Slack - AI agent giúp team query analytics mà không cần viết SQL

5 concrete implementations:

  1. Auto-spawn app instance per worktree: Mỗi git worktree tự khởi động một application instance riêng. Codex có thể tự mở instance đó, operate, xem response, verify changé có work như expected không - không cần engineer làm trung gian.

  2. Chrome DevTools Protocol tích hợp: AI có browser debugging ability ngang engineer: xem DOM structure, monitor network requests, inject JS, screenshot. Reproducing UI bug không cần engineer mở browser thủ công.

  3. Production logs expose cho AI query: Codex có thể dùng LogQL, PromQL, TraceQL để query trực tiếp production monitoring. Debug một issue không cần engineer copy-paste logs - AI tự grep, xem metric anomaly, trace request path.

  4. Custom architectural linter: Mọi layer dependency rule, naming convention, forbidden pattern đều được encode thành executable linter. Code AI viết mà vi phạm bị chặn ngay.

  5. Background garbage collection: Định kỳ Codex tasks scan codebase tìm architectural drift, tự mở small PRs để fix. Tech debt không còn tích lũy bị động.

Lesson từ OpenAI: Trước khi dùng AI, tự hỏi: AI có nhìn thấy state này không? Nếu không, tìm cách expose nó. Logs không structured = AI cũng không đọc được. Refactor logs thành JSON với fixed schema là bước đầu tiên của AI-friendly infrastructure.

Nous Research - Superpowers: Harness tự tối ưu chính nó

Nous Research xây Superpowers - open-source Agent Skills framework với triết lý tự động hóa tối đa, kể cả quá trình tối ưu harness.

Built-in workflows:

  • TDD workflow: AI viết test trước, viết implementation sau. Test pass mới tính là xong. Đây là default behavior, không phải option.

  • 2-phase code review: Generator agent viết code, Reviewer agent độc lập với role config và prompt khác hẳn đánh giá. Forced separation giữa creator và critic.

  • Sub-agent collaboration templates: Task decomposition, parallel execution, result aggregation - đóng gói sẵn thành reusable patterns.

Hermes Self-Evolution (ICLR 2026 Oral): Project sibling của Superpowers, dùng DSPy + GEPA (Genetic-Pareto Prompt Evolution) để tự động tối ưu harness. GEPA đọc execution traces để hiểu WHY fail, đề xuất targeted mutations - rồi chọn variants tốt nhất theo multi-objective optimization.

Chi phí: ~$2-10/optimization run. Không cần train lại model. Toàn bộ qua API calls: mutate text, evaluate results, select winners.

5-phase roadmap: Phase 1 (skill files) đã xong. Phase 2-4 sẽ tối ưu tool descriptions, system prompt sections, tool implementation code. Phase 5: continuous improvement pipeline tự chạy.

Lesson từ Nous Research: Nếu không muốn tự thiết kế TDD workflow và 2-phase review, Superpowers có template open-source dùng được ngay.

3 nguyên tắc ngược trực giác

Nguyên tắc 1: Harness không phải càng nhiều càng tốt

Tool càng nhiều, agent càng có nhiều selection space ở mỗi bước, xác suất chọn nhầm tool, đi sai đường càng cao. Vercel xóa 80% tools: 80%→100%, 3.5x nhanh hơn, -37% token. Manus cũng ghi nhận: "heavily armed agent sẽ kém thông minh hơn".

Trước khi thêm tool: tự hỏi nó giải quyết gap hành vi cụ thể nào. Không trả lời được = chưa cần.

Nguyên tắc 2: Context organization quan trọng hơn context size

Nhiều người thấy Claude 4 Opus có triệu token context window liền nghĩ "nhồi hết vào". Đây là sai lầm đắt tiền.

Nghiên cứu Context Rot: test 18 model trên long context - performance xuống đáng kể khi input tăng từ 10k lên 500k token dù task không thay đổi. Stanford "Lost in the Middle": model dùng info ở đầu và cuối context tốt nhất - info ở giữa hay bị ignore. Manus: input/output token ratio trong typical Agent task là 100:1, KV-cache hit vs miss chênh nhau 10x - context organization tốt có thể cắt API bill xuống 1 order of magnitude.

Nguyên tắc 3: Harness phải shrink theo model tiến hóa

Mỗi harness component ẩn chứa một assumption: "model tự làm không được cái này". Assumptions có hạn dùng.

Anthropic đã thêm explicit "planning" step trong early Claude Code - buộc AI output kế hoạch trước khi làm. Khi model mới ra với planning capability tốt hơn, họ xóa step đó - nó trở thành overhead thừa. Khi Opus 4.6 ra, sprint decomposition bị xóa vì model đã native handle long context.

Mỗi lần model version mới, review lại harness: component nào đang thực sự bù capability? Cái nào chỉ còn là legacy overhead? Cái nào AI đã tự làm được rồi?

Kết series

ProgramBench 0% nói lên điều ngược lại với what it seems: không phải AI không đủ mạnh, mà là khoảng cách giữa "model mạnh" và "system làm được việc thực" chính là Harness Engineering.

Agent = Model + Harness. Harness Engineering là kỹ năng cốt lõi của kỷ nguyên AI - không phải vì nó là thuật ngữ mới, mà vì nó hệ thống hóa những gì good software engineers đã làm từ trước: viết requirement doc, chia task, test, code review, enforce standards.

Bắt đầu đơn giản: có một AGENTS.md không? Có progress.md không? AI có cách tự verify output không?
Trả lời 3 câu đó trước khi nghĩ đến MCP servers hay sub-agent orchestration.

via Anthropic - Harness design for long-running apps · OpenAI - Harness Engineering · Nous Research - Hermes Self-Evolution · Martin Fowler - Harness Engineering