用 Multica 任务面板同时管理三个编程 Agent

运行一个编码 Agent 没问题。打开终端，描述任务，看着它工作。

运行三个就开始出问题了。每一个都在自己的终端里运行，谁也不知道其他几个做了什么，唯一的记录就是那些你一不小心就会关掉的回滚内容。想回答"现在有哪些任务在进行中"，除了去检查四个窗口之外别无他法。

Multica 就是解决这个问题的任务板。Agent 和人一样被分配 issue，它们自己把卡片在看板上移动，工作挂在 issue 上而不是关掉就没了的终端里。

这就是在一个真实项目上搭建它的样子：这个站点、它真实存在的待办列表、三个 Agent，以及最初几个小时实际消耗的情况。

安装：20 分钟，无报错

我在 macOS 上用的桌面版而非自托管，那是最快的上手方式。

唯一需要做决定的步骤是认证。在开始之前从终端登录 GitHub 并使用 HTTPS，因为那是 Agent 打开 pull request 时使用的凭证。搞错这个，前面的步骤都会正常，直到 Agent 试图推送的那一刻才出问题，那是最糟糕的发现时机。

这就是全部安装了。下载、登录、连接仓库，二十分钟左右搞定，没有出任何问题。

有一个地方容易让人踩坑：Multica 不附带 Agent。它驱动的是你已有的 CLI。一个守护进程扫描机器上它认识的工具，为每一个注册一个运行时。它开箱支持 23 种，包括 Claude Code、Codex、Cursor、Copilot、OpenCode、OpenClaw、Gemini CLI 和 Kimi。我的在 MacBook 上跑的是 Claude Code。如果你还没有安装任何 Agent CLI，先装一个。

通过提问来创建 Agent

我本来以为会有个表单。确实有，但不是给你日常工作用的。

Multica 自带一个叫 Mika 的 Agent，描述是"工作区首席助理"，其他所有东西都是通过和它对话来创建的。你用自然语言描述想要完成的工作，Mika 就会创建 issue、Agent 或定时任务。对话框会给你一个示例提示："让 Bojan 修复 Web 项目中收件箱加载慢的问题"。

我的另外两个 Agent 都是从那个对话里出来的：

精准度很关键。一个被告知"帮忙维护网站"的 Agent 产出的工作很模糊。被告知"审查 Agent 写的 PR，而且这段代码不是你写的"的 Agent 产出的东西才可用。

访问权限列也很重要。Vera 是纯所有者权限，因为任何人都能重新指派的审查者就不是审查者。

指令是 Agent 指令标签页里的纯文本。编辑它们，下一次运行时行为就会改变；不需要重新部署。你在调优一份工作描述，而不是配置文件。

写 Agent 真正能完成的 issue

看板是普通的看板：Backlog、Todo、In Progress、In Review、Done。Agent 自己移动它们的卡片。当 Vera 完成一次审查后，她自己把 issue 移到了 In Review 并把报告作为评论留下。

让这件事行得通的是写 issue 时用了 Outcome 行而不是 task 行。"定义 Agent 交接前必须通过的验证门"是一个 task。"一个可命名的、可运行的验证门"是一个 outcome。Agent 处理第二种好得多，因为有具体的东西可以自我检验。

我看板上的几个真实例子：

将代码库连接到项目

定义 Agent 交接前必须通过的验证门

对 Agent PR 进行自动化代码审查

Backlog 清理：将现有的 TODO 和已知问题转化为 issue

待处理工具提交的重复性 CLI 分类

关键的部分：让它们停下来

这是我如果扔掉其他所有功能也会保留的部分。

Scout 通过 Autopilot 按计划运行：每天 17:00 的 cron 触发器，它在专用项目中创建一个 issue 并分配给 Scout。指令明确说明了它必须在什么地方停下，而那正是提示的大部分内容：

运行一个 Phase 1 侦察周期。仅限 Phase 1，报告后停下。

在开始任何操作之前先检出仓库并重读 CLAUDE.md，特别是 CRITICAL SAFETY RULES。不要根据对这些文件的记忆来工作。

然后停下。不要写 SQL、不要打开 PR、不要碰数据库。将 issue 状态设为 in_review 并等待。

"停下"之前的一切都是只读的：筛选候选者、将已列出的和任何已暂存的内容去重、用无头浏览器加载每个候选者自己的网站和定价页来验证它们，然后把发现作为评论发布。不会往任何地方写东西。

我读那条评论并回复指定哪些要添加。那个回复就是解锁 Phase 2 的关键，Phase 2 里它写迁移脚本、运行验证脚本、打开 pull request。将迁移应用到生产数据库始终是我的工作，明确说："将它应用到生产数据库是他的操作，永远不是你的。"

