AI agent ที่นำไปใช้งานจริงในระดับโปรดักชันมักไม่ได้พังเพราะตัวโมเดลไม่ฉลาด แต่พังเพราะสถาปัตยกรรมบวมจากการสะสมฟีเจอร์แบบปะผุ มี tool ใหม่เพิ่มทุกสัปดาห์ เสริม subagent ใหม่ทุกเดือน และยัดนโยบายลงใน system prompt จนยาวเหยียด ท้ายที่สุดระบบก็พังลงพร้อมกัน Will จากทีม Applied AI ของ Anthropic นำเคส inventory agent ชื่อ Stock Pilot มาแชร์ในงาน Code with Claude London โดยระบบเดิมมี system prompt ยาวถึง 400 บรรทัด มี 12 tools และ 3 subagents ส่งผลให้ eval score ร่วงลงเหลือ 62% ทั้งที่ช่วงแรกเคยทำงานได้เสถียร

ในงาน Code with Claude London ทีม Anthropic นำเสนอกรอบการตัดสินใจ (Decision Framework) ที่ใช้งานจริง เพื่อชี้ชัดว่าสถานการณ์ไหนควรใช้ tool เมื่อไหร่ควรเลือก skill และจังหวะไหนจึงจำเป็นต้องใช้ subagent พร้อมทั้งสาธิตการ refactor ระบบที่บวมเกินไปด้วยแนวทาง Hill climbing on evals จนดึงคะแนน eval กลับขึ้นมาแตะ 92% ขณะที่ token usage และ latency ลดลงอย่างเห็นได้ชัด บทความนี้สรุปแก่นสำคัญและวิธีคิด เพื่อให้นักพัฒนาที่กำลังสร้าง AI agent นำไปปรับใช้กับระบบจริงได้ทันที

1. ปัญหาของ agent ที่โตเกินไป: ถอดบทเรียนจาก Stock Pilot

Stock Pilot คือ inventory management agent ที่สร้างขึ้นสำหรับธุรกิจค้าปลีกขนาดกลาง รับผิดชอบงานหลายด้านพร้อมกัน ตั้งแต่ตรวจจับสต็อกระดับต่ำ คาดการณ์ดีมานด์ คัดเลือกซัพพลายเออร์ ออกใบสั่งซื้อ (PO) ไปจนถึงเขียนสรุปรายงานประจำสัปดาห์ ในความเป็นจริงความสามารถแต่ละส่วนไม่ได้ซับซ้อน แต่ปัญหาร้ายแรงเกิดจากการ bolt-on ฟังก์ชันใหม่เข้าไปเรื่อยๆ โดยไม่มีการจัดระเบียบสถาปัตยกรรมใหม่เลย

โครงสร้างเดิมของ Stock Pilot วาง orchestrator ไว้ด้านบน คุม system prompt ยาว 400 บรรทัด และเรียกใช้ 12 tools ซึ่งในจำนวนนี้มี 3 tools ที่เป็น wrapper ครอบ subagent แยก context window อีกชั้น เมื่อต้องเพิ่มฟังก์ชัน forecasting ทีมก็แปะ subagent ใหม่ พอจะเพิ่มงานเขียนรีพอร์ต ก็สร้างอีก subagent ด้านกฎระเบียบและ business logic ของคลังสินค้า ทีมก็ใช้วิธี append ต่อท้าย system prompt ไปเรื่อยๆ จนสะสมถึง 400 บรรทัด

Will อธิบายว่าแพทเทิร์นนี้เกิดขึ้นบ่อยมาก ทั้งในโปรเจกต์ของลูกค้าและทีมงานภายในของ Anthropic เอง สัญญาณเตือนอันดับแรกคือ regression ในจุดที่ agent เคยทำได้ดี ผลการรัน eval รอบใหม่ของ Stock Pilot ได้คะแนนเพียง 62% ผ่านแค่ 7 จาก 12 tasks ตกจากเดิมที่เคยทำได้ราว 83% ซึ่งความผิดพลาดระดับ 17% ในงานสายการผลิตและสินค้าคงคลังถือเป็นความเสียหายที่มีต้นทุนสูงเกินยอมรับได้

2. วางโครงสร้าง Eval: วัดผลด้วย 12 Tasks และ 5 Graders

