Hermes Agent คืออะไร? วิธีสร้าง Subagent และ Multi-agent พร้อมเปรียบเทียบ ChatGPT Work, Codex และ Claude Code

ลองนึกภาพว่าเรามีผู้ช่วย AI เพียงคนเดียว แล้วมอบงานให้เขาทั้งหมดในคราวเดียว: อ่านเอกสาร 20 ฉบับ ค้นข้อมูลล่าสุด เขียนโค้ด สร้างตาราง ตรวจความปลอดภัย และสรุปทุกอย่างเป็นรายงาน ผู้ช่วยคนนั้นอาจทำได้หลายอย่าง แต่ระหว่างทางบริบทจะเริ่มปะปน รายละเอียดจากงานหนึ่งไหลไปอีกงานหนึ่ง และพื้นที่ความจำที่ใช้คิดก็ถูกผลลัพธ์จากเครื่องมือกินไปเรื่อย ๆ

ปัญหานี้ไม่ได้แปลว่าโมเดลไม่เก่งพอเสมอไป บางครั้งปัญหาอยู่ที่เราออกแบบงานเหมือนให้คนหนึ่งคนเปิดหน้าต่าง 40 บาน แล้วสลับไปมาจนจำไม่ได้ว่ากำลังตรวจอะไรอยู่ หากงานแยกออกจากกันได้ การให้ผู้ช่วยหลายตัวรับผิดชอบคนละส่วนอาจช่วยให้ Context สะอาดขึ้น ทำงานพร้อมกันได้ และมีคนอีกตัวตรวจผลก่อนส่งมอบ

นี่คือพื้นที่ที่ Hermes Agent น่าสนใจ มันไม่ใช่เพียงโมเดลภาษาอีกตัวหนึ่ง แต่เป็นระบบ Agent ของ Nous Research ที่เชื่อมโมเดลเข้ากับเครื่องมือ ไฟล์ Terminal เว็บ Memory, Skills, MCP และการมอบหมายงานให้ Subagent ได้ ผู้ใช้เลือกได้ว่าจะให้โมเดลใดเป็นสมอง ให้เครื่องมือใดเป็นมือ และให้ระบบทำงานอยู่บนเครื่อง Local, Container, Remote Server หรือผู้ให้บริการอื่นตามการตั้งค่า

คำตอบสั้นที่สุดคือ: Hermes Agent เหมาะกับคนที่อยากควบคุม Agent Runtime และ Workflow เอง ตั้งแต่โมเดล Endpoint เครื่องมือ สิทธิ์ ไปจนถึงรูปแบบการแบ่งงาน ส่วน ChatGPT Work เหมาะกับคนที่อยากให้งานหลายขั้นตอนกลายเป็น Deliverable โดยไม่ต้องออกแบบระบบ Agent เอง ขณะที่ Codex และ Claude Code ถูกออกแบบมาสำหรับงานพัฒนาซอฟต์แวร์โดยตรง แม้ปัจจุบันทั้งสองจะทำงานหลายขั้นตอนและมีความสามารถด้าน Agent มากกว่าคำว่า “ผู้ช่วยเขียนโค้ด” มากแล้วก็ตาม

แต่ Multi-agent ไม่ได้ดีกว่า Agent ตัวเดียวโดยอัตโนมัติ ทุก Agent ที่เพิ่มเข้ามาคือ Model Call, Context, Tool Call, เวลา ความเสี่ยง และงานรวมผลที่เพิ่มขึ้น หลักที่ควรจำจึงไม่ใช่ “ใช้ Agent ให้มากที่สุด” แต่คือ เริ่มจาก Agent ตัวเดียว แล้วเพิ่ม Subagent เฉพาะเมื่อการแยกงานสร้างประโยชน์ที่ตรวจสอบได้

Hermes Agent คืออะไร

ก่อนตอบว่า Hermes Agent ทำอะไรได้ เราต้องแยกชื่อที่คล้ายกันสองอย่างออกจากกันก่อน

Hermes Model คือโมเดลภาษาตระกูลหนึ่งของ Nous Research เปรียบได้กับ “สมอง” ที่รับข้อความและสร้างคำตอบ ส่วน Hermes Agent คือระบบที่นำโมเดลมาอยู่ในวงจรทำงานจริง มีเครื่องมือ มีพื้นที่เก็บบริบท มีวิธีเรียก Terminal อ่านและแก้ไฟล์ ค้นเว็บ ใช้ MCP เก็บ Memory เรียก Skill และมอบหมายงานให้ Agent ลูก

ภาพจำที่ง่ายคือ รถยนต์หนึ่งคันมีทั้งเครื่องยนต์ พวงมาลัย เบรก เซนเซอร์ และกติกาการควบคุม เครื่องยนต์อย่างเดียวทำให้รถเคลื่อนที่ไม่ได้อย่างปลอดภัย เช่นเดียวกัน โมเดลภาษาอย่างเดียวสร้างข้อความได้ แต่ Agent Runtime เป็นส่วนที่กำหนดว่าโมเดลเห็นเครื่องมืออะไร เรียกเครื่องมืออย่างไร รับผลกลับมาอย่างไร ต้องขออนุมัติเมื่อใด และจะหยุดเมื่อใด

ตามเอกสารทางการ Hermes Agent รองรับความสามารถหลายกลุ่ม ได้แก่เครื่องมือสำหรับเว็บ ไฟล์ Terminal และ Browser, Memory ที่เก็บข้าม Session, Skills แบบโหลดตามความจำเป็น, MCP สำหรับเชื่อมเครื่องมือภายนอก, งานตามเวลา และการมอบหมายงานให้ Subagent ระบบสามารถใช้ Nous Portal, OpenRouter, OpenAI หรือ Custom Endpoint ที่เข้ากันได้ตามการตั้งค่า และมีตัวเลือกสภาพแวดล้อมการรันคำสั่งหลายแบบ เช่น Local, Docker และ SSH

คำว่า “รองรับหลายโมเดล” ต้องตีความให้ถูกด้วย การต่อ Endpoint ได้ไม่ได้หมายความว่าโมเดลทุกตัวจะเป็น Agent ที่ดีเท่ากัน โมเดลต้องเรียก Tool ได้ถูกต้อง รักษารูปแบบ Argument ได้ อ่านผลเครื่องมือยาว ๆ ได้ และมี Context Window เพียงพอ เอกสารผู้ให้บริการของ Hermes ระบุความต้องการ Context สำหรับการใช้งาน Agent พร้อม Tool ไว้สูง จึงไม่ควรนำ Local Model ขนาดเล็กที่ตั้ง Context ต่ำมาใช้แล้วสรุปว่า Hermes ใช้งานไม่ได้ ความล้มเหลวอาจมาจากโมเดล Runtime, Context หรือ Tool Calling มากกว่าตัว Framework

อินพุตผ่านอะไรไปเป็นผลลัพธ์

วงจรพื้นฐานของ Agent อธิบายได้ดังนี้

เป้าหมายของผู้ใช้
      ↓
โมเดลวิเคราะห์สถานะปัจจุบัน
      ↓
เลือกตอบหรือเรียกเครื่องมือ
      ↓
Runtime ตรวจสิทธิ์และรันเครื่องมือ
      ↓
ผลจากเครื่องมือกลับเข้า Context
      ↓
โมเดลประเมินว่าจะทำต่อ แก้ทาง หรือสรุปผล
      ↓
Artifact + หลักฐาน + สถานะงาน

จุดสำคัญคือ Agent ไม่ได้ “คิดแล้วทำทุกอย่างรวดเดียว” แต่วนเป็นรอบ เป้าหมายแต่ละรอบคือเลือกการกระทำถัดไปที่ช่วยให้งานเข้าใกล้เงื่อนไขสำเร็จ หากไม่มีเกณฑ์สำเร็จ Agent อาจหยุดเร็วเกินไป หรือวนแก้สิ่งเดิมโดยไม่รู้ว่าควรหยุดเมื่อใด

ดังนั้น Prompt ที่ดีสำหรับ Agent ต้องมีมากกว่าคำสั่งว่า “ทำรายงานเรื่องนี้” ควรบอกผลลัพธ์ปลายทาง แหล่งที่ใช้ได้ ขอบเขตไฟล์ สิ่งที่ห้ามทำ วิธีตรวจ และจุดที่ต้องให้มนุษย์อนุมัติ ยิ่ง Agent มี Tool ที่เปลี่ยนแปลงโลกภายนอกได้ เช่นส่งข้อความ ลบไฟล์ หรือแก้ฐานข้อมูล ความชัดเจนเหล่านี้ยิ่งสำคัญ

ติดตั้ง Hermes บน Windows

ส่วนนี้อ้างอิงหน้า Installation ทางการของ Hermes Agent และผลติดตั้งจริงบน Windows 11 เมื่อ 4 สิงหาคม 2026 เครื่องทดสอบมี Python 3.11.9, Git 2.53.0, Node.js 24.15.0 และ npm 11.12.1 ก่อนเริ่ม ผู้พัฒนาแนะนำให้ผู้ใช้ Windows หรือ macOS เริ่มจาก Hermes Desktop Installer เพราะติดตั้งทั้งแอป Desktop และคำสั่ง hermes ให้ในกระบวนการเดียว ส่วนการทดลองครั้งนี้ใช้ PowerShell Installer ทางการพร้อมตัวเลือกสร้าง Desktop เพื่อให้เก็บ Log ของแต่ละ Stage ได้ครบ

ก่อนเริ่ม ให้แยกสองเรื่องออกจากกัน การติดตั้งโปรแกรมคือการนำ Agent Runtime มาไว้บนเครื่อง ส่วนการเลือกผู้ให้บริการโมเดลคือการกำหนดว่าสมองของ Agent จะมาจากที่ใด ติดตั้งเสร็จไม่ได้หมายความว่าจะเริ่มทำงานได้ทันที หากยังไม่ได้ตั้ง Model Provider หรือ Custom Endpoint

ขอบเขตการทดลองจริง

• ดาวน์โหลด install.ps1 จากโดเมนทางการและบันทึก SHA-256 ของไฟล์ที่ใช้
• รันแบบผู้ใช้ปัจจุบัน ไม่ติดตั้งด้วยสิทธิ์ Administrator
• ใช้ -SkipSetup -NonInteractive -IncludeDesktop เพื่อไม่ให้บัญชีหรือ API Key ปรากฏใน Log
• ตรวจ Repository, Virtual Environment, Python dependencies, Desktop build, Shortcut และหน้า First Launch
• ไม่เชื่อม Model Provider และไม่ยอมรับ Host Key หรือ Permission ที่ไม่เกี่ยวกับการติดตั้ง

