自我改进是新的护城河，它能让产品公司超越简单封装 LLM API 的层次。
获取这种学习有两个地方：浏览器活动（用户在应用里实际做了什么）和 Agent trace（你的 Agent 实际做了什么）。
如果做得正确，你的产品可以仅仅因为被使用而变得更好。
你的产品每天可能会有几百、几千，甚至几百万次 Agent 与用户的交互。这是一座数据金矿。
然而今天，大部分这种价值都没有被捕捉下来。
你的用户在"教"Agent，但那堂"课"就这样消失了。
捕捉数据信号是一种复利资产。
但仅仅捕捉还不够。Agent 仍然需要在不被上下文淹没的情况下使用这些信号。模型的注意力预算是有限的，把所有东西都塞进上下文并不是解决方案......
文章概览
我们会讨论可以围绕它构建业务护城河的自我改进 Agent，包括：
- 从 Agent trace 和浏览器内活动中学习
- 学习可以应用在哪里：模型权重、harness 和上下文
- 不同类型的学习：程序性、语义性、情景性
- 数据隐私：保护你的用户数据
- 数据所有权：构建业务护城河
- 使用 AG-UI 为任何 Agent 轻松实现自学习的实践建议
我们将在未来几周发布我们的 Self-Learning 方案。
在这里报名，获取早期访问资格并参与设计合作。
你的 Agent 应该从两个地方学习
Agent 应该从 Agent trace 中学习，也应该从环境化的浏览器内活动中学习。
大多数学习方法只使用二者之一，但同时利用两者的产品会显著胜过没有这样做的产品。
1. Agent Trace
Agent 运行时，每一步都会被记录成 trace。它被要求做什么，调用了哪些工具，返回了什么，在哪里失败。
把另一个 Agent 指向这些 trace，它就能找到失败模式，并改写提示词、工具和指令。
缺失的另一半：Agent 交互之外的任何东西，而大多数活动仍然发生在那里。
2. 浏览器内的环境化用户活动
也就是，观察用户。
他们的点击、编辑、回应和工作流。
Brex 就是这样构建他们的 onboarding 的。他们观察分析师如何工作，并把每一次人工修正都反馈为训练信号。
每一次人工修正都会创建一个标注数据点，让下一次运行更精准。
缺失的另一半：这种方法能完美看到人类。但它完全不知道 Agent 尝试了什么，也不知道它为什么失败。
你应该同时捕捉这两种信号
怎么做？或者更准确地说，在哪里做？
今天几乎每一个产品里都有一个地方能同时看到这两种信号：人与 Agent 并肩工作的界面。
也就是 interface。
具体方法是通过 Agent-User Interaction Protocol（AG-UI）：这是一个开放标准，会在你的应用、用户和 Agent 之间流式传输每一个事件。下面会进一步解释为什么这很重要。
学习可以应用在哪里
有三个地方，每个地方都有自己的取舍。
→ 模型权重：把这次经验微调进模型本身。
→ Harness：模型周围的一切。它遵循的循环、允许调用的工具，以及在行动之前捕捉问题的检查机制。
→ 上下文内：把新信息直接加入提示词。Agent 每次调用时都会读取它。
我在第一篇文章中覆盖了这三层里的全部 10 种方法 ↓
不同类型的学习
有三种主要类型，可以帮助你的 Agent 随着时间推移不断改进。
1. 程序性记忆（工作流 / 如何做事）
程序性记忆就是许多人会放进 skills 或 agents.md 文件里的东西：
完成一项任务所需的已学习工作流和规则。
例如：经理为一位忠诚客户批准了一笔超限退款。Agent 学到了这一点，并在下一次做同样的事。
优点：Agent 每次都会用同样的方式处理同类情况。它一致且独立。
缺点：如果它学到了错误的工作流，它就会每一次都自信地做错。
2. 情景记忆（发生过的事情）
对特定过去事件和交互的记录。
例如："1 月 5 日，Joe Jonas 的退款失败了，因为他的银行卡已经过期。"
优点：一个真实的过去案例胜过一条抽象规则。Agent 能看到事情当时如何展开，并复制有效做法。
缺点：大多数过去案例都是无用噪音。必须有人筛选并只保留值得记住的内容，否则真正有用的案例会被埋没。
3. 语义记忆（事实）
Agent 应该知道的稳定事实。
例如："所有信用卡计划都有某种额度限制，但额度会因计划而异。"
优点：到处都可以复用。事实就是事实。
缺点：它会在没有警告的情况下过时。一旦额度发生变化，Agent 就会基于错误信息自信地行动。
视频：Self-learning in action via CopilotKit Intelligence and AG-UI
语义记忆保存什么是真的。
情景记忆保存发生过的案例。
程序性记忆保存处理它的规则。
自己拥有这个循环，并构建护城河
学习数据是你产品里最重要的部分。随着从零开始创建软件的成本下降，它会变得越来越有价值。
拥有学习数据，可以让你不只是一个 LLM API 的封装器。
Agent 的失误和人类的修正通常会落在两个不同的地方。
没有人把它们连接起来。
完成这种连接的表面其实已经存在于你的产品里：界面。
Trace 工具只看得到 Agent。
环境化工具，也就是那类观察浏览器的工具，只看得到人类，而且为了得到这些信号还会侵犯隐私。
但 CopilotKit 能同时看到两种信号。
CopilotKit 会读取流经你应用的事件：每一次工具调用、状态变化、审批和编辑，既来自 Agent，也来自使用它的人。
它通过 AG-UI（Agent-User Interaction Protocol）做到这一点。AG-UI 会在你的应用、用户和 Agent 之间实时传递每一个事件。
现在，Agent 的尝试和人类的修正会进入同一条事件流。
AG-UI 适用于任何 Agent 和任何 harness
AG-UI 是一个开放标准，并且与框架无关。
它已经被 AWS、Google、Microsoft、Oracle、LangChain、Mastra、Pydantic AI、CrewAI、LlamaIndex 等采用。
AG-UI 能看到事件，并把学到的上下文直接注入 Agent，不管底层这个 Agent 自己的 harness 长什么样。
这意味着，同一种学习可以自动应用到你今天或明年接入的任何 Agent 上，不需要为每一个新 Agent 做定制集成。
我们的一个客户运行着一个 UI，它同时连接 CopilotKit 的 Agent、Google ADK 和 Microsoft Agent Framework，所有记忆在这三个系统之间共享。
记忆脱离框架选择 = 可移植性
一切都运行在你的基础设施上，所以你拥有学习
CopilotKit Intelligence 可以自托管在你自己的 Kubernetes 集群上。完整的数据主权，SOC 2 Type II，如果需要也可以进行 air-gapped 部署。
数据留在你这里。Agent 从中学到的一切也留在你这里。
其他所有人的方法，要么把你的学习留在他们的云里，要么像 Meta 那样，为了得到它而走向监控。
@CopilotKit Intelligence 已经在财富 500 强企业里投入生产使用，并开放早期访问。如果你希望你的 Agent 越被使用就越好，请联系我们。
Learning Containers：决定新学习属于"谁"
一旦你在产品里启用学习，问题就来了：学习应该扩展到多远？来自某个用户的敏感事实不应该泄露到另一个用户的 Agent 上下文里。
CopilotKit 的解决方案是 Learning Containers：开发者友好的作用域，你可以控制它们，决定每一条经验会传播得有多"远"。
CopilotKit 允许你轻松为不同用户群定义 learning containers：
- 按用户。比如具体偏好。
- 按团队。比如审批流程。
- 按应用。比如全公司规则。
Learning container 是完全可审计的。你可以准确看到学到了什么，以及它落入了哪个 container。
总结
Self learning agent 真正有用的是它把学习来源拆清楚了：一边是 Agent 自己的 trace，能看到它怎么想、怎么调用工具、在哪里失败；另一边是用户在界面里的真实动作，能看到人是怎么接管、修正、补救的。
很多产品现在只存第一类数据。trace 很完整，但它只解释 Agent 的内部路径。用户怎么把错误结果改回可用状态，常常留在浏览器、表单、审批流和聊天窗口里，最后没有进入系统。反过来，只看用户行为也不够。你能看到人修了什么，却不知道 Agent 当时为什么走到那一步。
所以这篇文章的核心判断其实很简单：Agent 产品的护城河，不在模型调用本身，而在"错误和修正能不能进入同一个学习循环"。这个循环如果能跑起来，产品会因为使用而积累经验；如果跑不起来，用户每天都在教系统，但系统每天都在失忆。
这里面也有一个很现实的边界。不是所有东西都应该被记住，也不是所有记忆都应该全局共享。程序性记忆适合沉淀流程，情景记忆适合保留关键案例，语义记忆则最容易过期。对团队和企业产品来说，学习范围同样重要：哪些经验只属于某个用户，哪些属于团队，哪些可以沉淀成全局规则，这件事如果不先设计好，所谓"自学习"很快会变成上下文污染和权限泄露。
我更愿意把这类系统理解成一种产品级 feedback loop，而不是单纯的 memory 功能。它需要 trace、界面事件、权限边界、审计和应用层规则一起工作。模型只是执行的一部分。真正难的是让每一次失败、接管和修正都能留下合适的痕迹，并在下一次任务里以合适的粒度回来。