ก่อนเริ่มลงมือ refactor ทีม Anthropic เริ่มต้นจากการตั้ง baseline ด้วยชุด eval ที่รัดกุมเสมอ Stock Pilot กำหนดโจทย์ทดสอบไว้ 12 tasks แบ่งเป็นสองกลุ่มหลัก กลุ่มแรกคือ Eval ID ที่ขึ้นต้นด้วย R (Regression tasks) เป็น single-turn จำลองสถานการณ์จริง และกลุ่มที่สองคือ Eval ID ที่ขึ้นต้นด้วย F (Failure modes) ซึ่งเป็น multi-turn tasks ที่มีความซับซ้อนสูง

ระบบประเมินผลใช้ grader ทั้งหมด 5 ประเภท แบ่งออกเป็นสองฝั่งอย่างสมดุล:

• Deterministic grader: ตรวจวัดค่าที่นับได้ชัดเจนทางสถิติ ได้แก่ จำนวน token ที่ใช้งาน เวลาในการตอบสนอง (latency) และจำนวน turn ตลอดทั้ง task
• Non-deterministic grader: ใช้แนวคิด LLM-as-a-judge ประเมินมิติเชิงคุณภาพที่ตัวเลขวัดไม่ได้ตรงๆ เช่น ความเหมาะสมของน้ำเสียง (tone and style) บุคลิก และคุณภาพของคำตอบ

Will ย้ำว่า eval ไม่ใช่การสอบไล่ที่ตรวจครั้งเดียวจบ แต่คือเครื่องมือสำหรับการทำ hill climb กล่าวคือรัน baseline เพื่อดูจุดบกพร่อง ปรับ architecture รันซ้ำเพื่อเช็กตัวเลข แล้วปรับแต่งต่อ การเริ่มต้นจาก eval ทำให้ทุกการตัดสินใจ refactor มีข้อมูลเชิงประจักษ์รองรับเสมอ ไม่ได้พึ่งพาเพียงความรู้สึก

3. เจาะลึก Failure Modes: F1, F2, R8 พังเพราะอะไร

การวิเคราะห์ failure modes สามตัวหลักทำให้เห็นปัญหาคนละมิติ ซึ่งเป็นโจทย์ตั้งต้นในการเลือก primitives ให้ถูกต้องในขั้นตอนถัดไป

F1: Daily low-stock sweep (ปัญหาด้าน Efficiency)

F1 จำลองการกวาดสแกน inventory ทั้งหมดเพื่อหาสินค้าที่สต็อกใกล้หมด ซึ่งเป็นฟังก์ชันพื้นฐานที่สุด Task นี้ fail ไม่ใช่เพราะ agent สรุปผลผิด แต่เป็นเพราะ agent เลือกเส้นทางทำงานแบบ winding path คือไปถึงคำตอบที่ถูกต้องด้วยขั้นตอนที่เยิ่นเย้อ Deterministic grader จึงตัดคะแนนเนื่องจาก token และ latency พุ่งสูงเกินเกณฑ์

F2: Ordering ภายใต้โปรโมชัน (ปัญหา Communication breakdown ระหว่าง Subagent กับ Orchestrator)

F2 ทดสอบขั้นตอนการสั่งซื้อสินค้าระหว่างจัดแคมเปญโปรโมชันพิเศษ Will ชี้ว่า subagent ที่รับผิดชอบทำงานในส่วนของตัวเองได้ถูกต้องสมบูรณ์ แต่ข้อผิดพลาดเกิดขึ้นตอนส่งต่อข้อมูลระหว่าง subagent กลับไปยัง orchestrator เนื้อหาถูกย่อยหรือแปลความหมายคลาดเคลื่อนระหว่างทาง จุดนี้เป็น failure point ที่พบบ่อยมากในระบบที่มี subagent หลายตัว หาก communication contract ไม่รัดกุมพอ ข้อมูลสำคัญจะหล่นหายทันที

R8: Forecasting ช่วงเดือนโปรโมชัน (Context problem ไม่ใช่ Model problem)

R8 เป็นบทเรียนที่น่าสนใจที่สุด โดย task นี้ให้ agent คำนวณยอด forecast ในเดือนที่มีแคมเปญส่งเสริมการขาย ผลจากการจำลอง terminal แสดงให้เห็นว่า agent ดึงข้อมูล forecasting baseline ถูกต้อง (12 units/day) และดึงค่า promotion multiplier ถูกต้อง (3.1x) แต่พอถึงขั้นตอนคำนวณจริง โมเดลกลับนำตัวเลข 1.35 เข้ามาคูณแทน ทั้งที่ตัวเลขนี้ไม่มีอยู่ในชุดข้อมูลตั้งต้น

