Act Operator – โอเพนซอร์สฮาร์เนสควบคุมโปรเจกต์ LangGraph 1.0+ สำหรับ "ใช้งานจริงในโปรดักชัน"

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

ตรงนี้มักจะเกิดอาการผิดปกติเรื้อรังอยู่เสมอ เมื่อคนที่ใช้เครื่องมือ AI ต้องทำงานร่วมกัน

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

ปัญหาไม่ได้อยู่ที่ตัวโมเดล แต่คือ ช่องว่างของคอนเท็กซ์ (Context Gap) — และสิ่งนี้ใช้กับทั้งคนและ AI agent เหมือนกัน
เหตุผลเดียวกันนี้เองที่ทำให้สมาชิกใหม่ของทีมที่ถูกส่งเข้ามาโดยไม่มี onboarding ต้องหลงทางอยู่ในโค้ดเบสเดียวกัน: convention เป็นสิ่งที่รับรู้กันโดยนัย สถาปัตยกรรมอยู่แค่ในหัวใครบางคน และไม่มีสภาพแวดล้อมแบบมีโครงสร้างคอยนำทาง AI agent ก็ไม่ต่างกัน

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

การแก้ปัญหานี้ไม่ใช่การปรับปรุง prompt หรือหาโมเดลที่ดีกว่า แต่ต้องออกแบบสภาพแวดล้อมที่คนและ agent ทำงานร่วมกันได้ตั้งแต่ต้น

[ ฮาร์เนสมีอยู่มาตั้งแต่แรกแล้ว ]

คำว่า harness มาจากภาษาฝรั่งเศสโบราณ 'harnois' เดิมมีความหมายว่า "อุปกรณ์ทางทหาร, เครื่องมือควบคุม"
ตั้งแต่ช่วงทศวรรษ 1690 ก็มีความหมายเชิงเปรียบเทียบชัดเจนขึ้นว่า "ควบคุมพลังที่ยังไม่ถูกควบคุมให้อยู่ในทิศทางที่ถูกต้องเพื่อให้ใช้งานได้ (to control for use as power)"
เช่นเดียวกับที่เราเรียกกังหันลมซึ่งเปลี่ยนลมให้เป็นพลังงานว่าเป็นการ "harnessing" ลม

ในงานวิศวกรรม หลักการนี้ถูกนำกลับมาใช้ซ้ำในรูปแบบต่าง ๆ

• Wiring Harness: อุปกรณ์ที่รวบรวมสายไฟอันซับซ้อนให้เป็นชุดเดียวที่ควบคุมได้ เป็นมาตรฐานในอุตสาหกรรมยานยนต์มาหลายสิบปี
• Test Harness: สภาพแวดล้อมการรันที่ประกอบด้วย stub และ driver เพื่อแยกคอมโพเนนต์เฉพาะออกมาทดสอบได้โดยไม่ต้องมีโครงสร้างพื้นฐานครบทั้งระบบ เป็นแนวคิดหลักของ software testing
• CI/CD Pipeline: สภาพแวดล้อมควบคุมแบบมีโครงสร้างที่ทำให้โค้ดไม่ถูกส่งตรงขึ้น production แต่ต้องผ่านชั้นของ build, test และ validation ก่อน สิ่งนี้ก็คือฮาร์เนสอย่างหนึ่งเช่นกัน

ทั้งหมดมีจุดร่วมเพียงอย่างเดียว

การออกแบบสภาพแวดล้อมภายนอกเพื่อควบคุมสิ่งที่ยังไม่ถูกควบคุม (สายไฟ, คอมโพเนนต์โค้ด, โฟลว์การ deploy) ให้เคลื่อนไปในทิศทางที่ถูกต้อง

ดังนั้นเมื่อต้นปี 2026 OpenAI สร้างระบบขนาดระดับ 1 ล้านบรรทัดด้วย Codex agent ตลอด 5 เดือนโดยแทบไม่ต้องเขียนโค้ดด้วยมือเลยแม้แต่บรรทัดเดียว การตั้งชื่อว่าการนำหลักการเก่าแก่นี้มาประยุกต์ใช้กับ AI agent คือ Harness Engineering จึงเป็นบทสรุปที่เป็นธรรมชาติ ไม่ใช่เรื่องบังเอิญที่ทั้ง Martin Fowler และทีมวิศวกรรมของ Anthropic ต่างก็ใช้คำเดียวกันในช่วงเวลาใกล้เคียงกัน

LangChain เองก็ขยับอันดับ Terminal Bench 2.0 จากอันดับ 30 ขึ้นมาเป็นอันดับ 5 ได้ด้วยการปรับปรุงฮาร์เนสเพียงอย่างเดียว

