Bounded Context → agent หนึ่งตัว (memory + guardrails)

บทก่อนๆ ปั้น ข้างใน ของ agent ที่มีขอบเขต — บทที่ 2 ใช้ subdomain เลือกว่ากล่องไหนควรเป็น agent จริง บทที่ 3 แปลง ubiquitous language ให้กลายเป็น system prompt ที่ระดับความสูงพอดีกับชุด tool ที่ตั้งชื่อชัด ทั้งสองบทตั้งอยู่บนสมมติฐานเงียบๆ ข้อหนึ่ง: ว่าพอประกาศขอบเขตแล้ว agent จะอยู่ในขอบเขตนั้นเอง บทนี้แตะสมมติฐานข้อนั้นตรงๆ เพราะมันไม่จริงโดยอัตโนมัติ

ต่างจาก Bounded Context ใน code ที่มี compiler กับ type system คอยบังคับขอบให้ ขอบเขตของ agent ไม่มีใครบังคับให้ฟรีๆ Agentic Loop ทำให้ context โตทุกรอบ และคำที่เราประกาศไว้ใน system prompt ก็เป็นแค่ ข้อความ ในบริบทที่ยาวขึ้นต่อเนื่อง ไม่ใช่ constraint ที่ runtime บังคับ วิทยานิพนธ์ของบทนี้จึงคมกว่าบทก่อน: bounded context ของ agent คือ ความตั้งใจในการออกแบบ ไม่ใช่การรับประกันเชิงกลไก — และเราบังคับความตั้งใจนั้นได้แค่แบบ best-effort ด้วยสามอย่างที่ทำงานร่วมกัน คือ agent memory ภายนอก, กองของ guardrail และ eval

📦 code ตัวอย่าง

คอร์สนี้เป็น คอร์สออกแบบ ไม่ใช่ทัวร์ SDK — code ในบทคือ ภาพร่าง ของ memory topology, guardrail config และ Mermaid ขอบเขต ไม่ใช่ app ที่รันได้จริง (LangGraph, OpenAI Agents SDK, Claude ยกมาเป็นตัวอย่างประกอบเท่านั้น) ตัวอย่างต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) โดยเดินเรื่องด้วย agent Customer-Support จาก3 agent ตั้งต้นในบทที่ 1

working context ไม่ใช่ของนิ่ง มันโตทุกรอบ

ย้อนกลับไปที่ agent Customer-Support ของ ops-copilot มันพูดภาษาแคบ (เคส/นโยบาย/ประวัติสนทนา) แต่บริบทของงานยาว — ประวัติแชตทั้งเส้น บวกคู่มือนโยบาย บวกผลของทุก tool ที่มันเรียกระหว่างทาง ทุกรอบของ agentic loop เอาผล tool กลับเข้า context บริบทจึงพองขึ้นต่อเนื่อง และนี่คือจุดที่ Context Rot เริ่มทำงาน: งบ attention ที่จำกัดถูกเกลี่ยบางลง จนกฎเดียวที่สำคัญ ณ ตานี้ (“ห้ามคืนเงินเกินยอดที่จ่ายจริง”) อาจถูกกลบใต้ข้อความที่ไม่เกี่ยวแล้วสิบรอบก่อน

สังเกตว่าปัญหาไม่ใช่ “context ยาว” เฉยๆ แต่คือ เราไม่ได้เลือกว่าอะไรอยู่ อะไรไป — ปล่อยให้ทุกอย่างสะสมไปตามธรรมชาติของ loop การควบคุม working context จึงเป็นงานออกแบบ ไม่ใช่ผลพลอยได้ Effective context engineering for AI agents (Anthropic, Sep 2025) ให้มองมันเป็นการ curate: เลือกใส่ token ที่ให้ผลสูงสุดในแต่ละก้าว ไม่ใช่เติมถังจนล้น (มีฉบับแปลไทยในเว็บนี้ที่บทความ Context Engineering ที่ได้ผลสำหรับ AI Agents)

