Hầu hết những người thử xây dựng một tác nhân đa bước (multi-step agent) đề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 lịch sự chờ bước trước hoàn thành rồi mới bắt đầu.
9/10 người nhận ra rằng một nửa số bước đó chưa bao giờ cần phải chờ đợi.
Chúng không định tuyến (route). Chúng không rẽ nhánh (branch). Chúng không xử lý song song (parallelize). Chúng chỉ xếp hàng - một đầu óc, một ngữ cảnh, mỗi lần một việc, cho đến khi cửa sổ ngữ cảnh đầy lên và tác nhân quên mất nó đang làm gì.
Theo dõi Substack của tôi để nhận thông tin AI mới nhất:
Đây là lộ trình 14 bước biến hàng đợi một file đó thành một đồ thị (graph): một đồ thị tỏa ra trên một đội nhóm, tự 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 tác nhân đơn lẻ không bao giờ có thể nắm giữ.
Đây là sự thay đổi mà không ai nói rõ. Một prompt là một câu. Một vòng lặp là một chu trình. Một bộ khung (harness) là sàn mà tác nhân đứ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 (nodes) thực hiện việc suy nghĩ. Các cạnh (edges) mang kết quả.
Claude Code đã cung cấp công cụ để xây dựng trực tiếp các đồ thị này: các luồng công việc động (dynamic workflows).
Claude viết một script điều phối JavaScript thuần, sau đó tạo ra một đội nhóm các tác nhân con phối hợp với nhau để thực thi nó - và việc phối hợp này không tốn bất kỳ token mô hình nào, bởi vì nó là mã, không phải là một cuộc hội thoại.
01. Các nút là công việc. Các cạnh là thứ chảy giữa chúng.
Một đồ thị có chính xác hai thứ, và hiểu rõ chúng sẽ giải quyết hầu hết sự nhầm lẫn. Một nút (node) là một đơn vị công việc - một tác nhân, một công việc có giới hạn, một đầu vào và một đầu ra.
Một cạnh (edge) là 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 thế.
Sai lầm là coi "và sau đó" như một cạnh. "Tóm tắt file và sau đó cho tôi biết thời tiết" không có cạnh nào giữa hai việc - thời tiết không tiêu thụ bản tóm tắt.
Đó là hai nút không kết nối mà một script tuyến tính đã gắn xích một cách không cần thiết. Cạnh chỉ tồn tại khi dữ liệu thực sự di chuyển qua nó.
Hãy học cách đặt câu hỏi, cho mọi "và sau đó" trong tác nhân của bạn: bước tiếp theo có đọc đầu ra của bước trước không? Nếu không, không có cạnh nào cả, và sự chờ đợi là lãng phí.
1Vẽ nó dưới dạng các hộp và mũi tên. Một hộp là một lời gọi agent().2Một mũi tên là một biến được truyền từ kết quả trả về của lời gọi này3sang prompt của lời gọi khác. Nếu bạn không thể vẽ mũi tên - nếu không4có biến nào đi qua - hai hộp đó là độc lập, và tính độc lập là thứ bạn5sẽ khai thác trong phần còn lại của khóa học này.
02. Script tuyến tính của bạn là một đồ thị suy biến (degenerate)
Khi bạn viết một tác nhân dạng "làm A, rồi B, rồi C, rồi D," bạn đã vẽ một đồ thị - một chuỗi đơn không phân nhánh. Mọi nút có chính xác một cạnh vào và một cạnh ra.
Nó chạy đúng. Nhưng nó cũng chạy chậm và dễ hỏng, bởi vì một chuỗi không có sự dự phòng: nếu C bị treo, D không bao giờ xảy ra, và công việc của A bị mắc kẹt ở phía trê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. Hãy lấy tác nhân tuyến tính của bạn và, với mỗi mũi tên, hãy đặt câu hỏi ở Bước 1.
Hầu hết các chuỗi có hai hoặc ba mũi tên không mang dữ liệu - chúng chỉ là thứ tự bạn tình cờ gõ mọi thứ.
Cắt bỏ 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, cung cấp dữ liệu cho một nút duy nhất cần tất cả chúng.
03. Cung cấp cho mọi nút một hợp đồng (contract)
Một nút mà bạn không thể suy luận về 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, chính xác một công việc.
Đầu vào là bất cứ thứ gì nút đọc - được truyền vào 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 có thể tiêu thụ nó mà không cần phải phỏng đoán.
Trong một luồng công việc, hợp đồng này được thực thi bằng một lược đồ (schema). Khi bạn đưa cho Claude một lời gọi agent() với một lược đồ JSON, tác nhân con Claude tạo ra buộc phải trả về dữ liệu có cấu trúc đã được xác thực - việc xác thực diễn ra ở lớp gọi công cụ, vì vậy Claude sẽ thử lại nếu có sự không khớp thay vì đưa cho bạn văn bản tự do mà bạn phải phân tích và cầu nguyện.
Đây là sự khác biệt giữa một nút Claude có thể nối dây vào một đồ thị và một nút chỉ hoạt động khi một con người đọc đầu ra của nó.
1// Một nút với một 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.2const ITEM = {3 type: 'object', additionalProperties: false,4 properties: {5 title: { type: 'string' },6 url: { type: 'string' },7 impact: { type: 'string', enum: ['high', 'medium', 'low'] },8 },9 required: ['title', 'url', 'impact'],10};1112const result = await agent(source.prompt, {13 label: `research:${source.key}`,14 schema: ITEM, // buộc phải có đầu ra có cấu trúc đã được xác thực15 agentType: 'general-purpose',16});17// result bây giờ là một hình dạng mà nút tiếp theo có thể tin tưởng — không phải văn bản tự do.
04. Coi cạnh như một hợp đồng dữ liệu
Một cạnh không chỉ là "B đến 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, và B được xây dựng để tiêu thụ hình dạng này. Khi bạn đặt tên cho cạnh bằng dữ liệu của nó - chứ không phải thứ tự của nó - hai việc trở nên dễ dàng hơn.
Bạn có thể thấy ngay lập tức liệu cạnh có thật không (dữ liệu có thực sự di chuyển không?), và bạn có thể thay thế nút ở một trong hai đầu mà không làm hỏng đồ thị, miễn là hình dạng được giữ nguyên.
Trong thực tế, cạnh tồn tại trong JavaScript thuần. Bước reduce giữa fan-out và tổng hợp - làm phẳng, loại bỏ trùng lặp, lọc - chỉ là mã 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 tác nhân nào cả. Một trong những chiến thắng thầm lặng của tư duy đồ thị: một lượng lớn những gì mọi người đốt token mô hình vào thực sự là một cạnh, và các cạnh là miễn phí.
1Sự cám dỗ là tạo ra một tác nhân để "kết hợp các kết quả." Hãy chống2lạ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à3results.flatMap(...) và một Set — tất định, tức thì, không tốn token.4Hãy dành các tác nhân cho việc phán đoán, không phải cho việc kết nối5đường ống. Một đồ thị nơi mọi cạnh là một tác nhân là một đồ thị đang6trả tiền thuê cho chính hệ thống dây điện của nó.
05. Tỏa ra (Fan out) với parallel()
Đây là động thái trả giá cho mọi thứ. Khi bạn có N nút độc lập - N nguồn để kiểm tra, N file để xem xét, N tuyến đường để kiểm toán - bạn không xâu chuỗi chúng lại.
Bạn bảo Claude tỏa chúng ra và chạy chúng cùng một lúc. Trong một luồng công việc, đó là parallel(): Claude lấy một mảng các thunk và tạo ra một tác nhân con cho mỗi thunk, tất cả đều thực thi đồng thời, sau đó trả lại cho bạn mảng kết quả.
Hai chi tiết làm cho nó mạnh mẽ. Đầu tiên, parallel() là một rào chắn (barrier) - nó đợi mọi thunk trước khi trả về, vì vậy giai đoạn tiếp theo thấy được tập hợp đầy đủ. Thứ hai, một thunk ném ra lỗi sẽ phân giải thành null thay vì từ chối toàn bộ lô, vì vậy một tác nhân trục trặc không thể đánh chìm cả lần chạy.
Luôn .filter(Boolean) các kết quả. Mức độ đồng thời được giới hạn xung quanh 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ỉ một vài thứ cùng một lúc.
1phase('Research');23// Chín nguồn, chín tác nhân, tất cả cùng một lúc.4const raw = await parallel(5 SOURCES.map((s) => () =>6 agent(s.prompt, {7 label: `research:${s.key}`,8 phase: 'Research',9 schema: ITEM_SCHEMA, // mỗi nút trả về JSON đã được xác thực10 agentType: 'general-purpose',11 }),12 ),13);1415const collected = raw.filter(Boolean); // bỏ qua các null từ các tác nhân thất bại
Việc tỏa ra nằm trong mã Claude đã viết, không phải trong một cuộc hội thoại mô hình. Ngữ cảnh của chính Claude không bao giờ chứa chín nguồn cùng một lúc - mỗi tác nhân con mang ngữ cảnh riêng của nó, và chỉ câu trả lời cuối cùng mới quay lại.
Đó là điều cho phép Claude mở rộng một luồng công việc lên hàng chục hoặc hàng trăm tác nhân con mà không làm ngập phiên làm việc. Lớp điều phối không tốn token nào vì nó không phải là một lượt suy nghĩ khác của Claude.
06. Hội tụ (Fan in) tại một rào chắn (barrier)
Một sự tỏa ra chỉ hữu ích nếu có thứ gì đó tập hợp nó lại. Sự hội tụ là nút nơi các cạnh hội tụ - nơi một tác nhân (hoặc một đoạn mã) nhìn thấy tất cả kết quả từ thượng nguồn cùng một lúc và làm điều gì đó cần đến toàn bộ tập hợp: loại bỏ trùng lặp trên các nguồn, xếp hạng theo tác động, thoát sớm nếu tổng số trả về trống rỗng. Đây là nơi duy nhất một rào chắn xứng đáng với chi phí thời gian treo tường của nó.
Nguyên tắc giữ cho đồ thị nhanh: chỉ sử dụng một rào chắn khi một giai đoạn thực sự cần mọi kết quả trước đó cùng nhau. Loại bỏ trùng lặp trên tất cả các nguồn? Rào chắn - chính xác.
1// Cạnh: JS thuần, không có tác nhân, không tốn token.2const flat = collected.flatMap((c) => c.items);3log(`Collected ${flat.length} items`);45phase('Curate');6// Nút rào chắn: cần TOÀN BỘ tập hợp để loại bỏ trùng lặp + xếp hạng.7const curated = await agent(8 `Loại bỏ trùng lặp và xếp hạng các mục này theo tác động:\n${JSON.stringify(flat)}`,9 { phase: 'Curate', schema: CURATED_SCHEMA },10);
Chỉ làm phẳng một danh sách? Đó là một cạnh, hãy làm nó nội tuyến. Bài kiểm tra mùi rất tàn bạo và đơn giản: nếu bạn viết parallel → transform → parallel, và transform ở giữa đó không có sự phụ thuộc chéo giữa các mục, thì bạn nên sử dụng một pipeline và bỏ qua hoàn toàn rào chắn.
07. Hình thoi (diamond): phân chia → làm việc → hợp nhất
Kết hợp tỏa ra và hội tụ lại, bạn có được cấu trúc liên kết chủ lực của mọi đồ thị tác nhân nghiêm túc: hình thoi (diamond).
Một nút chia nhỏ công việc, nhiều nút thực hiện công việc song song, một nút hợp nhất. Đó là hình dạng đằng sau một bản quét thị trường, một cuộc kiểm toán phụ thuộc, một đánh giá mã, một báo cáo nghiên cứu - hãy thay đổi các nguồn và prompt, cùng một khung xương sẽ thích ứng.
Dạng chuẩn có một cái tên đáng nhớ: tỏa ra → reduce → tổng hợp. Tỏa ra để thu thập bề rộng, reduce bằng mã thuần để nén nó, tổng hợp với một tác nhân cuối cùng để viết câu trả lời.
Một khi bạn thấy hình thoi, bạn sẽ ngừng hỏi "làm thế nào để tác nhân của tôi làm nhiều bước hơn" và bắt đầu hỏi "sự phân chia ở đâu, sự hợp nhất ở đâu" - đó là câu hỏi thực sự mở rộng quy mô.
08. Định tuyến cạnh tại thời điểm chạy với một điều kiện (conditional)
Không phải mọi đồ thị đều cố định. Đôi khi cạnh cần đi phụ thuộc vào những gì một nút tìm thấy. Một nút định tuyến (router node) kiểm tra một kết quả và quyết định đường dẫn hạ nguồn nào sẽ kích hoạt - phân loại ticket, sau đó rẽ nhánh đến trình xử lý phù hợp; kiểm tra kích thước khác biệt (diff), sau đó thực hiện đánh giá nhanh hoặc khởi động một cuộc kiểm toán đầy đủ.
Trong một luồng công việc, đây chỉ là một câu lệnh if hoặc switch JavaScript trên đầu ra đã được xác thực của một nút, bởi vì luồng điều khiển nằm trong mã.
Đây là nơi tính tất định trở thành một tính năng, không phải là một giới hạn. Quyết định của bộ định tuyến có thể được hỗ trợ bởi Claude (một tác nhân con phân loại), nhưng việc định tuyến là mã Claude đã viết - vì vậy nó chạy theo cùng một cách mọi lần cho cùng một phân loại.
Bạn có được khả năng phán đoán của Claude tại nút và độ tin cậy của script tại cạnh. Không có bất ngờ "Claude quyết định bỏ qua cuộc kiểm toán" nổi lên - bởi vì việc bỏ qua sẽ phải được viết vào đồ thị, và nó thì không.
1// Nút định tuyến: một tác nhân phân loại, mã chọn cạnh.2const { severity } = await agent(3 `Phân loại rủi ro của diff này:\n${diff}`,4 { schema: { type: 'object',5 properties: { severity: { enum: ['low', 'high'] } },6 required: ['severity'] } },7);89let review;10if (severity === 'high') {11 // đường dẫn nặng: kiểm toán song song đầy đủ12 review = await parallel(FILES.map((f) => () => agent(`Kiểm toán ${f}`)));13} else {14 // đường dẫn nhẹ: một lượt nhanh15 review = await agent(`Đánh giá nhanh về ${diff}`);16}
09. Đặt một bộ xác minh (verifier) trên cạnh
Đòn bẩy thực sự của một đồ thị không phải là nhiều tác nhân hơn - mà là cấu trúc bạn có thể bọc xung quanh chúng để tạo ra sự tự 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 hạ nguồn, và 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ó sẽ được chuyển tiếp. Nếu không, nó không bao giờ đến được câu trả lời.
Ba mẫu hình đáng để bạn có trong tay.
- Xác minh đối kháng (Adversarial verify): cho mỗi phát hiện, tạo ra N kẻ hoài nghi độc lập được nhắc nhở để bác bỏ nó; chỉ giữ lại nếu đa số sống sót.
- Xác minh đa góc nhìn (Perspective-diverse verify): cung cấp cho mỗi bộ xác minh một lăng kính riêng biệt - tính đúng đắn, bảo mật, có thể tái tạo không - bởi vì sự đa dạng bắt được các chế độ thất bại mà N kiểm tra giống hệt nhau sẽ không bao giờ làm được.
- Hội đồng giám khảo (Judge panel): tạo ra N nỗ lực từ các góc độ khác nhau, chấm điểm chúng bằng các thẩm phán song song, tổng hợp từ người thắng cuộc trong khi ghép những phần tốt nhất của các á quân.
Đây chính xác là mẫu hình đã cho phép một nhóm thực sự chuyển đổi thời gian chạy Bun (Bun runtime) với việc đánh giá mã đối kháng được tích hợp vào vòng lặp.
10. Cô lập các nút để một lỗi không thể đầu độc đồ thị
Trong một chuỗi, một lỗi sẽ lan truyền - C chết, D không bao giờ chạy, toàn bộ dừng lại. Trong một đồ thị, lỗi nên được giới hạn trong nút của nó.
Điều đó đã phần nào đúng: một thunk ném ra lỗi bên trong parallel() sẽ phân giải thành null, vì vậy tám tác nhân tốt vẫn trả về trong khi một tác nhân xấu bỏ cuộc. .filter(Boolean) của bạn là sự ngăn chặn.
Hãy thiết kế mọi kênh hội tụ để chịu đựng các đầu vào bị thiếu thay vì giả định một tập hợp đầy đủ.
Lỗi tinh vi hơn là các nút giẫm chân lên nhau. Khi các tác nhân ghi file song song, chúng có thể xung đột.
Giải pháp là sự cô lập: "worktree" - mỗi tác nhân chạy trong worktree git riêng của nó, thực hiện công việc trong một hộp cát, và hợp nhất sạch sẽ.
Chỉ sử dụng nó khi các nút thực sự ghi file 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 chạy.
11. Thêm một chu trình (cycle) - nhưng hãy làm cho nó hội tụ (converge)
Đôi khi bạn không biết công việc lớn đến mức nào cho đến khi bạn đang ở trong nó: 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 lỗi lại tiết lộ thêm ba lỗi nữa. Điều đó cần 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 rất rõ ràng: một chu trình không hội tụ là một vòng lặp vô hạn tạo ra các tác nhân cho đến khi ngân sách của bạn cạn kiệt.
Mẫu hình hội tụ là lặp cho đến khi cạn (loop-until-dry): tiếp tục tạo ra các công cụ tìm kiếm cho đến khi K vòng liên tiếp không phát hiện ra điều gì mới, sau đó dừng lại. Một chi tiết làm nên hoặc phá vỡ nó - và sai lầm 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ỉ dựa trên các kết quả đã được xác nhận. Nếu không, các phát hiện bị từ chối sẽ xuất hiện trở 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 để tái khám phá cùng một ngõ cụt mãi mãi.
1const seen = new Set(); const confirmed = []; let dry = 0;23while (dry < 2) { // dừng sau 2 vòng trống4 const found = (await parallel(5 FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))6 )).filter(Boolean).flatMap((r) => r.bugs);78 const fresh = found.filter((b) => !seen.has(key(b)));9 if (!fresh.length) { dry++; continue; } // không có gì mới → tiến tới cạn10 dry = 0;11 fresh.forEach((b) => seen.add(key(b))); // loại bỏ trùng lặp dựa trên SEEN, không phải confirmed1213 // xác minh đa góc nhìn mỗi phát hiện mới trước khi nó được tính14 const judged = await parallel(fresh.map((b) => () =>15 parallel(['correctness', 'security', 'repro'].map((lens) => () =>16 agent(`Phán xét "${b.desc}" qua ${lens} — có thật không?`, { schema: VERDICT })))17 .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));1819 confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));20}
12. Phân tầng các mô hình trên các nút
Không phải nút nào cũng cần mô hình tốt nhất của bạn. Một đồ thị làm cho điều này trở nên rõ ràng theo cách mà một tác nhân đơn lẻ không bao giờ làm được: một số 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à một số nút mang phán đoán thực sự (tổng hợp báo cáo, phân xử phát hiện).
Hãy chạy các nút nhàm chán trên một mô hình rẻ hơn và dành token đắt tiền của bạn cho nơi phán đoán thực sự tồn tại.
Trong một luồng công việc, mọi tác nhân con Claude tạo ra sẽ kế thừa mô hình phiên làm việc của bạn trừ khi script ghi đè lên nó - vì vậy theo mặc định, một lần chạy lớn sẽ tính phí hoàn toàn ở mức phiên làm việc của bạn. Tùy chọn model trên một lời gọi agent() duy nhất bảo Claude định tuyến nút đó đến nơi khác.
Kiểm tra /model trước một lần chạy lớn, sau đó bảo Claude định tuyến các nút lặp đi lặp lại của sự tỏa ra xuống một mô hình rẻ hơn và giữ nút hợp nhất ở mức cao. Đây là đòn bẩy biến một đồ thị ngốn token từ đắt đỏ trở nên kinh tế mà không chạm vào hình dạng của nó.
13. Cấu trúc liên kết (topology) là chi phí và độ trễ của bạn
Hình dạng của đồ thị không chỉ là hình thức - nó là đòn bẩy lớn nhất đối với thời gian treo tường. Sự lựa chọn làm mọi người vấp ngã: parallel() so với pipeline(). Một rào chắn parallel() làm 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() truyền từng mục qua tất cả các giai đoạn một cách độc lập, không có rào chắn - mục A có thể ở giai đoạn 3 trong khi mục B vẫn ở giai đoạn 1. Các mục nhanh hoàn thành sớm thay vì chờ đợi sau các mục chậm.
Mặc định sử dụng pipeline(). Chỉ sử dụng rào chắn khi một giai đoạn thực sự cần mọi kết quả trước đó cùng một lúc - một sự loại bỏ trùng lặp chéo tập hợp, một sự thoát sớm trên tổng số, một prompt so sánh với "các phát hiện khác." "Mã sạch hơn" và "các giai đoạn có vẻ riêng biệt" không phải là lý do; độ trễ của rào chắn là thời gian lãng phí thực sự, có thể đo lường được. Riêng biệt không đồng nghĩa với đồng bộ.
14. Để Claude vẽ đồ thị - tự định tuyến (self-routing)
Động thái 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 luồng công việc động (dynamic workflows), 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 sự tỏa ra, tạo ra một đội nhóm các tác nhân con phối hợp, và tổng hợp kết quả. Bạn có được một đồ thị phù hợp với lần chạy này thay vì một đồ thị cố định mà bạn hy vọng sẽ phù hợp.
Có ba cách để bắt đầu. Nói từ "workflow" trong prompt của bạn và Claude sẽ viết một cái cho nhiệm vụ đó. Chạy một cái đã lưu hoặc đóng gói sẵn - /deep-research là một đồ thị thực sự đang hoạt động trong sản xuất: phạm vi → tìm kiếm song song → tìm nạp → xác minh đối kháng → tổng hợp, chính xác khung xương từ khóa học này.
Hoặc bật ultracode và Claude sẽ lên kế hoạch cho một luồng công việc cho mọi nhiệm vụ quan trọng trong phiên làm việc. Khi một lần chạy tốt, nhấn s để lưu script của nó vào .claude/workflows/ - được kiểm soát phiên bản, có thể chạy lại bằng tên, một đồ thị mà bất kỳ ai clone kho lưu trữ đều có thể khởi chạy.
1› Chạy một luồng công việc để kiểm toán mọi tuyến đường dưới src/routes/ xem có thiếu2xác thực không. Tạo một tác nhân cho mỗi file route, sau đó xác minh từng phát hiện trước khi3báo cáo. ● Claude đã viết một script điều phối · đang khởi chạy ở nền…4/workflows — auth-audit · đang chạy ✓ Phạm vi 1/1 2.1k tok · 4s ✓ Tỏa ra 18/18 một tác nhân5cho mỗi file route ◯ Xác minh 11/18 3 lá phiếu hoài nghi cho mỗi phát hiện… ○ Tổng hợp 0/16đang chờ xác minh phiên làm việc vẫn phản hồi — tiếp tục làm việc trong khi đội nhóm chạy
Sáu đồ thị để xây dựng với Claude trong tuần này
- Quét bảo mật trên mọi tuyến đường. Claude tạo ra một tác nhân con cho mỗi file route, mỗi cái săn tìm các kiểm tra xác thực bị thiếu, sau đó một lượt xác minh xác nhận mọi 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ể nắm giữ.
- Báo cáo có trích dẫn với /deep-research. Một đồ thị đã có sẵn trong Claude Code. Claude phân rã câu hỏi của bạn thành các góc nhìn riêng biệt, chạy các tìm kiếm song song, loại bỏ trùng lặp nguồn, sau đó xác minh đối kháng mọi tuyên bố với ba lá phiếu hoài nghi trước khi viết.
- Chuyển đổi một module, từng file một. Trần Bun, được mở rộng quy mô cho kho lưu trữ của bạn. Claude tỏa ra việc dịch thuật trên các file, chạy bộ kiểm thử như một cổng kiểm tra trên mỗi file, và lặp lại các lỗi quay lại - đánh giá đối kháng bắt được những gì một lượt duy nhất sẽ chuyển đi hỏng hóc.
- Đánh giá đối kháng của một diff (khác biệt mã). Claude định tuyến dựa trên kích thước diff: một thay đổi nhỏ có một lượt đánh giá nhanh, một thay đổi lớn kích hoạt một kiểm toán song song đầy đủ với những người đánh giá trên các lăng kính riêng biệt - tính đúng đắn, bảo mật, hiệu suất - 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. Lưu nó một lần, chạy lại nó mãi mãi. Claude kiểm tra nhiều nguồn song song - bản phát hành, blog, thảo luận - xếp hạng theo tác động tại một rào chắn, và viết bản tóm tắt. Được kiểm soát phiên bản 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 ở đó. Claude chạy các công cụ tìm kiếm song song, loại bỏ trùng lặp mỗi phát hiện mới dựa trên mọi thứ đã thấy, xác minh những cái sống sót, và tiếp tục lặp cho đến khi hai vòng không tìm thấy gì mới - sau đó dừng lại.
Kết luận:
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ị.
Tác nhân tuyến tính chưa bao giờ là trần nhà - nó chỉ 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ột đầu óc, mỗi lần một việc.
Một khi bạn có thể thấy các nút và các cạnh, bạn ngừng yêu cầu tác nhân làm nhiều hơn và bắt đầu yêu cầu đồ thị làm nó rộng hơn: tỏa ra nơi công việc độc lập, kiểm soát các cạnh nơi sự tự tin quan trọng, phân tầng các mô hình nơi phán đoán không cần thiết.
Hầu hết mọi người sẽ tiếp tục xếp hàng các bước trong một dòng. Những người học cách vẽ đồ thị sẽ vận hành một đội nhóm - và không bao giờ nhận thấy trần nhà mà phần còn lại đang bị kẹt bên dưới.
