Loop, Graph và Harness: 3 trụ cột trong kỹ thuật AI Agent

3 Hệ Thống AI Agent Mà Mọi Builder Phải Hiểu

Những thất bại của Agent

Hầu hết các hệ thống agent thất bại không phải vì mô hình quá yếu

Chúng thất bại vì hệ thống xung quanh mô hình chưa bao giờ được thiết kế như một hệ thống thực sự

Các công cụ không đáng tin cậy

Trạng thái biến mất giữa các lần chạy

Agent thử lại mà không học được gì

Quy trình làm việc rẽ nhánh theo những cách không ai có thể kiểm tra

Rồi mọi thất bại đều đổ lỗi cho mô hình

Đó là chẩn đoán sai lầm

Có ba tầng kỹ thuật khác nhau đằng sau một agent nghiêm túc:

• harness cho mô hình một nơi để làm việc
• loop cho công việc một chu trình phản hồi
• graph cho quy trình một lộ trình rõ ràng

Chúng chồng lấn lên nhau

Chúng có thể chứa đựng lẫn nhau

Nhưng chúng giải quyết những vấn đề khác nhau

Mô hình quyết định Harness cho phép nó hành động Loop buộc nó chứng minh kết quả Graph kiểm soát những gì được phép xảy ra tiếp theo

Phiên bản 30 giây

Kỹ thuật Harness xây dựng môi trường hoạt động xung quanh mô hình

Công cụ, bộ nhớ, tệp tin, quyền, sandbox, định tuyến, điểm kiểm tra, dấu vết và phê duyệt của con người đều nằm ở đây

Kỹ thuật Loop thiết kế công việc lặp lại và phản hồi

Agent tạo ra thứ gì đó, kiểm tra nó với bằng chứng, nhận tín hiệu thất bại hữu ích và thử lại theo một quy tắc có giới hạn

Kỹ thuật Graph làm cho luồng điều khiển trở nên rõ ràng

Nó định nghĩa các nút, nhánh, điểm kết nối, công việc song song, vòng lặp hợp lệ, chuyển đổi trạng thái và đường thoát

Cách dễ nhất để nhớ sự khác biệt là:

1HARNESS = MÔI TRƯỜNG
2LOOP    = PHẢN HỒI
3GRAPH   = LUỒNG

Sự khác biệt này trở nên quan trọng ngay khi một agent rời khỏi bản demo và bắt đầu chạm vào các tệp thật, API thật, khách hàng thật, tiền thật hoặc code sản xuất

Tại sao mọi người cứ nhầm lẫn chúng với nhau

Cả ba tầng đều nằm xung quanh cùng một mô hình

Cả ba đều ảnh hưởng đến độ tin cậy

Cả ba đều có thể bao gồm thứ gì đó trông giống như một vòng lặp

Và trong một nguyên mẫu nhỏ, cả ba thường bị chôn vùi bên trong một script duy nhất

Điều đó khiến chúng có vẻ như có thể thay thế cho nhau

Thực tế thì không

Hãy xem xét một agent sử dụng công cụ cơ bản

1hỏi mô hình
2nhận lệnh gọi công cụ
3chạy công cụ
4trả về quan sát
5hỏi mô hình lại
6dừng khi hoàn thành

Vòng lặp nhỏ đó là một phần của runtime

Nhưng định nghĩa công cụ, hệ thống tệp và kho lưu trữ trạng thái thuộc về harness

Chính sách kiểm tra và thử lại là một quyết định thiết kế loop

Sự lựa chọn giữa researcher, reviewer và publisher là một quyết định thiết kế graph

Một phần mềm có thể chứa cả ba tầng cùng một lúc

Kiến trúc sạch nhất bắt đầu bằng cách đặt tên riêng cho chúng

Tầng 1: Kỹ thuật Harness

Một mô hình thô có thể biến đổi đầu vào thành đầu ra

Nó không thể độc lập duy trì trạng thái dự án, chạy bộ kiểm thử, kiểm tra trình duyệt, ghi tệp an toàn, thực thi quyền hoặc tiếp tục vào ngày mai từ nơi nó dừng lại hôm nay

Harness cung cấp những khả năng đó

Định nghĩa đơn giản nhất là:

Mô hình là trí thông minh Harness là bộ máy làm cho trí thông minh đó trở nên hữu ích

Hãy loại bỏ mô hình khỏi sơ đồ kiến trúc của bạn

Mọi thứ vẫn còn nhìn thấy có lẽ là một phần của harness

