Thiết kế harness để phát triển các ứng dụng chạy dài hạn

• Anthropic đã phát triển một cấu trúc đa tác tử lấy cảm hứng từ GAN để đồng thời giải quyết hai vấn đề: nâng cao chất lượng thiết kế frontend và coding tự trị dài hạn
• Cấu trúc tách biệt generator (bộ sinh) và evaluator (bộ đánh giá) giúp chấm điểm chất lượng thiết kế mang tính chủ quan theo các tiêu chí cụ thể, qua đó giải quyết vấn đề thiên lệch khi tác tử tự đánh giá
• Với kiến trúc 3 tác tử gồm planner-generator-evaluator, hệ thống hoàn thiện ứng dụng full-stack trong các phiên coding tự trị kéo dài nhiều giờ, bao gồm cả thương lượng sprint contract và QA dựa trên Playwright
• Khi chuyển từ Opus 4.5 sang Opus 4.6, hệ thống có thể coding nhất quán hơn 2 giờ mà không cần chia sprint, giúp giảm độ phức tạp của harness mà vẫn giữ được hiệu năng
• Ngay cả khi hiệu năng mô hình tăng lên, không gian các tổ hợp harness thú vị không hề thu hẹp mà chỉ dịch chuyển, và nhiệm vụ cốt lõi của kỹ sư AI là tìm ra các tổ hợp mới đó

---

Vì sao cách triển khai đơn giản chạm tới giới hạn

• Trong các thử nghiệm trước đó, Anthropic dùng cách để tác tử khởi tạo phân rã đặc tả sản phẩm thành danh sách tác vụ, rồi tác tử coding triển khai từng tính năng một, sau đó truyền ngữ cảnh giữa các phiên thông qua artifact
  • Trong cộng đồng lập trình viên cũng xuất hiện các cách tiếp cận tương tự, như kiểu "Ralph Wiggum", dùng hook hoặc script để giữ tác tử trong một vòng lặp lặp lại liên tục
• Ở các tác vụ phức tạp, tác tử vẫn liên tục bị lệch quỹ đạo theo thời gian, và quan sát thấy hai kiểu thất bại phổ biến
• Kiểu thất bại thứ nhất: khi cửa sổ ngữ cảnh đầy lên, mô hình mất tính nhất quán; một số mô hình còn có xu hướng rơi vào hiện tượng "lo âu ngữ cảnh (context anxiety)", tức khi tự nhận thấy đã chạm giới hạn ngữ cảnh thì cố kết thúc công việc sớm
  • Context reset (xóa toàn bộ cửa sổ ngữ cảnh và khởi động một tác tử mới bằng một handoff có cấu trúc chứa trạng thái của tác tử trước cùng bước tiếp theo) giải quyết được cả hai vấn đề
  • Cách này khác với compaction, tức tóm tắt phần hội thoại trước đó để cùng một tác tử tiếp tục làm việc; compaction giữ được tính liên tục nhưng không tạo ra một trạng thái sạch hoàn toàn nên có thể vẫn duy trì lo âu ngữ cảnh
  • Ở Claude Sonnet 4.5, lo âu ngữ cảnh quá mạnh nên chỉ compaction thôi không thể đảm bảo hiệu năng cho tác vụ dài hạn, vì vậy context reset trở thành thành phần cốt lõi của thiết kế harness
• Kiểu thất bại thứ hai: vấn đề tự đánh giá (self-evaluation), khi tác tử tự chấm kết quả do mình tạo ra thì có xu hướng tự tin khen ngợi dù chất lượng thực tế chỉ ở mức trung bình
  • Điều này đặc biệt nghiêm trọng ở các tác vụ chủ quan như thiết kế, nơi không có phép kiểm tra nhị phân tương đương với các bài test phần mềm có thể xác minh được
  • Việc tách tác tử làm việc và tác tử đánh giá là một đòn bẩy rất mạnh; việc tinh chỉnh evaluator theo hướng hoài nghi cũng dễ xử lý hơn nhiều so với việc buộc generator phải tự phê bình

Thiết kế frontend: biến chất lượng chủ quan thành thứ có thể chấm điểm

