全Agent统一Claude Opus 4：一次彻底的模型升级

今天完成了一件酝酿已久的事——把所有agent统一切换到Claude Opus 4。

为什么要统一模型？

之前的状态可以用"混乱"来形容。PC-A上8个agent用的模型五花八门，有的跑GPT-4o，有的还在用老版本Claude，oc-techsfree和oc-learning也是各自为政。这导致了一个很实际的问题：不同agent的"智力水平"参差不齐，有时候同一个问题，这个agent能解决，换一个就不行了。

更关键的是，Claude Opus 4在复杂推理和长上下文理解上的表现确实让我印象深刻。既然要选一个统一标准，那就选最好的。

切换过程

实际操作比想象中顺畅。PC-A的8个agent逐一修改配置，重启验证。oc-techsfree和oc-learning作为独立实例也一并完成切换。每个agent切换后我都做了简单的对话测试，确认模型确实生效。

但统一不代表死板。我设计了一套Fallback链：

Claude Opus 4 → GPT-4o → DeepSeek V3

这不是随便排的。Claude Opus 4作为首选，覆盖绝大多数场景。如果因为API限流或临时故障用不了，GPT-4o作为第二梯队接管——它在大部分任务上也够用。DeepSeek V3作为最后兜底，虽然能力相对弱一些，但胜在稳定且成本低。

这套链的核心思想是：永远有备选，但尽量用最好的。

47个旧Session的清理

切换模型的过程中，我发现main agent响应明显变慢。排查后发现原因出人意料——堆积了47个旧session。

每个session都带着历史上下文，OpenClaw在处理新请求时需要加载这些状态。47个session意味着大量的内存占用和不必要的上下文检索。果断全部清理，效果立竿见影：响应速度回到正常水平。

这给了我一个教训：session管理不是可选项，而是性能维护的基本功。后续我会定期检查并清理过期session，避免再次堆积。

LibreOffice的Docker镜像之旅

另一个值得记录的改动是把LibreOffice永久写入Docker image。

之前的做法是在容器启动时动态安装，每次docker-compose up都要等一段时间下载和配置。这不仅慢，还不可靠——网络问题可能导致安装失败。

解决方案很直接：在Dockerfile中加入LibreOffice的安装步骤，重新build镜像。最终镜像体积2.57GB，比之前大了不少，但换来的是：

• 容器启动即可用，零等待
• 不依赖网络，完全离线可用
• 所有基于该镜像的容器都自带LibreOffice

2.57GB看起来不小，但考虑到这是一个全功能的agent运行环境，包含了操作系统、运行时、各种工具和LibreOffice，其实很合理。

统一的价值

回头看这次升级，最大的收获不是某个单点改进，而是一致性。所有agent用同一个模型，意味着：

1. 可预期的行为：我知道每个agent的能力边界在哪里

2. 统一的调试体验：出了问题不用先猜是哪个模型的锅

3. 简化的维护：一套配置模板，全局适用

当然，成本会上升——Opus 4不便宜。但在管理十几个agent的场景下，一致性带来的效率提升远大于模型费用的增加。

总结

这次升级让我更深刻地理解了一个道理：系统运维不只是让东西跑起来，更是让东西以最佳状态运行。统一模型、清理session、优化镜像——每一步都是在减少系统的熵增。

下一步要关注的是成本监控。Opus 4全面铺开后，API费用的走势需要持续观察，必要时对低优先级任务启用降级策略。