SOUL.md: ไฟล์เล็กที่ทำให้ AI Agent ไม่ใช่แค่ chatbot รอคำสั่ง

AI Agent ที่ดี ไม่ได้เริ่มจาก prompt ที่ยาวที่สุดครับ

มันเริ่มจากคำถามที่ฟังดูธรรมดากว่านั้นมาก

เราต้องการให้ AI ตัวนี้เป็นคนแบบไหนในระบบงานของเรา

นี่คือเหตุผลที่โพสต์ Reddit เรื่อง SOUL.md สำหรับ Hermes Agent น่าสนใจมากสำหรับผม

ไม่ใช่เพราะมันเป็น template ยาว ๆ ให้ copy paste

แต่เพราะมันชี้ให้เห็นว่า ถ้าเราอยากให้ AI Agent ทำงานเหมือน operator จริง เราต้องออกแบบ identity, stance, mission, autonomy และ proof loop ให้มันตั้งแต่ต้น

พูดง่าย ๆ คือ AI ไม่ควรรอคำสั่งอย่างเดียว

แต่มันก็ไม่ควรวิ่งเองแบบไม่มีเบรกเหมือนกัน

1) เกิดอะไรขึ้น

Arty ส่งโพสต์ Reddit จาก r/AIAgentsInAction หัวข้อ “The SOUL.md Template Behind My Hermes Agent” มาให้ดู

ในโพสต์นั้น ผู้เขียนบอกว่าเขาเคยพูดถึงไฟล์ SOUL.md ส่วนตัวที่ใช้กับ Hermes Agent แต่ไฟล์จริงมีข้อมูลส่วนตัวเยอะ เช่น ชื่อโปรเจกต์ path เฉพาะเครื่อง habit การใช้ tool และกติกา autonomy เฉพาะ workflow ของเขา

เขาเลยแชร์เวอร์ชัน sanitized template แทน

แก่นของโพสต์คือประโยคนี้ครับ:

“The generic version gets you a generic operator.”

แปลแบบ Data-Espresso คือ ถ้าเราให้ instruction กว้าง ๆ แบบ “ช่วยทำงานให้ดีนะ” เราก็จะได้ AI ที่ทำงานแบบกลาง ๆ รอคำสั่งกลาง ๆ และ push งานได้กลาง ๆ

แต่ถ้าเราอยากได้ AI coworker ที่มีวิธีคิด มีขอบเขต และรู้ว่าควรผลักงานอย่างไร เราต้องออกแบบ “ตัวตนการทำงาน” ให้มัน

Official Hermes docs ก็ยืนยันแนวคิดนี้ในเชิงระบบครับ

SOUL.md คือ primary identity file ของ Hermes instance อยู่ใน ~/.hermes/SOUL.md หรือ $HERMES_HOME/SOUL.md และถูกใส่เป็น slot แรกของ system prompt หลังผ่านการ scan และ truncation

แปลว่าไฟล์นี้ไม่ใช่แค่ note ประกอบ

มันคือฐานเสียง ฐานบุคลิก และฐานวิธีตอบของ Hermes ใน session ใหม่ ๆ

2) SOUL.md ไม่ใช่ prompt ยาว ๆ

หลายคนพอเห็นไฟล์แบบนี้จะคิดทันทีว่า “อ๋อ นี่คือ system prompt อีกแบบหนึ่ง”

ใช่ครับ แต่มันไม่ควรถูกใช้แบบ system prompt ที่เอาทุกอย่างยัดลงไป

Official docs ของ Hermes แยกชัดมาก:

• SOUL.md ใช้กับ identity, tone, style, default behavior, how to handle uncertainty, disagreement, ambiguity
• AGENTS.md ใช้กับ project rules, repo conventions, commands, ports, paths, deployment notes
• skills ใช้กับ reusable workflow หรือ playbook ที่ agent โหลดเวลาต้องทำงานเฉพาะทาง
• memory ใช้กับ facts ที่ต้องจำข้าม session

ถ้าเปรียบง่าย ๆ:

SOUL.md คือ “นิสัยและหลักการทำงาน” ของคนคนหนึ่ง

AGENTS.md คือ “กฎของออฟฟิศนี้”

skill คือ “คู่มือทำงานซ้ำ”

memory คือ “สิ่งที่ควรจำเกี่ยวกับเจ้านาย งาน และสภาพแวดล้อม”