• Nếu không can thiệp, Claude mặc định tạo ra các bố cục an toàn, dễ đoán, hoạt động đúng về mặt kỹ thuật nhưng khá tầm thường về mặt thị giác
• Có hai nhận định cốt lõi dẫn dắt thiết kế harness
  • Dù không thể chấm điểm thẩm mỹ một cách hoàn hảo, vẫn có thể cải thiện bằng bộ tiêu chí chấm điểm mã hóa các nguyên tắc và sở thích thiết kế — câu hỏi "thiết kế này có đẹp không?" kém nhất quán hơn "nó có tuân theo các nguyên tắc thiết kế tốt không?"
  • Tách việc tạo frontend khỏi việc chấm điểm để hình thành một vòng phản hồi đẩy generator tới kết quả mạnh hơn
• 4 tiêu chí chấm điểm được đưa cho cả generator lẫn evaluator:
  • Chất lượng thiết kế (Design quality): màu sắc, typography, bố cục, hình ảnh... có kết hợp thành một tổng thể nhất quán với bầu không khí và bản sắc rõ rệt hay không
  • Tính nguyên bản (Originality): có dấu vết của các quyết định tùy biến hay chỉ là bố cục mẫu, mặc định thư viện, hoặc pattern do AI sinh ra — nếu có các dấu hiệu quen thuộc kiểu AI như thẻ trắng trên nền chuyển sắc tím thì bị trừ điểm
  • Mức độ hoàn thiện (Craft): chất lượng thực thi kỹ thuật như phân cấp typography, tính nhất quán về khoảng cách, hòa hợp màu sắc, tỷ lệ tương phản... — đây là thước đo năng lực chứ không phải sáng tạo
  • Tính chức năng (Functionality): khả năng sử dụng độc lập với yếu tố thẩm mỹ — người dùng có hiểu giao diện dùng để làm gì và có tìm được các hành động chính hay không
• Chất lượng thiết kế và tính nguyên bản được gán trọng số cao hơn craft và functionality — vì Claude vốn đã dễ đạt điểm cao ở craft và functionality, nhưng lại thường cho ra kết quả tầm thường về thiết kế và tính nguyên bản
  • Bộ tiêu chí còn trừ điểm rõ ràng các pattern "AI slop" rất phổ biến, để buộc mô hình chấp nhận mạo hiểm hơn về mặt thẩm mỹ
• Anthropic xây orchestration bằng Claude Agent SDK; generator tạo frontend HTML/CSS/JS, còn evaluator dùng Playwright MCP để tương tác trực tiếp với trang chạy thật, chụp ảnh màn hình, kiểm tra kỹ phần triển khai rồi chấm điểm và viết nhận xét chi tiết
  • Mỗi lần sinh lặp 5–15 vòng, trong đó generator phản hồi lại phê bình của evaluator và dần chuyển sang các hướng độc đáo hơn
  • Toàn bộ quá trình có thể kéo dài tối đa 4 giờ
  • Sau mỗi lần đánh giá, generator được yêu cầu ra quyết định chiến lược: nếu xu hướng điểm số tốt thì tiếp tục cải thiện hướng hiện tại; nếu cách tiếp cận không hiệu quả thì chuyển hẳn sang một thẩm mỹ khác
• Cách diễn đạt của bộ tiêu chí lại ảnh hưởng đến generator theo các cách không ngờ — những câu như "thiết kế tốt nhất đạt chất lượng bảo tàng" khiến đầu ra hội tụ về một số đặc trưng thị giác nhất định; tức bộ tiêu chí và ngôn ngữ prompt liên quan trực tiếp định hình cá tính của sản phẩm tạo ra
• Điểm số nhìn chung tăng dần qua các vòng lặp nhưng không phải lúc nào cũng tuyến tính; cũng khá thường xuyên có trường hợp vòng giữa được ưa thích hơn vòng cuối
  • Độ phức tạp triển khai có xu hướng tăng dần theo các vòng, do generator theo phản hồi của evaluator để theo đuổi các giải pháp tham vọng hơn
  • Ngay từ vòng đầu tiên, kết quả đã tốt hơn rõ rệt so với baseline không prompt; bản thân bộ tiêu chí và ngôn ngữ liên quan đã đủ kéo mô hình rời khỏi các mặc định chung chung ngay cả trước khi nhận phản hồi từ evaluator
