AI 编程 Agent 现在最该补的不是提示词，而是权限边界

我最近对 AI 编程 Agent 的看法有点变了。

以前我更关心它能不能写出可用代码：能不能理解项目结构，能不能改对类型，能不能自己跑测试。现在我觉得这已经不是最值得纠结的问题。真正麻烦的是：当 Agent 开始接入 GitHub、Playwright、MCP server、CLI、本地文件系统和云端环境以后，它不再只是一个“会补全代码的聊天框”，而更像一个临时加入项目的初级工程师。

区别在于，这个初级工程师可能没有稳定记忆，没有完整责任感，但它可以拿到 token、读 .env、执行 npm install、改 workflow、开 PR，甚至通过 MCP 调用更多外部工具。

所以我现在不太建议个人开发者一上来就把整个工作流交给 AI Agent。不是因为它没用，而是因为它开始有“权限成本”了。

为什么这个话题现在值得写

GitHub Copilot coding agent 已经把 Agent 放进 issue、PR 和云端开发流程里。GitHub 文档里明确提到，MCP server 可以让 Copilot 访问不同数据源和工具，仓库级 MCP 设置会影响 Copilot cloud agent 和 Copilot code review。GitHub 还说明，GitHub MCP server 和 Playwright MCP server 在相关功能里是默认启用的。

OpenAI 的 Codex CLI 也走向了本地终端路线。它的 README 里说得很直接：Codex CLI 是一个运行在本机的 coding agent；如果想要桌面体验，可以运行 codex app；如果要云端 Agent，则去 Codex Web。

Anthropic 的 Claude Code 文档也把安全单独拎出来讲。官方安全页强调了安全保障和使用建议；2026 年 2 月 Anthropic 还发布了 Claude Code Security，目标是用 Claude Code 做代码安全审查。

这些信息放在一起看，趋势很清楚：AI 编程工具正在从“编辑器里的建议”变成“带工具权限的工程参与者”。

这一步很关键。因为补全工具错了，大多数时候只是多删几行代码；Agent 错了，可能会把错误提交进分支、把不该暴露的文件带进上下文，或者在你没认真看的情况下执行一个依赖安装脚本。

我现在最在意的不是模型，而是它能碰什么

很多人评估 AI 编程工具时，第一反应还是比较模型：Claude、GPT、Gemini、o3、o4、谁更会写代码。这个比较不是没意义，但在 Agent 场景里，我觉得优先级要往后放。

更应该先问几个土问题：

它能不能读 .env？
它能不能访问私有仓库？
它能不能执行 shell？
它能不能安装依赖？
它能不能连浏览器自动化工具？
它能不能通过 MCP 调外部服务？
它生成的 PR 有没有强制 CI？
它改 workflow 文件时有没有额外审批？

这些问题看起来不像“AI 能力”，但它们才决定了这个 Agent 造成损害的半径。

我自己会把 AI 编程 Agent 分成三层：

第一层是“只读建议”。例如在编辑器里解释代码、生成小函数、根据已有文件写测试。这一层风险相对低，出错成本主要是浪费时间。

第二层是“可写但不可执行”。例如允许它改文件、生成 diff，但不让它直接跑命令、不让它访问密钥、不让它推送远端。这一层适合个人项目日常使用。

第三层是“可执行、可联网、可连接外部系统”。例如让它跑 npm install、执行迁移脚本、通过 MCP 访问 GitHub、浏览器、数据库或内部 API。这一层才是真正的 Agent 工作流，但也最应该谨慎。

很多宣传视频会直接展示第三层，因为效果最好看。但对个人开发者来说，最稳妥的起点通常是第二层。

一个更现实的使用姿势

如果我现在给一个自己的项目接 AI 编程 Agent，我不会先写一大堆 prompt。我会先建一个相对安全的运行环境。

比如最小化做法可以是这样：

git checkout -b ai-agent/small-refactor

# 确认当前工作区干净
git status --short

# 给 Agent 一个很窄的任务
# 例如：只重构 src/lib/date.ts，并补充 tests/date.test.ts

如果工具支持配置，我会优先限制它的可访问范围。一个比较朴素的约束文件可以这样写：

允许：
- 读取 src/、tests/、package.json、tsconfig.json
- 修改 src/lib/date.ts
- 新增或修改 tests/date.test.ts
- 运行 npm test -- tests/date.test.ts

禁止：
- 读取 .env、.env.local、.ssh/
- 修改 .github/workflows/
- 执行 curl、wget、scp、ssh
- 安装新依赖
- 修改 package-lock.json

这段配置不一定能直接复制到所有工具里，但思路很重要：不要只告诉 Agent “帮我完成任务”，还要告诉它“不要碰什么”。

如果项目里用了 GitHub MCP server，我会优先用 OAuth，而不是随手塞一个权限很大的 personal access token。GitHub 的 MCP 教程里也明确建议：MCP server 能用 OAuth 时优先用 OAuth，并且只授予任务所需的最小权限，定期审查连接、监控 Agent 通过 MCP 做了什么。

这不是安全洁癖。个人开发者经常把很多东西放在同一台电脑上：客户项目、自己的 SaaS、生产环境 token、Cloudflare key、数据库连接串、Stripe webhook secret。一个 Agent 只要拿错上下文，问题就不是“代码写得不优雅”。

它真正有价值的地方

