Microsoft Copilot Harness: ระบบเบื้องหลังที่ช่วยให้ AI Agent ทำงานหลายขั้นตอน

• 1. Harness คืออะไร
• 2. ประกาศใหม่เกี่ยวข้องกับบริการใดบ้าง
• 3. ความสามารถสำคัญใน Foundry
  • Skill กับ Tool ต่างกันอย่างไร
  • Subagents กับ Connected agents
• 4. วงจรการทำงาน: จากคำขอไปสู่ผลลัพธ์
• 5. หลักฐานด้านประสิทธิภาพที่ Microsoft รายงาน
• 6. เริ่มต้นผ่าน Foundry Portal
  • ข้อจำกัดที่มีผลต่อการออกแบบ
• 7. Workshop: Agent วิเคราะห์ผลทดสอบซอฟต์แวร์
  • เป้าหมายการเรียนรู้
  • ข้อมูลจำลอง
  • Instructions ตัวอย่าง
  • ขั้นตอนของ Skill ที่ผู้เรียนควรออกแบบ
  • คำขอสำหรับทดลอง
  • ผลที่ควรตรวจพบ
  • ออกแบบการเปรียบเทียบในชั้นเรียน
• 8. เลือก managed harness หรือ framework ที่ควบคุมเอง
• 9. ค่าใช้จ่ายที่ควรแยกให้ออก
• แหล่งอ้างอิง

Microsoft ประกาศ Microsoft Copilot harness เมื่อวันที่ 28 ตุลาคม 2026 โดยนำเทคโนโลยีพื้นฐานจากทีม GitHub มาใช้ร่วมกันในประสบการณ์ Copilot ของ Microsoft และเปิดให้ใช้งานผ่าน Microsoft Foundry [1]

แนวคิดหลักคือ การสร้าง Agent ให้ทำงานสำเร็จต้องมีระบบรอบโมเดล ทั้งคำสั่ง บริบท เครื่องมือ สภาพแวดล้อมสำหรับลงมือทำงาน และกลไกควบคุมการทำงาน ระบบส่วนนี้เรียกว่า harness [1]

#1. Harness คืออะไร

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

แยกความรับผิดชอบเพื่อใช้ในการออกแบบได้ดังนี้:

ตารางนี้เป็นคำอธิบายเชิงแนวคิดของผู้เขียน อิงนิยาม harness ของ Microsoft [1]

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

#2. ประกาศใหม่เกี่ยวข้องกับบริการใดบ้าง

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

เอกสารบางหน้าอาจยังใช้ชื่อ GitHub Copilot harness ในช่วงเปลี่ยนผ่าน Microsoft ระบุว่าชื่อใหม่จะทยอยปรากฏในผลิตภัณฑ์ [3]

สำหรับ Copilot Studio เอกสารชี้แจงว่า harness นี้เป็นสภาพแวดล้อมสำหรับสร้างและรัน Agent ภายใน Copilot Studio ข้อมูลลูกค้าไม่ได้ถูกส่งไปประมวลผลโดยบริการ GitHub Copilot เพียงเพราะ harness มีรากฐานเทคโนโลยีร่วมกัน [4]

#3. ความสามารถสำคัญใน Foundry

ประกาศ Foundry จัดความสามารถหลักไว้สี่กลุ่ม [2]:

1. Reusable skills — รวมขั้นตอน คำสั่ง สคริปต์ และทรัพยากรที่ใช้ซ้ำได้
2. Connected tools — เชื่อมเครื่องมือที่รองรับ รวมถึง MCP โดยตั้งค่าการยืนยันตัวตนและการอนุมัติตามข้อกำหนด
3. Execution and delegation — ทำงานกับไฟล์และโค้ด รวมถึงมอบหมายงานที่มีขอบเขตให้ subagents ภายในระบบ
4. Source-controlled definitions — เก็บนิยาม Agent และทรัพยากรประกอบร่วมกับซอร์สโค้ดของแอปพลิเคชัน

ในเส้นทาง managed harness นั้น Microsoft ดูแล agent loop และ sandbox ส่วนทีมพัฒนากำหนดความรู้ วิธีทำงาน เครื่องมือ และโมเดลที่รองรับ [2]

#Skill กับ Tool ต่างกันอย่างไร

Skill อธิบายวิธีทำงาน เช่น “ตรวจหลักฐานก่อนจัดระดับความรุนแรงของข้อผิดพลาด” ส่วน Tool ทำให้เข้าถึงบริการหรือดำเนินการได้จริง เช่น API ดึงข้อมูล issue [5]

การมี Skill ที่ดีจึงยังต้องมีข้อมูลและเครื่องมือที่เหมาะสม ขณะเดียวกัน การเชื่อมเครื่องมือจำนวนมากก็ยังต้องมีคำสั่งและขอบเขตงานที่ชัดเจน

#Subagents กับ Connected agents