• Ví dụ website bảo tàng nghệ thuật Hà Lan: đến vòng lặp thứ 9, hệ thống tạo ra một landing page dark theme gọn gàng; nhưng ở vòng 10, nó vứt bỏ toàn bộ cách tiếp cận đó và tái hình dung thành một trải nghiệm không gian với căn phòng 3D render bằng CSS perspective, sàn caro, tác phẩm treo tự do trên tường và điều hướng giữa các gallery qua cửa ra vào — một cú nhảy sáng tạo kiểu hiếm thấy trong sinh một lượt duy nhất

Mở rộng sang coding full-stack

Kiến trúc

• Trong harness chạy dài hạn trước đó, Anthropic đã xử lý được việc coding nhất quán qua nhiều phiên bằng tác tử khởi tạo, các tác tử coding theo từng tính năng, và context reset giữa các phiên
  • Với Sonnet 4.5, context reset là cốt lõi vì lo âu ngữ cảnh; nhưng ở Opus 4.5, hành vi này hầu như biến mất, nên có thể thực hiện toàn bộ quá trình build trong một phiên liên tục mà không cần context reset
  • Automatic compaction của Claude Agent SDK xử lý việc ngữ cảnh tăng dần
• Hệ thống được tổ chức thành 3 tác tử:
  • Planner: mở rộng một prompt ngắn 1–4 câu thành đặc tả sản phẩm hoàn chỉnh — prompt được thiết kế để tập trung vào bối cảnh sản phẩm và thiết kế kỹ thuật ở mức cao thay vì chi tiết triển khai, vì nếu định sẵn chi tiết kỹ thuật quá sớm thì sai sót có thể lan truyền xuống các bước sau
    • Planner còn được yêu cầu tìm cơ hội đan AI feature vào đặc tả sản phẩm
  • Generator: lấy từng tính năng từ đặc tả theo đơn vị sprint, triển khai bằng stack React/Vite/FastAPI/SQLite (sau đó là PostgreSQL), cuối mỗi sprint tự đánh giá rồi handoff sang QA, đồng thời quản lý phiên bản bằng git
  • Evaluator: dùng Playwright MCP để click-through ứng dụng đang chạy như người dùng thật, kiểm tra chức năng UI, API endpoint và trạng thái cơ sở dữ liệu — chấm điểm theo các tiêu chí về độ sâu sản phẩm, tính năng, thiết kế thị giác và chất lượng code; nếu không đạt ngưỡng cứng ở từng tiêu chí thì sprint bị xem là thất bại
• Trước mỗi sprint, generator và evaluator sẽ thương lượng một sprint contract — tức cùng thống nhất định nghĩa "hoàn thành" của khối công việc đó trước khi viết code
  • Do đặc tả sản phẩm được cố ý giữ ở mức cao, đây là bước lấp khoảng cách giữa user story và phần triển khai có thể kiểm thử
  • Việc giao tiếp được xử lý theo kiểu dựa trên file — một tác tử ghi file, tác tử còn lại đọc và phản hồi

Kết quả chạy harness: công cụ làm game retro

• Hệ thống được thử bằng prompt: "Hãy tạo một trình làm game retro 2D có level editor, sprite editor, hành vi thực thể và chế độ test có thể chơi được"
• Tác tử đơn: 20 phút / 9 USD so với full harness: 6 giờ / 200 USD — harness đắt hơn hơn 20 lần, nhưng chênh lệch chất lượng kết quả là điều thấy rõ ngay lập tức
• Kết quả tác tử đơn: màn hình đầu nhìn có vẻ đúng kỳ vọng, nhưng khi bắt đầu bấm thử thì lộ vấn đề — bố cục lãng phí không gian, workflow cứng nhắc, đáng lẽ phải tạo sprite và entity trước nhưng UI không hướng dẫn điều đó, và quan trọng nhất là game thật sự không chạy (entity xuất hiện trên màn hình nhưng không phản hồi input, kết nối giữa định nghĩa entity và runtime của game bị đứt)
• Kết quả chạy harness: planner mở rộng prompt một câu thành 16 đặc tả tính năng trải trên 10 sprint — bao gồm hệ thống animation cho sprite, template hành vi, hiệu ứng âm thanh và nhạc, trình tạo sprite và thiết kế level có AI hỗ trợ, cùng tính năng xuất game thành link có thể chia sẻ
  • Hệ thống còn tận dụng kỹ năng thiết kế frontend để sinh ra ngôn ngữ thiết kế thị giác của ứng dụng như một phần trong đặc tả
  • Canvas dùng toàn bộ viewport, kích thước panel hợp lý, và có bản sắc hình ảnh nhất quán theo đúng hướng thiết kế trong đặc tả
  • Sprite editor đầy đủ tính năng hơn, hoàn thiện hơn, có bảng công cụ gọn gàng hơn, bộ chọn màu tốt hơn và điều khiển zoom dễ dùng hơn
  • Tích hợp AI giúp tăng tốc workflow bằng cách tạo các phần khác nhau của game thông qua prompting
