前两天我发过一条帖子，讲的是有人分享的企业 AI 落地套路。先让 Codex 把流程跑通，再把 Codex 请出去，留下的是一个 Python 脚本、一个按钮、一个定时任务。这篇顺着这段话往下想，配一篇 Google Cloud AI Research 的论文 Harness² 当数据。先把边界说清楚，这是资料解读加工程判断，那套做法不是我落地过的，文中的 Java 和 Spring 例子也都是假设场景，用来说明思路。

那段话里我最在意的是这一句。

Agent 探索期要的权限很宽，脚本只要那几张表。

探索和执行，本来就是两种活

让 Agent 去摸一个新流程，它得能读很多东西。要翻库表结构，要看历史数据，要试接口，要跑几遍错的再跑对的。这个阶段给它的权限，天然就宽。你很难提前知道它需要哪张表，只能先放开，再看它碰了什么。

流程一旦跑通，事情就变了。

每天凌晨把某几张表对一遍账，生成一份报表，发到某个群。这件事需要的权限其实很少，两张表的只读，一张结果表的写入，一个发消息的接口。剩下那些探索期开过的口子，生产里一个都用不上。

如果还让 Agent 每天去做这件事，你等于把探索期的宽权限，原样带进了生产。它每次运行都是一次新的推理，路径可能和昨天不一样。日志是一长串思考和工具调用，出了问题你得先读懂它当时在想什么，才能知道它为什么多删了一行。

换成脚本，权限可以收到那几张表，日志就是几行 SQL 和一个返回码。出事好查，因为它每次走的路都一样。

那段话的最后一句是，别让 agent 天天在生产里即兴发挥。我觉得这话不算保守，它讲的是一条很老的工程常识，探索的成本和执行的成本，不该混在一起付。

外围一直在被改，这件事有数据

可能有小伙伴觉得，Agent 的能力在涨，今天跑不稳的流程，过两个月换个模型就稳了，何必急着固化。

Harness² 这篇论文给了一个有点反直觉的角度。它没动模型。

论文把模型参数冻结，只改模型外面那一圈，作者叫 harness。具体拆成 8 个组件，系统提示词、护栏、记忆、skill、工具说明、脚本、子 Agent、中间件插件，每个组件都是运行时里挂载的一个文件。他们做的事情，就是让一个编辑器 Agent 去读执行轨迹，提出对这些文件的修改，在相同条件下试跑对比，再把有证据支持的改动组合起来。

结果是这样的。在 WorkBuddy-Bench 上，GLM-5 配 OpenCode 的基础 harness 平均分 64.2，只做一步改进（论文里 k=1），平均分到了 75.7，涨了 11.5 分。同一张表里，Gemini 3.5 Flash 配原版 OpenCode 的平均分是 72.4。弱一点的模型，换了一套更好的外围，跑赢了强一点的模型配原装外围。这些都是三次运行的均值，平均分是 Code、Web、Office 三个领域的宏平均。

权重一个没动，分数涨了 11 分多。

这组数字对我来说，重点不在涨了多少，而在它说明了一件事。决定一个 Agent 在具体任务上表现的，有相当一部分是外围那几个文件。而这几个文件，在论文的设定里是随着任务流一直被改的。

回到脚本这件事。把一个跑通的流程固化成脚本，其实就是把外围冻结下来，而且冻得更彻底，连模型都拿掉了。所以真正的问题从来不是 Agent 好不好，而是这个流程的外围，现在还需不需要继续调。

还在调，就留着 Agent。调不动了，或者调的收益很小了，就该冻结。

不验证就改，会比不改更差

论文里还有一个细节，我觉得比主结果更值得做平台的人看。

第 4 节分析部分，作者测了一种简化做法，直接让编辑器去改基础 harness，不给它参考执行、不做候选试跑、也不用积累下来的改进库。结果在 Code 和 Web 两个领域都退步了，Code 从 73.4 掉到 63.2，Web 从 69.9 掉到 65.0。

Code 掉了十分多。

这里要说清楚口径。论文拿掉的是三样东西一起，参考执行、候选试跑和改进库，不是单单「不跑测试」。所以我不会把它简化成「不跑测试就改，分数掉 10 分」。但它至少说明，一个能改自己外围的系统，如果改动之前没有对照证据，改完可能比原来还差。

论文在局限性里也写得很克制。没有标准答案的时候，改进只能依赖行为对比和模型判断，这些信号对执行波动和模型自身的偏差都敏感，不能保证改动是对的，也不能保证换个任务还成立。

放到生产里，这话的分量就更重了。实验里退步只是分数低了，生产里退步可能是一笔账算错了。

什么时候该固化成脚本，三条清单

我把判断条件压成三条。三条都满足，就可以考虑把 Agent 请出去。缺一条，先别急。

1. 流程是否稳定、可复现

  • 怎么查：把 Agent 最近若干次成功运行的工具调用序列拉出来比。如果每次碰的表、调的接口、步骤顺序基本一致，只是参数不同，它就已经是一个脚本了，只是还没写下来。
  • 怎么查：拿同一份输入让它跑两遍，结果是否一致。不一致的部分，要么是流程本身没定，要么是 Agent 在即兴发挥，两种情况都不该直接上生产。
  • 不满足时：流程还在变，继续留在探索区，别急着冻。

