องค์ประกอบของ Coding Agent

• Coding agent คือระบบที่ประกอบด้วย control loop และ software harness ที่มี LLM เป็นศูนย์กลาง ทำงานแบบวนซ้ำทั้งการเขียนโค้ด รันโค้ด และรับฟีดแบ็ก
• Agent harness ทำหน้าที่จัดการคอนเท็กซ์ การเข้าถึงเครื่องมือ การประกอบพรอมป์ต และการควบคุมสถานะ ส่วน coding harness ที่เฉพาะกับงานเขียนโค้ด จะจัดการรีโพซิทอรี การทดสอบ และการตรวจสอบข้อผิดพลาด
• Coding agent ทำงานด้วยองค์ประกอบ 6 ส่วน ได้แก่ live repo context, prompt cache, tool access, context management, session memory, การมอบหมายให้ subagent
• แม้จะใช้ LLM ตัวเดียวกัน แต่ ประสิทธิภาพและประสบการณ์ผู้ใช้จะแตกต่างกันมาก ตามคุณภาพของการออกแบบ harness และ harness ที่ออกแบบมาดีจะมอบสภาพแวดล้อมการพัฒนาที่ต่อเนื่องและรับรู้บริบท
• Mini Coding Agent คือ ตัวอย่างขนาดเล็กที่สร้างโครงสร้างนี้ด้วย Python ล้วนๆ และแตกต่างจาก OpenClaw ในแง่ความเฉพาะทางด้านโค้ดและขอบเขตการใช้งาน

---

องค์ประกอบของ Coding Agent

• Coding agent คือระบบที่ประกอบด้วย control loop ซึ่งมี LLM เป็นศูนย์กลาง และ software harness ที่ห่อหุ้มมันไว้ เป็นโครงสร้างที่ทำงานซ้ำๆ ในการเขียน แก้ไข รันโค้ด และรับฟีดแบ็ก
• LLM คือโมเดลพื้นฐานสำหรับการทำนายโทเคนถัดไป ส่วน reasoning model คือ LLM ที่ถูกฝึกให้ทำการให้เหตุผลระหว่างทางและการตรวจสอบมากขึ้น
• Agent คือ control loop ที่ทำซ้ำการเรียกใช้โมเดล การใช้เครื่องมือ การอัปเดตสถานะ และการตัดสินใจยุติการทำงาน เพื่อให้บรรลุเป้าหมาย
• Agent harness คือโครงสร้างซอฟต์แวร์ที่ห่อหุ้มลูปเหล่านี้ไว้ โดยรับผิดชอบ การจัดการคอนเท็กซ์, การเข้าถึงเครื่องมือ, การประกอบพรอมป์ต, การควบคุมสถานะ เป็นต้น
• Coding harness คือรูปแบบที่เฉพาะกับงานโค้ด โดยจัดการคอนเท็กซ์ของรีโพซิทอรี การรันโค้ด การทดสอบ และการตรวจสอบข้อผิดพลาด

ความสัมพันธ์ระหว่าง LLM, reasoning model และ agent

• เปรียบได้ว่า LLM คือ เครื่องยนต์, reasoning model คือ เครื่องยนต์ที่เสริมความสามารถ, และ agent harness คือ ระบบที่ควบคุมเครื่องยนต์นี้
• LLM และ reasoning model สามารถทำงานเขียนโค้ดได้ด้วยตัวเอง แต่ในสภาพแวดล้อมการพัฒนาจริง จำเป็นต้องมีการจัดการบริบทที่ซับซ้อน เช่น การสำรวจรีโพ, การค้นหาฟังก์ชัน, การรันทดสอบ, การวิเคราะห์ข้อผิดพลาด
• Coding harness ช่วยดึงศักยภาพของโมเดลออกมาได้สูงสุด และมอบประสบการณ์การเขียนโค้ดที่ทรงพลังกว่าอินเทอร์เฟซแชตทั่วไปมาก

บทบาทของ Coding Harness

