Nokka

Posted on Oct 31 AI-assisted

Harness ของ AI agent เป็นปัญหาสถาปัตยกรรมซอฟต์แวร์ ไม่ใช่ปัญหาพรอมป์ จริงแค่ไหน?

#ai #programming #productivity #architecture

โดย Nokka (นก-กา) | 30 ต.ค. 2026

มีโพสต์สเปนชิ้นหนึ่งจากเพจ naiker.codes เขียนไว้ว่า โครงสร้าง harness ของ AI agent เป็นปัญหาสถาปัตยกรรมซอฟต์แวร์ ไม่ใช่ปัญหาพรอมป์ [1]

โพสต์บอกต่อว่าเจ้าของเพจกำลังอ่านหนังสือ Agent Harness Engineering Patterns และบทที่ว่าด้วย Clean Architecture [1]

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

ประโยคเดียวที่เปลี่ยนมุมมองของคนทำ agent

คนที่แก้พรอมป์กับคนที่แก้โครง

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

เขาไปแก้คำสั่งในพรอมป์ เพิ่มกฎเข้าไปอีกสามบรรทัด เขียนตัวพิมพ์ใหญ่เพิ่มคำว่า IMPORTANT แล้วก็พบว่าโมเดลทำผิดอีกในสัปดาห์ถัดมา

ส่วนคนที่มองว่ามันเป็นปัญหาสถาปัตยกรรม จะถามอีกชุดว่า ส่วนไหนควรอยู่ในโค้ด ส่วนไหนควรเป็นข้อมูล ส่วนไหนควรมี unit test คอยจับ และส่วนไหนต้องรันใหม่ทุกครั้งที่เปลี่ยนโมเดล

Harness คืออะไร กันแน่

นิยามที่สั้นจนน่าสงสัย

นิยามที่วงการใช้วันนี้สั้นมาก คือ agent เท่ากับโมเดลภาษาขนาดใหญ่หรือ LLM บวก harness [2]

harness คือทุกอย่างที่เหลือ นอกจากน้ำหนักของโมเดล ได้แก่ พรอมป์ เครื่องมือ นโยบายจัดการบริบท hook ระบบ sandbox subagent ลูปตอบกลับ และเส้นทางกู้คืนเมื่อเกิดข้อผิดพลาด [3]

Addy Osmani เขียนบทความนี้ไว้บนบล็อกของตัวเอง และ O'Reilly Radar นำมาลงซ้ำเมื่อ 15 พ.ค. 2026 [3] เขาสรุปเป็นประโยคเดียวว่า โมเดลที่ดีพอแต่ harness ดี ย่อมชนะโมเดลที่เก่งกว่าซึ่งมี harness แย่ [3]

เขายังบอกด้วยว่าคำว่า harness engineering ถูกตั้งเป็นชื่อสาขาโดย Vivek (Viv) Trivedy ในโพสต์ Anatomy of an Agent Harness บน X [3]

Birgitta Böckeler เขียนบนเว็บ Martin Fowler เมื่อ 2 เม.ย. 2026 ว่ามันมีสามชั้นซ้อนกัน ชั้นในสุดคือโมเดล ชั้นถัดมาคือชุดที่ผู้สร้างเครื่องมืออย่าง Anthropic หรือ OpenAI ประกอบมาให้ และชั้นนอกสุดคือชุดที่ผู้ใช้อย่างเราประกอบเองบนเครื่องมือนั้น [4]

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

หลักฐานจากโค้ดจริง 11 ระบบ

สิ่งที่เจอเมื่ออ่านโค้ดสี่ล้านบรรทัด

ถ้าคำกล่าวอ้างนี้เป็นแค่ความเห็น ก็คงจบแค่การถกกันบน X

แต่งานวิจัย arXiv เมื่อ 15 ก.ค. 2026 ชิ้นหนึ่งไปอ่านซอร์สโค้ดของ coding harness ที่ใช้งานจริง 11 ตัว ได้แก่ Claude Code, Codex CLI, Gemini CLI, Mistral Vibe, OpenHands, Aider, Mini-SWE-Agent, Hermes, Pi, OpenCode และ OpenClaw พร้อมอีกหนึ่งตัวคือ Omnigent ที่เป็น meta-harness [5]

ที่เจอน่าสนใจกว่าตัวเลขดาว

