คู่มือฉบับสมบูรณ์ด้าน Graph Engineering สำหรับ Claude Code

คนส่วนใหญ่ยังคงใช้ Claude Code เหมือนจ้างเด็กฝึกงานที่แพงมาก

พวกเขามอบหมายงานหนึ่งอย่าง รอคำตอบหนึ่งอย่าง จากนั้นก็ตัดสินใจด้วยตัวเองว่าจะทำอะไรต่อไป

แต่ทีมที่ใช้ AI ได้ประโยชน์สูงสุดกลับกำลังสร้างอะไรบางอย่างที่คล้ายกับระบบกระจายขนาดเล็ก

เอเจนต์หนึ่งตัวกำหนดขอบเขตของปัญหา

เอเจนต์ราคาถูกกว่าห้าตัวค้นหาพร้อมกัน

สคริปต์ที่กำหนดตายตัวลบรายการซ้ำออก

เอเจนต์ที่ชอบตั้งข้อสงสัยสามตัวพยายามหาจุดบกพร่องของผลลัพธ์

โมเดลระดับสูงสุดหนึ่งตัวตัดสินใจขั้นสุดท้าย

นั่นคือวิศวกรรมกราฟ

ก่อนที่คุณจะอ่านต่อ:

คั่นหน้าไกด์นี้ไว้ เพื่อที่คุณจะได้กลับมาดูรูปแบบกราฟเมื่อเริ่มสร้างเวิร์กโฟลว์ Claude ของคุณเอง

และติดตาม

@Gyome1_ -

ผมจะอธิบาย Claude Code, AI agents, และระบบที่เปลี่ยนโมเดลตัวเดียวให้กลายเป็นเวิร์กโฟลว์วิศวกรรมที่เชื่อถือได้

ผมใช้เวลาหลายสัปดาห์ในการแยกแยะสถาปัตยกรรมเอเจนต์จริง ไดอะแกรมเวิร์กโฟลว์ และรูปแบบการผลิต เพื่อสร้าง Graph Engineering ขึ้นมาใหม่เป็นคู่มือปฏิบัติเล่มเดียว

แทนที่จะเขียนพรอมต์ที่ยาวขึ้น คุณจะออกแบบเส้นทางที่ข้อมูลเดินทางผ่านระบบ:

linear → fan-out → reduce → verify → synthesize

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

การเปลี่ยนแปลงที่สำคัญคือ Claude Code ไม่จำเป็นต้องทำตัวเหมือนปัญญาเดียวที่ทำงานผ่านรายการตรวจสอบขนาดยักษ์อีกต่อไป

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

รูปแบบพื้นฐานไม่ใช่เรื่องใหม่ วิศวกรซอฟต์แวร์ใช้ DAG, pipeline, barrier, MapReduce และ worker แบบกระจายมานานหลายทศวรรษ

สิ่งที่เปลี่ยนไปคือสิ่งที่อยู่ภายในแต่ละโหนดตอนนี้

โหนดสามารถค้นหา repository, ตรวจสอบการย้ายระบบ, ท้าทายการตัดสินใจทางสถาปัตยกรรม, ตรวจสอบความล้มเหลวของการทดสอบ, หรือสังเคราะห์ผลลัพธ์อิสระห้าสิบรายการเป็นรายงานที่มีการอ้างอิงหนึ่งฉบับ

ไกด์นี้จะแยกย่อยระบบทั้งหมดตั้งแต่เอเจนต์เชิงเส้นที่ง่ายที่สุดไปจนถึง diamond graphs, router nodes, adversarial verifier panels, converging loops, model tiering, และ dynamic workflows ที่สร้างขึ้นโดยตรงภายใน Claude Code

เมื่ออ่านจบ คุณจะสามารถมองงานใหญ่แล้วหยุดถามว่า:

"ฉันควรเขียนพรอมต์อะไร?"

1. GRAPH ENGINEERING เริ่มต้นที่ค่าใช้จ่าย

วิศวกรรมกราฟมักถูกนำเสนอว่าเป็นวิธีรันเอเจนต์ให้มากขึ้น

กรอบความคิดนั้นมองข้ามส่วนที่แพง

คุณสามารถปล่อย Claude agents ยี่สิบตัวลงใน repository เดียวกัน และได้รับรายงานที่ทับซ้อนกันยี่สิบฉบับ บริบทที่ซ้ำซาก ข้อสรุปที่ขัดแย้งกัน และค่าใช้จ่าย API ที่สูงขึ้นมาก

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

