วิศวกรรมกราฟด้วย Claude: แผนการดำเนินงาน 14 ขั้นตอนจาก 0 สู่การเป็นสถาปนิกกราฟ

คนส่วนใหญ่ที่พยายามสร้างเอเจนต์แบบหลายขั้นตอน มักจะลงเอยด้วยเส้นตรง ขั้นตอนที่หนึ่ง สอง สาม - แต่ละขั้นรอให้ขั้นก่อนหน้าสำเร็จอย่างสุภาพก่อนจึงจะเริ่ม

9 ใน 10 คน รู้ว่าครึ่งหนึ่งของขั้นตอนเหล่านั้นไม่เคยต้องรอเลย

พวกมันไม่ได้ กำหนดเส้นทาง พวกมันไม่ได้ แตกกิ่งก้านสาขา พวกมันไม่ได้ ทำงานขนานกัน พวกมันแค่เข้าแถว - หัวเดียว บริบทเดียว ทีละอย่าง จนกระทั่งหน้าต่างเต็ม และเอเจนต์ลืมสิ่งที่กำลังทำ

ติดตาม Substack ของฉันเพื่อรับ AI alpha ใหม่ล่าสุด:

movez.substack.com

นี่คือแผนงาน 14 ขั้นตอน ที่จะเปลี่ยนแถวเดี่ยว ๆ นั้นให้กลายเป็น กราฟ: กราฟที่แผ่กระจายไปทั่วกองทัพ ตรวจสอบสิ่งที่ค้นพบของตัวเอง และรวมตัวกันเป็นผลลัพธ์ที่เอเจนต์เดี่ยวไม่สามารถรักษาไว้ได้

นี่คือการเปลี่ยนแปลงที่ไม่มีใครอธิบายอย่างชัดเจน พรอมต์คือประโยคหนึ่ง ลูปคือวงจรหนึ่ง สายรัดคือพื้นดินที่เอเจนต์ยืนอยู่

แต่ รูปร่างของงานเอง - อะไรทำงานก่อนอะไร อะไรสามารถทำงานพร้อมกันได้ อะไรต้องรอทุกอย่างอื่น - รูปร่างนั้นคือกราฟ โหนดทำหน้าที่คิด ขอบทำหน้าที่นำพาผลลัพธ์

Claude Code จัดส่งเครื่องมือในการสร้างกราฟเหล่านี้โดยตรง: เวิร์กโฟลว์แบบไดนามิก

Claude เขียนสคริปต์จัดลำดับ JavaScript ธรรมดา จากนั้นก็สร้างกองทัพของเอเจนต์ย่อยที่ประสานงานกันเพื่อดำเนินการ - และการประสานงานนั้นใช้โทเค็นโมเดลเป็นศูนย์ เพราะมันคือโค้ด ไม่ใช่บทสนทนา

01. โหนดคือ งาน ขอบคือ สิ่งที่ ไหลผ่าน

กราฟมีเพียงสองสิ่ง และการทำให้เข้าใจตรงกันจะช่วยขจัดความสับสนส่วนใหญ่ได้ โหนด คือหน่วยของงาน - เอเจนต์หนึ่งตัว งานที่มีขอบเขตหนึ่งงาน ข้อมูลนำเข้าหนึ่งชุดและผลลัพธ์หนึ่งชุด

ขอบ คือการพึ่งพา: มันบอกว่า ผลลัพธ์ของโหนดนี้ ป้อนเข้าสู่โหนดนั้น ไม่มีอะไรเพิ่มเติม

ข้อผิดพลาดคือการปฏิบัติต่อ "แล้วก็" เหมือนเป็นขอบ "สรุปไฟล์ แล้วก็ บอกสภาพอากาศ" ไม่มีขอบระหว่างทั้งสอง - สภาพอากาศไม่ได้ใช้ประโยชน์จากสรุป

นั่นคือโหนดสองโหนดที่ไม่ได้เชื่อมต่อกัน ซึ่งสคริปต์เชิงเส้นผูกไว้อย่างไม่จำเป็น ขอบมีอยู่จริงก็ต่อเมื่อข้อมูลเคลื่อนที่ผ่านมันจริง ๆ

จงเรียนรู้ที่จะถาม สำหรับทุก "แล้วก็" ในเอเจนต์ของคุณ: ขั้นตอนถัดไปอ่านผลลัพธ์ของขั้นตอนก่อนหน้าหรือไม่? ถ้าไม่ ก็ไม่มีขอบ และการรอก็ไร้ประโยชน์

1วาดมันเป็นกล่องและลูกศร กล่องคือการเรียก agent()
2ลูกศรคือตัวแปรที่ส่งผ่านจาก return ของการเรียกหนึ่งไปยัง
3พรอมต์ของอีกการเรียกหนึ่ง ถ้าคุณวาดลูกศรไม่ได้ - ถ้าไม่มีตัวแปรข้ามผ่าน -
4ทั้งสองกล่องนั้นเป็นอิสระต่อกัน และอิสระคือสิ่งที่คุณจะใช้ประโยชน์
5สำหรับส่วนที่เหลือของหลักสูตรนี้