• เป็น ชั้นซอฟต์แวร์ ที่ครอบโมเดลไว้ ทำหน้าที่ประกอบพรอมป์ต เปิดให้ใช้เครื่องมือ ติดตามสถานะไฟล์ รันคำสั่ง จัดการสิทธิ์ แคช และเก็บหน่วยความจำ
• แม้จะใช้ LLM ตัวเดียวกัน แต่ ประสิทธิภาพและประสบการณ์ผู้ใช้จะแตกต่างกันมาก ตามการออกแบบ harness
• ตัวอย่างเช่น โมเดล open-weight อย่าง GLM-5 หากถูกผนวกรวมเข้ากับ harness ระดับเดียวกับ Codex หรือ Claude Code ก็อาจให้ประสิทธิภาพใกล้เคียงกันได้
• OpenAI ก็มีกรณีที่แยกดูแล post-processing model ตามแต่ละ harness อย่าง GPT-5.3 และ GPT-5.3-Codex

องค์ประกอบหลัก 6 ประการของ Coding Agent

• 1. คอนเท็กซ์รีโพซิทอรีแบบเรียลไทม์ (Live Repo Context)

  • เอเจนต์ต้องรับรู้ สถานะของ Git repo ปัจจุบัน, branch, เอกสาร, คำสั่งทดสอบ เป็นต้น
  • คำสั่งอย่าง “แก้การทดสอบ” จะมีความหมายต่างกันไปตามโครงสร้างและบริบทของรีโพ ดังนั้นจึงต้อง รวบรวมข้อมูลสรุปของรีโพก่อนเริ่มงาน
  • วิธีนี้ช่วยให้ไม่ต้องเริ่มจากศูนย์ทุกครั้ง และทำให้มี ฐานข้อเท็จจริงที่เสถียร (stable facts)

• 2. โครงสร้างพรอมป์ตและการใช้แคชซ้ำ (Prompt Shape and Cache Reuse)

  • เนื้อหาอย่างสรุปรีโพ คำอธิบายเครื่องมือ และคำสั่งทั่วไป มักไม่เปลี่ยนบ่อย จึงสามารถแคชเป็น stable prompt prefix ได้
  • แทนที่จะประกอบพรอมป์ตทั้งหมดใหม่ทุกคำขอ ก็ อัปเดตเฉพาะส่วนที่เปลี่ยน
  • ช่วย ลดการคำนวณที่สูญเปล่าและรักษาความสม่ำเสมอของคำตอบ ในเซสชันที่ทำซ้ำ

• 3. การเข้าถึงและการใช้เครื่องมือ (Tool Access and Use)

  • แทนที่โมเดลจะเพียงเสนอคำสั่ง ระบบ harness จะเปิดให้รันคำสั่งจริงผ่าน ชุดเครื่องมือที่ harness กำหนดไว้
  • แต่ละเครื่องมือมี รูปแบบอินพุต·เอาต์พุตและขอบเขตที่ชัดเจน พร้อม การตรวจสอบความถูกต้องและขั้นตอนอนุมัติ ก่อนรัน
  • ตัวอย่างเช่น ตรวจว่า “เป็นเครื่องมือที่รู้จักหรือไม่?”, “อาร์กิวเมนต์ถูกต้องหรือไม่?”, “พาธงานอยู่ภายใน workspace หรือไม่?”
  • แนวทางนี้ช่วยเพิ่ม ความปลอดภัยและความน่าเชื่อถือ แม้ลดอิสระของโมเดลลง แต่ เพิ่มความใช้งานได้จริง

• 4. การลดการพองตัวของคอนเท็กซ์ (Minimizing Context Bloat)

  • ในเซสชันยาวๆ อาจเกิดปัญหาพรอมป์ตยาวเกินจากการอ่านไฟล์ซ้ำๆ ล็อก และผลลัพธ์จากเครื่องมือ
  • Harness จัดการเรื่องนี้ด้วย 2 กลยุทธ์
    • Clipping: ย่อข้อความยาว ล็อก หรือโน้ต ให้เหลือความยาวตามกำหนด
    • Summarization: สรุปย่อประวัติการสนทนาเก่าๆ
  • เหตุการณ์ล่าสุดจะยังคงเก็บอย่างละเอียด ส่วนข้อมูลเก่าจะถูก ลบความซ้ำซ้อนและบีบอัด
  • ผลลัพธ์คือ ในทางปฏิบัติ คุณภาพของคอนเท็กซ์ส่งผลต่อประสิทธิภาพมากกว่าคุณภาพของโมเดล

