Coding Agent的底层运行逻辑是什么？

在本文中我将探讨编码智能体coding agents及其智能体编排agent harnesses的整体设计它们究竟是什么、工作原理如何以及在实际应用中各组件是如何协同运作的。广泛地讲智能体之所以成为一个备受关注的重要议题是因为近期实用型大语言模型LLM系统所取得的诸多进展不仅仅归功于模型本身的性能提升更在于我们如何去运用这些模型。在许多实际应用场景中智能体周边的支撑系统 —— 例如工具调用、上下文管理及记忆机制 —— 所发挥的作用其重要性丝毫不亚于模型本身。这也解释了为何像 Claude Code 或 Codex 这类系统往往给人的感觉要比单纯在普通聊天界面中使用的同款基础模型显得更为强大、更具能力。在本文中我将详细阐述构成编码智能体的六大核心构建模块。Claude Code、Codex CLI 及其他编程智能体如果你是开发者的话你可能已经很熟悉 Claude Code 或 Codex CLI 了但为了铺垫背景不妨先说明一下它们本质上属于「智能体式」编程工具通过在应用层 —— 即所谓的「智能体编排」agentic harness—— 中对大型语言模型LLM进行封装从而使编程任务变得更加便捷且高效。图 1Claude Code CLI、Codex CLI 和我自建的代码智能体。编程智能体Coding agents专为软件开发工作而设计在这一领域关键要素不仅在于模型的选择更在于其周边的系统架构 —— 包括代码仓库的上下文环境、工具的设计、提示缓存的稳定性、记忆机制以及长会话的连续性。这种区分至关重要因为当我们探讨大型语言模型LLM的编程能力时人们往往会将模型本身、其推理行为以及作为产品的智能体混为一谈。不过在深入探讨编程智能体的具体细节之前请允许我先简要补充一些背景信息阐明「大型语言模型」、「推理模型」和「智能体」这三个更宏观概念之间的区别。大模型、推理模型与智能体的关系大型语言模型LLM本质上是一种核心的「预测下一个 token」的模型。而「推理模型」虽然仍属于 LLM 的范畴但通常经过了专门的训练和 / 或提示工程优化使其在推理过程中投入更多的计算资源用于执行中间步骤的逻辑推理、结果验证或在候选答案集合中进行搜索。智能体Agent则是一个构建在模型之上的抽象层可以将其理解为围绕核心模型运作的一个「控制回路」。通常情况下当接收到一个既定目标后智能体层或称「编排框架」会负责决策下一步需要检查哪些信息、应当调用哪些工具、如何更新自身的状态以及何时终止任务等一系列操作。粗略地讲我们可以用这样一个类比来理解它们之间的关系LLM 相当于引擎推理模型则相当于经过强化的引擎性能更强但运行成本也更高而智能体编排框架则扮演着辅助我们操控这一引擎的角色。尽管这个类比并不完美 —— 毕竟我们也可以将常规 LLM 和推理型 LLM 作为独立的模型直接使用例如在聊天界面或 Python 交互会话中—— 但我希望它能有效地传达出其中的核心要义。图 2传统大语言模型LLM、推理型大语言模型或推理模型以及封装在智能体编排框架中的大语言模型之间的关系。换句话说智能体就是一个在特定环境中反复调用模型的系统。因此简而言之我们可以将其归纳如下大型语言模型原始模型。推理模型一种经过优化的 LLM旨在输出中间推理过程痕迹并具备更强的自我验证能力。智能体一个循环执行的实体它结合使用了模型、工具、记忆模块以及环境反馈。智能体编排框架Agent Harness围绕智能体构建的软件支架负责管理上下文、工具调用、提示词、状态以及控制流。代码编排框架Coding Harness智能体框架的一种特例即专用于软件工程任务的框架负责管理代码上下文、工具、代码执行以及迭代反馈。如上所述在智能体和编码工具的语境下我们还会遇到两个流行术语智能体编排框架和智能体驱动的代码编排框架。后者是围绕模型构建的软件支架旨在辅助模型高效地编写和编辑代码。而智能体编排框架的范畴则更为广泛并不局限于代码领域例如可以参考 OpenClaw 项目。Codex 和 Claude Code 均可被视为代码编排框架的实例。总之更优秀的大模型能为推理模型通常需要经过额外的训练奠定更坚实的基础而智能体框架则能进一步挖掘并充分发挥该推理模型的潜能。诚然LLM 和推理模型本身也具备独立解决编码任务的能力即无需借助编排框架辅助但实际上编码工作远不止是单纯的「下一个 token 生成」Next-token generation。编码工作很大程度上还涉及代码仓库导航、搜索、函数查找、代码差异应用Diff、测试执行、错误排查以及在整个过程中维持所有相关信息的上下文连贯性。程序员们想必深知这是一项极耗心力的脑力劳动 —— 这也正是我们在专心编码时最不愿被打扰的原因所在 :图 3。一个编码编排框架由三个层级构成模型族、智能体循环以及运行时支持。其中模型充当「引擎」智能体循环驱动迭代式的问题求解过程而运行时支持则提供底层的「管道」基础设施。在循环内部「观察」环节从环境中收集信息「审视」环节对这些信息进行分析「决策」环节选定下一步行动最后由「执行」环节付诸实施。这里的关键要点在于一套优秀的「编码辅助框架」能让具备推理能力和不具备推理能力的模型在实际表现上显得比单纯置于普通聊天框中强大得多 —— 因为它有助于处理上下文管理等一系列关键任务。编码辅助编排框架正如上一节所提到的当我们提及「辅助编排框架」Harness时通常是指围绕在模型外部的那一层软件层。这一层负责组装提示词Prompts、调用外部工具、追踪文件状态、应用代码修改、执行终端命令、管理权限、缓存稳定前缀、存储记忆信息以及处理更多其他任务。如今在使用大模型时相比于直接向模型输入提示词或是使用简单的网页聊天界面后者更接近于「上传文件后进行对话」的模式正是这一层辅助框架塑造了用户体验的绝大部分。在我看来当前各类大模型的「原生版本」在能力上已趋于同质化例如GPT-5.4、Opus 4.6 和 GLM-5 等模型的原生版本之间因此这套辅助框架往往就成了决定某款大模型表现优于另一款的关键差异化因素。这纯属推测但我猜想如果我们把当前最新、能力最强的开源权重大型语言模型之一例如 GLM-5置入一套类似的辅助框架之中它的表现很可能就能与 Codex 环境下的 GPT-5.4或是 Claude Code 环境下的 Claude Opus 4.6 达到同一水平。话虽如此针对特定的辅助框架进行一些「后训练」通常还是有益的。举例来说OpenAI 历史上就曾针对 GPT-5.3 模型维护过两个不同的变体版本GPT-5.3 和 GPT-5.3-Codex。在下一节中我将深入探讨具体细节并以我开发的「Mini Coding Agent」项目为例GitHub 链接https://github.com/rasbt/mini-coding-agent来详细解析一套编码辅助框架的核心组成部分。图 4编码智能体 / 编码编排框架的主要特性将在后续章节中讨论。顺便一提为了行文简洁本文中「编码智能体」和「编码编排框架」这两个术语有时会互换使用。严格来说智能体是模型驱动的决策循环而框架是提供上下文、工具和执行支持的外部软件框架。图 5一个极简但功能完备、从零构建的「迷你编程智能体」纯 Python 实现。言归正传下方列出了编程智能体的六大核心组件。你可以查阅我所构建的那个极简但功能完备、从零构建的「迷你编程智能体」纯 Python 实现的源代码以获取更具体的代码示例。在该代码中我已通过注释对下文将要探讨的这六大组件进行了标注复制############################## #### Six Agent Components #### ############################## # 1) Live Repo Context - WorkspaceContext # 2) Prompt Shape And Cache Reuse - build_prefix, memory_text, prompt # 3) Structured Tools, Validation, And Permissions - build_tools, run_tool, validate_tool, approve, parse, path, tool_* # 4) Context Reduction And Output Management - clip, history_text # 5) Transcripts, Memory, And Resumption - SessionStore, record, note_tool, ask, reset # 6) Delegation And Bounded Subagents - tool_delegate1、实时代码库上下文这或许是最显而易见的组件但同时也是至关重要的组件之一。当用户发出「修复测试」或「实现 xyz 功能」之类的指令时模型应当能够识别当前是否处于 Git 代码库环境中正处于哪条分支上哪些项目文档可能包含相关指引诸如此类。之所以如此是因为这些细节往往会改变或影响模型应采取的正确行动。例如「修复测试」这一指令本身并非一条自足的指令。如果智能体能够查阅诸如 AGENTS.md 或项目 README 之类的文档它便能获知应当执行哪条测试命令等具体信息。若能知晓代码库的根目录位置及整体布局它便能直奔目标位置进行查找而非盲目猜测。此外Git 分支信息、当前状态及提交记录等数据也能提供更为丰富的上下文信息帮助智能体了解当前正在进行哪些变更以及应当将工作重心聚焦于何处。图 6智能体运行框架首先构建一份简要的「工作区摘要」随后将其与用户请求合并以此为项目提供额外的上下文信息。核心要点在于该编程代理在着手执行任何任务之前会预先收集相关信息即作为工作区摘要的「稳定事实」这样一来它就不必在处理每一个提示词Prompt时都从零开始陷入缺乏上下文的窘境。2、提示词结构与缓存复用一旦智能体获得了代码仓库的概览视图接下来的问题便是如何将这些信息有效地输入给语言模型上一幅图中展示了这一过程的简化视图即「组合提示词前缀 请求」但在实际操作中若针对用户的每一次查询都重新合并并处理一遍工作区摘要将是相对低效且浪费资源的做法。换言之编程会话往往具有重复性且智能体所遵循的规则通常保持不变。各类工具的功能描述通常也维持原样。甚至连工作区摘要的内容通常也在很大程度上保持稳定。真正发生变化的主要因素通常仅限于最新的用户请求、近期的交互对话记录以及可能涉及的短期记忆信息。如图下方所示「智能」运行时环境并不会在每一个交互回合中都将所有信息重新打包成一个庞大且未作区分的整体提示词。图 7智能体编排框架构建一个「稳定提示前缀」随后加入不断变化的会话状态并将合并后的完整提示输入给模型。与第 1 节的主要区别在于第 1 节侧重于收集代码仓库的相关事实信息而在本节中我们的重点是如何高效地封装并缓存这些事实以便在后续对模型进行反复调用时加以复用。所谓「稳定提示前缀」中的「稳定」意指其中包含的信息变动极小。它通常涵盖了通用指令、工具描述以及工作空间的概览信息。如果其中未发生任何实质性变化我们便不希望在每一次交互过程中都耗费计算资源将其从头重建。而其他组件的更新频率则要高得多通常是每一轮交互更新一次。这些组件包括短期记忆、近期的对话记录以及最新的用户请求。简而言之针对「稳定提示前缀」所实施的缓存机制其核心理念就在于通过智能的运行时环境尽可能地对这部分内容进行复用。3、工具访问与使用工具访问与使用环节让交互体验从聊天逐渐转变为智能体。普通模型可以生成文字形式的命令建议但编码框架中的大模型应该执行更精准、更有用的任务并能够实际执行命令并获取结果而不是让我们手动调用命令并将结果粘贴回聊天窗口。但编排框架通常不会让模型随意生成语法而是提供一个预定义的、包含明确输入和边界的可用工具列表。当然像 Python 的 subprocess.call 这样的工具也可以包含在内这样智能体就可以执行任意范围的 shell 命令。工具使用流程如下图所示。图 8模型发出一个结构化操作框架对其进行验证并可选择性地请求批准然后执行该操作并将有界结果反馈回循环。为了说明这一点以下示例展示了用户使用迷你编码智能体时通常看到的界面。由于它非常简洁并且使用纯 Python 编写没有任何外部依赖因此不如 Claude Code 或 Codex 那样美观。图 9Mini Coding Agent 中工具调用审批请求的示意图。在此环节中模型必须选择一个编排框架harness能够识别的动作例如列出文件、读取文件、执行搜索、运行 Shell 命令、写入文件等。同时它还必须以一种编排框架能够进行校验的格式提供相应的参数。因此当模型请求执行某项操作时运行时环境会暂停执行并运行一系列程序化检查例如「这是一个已知的工具吗」「提供的参数是否有效」「此操作是否需要用户的审批」「请求访问的路径是否位于工作区workspace范围之内」只有在通过了上述所有检查之后实际的操作指令才会被真正执行。诚然运行编码智能体确实伴随着一定的风险但得益于编排框架的这些检查机制系统的可靠性也得到了提升因为模型无法执行完全随意、不受控的指令。此外除了能够拒绝格式错误的动作请求并实施审批门控机制外通过对文件路径进行校验还可以确保文件访问操作始终被限制在代码仓库repo的范围之内。从某种意义上说编排框架虽然限制了模型的自由度却显著提升了其实用性。4、最小化上下文膨胀上下文膨胀并非编码智能体所独有的问题而是大模型普遍面临的一个难题。诚然如今的 LLM 已能支持越来越长的上下文窗口但长上下文依然成本高昂且若其中夹杂大量无关信息还可能引入额外的「噪声」。在多轮对话过程中编码智能体比普通 LLM 更易受上下文膨胀之苦 —— 这主要是由于频繁的文件读取、冗长的工具输出、系统日志等因素所致。如果运行时环境对上述所有信息都采取「全保真」的存储策略那么可用的上下文 Token 额度很快就会被耗尽。因此一套优秀的代码智能体编排框架Coding Harness通常会采取相当精妙的策略来应对上下文膨胀问题其处理手段远比普通聊天界面那种单纯的「截断」或「摘要」操作要复杂得多。从概念层面来看编码智能体中的「上下文压缩」机制大致可按下方图示所概括的流程运作。具体而言我们在此将视角进一步聚焦于上一节图 8 中所展示的「截取」Clip即第 6 步环节。图 10在重新送入提示词之前系统会对大篇幅的输出进行截断对较早的读取内容进行去重并对交互记录Transcript进行压缩。一个极简的编排框架至少会采用两种「紧凑化」策略来应对这一问题。第一种策略是「截断」Clipping即缩短冗长的文档片段、大型工具输出、内存笔记以及交互记录条目。换言之它能防止任何单段文本仅仅因为内容冗长就独占了大部分的提示词预算。第二种策略是「记录缩减」或「摘要化」即将完整的会话历史关于这一点下一节会有更详细的阐述转化为一段篇幅更小、更适合作为提示词输入的摘要。这里的关键技巧在于保留近期事件的更多细节因为它们往往与当前步骤的关联度更高而对于较早期的事件我们会采取更激进的压缩手段因为它们的相关性通常较低。此外我们还会对较早期的文件读取操作进行去重处理从而避免模型因同一文件在会话早期被反复读取而不得不一遍又一遍地重复接收相同的文件内容。总而言之我认为这正是优秀「编码智能体」设计中那些往往被低估、看似枯燥乏味的关键环节之一。许多表面上归功于「模型质量」的优异表现实际上恰恰源自于「上下文质量」的提升。5、结构化会话记忆在实践中此处涵盖的所有这 6 个核心概念都是高度交织在一起的不同的章节和图示会以不同的侧重点或粒度来阐述这些概念。在上一节中我们探讨了在提示阶段prompt-time如何利用历史信息以及如何构建一份紧凑的会话记录transcript。当时的核心问题是在下一轮交互中究竟应该将多少过往的历史信息回传给模型因此那一节的重点在于信息的压缩、截断、去重以及时效性。而本节 —— 即「结构化会话记忆」—— 所探讨的则是历史信息在存储阶段storage-time的内部结构。本节的核心问题在于作为智能体它应当随着时间的推移保留哪些信息并将其作为永久性的记录因此本节的重点在于运行时环境应维护一份更为完整的会话记录作为「持久化状态」与此同时它还应维护一个更为轻量级的「记忆层」—— 该记忆层体积较小且其内容会经历修改与压缩处理而非仅仅进行简单的追加。综上所述一个编程智能体会将其状态拆分为至少两个层级工作记忆Working Memory即智能体显式维护的一份经过高度提炼、体积较小的状态信息。完整会话记录Full Transcript这份记录涵盖了所有的用户请求、工具输出结果以及大模型的响应内容。图 11新事件会被追加到「完整对话记录」中并被归纳总结至「工作记忆」里。磁盘上的会话文件通常以 JSON 格式存储。上图展示了两个主要的会话文件 ——「完整对话记录」和「工作记忆」—— 它们通常以 JSON 文件的形式存储在硬盘上。正如前文所述「完整对话记录」保存了完整的历史信息即使智能体程序被关闭该记录也能支持后续的会话恢复。「工作记忆」则更像是一个经过提炼的精简版本其中包含了当前最重要的信息这一点在功能上与「精简对话记录」有着一定的关联。不过「精简对话记录」与「工作记忆」各自承担的职责略有不同。「精简对话记录」主要用于提示词的重构。其作用是向模型提供近期历史信息的压缩视图从而使模型无需在每一轮对话中都查阅完整的对话记录便能顺畅地延续对话。「工作记忆」则更侧重于保障任务的连续性。其作用是维护一份小巧且经过显式管理的摘要专门用于记录跨轮次对话中那些至关重要的信息例如当前正在执行的任务、重要的相关文件以及近期的备忘记录等。参照上图中的第 4 步在随后的下一轮对话中为避免上图显得过于繁杂该轮次并未在图中展示最新的用户请求 —— 连同大模型的响应及工具的输出 —— 将被作为一条「新事件」同时记录并追加到「完整对话记录」与「工作记忆」之中。6、使用有界子智能体进行任务委托一旦智能体拥有了工具和状态下一个有用的功能之一就是任务委托。原因在于它允许我们通过子智能体将某些工作并行化为子任务从而加速主任务的执行。例如主智能体可能正在执行某个任务但仍然需要一些辅助信息例如哪个文件定义了某个符号、某个配置的含义是什么或者某个测试失败的原因。将这些信息拆分成一个有界子任务会很有用而不是强制一个循环同时处理所有线程的工作。在我的迷你编码代理中实现更简单子智能体仍然同步运行但基本思想是相同的。子智能体只有在继承足够的上下文来执行实际工作时才有用。但如果我们不加以限制就会出现多个智能体重复工作、访问相同文件或生成更多子智能体等问题。所以棘手的设计问题不仅在于如何生成子智能体还在于如何绑定子智能体。图 12子智能体继承了足以使其发挥作用的上下文但其运行边界比主智能体更为严格。这里的关键在于子智能体既继承了足够的上下文以确保其有效性同时也受到了一定的限制例如被设定为只读模式且递归深度受到限制。Claude Code 早在很久以前便已支持子智能体功能而 Codex 则是近期才引入这一特性的。通常情况下Codex 并不会强制将子智能体设定为只读模式相反它们往往会继承主智能体的大部分沙箱环境与审批配置。因此这里的「边界」更多是指任务的范围界定、上下文环境以及执行深度等方面的限制。总结上一节旨在概述编码智能体系统的主要组成部分。正如前文所述从实现层面来看这些组件之间或多或少都存在着深度交织与耦合。不过我仍希望通过逐一剖析这些组件的方式能有助于读者构建起一套关于编码智能体编排框架运作机制的整体心智模型并理解为何相比于简单的多轮对话模式代码智能体能够显著提升大语言模型的实用价值。图 13前文讨论过的编码编排框架Coding Harness的六大主要特征。如果你有兴趣看到这些特征是如何通过简洁、极简风格的 Python 代码实现的不妨看看「Mini Coding Agent」。它与 OpenClaw 相比有何不同OpenClaw 确实是一个值得拿来对比的有趣案例但它与本文所探讨的系统并非完全属于同一类型。OpenClaw 更像是一个运行于本地的通用型智能体平台 —— 尽管它也具备编码能力 —— 而非一款专精于终端环境下的编码辅助工具。不过它与编码辅助框架之间仍存在诸多重叠之处它会在工作区内利用提示词和指令文件例如 AGENTS.md、SOUL.md 和 TOOLS.md它会保存 JSONL 格式的会话记录文件并具备会话记录压缩与会话管理功能它能够衍生出辅助会话及子智能体等等。然而正如上文所述两者的侧重点截然不同。编码智能体的设计初衷是为了优化个人开发者在代码仓库中工作时的体验 —— 即高效地指挥辅助工具去检查文件、修改代码并执行本地工具。相比之下OpenClaw 的设计重心则在于跨聊天窗口、频道及工作区运行大量「长生命周期」的本地智能体而编码工作仅仅是其众多重要任务负载之一。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。