วิธีสร้าง Agent ใน SharePoint

SharePoint Agent คือแนวทางการใช้ AI เพื่อช่วยตอบคำถาม ค้นข้อมูล และทำงานกับเนื้อหาที่อยู่ใน SharePoint โดยอาศัยเอกสาร หน้า และข้อมูลที่ผู้ใช้มีสิทธิ์เข้าถึงเป็นบริบท ในประสบการณ์ที่รองรับ ผู้ใช้สามารถสร้าง Agent เพื่อให้ตอบคำถามเกี่ยวกับ Project, Policy, Knowledge Base หรือข้อมูลของทีมได้เฉพาะเจาะจงมากกว่าการถาม AI แบบกว้าง ๆ

ประโยชน์สำคัญคือช่วยเปลี่ยน SharePoint จากแหล่งเก็บเอกสารให้กลายเป็นพื้นที่ถาม-ตอบข้อมูล เช่น “ขั้นตอนขอสิทธิ์ VPN คืออะไร” “Policy วันลามีอะไรบ้าง” หรือ “Project Alpha มี Risk อะไร” โดยไม่ต้องเปิดไฟล์ทีละฉบับ

บทความนี้ comsiam จะอธิบายวิธีสร้าง Agent ใน SharePoint ตั้งแต่การกำหนดเป้าหมาย เลือก Source ตั้งชื่อ กำหนดคำแนะนำ ทดสอบคำตอบ ไปจนถึงตรวจ Permission และความถูกต้องก่อนให้ทีมใช้งานจริง

① SharePoint Agent คืออะไร

SharePoint Agent คือ AI Assistant ที่ใช้ข้อมูลจาก SharePoint เป็นบริบทหลัก

เหมาะกับงานถาม-ตอบจากข้อมูลภายใน

② Agent ใช้ทำอะไรได้บ้าง

ตัวอย่างเช่น

• ตอบคำถาม
• หา Policy
• สรุปเอกสาร
• หา Procedure
• หา Project Information
• หา FAQ

ตามความสามารถที่รองรับ

③ Agent ต่างจาก Search อย่างไร

Search เน้นหาไฟล์หรือ Page

Agent สามารถช่วยตอบคำถามโดยใช้ข้อมูลจาก Source ที่กำหนด

จึงเหมาะกับ Question & Answer มากกว่า

④ Agent ต่างจาก Copilot ทั่วไปอย่างไร

Agent สามารถถูกกำหนดให้โฟกัสข้อมูลเฉพาะชุด

เช่น

• HR
• IT
• Project Alpha
• Knowledge Base

ช่วยลดคำตอบที่กว้างเกิน

⑤ เริ่มจากกำหนด Objective

ก่อนสร้างควรรู้ว่า Agent มีไว้ทำอะไร

เช่น

ตอบคำถามเกี่ยวกับ IT Support

ช่วย Scope ชัด

⑥ กำหนด Audience

ตัวอย่าง

• พนักงานทั่วไป
• ทีม IT
• Sales
• HR
• Project Team

Audience มีผลต่อคำถามและ Source

⑦ เลือก SharePoint Site

เริ่มจาก Site ที่มีข้อมูลเกี่ยวข้องจริง

เช่น

IT Support Site

ช่วยลด Noise

⑧ เลือก Source

Source อาจเป็นข้อมูลที่ Agent ได้รับอนุญาตให้ใช้ในประสบการณ์ที่รองรับ เช่น

• Site
• Library
• Folder
• Files

ควรเลือกเฉพาะที่จำเป็น

⑨ อย่าเลือก Source กว้างเกิน

ถ้า Agent มีไว้ตอบเรื่อง HR Leave

ไม่จำเป็นต้องใช้เอกสารของทุก Department

ช่วยลดความสับสน

⑩ เลือก Source ที่เชื่อถือได้

ควรใช้

• Approved Policy
• Final Procedure
• Current Guide

มากกว่า Draft