Will ย้ำจุดนี้ชัดเจนว่า "นี่ไม่ใช่ปัญหาของโมเดล แต่เป็นปัญหาของ Context" (This isn't a model problem. It's a context problem) สาเหตุเกิดจาก system prompt 400 บรรทัดมี policy สองข้อวางอยู่คนละจุดและขัดแย้งกันเอง เมื่อเจอคำสั่งที่ตีกัน โมเดลจึงสับสนจน hallucinate ตัวเลขใหม่ขึ้นมา การอัดความรู้และกฎระเบียบทั้งหมดลงใน system prompt ไม่ได้ช่วยให้โมเดลทำงานดีขึ้น แต่กลับกลายเป็นการวางกับดักให้โมเดลสับสนตัวเอง

4. Decision Framework: เมื่อไหร่ควรใช้ Tool, Skill หรือ Subagent

นี่คือหัวใจสำคัญของการออกแบบ agent โดย Will สรุปเป็นกรอบความคิด 3 เสาหลักสำหรับการเลือก primitives ให้เหมาะสม พร้อมชี้ anti-patterns ที่ต้องระวัง

4.1 Tool: ลำดับการเลือกที่ทีม Anthropic ใช้งานจริง

ทีม Anthropic ยึดหลักคิดร่วมกันว่า ต้องเริ่มจาก Humanlike primitives เสมอ ซึ่งก็คือเครื่องมือพื้นฐานที่มนุษย์ใช้ทำงานหน้าคอมพิวเตอร์ ได้แก่ การเปิดอ่านเขียนไฟล์ใน file system การเปิดเว็บเบราว์เซอร์ การค้นหาข้อมูลบนอินเทอร์เน็ต การเขียนและรันโค้ด ตลอดจนการจดโน้ต to-do list ตัวอย่างเช่น Claude Code ทำงานได้อย่างยอดเยี่ยมไม่ได้เป็นเพราะมีเครื่องมือวิเศษ แต่เป็นเพราะเข้าถึง primitives พื้นฐานเหล่านี้ได้อย่างเป็นธรรมชาติเหมือนมนุษย์

ตัวอย่างเช่นงานวิเคราะห์เอกสาร ซึ่งนักพัฒนามักชอบสร้าง custom tool เฉพาะทางขึ้นมา Will ชี้ว่าหากต้องวิเคราะห์ไฟล์ CSV หรือ Excel หลายชุด การมอบ bash tool แล้วปล่อยให้โมเดลเขียนสคริปต์ Python สั้นๆ มารันประมวลผล จะมีประสิทธิภาพเหนือกว่าการยัดเนื้อหา CSV ทั้งก้อนลงใน context window อย่างมหาศาล เพราะช่วยประหยัด token ได้มาก และปล่อยให้สมองของโมเดลโฟกัสกับการตัดสินใจเชิงตรรกะ แทนที่จะต้องจดจำข้อมูลทุกตารางแถว

ลำดับการพิจารณาเลือก Tool ตามมาตรฐาน Anthropic:

1. เริ่มจาก Primitives พื้นฐานของ Claude Code เป็นอันดับแรก: ได้แก่ bash code execution, file system, web search และ to-do list ซึ่งใน Claude Managed Agents (CMA) มีสิ่งเหล่านี้ให้พร้อมใช้งานเป็นค่าเริ่มต้น
2. เพิ่ม Custom local tools เฉพาะเมื่อ Primitives จัดการไม่ได้จริงๆ: เช่น tool สำหรับเชื่อมต่อ API ภายในองค์กรที่ปลอดภัยและไม่สามารถเรียกผ่าน bash ได้โดยตรง
3. ใช้ MCP เป็นทางเลือกสุดท้าย ไม่ใช่ทางเลือกแรก: นำมาใช้เฉพาะกรณีที่ต้องการแชร์ tool ร่วมกันระหว่างหลายไคลเอนต์หรือหลายเอเจนต์ และต้องการ governance จากศูนย์กลาง

ลูกค้าจำนวนมากเลือกกระโดดไปหา MCP ตั้งแต่เริ่มต้น จนลงเอยด้วยการมี MCP servers หลายตัวที่ทับซ้อนกันและสร้าง context pollution เนื่องจาก MCP กินพื้นที่ใน context window พอสมควร หลายกรณีการรันสคริปต์ผ่าน CLI หรือเรียก API ตรงผ่านโค้ดจึงให้ความยืดหยุ่นและเบากว่ามาก