Foundry ประกาศความสามารถ built-in subagents ภายใน harness [2] ขณะที่เอกสาร Copilot Studio อธิบายการมอบหมายงานให้ Agent แยกต่างหากผ่าน Connected agents และระบุว่าแนวคิด child agents แบบเดิมไม่ได้มีใน harness นี้ [5] ควรใช้คำตามบริการที่กำลังออกแบบ

#4. วงจรการทำงาน: จากคำขอไปสู่ผลลัพธ์

แผนภาพนี้เป็นภาพอธิบายเชิงแนวคิด ไม่ใช่รายละเอียด implementation ภายในของ Microsoft

flowchart TD
    A["คำขอและขอบเขตงาน"] --> B["Harness จัดบริบทและคำสั่ง"]
    B --> C["Model พิจารณาขั้นตอนถัดไป"]
    C --> D{"ต้องใช้เครื่องมือหรือไม่"}
    D -->|ต้องใช้| E["เรียก Tool ตามสิทธิ์และนโยบาย"]
    E --> F["รับผลหรือข้อผิดพลาด"]
    F --> B
    D -->|ข้อมูลเพียงพอ| G["สร้างผลลัพธ์พร้อมหลักฐาน"]

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

#5. หลักฐานด้านประสิทธิภาพที่ Microsoft รายงาน

Microsoft เผยแพร่ผลเปรียบเทียบภายในระหว่าง Microsoft Copilot harness และ Standard harness ในบริบท Copilot Studio เมื่อเดือนตุลาคม 2026 [3]

ผลเหล่านี้เป็น ข้อมูลประเมินภายในของผู้ให้บริการ ไม่ใช่การทดลองที่ผู้เขียนบทความนี้ทำซ้ำ และ Microsoft ระบุว่าผลเปลี่ยนแปลงได้ตาม model, build, configuration และ scenario [3]

สำหรับการทดลองทางวิชาการ สามารถตั้งคำถามต่อได้ว่า เมื่อคงโมเดล ชุดงาน และข้อมูลให้เหมือนกัน การเปลี่ยน orchestration และวิธีจัดบริบทจะเปลี่ยน task success, latency และต้นทุนมากเพียงใด

#6. เริ่มต้นผ่าน Foundry Portal

เอกสาร Microsoft Learn ระบุว่าต้องมี Foundry project ใน region ที่รองรับ โมเดลที่รองรับ reasoning และ tool calling และสิทธิ์ที่เหมาะสมกับ project และเครื่องมือ [6][7]

ขั้นตอนเริ่มต้นตามเส้นทาง Portal [6]:

1. เปิด Microsoft Foundry แบบประสบการณ์ใหม่ และเลือก project ที่รองรับ
2. เลือกสร้าง Agent ใหม่ ตั้งชื่อ และใช้ interaction mode แบบ Text
3. เลือก Use the Microsoft Copilot harness แล้วสร้าง Agent
4. กำหนด instructions และทรัพยากรที่จำเป็นกับงาน
5. บันทึกและเริ่มแชตใหม่ รอให้เวอร์ชันที่แก้ไขพร้อมใช้งาน
6. ทดสอบและตรวจ response trace ว่ามีการเรียกเครื่องมือตามที่คาดไว้

ช่วง initial public preview ต้องเลือก harness ตั้งแต่สร้าง Agent และยังไม่รองรับการเปลี่ยน harness ของ Agent เดิม [6]

บทความนี้ไม่ได้ deploy ทรัพยากร Azure หรือรันทดสอบ Agent จริง ขั้นตอนเป็นแนวทางจากเอกสาร ณ วันที่ตรวจสอบ

#ข้อจำกัดที่มีผลต่อการออกแบบ

• การรองรับ region, model และ quota ต้องตรวจสอบจากตารางล่าสุด [7]
• Workspace และ sandbox สำหรับการทำงานไม่ใช่ที่เก็บผลลัพธ์ถาวร ควรส่งออกงานสำคัญไปยังบริการจัดเก็บที่เหมาะสม [6]
• Foundry รองรับโมเดลตามข้อกำหนดของบริการ การประกาศ multi-model ในภาพรวมไม่ได้แปลว่า preview รองรับโมเดลใดก็ได้ [1][6]

#7. Workshop: Agent วิเคราะห์ผลทดสอบซอฟต์แวร์

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

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

เมื่อจบกิจกรรม ผู้เรียนควรอธิบายความต่างระหว่าง Model, Skill และ Tool ได้ และตรวจสอบได้ว่า Agent สรุปจากข้อมูลจริงหรือเพียงเสนอสมมติฐาน

#ข้อมูลจำลอง

ใช้ข้อมูลนี้เป็นข้อความหรือไฟล์ตัวอย่างที่เครื่องมืออ่านได้:

{
  "run_id": "demo-run-001",
  "tests": [
    {"name": "login_valid_user", "status": "passed"},
    {
      "name": "checkout_submit",
      "status": "failed",
      "error": "Timeout while waiting for the confirmation message"
    },
    {"name": "profile_update", "status": "passed"}
  ]
}

#Instructions ตัวอย่าง

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

