不止于代码生成：面向开发者的智能体工程指南
今年 10 月，GitHub 一周内收到超过 12 亿次提交，比一年前增长 400% 以上。这个数字甚至超过了 GitHub 2025 年全年的提交总量。你很可能也比一年前生成了更多代码。但不妨问问自己：你感觉自己比去年高效了 400% 吗？开发软件不只是写好提示词那么简单。AI 加快了实现速度，开发者的压力却转移到了其他环节：Faros AI 的一项研究发现，当团队从低 AI 使用率转向高 AI 使用率后，拉取请求（PR）在评审环节停留的时间延长了 441%。作为开发者，你要收集需求、推动实现、评审改动、评估测试结果，还要排查生产环境中的问题。智能体可以在这些阶段帮你提效：规划、构建、验证、观测。下面我们来看看，在 GitHub 上，一套高效的智能体工程工作流是什么样子。
规划：让所有人和所有智能体达成共识
看看这个场景是否似曾相识。你正在规划一次 API 变更。设计方案放在一个工具里，兼容性要求埋在 Slack 聊天记录里，而一个旧的拉取请求解释了当前实现为什么是这样。在写出有用的计划之前，你得先把这些细节串起来，比较不同方案，并就让现有客户端如何继续工作达成一致。看起来简单的规划任务，变成了几个小时的搜索、交叉核对和到处追问。还没开始实现，你已经精疲力竭。
你可以用 Copilot 把这些散落各处的上下文汇聚到一处，梳理各种取舍，再把决策整理成实现计划。
在团队现有的工作场所一起规划
在 Slack 或 Teams 里使用 Copilot，与所有相关方协作——从产品经理、设计师到分析师和业务干系人。接入已连接工具中的上下文，让团队可以核对假设、贡献想法、共同完善需求。
把达成一致的需求变成可执行的工作
让 Copilot 创建 GitHub Issues，附上实现所需的上下文和验收标准，并把可以分开处理的任务拆出来。
把日常的分诊工作从规划时间里剥离出来。用 GitHub Agentic Workflows 给 issue 打标签、评估任务复杂度，低复杂度任务直接派给 Copilot，你把时间留给更难的决策。复杂的工作则需要充分的规划：在你常用的 Copilot 界面里打开 Plan Mode，对比不同方案，打磨实现计划；计划确认无误再交给 Copilot 动手。过去要花几天搜索和收集上下文的事，现在产出的是一份可审阅的计划、明确的验收标准和划定范围的问题，而你的时间花在决策上，而不是检索上。方案定下来之后，你和你的 agent 其实已经站在实现的起跑线上了。
构建：同时推进多个任务
你已经准备好把计划变成代码，但现实总有别的安排。agent 任务做到一半，下一个会议还有五分钟就开始，而你的狗已经在门口盯了二十分钟。会上又有人指出一个实现必须处理的边缘情况。所有人同时都在找你。你想继续推进，但没法分身三处。其实你可以让工作继续流动，而不必被绑在开始它的那台电脑上。
换个设备接着聊。 会话连续性（session continuity）让你在不同客户端上接续同一个 Copilot 会话，哪里方便就在哪里干活。
合上笔记本，任务照跑。 Copilot 在云端沙箱（cloud sandboxes）里执行任务，计算不占你的机器，你可以离开，之后再回到这个会话。
并行处理多个任务，互不干扰。 Copilot 应用为每个会话提供独立的仓库副本，所以实现任务和文档更新不会共享一个未完成的工作树。
把项目知识带进每个任务。 仓库指令记录约定和验证命令，共享记忆则保存 Copilot 可在整个仓库范围内复用的事实。
Copilot Dreaming 会检查符合条件的会话和拉取请求反馈，让记忆保持最新，并主动提出修改指令或技能的建议。这样一来，团队就不必反复解释自己的工作方式，Copilot 在不同任务中给出的帮助也更一致。模型要跟任务匹配。选用 Copilot Fusion，可以为任务挑选合适的模型和推理深度，需要时还能引入其他模型来审查方案。你设定投入档位，在质量、成本和响应时间之间找平衡。无论在哪里工作，都遵守公司规则。企业托管设置会把公司策略和已配置的工具带到各个 Copilot 界面，让你在不同客户端之间切换时，少一些配置差异。写代码不只是给大语言模型（LLM）丢一个提示词、看看返回什么就完事。而且手头的工作比以往更多，想守住编码标准、按时交付项目并不容易。Copilot 借助共享的项目知识，让任务独立推进，同时允许你在不同设备上接着上次的会话继续做。这样你就有更多空间去琢磨实现方案，随时应对变化。工作完成时，你会拿到一组聚焦的改动，可以直接审查。
验证：把精力花在刀刃上
你花了一个小时指挥智能体往正确方向走，觉得大家总算到位了。于是你开了一个拉取请求，标着“小重构”。结果它改了 47 个文件。你本想让人看看共享的校验逻辑，可它淹没在每个调用它的端点的改动、格式调整和几百行生成的测试里。你开始琢磨， team 的评审板上堆着一长串拉取请求，这个要等多久才能批下来。这条评审队列，就是实践中的那 441%。等待可以从两头缩短：一是让自己的改动更容易被人审查，二是让 Copilot 在任何人打开 diff 之前，先把例行检查和修复清掉。把改动拆成更小、更聚焦的拉取请求，而不是做成一个巨大的变更。你和你的智能体可以用堆叠式拉取请求，把有依赖关系的工作拆成更小的块。
这样每个 PR 都能单独审查，依赖关系一目了然，团队也能在你合并之前基于你的分支继续开发。常规质量问题在占用审查时间之前就能发现。GitHub Code Quality 会按照编码实践和组织标准检查变更，在交给人工审查者之前发现问题，为作者和审查者都节省时间。获取与变更匹配的审查帮助。Copilot 代码审查提供自动反馈，简单变更做轻量分析，复杂变更做深入分析。你可以自己设定分析深度，也可以让 Copilot 为每个 PR 自动选择。在更多代码库范围内检查安全问题。AI Scan 能发现 CodeQL 覆盖范围之外的语言和文件中的漏洞。AI 密钥检测有助于识别非结构化密钥，比如密码，这些是模式匹配容易漏掉的。让新依赖符合策略要求。许可证合规检查会在合并前对照公司规则检查依赖许可证。GitHub package firewall（目前对 npm 处于公开预览阶段）可以阻止违反已配置安全策略的下载。解决发现的问题和后续工作，无需时刻盯着每个 PR。Agentic Autofix 会针对安全问题提出修复方案，Agent Merge 则自动处理失败的检查、审查意见和合并冲突——帮你保持 PR 推进，并为合并做好准备。而且，如果你配置了，Copilot 甚至会在验证步骤通过后自动合并你的 PR。变更更小、常规工作已处理完毕，意味着来回沟通的轮次更少。审查者可以把注意力放在代码是否实现了你的意图，以及可能出现什么问题。
观察：从上线后发生的事中学习
变更获得批准，部署检查通过，你终于可以从清单上划掉它了。第二天早上，值班仪表盘显示间歇性超时，支持团队报告几位大客户受到影响。现在你在对比日志、发布历史和客户报告，同时有人问你是否应该回滚。
看到「全部检查通过」，已经不像过去那样让人安心了。需要把运维证据和工程上下文放到一起，才能判断下一步怎么做。拿真实行为来验证假设。Copilot 可以通过 Fabric 这类连接器接入可观测性工具和业务数据，帮你排查哪些请求或客户群受到了影响。把发现记录到有人能据此行动的地方。让 Copilot 起草一个问题单，附上支撑证据和验收标准，其中包含针对你发现的那个故障的回归测试。把有用的经验带到后续工作中。查看 Dreaming 给出的改进建议，它会利用会话和代码库活动来完善记忆、技能和代码审查指引。发布之后想弄清到底发生了什么，往往要在仪表板、聊天记录和提交历史之间来回切换。有了 Copilot 帮忙把这些信息串起来，你可以记录发现、创建后续问题单，并改进可供未来任务使用的指引。你能把更多时间花在决定需要改什么上，而不是重新梳理调查过程。你的下一个计划，也会从真实用户正在使用的软件中学到的东西出发。
从哪里开始
从手头已经有的某项工作开始，把眼光放到编码任务之外。它需要哪些上下文？你打算怎么审查和测试？上线之后怎么确认它真的有效？不必一次性改掉整个流程。从这周最让你头疼的一件事开始，让一个 agent 来处理它。然后再逐步扩展到流程的其他环节。当 agent 在整个工作流中都能帮上忙时，你也许终于会觉得自己的生产力配得上提交数量了。
我们在 GitHub Universe 2026 的「Agentic Engineering: Past the Pilot」中现场讨论了这个话题。
开始使用 Copilot >
Beyond code generation: A developer’s guide to agentic engineering 一文最早出现在 The GitHub Blog。
写代码变快了，但围着代码转的那些活儿并没有。本文介绍如何用 GitHub Copilot 做规划、写代码、审查改动、排查线上问题，以及哪些环节仍然需要你自己拿主意。
本文首发于 The GitHub Blog。