LLM ไม่ได้อยู่แค่ในหน้าเว็บแชตอีกต่อไป

ทุกวันนี้ผู้ให้บริการ LLM เจ้าหลัก ๆ ไม่ว่าจะเป็น OpenAI, Google Gemini, Anthropic Claude หรือผู้ให้บริการรวมอย่าง OpenRouter ต่างเปิด API ให้เราเรียกใช้โมเดลจากโค้ดของเราเองได้แล้ว นั่นแปลว่าเราไม่จำเป็นต้องใช้ AI ผ่านหน้าเว็บของเขาอย่างเดียว แต่สามารถ “ออกแบบผู้ช่วย AI ของตัวเอง” ที่คิด ตอบ และทำงานตามกติกาที่เรากำหนดได้

ปัญหาคือรายละเอียดของ API แต่ละเจ้ายังไม่เหมือนกัน ทั้งรูปแบบข้อความ วิธีส่ง tool วิธี stream ผลลัพธ์ และความสามารถเฉพาะของแต่ละโมเดล ถ้าเขียนชั้นเชื่อมต่อเองทุกเจ้าจะเหนื่อยมาก ตรงนี้เองที่ไลบรารีอย่าง LangChain เข้ามาช่วย ด้วย model interface และ integration สำหรับผู้ให้บริการหลายเจ้า ทำให้โค้ดส่วน agent ใช้รูปแบบร่วมกันได้มากขึ้น โดยยังเปิดให้ตั้งค่าความสามารถเฉพาะของแต่ละเจ้าได้เมื่อจำเป็น

ในบทความนี้ผมจะเล่า 3 เครื่องมือใน stack เดียวกัน คือ LangChain, LangGraph และ Deep Agents ว่าแต่ละตัวเหมาะกับงานแบบไหน ต่อกันอย่างไร และปิดท้ายด้วยวิธีที่ผมเอาทั้งสามตัวมาประยุกต์ใช้จริงในโปรเจกต์

หมายเหตุเรื่องเวอร์ชัน: API ของเครื่องมือกลุ่มนี้เปลี่ยนเร็ว ตัวอย่างและข้อสังเกตในบทความตรวจสอบกับ langchain 1.5.x, @langchain/langgraph 1.4.x, deepagents 1.13.x และ @langchain/mcp-adapters 1.1.x ณ วันที่ 4 กันยายน 2026

สรุปสั้น ๆ

  • ถ้า agent loop มาตรฐานที่ประกอบด้วยโมเดล, tool และ middleware ก็เพียงพอ ให้เริ่มที่ LangChain
  • ถ้าต้องออกแบบกราฟการทำงานเอง มี state หลายขั้น แตกเงื่อนไข หรือหยุดแล้วกลับมาทำต่อ ให้ลงไปใช้ LangGraph โดยตรง
  • ถ้าเป็นงานซับซ้อนและยาวที่อยากได้ planning, filesystem และ subagent มาให้พร้อมใช้ ให้เริ่มที่ Deep Agents

สามตัวนี้ไม่ได้แข่งกัน และไม่ได้บังคับให้เราไล่ใช้ทีละชั้น Agent API ของ LangChain เป็น framework ระดับสูงที่รันบน LangGraph ส่วน Deep Agents เป็น agent harness สำเร็จรูปที่ประกอบความสามารถหลายอย่างมาให้ เราจึงเลือกจุดเริ่มต้นตามระดับการควบคุมที่งานต้องการได้

หนึ่ง stack · สามจุดเริ่มต้นเลือกชั้นที่ตรงกับระดับการควบคุมของงานทั้งสามตัวทำงานร่วมกันได้ แต่ไม่จำเป็นต้องเริ่มจากชั้นล่างแล้วประกอบขึ้นมาทุกครั้ง
  1. Deep AgentsHarness

    เริ่มตรงนี้เมื่องานยาวและซับซ้อน ต้องวางแผน ใช้ไฟล์ หรือแบ่งงานให้ subagent

    Planning · filesystem · subagents · context management

    ประกอบจาก building blocks ของ LangChain และรันบน LangGraph

  2. LangChainFramework

    เริ่มตรงนี้เมื่อagent loop มาตรฐานที่มีโมเดล, tool และ middleware ก็เพียงพอ

    Model interface · tools · middleware · agent loop

    Agent API รันบน LangGraph

  3. LangGraphRuntime

    เริ่มตรงนี้เมื่อต้องกำหนด node, edge, state, เงื่อนไข หรือการหยุดแล้วทำต่อเอง

    Graph · state · persistence · interrupts · streaming

