สถาปัตยกรรม Agent ที่อยู่ได้นาน: แยกชั้นตามอัตราการเปลี่ยน

ทุกทีมที่ build ระบบ AI agent เจอแรงสองทาง — ship เดี๋ยวนี้ (ตลาดเร็ว ต้องมีของใน 2-3 สัปดาห์) กับ build ให้อยู่นาน (ระบบนี้จะอยู่อีกหลายปี)

ดูเผิน ๆ เหมือนต้องเลือกข้าง · แต่ทางเลือกนี้หายไปเมื่อเห็นว่าตัวแปรจริงไม่ใช่ “เร็ว vs ทน” — มันคือ อัตราการเปลี่ยน · บางส่วนของระบบเปลี่ยนทุกเดือน บางส่วนอยู่ทั้งทศวรรษ · ระบบที่อยู่นานคือระบบที่ไม่ล่ามสองความเร็วนี้ไว้ด้วยกัน

ขอบเขต — บทนี้มองโครงระบบจากมุมมหภาค ไม่ใช่คู่มือ product · ชื่อ tool ที่ยกมาเป็นภาพ ณ กลางปี 2026 · บทที่ 4 ของ LLM systems series ต่อจาก เลือกระดับ · เลือก vendor · เลือกอย่างปลอดภัย · และส่งต่อไป เข้าใจคำถาม แล้วดึงข้อมูล

ทำไมระบบ AI ถึงตายเร็ว

ระบบซอฟต์แวร์ไม่ได้ตายเพราะโค้ดเก่า · มันตายเพราะ ส่วนที่ควรอยู่นานถูกมัดไว้กับส่วนที่เปลี่ยนเร็ว

ในระบบ agent ส่วนที่เปลี่ยนเร็วที่สุดมีชื่อชัด — model · vendor ปลดรุ่นเก่าเร็วกว่าที่คิด · รุ่น generally-available มักได้เวลา “ไม่กี่เดือน” ก่อน retire · รุ่น preview สั้นได้ถึง “2 สัปดาห์” · แถม prompt ที่ tune มาดีกับ model ตัวหนึ่ง ย้ายไปอีกตัวมักได้ผลแย่ลง — มีคนทำ production เปรียบว่าเหมือน “ตอกเยลลี่ติดต้นไม้”

ปัญหาไม่ได้อยู่ที่ model เปลี่ยน · มันอยู่ที่ อะไรถูกล่ามไว้กับมัน · ถ้า business logic เรียก SDK ของ vendor ตรง ๆ ถ้า prompt ฝังกลางโค้ด ถ้า output ผูกเข้า downstream โดยไม่มีสัญญาคั่น · พอ model เปลี่ยน ทุกอย่างที่ล่ามไว้ต้องเปลี่ยนตาม · model release หนึ่งครั้งกลายเป็น migration หลายสัปดาห์

ระบบที่ hard-code model ไม่ได้ “อาจจะ” ถูก rewrite · มันถูก rewrite แน่ · เหลือแค่คำถามว่าตอนนั้นจะถูกหรือแพง

หลักมหภาค: แยกชั้นตามอัตราการเปลี่ยน

หลักที่แก้เรื่องนี้เก่าแก่กว่ายุค AI มาก — แยกชิ้นส่วนตามความเร็วที่มันเปลี่ยน

มองอาคารสักหลัง · สายไฟถูกรื้อเปลี่ยนทุกไม่กี่ปี โครงสร้างอยู่ทั้งชีวิตอาคาร ฐานรากแทบไม่เคยแตะ · ไม่มีใครเทฐานรากหุ้มสายไฟ เพราะวันเปลี่ยนสายไฟจะกลายเป็นวันทุบตึก · เขาแยกของที่เปลี่ยนเร็วออกจากของที่อยู่นาน — รื้ออันหนึ่งได้โดยอีกอันไม่พัง

