Sebastian Raschka 是《Build a Large Language Model From Scratch》和《Build a Large Reasoning Model From Scratch》的作者。这篇文章讲的是 coding agents 和 agent harnesses 的整体设计。

概念区分

  • LLM：核心的 next-token 模型
  • Reasoning Model：经过训练和/或 prompting 来在推理时输出中间推理痕迹并更自我验证的 LLM
  • Agent：模型上层的控制循环，给定目标后决定下一步检查什么、调用什么工具、如何更新状态、何时停止
  • Agent Harness：围绕 agent 的软件脚手架，管理上下文、工具使用、prompts、状态和控制流
  • Coding Harness：专门针对软件工程的 agent harness，管理代码上下文、工具、执行和迭代反馈

类比：LLM 是引擎，Reasoning Model 是更强力的引擎（有更多能力，但也更贵），Agent Harness 帮助驾驭这个引擎。Codex 和 Claude Code 可以视为 coding harnesses。

核心洞察：Harness 才是区分因素

vanilla 版本的 GPT-5.4、Opus 4.6、GLM-5 能力非常相似，如果把最新最强的开源 LLM（如 GLM-5）放进类似的 harness，可能在 Codex 或 Claude Code 中与 GPT-5.4 或 Opus 4.6 表现相当。Harness 常常是让一个 LLM 表现优于另一个的区分因素。

六大核心组件

基于 Raschka 的 Mini Coding Agent（纯 Python 从零实现）：

1. Live Repo Context

当用户说"修复测试"或"实现 xyz"时，模型需要知道是否在 Git repo 里、在哪个分支、哪些项目文档可能包含指令等。这些细节会影响正确操作。"Fix the tests" 不是自包含的指令——如果 agent 看到 AGENTS.md 或项目 README，它可能学会该运行什么测试命令。

Coding agent 在做任何工作之前先收集信息（"stable facts" 作为 workspace summary），这样它不会在每个 prompt 时从零开始、没有上下文。

2. Prompt Shape And Cache Reuse

Coding session 是重复的，agent rules 通常不变，工具描述通常不变，workspace summary 也基本不变。主要变化的是最新用户请求、近期 transcript 和短期记忆。

Smart runtime 不会在每次交互时把一切都重建为一个巨大的无差异化 prompt，而是：

  • 构建"Stable prompt prefix"（包含通用指令、工具描述、workspace summary）
  • 添加变化的 session state（短期记忆、近期 transcript、最新用户请求）
  • 合并后喂给模型

缓存"Stable prompt prefix"的本质是：如果没什么重要变化，就复用它，不要每次重新从头构建。

3. Structured Tools, Validation, And Permissions

Plain model 可以用文字建议命令，但 coding harness 中的 LLM 应该做更窄、更实用的操作——实际执行命令并获取结果，而不是让用户手动调用命令并把结果粘贴回聊天。

Harness 提供预定义的允许工具列表，有明确的输入和边界。Tool use 流程：模型发出结构化 action → Harness 验证 → 可选地请求批准 → 执行 → 把有界结果反馈给循环。

每次模型要求做什么，runtime 可以停下来做程序化检查：

  • "这是已知工具吗？"
  • "参数有效吗？"
  • "需要用户批准吗？"
  • "请求的路径在工作区内吗？"

只有关卡都通过才会实际运行。Harness 给了模型更少的自由，但同时提升了可用性。

4. Context Reduction And Output Management

上下文膨胀对 coding agents 的影响比普通 LLM 更严重，因为多轮聊天中会有重复的文件读取、冗长的工具输出、日志等。如果 runtime 保持一切全保真度，会很快用完可用上下文 token。

好的 coding harness 至少使用两种压缩策略：

Clipping：缩短长文档片段、大型工具输出、记忆笔记和 transcript 条目。防止任何一段文本仅因为恰好冗长就占据整个 prompt 预算。

Transcript reduction or summarization：把完整 session 历史转化为更小的可 prompt 的摘要。关键技巧：保持近期事件更丰富（更可能与当前步骤相关），更激进地压缩旧事件（可能不太相关）。同时对旧的文件读取做去重，避免模型因为多次读取同一文件而反复看到相同内容。

核心观点：很多明显的"模型质量"实际上是"上下文质量"。这是好的 coding agent 设计中最被低估的部分。

5. Transcripts, Memory, And Resumption

Session 记忆的存储时间结构：coding agent 把状态分离为（至少）两层：

  • Working memory：agent 显式维护的小型、提炼状态
  • Full transcript：完整的用户请求、工具输出和 LLM 响应的历史

Full transcript 存储完整历史，关闭 agent 后可恢复。Working memory 是更提炼的版本，只保留当前最重要信息——当前任务、重要文件、最近笔记等。

Compact transcript 和 working memory 职责不同：compact transcript 用于 prompt 重建（给模型压缩后的近期历史视图），working memory 用于任务连续性（跨步骤维护小而显要维护的摘要）。

6. Delegation And Bounded Subagents

一旦 agent 有了工具和状态，下一个有用的能力是委托。允许通过子 agent 并行化某些工作为子任务，加速主任务。例如，主 agent 可能在执行一个任务中途仍需要旁边问题的答案（哪个文件定义了一个符号、配置说了什么、为什么测试失败），把它拆分出来比强迫一个循环同时携带每条工作线程更高效。

子 agent 有用的前提：它继承了足够的上下文来做实际工作。但如果不限制，就会有多个 agent 重复工作、触碰同一文件或生成更多子 agent。所以棘手的设计问题不只是如何生成子 agent，还有如何给它设界。

诀窍：子 agent 继承足够上下文是有用的，但也要有约束（例如只读、限制递归深度）。

Raschka 对 OpenClaw 的评价

OpenClaw 是一个更通用的本地 agent 平台，也能编程，但不像专门的（终端）coding 助手那样是同类型的系统。

与 coding harness 有重叠的地方：

  • 在 workspace 中使用 prompt 和 instruction 文件（如 AGENTS.md、SOUL.md、TOOLS.md）
  • 保持 JSONL session 文件，包含 transcript 压缩和 session 管理
  • 可以生成辅助 session 和子 agent

但侧重点不同：Coding agent 优化的是在 repo 中工作、让 coding assistant 检查文件、编辑代码和运行本地工具的个人。OpenClaw 优化的是跨聊天、频道和工作空间运行多个长期本地 agent，coding 是若干重要工作负载之一。