ทำ AI Agent ใช้ Tools ได้จริงด้วย OpenAI Responses API และ MCP

บทความนี้พาคุณสร้าง AI Agent ที่เรียกใช้เครื่องมือภายนอกได้แบบเป็นระบบ ตั้งแต่ต่อ OpenAI Responses API, ออกแบบ tool schema, เชื่อม MCP server ไปจนถึงจัดการ state และ error เพื่อพร้อมใช้ในงานจริง

AI Agent, OpenAI, Responses API, MCP, Tutorial

ถ้าคุณอยากให้ AI Agent ไม่ได้แค่ตอบข้อความ แต่สามารถ เรียกใช้เครื่องมือภายนอก เช่น ค้นข้อมูล ดึงสถานะระบบ หรือสั่งงาน backend ได้อย่างเป็นขั้นเป็นตอน บทความนี้จะพาคุณทำตั้งแต่ต้นจนจบ โดยใช้ OpenAI Responses API เป็นแกนหลัก และใช้แนวคิด MCP เพื่อทำให้การเชื่อมต่อ tools เป็นมาตรฐานมากขึ้น หลังอ่านจบคุณจะได้ agent prototype ที่รับคำสั่งผู้ใช้ ตัดสินใจเรียก tool ได้เอง จัดการ state ระหว่างรอบสนทนา และรับมือ error ที่เจอในงานจริงได้ โดยควรมีพื้นฐาน JavaScript หรือ TypeScript, เข้าใจ REST API เบื้องต้น และมี environment สำหรับรัน Node.js

Step 1: ตั้งต้นโปรเจกต์และเชื่อม OpenAI Responses API

เริ่มจากแยกความรับผิดชอบของระบบออกเป็น 3 ส่วนก่อน คือ ตัว agent, ชุดเครื่องมือ, และ state ของการสนทนา เหตุผลที่ต้องแยกตั้งแต่แรก เพราะเมื่อโปรเจกต์โตขึ้น คุณจะ debug และเปลี่ยน implementation ได้ง่ายกว่า

ตัวอย่างโค้ดฝั่ง Node.js สำหรับเรียก Responses API:

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const response = await client.responses.create({
  model: "gpt-4.1",
  input: [
    {
      role: "user",
      content: "ช่วยตรวจสอบสถานะ order A1024 ให้หน่อย"
    }
  ]
});

console.log(response.output_text);

ในขั้นนี้เป้าหมายไม่ใช่ให้ model ใช้ tool ทันที แต่ต้องพิสูจน์ก่อนว่า flow พื้นฐานทำงานได้จริง จากนั้นค่อยเพิ่มความสามารถเรื่อง tool calling เข้าไปทีละชั้น

สิ่งที่ควรเตรียมเพิ่ม:

> แนวคิดสำคัญคือ อย่าผูก logic ธุรกิจไว้ใน prompt ทั้งหมด ควรมี application layer คอยควบคุม flow เสมอ

Step 2: ออกแบบ tool schema ให้ model ใช้งานได้แม่น

หัวใจของ agent ที่ใช้เครื่องมือได้จริงคือ schema ของ tool ถ้าออกแบบไม่ชัด model จะเรียกพารามิเตอร์ผิด หรือใช้เครื่องมือไม่ตรงงาน วิธีคิดที่ดีคือทำ schema ให้เหมือน API contract ที่คนอ่านแล้วเข้าใจทันที

ตัวอย่าง tool สำหรับเช็กสถานะ order:

const tools = [
  {
    type: "function",
    name: "get_order_status",
    description: "ใช้สำหรับดึงสถานะล่าสุดของคำสั่งซื้อจากหมายเลข order",
    parameters: {
      type: "object",
      properties: {
        order_id: {
          type: "string",
          description: "รหัสคำสั่งซื้อ เช่น A1024"
        }
      },
      required: ["order_id"],
      additionalProperties: false
    }
  }
];

หลักการออกแบบที่สำคัญ:

เมื่อส่ง tools เข้า Responses API model จะสามารถตัดสินใจได้ว่าควรตอบเอง หรือควรเรียก function ก่อน แล้วค่อยสรุปผลกลับให้ผู้ใช้

Step 3: เชื่อม MCP server เพื่อรวมเครื่องมือภายนอกอย่างเป็นระบบ

เมื่อ tools มีหลายตัว การเขียน adapter เฉพาะกิจทีละตัวจะเริ่มดูแลยาก จุดเด่นของ MCP คือช่วยให้ agent คุยกับแหล่งเครื่องมือต่าง ๆ ผ่านรูปแบบมาตรฐานเดียว แนวทางปฏิบัติคือให้ MCP server เป็นชั้นกลางที่เปิดรายการ tools ออกมา แล้วฝั่ง agent ค่อย map เข้ากับ schema ที่ model ใช้

ตัวอย่างโครงสร้าง flow:

ตัวอย่าง pseudo-code:

async function runToolCall(toolName, args) {
  const result = await mcpClient.callTool({
    name: toolName,
    arguments: args
  });

  return result;
}

ข้อดีของวิธีนี้คือ:

Step 4: จัดการ state, tool result และ error สำหรับงานจริง

ระบบ agent ที่ใช้ได้จริงต้องคิดเรื่อง state management ตั้งแต่แรก เพราะคำตอบในรอบถัดไปมักขึ้นอยู่กับผลของ tool call ก่อนหน้า เช่น ผู้ใช้อาจถามต่อว่า "แล้วส่งถึงเมื่อไร" หลังจากเพิ่งถามเรื่อง order เดิมไป

แนวทางที่ควรทำ:

ตัวอย่างโค้ดจัดการ error:

async function safeToolExecution(toolName, args) {
  try {
    const result = await runToolCall(toolName, args);
    return { ok: true, data: result };
  } catch (error) {
    return {
      ok: false,
      error: "TOOL_EXECUTION_FAILED",
      message: `เรียก ${toolName} ไม่สำเร็จ`
    };
  }
}

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

Troubleshooting / Tips

ปัญหาที่เจอบ่อยเมื่อลองทำ agent แบบนี้มีไม่กี่กลุ่ม แต่ถ้ารู้วิธีแก้จะประหยัดเวลาได้มาก

สรุปแล้ว การทำ AI Agent ให้ใช้เครื่องมือได้จริงไม่ได้จบแค่เปิด function calling แต่ต้องออกแบบทั้ง schema, orchestration, MCP integration, state และ error handling ให้ครบเป็นระบบ ถ้าคุณทำ 4 ส่วนนี้ได้ solid agent ของคุณจะพร้อมต่อยอดไปสู่ use case ที่ซับซ้อนขึ้น เช่น agent สำหรับ support, operations dashboard, หรือ internal workflow automation ได้ทันที

กลับไปยังบล็อก OVERFLOW