GitHub 正在把 Copilot 从单次对话推向连续代理工作流

GitHub 连续更新 Copilot 与 Agentic Workflows，代理工作流开始形成闭环

GitHub 在 2026 年 6 月 10 日和 6 月 11 日连续发布两项与代理工作流相关的更新：Copilot Chat 现在可以查看 agent sessions；GitHub Agentic Workflows 进入 public preview。两条更新分别对应代理任务的“对话追踪”和“工作流执行”，合在一起看，GitHub 正在把 coding agent 从一次性辅助能力推向更连续的工程流程。

6 月 10 日的更新让 Copilot Chat 能看到 Copilot cloud agent 的 session 状态，并新增 Get agent logs 与 Session search；6 月 11 日的更新则允许团队用自然语言 Markdown 定义 reasoning-based 自动化任务，再编译成标准 GitHub Actions YAML。

Copilot Chat 先补上 agent sessions 的追踪能力

第一项更新来自 Copilot Chat。按照 GitHub 的说明，当用户通过 Chat 创建 agent session、创建 pull request，或对仓库发起 deep research 时，Chat 现在会显示正在进行的 session 状态。session 完成后，用户还可以继续在 Chat 中围绕这次 session 追问，或者从对话中发起新的 session。

Copilot Chat 使用 agent session logs 回答问题的示例

这张截图对应 GitHub 原文中“Copilot Chat now sees your agent sessions”的说明：Chat 不再只是发起任务的入口，也开始承接 agent 执行后的状态、日志和后续追问。

GitHub 同时新增两个工具。Get agent logs 可以把 Copilot cloud agent 在 pull request 上的工作日志拉入对话，让用户询问改了什么、验证了什么、为什么这么做。Session search 则可以按主题、标题或时间查找并总结过去的 agent sessions。

这让 Copilot Chat 更像一个代理任务的上下文窗口。它不只是问答界面，而是把执行记录、历史任务和后续追问放回同一个交互链条里。

Agentic Workflows 把代理任务放进 Actions 管道

第二项更新是 GitHub Agentic Workflows 进入 public preview。GitHub 的说明是，团队可以用 agentic workflows 在 GitHub Actions 中自动处理需要推理的任务，例如 issue triage、CI failure analysis 和 documentation updates。

Agentic Workflows 的关键机制是：团队用自然语言 Markdown 文件定义自动化任务，GitHub 再将其编译成标准 Actions YAML。因为最终仍然是 Actions，它可以复用已有的 runner groups 和 policy constraints。

这和单纯的聊天式 agent 不同。聊天更像发起一次请求，Actions 工作流则意味着任务可以被版本化、复用、约束和检查。GitHub 引用的客户场景也集中在漏洞修复、依赖维护、例行 review、跨仓库变更和交付流程等方向。

一个负责追踪，一个负责沉淀

把两条更新放在一起看，Copilot Chat 与 Agentic Workflows 分别补上了代理工作流的两个环节。

Copilot Chat 这边解决的是“执行过程如何被看见”。用户可以查看进行中的 session 状态，拉取 agent logs，检索过去的 sessions，并在对话中继续追问。它让 agent 的工作不再完全沉没在一次性任务里。

Agentic Workflows 这边解决的是“任务如何被沉淀”。团队可以把需要推理的重复任务写成 Markdown，再编译到 Actions 体系中执行。它让 agent 不只是个人临时调用，而是可以进入团队工程管道。

因此，这两条更新合起来构成了一个更完整的链条：Chat 发起和追踪任务，agent session 记录执行过程，Agentic Workflows 把可重复任务固化为 Actions 管道。

安全和复查仍然是核心限制

GitHub 在 Agentic Workflows 公测中强调了 security-first by design。原文提到，agent 默认以只读权限运行，在 sandboxed container 中执行，并位于 Agent Workflow Firewall 之后。输出会经过 safe outputs 流程验证，proposed changes 也会由 threat detection job 扫描后再应用。

这个细节很重要。代理工作流要进入真实团队，不只是能不能自动完成任务，还要看能不能被权限、日志、审查和安全机制约束。GitHub 引用 Hud.io 的反馈也指出，让 agent 打开 pull request 不是最难的部分，真正难的是团队是否足够信任它，可以把结果合并。

Copilot Chat 的 agent logs 与 session search，同样是在补“复查”能力。用户能看见 agent 做了什么、验证了什么、为什么这样做，团队才更容易判断结果能否进入后续流程。

这组更新的实际意义

这组更新显示，GitHub 正在从两个方向推进 coding agent：一边让 Copilot Chat 更好地承接 agent 执行上下文，另一边让 Agentic Workflows 把重复任务放进 Actions 自动化体系。

它并不意味着 agent 可以直接接管开发流程。更贴近现实的变化是：issue 分流、CI 失败分析、文档更新、依赖维护、重复漏洞修复、例行变更审查这类任务，可能逐步从“个人临时让 AI 帮忙”变成“团队可复用的代理工作流”。

对开发团队来说，后续值得观察的是：GitHub 是否能提供足够好用的 workflow 示例，企业是否会形成自己的 workflow catalog，以及日志、权限、审计、成本和失败处理是否能支撑更大范围的团队使用。

参考来源

本文为公开资料整理与技术学习参考，不提供采编、转载或发布服务。