别急着上Multi-Agent，先看看哪些坑是真的坑

Multi-Agent到底怎么搞？

一群实战派吵了一下午，这些是干货

这句话是在场的一位嘉宾说的，就是那种每天跟底层模型打交道、听惯了"Agent将改变一切"的人。一个卖铲子的人，先说铲子不一定管用，这种坦诚在现在的AI圈确实不多见。

但也正是因为这句话，整场对话才不像在浪费时间。

不是那种"AI改造一切行业"的论坛腔，也不是照本宣科的融资路演。五个人坐在那儿聊了一下午，话题只有一个：Multi-Agent这东西，到底什么时候真能用上？

来的人挺有意思，五个完全不同的赛道：

李粒在TiDB，给全球头部AI公司做基础设施。他眼里的Multi-Agent是从数据库视角看的——海量并发、状态管理、数据一致性，这些才是真的疼。

陆剑锋在WIZ.AI，做东南亚和拉美的语音客服AI。他的场景简单粗暴：打电话，超过2秒不响应客户就挂了。什么优雅架构，在延迟面前都得低头。

陈亦凡做EverMind，搞Agent记忆基础设施。这活儿听起来抽象，其实是解决一个核心问题——Agent干着干着就忘了自己要干嘛，怎么破？

徐安邦的Loova AI做视频生成Agent，Pipeline极长——脚本、素材、剪辑、审核，每一步都可能翻车。

施燚在DeiNai，做红人营销AI Agent。他的Agent要去跟网红谈价格、谈合同、谈排期，对面是真人，Agent得像人一样博弈。

五个人的实战经验加起来，比任何Benchmark都值钱。他们不是在讨论"Multi-Agent能不能做"，而是在复盘"Multi-Agent我做过了，哪些坑是真的坑"。

扯了这么多，一个判断标准慢慢浮出来了。

你的业务里有没有"角色冲突"。

如果一件事从头到尾目标一致、逻辑连贯，单Agent大概率能搞定。但如果你发现业务里存在不同的角色、不同的目标、甚至互相较劲的力量——那Multi-Agent不是炫技，是刚需。

具体怎么判断？四个标尺。

标尺一：角色冲突论（李粒，TiDB）

李粒打了个比方，构建Agent系统跟构建一家企业差不多。

一家公司里，PM想把产品做完善，程序员想尽快交付，QA想拦住你不让上线。三个角色，三个目标，互相冲突。

单Agent就像一个全能员工，你再聪明，自己跟自己吵不起来。真实决策是在冲突里磨出来的。Multi-Agent模拟的是"各自为战又被迫协作"的张力。很多公司上来就做Multi-Agent架构，结果业务根本没有角色冲突，纯粹给自己加戏。

标尺二：能力分级论（陆剑锋，WIZ.AI）

陆剑锋的语音客服场景特别具体。同一个系统，营销需要甜美的声音，催账需要严厉的语气。换个Prompt就行？不行。不同任务需要的推理能力和响应速度完全不同。营销可以慢慢聊，催账必须快准狠，超过2秒不响应客户直接挂线。

让同一个Agent既处理高并发查询，又处理深度推理的投诉分析，还控制语音情感，这不就是逼一个人精神分裂吗？能力差异太大的任务硬塞给一个Agent，不是架构简洁，是偷懒。

标尺三：上下文管理论（徐安邦，Loova AI）

徐安邦的判断角度很技术。他的视频生成Pipeline很长，脚本、素材、剪辑、审核，一环扣一环。说透了就一句话，Tool Calling做不了的协同，才需要Multi-Agent。

关键看上下文怎么流。如果全量上下文塞给Tool就能搞定，Tool够了。但如果有的环节要保持风格一致性，有的要Loop和回溯，你就得给每个子Agent独立的上下文空间。全量塞进去模型会晕，切太碎又丢连贯性。Multi-Agent说到底是一种上下文治理策略，不是在堆数量。

标尺四：博弈对抗论（施燚，DeiNai）

施燚的场景最像人——红人营销。他的Agent要找网红，谈价格、谈合同、谈排期。对面是真人网红，有情绪、有偏好、有谈判策略。

这个说法挺有意思。一个Agent同时扮演"商家代表"和"理解网红心理"会打架。商家要压价，网红要涨价，这是零和博弈。不如拆成两个，一个代表商家据理力争，一个理解网红诉求寻找双赢，让它们吵出结果。

这跟李粒说的企业架构对上了。有博弈的地方，Multi-Agent才真的在干活。

我的理解是这样：业务走直线的，先把单Agent做扎实。真有角色冲突、能力分级差太多、上下文要隔离、或者存在博弈对抗的，再上Multi-Agent。

单Agent想换个模型？简单。跑一遍Benchmark，指标不降就上线。

Multi-Agent系统里，这个问题瞬间变成噩梦。五个Agent，三个模型，谁换谁不换？A升级了B崩了，联动效应像多米诺骨牌。李粒说他们在TiDB服务头部客户的时候，模型路由是最让人头大的工程问题，"没有标准答案，全是权衡"。

