ความรู้ของ AI agent ควรอยู่ที่ไหน? — source of truth เดียว ไม่ให้ drift

TL;DR — พอคุณเริ่มมี memory, skills, instruction files, docs หลายที่ — ความรู้เดียวกันมัก ไปโผล่หลายที่ → แก้ที่นึงลืมอีกที่ = ขัดกัน (drift). กติกาเดียวที่กันได้: ความรู้แต่ละชิ้นมี “บ้านเดียว” (source of truth) ที่อื่นเป็นแค่ pointer ชี้มา — copy ได้แบบเดียวคือ vendored (read-only)

🌐 vendor-neutral — หลักการใช้ได้ทุกเครื่องมือ. บทความนี้มัดรวมสามเรื่องก่อนหน้าในซีรีส์ — memory, repo files, skills — เข้าเป็นภาพเดียว: “อะไรอยู่ที่ไหน”

ปัญหา: knowledge เดียว ไปอยู่หลายที่ → drift

ยิ่งคุณตั้งค่า agent มากขึ้น ยิ่งมี “ที่เก็บความรู้” หลายแบบ: memory ส่วนตัว, skill/command, instruction file (CLAUDE.md/AGENTS.md), docs ในเรพ. แล้วสิ่งที่เกิดคือ ความรู้เดียวกันไปอยู่ หลายที่:

• workflow “ลงบทความ” เขียนไว้ทั้งใน skill และ memory และ doc
• กติกา “commit เป็นใคร” อยู่ทั้ง CLAUDE.md และ memory

พอแก้ที่นึง ลืมอีกที่ → สองที่ขัดกัน → agent สับสนว่าเชื่ออันไหน. นี่คือ drift

แผนที่: ความรู้แต่ละแบบควรอยู่ที่ไหน

ถามคำถามเดียว — “ใครต้องเห็นความรู้นี้ + มันเปลี่ยนบ่อยแค่ไหน” — แล้ววางตามนี้:

ความรู้แบบ	บ้าน (source of truth)	เดินทาง/แชร์?
preference ส่วนตัว/เครื่องนี้	agent memory	❌ local, ผูก path
team-durable (decisions, conventions, gotchas, สถานะ)	repo docs (CLAUDE.md/AGENTS.md, HANDOFF, PROGRESS)	✅ git
workflow ที่ทำซ้ำ	skill / command (1 อัน)	✅ reusable
กฎให้ agent ทำทุก session	instruction file ในเรพ	✅ git

เกณฑ์: ถ้าทั้งทีมต้องรู้ → repo · ถ้าเฉพาะเรา/เครื่องนี้ → memory · ถ้าเป็นขั้นตอนซ้ำ → skill

กฎ: “บ้านเดียว + pointer” (ห้าม copy)

พอรู้ว่าอะไรอยู่ที่ไหนแล้ว กติกากัน drift คือ:

ความรู้แต่ละชิ้นมี source of truth เดียว. ที่อื่นที่อยากอ้างถึง = ใส่ “pointer” (ลิงก์/ชื่อ) ชี้มา ไม่ใช่ copy เนื้อหาไปวาง

✅ pointer — ในไฟล์ memory (~/.claude/…/memory/blog-publishing.md) เขียนแค่บรรทัดเดียวชี้ไป skill:

การลงบทความ → ใช้ skill `publish-article` (ขั้นตอนเต็มอยู่ใน SKILL.md ของมัน)

ขั้นตอนจริงอยู่ ที่เดียว: ~/.claude/skills/publish-article/SKILL.md

❌ copy — เขียนขั้นตอนลงบทความ เต็มๆ ซ้ำ ลงไฟล์ memory ทั้งที่มันอยู่ใน SKILL.md แล้ว → วันหน้าขั้นตอนเปลี่ยน = ต้องแก้ 2 ไฟล์ (SKILL.md + memory) มักลืมอันนึง = ขัดกัน

⚠️ ข้อยกเว้นเดียวที่ copy ได้: “vendored copy” — copy ทั้งก้อนแบบ read-only + ระบุเวอร์ชัน + อัปเดตด้วยการ re-sync ทับทั้งก้อนเท่านั้น (คิดแบบ vendor dependency) เช่น sync ชุดกติกากลางขององค์กร เข้าโฟลเดอร์ standards/ ของ project → repo จบในตัว เพื่อนร่วมทีม/CI ไม่ต้องมี path เครื่องใคร · ตราบใดที่ไม่มีใครแก้สำเนา มันยังนับเป็น source เดียวอยู่ — บาปที่แท้จริงไม่ใช่การ copy แต่คือการ “แก้สำเนา” จนกลายเป็น source ที่สอง (แก้ที่ต้นทางแล้ว re-sync · diff ตอน sync = จุด review ฟรี)

