模型差距缩小，Harness 差距拉大！Coding Agent 工程化落地全攻略（非常硬核），收藏这一篇就够了！

Sebastian 做的事不太一样——他把这些散落的问题重新收回到一张总图里。他关心的问题是为什么同样是强模型进了 Codex、Claude Code 之后做代码任务会显得更像一个能协作的同事。答案说出来其实很朴素。不是因为聊天框里的模型突然不行了。而是因为真实可用的 Coding Agent外面多了一整层系统。这层系统原文叫Harness。可以把它理解成把模型接进真实工程世界的协作系统。Coding Agent 协作系统图太长不看版• Coding Agent 不是“会写代码的聊天机器人”它更像模型 控制循环 运行时系统的组合。• LLM、推理模型、Agent、Harness 不是一个东西。很多讨论之所以混乱就是把这几层混在了一起。• Sebastian 把 Coding Agent 拆成了 6 个核心组件Repo Context、提示词形态与缓存、结构化工具、上下文管理、会话记忆、子智能体委托。• 这 6 个组件里最容易被低估的往往是上下文压缩和工作记忆。它们不显眼但很影响长任务稳定性• 结合最近一批 Agent 实践来看一个感觉会更明显很多体感差距不只来自模型本身也来自系统能不能把任务稳稳带下去。先把几个词放回原位文章开头先做了一件我觉得很有必要的事把LLM、Reasoning Model、Agent、Harness这几层拆开。•LLM是最底层的引擎。核心能力还是预测下一个 token。•Reasoning Model还是 LLM只是它更愿意花 test-time compute多做一点推理、搜索和自我校验。•Agent是围绕模型运转的控制循环。你给它一个目标它决定下一步看什么、做什么、什么时候停。•Harness是包在外面的工程系统。负责上下文、工具、状态、权限、执行和恢复。这个区分其实很关键。因为我们太容易说一句“这个模型写代码很强”了但真实情况通常更复杂。你在聊天框里看到的是模型裸输出。你在 Codex、Claude Code 里看到的是模型加上一整套外围工程。所以很多时候“同款模型”进了不同产品体感会像换了一套工作方式。如果再口语一点大概是这样•LLM像一个会写代码、会解释问题的人•Agent Loop像他处理任务时的工作节奏•Harness像团队给他配的工位、规范、工具链、权限和验收机制只给一个很能干的人不给仓库上下文不告诉他规则不接测试和日志他也能写点东西。但很难稳定协作。图 1从模型到 Harness能力是怎么一层层叠起来的为什么聊天框里的同款模型没有那么能打有一个意思我觉得很值得留意。真实的软件开发只有一部分是在“生成下一段代码”。更多精力其实花在这些地方• 仓库导航• 搜索文档• 查找函数和文件• 应用 diff• 运行测试• 检查报错• 维持上下文连续性这些事人类工程师很熟。所以我们常觉得“写代码很累”不完全是因为要想算法。还有很多很碎、很脏、但绕不过去的脑力劳动。说到底其实不复杂一个好的 Coding Harness会把这些脏活累活接过去。所以同一个模型放在普通聊天界面里和放在一个做过上下文管理、工具编排、状态恢复的系统里表现很难一样。原文里有一个带点推测的判断挺有意思的如果把今天最强的开源模型比如 GLM-5放进跟 Codex 或 Claude Code 同等成熟的 Harness 里最终体验未必会跟 GPT-5.4 或 Opus 4.6 差得特别夸张。Sebastian 也提到OpenAI 一直有专门的 Codex 变体做过针对性训练但大框架上Harness 的工程质量可能比模型选型更决定体感。当然这个判断未必能一概而论。但方向大体没问题——这几年不少真实进步确实发生在模型外面的系统层。一个 Coding Agent不只是模型外面包了一层壳一个 Coding Harness通常是三层叠起来的模型层提供“引擎”Agent 循环在循环中不断地观察observe→ 检查inspect→ 选择choose→ 执行act运行时支撑提供上下文、工具、状态、权限、反馈模型、循环和运行时系统不是一个层面的东西。如果只看这三层会发现一个挺有意思的点真正变化快的常常不是那个最小的循环。很多系统的主循环其实都差不多。更容易拉开差距的往往是循环外面越来越厚的那层工程设施• 仓库事实怎么收• 状态怎么存• 工具怎么卡边界• 测试和日志怎么回流• 长上下文怎么压缩• 子智能体怎么约束也就是说Harness不是给模型套上的一层外壳。它更像一套把模型接进工程协作的工作系统。顺着 Claude Code 的源码往里看时这种感觉会更强。启动怎么做预热Prompt 怎么装配权限怎么介入长任务怎么做 compact 和 memory——看起来像是几条散线其实都能落回同一组问题。图 2一次典型 Coding Agent 任务通常是怎么跑起来的六个组件决定它是不是一个能协作的 Coding Agent原文用一个纯 Python 写的Mini Coding Agent做例子把这层系统拆成了 6 个模块。我觉得这个拆法很适合对照自己的实现看。先放一张简表。组件它解决什么问题更像团队里的什么Live Repo Context避免模型盲启动入组先读项目和规则Prompt Shape Cache稳定前缀和动态信息分层长期规则和当前任务分开Structured Tools工具调用可验证、可约束受控工具链和权限系统Context Management避免上下文膨胀只保留当下真正相关的信息Session Memory长任务不断线会议纪要 当前行动清单Delegation Subagents支线任务拆分有边界的协作分工下面逐个看。1. Live Repo Context先拿稳定事实再开始推理用户说一句“修一下测试”对模型来说远远不够。它得先知道• 当前是不是 Git 仓库• 现在在哪个分支• 目录结构长什么样•README或AGENTS.md里有没有规则• 哪些脚本才是标准入口核心就一个意思模型不能两眼一抹黑地开工。如果它能看到AGENTS.md就更可能知道应该跑哪条测试命令。如果它知道仓库根目录和文件结构就更可能去对的地方找代码而不是瞎猜。就像新同事入组第一天——先看项目文档先摸清目录先知道团队怎么做事。不是一坐下就开始改文件。一个成熟一点的 Agent通常会先把这些稳定事实收集出来整理成一个工作区摘要每轮任务都带着它出发。看起来不花哨。但它经常决定后面是不是一路都在猜。2. Prompt Shape Cache Reuse稳定的东西要稳定下来Agent 摸清仓库之后下一个问题是怎么把这些信息喂给模型。一个不太聪明的做法是每轮都把整份上下文重新拼一遍再让模型从头读一遍。这样当然也能跑。但很浪费。因为写代码是一个反复拉扯的过程。在这个过程中• 系统指令通常不变• 工具定义通常不变• 仓库摘要大多数时间也基本不变真正高频变化的其实是• 用户最新请求• 最近几轮对话• 刚返回的工具结果• 短期工作记忆所以更好的做法是把提示词拆成两部分•稳定前缀系统指令、工具定义、工作区摘要•动态部分当前请求、近期历史、短期记忆这样做有两个现实好处。一是更容易命中成本更低速度更稳。二是结构更清楚长任务里也更不容易漂。放到团队协作里也一样。长期规则和你今天手头这个 bug本来就不该揉在一起。前者决定边界。后者决定当前动作。3. Structured Tools真正危险的不是工具少而是边界不清很多人会把“会不会调工具”理解成模型能力。但工具层的大头其实在 Harness。模型能做的只是输出一个结构化动作。真正让这个动作安全、可控、能落地的是外层系统继续做的几件事• 校验参数• 检查路径• 判断是否需要批准• 执行动作• 把受控结果再喂回循环流程其实很清楚模型先输出动作 → Harness 验证 → 必要时请求人工批准 → 执行 → 结果传回系统。所以工具设计里最重要的判断可能不是“多不多”。而是• 是不是白名单• 描述是不是清楚• 输入是不是可验证• 出错时能不能明确失败• 路径和权限有没有边界最近很多 Agent 实践也在说同一件事如果工具设计不对模型选错工具时你表面上以为是模型笨实际上常常是工具本身不适合模型来用。一个能在错误方向上高速乱跑的 Agent通常比一个稍慢一点、但动作受控的 Agent 更危险。4. Context Management长任务的真正难点很多时候不是推理是别吃撑这一节讲的不是“更聪明”而是“别失真”。写代码这种任务天生会制造大量脏上下文• 文件很多• 日志很长• 工具输出很臭很长• 同一个文件会被反复读取• 历史对话会不断累积如果 Harness 老老实实把这些东西一股脑全塞回去上下文窗口很快就满了。所以一个好的 Coding Agent核心能力之一其实是“会忘”。至少有三种常见的压缩动作•Clipping超长输出直接截断•Transcript reduction / summarization把完整历史压成更轻的近期摘要•Deduplication早先读过的重复文件别一遍遍喂这里还有一个原则也很实用近的事保留更多细节。远的事压得更狠。因为离当前决策越近通常越重要。这一段看起来很像脏工程很少拿来当卖点。但 Sebastian 有句话说得好很多表面上的“模型质量”其实是上下文质量。很多系统最终稳不稳真的就死在这里。5. Session Memory完整记录和工作记忆不是一回事Coding Agent 至少应该有两层状态•Full Transcript完整记录。保存所有用户请求、工具输出和模型回复。目标是可恢复、可审计。•Working Memory工作记忆。只保留当下任务最需要的精炼状态。目标是让任务不断线。这个区分很重要。因为很多人会把“压缩后的近期历史”和“工作记忆”混在一起。但两者不是一回事。• 压缩后的对话是为了重建提示词• 工作记忆是为了维护任务连续性前者更像近期上下文的浓缩包。后者更像一份手动维护的小备忘录。里面可能只有这些信息• 当前最重要的任务是什么• 哪些文件最关键• 最近做过什么• 还有哪些待办没收尾这层设计在长任务里特别有用。因为很多时候模型不是突然变笨了。而是系统没有把“完整历史”和“当前重点”分开。图 3完整记录和工作记忆各自服务什么6. Delegation Subagents子智能体不是越多越好关键是怎么绑住当 Agent 有了工具也有了状态下一步很自然就会想到委托。主智能体正在干主线任务时常常会冒出来一些适合拆出去的支线问题• 这个符号在哪个文件定义• 这个测试为什么挂• 这个配置到底写了什么这种时候子智能体就很有价值。它能把辅助问题剥离出去减轻主循环负担。也能在理想情况下做并行。但子智能体最危险的地方有两个• 给它的上下文不够它出去一趟什么也做不了• 给它的边界太松它回来前已经把系统搞乱了所以真正难的不是“会不会 spawn subagent”。而是• 给它多少上下文才够• 它能不能写文件• 能不能继续往下再生子智能体• 它和主智能体是不是会重复劳动• 它的任务范围是不是足够清楚还有一个有意思的现实细节。Claude Code 很早就支持子智能体。Codex 是后来补上的。而 Codex 通常也不是一刀切地强制子智能体只读。更多时候它们会继承主智能体的大部分沙箱和批准设置。也就是说边界不一定只靠“只读”来做。很多时候更依赖任务范围、上下文大小和深度控制。不只是列了 6 个点如果只当成一份“组件综述”来读有点可惜。更值得留意的是一个这段时间越来越明显的感觉被说得更清楚了很多时候真正拉开体感的不只是“模型会不会回答”还有“系统能不能带着模型把任务走对”。最近不少 Agent 实践也在印证同一个方向。不是每个问题都要上更复杂的 Agent。很多时候先把任务推到“目标清楚、反馈可验证”的区域系统就会稳很多。换个角度看很多团队后来卡住的也不一定是想法不够。更常见的情况是任务还没有被翻译成系统真能执行的结构。放到 Coding Agent 上其实是同一个问题的工程版• 仓库事实有没有翻清楚• 规则有没有翻清楚• 工具边界有没有翻清楚• 完成标准有没有翻清楚这些东西一旦没翻好模型再强也还是容易各干各的。所以现在越来越容易把 Harness 看成一套协作系统。它不只是给模型加工具。它是在替模型补上这些东西• 共享事实• 共享规则• 共享状态• 错误反馈• 验收标准• 分工边界这几样凑在一起Agent 才比较像“同事”。对照自己的系统可以先看什么如果顺着一个比较现实的排查顺序往下看通常可以先看这几件事模型是不是在零上下文里盲启动长期规则和当前请求是不是混在一起工具是不是太多、太散、描述太工程师视角日志和历史是不是在吞掉注意力工作记忆和完整记录是不是混成一坨子智能体是不是已经比主智能体还难控如果这些地方有明显问题可能不必急着上更多 Agent。先把单 Agent 的协作基础设施补稳通常更划算。因为单个 Agent 如果连规则、上下文、工具、记忆和验证都还没站稳多开几个往往不是在提效更像是把混乱并行化了。不是说多 Agent 没价值。只是很多系统还没到那一步。它和 OpenClaw 像吗像但不完全是一类东西Sebastian 在结尾还提了一下 OpenClaw这个对比挺有意思。大致的看法是• Coding Harness 更像终端里的专用编码助手• OpenClaw 更像本地通用智能体平台编码只是其中一种工作负载两者也确实有不少重叠• 都会利用工作区里的指令文件比如AGENTS.md• 都会保留会话文件• 都会做记录压缩和状态管理• 都支持辅助会话或子智能体但它们的优化方向并不一样。Coding Agent 更关心的是怎么在仓库里高效地读文件、改代码、跑工具、接反馈。OpenClaw 更关心的是怎么在多个聊天、频道、工作区里养长期运行的本地智能体。这个边界值得留意。我们现在聊 Agent很容易一股脑都叫 Agent但产品目标不同最后补的系统层也会很不一样。如果还想往实现层多走一步这两天刷到一个可视化的Claude Code源码分析地图把运行时流程、权限治理、记忆系统、Coordinator、MCP 这些线索都用可视化的方式表现了出来方便理解和进一步的研究可以对比来看。Claude Code 源码分析地图 : https://code.claudecn.com跟 Sebastian 写的内容更像前后两步先把Harness的大框架立住再回头看Claude Code的具体实现很多原本零散的模块就比较容易找到位置了。如果最近正好也在看Claude Code代码或者想自己搭一套 Agent runtime先有总体框架视觉再回去看实现通常会省力一些。写在最后读完之后一个很直接的感受“Coding Agent 为什么强”这件事被从模糊的产品印象重新落回了一组能实现、能拆分、也能检查的工程问题。这个收束本身就挺有价值的。因为最近围绕 Agent 的讨论太多了——讲模型的、讲工作流的、讲工具的、讲多智能体的。Sebastian 做的是把这些东西收到一条主线上模型还是重要的。只是任务一旦进入真实仓库很多差距会慢慢转移到模型外面的那套系统工程。如果最近也在看 Codex、Claude Code、OpenClaw、Cursor 这些产品或许可以拿来当一张对照表看看自己缺的到底是更强一点的模型还是一套还没补齐的 Harness。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】