ai-agents-for-beginners

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

Deploying Scalable Agents

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

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

บทนำ

บทเรียนนี้จะครอบคลุม:

เป้าหมายการเรียนรู้

หลังจากทำบทเรียนนี้เสร็จ คุณจะรู้วิธี:

สิ่งที่ต้องมีพื้นฐานมาก่อน

บทเรียนนี้สมมติว่าคุณได้ทำบทเรียนก่อนหน้าและคุ้นเคยกับ:

คุณจะต้องมี:

จากต้นแบบสู่การผลิต: สิ่งที่เปลี่ยนแปลงจริงๆ

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

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

จดจำตารางนี้ไว้ ส่วนแต่ละส่วนด้านล่างจะเกี่ยวข้องกับแถวในตารางนี้

รูปแบบการปรับใช้เอเจนต์

มีสามรูปแบบที่คุณจะใช้ มักใช้รวมกัน

1. เอเจนต์โฮสต์โดยลูกค้า

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

2. Hosted Agents (Foundry Agent Service)

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

3. กระบวนงานของเอเจนต์

เอเจนต์หลายตัว (และเครื่องมือ) รวมกันเป็นกราฟที่มีการควบคุมการไหลชัดเจน — ขั้นตอนต่อเนื่อง, การแยกทางเลือก, โหนดอนุมัติจากมนุษย์, และจุดตรวจสอบทนทานที่สามารถหยุดและทำงานต่อได้ นี่คือความสามารถของ Microsoft Agent Framework Workflows ที่ใช้ในระดับการปรับใช้

flowchart TB
    subgraph P1[Client-Hosted]
        A1[Your App Process] --> M1[Model Provider]
    end
    subgraph P2[Hosted Agent]
        A2[Thin Client] --> F2[Foundry Agent Service]
        F2 --> M2[Model + Tools + Thread Store]
    end
    subgraph P3[Agent Workflow]
        A3[Orchestrator] --> S1[Triage Agent]
        S1 --> S2[Resolver Agent]
        S2 --> H[Human Approval Node]
        H --> S3[Action Agent]
    end

วงจรชีวิตของเอเจนต์บน Microsoft Foundry

การปรับใช้เอเจนต์ไม่ใช่การดำเนินการครั้งเดียว push แต่มันคือวัฏจักร และดูคล้ายกับวงจรการปล่อยซอฟต์แวร์เพราะนั่นคือสิ่งที่มันเป็น

flowchart LR
    Create[Create / Author] --> Version[Version]
    Version --> Evaluate[Evaluate offline]
    Evaluate -->|passes gate| Deploy[Deploy hosted]
    Evaluate -->|fails gate| Create
    Deploy --> Observe[Observe online]
    Observe --> Improve[Collect failures]
    Improve --> Create
    Deploy --> Retire[Retire old version]

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

กลยุทธ์การปรับขนาด

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

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

การส่งเส้นทางโมเดล ไม่ใช่ทุกคำขอต้องใช้โมเดลที่มีประสิทธิภาพที่สุด (และแพงที่สุด) ส่งคำขอที่ง่าย — การจำแนกเจตนา ตอบคำถามข้อเท็จจริงสั้น ๆ — ไปยังโมเดลเล็กและรวดเร็ว และสงวนโมเดลใหญ่ไว้สำหรับการใช้เหตุผลจริง ๆ Foundry’s Model Router สามารถทำสิ่งนี้ให้คุณ หรือคุณสามารถสร้างตัวจำแนกน้ำหนักเบาเอง คุณจะสร้างเวอร์ชัน DIY ในห้องปฏิบัติการ

การแคชการตอบกลับ คำถามสนับสนุนหลายคำถามเป็นคำถามซ้ำ (“ฉันจะรีเซ็ตรหัสผ่านได้อย่างไร?”) แคชคำตอบสำหรับคำถามที่พบบ่อยและให้คำตอบโดยไม่ต้องเรียกใช้โมเดลเลยแม้แต่น้อย แม้แต่การแคชที่ถือว่าไม่มากก็ช่วยลดค่าใช้จ่ายและความล่าช้าได้อย่างมีนัยสำคัญ

ความขนานและแรงกดดันย้อนกลับ ผู้ให้บริการโมเดลมีข้อจำกัดอัตราการเรียก คืนค่า concurrency ของคุณ ใช้การลองใหม่แบบ Backoff แบบทวีคูณ และล้มเหลวอย่างนุ่มนวล (การตอบสนองคิวแบบ “เรากำลังดำเนินการ” ดีกว่าข้อผิดพลาด 500)

