9 月 22 日提交的 arXiv 论文 2609.26760（Growing Harness）提出一个反直觉的思路：当智能体要处理一批相关任务，与其每次都把「怎么控制流程」写死在提示词里，不如让失败反馈把这部分控制直接「长」成可复用的代码。论文把这种范式叫 Growing Harness——一个从「无策略脚手架」里长出控制结构的训练流程。
具体分几步。脚手架只暴露固定的模型与工具接口，但本身不包含任何任务求解的控制器；智能体在任务上跑，函数级执行轨迹把每次失败定位到一块有边界的代码面上；优化器针对一小段失败做联合修复；最后一道「先成功、再放行」的保留门，会回滚那些伤害了已有能力的修复。被接受的修改累积进同一个共享 harness，于是控制结构从任务反馈里自然涌现，而非由人预先指定。
收益直接体现在成本与可部署性上。在 BrowseComp-Plus 与 WebArena-Verified 上，跨 4B 到 120B 三种部署模型，Growing Harness 在六项基准模型设定里有五项拿到平均最高成功率，第六项也只差 0.7 个百分点。更关键的是相对开销：相比朴素工具调用智能体，它把 LLM 调用次数压低 76.0% 到 91.8%，部署侧推理成本降 74.4% 到 98.6%。在 WebArena-Verified 上，它的成功率在 4B 小模型上仍维持在 44.7% 到 45.3%，而朴素工具调用在 4B 上掉到 6.7%。
这背后是一条清晰的逻辑：很多重复的控制决策（先调哪个工具、失败重试几次、何时汇总）其实不必每次都请大模型现想，可以沉淀成低成本代码常驻。把「控制权」从上下文里搬出来，既省 token，又让小模型也能撑起复杂任务。它和近期另一支研究（SAT 从少量样本学出可迁移协作剧本）方向一致——智能体系统的上限，越来越取决于「控制与协作结构能否被学习、被复用」，而不只是底座模型多强。
当然，把控制长成代码也不是免维护的银弹。共享 harness 随着任务不断累积修复，本身会变成一个需要版本管理与回归测试的 codebase——它把「上下文随任务变长」的麻烦，换成「代码随使用变厚」的维护成本。适用边界也比较清楚：当一类任务被反复执行、控制决策高度重复时，沉淀代码才划算；对一次性的、高度开放的探索型任务，现想现做的提示词反而更灵活。Growing Harness 真正的贡献，是给出了一种「让控制结构从使用里自然长出来」的机制，把过去靠资深工程师反复手调提示词的黑活，变成可累积、可回滚、可复用的工程资产。对工程团队而言，与其在每次新任务前重写一版长长的控制提示词，不如先设计一套能记录「哪些控制该固化成代码」的 harness——让系统随使用变厚，而不是让上下文随任务变长。
照例留一分冷静：论文数字是自报，基准集中在 BrowseComp-Plus 与 WebArena 一类网页任务，换到带长程工具调用或强约束的领域能否保持，待社区复现；「从失败里长代码」的修复质量，也高度依赖那道保留门的设计。但对工程团队，可操作的启示很直接：与其反复手调提示词里的控制流程，不如先设计一套能把「哪些控制该固化成代码」记录下来的机制——让 harness 随使用变厚，而不是让上下文随任务变长。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。