LLM Harness Writing Study

2026-05-26#llm-engineering#agent-runtime#harness#writing-method

来源

说明：这是一份读后学习笔记，只记录概念框架和写作方法。原文里的具体数据、公司案例和未来时间点如果要进入正式文章，需要再逐条考证一遍。

概念框架

原文把 LLM Engineering 的演化讲成三圈螺旋：

  1. Prompt Engineering：任务相对静态，人通过措辞、角色、示例和输出格式优化单次输入。它解决的是“怎么问”，但卡在多步任务上。
  2. Context Engineering：任务动态展开，程序把上一步输出、工具反馈、检索结果和压缩后的历史注入下一步。它解决的是“给模型看什么”，但规则大多由人预设。
  3. Harness Engineering：模型足够强以后，重点转向给 agent 工具和反馈通道，让它自己判断该看什么、该验证什么；同时用 sandbox、权限、测试、CI 轮数、结构约束等边界防止失控。

最有价值的区分：

  • Context Engineering 是程序替 agent 编排信息。
  • Harness Engineering 是给 agent 获取信息和反馈的能力，再用边界约束行为。
  • Runtime 能力不等于 harness。状态持久化、compaction、session 续接更像 agent runtime 的基础设施；harness 关心 agent 运行时是否能主动获得反馈，以及是否被可执行边界约束。

可复用判断

这篇文章的主线不是“新名词替代旧名词”，而是“瓶颈迁移”：

  • prompt 时代的瓶颈是表达方式；
  • context 时代的瓶颈是信息流转；
  • harness 时代的瓶颈是环境、反馈循环和控制系统。

这个框架适合用来写 agent 工程文章，因为它把抽象概念放回了工程问题里：上一阶段为什么不够用，下一阶段到底解决了哪个具体卡点，又引入了什么新的可靠性问题。

可以迁移到自己的文章里的句式骨架：

  • “瓶颈从 A 移到了 B。”
  • “X 不是凭空设计出来的新范式，而是 Y 跑起来之后被现实教育出来的经验。”
  • “先放手，再从失败模式倒推边界。”
  • “上一圈没有消失，它变成了当前这一圈的基础设施。”

这些句式好用，但正式写作时要换成自己的案例和语言，避免直接复刻。

写作方法

1. 先给读者地图，再展开历史

开头先用一段话给出三阶段关系和 TL;DR，让读者知道后面不是概念堆叠，而是在解释三个问题：

  • 旧做法为什么不够用；
  • 新做法解决了什么；
  • 新做法又卡在哪里。

这种开法适合长文，因为读者在进入细节前已经拿到“导航图”。

2. 每一节都用同一个推进模板

文章每讲一个阶段，都大致按这个顺序走：

  1. 当时的典型实践是什么。
  2. 为什么它确实有效。
  3. 它解决不了什么。
  4. 因此瓶颈迁移到哪里。

这种重复结构让概念升级显得自然，不像硬塞术语。

3. 抽象定义必须从案例里长出来

Harness Engineering 不是一开始就定义，而是先讲“放手”和“上保险”，再用 Stripe、Anthropic、OpenAI 三个案例验证：

  • Stripe：快速反馈工具链和受限运行环境。
  • Anthropic：从长任务失败模式倒推 feature 粒度、JSON 状态和端到端验证约束。
  • OpenAI Codex：把工程师工作重心从写产品代码转向环境、反馈循环和控制系统。

这正好贴合 thought-forge 的防概念先行规则：先让读者看到实践，再用术语压缩实践。

4. 概念边界要靠反例澄清

文中专门说了“什么不算 Harness”，把 compaction、session 续接、记忆管理归到 runtime，而不是 harness。

这个写法很重要：新概念最怕边界膨胀。给出反例，能让读者知道作者不是在拿新词兜所有东西。

5. 收尾不是总结，而是指出下一圈瓶颈

结尾没有停在“Prompt -> Context -> Harness”的总结，而是把下一圈问题指向 eval 和 governance。

这种收尾方式适合技术趋势文：它让文章从“定义当前阶段”自然过渡到“下一篇可以写什么”。

可发展的文章角度

  • Harness 不是 Agent Runtime：别把 compaction 当成产品卖点
  • 先放手，再上保险：Agent 工程里的边界从哪里来
  • 从 context rot 到 eval rot：LLM Engineering 的瓶颈为什么总会迁移
  • Agent 工程不是写更长的 prompt，而是设计更短的反馈回路

待考证清单

如果要把这篇 X Article 的内容发展成正式文章，至少需要验证：

  • Context Engineering 的 Karpathy 原始表述和发布时间。
  • Stripe Minions 的工具链、CI 轮数和 PR 数字。
  • Anthropic 长任务 harness 实验的具体设置。
  • OpenAI Codex 团队文章里关于 harness、环境设计和代码量的原始上下文。
  • Epsilla、LangChain Terminal Bench 2.0、Microsoft/Salesforce context rot 等定量结论的实验条件。
  • 2026 年关于 eval、governance、agent standard 的行业事件是否来自官方来源。