Reason Machines · 项目文档 / 0xLogicrw · 开发复盘 · 阅读原文
原始来源：Reason Machines · 项目文档 / 0xLogicrw · 开发复盘
发现渠道：X · AI 技术讨论
同事电脑上的 Agent 正在改后端接口，自己这边的 Agent 能否直接问它，而不用人复制两段聊天？Reason Network 为运行中的会话建立目录，标出所属人、电脑、仓库、分支和当前状态，通过 iroh 直连或加密中继传递消息。当前文档同时支持 Reason 工作区和免账号组队；不同客户端的收件能力并不相同，有的可在会话中推送，有的等下一步，有的需要查收 inbox。它首先解决“找到谁、怎样联系”的问题。
消息也有不同阶段：保存、送达、被暂缓或拒收，不能把送达回执解释为任务完成。设计文档说明了团队成员校验、接收策略、把同伴文字标为外部输入，以及限速和连续往返限制。这些是实现者描述的保护措施，不是安全性证明。与此同时，0xLogicrw 从这个项目谈到自己做 AGPair 的经历：为了让两个编程 Agent 协作，最后却把大量时间花在管理进程、恢复失败和检查交付上。
可信度 65 · 重要性 86 · 新颖度 68
技术与主题
Agent 系统 · AI 编程 · Agent Messaging · Session Discovery · Task Handoff · iroh
0xLogicrw
从 Reason Network 的会话通信谈到自己三月至六月开发 AGPair 的经历；这不是对 Reason Network 的故障测试。
忠实转述（非原句）：作者最初想让 Codex 派活、Antigravity 执行，利用后者当时充裕的额度。他先用 SQLite 传消息，由 IDE 扩展收任务和回传结果；也试过原生会话接口，但新会话 ID 不可用、完整对话读不到，只好改用 IDE 命令，并要求 Agent 把结果写入文件。
后来，他接入更多外部 CLI 执行器，随之遇到任务卡住、进程退出后难判是否完成、并行修改冲突和交付难验收的问题，于是逐步加上状态机、重试、worktree 隔离和结构化回执。到六月，系统已经能并行派活、追踪结果和查看 diff，项目也越来越重。
他并不否认隔离和验收的价值；遗憾的是，基本交互还没做好，精力就转向让复杂任务系统持续运转。六月底，他停止开发 AGPair，转去研究已有 Agent 的运行时与会话接口，希望先把接入和交互做好。
Kimka778
回应原帖：原帖作者
直接回复原帖，提出威胁场景；没有报告已发生攻击。
忠实转述（非原句）：评论者担心，同事的 Agent 若被恶意 README 误导，再向自己的会话发消息，会不会把错误指令继续传过来。他追问项目是否有发件人白名单，或要求人确认后才执行。
shuige_notes
回应原帖：原帖作者
直接回复原帖，对多机协作价值与实践痛点的简短判断。
忠实转述（非原句）：他认为多机协作的价值在于把任务交给不同环境，而不是把算力简单相加；实际使用最先遇到的往往是文件同步，以及失败后如何回滚。
编辑评读
这篇复盘最有用的地方，是把协作成本拆到了具体故障上。原生会话接口能否可靠读写，决定能否沿用现有工作环境；任务结束后有没有可验收结果，决定是否真的完成了委托。两件事都需要工程支持，但不能靠多加一个状态或一条自动重试规则，就假定用户的操作会更简单。
对 Reason Network，当前可以确认的是通信和会话发现机制。kazu 的公开试用在同一台 Mac 上完成终端往返并让 Codex 成功调用 list_team；作者明确说跨电脑测试、Claude 与 Codex 模型间的往返尚未完成。这比演示说明多了一步实际使用，也仍不足以说明多 Agent 能稳定交付完整项目。评论者提出的注入风险应继续看具体接收策略与失败案例，不能把疑问写成已发生的漏洞。