GitHub Copilot CLI 上新自定义智能体：终端里的工作流引擎成型

GitHub 这两天在官方博客放出了 Copilot CLI 的一次重要更新——自定义智能体（Custom Agents）。一句话概括：原来你在终端里敲的那些一次性 Prompt，现在可以变成有名字、有上下文、有约束的可复用 Agent，跨项目、跨团队复用。

这件事的份量比表面看起来要重。过去一年里，命令行 AI 助手已经卷成红海，Claude Code、Aider、Codex CLI、Warp、Cursor Agent，谁都想抢占开发者最原始的入口——终端。GitHub 自己的 Copilot CLI 在去年 10 月引入自定义 Agent 和任务委托后，一直在补能力。这次的更新，本质上是把 CLI 从「一个会打字的 AI」推到了「一个能承载团队规范的工作流引擎」。

这次到底改了什么

核心动作只有一个：让 Prompt 变成 Agent。

在过去的用法里，你打开终端，输入 copilot，告诉它「帮我把这个 Go 服务的 Dockerfile 优化一下，顺便加上多阶段构建」。它会做得很好。但下一次你想做同样的事，得重新把上下文打一遍——你的技术栈是什么、团队的命名规范、CI 是 Actions 还是别的、镜像仓库在哪。

自定义智能体解决的就是这个「重复贴上下文」的问题。你可以在三个层级定义 Agent：

• 项目级：放在仓库的 .github/agents/ 目录下，跟代码一起进版本控制，团队成员 clone 下来就能用
• 用户级：放在 ~/.copilot/agents/，跨项目通用，比如你自己的「代码 Review 助手」
• 内置：GitHub 官方提供的几个默认 Agent

一个 Agent 配置长这样（YAML 前置元数据 + Markdown 指令）：

---
name: k8s-expert
description: "Cloud-native specialist that helps manage and generate Kubernetes YAML manifests."
tools:
  - read
  - write
  - shell
---

# 🧭 Kubernetes Agent Instructions

- Generate, explain, and optimize Kubernetes YAML configurations
- Always follow our team's resource naming convention: <team>-<service>-<env>
- Prefer Deployment + HPA over bare Pods
- Use `kubectl --dry-run=client -o yaml` for validation

在 Copilot CLI 的交互模式里输入 /agent，就能切换、创建或编辑 Agent。这套写法对熟悉 Claude Code CLAUDE.md 或者 Cursor Rules 的人来说毫无门槛，但 GitHub 的优势在于——它直接挂在 GitHub 账号体系和仓库权限模型上。

「一次性 Prompt」和「工作流」差在哪

这是 GitHub 这篇博客的标题（From one-off prompts to workflows）里特意强调的事情，也是这次更新真正的价值主张。

先说一次性 Prompt 的问题：

1. 不可复用：你写得再精妙，下个人不知道，自己一周后也忘了
2. 不可审查：团队没法 Code Review 一段口头描述
3. 不可演进：发现 Prompt 写得不好，没地方改
4. 上下文漂移：每次 LLM 的理解都略有偏差，输出不稳定

而当 Prompt 变成提交在仓库里的 Agent 文件，这四个问题同时被解掉了：

• 文件可以被任何人调用，命名清晰
• PR 流程天然带来审查，谁改了 Agent、为什么改、改前改后效果对比，全部在 GitHub 上留痕
• 可以像迭代代码一样迭代 Agent 指令
• 团队对「该怎么生成 K8s YAML」「该怎么写迁移脚本」有了单一事实源

说白了，这是把 AI 协作的最佳实践，沉淀成了团队的资产。这跟早期 DevOps 把运维知识固化成 Ansible Playbook 是一个套路。

和 MCP 拼起来才是完整图景

光有 Agent 指令还不够，CLI 还得能「干活」。Copilot CLI 内置了 MCP（Model Context Protocol）支持，这就让 Agent 能突破纯文本生成的范畴，去读取本地文件、连接 GitHub API、查询数据库、对接 Jira。

举个具体场景：你定义一个 incident-responder Agent，挂载三个 MCP Server：

• GitHub MCP（只读）：拉取最近的 PR、Issue、Actions 失败日志
• Datadog MCP：查询指标和告警
• Slack MCP：把分析结论 Post 到指定频道

半夜值班时，你在终端打开 CLI，切到这个 Agent，问一句「生产环境 5 分钟前的 503 飙升是怎么回事」。Agent 会按照你预设的排查 SOP，串起这三个数据源跑一遍，给你一份可以直接贴到事故复盘文档的初步分析。这事用一次性 Prompt 写出来要花半小时，做成 Agent 之后只是一行话。