ภาพจำแบบสามชั้นอธิบายความสัมพันธ์ของ stack ส่วนกล่อง “เริ่มตรงนี้เมื่อ” ช่วยเลือก API ระดับแรกที่เหมาะกับโจทย์

ระดับที่ 1: LangChain เมื่อ agent loop มาตรฐานก็เพียงพอ

ถ้าสิ่งที่อยากได้คือผู้ช่วย AI ที่ตอบคำถาม เรียก tool จำนวนไม่มาก และทำงานในลูปมาตรฐาน “โมเดลคิด → เรียก tool → เอาผลกลับไปคิดต่อ” ตัว createAgent ของ LangChain ก็เป็นจุดเริ่มต้นที่เหมาะแล้ว

หัวใจของ LangChain ในกรณีนี้มีสามอย่าง

  • Model interface เลือกผู้ให้บริการผ่าน model identifier หรือ adapter ของแต่ละเจ้าได้ โดยโค้ด agent หลักเปลี่ยนน้อยลง แต่ API key และความสามารถเฉพาะของแต่ละ provider ยังต้องตั้งค่าแยกกัน สำหรับ OpenRouter ปัจจุบันมี integration @langchain/openrouter โดยตรง
  • Tool ประกาศฟังก์ชันพร้อม schema ให้โมเดลเรียกได้ เช่น ดูเวลาปัจจุบัน คำนวณ หรือค้นเว็บ
  • Agent loop ตัว createAgent ที่วนลูป “โมเดลคิด → เรียก tool → เอาผลกลับไปคิดต่อ” ให้อัตโนมัติ โดย runtime ข้างใต้สร้างจาก LangGraph

ตัวอย่างแบบสั้นที่สุด

import { createAgent, tool } from "langchain"
import { ChatOpenAI } from "@langchain/openai"
import { z } from "zod"

const getTime = tool(async () => new Date().toISOString(), {
  name: "get_current_time",
  description: "เวลาปัจจุบันของระบบ",
  schema: z.object({}),
})

const agent = createAgent({
  model: new ChatOpenAI({ model: "gpt-4o-mini" }),
  tools: [getTime],
  systemPrompt: "คุณเป็นผู้ช่วยตอบคำถามทั่วไป ตอบสั้น กระชับ เป็นภาษาไทย",
})

const result = await agent.invoke({
  messages: [{ role: "user", content: "ตอนนี้กี่โมงแล้ว" }],
})

เท่านี้ก็ได้ผู้ช่วย AI ที่ตอบคำถามทั่วไปและเรียก tool ง่าย ๆ ได้แล้ว เหมาะกับแชตบอตช่วยเหลือเบื้องต้น ผู้ช่วยสรุปข้อความ หรือ prototype ที่อยากลองไอเดียเร็ว ๆ ถ้าต้องการให้จำบทสนทนาข้ามการเรียกแต่ละครั้ง ต้องเพิ่ม checkpointer และใช้ thread_id; ใน production ควรใช้ checkpointer ที่เก็บข้อมูลแบบถาวร ไม่ใช่หน่วยความจำใน process อย่างเดียว

ข้อจำกัด ไม่ใช่ว่า LangChain ทำ human-in-the-loop ไม่ได้ เพราะ createAgent มี middleware สำหรับหยุดรอการอนุมัติ อยู่แล้ว แต่ถ้า workflow ต้องมี node, edge, state และเงื่อนไขเฉพาะจำนวนมาก การลงไปเขียน LangGraph โดยตรงจะทำให้โครงสร้างชัดและควบคุมได้ละเอียดกว่า