ภาพที่ 1 Log Snapshot จากการติดตั้งจริงบนเครื่อง Windows แสดง Stage พื้นฐานที่ผ่าน ภาพนี้เรนเดอร์จาก Log จริงโดยตัด Path ส่วนตัวและข้อมูล Host ออก

ทางเลือก A ติดตั้งด้วย Hermes Desktop Installer

นี่เป็นเส้นทางที่เหมาะกับผู้เริ่มต้นและเป็นวิธีที่เอกสารทางการแนะนำ

1. เปิดหน้า Hermes Agent จาก Browser
2. เลือก Download สำหรับ Windows
3. ตรวจว่าไฟล์ดาวน์โหลดมาจากโดเมน hermes-agent.nousresearch.com อย่าใช้ไฟล์ติดตั้งที่ส่งต่อมาจากแหล่งอื่น
4. ก่อนเปิดไฟล์ ให้ตรวจชื่อ Publisher ที่ Windows แสดง หาก Publisher หรือแหล่งดาวน์โหลดไม่ตรงกับข้อมูลทางการ ให้หยุด
5. เปิด Installer และทำตามหน้าจอจนจบ
6. เมื่อ Windows ขอสิทธิ์ติดตั้ง ให้อ่านชื่อโปรแกรมและขอบเขตสิทธิ์ก่อนกดยืนยัน
7. ปิดแล้วเปิด PowerShell ใหม่ เพื่อให้ระบบเห็นคำสั่งที่เพิ่งติดตั้ง
8. รัน hermes --help เพื่อตรวจว่าคำสั่งใช้งานได้
9. รัน hermes model หรือ hermes setup เพื่อตั้งค่า Model Provider
10. ทดลองแชตด้วยโจทย์ที่ไม่แตะข้อมูลส่วนตัวก่อนเปิด File, Terminal หรือ MCP เพิ่มเติม

ภาพที่ 2 หน้า Quick Install ทางการระบุว่า Desktop Installer เป็นวิธีแนะนำสำหรับ Windows และแสดงคำสั่ง PowerShell สำหรับแบบ Command Line — Source: Hermes Agent Documentation, 4 สิงหาคม 2026

ทางเลือก B ติดตั้งเฉพาะ Command Line ด้วย PowerShell

เอกสารทางการแสดงคำสั่งสั้นดังนี้

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

คำสั่งนี้ดาวน์โหลดสคริปต์จากอินเทอร์เน็ตแล้วรันทันที จึงสะดวกแต่ทำให้ผู้ใช้ไม่มีช่วงตรวจเนื้อหาสคริปต์ก่อนทำงาน สำหรับเครื่องส่วนตัวที่มีข้อมูลสำคัญ วิธีที่รอบคอบกว่าคือดาวน์โหลดสคริปต์มาเก็บในไฟล์ชั่วคราว ตรวจแหล่งที่มาและเนื้อหาก่อน แล้วจึงรันด้วยตนเอง

ตัวอย่างขั้นตอนตรวจสอบ:

$installerPath = Join-Path $env:TEMP 'hermes-install.ps1'
Invoke-WebRequest `
  -Uri 'https://hermes-agent.nousresearch.com/install.ps1' `
  -OutFile $installerPath

Get-Item -LiteralPath $installerPath
Get-FileHash -Algorithm SHA256 -LiteralPath $installerPath
notepad $installerPath

การดูค่า SHA-256 ช่วยบันทึกว่าสคริปต์ที่เราใช้เป็นไฟล์ใด แต่ค่า Hash จะยืนยันความถูกต้องได้ก็ต่อเมื่อผู้พัฒนาเผยแพร่ค่าอ้างอิงจากช่องทางที่เชื่อถือได้ หากไม่มีค่าอ้างอิง ให้ใช้ Hash เป็นบันทึกการติดตั้ง ไม่ใช่หลักฐานว่าไฟล์ปลอดภัย

หลังอ่านสคริปต์และยืนยันว่า URL เป็นโดเมนทางการแล้ว จึงเปิด PowerShell ปกติและรันไฟล์นั้น:

powershell -ExecutionPolicy Bypass -File $installerPath

อย่าใช้สิทธิ์ Administrator โดยอัตโนมัติ ให้ยกระดับสิทธิ์เฉพาะเมื่อเอกสารหรือ Installer รุ่นนั้นอธิบายความจำเป็นชัดเจน การใช้สิทธิ์เท่าที่จำเป็นช่วยลดผลกระทบหาก Dependency หรือ Script มีปัญหา

Failure Case ที่พบจริง: npm อยู่ในช่วงที่ Hermes ไม่รองรับ

การติดตั้งครั้งแรกผ่านขั้น uv, Python, Git, Repository, Virtual Environment และ Python dependencies แต่ Desktop build หยุดด้วย EBADENGINE เพราะเครื่องมี npm 11.12.1 ขณะที่ package.json ของ Hermes รุ่นที่ทดสอบกำหนดให้ใช้ npm ต่ำกว่า 11.10 หรืออย่างน้อย 11.17

นี่เป็นตัวอย่างว่าคำว่า “Installer จัดการ Dependency ให้อัตโนมัติ” ไม่ได้หมายความว่าจะไม่มี Version Conflict เมื่อเครื่องมี Node/npm ติดตั้งอยู่ก่อน สิ่งสำคัญคืออ่านบรรทัด Required กับ Actual ก่อนแก้ ไม่ควรลบ Environment หรืออัปเกรด npm ส่วนกลางแบบเดาสุ่ม

ภาพที่ 3 Desktop build หยุดเพราะ npm Engine ไม่ตรงเงื่อนไข ภาพนี้เป็น Log Snapshot จาก Error จริง ไม่ใช่ Error จำลอง

ทางแก้ที่ใช้ในการทดลองคือวาง npm 11.17 ไว้ใต้โฟลเดอร์ Hermes เพื่อไม่เปลี่ยน npm ส่วนกลาง แล้วรัน Desktop Stage ซ้ำ ในสภาพแวดล้อมนี้ Stage ภายในยังตรวจพบ npm 11.12.1 จึงปิด engine-strict เฉพาะ Process ของรอบ Build โดยไม่แก้ .npmrc และไม่เปลี่ยน Global npm จากนั้นตรวจ Build Output และไฟล์ Hermes.exe จริงก่อนยอมรับผล

วิธีนี้เป็น Recovery ของสภาพแวดล้อมทดสอบ ไม่ใช่คำแนะนำทั่วไป หากเครื่องของผู้อ่านใช้ npm ที่อยู่ในช่วงรองรับอยู่แล้ว ห้ามเพิ่มขั้นตอนนี้โดยไม่จำเป็น และหาก Build ล้มด้วยสาเหตุอื่น ต้องแก้ตาม Error นั้นแทน

ภาพที่ 4 หลัง Recovery, Installer สร้าง Desktop app และ Shortcut สำเร็จ พร้อมตำแหน่ง Hermes.exe ที่ตรวจได้จริง

Installer เตรียมอะไรให้บ้าง

เอกสาร Installation ระบุว่า Installer จัดการ Dependency หลักให้ รวมถึง Python ผ่าน uv, Node.js, ripgrep และ ffmpeg ผู้ใช้จึงไม่จำเป็นต้องติดตั้งเครื่องมือเหล่านี้แยกก่อนตามค่าเริ่มต้น แต่ควรมี Git และตรวจความพร้อมด้วยคำสั่ง:

git --version

ถ้าคำสั่งนี้หา Git ไม่พบ ให้ติดตั้ง Git จากแหล่งทางการก่อน แล้วเปิด PowerShell ใหม่ การมี Git สำคัญเพราะกระบวนการติดตั้งและการอัปเดตบางแบบต้องเข้าถึง Repository

ภาพที่ 5 เอกสารระบุ Dependency ที่ Installer จัดเตรียม เช่น Python 3.11, Node.js, ripgrep และ ffmpeg โดยผู้ใช้ควรตรวจว่า Git พร้อมใช้งาน — Source: Hermes Agent Documentation, 4 สิงหาคม 2026

ตรวจว่าติดตั้งสำเร็จหรือไม่

ปิดหน้าต่าง PowerShell เดิม เปิดหน้าต่างใหม่ แล้วตรวจตามลำดับนี้

Get-Command hermes
hermes --help
hermes model

Get-Command hermes ควรแสดงตำแหน่งคำสั่ง hermes ส่วน hermes --help ควรแสดงรายการคำสั่งโดยไม่เกิด Error ขั้นสุดท้ายคือ hermes model เพื่อเลือกผู้ให้บริการโมเดล

ผลทดสอบยืนยัน Hermes Agent v0.20.0 วันที่ Release 3 สิงหาคม 2026 ทำงานบน Python 3.11.9 และติดตั้ง OpenAI SDK 2.24.0 ส่วน Desktop สร้างและเปิดถึงหน้าเลือก Model Provider ได้จริง

ภาพที่ 6 Version Snapshot จาก Runtime ที่ติดตั้งจริง โดยย่อ Path ส่วนตัวก่อนใช้ในบทความ

ภาพที่ 7 Screenshot จาก Hermes Desktop ที่ติดตั้งบนเครื่องจริง หน้าแรกขอให้เลือก Model Provider ยังไม่มีการกรอกบัญชีหรือ API Key

เอกสารยังเสนอ hermes setup --portal เป็นเส้นทางตั้งค่า Nous Portal แบบรวดเร็ว แต่คำสั่งนี้อาจเปิดขั้นตอนเข้าสู่ระบบและผูกบริการภายนอก ควรอ่านแผน ราคา นโยบายข้อมูล และสิ่งที่จะเปิดใช้งานก่อนยืนยัน ไม่ต้องเลือก Portal หากต้องการใช้ Provider อื่นหรือ Local Endpoint

ภาพที่ 8 หลังติดตั้ง ผู้ใช้สามารถเริ่ม Hermes และตั้งค่า Model, Tools, Gateway หรือ Setup Wizard แยกกันได้ — Source: Hermes Agent Documentation, 4 สิงหาคม 2026

ผลตรวจ Dependency หลังติดตั้ง

คำสั่งติดตั้ง Workspace รายงานช่องโหว่ระดับสูงสองรายการเมื่อรวม Development dependencies ทั้งหมด แต่การรัน npm audit --omit=dev แยกเฉพาะ Runtime dependencies พบหนึ่งรายการระดับ Moderate ใน undici และไม่พบ High หรือ Critical ณ เวลาทดสอบ ตัวเลขนี้เปลี่ยนได้ตาม Lockfile และ Advisory Database จึงต้องบันทึกวันที่และไม่ใช้เป็นคำรับรองว่า Runtime ปลอดภัย

