คู่มือฉบับสมบูรณ์สำหรับ /goal

/goal ไม่ใช่ฟีเจอร์ มันคือ primitive

HTTP คือ primitive JSON คือ primitive และตอนนี้ /goal กำลังกลายเป็น primitive สำหรับ coding agents

เมื่อไม่กี่สัปดาห์ที่ผ่านมา OpenAI's Codex CLI ได้เพิ่ม /goal เป็นวิธีในการมอบงานให้กับ coding worker โดยมีสถานะที่กำหนดว่าเสร็จสิ้นแล้ว Claude Code ก็เพิ่มเข้ามาในสัปดาห์นี้

Hermes Agent ซึ่งเป็น orchestrator ที่ฉันรันบน Mac Mini เพื่อประสานงานระหว่าง coding workers มี /goal ติดตั้งอยู่แล้วตั้งแต่แรก

ตอนนี้ฉันมี builder, reviewer และ orchestrator ที่ยอมรับรูปแบบคำสั่งเดียวกัน แม้ว่าพวกมันจะไม่มีอะไรอื่นร่วมกันเลย

ถ้าคุณเคยเห็นแค่ /goal ถูกใช้เป็น prompt ที่สวยหรู คุณอาจจะพลาดสิ่งที่มันเปลี่ยนไป

/goal จริงๆ คืออะไร

prompt ทั่วไปจะขอให้ agent ตอบกลับครั้งถัดไป คุณอ่านสิ่งที่ส่งกลับมา ตัดสินใจว่าถูกต้องหรือไม่ แล้วผลักดัน agent ไปยังขั้นตอนถัดไป คุณเป็นคนคอยควบคุมทุกเทิร์น

/goal กลับด้านสิ่งนั้น คุณเขียนว่าสถานะ "เสร็จ" เป็นแบบไหน ส่งครั้งเดียว แล้ว agent จะทำงานไปจนกว่าจะถึงเป้าหมาย นี่คือตัวอย่างจริง:

1/goal สร้างแอปตามที่อธิบายไว้ใน SPEC.md เสร็จหมายถึงเทสผ่าน,
2build ผ่าน, README ถูกต้อง และ git status แสดงเฉพาะไฟล์โปรเจกต์ที่เกี่ยวข้องเท่านั้น

เป้าหมายจะยังคง active จนกว่าจะสำเร็จ, หยุดชั่วคราว, ถูกบล็อก, ถูกล้าง หรือหมดงบประมาณ

นี่ต่างจากการใส่คำว่า "goal" ในคำสั่งครั้งเดียวปกติ ถ้าคุณเขียนว่า codex exec 'goal: build the app' นั่นก็ยังเป็นแค่ prompt ที่มีป้ายชื่อ primitive ที่แท้จริงอยู่ใน interactive worker session คุณเปิด CLI คุณส่ง /goal แล้วคุณก็เดินจากไป

การเปลี่ยนแปลงคือจากการสั่ง (prompting) ที่คุณขับ ไปสู่การมอบหมาย (assigning) ที่ตัว agent ขับไปสู่เป้าหมายที่คุณกำหนดไว้

GIF

สามเครื่องมือที่ปัจจุบันรองรับ /goal

เครื่องมือสามตัวที่รองรับ /goal ไม่ใช่สิ่งเดียวกันทั้งหมด ดังนั้นจึงควรระบุให้ชัดเจน

Codex คือ coding CLI ของ OpenAI แข็งแกร่งในการนำไปปฏิบัติ โดยเฉพาะเมื่อมี spec ที่ชัดเจน /goal คือวิธีที่คุณให้ spec นั้นแก่ Codex

Claude Code คือ coding CLI ของ Anthropic แข็งแกร่งในสิ่งที่ตรงกันข้าม: การหาว่ามีอะไรผิดปกติกับโค้ดที่ดูเหมือนถูกต้อง การปฏิบัติตาม spec, ปัญหาด้านความปลอดภัย, สถานะข้อผิดพลาด, ช่องโหว่ด้านความปลอดภัย /goal คือวิธีที่คุณชี้ไปที่โค้ดและขอให้ตรวจสอบ

