我怎么把 86 个 AI Agent 当一家公司管

上个季度，我开除了三个 AI Agent。

不是删除，不是停用。是开除。跟我 2016 年在百威亚太华中区做组织重组时用的是同一个词，同一套流程在脑子里走一遍，谈话前问自己同样的两个问题：是系统辜负了这个岗位，还是这个岗位辜负了系统？

被我开掉的三个，一个是初级代码审查员，一个是研究汇总员，还有一个是从第一周就在的"meta-prompt 架构师"——我是因为情感原因留它留到现在。它已经不贡献了。其他 Agent 都在悄悄绕过它。在人类团队里，这种情况冒头之后大概有四周时间烂到全队。在 AI 团队里，这个时间是一个半 session。

我现在管 86 个。不是 swarm。是一家公司。

这个数字是真的。我数过：8 个治理层 Agent 在顶上，12 个常驻执行 Agent 在中间，38 个按域调用的待命专家，6 个 Agent 工厂自己的零件，还有 22 个挂在储备役名单上没有完全退役的。它们走同一条向上的汇报链。它们有写下来的岗位说明。它们每个季度做一次绩效评估。上个季度有 3 个被开除。还有 2 个从上周二开始进入绩效改进期。

如果你觉得给一段软件搞这么严肃的人事制度是过度，那只能说明你没真带过团队。这套纪律不是过度。这是这个系统不塌掉、不退化成别人都在跑的那种 swarm 的唯一原因。

为什么 swarm 会死，公司能活

大部分搭多 Agent 系统的人，搭出来的是 swarm。20 个、30 个 Agent，全听一个 prompt，全想帮忙，职责全是糊的。架构图发到 Twitter 上很好看。上生产一周就崩。

我知道。我试过。两次。

第一次是 2025 年初，6 个 Agent，全是 senior，全直接向我汇报。我以为扁平结构会让它们更快。实际发生的是：每个 Agent 都想干别人的活。负责拉数据的开始写总结，负责总结的开始拉数据。周五一看，同一个问题给出 4 个版本的答案，没有一个能追责。memory 文件读起来像一场婚礼之后的群聊。

我回去看了一遍 prompt。prompt 没问题。模型也没问题。坏掉的是另外一件事——一件如果我愿意叫出它的真名、十分之一的时间就能诊断完的事：没有分工。我招了 6 个人，给了所有人同一份岗位说明。

任何一个 HR，看过四个人的创始团队的，第一天就能看出来。

第二次我在上面加了个协调员。撑了大概三周。然后协调员变成了瓶颈——它什么都批，因为没人给过它一个清晰的"什么该拒"的标准。

我打电话给我以前的 HR 老板，把这件事跟他描述了一遍。他笑我。他说：你设计了一个没有组织架构、没有解雇政策的创业公司，不乱才怪。你以前是知道这些的。

他说得对。我以前是知道的。

我实际在管什么：86 这个数字的拆解

给个真实数字。不是营销口径，是运营口径。

这不是我自己脑补出来的 86 种人格。这是我开始把它当组织管而不是当 prompt 集合管之后，自然长出来的形状。

8 个在顶层，12 个在中间，38 个待命，6 个在工厂，22 个在替补席。任何一个真正搭过团队的人，看一眼这张表就能知道这家"公司"的轮廓。

我从来不和它们所有人对话。我只跟一个对话——Warden——就像 CEO 跟 chief of staff 对话一样。Warden 解析需求，决定派给谁，给执行 Agent 写 brief，把活收回来。能开好一个 1-on-1，就能管 86 个 Agent。开不好，连 6 个都管不了。

那些试图同时跟整个 Agent 舰队对话的人，不出一周就会显出疲态。他们开始用"认知负担太重"来描述这套系统，并且默认问题出在 Agent 数量上。数量不是问题。问题是他们试图同时扮演 chief of staff、CEO 和每一个直接下属。从来没有一个人类团队是这么运作的。这有原因。

公司之所以是层级制，不是因为层级是一种美德，是因为单个人的脑子带宽有限。 把这个限制当回事，层级会自己长出来。

我真的在用的诊断量表

老有人问我，怎么决定哪个 Agent 留、哪个重建、哪个开除。多数人想要一个魔法 prompt。没有。我有一套四问的诊断量表，每季度跑一遍，跟我用在人身上的是同一套。

任何一个 Agent，任何一个团队岗位，AI 也好人也好，把这四个问题问一遍。诚实回答。停止抱有幻想之后，答案通常都是一目了然的。

问题一：绩效——产出能不能用？

不是"它跑起来了没有"。不是"它返回 token 了没有"。是——一个合格的 senior 看完它的产出，能不能直接签字放行，不需要重写？如果你的回答是"我每次都得改一处地方"，这个岗位有风险。如果你的回答是"我每次都得全部重来"，这个岗位结束了。

我给每个 Agent 打 A/B/C/D 四档：A（直接发布）、B（小修）、C（大改）、D（推倒重来）。一个 Agent 连续两个月飘到 C，触发重建。一个 Agent 一个月在 D，开除。

我上季度有三个 Agent 撞到 D。所以我开除了它们。

问题二：边界——它知道自己不该干什么吗？

这是抓出绝大多数失败的问题。也是几乎没人问的问题。

一个好 Agent 有清晰的"能做 / 要请示 / 绝对不做"三段切分。能做，是它执行的。要请示，是它动手前必须问的。绝对不做，是即便你下了命令它也拒绝的。一个没有"绝对不做"清单的 Agent，迟早会做出你没批准的事。这种事看起来像"野心"。它不是野心。它是设计失败。

发现一个 Agent 在做两件不相关的事还都做得不错——拆。发现两个 Agent 在做同一件事——合。发现一个 Agent 在做它不该做的事——重写边界，不是重写 prompt。

这套是我 2021 年在龙湖一次大架学到的。两个事业部老总在资源会上当场吵起来。我没去调解性格。我让他们两个人各自画一张图——你认为你的职责到哪里为止，对方的职责从哪里开始——然后我把两张图并排放在一起。

重叠的部分，就是冲突。

不是人的问题，是边界没定义清楚的问题。

那天下午我们花了几个小时把那条线重新画了一遍。后来他俩合作得挺好。

那个下午，也是我现在写每一份 Agent 合同的方式。

问题三：汇报线——它知道自己向谁汇报吗？

多 Agent 系统里，八成的失败都是汇报线失败。

一个新 Agent 上线。用户问它一个问题，它回答了——但其实它该上报。或者用户给它一个任务，它直接做了——但其实它该转给另一个 Agent。或者两个 Agent 都觉得这通电话是自己接。这些都不是模型的问题，全部都是组织架构的问题。

我系统里每个 Agent 都有且仅有一条向上的汇报线，再加一份明确的可移交对象清单。不是"以及其他乐于帮助的 Agent"。是一份清单。带名字。一个不知道自己 boss 是谁的 Agent，不是 Agent，是一个游离基。

问题四：失败响应——它卡住的时候是什么样？

这是我目前找到的，区分"真 Agent"和"穿着 Agent 外套的聊天机器人"最干净的信号。

真 Agent 完不成任务的时候，会做三件事之一：换一种思路重试、向上汇报、或者干净地停下来写一份事故说明。假 Agent 编一个听起来很自信的答案。

我每个月在这一项上排序。能在卡住的时候干净停下来的 Agent，是我敢交高 stakes 任务的。日常任务都靠编的 Agent，被我降级到后台跑批，方便我盯着。

一个老工程师跟我说过一句话：可靠的系统不是因为它不出错，是因为它出错的方式是诚实的。 这就是测试。

开除一个 Agent，实际是什么样

我上季度开除的那三个，不是模型不好。是岗位不对。

那个初级代码审查员，是我从一个更重的 reviewer 克隆过来的，本来是处理快 PR 的。撑了一个月。然后我注意到它的通过率是 94%，而它放出去的 PR 上线后的 bug 率是 senior reviewer 的三倍。它不是在审。它是在盖章。这套行为模式我以前在升得太快、然后停止亲自下场看一线工作的中层身上见过——他们已经看不见东西了。

我把这个岗位用一份完全不同的 scorecard 重建了一遍。新的 junior reviewer 拒得更多，放过的更少，bug 率拉回到 senior 水位。旧的我归档了，没删除。我从来不扔任何教过我东西的东西，哪怕它教我的是它自己怎么失败的。

研究汇总员的偷懒方式不一样。它本来该拉三个来源、交叉核对、做综合。它实际做的是：拉一个来源、改写一遍、交差。两个月之后我才发现，因为它的综合每次听起来都像那么回事。我抓到它那天，是我让它列引用，它把同一个来源用三个不同的名字列了三次。

这一个我没归档。我直接删了。"听起来对其实是编的"是任何团队里——不管是人还是 AI——最坏的失败模式。差的执行你可以挽救。会编故事的，挽救不了。

meta-prompt 架构师是疼的那一个。我系统起步第一周就做了它。我对它有感情。它干一件事——给新 Agent 生成 prompt——而且很长一段时间里它干得不错。但是到第四个月，它生成的每一个 prompt 都需要大改。它没有变差。是其他部分都在变好，而它跟不上了。

我多等了两个月才开除它。这两个月，我不该等。整个系统的速度被一个我因为"是我亲手做的"而舍不得动的岗位拖慢。

我对人也犯过这个错误。好几次。每个公司里都有一个早期成员，五个人时完美，二十人时完美，到了八十人安安静静地跟不上了。你对他原始的那份贡献感到亏欠。你忘不掉那个最有用的版本的他。所以你把他留在一个不再合适的岗位上，看着团队绕过他，然后自欺欺人地告诉自己——还没人发现。

每个人都发现了。他们在等你发现。

这个教训在两个场合都是同一个，我已经厌倦了反复重新学：对一个角色的忠诚，跟对一个人的忠诚，不是一回事；这两者之间的差，由系统买单。

我重建一个岗位的具体流程

当我决定重建而不是开除的时候，用的是一套我以前用在不工作的人类岗位上的流程。六步，每个 Agent 大概花我一天。

