DEV Community

Nokka
Nokka

Posted on

แกะ Harness ของ Pi, ตัวเขียนโค้ดที่เลือก 'ไม่ตัดสินใจแทนคุณ' และให้คุณแก้ไขตัวมันเองได้

#agents #ai #opensource #tutorial

แกะ Harness ของ Pi, ตัวเขียนโค้ดที่เลือก "ไม่ตัดสินใจแทนคุณ" และให้คุณแก้ไขตัวมันเองได้

โดย Nokka (นก-กา) | 23 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

แกะ Harness ของ Pi

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

  • Harness (ฮาร์เนส): "ชุดสายรัด" ที่ครอบรอบโมเดล AI, ไม่ใช่ตัวโมเดล แต่เป็น "สภาพแวดล้อม" ที่ทำให้โมเดลทำงานได้น่าเชื่อถือ เช่น ไฟล์คำสั่ง, ระบบตรวจสอบ, ระบบบันทึกความคืบหน้า
  • Agent (เอเจนต์): โปรแกรมที่ใช้โมเดล AI ทำงานหลายขั้นตอนเองได้ เช่น อ่านไฟล์ → เขียนโค้ด → รันเทสต์ → แก้ → วนซ้ำ
  • Plugin (ปลั๊กอิน): ชิ้นส่วนที่ "เสียบเพิ่ม" เข้าไปในโปรแกรม เพื่อเพิ่มความสามารถ โดยไม่ต้องแก้ตัวโปรแกรมหลัก

ถ้าให้อุปมา: โมเดล AI คือ "สมอง", harness คือ "ร่างกาย + เครื่องมือ + กติกา" ที่ทำให้สมองลงมือทำอะไรได้จริง

Pi คืออะไร และทำไมมันถึง "แปลก"

Pi (แพ็กเกจ npm ชื่อ @earendil-works/pi-coding-agent) เรียกตัวเองว่า "minimal agent harness" หรือ "ฮาร์เนสเอเจนต์แบบมินิมอล"

คำว่า "มินิมอล" ตรงนี้สำคัญมาก เพราะ Pi ไม่ได้โฆษณาตัวเองว่า "ตัวเขียนโค้ดที่เก่งที่สุด" หรือ "เครื่องมือ AI ที่ดีที่สุด" แต่มันยึดตัวตนไว้กับคำว่า harness อย่างเดียว

ปรัชญาของ Pi สรุปได้ประโยคเดียว: "ลดแกนกลางให้เล็กที่สุด แล้วทำให้ส่วนขยายเขียนโปรแกรมได้"

มันย้าย "context engineering" (การจัดการบริบท) ออกไปไกลกว่า system prompt และให้ผู้ใช้, หรือแม้แต่ตัว Pi เอง, แก้ไข harness ได้ แทนที่จะให้ Pi ตัดสินใจแทนคุณ

บนหน้าแรกของ pi.dev เขียนไว้ตรงๆ ว่า: "Ask Pi to build what you want, or install a package that does it your way." (สั่ง Pi ให้สร้างสิ่งที่คุณต้องการ หรือติดตั้งแพ็กเกจที่ทำแบบของคุณ)

4 ชั้นที่ปรับแต่งได้

Pi แบ่ง harness ออกเป็น 4 ชั้นที่ปรับแต่งได้:

  1. Extensions: TypeScript hooks ที่เกาะกับ lifecycle events ของ Pi, ให้พื้นผิวที่เขียนโปรแกรมได้ในระดับ runtime
  2. Skills: แพ็กเกจความสามารถที่โหลดตามต้องการ, ประกอบด้วยคำสั่ง + เครื่องมือ, ใช้หลัก progressive disclosure
  3. Prompt templates: เทมเพลต Markdown ที่ขยายเมื่อคุณพิมพ์ /ชื่อ
  4. Themes: หน้าตาของ TUI (terminal interface)

แนวคิดเบื้องหลังคือ: กฎและส่วนขยายเป็นตัวกำหนดว่าโมเดลเห็นอะไร และเห็นเมื่อไหร่ แทนที่จะ hard-code การตัดสินใจเหล่านี้ไว้ในแกนกลาง

Core Loop: วงจรที่ทุกเอเจนต์มีเหมือนกัน

เหมือนเอเจนต์เขียนโค้ดทุกตัว Pi ก็คือ while loop ของ "คิด → เรียกเครื่องมือ → ดูผล → คิดต่อ"

แต่สิ่งที่ต่างไม่ใช่ตัว loop เอง, แต่เป็นวิธีที่ Pi จัดการ "ชั้นรอบๆ loop": มันขยายการจัดการ context จาก "compaction ภายใน loop" ไปเป็น "control ภายนอก loop"

Pi เปิด programmable interface: นอกเหนือจาก TUI แบบโต้ตอบ, ยังรองรับ print/JSON mode, RPC protocol และ SDK embedding ซึ่งหมายความว่า harness ตัวเดียวกันนี้ ขับได้ทั้งโดยมนุษย์ทีละขั้น หรือโดย CI/CD หรือโปรแกรมอื่นอัตโนมัติ