任务委托：CLI 不只是本地的事

这次更新还有一个容易被忽略但值得关注的点——/delegate 委托能力的强化。

你可以在 Copilot CLI 里把一项任务推给云端的 Copilot Agent 异步执行：

/delegate Let's deal with issue #14 to add the rest of the CRUD endpoints to games

Copilot 会在云端开一个分支、写代码、跑测试、提 PR，全程你不用盯着。等你回来终端会告诉你 PR 已经待 Review。这个流程跟 Devin、Cursor Background Agent 想做的事情是一模一样的，区别在于 GitHub 离仓库最近——它本来就掌管着分支、PR、Actions。

把自定义 Agent 和 /delegate 组合起来，能玩出来的花样就多了。比如你定义一个「依赖升级专家」Agent，写好规则（不升级 major、跑完测试再 PR、PR 描述用团队模板），然后每周一早上批量 /delegate 几十个仓库的依赖升级任务，周二来看 PR 就行。

跟 Claude Code、Codex CLI 比一下

这是开发者关心的核心问题。横向对比一下当下三家主流 CLI Agent：

| 维度 | GitHub Copilot CLI | Claude Code | Codex CLI | |------|--------------------|-------------|-----------| | 自定义 Agent | ✅ 项目级 + 用户级 YAML | ✅ CLAUDE.md + Subagents | ✅ AGENTS.md | | MCP 支持 | ✅ 原生 | ✅ 原生（最早支持） | ✅ | | 云端委托 | ✅ /delegate | ⚠️ 第三方方案 | ✅ Codex Cloud | | 多模型 | ✅ 可切换 | ❌ 仅 Claude 系 | ❌ 仅 OpenAI 系 | | 仓库集成 | ✅ 原生最深 | 一般 | 一般 | | 计费 | 含在 Copilot 订阅 | 按 Token | 按 Token |

Copilot CLI 的独家优势是和 GitHub 仓库的深度耦合——Issue、PR、Actions、Projects 全是它的母语。劣势在过去一直是模型能力没 Claude/GPT 那么硬核，但今年 2 月 GitHub 还放出了 Copilot SDK 和多模型支持，把后端模型的选择权交给了开发者，这个短板正在被补。

给开发者的几条上手建议

如果你已经在用 Copilot CLI，今天就可以动手。如果还没装，一行 npm 搞定：

npm install -g @github/copilot
copilot  # 进入交互模式
/agent   # 创建或切换 Agent

几条来自实操的建议：

1. 从最痛的重复劳动开始。别一上来就想做一个「全能助手」，找你这周重复做了 3 次以上的事——比如「把 Markdown 表格转成 SQL DDL」「按团队规范生成新 service 的脚手架」——先做这种小而具体的 Agent
2. Agent 文件要进版本控制。.github/agents/ 目录是设计来这么用的，团队对 Agent 的迭代要走 PR 流程
3. 指令要写「负向约束」。比写「应该做什么」更重要的是写「不要做什么」，比如「不要使用 any 类型」「不要引入新的依赖除非明确允许」
4. 配合 MCP 拓展能力边界。纯文本 Agent 价值有限，挂上 GitHub MCP、数据库 MCP、监控 MCP 之后才是完全体
5. Awesome-copilot 仓库可以抄作业。社区已经沉淀了不少高质量 Agent 配置，照着改比从零写快

一个更大的趋势

把视角拉远看，这次更新是「AI 在命令行原生化」的又一步。过去十年，CLI 工具的范式是「命令 + 参数」，你得记住每个工具的用法。AI Agent 的范式是「意图 + 上下文」，你只需要说清楚想做什么，工具自己拼装命令。

再往前推一步，未来的 CLI 可能不再是 git、kubectl、docker 这种命令的集合，而是 code-reviewer、migration-runner、incident-responder 这些 Agent 的集合。每个 Agent 背后是一组工具、一份指令、一段团队知识。

GitHub 把这一步落地在了 Copilot CLI 上，而且第一时间把它和企业最关心的「可审查、可复用、可治理」绑在了一起。这是个聪明的位置。短期看，开发者多了一个趁手的工作流工具；长期看，团队的 AI 协作规范有了第一个值得托管在版本控制里的载体。

这事不大，但方向对。

参考来源

• GitHub Blog: From one-off prompts to workflows — GitHub 官方关于自定义智能体的详细介绍
• GitHub Docs: 为 Copilot CLI 创建和使用自定义智能体 — 官方中文文档，含完整配置说明
• GitHub Docs: 关于 GitHub Copilot CLI — Copilot CLI 整体概念与能力概述