• 5. หน่วยความจำเซสชันแบบมีโครงสร้าง (Structured Session Memory)

  • เอเจนต์แยกสถานะออกเป็น working memory และ full transcript
  • บันทึกทั้งหมดจะรวมทุกคำขอ คำตอบ และผลลัพธ์จากเครื่องมือ ทำให้ กลับมาทำต่อในเซสชันเดิมได้
  • Working memory จะเก็บสรุปของข้อมูลสำคัญปัจจุบัน เช่น งานที่กำลังทำ ไฟล์หลัก และโน้ตล่าสุด
  • Compact transcript ใช้สำหรับประกอบพรอมป์ตให้โมเดลใหม่ ส่วน working memory ใช้เพื่อ รักษาความต่อเนื่องของงาน

• 6. การมอบหมายให้ subagent แบบมีขอบเขต (Delegation With Bounded Subagents)

  • เอเจนต์หลักสามารถสร้าง subagent เพื่อ ประมวลผลงานย่อยแบบขนาน
  • ตัวอย่างเช่น แยกงานค้นหาตำแหน่งที่ประกาศสัญลักษณ์ เนื้อหาไฟล์คอนฟิก หรือสาเหตุที่เทสต์ล้มเหลว ออกเป็นงานย่อยเฉพาะ
  • Subagent จะรับช่วงต่อเฉพาะ คอนเท็กซ์ที่จำเป็น และถูกจำกัดด้วยเงื่อนไขอย่าง อ่านอย่างเดียว และ จำกัดความลึกของการเรียกซ้ำ
  • ทั้ง Claude Code และ Codex รองรับ subagent และ กำหนดขอบเขตผ่านช่วงงานและความลึกของคอนเท็กซ์

สรุปองค์ประกอบ

• องค์ประกอบทั้งหกเชื่อมโยงกันอย่างใกล้ชิด และ คุณภาพของการออกแบบ harness เป็นตัวกำหนดประสิทธิภาพในการใช้โมเดล
• Coding harness ที่ออกแบบมาดีจะให้สภาพแวดล้อมช่วยพัฒนาที่ รับรู้บริบทและต่อเนื่อง กว่าการคุยกับ LLM แบบแชตธรรมดามาก
• Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) คือ ตัวอย่างขนาดเล็กที่สร้างโครงสร้างนี้ด้วย Python ล้วนๆ

เปรียบเทียบกับ OpenClaw

• OpenClaw ใกล้เคียงกับ แพลตฟอร์มเอเจนต์ทั่วไป มากกว่าจะเป็นผู้ช่วยเฉพาะด้านโค้ด
• จุดร่วม:
  • ใช้ ไฟล์พรอมป์ต·ไฟล์คำสั่ง (AGENTS.md, TOOLS.md เป็นต้น) ภายใน workspace
  • มีฟังก์ชัน ไฟล์เซสชันแบบ JSONL, การบีบอัดบทสนทนา, การจัดการเซสชัน
  • สามารถสร้าง เซสชันเสริมและ subagent ได้
• ความแตกต่าง:
  • Coding agent ถูกปรับให้เหมาะกับ การสำรวจรีโพ, การแก้ไขโค้ด, การรันเครื่องมือบนเครื่องโลคัล
  • OpenClaw เน้น การรันเอเจนต์ระยะยาวข้ามหลายแชนเนล·หลาย workspace

ภาคผนวก: แนะนำหนังสือใหม่

• เขียน Build A Reasoning Model (From Scratch) เสร็จแล้ว และตอนนี้เปิดเผยแพร่ Early Access อยู่
• สำนักพิมพ์กำลังจัดทำเลย์เอาต์ โดยตั้งเป้าออกวางจำหน่ายในช่วงฤดูร้อน
• หนังสือเล่มนี้เน้นแนวทาง ทำความเข้าใจกลไกการให้เหตุผลของ LLM ผ่านการลงมือสร้างด้วยตนเอง

