Người kế thừa của Loop Engineering và workflow giúp chạy các agent của bạn rộng gấp 10 lần...
Hầu hết những người xây dựng một agent đa bước đều kết thúc với một đường thẳng
bước một, bước hai, bước ba. Mỗi bước đều chờ bước trước đó hoàn thành mới bắt đầu
Đây là điều hầu như không ai kiểm tra:
một nửa số bước đó chưa bao giờ cần phải chờ
Chúng chỉ xếp hàng, mỗi lần một tác vụ, cho đến khi cửa sổ ngữ cảnh đầy và agent quên mất nó đang làm gì
- Nó không chậm vì mô hình yếu
- Nó chậm vì bạn đã vẽ một đường thẳng nơi công việc thực chất là một đồ thị
Hướng dẫn này sẽ đưa bạn từ đường thẳng đó đến một đồ thị mở rộng ra trên toàn bộ đội nhóm và tự kiểm tra công việc của chính nó
Năm bước. Đến Bước 2 bạn sẽ tự xây dựng được một cái -
Nó sẽ cho bạn một đồ thị hoạt động và chỉ ra những cái bẫy có thể phá vỡ các đồ thị thực tế, và tôi sẽ đánh dấu nơi phần khó bắt đầu
trước khi alpha - hãy đăng ký substack của tôi để nhận thêm alpha mới ↓
Chương 0 - Kỹ thuật đồ thị thực sự là gì
Một tháng trước, lĩnh vực này đang nói về vòng lặp.
Peter Steinberger đã tóm gọn nó trong chín từ:
https://x.com/steipete/status/2078277297791189132
Một vòng lặp là một chu kỳ cải thiện:
thử một cái gì đó → kiểm tra kết quả → điều chỉnh → làm lại
Đó là nguyên tử: một agent duy nhất cải thiện một thứ lặp đi lặp lại
(Nếu bạn đã đọc bài viết Loop Engineering của tôi, thì đó chính là nó)
https://x.com/0xCodila/status/2072329149520232639
Nhưng vòng lặp đơn lẻ có một lỗ hổng đã biết - một nhóm hỗ trợ gắn vòng lặp phản hồi vào một chỉ số duy nhất: tỷ lệ giải quyết vé
Con số tăng lên trong nhiều tháng trong khi sự hài lòng giảm xuống. Bot đã học cách đóng vé nhanh thay vì giải quyết vấn đề
Đó là định luật Goodhart. Một vòng lặp chỉ có thể thấy chỉ số của chính nó. Nó không thể tự hỏi liệu mục tiêu có đúng hay không, hoặc nhận thấy phép đo của chính nó đang trôi dạt.
Giải pháp không phải là một vòng lặp tốt hơn. Mà là một đồ thị các vòng lặp - một mạng lưới nơi các chu kỳ theo dõi và sửa lỗi cho nhau
Đối với các agent, điều đó có nghĩa là một điều:
Đừng viết một agent làm mọi thứ trên một đường thẳng - hãy thiết kế
hình dạng
của công việc - cái gì chạy trước cái gì, cái gì chạy cùng lúc, cái gì chờ đợi.
Các nút thực hiện việc suy nghĩ. Các cạnh mang kết quả
Và Claude Code đã ra mắt công cụ để xây dựng trực tiếp những thứ này: dynamic workflows
Bước 1 - Nhìn thấy những cạnh không tồn tại
Một đồ thị có hai phần:
- Một nút là một đơn vị công việc: một agent, một tác vụ, một đầu vào, một đầu ra
- Một cạnh là một sự phụ thuộc: đầu ra của nút này cung cấp cho đầu vào của nút kia
Sai lầm mà mọi người mắc phải là coi "và sau đó" như một cạnh.
"Tóm tắt tệp này
và sau đó
cho tôi biết thời tiết"
Thời tiết không đọc bản tóm tắt.
Đó là hai tác vụ độc lập mà một kịch bản tuyến tính xích lại với nhau mà không có lý do. Mỗi cái chờ đợi cái kia mà chẳng vì gì cả
Thói quen bắt đầu mọi thứ:
Với mỗi "và sau đó," hãy hỏi - bước tiếp theo có thực sự đọc đầu ra của bước trước không?
- Nếu có → cạnh thực sự. Giữ nguyên thứ tự.
- Nếu không → không có cạnh. Sự chờ đợi là lãng phí. Hãy chạy chúng song song.
Nếu không có dữ liệu nào truyền qua giữa hai hộp, chúng độc lập.
Sự độc lập đó là thứ bạn sẽ khai thác cho phần còn lại của hướng dẫn này
Agent "làm A, rồi B, rồi C" đơn giản của bạn thực ra đã là một đồ thị - chỉ là một cái buồn nhất: một chuỗi đơn lẻ nơi nếu C bị đình trệ, D không bao giờ xảy ra.
Bước 2 - Xây dựng đồ thị đầu tiên của bạn (từ đầu đến cuối)
Đủ lý thuyết rồi. Hãy xây dựng một cái và xem nó chạy.
Trước khi bạn bắt đầu:
- Claude Code v2.1.154+ (kiểm tra bằng claude --version)
- Một gói trả phí. Trên Max, Team, hoặc Enterprise, workflows được bật theo mặc định. Trên Pro, hãy bật hàng Dynamic workflows trong /config
1. Mở một repo bạn biết.
Một repo thực tế, để kết quả có ý nghĩa.
2. Dán prompt này (từ Anthropic):
1Tạo một workflow để kiểm tra mọi tệp route trong thư mục src/routes/2xem có thiếu kiểm tra xác thực không. Tạo một agent cho mỗi tệp, sau đó chạy3một bộ xác minh độc lập trên mỗi phát hiện trước khi báo cáo.4Phân tích tối đa 20 tệp để bắt đầu.
Thay src/routes/ bằng nơi các tệp của bạn sống. Dòng "tối đa 20" giữ cho lần chạy đầu tiên của bạn rẻ.
3. Xem "workflow" sáng lên.
Claude Code làm nổi bật nó: "Dynamic workflow requested." Đó là tín hiệu cho thấy một đồ thị đang được xây dựng, không phải một cuộc trò chuyện bình thường
4. Phê duyệt kế hoạch.
Claude viết một kịch bản điều phối JavaScript và hiển thị các giai đoạn trước tiên. Đọc chúng, chọn "Yes, run it."
5. Để đội nhóm chạy.
Một agent cho mỗi tệp, song song, trong khi phiên của bạn vẫn tự do.
Gõ /workflows để xem nó trực tiếp: phạm vi, mở rộng, xác minh, tổng hợp.
6. Đọc một câu trả lời duy nhất.
Không phải hai mươi cuộc trò chuyện riêng biệt. Một báo cáo duy nhất - bởi vì các kết quả trung gian nằm trong các biến của kịch bản, không phải trong ngữ cảnh của bạn.
Đó là một đồ thị.
Hàng tá agent, từ một câu duy nhất.
Về tuyên bố "zero tokens" mà bạn sẽ nghe thấy
Kịch bản điều phối là mã
Vì vậy, việc chuyển kết quả giữa các agent không tiêu tốn lại ngữ cảnh theo cách bàn giao trò chuyện làm.
Nhưng các agent vẫn tiêu tốn chi phí sử dụng. Một workflow tốn nhiều hơn đáng kể so với một phiên bình thường.
Sự tiết kiệm nằm ở sự phối hợp, không phải ở công việc. Hãy bắt đầu với phạm vi nhỏ, theo dõi mức sử dụng, sau đó mở rộng.
- Hãy biến nó thành của bạn
Khi một lần chạy tốt, hãy nhấn s.
Nó được lưu vào ~/.claude/workflows, có thể chạy lại bằng tên
Bây giờ hãy thay đổi tác vụ và giữ nguyên hình dạng. Thay "thiếu kiểm tra xác thực" bằng "promise chưa được xử lý," hoặc "hàm dài hơn 100 dòng"
Mức độ mở rộng này (tên bài viết)
Một lần chạy workflow có thể mở rộng đến 1,000 agent, với tối đa 16 agent hoạt động cùng lúc
Đó là nơi "1000+ vòng lặp trong một cửa sổ" đến từ - không phải một phép ẩn dụ, mà là giới hạn thực tế của tính năng
- Và quy mô là điểm mấu chốt Một ngàn agent có nghĩa là một công việc mà không một ngữ cảnh đơn lẻ nào có thể chứa được - một cơ sở mã hoàn chỉnh được kiểm tra cùng lúc, một bản di chuyển chạm vào mọi tệp, một tìm kiếm chạy một ngàn góc nhìn song song
Giới hạn 16 cùng lúc chỉ có nghĩa là đội nhóm di chuyển theo từng đợt, xử lý hết tất cả một ngàn tác vụ mà không cần bạn phải giám sát từng cái một
Hãy bắt đầu với 20 để xem một lần chạy hoạt động thế nào và chi phí bao nhiêu - sau đó mở rộng ra - bởi vì đây là giới hạn mà không ai khác đang xây dựng để vượt qua
Bước 3 - Phần thực sự phá vỡ mọi thứ
Bạn đã xây dựng một đồ thị. Đây là nơi những đồ thị thực tế sụp đổ.
Hai thất bại quan trọng nhất
- Thất bại một: đồ thị tự đồng ý với chính nó
Khi một agent kiểm tra công việc của chính nó, nó sẽ dễ dãi với chính nó. Các mô hình thích đầu ra của chính chúng hơn
Vì vậy, bạn đặt một bộ xác minh trên cạnh - một nút riêng biệt xác nhận một phát hiện trước khi nó chảy xuống dưới.
Cái bẫy mà không ai nói ra: bộ xác minh cần ngữ cảnh sạch
Đưa cho nó cùng một cuộc trò chuyện mà người thực thi đã có, và nó không phải đang xác minh. Nó đang đồng ý với chính nó bằng một phông chữ khác
Một đồ thị các agent chia sẻ một ngữ cảnh là một vòng lặp đơn duy nhất trong một bộ trang phục. Nó thất bại theo cùng một cách - muộn hơn, đắt hơn, với nhiều đèn xanh hơn trên đường đi xuống
Vì vậy, bộ xác minh là một nút mới - Ngữ cảnh riêng - Kiểm tra một tín hiệu thực sự - không phải "agent có nói nó xong không," mà là "bài kiểm tra có thực sự vượt qua không"
- Thất bại hai: các agent giẫm chân lên nhau
Điều này không phải giả định
Khi nhóm của Bun lần đầu tiên mở rộng một cổng lớn qua nhiều agent, lần chạy đã thất bại về mặt vận hành và các agent đã sử dụng các lệnh git dùng chung trong một không gian làm việc và ghi đè lên nhau
Sửa chữa là về mặt cấu trúc, không phải là một prompt thông minh. Họ đã cấm các lệnh không an toàn và cấp cho mỗi nhóm worktree biệt lập riêng của nó
Đó là bài học thực sự về tính song song - hai agent viết cùng một tệp sẽ cạnh tranh nhau
Trước khi bạn mở rộng, hãy trả lời ba câu hỏi:
- Mỗi agent làm việc ở đâu?
- Kết quả hợp nhất như thế nào?
- Điều gì xảy ra khi hai agent bất đồng?
Một đồ thị không có kế hoạch đó sẽ không mở rộng được - Nó thất bại nhanh hơn
Bước 4 - Sáu đồ thị để xây dựng trong tuần này
Phương pháp: tìm các cạnh thực sự → mở rộng → xác minh trên ngữ cảnh độc lập → cô lập các worker
///
Mỗi cái trong số này đều có cùng hình dạng đó, nhắm vào một công việc mới. Thay đổi dòng tác vụ và bắt đầu:
- Quét bảo mật - một agent mỗi tệp săn tìm xác thực bị thiếu, một bộ xác minh xác nhận từng phát hiện (cái bạn đã xây dựng)
- Báo cáo có trích dẫn với /deep-research - đã được triển khai: chia câu hỏi của bạn thành các góc, tìm kiếm song song, các agent bác bỏ lẫn nhau trước khi viết
- Di chuyển một module - từng tệp một, kiểm tra như một cổng, các thất bại được vòng lại
- Đánh giá diff đối kháng - được định tuyến theo kích thước: thay đổi nhỏ → một lần vượt qua; thay đổi lớn → kiểm tra song song toàn bộ
- Quét hệ sinh thái theo lịch trình - lưu một lần, chạy lại bằng tên
- Khám phá kích thước không xác định - các công cụ tìm kiếm chạy song song, mỗi kết quả được kiểm tra với mọi thứ đã thấy, lặp lại cho đến khi hai vòng không tìm thấy gì mới
///
Giới hạn trông như thế nàohttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Việc di chuyển Bun từ Zig sang Rust đã chạy trên chính cơ chế này.
Khoảng 50 workflow, đỉnh điểm là 64 agent song song. Khoảng 535,000 dòng Zig đã được chuyển thành hơn một triệu dòng Rust, trong 11 ngày.
Nó cũng tiêu tốn khoảng $165,000 chi phí sử dụng, Cần một con người thiết kế và giám sát toàn bộ quá trình
Và nó đã vấp phải sự chỉ trích công khai về việc liệu lượng mã do AI tạo ra nhiều như vậy có thể được xem xét một cách an toàn hay không.
Quy mô là có thật. Giá cả và sự giám sát cũng vậy
Bước 5 - Những mỏ neo giữ cho đồ thị trung thực
Chỉ riêng cấu trúc liên kết không mua được sự thật
Một mạng lưới các agent tất cả đều xác nhận lẫn nhau, không ai trong số chúng chạm vào bất cứ thứ gì thực tế, thất bại giống hệt như vòng lặp đơn lẻ đã làm - chỉ với nhiều bộ phận chuyển động hơn
Đồ thị cần các mỏ neo: những nút không thể bị tranh cãi
- Các bài kiểm tra thực sự đã chạy - không phải "sẽ vượt qua," đã vượt qua
- Một bộ xác minh dựa trên bằng chứng, không phải cảm nhận
- Các quy tắc bất di bất dịch mà các agent không bao giờ được phép điều chỉnh - bởi vì chúng là những thứ mà một bộ tối ưu hóa sẽ làm suy yếu
Đồ thị chỉ trung thực bằng những thứ trong nó từ chối thay đổi
Khi nào đồ thị là lựa chọn sai
Hầu hết các tác vụ không phải là đồ thị. Sử dụng một cái khi bạn không cần nó chỉ đốt tiền và thêm cách để thất bại.
Bỏ qua đồ thị khi:
- Tác vụ nhỏ hoặc biệt lập. Thêm một hàm, sửa một lỗi. Một workflow là chi phí thuần túy ở đây - một agent đơn lẻ nhanh hơn và rẻ hơn.
- Bạn cần giám sát chặt chẽ. Nếu bạn muốn đọc và phê duyệt mọi bước trước khi bước tiếp theo chạy, toàn bộ điểm của đồ thị (chạy rộng mà không có bạn) sẽ chống lại bạn.
- Bạn chưa biết mình đang tìm kiếm thứ gì. Công việc khám phá muốn một agent duy nhất bạn có thể điều khiển, không phải một đội nhóm cam kết với một kế hoạch trước khi bạn hiểu vấn đề.
- Các bước thực sự phụ thuộc vào nhau. Nếu mọi bước đọc đầu ra của bước trước, đó là một chuỗi thực sự. Tính song song không có gì để bám vào. Ép một đồ thị lên một tác vụ tuần tự thực sự chỉ thêm chi phí phối hợp mà không tăng tốc độ.
Dấu hiệu là Bước 1. Nếu bạn không thể tìm thấy hai hộp không có mũi tên giữa chúng, không có đồ thị nào để xây dựng. Đó là một vòng lặp, và một vòng lặp là ổn.
Một đồ thị là một công cụ cho bề rộng - công việc độc lập, được thực hiện cùng lúc
Khi công việc không rộng, đường thẳng chưa bao giờ là vấn đề...
Sự chuyển đổi
Một người viết prompt đặt một câu hỏi. Một kiến trúc sư vẽ một đồ thị.
Agent tuyến tính chưa bao giờ là giới hạn.
Nó là hình dạng đầu tiên - hình dạng mà ai cũng với tới vì nó phù hợp với cách chúng ta gõ: một dòng, mỗi lần một thứ.
Một khi bạn nhìn thấy các nút và các cạnh, bạn sẽ ngừng yêu cầu agent làm nhiều hơn và bắt đầu yêu cầu đồ thị làm rộng hơn:
- Mở rộng nơi công việc độc lập
- Đóng cổng các cạnh nơi sự tin cậy quan trọng
- Đóng băng các nút nắm giữ sự thật
Hầu hết mọi người sẽ tiếp tục xếp hàng các bước trên một đường thẳng.
Số ít những người học cách vẽ đồ thị, và tôn trọng những gì phá vỡ nó, sẽ điều hành một đội nhóm.
Hãy vẽ đồ thị. Hãy là kiến trúc sư.
Bắt đầu với điều kiện tiên quyết:
- vòng lặp đơn lẻ mà cái này được xây dựng trên đó