flowchart LR
    Q[User query] --> C{Cache hit?}
    C -->|yes| R[Return cached answer]
    C -->|no| Router{Complexity?}
    Router -->|simple| SLM[Small model]
    Router -->|complex| LLM[Large model]
    SLM --> Out[Response]
    LLM --> Out
    Out --> Store[Cache + trace]

การสังเกตการณ์ในสภาพแวดล้อมการผลิต

คุณไม่สามารถดำเนินการสิ่งที่คุณมองไม่เห็น ดังที่อธิบายในบทเรียน 10 Microsoft Agent Framework ส่งออก OpenTelemetry traces โดยตรง — ทุกการเรียกโมเดล เรียกใช้เครื่องมือ และขั้นตอนการจัดการกลายเป็น span ในสภาพแวดล้อมการผลิต คุณส่งออก spans เหล่านั้นไปยัง Microsoft Foundry (หรือแบ็คเอนด์ที่รองรับ OTel ใด ๆ) เพื่อที่คุณจะได้:

from agent_framework.observability import get_tracer

tracer = get_tracer()

with tracer.start_as_current_span("support_request") as span:
    span.set_attribute("customer.tier", "enterprise")
    span.set_attribute("routed.model", "gpt-5-nano")
    # agent execution is traced automatically inside this span

คุณลักษณะเช่น customer.tier และ routed.model คือสิ่งที่เปลี่ยนแผงของ traces ให้กลายเป็นคำถามที่ตอบได้ (“ลูกค้าองค์กรถูกส่งไปโมเดลเล็กบ่อยเกินไปหรือไม่?”)

การเพิ่มประสิทธิภาพค่าใช้จ่าย

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

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

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

ข้อพิจารณาสำหรับการปรับใช้ในองค์กร

การกำกับดูแล Hosted Agents สืบทอด RBAC, ความปลอดภัยของเนื้อหา และการบันทึกการตรวจสอบของ Foundry มอบตัวตนที่จัดการให้เอเจนต์แต่ละตัว ด้วยสิทธิ์น้อยที่สุดที่ต้องการ — อ่านฐานความรู้ได้อย่างเดียว เข้าถึง API ตั๋วได้ในขอบเขตที่กำหนด ไม่เกินกว่านี้

มนุษย์ในวงจร การกระทำบางอย่างมีความสำคัญมากเกินกว่าที่จะทำแบบอัตโนมัติโดยตรง — การคืนเงิน การลบบัญชี การยกระดับไปยังทีมกฎหมาย Microsoft Agent Framework รองรับเครื่องมือที่ต้อง อนุมัติ: เอเจนต์เสนอการกระทำ หยุดการดำเนินการ รอการอนุมัติหรือปฏิเสธจากมนุษย์ แล้วกระบวนงานดำเนินต่อ คุณเห็นสิ่งนี้เป็นพื้นฐานใน บทเรียน 6; ที่นี่คุณปรับใช้มัน

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

flowchart TB
    subgraph Dev[Development Architecture]
        D1[Notebook] --> D2[Agent Framework]
        D2 --> D3[Model Provider]
        D2 --> D4[Local tools]
    end
    subgraph Deploy[Deployment Architecture]
        E1[CI pipeline] --> E2[Evaluation gate]
        E2 -->|pass| E3[Foundry Agent Service]
        E3 --> E4[Versioned hosted agent]
    end
    subgraph Run[Runtime Architecture]
        F1[Client app] --> F2[Hosted agent]
        F2 --> F3[Model Router]
        F2 --> F4[Azure AI Search RAG]
        F2 --> F5[Memory service]
        F2 --> F6[MCP tools]
        F2 --> F7[OTel -> Foundry tracing]
        F2 --> F8[Human approval]
    end

แผนภาพสามอันนั้น — การพัฒนา การปรับใช้ และการรันไทม์ — คือเอเจนต์เดียวกันในสามขั้นตอนของชีวิต ห้องปฏิบัติการต่อไปจะพาคุณสร้างมัน

ห้องปฏิบัติการปฏิบัติ: เอเจนต์สนับสนุนลูกค้าที่พร้อมผลิต

