作者｜沙丘智库研究团队
来源｜沙丘社区（www.shaqiu.cn）
▎核心结论
过去半年，Harness Engineering从少数AI Coding团队的方法探索，快速进入大型企业的研发流程和Agent平台。腾讯、高德、阿里、美团等国内团队开始在存量系统重构、数据研发与复杂业务交付中建立Harness；OpenAI、Anthropic、GitHub、Spotify等海外公司则持续完善任务调度、会话恢复、沙箱隔离和跨模型运行时。
基于26项公开实践，沙丘智库形成五点判断：
第一，Harness正在成为企业Agent的控制层。它不是一个单独的框架，而是模型与真实工作环境之间的工程系统，负责上下文、状态、工具、权限、执行、验证和反馈。
第二，行业整体处于L2向L3迁移阶段。多数企业已经具备Rules、Skills、工作流和角色分工，但真正实现结果可验证、任务可恢复、全程可审计的仍是少数。持续学习与跨项目治理尚未成熟。
第三，验收能力是当前最主要的落地瓶颈。企业能否规模化使用Agent，不取决于模型生成了多少代码，而取决于系统能否证明任务完成、识别缺陷、控制风险并形成复查证据。
第四，中外企业形成了不同的实践重心。国内团队更多从存量工程、业务知识与内部流程切入；海外团队更多建设通用运行时、沙箱和规模调度。两条路线最终会在企业级Agent控制面汇合。
第五，Harness基础能力将加快商品化，差异化价值向组织资产迁移。随着DeepSeek Harness等开源项目出现，工具、会话、沙箱和调度会逐渐标准化。企业长期优势将来自领域知识、验收标准、失败数据和持续治理机制。
01
Harness的定位：不是另一种Agent框架，而是企业控制体系
企业对Harness的理解，正在经历与早期RAG相似的过程。
概念流行初期，市场往往倾向于把它识别为一类新工具：在模型外部增加Rules、Skills、Memory、MCP和多Agent编排，便构成一套Harness。这样的描述便于理解，但无法解释企业为什么需要为它投入独立的工程资源。
从目前的实践看，Harness更接近一种控制体系。
Agent与传统软件的差异，在于其执行路径不能被完全预先确定。模型会根据上下文、工具返回和中间状态动态作出判断。企业因此无法只验证单个模型输出，还需要管理整个行动过程：模型读到了哪些资料，调用了哪些工具，是否拥有相应权限，中断后怎样恢复，凭什么判断任务完成，以及失败是否会改变下一次执行。
从功能上看，一套企业级Harness至少包含六项能力：
这六项能力并非都需要由统一平台提供。腾讯应用宝将状态文件、专家Agent、强类型程序和内部DevOps平台组合使用；高德把依赖图、模块规格、行为保全账本和测试系统串成项目级Harness；Spotify则把Backstage、Fleetshift、Kubernetes、Claude Agent SDK与CI组合为后台Coding Agent Honk。
它们的共同点不是技术选型，而是建立了一个位于模型和生产环境之间的控制层。
这一定位也意味着，Harness不应被视为AI平台团队的孤立项目。它与研发效能、软件架构、测试、安全、知识管理和组织流程都有直接关系。企业若只从模型调用或Agent编排角度建设，通常只能覆盖其中一部分。
02
成熟度判断：多数企业尚未跨过“证据闭环”
沙丘智库将当前企业Harness的成熟度划分为四个阶段。
L1，工具接入。Agent可以读取文件、搜索代码、调用API、执行命令或修改系统。这一阶段解决“能不能行动”，但任务通常仍由人持续监督。
L2，流程受控。企业开始配置Rules、Skills、角色分工和工作流，并将计划和任务状态结构化。Agent能够在预设流程内完成较长任务，但对指令的遵循和中断恢复仍不稳定。
L3，结果可验证。确定性规则进入脚本、Hooks、CI和权限系统，独立Evaluator对结果进行验收；任务轨迹可以复查，失败后能够恢复或回滚。“完成”不再是模型的文本声明，而是测试、文件、接口和状态共同构成的证据。
L4，组织化运行。Agent由任务系统统一调度，可以跨项目并发执行；风险、成本、质量和人工接管进入集中治理，失败经验持续写回知识库、规则与评测集。此时企业获得的不只是个人提效，而是可管理的机器产能。
从公开案例看，大多数团队位于L2，少数已进入L3，触及L4的实践仍较有限。
高德搜索已经通过依赖图、变更集、模块规格和保全账本管理复杂重构，并对47项P0行为声明逐项验证，具备较强的证据闭环。高德汽车将上下文峰值降低约50%、AI工程缺陷逃逸降低73%，但团队仍将反馈前移视为最不成熟的部分。
OpenAI Symphony用Linear任务状态驱动Agent，崩溃或停滞后可自动重启，开始呈现组织调度能力；Spotify则通过Fleetshift管理大规模代码迁移。不过，这些案例仍主要集中在特定任务和工程团队，距离企业范围内统一管理不同业务Agent尚有距离。
因此，2026年的Harness仍不属于成熟的软件基础设施市场。其核心组件正在稳定，但架构边界、指标体系、治理责任和最佳实践仍在快速变化。企业可以开始建设，却不宜把当前方案固化为长期不变的平台标准。
03
关键瓶颈已经从生成转向验收
早期AI Coding的主要问题是代码质量不足。模型能力提升后，生成本身不再是唯一约束，新的矛盾来自生成速度与组织验收能力的不匹配。
Spotify的数据较为典型：超过99%的工程师每周使用AI编码工具，94%认为生产力有所提升，PR频率增长76%。AI增加了代码供给，也把压力转移到审查和决策环节。OpenAI的工程师在同时管理三至五个Codex会话后出现明显的注意力负担，随后以Symphony将会话管理转为任务系统调度，部分团队前三周合入PR数增长500%。
如果企业仍沿用传统的逐行Code Review，人工阅读速度很快会成为全链路瓶颈。
国内团队正在形成三种应对方式。
一是把规范类检查交给机器。美团将工程分层、领域模型和仓储规范转化为always级AI Rule，在提交代码前通过AI Pre-PR过滤常规问题；人工审查集中到业务语义、技术方案和高风险边界。
二是引入独立评估角色。阿里在长程Coding实践中将规划、执行和验证分离，使用结构化Rubric评价功能、设计、质量和风险；Anthropic则让Generator与Evaluator在每个Sprint开始前先确定验收契约，再由Evaluator使用Playwright实际操作应用。
三是把业务保真变成显式账本。高德搜索不是只检查新代码能否编译，而是将旧系统中的功能单元、云控开关、埋点和关键行为映射到新架构，逐项确认是否保留。
这些实践共同指向一个正在形成的“证据层”。它位于Agent的执行结果与企业验收之间，包含测试报告、运行轨迹、行为映射、接口状态、风险清单和人工审批。
未来企业对Agent的信任，不会主要来自模型品牌，也不会来自一次演示，而会来自证据层能否持续回答三个问题：
Agent实际做了什么； 结果是否满足预先定义的成功条件； 出现问题时，责任边界和恢复路径是否清楚。
在高风险行业，这一层的重要性会高于生成能力本身。
04
中外实践差异：国内深入业务现场，海外建设通用底座
国内外Harness实践已经呈现出不同的优先级。
国内团队的起点往往是一个不能推倒重来的系统。
腾讯CDN LEGO拥有百万行核心代码和数百万行深度改造依赖，服务万亿级日请求；高德搜索面对5463个文件、约50.3万行JS/TS和大量历史耦合；美团在业务持续迭代的同时重构31万行Java；阿里电商数据团队需要先把分散在历史SQL、文档和人员经验中的指标语义整理出来。
这类项目要求Harness不仅控制模型，还要理解组织已有的工程事实。因此，国内实践更强调知识结构化、范围控制、行为保真、内部系统接入和人工审批。
海外头部厂商更多从平台层出发。
Anthropic将Managed Agents拆成Session、Harness、Sandbox三个稳定接口，使运行容器、Harness和模型可以分别替换或恢复；GitHub用同一Agentic Harness支持CLI、App、代码审查和SDK，并在二十多个模型之间评估任务完成率、成本和方差；OpenAI通过Symphony将项目管理系统变成Agent控制平面。
海外路径强调运行时的通用性，国内路径强调业务环境的适配性。沙丘智库认为，这种分化将在未来两年逐步收敛：
国内大厂会将分散在项目中的状态、权限、验证和观测能力上收为统一平台； 海外通用Harness会加强企业知识、业务本体和复杂审批流程的接入； 企业最终需要的不是二选一，而是“通用运行底座 + 专有业务控制”的组合架构。
05
企业价值评估：AI代码占比不是核心指标
当前不少企业以AI代码采纳率、生成代码量或工具活跃用户数衡量AI Coding。这些指标适合观察工具使用情况，却不足以判断Harness是否创造了经营价值。
原因在于，Harness通常会增加单次任务的步骤和模型消耗。
Anthropic的同一应用实验中，单Agent运行20分钟、成本9美元，完整Harness运行6小时、成本200美元。后者成本高出20多倍，但单Agent生成的应用核心玩法无法运行，完整Harness则交付了可操作的产品。高德汽车也明确指出，更强的控制会增加单次任务时延和成本，交换的是可追踪性与生产可信度。
因此，单次调用成本不能独立衡量价值。企业更应观察“经过验证的有效交付成本”。
沙丘智库建议将Harness指标分为四组：
GitHub的生产A/B测试提供了一个较好的参考：调整子Agent委派后，每会话工具失败下降23%，搜索工具失败下降27%，编辑工具失败下降18%，P95等待时间下降5%，同时质量没有回退。这里衡量的不是Agent数量或Token总量，而是系统行为是否更稳定。
企业还需要将Harness的维护成本纳入评估。规则、Skills、评测集和知识库都需要更新；过时规则造成的误杀、无效重试和上下文浪费，同样是成本的一部分。
06
竞争壁垒：从Harness代码转向组织知识
DeepSeek Harness于8月以开发者预览形式开源，将模型、工具、Skills、Session、Sandbox、存储、循环、调度和UI设计为可替换插件，并以只追加事件流支持轨迹检查、恢复和回放。
这一变化意味着，Harness的通用技术能力可能比市场预期更快标准化。
当会话、沙箱、工具注册、任务循环和观测逐渐成为开源组件或云平台能力后，企业自行重复建设的必要性会降低。真正形成差异的，将是运行在这些基础设施上的专有资产：
企业如何定义业务对象、关系和状态； 哪些历史行为与合规要求不能被破坏； 什么结果可以自动放行，什么必须人工审批； 哪些失败模式已经被转化为测试、规则或评测任务； 不同岗位的专家经验能否被Agent按需调用。
Spotify的数据迁移案例能够说明这一点。Honk在标准化程度较高的dbt和BigQuery Runner中表现稳定，但面对不同团队实现差异很大的Scio，统一提示难以覆盖所有情况，团队最终选择暂缓自动迁移。部分仓库缺少构建期测试，也使Agent无法自行验证修改。
这类问题不能通过更换Harness框架直接解决。它反映的是企业的“Agent可用性债务”：代码、文档、测试和业务语义长期以人类默认能够理解的方式存在，却没有形成机器可以准确读取和验证的结构。
未来，代码库是否对Agent友好，会成为企业软件资产质量的一部分。统一技术栈、清晰依赖、结构化文档、稳定测试和明确所有权，不再只是研发管理规范，也会直接影响机器产能。
07
主要风险：Harness同样会形成技术债
Harness建设最容易出现的问题，是只增加控制，不评估控制是否仍有必要。
Anthropic曾为旧模型接近上下文上限时提前结束任务，设计Context Reset。模型升级后，这一行为消失，原有机制反而成为额外负担。GitHub的实践则说明，过度使用子Agent会增加工具失败和等待。高德汽车团队也指出，Hooks和角色过多可能让流程僵化。
这意味着Harness不是稳定不变的软件外壳，而是一组对模型能力和业务环境的动态补偿。模型升级、代码库调整或业务规则变化后，补偿可能失效，也可能从保护机制变成效率负担。
企业需要建立Harness自身的生命周期治理：
每项规则和Gate应对应明确的风险或历史失败； 新增控制后，应观察成功率、误杀率、成本和人工接管变化； 模型或环境升级后，应重新运行回归评测； 长期无贡献或产生负收益的规则应被移除； 对Harness的修改需要版本、审批和灰度机制。
因此，未来较成熟的Harness团队不会只负责“搭建脚手架”，还需要持续判断哪些脚手架应该保留、哪些可以拆除。
08
企业建设建议：从任务组合开始，而不是从平台开始
Harness涉及多种工程能力，但企业不应直接以建设统一平台作为起点。更可行的路径，是从任务、证据和风险逐步扩展。
1. 选择适合的首批任务
优先选择频率高、边界明确、结果可自动验收、失败影响可控的任务。例如依赖升级、接口迁移、测试补齐、局部缺陷修复、结构化数据处理。
不建议将业务边界模糊、外部依赖复杂、缺少测试且错误不可逆的任务作为第一批无人监督场景。
2. 先定义验收，再设计Agent
企业应在选择模型和编排方案之前，明确任务成功条件、禁止修改范围、测试方式、风险等级和人工审批点。无法定义完成条件的任务，也无法建立可靠Harness。
3. 将项目状态移出对话窗口
计划、进度、关键决定、工具结果和验收记录应进入结构化状态或事件日志，支持中断恢复、角色交接和复查。长上下文可以改善体验，但不能替代状态管理。
4. 将确定性约束交给系统
凡是可以由代码、权限、类型、脚本和测试判断的事项，不应主要依赖Prompt。模型适合处理语义判断，系统负责执行边界和硬性门禁。
5. 建立失败到资产的转化机制
每次人工纠正都应判断能否沉淀为知识条目、回归测试、规则或评测任务。Harness的长期收益，不来自单次提效，而来自相同问题不再重复发生。
6. 按风险设置不同自治等级
低风险、可回滚任务可以自动执行和合并；中风险任务要求Agent提交证据后由人确认；高风险任务应限制工具、数据和环境访问，保留双人审批或人工执行。
企业的目标不应是让所有Agent获得相同自治程度，而应让自治程度与任务风险、验证能力相匹配。
09
未来12—18个月的五项判断
其一，通用Harness组件将快速商品化。开源项目、模型厂商和云平台会逐步覆盖工具注册、沙箱、会话、调度、追踪和恢复。企业自研重点将向策略、知识和验证上移。
其二，模型会吸收一部分外部脚手架。更强的规划、上下文管理、工具选择和自我检查能力，会使某些复杂编排失去必要性。Harness架构需要保持可替换和可删减。
其三，评测将从上线前测试转向持续运营。企业会使用真实任务轨迹形成回归集，监测模型、规则、工具和业务环境变化后的性能漂移。Evaluation将成为Harness的日常运营能力。
其四，Agent安全将从内容治理走向行动治理。权限、凭证、网络、工具和审批会成为新的安全边界。安全团队需要理解Agent的意图与轨迹，而不仅是扫描最终输出。
其五，“Agent-ready”将成为软件工程的新质量维度。文档、测试、接口、依赖、所有权和运行环境是否便于机器理解与验证，将直接影响企业应用AI的速度和成本。
企业对大模型的投入，正在从获取通用能力转向建设组织能力。
模型解决的是“机器是否具备完成任务的能力”，Harness解决的是“企业是否具备使用这种能力的条件”。前者主要由模型厂商推动，后者必须由企业结合自身知识、系统和风险边界完成。
从当前成熟度看，Harness尚未形成稳定的产品边界，也没有统一的建设范式。但腾讯、高德、阿里、美团以及海外头部公司的实践已经证明：当Agent从辅助工具转向工作执行者，状态、验证、权限和知识不再是附属能力，而是能否进入生产环境的基本条件。
未来真正拉开企业差距的，不会只是接入哪个模型，而是能否把自身的工程方法、业务判断与风险标准，转化为一套机器可理解、可执行、可验证的工作系统。
这也是Harness对企业最重要的意义：它把通用模型能力，转化为一家具体组织可以持续使用的生产能力。
更多AI研究内容可前往【沙丘智库小程序】搜索查阅