• Khác biệt cốt lõi ở chế độ chơi: bản chạy tác tử đơn thì game không hoạt động, còn bản chạy harness thì thực sự có thể di chuyển entity và chơi game — vẫn có vài chỗ thô như engine vật lý hơi gượng (platform chồng lên nhân vật) và giới hạn trong việc AI bố trí level (có tường quá cao không thể nhảy qua), nhưng chức năng cốt lõi hoạt động được
• Evaluator giữ cho phần triển khai bám sát đặc tả — chỉ riêng Sprint 3, hợp đồng cho level editor đã bao phủ 27 tiêu chí rất chi tiết
  • Ví dụ các lỗi được phát hiện: công cụ tô hình chữ nhật chỉ đặt tile ở điểm đầu và điểm cuối khi kéo, lỗi điều kiện trong key handler xóa entity, vấn đề thứ tự route FastAPI khiến reorder bị parse thành số nguyên và trả về lỗi 422
• Việc tinh chỉnh evaluator đòi hỏi rất nhiều công sức — ở trạng thái mặc định, Claude là một QA agent kém: ngay cả khi phát hiện vấn đề chính đáng, nó vẫn có xu hướng tự thuyết phục mình rằng "không nghiêm trọng" và cho qua; nó cũng dễ bỏ sót bug tinh vi vì chỉ test hời hợt
  • Chỉ sau khi lặp lại nhiều vòng phát triển: đọc log của evaluator, tìm các trường hợp phán đoán bị lệch, rồi cập nhật prompt QA, Anthropic mới đạt được cách chấm điểm hợp lý

Cải tiến lặp lại cho harness

• Kết quả ban đầu rất đáng khích lệ nhưng lớn, chậm và đắt, nên bước tiếp theo là đơn giản hóa harness mà không làm giảm hiệu năng
  • Mọi thành phần trong harness đều mã hóa một giả định rằng mô hình tự nó không làm được việc nào đó, và các giả định này đáng để stress test — vì khi mô hình cải thiện, chúng có thể nhanh chóng trở nên lỗi thời
  • Nguyên tắc là: "tìm giải pháp đơn giản nhất có thể, chỉ tăng độ phức tạp khi thực sự cần"
• Nỗ lực đơn giản hóa triệt để không tái tạo được hiệu năng gốc; đồng thời khó xác định mảnh nào thật sự đang gánh tải, nên Anthropic chuyển sang cách tiếp cận có hệ thống hơn: gỡ từng thành phần một
• Sự ra mắt của Opus 4.6 cũng là động lực để giảm độ phức tạp của harness — mô hình lập kế hoạch cẩn thận hơn, duy trì tác vụ mang tính agentic lâu hơn, hoạt động ổn định hơn trên codebase lớn, review/debug tốt hơn trong việc phát hiện lỗi của chính mình, và cả khả năng truy xuất trong ngữ cảnh dài cũng cải thiện đáng kể

Loại bỏ cấu trúc sprint

• Anthropic đã loại bỏ hoàn toàn cấu trúc sprint — nhờ khả năng tốt hơn của Opus 4.6, mô hình có thể xử lý công việc một cách nhất quán mà không cần tách nhỏ
• Planner và evaluator vẫn được giữ lại — nếu không có planner, generator sẽ thiếu scope, bắt đầu build chỉ từ raw prompt mà không có đặc tả, từ đó tạo ra ứng dụng ít tính năng hơn
• Evaluator được chuyển từ kiểu chấm điểm theo từng sprint sang một lượt đánh giá duy nhất ở cuối quá trình chạy
  • Nếu tác vụ nằm trong phạm vi mà mô hình tự làm được một cách ổn định, evaluator chỉ là overhead không cần thiết; nhưng với các tác vụ ở ranh giới năng lực mô hình, nó vẫn mang lại cải thiện thực chất
  • Vì vậy evaluator không phải câu trả lời yes/no cố định; nó đáng với chi phí khi phạm vi nhiệm vụ vượt qua vùng mà mô hình hiện tại có thể tự xử lý ổn định
