- 19
- สิงหาคม
"Claude Agent จบได้ในตัวหรือต้องใช้คู่กับ n8n?" — คำตอบสั้นที่สุดคือ จบในตัวได้จริงสำหรับงานที่ขั้นตอนเดาไม่ได้ล่วงหน้า แต่ยังต้องมีตัวคุมคิวเมื่อขั้นตอนตายตัวและปริมาณเยอะ ปี 2569 ชุดเครื่องมือของ Claude ครบขึ้นมาก — มีทั้ง Agent SDK, MCP, Skills, Managed Agents และ Routines ที่สั่งงานตามเวลาได้ — จนหลายงานไม่ต้องพึ่ง workflow tool อีกแล้ว บทความนี้แยกให้ชัดว่าชิ้นไหนทำอะไร งานแบบไหนจบในตัว และเส้นแบ่งที่ n8n ยังจำเป็นอยู่ตรงไหน
สรุปบรรทัดเดียว: Claude Agent จบในตัวได้เมื่อขั้นตอนของงานเดาล่วงหน้าไม่ได้ ส่วน n8n ยังจำเป็นเมื่อขั้นตอนตายตัว ปริมาณสูง หรือต้องต่อกับหลายระบบและตรวจสอบย้อนหลังได้
ก่อนอื่น: "Claude Agent" ไม่ได้มีชิ้นเดียว
ความสับสนส่วนใหญ่เกิดจากการเอาคำว่า Agent มาเทียบกับ n8n ตรง ๆ ทั้งที่ฝั่ง Claude ไม่ได้เป็นผลิตภัณฑ์เดียว แต่เป็นชุดชิ้นส่วนที่เอามาประกอบกัน ถ้าแยกชิ้นออกมาก่อน คำถามว่า "จบในตัวไหม" จะตอบง่ายขึ้นมาก
| ชิ้นส่วน | หน้าที่ | เทียบกับโลก workflow |
|---|---|---|
| Agent SDK | ตัว loop ของ agent — วนคิด เรียกเครื่องมือ อ่านผล แล้วตัดสินใจขั้นต่อไป เขียนได้ทั้ง Python และ TypeScript | เครื่องยนต์ที่รันงาน |
| MCP | ช่องต่อไปยังเครื่องมือและแหล่งข้อมูลภายนอก — ฐานข้อมูล เบราว์เซอร์ API | คล้าย connector/node |
| Agent Skills | ความรู้เชิงขั้นตอน — วิธีทำงานเฉพาะเรื่อง เทมเพลต กติกาขององค์กร โหลดเข้ามาเฉพาะตอนที่ต้องใช้ | ไม่มีของเทียบตรง ๆ |
| Managed Agents | โครงสร้างพื้นฐานแบบโฮสต์ให้ — sandbox รันโค้ด, checkpoint, จัดการ credential, สิทธิ์แบบจำกัดขอบเขต, ติดตามการทำงานตั้งแต่ต้นจนจบ | คล้ายชั้น runtime + secrets |
| Routines | งานที่บันทึกไว้แล้วสั่งให้วิ่งตามเวลา ตามการเรียก API หรือตาม event เช่น GitHub webhook | คล้าย cron + trigger |
| Cowork | โหมดทำงานกับไฟล์ โฟลเดอร์ และแอปบนเครื่องผู้ใช้ จนได้ผลงานที่ส่งต่อได้ | ไม่มีของเทียบ |
สรุปสั้น ๆ ตามที่เอกสารสาย developer มักอธิบายไว้: SDK คือ loop, MCP กับ tools คือ "ทำอะไรได้", Skills คือ "รู้วิธีทำงานนั้นยังไง" ส่วน Managed Agents กับ Routines คือชั้นที่ทำให้มันวิ่งเองได้โดยไม่ต้องมีคนเปิดเครื่องรอ
โครงสร้าง Skill ที่ทำให้ agent "รู้วิธีทำงานขององค์กรเรา"
จุดที่หลายคนมองข้ามคือ Skills ซึ่งเป็นแค่โฟลเดอร์ที่มีไฟล์ SKILL.md อยู่ข้างใน — ระบบจะโหลดเข้ามาเฉพาะตอนที่เกี่ยวข้อง จึงแทบไม่กินคอนเท็กซ์เวลาไม่ได้ใช้ นี่คือช่องทางที่ทำให้ agent ทำงานตามระเบียบขององค์กรได้จริง ไม่ใช่ทำตามค่ากลางที่โมเดลเดาเอง
skills/
└── ตรวจใบขอซื้อ/
├── SKILL.md # ขั้นตอน + กติกา: วงเงินไหนต้องใครอนุมัติ
├── references/
│ └── ระเบียบพัสดุ-ฉบับย่อ.md
└── scripts/
└── check_budget.py # สคริปต์ที่ agent เรียกใช้ได้
ประเด็นสำคัญ: ความรู้เชิงขั้นตอนขององค์กร (ใครอนุมัติวงเงินเท่าไหร่ เอกสารต้องแนบอะไร) เป็นสิ่งที่ agent ไม่มีทางเดาถูกเอง ไม่ว่าโมเดลจะเก่งแค่ไหน — ต้องเขียนให้มันอ่าน
งานแบบไหนที่ Claude Agent จบในตัวได้จริง
เกณฑ์ที่ใช้ได้จริงมีข้อเดียว: ถ้าเขียนขั้นตอนตายตัวล่วงหน้าไม่ได้ ให้ใช้ agent ถ้าเขียนได้ สคริปต์ธรรมดาหรือ workflow จะเร็วกว่าและถูกกว่าเสมอ ตัวอย่างงานที่เข้าเกณฑ์แรก:
- ไล่หาสาเหตุบั๊กในโค้ดเบสเดิม — ไม่มีใครรู้ล่วงหน้าว่าต้องเปิดไฟล์ไหนบ้าง จำนวนขั้นขึ้นกับสิ่งที่เจอระหว่างทาง
- อ่านเอกสารยาวแล้วสรุปประเด็นที่ขัดกัน เช่นเทียบ TOR กับสัญญาฉบับจริง
- งานประจำที่มีเงื่อนไขเยอะ เช่น ตรวจชุดเอกสารขออนุมัติแล้วบอกว่าขาดอะไร ซึ่งแต่ละใบขาดไม่เหมือนกัน
- งานที่ต้องวิ่งเองตอนกลางคืน — Routines ทำให้ตั้งเวลาให้ agent ทำงานบนคลาวด์ได้โดยไม่ต้องเปิดเครื่องทิ้งไว้ เช่น รันทดสอบ ตรวจโค้ดที่เปลี่ยน หรืออัปเดต dependency
งานสี่กลุ่มนี้ ถ้าเครื่องมือที่ต้องใช้ต่อผ่าน MCP ได้ครบ Claude ทำจบได้เองจริง ไม่ต้องมี workflow tool มาคั่นกลาง
แล้วตรงไหนที่ยังไม่จบในตัว
ข้อจำกัดที่เจอในงานจริงไม่ค่อยเกี่ยวกับความฉลาดของโมเดล แต่เกี่ยวกับลักษณะของระบบรอบ ๆ มากกว่า
| สถานการณ์ | ทำไม agent เดี่ยวไม่พอ |
|---|---|
| ขั้นตอนตายตัว ทำซ้ำวันละหลายพันครั้ง | ให้โมเดลคิดใหม่ทุกรอบคือการจ่ายค่าคิดซ้ำโดยไม่จำเป็น ทั้งช้ากว่าและแพงกว่าเส้นทางที่เขียนไว้ตายตัว |
| ต้องรับ event จากหลายระบบที่ไม่มี MCP server | ต้องมีตัวกลางคอยรับ webhook, แปลงรูปแบบข้อมูล และจัดคิว |
| ต้องมีขั้นให้คนอนุมัติกลางทาง | งานที่หยุดรอคนหลายชั่วโมงหรือหลายวัน ต้องการตัวเก็บสถานะที่ออกแบบมาเพื่อการนี้โดยเฉพาะ |
| ต้องพิสูจน์ย้อนหลังได้ว่าใครสั่งอะไรเมื่อไหร่ | ผู้ตรวจสอบมักอยากเห็นเส้นทางที่เป็นแผนภาพชัดเจน มากกว่าบันทึกการคิดของโมเดล |
| งานล้มแล้วต้องลองใหม่แบบมีกติกา | การจัดการ retry, timeout และ dead-letter เป็นเรื่องที่ workflow engine ทำมาแล้วและทำได้ดีกว่า |
คำเตือนด้านความปลอดภัย: ยิ่ง agent ต่อกับระบบที่ "เขียนข้อมูลได้" มากเท่าไหร่ ความเสี่ยงจาก prompt injection ยิ่งสูงขึ้นเท่านั้น เพราะข้อความที่ agent อ่านจากอีเมล เว็บ หรือไฟล์แนบ อาจมีคำสั่งแฝงอยู่ กติกาที่ควรถือให้มั่น: อ่านได้กว้าง เขียนได้แคบ — งานที่แก้ข้อมูลจริงในระบบการเงินหรือพัสดุ ต้องผ่านการอนุมัติของคนเสมอ ไม่ว่าจะมั่นใจในโมเดลแค่ไหน
สองรูปแบบที่ใช้คู่กันได้จริง
ในทางปฏิบัติ ทีมที่ทำจริงมักไม่เลือกข้าง แต่เลือกว่าใครเป็นคนคุมจังหวะ ซึ่งมีสองแบบ:
แบบ A — workflow เป็นเจ้าของจังหวะ (ใช้บ่อยที่สุด)
trigger → กรอง/เตรียมข้อมูล → [ เรียก Claude ทำขั้นที่ต้องใช้วิจารณญาณ ]
→ ตรวจผลลัพธ์ → รอคนอนุมัติ → เขียนกลับเข้าระบบ → เก็บ log
แบบ B — agent เป็นเจ้าของจังหวะ
เป้าหมาย → Claude วางแผนเอง → เรียกเครื่องมือผ่าน MCP
→ [ เรียก webhook ของ workflow เมื่อต้องต่อระบบเก่า ] → สรุปผล
แบบ A เหมาะกับกระบวนการธุรกิจที่มีขั้นตอนชัดและมีจุดที่ต้องตัดสินใจไม่กี่จุด ส่วนแบบ B เหมาะกับงานสำรวจ งานวิเคราะห์ และงานพัฒนา ที่ขั้นตอนงอกระหว่างทาง ทั้งสองแบบใช้ Claude เหมือนกัน ต่างกันแค่ว่าใครถือแผน
ตารางตัดสินใจแบบใช้ได้จริง
| โจทย์ | ควรใช้ |
|---|---|
| ขั้นตอนเดาไม่ได้ ต้องอ่านของแล้วค่อยตัดสินใจ | Claude Agent เดี่ยว — SDK + MCP + Skills |
| ขั้นตอนตายตัว ปริมาณสูง ต้นทุนต่อรายการสำคัญ | workflow ล้วน ไม่ต้องมีโมเดลในเส้นทางหลัก |
| ขั้นตอนตายตัว แต่มี 1-2 จุดที่ต้องใช้วิจารณญาณ | ทั้งคู่ แบบ A — workflow คุม แล้วเรียก Claude เฉพาะจุดนั้น |
| งานตั้งเวลา เช่น ตรวจโค้ดทุกคืน สรุปรายงานทุกเช้า | Routines — ไม่ต้องมี workflow tool ถ้าไม่ต้องต่อหลายระบบ |
| ต้องรับ event จากระบบเก่าที่มีแต่ REST/DB | ทั้งคู่ แบบ B — agent ถือแผน แล้วยิง webhook ไปหา workflow |
| งานที่ต้องอธิบายให้ผู้ตรวจสอบเข้าใจได้ทีละขั้น | workflow เป็นหลัก เพราะเส้นทางเห็นเป็นภาพและไม่เปลี่ยนตามรอบ |
ในบริบทของระบบ ERP
งาน ERP เป็นตัวอย่างที่เห็นเส้นแบ่งชัดที่สุด เพราะในกระบวนการเดียวมีทั้งสองประเภทปนกัน ยกตัวอย่างการขออนุมัติจัดซื้อ: การตรวจว่าเอกสารครบไหมและงบหมวดนี้พอไหม เป็นตรรกะตายตัวที่ระบบตรวจได้เองอยู่แล้ว ไม่ควรเอาโมเดลไปคิดซ้ำ แต่ขั้นที่ต้องอ่านคำขอที่พิมพ์มาแบบยาว ๆ แล้วสรุปว่าตรงกับหมวดงบไหน หรือชี้ว่าคำอธิบายขัดกับใบเสนอราคาที่แนบมา — ตรงนั้นคือจุดที่ agent มีค่า
สำหรับ Saeree ERP เราพูดตรง ๆ ว่า AI Assistant ของเรายังอยู่ในช่วง Training ยังไม่ได้เปิดเป็นฟีเจอร์ให้ลูกค้าใช้งาน สิ่งที่ระบบทำได้แล้วคือส่วนที่เป็นเงื่อนไขจำเป็นก่อนหน้านั้น — การตรวจวงเงินคงเหลือก่อนอนุมัติ การแยกสถานะจอง ผูกพัน และค้างจ่ายออกจากกัน สิทธิ์การเข้าถึงตามบทบาท และร่องรอยการอนุมัติที่ตรวจย้อนได้ ซึ่งเป็นสิ่งที่ต้องมีก่อนจะให้ agent เข้ามาแตะได้อย่างปลอดภัย อ่านภาพรวมเรื่องนี้ต่อได้ที่ Agentic AI คืออะไร และ AI Agent ในงานบัญชี
สรุป
คำตอบของคำถามหัวเรื่องคือ จบในตัวได้ — แต่ไม่ใช่กับทุกงาน ชุดเครื่องมือของ Claude ปี 2569 ครบพอที่จะทำงานเปิดปลายให้จบเองได้จริง โดยเฉพาะเมื่อเครื่องมือที่ต้องใช้ต่อผ่าน MCP ได้ และมี Routines ช่วยให้วิ่งเองตามเวลา สิ่งที่ยังไม่ใช่จุดแข็งคือการเป็นตัวคุมคิวของงานตายตัวปริมาณมาก การรับ event จากระบบเก่าหลายตัว และการทิ้งร่องรอยแบบที่ผู้ตรวจสอบอยากเห็น
ในทางปฏิบัติ คำถามที่ถูกกว่าจึงไม่ใช่ "เลือกอะไร" แต่เป็น "ใครควรถือแผนของงานนี้" ถ้าแผนเขียนล่วงหน้าได้ ให้ workflow ถือ แล้วเรียก agent เฉพาะจุดที่ต้องใช้วิจารณญาณ ถ้าแผนต้องงอกระหว่างทาง ให้ agent ถือ แล้วใช้ workflow เป็นสะพานไปหาระบบที่ต่อตรงไม่ได้ — เราเจาะมุมกลับด้านของคำถามนี้ไว้ในบทความ n8n ถึงกาลอวสานแล้วหรือยัง
อย่าถามว่า agent แทน workflow ได้ไหม ให้ถามว่างานนี้ "เขียนขั้นตอนล่วงหน้าได้หรือเปล่า" — ถ้าได้ อย่าจ่ายค่าให้โมเดลคิดใหม่ทุกรอบ
- ทีมงาน Saeree ERP
แหล่งอ้างอิง
- Anthropic Newsroom
- Help Net Security — Claude Managed Agents bring execution and control to AI agent workflows
- InfoQ — Anthropic introduces Routines for Claude Code automation
- AI Agents Hub — Claude Agent SDK: capabilities, comparison and ecosystem guide
- IronPlate — Claude Code Routines vs n8n: deterministic vs agentic automation
- Zarif Automates — Claude Managed Agents vs n8n: the real difference
สนใจระบบ ERP สำหรับองค์กรของคุณ?
อยากวาง AI Agent บนระบบงานจริงโดยไม่เสี่ยง — ปรึกษาทีม Saeree ERP เรื่องการวางสิทธิ์ ขั้นอนุมัติ และร่องรอยการตรวจสอบ ให้พร้อมก่อนต่อ agent เข้ากับระบบงบประมาณ จัดซื้อ และพัสดุ
ขอคำปรึกษาฟรีโทร 02-347-7730 | sale@grandlinux.com