ระดับที่ 2: LangGraph เมื่ออยากกำหนดลำดับงานและให้คนเข้ามาตัดสินใจระหว่างทาง

LangGraph คือ runtime ระดับล่างที่อยู่ใต้ createAgent ของ LangChain และเปิดให้เราออกแบบการทำงานของผู้ช่วย AI เป็น กราฟ ที่มี node (ขั้นตอน), edge (เส้นทางว่าจะไปขั้นไหนต่อ) และ state กลางที่แต่ละ node อ่านหรือเขียนได้

จุดที่ LangGraph โดดเด่นกว่าการปล่อยให้ agent loop วิ่งอย่างเดียวคือ

  • กำหนดลำดับได้ชัด เช่น ต้องจัดประเภทคำถามก่อน แล้วค่อยแตกไปเส้นทาง A หรือ B ก่อนรวมผลตอนท้าย
  • Human-in-the-loop ผ่าน interrupt() ซึ่งหยุดกราฟไว้ รอให้ผู้ใช้ยืนยันหรือเติมข้อมูล แล้วค่อยรันต่อ
  • Checkpointer เก็บ state ของแต่ละ thread เป็น checkpoint; ถ้าใช้ตัวเก็บข้อมูลแบบ durable ก็กลับมาทำต่อได้แม้ process รีสตาร์ต
  • Streaming หลายโหมด เช่น messages สำหรับ token, custom สำหรับสัญญาณที่เรา emit เอง และ values หรือ updates สำหรับ state

ตัวอย่างโครงกราฟที่ให้คนอนุมัติก่อนทำงานจริง

import {
  StateGraph,
  StateSchema,
  MessagesValue,
  MemorySaver,
  START,
  END,
  interrupt,
  Command,
} from "@langchain/langgraph"
import { z } from "zod"

const AgentState = new StateSchema({
  messages: MessagesValue,
  approved: z.boolean().default(false),
})

const checkpointer = new MemorySaver()

const graph = new StateGraph(AgentState)
  .addNode("draft", async (state) => {
    // สมมติว่า model ถูกสร้างไว้แล้ว
    return { messages: [await model.invoke(state.messages)] }
  })
  .addNode("approve", async () => {
    const approved = interrupt({
      question: "ยืนยันให้ดำเนินการตามร่างนี้ไหม",
    }) as boolean
    return { approved }
  })
  .addNode("execute", async () => {
    // ทำงานจริง
    return {}
  })
  .addEdge(START, "draft")
  .addEdge("draft", "approve")
  .addConditionalEdges("approve", (state) =>
    state.approved ? "execute" : "draft"
  )
  .addEdge("execute", END)
  .compile({ checkpointer })

const config = { configurable: { thread_id: "t1" } }

// รอบแรกจะหยุดที่ approve และรอคน
await graph.invoke(
  { messages: [{ role: "user", content: "ช่วยร่างแผนงานให้หน่อย" }] },
  config
)

// คนตอบแล้วรันต่อ โดยใช้ thread_id เดิม
await graph.invoke(new Command({ resume: true }), config)

ตัวอย่างนี้ใช้ MemorySaver เพื่อให้โค้ดสั้น จึงเหมาะกับการทดลองใน process เดียว ถ้าต้องการให้กลับมาทำต่อหลัง process รีสตาร์ต ต้องเปลี่ยนเป็น checkpointer ที่เขียนลงฐานข้อมูลหรือ persistent storage

LangGraph เหมาะกับงานที่ “ขั้นตอน” สำคัญพอ ๆ กับคำตอบ เช่น workflow อนุมัติเอกสาร ระบบที่ต้องถามข้อมูลเพิ่มเป็นลำดับ หรือ pipeline ที่แต่ละขั้นมีกติกาของตัวเอง

ระดับที่ 3: Deep Agents เมื่องานเฉพาะทางต้องให้ AI วางแผน แบ่งงาน และจัดการ context