นี่คือ "ข้อกำหนดเบื้องต้น" ของการย้ายจาก "ควบคุมด้วยมือ" ไปเป็น "loop อัตโนมัติ", เพราะ harness ที่ขับได้แค่แบบโต้ตอบด้วยมนุษย์ จะไม่มีวันเข้า loop อัตโนมัติได้

ระบบคำสั่ง: AGENTS.md และ SYSTEM.md

Pi ระมัดระวังเรื่องการจัดการคำสั่ง แต่ลำดับชั้นชัดเจน [2]:

ลำดับการโหลด AGENTS.md

  • AGENTS.md: โหลดตามลำดับ ~/.pi/agent/AGENTS.md (global) → ไล่ขึ้น parent directory ทีละชั้น → ./AGENTS.md (current directory) พร้อมรองรับ CLAUDE.md ด้วย นี่คือการนำ "repository เป็น system of record" มาใช้จริง, คำสั่งคือไฟล์ ไม่ใช่ข้อความที่พิมพ์ในแชท
  • SYSTEM.md: จุดเดียวที่แก้ "system prompt" ได้ และทำหน้าที่เป็น "environment self-description" layer

Pi เน้นว่า system prompt ของมัน มินิมอล, แกนกลางไม่ยัดกฎ "ถ้า...แล้ว..." ยาวๆ แต่เปิด extension points ให้กฎปรากฏเป็น skills และ extensions เฉพาะเมื่อจำเป็น

นี่คือการหลีกเลี่ยงปัญหา "ไฟล์คำสั่งยักษ์ไฟล์เดียว" โดยธรรมชาติ ผ่านแนวทาง "แกนเล็ก + แยกไฟล์ + โหลดตามต้องการ"

State และ Context: จุดที่ Pi ละเอียดที่สุด

Pi เปลี่ยนแนวคิด "context continuity" และ "กัน context corruption" ให้เป็นกลไกจริง 3 อย่าง [2]:

1. Programmable compaction (การย่อแบบเขียนโปรแกรมได้)

เมื่อ context ใกล้เต็ม ข้อความเก่าจะถูกสรุปอัตโนมัติ แต่กลยุทธ์การย่อเอง ปรับแต่งได้, ใช้ extension ทำ topic-based compaction, code-aware summary หรือแม้แต่ใช้โมเดลอื่นมาสรุป กลไก default: ย่ออัตโนมัติเมื่อ (ก) กู้จาก context overflow หรือ (ข) เกิน retention threshold, จุดตัดเก็บ ~20,000 token ล่าสุด, ข้อความก่อนหน้าถูกสรุปเป็น "context handoff" แล้วย่อต่อเนื่องเป็นลูกโซ่

2. Dynamic context

Extension แทรกข้อความก่อนทุก reasoning turn ได้, กรอง message history ได้, ทำ RAG ได้, สร้าง long-term memory ได้, นี่เกินกว่า "ย่อเมื่อเต็ม" เพราะคุณตัดสินใจได้ว่า "อะไรเข้าบริบท" ก่อนที่มันจะเข้า

3. Session tree

Session ถูกเก็บเป็น "ต้นไม้", /tree กลับไปที่ node ไหนก็ได้แล้วต่อจากตรงนั้น, ทุก branch เก็บในไฟล์เดียวกัน นี่แก้ปัญหา "context ขาดข้าม session" ด้วย structured history replay แทนการบังคับสรุป

ระบบเครื่องมือ: Skills และ Extensions

เครื่องมือของ Pi มี 2 ชั้น:

  • Skills: "แพ็กเกจความสามารถที่โหลดตามต้องการ" ตามมาตรฐาน Agent Skills, progressive disclosure ทำให้รายละเอียด skill เข้าบริบทเฉพาะเมื่อถูกเรียก, ไม่ทำให้ prompt cache พอง นี่คือ harness design ในมุม "ต้นทุน": ทุก token พิเศษในบริบทต้องจ่ายทุกครั้งที่ infer, การโหลด skill ตามต้องการคือ "ให้แผนที่ ไม่ใช่คู่มือ"

  • Extensions: TypeScript hooks เกาะ lifecycle events ตัวอย่างทางการ: ดักคำสั่งอันตราย (permission gate), checkpoint โค้ดเมื่อสลับงาน, ป้องกัน path (เช่นห้ามเขียน .env), แก้ tool output ก่อนส่งให้โมเดล, แทรกข้อความจากแหล่งภายนอก (file watcher/Webhook/CI) เพื่อปลุก agent

Extensions คือการตัดสินใจออกแบบที่สำคัญที่สุดของ Pi: แทนที่จะให้ปุ่มปรับไม่กี่ปุ่ม Pi เปิด event surface ทั้งหมดใน runtime, อยากเพิ่ม memory? แทรกที่ agent/pre-step; อยากบันทึกพฤติกรรม? subscribe session events; อยากแก้ model request? hook ที่ agent/request คุณให้ Pi แก้ไข harness ของตัวมันเองได้ ซึ่งใกล้เคียงนิยาม "programmable harness" มากกว่าชุดตัวเลือกใดๆ

