Context Map → multi-agent เป็นข้อยกเว้นที่ต้องมีเหตุผล

ถ้ามีบทเดียวในคอร์สนี้ที่คนอ่านแล้วเอาไปใช้ผิดง่ายที่สุด บทนี้คือบทนั้น — เพราะมันคือบทที่พูดเรื่อง Multi-agent และแค่มีคำนี้อยู่ในหัวเรื่องก็พอจะทำให้คนกระโดดไปแตก agent เป็นสิบตัวโดยไม่ได้ถามว่าทำไม สี่บทที่ผ่านมาเราลงแรงกับคำถามเดียว: อะไรควรอยู่ใน agent ที่มีขอบเขตดี ตัวเดียว บทนี้ถึงจะเปิดประตูให้มีหลายตัว — แต่เปิดแบบมีเงื่อนไข ไม่ใช่เปิดทิ้งไว้ วิธีเปิดที่ถูกคือหยิบเครื่องมือ DDD ที่คุ้นมืออีกชิ้นมาใช้: Context Map วาดแผนที่ก่อน แล้วค่อยเถียงเรื่องจำนวนตัว

ขอปักธงตั้งแต่ต้นบท เพราะนี่คือความเสี่ยงอันดับหนึ่งของทั้งบท: multi-agent ไม่ใช่ค่าเริ่มต้น ทุกแหล่งที่บทนี้อ้าง — ทั้ง Anthropic และ Cognition — พูดตรงกันว่าให้เริ่มจาก agent เดียวเสมอ แล้วขึ้น multi-agent เมื่อพิสูจน์ได้ว่าคุ้มเท่านั้น DDD ไม่ได้แปลว่า “หนึ่ง Bounded Context ต่อ1 agent” — DDD คือวินัยที่บอกว่าอะไรควรอยู่ใน agent ตัวเดียวก่อน แล้ว multi-agent จึงเป็น ข้อยกเว้นที่ต้องมีเหตุผล

📦 code ตัวอย่าง

คอร์สนี้เป็น คอร์สออกแบบ ไม่ใช่ทัวร์ SDK — code ในบทคือ ภาพร่าง ของ context map, โทโพโลยี และ pseudo-config สั้นๆ (Thai Mermaid) ไม่ใช่ app ที่รันได้จริง สิ่งที่วาดด้วย LangGraph / OpenAI Agents SDK / Claude เป็นเพียงตัวอย่างประกอบ ตัวอย่างต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) โดยมองมันผ่านเลนส์ ops-copilot ที่ช่วยทีมปฏิบัติการของ platform

วาด context map ก่อนจะพูดเรื่องจำนวนตัว

ใน DDD เราไม่ตัดสินใจว่าจะมีกี่ service ก่อนจะรู้ว่า domain มีกี่ bounded context และแต่ละอันสัมพันธ์กันยังไง context map คือแผนภาพที่ตอบคำถามนั้น — มันวาด ทุก bounded context และความสัมพันธ์ระหว่างกัน (ใครเป็นต้นน้ำที่กำหนดรูปแบบข้อมูล ใครเป็นปลายน้ำ ตรงไหนต้องมี Anti-Corruption Layer กั้น) กับ agent ก็ใช้ลำดับเดียวกัน: วาด context map ของ ops-copilot ก่อน แล้วค่อยถามว่าแต่ละกล่องบนแผนที่ควรเป็น agent จริง เป็น workflow หรือควรถูกยุบรวมกัน

จุดที่ต้องแยกให้ขาดคือ context map วาด discontinuity ของ domain ไม่ได้วาดจำนวน agent เส้นบนแผนที่คือจุดที่ภาษาเปลี่ยนและระดับความไว้ใจเปลี่ยน — เหมือนที่เราลากในคอร์ส Bounded Contexts ตอนแยก order ในครัว ไรเดอร์ และบิลลิ่งออกจากกัน แผนที่บอกว่า ขอบเขตอยู่ตรงไหน ส่วนคำถามว่า จะ implement แต่ละขอบเขตด้วยกี่ agent เป็นการตัดสินใจที่มาทีหลัง และเป็นหัวใจของทั้งบทนี้

