DeepSeek接Agent建议慎用codex

背景

随着大语言模型在编程辅助、Agent 编排等场景的普及，开发者越来越倾向于将不同模型与多种工具链组合使用，以平衡成本、速度和效果。DeepSeek 作为开源模型中的热门选择，因其高性价比被广泛接入各类 Agent 或代码补全工具。然而，不同工具对 DeepSeek 的适配程度存在差异，部分用户在实际使用中发现了意料之外的 Token 消耗问题。本文源自 LINUX DO 社区的一则讨论帖，发帖人分享了自己在更换 DeepSeek API 接入方式后的观察与提醒。

核心内容

发帖人原本使用 codex（推测为某种基于代码上下文的辅助工具或 Agent 框架）接入 DeepSeek 模型，但在 codex 额度耗尽后，转而通过 cc switch（一种路由切换工具）直接调用 DeepSeek API。切换后，他注意到两个现象：

• 缓存命中率有所下降；
• Token 消耗明显增加。

发帖人认为，缓存命中率降低只是部分原因，Token 消耗过高的背后可能还有其他因素。作为对比，他在 Claude Code 中使用 DeepSeek 时表现正常，在 Hermes（可能指另一个 Agent 或 API 客户端）中使用也基本正常（尽管使用频率不高）。因此，他初步得出结论：在 codex 环境下使用 DeepSeek 可能效率较低，建议改用其他工具接入。

发帖人同时承认，该结论并未严格控制变量，缺乏严谨性，仅作为参考与提醒，并邀请社区成员讨论与指正。

关键要点

• 问题场景：codex 额度耗尽后，改用 cc switch 调用 DeepSeek API，导致 Token 消耗大幅上升。
• 缓存影响：切换后缓存命中率降低，但不足以完全解释 Token 增加。
• 交叉验证：在 Claude Code 中接入 DeepSeek 表现正常；在 Hermes 中也基本正常。
• 结论：不建议在 codex 中使用 DeepSeek 模型，建议更换为其他工具。
• 局限性：未做控制变量实验，结论仅供参考，欢迎社区进一步验证。

意义与影响

1. 对 DeepSeek 用户的实际指导：许多开发者通过 Agent 工具或代码补全工具使用 DeepSeek，若 codex 存在适配问题，可能导致不必要的 API 成本。该帖提供了一条实际排查路径：当感到 Token 消耗异常时，可尝试切换接入工具。
2. 工具链兼容性提醒：同一模型在不同客户端/框架下的表现可能存在显著差异，不仅涉及缓存机制，还可能涉及 prompt 构造、上下文管理、请求批处理等底层逻辑。用户应关注工具本身的实现细节，而非仅依赖模型质量。
3. 社区驱动的最佳实践：此类非正式但真实的经验分享，有助于快速定位问题，但需要更多控制变量实验来确证。该帖同时展示了社区自发的质量反馈机制，对模型服务商和工具开发者也有参考价值。