从 AI 助手到生产级 Agent:Harness 正在成为下一代软件服务的关键基础设施

当大模型能力不断增强，ToB 软件行业正在面临一个越来越现实的问题：未来交付给客户的，是一个“人来操作的软件系统”，还是一个“能够自主完成业务任务的智能系统”？这是HR最近在内部调研的一个课题，也是作为软件服务商需要直视的命题。

这个问题的变化，不只是多加一个 AI 聊天框那么简单。它意味着产品交付形态、系统架构、业务责任边界，乃至软件价值评估方式，都在发生调整。过去企业采购软件产品，买的是流程数字化工具；而在 AI 时代，企业越来越期待的是结果导向型系统，即系统不仅能记录流程，还能理解上下文、调用工具、执行动作，并最终交付可验证的业务结果。

沿着这条思路继续推演，就会自然引出一个更具体的问题：如果企业要构建真正可上线、可运维、可持续优化的 Agent，底层到底需要什么样的工程化承载能力？这正是讨论生产级 Agent 时，Harness 这一概念越来越重要的原因。

一、AI 之后，产品交付形态正在从“功能系统”走向“结果系统”

过去二十年，软件服务的基本逻辑相对稳定。厂商提供标准化软件，企业把业务流程映射进系统，由员工在系统中录入、审批、查询、协同，最终完成业务闭环。在这种范式里，软件的核心价值是流程承载、数据沉淀和组织协同。

但大模型进入企业软件之后，这套逻辑开始出现变化。

原因并不复杂。很多原本依赖人工完成的中间环节，例如信息整理、语义理解、任务分发、内容生成、规则匹配、跨系统操作，正在具备被 AI 接管的可能。于是，客户对产品的期待也随之变化：

不再满足于“给我一个能用的系统”；
而是进一步要求“帮我把这项工作做完”；
不再只关注功能是否齐全；
而是更关注结果是否稳定、效率是否提升、人工是否真正减少。

这意味着软件产品的竞争焦点，正在从“功能模块完不完整”，逐步转向“系统能否自治完成业务任务”。

例如在销售、客服、招聘、产研、法务、运营等知识密集型场景中，企业并不真正需要一个更复杂的表单界面，而是希望系统能够直接承担一部分工作职责：理解IM、邮件和会议内容、抽取关键信息、生成下一步动作、调用内部工具、触发审批或执行流程。换句话说，软件开始从“被人操作的工具”向“替人做事的系统”演进。

当然，这里也需要保持客观。并不是所有软件产品都会迅速变成全自治 Agent。对于强约束、高责任、低容错的场景，人工确认仍然是重要环节；对于高度标准化、规则完全确定的流程，传统自动化依然比 Agent 更简单、更可控。真正发生变化的，是一大批过去“难以自动化、又必须依赖人”的复杂知识工作，如今第一次具备了工程化自治的可能性。

更重要的是，交付形态的变化并不意味着系统本身会消失。恰恰相反，系统的角色变得更加关键了。企业经营始终需要面对审计、合规、决策支撑、组织协同等严肃的管理诉求，这些诉求的底层依赖没有改变——依然是结构化的数据沉淀、可追溯的流程记录、可控的权限体系和稳定的能力底座。Agent 接管的是执行层的动作，但数据的归集、治理和复用，仍然需要一套严谨的系统来承载。换句话说，Agent 并不是取代系统，而是让系统从”人工操作的载体”演变为”智能执行的底座”。系统依然在，只是它的价值从”提供界面让人操作”转向了”提供基础设施让 Agent 运行、让数据沉淀、让管理可控”。

这一点也是我们与业务沟通时经常面临的问题，他们往往惊艳于AI当下的表现而忽略系统本身的重要性，所以务必要合理管理他们预期，帮助他们建立正确认知：真正让 AI 持续发挥作用的，不是模型本身的聪明程度，而是承载模型的系统基础设施是否足够坚实。

因此，AI 时代的关键问题不再只是系统“要不要接入模型”，而是“要交付什么形态的产品”。如果答案是一个能持续完成任务的智能体系统，那么团队就必须进一步回答：这样的系统如何被构建、治理、评估与运行？

二、为什么生产级 Agent 需要 Harness，而不是只靠模型和 Prompt

很多团队在早期做 Agent 时，往往从 Prompt、模型调用和工具调用开始。这种方式适合快速验证 Demo，但一旦进入真实业务环境，问题很快就会暴露出来：流程不稳定、执行不可追踪、失败难以恢复、成本难以控制、权限边界不清晰、上下文管理混乱、版本难以迭代。