flowchart LR
  subgraph CM["Context Map ของ ops-copilot — เส้นแบ่งคือ discontinuity ของ domain ไม่ใช่จำนวน agent"]
    OT["Order-Tracking<br/>ภาษา ออเดอร์/สถานะ/ETA<br/>(อ่านอย่างเดียว)"]
    RO["Restaurant-Ops<br/>ภาษา เมนู/คิว/สต๊อก"]
    CS["Customer-Support<br/>ภาษา เคส/นโยบาย"]
    BILL["Billing<br/>ภาษา เงิน/สถานะจ่าย<br/>(คืนเงิน — ย้อนกลับไม่ได้)"]
  end
  RO -->|"upstream: คิว/พร้อมเสิร์ฟ"| OT
  OT -->|"upstream: ส่งสถานะ/ETA"| CS
  CS ==>|"ผ่าน ACL + human-in-the-loop"| BILL
  classDef ctx fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef risky fill:#fca5a5,stroke:#7f1d1d,color:#1a1a1f;
  class OT,RO,CS ctx;
  class BILL risky;

คำบรรยายภาพ: context map ของ ops-copilot — สี่กล่องคือ bounded context ของ domain ลูกศรบอกทิศต้นน้ำ→ปลายน้ำ (Order-Tracking ป้อนสถานะให้ Customer-Support) และเส้นหนาไป Billing คือจุดที่ต้องมี ACL + Human-in-the-loop คั่นเพราะการคืนเงินย้อนกลับไม่ได้ ย้ำว่าแผนที่นี้ไม่ได้สั่งว่าต้องมี4 agent — เส้นถูกลากบน discontinuity ของภาษาและความไว้ใจ ไม่ใช่ตำแหน่งงานหรือ subdomain แต่ละกล่องอาจเริ่มเป็น workflow, บางคู่ที่ภาษาใกล้กันอาจยุบรวมเป็น agent เดียว การนับจำนวนตัวเป็นคนละคำถามที่เราจะตอบด้านล่าง

multi-agent มีเหตุผลรองรับได้แค่ 3 ข้อ

เมื่อมี context map แล้ว คำถามคือ “ขอบเขตไหนคุ้มที่จะแยกเป็น agent ต่างหาก” คำตอบไม่ใช่ “ทุกอันบนแผนที่” บทความ When to use multi-agent systems (and when not to) (Anthropic/Claude) ให้กรอบที่คมมาก: การแยก agent ออกไปอีกตัวจะคุ้มก็ต่อเมื่อมันตอบได้ว่าอยู่ในเหตุผลข้อใดข้อหนึ่งจาก สามข้อนี้เท่านั้น

Context protection — งานย่อยนี้ต้องกิน context ก้อนใหญ่ (เช่นอ่านเอกสารยาวๆ หลายสิบหน้า) แล้ว “ผลย่อ” ที่ได้กลับมาสั้นนิดเดียว การแยกออกเป็น agent ต่างหากทำให้ context ก้อนใหญ่ไปเน่าอยู่ในหัว worker ตัวนั้นแทนที่จะไหลกลับมาเจือจางงบ attention ของตัวหลัก — นี่คือยาแก้ Context Rot โดยตรง
Parallelization — งานย่อยหลายชิ้น เป็นอิสระต่อกันจริง และรันพร้อมกันได้ เช่นต้องเช็กสถานะร้านสิบร้านที่ไม่เกี่ยวกัน การกระจายให้ worker หลายตัวทำขนานกันลดเวลารวมลงได้จริง
Specialization — งานย่อยต้องใช้ชุด tool, system prompt หรือกระทั่ง model ที่ต่างกันชัดเจนจนยัดรวมใน agent เดียวแล้วภาษาเริ่มตีกัน การแยกให้แต่ละตัวมีความเชี่ยวชาญเฉพาะทำให้แต่ละตัวคมกว่า

สังเกตว่าทั้งสามข้อพูดถึง คุณสมบัติของงาน (context หนัก / ขนานได้ / เชี่ยวชาญต่างกัน) ไม่มีข้อไหนพูดว่า “เพราะมันเป็นคนละ subdomain” หรือ “เพราะผังองค์กรแบ่งงานแบบนี้” ถ้าขอบเขตหนึ่งบน context map ตอบไม่ได้สักข้อในสามข้อนี้ มันควรอยู่ใน agent เดิมหรือเป็น tool/workflow ต่อไป ไม่ใช่ agent ใหม่

แบ่งตาม context-isolability ไม่ใช่ตาม phase

สามข้อข้างบนมีแกนร่วมเส้นเดียว: แบ่งตรงจุดที่ context แยกกันได้จริง (context-isolable) งานย่อยที่คุ้มจะเป็น agent แยกคืองานที่เอา context ของมันไปทำจนจบในกล่องปิดของตัวเองได้ แล้วส่งกลับมาแค่ผลลัพธ์ย่อๆ — ไม่ใช่งานที่ต้องคอยส่งสถานะไปมาทุกก้าว

