AI Agent Glossary 04: Workflow, Tool Calling, API และ MCP

HR Agent ค้นนโยบายได้แล้ว แต่ทีมอยากให้มันเปิด ticket เมื่อหลักฐานไม่พอ คนหนึ่งเสนอ “ต่อ API” อีกคนเสนอ “ใช้ MCP” และอีกคนบอกให้ทํา multi-agent คําเหล่านี้ตอบคนละระดับของปัญหา ถ้าใช้แทนกัน architecture จะซับซ้อนโดยยังไม่รู้ว่าใครควบคุม action

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

Workflow คือเส้นทางจาก input ไป outcome

Workflow คือลําดับขั้นเพื่อบรรลุเป้าหมาย ใน workflow แบบกําหนดไว้ code เป็นผู้เลือกเส้นทาง ส่วนใน Agent โมเดลเลือกขั้นตอนหรือ tools แบบไดนามิกมากขึ้น

HR Agent อาจมี workflow คงที่:

รับคําถาม → ตรวจตัวตน → ค้นนโยบาย → สร้างร่างคําตอบ
→ ตรวจ citation → ถ้าหลักฐานไม่พอ ขออนุญาตเปิด ticket

การมี LLM ในทุกขั้นไม่ได้ทําให้ระบบเป็น Agent โดยอัตโนมัติ ถ้า code กําหนดว่าต้องเดินตามลูกศรใดเสมอ เรามี LLM workflow ที่คาดเดาเส้นทางได้ง่ายกว่า

Pattern ของ workflow ที่ใช้บ่อย

Prompt chaining แบ่งงานเป็น LLM calls ต่อกัน เช่น สกัดข้อเท็จจริง ตรวจความครบ แล้วเขียนคําตอบ ข้อดีคือแต่ละ call มีงานแคบและตรวจจุดกลางได้ ข้อแลกเปลี่ยนคือ latency เพิ่ม

Routing จําแนก input แล้วส่งไปเส้นทางเฉพาะ เช่น คําถาม payroll ไปทีมเงินเดือน ส่วนคําถามวันลาไป knowledge base อีกชุด Routing ไม่ใช่ handoff เสมอไป เพราะปลายทางอาจเป็น workflow หรือ model ไม่ใช่ Agent ที่รับการควบคุมต่อ

Parallelization รันงานอิสระพร้อมกัน เช่น ตรวจ citation และตรวจข้อมูลส่วนบุคคลคนละขั้น แล้วรวมผล มันไม่ใช่ multi-agent โดยจําเป็น เพราะงานย่อยอาจเป็น function หรือ LLM calls ธรรมดา

Orchestrator-workers ใช้โมเดลส่วนกลางแตกงานที่คาดล่วงหน้าได้ยาก มอบหมาย workers แล้วรวมผล เหมาะเมื่อจํานวนและชนิดงานย่อยเปลี่ยนตาม input แต่เพิ่มความยากในการติดตามและจํากัดขอบเขต

Evaluator-optimizer ให้ขั้นหนึ่งสร้าง output และอีกขั้นประเมินตามเกณฑ์ก่อนส่ง feedback กลับไปแก้ เหมาะเมื่อเกณฑ์ชัดและการแก้รอบต่อไปวัดได้ว่าเพิ่มคุณภาพจริง

Function calling ทําให้โมเดลเสนอ action ที่มีโครงสร้าง

Function calling หรือ tool calling คือกลไกให้โมเดลสร้างชื่อ function และ arguments ตาม schema ตัวอย่าง:

{
"name": "create_hr_ticket",
"arguments": {
"category": "leave_policy",
"summary": "เอกสารไม่ครอบคลุมกรณีดูแลสมาชิกครอบครัวหลังผ่าตัด"
}
}

ผลนี้ยังไม่ใช่ ticket application ต้องตรวจ schema, authorization, consent และ business rules ก่อนเรียก API จริง

Structured output บังคับให้ output ตรงรูปแบบ เช่น JSON Schema ช่วยลดปัญหา parse แต่ไม่ได้รับประกันว่าค่าใน field เป็นจริง policy_version: 2026 อาจอยู่ใน JSON ที่ถูก schema ทุกอย่างและยังเป็นข้อมูลแต่งได้

API คือสัญญาระหว่างซอฟต์แวร์

Application Programming Interface หรือ API คือสัญญาการสื่อสารระหว่างระบบ กําหนด operations, inputs, outputs, authentication และ errors

ในระบบ Agent API อาจเป็นช่องทางที่ application ใช้ค้นข้อมูลหรือสร้าง ticket ส่วน tool คือความสามารถที่ออกแบบและอธิบายให้โมเดลเลือกใช้ Tool หนึ่งตัวอาจเรียกหลาย API และ API เดียวอาจรองรับหลาย tools

Tool ที่ดีไม่ควรเปิด operation กว้างเกินงาน เช่น run_any_hr_action พร้อม string อิสระ ควรแยกเป็น tool ที่มีชื่อและ schema สื่อความหมาย จํากัดสิทธิ์ และออกแบบให้ผิดยาก