สามกลไกคุม working context

มีสามกลไกหลักที่ใช้กันขอบเขตไม่ให้พังเพราะ context บวม และในทางปฏิบัติมักใช้พร้อมกัน:

Compaction — เมื่อ context ใกล้เต็ม ให้สรุปบีบอัดช่วงที่ผ่านมาแทนที่จะแบกดิบทั้งหมดต่อ เก็บข้อทิ้งรายละเอียดที่ไม่ต้องใช้แล้ว นี่คือกลไกที่ทรงพลังที่สุด — และอันตรายที่สุด เพราะมันคือจุดที่ข้อมูลถูก ตัดทิ้ง (เดี๋ยวเราจะกลับมาที่จุดนี้)
Agent Memory ภายนอก — เขียนสิ่งที่ต้องไม่ลืมออกไป นอก context: file โน้ต, progress file ของเคสที่ยังค้าง, หรือ commit ลง git แล้วอ่านกลับเข้ามาเฉพาะเมื่อจำเป็น context window กลายเป็นพื้นที่ทำงานชั่วคราว ไม่ใช่ที่เก็บถาวร
Sub-agent isolation — โยนงานย่อยที่ context หนัก (เช่น ไล่อ่านล็อกยาวๆ เพื่อหาสาเหตุ) ไปให้ sub-agent ทำในหน้าต่างของมันเอง แล้วรับกลับมาแค่ ข้อสรุป ไม่ใช่ทุก token ที่มันเห็นระหว่างทาง context หลักจึงไม่ต้องแบกงานสกปรกนั้น

sub-agent isolation ≠ ใบอนุญาตให้แตก multi-agent

กลไกที่ 3 ทำเพื่อ รักษา context ของ agent หลัก ไม่ใช่เพื่อแตกเป็น Multi-agent ตาม subdomain เหตุผลในการมี sub-agent ตรงนี้คือ “context-protection” ล้วนๆ — ไม่ใช่ specialization และไม่ใช่ parallelization ประตูต้นทุนของ multi-agent (ราว 15 เท่าของแชตเดี่ยว) กับการตัดสินใจว่าจะแตกจริงไหม เป็นเรื่องของบทที่ 5 บทนี้ยังคุยเรื่อง agent ตัวเดียว อยู่

memory สองชั้น: ระยะสั้นใน thread กับระยะยาวภายนอก

กลไกทั้งสามข้างบนตกผลึกเป็นหลักออกแบบข้อเดียว: agent memory ควรมีสองชั้นที่แยกหน้าที่กันชัด อย่ายัดทุกอย่างไว้ชั้นเดียว

	short-term (thread-scoped)	long-term (external)
อยู่ที่ไหน	ใน context window ของ thread/session นี้	นอก context — file โน้ต, progress file, git
อายุ	ชั่วคราว หายเมื่อจบ thread หรือถูก compaction	คงอยู่ข้าม session
ใครแตะ	agentic loop เขียน/อ่านเองอัตโนมัติ	agent เลือก เขียนออก สิ่งสำคัญ แล้ว อ่านกลับ เมื่อต้องใช้
ตัวอย่างในเคส Support	ประวัติแชตล่าสุดของตั๋วนี้	นโยบายคืนเงิน, สรุปเคสก่อนหน้าของลูกค้าคนนี้, runbook ที่ track ใน git
ความเสี่ยงถ้าปล่อย	โตจน context rot ถ้าไม่บีบ	ข้อมูลเก่า/ผิดถ้าไม่ดูแล