⑪ ตรวจ Version

ก่อนเพิ่มเอกสารเป็น Source

ต้องแน่ใจว่าเป็น Version ที่ถูกต้อง

⑫ ตรวจ Draft

Draft อาจยังไม่ผ่านการอนุมัติ

ไม่ควรนำไปใช้ตอบเหมือน Final

⑬ ตรวจข้อมูลซ้ำ

ถ้ามีเอกสารหลาย Version

Agent อาจเจอข้อมูลขัดกัน

ควรจัด Source ก่อน

⑭ ตั้งชื่อ Agent

ชื่อควรบอกหน้าที่ชัด

เช่น

IT Support Agent

ดีกว่า

Assistant 01

⑮ ชื่อ Agent สำหรับ HR

ตัวอย่าง

HR Policy Assistant

ช่วยให้ผู้ใช้เข้าใจทันที

⑯ ชื่อ Agent สำหรับ Project

เช่น

Project Alpha Assistant

เหมาะกับทีมโครงการ

⑰ ชื่อ Agent สำหรับ Knowledge Base

เช่น

Company Knowledge Assistant

เหมาะกับข้อมูลทั่วไป

⑱ เขียน Description

Description ควรบอกว่า Agent ช่วยเรื่องอะไร

เช่น

ช่วยตอบคำถามเกี่ยวกับ IT Services, VPN และ Account Access

⑲ ระบุข้อจำกัด

Description อาจระบุด้วยว่า Agent ไม่ควรใช้สำหรับอะไร

ช่วยลดการถามผิดขอบเขต

⑳ กำหนด Instructions

ในประสบการณ์ที่รองรับ ควรกำหนดแนวทางการตอบให้ Agent ชัดเจน

เช่น

ตอบโดยใช้เฉพาะ Source ที่กำหนด

㉑ Instruction ที่สำคัญ

ใช้

หากไม่พบข้อมูล ให้ตอบว่า “ไม่พบข้อมูลใน Source”

ช่วยลดการเดา

㉒ ห้าม Agent เดา Policy

Prompt

ห้ามสร้าง Policy ใหม่หาก Source ไม่มีข้อมูล

เหมาะกับ HR และ Compliance

㉓ ห้าม Agent เดา Owner

Owner ต้องมาจาก Source จริง

㉔ ห้าม Agent เดา Deadline

Deadline ที่ไม่มีในเอกสารไม่ควรถูกสร้างขึ้น

㉕ ห้าม Agent เดาตัวเลข

ราคา KPI และ Budget ต้องมาจาก Source

㉖ กำหนด Tone

เช่น

• Professional
• Concise
• Friendly
• Technical

ตาม Audience

㉗ กำหนดภาษา

สามารถกำหนดให้ตอบภาษาไทยเป็นหลัก

หากผู้ใช้กลุ่มเป้าหมายเป็นคนไทย

㉘ รักษาคำศัพท์เทคนิค

Prompt

คงชื่อ Product, System และ Technical Terms ตาม Source

ช่วยลดการแปลผิด

㉙ กำหนดรูปแบบคำตอบ

เช่น

ตอบเป็น Bullet ก่อน แล้วอธิบายรายละเอียด

ช่วยอ่านง่าย

㉚ กำหนดความยาว

ใช้

ตอบสั้นก่อน และขยายเมื่อผู้ใช้ถามต่อ

ช่วยลด Information Overload

㉛ สร้าง Agent สำหรับ IT

Source อาจประกอบด้วย

• VPN Guide
• Password Guide
• Device Policy
• Service Catalog

ช่วย Service Desk

㉜ ตัวอย่างคำถาม IT

เช่น

ฉันขอ VPN อย่างไร

Agent ควรตอบจาก Procedure จริง

㉝ สร้าง Agent สำหรับ HR

Source อาจมี

• Leave Policy
• Benefits
• Onboarding
• Training

ช่วย Employee Self-service