พอโจทย์เป็นงานเฉพาะด้านที่ AI ต้องใช้ข้อมูลซึ่งไม่ได้อยู่ในตัวโมเดล ต้องเรียกเครื่องมือหลายตัว วางแผนหลายขั้น และบางครั้งต้องอ่านเขียนไฟล์ ตรงนี้ Deep Agents เข้ามาตอบ

Deep Agents เป็น agent harness ที่สร้างจาก building blocks ของ LangChain และใช้ LangGraph เป็น runtime โดยเติมความสามารถที่งานยาวและซับซ้อนมักต้องใช้

  • Planning ผ่าน tool write_todos สำหรับแตกงานและติดตามความคืบหน้า
  • Subagent ผ่าน tool task ให้ผู้ช่วย AI หลักมอบหมายงานย่อยไปยังผู้ช่วยเฉพาะทางที่มี prompt และ tool ของตัวเอง แล้วรับผลสรุปกลับมา ช่วยแยก context ของงานย่อยออกจากผู้ช่วย AI หลัก
  • Virtual filesystem เช่น ls, read_file, write_file, edit_file, glob และ grep สำหรับเก็บหรือค้น context ขนาดใหญ่ผ่าน backend ที่เลือกได้ ไม่ได้แปลว่าจะเข้าถึงไฟล์จริงบนเครื่องเสมอไป
  • Context management เช่นการสรุปประวัติเมื่อ context ยาว และการใช้ไฟล์เป็น working memory

ส่วน MCP (Model Context Protocol) ไม่ใช่ความสามารถที่มีเฉพาะ Deep Agents แต่เป็นมาตรฐานสำหรับเชื่อม tool และ context จากระบบภายนอก เราโหลด MCP tools ผ่าน @langchain/mcp-adapters แล้วส่งให้ทั้ง LangChain agent หรือ Deep Agent ได้

ตัวอย่างแบบย่อ

import { createDeepAgent } from "deepagents"
import { MultiServerMCPClient } from "@langchain/mcp-adapters"

const mcp = new MultiServerMCPClient({
  mcpServers: {
    catalog: {
      transport: "http",
      url: "https://example.internal/mcp",
    },
  },
  useStandardContentBlocks: true,
})

const mcpTools = await mcp.getTools()

const agent = createDeepAgent({
  model,
  tools: mcpTools,
  systemPrompt: "คุณเป็นผู้ช่วยวิเคราะห์ข้อมูลสินค้า ...",
  subagents: [
    {
      name: "product-agent",
      description: "ค้นหาและเปรียบเทียบสินค้าจากแคตตาล็อก",
      systemPrompt: "ค้นให้ครบ แล้วสรุปเป็นรายการสั้น ๆ",
      tools: mcpTools.filter((tool) => tool.name.startsWith("search_")),
    },
  ],
})

Deep Agents เหมาะกับงานอย่างผู้ช่วยวิเคราะห์ข้อมูลภายในองค์กร ผู้ช่วย AI ทำวิจัยหลายขั้น หรือผู้ช่วย AI เขียนโค้ดที่ต้องอ่านโค้ด วางแผน แล้วแก้ไฟล์

แล้วควรใช้ตัวไหน หรือใช้ร่วมกันอย่างไร

ภาพจำแบบ “สามชั้น” ช่วยให้เข้าใจหน้าที่ได้ แต่ในทางปฏิบัติสามตัวนี้เป็นจุดเริ่มต้นคนละระดับใน stack เดียวกันมากกว่าจะเป็นขั้นที่ต้องใช้ต่อกันเสมอ LangChain ให้ agent framework ที่ประกอบโมเดล, tool และ middleware ได้ LangGraph ให้ runtime และโครงสร้างการไหลของงานระดับล่าง ส่วน Deep Agents ให้ agent harness ที่รวมความสามารถสำหรับงานซับซ้อนมาให้พร้อมใช้