ชั้นสั้นคือหน่วยความจำใช้งาน — เร็ว แต่หายและถูกบีบได้ ชั้นยาวคือหน่วยความจำที่เรา ตั้งใจ ให้อยู่รอด: มันคือที่ที่ข้อเท็จจริงห้ามลืมถูกปักหมุดไว้ เพื่อว่าถ้า compaction ตัดมันออกจากชั้นสั้น เรายังอ่านกลับมาได้ Effective harnesses for long-running agents (Anthropic) เรียกกลุ่มนี้ว่าสถานะภายนอกของ harness — progress file, artifact และ git history ที่ทำให้ agent ทำงานยาวๆ ต่อเนื่องข้ามรอบได้โดยไม่พึ่ง context window เป็นความจำถาวร (มีฉบับแปลไทยที่บทความ Harness Engineering)

agent: customer-support
memory:
  strategy: replay_everything      # ยัดประวัติแชตทั้งเส้น + ทุกผล tool กลับทุกรอบ
guardrail:
  - check: final_output_only       # ตรวจแค่ข้อความสุดท้ายก่อนส่งออก
# ผล 1: context โตทุกรอบจน context rot — กฎ "ห้ามคืนเงินเกินยอดจริง" ถูกกลบ
# ผล 2: ด่านเดียวไม่เห็น issue_refund ที่ tool-call ล้ำเส้นไปแล้วกลางทาง

agent: customer-support
memory:
  short_term:                      # thread-scoped — อยู่ใน context window
    window: recent_turns
    compaction: summarize_near_limit    # บีบอัดเมื่อใกล้เต็ม
  long_term:                       # external — อยู่นอก context
    notes: policy_and_case_notes.md     # โน้ตนโยบาย/สรุปเคส
    progress: ticket_progress.md        # progress file ของเคสที่ค้าง
    provenance: git                     # ประวัติแก้ไข ย้อนดูได้
guardrails:                        # กอง ไม่ใช่ช่องเดียว
  input:  [redact_pii, reject_out_of_scope]
  tool:   allowlist[search_ticket, draft_reply]   # ไม่มี issue_refund ในมือ
  output: policy_compliance_check
  human_in_the_loop: [refund, account_change]     # งานย้อนไม่ได้ → คนอนุมัติ
  stop_when: [resolved, max_turns, budget_exceeded]
  sandbox: read_only_replica       # tool วิ่งบน replica อ่านอย่างเดียว

guardrail เป็นกอง ไม่ใช่ช่องเดียว

สังเกตในภาพร่าง ✅ ว่า guardrails เป็น รายการ ไม่ใช่ค่าเดียว นี่ไม่ใช่ความละเอียดเกินเหตุ แต่เป็นหัวใจ Guardrail ที่ดีคือ กองของด่านที่ต่างชนิดกัน เพราะความพังของ agent มีหลาย class และไม่มีด่านเดียวที่ดักได้ทุก class:

Input guardrail — กรอง/ตรวจสิ่งที่เข้ามาก่อนถึง model: ลบ PII, ปฏิเสธคำขอที่อยู่นอกขอบเขต (คนถามเรื่องปรับราคาเมนู แต่นี่คือ agent ฝั่งลูกค้า) กันไม่ให้ prompt injection หรืองานนอกขอบไหลเข้า loop ตั้งแต่ต้น
Tool guardrail — ด่านที่แข็งแรงที่สุด เพราะบังคับที่ ความสามารถ ไม่ใช่ที่คำพูด: allowlist ของ tool ที่ agent นี้ถือได้ บวกการตรวจ argument ก่อนยิงจริง Customer-Support ไม่มี issue_refund ในมือเลย — ต่อให้ model อยากคืนเงิน มันก็ทำไม่ได้ นี่คือการ รักษาขอบด้วยการไม่ให้เครื่องมือ แทนที่จะหวังให้ model จำว่าห้ามทำ
Output guardrail — ตรวจสิ่งที่จะออกก่อนส่งถึงลูกค้าจริง: ตรงตามนโยบายไหม เผลอหลุดข้อมูลภายในหรือสัญญาเกินอำนาจไหม
Human-in-the-loop — สำหรับการกระทำที่แพงหรือย้อนกลับไม่ได้ (คืนเงิน, แก้บัญชี) ต้องมีคนอนุมัติคั่นเสมอ ไม่ปล่อยให้ agent กดเอง
เงื่อนไขหยุด (stopping condition) — agentic loop ที่ไม่มีเบรกจะวนไม่จบและเผา token: หยุดเมื่อแก้เคสจบ, เกินจำนวนรอบสูงสุด, หรือเกินงบ นี่คือ guardrail ต่อ ตัว loop เอง
Sandbox — จำกัด blast radius ของสิ่งที่ tool ทำได้จริง: ให้วิ่งบน read-only replica หรือใช้ credential ที่ scope แคบ เพื่อว่าถ้าด่านอื่นหลุดหมด ความเสียหายก็ยังถูกจำกัดด้วยสภาพแวดล้อม