㉞ ตัวอย่างคำถาม HR

เช่น

ลาพักร้อนได้กี่วัน

ต้องตอบจาก Policy จริง

㉟ สร้าง Agent สำหรับ Project

Source อาจมี

• Project Plan
• Meeting Notes
• Risk Register
• Decisions

ช่วย Project Team

㊱ ตัวอย่างคำถาม Project

เช่น

Milestone ถัดไปคืออะไร

ช่วยติดตามงาน

㊲ สร้าง Agent สำหรับ Sales

Source อาจมี

• Sales Playbook
• Product Info
• Proposal Templates
• FAQ

ช่วย Sales Enablement

㊳ ตัวอย่างคำถาม Sales

เช่น

Product A เหมาะกับลูกค้าประเภทไหน

ควรใช้ข้อมูลที่ได้รับอนุมัติ

㊴ สร้าง Agent สำหรับ Compliance

Source อาจเป็น Approved Policies

ไม่ควรใช้ Draft

㊵ ตัวอย่างคำถาม Compliance

เช่น

External Sharing ต้องทำอย่างไร

Agent ควรระบุ Source ที่เกี่ยวข้องเมื่อเหมาะสม

㊶ เลือก Source ให้น้อยแต่ตรง

Source ที่มากไม่ได้แปลว่าดีกว่าเสมอไป

ความเกี่ยวข้องสำคัญกว่า

㊷ Source เยอะเกินไปมีผลอย่างไร

อาจเกิด

• ข้อมูลซ้ำ
• Version Conflict
• Noise
• คำตอบยาว

จึงควรคัดกรอง

㊸ Source เก่าเป็นปัญหา

Policy เก่าอาจทำให้ Agent ตอบผิด

ควร Archive หรือเอาออกจาก Scope ตาม Governance

㊹ Source ขัดกัน

หากเอกสารสองฉบับให้ข้อมูลต่างกัน

ควรกำหนดให้ Agent

แสดงทั้งสอง Source และไม่ตัดสินเอง

㊺ กำหนด Source Priority ได้ไหม

หากระบบรองรับการกำหนดบริบทหรือคำแนะนำ

ควรระบุว่า Approved Source มีความสำคัญกว่า Draft

แต่ยังต้องตรวจผลลัพธ์จริง

㊻ ทดสอบคำถามง่ายก่อน

เช่น

Policy นี้มีผลกับใคร

ช่วยดูว่า Agent เข้าใจ Source หรือไม่

㊼ ทดสอบคำถาม Fact

เช่น

Deadline คือวันไหน

ควรได้คำตอบตรง Source

㊽ ทดสอบคำถามที่ไม่มีคำตอบ

ถามเรื่องที่ไม่ได้อยู่ใน Source

Agent ที่ดีควรบอกว่าไม่พบ

ไม่ใช่เดา

㊾ ทดสอบคำถามกำกวม

เช่น

ราคาเท่าไร

ถ้ามีหลายรายการ Agent ควรถามหรือแยก Context ให้เหมาะสม

㊿ ทดสอบคำถามหลาย Project

ช่วยดูว่า Agent แยกข้อมูลข้าม Project ได้หรือไม่

51. ทดสอบชื่อคล้ายกัน

Project Alpha กับ Alpha 2 อาจสับสน

ควรลองคำถามเพื่อจับปัญหา

52. ทดสอบ Version

ถามข้อมูลที่ต่างกันระหว่าง Version

ช่วยตรวจว่า Agent ใช้ Source ถูกหรือไม่

53. ทดสอบ Owner

ตรวจว่า Agent ไม่จับชื่อผิดคน

54. ทดสอบ Deadline

ตรวจว่าจับคู่ Task กับวันที่ถูกต้อง

55. ทดสอบตัวเลข

Budget หรือ KPI ต้องตรง Source

56. ทดสอบ Negative Statement

เช่น Source ระบุว่า

ไม่รองรับ External Sharing

