Jediah Katz：模型进步之后，智能体运行框架为何仍重要

我在 2025 年初加入 Cursor，负责智能体运行框架，后来随着收购加入 SpaceX。今天我想讨论：更聪明的模型是否让运行框架过时了？

行业术语变化很快，从提示词工程到上下文工程，再到运行框架工程。底层工作是为模型提供合适的信息和能力。

我把运行框架看成模型的眼睛和手：它连接应用、计算机和外部服务，并决定智能体如何运行。

运行时控制智能体循环在哪里执行、状态如何保存，以便工作可以恢复。建设这一基础与传统软件工程类似。

上下文与编排层选择模型、提示词、工具、记忆和压缩方式，也负责协调调用并决定模型看到什么信息。

Katz 回忆 Cursor 曾用多个模型、智能体和机器进行高成本的长时间实验。这说明为探索新任务，运行框架可能变得很复杂。

后来，多个团队报告删除了用于弥补模型不足的提示词和保护措施。Cursor 曾用小模型应用代码修改，也曾提供明确的编码指令。

Katz 讨论了比较不同运行框架的编码和机器学习基准研究。他说较新模型在这些设置中的分数差异不明显；结果不应推广到所有任务和部署。

他的解释是，更强的模型吸收了部分以前由脚手架提供的技能，例如探索仓库、持续工作和检查结果。这是对所测场景的判断，不代表脚手架永远无用。

他把这个循环称为数据飞轮：运行框架使更难任务可行，更多人使用智能体，数据可能进入模型开发，后续模型再学会一些技能，使旧脚手架不再必要。

但这不意味着整个运行框架消失。Katz 提出两个原因：它可以打开新的任务领域，而基础设施、安全和效率不能简单地被模型权重吸收。

他介绍 Grokbot 使用长期运行的协调者和工作智能体处理知识工作。这是其雇主的产品描述，不是对性能的独立评估。

对于新任务，团队又增加了提示词和保护措施。合适的脚手架取决于模型在相关环境中能够可靠完成什么。

例子包括制作演示文稿、旅行流程、汇报进展、判断何时先询问以及保存有用偏好。对外行动需要符合用户意图并具备适当权限。

这个飞轮可以反复运转：当某种能力在模型中变得更普遍，运行框架又可能打开另一类任务，同时暴露新的限制。

他介绍一种实验性的“软件工厂”流程：分诊错误报告、启动智能体提出修复、展示证据并监测部署。他明确说整体愿景尚未解决。

长时间任务需要能承受中断并保存状态的基础设施。Katz 预计云端执行会发挥重要作用，但架构仍取决于任务和约束。

安全包括按智能体和人员限制权限、保护凭据，以及防止意外或高成本行动。模型能使用 shell，并不意味着应把所有凭据交给它。

他指出，所引用研究即使在基准分数相近时，也观察到每项任务成本的差异。质量、延迟和成本应一起评估。

他表示团队通过改善缓存命中率、token 效率和模型选择，降低成本与延迟，且未观察到质量下降。这是演讲中的公司自述。

他预计运行框架需要更容易随模型和产品变化而修改。隐藏内部细节有助于迭代，但也会降低用户的可见性。

可复用的基础组件可以组合扩展。例如订阅接口可在收到消息、CI 事件或到达指定时间时唤醒智能体，而不必为每种事件设计完全不同的机制。

团队集中追踪临时补丁（shim）及其使用情况。如果补丁不再需要，自动流程可以提出删除建议；人员仍可审查这一变更。

他预测更多智能体工作将在用户笔记本之外运行，智能体本身也会成为更高层系统的组件。他提出的六个月时间表是预测，并非已测量的结果。

他的结论是，随着模型改进，一些编码专用脚手架可以移除；运行框架仍对新任务、基础设施、信任和效率很重要。