deploying-scalable-agents

การปรับใช้เอเจนต์ที่ปรับขนาดได้ด้วย Microsoft Foundry

ทักษะเสริมสำหรับ บทที่ 16 – การปรับใช้เอเจนต์ที่ปรับขนาดได้ ใช้เพื่อช่วยผู้เรียนในการย้ายเอเจนต์จากต้นแบบไปสู่การปรับใช้ในสเกลการผลิตที่สังเกตได้ อิงทุกคำแนะนำจากเนื้อหาบทเรียนและสมุดบันทึกที่ใช้งานได้; อย่าสร้าง API ของ Foundry ขึ้นเอง

ทริกเกอร์

เปิดใช้ทักษะนี้เมื่อผู้เรียนต้องการ:

• ปรับใช้เอเจนต์ไปยัง Microsoft Foundry ในฐานะ เอเจนต์ที่โฮสต์ และทำให้เป็นเวอร์ชัน/สังเกตได้
• เลือกระหว่างรูปแบบการปรับใช้ โฮสต์ที่ไคลเอนต์, เอเจนต์ที่โฮสต์, และเวิร์กโฟลว์เอเจนต์
• เพิ่ม การกำหนดเส้นทางโมเดล, การแคชชิ่งการตอบกลับ, หรือ การจำกัดความพร้อมใช้งานพร้อมกัน เพื่อควบคุมความหน่วงและค่าใช้จ่าย
• เพิ่ม เกตประเมินผล เพื่อป้องกันไม่ให้เวอร์ชันเอเจนต์ที่ไม่ดีถูกปรับใช้
• เพิ่มขั้นตอน การอนุมัติจากมนุษย์ในลูป สำหรับการดำเนินการที่มีความเสี่ยงสูง
• ติดตั้งเครื่องมือเอเจนต์ด้วย OpenTelemetry สำหรับการสังเกตการณ์ในสภาพแวดล้อมการผลิต
• ทดสอบอย่างรวดเร็ว (Smoke-test) เอเจนต์ที่ปรับใช้เป็นเกตหลังการปรับใช้ที่รวดเร็ว

แบบจำลองจิตหลัก

เอเจนต์ในสภาพแวดล้อมการผลิตส่วนใหญ่คือโครงสร้างปฏิบัติการ รอบๆ โมเดล (~80%) ไม่ใช่โมเดลเอง แผนที่ทุกคำแนะนำไปยังข้อกังวลเหล่านี้:

ข้อกังวล	ต้นแบบ → การผลิต
โฮสติ้ง	สมุดบันทึก → บริการที่โฮสต์แบบมีเวอร์ชัน
ตัวตน	az login ของคุณ → ตัวตนที่จัดการ + RBAC ช่วงสโคป
สถานะ	ในหน่วยความจำ → ที่เก็บเธรด/หน่วยความจำภายนอก
ความล้มเหลว	การเปลี่ยนแปลงย้อนกลับ → การลองใหม่, ทางเลือก, การแจ้งเตือน
ค่าใช้จ่าย	"ไม่กี่เซนต์" → ติดตาม, กำหนดเส้นทาง, แคช, งบประมาณ
คุณภาพ	การตรวจสอบด้วยตาเปล่า → เกตประเมินอัตโนมัติ
ความน่าเชื่อถือ	คุณอนุมัติ → นโยบาย + การมีมนุษย์ในลูป

รูปแบบการปรับใช้ (เลือกอย่างใดอย่างหนึ่ง หรือผสมผสาน)

1. โฮสต์ที่ไคลเอนต์ — ลูปเหตุผลทำงานในกระบวนการของคุณ ควบคุมสูงสุด; คุณเป็นเจ้าของการปรับขนาด/สถานะ
2. เอเจนต์ที่โฮสต์ (Foundry Agent Service) — Foundry โฮสต์ลูป, เก็บเธรด, บังคับใช้ RBAC/ความปลอดภัยเนื้อหา, แสดงเอเจนต์ในพอร์ทัล ควบคุมน้อยลง, พื้นที่ปฏิบัติการน้อยมาก
3. เวิร์กโฟลว์เอเจนต์ — เอเจนต์/เครื่องมือหลายตัวประกอบเป็นกราฟพร้อมการแตกแขนง, โหนดอนุมัติ, และจุดตรวจสอบที่ทนทาน

วงจรชีวิต (ลูปที่ส่งมอบเอเจนต์)

create → version → evaluate (gate) → deploy hosted → observe online → collect failures → repeat. การประเมินแบบออฟไลน์คือเกต ไม่ใช่การคิดย้อนหลัง — เวอร์ชันจะไม่ถูกส่งกว่าถ้าไม่ผ่านเกณฑ์นี้ ข้อมูลการสังเกตแบบออนไลน์จะย้อนกลับความล้มเหลวจริงไปยังชุดทดสอบออฟไลน์