ทุกระบบต้องตัดสินใจเรื่องระบบย่อยเจ็ดอย่างเหมือนกัน คือลูปของ agent, การต่อกับโมเดล, ระบบเครื่องมือ, การจัดการบริบทและความจำ, ความปลอดภัยและการอนุญาต, การประสานงาน และช่องทางขยาย
ในโค้ดราวสี่ล้านบรรทัดที่ใช้ Python, TypeScript และ Rust ไม่มี runtime ตัวไหน import framework agent สำเร็จรูปอย่าง LangChain, LangGraph หรือ AutoGen เลยสักตัว
ไม่มีตัวไหนใช้ vector embedding ในการค้นหาโค้ด ทุกตัวใช้วิธีค้นแบบตรงไปตรงมาอย่าง ripgrep, tree-sitter หรือ glob
มาตรฐานส่วนขยายที่ชนะคือ SKILL.md ซึ่งใช้ใน 9 จาก 11 ระบบ ส่วน MCP ใช้ใน 8 จาก 11
ช่วงหนึ่งไตรมาสที่ศึกษาซ้ำ พบว่าความคล้ายกันกลายเป็นการลอกกัน Codex รับคำศัพท์เรื่อง hook ไปใช้ทั้งชุด พร้อมตัว import เซสชันและ settings ของ Claude Code

ข้อค้นพบเรื่อง framework สำคัญกับบทความนี้มาก เพราะมันบอกว่างานนี้ไม่มีทางลัดแบบติดตั้งไลบรารีแล้วจบ ทีมที่ทำได้ดีคือทีมที่ออกแบบโครงสร้างเองอย่างตั้งใจ

ถ้ามันเป็นสถาปัตยกรรม ชั้นของมันหน้าตาเป็นอย่างไร

แปลง Clean Architecture มาเป็นชั้นของ harness

Clean Architecture ของ Robert C. Martin ตั้งอยู่บนกฎข้อเดียวที่เรียกว่า dependency rule คือการพึ่งพาในโค้ดต้องชี้เข้าข้างในเท่านั้น ชั้นในไม่รู้จักชั้นนอก [6]

เรียงชั้นจากในสุดออกมาเป็น entity ที่เป็นกฎธุรกิจ ใช้เคสที่ประสานงานกับ entity แล้วจึงเป็น interface adapter ที่แปลงข้อมูล และชั้นนอกสุดคือ framework กับไดรเวอร์

ลองเอาแผนนี้มาเทียบกับ harness ของ agent จะได้ภาพแบบนี้

นี่คือการตีความของผมเอง สองย่อหน้าก่อนหน้าเป็นของ Martin และ Böckeler ส่วนการจับคู่แบบนี้ยังไม่มีใครเขียนไว้ตรง ๆ

ชั้นในสุด คือเป้าหมายของงานและนโยบายที่ต้องยึด เช่น งานนี้ต้องแก้ไฟล์ห้ามลบนอกโฟลเดอร์ ห้ามรันคำสั่งที่แตะ production
ชั้นใช้เคส คือลูปของ agent ที่ตัดสินใจว่าจะเรียกเครื่องมืออะไรต่อ และจะหยุดเมื่อไหร่
ชั้น adapter คือตัวต่อกับโมเดล ตัวต่อกับเครื่องมือ แต่ละตัวแปลงของจริงให้เป็นรูปแบบที่ชั้นในเข้าใจ
ชั้นนอกสุด คือ CLI, ส่วนขยาย IDE, ระบบคิว และคนที่กดอนุมัติ

พอวางแบบนี้ คำถามที่เคยมืดก็จะชัดขึ้นทันทีว่า อะไรควรเป็นพรอมป์ และอะไรไม่ควร

อาการที่บอกว่าคุณกำลังแก้ผิดชั้น

ห้าสัญญาณที่เจอบ่อย

ห้าอาการที่ระบบซึ่งเริ่มจากพรอมป์มักเจอ

พรอมป์ยาวขึ้นเรื่อย ๆ เพราะทุกครั้งที่เจอบั๊ก มีคนเพิ่มกฎเข้าไปอีกข้อ จนสุดท้ายไม่มีใครรู้ว่ากฎข้อไหนยังจำเป็น
เปลี่ยนโมเดลแล้วพังทั้งระบบ เพราะพฤติกรรมสำคัญถูกฝังอยู่ในถ้อยคำ ไม่ได้อยู่ในโค้ดที่ทดสอบได้
ทดสอบอะไรไม่ได้เลย เพราะไม่มีที่ให้เขียน unit test นอกจากยิงพรอมป์จริงแล้วดูผล
ข้อผิดพลาดของเครื่องมือหายเงียบ เพราะลูปไม่มีที่ให้บันทึกและตัดสินใจซ้ำ
ไม่มีเพดานการใช้จ่าย เพราะไม่มีชั้นที่คุมงบและจำนวนรอบแยกจากตัวโมเดล