Building Effective Agents (Anthropic) พูดถึงเงื่อนไขหยุด, sandbox และการให้คนกำกับงานที่แพง/ย้อนไม่ได้ ส่วน OpenAI Agents SDK — Guardrails วางกองด่าน input/output/tool ไว้เป็นชั้นๆ ชัดเจน เหตุผลที่ต้องเป็น กอง ไม่ใช่ช่องเดียวมาจากธรรมชาติของการบังคับใช้ในโลก agent — ซึ่งพาเรามาที่ประเด็นที่ต้องพูดตรงๆ

พูดตรงๆ: agent ไม่ใช่ aggregate

ตลอดคอร์สเรายืมคำจาก DDD มาใช้กับ agent ได้ลื่นไหล แต่ตรงนี้มีรอยต่อที่ถ้าไม่พูดให้ชัดจะหลอกตัวเอง คนที่มาจากสาย DDD จะเผลอคิดว่า bounded context ของ agent บังคับใช้ได้เหมือน aggregate — และมันไม่จริง

aggregate รักษา invariant แบบ atomic ทุกการเปลี่ยนสถานะผ่าน root ตัวเดียว และที่ทุก transaction commit กฎธุรกิจ (invariant) เป็นจริงเสมอ ถ้าการเปลี่ยนแปลงจะทำให้กฎพัง transaction จะถูกปฏิเสธ — throw ออกมาเสียงดัง ไม่มีอะไรถูกตัดทิ้งเงียบๆ นี่คือ consistency boundary ที่บังคับใช้จริงโดยกลไก

context ของ agent หลัง compaction ไม่รับประกันแบบนั้นเลย สิ่งที่ใกล้เคียง “commit หน่วยความจำ” ที่สุดคือการสรุปบีบอัด และการสรุปนั้น lossy โดยธรรมชาติ — ตัวที่ตัดสินว่าอะไรเก็บอะไรทิ้งมักเป็น model อีกที มันตัดข้อเท็จจริงที่ boundary ควรรักษา (“ลูกค้าคนนี้เคยถูกปฏิเสธเคลมมาแล้ว”, “เพดานคืนเงินคือยอดที่จ่ายจริง”) ทิ้งได้ โดยไม่ throw อะไรทั้งนั้น ไม่มี transaction ถูก reject มีแต่ agent ที่เงียบๆ ไม่รู้กฎนั้นอีกต่อไป การบังคับใช้ขอบเขตจึงเป็น best-effort ไม่ใช่ atomic

นี่คือเหตุผลตรงๆ ว่าทำไมต้องมีทั้งสามอย่าง ไม่ใช่แค่ “เขียน system prompt ให้ดี”:

external memory ปักข้อเท็จจริงห้ามลืมไว้นอก context เพื่อว่า compaction ตัดจากชั้นสั้นไปก็ยังอ่านกลับได้ — ชดเชยความ lossy ของการสรุป
guardrails ย้ายการบังคับกฎแข็งๆ ไปไว้ที่ ขอบ (tool allowlist, human-in-the-loop, output check) แทนที่จะเชื่อว่า model จะ “จำได้” — เพราะการจำเป็น best-effort แต่การไม่ให้เครื่องมือเป็นของแน่นอน
Eval วัดว่าขอบยังอยู่จริงไหม โดยดู ปลายทาง (ผลลัพธ์ถูกตามนโยบายไหม) ไม่ใช่ เส้นทาง — เพราะเมื่อไม่มี compiler คอยบอกว่าขอบแตก การวัดผลเชิงประจักษ์คือสิ่งเดียวที่บอกเราได้

และนี่คือคำตอบว่าทำไม guardrail ต้องเป็น กอง: เมื่อการบังคับใช้เป็น best-effort/ความน่าจะเป็น ไม่ใช่ atomic ไม่มีด่านเดียวที่รับประกันได้ทั้งหมด แต่ละชั้นดักความพังคนละ class (input ปนเปื้อน, tool ล้ำเส้น, output หลุดนโยบาย, งานย้อนไม่ได้, loop วนไม่จบ, blast radius) การซ้อนหลายชั้นคือการทดแทนการรับประกันเชิงกลไกที่ agent ไม่มี ด้วย defense in depth — ด่านสุดท้ายที่ตรวจ “คำตอบสุดท้าย” อย่างเดียว มองไม่เห็น issue_refund ที่ยิงไปแล้วกลางทาง

DDD ยังให้คำศัพท์ของการยับยั้งชั่งใจที่มีค่าที่สุดในการออกแบบ agent — แต่ให้ถือ bounded context ไว้เป็น เจตนา ที่เราลงแรงบังคับ ไม่ใช่กำแพงที่ runtime ตั้งให้ฟรีๆ

ภาพรวม: agent ตัวเดียวที่มีขอบเขต (best-effort)

flowchart TB
  subgraph AGENT["agent เดียว = bounded context (ตั้งใจ, best-effort)"]
    SP["System Prompt<br/>ประกาศขอบเขต + ปฏิเสธงานนอกขอบ"]
    subgraph LOOP["agentic loop — working context (thread-scoped)"]
      CTX["context สั้น<br/>โตทุกรอบ → compaction เมื่อใกล้เต็ม"]
      TOOLS["Tools (allowlist)<br/>search_ticket, draft_reply<br/>ไม่มี issue_refund ในมือ"]
      CTX --> TOOLS --> CTX
    end
    subgraph GUARD["guardrails — กอง ไม่ใช่ช่องเดียว"]
      GIN["input: redact PII, reject นอกขอบ"]
      GTOOL["tool: allowlist + ตรวจ args"]
      GOUT["output: ตรวจนโยบายก่อนส่ง"]
      GHIT["human-in-the-loop: refund/ย้อนไม่ได้"]
      GSTOP["stop: resolved / max turns / งบหมด"]
      GSBX["sandbox: read-only replica"]
    end
  end
  MEM["external agent memory (long-term)<br/>notes + progress file + git<br/>อยู่นอก context window"]
  EVAL["eval<br/>วัดว่าขอบยังอยู่จริง<br/>(ดูปลายทาง ไม่ใช่เส้นทาง)"]

  SP --> LOOP
  LOOP <-->|"เขียนของสำคัญออก / อ่านกลับเมื่อต้องใช้"| MEM
  GUARD -.->|"รักษาขอบไม่ให้ล้ำ"| LOOP
  LOOP -->|"invariant ไม่ atomic: compaction อาจตัดของสำคัญเงียบ ๆ"| EVAL
  classDef agentbox fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef ext fill:#bbf7d0,stroke:#166534,color:#14532d;
  classDef evalc fill:#fde68a,stroke:#92400e,color:#3f2d00;
  class SP,CTX,TOOLS,GIN,GTOOL,GOUT,GHIT,GSTOP,GSBX agentbox;
  class MEM ext;
  class EVAL evalc;

