การวิเคราะห์เชิงลึกสถาปัตยกรรม Claude Code: ทีม MBZUAI เผย 5 ความขัดแย้งและทางออกที่ดีที่สุดในการออกแบบเอเจนต์เขียนโปรแกรม AI

เมื่อเครื่องมือเขียนโปรแกรม AI พัฒนาเป็น Agent ที่สามารถทำงานได้ด้วยตนเอง การเลือกสถาปัตยกรรมพื้นฐานไม่ได้ส่งผลแค่ประสิทธิภาพเท่านั้น แต่ยังเกี่ยวข้องกับความปลอดภัย ความสามารถในการควบคุม และความยั่งยืนในระยะยาวของระบบอีกด้วย ทีมวิจัยจาก MBZUAI VILA Lab ร่วมกับ UCL ได้ทำการวิเคราะห์พื้นที่การออกแบบของ AI Agent ระดับการผลิตอย่างเป็นระบบ โดยใช้ซอร์สโค้ด Claude Code ของ Anthropic เป็นกรณีศึกษา

งานวิจัยใหม่นี้ได้รับความสนใจและการอภิปรายอย่างกว้างขวางบนแพลตฟอร์ม X:

ทีมวิจัยเผยแพร่งานวิจัยนี้เพื่อตอบคำถามหลัก: การสร้าง AI Agent ระดับการผลิต จำเป็นต้องแก้ไขปัญหาการออกแบบที่สำคัญอะไรบ้าง?

Claude Code เป็นตัวแทนทั่วไปของเครื่องมือเขียนโปรแกรม AI ในยุคปัจจุบัน: เพียงพิมพ์ในเทอร์มินัลว่า “ช่วยแก้ไขการทดสอบที่ล้มเหลวใน auth.test.ts” มันจะรวบรวมบริบท วางแผนขั้นตอนการดำเนินการ เรียกใช้เครื่องมือต่างๆ รันคำสั่ง และตรวจสอบผลลัพธ์ โดยทำซ้ำจนกว่างานจะเสร็จสมบูรณ์[7] แม้จะมีบทความมากมายที่ตีความซอร์สโค้ดของมัน แต่ส่วนใหญ่ยังคงอยู่ในระดับเทคนิคของ “วิธีการนำไปใช้”

มุมมองของบทความนี้แตกต่างอย่างสิ้นเชิง:

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

วิธีการวิจัย

การวิเคราะห์ของบทความอิงจากแหล่งข้อมูลหลายประเภท: ซอร์สโค้ด TypeScript ของ Claude Code v2.1.88, บล็อกและเอกสารผลิตภัณฑ์ที่เผยแพร่โดย Anthropic อย่างเป็นทางการ และรายงานการวิเคราะห์วิศวกรรมย้อนกลับจากชุมชน

ข้อสังเกตที่หนึ่ง: ปรัชญาการออกแบบห้าประการหล่อหลอมสถาปัตยกรรม แต่มีความขัดแย้งภายในระหว่างกัน

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

1. อำนาจการตัดสินใจของมนุษย์: มนุษย์ต้องสามารถดู อนุมัติ หรือปฏิเสธการดำเนินการใดๆ ของ Agent ได้ตลอดเวลา
2. ความปลอดภัย ความเป็นส่วนตัว และการปกป้องข้อมูล: แม้ในเวลาที่มนุษย์ไม่มีเวลาดูแล ระบบเองก็ต้องสามารถปกป้องผู้ใช้ โค้ด และข้อมูลได้
3. การดำเนินการที่เชื่อถือได้: พฤติกรรมของ Agent ต้องสอดคล้องกับเจตนาของมนุษย์อย่างสูง และสามารถรักษาทิศทางไม่ให้เบี่ยงเบนระหว่างการทำงานเป็นเวลานาน
4. การขยายขีดความสามารถ: ระบบควรทำให้มนุษย์สามารถบรรลุภารกิจที่ไม่สามารถทำได้ด้วยตนเองมาก่อน
5. การปรับตัวตามบริบท: ระบบต้องสามารถปรับให้เข้ากับโปรเจกต์ เครื่องมือ และนิสัยเฉพาะของผู้ใช้แต่ละคน และปรับปรุงอย่างต่อเนื่องเมื่อเวลาผ่านไป

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

อย่างไรก็ตาม บทความพบว่ามีความขัดแย้งและความขัดแย้งตามธรรมชาติระหว่างปรัชญาการออกแบบเหล่านี้ ตัวอย่างเช่น:

• อำนาจการตัดสินใจของมนุษย์ vs. ความปลอดภัย: จากการวิเคราะห์ของ Anthropic [1] ผู้ใช้อนุมัติป๊อปอัปสิทธิ์ประมาณ 93% การคลิกอนุมัติบ่อยครั้งทำให้ความสนใจของผู้ใช้ต่อเนื้อหาที่ได้รับอนุญาตลดลงอย่างมาก ดังนั้น ความปลอดภัยไม่สามารถพึ่งพาการอนุมัติของมนุษย์เพียงอย่างเดียว ระบบเองต้องมีกลไกป้องกันที่เป็นอิสระ
• ความปลอดภัย vs. ความสามารถ: การตรวจสอบความปลอดภัยที่เข้มงวดทำให้เกิดต้นทุนด้านประสิทธิภาพ หน่วยวิจัยความปลอดภัย Adversa.ai [2] พบว่าเมื่อคำสั่งหนึ่งมีคำสั่งย่อยมากกว่า 50 คำสั่ง หากตรวจสอบกฎการปฏิเสธทีละคำสั่ง จะทำให้อินเทอร์เฟซค้าง ดังนั้น ระบบจึงเลือกที่จะเสียสละการตรวจสอบทีละคำสั่ง โดยถอยไปใช้การอนุมัติทีละคำสั่งเพื่อรักษาความเร็วในการตอบสนอง ซึ่งแสดงให้เห็นว่าภายใต้แรงกดดันด้านประสิทธิภาพ การป้องกันความปลอดภัยหลายชั้นบางครั้งต้องยอมจำนนต่อความสามารถในการใช้งาน
• ความสามารถในการขยาย vs. ความปลอดภัย: ความสามารถในการขยายที่หลากหลายจะขยายพื้นผิวการโจมตี การวิจัยความปลอดภัยของ Check Point Research [3] พบว่า Hooks และส่วนขยาย MCP จะโหลดก่อนที่กล่องโต้ตอบความไว้วางใจจะปรากฏขึ้น ช่องว่างของเวลานี้ถูกใช้ประโยชน์โดยช่องโหว่ด้านความปลอดภัยที่เปิดเผย (CVE-2025-59536, CVE-2026-21852) ยิ่งความสามารถในการขยายมากเท่าไร โค้ดที่โหลดล่วงหน้าก็ยิ่งมากขึ้นเท่านั้น และหน้าต่างที่สามารถถูกโจมตีก็ยิ่งใหญ่ขึ้นเท่านั้น (ช่องโหว่เหล่านี้ได้รับการแก้ไขภายในไม่กี่สัปดาห์หลังจากการเปิดเผย)

ความขัดแย้งเหล่านี้ดูเหมือนจะเป็นสิ่งที่ต้องแลกมาอย่างหลีกเลี่ยงไม่ได้จากการแสวงหาปรัชญาการออกแบบหลายข้อพร้อมกัน มากกว่าที่จะเป็นข้อบกพร่องในการออกแบบเพียงอย่างเดียว การ权衡ที่คล้ายกันนี้อาจเกิดขึ้นในระบบ Agent อื่นๆ เช่นกัน

ข้อสังเกตที่สอง: “นั่งร้านน้อยที่สุด Harness ปฏิบัติการสูงสุด”

△ รูปที่ 1: โครงสร้างระบบระดับสูงของ Claude Code

ระบบประกอบด้วยองค์ประกอบการทำงานเจ็ดส่วน: ผู้ใช้, ชั้นอินเทอร์เฟซ, วงจร Agent, ระบบสิทธิ์, เครื่องมือ, สถานะและการคงอยู่, สภาพแวดล้อมการดำเนินการ

“นั่งร้าน” ที่นี่หมายถึงกรอบการวางแผนที่จำกัดและนำทางการตัดสินใจของโมเดล ในขณะที่ “Harness ปฏิบัติการ” คือโครงสร้างพื้นฐานที่ทำงานรอบโมเดล การวิเคราะห์ซอร์สโค้ดแสดงให้เห็นว่าโค้ดส่วนใหญ่ของ Claude Code เป็นโครงสร้างพื้นฐานที่แน่นอน (การตรวจสอบสิทธิ์, การกำหนดเส้นทางเครื่องมือ, การจัดการบริบท, การกู้คืนข้อผิดพลาด) โดยตรรกะการตัดสินใจของ AI คิดเป็นเพียงประมาณ 1.6% วงจร Agent หลักเป็นกระบวนการวนซ้ำอย่างต่อเนื่อง: เรียกใช้โมเดล, รับคำขอเรียกใช้เครื่องมือ, ดำเนินการ, ส่งคืนผลลัพธ์ จนกว่าโมเดลจะหยุดขอ