[GN⁺]

ความคิดเห็นบน Hacker News

• context ที่ยาวยังคงมีราคาแพง และถ้ามีข้อมูลที่ไม่จำเป็นมากเกินไปก็จะกลายเป็น noise
  เพราะงั้นผมเลยคิดว่า การสร้างแบบอิง spec ดีกว่าการเขียนโค้ดแบบสนทนา
  Ossature ที่ผมทำใช้แนวทางตรงกันข้าม คือเริ่มจากเขียน spec ที่อธิบายพฤติกรรมก่อน จากนั้นจะตรวจทานส่วนที่ขาดหรือขัดแย้งกันก่อนสร้างโค้ด แล้วสร้าง build plan ในรูปแบบ TOML ที่ระบุว่างานแต่ละชิ้นอ้างอิงส่วนไหนของ spec และไฟล์ใดบ้าง
  LLM จะดูเฉพาะส่วนที่จำเป็น และไม่มีการสะสมประวัติการสนทนา ทุก prompt และ response จะถูกเก็บลงดิสก์ ทำให้มี การติดตามย้อนหลัง โดยอัตโนมัติ
  ช่วงหลังผมเพิ่งสร้าง CHIP-8 emulator เสร็จด้วยวิธีนี้โดยอาศัย spec ล้วน ๆ และก็มี โปรเจ็กต์ตัวอย่าง ด้วย

  • ช่วงนี้ผมคิดบ่อยมากว่าพวก coding agent ยังไม่มี แหล่งความจริงส่วนกลาง
    เมื่อก่อนทุกคนในทีมรู้ว่ากำลังสร้างอะไรอยู่ แต่ตอนนี้ agent เริ่มใหม่ทุกครั้ง
    เพราะงั้นผมมองว่า flow แบบ chat → spec → code คืออนาคต และขั้น spec → code ควรทำงานได้โดยไม่ต้องมีมนุษย์คอยแทรกแซง
    ถ้า spec ยังไม่ชัด ก็ควรถามมนุษย์ให้ชัดเจนก่อน แล้วค่อยสร้างโค้ดจากสิ่งนั้น
    ตอนนี้คำขอที่กำกวมถูกวนซ้ำไปเรื่อย ๆ และมนุษย์เองก็ไม่ได้เรียนรู้ว่าทำไม “memory” หรือไฟล์ agent ก็เป็นแค่ทางแก้ชั่วคราวเท่านั้น
  • ผมก็กำลังทำอะไรคล้าย ๆ กันอยู่ ยังไม่เปิดตัวแต่เป็น workflow engine ที่ยึด spec เป็นศูนย์กลาง
    แทนที่จะใช้บทสนทนา ผมจะป้อน projected context ของโค้ดและ spec ให้ LLM และจัดองค์ประกอบ context ต่างกันในแต่ละขั้น
    เพื่อป้องกัน drift จาก context ที่สะสม และให้โค้ดของผมเป็นตัวควบคุม workflow ไม่ใช่ LLM
    ไอเดียการใช้ TOML เป็น artifact สำหรับส่งต่อระหว่างแต่ละขั้นน่าสนใจมาก เดี๋ยวจะลองเอาไปอ้างอิงดู
  • ผมก็คิดเหมือนกัน Agent A ควรแก้เฉพาะ spec ส่วน Agent B ก็ควร build โดยดูจาก spec อย่างเดียว
    ผู้ใช้แค่ตรวจ diff ที่ Agent A สร้างก็พอ และไม่ต้องติดอยู่กับการตรวจโค้ดแบบซ้ำ ๆ
    หัวใจสำคัญคือการรักษา เจตนา (intent) ไว้ให้ได้เสมอ ต้องเก็บทั้งสเปกและบริบทไว้ตามเดิม
    ค่าใช้จ่ายอาจสูงขึ้น 2~3 เท่า แต่ระยะยาวน่าจะคุ้มค่ากว่าในแง่ประสิทธิภาพ
  • workflow แบบ chat ทำให้เหนื่อยและข้อมูลสูญหายเยอะ
    ผมคิดว่าแนวทางแบบอิง spec ดีกว่ามาก เลยอยากรู้ว่ามนุษย์เข้ามาแทรกตรงไหนบ้าง — แก้ spec กับ audit ไปพร้อมกันหรือเปล่า, อัตราความสำเร็จของการสร้างโค้ดเป็นอย่างไร, และมีแผนจะใช้กับโค้ดเดิมด้วยไหม
  • ผมเองก็ลองเริ่มจาก spec ก่อนด้วยชุด Claude Code + Cucumber แล้วค่อยปรับปรุงโค้ดแบบวนรอบ
    เลยสงสัยว่า Ossature ต่างจากแนวทางนั้นอย่างไร