ตัวอย่างจริง (จากการทำงานจริง)

• blog publishing playbook — เคยอยู่ทั้ง skill และ memory. ตัดสินให้ skill เป็น source of truth (self-contained) ส่วน memory เหลือแค่ pointer “ใช้ skill publish-article” → แก้ที่ skill ที่เดียว
• สถานะ merge ของโปรเจกต์ — เคยเขียน “รออนุมัติ merge” ลง PROGRESS/HANDOFF แล้วมันค้าง/ ผิดหลัง merge. ตัดสินให้ git เป็นเจ้าของ “merged รึยัง” ส่วน doc พูดแค่ fact ถาวร (“เฟสเสร็จ, gate เขียว”) → ไม่ต้อง sync กัน

จับสังเกต: source of truth ที่ดี = ที่ที่ความจริงถูกสร้าง/บังคับ — merge status ถูก git บังคับ → git เป็นเจ้าของ · workflow ถูกรันโดย skill → skill เป็นเจ้าของ

ถ้ามันซ้อนกันจริง อันไหนชนะ? (precedence)

บางทีความรู้ก็ layer กันหลายชั้น (global rules + project rules + memory + skill) — เครื่องมือมี ลำดับ ว่าอันไหน override อันไหน. หลักการทั่วไป:

ยิ่ง specific / local ยิ่ง override ของกว้างกว่า · และสิ่งที่ user พิมพ์สดในแชท ชนะไฟล์ทุกอัน

โมเดล layered (กว้าง → เฉพาะ, อันล่างทับอันบน):

enterprise / org policy       (บังคับ แก้ไม่ได้)
  └ user-global rules         (~/.claude/CLAUDE.md — ทุกโปรเจกต์ของคุณ)
     └ project rules          (./CLAUDE.md หรือ AGENTS.md — เฉพาะเรพนี้)
        └ subfolder rules     (rules เฉพาะโฟลเดอร์ย่อย)
           └ session / memory + สิ่งที่ user พิมพ์สด   ← เฉพาะสุด, ชนะ

🔷 Claude Code: ~/.claude/CLAUDE.md (global) + ./CLAUDE.md (project, เสริม/ทับ global) + memory + skill ที่ layer เข้ามาตอนถูกเรียก · 🌐 Copilot/Cursor/Codex/Antigravity มี hierarchy ของตัวเอง — order ไม่เหมือนกัน เช็ค docs ของเครื่องมือ

แต่จุดสำคัญ: ถ้าจัด placement ดี ก็แทบไม่ต้องพึ่ง precedence เลย — ความรู้แต่ละชิ้นมีบ้านเดียว (ไม่ copy ซ้ำ) → ไม่มีของขัดกันตั้งแต่แรก → ไม่ต้องมานั่งเถียงว่าอันไหนชนะ

วิธีจับ drift (audit สั้นๆ)

เป็นระยะถามตัวเอง:

1. ความรู้ชิ้นนี้เขียนไว้ กี่ที่? เกิน 1 ที่แบบ copy → เลือก 1 เป็น source of truth ที่เหลือทำ pointer
2. ที่ที่เหลือ ชี้ถูกไหม (ลิงก์ไม่ตาย / ชื่อ skill ยังอยู่)
3. transient state (สถานะชั่วคราว) ไปค้างในไฟล์ถาวรไหม → ย้ายให้ระบบที่บังคับมันเป็นเจ้าของ

สรุป

1. หลายที่เก็บความรู้ (memory / repo / skill / instruction file) → ความรู้ซ้ำ = drift
2. แผนที่: ส่วนตัว→memory · team-durable→repo · workflow ซ้ำ→skill · กฎ agent→instruction file
3. กติกา: ทุกชิ้นมี source of truth เดียว + pointer · copy ได้เฉพาะ vendored (read-only + re-sync — ห้ามแก้สำเนา)
4. source of truth ที่ดี = ที่ที่ความจริงถูกสร้าง/บังคับ (git คุม merge, skill คุม workflow)
5. ถ้าซ้อนกัน: ยิ่ง specific ยิ่งชนะ (in-chat ของ user ชนะไฟล์) — แต่จัด placement ดีก็แทบไม่ต้องพึ่ง

จัดบ้านความรู้ให้ agent ครั้งเดียว → เลิกเจอ “สองที่ขัดกัน” ไปตลอด 🚀

---

📚 บทความอื่นในซีรีส์ (see also): ระบบ handoff ที่ resume ได้ · memory ผูกกับ path · รัน agent ขนานด้วย worktree · codify workflow เป็น skill