เปิด code_samples/16-python-agent-framework.ipynb และทำตามตั้งแต่ต้นจนจบ คุณจะประกอบ เอเจนต์สนับสนุนลูกค้า Contoso ที่มีข้อกังวลในการผลิตทุกอย่างเชื่อมโยง:

  1. การเรียกเครื่องมือ — ตรวจสอบสถานะคำสั่งซื้อและเปิดตั๋วสนับสนุน
  2. RAG — ตอบคำถามนโยบายจากฐานความรู้ (Azure AI Search พร้อมทางเลือกหน่วยความจำในตัวเพื่อให้โน้ตบุ๊กทำงานได้โดยไม่ต้องมีทรัพยากร Search)
  3. ความจำ — จำลูกค้าข้ามรอบการสนทนา
  4. การส่งเส้นทางโมเดล — ตัวจำแนกความซับซ้อนส่งคำขอแต่ละรายการไปยังโมเดลเล็กหรือใหญ่
  5. การแคชการตอบกลับ — คำถามที่ซ้ำกันถูกให้คำตอบจากแคช
  6. การอนุมัติจากมนุษย์ — การคืนเงินที่เกินเกณฑ์ต้องพักรอการเซ็นชื่อจากมนุษย์
  7. สายการประเมินผล — ชุดทดสอบออฟไลน์เล็กๆ ประเมินเอเจนต์และทำหน้าที่เป็นประตูการปล่อยเวอร์ชัน
  8. การสังเกตการณ์ — การติดตาม OpenTelemetry รอบคำขอทุกคำขอ

การเดินผ่าน

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

async def handle_support_request(query: str, customer_id: str) -> str:
    # 1. Serve from cache when we can.
    cached = response_cache.get(normalize(query))
    if cached:
        return cached

    # 2. Route by complexity to control cost.
    model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"

    # 3. Run the agent inside a trace span for observability.
    with tracer.start_as_current_span("support_request") as span:
        span.set_attribute("routed.model", model)
        span.set_attribute("customer.id", customer_id)
        response = await support_agent.run(query, model=model)

    # 4. Cache and return.
    response_cache.set(normalize(query), response.text)
    return response.text

ประตูประเมินที่ปกป้องการปล่อยเวอร์ชันดูเหมือนนี้:

async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
    passed = 0
    for case in test_cases:
        result = await agent.run(case["input"])
        if score_response(result.text, case["expected"]) >= 0.8:
            passed += 1
    pass_rate = passed / len(test_cases)
    print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
    return pass_rate >= threshold  # only deploy if the gate passes

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

การตรวจสอบเอเจนต์ที่ปรับใช้ด้วยการทดสอบ smoke

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

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

รีโพสิตอรีนี้มีสายงานทดสอบ smoke ที่พร้อมใช้สร้างบน AI Smoke Test GitHub Action:

- name: Smoke-test hosted agent
  uses: JFolberth/ai-smoketest@v1
  with:
    project_endpoint: $
    agent_name: ContosoSupportAgent
    tests_file: tests/lesson-16-smoke-tests.json

รันจากแท็บ Actions เมื่อเอเจนท์ของคุณถูกติดตั้งแล้ว โดยระบุจุดเชื่อมต่อโปรเจกต์ Foundry และชื่อเอเจนท์ของคุณ ตัวตนแบบ federated ต้องมีบทบาท Azure AI User ในขอบเขตโปรเจกต์ Foundry คิดถึงเลเยอร์เป็นรูปปิรามิด: การทดสอบควัน (เข้าถึงและตอบสนองได้ไหม?) ถูกรันทุกครั้งที่ติดตั้งใหม่, การประเมินแบบออฟไลน์ (ดีพอที่จะส่งมอบไหม?) รันก่อนการโปรโมต, และการประเมินออนไลน์ (ทำงานได้ดีแค่ไหนในสภาพแวดล้อมจริง?) รันอย่างต่อเนื่อง

ตรวจสอบความรู้

ทดสอบความเข้าใจก่อนที่จะไปยังงานมอบหมาย

1. โดยประมาณแล้วเอเจนท์ที่ใช้งานจริงมีสัดส่วนเท่าไหร่ที่เป็น “โมเดล” และส่วนที่เหลือคืออะไร?

คำตอบ โมเดลเป็นส่วนน้อยของระบบ — มักอ้างว่าอยู่ราว 20% ส่วนที่เหลือคือโครงสร้างปฏิบัติการ: การโฮสต์และเวอร์ชัน, การพิสูจน์ตัวตนและ RBAC, สถานะที่แยกออกมา, การจัดการความล้มเหลว, การติดตามต้นทุน, การประเมินผล และการควบคุมโดยมนุษย์ การย้ายไปสู่การผลิตส่วนใหญ่คือการสร้างทุกอย่าง *รอบๆ* วงจรการให้เหตุผล