Hermes Agent เป็นเครื่องมือที่แตกต่างไปโดยสิ้นเชิง ไม่ใช่ coding worker แต่เป็น orchestrator ที่ประสานงานระหว่าง coding workers เช่นสองตัวด้านบน /goal คือวิธีที่ Hermes ส่งมอบงานให้กับเครื่องมือที่เหมาะสมกับงานนั้น และยังเป็นวิธีที่ฉันบอก Hermes ว่าฉันต้องการอะไรตั้งแต่แรก

สิ่งที่สำคัญไม่ใช่แค่ว่าตัวใดตัวหนึ่งเพิ่ม /goal เข้ามา แต่เป็นว่าสามทีมที่แตกต่างกันได้มาบรรจบกันที่ primitive เดียวกัน และการบรรจบกันนี้เองที่ทำให้สามารถนำพวกมันมาประกอบกันได้

GIF

การตั้งค่า

ครั้งแรกที่ฉันต้องการ Codex และ Claude Code บน Mac Mini ที่รัน Hermes ฉันไม่ได้ติดตั้งด้วยมือ ฉันส่งข้อความถึง Hermes ขอให้มันติดตั้งทั้งสองอย่างและเข้าสู่ระบบให้ มันจัดการส่วนที่เหลือ

นั่นคือเวิร์กโฟลว์ตอนนี้ คุณไม่ต้องพิมพ์คำสั่งติดตั้ง การตั้งค่าก็เป็นแค่เป้าหมายอีกอันหนึ่ง

ถ้าคุณยังไม่มี orchestrator ที่ทำงานอยู่ หน้าเว็บติดตั้งของ Codex และ Claude Code ก็ทำตามได้ง่ายพอ แต่เมื่อคุณมีแล้ว คุณไม่ควรตั้งค่าเครื่องมืออื่นด้วยมืออีกต่อไป จุดประสงค์ของการมี orchestrator คืองานกลไกจะไม่ใช่ของคุณอีกต่อไป

สิ่งที่ Hermes เพิ่มเติมเหนือ /goal

/goal ดิบๆ มีประโยชน์ในตัวมันเอง แต่มันทิ้งปัญหาการประสานงานไว้

ถ้า Codex กำลังรันใน terminal หนึ่ง และ Claude Code กำลังรันในอีก terminal หนึ่ง คุณต้องจำว่ากระบวนการไหนกำลังทำอะไรอยู่ คุณต้องตรวจสอบ logs คุณต้องส่งผลการตรวจสอบจากเครื่องมือหนึ่งไปยังอีกเครื่องมือหนึ่งด้วยตนเอง

Hermes เปลี่ยนการรันแบบกระจัดกระจายเหล่านี้ให้เป็นเวิร์กโฟลว์:

1. คุณส่งข้อความถึง Hermes (ในกรณีของฉัน ผ่าน Telegram จากโทรศัพท์)
2. Hermes สร้าง goal cards บน Kanban board
3. Hermes เลือก worker ที่เหมาะสมสำหรับแต่ละ card
4. Worker รันเป้าหมายในพื้นหลัง
5. การ์ดเก็บ process id, PID, repo และเกณฑ์ที่เสร็จสิ้น
6. เมื่อ build พร้อมแล้ว Hermes ส่งมอบ repo ให้ reviewer
7. ถ้าการตรวจสอบถูกบล็อก Hermes จะส่งผลการตรวจสอบกลับเป็น fix goal
8. Hermes ยืนยันผลลัพธ์สุดท้ายโดยตรวจสอบ filesystem, tests, build และ git state

บอร์ดคือสิ่งที่ /goal กลายเป็นเมื่อมี orchestrator อยู่ด้านบน ทุกเป้าหมายมีการ์ด ทุกการ์ดมีสถานะ ทุกการส่งมอบทิ้งร่องรอยไว้ แทนที่จะตามล่าหา terminals คุณดูงานเคลื่อนที่ไปตามคอลัมน์บนโทรศัพท์ของคุณ

สามบทบาท

เครื่องมือเปลี่ยนไป แต่บทบาทไม่เปลี่ยน

