多 Agent 协作平台：真正重要的功能

这个品类里的每个工具现在都说自己支持多 Agent。这个说法本身几乎没有意义，因为同时跑几个 Agent 很容易。失败发生在后面：两个 Agent 改同一个文件，一次运行一小时前就停了却没有告诉任何人，一堆做完的工作没有人审查，也没有办法回答某个 Agent 上周二到底做了什么。

多 Agent 协作平台是让这些问题可见、并且有人负责的那一层。本文列出决定一个平台是否做到这一点的功能、缺了每项会怎样，以及怎样用一个下午验证。把它当评估清单，而不是产品导览。

先看结论

重要的是八项功能：Agent 是真正的处理人、隔离执行、运行状态和任务状态分开、收件箱、明确的审查关口、供应商中立、限定范围的凭证，以及证据记录。其他都是包装。验证方法是让三个 Agent 同时在一个仓库上工作，看这八项里有哪些要自己临时补上。

1. Agent 是处理人，不是聊天面板

第一个问题就把这个品类分开了。Agent 能不能占据一条工作的处理人字段，还是 AI 只是帮助人的一块面板？

处理人认领任务，阅读上下文，在真实环境里执行，再交回结果。辅助功能则是帮人起草描述、总结讨论和整理待办。两者都有用。只有前者改变谁在做事。

没有这一点，任务系统里记的是意图，终端里发生的才是事实，两者一天之内就会分开。

2. 每次运行都隔离执行

两个 Agent 待在同一个工作目录里，不是协调问题，而是数据丢失问题。没有锁，也没有队列：最后保存的进程获胜。损坏可能只是悄悄覆盖，也可能是能编译但语义已经坏了。

平台应该默认给每次运行自己的工作区。HiFox 给每条任务一个隔离目录；有代码仓库的工作可以为每次运行使用单独的 worktree。共享本地目录也合理，前提是这次运行需要已有环境、缓存和已经安装的工具。这时应该只有一次运行占用它，其余运行停在一个看得见的等待状态。

没有隔离，你就会自己写 worktree 脚本，然后发现还得给它们做调度。

3. 运行状态和任务状态分开

这是两件不同的事。把它们混成一个字段，会误导所有人。任务的流程状态是团队约定：待办、进行中、待审查、完成。一次运行的状态是执行事实：排队中、已派发、等待本地目录、运行中、已完成、失败、已取消。

运行可以已经完成，任务仍然留在审查中。任务可以显示进行中，而它的运行二十分钟前已经失败。如果平台用一个状态表示两件事，看板就是在说谎。

4. 收件箱把需要人处理的事拉出来，而不是一条要滚动的信息流

三个 Agent 同时运行时，任何时刻唯一重要的问题是哪一个需要人。平台的价值就是不用你自己去找，就能回答这个问题。

有用的形式很窄。HiFox 的收件箱承载三类信号：等待你回复、等待你审查、执行失败。群通知可以按组静音，收件箱仍然记录全部事项。否则就会变成一个第二周就被所有人静音的聊天频道。

没有收件箱，你就成了轮询循环。这才是终端开得太多的真实成本。

5. 明确的审查关口

Agent 应该可以做完。它们不应该自己决定「做完」就是「已接受」。平台需要一个状态，表示 Agent 已经做完、人还没有看。最终动作应该留给人。

实践中就是一条规则：Agent 可以把任务推到待审查，由人把它改为完成。人对 Agent 工作的所有权在信任增加以后仍然成立。人的审查会成为并行执行的瓶颈，所以这个关口要单独设计。

6. 供应商中立

团队通常已经在用不止一个 Runtime，最好的那个每隔几个月就会变。把你绑在单一供应商 Agent 上的平台，是在赌这家供应商一直领先。

要看它能不能登记多个 Runtime，把任务路由到合适的那个，并添加供应商没有内置的 Runtime。HiFox 会检测已连接电脑上的受支持工具，把每个可用工具显示为 Runtime。列表里没有的，也可以作为自定义 ACP Runtime 添加，带上自己的启动命令和连接测试。路由就成了每条任务的决定，而不是一次平台迁移。

相关问题是谁为 Token 付费。转售模型用量的平台，是在你已经购买的东西上抽成。HiFox 不出售 Token：运行费用记在 Runtime 所连接的 Claude Code、Codex 或 API 方案上。

7. 限定范围的凭证和权限

对主机拥有不受限访问的 Agent，最终会用到全部权限。权限有三层，任何一层的缺口都会让另外两层失效：Runtime 可以调用哪些工具、主机和它的凭证暴露了什么、任务范围允许什么。

具体来说，凭证应按每次运行发放，而不是继承启动守护进程的那个 shell。安装令牌应该短时且一次性使用。Agent 不应该以你的身份登录。如果一个平台回答不了「这个 Agent 能碰到什么」，答案就是一切。

8. 以后还能读到的证据

最后一项没有人在评估时检查，到第二个月每个人都需要。变更发出去以后，你应该能打开这条任务，看到当时要求什么、哪个 Runtime 执行、它做了什么、验证了什么、哪里不确定，以及谁接受了它。

这意味着 Agent 的输出作为评论留在任务上，执行日志包含工具调用和触发来源，并且能连到产生的 pull request。这样才是在任务层面审查 Agent 的工作，而不是从 diff 里重新推导。

一个下午就能做的测试

六项都能回答，它是平台。只能回答三项，它是一块带 Agent 功能的仪表盘。

可以忽略什么

营销文案里的 Agent 数量。跑 100 个 Agent 是调度事实，不是能力。限制从来不是你能启动多少个。平台发布的模型基准也可以忽略，除非方法也公开。聊天界面不应该是主界面：和小组对话有助于思考，任务才是带有仓库、电脑和审查人的承诺。把每条消息都变成任务，看板就会变成噪音。

常见问题

什么是多 Agent 协作平台？

它是你已经在运行的 Coding Agent 上面的一层，负责保存工作：任务、指派、隔离执行、运行可见性、阻塞、结果和人工审查，并且覆盖多个 Agent 和多个人。

它和编排器有什么不同？

编排器决定下一步跑什么、按什么顺序跑，通常处在一条自动化流水线里。协作平台假定人在回路中，并描述人与 Agent 之间的交接。编排是更大系统里的一项功能。

只有一个 Agent 时需要它吗？

大概不需要。一个 Agent、一个仓库、一个人，用终端和任务记录就够了。当两个 Agent 可能碰到同一段代码，或者第二个人需要看到这项工作，情况就变了。

它会替代 Claude Code、Codex 或 Gemini CLI 吗？

不会。那些工具负责执行。平台管理执行周围的事：指派、隔离、审查和记录。供应商中立才是目的，不是替代。

评估它最省事的办法是什么？

用一个真实仓库和一条低风险任务做上面的下午测试，同时保留现在的任务系统。最小起步是一台电脑、一个 Agent，以及一条不修改文件的任务。