马是AI模型，强大、快速，但自己不知道该去哪。缰绳是约束和引导系统，骑手是人类工程师
一句话总结：模型能力很强但需要一套工程实践来兑现大模型的能力，就像顶级AI明星产品Claude Code那样，充分发挥模型的价值。业界都在不约而同的实践着这套工程理念，现有有个名字叫
harnessharness设计不是一步到位的，可以借鉴业界的思想，快速开始一个起步框架，然后根据自己的真实场景驱动进行设计。
🔔对于古法编程的我的启示: 不能vibing coding放飞自我了，而是需要设计环境、明确意图、构建反馈回路，让 AI 智能体可靠地完成工作
Harness Engineering
OpenAI在2026/02提出的工程范式：工程师不再写代码，而是设计环境、明确意图、构建反馈回路，让 AI 智能体可靠地完成工作.工程师工作的重点转向了系统、架构和杠杆作用
harness是一个tool shell（工具壳），一整个壳。
现在对智能体的定义变成了
Agent = Model + Harness一个裸模型在被harness赋予状态、工具执行、反馈循环和可执行约束后，才成为agent.
AI编程的根本模式：描述意图，让系统去执行
🔔古法编程者的启示: 人类掌舵，智能体执行
从写代码变成设计环境，从当执行者变成当架构师，从自己干活变成让AI在你设计的环境（情境）里干活
把AI想象成一个新来的、能力很强的工程师。你不会扔给一个刚入职的天才工程师一句「把支付系统重构了」然后走人。你会给上下文、给边界、给验收标准。
这实现了渐进式披露：智能体从一个小而稳定的切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。与Skill有些像
人类工程师的目标也是让智能体能够直接从代码仓库推理出完整的业务领域
AI协作发展史
Prompt Engineering
一门怎么跟AI说话的技术。角色设定、few-shot示例、chain-of-thought引导,输出结果格式...
根本局限：一次性的、无上下文的、不可复用的。写了一条好prompt，换个场景就得重写。你没法把一条prompt变成一个系统。
Context Engineering
把prompt联想为短指令，但在严肃的LLM应用中，真正的工作是动态构建上下文窗口，填入相关文档、对话历史、工具定义和RAG结果。
从写一条指令变成设计一个信息包
它的局限：它解决了「给AI看什么」，没解决「AI在什么环境里运行」。你可以给AI完美的上下文，但如果没有工具去执行、没有约束去遵守、没有反馈循环来自我修正，上下文再好也只是一堆漂亮的参考资料。
上下文是有长度限制的。而AI Agent要做的一件重要事情就是选择给语言模型会看到什么内容(AI Agent筛选过的长度合适的内容)
而AI Agent帮助LLM语言模型管理它输入，让输入长度合适的事情就叫Context Engineering
上下文是稀缺资源。塞太多进去，反而挤占干活的空间。塞进去的信息越多，模型准确回忆任何单条信息的能力越差
摘要压缩
因为语言模型的输入不能太长
Agent Context Optimization(ACON)优化方式
- 通过语言模型变成摘要。
- 把工具的输出内容换成这里
曾经有个工具的输出这是一种observation masking的方法 - 结合
- 把工具的输出存到一个文件中，不让这些内容一直存在上下文里面。记忆清除再记忆重拾
- 当需要的时候再读取文件重拾记忆。
Context = 输入语言模型的部分(Prompt) + 存在磁盘中的部分 所谓的Context是AI Agent所经历过的一切事情。所以Context的一部分会被作为Prompt给到LLM
强化模型做摘要的能力
Harness Engineering
Harness Engineering是缰绳、马鞍、围栏和道路本身。不只是你对马说什么（Prompt），不只是你让马看到什么（Context），而是你给马套上的那整套装备，加上你围出来的跑道，加上跑道上的护栏和检查站。
Harness有约束、反馈和质量检查。你的CLAUDE.md是Context，你的hooks是Harness的约束层，你的CI测试 是Harness的反馈层。三者加在一起才是完整的harness，它是一种新的工程实践。
提示：CI测试 = 你把测试脚本写好，CI工具帮你自动执行它，通过CI工具如Github Action,Jenkins等执行测试脚本
AI有一种本能，收到任务后立刻开始写实现，跳过规划和设计。你不拦它，它就会用代码量掩盖设计缺陷，直到整个系统复杂到没法维护。
Harness的五个组件
指令
指令是harness最基础的一层。告诉AI：我是谁、项目长什么样（项目说明书）、有哪些规则必须遵守。
在不同工具里名字不同：Claude Code叫CLAUDE.md，Codex CLI和OpenClaw叫AGENTS.md，Cursor叫.cursorrules，Windsurf叫.windsurfrules。
本质一样：用Markdown文件把你的意图编码成AI可读的规则。
龙虾的AGENTS.md与CLAUDE.md本质上一样的
臃肿的CLAUDE.md会让Claude忽略你真正的指令。一个薄入口文件当地图，指向更深层的专业文档。需要API设计规范？指个路。需要测试策略？指个路。别把所有东西平铺在一个文件里。
CLAUDE.md变成了一个路由器或者说地图，而不再是一本说明书。采用像skill那样的渐进式披露放入上下文。
一份根CLAUDE.md的地图:
## 工作区路由规则
收到任务后，先判断工作区，再读取对应的 `CLAUDE.md` 文件。
### 关键词与工作区对应表
| 关键词 | 工作区 | 读取文件 |
| ------- | ----- | --------------------- |
| 写文章、公众号 | 公众号写作 | `/01-公众号写作/CLAUDE.md` |
| 小红书、笔记 | 小红书写作 | `/02-小红书写作/CLAUDE.md` |
| 视频脚本 | 视频创作 | `/03-视频创作/CLAUDE.md` |
| 代码、Demo | 实验项目 | `/09-实验项目/` |
### 特殊情况处理
- **任务模糊** → 询问确认
- **涉及多个工作区** → 依次读取对应文件
指令文件三原则
- 方向感而非僵化步骤。方向感让agent保留判断空间，同时不跑偏。
- 护栏优先于手册
约束反而提升生产力 与其告诉agent你应该这么做，不如告诉它你不能这么做。
- 犯错 → 记录 → 迭代的飞轮
更新CLAUDE.md: 每次纠正agent的行为，就在CLAUDE.md里加一条。日积月累，这个文件变成了团队的制度知识。
约束
反馈
记忆
编排
小结
实际搭建时不需要五个同时上。一开始只要指令（写一个CLAUDE.md）和基本的反馈（让AI跑测试）。约束在你被agent搞烦了之后自然会加。记忆在你受够了每次重复解释规则之后自然会建。编排是最后才需要的，除非你的任务确实复杂到一个agent搞不定。
