最近多看几篇 Agent 文章就会反复遇到同一个词Harness。但这个词越讲越糊。有人把它理解成工具系统。有人把它理解成 Prompt 外面那层壳。也有人把它理解成多 Agent 编排、Memory、Sandbox、Hooks、Skills 这些东西的总和。这些说法都沾边但都还没有落到主要承重的地方。这两天反复读 Akshay 写的The Anatomy of an Agent Harness最有启发的地方不是又盘了一遍产品名单而是它把视角从“模型有多强”挪到了“模型外面那套系统到底在干什么”。原文信息量很大也铺得很开。我们不做逐段翻译有兴趣可以直接看原文。我们换另外一个角度来看同一个模型为什么做出来的 Agent 会差这么远。我自己的理解是Harness 是在模型和真实交付之间补上一套可运行、可恢复、可验证、可治理的软件系统。把这个问题想清楚以后Harness 不再像一个什么都能往里装的热词了。太长不看版• Harness 是包住模型的整套运行系统主循环、工具、上下文、状态、权限与错误、验证。• Prompt 管怎么表达任务Context 管模型看到什么Harness 管系统怎么跑、怎么停、怎么纠偏。• 2026 年大家都在讲 Harness因为模型能力上来之后瓶颈从“能不能答”转向“能不能稳定交付”。• 同一个模型只换 Harness不换权重结果可能差出一个量级。LangChain 只换外围基础设施就从 TerminalBench 2.0 前 30 名外拉到第 5。• 模型和 Harness 是协同演化的。Claude Code 的模型在训练阶段就把特定 Harness 放进了训练回路。• Harness 的演进方向是变薄Manus 半年内重建五次每次都在做减法。但 Harness 不会消失。• 如果一个 Agent 还不稳定值得先检查的通常是 Harness。Harness 不只是一层壳我们先把三个词分开看。•Prompt Engineering解决的是“怎么对模型说”。•Context Engineering解决的是“让模型在这一轮看到什么”。•Harness Engineering解决的是“整套系统怎么运行怎么持久化怎么验证怎么兜底”。这三层是包含关系。Prompt 更像指令。Context 更像喂给模型的工作台。Harness 更像操作系统。Akshay 引用了 Beren Millidge 2023 年的类比裸的 LLM 是一颗没有 RAM、没有磁盘、没有 I/O 的 CPU。上下文窗口充当内存外部数据库充当磁盘工具集充当设备驱动。让这台机器持续跑起来的是外面这套调度、执行、校验和保护机制。Harness 回答的是一个工程问题怎样把一个无状态、会推理的模型变成一个能持续交付结果的系统。聊天模型一旦进入真实任务场景体验有时会突然掉下去。Demo 阶段它看起来会思考、会调用几个工具已经很像回事。可一旦任务拉长另一面就会暴露出来它会忘记自己三步前做过什么工具报错后若无其事地往下走上下文越堆越脏最后产出一个“看着像完成了其实没法交付”的结果。很多时候问题出在包着模型跑的那套系统。一条主链路看懂 HarnessAkshay 生产级 Harness 拆成了 12 个组件。我们把它们压成 6 个核心结构先抓住主链路。先看一下总链路。图 1Harness 总链路六个承重层我们拆成六层来看。1. 主循环这是 Harness 的心脏。表面上看它经常只是一个 while loop组装输入调用模型解析输出执行工具把结果塞回去再来一轮。但难点在循环里每一步到底由谁控制、何时终止、出错后怎么回来。很多人第一次做 Agent会把注意力放在“模型有没有想明白”。上线以后最先暴露的反而是循环失控无限转圈、提前收尾、误把中间结果当最终结果。2. 工具系统工具是 Agent 的手。但工具系统不只是“给几个函数名”这么简单。它至少还要管四件事工具如何注册、参数如何校验、执行环境是否隔离、结果如何回写成模型能继续理解的 Observation。Akshay 举了一个对照Claude Code 把工具分成六类文件操作、搜索、执行、Web 访问、代码智能、子 Agent 派生OpenAI Agents SDK 支持函数工具、托管工具和 MCP 工具。分类方法不同但要解决的问题一样。所以同样都支持 tool calling跑出来的体验也会差很多。模型知道可以调用什么工具只是起点。它能不能在合适的时候调用、带着正确参数调用、在失败后继续恢复才是 Harness 的事情。3. 上下文与记忆这层解决的问题很具体该记什么、什么时候记、什么时候删。短期记忆是当前会话历史。长期记忆是跨会话持久化的事实、决策和索引。Claude Code 的做法是三层一个始终加载的轻量索引每条约 150 字符按需拉取的详细主题文件以及只通过搜索访问的原始会话记录。成熟系统不会把记忆当真相而是把它当线索。先靠记忆提示方向再回到真实文件、真实环境和真实状态里确认。记忆如果不能被验证就很容易从“帮助检索”滑向“帮助幻觉”。4. 状态与检查点任务一旦变长状态管理就从“有最好”变成“没有不行”。系统需要知道当前做到哪一步失败后从哪恢复哪些中间产物值得保留哪些只是临时噪音。有的系统用结构化状态对象做 checkpoint有的系统把 git commit、进度文件、任务日志一起当作恢复点。实现可以不同但目的只有一个让长任务可以继续而不是每次都从头赌一遍。5. 权限、错误与安全护栏这层常被低估但分量不小。一个看起来很能干的 Agent如果没有权限控制本质上只是一个事故放大器。稳一点的 Harness 会把“模型想做什么”和“系统允许做什么”拆开。模型负责提出动作。工具系统负责决定这个动作能不能做、要不要用户确认、失败后是重试、回传错误、还是直接终止。生产环境里的 Agent高风险动作必须有边界。6. 验证与纠偏这层才是 Demo 和生产的分水岭。工具给了模型行动能力。验证才给了模型纠错能力。更稳的做法是给模型一个外部反馈回路测试、lint、类型检查、页面截图、端到端操作甚至另一个专门负责挑刺的评估器。Claude Code 的创始人 Boris Cherny 提到给模型一种能验证自己工作的方式质量提升 2 到 3 倍。没有验证Harness 很容易变成“更快地产出错结果”。再把这条链跑一遍一次完整循环到底发生了什么只讲组件还是容易停在名词层。更贴近工程的办法是顺着一轮真实执行把它跑一遍。一套成熟的 Harness至少要把这七步串起来组装输入。把 system prompt、工具定义、记忆、会话状态、当前任务拼成这一轮实际给模型看的上下文。模型推理。模型决定这轮是直接回答还是先调工具。分类输出。如果只有文本没有 tool call这一轮可能就该结束如果有工具调用就进入执行阶段。执行工具。先做参数校验再做权限检查再决定这一步是并发读、串行改还是直接拒绝。回写结果。工具输出要重新包装成模型能继续理解的 Observation失败也不能静默吞掉而要回成一个明确错误。更新状态。会话历史、检查点、工作记忆、压缩触发条件都在这里更新。决定是否继续。要么回到下一轮要么因为任务完成、预算用尽、达到最大轮数、用户中断或安全护栏触发而终止。把这一轮压成图会更容易看见关键节点图 2一次完整 Harness 循环执行视角循环本身往往很朴素。复杂的是每一步背后的工程取舍。很多人第一次做 Agent 时会困惑循环有了怎么还是不稳多数时候有循环不等于有 Harness。为什么 2026 年突然都在讲 Harness这个词并不是今年才出现的只是今年开始被越来越正式地说出来了。模型已经强到很多团队第一次认真感受到能力不再是唯一瓶颈稳定交付开始变成更大的瓶颈。Akshay 提到两个很有代表性的信号。第一个信号是同一个模型、同一组权重只换外面的系统层表现就可能大幅跳跃。比如 LangChain 只换外围基础设施就能把名次从 TerminalBench 2.0 的前 30 名之外拉到第 5。还有研究项目把“优化 Harness”本身变成了搜索对象最终拿到了 76.4% 的通过率。这里要留一个边界榜单结果不能直接等同于真实产品体验单个实验也不能替所有场景下结论。但它至少说明一件事Agent 的表现并不只由模型上限决定还强烈依赖它跑在什么样的系统里。第二个信号是长任务的误差会快速累积。一个 10 步流程如果每一步成功率都是 99%最终全链路成功率也只有大约 90%。任务再拉长一点误差就会开始明显堆积。所以最近越来越多人开始把 Harness 叫成“战略资产”。Vercel 在 v0 上删掉了 80% 的工具表现反而更好。Claude Code 靠懒加载实现了 95% 的上下文缩减。这些数字说的是同一件事Harness 设计的重心在精简。因为到了这个阶段它在直接决定 Agent 能不能被稳定交付、能不能被团队持续复用。回头看2024 年大家还在卷 Prompt2025 年开始补 Context到了 2026 年讨论慢慢收到了 Harness。因为把系统拉垮的越来越是这些更工程的问题• 上下文会不会逐轮变脏。• 工具失败后有没有显式反馈。• 状态能不能跨会话延续。• 高风险动作有没有权限边界。• 结果到底由谁验收。模型智力在线之后大家开始重新面对软件工程。只不过这次面对的是一个会推理、会调用工具、还会不断消耗上下文预算的新型系统。原文里有一个容易被忽略的观点模型和 Harness 是协同演化的。Claude Code 的模型在训练阶段就把特定的 Harness 放进了训练回路换一套工具实现反而可能让表现下降。换个角度看怎么设计 Harness反过来也在影响模型该往哪个方向训。从设计模式到 Harness问题其实没变如果只盯着 2026 年的几个产品很容易把 Harness 看成一个新名词。但把时间拉长一点它更像软件工程演进里很自然的一步。把这条线压短一点大概是这样• 设计模式解决的是对象协作的复杂性• 分层架构和 DDD解决的是企业业务和系统边界的复杂性• 微服务和云解决的是分布式通信和运维的复杂性• 到了今天Harness 解决的是一个会推理、会执行、还会不断消耗上下文预算的系统复杂性图 3软件工程复杂性中心的迁移对象一直在变。但问题其实没怎么变。软件工程过去 30 年反复在做的都是同一件事把复杂系统变成可控系统。所以 Harness 让工程师觉得熟悉不是巧合。有点是旧瓶装新酒的感觉。它是复杂性继续外溢之后软件工程在 Agent 时代长出来的新接口。从这个角度看Harness 有价值的地方也不只是它让模型更能干。它让系统重新变得可设计、可治理、可拆边界。难点在取舍不在堆组件Akshay 后面讲到设计取舍那段我反复看了几遍。Harness 确实更像一组持续要做的架构取舍没有标准答案。这里面至少有几类问题每一类都没有放之四海而皆准的答案。图 4Harness 设计里的几组取舍单 Agent 还是多 Agent一个常见误区是一上来就上多 Agent。但多 Agent 从来不是白拿的收益。它会带来额外路由开销、上下文损失、角色边界设计和更多失败点。更稳的顺序通常是先把单 Agent 做通再把明显超载的职责拆出去。ReAct 还是 Plan-and-ExecuteReAct 的优点是灵活边想边做。Plan-and-Execute 的优点是稳定先把路线摊开再逐段执行。前者更像即兴驾驶。后者更像先画施工图再开工。任务越长、代价越高、回滚越麻烦越值得把计划层显式拿出来。上下文到底怎么管很多团队做 Context Management 时默认思路是“窗口大一点就好了”。但窗口变大不代表中间位置的信息就更容易被利用。成熟系统关心的是信号密度哪些信息必须常驻哪些信息只在需要时检索哪些旧 Observation 应该折叠哪些总结必须进入长期记忆。验证交给谁让生成器自己验自己速度很快。问题是它通常也最容易放过自己。所以只要任务一旦碰到代码、页面、部署、数据写入这些“能真测”的地方外部验证几乎都是值得补上的。Harness 到底要多厚我自己想得最久的是这个问题。Harness 太薄很多稳定性问题只能靠模型自觉。Harness 太厚系统会变得笨重、昂贵而且和当前模型强绑定模型一升级很多脚手架可能反而成了负担。所以好的 Harness 要一边补承重结构一边等待模型进步后再把不再承重的部分删掉。Akshay提到Manus 半年内重建了五次每次重写都在做减法。从最小可用开始搭如果今天从零开始搭我觉得更稳的方式是先把几件关键的事做好。单 Agent 主链路先做稳先让一条最短链路跑通用户任务进入后模型能稳定决定何时调用工具工具结果能正确回写出现失败时不会默默跳过任务结束条件明确。没有这条主链路后面加再多记忆、子代理和编排都不太稳。工具数量收紧工具不是越多越好。工具一多模型的选择成本、误调用概率和上下文负担都会一起上升。Akshay提到当工具数超过 10 个且职责重叠时模型的调用质量会明显下降。如果不是明确必要更稳的做法是只暴露当前步骤会用到的最小工具集。记忆是提示不是事实长期记忆要有但不要让它越权。它适合先做索引、摘要和决策记录。关键动作之前系统仍然要回到真实文件和真实环境里做二次确认。验证尽早外移能写测试就别只写总结。能跑页面就别只看文字描述。能让 lint、类型检查、截图或真实 API 响应说话就别只让模型自己评价“应该没问题”。状态和恢复点要显式写下来长任务一定会失败。所以系统设计时不该先假设它不会失败而该先假设它必然会在中途被打断、跑偏、超时或遇到工具异常。有检查点失败是恢复问题。没检查点失败就会重新变成运气问题。高风险动作要从“能力”里拆出来删除、外发、部署、联网写入、批量修改这些动作都不该默认和普通读操作一样。模型可以提出动作。系统必须决定边界。这一步看起来保守实际上是在给整个 Harness 留出能上线的空间。AGENTS.md、Spec、Skills 也是 Harness 的一部分这段时间写下来有一个观察越来越清晰很多人以为 Harness 只是 Runtime其实不是。Harness 真正吃力的地方往往是那些把团队经验外移成工件的层。我越来越觉得AGENTS.md、Spec、Skills 不只是“辅助材料”。它们解决的是同一个问题尽量缩小“必须靠模型临场发挥”的面积。AGENTS.md管的是仓库默认答案这一层回答的是• 这个仓库怎么读• 哪些规则先于当前任务• 哪些入口才是标准入口• 改哪些东西必须联动哪些检查它把团队在仓库层面的默认规则先写出来。Spec 管的是任务完成标准这一层回答的是• 这次到底要交付什么• 哪些边界不能越• 什么叫“做完了”• 哪些验收条件必须先对齐它是任务层的上下文管理层。Skills 管的是可复用操作规程这一层回答的是• 这类问题以后通常怎么做• 哪些步骤是高频而稳定的• 哪些检查和脚手架值得复用• 哪些经验不该每次都重新口头讲一遍如果说AGENTS.md更像仓库地图Spec 更像本轮任务契约那 Skills 更像团队沉淀下来的程序性记忆。把这三层和 Runtime 放在一起看会更清楚图 5团队经验如何进入 Harness它们合起来在做同一件事• 把知识从聊天记录里搬出来• 把规则从 review 口头提醒里搬出来• 把经验从某个资深工程师脑子里搬出来• 把验证从“我觉得差不多”搬到系统动作里前几天整理的AI-First文章里有个观点也能和 Harness 这条线接上门槛在于软件工程能不能被改造成对 Agent 可见、可验证、可执行的系统。从这个角度看Harness 更像 AI 时代的软件工程接口。回到系统层原文里有一句话我很喜欢大意是如果你不是模型你就在做 Harness。这句话的分量其实比看上去大很多。因为它把注意力从“怎么把模型哄好”重新拉回到了“怎么把系统搭对”。Agent 当然在进步。模型也还会继续变强。但只要系统还需要上下文管理、工具执行、状态持久化、错误恢复、权限控制和外部验证Harness 就不会消失。它可能会变薄。它不会变得不重要。当一个 Agent 又开始跑偏我现在的习惯是先看一眼 Harness。很多问题其实就藏在那一层。AI行业迎来前所未有的爆发式增长从DeepSeek百万年薪招聘AI研究员到百度、阿里、腾讯等大厂疯狂布局AI Agent再到国家政策大力扶持数字经济和AI人才培养所有信号都在告诉我们AI的黄金十年真的来了在行业火爆之下AI人才争夺战也日趋白热化其就业前景一片蓝海我给大家准备了一份全套的《AI大模型零基础入门进阶学习资源包》包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。有需要的小伙伴可以V扫描下方二维码免费领取人才缺口巨大人力资源社会保障部有关报告显示据测算当前****我国人工智能人才缺口超过500万****供求比例达1∶10。脉脉最新数据也显示AI新发岗位量较去年初暴增29倍超1000家AI企业释放7.2万岗位……单拿今年的秋招来说各互联网大厂释放出来的招聘信息中我们就能感受到AI浪潮比如百度90%的技术岗都与AI相关就业薪资超高在旺盛的市场需求下AI岗位不仅招聘量大薪资待遇更是“一骑绝尘”。企业为抢AI核心人才薪资给的非常慷慨过去一年懂AI的人才普遍涨薪40%脉脉高聘发布的《2025年度人才迁徙报告》显示在2025年1月-10月的高薪岗位Top20排行中AI相关岗位占了绝大多数并且平均薪资月薪都超过6w在去年的秋招中小红书给算法相关岗位的薪资为50k起字节开出228万元的超高年薪据《2025年秋季校园招聘白皮书》AI算法类平均年薪达36.9万遥遥领先其他行业总结来说当前人工智能岗位需求多薪资高前景好。在职场里选对赛道就能赢在起跑线。抓住AI风口轻松实现高薪就业但现实却是仍有很多同学不知道如何抓住AI机遇会遇到很多就业难题比如❌ 技术过时只会CRUD的开发者在AI浪潮中沦为“职场裸奔者”❌ 薪资停滞初级岗位内卷到白菜价传统开发3年经验薪资涨幅不足15%❌ 转型无门想学AI却找不到系统路径83%自学党中途放弃。他们的就业难题解决问题的关键在于不仅要选对赛道更要跟对老师我给大家准备了一份全套的《AI大模型零基础入门进阶学习资源包》包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。有需要的小伙伴可以V扫描下方二维码免费领取