Agent ต้องไม่ตอบกลับเป็น

รองรับ

57. ทดสอบ Exception

ข้อยกเว้นควรถูกเก็บไว้

ไม่ควรถูกสรุปหาย

58. ทดสอบภาษาไทย

ถามด้วยภาษาธรรมชาติแบบผู้ใช้จริง

เช่น

ขอ VPN ยังไง

ช่วยดู Adoption จริง

59. ทดสอบคำถามสั้น

ผู้ใช้อาจถามเพียง

VPN

Agent ควรจัดการ Context ให้เหมาะสม

60. ทดสอบคำถามยาว

เช่นคำถามที่มีหลายเงื่อนไข

ช่วยดูว่า Agent จับ Intent ได้ครบไหม

61. ตรวจคำตอบกับ Source

ทุกคำถามทดสอบควรมี Expected Answer

แล้วเทียบกับเอกสารจริง

62. สร้าง Test Set

อาจทำรายการ

• คำถาม
• คำตอบที่คาดหวัง
• Source
• ผลทดสอบ

ช่วย QA

63. ใช้คำถามจากผู้ใช้จริง

คำถามจาก Support Ticket หรือ FAQ จริงมีประโยชน์มาก

ช่วยทดสอบ Use Case จริง

64. ทดสอบก่อนแชร์ทั้งองค์กร

เริ่มจาก Pilot Group

ช่วยหา Error ก่อน Launch

65. ให้ Subject Matter Expert ตรวจ

เช่น

HR Agent → HR ตรวจ

IT Agent → IT ตรวจ

ช่วย Accuracy

66. Permission ยังสำคัญ

Agent ไม่ควรถูกใช้ข้ามสิทธิ์ของ SharePoint

ข้อมูลที่ผู้ใช้ไม่มีสิทธิ์ไม่ควรถูกเปิดเผย

67. ผู้ใช้ต่างกันอาจได้คำตอบต่างกัน

เพราะ Permission ที่เข้าถึง Source อาจต่างกัน

เป็นสิ่งที่ต้องเข้าใจ

68. ตรวจ Site Permission

ก่อนเปิด Agent ให้ทีม

ควรรู้ว่า Source ใดเปิดให้ใครบ้าง

69. ตรวจ Library Permission

Library บางแห่งอาจมีข้อมูล Confidential

ต้องระวัง

70. ตรวจ Folder Permission

Folder ก็สามารถจำกัดสิทธิ์ได้

จึงมีผลต่อ Agent

71. ตรวจ File Permission

เอกสารเดี่ยวอาจมีสิทธิ์พิเศษ

ต้องไม่ลืม

72. Sensitivity Label

Agent ควรเคารพ Information Protection ของ Microsoft 365

ไม่ใช่เครื่องมือหลีกเลี่ยง Label

73. External User

หาก SharePoint มี Guest User

ควรตรวจว่าการแชร์ Agent และ Source เป็นไปตาม Policy

74. อย่าแชร์ Agent กว้างเกิน Source

ก่อนแชร์ควรดู Audience จริง

ไม่ใช่เพียงสะดวก

75. ตรวจข้อมูลส่วนบุคคล

HR Agent อาจมีข้อมูลที่ไม่ควรเปิดให้ทุกคน

ควรแยก Source อย่างเคร่งครัด

76. ตรวจข้อมูลการเงิน

Budget หรือ Commercial Data อาจต้องจำกัด Audience

77. ตรวจข้อมูลลูกค้า

ต้องเป็นไปตาม Privacy และนโยบายองค์กร

78. ตั้ง Owner ให้ Agent

Agent ควรมีผู้ดูแลจริง

เพื่อจัดการ Source และคุณภาพคำตอบ

79. กำหนด Content Owner

Source สำคัญควรมีเจ้าของ

เพื่ออัปเดตข้อมูลให้ทันสมัย

80. กำหนด Review Cycle

เช่น Review รายเดือนหรือรายไตรมาส

