Lộ trình 14 bước để chuyển từ prompt sang một đội agent làm việc cho bạ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 lịch sự chờ bước trước hoàn thành rồi mới bắt đầu.
Và hầu như không ai nhận ra rằng một nửa số bước đó chưa bao giờ phải chờ đợi bất cứ điều gì.
Chúng không định tuyến. Chúng không rẽ nhánh. Chúng không song song hóa. Chúng chỉ xếp hàng. Một đầu óc, một ngữ cảnh, một việc tại một thời điểm, cho đến khi cửa sổ đầy lên và agent quên mất nó đang làm gì.
Đây là lộ trình 14 bước biến đường thẳng một hàng đó thành một đồ thị. Một đồ thị tỏa ra trên toàn bộ một đội, xác minh các phát hiện của chính nó và hội tụ về một kết quả mà một agent đơn lẻ không bao giờ có thể duy trì.
Đến cuối cùng, bạn sẽ biết ba điều:
→ hệ thống hiện tại của bạn đang chờ đợi ở đâu mà không có lý do → làm thế nào để phân phối công việc mà không làm mất niềm tin vào đầu ra → làm thế nào để giảm hóa đơn mà không ảnh hưởng đến chất lượng
SỰ THAY ĐỔI KHUNG MÀ KHÔNG AI GIẢI THÍCH
Một prompt là một câu. Một vòng lặp là một chu kỳ. Một harness là nền tảng mà agent đứng trên đó.
Nhưng hình dạng của công việc—cái gì chạy trước cái gì, cái gì có thể chạy cùng lúc, cái gì phải chờ đợi mọi thứ khác—hình dạng đó là một đồ thị.
Các nút suy nghĩ. Các cạnh vận chuyển kết quả.
Và Claude Code đã mang đến các công cụ để xây dựng chúng trực tiếp: các workflow động.
Claude viết một script điều phối bằng JavaScript thuần và sau đó khởi chạy một đội agent phối hợp để thực thi nó. Việc điều phối tự nó tốn zero token mô hình vì nó là code, không phải một cuộc hội thoại.
Lộ trình được chia thành bốn khối:
→ 01 đến 04, nhìn thấy đồ thị bạn đã có → 05 đến 08, di chuyển đội → 09 đến 11, tin tưởng vào những gì xuất ra → 12 đến 14, đảm bảo nó không hủy hoại bạn
KHỐI 1 · NHÌN THẤY ĐỒ THỊ BẠN ĐÃ CÓ
01. CÁC NÚT LÀ NHIỆM VỤ, CÁC CẠNH LÀ LUỒNG DỮ LIỆU
Một đồ thị có chính xác hai thứ, và hiểu rõ về chúng sẽ sửa chữa hầu hết mọi sự nhầm lẫn.
→ Nút: một đơn vị công việc. Một agent, một nhiệm vụ có giới hạn, một đầu vào, một đầu ra. → Cạnh: một sự phụ thuộc. Nó nói rằng đầu ra của nút này cung cấp đầu vào cho nút kia. Không hơn.
Sai lầm là coi "và sau đó" như thể nó là một cạnh.
"Tóm tắt file này và sau đó cho tôi biết thời tiết" không có cạnh nào giữa hai phần. Báo cáo thời tiết không tiêu thụ bản tóm tắt. Chúng là hai nút không liên kết mà một script tuyến tính xích lại với nhau mà không có bất kỳ sự cần thiết nào.
Cạnh chỉ tồn tại khi dữ liệu thực sự đi qua.
Vẽ nó dưới dạng các hộp và mũi tên. Một hộp là một lệnh gọi tới agent(). Một mũi tên là một biến đi ra từ kết quả trả về của một lệnh gọi và đi vào prompt của lệnh gọi khác.
Nếu bạn không thể vẽ mũi tên, nếu không có biến nào đi qua, hai hộp đó độc lập.
Và sự độc lập đó là thứ bạn sẽ khai thác trong 13 bước tiếp theo.
→ Nguyên tắc: với mỗi "và sau đó" trong agent của bạn, hãy hỏi xem bước tiếp theo có đọc đầu ra của bước trước không. Nếu không, thời gian chờ là lãng phí.
02. SCRIPT TUYẾN TÍNH CỦA BẠN ĐÃ LÀ MỘT ĐỒ THỊ, CHỈ LÀ MỘT ĐỒ THỊ SUY BIẾN
Khi bạn viết một agent là "làm A, rồi B, rồi C, rồi D," bạn đã vẽ một đồ thị. Một chuỗi không có nhánh. Mỗi nút có chính xác một cạnh đầu vào và một cạnh đầu ra.
Nó hoạt động. Nó cũng chạy chậm và mong manh vì một chuỗi không có dự phòng: nếu C bị kẹt, D không bao giờ xảy ra, và công việc của A bị mắc kẹt ở thượng nguồn không có nơi nào để đi.
Kỹ năng thực sự đầu tiên của kỹ thuật đồ thị là vẽ lại chuỗi.
Lấy agent tuyến tính của bạn và, với mỗi mũi tên, hãy đặt câu hỏi từ bước 01.
Hầu hết các chuỗi có hai hoặc ba mũi tên không vận chuyển dữ liệu. Chúng chỉ ở đó vì đó là thứ tự bạn đã nhập chúng.
Cắt những mũi tên đó và chuỗi sụp đổ thành một thứ rộng hơn: một vài nút độc lập có thể chạy cùng một lúc, đổ vào một nút duy nhất thực sự cần tất cả chúng.
Điều này không tốn tiền, không yêu cầu công cụ mới và thường loại bỏ nhiều thời gian chờ hơn bất cứ thứ gì bạn có thể mua.
→ Nguyên tắc: trước khi thêm bất cứ thứ gì, hãy xóa các cạnh không vận chuyển dữ liệu.
03. CUNG CẤP CHO MỖI NÚT MỘT HỢP ĐỒNG
Một nút mà bạn không thể suy luận là một nút bạn không thể song song hóa.
Giải pháp là một hợp đồng: đầu vào có giới hạn, đầu ra có giới hạn, một công việc duy nhất.
→ đầu vào là những gì nút đọc, được truyền một cách rõ ràng, không bao giờ được giả định từ một cửa sổ chia sẻ → đầu ra là một hình dạng được xác định, lý tưởng nhất là được xác thực, để nút tiếp theo tiêu thụ nó mà không cần phải phỏng đoán
Trong một workflow, hợp đồng đó được thực thi bằng một schema. Khi bạn chuyển cho Claude một lệnh gọi agent() với một JSON schema, agent con buộc phải trả về dữ liệu có cấu trúc hợp lệ. Việc xác thực xảy ra ở lớp tool call, vì vậy có một lần thử lại khi nó không khớp, thay vì trả về văn bản tự do mà bạn phải phân tích và cầu mong nó ổn.
1// một nút với hợp đồng thực sự: đầu vào có giới hạn, đầu ra được xác thực, một công việc duy nhất2const ITEM = {3 type: 'object',4 additionalProperties: false,5 properties: {6 title: { type: 'string' },7 url: { type: 'string' },8 impact: { type: 'string', enum: ['high', 'medium', 'low'] },9 },10 required: ['title', 'url', 'impact'],11};1213const output = await agent(source.prompt, {14 label: `research:${source.key}`,15 schema: ITEM,16 agentType: 'general-purpose',17});
Đó là sự khác biệt giữa một nút Claude có thể kết nối vào đồ thị và một nút chỉ hoạt động khi con người đọc nó.
→ Nguyên tắc: nếu đầu ra của một nút không có hình dạng, nó không phải là một nút. Nó là một cuộc trò chuyện.
04. CẠNH CŨNG LÀ MỘT HỢP ĐỒNG, VÀ NÓ MIỄN PHÍ
Một cạnh không phải là "B đi sau A." Nó là một lời hứa về những gì đi qua: A tạo ra hình dạng này, B được xây dựng để tiêu thụ hình dạng này.
Khi bạn đặt tên cho cạnh theo dữ liệu của nó thay vì thứ tự của nó, hai điều trở nên dễ dàng:
→ bạn thấy ngay lập tức nếu cạnh là thật, vì bạn có thể hỏi liệu có thứ gì di chuyển qua nó không → bạn có thể thay đổi nút ở một trong hai đầu mà không làm hỏng đồ thị, miễn là hình dạng được duy trì
Trong thực tế, cạnh tồn tại trong JavaScript thuần. Bước rút gọn giữa fan out và tổng hợp—làm phẳng, loại bỏ trùng lặp, lọc—chỉ là code hoạt động trên các hình dạng mà các nút của bạn trả về.
Không cần agent nào ở đó.
Và đây là một trong những chiến thắng thầm lặng của việc suy nghĩ theo đồ thị: một lượng lớn những gì người ta trả tiền cho token thực ra là một cạnh, và các cạnh là miễn phí.
Sự cám dỗ là khởi chạy một agent để "kết hợp các kết quả." Hãy chống lại nó.
Nếu kết hợp có nghĩa là làm phẳng và loại bỏ trùng lặp, đó là một flatMap và một Set. Xác định, tức thời, không tốn token nào.
→ Nguyên tắc: agent dành cho phán đoán, không dành cho đường ống. Một đồ thị mà mọi cạnh đều là một agent thì đang trả tiền thuê cho chính hệ thống dây điện của nó.
KHỐI 2 · DI CHUYỂN ĐỘI
05. FAN OUT VỚI parallel()
Đây là động thái chi trả cho mọi thứ khác.
Khi bạn có N nút độc lập, N nguồn để tham khảo, N file để xem xét, N tuyến đường để kiểm toán, bạn không xích chúng lại. Bạn bảo Claude fan out chúng và chạy chúng cùng một lúc.
Trong một workflow, đó là parallel(): nó nhận một mảng các thunk, khởi chạy một agent con cho mỗi thunk, tất cả thực thi đồng thời và trả về mảng các kết quả.
Hai chi tiết làm cho nó mạnh mẽ:
→ parallel() là một rào cản. Nó chờ tất cả các thunk trước khi trả về, vì vậy giai đoạn tiếp theo thấy tập hợp hoàn chỉnh. → một thunk ném ra ngoại lệ sẽ giải quyết thành null thay vì kéo cả lô xuống, vì vậy một agent không ổn định không thể làm chìm quá trình thực thi.
Đó là lý do tại sao bạn luôn .filter(Boolean) đầu ra.
Tính đồng thời được giới hạn một cách gần đúng bởi số lõi của bạn và phần dư được xếp hàng đợi, vì vậy bạn có thể truyền một trăm thunk và tất cả chúng sẽ hoàn thành, chỉ là theo từng nhóm.
1phase('Research');23const raw = await parallel(4 SOURCES.map((f) => () =>5 agent(f.prompt, {6 label: `research:${f.key}`,7 phase: 'Research',8 schema: ITEM,9 agentType: 'general-purpose',10 }),11 ),12);1314const collected = raw.filter(Boolean); // loại bỏ null khỏi các agent thất bại
Và đây là phần quan trọng: fan out nằm trong code do Claude viết, không phải trong một cuộc trò chuyện với mô hình.
Ngữ cảnh riêng của Claude không bao giờ giữ chín nguồn cùng một lúc. Mỗi agent con tải nguồn riêng của nó và chỉ có phản hồi cuối cùng mới quay trở lại.
Đó là điều cho phép mở rộng quy mô lên hàng chục hoặc hàng trăm agent con mà không làm ngập phiên làm việc. Lớp điều phối tốn zero token vì nó không phải là một lượt suy nghĩ khác của Claude.
→ Nguyên tắc: nếu N thứ không đọc lẫn nhau, đừng xếp hàng chúng. Hãy fan out chúng.
06. ĐÓNG FAN TẠI MỘT RÀO CẢN
Một fan out chỉ hoạt động nếu có thứ gì đó thu thập nó.
Fan in là nút nơi các cạnh hội tụ. Nơi một agent, hoặc một đoạn code, nhìn thấy tất cả các kết quả thượng nguồn cùng một lúc và làm điều gì đó yêu cầu toàn bộ tập hợp: loại bỏ trùng lặp qua các nguồn, sắp xếp theo tác động, thoát sớm nếu hoàn toàn không có gì quay trở lại.
Đó là nơi duy nhất mà một rào cản xứng đáng với chi phí thời gian đồng hồ của nó.
Loại bỏ trùng lặp qua tất cả các nguồn? Rào cản, đúng.
Chỉ làm phẳng một danh sách? Đó là một cạnh, hãy làm nó inline.
1// cạnh: JS thuần, không agent, không token2const flat = collected.flatMap((c) => c.items);3log(`Đã thu thập ${flat.length} phần tử`);45phase('Curate');67// nút rào cản: cần TOÀN BỘ tập hợp để loại bỏ trùng lặp và sắp xếp8const curated = await agent(9 `Loại bỏ trùng lặp và sắp xếp những thứ này theo tác động:10${JSON.stringify(flat)}`,11 { phase: 'Curate', schema: CURATED },12);
Bài kiểm tra rất đơn giản: nếu bạn viết parallel → transform → parallel, và phép biến đổi ở giữa đó không có sự phụ thuộc nào giữa các phần tử, bạn nên sử dụng một pipeline và bỏ qua toàn bộ rào cản.
→ Nguyên tắc: chỉ rào cản khi một giai đoạn thực sự cần tất cả các kết quả trước đó cùng nhau.
07. HÌNH KIM CƯƠNG: CHIA, LÀM, HỢP NHẤT
Kết hợp fan out và fan in và bạn có cấu trúc liên kết công việc của bất kỳ đồ thị agent nghiêm túc nào: hình kim cương.
Một nút chia nhiệm vụ. Nhiều nút làm việc song song. Một nút hợp nhất nó.
Dạng chuẩn có một cái tên đáng ghi nhớ: fan out → rút gọn → tổng hợp.
→ fan out để có được bề rộng → rút gọn bằng code thuần để nén nó → tổng hợp với một agent cuối cùng viết phản hồi
Nó là bộ xương đằng sau một cuộc khảo sát thị trường, một cuộc kiểm toán phụ thuộc, một đánh giá code và một báo cáo nghiên cứu. Bạn thay đổi các nguồn và các prompt và cùng một bộ xương thích nghi.
Khi bạn thấy hình kim cương, bạn ngừng hỏi "làm thế nào để agent của tôi thực hiện nhiều bước hơn" và bắt đầu hỏi "sự phân chia ở đâu và sự hợp nhất ở đâu." Đó là câu hỏi thực sự mở rộng quy mô.
→ Nguyên tắc: đừng thiết kế các bước. Hãy thiết kế nơi nó chia và nơi nó nối.
08. ĐỊNH TUYẾN CẠNH TẠI THỜI ĐIỂM CHẠY
Không phải tất cả các đồ thị đều cố định. Đôi khi cạnh được chọn phụ thuộc vào những gì một nút tìm thấy.
Một nút định tuyến kiểm tra một kết quả và quyết định đường dẫn nào được kích hoạt. Nó phân loại ticket và rẽ nhánh đến trình xử lý chính xác. Nó xem xét kích thước của diff và chọn giữa một đánh giá nhanh hoặc khởi chạy một cuộc kiểm toán đầy đủ.
Trong một workflow, đây là một câu lệnh if hoặc switch JavaScript đơn giản trên đầu ra đã được xác thực của một nút, vì kiểm soát luồng nằm trong code.
1// nút định tuyến: một agent phân loại, code chọn cạnh2const { severity } = await agent(3 `Phân loại rủi ro của diff này:4${diff}`,5 { schema: {6 type: 'object',7 properties: { severity: { enum: ['low', 'high'] } },8 required: ['severity'],9 }},10);1112let review;13if (severity === 'high') {14 review = await parallel(FILES.map((a) => () => agent(`Kiểm toán ${a}`)));15} else {16 review = await agent(`Đánh giá nhanh ${diff}`);17}
Ở đây, tính xác định là một tính năng, không phải là một hạn chế.
Quyết định của bộ định tuyến có thể đến từ Claude, nhưng việc định tuyến là code. Nó chạy giống nhau mọi lần cho cùng một phân loại.
Phán đoán của mô hình trong nút, độ tin cậy của script trong cạnh. Không có bất ngờ nổi lên như "agent quyết định bỏ qua cuộc kiểm toán," vì việc bỏ qua đó sẽ phải được viết trong đồ thị. Và nó không có.
→ Nguyên tắc: hãy để mô hình quyết định cái này là gì và hãy để code quyết định làm gì với nó.
NGUYÊN TẮC ĐỐI LẬP (đọc trước khi tiếp tục) Một đồ thị mua bề rộng.
Nó không mua phán đoán tốt hơn.
Nếu mọi bước trong công việc của bạn cần bức tranh toàn cảnh của bước trước, việc phân phối nó giữa các agent không mang lại cho bạn một câu trả lời tốt hơn. Nó mang lại cho bạn cùng một câu trả lời, đắt hơn và muộn hơn. Đồ thị bắt đầu mang lại lợi ích tại thời điểm chính xác công việc tách thành các nhiệm vụ không bao giờ đọc kết quả của nhau. Trước khi thêm một agent duy nhất, câu hỏi duy nhất quyết định hóa đơn của bạn là:
công việc của tôi tách ra ở đâu?
Nếu nó không tách ra, hãy gắn bó với một agent và tự cứu mình 6 bước còn lại.
KHỐI 3 · TIN TƯỞNG VÀO NHỮNG GÌ XUẤT RA
09. ĐẶT MỘT BỘ XÁC MINH TRÊN CẠNH
Đòn bẩy thực sự của một đồ thị không phải là có nhiều agent hơn. Đó là cấu trúc bạn có thể xây dựng xung quanh chúng để tạo ra niềm tin.
Một nút xác minh nằm trên cạnh trước khi một kết quả được phép đi xuống. Công việc duy nhất của nó là cố gắng tiêu diệt phát hiện. Nếu nó sống sót, nó đi qua. Nếu không, nó không bao giờ đến được câu trả lời.
Và có một quy tắc cứng rắn bên dưới tất cả điều này: không bao giờ để cùng một agent chấm bài thi của chính nó. Một mô hình xem xét lại đầu ra của chính nó bỏ lỡ hầu hết các lỗi của chính nó vì nó đánh giá từ cùng một nơi nó đã mắc lỗi.
Ba mẫu hình đáng có trong tay:
→ Xác minh đối nghịch: với mỗi phát hiện, khởi chạy N người hoài nghi độc lập với lệnh bác bỏ nó. Nó chỉ ở lại nếu nó sống sót qua đa số.
→ Xác minh góc nhìn đa dạng: cung cấp cho mỗi bộ xác minh một góc độ khác nhau. Chính xác, an toàn, có thể tái tạo. Sự đa dạng bắt được các chế độ thất bại mà N kiểm tra giống hệt nhau không bao giờ tìm thấy.
→ Hội đồng giám khảo: tạo ra N lần thử từ các góc độ khác nhau, chấm điểm chúng bằng các giám khảo song song, tổng hợp từ người chiến thắng bằng cách ghép những cái tốt nhất từ những cái gần đạt.
Đây là mẫu hình đằng sau các dự án đầy tham vọng nhất được thực hiện với agent, như porting toàn bộ một runtime với đánh giá đối nghịch được nhúng trong chính vòng lặp thay vì ở cuối.
→ Nguyên tắc: không có phát hiện nào đi mà không có xác minh, và hai bộ xác minh không bao giờ hỏi cùng một câu hỏi.
10. CÔ LẬP CÁC NÚT ĐỂ MỘT THẤT BẠI KHÔNG LÀM NHIỄM ĐỘC ĐỒ THỊ
Trong một chuỗi, một thất bại lan truyền. C chết, D không bao giờ chạy, mọi thứ dừng lại.
Trong một đồ thị, thất bại nên được giữ trong nút của nó.
Điều đó đã phần nào đúng: một thunk nổ tung bên trong parallel() giải quyết thành null, vì vậy tám agent tốt trả về trong khi agent xấu ngã một mình. .filter(Boolean) của bạn là sự ngăn chặn.
Thiết kế mọi fan in để chịu đựng các đầu vào bị thiếu thay vì giả định tập hợp hoàn chỉnh.
Thất bại tinh vi nhất là các nút giẫm lên nhau. Khi nhiều agent ghi file song song, chúng xung đột.
Giải pháp là cô lập: mỗi agent chạy trong git worktree riêng của nó, làm việc trong một sandbox và sau đó merge sạch sẽ.
Chỉ dùng đến điều này khi các nút thực sự ghi song song. Nó là dây an toàn cho cấu trúc liên kết duy nhất cần nó, không phải là một khoản thuế mặc định cho mọi lần thực thi.
→ Nguyên tắc: một người ghi duy nhất cho mỗi file. Và mọi fan in chịu đựng được các khoảng trống.
11. THÊM MỘT CHU TRÌNH, NHƯNG LÀM CHO NÓ HỘI TỤ
Đôi khi bạn không biết công việc lớn đến mức nào cho đến khi bạn ở bên trong. Khám phá kích thước không xác định. Một cuộc quét lỗi nơi tìm thấy một cái tiết lộ ba cái khác.
Điều đó đòi hỏi một chu trình: một cạnh được kiểm soát trở lại một nút trước đó.
Mối nguy hiểm là rõ ràng. Một chu trình không hội tụ là một vòng lặp vô hạn khởi chạy agent cho đến khi nó làm tan chảy ngân sách của bạn.
Mẫu hình hội tụ là lặp cho đến khi cạn: tiếp tục khởi chạy các trình tìm kiếm cho đến khi K vòng liên tiếp không mang lại gì mới, sau đó dừng.
Và chi tiết làm nên hoặc phá vỡ nó, lỗi hầu như ai cũng mắc phải lần đầu tiên, là bạn loại bỏ trùng lặp dựa trên cái gì.
Loại bỏ trùng lặp dựa trên mọi thứ đã thấy, không chỉ những gì đã được xác nhận.
Nếu không, các phát hiện bị từ chối sẽ xuất hiện lại mỗi vòng, vòng lặp không bao giờ cạn và bạn đã xây dựng một cỗ máy trả tiền để khám phá lại cùng một ngõ cụt mãi mãi.
1const seen = new Set();2const confirmed = [];3let dryRounds = 0;45while (dryRounds < 2) { // dừng sau 2 vòng trống6 const found = (await parallel(7 SEARCHERS.map((b) => () => agent(b.prompt, { schema: BUGS }))8 )).filter(Boolean).flatMap((r) => r.bugs);910 const newItems = found.filter((b) => !seen.has(key(b)));11 if (!newItems.length) { dryRounds++; continue; } // không có gì mới → tiến tới khô1213 dryRounds = 0;14 newItems.forEach((b) => seen.add(key(b))); // loại bỏ trùng lặp dựa trên ĐÃ THẤY, không phải đã xác nhận1516 const judged = await parallel(newItems.map((b) => () =>17 parallel(['correct', 'security', 'repro'].map((lens) => () =>18 agent(`Phán xét "${b.desc}" từ góc độ ${lens}. Nó có thật không?`, { schema: VERDICT })))19 .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))20 ));2122 confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));23}
→ Nguyên tắc: mọi vòng lặp đều có giới hạn vòng và loại bỏ trùng lặp dựa trên mọi thứ đã thấy.
KHỐI 4 · ĐẢM BẢO NÓ KHÔNG HỦY HOẠI BẠN
12. PHÂN BỔ CÁC MÔ HÌNH KHÁC NHAU TRÊN CÁC NÚT
Không phải mọi nút đều cần mô hình tốt nhất của bạn.
Một đồ thị làm cho điều này rõ ràng theo cách mà một agent đơn lẻ không bao giờ làm được. Có các nút có giới hạn và lặp đi lặp lại—trích xuất trường này, phân loại ticket này. Và có các nút nơi phán đoán thực sự sống—tổng hợp báo cáo, phân xử phát hiện.
Chạy các nút nhàm chán trên một mô hình rẻ và chi tiêu các token đắt tiền ở nơi phán đoán quan trọng.
Trong một workflow, mỗi agent con kế thừa mô hình từ phiên làm việc của bạn trừ khi script ghi đè nó. Theo mặc định, một thực thi lớn tính phí hoàn toàn ở cấp độ phiên làm việc của bạn.
Tùy chọn mô hình trong một lệnh gọi agent() cụ thể chỉ định tuyến nút đó ở nơi khác.
Xem xét /model trước một thực thi lớn, và sau đó hạ cấp các nút fan-out lặp đi lặp lại trong khi vẫn giữ nút hợp nhất ở mức cao.
Đây là đòn bẩy biến một đồ thị ngốn token thành thứ gì đó kinh tế mà không chạm vào hình dạng của nó.
→ Nguyên tắc: mô hình đắt tiền chỉ khi phán đoán đang bị đe dọa.
13. CẤU TRÚC LIÊN KẾT LÀ CHI PHÍ VÀ ĐỘ TRỄ CỦA BẠN
Hình dạng của đồ thị không phải là mỹ phẩm. Nó là đòn bẩy lớn nhất trên thời gian đồng hồ tồn tại.
Quyết định làm mọi người vấp ngã: parallel() so với pipeline().
→ một rào cản parallel() làm cho mọi thứ chờ đợi nút chậm nhất trước khi giai đoạn tiếp theo bắt đầu → một pipeline() cho phép mỗi phần tử chảy qua tất cả các giai đoạn một cách độc lập, không có rào cản. Phần tử A có thể ở giai đoạn 3 trong khi B vẫn ở giai đoạn 1
Các phần tử nhanh kết thúc sớm thay vì bị kẹt sau các phần tử chậm.
Theo mặc định, hãy dùng pipeline. Chỉ dùng đến rào cản khi một giai đoạn thực sự cần tất cả các kết quả trước đó cùng một lúc: một lần loại bỏ trùng lặp dựa trên tập hợp, một lần thoát sớm dựa trên tổng số, một prompt so sánh "với các phát hiện khác."
"Nó trông sạch hơn" và "các giai đoạn có vẻ riêng biệt" không phải là lý do. Độ trễ rào cản là thực, có thể đo lường được và là thời gian lãng phí.
Riêng biệt không giống như đồng bộ hóa.
→ Nguyên tắc: pipeline theo mặc định, rào cản theo ngoại lệ có lý do chính đáng.
14. ĐỂ CLAUDE VẼ ĐỒ THỊ
Bước cuối cùng là ngừng vẽ đồ thị bằng tay cho những công việc bạn không thể lên kế hoạch trước.
Với các workflow động, bạn mô tả mục tiêu và Claude tự viết script điều phối: phân rã nhiệm vụ, chọn fan out, khởi chạy một đội agent phối hợp và tổng hợp kết quả.
Bạn có được một đồ thị phù hợp với thực thi cụ thể đó thay vì một đồ thị cố định mà bạn hy vọng sẽ phù hợp.
Có ba điểm vào:
→ nói từ "workflow" trong prompt của bạn và Claude viết một cái cho nhiệm vụ đó → thực thi một cái đã lưu hoặc một cái tiêu chuẩn. /deep-research là một đồ thị thực sự đang chạy trong sản xuất: bound → tìm kiếm song song → tìm nạp → xác minh đối nghịch → tổng hợp. Chính xác bộ xương của lộ trình này. → kích hoạt chế độ lập kế hoạch một workflow cho mọi nhiệm vụ quan trọng trong phiên làm việc
Khi một thực thi diễn ra tốt đẹp, hãy lưu script của nó trong .claude/workflows/. Được phiên bản hóa, có thể thực thi lại bằng tên và có thể khởi chạy bởi bất kỳ ai clone repo.
› Khởi chạy một workflow kiểm toán tất cả các tuyến đường trong src/routes/ để tìm
thiếu auth. Một agent cho mỗi file tuyến đường và xác minh từng phát hiện
trước khi báo cáo nó.
● Claude đã viết một script điều phối · đang khởi chạy trong nền…
/workflows — auth-audit · đang chạy
✓ Bound 1/1 2.1k tok · 4s
✓ Fan-out 18/18 một agent cho mỗi file tuyến đường
◯ Verify 11/18 người hoài nghi với 3 phiếu cho mỗi phát hiện…
○ Synthesize 0/1 đang chờ xác minh
phiên làm việc vẫn phản hồi, bạn có thể tiếp tục làm việc trong khi đội chạy
→ Nguyên tắc: nếu công việc thay đổi hình dạng trong mỗi lần thực thi, đừng vẽ đồ thị. Hãy mô tả nó.
SÁU ĐỒ THỊ ĐỂ XÂY DỰNG TRONG TUẦN NÀY
Quét bảo mật trên tất cả các tuyến đường. Một agent con cho mỗi file tuyến đường, mỗi cái săn tìm các kiểm tra auth bị thiếu, tiếp theo là một lượt xác minh xác nhận từng phát hiện trước khi nó đến báo cáo. Bề rộng mà không một ngữ cảnh đơn lẻ nào có thể duy trì.
Báo cáo với các nguồn qua /deep-research. Một đồ thị đã có sẵn trong Claude Code. Nó phân rã câu hỏi của bạn thành các góc độ khác nhau, chạy tìm kiếm song song, loại bỏ trùng lặp các nguồn và xác minh đối nghịch mọi tuyên bố với những người hoài nghi với ba phiếu trước khi viết.
Porting một module, file theo file. Fan out bản dịch trên các file, bộ kiểm thử như một cổng cho mỗi file và các thất bại quay trở lại vòng lặp. Đánh giá đối nghịch bắt được những gì một lượt duy nhất sẽ giao hỏng.
Đánh giá đối nghịch của một diff. Định tuyến dựa trên kích thước: một thay đổi nhỏ có được một lượt nhanh, một thay đổi lớn kích hoạt một cuộc kiểm toán song song đầy đủ với những người đánh giá sử dụng các góc nhìn khác nhau—chính xác, an toàn, nhanh—và sau đó một hội đồng giám khảo tổng hợp.
Quét hệ sinh thái theo lịch trình. Được lưu một lần và thực thi lại mãi mãi. Tham khảo nhiều nguồn song song—bản phát hành, blog, diễn đàn—sắp xếp theo tác động tại một rào cản và viết bản tóm tắt. Được phiên bản hóa trong .claude/workflows/, có thể khởi chạy bằng tên.
Khám phá kích thước không xác định. Bạn không biết có bao nhiêu lỗi. Các trình tìm kiếm song song, loại bỏ trùng lặp mỗi phát hiện mới so với mọi thứ đã thấy, xác minh những cái sống sót và vòng lặp tiếp tục cho đến khi hai vòng không mang lại gì. Sau đó dừng.
DANH SÁCH KIỂM TRA TRƯỚC KHI KHỞI CHẠY ĐỒ THỊ ĐẦU TIÊN CỦA BẠN
→ tôi đã xóa các cạnh không vận chuyển dữ liệu chưa? → công việc có thực sự tách ra không, hay mỗi bước cần bước trước đó? → mỗi nút có đầu vào có giới hạn, đầu ra có hình dạng và một nhiệm vụ duy nhất không? → tôi có đang trả tiền cho một agent để làm điều gì đó là một flatMap không? → có bất kỳ rào cản nào không cần toàn bộ tập hợp không? → có bất kỳ phát hiện nào đến được kết quả mà không có ai cố gắng tiêu diệt nó không? → hai bộ xác minh có hỏi cùng một câu hỏi không? → tất cả các vòng lặp có giới hạn vòng không? → có nhiều hơn một nút ghi vào cùng một file không? → các nút lặp đi lặp lại có đang chạy trên mô hình đắt tiền không?
Nếu bạn thất bại hơn ba, bạn không có một đồ thị. Bạn có một chuỗi với nhiều bước hơn.
KẾT LUẬN
Người prompt đặt câu hỏi. Người kiến trúc vẽ một đồ thị.
Agent tuyến tính chưa bao giờ là trần nhà. Nó chỉ là hình thức đầu tiên, thứ mà mọi người nắm lấy vì nó phù hợp với cách chúng ta viết. Một dòng, một đầu óc, một việc tại một thời điểm.
Khi bạn bắt đầu thấy các nút và cạnh, bạn ngừng yêu cầu agent thực hiện nhiều bước hơn và bắt đầu yêu cầu đồ thị làm cho nó rộng hơn.
Fan out nơi công việc độc lập. Cổng trên các cạnh nơi niềm tin quan trọng. Các mô hình rẻ hơn nơi phán đoán không bị đe dọa.
Hầu hết sẽ tiếp tục xếp hàng các bước trong một đường thẳng một hàng.
Những người học cách vẽ đồ thị sẽ di chuyển một đội. Và họ sẽ không bao giờ nhận thấy trần nhà thấp bên dưới mà những người còn lại đang mắc kẹt.
Hãy vẽ hệ thống hiện tại của bạn tối nay. Chỉ các nhiệm vụ và các mũi tên giữa chúng. Đếm các cạnh giả và xóa chúng.
Đó là bước đầu tiên của toàn bộ quy trình, nó không tốn phí, và nó thường loại bỏ nhiều thời gian chờ đợi hơn bất kỳ công cụ nào bạn có thể mua.
