从Prompt到Harness：Agent进入企业需要流程治理吗

AI技术正在经历一场深刻的范式转变。从早期的提示词工程（Prompt Engineering），到上下文工程（Context Engineering），再到如今的驾驭工程（Harness Engineering），我们与AI系统的交互方式不断升级。提示词工程关注如何准确表达指令，上下文工程关注如何为模型提供合适的信息、工具和状态，而驾驭工程则开始处理Agent在真实环境中的约束、观察和修正机制。这标志着我们对Agent的期待已经从“表现得足够聪明”升级到“在一个被约束、被校验、被反馈的环境里稳定工作”。

企业Agent治理的三大核心问题

然而，当这些被驾驭的Agent试图进入企业时，我们发现单纯的技术harness仍然不够。在技术语境中，harness为Agent配置了一套执行规范：规定Agent能看到什么、能调用什么工具、输出要满足什么格式、执行过程如何被记录、错误如何被发现、反馈如何重新进入系统。但企业面对的不仅是行为失控的问题，更是Agent进入组织后的边界划分、责任归属以及灵活性处理等深层次挑战。

演示环境与生产环境的本质鸿沟

企业的流程治理决定了更精细化的Agent适配。具体而言，企业需要解决三个核心问题： 第一是定边界。企业需要明确哪些事项可以自动处理，哪些只能生成建议，哪些必须人工确认，哪些根本不能进入自动执行。这涉及到对业务流程的全面梳理和风险评估。 第二是定路径。包括正常情况下的流程流转、异常情况下的分流机制、卡住后由谁接管、退回后如何重新进入流程等。这需要建立清晰的决策树和升级机制。 第三是定责任。明确谁授权、谁审批、谁复核、谁保留记录，出了问题谁能解释清楚。这涉及到组织架构的调整和责任体系的重建。

采购申请Agent的失败启示

很多Agent项目在演示阶段推进顺利，但一到上线就突然变慢。根本原因在于：演示环境里最重要的是完成任务，证明功能可行性；而生产环境里最重要的是控制后果，承担相应责任。两者看似只差一步，实际上隔着一整套组织秩序。 一家企业曾尝试将采购申请的初审交给Agent处理。团队做了充分准备：制度文件入库、预算和供应商信息接入、输出格式约束、关键字段校验。然而上线测试时，业务部门提出了诸多具体问题：申请金额临近审批阈值时谁来决定放行？预算系统数据未更新时Agent建议是否有效？临时特批如何识别？申请人被拒绝后能否看到明确依据？出现争议谁来解释判断依据？由于这些问题无法得到有效解答，项目最终不了了之。

技术推动的业务变革

这个案例深刻揭示了一个道理：Harness不是流程治理的替代品，流程治理也不是Harness的上位概念。两者处理的是同一条价值链上的不同问题。Harness解决的是Agent在系统中如何可靠地产生结果，而流程治理解决的是这些结果进入企业后如何被授权、被审阅、被接管、被追责。没有Harness，Agent的行为不稳定；没有流程治理，Agent的行为无法在企业环境中真正成立。 从历史视角看，1712年纽可门蒸汽机发明到1780年瓦特改良蒸汽机在工厂里被广泛应用，中间花了65年。企业需要时间去理解、思考和适应新技术带来的能力边界和变革方向。当AI团队开始谈论硅基Agent的harness时，很快就会遇到一个现实边界：系统看起来已经具备能力，但组织却仍然不敢放权。原因已经不在技术层面，而在于组织尚未准备好承接这一能力。

如有侵权，请联系删除。