面试官连Harness Engineering都问？AI Agent开发瓶颈竟不在模型！深度解析+实战案例

这个概念火起来也就最近半个月不到的事面试官就开始问了不得不说追新的速度确实有点离谱。Guide 对面试官的行为不做评价——可能人家就是想考察求职者对新概念的了解程度。只是如果换做我当面试官大概率会避开这么新的概念毕竟技术迭代太快。吐槽归吐槽既然面试已经在问了那就得搞清楚。而且退一步讲就算不为面试只要做 AI Agent 相关的工作Harness Engineering 也是绕不开的。Can.ac 做过一个实验同一个模型只换了文件编辑接口的调用方式编码基准分数从 6.7% 直接跳到 68.3%。模型没变变的是外围的那套系统。这就是 Harness Engineering 在做的事。Mitchell Hashimoto 在博客里用了这个说法他原话是”我不知道业界有没有公认的术语我自己管这叫 harness engineering”OpenAI 几天后发了一篇百万行代码的实验报告Birgitta Böckeler 在 Martin Fowler 网站上写了深度分析Anthropic 在三月份又放出了全新的多智能体架构设计。几周之内Harness 成了讨论 AI Agent 开发绕不开的概念。今天 Guide 就来系统梳理 Harness Engineering 的核心概念和工程方法帮你搞清楚决定 Agent 表现的天花板到底在哪里。本文接近 1.3w 字建议收藏通过本文你将搞懂Harness 到底是什么为什么说“你不是模型那你就是 Harness”Agent Model Harness 这个公式怎么理解和 Prompt Engineering、Context Engineering 是什么关系六层架构长什么样⭐为什么瓶颈不在模型而在 Harness同一个模型只换了接口格式分数从 6.7% 跳到 68.3%上下文用到 40% Agent 就开始变蠢⭐从零搭建 Harness 的行动清单P0/P1/P2 三个优先级按需取用。⭐一线团队实战案例附录OpenAI 三人五月百万行零手写、Anthropic 的 GAN 式三智能体架构和 context resets 交接棒策略、Stripe 每周 1300 无人值守 PR、Mitchell Hashimoto 的六步进阶。 系列阅读本文是 AI Agent 系列的一部分相关文章AI Agent 核心概念Agent Loop、Context Engineering、Tools 注册[1]Agent Skills 详解是什么怎么用和 Prompt、MCP 有什么区别[2]万字拆解 MCP附带工程实践[3]⭐️ Harness 核心概念Harness 到底是什么一句话Agent Model Harness。你不是模型那你就是 Harness。这句话是不是感觉听起来有点绝对我第一次看到也是这种感觉。不过其实这样简单的一句话反而抓住了关键。Harness 就是模型之外的一切——系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、钩子中间件、反馈回路、约束机制。模型本身只是能力的来源只有通过 Harness 把状态、工具、反馈和约束串起来它才真正变成一个 Agent。LangChain 的 Vivek Trivedi 在《The Anatomy of an Agent Harness》里把这个定义讲得很清楚先搞清楚模型负责什么剩下的系统要补什么用这条线把整个系统切开。通俗理解模型是 CPUHarness 是操作系统。CPU 再强OS 拉胯也白搭。你买了最新款 M5 芯片装了个崩溃不断的系统体验还不如老芯片配稳定的 OS。Agent Model HarnessHarness 和 Prompt/Context Engineering 是什么关系三者不是并列关系而是嵌套关系。更重要的是每一层解决的是完全不同的问题Harness 和 Prompt/Context Engineering 的关系层级解决的核心问题关注点典型工作Prompt Engineering表达——怎么写好指令塑造局部概率空间让模型听懂意图系统提示词设计、Few-shot 示例、思维链引导Context Engineering信息——给 Agent 看什么确保模型在合适的时机拿到正确且必要的事实信息上下文管理、RAG、记忆注入、Token 优化Harness Engineering执行——整个系统怎么防崩、怎么量化、怎么持续运转长链路任务中的持续正确、偏差纠正、故障恢复文件系统、沙箱、约束执行、熵管理、反馈回路Guide 的理解是简单任务里提示词最重要——你把话说清楚就行依赖外部知识的任务里上下文很关键——你得把正确的信息喂进去但在长链路、可执行、低容错的真实商业场景里Harness 才是决定成败的东西。这也是为什么一线团队的重心都放在了 Harness 上。Harness 包含哪些组件理解 Harness 的最好方式不是直接看它包含什么而是看模型做不到什么。不管大模型看起来多能干本质就是一个文本或图像、音频进、文本出的函数。模型做不到的就是 Harness 要补的模型做不到Harness 怎么补核心组件记住多轮对话历史维护对话历史每次请求时拼进上下文记忆系统执行代码、跑命令提供 Bash 代码执行环境通用执行环境获取实时信息新库版本、API 变化Web Search、MCP 工具外部知识获取操作文件和环境文件系统抽象 Git 版本控制文件系统知道自己做对了没有沙箱环境 测试工具 浏览器自动化验证闭环在长任务中保持连贯上下文压缩、记忆文件、进度追踪上下文管理通俗理解把这些“模型做不了但你希望 Agent 能做到”的事情一个个补上就得到了 Harness 的核心组件。LangChain 有一位大佬把这件事拆解为五个子系统文件系统持久化、Bash 执行通用工具、沙箱环境安全隔离、记忆机制跨会话积累、上下文压缩对抗衰减。Harness 进阶⭐️ 一个成熟的 Harness 长什么样上面对组件的理解是“缺什么补什么”的思路。但如果从系统设计的角度看一个成熟的 Harness 其实有清晰的层次结构。我在油管看到一位技术大佬分享了一个六层体系Guide 觉得这个框架把 Harness 的全貌描绘得比较完整Harness Engineering 六层架构层级名称解决什么问题关键设计L1信息边界层Agent 该知道什么、不该知道什么定义角色与目标裁剪无关信息结构化组织任务状态L2工具系统层Agent 怎么跟外部世界交互工具的选拔、调用时机、结果的提炼与反馈L3执行编排层多步骤任务怎么串起来让模型像人一样走完“理解目标 → 判断信息 → 分析 → 生成 → 检查”的完整轨道L4记忆与状态层长任务中间结果怎么管独立管理当前任务状态、中间产物和长期记忆防止系统混乱L5评估与观测层Agent 怎么知道自己做对了没有建立独立于生成过程的验证机制让 Agent 具备“自知之明”L6约束、校验与恢复层出错了怎么办预设规则拦截错误失败时API 超时、格式混乱提供重试或回滚机制通俗理解你可以把它类比成给一个新手员工搭建的完整工作环境。L1 是岗位说明书告诉 ta 该关注什么L2 是办公工具给 ta 用什么干活L3 是标准操作流程按什么步骤做事L4 是项目管理系统和笔记本怎么记住做过的事L5 是质检流程怎么检验做对了没有L6 是红线规则和应急预案什么事绝对不能做、出了事怎么补救。这个六层架构最大的价值在于——它不是简单的功能堆叠而是一个从“定义边界”到“兜底恢复”的完整闭环。附录中一线团队的实践也印证了这一点他们的做法都可以映射到这六层里。⚠️注意不要试图一开始就搭齐六层。从 L1信息边界和 L6约束与恢复入手这两层投入产出比最高。L1 决定了 Agent 知道该干什么L6 决定了它搞砸了能不能拉回来。中间的层次随着项目复杂度增长逐步补齐。为什么瓶颈不在模型而在 Harness说实话Guide 第一次看到这个结论的时候也觉得有点反直觉——不是应该等更强的模型出来就好了吗但数据确实不支持这个想法。OpenAI、Anthropic、Stripe、LangChain、Can.ac 的实验数据指向同一个结论基础设施才是瓶颈而非智能水平。常见误区很多团队一遇到 Agent 表现不好第一反应是“换更强的模型”或“调整提示词”。但 Can.ac 的实验证明同一模型只换了工具调用格式效果就能差十倍。瓶颈大概率不在模型智能水平而在 Harness 的基础设施质量。LangChain 那边也印证了这个结论他们优化了 Agent 运行环境文档组织方式、验证回路、追踪系统在 Terminal Bench 2.0 上从全球第 30 名升到第 5 名得分从 52.8% 提升到 66.5%。模型没换Harness 换了。 一个值得注意的发现LangChain 还指出了一个 model-harness 耦合问题——当前的 Agent 产品如 Claude Code、Codex是模型和 Harness 一起训练的这导致一种过拟合换了工具逻辑后模型表现会变差。他们在 Terminal Bench 2.0 排行榜上观察到Opus 在 Claude Code 中的 Harness 下的得分远低于它在其他 Harness 中的得分。结论是“the best harness for your task is not necessarily the one a model was post-trained with”——为你的任务选择 Harness 时不要被模型的默认 Harness 束缚。⭐️ 为什么上下文喂越多Agent 反而越蠢Dex Horthy 观察到一个现象168K token 的上下文窗口用到大约 40% 的时候Agent 的输出质量就开始明显下降。上下文利用率的 40% 阈值现象区间占比表现Smart Zone0 - ~40%推理聚焦、工具调用准确、代码质量高Dumb Zone超过 ~40%幻觉增多、兜圈子、格式混乱、低质量代码Anthropic 在自己的实践中也碰到了类似的问题他们叫“上下文焦虑”Sonnet 4.5 在上下文快填满时会变得犹豫倾向于提前收工——哪怕任务还没做完。光靠压缩不够他们最终的做法是直接清空上下文窗口但通过结构化的交接文档把关键状态留下来详见附录中 Anthropic 的 context resets 策略。你的目标不是给 Agent 塞更多信息而是让它在任何时候都运行在干净、相关的上下文里。一线团队的实践都围绕着“渐进式披露”和“分层管理”在做背后的原因就是这个 40% 阈值。⚠️工程视角在生产环境中监控上下文利用率是第一优先级。建议设置 40% 阈值告警——当 Agent 的上下文占用超过这个比例时就应该触发上下文压缩或任务交接。等到 Agent 已经变蠢了再处理就晚了。⭐️ 如果你要开始搭 Harness应该从哪里入手综合一线团队的实践经验详见附录Guide 梳理了一个按优先级的行动路线。说实话你不需要一开始就把所有东西都搞齐先把 P0 做了效果就会很明显。P0不用犹豫立即可以做行动为什么参考实践创建AGENTS.md并持续维护Agent 每次启动自动加载犯错就更新形成反馈循环Hashimoto 每一行对应一个历史失败案例构建自定义 Linter 修复指令错误消息里直接告诉 Agent 怎么改纠错的同时在“教”OpenAI 的 Linter 报错自带修复方法把团队知识放进仓库写在 Slack/Wiki/Docs 里的知识对 Agent 等于不存在OpenAI 以仓库为唯一事实源常见误区很多团队把AGENTS.md当成“超级 System Prompt”来写恨不得把所有规则塞进一个文件。结果上下文窗口被撑爆Agent 反而更蠢了。正确做法是像 OpenAI 一样——AGENTS.md只当目录用约 100 行详细规则放在子文档中按需加载。P1P0 做完之后可以考虑这些行动为什么参考实践分层管理上下文不要把所有东西塞进一个文件渐进式披露OpenAI AGENTS.md 当目录用约 100 行建立进度文件和功能列表JSON 格式追踪功能状态Agent 不太会乱改结构化数据Anthropic 初始化 Agent 编码 Agent 两阶段给 Agent 端到端验证能力浏览器自动化让 Agent 能像用户一样验证功能Anthropic 用 Playwright/Puppeteer MCP控制上下文利用率尽量不超过 40%增量执行Dex Horthy 的 Smart Zone / Dumb ZoneP2有余力再考虑行动为什么参考实践Agent 专业化分工每个 Agent 携带更少无关信息留在 Smart ZoneCarlini 的去重/优化/文档 Agent定期垃圾回收确保清理速度跟得上生成速度OpenAI 的后台清理 Agent可观测性集成把“性能优化”从玄学变成可度量的工作OpenAI 接入 Chrome DevTools你的 Harness 到哪个阶段了阶段特征工程师角色Level 0无 Harness直接给 Agent prompt无结构化约束手动写代码 偶尔使用 AILevel 1基础约束AGENTS.md 基础 Linter 手动测试主要写代码AI 辅助Level 2反馈回路CI/CD 集成 自动化测试 进度追踪规划 审查为主Level 3专业化 Agent多 Agent 分工 分层上下文 持久化记忆环境设计 管理为主Level 4自治循环无人值守并行化 自动化熵管理 自修复架构师 质量把关者面试准备要点Guide 把 Harness Engineering 相关的高频面试问题整理在下面方便你快速回顾基础概念问题核心回答Harness 是什么模型之外的一切——系统提示词、工具调用、文件系统、沙箱、编排逻辑、约束机制。Agent Model Harness。Harness 和 Prompt Engineering、Context Engineering 的关系嵌套关系Prompt ⊂ Context ⊂ Harness。三者分别解决表达、信息、执行三个层面的问题。为什么瓶颈不在模型而在 HarnessCan.ac 实验证明同一模型只换工具调用格式分数从 6.7% 跳到 68.3%。基础设施质量决定了模型能力的实际发挥。架构设计问题核心回答Harness 六层架构是什么L1 信息边界 → L2 工具系统 → L3 执行编排 → L4 记忆与状态 → L5 评估与观测 → L6 约束校验与恢复。从“定义边界”到“兜底恢复”的完整闭环。上下文管理有什么经验法则利用率控制在 40% 以内。超过后 Agent 质量明显下降幻觉增多、兜圈子。策略是压缩或交接不是继续塞信息。单 Agent 还是多 Agent规模决定。小项目单 Agent 够用Hashimoto 模式大项目几乎必然需要专业化分工Carlini 用 16 个并行 Agent。实战方案问题核心回答OpenAI 的 Harness 实践核心是什么五大方法论地图式文档渐进式披露、机械化约束自定义 Linter、可观测性接入、熵管理定期垃圾回收、仓库即事实源。Anthropic 如何解决上下文焦虑Context resets 策略不压缩而是启动一个全新“干净”的 Agent通过结构化交接文档恢复状态。类似重启进程解决内存泄漏。从零搭 Harness 先做什么P0创建 AGENTS.md 自定义 Linter 团队知识仓库化。投入产出比最高。还没有答案的问题Harness Engineering 是一个快速发展的领域仍有许多未解的问题。Guide 觉得了解这些“不知道”同样重要——面试时能展现你的思考深度。问题现状谁在关注棕地项目怎么改造所有公开案例全是绿地项目零方法论Böckeler比作“在从没用过静态分析的代码库上跑静态分析”。她还提出“Ambient Affordances”概念环境本身的结构特性类型系统、模块边界、框架抽象决定了 Harness 能做多好怎么验证 Agent 做对了事大家擅长“约束不做错事”但“验证做对了事”远未解决Böckeler 批评用 AI 生成的测试来验证 AI 生成的代码本质上是“用同一双眼睛检查自己的作业”——“that’s not good enough yet”AI 生成代码的长期可维护性LLM 代码经常重新实现已有功能长期效果未知Greg Brockman 提出至今无人回答Harness 该做厚还是做薄Manus 五次重写越做越简单 vs OpenAI 五个月越做越复杂场景决定通用产品追求最小化特定产品可以高度定制。而且随着模型变强已有 Harness 应该定期简化Anthropic 实测验证单 Agent 还是多 AgentHashimoto 坚持单 Agent vs Carlini 用 16 个并行 Agent规模决定小项目单 Agent 够用大项目几乎必然需要专业化绿地项目和棕地项目是软件工程里的经典比喻绿地项目Greenfield从零开始的新项目没有历史包袱。就像在一片空地上盖房 子想怎么设计都行。棕地项目Brownfield在已有代码库上改造有历史架构、技术债、遗留逻辑的约 束。就像在老旧城区搞翻新到处是管线不能随便动。OpenAI、Anthropic、Stripe、Hashimoto 这些成功案例全部是在全新项目上从零搭 Harness。但现实中绝大多数团队面对的是已经跑了多年的代码库——怎么把 Harness 入一个十年历史、没有架构约束、到处是技术债的项目目前没有任何公开方法论。结语抓住大模型时代的职业机遇AI大模型的发展不是“替代人类”而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作却催生了更多需要“技术业务”交叉能力的高端岗位。对于求职者而言想要在这波浪潮中立足不仅需要掌握Python、TensorFlow/PyTorch等技术工具更要深入理解目标行业的业务逻辑如金融的风险控制、医疗的临床需求成为“懂技术、懂业务”的复合型人才。无论是技术研发岗如算法工程师、研究员还是业务落地岗如产品经理、应用工程师大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情紧跟技术趋势就能在AI大模型时代找到属于自己的职业新蓝海。最近两年大模型发展很迅速在理论研究方面得到很大的拓展基础模型的能力也取得重大突破大模型现在正在积极探索落地的方向如果与各行各业结合起来是未来落地的一个重大研究方向大模型应用工程师年包50w属于中等水平如果想要入门大模型那现在正是最佳时机2025年Agent的元年2026年将会百花齐放相应的应用将覆盖文本视频语音图像等全模态如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享扫描下方csdn官方合作二维码获取哦给大家推荐一个大模型应用学习路线这个学习路线的具体内容如下第一节提示词工程提示词是用于与AI模型沟通交流的这一部分主要介绍基本概念和相应的实践高级的提示词工程来实现模型最佳效果以现实案例为基础进行案例讲解在企业中除了微调之外最喜欢的就是用提示词工程技术来实现模型性能的提升第二节检索增强生成RAG可能大家经常会看见RAG这个名词这个就是将向量数据库与大模型结合的技术通过外部知识来增强改进提升大模型的回答结果这一部分主要介绍RAG架构与组件从零开始搭建RAG系统生成部署RAG性能优化等第三节微调预训练之后的模型想要在具体任务上进行适配那就需要通过微调来提升模型的性能能满足定制化的需求这一部分主要介绍微调的基础模型适配技术最佳实践的案例以及资源优化等内容第四节模型部署想要把预训练或者微调之后的模型应用于生产实践那就需要部署模型部署分为云端部署和本地部署部署的过程中需要考虑硬件支持服务器性能以及对性能进行优化使用过程中的监控维护等第五节人工智能系统和项目这一部分主要介绍自主人工智能系统包括代理框架决策框架多智能体系统以及实际应用然后通过实践项目应用前面学习到的知识包括端到端的实现行业相关情景等学完上面的大模型应用技术就可以去做一些开源的项目大模型领域现在非常注重项目的落地后续可以学习一些Agent框架等内容上面的资料做了一些整理有需要的同学可以下方添加二维码获取仅供学习使用