#ขั้นตอนของ Skill ที่ผู้เรียนควรออกแบบ

1. ตรวจรูปแบบข้อมูลและจำนวนรายการ
2. แยกผลทดสอบผ่าน ล้มเหลว และสถานะอื่นที่พบจริง
3. ดึงข้อความผิดพลาดโดยรักษาความหมายเดิม
4. เสนอสมมติฐานพร้อมหลักฐานที่สนับสนุนหรือยังขาด
5. สรุปแนวทางตรวจสอบ โดยอ้างกลับไปยัง test case

#คำขอสำหรับทดลอง

วิเคราะห์ demo-run-001 จากข้อมูลที่แนบ
สรุปจำนวน test ที่ผ่านและล้มเหลว
อธิบายสิ่งที่ทราบเกี่ยวกับ checkout_submit
เสนอสิ่งที่ควรตรวจต่อ โดยแยกข้อเท็จจริงและสมมติฐาน

#ผลที่ควรตรวจพบ

• มีทั้งหมด 3 test cases: ผ่าน 2 และล้มเหลว 1
• checkout_submit ล้มเหลวด้วย timeout ขณะรอข้อความยืนยัน
• ข้อมูลยังไม่พอระบุว่าเป็นปัญหาของแอป เครือข่าย locator หรือเวลารอ
• หลักฐานต่อไปที่อาจช่วยได้ ได้แก่ trace, screenshot และผลตอบกลับของ API ในช่วงเกิดเหตุ

#ออกแบบการเปรียบเทียบในชั้นเรียน

ควรใช้โมเดลและชุดกรณีเดียวกันในทุกเงื่อนไข พร้อมบันทึก latency, จำนวน tool calls และต้นทุนต่อกรณี การเปรียบเทียบนี้ประเมินผลจากการเพิ่มองค์ประกอบในระบบ ไม่ใช่หลักฐานเชิงสาเหตุของ harness ทั้งระบบ เพราะหลายกลไกยังเปลี่ยนร่วมกันได้

เพิ่มกรณีทดสอบอย่างน้อยสามแบบ: ข้อมูลครบ, ข้อมูลบางส่วนหาย และเครื่องมือคืนข้อผิดพลาด จากนั้นตรวจว่า Agent สร้างรายละเอียดที่ไม่มีในหลักฐานหรือไม่

#8. เลือก managed harness หรือ framework ที่ควบคุมเอง

Foundry แยกทางเลือก prompt agents ที่ใช้ Copilot harness ออกจาก hosted agents ซึ่งรองรับการนำ framework และ agent loop ของทีมเองมารัน [2]

ข้อเสนอในตารางเป็นการตีความเชิงออกแบบ ไม่ใช่การจัดอันดับว่าแนวทางใดดีกว่าในทุกสถานการณ์

ใน Copilot Studio ยังมี Standard harness ที่ได้รับการสนับสนุนควบคู่กัน และเอกสารระบุว่าไม่มีการบังคับเปลี่ยน [5]

#9. ค่าใช้จ่ายที่ควรแยกให้ออก

ประกาศ Foundry ระบุว่าเริ่มคิดค่า harness runtime วันที่ 1 ธันวาคม 2026 ก่อนวันดังกล่าว runtime ใช้ได้โดยไม่มีค่า runtime แต่ยังมีค่า model inference เครื่องมือ และบริการที่คิดแยกตามเงื่อนไข [2]

สำหรับ Copilot Studio การเปลี่ยนชื่อ harness ไม่เปลี่ยน billing ของ Agent เดิม และการใช้งานอยู่ภายใต้เงื่อนไขการคิดค่าบริการของ Copilot Studio [3][5] จึงไม่ควรนำราคา Foundry ไปใช้ประมาณค่าใช้จ่ายของ Copilot Studio โดยตรง

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

#แหล่งอ้างอิง

1. Microsoft: Introducing the Microsoft Copilot harness — ประกาศภาพรวม วันที่ 28 ต.ค. 2026
2. Microsoft Foundry Blog: Microsoft Copilot harness in Foundry Agent Service — Public Preview ความสามารถ ทางเลือก runtime และการคิดค่าบริการ
3. Microsoft Copilot Blog: The GitHub Copilot harness is now the Microsoft Copilot harness — การเปลี่ยนชื่อและผลประเมินภายใน
4. Microsoft Learn: Agents powered by the GitHub Copilot harness overview — แนวคิดใน Copilot Studio
5. Microsoft Learn: FAQ for agents powered by the GitHub Copilot harness — Skills, tools, connected agents และสถานะ Standard harness
6. Microsoft Learn: Use the Microsoft Copilot harness with prompt agents — วิธีเริ่มต้นและข้อกำหนดทางเทคนิค
7. Microsoft Learn: Quotas and limits for Foundry Agent Service — Region, model และข้อจำกัดบริการ
8. Microsoft Learn: Quickstart — Create a web research agent — ตัวอย่างต่อยอดจากเอกสารทางการ