什么是框架工程（Harness Engineering）— 模型是固定输入，你交付的是它周围的一切

• 同一个模型，为什么结果不一样
• 框架：围绕模型的整个执行系统
• "提示词工程"这个名字遮住了什么
• 工作流也好，智能体也好，框架都在那里
• 旋钮不是各转各的
• 亲手练习
• 参考资料

同一个模型，为什么结果不一样

假设两个团队用同一个基础模型自动化同一类任务。一个团队的智能体接到 issue 后能产出通过测试的补丁，另一个团队的智能体在类似的 issue 上翻了一圈文件，卡在半路。这个对比是为了说明而构造的例子，但这个格局本身，运营过智能体的团队都不会陌生。既然模型相同，差异就来自模型之外。

把模型之外有什么写下来，清单比想象的长。暴露了哪些工具、多少个。工具失败时返回给模型什么。最多重试几次、依据什么停下来。每一轮往上下文窗口里放什么、丢掉什么。智能体能写到哪些路径。以及结果好不好由谁、按什么标准来判定。这整张清单以代码的形式存在、被部署，并左右任务成功率。

框架：围绕模型的整个执行系统

Lilian Weng 在 2026 年 7 月写的那篇文章给这张清单起了名字。框架是包裹基础模型、协调其执行的系统：决定模型如何思考与规划、如何调用工具与行动、如何感知与管理上下文、把产物存到哪里、如何评估结果的那一整层，都是框架。

本系列把这条边界之内的东西分成六个旋钮来讲。

• 工具表面 — 暴露给模型的工具集合及其 schema。给多少个，用什么名字和描述。
• 失败返回格式 — 工具失败时，是把异常字符串原样丢回去，还是把原因加可选替代方案结构化返回。
• 循环 — 重试上限、停止条件、卡住时的升级路径。
• 上下文策略 — 放什么、去掉什么、什么时候做摘要。
• 权限 — 智能体能读写的范围，尤其是评估代码是否在这个范围之内。
• 评估者 — 判定结果的打分器。它决定整个系统的上限。

前提只有一个。对大多数团队来说，模型是固定输入。既不训练基础模型也不做微调的团队，能动手的就是这六样，而这六样也已经足够多了。

"提示词工程"这个名字遮住了什么

这项工作长期以来的名字是提示词工程。这个名字并没有错，但它严重低估了范围。在上面六个旋钮里，提示词没有作为独立条目出现在任何一处。系统提示词是上下文策略的一部分，工具描述文案是工具表面的一部分。能用代码定义的空间远大于能用句子指示的空间，而真正大幅移动成功率的决定，大多在前者。

Anthropic 在 2024 年 12 月发布的智能体构建指南从工具这一侧点破了这件事。就像人有 UI 一样，智能体的接口就是工具定义，所以在工具设计上要花与提示词同等的功夫。同一篇文章还写道，在他们自己的 SWE-bench 工作中，花在优化工具上的时间比花在整体提示词上的还多。

失败返回格式也是同一类例子。在把异常字符串原样返回的框架里，模型倾向于重复同一个调用；在把失败原因和当前可尝试的替代方案结构化返回的框架里，下一次调用就会不一样。这种差异靠打磨提示词是买不来的，它完全是代码侧的决定。

工作流也好，智能体也好，框架都在那里

同一篇 Anthropic 文章把智能体式系统分成两类。工作流是把 LLM 与工具编排在预先确定的代码路径上；智能体则让模型自己决定下一步行动和工具使用。文章还建议从最简单的方案开始，只在需要时增加复杂度。很多问题，单次调用加上检索和示例就真的够用了。

从框架的视角重读这个区分，会得到这样的结论：工作流同样需要工具表面、失败返回格式、权限和评估者。越往智能体那头走，循环的主导权越移向模型，重试上限、停止条件、上下文策略的分量就急剧增大。无论哪一种，你部署的都是框架——而能说清自己部署了什么，管理才算开始。

旋钮不是各转各的

把六个旋钮写成代码，就是本系列的目录。

harness = {
    "tools": ["read_file", "write_file", "run_tests"],      # 第 3 篇：工具表面
    "on_error": "cause_plus_alternatives",                  # 第 3 篇：失败怎么返回
    "loop": {"max_retries": 3, "stop": "goal_check"},       # 第 4 篇：循环与停止条件
    "context": {"policy": "playbook", "budget": 12000},     # 第 2 篇：上下文预算
    "permissions": {"write": ["src/"], "deny": ["eval/"]},  # 第 6 篇：奖励作弊与权限
    "evaluator": "rubric_v3",                               # 第 5 篇：评估者瓶颈
}

要注意的是旋钮之间互相纠缠。提高重试上限的决定与失败返回格式纠缠在一起：没有原因的重试只是以更高的代价重复同一次失败。增加工具的决定与上下文预算纠缠在一起：工具的 schema 也吃 token。而所有旋钮都与评估者纠缠在一起：判定哪种组合更好的是评估者，评估者弱，比较本身就不成立。所以本系列逐个讲旋钮，但总会回到同一个问题：这次改动变好了，你凭什么知道？

亲手练习

这个博客有一个把框架工程做成游戏的框架工程 RPG：亲手组装刚才看到的六个旋钮，通关 27 个场景。第 1 层"观测与指纹"对应本文的内容。想打牢提示词侧的基本功，还有提示词工程练习工具。

• 本系列的背景文章：框架不是配置，而是交付物
• 下一篇：上下文预算 — 设计在于去掉什么，而不是放进什么

参考资料

• Harness engineering for self-improvement — Lilian Weng, 2026-07-04 —— 框架的定义与组成部分，以及框架工程面临的难题清单，都在这篇文章里。
• Building effective agents — Anthropic, 2024-12-19 —— 工作流与智能体的区分、从简单方案开始的建议、把工具定义当作接口的观点，都在这篇文章里。
• 开头的两个团队的故事与正文中的框架代码是为说明而构造的示例，不是实测。