但头疼归头疼，实战派总有办法。我整理了四个招数。

策略一：把回归测试集当成核心资产

李粒的做法很工程师。任务先分级——查个天气、写个邮件，便宜模型随便搞定；关键推理、客户-facing的任务，上最顶的闭源模型。钱要花在刀刃上，但刀怎么磨，得有标准。

他们最宝贵的资产不是模型，是内部积累的回归测试集。新模型出来，先跑测试集，过了才能上生产。听起来像是基础操作？做到了的团队没几个。大部分公司换个模型靠感觉，"嗯，GPT-4o好像比GPT-4快一点"，然后就上了。

更狠的一招是主动搞乱。同一个目标Fork多个Workspace，不同模型并行跑，做消融实验。哪个路径好，再深度优化。不确定的事情，让它并行发生就好了。

策略二：三个E的硬约束

陆剑锋抛了一个简洁的框架——Effectiveness、Efficiency、Economics。三个E，你最多同时满足两个。

语音场景里，时延是生死线。超过2秒客户就挂电话了，管你回答得多好。所以WIZ.AI选模型，先看延迟，再看成本，末了才是效果天花板。智谱的模型性价比很高，日常任务用它。但高难度任务，比如多轮情绪安抚，还得请更贵的出山。

每个业务都有自己的硬约束。语音是时延，金融是准确率，广告是成本。路由策略不是抄别人的，是先认清楚自己赌不起什么。

策略三：让用户投票

徐安邦的路线更接地气。Loova AI的系统里常年跑着两种模型——性价比最高的做默认，效果最好的做备选。用户可以自己切，相当于用脚投票。

但这只是表层。真正的飞轮在用户数据上。哪些视频被用起来了、哪些投放ROI高、哪些素材在社交媒体上爆了——这些数据回到模型做Post-training，路由越跑越聪明。他们还专门有人监控视频的实际使用情况，不是看系统日志，是看客户到底有没有把生成的素材发朋友圈。

数据回流这件事，表面看是技术架构，实际考验的是组织习惯。能做到这一层的团队，模型路由才会自己进化。

策略四：实在不行，自己训一个

施燚的解法最反常识。通用大模型做不好网红谈判决策？那就不用它做决策。

DeiNai把四五年的运营数据、网红沟通记录、成交历史全掏出来，训练了一个垂直私有模型。谈判策略、价格锚点、网红心理画像，这些核心决策由私有模型负责。GPT-4、Claude这些通用模型只干外围——润色文案、生成邮件、整理笔记。

行业Know-how成了护城河，通用模型变成了高级秘书。这个分工挺妙的——越靠近业务核心，越要用私有模型；越靠近通用能力，越可以用大厂的。

四条策略说完，我有一个感受：模型路由没有银弹。有人用测试集把关，有人用硬约束卡死，有人让用户投票，有人干脆自己造模型。区别不在谁更聪明，在于谁更清楚自己业务的约束条件是什么。

聊记忆之前，我想先戳破一个幻觉。

很多人觉得Agent的Memory就是"把对话历史存下来，下次接着聊"。要是真这么简单，陈亦凡也不用专门做EverMind了。实战者的共识很清晰——记忆不是通用的存储，是跟业务死死绑在一起的分层架构。

这场对话关于记忆的部分，信息量最大。五个角度，拼出了一张完整的图景。

记忆必须分层——通用聊天和工作协同是两码事

李粒先给了一个基础框架：你的Agent是陪你闲聊的，还是帮你干活的？这两种记忆完全不同。

闲聊Agent，记住用户喜欢什么风格、什么话题就够了。工作Agent呢？得按Project区分记忆，还要支持组织层级式的共享。头部客户提了一个很狠的需求——记忆要能像组织架构一样一层层传递。底层员工跟客户沟通的细节，要能沉淀成中层管理的决策依据；中层的判断，又要能辅助高层拍板。

这背后是巨大的工程挑战。TiDB做了大量多租户隔离的工作，"10万用户以上，隐私事故是灾难区，一个数据串台就是新闻头条"。

过期的记忆怎么办？

陆剑锋的场景特别具体。企业促销政策3月发布的，4月过期了。但客户6月找回来问："你们3月那个Deal还能不能给？"

如果系统只保留最新政策，客服Agent会说"没有这个活动"，客户炸了。

WIZ.AI的做法是冷热分离。当前有效的促销政策放在系统里，热数据，实时查。过期的政策进冷存储，客户要追溯的时候，用MCP工具去捞。时效性数据和历史追溯能力，一个都不能少。

"妈生感"——好记忆让人以为是天生的

陈亦凡这个词把我逗乐了，但细想特别准。

他说记忆必须有"妈生感"——私人、有人性，你说一句对方就心领神会。不是那种机械的"您上次查询了XX"，而是"我知道你偏好什么、我预见你可能会要什么"。

怎么做到？Preference偏好分层加Forecast预见功能。Agent不光记你说过什么，还要推你接下来可能需要什么。从被动应答到主动服务，差别全在记忆。

