Microsoft Foundry ที่ Build 2026 — Hosted Agents ขึ้น GA, 'Autopilot Agents' ที่มี Entra ID และที่นั่งในผังองค์กร, พร้อม Agent Optimizer ปิดลูปจาก trace สู่ตัวที่ดีกว่า

ในงาน Microsoft Build 2026 ทีม Microsoft Foundry เผยแพร่บทความก้อนใหญ่บน Microsoft Dev Blogs (2 มิถุนายน 2026) สรุปวิสัยทัศน์ “Microsoft Agent Platform” ที่วางให้นักพัฒนา สร้างใน GitHub, รันใน Foundry, และส่ง agent ไปอยู่ในแอปที่ผู้ใช้เปิดอยู่แล้ว ประเด็นหลักของบทความไม่ใช่ตัวเฟรมเวิร์ก แต่คือทุกอย่างที่ “อยู่รอบ ๆ agent” — การ deploy, การแยก session, observability และการ deploy ซ้ำ — ซึ่งทีม Foundry เปรียบว่าเป็นจุดเดียวกับที่ microservices เคยเจอเมื่อสิบปีก่อน: ต้นแบบตัวเดียวทำง่าย แต่ของจริงคืองานที่ล้อมรอบมัน

Microsoft จัดของใหม่เป็นสามชั้น — Build (สร้าง), Deploy (ปล่อยลงสนาม) และ Operate (ดูแลให้รันต่อ) — โดยมีหมุดสำคัญหลายตัวที่กำลังขึ้น GA ภายในเดือนนี้

Deploy: Hosted Agents ขึ้น GA และกำเนิด “autopilot agents”

Hosted Agents ใน Foundry Agent Service (จะขึ้น GA ภายใน 30 วัน) คือ runtime ที่ Microsoft จัดการให้สำหรับ agent ระดับ production — ทุก session รันใน sandbox ของตัวเอง แยก compute, memory และ filesystem ออกจากกัน และเป็น framework-agnostic จึงรับ agent ที่สร้างจาก Microsoft Agent Framework, GitHub Copilot SDK, LangGraph หรือ SDK อื่นได้โดยไม่ต้องเขียนใหม่ รองรับทั้ง Responses API แบบ OpenAI-compatible และ Invocations protocol แบบ pass-through รวมถึง long-running agents ที่ถือ state ค้างไว้และทำงานเองต่อเนื่อง กับ routines ที่สั่งให้ agent ทำงานตามตารางเวลา (เช่น เฝ้า repo ตอนกลางคืน คัดแยก issue ตอนเช้า แล้วโพสต์สรุปลง Teams ก่อนประชุม)

ของที่น่าสนใจที่สุดคือประเภท agent ใหม่ที่สามชื่อ autopilot agents (public preview) — นอกเหนือจาก assistive agent (ทำงานแทนผู้ใช้) และ autonomous agent (ทำงานเองเบื้องหลัง) คราวนี้ autopilot agent มี Entra Agent ID, อีเมลของตัวเอง, สถานะใน Microsoft Teams และตำแหน่งในผังองค์กร มันเริ่มบทสนทนาเองได้ ทำงานบนไฟล์ร่วมกัน ตามงานค้าง และทำงานร่วมกับมนุษย์ได้ข้ามเวลา — ทุกการกระทำระบุที่มา ตรวจสอบย้อนหลังได้ และถูกกำกับผ่าน Agent 365 ใน Admin Center พูดง่าย ๆ คือ Microsoft กำลังให้ agent กลายเป็น “เพื่อนร่วมงาน AI” ที่มีตัวตนในระบบองค์กรจริง ๆ

ฝั่งการกระจาย agent ก็เปิด publishing เข้า Microsoft Teams และ Microsoft 365 Copilot (GA เดือนหน้า) ให้ agent ไปโผล่ในเครื่องมือที่พนักงานใช้อยู่แล้ว พร้อม identity/permission/policy ที่ไหลตามไปอัตโนมัติ และเพิ่ม incoming A2A (Agent2Agent, public preview) ที่ให้ expose agent ของ Foundry เป็น endpoint ให้ agent ค่ายอื่น/คลาวด์อื่นค้นเจอผ่าน agent card แล้วเรียกใช้ผ่านโปรโตคอลเปิดได้

Build + Operate: Toolboxes, procedural memory และ Agent Optimizer