ระบบ agent มีชั้นแบบเดียวกัน เรียงตามความเร็วที่มันเปลี่ยน:

ยิ่งชั้นอยู่ลึก ยิ่งช้า และยิ่งมีค่า · งานของสถาปัตยกรรมจึงมีอยู่อย่างเดียว — กันไม่ให้ความเร็วของชั้นบนลามลงไปสั่นชั้นล่าง

เส้นแบ่งคือสัญญาที่นิ่ง

ที่รอยต่อระหว่างชั้น วางของอย่างเดียว — สัญญาที่นิ่ง · ชั้นบนเปลี่ยนได้เต็มที่ ตราบใดที่ยังพูดผ่านสัญญาเดิม ชั้นล่างไม่รู้สึกอะไร · agent stack มีรอยต่อสำคัญสี่จุด:

1. Model อยู่หลัง gateway — ทุก call ผ่านจุดเดียว · เลือก model กลายเป็นค่า config · สลับ provider, ใส่ fallback, เพิ่ม guardrail ที่เดียวจบ
2. Tools อยู่หลัง MCP + registry — เปิดผ่าน standard เดียว ขึ้นทะเบียนที่คุม version · backend เปลี่ยน = pin/rollback ได้ ไม่กระทบ agent
3. Business logic อยู่ใน orchestration graph — flow อยู่ในกราฟที่อิสระจาก model · node ไหนใช้ model ตัวไหนเป็นรายละเอียด ไม่ใช่โครง
4. Eval คลุมทุกรอยต่อ — ทุกการ swap ผ่านการตรวจ ไม่ใช่หวังว่าจะเวิร์ก · เส้นนี้ทำให้สามเส้นแรกปลอดภัยที่จะใช้จริง

ของที่อยู่นอกสัญญาเหล่านี้ — model ตัวไหน, prompt ถ้อยคำใด, embedding version อะไร — เปลี่ยนได้อิสระ เพราะมันอยู่หลังสัญญาแล้ว · รายละเอียดเปลี่ยนเร็วได้ เพราะโครงไม่ขยับตาม

และของขวัญจริงของสัญญาที่นิ่ง ไม่ใช่แค่ swap ถูก — แต่คือ สิทธิ์เลือกว่าจะขยับเมื่อไหร่ · ส่วนใหญ่ model เวอร์ชันใหม่ไม่ได้ “เปลี่ยน” มันแค่ “ดีขึ้น” — benchmark สวยกว่าเดิม น่าตาม แต่ไม่จำเป็นต้องตาม · ระบบที่ผ่าน eval แล้วบนโมเดลที่ทำงานได้ดี อยู่กับที่ก็เป็นคำตอบที่ถูก — การไล่ตามทุกเวอร์ชันที่ไม่ได้ต้องการ ก็เป็น over-engineer แบบหนึ่ง · สิ่งที่บังคับจริงมีอย่างเดียว — วันที่ vendor retire รุ่นนั้น ซึ่งนาน ๆ ที และรู้ล่วงหน้า · boundary ทำให้ทั้งสองกรณีไม่เจ็บ: เมินตัวที่ไม่ต้อง · รับตัวที่เลี่ยงไม่ได้

รอยต่อที่สำคัญที่สุด

ในสี่รอยต่อ จุดที่ model สัมผัสระบบสำคัญที่สุด เพราะ model ผันผวนที่สุด · แนวคิดที่จัดการมันมีมาก่อนยุค LLM — Anti-corruption layer (ACL) ใน Domain-Driven Design · มันคือชั้นที่แปลระหว่าง domain ที่นิ่ง (typed object, validated schema) กับ dependency ที่ผันผวน — ซึ่งในระบบ agent ก็คือตัว model เอง

จุดที่มักถูกมองข้าม — ถ้าแต่ละ service เรียก SDK ของ vendor ตรง ๆ การ enforce policy หรือสลับ provider ต้อง redeploy ทุก service · gateway ทำให้ “เลือก model” เหลือแค่แก้ config · และทำให้ downstream พึ่งสัญญาที่นิ่ง (structured output) แทน free-text จาก model