讲了这么多限制，不代表我不看好 AI 编程 Agent。恰恰相反，我觉得它对个人开发者很有价值，只是价值不在“替你写完整产品”。

我现在更愿意让它做三类任务。

第一类是封闭范围的小重构。比如把一个工具函数拆出去，把重复逻辑收敛掉，把 Jest 测试补齐。这种任务上下文边界清楚，验收方式也清楚。

第二类是迁移里的机械活。比如把一个旧 API 调用从 pages/api 迁到新的 route handler，把一批组件从旧 props 改成新 props。人做很烦，Agent 做完再人工 review，性价比不错。

第三类是“读项目后给计划”。让它先不改代码，只输出修改计划、风险点和涉及文件列表。这个步骤经常比直接让它写代码更值钱，因为它能帮你把脑子从大量文件切换里解放出来。

我比较不建议一上来让 Agent 做“把这个想法做成一个完整 SaaS”。不是绝对不行，而是这种任务会把产品判断、架构取舍、依赖选择、权限管理、部署策略全混在一起。最后你可能得到一个能跑的 demo，但后续维护成本全在你身上。

AI 写出来的代码不会自动变成你的工程资产。只有你理解、能测试、能回滚、能维护的那部分，才算资产。

被夸大的地方也很明显

现在很多 Agent 演示喜欢强调“从 issue 到 PR 自动完成”。这个方向没问题，但它容易让人忽略一个事实：高质量 issue 本身就是工程能力。

一个写得很烂的 issue：

优化登录体验

丢给 Agent，结果大概率也是一坨猜测。

一个对 Agent 友好的 issue 反而更像工程任务单：

目标：
- 登录失败时保留用户已输入的 email
- 密码错误时展示 i18n key: auth.error.invalid_password
- 不修改现有 OAuth 登录逻辑

涉及文件：
- src/features/auth/LoginForm.tsx
- src/features/auth/login.schema.ts
- tests/auth/login-form.test.tsx

验收：
- npm test -- tests/auth/login-form.test.tsx
- 手动验证 email/password 登录失败场景

也就是说，Agent 没有消灭工程管理，它只是把“写清楚任务”的收益放大了。

这对独立开发者是好事，也是坏事。好处是你一个人也可以把 backlog 切得更细，让 Agent 帮你吃掉一部分机械劳动。坏处是，如果你本来就没有测试、没有任务拆解、没有分支策略，Agent 只会让混乱跑得更快。

个人开发者现在要不要投入

我的判断是：要投入，但不要重仓。

可以投入半天时间，把一个非核心项目跑通以下流程：

# 1. 新建隔离分支
git checkout -b ai-agent/evaluate

# 2. 选一个小任务
# 例如：补 3 个单元测试，不改业务逻辑

# 3. 让 Agent 先输出计划，不直接改代码

# 4. 允许它生成 diff

# 5. 本地跑测试
npm test

# 6. 人工 review 每一处修改
git diff

半天内只验证三件事：

第一，它能不能理解你的项目结构。

第二，它生成的代码有没有降低你的 review 成本，而不是制造更多解释成本。

第三，你能不能把权限控制在一个自己能接受的范围内。

如果这三件事都过不了，就先别把它接进主力工作流。继续把它当 ChatGPT、Copilot Chat 或代码解释器用就够了。

小团队也一样。不要一开始就讨论“全员 Agent 化”。更现实的做法是先选一个低风险仓库，规定 Agent 只能处理测试、文档、小重构，并且所有 PR 必须过 CI 和人工 review。等流程稳定后，再考虑让它碰更多业务代码。

我会继续观察什么

接下来我会重点看三个东西。

第一是权限模型会不会变细。Agent 工具如果只能给“允许全部”或“全部禁止”，那它很难成为长期生产工具。真正有用的是文件级、命令级、网络级、MCP server 级的权限控制。

第二是成本是否可预测。Agent 模式比聊天模式更容易产生多轮调用和隐藏消耗。尤其是云端 Agent，跑计划、读仓库、生成代码、修测试失败，都会消耗额度。个人开发者不能只看月费，还要看一次任务平均会烧掉多少预算。

第三是安全事件会不会逼出新的默认实践。最近已经出现过围绕 Codex 相关第三方 npm 包和 Android 应用的凭证窃取报道。这个事件不等于官方工具本身不安全，但它提醒了一件事：当一个热门 Agent 工具出现后，周边生态里的假包、假 UI、假客户端会很快跟上。

我的当前判断很简单：

AI 编程 Agent 值得用，但不值得迷信。它现在最适合接管边界清楚、可测试、可回滚的小任务。个人开发者真正该补的不是更多提示词模板，而是更好的仓库卫生、测试习惯、分支策略和权限边界。

如果这些基础没有，Agent 不会让你变成十倍工程师。它更可能让你用十倍速度制造一个自己也不敢合并的 diff。

参考来源

GitHub Docs：About GitHub Copilot cloud agent
GitHub Docs：About Model Context Protocol
GitHub Docs：Enhancing GitHub Copilot agent mode with MCP
GitHub Blog：GitHub Copilot coding agent public preview
OpenAI GitHub：openai/codex README 与 releases
Anthropic Docs：Claude Code Security
Anthropic News：Claude Code Security
TechRadar：关于 Codex 相关恶意 npm 包和 Android 应用的报道