กับดักที่พบบ่อยที่สุดคือแบ่งตาม phase ของงาน หรือ ตำแหน่งงาน — planner → coder → reviewer — เพราะมันเลียนผังการทำงานของคนได้สวยงาม แต่มันพังด้วยเหตุผลเดียว: 3 phase นี้ไม่ได้ context-isolable เลย coder ต้องรู้ เหตุผล ที่ planner ตัดสินใจ ไม่ใช่แค่ผลลัพธ์ของแผน และ reviewer ต้องเห็นข้อมูลชุดเดียวกับที่ planner เห็นตอนตัดสินใจ พอแยกเป็นคนละ agent ทุก Handoff จึงบีบ context ทั้งก้อนให้เหลือข้อความสั้นๆ ส่งต่อ — ทุก handoff เสีย context บทความ Cognition — Don’t Build Multi-Agents ชี้ตรงนี้ชัด: decision ที่ agent ตัวก่อนทำไปโดยปริยาย (implicit) หายไปกับ handoff จน agent ตัวถัดตัดสินใจขัดกันเอง งานที่บริบทพัวพันกันแน่นแบบนี้ควรอยู่ใน agent เดียวที่ถือ context ต่อเนื่อง ไม่ใช่แตกตาม phase

topology: pipeline            # แบ่งตาม "ขั้นตอนของงาน" ไม่ใช่ตามจุดที่ context แยกกันได้จริง
agents:
  - planner    # วางแผน แล้วโยน "แผนที่ย่อแล้ว" ให้ตัวถัดไป
  - coder      # ลงมือ แต่ไม่เห็นเหตุผลเบื้องหลังที่ planner ชั่งไว้
  - reviewer   # ตรวจงาน แต่ไม่เห็นข้อมูลชุดเดียวกับที่ planner ตัดสินใจ
handoff: บริบทที่ตัดสินใจถูกบีบเป็นข้อความสั้น → decision โดยปริยายหล่นหายทุกทอด
# version เดียวกันในคราบองค์กร: "1 agent ต่อหนึ่งทีม / 1 subdomain"
# ทั้งคู่ผิดเพราะแบ่งตามผังงาน/ผังคน ไม่ได้แบ่งตาม context-isolability

ฝั่งที่ ได้ผลจริง เป็นภาพกลับกัน — Cognition — Multi-Agents: What’s Actually Working เล่าว่าโครงที่เวิร์กคือให้ subagent รับงานที่ปิดจบในตัวเองได้ (เช่น “ไปหาข้อมูล X มา”) แล้วคืนผลย่อกลับหา agent หลักที่ยังถือ context หลักไว้ตลอด — ไม่ใช่ pipeline ที่โยน state ต่อกันเป็นทอดๆ นี่คือ context-isolability และมันตรงกับข้อ context protection / parallelization ข้างบนพอดี

กฎ DDD กับกฎ agent คือกฎเดียวกัน

พอวางเรียงกัน ประโยคเด็ดของบทนี้จะโผล่มาเอง — วินัยที่เรากำลังใช้กับ agent ไม่ใช่ของใหม่ มันคือกฎ DDD คำเดิมที่แค่เปลี่ยนคำนาม:

กฎ DDD: อย่าแยก bounded context ออกจากกัน ถ้าไม่มี discontinuity ของภาษา/model จริงๆ รองรับ

กฎ agent: อย่าไป multi-agent ถ้าไม่มีเหตุผล isolation จริงๆ (context protection / parallelization / specialization) รองรับ

สองประโยคนี้คือกฎเดียวกัน คำว่า “discontinuity” ในโลก DDD (ภาษาเปลี่ยน model เปลี่ยน จนบังคับต้องแยก) คือคำเดียวกับ “isolation” ในโลก agent (context แยกกันได้จริงจนคุ้มจะแยก) และในทั้งสองโลก ภาระการพิสูจน์อยู่ที่ฝ่ายที่อยากแยก ไม่ใช่ฝ่ายที่อยากรวม — การแยกมีต้นทุน (integration, การเสีย context ที่ handoff, ความซับซ้อน) เสมอ ถ้าพิสูจน์ discontinuity/isolation ไม่ได้ คำตอบตั้งต้นคือ “อยู่รวมกันไปก่อน” นี่คือเหตุผลที่ DDD เป็นเครื่องมือที่เหมาะกับยุค multi-agent hype พอดี: มันคือวินัยของการ ไม่แยกโดยไม่มีเหตุผล ที่วงการ agent กำลังค้นพบใหม่ด้วยตัวเอง

Orchestrator-Workers: ข้อยกเว้นที่มีเหตุผลและ ship แล้วจริง