02. สคริปต์เชิงเส้นของคุณคือ กราฟ แบบ เสื่อม

เมื่อคุณเขียนเอเจนต์เป็น "ทำ A, แล้ว B, แล้ว C, แล้ว D" คุณได้วาดกราฟขึ้นมาแล้ว - เป็นห่วงโซ่เส้นเดียวที่ไม่มีการแตกกิ่ง ทุกโหนดมีขอบเข้าและขอบออกอย่างละหนึ่งอัน

มันทำงานได้ถูกต้อง แต่มันก็ทำงานช้าและเปราะบาง เพราะห่วงโซ่ไม่มีความซ้ำซ้อน: ถ้า C หยุดชะงัก D จะไม่เกิดขึ้น และงานของ A ก็ติดอยู่ต้นน้ำไม่มีที่ไป

ทักษะแรกที่แท้จริงของวิศวกรรมกราฟคือ การวาดห่วงโซ่ใหม่ นำเอเจนต์เชิงเส้นของคุณ และสำหรับแต่ละลูกศร ให้ถามคำถามในขั้นตอนที่ 1

ห่วงโซ่ส่วนใหญ่มีลูกศรสองหรือสามอันที่ไม่นำพาข้อมูล - พวกมันเป็นแค่ลำดับที่คุณบังเอิญพิมพ์สิ่งต่าง ๆ ลงไป

ตัดลูกศรเหล่านั้นทิ้ง แล้วห่วงโซ่จะพังทลายลงเป็นสิ่งที่กว้างขึ้น: โหนดอิสระสองสามโหนดที่สามารถทำงานพร้อมกันทั้งหมด ป้อนเข้าสู่โหนดเดียวที่ต้องการพวกมันทั้งหมด

03. ให้ ทุกโหนดมี สัญญา

โหนดที่คุณไม่สามารถใช้เหตุผลเกี่ยวกับมันได้ คือโหนดที่คุณไม่สามารถทำขนานได้ วิธีแก้คือสัญญา: ข้อมูลนำเข้าที่มีขอบเขต, ผลลัพธ์ที่มีขอบเขต, งานเพียงหนึ่งงานอย่างชัดเจน

ข้อมูลนำเข้าคืออะไรก็ตามที่โหนดอ่าน - ส่งผ่านเข้ามาอย่างชัดเจน ไม่เคยสันนิษฐานจากหน้าต่างที่ใช้ร่วมกัน ผลลัพธ์คือรูปแบบที่กำหนดไว้ โดยควรได้รับการตรวจสอบความถูกต้อง เพื่อให้โหนดถัดไปสามารถบริโภคได้โดยไม่ต้องเดา

ในเวิร์กโฟลว์ สัญญานี้ถูกบังคับใช้ด้วย schema เมื่อคุณส่งการเรียก agent() พร้อม JSON schema ให้กับ Claude เอเจนต์ย่อยที่ Claude สร้างขึ้นจะถูกบังคับให้ส่งคืนข้อมูลที่มีโครงสร้างที่ตรวจสอบแล้ว - การตรวจสอบเกิดขึ้นที่เลเยอร์การเรียกใช้เครื่องมือ ดังนั้น Claude จะลองใหม่เมื่อไม่ตรงกัน แทนที่จะส่งข้อความอิสระที่คุณต้องแยกวิเคราะห์และหวังผล

นี่คือความแตกต่างระหว่างโหนดที่ Claude สามารถต่อเข้ากับกราฟได้ กับโหนดที่ทำงานได้ก็ต่อเมื่อมนุษย์อ่านผลลัพธ์ของมันเท่านั้น

1// โหนดที่มีสัญญาจริง: input มีขอบเขต, output ผ่านการตรวจสอบ, หนึ่งงาน
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};
11
12const result = await agent(source.prompt, {
13  label:  `research:${source.key}`,
14  schema: ITEM,           // บังคับให้ output ที่มีโครงสร้างผ่านการตรวจสอบ
15  agentType: 'general-purpose',
16});
17// ตอนนี้ result เป็นรูปแบบที่โหนดถัดไปสามารถเชื่อถือได้ — ไม่ใช่ข้อความอิสระ

04. ปฏิบัติต่อ ขอบเป็นสัญญาข้อมูล

ขอบไม่ใช่แค่ "B ตามหลัง A" มันคือคำมั่นสัญญาเกี่ยวกับสิ่งที่ข้ามผ่าน: A สร้าง รูปแบบนี้ และ B ถูกสร้างขึ้นเพื่อบริโภค รูปแบบนี้ เมื่อคุณตั้งชื่อขอบตามข้อมูลของมัน - ไม่ใช่ลำดับของมัน - สองสิ่งจะง่ายขึ้น

คุณสามารถเห็นได้ทันทีว่าขอบนั้นเป็นจริงหรือไม่ (ข้อมูลเคลื่อนที่จริงหรือ?) และคุณสามารถสลับโหนดที่ปลายด้านใดด้านหนึ่งได้โดยไม่ทำให้กราฟเสียหาย ตราบใดที่รูปแบบยังคงอยู่

ในทางปฏิบัติ ขอบอาศัยอยู่ใน JavaScript ธรรมดา ขั้นตอน reduce ระหว่างการกระจายออกและการสังเคราะห์ - ทำให้แบน, ลบรายการซ้ำ, กรอง - เป็นแค่โค้ดที่ดำเนินการกับรูปแบบที่โหนดของคุณส่งคืนมา

ไม่จำเป็นต้องใช้เอเจนต์ หนึ่งในชัยชนะที่เงียบงันของความคิดแบบกราฟ: งานจำนวนมหาศาลที่คนใช้โทเค็นโมเดลไปกับมัน จริง ๆ แล้วคือขอบ และขอบนั้นฟรี

1สิ่งล่อใจคือการสร้างเอเจนต์เพื่อ "รวมผลลัพธ์" จงต่อต้าน
2มัน ถ้าการรวมหมายถึงการทำให้แบนและลบรายการซ้ำ นั่นคือ results.flatMap(...)
3และ Set — deterministic, ทันที, ใช้โทเค็นเป็นศูนย์ เก็บเอเจนต์ไว้สำหรับ
4การตัดสินใจ ไม่ใช่สำหรับการเดินท่อ กราฟที่ทุกขอบคือเอเจนต์ คือกราฟ
5ที่จ่ายค่าเช่าให้กับสายไฟของตัวเอง

05. กระจายออกด้วย parallel()

นี่คือการเคลื่อนไหวที่จ่ายผลตอบแทนให้กับทุกสิ่ง เมื่อคุณมีโหนดอิสระ N โหนด - แหล่งที่มาที่ต้องตรวจสอบ N แหล่ง, ไฟล์ที่ต้องตรวจสอบ N ไฟล์, เส้นทางที่ต้องตรวจสอบ N เส้นทาง - คุณไม่ต้องต่อเป็นลูกโซ่

คุณบอกให้ Claude กระจายพวกมันออกและรันพวกมันพร้อมกัน ในเวิร์กโฟลว์ นั่นคือ parallel(): Claude รับอาร์เรย์ของ thunks และสร้างเอเจนต์ย่อยหนึ่งตัวต่อ thunk ทั้งหมดทำงานพร้อมกัน จากนั้นส่งคืนอาร์เรย์ของผลลัพธ์ให้คุณ

รายละเอียดสองประการทำให้มันแข็งแกร่ง ประการแรก parallel() คือ สิ่งกีดขวาง - มันรอทุก thunk ก่อนที่จะส่งคืน ดังนั้นขั้นตอนถัดไปจะเห็นชุดที่สมบูรณ์ ประการที่สอง thunk ที่ throw จะ resolve เป็น null แทนที่จะปฏิเสธทั้งชุด ดังนั้นเอเจนต์ที่เสียหนึ่งตัวไม่สามารถทำให้การรันทั้งหมดจมลงได้

ใช้ .filter(Boolean) กับผลลัพธ์เสมอ จำนวนพร้อมกันถูกจำกัดรอบจำนวนคอร์ของคุณและคิวที่เกินมา ดังนั้นคุณสามารถส่ง thunk หนึ่งร้อยตัวและพวกมันทั้งหมดจะเสร็จ - แค่ทีละหยิบมือ

1phase('Research');
2
3// เก้าแหล่ง, เก้าเอเจนต์, ทั้งหมดพร้อมกัน
4const raw = await parallel(
5  SOURCES.map((s) => () =>
6    agent(s.prompt, {
7      label: `research:${s.key}`,
8      phase: 'Research',
9      schema: ITEM_SCHEMA,     // แต่ละโหนดส่งคืน JSON ที่ตรวจสอบแล้ว
10      agentType: 'general-purpose',
11    }),
12  ),
13);
14
15const collected = raw.filter(Boolean);  // ละทิ้ง null จากเอเจนต์ที่ล้มเหลว

การกระจายออกอาศัยอยู่ในโค้ดที่ Claude เขียน ไม่ใช่ในการสนทนาของโมเดล บริบทของ Claude เองไม่เคยเก็บแหล่งที่มาเก้าแห่งพร้อมกัน - เอเจนต์ย่อยแต่ละตัวมีของตัวเอง และมีเพียงคำตอบสุดท้ายเท่านั้นที่กลับมา