โจทย์ เริ่มที่
Agent loop มาตรฐาน ใช้โมเดล, tool และ middleware เท่าที่จำเป็น LangChain
ต้องออกแบบกราฟเอง มี state หลายขั้น แตกทาง หยุดและทำต่อ หรือควบคุม durable execution LangGraph
งานซับซ้อนและยาว ต้องวางแผน จัดการ context ใช้ filesystem และแบ่งงานให้ subagent Deep Agents

และเพราะใช้ building blocks ชุดเดียวกัน เราจึง “หยิบเฉพาะส่วนที่ต้องการ” ได้ เช่น ใช้ createAgent ของ LangChain แล้วเพิ่ม middleware ที่ทำงานอยู่ในกราฟ หรือหยิบเฉพาะ createSubAgentMiddleware จาก Deep Agents มาใช้โดยไม่ต้องใช้ createDeepAgent ทั้งชุด

ประสบการณ์จริง: ผมไม่ได้เลือกตัวใดตัวหนึ่ง แต่ประกอบทั้งสามเข้าด้วยกัน

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

โครงสร้างที่ใช้ในโปรเจกต์จริงแกนเล็ก คุมเข้ม แล้วค่อยแจกงานเฉพาะทางผู้ช่วยหลักเห็น tool เพียงสามตัว ส่วนสิทธิ์ งบเวลา และขอบเขตของ tool ถูกบังคับซ้ำในผู้ช่วยเฉพาะทางทุกตัว
Main agentLangChain createAgentลูปหลักของทุกเทิร์น

LangGraph controls

  • Budget
  • Deadline abort
  • Tool allowlist
  • Sequential calls
  • Output filter

Tool ที่ผู้ช่วยหลักเห็น

  • ดูเวลา
  • แนะนำคำตอบถัดไป
  • task

task แจกงานตามขอบเขต

ผู้ช่วยเฉพาะทาง

  • สินค้าค้นหาและเปรียบเทียบแคตตาล็อก
  • บัญชีลูกค้าเกิดขึ้นเฉพาะเมื่อผู้ใช้มีสิทธิ์
  • บทความค้นหาเนื้อหาและข้อมูลประกอบ
MCP boundaryTools จากระบบหลังบ้านแจกจ่ายตามสิทธิ์ของผู้ใช้ในเทิร์นนั้น

Catalog · Content · Customer account

โครงนี้ใช้ LangChain เป็นแกน ใช้ LangGraph เป็นชั้นควบคุม และหยิบเฉพาะ subagent middleware จาก Deep Agents โดยให้ MCP เป็นขอบเขตเชื่อมระบบหลังบ้าน

LangChain เป็นแกน ผมใช้ createAgent เป็นลูปหลักของทุกเทิร์น และใช้ model adapter เพื่อสลับผู้ให้บริการจาก config โดยไม่ต้องเปลี่ยนโครง agent หลัก ตอนวัดผลผมจึงสลับระหว่างโมเดลหลายเจ้าเพื่อเทียบราคาและคุณภาพได้ โดยยังคงตั้งค่าที่แตกต่างกันของแต่ละ provider แยกไว้

LangGraph เป็นชั้นควบคุม แทนที่จะปล่อยให้ลูปวิ่งอิสระ ผมเขียน middleware ของตัวเองหลายตัว แต่ละตัวทำหน้าที่เดียว

  • budget นับจำนวนครั้งที่เรียกโมเดลและเวลารวมของทั้งเทิร์นเป็นถังเดียว ครบเมื่อไรก็บังคับให้สรุปคำตอบ
  • deadline-abort ยกเลิกคำขอที่ค้างเมื่อชนเพดานเวลา เพื่อไม่ให้ผู้ใช้รอเกินที่ reverse proxy ยอม
  • tool-guard allowlist ว่าเทิร์นนี้เรียก tool อะไรได้บ้าง เรียกนอกรายการจะได้ข้อความปฏิเสธกลับไปแทน error
  • no-parallel บังคับให้เรียก tool ทีละตัว เพราะจากการทดสอบในโปรเจกต์นี้ การยิงพร้อมกันทำให้ผลค้นหาชนกันและคุณภาพคำตอบลดลง
  • model-output กรองข้อความที่โมเดลเผลอพิมพ์ออกมา เช่น JSON ภายในหรือชื่อ tool ก่อนถึงหน้าจอผู้ใช้