• น่าทึ่งที่ใช้แค่ state machine แบบเรียบง่ายกับแนวทาง bash ก็สามารถดึงศักยภาพของ LLM ออกมาได้

  • เพราะแบบนั้นผมเลยกำลังสร้าง coding agent แบบแยกสภาพแวดล้อม เอง
    ช่วงนี้ ecosystem ของ agent เต็มไปด้วยฟีเจอร์ที่มากเกินจำเป็นและการตัดสินใจที่แย่
    ถ้าย้อนกลับไปเมื่อ 10 ปีก่อน คนยังพูดกันว่าเครื่องมือแบบนี้ต้องมีความรับผิดชอบ แต่ตอนนี้มันเป็นช่วงเวลาที่สับสน มีทั้งความกลัวและกระแส hype ปะปนกันไป
  • สุดท้ายแก่นจริง ๆ คือ prompt/context engineering
    ตัวโมเดลมีความรู้อยู่แล้ว แต่การจะพามันไปสู่การกระทำที่ใช้ได้จริงต้องออกแบบ context ให้ดี
    วิธีที่น่าสนใจคือแปลงคำขอของผู้ใช้ให้เป็นขั้นตอนแบบนักพัฒนาที่ชำนาญ แล้วเชื่อมต่อกับเครื่องมือที่จำเป็น
    ผมมองว่าแม้แต่โมเดลโอเพนซอร์สก็ยังแข่งขันได้สบาย หากมี agent ที่ optimize มาดีพร้อมการจูนเพิ่มอีกเล็กน้อย
  • ถ้าดูจาก Claude Code ฉบับที่หลุดออกมา จะเห็นว่าโครงสร้างมันไม่ได้เรียบง่าย
    มันต้องมี harness ที่ซับซ้อน แต่ก็เพราะแบบนั้น LLM ถึงทำงานเป็นเครื่องมือได้อย่าง deterministic
  • CLI agent หลายตัวมองว่าแค่เข้าถึง bash อย่างเดียวไม่พอ เลยพยายามยัดฟีเจอร์ทุกอย่างลงใน JavaScript TUI
  • แทนที่จะใช้ bash ผมพบว่าใช้ Python มีประโยชน์กว่า
    เพราะมันให้ประกอบตรรกะอะไรก็ได้อย่างอิสระ แทนที่จะถูกจำกัดด้วย pipeline

• ตัวอย่างกระชับและชัดเจนมาก
  ถึงผมจะไม่ได้ใช้ coding agent แต่บทความนี้ช่วยให้เข้าใจ แก่นแท้ของ coding agent ได้ดี
  และยังชี้ให้เห็นชัดว่าต่อให้เริ่มจากโค้ดที่มีประโยชน์เพียง 1k LOC ก็อาจกลายเป็นความวุ่นวายระดับ 500k LOC ได้

• ตอนนี้มีหลายคนใช้โมเดลเปิดอย่าง GLM-5 ต่อเข้ากับ Claude Code หรือ Codex CLI อยู่แล้ว
  เอกสารทางการของ GLM ก็แนะนำแนวทางนี้

  • ถึงจะยังไม่ถึงระดับ Opus แต่ชุด GLM กับ Qwen3.5-plus ก็ยอดเยี่ยมพอสำหรับโปรเจ็กต์ส่วนตัว