ถ้าเราเอา project path, command, temporary decision, server detail ไปยัดใน SOUL.md หมด วันหนึ่ง AI จะกลายเป็นคนที่พกกฎของทุกออฟฟิศติดตัวไปทุกที่

ฟังดูขยัน แต่จริง ๆ อันตรายครับ

3) สามส่วนที่ทำให้ AI ไม่ใช่แค่ chatbot

ในโพสต์ Reddit ผู้เขียนบอกว่าสามส่วนที่สำคัญที่สุดคือ Stance, Autonomy และ Mission

ผมเห็นด้วยค่อนข้างมาก

Stance: AI ควรยืนแบบไหน

Stance คือวิธีคิดและน้ำเสียงของ agent

เช่น:

• ตรงไปตรงมาแค่ไหน
• push back ได้ไหม
• เน้น proof หรือเน้นความสุภาพ
• แยก fact, assumption, opinion หรือไม่
• ถ้างานคลุมเครือจะถามก่อน หรือเลือก default แล้วเดินต่อ

สำหรับธุรกิจไทย ผมว่า stance สำคัญมาก เพราะเรามักเจอ AI ที่สุภาพมาก แต่ไม่ช่วยตัดสินใจ

ตอบยาว ดูดี แต่ไม่ชี้ว่าต้องทำอะไรต่อ

AI แบบนั้นเหมาะกับการอ่านเล่น แต่ไม่เหมาะกับงาน operator

Autonomy: AI ทำเองได้แค่ไหน

Autonomy คือขอบเขตการตัดสินใจ

นี่ไม่ใช่การบอกให้ AI ทำอะไรก็ได้ครับ

ตรงกันข้าม มันคือการกำหนดว่าอะไรทำได้เอง อะไรต้องถาม และอะไรห้ามทำเด็ดขาด

ตัวอย่างที่ควรเขียนให้ชัด:

• แก้ไฟล์ใน repo ได้ไหม
• run test เองได้ไหม
• commit ได้ไหม
• ส่งข้อความหาลูกค้าได้ไหม
• publish content ได้ไหม
• ลบข้อมูลได้ไหม
• เปลี่ยน credential หรือ permission ได้ไหม

สำหรับผม เส้นแบ่งง่าย ๆ คือ งานภายในที่ reversible ให้ AI เดินได้มากขึ้น

แต่งานที่ออกสู่โลกจริง เช่น public post, email, payment, credential, permission, destructive change ต้องขออนุมัติ

ไม่ใช่เพราะไม่ไว้ใจ AI

แต่เพราะ blast radius ของงานแต่ละชนิดไม่เท่ากัน

Mission: AI เกิดมาเพื่อผลักอะไร

Mission คือคำตอบว่า agent ตัวนี้มีหน้าที่ผลักงานอะไรให้เดิน

ถ้า mission ไม่ชัด AI จะกลายเป็นผู้ช่วยทั่วไป

ถามอะไรก็ตอบ ทำอะไรก็ได้ แต่ไม่มีแรงดันไปสู่ผลลัพธ์ที่สำคัญ

ตัวอย่าง mission ที่ใช้งานได้:

• ปกป้อง attention ของ founder
• ลดงานซ้ำที่กินเวลาทุกวัน
• ทำให้ content pipeline มี draft, proof, cover, queue โดยไม่หลุดขั้น
• ทำให้ลูกค้าได้รับคำตอบเร็วขึ้น แต่ยังมี human approval ในเคสเสี่ยง
• ตรวจงาน software ให้จบด้วย test และ evidence ไม่ใช่คำว่า “น่าจะได้แล้ว”

Mission ที่ดีทำให้ agent รู้ว่าอะไรควรหยิบขึ้นมาทำก่อน

4) ทำไมเรื่องนี้สำคัญกับ SME และ One Person Business

ถ้าเป็นบริษัทใหญ่ อาจมีทีม IT, legal, data governance, security, workflow owner และ analyst หลายคนช่วยกันออกแบบระบบ AI

แต่ SME หรือ One Person Business ไม่มี luxury แบบนั้นครับ

เจ้าของมักเป็นคนเดียวที่รู้ทุกอย่าง:

• ลูกค้าคนไหนสำคัญ
• งานไหนเร่งจริง
• ข้อมูลไหนห้ามหลุด
• ข้อความแบบไหนไม่ควรส่ง
• คำตอบแบบไหนถือว่า “ใช้ได้”
• งานไหนควรหยุดแล้วถามคน

ถ้าเราไม่ถอดสิ่งเหล่านี้ออกมาเป็น operating rules ให้ AI มันก็จะเดาจาก prompt ล่าสุด

บางวันเดาถูก

บางวันเดาผิด

บางวันดูมั่นใจมากทั้งที่หลุด context

SOUL.md เลยเป็นเหมือนจุดเริ่มของการทำ “AI coworker onboarding”

เหมือนเรารับคนใหม่เข้าทีม แล้วไม่ได้แค่บอกว่า “ช่วยตอบลูกค้าหน่อย”

แต่บอกด้วยว่า:

• บริษัทเราให้คุณค่ากับอะไร
• ถ้าไม่แน่ใจให้ทำอย่างไร
• เรื่องไหนต้อง escalation
• งานจบต้องมีหลักฐานแบบไหน
• ห้ามทำอะไรแม้ดูสะดวก

นี่คือจุดที่ AI เริ่มเปลี่ยนจากเครื่องตอบคำถามเป็นเพื่อนร่วมงานที่พอจะอยู่ในระบบได้

5) Framework: เขียน SOUL.md แบบใช้งานจริง

ถ้าให้ผมแนะนำแบบ practical ผมจะเริ่มจาก 6 บล็อกนี้ครับ

1. Identity

บอกว่า agent เป็นใครในระบบงานนี้

ไม่ต้องหล่อมาก ไม่ต้องเว่อร์

เช่น:

You are my operator partner for daily business execution. Your job is to reduce repeated briefing, protect my attention, and turn clear intent into verified output.

จุดสำคัญคือ agent ต้องรู้ว่าตัวเองไม่ใช่แค่ answer bot

2. Stance

บอกน้ำเสียงและวิธีคิด

เช่น:

Be direct, practical, proof first, and concise. Separate facts, assumptions, opinions, and open questions. Push back when the plan is weak, but always give a better alternative.

อันนี้ช่วยลด AI ที่เอาแต่เห็นด้วย

3. Mission

บอกผลลัพธ์หลักที่ต้องผลัก

เช่น:

Move important work from vague idea to concrete artifact, verified output, or clear blocker.

คำว่า blocker สำคัญ เพราะงานบางอย่างไม่ควรฝืนให้ดูเสร็จ

ถ้าติดจริง ต้องบอกว่าติดอะไรและต้องการอะไรต่อ

4. Autonomy boundary

บอกอะไรทำเองได้ อะไรต้องถาม

ตัวอย่าง:

• อ่านไฟล์ ค้นข้อมูล วิเคราะห์ วางแผน ร่างเอกสาร run test ทำได้เอง
• ส่งข้อความ publish ซื้อของ เปลี่ยน permission ลบข้อมูล ใช้ credential ต้องขออนุมัติ

กติกานี้ทำให้ agent ไม่เป็นทั้งเด็กฝึกงานที่ถามทุก 5 นาที และไม่เป็น intern บ้าพลังที่กด production เอง

5. Proof loop

บอกว่า “งานเสร็จ” ต้องมีอะไร

เช่น:

• link
• screenshot
• test output
• commit SHA
• diff
• issue number
• live page check
• source list

สำหรับงาน AI ในธุรกิจ ผมชอบกติกานี้มาก:

Do not report done without proof.

สั้น แต่เปลี่ยน behavior ได้เยอะ

6. Memory hygiene

บอกว่าอะไรควรจำ อะไรไม่ควรจำ

เช่น:

• จำ preference ที่ใช้ซ้ำ
• จำ environment convention
• จำ workflow ที่แก้ปัญหาซ้ำได้
• ไม่จำ task progress ชั่วคราว
• ไม่จำ secret
• ไม่เอา project detail เฉพาะทางไปปนกับ identity

ถ้าไม่เขียนไว้ memory จะค่อย ๆ กลายเป็นถังรวมทุกอย่าง

6) ตัวอย่างแบบสั้นสำหรับเจ้าของธุรกิจ

ลองดู template แบบสั้นที่เอาไปปรับได้ครับ

# Identity
You are my AI operator partner.
Your job is to protect my attention, reduce repeated work, and turn intent into verified execution.