更猛的是"Dreaming"——系统offline的时候，Agent复盘白天所有的执行记录，隐式自我进化。白天跟人谈判犯了什么错、哪个网红的价格谈高了、哪条视频爆了——晚上Agent"睡觉"的时候消化这些信息，第二天醒来更聪明。

LlamaIndex的创始人Jerry Liu说过一句话，陈亦凡特别认同："别再盯着Prompt看了，要搞Loop Engineering。"Prompt调来调去确实是雕虫小技，记忆和反馈循环才是正事。

别跟客户说Memory，说"用户资产"

徐安邦的商业嗅觉很敏锐。跟客户聊的时候，他不说"Memory系统"，说"属于你企业专属的用户资产"。

三层资产——品牌个性化数据、投放效果数据回流、用户Workflow。Memory成了资产，买单的人就从技术团队变成了CEO。

审计Agent：用越久越聪明

施燚的做法最务实。AI跟网红沟通的所有内容——聊天、谈价、图片、视频——全部存下来。但不是存原始记录，而是由一个审计Agent负责切冗余，只保留核心结构化内容。

这个审计Agent本身也是Multi-Agent系统的一环。它越跑越知道什么该留、什么该扔，整个系统的记忆质量随时间上升。

做记忆系统之前先问自己三个问题：存什么、怎么存、谁可以访问。存什么是业务问题，怎么存是工程问题，谁可以访问是安全和隐私问题。三个都想清楚了，记忆才会成为Agent的护城河，而不是拖后腿的技术债。

陈亦凡有句话我印象很深——记忆决定了Agent表现出来的喜好和偏见。你存了什么、怎么组织的，最终都会反映在Agent的行为里。这跟养孩子有点像，你给他什么样的成长环境，他就长成什么样的人。

快结束的时候，主持人换了个轻松的话题——今年最期待的技术突破是什么？

五个人给了五个答案。拼在一起，恰好是一幅完整的层次图。

最底层是陆剑锋说的Reliability。做过企业级语音客服的人，对"不可靠"三个字有生理反应。"对话质量、输出结果、版本迭代后还能一如既往地可靠，这是命根子。"地基不牢，上面盖什么都没用。

往上是李粒的Stability。从Demo到Production-ready，中间隔着一个太平洋。隐私隔离、扩展性、多租户不串台，"头部客户选TiDB，核心指标就是这个"。可靠性是一个点的表现，稳定性是整个系统的底气。

再往上是陈亦凡的Memory自由。这个词有画面感。跨Session的记忆连贯、跨Agent的身份一致、数据真正属于用户而不是锁在某个平台的黑匣子里。"我想让Agent有'妈生感'，它生来就是你的，你带它去哪里它都认识你。"

比记忆更进一步的，是徐安邦期待的Self-evolve。视频生成的Pipeline太长，人工调优总有一天会摸到天花板。"真正的突破是建立自进化的Loop。用户数据回来，系统自动迭代，越跑越聪明。"这跟陈亦凡提到的Dreaming遥相呼应，Agent不再只是被调教的工具，而是能自己长本事。

最顶层是施燚的Context Management加Workflow编排。垂直行业落地，算法已经不是最大瓶颈，工程化才是。"怎么用工具链把Context管好、把Workflow串顺，决定了一个Multi-Agent系统是Demo还是正经生意。"

五个答案，五层意思。可靠性是地基，稳定性是承重墙，Memory自由是住进去的感受，自进化是房子自己修自己的能力，Context加Workflow编排是让这一切在真实世界里跑起来的施工图。

缺任何一层，Multi-Agent都只能是实验室里好看的模型。

最后扯点大的。

Multi-Agent不是一个技术架构问题。或者说，它不首先是技术问题。

你在搭建的东西，比一个更复杂的AI系统复杂得多——你在搭一个微型公司。这家公司有不同的部门，有不同的KPI，有冲突也有协同。PM想让产品做完善，程序员想尽快交付，QA想拦住你不让上线。三个角色，三个目标，互相argue，最终吵出一个结果。

这才是Multi-Agent真正在做的事。

活动现场有人问：Multi-Agent是不是hype？值不值得all in？

这个问题本身就问错了。不是非此即彼。

你真正需要想的是：你的业务里，有没有需要多个角色博弈协作的场景？有没有角色冲突？有没有能力分级？有没有上下文需要隔离？有没有零和博弈需要对抗？

有的话，Multi-Agent已经不是选择题，是必答题。

核心不是AI够不够聪明，是你的业务够不够复杂。

回去看看你手头的东西——如果它只是走一条直线，一个聪明员工就能搞定，那别急着上Multi-Agent。但如果你的业务里已经有几个部门在互相扯皮、互相argue、互相博弈，那恭喜你，你的Multi-Agent架构图，可能已经画在你的组织架构图里了。

主持人：如果大家想加我的联系方式，用 X（原 Twitter）是最快的，我在 X 上经常发一些跟支付、大模型、Graph Model（图模型）相关的事情。