Anti-pattern ที่พบบ่อย: สร้าง custom tool ใหม่ทุกครั้งที่ต้องการฟีเจอร์เพิ่ม ทั้งที่งานเหล่านั้น Claude จัดการผ่าน bash และ code execution ได้อยู่แล้ว ผลลัพธ์คือรายการ tool ยาวเป็นหางว่าว จนโมเดลสับสนว่าจะหยิบเครื่องมือชิ้นไหนมาใช้

4.2 Skill: ปฏิบัติตามหลัก Progressive Disclosure

ทีม Anthropic นิยาม Skill ว่าเป็น ข้อมูลแบบแพ็กเกจที่ประกอบรวมกันได้ (Packaged composable information) ซึ่ง Claude จะดึงเข้ามาใน Context เฉพาะตอนที่ต้องใช้งานจริงเท่านั้น ไม่ใช่ข้อมูลที่ต้องจำค้างไว้ในสมองตลอดเวลา หลักการนี้เรียกว่า Progressive disclosure

ความแตกต่างระหว่าง System Prompt กับ Skill มีกฎเกณฑ์ชัดเจน:

• System Prompt: ใส่เฉพาะข้อมูลที่ Claude จำเป็นต้องรู้ใน ทุกๆ Task ที่ได้รับมอบหมาย
• Skill: ใส่ข้อมูลที่ Claude จะต้องใช้ใน บางสถานการณ์เท่านั้น

ตัวอย่างเช่น แนวทางการคำนวณ forecasting ไม่จำเป็นต้องฝังใน system prompt เพราะ Claude ไม่ได้ทำ forecast ทุกครั้ง แต่เมื่อได้รับโจทย์ forecast ตัวโมเดลจะรับรู้และดึง skill นั้นเข้ามาประมวลผลเอง

ในเคสของ Stock Pilot ทีมงานย้าย business logic จำนวนมากออกจาก system prompt เดิม แล้วจัดระเบียบเป็น skill แยกไว้ ผลลัพธ์คือ system prompt ลดความยาวจาก 400 บรรทัดเหลือเพียง 15 บรรทัด context window ไม่ต้องแบกรับ policy ที่ไม่เกี่ยวข้อง ส่งผลให้โจทย์ R8 ที่เคยเฟลเพราะกฎสองข้อตีกัน ได้รับการแก้ไขจนทำงานได้ถูกต้องทันที

Anti-pattern ที่พบบ่อย: เมื่อมี requirement ใหม่จากทีมธุรกิจ ก็ใช้วิธีพิมพ์ต่อท้าย system prompt ไปเรื่อยๆ ซึ่งเป็นการสะสมหนี้ทางเทคนิคอย่างเงียบๆ จนวันหนึ่งโมเดลทำงานช้าลงและหลอน แต่หาต้นตอไม่เจอ

4.3 Subagent: สงวนไว้สำหรับการ Parallelize หรือการตรวจแบบ Fresh-mind

Will แนะนำว่าจังหวะที่เหมาะสมสำหรับการแยก Subagent มีเพียงสองกรณีหลักเท่านั้น:

1. ต้องการระดมสมองหลาย instance เข้าแก้ปัญหาเดียวกัน (Throw a lot of Claude at it): เช่น งาน deep research ค้นหาข้อมูลจากหลายแหล่งพร้อมกัน หรือการสำรวจโครงสร้างโค้ดเบสขนาดใหญ่ ซึ่งการเปิด Claude หลาย instance ทำงานขนานกันจะช่วยเพิ่มความครอบคลุมและความเร็ว
2. ต้องการมุมมองที่สดใหม่มารีวิวงาน (Fresh mind review): เปรียบเสมือนนักพัฒนาที่ไม่อยากเป็นทั้งคนเขียนโค้ดและคนตรวจโค้ดตัวเองในเวลาเดียวกัน การให้ Claude ตัวหนึ่งเขียนโค้ด แล้วส่งต่อให้อีกตัวที่ไม่มี context เริ่มต้นมาช่วยรีวิว จะได้ผลลัพธ์ที่รอบคอบและเป็นกลางกว่ามาก

ในเคส Stock Pilot ทีมตัดสินใจตัด subagent เดิมออกเกือบหมด เหลือไว้เพียง forecasting subagent เพียงตัวเดียว เพื่อแยกบริบทการคำนวณตัวเลขทางสถิติออกจากบริบทการคุยกับลูกค้า ไม่ให้ความต้องการฝั่งลูกค้ารบกวนการประมวลผล ส่วน subagent อื่นๆ ถูกแทนที่ด้วย primitives tools และ skill ทั้งหมด