# Stance
Be direct, practical, concise, and proof first.
Separate fact, assumption, opinion, and open question.
Push back when my plan is weak, unclear, risky, or not worth doing.
When you push back, explain the evidence and propose a better path.

# Mission
Move important work forward.
Do not create artifacts for the graveyard.
End with one of these states: done, verified, blocked, or needs approval.

# Autonomy
Act without asking for low-risk internal work: reading, researching, drafting, organizing, testing, summarizing, and preparing options.
Ask before external or irreversible actions: public posts, real messages, purchases, destructive changes, credentials, permissions, or customer data exposure.

# Proof
Do not say done without proof.
Use links, screenshots, test output, file paths, commit SHA, issue numbers, or source lists.

# Memory
Remember durable preferences and reusable lessons.
Do not remember secrets, temporary task progress, or stale one-off details.

ต้องใช้ภาษาอังกฤษไหม?

ไม่จำเป็นครับ

แต่ถ้าใช้กับโมเดลหลายตัว ภาษาอังกฤษอาจลดความคลาดเคลื่อนในคำสั่ง technical ได้บ้าง

สำหรับทีมไทย ผมมักใช้ Thai-English mix แบบที่คนทำงานจริงเข้าใจ

7) สิ่งที่ไม่ควรทำ

SOUL.md มีพลัง แต่ถ้าใช้ผิดจะทำให้ agent เละได้เหมือนกัน

อย่าใส่ข้อมูลลับ

ห้ามใส่ API key, password, token, customer data, internal URL ที่ไม่ควรเผยแพร่ หรือรายละเอียดลูกค้า

นี่ไม่ใช่ที่เก็บ secret

อย่าใส่ project detail ที่เปลี่ยนบ่อย

เช่น port, branch, path, deploy command, issue number, task state

พวกนี้ควรอยู่ใน project docs, AGENTS.md, skill, หรือ issue tracker

อย่าเขียนกติกาขัดกันเอง

เช่น “ถามก่อนทำทุกอย่าง” แต่ก็ “อย่าถามให้เสียเวลา”

agent จะได้บุคลิกสับสน

อย่าทำให้มันกลายเป็นเทพไร้เบรก

คำว่า autonomy ไม่ได้แปลว่าให้ AI ทำทุกอย่างเอง

AI ที่ใช้จริงต้องมีทั้งคันเร่งและเบรก

8) ถ้ามองในมุม Data-Espresso

ผมมองว่า SOUL.md เป็นหนึ่งในชั้นแรกของ AI coworker stack

ไม่ใช่ technical feature ที่เอาไว้โชว์

แต่เป็นสิ่งที่ตอบคำถามว่า “AI คนนี้ควรทำงานกับเราอย่างไร”

ถ้าธุรกิจอยากใช้ AI เพื่อลดต้นทุน เพิ่มยอดขาย หรือทำงานมากขึ้นโดยไม่เพิ่มคนทุกครั้ง เราต้องหยุดคิดว่า AI คือช่องแชตที่รอ prompt

เราต้องเริ่มคิดว่า AI คือคนทำงานดิจิทัลที่ต้อง onboarding

และ onboarding ที่ดีไม่ได้มีแค่ task list

มันมีนิสัย วิธีคิด ขอบเขต escalation และ definition of done

SOUL.md คือจุดเริ่มที่ดีของเรื่องนั้นครับ

สรุป

ในความเห็นของผม เรื่องนี้ให้ 9/10 สำหรับคนที่กำลังสร้าง AI coworker จริงจัง

ไม่ใช่เพราะ template นี้สมบูรณ์แบบ หรือทุกคนควร copy ทั้งไฟล์

แต่เพราะมันเตือนเราว่า AI Agent ที่ดีไม่ได้เกิดจาก prompt เดียวยาว ๆ

มันเกิดจากระบบเล็ก ๆ ที่บอกว่า agent เป็นใคร คิดแบบไหน ตัดสินใจได้แค่ไหน ห้ามทำอะไร และต้องมี proof อะไรก่อนบอกว่างานจบ

สุดท้าย AI ที่ธุรกิจใช้ได้จริง ไม่ใช่ตัวที่ตอบได้ทุกเรื่องครับ

แต่คือตัวที่รู้ว่าเมื่อไหร่ควรทำเอง เมื่อไหร่ควรถาม และเมื่อไหร่ต้องหยุด