这也是为什么“生产级 Agent”不能只理解为“把大模型接进业务系统”。它本质上是一套完整的运行体系，需要回答至少以下几个问题：

Agent 如何定义任务边界与执行流程；
如何组织多步推理、工具调用和状态流转；
如何保证任务失败后可恢复、可重试、可回溯；
如何对模型输出做约束、校验与安全防护；
如何沉淀记忆、上下文和中间结果；
如何观察线上表现，并持续迭代策略与提示词；
如何在自治和人工介入之间建立合理的控制机制。

从这个角度看，Harness 可以理解为 Agent 的工程化承载层，是一整套让 Agent 能够“真正跑在线上”的基础设施组合。它通常覆盖任务编排、状态管理、工具接入、上下文管理、权限约束、日志追踪、评测反馈、人机协同、安全治理等关键能力。

如果说模型决定了 Agent 的“上限”，那么 Harness 决定的往往是 Agent 的“可用性下限”。没有 Harness，Agent 能回答问题；有了 Harness，Agent 才可能稳定完成任务。

这也是 Harness 之所以重要的根本原因。企业真正采购和使用的，不是一个会说话的模型，而是一个可上线、可治理、可负责的业务系统。

三、把 Harness 具象化：它不是抽象概念，而是一类明确的工程实践

讨论 Harness 时，最容易陷入两个误区。

第一个误区，是把它理解成某个特定产品名称；第二个误区，是把它理解成一个过于宏大的架构口号。更准确的理解方式是：Harness 代表的是一套围绕 Agent 生命周期展开的工程实践，其目标是让智能体从“能跑”走向“可用、可控、可扩展”。

一个相对完整的 Harness，通常会体现为以下几个方面：

1. 任务编排能力

Agent 很少只执行一步操作。真实任务往往需要拆解、规划、执行、反思、再执行。Harness 需要提供流程编排能力，把复杂任务组织成可管理的执行图，而不是把所有逻辑都堆进单次 Prompt。

2. 状态与上下文管理能力

生产环境中的 Agent 必须知道自己当前处于什么阶段、已经做过什么、哪些结果可复用、哪些上下文必须保留。否则同一个任务在长链路执行过程中会不断失真，甚至发生循环和漂移。

3. 工具与环境接入能力

Agent 的价值不在于“理解”，更在于“行动”。Harness 需要规范化地接入数据库、知识库、浏览器、邮件、工单系统、内部 API 等工具，并对调用权限、参数结构和异常处理进行约束。

4. 观测、评测与回放能力

如果一次任务失败，团队需要知道失败发生在哪一步，是模型判断错误、工具返回异常，还是上下文缺失。没有可观测性，就没有线上治理；没有回放与评测，就很难做稳定迭代。

5. 安全与控制能力

一旦 Agent 开始具备执行能力，安全就不再是附加项。权限隔离、敏感操作确认、输出校验、注入防护、数据边界控制，都必须纳入 Harness 的设计范围。否则自治能力越强，风险也越大。

当我们这样去理解 Harness，就会发现它已经不是一个抽象概念，而是能够直接映射到开源工程上的实践路径。

四、几个有代表性的开源方向：LangGraph、DeepAgents 与 OpenClaw

为了让 Harness 的概念更具体，可以看几个典型开源项目。它们并不完全相同，但都代表了生产级 Agent 不同方向上的工程化探索。

1. LangGraph：当前最标准、最工程化的 Agent Harness 代表

如果从“状态流 + 节点图 + 可控编排”的角度看，LangGraph 是目前较具代表性的 Agent 工程框架之一。它的重要价值在于，给多步骤 Agent 提供了清晰的状态管理和流程组织方式，让开发者可以像设计工作流一样设计智能体执行路径。

它适合那些对流程可控性、可观测性和复杂任务编排有较高要求的团队，尤其适用于：

多阶段任务执行；
需要显式状态流转的流程；
多工具协同调用；
需要人机协同插入点的业务场景。

从 Harness 的视角看，LangGraph 的意义不只是“能编排 Agent”，而是把 Agent 系统中原本隐性的控制逻辑显式化、结构化了。这使其更接近生产级系统，而不是实验性脚本。

2. DeepAgents：官方范式下的成品化 Harness 方向

DeepAgents 更像是对“官方推荐 Agent 组织方式”的产品化表达。它的重要意义在于，把一些常见的 Agent 结构、执行范式和组件能力封装得更直接，降低团队从零搭建 Harness 的成本。

