devgo.cn核心观点
- 编码 Agent 的能力不只是模型的选择：repo 上下文、工具设计、提示缓存稳定性、记忆与长会话连续性，这些「周围系统」与模型本身同等重要。
- 概念分层要分清：LLM 是核心下一个 token 引擎；推理模型是「强化版引擎」（更多推理时计算）；Agent 是围绕模型的控制循环；harness 是管理上下文、工具、提示、状态与控制流的软件骨架。
- coding harness 把三层叠在一起：模型家族（引擎）+ Agent 循环（观察→检查→选择→行动）+ 运行时支撑——这让推理模型在编程任务上远比裸聊天框表现强。
- 这也是 Claude Code、Codex 为什么「比同一个模型在聊天界面里强」的底层解释：差别不在模型，而在 harness 做的上下文管理与工具编排。
内容精讲
人们讨论 LLM 编程能力时，常把「模型」「推理行为」和「Agent 产品」混为一谈。实际上三者边界清晰，而理解这些边界，才能解释编码 Agent 的真实能力来源。
**分层先立住。** LLM 是核心的下一个 token 模型——原始的「引擎」。推理模型仍然是一个 LLM，但经过训练或提示，会在中间推理、验证、候选答案搜索上投入更多推理时计算——可以类比为「更强但也更贵的引擎」。Agent 是包在模型外的一层：一个控制循环，根据目标决定接下来检查什么、调用哪些工具、如何更新状态、何时停止。Agent harness 是这个循环周边的软件骨架：管理上下文、工具使用、提示、状态与控制流。coding harness 则是 Agent harness 在软件工程任务上的特化：管理代码上下文、工具、执行与迭代反馈。
**编码工作的本质不只生成 token。** 更直白的说法是：编程只有一部分是下一个 token 的生成。很大一部分是 repo 导航、搜索、函数查找、diff 应用、测试执行、错误检查，以及让所有相关信息留在上下文里——写过代码的人都知道这是艰难的心智劳动。所以 coding harness 存在的意义是：把「模型的输出」变成「仓库里的实际改动」，并验证它。一个 harness 的核心是一个 Agent 循环，其中四个动作反复运转：观察（从环境收集信息）、检查（分析信息）、选择（决定下一步）、行动（执行）。
**三层结构。** 一个 coding harness 把三层叠起来：模型家族提供「引擎」，Agent 循环驱动迭代式问题求解，运行时支撑提供「管道」（执行、文件系统、测试、网络等）。结论很重要：一个好的 coding harness 能让推理模型和非推理模型都表现得比在裸聊天框里强得多——因为它补上了上下文管理和迭代执行。
**六个构建块。** 以 Claude Code、Codex 这类工具为参照，编码 Agent 主要由六块组成：repo 上下文管理（把项目相关的代码与文档喂给模型）、工具设计（读/写/搜索/执行等原子操作）、提示缓存稳定性（长会话中保持提示一致性以省钱、减延迟）、记忆（跨会话保存偏好与结论）、长会话连续性（在很长的会话里维持状态）、以及执行与反馈回路（跑测试、读报错、修再试）。这六个块共同决定了 Agent 在真实仓库上的表现，也解释了为什么「同一个模型 + 好 harness」远强于「同一个模型 + 聊天框」。
**对模型能力评估的启示。** 当基准把「模型」与「harness」混在一起测评时，结果更多反映的是工具组合而非模型本身。真正的评估应该分层：单独测模型的下一个 token 能力，再测 harness 的上下文与工具管理，再测组合效果。对使用者来说，这意味着「换 harness」有时比「换模型」提升更明显——这也是 2026 年编码工具竞争最激烈的维度。
阅读价值
对 LLM 应用开发者，这篇文章把 agent、harness、coding harness 的概念谱系一次理清，六个构建块可直接用作搭建编码 Agent 的检查清单；对评估与选型者，它提示了「模型与 harness 混测」的评估陷阱，也解释了 Claude Code/Codex 能力来源的真实结构。
内容与图片版权归原作者所有 · 原文: https://magazine.sebastianraschka.com/p/components-of-a-coding-agent