dirac - เอเจนต์ AI โอเพนซอร์สที่แม่นยำและมีประสิทธิภาพด้านโทเคนสูง

 (github.com/dirac-run)
3 คะแนน โดย GN⁺ 2026-04-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มุ่งเน้นที่ การคัดสรรคอนเท็กซ์อย่างหนาแน่น และ การปรับสมดุลประสิทธิภาพต่อการใช้เครื่องมือให้เหมาะสมที่สุด เพื่อลดปัญหาที่ประสิทธิภาพการให้เหตุผลแกว่งเมื่ออยู่ในคอนเท็กซ์ยาว
  • อ้างอิงจาก gemini-3-flash-preview ทำสถิติ Terminal-Bench-2 65.2% และทำสำเร็จ 8/8 งาน ในงานรีแฟกเตอร์ที่ซับซ้อน 8 รายการบน GitHub repository แบบสาธารณะ
  • ผสาน Hash-Anchored Edits, Multi-File Batching และการแก้ไขที่รับรู้โครงสร้าง เพื่อจัดการหลายไฟล์ด้วยจำนวนรอบโต้ตอบที่น้อยลง พร้อมแก้ไขโดยสะท้อนโครงสร้างไวยากรณ์ของภาษาอย่าง TypeScript, Python และ C++
  • รองรับการอ่าน·เขียนไฟล์, คำสั่งเทอร์มินัล และ เบราว์เซอร์แบบ headless พร้อมมอบทั้งเวิร์กโฟลว์แบบอิงการอนุมัติและการทำงานผ่าน CLI เช่น Plan Mode, Yolo Mode และการกลับมาทำงานต่อจากประวัติงาน
  • ชูจุดเด่นค่าใช้จ่ายเฉลี่ย $0.18 และ ลดต้นทุน 64.8% เมื่อเทียบกับเครื่องมือคู่แข่ง โดยโดดเด่นที่ยกระดับทั้งประสิทธิภาพและต้นทุนในงานใช้งานจริงโดยไม่พึ่งข้อมูลเฉพาะสำหรับเบนช์มาร์ก

ประสิทธิภาพหลัก

  • ผลลัพธ์เบนช์มาร์ก

    • ทำได้ถูกต้อง 8/8 ในทั้ง 8 งาน และในกลุ่มที่เปรียบเทียบมีเพียง Opencode เท่านั้นที่ทำได้ 8/8 เท่ากัน
    • ค่าใช้จ่ายเฉลี่ยอยู่ที่ $0.18 ซึ่งต่ำกว่า Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38, Roo $0.60
    • README ระบุว่า Dirac ถูกกว่าคู่แข่ง 64.8% และลดต้นทุนได้ 2.8 เท่า เมื่อวัดตามค่าใช้จ่าย
    • ดูคำอธิบายงานและวิธีวิทยาโดยละเอียดได้ที่ evals/README.md

  • ลักษณะต้นทุนรายงาน

    • ในแต่ละงานรีแฟกเตอร์รวมถึง repository transformers, vscode, django ส่วนใหญ่ทำได้ด้วยต้นทุน ต่ำสุดหรือใกล้ต่ำสุด
    • ตัวอย่างเช่น งาน DynamicCache ของ transformers อยู่ที่ $0.13, งาน datadict ของ django อยู่ที่ $0.08, และงาน sendRequest ของ vscode อยู่ที่ $0.25
    • แม้เครื่องมือคู่แข่งบางตัวจะได้ผลลัพธ์เป็น Incomplete หรือ Failure แต่ Dirac ถูกระบุเป็น Success ในทั้ง 8 งานในตาราง

