Agent 怎么用

把这个词拆开，其实只有四样东西：

模型——会读会写会推理的那部分。 工具——它能真的动手的通道：读文件、跑命令、查数据库、发请求、点浏览器。 循环——做一步，看结果，再决定下一步。这是它跟"一问一答"最本质的差别。 停止条件——什么算做完了。是它自己判断，还是等你点头。

少了工具，它只能说；少了循环，它只能说一次；少了停止条件，它会一直干下去或者早早收工。

市面上很多东西都叫 agent，用这三条一问就清楚：

一、它能不能自己拿到反馈？ 能跑命令看到报错、能查库看到真实数据、能截图看到渲染结果——这是 agent。只能凭你转述——这是聊天框套了个壳。

二、出错谁先发现？ 它自己先发现，是 agent；永远是你先发现，那它只是个打字快的实习生。

三、什么时候停是谁定的？ 它按验收标准自己判断"通过了"，是 agent；每一步都要你说"继续"，那循环在你脑子里，不在它那里。

别去纠结"这算不算 agent"，去问"它的反馈从哪来"。 这个问题答不上来，加多少提示词都没用；答得上来，剩下的都是工程活。

不是自动化脚本。 脚本是路径写死的，条件变了就挂。agent 是路径现想的，代价是同一个输入两次结果可能不一样——所以稳定的活反而该写成脚本，让 agent 去调这个脚本。

不是"更长的提示词"。 提示词优化的收益很快见顶。真正拉开差距的是它手上有什么工具、能不能自己验证。

不是"人不用管了"。 它换来的是你从"每一步都参与"变成"定标准 + 验收"。管的总量没少，管的位置变了。

能不能交给 agent，最强的单一判据是：这个任务有没有一个"不用问人就能判对错"的裁判。

写代码之所以是 agent 最先做好的领域，不是因为代码简单，是因为代码有裁判——编译器、测试、报错、浏览器截图。写年终总结没有裁判，所以它永远只能给你个草稿。

先看可逆性，再看有没有裁判。 不可逆的一律留人工闸门，哪怕它做得再对——因为这类事的期望收益不是按平均算的，是按最坏的一次算的。

看你这几个项目的工作方式，agent 的三个核心零件你其实都有了，只是还没接成一条链：

一、你在写"坑清单"。 每个项目的 CLAUDE.md 里都有一节"踩过的坑"——正则里不能用 \w 判断中文边界、flex 容器里的行内标记要包一层、后台菜单是硬编码的改这个文件才生效。这就是 agent 的常驻上下文，而且是最值钱的那种：外面搜不到、只有踩过才知道。

二、你定了硬闸门。 删除必须先确认、动数据库要先报备、只读排查随便。这就是 agent 的权限边界，而且划得比大多数人都清楚。

三、你有自测的手段。 无头浏览器在 393px 视口量 scrollWidth、改完模板跑语法检查、请求线上要带 Host 头否则假 404。这就是裁判。

一、验收标准还是自然语言，不是命令。 "改完看一下手机上正不正常"——这句话它执行不了。改成一条能跑的命令 + 一个明确的断言（跑这个脚本，scrollWidth 必须等于 393），它就能自己循环到通过为止。这是收益最大的一步改造。

二、复盘没有固定的落点。 现在的坑是"想起来了就写进 CLAUDE.md"。应该变成每次收尾的固定动作：这次踩了什么、哪条已有规矩没生效、要不要升级成新规矩。不固定下来，信息就随对话消失了。

你不缺"用 agent 的意识"，缺的是把口头标准变成可执行标准。 一句"验收标准 = 这条命令退出码为 0"，比十句提示词优化都管用。

一次性的活也别只写目标。加上禁区和验收标准，返工率立刻降一半：

目标——要达成什么，不是"怎么做"。写"让手机上正文不横向滚动"，别写"给 body 加 overflow-x hidden"（那是你替它想的方案，可能是错的）。 禁区——哪些文件不许动、哪些操作要先问、哪些方案已经试过不行。 验收——用什么命令、看什么信号、什么值算通过。

放在项目根目录，每次自动进上下文。判断该不该写进去的标准只有一条：这件事能不能从代码里读出来？

该写： 踩过的坑和它的现象（"改了却不生效，先去查这个文件，别翻缓存"）、约定（"手机优先，先写默认样式再加宽屏"）、验证方法（那条自测命令怎么跑）、边界（"这个目录是生成物，绝不手改"）。

不该写： 目录结构、函数在哪（它自己会找）、通用编程常识、上次那个 bug 的修复过程（那是 git 的活）。

写坑的时候一定要写"现象"，不只写"结论"。 "菜单不显示要改 menu.htm"——它只有在遇到"菜单不显示"的时候才想得起来这条；写成"改了菜单配置却不显示 → 去看 menu.htm 那行"，它才认得出场景。

当一件事步骤固定、但每次参数不同，就该做成技能。比如你已经有的那个部署技能——一句话唤起，不用每次再讲一遍"先构建、再上传、再重启"。

做成技能的三个信号： - 你已经第三次在对话里复述同一套步骤了 - 这套步骤里有顺序不能错的地方（先备份再改、先构建再传） - 有每次都会忘的那一步（清缓存、重启服务、改完要 reload）

技能就是一个带名字和一句话说明的文件夹，里面写清步骤。说明那句话要写"什么时候该用"，不是"这是什么"——因为它是靠这句话决定要不要唤起你这个技能的。

只有两个理由值得单独开一个子 agent：

一、要独立干净的上下文。 比如让它把整个目录翻一遍找出所有引用点——这活会把几十个文件读进上下文，做完就没用了。放在子 agent 里，主线只拿到结论，不被垃圾撑爆。

