---
title: "约束工程"
date: "2026-04"
category: "ai运用"
tags: ["ai运用"]
description: "约束（Harness，或者说缰绳、马鞍，限制马的工具）工程，是个很有意思的概念，看上去更像是上下文工程的延申——核心的关键是把对agent的上下文约束，进展到整个环境约束..."
source: "https://enriquemark.com/zh-hans/posts/%E7%BA%A6%E6%9D%9F%E5%B7%A5%E7%A8%8B"
---

约束（Harness，或者说缰绳、马鞍，限制马的工具）工程，是个很有意思的概念，看上去更像是上下文工程的延申——核心的关键是把对agent的上下文约束，进展到整个环境约束。给agent提供一套受控的、完善的开发环境，里面同时包含着所需的默认工具、知识（待注入的上下文）、预定义的指定、安全沙箱、hook等完善的配置。总之其核心目的，就是让agent在一个远超单纯上下文的环境中工作。

一个比较关键的核心是：让agent自主利用已有的一切，去让自身保持最佳状态。而这个最佳状态是我（约束）设计者，预先定义好的。比如让agent在合适的时候[自主](https://blog.langchain.com/autonomous-context-compression/)触发上下文压缩的hook，亦或者在执行bash命令时强制请求同意，亦或者时从最初就遵循渐进披露的原则，等等。

甚至更进一步的，当今agent时代的代码开发瓶颈已经从实现变成了审查，那我就可以在约束内部自定义一个检查机制（比如TDD导向的开发模式），让agent在最初就保证代码质量。抑或是直接在平台内部开一个agent，不断地跟进代码质量并**实时**基于开发agent代码质量的反馈。

>具体来说，约束包括以下内容：
	系统提示
	工具、技能、MCP + 及其描述
	捆绑基础设施（文件系统、沙盒、浏览器）
	编排逻辑（子代理生成、切换、模型路由）
	用于确定性执行的钩子/中间件（压缩、延续、lint 检查）
>[The Anatomy of an Agent Harness](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)

可以分为两个大块，对状态的管理，和对边界的管理。agent的运行在默认状况下是无状态的，那么当我需要让它开发一个新的项目时，就会变得非常有问题。因此我就需要从外部给它注入状态，上下文工程就是干这个的。但随着项目开发本身开始复杂，那我需要的就不只是让它知道干什么、怎么做、用什么做——我还需要规定它的边界。因此「约束」不只是对上下文的约束，同样还是对执行和开发的约束。

而这玩意儿做到极致就是全自动的agent，只需要「许愿」，就能带出全部想要的结果。所以想是[oh-my-claudecode](https://github.com/Yeachan-Heo/oh-my-claudecode/blob/main/README.zh.md)这样的工具，其最核心的目的就是给agent提供**持久自主运行**下的约束。核心模型负责提供大脑，而 Harness 则提供让其能最大化按照我想要的效果去发挥和生长的基础平台。就像一匹马，让框架带着着缰绳，让它走向我希望它去的方向。

---

现在比较正式的翻译叫做「驾驭工程」，这个我确实也更贴切，用合适的Harness让agent能更好的工作。我之前比较强调「自动运作」，但「人机交互」同样需要更好的缰绳。一个好的Harness确实对工作非常重要。比如我比较习惯cc，codex和gemini或者opencode也不是不能用，但就总感觉少了点什么。因为cc的Harness就目前来看，的确是用户体验比较好的一批，ide支持也齐全，最大的缺点就是闭源（当然也有开源平替，这还得感谢A\自己的误操作）。我个人也不是很喜欢厂商锁定，因此多尝试其他Harness也是有益的。如果实在不爽，直接换成开源版cc倒也可以。