Orchestrator. เป็นเจ้าของ control loop การแบ่งงาน (task decomposition), การเลือก worker, Kanban cards, กระบวนการพื้นหลัง, การพึ่งพา, การตรวจสอบครั้งสุดท้าย, สรุปผลให้ผู้ใช้ ในระบบของฉัน คือ Hermes

Builder. รับ spec และสร้างโค้ดที่ทำงานได้ การนำไปปฏิบัติคือคอขวดที่บทบาทนี้แก้ไข Codex มักจะแข็งแกร่งในด้านนี้

Reviewer. อ่านสิ่งที่ builder สร้างขึ้นและค้นหาสิ่งที่ผิดพลาด ความถูกต้องคือคอขวด Claude Code มักจะแข็งแกร่งในด้านนี้

การทำงานจริง ตั้งแต่ต้นจนจบ

ฉันให้ Hermes agent ทำเป้าหมายนี้:

1/goal สร้าง CLI tool ที่ค้นหา X mentions ของฉันและแจ้งเตือนฉันเมื่อ
2มีอะไรระเบิด

Hermes แบ่งคำขอออกเป็นหกการ์ด

Shubham Saboo

@Saboo_Shubham_

·

12 พ.ค.

Codex /goal สร้างมัน

Claude Code /goal ตรวจสอบและปรับปรุงมัน

Hermes /goal จัดการการประสานงานและการส่งมอบ

ทั้งหมดติดตามบน Kanban Board เดียว และ agents ยังคงรันวน loop

58

61

852

88K

การ์ด 1: Spec. Hermes เขียน SPEC.md เอง โดยจับ stack, repo path, ข้อจำกัดแบบ read-only, ข้อกำหนดในโหมด mock, tests และคำสั่งตรวจสอบ เป็นเจ้าของโดยบทบาท PM

การ์ด 2: Codex สร้าง. Codex รัน /goal กับ SPEC.md มันสร้างไฟล์โปรเจกต์, นำ UI และ backend ไปใช้, เพิ่ม tests และทำให้แอปอยู่ในสถานะที่ผ่าน ประมาณ 15 นาที เมื่อเสร็จแล้ว npm test ผ่าน, npm run build ผ่าน และ git status แสดงเฉพาะไฟล์ใหม่ที่เกี่ยวข้องเท่านั้น

การ์ด 3: Claude Code ตรวจสอบ. Claude Code รัน /goal เพื่อตรวจสอบสิ่งที่ Codex สร้าง ตรวจสอบการปฏิบัติตาม spec, ความปลอดภัยแบบ read-only, การจัดการ API key, สถานะข้อผิดพลาด, tests, ความมีประโยชน์ของ UI, bugs และประเด็นด้านความปลอดภัย ผลลัพธ์: PASS, ไม่มีปัญหาที่บล็อก

การ์ด 4: Codex fix loop. ข้ามไป เพราะการตรวจสอบผ่าน การ์ดยังคงมีความสำคัญแม้จะถูกข้าม มันแสดงให้เห็นว่า Hermes สามารถจำลองงานแบบมีเงื่อนไขได้ ถ้า Claude Code บล็อกไว้ Hermes จะส่งผลการตรวจสอบกลับไปให้ Codex เป็น /goal ใหม่

การ์ด 5: Claude Code ตรวจสอบครั้งสุดท้าย. ข้ามไปด้วยเหตุผลเดียวกัน

การ์ด 6: Hermes สรุปผลสุดท้าย. แอปที่ใช้งานได้ที่ local path, UI และ API ตรวจสอบแล้วในโหมด mock Codex สร้างมันด้วย /goal Claude Code ตรวจสอบมันด้วย /goal และส่งคืน PASS

ทั้งหมดนี้มาจากข้อความเดียว เครื่องมือสามตัวที่แตกต่างกันทำงานจริง แต่ฉันคุยกับแค่ Hermes เท่านั้น

กฎการตรวจสอบ

Hermes ไม่เคยเชื่อรายงานตนเองของ Codex หลังจาก Codex ทำเครื่องหมายว่า build เสร็จแล้ว Hermes รันคำสั่งด้วยตนเอง:

1npm test         # 17 tests passed
2npm run build    # vite build passed

verifier คือสิ่งที่ทำให้ /goal กลายเป็นสัญญา (contract) แทนที่จะเป็นเพียงคำสัญญา (promise) อย่าเชื่อรายงานตนเองของ worker เป็นที่สุด เชื่อ verifier