แนวทางและการออกแบบ

  • คอนเท็กซ์และกลยุทธ์การแก้ไข

    • ใช้ Hash-Anchored Edits เพื่อกำหนดตำแหน่งแก้ไขโดยอิงจากแฮชของบรรทัดที่เสถียร ช่วยหลีกเลี่ยงปัญหา "lost in translation" ของการแก้ไขแบบอิงเลขบรรทัดดั้งเดิม
    • ใช้ Multi-File Batching เพื่ออ่านและแก้ไขหลายไฟล์ในรอบโต้ตอบกับ LLM เพียงครั้งเดียว ลดทั้ง latency และค่าใช้จ่าย API
    • ปรับแต่ง High-Bandwidth Context ให้คงไว้เฉพาะข้อมูลที่เกี่ยวข้องมากที่สุด เพื่อลดการสิ้นเปลืองโทเคนและทำให้เอเจนต์ยังคงเบาและรวดเร็ว
    โฆษณา

  • การแก้ไขแบบรับรู้โครงสร้าง

    • ฝัง AST-Native Precision มาในตัว ทำให้ทำงานโดยเข้าใจโครงสร้างไวยากรณ์ของภาษาอย่าง TypeScript, Python, C++ เป็นต้น
    • ระบุว่าสามารถทำ การจัดการเชิงโครงสร้าง เช่น การแยกฟังก์ชันหรือรีแฟกเตอร์คลาส ได้ด้วยความแม่นยำ 100%

  • โมเดลการใช้เครื่องมือ

    • รองรับการอ่านและเขียนไฟล์, การรันคำสั่งเทอร์มินัล และการใช้งาน เบราว์เซอร์แบบ headless
    • เวิร์กโฟลว์การทำงานยังคงเป็น เวิร์กโฟลว์แบบอิงการอนุมัติ เพื่อให้ผู้ใช้ยังมีอำนาจควบคุม
    • การรองรับโมเดลจำกัดเฉพาะกรณีที่มี native tool calling ได้ เพื่อเหตุผลด้านความน่าเชื่อถือและประสิทธิภาพ
    • อ้างอิงตาม README ว่า ไม่รองรับ MCP

วิธีใช้งานและการปรับแต่ง

  • การควบคุมพฤติกรรมตามโปรเจกต์

    • สามารถใช้ไฟล์ AGENTS.md เพื่อกำหนด คำสั่งเฉพาะโปรเจกต์ และปรับแต่งพฤติกรรมการทำงานได้
    • อ่านไดเรกทอรี .ai, .claude, .agents โดยอัตโนมัติเพื่อใช้งาน Claude skills ร่วมกัน
    โฆษณา

  • โฟลว์การใช้งาน CLI

    • หลังยืนยันตัวตนด้วย dirac auth แล้ว สามารถรันงานแบบ dirac "Analyze the architecture of this project" ได้
    • dirac -p "prompt" คือการใช้งาน Plan Mode เพื่อดูกลยุทธ์ก่อน
    • dirac -y "prompt" คือ Yolo Mode ที่อนุมัติทุกการทำงานโดยอัตโนมัติ
    • สามารถส่งคอนเท็กซ์ผ่าน pipe input ได้โดยตรง เช่น git diff | dirac "Review these changes"
    • ใช้ dirac history เพื่อดูงานก่อนหน้าและกลับมาทำต่อได้

  • การผสานกับ VS Code

    • ติดตั้งส่วนขยายได้จาก VS Code Marketplace
    • เปิดแถบด้านข้างของ VS Code ตั้งค่า ผู้ให้บริการ AI ที่ต้องการ เช่น Anthropic, OpenAI, OpenRouter แล้วเริ่มงานใหม่ได้

สภาพแวดล้อมการรันและการเชื่อมต่อผู้ให้บริการ

  • API key และตัวแปรแวดล้อม

    • สามารถรับค่าผ่านตัวแปรแวดล้อม เช่น ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN เพื่อข้ามขั้นตอนการยืนยันตัวตน
    • รายการทั้งหมดอยู่ใน src/shared/storage/env-config.ts

  • รองรับ AWS Bedrock

    • หากตั้งค่า AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN พร้อมกับ AWS_BEDROCK_MODEL หรือ AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN ระบบจะสลับเป็น Bedrock provider โดยอัตโนมัติ
    • มีตัวอย่างการรันร่วมกับ aws-vault
    • Claude รุ่นใหม่อย่าง Sonnet 4.6 ขึ้นไป ต้องใช้ cross-region inference profile prefix เช่น us., eu., ap. และแนะนำให้อ้างอิง model ID ที่รองรับจาก AWS docs
    โฆษณา

