跨国深谈← 返回←软件工厂如何自我改进:技能、记忆与模型路由

软件工厂如何自我改进:技能、记忆与模型路由

关联

人物 Suraj Gupta

公司 Warp

概念 智能体 · 软件工厂 · 技能 · 外循环智能体 · 持久记忆 · 模型路由 · 分诊智能体

这一集是 Warp 的 Suraj Gupta 的一场演讲——他在 Warp 负责开发 harness(也就是驱动智能体运行的这套框架)。Warp 从一个现代终端起家,现在有大约一百万活跃用户,如今在做一个云端智能体平台,让团队能搭建「软件工厂」——即把开发工作从 issue 分诊一直自动化到上生产的一整套流水线。

他提出的核心问题是:大家都在讲智能体能自我改进、也都在讲软件工厂,但软件工厂本身怎么随时间变得更好、更高效、更快,却很少有人讲。他给了三条可落地的路径:技能、持久记忆、模型路由。

一、用「外循环智能体」让技能自动进化

技能(skill)就是给智能体的程序性记忆:你把某个要反复执行的流程描述给它,比如一个分诊智能体该怎么复现 GitHub 上用户报的问题。

问题在于技能会过时:人类不断给智能体反馈,智能体自己跑的过程中也学到新东西,你当初写的技能很快就跟不上了。

Warp 的解法是部署一个**外循环智能体**:内循环智能体实际执行技能(比如做分诊),外循环智能体则观察内循环的运行,收集反馈信号——包括用户或 Warp 员工在 issue 上的点赞点踩和评论、智能体犯的错——然后综合这些信息去改进内循环的技能。改进结果通过 pull request 提交,带来两个好处:所有技能演变都经 Git 追踪,完全可观测;同时一定有真人审查这些更新,防止外循环改坏了反而让分诊智能体变差。

这套机制就在 Warp 自己开源的客户端代码库上真实运行着:每次仓库里有新 issue 提交,工作流就触发分诊智能体判断这是该构建的新需求、还是可以合并去重的已有 issue,并找出用户漏报了哪些信息。

二、持久记忆:让智能体记住修过的问题

技能管流程,但其余的经验呢?比如一个 Sentry 智能体(负责盯错误上报的智能体)找到问题、收集上下文、修好了——三个月后来了个类似的问题,它可能运气好能重新找到同样的根因,但即使做到了,也为一个已经修过的问题白白重烧了大量 token 去重新收集上下文。

持久记忆就是一个限定于某个智能体的事实存储:类似技能改进循环,也由外循环智能体从内循环的运行中提取事实、经验教训和结果,供未来的运行直接复用。在 Warp 的平台上,每个智能体都能挂记忆存储,可以版本管理,人类可以审查、编辑、删除,还能追溯每条记忆是从哪次运行提炼出来的——这样你能判断某条记忆是不是无关紧要,或者只是不该纳入的局部最优。

效果是实实在在的:他们的 Sentry 智能体积累了五条根因分析的记忆,之后处理新问题时报告了自己用了哪几条,直接加速了这次的工作。而且这套持久记忆跨所有 harness 通用——不管你跑的是 Warp 自家的还是 Claude Code、Codex,记忆都会自动创建。

三、模型路由:别让简单任务烧大模型的钱

让所有做简单任务的智能体——比如分诊、修简单的 CI 失败——都用最贵的模型(如 Opus)来跑,成本会高到不可持续。所以「哪个任务用哪个模型」本身就是工厂效率的关键。

Warp 提供开箱即用的模型路由(叫 auto models),随着新模型发布持续评估帕累托效率(即在同等质量下找更便宜更快的选项)。用户也可以自定义路由规则:比如规定数据库迁移用 GLM 做、runbook 和 API 文档用 Quen 做——本质是给任务分类,再把类别映射到模型。

不过选哪个模型配哪类任务,目前「更像艺术而非科学」。所以 Warp 内部在用一种简单粗暴的 best.k 方法建立评测:同一个 prompt,在他们的云平台上用一组不同模型各跑一遍智能体,靠实测判断——他们由此发现 UI 任务用 GLM 做得就很好,根本不必动用 Opus,效率高得多。下一步是把这套评测做成面向客户的产品能力,让客户能在专属于自己工作流的任务类型上比较模型好坏,而不是只看网上发布的通用基准。

本集带走

• 技能会过时,给技能配一个外循环改进者:内循环智能体干活,外循环智能体收集点赞点踩和评论等反馈、定期修订技能,改动走 pull request、由真人审查——既自动进化又可观测、可回滚。
• 把修过的问题存成事实库:为智能体挂持久记忆,由外循环自动从每次运行中提取根因和教训;要能版本管理、能追溯来源,避免存进局部最优的错误结论。
• 按任务类别路由模型:简单任务(分诊、修 CI)别用旗舰模型;用配置规则把任务类别映射到模型,再用 best.k 实测(同一 prompt 多模型各跑一遍)验证选择,而不是照搬通用排行榜。