只有橘子最近几天，关于AI的讨论几乎到了一年中最热闹的时候，达沃斯论坛上那几场围绕人工智能的激辩，被各路媒体反复引用。我也仔细看了几场对谈的文字实录和现场转述，说实话，真正让圈内人绷紧神经的，不是哪个模型又跑了个漂亮分数，而是一连串悬而未决的方向性问题：大模型的“暴力美学”到底还能撑多久？Agent是不是被捧得过高了？开源和闭源的路线之争，是不是已经有答案了？以及最现实的问题——AI究竟能不能赚钱？
这些问题在论坛上被大佬们用很体面的方式讨论了无数轮，但对真正在一线做AI应用、做模型部署、做技术选型的人来说，答案并不在台上的麦克风里，而在每一个项目的需求文档里、每一次评测的准确率波动里、每一笔GPU账单里。这篇文章我不打算复述达沃斯上谁说了什么，而是想顺着论坛上几场争论最激烈的议题，结合我这几年在AI工程化落地里的实际体验，聊聊那些“台上没法细说、但台下必须直面”的技术真相。文章里的每一条，都不是从新闻稿里摘的，是我自己在项目里踩过的坑和验证过的判断。
1. 吵得最凶的其实不是模型有多强，而是钱还该不该这样烧
达沃斯上关于大模型“暴力美学”是否走到头的争论，几乎每一场都有。一派观点认为，只要继续堆算力、堆数据、堆参数，模型能力自然会继续往上涨，这是过去几年已经被反复验证过的路径；另一派则认为，低成本、高效率的路线正在成为新主流，大厂们动辄数十亿美元的训练账单，边际收益已经开始快速递减。
这个问题在新闻里被简化成了“Scaling Law是否见顶”的路线之争，但在实际工程里，它的答案要复杂得多。
先说我自己比较确定的判断：纯粹堆参数的路线确实在放缓，但这不意味着Scaling Law失效了，而是“堆什么”变了。以前你只需要拼命找更多的文本数据，现在文本已经快被榨干了，于是大家开始疯狂做合成数据、做多模态数据、做推理过程的数据。我去年帮一个客户做金融领域的合同审查模型，最明显的感受就是：通用语料能带来的提升已经微乎其微了，反而是把几千份脱敏合同、几百条审查规则整理成结构化数据之后，模型在具体任务上的表现瞬间上了一个台阶。
你去看达沃斯上那些还在坚持“大力出奇迹”的团队，他们其实也没有真的躺平，而是在换一种方式“大力”——大力做数据工程、大力做强化学习、大力做推理时计算。DeepSeek R1能让整个行业重新讨论推理模型，靠的也不是参数规模碾压，而是把强化学习用在了推理路径的优化上。这说明一个问题：大模型的下一波增长点，可能不在“模型更大”，而在“训练更聪明、推理更会用”。
但我在实际项目里也见过很多团队走了另一个极端——一听Scaling Law放缓，就觉得微调、蒸馏这些“技巧流”可以完全替代底层模型能力的提升。这个认知很危险。你可以用蒸馏和微调把7B模型调教得很听话，但遇到真正需要复杂推理和广泛知识覆盖的任务，小模型的边界是实实在在的。你没法用技巧去弥补一个它从来没见过的知识盲区。
所以关于“钱还该不该这样烧”，我自己的判断是：基础模型的预训练确实越来越像一场巨头游戏，不是一般团队能参与的；但对做应用层的人来说，这场争论的实质其实跟你关系不大。你需要关心的是怎么用更小的模型、更省的推理成本、更高质量的领域数据，把90分的通用能力变成95分的业务能力。方向永远比“烧多少钱”重要。
1.1 别被几个榜单分数骗了，关键要看评测任务怎么设计
很多团队在选模型的时候，最喜欢看的就是公开榜单的排名。但达沃斯上也有一位非常务实的工程派大佬点了一句：公开评测集正在被严重刷爆。这句话我太认同了。我在做模型选型的时候几乎不看纯粹的排行榜，因为那些分数背后有太多水分。
比如说，有的模型在MMLU这种知识问答集上分数很高，但在具体的业务问答里表现非常一般，原因很简单——训练数据可能已经把这些题“背”下来了。真正有效的评测是自己根据业务数据构造的评测集，而且评测任务的设计必须贴近真实使用场景。比如你做客服机器人，就不能只测“它知不知道答案”，而要测“它在上下文混乱、用户表达不完整的情况下还能不能给出可靠回答”。
我建议团队在选型阶段至少要做三层评测：第一层是通用能力基准，看模型的逻辑推理和知识覆盖是否有明显短板；第二层是领域数据评测，用你自己的业务数据构造几十上百道题，看模型的输出质量；第三层是红队对抗测试，专门拿边界问题、诱导性问题、陷阱问题去攻击它。只有三层评测都过关的模型，才值得你进入下一步的研发投入。
1.2 推理模型的“思考”消耗，是你成本评估里必须算清楚的账
达沃斯上关于推理模型的讨论，很多都集中在“思考能力”的提升上，但很少有人提醒大家：让模型“想”得多，是要额外付费的。我见过不止一个团队，前面评估模型能力时觉得推理模型表现惊艳，结果一上生产，发现API费用比预期贵了三四倍，整个项目的ROI瞬间变成负数。
所以你在做推理模型选型前，一定要先想清楚自己的场景是不是真的需要“深度思考”。像代码生成、数学推导、复杂规划这类任务，推理模型确实有优势；但像信息抽取、情感分类、简单问答这类任务，让推理模型开启长时间思考，完全是浪费钱。现在的模型服务商基本都提供了关闭思维链或者限制思考时长的参数，我一般建议在非推理密集场景下强制关闭，或者在路由层做分流——简单问题走小模型，复杂问题才交给推理模型。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Agent 到底是未来，还是又一轮 Demo 狂欢
达沃斯上另一个绕不开的话题，就是Agent。几乎每家AI公司都在讲“Agent是关键趋势”，但到底什么是Agent，不同的人给出的定义是千差万别的。有人觉得能调用几个工具就是Agent，有人觉得必须有完整的规划-执行-反思循环才算Agent，还有人干脆把所有自动化工作流都叫Agent。
作为从自动化脚本、RPA时代走过来的人，我看到的真实情况是：Agent概念的膨胀速度远快于它的工程成熟度。那几场论坛里，大佬们在台上说的东西都很乐观，但一落到实际生产环境，就知道问题有多少。
我自己测试过当前主流的Agent框架，也在一家电商公司落地过一个半自动化的运营助手。最直观的体感是：在受控的Demo环境和低复杂度任务上，Agent的完成度已经相当高了，你让它查个库存、发个优惠券、填个报表，它能干得像模像样。但一旦任务链条变长、依赖外部系统变多、条件分支变复杂，成功率就会以肉眼可见的速度往下掉。
这不是某个框架的问题，而是Agent这个技术方向当前的结构性短板：第一，它依赖于大模型每一步的推理质量，而大模型在长链条任务里容易出现错误累积；第二，Agent的任务编排和状态管理目前仍然缺乏统一的标准，各家框架自娱自乐，很难互通；第三，一旦引入多Agent协作，通信开销和协调成本会指数级上升，维护起来非常痛苦。
但我也要诚实地讲：Agent即便有这么多问题，它依然是目前最接近“AI能独立干活”的形态。我之所以愿意在这个方向上持续投入，是因为我看到它在某些场景下确实已经产生了实际价值。关键在于你要选对战场，不要一上来就做那种全自动、无人值守、跨十个系统的复杂Agent，而是先从“人审+Agent干活”的半自动模式开始，让Agent在明确的边界内发挥价值，把异常情况交给人工处理。
2.1 架构设计上，把“计划”和“执行”拆开才是正解
很多Agent翻车，不是因为某个模型能力不行，而是架构设计上出了问题——让模型在同一次推理里去完成“理解需求、拆解任务、调用工具、校验结果”的所有工作。这样一旦任务复杂，模型的注意力就散掉了，每一步都做得不够好。
我目前验证下来比较稳的模式，是两层架构：上层有一个Planner（规划器），负责把任务拆解成子步骤；下层有若干个专门的Executor（执行器），每个执行器只做一个具体动作，比如调数据库、调API、生成文本。Planner不直接干活，它只负责拆任务和检查结果；Executor不思考大局，它只负责把单一动作做到位。
这样拆开之后，每个环节的模型都可以单独调优和替换，出了问题也能快速定位是规划错了还是执行错了。比你让一个Agent从头到尾全包要稳得多。如果你打算在生产环境上Agent，我强烈建议从这个架构入手，不要迷信一站式Agent框架。
2.2 真实业务里的Agent，先做“窄而深”而不是“宽而浅”
我观察到一个挺普遍的现象：很多团队做AgentDemo的时候喜欢做那种“万能助手”，什么都能聊、什么都能干，然后一到真实业务里就露馅。我觉得这跟达沃斯上那些宏大的Agent叙事有很大关系——大家被“AI同事”“数字员工”这些概念带偏了，总想一步到位。
但真实业务里的Agent，最有价值的恰恰是“窄而深”。比如你做一个电商售后Agent，不要让它什么都干，就让它专注做退换货地址识别、物流状态查询、运费规则判断这三件事。范围窄了，评测集可以做得很全，模型行为就变得可预期，你才敢让它面对真实用户。等它在三个窄场景上跑熟了，再去扩下一个场景，这种路径比做一个看似全能但处处需要人盯的Agent要靠谱得多。
3. 开源模型和闭源模型，厂里到底该站哪边
达沃斯上开源和闭源的争论也非常激烈。闭源派强调模型能力、安全性和企业级支持；开源派强调自主可控、私有化部署和数据安全。两边都有道理，但落到具体的技术选型上，情况远非一句“开源好还是闭源好”能概括。
从我的使用经验来看，过去两年开源模型的进步速度确实超出了我的预期。拿Qwen系列和Llama系列来说，从早期版本到现在，开源模型在通用能力上已经把和顶尖闭源模型的差距缩小到了一个“可接受”的范围。更重要的是，开源模型在垂直领域的可塑性非常强，你可以做全参数微调、LoRA微调、甚至蒸馏蒸馏再蒸馏，这在闭源模型上是做不到的。
我去年有一个项目，客户的数据完全不能出内网，闭源模型连试用都谈不上。最终我们选了基于开源模型做私有化部署，配合LoRA微调，效果在客户的业务场景里跟闭源大模型的差距已经很小了。这个过程中，开源社区的力量给我留下了很深的印象，你能找到各种优化过的推理框架、量化方案和部署工具，生态成熟度远超三年前。
但这不是说闭源模型没有优势。论综合能力，尤其是复杂推理、创意写作、长上下文理解这些方面，顶级闭源模型仍然是第一梯队。而且闭源模型的API通常更稳定，服务SLA有保障，对很多ToB客户来说，“出了问题有人扛”这件事本身就值不少钱。
我个人现在的选型策略基本上是三分法：核心业务、涉及隐私数据的一定走私有化开源模型；需要最强能力且数据合规允许的，走闭源API；中间地带——也就是那些数据敏感度不高、但需要一定稳定性和成本优势的场景，我会做一个双通道，平时用开源模型兜底，遇到复杂任务路由给闭源模型。这样既照顾了成本和数据安全，又保住了能力上限。
3.1 蒸馏和微调，决定了开源模型在你手里的真实价值
很多人觉得开源模型和闭源模型的差距是固定的，其实不然。开源模型就像一块原石，微调和蒸馏的工艺决定了它最终的成色。我见过有人在7B模型上微调之后，领域能力直接追平了同级别的闭源模型；也见过有人完全不做任何适配，把开源模型直接扔到生产环境里，结果效果差得没法看。
这里我不展开微调的技术细节，但想强调三点经验：第一，微调的数据质量远比数据量重要，50条高质量样本往往比5000条低质量数据效果更好；第二，蒸馏是现在性价比极高的路线，你可以拿最强的闭源模型当“老师”，生成一批高质量思维链数据，然后用开源小模型去学，能在成本和效果之间取得很好的平衡；第三，微调不是越多越好，过拟合是开源模型微调里最常见的坑，一定要留一部分评测集来监控泛化能力。
3.2 部署和运维成本，才是“免费”模型最贵的地方
开源模型本身不需要付License费，但部署和运维成本经常被低估。我在一个生产项目里就栽过大跟头：模型下载下来跑通了，但一上生产，并发一高，GPU显存直接被打满，服务频繁OOM。后来才发现，光做量化、配推理加速、设计缓存策略就花了整整两周时间，这笔投入一点都不比API调用费便宜。
所以如果你团队里没有人熟悉模型部署和推理优化，我建议刚开始不要急着私有化部署开源模型。可以先走闭源API把业务跑通，等验证了场景价值之后，再逐步引入开源模型做降本。这个顺序能帮你少走很多弯路，避免在技术基建上过早投入。
4. AI 到底能不能赚钱，以及“幻觉”这个老问题怎么解
达沃斯上的讨论再热闹，最后大家都会绕回一个问题：AI的商业模式到底成立吗？其实这背后有两层意思，外层是“企业愿意为什么样的AI能力付费”，内层是“AI的输出能不能被信任到直接进业务流程”。这两件事没有一件是容易的。
从我这几年看过和做过的AI项目来看，真正赚到钱的AI应用，几乎没有一个是靠“哦我有一个好酷的AI功能”完成的，而是靠着AI帮企业在某个具体环节上省下了实打实的钱或者创造了实打实的增量。比如客服场景，AI替代了一部分人工咨询，响应时长降低了50%，这就是钱；比如出海电商场景，AI批量生成了多语言商品描述，Listing上新的速度翻了一倍，这也是钱。AI并不是没有商业价值，而是它的价值藏在业务流程的毛细血管里，不是一场发布会就能讲清楚的。
但要真正把AI塞进业务流程，最大的拦路虎就是“幻觉”。我在好几个项目里都遇到过同一个尴尬：模型在80%的情况下表现完美，剩下的20%会一本正经地输出错误信息。对C端聊天机器人来说，这个错误率可能还能忍受；但对B端系统，尤其是涉及合同、医疗、金融这些领域，一次幻觉就可能造成不可挽回的损失。
所以现在业内对幻觉的解法已经从“让它不犯错”转变为“让它知道自己不知道”，以及“在架构上阻断幻觉带来的危害”。我自己的实践里，下面这几招组合使用下来，效果是最明显的。
4.1 RAG不是银弹，但做对了能把幻觉压到可用区间
RAG（检索增强生成）是当前缓解幻觉最主流的方案，但很多人把它想得太简单了——以为把文档切一切塞进向量库就完事了。我见过太多做失败的RAG项目，召回率低、答案不准确、引用错乱，最后团队得出一个“RAG没用”的结论。其实RAG的效果取决于每一个环节的细致程度。
我现在做RAG已经形成了一套固定的工程流程：先做文档清洗和结构化解析，把PDF里的表格、页眉页脚、乱码处理干净；再做混合检索，“向量召回+关键词召回”双通道，用重排序模型把两边的结果合并和去重。这个过程看着基础，但恰恰是决定RAG质量的胜负手。你花80%精力把知识库和检索做好，模型生成答案的质量自然就上去了。
另外，知识库的更新频率和版本管理也值得重视。我见过一个内部问答系统，因为知识库没更新，三个月前已经作废的流程还被模型当作标准答案给出来，这种问题在RAG架构里比幻觉本身还危险。现在我会给知识库里的文档都打上时间戳和版本号，并且在Prompt里强制要求模型优先引用最新版本的内容。
4.2 建立“事实核查”机制，别让模型独自做最后决定
即便有了RAG，模型在生成答案时仍然可能“自由发挥”。所以我在生产级系统里会额外加一道“事实核查”的关卡：让模型在回答的同时给出回答所依据的引用片段，然后由一个独立的校验模块去检查这些引用片段是否真的存在于知识库中，以及答案和引用片段之间是否存在矛盾。
这个过程不需要特别复杂的模型，逻辑规则加一层校验提示词就能覆盖大多数问题。它的核心思路是把“模型说对了没”这个不可控问题，转化为“模型的回答能不能在知识库里找到依据”这个可验证问题。只要校验不通过，系统就会返回“我无法回答这个问题”而不是继续硬编。虽然这样会让回答的覆盖率稍微下降一点，但守住的是下限——下限守住了，企业才敢让你上线。
4.3 用评测集和回归测试，给“幻觉”上保险丝
很多团队只在项目上线前做一次评测，上线之后就再也不管了。但大模型是会“漂移”的——API升级、Prompt微调、知识库变更，任何一个环节动了，模型的表现都可能发生变化。我在项目里会坚持做一套“线上回归测试”：每个月用同一批评测集跑一遍全流程，把回答正确率、引用准确率、拒答率这些指标记录下来，一旦发现指标滑坡，立刻回溯定位是哪一次改动引发的。
这套机制看起来很笨，但它是目前对抗“幻觉”和“模型漂移”最可靠的手段。评测集不是越大越好，而是覆盖度越广越好——要包含正常的业务问题、边界问题、误导性问题和完全无关的问题。每季度更新一次评测集，把新发现的错误案例加进去，模型就会在下一个版本里“长记性”。
5. 我在迷雾里做选择时的一些土办法
前面讲了达沃斯上争论的几大技术议题和我的一些判断，最后想分享几条比较个人化的经验。这些“土办法”不一定是理论最优解，但在方向和不确定性都很大的时候，它们很管用。
第一条，所有的路线之争，最后都要落到“你手头是什么数据、面对什么用户、有多少预算”这三个问题上。别人说得再对，场景不一样答案就会不一样。达沃斯上的大佬们可以聊十年后的通用人工智能，但你不能拿十年后的愿景去支付下个月的服务器账单。任何技术选型，先算清楚三个账：数据账、场景账、成本账。
第二条，不要让“完美主义”拖死项目。现在AI技术迭代太快了，你等“最完美的方案”出现，可能等着等着，你的业务窗口期就过去了。我见过太多团队在模型选型上反复纠结了几个月，最后什么也没做出来。比较务实的做法是：先设定一个“能用”的标准，找一个80分的方案快速上线试错，然后用真实业务数据来驱动迭代。做AI项目最忌讳的是在岸上反复研究游泳姿势，不下水永远学不会。
第三条，也是最核心的一条：无论外界怎么吹或者怎么唱衰，AI的能力边界是在快速变动的。我两年前觉得“这个任务AI肯定做不了”，现在已经成了常规操作；但也有一些两年前觉得“AI马上要替代人类”的场景，至今还在原地踏步。所以对技术保持乐观，对落地保持谨慎，这两者完全不矛盾。与其把宝押在某一个具体的技术路线上，不如把团队的能力建在“快速学习、快速验证、快速迭代”上。
达沃斯上的那些激辩，本质上就是大家在给AI的现状找一个坐标。但坐标这个东西，别人给不了你，只有自己在实战中一次次试错、一次次复盘，才能慢慢画出来。希望这些文字能给你一些参考，也欢迎在评论区分享你在AI实践里踩过的坑和得出的判断。毕竟，迷雾里的路，都是大家一起趟出来的。