หัวข้อเรื่องเดิม: "อัซเพน หลักประกัน ฝันดัดแปลง: ทำไมโครงสร้างแบบ 'บริษัทเสมือน' หลายตัวแทนในด้านวิศวกรรมไม่สามารถสร้างขึ้นได้"

แนวคิดโครงสร้างที่กระจายกันอย่างแพร่หลายในชุมชน AI กำลังทำให้ทีมมากมายเส้นทางทางเด็กวีหัน

เริ่มแรกพูดถึงข้อสรุป

หากคุณกำลังพิจารณาที่จะให้ตัวแทน AI หลายตัวแทนชื่อเรียกต่างๆ เช่น "ผู้จัดการผลิตภัณฑ์", "สถาปัตยกรรม", "วิศวกรทดสอบ" แล้วทำให้พวกเขาทำงานร่วมกันเหมือนแผนกของบริษัทในการส่งผลิตภัณฑ์และร่วมมือกัน — โปรดหยุด

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

นี่ไม่ใช่ความบังเอิญ

แบบออกแบบ 'สามจังหวัดหกส่วน'

การเปรียบเทียบนี้หมายถึงรูปแบบการออกแบบหลายตัวแทนที่มีความนิยมในชุมชน ในโครงการและบทความที่แตกต่างกันมีชื่อต่างกัน: ตัวแทนที่มีบทบาท, ทีมเสมือน, การกระจายงานแบบ CrewAI, โครงการ Gururaja ที่ล้อมรอบตนเอง — ในบทความนี้เรียกว่า 'สามจังหวัดหกส่วน'

รูปแบบกลางตัวคือ: แยกงานทำงานที่ซับซ้อนออกเป็นหลายบทบาท แต่ละตัวแทนเล่นบทบาทหนึ่ง — PM รับผิดชอบความต้องการ, ผู้นำทางเทคนิค รับผิดชอบโครงสร้าง, Dev รับผิดชอบการปฏิบัติ, QA รับผิดชอบการทดสอบ งานเคลื่อนไหวระหว่างตัวแทนเหมือนสายการผลิต

รูปแบบนี้ดูดีมากในกราฟิก มันตอบสนองต่อความคิดทาง "การแบ่งงาน" ของมนุษยชาติ และทำให้ความคิด "ทีม AI" เข้าใจและน่าตื่นตาตื่นใจ Framework CrewAI และเฟรมเวิร์คที่คล้ายกันได้สะสมผู้ใช้เป็นจำนวนมาก

ปัญหาอยู่ที่มันแก้ปัญหาที่เกิดจากมนุษย์ ไม่ใช่ปัญหาของ AI

ทำไมการเปรียบเทียบชนิดนี้โดยกำเนิดผิด

มนุษย์ต้องการที่จะทำงานร่วมกัน เนื่องจาก:

· ความสนใจของบุคคลละเอียด, ไม่สามารถดูแลทุกข้อมูลพร้อมกันได้

· มนุษย์มีความเชี่ยวชาญลึกซึ้ง, ค่าใช้จ่ายในการเรียนรู้และเปลี่ยนสาขาสูง

· บุคคลและบุคคลต้องการอินเทอร์เฟซในการประสานงาน

แต่ลักษณะของ LLM ที่แตกต่างอย่างสิ้นเชิง:

· โมเดลเดียวกันสามารถเขียน PRD และโค้ดได้พร้อมกัน โดยไม่มี「ขอบเขตอาชีพ」

· Bottleneck ของโมเดลไม่ใช่ความกว้างของความสนใจ แต่เป็นความลึกของการคิดตรง ๆ และความสมบูรณ์ของข้อมูล

· ไม่มี「วัฒนธรรม」และ「ความเข้าใจสม่ำเสมอ」 ระหว่างโมเดลเพื่อชดเชยการสูญเสียของข้อมูล

