让 Agent 管到上线之后：Amp 团队的 8 条用法
很多人用编码 Agent 的方式还停在「编辑器里替我打字」：它写完，人逐行审，然后照旧提 PR、等 CI、手动上线。Amp 官方频道在 2026 年 10 月放出一段团队工程师的分享，讲他们怎么用 Agent 开发 Amp 本身：让 Agent 往横向走，从原型一路管到发版、看日志、开功能开关、上线后复查。这篇把其中能搬到任何 harness 上的做法整理成 8 条，Amp 专有功能只作说明，我们没有实际使用 Amp，标「未实测」。
说明：以下观点和例子来自 Amp 官方 YouTube 频道的2026 年 10 月工程师分享（按视频字幕整理）。里面提到的代码量、提交速度变化等是演讲者自述，我们没有核对；orbs、plugins 等是 Amp 的产品功能，换别的工具要找对应能力。
1. 提示词写「要什么」，别写「怎么做」
演讲者的判断是：去年那套提示词技巧（文件放最前、重点放最后、@ 提及具体文件）对现在的强模型已经不必要了，Amp 的网页、macOS、iOS 客户端甚至去掉了 @ 提及。他举的例子都只有一个目标：「把字节码编译器和虚拟机提速一倍」「照这几张截图做一个类似的项目」。
前提是 Agent 能自己摸清代码库。他把这叫 Agent、代码库、流程三件事一起改：只把打字换成 Agent，其余流程照 2016 年那样走，就拿不到别人看到的收益。
2. 让 Agent 往横向走
Agent 已经能纵向通吃前端、后端、数据库、基础设施。下一步是横向：帮你做原型，也能发版或者至少知道发了什么版本，能看 CI，能看生产日志、在生产环境排错，能开关功能开关，能读监控指标。
做法是把这些都变成 Agent 看得见的东西。他们仓库里有 15 个 AGENTS.md，分别说明怎么操作代码库的不同部分；开发服务器、云监控各有专门的 Skill；还写了查系统健康、拉 bug 报告诊断包、发用户邮件、开功能开关的插件。理由很直接：工具调用让模型能「摸到现实」，看不到文件是否存在，它就会猜。
3. 用最强的模型
他的意见是干活时用当前最好的模型（视频里是 Opus 5.5）。便宜模型的问题是你不知道它会在哪里出错，于是它多跑几轮、你再复查几遍。他举过一个例子：让一个便宜模型启动开发服务器，它试错了好几次命令和参数，最后烧掉的 token 反而更多。分类、路由这类有评测兜底的固定工作负载，才值得挑够用的最便宜模型。
4. 要变体，别来回磨
Agent 不是人，可以提「对人来说很过分」的要求：给我 20 个变体，再做一个小页面让我点着比较。演讲里的例子是一个没对齐的圆形图标：他不确定问题在哪，就让 Agent 给出几种修法的截图并排展示，看完才选了 B。查性能问题也一样：他不确定瓶颈在哪，就让 Agent 先在大数据上复现，再把最常见的几种优化都试一遍，用一张表交代每种改了多少。
与其跟 Agent 来回聊十轮，不如一次要 20 个变体加一个对比页，挑完再说。
5. 异步干活：上线后让它两小时回来看
他的原则是人不该等 Agent，也别开八个窗口盯着它们。现在 Agent 一跑就是 20 到 45 分钟，人做自己的事，轮到自己时再看。Amp 的 automations（定时）功能让 Agent 能自己约时间醒来，比如：「发布上线，两小时后检查推理错误率有没有升。」视频里那次它回报错误率没升，但发现了一个用户可见的回退，于是又让它回滚了。
换到别的工具，思路一样：把上线后复查写成定时任务，交给 Agent 去对比指标，人只处理它报上来的异常。
6. 先要证据，人只审承重代码
他们最常用的一句提示是「给我无可辩驳的证据，证明它现在能用」：Agent 在一次性云端机器里起开发服务器、写脚本跑端到端、截图、录屏、给出测试矩阵，再交代码。拿着这些去审，人关心的就变成：真能用吗？我看得懂原理吗？方案对吗？一个月后我知道怎么改吗？
人只细看承重文件，比如核心模块和数据库迁移，越靠系统边缘容错越大，CSS 出错和迁移出错不是一个级别。证据怎么要、怎么验收，站内 Agent 完成证据：用截图和录屏验收 有更细的写法。
7. 用新开的 Agent 验证 AGENTS.md
改了 AGENTS.md，Agent 到底照不照做？他们的做法是让 Agent 自己跑一个小评测：开五台全新的云端机器，用不同的请求测它是否每次都用了规定的插件发积分；有时还加对照组。比如发现 Agent 以为自己没有某个沙箱服务的权限，就让它找出缺的说明该写在哪，改完再开 10 个新会话验证。
这一条不依赖 Amp。任何 harness 都能开几个干净会话，拿同一组请求看行为变没变。说明写进去了，Agent 也可能根本没读。
8. 只让 Agent 写「机械文字」
他不让 Agent 写给人看的东西，例如 Slack 消息，因为对方期待那是你本人的想法。机械类文字可以交出去：教用户怎么在 Windows 上设环境变量、事故报告、参数说明文档。
| 旧习惯 | 演讲里的做法 |
|---|---|
| 提示词里 @ 文件、规定写法 | 一句话说目标，让 Agent 自己摸代码库 |
| Agent 只碰编辑器 | 能看 CI、日志、监控，能开功能开关、发版 |
| 来回微调一个结果 | 一次要多个变体加对比页 |
| 盯着 Agent 跑 | 异步，上线后定时回来复查 |
| 逐行审 500 行 | 先看证据和测试矩阵，只细审承重代码 |
| 写完 AGENTS.md 就算 | 开几个新会话评测它有没有生效 |
常见坑
- 横向权限一次给满。演讲里生产权限仍要人在终端里批，功能开关也要人点头。看日志、看指标可以只读，发版和发邮件要单独授权。
- 把演示当成证明。录屏好看不等于没 bug，证据要配测试矩阵和日志，关键路径仍要人看。
- 照搬「不用 PR、直推主干」。他们能这么做，前提是有功能开关、内部自用、Agent 能看生产、修 bug 很快。缺这些条件就别跟。
- 只改 AGENTS.md 不评测。说明写得再细，没用干净会话验证过，就不知道 Agent 读没读。
完成标准
- 你最近 5 条给 Agent 的提示里，至少 3 条只写了目标和验收条件。
- Agent 能自己启动开发服务器、读到 CI 结果和至少一种生产日志（可以只读）。
- 有一个上线后定时复查的任务，由 Agent 回报指标变化。
- 改过的 AGENTS.md 或 Skill 用至少 3 个新会话验证过行为。
最后
想先从团队实践里挑最省事的一条做起，可以看站内 编码 Agent 实战 5 条，再回来补本篇的横向权限和定时复查。
