技术速递|为 GitHub Copilot 构建智能体记忆系统

技术速递|为 GitHub Copilot 构建智能体记忆系统
作者:Tiferet
排版:Alan Wang
Copilot 的跨智能体记忆系统使各类智能体能够在整个开发工作流中学习和改进,涵盖从编码智能体、CLI 到代码审查。

我们的愿景是将 GitHub Copilot 发展为一个由多个智能体组成的生态系统,在整个开发生命周期中协作——从编码和代码审查,到安全、调试、部署和维护。要释放多智能体工作流的全部潜力,我们需要超越彼此孤立、每次会话都从零开始的交互方式,转向一个随着每次使用不断积累的知识库。

跨智能体记忆使各类智能体能够在整个开发流程中基于经验进行记忆和学习,而无需依赖用户的明确指示。

每一次交互都会让 Copilot 更加了解你的代码库和约定,使其随着时间推移变得越来越高效。例如,当 Copilot 编码智能体在修复安全漏洞时学会了你的仓库如何处理数据库连接,Copilot 代码审查智能体之后就可以利用这些知识,在未来的拉取请求中识别不一致的模式。又比如,如果 Copilot 代码审查智能体发现某些文件必须保持同步,那么在未来生成新代码时,Copilot 编码智能体会自动同时更新这些文件。

目前 GitHub Copilot 中记忆的工作方式(公开预览版)
Copilot 的新记忆系统已进入公开预览,首先支持 Copilot 编码智能体、Copilot CLI 和 Copilot 代码审查,面向所有付费 Copilot 计划,其他智能体将很快跟进(了解其工作方式请参阅我们的文档)。该功能默认关闭,完全自愿启用,因此由你决定何时以及在何处让 Copilot 开始从你的工作流中学习。
你可以在 GitHub Copilot 设置中开启记忆功能。
了解如何启用记忆功能 >

挑战:记住什么,以及何时遗忘

我们的智能体在持续提升提取特定任务所需上下文的能力。记忆系统的核心挑战并不在于信息检索,而在于确保任何存储的知识在代码随分支和时间演变的过程中仍然有效。

在实践中,这意味着记忆系统必须处理代码变更、被放弃的分支以及相互冲突的观察结果——同时确保智能体仅基于与当前任务和代码状态相关的信息采取行动。例如,在某个分支中观察到的日志约定,之后可能被修改、替代,甚至根本未被合并。

一种选择是实现离线整理服务,用于去重、解决冲突、跟踪分支状态并清理过时信息。然而在 GitHub 的规模下,这种方式会引入显著的工程复杂性和 LLM 成本,同时仍然需要在读取时进行变更协调。因此我们首先探索了一种更简单、更高效的方法。

我们的解决方案:即时验证

信息检索是一个非对称问题:解决它很难,但验证它却很容易。通过使用实时验证,我们既能获得预存记忆的优势,又能避免过时或误导信息的风险。

我们不进行离线记忆整理,而是以带引用的方式存储记忆:每条事实都附带支持该事实的具体代码位置引用。当智能体遇到存储的记忆时,它会实时验证这些引用,在使用前确认信息在当前分支中仍然准确且相关。这种验证仅需少量简单的读取操作,在我们的测试中不会为智能体会话带来显著延迟。

将记忆创建作为工具调用

我们将记忆创建实现为一个工具,当智能体发现某些信息可能对未来任务具有可执行意义时,可以调用该工具。

Copilot 智能体在执行任务过程中如何存储值得记住的学习内容

考虑以下示例:在审查一位资深开发者的拉取请求时,Copilot 代码审查发现 API 版本跟踪必须在代码库的不同部分保持同步。它可能在同一个拉取请求中看到以下三个更新:

在 src/client/sdk/constants.ts 中:

export const API_VERSION ="v2.1.4";

在 server/routes/api.go 中:

const APIVersion ="v2.1.4"

在 docs/api-reference.md 中:

Version: v2.1.4

对此,Copilot 代码审查可以调用记忆存储工具,创建如下记忆:

{ subject:"API version synchronization", fact:"API version must match between client SDK, server routes, and documentation.", citations:["src/client/sdk/constants.ts:12","server/routes/api.go:8","docs/api-reference.md:37"], reason:"If the API version is not kept properly synchronized, the integration can fail or exhibit subtle bugs. Remembering these locations will help ensure they are kept synchronized in future updates."}

结果是:下次智能体在这些位置中的任意一个更新 API 版本时,它都会看到这条记忆,并意识到必须同步更新其他位置,从而避免可能破坏集成的版本不一致。同样,如果一位经验不足的开发者只更新了其中一个位置并提交拉取请求,Copilot 代码审查会指出遗漏并建议补充更新,从而将资深成员的知识自动传递给新成员。💥