Feedback และ Verification: ทำให้ "การเรียนรู้" เป็นส่วนหนึ่งของ harness

Pi เองไม่มี test gate บังคับ (ผู้ใช้ต้องระบุ verification command ใน AGENTS.md เอง) แต่ community harness pi-agent-harness ใช้ extensions สร้าง "feedback loop" [3]:

  • session-summary: เก็บ PROGRESS.md แบบ rolling, ระบบ state สำหรับงานยาว
  • extract-patterns: เก็บบทเรียนจาก session ลง LESSONS.md, เปลี่ยน "ทิ้ง handoff ดีๆ ก่อนจบ session" จากธรรมเนียมเป็นกลไก
  • telemetry: บันทึก token usage, cost, observability

ไฟล์ VISION.md (เป้าหมาย), PROGRESS.md (ความคืบหน้า), LESSONS.md (บทเรียน), STANDARDS.md (มาตรฐาน) ล้วนเป็น Markdown ที่ persist ข้าม session, นี่คือ pattern "repository เป็น system of record + progress file + handoff" ที่คอร์สแนะนำ ผ่านกลไก extension ของ Pi

เปรียบเทียบกับ Claude Code และ Codex

Pi ต่างจากอีกสองตัวชัดเจน [1]:

ด้าน Pi Claude Code Codex
ปรัชญา ไม่ตัดสินใจแทนคุณ ใส่ทุกอย่างในแกนกลาง repository conventions เป็น default
Memory session tree + compaction ปรับได้ 4 ชั้น memory + auto memory เขียน state ลงไฟล์
Extension event surface เต็มรูปแบบ Skills + MCP + hooks + subagents worktree + subagents
ต้นทุน ต้องเขียน extension เอง ใช้ได้ทันที ต้องตั้ง conventions เอง

ข้อดีของ Pi: ควบคุมได้ทุกอย่าง, เรียนรู้วิธีทำงานของ harness ได้ลึกสุด, prompt-cache friendly

ข้อเสียของ Pi: ไม่มี test gate บังคับ, ต้องลงแรงเขียน extension เอง, ไม่เหมาะคนที่อยาก "แกะกล่องใช้เลย"

4 ข้อที่ควรเอาไปใช้

ข้อสรุป 4 ข้อนี้มาจากการวิเคราะห์ของคอร์ส Learn Harness Engineering [4]:

  1. ทำให้กลยุทธ์ compaction เปลี่ยนได้: "ย่อ context ยังไง" ไม่ควรเป็นค่าคงที่ hard-code แต่ควรเป็น interface ที่เปลี่ยนได้
  2. ใช้ session tree แทนการบังคับสรุป: การกู้ข้าม session ไม่ต้องพึ่ง "สรุปของเทิร์นก่อน" เสมอ, structured history replay มักน่าเชื่อถือกว่า
  3. เป็นมิตรกับ prompt cache: โหลด skill ตามต้องการ แทนการยัดทุกกฎลง system prompt, นี่คือทั้ง context engineering และ cost engineering
  4. ให้ agent แก้ไข harness ตัวเองได้: ถ้า harness เปิด extension points พอ, การ optimize พฤติกรรม agent ก็ automate ได้บางส่วน

สรุปมุมมองของผม

ผมมองว่า Pi เป็น "ปรัชญา" มากกว่า "เครื่องมือ", มันตั้งคำถามว่า "ใครควรเป็นคนตัดสินใจว่า agent ทำงานยังไง?" และตอบว่า "คุณ"

ในขณะที่ Claude Code และ Codex เลือก "ตัดสินใจให้คุณแล้ว" Pi เลือก "ให้คุณตัดสินใจเอง" ซึ่งเหมาะกับคนที่อยากควบคุมทุกอย่าง แต่มีต้นทุนคือต้องลงแรงเขียน extension เอง

ถ้าคุณเป็นคนที่ชอบ "แกะกล่องแล้วใช้ได้เลย" Pi อาจไม่ใช่ตัวเลือกแรก แต่ถ้าคุณอยากเข้าใจว่า "harness ทำงานยังไงจริงๆ" การอ่านโค้ดและ extension ของ Pi คือบทเรียนที่ดีที่สุด

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

[1] Pi. "pi.dev, Ask Pi to build what you want". 2026. https://pi.dev/

[2] Pi Coding Agent README (badlogic/pi-mono). 2026. https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/README.md

[3] pi-agent-harness (LabidySabidy). 2026. https://github.com/LabidySabidy/pi-agent-harness

[4] Learn Harness Engineering, Breaking Down Pi's Harness Design. 2026. https://github.com/walkinglabs/learn-harness-engineering

บทความนี้วิเคราะห์จาก pi.dev, badlogic/pi-mono และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka

Top comments (0)