API สำหรับ AI Agent: จาก MCP ถึง Endpoint แบบกำหนดเอง

เมื่อ LLM เรียนรู้การเรียกฟังก์ชัน

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

ฟีเจอร์ที่เปลี่ยนสิ่งนี้กลับได้รับการกล่าวถึงน้อยอย่างน่าประหลาดใจ ฟีเจอร์นี้ทำให้โมเดลมีทางเลือกระหว่างการสร้างข้อความกับการเรียกฟังก์ชัน แทนที่จะสร้างโทเค็นถัดไปเสมอ ตอนนี้โมเดลสามารถส่งออกออบเจ็กต์ JSON ที่มีโครงสร้างซึ่งระบุชื่อฟังก์ชันและอาร์กิวเมนต์ได้ runtime จะเรียกใช้ฟังก์ชันนั้น ส่งผลลัพธ์กลับไปให้โมเดล แล้วโมเดลจะทำงานต่อจากจุดนั้น งานวิจัย ReAct (Yao et al., 2022) ทำให้รูปแบบนี้ชัดเจนขึ้นในฐานะ Thought-Action-Observation loop โมเดลให้เหตุผลว่าควรทำอะไร ทำการกระทำหนึ่งอย่าง (เรียก tool) สังเกตผลลัพธ์ แล้วทำซ้ำ AI agent ที่จริงจังทุกตัวในปี 2026 ทำงานบนรูปแบบนี้ในบางเวอร์ชัน

ลูป

Claude Code, OpenClaw, Codex, Devin และระบบ agentic อื่น ๆ อีกหลายสิบระบบทำงานในลักษณะเดียวกันทั้งหมด เรียก tool สังเกตผลลัพธ์ ตัดสินใจว่าจะทำอะไรต่อ แล้วทำซ้ำ Simon Willison อธิบายไว้ดี: “LLM agent เรียกใช้ tools เป็นลูปเพื่อให้บรรลุเป้าหมาย”

ตัวอย่างเช่น Claude Code ใช้ single-threaded master loop โดยไม่มี multi-agent swarm หรือกราฟ orchestration ที่ซับซ้อน: while(tool_call) -> execute -> feed results -> repeat

งานวิจัยของ Anthropic เกี่ยวกับ autonomy ของ agent แสดงให้เห็นว่า ระยะเวลาของ turn ใน Claude Code เพิ่มขึ้นเกือบสองเท่า ภายในสามเดือน จาก 25 นาทีเป็นมากกว่า 45 นาที ผู้ใช้ไว้วางใจให้ลูปทำงานเองมากขึ้นเรื่อย ๆ ข้อมูลแสดงว่าผู้ใช้ที่มีประสบการณ์ขัดจังหวะ บ่อยขึ้น (เปลี่ยนจากการอนุมัติเป็นราย action ไปเป็นการติดตามเชิงกลยุทธ์) ในขณะที่ agent เองขอคำชี้แจงบ่อยกว่าที่ผู้ใช้ขัดจังหวะมากกว่าสองเท่า

รูปแบบลูปนี้พบได้ทั่วไป ทั้งใน coding agent, customer support bot และ robotics controller

อะไรนับเป็น Tool?

LLM ให้อิสระกับเรามากในการตัดสินใจว่า tool ควรทำงานที่ระดับ abstraction ใด ในสุดขั้วหนึ่ง คุณมี API endpoint ที่เฉพาะเจาะจงมาก เช่น “สร้าง HubSpot contact ด้วย 12 ฟิลด์เหล่านี้” อีกสุดขั้วหนึ่ง คุณมี tool อย่าง “รันคำสั่ง bash นี้” หรือ “เรียกใช้โค้ด Python นี้” ซึ่งโดยสาระแล้วคือ “ทำอะไรก็ได้ที่ต้องการ”

Devin ทำงานด้วย สาม tool: shell, code editor, browser tool หลักของ Claude Code ก็เป็น shell เช่นกัน OpenClaw ใช้ระบบ dynamic skills plugin แนวโน้มใน agentic coding tools คือการมี tool ที่น้อยลงและทั่วไปมากขึ้น แทนที่จะมี tool เฉพาะจำนวนมาก

Simon Willison สังเกตว่า MCP “initially exploded but then felt less central” สำหรับ coding agent เพราะ bash คือ tool สากล ไฟล์และสคริปต์เป็น primitive ที่มี overhead ต่ำกว่าการทำ MCP server เต็มรูปแบบ ถ้า agent เขียนและรันโค้ดได้ ก็สามารถทำได้แทบทุกอย่างโดยไม่ต้องมีคำจำกัดความของ tool เฉพาะ