Coding agents มีความมั่นใจสูง พวกมันจะบอกคุณว่า build ผ่านทั้งที่ build ไม่เคยถูกรัน พวกมันจะบอกคุณว่า tests ผ่านทั้งที่พวกมันเขียน tests ที่ไม่เคยถูก execute verifier ปิดช่องว่างนั้น

ถ้าไม่มี verification /goal ก็เป็นแค่ prompt ที่สวยหรู แต่เมื่อมี verification มันจะกลายเป็นสัญญา

GIF

การรันหลายเป้าหมาย

คุณสามารถรัน /goal หลายรายการพร้อมกันได้ แต่คุณไม่สามารถชี้ coding workers หลายตัวไปที่ไฟล์เดียวกันโดยไม่คิดก่อน

ค่าเริ่มต้นของฉันคือ builder หลักหนึ่งตัวต่อหนึ่ง repo ถ้าฉันต้องการ parallelism ฉันจะเพิ่มตามขอบเขตที่ชัดเจน repos ที่แตกต่างกัน, branches ที่แตกต่างกัน, git worktrees, packages ที่แยกจากกัน, docs vs code, tests vs implementation ทุกที่ที่ workers สองตัวไม่สามารถก้าวก่ายกันได้

รูปแบบที่ไม่ดีคือ workers สามคนแก้ไขไฟล์เดียวกันใน repo เดียวกัน คุณจะเจอ conflicts, การเขียนทับบางส่วน และ worker หนึ่งตัวเงียบๆ ทำงานของอีกตัว

รูปแบบที่ดีกว่าคือ writer หนึ่งตัวต่อหนึ่งไฟล์ในเวลาที่กำหนด Builder เขียน, reviewer อ่านเท่านั้น, fix goals ถูกจำกัดขอบเขตเฉพาะการแก้ไข หรือรัน builders สามตัวในสาม worktrees บนสามแนวทางที่แข่งขันกัน และให้ orchestrator เลือกแนวทางที่ดีที่สุด

บอร์ดคือสิ่งที่ทำให้สิ่งนี้ใช้งานได้จริง ถ้าไม่มีมัน workers พื้นหลังที่ทำงานพร้อมกันจะกลายเป็นความวุ่นวายใน terminal

สิ่งที่เปลี่ยนไปสำหรับฉัน

กรอบความคิดที่เป็นประโยชน์ไม่ใช่ "ฉันสามารถรัน agents ในพื้นหลังได้"

แต่มันคือข้อความหนึ่งเปลี่ยนเป็นไปป์ไลน์ข้ามเครื่องมือ coding สามตัวที่แตกต่างกัน และฉันดูทุกอย่างเคลื่อนที่ข้ามบอร์ดหนึ่งเดียว

คุณหยุดนั่งรอ agent ตัวหนึ่งใน terminal จนเสร็จ และเริ่มจัดการคิวงานที่มีสถานะที่มองเห็นได้

ถ้า Codex และ Claude Code ต่างคิดค้นรูปแบบการส่งมอบงานของตัวเองขึ้นมา ก็จะไม่มี orchestrator ใดที่สามารถกำหนดเส้นทางระหว่างกันได้ บอร์ดนั้นน่าประทับใจ แต่ primitive ทำให้บอร์ดมีประโยชน์ยิ่งขึ้นไปอีก

workers สามารถเปลี่ยนได้ แต่ primitive ยังคงเหมือนเดิม เครื่องมือ coding ตัวถัดไปที่นำ /goal มาใช้ จะเข้าร่วมไปป์ไลน์นี้โดยที่ฉันไม่ต้องเปลี่ยนแปลงอะไรเลย ฉันแค่กำหนดเส้นทางงานไปยังมัน

นั่นคือสิ่งที่ primitive ที่ดีทำ

สำหรับเคล็ดลับเจ๋งๆ และไอเดียที่น่าสนใจเพิ่มเติมเกี่ยวกับ Hermes, OpenClaw, Claude Code, Codex และทีม agent อื่นๆ ที่ทำงาน 24/7

ติดตาม → @Saboo_Shubham_