Anti-Corruption Layer → ต่อ tool/API ภายนอก

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

📦 code ตัวอย่าง

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

backend พูดคนละภาษากับ agent

order-service ที่เก็บออเดอร์ไม่ได้ถูกออกแบบมาให้ model อ่าน มันถูกออกแบบมาให้เครื่องอ่าน — มันคืน UUID เป็นตัวระบุ, payload JSON สี่10 field, สถานะเป็น enum ตัวเลขภายใน, และเวลาพังก็โยน HTTP 500 พร้อม stack trace กลับมา นี่คือ model ของ Subdomain คนละอันกับ Order-Tracking agent — มันมีเหตุผลของมันในบริบทของมันเอง แต่ไม่ใช่ภาษาที่ agent ใช้ตัดสินใจได้

ถ้าเราปั้น Tool ที่แค่ส่ง response ก้อนนั้นกลับเข้ามาตรงๆ ปัญหาไม่ได้จบแค่ “อ่านยาก” — ทุก field ที่ agent ไม่ได้ใช้ก็ยังกิน งบ attention เท่ากับ field ที่ใช้ นี่คือ Context Rot จากบทที่ 1 ในคราบใหม่: ยิ่ง payload บวม ความสามารถในการดึงข้อเท็จจริงชิ้นที่สำคัญ ณ ตานั้นยิ่งจาง และเพราะ Agentic Loop เอาผล tool กลับเข้า context ทุกรอบ ต้นทุนก้อนนี้จ่ายซ้ำทุกรอบที่วน ไม่ใช่ครั้งเดียวจบ

tool คือ Anti-Corruption Layer

ตรงนี้เองที่ Anti-Corruption Layer ของ DDD เข้ามาเป๊ะๆ ACL คลาสสิกคือชั้นแปลที่คั่นระหว่าง Bounded Context สองอัน ไม่ให้ model ของฝั่งต้นน้ำรั่วเข้ามาปนเปื้อน code เรา — สิ่งที่มันรักษาคือ code ของเรา จากการเปลี่ยนรูปของ schema ต้นน้ำ tool ของ agent ทำงานนั้นเหมือนกันทุกประการ บวกอีกหนึ่งหน้าที่: มันยังต้องรักษา ตัว model จากรูปดิบและความ verbose ของ backend ด้วย เพราะฝั่งที่บริโภคผลไม่ใช่ code deterministic แต่เป็น model ภาษาที่มีงบ attention จำกัด

พูดให้เป็นวินัย: tool ที่ดีคือ Anti-Corruption Layer ไม่ใช่ท่อส่ง API ดิบ Writing effective tools for AI agents (Anthropic) สรุปหน้าที่ของชั้นแปลนี้ไว้สามอย่าง:

คืนข้อมูลสัญญาณสูง (high-signal) — เฉพาะ field ที่ agent ต้องใช้ตัดสินใจก้าวถัดไป ไม่ใช่ payload ทั้งก้อน ทุก field ที่ตัดออกคืองบ attention ที่คืนกลับมา
ใช้ตัวระบุเชิงความหมายที่เสถียร — คืนชื่อ/slug/เลขออเดอร์ที่มนุษย์กับ model reason ด้วยได้ ไม่ใช่ UUID ดิบหรือ handle ทึบๆ ผลลัพธ์ที่สะอาดนี้เองคือ Ubiquitous Language ของ agent ที่ปรากฏจริงในบริบท
error ที่เจาะจงและแก้ได้ — ไม่ใช่ HTTP 500 กับ stack trace แต่เป็นข้อความที่บอก model ว่า เกิดอะไร และ ควรลองอะไรต่อ

version ที่พลาดคือปล่อยให้ backend ไหลเข้ามาทั้งดุ้น:

tool: get_order
returns: |
  # ส่ง response ของ order-service กลับตรง ๆ ทั้งก้อน
  {
    "order_id": "9f2c1b7a-3e5d-4a11-b2c8-77e0a1f3de71",   # UUID ทึบ
    "customer_id": "c_0b9e4f...",
    "restaurant_id": "r_5521aa...",
    "line_items": [ ... 30 บรรทัด ... ],
    "status_code": 7,             # enum ภายใน ไม่มีความหมายใน context
    "internal_flags": { ... },
    "audit_trail": [ ... ],
    # ...อีกสามสิบกว่า field ที่ agent ไม่ได้ใช้ แต่กินงบ attention เท่ากัน
  }
error: "HTTP 500: NullPointerException at OrderService.java:214"

version ที่เป็น ACL แปลทุกอย่างให้เป็นภาษาสะอาดก่อนคืน:

tool: get_order_status
description: |
  ดูสถานะและ ETA ของออเดอร์จากเลขออเดอร์ 6 หลัก (เช่น A-4821)
  ใช้เมื่อผู้ใช้ถามว่า "ออเดอร์ถึงไหนแล้ว"
input:
  order_no: string     # เลขที่ลูกค้าเห็นบนใบเสร็จ ไม่ใช่ UUID ภายใน
returns: |
  {
    "order_no": "A-4821",
    "status": "กำลังจัดส่ง",        # แปลจาก enum 7 -> คำที่มีความหมาย
    "eta_min": 12,
    "restaurant": { "name": "ส้มตำนัว", "slug": "somtam-nua" }
  }
errors:
  - not_found: "ไม่พบออเดอร์ A-4821 — ขอเลขออเดอร์ 6 หลักจากลูกค้าอีกครั้ง"
  - ambiguous: "พบหลายออเดอร์ใกล้เคียง ระบุเลขให้ครบ 6 หลัก"

ทำไมคืน slug ไม่ใช่ UUID ดิบ

จุดที่ดูเล็กแต่สำคัญที่สุดคือ ตัวระบุ UUID ดิบเป็นค่า opaque — model reason กับมันไม่ได้ จำข้ามรอบได้ยาก และถ้ามันจำ/พิมพ์ผิดตัวเดียวใน 9f2c1b7a... การเรียกครั้งต่อไปก็พลาดแบบเงียบๆ โดยไม่มีสัญญาณว่าเพราะอะไร ตรงข้ามกับตัวระบุเชิงความหมายที่เสถียรอย่างเลขออเดอร์ A-4821 หรือร้าน slug somtam-nua:

มันเป็นส่วนหนึ่งของ ubiquitous language อยู่แล้ว — ทั้งลูกค้า พนักงาน และ model ใช้คำเดียวกัน tool จึงไม่ได้สร้างศัพท์ใหม่ให้จำ
มันรอด compaction/summarization ได้ดีกว่า เพราะเป็นคำที่มีความหมาย ไม่ใช่สายอักขระสุ่มที่ถูกย่อแล้วเพี้ยนง่าย
มันตรวจสอบได้ — รูปแบบ A-4821 ผิดปกติเมื่อไรก็เห็น ต่างจาก UUID ที่ผิดหนึ่งตัวก็ยังดู “เหมือนจริง”

การคืน slug จึงไม่ใช่แค่เรื่องความสวยงามของ output แต่คือการเลือกภาษาที่ caller ซึ่งเป็น model ใช้ต่อได้จริง

harden contract ต่อ caller ที่ไม่ deterministic

นี่คือความต่างที่ลึกที่สุดระหว่าง tool ของ agent กับ API ธรรมดา API ทั่วไปสมมติว่า caller เป็น code deterministic — เรียกตรงตามเอกสารเป๊ะทุกครั้ง แต่ caller ของ tool คือ agent ที่ ไม่ deterministic: มันอาจอ่าน schema ผิด, hallucinate parameter ที่ไม่มีจริง, เรียกผิดตัว, หรือส่ง id ที่มันแต่งขึ้นเอง tool ที่ดีจึงไม่ใช่ passthrough ที่เชื่อว่า caller เรียกถูกเสมอ แต่เป็น contract ที่ถูก harden ไว้ต่อ caller ที่ใช้ผิดได้ — ออกแบบโดยตั้งสมมติฐานว่าการใช้ผิดจะเกิดขึ้นจริง:

schema ที่บรรยายชัดและตั้งชื่อตรงกับ ubiquitous language — เพื่อให้ model เลือก tool ถูกตัวและกรอก field ถูกตั้งแต่แรก
ตรวจ input ให้ fail เร็วและดัง — id รูปแบบผิดต้องถูกปฏิเสธทันทีพร้อมบอกว่าผิดตรงไหน ไม่ใช่ยิงเข้า backend แล้วพังลึก
รับ input ที่ผ่อนปรน — รับเลขออเดอร์ 6 หลักที่ลูกค้ามีจริง แทนที่จะบังคับ UUID ภายในที่ model ไม่มีทางรู้
เขียน error ให้สอน model ว่าจะกู้ยังไง — ไม่พบออเดอร์ A-4821 — ขอเลขออเดอร์ 6 หลักจากลูกค้าอีกครั้ง มีค่ากว่า HTTP 404 มหาศาล เพราะมันบอกก้าวถัดไป

นี่คือ Guardrail ที่ระดับ tool boundary โดยตรง: ชั้นแปลไม่ได้แค่ทำให้ข้อมูลสะอาด แต่ทำให้ตัว contract ทนต่อการถูกเรียกแบบมั่วๆ ได้ด้วย

ขอบที่ tool กั้นได้ ไม่ใช่ aggregate

ต้องพูดให้ตรงจุดหนึ่งไม่ให้เข้าใจผิด ในโลก DDD บาง Bounded Context มี aggregate ที่ enforce invariant แบบ atomic — พอ aggregate รับคำสั่ง invariant ก็เป็นจริงทันที ณ วินาทีนั้น แบบ transaction มันน่าเผลอคิดว่า tool-ในฐานะ-ACL ให้หลักประกันเดียวกัน คือ “ข้อมูลสะอาดเข้าไปแล้ว กฎก็ถูกรักษา” — แต่มันไม่ใช่ tool ทำความสะอาดข้อมูล ตรงจุดเข้า เท่านั้น ส่วน context ของ agent ที่อยู่ถัดจากนั้นไม่ใช่ขอบเขต transaction หลัง compaction หรือ summarization ข้อเท็จจริงสะอาดที่ tool คืนมา (เลขออเดอร์ที่ถูกต้อง หรือกฎ “คืนเงินต้องมีคนอนุมัติ”) อาจถูกตัดทิ้ง ถูกบีบจนเพี้ยน หรือถูก hallucinate ขึ้นใหม่ได้

ดังนั้น ACL ที่ระดับ tool เป็นการรักษาแบบ best-effort ไม่ใช่การบังคับแบบ atomic ตลอดกาล มันลดการปนเปื้อนที่ประตู แต่ไม่การันตีว่าความสะอาดจะอยู่ยงตลอด session — และนี่คือเหตุผลตรงๆ ว่าทำไมบทก่อนๆ ถึงต้องวางชั้นอื่นทับเข้าไป: Agent Memory เพื่อดึงข้อเท็จจริงกลับขึ้นมาย้ำ, guardrail กับ Human-in-the-loop เพื่อ hard-stop การกระทำที่ย้อนไม่ได้ไม่ว่า context จะบอกอะไร, และ Eval เพื่อวัดว่าขอบนี้กั้นได้จริงในทางปฏิบัติหรือเปล่า tool boundary จำเป็น แต่ไม่พอด้วยตัวมันเอง

เห็นภาพ: backend รก → ชั้นแปล → ภาษาสะอาด

