ณ เวลาที่เขียนบทความนี้ Artie มีทีมทั้งหมด 17 คน ทุกคนทำงานเคียงข้าง Hermes ซึ่งเป็น AI agent harness แบบ open-source จาก @NousResearch มันรันอยู่บนเครื่องกายภาพเพียงเครื่องเดียวในเยอรมนี มีบุคลิกเฉพาะตัวสำหรับแต่ละทีม และจะ "ฝัน" ในตอนกลางคืน
นี่คือเรื่องราวที่ทำให้มันกลายเป็นแบบนี้
จุดเริ่มต้นมาจาก WhatsApp contact ของวิศวกรคนเดียว
เมื่อไม่กี่เดือนก่อน หนึ่งในวิศวกรของเรา (Ani, @anirudhsriramzz) ได้ใช้งาน Hermes สำหรับตัวเอง เป็นแค่การตั้งค่าส่วนตัวที่เขาคุยกับมันผ่าน WhatsApp
ในช่วงเวลาเดียวกัน Robin CTO ของเรา กลับมาจากงาน hackathon ที่เพื่อนของเขาโชว์ให้ดูว่า agent หลายตัวสามารถทำงานแทนคนได้จริง คำถามที่เขา带回มาก็คือ: เราจะทำให้ทุกคนที่ Artie ใช้ประโยชน์จากสิ่งนี้ได้บ้างไหม ไม่ใช่แค่เฉพาะทีมวิศวกร?
เราลองพิจารณา OpenClaw ก่อน มันดี แต่เห็นได้ง่ายว่า agent มักจะออกนอกลู่นอกทางและทำอะไรที่ไม่ได้รับคำสั่ง เราจึงต้องการ guardrails (มาตรการป้องกัน) ก่อนที่จะขยายขนาด ดังนั้นเราจึงเลือก Hermes และเริ่มคิดว่าจะสร้าง guardrails อย่างไร
สมองที่มีผ้าปิดตา
วิธีที่เราคิดเกี่ยวกับเรื่องนี้คือ: ทุก lab ต่างส่งมอบ "สมอง" ออกมา คุณสามารถถามอะไรก็ได้และมันจะตอบ ถามคำถามเดิมห้าครั้ง คุณจะได้คำตอบห้าแบบ ซึ่งล้วนดูสมเหตุสมผลแต่มีรูปแบบต่างกัน
นั่นใช้ได้สำหรับหน้าต่างแชททั่วไป แต่มันเป็นปัญหาเมื่อคุณอยากให้สมองนั้น "ทำงาน" จริงๆ ถ้า sales engineer ขอประเมินความเสี่ยงจาก customer threads ที่เปิดอยู่ 25 รายการ พวกเขาต้องการรูปแบบผลลัพธ์ที่เหมือนกันทุกครั้ง เพื่อให้สามารถนำไปปฏิบัติ เปรียบเทียบรายสัปดาห์ และไว้วางใจระบบได้
ม้าแข่งสวมผ้าปิดตาเพื่อให้วิ่งตามเส้นทางโดยไม่สนใจฝูงชน Skills และ tools คือผ้าปิดตานั้น ส่วน harness คือวิธีการผูกมันไว้ Hermes, Codex, Claude Code และอื่นๆ ล้วนเป็นเวอร์ชันของแนวคิดเดียวกัน: วิธีกำหนดว่าโมเดลได้รับอนุญาตให้ทำอะไรได้บ้าง และผลลัพธ์ควรมีหน้าตาเป็นอย่างไร
เมื่อเราคิดในมุมนี้ โปรเจกต์ก็เปลี่ยนจาก 'ติดตั้ง chatbot' กลายเป็น 'สร้างผ้าปิดตาสำหรับแต่ละงานที่ Artie'
เซิร์ฟเวอร์ราคา $60 ในเยอรมนีรันทุกอย่าง
Robin และ Ani ตั้งค่า Hermes ตัวแรกเสร็จภายในประมาณสามชั่วโมงในวันหยุดสุดสัปดาห์หนึ่ง เราเช่าแพ็กเกจที่ถูกที่สุดบน Railway เปิดใช้ Hermes ด้วยโปรไฟล์ default เพียงหนึ่งตัว แล้วปล่อยให้ทีมวิศวกรใช้งานต่อ
ภายในห้าวัน เราก็ชนขีดจำกัดการใช้งานของ Railway ซ้ำแล้วซ้ำเล่า ทุก alert คือสัญญาณเตือนให้อัปเกรดแผน นี่คือบทเรียนแรกที่สำคัญ: ทันทีที่ทีมเริ่มนำ agent มาใช้อย่างจริงจัง ค่าใช้จ่ายจะไม่ดูเหมือนโปรเจกต์ข้างเคียงอีกต่อไป
โครงสร้างพื้นฐาน production ของเราอยู่บน AWS และยังคงอยู่ที่นั่น แต่สิ่งนี้เป็น sandbox ภายในสำหรับ agents ไม่ใช่ infrastructure สำหรับลูกค้า และเราอยากทดสอบว่าเราจะทำให้มันราคาถูกที่สุดได้แค่ไหน เราพบ Hetzner (@Hetzner_Online) บริษัท hosting สัญชาติเยอรมัน และซื้อเครื่องกายภาพในราคาปีละ $60 วันนี้ Hermes ทุกตัวที่ Artie รันอยู่บนเครื่องนั้น
เราเป็นบริษัทที่คล่องตัวและประหยัด คำถามหลักเรื่อง AI ที่ Artie คือ: เราจะทำให้ทีมมีความเป็น AI-native มากที่สุดได้อย่างไร โดยไม่เผาเงินทิ้ง? เครื่อง Hetzner คือคำตอบแรก
สิ่งที่เราต้องการจริงๆ
เมื่อมีเครื่องที่รับโหลดงานไหว เราก็นั่งลงและตัดสินใจว่า Hermes มีไว้เพื่ออะไร โดยมีเป้าหมายสองข้อ
ทุกคนต้องมีผู้ช่วย. วิศวกร, ฝ่ายขาย, ปฏิบัติการ, การตลาด, ดีไซน์ เวอร์ชัน junior ของตัวคุณเองที่ช่วยให้คุณทำผลงานได้มากขึ้น ไม่ใช่สิ่งที่มาแทนที่คุณ ความกลัวในอุตสาหกรรมคือ agents จะแย่งงาน ประสบการณ์ของเราตรงกันข้าม: เมื่อทุกคนมี agent ช่วย ทุกคนส่งงานได้เร็วขึ้นและรับงานที่ทำไม่ได้มาก่อน
มนุษย์ต้องอยู่ในลูปเสมอ. Hermes สามารถทำทุกอย่างที่ได้รับคำสั่ง แต่ก่อนที่ผลลัพธ์ใดๆ จะเข้าสู่ production, เอกสาร หรือถึงมือลูกค้า ต้องมีมนุษย์ตรวจสอบก่อน
คนเก่งเฉพาะด้าน Agent ก็ควรเป็นเช่นนั้น
ไม่มีใครในทีม 17 คนที่เก่งเพียงอย่างเดียว แต่ทุกคนมีความเชี่ยวชาญเฉพาะด้าน (spike) เราจ้างคนเพราะความเชี่ยวชาญนั้น
ดังนั้นเราจึงถามว่าทำไม agent ของเราไม่ควรเป็นแบบเดียวกัน วิศวกร junior ที่ไปเขียน copy การตลาดคือการเสียทรัพยากร นักการตลาด junior ที่เข้าไปแก้ codebase ยิ่งแย่กว่า เราออกแบบ agent ตามวิธีที่เราคิดเกี่ยวกับคน: ให้แต่ละตัวมี domain เฉพาะ, บุคลิก, และการเข้าถึงเครื่องมือที่จำเป็นสำหรับ domain นั้น
ผลลัพธ์คือครอบครัวของ Hermes profiles หนึ่งตัวต่อหนึ่งทีม
Hermes Plan และ Hermes Code เป็นของทีมวิศวกรรม Plan สำหรับ tech lead: ตัดสินใจว่าจะทำ A แล้วค่อย B หรือทำ A และ B ขนานกันแล้วค่อย C ทีหลัง พร้อมบันทึกไว้ Plan จะกระจายงานไปยัง Kanban board ส่วน Code จะรับ ticket ไป execute ใน background บน codebase ที่มีอยู่ สร้าง PRs และรอ มนุษย์จะ review PR และ merge เข้า master เฉพาะเมื่อผ่านการตรวจสอบเท่านั้น เมื่อหนึ่งงานเสร็จ มันจะ trigger งานถัดไปในแผนโดยอัตโนมัติ
ผลข้างเคียงที่ไม่มีใครคาดคิด: เวลาส่วนใหญ่ของทีมวิศวกรรมตอนนี้หมดไปกับการวางแผน สมัยก่อนคนอยู่กับ code และการ execute ตอนนี้พวกเขาอยู่กับ system design และการ review ส่วน Hermes Code จัดการส่วนตรงกลาง
Hermes Sales เตรียมตัวก่อน discovery call มันวิจัย prospect, วิเคราะห์ stack ปัจจุบันของพวกเขา และดึงบริบทล่าสุดของดีล เนื่องจากมันเข้าถึง docs และความรู้ทางวิศวกรรมของเราได้ มันจึงก้าวไปอีกขั้น: ถ้า prospect บอกว่าพวกเขากำลังย้ายข้อมูลด้วย tool ตัวหนึ่ง Hermes สามารถบอก rep ได้ว่า tool นั้นมักจะมีปัญหาตรงไหน เช่น schema drift ก่อนที่การสนทนาจะเริ่มด้วยซ้ำ
Hermes Design และ Hermes Code ทำงานร่วมกันช่วยให้ฝ่ายการตลาดออกแบบ, สร้าง, และ deploy landing pages โดยไม่ต้องดึงวิศวกรเข้ามา เว็บไซต์การตลาดของเราใช้ Next.js และเราเลิกใช้ CMS แล้ว Design ทำงานในระบบ component ที่มีอยู่ ตรวจสอบว่ามี component เดิมหรือไม่ก่อนสร้างใหม่ แล้วส่งต่อให้ Code implement
Hermes BizOps ดูแลงานปฏิบัติการประจำ: pipeline reviews, reconciliation, อัปเดต tracker, และหา exception ที่ต้องให้มนุษย์จัดการ
และมี default profile สำหรับทุกสิ่งที่ไม่เข้าข่ายข้างต้น
พวกเราส่วนใหญ่สื่อสารกับ agent เหล่านี้ผ่าน Slack บางคนใช้ Hermes desktop ไม่ว่าจะแบบไหน ทั้งหมดเปลี่ยนจาก reactive เป็น proactive: agents มี codebase, docs, CRM, และอินเทอร์เน็ตอยู่แล้ว จึงสามารถตอบจากแหล่งข้อมูลทุกที่โดยไม่ต้องรอให้ป้อน context
Skills ถูก versioning เหมือนโค้ด ตั้งแต่แรกเริ่ม
Profiles คือบุคลิก ส่วน Skills คือสิ่งที่ทำให้พวกมันมีความสามารถ
Skill คือขั้นตอนการทำงานที่นำกลับมาใช้ซ้ำได้สำหรับงานประเภทจริง: ควรเช็คอะไรก่อน, แหล่งข้อมูลใดที่น่าเชื่อถือ, รูปแบบผลลัพธ์เป็นอย่างไร, และวิธีตรวจสอบ เราเขียน skills ของเราเองตั้งแต่สัปดาห์แรกและเก็บไว้ใน Git repo ทุก Hermes อ่านจากที่นั่น เมื่อ skill เปลี่ยนแปลง มันคือการ commit ที่มีประวัติ ซึ่งทุก profile จะดึงไปใช้
เราตั้งใจที่จะไม่เขียน skills มากเกินไป มีล้านวิธีในการทำให้ AI ทำงานให้คุณ และอินเทอร์เน็ตส่วนใหญ่จะบอกให้คุณสร้างโรงงาน autonomous agents ที่ทำงานตลอด 24/7 ถ้าคุณมี tokens ไม่จำกัด ก็อาจทำได้ แต่เราไม่มี agent ที่พลิกดู skills หลายร้อยตัวเพื่อตัดสินใจว่าจะใช้อันไหน ทำให้เสีย tokens ไปกับการตัดสินใจ ดังนั้นเราตัดทุกอย่างที่ไม่คุ้มทุนอย่างชัดเจน และเราก็ยังตัดต่อไปเรื่อยๆ
กฎสุดท้ายคือ: ถ้าคุณค่าชัดเจน ต้นทุนก็คุ้มค่า ถ้าคุณค่าคลุมเครือ ก็ไม่สร้าง
Hermes ฝัน
Hermes มีระบบ cron คุณสามารถกำหนด task และความถี่ แล้วมันจะรันเอง
ได้รับแรงบันดาลใจจากงานของ Anthropic เรื่อง agent memory เราใช้มันเพื่อเลียนแบบสิ่งที่มนุษย์ทำ ในช่วง REM sleep สมองของคุณจะจัดเรียงเหตุการณ์ของวัน บางอย่างถูกเลื่อนสถานะเป็น long-term memory บางอย่างถูกลืม ปีที่คุณย้ายเมืองและเดินทางบ่อยจะจำได้ดีเพราะไม่มีอะไรซ้ำเดิม
ดังนั้นทุกคืน เมื่อไม่มีใครใช้งาน แต่ละ Hermes จะ "ฝัน" มันทบทวนสิ่งที่ทำในวันนั้น ตัดสินใจว่าอะไรมีประโยชน์และอะไรไม่มี เลื่อนสถานะส่วนที่มีประโยชน์เข้า memory และลดสถานะส่วนที่เหลือ จากนั้นส่งรายงานให้วิศวกรของเรา รายงานจะบอกว่า: ฉันทำผิดตรงนี้, ฉันทำผิดตรงนั้น, ฉันแก้ไขแล้ว, ฉันเก็บการแก้ไขไว้แล้ว, และฉันลืมนิสัยที่ก่อให้เกิดความผิดพลาดนั้นแล้ว
เมื่อผ่านไปหลายสัปดาห์ แต่ละ profile จะมีความเห็นที่ชัดเจนขึ้นเกี่ยวกับสิ่งที่ควรและไม่ควรทำสำหรับทีมของมัน เราไม่ได้โปรแกรมความเห็นเหล่านั้น พวกมันเกิดจากการ "ฝัน"
ทำไมเราถึงรัน harness ของเราเอง
ผู้คนถามว่าทำไมเราไม่ใช้ Cursor, Codex, หรือ Claude Code เฉยๆ
เราสามารถทำได้ และในทางเทคนิคเราสามารถย้าย workload ได้พรุ่งนี้เลย แต่เพราะเรา run และ operate Hermes เอง โมเดลที่อยู่เบื้องหลังจะเป็นของใครก็ได้ ถ้า lab ใด lab หนึ่งขึ้นราคาในสัปดาห์หน้า เราก็เปลี่ยน โปรไฟล์ของเรามีเสถียรพอที่การเปลี่ยนโมเดลจะไม่ทำให้มันพัง วันจันทร์เราอาจใช้โมเดลของ Anthropic; ถ้าราคาขยับ วันศุกร์เราอาจย้ายไป OpenAI
เหตุผลที่สองคือฟีเจอร์ ถ้า Cursor ไม่รองรับ authentication ที่คุณต้องการ หรือทำ error เดิมซ้ำๆ ใน codebase ของคุณ คุณต้องยื่น ticket แล้วรอ เมื่อ Hermes ต้องการอะไรบางอย่าง เราสร้างมันเอง Hermes เป็นส่วนหนึ่งของ Artie เชื่อมต่อกับระบบของเราเหมือน internal tool อื่นๆ ไม่ใช่สิ่งที่เราต่อพ่วงแล้วหวังว่ามันจะทำงานได้
งานวิศวกรรม AI แพงมากในปัจจุบันเพราะเศรษฐกิจของ tokens ยังไม่ลงตัว วันหนึ่งการรันสิ่งเหล่านี้จะเกือบฟรี จนกว่าจะถึงเวลานั้น การเป็นเจ้าของ harness คือวิธีที่เราควบคุมค่าใช้จ่าย
สถานะปัจจุบันและก้าวต่อไป
Hermes น่าจะเสร็จไปแล้ว 85 ถึง 90 เปอร์เซ็นต์ มันทำงานจริงทุกวัน แม้ว่าการผ่านครั้งแรกอาจไม่ใช่การผ่านที่ดีที่สุด
ดังนั้นเราจึงลงทุนใน evals ทุกครั้งที่ Hermes ได้รับคำถามและผลิตคำตอบ เราอยากรู้ว่าอะไรใช้เวลาเท่าไหร่, เรียก skills ไหนบ้าง, tools ตัวไหนล้มเหลวและทำไม เรา self-host Arize Phoenix ซึ่งเป็น open source เพื่อให้ได้ข้อมูลนี้โดยไม่ต้องซื้อ tool ใหม่ Traces จาก Hermes ส่งเข้า Phoenix และ Phoenix จะบอกเรา: task นี้เรียก 5 skills และ 2 tools, tool นี้ใช้เวลานานที่สุด, ตัวนี้ล้มเหลว, นี่คือสาเหตุ
ใต้ชั้นนั้นเราส่ง telemetry ผ่าน Datadog: จำนวน tokens ที่ใช้, success rate ต่อ task, alerts ไปยัง on-call หาก Hermes ล่มหรือ memory store เต็ม ทุก task รันใน sandbox และเราสร้างระบบ pruning เองที่ล้าง sandboxes ทุกวัน
จุดประสงค์ของทั้งหมดนี้คือเราไม่ต้องเดาอีกต่อไปว่าการเปลี่ยนแปลงทำให้ Hermes ดีขึ้นหรือไม่ เราเปลี่ยน skill, รับรายงาน ถ้าดีขึ้นก็คงไว้ ถ้าแย่ลงก็ revert
เรายังเขียน documentation ลงใน server ของ Hermes เองโดยตรง: config ของคุณคืออะไร, คุณได้รับอนุญาตให้ทำอะไร, ข้อมูลหมายถึงอะไร Hermes ทุกตัวอ่านได้ ซึ่งหมายความว่าเราสามารถสร้าง Hermes ตัวหนึ่งที่มีหน้าที่เดียวคืออ่าน eval data และปรับปรุง profiles อื่นๆ
มันคือ Hermes Coach โดยพื้นฐาน มันโค้ช Hermes
สิบเจ็ดคน, เซิร์ฟเวอร์เยอรมันหนึ่งเครื่อง, ครอบครัวของ agents ที่เข้านอนทุกคืนและตื่นขึ้นมาด้วยความคมชัดขึ้นเล็กน้อย เราสร้างมันเพราะเราเล็กและอยากส่งผลงานให้ได้ราวกับว่าเราไม่เล็ก
