Để coding agent làm việc với ít sự giám sát hơn, ta cần cách tăng độ tin cậy vào kết quả của nó. Là kỹ sư phần mềm, ta vốn có một rào cản niềm tin tự nhiên với code do AI sinh ra: LLM không tất định (non-deterministic), chúng không biết bối cảnh của ta, và chúng không thực sự “hiểu” code, chúng nghĩ bằng token. Bài viết này của Birgitta Böckeler (Thoughtworks) trình bày một mô hình tư duy kết hợp các khái niệm đang nổi lên từ context engineering và harness engineering, để xây dựng niềm tin đó.
Bài này cập nhật một memo trước đó về những ấn tượng đầu tiên của tác giả về harness engineering.
Từ “harness” nổi lên như một cách gọi tắt cho mọi thứ trong một AI agent trừ bản thân model - agent = model + harness. Đó là một định nghĩa rất rộng, nên đáng để thu hẹp lại cho các nhóm agent phổ biến. Tác giả muốn thu hẹp định nghĩa này trong phạm vi cụ thể: dùng một coding agent. Với coding agent, một phần harness đã được xây sẵn (qua system prompt, cơ chế truy xuất code, hay cả một hệ thống điều phối phức tạp). Nhưng coding agent cũng cho người dùng rất nhiều tính năng để tự xây một harness “bên ngoài” riêng cho use case và hệ thống của họ.
Một harness bên ngoài được xây tốt phục vụ hai mục tiêu: tăng xác suất agent làm đúng ngay từ đầu, và cung cấp một feedback loop giúp tự sửa càng nhiều vấn đề càng tốt trước khi chúng lọt vào mắt con người. Cuối cùng, nó nên giảm bớt công sức review và tăng chất lượng hệ thống, kèm theo lợi ích phụ là ít tốn token hơn.
Feedforward và feedback
Phần tiêu đề “Feedforward và feedback”Để “harness hoá” một coding agent, ta vừa dự đoán trước những output không mong muốn và cố ngăn chúng, vừa đặt các sensor để agent tự sửa:
- Guide (kiểm soát feedforward) - dự đoán trước hành vi của agent và cố định hướng nó trước khi nó hành động. Guide tăng xác suất agent tạo ra kết quả tốt ngay lần thử đầu tiên.
- Sensor (kiểm soát feedback) - quan sát sau khi agent hành động và giúp nó tự sửa. Đặc biệt mạnh khi chúng tạo ra tín hiệu được tối ưu cho việc LLM tiêu thụ, ví dụ thông báo linter tuỳ biến kèm chỉ dẫn tự sửa - một dạng “prompt injection” tích cực.
Nếu chỉ dùng riêng lẻ, bạn sẽ có hoặc một agent cứ lặp lại cùng một lỗi (chỉ có feedback), hoặc một agent mã hoá sẵn luật nhưng chẳng bao giờ biết luật đó có hiệu quả hay không (chỉ có feedforward).
Computational và Inferential
Phần tiêu đề “Computational và Inferential”Có hai kiểu thực thi của guide và sensor:
- Computational (tính toán) - tất định và nhanh, chạy bởi CPU. Test, linter, type checker, phân tích cấu trúc. Chạy trong mili giây đến vài giây; kết quả đáng tin cậy.
- Inferential (suy luận) - phân tích ngữ nghĩa, AI review code, “LLM làm giám khảo”. Thường chạy bởi GPU hoặc NPU. Chậm hơn, tốn kém hơn; kết quả kém tất định hơn.
Guide computational tăng xác suất có kết quả tốt bằng công cụ tất định. Sensor computational đủ rẻ và nhanh để chạy trên mọi thay đổi, song song với agent. Kiểm soát inferential dĩ nhiên tốn kém và kém tất định hơn, nhưng cho phép ta vừa cung cấp hướng dẫn phong phú, vừa thêm phán đoán ngữ nghĩa. Dù không tất định, sensor inferential đặc biệt tăng độ tin cậy khi dùng với một model mạnh, hay đúng hơn là một model phù hợp với tác vụ đang xét.
Ví dụ
| Hướng | Computational / Inferential | Cách triển khai ví dụ | |
|---|---|---|---|
| Quy ước coding | feedforward | Inferential | AGENTS.md, Skill |
| Chỉ dẫn cách khởi tạo một dự án mới | feedforward | Cả hai | Skill kèm chỉ dẫn và script khởi tạo |
| Code mod (biến đổi code tự động) | feedforward | Computational | Một tool có quyền truy cập các recipe OpenRewrite |
| Structural test (test cấu trúc) | feedback | Computational | Một hook pre-commit (hoặc hook của coding agent) chạy test ArchUnit kiểm tra vi phạm ranh giới module |
| Chỉ dẫn cách review | feedback | Inferential | Skill |
Vòng lặp điều khiển (steering loop)
Phần tiêu đề “Vòng lặp điều khiển (steering loop)”Việc của con người trong bức tranh này là điều khiển (steer) agent bằng cách liên tục cải tiến harness. Bất cứ khi nào một vấn đề xảy ra nhiều lần, các kiểm soát feedforward và feedback nên được cải thiện để giảm xác suất vấn đề đó xảy ra lần nữa, hoặc thậm chí ngăn hẳn nó.
Trong vòng lặp điều khiển này, ta dĩ nhiên cũng có thể dùng AI để cải thiện chính harness. Coding agent giờ khiến việc xây kiểm soát tuỳ biến và phân tích tĩnh tuỳ biến rẻ hơn nhiều. Agent có thể giúp viết structural test, sinh bản nháp luật từ các mẫu hình đã quan sát được, dựng khung linter tuỳ biến, hoặc tạo how-to guide từ việc “khảo cổ” codebase.
Thời điểm: giữ chất lượng “dịch sang trái”
Phần tiêu đề “Thời điểm: giữ chất lượng “dịch sang trái””Các team làm continuous integration luôn phải đối mặt với bài toán phân bổ test, kiểm tra và review của con người xuyên suốt timeline phát triển, tuỳ theo chi phí, tốc độ và mức độ quan trọng. Khi bạn hướng tới continuous delivery, lý tưởng nhất là muốn mọi trạng thái commit đều có thể deploy được. Bạn muốn có kiểm tra càng sớm càng tốt trên đường đi tới production, vì phát hiện vấn đề càng sớm thì sửa càng rẻ. Các sensor feedback, kể cả loại inferential mới, cần được phân bổ xuyên suốt vòng đời tương ứng.
Feedforward và feedback trong vòng đời một thay đổi
- Cái gì đủ nhanh và nên chạy ngay trước khi tích hợp, hoặc thậm chí trước khi một commit được tạo ra? (ví dụ: linter, bộ test nhanh, code review agent cơ bản)
- Cái gì tốn kém hơn và vì vậy chỉ nên chạy sau khi tích hợp trong pipeline, thêm vào bên cạnh việc lặp lại các kiểm soát nhanh? (ví dụ: mutation testing, một code review rộng hơn có thể tính đến bức tranh toàn cảnh)
Sensor giám sát drift và sức khoẻ liên tục
- Loại drift nào tích luỹ dần dần và nên được giám sát bởi sensor chạy liên tục trên codebase, nằm ngoài vòng đời của một thay đổi? (ví dụ: phát hiện dead code, phân tích chất lượng test coverage, dependency scanner)
- Agent có thể giám sát loại feedback runtime nào? (ví dụ: cho agent theo dõi SLO đang xuống cấp để đề xuất cách cải thiện, hoặc AI giám khảo liên tục lấy mẫu chất lượng phản hồi và gắn cờ các bất thường trong log)
Các nhóm điều tiết (regulation categories)
Phần tiêu đề “Các nhóm điều tiết (regulation categories)”Harness của agent hoạt động như một bộ điều chỉnh (governor) kiểu điều khiển học (cybernetic), kết hợp feedforward và feedback để điều tiết codebase hướng về trạng thái mong muốn. Việc phân biệt nhiều chiều của trạng thái mong muốn đó rất hữu ích, phân loại theo việc harness được kỳ vọng điều tiết cái gì. Phân biệt các nhóm này hữu ích vì khả năng “harness hoá” và độ phức tạp khác nhau giữa các nhóm, và việc định danh rõ ràng giúp ta có ngôn ngữ chính xác hơn cho một thuật ngữ vốn rất chung chung.
Ba nhóm sau đây có vẻ hữu ích ở thời điểm hiện tại:
Harness cho khả năng bảo trì (maintainability harness)
Phần tiêu đề “Harness cho khả năng bảo trì (maintainability harness)”Gần như tất cả ví dụ trong bài này đều nói về điều tiết chất lượng code nội bộ và khả năng bảo trì. Đây hiện là loại harness dễ xây nhất, vì ta đã có sẵn rất nhiều công cụ có thể tận dụng.
Để phản ánh mức độ các ý tưởng harness bảo trì này thực sự tăng niềm tin vào agent, tác giả đã đối chiếu chúng với danh mục các chế độ lỗi phổ biến của coding agent mà cô từng liệt kê trước đây.
Sensor computational bắt được các vấn đề cấu trúc một cách đáng tin cậy: code trùng lặp, độ phức tạp cyclomatic, thiếu test coverage, kiến trúc bị trôi dạt (drift), vi phạm style. Đây là những kiểm soát rẻ, đã được kiểm chứng, và tất định.
LLM có thể xử lý một phần các vấn đề cần phán đoán ngữ nghĩa - code trùng lặp về mặt ngữ nghĩa, test dư thừa, các bản sửa “brute-force”, giải pháp over-engineer - nhưng tốn kém và mang tính xác suất. Không chạy được trên mọi commit.
Cả hai loại đều không bắt được đáng tin cậy một số vấn đề tác động lớn hơn: chẩn đoán sai vấn đề, over-engineering và tính năng không cần thiết, hiểu sai chỉ dẫn. Đôi khi chúng bắt được, nhưng không đủ đáng tin cậy để giảm bớt sự giám sát. Tính đúng đắn (correctness) nằm ngoài phạm vi của bất kỳ sensor nào, nếu ngay từ đầu con người không nói rõ mình muốn gì.
Harness cho tính phù hợp kiến trúc (architecture fitness harness)
Phần tiêu đề “Harness cho tính phù hợp kiến trúc (architecture fitness harness)”Nhóm này gồm các guide và sensor định nghĩa và kiểm tra đặc tính kiến trúc của ứng dụng. Về cơ bản: các Fitness Function.
Ví dụ:
- Skill đưa trước (feed forward) yêu cầu hiệu năng, và performance test đưa phản hồi (feed back) lại cho agent biết nó có cải thiện hay làm xấu đi các yêu cầu đó không.
- Skill mô tả quy ước coding để observability tốt hơn (như chuẩn logging), và chỉ dẫn debug yêu cầu agent tự phản ánh lại chất lượng log mà nó có sẵn.
Harness cho hành vi (behaviour harness)
Phần tiêu đề “Harness cho hành vi (behaviour harness)”Đây là “con voi trong phòng” - làm sao ta định hướng và cảm nhận được liệu ứng dụng có hành xử đúng chức năng như ta cần hay không? Ở thời điểm hiện tại, phần lớn người trao mức độ tự chủ cao cho coding agent làm như sau:
- Feed-forward: một đặc tả chức năng (mức độ chi tiết khác nhau, từ một prompt ngắn đến mô tả nhiều file)
- Feed-back: kiểm tra xem bộ test do AI sinh ra có “xanh” (pass) không, có coverage đủ cao không, một số người còn giám sát chất lượng test bằng mutation testing. Rồi kết hợp với testing thủ công.
Cách tiếp cận này đặt quá nhiều niềm tin vào test do AI sinh ra, điều đó chưa đủ tốt. Một số đồng nghiệp của tác giả thấy kết quả tốt với mẫu hình “approved fixtures” (fixture đã được duyệt), nhưng nó dễ áp dụng ở một số mảng hơn mảng khác. Họ dùng nó có chọn lọc ở nơi phù hợp, đây không phải câu trả lời toàn diện cho bài toán chất lượng test.
Nhìn chung, vẫn còn rất nhiều việc phải làm để tìm ra harness tốt cho hành vi chức năng, đủ để tăng niềm tin và giảm bớt sự giám sát cùng testing thủ công.
Khả năng “harness hoá” (harnessability)
Phần tiêu đề “Khả năng “harness hoá” (harnessability)”Không phải codebase nào cũng dễ “harness hoá” như nhau. Một codebase viết bằng ngôn ngữ kiểu tĩnh mạnh tự nhiên có sẵn type-checking như một sensor; ranh giới module được định nghĩa rõ ràng tạo điều kiện cho luật ràng buộc kiến trúc; các framework như Spring trừu tượng hoá bớt chi tiết mà agent thậm chí không cần bận tâm, nhờ đó ngầm tăng xác suất thành công của agent. Không có những đặc tính đó, các kiểm soát này không có sẵn để xây dựng.
Harness template
Phần tiêu đề “Harness template”Hầu hết doanh nghiệp chỉ có một vài kiểu topology dịch vụ phổ biến, bao phủ 80% nhu cầu của họ: dịch vụ nghiệp vụ phơi bày dữ liệu qua API; dịch vụ xử lý sự kiện; dashboard dữ liệu. Trong nhiều tổ chức kỹ thuật trưởng thành, các topology này đã được mã hoá sẵn thành service template. Chúng có thể tiến hoá thành harness template trong tương lai: một gói guide và sensor “buộc dây” coding agent vào cấu trúc, quy ước và tech stack của một topology. Các team có thể bắt đầu chọn tech stack và cấu trúc dựa một phần vào việc đã có sẵn harness nào cho chúng hay chưa.
Vai trò của con người
Phần tiêu đề “Vai trò của con người”Là developer con người, ta mang theo kỹ năng và kinh nghiệm của mình như một harness ngầm cho mọi codebase. Ta đã thấm nhuần quy ước và thực hành tốt, ta đã cảm nhận nỗi đau nhận thức của sự phức tạp, và ta biết tên mình gắn trên commit. Ta cũng mang theo sự gắn kết với tổ chức: nhận thức về việc team đang cố đạt được gì, khoản nợ kỹ thuật nào được chấp nhận vì lý do kinh doanh, và “tốt” trong bối cảnh cụ thể này trông như thế nào. Ta đi từng bước nhỏ theo nhịp độ của con người, tạo ra không gian tư duy để kinh nghiệm đó được kích hoạt và áp dụng.
Một coding agent không có bất kỳ điều nào trong số này: không có trách nhiệm giải trình xã hội, không cảm thấy ghê tởm về mặt thẩm mỹ trước một hàm dài 300 dòng, không có trực giác “ở đây bọn mình không làm vậy”, và không có ký ức tổ chức. Nó không biết quy ước nào là “chịu lực” (load-bearing) và quy ước nào chỉ là thói quen, hay liệu giải pháp đúng về mặt kỹ thuật có phù hợp với điều team đang cố làm hay không.
Harness là một nỗ lực để ngoại hiện hoá và làm tường minh những gì kinh nghiệm của developer con người mang lại, nhưng nó chỉ đi được đến một mức nhất định. Xây một hệ thống mạch lạc gồm guide, sensor và vòng lặp tự sửa là tốn kém, nên ta phải ưu tiên với một mục tiêu rõ ràng trong đầu: một harness tốt không nhất thiết nhắm tới việc loại bỏ hoàn toàn sự can thiệp của con người, mà là hướng sự can thiệp đó tới nơi nó quan trọng nhất.
Một điểm khởi đầu - và những câu hỏi còn bỏ ngỏ
Phần tiêu đề “Một điểm khởi đầu - và những câu hỏi còn bỏ ngỏ”Mô hình tư duy được trình bày ở đây mô tả các kỹ thuật đã đang diễn ra trong thực tế, và giúp đóng khung các cuộc thảo luận về những gì ta còn cần tìm hiểu thêm. Mục tiêu của nó là nâng cuộc trò chuyện lên trên mức tính năng đơn lẻ - từ skill và MCP server, tới cách ta thiết kế chiến lược một hệ thống kiểm soát mang lại niềm tin thực sự vào những gì agent tạo ra.
Một vài ví dụ liên quan tới harness từ các cuộc thảo luận hiện tại:
- Một team tại OpenAI đã ghi lại harness của họ trông như thế nào: kiến trúc phân lớp được áp đặt bởi linter tuỳ biến và structural test, cùng việc “thu gom rác” định kỳ quét tìm drift và để agent đề xuất sửa. Kết luận của họ: “Thách thức khó nhất của chúng tôi hiện giờ xoay quanh việc thiết kế môi trường, feedback loop, và hệ thống kiểm soát.”
- Bài viết của Stripe về các “minion” của họ mô tả những thứ như pre-push hook chạy linter liên quan dựa trên một heuristic, họ nhấn mạnh tầm quan trọng của việc “dịch feedback sang trái”, và các “blueprint” của họ cho thấy cách họ tích hợp sensor feedback vào workflow của agent.
- Mutation testing và structural testing là ví dụ về sensor feedback computational từng ít được dùng trong quá khứ, nhưng nay đang hồi sinh.
- Ngày càng nhiều developer bàn về việc tích hợp LSP và code intelligence vào coding agent, đây là ví dụ về guide feedforward computational.
- Tác giả nghe được nhiều câu chuyện từ các team tại Thoughtworks về việc xử lý kiến trúc bị trôi dạt bằng cả sensor computational lẫn inferential, ví dụ tăng chất lượng API bằng kết hợp agent và linter tuỳ biến, hay tăng chất lượng code bằng một “đội quân lao công” (janitor army).
Vẫn còn rất nhiều điều cần tìm hiểu, không chỉ riêng behaviour harness đã nhắc ở trên. Làm sao giữ một harness mạch lạc khi nó lớn dần, với guide và sensor đồng bộ, không mâu thuẫn nhau? Ta có thể tin agent đưa ra đánh đổi hợp lý tới đâu, khi chỉ dẫn và tín hiệu feedback trỏ về các hướng khác nhau? Nếu sensor không bao giờ kích hoạt, đó là dấu hiệu của chất lượng cao hay cơ chế phát hiện chưa đủ tốt? Ta cần một cách đánh giá độ bao phủ và chất lượng của harness, tương tự như cách code coverage và mutation testing làm với test. Các kiểm soát feedforward và feedback hiện đang rải rác khắp các bước triển khai, có tiềm năng thực sự cho công cụ giúp cấu hình, đồng bộ, và suy luận về chúng như một hệ thống thống nhất. Xây dựng harness bên ngoài này đang nổi lên như một thực hành kỹ thuật liên tục, chứ không phải một cấu hình một lần.
lượt xem