นั่นคือสิ่งที่ทำให้ Claude สามารถปรับขนาดเวิร์กโฟลว์ไปยัง เอเจนต์ย่อยหลายสิบหรือหลายร้อยตัว โดยไม่ทำให้เซสชั่นจมน้ำ เลเยอร์การจัดลำดับใช้โทเค็นเป็นศูนย์เพราะมันไม่ใช่การคิดรอบอื่นของ Claude

06. รวมเข้าที่ สิ่งกีดขวาง

การกระจายออกจะมีประโยชน์ก็ต่อเมื่อมีบางสิ่งรวบรวมมัน การรวมเข้าคือโหนดที่ขอบมาบรรจบกัน - ที่ซึ่งเอเจนต์หนึ่งตัว (หรือโค้ดชิ้นเดียว) เห็น ผลลัพธ์ต้นน้ำทั้งหมด พร้อมกัน และทำสิ่งที่ต้องการทั้งชุด: ลบรายการซ้ำข้ามแหล่งที่มา, จัดอันดับตามผลกระทบ, ออกก่อนกำหนดถ้าผลรวมทั้งหมดกลับมาเป็นค่าว่าง นี่คือที่เดียวที่สิ่งกีดขวางสร้างค่าใช้จ่ายตามเวลาจริงของมัน

กฎที่ทำให้กราฟเร็ว: ใช้สิ่งกีดขวางเมื่อขั้นตอนหนึ่งต้องการผลลัพธ์ก่อนหน้านี้ทั้งหมดพร้อมกันจริง ๆ เท่านั้น การลบรายการซ้ำข้ามทุกแหล่งที่มา? ต้องใช้สิ่งกีดขวาง - ถูกต้อง

1// ขอบ: JS ธรรมดา, ไม่มีเอเจนต์, โทเค็นเป็นศูนย์
2const flat = collected.flatMap((c) => c.items);
3log(`รวบรวม ${flat.length} รายการแล้ว`);
4
5phase('Curate');
6// โหนดสิ่งกีดขวาง: ต้องการชุดทั้งหมดเพื่อลบรายการซ้ำ + จัดอันดับ
7const curated = await agent(
8  `ลบรายการซ้ำและจัดอันดับตามผลกระทบ:\n${JSON.stringify(flat)}`,
9  { phase: 'Curate', schema: CURATED_SCHEMA },
10);

แค่ทำให้ลิสต์แบนราบ? นั่นคือขอบ ทำแบบอินไลน์ การทดสอบการดมกลิ่นนั้นโหดร้ายและง่าย: ถ้าคุณเขียน parallel → transform → parallel และ transform ตรงกลางนั้นไม่มีการพึ่งพาข้ามรายการ คุณควรใช้ไปป์ไลน์และข้ามสิ่งกีดขวางไปเลย

07. รูปเพชร: แยก → ทำงาน → รวม

นำการกระจายออกและการรวมเข้ามารวมกัน แล้วคุณจะได้โทโพโลยีหลักของกราฟเอเจนต์ที่จริงจังทุกอัน: รูปเพชร

โหนดหนึ่งแยกงาน หลายโหนดทำงานขนานกัน โหนดหนึ่งรวม มันคือรูปร่างเบื้องหลังการสแกนตลาด การตรวจสอบการพึ่งพา การตรวจสอบโค้ด รายงานการวิจัย - สลับแหล่งที่มาและพรอมต์ แล้วโครงกระดูกเดียวกันก็ปรับตัวได้

รูปแบบมาตรฐานมีชื่อที่ควรค่าแก่การจดจำ: กระจายออก → ลดขนาด → สังเคราะห์ กระจายออกเพื่อรวบรวมความกว้าง ลดขนาดด้วยโค้ดธรรมดาเพื่อบีบอัดมัน สังเคราะห์ด้วยเอเจนต์สุดท้ายเพื่อเขียนคำตอบ

เมื่อคุณเห็นรูปเพชร คุณจะหยุดถามว่า "ฉันจะทำให้เอเจนต์ของฉันทำขั้นตอนมากขึ้นได้อย่างไร" และเริ่มถามว่า "รอยแยกอยู่ที่ไหน จุดรวมอยู่ที่ไหน" - ซึ่งเป็นคำถามที่ปรับขนาดได้จริง

08. กำหนดเส้นทางขอบในขณะรันไทม์ด้วย เงื่อนไข

ไม่ใช่ทุกกราฟที่จะถูกกำหนดตายตัว บางครั้งขอบที่จะใช้ขึ้นอยู่กับสิ่งที่โหนดพบ โหนดเราเตอร์ ตรวจสอบผลลัพธ์และตัดสินใจว่าเส้นทางปลายน้ำใดจะทำงาน - จัดหมวดหมู่ตั๋ว จากนั้นแตกกิ่งไปยังตัวจัดการที่ถูกต้อง; ตรวจสอบขนาด diff จากนั้นทำการตรวจสอบอย่างรวดเร็วหรือเริ่มการตรวจสอบอย่างเต็มรูปแบบ