记忆的使用

检索

当智能体开始新的会话时,我们会检索目标仓库中最新的记忆,并将其包含在提示中。未来的实现将支持更多检索技术,例如搜索工具和加权优先级排序。

Copilot 如何将以往任务的记忆加入到智能体提示中
验证

在应用任何记忆之前,系统会提示智能体通过检查引用的代码位置来验证其准确性和相关性。如果代码与记忆内容相矛盾,或引用无效(例如指向不存在的位置),智能体会被鼓励根据新证据存储修正后的记忆。如果引用有效且记忆被认为有用,智能体会再次存储该记忆以刷新时间戳。

隐私与安全

需要强调的是,记忆具有严格的作用范围。某个仓库的记忆只能在该仓库内由具有写入权限的贡献者操作时创建,并且只能在同一仓库中由具有读取权限的用户发起的任务中使用。就像源代码本身一样,关于某个仓库的记忆仅限于该仓库之内,从而确保隐私和安全。

跨智能体记忆共享

我们记忆系统的真正力量在于不同 Copilot 智能体之间的相互学习。

  1. Copilot 代码审查在审查拉取请求时发现一个日志约定:“日志文件名应遵循 ‘app-YYYYMMDD.log’ 模式。使用 Winston 进行日志记录,格式为:时间戳、错误代码、用户 ID。”
  2. 之后,Copilot 编码智能体被分配实现一个新的微服务任务。它看到并验证了这条记忆,并自动应用相同的日志格式。
  3. Copilot CLI 帮助开发者调试问题时,可以高效检索正确的日志文件,并基于代码审查智能体学到的日志格式找到相关时间戳。

每个智能体都为共享知识库做出贡献并从中受益,使智能体能够在不同任务中复用经过验证的仓库知识。随着更多智能体采用记忆机制——无论是用于开发流程、调试还是安全分析——它们都将参与并受益于对代码库不断演进的共同理解。

评估

对智能体韧性进行压力测试

我们最大的担忧是过时、不正确甚至恶意注入的记忆所带来的影响。为测试系统的韧性,我们故意在仓库中植入对抗性记忆——与代码库相矛盾的事实,并附带指向无关或不存在代码位置的引用。

在所有测试案例中,智能体都持续验证引用、发现矛盾并更新错误记忆。记忆池会在智能体根据自身观察存储修正版本后实现自我修复。引用验证机制有效防止了误导性记忆的风险。

模拟真实的记忆池

对于评估集中的每个仓库,我们在多种历史任务(早于目标评估任务)上运行智能体,并让其通过我们提供的 “store_memory” 工具自然填充记忆数据库。为模拟最坏情况,我们刻意提高来自已被放弃或未合并分支的记忆比例,确保记忆环境具有现实噪声。

当我们在评估集的拉取请求上运行 Copilot 代码审查时,使用记忆后,精确率提升 3%,召回率提升 4%。

衡量对开发者的影响

记忆系统的最终考验是它在开发者日常工作流中的实际影响。我们在首批部署记忆功能的两个 Copilot 智能体——Copilot 代码审查和 Copilot 编码智能体——上进行了 A/B 测试,衡量关键用户指标的变化。

  • Copilot 编码智能体:拉取请求合并率提升 7%(启用记忆为 90%,未启用为 83%)。这意味着当开发者将任务交给 Copilot 时,可以节省更多时间,更频繁获得期望结果。
  • Copilot 代码审查:评论的正向反馈率提升 2%(启用记忆为 77%,未启用为 75%)。这意味着自动化代码审查带来了更高质量的质量保障。
  • 两项提升均具有高度统计显著性,p 值 < 0.00001。

这些结果表明,跨智能体记忆为开发者的日常工作流带来了可衡量的价值。

下一步

我们已在 Copilot CLI、Copilot 编码智能体和 Copilot 代码审查中,以自愿启用方式部署了基于仓库范围的记忆存储与使用功能。我们正在倾听用户反馈,并密切跟踪性能指标,以便在更广泛的 Copilot 工作流中推广之前持续迭代。同时,我们也在探索多种方法来优化记忆的生成、整理、优先级排序和使用。

跨智能体记忆通过让经过验证的信息在智能体工作流中持续存在,减少了每次任务开始时重新建立上下文的需要。我们对记忆将带来的可能性充满期待,而这仅仅是一个开始。期待你的反馈,帮助我们确保 GitHub Copilot 以最符合你需求的方式不断演进。祝编程愉快!

阅读我们的文档,了解如何在 Copilot 中启用记忆功能 >

Read more