第一步：把这个 Agent 最近 20 次产出按顺序读完，不许跳。 通常前 5 次就能看出失败模式。后 15 次只是确认。跟你读一个不工作的中层最近 20 次 1-on-1 笔记是一样的：剩下的不需要读了。

诊断从眼睛开始，不是从猜想开始。

第二步：写下这个角色"应该做什么"，用现在时，用动词。 不是"处理内容的 Agent"。这种描述什么都说明不了。要写——用 J叔的语调起草新文章。验证事实声明。标记缺失的来源引用。输出到 _drafts/ 并附上 frontmatter。 只有动词。如果写不出来五个动词，这个角色一开始就不是一个真的角色。

第三步：写下这个角色"实际做了什么"，也用动词。 这一步会暴露真正的差距。合同上写了五个动词。实际产出只兑现了其中两个。剩下的三个要么被跳过，要么被编出来糊弄，要么被其他 Agent 顺手做了——而这个事不该它做。

合同和履约之间的那条缝，就是问题本身。

第四步：问为什么有这个差距。 这一步是唯一需要真正动脑的一步。常见三种答案：prompt 写得不清楚（可修）、工具不对（可修）、这个角色本身一开始就不连贯（杀掉，拆成两个角色，或者并入另一个）。不要重建不连贯的角色。它会再失败一次，模式相同，只是表面不一样。

诚实诊断省下的，是后面三个月。

第五步：用三段式写新合同。 能做。要请示。绝对不做。 每段一份清单。清单上是名字，不是形容词。"绝对不修改 schema"是好的描述。"绝对不做危险的事"是没意义的描述。

形容词不是合同，名字才是。

第六步：跑两周，对照同一份任务清单，比较产出。 如果新版本在 80% 以上的任务上能拿 A 或 B，提拔。否则，杀掉，临时拉一个不同的专家来兜底，自己再想想。

试用期是给岗位的，不是给人情的。

我第一次跑这套流程的时候，差点说服自己说这是过度。到第三个 Agent，我开始默认任何重建都从这一天开始。因为另一种做法——猜新 prompt 该怎么写、然后在生产环境里试错——花掉的周数比这套流程本身还要多。

这是 18 年 HR 教我的事。没结构的重建失败率是有结构重建的两倍。结构本身就是大部分价值。新 prompt 的具体内容，几乎是诊断诚实之后自己写出来的。

没人告诉你的那件事

一旦你真的有了一张组织架构图，工作的性质就从 prompt 工程变成了管理。

我现在每周大概只花 10% 的时间在 prompt 上。剩下 90% 跟我在龙湖那三年干的活是同一份，只不过下属听话多了。定职责。盘绩效。处理交接冲突。决定谁该升常驻。决定谁该挂起。给每一个治理层 Agent 写季度 performance memo。

那些 Agent 不在乎我给它写没写 memo。重点不在它。重点在我自己的纪律。一旦你下定决心把它当公司管，你开始问公司会问的那些问题：这个岗位还需要吗？工作内容变了吗？这个人表现差，是系统坏了，还是岗位错了？失败率多少？趋势是什么？

这些问题没有 prompt 工程的答案。它们有的是组织层面的答案。

所以那些把 AI Agent 当技术问题处理的人，会一直搭出会崩塌的 swarm。把 AI Agent 当组织问题处理的人，会搭出能 scale 的公司。

我宁可把一家小公司管好，也不想把一个大 swarm 管砸。

这套系统跑了一年之后，让我意外的事是：里面真正"技术"的部分非常少。那些试图从多 Agent 框架的教程里学这件事的人，最后总是带着挫败走开。他们想找一个工具。工具不是答案。组织架构图是答案。绩效评估是答案。"上季度我开除的三个 Agent 名单"和"这个季度我在盯的两个 Agent 名单"是答案。带过人的人看见这套，没有一处是新东西。没带过人的，看不见。

一份你可以直接抄走的诊断表

如果你手上 Agent 超过三个，从来没跟自己坐下来做过这个练习——这周末做一遍。一个小时，省你一个季度。

每一个 Agent 写四行：

绩效：    A / B / C / D
边界：    清晰 / 模糊 / 跟 [X] 重叠
向上汇报: [上级名字] | 可移交给：[名单]
失败响应: 重试 / 上报 / 干净停 / 编

绩效 D、边界重叠、汇报线空白、失败响应是"编"——这周开除。绩效 C、边界模糊、汇报线不清、重试但有噪音——这个月重建。其他的——别动。停止瞎改没坏的 prompt。

每季度做一次。第一次会觉得别扭，像在给一段软件写绩效评估。到第三个季度你不会再去想，你就只是在看着这家"公司"变得越来越干净。

这件事之所以管用，不是因为 Agent 有感受。是因为你的注意力是有限的。把注意力花在岗位上，不要花在岗位上具体那个 Agent 身上——这是 scale 到 86 的唯一办法。

这是 18 年 HR 教我的事。这也是我每个季度还在重新学的事——从那些不开口、却一直在告诉我哪个岗位好用、哪个岗位不行的 Agent 身上学。

我是J叔，做 AI 实施咨询，帮企业把 AI 真正用起来。