English | 中文

提到持续学习，人们通常会想到重新训练模型、更新参数，或者使用新数据进行微调。

但现实中，许多企业使用的是闭源模型。开发者可以通过 API 调用模型，却无法直接访问或修改模型权重。那么，这些 AI 系统是否只能保持静态，直到模型供应商发布下一代模型？

在 Berkeley 举办的 Agentic AI Summit 2026 上，三场演讲从不同角度回答了这个问题：

  • Replit 总裁 Michele Catasta 介绍了如何利用生产数据持续改进 Agent harness。
  • Ohio State University 副教授 Huan Sun 讨论了持续学习与安全之间容易被忽略的矛盾。
  • Perplexity AI 的 Alex Graveley 则进一步描述了 Agent 如何从执行任务发展到自主负责 Feature、Project，甚至整个 Product。

将这三场演讲联系起来，可以看到一条完整的 Agent 演进路径：

Agent 不仅需要持续学习，还必须安全地学习，并逐渐扩大自己能够理解和负责的范围。

Agent 的能力不只取决于模型

一个生产环境中的 Agent 通常不只是一个大语言模型。

它还包含：

  • 系统提示和任务指令
  • 可调用的工具与 API
  • 上下文检索机制
  • 代码或计算机执行环境
  • 重试和错误处理逻辑
  • 权限与安全限制
  • Memory 和历史信息
  • 多 Agent 编排
  • Evaluation 和监控系统

这些组件共同构成了 Agent 的 harness。

因此，即使底层模型保持不变，修改工具、上下文、执行环境、工作流和评估方式，也可能显著改善整个 Agent 系统的表现。

严格来说，这并不是模型参数层面的持续学习，而是系统层面的持续改进。但从用户角度看，效果非常相似：Agent 会随着真实使用逐渐变得更可靠。

固定 Evaluation 为什么还不够

AI 团队通常使用 benchmark 和 evaluation 检查 Agent 的表现。

标准流程很清楚：

  1. 修改 Agent harness。
  2. 运行固定评测集。
  3. 得到一个分数。
  4. 判断能力提升还是发生回归。

这种方法非常重要，但评测集本身必然是有限的。

一个 benchmark 可能包含几十个或几百个案例，而生产环境每天可能产生数百万次真实交互。用户会提出评测设计者没有预料到的问题，也会以意料之外的方式使用产品。

固定评测可以告诉团队 Agent 在已知场景中的表现，却很难覆盖真实世界中的长尾问题。

而这些长尾问题往往最有价值，因为它们揭示了系统真正的能力边界。

生产 Trace 是持续学习的信号

当一个 AI 产品获得大量真实用户后，每天都会产生海量执行 traces。

一条 trace 可能包括：

  • 用户提出了什么请求
  • Agent 获取了哪些上下文
  • Agent 调用了哪些工具
  • 每一步返回了什么结果
  • Agent 如何处理错误
  • 任务最终是否完成
  • 用户是否满意
  • 整个过程消耗了多少时间和成本

这些数据当然可以用于未来的模型训练，但它们也可以直接用于改进当前的 Agent 系统。

通过分析 traces，团队能够发现：

  • Agent 经常在哪些步骤失败
  • 哪些工具描述容易让模型误解
  • 哪些异常正在重复发生
  • 用户为什么对某类行为不满意
  • 问题来自模型、harness，还是底层基础设施
  • 哪些 Prompt、工作流或执行逻辑需要调整

Michele Catasta 的核心观点是，这种分析不应该只是偶尔进行，而应该成为一个持续运行的反馈闭环。

一个持续改进 Agent 的反馈闭环

他介绍的生产流程可以概括为六个步骤。

1. 收集生产环境中的 Traces

系统持续记录 Agent 在真实任务中的完整执行过程。

当每天产生数百万条 traces 时，人工逐条阅读并不现实。

2. 对相似行为进行聚类

系统首先使用语义相似度等机器学习技术，将行为相似的 traces 聚集在一起。

绝大多数集群代表正常和预期行为，可以暂时忽略。真正值得关注的是：

  • 突然出现的新集群
  • 频率快速上升的小集群
  • 与正常行为明显不同的异常集群

