AI ในทีมเรา อ่านความรู้ของกันเองไม่ออก
จนต้องมีไฟล์กลาง

เราใช้ AI หลายตัวทำงานเป็นทีม Claude เขียนโค้ด codex คอยรีวิว โมเดลเล็กที่รันในเครื่องไว้ตอบเร็วๆ แต่ละตัวสะสมสิ่งที่เรียนรู้ไว้ในแบบของตัวเอง อยู่มาวันหนึ่งเราอยากให้มันแชร์ความรู้กัน กลายเป็นว่าทำไม่ได้ ไม่ใช่เพราะไม่มีข้อมูล แต่เพราะรูปแบบที่ตัวหนึ่งเขียนไว้ อีกตัวกลับอ่านไม่ออก

ฟังดูเหมือนปัญหาเทคนิคเล็กๆ แต่จริงๆ นี่คือคำถามที่คนทำทีม AI ทุกคนต้องเจอ พอมี agent มากกว่าหนึ่งตัว ความรู้จะไปกองอยู่ตรงไหน แล้วทำยังไงให้ทุกตัวหยิบไปใช้ได้

ช่วงที่ 1ปัญหาไม่ได้อยู่ที่ "มีความรู้ไหม"

ความรู้ของ Claude เขียนในแบบเฉพาะตัว ลิงก์ข้ามไฟล์ด้วยวงเล็บก้ามปู ([[ชื่อไฟล์]]) หัวไฟล์ซ้อนหลายชั้น พวกนี้อ่านง่ายสำหรับ Claude เอง แต่พอส่งให้ codex หรือโมเดลในเครื่อง มันก็งงทันที เพราะรูปแบบพวกนี้ไม่ใช่มาตรฐานกลางที่ทุกตัวเข้าใจตรงกัน

ตรงนี้แหละที่ทำให้เห็นว่าปัญหาไม่ได้อยู่ที่ "มีความรู้ไหม" ทีมเรามีความรู้เต็มไปหมด แต่แชร์กันไม่ได้เพราะแต่ละตัวพูดคนละภาษา ความรู้ที่เปิดอ่านได้แค่ตัวเดียว ก็ไม่ต่างอะไรกับความรู้ที่ไม่มี

ช่วงที่ 2ไฟล์เดียว ไม่ใช่ฐานข้อมูล

พอรู้ว่าปัญหาคือรูปแบบ ทางแก้ก็ชัดขึ้น เราต้องการรูปแบบที่ทุกตัวอ่านตรงกัน ไม่ใช่ฐานข้อมูลก้อนใหญ่ที่ต้องเชื่อมต่อเข้าหา คำตอบคือ AGENTS.md ไฟล์ markdown ธรรมดาที่ AI ตัวไหนก็โหลดได้ตอนเริ่มงาน

AGENTS.md เป็นรูปแบบเปิดสำหรับบอกบริบทให้ coding agent ทำงานบนโปรเจกต์เรา เอกสารทางการของรูปแบบนี้นิยามไว้ว่าเป็น "README สำหรับ agent" คือที่ที่จัดไว้ให้รู้แน่ๆ ว่าจะวางคำสั่งและบริบทตรงไหน ต่างจาก README.md ที่เขียนให้คนอ่าน ตัวนี้เขียนให้ AI อ่าน เป็นไฟล์ markdown ล้วนๆ ไม่มี schema ตายตัว ตอนนี้มีโปรเจกต์ใช้แล้วกว่า 60,000 และเครื่องมืออย่าง Claude Code, Copilot, Cursor, Gemini CLI ก็อ่านไฟล์นี้เหมือนกันหมด

มองอีกมุม นี่คือสิ่งที่เรียกว่า context engineering การออกแบบว่าจะป้อนบริบทอะไรให้ AI ก่อนลงมือทำงาน ความรู้ที่ดีแต่ป้อนผิดที่ผิดเวลา AI ก็เอาไปใช้ไม่ได้อยู่ดี

ช่วงที่ 3สองที่ที่ความรู้เข้าถึง AI

พอลงมือวางจริง เราเจอว่าความรู้ไม่ได้มีที่อยู่เดียว มีอยู่สองที่ ต่างกันชัดเจน

