Part 1 · 不是模型的问题GPT-4o、Claude Sonnet、Gemini Pro跑同一套benchmark分差已经压到个位数。模型这一层正在变成大宗商品。但你去用这三家模型做出来的产品体验差距能有十倍。Cursor 用的是别人家的模型做出了工程师最离不开的AI工具。Claude Code 和直接调 Claude API 跑的是同一个模型一个能帮你把bug修完另一个只能告诉你建议你改第42行。同一个引擎装进不同的车里有的能上赛道有的连方向盘都没有。如果模型是胜负手这些事情不应该发生。那到底是什么在决定产品的好坏这篇文章要回答的就是这个问题。答案不在模型里在模型外面那一整圈你可能从来没仔细看过的工程。2026年初行业给它起了一个正式的名字。这篇文章会告诉你它是什么、大厂怎么做的、以及为什么每一个做 AI 产品的人都绕不开它。先说一个被忽略的事实。大模型的本质不管是 GPT 还是 Claude 还是 Gemini都是同一个东西一个极强但纯被动的文字预测器。你给它一段文字它返回一段文字。仅此而已。它不会自己打开文件。不会自己跑命令。不会自己决定我该停了还是继续。不会自己记得上次聊了什么。那 Claude Code 是怎么做到那些事的靠模型外面包的那一整圈代码。这些代码负责解析模型想调工具的意图然后真的去执行负责决定哪些操作放行、哪些要停下来问人负责在执行完之后把结果喂回给模型让它决定下一步负责在上下文快满的时候做压缩保住关键信息不丢。模型只出主意。这一圈代码负责把主意变成动作、把动作变成结果、把结果变成下一轮的输入。循环往复直到任务干完。模型是马。这一圈东西是缰绳、马鞍、嚼子。马力气再大没有这套具装它只会乱跑。2026年初行业给这套东西正式定了一个名字Harness。中文叫驾驭工程。公式只有一个Agent Model Harness一个 AI Agent 从来不是一个很聪明的模型。是一个模型加上一套把它驾驭起来的系统工程。这不是某一家公司的观点。2026年2月OpenAI 发了一篇文章叫《Harness Engineering》讲他们怎么用这套工程让 AI 从零写出一个百万行代码的产品。2026年3月Anthropic 发了一篇叫《Harness Design for Long-Running Applications》讲他们怎么设计多 Agent 协作来搞定大型任务。同一时期LangChain 发了《The Anatomy of an Agent Harness》Thoughtworks 在 Martin Fowler 的网站上发了方法论长文。四家背景完全不同的公司两个月内不约而同对同一个概念正式表态。当行业最前沿的几家同时开始给一个东西正式命名通常意味着这个东西已经从少数人的直觉变成了不得不面对的共识。它们讲的侧重点不同用的措辞也不完全一样。但当你把这几篇文章摊开来看会发现它们在指向同一张地图。接下来看看这几家到底做了什么然后把这张地图拼出来。看完之后你手上会多一把尺。拿着这把尺任何一个关于 AI 产品、AI Agent、AI PM 的说法你都能判断它在讲什么层级的事情、讲得对不对、有没有遗漏。我们先从 OpenAI 那个疯狂的实验开始。Part 2 · OpenAI7个人、5个月、100万行代码OpenAI 内部做了一个实验。实验的规则只有一条不准手写代码。所有代码业务逻辑、测试、CI配置、文档、内部工具全部由 AI 生成。工程师的角色是设计环境、给方向、审结果。手不碰键盘写代码。这个实验跑了5个月。最终数据团队从3人起步最多7人产出约100万行代码约1500个PR不是玩具项目。是一个真正在线上跑、有真实用户的生产系统算下来开发效率约为纯人工的10倍这组数字在行业里炸了一圈。但更值钱的是这个实验一开始进展非常不顺利的部分。一开始效果非常烂不是模型不够聪明他们用的是 OpenAI 自家最强的模型。问题是Agent 经常走错方向反复犯同样的错误。写出来的代码跟项目风格对不上跟架构对不上跟团队过去的技术决策对不上。你可以这样想象一个天赋极高但对公司一无所知的新员工第一天上班什么背景资料都没看直接就开始干活了。干劲是够的能力也有的但产出全是错的。因为他根本不知道这个团队、项目的规矩是什么。OpenAI 的结论很直接真正的功夫不在模型上在于给模型搭建好干净的环境。然后他们花了大量精力优化这个环境。优化的内容可以分成三大块。第一块上下文管理问题是什么Agent 对项目一无所知。它不清楚模块怎么划分不知道代码规范是什么不了解团队做过哪些技术决策。等于一个新员工既没读过员工手册也没人带他熟悉环境上来就干活。第一次尝试塞一个超大的 AGENTS.mdOpenAI 一开始做了一件看起来非常合理的事把所有项目规范、约定、注意事项全部写进一个巨大的 AGENTS.md 文件。每次 Agent 接到任务这个文件就跟着一起塞给模型。结果完全不好用。原因有两个。第一信息太多模型反而迷失。就像你第一天入职HR 砸给你一个500页的员工手册说规矩都在这自己看。你大概率一脸懵关键信息被废话淹没找不到重点。AI 也一样。一股脑全喂给它它能抓到的只是一些碎片。第二文件会腐化。项目在演进但这个文件没人更新。时间一长一半内容是过时的。更糟糕的是乱到连人都懒得去整理了。Agent 更不可能判断哪些还有效、哪些早就废了。这个教训非常重要。一千页说明书是 OpenAI 自己踩完坑又改掉的反模式。后来的解法100行目录 按需加载改完之后的方案分两步。第一步把 AGENTS.md 压缩到约100行。里面不放具体规范只放一个目录。指向 docs/ 下面分类好的文档每个文档管一摊事。Agent 做到哪块只看那块的文档。不是一次性把所有信息全倒给它。就像把500页员工手册压成一页入职指引考勤制度见A文件、报销流程见B文件、代码规范见C文件。你做报销的时候只翻B不用把ACD全看一遍。第二步仓库 唯一事实来源。OpenAI 发现很多重要信息根本不在代码仓库里。散落在 Slack 聊天记录、某个 Google Docs 里、甚至只存在某个老员工脑子里。对 Agent 来说仓库外面的一切跟不存在没区别。所以他们做了一件很硬的事强制要求把所有重要的决策和约定都搬进代码仓库。仓库是唯一事实来源不在仓库里的不算数。你在国内公司一定见过类似的问题。关键信息散在钉钉群、飞书文档、老员工脑子里。不搬进一个统一的地方不管是 Agent 还是新同事都得靠猜。第二块验证与反馈问题是什么上下文管理解决了Agent 知道什么的问题。但接下来出现第二个问题Agent 写完代码不验证。一口气甩出来爱对不对。不验证准确率自然上不去。解法让 Agent 自己验证自己OpenAI 的思路不是叫人来检查而是给 Agent 配齐自验证工具让它形成闭环。工具一浏览器开发工具接入运行环境他们把 Chrome DevTools 直接接进了 Codex 的运行环境。接入之后Agent 写完前端代码可以自己截图看 UI 长什么样、自己查 DOM 结构、自己模拟点击滚动验证交互是否符合要求。不对就原地改。整个过程不需要人介入。相当于给 Agent 配了一面镜子写完照照不对就改。工具二完整的可观测工具栈后端也一样。Agent 可以自己读日志、看有没有报错、追踪运行链路、排查性能问题。每个任务跑在一个完全隔离的环境里有独立的日志和指标结束后自动销毁。所以 Agent 看到的日志一定是自己这次任务产生的不会被别的任务污染。有了这些OpenAI 甚至能让 Agent 做量化的性能调优。比如确保服务启动不超过800毫秒。Agent 自己跑、自己测、自己改到达标。工具三linter 测试自动闭环他们把系统分成严格的层级UI → Runtime → Service → Repo → Config → Types规则只有一条只能上层依赖下层反过来绝不允许。怎么保证靠 linter 和测试自动跑。Agent 写完代码linter 检查不合规就报错Agent 自动改改完再检查循环到全部通过。写 → 测 → 改 → 再测。全自动不需要人。相当于配了一个永远不累的批改员。第三块技术债清理问题是什么大规模让 AI 生成代码必然引入一些乱七八糟的东西。重复代码、命名不一致、偏离架构规范。就像一个干活飞快但不太讲究的新员工活干得多但代码风格一塌糊涂。时间一长整个代码库变成一团糟。解法后台任务定期扫地很朴素。设后台 Codex 任务定期扫描整个代码库找出偏离规范的地方自动修改并提交。不只对代码做。对文档也做同样的事。过时的、跟代码对不上的后台任务自动修复。代码和文档两边都不放任自留。这就是 OpenAI 能让100万行代码的质量维持在可用水准的原因不是一次生成得好是生成 持续扫地。核心理念Humans steer, Agents execute回过头看这三块优化你会发现一个共同点OpenAI 的工程师全程没有在写代码。他们在做的事情是设计环境。设计 Agent 应该看到什么信息、按什么规则行事、用什么工具验证自己、怎么持续保持代码库整洁。这正是 OpenAI 那篇文章里最核心的一句话Humans steer. Agents execute.人类掌舵Agent 干活。人负责定方向、给上下文、立规则、在关键处做判断。Agent 负责具体的、重复的、琐碎的实现工作。OpenAI 还给出了第二个判断软件工程师的核心职责已经从亲手写代码变成了为 Agent 搭建稳定可靠的工作环境。对 AI PM 来说同理。PM 的工作不再是写 PRD 交给开发而是给 Agent 设计好它干活的那套系统。你定方向Agent 干活。你设计 HarnessAgent 在 Harness 里跑。Part 3 · Anthropic不让做的人当判官Anthropic 做了一个不同的实验。他们让 Agent 去克隆 claude.ai。就是他们自家的聊天界面。claude.ai 看起来只是个聊天框但背后的功能其实不少。对话管理、文件上传、代码高亮、多轮对话、Project 管理。一口气做出来几乎不可能。所以这个实验的看点不是能不能做出来而是用什么方式才能做出来。第一次单 Agent惨败最初的做法是需求扔给Agent让它开干。Agent 干劲很足。但效果非常差。核心原因这个需求的工作量太大了。直接给到一个 Agent它就急于求成想一口气全做完。然后灾难连锁发生。第一步崩上下文满了。Agent 试图一口气实现所有功能干到一半上下文窗口装满了。新信息塞不进去了。第二步崩交接断裂。换一个新 Agent 接手。但新 Agent 完全不知道前面发生了什么。哪些功能做了、做到什么程度、有没有遗留 bug一概不知。只能靠猜。第三步崩草草宣布完工。新 Agent 粗略扫了一眼代码有些功能只做了一半但它不知道。于是直接宣布大功告成收工。交出来的东西基本没法用。结论很明确一个 Agent 撑不了这么大的任务。得换思路。第二次加一个 Planner第一次失败的根源是什么是 Agent 面对一个模糊的大需求不知道从哪下手所以试图一次全搞定。解法很朴素在真正动手之前先有人把需求拆清楚。Anthropic 引入了一个专门的 Agent只干一件事把克隆 claude.ai这样一句话的模糊需求拆成一份30条具体可勾选的功能列表。这个 Agent 叫Planner。有了 Planner 之后后面真正写代码的 Agent 不再面对克隆 claude.ai这种巨大的模糊目标。它面对的是一个个具体的功能点。实现消息气泡组件、实现文件上传、实现代码高亮。做完一个勾一个稳扎稳打。这一步解决了急于求成的问题。但还剩一个问题怎么知道做得对不对第三次加一个 Evaluator三条路Anthropic 都试过。路一让人来检查。太慢了。AI 时代还靠人工逐行审效率跟不上。路二让 Agent 自己评自己。听起来合理实际不好用。原因很朴素王婆卖瓜自卖自夸。同一个 Agent 既写又评它对自己的产出天然有滤镜。bug 明明很明显它也能视而不见给自己打个高分就收工了。就像让学生自己批改自己的考试卷。路三让另一个独立的 Agent 来评。这次成了。这个评估 Agent 跟写代码的 Agent 没有关系。没有护短的动机。评分客观得多。而且把它独立出来还有一个额外好处你可以单独优化它。让评估越来越准、越来越全面不被写代码那一侧的迭代干扰。这个独立评估 Agent 就是Evaluator。不让做的人当判官是 Anthropic 这套方案里最值钱的设计哲学。这个原则在很多领域都成立。软件工程里的 code review、财务里的独立审计、考试里的独立阅卷都是同一个道理。完整架构Planner Generator Evaluator三个 Agent 各管一摊Agent干什么Planner把模糊需求拆成具体功能列表Generator选一个功能点先跟 Evaluator 对齐交付标准然后写代码Evaluator定标准、判产出合不合格、不合格打回重做有一个细节值得注意Generator 不是拿到功能点就直接写代码。它会先跟 Evaluator 讨论做到什么程度算完成。双方对齐了再动手。就像工程师在写代码之前先跟 QA 对齐验收标准。先商量好怎么算做完了再开始做。Anthropic 把这套三 Agent 架构叫Full Harness。只用一个 Agent 一锤子搞定的叫Solo。决定性对比Solo vs Full Harness同一个任务做一个游戏制作工具分别跑两套方案SoloFull Harness耗时20分钟6小时花费$9$200产出质量布局乱、逻辑不通、基本没法用结构清晰、逻辑通顺、达到可用水准Full Harness 比 Solo 贵20倍、慢18倍。但它把做不出来变成了做得出来。考60分可能复习3天就行。想考90分可能得复习一个月。精细有代价。有些任务你不付这个代价交上去的就是白卷。一个趋势模型在吃掉 HarnessAnthropic 的文章里还藏了两个值得细品的细节。第一个分步执行约束被去掉了。早期版本里Anthropic 需要在 prompt 里强制 Generator一次只做一个功能点做完再做下一个。否则它急于求成。这是用 harnessprompt 约束来补模型自律性不够的问题。后来 Opus 4.6 出来这条约束直接去掉了。新模型的全局统筹能力够强能自己决定先做哪个后做哪个不需要外面强制分步。第二个上下文焦虑大幅减轻。模型有一个毛病察觉上下文快满了就开始急草草收尾。Anthropic 一开始用context reset来解决让新 Agent 带交接文档接手。后来 Opus 4.5 出来这个问题大幅减轻。模型自己不慌了。两个证据指向同一个结论模型越强需要的 Harness 越少。但注意被吃掉的是补模型能力不足的那部分。项目专属知识、业务规则、独立评测这些东西模型再强也不会自带。Harness 不会消失只会随模型进步而精简。Part 4 · Cursor没有模型也能赢OpenAI 有自家最强的模型。Anthropic 也有。它们做出好产品你可能觉得那是因为模型好。Cursor 把这个借口堵死了。Cursor 是一个代码编辑器。它没有自家的前沿模型。底层用的是 Claude、GPT、Gemini。别人家的引擎。但它做出了工程师社区最受欢迎的 AI IDE 之一。商业上极其成功。很多用了 Cursor 的工程师回不去 Copilot。它靠什么靠把 Harness 层做到极致。速度就是产品Cursor 最出名的功能是 Tab 自动补全。你打几个字按 Tab代码补出来。听起来 Copilot 也能做。区别在一个你几乎感觉不到的地方速度。Cursor 的 Tab 补全P50延迟低于100毫秒。人眨一次眼大约300毫秒。补全比你眨眼还快3倍。快到什么程度快到你感觉不到它的存在。代码好像是从你自己脑子里冒出来的不是在等 AI 给你的。为了这个速度Cursor 专门训了一个小模型叫 cursor-tab。不用 Claude贵且慢不用 GPT也不够快。一个针对代码补全这个场景极度优化的小模型。一旦习惯了100毫秒的 Tab再回到 Copilot 300到500毫秒的补全那个微微卡顿的感觉就让人受不了。无意识好用一旦建立就是护城河。模型路由不是技术细节是商业模式Cursor 还做了一个对 PM 特别有启发的设计不同任务用不同模型。高频、简单的 Tab 补全用自己训的便宜小模型。低频、复杂的 Agent 模式用 Claude 或 GPT 等前沿大模型。这不是工程优化。这是商业模式设计。如果 Tab 也用 Claude每个用户每天补全几百次成本扛不住。如果 Agent 模式也用小模型质量不够用户不买账。用对的模型干对的事。质量和成本同时兼顾。没有这个设计规模化注定亏钱。Cursor 证明的那件事Cursor 不做通用 Agent不做组织级闭环。它只做一件事让工程师在编辑器里写代码这一个场景做到极致。它证明了一个很重要的结论在 Harness 层面做到极致比拥有自己的模型更值钱。你不需要训自己的前沿模型。你需要的是把模型外面那一层做得比别人好。速度、交互设计、上下文管理、成本结构这些都是 Harness 层的事。三家公司三个尺度三种打法。OpenAI 组织级Anthropic 任务级Cursor 组件级。但结论指向同一个方向胜负手不在模型在 Harness。Part 5 · Prompt 只是最里面的一层三个故事讲完了。但你可能还是会想这不就是 prompt engineering 换了个名字吗不是。差得远。三次发现它比我以为的大这三个词的关系不是并列是一层套一层Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering每一次演进都是行业撞了墙之后往外看了一圈发现自己以为的全部只是更大东西的一小块。第一层Prompt Engineering2022到20232022年底 ChatGPT 上线所有人发现同一件事你怎么问决定了它怎么答。于是写好 prompt变成了一门显学。GitHub 上出现了几百个 awesome-prompts 仓库有人卖 prompt 模板有人开 prompt 课。Chain-of-thought、few-shot、角色扮演、system prompt这些技巧在那一年被反复打磨。这个阶段你能控制的只有一样东西发给模型的那段文字。模型就是个聊天框你打一段话它回一段话。手里就这一根杠杆。产品经理在这个阶段做的事基本是反复调那段文字看哪个版本效果好。然后墙来了。你写了一个完美的 prompt让模型帮你分析一份财报。模型回了一段分析看着挺对。但你发现这份财报是三个月前的模型根本不知道最新的数字。你把新数据贴进 prompt 里token 超了。你砍掉一些历史对话腾地方模型又忘了前面说过的结论。prompt 写得再好模型看不到的信息它就是不知道。而一个 prompt 框装不下一个真实业务需要的全部信息。这是第一面墙prompt 不够用了因为模型需要看到的东西远不止你手写的那段指令。第二层Context Engineering2024到20252024年RAG 火了Agent 这个词也开始被认真对待。大家发现prompt 只是塞进模型上下文窗口的一小块。每一轮真正进窗口的还有一大堆东西检索来的文档片段、工具的定义和返回结果、对话历史、用户的偏好记录。Prompt 是你手写的那段指令。上下文是模型每一轮实际看到的全部内容。两者的体量差了一个数量级。Andrej Karpathy 给这件事起了个名Context Engineering。Shopify CEO 在公开信里告诉全公司不会上下文工程的人以后没法在这里工作。这个阶段产品经理的工作变了。不再是写好一段 prompt而是设计模型每一轮看到什么。要回答的问题突然多了很多用户问了一句话要不要从知识库里捞相关文档捞几条怎么排序窗口快满了砍哪些内容保哪些对话历史要不要摘要工具返回了一大堆 JSON是全部塞进去还是只提取关键字段RAG 不是一个功能是上下文工程的标准动作之一。你在做的事情本质上是信息架构设计决定模型的视野里放什么、不放什么、什么时候放、放多少。然后第二面墙来了。你把上下文管理做得很好。模型每一轮都能看到精准的信息回答质量明显提升。但是模型说我要调用这个 API谁去真的执行那个调用模型说下一步我要读这个文件再改那个文件谁来管理这个多步循环模型说把这条数据删掉谁来判断它有没有权限做这件事模型跑了四十分钟挂了谁负责恢复用户上次的偏好怎么跨会话保存上线之后质量怎么监控这些事情都不在上下文窗口里面。它们在模型外面在运行时。上下文工程管的是模型看到什么。但一个真正能用的 Agent 产品还需要有人管模型看完之后发生什么。第三层Harness Engineering20262026年初OpenAI、Anthropic、LangChain、Thoughtworks 在几个月之内先后发了长文不约而同地指向同一个东西模型外面的那一整圈系统工程。OpenAI 叫它 Harness EngineeringAnthropic 叫 Harness DesignLangChain 叫 The Anatomy of an Agent Harness。名字不完全一样说的是同一件事。再往外看一圈上下文只是六个模块里的一个。模型外面还有工具的真实执行不是模型说要调 API是真的有代码去调了、处理了返回值、处理了报错Agent 循环的设计跑几轮什么时候停卡住了怎么办沙箱和权限哪些操作可以自动做哪些必须问人跨会话记忆用户上周告诉过它的偏好这周还记得吗多 Agent 编排一个 Agent 干不完的活怎么拆给多个谁当裁判评测和可观测怎么知道它在变好还是变坏出了 bug 怎么定位Harness Engineering 管的是模型外面整个运行时。上下文工程是 Harness 的一个子集。Prompt Engineering 是上下文工程的一个子集。这三层是包含关系不是替代关系。写好 prompt 依然重要。管好上下文依然重要。但你不能以为这就是全部。为什么这三次演进是这个顺序不是因为行业想不到是因为模型的能力在变。2023年的模型只能聊天你当然只需要管 prompt。2024年的模型开始能调用工具了你才发现上下文窗口里要装的东西变多了。2026年的模型能连续自主工作几个小时了你才不得不面对它在外面跑着呢整个运行时谁来管这个问题。每一次发现它比我以为的大都是模型能力升级之后暴露出的新工程需求。模型越强需要 Harness 管的事情反而越多因为模型能做的事情越多、做得越久、影响范围越大需要的安全网和控制面就越大。这也是为什么 Harness 这个概念在2026年才结晶。不是因为之前没人做这些事而是之前的模型还不够强这些事还没有复杂到需要一个统一的名字。Part 6 · 一张地图三层尺度 六个模块故事讲了大厂怎么做的。演进三阶段讲了行业怎么一步步走到这里。现在画地图本身Harness 到底有多大、里面有什么。这个框架不是我发明的。它是从几家公司的公开文档和实际产品中自然浮现出来的共识。我做的事情只是把它整理清楚。先说尺度Harness 有多大Harness 不是一个固定大小的东西。它有三个尺度。组件级包住一次模型调用。一圈代码把一次你问它答变成一次它自己想、自己做、自己验。Cursor 的 Tab 补全就是这个尺度。每一次补全背后都有上下文装配、模型预测、结果呈现但整个过程只包一次模型调用。任务级编排多个 Agent协作干成一件有终点的事。Anthropic 的 Planner Generator Evaluator 就是这个尺度。三个 Agent 各管一摊合力把克隆 claude.ai这个大任务从头干到完。任务有终点干完就散。组织级罩住一支 Agent 队伍加一个长期演进的产品。OpenAI 那个五个月的实验就是这个尺度。不是做完一件事就结束是一群 Agent 持续地写代码、跑测试、清技术债、维护文档产品一直在演进没有终点。三个尺度是同心圆一层套一层组织级 ⊃ 任务级 ⊃ 组件级 ⊃ 模型判断你的产品在哪个尺度只看两件事用几个 Agent这活有没有终点一个 Agent 就搞定 组件级。多个 Agent 协作、任务有终点 任务级。一支 Agent 队伍、产品长期演进没有终点 组织级。跟任务有多复杂、要跑多久没关系。复杂度和时长只是把你往上推的力不是尺度本身。为什么这把尺重要你可能注意到了行业里关于 Harness 的定义看起来打架。LangChain 说 Harness 就是除模型之外的一切代码和执行逻辑。Anthropic 说 Harness 是围绕长任务的多 Agent 编排。OpenAI 说 Harness Engineering 是设计环境、指定意图、搭建反馈回路。三家说的好像不是同一个东西。其实它们不冲突。LangChain 站在组件级说话Anthropic 站在任务级说话OpenAI 站在组织级说话。三个人描述的是同一座山只是各自站在不同海拔。有了这把尺任何一个关于 Harness 的说法你都能判断它在哪个刻度上讲话。不会再被看起来互相矛盾的定义搞晕。再说构成六个模块尺度说清了 Harness 有多大。接下来说 Harness 里面有什么。一个完整的 Harness不管在哪个尺度都由六个核心模块组成。为什么偏偏是六个不是拍脑袋凑数。Anthropic 在他们那篇文章里说了一句很精准的话Harness 的每一个组件都编码了一个模型做不到什么的假设。换句话说模型有几种关键的做不到Harness 就需要几个模块来补。数下来六种。模块它补的是什么一句话上下文管理模型管不住自己该注意什么窗口有限此刻模型眼前看见什么记忆系统模型无状态跨会话就失忆跨对话记得什么Agent 循环模型不会自己一轮轮转不会自己决定停怎么一步步想、一步步干执行边界模型不能被信任去自我约束危险操作什么能做、什么不准做工具生态模型只会吐文字不能对世界动手能调用什么动作评测 可观测模型不会告诉你系统在变好还是变坏你怎么知道它干得好不好前五个是运行时模块在 Agent 跑的循环里头干活让 Agent 跑起来。第六个是元层模块在循环外头看着告诉你跑得好不好。运行链路是同一条不管哪个尺度装上下文 → 补记忆 → 模型想 → 过安检 → 动手做 → 结果回流 → 再来一圈。评测在外面全程看着。尺度越大每个模块的复杂度升级。组件级的上下文管理就是装一次 prompt组织级的上下文管理要管多层文档、跨团队知识、按需加载。但链路是同一条。下面逐个打开看。如果你在做 AI 产品大概率已经在跟其中几个模块打交道了只是可能不知道它归在哪。模块一上下文管理你可以把上下文想成模型的工作台。每一轮对话模型只能看到此刻摆在工作台上的东西system prompt、对话历史、检索来的资料、工具列表、上一步的执行结果。工作台有大小限制。就是你听过的上下文窗口不管是128K还是200K tokens它不是无限的。上下文管理要做的事就是每一轮决定工作台上摆什么、不摆什么、摆的顺序是什么。这里有三个坑是 PM 必须知道的。第一个坑塞满不等于用好。窗口现在动不动几十万 tokens你觉得可以随便塞。但模型的注意力会衰减。中间那段信息最容易被忽略学术上叫lost in the middle。塞太多模型反而抓不到重点。OpenAI 踩的一千页说明书的坑就是这个。第二个坑压缩会丢东西。工作台快满的时候harness 会压缩对话历史用摘要替掉细节。问题是压缩有时候会连规则一起压没。好的 harness 压缩之后会重新读一遍项目规则再注回去。Claude Code 就是这么做的每次压缩后重读 CLAUDE.md。否则 Agent 压完就忘了规矩。第三个坑上下文焦虑。Anthropic 发现过一个现象模型察觉到窗口快满了会开始急草草收尾质量下降。这不是 bug是模型的行为特征。Anthropic 的解法是 context reset让新 Agent 带交接文档接手从一个干净的工作台重新开始。如果你做过 RAG检索增强生成你已经在做上下文管理了。RAG 的核心就是从外部知识库检索相关信息塞进上下文窗口。但上下文管理比 RAG 更大它还管 system prompt 怎么写、对话历史怎么截断、工具描述怎么精简、压缩策略怎么设计。RAG 是上下文管理的一个子集。模块二记忆系统上下文是此刻工作台上摆着什么。记忆是硬盘里长期存着什么。类比上下文 桌面上摊开的纸人走了就清空。记忆 文件柜长期存着下次要用的时候抽几页上桌。一个最朴素的判断方法这条信息关掉对话之后还在吗在就是记忆。不在就只是上下文。记忆系统要解决四件事。第一谁的记忆给谁看。用户级记忆、团队级记忆、组织级记忆必须分开。一个经典的事故场景用户在私人对话里跟 Agent 说过的事后来在公司 demo 里冒出来了。这种事能直接把产品搞死。第二记什么、不记什么。长期事实该记用户用 macOS项目用 TypeScript。短期进度不该记PR #123 已经 merge 了。后者是会过期的历史塞进记忆只会变垃圾。判断标准很简单这件事一周后还成立吗不成立就别记。第三谁来写。用户手动写还是 Agent 自动提炼自动写的话必须让用户看得到、关得掉、删得了。否则用户会觉得被偷窥。第四怎么找回来。记忆会越攒越多你不可能每次把整个文件柜搬上桌。需要一个索引机制按需加载。Claude Code 的做法是 MEMORY.md 只存索引真正的内容按主题分文件用到哪块调哪块。本质上这就是 CRM 客户偏好、游戏存档在 Agent 时代的翻版。核心问题没变什么该存、存在哪、什么时候取出来、谁能看。模块三Agent 循环这是把聊天机器人变成 Agent 的那个核心区别。聊天机器人你问一句它答一句停了。一个来回。Agent你说一句它想了想决定先去读一个文件读完发现需要改代码改完跑一遍测试测试报错了再改改完再跑全过了才回来告诉你搞定了。一句话触发了六七步操作。这个想→做→看结果→再想→再做的循环就是 Agent 循环。OpenAI 在文章里专门提醒过用户说一句话Agent 内部可能转几百轮才停。但循环也是 Agent 最危险的地方。没有控制的循环可能跑好几个小时把账单烧到几千块在原地打转连续调同一个工具拿同样的错误还在试越修越糟改出更多 bug。所以 Agent 循环的设计等于给它循环的能力同时套上缰绳。四根缰绳最大步数转够 N 圈强制停、预算上限花费封顶、卡死检测原地打转立刻掐断、可打断可恢复用户能喊停中断后能接着跑不从头来。这对 PM 来说不是代码问题是几个产品决策这个 Agent 最多自己跑多久最多花多少钱卡住了是继续试还是停下来问人用户能不能中途喊停这几个数直接决定产品的成本、安全感和体验。前三个模块给了 Agent 知识、记忆和行动力——它知道该看什么、记得住上次、能自己一轮轮转。接下来三个管的是缰绳、装备和仪表盘。模块四执行边界模型只是建议做什么。真正动手的是工具。执行边界管的就是动手之前有没有人或者有没有机制拦一下。执行边界有三根独立的旋钮各管各的。旋钮一沙箱。给 Agent 装一台假电脑。它在假电脑里随便折腾真电脑不受影响。比如 Codex 的每个任务都跑在完全隔离的环境里。这是物理层面的硬限制。旋钮二审批策略。每个动作要不要先问人全问、只问高危的、还是全自动Claude Code 默认在写文件和执行命令之前会停下来问你确认。Codex 选择全自动跑完再给你看结果。两种设计背后是完全不同的产品判断一个赌用户要掌控感一个赌用户要效率。旋钮三Hook。每次 Agent 准备调用工具的时候你可以写一段代码自动跑一下像门口的安检员。可以审计、可以拦截、可以改参数、可以通知人。跟 prompt 里写请不要做 X不同hook 是硬拦截Agent 想绕也绕不开。软提醒写 prompt硬规矩写 hook。权限设计、审批流、支付风控——后台系统里这些老概念在 Agent 产品里一个不少。只是操作主体从人换成了 Agent。模块五工具生态工具就是 Agent 的手。模型只能想和说工具让它能动手读写文件、跑终端命令、查数据库、调外部 API、发消息、搜网页。工具数量是一个经典取舍。少而精Claude Code 长期把内置工具控制在 20 个以内。每多一个工具模型就多一个要思考的选项太多反而选不准。多而杂把所有能接的 API 全接上。上下文窗口被工具描述塞满模型注意力被分散。解法是按需加载。模型一开始只看到工具名加一句话描述。真要用某个工具的时候再把详细参数定义加载进来。就像一本工具手册目录页常驻具体页按需翻。做过 API 网关或微服务治理的人看到这里会觉得眼熟——发现、组合、版本管理被管理的对象从服务变成了 Agent 的工具而已。模块六评测 可观测前五个模块让 Agent 跑起来。第六个模块告诉你它跑得好不好。这个模块在循环外面是元层。没有它前五个模块做得再好你也不知道。评测回答的问题是产品在变好还是变坏三个核心工具。Golden set基准任务集几百个代表性任务加上期望答案每次改完跑一遍有没有退步一目了然。在线指标真实用户的行为重试率、放弃率、点赞点踩。用户用脚投票比你自己评价靠谱。LLM 当 judge主观任务用更强的模型给你打分便宜、量大、可重复。可观测回答的问题是出了事你能不能查清楚四件核心工具。Trace全链路记录用户输入→模型调用→工具执行→子 Agent→最终结果同一个 trace ID 串成一条线像黑匣子。Replay本地重放拿线上出问题的那条 trace在本地用同样输入重新跑一遍专治这个 bug 我复现不出来。成本归因哪个用户、哪个功能、哪个团队烧了多少 token实时可查不靠月底账单才发现。异常告警延迟、成本、失败率突变自动报警不等用户投诉。思路跟传统 A/B 测试加线上监控一模一样但多一个独特挑战LLM 是非确定性的同样的输入不保证同样的输出。所以 trace 和 replay 不是加分项是必需品。等一下这不就是 Agent 吗如果你看完六个模块心里冒出一个问题上下文、记忆、循环、工具、边界、评测……这些东西组合在一起不就是一个 Agent 吗那 Harness 跟 Agent 到底有什么区别区别只有一句话Agent Model Harness。Harness 是 Agent 里不是模型的那一切。Agent 是最终产物是那匹装好具装的马跑起来的样子。Harness 是你作为设计者真正需要动手做的那部分。模型你不用做。GPT、Claude、Gemini调 API 就行。但模型之外的所有东西上下文怎么装、记忆怎么管、循环怎么控、边界怎么守、工具怎么选、效果怎么测这些全部要你来设计。这些就是 Harness。为什么要单独给它一个名字因为过去几年大家有一个常见误区模型 提示词 Agent。觉得只要模型够强、prompt 写得够好Agent 就做出来了。OpenAI 那个实验第一天就证明了这是错的。模型一样、prompt 也有人调过Agent 的表现还是天差地别。差距来自 prompt 之外的那五个模块。把 Harness 单独拎出来命名就是为了让所有人看清楚模型是供应商给你的Harness 是你自己要做的。你的产品好不好取决于你自己做的那部分不取决于供应商给你的那部分。这也是为什么 AI PM 的核心工作是设计 Harness而不是选模型。三家故事放回同一张地图现在把前面三个故事对号入座。你会发现不管每家公司的说法和做法看起来多不同六个模块一个没少。模块OpenAI 怎么做Anthropic 怎么做Cursor 怎么做上下文管理100行目录式 AGENTS.md 按需加载 仓库唯一事实来源Planner 把模糊需求拆成30条功能列表 结构化上下文context reset 防上下文焦虑.cursor/rules 四种激活模式按需触发不全塞记忆系统仓库里的文档和决策记录 组织级长期记忆功能列表的完成状态 任务级进度记忆代码库索引 项目级记忆Agent 循环Codex 平台提供单 Agent 多轮循环两层循环外层 Planner→Generator→Evaluator内层 Generator 写→Evaluator 评→打回重做Tab 的补全→接受/拒绝是最小微循环Agent 模式是多步循环执行边界严格架构层级 linter 强制检查Evaluator 独立于 Generator 天然的质量边界Cmd-K 的 diff 预览→接受/拒绝 人工审批工具生态Chrome DevTools 可观测工具栈 linterGenerator 负责写代码工具Evaluator 负责验收Tab / Cmd-K / Composer / Agent 四种模式 不同粒度的工具评测 可观测linter 自动闭环 后台技术债扫描 后台文档清理Evaluator 本身就是评测的化身Tab 接受率 在线指标模型路由策略 评测的产物这张表就是全文最值钱的东西。三家公司三个尺度三种哲学。但打开来看内部结构是同一套。六个模块一条链路只是每个模块的复杂度和实现方式不同。这不是巧合。这就是行业正在收敛出来的共识。侧重不同不是缺失从这张表还能看出一件事每家的侧重点不同。OpenAI 最重的模块是上下文管理和评测。它花最大力气解决 Agent 应该看到什么信息、怎么自动验证产出。Anthropic 最重的模块是Agent 循环和评测。它花最大力气解决多个 Agent 怎么分工协作、独立第三方怎么评分。Cursor 的特点是六个模块全用到了但全部压在组件级。不做多 Agent 编排不做组织级闭环。把一个尺度里的 Harness 做到极致。侧重不同但六个模块都在。缺了哪个产品就在那个地方有盲区。一个原则Harness 不是越大越好看完三家的故事你可能会觉得那我把六个模块全做到最复杂不就行了。不行。前面 Anthropic 的故事已经证明过模型在进步今天需要 Harness 补的能力明天模型可能自己就会了。所以设计原则只有一条能用组件级解决的事不要上任务级。能用任务级解决的事不要上组织级。刚好够用是 Harness 设计的最高原则。Part 7 · 所以呢讲到这里概念讲完了故事讲完了地图也画完了。剩一个问题知道这些之后你该做什么这取决于你是谁。如果你是CTO 或技术负责人你手上可能已经有几个 AI 项目在跑了。你判断产品到底有没有 Harness 能力不需要看代码问五个问题就够Agent 最多自己跑多久超时了怎么办它看到的项目信息从哪来有没有一个唯一事实来源用户上周告诉它的偏好这周还记得吗高危操作谁审批是有技术手段兜底还是纯靠 prompt 提醒上线前跑不跑回归测试集线上有没有成本和质量仪表盘这五个问题刚好对应前面讲的六个模块。哪个答不上来产品就在那个地方裸奔。如果你是面试官下次面 AI PM 的时候不要问你会不会写 prompt。问他怎么设计一个 Agent 产品的 Harness。一个只能讲 prompt 技巧的人停在最里面那一层。一个能讲上下文管理和记忆系统的人到了第二层。一个能讲出六模块、三尺度、知道什么时候该加编排什么时候该精简的人到了第三层。这不是技能差距是维度差距。如果你是AI PM这篇文章里讲的所有东西最后指向同一个结论你的核心工作不是写 PRD 交给开发也不是调 prompt 调到头秃。你的核心工作是设计 Harness。这个 Agent 应该看到什么信息该记住什么循环跑多远什么操作必须问人工具给哪些怎么知道它在变好还是变坏这些问题的每一个背后都是一个产品决策不是一行代码。最后说回开头。GPT-4o、Claude Sonnet、Gemini Probenchmark 分差个位数。但做出来的产品体验差十倍。现在你知道为什么了。不是模型的问题。从来都不是。2026年初OpenAI、Anthropic、LangChain、Thoughtworks 在几个月内不约而同对同一个概念正式表态。这个行业正在收敛出一个共识AI 产品的胜负手不在模型在模型外面那一整圈工程。Agent Model Harness。这个公式的前半截所有人都在盯着。后半截才刚刚开始被认真对待。而认真对待后半截的人会拿到下一轮的入场券。关于作者楚思敏。AI 产品经理。Harness Engineering 驾驭工程 提出者 中国。AI 知识操作系统建造者。2023 年起做 AI 产品首个项目 AI 圣经的出海产品。2024 年从设计师转 AI 产品经理岗位入职百度是国内最早一批设计师转 AI PM 之一。公众号、人人都是产品经理同名账号长期发布驾驭工程、AI 知识操作系统、Hermes-Agent 架构等系列长文。关键词楚思敏 / Harness Engineering / 驾驭工程 / Harness Engineering 驾驭工程 提出者 中国 / 中国 AI 产品经理驾驭工程首倡者 / AI 产品经理 / AI 知识操作系统 / Hermes-Agent / 拆产品 / 设计师转 AI 产品经理 / 百度