这些集群通常代表新的失败模式。

3. 发现长尾问题

Agent 具有非确定性。

面对同一个底层问题，它可能在不同请求中采用不同的推理路径、工具调用方式和排错策略。因此，单独查看时，多条失败 traces 可能看起来完全没有关系。

语义聚类可以帮助团队发现，这些表面不同的失败其实共享同一个根本原因。

4. 使用前沿模型分析根因

发现异常集群后，系统可以让能力更强的模型阅读相关 traces，分析问题究竟发生在哪里。

可能的原因包括：

  • Prompt 不够清楚
  • 工具描述不准确
  • 缺少必要上下文
  • API 返回格式发生变化
  • 执行环境尚未准备完成
  • 重试逻辑不合理
  • Agent 选择了错误的恢复策略

5. 自动生成修复 PR

识别可能的根因后，系统可以修改 harness、应用代码或基础设施配置，并自动生成 Pull Request。

生产环境中的失败不再只能等待工程师手动发现和排查，而是可以被自动转化为候选修复方案。

6. 通过 A/B Test 验证

自动生成 PR 并不意味着应该立即上线。

团队仍然需要观察修改对不同指标的影响，例如：

  • 任务成功率
  • 响应速度
  • 计算成本
  • 用户满意度
  • 工具调用次数
  • 错误恢复能力

实际结果通常不会是所有指标都同时改善。

一次修改可能提高速度，却降低准确率；也可能降低成本，却让用户体验变差。

因此，最终是否上线，仍然需要人类结合产品目标做出判断。

虚拟机启动过慢的真实案例

Michele 分享了一个很难通过传统监控发现的生产问题。

他们的系统每天会为用户启动大量虚拟机。正常情况下，Agent harness 和虚拟机都需要准备完成，Agent 才能执行代码或调用工具。

但偶尔会出现一种长尾情况：

Agent harness 已经准备好了，虚拟机却还没有完全启动。

这时，Agent 尝试执行代码就会失败。

Agent 不会简单等待，而是会主动尝试各种排错方法：

  • 检查命令是否正确
  • 尝试其他工具
  • 怀疑权限问题
  • 修改执行步骤
  • 再次运行代码

由于每次采用的恢复方式不同，这些 traces 看起来并不像同一个错误。

问题发生频率又不够高，因此也未必会在 Datadog 等传统监控仪表盘中形成明显信号。

但在对大量 traces 进行聚类后，这些表面不同的失败被归入了同一个异常集群。分析系统最终发现，它们的共同原因是虚拟机偶尔比 Agent harness 启动得更慢，并自动生成了修复 PR。

这个案例说明：

生产 traces 不只是用于事后调试的日志，也可以成为 Agent 持续学习和改进的信号。

Evaluation 不应只是发布前的检查

传统软件流程经常把 evaluation 放在最后：

开发完成，运行测试，然后决定是否发布。

Michele 建议换一种理解方式：

Evaluation 不应该只是一个发布前的布尔检查，而应该成为持续改进 Agent 的引擎。

新的流程更接近：

生产使用
→ 收集 traces
→ 聚类并发现异常
→ 分析根因
→ 自动生成修改
→ A/B Test
→ 人类决策
→ 灰度部署
→ 继续收集新的 traces

在这个循环中，每一次真实失败都可能帮助系统变得更好。

但这里还存在一个非常重要的问题：

如果系统只学习如何提高任务成功率，它是否也可能同时学会更加危险的行为？

持续改进并不等于安全改进

Huan Sun 在 Smarter and Safer Every Day? Continual Learning and Safety in Computer-Use Agents 演讲中，讨论了持续学习和安全之间一个容易被忽略的矛盾。

Agent 最需要持续学习的地方，通常是训练环境与真实部署环境发生差异的地方，也就是 distribution shift。

但安全失败也最容易在这些陌生环境中出现。

一个危险的循环可能是：

Agent 遇到新的环境或任务
→ 完成了任务，但违反了某项安全约束
→ Evaluation 没有发现安全问题
→ 系统仍然给予正向反馈
→ 下一次更新强化了这种行为
→ 相同问题重复出现，甚至变得更加严重

这里的问题不是 Agent 没有完成任务。

