任务太复杂,要不要拆成子Agent?

先说结论,省得你翻到底:如果一个 Agent 干一件事老在中途跑偏、上下文越塞越长、改一个 prompt 就崩另一处,那就该拆;反过来,流程短、步骤之间咬得很紧、对延迟敏感,别拆,拆了你会后悔。我两种都踩过,下面拿实际例子聊。起因是我接了个活儿——给一个做跨境小家电的朋友(他公司叫暖屋,卖加湿器那种)做一个客服选品分析的助手。第一版我图省事,塞一个 Agent 里:读用户问题、查知识库、判断是售后还是选品、再调外部销量接口、最后润色成人话回复。跑了大概两天,崩得我心态有点炸。单体硬扛,我撞到的几个坑最直接的就是上下文打架。售后那套话术要求先共情再给方案,选品那套要求直给数据别废话,我把两套规则写一个 system prompt 里,结果它给售后问题也甩一堆销量表格,客户问我的加湿器不出雾,它回了我一段竞品价格分析……当时我盯着屏幕愣了三秒,心想这货是不是在玩我。第二个坑是改一处崩一处。我把售后的语气调软了点,选品那边的判断逻辑莫名其妙也变迟钝了。同一个脑子装太多指令,牵一发动全身,根本没法做隔离测试。第三,token 越烧越多。所有工具、所有知识库、所有规则全挂在一个会话里,一轮下来输入轻松四五千 token,慢且贵。拆开之后我后来改成一个分诊台 两个干活的小助手:前面一个轻量的路由 Agent,只干一件事——判断这是售后还是选品,然后甩给对应的子 Agent。售后助手只揣着售后知识库和那套共情话术;选品助手只连销量接口和数据模板。各管各的,互不污染。效果立竿见影的是可维护性。我改选品的逻辑,售后那边纹丝不动,终于能单独回归测试了。出了问题也好定位——是路由分错了,还是某个子 Agent 自己抽风,一眼能看出来。但拆也不是白拿好处。多了一跳,延迟肉眼可见地涨了,路由那一步多花了将近一秒;而且子 Agent 之间传参,我得自己定一个干净的中间格式,不然上游吐的字段下游读不懂,这块调了我大半天。单体 vs 拆分,我自己的对照表维度单体 Agent 硬扛拆成子 Agent / 多 Agent适合的任务流程短、步骤强耦合、一气呵成步骤多、职责能切干净、有明显分叉上下文容易互相污染,prompt 越堆越乱各管一摊,互不干扰改动影响牵一发动全身,难隔离测试改一个不动另一个,能单独回归延迟少一跳,快多了路由/传参,慢半拍到一秒token 成本单轮上下文臃肿,偏贵各子任务上下文精简,总体更省调试定位出错像开盲盒哪个环节崩了一眼可见上手门槛一个 prompt 起步,快要设计编排和中间格式,前期慢给你的决策建议(照着判就行)先问职责能不能切干净。能用一句话把任务分成A 干这个、B 干那个且互不依赖,就拆;切不开、来回交叉,别硬拆。看 prompt 长度。system prompt 写到自己都嫌乱、规则开始打架,信号很明显——该拆了。对延迟敏感就忍。实时对话、抢秒级响应的场景,多一跳的代价要掂量,单体可能反而舒服。别一上来就拆。我的经验是先单体快速验证能不能跑通,跑通了发现它又当爹又当妈忙不过来,再动手拆。过早拆分等于自找编排的罪受。说句实在的,真正让我敢这么折腾的,是搭这套东西现在门槛真不高了。我用的是那种零代码就能配智能体的平台,拖一拖、配一配,挂知识库、接外部接口、设路由分诊,全程没写几行代码。第一版单体是它,后来拆成多 Agent 也是它,改编排就是动几个配置块的事,省了我搭一堆胶水代码的功夫。当然它也不是万能,复杂的自定义逻辑还得自己想清楚结构,平台只帮你把搭这步变轻,怎么拆这道题它替不了你。(模型这块我直接调的讯飞星辰MaaS,现成大模型 API,没自己部署算力,省心。)你们做复杂 Agent 是倾向单体还是拆?有没有那种本以为该拆结果拆完更糟的翻车经历?评论区聊聊,我想看看是不是只有我交过这学费。