ในเวิร์กโฟลว์ นี่เป็นแค่ if หรือ switch ของ JavaScript บน output ที่ตรวจสอบแล้วของโหนด เพราะการควบคุมการไหลอาศัยอยู่ในโค้ด

นี่คือจุดที่ความแน่นอนกลายเป็นคุณสมบัติ ไม่ใช่ข้อจำกัด การตัดสินใจ ของเราเตอร์สามารถขับเคลื่อนโดย Claude ได้ (เอเจนต์ย่อยจัดประเภท) แต่ การกำหนดเส้นทาง เป็นโค้ดที่ Claude เขียน - ดังนั้นมันจึงทำงานในลักษณะเดียวกันทุกครั้งสำหรับการจัดประเภทเดียวกัน

คุณได้รับวิจารณญาณของ Claude ที่โหนด และความน่าเชื่อถือของสคริปต์ที่ขอบ ไม่มีเซอร์ไพรส์ "Claude ตัดสินใจข้ามการตรวจสอบ" ที่เกิดขึ้นใหม่ - เพราะการข้ามจะต้องถูกเขียนลงในกราฟ และมันไม่ได้ถูกเขียนไว้

1// โหนดเราเตอร์: เอเจนต์จัดประเภท, โค้ดเลือกขอบ
2const { severity } = await agent(
3  `จัดประเภทความเสี่ยงของ diff นี้:\n${diff}`,
4  { schema: { type: 'object',
5      properties: { severity: { enum: ['low', 'high'] } },
6      required: ['severity'] } },
7);
8
9let review;
10if (severity === 'high') {
11  // เส้นทางหนัก: ตรวจสอบแบบขนานเต็มรูปแบบ
12  review = await parallel(FILES.map((f) => () => agent(`ตรวจสอบ ${f}`)));
13} else {
14  // เส้นทางเบา: ผ่านด่วนหนึ่งครั้ง
15  review = await agent(`ตรวจสอบอย่างรวดเร็วของ ${diff}`);
16}

09. วาง ตัวตรวจสอบ บนขอบ

พลังที่แท้จริงของกราฟไม่ใช่เอเจนต์ที่มากขึ้น - มันคือโครงสร้างที่คุณสามารถวางรอบตัวมันเพื่อสร้างความมั่นใจ

โหนดตัวตรวจสอบอยู่บนขอบ ก่อนที่จะอนุญาตให้ผลลัพธ์ผ่านไปยังปลายน้ำ และงานเดียวของมันคือพยายาม ฆ่า ข้อค้นพบ ถ้ามันรอด มันก็ผ่าน ถ้าไม่ มันก็ไม่ถึงคำตอบ

สามรูปแบบที่ควรมีไว้ในมือ

• การตรวจสอบแบบเป็นปฏิปักษ์: สำหรับแต่ละข้อค้นพบ ให้สร้างผู้ขี้ระแวงอิสระ N คนที่ได้รับพรอมต์ให้หักล้างมัน; เก็บไว้ก็ต่อเมื่อส่วนใหญ่รอดชีวิต
• การตรวจสอบแบบมุมมองที่หลากหลาย: ให้ตัวตรวจสอบแต่ละตัวมีเลนส์ที่แตกต่างกัน - ความถูกต้อง, ความปลอดภัย, ทำซ้ำได้หรือไม่ - เพราะความหลากหลายจับรูปแบบความล้มเหลวที่การตรวจสอบที่เหมือนกัน N ครั้งไม่เคยทำได้
• คณะกรรมการตัดสิน: สร้างความพยายาม N ครั้งจากมุมที่แตกต่างกัน ให้คะแนนพวกเขาด้วยผู้ตัดสินแบบขนาน สังเคราะห์จากผู้ชนะ ในขณะที่ต่อกิ่งส่วนที่ดีที่สุดของรองชนะเลิศ

นี่คือรูปแบบที่ทำให้ทีมงานจริงสามารถพอร์ต Bun runtime โดยมีการตรวจสอบโค้ดแบบเป็นปฏิปักษ์ฝังอยู่ในลูป

10. แยกโหนดเพื่อให้ความล้มเหลวหนึ่งครั้งไม่สามารถ ทำให้เป็นพิษ ต่อกราฟ

ในห่วงโซ่ ความล้มเหลวจะลดหลั่นกัน - C ตาย, D ไม่เคยทำงาน, ทุกอย่างหยุดชะงัก ในกราฟ ความล้มเหลวควร ถูกจำกัดไว้ที่โหนดของมัน

นั่นเป็นความจริงบางส่วนอยู่แล้ว: thunk ที่ throw ภายใน parallel() จะ resolve เป็น null ดังนั้นเอเจนต์ที่ดีแปดตัวยังคงส่งคืนในขณะที่ตัวเสียหนึ่งตัวหลุดออกไป .filter(Boolean) ของคุณคือการกักกัน

