หนังสือเล่มใหม่เกี่ยวกับรูปแบบการออกแบบแบบเอเจนต์เปลี่ยนแปลงความเข้าใจเกี่ยวกับเอเจนต์ปัญญาประดิษฐ์

ผู้เขียน：Yanhua

Antonio Gullí เป็นผู้อำนวยการด้านวิศวกรรมของ Google เขาเขียนหนังสือ 453 หน้าที่แบ่งการพัฒนา AI Agent ออกเป็น 21 รูปแบบการออกแบบ

แต่นี่ไม่ใช่รีวิวหนังสือ แรงจูงใจของฉันในการอ่านหนังสือเล่มนี้มีความเฉพาะเจาะจง: ฉันเคยเขียนเรื่อง Harness Engineering เขียนประสบการณ์การตกหลุมพรางของ Clawdbot เขียนบทความ “ตัวแทน AI ไม่ใช่เวทมนตร์” ซึ่งเล่าถึงการเปลี่ยนแปลงเจ็ดครั้งจากการเผา Token ไปสู่การใช้งานที่ดีจริงๆ ทุกครั้งที่เขียนเสร็จ ฉันยังมีคำถามที่ยังไม่ได้คิดให้ชัดเจนเต็มที่: แล้วสิ่งเหล่านี้มีตรรกะพื้นฐานที่สามารถนำไปใช้ซ้ำได้หรือไม่?

This book gave me the answers, and even deeper than I expected.

คุณอาจเขียนไม่ใช่ Agent เลย

การตัดสินที่รุนแรงที่สุดในหนังสือซ่อนอยู่ในบทนำ

ผู้คนส่วนใหญ่ใช้ “AI” ที่เป็นเพียง Level 0: LLM แบบเปลือย ไม่มีเครื่องมือ ไม่มีความจำ และไม่สามารถกระทำได้ คุณถามมันว่าภาพยนตร์เรื่องใดจะได้รับรางวัลออสการ์ประจำปี 2025 มันก็เดา หนังสืออธิบายไว้อย่างชัดเจน: สิ่งที่อยู่ใน Level 0 ไม่ใช่ Agent

ขึ้นไปด้านบน才是真 Agent：

• ระดับ 1: ผู้ใช้งานเครื่องมือ

  ตัวแทนเริ่มใช้เครื่องมือแล้ว: การค้นหา, API, ฐานข้อมูล แต่มันไม่ได้แค่ “สามารถเรียกใช้อินเทอร์เฟซ” เท่านั้น แต่ต้องสามารถตัดสินใจด้วยตัวเองว่าเมื่อใดควรเรียกใช้, เรียกอะไร, และจะใช้ผลลัพธ์อย่างไร หนังสือให้ตัวอย่างที่ชัดเจนมาก: ผู้ใช้ถามว่า “มีซีรีส์ใหม่อะไรบ้างตอนนี้” ตัวแทนจึงตระหนักด้วยตัวเองว่าข้อมูลนี้ไม่อยู่ในชุดข้อมูลการฝึกสอน จึงดำเนินการเรียกใช้เครื่องมือค้นหาอย่างอิสระ และรวมผลลัพธ์ขึ้นมา ขั้นตอนสำคัญอยู่ที่ “การตระหนักด้วยตัวเอง” ไม่ใช่มนุษย์บอกว่า “คุณไปค้นหาสิ” แต่มันตัดสินใจด้วยตัวเองว่าจำเป็นต้องค้นหา ความสามารถในการตัดสินใจนี้คือเกณฑ์ขั้นพื้นฐานของระดับ 1

