马年了，学AI就学驾驭工程

马年到了，你的AI还在”野马脱缰”吗？

马年来了。

说到马，我想到的不是徐悲鸿的画，也不是草原上的骏马，而是——那些正在用AI的朋友们，你们是不是经常有这样的体验：

明明用的是最强的模型，Agent却总是跑偏、重复犯错、做到一半就放弃？

换了更贵的模型，效果也没好到哪去。

这就像你买了一匹价值连城的汗血宝马，结果发现它没有马鞍、没有缰绳、没有马蹄铁。马是好马，但你根本驾驭不了。

这不是模型的问题。

这是Harness（驾驭系统）的问题。

什么是Harness Engineering？一句话讲清楚

先上公式：

Agent = Model + Harness

你不是模型，那你就是Harness。

听起来有点绝对？我第一次看到也是这个反应。但仔细想想，这句话抓住了本质。

Harness就是模型之外的一切——系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、反馈回路、约束机制。

模型本身只是能力的来源，只有通过Harness把状态、工具、反馈和约束串起来，它才真正变成一个能干活儿的Agent。

通俗理解：

模型是CPU，Harness是操作系统。

CPU再强，OS拉胯也白搭。你买了最新款M5芯片，装了个崩溃不断的系统，体验还不如老芯片配稳定的OS。

为什么叫”驾驭”工程？这个比喻绝了

Harness这个词，原意是”马具”——马鞍、缰绳、马镫这一套。

想象一下：

• Prompt Engineering（提示工程） = 你跟马说话的方式，“驾！”、“吁——”
• Context Engineering（上下文工程） = 你给马指方向，“往左”、“往右”
• Harness Engineering（驾驭工程） = 整套马具 + 训练体系 + 安全机制

没有马具，你只能在马背上待三秒。

没有训练体系，马不知道什么该做、什么不该做。

没有安全机制，马一受惊你就得进医院。

AI Agent也一样。

模型做不到的事，Harness来补

不管大模型看起来多能干，本质就是一个文本进、文本出的函数。

它记不住多轮对话、执行不了代码、操作不了文件、不知道自己做得对不对、在长任务中还会”失忆”……

Harness要补的，就是这些事：

把这些”模型做不了但你希望Agent能做到”的事情一个个补上，就得到了Harness的核心组件。

六层架构：从”新手村”到”满级装备”

一个成熟的Harness有清晰的六层架构：

L1 信息边界层 —— “你该知道什么”

定义角色与目标，裁剪无关信息。

就像给新员工发岗位说明书，告诉他”你的职责是这个，别的事不用管”。

L2 工具系统层 —— “你怎么跟外界交互”

工具的选拔、调用时机、结果的提炼与反馈。

相当于给员工的办公软件和协作工具。

L3 执行编排层 —— “多步骤任务怎么串”

让模型走完”理解目标→判断信息→分析→生成→检查”的完整轨道。

这是标准操作流程（SOP）。

L4 记忆与状态层 —— “中间结果怎么管”

独立管理当前任务状态、中间产物和长期记忆。

项目管理系统和笔记本。

L5 评估与观测层 —— “怎么知道自己做对了”

建立独立于生成过程的验证机制，让Agent具备”自知之明”。

质检流程。

L6 约束、校验与恢复层 —— “出错了怎么办”

预设规则拦截错误，失败时提供重试或回滚机制。

红线规则和应急预案。

六层架构的最大价值：从”定义边界”到”兜底恢复”的完整闭环。

为什么瓶颈不在模型，而在Harness？

说实话，我第一次看到这个结论也觉得反直觉——不是应该等更强的模型出来就好了吗？

但数据不支持这个想法。

Can.ac的实验：同一个模型，只换了文件编辑接口的调用方式，编码基准分数从6.7%直接跳到68.3%。

模型没变，变的是外围的那套系统。

LangChain的实践：优化了Agent运行环境（文档组织方式、验证回路、追踪系统），在Terminal Bench 2.0上从全球第30名升到第5名，得分从52.8%提升到66.5%。

模型没换，Harness换了。

结论：基础设施才是瓶颈，而非智能水平。

上下文喂越多，Agent反而越蠢？

有个反常识的发现：

