Harness Agent 在实际业务中的落地现状和未来发展

01

范式演进：从 Prompt 到 Harness

企业需要的不只是 Prompt 技巧，还需要一套能够让 Agent 持续运行、调用工具、管理状态并交付结果的 Harness 运行架构。要理解这一点，可以先回看大模型从“交互”走向“执行”的过程。

1. AI 的演进：从交互到执行

ChatGPT 刚出现时，人们首先期待大模型替代一部分搜索工作。传统搜索需要选择关键词、翻页，并由用户判断答案出现在哪一页；找到内容后，还要继续提取和整理。大模型能够直接围绕问题生成答案，典型形态是 Chatbot。

随后，人们希望大模型辅助完成更多工作，例如写邮件、改代码和代码补全，典型形态是 Copilot。再往后，用户开始要求模型拆解任务、执行步骤并直接交付结果：用户只说明“做什么”，而不是逐步说明“怎么做”，这对应 Agent 的初级阶段。

当期望进一步提高，Agent 还需要承担完整流程，串联跨工具、跨系统的复杂任务，最终交付高质量结果。这就是我今天要讨论的 Harness Agent System。

图 1.2 AI 从替代搜索、辅助工作、解决任务到承担完整流程

2. 从 Prompt 到 Harness 的四阶段演进

第一个阶段是 Prompt。通过定义角色、任务目标、输出格式和约束，表达用户意图，让大模型完成一次相对明确的生成任务。

第二个阶段是 Context。企业希望注入更多知识，典型方式是 RAG，用于补充通用模型中不存在的企业文档和较新的业务信息，降低知识缺失带来的问题。

第三个阶段是 Tool 与 MCP。Tool 让大模型获得行动能力，例如读取、写入或删除文件；MCP 则用于把已有 API、业务系统和跨系统能力接入 Agent，使其能够在统一的交互中调用外部能力。

第四个阶段是 Harness。目标不再是完成一次问答，而是端到端地形成闭环，处理复杂任务中的状态持久化、中断恢复、结果可信度、异常处理和持续执行。

图 1.3 从 Prompt、Context、Tool/MCP 到 Harness 的四阶段演进

3. Harness 为什么重要

这里我列举了多组基准测试和行业实验：在底层模型不变的情况下，更换或增强脚手架，复杂任务的效果和排名可能出现明显变化；使用较弱模型配合更好的Harness，也可能超过更强模型配合较弱脚手架的结果。我想借此说明，在模型能力逐渐趋同的阶段，Harness 会成为影响复杂任务表现的重要变量。

第二个例子是构建 2D 复古游戏：单 Agent 在较短时间和较低成本下生成了结果，但游戏中的实体无法正常响应；在底层模型不变的情况下，Harness 方案投入更长时间和更多成本，最终交付了可运行、可交互的版本。这个例子强调，Harness 关注的不是一次生成是否“看起来完成”，而是任务能否真正闭环并达到可用标准。

图 1.4 基准测试与 2D 游戏案例：Harness对复杂任务表现的影响

4. Agent = Model + Harness

我们可以用一个工程公式来概括 Harness：Agent = Model + Harness。这里的 Harness 指模型之外、为了完成复杂任务而提供的周边工程能力，包括方向、记忆、行动、约束和运行轨迹。

如果把模型比作发动机，汽车要真正上路，还需要方向盘、导航、传动、刹车和仪表盘。类似地，模型能力再强，Agent 若缺少状态、权限、工具、观测和验证机制，也很难进入生产环境。

图 1.5 Harness：从能力调用到生产闭环

02

落地挑战：工程难题拆解

在工业生产环境里，一个业务目标通常要经历目标定义、信息准备、执行推进和验证交付等多个环节。任意一步发生问题，都可能导致端到端任务失败。从相关行业调查来看，Agent 在生产环境中的失败比例依然很高。

1. 一个业务目标如何变成可执行结果

Agent 落地面对的并不只是“模型够不够聪明”。生产环境需要把业务目标拆成可以定义、准备、执行和验证的完整链路，并明确每个环节的输入、状态、权限和验收方式。Demo 中表现良好的 Agent，一旦进入多步骤、多系统流程，任务状态、上下文可信度、工具安全和结果验证中的任何缺口，都可能使最终结果不可用。