คันโยกการปรับขนาดและค่าใช้จ่าย (ตามลำดับความสำคัญ)

1. ปรับขนาดโมเดลให้เหมาะสม — ใช้โมเดลที่เล็กที่สุดที่ผ่านเกตประเมินผล
2. กำหนดเส้นทางตามความซับซ้อน — โมเดลขนาดเล็ก/เร็วสำหรับคำขอเรียบง่าย, โมเดลขนาดใหญ่สำหรับการเหตุผลจริง (ตัวจัดประเภท DIY หรือ Foundry Model Router)
3. แคช — ให้บริการคำขอที่เหมือนกันเกือบทั้งหมดโดยไม่ต้องเรียกโมเดล
4. ออกแบบแบบไม่มีสถานะ + จำกัดความพร้อมใช้งานพร้อมกัน — แยกสถานะออก; ลองใหม่ด้วยการหน่วงเวลา

รูปแบบหลักที่ต้องทำซ้ำ

ชี้ผู้เรียนไปที่เหล่านี้จากสมุดบันทึก 16-python-agent-framework.ipynb:

• ตัวจัดการคำขอ: แคช → กำหนดเส้นทางตามความซับซ้อน → ติดตามช่วง → รัน → แคช
• เกตประเมินผล: ให้คะแนนชุดทดสอบออฟไลน์; คืนค่า pass_rate >= threshold และปรับใช้เฉพาะเมื่อเป็นจริง
• การอนุมัติจากมนุษย์: @tool(approval_mode="always_require") สำหรับการกระทำเช่นการคืนเงินจำนวนมาก
• การติดตาม: ห่อแต่ละคำขอด้วย tracer.start_as_current_span(...) และตั้งแอตทริบิวต์เช่น routed.model, customer.id

การทดสอบเบื้องต้นกับเอเยนต์ที่ถูกติดตั้ง

หลังติดตั้ง ให้ตรวจสอบว่า endpoint ตอบสนองจริง (การ deploy สีเขียวยังอาจเป็น เงียบอยู่) ใช้การทำงาน AI Smoke Test ผ่าน .github/workflows/smoke-test.yml กับแคตาล็อกใน tests/ ตัว runner จะส่ง POST แต่ละ prompt ไปที่ POST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responses และตรวจสอบข้อความตอบกลับ ตัวตนต้องมีบทบาท Azure AI User ในขอบเขต โครงการ Foundry; โทเค็นต้องมี audience เป็น https://ai.azure.com/

วางชั้นของเกท: smoke test (เข้าถึง/ตอบสนองได้, ทุกการ deploy) → offline evaluation (กำหนดว่าพร้อมส่งหรือไม่, ก่อนเลื่อนระดับ) → online evaluation (ทำงาน อย่างไรในสถานการณ์จริง, ต่อเนื่อง)

การควบคุมสำหรับองค์กร

• RBAC: ให้แต่ละเอเยนต์ที่โฮสต์มี managed identity กับสิทธิ์น้อยที่สุด
• MCP ในสภาพแวดล้อมการผลิต: ถือว่าเซิร์ฟเวอร์ MCP ทุกเครื่องเป็นเขตแดนที่ไม่น่าเชื่อถือ — ติดเวอร์ชัน, กำหนดขอบเขตตัวตน, ตรวจสอบผลลัพธ์, จำกัดอัตรา, ห้ามเปิดเผยความลับ

แนวทางสำหรับผู้ช่วย

• ควรใช้รูปแบบ FoundryChatClient(...) + provider.as_agent(...) ที่เป็นมาตรฐานที่ใช้ในหลักสูตร
• อย่าสัญญาผลลัพธ์สดจาก Azure ที่คุณยังไม่ยืนยัน; แนะนำใช้ workflow smoke-test เพื่อยืนยันการติดตั้ง
• รักษาการประเมินผลและคำแนะนำค่าใช้จ่ายให้สัมพันธ์กัน: การประเมินกำหนดคุณภาพขั้นต่ำ, การจัดเส้นทาง/แคชช่วยรักษาต้นทุนให้อยู่ใกล้ค่านั้น

---

<!-- CO-OP TRANSLATOR DISCLAIMER START --> ปฏิเสธความรับผิดชอบ: เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษา AI Co-op Translator ขณะที่เราพยายามให้ความถูกต้อง โปรดทราบว่าการแปลโดยอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาต้นทางควรถูกพิจารณาเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ แนะนำให้ใช้การแปลโดยมนุษย์มืออาชีพ เราไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความที่ผิดพลาดที่เกิดขึ้นจากการใช้การแปลนี้ <!-- CO-OP TRANSLATOR DISCLAIMER END -->