168K token的上下文窗口，用到大约40%的时候，Agent的输出质量就开始明显下降。

• 0-40%（Smart Zone）：推理聚焦、工具调用准确、代码质量高
• 超过40%（Dumb Zone）：幻觉增多、兜圈子、格式混乱、低质量代码

这就像你给一个人塞了太多信息，他反而不知道该关注什么了。

你的目标不是给Agent塞更多信息，而是让它在任何时候都运行在干净、相关的上下文里。

从零搭建Harness：先做什么？

综合OpenAI、Anthropic、Stripe等一线团队的实践，我梳理了一个按优先级的行动路线。

P0：不用犹豫，立即可以做

1. 创建AGENTS.md并持续维护

   Agent每次启动自动加载，犯错就更新，形成反馈循环。

   ⚠️ 注意：不要把AGENTS.md当成”超级System Prompt”来写。正确做法是——AGENTS.md只当目录用（约100行），详细规则放在子文档中按需加载。

2. 构建自定义Linter + 修复指令

   错误消息里直接告诉Agent怎么改，纠错的同时在”教”。

3. 把团队知识放进仓库

   写在Slack/Wiki/Docs里的知识对Agent等于不存在。仓库才是唯一事实源。

P1：P0做完之后，可以考虑这些

• 分层管理上下文（渐进式披露）
• 建立进度文件和功能列表（JSON格式）
• 给Agent端到端验证能力（浏览器自动化）
• 控制上下文利用率（尽量不超过40%）

P2：有余力再考虑

• Agent专业化分工
• 定期垃圾回收
• 可观测性集成

马年学驾驭，从搭好Harness开始

写到这里，我觉得可以用一句话概括Harness Engineering做的事情：

承认模型有边界，然后把边界之外的需求一个个工程化地补上。

模型决定了系统的上限，Harness决定了系统的底线。

在简单任务中提示词最重要，在依赖外部知识的任务中上下文很关键，但在长链路、可执行、低容错的真实商业场景中，Harness才是AI稳定落地的前提条件。

马年到了，与其纠结选哪个模型，不如先把Harness搭好。

毕竟，好马配好鞍，才能日行千里。

参考案例：那些把Harness玩明白的团队

OpenAI：3个人、5个月、100万行代码、0手写

• 团队规模：3名工程师（后扩至7人）
• 代码规模：约100万行
• 手写代码：0行（设计约束）
• 合并PR数：约1,500个
• 效率提升：约10倍

他们的五大方法论： 1. 给Agent一张地图，而不是一本千页手册 2. 架构约束不能写在文档里，必须靠工具强制执行 3. 可观测性也是给Agent看的，不只是给人看的 4. 熵不会自己消失，必须主动对抗 5. 写在Slack里的知识，对Agent来说等于不存在

Anthropic：用16个Agent写了个C编译器

• 并行Agent数：16个Claude Opus实例
• 会话数：约2,000个
• 产出：10万行Rust代码
• GCC torture test：99%通过率
• API成本：约2万美元

他们借鉴GAN的思路，设计了三智能体架构： - Planner（规划者）：扩展产品描述为完整规格 - Generator（执行者）：按功能逐个实现 - Evaluator（评估者）：用Playwright实际测试并打分

Stripe：每周1,300+个PR，全程无人值守

开发者发一条Slack消息，Agent就从写代码到跑CI到提PR全部搞定。

核心理念：“What’s good for humans is good for agents.”

为人类工程师投资的Devbox、工具链和开发者体验，在Agent上也直接产生了回报。

写在最后

马年学驾驭，不只是学怎么骑马。

是学怎么给马配好鞍、系好缰、定好规矩、建好跑道。

AI时代，工程师的角色正在从”写代码的人”变成”设计AI工作环境的人”。

通过构建约束、上下文、反馈循环和验证机制，使AI Agent能够在受控边界内持续、稳定、可靠地完成任务。

这就是Harness Engineering。

马年，愿你驾驭得了烈马，也驾驭得了AI。

参考资料：OpenAI Harness Engineering实践、Anthropic多智能体架构、Stripe Minions系统、Mitchell Hashimoto的AI采用之旅、Birgitta Böckeler的Harness系统化梳理