บทความไม่ได้รัน npm audit fix หรือ --force เพราะคำสั่งแก้อัตโนมัติอาจเปลี่ยน Lockfile และเวอร์ชัน Dependency ควรให้ Maintainer ประเมิน Patch ที่เข้ากันได้ก่อน

ตั้งค่า Model Provider ครั้งแรก

ผู้ใช้มีสามเส้นทางหลัก

• Nous Portal — เหมาะเมื่ออยากใช้บริการและ Tool Gateway ของ Nous ผ่านกระบวนการ Setup ที่เตรียมไว้
• Cloud Provider อื่น — เลือกผู้ให้บริการที่ Hermes รองรับและใส่ Credential ตามช่องทางของระบบ ห้ามวาง API Key ลงใน Prompt, Screenshot หรือไฟล์ที่ Commit เข้า Git
• Local/Custom Endpoint — เลือก Custom Endpoint แล้วใส่ Base URL, Model Name และ Context Length ให้ตรงกับ Server จริง โมเดลต้องรองรับ Tool Calling ได้ดีพอสำหรับงาน Agent

หากเลือก Local Model อย่าเริ่มจาก Subagent ทันที ให้ทดสอบบทสนทนาธรรมดา จากนั้นทดสอบ Tool Call แบบ Read-only หนึ่งงาน เช่นให้ Agent แสดงรายชื่อไฟล์ในโฟลเดอร์ทดลอง เมื่อขั้นพื้นฐานเสถียรจึงเพิ่ม Memory, Skills, MCP และ Delegation ตามลำดับ

Hands-on: ดาวน์โหลด Local LLM แล้วคุยภาษาไทยผ่าน Hermes

การทดลองรอบนี้ทำบนเครื่อง Windows จริงที่ติดตั้ง Hermes Desktop 0.20.0 แล้ว เครื่องมี NVIDIA GeForce RTX 4080 พร้อม VRAM 16,376 MiB และมีหน่วยความจำระบบว่างประมาณ 47 GB ขณะตรวจ สภาพแวดล้อมมี Ollama 0.32.5 อยู่ก่อนแล้ว แต่ยังไม่มี gemma4:12b เราจึงดาวน์โหลดโมเดลใหม่จริง ไม่ได้นำผลจากโมเดลเดิมมาอ้างแทน

เอกสาร Local Ollama Setup ของ Hermes กำหนดประเด็นสำคัญสองข้อสำหรับงาน Agent คือโมเดลควรรองรับ Tool Calling และต้องมี Effective Context อย่างน้อย 64K การเลือกครั้งนี้จึงไม่ดูแค่คำว่า “ตอบภาษาไทยได้” แต่ดูความเข้ากันได้กับ Agent Runtime ด้วย จากตัวเลือกที่ตรวจพบ เราเลือก gemma4:12b เพราะเป็นโมเดล 11.9B แบบ Q4_K_M ขนาดดาวน์โหลด 7.6 GB รองรับ Tools, Thinking, Vision และ Audio มี Native Context 262,144 tokens และใช้ Apache License 2.0 ขนาดดังกล่าวเหมาะกับ VRAM 16 GB มากกว่ารุ่น 26B หรือ 31B ที่ต้องใช้หน่วยความจำสูงกว่า

ภาพที่ 9 — Snapshot จากการตรวจเครื่องจริงก่อนเลือก Local LLM ตัวเลข RAM เปลี่ยนได้ตามโปรแกรมที่กำลังเปิดอยู่

ขั้นที่ 1 ดาวน์โหลดโมเดลด้วย Ollama

ใช้คำสั่งต่อไปนี้

ollama pull gemma4:12b

Ollama ดาวน์โหลด Layer หลักประมาณ 7.4 GB และ Layer ประกอบประมาณ 175 MB จากนั้นตรวจ SHA-256, เขียน Manifest และรายงาน success กระบวนการบนเครื่องทดสอบใช้เวลาประมาณ 112 วินาที แต่อัตราเร็วจริงขึ้นกับอินเทอร์เน็ตและ Cache ของแต่ละเครื่อง

ภาพที่ 10 — Log Snapshot จากผลการดาวน์โหลดจริง ตัด Animation ซ้ำของ Progress Bar ออกเพื่อให้อ่านง่าย แต่คงขนาด Layer และสถานะตรวจสอบไว้

หลังดาวน์โหลด ให้ตรวจคุณสมบัติจริงจากเครื่อง ไม่อาศัยชื่อบนหน้าเว็บอย่างเดียว

ollama show gemma4:12b
ollama list

ผลที่ได้ต้องเห็น gemma4:12b ในรายการ และควรตรวจ Capabilities, Context Length, Quantization และ License ให้ตรงกับสิ่งที่ต้องการใช้งาน

ขั้นที่ 2 สร้างโปรไฟล์ 64K สำหรับ Hermes

แม้โมเดลรองรับ Context สูงสุด 262K แต่ Hermes ต้องรู้ Effective Context ที่ Server จัดสรรจริง เราจึงสร้างโปรไฟล์ชื่อ gemma4-hermes-thai:12b จากโมเดลที่ดาวน์โหลด โดยตั้ง num_ctx 65536 ไม่ดันไปถึงค่าสูงสุด เพราะ Context ที่ใหญ่ขึ้นใช้ VRAM/RAM มากขึ้นและทำให้ตอบช้าลง

FROM gemma4:12b
PARAMETER num_ctx 65536
PARAMETER temperature 0.7
PARAMETER top_p 0.95
PARAMETER top_k 64

จากนั้นสร้างโปรไฟล์ด้วย

ollama create gemma4-hermes-thai:12b -f .\Modelfile-gemma4-hermes-thai

การสร้างโปรไฟล์ไม่ได้ดาวน์โหลดโมเดล 7.6 GB ซ้ำ Ollama ใช้ Layer เดิมและสร้าง Manifest ใหม่สำหรับ Parameter ชุดนี้

ขั้นที่ 3 เชื่อม Hermes กับ Local Endpoint

ค่าที่ใช้ในการทดลองมีดังนี้

model:
  default: "gemma4-hermes-thai:12b"
  provider: "custom"
  base_url: "http://127.0.0.1:11434/v1"
  context_length: 65536

127.0.0.1 หมายถึงปลายทางอยู่บนเครื่องเดียวกัน ไม่ใช่ Cloud API และ Ollama ในการตั้งค่านี้ไม่ต้องใช้ API Key หากเปลี่ยนเป็น IP ในเครือข่ายหรือเปิด Port ให้เครื่องอื่นเข้าถึง Threat Model จะเปลี่ยนทันที ต้องเพิ่ม Authentication, Firewall และ Access Control ตามความเสี่ยง

ภาพที่ 11 — ค่าที่ตรวจจาก config.yaml จริง แสดงเฉพาะค่าที่ไม่เป็นความลับ

เมื่อรีสตาร์ต Hermes Desktop ช่องเลือกโมเดลด้านล่างแสดง Gemma4 Hermes Thai จึงยืนยันได้ว่าแอปอ่านการตั้งค่าใหม่แล้ว

ภาพที่ 12 — Hermes Desktop เปิดด้วย Local Model ที่ตั้งไว้ โดยไม่มี Cloud API Key

ขั้นที่ 4 ทดสอบโมเดลตรงก่อนทดสอบผ่าน Hermes

เราส่งคำถามภาษาไทยไปยัง Ollama Local API โดยปิด Thinking สำหรับ Baseline และกำหนด num_ctx 65536 โมเดลตอบเรื่องบทบาทของกรุงเทพมหานครเป็นภาษาไทยถูกต้องในเวลาประมาณ 9.8 วินาที การทดสอบชั้นนี้สำคัญเพราะถ้า Ollama ตอบไม่ได้ ปัญหายังไม่เกี่ยวกับ Hermes

ขั้นที่ 5 แชตภาษาไทยผ่าน Hermes Desktop

Prompt แรกใช้ยืนยันว่าระบบตอบภาษาไทยได้ จากนั้นส่ง Prompt ติดตามเพื่อให้โมเดลอธิบายขอบเขตของคำว่าออฟไลน์ให้ชัดขึ้น

ตอบเป็นภาษาไทยแบบเข้าใจง่ายไม่เกิน 6 บรรทัด: Local LLM คืออะไร
เหมาะกับใคร และมีข้อดี 3 ข้อ โปรดระบุด้วยว่าการทำงานออฟไลน์
ไม่รวมเครื่องมือที่ต้องใช้อินเทอร์เน็ต

Hermes ส่ง Prompt ไปยัง gemma4-hermes-thai:12b บนเครื่อง รอบแรกแสดงเวลาคิด 21 วินาที และรอบติดตามแสดง 52 วินาที คำตอบใหม่อธิบายว่า Local LLM รันบนคอมพิวเตอร์ของผู้ใช้ เหมาะกับผู้ที่กังวลเรื่องความปลอดภัยหรือความเป็นส่วนตัว พร้อมยกข้อดีเรื่องความเป็นส่วนตัว ค่าใช้จ่าย และการทำงานออฟไลน์ครบสามข้อ อีกทั้งระบุว่า Feature ที่ต้องค้นข้อมูลล่าสุดแบบ Real-time ยังต้องใช้อินเทอร์เน็ต แปลว่าห่วงโซ่ Desktop → Hermes Runtime → OpenAI-compatible Local Endpoint → Ollama → Model → UI ทำงานครบ

ภาพที่ 13 — การสนทนาจริงสองรอบกับ gemma4-hermes-thai:12b ผ่าน Hermes Desktop ใน Dark Theme ภาพจับจากหน้าต่าง Hermes บนจอ 1 โดยตรงในระบบสามจอ เพื่อไม่ให้พิกัด Virtual Desktop ทำให้ได้ภาพจอดำ และผ่านการตรวจรูปสระกับวรรณยุกต์ไทยก่อนนำมาใช้

