ภาพลวงตาของบริษัทเสมือนจริง: ทำไมสถาปัตยกรรม Multi-Agent แบบแบ่งบทบาทถึงล้มเหลวในงานวิศวกรรม

**

แนวคิดทางสถาปัตยกรรมที่ถูกพูดถึงอย่างกว้างขวางในวงการ AI กำลังนำทีมจำนวนมากหลงทาง

สรุปก่อนเลย

หากคุณกำลังคิดจะตั้งชื่อ AI Agent หลายตัวเป็น "Product Manager" "Architect" และ "Test Engineer" แล้วให้พวกมันส่งเอกสารและทำงานร่วมกันเหมือนแผนกในบริษัท—กรุณาหยุด

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

นี่ไม่ใช่เรื่องบังเอิญ

สถาปัตยกรรม "สามกรมหกกระทรวง" คืออะไร?

คำอุปมานี้หมายถึงแนวคิดการออกแบบ multi-agent ที่ได้รับความนิยมในชุมชน โดยมีชื่อเรียกต่างกันในแต่ละเฟรมเวิร์กและบทความ: role-based agents, virtual teams, CrewAI-style division of labor หรือ MetaGPT-style organization บทความนี้จะเรียกรวมกันว่าโมเดล "แบบแผนก"

รูปแบบหลักคือ: แยกย่อยงานที่ซับซ้อนออกเป็นหลายฟังก์ชัน โดย Agent แต่ละตัวสวมบทบาท—PM รับผิดชอบ requirements, Tech Lead รับผิดชอบ architecture, Dev รับผิดชอบ implementation และ QA รับผิดชอบ testing งานจะไหลระหว่าง Agent เหมือนสายการผลิต

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

ปัญหาคือ มันแก้ปัญหาคอขวดของมนุษย์ ไม่ใช่คอขวดของ AI

ทำไมการเปรียบเทียบนี้ถึงผิดโดยพื้นฐาน

มนุษย์ต้องการการแบ่งงานเพราะ:

• คนคนหนึ่งมีสมาธิจำกัด ไม่สามารถประมวลผลข้อมูลทั้งหมดพร้อมกันได้
• มนุษย์มีกำแพงทางวิชาชีพและมีต้นทุนการเรียนรู้/การเปลี่ยนงานสูง
• มนุษย์ต้องการอินเทอร์เฟซเพื่อประสานงานระหว่างกัน

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

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

การติดป้าย Agent ว่า "Product Manager" ไม่ได้ทำให้มันมืออาชีพขึ้น—มันทำให้มัน ปฏิเสธที่จะข้ามขอบเขต Agent ที่ถูกจำกัดบทบาทเป็น "Test Engineer" อาจมองข้ามปัญหาทางสถาปัตยกรรมเพราะ "มันไม่อยู่ในขอบเขตของฉัน" การใช้เหตุผลที่มีค่าที่สุดมักเกิดขึ้นที่ขอบเขต และโมเดลแบบแผนกก็ปิดกั้นความเป็นไปได้นี้ในระดับระบบ

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

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

ในโมเดลแบบแผนก Agent A สร้างเอกสารและส่งต่อให้ Agent B

กระบวนการนี้ส่งต่อ ข้อสรุป ไม่ใช่ กระบวนการใช้เหตุผล

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

องค์กรมนุษย์อาศัยการประชุม วัฒนธรรม และการสื่อสารนอกระบบเพื่อชดเชยการสูญเสียนี้ Agent ไม่มีกลไกเหล่านี้

มีข้อโต้แย้งทั่วไป: โซลูชันจากผู้ให้บริการรายใหญ่สามราย (progress.txt, spec files, runbooks) ก็เกี่ยวข้องกับ "การส่งไฟล์" เหมือนกันไม่ใช่หรือ? ต่างกันตรงไหน?

ความแตกต่างอยู่ที่ ใครเป็นคนเขียน มีไว้เพื่อใคร และอัปเดตอย่างไร

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

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

ความแตกต่างนี้กำหนดว่าห่วงโซ่การใช้เหตุผลจะยังคงต่อเนื่องข้ามเซสชันได้หรือไม่

โทเคนจำนวนมหาศาลถูกใช้ไปกับ "ไฟล์ส่งต่อ" ระหว่าง Agent แทนที่จะใช้กับการใช้เหตุผลจริง คุณได้ ระบบที่จำลองพฤติกรรมบริษัท ไม่ใช่ ระบบที่แก้ปัญหา

ผู้ให้บริการรายใหญ่สามรายทำจริงอย่างไร

เป็นที่น่าสังเกตว่า เมื่อ Anthropic, OpenAI และ Google สร้างระบบ Agent ระดับ production เอกสารทางวิศวกรรมของพวกเขาแทบไม่เคยพูดถึง "การสวมบทบาท" หรือ "การแบ่งแผนก"

Anthropic: Context Engineering + ไฟล์สถานะที่ชัดเจน

