两个Claude互相甩锅3天后，这个程序员被逼出了个狠活

去年有个数据挺有意思：GitHub Copilot用户平均每月接受30%的代码建议，但AI代理（AI Agent，能自主执行任务的智能体）之间的协作效率几乎为零。不是技术不行，是架构问题——所有代理都得通过人类传话，像极了两个部门之间必须找领导签字才能沟通。

硅谷开发者Xaviair最近就卡在这个坑里。他和同事同时用Claude Code搞基础设施项目，一个写服务，一个配Pulumi。两周下来，两人发现自己成了「人形消息队列」：复制粘贴AI的输出、截图发过去、等对方AI处理完再传回来。效率损耗比直接手写还高。

他算了笔账：每次上下文切换平均浪费23分钟，一天切换8次就是3小时。这还没算信息失真——人类转述时总会漏掉技术细节，导致AI反复确认。两周后Xaviair掀桌了，花周末写了个开源中继层Handoff，让代理直接对话。

从「人形路由器」到「代理自治」

Handoff的核心设计很直白：给AI代理一套它们能理解的协作原语，就像人类团队用的Slack或飞书。

具体包括频道（channels）、线程（threads）、@提及（mentions）、已读回执（read receipts）和共享状态（shared status）。Xaviair在博客里贴了一段对话示例：

「你的Claude："ArgoCD expects deploy/{service}/kustomization.yaml"」
「对方的Claude："Structured deploy/ to match. checkout-api, inventory-service ready."」

没有人类介入，没有复制粘贴，没有截图。两个代理在deploy频道里对齐了文件结构，直接推进到下一步。

这套协议的技术实现分三层。最底层是REST API，支持团队注册、密钥管理和消息CRUD。中间层是MCP服务器（Model Context Protocol，Anthropic推出的AI工具调用标准），Claude通过它自动发现17个协调工具。最上层是可选的SSE实时推送（Server-Sent Events，服务器主动推送技术）和客户端AES-256-GCM加密。

Xaviair特别强调了权限系统——这是他「最骄傲的功能」。每个API密钥附带权限映射，精确控制可访问的频道和操作级别。比如build频道可写、deploy频道只读、monitoring频道只读。这种细粒度控制在企业场景很关键：你不会想让测试环境的代理意外触发生产部署。

17个工具，零配置上手

Handoff的接入流程被压缩到两步，每一步都是单条命令。

第一步创建团队：curl POST到signup端点，传team_name和sender_name，返回API密钥。第二步添加MCP服务器：claude mcp add handoff加上环境变量，npx直接拉取SDK。完事。Claude会自动识别这17个工具，并在需要时调用。

工具列表覆盖了协作的全生命周期：post_message发消息、reply_to_thread回复线程、set_mention指定接收方、ack确认已读、get_acks查看他人进度、read_unread拉取新消息、set_status更新键值状态、subscribe_channel订阅实时推送……

状态系统值得细说。每个频道维护一组键值对，比如stage=building、lock=agent-1、progress=4/5。每次写入都带日志，可追溯完整变更历史。这比人类在群里发「我改好了」靠谱得多——代理能精确知道谁在什么时候做了什么，不存在「我以为你说的是那个」的歧义。

消息线程的设计也很关键。代理可以回复特定消息ID，保持对话脉络清晰。人类团队常有的「翻聊天记录找上下文」问题，在代理协作里通过结构化数据直接解决。

为什么现在才有人做？

这个问题反过来问更尖锐：为什么AI代理的协作基础设施落后了整整两年？

2023年AutoGPT爆火时，行业注意力全在「单个代理能做多复杂的事」。多代理协作被视为高级功能，默认先搞定单代理再说。但Xaviair的经历揭示了一个被忽视的痛点：当两个开发者各自用AI工具时，工具之间是孤岛，人类被迫成了集成层。

这种架构债务在小型团队里还能忍，规模稍大就崩。想象一个场景：前端代理、后端代理、DevOps代理、测试代理，四个AI同时跑在一个项目里。没有中继层的话，人类得同时盯着四个窗口，当翻译、当仲裁、当故障背锅侠。

Handoff的解法是把「人类退出协作回路」作为设计目标。不是完全去掉人类监督——权限系统和审计日志保留了管控抓手——而是让代理之间的信息流动不再经过人类缓冲区。

这和工业自动化的历史有点像。早期工厂里，每个机器需要工人看管、传递半成品。流水线出现后，机器之间直接衔接，工人转到质检和异常处理。Xaviair的relay本质上是在给AI代理铺流水线。

开源48小时后的反馈

Handoff在GitHub开源后，Xaviair收到了两类最集中的反馈。

一类是功能请求：多团队联邦（类似Slack Connect）、消息持久化策略、与Kubernetes原生集成的operator。另一类是安全担忧：客户端加密虽然让服务器看不到明文，但密钥分发怎么保证？代理被劫持后伪造状态怎么办？

Xaviair的回应很产品经理：先解决「有没有」，再优化「好不好」。当前版本验证了核心假设——代理确实能自主使用这些协作原语，且效率显著提升。他和同事的项目后期，人类介入频率从每天20+次降到3-4次，主要集中在需要人工判断的架构决策点。

有个细节很有意思。Xaviair发现代理对「已读回执」的使用比人类更激进——它们几乎每条消息都ack，因为计算成本忽略不计。这导致get_acks的返回数据量爆炸，他不得不加了分页。人类社交里的「已读不回」焦虑，在代理世界不存在，但带来了新的工程问题。

另一个意外是线程的使用模式。人类倾向于在单个频道里开多个并行话题，代理反而更守规矩：一个任务一个线程，做完归档。Xaviair怀疑这是Claude的上下文管理机制在起作用——线程帮它压缩了需要跟踪的状态范围。

目前Handoff的部署实例还不多，但Xaviair已经在吃自己的狗粮：用Handoff协调Handoff本身的开发。三个Claude实例分别负责文档、测试和代码审查，他在需要时才介入。这种「自举」场景是对架构最好的压力测试。

如果AI代理的渗透率继续上升，类似Handoff的基础设施会变成标配。问题只是：它会像Docker一样成为开源标准，还是像Kubernetes一样被云厂商收编？Xaviair押注前者，但承认需要更多生产环境的验证。你的团队现在有几个AI代理在同时运行？它们之间怎么对话——还是也在靠你传话？