flowchart LR
  subgraph BE["❌ backend รก — model ภายในของ order-service"]
    RAW["order_id: 9f2c...de71 (UUID ทึบ)<br/>payload JSON เต็ม 40 field<br/>status_code: 7 (enum ภายใน)<br/>error: HTTP 500 + stack trace"]
  end
  subgraph ACL["tool = Anti-Corruption Layer (ชั้นแปล)"]
    T["get_order_status(order_no)<br/>• ตัดเหลือ field สัญญาณสูง<br/>• UUID → เลขออเดอร์/slug ที่เสถียร<br/>• enum → คำที่มีความหมาย<br/>• error ดิบ → error เจาะจงที่แก้ได้"]
  end
  subgraph AG["✅ ภาษาสะอาดของ agent — Order-Tracking"]
    CLEAN["order_no: A-4821<br/>status: กำลังจัดส่ง<br/>eta_min: 12<br/>restaurant: ส้มตำนัว (somtam-nua)"]
  end
  RAW ==>|"agent ไม่ต้องเห็นความรกนี้"| T
  T ==>|"คืนเฉพาะสิ่งที่ใช้ตัดสินใจรอบถัดไป"| CLEAN
  classDef raw fill:#dc2626,stroke:#7f1d1d,color:#f8fafc;
  classDef acl fill:#fde68a,stroke:#b45309,color:#1a1a1f;
  classDef clean fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  class RAW raw;
  class T acl;
  class CLEAN clean;

คำบรรยายภาพ: ฝั่งซ้าย (แดง) คือ model ภายในของ order-service ที่รกด้วย UUID ทึบ payload เต็มก้อน enum ภายใน และ error ดิบ — เหมาะกับ caller ที่เป็น code ไม่ใช่ model ตรงกลาง (เหลือง) คือ tool ที่ทำหน้าที่ Anti-Corruption Layer: ตัดให้เหลือ field สัญญาณสูง แปลง UUID เป็นเลขออเดอร์/slug ที่เสถียร แปลง enum เป็นคำที่มีความหมาย และเปลี่ยน error ดิบเป็น error ที่บอกก้าวถัดไป ฝั่งขวา (น้ำเงิน) คือภาษาสะอาดที่ agent อ่านแล้วตัดสินใจต่อได้ทันที ย้ำว่าเส้นแปลนี้กั้นความปนเปื้อนได้แค่ ตรงจุดเข้า — context ที่อยู่ถัดไปไม่ใช่ขอบเขต atomic แบบ aggregate ความสะอาดจึงเป็น best-effort ที่ยังต้องมี memory + guardrail + eval หนุนหลัง

สรุปและสิ่งที่จะทำต่อ

tool ไม่ใช่แค่ “ปุ่มให้ agent กด” แต่คือ Anti-Corruption Layer ที่ลากเส้นภาษาระหว่าง agent กับโลกภายนอก — คืนข้อมูลสัญญาณสูง ใช้ตัวระบุที่เสถียรและมีความหมาย โยน error ที่แก้ได้ และถูก harden ไว้ต่อ caller ที่ไม่ deterministic ทำถูก ความรกของ backend ก็จบที่ขอบ ไม่ไหลเข้าไปเน่า context

สังเกตว่า schema ของ tool ที่เราตั้งใจออกแบบตรงนี้ คือรูปแรกของ สัญญาข้ามขอบเขต — มันคือ Published Language version ย่อ ระหว่าง agent กับ backend หนึ่งตัว บทที่ 7 จะยกแนวคิดเดียวกันนี้ขึ้นอีกชั้น: เมื่อ agent ต้องคุย กับ agent อีกตัว สัญญานั้นต้องนิ่งและชัดยิ่งกว่าเดิม เราจะแยก Handoff (โอนการควบคุมถาวร) ออกจาก delegation (มอบงานแล้วรอผลกลับ) ให้ขาด และดูว่า published language ทำให้สองขอบเขตคุยกันได้โดยไม่ปนเปื้อนกันยังไง

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

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

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

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

ข้อ 1 / 3

tool ของ agent ทำหน้าที่เป็น Anti-Corruption Layer อย่างไร?

Anti-Corruption Layer → ต่อ tool/API ภายนอก

backend พูด​คนละ​ภาษา​กับ agent

tool คือ Anti-Corruption Layer

ทำไม​คืน slug ไม่ใช่ UUID ดิบ

harden contract ต่อ caller ที่​ไม่ deterministic

ขอบ​ที่ tool กั้น​ได้ ไม่ใช่ aggregate

เห็น​ภาพ: backend รก → ชั้น​แปล → ภาษา​สะอาด

สรุป​และ​สิ่ง​ที่​จะ​ทำ​ต่อ