นอกจากนี้ Claude Managed Agents ยังมีฟีเจอร์ Callable agents แบบ native ต่างจากการห่อ subagent ไว้ในรูป tool ทั่วไป เพราะ callable agents ช่วยให้การเก็บ log และ observability ทำได้ครบถ้วนภายใน session เดียว ช่วยแก้ปัญหา communication breakdown ระหว่าง orchestrator กับ subagent ได้อย่างมีประสิทธิภาพ

Anti-pattern ที่พบบ่อย: แตก subagent ทันทีที่งานเริ่มมีความซับซ้อน ทั้งที่โมเดลเรือธงในปัจจุบันบริหาร context ขนาดใหญ่ได้ดีมาก ปัจจุบันหลายทีมเริ่มรวบ subagent กลับเข้าสู่ main agent ตัวเดียว เพราะโมเดลสามารถคิดเชิงเหตุผลข้ามบริบทได้โดยตรง ช่วยตัดปัญหา overhead และข้อผิดพลาดจากการสื่อสารข้ามเอเจนต์

5. ขั้นตอนการ Refactor: เดินหน้าแบบ Hill Climbing ด้วย Eval

หลังวางกรอบ primitive ชัดเจน ทีมงานเริ่มลงมือปรับโครงสร้าง Stock Pilot ทีละสเต็ป โดยมีชุด eval คอยตรวจวัดผลลัพธ์ในทุกก้าว เพื่อให้มั่นใจว่าการปรับปรุงส่งผลเชิงบวกต่อเมทริกซ์จริง โดยทีมเลือกใช้ Claude Code ที่ทำงานบน Opus 4.7 ตั้งค่า effort level ระดับ extra high มาช่วย refactor และวิเคราะห์ผล eval

ขั้นที่ 1: ย้ายจาก Messages API สู่ Claude Managed Agents

Stock Pilot เวอร์ชันแรกพัฒนาบน Messages API โดยตรง ทำให้ทีมต้องดูแล agent harness, การขยายระบบ, ความปลอดภัย ตลอดจน memory ด้วยตัวเอง การย้ายมาใช้ Claude Managed Agents ช่วยปลดภาระด้านโครงสร้างพื้นฐานเหล่านี้ออกไป เพื่อให้โฟกัสกับการออกแบบสถาปัตยกรรมได้อย่างเต็มที่

ขั้นที่ 2: รีด System Prompt จาก 400 บรรทัดเหลือ 15 บรรทัดด้วย Skill

ทีมใช้ Claude ช่วยวิเคราะห์เนื้อหาใน system prompt เดิม เพื่อระบุว่าส่วนใดเป็น "กฎเฉพาะกิจสำหรับบางงาน" แล้วแยกออกไปสร้างเป็น skill คงเหลือไว้ใน system prompt เฉพาะแก่นสำคัญ เช่น อัตลักษณ์ของระบบและข้อกำหนดความปลอดภัยพื้นฐาน

ขั้นที่ 3: ลด 12 Tools เหลือ 3 Tools พื้นฐานด้วย Code Execution

ตัด custom tools ออกเกือบทั้งหมด แล้วแทนที่ด้วยชุดเครื่องมือมาตรฐาน bash, read และ write เมื่อเริ่มงาน ระบบจะ sync ข้อมูลเข้าสู่สภาพแวดล้อมของ CMA แล้วเปิดให้ Claude เขียนสคริปต์ Python เพื่อวิเคราะห์ข้อมูลด้วยตัวเอง ผลการทดสอบพบว่า token usage ลดฮวบจากระดับ 200,000+ ค่าใช้จ่ายและ latency ลดลงตามไปด้วย เพราะโมเดลไม่จำเป็นต้องอ่าน CSV ทั้งไฟล์เข้าสู่ context แต่เขียนโค้ดไปกรองเฉพาะข้อมูลที่ต้องการ

ขั้นที่ 4: คง Subagent ไว้เฉพาะงาน Forecast และปรับเป็น CMA Callable Agents

ตัด subagents เดิมออก 2 ตัวเนื่องจากใช้ tool และ skill ทดแทนได้แล้ว เหลือไว้เพียง forecasting subagent ตัวเดียว พร้อมเปลี่ยนการเชื่อมต่อเป็น CMA native callable agents เพื่อขจัดปัญหาข้อมูลตกหล่นตอนสื่อสาร

