เมื่อเร็วๆ นี้ โครงการเฟรมเวิร์ก Agent ชื่อ openClaw แสดงผลงานโดดเด่นในการทดสอบมาตรฐาน Terminal-Bench เอาชนะคู่แข่งที่มีคุณสมบัติหลากหลายได้มากมาย แกนหลักเบื้องหลังคือปรัชญาของนักพัฒนา Zechner Mario Zechner: เขาเบื่อกับเครื่องมืออย่าง Claude Code ที่กลายเป็นเหมือน “ยานอวกาศที่มีฟังก์ชัน 80% ที่ไม่ได้ใช้” เขาจึงตัดสินใจสร้างผู้ช่วยเขียนโค้ด AI แบบมินิมอลด้วยตัวเอง หลักการของเขาง่ายมาก: ถ้าไม่ต้องการฟังก์ชันนั้น ก็จะไม่สร้างมัน
สิ่งที่กำเนิดขึ้นในที่สุดคือ pi-mono ผู้ช่วยเขียนโค้ดที่ลดจำนวนเครื่องมือลงเหลือเพียงสี่อย่าง
จากการคัดลอกวางสู่มินิมอลลิสต์
เส้นทางการพัฒนาของ Zechner น่าสนใจเป็นอย่างยิ่ง ในสามปีที่ผ่านมา เขาเริ่มจากการคัดลอกวางโค้ดไปยัง ChatGPT ไปสู่การเติมข้อความอัตโนมัติของ Copilot (เขายอมรับว่าไม่เคยใช้ได้ดีเลย) ตามด้วย Cursor และสุดท้ายในปี 2025 ก็คือผู้ช่วยเขียนโค้ดอย่าง Claude Code, Codex, Amp, Droid, opencode ที่กลายเป็นเครื่องมือประจำวัน
ตอนแรกเขาชอบ Claude Code เพราะเวอร์ชันแรกๆ นั้นพื้นฐานและเรียบง่าย สอดคล้องกับบุคลิกที่เขา “ชอบเครื่องมือที่เรียบง่ายและคาดเดาได้” แต่หลังจากผ่านไปหลายเดือน Claude Code กลับซับซ้อนขึ้นเรื่อยๆ คำสั่งระบบและคำจำกัดความเครื่องมือเปลี่ยนบ่อยครั้ง ทำลายเวิร์กโฟลว์ของเขา และปัญหาหน้าจอกระพริบยิ่งทำให้แย่ลง
ในฐานะนักพัฒนาที่เคยสร้างโปรเจกต์ Agent หลายอย่างเช่น Sitegeist Zechner เข้าใจดีถึงความสำคัญของวิศวกรรมบริบท การควบคุมบริบทของโมเดลอย่างแม่นยำสามารถเพิ่มคุณภาพการสร้างโค้ดได้อย่างมีนัยสำคัญ แต่เครื่องมือที่มีอยู่มักจะฉีดเนื้อหาที่มองไม่เห็นในแบ็กกราวด์ ทำให้การควบคุมที่แม่นยำทำได้ยากอย่างยิ่ง
ปรัชญาของเครื่องมือสี่อย่าง
pi-mono รักษาเฉพาะเครื่องมือหลักสี่อย่างเท่านั้น:
read # อ่านเนื้อหาไฟล์ รองรับข้อความและรูปภาพ สามารถระบุช่วงบรรทัดได้
write # สร้างไฟล์ใหม่หรือเขียนทับทั้งหมด สร้างไดเรกทอรีอัตโนมัติ
edit # แทนที่ข้อความอย่างแม่นยำ oldText ต้องตรงกันทุกประการ
bash # รันคำสั่ง ส่งคืน stdout และ stderr ตั้งค่า timeout ได้
ตรรกะของ Zechner ตรงไปตรงมาอย่างยิ่ง: แก่นแท้ของการเขียนโปรแกรมคือการอ่านโค้ด เขียนโค้ด แก้ไขโค้ด รันโค้ด การผสมผสานเครื่องมือสี่อย่างนี้เพียงพอที่จะครอบคลุมสถานการณ์การเขียนโปรแกรมส่วนใหญ่
ตัวอย่างเช่น เมื่อวิเคราะห์โครงสร้างโปรเจกต์ AI จะ read ไฟล์หลักสองสามไฟล์ เมื่อแก้ไขบั๊ก มันจะระบุตำแหน่งปัญหา ใช้ edit แก้ไขบรรทัดเฉพาะ จากนั้น bash รันทดสอบเพื่อยืนยัน เมื่อต้องการปรับโครงสร้างใหม่ มันจะเข้าใจตรรกะที่มีอยู่ write การนำไปใช้ใหม่ และตรวจสอบให้แน่ใจว่าฟังก์ชันยังคงเหมือนเดิม
สถาปัตยกรรมเทคโนโลยีสี่ชั้น
Zechner สร้างสแต็กเทคโนโลยีทั้งหมดตั้งแต่ต้น:
┌─────────────────────────────────────┐
│ pi-coding-agent │ ← ชั้นเครื่องมือ CLI
│ (การจัดการเซสชัน, ธีม, ไฟล์บริบท) │
├─────────────────────────────────────┤
│ pi-tui │ ← ชั้น UI เทอร์มินัล
│ (การเรนเดอร์แบบดิฟเฟอเรนเชียล, ระบบคอมโพเนนต์) │
├─────────────────────────────────────┤
│ pi-agent-core │ ← ชั้นตรรกะ Agent
│ (การดำเนินการเครื่องมือ, สตรีมเหตุการณ์, การตรวจสอบ) │
├─────────────────────────────────────┤
│ pi-ai │ ← ชั้นนามธรรม LLM
│ (API ผู้ให้บริการหลายราย, การสลับบริบท, การติดตามต้นทุน) │
└─────────────────────────────────────┘
pi-ai คือชั้น API LLM ที่เป็นหนึ่งเดียว รองรับผู้ให้บริการมากกว่าสิบราย เช่น Anthropic, OpenAI, Google, xAI, Groq, Cerebras, OpenRouter การจัดการความแตกต่างของ API จากผู้ให้บริการต่างๆ เป็นงานวิศวกรรมที่ซับซ้อน:
// ตัวอย่างความแตกต่างของผู้ให้บริการ
const providerQuirks = {
cerebras: { disallowedFields: ['store'] },
mistral: {
tokenField: 'max_tokens', // แทนที่จะเป็น max_completion_tokens
disallowedFields: ['store', 'developer']
},
grok: { disallowedFields: ['reasoning_effort'] }
};
การสลับบริบทข้ามผู้ให้บริการเป็นฟังก์ชันการออกแบบหลัก ตัวอย่างเช่น เมื่อสลับจาก Anthropic ไปยัง OpenAI แทร็กการคิดของ Anthropic จะถูกแปลงอัตโนมัติเป็นบล็อกเนื้อหาในข้อความของผู้ช่วย
pi-tui คือเฟรมเวิร์ก UI เทอร์มินัลแบบมินิมอลที่ใช้เทคโนโลยีการเรนเดอร์แบบดิฟเฟอเรนเชียล Zechner เติบโตมาในยุค DOS และมีความผูกพันลึกซึ้งกับอินเทอร์เฟซเทอร์มินัล แต่เขาไม่ต้องการเขียน TUI ในแบบของ React
เพื่อป้องกันการกระพริบของอินเทอร์เฟซ pi-tui ใช้ลำดับการหลีกหนีเอาต์พุตแบบซิงโครนัสห่อหุ้มการดำเนินการเรนเดอร์ทั้งหมด ในเทอร์มินัลสมัยใหม่อย่าง Ghostty หรือ iTerm2 สามารถให้ประสบการณ์ที่ไร้การกระพริบโดยสมบูรณ์ ซึ่งดีกว่า Claude Code
ไอเดียอันชาญฉลาดในการจัดการเซสชัน
การสนทนาถูกเก็บในรูปแบบ JSONL แต่ละข้อความมี id และ parentId ก่อตัวเป็นโครงสร้างแบบต้นไม้:
{"id": "1", "parentId": null, "role": "user", "content": "ช่วยเขียนฟังก์ชันให้หน่อย"}
{"id": "2", "parentId": "1", "role": "assistant", "content": "ได้เลย เดี๋ยวช่วยเขียนให้..."}
{"id": "3", "parentId": "2", "role": "user", "content": "เปลี่ยนให้เป็นแบบอะซิงโครนัส"}
{"id": "4", "parentId": "2", "role": "user", "content": "เพิ่มการจัดการข้อผิดพลาด"} // สาขา
คำสั่ง /tree สามารถแสดงแผนผังการสนทนาแบบเห็นภาพได้ /fork ใช้สำหรับสร้างสาขา การสนทนายาวจะทริกเกอร์การบีบอัดอัตโนมัติ ระบบยังรองรับการพูดแทรกขณะที่ AI กำลังทำงาน: กด Enter เพื่อส่งข้อความ steering เพื่อขัดจังหวะการเรียกใช้เครื่องมือที่เหลือ; กด Alt+Enter เพื่อส่งข้อความ follow-up รอให้งานปัจจุบันเสร็จสิ้นก่อนจึงจะประมวลผล
ระบบส่วนขยาย: พรีมิทีฟ ไม่ใช่ฟังก์ชัน
หนึ่งในการออกแบบที่ชาญฉลาดที่สุดของ pi-mono คือระบบส่วนขยาย ฟังก์ชันซับซ้อนที่เครื่องมืออื่นมีในตัว ผู้ใช้สามารถสร้างเองได้ผ่านส่วนขยาย TypeScript เช่น: ซับเอเจนต์, โหมดวางแผน, การควบคุมสิทธิ์, การป้องกันเส้นทาง, การดำเนินการ SSH, การแยกแซนด์บ็อกซ์, การผสานรวม MCP, หรือแม้แต่การรันเกม Doom
ถ้าไม่อยากเขียนเอง ก็สามารถให้ผู้ช่วย pi เขียนให้ หรือติดตั้งแพ็กเกจชุมชนโดยตรง:
pi install npm:@foo/pi-tools
pi install git:github.com/badlogic/pi-doom
ภูมิปัญญาของ “รายการไม่ทำ”
ที่น่าสนใจยิ่งกว่าคือ “รายการไม่ทำ” ที่ชัดเจนของ Zechner pi-mono ปฏิเสธอย่างแน่วแน่ที่จะมีฟังก์ชัน “มาตรฐาน” หลายอย่างในตัว:
ไม่รองรับ MCP เซิร์ฟเวอร์ MCP ที่เป็นที่นิยมจะใช้บริบทจำนวนมาก:
Playwright MCP: 21 เครื่องมือ, 13.7k โทเค็น
Chrome DevTools MCP: 26 เครื่องมือ, 18k โทเค็น
ใช้พื้นที่หน้าต่างบริบท 7-9% เครื่องมือหลายอย่างไม่ได้ใช้
ทางเลือกคือการสร้างเครื่องมือ CLI พร้อม README เมื่อ Agent ต้องการจึงค่อยอ่านเอกสาร ทำให้เกิดการเปิดเผยแบบค่อยเป็นค่อยไป และใช้โทเค็นได้มีประสิทธิภาพมากขึ้น
ไม่ทำซับเอเจนต์ เครื่องมืออย่าง Claude Code มักจะสร้างซับเอเจนต์ที่มองไม่เห็นเพื่อจัดการงานที่ซับซ้อน สิ่งนี้กลายเป็น “กล่องดำในกล่องดำ” pi-mono ใช้วิธีที่โปร่งใส โดยเรียกใช้ตัวเองผ่าน bash โดยตรง ทำให้กระบวนการสังเกตได้ทั้งหมด:
# ตัวอย่างซับเอเจนต์
pi --print --model claude-3-5-sonnet "Review this code: $(cat app.py)"
# หรือได้การสังเกตการณ์เต็มที่ใน tmux
tmux new-session -d "pi --session review 'Review the auth module'"
ไม่ทำโหมดวางแผน pi-mono ไม่มีระบบการวางแผนหรือ TODO ที่ซับซ้อนในตัว เมื่อต้องการวางแผนที่คงทน ให้เขียนลงไฟล์โดยตรง เมื่อต้องการงานแบ็กกราวด์ ให้ใช้เครื่องมือมาตรฐานเช่น tmux ในการจัดการเซสชัน
พรอมต์ระบบแบบมินิมอลสุดๆ
พรอมต์ระบบของ pi-mono นั้นกระชับมาก ความยาวทั้งหมดน้อยกว่า 1000 โทเค็น:
You are an expert coding assistant. You help users with coding tasks
by reading files, executing commands, editing code, and writing new files.
Available tools:
- read: Read file contents
- bash: Execute bash commands
- edit: Make surgical edits to files
- write: Create or overwrite files
Guidelines:
- Use bash for file operations like ls, grep, find
- Use read to examine files before editing
- Use edit for precise changes (old text must match exactly)
- Use write only for new files or complete rewrites
- Be concise in your responses
- Show file paths clearly when working with files
เมื่อเทียบกับพรอมต์ที่ยาวเหยียดหลายหมื่นโทเค็นของเครื่องมืออื่น การออกแบบนี้ดูสุดโต่งมาก นักพัฒนา Zechner คิดว่าโมเดลล้ำสมัยที่ผ่านการเรียนรู้แบบเสริมกำลัง (RL) มาแล้วจำนวนมากเข้าใจแนวคิดของผู้ช่วยเขียนโปรแกรมโดยธรรมชาติอยู่แล้ว ไม่จำเป็นต้องมีคู่มืออธิบายยาวเป็นหมื่นคำ
การเลือกของ OpenClaw
การที่ OpenClaw เลือก pi-mono เป็นเฟรมเวิร์กพื้นฐาน พิสูจน์ถึงคุณค่าของการออกแบบ SDK ที่เรียบง่ายของ pi-mono ทำให้การผสานรวมเป็นไปโดยตรงมาก:
import { createAgentSession } from "@mariozechner/pi-coding-agent";
const { session } = await createAgentSession({
sessionManager: SessionManager.inMemory(),
authStorage: new AuthStorage(),
modelRegistry: new ModelRegistry(),
});
await session.prompt("What files are in the current directory?");
วิธีการผสานรวมแบบนี้เผยให้เห็นความจริง: แกนกลางที่เรียบง่าย ร่วมกับความสามารถในการขยายที่ทรงพลัง มักจะเชื่อถือได้มากกว่าโซลูชันแบบรวมศูนย์ที่ซับซ้อน
การยืนยันด้วยการทดสอบมาตรฐาน
สิ่งที่โน้มน้าวใจที่สุดคือผลการทดสอบมาตรฐาน Zechner ใช้ pi-mono ร่วมกับ Claude Opus 4.5 ทดสอบเต็มรูปแบบบน Terminal-Bench 2.0 ทดลองแต่ละงานห้าครั้ง ผลลัพธ์แสดงว่า pi-mono ทำได้ดีเยี่ยม อยู่ในอันดับต้นๆ ของกระดานคะแนน
ที่น่าสนใจยิ่งกว่านั้นคือ Terminus 2 ของทีม Terminal-Bench เองก็ใช้วิธีมินิมอลที่คล้ายกัน: ให้โมเดลแค่เซสชัน tmux เดียว ให้โมเดลส่งคำสั่งผ่านข้อความและแยกวิเคราะห์เอาต์พุตเทอร์มินัล ไม่มีเครื่องมือหรูหรา ไม่มีการดำเนินการไฟล์พิเศษ มีเพียงการโต้ตอบเทอร์มินัลดั้งเดิม อย่างไรก็ตาม มันก็ทำได้ดีในกระดานคะแนนเช่นกัน ซึ่งยืนยันเพิ่มเติมถึงประสิทธิผลของวิธีมินิมอล
โหมดการทำงานสี่แบบ
pi # โหมดโต้ตอบเริ่มต้น
pi -p "คำอธิบายงาน" # ดำเนินการครั้งเดียว
pi --mode json # เอาต์พุตข้อมูลที่มีโครงสร้าง
pi --mode rpc # การสื่อสารระหว่างกระบวนการ
pi @file1.js @file2.js "ปรับโครงสร้างไฟล์เหล่านี้ใหม่" # ประมวลผลไฟล์แบบแบทช์
มันรองรับบริการสมัครสมาชิกและยืนยันตัวตนด้วย API key จากผู้ให้บริการ AI หลัก การสลับโมเดลทำได้ง่ายมาก:
pi --model claude-3-5-sonnet
pi --model openai/gpt-4o
pi --model sonnet:high # ระบุระดับการคิด
สัจนิยมของโหมด YOLO
pi-mono ทำงานใน “โหมด YOLO” โดยค่าเริ่มต้น ซึ่งมีสิทธิ์เข้าถึงระบบไฟล์โดยไม่จำกัด Zechner คิดว่ามาตรการความปลอดภัยของเครื่องมืออื่นๆ หลายอย่างดูเหมือน “โรงละครความปลอดภัย” มากกว่า
Simon Willison เคยเสนอโหมด “LLM คู่” เพื่อพยายามแก้ไขปัญหาความปลอดภัย แต่ตัวเขาเองก็ยอมรับว่า “โซลูชันนี้แย่มาก” ความขัดแย้งหลักคือ: ถ้า LLM มีความสามารถในการอ่านข้อมูล รันโค้ด และเข้าถึงเครือข่ายพร้อมกัน นักพัฒนาก็จะติดอยู่ในเกม “ตีตุ่น” กับเวกเตอร์โจมตี
เนื่องจากไม่สามารถแก้ไขปัญหาความปลอดภัยที่เกิดจาก “ทริโอแห่งความสามารถ” นี้ได้ตั้งแต่รากฐาน pi-mono จึงเลือกที่จะยอมรับความเป็นจริงอย่างสงบ อย่างไรก็ตาม เพื่อเพิ่มประสิทธิภาพ ผู้ใช้ส่วนใหญ่สุดท้ายก็มักจะรันในโหมดที่คล้ายกับ YOLO อยู่ดี
คุณค่าของมินิมอลลิสต์
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
☕ สนับสนุนค่ากาแฟทีมงาน
หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay
本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/22884