Đây là sự chuyển đổi sản xuất mà Boris Cherny liên tục chỉ ra thông qua Claude Code: hooks, các lần chạy theo lịch trình, worktrees biệt lập, agent tùy chỉnh và thực thi song song không phải là các thủ thuật prompt

Chúng là các nguyên thủy của harness

https://x.com/bcherny/status/2038454336355999749

Những gì nằm bên trong một harness nghiêm túc

Ngữ cảnh

• hướng dẫn hệ thống
• kiến thức đã truy xuất
• trạng thái hội thoại
• chính sách tác vụ
• kỹ năng và quy trình vận hành

Bề mặt hành động

• API
• điều khiển trình duyệt
• shell và thực thi code
• cơ sở dữ liệu
• công cụ MCP
• agent chuyên biệt

Tính bền vững

• tệp tin
• điểm kiểm tra
• trạng thái phiên
• nhật ký tiến độ
• lịch sử git
• bộ nhớ dài hạn

Kiểm soát thực thi

• thời gian chờ
• giới hạn thử lại
• ngân sách token và chi phí
• định tuyến mô hình
• bàn giao
• cổng phê duyệt

An toàn

• môi trường biệt lập
• quyền tối thiểu
• danh sách cho phép
• xử lý bí mật
• ủy quyền của con người

Khả năng quan sát

• dấu vết
• đầu vào và đầu ra của công cụ
• chuyển đổi trạng thái
• chi phí và độ trễ
• kết quả đánh giá

Nơi kỹ thuật Harness phát huy giá trị

Công việc harness trở nên quan trọng khi các tác vụ kéo dài hơn một cửa sổ ngữ cảnh

Một agent viết code làm việc trong nhiều giờ không thể chỉ dựa vào lịch sử trò chuyện

Nó cần các artifact bền vững mà một phiên khác có thể hiểu được

Một thiết lập hữu ích có thể bao gồm:

• một bộ khởi tạo kiểm tra workspace
• một tệp tiến độ giải thích những gì đã làm và những gì còn lại
• các commit git bảo tồn trạng thái làm việc
• điểm kiểm tra trước các hành động rủi ro
• công cụ xác minh tạo ra bằng chứng rõ ràng

Đây không phải là một prompt tốt hơn

Đây là một môi trường làm việc tốt hơn

Hãy bắt đầu với kỹ thuật harness khi agent:

• không thể truy cập đúng khả năng
• mất tiến độ giữa các phiên
• có quyền quá rộng
• hoạt động khác nhau giữa các môi trường
• không thể bị tạm dừng, kiểm tra hoặc tiếp tục
• tạo ra các lỗi mà không ai có thể tái tạo

Tầng 2: Kỹ thuật Loop

Mọi agent sử dụng công cụ đều đã có một vòng lặp nội bộ nhỏ

1mô hình -> hành động -> quan sát -> mô hình

Kỹ thuật Loop bắt đầu khi bạn chủ ý thiết kế các chu kỳ xung quanh hành vi đó

Mục tiêu không phải là bắt agent lặp lại mãi mãi

Mục tiêu là biến một nỗ lực một lần thành một quy trình được quản lý

Vòng lặp xác minh

Vòng lặp bên ngoài hữu ích nhất rất đơn giản

1XÂY DỰNG
2  ↓
3KIỂM TRA VỚI BẰNG CHỨNG
4  ↓
5ĐẠT? ── có ──> DỪNG
6  │
7  không
8  ↓
9TRẢ VỀ PHẢN HỒI CỤ THỂ
10  ↓
11THỬ LẠI VỚI GIỚI HẠN

Việc kiểm tra có thể mang tính xác định:

• kiểm thử đạt
• schema xác thực
• liên kết phân giải
• số liệu đối chiếu
• tệp biên dịch

Hoặc có thể cần một người đánh giá:

• lập luận đầy đủ
• giọng điệu phù hợp với đối tượng
• bằng chứng hỗ trợ kết luận
• thay đổi được phạm vi chính xác

Quy tắc là như nhau

Đừng lặp dựa trên sự tự tin

Hãy lặp dựa trên bằng chứng

"Agent nói nó đã hoàn thành" không phải là bằng chứng

"Kiểm thử đạt, nguồn phân giải và reviewer phê duyệt bản diff" mới là bằng chứng

Sức mạnh thực sự đến từ việc xây dựng chu kỳ một lần và để hệ thống tự động chạy nó cho bạn

