把 Agent 用出"资深工程师"的效果,关键不在提示词,而在你如何设计协作边界。这是我在真实任务中总结的方法。

资深工程师做事的方式

回想你见过的高级工程师接手陌生系统时的动作:

  1. 先读后写:花大量时间看现状——配置、日志、网络拓扑——而不是上来就改
  2. 方案先行:动手前列出"我打算做什么、影响什么、怎么回滚"
  3. 变更最小化:能用新增解决的绝不动既有代码
  4. 可验证:每一步都有明确的成功判据
  5. 留痕:决策有记录,后人能看懂为什么

Agent 完全可以按同样的纪律工作——前提是你给它同样的信息和边界。

落到 Agent 协作上的四个原则

1. 侦察与执行分离

让 Agent 先做一轮纯只读的侦察并汇报事实,再基于事实出方案。本次博客部署中,侦察发现了"服务器上已有 20+ 服务、80 端口被宿主机 nginx 占用"——没有这个事实,方案很可能错选成"再起一个容器化 nginx 反代",平添复杂度和端口冲突。

2. 写操作白名单化

危险的不是 Agent 执行命令,而是范围不受控的执行。好的做法:

  • 侦察阶段:只允许查询类命令
  • 执行阶段:把将要执行的写操作逐条列出,经确认后按清单执行
  • 清单本身成为审计记录:“本次变更了 DNS 一条记录、nginx 一个配置文件、新建一个目录”

3. 默认可回滚

要求 Agent 的每个方案自带回滚路径。一个天然的检验标准:这个变更是"新增"还是"修改"? 新增几乎总是更安全——新子域名、新 server block、新目录。本博客部署全程只新增、不修改,回滚就是四个删除动作。

4. 用平台能力替代临时脚本

资深工程师讨厌一次性胶水代码。Agent 很擅长写脚本,但更好的问题是"平台有没有现成能力":文件分发用 OSS 内网而不是手搭传输服务,命令执行用云助手而不是打洞 SSH。让 Agent 在写脚本之前先查平台目录,是减少长期维护负担的关键一招。

一个反面模式

最浪费的用法是把 Agent 当"高级搜索引擎 + 代码打字员":丢一个模糊需求,拿到一段没看过上下文的代码,直接贴进生产。这相当于让一个新员工背着你改生产系统。

结语

Agent 的产出质量 = 你的工程纪律 × Agent 的执行能力。前者是你能给的部分。把这个博客的部署实录(上一篇)当作一个可模仿的模板:侦察 → 方案 → 白名单执行 → 验证 → 留痕。