Grok Build เปิดซอร์ส: อยากใช้ Coding Agent ให้ดีขึ้น ต้องดูที่ Harness ไม่ใช่แค่ Model

ข่าวนี้คืออะไรในภาษาคนทำงาน

xAI เปิดซอร์ส Grok Build ซึ่งเป็น Coding Agent ที่ทำงานผ่าน Terminal ครับ

มันอ่าน codebase, แก้ไฟล์, รันคำสั่ง, ค้นเว็บ และจัดการงานยาว ๆ ได้ทั้งแบบคุยผ่านหน้าจอ, เรียกแบบ headless ใน script หรือเชื่อมเข้า editor ผ่าน Agent Client Protocol (ACP)

ประเด็นสำคัญไม่ใช่แค่คำว่า open source

สิ่งที่ถูกเปิดให้ดูคือ Harness หรือระบบที่ทำให้ Model เปลี่ยนจาก “ตอบข้อความ” ไปเป็น “ลงมือทำงาน” ได้แก่:

• Agent Loop ที่ประกอบ Context และจัดลำดับการทำงาน
• ตัวแปลงคำตอบจาก Model ไปเป็น Tool Call
• Tools สำหรับอ่าน แก้ ค้นหาไฟล์ และรันคำสั่ง
• Terminal UI, Plan Review และ Inline Diff
• ระบบต่อขยายผ่าน Skills, Plugins, Hooks, MCP Servers และ Subagents

พูดง่าย ๆ คือ ถ้า Model เป็นสมอง Harness ก็คือโต๊ะทำงาน, เครื่องมือ, วิธีส่งงาน และกติกาที่ทำให้สมองนั้นทำงานกับของจริงได้ครับ

ทำไม founder/operator และทีมเล็กควรสนใจ

เวลาคนเลือก Coding Agent เรามักเริ่มจากคำถามว่า “ใช้ Model อะไร” หรือ “คะแนน benchmark เท่าไร”

สองอย่างนี้มีประโยชน์ แต่ยังไม่พอครับ

Model เก่งแค่ไหนก็ทำงานพลาดได้ ถ้าได้รับ Context ผิด, หาไฟล์ไม่เจอ, Tool ส่งผลลัพธ์ยาวเกินจนกลบงานสำคัญ, Hook ไม่ทำงาน หรือ Subagent ส่งงานกลับมาแบบไม่มี Diff ให้ review

ในทางกลับกัน Model ที่ราคาไม่แรงมาก อาจทำงานได้ดีขึ้นถ้า Harness จัด Context, จำกัด Tool และส่ง Artifact กลับมาเป็นระบบ

ข่าวนี้จึงมีบทเรียนง่าย ๆ ว่า ก่อนเปลี่ยน Model ให้ดู Workflow รอบ Model ก่อน

สำหรับทีมเล็ก เรื่องนี้มีผลกับ 3 อย่างโดยตรง:

1. ต้นทุน: Context และ Tool Output ที่ไม่จำเป็นทำให้ใช้ Token มากขึ้น
2. คุณภาพงาน: Agent ที่รู้ขอบเขตไฟล์และ Definition of Done ชัด มักส่งงานให้ review ง่ายกว่า
3. ความต่อเนื่อง: Skills, Hooks และ MCP ช่วยย้ายวิธีทำงานจากความจำใน Prompt ไปเป็นส่วนประกอบที่ใช้ซ้ำได้

เอาไปใช้กับงานตัวเองอย่างไร

1) อ่าน Agent Loop ก่อนอ่านทุกไฟล์

Repository นี้ใหญ่ครับ ถ้าเปิดแล้วไล่อ่านตั้งแต่ไฟล์แรก มีโอกาสหลงสูงมาก

เริ่มจากคำถาม 4 ข้อก่อน:

• Context แรกของ Agent มาจากไหน
• Model Response ถูก parse อย่างไร
• Tool Call ถูก dispatch ไปที่ไหน
• เมื่อ Tool ทำงานเสร็จ ผลลัพธ์กลับเข้า Loop แบบไหน

สี่คำถามนี้ทำให้เราเห็นเส้นทางหลักของงาน ก่อนค่อยลงรายละเอียดว่ามี Tool หรือ UI อะไรบ้าง

ถ้าไม่ได้เขียน Rust ก็ยังใช้วิธีเดียวกันกับ Coding Agent ตัวอื่นได้ครับ ดูเอกสาร Architecture, Session Log หรือ Trace ว่างานเดินตามลำดับไหน

2) แยก Context ออกจาก Tool