这类项目对很多企业团队尤其有价值，因为现实里并不是每家公司都需要自己从底层搭 Agent Runtime。很多时候，团队更需要的是一个足够成熟的成品化起点，用来快速验证业务闭环，再根据实际场景逐步加深定制。

因此，DeepAgents 代表的是另一条路径：不是从底层抽象开始，而是从可交付系统开始，向下收敛工程能力。这种路径对于业务驱动型团队往往更友好。

3. OpenClaw：本地化、私有化部署场景下的 Harness 价值

OpenClaw 的代表意义在于，它提示了另一个重要方向：并非所有生产级 Agent 都会运行在开放云环境中。对于数据敏感、合规要求高、基础设施自控要求强的组织来说，本地化、私有化部署仍然非常关键。

在这类场景中，Harness 不仅要解决任务编排和工具调用，还要同时考虑：

本地模型与本地工具链的适配；
内网数据访问约束；
私有环境中的部署复杂度；
更严格的权限控制与审计要求。

因此，OpenClaw 这类项目的价值，不只是“可以本地运行”，而是说明 Harness 作为一层基础设施，完全可以根据企业约束条件做不同形态的实现。

五、对企业和产品团队来说，真正的机会不在“做一个通用 Agent”，而在“围绕某个领域工作流做自治系统”

当 Harness 逐渐成熟之后，一个更关键的问题也随之出现：企业究竟应该拿这套能力去做什么？

从产品机会的角度看，答案未必是做一个无所不能的通用型 Agent。通用 Agent 的想象力很大，但现实难度也极高。它需要覆盖大量场景、管理高度开放的任务边界，并处理非常复杂的不确定性。对于大多数团队来说，这条路径既昂贵，也不容易形成稳定的商业价值。

相较之下，围绕某个明确领域、明确角色、明确工作流构建“完全自治或高自治”的系统，反而更可能形成真正的产品机会。

原因主要有三点。

1. 领域边界更清晰，更容易构建可靠性

当任务范围收敛在特定业务域内，例如销售跟进、客服分流、投标响应、招聘筛选、知识运营、合规审核等，系统可调用的工具、可处理的数据、可接受的输出格式都会更明确。边界越清晰，Harness 越容易发挥作用，系统可靠性也越容易建立。

2. 工作流天然存在，可直接映射为 Agent 执行图

很多高价值业务场景本身就有相对稳定的步骤结构，例如“接收输入 – 理解语义 – 查询资料 – 生成方案 – 发起动作 – 记录结果 – 异常回退”。这类流程非常适合用 Harness 显式表达，并逐步把人工节点收缩到必要的审核与兜底环节。

3. 商业价值更容易闭环

企业最终愿意为之付费的，往往不是“一个很聪明的 AI”，而是“一个能持续替代部分工作量、提升关键指标的系统”。垂直工作流型产品更容易定义 ROI，例如节省多少人工时长、提升多少处理时效、减少多少漏单或误判。这比泛化能力更容易形成采购理由。

从这个角度看，Harness 的真正战略价值，不在于让所有人都去造一个超大通用智能体，而在于让团队可以围绕具体业务场景，把原本依赖人工协作的流程，逐步重构为一个自治系统。

六、产研在这中间需要承担的责任与使命

前面五个部分讨论的是行业趋势、工程方法和产品机会。但所有这些最终能否落地，取决于一个非常具体的组织单元——产研团队。

从 Demo 到生产级 Agent，中间的距离远比想象中大。这段距离不会被模型自动填补，也不会因为引入一个框架就自动消失。它只能靠产研团队一步步地设计、构建、验证和迭代来走完。因此，在 AI 驱动型产品的建设过程中，产研承担的不只是执行角色，而是要扛起几项关键责任。

1. 重新定义”交付物”：从功能交付转向结果交付

过去产研的交付标准往往是”需求完成、功能上线、无严重 Bug”。但在 Agent 类产品中，功能上线只是起点，真正的交付标准是”系统是否稳定地完成了业务任务”。这意味着产研需要把视角从”我做了什么功能”拉升到”用户因此少做了什么事、业务因此提升了什么指标”。

这不是口号，而是实际影响产品设计、技术选型和验收标准的底层变化。

2. 补齐 Agent 工程化能力：不只是会调模型，而是能建系统

当前很多团队的 AI 能力集中在 Prompt 调优和模型选型上，这是必要的，但远远不够。生产级 Agent 需要的工程能力远比调用一个 API 复杂得多：

