Harness 会替代固定工作流吗：智能探索与流程可控，本就不是一个赛道

　　最近 “Harness” 这个词在 Agent 圈子里很流行。它内核里确实包含一套强管控的升级版 Runtime Loop，但把它说成"把过去的循环升级一版"其实不够准确——它更像是一整套完整的智能体运行操作系统：独立的状态持久层、任务 DAG（有向无环图）编排、MCP 网关、权限沙箱、执行链路观测、异常事务回滚，都在它的体系之内，Loop 只是其中一个核心执行单元。它能自主任务拆解、运行时纠错、checkpoint 快照、死循环防护，还会在报文上做工程化的固定写法，去最大化命中厂商磁盘上的 KV 推理缓存，把长任务的 token 成本压下来。

　　顺带厘清一点：KV 缓存是底层 API 服务本身的能力，Harness 并不生产缓存，它只是通过标准化报文去蹭命中率，属于附属的成本优化手段，并非核心功能。听起来很美好，但聊得越深，我越觉得它和另一条路——开源框架里写死的固定工作流——根本不是同一个东西，更谈不上谁取代谁。

　　先看行业这两代 Agent 卖点的变化。上一代主打"越用越懂你"，靠长期记忆和会话沉淀，适合持续的对话交互；可一遇到多步复杂长任务，就容易失忆、死循环，执行的稳定性很差。于是这一代就转向了"自主循环拆解规划、自主纠错、执行复杂任务"。Harness 和 ZCode 这类工具，本质上都是这套升级版 Runtime Loop 的产物。它们最大的共同点，也是最硬的痛点，是黑盒执行。

　　什么是黑盒？就是任务路径不由人完全掌控。你给一个目标，它内部怎么做 DAG 拆解、什么时候生成子任务、什么时候重试、什么时候重规划，是框架加模型共同决定的。哪怕你心里清楚最简路径就三步，它也可能多绕几个弯，凭空多出第四、第五个步骤，白白浪费时间、消耗 token。你只能通过提示词去引导，却没法硬性锁死整条执行链路。更麻烦的是它深度绑定自家模型——换一个模型，整套缓存优化、联合调优的收益当场归零。这种"不可精确管控、不可严格复现"的属性，对某些场景是救命稻草，对另一些场景却是纯负担。

　　另一类是专业开发者，业务步骤自己能提前梳理清楚。既然流程我知道 A 之后是 B、B 之后是 C，哪一步可以跳过、哪种情况要重试，我全都心里有数，那我要的根本不是 AI 临场脑补规划，而是按我规定的路径跑。这时候写死的固定工作流就完胜：步骤、顺序、分支、是否重试，全部由配置文件定义，绝不私自新增步骤，时间与调用量可预判，模型随便换，数据完全自持。Harness 那套动态重规划、checkpoint 回退、死循环检测，对我不是加分项，反而是多余的复杂度。我要的是可控，不是智能探索。

　　这两类需求，其实天然分叉。Harness 优先保证"任务尽量做完"，代价是流程不可控、允许它自己绕路加步骤，适合目标明确但不知道怎么做才好的开放场景；固定工作流优先保证"按我规定的路径跑"，绝不私自乱来，适合我已经知道最优路径、出意外就按写好的规则处理的确定性业务。前者的自动纠错回退能力确实强，可如果你的业务本身就不允许机器自作主张改执行序列，那这套能力反而变成负担——我宁愿它直接报错失败，也不希望它私自换一套方案去执行。这种场景，固定工作流就再合适不过。

　　更有意思的是，工程上这两条路并不互斥，反而大量出现混合模式：主流程走固定工作流，遇到个别模糊未知的子环节，再调一层 Harness 做局部探索。OpenClaw 这类开源底座做网关调度，把 Harness 包装成一个 MCP 子能力，复杂探索交给它，固定流水线依然走本地 YAML。说白了，智能探索和流程可控，本来就是两类需求，不存在一套技术通吃全部。