给AI换个大脑没用，先看看它手里的工具够不够趁手

你有没有遇到过这种情况：请了一个非常聪明的新同事，结果第一周他天天出错，不是因为他笨，而是因为没人告诉他公司系统怎么用，哪个按钮点了会出bug，哪份文档写着但已经过时了。等你把这些"潜规则"一条条讲给他听之后，他立刻像换了个人一样高效。

这篇论文讲的就是这么一件事，只不过主角不是新同事，而是大语言模型智能体。

**核心问题：模型越换越强，但企业里的活儿还是干不好**

过去两年,大家做AI智能体优化的思路基本是一条路：换更强的模型。GPT从5.0升到5.4再到5.5,Qwen也在不断迭代。可是ServiceNow的研究团队发现一个挺尴尬的事实：就算你把模型换成当时最先进的版本,在真实企业场景里表现依然很拉胯。

拿论文里的三个测试场景来说。第一个叫ITBench,考的是运维工程师最头疼的活儿,根因分析：系统出了故障,一堆日志、指标、调用链摆在你面前,你得从中间揪出到底是哪个环节坏了。第二个叫EnterpriseOps-Gym,考的是IT服务管理,比如处理工单、变更审批,做完之后要满足数据库里严格的状态校验。第三个叫AutomationBench,考的是财务自动化,横跨47个模拟的SaaS应用做报销、对账之类的工作。

在这三个场景下,用默认配置直接跑GPT-5.4(中等推理档),成绩分别是40.0%、23.3%、57.1%。这什么概念？EnterpriseOps-Gym这个场景,一百个任务里模型能做对的还不到四分之一。这不是模型笨,这是模型压根不知道这个环境的规矩。

问题出在哪儿？出在**智能体外壳**（Harness*：指包裹在大语言模型外面的一整套执行框架,包括提示词、工具接口、任务拆分逻辑、执行策略等,决定了模型如何理解环境、调用工具、判断任务是否完成）身上。模型的工具接口写得含糊,模型不知道该传什么参数；企业系统有一堆约定俗成的规矩,比如改工单优先级必须同时改影响度,这些规矩工具schema里根本没写；还有很多重复性的推理工作,比如日期换算、故障链路排查,本该用固定套路解决,结果每次都让模型现场"发明轮子"。

这就好比给一个厨艺精湛的大厨,扔进一个从没进过的陌生厨房。刀在哪个抽屉、哪个灶眼漏气得小火慢炖、冰箱里哪瓶调料其实过期了没标签,这些事厨艺再好也帮不上忙。你要么换个更贵的厨师(换模型),要么干脆把厨房收拾一遍,把这些隐藏信息明明白白贴出来。研究团队选的是后者。

**方法核心：让外壳自己进化，模型权重一动不动**

StarHarness要做的事情说白了很简单：**只改外壳，不碰模型**。

具体怎么改？论文设计了一套叫做**分层搜索**（Stratified Search*：先按任务的失败类型、得分、验证通过率对任务分组,再从每组里抽样,保证搜索样本能覆盖各种失败模式,而不是只覆盖某一类简单任务）的流程,让一个AI（叫做"提出者"）去读取当前外壳的代码和一批任务的执行记录,分析哪里出了问题,然后写一个补丁去修复。

这个提出者本身也是跑在一个叫**Oh My Pi**（一种基于Pi Agent的编程智能体框架,论文里用它来执行外壳的修改、验证和评测流程）的编程框架里,它能读取被测外壳（叫Stirrup）的源码,提出补丁,跑测试,看效果好不好,好就留下,不好就撤回。

这里有个很关键的设计：**任务要分成三份，提出者只能看到其中一份**。

第一份叫**搜索集**,提出者能看到这些任务的执行轨迹和结果,用来诊断问题在哪；第二份叫**选择集**（Selection Set*：提出者看不到具体内容和轨迹,只有系统内部拿这批任务打分,决定一个补丁是否被接受,相当于一个隐藏的"期中考试"）,用来给补丁打分,决定接不接受这次修改,但提出者完全看不到里面是什么任务；第三份叫**留出集**（Holdout Set*：整个进化过程完全不参与,只在最后用来检验进化出来的外壳有没有"真本事"),彻底封存,直到最后一次性拿出来验证。

为什么要这么麻烦地切三份？

想想学生备考的场景。如果老师只给学生看考试原题去练习,学生考出高分不代表他真学会了,他可能只是把答案背下来了。真正想知道学生学没学会,得用没见过的新题来考。这里的道理一样：如果提出者能看到所有任务的评分反馈,它完全可能"偷懒"直接针对具体题目打补丁,而不是真的去修复一个通用的接口问题。选择集的隐藏性,加上留出集的彻底封存,逼着提出者只能去修那些真正普遍存在的毛病,不能去死记硬背具体答案。

