编码智能体的核心组件——编码智能体如何借助工具、记忆与仓库上下文，让大语言模型在实际应用中更高效
Sebastian Raschka 博士 2026年4月4日
本文将讲解编码智能体与智能体框架的整体设计：它们是什么、如何工作，以及各模块在实际中如何协同。读过我《从零构建大语言模型》《从零构建推理模型》两本书的读者经常问到智能体相关问题，因此我整理了这份可直接参考的说明。
总体而言，智能体之所以成为重要议题，是因为当下大语言模型实用系统的进步，不只在于模型本身更强，更在于我们如何使用模型。在许多真实场景中，模型外围的系统——如工具调用、上下文管理、记忆机制——与模型本身同等重要。这也解释了为何 Claude Code、Codex 这类系统，会比在普通聊天界面中使用同款模型显得能力强得多。
本文将拆解编码智能体的六大核心组件。
Claude Code、Codex CLI 与其他编码智能体
你大概率熟悉 Claude Code 或 Codex CLI，简单来说，它们本质是智能体式编码工具：在大语言模型外层封装一层应用层（即智能体框架），让编码任务更便捷、性能更优。
编码智能体专为软件工程场景设计，其关键不只在于模型选择，更在于外围系统：仓库上下文、工具设计、提示词缓存稳定性、记忆能力、长会话连续性。
这个区分很重要，因为人们谈论大语言模型的编码能力时，常把模型、推理行为、智能体产品混为一谈。在展开编码智能体细节前，我先简要说明几个更宽泛概念的区别：大语言模型、推理模型与智能体。
大语言模型、推理模型与智能体的关系
- 大语言模型（LLM）：核心的下一个词预测模型。
- 推理模型：仍属于大语言模型，但通常经过训练或提示词优化，在推理阶段投入更多计算，用于中间推理、结果验证或候选答案检索。
- 智能体：模型之上的控制层，可理解为包裹模型的控制循环。给定目标后，智能体层（框架）决定下一步检查什么、调用什么工具、如何更新状态、何时停止等。
可以简单类比：
- 大语言模型是发动机
- 推理模型是强化版发动机（性能更强，但使用成本更高）
- 智能体框架则是让发动机高效运转的控制系统
这个比喻不算完美，因为常规大语言模型与推理大语言模型也可独立使用（在聊天界面或 Python 环境中），但足以说明核心逻辑。
换句话说：智能体是在环境中反复调用模型的系统。
精简总结：
- 大语言模型：原始模型
- 推理模型：优化输出中间推理过程、具备更强自我验证能力的大语言模型
- 智能体：结合模型、工具、记忆与环境反馈的循环系统
- 智能体框架：智能体外层的软件脚手架，管理上下文、工具调用、提示词、状态与控制流
- 编码框架：智能体框架的特例，面向软件工程的专用框架，管理代码上下文、工具、执行与迭代反馈
更好的大语言模型为推理模型（需额外训练）提供更好基础，而框架能进一步挖掘推理模型的潜力。
当然，大语言模型与推理模型也能独立完成编码任务（无需框架），但编码工作不只是生成下一个词，大量工作涉及仓库导航、检索、函数查找、差异应用、测试执行、错误排查，并把所有相关信息保持在上下文中。
编码框架
前文提到，框架指模型外层的软件层，负责组装提示词、开放工具、追踪文件状态、执行编辑、运行命令、管理权限、缓存稳定前缀、存储记忆等。
如今使用大语言模型时，相比直接提示模型或使用网页聊天界面（更接近“上传文件聊天”），这一层直接决定了大部分用户体验。
在我看来，当下主流大语言模型的基础能力已非常接近（如 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-Codex 两个版本。
接下来，我将结合自己实现的迷你编码智能体（https://github.com/rasbt/mini-coding-agent），详细讲解编码框架的核心组件。
编码智能体的六大组件
为简化表述，本文中编码智能体与编码框架可互换使用（严格来说，智能体是模型驱动的决策循环，框架是提供上下文、工具与执行支持的外围软件脚手架）。
下图是纯 Python 实现、最小可用且从零搭建的迷你编码智能体：
以下是六大组件的详细说明，迷你编码智能体源码中已用注释标注对应模块：
##############################
#### 六大智能体组件 ####
##############################
# 1) 实时仓库上下文 -> WorkspaceContext
# 2) 提示词结构与缓存复用 -> build_prefix, memory_text, prompt
# 3) 结构化工具、验证与权限 -> build_tools, run_tool, validate_tool, approve, parse, path, tool_*
# 4) 上下文压缩与输出管理 -> clip, history_text
# 5) 会话记录、记忆与恢复 -> SessionStore, record, note_tool, ask, reset
# 6) 任务委派与受限子智能体 -> tool_delegate
1. 实时仓库上下文
这是最直观、也最重要的组件。
当用户说“修复测试”“实现某个功能”时，模型需要知道：
- 是否在 Git 仓库中
- 当前所在分支
- 哪些项目文档包含说明
这些细节直接影响正确操作。例如“修复测试”不是自包含指令，若智能体能读取 AGENTS.md 或 README，就能知道该运行什么测试命令；知晓仓库根目录与结构，就能精准查找而非猜测。
Git 分支、状态、提交记录也能提供变更进度与聚焦方向。
核心价值：编码智能体在工作前先收集信息（生成工作区摘要的“稳定事实”），避免每次提示都从零开始、缺乏上下文。
2. 提示词结构与缓存复用
获取仓库视图后，下一步是如何高效把信息喂给模型。前文简化为“前缀+请求”的组合提示，但实际中每次都重新处理工作区摘要非常浪费计算。
编码会话具有重复性：
- 智能体规则基本不变
- 工具描述基本不变
- 工作区摘要大多不变
- 仅最新用户请求、近期对话、短期记忆会频繁变化
“智能”运行时不会每次都把所有内容拼成一个巨大无区分的提示词。
- 稳定提示词前缀：包含通用指令、工具描述、工作区摘要，信息变动小，可缓存复用，避免重复计算。
- 动态部分：短期记忆、近期对话、最新用户请求，每轮交互都会更新。
核心价值：对稳定前缀做缓存，大幅降低重复计算，提升响应速度。
3. 工具访问与使用
工具调用是让系统从“聊天”变成“智能体”的关键。
- 普通模型只能用文字建议命令
- 编码框架中的大语言模型可实际执行命令并获取结果，无需用户手动复制粘贴
框架会提供预定义、可命名、边界清晰的工具列表，而非让模型随意生成语法（也可通过 Python subprocess.call 执行任意 shell 命令）。
工具调用流程：
- 输入组装好的提示词
- 模型输出结构化工具调用
- 框架验证工具与参数
- 可选用户审批
- 裁剪工具输出（仅保留关键信息）
- 执行工具并将结果回流到循环
迷你编码智能体的工具调用审批示例：
模型必须选择框架可识别的操作（如列出文件、读取文件、搜索、执行 shell 命令、写入文件等），并按框架可校验的格式传入参数。
框架会做程序化检查：
- 是否为已知工具？
- 参数是否合法？
- 是否需要用户审批？
- 请求路径是否在工作区内？
检查通过后才会实际执行。
核心价值：降低风险、提升可靠性，限制模型随意执行命令，同时把文件访问限制在仓库内，减少自由度但提升可用性。
4. 抑制上下文膨胀
上下文膨胀不是编码智能体独有的问题，而是大语言模型的通用问题。即便现在大语言模型支持更长上下文，长上下文依然计算成本高，且易引入无关噪声。
编码智能体在多轮对话中更容易出现上下文膨胀：反复读取文件、冗长工具输出、日志等。
若运行时完整保留所有信息，很快会耗尽上下文令牌。优秀的编码框架会用更精细的方式处理，而非简单截断或摘要。
上下文压缩策略：
- 裁剪：缩短长文本片段、大工具输出、记忆笔记、对话记录，避免单段内容占满提示词配额。
- 对话压缩/摘要：将会话历史转为更小的可提示摘要。
- 非对称细节保留：近期事件保留更丰富信息，早期事件更激进压缩。
- 去重：对早期文件读取去重，避免模型重复看到相同内容。
核心价值：这是编码智能体设计中被低估的关键环节，很多看似“模型质量”的差异，本质是上下文质量的差异。
5. 结构化会话记忆
前文聚焦提示时的历史使用与紧凑对话构建，侧重压缩、裁剪、去重、时效性。
本节结构化会话记忆关注历史的存储结构：智能体长期保留哪些永久记录，侧重持久状态存储。
编码智能体至少把状态分为两层：
- 工作记忆：精简的显式状态，用于任务延续，记录当前任务、重要文件、关键笔记。
- 完整对话记录：保存所有用户请求、工具输出、模型响应，可持久化到磁盘（通常为 JSON 文件），支持会话恢复。
- 紧凑对话：用于重建提示，给模型压缩后的近期历史，无需每次都看完整记录。
- 工作记忆：用于任务延续，维护跨轮次的关键信息摘要。
新事件会同时追加到完整对话记录与工作记忆中。
6. （受限）子智能体委派
智能体具备工具与状态后，下一个关键能力是任务委派。
委派可把任务拆分为子任务交给子智能体并行处理，加速主任务。例如主智能体处理核心任务时，可把子问题（如符号定义文件、配置内容、测试失败原因）交给子智能体，避免单循环承载所有任务线程。
（迷你编码智能体实现更简单，子智能体同步运行，但核心思想一致。）
子智能体的设计难点：
- 需继承足够上下文才能完成工作
- 必须加限制，避免多智能体重复工作、修改同一文件、无限衍生子智能体
设计技巧：子智能体继承必要上下文，但在更严格的边界内运行（如只读、限制递归深度）。
Claude Code 很早就支持子智能体，Codex 近期也加入。Codex 不强制子智能体只读，而是继承主智能体的沙箱与审批配置，边界更多体现在任务范围、上下文、深度上。
组件总结
以上六大组件在实现中高度交织，逐一讲解有助于建立编码框架的完整心智模型，理解为何它能让大语言模型比普通多轮聊天更实用。
与 OpenClaw 的对比
OpenClaw 是有趣的参照，但并非同类系统。
- OpenClaw：本地通用智能体平台，编码只是其能力之一。
- 编码智能体：专为仓库内编码场景优化，高效完成文件检查、代码编辑、本地工具运行。
两者重合点：
- 使用工作区中的提示词与指令文件（AGENTS.md、SOUL.md、TOOLS.md）
- 存储 JSONL 会话文件，支持对话压缩与会话管理
- 可创建辅助会话与子智能体
核心差异：编码智能体聚焦编码效率，OpenClaw 聚焦多场景、长生命周期本地智能体管理。
新书预告
我已完成《从零构建推理模型》全书写作，目前进入抢先阅读阶段，出版社正在排版，预计今年夏天正式发售。
这是我最具野心的作品，耗时1年半完成，包含大量实验打磨。
核心内容：
- 推理模型评估
- 推理时扩展
- 自我优化
- 强化学习
- 知识蒸馏
理解大语言模型中“推理”的最好方式，就是从零实现一个推理模型！