โครงสร้างพื้นฐานเอเจนต์และแบ็กเอนด์ใหม่

เรามักจะพูดถึงเฟรมเวิร์กเอเจนต์ LangGraph, CrewAI, AutoGen, SDK ต่างๆ, ลูป, การเรียกใช้เครื่องมือ, หน่วยความจำ, ผู้วางแผน, นักวิจารณ์, หัวหน้างาน ถ้อยคำที่เป็นประโยชน์ทั้งสิ้นเพื่อความดี แต่ยิ่งฉันดูตัวแทนที่ใช้งานจริงมากเท่าไร สำหรับฉันก็ยิ่งดูเหมือนว่าส่วนที่น่าสนใจได้เคลื่อนไปต่ำกว่าระดับเฟรมเวิร์กมากขึ้นเท่านั้น

คำถามไม่ได้เป็นเพียงอีกต่อไป: ฉันต้องใช้ไลบรารีใดเพื่อทำให้โมเดลขั้นตอนคิด?

คำถามที่แท้จริงคือ: ตัวแทนรายนี้จะอาศัยอยู่ที่ไหนเมื่อเขาหยุดเป็นบัญชีทดลอง?

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

โครงเป็นพวงมาลัย โครงสร้างพื้นฐานได้แก่ ถนน เบรก ที่จอดรถ ประกันภัย และบุคคลที่รู้ว่ากุญแจอยู่ที่ไหน

เพราะตอนนี้มีคนพูดถึงกันเยอะมาก

ในปี 2023 และ 2024 การสนทนาเน้นโมเดลเป็นหลัก LLM ใด? มีบริบทมากแค่ไหน? มีค่าใช้จ่ายเท่าไร? เขาเก่งการเขียนโปรแกรมแค่ไหน?

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

เป็นการเปลี่ยนแปลงตามธรรมชาติจากเวทมนตร์ไปสู่วิศวกรรม

เมื่อตัวแทนเพียงต้องการสร้างการตอบกลับ การแชทก็เพียงพอแล้ว เมื่อคุณต้องการเปิดคำขอดึง สืบค้นฐานข้อมูล เรียก CRM เริ่มงาน นำทางไซต์ อ่าน Slack คอมไพล์โค้ด และอัปเดตเอกสาร คุณต้องมีระบบปฏิบัติการล้อมรอบ

ไม่ใช่ในความหมายที่แท้จริง ในแง่องค์กร

ชิ้นแรก: รันไทม์ที่ตัวแทนสามารถคงอยู่ได้

ตัวแทนมักจะทำงานเป็นขั้นตอน ดูสถานะ เลือกการกระทำ ใช้เครื่องมือ สังเกตผลลัพธ์ ปรับปรุงแผน ทำซ้ำ

หากการวนซ้ำนี้อยู่ในคำขอ HTTP เดียว คุณจะประสบปัญหาทันที การกระทำบางอย่างช้า บางส่วนกำลังรอข้อมูลจากมนุษย์ บางอย่างล้มเหลวและต้องลองอีกครั้ง บางส่วนต้องคงอยู่หลังจากการปรับใช้หรือการหมดเวลา

นี่คือจุดที่เวิร์กโฟลว์ คิว ​​พื้นหลังงาน และสถานะแมชชีนที่คงทนเข้ามามีบทบาท พวกเขาไม่ได้มีเสน่ห์ แต่เป็นความแตกต่างระหว่างตัวแทนที่ดูฉลาดในการสาธิตกับตัวแทนที่คุณสามารถออกจากงานไปดื่มกาแฟได้

สำหรับฉันรันไทม์แบบตัวแทนต้องตอบคำถามที่เป็นรูปธรรมมาก:

• ฉันจะบันทึกสถานะระหว่างขั้นตอนหนึ่งไปอีกขั้นได้ที่ไหน
• จะเกิดอะไรขึ้นหากกระบวนการนี้หยุดทำงานกลางคัน?
• ฉันสามารถหยุดและขออนุมัติได้หรือไม่?
• ฉันสามารถเล่นซ้ำการวิ่งเพื่อทำความเข้าใจว่าทำไมเขาถึงเลือกเช่นนั้นได้หรือไม่
• ฉันสามารถจำกัดระยะเวลา หน่วยความจำ เครื่องมือ และค่าใช้จ่ายได้หรือไม่

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