今天因为我们是上市公司，没法分享太多内部信息，所以我特别喜欢作为主持人。今天这个话题我觉得会比较硬核一点，关于 Multi-Agent。因为我们不再去讲智能体作为一个宏观的概念，而是切入到一些细节。包括我自己，其实并不是一个非常坚定的 Multi-Agent 的信仰者。因为作为模型厂商，你的单智能体模型（Single-Agent Model）需要非常聪明才行。所以今天其实也是跟大家共同来探讨一下。

首先请各位嘉宾简单介绍一下自己的公司，还有自己的工作内容。

李粒：大家好，我叫李粒，来自于 TiDB：。TiDB 的话可能很多人都知道，我们是很早就开始做海圈（出海/海外）生意了。大家可能更多知道的是我们为大公司提供数据库服务，但事实上，大家可能不知道的是，我们已经开始为全球最好的 AI 产品或模型提供基础软件服务了。

包括新加坡最大的 AI 厂商，以及最近不太出来活动的、包括我衣服上印着的 OpenClaw（此处修正错别字），其实都是我们的客户。所以我们现在会为所有的 Agent 机制、人工智能资产提供非常多的基础设施支撑，包括数据库、Vector Services 等等。大家如果后面有什么兴趣，也可以来跟我沟通。

陆剑锋：大家好，我叫陆剑锋，是 WIZ.AI 的创始人兼 CEO。WIZ.AI 主要在东南亚、拉美等国家为大企业提供客服以及客户联络的 AI 技术支持。比如在马来西亚，我们会提供马来语、中文、英语混合且可以自由切换的语音对话系统。

还有一个很重要的是，我们主要支持在电话系统上面的语言对话，所以需要处理很多低质量音频的信息。刚才子玄说了他不倾向支持 Multi-Agent，但我倒觉得反过来应该说，支持 Multi-Agent 可能会更好，而且大家的机会会更多。谢谢。

陈亦凡：大家好，我是艾略特（陈亦凡），来自盛大 EverMind。我们做长期的 Agent 研究，我也活跃在 X（Twitter）上面，大家如果经常上中文圈的话应该会刷到我。

我们第一是做 Agent Memory 的 Infra（基础设施），做可持续、可进化的 Agent 记忆；接下来，我们还有非常酷炫的 C端产品推出。其实现在已经推出了一款叫作 Everme，一件可以集成的产品。接下来还有一个彩蛋——我们会推出自己的、可自进化的 Agent。名字我先留一个悬念，大家可以线下来那边的桌板找我，给大家看一些有意思的东西。

回应前面两位老师刚刚说的 Multi-Agent。怎么用好 Multi-Agent 呢？记忆这一环就非常非常关键，我们刚好就是做这一环的。

徐安邦：大家好，我叫 Benson（徐安邦），我是 Loova AI 的创始人。我们在做的其实是一个 Video Agent（视频智能体），因为我们主要的 Focus 是在营销视频还有一些剧情视频这两个场景。

我们看到今年视频模型以及 Agent 发展确实非常快，所以我们觉得整个 Agent 会重塑之前视频的整个生产链路，这也是为什么我们在做一个新的 Video Agent 的入口，这是我们正在做的。我们主要面向的是欧美市场。

顺便回应一下 Multi-Agent 这件事。我们在很多场景下是不会去用 Multi-Agent 的，但是在某些 Context（上下文）没办法比较好地传递给特定角色的 Agent 时，我们就会去用它。所以它并不是说所有场景都需要 Multi-Agent，但在某些需要更多、更具体 Context 的场景下，我们会需要用到，具体的我们后面可以再展开。

施燚：大家好，我是 DeiNai 的创始人兼 CEO 施燚。我们是一家做 Creator Marketing AI Agent（红人营销AI智能体）的公司。我们的产品可以输入你的需求，通过全球 3.5 亿的网红（如 YouTube、TikTok），帮你去 Discover（挖掘）并 Reach 到他们。

找到之后，我们能够看到每个网红的数据，并判定要不要跟他合作。比如你是做硬件的，或者做 AI Agent 的，你要做出海、做 Marketing，如果你想跟某个网红合作，点击发起这个项目，就会由我们的 AI 去帮他做谈判。从第一封邮件或 WhatsApp 沟通，到后面的所有底层细节，我们的 AI 会去做 80% 的工作，然后人工去做确认。就像你们用 Copilot 一样，写一段 Prompt，然后确定是不是要这么去做。所以我们主要解决的就是效率问题，让你以前需要 10 个运营，现在可能只要 2 个人就能去做。

同步来讲，我们现在也在 OpenClaw（原转写错误）等平台和 Code 里面上传了我们 DeiNai 的 Creator Skills，你们可以去下载使用，无线集成到你们的 Facebook、Slack 里面去。大概是这样一个产品。

主持人：刚才 Benson 说可以展开一下。为了防止忘了，我就地展开。我想问一下所有的嘉宾：对你们来说，怎么去判断一个系统什么时候需要用多智能体（Multi-Agent）？因为其实除了多智能体之外，我们还有 Skills，还有环境，你们怎么去判断这个事情？

