https://factory.com/news/frontier-harness，看看这个

回复 群友 2236： 看完了。这篇是 Factory 发 Droid 1.0，核心一句话：model 已经是商品，护城河在 harness。对你在做 pa 这方面，有几个点值得抄。 一、他们的判断口径 定义很干脆：harness = 模型之外的一切（prompts、tools、tool 结果怎么回来、跑它们的 loop）。他们强调 agent 现在跑几小时到几天、几百轮，每一轮都要重发 instructions、tools、history，所以 harness 的每一分浪费都是复利式的。 二、最大的改动：programmatic tool calling（PTC） 不再让模型一个个调工具、每个结果都塞回上下文，而是让模型写一段程序去调工具。文章里两个真实例子最能说明差距： Linear 清理，151 个 issue 改状态并逐个校验，共 312 次工具调用。直调模式每轮重发 instructions 和越来越长的历史，就算每请求 10 次调用也要 36 个请求、读约 310 万 input token；Script 模式只要 2 个请求 token——一个写程序，一个读它打印的 6 行。 CI 扫一遍，547 个 run、5384 个 job、550 次工具调用，模型只看到五个数字的汇总（含 41 个失败），原始结果进上下文的不到 0.1%，而且它是后台跑了 8 分钟，模型同时干别的。 三个收益分别是：上下文干净、模型请求数变少、循环和校验在代码里确定性执行（不会出现"计划里说检查 15 个字段，实际偷懒只比 2 个"）。 几个关键设计选择，抄的时候用得上：程序拿到的是真实数据（整文件和结构化搜索结果，过滤计数在代码里做，不花 token）；文件内容、patch、命令走原始文本块而不是转义字符串；编辑返回短摘要不回灌全文；程序最长等 5 分钟就交回当前输出，还能后台起；另设一个工具查状态，不靠轮询。 三、prompt cache 这条更对付费系统有直接意义 provider 按前缀缓存，任何改动都让后面全部失效。他们把中途发现的 MCP 工具追加到请求末尾而不是插进工具列表——同样加载一个工具，从" token 重新处理"变成"1500 新 token，10 万走缓存"。现在生产里典型请求 98% 输入来自缓存，98.6% 的请求是严格 append-only，还专门做了个监控逐请求比对、指出是哪段破坏了缓存。 基础 prompt 从 砍到 （降 37%），主要靠工具定义从 11 个降到 2 个，其余按需加载。 四、bounded autonomy 那段对你尤其有用 长跑 agent 的失败模式他们归成三类，而且规则放在 loop 里而不是模型里，任何模型第一天就生效：卡住（流 4 分钟无输出算断流重试，硬时限最多两次且重试前把半截回答删掉）；重复（连续三轮无可见产出就停，三次相同工具调用给提醒，六次直接停，但对轮询构建这类"重复但结果在变"的放行）；丢任务（压缩摘要上限从 8000 提到，因为估计三分之一以上撞顶）。长任务可以转后台睡眠，完成时被唤醒，不为"好了没"而花请求。 五、Agent Factory 跟你的 eval 路线高度重合：新模型进来 → 跑同一批任务 → 读 trace 找失败共性 → 提出带假设的改动 → 在每个受影响的模型上做对照实验 → 工程师审了才合。他们的工程准则是"每个 token 都要记账、大工具结果落文件、始终维护缓存、热路径做 profiling、后台任务要能被唤醒、卡住时永远有下一步"。还有个细节值得记：同一处改动在不同模型上效果相反——给每行加行号让 Opus 省 22%，但给 GLM 涨 8%、Kimi 涨 32%，最后改成模型自己需要时才要行号。 给你的落点：你的 pa 现在最值得先试的是别让工具原始结果进对话上下文。你现在是线性对话，这恰好是最容易被打爆的地方。哪怕不上完整的 Script 沙箱，先做到"工具返回落文件、只在对话里放摘要和指针"，收益就已经很大。其次是把那几条 bounded autonomy 规则写进你的 loop 而不是 prompt 里，这跟你之前说的 trace 是对得上的——trace 存在的意义之一就是能看见"连续三轮没产出"这种事。 最后说一句我的判断：这篇文章有品牌宣传成分（"最 efficient"是自家基准、自家对比），但 PTC 和 prompt cache 这两块是可验证的机制，不是话术。真正难抄的不是 Script 工具本身，是"多模型对照 + 工程师在回路里"的那套流程。