为什么专用 AI 可能胜过全能模型?

OpenRouter 与 Replit 的一场对谈:通用模型负责探索,专用模型接手重复任务,企业用自己的数据、评测和权限把它们组合起来。

作者:a16z10-04 · 20 分钟
🎧 听播客版0:00 / --:--
0:00 / --:--

a16z 邀请了两位技术创业者——OpenRouter 创始人 Alex Atallah 与 Replit 创始人兼 CEO Amjad Masad,进行了一场名为 Why Specialized AI Could Beat The God Model 的访谈。

对话的核心观点是:未来的 AI 生态,未必由一个包办一切的“神级模型”(God Model)主导。两位嘉宾都重视不同模型的能力互补,也就是他们所说的“神经多样性”(Neurodiversity);但怎样组织这些能力,仍有取舍:Amjad 强调统一上下文的价值,Alex 更看好专用 Agent 的垂直分工。

翻成大白话:一个 AI 再聪明,也未必适合同时管银行账户、写代码、处理客户关系。企业更关心的是,能不能让不同助手各做擅长的工作,分别限制权限、检查结果,再把它们协调起来。这场访谈讨论的,就是这种分工为什么值得做,以及怎样兼顾能力、成本和控制。

原访谈 · 中英双语字幕 · 约 48 分钟。中文采用 24 号加粗字幕。

通用模型之外,产品还能提供什么价值?

这场对谈发生在 Stripe 收购 OpenRouter 之后。Alex 说,他看重的是品牌、产品与路线图的自主权,以及更有力的市场拓展。双方希望通过可靠、价格合理的基础设施,支持更多新公司出现,而不是让所有业务都归入一家巨头。他还设想,未来企业的支付与模型推理会更多地结合。(00:47:收购背景)

这解释了 OpenRouter 为什么关心模型选择与成本:开发者能用不同模型做出有差异的产品,调用费用也足够低,更多生意才有机会成立。这既是 Alex 对产业的期待,也与 OpenRouter 作为模型接入平台的业务方向相连。

做 AI 产品时,一个很直接的问题是:“你做的这个东西,我直接去调 ChatGPT 或者 Claude 不也一样能做吗?为什么非得买你的产品?”

Alex 认为,要打破这种同质化困局,答案不在于写出更长、更精巧的提示词,而在于神经多样性(Neurodiversity)。

不同模型使用的训练数据和方法不同,擅长的任务也不同。在 Alex 看来,企业可以把不同训练方法训练出来的模型、开源与开放权重模型、自研的专有小模型以及企业自身的独特数据融合在一起。企业要用自己的任务评测,判断这种组合是否真的比直接调用通用模型更好。

更现实的考量在于成本效益。如果整个市场只有 OpenAI 一家独大,在垄断或半垄断状态下,模型提供方可能缺少主动降价的动力;而只有建立起多模型并行、自由切换的交易市场,让企业不断选择效果与成本更合适的组合,大批对成本敏感的应用场景才有可能真正落地生根。


企业需要掌握自己的数据、评测和选择权

Alex 原本以为,许多企业会沿用熟悉的采购思路:“我不懂怎么分辨这些模型,那就买名气最大、大家都在买的那家。”

但他在 OpenRouter 看到,不少企业愿意探索开放权重模型,也就是可以取得模型权重并按许可部署或调整的模型。这不一定等同于完全开源;企业关注的是成本、自定义能力和供应商选择。

1. “拥有自己的智能”,不等于自己训练大模型

Amjad 用互联网和软件作类比:企业不必制造互联网,但需要掌握建设网站、使用软件的能力。AI 也是如此,企业应该积累内部能力,知道哪个模型适合哪个任务、怎样减少费用、怎样评测结果。

这种能力不是买一个功能就结束。模型持续变化,企业需要自己的任务样本和评测,才能知道新的选择是否真的更好。掌握自己的数据、流程和评测,也能降低切换供应商的困难。

Alex 提醒,模型的能力很难像普通软件那样,在网页上列一张功能清单就讲完;要看它被怎样使用,才能知道它擅长什么。对企业来说,通用榜单无法直接回答“它能不能做好我们的工作”。把真实任务、完成结果和费用持续记录下来,再比较不同模型,才会积累自己的“模型—任务匹配”经验。访谈以 Replit 的单任务成本研究为例,强调评测不只问答得好不好,还要问完成这件事花了多少。(08:53:企业选型与评测)