การป้าย Agent ว่าเป็น「ผู้บริหารผลิตภัณฑ์」 จะไม่ทำให้มันเชี่ยวชาญมากขึ้น—แต่จะทำให้มันปฎิเสธการล้มเหลวขอบเขต หนึ่ง Agent ที่ถูกขอบเขตโดยบทบาท「วิศวกรการทดสอบ」 ที่เจอปัญหาในระดับโครงสร้างอาจกระโดดข้ามโดยตรงเพราะ「ไม่อยู่ในขอบเขตของงานของฉัน」 การตรวจสอบที่มีคุณค่าที่สุดมักเกิดขึ้นที่ขอบเขต แต่รูปแบบสามสี่อย่างตรงกันจัดล็อกโอกาสนี้ในระดับระบบ

การเล่นบทบาทสร้างขอบเขตเท็จ. นี่คือปัญหาครั้งแรก

ปัญหาที่สอง: ข้อมูลตายตัวในกระบวนการไหล

ในโครงสร้างห้าสี่ ประทับใจ A สร้างเอกสารและส่งให้ B

กระบวนการนี้ส่งผ่าน การสรุป ไม่ใช่ กระบวนการคิดตรง ๆ

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

องค์การบุคลากรใช้การประชุม วัฒนธรรม การสื่อสารที่ไม่เป็นทางการเพื่อชดเชยสูญเสียข้อมูล Agent อารมณ์การระหว่างตนเองไม่มีกลไกเหล่านี้

นี่เป็นข้อโต้แย้งที่พบบ่อย: วิธียอดนิยมของบริษัทสามสี่ (progress.txt, spec ไฟล์, runbook) ไม่ใช่「ส่งเอกสาร」ใช่ไหม? ความแตกต่างอยู่ที่ใครเขียน เขียนให้ใคร และวิธีอัปเดตอย่างไร

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

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

ความแตกต่างนี้กำหนดว่าเชื่อมโยงสรรพสาครสามารถรักษาความต่อเนื่องข้ามเซสชันหรือไม่

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

วิธีที่สามิัพดำเนินการจริง ๆ

สิ่งที่น่าสังเกตคือ เมื่อ Anthropic、OpenAI และ Google สร้างระบบเอเจนต์ในห้วของตนจริง ๆ คำว่า「การเล่นบทบาล」หรือ「การแบ่งบทบาลตามแผนก」เกือบไม่ปรากฏในเอกสารช่างฝีมือของพวกเขา

Anthropic: วิศวกรรมบริบท + ไฟล์สถานะโดยชัดเจน

Anthropic ภายในได้นำ「วิศวกรรมโปรโมปต์」 สู่ระดับสูงกว่าโดยที่ในท้ายที่ประกอบประกันสุขภาพ่ : ปัญหาไม่อยู่ที่การเขียนโปรโมปต์อย่างดี แต่อยู่ที่การกำหนดโทเค็นได้อย่างไรที่สามารถสร้างพฤติกรรมที่ต้องการ

ในขณะที่กำลังสร้างระบบ Claude Code และ Research พวกเขาเผชิญกับความท้าทายหลักคือ: เอเจนต์ต้องทำงานในเซสชันที่แตกต่างกัน โดยทุกเซสชันใหม่ไม่มีความทรงจำเกี่ยวกับสิ่งที่เคยเกิดขึ้น อุปมสมรคเป็น «นักวิศวกรปฏิบัติ»—วิศวกรเข้างานในอายุแต่งงานใหม่ๆว่างพักเป็นปากต่องก็ถูกส่อเสียวาคการทำงานของอายุแต่งการที่แล้ว

การแก้อาการปัญหาไม่ใช่การทำให้อาจปฏิบัติบทบาลต่างกัน เราจธำา:

· claude-progress.txt: บันทึกการทำงานข้ามเซสชัน ที่อัพเดททุกเวลาที่เซสชันจบ และถูกอ่านโดยเซสชันถัดไปที่เริ่ม

· ประวัติ Git: เป็นจุดยศถาวรของสถานะบันทึก บันทึกการเปลี่ยนแปลงเพิ่มเติมทุก ๆ ครั้ง

· Initializer Agent: ใช้งานเฉพาะใน Session แรกเท่านั้น เพื่อสร้างสภาพแวดล้อม แกะสรรค์รายการ feature และเขียน runbook เพื่อ Session ทุกตัวใช้

