---
layout: single
title:  "编码智能体的核心组件"
date:   2026-04-22 08:00:00 +0800
categories: [AI 与大模型, 操作系统]
tags: [智能体, 编码智能体, LLM]
---

编码智能体的核心组件——编码智能体如何借助工具、记忆与仓库上下文，让大语言模型在实际应用中更高效

**Sebastian Raschka 博士**
2026年4月4日

本文将讲解编码智能体与智能体框架的整体设计：它们是什么、如何工作，以及各模块在实际中如何协同。读过我《从零构建大语言模型》《从零构建推理模型》两本书的读者经常问到智能体相关问题，因此我整理了这份可直接参考的说明。

总体而言，智能体之所以成为重要议题，是因为当下大语言模型实用系统的进步，**不只在于模型本身更强，更在于我们如何使用模型**。在许多真实场景中，模型外围的系统——如工具调用、上下文管理、记忆机制——与模型本身同等重要。这也解释了为何 Claude Code、Codex 这类系统，会比在普通聊天界面中使用同款模型显得能力强得多。

本文将拆解编码智能体的**六大核心组件**。

---

## Claude Code、Codex CLI 与其他编码智能体
你大概率熟悉 Claude Code 或 Codex CLI，简单来说，它们本质是**智能体式编码工具**：在大语言模型外层封装一层应用层（即智能体框架），让编码任务更便捷、性能更优。

![图1：Claude Code CLI、Codex CLI 与作者的迷你编码智能体](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-1)

编码智能体专为软件工程场景设计，其关键不只在于模型选择，更在于外围系统：仓库上下文、工具设计、提示词缓存稳定性、记忆能力、长会话连续性。

这个区分很重要，因为人们谈论大语言模型的编码能力时，常把**模型、推理行为、智能体产品**混为一谈。在展开编码智能体细节前，我先简要说明几个更宽泛概念的区别：大语言模型、推理模型与智能体。

---

## 大语言模型、推理模型与智能体的关系
- **大语言模型（LLM）**：核心的下一个词预测模型。
- **推理模型**：仍属于大语言模型，但通常经过训练或提示词优化，在推理阶段投入更多计算，用于中间推理、结果验证或候选答案检索。
- **智能体**：模型之上的控制层，可理解为包裹模型的**控制循环**。给定目标后，智能体层（框架）决定下一步检查什么、调用什么工具、如何更新状态、何时停止等。

可以简单类比：
- 大语言模型是**发动机**
- 推理模型是**强化版发动机**（性能更强，但使用成本更高）
- 智能体框架则是**让发动机高效运转的控制系统**

这个比喻不算完美，因为常规大语言模型与推理大语言模型也可独立使用（在聊天界面或 Python 环境中），但足以说明核心逻辑。

换句话说：**智能体是在环境中反复调用模型的系统**。

精简总结：
- **大语言模型**：原始模型
- **推理模型**：优化输出中间推理过程、具备更强自我验证能力的大语言模型
- **智能体**：结合模型、工具、记忆与环境反馈的循环系统
- **智能体框架**：智能体外层的软件脚手架，管理上下文、工具调用、提示词、状态与控制流
- **编码框架**：智能体框架的特例，面向软件工程的专用框架，管理代码上下文、工具、执行与迭代反馈

更好的大语言模型为推理模型（需额外训练）提供更好基础，而框架能进一步挖掘推理模型的潜力。

当然，大语言模型与推理模型也能独立完成编码任务（无需框架），但编码工作不只是生成下一个词，大量工作涉及**仓库导航、检索、函数查找、差异应用、测试执行、错误排查**，并把所有相关信息保持在上下文中。

![图2：常规大语言模型、推理大语言模型与封装在智能体框架中的大语言模型的关系](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-2)

---

## 编码框架
前文提到，**框架**指模型外层的软件层，负责组装提示词、开放工具、追踪文件状态、执行编辑、运行命令、管理权限、缓存稳定前缀、存储记忆等。

