把 Orca 的 DeepSeek测评看什么-指标和场景要分清

如果只是逐项记功能，DeepSeek的实际价值并不容易看出来。把前言、背景：Agent 为什么特别吃缓存、先把评测口径说清楚放到具体场景里理解，使用时会更清楚。

具体操作要围绕这些条件展开：前言这几天我在 Orca 里做了一轮比较硬的优化：DeepSeek 上下文缓存。；这件事一开始看起来很简单：既然 DeepSeek 有 prefix cache，那就让每轮请求前缀尽量稳定。；系统提示词别乱变，工具 schema 别乱变，对话历史 append-only，不要动老消息。。往下核对时，条件要对应这些点：但真正做下来，我最大的感受是：缓存优化不是靠读代码“想明白”的，它必须拿真实 API 一轮一轮去撞。；因为这里面有太多看起来合理、实际没效果的判断：你以为改了，其实没改到真实 wire prompt。；你以为只是本地 token 预算情况，实际 API 请求里还注入了 summary、tools、volatile overlay。。收尾检查时，再把这些细节对上：你以为 remote summary 能靠稳定 prompt 命中缓存，真实 API 返回还是 0%。；你以为压缩是在省 token，结果一不小心变成压缩风暴，每轮都压。；Orca 最终在真实 API 评测里，压缩后的主链路能稳定到 99% 左右缓存命中。。