Copilot Chat 可读取 agent 历史会话,GitHub 正在补齐“对话 + 代理”的连续工作流
GitHub 在 6 月 10 日更新 Copilot Chat,使其能查看进行中的 agent 会话状态,并支持拉取 agent logs 和按主题检索历史 sessions。
Copilot Chat 接入 agent sessions:聊天窗口可以查看代理执行过程
GitHub 在 2026 年 6 月 10 日更新 Copilot Chat,改进了 Copilot Chat 与 Copilot cloud agent 在网页端的交接体验。按照 GitHub 的说明,用户现在可以在 Chat 中查看进行中的 agent session 状态,也可以在 session 完成后继续追问相关内容。
这次更新还为 Copilot Chat 增加了两个工具:Get agent logs 和 Session search。前者可以把 Copilot cloud agent 在 pull request 上的工作日志拉回到对话中,方便询问它改了什么、验证了什么、为什么这么做;后者可以按主题、标题或时间检索并总结过去的 agent sessions。
Chat 可以看到进行中的 agent session
GitHub 原文提到,当用户通过 Chat 发起 agent session,例如要求创建一个 session、创建 pull request,或者对某个仓库做 deep research 时,Chat 现在会反映这个正在进行的 session 状态。
这解决的是 Copilot Chat 和 cloud agent 之间的交接问题。以前用户在对话里发起任务后,执行过程容易从聊天上下文里“离开”;现在 Chat 可以看到 session 状态,用户不用完全切换到另一个界面去判断代理任务是否还在运行、是否已经完成。
当 session 完成后,用户还可以围绕这个 session 在 Chat 里继续追问,或者从 Chat 中发起新的 session。这个变化让 Chat 不只是任务入口,也更接近 agent 工作过程的追踪入口。
Get agent logs 把执行记录拉回对话
新增的 Get agent logs 工具用于读取 Copilot cloud agent 在 pull request 上的 session logs。GitHub 原文说明,用户可以直接在对话中询问这次任务改了什么、验证了什么,以及为什么做这些处理。
这类日志能力对 agent 工作流很关键。因为 agent 不是只返回一句答案,而是会在仓库里执行一系列操作:查看文件、修改代码、运行验证、生成 pull request。用户真正需要的不只是最终结果,还要知道执行路径是否可靠。
把日志接回 Chat 后,Copilot Chat 可以承担“解释代理工作”的角色。对于 code review、问题排查或交接场景,这比单纯看到一个 PR 更有用:团队可以追问改动依据、验证过程和未覆盖风险。
Session search 让历史代理任务可检索
另一个新增工具是 Session search。GitHub 的说明是,它可以按 topic、title 或 recency 查找并总结过去的 agent sessions,让用户更容易从此前工作中继续接上。
这看似是一个小功能,但对连续工作流很重要。代理任务如果只存在于一次性 session 里,完成后很容易被遗忘;如果过去的 sessions 可以被检索、总结和重新引用,它们就更像项目历史的一部分。
例如,用户可以查找此前围绕某个 bug、某个模块、某次依赖升级或某个 PR 的 agent 工作记录,再继续追问或开启新的任务。这让 Copilot Chat 从“当下对话”扩展到了“历史代理工作入口”。
这不是普通记忆功能,而是工作交接能力
这次更新容易被简单理解成 Copilot Chat 有了更多上下文,但从原文看,它更像是在补齐 agent 工作交接。GitHub 没有把重点放在长期个性化记忆,而是放在 session 状态、session logs 和 past sessions search 上。
这些能力都围绕同一个问题:当 agent 开始替用户处理仓库任务后,用户如何知道它做了什么、为什么这么做,以及能否在后续对话中接着处理。
对于团队使用 AI coding agent 来说,这比单次生成更接近真实工作方式。真实开发并不是一次问答结束,而是由任务发起、执行、验证、解释、复盘和继续跟进构成。Copilot Chat 现在能看到 agent sessions,说明 GitHub 正在把代理任务从“执行一次”往“可追踪的工作链条”推进。
参考来源
本文为公开资料整理与技术学习参考,不提供采编、转载或发布服务。
Kimi K3.1 Pro:跑分逼近 Opus 5.5,白模能变成动画吗?
终端任务与Opus只差0.7个百分点,科学任务却仍有明显距离。结合官方游戏、3D网页和Blender白模案例,拆解Kimi、三维软件与视频模型的分工,并给出可访问的试玩入口。
71 个 Agent 真会一起干活?ECC 给 Codex 加了什么
ECC的71份Agent定义和311个技能怎样进入Codex?从CSV导出的一次交付拆解规划、验证、Hooks与记忆,核对原生插件和旧同步路径,讲清目录规模、安装成功与任务效果的区别。
Codex 总在翻整份代码?Serena 能让它少走多少弯路
Serena能按函数和引用关系为Codex取代码,但“省90% token”缺少统一对测依据。结合官方案例,看默认LSP与JetBrains后端的能力差异、接入步骤,以及哪些任务原生工具更省事。