ชั้น Build เน้นการ “เลือกสถาปัตยกรรมให้ถูกตั้งแต่ต้น” — Toolboxes in Foundry (preview) รวม tool ทุกชนิดไว้หลัง endpoint เดียว ตั้งค่าครั้งเดียวแล้วชี้ MCP client ใด ๆ มาที่ URL เดียว ให้ Foundry จัดการ auth/lifecycle/governance เอง โดยมี Skills (preview) เป็น first-class — เก็บเวอร์ชันใน catalog ระดับโปรเจกต์และให้ agent ค้นเจอเป็น MCP resource — บวกกับ tool search ที่เลือก tool ที่เกี่ยวข้องต่องานแทนที่จะยัดทุก tool ให้โมเดล ส่วน Memory in Foundry Agent Service เพิ่ม procedural memory ที่ให้ agent “เรียนรู้วิธีทำงาน” ข้าม run (ผล Tau-bench เบื้องต้นชี้ success-rate เพิ่ม 7–14% ที่ต้นทุนใกล้เดิม) เสริมจาก user memory และ session memory เดิม

ชั้น Operate คือจุดที่ทีมส่วนใหญ่หมดความมั่นใจ — Foundry ปิดช่องนี้ด้วย tracing และ evaluation สำหรับ hosted agents (GA ปลายมิถุนายน) ที่ส่งทุก model call, tool call, sub-agent hop ผ่านไปป์ไลน์ OpenTelemetry เดียว และเชื่อม eval กลับไปยัง trace ที่ก่อปัญหาโดยตรง จุดพีคคือ Agent Optimizer (public preview ใน 30 วัน) ที่กิน production trace + eval แล้วสร้างชุดปรับปรุง prompt/skill เป็นอันดับ ตรวจกับ scenario และข้อจำกัดของเราเอง แล้วเสนอตัวชนะพร้อม diff, audit และ rollback — เปลี่ยนวงจร “เดา-ลอง-หวังว่าจะดีขึ้น” ให้เป็นลูป observe → evaluate → optimize → deploy ที่มีหลักฐานกำกับทุกขั้น

มุมมอง AI Curator

ถ้าโพสต์ Agent Framework เมื่อวานคือเรื่อง “ตัวเครื่องยนต์” (harness, CodeAct) โพสต์นี้คือเรื่อง “โรงงานและสายพานการผลิต” — และสิ่งที่ Microsoft กำลังเดิมพันชัดเจนคือ agent จะไม่ใช่ feature ในแอป แต่จะเป็น identity ในองค์กร มีอีเมล มีที่นั่งในผังองค์กร มี audit trail เหมือนพนักงานคนหนึ่ง นี่คือก้าวที่ใหญ่กว่าที่หลายคนมอง เพราะมันลากเรื่อง agent ออกจากโลกของนักพัฒนาเข้าสู่โลกของ HR, compliance และ IT governance เต็มตัว

สำหรับองค์กรในไทยและ SEA ที่ผูกกับ Microsoft 365/Entra อยู่แล้ว เส้นทางนี้น่าจะ “ลื่น” ที่สุดในการเอา agent ขึ้น production จริง — ไม่ต้องสร้างชั้น identity/observability เองตั้งแต่ศูนย์ และการที่ runtime เป็น framework-agnostic รับทั้ง Claude Agent SDK, LangGraph และ Copilot SDK ก็ลดความเสี่ยง lock-in ระดับเฟรมเวิร์กลงได้จริง แต่ข้อควรระวังเชิงกลยุทธ์ยังเหมือนเดิม: “ของฟรีในแพลตฟอร์ม” อย่าง Foundry IQ, managed memory และ Agent 365 ผูกเรากับ Azure อย่างแนบแน่นขึ้นทุกชั้น — โดยเฉพาะเมื่อ agent กลายเป็น identity ที่มี audit trail ในระบบ การย้ายออกในวันหน้าจะไม่ใช่แค่ย้ายโค้ด แต่ต้องย้าย “ตัวตนเชิงองค์กร” ของ agent ไปด้วย ทีมที่ฉลาดจึงควรวางสัญญาข้อมูลและ identity ให้พกพาได้ตั้งแต่วันแรก ก่อนที่ “เพื่อนร่วมงาน AI” จะฝังรากลึกเกินถอน

แหล่งข่าว:

• Build and run agents at scale with Microsoft Foundry at Build 2026 — Microsoft DevBlogs
• From Building Agents to Working with Them: Enterprise Agent Distribution in Microsoft Foundry — Microsoft DevBlogs