最近有一种说法在中文圈里来回传：黄仁勋说：未来企业 AI 要建立在 Harness 上，而不是工作流，也不是业务流程。
这句话听起来很新，但要先问一个问题：原始材料到底是不是这个意思？
我把 LangChain、NVIDIA 的正式发布稿，以及几篇围绕 Agent Harness 的技术文章重新看了一遍。结论很明确：公开可查的一手材料讲的是模型之外的工程系统，而不是否定业务流程。
图1：一手材料讲的是工程系统，不是否定业务流程。
这里必须正本清源。
原始语境里，被讨论的是企业如何把模型变成可运行、可治理、可评测、可进入生产的 Agent 系统。LangChain/NVIDIA 的正式稿甚至明确把企业自己的 data、know-how 和 workflows 放在一起讲。
所以，问题不是某个人说错了，而是二次传播把一个工程词讲成了管理词的替代品。有人听到 Harness，就顺手把 workflow、business process 打倒，好像企业以后不要围绕流程建设 AI，而要围绕 Harness 建设 AI。
这就把话说歪了。
企业 AI 一定是围绕业务流程走的。离开业务流程，Harness 只是工程外壳；回到业务流程，Harness 才有任务、有边界、有权限、有验收标准。更准确地讲，在企业 Agent 落地场景里，Harness 是业务流程被工程化之后的执行载体。
图2：Harness 的价值在于让流程进入可执行状态。
一、先把 Harness 这个词讲清楚
LangChain 在《The Anatomy of an Agent Harness》里给了一个很直接的定义：Agent 等于模型加 Harness。它的意思不是“公司等于 Harness”，也不是“业务流程被 Harness 取代”，而是在 Agent 工程里，模型之外那套让 Agent 能完成任务的工程装置，都属于 Harness 的范围。
这里面包括系统提示词、工具、Skill、MCP、文件系统、沙箱、浏览器、编排逻辑、中间件、状态管理、校验钩子、执行环境和约束条件。它们共同解决一个问题：模型本身只能生成内容，Harness 才让它进入任务执行。
换成人话：模型只是“大脑”，Harness 是让这个大脑能干活的工作装置。
模型本身不能稳定记住企业状态，不能直接执行代码，不能安全访问系统，不能自己判断哪些动作允许做、哪些动作必须停下来等人确认。所有这些东西，都要靠 Harness 包起来。
所以 Harness 不是一个玄学词。它就是围绕模型搭出来的一套执行系统。技术专家如果更严谨一点，可以把它理解成 Agent 的控制面、执行外壳和工程适配层。
二、原始材料到底讲了什么
这次 NVIDIA 和 LangChain 推 NemoClaw Deep Agents Blueprint，核心不是又发布了一个模型，而是把模型、Agent Harness、评测和安全运行时放到同一个开放技术栈里。
LangChain 的正式稿讲得很清楚：生产级 Agent 不能只看模型选择，还要控制模型周围的系统，包括工具、上下文、评测、运行位置，以及每个动作适用的策略。它还特别提到，企业把 Agent 放进生产之后，记忆、workflows、执行轨迹、评测数据、Harness 配置和调优数据都会沉淀企业自己的领域经验。
NVIDIA 中文博客和 LangChain 的技术文章也指向同一个事实：性能提升不只是重训模型，很多时候来自模型周围环境的工程优化，比如提示词、工具描述、中间件、运行时和评测回路。
这才是原始材料里真正值得抓住的事。
企业不能只买一个通用模型，然后指望它自动懂自己的业务。企业真正要拥有的，是自己那套任务怎么拆、工具怎么调、权限怎么控、失败怎么回退、结果怎么评测的系统。
在 Agent 工程里，这类围绕模型的任务执行系统，可以被称为 Harness。但它并不自动回答“企业应该围绕什么设计 AI 能力”这个管理问题。
三、正本清源：企业 AI 一定围绕业务流程走
很多人误读，就误在这里。
他们听到 Harness，就以为它是一个比 workflow、business process 更高级的新词。于是顺手把旧词打倒：以后不要讲流程了，要讲 Harness。
我不认同。
企业 AI 不可能脱离业务流程。
因为企业里任何一段真正有价值的 AI 执行，都不是凭空发生的。它一定对应一个业务任务：采购申请、合同预审、客户跟进、需求评审、费用报销、供应商准入、项目周报、风险检查。
这些任务背后都有流程。谁发起，谁判断，谁审批，谁执行，谁兜底，输入是什么，输出是什么，异常怎么处理，责任怎么追溯。
Workflow 更偏“步骤如何流转”。它可以是系统里的节点、状态、条件分支、通知和任务流，也可以是自动化平台里的任务编排。
Harness 是工程表达。它把模型、工具、上下文、记忆、权限、评测、沙箱和运行时包起来，让 Agent 能在这段业务流程里稳定、安全、可复盘地干活。
所以三者不是互相替代。
更准确的关系是：业务流程是本体，Workflow 是流转表达，Harness 是 Agent 执行的工程载体。
业务流程、Workflow、Harness 不是三套彼此否定的东西，而是同一段业务能力在不同层面的表达与承载。
四、不要把载体当本体
这个问题放到企业软件史里看，其实一点都不新。
企业过去建流程能力，会用 ERP、OA、BPMS、RPA，也会用低代码平台和自动化平台。每一代工具都会说自己更先进、更自动、更灵活，但没有人会认真说：企业能力不要建在业务流程上，要建在 ERP 上；不要建在流程上，要建在 BPMS 上；不要建在业务流程上，要建在 RPA 上。
这当然说不通。
ERP 是资源和业务交易的系统载体，BPMS 是流程建模和流转的系统载体，RPA 是跨系统操作自动化的执行载体。它们都很重要，但它们都不是业务本身。真正决定企业能力的，仍然是业务对象、流程规则、组织责任、决策标准和执行闭环。
Harness 也是同一类逻辑。只不过到了 AI 时代，载体换成了 Agent 可以运行的工程装置：它可以带上下文、调工具、用沙箱、做评测、留轨迹、让人确认，也可以在研发、运营、采购、营销、风控等不同链路里接走一段活。
我自己在产品研发和协同开发里，也越来越多用这套方式工作。一个需求进来，不是先问模型一句话，而是把需求、原型、交互、任务拆解、代码修改、评测检查、发布验证串成一条新的研发链路。Agent 在里面不是聊天助手，而是接任务、跑步骤、留记录、等确认、再推进。
这件事的本质，不是“用了 Harness 所以流程不重要了”，而是 AI 时代需要重新设计研发流程、研发链路和协同方式。Harness 只是这条新链路的工程载体。没有这条链路，它就是一堆工具和配置；有了这条链路，它才变成真正可复用、可治理、可扩展的企业能力。
图3：ERP、BPMS、RPA、Harness 都是载体，业务流程才是本体。
五、为什么我说 Harness 本质上仍然离不开流程
举个采购申请的例子。
业务流程会说清楚：什么时候需要采购，什么金额走什么权限，供应商要怎么准入，预算怎么校验，哪些材料必须补齐，哪些异常必须升级。
Workflow 会把这件事做成系统里的步骤：提交申请、自动校验、主管确认、采购比价、财务复核、合同归档。
Harness 则会把 AI 接进来：让 Agent 读取申请单和附件，调用预算系统，检查供应商风险，读取制度文件，生成补件意见，判断是否触发人工确认，并把每一步执行轨迹留下来。
你看，Harness 并没有消灭业务流程。它只是在流程的关键节点上，把“人过去怎么判断、怎么查资料、怎么写意见、怎么叫人复核”变成了 Agent 可执行的装置。
如果没有业务流程，Harness 就没有业务边界。Agent 不知道什么叫合格，什么叫越权，什么叫风险，什么叫必须停下来。
如果没有 Workflow，Harness 就没有稳定的任务位置。Agent 不知道自己是在流程前、流程中、流程后，还是在异常处理里。
所以说 Harness 是流程进入 Agent 执行体系后的工程升级可以，说 Harness 让流程进入可执行、可评测、可治理状态也可以。但说 Harness 不是流程、要替代业务流程，这就把话说歪了。
六、真正该反对的，是把流程理解成画图
这里必须把另一个问题讲透。
很多人一听流程，就想到流程图。几个框、几根箭头、几个审批节点。这样的流程当然不够。
AI 时代需要的流程，不是贴在墙上的图，而是详细流程文件、规则说明、操作说明、例外处理、判断标准、输入输出、责任边界和系统接口。
只有这些东西足够清楚，才有可能被工程化成 Harness。
换句话说，Harness 不是流程管理的终结，而是对流程管理提出了更高要求。过去你可以画一张图糊弄过去，现在不行。Agent 要执行，必须知道依据是什么；Agent 要调用工具，必须知道权限在哪里；Agent 要自动推进，必须知道什么时候停。
流程越粗，Harness 越虚。流程越细，Harness 越能跑。
图4：流程图只是入口，详细流程文件才是 Agent 可执行的依据。
七、企业真正要补的是“流程到 Harness”的翻译能力
未来企业 AI 的核心能力，不是到处建聊天框，也不是追一个新名词。
真正重要的是从业务流程出发，把一段流程翻译成 Agent 能理解、能执行、能评测、能治理的 Harness。这个动作不是给流程换个英文名，而是把企业原来靠人理解、靠系统流转、靠会议协调的那套工作方式，变成 AI 可以参与执行的新链路。
这件事至少包含六个动作。
第一，把业务任务定义清楚。Agent 到底接走哪一段活，不要泛泛说“提高效率”。
第二，把流程文件写细。输入、步骤、规则、异常、输出和责任边界都要能读。
第三，把工具和系统接口列出来。能查什么，能写什么，失败时怎么反馈。
第四，把权限和人工确认设计进去。低风险可以自动，高风险必须停下来。
第五，把评测样例沉淀下来。好坏不能靠感觉，要有标准案例和回放记录。
第六，把运行轨迹留住。Agent 做了什么、为什么这么做、哪一步出错，都要能追踪。
这些加起来，才是企业自己的 Harness。
图5：企业真正要补的是流程到 Harness 的翻译能力。
最后
这场关于 Harness 的讨论，真正有价值的地方，是提醒企业不要只盯模型。
模型会越来越强，也会越来越便宜。真正决定企业 AI 能不能落地的，是模型周围那套系统：上下文、工具、权限、执行、评测、审计和运行时。
但这不意味着业务流程不重要。
恰恰相反，业务流程会变得更重要。因为所有 Harness 的业务语义，都来自流程。没有流程，Harness 只是技术外壳；没有 Harness，流程仍然停在纸面和系统节点上。
所以我更愿意把这句话说清楚：未来企业不是不要业务流程，而是要围绕业务流程建设 AI 能力，把关键流程升级成 Agent 可执行的 Harness。
把企业能力建在 Harness 上，而不是建在业务流程上，这句话听起来很新，其实逻辑上站不住。就像不能说企业能力不要建在业务流程上，要建在 BPMS 上；也不能说企业能力不要建在业务流程上，要建在 RPA 上。BPMS、RPA、Harness 都是载体，业务流程才是企业能力真正发生的地方。
流程管理者也不要被新词吓住。
你真正要做的，不是放弃流程语言，去追一个英文概念；而是把流程文件、规则、操作说明、异常处理和系统能力，翻译成 AI 可以工作、企业可以治理、结果可以检验的产品能力。
这才是 Harness 和业务流程的真实关系。
Harness 不是流程的敌人。
它是业务流程进入 AI 工程之后的一种关键表达式