ลองนึกภาพว่าคุณขอให้ Claude Code เตรียมการย้ายระบบ production:

ตรวจสอบ repository, ค้นหาทุก dependency, เสนอการย้ายระบบ, ระบุความเสี่ยง, ตรวจสอบแผน, และเขียนสรุปสุดท้าย

ภายในพรอมต์เดียว สิ่งนี้กลายเป็นกระบวนการที่ยาวและไม่โปร่งใส Claude ค้นหา codebase, เก็บผลลัพธ์ในบริบท, ออกแบบการย้ายระบบ, ตรวจสอบแผนของตัวเอง, และสร้างรายงานสุดท้าย

เมื่อรายงานล้มเหลว แหล่งที่มาของความล้มเหลวนั้นยากที่จะระบุ Claude อาจพลาดไฟล์, เข้าใจ dependency ผิด, สูญเสียรายละเอียดก่อนหน้านี้, หรือยอมรับสมมติฐานที่อ่อนแอระหว่างการตรวจสอบ

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

วิศวกรรมกราฟเปิดเวิร์กโฟลว์นั้นและให้ทุกการตัดสินใจมีตำแหน่งที่มองเห็นได้

สาขาการตรวจสอบรันพร้อมกันเพราะใช้ขอบเขตงานเดียวกันและไม่ขึ้นอยู่กับเอาต์พุตของกันและกัน

ผลลัพธ์ของพวกมันมาพบกันที่ขั้นตอน reduce ซึ่งรายการซ้ำจะหายไปและหลักฐานถูกบีบอัดเป็นชุดข้อมูลที่เล็กลง

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

ผลลัพธ์คือเวิร์กโฟลว์ที่ latency, ต้นทุนโมเดล, ขนาดบริบท, และความลึกของการตรวจสอบถูกควบคุมผ่านโครงสร้างของกราฟ

โหนดควรตัดสินใจแค่เรื่องเดียว

โหนดที่มีประโยชน์มีความรับผิดชอบที่จำกัด

ค้นหาทุกการเรียกไปยัง API ที่เลิกใช้แล้ว จำแนกความเสี่ยงในการย้ายระบบแต่ละรายการเป็น ต่ำ, ปานกลาง, หรือ สูง ทดสอบแผน rollback สำหรับกรณีที่ล้มเหลว

แต่ละโหนดต้องการอินพุตที่ชัดเจน เอาต์พุตที่กำหนดไว้ และพื้นผิวการตัดสินใจที่จำกัด

โหนดที่ค้นหา repository, ประเมินผลกระทบทางธุรกิจ, ออกแบบการแก้ไข, และเขียนคำแนะนำ ยังคงมีหลายขั้นตอนที่ซ่อนอยู่

การดีบักยังคงยากเพราะเหตุผลระหว่างกลางถูกฝังอยู่ในการเรียกโมเดลครั้งเดียว

ขอบเขตที่เล็กลงเผยให้เห็นว่าหลักฐานเข้าสู่ระบบที่ไหนและความหมายของมันเปลี่ยนไปที่ไหน

ขอบควรนำหลักฐาน

ขอบแสดงถึงข้อมูลที่จำเป็นสำหรับโหนดถัดไป

สแกนเนอร์สามารถคืนค่าออบเจกต์ที่คาดเดาได้:

1{
2  "file": "src/auth/session.ts",
3  "lines": [84, 119],
4  "dependency": "legacySessionClient",
5  "confidence": 0.94,
6  "evidence": "Both call sites depend on the deprecated refresh method."
7}

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

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

เอาต์พุตที่มีโครงสร้างทำให้หลักฐานคงที่ในขณะที่เคลื่อนผ่านกราฟ

โหนดบางตัวเป็นโค้ดธรรมดา

สมมติว่าเอเจนต์ค้นหาแปดตัวคืนผลลัพธ์แปดสิบรายการ

เวิร์กโฟลว์ต้องรวมอาร์เรย์ ทิ้งการตอบกลับที่ว่างเปล่า ลบรายการซ้ำ และเรียงลำดับรายการที่เหลือ

การดำเนินการเหล่านี้มีคำตอบที่แน่นอน:

1const uniqueFindings = [
2  ...new Map(
3    results
4      .flatMap(batch => batch ?? [])
5      .map(item => [`${item.file}:${item.lines.join("-")}`, item])
6  ).values()
7];

การแปลง JavaScript จัดการสิ่งนี้ได้ทันทีและสร้างเอาต์พุตเดียวกันทุกครั้งที่รัน การส่งงานเดียวกันไปยังโมเดลอื่นจะเพิ่มต้นทุน token และสร้างจุดที่หลักฐานสามารถหายไปได้อีก

โหนดโมเดลควรอยู่รอบๆ การค้นหา การจำแนก การเปรียบเทียบ การตรวจสอบ และการสังเคราะห์ โค้ดสามารถจัดการการตรวจสอบ การลบรายการซ้ำ การเรียงลำดับ กฎการกำหนดเส้นทางที่ชัดเจน และการแปลงอื่นๆ ที่คาดเดาได้

การแบ่งส่วนนี้กลายเป็นรากฐานของกราฟ

ทุกการเรียกโมเดลควรสอดคล้องกับการตัดสินใจที่ต้องใช้การตัดสินใจจริงๆ

2. THE DIAMOND: กราฟเอเจนต์จริงย้ายงานอย่างไร

กราฟเอเจนต์ที่จริงจังส่วนใหญ่ในที่สุดจะมีรูปร่างเดียวกัน

งานเริ่มต้นด้วยขอบเขตร่วมกันหนึ่งเดียว แยกออกไปยัง worker อิสระหลายตัว รอเอาต์พุตของพวกมัน บีบอัดหลักฐาน และส่งผลลัพธ์ไปยังการตัดสินใจสุดท้าย

รูปร่างนั้นคือเพชร (diamond)

ด้านซ้ายคือ fan-out

จุดกลางที่ทุกสาขามาบรรจบกันคือ barrier

ด้านขวาคือ fan-in

รูปแบบนี้ปรากฏทุกที่เมื่องานใหญ่เกินไปสำหรับหน้าต่างบริบทเดียว

การตรวจสอบ repository สามารถแยกตาม subsystem รายงานตลาดสามารถแยกตามแหล่งที่มา งานวิจัยสามารถแยกตามสมมติฐาน การตรวจสอบการย้ายระบบสามารถแยกตามการใช้งาน API, การเปลี่ยนแปลงฐานข้อมูล, ความเสี่ยงในการปรับใช้, และความครอบคลุมของการทดสอบ

worker แต่ละตัวได้รับขอบเขตเดียวกันกับงานที่แคบลง

จากนั้นกราฟจะรอจนกว่าหลักฐานที่มีประโยชน์เพียงพอจะกลับมา

Fan-out ควรสร้างงานอิสระ

สาขาอยู่ใน fan-out เมื่อมันสามารถเริ่มจากอินพุตร่วมกันและสร้างผลลัพธ์ที่มีประโยชน์โดยไม่ต้องอ่านเอาต์พุตของสาขาอื่น

สำหรับการตรวจสอบความปลอดภัย การแยกอาจมีลักษณะดังนี้:

Claude Code สามารถเรียกใช้การทำงานเหล่านี้พร้อมกันด้วย primitive barrier เช่น parallel()

1const findings = await parallel(
2  checks.map(check => async () => {
3    return agent({
4      task: check.task,
5      context: auditScope,
6      schema: FINDING_SCHEMA
7    });
8  })
9);

การจัดเตรียมยังคงอยู่ใน JavaScript ธรรมดา แต่ละสาขาได้รับงานที่จำกัดและคืนออบเจกต์ที่ตรวจสอบแล้ว

ผลลัพธ์มาถึงเป็นชุดของเอาต์พุตที่สามารถกรอง ตรวจสอบ และส่งต่อไปยังขั้นตอนถัดไป

fan-out ขนาดใหญ่ยังคงต้องมีเหตุผลอยู่เบื้องหลังทุกสาขา

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

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

Barrier สร้างจุดตัดสินใจ

barrier จะหยุดขั้นตอนถัดไปชั่วคราวจนกว่าสาขาที่จำเป็นจะเสร็จสมบูรณ์

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

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

ที่ barrier กราฟมีโอกาสตรวจสอบสถานะของการรัน:

1const completed = findings.filter(Boolean);
2
3if (completed.length < MIN_REQUIRED_RESULTS) {
4  throw new Error("Insufficient audit coverage");
5}

นี่คือจุดที่ความล้มเหลวบางส่วนมองเห็นได้

worker อาจหมดเวลา คืนข้อมูลที่ผิดรูป หรือไม่สร้างผลลัพธ์ การกรองค่า null ช่วยให้การรันดำเนินต่อไป แต่เวิร์กโฟลว์ production มักต้องการนโยบายที่ชัดเจนกว่า:

• ต้องการสาขาที่สำเร็จกี่สาขา;
• สาขาไหนที่จำเป็น;
• โหนดที่ล้มเหลวควรลองอีกครั้งหรือไม่;
• ควรทำเครื่องหมายผลลัพธ์สุดท้ายว่าไม่สมบูรณ์หรือไม่

ดังนั้น barrier จึงเป็นส่วนหนึ่งของโมเดลความน่าเชื่อถือ ไม่ใช่แค่กลไกการซิงโครไนซ์

Reduce ก่อนที่จะสังเคราะห์

หลังจาก fan-out กราฟอาจมีผลลัพธ์ที่ทับซ้อนกันหลายสิบรายการ

การส่งทั้งหมดเข้าไปในโมเดลระดับสูงสุดโดยตรงจะสร้างบริบทขนาดใหญ่ ทำซ้ำหลักฐานเดียวกัน และทำให้รายละเอียดสำคัญแยกแยะได้ยากขึ้น

ขั้นตอน reduce เตรียมหลักฐาน

การลดบางอย่างสามารถเกิดขึ้นในโค้ด:

1const unique = deduplicateByKey(
2  completed.flatMap(result => result.findings),
3  finding => `${finding.file}:${finding.line}:${finding.type}`
4);

ชั้นถัดไปอาจต้องใช้การตัดสิน:

1const curated = await agent({
2  task: `
3    จัดกลุ่มผลลัพธ์ที่เกี่ยวข้อง
4    เก็บการอ้างอิงไฟล์และบรรทัดทั้งหมด
5    จัดอันดับแต่ละกลุ่มตามผลกระทบในการดำเนินงาน
6    ส่งคืนหลักฐานที่แข็งแกร่งที่สุดสำหรับทุกข้อสรุป
7  `,
8  input: unique,
9  schema: CURATED_FINDINGS_SCHEMA
10});

การลดควบคุมสิ่งที่ไปถึงโมเดลสุดท้าย

ตัวลดที่ดีจะลบการซ้ำซ้อนในขณะที่เก็บหลักฐานไว้ ตัวลดที่รุนแรงอาจบีบอัดความเสี่ยงที่แตกต่างกันหลายรายการเป็นสรุปที่คลุมเครือหนึ่งเดียวและลบรายละเอียดที่จำเป็นสำหรับการตรวจสอบ

รูปแบบที่ปลอดภัยที่สุดจะเก็บลิงก์ระหว่างทุกข้ออ้างที่ถูกลดและรายการต้นทางของมัน

1{
2  "risk": "Session refresh may fail after migration",
3  "severity": "high",
4  "sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],
5  "evidence": [
6    "Three services call the deprecated refresh method",
7    "No fallback path exists",
8    "Integration coverage is missing"
9  ]
10}

ตอนนี้โหนดสังเคราะห์ได้รับชุดข้อมูลที่เล็กลงโดยไม่สูญเสียการติดตามย้อนกลับ

3. ความน่าเชื่อถือเป็นส่วนหนึ่งของกราฟ

กราฟสามารถเสร็จเร็วและยังคงให้คำตอบที่ไม่ดีได้

เมื่อเอเจนต์หลายตัวเริ่มค้นหา จำแนก และตรวจสอบงานเดียวกัน ปัญหาหลักกลายเป็นการควบคุม

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

กำหนดเส้นทางตามความเสี่ยง

โหนดเราเตอร์อ่านเอาต์พุตที่มีโครงสร้างและเลือกสาขาถัดไป

การจำแนกสามารถมาจากโมเดล ในขณะที่สาขาเองยังคงชัดเจนในโค้ด

1const route =
2  finding.severity === "high"
3    ? runFullAudit(finding)
4    : runQuickReview(finding);

สิ่งนี้ทำให้การตรวจสอบที่มีราคาแพงกระจุกตัวอยู่รอบๆ ผลลัพธ์ที่มีผลกระทบที่มีความหมาย

เราเตอร์ที่มีประโยชน์อาศัยฟิลด์ที่กราฟสามารถตรวจสอบได้: ความรุนแรง, ความมั่นใจ, ระบบที่ได้รับผลกระทบ, การเปิดรับทางการเงิน, หรือการมีอยู่ของหลักฐานที่ขาดหายไป

เพิ่มการตรวจสอบอิสระ

เอเจนต์หนึ่งตัวที่ตรวจสอบข้อสรุปของตัวเองจะนำสมมติฐานเดียวกันเข้าสู่ทั้งสองขั้นตอน

กราฟที่แข็งแกร่งกว่าจะส่งผลลัพธ์ที่สำคัญไปยังผู้ตรวจสอบหลายคนที่มีงานที่แตกต่างกัน

ผู้ตรวจสอบไม่ควรได้รับคำแนะนำให้ปรับปรุงคำตอบเดิม งานของพวกเขาคือค้นหาเหตุผลว่ามันอาจไม่สมบูรณ์หรือผิด

กราฟสามารถกำหนดให้ต้องมีข้อตกลงก่อนที่ผลลัพธ์จะก้าวต่อไป:

1const accepted = votes.filter(vote => vote.approve).length >= 2;

แยกเอเจนต์ที่เปลี่ยนแปลงโค้ด

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

เอเจนต์หนึ่งอาจเขียนทับไฟล์ในขณะที่อีกตัวยังอ่านอยู่ การทดสอบอาจรันกับส่วนผสมของการเปลี่ยนแปลงที่ไม่เกี่ยวข้องกัน

Git worktrees ให้แต่ละสาขามีสำเนา repository ของตัวเอง

1main repository
2      │
3      ├→ worktree/auth-fix
4      ├→ worktree/db-migration
5      └→ worktree/test-repair

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

สิ่งนี้เปลี่ยนการแยกตัวให้เป็นส่วนหนึ่งของกราฟแทนที่จะเป็นขั้นตอนการทำความสะอาดด้วยตนเอง

ปล่อยให้การค้นพบมาบรรจบกัน

งานบางอย่างไม่สามารถทำให้เสร็จในรอบเดียว

การตรวจสอบ repository อาจค้นพบ dependency ที่ชี้ไปยังแพ็คเกจอื่น แพ็คเกจนั้นอาจเผยให้เห็นจุดเรียกอื่น กราฟต้องการวิธีควบคุมเพื่อค้นหาต่อไปโดยไม่ต้องทำซ้ำทุกอย่างที่เห็นแล้ว

1const seen = new Set();
2let dryRounds = 0;
3
4while (dryRounds < 2) {
5  const findings = await discoverNext([...seen]);
6  const fresh = findings.filter(item => !seen.has(item.id));
7
8  fresh.forEach(item => seen.add(item.id));
9  dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;
10}

รายละเอียดที่สำคัญคือการลบรายการซ้ำกับทุกรายการที่เคยเห็นแล้ว

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

ลูปจะหยุดหลังจากหลายรอบที่แห้ง (dry rounds), งบประมาณที่คงที่, หรือจำนวน iteration สูงสุด กราฟ production มักต้องการทั้งสามอย่าง

จับคู่โมเดลกับโหนด

ไม่ใช่ทุกโหนดที่ต้องการโมเดลที่แข็งแกร่งที่สุดที่มี

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

การแบ่งชั้นโมเดลกลายเป็นคุณสมบัติอีกอย่างของกราฟ

งบประมาณถูกกำหนดโดยจำนวนโหนดที่รัน, ลูปทำซ้ำบ่อยแค่ไหน, บริบทที่ข้ามแต่ละขอบมากแค่ไหน, และโมเดลไหนจัดการแต่ละขั้นตอน

กราฟที่มีการค้นหาถูกยี่สิบครั้งยังคงมีราคาแพงกว่าการเรียกที่แรงหนึ่งครั้ง สถาปัตยกรรมต้องใช้งบประมาณ token ก่อนที่จะต้องการสาขาอื่น

รู้ว่าเมื่อไหร่ควรหยุดวาด

งานเล็กๆ ไม่ค่อยต้องการเราเตอร์, แผงลงคะแนน, worktrees, และลูปการบรรจบกัน

ค่าใช้จ่ายของกราฟรวมถึงโค้ดการจัดเตรียม, สคีมา, การลองใหม่, การบันทึก, การจัดเก็บระหว่างกลาง, และสถานะความล้มเหลวมากขึ้นให้ดีบัก

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

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

เวิร์กโฟลว์ที่สมบูรณ์อาจมีลักษณะดังนี้ในที่สุด:

คุณค่ามาจากการทำให้การเคลื่อนที่ของงานมองเห็นได้

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

ถึงจุดนั้น Claude Code จะไม่ทำงานผ่านคำสั่งยาวๆ หนึ่งคำสั่งอีกต่อไป

มันกำลังดำเนินการระบบที่ถูกออกแบบทางวิศวกรรม