สิ่งที่ได้เรียนรู้จากการสร้าง Pi coding agent

 (mariozechner.at)
15 คะแนน โดย GN⁺ 2026-02-02 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • pi-coding-agent เป็นเฟรมเวิร์ก coding agent ที่ออกแบบมาเพื่อลดฟีเจอร์ที่ซับซ้อนให้เหลือน้อยที่สุด และทำให้ผู้ใช้ควบคุม บริบทและความโปร่งใส ได้อย่างสมบูรณ์
  • องค์ประกอบหลักมี 4 ส่วนคือ pi-ai, pi-agent-core, pi-tui, pi-coding-agent ซึ่งรับผิดชอบด้านการรวม LLM API, agent loop, terminal UI และ CLI integration ตามลำดับ
  • รักษา system prompt และชุดเครื่องมือไว้ให้มีขนาด ต่ำกว่า 1000 โทเค็น และมุ่งสู่ ความเรียบง่ายแบบสุดขั้ว โดยมีเครื่องมือเพียง 4 อย่างคือ read/write/edit/bash
  • ตัด ข้อจำกัดด้านความปลอดภัย, sub-agent, plan mode, การรองรับ MCP ออกทั้งหมด และให้ความสำคัญกับ การสังเกตเห็นได้ทั้งหมดและอำนาจการควบคุม แทน
  • จากผล benchmark และประสบการณ์ใช้งานจริง พิสูจน์ให้เห็นว่า การออกแบบที่เรียบง่ายและโปร่งใสสามารถแข่งขันกับ agent ที่ซับซ้อนได้อย่างเพียงพอ

pi-ai และ pi-agent-core

  • pi-ai ให้บริการ API สำหรับรวมผู้ให้บริการ LLM หลากหลายราย เช่น Anthropic, OpenAI, Google, xAI, Groq
    • รองรับ streaming, tool calling, reasoning (trace), การติดตามโทเค็นและต้นทุน รวมถึง ความเข้ากันได้กับเบราว์เซอร์
    • ใช้เพียง API หลัก 4 แบบ (OpenAI Completions/Responses, Anthropic Messages, Google Generative AI) ก็สามารถสื่อสารกับโมเดลส่วนใหญ่ได้
  • รวมความต่างของ API ในแต่ละผู้ให้บริการ ไว้ในที่เดียว
    • ตัวอย่างเช่น ความแตกต่างของชื่อฟิลด์ max_tokens, ตำแหน่งของฟิลด์ reasoning, การไม่รองรับบทบาท developer เป็นต้น
    • เนื่องจากแต่ละรายรายงานโทเค็นไม่เหมือนกัน จึง ไม่สามารถคำนวณต้นทุนได้อย่างแม่นยำ และ pi-ai ติดตามแบบ best-effort
  • มีฟีเจอร์ Context handoff ที่ทำให้สามารถสลับโมเดลหรือผู้ให้บริการระหว่าง session ได้
    • เช่น เมื่อสลับจาก Anthropic → OpenAI → Google เนื้อหา reasoning จะถูกแปลงเป็นแท็ก `` และคงไว้ต่อเนื่อง
  • รองรับการนิยามโมเดลแบบ type-safe ผ่าน model registry
    • parse ข้อมูลจาก OpenRouter และ models.dev เพื่อสร้าง ข้อมูลต้นทุนและความสามารถของแต่ละโมเดล โดยอัตโนมัติ
  • รองรับ การยกเลิกคำขอ (abort) และ การคืนผลลัพธ์บางส่วน อย่างสมบูรณ์
    • เมื่อหยุด streaming ผ่าน AbortController ก็ยังสามารถนำผลลัพธ์ระหว่างทางมาใช้ได้ทันที
  • ใช้ โครงสร้างแยกผลลัพธ์ของเครื่องมือ
    • แยกข้อความสำหรับ LLM และข้อมูลสำหรับแสดงผลใน UI ออกจากกัน พร้อมตรวจสอบอาร์กิวเมนต์ด้วย TypeBox/AJV
    • ในอนาคตมีแผนเพิ่มฟีเจอร์ tool result streaming
  • agent loop จะทำซ้ำการประมวลผลข้อความ การรันเครื่องมือ และการป้อนผลลัพธ์กลับโดยอัตโนมัติ
    • ด้วยโครงสร้างแบบ event-driven จึงทำให้สร้าง UI ที่ตอบสนองได้ง่าย
    • ลดความซับซ้อนด้วยการตัดพารามิเตอร์ควบคุมที่ไม่จำเป็นออก (เช่น จำนวนขั้นสูงสุด)