李粒：我们是技术软件厂商，所以我们看到过非常多最 Top 的 AI 公司、模型公司、Agent 公司，也看到过最 Top 的垂直行业公司。看完并跟大家讨论完之后，我们发现一个本质：构建一个 Agent 系统，本质上就像在构建一家企业。

什么时候需要 Multi-Agent？其实是当你的任务（Task）需要分不同的 Role（角色）、不同 Goal（目标）的角色去 Argue（辩论、博弈）的时候，你这个时候可能需要 Multi-Agent。因为这些 Agent 是需要带着不同的目的，它的目的甚至可能是冲突的去做出决策。

拿最简单的软件开发来举例子，因为这里大部分是技术人员。PM（产品经理）角色的 PRD/Spec 任务，是尽可能地把这个事情想得完善；而真正负责 Coding 的角色，想的是怎么尽快把这个东西做完，满足用户交付；做 QA/Test 的这个角色，其实是要去拦截它，不能让它随便上线。每一个角色的目的是冲突的，这种情况下就不适合由一个 Agent 单独做，就需要 Multi-Agent 架构。其实在其他垂直行业也有这种冲突博弈的情况。

陆剑锋：我们这边的应用场景很明确。比如如果我要做电话营销，那首先第一个，电话里必须得有比较甜美的女生声音，这样比较容易达成营销的转换。但如果我是帮一些信用卡公司去催账单，这时候声音就需要比较严厉一点。从 Persona（角色定位）的角度来讲，我需要不同的 Agent 来完成这样不同的任务。

第二点刚才 TiDB 的兄弟也提到了，就是从能力和算力的角度来看。有些任务我们需要非常高的推理能力和高智能，但在另一些任务上，其实只需要一些非常 Routine（常规）、简单的处理。这样的话在过程中，它们需要的 Context（上下文）不一样，第二点是在于对它的评判标准也不同。

我们给很多银行或者 Telco（电信运营商）提供服务，他们对对话的质量要求非常高。每家公司、每个角色的评价标准可能都不一样，所以基于这一些，我需要把它分布成不同的 Agent，这样总体的效果才能达到最好。比如最简单的银行 IVR 系统（互动式语音应答），按1按2，有些需要去帮忙做任务规划，有些只需要做简单的 FAQ，还有一些可能只是对接后台系统查询一些数据。所以在这样一个 AI 系统中间，我可能就需要 Deploy 三个不同的 Agent 来完成相关的任务。

陈亦凡：这个问题在我看来，结合我个人的理解和实践，基本上可以从三个角度去看：

第一是“角色化”：假设我拿到一个复杂的任务，我能不能把它拆开，让不同的角色去办这个事？比如探索 Agent 去探索，测试 Agent 去测试，分析 Agent 去分析，最后有一个 Agent 来验证。

第二是“持续性”：假设我其中一个 Agent 突然出于某些原因跑不完这个任务，那会不会有另一个 Agent 来帮我代替完成？正常情况下可以把这个任务 Pass 给 Agent B，这就是持续性。

第三是“验证与复盘”：我怎么样能验证我的输出结果？最终是通过一个什么样的方式验证成功，并且我下次怎么去复盘把它做得更好？

其实在我看来，现在大部分人在使用所谓 Multi-Agent 的时候，还达不到真正的多智能体自协同，而是一种 “Multi-Agent Usage（多智能体使用）”的状态。也就是在 OpenClaw（原转写错误）或者 Code 里面建好几个 Projects，在每个 Project 里面去手动地切换 Agent，或者自己用一个 Browser Agent 帮我跑一些轻度 Task。真正意义上能实现 Multi-Agent 并且很丝滑、可以互补自进化，今年可能才有机会。就像前两天 LlamaIndex 的创始人（此处修正 Peter Stinberg 语误背景）自己说的：不要再单单盯着 Prompt 看了，现在要提供一种叫作Loop Engineering（环路工程） 的东西。而想把这个东西做好，知识库还有记忆这些东西是必不可少的。

徐安邦：前面几位嘉宾把概念和角色划分讲得非常清楚了。我可以分享几点我们在实践过程当中的核心判断标尺：我们到底是用简单的工具调用（Tool Calling），还是把它做成一个 Agent？

第一点就是Context（上下文）的管理判断。我们到底是把整个 Agent 的上下文都输入给 Tool，它就可以完成任务，还是说我把它浓缩成一些特定子 Agent 的 Context 会更好？简单来说，就拿我们做视频的创意脚本来举例子。创意脚本这个环节，我到底是把整段上下文都扔进去执行得更好，还是只把和创意脚本相关的结构化 Context 喂给它能执行得更好？如果我们发现只需要给到它创意脚本的 Structure Context，我们就会把它变成一个单独的 Sub-Agent。

第二点是任务是否在持续运作。比方说我后台一直有一个监控，监控投放出去的素材 ROI 怎么样，当我需要一个持续监控的 Agent 时，我就需要做个单独的 Sub-Agent。

第三个场景就是Agent 与 Agent 之间有协同与回溯。比方说我们有时候会用创意脚本 Agent 去写出不同的分镜，但这个分镜给到一些视频模型、图片模型的时候，它可能生成不了，或者生成的效果不好。它需要反过来再跟脚本 Agent 去对话、去重新生成。有这种双向协同和 Loop 的时候，我们其实也会把这个事情变成一个单独的 Agent。否则你如果只是一个单纯的 Tool Calling，其实你是做不了这样的协同的。

施燚：现行的简单的任务，单个 Agent 是完全可以的。那复杂的、可能需要去对抗和博弈的，就需要多个 Agent。以我们的 Creator Marketing AI Agent 为例，在我们的系统里面，我们的 AI Agent 它既要去跟网红沟通、去模拟网红的心理去谈判，又要代表商家的利益去博弈、去谈价格，去说我们要怎么签合同、这个价格不 OK。其实这个时候我们就用到了多个 Agent 去做博弈和对抗。所以总的来讲，复杂的、多任务的、包括高并发的任务，我们觉得更适合用多 Agent 架构。

主持人：然后我们再聊一下后面的一个话题：模型路由（Model Routing）。对于多智能体来说，我最关注的一个点就是当底层大模型升级换代的时候（比如从 4.7 到 4.8 ），它会发一堆 Benchmark 榜单，但这些榜单可能跟大公司的真实生产环境没有任何关系。如果你是 Single Agent，其实比较简单，把自己的 Benchmark 全跑一遍就知道影响了。但是多 Agent 系统里，谁换模型、谁不换模型，其实是一个非常复杂的事情。你们怎么去处理这种事情？

李粒：我们在开发 Agent 的时候确实遇到了这样的问题，这也是很痛苦的。我们公司内部做开发和业务处理也是用多模型，而不是单一模型。我们其实会从两个视角来看多模型路由：

第一，任务分级约束。我们会对模型处理的所有任务进行分级，什么级别的模型处理什么样的任务。比较简单的任务，我们可以用比较低级、低成本的模型来做；如果是非常复杂的、Critical（关键性）的任务，我们可能就会上最顶级的闭源大模型。

第二，标准约束与资产化测试集。我们对外提供 AI 产品的时候，跟客户约定的产出标准，不能因为我们后端模型的变更而导致劣化。所以我们会设立关键的 Checkpoint 规范来约束模型的输出。当同样的模型进行升级切换的时候，不可避免要测试。所有认真做 Agent 的公司，内部一定都有海量的测试集，这个回归测试集是我们公司最宝贵的资产之一。只有新模型在回归测试中大量通过了，我们才会把这个模型上线切换过去。

除了约束的部分，第二部分是主动拥抱路由的不确定性。举个例子，我们在做一些探索性任务时，会进行广度优先的探索。我们会把同一个 Workspace 衍生（Fork）很多遍，进入同一个目标，但是用不同的 Model，甚至用同一个 Model 但微调一下 Prompt 去直接跑。在这种情况下，我们其实在主动利用路由的不确定性，在不确定性里面找到更好的路径，做一个消融实验，然后再做深度优化。这种做法在我们内部是一个非常有效的行为。

陆剑锋：我们在做模型路由的过程中，主要考虑三个核心维度：

Effectiveness（有效性）：这个模型是不是能够帮我把这件事给做好。如果做的质量不够好，那肯定不能用这个模型。

Efficiency（效率/时延）：这对于我们处理电话语音对话至关重要。前面客户讲完一句话，我必须在一秒到两秒之内（最长不能超过两秒）做出响应并回答对方。如果这个时间模型搞不定，那客户就把电话挂了，所以 Efficiency 对我们来讲非常重要。

Economics（经济性/成本）：各个不同模型的底层价格差别很大。比如像智谱（Zhipu）的一些模型，性价比就非常的高，但在有一些特定的高难任务中间，我有可能需要用别的。所以我们对模型路由的选择，基本上就是在这三个要素之间做平衡。

陈亦凡：我们是做记忆的，跟路由问题没有最直接的物理关系，但我们的底层可以很好地解决这个问题。很多人在很多场景下决定用 RAG（检索增强生成），其实很多时候可以用“记忆”来替代。我们的记忆 Infra 里面刚好有一个 Knowledge Wiki 的功能，有了这个东西的存在之后，所谓不同模型的不同能力体现，在用了我们召回 Wiki 的情况下，会得到非常强烈的改善。

这有点像去年的“百模大战”，大家在看哪个模型做某些事有不一样的好处。但在垂直类 Agent 里面，并不会证明在法律层面或者医疗层面最新的模型就是最好的。因为模型里面讲究相似性跟相关性，如果这个时候采用一些机制把它强烈地去打标、更准确地召回，就可以解决大模型本身能力变动带来的路由问题。

徐安邦：模型路由和多模态选择上，我们的产品是比较有发言权的，因为我们会涉及视频、图片和大语言模型。我们在选择和控制模型时，一个最核心的点是团队内部会先做严密的评测。第二点是，我们会通过用户的使用过程以及反馈数据来进行Post-training（后续训练优化），这两点其实是必要的。

通过测试让这些模型达到可用标准后，最后往往会留存两种类型的模型：一种是性价比最高的模型，还有一种是效果最好的模型。系统往往会有一个默认选项，默认可能是性价比最高的，但我们也把效果最好的选项留给用户去切换。

因为我们的应用场景还比较多，比方说有 TT 广告的、Paid Marketing、数字人，或者是一些剧情类视频、教育类视频，我们自己会尽可能地去跑回归测试，但你也不可能穷尽全部场景。所以用户的数据闭环对我们来说就非常重要。我们其实有一个团队专门去监控这些视频最后到底有没有被用户真正用起来、有没有被投放覆盖到社交媒体上。这种用户数据闭环反馈回来的 Post-training，对我们优化模型自动切换路由非常有用。

施燚：我来回答关于垂直领域不确定性控制的问题。在网红营销这个垂直领域，让我们的 AI 去跟 Influencer 做博弈跟谈判，底层的通用大模型肯定是没有办法直接帮我做好谈判决策的。

本质上，我们是把过去四五年我们自己的运营同学跟网红沟通的邮件、WhatsApp 等所有核心信息做了大量的垂直训练，搞了一个在这个行业里最懂行的小模型（Small Specialized Model）。所以基本上在做具体的业务谈判和决策时，都是由我们的私有小模型去做判断；通用大模型反而是在外围做一些推理或通用文本润色。所以说对于我们来讲，控制不确定性的核心是把属于自己行业的私有小模型给做好。

主持人：下面一个问题，如果你们的工作和多智能体中比较侧重于记忆（Memory）的话，可以分享一下怎么去搭建这个系统？

李粒：刚才介绍了，TiDB 其实是在提供整个 Agent 的 Infra，关于记忆的话我们有一套完整的 Solution（解决方案），前段时间在 OpenAI 的发布活动上也有用户用我们的数据库来做记忆解决方案。在我们和所有用户观察之后，我们发现 Agent 的记忆存储有很大的业务区间区别：

有的是工作类 Agent，有些产品是通用类/泛娱乐 Agent（General/Generative Agent）。这两者想要存储的记忆是完全不一样的。General Agent 它可能更多地想记录你的个人 Personal Profile，以及从中延伸出来的 Workspace Profile 等。而工作类的 Agent，它其实更纯粹地想记录你工作相关的事情，并且它可能要区分不同的 Project，甚至要考虑在不同 Project 之间的记忆共享（Memory Sharing）。我们有非常多的生产级用户，直接要求记忆支持共享，并且这些知识和记忆要能跟组织的架构层级一样，一层一层被传递下去，因为他们认为底层员工沉淀的知识对上层决策也是有用的。所以，记忆不是一个 General 丢进去存储的东西，一定要根据自己的业务情况进行分层。

第二是记忆怎么抽取，谁来抽取。特别是针对想要做自进化的 Agent 平台，每一个 Agent 绑定了前面的一个 User。这个 User 会有自己的工作偏好倾向或个人爱好。这些信息最适合被 Agent 自己记下来。我们在和头部 Agent 厂商合作的时候，他们倾向于把整个记忆流放到Agent Loop 里面，让 Agent 自己去做记忆的抽取和采回，并且在 Action 阶段再把有用的记忆拉回来。

而对于更多垂直类的 AI 产品，你们还要考虑的是记忆的安全隔离（Privacy Isolation）。当你的用户到了 10万、20万甚至上百万级时，如果多租户的隔离做不好，很容易成为灾难性的隐私事故。我们在多租户记忆隔离的安全方面花了非常多的工作。记忆决定了你 Agent 表现出来的喜好和偏见，做记忆系统时一定要想清楚自己要存什么，跟业务高度相关的记忆系统才是好系统。

陆剑锋：我们的系统中也有蛮多跟记忆相关的，比如企业的业务流程、政策知识库（Knowledge Base）等。但在做 Agent 系统的过程中，我们发现一个难点是记忆的刷新与可追溯性。

举个很简单的场景：3月份我们企业的促销政策是这样的情况，到了4月份，3月份的很多 Policy 已经过期了。但是呢，有些客户他可能还会回过头来追溯，问 3 月份的那个 Deal 怎么样。所以在整个过程当中，我们除了把时效性数据做在系统中间，有些过期或冷数据就要用MCP（Model Context Protocol，此处修正原文字幕误读） 的一些工具调用，再把过去的这些历史信息给追溯出来。这里面有蛮多细节处理，我们也十分期待市场上诸如 EverMind 等在记忆研究这块的成果。

陈亦凡：这确实算入我们的舒适区了，因为我们一直专注于做记忆。我们自发布以来，跑分基准一直非常高。记忆这个事情在我看来经历了几个发展阶段：第一阶段大家在比拼怎么帮系统有效去解决召回问题，从而帮用户省下很多 Token，非常直接。

到了今年，特别是像Hermes Agent 这类可自进化（Self-evolving）的 Agent 起来之后，玩法完全不一样了。我们也对我们的 Agent 做自进化，只有当 Agent 可以自进化了，它才真正算是一个有生命力的 AI Assistant。

在我们的记忆系统里，有非常关键的两点：

记忆必须是“私人且有人性”的，我们称之为“妈生感”。什么叫妈生感？就是当我说一句话，对方马上就能心领神会知道我是什么意思。所以我们的记忆系统会对用户的过往进行一个Preference（偏好分区分层），然后它会有一个叫作Forecast 的功能去预见你将来的倾向，让你的私人类 Agent 变得更加 Proactive（主动化）和私人化。

企业级的 Knowledge Wiki 与 Reflection 机制。Wiki 功能可以非常有效地把知识沉淀出来，在一定程度上取代传统的 RAG。同时，我们还有一个王炸功能叫作Dreaming（反思/复盘机制，即 Reflection）。现在很火的终端大模型都在提这个。它的意思是在 Offline（线下）状态下，Agent 可以利用这个功能对白天或者上一阶段的执行进行复盘、总结、进而提升自己，实现隐式的自我进化。

徐安邦：前面几位讲得很好，记忆确实要跟业务高度相关。分享一下我们在做视频方面的 Context 和 Memory 存储实践。我们其实分为三层资产：

第一层是品牌和产品的个性化数据：包含我们客户品牌的调性、产品的特点等一系列 Enterprise 自定义且非常个性化的资产。

第二层是投放素材与投放效果的数据闭环：这些素材投出去之后的 CAC（客户获取成本）、Click（点击率）等底层数据，我们全都会存下来。这在后面会形成用户自己的 Agent Loop，去自动更新和指导素材的生成。

第三层是用户自己的 Workflow（工作流）：我们会把用户习惯的工作流保存下来，通过 Self-involve 生成他自己独特的一个 Skill（技能），让用户可以重复调用。

虽然技术上大家管这个叫 Memory，但我们跟客户沟通的时候往往不讲 Memory，我们跟他们讲：这是属于你企业专属的“用户资产”。

施燚：说一下我们在 Creator Marketing 领域的记忆落地。AI 去跟网红沟通有一个起点：我们需要品牌方或者用户，首先把你的网站或者你公司的一些基础材料传给我们。我们的智能体去进行意图识别，理解你是谁，我们才能开始第一轮的沟通。

在接下来的整个 Workflow 里面，AI 去跟网红会沟通很多内容：聊天、谈价，甚至达成合作后会存一些图片、视频素材。我们针对在整个工作流里产生的图片、视频、聊天记录，都会做综合的存储，作为品牌的资产。

在这个存储过程中，我们引入了另一个叫审计 Agent（Auditing Agent） 的机制。它会把来回沟通中一些不必要、没有价值的冗余内容切割掉，只保留最核心、有价值的结构化内容存在我们的记忆库里。随着用户用得越多，它的 Agent 就会越用越聪明，这是我们在记忆这块的实践。

主持人：感谢大家，因为时间快到了，最后请每位嘉宾用一个词或者一句话，来展望一下今年你们最期待的、或者认为最需要被突破的 Multi-Agent 技术是什么？

陆剑锋：我觉得最重要的一点是“可靠性（Reliability）”。尤其是企业级应用，多智能体的企业级应用必须得绝对可靠。无论是回答的对话质量、输出的结果，还是说在后面版本迭代的过程中，后台工具变了、模型换了，迭代完了之后系统是不是还能一如既往地可靠。所以今年我最期待的突破就是可靠性。

李粒：因为我们是做基础设施的，其实选择我们 TiDB 的包括各类头部的 Agent 框架、模型厂商和硬件厂商。他们选择我们最核心的指标就是“稳定性（Stability）”。如何解决智能体从 Demo 阶段走向生产级别（Production-ready）的这种复杂度处理？如何做好隐私隔离？如何做好扩展性（Scalability）？如果你要做一个严谨的生产级 Agent，稳定性一定是最重要的。

陈亦凡：我这边的词是“实现 Memory 自由”。无论您用的是什么 Agent，什么 LLM，我们希望能够做到跨 Session、跨 Agent 的记忆连贯，让这个 Agent 总是属于你，拥有真正的“妈生感”。

徐安邦：我们最希望的能够真的帮客户直接 Deliver（交付）最终可用的 Final Video。这里面其实包含两个关键词，一个是刚刚讲的稳定性，另一个就是“Self-evolve（自进化环路）”。营销视频跟时效性关系很大，所以它基于用户数据把 Loop（环路）搭起来、不断迭代自进化的能力特别重要。

施燚：我们基于垂直出海行业的工程实践，我认为有两点结合特别重要：第一是“上下文的管理（Context Management）”，第二是“工作流（Workflow）的编排”。把这两点做好，我们才能够真正针对某一个垂直行业，把它应用到真实的工作生产中去。