ถึงตรงนี้อาจฟังดูเหมือนบทนี้จะบอกว่า “อย่าทำ multi-agent เลย” — ไม่ใช่ เมื่อเหตุผลข้อใดข้อหนึ่งในสามข้อเป็นจริง multi-agent ก็คุ้มจริง และโทโพโลยีที่พิสูจน์ตัวเองแล้วมีชื่อว่า Orchestrator-Workers: agent หลัก (lead / orchestrator) แตกงานใหญ่เป็นงานย่อยที่ context-isolable แล้วมอบให้ worker แต่ละตัวไปทำในกล่องปิดของมัน ก่อนรวม “ผลย่อ” กลับมาที่ lead — lead เป็นคนเดียวที่ถือภาพรวม ไม่ใช่ปล่อยให้ worker คุยกันเองมั่วๆ

นี่ไม่ใช่ทฤษฎี Anthropic เล่าใน How we built our multi-agent research system (Anthropic, Jun 2025) ว่าระบบ research ที่ใช้โครงนี้ ชนะ single-agent baseline ถึง 90.2% บน eval ภายใน และพบว่า token ที่ใช้อธิบาย variance ของ performance ได้ถึง ~80% (งานที่ต้องค้นกว้างๆ ขนานได้ ยิ่งได้ประโยชน์จากการกระจาย worker) — แต่ตัวเลขที่ต้องจำให้ขึ้นใจคือ ต้นทุน: multi-agent กิน token ราว ~15 เท่า ของแชตเดี่ยว นั่นคือ “ประตูต้นทุน” ที่ทำให้โครงนี้คุ้มเฉพาะกับงานที่มูลค่าสูงพอและขนานได้จริง เช่นงานค้นคว้ากว้างๆ ไม่ใช่ทุกงานตอบลูกค้าทั่วไป งานที่ ~15 เท่าไม่คุ้มก็กลับไปที่ agent เดียว

flowchart LR
  subgraph DEFAULT["ค่าเริ่มต้น: single-agent (เริ่มที่นี่เสมอ)"]
    SA["agent เดียวที่มีขอบเขตดี<br/>1 bounded context<br/>context ต่อเนื่อง คุมง่าย ถูก"]
  end
  subgraph EXC["ข้อยกเว้นที่มีเหตุผล: Orchestrator-Workers"]
    LEAD["lead / orchestrator<br/>ถือภาพรวม + แตกงานที่ context-isolable"]
    W1["worker A<br/>context แยกของตัวเอง<br/>ทำจนจบในกล่องปิด"]
    W2["worker B<br/>context แยกของตัวเอง<br/>ทำจนจบในกล่องปิด"]
    LEAD --> W1
    LEAD --> W2
    W1 -->|"คืนผลย่อ"| LEAD
    W2 -->|"คืนผลย่อ"| LEAD
  end
  DEFAULT ==>|"ข้ามมาได้ต่อเมื่อมี 1 ใน 3 เหตุผล + ผ่านประตูต้นทุน ~15×"| EXC
  classDef def fill:#bbf7d0,stroke:#166534,color:#1a1a1f;
  classDef orch fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  class SA def;
  class LEAD,W1,W2 orch;

คำบรรยายภาพ: ซ้ายคือค่าเริ่มต้นที่ต้องเริ่มเสมอ — single-agent ที่มีขอบเขตดีตัวเดียว ขวาคือข้อยกเว้น Orchestrator-Workers: lead แตกงานให้ worker ที่มี context แยกของตัวเอง ทำจนจบในกล่องปิด แล้วคืนผลย่อกลับหา lead (ไม่ใช่ pipeline ที่โยน state ต่อกัน) เส้นหนากลางภาพคือประตู — ข้ามได้ต่อเมื่อมี 1 ใน 3 เหตุผล และ งานคุ้มกับต้นทุน ~15 เท่า ย้ำ propagation rule ของทั้งคอร์ส: การที่รูปแตกกล่องหนึ่งเป็นหลายกล่องไม่ได้แปลว่าต้องมี agent แยกจริงเสมอ — เส้นถูกลากบน context-isolation discontinuity ไม่ใช่บนตำแหน่งงานหรือ subdomain worker บางตัวเริ่มเป็น workflow ได้ บางคู่ยุบรวมได้ และ single-agent ฝั่งซ้ายยังเป็นคำตอบที่ถูกสำหรับงานส่วนใหญ่

ข้อควรระวังที่ต้องพูดให้ตรง: agent ไม่ใช่ aggregate