pi-tui

  • pi-tui เป็น terminal UI framework บน Node.js ที่รองรับการอัปเดตแบบเรียลไทม์โดยมี flicker น้อยที่สุด
    • ใช้ differential rendering เพื่ออัปเดตเฉพาะบรรทัดที่เปลี่ยนแปลง
    • ใช้ synchronized output sequence (CSI ?2026h/l) เพื่อลด flicker ให้ต่ำที่สุด
  • ในบรรดาวิธีทำ TUI สองแนวทาง เลือกใช้ รูปแบบการแสดงผลแบบ CLI ที่คง scrollback buffer ไว้
    • ใช้ความสามารถพื้นฐานของ terminal เช่น การเลื่อนแบบธรรมชาติและการค้นหาได้ตามปกติ
    • มีโครงสร้างคล้ายกับ Claude Code, Codex, Droid
  • ใช้ Retained mode UI
    • แต่ละคอมโพเนนต์จะแคชผลการเรนเดอร์ของตัวเองไว้ และจะวาดใหม่เฉพาะเมื่อมีการเปลี่ยนแปลง
    • ทำให้อัปเดตได้อย่างมีประสิทธิภาพโดยไม่ต้อง re-render ทั้งหน้าจอ
  • ประสิทธิภาพและการใช้หน่วยความจำ อยู่ในระดับเล็กน้อย โดย session ขนาดใหญ่ก็ยังจัดการได้ลื่นไหลที่ระดับไม่กี่ร้อย KB

pi-coding-agent

  • pi-coding-agent เป็น coding agent แบบ CLI ที่มีฟีเจอร์ดังต่อไปนี้
    • รองรับ Windows/Linux/macOS, การจัดการ session (resume/branch), การสลับโมเดล, การโหลด AGENTS.md แยกตามโปรเจกต์
    • รองรับ OAuth authentication, การเปลี่ยนธีมแบบเรียลไทม์, การส่งออก session เป็น HTML, และ headless mode (JSON/RPC)
  • system prompt อยู่ในรูปแบบกระชับที่มีขนาดต่ำกว่า 1000 โทเค็น
    • ระบุเพียงเครื่องมือ 4 อย่างคือ read/write/edit/bash
    • ตัดคำอธิบายที่ไม่จำเป็นและกฎที่ซับซ้อนออก โดยผู้ใช้สามารถขยายได้อย่างอิสระผ่าน AGENTS.md
  • ชุดเครื่องมือ มีอย่างน้อยเพียง 4 รายการ
    • ใช้แค่ read, write, edit, bash ซึ่งเพียงพอสำหรับงานเขียนโค้ดส่วนใหญ่
    • เครื่องมือเพิ่มเติมสามารถเปิดใช้แบบเลือกได้ (เช่น grep, find, ls)
  • ใช้ YOLO mode เป็นค่าเริ่มต้น
    • เข้าถึงไฟล์ทั้งระบบและรันคำสั่งได้โดยไม่มีข้อจำกัด
    • ตัด security prompt และขั้นตอนตรวจสอบล่วงหน้าออก และแนะนำให้ใช้ในสภาพแวดล้อมแบบ container แทน
  • ตัด To-do ในตัว, Plan mode, MCP, Background bash, Sub-agent ออกทั้งหมด
    • To-do/Plan ถูกแทนที่ด้วย การจัดการแบบอิงไฟล์ (TODO.md, PLAN.md) ที่เรียบง่าย
    • ตัด MCP ออกเพราะ เปลืองโทเค็นและเพิ่มความซับซ้อน โดยใช้แนวทาง CLI+README แทน
    • สำหรับ Background bash แนะนำให้ใช้ tmux
    • ปิดใช้งาน Sub-agent เพราะ ขาดการมองเห็นที่ชัดเจน และหากจำเป็นให้เรียกตัวเองผ่าน bash
  • ให้ความสำคัญกับ Observability
    • คำสั่งทั้งหมด การเข้าถึงไฟล์ และผลลัพธ์ทุกอย่างจะแสดงอย่างโปร่งใส
    • แตกต่างจากโครงสร้างแบบ “black box” ของ agent อื่นอย่าง Claude Code