แต่ tool อเนกประสงค์เหมาะกับ agent อเนกประสงค์ สำหรับ AI agent เฉพาะโดเมน (customer support, sales, internal operations) คุณต้องใช้ tool เฉพาะโดเมน support agent ของคุณไม่ควรเขียน Python เพื่อตรวจสอบสถานะคำสั่งซื้อ แต่ควรเรียก API endpoint ที่นิยามไว้อย่างชัดเจน มีพารามิเตอร์ชัดเจน และให้คำตอบที่คาดเดาได้ การออกแบบชุด tool ของคุณจึงกลายเป็นการตัดสินใจด้านผลิตภัณฑ์

API Endpoint หมายถึงอะไรในตอนนี้

สำหรับ AI agent, API endpoint ทำหน้าที่เป็นการประกาศความสามารถ การเผยแพร่ endpoint หนึ่งรายการหมายความว่าคุณ (หรือ AI agent ของคุณ) สามารถทำบางสิ่งที่ก่อนหน้านี้ทำไม่ได้แล้ว

สิ่งนี้ทำงานได้ทั้งสองทิศทาง ผู้ขายซอฟต์แวร์เผยแพร่ API เพื่อให้ผู้อื่นอินทิเกรตกับผลิตภัณฑ์ของตนได้ แต่ AI agent ก็สามารถค้นพบ endpoint ได้เองเช่นกัน ด้วยการค้นหาเอกสาร อ่าน OpenAPI spec หรือค้น Google ตรง ๆ ว่าจะทำงานหนึ่งให้สำเร็จได้อย่างไร

MCP server คือชุด API endpoint ที่คัดสรรไว้พร้อมแนวคิดล่วงหน้าว่าควรใช้งานอย่างไร ผู้สร้าง MCP ได้ตัดสินใจไว้แล้วว่าจะเปิดเผย endpoint ใด ตั้งชื่ออย่างไร แสดงพารามิเตอร์ใด และโดยนัยแล้วรองรับ workflow แบบใด การคัดสรรนี้เป็นทั้งจุดแข็ง (ความสะดวก, การทำให้เป็นมาตรฐาน) และจุดอ่อน (ความตายตัว, scope ที่มีมุมมองกำกับ) เซิร์ฟเวอร์ของ Notion เป็นตัวอย่างที่ชัดเจน: เซิร์ฟเวอร์เผยแพร่ tool 28 รายการ และ help-center agent ต้องใช้ 4 รายการ แบ่งข้าม 2 connection

MCP แลกการควบคุมกับความง่ายในการใช้งาน ในปี 2026 AI เขียนโค้ดอินทิเกรชันส่วนใหญ่ ถ้า agent อ่านเอกสาร API และเขียนอินทิเกรชันเองได้ ข้อโต้แย้งเรื่อง “ความง่ายในการใช้งาน” ของ MCP ก็อ่อนลง เลเยอร์ MCP อาจสำคัญที่สุดในช่วงเปลี่ยนผ่าน ในขณะที่เครื่องมือยังตามความสามารถของโมเดลไม่ทัน คู่มือของ Anthropic เกี่ยวกับ design pattern สำหรับ tool use เป็นข้อมูลอ้างอิงเชิงปฏิบัติสำหรับจัดโครงสร้าง tool schema ไม่ว่าคุณจะใช้ MCP หรือ endpoint แยกส่วน

พัฒนาการที่เกี่ยวข้อง: llms.txt เป็นมาตรฐานที่เสนอให้เว็บไซต์เผยแพร่ไฟล์ /llms.txt เพื่อชี้นำโมเดล AI ไปยังทรัพยากรที่มีคุณค่าสูง Anthropic, Cloudflare, Docker และ Stripe นำไปใช้แล้ว MCP ทำให้การเรียกใช้ tool เป็นมาตรฐาน ส่วน llms.txt ทำให้การค้นพบเอกสารเป็นมาตรฐาน ทั้งสองพยายามทำให้เว็บอ่านเข้าใจได้ง่ายขึ้นสำหรับเครื่องจักร แต่ทำจากคนละมุม

API endpoint คืออะไรในบริบทของ AI agent?