ชิ้นที่สอง: กระบะทราย เพราะตัวแทนจะต้องสามารถสกปรกได้โดยไม่แตกหัก

ทันทีที่ตัวแทนเขียนโค้ดหรือดำเนินการคำสั่ง จำเป็นต้องมีแซนด์บ็อกซ์

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

แซนด์บ็อกซ์แบบตัวแทนควรมีคุณสมบัติบางประการ:

• ระบบไฟล์แบบแยกส่วน
• CPU หน่วยความจำ และการจำกัดเวลา
• เครือข่ายควบคุม
• ความลับจะถูกติดตั้งเมื่อจำเป็นเท่านั้น
• บันทึกที่สมบูรณ์
• ความเป็นไปได้ในการส่งออกสิ่งประดิษฐ์
• ล้างการรีเซ็ตระหว่างการรันเมื่อจำเป็น

Vercel Sandbox ดำเนินไปในทิศทางนี้ทุกประการ: สภาพแวดล้อมที่แยกออกมาเพื่อรันโค้ด ติดตั้งการขึ้นต่อกัน ทำงานกับไฟล์ และสร้างอาร์ติแฟกต์โดยไม่ต้องรันทุกอย่างในรันไทม์ของแอปพลิเคชันหลัก

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

แซนด์บ็อกซ์เป็นวิธีสำหรับผู้ใหญ่ในการพูดว่า: เอาเลย แต่อยู่ตรงนี้

ชิ้นที่สาม: ปัญหา MCP และตัวเชื่อมต่อ

Model Context Protocol ได้กลายเป็นหนึ่งในส่วนที่น่าสนใจที่สุดของระบบนิเวศ เนื่องจากพยายามสร้างมาตรฐานให้กับบางสิ่งที่ไม่สามารถจัดการได้อย่างรวดเร็ว: วิธีที่โมเดลค้นพบและใช้เครื่องมือภายนอก

หากไม่มีมาตรฐาน แต่ละการบูรณาการก็เป็นเพียงเกาะเล็กๆ ตัวเชื่อมต่อสำหรับ GitHub ทำได้อย่างหนึ่ง อย่างหนึ่งสำหรับ Slack อีกอย่างหนึ่ง อย่างหนึ่งสำหรับฐานข้อมูลที่มีความหมายต่างกัน อีกอย่างหนึ่งสำหรับเบราว์เซอร์อัตโนมัติที่ดูเหมือนไม่มีอะไรเลย

MCP เสนอภาษากลางระหว่างไคลเอนต์และเซิร์ฟเวอร์: เครื่องมือ ทรัพยากร ข้อความแจ้ง การอนุญาต การขนส่ง การค้นพบ มันไม่ได้แก้ปัญหาการกำกับดูแลและความปลอดภัยอย่างน่าอัศจรรย์ แต่ให้ไวยากรณ์

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

สำหรับฉัน MCP ไม่ใช่โฆษณาเกินจริงเพราะมัน "ทำการเรียกเครื่องมือ" เราทำอย่างนั้นแล้ว เป็นเรื่องฮือฮาเพราะมันเปลี่ยนจุดศูนย์ถ่วงจากการบูรณาการแบบเดี่ยวไปสู่แค็ตตาล็อกการปฏิบัติงานของเครื่องมือ

ในสถาปัตยกรรมเอเจนต์ที่ดี MCP จะกลายเป็นแผงแพทช์:

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

ส่วนที่ยุ่งยากก็คือแค็ตตาล็อกเครื่องมือที่ไม่มีนโยบายเป็นเพียงวิธีที่หรูหรากว่าในการสร้างความสับสนวุ่นวาย

ชิ้นที่สี่: ข้อมูลประจำตัวและการอนุญาต

นี่คือพื้นที่ที่การสาธิตจำนวนมากเมินเฉย

ตัวแทนกระทำการในนามของบุคคลอื่น ดังนั้นจึงต้องชัดเจนว่าใครเป็นเป้าหมายของการดำเนินการ

มันใช้สิทธิ์ของผู้ใช้หรือไม่? ของบัญชีบริการ? ของพื้นที่ทำงาน? คุณมีสิทธิ์เข้าถึงชั่วคราวหรือถาวรหรือไม่? คุณสามารถอ่านทุกอย่างหรือเพียงแหล่งข้อมูลบางส่วนได้หรือไม่? คุณเขียนได้ไหม? ยกเลิกได้ไหม? เขาส่งข้อความหาคนจริงๆ ได้ไหม?