ชั้นที่อยู่นาน

สามชั้นล่างมีจังหวะของตัวเอง ต่างจาก model

Data — ชั้นที่ช้าที่สุด ค่าที่สุด · model มาแล้วไป แต่ knowledge base คือตัวระบบเอง · เลือกจาก platform ที่มีอยู่ ไม่ใช่จาก benchmark — รันอะไรอยู่แล้วใช้อันนั้นต่อ ลดการดูแลระบบที่สอง · เก็บ raw source เป็น source of truth เสมอ เพราะ embedding ผูกกับ model ที่สร้าง · เปลี่ยน embedding = re-index ใหม่หมด · ทิ้ง source เมื่อไหร่ ก็ติดอยู่กับ embedding ตัวนั้นตลอด · hybrid search (keyword + vector) ให้ทั้ง exact match และ semantic recall พร้อมกัน

Tools — standard ที่ converge เอง · MCP ต่อ tool ด้วยภาษาเดียว · registry คือ control plane ที่คุม version (publish หลายตัวพร้อมกัน, pin, rollback, sunset) และสิทธิ์ — agent ไม่เห็น tool ที่ตัวเองไม่มีสิทธิ์ด้วยซ้ำ · vendor หลักมาลงที่ tool format แบบ JSON-Schema เกือบเหมือนกัน skill จึงย้ายข้าม model ได้ในไม่กี่นาที · จุดเล็กที่สำคัญ: description ของ tool มีผลต่อความแม่นมากกว่าโครง schema

Eval — สิ่งที่ทำให้การ swap ปลอดภัย · นี่คือส่วนที่แยก demo สวย ออกจากระบบที่ใช้จริงได้นาน · ปฏิบัติต่อ prompt เป็น code — version, review, eval-gate ทุกการแก้ · เฝ้าตัวเลขที่บอกว่า model เปลี่ยนใต้เท้า: format compliance, groundedness, refusal rate, latency · การกระโดดของมันคือสัญญาณแรก · ยึด OpenTelemetry (gen_ai.*) ให้ observability รอดข้ามการเปลี่ยน framework — ตัว observability เองก็ต้องอยู่นานด้วย

ค่าใช้จ่ายที่ต้องเผื่อ — multi-agent ใช้ token มากกว่า chat ราว ๆ สิบเท่าขึ้นไป · gateway ช่วยด้วย semantic caching + routing model ถูกสำหรับ step ง่าย · prompt caching ตัด cost ของ system prompt ที่นิ่งได้ถึง ~90%

มาตรฐาน — ชั้นที่เปลี่ยนช้ากว่าทุกอย่าง

ใต้ data ยังมีชั้นที่เปลี่ยนช้ากว่า — มาตรฐาน · มันเป็นกลาง ไม่ขึ้นกับ vendor และขยับช้าที่สุดในระบบ · พอฐานไม่ขยับ ชั้นบนก็เปลี่ยนไปมาได้โดยไม่กระเทือนลงมา — เพราะมาตรฐานคือสัญญาที่นิ่งคั่นไว้ · นี่คือแผนที่คร่าว ๆ ของมาตรฐานที่ระบบ agent ยึด — พอให้เห็นภาพและจับไปต่อ

Design · การคิด — แยกส่วนตามอัตราการเปลี่ยน (pace layering / shearing layers) · separation of concerns · ports & adapters (hexagonal) · Domain-Driven Design / anti-corruption layer · least-privilege / capability · ทั้งหมดคือวิธีวาง “สัญญาที่นิ่ง” ตรงรอยต่อ

