reason-machines/reason-network

解决什么问题

当几个人在同一代码库上各自跑编码 Agent 时，这些 Agent 彼此是孤岛。一个 Agent 需要另一个人的 Agent 手里的 schema 或某个决定，唯一的通道就是那个人本人，在两个终端之间手工转述。每个会话在哪个仓库、哪个分支、忙还是闲，这些上下文各在各的机器上，需要的人根本看不到。Reason Network 在每台电脑上装一个小守护进程，让会话互相可见，并能直接给对的那个会话发消息。

有什么不同

多数多 Agent 工具假设所有 Agent 跑在单一编排器、单一进程或单一云账号下；这个项目把每个同事的机器当成点对点网络里的一个节点，用 iroh 直连，失败时走只看得到密文的 relay。守护进程是挂在 Agent 会话生命周期上的，而不是再套一层聊天界面：消息可以落到 Claude Code、Codex、opencode、pi 和 Reason 的会话中途，空闲会话会被唤醒。第二个区别是 ask_user：远程 Agent 可以向不在电脑前的人请求批准，回答以那个人的身份直接回到 Agent，而不是当作一条谁都能伪造的消息。身份模型是核心：只有团队成员能连，一台电脑只能代表它自己。README 对机制写得很细，但对失败模式和大队部规模下的表现着墨不多。

适合谁

适合已经每天在使用编码 Agent、本来就在聊天工具里互相协调的小到中型团队：价值出现在两三个会话确实需要彼此上下文的时候。不适合独立开发者（没有对象可连），不适合需要审计日志或集中记录 Agent 流量的团队，也不适合无法在每台机器上跑守护进程或开 UDP 的环境。想要一个统一编排层而非对等会话的人，应该去看托管型 Agent 平台。

上手成本

每台电脑装一个守护进程，并用 Reason 账号登录：虽然流量是点对点的，但身份是托管依赖；默认地址查找走 n0，除非团队自建 relay。支持 macOS、Linux、Windows，需要浏览器登录，setup 时会改动 Agent 配置（MCP server reason-network）。项目只有 8 天，API、CLI 参数和会话 hook 的行为都应按移动目标对待。MIT/Apache-2.0 双许可没有障碍。安装是 curl 管道到 bash，部分组织会直接禁止，先读脚本。

点评

这是一个有真实设计的项目，不是套壳：对等身份、会话级收件箱、把人工审批绕回 Agent，都不是随手能做的。但它太新了，创建仅 8 天就到 1,195 stars，新 Rust 榜上日均约 +142，目前的关注是发布脉冲而非历史成绩。Hacker News 上没有讨论可供参考独立评价，也没有长期维护信号。值得在一个小而可信的团队里试用，看 Agent 之间的对话是否真的降低了协调成本；在维护性和故障行为更清楚之前，不要放进安全敏感或大型组织。