ออกแบบ fan-in ทุกตัวให้ทนต่ออินพุตที่หายไป แทนที่จะสมมติว่ามีชุดที่สมบูรณ์

ความล้มเหลวที่ละเอียดอ่อนกว่าคือโหนดที่ก้าวก่ายกัน เมื่อเอเจนต์เขียนไฟล์แบบขนาน พวกมันสามารถชนกันได้

วิธีแก้คือการแยก: "worktree" - เอเจนต์แต่ละตัวทำงานใน git worktree ของตัวเอง, ทำงานในแซนด์บ็อกซ์, และรวมเข้าอย่างสะอาด

ใช้มันเมื่อโหนดเขียนแบบขนานจริง ๆ เท่านั้น มันคือเข็มขัดนิรภัยสำหรับโทโพโลยีเดียวที่ต้องการมัน ไม่ใช่ภาษีเริ่มต้นสำหรับทุกการรัน

11. เพิ่ม วงจร - แต่ทำให้มัน ลู่เข้า

บางครั้งคุณไม่รู้ว่างานใหญ่แค่ไหนจนกว่าคุณจะอยู่ในนั้น: การค้นพบขนาดที่ไม่รู้จัก, การกวาดล้างบั๊กที่การพบหนึ่งบั๊กเผยให้เห็นอีกสามตัว นั่นต้องการ วงจร - ขอบที่ควบคุมกลับไปยังโหนดก่อนหน้า

อันตรายนั้นชัดเจน: วงจรที่ไม่ลู่เข้าคือลูปอนันต์ที่สร้างเอเจนต์จนกว่างบประมาณของคุณจะหมด

รูปแบบที่ลู่เข้าคือ loop-until-dry: ค้นหาต่อไปจนกว่า K รอบติดต่อกันจะไม่พบสิ่งใหม่ จากนั้นหยุด รายละเอียดเดียวที่ทำให้มันสำเร็จหรือล้มเหลว - และความผิดพลาดที่เกือบทุกคนทำในครั้งแรก - คือสิ่งที่คุณใช้ลบรายการซ้ำ

ลบรายการซ้ำกับทุกสิ่งที่ เห็น ไม่ใช่แค่กับผลลัพธ์ที่ยืนยันแล้ว มิฉะนั้นข้อค้นพบที่ถูกปฏิเสธจะปรากฏขึ้นอีกทุก ๆ รอบ ลูปไม่เคยแห้ง และคุณได้สร้างเครื่องจักรที่จ่ายเงินเพื่อค้นพบทางตันเดียวกันซ้ำแล้วซ้ำเล่าตลอดไป

1const seen = new Set(); const confirmed = []; let dry = 0;
2
3while (dry < 2) {                       // หยุดหลังจาก 2 รอบที่ไม่มีอะไรใหม่
4  const found = (await parallel(
5    FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))
6  )).filter(Boolean).flatMap((r) => r.bugs);
7
8  const fresh = found.filter((b) => !seen.has(key(b)));
9  if (!fresh.length) { dry++; continue; } // ไม่มีอะไรใหม่ → เข้าสู่ภาวะแห้ง
10  dry = 0;
11  fresh.forEach((b) => seen.add(key(b))); // ลบรายการซ้ำเทียบกับ SEEN, ไม่ใช่ confirmed
12
13  // ตรวจสอบแต่ละข้อค้นพบใหม่ด้วยเลนส์ที่หลากหลายก่อนนับ
14  const judged = await parallel(fresh.map((b) => () =>
15    parallel(['correctness', 'security', 'repro'].map((lens) => () =>
16      agent(`ตัดสิน "${b.desc}" ผ่าน ${lens} — จริงไหม?`, { schema: VERDICT })))
17    .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));
18
19  confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));
20}

12. จัดลำดับชั้นของโมเดล ข้ามโหนด

ไม่ใช่ทุกโหนดที่ต้องการโมเดลที่ดีที่สุดของคุณ กราฟทำให้สิ่งนี้ชัดเจนในแบบที่เอเจนต์เดี่ยวไม่เคยทำ: โหนดบางโหนดมีขอบเขตและซ้ำซาก (แยกข้อมูลฟิลด์นี้, จัดหมวดหมู่ตั๊กเกตนี้) และบางโหนดมีวิจารณญาณที่แท้จริง (สังเคราะห์รายงาน, ตัดสินข้อค้นพบ)

รันโหนดที่น่าเบื่อบนโมเดลที่ถูกกว่า และใช้จ่ายโทเค็นราคาแพงของคุณในที่ที่วิจารณญาณอาศัยอยู่จริง

ในเวิร์กโฟลว์ เอเจนต์ย่อยทุกตัวที่ Claude สร้างขึ้นจะสืบทอดโมเดลเซสชั่นของคุณ เว้นแต่สคริปต์จะแทนที่มัน - ดังนั้นโดยค่าเริ่มต้น การรันขนาดใหญ่จะคิดค่าบริการทั้งหมดที่ระดับเซสชั่นของคุณ ตัวเลือก model บนการเรียก agent() เดียวบอกให้ Claude กำหนดเส้นทางเฉพาะโหนดนั้นไปที่อื่น