Anthropic ยกระดับ "Prompt Engineering" เป็น "Context Engineering": คำถามไม่ใช่วิธีเขียน prompt ที่ดี แต่คือ การกำหนดค่าโทเคนแบบไหนที่สร้างพฤติกรรมที่ต้องการได้ดีที่สุด

เมื่อสร้างระบบ Claude Code และ Research ความท้าทายหลักคือ: Agent ต้องทำงานในเซสชันที่ไม่ต่อเนื่อง และแต่ละเซสชันใหม่ไม่มีความทรงจำเกี่ยวกับสิ่งที่เกิดขึ้นก่อนหน้านี้ คำอุปมาของพวกเขาคือ "วิศวกรกะ"—วิศวกรกะใหม่แต่ละคนไม่รู้ว่างานของกะก่อนหน้าทำอะไร

วิธีแก้ไขไม่ใช่การให้ Agent สวมบทบาทต่างกัน แต่คือ:

• claude-progress.txt: บันทึกการทำงานข้ามเซสชันที่ Agent อัปเดตเมื่อสิ้นสุดแต่ละเซสชันและอ่านเมื่อเริ่มเซสชันถัดไป
• Git history: ทำหน้าที่เป็นจุดยึดสถานะ บันทึกการเปลี่ยนแปลงทีละน้อยทุกครั้ง
• Initializer Agent: ทำงานเฉพาะในเซสชันแรกเพื่อตั้งค่าสภาพแวดล้อม ขยายรายการฟีเจอร์ และเขียน runbook สำหรับทุกเซสชันถัดไป

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

พวกเขายังพบว่าการ hard-code "สมมติฐานความสามารถของโมเดล" ลงใน harness เป็นอันตราย Sonnet 4.5 มี "context anxiety"—มันจะสรุปงานก่อนเวลาเมื่อใกล้ถึงขีดจำกัดบริบท ดังนั้นพวกเขาจึงเพิ่มการรีเซ็ตบริบทใน harness แต่ใน Opus 4.5 พฤติกรรมนี้หายไป และการรีเซ็ตกลายเป็นภาระส่วนเกิน นี่แสดงให้เห็นว่า harness ต้องพัฒนาไปพร้อมกับโมเดล "โซลูชันถาวร" ใดๆ ก็เป็นเพียงการประนีประนอมทางวิศวกรรมสำหรับช่วงปัจจุบัน

ในระบบ Research แบบ multi-agent สถาปัตยกรรมของ Anthropic คือ orchestrator-worker: Agent นำหน้าแยกย่อยงานและประสานงาน subagent ซึ่งสำรวจทิศทางต่างๆ แบบขนาน ผลลัพธ์ไหลกลับไปยัง Agent นำหน้าเพื่อสังเคราะห์ พวกเขาพบว่าการใช้โทเคนเพียงอย่างเดียวอธิบายความแตกต่างด้านประสิทธิภาพได้ 80%—คุณค่าของ multi-agent ไม่ใช่ "การแบ่งงาน" แต่คือ การใช้โทเคนมากขึ้นเพื่อครอบคลุมพื้นที่การค้นหาที่ใหญ่ขึ้น

มีจุดที่ทำให้สับสน: subagent ของ Anthropic อาจดูเหมือน "การแบ่งงาน" แต่สาระสำคัญต่างกัน แบบแผนกคือการแบ่งตามหน้าที่—บทบาทต่างกันจัดการงานประเภทต่างกัน (PM ไป Dev ไป QA) subagent ของ Anthropic คือความขนานตามหน้าที่—Agent ที่เหมือนกันหลายตัวค้นหาทิศทางต่างๆ พร้อมกัน ไม่มี "การส่งต่อ" และผลลัพธ์ทั้งหมดกลับมาที่ orchestrator ตัวเดียวกัน อันแรกคือวิ่งผลัด อันหลังคือการทอดแห

OpenAI: Compaction + Skills + ไฟล์ Spec ที่มีโครงสร้าง

หลักการของ OpenAI สำหรับงานระยะยาวนั้นตรงไปตรงมา: วางแผนเพื่อความต่อเนื่องตั้งแต่เริ่มงาน

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

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

Server-side compaction ทำหน้าที่เป็น primitive เริ่มต้น ไม่ใช่ทางเลือกฉุกเฉิน ในงานหลายขั้นตอน previous_response_id ช่วยให้โมเดลทำงานต่อในเธรดเดียวกันแทนที่จะสร้างบริบทใหม่ทุกครั้ง

พวกเขายังแนะนำแนวคิด Skills—ชุดคำสั่งที่ใช้ซ้ำได้และมีเวอร์ชัน ซึ่งติดตั้งใน containers ทำให้ Agent มีมาตรฐานการทำงานที่เสถียรสำหรับงานเฉพาะ สิ่งเหล่านี้ไม่ใช่ "บทบาท" แต่เป็น เครื่องมือและขั้นตอนการทำงาน ซึ่งแตกต่างกันโดยพื้นฐาน

