LLM, AI Agent และ Workflow Architecture ต่างกันอย่างไร?

คิดเป็น Layer ไม่ใช่ Product Label

ระบบองค์กรที่เชื่อถือได้มักมีอย่างน้อยหกชั้น: model สำหรับภาษาและ reasoning, retrieval และ tool สำหรับ context กับ action, agent loop สำหรับการตัดสินใจแบบ dynamic, workflow orchestration สำหรับ state และลำดับธุรกิจ, control plane สำหรับ identity policy approval และ budget, และ evidence layer สำหรับ tracing eval และ audit ผลิตภัณฑ์หนึ่งอาจทำหลายชั้น แต่ยังต้องมี owner ของแต่ละความรับผิดชอบ

แนวทางสถาปัตยกรรมระดับ production แยก workflow ที่กำหนด code path จาก agent ที่เลือกกระบวนการและเครื่องมือแบบ dynamic ส่วน แนวทาง deployment ระดับ production อธิบาย agent เป็น model tools instructions ผ่าน run loop ทั้งสองเข้ากันได้เมื่อมองเป็นชั้น

แยก Data Plane จาก Control Plane

Data plane ส่ง prompt ระเบียนที่ค้น tool argument และ output ส่วน control plane ตัดสินว่า identity ใดใช้ tool ใด action ต้องอนุมัติหรือไม่ ใช้งบเท่าไร และหยุดเมื่อใด การบังคับ policy ควรอยู่นอกโมเดล เพื่อไม่ให้อินพุตที่ชักจูงเปลี่ยน boundary

Protocol เช่น typed tool protocol ทำให้การค้นและเรียก capability เป็นมาตรฐาน แต่ไม่แทน authorization tenant isolation network policy หรือ data classification ความสะดวก integration และ enterprise trust เป็นคนละคำถาม

มอง Memory เป็นหลาย Store

Conversation history, workflow state, user preference, enterprise knowledge และ procedural skill ไม่ใช่ memory ก้อนเดียว มีแหล่ง retention access rule และ correctness ต่างกัน Workflow state ต้องแม่นยำ ความรู้ต้องสดและมี provenance preference ต้องมี consent และ deletion ส่วน summary ต้องมีวิธีกู้ข้อเท็จจริงที่หายจาก compaction

กำหนด schema กับ owner ให้แต่ละ store และตัดสินว่าอะไรข้าม user session project หรือ region ได้ Memory มากขึ้นไม่ได้ดีเสมอ เพราะเพิ่ม privacy risk ต้นทุน และสมมติฐานเก่า

ประเมินแต่ละ Layer และทั้งระบบ

Model eval ทดสอบ extraction classification หรือ reasoning Tool test ตรวจ schema permission และ failure Agent trajectory eval ตรวจ decision หลาย turn Workflow test ครอบคลุม state retry approval และ end-to-end ส่วน operational test ดู latency cost recovery และ audit evidence

ระบบอาจผ่านชั้นหนึ่งแต่ล้มโดยรวม เช่น คำตอบถูกแต่เขียนซ้ำหลัง retry สร้าง test ที่รอยต่อระหว่างชั้นและคง end-to-end case แบบ production ไว้ สถาปัตยกรรมที่ดีทำให้ระบุ จำกัด และซ่อม failure ได้โดยไม่เดา

รายการตัดสิน Architecture

• เริ่มจาก business outcome ที่วัดได้
• ลอง direct model call ก่อนเพิ่ม agent loop
• คง deterministic policy ไว้นอก model reasoning
• กำหนด identity state และ evidence ทุก tool boundary
• ให้ retention และ access rule แก่ memory ทุก store
• ทดสอบรอยต่อ recovery และ end-to-end

เลือก Layer ที่เล็กที่สุดแต่เพียงพอ