我看到 GitHub Copilot 在 JetBrains 相关更新里支持全局自定义 Agent，可以把 .agent.md 放到 ~/.copilot/agents 下面，让多个工作区复用。第一反应是：这东西对个人开发者很方便。第二反应是：它也很容易变成新的配置债。

开发工具一旦支持“全局规则”，就会诱惑我们把所有个人偏好都写进去。短期确实省事，长期可能让每个项目都背上同一套不一定合适的假设。

全局 Agent 解决的是重复上下文问题

个人开发者通常会维护多个项目：一个主产品、几个脚本、一个博客、一些客户项目。每个项目都重复告诉 AI “我喜欢 TypeScript”“测试用 pnpm”“不要随便改格式”，很烦。全局 Agent 配置的价值就在这里：把跨项目稳定的习惯抽出来。

~/.copilot/agents/
  code-review.agent.md
  typescript-maintainer.agent.md
  bug-triage.agent.md

如果设计得好，它可以像 dotfiles 一样，成为个人工作流的一部分。比如你可以有一个专门做代码审查的 Agent，一个专门帮你看错误日志的 Agent，一个专门做小范围重构的 Agent。

问题在于，全局规则很容易过期

全局配置最大的风险，是它看起来总是对的。比如你两年前写过一条规则：

优先使用 Jest，不要引入 Vitest。

后来新项目已经全面迁到 Vitest，但全局 Agent 仍然带着旧偏好。模型不会知道这是历史遗留，它会很认真地按你的旧规则做事。更麻烦的是，错误来源不在当前项目，review 的时候很难第一时间发现。

所以全局 Agent 不能写太多项目相关判断。它应该只放长期稳定的个人工作原则，而不是具体技术栈决策。

我会把全局规则分成三层

第一层是个人偏好，适合全局：

• 修改前先列计划；
• 默认小步提交；
• 不主动做无关重构；
• 解释风险时要区分必须修和建议改；
• 遇到不确定需求先列问题，不要猜。

第二层是项目约定，应该放在仓库里：

AGENTS.md
.github/copilot-instructions.md
docs/testing.md
docs/architecture.md

比如这个项目用 Next.js 还是 Remix，数据库是 Prisma 还是 Drizzle，测试命令是什么，哪些目录是生成代码，这些都应该跟着项目走。

第三层是任务临时约束，只能放在当前 prompt 里：

这次只修复导出失败问题，
不要重构 billing 模块，
不要修改 API response schema，
只允许改 src/export 和 tests/export。

这三层混在一起，就会出问题。全局文件里写项目规则，项目文件里写临时任务，最后 Agent 每次都带着一堆互相冲突的指令。

全局 Agent 应该短，而且要能被覆盖

我不建议把全局 Agent 写成长篇方法论。它越长，越容易和项目上下文打架。一个更现实的全局 Agent 可能只有这样：

# Role
你是一个保守的代码维护助手。

# Defaults
- 修改前先输出计划和影响范围；
- 优先最小改动；
- 不做无关重构；
- 不确定时列出问题；
- 修改后给出验证命令；
- 明确区分 bug、风险、建议。

# Override
项目级 AGENTS.md 和当前用户指令优先级高于本文件。

最后一段很重要。全局规则必须承认自己优先级最低。否则它会变成一个看不见的“超级 prompt”，偷偷影响所有项目。

小团队要小心个人配置污染团队协作

全局 Agent 对个人很好，对团队要谨慎。因为每个成员的全局配置不同，同一个任务在不同机器上可能得到不同建议。团队如果依赖 AI 生成代码，就需要把关键规则放进仓库，而不是放在个人目录。

我会建议团队只把这些内容个人化：

• 输出语言和格式偏好；
• 个人常用审查 checklist；
• 本地命令别名说明。

而这些必须项目化：

• 架构边界；
• 测试命令；
• 代码风格；
• 安全规则；
• 发布流程；
• 禁止修改的目录。

个人开发者的维护清单

如果你准备使用全局自定义 Agent，我建议加一个简单维护清单：

• 每个月看一次全局 agent 文件；
• 删除具体框架、库、版本号偏好；
• 只保留长期稳定的工作原则；
• 在每个项目里放更具体的 AGENTS.md；
• 遇到 AI 反复犯错，先检查是不是全局规则误导。

这个检查很土，但很有用。很多 AI 工具的问题，不是模型突然变差，而是我们在某个地方留下了一条过期规则。

我的判断

全局自定义 Agent 值得用，尤其适合个人开发者整理自己的工作流。但它不是越多越好，也不是把个人偏好全写进去就更智能。它更像 dotfiles：强大、贴身、容易积灰。

我的建议是：全局 Agent 只写工作原则，项目 Agent 写工程事实，当前 prompt 写临时约束。三层分清楚，它会提高效率；混在一起，它会成为新的配置债。

资料依据：GitHub Copilot for JetBrains 2026 年 5 月关于 Copilot CLI agent、unified sessions view 和全局 .agent.md 的公开更新。本文基于工程经验判断，没有做多项目对照测试，后续可以补一组同任务在不同 agent 配置下的输出差异。