ที่เลือกทำเป็น middleware แทนการแก้ในลูป เพราะ LangGraph stream ได้หลายโหมดพร้อมกัน ทั้ง token จาก messages, สัญญาณที่ผมส่งผ่าน custom และ state จาก values หรือ updates ผมจึงรวม event เหล่านี้เป็นลำดับเดียวก่อนส่งขึ้นหน้าจอ และบันทึกบทสนทนาที่ผ่านการกรองแล้วลงฐานข้อมูลของเราเอง

ส่วน checkpointer และ interrupt() ของ LangGraph ผมไม่ได้ใช้ เพราะ workflow นี้ไม่ต้องหยุดกลางกราฟแล้วกลับมา resume ส่วนประวัติแชตมีฐานข้อมูลหลักดูแลอยู่แล้ว อย่างไรก็ตาม ประวัติแชตในฐานข้อมูลไม่ได้ทดแทน graph checkpoint โดยอัตโนมัติ ถ้าวันหนึ่งต้อง resume งานจากกลางกราฟก็ยังต้องเพิ่ม checkpointer

Deep Agents เอามาเฉพาะ subagent ตอนแรกผมทดลองด้วย createDeepAgent เต็มตัว แต่ในเวอร์ชันและ config ที่ใช้ตอนนั้นพบปัญหาสองอย่าง อย่างแรก ผู้ช่วย AI หลักได้ filesystem tools มาด้วย ทั้งที่บอตขายของไม่ต้องใช้ และจากที่วัดในโปรเจกต์ มันเพิ่ม prompt ราวหนึ่งพัน token ต่อการเรียกโมเดล อย่างที่สอง ระบบเพิ่ม subagent แบบ general-purpose ซึ่งมี tool กว้างกว่าขอบเขตที่ผมต้องการ

ข้อจำกัดสองข้อนี้ขึ้นกับเวอร์ชัน ปัจจุบัน Deep Agents ปรับชุด filesystem tools และ permission ได้ละเอียดขึ้น และ createSubAgentMiddleware มีตัวเลือกปิด general-purpose agent ได้ แต่สำหรับโปรเจกต์นี้ผมยังต้องการ harness ที่เล็กและกำหนดเองทั้งหมดอยู่ดี

ผมจึงหยิบเฉพาะ createSubAgentMiddleware ของ Deep Agents มาเสียบเข้ากราฟ แล้วปิดผู้ช่วยทั่วไปทิ้ง ผลคือผู้ช่วย AI หลักถือ tool แค่สามตัว คือดูเวลา แนะนำคำตอบถัดไป และ task สำหรับมอบหมายงาน ส่วนผู้ช่วยเฉพาะทางแยกเป็นด้านสินค้า ด้านบัญชีลูกค้า และด้านบทความ แต่ละตัวมี prompt ของตัวเองและได้ tool เฉพาะกลุ่มของตัวเอง ที่สำคัญคือผู้ช่วยแต่ละตัวได้ middleware งบ เวลา และ tool-guard ชุดเดียวกับผู้ช่วย AI หลัก จึงถูกบังคับด้วยกรอบเดียวกัน

MCP เป็นแหล่งของ tool เครื่องมือค้นสินค้า ค้นบทความ และดูข้อมูลบัญชีไม่ได้เขียนอยู่ในบอต แต่เปิดเป็น MCP server จากระบบหลังบ้าน บอตเชื่อมเข้าไปแล้วแจกจ่าย tool ให้ผู้ช่วยตามสิทธิ์ของผู้ใช้ในเทิร์นนั้น เช่น ผู้ใช้ที่ไม่ได้ล็อกอินจะไม่มีผู้ช่วยด้านบัญชีเกิดขึ้นเลย