图 2.2 从业务目标到结果交付的执行链路

2. 任务链路失控

有这么一个例子：一个团队使用 Agent 处理长周期文档，中途因模型调用速率限制而中断。每次重试都从头开始，进度随之丢失，项目周期受到影响。

问题的关键不只是上下文窗口大小。模型本身是无状态的，只有当前请求携带了状态信息，模型才知道任务进行到哪里。一旦会话中断，如果没有外部状态与存档机制，就只能重新执行。

因此，需要先定义任务状态：哪些步骤已经完成、哪些尚未完成、中间遇到过哪些问题，以及恢复时应从哪里继续。同时，应持久化用户与 Agent 的交互历史。一个任务可能包含多轮用户交互，而每轮交互又包含多次模型调用，这些历史共同构成恢复任务所需的上下文。

当历史超过上下文窗口阈值时，需要触发压缩与摘要，把当前进度、已完成任务、未完成任务和关键问题整理为可恢复的状态。它类似游戏存档：任务中断后从断点继续，而不是每次从头开始。

图 2.3 任务状态、Checkpoint、历史管理与摘要恢复

3. 上下文失真

这里还有一个制造业案例：Agent 使用了过期的设备维护手册，进而生成错误的规格参数。这个案例想说明的是，上下文并非越多越好，进入上下文的信息必须有明确边界和可信来源。

当上下文过长时，模型的注意力可能更多集中在开头和结尾，中间部分的信息更容易被忽略。如果正确数据恰好处于中间，输出就可能出现错误。解决思路是建立严格的知识边界与配套的压缩策略。

首先，要明确哪些数据可以使用、哪些数据不能使用，对法律法规、维护手册等时效性资料进行版本管理；对仅在特定场景可用的数据进行权限管理；对关键结论保留来源，方便二次校验；对字段缺失或质量不足的输入进行过滤。

其次，要针对长时间运行设计压缩机制。策略压缩可以移除已经完成的工具调用过程，只保留总结性结论；语义压缩可以在达到阈值后额外调用模型生成摘要；必要时还可以做全局重建，使长任务持续获得可用的上下文空间。

图 2.4 上下文边界、知识版本、来源与压缩策略

4. 工具调用风险

这里有一个 PocketOS 相关案例：Agent 在排查问题时错误调用高权限 API，导致生产数据和备份卷被删除，业务随之停摆。这个案例要说明的是，当行动与验证脱节、权限边界不清晰时，Agent 会只围绕目标执行，而不会自然承担不可逆操作的后果。

工具治理首先要划分能力与风险等级。读文件、写文件、修改文件和删除文件的风险不同，删除系统配置等操作必须受到严格限制。高风险指令还需要在安全环境中执行，例如通过容器或沙箱隔离，避免错误参数影响真实生产系统。

其次，要建立人工审批。涉及资金转账、删除、发布等高风险动作时，必须获得人工确认。这里的基本原则是 Deny-Ask-Allow：默认拒绝高风险或未登记能力，必要时询问用户，低风险读取类操作才可以在权限范围内开放。

最后，要记录完整的工具调用链路，包括调用主体、参数、执行结果和审批过程，从而形成责任链与问题排查依据。权限约束不能只写在系统提示词里，因为提示词是软性约束；生产环境仍需要物理隔离和执行层门禁。

图 2.5 工具风险分级、沙箱、人工审批与审计闭环

5. 结果难信任

金融场景中有这样一个例子：Agent 生成的审计报告格式完整、语言确定，但其中引用的法规条款存在错误。如果直接提交，可能带来监管风险。Agent 往往会以很有把握的语气回答问题，即使答案并不正确。

如果人类仍需逐行验证一份长篇报告，认知负担可能接近从头撰写，自动化也就失去意义。因此，生产系统需要建立多层次的自动验证流水线。

