摆脱“人肉路由器”：多Claude Code代理编排实战

从“人肉路由器”到CEO：一个多代理编排的痛点

一位homelab开发者用Claude Code管理着11个项目，每个项目配备一个负责规划的编排器会话和一个只写代码的开发会话，外加一个基础设施代理。这些代理通过Vikunja任务评论交接工作，听起来很自动化？但现实是，他本人成了代理之间的“电线”：上周他在约20个终端之间手动复制粘贴了257条中转提示，平均要等11分钟才发现某个代理已经完成。他想要的很简单——像CEO一样只给想法、收结果、给反馈，中间环节全自动。这个困境戳中了很多尝试多代理工作流的开发者：工具已经能写代码，但协调成本仍然落在人身上。

据Reddit原帖分享，这种“babysitting”（保姆式看护）模式让效率大打折扣。问题的核心不在于单个代理的能力，而在于多个代理之间缺乏自动化的任务流转和状态感知机制。

为什么“一个项目一个代理+子代理”不是万能解

原帖作者提出的疑问是：是否应该让每个项目只用一个代理，再通过子代理（subagents）处理细分任务？从社区讨论来看，这确实是一种常见思路，但并非没有代价。单代理+子代理的好处是上下文集中、协调简单，但缺点是单个代理容易成为瓶颈，尤其是在项目数量多、任务并行度高时，子代理之间的依赖关系仍然需要主代理来调度。

另一种思路是保留多代理架构，但引入一个轻量的“调度层”——比如用消息队列或任务看板自动触发代理。Vikunja在这里已经充当了任务存储，但缺少自动通知机制。有开发者建议用webhook或轮询脚本监听任务状态变化，一旦某个代理完成任务，就自动生成下一条提示并发送给下一个代理，从而消除人工中转。

自动化中转的三种可行方案

结合原帖中的技术栈（Claude Code + Vikunja + 多终端），可以梳理出几条落地路径：

方案一：脚本监听+自动注入

写一个守护脚本，定期查询Vikunja中特定任务的状态。当检测到“待处理”评论时，提取内容并通过终端复用工具（如tmux send-keys）自动输入到对应的Claude Code会话中。这能直接替代人工复制粘贴，把257次操作变成0次。关键点在于会话标识的映射：每个终端对应哪个项目、哪个代理，需要一张配置表来维护。

tmux send-keys 是终端复用器 tmux 的一个命令，用于向指定会话或窗口发送按键序列，效果等同于有人在键盘上敲入这些字符。在自动化场景中，它常被用来向正在运行的交互式程序（如 Claude Code 的 REPL）注入输入，而无需人工切换终端。使用前需要先通过 tmux list-sessions 或 tmux list-panes 获取目标窗格的标识（如 session:window.pane），并确保目标程序处于可接受输入的状态。由于 send-keys 直接模拟键盘输入，它不依赖程序本身提供 API，因此对任何 CLI 工具都通用，但也意味着无法感知程序是否已就绪，通常需要配合 tmux capture-pane 读取输出或加入延时来保证可靠性。

Vikunja 是一个开源的自托管任务管理工具，支持看板、列表、甘特图等视图，并提供 REST API 和 webhook 能力。在多代理工作流中，它被用作共享任务存储：每个任务对应一个工作项，代理通过添加评论来交接状态和内容。要基于 Vikunja 实现自动中转，需要了解其 API 的基本用法——例如通过 GET /api/v1/tasks/{id}/comments 拉取评论、通过 POST 添加新评论，以及利用任务标签或自定义字段标记“待处理”“已完成”等状态。Vikunja 原生支持 webhook（需在项目中配置），可在任务创建、更新或评论时向外部 URL 推送事件，这比轮询更实时，但需要额外的接收服务。

方案二：代理间直接通信

如果Claude Code支持工具调用或函数执行，可以让代理在完成任务后主动调用一个“通知接口”，把结果写入Vikunja并触发下一个代理的启动。这需要给每个代理配置一个简单的CLI工具或HTTP端点，使其具备“交棒”能力。相比轮询，这种方式更实时，但对代理的自主性要求更高。

方案三：升级为编排框架

社区中有人提到LangChain、CrewAI等编排框架，但它们与Claude Code的终端交互模式并不天然契合。更轻量的做法是采用“监督者模式”：用一个主代理负责读取全局任务列表，根据依赖关系生成子任务并分发给工作代理。原帖中的“编排器会话”其实已经具备监督者雏形，缺的是自动唤醒机制。

监督者模式（Supervisor Pattern） 是多代理编排中的一种常见拓扑：一个主代理（supervisor）持有全局任务视图，负责将高层目标拆解为子任务、按依赖关系排序，并分派给工作代理；工作代理只执行具体子任务并将结果回传，不直接相互通信。这种模式的优势是协调逻辑集中、易于监控和调试，缺点是主代理可能成为瓶颈，且对主代理的规划能力要求较高。在 Claude Code 的语境下，“编排器会话”天然适合扮演监督者，但需要补充自动唤醒机制——例如当工作代理完成任务并写入 Vikunja 后，由外部脚本或 webhook 触发编排器会话继续规划下一步，而不是等人来推动。

关键设计原则：减少人工介入的边界

无论选哪种方案，有几个原则值得注意。第一，状态可见性：每个代理的当前状态（空闲、工作中、等待反馈）应该集中展示，而不是散落在20个终端里。第二，失败隔离：一个代理卡住不应该阻塞整个流水线，需要超时和重试机制。第三，反馈闭环：作者希望“给反馈”仍然由人来做，这意味着自动化只应覆盖代理之间的中转，而人的决策点要保留清晰的入口。

原帖作者统计的“中位11分钟发现完成”暴露了监控盲区。如果有一个仪表盘显示所有代理的任务状态和最近活动时间，这个延迟可以降到秒级。

总结：编排层才是多代理的瓶颈

Claude Code让单个代理的编码能力变得触手可及，但当项目数量上升到两位数时，真正的挑战从“写代码”转移到了“协调代码”。原帖作者的257次复制粘贴是一个极端但真实的信号：缺少编排层，多代理只是多个孤岛。无论是用脚本自动中转、让代理主动通信，还是引入监督者代理，目标都是一致的——把人从“电线”的角色中解放出来，只保留决策和反馈。对于homelab玩家来说，从tmux+轮询脚本开始改造，可能是成本最低的第一步。