2. 输入是否有边界、可校验

  • 怎么查：能不能用一份 schema 写清楚输入长什么样。字段、类型、取值范围、上下游表名，写得出来就有边界。
  • 怎么查：碰到不合法的输入，能不能在入口就拒绝，而不是指望处理逻辑里聪明地绕过去。
  • 不满足时：输入是自由文本、开放网页、客户随手发来的附件，这类边界本来就不清楚，硬写成脚本只会写出一堆 if-else，最后还是兜不住。

3. 出错能否回放、能否回滚

  • 怎么查：失败的那一次，能不能用同样的输入在测试环境原样再跑一遍，复现出同一个错。
  • 怎么查：它写下去的数据，能不能按批次撤销。有没有幂等键，重跑会不会重复写。
  • 不满足时：回放不了就没法定位，回滚不了就没法止损。这种流程，不管谁来跑，都得先补上这两样，再谈固化。

这三条其实是同一个意思的三个面。脚本的好处是确定，而确定只有在流程、输入、出错处理都确定的时候才成立。

哪些流程不该固化

清单反过来看，也就知道哪些事该继续留给 Agent。

一类是输入开放的。客服工单的分类和初步回复，每天进来的问题都不太一样，你很难写出一份穷尽的规则。

一类是还在演化的。新业务线刚上，报表口径每周都在改，这时候固化，等于每周重写一次脚本，不如让 Agent 先跑着，把口径稳定下来。

一类是需要判断的。排查一次线上异常，要看日志、看监控、猜原因、验证猜测。这件事的价值就在于每次的路径不同，固化成脚本反而丢了它最有用的部分。

还有一类，是本身就是探索的工作。比如定期扫一遍依赖、看看有没有可以合并的重复代码。这种事要的就是 Agent 的发散，把它写死，它就只能发现你已经知道的问题。

这里我也不太确定边界在哪。很多流程是一半能固化、一半不能，下面这个中间形态，可能才是大多数团队真正会用到的。

中间形态，Agent 写脚本，脚本跑生产

我更倾向的做法是把 Agent 的位置挪一下，不是请出去，而是请到旁边。

Agent 生成脚本。 探索期 Agent 跑通流程后，让它把成功的那条路径写成脚本，交给人审，走正常的 PR。脚本进仓库，有版本，有 diff，有人签字。

脚本跑生产。 每天定时执行的是脚本，不是 Agent。权限按脚本需要的那几张表来开。

Agent 只在异常时介入。 脚本失败、校验不过、数据量突变，这时候才把 Agent 叫进来，给它看失败的上下文，让它诊断，提出修复。修复本身仍然走一遍生成脚本、人审、上线的路。

权限分级。 同一个 Agent，在不同阶段拿不同的权限。探索期在隔离环境里拿宽权限；诊断期在生产里只拿只读；修复期它只能提 PR，不能直接写库。

落到 Java 和 Spring 的平台上，我会这么设想（假设场景，不是我做过的）。

假设有一个每天凌晨对账的任务。探索期，Agent 在一个只连脱敏副本的环境里跑，摸清楚要读哪几张表、怎么关联、差异怎么判定。跑通之后，让它把逻辑写成一个 Spring Batch 的 Job，或者一个简单的 @Scheduled 方法，配一个专用的数据库账号，只授予那两张表的 SELECT 和结果表的 INSERT。

运营同学要手动补跑，就在管理后台加一个按钮，后面调的是同一个 Job，参数用表单约束死，日期选择器而不是自由输入框。

审计日志记三样东西，谁触发的（定时还是哪个人点的按钮）、输入参数、影响行数。这三样在脚本里是天然确定的，几行就记完了。换成 Agent 来跑，你要记的是整条推理和每一次工具调用，日志长度差了几个数量级，真出事的时候能不能翻得动是另一回事。

Job 失败时，告警里附上失败批次和异常栈，再触发一个诊断用的 Agent。它拿的是只读账号，产出是一份诊断说明加一个修复 PR。要不要合，人说了算。

这套东西没什么新鲜的，定时任务、最小权限、审计日志，Java 平台上做了很多年。Agent 进来之后，这些老规矩不是过时了，反而更该守。

什么时候继续调，什么时候冻结

回到 Harness² 的那组数字。

它证明外围值得调，调好了能让弱模型跑赢强模型。它也证明外围不能乱调，没有对照证据的改动会让结果变差。这两点放在一起，就是一个很朴素的工程节奏。

调的阶段，在隔离环境里调，每次改动要有对照，要能比较改之前和改之后。

冻的阶段，把调好的东西写成脚本或者固定配置，放进版本库，权限收窄，日志变短。

再出问题，先解冻一小块，在旁边调，调好再冻回去。

我始终坚信，生产环境最需要的不是聪明，是可预期。Agent 的聪明应该花在找到那条路上，路找到了，就让脚本去走。

参考资料

  1. Ruiyao Xu 等，Harness²: Recursive Agent Harnessing for an Open World，Google Cloud AI Research，arXiv:2610.14224，https://arxiv.org/abs/2610.14224 （HTML 版 https://arxiv.org/html/2610.14224）
  2. Harness² 代码仓库，https://github.com/google-research/harness2
  3. 晨 10/19 在 X 上转述的「有人分享的企业 AI 落地套路」，https://x.com/Channing_AI_X/status/2112192310930968804