Interop · โปรโตคอล — ภาษากลางที่ให้ชิ้นส่วนคุยกันโดยไม่ต้องเขียน glue เอง · MCP (agent ↔ tool · “USB-C ของ AI”) · A2A (agent ↔ agent) · WebMCP (เปิด tool ให้ agent ผ่านหน้าเว็บ) · OpenTelemetry gen_ai.* (observability) · เขียนทับครั้งเดียว ใช้ได้ข้าม vendor และข้ามยุค

Security posture — ความปลอดภัยที่ทนเกิดจากการ จำกัดที่ขอบ ไม่ใช่เชื่อผู้กระทำ · iOS เป็นแบบอย่าง — sandbox + entitlement + capability ทำให้แอปทำได้แค่สิ่งที่ได้รับสิทธิ์ · ในระบบ agent แปลว่าบังคับที่ tool / sandbox / gateway ไม่ใช่หวังให้ model คุมตัวเอง · เสริมด้วย zero-trust กับ least-privilege/RBAC · ภัยเฉพาะ LLM (injection, PII, audit) อยู่ใน บทที่ 3

Compliance · assurance — cert ที่บุคคลที่สาม audit ให้ ไม่ใช่คำโฆษณา · เป็นใบเบิกทางที่ฝ่ายจัดซื้อ/กฎหมายเช็คก่อน regulated org จะรับเข้าใช้ได้ · SOC 2 Type 2 กับ ISO 27001 (คุมความปลอดภัยข้อมูล — baseline ของ enterprise) · ISO 42001 (มาตรฐานจัดการ AI โดยเฉพาะ — ตัวที่เกิดมาเพื่อยุคนี้) · เฉพาะวงการ — HIPAA (สุขภาพ), FedRAMP / NIST 800-171 / DoD IL (รัฐ-กลาโหมสหรัฐ), CSA STAR (cloud) · vendor ประกาศว่าผ่านอะไรใน Trust Center ของตัวเอง (เช่น Anthropic)

Governance · stewardship — MCP, A2A, OTel ถูกบริจาคให้ Linux Foundation (Agentic AI Foundation, ธ.ค. 2025) · ความเป็นกลางคือเหตุผลที่มาตรฐานอยู่นาน — ไม่มี vendor เดียวถอดปลั๊กได้ · ฝั่งในระบบก็มีวินัยกำกับ: prompt เป็น code, eval-gate ทุกการเปลี่ยน

product ในตารางถัดไปจะหมุนเปลี่ยน · มาตรฐานพวกนี้อยู่นานกว่า — เดิมพันที่มาตรฐานคือเดิมพันที่ชั้นที่ช้าที่สุด

Landscape กลางปี 2026 — ชั้นที่เปลี่ยนเร็วที่สุด

ทุกชั้นข้างบนคือ role ที่อยู่นาน · ส่วนนี้คือ product จริงที่เติมเข้าไปในแต่ละ role — และมันคือชั้นที่เปลี่ยนเร็วที่สุดในบทความเอง · อ่าน role ให้ขึ้นใจ ใช้ชื่อเป็นจุดเริ่ม

ตัวเลขทั้งหมดเป็นภาพรวม พ.ค.-มิ.ย. 2026 · ยืนยันที่หน้า vendor ก่อนตัดสินใจจริง

Orchestration / framework — โครงรันที่ business logic อยู่ · framework อิสระ = model-agnostic · vendor SDK = integration ลึกแต่ lock-in มากกว่า

Managed runtime (cloud) — operational plane สำเร็จรูป เมื่อ commit cloud เดียว · ทุกตัว framework-flexible (วาง LangGraph/CrewAI ทับได้)

Model gateway / ACL — รอยต่อที่ model สัมผัสระบบ · จุดเดียวที่ทุก call ผ่าน

Data / vector — เลือกจาก platform ที่มีอยู่ก่อน · benchmark เป็นแค่ตัวตัดสินตอนเสมอ