ข้อความสำคัญ: ความต่อเนื่องของเชื่อมโยงทำนายไม่ใช่การ "จำ" ของโมเดล แต่ใช้สถานะภายนอกแสดงตัวตั้งตรึง

พวกเขาพบว่าการฝัง "ความสามารถของโมเดล" เข้าเเบรนส์ เป็นวิกฤต Sonnet 4.5 มี "ความกังวลของบริบท" — คงอยู่ในขีดจำกัดของบริบทโดยตัดช้าต่อจบก่อน ดังนั้นเบรนส์ถูกเพิ่มรีเซ็ตบริบทไว้

แต่พฤกษสาย Opus 4.5 พฤษอยุติ: การรีเซ็ตมีเป็น "น้ำหนักตาย" นี่บ่งชี้ว่า เบรนส์ต้องพัฒนาร่วมกับการรุกเริ่ดของโมเดล ทุกวาจสร เร้าของการวอนคล็อปอาคศ "ตัววาจอง" มีป้มการเลี้ยงของโมเดลให้เหมาะสม

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

พวกเขาค้นพบว่าปริมาตรการใช้ token เองได้อธิบายผลต่างในประสิทธิภาพ 80% — มูลค่าของ Agent หลายชั้นไม่ได้เป็น "การกำหนดภาระ" แต่เป็น การใช้ token เพิ่มเติ่มเพื่อรองรับพื้นที่ค้นหาที่ใหญ่ขึ้น

มีจุดสับสนที่ง่ายต่อการสับสน: Subagent ของ Anthropic ดูเหมือนว่ามี "การจำแนกงาน" เช่นกัน แต่กำเนิดแตกต่างอย่างสิ้นเชิง ไตารมินละหกรสเป็นการจำแนกงานจากฟังก์ชัน—บทบาทที่แตกต่างต้องการงานทำส่งจนให้กับ Dev โปรแกรมเมอร์ทำส่งจนให้กับ QA แต่ละบทบาทจดที่ผิดมันแต่เพียงแต่ หัวหน้ากระบวนการสิ้นสุดจากพื้นที่ค้นหาที่จุ่มสำหรับสัปดาห์งาน—ทำหน้าที่บนบริบทแต่เรียกขึ้นการสร้างร่วมกันหรือ/ atau คือกันแท้

OpenAI: คอมแพ็คชัน + ทักษะ + ไฟล์สเปกโครงสร้าง

OpenAI มีหลักการงานยาวเข้าใจง่ายมากขึ้น: วางแผนสำหรับความต่อเนื่องในทันทีที่เริ่มงาน

ในการทดลอง Codex ของพวกเขา, วิศวกรให้เอเจนต์ได้ spec ไฟล์ (ทำให้เป็นเป้าหมายที่ถูกต้อง และป้องกันไม่ให้เอเจนต์「สร้างสิ่งที่น่าประทับใจมาก แต่ทางที่ผิด」), ซึ่งทำให้มันสร้างแผนที่มีขั้นตอนตามก้าว แล้วใช้ไฟล์ runbook เพื่อบอกเอเจนต์วิธีการดำเนินการ ไฟล์ runbook นี้เป็นเช่นกันที่เป็นหลักถึงความทรงจำแบ่งปัน และบันทึกการตรวจทาน

ผลลัพธ์: GPT-5.3-Codex ทำงานเกือบ 25 ชั่วโมงต่อเนื่อง สร้างเครื่องมือออกแบบที่สมบูรณ์ โดยรักษาความต่อเนื่องตลอดการดำเนินงาน

การบีบอัดด้านเซิร์ฟเวอร์เป็น primitive ค่าเริ่มต้น ไม่ใช่ fallback ที่เร่งเร็ว ในงานหลายขั้นตอน, previous_response_id ช่วยให้โมเดลสามารถทำงานต่อจาก context เดิมใน thread เดียว แทนที่ต้องสร้าง context ใหม่ทุกครั้ง

