截至 11 月 5 日的公开信息，豆包工作首次接入第三方模型，首批上线 Kimi、智谱与 DeepSeek；管理员可以按成员、部门、场景细化调用权限；多模型配置可帮助企业优化 Token 成本，实现在性能与成本之间的平衡腾讯新闻：AI 日报 豆包工作首次接入第三方模型。对企业用户来说这是一次成本与能力的组合优化，对做 AI 搜索可见度的团队来说，它意味着同一个问题在同一个入口里可能得到几套不同的答案。
一个入口里跑四个模型，答案就不止一套
过去做 AI 搜索可见度，默认的前提是"一个平台等于一个模型"。豆包工作接入 Kimi、智谱与 DeepSeek 之后，这个前提不再成立：同一个入口背后可能是四套知识结构、四套检索偏好、四套表达习惯。品牌在 AI 回答里被提到的概率，从此不只是一个数字，而是按模型分裂成几个数字。
模型不同，引用来源也不同
不同模型在检索与生成上的偏好差异很明显：有的更依赖实时检索结果，会直接给出引用来源；有的更依赖训练语料，倾向于用概括性描述回答，不标注出处。这意味着同一个品牌，在检索型模型里可能表现为"被引用"，在生成型模型里只表现为"被提到"。把两者混在一个可见度指标里统计，等于把两种完全不同的曝光方式加在一起。
权限分级把可见度切成碎片
管理员可以按成员、部门、场景细化调用权限，这条设计对企业客户是成本控制手段，对品牌监测却是一个新变量。同一个企业里，市场部可能被配置为使用模型 A，研发部使用模型 B，客服场景固定使用模型 C。品牌想影响这个客户的认知，就必须知道对方实际在用的是哪一个。
部门级配置会放大差异
企业采购决策往往由多个部门共同参与，而各部门使用的模型不同，看到的产品描述也不同。如果品牌在模型 A 里的描述准确、在模型 B 里存在事实错误，那么同一个客户内部就可能出现两套认知。这类分歧不会出现在任何公开数据里，只能通过按场景拆分的问题库去还原。
| 变化 | 对企业的意义 | 对品牌监测的意义 |
|---|---|---|
| 一个入口接入四个模型 | 能力互补、成本可调 | 可见度指标必须按模型拆分 |
| 按成员/部门/场景配权限 | 控制调用成本与合规风险 | 品牌曝光分散在不同模型里 |
| 多模型优化 Token 成本 | 降低单位调用成本 | 低成本的模型可能覆盖更多日常提问 |
| 答案归属不透明 | 使用体验统一 | 难以直接归因到具体模型 |
这张表最后一行是关键约束。企业用户看到的是一个统一的对话框，不会关心背后调用的是哪个模型，但监测方必须知道。在缺少答案归属标识的情况下，比较可行的做法是用同一批问题在四个模型的独立入口各跑一遍，先建立模型间的基线差异，再回过头推断混合入口里的答案来自哪一套。
多模型环境下，监测该怎么搭
原来的做法是"选几个平台、固定一批问题、按月跑"。多模型之后，平台与模型不再一一对应，监测结构要改成三层：平台层、模型层、场景层。平台层回答"用户在哪个入口提问"，模型层回答"答案由谁生成"，场景层回答"提问发生在什么任务里"。
执行时要把"模型"当成一个独立维度固定下来，而不是当成平台的一个属性。模型版本会升级，路由规则会调整，如果不把模型单独记录，某个月可见度突然变化时，就无法判断是内容出了问题还是模型换了。这份记录同时也是与内部沟通的依据：当业务方问"为什么这个月 AI 里看不到我们"，能直接指出是哪个模型、哪类问题上的缺口。
常见问题
豆包工作接入多个模型后，品牌的 AI 可见度会变高还是变低？
取决于原本在哪个模型里表现好。接入更多模型意味着分母变大，原本只在单一模型里占位的品牌，整体可见度会被稀释。
为什么要把模型单独作为一个监测维度？
因为不同模型的检索偏好与引用习惯不同。混在一起统计会让指标失去解释力，出问题时也无法定位是内容还是模型变了。
企业客户按部门配了不同模型，品牌该怎么应对？
按部门对应的使用场景拆分问题库，分别核对品牌描述是否准确，避免同一客户内部出现两套互相矛盾的产品认知。
答案不标注来源模型，还能做归因吗？
可以间接做。先在四个模型的独立入口建立基线差异，再用混合入口的答案特征去比对，能推断出大致归属。
