第八章：横向比较的单位应当是工程问题

8.1 不把四条主路径压成同一个函数

四套系统都连接模型与工具，但它们的对象层级、扩展方式和部署关注不同。Claude Code 快照中可观察到多类型事件交付与独立工具执行器；DeepSeek Harness 强调日志派生视图和插件作用域；Pi 提供可组合的代理与模型流接口；Codex 则呈现输入通道、步骤上下文与执行编排的清楚边界。

这组描述适合作为读书路线，不是给项目排座次。要比较某项能力，应拿相同任务、相同资源范围和相近故障条件来观察。单看代码行数，既无法证明可靠性，也无法说明维护成本。

8.2 用决策矩阵代替标签

每一项也可能在其他项目找到相似设计。矩阵表达“哪里最适合从本书继续阅读”，不表达某个项目独占某项能力。

8.3 容易做出的三种错误结论

第一种是“存在钩子，所以有沙箱”。钩子只说明宿主有机会检查，是否能在操作系统层限制文件与网络，需要看执行提供方。第二种是“有会话日志，所以可以安全恢复任何工具”。日志只记录已知事实，无法自动消除外部副作用的不确定性。第三种是“支持并行，所以更快”。收益取决于独立工作比例、外部资源限额和结果提交成本。

对这三种说法，都可以提出一个反例：直接绕过钩子调用函数、写入完成后日志未落盘、两个写工具竞争同一文件。架构研究有价值的地方，就是找出设计在这些条件下给了什么保证。

8.4 用一份决策记录结束比较

假设团队只需一个单人、只读的仓库问答工具，模型接口可替换、明确的读取边界与可靠错误结果可能就足够。此时复制一个完整插件容器会增加学习与运维成本。

若团队需要远程执行、可恢复的长期任务和第三方扩展，生命周期、会话协议、能力提供方及执行隔离就变成核心需求。你需要更多结构，不是因为结构本身高级，而是因为故障和协作需求已经要求这些边界。

建议每次比较写一页记录：当前任务、约束、候选方案、采用理由、牺牲的能力以及以后重新决策的触发条件。这样源码研究才能转化为自己的工程选择，而不止是收藏一张漂亮架构图。