三处停下点，每一处都等待人类。沉默让它无限期地停在那里，因为没有超时机制会悄悄替你批准。

这个设计来自于一个具体的担忧。这个仓库里有一个脚本会往生产数据库写入东西，除非你传 --dry-run，我不希望一个无人值守的 Agent 编辑一个有 400+ 工具的目录。

还有两条小指令也值得占有一席之地。"永远不要把聚合器或综述定价当作证据"，因为那正是错误价格被复制到整个互联网的方式。还有"不要为了凑数而填充批次；这比一份简短的报告更糟糕"，因为否则不管存不存在五个结果你都会得到五个。

如果你从这篇文章里只记住一件事：决定一个 Agent 可以在不询问的情况下做什么，其他一切都停下来等待。

实际消耗了多少

Multica 有一个分析标签页。这是最初几个小时的使用数据，不是一个月后的，虽然仪表盘窗口显示 30 天因为那是现有的全部历史：

仔细看那个数字，因为它不是账单。我的运行使用的是 Claude Code 的每月 $100 套餐，那是我已经付过费的，所以这里没有任何东西作为额外费用出现在账单上。$23.43 是 Multica 估算的按 API 费率计算的使用量，这使得它成为一个有用的衡量标准——衡量你完成了多少工作——而不是从你账户里流出的钱。

按 Agent 分开看，Mika 做了 19 个任务，估算成本 $21.31，运行时长刚过一小时。Vera 做了一次代码审查，$2.12，9.5 分钟。

值得做的比较是相对于你的额度，而不是相对于账单。一下午 20 个任务消耗了大约一个月份度的 API 等价用量。如果你已经为一个编码 Agent 订阅付费，这就是参照系。板上的 Agent 比你对着一个 Agent 打字消耗你现有额度更快，而分析标签页就是在你的限额到期之前告诉你这个事实的地方。

输出质量怎么样

这是 Vera 审查另一个 Agent 写的 pull request：

唯一的阻断性发现是我毫无保留会为之辩护的那一个，而我之所以有它只是因为我运行了那个检查口而不是读了一遍。盯着 "eslintWarnings": 27 看多少遍也告诉不了你我实际数是 25；你必须执行它。

我最不确定的两个也是仅凭 diff 我就会产生的两个。#1（未强制执行的禁止）是论点，不是观察……两者都是那种审查者为显得全面而产生的发现类型，这恰恰是我把它们标为可疑的原因。

一个 Agent 把它验证过的和它推断的分离开来，并告诉我哪一半值得怀疑，这比一份更长的发现列表有用得多。

我不会假装每次运行都长这样。同一天下午的一次 backlog 清理取消了一打 issue，那是正确的但确实算不上什么工艺。关键是好的输出可读，坏的输出可见，因为它们都落在 issue 上而不是消失在终端里。

板上的一切都有命令行等价物，如果你想围绕它写脚本就很重要：

multica agent get <agent-id> --output json
multica autopilot get <autopilot-id> --output json
multica autopilot runs <autopilot-id> --output json

autopilot runs 是我常用的那个：它是定时 Agent 的运行历史，所以它回答"昨晚它触发了吗，做了什么"，不需要打开应用。

许可证和定价，在你依赖它之前

自托管是免费的，对 Agent 数量没有限制。并发受限于你的硬件，你可以让多台机器加入作为运行时。

有两件事是营销没有前置展示的。

许可证不是纯开源的。它是 Apache 2.0 加额外条件：你不得在没有商业许可证的情况下向第三方提供 Multica 作为托管服务，即使你分文不取。未经书面豁免不得移除品牌。一个组织内部的的使用是明确允许的，这覆盖了大多数读到这里的人。

没有公开发布的云端定价。托管版本提供免费试用，而 multica.ai/pricing 返回 404。

值得用吗，附带一个警告：价值不在 Agent；在看板上，在检查口上。

Agent 已经存在了。改变的是我能看见它们在做什么，工作在会话结束后仍然存在，没有任何不可逆的事情会在我没有说出口的情况下发生。最后这一点让它得以在真实站点上使用而不是当个玩具仓库。

坦诚状态：定时侦察运行已配置好但尚未触发，所以我能告诉你设计是对的但还不知道它能否经受住一个月每日运行的考验。等它跑起来我会再报告。

如果你偶尔跑一个 Agent，这是一个你还没遇到的问题的协调层。如果你开着三个终端却不知道什么做完了，它就是缺失的那块拼图。

最初发布于 intelligenttools.co，我在那里维护了一个 AI 工具目录，价格在供应商自己的页面上核对过。