• ระดับ 2: ผู้คิดเชิงกลยุทธ์

  มีสิ่งเพิ่มเติมสองอย่าง: การวางแผนและ Context Engineering หนังสือกำหนดนิยามของ Context Engineering ว่า ไม่ใช่การสะสมข้อมูล แต่เป็นการเลือก ตัดทอน และแพ็กเกจบริบทอย่างระมัดระวัง ตัวอย่างนั้นยอดเยี่ยม: ผู้ใช้ต้องการหาคาเฟ่ระหว่างสองสถานที่ Agent ก่อนอื่นเรียกใช้เครื่องมือแผนที่เพื่อรับข้อมูลจำนวนมาก จากนั้นตัดสินใจด้วยตนเองว่า “ขั้นตอนถัดไปต้องการแค่ชื่อถนน” จึงตัดผลลัพธ์จากแผนที่ให้เหลือเพียงรายการสั้นๆ ก่อนส่งให้เครื่องมือค้นหาในพื้นที่ ทุกขั้นตอนล้วนลดเสียงรบกวนของข้อมูล

  ในหนังสือมีประโยคหนึ่งที่ฉันอ่านซ้ำหลายครั้ง: “เพื่อให้ AI đạtความแม่นยำสูงสุด ต้องให้บริบทที่สั้น กระชับ และมีพลัง” Context Engineering คือการดำเนินการนี้

  ที่ระดับนี้ ตัวแทนยังสามารถทบทวนตนเองได้ หลังจากทำงานเสร็จ จะตรวจสอบด้วยตัวเองและแก้ไขข้อผิดพลาดด้วยตัวเอง ฉันจะอธิบายรายละเอียดเพิ่มเติมในภายหลัง

• ระดับ 3: การร่วมมือของตัวแทนหลายตัว

  มุมมองของหนังสือชัดเจน: อย่าเพียงแต่คิดถึงการสร้าง super agent ที่ทำได้ทุกอย่าง วิธีที่เชื่อถือได้จริงคือการสร้างทีมเหมือนกับการจัดทีมจริง ได้แก่ ตัวแทนผู้จัดการโครงการ + ตัวแทนนักวิจัย + ตัวแทนดีไซเนอร์ + ตัวแทนนักเขียนเนื้อหา ตัวอย่างที่หนังสือยกมาคือการเปิดตัวผลิตภัณฑ์ใหม่: “ตัวแทนผู้จัดการโครงการ” ทำหน้าที่ประสานงานโดยส่งงานให้กับ “ตัวแทนการวิจัยตลาด” “ตัวแทนการออกแบบผลิตภัณฑ์” และ “ตัวแทนการตลาด” จุดสำคัญคือการสื่อสาร: ตัวแทนแต่ละตัวส่งข้อมูลอย่างไร ซิงค์สถานะอย่างไร และจัดการความขัดแย้งอย่างไร บทนี้แสดงโครงสร้างการสื่อสารหกแบบ ตั้งแต่แบบตัวแทนเดียวที่ง่ายที่สุด จนถึงแบบผสมผสานที่ยืดหยุ่นที่สุด โดยอธิบายชัดเจนว่าแต่ละแบบเหมาะกับสถานการณ์ใด

ดูระดับทั้งสี่นี้แล้ว ฉันเข้าใจทันทีว่าทำไมหลายคนจึงพูดว่า “เอเจนต์ของฉันใช้งานไม่ได้” โมเดลไม่มีปัญหา ปัญหาคือคุณกำลังใช้มันเหมือนแชทบอท มันอาจยังไม่ถึงระดับ 1 เลย

Context Engineering: แนวคิดที่ถูกมองข้ามมากที่สุดในหนังสือ

ฉันเคยเขียนบทความเกี่ยวกับ Harness Engineering ซึ่งพูดถึงการออกแบบเส้นทางที่สำคัญกว่าแรงม้าของเครื่องยนต์ หลังจากอ่านหนังสือเล่มนี้ ฉันจึงตระหนักว่า Context Engineering คือการสะท้อนของ Harness Engineering ในระดับ prompt

การสร้างพรอมต์แบบดั้งเดิมสนใจเพียงแค่ “คุณถามอย่างไร” ส่วน Context Engineering ในหนังสือเล่มนี้สนใจสิ่งที่ “เอเจนต์เห็นอยู่หน้าตาอยู่ก่อนที่จะถาม” มันรวมข้อมูลสี่ระดับ:

1. ชั้นแรก ระบบพรอมต์ กำหนดว่า Agent คือใคร ใช้น้ำเสียงแบบไหน และมีขอบเขตอย่างไร ผู้คนส่วนใหญ่เขียนแค่ชั้นนี้เท่านั้น

2. ชั้นที่สอง ข้อมูลภายนอก เอกสารที่ RAG ดึงมา ค่าที่คืนกลับจากการเรียกใช้เครื่องมือ และข้อมูล API แบบเรียลไทม์ นี่คือจุดที่ผู้คนส่วนใหญ่ติดขัด: รู้ว่าต้องป้อนข้อมูล แต่ไม่รู้ว่าจะป้อนอย่างไรจึงจะไม่ทำให้โมเดลจมน้ำ