ในเวอร์ชันของ @langchain/mcp-adapters ที่โปรเจกต์ใช้ตอนพัฒนา ผมต้องเขียนชั้นห่อเองเพื่อแนบตัวระบุผู้ใช้ไปกับคำขอ MCP ทุกครั้ง ปัจจุบันรุ่น 1.1.x รองรับ beforeToolCall ที่คืนค่า headers ราย tool call สำหรับ HTTP/SSE ได้แล้ว ดังนั้นนี่เป็นบทเรียนเรื่องการล็อกเวอร์ชันและตรวจ changelog มากกว่าเป็นข้อจำกัดถาวรของ adapter

บทเรียนที่ได้ มีสองข้อที่อยากฝากไว้

ข้อแรก จากผลที่วัดในโปรเจกต์นี้ การลด token ที่เห็นชัดที่สุดไม่ได้มาจากการมี subagent โดยตรง แต่มาจากการที่ผู้ช่วย AI หลักเห็น tool น้อยลง จาก 15 ตัวเหลือ 3 ตัว เทิร์นที่ไม่ต้องค้นอะไรเลยจึงถูกลง ส่วนเทิร์นที่ต้องส่งงานให้ผู้ช่วยกลับแพงขึ้นและช้าลง เพราะมีการเรียกโมเดลเพิ่มอีกหนึ่งชั้น การออกแบบจึงเป็นเรื่องของการเลือกว่าจะจ่ายตรงไหน

ข้อสอง unit test อย่างเดียวจับความผิดพลาดของ “การตัดสินใจของโมเดล” ได้ไม่ครบ ผมเคยมีเทสต์เขียวเกือบสองพันเคส แต่พอรัน eval ด้วยชุดคำถามจริงถึงพบว่าบอตเลิกเรียกเครื่องมือไปเฉย ๆ เพราะกฎใน prompt ยังอ้างชื่อ tool เก่าที่ย้ายไปอยู่กับผู้ช่วยแล้ว ถ้าทำผู้ช่วย AI จริงจัง ต้องมีชุด eval ที่รันซ้ำได้คู่กับเทสต์เสมอ

บทสรุป

LLM API ทำให้เราสร้างผู้ช่วย AI เองได้ และ LangChain, LangGraph, Deep Agents เป็นจุดเริ่มต้นคนละระดับสำหรับงานนั้น

  • ถ้า agent loop มาตรฐานที่ประกอบด้วยโมเดล, tool และ middleware ก็เพียงพอ ให้เริ่มที่ LangChain
  • ถ้าต้องกำหนดกราฟการทำงาน มี state หลายขั้น แตกเงื่อนไข หรือหยุดแล้วกลับมาทำต่อ ให้ใช้ LangGraph
  • ถ้าเป็นงานซับซ้อนและยาวที่ต้องวางแผน จัดการ context ใช้ filesystem และแบ่งงานให้ผู้ช่วย ให้เริ่มที่ Deep Agents

แต่ในโปรเจกต์จริง ผมไม่ได้เลือกตัวใดตัวหนึ่ง ผมใช้ LangChain เป็นแกน ใช้ LangGraph เป็นชั้นควบคุมงบ เวลา และความปลอดภัยผ่าน middleware ที่เขียนเอง และหยิบเฉพาะ subagent middleware จาก Deep Agents มาแบ่งงานให้ผู้ช่วยเฉพาะทาง โดยดึงเครื่องมือผ่าน MCP จากระบบหลังบ้าน ความยืดหยุ่นแบบนี้คือข้อดีที่สุดของ stack นี้ มันไม่ได้บังคับให้เราใช้ทั้งก้อน แต่เปิดให้เราประกอบผู้ช่วย AI ในแบบที่เหมาะกับงานจริง

ถ้ากำลังออกแบบผู้ช่วยที่ต้องเชื่อมข้อมูลและ workflow ขององค์กร อ่านต่อได้ที่ เชื่อม AI เข้ากับ ERP/CRM อย่างไรให้ปลอดภัย และ MCP Server คืออะไรในระบบ Backoffice

แหล่งอ้างอิงและอ่านต่อ