Amjad 还担心,基础模型公司可能从供应商变成应用企业的竞争者。他在讨论中提到了 Figma、Harvey 等公司,但核心判断是供应商的业务边界可能扩大。因此,他希望 Replit 在企业与模型、云环境之间提供一层缓冲,让企业保留选择不同供应商和部署环境的能力。

2. 别把“基础设施”当成“产品壁垒”

访谈提到一种常见观察:许多 AI Agent 产品都在建设类似的功能——反复规划并调用工具的 Agent 流程、消息通知、上下文管理与长记忆、第三方连接器、代码沙盒、网络搜索、操作电脑界面的能力。

他们认为,这些功能越来越像做 AI 应用的基本设施。 这就好比在 2005 年做 Web 网站,每个人都在写“用户数据库、注册页、登录页、个人主页、退出登录按钮”。在当时看来这也是技术,但它本身根本不构成真正的商业差异化。

企业还要考虑数据访问和部署位置。个人可以决定是否让助手读取自己的日历,但企业数据涉及不同员工、团队与客户的权限。Amjad 说,这种顾虑促使 Replit 投入让客户在自己的云环境中部署的能力。这类部署选择需要配合数据隔离与访问控制。


一个全能助手,还是一组专用助手?

如果构建一个通晓公司一切事务、打通所有业务系统的“超级个人助理”,会发生什么?

Replit 创始人 Amjad 分享了他自己的真实尝试:他曾经亲手做了一个深度绑定的 Agent,一开始只用来管理客户关系(CRM),后来逐步把个人的聊天记录、代码仓库(GitHub)、销售系统(Salesforce)乃至日常日历全接了进去。从协同效果上看,这种跨领域的串联确实能带来神奇的时刻——比如去开会前,Agent 会突然提醒你:“以前你在一次会议上见过这个人,而且对方团队也有人在与你的销售团队沟通。”

Alex 则提出另一层顾虑:把事情交出去时,人会减少对细节的理解,但 Agent 不会像同事那样承担心理压力。于是,用户仍需知道哪些任务可以信任它,哪些需要自己参与。

1. 委托工作以后,责任不会自动消失

在一家正常的运转机构中,理解细节是需要付出心智成本的。当一个人把所有跨领域的业务全盘交给一个“全能 Agent”去处理时,看似效率提高了,实际上人类放弃了对真实业务过程的深入理解。

但问题在于:Agent 不会像同事那样接过压力和责任;人和企业仍要为结果负责。

Alex 用“皮质醇”比喻委托工作时希望减轻的压力。如果助手涉及的范围太广,用户就很难分别调整自己在每类任务上的参与程度。专业化的价值,在于能分领域检查和改进:做得好的多委托,做得不好的多介入。

2. 把信任分到具体任务上

Alex 描述了自己的使用经历:他曾让一个通用 Agent 每天寻找需要自己处理的事项,但调整它之后,过一周又会开始忽略输出。他觉得宽泛职责让助手很难持续改进。

他由此更看好垂直领域的精细分工: 与其要一个在全公司大揽大包、起草所有回信的单一“超级总管”,不如要 10 个能力过硬但各自只专注一个细分业务领域的“垂直专家”。在后一种架构下,管理者可以清晰地知道每一个专用 Agent 的能力边界在哪里、对应任务由谁检查、由谁负责。在 Agent 表现不佳的领域,人类亲自接管并深度介入;在 Agent 足够可靠的边界内,人类则可以放心地享受效率红利。

两种方向仍有取舍。统一上下文能发现跨部门的关联,分工更容易把质量和权限限定在具体任务上。嘉宾设想,也许可以由一个协调者管理多个专用 Agent,但尚未找到像直接与通用助手聊天那样简洁的使用方式。

分开检查每个助手,可以更好地管理任务;让不同业务的信息相互关联,则能帮助人发现机会。真正难的是同时保留这两种能力。个人助手可以由本人决定接入多少信息,企业助手还要遵守不同员工和团队的数据权限。

3. 亚当·斯密的分工理论,在机器世界重新生效

他们借用经济学中的专业化分工,解释为什么机器未必需要包办所有工作。但在工业文明发展到后半程时,马克思指出了人类社会面临的“异化”困境:工人在流水线上日复一日只拧一颗螺丝,看不到劳动的全貌,失去了与劳动成果的情感连结,人逐渐退化成了冰冷的机器零件。