หลายทีมใส่ทุกอย่างไว้ใน Prompt เดียว ทั้งกติกาบริษัท, รายละเอียด repository, วิธีรัน test, คำสั่ง deploy และตัวอย่าง output

พอ Prompt ยาว เราเริ่มแยกไม่ออกว่าอะไรคือความรู้ และอะไรคือความสามารถในการลงมือทำ

ลองแบ่งใหม่เป็น 3 ชั้น:

• Context: ข้อมูลที่ Agent ต้องรู้ เช่น architecture, coding convention, definition of done
• Tool: สิ่งที่ Agent ทำได้ เช่น อ่านไฟล์, รัน test, เปิด issue, สร้าง draft PR
• Workflow: ลำดับการใช้ Context กับ Tool เพื่อให้ได้ผลลัพธ์หนึ่งชิ้น

การแยกแบบนี้ช่วยให้เปลี่ยน Model ได้ง่ายขึ้น และช่วยหาสาเหตุได้ตรงขึ้นเมื่อ Agent ทำงานไม่ดี

3) เลือก Skill, Hook และ MCP ให้ถูกงาน

Grok Build เปิดให้เห็น extension system หลายแบบ แต่ไม่จำเป็นต้องใช้ทุกแบบพร้อมกันครับ

ใช้หลักง่าย ๆ แบบนี้:

• Skill: วิธีทำงานหรือความรู้ที่ Agent ควรโหลดเมื่อเจองานประเภทหนึ่ง
• Hook: งานที่ต้องเกิดอัตโนมัติก่อนหรือหลังเหตุการณ์ เช่นตรวจ format หลังแก้ไฟล์
• MCP Server: ช่องทางเชื่อมระบบหรือ Tool ภายนอก เช่น GitHub, issue tracker หรือฐานข้อมูล
• Subagent: แยกงานย่อยที่มีขอบเขตและผลลัพธ์ของตัวเอง

ถ้างานยังอธิบายไม่ชัด อย่าเพิ่งเพิ่ม extension ครับ เริ่มจาก Workflow เดียวที่มี Input, Output และคนรับงานต่อชัดก่อน

4) ทดลองกับ Model คนละตัวโดยไม่เปลี่ยนทั้งระบบ

xAI ระบุว่า Grok Build สามารถตั้งค่า Custom Model ผ่าน config.toml และชี้ไปยัง OpenAI-compatible endpoint ได้

นี่คือประโยชน์ของ Harness ที่แยกจาก Model ครับ เราสามารถทดสอบงานเดิมกับ Model คนละตัว แล้วเทียบผลลัพธ์บน Workflow เดียวกันได้

อย่าเทียบจากคำตอบสวยอย่างเดียว ให้ดู:

• งานเสร็จจริงหรือไม่
• Diff ใช้ได้กี่เปอร์เซ็นต์
• Test ผ่านหรือไม่
• คนต้องแก้ต่อมากแค่ไหน
• ต้นทุนและเวลาต่อ Accepted Output เท่าไร

เริ่มจาก repository ทดลองหรือ issue เล็กก่อน แล้วค่อยขยายไปงานจริง

5) จบงานเป็น Artifact ไม่ใช่แค่ข้อความ

Harness ที่ดีไม่ควรจบด้วย “Done” ใน Chat ครับ

ผลลัพธ์ควรเป็นของที่คนรับช่วงต่อได้ เช่น:

• Diff หรือ Commit
• Test Result
• Draft PR
• รายการไฟล์ที่เปลี่ยน
• Caveat และงานที่ยังไม่เสร็จ

ถ้า Agent ทำงานหลายรอบหรือมี Subagent ให้ระบุด้วยว่า Artifact แต่ละชิ้นมาจาก Session และ Branch ไหน

Operator Kit: Agent Harness Reading Map 30 นาที

ใช้ Checklist นี้อ่าน source ของ Grok Build หรือสำรวจ Coding Agent ที่ทีมใช้อยู่ได้เลย

นาที 0 ถึง 5: กำหนดงานตัวอย่าง

เลือกงานเดียวที่ทีมทำจริง เช่น “แก้ Bug แล้วเปิด Draft PR”

Sample workflow:
Input:
Expected artifact:
Human reviewer:
Success condition:

อย่าเริ่มจากคำถามว่า Agent ทำอะไรได้ทั้งหมด ให้เริ่มจากงานเดียวที่ต้องการให้มันทำให้จบ

นาที 5 ถึง 10: วาด Loop

• [ ] Context เริ่มต้นมาจากไหน
• [ ] Model ถูกเรียกตรงไหน
• [ ] Tool Call ถูกเลือกและส่งต่ออย่างไร
• [ ] Tool Result กลับเข้า Context แบบไหน
• [ ] Loop หยุดเมื่อเงื่อนไขอะไร

