把 Agent 当成一个要上岗的员工来带：这个专题讲什么

2026-08-25

如果你手上已经有一两个 Agent 在替你干活，大概会遇到这样一天：它跑完了，界面上每一步都是绿的，没有报错，你却说不上来事情到底办没办成。你去看结果，有的确实办成了，有的只是”调用成功”了。

我遇到这一天的时候，是在三条完全不同的线上分别遇到的。第一条是一个替我写公众号文章的 Agent，一次做一篇，我在流程中间盯着；第二条是一条把一批选题批量做成入库文章的流水线，我只在开工前和收工后出现；第三条是用 AI 写我那个内容仓库本身的代码。三条线的工具不同、节奏不同、失败的样子也不同，但它们把我坑到的地方是同一个。

这个专题就是从这个”同一个地方”开始的。

你分不清”跑通了”和”办成了”

先说清这件事在什么处境下才成为问题。

只有一个 Agent、你全程盯着的时候，这不是问题。它每一步在做什么你都看得见，做错了你当场就知道。问题出现在你开始不看它的时候——要么是你把它放到后台去跑一批，要么是它的动作里出现了你看不见的那一段：写到别的系统里去了、部署到别的机器上去了、提交进版本库里去了。

这一段一旦看不见，你就只剩下一个信息源：它自己报的状态。而这个状态说的是”我发出了那个动作”，不是”那个动作产生了你要的结果”。这两件事在顺利的时候是一回事，在不顺利的时候完全不是一回事，而且长得一模一样——都是一个看起来正常的返回。

我这三条线上，它各自长成这样：

写公众号那条线上，接口返回了成功，不代表草稿箱里真的多了一篇草稿。
批量那条线上，编排层报”已完成”，不代表磁盘上真的落了那个文件；反过来，它报”零完成”的时候，磁盘上也可能已经躺着好几篇了。这两个方向都会发生。
写代码那条线上，命令的退出码是 0，不代表构建真的构建了东西、部署真的把东西传上去了。

三条线是我在不同时间、用不同工具、干不同的活时独立踩到的。踩第三次的时候我才确认：这不是某个工具的毛病，是把动作交出去这件事本身自带的结构性问题。

一个当场能用的判据

抽象地讲”要验证结果”是没用的，人人都同意，人人都不会做。我给自己定的是一个当场能问出口的判据：

你现在拿到的这个”成功”，是谁说的？是执行方说的，还是目标状态说的？

如果答案是”执行方说的”，那它还不能算验收。往下再问一句：要确认这件事真的办成了，我应该去查什么？

这一句问出来，验收标准就自己浮出来了。写公众号那条线上，答案是”去查草稿列表里有没有这一条”；批量那条线上，答案是”去磁盘上数文件个数”；写代码那条线上，答案是”去查线上的文件数和状态码”。三个答案都跟”调用有没有报错”没有半点关系。

这个判据的好处是它不需要你懂那个系统。你不需要知道接口怎么设计的、编排框架怎么写的，你只需要分得清”我听说的”和”我查到的”。能被查到的那个东西，才是验收对象。

这个专题打算讲到哪一步

上面这条判据要落地，得落到一份能被别人看到的文件上，而不是落到你的自觉上。我这边落到的位置是这样：那个写公众号文章的 Agent，说明书里给草稿写入这一步写死了成功标准——拿到返回的凭据之后再次查询一次草稿列表，查到了才算数，并且明文写了一句：

禁止把「接口已提交」误报为「草稿已创建」。

我特别在意这句话是写成禁令的。它没有写成”建议再确认一下”，因为建议在执行的时候会被跳过；它写成了一条不许做的事，被跳过的时候是可查的。这个专题里大量的内容都是这个形状：把一条经验，写成一句可以被检查的约束。

整个专题分七个阶段，顺序大致就是我把一个 Agent 带上岗的顺序：