คำบรรยายภาพ: ทั้งหมดนี้คือ agent ตัวเดียว (Customer-Support) ไม่ใช่การแตกหลาย agent — กล่องขอบเขตล้อม system prompt, ชุด tool ที่ allowlist, working context และ guardrails ไว้เป็น consistency boundary แบบ ตั้งใจ คล้าย aggregate ใน domain แต่ต่างกันที่หัวใจ: aggregate รักษา invariant แบบ atomic ส่วนขอบของ agent เป็น best-effort เพราะ working context โตทุกรอบและถูก compaction บีบ ซึ่งอาจตัดข้อเท็จจริงที่ boundary ควรรักษาทิ้งเงียบๆ external memory (เขียว อยู่นอก context) จึงกันของสำคัญไม่ให้หายไปกับการสรุป, guardrails หลายชั้นรักษาขอบไม่ให้ล้ำ และ eval (เหลือง) วัดว่าขอบยังอยู่จริง — สามอย่างนี้มาแทนการรับประกันเชิงกลไกที่ agent ไม่มี ส่วน sub-agent isolation ที่พูดถึงในเนื้อหาเป็นกลวิธีรักษา context ของ agent หลัก ไม่ใช่คำสั่งให้แตก agent ตาม subdomain — เส้นแบ่ง agent ที่แท้จริงลากบนจุดที่ภาษา/ความไว้ใจเปลี่ยน (เรื่องของบทที่ 5) ไม่ใช่บนตำแหน่งงาน

สิ่งที่จะทำต่อ

บทนี้ปิดเรื่อง agent ตัวเดียว: เรารู้แล้วว่าจะกันมันไม่ให้หลุดขอบตลอด loop ยาวๆ ได้อย่างไร — คุม working context ด้วย compaction/external memory/sub-agent isolation, ทำ memory สองชั้น, กอง guardrail หลายด่าน และยอมรับว่าทั้งหมดนี้บังคับใช้ขอบเขตแบบ best-effort ไม่ใช่ atomic จึงต้องมี eval คอยวัด

บทที่ 5 ถึงจะเปิดคำถามที่เราเลื่อนมาตลอด: เมื่อไรถึงคุ้มที่จะมีมากกว่า1 agent — วาด context map ก่อน แล้วพิสูจน์ด้วยเหตุผลที่มีชื่อสามข้อ (context-protection, parallelization, specialization) บวกประตูต้นทุน ไม่ใช่แตกตาม subdomain แบบอัตโนมัติ วินัยเดิมยังอยู่: รู้ว่าอะไรควรอยู่ใน agent ที่มีขอบเขตดีตัวเดียวให้ชัดก่อน แล้วค่อยแตกเมื่อมีเหตุผลจริง

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:

Bounded Context — ขอบเขตที่ model หนึ่งชุดและภาษาหนึ่งชุดคงความหมายไว้ บทนี้ยืมมันมาใช้กับ agent ในฐานะ เจตนา ที่ต้องลงแรงบังคับ ไม่ใช่กำแพงฟรี
Aggregate — consistency boundary ที่รักษา invariant แบบ atomic คือหลักที่บทนี้ใช้เทียบเพื่อชี้ disanalogy: agent context หลัง compaction ไม่ ให้การรับประกันแบบเดียวกัน

เช็กความเข้าใจ — บทที่ 4

ข้อ 1 / 3

สามกลไกหลักที่ใช้ควบคุม working context ของ agent ไม่ให้บวมจน context rot คืออะไร?

Bounded Context → agent หนึ่ง​ตัว (memory + guardrails)

working context ไม่ใช่​ของ​นิ่ง มัน​โต​ทุกรอบ

สาม​กลไก​คุม working context

memory สอง​ชั้น: ระยะ​สั้น​ใน thread กับ​ระยะ​ยาว​ภายนอก

guardrail เป็นกอง ไม่ใช่​ช่อง​เดียว