มีข้อควรอ่านผลอย่างระมัดระวัง: คำตอบรอบแรกใช้ ChatGPT และ Gemini เป็นตัวอย่างเพื่อเปรียบเทียบความคุ้นเคย แต่ไม่ได้หมายความว่าเราดาวน์โหลดโมเดลกรรมสิทธิ์ของบริการเหล่านั้นมาไว้ในเครื่อง โมเดลที่รันจริงคือ Gemma 4 12B ผ่าน Ollama ส่วนคำตอบรอบติดตามแก้ขอบเขตให้ชัดว่า “ทำงานออฟไลน์” หมายถึงการอนุมานด้วยโมเดลที่ดาวน์โหลดแล้ว; Tool ที่ต้องเรียกเว็บ, Cloud API หรือบริการภายนอกยังต้องใช้อินเทอร์เน็ต

การทดสอบแบบปลอดภัยครั้งแรก

สร้างโฟลเดอร์ทดลองที่ไม่มีข้อมูลจริง แล้ววางไฟล์ข้อความจำลองหนึ่งหรือสองไฟล์ ตั้งขอบเขตให้ Agent อ่านอย่างเดียว จากนั้นใช้ Prompt เช่น

อ่านไฟล์ในโฟลเดอร์ทดลองนี้และสรุปชื่อไฟล์กับหัวข้อหลัก
ห้ามแก้ ลบ ย้าย หรือสร้างไฟล์
ถ้าต้องใช้สิทธิ์เพิ่ม ให้หยุดและถามก่อน

ตรวจคำตอบกับไฟล์จริง หาก Agent บอกว่าเปิดไฟล์แล้ว ให้ดูว่ารายชื่อและเนื้อหาตรงกัน ขั้นต่อไปจึงค่อยอนุญาตให้สร้างไฟล์ใหม่ในโฟลเดอร์ทดลองหนึ่งไฟล์ อย่าเริ่มด้วย Repository สำคัญ, API Key, Production Data หรือโฟลเดอร์ส่วนตัวทั้งหมด

ปัญหาที่พบบ่อยหลังติดตั้ง

PowerShell หา hermes ไม่พบ — ปิด Terminal แล้วเปิดใหม่ ตรวจ Get-Command hermes และตรวจว่าตำแหน่งติดตั้งถูกเพิ่มใน PATH แล้วหรือไม่

เปิด Hermes ได้แต่คุยไม่ได้ — ตรวจว่าเลือก Model Provider แล้ว Credential ใช้ได้ และชื่อโมเดลตรงกับ Provider

Local Model เรียก Tool ไม่สำเร็จ — ตรวจว่า Endpoint ใช้รูปแบบ API ที่รองรับ โมเดลรองรับ Tool Calling และ Context Length ที่ตั้งไว้ไม่เกินความสามารถจริงของ Server

คำสั่งถูกบล็อก — นี่อาจเป็น Approval Guard ที่ทำงานตามปกติ อ่านคำสั่งและผลกระทบก่อนอนุมัติ อย่าปิด Safety Prompt เพียงเพื่อให้ Tutorial ทำงานเร็วขึ้น

พบคำเตือน Remote Host Identification Has Changed — ระหว่างการตรวจ CLI ในสภาพแวดล้อมนี้มีคำสั่งหนึ่งพยายามเข้าสู่เส้นทาง SSH และพบ Host Key เปลี่ยน เราหยุดทันที ไม่ลบ known_hosts และไม่ยอมรับ Key ใหม่ หากผู้อ่านพบข้อความเดียวกัน ให้ตรวจ Host, Fingerprint, Profile และ Config กับผู้ดูแลระบบก่อน การติดตั้ง Hermes ไม่ใช่เหตุผลให้ข้ามคำเตือน Man-in-the-middle

ต้องการถอนการติดตั้งหรืออัปเดต — ใช้หน้า Updating & Uninstalling ของ Documentation รุ่นปัจจุบัน ไม่ลบโฟลเดอร์ .hermes แบบเหมารวม เพราะอาจมี Config, Memory, Skill และ Session ที่ต้องสำรองก่อน

Agent ต่างจาก Chatbot อย่างไร

Chatbot แบบพื้นฐานรับข้อความแล้วส่งข้อความกลับ การสนทนาอาจยาวและฉลาดมาก แต่แกนของมันยังเป็น “ตอบ” มากกว่า “ลงมือทำ” หากเราถามวิธีหาจำนวนไฟล์ Chatbot อาจอธิบายคำสั่งให้ แต่ Agent สามารถอ่านโฟลเดอร์ รันคำสั่ง นับไฟล์ ตรวจผล และส่งรายการผิดปกติกลับมาได้—เมื่อได้รับสิทธิ์ให้ทำเช่นนั้น

ความแตกต่างจึงไม่ควรวัดจากน้ำเสียงหรือความยาวของคำตอบ ควรวัดจากวงจรการกระทำ

อย่างไรก็ตาม เส้นแบ่งนี้ไม่แข็งตายตัว ผลิตภัณฑ์ Chat สมัยใหม่อาจมี Browser, Code Execution และ Connector ขณะที่ Agent บางตัวอาจถูกจำกัดให้ตอบอย่างเดียวในบาง Session คำว่า Agent จึงบอก “รูปแบบการทำงานที่เป็นไปได้” ไม่ได้รับประกันความเป็นอิสระ ความถูกต้อง หรือความปลอดภัย

อีกความเข้าใจผิดคือ Agent มีความตั้งใจของตัวเองเหมือนคน ความจริง Agent ทำงานภายใต้ Prompt, Model, Tool Schema, Policy และข้อมูลที่ได้รับ มันอาจเลือกเส้นทางระหว่างงาน แต่การเลือกนั้นยังเกิดในกรอบที่ระบบอนุญาต ความรับผิดชอบด้านข้อมูล สิทธิ์ และผลกระทบจึงยังอยู่กับผู้ติดตั้งและผู้อนุมัติงาน

Parent, Subagent และ Multi-agent

เมื่อ Agent ตัวเดียวเริ่มแบก Context มากเกินไป เราอาจแยกงานบางส่วนออกไปให้ Agent อีกตัว นี่คือจุดเริ่มของ Parent และ Subagent

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

Subagent คือ Agent ลูกที่ได้รับงานเฉพาะ มี Context แยก และคืนผลกลับมาให้ Parent จุดเด่นไม่ใช่เพียง “มี AI เพิ่มอีกตัว” แต่คือการสร้างขอบเขตความสนใจใหม่ งานวิจัยไม่ต้องเห็น Log การ Build ทั้งหมด และผู้ตรวจความเป็นส่วนตัวไม่ต้องแก้สำนวนบทความทั้งชิ้น

Multi-agent Workflow คือกระบวนการที่มี Agent มากกว่าหนึ่งตัวทำงานภายใต้ความสัมพันธ์ที่กำหนด อาจทำพร้อมกัน ทำต่อกัน สร้างแล้วตรวจ หรือมี Manager แจกงานให้ Worker หลายตัว ความหมายสำคัญอยู่ที่ Workflow และสัญญาส่งมอบ ไม่ใช่จำนวน Agent

ผู้ใช้
  ↓
Parent / Orchestrator
  ├─ Research Subagent ── หลักฐาน + ช่องว่างข้อมูล
  ├─ Technical Subagent ─ กลไก + ตัวอย่าง
  └─ Risk Subagent ────── ความเสี่ยง + วิธีลด
  ↓
Parent ตรวจความขัดแย้งและรวมผล
  ↓
Reviewer ตรวจ Claim และ Artifact
  ↓
Human Approval

เหตุผลที่ใช้ Subagent มักมีห้าข้อ

หนึ่ง แยก Context งานที่มีข้อมูลมากออกจากกัน สอง ทำงานอิสระพร้อมกันเพื่อลดเวลารอ สาม เลือกโมเดลหรือ Toolset ให้เหมาะกับงาน สี่ เพิ่มขั้นตอนตรวจงานจากมุมที่ต่างกัน และห้า รักษา Context หลักให้เหลือเฉพาะข้อมูลที่ใช้ตัดสินใจ

แต่มีต้นทุนแลกเปลี่ยน Parent ต้องเขียน Context Package, รอผล, ตรวจความขัดแย้ง และรวมคำตอบ หากงานย่อยเชื่อมกันแน่นจนทุกตัวต้องอ่านข้อมูลชุดเดียวกัน การแยก Agent อาจทำให้ส่ง Context ซ้ำและแพงกว่าเดิม หากทุก Agent แก้ไฟล์เดียวกันก็เสี่ยงชนกัน หากไม่มี Output Schema ผลที่คืนมาอาจคนละรูปแบบจนรวมไม่ได้

กฎง่ายที่สุดคือ แยกตามขอบเขตการตัดสินใจ ไม่ใช่แยกตามหัวข้อที่ดูสวย งานย่อยที่ดีควรมีอินพุตชัด ทำได้ค่อนข้างอิสระ ส่งผลลัพธ์ในรูปแบบที่ตกลง และมีวิธีตรวจโดยไม่ต้องเชื่อคำสรุปของ Agent

Subagent ของ Hermes ทำงานอย่างไร

เอกสาร Hermes อธิบายว่า delegate_task ใช้สร้าง Agent ลูกที่มี Context แยก และเริ่มด้วยบทสนทนาใหม่ โดยลูกจะสืบทอด (Inherit) ชุดเครื่องมือที่เปิดใช้งานอยู่จาก Parent และระบบจะควบคุมการเข้าถึงเครื่องมือบางประเภทตามนโยบายความปลอดภัยของโปรไฟล์ หัวใจสำคัญคือ Subagent จะไม่เห็นประวัติการคุยของ Parent และทำงานภายใต้ขอบเขตที่กำหนดชัดเจนผ่าน goal และ context ที่ส่งให้

นี่คือข้อจำกัดที่ดูเหมือนจุดอ่อน แต่จริง ๆ เป็นคุณสมบัติสำคัญของการแยกงาน ถ้า Subagent เห็นทุกอย่างโดยอัตโนมัติ เราจะไม่ได้ Context Isolation และยังเสีย Token กับข้อมูลที่ไม่เกี่ยวข้องเหมือนเดิม

เปรียบเทียบสองคำสั่งนี้

ไม่พอ: "ตรวจข้อผิดพลาดให้หน่อย"

พอใช้ได้:
- เป้าหมาย: หาสาเหตุ TypeError ใน api/handlers.py
- อาการ: เกิดเมื่อ Request ไม่มี Content-Type
- ขอบเขต: อ่าน src/api และ tests/api เท่านั้น
- ห้าม: เปลี่ยน Public API หรือ Dependency
- ส่งกลับ: สาเหตุ, ไฟล์ที่เกี่ยวข้อง, Patch ที่เสนอ, Test ที่รัน, ความเสี่ยงคงเหลือ

