引言
大规模交付 AI 智能体的团队不断遇到同一种模式。即便是基于 Fable 和 Astra 这类顶级模型构建的智能体，也难以在特定产品内稳定地执行复杂的端到端任务，稳定到足以部署的程度。于是团队针对最关键的工作流苦苦打磨评估，往往是数百甚至数千个手写用例，然后通过修改提示词、修复运行框架、处理特殊情况，一点点改进智能体，直到它通过足够多的用例得以上线。
与此同时，产品自己的用户每天都在执行这些相同的任务，并且知道该采取哪些操作、按什么顺序。CopilotKit 是开源 CopilotKit 框架和 AG-UI 协议背后的公司，它发布了 CLiF，一个从全栈轨迹中持续学习的平台，现已开放早期访问。CLiF 会安全地捕获智能体在产品中的行为以及用户在产品中的行为，并将这些记录转化为技能、基于生产的评估和微调数据集，全部可与原始轨迹一同导出。
CopilotKit 是开源的，在 GitHub 上拥有超过 38,000 颗星。
TL;DR
智能体追踪显示智能体在哪里出错，而正确的路径存在于用户在产品中的行为里，而大多数技术栈从不捕获这些行为。
CLiF 现已开放早期访问，它从全栈轨迹中学习：智能体追踪和用户在产品中的操作，通过 AG-UI 安全地捕获为一条统一时间线。
一个基于 CopilotKit 的 Automatic Learning 构建的四阶段循环，将这些全栈轨迹转化为技能、基于生产的评估、微调数据集和原始导出，每个技能都由人工审核。
一个实例演示了智能体如何学习团队负责人实际收尾一个冲刺的方式。
CLiF 针对的是拖慢智能体团队的种种痛点，包括评估、上下文膨胀、成本、碎片化的技术栈以及影子 AI 使用，并且完全自托管运行。
智能体追踪遗漏了什么
如今大多数智能体可观测性都以智能体为中心。追踪工具捕获提示词、工具调用和模型输出，这能显示智能体在哪里出错，却让正确的路径处于视野之外。产品分析则覆盖了另一面，包含点击、漏斗和会话回放，不过这些数据是为阅读仪表盘的人构建的，而不是为了教智能体完成一项任务或对其进行测试。在大多数生产环境的智能体技术栈中，这两者最终永远不会落在同一条时间线上。
这个缺口很重要，因为智能体是通过提示词、技能、工具描述和暴露的 API 来学习一个产品的，并且必须自己弄清楚这些部分如何组合起来完成一项真实任务。而使用产品的人早已解决了这个问题，往往解决过数百次。CopilotKit 在其关于智能体学习的解读文章中阐述的观点是：用户实际完成工作的方式，是任何智能体团队所拥有的最有价值的数据集，而它很少以智能体能够学习的形式被捕获。
全栈轨迹：CLiF 所构建于其上的训练信号
CLiF 是 CopilotKit Intelligence 的一部分，围绕一个单一原语构建，即全栈轨迹。它通过 AG-UI（Agent-User Interaction Protocol）捕获，这是 CopilotKit 创建的开放协议，用于将智能体连接到面向用户的应用。由于 AG-UI 在任何界面上都位于智能体和用户之间，它能看到一项任务的两侧：
智能体轨迹（智能体追踪）：智能体所做的每一次运行、工具调用和状态变更，以及每一次返回的内容。
产品轨迹（用户操作）：用户屏幕上显示的内容、他们点击的按钮，以及他们触发的服务器请求。如果用户在此过程中与智能体对话，该对话也会按顺序落在同一条时间线上。
合在一起，这就是一条全栈轨迹。
AG-UI 已经将智能体的事件流式传输到前端，因此通过同一协议安全地捕获用户操作，从一开始就把两半放在同一个流中，无需单独的 analytics 管道在事后将它们拼接起来。每个用户会话都成为一条单一轨迹，团队可以在 CopilotKit Intelligence 中打开它并逐步回放，点击、服务器请求和智能体消息都按它们发生的顺序排列。
CLiF 内部：从轨迹到技能、评估和训练数据
CopilotKit 将学习循环描述为四个阶段。
1. 捕获。轨迹流入 CopilotKit Intelligence 并被分配到学习容器中，这些容器将学习范围限定为某一类工作，例如账单支持或客户引导。运行时通过 getTrajectoryLearningContainerIds 回调为每个会话选择容器，之后可以在 Intelligence UI 中将会话移入或移出容器。每个容器只从自己的会话中学习。
2. 发现模式。当一个容器积累了超过设定阈值的新会话后，分析会按计划运行，团队也可以手动触发。每次运行都基于该容器会话的冻结快照，并呈现出洞察（Insights）：反复出现的请求、重复的纠正，以及用户默默绕过的摩擦点。CopilotKit 将这种摩擦视为最强的信号，因为它往往会在数千个会话中重复出现，并准确显示出智能体接下来应该学习什么。每条洞察都会引用其背后的具体事件，并直接链接到源轨迹。
3. 审核。当证据支持一条可复用的经验时，CLiF 会将其作为一项技能提出，写成普通的 SKILL.md 文件。分析服务不能自行发布任何内容：由人来批准或拒绝每项提案，可以在 Intelligence UI 中操作，也可以通过 CopilotKit CLI 操作。已发布的技能会进行版本管理，并且可以随时停用。
4. 交付和导出。已发布的技能无需重新部署即可到达智能体，而需要稳定性的团队可以将智能体固定到某个固定的技能修订版本。对于任何其他智能体或 MCP 服务器，技能可以通过 copilotkit skills download <container> –output <dir> 下载为普通文件。轨迹本身可以从 Intelligence 仪表板导出为原始事件数据。对于早期访问团队，同一流水线还会从这些轨迹中生成评估候选和微调数据集。
智能体轨迹：CopilotKit Intelligence 中的自动学习
在智能体方面，CLiF 建立在 Automatic Learning 之上，这是 CopilotKit Intelligence 中的能力，CopilotKit 也将其定位为自我改进智能体的基础。Automatic Learning 从用户与智能体的对话中学习。CLiF 将同样的循环扩展到产品轨迹，因此它也能从用户直接在产品中、聊天之外所做的工作中学习。
每一次智能体对话都通过 AG-UI Streams 完整存储：消息、工具调用、生成式 UI、状态、审批和文件。开发者通过从 CopilotKit 运行时上的 getLearningContainerId 回调返回容器 ID，来选择哪些线程算作证据，这是智能体侧与轨迹回调相对应的部分。已经在生产环境中运行智能体的团队可以从 LangGraph Server 或 LangSmith Deployment 导入现有历史记录，而不必从零开始。
技能交付通过适配器实现，支持 LangGraph（Python 和 TypeScript）、Mastra、Google ADK、Microsoft Agent Framework、CopilotKit 内置智能体等。适配器会添加一个目录和两个工具——copilotkit_load_skill 和 copilotkit_read_skill_file，模型在任务需要时加载技能。开发者指令保持优先，因此技能无法覆盖智能体的角色、安全规则或工具限制。
超越技能：评估、微调数据和原始轨迹
技能只是第一个输出。同样的轨迹总共可供给四种输出，全部都可以导出到团队现有的技术栈中：
用于智能体或 MCP 服务器的技能，基于在多次会话中反复出现的模式构建。
基于生产的评估，基于用户实际执行的任务构建，包括没人想到要手写的输入和边缘情况。这些可以导出到团队已经在使用的评估平台。
从真实任务轨迹中提取的微调数据集，用于针对公司最频繁的工作流训练更小、更快的开源模型。
原始全栈轨迹，可以导出到任何可观测性平台，或按团队想要的方式使用。
CopilotKit 的观点是，团队应该保留他们已经在使用的评估和可观测性工具，而 CLiF 提供这些工具一直缺失的数据。
CLiF 实战：一个实际示例
假设你是一家类似 Linear 的项目管理平台的 CTO，工程团队在该平台上规划冲刺并跟踪问题。你希望智能体接管产品中的日常工作，并可靠地完成，无论是你自研的内置智能体，还是客户通过你的 MCP 服务器接入的 Claude 等外部智能体。冲刺收尾就是首批任务之一。
你的平台已经有一个一键选项，可以把所有未完成的问题移到下一个冲刺，你的文档也正是这样描述收尾的。所以，当智能体被要求收尾一个冲刺时，它就这么做了，把所有未完成的问题都往前移。
一旦 CLiF 安全地捕获产品轨迹，数千次收尾操作会显示，你平台上的团队负责人做的远不止这些。大多数人会先使用一键选项，然后用接下来的几分钟修正结果：
他们把已经被顺延过一次的问题移回待办列表，并取消分配。
他们在被阻塞的问题下评论，并 @ 上负责该阻塞项的人。
你团队里没有人设计过这套例行操作，也很少有用户在被问起时能描述出来。它只存在于一键操作之后的那些点击和请求中。智能体的轨迹永远看不到它，因为这是用户自己做的。产品分析记录下了那些额外的点击，却不知道它们的含义，而要在会话回放中发现这个模式，意味着要观看数千段录屏。
CLiF 将这套例行操作作为一个 Insight 呈现出来，并引用其背后的确切会话，同时为完整的收尾流程提出一项技能。在你的团队审核并发布后，你的内置智能体无需重新部署就能采用它，你还可以把同一项技能随 MCP 服务器一起发布，让 Claude 和其他接入的智能体也遵循它。随着用户习惯变化，新的会话会让这项技能保持最新，而这个 Insight 还会向你展示你自己的功能在哪里有所欠缺。
同样的会话会变成评估用例，用来检查智能体是否像你平台上的团队负责人那样处理每个问题，这样你就可以在把任务交给智能体之前确认它们已经准备就绪。如果你之后要为规划工作微调一个更小的模型，它们也可以成为训练数据。
CLiF 如何解决 2026 年拖慢智能体团队的痛点
对于大规模运行智能体的技术负责人来说，CopilotKit 将 CLiF 定位为对一系列常见问题的回应。
让智能体通过评估：对大多数团队而言，交付智能体过程中最慢的环节是让它在一批关键工作流上通过足够多的评估。从用户完成这些工作流的方式中学到的技能，为智能体补上了它缺失的步骤。基于生产的评估随后会补充用户在实践中所遇到的边缘情况，因此评估套件会随着真实使用而不断增长。
上下文膨胀与工具过载：智能体每犯一次错，往往就会在系统提示中多加一条规则，或给智能体多加一个工具。久而久之，上下文被填满，行为也变得更难预测。CLiF 则将学到的行为保存在技能目录中，模型只在任务需要时才加载相应技能。
成本：随着智能体获得更多工具和更长的提示，其成本往往会上升。来自真实轨迹的微调数据集，为团队提供了一条路径，可将高频工作流迁移到更小、更便宜的开源模型上，而按工作流划分的容器则能显示出智能体在哪些地方吃力、哪些地方不吃力。
碎片化的技术栈：大型组织很少会只选定一种智能体框架，而且它们的智能体运行在 Web 应用、移动应用、Slack 和 Teams 中。CLiF 运行在 AG-UI 之上，因此可与任何智能体框架以及底层任何模型配合使用。AG-UI 得到了 Google、Microsoft、Anthropic、Amazon 和 Oracle 的支持，以及包括 LangChain、Mastra、Pydantic AI、Google ADK 等在内的框架的支持。
智能体在中央监管之外被采用：随着各团队自行采用智能体工具，越来越难以了解每个智能体学到了什么以及为什么。每个 CLiF 技能都要经过人工审核，可追溯到其来源会话，并保持版本化和可回滚。整个平台也可以运行在公司自己的基础设施内。
按设计自托管
CLiF 完全可自托管。CopilotKit Intelligence 可以通过 Helm chart 自托管在公司自己的 Kubernetes 集群上，或托管在 AWS ECS 和 Fargate 上，并使用团队自己的 Postgres、Redis 和身份提供商，例如 Okta、Azure AD 或 Keycloak。
轨迹、技能以及从中学到的一切都保留在公司的 VPC 或本地环境中，因此用户活动和智能体轨迹永远无需离开其网络。轨迹也可以流入现有的 OpenTelemetry collector。对于希望获得最快部署的团队，CopilotKit Intelligence 也可运行在托管云上。
关键要点
CopilotKit 发布了 CLiF，一个从全栈轨迹中进行持续学习的平台，现已作为 CopilotKit Intelligence 的一部分开放早期访问。
用户实际如何完成工作，正是智能体所缺失的信号。全栈轨迹通过 AG-UI 在一条时间线上将其与智能体轨迹一同捕获。
CLiF 将这些轨迹转化为四种输出：基于生产环境的评估、用于更小开源模型的微调数据集、供智能体或 MCP 服务器使用的技能，以及用于导出的原始轨迹，全部兼容现有的评估和可观测性技术栈。
每一项技能都由人工审核，且每一项都能追溯回其来源会话。已发布的技能无需重新部署即可到达智能体，并可与 MCP 服务器一起交付给 Claude 等外部智能体。
它针对的是大规模运行智能体的核心痛点：通过评估、上下文膨胀、成本、碎片化的技术栈，以及对每个智能体所学内容的监督。
CLiF 通过 AG-UI 与任何智能体框架和任何模型配合使用，并且完全可自托管。
团队可以在 CLiF 页面上了解更多信息、预约演示或申请早期访问。
参考资料
CLiF 产品页面
Introducing CLiF: The Continual Learning Platform for AI Agents from Full-Stack Trajectories（CopilotKit 博客）
What Is Agent Learning?（CopilotKit）
CLiF 发布视频
CopilotKit Intelligence
Automatic Learning 文档
Skill delivery 文档
感谢 Copilotkit 团队为本文提供的思想领导力/资源。本文由 Copilokit 赞助。
文章 CopilotKit Releases CLiF: A Continual Learning Platform That Turns Agent Traces and User Actions into Skills, Evals, and Fine-Tuning Data 首次发表于 MarkTechPost。