- Đây là một coding agent mã nguồn mở tập trung vào tuyển chọn ngữ cảnh dày đặc và tối ưu hiệu năng so với hiệu quả công cụ để giảm vấn đề hiệu năng suy luận bị dao động trong ngữ cảnh dài
- Theo chuẩn
gemini-3-flash-preview, công cụ đạt Terminal-Bench-2 65.2% và hoàn thành 8/8 thành công trên 8 tác vụ refactor phức tạp trong các kho lưu trữ GitHub công khai
- Công cụ kết hợp Hash-Anchored Edits, Multi-File Batching và chỉnh sửa nhận biết cấu trúc để xử lý nhiều tệp với ít lượt qua lại, đồng thời sửa đổi theo cấu trúc cú pháp của các ngôn ngữ như TypeScript, Python và C++
- Hỗ trợ đọc·ghi tệp, lệnh terminal, trình duyệt headless, đồng thời cung cấp luồng CLI như quy trình phê duyệt, Plan Mode, Yolo Mode và tiếp tục lịch sử tác vụ
- Nhấn mạnh mức chi phí trung bình $0.18 và giảm 64.8% chi phí so với các công cụ cạnh tranh, nổi bật ở chỗ cải thiện đồng thời hiệu năng và chi phí trong các tác vụ thực chiến mà không dựa vào thông tin chuyên biệt cho benchmark
Hiệu năng cốt lõi
-
Kết quả benchmark
- Ghi nhận 8/8 đáp án đúng trên toàn bộ 8 tác vụ; trong các đối tượng so sánh, chỉ Opencode cũng đạt 8/8 tương tự
- Chi phí trung bình là $0.18, thấp hơn Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38, Roo $0.60
- README cho biết Dirac rẻ hơn 64.8% so với các công cụ cạnh tranh và giảm chi phí 2.8 lần
- Có thể xem mô tả tác vụ chi tiết và phương pháp luận tại evals/README.md
-
Đặc tính chi phí theo từng tác vụ
- Ở từng tác vụ refactor, bao gồm các kho
transformers, vscode, django, công cụ ghi nhận chi phí thấp nhất hoặc thuộc nhóm thấp nhất trong đa số trường hợp
- Ví dụ, tác vụ DynamicCache của
transformers ở mức $0.13, tác vụ datadict của django ở mức $0.08, và tác vụ sendRequest của vscode ở mức $0.25
- Một số công cụ cạnh tranh ghi nhận Incomplete hoặc Failure, nhưng Dirac được đánh dấu Success ở cả 8 tác vụ trong bảng
Cách tiếp cận và thiết kế
-
Chiến lược ngữ cảnh và chỉnh sửa
- Với Hash-Anchored Edits, công cụ nhắm vị trí sửa đổi dựa trên hash dòng ổn định, tránh vấn đề "lost in translation" của cách chỉnh sửa truyền thống dựa trên số dòng
- Với Multi-File Batching, công cụ đọc và chỉnh sửa nhiều tệp trong một lượt trao đổi với LLM để giảm độ trễ và chi phí API
- Tối ưu High-Bandwidth Context để chỉ giữ lại thông tin liên quan nhất, giảm lãng phí token và duy trì agent gọn nhẹ, nhanh
-
Chỉnh sửa nhận biết cấu trúc
- Tích hợp AST-Native Precision để làm việc trong trạng thái hiểu cấu trúc cú pháp của các ngôn ngữ như TypeScript, Python, C++
- Công cụ cho biết có thể thực hiện các thao tác cấu trúc như trích xuất hàm hoặc refactor lớp với độ chính xác 100%
-
Mô hình sử dụng công cụ
- Hỗ trợ đọc và ghi tệp, thực thi lệnh terminal, sử dụng trình duyệt headless
- Luồng tác vụ duy trì quy trình phê duyệt để người dùng giữ quyền kiểm soát
- Hỗ trợ mô hình chỉ giới hạn ở các trường hợp có native tool calling, nhằm bảo đảm độ tin cậy và hiệu năng
- Theo README, không hỗ trợ MCP
Cách sử dụng và tùy biến
-
Kiểm soát hành vi theo từng dự án
- Có thể tùy biến hành vi bằng cách áp dụng chỉ dẫn theo từng dự án qua tệp
AGENTS.md
- Tự động đọc các thư mục
.ai, .claude, .agents để tận dụng cả Claude skills
-
Luồng sử dụng CLI
- Có thể xác thực bằng
dirac auth, sau đó chạy tác vụ như dirac "Analyze the architecture of this project"
dirac -p "prompt" là cách dùng Plan Mode để xem chiến lược trướcdirac -y "prompt" là Yolo Mode tự động phê duyệt mọi hành động- Có thể truyền trực tiếp ngữ cảnh qua đầu vào pipe như
git diff | dirac "Review these changes"
- Có thể xem và tiếp tục tác vụ trước đó bằng
dirac history
-
Tích hợp VS Code
- Có thể cài extension từ VS Code Marketplace
- Luồng sử dụng là mở thanh bên VS Code, thiết lập nhà cung cấp AI ưu tiên như Anthropic, OpenAI, OpenRouter rồi bắt đầu tác vụ mới
Môi trường chạy và tích hợp nhà cung cấp
-
API key và biến môi trường
- Có thể nhận các biến môi trường như
ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN để bỏ qua bước xác thực
- Danh sách đầy đủ có trong
src/shared/storage/env-config.ts
-
Hỗ trợ AWS Bedrock
- Nếu thiết lập
AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN cùng với AWS_BEDROCK_MODEL hoặc AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN, công cụ sẽ tự động chuyển sang nhà cung cấp Bedrock
- Bao gồm ví dụ chạy cùng aws-vault
- Các model Claude mới như Sonnet 4.6 trở lên cần cross-region inference profile prefix như
us., eu., ap.; README hướng dẫn tham khảo ID model được hỗ trợ tại AWS docs
Bối cảnh dự án
-
Mã nguồn mở và hệ phả
- Đây là dự án mã nguồn mở theo Apache License 2.0
- Được ghi rõ là dự án fork từ Cline
-
Tài nguyên tham khảo
1 bình luận
Ý kiến trên Hacker News
Điều thú vị ở Dirac là những điểm như thế này
Nó chỉnh sửa tệp bằng phiên bản tối ưu của Hash-Anchored edits, và dùng AST của ngôn ngữ để quyết định nên đưa đoạn mã nào vào ngữ cảnh, nên không phải đọc toàn bộ các tệp mã lớn
Mọi tác vụ đều được gom theo lô để xử lý đồng thời số lượng lớn thao tác đọc/chỉnh sửa, và khi cần thì mô hình còn trực tiếp chạy script bash/python/perl để phân tích tức thời
Ngoài ra, nó quản lý ngữ cảnh khá tỉ mỉ, cập nhật theo kiểu đưa sẵn vào trước những thông tin mà mô hình gần như chắc chắn sẽ yêu cầu ở bước tiếp theo
Trước đây có bài viết nói
grepcũng hiệu quả tương tự, và trong ngữ cảnh đó thì tôi cũng phần nào thấy hợp lýKể cả khi hash chỉ chiếm một token thì mã vẫn được đọc nhiều hơn viết, nên chi phí tích lũy cũng lớn
Trước đây khi tôi thử với stable anchors dài hơn thì ngược lại còn thấy như bị thụt lùi, và hiệu quả của Dirac có vẻ chủ yếu đến từ việc chỉ hiển thị bộ khung của tệp
Batches all operationsnghĩa là gì nên đã đi xem mã nguồn, và có vẻ nó có nghĩa là thay vì kỳ vọng mô hình sẽ tự gọi công cụ song song tốt, thì chính tool API được thiết kế để nhận danh sách nhiều đối tượng cùng lúcTheo kinh nghiệm của tôi, mô hình không giỏi thực hiện hàng loạt lệnh gọi song song trong một lần, đặc biệt mô hình càng yếu thì xu hướng đó càng rõ
Có vẻ cũng có thể để mô hình cấp cao hơn chỉ lo tạo và gọi các mô hình chỉnh sửa rẻ hơn
Việc AI harness ảnh hưởng đến hiệu năng lớn đến mức nào thực sự rất thú vị
Tăng từ 48% trong kết quả chính thức của Google lên 65% là khác biệt cực lớn, nhưng dù tôi thấy rất nhiều so sánh mô hình thì hầu như không thấy kết quả so sánh chỉ riêng harness trên cùng một mô hình
Tôi tự hỏi có bảng xếp hạng nào so sánh hiệu năng harness trên cùng một mô hình hay không
Khá bất ngờ là với Opus 4.6 thì Claude Code lại xếp chót, và điều này có thể phản ánh giới hạn của Claude Code hoặc cũng có thể là điều mà chính benchmark đang nói lên
Khi đó điểm cốt lõi sẽ là làm cho chính harness thông minh hơn, chứ không phải chỉ tập trung vào mô hình
Nếu là benchmark thì tối thiểu cũng nên đưa thêm một mô hình thuộc hệ khác vào để biết có khái quát hóa được hay không
Xét về chi phí thì Minimax 2.7 có vẻ ổn, và trước khi có thêm kết quả thì khó biết đây có phải là kết quả bị overfit vào Gemini 3 Flash hay không
Trên landing page cũng nên ghi rõ rằng các con số hiện tại đều dựa trên Gemini 3 Flash, và nếu rẻ hơn đồng nghĩa với nhanh hơn trên cùng một mô hình thì thời gian hoàn thành cũng nên được đưa vào benchmark
Ngoài ra, việc có hỗ trợ skills, AGENTS.md lồng nhau và MCP hay không cũng quan trọng với những ai đang cân nhắc chuyển sang
sedCó vẻ tự nhiên là mô hình không thể khái quát hoàn hảo sang các công cụ tùy ý, nhất là với những tác vụ phổ biến như chỉnh sửa tệp thì nó sẽ bị ảnh hưởng bởi thiên lệch công cụ từ dữ liệu huấn luyện
Theo nghĩa đó, dòng Gemini nhìn chung yếu hơn ở tác vụ agent, nên biết đâu lại ít bị thiên lệch công cụ cụ thể hơn
Tôi cũng đã thử benchmark mô hình open-weights, nhưng suy luận chậm nên cứ bị timeout liên tục, còn terminal bench thì không cho sửa timeout
Tôi cũng đã viết phàn nàn liên quan ở đây https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
Tôi đã cập nhật ghi chú về Gemini trong README trên GitHub, còn thời gian hoàn thành trung bình thì ngắn hơn thật nhưng tốc độ sinh đầu ra đôi lúc chậm ngẫu nhiên nên tôi không đưa vào benchmark nghiêm ngặt
Tôi cũng đã bổ sung thông tin skills / AGENTS.md / MCP
Tôi դեռ chưa trực tiếp dùng thử, nhưng tôi tò mò vì sao lại không chọn hướng gắn thêm vào pi dưới dạng extension thay vì xây hẳn một harness mới từ đầu
Extension API của pi mà tôi từng thấy khá rộng, và những thứ như Hash anchored edits trông cũng hoàn toàn có thể triển khai được
Cảm ơn vì đã mở mã dự án, tôi định sau này sẽ tự xem kỹ
Sau đó càng lúc càng bị cuốn vào, đến khi cộng dồn thành khoảng 70 nghìn dòng thay đổi và 40 nghìn dòng xóa thì hai tháng trôi qua, và thành ra trạng thái hiện tại
Tôi cũng muốn biết nếu tận dụng tối đa thì tổ hợp mô hình và tùy biến nào là tốt nhất
Khi xem mã, tôi phát hiện telemetry được gửi tới https://dirac.run/v1/event
Có vẻ không cố tình gửi thông tin nhạy cảm một cách lộ liễu và cũng không mang dáng dấp ác ý, nhưng nó còn gửi cả lỗi API nên trong một số trường hợp vẫn có khả năng làm rò rỉ nội dung nhạy cảm
Hơn nữa, đây lại là endpoint do một nhà phát triển cá nhân vận hành và theo cơ chế opt-out, nên cá nhân tôi thấy khá đáng sợ và chỉ riêng điểm này cũng đủ khiến tôi không dùng
Nó gửi machine ID, lượng token sử dụng, thông tin mô hình, sự kiện, 500 ký tự đầu của lỗi, và thông tin nền tảng tới
dirac.run/v1/eventTại
dirac.run/v1/event/decide, nó truy vấn feature flag cùng machine ID mỗi 60 phút, và phần này luôn bật bất kể telemetry opt-out, không thể tắt nếu không sửa mãCông cụ tìm kiếm web/web fetch gửi nội dung yêu cầu và system header thông qua api.dirac.run
Danh sách mô hình cũng được truy vấn tới OpenRouter, HuggingFace, Groq... ngay cả khi dùng provider Anthropic
Đây là phần thừa hưởng nguyên cơ chế telemetry từ fork của Cline, tôi chỉ để lại vì nghĩ có thể hữu ích cho việc debug thôi
Hoàn toàn không có mục đích ác ý và tôi cũng không tạo hay lưu PII
Điểm cốt lõi là harness quan trọng đến mức nào, và tôi nghĩ đây là cách diễn giải sẽ còn tồn tại lâu
Mô hình thì có thể thuê dùng, prompt cũng có thể sao chép gần giống, nhưng phần lớn con số benchmark lại do harness xung quanh quyết định
Việc đổi Gemini sang Sonnet trong cùng một harness có thể còn tạo khác biệt nhỏ hơn việc đổi harness trong khi giữ nguyên mô hình
Bài viết về cheating-agents mà bạn liên kết rốt cuộc cũng nói cùng một ý: thứ thực sự được đo là harness, còn mô hình gần như chỉ là nguyên liệu nền
Tuy vậy, context management có vẻ mang tính vá điểm yếu của thế hệ mô hình hiện tại hơn là một thuộc tính phổ quát, nên vài thế hệ nữa có thể nó sẽ biến mất giống như cách công cụ đã thay RAG dựa trên embedding truy vấn
Nó buộc mô hình phải tự tạo harness
Chúc mừng, có vẻ bạn đã làm rất tốt
Trong vài tuần qua, với tôi việc làm harness cũng là side project thú vị nhất, và dù lúc nào cũng không hoàn thiện được, tôi đặc biệt tò mò về hai trải nghiệm
Ở phần quản lý ngữ cảnh, việc cắt tỉa các phản hồi tool call cũ, cắt ngắn đầu ra và tự động compaction hoạt động khá hiệu quả, và lợi ích của việc giảm ngữ cảnh lớn hơn lợi ích của việc nhớ mọi thứ
Tuy vậy tôi vẫn luôn giữ lại các bản tóm tắt ngắn
Còn về subagents, tôi đang thử cách gần như không lộ công cụ cho agent chính mà chỉ cấp một
run_agent, rồi để agent con dùng search/execute/fetchNếu agent con chỉ trả về tóm tắt ngắn gọn thì tôi nghĩ ngữ cảnh cấp trên sẽ sạch sẽ lâu hơn, dù phần thiết kế prompt thì tôi vẫn đang thử thêm
Nếu hỗ trợ API caching thì tốt nhất là đừng đụng vào pruning trừ khi thật cần, vì mỗi lần prune là lại làm vỡ cache và mất lợi thế giảm giá 90% từ caching
subagent thì Dirac cũng thừa hưởng từ phần cải tiến tính năng của Cline, nhưng mức độ học được cách ủy quyền khác nhau rất nhiều theo từng mô hình
Đặc biệt, nhất định phải có cơ chế để agent chính kiểm soát trong trường hợp agent con rơi vào vòng lặp hoặc không quay về
Điều này thực sự rất thú vị, và cũng khớp chặt với trải nghiệm tôi có khi tự làm harness
Tôi nghĩ ngay cả với cùng một mô hình thì vẫn còn dư địa tăng đáng kể
Năm ngoái Anthropic từng thúc đẩy câu chuyện rằng mỗi khi có mô hình mới thì harness ngày càng gần với một vòng lặp while đơn giản bọc quanh công cụ, nhưng giờ tôi lại có cảm giác đang diễn ra điều ngược lại
Phía harness còn quá nhiều thứ để khám phá, và trong công việc của tôi thì rolling context window mạnh hơn compaction rất nhiều
Nếu gắn thêm cả tóm tắt cấp cao liên tục và pipeline phản hồi tự động chi tiết thì còn tốt hơn nữa, dĩ nhiên điều này sẽ dễ triển khai hơn khi mục tiêu của agent rõ ràng và nhất quán
Tôi đặc biệt thấy điểm về harness rất thú vị
Khi tín dụng gần cạn, nếu hạ xuống mô hình nhỏ hơn và cấu trúc prompt chặt chẽ hơn thì đôi khi gpt-5.4-mini còn làm tốt hơn gpt-5.4 vận hành theo cảm tính
Vì vậy tôi đã bắt đầu
skill distillery, chuyển các ý tưởng workflow agent tốt thành những skills nhỏ, có thể kiểm tra và cài đặt được https://github.com/ouatu-ro/skill-distilleryCái đầu tiên là
dirac-workflow, dựa trên workflow mã có cấu trúc của Dirac, nhưng không phải bản sao Dirac vì không có runtime, chỉ mục AST thường trú, engine chỉnh sửa hash-anchor hay benchmark harnessThay vào đó, tôi chỉ chuyển các helper AST nhỏ và kỷ luật workflow thành một skill có thể mang đi nơi khác, và cũng đính kèm một báo cáo ngắn về việc áp dụng nó ngay trên chính kho Dirac
Với tư cách tác giả gốc, tôi muốn xin phản hồi xem prompt và công cụ có mang tính đại diện hay không
https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py
Tôi đang refactor một codebase Rust bằng Kimi 2.6 và Dirac
Hướng đi là củng cố hơn nữa Clean Architecture, và phạm vi công việc được sắp xếp thành Beads epic cùng các issue con
Tôi đã lập kế hoạch bằng gpt5.5 và việc xác minh hoàn thành cũng do gpt5.5 đảm nhiệm
Trong các đợt refactor codebase lớn, Dirac cho năng suất cao hơn OpenCode, còn OpenCode thì từng làm hỏng các tệp
.rskhiến tôi phải hoàn tác