ในสาขาวิศวกรรม Agent มีแนวทางการออกแบบที่แตกต่างกัน เฟรมเวิร์กบางตัว (เช่น LangGraph [8]) เข้ารหัสตรรกะการตัดสินใจเป็นแผนภาพสถานะที่ชัดเจน ในขณะที่ Claude Code เลือกเส้นทางอื่น: ไม่ได้กำหนดเส้นทางการตัดสินใจของโมเดลอย่างตายตัว แต่ให้อิสระในการตัดสินใจแก่โมเดลค่อนข้างมาก ในขณะเดียวกันก็ใช้โค้ดที่แน่นอนเพื่อรับประกันการดำเนินการที่ปลอดภัย

การวิเคราะห์ของบทความชี้ให้เห็นว่า เมื่อโมเดล前沿มีความสามารถในการเขียนโค้ดที่ใกล้เคียงกัน คุณภาพของ “Harness ปฏิบัติการ” ที่สร้างรอบโมเดลอาจกลายเป็นปัจจัยสำคัญในการสร้างความแตกต่างของผลิตภัณฑ์

ขั้นตอนการดำเนินการตามคำขอของผู้ใช้

△ รูปที่ 2: กระบวนการวนซ้ำหลายรอบของวงจร Agent

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

ข้างต้นได้กล่าวถึง “เหตุใดจึงออกแบบเช่นนี้” ต่อไปมาดู “วิธีการทำงานเฉพาะ” บทความใช้ “ตัวอย่างการทำงาน” เพื่อเชื่อมโยงสถาปัตยกรรมแต่ละชั้น: สมมติว่าป้อน “ช่วยแก้ไขการทดสอบที่ล้มเหลวใน auth.test.ts” ระบบจะจัดระเบียบบริบทก่อน (โหลดคำสั่งโปรเจกต์ CLAUDE.md, ประวัติการสนทนา, คำจำกัดความของเครื่องมือ, สถานะ git ฯลฯ) จากนั้นดำเนินการไปป์ไลน์การบีบอัดบริบทก่อนเรียกใช้โมเดลในแต่ละรอบ ก่อนเรียกใช้โมเดล ระบบสิทธิ์ได้ลบเครื่องมือที่ถูกห้ามผ่านการกรองล่วงหน้าของเครื่องมือแล้ว โมเดลตัดสินใจว่าจะเรียกใช้เครื่องมือใดภายในขอบเขตของเครื่องมือที่มองเห็นได้ จากนั้นระบบสิทธิ์จะตัดสินอีกครั้งว่าการดำเนินการเฉพาะนั้นได้รับอนุญาตให้ดำเนินการหรือไม่ หลังจากผ่านแล้ว เครื่องมือจะทำงาน ผลลัพธ์จะถูกป้อนกลับไปยังโมเดล เข้าสู่วงจรถัดไป การมอบหมาย Agent ย่อยก็ถูกกระตุ้นผ่านเครื่องมือ Agent ในวงจรนี้เช่นกัน

วงจรนี้เกี่ยวข้องกับประเด็นสถาปัตยกรรมที่สำคัญดังต่อไปนี้:
1. กลไกสิทธิ์

△ รูปที่ 3: โครงสร้างการตัดสินใจของระบบสิทธิ์

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

ระบบออกแบบกลไกความปลอดภัยอิสระเจ็ดชั้น รวมถึงการกรองล่วงหน้าของเครื่องมือ, กฎการปฏิเสธก่อน, โหมดสิทธิ์, ตัวจำแนกประเภท ML (Auto-Mode Classifier), การแยก Sandbox, การไม่สืบทอดสิทธิ์เก่าเมื่อกู้คืนเซสชัน และการสกัดกั้น Hooks ไม่ใช่ทุกการดำเนินการจะกระตุ้นทั้งเจ็ดชั้น ตัวอย่างเช่น ตัวจำแนกประเภท ML จะทำงานเฉพาะเมื่อเปิดโหมดอัตโนมัติ Sandbox ใช้เฉพาะกับคำสั่ง Shell และต้องเปิดใช้งานทั่วโลก การสกัดกั้น Hooks ขึ้นอยู่กับว่าผู้ใช้กำหนดค่า Hook ที่เกี่ยวข้องหรือไม่ แต่ในชั้นที่เกี่ยวข้อง ชั้นใดชั้นหนึ่งสามารถปฏิเสธการดำเนินการได้เพียงลำพัง (อย่างไรก็ตาม บทความชี้ให้เห็นว่าภายใต้แรงกดดันด้านประสิทธิภาพ ชั้นเหล่านี้อาจมีรูปแบบความล้มเหลวร่วมกัน)