Subagent ไม่มีทางเดาข้อจำกัดส่วนที่ Parent ลืมส่งได้อย่างน่าเชื่อถือ หาก Repository ใช้ Python 3.11 แต่ Parent ไม่บอก หากคำว่า “สำเร็จ” หมายถึงต้องผ่าน Test 120 รายการแต่ Parent ไม่ระบุ หรือหากมีไฟล์ที่ห้ามแก้แต่ Parent ไม่กล่าวถึง ผลลัพธ์อาจดูดีแต่ใช้จริงไม่ได้

Context Package ที่ดีควรมีอะไร

ใช้สูตรสั้น ๆ แปดส่วนได้ดังนี้

1. Goal — ต้องการผลอะไร ไม่ใช่เพียงให้ทำกิจกรรมอะไร
2. Background — เหตุใดงานนี้จึงเกิดขึ้น และข้อเท็จจริงใดห้ามเปลี่ยน
3. Inputs — ไฟล์ ลิงก์ ข้อมูล Error หรือ Artifact ที่ต้องใช้
4. Scope — อ่านหรือแก้ตรงไหนได้ และตรงไหนอยู่นอกขอบเขต
5. Constraints — เวลา งบ Tool, Model, Privacy, Style และข้อห้าม
6. Output Contract — ต้องส่งอะไร ในโครงสร้างใด พร้อมหลักฐานอะไร
7. Success Criteria — เราจะรู้ได้อย่างไรว่างานผ่าน
8. Escalation Rule — เมื่อข้อมูลไม่พอหรือเสี่ยง ให้หยุดและรายงานอะไร

ตัวอย่าง Context Package สำหรับ Research Subagent

Goal: ตรวจว่าคำกล่าวอ้างเรื่อง Local LLM ของ Hermes Agent ถูกต้องแค่ไหน
Sources: ใช้ Documentation และ Repository ทางการเป็นหลัก
Date: อ้างสถานะ ณ 4 สิงหาคม 2026
Required claims: Custom endpoint, Tool Calling, Context requirement, data location
Do not infer: ห้ามสรุปว่า Local เท่ากับ Private โดยอัตโนมัติ
Output: ตาราง Claim | Source | Qualification | Confidence
Success: ทุก Claim สำคัญมี URL ตรงหน้าและบอกสิ่งที่เอกสารไม่ยืนยัน

งานพร้อมกันกับงานซ้อนชั้น

Hermes รองรับการส่ง tasks หลายรายการเพื่อให้ Subagent ทำงานพร้อมกัน โดยเอกสารปัจจุบันระบุค่าเริ่มต้นของจำนวนงานพร้อมกันและเปิดให้กำหนดได้ การเพิ่ม Concurrency ไม่ได้แปลว่าจะเร็วขึ้นเสมอ เพราะยังติด Rate Limit, VRAM, Network, Disk และงานรวมผล

สำหรับ Nested Orchestration เอกสารแยกบทบาทลูกเป็น leaf กับ orchestrator โดย Leaf ไม่ได้รับสิทธิ์ Delegate ต่อ ส่วน Orchestrator สามารถมอบหมายต่อได้เมื่อเปิดการตั้งค่าความลึก การจำกัดนี้ช่วยลดความเสี่ยงที่ต้นไม้ Agent แตกกิ่งโดยไม่มีขอบเขต

Depth 0: Parent
  ├─ Depth 1: Leaf A
  ├─ Depth 1: Leaf B
  └─ Depth 1: Orchestrator C
       ├─ Depth 2: Leaf C1
       └─ Depth 2: Leaf C2

อย่ามอง Spawn Depth เป็นระดับความฉลาด มันคือระดับความซับซ้อนและตัวคูณต้นทุน ถ้าแต่ละ Agent แตกงานสามตัว ต้นไม้สามชั้นอาจสร้างงานปลายทางจำนวนมากอย่างรวดเร็ว พร้อม Model Call, Context และ Tool Call แยกกันทุกกิ่ง การใช้ Nested Agent จึงควรมีเพดาน Concurrency, Iteration, Timeout, Budget และผู้รับผิดชอบรวมผล

วิธีสร้าง Subagent ทีละขั้น

ส่วนนี้เป็นวิธีออกแบบตามเอกสาร ไม่ใช่บันทึกการทดลองบนเครื่องของ Insightful AI World คำสั่งและค่าตั้งอาจเปลี่ยนตามรุ่น ควรตรวจ Documentation ปัจจุบันก่อนนำไปใช้

ขั้นที่ 1 เริ่มจาก Baseline แบบ Agent ตัวเดียว

อย่าเริ่มด้วยทีม Agent ให้รันโจทย์เดียวกันด้วย Parent ตัวเดียวก่อน บันทึกเวลา จำนวนครั้งที่ต้องแก้ คุณภาพผลลัพธ์ ปริมาณ Context และความผิดพลาด Baseline นี้ทำให้เรารู้ว่า Subagent ช่วยจริงหรือเพียงทำให้ระบบดูซับซ้อนขึ้น

ตัวอย่างโจทย์คือ “อ่านเอกสารผลิตภัณฑ์ สรุปความสามารถ ตรวจ Privacy และเขียนคำแนะนำ 1,500 คำ” ให้ Agent ตัวเดียวทำจนเสร็จ แล้วสังเกตว่าปัญหาอยู่ตรงไหน หากปัญหาเป็นเพียงงานคัดข้อความเชิงกล Script อาจเหมาะกว่า Subagent หากปัญหาคือหลักฐานกับข้อสรุปปะปนกัน เราอาจแยก Researcher กับ Reviewer

ขั้นที่ 2 แยกงานตาม Dependency

เขียนงานย่อยทั้งหมดแล้ววาดลูกศรว่าอะไรต้องรออะไร งานที่ไม่ต้องรอกันสามารถทำ Parallel งานที่ต้องใช้ผลก่อนหน้าควรทำ Sequential

ค้นข้อมูล Technical ─┐
ตรวจ Privacy ────────┼─→ Parent สังเคราะห์ ─→ Reviewer
ประเมิน Cost ────────┘

หาก Technical Agent ต้องใช้ผล Privacy ก่อนจะตัดสินใจ งานสองชิ้นนี้ไม่อิสระจริง อย่าฝืนรันพร้อมกันเพื่อหวังความเร็ว เพราะ Parent อาจต้องส่งงานแก้อีกครั้ง

ขั้นที่ 3 กำหนด Toolset เท่าที่จำเป็น

Research Agent อาจต้องใช้เว็บแต่ไม่ต้องแก้ไฟล์ Reviewer อาจต้องอ่านไฟล์แต่ไม่ต้อง Terminal ส่วน Coding Agent อาจต้อง File กับ Terminal หลัก Least Privilege ช่วยลดทั้งความเสี่ยงและทางเลือกที่รบกวนการตัดสินใจ

อย่าให้ Agent ทุกตัวใช้ทุก Tool “เผื่อไว้” โดยเฉพาะ Tool ที่ส่งข้อมูลออกภายนอก แก้ Production หรือลบข้อมูล การจำกัด Tool ไม่ได้ทำให้ระบบด้อยลง หากตรงกับขอบเขตงาน มันทำให้เหตุผลและ Audit ง่ายขึ้น

ขั้นที่ 4 เขียน Output Contract

แทนที่จะขอ “สรุปผล” ให้กำหนดโครงสร้าง เช่น

status: complete | partial | blocked
claims:
  - statement:
    source_url:
    evidence_type:
    confidence:
files_read: []
files_changed: []
tests_run: []
open_questions: []
risks: []

Schema ไม่รับประกันว่าข้อมูลถูก แต่ทำให้ Parent ตรวจสิ่งที่ขาดได้ง่าย และลดปัญหา Agent หนึ่งเขียนเรียงความ ขณะที่อีกตัวส่งรายการสั้นจนเปรียบเทียบไม่ได้

ขั้นที่ 5 มอบหมายงาน

ตัวอย่างรูปแบบจากเอกสาร Hermes แบบย่อมีลักษณะดังนี้

delegate_task(
    goal="ตรวจเอกสารทางการของ Hermes Agent เรื่อง Subagent",
    context="ใช้แหล่งทางการเท่านั้น อ้างสถานะวันที่ 4 สิงหาคม 2026 ส่ง Claim Register พร้อม URL และข้อจำกัด"
)

จุดที่ต้องเข้าใจ: delegate_task ไม่มีพารามิเตอร์ toolsets สำหรับให้ Parent ส่งชุดเครื่องมือแก่ลูกโดยตรง Subagent สืบทอด Toolsets ที่เปิดให้ Parent ตามการตั้งค่าของ Session แต่ Runtime จะบล็อกเครื่องมือบางชนิดในบริบทของ Subagent เพื่อควบคุมความเสี่ยง ดังนั้นต้องเตรียมสิทธิ์ที่ Parent ให้ถูกก่อนมอบหมายงาน และตรวจพฤติกรรมกับเอกสารของรุ่นที่ติดตั้ง

สำหรับงานอิสระหลายชิ้น สามารถส่งรายการงานเป็น Batch

delegate_task(tasks=[
    {
        "goal": "ตรวจกลไก Subagent",
        "context": "คืนค่า Claim, Source, Qualification"
    },
    {
        "goal": "ตรวจ Privacy และ Security",
        "context": "แยก Local storage, provider data flow, permissions และ residual risk"
    },
    {
        "goal": "ตรวจ Local LLM requirements",
        "context": "ตรวจ endpoint, context และ tool calling จากเอกสารทางการ"
    }
])

โค้ดนี้เป็นตัวอย่างแนวคิด ต้องตรวจชื่อ Parameter และพฤติกรรมกับเอกสารรุ่นที่ติดตั้งจริงก่อนใช้ โดยเฉพาะค่า Concurrency, Background behavior และการยกเลิกงานซึ่งอาจเปลี่ยนระหว่าง Release

ขั้นที่ 6 ตรวจ Artifact ไม่เชื่อ Summary อย่างเดียว

หาก Subagent บอกว่าสร้างไฟล์แล้ว ให้ Parent ตรวจว่าไฟล์มีอยู่ เปิดได้ และมีเนื้อหาตรงข้อกำหนด หากบอกว่า Test ผ่าน ให้ดู Exit Code และ Test Output หากบอกว่า Claim มี Source ให้เปิด URL ตรงหน้า ไม่ใช่เชื่อชื่อเอกสารที่ Agent พิมพ์