ตรวจสอบ /model ก่อนการรันขนาดใหญ่ จากนั้นให้ Claude กำหนดเส้นทางโหนดที่ซ้ำซากของการกระจายออกไปยังโมเดลที่ถูกกว่า และรักษาโหนดรวมไว้ให้อยู่ในระดับสูง นี่คือคันโยกที่เปลี่ยนกราฟที่หิวโทเค็นจากราคาแพงให้เป็นประหยัด โดยไม่ต้องแตะรูปร่างของมัน

13. โทโพโลยี คือ ต้นทุนและความหน่วงของคุณ

รูปร่างของกราฟไม่ใช่แค่เครื่องสำอาง - มันคือคันโยกที่ใหญ่ที่สุดในเวลาจริง ทางเลือกที่ทำให้ทุกคนสะดุด: parallel() เทียบกับ pipeline() สิ่งกีดขวาง parallel() ทำให้ ทุกอย่าง รอโหนดที่ช้าที่สุดก่อนที่ขั้นตอนถัดไปจะเริ่ม

pipeline() สตรีมแต่ละรายการผ่านทุกขั้นตอนอย่างอิสระ โดยไม่มีสิ่งกีดขวาง - รายการ A สามารถอยู่ในขั้นตอนที่ 3 ในขณะที่รายการ B ยังอยู่ในขั้นตอนที่ 1 รายการที่เร็วเสร็จเร็วแทนที่จะว่างอยู่ข้างหลังรายการที่ช้า

ใช้ pipeline() เป็นค่าเริ่มต้น ใช้สิ่งกีดขวางเมื่อขั้นตอนหนึ่งต้องการผลลัพธ์ก่อนหน้านี้ทั้งหมดพร้อมกันจริง ๆ เท่านั้น - การลบรายการซ้ำข้ามชุด, การออกก่อนกำหนดจากผลรวมทั้งหมด, พรอมต์ที่เปรียบเทียบกับ "ข้อค้นพบอื่น ๆ" "มันเป็นโค้ดที่สะอาดกว่า" และ "ขั้นตอนต่าง ๆ รู้สึกแยกจากกัน" ไม่ใช่เหตุผล; ความหน่วงของสิ่งกีดขวางเป็นเวลาที่เสียไปจริง ๆ และวัดผลได้ การแยกจากกันไม่เหมือนกับการซิงโครไนซ์

14. ให้ Claude วาดกราฟ - การกำหนดเส้นทางด้วยตนเอง

การเคลื่อนไหวสุดท้ายคือการหยุดวาดกราฟด้วยมือสำหรับงานที่คุณไม่สามารถวางแผนล่วงหน้าได้

ด้วย เวิร์กโฟลว์แบบไดนามิก คุณอธิบายวัตถุประสงค์ และ Claude จะเขียนสคริปต์การจัดลำดับเอง - ย่อยสลายงาน, เลือกการกระจายออก, สร้างกองทัพของเอเจนต์ย่อยที่ประสานงานกัน, และสังเคราะห์ผลลัพธ์ คุณจะได้กราฟที่ปรับแต่งสำหรับ การรันนี้ แทนที่จะเป็นกราฟที่ตายตัวซึ่งคุณหวังว่าจะพอดี

มีสามวิธีในการเริ่มต้น พูดคำว่า "workflow" ในพรอมต์ของคุณ แล้ว Claude จะเขียนหนึ่งให้สำหรับงานนั้น รัน workflow ที่บันทึกไว้หรือแบบรวม - /deep-research เป็นกราฟจริงที่ใช้งานในระบบการผลิต: ขอบเขต → ค้นหาแบบขนาน → ดึงข้อมูล → ตรวจสอบแบบเป็นปฏิปักษ์ → สังเคราะห์ ซึ่งเป็นโครงกระดูกที่แน่นอนจากหลักสูตรนี้

หรือเปิด ultracode แล้ว Claude จะวางแผน workflow สำหรับทุกงานสำคัญในเซสชั่น เมื่อการรันดี ให้กด s เพื่อบันทึกสคริปต์ของมันลงใน .claude/workflows/ - ควบคุมเวอร์ชัน, รันซ้ำได้ด้วยชื่อ, กราฟที่ใครก็ตามที่โคลน repo สามารถเปิดใช้ได้

