harness、agent

🍎

harness、agent 🍎 harness、agent Modified April 22 AI Agent 真正的门槛，不是模型，而是 Harness 过去两年，大家一聊 AI 工程，第一反应总是模型、参数、推理能力、上下文长度。好像模型越强，Agent 自然就会越好用。但真正到了落地阶段，很多团队很快就会发现：问题往往不出在模型不够聪明，而出在它根本没有被放进一个能稳定工作的系统里。理解这一点，先要建立第一个认知：Agent 不是模型本身，Agent = Model + Harness。模型负责“想”，Harness 负责让它看见环境、调用工具、记住约束、执行动作、接受验证、被纠错回滚。没有 Harness，再强的模型也更像一个被关在房间里的天才，能回答问题，却很难持续干活。第二个认知是：Harness 不是某一个功能，而是一整套工程基础设施。它至少要补上裸模型的四个硬伤：没有长期记忆，不能真正执行代码，知识会过时，没有工作环境。对应地，真正可用的 Harness 通常会包含六类关键能力：文件系统、Bash 与沙箱、记忆机制、搜索与外部接口、上下文工程、编排与 Hooks。System Prompt 贯穿其中，但它只是起点，不是全部。第三个认知是：别把“能造 Agent 的框架”和“让 Agent 稳定运行的 Harness”混为一谈。很多人会把 SDK、工作流框架、多 Agent 编排工具统称为 Harness，其实不完全对。前者更像是“怎么把 Agent 造出来”，后者解决的是“Agent 进入真实环境后，怎么被管理、监督、纠错和审计”。一个系统能不能调用很多工具，不等于它就具备了企业级可用性。第四个认知是：企业真正需要的，从来不是一个更会聊天的 Agent，而是一个可控的 Agent。一旦进入生产环境，问题就会从“回答得对不对”，变成“会不会越权”“会不会跑偏”“出错能不能追溯”“失败能不能恢复”。所以 Harness Engineering 的核心，不是给 AI 加更多能力，而是让它的能力变得可控、可验证、可观测。这就引出第五个认知：真正支撑企业落地的，不是花哨功能，而是三类底层能力。第一类是上下文工程，它解决的是信息腐烂。上下文一长，模型就容易遗忘约束、忽略重点、前后矛盾，所以必须把知识结构化分发，而不是一股脑塞进去。第二类是架构约束，它解决的是边界执行。不能总指望模型“自觉守规矩”，而要用确定性的规则、测试和检查，把不该发生的事情硬拦下来。第三类是对抗混乱，它解决的是长期退化。AI 持续写代码、补文档、改结构，系统一定会慢慢变乱，所以需要专门的机制不断清理技术债和架构漂移。第六个认知是：企业级 Harness 一定离不开两个原则：检查点和人工介入。检查点决定了系统失败后能不能从中间恢复，而不是每次推倒重来；人工介入节点决定了高风险操作前，是否必须有人把关。说白了，AI 可以提速，但不能在关键环节跳过治理。第七个认知是：Vibe Coding、Spec Coding、Harness Engineering，不是互相替代，而是层层向上。 Vibe Coding 解决的是“先快速做出来”，Spec Coding 解决的是“按规格做出来”，Harness Engineering 解决的是“长期稳定地跑起来”。很多人现在用的工具，更多还停留在前两层，所以会出现一个常见现象：演示很惊艳，一上真实项目就开始失控。第八个认知是：Harness 最有价值的地方，不是概念，而是它能把软件工程常识变成 AI 必须执行的流程。这也是一些先进实践最值得借鉴的地方。真正成熟的系统，不会让 Agent 上来就开写，而是先理解需求、拆里程碑、确认策略、检查现有环境、做 Dry Run，进入执行。执行过程中，不同 Worker 用独立会话处理不同任务，交接时留下可验证的痕迹，代码审查和用户测试在关键节点自动介入。你会发现，这套东西本质上并不神秘，它只是把“需求确认、阶段验证、代码审查、用户测试、知识沉淀”这些原本依赖人自觉完成的动作，全部改造成了可执行、可检查、可回退的机制。所以，Harness Engineering 这波真正重要的变化，不是行业多了一个新名词，而是软件工程的分工在变。未来更有价值的工程师，未必是写代码最快的人，而是最会设计环境、定义规则、组织知识、设置反馈回路的人。模型当然还会继续变强，但模型越强，反而越会放大一个事实：决定 Agent 能不能真正干活的，越来越不是它会不会“想”，而是你有没有把那套让它稳定“做”的 Harness 搭出来。这版我已经尽量收成公众号可发稿了。还可以继续往两个方向再调：一个是更像爆款公众号的开头和标题，一个是更偏“认知总结”的小标题版本。 AI Agent 真正的门槛，不是模型，而是 Harness 过去两年，大家一聊 AI 工程，第一反应总是模型、参数、推理能力、上下文长度。好像模型越强，Agent 自然就会越好用。但真正到了落地阶段，很多团队很快就会发现：问题往往不出在模型不够聪明，而出在它根本没有被放进一个能稳定工作的系统里。理解这一点，先要建立第一个认知：Agent 不是模型本身，Agent = Model + Harness。模型负责“想”，Harness 负责让它看见环境、调用工具、记住约束、执行动作、接受验证、被纠错回滚。没有 Harness，再强的模型也更像一个被关在房间里的天才，能回答问题，却很难持续干活。第二个认知是：Harness 不是某一个功能，而是一整套工程基础设施。它至少要补上裸模型的四个硬伤：没有长期记忆，不能真正执行代码，知识会过时，没有工作环境。对应地，真正可用的 Harness 通常会包含六类关键能力：文件系统、Bash 与沙箱、记忆机制、搜索与外部接口、上下文工程、编排与 Hooks。System Prompt 贯穿其中，但它只是起点，不是全部。第三个认知是：别把“能造 Agent 的框架”和“让 Agent 稳定运行的 Harness”混为一谈。很多人会把 SDK、工作流框架、多 Agent 编排工具统称为 Harness，其实不完全对。前者更像是“怎么把 Agent 造出来”，后者解决的是“Agent 进入真实环境后，怎么被管理、监督、纠错和审计”。一个系统能不能调用很多工具，不等于它就具备了企业级可用性。第四个认知是：企业真正需要的，从来不是一个更会聊天的 Agent，而是一个可控的 Agent。一旦进入生产环境，问题就会从“回答得对不对”，变成“会不会越权”“会不会跑偏”“出错能不能追溯”“失败能不能恢复”。所以 Harness Engineering 的核心，不是给 AI 加更多能力，而是让它的能力变得可控、可验证、可观测。这就引出第五个认知：真正支撑企业落地的，不是花哨功能，而是三类底层能力。第一类是上下文工程，它解决的是信息腐烂。上下文一长，模型就容易遗忘约束、忽略重点、前后矛盾，所以必须把知识结构化分发，而不是一股脑塞进去。第二类是架构约束，它解决的是边界执行。不能总指望模型“自觉守规矩”，而要用确定性的规则、测试和检查，把不该发生的事情硬拦下来。第三类是对抗混乱，它解决的是长期退化。AI 持续写代码、补文档、改结构，系统一定会慢慢变乱，所以需要专门的机制不断清理技术债和架构漂移。第六个认知是：企业级 Harness 一定离不开两个原则：检查点和人工介入。检查点决定了系统失败后能不能从中间恢复，而不是每次推倒重来；人工介入节点决定了高风险操作前，是否必须有人把关。说白了，AI 可以提速，但不能在关键环节跳过治理。第七个认知是：Vibe Coding、Spec Coding、Harness Engineering，不是互相替代，而是层层向上。 Vibe Coding 解决的是“先快速做出来”，Spec Coding 解决的是“按规格做出来”，Harness Engineering 解决的是“长期稳定地跑起来”。很多人现在用的工具，更多还停留在前两层，所以会出现一个常见现象：演示很惊艳，一上真实项目就开始失控。第八个认知是：Harness 最有价值的地方，不是概念，而是它能把软件工程常识变成 AI 必须执行的流程。这也是一些先进实践最值得借鉴的地方。真正成熟的系统，不会让 Agent 上来就开写，而是先理解需求、拆里程碑、确认策略、检查现有环境、做 Dry Run，进入执行。执行过程中，不同 Worker 用独立会话处理不同任务，交接时留下可验证的痕迹，代码审查和用户测试在关键节点自动介入。你会发现，这套东西本质上并不神秘，它只是把“需求确认、阶段验证、代码审查、用户测试、知识沉淀”这些原本依赖人自觉完成的动作，全部改造成了可执行、可检查、可回退的机制。所以，Harness Engineering 这波真正重要的变化，不是行业多了一个新名词，而是软件工程的分工在变。未来更有价值的工程师，未必是写代码最快的人，而是最会设计环境、定义规则、组织知识、设置反馈回路的人。模型当然还会继续变强，但模型越强，反而越会放大一个事实：决定 Agent 能不能真正干活的，越来越不是它会不会“想”，而是你有没有把那套让它稳定“做”的 Harness 搭出来。这版我已经尽量收成公众号可发稿了。还可以继续往两个方向再调：一个是更像爆款公众号的开头和标题，一个是更偏“认知总结”的小标题版本。