3. ระดับที่สาม: ข้อมูลแบบนัย ได้แก่ ตัวตนของผู้ใช้ ประวัติการโต้ตอบ และสถานะของสภาพแวดล้อม สิ่งที่คุณไม่ได้ระบุอย่างชัดเจนแต่ Agent ควรรู้ เช่น เมื่อคุณบอก Agent ว่า “ช่วยส่งอีเมลหา John เพื่อยืนยันการประชุมพรุ่งนี้” มันควรรู้ว่าการประชุมในปฏิทินของคุณในวันพรุ่งนี้คืออะไร และคุณมีความสัมพันธ์กับ John อย่างไร

4. ระดับที่สี่ วงจรป้อนกลับ หลังจาก Agent ให้ผลลัพธ์แต่ละครั้ง จะมีการประเมินคุณภาพอัตโนมัติและปรับกลยุทธ์บริบทสำหรับครั้งถัดไป หนังสือเรียกสิ่งนี้ว่า “การปรับปรุงบริบทอัตโนมัติ” และ Google’s Vertex AI Prompt Optimizer เป็นการนำแนวคิดนี้ไปใช้งานจริง

เมื่อฉันอ่านถึงจุดนี้ ฉันนึกถึงบทความก่อนหน้าที่เขียนเรื่อง “ตัวแทน AI ไม่ใช่เวทมนตร์” ซึ่งมีประสบการณ์หนึ่งข้อคือ “ตัวแทนของคุณต้องการกฎเกณฑ์ และต้องการหลายกฎมาก” ตอนนี้กลับมามองอีกครั้ง กฎเหล่านั้นในพื้นฐานแล้วคือเวอร์ชันแบบทำด้วยมือของ Context Engineering หนังสือเล่มนี้ได้ระบบ化进程เหล่านั้นไว้อย่างเป็นระบบ

Reflection: ตัวแทนสองตัวดีกว่าหนึ่งตัว

นี่คือรูปแบบที่มีคุณค่าเชิงปฏิบัติที่สุดสำหรับฉันในหนังสือเล่มนี้

หัวใจของ Reflection นั้นเรียบง่าย: Agent หลังจากทำงานเสร็จแล้วจะตรวจสอบตนเองและแก้ไขข้อผิดพลาดที่พบ แต่วิธีการดำเนินการมีความละเอียดอ่อน หนังสือระบุชัดเจนว่า: Producer และ Critic ต้องใช้ Agent สองตัวที่แตกต่างกัน โดยให้ system prompt ที่ต่างกัน ถ้าใช้ persona เดียวกันในการตรวจสอบผลงานของตนเอง จะมีจุดบอดแน่นอน คุณให้ LLM เดียวกันเขียนโค้ดแล้วตรวจสอบโค้ดที่ตัวเองเขียน มันมีแนวโน้มสูงที่จะตอบว่า “ดีมาก”

The book provides a complete code example.

• คำสั่งของ Producer คือ “คุณเป็นนักพัฒนา Python เขียนฟังก์ชันคำนวณแฟกทอเรียล โดยจัดการเงื่อนไขขอบเขตและข้อผิดพลาด”

• คำสั่งของ Critic คือ “คุณเป็นวิศวกรระดับสูงที่พิจารณาอย่างละเอียด ตรวจสอบโค้ดทีละบรรทัด เพื่อค้นหาบั๊ก รูปแบบการเขียน ข้อกำหนดขอบเขตที่ขาดหายไป และจุดที่สามารถปรับปรุงได้ หากสมบูรณ์แบบให้แสดงผล CODE_IS_PERFECT มิฉะนั้นให้ระบุปัญหาทั้งหมด”

• จากนั้นเป็นลูป for: Producer เขียนโค้ด → Critic ตรวจสอบ → Producer แก้ไขตามข้อเสนอแนะ → Critic ตรวจสอบอีกครั้ง → ทำซ้ำจนกว่า Critic จะระบุ CODE_IS_PERFECT หรือถึงจำนวนครั้งสูงสุดที่กำหนด