1› รัน workflow เพื่อตรวจสอบทุกเส้นทางภายใต้ src/routes/ ว่าขาด
2auth หรือไม่ สร้างเอเจนต์หนึ่งตัวต่อไฟล์เส้นทาง จากนั้นตรวจสอบแต่ละข้อค้นพบก่อน
3รายงาน ● Claude เขียนสคริปต์การจัดลำดับ · กำลังเปิดตัวในพื้นหลัง…
4/workflows — auth-audit · กำลังทำงาน ✓ ขอบเขต 1/1 2.1k tok ·
54s ✓ กระจายออก 18/18 หนึ่งเอเจนต์ต่อไฟล์เส้นทาง ◯ ตรวจสอบ 11/18 ผู้ขี้ระแวง 3 เสียง
6ต่อข้อค้นพบ… ○ สังเคราะห์ 0/1 รอการตรวจสอบ เซสชั่นยังตอบสนอง — ทำงานต่อไปในขณะที่กองทัพทำงาน

กราฟหกแบบที่จะสร้างด้วย Claude ในสัปดาห์นี้

• การกวาดล้างความปลอดภัยข้ามทุกเส้นทาง Claude สร้าง เอเจนต์ย่อยหนึ่งตัวต่อไฟล์เส้นทาง แต่ละตัวค้นหาการตรวจสอบ auth ที่ขาดหายไป จากนั้นการตรวจสอบผ่านยืนยันทุกข้อค้นพบก่อนที่จะถึงรายงาน ความกว้างที่ไม่มีบริบทเดียวสามารถเก็บไว้ได้
• รายงานที่อ้างอิงด้วย /deep-research กราฟที่มาพร้อมกับ Claude Code อยู่แล้ว Claude ย่อยสลายคำถามของคุณเป็นมุมที่แตกต่างกัน, รันการค้นหาแบบขนาน, ลบแหล่งที่มาซ้ำ, จากนั้น ตรวจสอบทุกข้ออ้างแบบเป็นปฏิปักษ์ ด้วยผู้ขี้ระแยะสามเสียงก่อนที่จะเขียน
• พอร์ตโมดูล, ทีละไฟล์ เพดาน Bun, ปรับขนาดไปยัง repo ของคุณ Claude กระจายการแปลข้ามไฟล์, รันชุดทดสอบเป็นเกทในแต่ละไฟล์, และวนความล้มเหลวกลับ - การตรวจสอบแบบเป็นปฏิปักษ์ จับสิ่งที่การผ่านครั้งเดียวจะส่งมอบที่เสียหาย
• การตรวจสอบ diff แบบเป็นปฏิปักษ์ Claude กำหนดเส้นทางตามขนาด diff: การเปลี่ยนแปลงเล็กน้อยได้รับการตรวจสอบอย่างรวดเร็วหนึ่งครั้ง, การเปลี่ยนแปลงใหญ่ก่อให้เกิด การตรวจสอบแบบขนานเต็มรูปแบบ ด้วยผู้ตรวจสอบในเลนส์ที่แตกต่างกัน - ความถูกต้อง, ความปลอดภัย, ประสิทธิภาพ - จากนั้นคณะกรรมการตัดสินสังเคราะห์
• การสแกนระบบนิเวศตามกำหนดการ บันทึกครั้งเดียว, รันซ้ำตลอดไป Claude ตรวจสอบหลายแหล่งแบบขนาน - รีลีส, บล็อก, การสนทนา - จัดอันดับตามผลกระทบที่สิ่งกีดขวาง, และเขียนสรุป ควบคุมเวอร์ชันใน .claude/workflows/, เปิดใช้ได้ด้วยชื่อ
• การค้นพบขนาดที่ไม่รู้จัก คุณไม่รู้ว่ามีกี่บั๊ก Claude รันตัวค้นหาแบบขนาน, ลบรายการซ้ำในแต่ละสิ่งที่พบใหม่ เทียบกับทุกสิ่งที่เห็น, ตรวจสอบผู้รอดชีวิต, และวนซ้ำต่อไปจนกว่าสองรอบจะไม่พบสิ่งใหม่ - จากนั้นหยุด

บทสรุป:

ผู้ใช้พรอมต์ถามคำถาม สถาปนิกวาด กราฟ

เอเจนต์เชิงเส้นไม่เคยเป็นเพดาน - มันเป็นแค่รูปร่างแรก รูปร่างที่ทุกคนเอื้อมถึงเพราะมันตรงกับวิธีที่เราพิมพ์ หนึ่งบรรทัด, หนึ่งหัว, ทีละอย่าง

เมื่อคุณเห็นโหนดและขอบได้แล้ว คุณจะหยุดขอให้เอเจนต์ทำมากขึ้น และเริ่มขอให้กราฟทำมันให้กว้างขึ้น: กระจายออกในที่ที่งานเป็นอิสระ, กั้นขอบในที่ที่ความมั่นใจสำคัญ, จัดลำดับชั้นของโมเดลในที่ที่วิจารณญาณไม่สำคัญ

คนส่วนใหญ่จะยังคงเรียงขั้นตอนในแถว ผู้ที่เรียนรู้ที่จะวาดกราฟจะรันกองทัพ - และไม่มีวันสังเกตเห็นเพดานที่คนอื่น ๆ ติดอยู่ข้างใต้