升级Z-Image-Turbo后,我的AI绘画效率翻倍了

升级Z-Image-Turbo后,我的AI绘画效率翻倍了 以前做AI绘画,我总在“等”字上耗掉大半时间:等模型加载、等提示词调试、等8步变50步、等一张图出完再改下一句描述——直到我把本地部署的Z-Image换成了Z-Image-Turbo。不是参数更多、不是显卡升级,只是换了个镜像,生成一张4K高清图的时间从12秒压到5.3秒,批量跑10张海报的耗时直接砍掉62%,连带工作流节奏都变了:以前是“画一张,喝一口咖啡”,现在是“画一张,顺手改三版”。 这不是玄学提速,而是通义实验室把“快”这件事,从算法层、工程层到交付层全链路重写了。它不靠堆显存,不靠换H100,甚至不需要你动一行代码——只要启动一个预置镜像,就能把消费级GPU用出服务器级响应感。 下面我就用真实工作流告诉你:这个叫Z-Image-Turbo的开源模型,到底快在哪、稳在哪、好用在哪。 1. 为什么说“8步生成”不是营销话术 很多人看到“8步出图”第一反应是:画质肯定崩。我一开始也这么想,直到用同一段提示词对比测试:

AI写作大师Qwen3-4B部署:本地开发环境配置

AI写作大师Qwen3-4B部署:本地开发环境配置 1. 引言 1.1 学习目标 本文将详细介绍如何在本地开发环境中部署 Qwen3-4B-Instruct 模型,构建一个功能完整的 AI 写作与代码生成系统。通过本教程,读者将掌握从环境准备到服务启动的全流程操作,最终实现基于 CPU 的高性能推理应用。 完成本教程后,您将能够: * 成功部署 Qwen3-4B-Instruct 模型 * 启动并访问集成 WebUI 的交互界面 * 执行复杂任务如 Python 程序生成、长文本创作等 * 理解模型在 CPU 环境下的优化策略 1.2 前置知识 建议读者具备以下基础: * 基本的命令行操作能力(Linux/macOS/Windows) * 对 Docker 或 Python 虚拟环境有一定了解 * 了解大语言模型的基本概念(如 token、inference、

KoboldAI完整安装与配置指南:AI写作工具的终极入门教程

KoboldAI完整安装与配置指南:AI写作工具的终极入门教程 【免费下载链接】KoboldAI-Client 项目地址: https://gitcode.com/gh_mirrors/ko/KoboldAI-Client 想要体验强大的AI写作助手吗?KoboldAI是一个基于浏览器的AI辅助写作前端,支持多种本地和远程AI模型。无论你是想创作小说、玩文字冒险游戏,还是与AI聊天,这个终极指南将带你一步步完成安装配置,开启你的AI写作之旅!🚀 💡 KoboldAI是什么? KoboldAI是通往GPT写作的门户,提供标准化的写作工具套件,包括记忆功能、作者笔记、世界信息、保存加载、可调节的AI设置、格式化选项等。你可以将其作为写作助手、游戏平台或聊天机器人使用。 核心功能亮点 * 多种游戏模式:小说模式、冒险模式、聊天模式 * 丰富的AI模型:支持多种本地和云端模型 * 完整写作工具:记忆系统、世界构建、格式控制 🛠️ 快速开始:三种安装方式 在线免费体验(最简单) 使用Google Colab在线运行KoboldAI,无需安装任何软件: * T

LM Studio模型加载全攻略:从格式识别到本地部署(支持LLaMA/Mistral等主流模型)

LM Studio模型加载全攻略:从格式识别到本地部署(支持LLaMA/Mistral等主流模型) 在开源大模型生态中,本地部署已成为开发者探索AI能力的重要方式。LM Studio作为一款轻量级模型运行环境,以其简洁的交互界面和对多种架构的支持,逐渐成为个人开发者的首选工具。本文将深入剖析模型加载的全流程,从文件格式解析到实战部署技巧,帮助您避开常见陷阱,高效运行各类主流大模型。 1. 模型格式深度解析 LM Studio对模型格式的支持并非一刀切,不同格式在性能、兼容性和功能完整性上存在显著差异。当前主流格式可分为三类: GGUF格式 作为llama.cpp生态的专有格式,GGUF已成为LM Studio的黄金标准。其优势体现在: * 量化支持:内置从2bit到8bit的多级量化方案(如q4_K_M表示4bit中精度量化) * 跨平台一致性:同一模型文件可在Windows/macOS/Linux无缝运行 * 内存映射:支持部分加载,降低内存占用 GPTQ格式 基于TensorRT的量化方案,特点包括: * 仅部分架构支持(如LLaMA-1/2、Mistral