ทั้งห้าข้อไม่ใช่ปัญหาโมเดล ไม่ว่าจะเปลี่ยนไปใช้ตัวไหนก็ยังอยู่ ถ้าโครงยังเหมือนเดิม

โครงที่ผมจะเสนอให้ทีมที่เริ่มใหม่

แยกให้เห็นว่าใครรู้จักใคร

ไม่มีสูตรตายตัว แต่โครงนี้ทำให้ dependency rule ใช้งานได้จริง

agent/
  core/            # นโยบายและเพดานงบ ไม่ import ของนอก
    policy.ts
    budget.ts
  usecases/
    run_turn.ts    # ลูป: ตัดสินใจ -> เรียกเครื่องมือ -> สังเกต -> วนซ้ำ
  adapters/
    model_openai.ts
    model_local.ts
    tool_shell.ts
    tool_fs.ts
  runtime/
    cli.ts
    ide_bridge.ts
    queue.ts
  tests/
    policy.test.ts
    run_turn.test.ts

หัวใจอยู่ที่โฟลเดอร์ core กับ usecases ไม่รู้จักชื่อโมเดล ไม่รู้จักเครื่องมือที่ใช้ และไม่รู้ว่าใครเรียกมัน

พอเปลี่ยนจาก GPT เป็น Claude หรือย้ายไปโมเดลบนเครื่องตัวเอง ไฟล์ที่ต้องแก้มีแค่ใน adapters เท่านั้น

กฎที่ควรอยู่ในโค้ด ไม่ใช่ในพรอมป์

ตัวอย่างกฎกันลบไฟล์

ยกตัวอย่างกฎง่าย ๆ ที่คนมักเขียนในพรอมป์ว่า ห้ามลบไฟล์นอกโฟลเดอร์งาน

ถ้าเขียนเป็นโค้ด มันจะหน้าตาแบบนี้ และตรวจสอบได้ด้วย unit test ซึ่งถ้อยคำในพรอมป์ทำไม่ได้

// core/policy.ts
import { resolve, dirname, join, sep } from 'node:path'
import { realpath } from 'node:fs/promises'

export async function guardDelete(path: string, workdir: string) {
  const root = await realpath(resolve(workdir))
  const abs = resolve(path)
  const existing = await realpath(abs).catch(async () => {
    const parent = await realpath(dirname(abs)).catch(() => dirname(abs))
    return join(parent, abs.slice(abs.lastIndexOf(sep) + 1))
  })
  if (existing !== root && !existing.startsWith(root + sep)) {
    return { allow: false, reason: 'outside_workdir' }
  }
  return { allow: true }
}

ผมใช้ realpath ไม่ใช่ resolve เพราะ resolve ไม่คลาย symlink ถ้ามีลิงก์ในโฟลเดอร์งานที่ชี้ไปข้างนอก ด่านนี้จะปล่อยผ่านทั้งที่ปลายทางอยู่คนละที่ นี่เป็นตัวอย่างขั้นต่ำเพื่อให้เห็นหลัก ไม่ใช่ด่านความปลอดภัยครบชุด

ยังมีอีกสองจุดที่ต้องดักเอง ถ้า workdir ไม่มีอยู่ realpath จะโยน error ออกมา และระหว่างตรวจกับลบมีช่องว่างที่ไฟล์อาจถูกสลับได้ ทางปฏิบัติคือลบด้วย path ที่ผ่านการคลายแล้ว ไม่ใช่ path ที่ผู้ใช้ส่งเข้ามา

พรอมป์ยังมีที่ของมัน คือบอก intent และวิธีทำงานให้โมเดล แต่พรอมป์ไม่ใช่ที่เก็บกฎที่ผิดแล้วเสียหาย

กฎที่ผิดแล้วเสียหายต้องอยู่ในโค้ดที่รันทุกครั้ง ไม่ว่าจะใช้โมเดลไหน และต้องมี test คอยจับ

ข้อโต้แย้งที่ต้องฟัง

ทำไมการเริ่มจากพรอมป์ถึงสมเหตุสมผล

มีเหตุผลที่ดีที่คนจำนวนมากยังเริ่มจากพรอมป์

เพราะช่วงแรกของโปรเจกต์ เรายังไม่รู้ว่าผู้ใช้อยากได้อะไร ไม่ใช่ยังไม่รู้ว่าจะวางโครงอย่างไร การเขียนชั้นให้ครบตั้งแต่ยังไม่รู้โจทย์คือการสร้างต้นทุนที่อาจทิ้งทั้งดุ้น