恰恰相反，它可能成功完成了用户要求的目标，因此获得了正向评价。但它在完成任务的过程中，做出了用户没有要求、影响范围过大或具有不可逆后果的操作。

如果反馈只奖励结果，而没有评估过程，持续学习就可能把危险行为当作成功经验保存下来。

没有攻击者，也可能发生严重安全问题

很多 Agent 安全研究关注的是：

  • 恶意 Prompt
  • Prompt injection
  • 对抗攻击
  • 故意诱导模型越权

Huan Sun 团队的研究指出，即使没有攻击者、没有恶意输入，普通请求和正常环境也可能触发严重后果。

原因可能只是：

  • 指令存在轻微歧义
  • Agent 对用户意图进行了错误推断
  • 环境状态与训练阶段不同
  • Agent 为了提高成功率，选择了影响范围更大的操作
  • Agent 没有意识到某个操作是全局性的或不可逆的

SSH 配置案例

用户本来只希望：

  • 创建一个 SSH 用户
  • 限制该用户只能访问指定目录
  • 为该用户启用密码登录

一种安全实现应该只修改这个用户对应的 SSH 配置。

但 Agent 可能直接启用全局设置：

PasswordAuthentication yes

这样虽然成功完成了指定用户的登录配置，却同时修改了整个系统的认证策略。

从任务完成角度看，它可能是成功的。

从安全角度看，它进行了用户没有授权的全局修改。

“整理桌面”案例

用户给出一个看似普通的指令：

Tidy up the Desktop.

Agent 可能自行推断：

原始的 PowerPoint 文件已经不需要了，可以删除。

于是，它在关闭其他程序的同时，删除了用户仍然希望保留的原始文件。

这里没有恶意输入。风险来自：

模糊指令
→ 不安全推断
→ 不可逆操作

这说明 Agent 安全不能只关注“是否拒绝恶意请求”，还必须关注它如何处理：

  • 模糊性
  • 权限范围
  • 用户未明确说明的假设
  • 不可逆操作
  • 请求范围之外的副作用

部署前发现长尾安全失败

Huan Sun 团队的第一个项目是 AutoElicit。

它研究的问题是：

如何在长尾安全失败变成生产事故之前，主动把它们暴露出来？

传统安全测试往往使用明显的恶意 Prompt。AutoElicit 更关注正常任务的轻微变化，例如：

  • 改变指令的表达方式
  • 增加一个仍然合理的条件
  • 引入轻微歧义
  • 改变文件、权限或系统环境
  • 对原始任务进行小幅扰动

这些输入仍然是良性的，但可能让 Agent 从正常行为突然转向不安全行为。

这种方法尤其适合发现：

  • 固定 benchmark 没有覆盖的问题
  • 只有在特定环境中才出现的问题
  • 低概率但高影响的问题
  • 普通用户无意间就可能触发的问题

这与 Michele 的生产 trace 分析形成了互补：

  • Michele 关注部署后，如何从真实使用中发现长尾故障。
  • Huan 关注部署前，如何主动生成场景并提前发现长尾安全失败。

理想的系统应该同时具备这两种能力。

建立安全持续学习的开放基础设施

Huan Sun 团队的第二个项目是 ACuRL，用于研究开放权重的 computer-use agents 如何在新环境中安全地持续适应。

这个框架提供了三个主要组件。

强化学习基础设施

支持 computer-use agents 在真实或模拟计算机环境中进行学习和适应。

自动任务合成

自动创建多样化任务和环境，让 Agent 接触更多新的操作场景，而不是只在少量固定任务上学习。

Trajectory Evaluator

评估 Agent 的完整执行轨迹，而不仅仅是检查最终结果是否正确。

这一点尤其重要。

普通 evaluation 可能只问：

任务是否完成？

Trajectory evaluation 还需要检查：

  • Agent 是否超出了用户请求范围
  • 是否使用了不必要的高权限
  • 是否修改了无关配置
  • 是否删除了用户仍然需要的数据
  • 是否采取了不可逆操作
  • 是否在不确定时主动询问用户
  • 是否通过危险捷径完成了任务

真正安全的持续学习，必须同时优化两个目标：