Các tác vụ theo lịch trình của Claude là phiên bản sản phẩm có thể thấy của cùng một sự chuyển đổi: định nghĩa công việc định kỳ một lần và để hệ thống tự động nhập lại nó mà không cần prompt thủ công khác

Lập lịch chỉ là trình kích hoạt

Các kiểm tra, phản hồi và điều kiện thoát mới là thứ biến tác vụ định kỳ thành một vòng lặp được kỹ thuật hóa

https://x.com/claudeai/status/2026720870631354429

Giải phẫu của một vòng lặp hữu ích

Mọi vòng lặp sản xuất cần bảy thứ

1. Trình kích hoạt

Thứ bắt đầu một chu kỳ mới: một yêu cầu, lịch trình, webhook, kiểm thử thất bại, tài liệu mới hoặc kết quả đánh giá

2. Mục tiêu

Một trạng thái có thể đo lường để đạt được, không phải "tiếp tục cải thiện"

3. Trạng thái

Những gì lần thử tiếp theo phải biết mà không cần phát lại toàn bộ lịch sử

4. Chính sách hành động

Những gì agent có thể thay đổi, gọi, ủy quyền hoặc chi tiêu

5. Bằng chứng

Kiểm thử, trích dẫn, bản diff, chỉ số, schema hoặc đánh giá của con người

6. Phản hồi

Một giải thích ngắn gọn về những gì đã thất bại và những gì phải thay đổi

7. Quy tắc dừng

Thành công, số lần thử tối đa, cạn kiệt ngân sách, hết thời gian, lỗi nghiêm trọng hoặc leo thang lên con người

Các vòng lặp có thể xếp chồng

Agent loop thực hiện công việc

Verification loop kiểm tra công việc

Event loop đánh thức hệ thống khi có công việc mới

Improvement loop nghiên cứu dấu vết sản xuất và thay đổi chính harness

1EVENT LOOP
2└── VERIFICATION LOOP
3    └── AGENT LOOP
4
5TRACE IMPROVEMENT LOOP
6└── cập nhật prompts, công cụ, chính sách và graders

Đây là lý do tại sao kỹ thuật loop lớn hơn kỹ thuật prompt

Một prompt định nghĩa những gì sẽ xảy ra trong một lần gọi mô hình

Một loop định nghĩa những gì hệ thống làm sau lần gọi đó

Chi phí là rõ ràng

Mỗi lần thử lại, grader và reviewer đều thêm độ trễ và chi phí

Hãy thêm một loop khi chi phí dự kiến của thất bại cao hơn chi phí xác minh

Tầng 3: Kỹ thuật Graph

Kỹ thuật Graph đặt một câu hỏi khác

Không phải "agent nên làm việc như thế nào"

Mà là "thứ gì được phép chạy tiếp theo"

Công việc trở thành các nút

Chuyển tiếp được phép trở thành các cạnh

Trạng thái di chuyển qua graph

Cấu trúc đó có thể đại diện cho:

• trình tự cố định
• nhánh có điều kiện
• phân nhánh song song
• điểm kết nối
• vòng lặp có giới hạn
• đường phục hồi
• can thiệp của con người

Những gì kỹ sư graph thực sự quyết định

Ranh giới nút

Công việc nào thuộc về code thông thường, lời gọi LLM, agent chuyên biệt hoặc bước đánh giá của con người

Schema trạng thái

Mỗi nút có thể đọc hoặc cập nhật những gì và kết quả song song được hợp nhất như thế nào

Điều kiện định tuyến

Bằng chứng nào đưa công việc tiến lên, lùi lại, sang ngang hoặc vào leo thang

Tính đồng thời

Những gì có thể chạy song song và những gì phải chờ điểm kết nối

Vòng lặp và lối thoát

Nơi nào việc thử lại được phép, bao nhiêu lần thử được cho phép và điều gì làm cho vòng lặp an toàn

Tính bền vững

Nơi thực thi được đánh dấu và nó tiếp tục như thế nào sau khi bị gián đoạn

Khi nào graph đáng để đầu tư

Sử dụng graph khi quy trình chứa các nhánh có ý nghĩa, chuyên gia song song, phê duyệt, tuyến phục hồi hoặc bàn giao có trạng thái

Đừng bắt đầu với graph chỉ vì quy trình làm việc có nhiều bước

Nếu một agent có năng lực với ba công cụ có thể giải quyết tác vụ, graph có thể thêm cấu trúc mà không thêm giá trị

Có một kiểu thất bại khác

Các nhóm chính thức hóa quy trình làm việc trước khi họ hiểu công việc

Kết quả là một sơ đồ đẹp đẽ mã hóa những giả định sai lầm

Hãy bắt đầu với một harness đơn giản

Nghiên cứu dấu vết thực tế

Chính thức hóa các đường dẫn vẫn ổn định

Bước tiếp theo sau các loop là làm cho cấu trúc liên kết thực thi trở nên rõ ràng

OpenAI đóng gói cùng một ý tưởng vào Agent Builder: một canvas quy trình làm việc trực quan cho thực thi đa agent với guardrails và evals xung quanh graph

https://x.com/OpenAIDevs/status/1975269388195631492

Cả ba tầng hoạt động như thế nào trong một hệ thống thực tế

Hãy tưởng tượng một agent nghiên cứu và xuất bản tạo ra một bản tóm tắt ngành thực tế

Harness cung cấp:

• công cụ trình duyệt và tìm kiếm
• kho lưu trữ nguồn
• không gian làm việc viết lách
• kiểm tra trích dẫn
• quyền và quy tắc phê duyệt
• điểm kiểm tra và dấu vết

Graph kiểm soát lộ trình:

1NGHIÊN CỨU
2   ↓
3NHÁP
4   ↓
5KIỂM TRA THỰC TẾ ── thất bại ──> NGHIÊN CỨU
6   │
7  đạt
8   ↓
9ĐÁNH GIÁ BIÊN TẬP ── thất bại ──> NHÁP
10   │
11  đạt
12   ↓
13PHÊ DUYỆT CON NGƯỜI
14   ↓
15XUẤT BẢN

Các vòng lặp sống bên trong lộ trình đó

Nút nghiên cứu có thể tìm kiếm cho đến khi độ phủ nguồn đủ

Nút viết nháp có thể sửa đổi cho đến khi style grader đạt

Nút kiểm tra thực tế có thể trả về các tuyên bố không được hỗ trợ chính xác thay vì một sự từ chối mơ hồ

Sự lồng ghép là phần quan trọng

Graph chạy bên trong harness

Các vòng lặp chạy bên trong các phần của graph

Harness cung cấp các công cụ, trạng thái và bằng chứng mà các vòng lặp đó cần

Các tầng chồng lấn vì các tầng phần mềm thực tế chồng lấn

Chúng vẫn cung cấp cho bạn ba đòn bẩy khác nhau khi hệ thống thất bại

Chẩn đoán thất bại trước khi thay đổi kiến trúc

Triệu chứng

Bắt đầu với

Sửa lỗi có khả năng

Agent không thể truy cập đúng dữ liệu một cách an toàn

Harness

Hợp đồng công cụ, quyền, sandbox và tiêm ngữ cảnh tốt hơn

Agent quên tiến độ giữa các phiên

Harness

Trạng thái bền vững, điểm kiểm tra, artifact tiến độ và nén

Lần thử đầu tiên gần đúng nhưng không đáng tin cậy

Loop

Grader bên ngoài, kiểm thử xác định, phản hồi khả thi và thử lại có giới hạn

Agent tiếp tục sau thành công hoặc dừng trước khi có bằng chứng

Loop

Trạng thái kết thúc dựa trên bằng chứng và quy tắc dừng có ý thức về ngân sách

Chuyên gia phải chạy theo thứ tự kiểm soát

Graph

Các nút, cạnh, điều kiện định tuyến và điểm kết nối rõ ràng

Một thất bại nhiều bước không thể xác định vị trí

Graph + harness

Dấu vết có trạng thái phù hợp với các nút và chuyển tiếp

Quy trình thay đổi quá nhanh cho một sơ đồ cố định

Harness đơn giản hơn

Giữ cho kế hoạch do mô hình điều khiển và trì hoãn chính thức hóa graph

Bảng này hữu ích hơn là tranh luận về thuật ngữ

Tìm tầng sở hữu thất bại

Sửa tầng đó trước

Những sai lầm đắt giá đằng sau các hệ thống agent yếu kém

Xây dựng graph quá sớm

Đừng chuyển đổi một quy trình kinh doanh tưởng tượng thành bốn mươi nút trước khi xem một agent mạnh thực hiện công việc

Theo dõi trước

Chính thức hóa sau

Để người tạo tự đánh giá mình

Tự đánh giá có ích nhưng chia sẻ cùng những điểm mù với nỗ lực ban đầu

Ưu tiên kiểm tra xác định khi có thể

Sử dụng ngữ cảnh reviewer biệt lập cho các kiểm tra chủ quan

Yêu cầu phê duyệt của con người cho các hành động có tác động cao

