先给你看一个我亲手拆坏过的东西。一个企业客服问答的场景，需求很清楚：用户问一句话，系统给一个既准确又得体的回复。第一版我用一个模型加一个知识库就搞定了，跑得挺好。后来我起了个“精细化”的念头，觉得这么重要的链路，怎么能让一个模型大包大揽——于是我把它拆成了三个 Agent：第一个专门做意图识别，第二个专门做知识检索，第三个专门把检索结果润色成客服话术。三个各司其职，听起来无懈可击。上线当天就出事了。用户说“我上周买的东西想退”，第一个意图识别 Agent 把它归成了“售前咨询”（因为它只看到这一句话，看不到订单上下文）；第二个检索 Agent 拿着“售前咨询”这个标签，检索出来一堆产品介绍，它并不知道用户其实有个订单号躺在对话历史里；第三个润色 Agent 更离谱，它拿到的是一段冷冰冰的“暂不支持无理由退货”，为了“话术得体”，它热情洋溢地把这句话包装成了一大段道歉加安抚，末尾还自作主张加了句“我们会尽快为您处理退款”——而系统压根没有发起任何退款。一个模型本来能答对的问题，拆成三个“专家”之后，答错了，而且错得理直气壮。这件事让我盯着代码看了很久。问题不在于哪个 Agent 写得不好，三个 prompt 单独看都没毛病。问题在于拆分这个动作本身是有代价的，而我当时以为它是免费的。这篇文章想把这个代价讲透：一个 Agent 和多个 Agent，边界到底在哪里；什么时候多花这份代价能回本，什么时候纯属自找麻烦。我会拿 MaxKB 这个开源的一体化 Agent 平台的源码来讲——它的工作流引擎恰好把“单 Agent”“单 Agent 加工具”“真·多 Agent”三种形态都实现了，是难得的活教材。跟着它的代码走一遍，你手里会多一条能落地的拆分判据，也会看清我最想反驳的