2. การจัดการบริบท
เมื่อการสนทนาดำเนินไป เนื้อหาในหน้าต่างบริบทจะขยายตัวขึ้นเรื่อยๆ เพื่อไม่ให้เกินงบประมาณ token ระบบออกแบบการบีบอัดบริบทห้าชั้น: การตัดแต่งงบประมาณ (มีผลเสมอ), การตัดแต่งประวัติ, การบีบอัดแบบไมโคร, การพับบริบท, การสรุปอัตโนมัติ (เปิดใช้งานโดยค่าเริ่มต้น) ในจำนวนนี้ การตัดแต่งประวัติและการพับบริบทถูกควบคุมโดย feature flag และอาจไม่ได้เปิดใช้งานในทุกเวอร์ชัน ห้าชั้นนี้จะถูกประเมินตามลำดับก่อนเรียกใช้โมเดลในแต่ละรอบ แต่ละชั้นจะตัดสินใจอย่างอิสระว่าจำเป็นต้องกระตุ้นหรือไม่ ตั้งแต่การตัดแต่งแบบเบาไปจนถึงการสร้างสรุปโดยโมเดล ความเข้มข้นของการบีบอัดจะเพิ่มขึ้นทีละชั้น

3. ความสามารถในการขยาย

ความสามารถของโมเดลไม่ได้จำกัดอยู่แค่ชุดเครื่องมือในตัว Claude Code มีช่องทางการขยายหลักสี่ช่องทาง: เซิร์ฟเวอร์ MCP สำหรับเชื่อมต่อกับเครื่องมือภายนอกและทรัพยากรข้อมูล; ทักษะ (Skills) สำหรับฉีดคำสั่งการทำงานเฉพาะโดเมน; Hooks ให้จุดสกัดกั้นในหลายระดับ เช่น การเรียกใช้เครื่องมือ, วงจรชีวิตเซสชัน และการจัดการบริบท; ปลั๊กอิน (Plugin) เป็นรูปแบบการบรรจุและแจกจ่ายที่สามารถรวมกลไกข้างต้น รวมถึงคำสั่ง, คำจำกัดความของ Agent และส่วนประกอบอื่นๆ เข้าเป็นแพ็คเกจส่วนขยายที่ติดตั้งได้ กลไกการขยายที่แตกต่างกันใช้ทรัพยากรหน้าต่างบริบทในระดับที่แตกต่างกัน นักพัฒนาสามารถเลือกวิธีการขยายที่เหมาะสมที่สุดตามสถานการณ์เฉพาะ

4. การมอบหมายและการจัดเรียง Agent ย่อย

โมเดลสามารถส่ง Agent ย่อย (Subagent) เพื่อดำเนินงานย่อยผ่านการเรียกใช้เครื่องมือ Agent ระบบมีประเภท Agent ย่อยที่กำหนดไว้ล่วงหน้าหลายประเภท (เช่น Explore ที่เน้นการสำรวจ และ Plan ที่เน้นการวางแผน) และยังรองรับการกำหนดเองโดยผู้ใช้ โดยค่าเริ่มต้น Agent ย่อยจะทำงานในหน้าต่างบริบทที่เป็นอิสระ โหมดการแยกของมันรวมถึงการแยกภายในกระบวนการ (โหมดเริ่มต้น ใช้ระบบไฟล์ร่วมกันแต่บริบทเป็นอิสระ) และการแยก git worktree (มีสำเนาระบบไฟล์ของตัวเอง) เมื่องานเสร็จสมบูรณ์ Agent ย่อยจะส่งคืนเฉพาะผลลัพธ์สุดท้ายให้กับ Agent หลัก ในสถานการณ์ agent teams ระบบใช้กลไกการล็อกไฟล์เพื่อประสานงานการจัดสรรงานระหว่าง Agent หลายตัว

ข้อสังเกตที่สาม: การเปรียบเทียบกับ OpenClaw: ความท้าทายในการออกแบบเดียวกัน วิธีแก้ปัญหาที่แตกต่างกัน

