การสร้าง AI Agent อย่างมีประสิทธิภาพ
(anthropic.com)- ทีมที่นำ เอเจนต์ที่ขับเคลื่อนด้วย LLM ไปใช้งานได้สำเร็จ มักมีแนวโน้มใช้ แพตเทิร์นที่เรียบง่ายและนำมาประกอบกันได้ แทนเฟรมเวิร์กที่ซับซ้อน
- ควรทำความเข้าใจความแตกต่างเชิงโครงสร้างระหว่าง เวิร์กโฟลว์ กับ เอเจนต์ และแนะนำให้ใช้ความซับซ้อนเท่าที่จำเป็นเสมอเพื่อให้ได้โซลูชันที่เหมาะสมที่สุด
- แพตเทิร์นเอเจนต์หลากหลายแบบ เช่น prompt chaining, routing, parallelization, orchestrator-workers, evaluation-optimization loop ถูกนำไปใช้จริงในสภาพแวดล้อมการผลิต และแต่ละแบบก็มี กรณีการใช้งาน พร้อมข้อดีข้อเสียที่ต่างกัน
- ในการนำเอเจนต์ไปใช้งานจริง ความเรียบง่าย ความโปร่งใส และการออกแบบอินเทอร์เฟซ คือหลักการสำคัญ และต้องใส่ใจกับการออกแบบเครื่องมือและ prompt engineering
- กรณีที่เอเจนต์สร้างคุณค่าได้จริงกำลังเพิ่มขึ้นเรื่อย ๆ ทั้งในงานสนับสนุนลูกค้าและสภาพแวดล้อมการพัฒนาซอฟต์แวร์
ภาพรวม
ตลอด 1 ปีที่ผ่านมา Anthropic ได้สร้าง เอเจนต์ที่อิงกับโมเดลภาษาขนาดใหญ่ (LLM) ร่วมกับทีมในหลากหลายอุตสาหกรรม ในทางปฏิบัติ กรณีที่ประสบความสำเร็จในการนำเอเจนต์มาใช้ มักตั้งอยู่บนพื้นฐานของ แพตเทิร์นที่เรียบง่ายและประกอบต่อกันได้ มากกว่าเฟรมเวิร์กที่ซับซ้อนหรือไลบรารีเฉพาะทาง โพสต์นี้จะแชร์อินไซต์จากการทำงานร่วมกับลูกค้าและประสบการณ์พัฒนาภายใน รวมถึง คำแนะนำเชิงปฏิบัติสำหรับการสร้างเอเจนต์อย่างมีประสิทธิภาพ
เอเจนต์คืออะไร
เอเจนต์สามารถนิยามได้หลายแบบ
- บางคนให้นิยามว่าเป็น ระบบอัตโนมัติเต็มรูปแบบ ที่ใช้เครื่องมือภายนอกเพื่อทำงานที่ซับซ้อนให้สำเร็จได้ด้วยตนเอง
- บางคนมองว่าเป็น การใช้งานแบบกำหนดขั้นตายตัว ที่ทำงานตามเวิร์กโฟลว์ที่จำกัดหรือกระบวนการที่กำหนดไว้ล่วงหน้า
Anthropic จัดทั้งสองแบบนี้เป็น ระบบเชิงเอเจนต์ แต่ให้ความแตกต่างเชิงสถาปัตยกรรมที่สำคัญระหว่าง เวิร์กโฟลว์ และ เอเจนต์
- เวิร์กโฟลว์: โครงสร้างที่ LLM และเครื่องมือถูก orchestration ตามเส้นทางโค้ดที่กำหนดไว้ล่วงหน้า
- เอเจนต์: LLM เป็นผู้ตัดสินใจแบบไดนามิกด้วยตนเองว่าจะใช้เครื่องมือและกระบวนการใด โดยมีอำนาจควบคุมวิธีบรรลุภารกิจ
ในโพสต์นี้จะอธิบายระบบทั้งสองรูปแบบอย่างละเอียด และกล่าวถึงกรณีการใช้งานจริงในภาคผนวก 1
เมื่อใดควรใช้เอเจนต์ (และเมื่อใดไม่ควร)
ในการพัฒนาแอปพลิเคชัน ควรยึดหลัก ความซับซ้อนให้น้อยที่สุด และค่อย ๆ เพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น
- ระบบเชิงเอเจนต์อาจยอมแลก latency/ต้นทุน บางส่วนเพื่อยกระดับ ประสิทธิภาพของงาน
- หากยังไม่จำเป็นต้องใช้ความซับซ้อนมาก ก็มักแก้ปัญหาได้ดีพอด้วยการเรียก LLM ครั้งเดียว ร่วมกับ few-shot examples หรือการเชื่อมกับระบบค้นคืนข้อมูล
- เวิร์กโฟลว์เหมาะกับงานที่ต้องการความคาดเดาได้และความสม่ำเสมอ ส่วนเอเจนต์เหมาะกับงานที่ต้องการ ความยืดหยุ่นและการสเกล
ควรใช้เฟรมเวิร์กเมื่อใดและอย่างไร
มีเฟรมเวิร์กหลากหลายที่ช่วยให้การสร้างระบบเชิงเอเจนต์ทำได้ง่ายขึ้น
- LangGraph (LangChain)
- Amazon Bedrock AI Agent framework
- Rivet, Vellum เป็นต้น
เฟรมเวิร์กเหล่านี้ช่วยลดภาระงานระดับล่าง เช่น การเรียก LLM การนิยาม/พาร์สเครื่องมือ และการประกอบ call chain แต่การมี abstraction มากเกินไปก็เสี่ยงทำให้โฟลว์ของ prompt และการตอบกลับ ไม่โปร่งใส หรือเพิ่มความซับซ้อนโดยไม่จำเป็น
- แนะนำให้นักพัฒนาเริ่มจาก การใช้ LLM API โดยตรงให้มากที่สุด
- แม้จะใช้เฟรมเวิร์ก ก็ต้องเข้าใจการทำงานภายในอย่างถูกต้อง
ดูตัวอย่างการใช้งานได้ที่ anthropic-cookbook
Building blocks, เวิร์กโฟลว์ และแพตเทิร์นเอเจนต์
Anthropic แนะนำแพตเทิร์นของระบบเชิงเอเจนต์ที่ถูกใช้งานบ่อยในสภาพแวดล้อมจริง
Building block: LLM แบบเสริมความสามารถ
หัวใจของระบบเชิงเอเจนต์คือ LLM ที่ถูกเสริมความสามารถด้วยฟังก์ชันอย่าง การค้นคืนข้อมูล เครื่องมือ และหน่วยความจำ
- โมเดลสามารถทำ การสร้าง search query, การเลือกเครื่องมือที่เหมาะสม และ การจัดเก็บข้อมูล ได้ด้วยตัวเอง
- ประเด็นสำคัญในการนำไปใช้คือการปรับความสามารถให้เหมาะกับกรณีใช้งาน และให้ อินเทอร์เฟซที่ชัดเจนและมีเอกสารประกอบ แก่ LLM
ด้วย Model Context Protocol ที่เพิ่งเปิดตัว ทำให้สามารถเชื่อมกับเครื่องมือของ third party ได้อย่างง่ายดาย
คำอธิบายแยกตามประเภทเวิร์กโฟลว์
Prompt chaining
- แยกงานออกเป็นลำดับขั้น โดยแต่ละการเรียก LLM จะรับผลลัพธ์จากขั้นก่อนหน้าไปประมวลผลต่อ
- สามารถควบคุมกระบวนการได้ด้วยการเพิ่มการตรวจสอบเชิงโปรแกรม (gate) ในแต่ละขั้น
- ตัวอย่างการใช้งาน: สร้างข้อความการตลาดแล้วแปลภาษา, วางโครงเอกสาร → ตรวจสอบ → เขียนเนื้อหา
Routing
- จำแนกอินพุตแล้วแยกไปยังงานถัดไปที่เหมาะสม
- สามารถใช้ prompt และเครื่องมือที่ปรับแต่งเฉพาะตามแต่ละหมวดหมู่
- ตัวอย่างการใช้งาน: แยกประเภทคำถามลูกค้า (การคืนเงิน, การสนับสนุนด้านเทคนิค ฯลฯ), เลือกโมเดลตามระดับความยาก
Parallelization
- แบ่งงานออกเป็นหน่วยย่อย ประมวลผลแบบขนาน แล้วรวบรวมผลลัพธ์
- Sectioning: ประมวลผลแต่ละส่วนอย่างอิสระ
- Voting: ทำงานเดียวกันซ้ำด้วยมุมมองหรือ prompt หลายแบบ แล้วใช้เสียงข้างมากหรือวิธีคล้ายกัน
- ตัวอย่างการใช้งาน: แยกการกรองและตอบคำถามผู้ใช้, การประเมินอัตโนมัติ, การรีวิวโค้ด
Orchestrator-workers
- LLM ส่วนกลางทำหน้าที่แยกและมอบหมายงานแบบไดนามิก แล้วให้ worker LLM หลายตัวทำงานแต่ละส่วนก่อนนำมารวมกัน
- เหมาะกับ subtasks ที่ไม่ได้กำหนดไว้ล่วงหน้าและเปลี่ยนแปลงตามอินพุต
- ตัวอย่างการใช้งาน: การเขียนโค้ดที่ต้องแก้หลายไฟล์, การค้นหาข้อมูลที่ซับซ้อน
Evaluation-optimization loop
- ใช้ LLM สำหรับสร้างคำตอบและ LLM สำหรับประเมินผลในลูปแบบวนซ้ำ
- เหมาะกับสถานการณ์ที่มีเกณฑ์ประเมินชัดเจนและการปรับปรุงจาก feedback มีคุณค่า
- ตัวอย่างการใช้งาน: ประเมินนัยละเอียดอ่อนในการแปลวรรณกรรม, การค้นหาข้อมูลหลายรอบ
เอเจนต์
-
เมื่อ LLM พัฒนาขึ้น ก็เริ่มมีเอเจนต์ในบริการจริงที่รองรับ อินพุตซับซ้อน การให้เหตุผลและการวางแผน การใช้เครื่องมือ และการฟื้นตัวจากข้อผิดพลาด ได้
-
เริ่มจากคำสั่งหรือบทสนทนาของผู้ใช้ → ทำให้ภารกิจชัดเจน → ดำเนินการอย่างอิสระ → รับ feedback ได้ที่ checkpoint ระหว่างทาง → จบเมื่อทำเสร็จหรือถึงเงื่อนไขหยุด
-
ในการใช้งานจริง LLM จะวนลูปโดยอ้างอิง feedback จากสภาพแวดล้อม เช่น ผลลัพธ์จากเครื่องมือหรือการรันโค้ด และ ชุดเครื่องมือกับเอกสารประกอบ คือหัวใจสำคัญ
-
ตัวอย่างการใช้งาน: coding agent เพื่อแก้ งาน SWE-bench, การทำคอมพิวเตอร์ใช้งานอัตโนมัติบน Claude
-
ขอบเขตที่เหมาะสม: ปัญหาแบบปลายเปิดที่คาดเดาเส้นทางหรือขั้นตอนตายตัวไม่ได้ และสถานการณ์ที่ต้องการความน่าเชื่อถือในการตัดสินใจ
-
ต้องคำนึงถึง ต้นทุนและความเป็นไปได้ของข้อผิดพลาดเชิงซ้อน ที่เพิ่มขึ้นจากความเป็นอิสระที่สูงขึ้น และต้องมีการทดสอบใน sandbox กับ guardrails ที่เหมาะสม
การผสมผสานและปรับแต่งแพตเทิร์น
- Building block ที่กล่าวมานี้ไม่ใช่กฎตายตัว แต่สามารถ นำมาผสมผสาน ให้เหมาะกับสถานการณ์ต่าง ๆ ได้
- สิ่งสำคัญคือการเลือกโครงสร้างที่เหมาะสมที่สุดผ่าน การวัดผลและการปรับปรุงซ้ำ พร้อมเพิ่มความซับซ้อนแบบค่อยเป็นค่อยไป
สรุปและหลักการแนะนำ
ความสำเร็จของระบบ LLM ไม่ได้อยู่ที่ความซับซ้อนหรือความใหม่ของเทคโนโลยี แต่อยู่ที่การหาแนวทางที่แม่นยำและเหมาะกับวัตถุประสงค์
-
เริ่มจาก prompt ที่เรียบง่าย ประเมินผลและปรับให้เหมาะสมซ้ำ ๆ แล้วค่อยขยายความซับซ้อนเป็นขั้น ๆ
-
หลักการสำคัญ 3 ข้อในการออกแบบเอเจนต์
- รักษา ความเรียบง่าย
- ให้ความสำคัญกับ ความโปร่งใส (ทำให้ชัดเจนตั้งแต่ขั้นวางแผน)
- เน้น การทำเอกสารและการทดสอบเครื่องมือ/อินเทอร์เฟซ
-
เฟรมเวิร์กช่วยให้เริ่มต้นได้เร็ว แต่ในทางปฏิบัติ ความสามารถในการลด abstraction layer และลงมือสร้างเองโดยตรงต่างหากที่กำหนดความน่าเชื่อถือและการบำรุงรักษาในระยะยาว
ภาคผนวก 1: กรณีการใช้เอเจนต์ในงานจริง
การสนับสนุนลูกค้า
ด้านการสนับสนุนลูกค้าเหมาะกับการใช้เอเจนต์โดยธรรมชาติ เพราะผสาน อินเทอร์เฟซแบบแชตบอต เข้ากับ การเชื่อมต่อเครื่องมือ
- มีทั้งอินเทอร์เฟซแบบบทสนทนาและความจำเป็นในการเข้าถึงข้อมูลภายนอกหรือประมวลผลงานธุรกิจ
- เชื่อมกับข้อมูลลูกค้า ประวัติคำสั่งซื้อ และ knowledge base ผ่านเครื่องมือได้
- ทำงานอย่างการคืนเงินหรือจัดการทิกเก็ตให้เป็นอัตโนมัติ
- สามารถกำหนดเกณฑ์ความสำเร็จของการแก้ปัญหาได้ชัดเจน
กรณีที่นำไปใช้ได้สำเร็จมีการตรวจสอบ ประสิทธิผลของเอเจนต์ ด้วยโมเดลคิดค่าบริการตามการใช้งาน โดยอิงจากปริมาณการแก้ปัญหาสำเร็จ
Coding agent
ในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ การใช้เอเจนต์ในงานอย่าง การแก้ปัญหาอัตโนมัติ ก็เพิ่มขึ้นอย่างมากเช่นกัน
- สามารถตรวจสอบผลลัพธ์ของโค้ดได้ผ่านการทดสอบอัตโนมัติ
- สามารถปรับปรุงซ้ำโดยใช้ผลการทดสอบเป็น feedback
- นิยามของปัญหาชัดเจน และคุณภาพของผลลัพธ์ก็วัดได้อย่างเป็นกลาง
กรณีใช้งานภายในของ Anthropic: แก้ปัญหา GitHub issue จริงใน benchmark SWE-bench Verified ได้โดยใช้เพียงคำอธิบายของ pull request แม้นอกเหนือจากการทดสอบอัตโนมัติแล้ว การตรวจสอบโดยมนุษย์ ก็ยังสำคัญในการยืนยันว่าระบบตอบโจทย์ความต้องการทั้งหมด
ภาคผนวก 2: วิธีทำ tool prompt engineering
ในทุกระบบเชิงเอเจนต์ เครื่องมือ คือองค์ประกอบสำคัญ
- LLM อย่าง Claude สามารถโต้ตอบกับบริการภายนอกผ่าน API ได้อย่างตรงตามโครงสร้างและนิยามที่กำหนด
- คำตอบสามารถมี tool use block รวมอยู่ได้
- การนิยามและสเปกของเครื่องมือก็ต้อง ออกแบบอย่างละเอียดพอ ๆ กับ prompt engineering
เคล็ดลับการออกแบบฟอร์แมตของเครื่องมือ
-
เผื่อโทเค็นให้เพียงพอเพื่อไม่ให้โมเดลตกหลุมพรางจากสิ่งที่โมเดลเขียนขึ้นเอง
-
แนะนำให้ใช้ฟอร์แมตที่เป็นธรรมชาติและพบได้บ่อยบนอินเทอร์เน็ต
-
ลดภาระของการจัดรูปแบบที่ไม่จำเป็น (เช่น การนับจำนวนบรรทัดโค้ด, การ escape สตริง เป็นต้น) ให้เหลือน้อยที่สุด
-
เราควรใส่ใจกับ agent-computer interface (ACI) มากพอ ๆ กับที่ลงทุนกับการออกแบบ human-computer interface (HCI)
-
จากมุมมองของโมเดล การทำความเข้าใจและใช้งานเครื่องมือต้อง ‘ชัดเจน’ และควรมีตัวอย่างการใช้งาน เงื่อนไขขอบเขต และรูปแบบอินพุตที่ระบุไว้อย่างชัดเจน
-
ชื่อพารามิเตอร์และคำอธิบายก็ควรใช้คำที่เข้าใจง่าย พร้อมออกแบบเหมือนกำลังเขียนคู่มือ (docstring)
-
ทดสอบวิธีใช้งานจริงด้วยค่าอินพุตที่หลากหลาย และปรับปรุงซ้ำ
-
ออกแบบอาร์กิวเมนต์แบบ Poka-yoke เพื่อลดโอกาสเกิดความผิดพลาด
ระหว่างสร้างเอเจนต์สำหรับ SWE-bench จริง Anthropic ใช้เวลากับ การปรับแต่งการออกแบบเครื่องมือมากกว่าพร้อมป์ทั้งหมด ตัวอย่างเช่น หลังปรับให้รับเฉพาะ absolute path เพื่อลดความผิดพลาดของพาธไฟล์เมื่อหลุดออกจาก root folder ระบบก็ทำงานได้อย่างสมบูรณ์แบบ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ความเห็นนี้บอกว่าน่าประทับใจมากที่บทความเริ่มจากการทำให้คำจำกัดความของ "AI agents" ชัดเจนเสียก่อน โดยนิยามที่ใช้ที่นี่คือ "ระบบที่ LLM จัดการกระบวนการและการใช้เครื่องมือแบบไดนามิกด้วยตัวเอง และควบคุมวิธีการทำงานของตนเอง" อีกทั้งยังชอบส่วนที่แยกความแตกต่างระหว่าง ‘agent’ กับ ‘workflow’ รวมถึงวิธีที่บทความแนะนำแพตเทิร์น workflow เชิงปฏิบัติหลายแบบด้วย ตอนที่บทความออกมาใหม่ ๆ ก็มีสรุปที่เขียนไว้เองเช่นกัน บันทึก building-effective-agents และเมื่อไม่นานมานี้ก็พบว่าบทความของ Anthropic เรื่อง การสร้างระบบวิจัยแบบ multi-agent น่าสนใจมาก พร้อมทั้งมีบันทึกเพิ่มเติมเกี่ยวกับเรื่องนี้ด้วย บันทึก multi-agent research system
มีความเห็นว่าคำจำกัดความของ workflow ที่บทความนี้ใช้ไม่ค่อยแม่นยำนัก เพราะทุกวันนี้ workflow engine จำนวนมากไม่ได้ทำงานตามเส้นทางโค้ดที่กำหนดไว้ล่วงหน้า และในหลายกรณีก็ทำงานแทบไม่ต่างจาก agent เลย มองว่าผู้เขียนนิยาม workflow ขึ้นมาใหม่เพื่อพยายามแยกสองสิ่งนี้ออกจากกัน แต่ในความเป็นจริง agent เองก็อาจเป็นเพียง workflow แบบลูปที่เรียกใช้งานแบบไดนามิกตามคำตอบของ LLM เท่านั้น และ workflow engine สมัยใหม่ก็มีความไดนามิกสูงมากเช่นกัน
หนึ่งในผู้เขียนร่วมของ Building Effective Agents เคยไปบรรยายหัวข้อนี้ที่ AIE ด้วย และประสบการณ์คือได้รับการตอบรับดีมาก วิดีโอ YouTube
บทความเกี่ยวกับงานวิจัย multi-agent นั้นดีมากจริง ๆ แต่ไม่เห็นด้วยกับข้ออ้างในบทความ Building Effective AI Agents ที่ว่า "การสร้างระบบตั้งแต่ต้นโดยไม่ใช้ framework นั้นดีในเชิงการเรียนรู้" โดยให้เหตุผลว่าข้อดีข้อแรกของการใช้ framework ที่ดีคือสามารถทดลองกับ LLM ได้หลากหลายตัวอย่างง่ายดาย รวมถึงแบบที่ไม่ผูกกับผู้ให้บริการรายใดรายหนึ่งด้วย
มีคำถามว่า Anthropic ใช้ AI agent framework อะไรอยู่ เพราะดูเหมือนจะไม่เคยเปิดเผย framework ภายในของตัวเองเลย
มีความเห็นตอบกลับว่าขอบคุณสำหรับบันทึกเพิ่มเติม และหัวข้อนี้ก็เป็นประเด็นสำคัญมากสำหรับตัวเองในช่วงนี้เช่นกัน
มีความรู้สึกว่าในวงการ AI แค่ครึ่งปีก็นานมากแล้ว ไม่กี่เดือนก่อนยังอ่านบทความนี้ซ้ำไปซ้ำมาอยู่เลย แต่ตอนนี้กลับรู้สึกชัดเจนว่าการพัฒนา agent ชนเพดานคอขวดแล้ว แม้แต่ Gemini รุ่นล่าสุดก็ดูเหมือนประสิทธิภาพถดถอยลงด้วยซ้ำ
การรันหลาย agent พร้อมกันมีค่าใช้จ่ายสูงและทำให้ RoI ต่ำลง ตัวอย่างเช่น DeepSearch agent สำหรับหุ้นใช้ agent 6 ตัว และมีค่าใช้จ่ายราว 2 ดอลลาร์ต่อหนึ่ง query การ orchestrate multi-agent ควบคุมได้ยาก และถ้าโมเดลแข็งแกร่งขึ้น ความจำเป็นของ multi-agent ก็ลดลง ในทางกลับกัน ยิ่งโมเดลอ่อนลง มูลค่าทางธุรกิจของ AI เฉพาะทางที่แคบและชำนาญเฉพาะด้านก็ยิ่งสูงขึ้น นี่เป็นประสบการณ์จริงที่นำมาแชร์
มีคนถามว่าเหตุใดจึงรู้สึกว่า agent ถดถอยลง และสงสัยว่าทำไมมันถึงไม่สามารถแยกร่างตัวเองออกเป็นหลายชุดเพื่อทำงานแบบขนานตลอด 24/7 พร้อมตรวจสอบและพัฒนาตัวเองต่อเนื่องได้เสียที
มีความเห็นว่าการแก้ปัญหา prompt injection เป็นเรื่องยากมาก และกำลังกลายเป็นคอขวดที่ร้ายแรง
มีคำถามว่า agent จัดการกับ task queueing, race condition และปัญหา concurrency อื่น ๆ อย่างไร เวลามีบทความเกี่ยวกับการสร้าง workflow แบบ multi-agent มักจะบอกว่า orchestrator agent เป็นผู้จัดการทั้งหมด แต่ก็สงสัยเสมอว่าในทางปฏิบัติต้องอาศัยการออกแบบที่ซับซ้อนกว่านั้นและ glue code ที่ฉลาดมากหรือไม่ หรือว่าทั้งหมดนี้ทำงานได้จริงราวกับเป็น “เวทมนตร์อัตโนมัติ”
มีคำอธิบายว่ามาตรฐานของ agent คือเครื่องมือจะถูกรันแบบลำดับต่อกัน จึงไม่ต้องกังวลเรื่อง concurrency มากนัก แต่ตอนนี้หลายโมเดลรองรับการเรียกใช้เครื่องมือแบบขนานแล้ว ดังนั้นถ้าโมเดลร้องขอว่า “ให้รันเครื่องมือสามตัวนี้” ตัว harness ก็สามารถรันแบบขนานหรือแบบลำดับแล้วส่งผลลัพธ์กลับไปในขั้นถัดไปได้ Anthropic ใช้การตั้งค่าแบบ multi-agent อย่างจริงจังมากกว่า โดยมี agent ระดับบนมอบหมายงานให้ agent ระดับล่างหลายตัวทำแบบขนาน กลเม็ดนี้ถูกนำไปใช้กับ Claude Code และมีการอธิบายเพิ่มเติมทั้งในบันทึก reverse engineering ที่เกี่ยวข้อง (claude-trace) และในบทความว่าด้วยวิธีทำงานของ Claude Research (multi-agent-research-system) ขั้นของการค้นหาแพตเทิร์นการใช้เครื่องมือของ LLM ยังอยู่ในช่วงเริ่มต้นมาก และที่โมเดลเริ่มใช้เครื่องมือได้ดีจริง ๆ ก็เพิ่งเป็นเรื่องในช่วง 6 เดือนหลังนี้เอง จึงยังมีโอกาสพัฒนาอีกมาก
เพราะอย่างนี้จึงเริ่มชอบแนวทางที่ให้ LLM เขียน code เพื่อจัดการ tool call โดยตรง มากกว่าจะทำทุกอย่างเป็น JSON ไลบรารี smolagents ของ Huggingface ใช้วิธีให้ LLM สร้างโค้ดเรียก python function หากต้องการ parallel tool calls ก็แค่ระบุใน prompt และ LLM เองก็ควรจัดการ synchronization ด้วย แน่นอนว่ายังมีประเด็นเรื่องการรันโค้ดที่ LLM สร้างขึ้น แต่ก็มีหลายวิธีแก้ปัญหานี้อยู่แล้ว
มีการแชร์กรณีใช้งานของเว็บอินเทอร์เฟซ Codex โดยมีแผนรีแฟกเตอร์ที่ยาวเกินกว่าจะจบได้ในครั้งเดียว จึงใช้ฟังก์ชัน “ask” เพื่อแยกเป็นหลายงานและจัดกลุ่มงานที่ทำแบบขนานได้ LLM แบ่งงานออกมาได้คล้ายวิธีที่ทีมงานจริงแบ่งกันทำ แต่เพราะไม่มีสมมติฐานเรื่องการสื่อสารระหว่างงาน การสูญเสียคอนเท็กซ์จึงสูงมาก แม้สุดท้ายจะใช้เวลานานกว่าทำเองก็ยังลองทำดู แล้วจึงเปลี่ยนมาใช้วิธีประมวลผลแบบลำดับ โดยให้แต่ละงานอยู่ในคนละเซสชันพร้อม prompt ละเอียดสำหรับแต่ละงาน เช่น เป้าหมาย วิธีการ การตรวจสอบ และการทำเอกสาร สรุปคือ orchestrator agent ใช้ได้กับงานที่เรียบง่ายมาก ๆ แต่ขอบเขตการใช้งานจริงค่อนข้างจำกัดกว่าที่คิด
มีจุดยืนว่าไม่มีอะไรที่ทำงานอัตโนมัติได้อย่างกับเวทมนตร์เลย คุณลักษณะด้านปฏิบัติการที่ระบบเดิมต้องใส่ใจ ก็ต้องพัฒนาให้มีใน AI agent เช่นกัน ถ้ามองแค่เดโมของ AI agent แล้วคิดว่าจะเอา “โค้ดของทีมที่เต็มไปด้วย spaghetti code” มาแทนด้วย AI prompt สวย ๆ ไม่กี่อัน ก็อาจโดนหลอกได้ แม้บางกรณีจำนวนน้อยอาจใช้ได้จริง แต่สุดท้ายโค้ดทุกชิ้นที่อยู่ในระบบล้วนมีเหตุผลของมัน และถ้าถึงขั้นต้องแปลโค้ดทั้งหมดนั้นยัดเข้าไปใน LLM ก็ถือว่าหลงทิศทางแล้ว
สำหรับ coding agent มีแพตเทิร์นที่กำลังก่อตัวขึ้นคือใช้ container เพื่อแยกงานออกจากกัน และใช้ git สำหรับรีวิวและ merge ผลงาน ตัวอย่างเช่นกรณีใช้งาน container และ MCP (container-use) ซึ่งมีประโยชน์มากกับงานเขียนโค้ดแบบขนาน ส่วนงานประเภทอื่นก็ยังใช้ตัวสร้าง workflow อย่าง n8n, Zapier และ CrewAI บ่อยอยู่ดี
บทความนี้เตือนให้กลับมานึกถึงข้อความสำคัญว่าให้เริ่มจาก “สิ่งที่ง่ายที่สุด” แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็นจริง ๆ มีการกล่าวว่าการเรียกใช้ LLM อย่างชัดเจนร่วมกับ glue logic ง่าย ๆ เพียงเล็กน้อย ก็อาจสร้างระบบที่เสถียรกว่า ดีบักง่ายกว่า และมีต้นทุนต่ำกว่าได้ ในทางกลับกัน ระบบ agent ที่ดูหวือหวากลับมักสร้างปัญหาเพิ่มมากกว่าเดิม
มีการแสดงความหวังว่า AI จะกลายเป็นสิ่งที่ช่วยผู้คนได้อย่างเป็นรูปธรรมจริง ๆ
มีความเห็นว่าเป็นเรื่องดีที่ Anthropic เผยแพร่ข้อมูลทางเทคนิคแบบนี้ แต่ก็ควรมีเวอร์ชันคู่มือที่เข้าใจง่ายสำหรับคนที่ไม่ใช่ผู้เชี่ยวชาญด้วย ยกตัวอย่างเช่น แม้ฝ่ายการตลาดจะอยากนำ agent มาใช้ ก็ยังต้องมีคู่มือสำหรับการกำหนดสเปกในระดับพื้นฐาน แม้ส่วนท้ายของบทความและภาคผนวกจะมีเนื้อหาที่เกี่ยวข้องอยู่บ้าง แต่ก็ยังถูกมองว่ายังเน้นอยู่ที่มุมของการลงมือ implement มากกว่า “จะสร้างอย่างไร” ในระดับที่คนทั่วไปนำไปใช้ได้
(ธันวาคม 2024 - ตอนนี้พอย้อนคิดแล้วรู้สึกเหมือนเป็นช่วงเวลาที่นานมากมาแล้ว)
มีความเห็นว่าบทความนี้ยังคงยืนระยะได้ดีมาก ส่วนตัวก็ยังใช้เป็นเอกสารอ้างอิงต่อเนื่อง และไม่รู้สึกว่ามันล้าสมัยไปตามเวลา อีกทั้งยังเป็นบทความที่ทำให้ Anthropic ดูเป็น “พาร์ตเนอร์ด้านการพัฒนาเครื่องมือ AI ที่ใช้งานได้จริง” ในภาพลักษณ์ใหม่ด้วย
มีมุมมองว่ากระแส hype ของ Agent ตอนนี้ซาลงไปมากแล้ว
มีการแชร์ข้อมูลว่าบทความนี้เคยถูกนำมาถกเถียงกันมาก่อนแล้วในเวลานั้น การสนทนา HN ต้นฉบับ
มีความเห็นว่าชอบที่บทความนี้เข้าหาเรื่องนี้อย่างสมจริง โดยไม่โอ้อวดหรือไหลตามกระแส หลายคนมีแนวโน้มจะสร้างระบบ agent เพราะกระแส แต่ไม่ได้หยุดคิดก่อนว่างานนั้นจำเป็นต้องใช้ agent จริงหรือไม่ จึงมีท่าทีวิจารณ์แนวโน้มดังกล่าว