ตามประเภทข้อมูล

81. Agent ไม่ควรถูกสร้างแล้วปล่อยทิ้ง

Source สามารถเก่าได้

จึงต้อง Maintenance

82. ตรวจ Broken Sources

เอกสารอาจถูก Move หรือ Delete

ควรตรวจเป็นระยะ

83. ตรวจ Policy ใหม่

เมื่อ Policy เปลี่ยน

ต้องอัปเดต Source ของ Agent

84. ตรวจ Version ใหม่

เมื่อ Project Plan เปลี่ยน

ควรตรวจว่า Agent ใช้ข้อมูลใหม่

85. Prompt สำหรับ IT Agent

ตอบคำถามโดยใช้เฉพาะ IT Knowledge Base ที่กำหนด หากไม่พบข้อมูลให้บอกว่าไม่พบ และแนะนำให้ติดต่อ IT Support ตาม Contact ที่อยู่ใน Source เท่านั้น

86. Prompt สำหรับ HR Agent

ตอบคำถามเกี่ยวกับ Leave, Benefits และ Onboarding โดยใช้เฉพาะ Approved HR Policies และห้ามสร้างข้อกำหนดใหม่

87. Prompt สำหรับ Project Agent

ตอบคำถามเกี่ยวกับ Project Alpha จาก Project Plan, Meeting Notes, Risks และ Decisions ที่กำหนด โดยแยกข้อมูลที่ยัง Pending ออกจาก Final Decision

88. Prompt สำหรับ Sales Agent

ใช้เฉพาะ Approved Sales Materials และ Product Information ในการตอบ ห้ามสร้างราคา ส่วนลด หรือเงื่อนไขใหม่

89. Prompt สำหรับ Policy Agent

หาก Source หลายฉบับขัดกัน ให้แสดงชื่อเอกสารและข้อมูลของแต่ละ Source โดยไม่ตัดสินเองว่าอันไหนถูก

90. Prompt แบบปลอดภัย

ตอบจาก Source ที่กำหนดเท่านั้น หากไม่พบข้อมูลให้ตอบว่า “ไม่พบข้อมูลใน Source ที่ได้รับอนุญาต” ห้ามเดาชื่อ ตัวเลข วันที่ Owner, Policy หรือ Deadline และห้ามใช้ข้อมูลที่ผู้ใช้ไม่มีสิทธิ์เข้าถึง

เหมาะกับ Agent องค์กร

91. Workflow ที่แนะนำ

ใช้ลำดับ

กำหนด Use Case → กำหนด Audience → เลือก Source → เขียน Instructions → สร้าง Agent → Test → Review Permission → Pilot → Share

ช่วยลดความเสี่ยง

92. เริ่มจาก Use Case เล็ก

ไม่ควรสร้าง Agent ที่ตอบทุกเรื่องในองค์กรตั้งแต่วันแรก

เริ่มจากหัวข้อเฉพาะก่อน

93. ขยาย Scope ภายหลัง

เมื่อ Agent ตอบแม่นและ Source มีคุณภาพ

ค่อยเพิ่มข้อมูล

ช่วยควบคุมคุณภาพ

94. วัดว่า Agent มีประโยชน์หรือไม่

ดูว่า Agent ช่วย

• ลดเวลาค้น
• ลดคำถามซ้ำ
• เพิ่มการเข้าถึง Knowledge
• ลด Support Load

ได้จริงหรือไม่

95. Checklist ก่อนสร้าง Agent

ตรวจว่า

1. Use Case คืออะไร
2. Audience คือใคร
3. Source อยู่ที่ไหน
4. Source Approved หรือไม่
5. มี Version ซ้ำไหม
6. Permission ถูกไหม
7. Agent ต้องตอบแบบไหน
8. หากไม่พบข้อมูลให้ทำอย่างไร
9. ใครเป็น Owner
10. Review เมื่อไร

96. Checklist ก่อนแชร์ Agent