หลักนี้สำคัญมากเพราะ Agent สามารถสรุปการกระทำคลาดเคลื่อนได้ แม้ Tool จะทำงานล้มเหลว Hermes มีระบบด้านความปลอดภัยและการตรวจการกลายพันธุ์ของไฟล์ตามเอกสาร แต่ผู้ใช้ยังควรออกแบบ Verification Layer ที่ผูกกับ Artifact จริง

ขั้นที่ 7 วัดเทียบ Baseline

หลังรัน Multi-agent ให้เทียบกับ Agent ตัวเดียวด้วยโจทย์และ Rubric เดียวกัน

• ความครบถ้วนของ Claim ดีขึ้นหรือไม่
• จำนวนข้อผิดพลาดสำคัญลดลงหรือไม่
• เวลารวมและเวลาที่มนุษย์ใช้ตรวจเปลี่ยนอย่างไร
• Model Call และค่าใช้จ่ายเพิ่มเท่าไร
• Context ของ Parent สะอาดขึ้นจริงหรือไม่
• งานชนกันหรือเกิดการแก้ซ้ำหรือไม่

ถ้าคุณภาพเพิ่มเพียงเล็กน้อยแต่ต้นทุนและเวลาตรวจเพิ่มมาก ให้กลับไปใช้ Agent ตัวเดียวหรือ Script การลด Agent เป็นการปรับสถาปัตยกรรม ไม่ใช่ความล้มเหลว

รูปแบบ Multi-agent ที่ใช้ได้จริง

Multi-agent ไม่มีแบบเดียว การเลือกรูปแบบควรเริ่มจาก Dependency และวิธีตรวจ

Parallel Specialists

ให้ Agent หลายตัวตรวจคนละมิติพร้อมกัน เช่น Technical, Privacy และ Cost แล้ว Parent รวมผล เหมาะกับงานที่ใช้แหล่งต่างกันและไม่ต้องรอคำตอบซึ่งกันและกัน

ข้อดีคือเร็วและแยก Context ชัด ข้อเสียคือ Agent อาจใช้คำนิยามหรือสมมติฐานต่างกัน Parent ต้องกำหนด Rubric และวันที่ Fact-check เดียวกัน มิฉะนั้นผลที่ดูขัดแย้งอาจมาจากโจทย์คนละชุด

Sequential Pipeline

งานไหลเป็นลำดับ Research → Outline → Draft → Fact-check → Edit เหมาะเมื่อผลของขั้นก่อนเป็นอินพุตบังคับของขั้นถัดไป

ข้อดีคือ Trace ได้ง่าย ข้อเสียคือความผิดช่วงต้นแพร่ไปทุกขั้น หาก Research ผิด Writer อาจเขียนผิดอย่างเป็นระบบ จึงควรมี Gate ระหว่างขั้น ไม่ใช่รอ Reviewer คนสุดท้ายจับทุกอย่าง

Generator–Reviewer

Agent หนึ่งสร้างงาน อีกตัวตรวจตาม Rubric แล้ว Parent ตัดสินใจแก้ เหมาะกับโค้ด เอกสาร และการวิเคราะห์ที่มีเกณฑ์ตรวจชัด

Reviewer ไม่ควรถูกสั่งเพียง “ดูว่าดีไหม” ควรตรวจ Claim, Test, Security, Style หรือ Acceptance Criteria ที่ระบุ หาก Reviewer ใช้โมเดลและ Context แบบเดียวกับ Generator อาจมี Blind Spot เดียวกัน จึงควรผูกกับหลักฐานภายนอกหรือการทดสอบ

Debate–Judge

ให้ Agent หลายตัวเสนอแนวทางต่างกัน แล้ว Judge ประเมินตามเกณฑ์ เหมาะกับการตัดสินใจที่มี Trade-off ไม่ใช่ข้อเท็จจริงคำตอบเดียว

ข้อควรระวังคือ Consensus ไม่ได้แปลว่าถูก Agent หลายตัวอาจได้รับข้อมูลผิดชุดเดียวกัน และ Judge อาจชอบคำตอบที่เขียนดีมากกว่าคำตอบที่ถูก หากใช้รูปแบบนี้ ควรให้แต่ละข้อเสนอแนบหลักฐานและกำหนดเงื่อนไขที่จะหักล้างข้อเสนอ

Manager–Worker

Manager แตกงานและมอบหมายให้ Worker เหมาะกับงานจำนวนมากที่มีรูปแบบซ้ำ เช่นตรวจหลายไฟล์หรือสรุปเอกสารหลายชุด Manager ต้องควบคุม Queue, Retry และการรวมผล

ถ้างานเป็นเชิงกลทั้งหมด เช่นแปลงรูปแบบไฟล์ 1,000 ไฟล์ Script มักถูกกว่า เร็วกว่า และทำซ้ำได้มากกว่า Agent ให้ Worker รับเฉพาะส่วนที่ต้องใช้การตีความ

Hierarchical Orchestration

Parent สร้าง Orchestrator ลูก ซึ่งสร้าง Leaf ต่อ เหมาะกับงานขนาดใหญ่ที่แบ่งเป็นทีมย่อยจริง เช่นระบบหนึ่งมี Backend, Frontend และ Security โดยแต่ละส่วนมีงานย่อยหลายงาน

นี่คือรูปแบบที่ควรใช้ช้าที่สุด เพราะ Cost, Race Condition, Context Handoff และ Failure Surface เพิ่มแบบคูณ หากยังรวมผลจาก Parallel Agent ชั้นเดียวไม่เสถียร อย่าเพิ่ม Depth

Hermes ในฐานะ Orchestration Layer

Orchestration Layer คือชั้นที่ประสานเป้าหมาย โมเดล เครื่องมือ Context งานย่อย ลำดับ Dependency การตรวจ และ Approval ให้กลายเป็นกระบวนการเดียว เปรียบได้กับผู้จัดการเวทีที่ไม่ได้ร้องเพลงแทนนักแสดง แต่รู้ว่าใครขึ้นเมื่อใด ใช้อุปกรณ์อะไร และการแสดงจบเมื่อใด

Hermes ทำหน้าที่นี้ได้ในระดับ Framework/Runtime เพราะผู้ใช้กำหนด Model Provider, Toolset, Memory, Skills, MCP, Terminal Backend, Delegation และ Security Controls ได้ แต่คำว่า “Framework” ไม่ได้หมายความว่าต้องเขียนทุกอย่างจากศูนย์ Hermes มี CLI, Desktop, Dashboard และค่าเริ่มต้นจำนวนมาก เพียงแต่ระดับการควบคุมและภาระการดูแลมากกว่าผลิตภัณฑ์ Work สำเร็จรูป

สี่ส่วนที่ต้องแยกออกจากกันคือ

1. Model — ส่วนสร้างเหตุผลและเลือกการกระทำ
2. Agent Runtime — วงจร Tool Calling, Context และ Policy
3. Orchestrator — ส่วนแบ่งงาน จัด Dependency และรวมผล
4. Execution Environment — เครื่องหรือ Container ที่คำสั่งทำงานจริง

ความสับสนมักเกิดเมื่อเห็นชื่อโมเดลแล้วคิดว่า Runtime เหมือนกัน เช่นการเลือก Claude model เป็น Main Model ภายใน Hermes ไม่ทำให้ Hermes กลายเป็น Claude Code โดยอัตโนมัติ Tool, Permission, Prompt, Memory, Hooks และ Agent Loop ยังเป็นของ Hermes ในทางกลับกัน Claude Code ปัจจุบันมี Subagent และ Agent Teams ของตัวเอง จึงไม่ใช่เพียงโมเดล Claude ห่อ Terminal

เช่นเดียวกับ Codex การใช้โมเดล OpenAI หรือ Provider ที่ชื่อ Codex ใน Hermes ไม่ควรถูกเขียนว่าเท่ากับการใช้ Codex App/CLI/Cloud Agent เพราะ Surface, Sandbox, Approval, Repo Context และ Workflow อาจต่างกัน หากต้องการให้ Hermes เรียก External CLI จริง ต้องตรวจว่ารุ่นที่ใช้อยู่รองรับ Integration นั้นเป็น Feature ทางการแล้วหรือยัง อย่านำข้อเสนอใน GitHub Issue หรือ Roadmap มาเขียนเป็นความสามารถปัจจุบัน

เปรียบเทียบ Work, Hermes, Codex และ Claude Code

การเปรียบเทียบต่อไปนี้ยึดคำอธิบายจากเอกสารปฐมภูมิของแต่ละผลิตภัณฑ์ ไม่ใช้ภาพประชาสัมพันธ์หรือ Branding ของบุคคลที่สามเป็นหลักฐานความสามารถ

ChatGPT Work

เอกสาร OpenAI อธิบาย Work ว่าเป็น Agent สำหรับงานยาวหลายขั้นตอนและ Deliverable สำเร็จ เช่นเอกสาร Spreadsheet, Presentation, Report หรือ Site ผู้ใช้ให้ไฟล์และบริบท ระบุผลลัพธ์ ติดตามความคืบหน้า ตอบคำถาม เปลี่ยนทิศ และอนุมัติการกระทำสำคัญได้ Work ยังเชื่อมกับงานตามเวลา/Trigger ใน Surface ที่รองรับ

ข้อได้เปรียบคือผู้ใช้ไม่ต้องออกแบบ Agent Architecture หรือดูแล Runtime เอง แต่ไม่ควรสรุปจากประสบการณ์หน้าจอว่า Work ภายในใช้ Agent กี่ตัว แบ่ง Context แบบใด หรือใช้ Orchestrator ชนิดใด เว้นแต่ OpenAI เปิดเผยตรง ๆ ดังนั้นคำว่า Orchestration as a Product ในบทความนี้เป็นภาพจำเชิงผลิตภัณฑ์ ไม่ใช่ข้อเท็จจริงด้านสถาปัตยกรรมภายใน

Hermes Agent

Hermes เหมาะเมื่อเราต้องการเลือก Provider หรือ Local Endpoint, จำกัด Tool, ควบคุม Terminal Backend, เขียน Skill, เชื่อม MCP และออกแบบ Delegation เอง ข้อได้เปรียบนี้มาพร้อมภาระติดตั้ง อัปเดต Dependency ปกป้อง Secret ตรวจ Supply Chain และออกแบบ Monitoring

คำว่า Local ก็ต้องระวัง Hermes เก็บ Conversation, Memory และ Skills ไว้ในพื้นที่โปรไฟล์ตามเอกสาร แต่หาก Main Model อยู่บน Cloud Prompt และผล Tool ที่ส่งเข้าโมเดลยังออกจากเครื่องตามเส้นทางของ Provider การรัน CLI บนเครื่องไม่ได้ทำให้ข้อมูลทั้งหมด Local โดยอัตโนมัติ ต้องวาด Data Flow ตั้งแต่ไฟล์ถึง Model Endpoint, Web Tool, MCP และ Log