如今使用大语言模型时，相比直接提示模型或使用网页聊天界面（更接近“上传文件聊天”），**这一层直接决定了大部分用户体验**。

在我看来，当下主流大语言模型的基础能力已非常接近（如 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），详细讲解编码框架的核心组件。

![图3：编码框架由三层组成：模型家族、智能体循环、运行时支持](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-3)

---

## 编码智能体的六大组件
为简化表述，本文中**编码智能体**与**编码框架**可互换使用（严格来说，智能体是模型驱动的决策循环，框架是提供上下文、工具与执行支持的外围软件脚手架）。

![图4：编码智能体/框架的六大核心功能](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-4)

下图是纯 Python 实现、最小可用且从零搭建的迷你编码智能体：

![图5：迷你编码智能体运行界面](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-5)

以下是六大组件的详细说明，迷你编码智能体源码中已用注释标注对应模块：
```
##############################
#### 六大智能体组件 ####
##############################
# 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 分支、状态、提交记录也能提供变更进度与聚焦方向。

**核心价值**：编码智能体在工作前先收集信息（生成工作区摘要的“稳定事实”），避免每次提示都从零开始、缺乏上下文。

![图6：智能体框架先构建工作区摘要，结合用户请求形成完整上下文](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-6)

### 2. 提示词结构与缓存复用
获取仓库视图后，下一步是如何高效把信息喂给模型。前文简化为“前缀+请求”的组合提示，但实际中每次都重新处理工作区摘要非常浪费计算。

编码会话具有重复性：
- 智能体规则基本不变
- 工具描述基本不变
- 工作区摘要大多不变
- 仅**最新用户请求、近期对话、短期记忆**会频繁变化

“智能”运行时不会每次都把所有内容拼成一个巨大无区分的提示词。

![图7：智能体框架构建稳定提示词前缀，叠加动态会话状态后输入模型](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-7)

- **稳定提示词前缀**：包含通用指令、工具描述、工作区摘要，信息变动小，可缓存复用，避免重复计算。
- **动态部分**：短期记忆、近期对话、最新用户请求，每轮交互都会更新。

**核心价值**：对稳定前缀做缓存，大幅降低重复计算，提升响应速度。

### 3. 工具访问与使用
工具调用是让系统从“聊天”变成“智能体”的关键。

- 普通模型只能用文字建议命令
- 编码框架中的大语言模型可**实际执行命令并获取结果**，无需用户手动复制粘贴

框架会提供**预定义、可命名、边界清晰**的工具列表，而非让模型随意生成语法（也可通过 Python subprocess.call 执行任意 shell 命令）。

工具调用流程：
1. 输入组装好的提示词
2. 模型输出结构化工具调用
3. 框架验证工具与参数
4. 可选用户审批
5. 裁剪工具输出（仅保留关键信息）
6. 执行工具并将结果回流到循环

![图8：模型输出结构化动作，框架验证、审批、执行并回流结果](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-8)

迷你编码智能体的工具调用审批示例：

![图9：迷你编码智能体中的工具调用审批请求](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-9)

模型必须选择框架可识别的操作（如列出文件、读取文件、搜索、执行 shell 命令、写入文件等），并按框架可校验的格式传入参数。

框架会做程序化检查：
- 是否为已知工具？
- 参数是否合法？
- 是否需要用户审批？
- 请求路径是否在工作区内？

检查通过后才会实际执行。

**核心价值**：降低风险、提升可靠性，限制模型随意执行命令，同时把文件访问限制在仓库内，减少自由度但提升可用性。

### 4. 抑制上下文膨胀
上下文膨胀不是编码智能体独有的问题，而是大语言模型的通用问题。即便现在大语言模型支持更长上下文，长上下文依然计算成本高，且易引入无关噪声。

编码智能体在多轮对话中更容易出现上下文膨胀：反复读取文件、冗长工具输出、日志等。

若运行时完整保留所有信息，很快会耗尽上下文令牌。优秀的编码框架会用更精细的方式处理，而非简单截断或摘要。

上下文压缩策略：
1. **裁剪**：缩短长文本片段、大工具输出、记忆笔记、对话记录，避免单段内容占满提示词配额。
2. **对话压缩/摘要**：将会话历史转为更小的可提示摘要。
3. **非对称细节保留**：近期事件保留更丰富信息，早期事件更激进压缩。
4. **去重**：对早期文件读取去重，避免模型重复看到相同内容。

![图10：大输出裁剪、早期读取去重、对话压缩后再输入提示词](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-10)

**核心价值**：这是编码智能体设计中被低估的关键环节，很多看似“模型质量”的差异，本质是**上下文质量**的差异。

### 5. 结构化会话记忆
前文聚焦提示时的历史使用与紧凑对话构建，侧重**压缩、裁剪、去重、时效性**。

本节**结构化会话记忆**关注历史的**存储结构**：智能体长期保留哪些永久记录，侧重**持久状态存储**。

编码智能体至少把状态分为两层：
1. **工作记忆**：精简的显式状态，用于任务延续，记录当前任务、重要文件、关键笔记。
2. **完整对话记录**：保存所有用户请求、工具输出、模型响应，可持久化到磁盘（通常为 JSON 文件），支持会话恢复。

![图11：新事件追加到完整对话记录，并摘要到工作记忆](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-11)

- **紧凑对话**：用于重建提示，给模型压缩后的近期历史，无需每次都看完整记录。
- **工作记忆**：用于任务延续，维护跨轮次的关键信息摘要。

新事件会同时追加到完整对话记录与工作记忆中。

### 6. （受限）子智能体委派
智能体具备工具与状态后，下一个关键能力是**任务委派**。

委派可把任务拆分为子任务交给子智能体并行处理，加速主任务。例如主智能体处理核心任务时，可把子问题（如符号定义文件、配置内容、测试失败原因）交给子智能体，避免单循环承载所有任务线程。

（迷你编码智能体实现更简单，子智能体同步运行，但核心思想一致。）

子智能体的设计难点：
- 需继承足够上下文才能完成工作
- 必须加限制，避免多智能体重复工作、修改同一文件、无限衍生子智能体

**设计技巧**：子智能体继承必要上下文，但在更严格的边界内运行（如只读、限制递归深度）。

Claude Code 很早就支持子智能体，Codex 近期也加入。Codex 不强制子智能体只读，而是继承主智能体的沙箱与审批配置，边界更多体现在**任务范围、上下文、深度**上。

![图12：子智能体继承上下文并在受限边界内运行](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-12)

---

## 组件总结
以上六大组件在实现中高度交织，逐一讲解有助于建立编码框架的完整心智模型，理解为何它能让大语言模型比普通多轮聊天更实用。

![图13：编码框架的六大核心功能](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent#fig-13)

---

## 与 OpenClaw 的对比
OpenClaw 是有趣的参照，但并非同类系统。
- **OpenClaw**：本地通用智能体平台，编码只是其能力之一。
- **编码智能体**：专为仓库内编码场景优化，高效完成文件检查、代码编辑、本地工具运行。

两者重合点：
- 使用工作区中的提示词与指令文件（AGENTS.md、SOUL.md、TOOLS.md）
- 存储 JSONL 会话文件，支持对话压缩与会话管理
- 可创建辅助会话与子智能体

核心差异：**编码智能体聚焦编码效率，OpenClaw 聚焦多场景、长生命周期本地智能体管理**。

---

## 新书预告
我已完成《从零构建推理模型》全书写作，目前进入抢先阅读阶段，出版社正在排版，预计今年夏天正式发售。

这是我最具野心的作品，耗时1年半完成，包含大量实验打磨。

**核心内容**：
- 推理模型评估
- 推理时扩展
- 自我优化
- 强化学习
- 知识蒸馏

理解大语言模型中“推理”的最好方式，就是从零实现一个推理模型！


## 参考资料
- [Components of A Coding Agent](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent)