先说结论,省得你翻到底:如果一个 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 是倾向单体还是拆?有没有那种"本以为该拆结果拆完更糟"的翻车经历?评论区聊聊,我想看看是不是只有我交过这学费。