MCP มาตรฐานการเชื่อม context และ tools

Model Context Protocol หรือ MCP เป็นโปรโตคอลเปิดที่ทําให้ LLM applications เชื่อมข้อมูลและ tools ภายนอกด้วยรูปแบบมาตรฐาน Specification รุ่น 2026-07-28 ระบุการสื่อสารด้วย JSON-RPC, request แบบ stateless และ capability negotiation ต่อ request

MCP ไม่ใช่ Agent framework มันไม่ได้เลือก workflow หรือเขียน policy การอนุมัติให้เรา มันกําหนดวิธีที่ application ค้นพบและเรียกความสามารถจาก server

องค์ประกอบหลัก:

• Host: LLM application ที่ควบคุมประสบการณ์ผู้ใช้ context และนโยบายโดยรวม
• Client: connector ภายใน host ที่สื่อสารกับ MCP server หนึ่งตัว
• Server: บริการที่เปิดข้อมูลหรือความสามารถผ่าน MCP

ฝั่ง server มี primitives สําคัญสามแบบ:

• Resources: ข้อมูลเชิงบริบทที่ application เลือกอ่านและแนบให้โมเดล
• Prompts: template ที่ผู้ใช้เลือกเรียกเพื่อเริ่มงาน
• Tools: functions ที่โมเดลอาจเลือกเรียกเพื่ออ่านข้อมูลหรือทํา action

MCP Prompt ไม่ใช่ system prompt และ Resource ไม่ใช่ Tool ข้อมูลนโยบายที่อ่านได้ควรเป็น resource ส่วนการสร้าง ticket เป็น tool ที่มีผลต่อระบบ

Capability negotiation บอกว่าฝั่งใดรองรับอะไร

Capability negotiation คือการประกาศความสามารถที่ client และ server รองรับ เพื่อไม่ให้ application สมมติว่า feature ทุกอย่างมีอยู่ ในสเปกล่าสุด การค้นพบ capabilities และ primitives ผูกกับ request ที่ส่ง

การเชื่อม MCP สําเร็จจึงยังไม่แปลว่า Agent ใช้ tool ได้อย่างปลอดภัย Host ต้องควบคุม consent, authorization และข้อมูลที่ส่งข้ามขอบเขต ขณะที่ server ต้องตรวจสิทธิ์ของ operation จริง

Human-in-the-loop ต้องอยู่ตรงจุดที่เปลี่ยนผลลัพธ์

Human-in-the-loop หรือ HITL คือจุดที่มนุษย์ให้ข้อมูล ตรวจ ตัดสินใจ อนุมัติ หรือรับช่วงงาน ไม่ใช่เพียงมีคนอ่านรายงานหลังทุกอย่างเกิดขึ้นแล้ว

ใน HR Agent จุดอนุมัติควรอยู่ก่อนส่งข้อมูลส่วนบุคคลไปสร้าง ticket หน้าจอต้องบอกว่าจะส่งอะไร ไปที่ใคร และผู้ใช้ยกเลิกได้อย่างไร ถ้าให้คน “รับทราบ” หลัง ticket ถูกสร้าง นั่นคือ human-on-the-loop หรือ monitoring มากกว่าการควบคุมใน loop

เลือกส่วนประกอบจากปัญหา ไม่ใช่จากชื่อเทคโนโลยี

MCP ไม่ทําให้ Agent ฉลาดขึ้นเอง Multi-agent ไม่ทําให้ integration ปลอดภัยขึ้นเอง และ structured output ไม่ทําให้ข้อมูลจริงขึ้นเอง ทุกชั้นต้องตอบปัญหาที่มองเห็นและมีวิธีทดสอบ

แบบฝึกหัด: เขียน action contract

เลือก action หนึ่งอย่างที่ Agent ทําได้ แล้วเขียน contract ให้ครบ:

• ชื่อ tool ที่สื่อ outcome
• arguments และข้อจํากัดของแต่ละ field
• API หรือ service ที่ถูกเรียกจริง
• สิทธิ์ที่ต้องมี
• ผลสําเร็จและ error ที่คืน
• จุดขออนุมัติ
• หลักฐานที่บันทึกใน trace

งานผ่านเมื่อ reviewer แยกได้ว่าโมเดลเพียงเสนอ tool call ตอนไหน และระบบทํา action จริงตอนไหน รวมถึงหยุด action ที่ไม่มีสิทธิ์ได้โดยไม่พึ่งคําสั่งใน prompt

ตอนสุดท้ายจะดูหลักฐานหลังระบบทํางาน: eval, trace, guardrail และ governance ต้องประกอบกันอย่างไรจึงเรียกว่าพร้อมใช้

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

• Anthropic: Building effective agents
• OpenAI: Function calling
• OpenAI: Structured Outputs
• Model Context Protocol Specification 2026-07-28
• MCP Architecture 2026-07-28
• MCP Server features 2026-07-28

ตรวจสอบแหล่งอ้างอิงล่าสุด: 17 สิงหาคม 2026