论文里还专门列了几条**护栏规则**,禁止补丁按任务ID做判断、禁止把验证答案写进提示词、禁止访问隐藏的标准答案表。这些规则的作用也很直白：防止"作弊",让进化出来的东西是真本事,不是投机取巧。

进化的具体流程走三步：提出、验证、评测。系统先让提出者写一个补丁,验证器检查这个补丁有没有越界改到不该改的地方,然后拿一个任务做"冒烟测试"，如果连这一个任务都没修好,直接打回,省得浪费算力去跑全套评测。通过冒烟测试的补丁,才拿到隐藏的选择集上正式评分,分数比之前的版本高,才被采纳,成为新的基准版本。

这个"先冒烟测试再正式评测"的设计,类似汽车厂做碰撞测试之前会先做个简易模拟。如果不做这道预筛,每次改动都直接上全套昂贵的实车碰撞测试,成本会爆炸,而且大部分明显不靠谱的方案根本不需要走到这一步。

论文还用了两种搜索策略做对比实验。一种叫**爬山法**（Hill Climbing*：每次只保留一个"当前最好"的版本,新补丁必须严格打败它才会被采纳,否则就撤销,是一种步步为营、只往一个方向走的搜索方式）,简单直接,但容易卡在局部最优；另一种叫**树搜索**（Tree Search*：同时保留多个候选分支,可以合并不同分支的优点,探索完再选出最强的那条分支继续往下走）,更耗资源但探索面更广。

论文在EnterpriseOps-Gym上专门测了这两种策略配合使用的效果,先用树搜索广撒网找到几个有潜力的方向,再用爬山法精细打磨。最后12个被采纳的补丁里,8个来自树搜索阶段,4个来自后续爬山阶段。这跟先头脑风暴列一堆方案,再挑一个最靠谱的方案精细化执行,是同一个道理。如果一开始就用爬山法直奔一个方向,很可能一头扎进死胡同,错过了更好的解法。

**结果：20到35个百分点的提升，而且不是白来的**

三个场景跑下来,进化后的外壳相比默认外壳，全benchmark的成绩提升了20到35个百分点。

ITBench从40.0%涨到75.0%，提升35个百分点。EnterpriseOps-Gym从23.3%涨到43.7%，提升20.4个百分点。AutomationBench从57.1%涨到83.2%，提升26.1个百分点。

这个提升幅度是什么概念？想象一次考试原本每五道题错三道,现在变成每五道题只错一道多一点。而且整个过程只用了4到12次被采纳的修改,ITBench只改了4次,AutomationBench改了5次,EnterpriseOps-Gym改了12次。改动次数不多,但每一次都踩在了要害上。

更重要的是,这个提升不是靠死记硬背题目刷出来的。论文专门测了**留出集**（前面提到过,是完全没参与进化过程的任务)的表现,发现ITBench在留出集上依然涨了31.7个百分点,EnterpriseOps-Gym涨了15.1个百分点,AutomationBench涨了29.3个百分点。这说明进化出来的东西是通用的环境适应能力,不是针对特定题目的投机取巧。

还有一个挺有意思的发现：这个进化出来的外壳,拿到别的模型上用,居然照样管用,而且不用重新进化。研究团队用GPT-5.4进化出来的外壳,直接拿去测Qwen3.5、Qwen3.6、GPT-5.4-mini、GPT-5.5,结果全部都涨。ITBench上,Qwen3.5-27B从25.6%涨到70.0%,涨了44.4个百分点，这个涨幅比GPT-5.4自己进化的涨幅还大。

这就好比一套写得很清楚的操作手册,不管是老员工还是新员工来用,都能少踩坑,因为坑本身就被填平了,不是靠某个人的经验去绕开的。

**外壳到底改了什么：三类问题的修复**

论文用trace分析（也就是看具体的执行记录）把这些改动归成了三类。

第一类叫**接口修复**。企业系统的工具接口经常有各种坑,比如EnterpriseOps-Gym背后连的是一个ServiceNow数据库,通过**MCP**（Model Context Protocol*：一种让AI模型调用外部工具和数据源的标准化协议,类似给AI装了一套"插座标准",不同工具只要遵守这个协议就能被模型调用）来交互。这个数据库对参数要求特别严格,如果你传了一个多余的空值字段,直接报错拒绝。进化后的外壳学会了在调用之前把这些无用的null值、空值、占位符参数统统清理干净,同时把重要的字段结构保留下来。

对照一下另一个工具Codex的默认处理方式,发现两者思路殊途同归,Codex靠的是标准化压缩schema,StarHarness学到的是先精简再清洗参数,结果分数上StarHarness的43.7%还略高于Codex的41.7%。

这就像去银行办业务,柜台要求你填的表格里有些字段留空会被打回,有些字段乱填也会被打回。一个熟悉柜台规矩的老员工,会提前把表填得干干净净,不该填的地方绝不乱填,这样一次通过。一个新手可能填了一堆试探性的内容,来回被打回好几次才办成,浪费的是时间和银行的耐心。