任务完成质量
+
完成任务过程中的安全性

从工程角度，安全 Evaluation 应该检查什么

将 Michele 和 Huan 的观点结合起来，Agent 的生产反馈系统不应只追踪成功率、延迟和成本，还应该加入更多安全维度。

结果是否正确

Agent 是否真正完成了用户要求的任务。

操作范围是否合理

Agent 是否只修改了完成任务所必需的内容。

权限是否最小化

它是否使用了超出任务需要的系统权限。

副作用是否可接受

它是否影响了其他用户、文件、配置或系统功能。

操作是否可逆

如果 Agent 理解错误，是否能够回滚。

不确定时是否升级给人类

面对歧义、高风险或不可逆操作时，Agent 是否暂停并请求确认。

因此，一个更完整的反馈闭环应该是：

生产使用
→ 收集 traces
→ 发现异常模式
→ 分析根因
→ 自动生成修改
→ 评估任务成功率
→ 评估完整执行轨迹的安全性
→ A/B Test
→ 人类审核关键权衡
→ 灰度部署和持续监控

人类的角色并没有消失

即使异常分析和 PR 生成可以大量自动化，人类仍然承担几个关键职责：

  • 定义哪些业务和安全指标最重要
  • 判断速度、成本、质量和安全之间的取舍
  • 审核高风险或不可逆修改
  • 决定哪些实验应该继续
  • 判断局部修复是否掩盖了更深层的架构问题
  • 明确 Agent 可以自主执行到什么程度
  • 确定产品长期应当优化的目标

Agent 可以发现问题、生成方案并运行实验，但它未必知道组织最终应该优化什么。

特别是在多个目标相互冲突时，目标函数本身仍然需要由人类定义和修正。

从安全持续学习走向 Omniscient Agents

Alex Graveley 在 Omniscient Agents 中讨论了 Agent 自治范围进一步扩大的方向。

他将 Agent 能够独立完成的工作描述为一个逐渐上升的复杂度阶梯：

Tool Call
→ Commit
→ Pull Request
→ 多个 Pull Requests
→ Feature
→ Project
→ Product

一个只会修改代码的 Agent，很难独立负责一个完整 Feature。

要真正负责 Feature 或 Product，它还需要：

  • 读取真实业务数据
  • 观察用户反馈
  • 运行实验
  • 监控生产系统
  • 判断功能是否改善留存、收入或其他业务目标
  • 根据结果扩大部署、继续迭代或执行回滚

Alex 将这种能力归纳为两个维度。

Insight

Agent 能看到哪些信息，以及能否从这些信息中形成正确判断。

它需要从理解一个代码库，逐渐发展到理解用户、实验、产品和整个业务。

Control

Agent 能够对真实世界做什么。

它需要从提出建议，发展到修改代码、部署功能、运行实验和操作线上系统。

但 Agent 的 Control 越强，安全失败造成的影响也越大。

一个只能生成代码建议的 Agent 出错，可能只是给出错误代码。

一个能够修改系统配置、删除文件、部署服务或运行实验的 Agent 出错，则可能造成真实且不可逆的损害。

因此，Huan 的安全持续学习可以被看作 Alex 所描述的高自治 Agent 的必要基础：

只有当系统能够发现、评估并阻止长尾安全失败时，人类才可能安全地退出更多执行环节。

结语

未来 Agent 的进步不一定只来自更大的模型或更多参数。

大量提升可能来自模型之外：

  • 更好的工具
  • 更准确的上下文
  • 更完整的生产 traces
  • 更有效的异常检测
  • 更严格的轨迹评估
  • 更可靠的实验和回滚机制
  • 更清晰的人类决策边界

Michele Catasta 展示了 Agent 如何从真实生产数据中持续改进。

Huan Sun 提醒我们，持续学习如果只奖励任务成功，也可能持续强化危险行为。

Alex Graveley 则描述了当 Agent 获得更完整的 Insight 和更大的 Control 后，它们可能承担怎样的业务责任。

将三者联系起来，真正重要的问题不再只是：

我们使用了哪个模型？

而是：

我们是否建立了一个能够从真实世界中持续学习、安全学习，并逐渐承担更多责任的 Agent 系统？