二、要收窄工具权限。 排查线上问题的 agent，只给读文件、grep、只读查库，不给写权限。这不是防它使坏，是从结构上消除"手滑"这个可能性——比你在提示词里写十遍"不许改数据"可靠得多。

除此之外的"我想让它专门干某件事"，用技能就够了，别开子 agent。

名字：<一个动词短语，说清它干什么，比如 db-readonly-investigator>

什么时候用我：<一句话。这句是给主 agent 看的，它靠这句决定要不要叫你。
写"当需要查线上数据解释某个数字为什么不对时"，
别写"这是一个数据库排查助手"。>

我能用的工具：<明确列出。能不给的一律不给。
排查类：只给读文件 / 搜索 / 只读 SQL
改代码类：给读写 + 跑构建，不给部署
写文档类：只给读写，不给执行命令>

我要做的事：
1. <第一步做什么>
2. <第二步做什么>
3. <怎么算做完了——写成可验证的>

我绝不做的事：
- 任何写操作（UPDATE / INSERT / DELETE / DROP / 删文件）
- <本项目特有的禁区>
- 拿不准的时候不猜，直接说"这里我不确定，需要你确认"

我返回什么：
<固定格式。比如：
- 结论：一句话
- 证据：查了什么、看到什么（贴真实输出，不转述）
- 不确定的地方：列出来
不要写成给人看的报告，主线要的是数据。>

一、只读排查 agent。 线上数字对不上、页面不对劲的时候用。只给读权限，让它自己查库、看日志、读代码，回来给你"结论 + 证据 + 存疑"。这个最安全、用得最多、见效最快。

二、发布前自检 agent。 在你要发布之前跑：改了哪些文件、语法过不过、有没有碰到禁区目录、有没有漏掉那些"每次都忘"的收尾步骤（清缓存、重启、reload 后实测）。它不发布，只出一张检查单。

三、收尾复盘 agent。 一件事做完之后跑：这次踩了什么坑、哪条已有规矩本该拦住但没拦住、要不要补一条新规矩。它的产出直接是 CLAUDE.md 的一段 diff，你看一眼决定要不要合。

这三个的共同点：都不做不可逆的事。 先在零风险的地方把手感练出来，再往写操作那边挪。

别一上来就建一堆 agent。 建了不用的 agent 是负债——它会在不该出现的时候被唤起，还得你去纠正。一次只建一个，用满两周，再建下一个。

同一个坑踩第二次，说明上一次的教训停在了太低的台阶上。每次收尾问一句：这次的教训该待在哪一级？

第 1 级 · 对话里说过 —— 关掉就没了。默认所有教训都在这一级。 第 2 级 · 写进记忆 —— 跨对话还在。适合"这个项目的现状/决策"。 第 3 级 · 写进项目规矩 —— 每次自动生效。适合"这类改动必须怎么做"。 第 4 级 · 做成技能 —— 步骤不用再复述。适合"固定流程"。 第 5 级 · 变成检查项 —— 不靠记性，靠自动拦。适合"最容易忘、忘了代价大"的。

升到第 5 级的东西不该多。 大部分教训停在第 3 级就够了。但踩过两次的，必须往上升一级——这是硬规矩。

最强：机器判定。 退出码、语法检查、断言（这个值必须等于 393）。没有解释空间，它没法自欺欺人。

中等：可比对的产出。 截图、渲染出的 HTML、接口返回的 JSON。要它贴真实输出，不要它转述"看起来正常"。"看起来正常"这四个字是所有翻车的开始。

最弱：它自己说做完了。 只在改动很小、你会亲自复检的时候接受。

一个活如果连中等的裁判都造不出来，先别急着交给它——先花半小时把裁判造出来。 这半小时是这条链上回报率最高的半小时。

绿灯（它做完直接算数）： 读、查、搜、分析、生成草稿、跑只读命令。不用问。

黄灯（它做，但要给你看过再进下一步）： 改代码、改配置、改文档、生成迁移脚本。diff 摆出来，你扫一眼。

红灯（它准备，你执行）： 删数据、删文件、动生产库、发线上、对外发消息、动钱。它可以把命令写好、把影响面列清楚，但那一下回车是你按的。

这三档要提前写进项目规矩，别临场判断。 临场判断的问题是：你赶时间的时候标准会松，而赶时间正是最容易出事的时候。

流程改进不是"用更多 agent"，是"把判断标准从你脑子里搬到文件里"。 搬出去的每一条，都同时提升了两件事：agent 的下限，和你自己的一致性。

一、目标本身错了，它跑得越顺越糟。 agent 优化的是"怎么达成"，不是"该不该达成"。方向的账，它一分钱都替你担不了。 这也是为什么取舍类的问题不该交出去。

二、你不懂的领域，它的产出你没法验收。 前面说过，这里再强调一次：没有验货能力的地方，交出去的不是活，是风险。 想用它进入新领域，可以——但要在沙箱里学，别直接交付。

三、协作和组织的问题，它不解决。 一个改动要等三个部门排期，这跟 agent 快不快没关系。编码被解决得越彻底，编码之外的环节就越成为瓶颈——这是另一个话题了。

1. 一个 agent 能干多少活，取决于它能不能自己知道"我做对了没有"。
2. 先看可逆性，再看有没有裁判。不可逆的一律留人工闸门。
3. "看起来正常"这四个字，是所有翻车的开始。
4. 同一个坑踩第二次，说明上一次的教训停在了太低的台阶上。
5. 流程改进不是用更多 agent，是把判断标准从你脑子里搬到文件里。