中文精炼导读
核心观点
- Sebastian Raschka 系统拆解了"编程智能体"（coding agent）的设计：它本质是把 LLM 包进一层智能体外壳（agent harness），围绕"仓库上下文、工具、提示缓存、内存、会话连续性"做工程，而不是只依赖模型本身。
- 三层概念需要分清：LLM 是"引擎"；推理模型（reasoning model）是更强但也更贵的"加强版引擎"；agent harness 则是让引擎发挥出最大作用的"传动系统"。同样一个模型，放进 Claude Code/Codex 这类 harness 里远比裸聊天界面好用。
- 文章给出了编程智能体的六大核心组件：实时仓库上下文、提示形态与缓存复用、结构化工具与权限校验、上下文膨胀控制、结构化会话记忆、带边界的子代理委派。
- 关键洞见：如今主流基础 LLM 的裸能力已相当接近，真正的差异化往往来自 harness 层——"很多看起来是模型质量的东西，其实都是上下文质量"。
- 作者以自己用纯 Python 实现的 Mini Coding Agent（零第三方依赖）为实例，逐一定位每个组件在真实代码中的位置。
内容精讲
文章先厘清三个常被混为一谈的概念。LLM 是最底层的"下一个 token 模型"；推理模型仍然是 LLM，但被训练/提示为在推理上投入更多推理期计算——中间推理、自我校验、对候选答案的搜索；agent 则是叠加在模型之上的一层，可以理解为一个围绕模型的"控制循环"：给定目标，agent 层（harness）决定下一步检查什么、调用哪个工具、如何更新状态、何时停止。作者用一个三层比喻总结：模型是引擎，推理模型是更强的引擎（更有力但更贵），harness 帮助我们用好引擎。更具体地说，coding harness 是为软件工程任务定制的智能体外壳，负责代码上下文、工具、执行与迭代反馈的管理。
为什么 harness 这么重要？因为编程工作只有一部分是"生成下一个 token"。真正的难点在于仓库导航、搜索、函数查找、diff 应用、测试执行、错误检查，以及把所有相关信息保持在上文中——这正是程序员在写代码时不愿被打断的原因。一个良好的 coding harness 能让推理模型和非推理模型都比在纯聊天框里"强得多"，因为它做了上下文管理等大量工作。作者甚至给出了一个大胆判断：如今 vanilla（未定制）版本的主流 LLM 能力已经非常接近，把 GLM-5 这类最强开源模型放进合适的 harness，很可能达到 GPT-5.4 in Codex 或 Claude Opus 4.6 in Claude Code 的水平——当然，针对 harness 的特定后训练仍然有益（OpenAI 曾维护 GPT-5.3 与 GPT-5.3-Codex 两个变体即是例证）。
第一个组件是"实时仓库上下文"。当用户说"修好这些测试"或"实现某某功能"时，模型应该知道自己在不在 Git 仓库里、在哪个分支、项目里有哪些文档包含指令。这不是自包含的指令：如果智能体看到 AGENTS.md 或项目 README，就可能学到该运行哪个测试命令；知道仓库根目录与布局，就能去对的地方查找而非瞎猜。Git 分支、状态和提交记录还能提供"当前改动进展到哪"的上下文。做法是：harness 在干活之前先构建一份小的"工作区摘要"（稳定事实），与用户请求拼接，让模型不用每次从零开始。
第二个组件是"提示形态与缓存复用"。会话是重复性的：agent 规则通常不变、工具描述通常不变、工作区摘要大体不变，真正变化的主要是最新用户请求、最近对话记录和短期记忆。聪明的运行时不会每一轮都把所有内容重建成一大坨无差别的提示词，而是构建一个"稳定提示前缀"（一般指令 + 工具描述 + 工作区摘要），配合高频更新的会话状态（短期记忆、最近记录、最新请求）后喂给模型。缓存并复用稳定前缀，避免每轮都白费算力重建。
第三个组件是"工具访问与使用"，这是从"聊天感"变成"agent 感"的分界。普通模型只能用散文提建议，而 harness 里的 LLM 能实际执行命令并取回结果。但 harness 不会让模型即兴发挥任意语法，而是提供一份预先定义的、带明确输入与边界的具名工具清单（列文件、读文件、搜索、运行 shell 命令、写文件等），加上 `subprocess.call` 这类可执行任意命令的兜底。模型输出结构化动作后，运行时先做程序化检查：是已知工具吗？参数有效吗？需要用户批准吗？请求的路径在工作区内吗？全部通过才真正执行。这看起来是"限制模型的自由"，实际同时提升了可靠性——模型无法执行完全任意的命令，文件访问也被限制在仓库内。
第四个组件是"控制上下文膨胀"。上下文膨胀并非编程 agent 独有，但编码场景尤其严重：反复读文件、冗长的工具输出、日志，如果全程保真，上下文 token 很快就会耗尽。好的 harness 至少用两种压缩策略：一是裁剪（clipping）——缩短长文档片段、大工具输出、记忆笔记和对话记录，防止任何一段文本因话痨而霸占提示预算；二是记录缩减/摘要——把完整会话历史压缩成可入提示的摘要，关键技巧是"近的保留更完整、远的压缩更狠"，因为近期事件更可能影响当前步骤。此外还要对旧的重复文件读取去重，避免模型反复看到同一文件内容。作者强调这是被低估的"枯燥"设计点："很多看起来是模型质量的东西，其实都是上下文质量。"
第五个组件是"结构化会话记忆"。这里把状态分成至少两层：完整对话记录（transcript）——涵盖所有用户请求、工具输出和 LLM 响应，以 JSON 文件形式落盘，可随时恢复会话；工作记忆（working memory）——一份小而精的蒸馏状态，随回合被修改与压缩而非只追加，保存"当前任务、重要文件、近期笔记"这类跨回合有意义的信息。两者分工不同：压缩后的 transcript 用于提示重建，给模型一个压缩的近期历史视图；working memory 用于任务连续性，保持跨回合真正重要的信息。
第六个组件是"带边界的子代理委派"。当主 agent 中途需要旁路答案（哪个文件定义了某个符号、配置说了什么、测试为什么失败）时，把它拆成有界子任务比让单个循环同时扛所有线头更高效。但子代理只有继承足够上下文才有用，若不加约束又会出现多个代理重复干活、碰同一批文件甚至无限下钻的问题。所以设计难点不只是"如何派生子代理"，更是"如何绑定它"：子代理继承足以干活的上下文，但在更紧的边界内运行（例如只读、限制递归深度）。Claude Code 早已支持子代理，Codex 最近也加入——Codex 通常不强制子代理只读，而是继承主 agent 的沙箱与批准设置，边界主要体现在任务范围、上下文与深度上。
文章最后把 OpenClaw 拿来对比：OpenClaw 更像一个本地通用的 agent 平台（也能编码），与专门面向仓库内编程的 coding harness 有不少重叠（AGENTS.md/SOUL.md/TOOLS.md 提示文件、JSONL 会话文件、记录压缩、子代理），但重心不同——编程 agent 优化的是"一个人在仓库里高效地让助手检查文件、改代码、跑本地工具"，而 OpenClaw 优化的是"跨会话、渠道与工作区运行大量长生命周期本地代理"。
阅读价值
适合想深入理解 Claude Code/Codex 这类工具内部原理的开发者与 AI 应用工程师：文章用清晰的六组件框架和可运行的 Mini Coding Agent 源码，把"为什么同一个模型在 harness 里更好用"讲得明明白白；如果你想自己搭建或评估智能体系统的外围工程（上下文管理、工具校验、记忆设计、子代理），这是一份理想的参考手册。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://magazine.sebastianraschka.com/p/components-of-a-coding-agent