6. สรุปผลลัพธ์: ดึง Eval ขึ้นจาก 62% สู่ 92% พร้อมโครงสร้างที่คล่องตัว

หลังจากปรับปรุงครบทั้ง 4 ขั้นตอน ผลลัพธ์เชิงตัวเลขของ Stock Pilot เปลี่ยนแปลงอย่างเห็นได้ชัด:

• System prompt: ลดลงจาก 400 บรรทัด เหลือ 15 บรรทัด
• Tools: ลดลงจาก 12 ตัว เหลือ 3 ตัว (bash, read, write)
• Subagents: ลดลงจาก 3 ตัว เหลือ 1 ตัว (forecasting) ทำงานบน CMA callable agents
• Eval score: เพิ่มขึ้นจาก 62% เป็น 92%
• Token usage: ลดลงอย่างมีนัยสำคัญ จากเดิมที่เกิน 200,000 tokens
• Cost: ประหยัดค่าใช้จ่ายลงตามปริมาณ token
• Latency: ตอบสนองได้รวดเร็วขึ้น แม้จำนวน turn จะใกล้เคียงเดิม

ประโยชน์สำคัญอีกข้อคือ เมื่อสถาปัตยกรรมตั้งอยู่บน primitives พื้นฐานที่มั่นคง ทีมงานจะสามารถ "Drop in better Claude" ได้ทันทีที่โมเดลเวอร์ชันใหม่ออกสู่ตลาด โดยไม่ต้องรื้อเขียน tool หรือจัดโครงสร้าง agent ใหม่ทั้งหมด เปรียบเหมือนคนที่โต๊ะทำงานและเครื่องมือยังคงเดิม แต่สมองได้รับการอัปเกรดให้ฉลาดและคิดไวขึ้น

7. บทเรียนสำคัญสำหรับนักพัฒนา AI Agent

Will ฝากข้อคิดหลัก 3 ประการสำหรับผู้ที่กำลังออกแบบระบบ agent:

1. เริ่มต้นจาก Single loop พร้อม Simple primitives เสมอ: ยึดเครื่องมือพื้นฐานอย่าง file system, code execution, web search และ to-do list มอง agent เหมือนเพื่อนร่วมงานหนึ่งคนที่นั่งทำงานหน้าคอมพิวเตอร์ ก่อนจะสร้าง custom tool เพิ่ม ต้องตอบให้ชัดเจนว่า primitives เดิมทำไม่ได้จริงๆ หรือไม่
2. ใช้ Progressive disclosure ผ่าน Skill: หลีกเลี่ยงการยัดข้อมูลทุกอย่างลงใน system prompt หากข้อมูลนั้นไม่ได้ใช้ในทุก task ควรแยกออกไปเป็น skill เพื่อลดปริมาณ token และตัดปัญหาเรื่อง policy ขัดแย้งกันเอง
3. ทำ Hill climb ด้วยชุด Eval ที่วัดผลจริง: ทุกครั้งที่เพิ่มความสามารถใหม่ ต้องตรวจวัดด้วย eval suite ที่ครอบคลุมทั้งเชิงปริมาณ (deterministic เช่น token, latency, turn count) และเชิงคุณภาพ (non-deterministic เช่น tone, output quality) แล้วใช้ตัวเลขนำทางการปรับปรุงระบบ แทนการเดาด้วยสัญชาตญาณ

บทเรียนจาก Stock Pilot ยืนยันว่าการที่ agent บวมจนใช้งานไม่ได้ มักเกิดจากการไม่ได้หยุดเพื่อจัดระเบียบสถาปัตยกรรมใหม่เมื่อมีฟังก์ชันเพิ่มขึ้น การมีกรอบความคิดที่ชัดเจนในการเลือกใช้ Tool, Skill และ Subagent ควบคู่กับการรัน Eval สม่ำเสมอในทุกการปรับเปลี่ยน จะช่วยให้การขยายขีดความสามารถของ AI Agent เป็นไปอย่างยั่งยืนและมีประสิทธิภาพในระยะยาว

สรุปเนื้อหาและเรียบเรียงจากวิดีโอ Tool, skill, or subagent? Decomposing an agent that outgrew its prompt โดยช่อง Claude (Anthropic) ในงานเวิร์กช็อป Code with Claude London บรรยายโดย Will จากทีม Applied AI

ที่มา: Claude: Tool, skill, or subagent? Decomposing an agent that outgrew its prompt