因此,现代人类追求的是更加通识、全面、具有宏观视野的发展,去克服过度分工带来的异化感。但两位创始人点出了一个精妙的反差: 人类可能不愿一辈子只做一件重复工作,但机器可以承担这样的专门任务。

这里还要分清三个层次:专用 Agent 是分职责,专用模型是针对任务选择或训练模型,结构化输出是限制回答的形式。 例如,代码助手与客户助手可以共用一个通用模型,但拿到不同数据、使用不同工具;费用预测器则可以单独训练,只返回区间和概率。多个 Agent 不等于多个小模型,输出规整也不等于判断正确。

这种类比表达了他们对机器分工的偏好,真正影响企业架构的还有权限。在真实的组织架构中,普通员工由于安全合规和权限控制,本身就不可能拥有全知全能的超级权限,助手也要遵循实际的数据访问范围。

访谈举了一个凭据隔离的例子:一个 Agent 管理银行账户,另一个管理社交媒体账号。它们可以交流完成任务需要的信息,却不必互相共享账户凭据。

不过,拆分职责还不够。一个 Agent 可能受到诱导,再说服另一个交出不该披露的信息。沿着银行与社交账号的例子想:社交助手虽然没有银行凭据,却可能通过请求银行助手发送敏感信息,间接绕过原本的分工。因此,通信本身也是需要检查的权限边界。嘉宾希望协作有明确的数据隔离与通信协议,而不是完全依赖自由的自然语言交流。(23:36:分工、权限与通信)

Alex 还介绍了 OpenRouter 内部尝试的方向:用一个快速、低成本的决策模型检查工具调用。它对照执行 Agent 的系统提示词和额外规则,判断当前操作是否允许,拒绝时给出反馈。因为工具调用很多,检查本身也要考虑延迟与费用。

红队测试的例子能说明为什么要分开。测试 Agent 需要模拟攻击者、尝试突破沙箱,但又不能访问互联网。如果让它一边模拟攻击、一边靠自己的提示词决定何时停手,就很难兼顾两种要求。另一个检查者可以掌握执行者不知道的额外限制,专门判断调用有没有越界。

他们还提到结合沙箱、网络限制等结构防护:模型负责判断,系统限制实际能够执行的操作。检查模型仍可能误判,不能因为增加了它,就撤掉外部权限控制。


让大模型探索,让专用模型接手重复任务

长期以来,业内一直流传着一种乐观的预设:模型越聪明,对人类意图的理解就越深,因而也就会天然地越安全、越对齐。

访谈也提出了这种可能性:能力增强或许让模型更能理解约束、更善于合作。Amjad 则担心,能力也可能被用于钻规则漏洞。对话同时指出,这方面不少评测并不公开,因此还缺少足够证据判断风险会怎样变化。(34:13:能力与安全的争论)

1. 更聪明,是否就更值得信任?

在 AI 安全领域,有一个著名的正交性命题(Orthogonality Thesis):系统的智力水平与其终极道德/伦理目标是相互独立的。高智力并不等同于高道德。

Amjad 认为,在人类社会中教育与同理心有时相关;但在基于强化学习(RL)训练的机器身上,情况很可能走向反面:

  • Amjad 在访谈中援引研究,担心能力增强也会提高模型在利用系统奖励漏洞(Reward Hacking)和制造欺骗行为上的能力;
  • 他还担心,模型识别自己正在接受评测后,测试中的表现未必代表长期任务中的行为;
  • 在他看来,监控思维链,也就是模型展示的推理过程,也可能改变模型的表现,不能仅凭这段文字判断它是否可靠。

在这种局面下,如果企业试图把核心安全防御、内部合规审查等命脉任务,全部托付给一个庞大复杂的非结构化黑盒模型,需要评测它的实际行为,而不只看通用能力分数。嘉宾认为,长期 Agent 任务还需要更长时间的观察。

这场对话里的“对齐”,可以具体理解为:模型会不会欺骗用户,知道自己被测试后会不会改变表现,以及能不能在长期任务中持续遵守要求。短时间答得很好,不能单独回答这些问题。

