目录
缰绳工程（Harness Engineering）这个说法在 2026 年 2 月迅速流行开来。2026 年 2 月 5 日，终端 Ghostty 的作者、HashiCorp 联合创始人 Mitchell Hashimoto 在博客中用它来称呼一种做法：代理每犯一次错，就花时间搭一套机制，让它再也不犯同样的错。6 天后，OpenAI 把这个词放进了 Codex 团队实验报告的标题。Anthropic 更早之前就以“harness”之名公开了长时间运行代理周边机制的设计。如果说 2025 年人们在讲“提示词之后是上下文工程”，那么缰绳工程处理的是更外面的一层。
本文将系统梳理缰绳工程到底是什么，它与提示词工程、上下文工程有何不同，构成缰绳的 6 大组件，OpenAI 和 Anthropic 公开的真实案例，实用的设计清单，以及主流工具的比较——这是你认真使用或构建 AI 代理时不可或缺的根基。
缰绳 = 包裹 LLM 的 4 层结构
— 如同套在马身上的缰绳，将强大的力量引导向你所指的目标
即使使用同一个 LLM，仅靠缰绳设计就能让品质与安全性发生剧烈摆动。
这就是“缰绳工程”所在的战场——一门全新的设计学科。
1. 什么是缰绳工程（Harness Engineering）？
“Harness（缰绳/挽具）”原本指套在马身上的器具——把动物的力量引向你所指方向的整套装备。AI 领域里的这一术语正是同一个隐喻：把强大却难以驯服的 LLM 投入实际生产的整套装备。
具体而言，包含：
- 工具（Tools）：文件操作、网页搜索、代码执行——LLM 借以采取行动的手段。
- 上下文管理：决定哪些内容塞进提示词、哪些被压缩或丢弃的策略。
- 记忆系统：跨会话保存的持久化知识与用户偏好。
- 代理循环（Agent loop）：感知 → 推理 → 行动 → 观察的循环。
- 护栏（Guardrails）：权限、沙箱、Hooks、审批流程。
- 输出格式：markdown、JSON、引用、流式传输。
把上述一切作为整体来设计，就是缰绳工程。它不是去训练或改进 LLM 本身，而是通过精心打造 LLM 周围的一切，提升其在真实世界中的可用性。Claude Code、Cursor、Devin、Codex CLI——它们运行的底层模型大致相同，但行为与表现却天差地别，原因正在于缰绳的差异。
“缰绳”一词的边界在哪里，Thoughtworks 的 Birgitta Böckeler 在 martinfowler.com 上（2026 年 4 月 2 日）说得很清楚：缰绳就是代理中除模型以外的一切，写成式子就是 Agent = Model + Harness。Anthropic 也用同一个词描述自家的云服务，称 Claude Managed Agents 为可配置的代理缰绳。
2. 缰绳工程 vs 提示词工程
提示词工程并未消失——但两者的范畴有本质差异。
| 维度 | 提示词工程 | 缰绳工程 |
|---|---|---|
| 对象 | 单轮输入文本 | 整个系统（工具、记忆、循环） |
| 主要工作 | 优化提示词措辞、挑选 few-shot 示例 | 工具设计、上下文策略、循环设计 |
| 交付物 | 文本模板 | 代码、配置、系统架构 |
| 所需技能 | 语言感、对 LLM 行为的直觉 | 通用软件工程能力 |
| 影响范围 | 单次回复的质量 | 长任务的完成率、成本与安全 |
| 例子 | “Think step by step” | 定义一个计算器工具，让 LLM 调用 |
如果说提示词工程是“对 LLM 说什么”的手艺，那么缰绳工程就是“给 LLM 配备什么、又如何驾驭它”的手艺。两者并非竞争关系——而是分层关系。提示词只是缰绳之中的一个组件。
另一个容易混淆的概念是上下文工程。Anthropic 在 2025 年 9 月 29 日的文章中，把它定位为提示词工程的自然延伸。前面提到的 Böckeler 则把为编程代理搭建缰绳视为上下文工程的一种具体形式。归纳起来是一层套一层：提示词（说什么）⊂ 上下文（给模型看什么）⊂ 缰绳（给它什么、如何检查它的产出、如何让它停下）。缰绳特有的，是像 linter 和测试那样机械地检查结果并把失败退回给代理的部分。
3. 缰绳的 6 大组件
1. 工具调用（Tool Use）
LLM 作用于世界的手段：读写文件、执行代码、网页搜索、调用 API。工具接口（名称、参数、返回值）一旦设计错误，LLM 就无法正确使用。具体而言：
- 动词式、含义明确的命名（例如
read_file）。 - 必填与可选参数显式区分，并提供默认值。
- 失败时返回结构化错误信息（告诉模型下一步该怎么办）。
- 对有副作用（破坏性）的操作明确标注警告。
2. 上下文管理
LLM 的注意力是有限的——你给它看什么，决定它说什么。具体而言：
- 相关性过滤：只抽取与任务相关的部分，而非整份文件。
- 压缩：对长对话进行总结以便保留。
- RAG 集成：通过向量检索按需获取所需信息。
- 缓存：借助 Anthropic 的 prompt cache 等工具，削减重复系统提示的成本。
相关阅读：什么是 RAG？
3. 记忆系统
跨会话保留知识。Claude Code 的 CLAUDE.md、Cursor 的 .cursor/rules、Codex 的 AGENTS.md 都是项目记忆的实例。除此之外还有：
- 短期记忆：近期对话历史。
- 长期记忆：用户画像、过往决策。
- 事实性知识：领域专属知识库。
4. 代理循环（Agent Loop）
让“AI 代理”真正运转起来的核心。基本形态是感知 → 推理 → 行动 → 观察循环：
- 接收用户的目标。
- 分析当前状态（必要时通过工具收集信息）。
- 规划下一步行动。
- 通过工具执行行动。
- 观察结果；判断目标是否达成。
- 未达成则继续循环，达成则终止。
代理能多聪明，取决于你是否在其中嵌入了重新规划、自我批评与子目标分解。
5. 护栏（Guardrails）
防止失控行为的机制。正如AI 为何无视你的 .md 规则所述，通过环境强制行为，比在文档里好言相劝可靠得多：
- 审批模式：危险操作执行前由人确认（例如 Claude Code 的权限设置、Codex CLI 的审批模式）。
- 沙箱：限制文件系统与网络访问。
- Hooks：在工具调用前后插入任意校验。
- 速率限制：万一失控，将损害最小化。
6. 输出 UX
把结果以用户能够理解并验证的形式呈现出来。Markdown 渲染、来源引用、语法高亮的代码块、流式输出、可见的推理（thinking）、结构化输出（JSON）等等。仅仅给出“正确答案”还不够——以用户能信任并验证的形式交付，正是缰绳的职责。
4. 为何缰绳工程，为何就在此刻？
有三股力量正在推动缰绳工作热度的飙升。
1. 事实证明，同一个模型因外围机制不同，结果差别巨大。在 Anthropic 2026 年 3 月 24 日公开的实验中，同一个 Claude Opus 模型收到一句话的任务：做一个 2D 复古游戏制作工具。单个代理 20 分钟、花费 9 美元就结束了，但做出的关卡无法游玩。拆成规划者、生成者、评估者三个角色的缰绳跑了 6 小时、花费 200 美元，做出的游戏角色真的能动起来（物理效果仍然粗糙）。成本高出 20 倍以上，但质量也完全是两回事。在质量与成本之间取舍，如今和选模型一样，要靠缰绳的设计来决定。
2. 提示词无力解决的问题在不断堆积。“工具太多，模型挑错了。”“上下文塞得太满，重要信号被淹没。”“长任务跑到一半，代理就跟丢了主线。”这些都不是单轮里换个更聪明的措辞就能解决的——它们是设计层面的问题。
3. 工程师的工作本身开始变化。OpenAI 的 Codex 团队报告说，他们用 5 个月、在不手写一行代码的情况下持续开发一款内部产品，代码量达到约 100 万行，合并了约 1,500 个拉取请求（2026 年 2 月 11 日）。他们的结论是：工程师的主要工作已从写代码转向设计环境、明确意图、搭建反馈回路。Claude Code、Codex、Cursor、Devin 等主流产品，也都在模型之外的设计上一较高下。
5. 公开的真实案例：三套缰绳
缰绳工程很容易流于空谈。下面三个例子，作者都公开了细节，这里按他们实际做了什么的粒度来介绍。
1. OpenAI Codex 团队：AGENTS.md 只做“地图”，规则交给 linter 强制
- AGENTS.md 只保留约 100 行的目录，设计、计划和质量记录放在仓库内的
docs/目录，并以它为唯一可信来源。原因是一个巨大的文件会挤占上下文、很快过时，也无法机械检查。 - 为防止文档过时，由 linter 和 CI 检查交叉链接和结构，并定期运行一个代理，找出与实际代码不符的描述，提交修正的 PR。
- 分层结构与依赖方向、结构化日志、文件大小上限等，都用自研的 linter 和结构测试强制执行。错误信息里直接写明修复方法，让代理读了就能自己改。
2. Anthropic：为长时间运行的代理设计“交接”
当开发跨越多个上下文窗口时，代理会一次做太多，或者做到一半就宣布完成。Anthropic（2025 年 11 月 26 日）的对策如下。
- 只有第一个会话运行使用专门提示词的初始化代理，由它准备功能清单（
feature_list.json）、进度记录（claude-progress.txt）、启动开发服务器的init.sh，以及第一次 git 提交。 - 之后的每个会话都先读进度记录和 git log 了解现状，每次只实现一个功能，最后以提交和更新记录结束。
- 功能清单用 JSON 而不是 Markdown，因为模型不太会乱改 JSON 文件。允许改动的只有表示通过与否的字段（
passes）。 - 只有在用浏览器自动化像真实用户一样从头到尾测过之后，才能把功能记为完成。
3. Mitchell Hashimoto：同样的错误不犯第二次
命名者本人的做法更小巧。代理犯了简单的错，就在 AGENTS.md 里加一行；他的终端项目 Ghostty 的这个文件，每一行都对应一次过去的错误行为，这样几乎全部解决了。文字解决不了的，就写真正能运行的脚本（截图、只跑筛选后的测试等）交给代理。
三者的共同点是，重心放在检查并退回的机制上，而不是用文字去拜托。哪些该做成机制，可以用下面的清单来判断。
6. 实用缰绳设计清单
优秀缰绳的 7 项检查点
7. 主流缰绳横向对比
主流 AI 代理缰绳的设计倾向
这些缰绳运行在大致相同的 LLM（Claude / GPT / Gemini）之上，长处却因设计哲学不同而显著分化。“用哪个缰绳”比“用哪个 LLM”更重要——这才是代理时代真正的战场。
8. 反模式
1. 工具加得太多
工具越多，LLM 越容易选错。Anthropic 的文档写道，可用工具超过 30–50 个时，Claude 选择工具的准确度会下降，并提供了按需只加载相关工具的工具搜索。该公司关于编写工具的指南也指出，工具并非越多越好：不要把每个 API 端点都原样包成工具，相似的功能应合并。
2. 把所有东西都塞进上下文
“为了保险，干脆全都给它看”是适得其反的做法。过一道相关性过滤，只放必要的内容。上下文是凸显重要信号的装置——而非储物柜。
3. 仅靠提示词来实现安全
“请不要执行危险操作”——这种叮嘱迟早会被无视，时机各看情况。正确做法是在环境层面让其物理上不可行——沙箱、Hooks、权限限制。
4. 加上去的机制从不复查
缰绳加得越多，就越重、越慢、越贵。Anthropic 在前述实验之后，把组件一个个拿掉并比较结果，只留下仍然有效的部分（规划者和评估者）。他们指出：缰绳里的每个组件，都隐含着“模型自己做不到什么”的假设，而随着模型变强，这些假设很快就会过时。换了模型之后，要逐一确认当初加的检查和拆分是否仍然有用。
总结
缰绳工程是设计 LLM “外侧”那一层的手艺。提示词工程不过是缰绳之中的一个组件而已。把六大要素——工具定义、上下文管理、记忆、循环、护栏、输出 UX——一一审慎对待，同一个底层 LLM 也能在真实场景中焕然一新。
截至 2026 年，生产级 AI 代理的主战场已明确转移到了缰绳一侧。打造“聪明的缰绳”——而不仅仅是写出“聪明的提示词”——将是下一代工程师的差异化所在。
FAQ
Q1. 那提示词工程不再需要了吗？
错。它依然不可或缺——只是作为缰绳之中的一个组件。工具描述、系统提示、错误信息——它们都是提示词设计的对象面。过时的，是“靠一个更妙的提示词把它修好”这种心态。
Q2. 学习缰绳工程的第一步是什么？
找一个 Claude Code 或 Cursor，不要只是用——通过修改它的配置去改变它的行为。把前面 Hashimoto 的做法拆成步骤，就是下面这样。
- 逐条记下代理的失败（在哪条指令下、错在哪里）。
- 简单的失败，就在
CLAUDE.md/AGENTS.md/.cursor/rules里加一行。 - 反复出现的、或一旦发生就麻烦的失败，用 Hooks、linter、测试机械地拦住，并在错误信息里写明修复方法。
- 让代理再做一遍同样的任务，确认失败已经消失。
Q3. 缰绳和 LangChain 这类框架是一回事吗？
接近，但并不相同。框架是实现工具箱；缰绳是设计学科与思维方式。LangChain、LlamaIndex、Claude Agent SDK等都属于构建缰绳的工具。
Q4. 自己造缰绳，还是用现成的？
多数情况下，现成缰绳（Claude Code、Cursor 等）+ 自定义就够了。从零自造只在企业级要求、垂直领域或极致成本优化等场景下才有意义。
Q5. “缰绳工程师”会成为正式的职位名称吗？
目前还没有固定的职位名称。命名者 Hashimoto 本人也写道，他不知道业界是否已有通行的叫法。不过 OpenAI 的 Codex 团队报告说，工程师的主要工作已转向设计环境、明确意图、搭建反馈回路——在职位名称定下来之前，工作内容已经先变了。