พวกเขายังมีการนำเข้าคอนเซปต์ของ Skills – ชุดคำสั่งที่สามารถนำกลับมาใช้ซ้ำได้ และที่มีรุ่น เชื่อมกับคอนเทนเนอร์ ทำให้เอเจนต์ดำเนินกิจกรรมพิเศษได้ตามมาตรฐานการดำเนินการอย่างมั่นคง สิ่งนี้ไม่ใช่「ตำแหน่ง」 แต่เป็นเครื่องมือและข้อบังคับการดำเนินงาน ที่เป็นความแตกต่างในสิ่งที่แท้จริง

Google: 1M บริบท + การพัฒนาจากเนื้อความของบริบท

ทิศทางของ Google คือการขยายหน้าต่างแบบชนะ: บริบท 1M โทเคนของ Gemini เป็นกลยุทธ์ที่ชัดเจน หนึ่งข้อเรียกร้องของพวกเขาคือ: การตัดสินใจในอดีต การที่ต้องเสีย RAG และวิธีที่จัดส่งข้อความเก่าไป, ในหน้าต่างที่ใหญ่พอ สามารถใช้วิธีการ「ใส่ตรงไป」แทน

แต่พวกเขายังไม่รู้สึกพอใจ Google เปิดตัว Conductor extension ใน Gemini CLI, ความคิดหลักกับ Anthropic มากน้อยเหมือน กัน: นำเอาเจตมาออกจากหน้าต่างสนทนา และวางไว้ในไฟล์ Markdown ถาวรของโค้ด ความคิดทาง哲學คือ: 「อย่าใช้การ์เด็นที่ไม่เสถียร, ให้ขึ้นอยู่กับไฟล์สเปกและแผนที่ถูกต้อง」

Gemini 3 ยังนำเสนอกลไล Thought Signatures: บันทึกจุดเด่นของเส้นทางการคิดในเซสชั่นยาว เพื่อป้องกันปัญหา "reasoning drift" — การที่ตรรกะในบริบทยาวเปลี่ยนแปลงโดยไม่สอดคล้องกัน

หลักสถาปัตยกรรมแท้

จากปฏิบัติการวิศวกรรมของสามบริษัท สามารถสรุปหลักการร่วมกันได้หลายอย่าง:

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

สถานะภายนอกชัดเจน ไม่พึ่งอยู่กับการจำขอํง ไฟล์ความก้าวหน้า progress.txt, ประวัติ Git, ไฟล์สเปค, ฐานข้อมูล — รูปแบบไม่สำคึญ หลักการคือ: จุดเด่นในเส้นทางการคิดต้องถูกส่งออกไปยังสตอเกสต้นทางก้อนของความจำถาวรและไม่ขึ้นอยู่กับการจำขอํในหน้าต่างบริบท

คุณค่าของ Multiple Agent เป็นการครอบคลุมแบบพร้อมเสารจ และไม่ใช่การแบ่งงาน ระบบการวิจัยที่เน้นมนุษย์ชัดเจนขาดคุย: ประสิทธิภาพเพิ่มขึ้นส่วนใหญ่มาจากการ "ใช้ token มากขึ้น" และไม่ใช่การ "แบ่งงานอย่างเหมาะสม". Multiple Agent เหมาะสมสำหรับงานประเภท breadth-first — ที่ต้องการสืบสวนทางตัดที่สิ้นเชิงเป็นหลายทิศทาง แต่ไม่เหมาะสมสำหรับสถานการณ์ที่ต้องการตรรกะต่อเนื่องและการพึงพิจารณาลึกซึ้งบริบท

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

เครื่องมือคือเครื่องมือ ไม่ใช่บทบาท การจัดให้ Agent มีเครื่องมืออะไร (bash, การเขียน/อ่านไฟล์, การค้นหา, การสั่งรันโค้ด) มีแรงบังคับมากกว่าการให้ป้ายชื่อให้กับอะไรเขาพร้อมทำ เครื่องมือกํบังตัดสินใจภายให Agent ที่พร้อมทำอะไร; ป้ายชื่อบทบาทเพียงเพื่อจํากัดเขายิน่อยทำอะไร

ทำไมงานสามนิยเมืองถึงได้อยุ้งรุ่ง?

เพราะว่ามันเข้าใจง่าย