นาที 10 ถึง 15: ทำ Tool Map

• [ ] Tool ไหนอ่านอย่างเดียว
• [ ] Tool ไหนแก้ไฟล์หรือสถานะระบบ
• [ ] Tool ไหนเรียก Network หรือบริการภายนอก
• [ ] Tool Output ถูกตัดหรือสรุปอย่างไร
• [ ] มี Artifact อะไรเหลือหลัง Tool ทำงาน

นาที 15 ถึง 20: ทำ Extension Map

• [ ] ความรู้ไหนควรเป็น Skill
• [ ] ขั้นตอนไหนควรเป็น Hook
• [ ] ระบบไหนควรเชื่อมผ่าน MCP
• [ ] งานไหนคุ้มที่จะแยกเป็น Subagent
• [ ] Extension แต่ละตัวโหลดจาก Scope ใด เช่น User, Project หรือ Team

นาที 20 ถึง 25: เช็ก Model Swap

• [ ] Harness เปลี่ยน Model ได้หรือไม่
• [ ] งานเดิมมี Test Case เดียวกันหรือไม่
• [ ] วัด Token, เวลา และ Accepted Output ได้หรือไม่
• [ ] Prompt หรือ Tool Schema ผูกกับ Model ใดมากเกินไปหรือไม่

นาที 25 ถึง 30: วาง Pilot

Workflow ที่จะลอง:
Repository หรือข้อมูลทดลอง:
Model A / Model B:
Allowed tools:
Expected artifact:
Metrics:
Owner ที่ review:
เงื่อนไขหยุดทดลอง:

พอจบ 30 นาที คุณควรตอบได้ว่า “Agent ทำงานอย่างไร” และ “ถ้าจะปรับให้ดีขึ้นควรแตะตรงไหน” โดยไม่ต้องเข้าใจทุกไฟล์ใน repository

ข้อจำกัดที่ควรรู้

การเปิดซอร์สไม่ได้แปลว่าทุกอย่างในบริการออนไลน์จะเหมือน source ที่เห็นตลอดเวลาครับ

README ระบุว่า repository นี้ sync มาจาก internal monorepo เป็นระยะ และเอกสาร Contributing ระบุว่ายังไม่รับ Pull Request จากภายนอก จุดนี้จึงเป็น source transparency และ local-build reference มากกว่าจะเป็น community development model เต็มรูปแบบ

อีกข้อคือคำว่า local-first ไม่ได้แปลว่าทุก configuration จะไม่มีการเชื่อมออกนอกเครื่องโดยอัตโนมัติ การใช้ Custom Model, MCP Server, Web Search, Plugin หรือบริการอื่นอาจมี Data Path ของตัวเอง

ถ้าจะลองกับ source code สำคัญ ให้เริ่มจาก repository จำลอง, ตรวจ config ที่เปิดใช้งาน และดู Network Behavior ของเครื่องมือใน Workflow นั้นก่อน ไม่ต้องทำเอกสารยาวครับ แค่รู้ว่าข้อมูลอะไรออกไปที่ไหนก็เพียงพอสำหรับการทดลองรอบแรก

สรุป

Grok Build เปิดซอร์สครั้งนี้มีค่าตรงที่ทำให้เราเห็นว่า Coding Agent ไม่ได้มีแค่ Model

ข้างในมี Agent Loop, Context Assembly, Tool Dispatch, Plan Review, Skills, Plugins, Hooks, MCP และ Subagents ที่ร่วมกันเปลี่ยนคำสั่งหนึ่งบรรทัดให้กลายเป็นงานที่แก้ไฟล์และส่งต่อให้คนได้

ในความเห็นของผม คนทำงานไม่จำเป็นต้อง Fork Grok Build หรืออ่าน Rust ล้านบรรทัดครับ แค่ใช้ source นี้เป็นแผนที่ย้อนดู Coding Agent ของตัวเองก็ได้ประโยชน์แล้ว

ครั้งหน้าก่อนถามว่า “ควรเปลี่ยนไปใช้ Model ไหน” ลองถามเพิ่มอีกข้อว่า “Harness ตอนนี้พา Model ไปทำงานอย่างไร”

Data-Espresso และ OPB Stack จะคอยแปลงข่าว AI Agent ให้เป็น Workflow, SOP และ Toolkit ที่ทีมเล็กเอาไปลองกับงานจริงได้ โดยไม่ต้องเริ่มจาก release note หรือ source code ทั้ง repository ครับ