标签： AI技术

如果你用过AI编程助手，大概率会遇到一个效率瓶颈——同一时间只能让一个代理干活。改这个文件的时候，另一个任务只能排队等着。Kanbots把一个看似简单的想法做成了产品：让多张看板卡片同时跑不同的AI代理，每个代理住在自己独立的Git工作树里，互不干扰。

看板+AI代理，拼在一起是什么体验

Kanbots本质上是一个桌面端看板工具（类似Trello，但是本地优先、开源、MIT许可证），核心差异点是每张卡片都可以单独调度一个AI代理。你可以在「收件箱」里扔进去十个需求卡片，然后看着代理们并行地把它们各自推进到「进行中」「评审」「待处理」。

代理不是在同一个代码目录里打架，而是每个都运行在独立的Git工作树（worktree）里，对应独立的kanbots/issue-N分支。你主分支的代码，代理碰不到。

每个代理活在属于自己的Git分支里，改坏了也不影响主分支——这个设计让「让AI大胆改代码」变成了一件放心的事。

自动驾驶模式：设好预算，让代理自己干活

Kanbots有一个叫自动驾驶（Autopilot）的模式，可能是最受欢迎的功能。你可以配置多个角色人设——比如「产品经理解需求」「高级开发写代码」「测试工程师补单测」，然后设置并行数量（最多4个）和成本上限。

启动之后，代理会自动把父任务拆成子任务、更新待办列表、跑测试和lint检查。遇到需要人工决策的时候，它会暂停，弹出带编号的选项等你选。整个过程的成本实时统计，到预算了自动停。

• 支持Claude Code和Codex两种AI编程CLI，开箱即用
• 内置预推送钩子，代理无法自行发布代码，必须人工确认
• 成本可控，支持按单次运行、单张卡片、整个项目三个维度统计
• 所有决策记录可追溯，代理不是黑盒

实际用起来是什么感觉

一个典型场景：Sentry捕获到前端报错，你点一下导入看板，调度代理去修。代理在独立工作树里改代码、跑测试、lint检查，全部通过后暂停，等你确认。确认完一键提交草稿PR。全程你不需要手动改一行代码。

另一个场景是「先写规格再开发」：给卡片打上需求描述，代理先跑/spec命令细化验收标准，你审批完再开始写代码。相当于给AI代理加了一个「需求评审」环节。

本地优先，数据不离开你的设备

Kanbots强调本地优先——所有数据存在代码仓库下的.kanbots目录里，默认不收集遥测，不需要注册账号，代码不会离开本地设备。这一点对企业开发者尤其重要。

当然也有云版本（每座19美元/月），多了团队实时协作、Slack通知、SSO这些企业功能。但核心的单人开发功能，开源桌面版全部都有。

有意思的是，Kanbots本身是跑在Kanbots看板上开发的（官方称之为「dogfooding」）。一个做AI代理看板的工具，用自己的看板来管理开发任务——这件事本身就挺有说服力的。

如果你最近试着搭过一个编程AI代理，大概率会遇到一个尴尬的问题——工具很多，但拼不到一起。要么对着文档抄提示词，要么把一堆零散脚本硬凑成一个「代理」，改一丁点需求就要推翻重来。obra在GitHub开源的Superpowers项目，想用「方法论+可组合技能」的思路，把这件事从手工活变成工程活。

碎片化开发的痛点，它想一次解决

现在的AI代理开发，多少有点像2010年之前的移动互联网——热闹，但混乱。大家都在做代理，但每个人对「什么是好的代理」理解不一样，实现方式更是千差万别。有人把所有逻辑写进一个超长提示词，有人用LangChain拼流水线，有人直接调API硬编。

Superpowers的核心判断是：问题不在模型能力不够，而在开发方式本身缺乏标准。它不给你一个「万能代理」，而是提供一套可复用、可组合、可验证的开发方法论。

「代理开发应该从『依赖模型黑盒』转向『可定义、可验证的流程设计』」——这是Superpowers最核心的设计理念。

可组合技能架构，像搭乐高一样搭代理

框架把代理能力拆成「原子技能模块」——每个模块负责一件具体的事，比如「分析代码库结构」「生成单元测试」「解释报错信息」。这些模块可以单独测试、单独维护，也能按需组合。

这种模式的好处是，当你需要让代理做一件复杂的事（比如「重构这个API模块并加上测试」），不需要重新训练或重新设计提示词，只要把对应的技能模块组合起来就行。代理的行为也因此变得更可预测——你知道它在每一步调用的什么技能，而不是对着一段黑盒输出猜它「想干什么」。

• 技能模块独立可测，改一个不影响其他
• 支持跨项目复用，慢慢攒出自己的「技能库」
• 代理行为可追踪，哪一步调了什么技能一目了然

初始指令层：让代理行为可控

Superpowers另一个有意思的设计，是用「初始指令集」作为代理的逻辑入口，而不是直接把任务丢给底层大模型。这套指令定义了代理怎么解析目标、什么时候调哪个技能、遇到歧义怎么处理。

这样做的一个直接好处是，代理的输出稳定性大幅提升。你不用担心换一个模型，代理的行为就完全跑偏；只要初始指令层保持一致，代理在不同模型上的表现是可以预期的。

从实验脚本到生产应用，就差这一套方法论

过去一年多，我们看到无数「代理Demo」——能跑通一个特定任务，但换一个场景就跪。Superpowers想解决的，就是把这个「Demo到生产」的鸿沟填平。它提供的不只是代码框架，而是从设计、开发、组合、验证到部署的完整流程规范。

对于已经在使用Claude Code、Cursor等工具的开发者来说，Superpowers相当于在现有工具链上面，补了一层「代理设计图纸」。你可以继续用熟悉的CLI，但代理的能力组织和复用方式会系统性地升级。