Codex

Codex เป็น Coding Agent ของ OpenAI ที่อ่าน Repository แก้ไฟล์ รันคำสั่งและ Test ช่วยเขียน Review และส่งมอบโค้ดได้ทั้ง Local Surface และงานที่ Delegate ไป Cloud ตามผลิตภัณฑ์ที่รองรับ หากเป้าหมายหลักคือแก้ Bug หรือพัฒนา Feature ใน Repository การใช้ Codex โดยตรงมักลดชั้น Integration และมี Workflow ที่ออกแบบมาสำหรับ Software Engineering

ไม่ควรเรียก Codex ว่า “โมเดลเขียนโค้ด” อย่างเดียว เพราะประสบการณ์ Codex รวม Agent Runtime, Permission, Context และเครื่องมือ แต่ก็ไม่จำเป็นต้องใช้ Hermes ครอบ Codex ทุกครั้ง การเพิ่ม Orchestrator มีเหตุผลเมื่อ Coding เป็นเพียงส่วนหนึ่งของงานที่มี Research, Compliance, Documentation และ Approval ข้ามระบบ และเมื่อ Integration นั้นได้รับการยืนยันว่ารองรับจริง

Claude Code

Claude Code เป็น Agentic Coding Tool ของ Anthropic อ่าน Codebase แก้ไฟล์ รันคำสั่ง ใช้ Git เชื่อม MCP และทำงานผ่าน Terminal, IDE, Desktop, Browser และ Surface อื่น เอกสารปัจจุบันยังระบุ Subagent ที่มี Context แยก และ Agent Teams ที่ประสานหลาย Session ได้

ดังนั้นคำกล่าวว่า “Hermes คือ Multi-agent ส่วน Claude Code คือ Agent ตัวเดียว” ไม่ถูกต้องแล้ว การเลือกควรดูว่างานอยู่ในโลก Software Engineering แค่ไหน ต้องการ Runtime/Provider แบบใด และองค์กรต้องการควบคุม Tool กับข้อมูลระดับใด

Decision Rule

• เลือก ChatGPT Work เมื่อปลายทางคือเอกสาร วิเคราะห์ Spreadsheet, Presentation หรือ Deliverable ธุรกิจ และคุณไม่ต้องการดูแล Agent Runtime
• เลือก Hermes Agent เมื่อคุณต้องควบคุม Provider, Endpoint, Tool, Memory, Skills, MCP, Environment และ Delegation เอง
• เลือก Codex เมื่อแกนงานคือ Repository และคุณต้องการ Coding Agent ในระบบ OpenAI
• เลือก Claude Code เมื่อแกนงานคือ Repository และคุณต้องการ Coding Agent พร้อม Extension/Subagent ในระบบ Claude Code
• ใช้หลายระบบร่วมกันต่อเมื่อมี Integration ที่รองรับ มีขอบเขตข้อมูลชัด และประโยชน์มากกว่าค่าใช้จ่ายในการประสานงาน

Use Case และแผนทดลอง

Use Case 1 ทีมวิจัยบทความ

Parent รับคำถามหลักแล้วส่ง Technical Researcher, Privacy Researcher และ Fact-checker ทำงานคนละส่วนพร้อมกัน จากนั้น Writer ใช้เฉพาะ Claim ที่มี Source และ Editor ตรวจว่าข้อสรุปเกินหลักฐานหรือไม่

ตัวชี้วัดไม่ควรเป็นจำนวนหน้าที่เขียน แต่เป็นสัดส่วน Claim สำคัญที่มี Primary Source, จำนวนข้อขัดแย้งที่ Parent แก้ได้, เวลาที่มนุษย์ใช้ตรวจ และจำนวนข้อผิดพลาดหลัง Editorial Pass

ความเสี่ยงคือ Agent หลายตัวอาจอ้าง Source เดียวกันโดยไม่ได้เปิดจริง หรือสร้างคำอธิบายซ้ำกัน ทางแก้คือใช้ Claim Register กลางและบังคับ URL ระดับหน้าที่รองรับข้อความโดยตรง

Use Case 2 ทีมพัฒนาซอฟต์แวร์

Parent แยกงานเป็น Codebase Mapping, Implementation, Test และ Security Review งาน Mapping กับ Threat Review อาจทำ Parallel แต่ Implementation ควรรอ Contract ที่ตกลงแล้ว หากหลาย Agent แก้ Repository เดียวกัน ให้แยก Branch หรือ Worktree และกำหนด Ownership ของไฟล์

สัญญาณผ่านคือ Test จริงผ่าน Diff อยู่ใน Scope และ Reviewer ตรวจ Artifact ไม่ใช่เพียง Summary สัญญาณหยุดคือ Agent เริ่มแก้ไฟล์นอกขอบเขต Merge Conflict สูง หรือใช้เวลารวมผลมากกว่าเวลาเขียนโค้ด

Use Case 3 ผู้ช่วยความรู้ภายในองค์กร

Hermes อาจเชื่อม MCP หรือระบบค้นข้อมูลภายใน แล้วใช้ Subagent แยกค้น Policy, Product และ Incident แต่ความเสี่ยงสูงกว่า Use Case สาธารณะ เพราะ Context อาจมีข้อมูลลูกค้า Credential หรือเอกสารจำกัดสิทธิ์

การบอกว่า “On-premises” ไม่พอ ต้องตรวจว่า Model Endpoint, Embedding, Web Search, Telemetry, Log, Error Report และ MCP Server อยู่ที่ใด ใครเข้าถึงได้ และข้อมูลถูกเก็บนานเท่าไร หาก Agent ใดไม่จำเป็นต้องเห็นข้อมูลส่วนบุคคล ให้ส่งเฉพาะข้อมูลที่ลดรูปแล้ว

แผนทดลองที่ควรทำก่อน Verdict

บทความฉบับต่อไปควรทดลองโจทย์เดียวกันสี่แบบ ไม่ควรแต่งผลลัพธ์ล่วงหน้า

1. ChatGPT Work หนึ่งงาน
2. Hermes Agent ตัวเดียว
3. Hermes Parent + Researcher + Reviewer
4. Codex หรือ Claude Code สำหรับส่วน Coding ที่กำหนด

ให้ทุกวิธีใช้ Input ชุดเดียวกัน เป้าหมายเดียวกัน Rubric เดียวกัน และเวลาสูงสุดเท่ากัน บันทึกรุ่น Model, Provider, Hardware, Context, Tool, Prompt, เวลา, ค่าใช้จ่าย, Retry, Error และเวลาที่มนุษย์ตรวจ

โจทย์ตัวอย่างที่วัดได้คือ “สร้างรายงานเปรียบเทียบวิธีรัน Local LLM สำหรับทีม 5 คน โดยมีแหล่งปฐมภูมิ ตารางต้นทุน Threat Model และ Script ตรวจสเปก” Deliverable ต้องมีไฟล์จริง ลิงก์เปิดได้ ตัวเลขตรวจซ้ำได้ และ Script รันผ่าน

Rubric อาจแบ่งเป็น Accuracy 30, Completeness 20, Reproducibility 15, Safety 15, Human Review Time 10 และ Cost 10 คะแนน การให้คะแนนต้องมีหลักฐาน ไม่ใช้ความรู้สึกว่า Agent “ดูฉลาด”

จนกว่าจะทำการทดลองนี้ บทความควรใช้คำว่า สำรวจจากเอกสาร ไม่ใช้ “รีวิวแล้ว”, “แนะนำ”, “เร็วกว่า” หรือ “คุ้มกว่า”

ความปลอดภัย ต้นทุน และข้อจำกัด

Agent ที่มี Terminal และ File Access ไม่ใช่ Chatbot ที่ตอบผิดแล้วจบ มันอาจแก้ไฟล์ ลบข้อมูล เรียก API หรือส่ง Secret ออกไปได้ การสร้าง Subagent เพิ่มคือการเพิ่มเส้นทางที่ข้อมูลและการกระทำไหลผ่าน

Threat Model ที่ควรเริ่มจากสินทรัพย์

ถามก่อนว่าเราปกป้องอะไร: Source Code, API Key, เอกสารลูกค้า, Production Database, บัญชี Cloud หรือชื่อเสียงจากการเผยแพร่ จากนั้นดูว่า Tool ใดแตะสินทรัพย์เหล่านั้นได้

ภัยสำคัญได้แก่ Prompt Injection ในหน้าเว็บหรือเอกสาร, Tool Permission กว้างเกินไป, Agent เชื่อผลจาก Agent อื่น, การรันคำสั่งทำลายข้อมูล, MCP Server ที่ไม่น่าเชื่อถือ, Dependency ถูกฝังโค้ดอันตราย, Secret ปรากฏใน Log และ Recursive Delegation ที่เพิ่มค่าใช้จ่าย

เอกสาร Hermes ระบุระบบอนุมัติคำสั่งอันตราย Deny Rule, Write Safety และ Container Backend แต่ Guardrail ไม่ควรถูกอธิบายเป็นความปลอดภัยสมบูรณ์ เอกสารเองเตือนว่า Write Guard บางส่วนป้องกัน Tool เขียนไฟล์โดยตรง แต่ Terminal ที่รันสิทธิ์ผู้ใช้เดียวกันยังเป็นอีกเส้นทางหนึ่ง Container จึงเหมาะเมื่ออยากแยกผลกระทบจาก Host และต้องจำกัด Secret ที่ Forward เข้า Container

Human Approval Gate

การกระทำต่อไปนี้ควรหยุดให้มนุษย์อนุมัติอย่างชัดเจน

• ส่งอีเมลหรือข้อความภายนอก
• โพสต์หรือเผยแพร่เนื้อหา
• ลบหรือย้ายไฟล์จำนวนมาก
• Merge, Push หรือสร้าง Release
• ใช้ Credential หรือข้อมูลลูกค้า
• เรียก API ที่มีค่าใช้จ่ายสูง
• แก้ Production หรือ Infrastructure
• ส่งข้อมูลไปยัง Model/MCP ภายนอก

Approval ต้องอยู่ก่อนการกระทำ ไม่ใช่ให้ Agent ทำแล้วค่อยรายงาน และการอนุมัติควรแสดง Target, Diff, Cost และผลกระทบที่คาด ไม่ใช่ปุ่ม “ยอมรับ” ที่ไม่บอกว่าจะเกิดอะไร