第二类叫**环境惯例**。有些规矩是这个环境里心照不宣的常识,但工具接口从来不会主动告诉你。比如在EnterpriseOps-Gym里,修改工单的优先级必须同时联动修改影响度和紧急度这两个字段,这是ITSM系统里的隐性规则。再比如AutomationBench里,财务系统里的"相对日期"（比如"三天前"）必须锚定到沙箱环境自己的系统时钟,而不是模型自己以为的当前时间,不然算出来的日期全错。进化后的外壳把这些惯例写进了系统提示词里,变成了显性的操作指南。

这类似老员工带新人的场景。新人第一天上岗,没人告诉他"周三下午系统会自动备份,那时候提交的数据要延迟同步",他自然会踩这个坑。老员工把这条不成文的规矩写进入职手册,新人以后就不会再犯。

第三类叫**操作知识和搜索压缩**。有些工作本可以用固定套路解决,不需要每次都让模型现场从零推理。比如ITBench进化出了一个"取证概览"工具,能自动从证据里排出候选故障源的优先级顺序；AutomationBench进化出了专门的日期计算器和财务计算器,把容易出错的算术和日期推算,从模型的开放式推理里剥离出来,交给确定性的工具去做。

这就好比会计做报表,如果每笔计算都靠脑子心算,出错概率会随着计算量线性上升。给他配一个计算器,同样的计算瞬间变得又快又准。模型的"脑子"擅长的是判断和推理,不擅长的是重复性的精确计算,把这类活儿分流出去,是在扬长避短。

**具体的执行轨迹变化：更快、更准、更省钱**

论文还提供了详细的执行记录对比,数字很扎实。

ITBench场景下,进化前平均每个任务要走25.2轮对话,进化后降到22.1轮；误报（把没问题的地方当成故障根因）从0.79降到0.33，几乎降了一半；真正命中的（真的找到了故障根因）从0.45涨到0.78。每个任务的API调用成本从3.26美元降到2.70美元，降了17%。

EnterpriseOps-Gym场景下,变化更明显。每任务对话轮次从18.12降到9.87,工具调用次数从29.53降到16.83，几乎砍半。成本从1.23美元降到0.58美元，降了53%。验证通过率从34.5%涨到72.8%。

AutomationBench场景下,任务完成度评分从67.3%涨到86.1%；出现安全违规的任务数从20个降到4个,总违规次数从33次降到4次；得零分的任务从24个降到6个,足足少了18个。

|指标|ITBench基线|ITBench进化后|EnterpriseOps基线|EnterpriseOps进化后|AutomationBench基线|AutomationBench进化后|

|任务成绩|40.0%|**75.0%**|23.3%|**43.7%**|57.1%|**83.2%**|

|每任务成本|$3.26|**$2.70**|$1.23|**$0.58**|$0.14|**$0.10**|

这组数据说明一件事：外壳进化不是拿更多算力和更长的思考换来的效果提升,恰恰相反,是让模型少走弯路、少犯低级错误换来的效果提升,顺带把成本也降下来了。这跟很多人对AI优化的直觉正好相反,大家通常觉得效果更好意味着要烧更多算力,但这里效果更好反而更省钱,因为真正浪费算力的不是"思考不够",而是"绕了太多弯路"。

**目前的局限：进化不是万能药**

论文也很坦诚地指出了一些局限。ITBench的回归案例里,有些情况是模型在找到近端故障原因之后,还继续往上游搜索,本该停下来的时候没停,反而把已经找对的答案又推翻了。这说明进化出来的外壳还没能完全解决"什么时候该收手"这个判断问题。

而且论文反复强调,没办法把每一条补丁的贡献单独剥离出来验证,只能看整体效果的变化。这是一种诚实的局限说明,不是每个企业级AI优化工作都会主动承认自己没做到的地方。

Q&A

Q1：StarHarness是什么？

A：StarHarness是ServiceNow团队提出的一种框架,专门用来进化AI智能体的外壳(包括提示词、工具接口、执行策略等),而不改动模型本身的权重,目的是让固定的大模型更好地适应企业环境的复杂规矩。

Q2：StarHarness进化出来的外壳能不能换到别的模型上用？

A：可以。论文实测把用GPT-5.4进化出来的外壳直接拿去测Qwen3.5、Qwen3.6、GPT-5.5等模型,结果全部有明显提升,不需要针对新模型重新进化,说明改进的是环境适应能力而不是针对某个模型的特殊技巧。

Q3：StarHarness进化外壳主要修复了哪些问题？

A：主要是三类：一是工具接口的参数处理错误,比如清理无效空值参数；二是把企业系统里隐性的操作惯例写清楚,比如字段联动规则；三是把重复性推理工作(如日期计算、故障排查)固化成确定性工具,减少模型现场瞎猜。