为什么 Claude Code 和 Codex CLI 用同一批底层模型，却比直接调用 API 的聊天界面感觉强大得多？Sebastian Raschka 在他的 Ahead of AI Newsletter 里系统回答了这个问题。
LLM、Reasoning Model 与 Agent 的区别
Raschka 首先厘清了三个被频繁混用的概念：
LLM（大语言模型）：核心的下一个 Token 预测引擎。给定输入，输出文本。
Reasoning Model（推理模型）：仍然是 LLM，但经过专门训练或 Prompt 设计，在生成最终答案之前会花更多推理时间进行中间步骤、验证或候选答案搜索。更强但更贵。
Agent：在 LLM 或 Reasoning Model 之上叠加的控制循环（Control Loop）。给定目标，Agent 层决定下一步检查什么、调用哪个工具、如何更新状态、何时停止。这个控制循环，也叫 Agent Harness。
一个直觉性比喻：LLM 是发动机，Reasoning Model 是加强版发动机（更强但更贵），Agent Harness 是帮助你使用发动机的完整车辆系统。你可以单独使用 LLM（聊天界面），也可以把它放入 Harness 获得更强的任务完成能力。
编程 Agent 的六个核心构件
Raschka 归纳的六个主要构建块：
1. Repo Context（仓库上下文注入）
编程 Agent 与普通聊天最本质的区别之一，是它能感知整个代码仓库的结构。Claude Code、Codex 这类工具会在任务开始前自动建立仓库上下文：文件树、关键文件内容、相关函数签名等。这让 Agent 可以做出有依据的代码修改决策，而不是凭空生成。
2. Tool Design（工具设计与边界）
工具是 Agent 与环境交互的接口：读文件、写文件、执行 Shell 命令、调用测试、搜索代码等。工具的设计决定了 Agent 的能力边界，也决定了安全边界。Harness 需要仔细设计哪些工具是允许的，以及什么情况下工具调用应该要求用户确认。
3. Prompt Cache Stability（Prompt 缓存稳定性）
这是一个在工程实践中经常被忽视的构件。现代 LLM API 支持 Prompt 前缀缓存——如果每次请求的 Prompt 前缀相同，可以复用之前的 KV Cache，大幅降低延迟和 Token 成本。Claude Code 达到 92% 以上缓存命中率的关键，正是精心设计了哪些内容放在 Prompt 的稳定前缀部分（系统提示、代码仓库上下文），哪些内容是变化的用户输入。不稳定的 Prompt 结构会让缓存频繁失效，导致延迟和成本飙升。
4. Memory（记忆管理）
编程任务通常跨越多轮交互，Agent 需要管理多种类型的记忆：
- 短期记忆：当前对话的上下文窗口内的内容
- 长期记忆：跨会话的持久化知识（比如项目约定、用户偏好）
- 工具状态：文件系统、测试结果等外部状态
如何在有限的上下文窗口内高效管理记忆，是 Harness 设计的核心挑战之一。
5. Long-Session Continuity（长会话连续性）
现实的编程任务可能需要数十轮、甚至数百轮工具调用。Agent 需要机制来维持长会话的连贯性：上下文压缩、关键信息的提炼与保存、任务进度的追踪。当上下文接近限制时，Harness 需要优雅地处理"遗忘"，而不是硬截断。
6. Agent Loop（目标驱动循环）
整个 Agent 的核心：给定一个目标，循环执行"观察→决策→行动"，直到目标完成或达到停止条件。循环的退出条件设计至关重要——什么时候认为任务完成？什么时候应该向用户请求澄清？这些判断直接影响 Agent 的可靠性。
构件质量决定用户体验
Raschka 的核心论点是：当我们评价一个编程 Agent 的能力时，我们实际上是在评价模型能力与 Harness 设计质量的综合结果。
这也解释了一个常见的困惑：有时候，一个看起来"更弱"的模型在某个 Agent 产品中的表现，可能优于"更强"的模型在粗糙 Harness 中的表现。因为仓库上下文的质量、工具设计的合理性、缓存策略的优化，都在放大或削弱基础模型的实际输出质量。
Claude Code 和 Codex CLI 之所以感觉强大，很大程度上是因为它们在这六个构件上都做了认真的工程投入。