Osmani เองก็ไม่ได้บอกให้ทุกคนเริ่มจากสถาปัตยกรรม เขาเน้นว่าของที่คุ้มคือการขัด harness ให้ดีขึ้นทุกครั้งที่ agent พลาด [3]

และงานวิจัย 11 ระบบก็ไม่ได้บอกว่าทุกคนต้องเขียนลูปเอง มันบอกแค่ว่าในระดับที่ระบบเหล่านี้โตขึ้นมา ไม่มีใครใช้ framework สำเร็จรูปเป็นแกน

ฝั่ง OpenAI รายงานเมื่อ 11 ก.พ. 2026 ว่า ทีมหนึ่งสร้างผลิตภัณฑ์จริงโดยไม่มีโค้ดที่มนุษย์เขียนเองสักบรรทัด และใช้เวลาราวหนึ่งในสิบของที่เขียนมือ [7] ทีมนั้นลงทุนกับสภาพแวดล้อมและวงจรตอบกลับ ไม่ใช่พรอมป์ที่เก่งขึ้น

แปลว่าเส้นทางที่สมเหตุสมผลคือ เริ่มจากของที่เบาที่สุดก่อน แล้วค่อยแยกชั้นออกมาเมื่อเจออาการที่บอกว่าต้องแยก

สำหรับทีมเล็กที่ทำ agent อยู่ตอนนี้

สามขั้นเรียงตามต้นทุน

สามขั้นที่ผมคิดว่าคุ้มที่สุดเมื่อเรียงตามต้นทุน

แยกกฎที่ผิดแล้วเสียหายออกจากพรอมป์ แล้วเขียนเป็นฟังก์ชันที่มี test
ทำชั้นต่อกับโมเดลให้เป็น adapter ตัวเดียว ถ้าวันนี้ยังไม่มีเวลาแยก ก็อย่างน้อยให้มันอยู่ไฟล์เดียวและไม่มีที่อื่นเรียก SDK ตรง
เพิ่มเพดานงบและจำนวนรอบในชั้นใช้เคส เพราะค่าใช้จ่ายเป็นเรื่องที่สถาปัตยกรรมคุมได้ แต่พรอมป์คุมไม่ได้

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

สรุป

สิ่งที่ผมอยากให้จำ

ข้อกล่าวอ้างที่ว่า harness เป็นปัญหาสถาปัตยกรรม ไม่ใช่ปัญหาพรอมป์ ผมคิดว่าใช่อยู่ในระดับหนึ่ง

มันไม่จริงในแง่ว่าพรอมป์ไม่สำคัญ เพราะพรอมป์คือส่วนหนึ่งของ harness และเป็นส่วนที่กำหนดวิธีคิดของโมเดล

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

งานวิจัยที่อ่านโค้ดสี่ล้านบรรทัดของระบบจริง 11 ตัวก็ชี้ไปทางเดียวกันว่า ระบบที่โตได้คือระบบที่ออกแบบโครงเอง ไม่ได้ต่อยอดจากของสำเร็จรูป

คำถามที่ผมอยากฝากไว้คือ ถ้าพรุ่งนี้คุณต้องเปลี่ยนโมเดลทั้งระบบ วันนี้คุณจะต้องแก้กี่ไฟล์

แหล่งอ้างอิง

[1] Facebook · naiker.codes · โพสต์วิดีโอ "La arquitectura harness de tu agente de IA es un problema de arquitectura de software, no de prompts" · เข้าถึง 30 ต.ค. 2026 · https://www.facebook.com/61555688363983/posts/122303229470189612
[2] LangChain Blog · Vivek Trivedy · The Anatomy of an Agent Harness (Agent = Model + Harness) · 10 มี.ค. 2026 · https://blog.langchain.com/the-anatomy-of-an-agent-harness/
[3] O'Reilly Radar · Addy Osmani · Agent Harness Engineering (15 พ.ค. 2026) · https://www.oreilly.com/radar/agent-harness-engineering
[4] martinfowler.com · Birgitta Böckeler · Harness engineering for coding agent users (2 เม.ย. 2026) · https://martinfowler.com/articles/harness-engineering.html
[5] arXiv 2609.00006 · Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems (15 ก.ค. 2026) · https://arxiv.org/abs/2609.00006
[6] The Clean Coder Blog · Robert C. Martin · The Clean Architecture (2012) · https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
[7] OpenAI · Ryan Lopopolo · Harness engineering: leveraging Codex in an agent-first world (11 ก.พ. 2026) · https://openai.com/index/harness-engineering/

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

DEV Community