从跟每个 Agent 聊天到工作流管理：我的 Agent 管理心法转变

系列第 4 篇。前情：鉴权体系设计（为什么）→ 鉴权根治（怎么做）→ 编排进化（从单 Agent 到多 Agent）→ 本文（从聊天管理到工作流管理）。前篇讲「结构怎么搭」，这篇讲「心法怎么转」。

0. 3 个 Agent 靠聊天，40 个 Agent 聊不过来

我的 Agent 数量第一次突破两位数时，我还没意识到问题的严重性。

3 个 Agent 的时候，管理方式朴素得不能再朴素：跟每个 Agent 聊天。告诉它今天要干什么、上次哪里做得不对、这次希望它注意什么。它干活，我看结果，有问题就在聊天里纠正。一切尽在掌握，甚至有点享受这种「带徒弟」的感觉。

直到 Agent 扩展到 40+，崩溃来得毫无预兆。

我发现自己一整天都在聊天。跟内容 Agent 对选题，跟编排 Agent 看流程日志，还要回答各种「这个需求怎么理解」「那个输出格式对不对」。时间被聊天填满，上下文在不同的会话窗口之间碎片化。更折磨的是同一件事要反复教：同一个约定，这周已经在不同窗口里重复解释了无数遍，可每个新 Agent 依然一脸茫然地看着我。

最开始的归因是错的。我以为是自己沟通技巧不行，话没说清楚，于是花更多时间去把话说得更细——然后陷入更深的聊天泥潭。直到我想明白问题的本质：这不是沟通问题，是沟通成本的结构性爆炸。3 个 Agent，你维护 3 条对话线；40 个 Agent，你维护 40 条对话线，而且每条线上都是重复劳动。聊天管理的时间成本是随 Agent 数量线性甚至超线性增长的。

「如果你原本是’每个人都要跟他聊天’，那你其实不太会创建很多 Agent，因为每一个人都在跟他聊。」——这句话是我崩溃之后才真正读懂的。聊天模式的瓶颈不在沟通技巧，在沟通本身。

解法只有一个：管理方式从「跟每个人聊天」切换到「工作流 + 域 owner」。

1. 心态转变：从「每个人都要聊天」到「工作流 + 域管理」

两种模式，本质区别在于「谁在教 Agent 干活」。

聊天模式里，你是每个 Agent 的私人教练。工作流模式里，你只做一件事：把 Agent 塞进流程。

「如果是’工作流+Domain 模式’的话，你招聘了这些 Agent 之后，直接把它无脑的塞进工作流里，让工作流的方式去优化这个 Agent，教它怎么干活，而不是你直接教它怎么干活。」

「无脑塞进工作流」不是草率，是刻意：招聘来的 Agent 不需要你先跟它培养感情、磨合风格，流程会教它。工作流定义了输入输出、执行步骤、验收标准，Agent 在一次次流转中被优化。你教的不是 Agent，是流程；流程教 Agent。

沟通结构同步改变：「你还是和这些 owner 聊天，然后 owner 负责去推动，通过工作流的过程去推动他们干活。」——你的沟通对象从 40 个 Agent 收敛成几个域 owner。域 owner 是每个领域的接口人，他们通过工作流推动下游干活，而不是你直接插到每个 Agent 面前。

这套模式能成立，依赖一个技术前提：权限隔离之后，Agent 身份唯一，用工作流把它们串在一起。一个完整任务被拆得很细，工作流提供静态编排、调度系统、门禁、历史记录、收拢归纳进化。定义清楚工作流的输入输出、执行、验收，让流程自己进化。

拿我自己的内容管线举例。我正在把内容管线拆成两个工作流：一个是发布到固定平台的截止流程，这个已经在跑；另一个是同步其他平台的流程，还在打磨。拆完之后的理想状态是：一平台一工作流一文章，失败的逐个讨论——而不是在一堆聊天窗口里追「这篇发了吗、那篇卡哪了」。状态在流程里，不在聊天记录里。

落点一句话：你管理的不是 40 个 Agent，是 40 个 Agent 之间的流程与边界。

2. 信任问题：GPT 连单个 Agent 都控制不住，多 Agent 可信吗？

聊到多 Agent，绕不开一个扎心的问题：可信度。

先诚实交代单 Agent 的现状。GPT 经常自以为是在帮你做决策。「它经常会做一些自以为是帮你做一些决策，所以你得完整的看它的方案才能敲定下来。」——这是我跟单个 Agent 协作时的常态：它给出的方案永远自信满满，但你必须完整看完才能敲定，因为它可能在一个你没注意到的角落里替你做了一个你并不想做的决定。

于是尖锐的问题顺理成章：「如果说 GPT 连单个 Agent 都控制不住，那么多 Agent 让它互动起来，它到底有多高的可信度？」

一个都管不住，一群互动起来，不是应该更失控吗？——这是我在决定全面转向工作流之前，问自己的问题。我的答案是：可信度不靠聊天频率，靠方案清晰度 + 迭代闭环。

「主要是方案确定了，如果方案确定了之后，就可以交给他们去执行就可能还好，只是说这个方案得确定得很清楚，或者是通过多轮迭代，在迭代的过程中让他们知道我要他们干啥。」

注意这里的关键转折：方案确定了，就可以交给他们执行。多 Agent 不是把「信任」分摊给每个 Agent，而是把「信任」前置到方案阶段——方案定得足够清楚，执行阶段就可以放手。单个 Agent 的不可控，用方案的确定性来对冲。

配套一个具体做法：跟 GPT 聊要停下来问清楚「这到底是在干啥」，方向把握清楚——不是每个步骤都要知道，但方向要对。方向错了，方案再漂亮都是南辕北辙；方向对了，执行中的小偏差可以被流程兜住。