• Anthropic cũng bổ sung prompting để cải thiện việc build AI feature — cần khá nhiều vòng lặp để khiến generator xây đúng các agent phù hợp được vận hành qua công cụ cho các tính năng ngay bên trong ứng dụng, vì kiến thức liên quan còn mới nên dữ liệu huấn luyện của Claude chỉ bao phủ mỏng

Kết quả harness đã cập nhật: DAW trên trình duyệt

• Hệ thống được thử bằng prompt: "Hãy build một DAW đầy đủ chức năng trong trình duyệt bằng Web Audio API"
• Tổng cộng mất khoảng 4 giờ, 124,70 USD
  • Planner 4,7 phút / 0,46 USD, build round 1: 2 giờ 7 phút / 71,08 USD, QA round 1: 8,8 phút / 3,24 USD, build round 2: 1 giờ 2 phút / 36,89 USD, QA round 2: 6,8 phút / 3,09 USD, build round 3: 10,9 phút / 5,88 USD, QA round 3: 9,6 phút / 4,06 USD
• Builder chạy nhất quán hơn 2 giờ mà không cần tách thành sprint
• Phản hồi đầu tiên từ QA agent: độ trung thành về thiết kế, AI agent và backend đều tốt, nhưng độ hoàn chỉnh chức năng là điểm thất bại chính — không thể kéo/di chuyển clip trên timeline, không có panel UI cho nhạc cụ (núm synth, drum pad), không có editor hiệu ứng trực quan (đường cong EQ, đồng hồ compressor)
• Phản hồi QA vòng 2: ghi âm vẫn chỉ là stub, chưa có resize và split clip, phần hiển thị hiệu ứng chỉ là slider số chứ không phải đồ họa
• Ứng dụng cuối cùng: vẫn chưa đạt đến mức của phần mềm sản xuất âm nhạc chuyên nghiệp, và năng lực sáng tác nhạc của agent vẫn cần cải thiện; vì Claude không thực sự nghe được âm thanh, vòng phản hồi QA cũng kém hiệu quả hơn về mặt gu âm nhạc
  • Tuy nhiên, nó đã có những thành phần cốt lõi của một chương trình làm nhạc hoạt động được, bao gồm arrangement view, mixer và transport
  • Chỉ bằng prompting cũng có thể tạo ra các đoạn nhạc ngắn — agent thiết lập tempo và key, đặt melody, tạo drum track, chỉnh mức mixer và thêm reverb

Triển vọng phía trước

• Khi mô hình tiếp tục cải thiện, có thể kỳ vọng chúng xử lý được các tác vụ dài hơn và phức tạp hơn; trong một số trường hợp, tầm quan trọng của scaffold bao quanh mô hình sẽ giảm đi, nên chỉ cần chờ thế hệ mô hình tiếp theo là một số vấn đề có thể tự được giải quyết
• Ngược lại, mô hình càng tốt thì không gian để phát triển harness cho các tác vụ phức tạp hơn mức baseline cũng càng mở rộng
• Những bài học cốt lõi:
  • Luôn là thực hành tốt khi thử nghiệm trực tiếp với mô hình mục tiêu, đọc trace trên các vấn đề thực tế và tinh chỉnh hiệu năng để khớp với kết quả mong muốn
  • Với các tác vụ phức tạp hơn, việc phân rã bài toán và áp dụng các tác tử chuyên biệt cho từng khía cạnh có thể tạo ra thêm dư địa
  • Khi mô hình mới ra mắt, nên rà soát lại harness để loại bỏ những phần không còn thực sự gánh hiệu năng, đồng thời bổ sung các phần mới nhằm đạt được những năng lực lớn hơn trước đây vốn bất khả thi
• Ngay cả khi mô hình tốt lên, không gian các tổ hợp harness thú vị không hề thu hẹp mà chỉ dịch chuyển; nhiệm vụ của kỹ sư AI là tiếp tục tìm ra tổ hợp mới tiếp theo