ง่ายเพียงเท่านี้ แต่หนังสือเตือนถึงต้นทุนที่มักถูกมองข้าม: ทุกวงจรการสะท้อนคือการเรียกใช้ LLM ครั้งใหม่ ยิ่งมีจำนวนรอบมากเท่าไร ค่าใช้จ่ายก็ยิ่งสูงขึ้น และเมื่อประวัติการสนทนาขยายตัว ช่องบริบทจะถูกเต็มไปด้วยเวอร์ชันก่อนหน้าและความเห็นวิจารณ์ พื้นที่การให้เหตุผลที่ใช้งานได้จริงจึงลดลง ดังนั้น แนวทางปฏิบัติที่ดีที่สุดสำหรับ Reflection คือ: ตั้งจำนวนรอบสูงสุดที่สมเหตุสมผล (หนังสือใช้ค่า 3) เมื่อ Critic พึงพอใจแล้วให้หยุด อย่าไล่หาความสมบูรณ์แบบ

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

Multi-Agent ไม่ได้ยิ่งซับซ้อนยิ่งดี

ฉันชอบมากที่สุดในบทนี้คือแผนผังโทโพโลยีการสื่อสารหกแบบ หลายคนเริ่มต้นด้วยสิ่งที่ซับซ้อน แต่ในความเป็นจริง ส่วนใหญ่สถานการณ์ใช้แค่สามแบบก็เพียงพอ:

1. เอเจนต์เดียว (ทำงานอิสระ): งานสามารถแบ่งเป็นปัญหาย่อยที่ไม่พึ่งพากัน แต่ละเอเจนต์จัดการงานของตัวเองได้ ง่ายและดูแลรักษาง่าย

2. เครือข่ายแบบเพียร์ทูเพียร์ (Peer-to-Peer): ตัวแทนสื่อสารโดยตรงกันโดยไม่มีโหนดควบคุมแบบศูนย์กลาง กระจายศูนย์และมีความทนทานต่อข้อผิดพลาด ตัวแทนหนึ่งตัวล้มลงไม่ส่งผลต่อระบบโดยรวม แต่มีต้นทุนในการประสานงานสูงและอาจเกิดความยุ่งเหยิง

3. ผู้ควบคุม (การจัดการแบบศูนย์กลาง): ตัวแทนผู้ควบคุมหนึ่งตัวดูแลกลุ่มตัวแทนผู้ปฏิบัติงาน จัดสรรงาน รวบรวมผลลัพธ์ และแก้ไขความขัดแย้ง มีโครงสร้างชั้นตอนชัดเจน จัดการได้ง่าย แต่ผู้ควบคุมเป็นจุดล้มเหลวเดียวและเป็นข้อจำกัดด้านประสิทธิภาพ

อีกสามแบบ (Supervisor-as-Tool, แบบเชิงชั้น, และแบบผสมที่กำหนดเอง) เป็นรูปแบบย่อยและการรวมกันของสามแบบแรก หนังสือกล่าวอย่างตรงไปตรงมา: โครงสร้างที่คุณต้องการขึ้นอยู่กับความซับซ้อนของงานของคุณ ยิ่งงานถูกแบ่งย่อยมากเท่าใด ค่าใช้จ่ายในการสื่อสารก็ยิ่งสูงขึ้น จนถึงจุดหนึ่ง รูปแบบ Supervisor จะมีประสิทธิภาพมากกว่ารูปแบบเชิงชั้น

ประสบการณ์ของฉันคือ หลายคนใช้เวลา 80% ไปกับการพัฒนาโปรโตคอลการสื่อสารเมื่อสร้าง Multi-Agent โดยลืมถามคำถามพื้นฐานกว่านั้น: งานนี้จริงๆ แล้วต้องการหลาย Agent หรือไม่? หนังสือเขียนไว้อย่างชัดเจนว่า Level 2 ด้วย Single Agent + Reflection มักเพียงพอแล้ว ส่วน Level 3 ถูกออกแบบมาสำหรับสถานการณ์ที่ Single Agent ไม่สามารถจัดการได้จริง

Memory แบบสามชั้น ฉันรู้สึกได้ถึงมันมาโดยไม่ชัดเจนแต่ยังไม่ได้ตั้งชื่อ