• บทความนี้น่าประทับใจมาก ผมสร้าง agent ที่ไม่ใช่สำหรับเขียนโค้ด แบบใช้ email เป็นฐานอยู่ และหลักการก็คล้ายกัน
  ในแต่ละลูปของอีเมลจะเริ่ม context ใหม่ ทำให้แก้ ปัญหา context สะสม ได้อย่างเป็นธรรมชาติ
  สิ่งสำคัญคือการหาสมดุลระหว่าง context ที่ควรใส่ใน prompt แรก กับ context ที่ควรแยกไปไว้ใน tool
  ต้องคิดถึงทั้ง caching และต้นทุน token ด้วย
  รายละเอียดผมสรุปไว้ใน โพสต์บล็อก

• ผมไม่ค่อยชอบคำว่า “harness” เท่าไร เลยสงสัยว่ามีคำที่ดีกว่านี้ไหม

  • มันมักใช้ในความหมายของ shim ที่ทำหน้าที่ควบคุมโปรแกรม เช่น “test harness” หรือ “fuzzing harness”
  • น่าขันตรงที่ทุกวันนี้อะไรก็ถูกเรียกว่า “app” ไปหมด แต่แอปสำหรับรัน LLM กลับไม่ค่อยถูกเรียกว่า “app”
  • สุดท้าย “harness” ก็เป็นแค่คำเท่ ๆ สำหรับ scaffolding เท่านั้น
  • แล้วก็มีคนตอบกลับว่า ถ้างั้นก็ลองเสนอคำทางเลือกมาสิ

• tool output truncation มีประสิทธิภาพมากในการลดการพองตัวของ context
  ผมประกอบ context โดยใช้ SQLite และถ้าจำเป็นก็สามารถกู้ tool call ที่ถูกตัดทอนกลับมาด้วย message ID
  การทดลองที่เกี่ยวข้องสรุปไว้ในเอกสาร

• การเอา Claude Code ไปรันกับโมเดลอื่นเป็นเรื่องที่พบได้บ่อย
  เอกสารตัวอย่าง ก็เขียนไว้เหมือนกัน
  แต่จากประสบการณ์ของผม มันยังไปไม่ถึงระดับโมเดลของ Anthropic

  • แล้วแต่โปรเจ็กต์ บางทีโมเดลราคาถูกอย่าง MiMo V2 Pro ก็ทำได้ 70~80% แต่ในหลายกรณี Sonnet เหนือกว่ามาก
    ส่วน Opus มีแค่ราว 5% ของกรณีที่คุ้มกับราคา
    สำหรับผม OpenCode ดีกว่า Claude Code มาก เลยถึงขั้นไปซื้อเครดิต OpenRouter API
    OpenCode ทรงพลังพอมากแล้วด้วยคำสั่งแบบกำหนดเองกับการนิยาม agent ง่าย ๆ
    ถ้ากำหนด workflow ด้วย AGENTS.md, ROADMAP.md และไฟล์ลักษณะนี้ ก็เพียงพอสำหรับโปรเจ็กต์ส่วนใหญ่
    ผมคิดว่าโครงสร้างที่ ยืดหยุ่น แบบนี้รับมือกับการเปลี่ยนแปลงของโมเดลรุ่นใหม่ได้ดีกว่า harness ที่ซับซ้อน
  • เลยสงสัยว่าที่โมเดลของ Anthropic ดีกว่านี่เป็นเพราะคุณภาพโมเดลล้วน ๆ หรือเป็นผลจาก การ optimize harness ด้วย

• ความก้าวหน้าของ coding agent มาจากการพัฒนา โครงสร้างรอบข้าง (scaffolding) มากกว่าตัวโมเดลเอง
  เมื่อมีทั้งเครื่องมือ, context ของ repository และ state machine แบบเรียบง่ายแล้ว คอขวดก็จะย้ายไปอยู่ที่ คุณภาพของ context

• บทความนี้ทรงพลังมาก ผมเองก็ชอบอธิบาย coding agent ด้วย อุปมาแบบเครื่องยนต์/รถยนต์
  ถ้าอยากลองเล่นกับองค์ประกอบพื้นฐานเหล่านี้ OpenHands software-agent-sdk ก็น่าลองดู