Google: 1M Context + Context-driven Development

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

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

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

หลักการทางสถาปัตยกรรมที่แท้จริงคืออะไร?

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

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

สถานะภายนอกที่ชัดเจน อย่าพึ่งพาความทรงจำของโมเดล ไม่ว่าจะเป็น progress.txt, git history, spec files หรือฐานข้อมูล—รูปแบบไม่สำคัญ หลักการคือ: โหนดสำคัญของห่วงโซ่การใช้เหตุผลต้องถูกทำให้อยู่ภายนอกในพื้นที่จัดเก็บถาวร

คุณค่าของ multi-agent คือการครอบคลุมแบบขนาน ไม่ใช่การแบ่งงาน ข้อสรุปของระบบ Research ของ Anthropic ชัดเจน: ประสิทธิภาพที่เพิ่มขึ้นมาจาก "การใช้โทเคนมากขึ้น" ไม่ใช่จาก "การแบ่งงานที่ดีขึ้น" Multi-agent เหมาะกับงานแบบกว้างก่อน—สถานการณ์ที่ต้องสำรวจทิศทางอิสระพร้อมกัน ไม่เหมาะกับสถานการณ์ที่ต้องใช้เหตุผลต่อเนื่องและพึ่งพาบริบทเชิงลึก

Verifier Agent คือผู้ปฏิเสธ ไม่ใช่นักวิ่งผลัด หากใช้ multi-agent เพื่อควบคุมคุณภาพ การออกแบบที่ถูกต้องคือให้ Agent หนึ่งตัวค้นหาปัญหาในงานของอีกตัวหนึ่งโดยเฉพาะ แทนที่จะ "ส่งต่องาน" การทดสอบแบบ adversarial ไม่ใช่การส่งต่อในสายการผลิต

เครื่องมือคือเครื่องมือ ไม่ใช่บทบาท เครื่องมือที่คุณติดตั้งให้ Agent (bash, file I/O, search, code execution) สำคัญกว่าป้ายที่คุณติดไว้มาก เครื่องมือกำหนดว่า Agent สามารถ ทำอะไรได้ ป้ายบทบาทแค่จำกัดสิ่งที่มัน เต็มใจ จะทำ

ทำไมโมเดล "แบบแผนก" ถึงได้รับความนิยม?

เพราะมัน อธิบายง่าย

"Agent นี้คือ PM ตัวนั้นคือ QA"—ใครๆ ก็เข้าใจ มันตอบสนองความต้องการของมนุษย์ในการอธิบายระบบ AI ได้ และตอบสนองจินตนาการของผู้บริหารที่ว่า "AI ทำงานเหมือนทีม"

มันยัง สาธิตง่าย วาดเป็นผังงานที่มีแผนก ลูกศร และการส่งต่อ ก็เข้าใจได้ง่ายมาก

แต่การอธิบายง่ายและสาธิตง่ายนั้นแตกต่างจากการมีหลักการทางวิศวกรรมที่ดี

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

คำแนะนำเชิงปฏิบัติ

ระบบ multi-agent ที่ดีที่สุดไม่ได้ดูเหมือนบริษัท มันดูเหมือนร่างหลายฉบับของนักคิด—สมองเดียวกันขยายการใช้เหตุผลข้ามมิติต่างๆ และสุดท้ายรวมมันเป็นข้อสรุปที่สอดคล้องกัน

ตามหลักการนี้:

อย่าถาม "ฉันต้องใช้ Agent กี่ตัว?" ให้ถาม "โครงสร้างการพึ่งพาข้อมูลของงานนี้คืออะไร?"

หากงานต้องใช้เหตุผลต่อเนื่องและพึ่งพาบริบทสูง (เช่น การเขียนเอกสารออกแบบสำหรับฟีเจอร์ที่ซับซ้อน) Agent ตัวเดียว + context engineering ที่ดีมักจะเหนือกว่า multi-agent

หากงานต้องสำรวจทิศทางอิสระพร้อมกัน (เช่น การวิจัยคู่แข่ง 10 รายพร้อมกัน) ความขนานแบบ multi-agent สมเหตุสมผล—งานของ subagent แต่ละตัวเป็นอิสระ และต้นทุนของการสูญเสียข้อมูลลดลง

หากงานครอบคลุมหลายเซสชัน ไฟล์สถานะภายนอกเป็นสิ่งจำเป็น ไฟล์สถานะที่มีประสิทธิภาพควรมีข้อมูลสี่ประเภท:

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

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

หากเพิ่มขั้นตอนการตรวจสอบ ให้ภารกิจเดียวของ Verifier Agent คือค้นหาปัญหา ไม่ใช่ "รับไม้ต่อแล้ววิ่งต่อ" การทดสอบแบบ adversarial ไม่ใช่การส่งต่อในสายการผลิต

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

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

เมื่อคุณพบปัญหา สายการผลิตก็ยาวมากแล้ว

อ้างอิง: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)