พื้นหลังของโปรเจกต์

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

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

 
GN⁺ 2026-04-28
ความเห็นจาก Hacker News

  • สิ่งที่น่าสนใจใน Dirac สำหรับผมคือส่วนพวกนี้
    มันแก้ไขไฟล์ด้วยเวอร์ชันที่ปรับให้เหมาะสมของ Hash-Anchored edits และใช้ AST ของภาษาเพื่อตัดสินใจว่าจะใส่โค้ดส่วนไหนเข้าไปในคอนเท็กซ์ จึงไม่ต้องอ่านไฟล์โค้ดขนาดใหญ่ทั้งไฟล์
    งานทั้งหมดถูกรวมเป็นแบตช์เพื่อจัดการการอ่าน/แก้ไขจำนวนมากพร้อมกัน และถ้าโมเดลต้องการก็ให้รันสคริปต์ bash/python/perl โดยตรงเพื่อวิเคราะห์สดได้ด้วย
    อีกอย่างคือมันจัดการคอนเท็กซ์ค่อนข้างละเอียด โดยอัปเดตในลักษณะใส่ข้อมูลที่โมเดลแทบจะแน่นอนว่าจะขอต่อไปไว้ล่วงหน้า

    • ผมสงสัยมาตลอดว่าทำไม AST ถึงไม่ถูกใช้แพร่หลายกว่านี้กับการแก้ไขโค้ดหรือการอนุมานขอบเขตการเปลี่ยนแปลง
      ก่อนหน้านี้เคยมีบทความหนึ่งบอกว่า grep ก็ได้ผลใกล้เคียงกัน และในบริบทนั้นผมก็พอเข้าใจว่าเพราะอะไร
    • การแก้ไขแบบยึดแองเคอร์ต้องใส่แองเคอร์ใหม่เข้าไปในคอนเท็กซ์ และ Dirac เองก็ดูเหมือนจัดการแบบนั้นผ่าน diff ดังนั้นผมเลยไม่แน่ใจว่ามันมีประสิทธิภาพกว่า search and replace ในแง่โทเค็นจริงหรือเปล่า
      ต่อให้แฮชเป็นแค่หนึ่งโทเค็นก็เถอะ และโค้ดก็อ่านมากกว่าเขียน ต้นทุนสะสมเลยยิ่งสูง
      ก่อนหน้านี้ตอนผมทดลองกับ stable anchors ที่ยาวกว่า ก็กลับรู้สึกเหมือนแย่ลง และประสิทธิภาพของ Dirac น่าจะมาจากการแสดงแค่โครงของไฟล์เป็นหลักมากกว่า
    • ผมไม่เข้าใจว่า Batches all operations คืออะไรเลยไปดูซอร์สมา แล้วดูเหมือนว่ามันหมายถึงตัว tool API เองถูกออกแบบให้รับหลายเป้าหมายเป็นลิสต์ แทนที่จะหวังว่าโมเดลจะเรียกเครื่องมือแบบขนานได้ดี
      จากประสบการณ์ผม โมเดลมักไม่ค่อยยอมเรียกแบบขนานจำนวนมากทีเดียว โดยเฉพาะโมเดลที่อ่อนกว่าจะยิ่งเป็นแบบนั้น
    • ผมสงสัยว่าการใช้โมเดลเฉพาะทางราคาถูกมากที่ทำมาเพื่อแก้ไขไฟล์โดยตรง จะดีกว่าเอาโทเค็นไปเผากับ SOTA model หรือเปล่า
      โมเดลระดับบนก็ดูเหมือนจะสามารถสร้างและแค่เรียกใช้โมเดลแก้ไขที่ถูกกว่านั้นได้ด้วย
    • ถ้าใช้ AST ของภาษาเพื่อกำหนดคอนเท็กซ์ที่จะดึงมา โครงสร้างนี้ก็จะทำงานได้เฉพาะกับ ภาษาที่มี parser ใช่ไหม อันนี้ผมสงสัย

  • น่าสนใจมากว่า AI harness ส่งผลต่อประสิทธิภาพได้มากแค่ไหน
    การขึ้นจาก 48% เป็น 65% จากผลทางการของ Google ถือว่าต่างกันมหาศาล แต่แม้จะเห็นการเปรียบเทียบโมเดลเยอะ ผมแทบไม่เคยเห็นผลเปรียบเทียบที่ใช้โมเดลเดียวกันแล้วเปลี่ยนแค่ harness เลย
    สงสัยว่ามีลีดเดอร์บอร์ดที่เทียบประสิทธิภาพ harness ภายใต้โมเดลเดียวกันไหม

    • น่าจะต้องเทียบทั้งเดการ์ตโปรดักต์ของ model+harness เลยมากกว่า
    • อันที่ถูกอ้างถึงมากที่สุดน่าจะเป็น terminal bench 2.0 แต่ที่นั่นก็ยังหนีข้อสงสัยเรื่อง cheating และปัญหา benchmaxxing ไม่พ้น
      ที่ค่อนข้างน่าแปลกคือ Claude Code บน Opus 4.6 กลับรั้งท้าย ซึ่งอาจเป็นข้อจำกัดของ Claude Code เอง หรืออาจเป็นสิ่งที่ตัวเบนช์มาร์กกำลังบอกอยู่ก็ได้
    • ผมยังคิดด้วยว่าอนาคตอาจไม่ได้เป็นปัญญารวมศูนย์แบบมนุษย์ แต่ใกล้กับ ปัญญาแบบกระจายตัวคล้ายปลาหมึก มากกว่า
      ถ้าเป็นอย่างนั้น จุดสำคัญก็จะกลายเป็นการทำให้ harness ฉลาดขึ้นมากกว่าตัวโมเดล
    • ถ้ามองแบบนั้น นี่ก็เหมือนเป็นสิ่งที่ terminal-bench ทำอยู่ไม่ใช่หรือ
    • ช่วงสองสามเดือนที่ผ่านมา ผมลองทดสอบด้วย local model ตัวเดียวกันเอง และในสภาพแวดล้อมของผม Claude Code ดีกว่า OpenCode อย่างชัดเจน และ OpenCode ก็ดีกว่า Codex

  • ถ้าจะเรียกว่าเป็นเบนช์มาร์ก อย่างน้อยก็ควรใส่โมเดลอีกสักตัวจากคนละตระกูลเพื่อดูว่า generalize ได้ไหม
    ถ้าดูเรื่องต้นทุน Minimax 2.7 ก็ดูน่าสนใจ และก่อนจะถึงจุดนั้นก็ยากจะบอกได้ว่าผลลัพธ์นี้ overfit กับ Gemini 3 Flash หรือเปล่า
    บนหน้า landing page ก็ควรเขียนให้ชัดด้วยว่าตัวเลขปัจจุบันทั้งหมดอิงกับ Gemini 3 Flash และถ้าคำว่า “ถูกกว่า” หมายถึง “เร็วกว่า” ภายใต้โมเดลเดียวกัน ก็ควรใส่เวลาเสร็จงานไว้ในเบนช์มาร์กด้วย
    อีกอย่าง ข้อมูลเรื่อง skills, AGENTS.md แบบซ้อน, และการรองรับ MCP ก็สำคัญสำหรับคนที่กำลังพิจารณาย้ายมาใช้

    • ผมลองรันด้วย Minimax 2.7 เองแล้ว มันดูไม่ชอบเครื่องมือแก้ไขเท่าไร และไม่นานก็ไหลไปใช้ sed แก้ไฟล์แทน
      ดูเป็นเรื่องธรรมชาติที่โมเดลจะไม่ได้ generalize กับเครื่องมืออะไรก็ได้อย่างสมบูรณ์ และโดยเฉพาะงานที่พบบ่อยอย่างการแก้ไขไฟล์ ก็มักได้รับอิทธิพลจากอคติเครื่องมือที่มีอยู่ในข้อมูลฝึก
      ในแง่นั้น ตระกูล Gemini โดยรวมอาจเก่งงานเอเจนต์น้อยกว่า จึงอาจมีอคติเฉพาะต่อเครื่องมือน้อยกว่าด้วย
    • ชี้ประเด็นได้ดีมาก
      ผมก็ลองทำเบนช์มาร์กกับ open-weights model อยู่ แต่ inference ช้าเลยโดน timeout ตลอด และ terminal bench ก็แก้ timeout ไม่ได้
      ผมเขียนบ่นเรื่องนี้ไว้ที่นี่ด้วย https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      เรื่องการระบุว่าใช้ Gemini ผมใส่ไว้ใน GitHub README แล้ว และเวลาเสร็จเฉลี่ยก็สั้นกว่าจริง แต่เพราะบางครั้งความเร็วในการออกผลช้าลงแบบสุ่ม เลยยังไม่ได้ใส่เป็นเบนช์มาร์กแบบเข้มงวด
      ข้อมูล skills / AGENTS.md / MCP ก็เพิ่มไว้แล้ว

  • ผมยังไม่ได้ลองใช้เอง แต่สงสัยว่าทำไมถึงไม่เลือกทำเป็นส่วนขยายบน pi แทนที่จะสร้าง harness ใหม่ทั้งก้อน
    เท่าที่ผมเห็น extension API ของ pi ค่อนข้างกว้าง และอะไรอย่าง Hash anchored edits ก็น่าจะทำได้สบาย
    ขอบคุณที่เปิดโครงการนี้ ผมตั้งใจว่าจะลองเข้าไปดูเองทีหลัง

    • หลายเดือนก่อน บ่ายวันหนึ่งผมหงุดหงิดกับความช้าของ Cline มาก เลยเริ่มแกะดูข้างในและแก้บางจุด
      จากนั้นก็เหมือนโดนดูดเข้าไปเรื่อย ๆ จนสุดท้ายเพิ่มโค้ดไปประมาณ 70,000 บรรทัด ลบไป 40,000 บรรทัด แล้วสองเดือนต่อมาก็กลายมาเป็นสภาพปัจจุบัน
    • ช่วงนี้ผมกำลังดูทั้ง local LLM และ harness ใหม่ ๆ อยู่ เลยสงสัยว่า Pi จริง ๆ แล้วดีกว่า OpenCode แค่ไหน
      และถ้าจะรีดประสิทธิภาพสูงสุด ควรใช้กับโมเดลและการคัสตอมแบบไหน

  • ระหว่างดูโค้ด ผมเจอว่า telemetry ถูกส่งไปที่ https://dirac.run/v1/event
    ดูไม่ได้เหมือนส่งข้อมูลอ่อนไหวอย่างโจ่งแจ้งหรือมีเจตนาร้าย แต่เพราะมันส่ง API error ด้วย ก็อาจมีกรณีที่ข้อมูลอ่อนไหวเล็ดรอดออกไปได้
    แถมยังเป็น endpoint ของนักพัฒนาคนเดียวและใช้แบบ opt-out ด้วย สำหรับผมเลยรู้สึกน่ากลัวพอสมควร และคงใช้ไม่ได้เพราะจุดนี้

    • telemetry ที่ผมตรวจเจอมีประมาณนี้
      ส่ง machine ID, การใช้โทเค็น, ข้อมูลโมเดล, อีเวนต์, 500 ตัวอักษรแรกของข้อผิดพลาด, และข้อมูลแพลตฟอร์ม ไปยัง dirac.run/v1/event
      มีการดึง feature flag จาก dirac.run/v1/event/decide ทุก 60 นาทีพร้อม machine ID และอันนี้เปิดอยู่ตลอดโดยไม่ขึ้นกับการ opt-out telemetry ถ้าไม่แก้โค้ดก็ปิดไม่ได้
      เครื่องมือ web search/web fetch จะส่งเนื้อหาคำขอและ system header ผ่าน api.dirac.run
      รายการโมเดลก็มีการยิงไปถาม OpenRouter, HuggingFace, Groq เป็นต้น แม้จะใช้ Anthropic provider ก็ตาม
    • ขอบคุณ
      นี่เป็น Cline fork เลยรับกลไก telemetry มาตรง ๆ และผมแค่ปล่อยไว้เพราะคิดว่าอาจช่วยตอนดีบักได้
      ไม่มีเจตนาร้ายใด ๆ ทั้งสิ้น และก็ไม่ได้สร้างหรือเก็บ PII ด้วย

  • ประเด็นสำคัญคือ harness สำคัญแค่ไหน และผมคิดว่านี่เป็นข้อสรุปที่อยู่ได้นาน
    โมเดลยืมมาใช้ได้ และพรอมป์ต์ก็ลอกกันได้พอสมควร แต่ตัวเลขบนเบนช์ส่วนใหญ่ถูกกำหนดโดย harness รอบนอก
    การเปลี่ยนจาก Gemini ไป Sonnet ภายใต้ harness เดียวกัน อาจมีผลน้อยกว่าการเปลี่ยน harness ภายใต้โมเดลเดียวกัน
    บทความ cheating-agents ที่คุณลิงก์มาก็พูดเรื่องเดียวกัน สุดท้ายสิ่งที่ถูกวัดจริง ๆ คือ harness ส่วนโมเดลใกล้เคียงกับวัตถุดิบตั้งต้นมากกว่า
    เพียงแต่ context management อาจไม่ใช่คุณสมบัติสากลเท่าไร แต่เป็นการอุดจุดอ่อนของโมเดลรุ่นปัจจุบันมากกว่า ดังนั้นอีกไม่กี่เจเนอเรชันมันก็อาจหายไป เหมือนที่เครื่องมือเคยมาแทน RAG แบบฝังคำถาม

    • เพราะแบบนั้น ARC-AGI-3 ถึงไม่อนุญาตให้ใช้ harness
      โมเดลต้องสร้าง harness เอง

  • ยินดีด้วย ดูเหมือนทำออกมาได้ดีมาก
    ช่วงหลายสัปดาห์ที่ผ่านมา ฝั่งผมเองการทำ harness ก็เป็นไซด์โปรเจกต์ที่สนุกที่สุด และแม้จะไม่ค่อยปิดงานได้ ผมก็อยากรู้ประสบการณ์อยู่สองเรื่องเป็นพิเศษ
    ด้าน context management การตัดกิ่งคำตอบจาก tool call เก่า การตัดเอาต์พุต และการ compaction อัตโนมัติ ได้ผลค่อนข้างดี และประโยชน์จากการลดคอนเท็กซ์ก็มากกว่าประโยชน์จากการจำทุกอย่าง
    แต่ผมจะเก็บสรุปสั้น ๆ ไว้เสมอ
    อีกด้านคือ subagents ตอนนี้ผมกำลังทดลองแนวทางที่แทบไม่เปิดเครื่องมือให้เอเจนต์หลักเลย แต่ให้แค่ run_agent ตัวเดียว แล้วให้เอเจนต์ย่อยไปใช้ search/execute/fetch กันเอง
    ถ้าเอเจนต์ย่อยส่งกลับมาแค่สรุปสั้น ๆ ผมคิดว่าคอนเท็กซ์ระดับบนจะสะอาดได้นาน แต่ตอนนี้ยังต้องทดลองการออกแบบพรอมป์ต์เพิ่มอีก

    • ขอบคุณ
      ถ้ารองรับ API caching การ pruning มักไม่ค่อยควรไปแตะ เพราะทุกครั้งที่ prune แคชจะพังและทำให้เสียประโยชน์จากแคชส่วนลด 90% ไป
      เรื่อง subagent นั้น Dirac ก็รับความสามารถจากการปรับปรุงฟีเจอร์ของ Cline มาเหมือนกัน แต่แต่ละโมเดลเรียนรู้การมอบหมายงานได้ไม่ดีเท่ากัน จึงแปรผันสูง
      โดยเฉพาะเมื่อเอเจนต์ย่อยติดลูปหรือไม่ยอมส่งคืนผล ต้องมีกลไกให้เอเจนต์หลักควบคุมได้แน่นอน

  • อันนี้น่าสนใจมาก และตรงกับประสบการณ์ที่ผมเจอจากการทำ harness ด้วย
    แม้ใช้โมเดลเดียวกัน ผมก็ยังคิดว่ายังมี ช่องให้ดีขึ้นอีกมาก
    ปีที่แล้ว Anthropic ผลักเรื่องเล่าว่ายิ่งมีโมเดลใหม่ harness ก็ยิ่งเข้าใกล้ while loop ง่าย ๆ ที่ครอบเครื่องมือไว้ แต่ตอนนี้กลับรู้สึกว่าเป็นไปในทิศทางตรงกันข้าม
    ฝั่ง harness ยังมีอะไรให้สำรวจอีกเยอะมาก และในงานของผม rolling context window ทรงพลังกว่า compaction มาก
    ถ้าเสริมด้วยสรุประดับบนแบบต่อเนื่องและไปป์ไลน์ auto-feedback ที่ละเอียดก็จะยิ่งดีขึ้น แม้แน่นอนว่าสิ่งนี้จะทำได้ง่ายกว่ามากเมื่อเป้าหมายของเอเจนต์ชัดและสม่ำเสมอ

  • ผมว่าน่าสนใจเป็นพิเศษตรงประเด็น harness
    เวลาที่เครดิตใกล้หมด ถ้าลดไปใช้โมเดลเล็กลงและทำพรอมป์ต์ให้เป็นโครงสร้างมากขึ้น บางครั้ง gpt-5.4-mini ก็ทำได้ดีกว่า gpt-5.4 ที่ปล่อยให้ลุยตามสัญชาตญาณเสียอีก
    เพราะอย่างนั้นผมเลยเริ่ม skill distillery สำหรับย้ายไอเดียเวิร์กโฟลว์เอเจนต์ที่ดีไปเป็น skills ขนาดเล็กที่ตรวจสอบได้และติดตั้งได้ https://github.com/ouatu-ro/skill-distillery
    ตัวแรกคือ dirac-workflow ที่อิงกับเวิร์กโฟลว์โค้ดแบบมีโครงสร้างของ Dirac แต่ไม่ใช่การโคลน Dirac เพราะไม่มี runtime, ดัชนี AST แบบถาวร, เอนจินแก้ไขแบบ hash-anchor หรือ benchmark harness
    แต่ผมพกไปเฉพาะ AST helper ขนาดเล็กกับวินัยด้านเวิร์กโฟลว์ในรูป skill ที่ย้ายไปใช้ที่ไหนก็ได้ และใส่รายงานสั้น ๆ ของการนำไปใช้กับรีโพ Dirac เองไว้ด้วย
    ในมุมของผู้สร้างต้นฉบับ ผมอยากได้ฟีดแบ็กว่าพรอมป์ต์กับเครื่องมือมีความเป็นตัวแทนที่ดีหรือไม่
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • ผมกำลังรีแฟกเตอร์โค้ดเบส Rust ด้วย Kimi 2.6 และ Dirac
    เป้าหมายคือทำ Clean Architecture ให้เข้มขึ้น และผมจัดขอบเขตงานไว้เป็น Beads epic กับอิชชูย่อยแล้ว
    แผนวางด้วย gpt5.5 และการตรวจว่าทำเสร็จครบก็ให้ gpt5.5 รับผิดชอบ
    สำหรับการรีแฟกเตอร์โค้ดเบสขนาดใหญ่ Dirac ทำงานได้มีประสิทธิผลกว่า OpenCode และ OpenCode เคยทำไฟล์ .rs พังจนผมต้องย้อนกลับ

    • อยากรู้ว่าคุณใช้ Dirac ร่วมกับ gpt-5.5 ด้วยไหม