บทความนี้ไม่เพียงเจาะลึก Claude Code เท่านั้น แต่ยังเปรียบเทียบในแนวนอนหกมิติกับระบบ Agent ที่ได้รับความนิยมอย่างรวดเร็วในชุมชนโอเพนซอร์สอย่าง OpenClaw [6] OpenClaw เป็นเกตเวย์ผู้ช่วยส่วนตัวที่รองรับการเชื่อมต่อหลายแพลตฟอร์ม เช่น WhatsApp, Telegram, Slack เมื่อเผชิญกับปัญหาการออกแบบเดียวกัน ทั้งสองระบบให้คำตอบที่แตกต่างกันอย่างสิ้นเชิง:

• Claude Code ประเมินความปลอดภัยทีละการดำเนินการสำหรับการเรียกใช้เครื่องมือแต่ละครั้ง ในขณะที่ OpenClaw ใช้การควบคุมการเข้าถึงระดับขอบเขต
• วงจร Agent ของ Claude Code เป็นศูนย์กลางหลักของระบบ ในขณะที่วงจร Agent ของ OpenClaw เป็นเพียงส่วนประกอบหนึ่งในเกตเวย์
• กลไกการขยายของ Claude Code แก้ไขหน้าต่างบริบทเดียว ในขณะที่ปลั๊กอินของ OpenClaw ขยายขอบเขตความสามารถของเกตเวย์ทั้งหมด
• ทั้งสองสามารถใช้ร่วมกันได้: OpenClaw สามารถเชื่อมต่อ Claude Code เป็น Harness การเขียนโปรแกรมภายนอกผ่าน ACP (Agent Client Protocol) ซึ่งแสดงให้เห็นว่าพื้นที่การออกแบบของ Agent ไม่ใช่แค่การเลือกอย่างใดอย่างหนึ่ง แต่เป็นโครงสร้างที่สามารถประกอบเป็นชั้นๆ ได้ โดยระบบระดับเกตเวย์และ Harness ระดับงานสามารถซ้อนทับกันได้

ข้อสังเกตที่สี่: ผลกระทบที่อาจเกิดขึ้นต่อประสิทธิภาพการทำงานระยะยาวและคุณภาพโค้ด

นอกเหนือจากการวิเคราะห์ในระดับสถาปัตยกรรมแล้ว บทความยังตรวจสอบระบบ Agent จากอีกมุมมองหนึ่ง: การเพิ่มประสิทธิภาพการทำงานที่ AI Agent นำมานั้นเป็นจริงอย่างที่ผู้คนรับรู้หรือไม่? มันจะนำมาซึ่งต้นทุนแฝงในด้านคุณภาพโค้ดและการบำรุงรักษาในระยะยาวหรือไม่?

ในส่วนของการอภิปราย บทความอ้างอิงผลการศึกษาหลายชิ้นที่มุ่งเป้าไปที่เครื่องมือเขียนโปรแกรม AI ที่คล้ายคลึงกัน:

• การทดลองแบบสุ่มที่มีกลุ่มควบคุม [4] กับนักพัฒนาที่มีประสบการณ์ 16 คน เกี่ยวข้องกับ 246 งาน พบว่ากลุ่มที่ใช้เครื่องมือ AI ทำงานเสร็จช้าลง 19% แต่พวกเขารู้สึกว่าตัวเองเร็วขึ้น 20%
• การวิเคราะห์เชิงสาเหตุ [5] ของคลังโค้ด 807 แห่ง แสดงให้เห็นว่าหลังจากใช้ Cursor ความซับซ้อนของโค้ดเพิ่มขึ้น 40.7%

บทความชี้ให้เห็นว่าระบบ Agent ในอนาคตสามารถรวม “ช่องว่างความยั่งยืน” นี้เข้าไปในการพิจารณาการออกแบบระบบ แทนที่จะเป็นเพียงตัวชี้วัดการประเมินภายหลัง

ทิศทางในอนาคตที่เปิดกว้างหกประการ

บทความสรุปทิศทางการวิจัยที่ต้องสำรวจเพิ่มเติมอีกหกประการ:

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

2. การคงอยู่ของความทรงจำและการทำงานร่วมกันระยะยาวระหว่างมนุษย์กับ Agent: จะทำให้ความสัมพันธ์ในการทำงานระหว่าง Agent และผู้ใช้สะสมอย่างมีประสิทธิภาพและมั่นคงในการสนทนาหลายครั้งได้อย่างไร?