第一层是确定性规则校验，例如数值、格式、Schema 和合规项；第二层是关键事实与权威数据的交叉比对，保证引用可靠；第三层可以使用模型对结果进行判别和评分；最后设置发布门禁，例如用规则或正则表达式拦截 Token、API Key 等敏感信息。只有形成验证闭环，Agent 的结果才具备进入生产环境的基础。

图 2.6 规则校验、事实比对、模型评审与门禁拦截

6. 生产不可观测

再看一个自动化营销方案的例子：团队夜间启动 Agent，第二天发现没有任何产出，也没有错误日志。排查后发现，所调用 API 的参数格式发生变化，Agent 一直在重试。

传统监控主要观察 CPU、GPU、内存和 HTTP 状态码，但 Agent 的失败更多是逻辑失败：为什么选择某个工具、在哪一步偏离目标、为何反复重试，都需要从推理与执行轨迹中判断。

因此，要记录 Agent 每一步决策以及多 Agent 场景中的分叉点，并把模型返回的工具调用与外部环境的实际执行结果一一对应。完整轨迹既可以通过看板展示当前进度和异常，也可以用于故障定位和反向优化 Agent。

图 2.7 Agent 运行轨迹、工具调用关联与细粒度可观测

7. 经验难复用

一个资深员工可能通过几十轮对话，与 Agent 共同完成高质量数据分析报告；但如果这名员工休假或离开，其他人很难复现同样的结果。原因在于交互经验仍停留在个人脑海中，没有被结构化沉淀。

我把 Agent 比作实习生：资深员工知道怎样带好实习生，但“怎么带”的经验如果不被记录，就无法成为团队资产。Skill 是把个人经验沉淀为可复用资产的一种机制。

Skill 的粒度需要平衡。把完整任务流程封装成一个 Skill，内容会很长、迁移成本高；拆得过小，数量又会迅速膨胀，不利于管理。团队需要统一规范，明确 Skill 的生产标准和粒度，并将不同团队的实践整合为企业级资产。

Skill 还涉及安全监管。外部或个人 Skill 可能包含恶意文件操作或转账指令，因此在进入公司级资产库之前，需要完成内容审核、权限检查和验证。

图 2.8 Skill 粒度、组织规范与安全治理

8. 协作规模失控

多 Agent 开发软件项目时，开发 Agent 与测试 Agent 可能相互覆盖文件，引发冲突和项目失败。问题通常来自上下文污染与责任边界不清。

每个 Agent 都试图掌握全部细节，会稀释对全局目标的关注。合理的方式是明确主Agent 与子 Agent 的分工：主 Agent 与用户交互、澄清意图、规划和拆解任务；子 Agent 完成具体子任务，并以“结论与必要摘要”回传，而不是把所有过程细节重新塞给主 Agent。

主 Agent 与子 Agent 之间还可以采用异步协作，只要定义统一的通信标准，子任务就能并行执行，从而提高整体效率。

图 2.9 多 Agent 的上下文隔离、职责边界与异步协作

9. 知识不沉淀

每次启动新项目，Agent 都像新人一样从头开始，过去纠正过的错误和规范还会再次出现。原因在于模型每次推理都是新的，只依赖当前上下文，本身没有可持续的长期记忆。

为了保证知识能够沉淀下来，我们需要构建分层的记忆架构。顶层是稳定知识，例如构建命令、数据口径和企业规范，这些内容可以在每次项目启动时加载；中层是主题文件，把用户与 Agent 对话中形成的经验按项目、任务类型或主题归类；底层是完整历史记录，通常不直接全部放入上下文，而是在需要时进行检索。

主题文件可以通过“静默知识蒸馏”生成。当一段时间内积累了足够多的对话，后台进程可以对历史信息进行分类、总结并沉淀为主题知识，在后续任务中按需加载。

图 2.10 企业记忆的分层、按需加载与静默知识蒸馏

10. 实施路线：先跑通最小闭环，再做平台化

Harness 落地不仅是技术问题，还包含旧系统改造、组织阻力、团队习惯和生产稳定性等非技术挑战。企业如果希望一个 Agent 一次解决所有问题，往往会在新能力与旧体系的矛盾中受阻。

