当我们谈论大型语言模型的编码能力时，往往容易将模型本身、推理行为和最终产品混为一谈。Sebastian Raschka 在其最新研究中明确指出，模型是引擎，推理模型是加装增压器后的更强引擎，而智能体 harness（智能体框架）则是帮助我们更好地驾驭这台引擎的外层系统。这一层层递进的关系，恰恰解释了为什么相同的基础模型在不同的工程化包装下会表现出截然不同的能力水平 ——Claude Code 和 Codex 之所以比普通聊天界面更强大，关键不在于底层模型，而在于周围系统的工程设计。
一、提示工程与缓存复用：稳定前缀的构建艺术
编码智能体的提示工程与通用对话系统有着本质区别。在传统聊天场景中，每次交互都是相对独立的上下文；而在编码场景中，会话是高度重复的 —— 智能体规则保持不变，工具描述保持不变，工作区摘要也基本保持不变。变化的只有最新的用户请求、最近的对话记录和短期记忆。
基于这一观察，优秀的编码智能体不会在每次交互时都重新构建一个完整的提示，而是采用稳定前缀（Stable Prompt Prefix）的策略。这个稳定前缀包含通用指令、工具描述和工作区摘要，这些信息在短时间内不会发生重大变化，因此可以在多次调用中重复使用。这种设计的核心优势在于避免计算资源浪费，同时保证模型能够获得一致性的上下文支持。Raschka 在其 Mini Coding Agent 实现中，通过 build_prefix、memory_text 和 prompt 三个组件实现了这一机制，分别负责构建稳定前缀、管理记忆文本和组合最终提示。
值得注意的是，缓存策略的实现需要权衡两个因素：一是缓存粒度，过粗的缓存可能导致上下文过期；二是计算开销，过细的缓存则失去了复用的意义。在实际工程中，通常会设定缓存失效的触发条件，例如检测到文件系统变化或用户明确指示任务切换。
二、工具链设计：结构化执行与权限控制
工具访问与工具使用是编码智能体从聊天模式转向智能体模式的关键转折点。一个普通模型可以在对话中建议执行某些命令，但编码智能体需要能够真正执行这些命令并获取结果，而不是让用户手动调用命令后再将结果粘贴回对话中。
在工具链设计中，最核心的原则是结构化约束。与其让模型自由发挥、生成任意格式的指令，智能体框架通常会提供预定义的工具列表，每个工具都有明确的输入输出规范和调用边界。这种设计带来三重优势：首先是安全性保障，框架可以在执行前进行程序化检查，验证工具是否已知、参数是否合法、是否需要用户审批、请求路径是否在工作区范围内；其次是可靠性提升，模型不会执行完全随意的命令，行为变得可预测；最后是执行效率，结构化的工具调用可以被框架直接解析和执行，无需额外的自然语言处理步骤。
Raschka 在研究中特别强调了权限控制的重要性。在他的 Mini Coding Agent 实现中，工具的执行流程包括 validate_tool（验证工具）、approve（审批检查）和 run_tool（执行工具）三个阶段。对于可能产生副作用的操作（如文件写入、命令执行），框架可以要求用户确认；对于敏感路径的访问，框架可以自动拒绝。这种设计在赋予模型强大能力的同时，也将其控制在安全边界内。
三、记忆与上下文管理：双层状态架构
上下文膨胀（Context Bloat）是所有大型语言模型面临的共同挑战，但在编码智能体中，这个问题更为突出。因为编码智能体需要处理重复的文件读取、冗长的工具输出、复杂的日志信息，这些都会快速消耗有限的上下文窗口。如果框架将所有信息都保持完整 fidelity，可用上下文 token 会很快耗尽。
一个优秀的编码智能体框架通常采用双层状态架构来应对这一挑战。第一层是工作内存（Working Memory），这是智能体显式维护的精炼状态，包含当前任务、最重要的文件和最近的笔记等关键信息。第二层是完整转录本（Full Transcript），记录所有用户请求、工具输出和模型响应，作为持久化状态存储。
在具体实现上，上下文压缩策略通常包括三个核心技术：首先是截断（Clipping），将过长的文档片段、工具输出和对话记录压缩到合理长度，防止单条信息占据过多提示预算；其次是去重（Deduplication），对于多次读取的同一文件，智能体只需要保留最新版本，避免重复内容浪费空间；最后是差异化管理，最近发生的事件保持丰富细节，而较早的事件则进行更激进的压缩。这种基于时间衰减的差异化策略，源于一个朴素但重要的观察 —— 最近的事件更可能与当前步骤相关。
Raschka 特别指出，上下文质量往往被认为是模型质量，但实际上很多 apparent 的模型能力差异本质上是上下文质量的差异。这一观点对于工程实践具有重要启示：在抱怨模型表现不佳之前，首先应该检查提供给模型的上下文是否足够清晰、相关和结构化。
四、推理机制与子智能体委托
如果说前三项组件更多是基础设施层面的设计，那么推理机制则是编码智能体实现复杂任务分解和执行的核心能力。在 Raschka 提出的六组件模型中，推理机制主要体现在子智能体委托（Delegation And Bounded Subagents）这一维度上。
当主智能体在执行一个任务时，经常会遇到需要并行处理的旁支需求 —— 例如查询某个符号的定义、查看配置文件内容、或者分析测试失败原因。将这些旁支任务委托给子智能体，可以有效提升整体效率。但子智能体的设计存在一个关键挑战：如何在保证足够上下文的同时，避免多个智能体之间的工作重复、文件冲突和递归失控。
解决这一挑战的关键在于为子智能体设置明确的边界（Boundary）。具体而言，子智能体应该继承足够的上下文以完成有意义的工作，但同时受到严格的约束 —— 通常是只读模式或受限的递归深度。Raschka 以 Claude Code 和 Codex 为例说明了两者的不同策略：Claude Code 长期支持子智能体，通常将其限制为只读模式；Codex 则更倾向于让子智能体继承主智能体的大部分沙箱和审批设置，边界主要体现在任务范围、上下文和深度上。
在更高级的实现中，子智能体的边界还可以包括资源限制（如最大执行时间、最多工具调用次数）和状态隔离（不允许访问主智能体的某些敏感数据）。这些边界机制确保了智能体系统的可控性和可预测性。
五、工程落地的关键参数
基于上述分析，我们可以提炼出构建编码智能体时需要关注的核心工程参数。在提示工程维度，稳定前缀的缓存周期建议设置为 5 至 15 分钟或依据文件系统变化事件触发；工作区摘要的构建应包含 Git 状态、分支信息和项目文档路径。在工具链设计维度，工具调用审批阈值应根据操作风险等级分类设定 —— 文件读取可自动执行，文件写入需确认， shell 命令执行需严格审批。在上下文管理维度，单次截断的目标长度建议不超过原始内容的 30%，对话历史压缩比可设置在 5:1 至 10:1 之间，文件读取去重策略应保留最近三次读取的完整内容。在子智能体维度，递归深度建议限制在 2 至 3 层，只读子智能体可适当放宽上下文继承比例。
这些参数并非一成不变的最优解，而是需要根据具体应用场景、目标代码库规模和团队安全策略进行调优。Raschka 在其开源的 Mini Coding Agent 项目中提供了简洁的参考实现，这些参数可以作为工程落地的起点。
Sebastian Raschka 的研究揭示了一个重要趋势：在模型能力日趋同质化的当下，智能体框架的设计正在成为决定实际表现的关键差异因素。提示工程的优化、工具链的完善、记忆与上下文的管理、以及推理机制的增强，这四大维度相互交织，共同构成了现代编码智能体的技术基石。
资料来源：Sebastian Raschka, "Components of A Coding Agent", 2026 年 4 月 4 日发布于 Sebastian Raschka Magazine。