同一模型为何在CLI工具中表现截然不同：解析AI Harness的神奇魔力

许多用户在体验Claude Code和Codex CLI后都会有一个共同的困惑：为什么同一个AI模型在这些专用CLI工具中表现远比普通聊天界面强大？这并非幻觉，而是AI领域一个值得深入探讨的技术现象。当前AI发展的实际进展已经不单纯取决于模型本身变得有多强，更重要的是我们如何构建围绕模型的外层系统——包括工具调用、上下文管理、记忆机制等，这些基础设施正在扮演与模型能力同等重要的角色。

Coding Agent的六大核心组件

理解这一现象需要先厘清几个核心概念。LLM是最核心的next-token预测模型，相当于汽车的发动机；Reasoning Model则是经过特殊训练、会在给出答案前进行更多推理和验证的增强版本；而Agent是运行在模型外的控制循环，负责决定下一步查看什么、调用哪个工具、如何更新状态；最后，Harness是Agent的软件控制层，负责管理上下文、工具、提示词、状态和控制流。当我们谈论某个模型的编程能力时，往往将模型能力、推理行为和Agent产品混为一谈，但实际上，写代码远不止生成token，还包括仓库导航、文件搜索、执行测试、检查错误等一系列复杂操作，这些能力大多不在模型本体能力范围内。

工具调用与上下文管理

一个优秀的Coding Agent需要具备六个核心组件才能发挥最大效能。首先是实时仓库上下文，Agent在开始工作前必须清楚自己处于什么位置——是否在Git仓库中、当前在哪个分支、哪些项目文档可能包含相关指令。如果Agent能看到AGENTS.md或项目README，就能知道该运行什么测试命令；如果了解仓库根目录和布局，就能准确找到目标文件而非盲目猜测。其次是提示结构和缓存复用，合理的做法是将prompt拆分为稳定前缀（通用指令、工具描述、工作区摘要）和动态部分（短期记忆、最新用户请求），这样才能真正发挥prompt cache的价值，这也是为什么直接调用API构建Agent的用户往往发现token消耗比Claude Code高出数倍。

上下文压缩与记忆机制

第三个核心组件是工具访问与结构化调用，这是从普通聊天升级为Agent的关键转折点。普通模型只是在文字中建议“你应该运行pytest”，但Coding Harness需要真正执行命令并获取结果。Harness提供预定义的工具列表，每个工具有清晰的输入输出边界，模型发出结构化action后经过验证、审批、执行、反馈的完整流程。边界约束越清晰，执行者反而越能稳定发挥。第四个组件是上下文压缩策略，长上下文成本高昂且引入噪声，优秀的Harness会采用裁剪策略缩短长文档片段和工具输出，以及会话压缩策略将完整历史转化为可提示摘要，对近期事件保留更丰富信息，对早期事件更激进压缩。这是常被低估但极为关键的部分——很多看似模型质量的问题实则是上下文质量问题。

编排与系统设计

第五个组件是结构化会话记忆，分为工作记忆和完整会话记录两层。工作记忆是Agent显式维护的小而浓缩的状态，完整会话记录则以JSON形式保存在磁盘上用于会话恢复。两者分工明确：压缩后的会话记录为prompt重建服务，工作记忆为任务连续性服务。第六个组件是编排能力，当主Agent需要处理旁支任务时（如查看配置或分析测试失败原因），拆分为有边界的子任务比让单一循环同时处理所有线程更高效。subagent需要足够上下文才能工作，但必须严格约束（如只读、递归深度受限），这本质上是一个分布式系统设计问题。

如有侵权，请联系删除。