บทความนี้ของ Anthropic ชื่อ Building effective agents เผยแพร่เมื่อวันที่ 19 ธันวาคม 2024 โดยเป็นการสรุปบทเรียนจากการทำงานร่วมกับทีมที่สร้างระบบ LLM agents จำนวนมากในหลายอุตสาหกรรม ข้อสรุปสำคัญของเขาชัดมากว่า ระบบที่ได้ผลดีที่สุดในโลกจริง มักไม่ได้ชนะด้วยความซับซ้อนหรือ framework ที่อลังการที่สุด แต่ชนะด้วย “รูปแบบที่เรียบง่าย ต่อประกอบได้ และควบคุมได้” มากกว่า
แก่นหลัก
คือ Anthropic พยายามแยกคำว่า agent ออกให้ชัด เพราะในตลาดคำนี้ถูกใช้ปนกันมาก บางคนเรียก agent ว่าระบบอัตโนมัติที่ทำงานเองยาว ๆ ใช้เครื่องมือหลายชนิดและตัดสินใจเองได้ แต่บางคนก็ใช้คำนี้กับระบบที่เป็น workflow ที่กำหนดเส้นทางไว้ล่วงหน้า Anthropic จึงเสนอให้แยกเป็น 2 กลุ่ม คือ workflows กับ agents โดย workflows คือระบบที่ให้ LLM และเครื่องมือทำงานตามเส้นทางที่เขียนโค้ดกำหนดไว้ล่วงหน้า ส่วน agents คือระบบที่ให้ LLM เป็นผู้กำหนดวิธีทำงานและการใช้เครื่องมือด้วยตัวเองแบบยืดหยุ่นมากกว่า
เวลาจะสร้างแอปด้วย LLM ไม่ควรเริ่มจากของซับซ้อนก่อน แต่ควรเริ่มจากวิธีที่ง่ายที่สุด แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็นจริง ๆ เพราะระบบแบบ agentic มักแลกมาด้วยต้นทุนและเวลาในการตอบที่สูงขึ้น แม้จะเพิ่มคุณภาพของงานในบางกรณีได้ก็ตาม สำหรับหลายงาน การปรับ single LLM call ให้ดีขึ้นด้วย retrieval และตัวอย่างใน context ก็อาจเพียงพอแล้ว ยังไม่จำเป็นต้องไปสร้าง agent เต็มรูปแบบ
Framework
ไม่ได้บอกว่าไม่ควรใช้ แต่เตือนว่า framework หลายตัวช่วยให้เริ่มต้นง่ายขึ้นก็จริง เช่น ช่วยเรื่องเรียก LLM, นิยาม tools, parse output, หรือ chain ขั้นตอนต่าง ๆ เข้าด้วยกัน แต่ข้อเสียคือมันเพิ่มชั้น abstraction จนทำให้มองไม่เห็นสิ่งที่เกิดขึ้นจริงใต้ระบบ โดยเฉพาะ prompt และ response ทำให้ดีบักยาก และเผลอเพิ่มความซับซ้อนเกินจำเป็นได้ Anthropic จึงแนะนำให้นักพัฒนาเริ่มจากการเรียก LLM API ตรง ๆ ก่อน เพราะหลาย pattern ทำได้ในโค้ดไม่กี่บรรทัด และถ้าจะใช้ framework ก็ควรเข้าใจการทำงานภายในจริง ๆ ไม่ใช่ใช้แบบเชื่อตามหน้าตาเครื่องมืออย่างเดียว
จากองค์ประกอบพื้นฐานที่สุดไปจนถึง agent เต็มตัว
โดยจุดตั้งต้นคือสิ่งที่เรียกว่า augmented LLM นี่คือ LLM ที่ถูกเสริมความสามารถด้วย retrieval, tools และ memory เพื่อให้ไม่ได้แค่ “ตอบจากความรู้ในตัวเอง” แต่สามารถค้นข้อมูล ใช้เครื่องมือ เลือกว่าจะเก็บอะไรไว้ใช้ต่อ และตัดสินใจว่าเมื่อไรควรเรียกใช้ความสามารถเสริมใด Anthropic เน้นว่า 2 เรื่องที่สำคัญที่สุดคือ หนึ่ง ต้องปรับ augmentation ให้เหมาะกับ use case จริงของคุณ และสอง ต้องทำ interface ระหว่าง LLM กับความสามารถเหล่านี้ให้ชัด ใช้ง่าย และมีเอกสารดีพอ เพราะต่อให้ model เก่ง แต่ถ้า interface กับ tool สับสน ระบบก็จะเป๋ได้ง่าย
Workflow แบบง่ายที่สุดที่คือ
1. Prompt chaining หรือการแตกงานออกเป็นลำดับขั้น
โดยให้ผลลัพธ์จาก LLM รอบก่อนส่งต่อเป็น input ให้รอบถัดไป และสามารถใส่จุดตรวจสอบเชิงโปรแกรมไว้กลางทางได้เพื่อกันงานหลุดเป้า ข้อดีของ pattern นี้คือเหมาะกับงานที่สามารถแยกเป็นขั้นตอนย่อยแบบชัดเจนและคงที่ได้ เช่น เขียนข้อความการตลาดก่อน แล้วค่อยแปลเป็นอีกภาษา หรือให้ร่างโครงบทความก่อน ตรวจว่าโครงผ่านเกณฑ์ที่กำหนด แล้วค่อยขยายเป็นบทความเต็ม จุดคิดสำคัญคือ pattern นี้ยอมแลก latency เพื่อเพิ่มความแม่นยำ เพราะแต่ละรอบ LLM จะเจอโจทย์ที่เล็กและง่ายขึ้น
2. Routing
ซึ่งเป็นการจำแนก input ก่อน แล้วค่อยส่งต่อไปยังเส้นทางย่อยที่เหมาะสมกับประเภทของงาน บทความอธิบายว่าระบบแบบนี้ดีมากเมื่อปัญหามีหลายหมวดที่ต้องการ prompt, tool หรือกระบวนการที่ต่างกัน เช่น งานบริการลูกค้าที่ต้องแยกคำถามทั่วไป คำขอคืนเงิน และปัญหาทางเทคนิคออกจากกัน เพราะถ้าพยายามออกแบบ prompt เดียวให้ครอบจักรวาล ประสิทธิภาพกับบางหมวดอาจลดลงได้ ตัวอย่างที่ Anthropic ให้ยังรวมถึงการ route คำถามง่ายไปยังโมเดลเล็กที่ต้นทุนต่ำกว่า และส่งคำถามยากไปยังโมเดลที่เก่งกว่า เพื่อให้ได้สมดุลระหว่างคุณภาพและต้นทุน
Pattern ที่สำคัญคือ Parallelizatio
หรือการให้ LLM หลายตัวหรือหลาย call ทำงานพร้อมกัน แล้วค่อยนำผลมารวมกันภายหลัง แบ่งเป็น 2 แบบ คือ sectioning กับ voting
sectioning คือแบ่งงานย่อยที่เป็นอิสระต่อกันออกไปทำคู่ขนานเพื่อให้เร็วขึ้น เช่น ให้แต่ละรอบประเมินคนละมิติของคุณภาพงาน หรือคนละด้านของคำถาม
voting คือให้ลองทำงานเดียวกันหลายครั้งเพื่อให้ได้มุมมองที่หลากหลายหรือเพิ่มความมั่นใจ เช่น ให้หลาย prompt ตรวจโค้ดหา vulnerability แล้วค่อยโหวตหรือรวมธงเตือนเข้าด้วยกัน
Anthropic ชี้ว่า pattern นี้เหมาะเมื่อเราต้องการความเร็ว หรืออยากได้ความมั่นใจสูงขึ้นจากหลายมุมมอง เพราะ LLM มักทำได้ดีขึ้นเมื่อให้แต่ละ call โฟกัสแค่ประเด็นเฉพาะจริง ๆ
รูปแบบที่ยกระดับขึ้น
1. Orchestrator-workers
ซึ่งมี LLM ตัวกลางคอยแตกงานอย่างยืดหยุ่นแล้วมอบหมายให้ worker LLM หลายตัวไปทำส่วนย่อย ก่อนจะดึงผลกลับมาสังเคราะห์อีกที ความต่างจาก parallelization คือ งานย่อยไม่ได้ถูกกำหนดตายตัวตั้งแต่แรก แต่ตัว orchestrator จะเป็นคนตัดสินใจเองจาก input ที่ได้รับว่า ต้องมี subtasks อะไรบ้าง และต้องมีกี่ส่วน บทความยกตัวอย่างงาน coding ที่ต้องแก้หลายไฟล์ ซึ่งจำนวนไฟล์ ลักษณะการเปลี่ยนแปลง และลำดับการทำงานอาจต่างกันไปในแต่ละเคส รวมถึงงาน search ที่ต้องไล่หาข้อมูลจากหลายแหล่งแล้วคัดว่าข้อมูลไหนเกี่ยวข้องจริง Pattern นี้เหมาะกับปัญหาที่ซับซ้อนและคาดการณ์โครงสร้างย่อยล่วงหน้าไม่ได้ดีพอ
2. Evaluator-optimizer
ซึ่งให้ LLM ตัวหนึ่งสร้างคำตอบ แล้วอีกตัวหนึ่งทำหน้าที่วิจารณ์ ประเมิน และให้ feedback วนเป็นลูปจนได้ผลลัพธ์ที่ดีขึ้น Anthropic บอกว่ารูปแบบนี้เหมาะเมื่อมีเกณฑ์ประเมินที่ค่อนข้างชัด และการปรับแก้ซ้ำ ๆ ให้คุณค่าที่วัดได้จริง สัญญาณว่าโจทย์เหมาะกับ pattern นี้คือ มนุษย์สามารถทำให้งานดีขึ้นได้ด้วยการให้ feedback ที่เฉพาะเจาะจง และ LLM เองก็สามารถสร้าง feedback แบบนั้นได้เช่นกัน เขาเปรียบเทียบว่าเหมือนกระบวนการที่นักเขียนค่อย ๆ ขัดเกลางานต้นฉบับให้ดีขึ้นหลายรอบ ตัวอย่างที่ยกมามีทั้งงานแปลเชิงวรรณศิลป์และงานค้นหาข้อมูลเชิงซับซ้อนที่อาจต้องค้นหลายรอบ วิเคราะห์หลายรอบ ก่อนจะตัดสินว่าข้อมูลเพียงพอหรือยัง
Agents
ให้ภาพค่อนข้างสมดุล คือไม่ได้เชียร์จนเกินจริง แต่ก็ยอมรับว่า agent เริ่มใช้งานจริงได้มากขึ้น เพราะ LLM เก่งขึ้นในหลายด้านพร้อมกัน ทั้งการเข้าใจโจทย์ซับซ้อน การวางแผน การใช้เครื่องมืออย่างเชื่อถือได้ และการฟื้นตัวจากความผิดพลาดได้เอง Agent จะเริ่มจากคำสั่งหรือการสนทนากับมนุษย์ พอเข้าใจงานแล้วก็จะวางแผนและลงมือทำเอง โดยอาจย้อนกลับมาขอข้อมูลเพิ่มเติมหรือขอให้มนุษย์ช่วยตัดสินใจในบางจุดได้ ระหว่างทำงาน Agent ต้องอาศัย “ground truth” จากสภาพแวดล้อมทุกก้าว เช่น ผลจาก tool call หรือผลการรันโค้ด เพื่อประเมินว่าตัวเองกำลังไปถูกทางหรือไม่ และควรมีจุดหยุดหรือ checkpoint ไว้ให้มนุษย์ตรวจ หรือใช้เป็นเงื่อนไขควบคุมไม่ให้ agent วนไม่จบ เช่น จำกัดจำนวนรอบสูงสุด
Anthropic เน้นชัดว่า agents มีประโยชน์มากกับปัญหาแบบเปิดกว้างที่คาดจำนวนขั้นตอนล่วงหน้าไม่ได้ และไม่สามารถ hardcode เส้นทางตายตัวไว้ได้ แต่ในอีกด้าน ความเป็นอิสระของ agent ก็ทำให้ต้นทุนสูงขึ้น และมีความเสี่ยงเรื่องความผิดพลาดสะสมมากขึ้นด้วย เขาจึงแนะนำให้ทดสอบอย่างหนักใน sandbox และติด guardrails ที่เหมาะสมก่อนปล่อยใช้งานจริง ตัวอย่างที่ Anthropic ยกมาจากงานของตัวเอง ได้แก่ coding agent ที่ใช้แก้โจทย์แนว SWE-bench ซึ่งต้องแก้หลายไฟล์ตามคำอธิบายงาน และ implementation ด้าน computer use ที่ให้ Claude ใช้งานคอมพิวเตอร์เพื่อทำภารกิจจริง
สรุป
บทสรุปนี้ถือว่าเป็นหัวใจที่สุด เพราะตอกย้ำว่า ความสำเร็จในโลก LLM ไม่ได้มาจากการสร้างระบบที่ “ล้ำที่สุด” แต่มาจากการสร้างระบบที่ “เหมาะที่สุดกับความต้องการจริง” วิธีคิดที่ถูกต้องคือ เริ่มจาก prompt แบบง่าย ปรับปรุงด้วยการประเมินผลอย่างจริงจัง แล้วค่อยเพิ่มระบบหลายขั้นหรือหลาย agent เมื่อวิธีง่ายไม่พอจริง ๆ เท่านั้น และเมื่อจะสร้าง agent ควรยึด 3 หลักสำคัญ คือ รักษาความเรียบง่ายของการออกแบบ ทำให้การวางแผนของ agent โปร่งใสตรวจสอบได้ และออกแบบ agent-computer interface หรือ ACI ให้ดี ผ่านการเขียนเอกสารของ tools อย่างละเอียดและการทดสอบอย่างรอบคอบ
ภาคผนวก
ก็มีประโยชน์มาก เพราะยก 2 โดเมนที่ agent ให้คุณค่าได้ชัดเจน ได้แก่ customer support และ coding agents ในงาน support จุดแข็งคือรูปแบบของงานมีทั้ง “บทสนทนา” และ “การลงมือทำ” อยู่พร้อมกัน เช่น ต้องคุยกับลูกค้า เข้าถึงประวัติคำสั่งซื้อหรือข้อมูลลูกค้า ดึงบทความจาก knowledge base และลงมืออัปเดต ticket หรือคืนเงินผ่านเครื่องมือได้จริง ความสำเร็จยังวัดได้ค่อนข้างชัดผ่านการแก้ปัญหาได้จริงของผู้ใช้ ส่วนในงาน coding จุดแข็งคือผลลัพธ์สามารถตรวจสอบได้ด้วย automated tests ทำให้ agent ลองผิดลองถูกและปรับปรุงตาม feedback จากผลทดสอบได้อย่างเป็นระบบ แม้จะตรวจสอบได้ด้วยเทสต์ แต่บทความก็ย้ำว่ามนุษย์ยังจำเป็นมากในการรีวิวภาพรวมว่าโซลูชันนั้นสอดคล้องกับข้อกำหนดของระบบจริงหรือไม่
ภาคผนวกเรื่องการ prompt engineering สำหรับ tools
ซึ่งเป็นมุมที่หลายคนมองข้าม ไม่ว่าคุณจะสร้าง workflow หรือ agent แบบไหน tools มักเป็นแกนสำคัญ และนิยามของ tool ควรได้รับความใส่ใจไม่แพ้ prompt หลัก เพราะรูปแบบของเครื่องมือมีผลโดยตรงต่อความสามารถของ model ในการใช้งาน เช่น การสั่งแก้ไฟล์ด้วย diff อาจยากกว่าการเขียนไฟล์ใหม่ทั้งก้อน เพราะโมเดลต้องรู้จำนวนบรรทัดที่เปลี่ยนให้ตรงตั้งแต่ต้น หรือการให้ output เป็น code ภายใน JSON ก็ยากกว่าการให้เขียนใน markdown เพราะต้องหนีอักขระและจัด format มากขึ้น Anthropic จึงเสนอหลักคิดในการออกแบบ format ของ tools ว่า ควรให้ model มีพื้นที่คิดพอ ไม่บีบจนตัน ควรใช้ format ที่ใกล้กับสิ่งที่ model คุ้นเคยจากข้อความบนอินเทอร์เน็ต และควรหลีกเลี่ยง format ที่มีภาระเชิงรูปแบบมากเกินไป เช่น ต้องนับบรรทัดจำนวนมาก หรือ escape string ซับซ้อนเกินจำเป็น
เรียบเรียงให้เห็นภาพแบบภาษาคนทำงานธุรกิจ
การสร้าง AI agent ที่ดี ไม่ใช่การรีบทำ “ผู้ช่วยอัจฉริยะที่ทำทุกอย่างได้เอง” ตั้งแต่วันแรก แต่คือการเริ่มจากหน่วยที่เล็กและชัดก่อน เช่น prompt เดียวให้ดี, เพิ่ม retrieval ให้แม่น, เติม tools ให้คุยกับโลกจริงได้, จากนั้นค่อยใช้ workflow แบบ chain, route, parallel, หรือ evaluate ตามธรรมชาติของปัญหา และมีเพียงบางกรณีเท่านั้นที่ควรปล่อยให้มันกลายเป็น agent อัตโนมัติเต็มรูปแบบ มุมมองนี้สำคัญมาก เพราะช่วยกันไม่ให้ทีมหลงไปกับความหวือหวา แล้วสร้างของแพง ช้า และควบคุมยาก โดยที่ผลลัพธ์ไม่ได้ดีขึ้นอย่างมีนัยสำคัญ
อีกนัยหนึ่ง เหมือนคู่มือ “ถอดมายาคติ” เรื่อง AI agents ว่า agent ที่ดีไม่จำเป็นต้องซับซ้อน แต่ต้องออกแบบให้เหมาะงาน วัดผลได้ ตรวจสอบได้ และเชื่อมกับเครื่องมือหรือสภาพแวดล้อมจริงได้อย่างน่าเชื่อถือ นี่คือแนวคิดที่ใช้ได้ทั้งกับนักพัฒนา ทีมผลิตภัณฑ์ ทีม automation ไปจนถึงคนที่กำลังสร้าง AI assistant ในองค์กร เพราะมันไม่ได้พูดแค่เทคนิค แต่พูดถึงวินัยในการออกแบบระบบด้วย ว่าจะเพิ่มความฉลาดอย่างไรโดยไม่ทำให้ระบบเปราะบางเกินไป
บทความจาก
https://www.anthropic.com/engineering/building-effective-agents