ด้วยเหตุนี้ act-operator จึงถูกสร้างขึ้นมาเป็นฮาร์เนสสำหรับควบคุมโครงสร้าง LangGraph 1.0+ ที่สามารถนำไปใช้กับ โปรดักต์จริง ได้

[ Ultra-Quick Start ]}

ในสภาพแวดล้อมที่ติดตั้ง uv ไว้แล้ว ใช้เพียงบรรทัดด้านล่างนี้ก็จะตั้งค่าโปรเจกต์ฮาร์เนส LangGraph 1.0+ สำหรับ production จริงได้เสร็จสมบูรณ์

uvx --from act-operator act new

[ 3 เลเยอร์ของ Act Operator ]

ในการพัฒนาที่ขับเคลื่อนด้วย AI ฮาร์เนสคือระบบของ scaffolding, ความรู้ที่รันได้จริง และ feedback loop ที่ครอบไว้เพื่อให้ไม่ว่าใครจะลงมือทำ ทั้งคนและ AI agent ก็สามารถสร้างผลลัพธ์ที่ถูกต้องได้อย่างเสถียร

Act Operator นำแนวคิดนี้มาสร้างเป็น 3 เลเยอร์:

1. Scaffolding: โครงกระดูกโปรเจกต์แบบสมบูรณ์ที่ประกอบขึ้นก่อน prompt แรกของ agent โดยมี module convention และ base class ในตัว ซึ่งรับประกันทั้ง low coupling ขั้นต่ำและ high cohesion ขั้นต่ำ
2. SSOT ที่รันได้จริง: ความรู้ที่เข้ารหัสเป็นไฟล์ที่ใช้งานได้จริง ซึ่งทั้ง agent และคนอ่านได้ในระหว่าง runtime
3. Feedback Loop: ข้อกำหนดที่ช่วยรักษา agent ให้ยังอยู่ในสภาวะที่สอดคล้องกันข้ามแต่ละเซสชัน

[ SSOT ที่รันได้จริง ]

โดยทั่วไปทีมมักแชร์ความรู้ด้านการพัฒนาและการออกแบบผ่าน wiki, เอกสารสถาปัตยกรรม หรือความรู้ปากต่อปาก และบางครั้งก็ไม่ได้แชร์เลย ปัญหาคือเอกสารล้าสมัย wiki เก่า และความรู้ปากต่อปาก ไม่สามารถอยู่รอดจากการเปลี่ยนแปลงของทีมได้

ฮาร์เนสจะเข้ารหัสความรู้เหล่านี้ไว้เป็น ไฟล์ที่ทำงานได้จริง — ไม่ใช่เอกสารแบบ static แต่เป็น แหล่งอ้างอิงแบบรันได้ที่ทั้ง agent และคนอ่านโดยตรง Act Operator จัดการสิ่งนี้เป็น 3 ชั้นขององค์ประกอบ SSOT ที่เสริมกัน โดยคำนึงถึง coupling และ cohesion ดังนี้:

1. Act Template (scaffold): ตัวโครงกระดูกโปรเจกต์เอง — เวิร์กโฟลว์ CI พื้นฐาน, base class, โครงสร้างการทดสอบ, การตั้งค่า monorepo, การจัดการ environment variable และคู่มือการใช้งาน
2. Agent Skills: รวม 5 skills, reference pattern มากกว่า 50 แบบ, decision tree และ template สถาปัตยกรรม
3. Drawkit: shape แบบกำหนดล่วงหน้าของสถาปัตยกรรม Act สำหรับ draw.io — คำศัพท์ภาพร่วมกันสำหรับการสื่อสารระหว่างคนในทีม

องค์ประกอบแต่ละส่วนมุ่งไปที่เป้าหมายต่างกัน แต่ต่างอ้างอิง convention พื้นฐานชุดเดียวกัน Act Template สร้างรากฐานเชิงโครงสร้างที่ทั้ง agent และนักพัฒนาทำงานอยู่บนมัน ส่วน skills บอกวิธีที่ agent ควรสร้างสิ่งต่าง ๆ ให้ถูกต้องภายในโครงสร้างนั้น และ Drawkit บอกทีมว่าควรมองเห็นและสื่อสารสถาปัตยกรรมอย่างไร

[ ข้อมูลอื่น ๆ ของโอเพนซอร์ส ]

• นอกจาก Claude Code แล้ว เครื่องมือใดก็ตามที่รองรับ skill directory เช่น OpenCode, Cursor, Gemini CLI ก็ใช้งานได้ทั้งหมด
• รองรับเอกสารทั้งภาษาเกาหลีและภาษาอังกฤษ
• Apache 2.0 License – แจกฟรี 200% บน PIPY

ยินดีอย่างยิ่งสำหรับทุก feedback และ contribution จากทุกคนที่รัก (และ GitHub star★..!) ขอบคุณครับ :)

Github: https://github.com/Proact0/act-operator