2. เมื่อไรที่คุณเลือกใช้ Hosted Agent แทนเอเจนท์ที่โฮสต์บนไคลเอนต์?

คำตอบ เมื่อคุณต้องการรันไทม์ที่จัดการโดยอัตโนมัติพร้อมความทนทานในตัว (เธรดที่คงอยู่และสามารถทำงานต่อได้), การสังเกตการณ์, ความปลอดภัยของเนื้อหา และ RBAC และคุณพร้อมที่จะแลกกับการควบคุมวงจรให้เหตุผลในระดับต่ำแลกกับพื้นที่ปฏิบัติการที่น้อยลง การโฮสต์บนไคลเอนต์เหมาะสมกว่าหากคุณต้องการควบคุมเต็มที่กับวงจรหรือฝังเอเจนท์ในแบ็กเอนด์ที่มีอยู่แล้ว

3. ทำไมเอเจนท์ที่ขยายตัวได้ต้องไม่มีสถานะในหน่วยความจำของกระบวนการของตัวเอง?

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

4. การกำหนดเส้นทางโมเดลแก้ไขปัญหาอะไร และเกี่ยวข้องกับการประเมินผลอย่างไร?

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

5. “เกตการประเมิน” คืออะไร และอยู่ในช่วงใดของวงจรชีวิต?

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

6. ทำไมเซิร์ฟเวอร์ MCP ต้องถูกปฏิบัติเหมือนเป็นขอบเขตที่ไม่เชื่อถือได้ในสภาพแวดล้อมการผลิต?

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

7. การเปลี่ยนแปลงอย่างเดียวที่มักมีผลกระทบมากที่สุดต่อค่าใช้จ่ายของเอเจนท์ที่ใช้งานจริงคืออะไร และทำไม?

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

8. แอตทริบิวต์ของสแปนเช่น customer.tier และ routed.model มีบทบาทอย่างไรในด้านการสังเกตการณ์?

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

งานมอบหมาย

นำเอเจนท์สนับสนุนลูกค้าจากห้องทดลองมาเสริมความแข็งแกร่งสำหรับสถานการณ์เฉพาะ: เอเจนท์สนับสนุนบิลค่าสมาชิกสำหรับบริษัท SaaS

การส่งของคุณควร:

  1. แทนที่เครื่องมือ ด้วยเครื่องมือที่เกี่ยวข้องกับบิลลิ่ง: get_subscription_status, get_invoice, และ issue_credit (เครดิตมากกว่า $50 ต้องได้รับการอนุมัติจากมนุษย์)
  2. เพิ่มเอกสาร RAG สามชุด ครอบคลุมนโยบายคืนเงินของบริษัท, รอบบิล, และนโยบายการยกเลิก
  3. ขยายชุดประเมินผล ให้มีอย่างน้อยแปดกรณี รวมอย่างน้อยสองกรณีที่ ควร กระตุ้นเส้นทางอนุมัติจากมนุษย์ และยืนยันว่าเกตการประเมินของคุณผ่านหรือไม่ผ่านอย่างถูกต้อง
  4. เพิ่มรายงานต้นทุนหนึ่งฉบับ: หลังจากรันคำถามผสมสิบคำถามผ่านเอเจนท์ แสดงจำนวนที่ส่งไปยังโมเดลเล็ก, โมเดลใหญ่, และที่ให้บริการจากแคช

เขียนย่อหน้าเล็ก ๆ (ในเซลล์มาร์กดาวน์) อธิบายว่าเลือกกฎการกำหนดเส้นทางโมเดลใดและวิธีที่คุณจะยืนยันกับทราฟฟิกจริง ไม่มีคำตอบที่ถูกต้องเดียว — คุณจะถูกประเมินว่ากังวลเรื่องการผลิตถูกเชื่อมโยงกันอย่างสอดคล้องหรือไม่

สรุป

ในบทเรียนนี้คุณได้ย้ายเอเจนท์จากต้นแบบไปสู่การผลิตด้วย Microsoft Foundry:

บทเรียนถัดไปจะเดินทางย้อนกลับ: แทนที่จะขยายเอเจนท์ขึ้นในคลาวด์ คุณจะนำพวกมัน ลง บนเครื่องนักพัฒนาคนเดียวและรันทั้งหมดในเครื่องแบบโลคัล

แหล่งข้อมูลเพิ่มเติม

บทเรียนก่อนหน้า

Building Computer Use Agents (CUA)

บทเรียนถัดไป

Creating Local AI Agents

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

This site is open source. Improve this page.