ที่แรกคือ AGENTS.md อยู่ในโฟลเดอร์ของแต่ละโปรเจกต์ เป็นความรู้เฉพาะงานนั้น เป็นรูปแบบเปิดและข้าม engine ได้ ใครมาทำโปรเจกต์นี้ก็โหลดไฟล์เดียวกัน

ที่สองคือ SOUL.md ไฟล์ persona (ตัวบอกบุคลิกของ agent) ที่ฝังอยู่ในตัว agent ของเราเอง มันไม่ได้ผูกกับโปรเจกต์ไหน แต่อยู่ใน system prompt ที่ระบบ cache ไว้ แปลว่าติดไปทุกงานที่ agent ตัวนั้นทำ ไม่ว่าจะเปิดโปรเจกต์ไหน

สองที่นี้ไม่ได้แข่งกัน ทำคนละหน้าที่ต่างหาก ตารางข้างล่างเทียบให้เห็นว่าควรวางความรู้แบบไหนไว้ตรงไหน

ช่วงที่ 4สำหรับคนที่ใช้ Hermes

ส่วนนี้เจาะให้คนที่รัน Hermes โดยเฉพาะ (Hermes คือชุดเครื่องมือ agent ที่เราใช้รัน coder กับ reviewer ส่วนเรื่อง "Hermes คืออะไร ทำไมเราเลือก" เก็บไว้เล่ายาวอีกบทความ)

ข้อดีของ SOUL.md คือมันโหลดทุกงานแน่นอน เพราะอยู่ใน system prompt ที่ระบบ cache ไว้ ความรู้ที่อยากให้ติดตัว agent ไปทุกที่ วางตรงนี้เชื่อถือได้

แต่มีข้อจำกัดสามอย่างที่ต้องรู้ก่อนใช้ หนึ่ง เป็น persona ระดับ global ไม่ใช่ความรู้เฉพาะโปรเจกต์ สอง ค่า default คือ boilerplate (ค่าตั้งต้นกลางๆ) ถ้าไม่แก้ก็ไม่ได้ช่วยอะไร สาม และข้อนี้สำคัญสุด ต้อง verify ว่า code path ที่รันจริงโหลดไฟล์นี้ไหม

เรื่องข้อสามเราเจอกับตัว ตอนแรกเดาว่า swarm รันผ่าน batch_runner ที่ข้าม context ไป ความจริงรันผ่าน CLI ที่โหลด AGENTS.md, SOUL.md และ memory มาครบ ถ้าไม่ไล่ code path จริงให้เห็นกับตา เราก็จะวางความรู้ผิดที่ แล้วก็งงว่าทำไม agent ไม่รู้เรื่องที่เราอุตส่าห์เขียนไว้

ช่วงที่ 5เปิดรูปแบบ แต่วิธีคัดเป็นของเรา

มาถึงตรงนี้อาจสงสัยว่า ถ้าทุกอย่างเป็นรูปแบบเปิด แล้วอะไรคือของเราจริงๆ

รูปแบบกับที่วางไฟล์ เปิดหมด ใครก็ทำตามได้ แต่สิ่งที่เป็น design ของเราคือการเลือก ว่าความรู้ชิ้นไหนคู่ควรแชร์ ชิ้นไหนต้องตัดทิ้ง ชิ้นไหนให้น้ำหนักมากกว่า นี่คือ interface ที่ตายตัว แต่เครื่องยนต์ข้างในเปลี่ยนได้ ไม่ใช่การกั๊กความรู้ แต่เป็นการบอกว่าขอบเขตอยู่ตรงไหน

ช่วงที่ 6สรุปสั้น เอาไปใช้ได้เลย

ถ้าคุณใช้ AI หลายตัว หรือใช้ coding agent อยู่ เริ่มจากไฟล์กลางก่อน วาง AGENTS.md ไว้ในโปรเจกต์สำหรับความรู้ที่ portable ข้าม engine ได้ ถ้าใช้ Hermes ก็วาง SOUL.md สำหรับ persona ที่อยากให้ติดทุกงาน แต่ก่อนจะลงแรงเขียน เช็คให้ชัดก่อนว่า engine ที่รันอยู่โหลดไฟล์ไหนจริง แล้วค่อยลงแรงไปที่ส่วนที่ยากที่สุดและเป็นของเราจริงๆ นั่นคือการคัดและการตัด

เขียนจากงานจริง ไม่ใช่ทฤษฎี งานวางความรู้ให้ AI fleet ของเราเองจริง