我想让研发 agent 长成一支能自己扩编的舰队

这是「探索 agent 的未来模式」系列的一篇。另一篇讲护栏：《让 agent 有野心地干活之前，先给它一份真人签过名的 truth source》。

这周，我围绕我们在做的研发助手，前前后后补了九次想法。我把这些碎片拼起来后，发现自己想要的不是「再做一个更好用的 agent」，而是一支能自己扩编的舰队。

我现在想解决的，是研发助手该怎样接住一项持续推进的工作，而不只是回答眼前的问题。当我把任务分派、进度跟踪和结果验收放在一起想时，我就觉得，单个对话里的 agent 不够用了。我不想让用户一直充当调度员，替每个 agent 记住它在做什么、下一步该找谁。

每个 bot 自带看板和工作区

我想在我们的研发助手里新增自定义 bot。每个 bot 都可以有自定义的看板和工作区，而且能在对话区里直接端上来。与此同时，用户还要能把对话里的东西直接拖到看板上。

我这么想，是因为对话和看板/工作区应该打通，用户不用在两边来回切。

自定义看板具体怎么做，我想参考 DeepSeek harness 那个视频。我想借的首先是它对交互和执行的分离：后台任务继续推进时，用户仍然可以在前台提问或调整方向。它还把 CI 结果、审查评论等变化当作事件来处理，这让我想到，看板也应该反映任务的真实进展，而不是等人回来手动更新。但是，看板上的状态、产物和待确认事项应该怎样组织，仍然是我需要设计的部分，不能直接当成视频已经给出的界面方案。

bot 能生 bot，还能共享 skills

自定义的 bot 自己也可以创建 bot。各个 bot 共享 skills、互相连通；新建出来的 bot 归属到某个特定 bot 下面，形成层级。

这样一来，一个 bot 就能长出一支队伍，各个 bot 也能复用 skills，不用各写一份。

这里我还要看 DeepSeek 的 super agent 概念。我把相关规格整理在了《DeepSeek Super-agent 概念规格笔记》里；其中的 Super-agent 是架构探索，并不是已经交付的产品能力清单。它追求连续、高效、主动和持久，主要依靠 Router／Worker 双层架构、事件驱动、面向人的交互、计算与状态及环境的分离，以及 Watchdog 这五个模块。我的分层 bot 想法与它的共同点，是让协调者处理分派，让执行者带着各自的上下文干活。但是，我还想让用户能定义 bot 的身份、看板、工作区和归属层级；这些产品组织方式并不等于 Router／Worker 的运行时分工，我不能只凭 bot 有了上下级就认为系统已经具备 Super-agent 的能力。

默认给一个「舰队」模板

这些 bot 用自动化和 CLI agents 来干活。我们预先做好一个类似舰队的默认看板模板，用户当然也可以自己改。因此，用户开箱就有一整队 agent 可用，不用从零搭。

我也想学习已经有人在做的相近产品：

• agent_hub：它是一个给 Codex 和 Claude Code 用的本地 web hub。它把可读的对话和实时 CLI 放在一起，按项目浏览 session，桌面和手机上都能接着干。
• orca：用户可以用自己的订阅跑一整队 coding agent（Claude Code、Codex 等），它支持桌面、手机和远程 runtime。

我想从 agent_hub 和 orca 学习怎样把现有 CLI agent 组织起来，而不是要求用户先换掉手里的工具。但是，我更想围绕持续的工作来组织产品：用户交给一个 bot 的任务、产物和后续变化，应该留在它的看板与工作区里。我的判断是，自定义 bot、层级归属和共享 skills 如果能把这些工作接起来，用户就不必每次都重新搭队伍；这也是我想验证的差异，而不是我已经做出的能力。

不只跑在云上

我们的研发助手除了云上的 agent，还可以连接到其他 runner，比如服务器和个人机。也就是说，活可以跑在最合适的机器上，本地环境和自有服务器也能纳进来。

内核一套，外面换皮

我还想让我们的研发助手用 herdr core 这种自定义皮的方式来做可定制的桌面工作台：不同的外观共用一套内核。

我想到的场景包括研发团队的项目协作、企业内部的事务处理，以及个人管理自己的长期任务。同一套内核可以在研发场景突出代码和审查，在企业事务场景突出待办与审批，在个人场景突出计划和产物。但是，我不想让换皮只剩下颜色和标志的变化；不同场景需要展示哪些信息、允许谁做什么，也应该能随之调整。

舰队也需要护栏

一支能自己扩编的舰队，干活的胆子会越来越大。但是，bot 越多、越自主，就越需要一份它们不能随手改掉的基准。我想先给它们一份真人确认过的基准，相关思路见《让 agent 有野心地干活之前，先给它一份真人签过名的 truth source》。

我会先把这支舰队收在一个具体项目里，验证它能不能把任务从分派一直推进到交付，再决定哪些地方值得扩编。我想看到的不只是 bot 数量增加，还包括用户能否看清谁在负责、工作停在哪里，以及哪些决定仍然需要自己确认。如果这些问题还要靠用户反复追问，我就应该先把协作方式补好，而不是继续增加 bot。