ตรวจ

1. ชื่อ Agent ชัดไหม
2. Description ชัดไหม
3. Source ถูกไหม
4. Version ถูกไหม
5. Instructions ชัดไหม
6. คำตอบ Fact ถูกไหม
7. คำถามที่ไม่มีข้อมูลไม่ถูกเดาใช่ไหม
8. Permission ถูกไหม
9. Pilot Test ผ่านไหม
10. Owner พร้อมดูแลไหม

97. คำถามที่พบบ่อย

สร้าง Agent ใน SharePoint ได้ไหม

ได้ในประสบการณ์ที่รองรับ โดยสามารถสร้าง Agent ที่ใช้ข้อมูล SharePoint เป็นบริบทสำหรับตอบคำถามได้

ต้องเขียนโปรแกรมไหม

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

Agent อ่านทุกไฟล์ใน SharePoint ได้ไหม

ไม่ควรคาดหวังเช่นนั้น การเข้าถึงขึ้นอยู่กับ Source ที่กำหนดและ Permission ของผู้ใช้

Agent สร้างคำตอบใหม่เองได้ไหม

สามารถสร้างคำตอบจากบริบทได้ แต่สำหรับข้อมูลสำคัญควรกำหนดให้ยึด Source และไม่เดาข้อมูลที่ไม่มี

ต้องมีคนดูแล Agent หรือไม่

ควรมี Owner เพื่อดูแล Source, Permission, Version และคุณภาพคำตอบ

98. สูตรสร้าง Agent ที่แนะนำ

ใช้หลัก

Use Case + Audience + Trusted Sources + Instructions + Missing Data Rule + Permission + Testing

ตัวอย่าง

สร้าง IT Support Agent สำหรับพนักงานทั่วไป ใช้เฉพาะ Approved IT Guides ตอบสั้นและเป็น Step-by-Step หากไม่พบข้อมูลให้แจ้งว่าไม่พบ ห้ามสร้าง Policy หรือ Contact ใหม่

99. Instructions พร้อมใช้

“คุณเป็น SharePoint Agent สำหรับตอบคำถามจาก Source ที่ได้รับอนุญาตเท่านั้น ให้ตอบโดยยึดข้อมูลในเอกสารและหน้า SharePoint ที่กำหนด รักษาชื่อ ตัวเลข วันที่ Owner, Policy, Scope และเงื่อนไขตามต้นฉบับ หากไม่พบคำตอบให้ระบุว่า ‘ไม่พบข้อมูลใน Source ที่ได้รับอนุญาต’ ห้ามคาดเดาหรือสร้างข้อเท็จจริงใหม่ หาก Source ขัดกันให้แสดงข้อมูลจากแต่ละ Source แยกกัน และอย่าตัดสินเองว่าอันไหนถูก”

เหมาะเป็นแนวทางตั้งต้นสำหรับ Agent

100. สรุป

วิธีสร้าง Agent ใน SharePoint ให้ได้ผลดีที่สุด คืออย่าเริ่มจากความคิดว่า

“สร้าง AI ที่ตอบได้ทุกอย่าง”

แต่ควรกำหนดให้ชัดว่า

Agent ช่วยเรื่องอะไร → ใครใช้ → ใช้ Source ไหน → Source ใดเชื่อถือได้ → ถ้าไม่พบข้อมูลให้ตอบอย่างไร → ใครดูแล Agent

SharePoint Agent เหมาะกับงาน เช่น

• IT Support
• HR Policy
• Project Q&A
• Sales Knowledge
• Compliance
• Knowledge Base

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

comsiam แนะนำให้ใช้หลัก “Agent เก่งได้เท่ากับ Source ที่เราให้มันใช้” ดังนั้นควรเริ่มจากขอบเขตเล็ก ใช้เอกสารที่ Approved ทดสอบกับคำถามจริง และมี Owner คอยอัปเดตข้อมูลอย่างต่อเนื่อง