「เอเจ้นต์นี้คือ PM，และเอเจ้นต์อีกตัวคือ QA」—ประโยคนี้ใครๆ ก็เข้าใจได้ มันทำให้ความต้องการที่เรามีต่อความชัดเจนของระบบ AI ขึ้นอยู่ได้ และทำให้ความคิดของผู้บริหารเกี่ยวกับ AI ทำงานเหมือนทีมได้รับการตอบสนอง

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

แต่การตอบคำถามและการนำเสนออย่างดี กับความเชื่อถือได้ว่าสถาปัตย์เป็นสองเรื่องต่างกัน

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

คำแนะนำในการปฏิบัติ

ระบบหลายเอเจ้นต์ที่ดีที่สุด ไม่เหมือนสถานประกอบไม่! มันเหมือนผลงานฉบับร่างหลายครั้ง—แบรนของคิด ณ มิติต่าง โดนการแยกสร้างเหตุผลสุจริตณแลนุสสุปเหตุผลไลฮปมาลัใากลย ุวว.

จากหลักการเหล่านี้:

ไม่ต้องถามว่า「ผมต้องการเอเจ้นต์กี่คน」 สอบถามว่า「โครงสร้างขึ้นตอนข้อมูลของงานนี้คืออะไร」.

ถ้างานต้องการการเหตุการณ์ต่อเนื่อง ใช้หลักการตรรกะซึ่งดีและการวิญญฃ์บริบทมากขึ้น (เช่นการเขียนเอกสารออกแบบฟั่นหน้ามุชล) อาจจะดีกว่าเอเจ้นต์หละแบบ + วิญญฃ์บริบทจัก.

ถ้างานต้องการสำรวจทางทับต่างต่อหนหาย (เช่นการสำรวจสมัครคู่อีกต่างหาย สบัวหรรดโมดูล 10 รายกันvroobesn) ทางทุอน ง ปรานกนี้ตอการผสิ ออเจ ข้กี

ถ้างานครอเปรับริมี่หนหายนเนชารย่าดระับ ไขานไ์เตลเอสเททส ฟาีสิ

· วัตถุประสงค์ของงาน (ที่คงที่ ด้านา นเะิถนหย่ อสิธ เลืตมิตี ปิกรีิอ ค่าจนท่า) .ป้าู

· สถานะปัจจุบัน（การถ่ายทอดข้อมูลล่าสุด）

· ช่องว่างที่รู้จัก（การเพิ่มเติมเพื่อหลีกเลี่ยงการซ้ำซ้อนใน session ถัดไป）

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

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

ที่สุด: ศักยภาพของโมเดลกำลังขึ้นอย่างรวดเร็ว อาจจะทำให้ workaround ที่ต้องใช้อยู่ใน harness วันนี้ กลายเป็นเรื่องที่ใช้จริงตอนหลัง. Anthropic ได้ตรวจสอบเรื่องนี้แล้ว — anxiety ใน context ของ Sonnet 4.5 ได้หายไปใน Opus 4.5, context reset ที่ออกแบบมาให้มันเป็นพลาง ก็กลายเป็นโค้ดที่ไม่ได้ใช้งานอีกต่อไป การรักษาความสามารถของโครงสร้างให้สามารถปรับเปลี่ยนกว่าการเลือกโครงสร้าง "สมบูรณ์"

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

เมื่อคุณได้พบปัญหามันเป็นเวลานานเกินไปแล้ว

หมายเหตุ :

บล็อกเว็บ Anthropic Engineering (การสร้างเอเจนต์ที่มีประสิทธิภาพ, การวิศวกรรมบรรยากาศที่มีประสิทธิภาพ, ระบบวิจัย Multi-Agent, เฮาร์เนสที่มีประสิทธิภาพสำหรับเอเจนต์ที่ทำงานนาน, เอเจนต์ที่จัดการ); บล็อกเว็บนักพัฒนาของ OpenAI (เรียกใช้งานงานระยะเวลานานด้วย Codex, Shell + Skills + Compaction); บล็อกนักพัฒนาของ Google (การสร้างเฟรมเวิร์ค Multi-Agent ที่มีการสำรองต่อบริบาลที่มีบริบท, พ่อค้า: การพัฒนาที่เชื่อมโยงกับบริบทสำหรับ Gemini CLI)

ลิงก์ต้นฉบับ