deepagents กับ turbovec — เป็น component ไม่ใช่สถาปัตยกรรม · deepagents เก่งเรื่อง build เร็ว แต่ยกภาระ governance/eval/RBAC มาให้เราเติมเอง (มันเป็น harness ไม่ใช่ governed platform) · turbovec เป็น library node เดียว เหมาะ embedded RAG แต่ไม่ใช่ enterprise data store แบบ distributed · ทั้งคู่เสียบเข้าชั้นที่เหมาะได้ แต่ไม่ทำให้ครบทั้งระบบเอง

Memory (long-term) — layer แยกที่ version ของตัวเอง · ตัวที่ผูกกับ framework เดียวจะไม่ถูก adopt

Eval / observability — ตรวจทุก swap · ยึด OpenTelemetry ให้รอดข้ามการเปลี่ยน framework

โครงทั้งหมดนิ่งแล้ว — framework ลงตัวที่กราฟ stateful, tool ที่ MCP, gateway เป็นชั้นมาตรฐาน, vector DB เลือกตาม platform · ที่ยังขยับคือชื่อในแต่ละช่อง · ยึด role ไว้ แล้วชื่อจะเปลี่ยนได้โดยโครงไม่สะเทือน

บทสรุป

ระบบ AI ที่อยู่นานไม่ใช่ระบบที่ไม่เคยเปลี่ยน · มันเปลี่ยนตลอด — model ใหม่ทุกไตรมาส prompt ใหม่ทุกสัปดาห์ · สิ่งที่ทำให้มันอยู่นานคือ การเปลี่ยนที่ความเร็วหนึ่ง ไม่ลามไปบังคับให้อีกความเร็วเปลี่ยนตาม

• แยกชั้นตามอัตราการเปลี่ยน — model/prompt เร็ว · logic, tool, data, eval ช้า
• วางสัญญาที่นิ่งตรงรอยต่อ — gateway, MCP+registry, orchestration graph, eval
• อ่าน role ไม่ใช่ product — ชั้นอยู่นาน ของในนั้นเปลี่ยนตลอด

เป้าหมายไม่ใช่ “เลือก stack ที่ดีที่สุด” เพราะ “ดีที่สุด” เปลี่ยนภายในไตรมาส · เป้าหมายคือทำให้การเปลี่ยน model เป็นการ swap ชั้นเดียว ไม่ใช่ rewrite ทั้งระบบ · ทำได้เมื่อไหร่ ship เร็ว กับ อยู่นาน จะไม่ใช่สองสิ่งที่ต้องเลือก — แต่เป็นสิ่งเดียวกัน

ขอบเขต — บทนี้มองโครงระบบจากมุมอัตราการเปลี่ยน · อีกสามแกนของ series ตัดสินอิสระจากกัน: เลือกระดับ (raw/workflow/agent) · เลือก vendor (cloud/open-weight/self-host) · เลือกอย่างปลอดภัย (residency/PII/injection/audit) · gateway ในบทนี้คือสิ่งที่ทำให้สลับ vendor ในบทที่ 2 ได้จริง · registry คือ control plane เดียวกับที่บทที่ 3 ต้องการ · ส่วนการดึงข้อมูลจากชั้น data ดูที่ บทที่ 5

หมายเหตุ timeless — ชื่อ product, ตัวเลข, และ cadence การ deprecate เป็นภาพรวมกลางปี 2026 และจะ outdated · สิ่งที่ตั้งใจให้อยู่นานคือ หลักการ: แยกชั้นตามอัตราการเปลี่ยน, วางสัญญาที่นิ่งตรงรอยต่อ · แหล่งแนวคิดหลัก: pace layering / shearing layers (สถาปัตยกรรม), Domain-Driven Design (anti-corruption layer), ports & adapters, capability-based security / least-privilege (iOS sandbox model), compliance assurance (SOC 2 · ISO 27001 · ISO 42001 · FedRAMP), Anthropic — Building Effective Agents, Model Context Protocol, OpenTelemetry GenAI conventions