更合理的路线，是选择高频、可控、风险可管理的小场景，先把输入、执行、验证和交付的整条链路跑通。在单点获得收益后，再扩展到其他场景，并把经过验证的能力逐步沉淀为平台。

图 2.11 Harness 实施路线：从精准切入点到平台化

03

实践原则：AI 时代的研发方式

当 Agent 已经进入生产实践，研发团队还需要改变对“人、模型、代码和文档”关系的理解。下面我们以 Vibe Coding 为例，讨论意图表达、验证方法和文档契约的转变。

1. 从代码交互转向意图表达

传统开发由人写代码、写文档，并通过文档沟通；协同阶段由人与大模型交互，大模型写代码，人负责审核；进入 Vibe Coding 阶段，人更多成为意图表达者：人表达目标，模型生成文档，再根据文档生成代码。

这里再回顾一下我们团队在模型优化中的认知变化。在代码补全阶段，人和模型共同修改代码，人的改动可以被理解为对 Label 的纠正；但在 Agent 阶段，用户只提出需求，不再逐行参与代码改写。原有以“人工改代码”为核心的优化思路因此需要改变。

图 3.2 从传统研发、人机协同到 Vibe Coding 的认知转变

2. 验证粒度迁移与测试前置

大模型可以在很短时间生成大量代码，如果人仍然逐行 Review，既难以提效，也会增加认知负担。所以我们应该把主要验证重心从逐行实现细节转向功能黑盒验证，以可观察的输入、输出和行为判断功能是否正确。

要实现这一点，测试需要前置，评测数据应独立于功能开发。如果先生成实现，再让同一上下文生成评测数据，就会形成“考生自己出卷、自己答题”的情况。功能开发上下文与评测生产上下文应相互隔离，通过独立的黑盒测试验证正确性。

图 3.3 验证重心迁移、测试前置与评测上下文隔离

3. Vibe Coding 的反噬与文档契约

使用 Agent 生成代码时，项目初期往往进展很快；到了后期，一旦出现 Bug，排查成本可能急剧上升，甚至不如从头开始。根本原因是缺少约束，代码生成速度超过了维护能力。

因此，人不再只与代码交互，而要通过文档与模型建立契约。模型依靠文档理解项目现状；文档记录“为什么这样做”的决策逻辑，供人工审核并继续指导模型；开发中的变更也要同步更新到文档。

文档还需要固定模板。若每次都让 Agent 自由生成，格式和术语会不断变化，既可能造成模型对语义的歧义，也会增加人阅读和接手的成本。统一模板可以提高前后语义一致性，并让团队按稳定结构理解项目。

图 3.4 Vibe Coding 的反噬与文档契约

4. Harness 下沉为 AgentOS

我们现在做的大模型 Agent，本质上都是在做提效。那现在使用 Agent，提效倍数究竟是 10 倍还是 100 倍？如果目标是 10 倍，我们可能还需要关注工具调用和代码实现的细节；如果目标是100 倍，就需要把 Harness 这一套能力下沉为智能操作系统，逐步沉淀为基础服务。

在这个设想中，Harness 进一步下沉为 AgentOS：我们不再关注意图怎么解析、任务怎么拆解、Agent 怎么调度，而是把任务理解、拆解、调度、执行和安全控制逐步沉淀为基础服务；人只需要关注目标和意图的表达。

图 3.5 Harness 下沉为 AgentOS 的趋势判断

04

总结

Harness 的价值，是把模型能力放入可持续执行的工程闭环。这个闭环不仅包括Prompt、上下文和工具，还包括状态恢复、知识边界、权限隔离、结果验证、运行轨迹、经验复用、协作边界和长期记忆。企业应从高频、可控的小场景开始，先跑通闭环，再逐步平台化。

研发方式也会随之变化：人从直接编写和修改代码，逐步转向表达意图、维护契约和验证结果；模型从一次性生成工具，逐步进入可以承担完整流程的 Agent 系统。Harness 是否成熟，决定了这种变化能否真正进入生产环境。

点个在看你最好看

SPRING HAS ARRIVED