Định nghĩa loop là "cứ thử tiếp"

Thử lại không giới hạn không phải là độ tin cậy

Đó là một rò rỉ chi phí

Mỗi chu kỳ cần bằng chứng mới, số lần thử tối đa và một đường leo thang được đặt tên

Biến harness thành một nhà kho

Nhiều công cụ hơn không tự động tạo ra agent tốt hơn

Một bộ công cụ đông đúc làm tăng lỗi lựa chọn

Ngữ cảnh nhiễu làm tăng sự nhầm lẫn

Quyền rộng làm tăng rủi ro

Hãy cho agent môi trường nhỏ nhất có thể hoàn thành công việc

Đổ lỗi cho mô hình vì các lỗi điều phối

Một mô hình mạnh hơn không thể sửa chữa một cách đáng tin cậy trạng thái cũ, API hỏng, schema công cụ mơ hồ hoặc điều kiện thoát bị thiếu

Đừng nâng cấp mô hình trước khi chứng minh mô hình là vấn đề

Danh sách kiểm tra sẵn sàng sản xuất

Harness

• các công cụ có hẹp, được tài liệu hóa và có thể quan sát không
• trạng thái có bền vững giữa các phiên không
• quyền có là tối thiểu không
• người vận hành có thể tạm dừng, kiểm tra và tiếp tục lần chạy không
• mọi hành động quan trọng có thể được tái tạo từ dấu vết không

Loop

• bằng chứng nào chứng minh thành công
• phản hồi nào được trả về sau thất bại
• bao nhiêu lần thử lại được cho phép
• điều gì xảy ra khi ngân sách cạn kiệt
• nơi nào cần phán đoán của con người

Graph

• đường dẫn nào phải mang tính xác định
• nơi nào công việc có thể chạy song song
• trạng thái nào được chia sẻ
• các điểm kết nối, phê duyệt và tuyến phục hồi ở đâu
• vòng lặp nào là hợp pháp và chúng kết thúc như thế nào

Đánh giá

• nhóm có thể phát lại dấu vết thực tế không
• các phiên bản có thể được so sánh trên cùng các tác vụ không
• một cải tiến có thể được quy cho một thay đổi cụ thể không

Vận hành

• chi phí và độ trễ có được giám sát không
• tỷ lệ thất bại có thể thấy theo nút và công cụ không
• can thiệp của con người có được đo lường không
• thành công ở cấp tác vụ có được đo lường trong sản xuất không

Cách đơn giản nhất để nhớ sự khác biệt

Kỹ thuật Harness làm cho mô hình có thể vận hành được

Kỹ thuật Loop làm cho công việc trở nên lặp đi lặp lại và có thể xác minh

Kỹ thuật Graph làm cho việc thực thi phức tạp trở nên rõ ràng và có thể kiểm soát

Không cái nào thay thế được cái nào

Một graph hoàn hảo không thể cứu một agent mất trạng thái

Một harness hoàn hảo vẫn lãng phí tiền nếu loop không có bằng chứng hoặc quy tắc dừng

Một loop mạnh trở nên khó vận hành khi các nhánh, song song và phê duyệt bị ẩn bên trong code tùy tiện

Các agent đáng tin cậy xuất hiện khi cả ba tầng được thiết kế cùng nhau

Và khi mỗi tầng có một công việc rõ ràng

1MÔI TRƯỜNG -> HARNESS
2PHẢN HỒI    -> LOOP
3LUỒNG        -> GRAPH

Đó là toàn bộ khuôn khổ

Nguồn và đọc thêm

• Tác vụ theo lịch trình của Claude
• OpenAI AgentKit
• OpenAI Agents SDK
• AutoGen GraphFlow
• Xây dựng AI Agent Hiệu quả

Nếu bạn đã đọc đến đây

Hãy đánh dấu bài viết và theo dõi @0xwhrrari để biết thêm nội dung về kỹ thuật agent thực tế

Bạn cũng có thể đọc các bài viết khác:

• Cách tôi thiết lập Obsidian + Claude làm bộ não thứ hai
• Cách tôi thiết lập Claude để thực sự hoàn thành công việc
• Cách tôi thiết lập dự án Claude để chúng thực sự hoạt động
• 30 prompt hệ thống Claude tôi thực sự dùng
• Loop Engineering: Kỹ năng AI mọi builder cần năm 2026
• 30 cài đặt, phím tắt và quy trình làm việc Claude Code hầu hết người dùng bỏ lỡ
• Cách tôi dùng Claude Cowork để vận hành như một công ty một người