ฉันมีความรู้สึกเชื่อมโยงกับบทนี้มากที่สุด เพราะขณะเขียนบทความสองบทความเกี่ยวกับ Obsidian + Claude ฉันได้ครุ่นคิดเกี่ยวกับคำถามหนึ่งเสมอ: หน่วยความจำของ Agent ควรแบ่งชั้นอย่างไร?

หนังสือให้คำตอบแล้ว:

1. เซสชัน (Session Layer): หน้าต่างบริบทของการสนทนาปัจจุบัน ซึ่งเป็นความจำที่สั้นที่สุด และจะหายไปเมื่อการสนทนาสิ้นสุด โมเดลบริบทยาวแค่ขยายหน้าต่างนี้ออก แต่โดยแก่นแท้ยังคงเป็นชั่วคราว และต้องประมวลผลทั้งหน้าต่างทุกครั้งที่ทำการอนุมาน ทำให้ค่าใช้จ่ายสูงและช้า

2. สถานะ (State): ข้อมูลชั่วคราวระหว่างดำเนินงานในภารกิจปัจจุบัน เช่น “ภารกิจที่กำลังทำคืออะไร” “ทำไปถึงขั้นตอนไหนแล้ว” และ “มีข้อมูลใดเกิดขึ้นระหว่างทาง” ยาวกว่า Session แต่จะถูกลบออกเมื่อภารกิจสิ้นสุด หนังสือใช้กลไก State ของ Google ADK แสดงตัวอย่างอย่างสมบูรณ์

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

ในบทความที่ฉันเขียนเกี่ยวกับ Clawdbot ฉันได้กล่าวถึง “ไฟล์สถานะ” และ “เอกสารพื้นที่ทำงาน” ซึ่งโดยแก่นแท้แล้วคือการสร้างชั้น State และชั้น Memory ด้วยตัวเอง หนังสือเล่มนี้ได้จัดกรอบเรื่องนี้ไว้อย่างเป็นระบบ

สมมติฐานห้าข้อ ข้อที่ห้าแปลกที่สุด

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

ห้าอันที่ทำให้ฉันประหลาดใจ: การเปลี่ยนรูป Multi-Agent

คุณระบุเป้าหมายเท่านั้น เช่น “สร้างธุรกิจอีคอมเมิร์ซขายกาแฟคุณภาพสูง” ระบบจะตัดสินใจอัตโนมัติ: เริ่มด้วยการสร้าง “เอเจนต์วิจัยตลาด” และ “เอเจนต์แบรนด์” หลังจากดำเนินการข้อมูลหนึ่งรอบ ระบบจะตัดสินเองว่าไม่จำเป็นต้องใช้เอเจนต์แบรนด์อีกต่อไป แล้วแยกออกเป็นสามเอเจนต์ใหม่: “เอเจนต์ออกแบบโลโก้”、“เอเจนต์สร้างเว็บไซต์”、“เอเจนต์ซัพพลายเชน” หากเอเจนต์สร้างเว็บไซต์กลายเป็นจุดคอขวด ระบบจะคัดลอกเอเจนต์สามตัวขึ้นมาเพื่อทำงานพร้อมกันในหน้าต่างๆ ที่แตกต่างกัน ตลอดกระบวนการ ระบบจะปรับแต่ง prompt ของแต่ละเอเจนต์อัตโนมัติอย่างต่อเนื่อง และจัดโครงสร้างทีมใหม่อย่างสม่ำเสมอ

หนังสือเรียกสิ่งนี้ว่า “ระบบตัวแทนหลายตัวที่มีเป้าหมายและเปลี่ยนรูปร่างด้วยตนเอง” มันไม่ได้ดำเนินการตามแผนที่คุณเขียนขึ้น แต่กำลังสร้างแผนขึ้นเอง ปรับแผนเอง และจัดทีมดำเนินการใหม่เอง

สิ่งนี้ทำให้ฉันนึกถึง AutoResearch ของ Karpathy: เขียน program.md ที่กำหนดเป้าหมาย ตัวชี้วัด และขอบเขต แล้วกด “เริ่มต้น” มนุษย์อยู่นอกวงจร แต่หนังสือเล่มนี้ขยับไปไกลกว่านั้น: แม้แต่การจัดตั้งและรีจัดองค์กรทีม Agent ก็ให้ระบบตัดสินใจเอง มนุษย์แค่ประกาศว่า “ต้องการอะไร”

สามสิ่งที่สามารถทำได้ทันที