หากคุณตอบคำถามเหล่านี้ได้ไม่ดี ไม่ช้าก็เร็ว คุณจะสร้างผู้ช่วยที่มีกุญแจบ้านและไม่มีความทรงจำว่าใครเป็นคนมอบกุญแจให้เขา

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

ซึ่งหมายความว่า OAuth, ขอบเขตโทเค็น, การจัดการข้อมูลลับ, บันทึกการตรวจสอบ, นโยบายเครื่องมือ, รายการที่อนุญาต, ขั้นตอนการอนุมัติ ไม่ค่อยโรแมนติกเท่าไหร่ สิ่งที่จำเป็น

ชิ้นที่ห้า: ความทรงจำและบริบท แต่ไม่สะสมขยะ

เจ้าหน้าที่จำเป็นต้องมีความทรงจำ แต่ความทรงจำนั้นอันตรายเมื่อมันกลายเป็นห้องใต้หลังคา

หน่วยความจำมีอย่างน้อยสามประเภท:

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

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

ตัวแทนที่จำไม่ดี แย่กว่าตัวแทนที่จำไม่ได้ เพราะเขาพูดด้วยความมั่นใจ

ดังนั้นโครงสร้างพื้นฐานจึงต้องรวมถึงการดึงข้อมูล ไฟล์คำสั่ง ฐานความรู้ การฝังเมื่อจำเป็น แต่ยังรวมถึงการทำความสะอาดด้วย เราต้องการวัฒนธรรมแห่งความทรงจำ อะไรเข้ามา ใครเห็นชอบ เมื่อมันเสื่อมสลายไป ฉันจะแก้ไขมันได้อย่างไร

ชิ้นที่หก: การสังเกต การประเมิน และการเล่นซ้ำ

หากตัวแทนทำผิดพลาด บันทึก "ที่เรียกว่าโมเดล" ยังไม่เพียงพอ

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

ในที่นี้ตัวแทนเป็นเหมือนระบบแบบกระจายมากกว่าแชทบอท

คุณต้องมีการติดตามที่อ่านได้ ไม่ใช่แค่บันทึกข้อความ คุณต้องสามารถเล่นซ้ำการวิ่งได้ จำเป็นต้องเปรียบเทียบเอเจนต์เดียวกันสองเวอร์ชันกับงานที่ทราบ เราจำเป็นต้องวัดการถดถอย ไม่เพียงแต่ "ตอบได้ดีขึ้น" เท่านั้น แต่ยัง "ปิดตั๋วที่ถูกต้องโดยไม่ต้องสัมผัสไฟล์ที่ไม่พึงประสงค์"

การประเมินแบบตัวแทนนั้นยากกว่าการประเมินแบบข้อความ เนื่องจากมีการดำเนินการด้วย การเปรียบเทียบสตริงที่คาดหวังนั้นไม่เพียงพอ คุณต้องดูลำดับ ผลข้างเคียง คุณภาพของสิ่งประดิษฐ์ เวลา ต้นทุน จำนวนการแทรกแซงของมนุษย์

สิ่งที่ตลกคือเรามักจะกลับมาที่นั่นเสมอ: วิศวกรรมซอฟต์แวร์ การทดสอบ สภาพแวดล้อม การติดตาม การย้อนกลับ ยกเว้นว่าตอนนี้โค้ดยังตัดสินใจว่าจะทำอะไรต่อไป

ชิ้นที่เจ็ด: ส่วนต่อประสานของมนุษย์

ตัวแทนไม่จำเป็นต้องอยู่แค่ในแชทเท่านั้น

ตัวแทนบางคนจำเป็นต้องมีบอร์ด เพจอื่นๆ ที่มีสถานะและบันทึก อื่นๆ ของปุ่ม "อนุมัติ" More inline comments. ยังมี CLI อื่นๆ อีก

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

โครงสร้างพื้นฐานของเอเจนต์ที่เหมาะสมประกอบด้วยพื้นผิวการควบคุม:

• สถานะปัจจุบัน
• แผนแก้ไขได้
• ผลิตสิ่งประดิษฐ์
• ความแตกต่าง;
• คำขออนุมัติ
• ลำดับเหตุการณ์;
• ปุ่มหยุด;
• ปุ่มลองอีกครั้ง;
• สิทธิ์ที่มองเห็นได้

It seems trivial, but it isn't. ความแตกต่างระหว่าง "AI ที่น่าขนลุก" และ "ผู้ช่วยที่เชื่อถือได้" มักจะเป็นเพียงส่วนหลังที่แสดงให้คุณเห็นว่ามันอยู่ในมือตรงไหน

กองจิต

ถ้าผมจะวาดมันวันนี้ จำนวนตัวแทนขั้นต่ำจะเป็นดังนี้:

1. โมเดล: การใช้เหตุผล การสร้าง การเรียกใช้เครื่องมือ ต่อเนื่องหลายรูปแบบ หากจำเป็น
2. การเรียบเรียง: วนซ้ำ ขั้นตอน ผู้วางแผน นโยบาย มนุษย์ในวง
3. รันไทม์ที่คงทน: เวิร์กโฟลว์ คิว ​​ลองใหม่ หยุดชั่วคราว ดำเนินการต่อ
4. Sandbox: code execution, isolated file system, limitations, artifacts.
5. เลเยอร์เครื่องมือ: MCP, API ภายใน, เบราว์เซอร์, ฐานข้อมูล, พื้นที่เก็บข้อมูล
6. ชั้นข้อมูลประจำตัว: OAuth ขอบเขต ความลับ การตรวจสอบ นโยบาย
7. ชั้นหน่วยความจำ: บริบทของโปรเจ็กต์ การดึงข้อมูล คำแนะนำ การหมดอายุ
8. ความสามารถในการสังเกต: ติดตาม เล่นซ้ำ ประเมิน ต้นทุน และตัวชี้วัดคุณภาพ
9. พื้นผิวของผลิตภัณฑ์: แชทเมื่อเพียงพอ แดชบอร์ดเมื่อจำเป็น ตรวจสอบเมื่อมีความสำคัญ

Agentic Framework ครอบคลุมจุดที่ 2 และจุดที่ 1 เป็นหลัก ส่วนที่เหลือเป็นงานจริง

สิ่งที่ผมจะทำในทางปฏิบัติ

หากทีมบอกฉันว่า “เราต้องการตัวแทนในการผลิต” ฉันจะไม่เริ่มต้นด้วยตัวแทนสิบคน

ฉันจะเริ่มต้นด้วยขั้นตอนการทำงานเล็กๆ ซ้ำๆ และสังเกตได้ ตัวอย่างเช่น: ประชาสัมพันธ์การบำรุงรักษาแบบเปิด อัปเดตเอกสารจากปัญหาที่ปิดไปแล้ว เตรียมการตรวจสอบรายสัปดาห์ คัดแยกข้อบกพร่องที่ซ้ำกัน สร้างการทดสอบสำหรับไฟล์ที่ได้รับผลกระทบ

จากนั้นฉันจะกำหนดขอบเขตที่ชัดเจนมาก:

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

เมื่อนั้นฉันก็จะขยาย

เจ้าหน้าที่ไม่ได้ล้มเหลวเพียงเพราะโมเดลเข้าใจผิด พวกเขาล้มเหลวเพราะเราวางมันไว้ในสภาพแวดล้อมที่คลุมเครือ พร้อมด้วยสิทธิ์ที่ทำให้เกิดความสับสนและความคาดหวังในการแสดงละคร

การอ่านของฉัน

โครงสร้างพื้นฐานเอเจนต์น่าเบื่อในวิธีที่ดีที่สุด

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

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

นั่นคือสิ่งที่ตัวแทนเลิกเป็นของเล่นและกลายเป็นโครงสร้างพื้นฐาน

แหล่งที่มา

• Vercel: วิธีสร้างตัวแทน AI ด้วย Vercel และ AI SDK
• เอกสาร Vercel: แซนด์บ็อกซ์
• Vercel Docs: การทำงานกับ Sandbox
• เอกสาร Vercel: MCP
• Model Context Protocol: ข้อมูลจำเพาะ
• OpenAI: เครื่องมือใหม่สำหรับตัวแทนการสร้าง
• บล็อก Cloudflare: ตัวแทนบน Cloudflare