阶段	讲什么
定岗位	岗位卡写哪几段、一句话岗位定义怎么压、成功标准为什么要写成”做对了/做错了”两组、“本期不做”为什么必须单独成段
拆工序	判断点为什么要成对写、工序边界该切在哪、人工闸门该设在哪一步、失败之后退回哪一步
写大脑	Profile 分几节、输出结构怎么写死、判据怎么写成当场能执行的问法、哪些段落可以口语化
接手脚	能力清单怎么列、哪些权限不该给、关键外部能力怎么留降级路径、审查者的权限为什么不该大于被审查者
跑闭环	上面那条主判据的三个实例、静默失败、质量门的误报、验收样本按失败分支覆盖
交付复用	交付物为什么不该只有终稿、产物命名按什么频次设计、任务书为什么要当代码来维护、核实结果为什么要分等级
协作与移交	实现者和评审员为什么必须分开、核实为什么要从生产里拆出来、有副作用的动作为什么要收归单点串行

七个阶段里，前四个讲的是结构——这几阶我手上的一手材料就是那些卡和文档本身，所以写的是”它长什么样、为什么这么长”；后三个讲的是事故——这几阶的材料是我实际翻过的车。

接下来是这个专题最该说清楚的部分：哪些是我真做过的，哪些没有。

我做过的：写公众号那个 Agent 的完整链路，从收到素材、分析选题、确认方向、确认提纲、核验资料、写出正文，到生成封面、按结构落盘，是跑通了的，我对质量基本满意。批量那条流水线跑过很多批，实现者与独立评审两阶段的编排、脚本层的客观体检，都是实际在用的。用 AI 写仓库代码这条线，部署、质量门、并发纪律上的坑，都是我自己踩的。

我没做通的，有三处，专题里凡是碰到都会标出来：

第一，那个 Agent 的草稿写入至今没接通。它的交付终点实际上停在”文章和封面已生成并保存在本地”，不是”已经进了草稿箱”。有意思的是，它那句一句话岗位定义里写的交付终点是包含草稿箱的——所以那句话描述的是目标态，不是现状。这个落差本身我会单独讲。

第二，第二个岗位只写了岗位卡，工序还没拆。那是个做音视频转录的岗位，起因是我自己听播客想记笔记。目前只有一份岗位卡，工作流卡片还没产出，我正在分析流程阶段。所以这个专题里关于它，只会写到”先写岗位卡、正在拆工序”为止，它的实现细节还不存在，我不会去编。

第三，接单和收钱这一步我没走到。这个专题的终点是”可移交”——把自用的东西拆到别人也能用，比如把写死的本机路径拆成配置项。移交之后能不能变成生意，我没有实践，所以不写。

这条判据在什么情况下不适用

最后说边界，这一段我不想省。

第一，回查本身有成本，值得回查的是那些失败会被下游沉默继承的动作。 草稿有没有真的建出来，会一路影响到后面所有步骤，所以我把它写进了成功标准；而一个马上会被下一步覆盖掉的中间态，错了也传不下去。要问的是”这一步错了会不会被后面吃进去”，不是”这一步重不重要”。这条我目前只在草稿写入这一处真正立过规矩，别处怎么划，我还没有成型的记录。

第二，回查得能查到目标状态才算数。 如果你回查的那个查询接口，和你刚才调用的那个写入接口，是同一层缓存里的同一个东西，那你查到的还是执行方告诉你的话，只是换了个说法。这种情况下这条判据是失效的，你得换一个更外层的观察点。

第三，“有客观真值”的场景反而更容易破功。 内容类的工作没有真值，好不好只能靠人看，这逼着你每一步都去确认；代码类的工作有真值——构建过不过、测试红不红——反倒容易让人停止怀疑，看到一个 0 就认为成功了。所以这条判据最该被严格执行的地方，恰恰是那些看起来最容易自动验收的地方。

第四，这套东西是给”你已经不打算全程盯着”的场景写的。 如果你现在只有一个 Agent，你就在旁边看着它做每一步，那这七个阶段里绝大部分内容对你都是过度设计，先别做。等你开始把它放后台、开始一次派好几个、开始让它去碰你看不见的系统，再回来看。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。

延伸阅读

按阶段进入：