อ่านหนังสือเล่มนี้เสร็จ ฉันมีสามขั้นตอนที่สามารถนำไปปฏิบัติได้ทันที:

• ประการแรก ให้เพิ่ม Critic เข้าไปใน Agent ปัจจุบันของคุณ ไม่ว่าคุณจะใช้ Claude Code, CrewAI หรือเฟรมเวิร์กที่สร้างขึ้นเอง ให้เพิ่มขั้นตอนหนึ่งที่ท้าย workflow ปัจจุบันของคุณ: ให้ Agent อีกตัวหนึ่ง (ใช้ system prompt ที่ต่างกัน) ตรวจสอบผลลัพธ์จากขั้นตอนก่อนหน้า การสร้างโค้ดให้ตรวจสอบโค้ด การเขียนบทความให้ตรวจสอบข้อเท็จจริง การวางแผนให้ประเมินความเป็นไปได้ การเรียกใช้ LLM เพิ่มอีกหนึ่งครั้ง แต่คุณภาพมักจะเพิ่มขึ้นเป็นสองเท่า รูปแบบ Producer-Critic ในหนังสือสามารถใช้งานได้ทันที

• ประการที่สอง เริ่มทำ Context Engineering ไม่ใช่แค่ Prompt Engineering ย้อนกลับไปดูไฟล์คำสั่งที่คุณเขียนให้ Agent หากทั้งหมดเป็นกฎว่า “คุณต้องทำอย่างไร” แต่ขาดบริบทว่า “คุณกำลังเผชิญกับสภาพแวดล้อมอะไรอยู่ตอนนี้” ให้เติมเข้าไป บอก Agent ว่าตอนนี้มันอยู่ในโปรเจกต์ไหน ตัดสินใจอะไรไปแล้วบ้าง และความชอบของผู้ใช้คืออะไร บทเกี่ยวกับ Context Engineering ในหนังสือและ AGENTS.md ของคุณคือการอธิบายเรื่องเดียวกันสองแบบ

• ثالثly อย่ารีบใช้ Multi-Agent ก่อน ให้ปรับแต่ง Single Agent ของคุณให้ถึง Level 2: มีเครื่องมือ มี Reflection และมี Memory หนังสือเน้นย้ำหลายครั้งว่า Single Agent Level 2 ที่เสริมด้วย Producer-Critic และ Context Engineering สามารถครอบคลุมสถานการณ์จริงส่วนใหญ่ได้ Level 3 เป็นสำหรับงานที่ต้องข้ามสาขา หลายขั้นตอน และต้องแบ่งงานแบบขนานเท่านั้น ปัญหาของคนส่วนใหญ่ไม่ใช่ Agent ไม่พอ แต่คือยังปรับแต่ง Agent ตัวเดียวไม่ดีพอ

หนังสือเล่มนี้มี 453 หน้า ตีพิมพ์โดย Springer ปี 2025 ตัวอย่างโค้ดครอบคลุม LangChain/LangGraph, Google ADK, CrewAI, OpenAI API คำนำเขียนโดยรองประธานฝ่ายปัญญาประดิษฐ์ของ Google Cloud และมีคำแนะนำจากหัวหน้าเจ้าหน้าที่การเงินของ Goldman Sachs ซึ่งอ่านแล้วน่าสนใจอย่างไม่คาดคิด

แต่เหตุผลที่ฉันแนะนำมันไม่ใช่เพราะ “ครอบคลุมทุกด้าน” แต่เพราะคุณจะตระหนักหลังจากอ่านจบว่า: ปัญหาที่คุณเคยเจอใน Agent ตลอดหกเดือนที่ผ่านมา ได้มีการจัดระเบียบเป็นรูปแบบเรียบร้อยแล้ว คุณไม่จำเป็นต้องสร้าง Reflection ขึ้นมาใหม่ ไม่ต้องเดาว่า Memory ควรแบ่งชั้นอย่างไร และไม่ต้องทดลองว่า Multi-Agent ควรใช้โทโพโลยีการสื่อสารแบบไหน

มีคนวาดแผนที่ให้คุณแล้ว สิ่งที่เหลือก็แค่เดินไป

คุณกำลังพัฒนาด้วย AI Agent ใช่ไหม? Agent ของคุณตอนนี้อยู่ระดับเท่าไหร่?