AI Agent 自主性：让 Claude 和 Cursor 像资深工程师一样工作
Tokyo AI Dad•••3 分钟阅读
**先说结论：**AI Agent 的自主性只能和它的验证能力一起提高。给 Claude 或 Cursor 明确的目标、范围、权限、停止条件、证据要求和人工升级路径；这份工作契约，才是让 agent 像资深工程师而不只是“写得快”的关键。
原文是 Addy Osmani 在 Elevate 上发布的 《Agentic Autonomy Levels》，时间是 2026 年 7 月 3 日。
这篇不是逐句翻译，而是一篇面向普通读者的拆解：为什么 Claude Code、Cursor、Codex 这类 AI coding agent 有时像“刚入门的实习生”，有时又像“能自己推进事情的资深工程师”？
答案不是一句“模型更聪明了”。
更准确地说，关键在一套 agent skills：让 AI 知道目标是什么、边界在哪里、能做什么、做到什么算完成、拿什么证明自己做对了、什么时候必须停下来找人。
换成生活里的比喻：
- 初级助手会说：“我可以试试。”
- 熟练助手会说：“我做了，看看行不行。”
- 资深工程师会说：“目标是这个，范围是这个，风险是这些，我已经跑了这些验证；剩下这个判断需要你拍板。”
Addy 文章真正有价值的地方，是把这种差别拆成了一个可操作的“自主性等级”。
图 1：Addy 的核心提醒是：自主性不是一个单纯的等级徽章。越高不一定越好。它必须同时看行动自主性、编排能力、风险、可回滚性和证据质量。
一句话讲清楚
让 Claude/Cursor 像资深工程师，不是要给它一句更神奇的 prompt。
而是要把“聊天”改造成“工程操作系统”：
目标 → 范围 → 权限 → 执行 → 验证 → 证据 → 人类判断
这也是 Addy 说的变化：讨论的重点正在从 prompting 转向 operating。
以前我们问：“怎么提示 AI 才能写出好代码？”
现在更重要的问题是：
这个任务应该给 AI 多大自主权？什么证据能证明这个自主权是安全的？
这篇应该怎么读
这类文章最容易读偏。
如果只记住“Level 5”“agent factory”“上千个 agent”，你会被热闹带走。真正该学的是：怎样把 AI 的自主性变成一个可控制、可验证、可回滚的工程选择。
我建议这样拆：
| 分类 | 应该带走什么 | 不要被什么带偏 |
|---|---|---|
| 该学 | 自主性不是信任问题，而是验证问题 | “我敢让 AI 自己跑，所以我更先进” |
| 该学 | 工作契约：目标、范围、权限、停止条件、证据、预算 | 只追求更长、更复杂的 prompt |
| 该学 | 证据包：测试、diff、日志、截图、风险说明 | 用 agent 的漂亮总结代替 review |
| 周末可试 | 给一个低风险任务写工作契约，让 AI 先计划再执行 | 一上来就让 AI 改付款、权限、生产数据 |
| 周末可试 | 用两个 agent 做只读调研，再让自己合并结论 | 让多个 agent 同时改同一片代码 |
| 暂时忽略 | 具体命令名和工具名，比如某个 /goal 或 /loop | 工具名会变，工作方法才重要 |
| 多半是噪音 | “IDE 已死”“人类工程师要消失”“我们有 1000 个 agent” | 这些通常没有告诉你验证和回滚怎么做 |
| 可能真有用 | sandbox、权限边界、独立 reviewer、自动测试、可回滚部署 | 它们不炫，但能让自主性变安全 |
所以，这篇文章最好不是当趋势文章读，而是当一张检查表读：
下一次我把任务交给 Claude/Cursor 前，能不能先说清楚：目标、边界、证据和停止条件？
六个等级：从自动补全到 Agent 工厂
Addy 把 agent 的自主性分成 0 到 5 级。普通人可以这样理解：
| 等级 | 像什么 | 适合什么任务 | 最大风险 |
|---|---|---|---|
| 0 辅助建议 | 自动补全、建议员 | 小改动、需要你自己判断的工作 | 你误信建议 |
| 1 监督执行 | 每步请示的助手 | 大多数日常探索和小修小补 | 批准疲劳 |
| 2 有边界委托 | 接一个明确 ticket 的工程师 | 目标、范围、完成标准都清楚的任务 | 边界没写清 |
| 3 目标驱动 | 会循环推进的工程师 | 可自动衡量成功的目标 | 目标太虚，越做越偏 |
| 4 并行委托 | 多人小组分工 | 能切成互不冲突的小任务 | 假并行、冲突、重复劳动 |
| 5 异常管理 | 工程流水线 / Agent 工厂 | 可由系统持续派工和验证的队列 | 验证不过关却自动扩散 |
这里最容易误解的是：等级高不代表更先进。
如果任务是“改一下付款逻辑”，但是没有测试、没有回滚方案、没有安全审查，让 agent 开到 5 级就是危险的。反过来，如果任务是“批量整理 100 个文档标题”，只要有规则和抽样检查，给更高自主性反而很合理。
所以，真正的原则是：
自主性等级要跟验证能力匹配，而不是跟你的野心匹配。
“资深感”来自工作契约
一个资深工程师不会拿到一句“优化一下”就闷头乱改。他会先把任务变成可验证的工作契约。
这也是你给 Claude/Cursor 写任务时最该补上的东西。
图 2：让 agent 变得可靠的不是更多形容词，而是更清楚的契约：目标、范围、权限、停止条件、证据、升级规则和预算。
可以直接用这个模板：
目标：我希望达成什么结果，不是希望你做什么动作。
范围：你可以改哪些文件、哪些模块、哪些页面。
非目标：哪些东西不要碰。
权限：能否运行命令、安装包、访问外部服务、修改数据库。
停止条件：什么指标达标就停，什么情况必须停。
证据：需要给我哪些测试、日志、截图、diff、复现步骤。
升级：遇到什么不确定情况必须问我。
预算：最多花多少时间、token、尝试次数、并行 agent 数。
比如不要说：
帮我让首页更快。
更好的说法是：
目标：把首页移动端 Lighthouse performance 提到 90 以上。
范围：只能改 app 首页和直接依赖的组件，不改设计语言。
权限：可以读文件、改代码、运行现有测试和 build，不安装新依赖。
停止条件：Lighthouse 90+，npm run build 通过，核心视觉不变。
证据：给出改动列表、build 输出、性能前后对比和截图。
升级：如果需要删除功能、改 API、引入缓存策略，先问我。
预算：最多两轮尝试。
这时候，AI 更容易表现得像资深工程师，因为你已经把“工程判断”编码进了任务本身。
证据比总结重要
Addy 文章里有一个非常重要的暗线：不要让 agent 的总结替代你的 review。
AI 很会写总结，但总结不是证据。
真正可信的是：
- 测试是否通过
- 类型检查是否通过
- lint 是否通过
- 截图是否和预期一致
- 日志是否能复现问题
- diff 是否只改了该改的地方
- reviewer agent 或人类 reviewer 是否指出风险
普通人可以记一个简单判断：
如果你只能看 AI 自己说“我已经完成了”，那还不叫高自主性。
如果它能拿出独立证据证明“为什么完成了”，才有资格提高自主性。
为什么 Cursor/Claude 会“突然变强”
很多人第一次用 AI 写代码，会经历两个阶段。
第一阶段：惊艳。它几秒钟写出一大段代码。
第二阶段：失望。代码能跑一点，但细节不稳、边界不清、改坏别的地方。
Addy 的模型解释了这个落差：你看到的是“生成能力”，但工程真正需要的是“闭环能力”。
资深工程师的工作不是只写代码，而是：
- 读懂上下文。
- 确定目标。
- 限制改动范围。
- 做最小可验证改动。
- 跑测试。
- 看 diff。
- 解释风险。
- 知道何时停。
Claude、Cursor、Codex 这类工具要真正好用，也必须被放进这个闭环。否则它只是更快地产生代码。
并行不是“多开几个窗口”
Addy 特别强调，到了第 4 级和第 5 级，问题不再是“单个 agent 多聪明”，而是“你会不会管理一组 agent”。
这像带一个工程团队。
你不能让 5 个工程师同时改同一个文件、解决同一个模糊问题。那只会制造冲突。
好的并行必须满足几个条件：
- 每个 agent 有清楚的任务切片。
- 每个 agent 有隔离的工作区。
- 每个 agent 有自己的完成标准。
- 每个 agent 的输出都要进入 review 队列。
- 最后有人或系统负责合并证据和决策。
图 3：第 5 级不是“AI 想干嘛就干嘛”。更像一个受控流水线：任务自动进入队列，manager agent 分派工作，worker agent 独立执行，验证门检查证据，人类只处理异常。
四个常见坑
Addy 列出的反模式很实用，我用更口语化的方式重讲一遍。
1. 把自主性当荣誉徽章
“我们已经 Level 5 了”没有意义。真正的问题是：你的验证系统配得上 Level 5 吗？
2. 权限洗白
一开始每步都要批准，很烦。然后你一气之下给 agent 全部权限。短期舒服，长期危险。
3. 用总结代替审查
AI 说“我修好了”，不等于它修好了。你要看测试、diff、截图、日志和风险。
4. 假装自己有 Agent 团队
开了很多 agent，但所有切分、沟通、合并、验收都还靠你手动做。这不是编排，只是把混乱变多。
周末可以试的三个小实验
这篇文章最适合周末试，而不是周一早上直接上生产。
实验一：给一个低风险任务写工作契约
选一个不会造成真实损失的小任务，比如整理 README、补一个测试、修一个样式 bug。先不让 AI 改代码，只让它把任务拆成目标、范围、非目标、风险和证据。你会很快发现：任务写清楚以后，agent 的输出会稳定很多。
实验二：要求它交“证据包”
让 Claude/Cursor 每次完成任务后，不只写总结，而是按固定格式交付：
- 改了什么
- 为什么这样改
- 跑了哪些验证
- 还有哪些风险
- 哪些地方需要人类判断
这比“帮我总结一下你做了什么”有用得多。
实验三：做一次只读并行
开两个 agent，但只让它们读，不让它们改。比如一个分析性能瓶颈，一个分析测试缺口。最后你自己合并结论。这个实验能让你感受“并行调研”的价值，同时不会引入 merge conflict。
先不要试这些：
- 不要让多个 agent 同时改同一批文件。
- 不要把支付、权限、登录、生产数据库当第一个实验。
- 不要因为觉得审批麻烦，就给 agent 一次性开全权限。
- 不要把“AI 说完成了”当作完成。
真正值得练的是这 6 个动作：
- 先给任务选等级。是建议、监督执行、边界委托、目标驱动，还是并行？
- 写工作契约。目标、范围、非目标、权限、停止条件、证据、预算。
- 要求它先计划，不要马上改。
- 要求每一步产出证据，而不是只写解释。
- 风险越大，权限越小，回滚越清楚。
- 一旦需要并行，先切任务边界，再启动多个 agent。
一个好用的提示词是：
请先不要改代码。先把这个任务拆成：
1. 目标
2. 范围
3. 非目标
4. 风险
5. 需要验证的证据
6. 推荐自主性等级
7. 你需要我确认的问题
等我确认后，再开始执行。
这句提示词的目的不是“让 AI 更听话”，而是让它进入工程工作模式。
最后：资深工程师不会消失，但资深方式会被编码
这篇文章最值得记住的一句话是：
AI coding 的未来，不是把人从工程里拿掉，而是把资深工程师的工作方式变成可复用的系统。
资深工程师真正厉害的地方，不只是会写代码。
而是会控制风险、拆分问题、定义完成、验证事实、判断何时升级、什么时候不该继续。
Claude/Cursor 变强的路径，也不是“让它更像一个会聊天的人”，而是让它学会这些工程动作。
所以，下次你觉得 AI 不靠谱，先别急着换模型。
先问自己：
我有没有给它一个资深工程师会要求的工作环境？