- KanBots là ứng dụng desktop chạy song song Claude Code và Codex trên từng thẻ Kanban, đồng thời hiển thị theo thời gian thực tiến độ, quyết định và chi phí ngay trên bảng
- Mỗi lần chạy được cô lập trong một git worktree riêng trên nhánh
kanbots/issue-N, và bạn có thể thả thư mục vào để tạo bảng rồi gán agent cho từng thẻ
- Autopilot luân chuyển qua các persona như sản phẩm, kỹ sư, reviewer, tester với độ song song tối đa 4 để chia nhỏ công việc và cập nhật backlog
- Agent sẽ dừng ở những điểm cần phán đoán để đưa ra các lựa chọn, và người dùng có thể tiếp tục bằng cách chọn số, chỉnh sửa rồi gửi lại, hoặc dùng
/spec, /review, /split
- Ứng dụng desktop áp dụng cách tiếp cận miễn phí theo giấy phép MIT và ưu tiên cục bộ, còn Cloud có giá $19/tháng cho mỗi ghế để cung cấp đồng bộ nhóm, thông báo và dashboard
Khái niệm cơ bản của KanBots
- KanBots là ứng dụng desktop chạy song song các agent Claude Code và Codex theo từng thẻ trên bảng Kanban
- Mỗi agent chạy trong một git worktree riêng trên nhánh
kanbots/issue-N, và bảng sẽ cập nhật theo thời gian thực tiến độ, yêu cầu quyết định và chi phí
- Khi thả một thư mục vào, một bảng sẽ được tạo ra, và có thể gán agent Claude Code hoặc Codex cho nhiều thẻ
- Ở chế độ chạy tự động, các persona sẽ chia nhỏ công việc, thực thi song song và kiểm tra kết quả
- Ứng dụng desktop miễn phí, dùng giấy phép MIT, dựa trên đóng góp và hoạt động theo hướng ưu tiên cục bộ
Cấu trúc sản phẩm và giá bán
-
Desktop OSS
- Desktop ưu tiên cục bộ, không cần tài khoản, không có telemetry, miễn phí vĩnh viễn và dùng giấy phép MIT
- Hỗ trợ macOS, Linux, Windows và bao gồm toàn bộ tính năng
- Các tính năng chính gồm chạy agent song song, chạy tự động, lời nhắc quyết định, persona tích hợp sẵn và tùy biến, phân tích chi phí theo thời gian thực, thư viện recipe,
kanbots-mcp-server, nhập Sentry, chế độ GitHub Issues, xem trước nhánh, tạo bản nháp PR, hỗ trợ Claude Code và Codex, cùng hook pre-push
-
Cloud cho nhóm
- Cloud là sản phẩm đa người dùng được lưu trữ, còn agent vẫn chạy cục bộ trên phần cứng của người dùng
- Giá là $19/tháng cho mỗi ghế, hoặc $190 khi thanh toán hằng năm
- Ngoài các tính năng OSS, còn có hiển thị sự hiện diện theo thời gian thực trên bảng, thông báo phân công thành viên, đồng bộ giữa các thiết bị, thông báo Slack, tổng hợp chi phí toàn tổ chức, cùng chỉnh sửa thẻ theo thời gian thực, dashboard hoạt động agent theo tổ chức, và Managed GitHub App
- Các tính năng Enterprise gồm nhật ký kiểm toán, SSO / SCIM, REST API và PAT, webhook outbound
- Các tính năng chỉ có trên Cloud được giới hạn ở những gì thực sự có ý nghĩa khi có người khác hoặc thiết bị khác; mọi tính năng dùng một mình trên một máy đều nằm trong OSS
Công cụ được hỗ trợ và tích hợp
- Hỗ trợ CLI của Claude Code và Codex
- Hỗ trợ GitHub Issues và công việc PR
- Hỗ trợ nhập lỗi từ Sentry
- Cursor và Claude Desktop có thể tích hợp như MCP client
- Lưu trữ cục bộ dùng SQLite
- Desktop shell được cung cấp dựa trên Electron
Tính năng cốt lõi
-
Chạy thẻ song song
- Có thể chạy agent đồng thời trên nhiều thẻ, và mỗi lần chạy sẽ diễn ra trong git worktree riêng cùng nhánh
kanbots/issue-N
- Bảng cập nhật theo thời gian thực tiến trình chạy, yêu cầu quyết định từ agent và chi phí tích lũy
-
Chạy tự động và persona
- Có thể liên kết các persona như sản phẩm, kỹ sư, reviewer, tester, và đặt độ song song tối đa đến 4
- Bộ điều phối sẽ luân phiên qua các persona theo kiểu round-robin, chia issue cấp cao thành các tác vụ con, và cập nhật backlog bằng những việc agent phát hiện ra
- Persona có thể tạo ra persona khác
-
Thực thi xoay quanh quyết định
- Agent sẽ dừng lại khi gặp quyết định cần thiết và hiển thị các lựa chọn
- Người dùng có thể tiếp tục bằng cách chọn số, chỉnh sửa rồi gửi lại, hoặc dùng các lệnh slash như
/spec, /review, /split
- Thay vì âm thầm thay đổi cây công việc, hệ thống để lại luồng quyết định có thể xem xét được
-
Tích hợp Claude Code và Codex
- Có thể dùng Claude Code hoặc Codex trên cùng một bảng, cùng worktree và cùng UI quyết định
- KanBots xử lý hai định dạng stream phía sau một AgentCliAdapter duy nhất
- Có thể dùng
claude /login hiện có hoặc OPENAI_API_KEY
-
Lưu trữ ưu tiên cục bộ
- Mọi dữ liệu nằm trong
.kanbots/ bên cạnh kho mã
- Cơ sở dữ liệu SQLite, cấu hình và worktree đều được lưu cục bộ
- Không có tài khoản đám mây, không telemetry, không HTTP server, và mã không rời khỏi máy
-
Phân tích chi phí và giới hạn ngân sách
- Cung cấp thống kê chi phí theo từng lần chạy, từng thẻ và từng dự án
- Đồng hồ chi phí tích lũy trong lúc agent làm việc
- Có thể đặt giới hạn theo lần chạy hoặc theo phiên, và việc chạy sẽ dừng khi chạm ngân sách
-
Workflow GitHub
- Có thể xử lý issue GitHub thực bằng PAT cá nhân
- Có thể nâng worktree thành commit, hoặc mở PR nháp chỉ bằng một cú nhấp
- Hook pre-push ngăn agent tự đăng nội dung lên
-
Máy chủ MCP
kanbots-mcp-server hiển thị bảng qua Model Context Protocol- Cursor, Claude Desktop hoặc các công cụ hiểu MCP có thể thao tác với bảng
- Bảng trở thành một công cụ mà các agent khác có thể sử dụng
Workflow bên trong ứng dụng
-
Autopilot
- Chọn một hoặc nhiều persona, đặt độ song song rồi bắt đầu chạy tự động
- Tối đa 4 slot song song sẽ luân phiên qua danh sách persona theo round-robin
- Mỗi slot lấy persona tiếp theo theo cách nguyên tử, và agent sẽ chia issue cấp cao đang xử lý thành các tác vụ con
- Dừng khi hoàn tất hoặc khi chạm ngân sách phiên
- Màn hình ví dụ cho thấy Claude Opus 4.7, effort
medium, độ song song 2, với persona Product Manager và Senior Engineer được chọn
-
Decisions
- Luồng chạy stream toàn bộ
tool_use và tool_result theo thời gian thực
- Agent sẽ dừng tại điểm cần phán đoán và đưa ra các lựa chọn được đánh số
- Ô nhập phản hồi chấp nhận các lệnh như
/spec, /review, /split
- Trong ví dụ triển khai token đặt lại mật khẩu, các lựa chọn được hiển thị gồm JWT dùng một lần, opaque token lưu trong DB, magic link, hoặc giải thích trade-off trước
- Màn hình chạy hiển thị model, thời gian trôi qua, số token, chi phí, trạng thái, độ ưu tiên, thư mục, worktree, nhánh, nhánh cơ sở và tác giả
-
Personas
- Persona là các đoạn system prompt có tên
- Persona mặc định được tích hợp trong ứng dụng, và người dùng có thể viết, lưu và tái sử dụng persona mới
- Persona tùy chỉnh được lưu cục bộ trên chính máy đó
- Ví dụ mặc định gồm Product Manager, Senior Engineer, UX Designer, Growth Lead, Reliability Engineer
-
Providers
- Claude Code và Codex có thể được dùng phía sau một
AgentCliAdapter
- Có thể tái sử dụng
claude /login hoặc codex login hiện có mà không cần tài khoản bổ sung hay quản lý thêm khóa
- Có thể chuyển nhà cung cấp cho từng lần chạy
- Codex CLI yêu cầu
codex phải có trong PATH, còn tạo nháp issue và phân tích Sentry vẫn chạy trên Claude
- Đăng nhập Codex có thể mở
auth.openai.com trên trình duyệt hoặc dùng biến môi trường OPENAI_API_KEY
-
Tasks
- Tác vụ mới cung cấp các mẫu sửa lỗi, tính năng, refactor, review và spike
- Có thể chọn cách bắt đầu là spec-first, chạy ngay sau khi tạo, hoặc đưa vào hàng đợi để chạy sau
- Tiêu đề được dùng làm tên nhánh và tiêu đề PR
spec-first sẽ chạy /spec để tinh chỉnh tiêu chí chấp nhận rồi đặt ở trạng thái chờ phê duyệt- Tác vụ mới tạo fresh worktree và tạo nhánh dưới
.kanbots/worktrees/issue-N dựa trên main
-
Chat
- Có sẵn một agent đa dụng để đặt câu hỏi về workspace
- Agent hiểu kho mã, bài test và trạng thái git để trả lời câu hỏi
- Ví dụ được nêu là tìm API route không có rate limiting, thêm
rateLimit({ windowMs: 60_000, max: 10 }) vào /api/login và /api/signup, rồi viết test để pass
Cách Autopilot hoạt động
- Autopilot là chế độ nhận issue và ngân sách rồi tự cập nhật backlog
- Bộ điều phối luân phiên qua danh sách persona theo round-robin và chạy song song tối đa 4 slot
- Hệ thống chia issue cấp cao thành các tác vụ con và lặp lại cho đến khi công việc hội tụ hoặc chạm giới hạn chi phí
- Ví dụ hiển thị độ song song 4, model
opus 4.7, đã dùng $4.27 trên ngân sách phiên $25.00, và trạng thái ở chu kỳ thứ 14
-
Chọn danh sách persona
- Có thể dùng persona mặc định hoặc tự định nghĩa system prompt để lưu và tái sử dụng
- Persona tùy chỉnh không rời khỏi máy
-
Đặt độ song song
- Độ song song có thể đặt từ 1 đến 4
- Mỗi slot lấy persona tiếp theo một cách nguyên tử qua bộ đếm round-robin
- Bốn agent có thể chạy đồng thời với bốn góc nhìn và bốn worktree khác nhau
-
Chia nhỏ công việc
- Khi agent phát hiện công việc, nó sẽ tạo thẻ mới trên bảng
- Các chu kỳ sau sẽ lấy các thẻ mới này, và backlog sẽ phình ra rồi co lại dưới sự điều phối của orchestrator
-
Dừng khi hết ngân sách hoặc hoàn tất
- Ngân sách chi phí theo phiên giới hạn tổng chi tiêu
- Nút dừng sẽ kết thúc lần chạy cha và toàn bộ lần chạy con
- Những lần chạy đang diễn ra sẽ hoàn tất sạch sẽ vòng lặp hiện tại
Chế độ QA
- Chế độ QA chạy typecheck, tests, lint, build, e2e bên trong worktree
- Khi cần, có thể khởi động và theo dõi development server
- Với mỗi kiểm tra thất bại, hệ thống sẽ gán một lần chạy sửa lỗi trong issue con được suy ra
- Quy trình lặp lại cho đến khi các kiểm tra đều pass
Cách cung cấp và phần kết
- Ứng dụng desktop OSS được cung cấp miễn phí, dùng giấy phép MIT và không cần tài khoản
- Nhấn mạnh quy trình đưa mọi lần chạy agent lên Kanban để trực quan hóa, cho phép ra quyết định và cô lập chúng
- Khi nhóm cần chia sẻ bảng, có thể chuyển sang Cloud
- Các định dạng tải xuống gồm macOS
.dmg, Windows .exe, Linux .AppImage / .tar.xz
1 bình luận
Ý kiến trên Hacker News
Tôi vẫn luôn băn khoăn mọi người tiếp nhận kết quả mà agent làm suốt đêm như thế nào
Ngay cả với kho dự án phụ cá nhân, tôi cũng thấy kết quả của 30 phút lập kế hoạch và 30 phút triển khai đã quá lớn để review. Sau khoảng 5 phút, ngay cả khi code vẫn đang tuôn ra, đôi lúc tôi đã bảo AI làm lại
Cá nhân tôi thấy cấu trúc file chặt chẽ cũng hữu ích. Việc review một file 3.000 dòng vừa được sinh ra là điều tệ nhất, và tôi sẽ không muốn nhận kết quả như vậy từ cả người lẫn máy. Nếu nó được chia thành nhiều file đặt đúng chỗ thì gánh nặng nhận thức sẽ giảm đi
Đôi khi tôi cũng vừa nói chuyện với agent vừa review cùng nó. Ví dụ như hỏi file nào là quan trọng nhất để review trước
Tôi thích stage các thay đổi vào đống “LGTM”. Nếu sau đó cần sửa tiếp, tôi sẽ bảo agent: “Hãy review các thay đổi chưa được stage. Ở đây tôi muốn làm theo cách khác”
Nếu có gì sai, tức là phát sinh bug, thì cứ sửa lúc đó. Đây là một thời kỳ rất buồn của software engineering. Nếu ngành của chúng ta từng có cái gọi là engineering thì giờ phần lớn đã biến mất, và chúng ta chỉ đang đoán mò bằng cách viết file skills kiểu “đừng tạo bug” hay “bạn là chủ sở hữu chứ không phải người thuê”
Mức độ nỗ lực thấp, và tính xác định cũng cực thấp. Những ứng dụng lớn như GitHub liên tục đi xuống vì rác AI, và ở các hệ thống kém nổi tiếng hơn thì điều đó còn thấy thường xuyên hơn. Ở công ty tôi hay các SaaS khác mà chúng tôi dùng cũng vậy
Product manager vốn dĩ chưa bao giờ quan tâm đến code, engineering manager thì không còn quan tâm đến code như khi họ còn là engineer, director thì chẳng quan tâm gì đến code, còn CTO giờ thậm chí còn không biết code trông như thế nào
Chúng tôi ở cuối chuỗi, và vì hiểu rất sâu rằng hệ thống tốt được xây trên code tốt nên từng có niềm tự hào về việc viết code dễ dùng và dễ bảo trì. Nhưng giờ chúng tôi đang tự đẩy mình vào rủi ro, và chính chúng tôi, những engineer, lại là phía không còn quan tâm đến code nữa, còn AI thì đang khuếch đại vấn đề đó
Phần lớn thời gian được dùng để thử nhiều cách tiếp cận rồi tóm tắt lại, sau đó đưa cho tôi một diff tương đối nhỏ để tôi có thể review và chỉnh sửa
Cá nhân tôi lúc nào cũng muốn chỉnh gì đó trong kết quả do agent tạo ra. Tôi đang tự hỏi liệu mình có nên buông bỏ sự kiểm soát đó hay không
Điều này làm tôi nhớ đến Vibe Kanban(https://vibekanban.com/), thứ tôi dùng để quản lý coding agent trong phần lớn các dự án
Tiếc là các nhà phát triển Vibe Kanban đã ngừng đầu tư vào dự án vì cho rằng không thấy con đường kiếm tiền. Nó là mã nguồn mở nên bạn vẫn có thể chạy cục bộ hoặc fork, nhưng việc cải tiến đã dừng lại và vẫn còn vài bug khó chịu cần sửa. Cá nhân tôi không có thời gian để tự bảo trì
Tôi thật sự sẵn sàng trả tiền cho Vibe Kanban nên thấy khá tiếc. Chỉ là tôi không cần các tính năng của gói trả phí. Nghĩ lại thì có lẽ tôi nên trả luôn
Tôi cũng sẽ thử Kanbots. Có vẻ hoàn toàn ổn nếu tích cực sao chép các tính năng của Vibe Kanban. Đặc biệt, hỗ trợ từ xa và nút “Open in VS Code” là tối quan trọng với tôi. Trong trường hợp của tôi, nút này mở client VSCode cục bộ trỏ đến máy chủ VSCode từ xa
Trong 1–2 tuần qua tôi đã làm việc để đưa công cụ mới lên mức tương đương tính năng với VK, đồng thời thêm các cải tiến mới. Tôi cũng đã đăng vài ảnh chụp màn hình lên Discord của Vibe Kanban. Khi sẵn sàng phát hành, hy vọng nó cũng sẽ phù hợp với trường hợp sử dụng của bạn
Công cụ của tôi nhắm tới việc tốt hơn VK cả ở bảng Kanban lẫn không gian làm việc của agent, đồng thời thêm các hệ thống phụ như quản lý cửa sổ desktop, plugin, tích hợp VSCode trong trình duyệt và UI render phía server kiểu giống htmx
Cách tiếp cận truy cập từ xa cũng khác. Thay vì chạy một web server trên laptop để truy cập coding agent từ xa, tôi host toàn bộ như OpenClaw và truy cập UI desktop từ xa ngay trong trình duyệt
Điểm “local-first, không có server. Mọi thứ nằm trong
.kanbots/cạnh kho mã: cơ sở dữ liệu SQLite, cấu hình, worktree. Không có tài khoản cloud, không có telemetry, không có HTTP server. Đây là bản desktop mã nguồn mở” là điều kiện nền tảng để cân nhắc dùng các công cụ kiểu nàyNếu AI mang tính agent, tôi kỳ vọng bất kỳ product manager nào cũng có thể dành khoảng một giờ trò chuyện để tích hợp Jira với một vòng lặp agent nào đó
Jira, Trello, Linear, Basecamp đều có API, và có lẽ cũng có CLI để agent sử dụng. Không nên cần đến developer hay SaaS chỉ để làm cho nó hiểu rằng khi bắt đầu công việc thì ticket được checkout, chứa hướng dẫn, và khi xong thì được chuyển sang DONE
Nói thật là nó trông khá ngầu. Nhưng hiện giờ cũng đã có khá nhiều công cụ trông ngầu rồi
Ban đầu từ “Kanban” được Toyota dùng để mô tả hệ thống thẻ của họ, và hệ thống đó giúp đạt được một số mục tiêu quan trọng như không làm quá nhiều việc cùng lúc và trực quan hóa công việc
Nhìn chung, Kanban được dùng để quản lý luồng công việc sao cho khuyết tật không lọt qua
Nhưng công cụ này lại gần với kiểu “đẩy vào càng nhiều việc song song mà bạn có thể nghĩ ra càng tốt”. Nó không quản lý luồng đầu ra chất lượng, cũng không giới hạn công việc. Chỉ đơn giản là ném mọi thứ cho agent và đốt token như điên
Việc gọi cái này là “Kanban” thật sự khiến tôi khó chịu. Cảm giác như báng bổ vậy
Khi tôi thử chạy agent mà không giám sát, cảm giác thất vọng còn nhiều hơn thành công
Tôi tin công nghệ cuối cùng sẽ tới được mức đó, nhưng hiện tại mỗi agent đều cần một IDE riêng và việc gộp các công việc lại cũng rất phiền
Chia sẻ một dự án mã nguồn mở mới. Đây là bảng Kanban có agent chạy song song
Tôi đang cố cải thiện nó với nhiều tính năng hơn, và rất mong nhận được đóng góp cho kho mã, dù là code hay ý tưởng
Có vẻ sẽ rất thú vị khi theo dõi tiến triển của dự án
Về cơ bản đây chẳng phải là điều Windsurf đang làm sao? Rốt cuộc mọi UI kiểu này chỉ là lớp vỏ đặt lên trên agent mà thôi
[0] https://windsurf.com/blog/windsurf-2-0
Với tôi thì cần một quy trình có con người can thiệp nhiều hơn. Kiểu giao hết cho agent mà không nhìn rõ change set hay có cơ hội đổi hướng thì không hợp với tôi
https://www.agentkanban.io kết nối bảng công việc với GitHub Copilot Chat trong VS Code thông qua extension, để bạn có cả quản lý công việc lẫn việc ghi lại ngữ cảnh từ chat thành công việc. Nhờ vậy có thể tận dụng lợi thế của môi trường thực thi cấp cao hơn là VS Code, đồng thời vẫn có tính năng quản lý công việc/dự án
Linear cũng đang trực tiếp làm theo hướng này
Điều tôi không hiểu ở các công cụ này là họ xử lý việc khởi động hạ tầng cho các worktree khác nhau như thế nào
Ví dụ nếu có một web app thì mỗi worktree phải tự khởi chạy hạ tầng của riêng nó, và mỗi cái phải truy cập được qua một URL cục bộ riêng. Như vậy mới có thể xem các thay đổi của từng worktree trên máy cục bộ, hoặc để agent tự động hóa việc kiểm tra trực quan bằng thứ như agent-browser
Hiện tại tôi dùng Docker cho hạ tầng, và mỗi service chạy trong container riêng của nó. Tôi có script
./app worktree create worktreename, script này tạo worktree “worktreename” rồi khởi động toàn bộ hạ tầng Docker với tiền tố như “WORKTREENAME”. Vì thế mọi URL đều có thể truy cập qua worktreename.myapp.test, còn worktree chính thì dùng myapp.testHiện giờ nó hoạt động tốt, nhưng sẽ hay nếu một trong các ứng dụng kiểu này tương thích với khái niệm đó để tôi có thể chuyển sang dùng
CLI đó điền URL và cơ sở dữ liệu tương ứng cho từng worktree vào file
.env, rồi dùng gói mã nguồn mở portless của Vercel để khởi chạy dev server trên cổng riêng. Nhờ vậy mỗi worktree đều có URL riêngTrong đó có
EMDASH_PORT, là cổng riêng nằm trong dải 10 cổng. Rất hữu ích khi chạy nhiều service trong một monorepo duy nhấtShell script sẽ tìm một cổng riêng chưa dùng trong tất cả worktree hiện có, rồi gán nó vào
.envcục bộ khi tạo worktree. Khi worktree được merge và xóa thì cổng cũng được giải phóngNhững secret không theo từng worktree thì tôi không để trong
.envcục bộ mà inject bằng shellNói thật thì việc viết các script cục bộ kiểu này để tự động hóa công việc phát triển là rất đơn giản, lại kết hợp tốt với mọi công cụ CLI khác. Vì vậy tôi vẫn chưa thử ứng dụng GUI nào. Tôi không chắc chúng có thể cạnh tranh với thiết lập cục bộ tùy biến chạy đúng như cách tôi muốn hay không
N=mod(...)rồiport=default_port+Nlà xongCứ bảo Claude cấu hình cho. Chỉ một prompt là làm được thôi
“‘kanbots’ bị hỏng và không thể mở. Bạn nên chuyển nó vào Thùng rác”
Đây đúng là lỗi quá hợp để gặp đầu tiên trong một phần mềm vibe coding
Đây chẳng phải chỉ là vibe-kanban sao?
https://github.com/BloopAI/vibe-kanban