เพื่อไม่ให้อุปมา “agent = bounded context” ถูกยืดเกินจริง ต้องพูดจุดที่มันไม่เหมือนให้ชัด ใน DDD ตัว aggregate รักษา invariant แบบ atomic — กฎธุรกิจถูกบังคับ ณ ขอบของ aggregate ทุกครั้งที่ commit ไม่มีทางที่สถานะจะละเมิดกฎแล้วรอด แต่ context ของ agent ไม่ได้ ให้การรับประกันแบบนั้น เมื่อ context ถูก compact หรือ summarize เพื่อกันไม่ให้ยาวเกิน กฎที่เคยอยู่ใน context อาจถูกย่อหายหรือเพี้ยนไปได้ การบังคับกฎของ agent จึงเป็นแบบ best-effort ไม่ใช่ atomic

นี่ไม่ใช่รายละเอียดปลีกย่อย มันคือเหตุผลว่าทำไมระบบ agent จริงต้องมีของสามอย่างประกอบเสมอ: Agent Memory ภายนอกเพื่อกันข้อเท็จจริงสำคัญไม่ให้หายตอน compact, Guardrail เพื่อรักษาขอบเขตด้วยกลไกนอก context (เช่นบังคับ human approval ก่อนคืนเงิน — ไม่ฝากไว้กับ prompt ที่อาจถูกย่อทิ้ง) และ Eval เพื่อวัดว่าขอบเขตยังถูกรักษาไว้จริงหลังผ่านหลายรอบ กล่าวอีกแบบ: context map บอกว่าขอบเขต ควร อยู่ตรงไหน แต่การทำให้ขอบเขตนั้น ถูกรักษาไว้จริง ต้องอาศัย memory + guardrail + eval ไม่ใช่หวังพึ่ง context window อย่างเดียว

สรุปบทนี้

วาด context map ก่อน แล้วค่อยนับจำนวน agent — แผนที่วาด discontinuity ของ domain ไม่ได้สั่งจำนวนตัว
multi-agent คุ้มก็ต่อเมื่อมี 1 ใน 3 เหตุผล: context protection / parallelization / specialization — ไม่ใช่ “1 agent ต่อ1 subdomain”
แบ่งตาม context-isolability ไม่ใช่ตาม phase/ตำแหน่งงาน — planner/coder/reviewer พังเพราะทุก handoff เสีย context
กฎ DDD = กฎ agent: อย่าแยกถ้าไม่มี discontinuity/isolation จริง ภาระพิสูจน์อยู่ที่ฝ่ายที่อยากแยก
Orchestrator-Workers เป็นข้อยกเว้นที่ ship แล้วจริง (ชนะ single-agent 90.2%, token อธิบาย variance ~80%, ต้นทุน ~15×) — แต่เริ่มที่ single-agent เสมอ
agent ไม่ใช่ aggregate: การบังคับกฎเป็น best-effort ไม่ใช่ atomic จึงต้องมี memory + guardrail + eval

บทถัดไปจะเจาะจุดที่ agent สองตัวมาเจอกันจริง — Anti-Corruption Layer กับการออกแบบ tool ให้เป็นชั้นแปลภาษาที่กั้นความรกของ backend ไม่ให้ไหลเข้ามาปน context ของ agent

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

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

Context Mapping — การวาดแผนที่ทุก bounded context และความสัมพันธ์ต้นน้ำ/ปลายน้ำ เครื่องมือที่บทนี้ยืมมาใช้ก่อนตัดสินใจจำนวน agent
Bounded Context — ขอบเขตที่ model และภาษาหนึ่งชุดคงความหมายไว้ หน่วยที่ agent แต่ละตัว (หรือกลุ่ม agent) ควรรับผิดชอบ
Anti-Corruption Layer — ชั้นแปลภาษาที่กั้นระหว่าง context จุดที่บทนี้ชี้ว่าต้องมีคั่นก่อนถึง Billing

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

ข้อ 1 / 3

เหตุผลสามข้อที่ทำให้การแตกเป็น multi-agent สมเหตุผลคืออะไร?

Context Map → multi-agent เป็น​ข้อ​ยกเว้น​ที่​ต้อง​มี​เหตุผล

วาด context map ก่อน​จะ​พูด​เรื่อง​จำนวน​ตัว

multi-agent มี​เหตุผล​รองรับ​ได้​แค่ 3 ข้อ

แบ่ง​ตาม context-isolability ไม่ใช่​ตาม phase

กฎ DDD กับ​กฎ agent คือ​กฎ​เดียวกัน

Orchestrator-Workers: ข้อ​ยกเว้น​ที่​มี​เหตุผล​และ ship แล้ว​จริง

ข้อ​ควร​ระวัง​ที่​ต้อง​พูด​ให้​ตรง: agent ไม่ใช่ aggregate

สรุป​บท​นี้