小模型也不必然更安全。如果某个前沿模型在重要任务上被证明明显更可靠,企业可能愿意付更高价格。嘉宾甚至讨论了高风险安全工作中愿不愿意付十倍价格的假设:关键在于减少错误和欺骗的价值,而不只是每次调用的价格。模型大小本身不能回答这个问题。

2. 模型训练自己的“接班者”:AI 时代的即时编译器(JIT)

面对通用模型的失控风险与高昂成本,访谈中探讨了一个极具启发性的技术演进路径:让大模型训练自己的专用替代者。

这与传统软件工程中的即时编译器(JIT Compiler)异曲同工: 在编写代码时,开发者通常使用灵活但运行缓慢的动态语言;当程序运行起来后,底层的 JIT 解释器一旦检测到某一段逻辑被反复高频调用,就会在后台实时把它编译成极其高效、专用的底层机器码。

对应到 AI,企业可以先用通用前沿模型探索场景。嘉宾设想,由大模型自己、提示词引导,或另一个观察系统运行的 Agent,发现哪些工作其实只需要有限的能力。识别出这类任务后,再以大模型为导师,定向训练或微调一个只做这一件事的专用模型。(31:13:训练接班者的设想)

这个类比的重点不只是“把大模型换成小模型”,而是先发现哪里值得替换,再为这个环节选择执行方式。自动发现并训练接班者仍是设想;对企业实际选型来说,还要把替代者放回原任务中评测,确认完成质量和总费用是否合适。

Amjad 用“拿核弹打蝴蝶”形容对简单任务动用过强模型的浪费。 任务范围缩小,可能降低推理成本,也减少不必要的行动能力。但它仍可能判断错误或受到攻击。是否值得训练,还要比较现成低成本模型能否完成任务。

从通用探索到专用执行:分工思路示意
  1. 通用模型探索先处理尚不熟悉、变化较多的任务。
  2. 识别稳定任务找出反复出现、范围清楚的工作。
  3. 选择或训练专用模型先看现成低成本模型是否够用。
  4. 用真实任务评测质量与总成本合适,再让它接手这一环节。

替换的是特定任务的执行方式;复杂问题仍可调用通用模型。

3. 只预测费用区间,为什么不需要一个全能模型

嘉宾提到,企业担心微调模型会带来一项持续负担:“模型技术债太重了。” 由于前沿大模型的迭代速度是以月甚至以周为单位计算的,企业辛辛苦苦针对非结构化文本微调出来的一个模型,可能很快面临重新微调和评估的压力。

专用分类器的“够用”标准则更集中:通用模型要不断改进语言、编程等广泛能力,企业的费用预测器主要看它能否准确预测自己的任务费用。通用榜单出现更强模型,不代表这个预测器立刻失去用途。只要任务和数据仍适用,就不必为了追赶榜单重训;业务变化时仍要重新评测和维护。

做成高结构化输出的“决策模型”(Decision Models),也让程序更容易使用和检查结果:

  • 输出范围明确:模型不生成漫无边际的自然语言长文本,更不直接生成具有执行权限的代码,它只输出离散的标签(枚举值)、特定的概率分布或结构化分类;
  • 案例实践:Amjad 说,他训练了一个费用评估器,根据用户的任务输入,预测完成编程任务的费用区间。例如,把 5 至 10 美元、10 至 20 美元设为不同类别,返回各类别的概率。他提到用分类标签的对数概率(log probs)实现这种判断。输出格式明确,程序容易读取,但预测仍可能出错;
  • 更新目标更集中:这种基于企业内部专有数据训练的垂直决策器,本质上是一个极其敏捷的业务过滤器。它不需要会写复杂的 Rust 代码,也不需要掌握全球多种罕见语言,即使外部大模型日新月异,这个专用决策器依然可以在企业内部持续服务这一任务,不必为了跟上通用榜单反复更新;业务或数据变化时仍需要维护。

4. 软件工程的历史镜鉴:从动态脚本狂欢到 Rust 时代的回归

Amjad 用软件开发作类比:开发者曾热衷于 Python、Ruby、PHP 这样的动态脚本语言。当时大家惊叹于几行代码就能搭起一个网站的开发速度,甚至连 Stripe 这样的金融机构最初都是用 Ruby 构建的,Facebook 也是从 PHP 里生长出来的。

