dirac-run/dirac

 (github.com/dirac-run)
1 คะแนน โดย GN⁺ 2 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเอเจนต์เขียนโค้ดโอเพนซอร์สที่มุ่งลดปัญหาประสิทธิภาพการให้เหตุผลที่แกว่งในบริบทยาว โดยโฟกัสที่ การคัดสรรบริบทอย่างหนาแน่น และ การเพิ่มประสิทธิภาพสมรรถนะเทียบกับประสิทธิผลของเครื่องมือ
  • บนเกณฑ์ gemini-3-flash-preview ทำสถิติ Terminal-Bench-2 65.2% และทำสำเร็จ 8/8 งาน ในงานรีแฟกเตอร์ที่ซับซ้อน 8 งานบนที่เก็บ GitHub สาธารณะ
  • ผสาน 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

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

    • ในแต่ละงานรีแฟกเตอร์ รวมถึงที่เก็บ 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 ครั้งเดียว ลดทั้งเวลาแฝงและค่าใช้จ่าย 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 ได้โดยตรง เช่น 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 โดยอัตโนมัติ
    • มีตัวอย่างการรันร่วมกับ aws-vault
    • Claude รุ่นใหม่อย่าง Sonnet 4.6 ขึ้นไป ต้องใช้ cross-region inference profile prefix เช่น us., eu., ap. และแนะนำให้อ้างอิง model ID ที่รองรับจาก AWS docs

ภูมิหลังของโปรเจกต์

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

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

 
GN⁺ 2 일 전
ความเห็นจาก 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 ด้วยไหม