AI编程Agent六大核心组件权威解析
你是否曾疑惑，为何 Claude Code 或 Codex CLI 在实际编码中的表现，远超单纯在聊天窗口调用同一模型？
多数人的第一反应是“模型更强”或“做了针对性微调”。但 Sebastian Raschka 博士的最新分析揭开了真相：关键区别在于 Agent Harness——那个包裹模型的软件框架。
Raschka 是《自己动手构建大语言模型》与《从零构建推理模型》的作者。这篇文章将编程 Agent 的底层结构拆解得十分透彻，尤其适合理解 Claude Code、Codex CLI 这类工具的真实运作机制。
一、核心概念：LLM、推理模型与 Agent
深入技术前，先厘清几个易混淆的术语。
1. LLM（大语言模型）
这是最底层的“下一词预测”引擎，所有智能体系统的动力源。
2. 推理模型
推理模型本质仍是 LLM，但经过特殊训练，在推理时投入更多算力用于中间推理、验证与搜索。你可以把它视为升级版引擎——更强，也更昂贵。
3. Agent（智能体）
Agent 是架在模型之上的控制层。给定目标后，它自主决策：下一步检查什么？调用哪些工具？如何更新状态？何时终止？
4. Agent Harness
这是围绕 Agent 的软件脚手架，负责管理上下文、工具调用、提示词、状态与控制流。
5. Coding Harness
Agent Harness 的专化版本，针对软件工程任务——管理代码上下文、工具、执行与迭代反馈。
核心术语关系示意图
二、一个形象的比喻
Raschka 用一个直观类比来解释：
LLM如同汽车引擎推理模型就是高性能引擎，动力更强但油耗更高Agent Harness则相当于整车的驾驶系统，让引擎真正驱动车辆
这个类比并不完美——LLM 也能独立使用——但它抓住了核心：模型决定了“能跑多快”，Harness 决定了“能跑多远”。
更重要的是，在各大模型能力日趋均衡的当下，Harness 往往成为体验差异的决定性因素。Raschka 甚至推测，如果把 GLM-5 放进类似 Claude Code 的 Harness 中，它的实际表现很可能不弱于 GPT-5.4。
三、编程 Agent 的六大核心组件
Raschka 将编程 Agent 拆解为六个核心组件：
六大核心组件概览
组件一：实时代码库上下文
这是最直观也最关键的一层。
当用户下达“修复测试”指令时，模型需要明确：这是不是 Git 仓库？当前在哪个分支？项目结构如何？是否存在 AGENTS.md 或 README 说明文件？
为什么如此重要？因为“修复测试”并非自包含指令。如果 Agent 读取了项目文档，就能知道该执行哪个测试命令；如果理解了仓库布局，就能在正确路径下查找，而非盲目猜测。
实现要点通常是：在开始工作前先收集一组稳定事实，包含 Git 状态、分支、最近提交等信息，且无需每次从零重建。
组件二：提示词形状与缓存复用
编程会话往往重复性极高：Agent 规则基本固定，工具描述基本固定，工作区摘要也基本固定。真正变化的，主要是用户请求、对话历史与短期记忆。
高效设计不会每次重建一个庞大的提示词。
提示词与记忆的分层架构
核心洞察在于：收集仓库事实与打包缓存事实，是两个独立的步骤。
组件三：工具访问与使用
这是从“聊天”进化到“智能体”的关键一步。
普通模型只能用自然语言推荐命令，而编程 Agent 会实际执行命令、获取返回结果，并将结果反馈到下一轮推理中。
当然，并非让模型完全自由操作。实际流程更接近以下模式：
工具调用的安全流程
安全边界通常包括：预定义的允许工具列表、路径检查（仅限仓库内操作）、用户审批机制。这些看似限制的规则，实际上是提升可靠性与可用性的关键。
组件四：最小化上下文膨胀
上下文膨胀是 LLM 的通病，编程 Agent 尤为严重：重复读取文件、冗长的工具输出、大量日志……若保留全部内容，上下文窗口很快就会被撑爆。
这里有两种核心压缩策略：
- 截断：缩短长文档、截断大输出、压缩记忆笔记
- 对话压缩：将历史转为摘要，保持最近事件更详尽
额外技巧包括：对旧文件读取去重，避免重复看到同一内容；保持最近事件更详尽；对旧事件实施更激进的压缩。
原文有一句话值得铭记：很多看似模型能力的问题，本质上其实是上下文质量问题。
组件五：结构化会话记忆
这一层与上一组件紧密关联，但关注点不同。
压缩后的对话历史与工作记忆
两层状态管理可概括为：
- 完整对话记录：存储所有请求、输出、响应，只追加不修改，支持会话恢复
- 工作记忆：小型、精炼的状态，记录当前任务、重要文件、最近笔记，会被修改与压缩
组件六：委托与有界子智能体
为什么要委托？实际理由包括：并行处理子任务，避免单一循环承载所有工作——如查找符号、检查配置、诊断测试失败。
核心挑战在于如何约束子智能体。子智能体需要继承足够的上下文才能工作，但同时必须有边界：
- 只读模式：子智能体不能修改文件
- 递归深度：限制子智能体再启动子智能体
- 工作范围：限制操作的目录或文件
原文的总结很到位：继承足够上下文才能发挥作用，但必须设置约束边界防止失控。
四、完整架构总览
将这六个组件整合起来，大致呈现如下分层结构：
整体架构分层示意
这张总览图最重要的信息在于：它将 harneess 放在模型外面整整一层。也就是说，用户请求并非直接送入模型，而是先经过代码库上下文、稳定提示词前缀、工具访问与使用、上下文管理、会话记忆、子智能体委托，最后才进入 LLM 或推理模型。
五、编程 Agent vs 通用 Agent 平台
Raschka 还对比了编程 Agent（如 Claude Code）与通用 Agent 平台（如 OpenClaw）：
编程 Agent 与通用 Agent 平台的区别
核心差异在于：编程 Agent 优化的是“一个人在仓库中工作”的场景，而 OpenClaw 优化的是“跨多个聊天、通道、工作区运行多个长期 Agent”。编程只是其中一种工作负载。
六、核心洞见总结
1. 模型不是全部
在许多实际应用中，围绕模型的系统与模型本身同等重要。这也是为什么同一个模型放进 Claude Code 后，体验会与聊天界面天差地别。
2. Harness 是差异化因素
在模型能力逐渐趋同的背景下，Agent Harness 往往就是体验差异的来源。一个设计合理的 Harness，能让模型的能力更稳定地发挥出来。
3. 上下文质量 = 模型表现
许多看似模型能力的问题，最终都会落在上下文质量上。
4. 边界即自由
预定义工具、路径检查、审批机制——这些边界看似限制，实际上能提升可靠性与实用性。
七、实践建议
如果你想构建自己的编程 Agent，或希望更深入地理解现有系统：
- 从最小可行实现开始
- 重视上下文管理
- 工具设计要有清晰边界
- 会话记忆要分层存储
- 提示词缓存尽量复用