Benchmarks

  • ทดสอบบน Terminal-Bench 2.0 ร่วมกับโมเดล Claude Opus 4.5
    • เมื่อเทียบกับ Codex, Cursor, Windsurf ก็ได้ ประสิทธิภาพที่แข่งขันได้
    • ไฟล์ผลลัพธ์ (results.json) ถูกส่งไว้ใน public repository
  • agent แบบเรียบง่ายอย่าง Terminus 2 ก็แสดงประสิทธิภาพใกล้เคียงกัน ซึ่งพิสูจน์ ความมีประสิทธิผลของแนวทางแบบมินิมอล

บทสรุป

  • pi เป็น coding agent ที่ให้ความสำคัญกับ การควบคุมบริบท, ความเรียบง่าย, และความโปร่งใส มากกว่าฟีเจอร์ที่ซับซ้อน
  • ทั้งจากการใช้งานจริงและ benchmark แสดงให้เห็นว่า มีประสิทธิภาพทัดเทียมกับ agent ขนาดใหญ่
  • ฟีเจอร์ที่มีแผนจะเพิ่มในอนาคตมีเพียง context compaction และ tool result streaming
  • โปรเจกต์ถูกเผยแพร่เป็นโอเพนซอร์ส และรับประกัน อิสระในการ fork และขยายต่อ
  • บทเรียนสำคัญคือ “ความเรียบง่ายคือการควบคุม และการควบคุมคือประสิทธิภาพการทำงาน”

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2026-02-02
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่าเขาจะสร้างโปรเจกต์ที่ยอดเยี่ยมและใส่ใจรายละเอียดมาก
    ผมเห็นด้วยอย่างยิ่งกับความสำคัญของ context engineering และ โครงสร้างบทสนทนาแบบต้นไม้
    รูปแบบบทสนทนาเชิงเส้นแบบเดิมนั้นจำกัดเกินไป ทำให้การทำงานร่วมกับ LLM สำหรับงานวิจัยหรือการระดมความคิดไม่สะดวก
    ผมเองก็เคยทำเครื่องมือส่วนตัวด้วยแนวคิดคล้ายกัน โดยเน้นการจัดโครงสร้างคอนเท็กซ์ให้ดีแล้วนำกลับมาใช้ซ้ำ หรือแตกไปทำ side quest แล้วดึงกลับมาเฉพาะผลลัพธ์ที่ดี
    เวอร์ชันที่คุณทำมีคุณค่ากว่าในแง่การนำไปใช้จริงมาก ขอบคุณที่ทำให้ผมได้รู้จัก Pi

    • ผมก็เคยลองอะไรคล้ายกันเหมือนกัน ใช้ไฟล์ Markdown ชื่อ MIND_MAP.md จัดการในรูปแบบกราฟ พร้อมบันทึกการอ้างอิงไว้แบบอินไลน์
      วิธีนี้ช่วยคงหน่วยความจำข้ามเซสชัน และลดการเปลืองคอนเท็กซ์เวลาสร้าง sub-agent
      ดูได้ที่ โค้ดตัวอย่างของผม

  • รู้สึกว่าความสัมพันธ์ระหว่าง OpenClaw กับ Pi-agent คล้ายกับความสัมพันธ์ระหว่าง ollama/llama-cpp
    ตัวแรกเป็นฝ่ายที่ได้รับความสนใจ แต่จริง ๆ แล้วตัวหลังน่าประทับใจกว่า
    ตอนนี้ Claude Code ยังโอเคเพราะได้อานิสงส์จากสิทธิประโยชน์ของแพ็กเกจสมัครสมาชิก แต่เมื่อตลาดนิ่งลงและราคา API เข้าใกล้กันมากขึ้น ประสบการณ์พรีเมียมแบบ จ่ายตามโทเค็น น่าจะเป็นตัวเลือกที่ดีกว่า
    ท้ายที่สุดผมคิดว่า agent framework ที่ปรับแต่งได้จะเหนือกว่าแอปปิดแบบปิดตายในที่สุด

    • ผมกลับคิดว่าราคา API จะยิ่งถูกลงอีก และสิทธิประโยชน์ของการสมัคร Claude Code จะยิ่งเพิ่มขึ้น
      โครงสร้างต้นทุนของ inference มีประสิทธิภาพกว่าที่คิด และเงินทุน R&D ก็มีเพียงพอ
      ทุกเครื่องมือกำลังดีขึ้นเรื่อย ๆ และคู่แข่งเองก็ไม่ได้สมบูรณ์แบบ
    • Pi ก็ผูกกับระบบสมัครสมาชิกได้เช่นกัน OpenAI อนุญาตให้ใช้การสมัคร GPT ผ่าน Pi ได้
      ส่วนตัวผมดีใจที่โปรเจกต์ของ Peter ได้รับความสนใจ
      ฝั่ง OpenClaw ยังมี PR เข้ามาเยอะมาก แต่ Pi มีแค่ราว 1/100 เลยจัดการได้ง่ายกว่ามาก
    • แทบจะเป็นสถานการณ์เดียวกับความสัมพันธ์ระหว่าง ChatGPT กับ GPT-3
      OpenAI เองก็เคยพูดทำนองว่า “ไม่เข้าใจว่าทำไม ChatGPT ถึงดังมาก ทั้งที่ GPT ก็มีให้ใช้ผ่าน API อยู่แล้ว”
    • ก็เป็นไปได้เหมือนกันว่าสุดท้ายมันจะ enshittification (คุณภาพถดถอยลง) แบบเดียวกับ ollama
    • ชื่อ “pi” ค่อนข้างทำให้สับสนอยู่แล้ว มี “Pi” ที่ดังอยู่ก่อนแล้ว เลยสงสัยว่าทำไมถึงใช้ชื่อนี้

  • น่าแปลกใจที่ Google ยังไม่รองรับ tool call streaming
    ขนาด local tokenizer ก็ยังไม่มีให้ ทำให้ AI Studio ต้องยิง API ทุกครั้งเพื่อนับโทเค็น ซึ่งไม่มีประสิทธิภาพเลย

    • AI Studio มีบั๊กที่มันยังคงนับโทเค็นต่อแม้ไม่ได้พิมพ์อะไรอยู่
      การใช้ CPU ขึ้นไปถึง 100% จนรู้สึกว่าโน้ตบุ๊กผมกินไฟยิ่งกว่าคลัสเตอร์ TPU เสียอีก
    • จริง ๆ แล้ว Anthropic ก็ไม่ได้มี tokenizer ให้เหมือนกัน

  • มาตรการความปลอดภัยของ coding agent ตัวอื่น ๆ ส่วนใหญ่เป็นแค่ security theater
    Codex รันคำสั่งอยู่ใน OS sandbox (เช่น macOS Seatbelt) เลยไม่ได้ไร้ประโยชน์ไปเสียทีเดียว

    • ผมคิดว่า tool call ทุกอย่างที่ไม่ใช่การอ่านควรต้องผ่านการอนุมัติด้วยมือ
      ถึงจะน่ารำคาญ แต่ก็ดีกว่าต้องมาแก้คำสั่งที่พังทีหลัง
    • Codex ของผม ถ้าขอให้แพตช์ SDK ที่อยู่นอก sandbox มันก็จะใช้ Python แก้ไฟล์แทน
    • การรัน agent นอกคอนเทนเนอร์เป็นเรื่องอันตราย นี่คือพื้นฐานที่สุด
    • ผมตั้งค่า Codex ให้เชื่อมกับ GitHub repo และสร้าง PR อัตโนมัติ
      ไม่ให้แตะ DB และให้แก้เฉพาะ UI กับโค้ด middleware
    • อยากรู้ว่า Codex ปิด sandbox เองแบบตามอำเภอใจเหมือน Claude Code หรือเปล่า
    • โหมด YOLO ควรใช้แค่ในคอนเทนเนอร์เท่านั้น และควรจำกัดให้เข้าถึงเฉพาะทรัพยากรที่จำเป็น

  • ผมเห็น power user บางส่วนย้ายมาใช้ Pi แล้ว และตัวเองก็กำลังพิจารณาอยู่เหมือนกัน
    จุดเด่นของ Pi คือ การควบคุมคอนเท็กซ์ได้ทั้งหมด และ โครงสร้างเครื่องมือที่ขยายได้
    มีตัวอย่างหลากหลายทั้ง system prompt, การขยาย todo, MCP adapter เป็นต้น
    ถ้าคุณเข้าใจข้อจำกัดด้านประสิทธิภาพของคอนเท็กซ์ หรือปัญหาอย่าง context rot และ contextual drift คุณจะเห็นคุณค่าของ Pi ได้ชัดเจน
    รวมลิงก์ที่เกี่ยวข้อง

    • Pi คือส่วนที่ควรได้รับความสนใจมากที่สุดใน moltXYZ
      Armin นำยุคไปชัดเจน
      Claude Code ยังตื้นอยู่มากทั้งในแง่ hook และการจัดการคอนเท็กซ์

  • ตอนนี้ผมยังใช้ Cursor อยู่
    เคยพยายามจะย้ายไป Claude Code แต่กับ codebase เล็ก ๆ ของผม Cursor เร็วกว่ามาก
    เพียงแต่ UI สำหรับรีวิว diff ไม่ผสานกับ Git เลยทำให้ใช้งานลำบาก
    แยกได้ยากว่าการเปลี่ยนแปลงไหน AI ทำและอันไหนผมทำเอง และผมรู้สึกว่าการรีวิวที่ผูกกับ Git สำคัญกว่า

    • จุดแข็งของ Cursor คือ วงจร feedback ที่สั้น
      ส่วน Claude Code ให้ความรู้สึกเหมือนต้องฝากความหวังไว้กับผลลัพธ์เลยทำให้ไม่ค่อยสบายใจ
      การสลับโมเดลได้อย่างอิสระคือหัวใจสำคัญ เพราะประสิทธิภาพของโมเดลต่างกันไปตามภาษาและประเภทงาน
    • ถ้าติดตั้ง ส่วนขยาย Claude Code สำหรับ VS Code ก็จะได้ทั้งความสามารถในการสำรวจ codebase ขนาดใหญ่และการผสานกับ CC พร้อมกัน
    • Claude Code ไม่มี project index มาให้โดยพื้นฐาน เลยต้องไล่สำรวจไฟล์ทีละไฟล์
      ผมเลยทำ hook ที่ใส่รายการไฟล์เข้าไปในคอนเท็กซ์ตอนเริ่มต้นเพื่อให้เร็วขึ้น
      ยังทำเครื่องมือ custom ที่แก้หลายไฟล์พร้อมกันได้จนเร็วขึ้นประมาณ 3 เท่า แต่สุดท้ายปิดไปเพราะมีบางเคสขอบที่ทำให้เกิดปัญหา
    • ผมก็เป็น solo developer แบบ bootstrap เหมือนกัน และใช้ Claude เพื่อ ทำงานเล็ก ๆ ให้เป็นอัตโนมัติ
      เช่น เทสต์ frontend อัตโนมัติ หรือแก้หน้า landing page
      ส่วนฟีเจอร์หลักผมจะจัดการในวงจร feedback ที่ใกล้ชิดผ่าน Claude อีกอินสแตนซ์หนึ่ง
    • Cursor เองก็กำลังพัฒนาอยู่ อีกไม่นานจะมีฟีเจอร์ AI-authored line tracking (blame) ที่ทำให้ดูได้ว่าโมเดลไหนเขียนอะไรจากพรอมป์ต์ไหน

  • บทความเรื่อง สถาปัตยกรรม agent แบบมินิมัล น่าประทับใจมาก
    ผมชอบแนวคิดที่ว่า “ถ้ายังไม่จำเป็น ก็อย่าเพิ่งสร้าง”
    ผมใช้ OpenClaw จัดการหลาย workflow แบบขนาน — ทั้งซัพพอร์ตลูกค้า, มอนิเตอร์การ deploy, รีวิวโค้ด ฯลฯ
    หัวใจสำคัญคือ context engineering
    โมเดลแบบ workspace-first ของ OpenClaw ใช้ AGENTS.md, TOOLS.md และไดเรกทอรี memory/ เพื่อให้การเรียนรู้ต่อเนื่องข้ามเซสชัน
    คุณสามารถดู log ของกระบวนการที่ agent เรียนรู้ด้วยตัวเองได้
    ผมชอบแนวทางที่ยอมรับ threat model ตามความเป็นจริง มากกว่าจะเล่นบทละครความปลอดภัย
    และก็เห็นด้วยว่าการมี agent เฉพาะทางหลายตัวทำงานขนานกันดีกว่าตัวเดียวที่พยายามเป็น万能
    ถ้าเอา Pi กับ OpenClaw ไปเทียบกันบน Terminal-Bench ก็น่าจะน่าสนใจ

  • ผมชอบบทความที่อธิบายว่าเหตุใด Armin Ronacher ถึงใช้ Pi
    ผมเพิ่งรู้จาก โพสต์ของ Armin ว่า Pi เป็น agent harness ของ OpenClaw

  • Pi มี โครงสร้างที่อิง JavaScript เลยเข้ากับสถาปัตยกรรม browser sandbox ได้ดี
    ผมคิดว่ามันเหมาะกับทิศทางอนาคตของ AI agent
    แต่ก็อยากให้ผู้เขียนยืดหยุ่นกับ vendor extensions มากกว่านี้หน่อย
    การสนทนาที่เกี่ยวข้อง

    • ประโยคที่ว่า “ทำให้ส่วนตัดกันเป็นมาตรฐาน แล้วเปิดเผยส่วนรวม” น่าประทับใจมาก

  • ตอนนี้ผมยังไม่ใช้ โหมด YOLO
    คิดว่าเครื่องมือจะพร้อมจริง ๆ คงต้องใช้เวลาอีกสัก 6 เดือน
    ในทางปฏิบัติแทบไม่มีเหตุผลที่ agent ต้องไปรันคำสั่งตามอำเภอใจ
    แค่รวม lint, การค้นหา, การแก้ไข, และการเข้าถึงเว็บ เข้าไว้ในระบบสิทธิ์ก็เพียงพอแล้ว
    ถ้าเป็น runtime ที่มี sandboxing และการควบคุมสิทธิ์อย่าง Deno หรือ Workerd ก็ถือเป็นแนวป้องกันชั้นแรกได้
    เพราะงั้นจึงเข้าใจได้ยากว่าทำไม Anthropic ถึงเลือก Bun — มันแทบไม่มีสถาปัตยกรรมความปลอดภัยเลย