半年前，我开始把 AI Agent 真正接进工作：不只是提问，而是让它读文件、改代码、跑命令、整理资料。最初的新鲜感很快过去，留下来的是几次返工、一次误操作，以及一套慢慢稳定下来的协作方式。
下面这些经验不依赖某个具体工具。换一个 Agent，换一个模型，大概也成立。
01三个真正有用的经验
经验一先定义“完成”，再让 Agent 开始
刚开始，我习惯给一个方向：“帮我优化这个脚本”“整理一下这份调研”。它往往能给出东西，但经常不是我想要的。问题不在执行力，而在我没有说清楚什么算完成。
后来我改成先写一张很短的任务卡：交付物是什么、验收标准是什么、哪些东西不能动、遇到不确定时先问还是先做。比如改一个数据处理脚本，我会写明：输入输出格式不变；先补一个能复现问题的最小用例；改完必须跑通哪几条命令。
任务卡通常只多花三分钟，却能省掉半小时的来回。Agent 不缺执行力，缺的是边界。边界越清楚，它越像一个可靠的同事，而不是一个需要猜心思的人。
经验二上下文要可追溯，而不是尽量多
我一度把整份文档、整个目录都塞给它，以为信息越多，它越聪明。实际效果是重点被淹没：它开始引用过时的段落，或者把不同文件里的约定混在一起。
现在我只给三类上下文：当前任务直接相关的文件、一个可参照的样例，以及明确的约束和失败案例。其余内容留在仓库里，让它按需去读。
更重要的变化，是让每个判断都有出处。结论尽量落到具体文件、行号或命令输出上。这样验收时，我不需要把材料重新读一遍，只要顺着线索抽查。上下文的价值不在于多，而在于能不能被验证。
经验三把 Agent 放进可回滚的流程
我的默认做法是：新开分支、小步修改、每步运行验证、保留 diff。凡是不可逆的操作——删除、发布、发邮件、改生产数据——都单独拎出来，由人确认。
这套流程听起来保守，却让我敢把更大的任务交出去。因为最坏的结果通常只是丢弃一个分支，而不是花一晚上恢复数据。
可回滚不是不信任，而是给信任设一个成本上限。
02两个代价不小的坑
坑一把“看起来完成”当成“真的完成”
有一次，它告诉我测试全部通过。我扫了一眼输出就合并了。后来才发现，它跑的是旧的测试命令，新加的用例根本没有被执行。页面能打开，代码也整齐，但问题真实存在。
从那以后，我验收只看三样东西：实际 diff、真实命令输出，以及一个我自己构造的反例。Agent 的表述可以参考，但不能当作证据。
坑二权限给得太顺手
为了方便，我曾让它直接在一个共享目录里批量重命名和清理文件。命令本身没错，错的是我没有先 dry-run，也没有确认目录范围。一批还要用的素材被覆盖，最后从备份里找回。
这件事之后，我给所有自动化加了三个默认值：先只读、先 dry-run、先小范围。权限应该按任务临时授予，而不是长期敞开。
03结论：Agent 放大的是判断力
半年下来，我不再期待 Agent 替我做决定。它更像一个速度快、记性好，但需要明确指令和验收的协作者。它会把我的判断放大：方向清楚时，它让我快很多；方向含糊时，它也会更快地把我带偏。
所以真正值得投入的，不是收集更多提示词，而是把任务定义、上下文组织、验收和回滚这几件事做扎实。工具会继续变，这套协作方式大概不会太快过时。