需要设计任务编排逻辑，而不只是写单步调用；
需要建设状态管理与上下文持久化机制，而不只是拼接对话历史；
需要搭建可观测体系，而不是出问题后凭日志猜原因；
需要实现安全防护与权限隔离，而不是默认信任模型输出；
需要构建评测与回归能力，而不是靠人肉试几轮就上线。

产研团队要把这些能力视为核心基建来投入，而非外围支撑。Harness 不是架构师画出来挂在墙上的，而是工程师一层一层搭出来跑在线上的。

3. 成为业务与 AI 之间的翻译层

Agent 产品与传统功能型产品最大的区别之一，是它高度依赖对业务场景的深度理解。Agent 不是通用引擎，它必须知道”在什么场景下该做什么、不该做什么、做到什么程度算完成”。这些判断不是模型自动生成的，而是产研团队在业务调研、流程拆解和边界定义中沉淀出来的。

产研需要承担起”业务理解”和”AI 能力”之间的翻译职责。一方面把业务工作流拆解成 Agent 可执行的任务图，另一方面把 AI 的能力边界和不确定性如实传递给业务方。既不过度承诺，也不因畏难而止步。

4. 建立持续迭代的评估闭环，而不是一次性交付

Agent 产品不存在”一版定型”的状态。模型会升级，业务会演化，用户行为会漂移，数据分布会变化。如果产研只是做完第一版就转向下一个需求，系统质量必然衰减。

因此产研团队需要为 Agent 建立持续运行的评估闭环：

线上行为的可追踪、可回放；
关键指标的持续监控与基线对比；
提示词、工具配置和流程策略的版本管理；
典型 Bad Case 的快速定位与修复机制。

这套能力不是锦上添花，而是 Agent 产品能否长期存活的基本条件。

5. 在自治与可控之间找到动态平衡

Agent 的终极愿景是全自治，但在产品早期和绝大多数真实场景中，完全自治既不现实也不负责。产研需要为每一个 Agent 场景设计合理的”自治度”：哪些环节可以全自动执行，哪些环节必须人工确认，哪些环节需要兜底回退。

这不是一个静态答案，而是需要随着系统成熟度和业务信任度的提升不断调整的动态策略。产研的责任，是让这条从半自治走向高自治的路径可规划、可观测、可回退。

使命：成为 AI 时代产品能力的定义者，而不只是需求的执行者

如果把视角再拉高一层，产研团队在这一轮变革中真正需要承担的使命，是从”按需求交付功能”的角色，成长为”定义 AI 产品能力边界”的角色。

过去，产研的核心能力是把确定性需求高效转化为稳定系统。而在 Agent 时代，需求本身往往是不确定的——客户不知道 AI 能做到什么程度，业务方也无法像以前一样写出完整的 PRD。产研需要具备主动定义”AI 在这个场景里能交付什么、不能交付什么”的能力，并用工程手段保障这条线的稳定和演进。

这意味着产研不能只是等待需求输入，而要主动参与到业务场景的评估、Agent 方案的设计和产品价值的验证中。谁能在这一轮跑出来，谁就有可能重新定义自己团队在组织中的位置。

七、结语：Harness 不是 Agent 的配件，而可能是 AI 时代软件产品的新底座

回到最初的问题：软件服务商在 AI 进入之后，到底应该交付什么样的产品？

如果只是把 AI 当作一个附加功能，那么产品大概率仍停留在”更聪明的软件工具”阶段；但如果目标是交付一个能够围绕业务目标持续执行的系统，那么团队就必须面对生产级 Agent 的建设问题。而一旦进入这个层面，Harness 就不再是可有可无的技术细节，而是产品能否真正成立的关键基础设施。

从行业趋势看，Harness 的意义至少体现在三个层面：

它帮助团队把 Agent 从 Demo 变成系统；
它让自治能力具备可控、可观测、可治理的工程基础；
它为围绕垂直工作流构建自治产品提供了现实路径。

而产研团队，是让这三件事真正发生的核心力量。他们既是 Harness 的建设者，也是 Agent 产品质量的最终守门人。

因此，最好的方案未必是”谁先做出一个最通用的 Agent”，而是”谁的团队先在某个具体领域，借助 Harness 把一条真实工作流重构为稳定、自主、可规模化交付的系统”。

这类产品，一旦成立，很可能就是 AI 时代新一轮软件机会的重要来源。而能把它做出来的，一定是那些既懂业务、又懂工程、还敢于重新定义自己角色的团队。