ต้นทุนที่มองไม่เห็น

Multi-agent เพิ่ม Model Calls, Context ที่ส่งซ้ำ, Search, Retry, Reviewer, Log, Storage และเวลาที่ Parent รวมผล หากใช้ Local Model ยังมีค่าไฟ VRAM และเวลารอ หากใช้ Cloud อาจติด Rate Limit และค่าใช้จ่ายตาม Token หรือ Credit

ต้นทุนของมนุษย์ก็สำคัญ หาก Reviewer ส่งรายงานยาว 20 หน้าแต่ไม่มี Priority เจ้าของอาจใช้เวลาตรวจมากกว่าทำเอง จึงควรกำหนด Output ให้คืน Blocker ก่อน รายละเอียดรองทีหลัง

วิธีลดต้นทุนคือใช้ Script กับงานเชิงกล ใช้ Agent เท่าที่จำเป็น ลด Context ให้เฉพาะงาน ใช้โมเดลเล็กกับงานที่มี Schema ชัด จำกัด Iteration และ Concurrency, Cache ผลค้นหา และให้ Parent สังเคราะห์ครั้งเดียว

เมื่อไรไม่ควรใช้ Multi-agent

ไม่ควรใช้เมื่อ Tool Call ครั้งเดียวจบ งานสั้นเกินไป งานมีลำดับต่อเนื่องแน่นมาก ทุก Agent ต้องอ่าน Context ชุดเดียวกัน ไม่มีวิธีรวมผล ไม่มีเกณฑ์ตรวจ หรือความเสี่ยงจากการให้สิทธิ์สูงกว่าประโยชน์

ตัวอย่างเช่นการเปลี่ยนชื่อคอลัมน์ 20 จุดในไฟล์เดียวอาจใช้ Script หรือ Agent ตัวเดียว การให้ Agent สามตัวแก้พร้อมกันเพิ่ม Merge Conflict โดยไม่เพิ่มความเข้าใจ

Checklist ก่อนเริ่ม

ด้านโจทย์

• ระบุ Deliverable ที่เปิดและตรวจได้
• มี Baseline แบบ Agent ตัวเดียว
• แยกงานตาม Dependency แล้ว
• ทุก Subtask มี Success Criteria
• รู้ว่าเหตุใดต้องใช้การตีความแทน Script

ด้าน Context

• Subagent ได้ Goal และ Background ที่จำเป็น
• ระบุไฟล์ แหล่งข้อมูล วันที่ และ Version
• บอกสิ่งที่ห้ามเปลี่ยน
• กำหนด Output Contract เดียวกัน
• มี Escalation Rule เมื่อข้อมูลไม่พอ

ด้านความปลอดภัย

• จำกัด Tool ตาม Least Privilege
• จำกัด Root/Folder ที่เขียนได้
• แยก Secret ออกจาก Context ที่ไม่จำเป็น
• ใช้ Container หรือ Environment ที่เหมาะกับความเสี่ยง
• มี Approval ก่อน External Side Effect
• ตรวจ MCP, Skill และ Dependency ก่อนติดตั้ง

ด้านต้นทุนและการหยุด

• จำกัด Concurrency, Depth, Iteration และ Timeout
• มี Budget ต่อ Run
• ระบุ Stop Rule เมื่อ Retry ซ้ำ
• บันทึก Model Call, Tool Call และ Error
• พร้อมกลับไปใช้ Agent ตัวเดียวหากไม่คุ้ม

ด้าน Verification

• ตรวจไฟล์จริง ไม่เชื่อคำว่า “สร้างแล้ว”
• ตรวจ Test Output และ Exit Code
• เปิด Source URL และเทียบ Claim
• ตรวจ Diff ว่าอยู่ใน Scope
• ให้ Reviewer ใช้ Rubric ที่ต่างจาก Generator
• ให้มนุษย์เป็นผู้อนุมัติขั้นสุดท้าย

คำถามที่พบบ่อย

Hermes Agent คืออะไร

Hermes Agent คือระบบ Agent แบบเปิดจาก Nous Research ที่เชื่อมโมเดลภาษาเข้ากับ Tool, Terminal, File, Web, Memory, Skills, MCP และการ Delegation ผู้ใช้กำหนด Provider, Endpoint, Environment และ Workflow ได้มากกว่าผลิตภัณฑ์ Agent สำเร็จรูป แต่ต้องรับผิดชอบการติดตั้ง ความปลอดภัย และการตรวจผลมากขึ้นด้วย

Subagent เห็น Conversation ของ Parent หรือไม่

ไม่ควรสมมุติว่าเห็น เอกสาร Hermes ระบุว่า Subagent เริ่มด้วย Context ใหม่และได้รับข้อมูลจาก Goal กับ Context ที่ Parent ส่งให้ นี่ทำให้ Parent ต้องสร้าง Context Package ที่ครบ หากอ้างว่า “แก้ปัญหาเดิม” โดยไม่ส่ง Error, File และ Constraint Agent ลูกอาจตีความผิด

Multi-agent ดีกว่า Agent ตัวเดียวหรือไม่

ไม่เสมอไป มันมีประโยชน์เมื่องานแยกเป็นส่วนอิสระ ต้องใช้ความเชี่ยวชาญต่างกัน หรือต้องมี Generator–Reviewer แต่จะด้อยลงเมื่องานสั้น ทุกส่วนพึ่งกันแน่น หรือไม่มีวิธีรวมและตรวจผล ให้เทียบกับ Baseline ก่อนเสมอ

Hermes ใช้กับ Local LLM ได้หรือไม่

เอกสารทางการรองรับ Custom Endpoint ที่เข้ากันได้และยกตัวอย่างระบบ Local หลายแบบ แต่โมเดลต้องรองรับ Tool Calling และ Context ที่เหมาะสม คำว่า Local ไม่รับประกันความเป็นส่วนตัว หาก Web Tool, MCP หรือ Model Call บางส่วนยังส่งข้อมูลออกนอกเครื่อง

ChatGPT Work เป็น Orchestration Layer หรือไม่

ในเชิงประสบการณ์ Work รับบริบท วางแผน ทำงานหลายขั้น และสร้าง Deliverable จึงเปรียบเป็น Orchestration as a Product ได้ แต่เราไม่ควรอนุมานจำนวน Agent หรือโครงสร้างภายในที่ OpenAI ไม่ได้เปิดเผย เปรียบเทียบนี้ใช้ช่วยตัดสินใจด้านผลิตภัณฑ์ ไม่ใช่ Reverse-engineer สถาปัตยกรรม

ใช้ Claude Model ใน Hermes เหมือน Claude Code หรือไม่

ไม่เหมือนโดยอัตโนมัติ Model เป็นเพียงส่วนหนึ่ง Runtime, Tool, Permission, Prompt, Memory, Hook และ Subagent behavior ยังเป็นของระบบที่ห่อโมเดล Claude Code เป็นผลิตภัณฑ์ Agentic Coding ที่มี Agent Loop และ Extension ของตนเอง

ใช้ Codex ผ่าน Hermes ดีกว่าใช้โดยตรงหรือไม่

ไม่เสมอไป สำหรับงาน Coding ใน Repository การใช้ Codex โดยตรงมักลดชั้นและง่ายกว่า Hermes มีเหตุผลเมื่อ Coding เป็นส่วนหนึ่งของ Workflow ข้ามระบบ และเมื่อมี Integration ทางการหรือ Adapter ที่เราทดสอบแล้ว อย่านำ GitHub Issue ที่เสนอ Feature มาเขียนเป็นความสามารถปัจจุบัน

ควรเริ่มจากกี่ Agent

เริ่ม Parent หนึ่งตัวก่อน เมื่อพบ Bottleneck ที่ชัด เพิ่ม Subagent หนึ่งตัว เช่น Researcher หรือ Reviewer วัดผล แล้วค่อยเพิ่มตัวที่สอง การเริ่มด้วย Agent Tree หลายชั้นทำให้แยกไม่ออกว่าคุณภาพดีหรือเสียเพราะจุดใด

บทสรุป

กลับมาที่ฉากแรก—ผู้ช่วยคนเดียวที่เปิดหน้าต่าง 40 บาน—คำตอบไม่ใช่จ้างผู้ช่วยเพิ่มอีก 40 คนทันที แต่คือจัดงานให้เห็นว่าอะไรควรอยู่ด้วยกัน อะไรควรแยก และผลของแต่ละงานตรวจได้อย่างไร

Hermes Agent ให้อิสระในการสร้างระบบนั้น ผู้ใช้เลือกโมเดล Tool, Memory, Skill, MCP, Environment และ Subagent ได้ จึงเหมาะกับคนที่ต้องการควบคุม Architecture และยอมรับภาระดูแล ส่วน ChatGPT Work ลดภาระการประกอบระบบเพื่อมุ่งไปที่ Deliverable ขณะที่ Codex และ Claude Code เหมาะกับ Software Engineering โดยตรง และต่างก็มี Agent Workflow ของตัวเองมากกว่าภาพจำ “ผู้ช่วยเขียนโค้ด”

Decision Rule ที่ควรจำมีเพียงสามบรรทัด

1. ถ้างานเดียวทำได้และตรวจง่าย ใช้ Agent ตัวเดียว
2. ถ้างานแยกอิสระหรือควรมีผู้ตรวจ เพิ่ม Subagent เท่าที่จำเป็น
3. ถ้ายังไม่มี Verification, Permission และ Stop Rule อย่าเพิ่มความลึกของ Agent Tree

Multi-agent ที่ดีไม่ได้วัดจากจำนวน Agent แต่วัดจากความชัดของ Handoff คุณภาพของหลักฐาน และความสามารถในการหยุดก่อนความเสียหายเกิดขึ้น

Sources

แหล่งปฐมภูมิ ตรวจเมื่อ 4 สิงหาคม 2026

1. Hermes Agent Documentation
2. Hermes Agent — Subagent Delegation
3. Hermes Agent — Delegation & Parallel Work
4. Hermes Agent — Configuration
5. Hermes Agent — Configuring Models
6. Hermes Agent — AI Providers
7. Hermes Agent — Skills System
8. Hermes Agent — MCP
9. Hermes Agent — Security
10. Nous Research/hermes-agent Repository
11. OpenAI — ChatGPT Work and Codex
12. OpenAI — ChatGPT Work
13. OpenAI — Codex
14. Anthropic — Claude Code Overview
15. Anthropic — Extend Claude Code
16. Hermes Agent — Run Hermes Locally with Ollama
17. Ollama Library — Gemma 4