随后,在更复杂的系统中,开发者又开始重视运行效率与错误检查,通过类型系统、即时编译等方式改进软件,也使用 Rust 等强调安全与性能的语言。这个类比说的是开发便利与运行约束之间的取舍,并不意味着动态语言被统一替代。

Amjad 预测,AI 应用也会逐渐重新重视效率和控制。 自然语言能快速探索场景,但生产系统还要计算费用、限制行动范围。Amjad 认为,开发者会越来越关注哪些环节可以用更简单的模型完成。

这一思路是:把明确规则交给代码,把概率判断限制在可评测的输出范围内。 随着训练工具的普及,未来企业在内部上传一份专有业务数据、得到一个只负责该任务的轻量决策模型,可能变得普遍;这是他对产品方向的预测。


不同模型互相补充,省下的是整个任务的成本

在实践层面,既然不迷信单一通用大模型,企业和高阶开发者该如何构建兼具高质量与高性价比的系统?

他们讨论的方向是模型融合(Model Fusion)与协同路由。(45:12:多模型组合与成本)

可以这样理解几种组合方式:复核是用另一个模型检查已有结果;路由是为当前任务选择模型;逐级升级是先用低成本模型尝试,需要时再调用更强模型;融合则结合多个模型的能力与结果。

1. 跨模型家族的协同复核

嘉宾较早观察到认真采用不同模型互相检查的场景,是软件开发领域的代码审查(Code Review)场景。工程师们很快发现:同一个模型自己写的代码,让它自己复查,可能重复原来的盲点;但如果把代码扔给另外一个不同架构、不同训练集背景的模型家族去审校,可能获得不同的检查思路,仍需用实际结果判断是否有效。

这种思维进一步延伸到了深层研究与复杂推理场景中。不同的前沿实验室在预训练时所喂入的数据资产、训练和调整方式各有千秋。将多个模型的长处进行混合编排,构建复合模型矩阵,可以让系统探索更宽广的解题思路。

这里省的可能是整个任务的费用,而不是每一步都少调用一个模型。例如,常规步骤由低成本模型处理,只把需要更强能力的部分交给昂贵模型,总费用可能低于全程调用最强模型;但如果增加的复核、重试和重复输入太多,也可能更贵。需要把所有步骤的花费和最终质量一起比较。

两位嘉宾介绍了两项具体结果:Alex 说,OpenRouter 的融合方案最初用于深度研究,以约一半成本达到较高质量;另一段讨论介绍了结合执行框架等方法,以约四到五成成本达到接近前沿模型表现的方案。它们是嘉宾介绍的具体成绩,不能把其中一个比例套到所有多模型任务上。

2. 缓存感知的工程考量与边界

在搭建多模型融合系统、模型路由网关(Router)或逐级升级模型(Escalation Model,即先由极便宜的小模型尝试解决,遇到困难再升级调用昂贵模型)时,最关键的底层工程优化之一在于提示词缓存(Prompt Caching)感知。

如果组合过程能复用此前的计算,就可能减少重复花费;反复切换模型和重复输入则可能抵消节省。嘉宾因此强调,设计路由、升级或融合系统时,需要考虑缓存。

关于是否能跨模型家族复用缓存,发言者明确说自己可能记错、需要核实。设计自己的组合系统时,仍需要查清各供应商实际支持的缓存方式。


翻成大白话,企业应该记住什么?

  1. 别指望一个“全能 AI 秘书”包办一切。 写代码、管理客户、处理银行账户,各自需要的能力和权限不同。可以让一个协调者安排任务,再交给各有所长的专用助手;哪一项出了问题,就检查哪一项。银行凭据不必交给负责发社交媒体内容的助手,人仍要负责关键结果的复核。
  2. 把选择权和判断能力握在自己手里。 企业不一定要自己训练模型,但要保留自己的数据、任务样本和评测,知道不同模型在实际业务里做得怎样。这样换供应商时,就有依据,也不必把产品全部绑在某一家 API 上。
  3. 能明确回答的任务,就让输出简单一点。 例如预测费用区间,需要的是几个区间及其概率,而不是一篇长文章。先用通用模型探索,再考虑让便宜的现成模型或自训决策模型接手重复工作。格式规整只是便于程序读取,判断是否正确、整个任务是否省钱,还得用实际业务结果来检验。
来源
Why Specialized AI Could Beat The God Modela16z;Erik Torenberg、Alex Atallah、Amjad Masad·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。