多智能体协作新玩法：用现有工具组建AI评审团

给单个 AI 智能体派活，然后祈祷它一次做对——这件事的体验越来越像开盲盒。一位开发者在 Reddit 上分享的"panel"方案提供了另一种思路：把编码任务交给一个由你已经在用的多个智能体组成的团队，一个负责写，其他从不同角度审，最后让主导智能体逐行核实后交付。最近这轮更新让整套流程几乎不需要手动配置。

从指定面板到自然语言派活

早期的版本要求用户精确告诉技能"哪个终端面板对应哪个智能体"，这种 pane ID 管理方式在智能体数量增加后变得繁琐。新版本取消了这个限制：你只需用自然语言描述任务，例如 /panel implement the serializer per the spec 或 /panel codex implements, opencode reviews: fix the flaky test，主导智能体会自行发现可用的面板、读取每个智能体的 harness 与模型信息，然后分配角色。

关键设计在于，主导智能体在开工前会明确告诉你它选择的映射关系。一旦分配有误，你能在第一时间看到并纠正，而不是等到任务跑偏才发现。这种"先声明再执行"的模式，把原本隐藏在幕后的调度逻辑暴露给了用户。

harness（智能体运行骨架） 在这里指驱动一个编码智能体运行的工具链，包括 CLI 程序、模型后端、系统提示词与工具集配置。不同 harness（如 Claude Code、Codex、OpenCode）在上下文长度、工具调用格式、权限模型上差异明显，同一个任务交给不同 harness 可能得到不同结果。主导智能体读取各面板的 harness 与模型信息，是为了按能力特点分配实现与评审角色——例如让长上下文模型做跨文件规格审查，让擅长执行的模型去写代码。

没人需要轮询：事件驱动的唤醒机制

多智能体协作最常见的工程麻烦是等待。派发任务后，主导智能体要么陷入 sleep 循环反复检查"完成了吗"，要么需要后台常驻进程盯着状态。这个项目捆绑了一个名为 lanes 的小型 Claude Code 插件，专门监视 Herdr 面板：当被派发的智能体完成任务、卡在权限提示上或者停滞时，它会自动唤醒主导智能体。

主导智能体的工作方式因此变得干净：派发任务，结束自己的回合，等到有东西要审时被唤醒。没有后台 waiter，没有轮询开销。这种事件驱动结构也更接近人类团队的协作节奏——你不需要每隔五分钟问同事"改完了没"。

轮询（polling）与事件驱动 是两种状态同步范式。轮询由主导智能体按固定间隔主动查询“任务完成了吗”，实现简单但空转消耗 token 与时间，间隔过长又会延迟响应。事件驱动则把状态变化（完成、权限阻塞、停滞）作为信号推送给监听方，由插件监视面板输出并触发唤醒。在智能体编排中，事件驱动能显著降低空转成本，但依赖对终端状态的可靠解析——如果某个 harness 的输出格式不标准，监视器可能漏判或误判状态。

评审循环才是核心

这套方案真正的价值不在"多个智能体"这个噱头，而在评审机制的设计。规则很明确：任意时刻只有一个智能体拥有写权限，其他所有智能体都对同一份冻结的改动做只读评审，且各自从不同角度切入——规格符合度、正确性与边界条件、以及那些实际上永远不会失败的测试。

最后，主导智能体亲自读取真实 diff，打开每一处被引用的代码行，单独运行完整的验证门禁，然后汇总成一份统一的修复简报发回去。循环上限设为三轮；如果三轮后仍有问题，主导智能体自己动手完成工作，而它的改动同样要接受评审。

这个设计正面回应了单智能体编码的一个顽疾：模型倾向于确认自己的输出正确，缺乏真正的对抗性检查。把写和审拆到不同智能体身上，并在评审时冻结改动，能在一定程度上制造出独立的审视视角。

冻结改动（frozen diff） 指在评审期间锁定被审代码的快照，评审者看到的始终是同一版本，写权限方在此期间不得继续修改。若不冻结，评审者可能在阅读过程中遭遇代码变动，导致意见指向已消失的行，多方评审结论也无法对齐。冻结把“写”与“审”在时间上分离，使每轮评审有明确对象，修复意见能对应到具体快照，这也是该流程能产生独立审视视角的工程前提。

不增加订阅，复用现有技术栈

按照作者的说法，整套流程不需要额外订阅，也不用折腾 API key。它建立在 Herdr 加上你技术栈里已有的编码 CLI 之上——Claude Code、Codex、ZCode、OpenCode，跑什么都行。这降低了尝试门槛：如果你已经在并排运行多个智能体，这套编排层几乎是零成本的增量。

实践中的观察

作者在帖子里邀请有并行运行多个智能体经验的用户提问，说明这套工作流目前仍处于实战打磨阶段。自然语言分配角色的灵活性带来一个隐含问题：主导智能体对面板和模型的"自行发现"是否可靠，取决于它对环境的理解能力。映射声明机制缓解了这一点，但复杂的多智能体环境仍可能需要人工干预。

三轮上限也是一个值得注意的取舍。它避免了无限修复循环，但也意味着复杂任务可能落到主导智能体自己收尾的路径上——此时评审对象变成了主导智能体的改动，评审者与被评审者的角色发生倒转，流程的一致性需要用户自己把握。

对于已经在用多个编码智能体的开发者，这套方案提供了一个结构化的协作模板：明确分工、冻结改动、独立评审、统一收口。它未必适合所有任务，但对于需要高可靠性的编码工作，把"写完就算"变成"写完还要过审"，方向上是对的。

项目地址：https://github.com/alexstrilets/panel