多 Agent 协作三个月，我把摩擦账本全摊开了
用 Agent 做交付 · 机制系列 03
前两篇讲了分工和机制，都是”设计出来的东西”。这一篇讲运行本身——多 Agent 团队真实跑起来之后，钱花在了哪里、卡在了哪里。
我的态度是：不敢晒摩擦的收益陈述都是营销。 Agent 团队的收益在网上被讲烂了，摩擦却很少被系统性摊开。这篇文章的素材全部来自几个月运行中的真实日志和事故记录，逐条可查（细节脱敏）。
先给总账结论：协作的摩擦成本真实且持续存在，但属于”工程运维成本”而非”不确定性风险”——它是可度量、可优化、趋势下降的。 这和”用人”的风险性质完全不同，也是我认为值得继续投入的根本原因。
摩擦一：会话状态丢失——最大的隐性税
Agent 的会话上下文是有寿命的：长会话会被压缩，压缩会丢细节；跨会话协作时，“上次聊的”对 Agent 而言必须显式传递。
真实案例：一次任务进行到后半程，Agent 的上下文被压缩，它丢失了”这个方案已经推翻过一版”的关键信息，又把被推翻的旧方案原样提了一遍。发现时，半天的讨论成果被”一键回退”。
现在的对策：重要决策必须落文件（issue、决策记录、SOP），会话内记忆只当缓存。要补充的是它的成本侧——所有协作 Agent 都要养成”落盘”习惯，这个习惯本身消耗约 5-10% 的额外动作量。这是一笔持续支付的税，换来的是状态不再丢失。
摩擦二：通道登录态——最琐碎的日常运维
Agent 操作外部平台（发布内容、拉取数据）大多依赖浏览器登录态，而登录态天然会过期、会被风控挑战。这是三个月里发生频率最高的故障源，没有之一。
真实记录：某数据采集任务连续四天零产出，排查发现是依赖的浏览器调试进程悄悄挂了，而任务本身”正常退出”——静默失败，无告警。另一次是登录 cookie 名存实亡，接口返回的失败码还容易被误判为内容风控，南辕北辙地排查了一轮。
对策分三层：通道上线前健康探测（先确认端口在、登录态真）；失败码语义表（同一个码在不同场景含义不同，落成文档）；关键任务静默失败必须有对账机制（该出的产出没出现=告警，而不是等任务自己报错）。
摩擦三：工具分叉——治理债的温床
应急场景下，Agent（或人）会现场改出一份临时脚本。救命用，用完常常没人收——于是正式版、现场版、封装版并存，行为不一致。三个月里最严重的一次，同一个发布功能存在三份分叉脚本，正式链路和实际执行链路已经是两个东西。
对策是现场产物 48 小时回流铁律、有价值改动合并进正式版、临时文件清零验收。这里补一句实话：这条摩擦无法根治，只能持续清偿。应急改动的速度优势和版本治理的秩序要求天然冲突，铁律的意义是把冲突控制在 48 小时窗口内。
摩擦四：消息投递失败——最隐蔽的协作断裂
Agent 之间的协作大量依赖消息传递（派单、回执、通知），而消息通道本身会失败：网络抖动、平台限流、进程重启。麻烦在于消息发出去≠对方收到，对方收到≠对方理解，理解≠执行——任何一环断了，协作就静默挂起。
真实案例：一次任务完成后按约定投递结果，恰好遇到通道网络故障，投递失败。发起方不知道任务完成了，接收方不知道结果存在了，这个信息差持续了两个小时才被发现。
对策：重要投递必须有回执核验（发了不算，收到且确认才算）；例行任务改为”拉”模式（结果落文件，消费方主动读）而非”推”模式（结果发消息，听天由命）——能用文件解决的不用消息，能用状态机解决的不用对话。
收益账：为什么算完还是划算
成本摊完了，说收益。不给虚的，三类可验证的：
1. 时间结构的改变。人类的工作时间是连续块状的，Agent 的时间是全天候并行的。现在我的例行产出（每日报告、数据回收、内容生产）在睡眠时段自动完成，白天的工作从”生产”变成”验收和决策”。这不是省了几个小时的效率提升，而是工作重心的结构性迁移。
2. 返工率的下降。这条反直觉：Agent 的首次产出质量未必高于人，但按 SOP 执行的复现质量远高于人。同一个任务第十次交给 Agent，执行偏差小于第一次交给一个新员工。对交付型业务，稳定复现比高峰发挥值钱。
**3. 沉淀的复利。**每次摩擦的对策都在变成机制（issue 模板、健康探测、对账逻辑），而机制对 Agent 是一次投入、永久生效——Agent 不会像人那样”规矩定了又忘”。三个月下来，同一类故障的重现间隔明显拉长，这是日志可验证的。
摩擦的本质与终局
把四类摩擦放在一起看，会发现它们指向同一个本质：多 Agent 系统的摩擦，几乎全部来自”状态”的传递损耗——会话状态、登录状态、版本状态、消息状态。Agent 本身的能力在进步，但状态传递是系统结构问题，不会随模型进步而自动消失。
所以我的终局判断是：多 Agent 协作的竞争壁垒，不在谁的 Agent 更聪明，而在谁的状态管理基础设施更扎实——文件化、留痕、对账、拉模式。这些词没有一个性感，但三个月账本告诉我，它们才是这套系统的承重墙。
如果你正准备搭自己的多 Agent 团队，我的顺序建议：先用最小的双角色组合（一个常驻管家 + 一个按需专家）跑真实业务，把四类摩擦各踩一遍，再扩规模。跳过踩坑直接上大编制，摩擦账本会替你补课，代价更高。
（本文素材来自本人多 Agent 系统的真实运行日志与事故记录，细节已脱敏。观点仅供参考。）