โฮสติ้งส่วนใหญ่ถูกออกแบบรอบคนที่นั่งอยู่หน้าคีย์บอร์ด: แบบฟอร์มสมัคร บัตร แดชบอร์ด อีเมลเมื่อมีอะไรผิดพลาด AI agent ที่ต้องการพลังประมวลผลไม่เข้ากับขั้นตอนใดเลย มันแก้ captcha ไม่ได้ แยกหน้าปิดปรับปรุงกับหน้าที่พังไม่ออก และจะไม่สังเกตว่ามันสร้างเซิร์ฟเวอร์เดิมไปแล้วสี่สิบครั้ง
มันน่าจะพูดว่า “แค่ให้ API มันไป” แต่นั่นคือข้อกำหนดแรก ไม่ใช่ข้อสุดท้าย ด้านล่างคือเจ็ดข้อที่เราคิดว่าสำคัญ จากประสบการณ์สร้างเซิร์ฟเวอร์ MCP และ REST API ของเราเองสำหรับเอเจนต์ แต่ละข้อบอกว่า: ถ้าไม่มีแล้วจะเกิดอะไรผิดพลาด
1. ทุกอย่างที่เอเจนต์ต้องการต้องเขียนโปรแกรมสั่งได้
การสร้าง ตรวจสอบ ปรับขนาด และลบทรัพยากรต้องทำได้โดยไม่ใช้เบราว์เซอร์ รวมถึงส่วนที่น่าเบื่อด้วย: รู้ราคาก่อนซื้อ ตรวจว่าโลเคชันมีความจุหรือไม่ อ่านรหัสผ่านของเครื่องใหม่ ยกเลิก
ถ้าไม่มี: เอเจนต์ไปได้ 80% ของทางแล้วติดอยู่ที่ขั้นตอนเดียวที่ต้องคลิก สุดท้ายคนก็ต้องมาทำให้เสร็จอยู่ดี API ที่ไม่ครบมักแย่กว่าไม่มีเลย เพราะมันชวนให้สร้างระบบอัตโนมัติที่ทำไม่จบ
2. ข้อผิดพลาดที่โปรแกรมนำไปดำเนินการต่อได้
เอเจนต์อ่านคำตอบแล้วตัดสินใจว่าจะทำอะไรต่อ เนื้อหา JSON ที่มีรหัสคงที่ (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded พร้อมเวลารีเซ็ต) คือสิ่งที่มันใช้แตกแขนงการตัดสินใจได้ หน้าข้อผิดพลาด HTML หรือ 500 ที่มีข้อความคลุมเครือทำให้มันต้องเดา และมักลองซ้ำในสิ่งที่ไม่มีวันสำเร็จ
ถ้าไม่มี: ลูปการลองซ้ำ ความล้มเหลวที่แพงที่สุดของเอเจนต์มักไม่ใช่การตัดสินใจผิด แต่คือการเรียกที่ล้มเหลวแบบเดิมซ้ำเป็นพัน ๆ ครั้ง
3. การชำระเงินที่ไม่มีคนอยู่ตรงกลาง
การชำระด้วยบัตรเต็มไปด้วยขั้นตอนที่ออกแบบมาเพื่อยืนยันว่ามีคนอยู่: รหัส 3-D Secure การยืนยันในแอปธนาคาร การตรวจสอบตัวตน สิ่งเหล่านี้ดีสำหรับป้องกันการฉ้อโกงแต่ซอฟต์แวร์ทำไม่ได้ ยอดเงินเติมล่วงหน้าที่เติมไว้ก่อน (ในกรณีของเรามักเติมด้วย stablecoin) ทำให้เอเจนต์จ่ายตามที่ใช้ได้โดยไม่ต้องมีคนอนุมัติทุกรายการ
ถ้าไม่มี: หากไม่ให้คนอนุมัติทุกการซื้อ ซึ่งทำให้หมดความหมาย ก็ต้องมีคนยื่นบัตรให้เอเจนต์ ซึ่งเป็นความเสี่ยงที่ไม่ควรมีใครรับ
4. เพดานค่าใช้จ่ายที่เข้มงวด
ยอดเงินเติมล่วงหน้าจำกัดกรณีเลวร้ายที่สุดไว้ที่จำนวนเงินในนั้น ซึ่งก็อาจยังมาก เพดานรายวันและรายเดือนเป็นดอลลาร์ที่แพลตฟอร์มบังคับใช้ ไม่ใช่ความตั้งใจดีของเอเจนต์เอง จะทำให้เอเจนต์ที่ติดลูปกลายเป็นความเสียหายเล็ก ๆ เพดานควรล้มเหลวอย่างชัดเจน ด้วยข้อผิดพลาดที่เอเจนต์จดจำได้ และหยุดหรือพักสิ่งที่กำลังรันอยู่
ถ้าไม่มี: คุณจะรู้เรื่องลูปจากยอดเงิน การคิดเงินของแซนด์บ็อกซ์ ของเรามีเพดานด้วยเหตุผลนี้ และหน้ามาตรการป้องกันของ MCP แนะนำว่าการกระทำใดควรต้องได้รับการอนุมัติจากคนตั้งแต่แรก
5. การประมวลผลในความละเอียดที่เหมาะสม
เอเจนต์สร้างงานสามแบบที่ต่างกันมาก:
- วินาที: รันโค้ดที่สร้างขึ้นสั้น ๆ ตรวจคำตอบ ลองแก้ไข
- ชั่วโมง: การประเมินผล การดึงข้อมูลจากเว็บ บิลด์ที่ยาว
- เปิดตลอดเวลา: บอต API worker ที่รันตามกำหนดเวลา
แพลตฟอร์มที่มีแต่เซิร์ฟเวอร์รายเดือนทำให้งานแบบแรกแพงอย่างไร้เหตุผล แพลตฟอร์มที่มีแต่แซนด์บ็อกซ์อายุสั้นทำให้งานแบบที่สามเปราะบาง งาน 20 วินาทีบนเครื่องที่คิดเงินรายชั่วโมงต้องจ่ายค่าความว่างเปล่า 59 นาที การคิดเงินรายวินาทีทำงานอย่างไร แสดงจุดที่แต่ละโมเดลหมดความคุ้มค่า
ถ้าไม่มี: เอเจนต์จะจ่ายแพงเกินไปสำหรับงานสั้น หรือรันบริการระยะยาวบนโครงสร้างพื้นฐานที่ไม่ได้ออกแบบมาให้เปิดค้างไว้
6. การแยกส่วนเป็นค่าเริ่มต้น
โค้ดที่เอเจนต์เขียนคือโค้ดที่ไม่มีใครรีวิว มันควรรันในที่ที่ไม่มีอะไรมีค่า: ไม่ใช่บนโฮสต์ของเอเจนต์เอง ไม่ใช่เซิร์ฟเวอร์ที่มีคีย์ของคุณ ไม่ใช่เครื่องที่ส่งอีเมลของคุณ ในทางปฏิบัติหมายถึง VM หรือ microVM แยกต่องาน แล้วลบทิ้ง ระดับการแยกส่วนสำหรับโค้ดที่ไม่น่าไว้ใจ เปรียบเทียบตัวเลือก และ อธิบาย Firecracker microVM แบบเข้าใจง่าย อธิบายว่าทำไมเคอร์เนลของตัวเองถึงสำคัญ
ถ้าไม่มี: prompt injection ตัวแรกที่หลุดเข้าไปในโค้ดที่สร้างขึ้น จะเข้าถึงทุกอย่างที่โฮสต์ของเอเจนต์เข้าถึงได้
7. การมองเห็นและสวิตช์ปิด
คนที่รับผิดชอบเอเจนต์ต้องเห็นว่ามันทำอะไรไปและหยุดมันได้อย่างรวดเร็ว นั่นหมายถึงการใช้งานและค่าใช้จ่ายรายทรัพยากร รายการทุกอย่างที่เอเจนต์สร้าง และวิธีลบทั้งหมด ข้อมูลรับรองควรเพิกถอนได้และมีอายุสั้นพอที่ข้อมูลที่รั่วไปจะไม่ใช้ได้ตลอดไป พร้อมวิธีต่ออายุที่ไม่ต้องใช้คน
ถ้าไม่มี: การเก็บกวาดกลายเป็นงานโบราณคดี ทรัพยากรที่ถูกลืมยังคงถูกคิดเงิน โทเค็นที่รั่วไปยังคงใช้งานได้
สิ่งที่เอเจนต์ไม่ต้องการ
สิ่งที่ไม่ช่วยอะไรก็บอกอะไรได้มากไม่แพ้กัน: แดชบอร์ดที่ออกแบบมาเพื่อขายเพิ่ม อีเมลต้อนรับ แพ็กเกจที่ขีดจำกัดจริงอยู่ในเชิงอรรถ ราคาที่แสดงหลังสมัครเท่านั้น ไม่มีอะไรในนี้ที่ซอฟต์แวร์อ่านได้ และบางอย่างยังทำให้โมเดลที่ตีความข้อความตามตัวอักษรเข้าใจผิดอย่างจัง
สิ่งที่ยังแก้ไม่ได้
ไม่ใช่ทุกข้อที่นี่เป็นปัญหาทางวิศวกรรมที่แก้ได้แล้ว
- ความรับผิดชอบ ต้องมีคนรับผิดชอบต่อสิ่งที่เอเจนต์ทำกับบัญชี แพลตฟอร์มต้องมีวิธีผูกกิจกรรมอัตโนมัติเข้ากับผู้รับผิดชอบ โดยไม่บังคับให้คนนั้นต้องผ่านทุกขั้นตอน
- การใช้งานในทางที่ผิด การสมัครแบบเปิดและอัตโนมัติทั้งหมดคือสิ่งที่ผู้ใช้ในทางที่ผิดต้องการเช่นกัน ทุกแพลตฟอร์มที่ให้บริการเอเจนต์กำลังหาสมดุลระหว่างการเข้าถึงที่ไร้แรงเสียดทานกับการสร้างบัญชีจำนวนมากและการขุดเหรียญ และยังไม่มีใครมีคำตอบที่สมบูรณ์
- กระบวนการยาว เอเจนต์ยังล้มเหลวกับกระบวนการสิบขั้นตอนบ่อยกว่าการเรียกครั้งเดียว โครงสร้างพื้นฐานช่วยได้ด้วยการทำให้แต่ละขั้นตอนเป็น idempotent และสอบถามสถานะได้ง่าย เพื่อให้การลองซ้ำทำต่อจากเดิมแทนที่จะทำซ้ำ
จุดที่เรามาถึง
เราพยายามสร้างเพื่อรองรับข้อกำหนดเหล่านี้แทนที่จะเลี่ยงมัน: เซิร์ฟเวอร์ MCP และ REST API ที่ครอบคลุมวงจรชีวิตทั้งหมด ข้อผิดพลาดที่เครื่องอ่านได้ ยอดเงินเติมล่วงหน้า เพดานค่าใช้จ่าย แซนด์บ็อกซ์สำหรับโค้ด แบบรายวินาทีสำหรับงานสั้น และเซิร์ฟเวอร์รายเดือนอย่างแพ็กเกจ AI agent สำหรับงานระยะยาว ภาพรวมฝั่งแซนด์บ็อกซ์อยู่ในแซนด์บ็อกซ์สำหรับ AI agent เราอยากให้คุณตัดสินรายการนี้จากคุณค่าของมันเอง มันเป็นเช็กลิสต์ที่มีประโยชน์สำหรับทุกแพลตฟอร์มที่คุณปล่อยให้เอเจนต์ทำงาน
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