约束工程
约束（Harness，或者说缰绳、马鞍，限制马的工具）工程，是个很有意思的概念，看上去更像是上下文工程的延申——核心的关键是把对agent的上下文约束，进展到整个环境约束。给agent提供一套受控的、完善的开发环境，里面同时包含着所需的默认工具、知识（待注入的上下文）、预定义的指定、安全沙箱、hook等完善的配置。总之其核心目的，就是让agent在一个远超单纯上下文的环境中工作。
一个比较关键的核心是：让agent自主利用已有的一切，去让自身保持最佳状态。而这个最佳状态是我（约束）设计者，预先定义好的。比如让agent在合适的时候自主触发上下文压缩的hook，亦或者在执行bash命令时强制请求同意，亦或者时从最初就遵循渐进披露的原则，等等。
甚至更进一步的，当今agent时代的代码开发瓶颈已经从实现变成了审查，那我就可以在约束内部自定义一个检查机制（比如TDD导向的开发模式），让agent在最初就保证代码质量。抑或是直接在平台内部开一个agent，不断地跟进代码质量并实时基于开发agent代码质量的反馈。
具体来说，约束包括以下内容： 系统提示 工具、技能、MCP + 及其描述 捆绑基础设施（文件系统、沙盒、浏览器） 编排逻辑（子代理生成、切换、模型路由） 用于确定性执行的钩子/中间件（压缩、延续、lint 检查） The Anatomy of an Agent Harness
可以分为两个大块，对状态的管理，和对边界的管理。agent的运行在默认状况下是无状态的，那么当我需要让它开发一个新的项目时，就会变得非常有问题。因此我就需要从外部给它注入状态，上下文工程就是干这个的。但随着项目开发本身开始复杂，那我需要的就不只是让它知道干什么、怎么做、用什么做——我还需要规定它的边界。因此「约束」不只是对上下文的约束，同样还是对执行和开发的约束。
而这玩意儿做到极致就是全自动的agent，只需要「许愿」，就能带出全部想要的结果。所以想是oh-my-claudecode这样的工具，其最核心的目的就是给agent提供持久自主运行下的约束。核心模型负责提供大脑，而 Harness 则提供让其能最大化按照我想要的效果去发挥和生长的基础平台。就像一匹马，让框架带着着缰绳，让它走向我希望它去的方向。
现在比较正式的翻译叫做「驾驭工程」，这个我确实也更贴切，用合适的Harness让agent能更好的工作。我之前比较强调「自动运作」，但「人机交互」同样需要更好的缰绳。一个好的Harness确实对工作非常重要。比如我比较习惯cc，codex和gemini或者opencode也不是不能用，但就总感觉少了点什么。因为cc的Harness就目前来看，的确是用户体验比较好的一批，ide支持也齐全，最大的缺点就是闭源（当然也有开源平替，这还得感谢A\自己的误操作）。我个人也不是很喜欢厂商锁定，因此多尝试其他Harness也是有益的。如果实在不爽，直接换成开源版cc倒也可以。