3. วิวัฒนาการของขอบเขต Harness: สี่มิติของ Agent ที่ทำงานที่ไหน, เมื่อไหร่ที่ลงมือ, ดำเนินการกับวัตถุอะไร, และร่วมมือกับใคร กำลังขยายตัวอย่างรวดเร็ว

4. การขยายช่วงเวลา: Agent สามารถขยายจากระดับการสนทนาครั้งเดียวไปสู่งานระดับการวิจัยที่กินเวลาหลายวันหรือหลายสัปดาห์ได้หรือไม่?

5. การกำกับดูแลและการควบคุม: เมื่อกฎหมาย เช่น EU AI Act มีผลบังคับใช้ สถาปัตยกรรม Agent ต้องจัดเตรียมอินเทอร์เฟซการตรวจสอบและความโปร่งใสอะไรบ้าง?

6. ผลกระทบต่อความสามารถระยะยาวของมนุษย์: ปัญหาความยั่งยืนข้างต้นสามารถยกระดับจากตัวชี้วัดการประเมินภายหลังเป็นเป้าหมายการออกแบบระบบได้หรือไม่?

ข้อคิดสำหรับนักพัฒนาและนักวิจัย AI

ประการแรก บทความนำเสนอมุมมองการวิเคราะห์สถาปัตยกรรม Agent จากปรัชญาการออกแบบ โดย追溯ตัวเลือกการนำไปใช้เฉพาะกลับไปยังแนวคิดและหลักการออกแบบเบื้องหลัง แทนที่จะ停留在ระดับ “วิธีการนำไปใช้”

ประการที่สอง บทความแสดงให้เห็นถึงการ权衡ระหว่างคุณค่าหลายประการในการออกแบบ Agent: ความปลอดภัยกับประสิทธิภาพ การควบคุมของมนุษย์กับระบบอัตโนมัติ ความสามารถในการขยายกับความปลอดภัยมักมีการแลกเปลี่ยนกัน การทำความเข้าใจการ权衡เหล่านี้ช่วยในการตัดสินใจทางสถาปัตยกรรมที่ชาญฉลาดยิ่งขึ้น

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

ประการที่สี่ บทความยังให้ความสนใจกับปัญหานอกเหนือจากเทคโนโลยี: การเพิ่มประสิทธิภาพในระยะสั้นที่ Agent นำมานั้นเป็นจริงหรือไม่? มันจะต้องแลกมาด้วยต้นทุนในด้านคุณภาพโค้ดและการบำรุงรักษาในระยะยาวหรือไม่?

คำส่งท้าย

AI Agent ยังคงอยู่ในระหว่างการวิวัฒนาการอย่างรวดเร็ว บทความนี้ใช้ Claude Code เป็นจุดเริ่มต้น โดยมีจุดมุ่งหมายเพื่อให้ข้อสังเกตบางประการที่สามารถอ้างอิงได้สำหรับการอภิปรายการออกแบบสถาปัตยกรรม Agent

โค้ดและบทความฉบับสมบูรณ์เป็นโอเพนซอร์ส ยินดีต้อนรับ!

หน้าโปรเจกต์ GitHub: https://github.com/VILA-Lab/Dive-into-Claude-Code
ดาวน์โหลดบทความ: https://arxiv.org/abs/2604.14228
โค้ดและข้อมูล: https://github.com/VILA-Lab/Dive-into-Claude-Code

เอกสารอ้างอิง

[1] Anthropic. Claude Code Auto Mode: A Safer Way to Skip Permissions. https://www.anthropic.com/engineering/claude-code-auto-mode
[2] Adversa.ai. Critical Claude Code Vulnerability: Deny Rules Silently Bypassed Because Security Checks Cost Too Many Tokens. https://adversa.ai/blog/claude-code-security-bypass-deny-rules-disabled/
[3] Donenfeld, A. & Vanunu, O. Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files. Check Point Research. https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/
[4] Becker, J. et al. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. https://arxiv.org/abs/2507.09089
[5] He, H. et al. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. arXiv:2511.04427. https://arxiv.org/abs/2511.04427
[6] Steinberger, P. & OpenClaw Contributors. OpenClaw: Personal AI Assistant. https://github.com/openclaw/openclaw
[7] Anthropic. How Claude Code Works. https://code.claude.com/docs/en/how-claude-code-works
[8] LangChain, Inc. LangGraph: Build Resilient Language Agents as Graphs. https://github.com/langchain-ai/langgraph