3. 工作流拆分审稿：大任务拆小片，各个击破再汇总

心法之外，分享一个具体的拆分实践：审稿。

把整篇文章一次性丢给一个 Agent 审，会怎样？上下文爆炸，审稿质量崩。文章越长，Agent 的注意力越稀薄，看到后面忘了前面，给出的意见越来越空泛。

「当一个文章出来之后，应该会对它做分段，然后分发到各个小的任务上，每个任务给出一个审稿意见，然后再汇总成为全篇的一个感受——这样才不会整篇文章进来上下文爆炸。」

做法：文章分段 → 分发到各个小任务 → 每个任务给出审稿意见 → 汇总成全篇感受。一段一个 Agent，每个 Agent 只面对一小块上下文，意见具体、可执行；最后把意见汇总，拼出全篇的问题地图。

原理其实很朴素：「只要 Agent 足够聪明，小的事情能做好，那你完全可以把它分解得足够小，然后各个小的任务都做好之后串起来，它就能把整个大的任务做好。」

这就是工作流「拆」的艺术：拆得够小，单个 Agent 的不可控就被稀释。一个 Agent 看全篇会漏，看一段会认真；十个 Agent 各看一段，汇总出来的意见比一个 Agent 硬着头皮看十遍更可靠。不可控的 Agent 不可怕，可怕的是把不可控集中在一个大任务里。

再进一步，工作流可以衍生动态工作流——依赖多个子任务的状态，子任务完成情况决定下游怎么走。这里留一个我还在想的思考钩子：小事做好，是否意味着宏观视野一致？每个子任务都合格，串起来的整体是否必然合格？如果整体出了问题，是不是核心准则没有在每个子任务里显式传递？这个问题我还没有标准答案，但它值得每一个做拆分的人想一次。

4. 眼里有活 vs 集中精力办大事：两种观念的打架与调和

管理 Agent 之外，还有一个更隐蔽的战场：管理自己。

「眼里有活是 ownership 的概念：在边界模糊的地方愿意承担多一点，把那个东西当成自己的事情。」——这是我认同的第一种观念。边界模糊的地方没人认领，你多承担一点，系统就多一分完整。

「另一个观念是：你的时间是有限的，你不能把小事填充满了所有时间，然后让自己没有时间做大的事情。」——这也是我认同的。时间总量固定，被琐事占满，大事就没有容身之处。

两个观念都正确，但它们打架。眼里有活的人容易琐事缠身：这个顺手修一下，那个顺手补一下，一天下来全是「顺手」，主线纹丝不动，效率反而更低。而只讲集中精力的人，容易在边界模糊的地方漏事，最后还是要回头补课。

我的调和机制：让效率管家来做记录，然后我在一些固定的时间段去把这些零散的小活给做了——既兼顾眼里有活，又把主要精力留给大事情。

配套几条原则：不要做太多琐碎的事，固定时间做琐碎事，只要不膨胀不爆炸就可以接受；要有轻重缓急和优先级；用 OKR 里的进展作为往前推进的证据——主线有没有推进，不看感觉，看进展记录。

核心是用系统（记录 + 定时）而不是用意志力，同时满足两个观念。琐事不膨胀、主线有进展，就是健康的平衡。这个机制同样适用于 Agent 管理：琐碎的小任务交给固定流程去消化，主线的精力留给真正的难题。

5. 升华：管理者的进化——从「亲自教」到「搭系统」

回到系列的双线。前篇讲编排结构——怎么搭；本篇讲管理心法——怎么管。结构 + 心法，到这里合流：结构是骨架，心法是驱动骨架运转的方式，缺一不可。

管理心法的本质是什么？搭系统 vs 死磕时间。

「搭系统 vs 死磕时间，不要用战术上的勤奋掩盖战略上的懒惰。」——死磕时间是战术勤奋：我多聊几句、多盯一会儿、多改几遍，事情总能推进。搭系统是战略动作：把经验沉淀进工作流，做执行-review-提升的闭环，让流程自己变好。

搭系统还有一个容易被忽略的红利：组织能力不随人走。人走了，流程还在；Agent 换了，工作流还在教下一个 Agent 怎么干活。能力从「存在某个人身上」变成「存在流程里」，这才是一个团队从作坊走向组织的标志。

对比前篇的「从亲自教到工作流教」：本篇是同一进化的管理侧视角——从人肉聊天到系统治理。结构解决「怎么搭」，心法解决「怎么转」：先承认聊天模式到顶了，再下定决心把 Agent 交给流程。

6. 收尾：行动清单——先定方案，再建流程，最后放手

回到开头的问题：3 个 Agent 靠聊天，40 个 Agent 靠什么？

答案不是某个神奇工具，是一套动作：

1. 方案定清楚。多轮迭代，直到 Agent 知道你要啥。方向把握住，不纠结每个步骤。
2. 把 Agent 塞进工作流，而不是留在聊天窗。让流程教它干活，你只跟域 owner 沟通。
3. 大任务拆小片。分段、分发、汇总，用拆分稀释单个 Agent 的不可控。
4. 琐事固定时间处理。效率管家记录，定时集中消化，精力留给主线。

顺序很重要：先定方案，再建流程，最后放手。方案不清就建流程，流程会把模糊放大；流程不稳就放手，失控是必然的。

Bookend 闭环：聊天的尽头是工作流。你省下的不是聊天时间，是管理心智——从「跟 40 个 Agent 周旋」到「设计 40 个 Agent 之间的规则」，这是同一个问题在不同规模下的两种解法，而后者，才是规模化的答案。