API endpoint คือ URL เฉพาะที่รับ input แบบมีโครงสร้างและส่งคืน output แบบมีโครงสร้าง สำหรับ AI agent แต่ละ endpoint แทนความสามารถที่แยกออกมาได้หนึ่งอย่าง ซึ่งเป็นสิ่งที่ agent สามารถทำได้ในโลกจริง คำอธิบายของ endpoint, คำจำกัดความพารามิเตอร์ และ error response ทำหน้าที่เป็นคู่มือการใช้งานของ agent ยิ่ง endpoint มีเอกสารดีเท่าไร agent ก็ยิ่งใช้งานได้อย่างน่าเชื่อถือมากขึ้นเท่านั้น

ต่างจากนักพัฒนามนุษย์ที่อ่าน tutorial และ debug แบบวนซ้ำได้ agent พึ่งพา schema และคำอธิบายของ endpoint เพื่อทำ call ที่ถูกต้องเพียงครั้งเดียว นี่คือเหตุผลที่ เอกสาร API ที่ออกแบบมาสำหรับการใช้งานโดย AI สำคัญยิ่งกว่าที่เคย มีเพียง 24% ของนักพัฒนาที่ออกแบบ API โดยคำนึงถึง AI agent ในปัจจุบัน แม้ว่า 89% จะใช้ AI ใน workflow ของตน

MCP (Model Context Protocol) คืออะไร?

MCP คือ open protocol ที่ Anthropic เปิดตัว ซึ่งทำให้วิธีที่ AI agent เชื่อมต่อกับ tool และแหล่งข้อมูลภายนอกเป็นมาตรฐาน ให้คิดว่าเป็น USB-C สำหรับ AI ตัวเชื่อมต่อเดียวที่ผู้ให้บริการ tool ใด ๆ สามารถ implement ได้ และ AI agent ใด ๆ สามารถใช้งานได้ MCP server เปิดเผยชุด tool (โดยสาระคือ API endpoint) พร้อม schema มาตรฐาน และ MCP client (agent) สามารถค้นพบและเรียกใช้ได้โดยไม่ต้องมีโค้ดอินทิเกรชันเฉพาะ หากต้องการคำอธิบายเชิงเทคนิคที่ลึกขึ้น โปรดดูโพสต์ อธิบาย MCP ของเรา หากต้องการมุมมองเชิงปฏิบัติของ MCP ในโปรดักชัน โปรดดูการวิเคราะห์ของเราเกี่ยวกับ ความท้าทายในโลกจริงเมื่อสร้างบน MCP ของ Shopify

สเปกตรัมของการควบคุมใน Quickchat AI

Quickchat AI ให้วิธี 3 แบบในการติดตั้ง tool ภายนอกให้ AI Agent วิธีเหล่านี้อยู่บนสเปกตรัมตั้งแต่อัตโนมัติมากที่สุดไปจนถึงควบคุมได้มากที่สุด แต่ละวิธีแลกเปลี่ยนความเร็วในการตั้งค่ากับความแม่นยำของพฤติกรรมต่างกัน

Remote MCP: เชื่อมต่อแล้วใช้งานได้ทันที

Remote MCP เป็นวิธีที่เร็วที่สุดในการเชื่อมต่อ AI Agent กับฟังก์ชันภายนอก คุณระบุ URL ของ MCP server, Quickchat AI เชื่อมต่อ ค้นพบ tool ทั้งหมดที่มี และให้คุณเลือกว่าจะให้ agent ของคุณใช้รายการใด

วิธีตั้งค่า:

1. ไปที่ AI Actions ใน dashboard ของ Quickchat AI
2. คลิก “Add Remote MCP”
3. วาง URL ของ MCP server (เช่น https://mcp.example.com/sse)
4. เลือกเพิ่ม authentication token หรือ custom headers ได้ (ทั้งสองอย่างใช้ร่วมกันไม่ได้)
5. คลิก “Connect.” Quickchat AI จะค้นพบ tool ทั้งหมดที่มีและแสดงชื่อของ tool เหล่านั้น
6. เปิดหรือปิด tool แต่ละรายการเพื่อควบคุมว่า agent ของคุณใช้รายการใดได้บ้าง
7. ตั้งค่า flag “default tool is active” เพื่อควบคุมว่า tool ที่ค้นพบใหม่จะถูกเปิดใช้งานหรือปิดใช้งานโดยอัตโนมัติ

สิ่งที่เกิดขึ้นภายในระบบ:

เมื่อคุณคลิก Connect, Quickchat AI จะตรวจจับ transport protocol จาก URL โดยอัตโนมัติ ถ้า URL มี sse จะใช้ SSE transport มิฉะนั้น streamable_http จะเป็นค่าเริ่มต้น เมื่อคุณระบุ auth token ระบบจะส่งเป็น token แบบ Bearer ใน header Authorization

Tool filtering ทำงานผ่านระบบสามชั้น tool แต่ละรายการจาก MCP server จะถูกตรวจสอบกับชุดข้อมูลสองชุด: tool ที่เปิดใช้งานอย่างชัดเจนจะถูกรวมเสมอ, tool ที่ปิดใช้งานอย่างชัดเจนจะถูกตัดออกเสมอ และ tool ใด ๆ ที่ไม่อยู่ในทั้งสองชุดจะย้อนกลับไปใช้การตั้งค่า “default tool is active” ที่คุณเลือก ซึ่งหมายความว่าเมื่อ MCP server เพิ่ม tool ใหม่ คุณควบคุมได้ว่าจะให้ tool เหล่านั้นพร้อมใช้งานกับ agent ของคุณโดยอัตโนมัติ หรือต้องเปิดใช้งานอย่างชัดเจนก่อน

ใน runtime เมื่อ conversation เริ่มต้น connection ของ Remote MCP ที่ active ทั้งหมดสำหรับ agent จะถูกโหลด ระบบจะดึง tool และกรองตาม configuration ของแต่ละ connection และตรวจสอบว่า tool name ไม่ซ้ำกันในทุกแหล่งที่มา (พร้อม warning หากพบรายการซ้ำ)

ข้อแลกเปลี่ยน: คุณเข้าถึงทุกอย่างที่ MCP เปิดเผยได้ทันที แต่ควบคุมคำอธิบาย tool, คำจำกัดความพารามิเตอร์ หรือวิธีที่ agent ตัดสินใจใช้งานได้จำกัด ดังที่เราพบเมื่อ สร้าง AI Agent บน MCP ของ Shopify การเปลี่ยนจาก demo ไปสู่โปรดักชันต้องปรับแต่งอย่างระมัดระวัง ซึ่งแนวทางแบบ bundle ของ MCP อาจทำให้ยากขึ้น

ดูเพิ่มเติม: เชื่อมต่อ agent ของคุณกับ remote MCP server, วิธีเปิดตัว Quickchat AI MCP ของคุณ, ข้อควรพิจารณาด้านความปลอดภัยของ MCP, เอกสาร Quickchat AI: MCP channel

AI Actions (HTTP Request): หนึ่ง Endpoint, ควบคุมเต็มรูปแบบ

AI Action ใน Quickchat AI คือ HTTP API endpoint เดี่ยวที่คุณ configure แยกสำหรับ AI Agent ของคุณ MCP นำเข้า bundle ของ tool หลายรายการในคราวเดียว แต่ AI Action แต่ละรายการให้คุณควบคุมความสามารถเฉพาะหนึ่งอย่างได้เต็มที่ สำหรับตัวอย่างที่ทำครบถ้วน ซึ่งมี 4 actions ที่สร้างและเติมข้อมูล contacts, log deals และเปิด tickets ใน CRM โปรดดู tutorial HubSpot AI Actions

การ configure AI Action:

1. Name (สูงสุด 64 อักขระ): สิ่งนี้จะกลายเป็นชื่อ tool ที่ LLM เห็น ระบบจะ normalize ให้เป็น identifier ที่ถูกต้อง (เช่น “Check Order Status” จะกลายเป็น Check_Order_Status)
2. Description (สูงสุด 1,000 อักขระ): นี่คือฟิลด์ที่สำคัญที่สุด คำอธิบายจะบอก LLM ว่า เมื่อใด ควรใช้ tool นี้ คำอธิบายที่ดีระบุว่าควรเรียกใช้เมื่อมีสถานการณ์การสนทนาแบบใด ต้องรวบรวมข้อมูลอะไรจากผู้ใช้ก่อน และควรสื่อสารผลลัพธ์กลับอย่างไร
3. HTTP method: GET, POST, PATCH, DELETE หรือ PUT
4. URL (สูงสุด 10,000 อักขระ): สามารถมี placeholder {{parameter_name}} สำหรับค่าที่เปลี่ยนแปลงได้
5. Headers: คู่ key-value สำหรับ authentication และ content type
6. Body items / Body JSON: request body พร้อมการ inject พารามิเตอร์
7. Query parameters: ค่าของ URL query string
8. Parameters (สูงสุด 10): แต่ละรายการมีชื่อ, คำอธิบาย (สูงสุด 500 อักขระ), type (str, int, float, bool หรือ custom), flag required และค่า default ที่เป็น optional

Placeholder {{parameter_name}} คือกลไกหลัก เมื่อ LLM เรียก tool ระบบจะให้ค่าของแต่ละ parameter ตาม context ของ conversation จากนั้น Quickchat AI จะ inject ค่าเหล่านั้นเข้าไปใน template ของ URL, headers, body และ query string ก่อนส่ง HTTP request นอกจากนี้ยังมีตัวแปร built-in 4 ตัวที่สามารถ inject ด้วยวิธีนี้ได้: scenario_id, conversation_id, conversation_channel และ conversation_url

AI Action ที่ configure เพื่อตรวจสอบสถานะคำสั่งซื้อ แสดง URL template พร้อม parameter placeholder, headers และคำจำกัดความพารามิเตอร์

ภายในระบบ: Quickchat AI สร้าง typed schema แบบไดนามิกจากคำจำกัดความ parameter ของคุณสำหรับ AI Action แต่ละรายการ type ที่รองรับ 5 แบบ (str, int, float, bool, custom) จะถูก map ไปยัง equivalent แบบ native และ schema นี้ใช้ validate input ของ LLM ก่อนส่ง HTTP request

ตัวอย่าง AI Action สำหรับตรวจสอบสถานะคำสั่งซื้อ:

{
  "name": "check_order_status",
  "description": "เมื่อผู้ใช้ถามเกี่ยวกับสถานะคำสั่งซื้อและระบุหมายเลขคำสั่งซื้อแล้ว ให้เรียก endpoint นี้เพื่อดึงสถานะปัจจุบัน รายงานสถานะ วันที่จัดส่งโดยประมาณ และหมายเลขติดตามพัสดุ (ถ้ามี) กลับไปยังผู้ใช้",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "รหัสคำสั่งซื้อที่ผู้ใช้ระบุ (เช่น ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

การทดสอบ: dashboard มีปุ่ม “Test” ที่ให้คุณระบุค่าพารามิเตอร์ตัวอย่างและดู HTTP request จริง (รวมถึงคำสั่ง curl ที่สร้างขึ้น) และ response ก่อน deploy

คำแนะนำในการเขียนคำอธิบาย AI Action ที่มีประสิทธิภาพ:

• ระบุให้ชัดเจนว่า agent ควรเรียกใช้เมื่อใด: “เมื่อผู้ใช้ถามเกี่ยวกับสถานะคำสั่งซื้อและระบุหมายเลขคำสั่งซื้อ ให้เรียก endpoint นี้”
• ระบุข้อมูลที่ต้องเก็บก่อน: “ก่อนเรียกใช้ ให้แน่ใจว่าคุณมีที่อยู่อีเมลและรหัสคำสั่งซื้อของผู้ใช้”
• อธิบายวิธีจัดการ response: “ถ้าสถานะคือ ‘shipped’ ให้บอกหมายเลขติดตามพัสดุจาก response แก่ผู้ใช้”
• สำหรับ workflow หลายขั้นตอน ให้อธิบายลำดับใน system prompt หลักของ agent แทนที่จะใส่ในคำอธิบาย action แต่ละรายการ และเพื่อ ส่งต่อค่าระหว่าง actions และกั้นการเขียนด้วยค่านั้น ให้ใช้ Save to memory ร่วมกับ run-condition

ตัวอย่างที่ทำครบถ้วน: สำหรับ AI Action แบบทีละขั้นตอนที่ log leads, คำถามที่ยังไม่ได้ตอบ และคำขอ demo ลง spreadsheet โดยตรง โปรดดู วิธีเชื่อมต่อ AI agent กับ Google Sheets

Generate from Text: ให้ AI หาวิธีเอง

ตัวเลือกที่สามเหมาะสำหรับผู้ใช้ที่รู้ว่าต้องการให้ agent ทำอะไร แต่ไม่รู้ว่าควรใช้ API endpoint ใด (หรือแม้แต่บริการใด)

วิธีทำงาน:

1. คุณพิมพ์คำอธิบายภาษาธรรมชาติของสิ่งที่ต้องการ เช่น “ฉันต้องการให้ AI Agent ของฉันสามารถสตาร์ทรถ Tesla ของผู้ใช้เมื่อผู้ใช้ร้องขอ”
2. Quickchat AI ส่งสิ่งนี้ไปยัง LLM โดยเปิดใช้ tool web_search
3. โมเดลค้นคว้าบนเว็บเพื่อหา API ที่เหมาะสม อ่านเอกสารทางการ และสร้าง specification ของ AI Action ที่สมบูรณ์ รวมถึง URL, method, headers, parameters และข้อกำหนดด้าน authentication
4. ผลลัพธ์ส่งกลับมาพร้อม configuration ของ action ทั้งหมด, citation ไปยังเอกสารที่ใช้ และข้อความอธิบายที่ระบุ assumption และ gap
5. คุณตรวจสอบ กรอก credentials และ activate

การป้อนคำอธิบายภาษาธรรมชาติของความสามารถที่ต้องการ

Configuration ของ AI Action ที่สร้างขึ้น พร้อม citation ไปยังเอกสาร API ที่ใช้

การสร้าง AI Action อัตโนมัติถูกจัดโครงสร้างรอบ priority 3 ข้อ:

• Priority 1: เข้าใจ intent. ระบุความสามารถที่แน่นอนที่นักพัฒนาต้องการและ API endpoint เฉพาะที่ให้ความสามารถนั้น
• Priority 2: ยึดกับเอกสาร. ใช้ web search เพื่อหาเอกสารทางการของ vendor ไม่ใช่การเดา
• Priority 3: ออกแบบ semantics ที่ยึด conversation เป็นหลัก. name และ description ที่สร้างขึ้นควรเกี่ยวกับว่า tool นี้ถูกใช้ เมื่อใดในการสนทนา ไม่ใช่แค่ API ทำอะไรในเชิงเทคนิค

Prompt ใช้ convention ของ placeholder 2 แบบ {{param}} ทำเครื่องหมาย runtime parameter ที่ LLM เติมจาก context ของ conversation [[secret_name]] (วงเล็บเหลี่ยมคู่) ทำเครื่องหมายค่าคงที่ของนักพัฒนา เช่น API key และ account ID ที่ต้อง configure ด้วยตนเองก่อน activate ชื่อ parameter ทุกชื่อต้องปรากฏเป็น placeholder {{that_exact_name}} ที่ไหนสักแห่งใน request definition และต้องไม่มี placeholder ที่ไม่มีที่อ้างอิง

ระบบใช้ fail-closed policy หากโมเดลไม่สามารถยืนยันข้อมูลสำคัญจากเอกสารได้ (HTTP method, URL, authentication scheme หรือโครงสร้าง payload ที่จำเป็น) จะไม่มีการสร้าง action แต่ระบบจะส่งคำอธิบายสั้น ๆ ของสิ่งที่ขาดหายไปแทนการเดา

นี่คือจุดที่แนวคิดเชิงปรัชญาเกี่ยวกับ AI agent ที่ค้นพบ API เชื่อมกับฟีเจอร์ผลิตภัณฑ์ที่เป็นรูปธรรม ฟีเจอร์ Generate from Text คือ AI agent ตัวหนึ่ง (LLM ที่มี web search) สร้างคำจำกัดความของ tool ให้ AI agent อีกตัวหนึ่ง (Quickchat AI agent ที่จะใช้สิ่งนั้นในการสนทนา) อย่างแท้จริง

ตัวอย่างที่ทำครบถ้วน: สำหรับ tutorial ฉบับเต็มที่เปลี่ยนประโยคที่พิมพ์ 2 ประโยคให้เป็น action ที่ใช้งานจริงและทดสอบแล้ว 2 รายการ (การดูสภาพอากาศแบบไม่ใช้ key และ NASA แบบใช้ key รวมถึงการปฏิเสธแบบ fail-closed) โปรดดู วิธีเชื่อมต่อ AI agent ของคุณกับ API ใดก็ได้ด้วยภาษาอังกฤษธรรมดา

ใน runtime, tool type ทั้งหมดเหล่านี้จะถูกประกอบเข้าด้วยกัน Quickchat AI รวบรวม HTTP request AI Action tools, Shopify MCP tools, knowledge base tools, remote MCP tools, Discord tools และ custom tools อื่น ๆ เข้าเป็น collection เพื่อนำเสนอให้ LLM โมเดลไม่เห็นความแตกต่างระหว่างสิ่งเหล่านี้ Remote MCP tool และ AI Action ที่ configure ด้วยตนเองจะดูเหมือนกันเมื่ออยู่ในรายการ tool แล้ว

Open API ในฐานะ SEO แบบใหม่

ถ้า AI agent จะค้นพบและใช้ API โดยอัตโนมัติ การมี API ที่จัดทำเอกสารดีและใช้งานง่ายจะกลายเป็นสินทรัพย์ด้านการกระจายการใช้งาน Gartner คาดการณ์ ว่ามากกว่า 30% ของความต้องการ API ที่เพิ่มขึ้นจะมาจาก AI agent ภายในปี 2026

บริษัทที่มี open API พร้อมอุปสรรคด้าน credential ต่ำอาจพบว่า API ของตนกลายเป็นช่องทาง acquisition ที่ดีที่สุด แทนที่จะเป็น impression จาก Google search, “impression” คือ AI agent ที่เลือกใช้บริการของคุณแทนบริการของคู่แข่ง

ตรรกะเดียวกันใช้ได้ในระดับที่สูงขึ้นหนึ่งระดับ AI agent ที่ตอบจากเอกสารของคุณสามารถ ถูกเปิดเผยเป็น MCP server ที่ ChatGPT, Claude และ Cursor เรียกใช้เป็น tool ได้ ซึ่งทำให้ความรู้ของคุณ ไม่ใช่แค่ API ของคุณ ค้นพบได้โดย agentic web

คุณภาพของเอกสาร API ของคุณเป็นตัวกำหนดว่า AI agent จะสามารถอินทิเกรตกับคุณสำเร็จในการลองครั้งเดียวหรือไม่ คำอธิบายพารามิเตอร์, ข้อความ error และ response ตัวอย่างทำหน้าที่เดียวกับ meta description และ structured data ใน SEO แบบดั้งเดิม response error ที่สับสนหรือ required field ที่ไม่มีเอกสารหมายความว่า agent จะล้มเหลว และไม่มีมนุษย์อยู่อีกฝั่งเพื่อ debug

บริษัทที่ API ไม่มีเอกสารหรือถูกกั้นด้วยข้อกำหนด credential ที่หนักมากอาจพบว่าตนเองล่องหนต่อ agentic web เช่นเดียวกับที่บริษัทที่ไม่มีเว็บไซต์เคยล่องหนต่อ Google ในยุค 2000s

Computer Use เทียบกับ API

มีการลงทุนอย่างมากในการสอนโมเดล AI ให้ทำ “computer use” (คลิกปุ่ม, กรอกฟอร์ม, นำทาง UI) Anthropic, OpenAI (Operator) และโครงการ open-source อย่าง Browser Use ต่างก็มีเวอร์ชันของสิ่งนี้

แต่การใช้ browser เป็นวิธีแก้ปัญหาเฉพาะหน้าสำหรับ API ที่ไม่มีอยู่ การเรียก POST /orders ใช้เวลาเป็นมิลลิวินาทีและส่งคืนข้อมูลที่มีโครงสร้าง browser agent ที่นำทาง checkout flow ใช้เวลาหลายนาทีและอาจพังเมื่อปุ่มขยับไปทางซ้าย 3 พิกเซล API เร็วกว่า deterministic กว่า และถูกกว่าในการ execute

ข้อโต้แย้งมีอยู่จริง: API ไม่ได้มีอยู่สำหรับทุกอย่าง ระบบ legacy, enterprise software ที่ไม่มี API surface, อุปกรณ์กายภาพที่ควบคุมผ่าน GUI Computer use เติมช่องว่างจริงในกรณีเหล่านั้น

คำตอบระยะยาวที่ดีกว่าสำหรับ “เราไม่มี API สำหรับสิ่งนี้” น่าจะเป็นการสร้าง API แทนที่จะสอน AI ให้ใช้ GUI เมื่อซอฟต์แวร์ถูกเขียนโดย AI agent เพื่อ AI agent มากขึ้น ต้นทุนในการสร้างและดูแล API จะลดลง การคำนวณทางเศรษฐศาสตร์ที่เคยทำให้การ scrape UI ถูกกว่าการสร้าง API กำลังเปลี่ยนไป

ยังมีมุมด้านความปลอดภัยด้วย “lethal trifecta” ของ Simon Willison อธิบายการผสมผสานที่อันตรายของ การเข้าถึงข้อมูลส่วนตัว + การเปิดรับเนื้อหาที่ไม่น่าเชื่อถือ + การสื่อสารภายนอก สิ่งนี้ใช้ได้กับทั้งสองแนวทาง แต่ tool ที่อิง API ตรวจสอบและจำกัดได้ง่ายกว่า คุณสามารถ log ทุก API call, validate ทุก parameter และ rate-limit ทุก endpoint การทำสิ่งเทียบเท่าสำหรับ browser agent ที่คลิกอะไรก็ได้ยากกว่ามาก

Tool สำหรับโลกกายภาพ

ทุกอย่างที่กล่าวมาจนถึงตอนนี้เกี่ยวกับซอฟต์แวร์ รูปแบบเดียวกันปรากฏในโลกกายภาพด้วย

RT-2 และ Gemini Robotics ของ Google DeepMind ใช้สถาปัตยกรรมเดียวกัน เพียงแต่ tool ส่งคำสั่งไปยัง actuator แทน API framework SPCA (Sense-Plan-Code-Act) ทำให้สิ่งนี้เป็นรูปแบบชัดเจนสำหรับ robotics: scan สภาพแวดล้อม, plan แนวทาง, generate โค้ดที่ execute ได้, execute, สังเกตผลลัพธ์

ไม่มี API สำหรับ “ย้ายต้นไม้บนโต๊ะของฉันไปทางขวา” แต่หุ่นยนต์ที่มีกล้องอาจกำหนด move_object(object_id="plant_01", direction="right", distance_cm=15) เป็น tool ได้ทันทีแล้วเรียกใช้ คำจำกัดความของ tool ทำหน้าที่เป็น interface ระหว่าง reasoning layer กับ physical execution layer ซึ่งเป็นบทบาทเดียวกับที่ API endpoint ทำในซอฟต์แวร์

สถาปัตยกรรม LLM + tools + loop เป็นแบบอเนกประสงค์ วันนี้สิ่งนี้ implement ในซอฟต์แวร์ได้ง่ายที่สุด แต่ robotics กำลังตามมา

API ที่เขียนโดย AI เพื่อ AI

ในช่วงประมาณสองปี (2024 ถึง 2026) เราเปลี่ยนจากโค้ดส่วนใหญ่ถูกเขียนโดยมนุษย์ ไปสู่ โค้ดส่วนใหญ่ถูกเขียนโดย AI นี่เป็นจังหวะที่ดีในการทบทวนว่า API endpoint คืออะไร มากขึ้นเรื่อย ๆ endpoint คือ การประกาศความสามารถ ที่ออกแบบมาให้เครื่องจักรค้นพบและ execute ไม่ใช่ interface เชิงเทคนิคให้มนุษย์นักพัฒนาอ่านเอกสารแล้วอินทิเกรตด้วยตนเอง

MCP เป็นเลเยอร์มาตรฐานที่มีประโยชน์ แต่ก็เป็นเลเยอร์การคัดสรรที่นำ bias เข้ามาด้วย ผู้สร้าง MCP เป็นผู้ตัดสินใจว่าจะเปิดเผย tool ใดและจัดกรอบอย่างไร สำหรับ AI agent ในโปรดักชัน กรอบนั้นอาจไม่ตรงกับสิ่งที่คุณต้องการจริง ๆ (เราเขียนเรื่องนี้โดยละเอียดเมื่อวิเคราะห์ ความท้าทายกับ MCP ของ Shopify)

สเปกตรัมที่เราอธิบายใน Quickchat AI Agents สะท้อนประเด็นที่กว้างกว่า ระดับการควบคุมที่เหมาะสมขึ้นอยู่กับ use case ของคุณ Remote MCP เหมาะกับการทำต้นแบบอย่างรวดเร็ว AI Actions แยกส่วน ให้การควบคุมละเอียดสำหรับ agent ที่ติดต่อกับลูกค้าในโปรดักชัน Generate from Text ให้ AI ค้นคว้า API และสร้างคำจำกัดความของ tool ให้คุณในช่วงที่คุณยังสำรวจอยู่

และในทุกระดับ รูปแบบพื้นฐานเหมือนกัน LLM หนึ่งตัว, ชุด tool หนึ่งชุด, ลูปหนึ่งวง ไม่ว่า tool จะเป็นคำสั่ง bash, API endpoint, MCP server หรือ actuator ของหุ่นยนต์ ทุกอย่างล้วนเป็น tool ซ้อนลงไปเรื่อย ๆ.