看多了学术圈的漂亮跑分，真到了企业里干活，大模型的裸能力简直是不堪一击。在Spider这类榜单上，那些顶尖的Text-to-SQL方案准确率能跑到85%到91%，看着快赶上人类标注员了。结果呢？Shopee技术专家王新波在QCon上直接交了底，他们团队不到一周搭了个初代Demo，把平台上一百万张表做了向量索引，满怀信心地丢给大模型生成SQL。一跑内部评测集，找表准确率只有56%，执行准确率不到40%，连最基本的语法准确率都徘徊在五六十。 这还不是最惨的。Spider 2.0搞了个基于企业真实OLAP场景的评测集，GPT-4o这种顶尖裸模型上去跑，准确率直接跌到10%左右。从纸面上的90%跌到实战的10%，这脸打得啪啪响。其实不光是数据查询，你去看看Snowflake在Summit 2026上探讨的企业级Agent落地，大家都在面对同一个残酷现实：通用大模型在实验室里无所不能，一进企业复杂的业务泥潭就集体翻车。 以前我们总觉得，只要模型够聪明，写个好Prompt就能解决所有问题。现在看完全是想多了。企业级场景里的表结构错综复杂，业务语义千变万化，指望大模型靠裸能力一步到位，纯属自欺欺人。这根本不是模型参数量够不够大的问题，而是缺乏对真实业务逻辑的工程化拆解。 想靠大模型裸能力在企业场景里蒙混过关，趁早歇歇。真正的企业级Agent落地，必须得把大模型塞进Multi-Agent架构里，配上工程化底座，跟业务场景死死绑在一起。别总盯着那些虚无缥缈的学术跑分了，放下对通用大模型一键解决问题的执念，去啃那些脏活累活，才是跨越从看见问题到解决问题这道鸿沟的唯一出路。 Shopee团队当时搭了个典型的RAG链路，把平台近30天有访问记录的100万张表全做了向量索引。用户提问，系统先检索召回表，再拼元数据丢给大模型一步出SQL。听着挺顺理成章，结果一跑内部评测集直接傻眼。找表的平均倒数排名只有56%，执行准确率不到40%，连最基础的语法准确率都只在五六十徘徊。 翻车原因其实很现实。企业里的OLAP场景根本不是学术榜单上那种干干净净的玩具数据。100万张表里，同名不同义的、历史遗留的废弃表、各种复杂关联的宽表多得是。大模型靠向量检索捞出来的表，往往张冠李戴。就算表侥幸找对了，面对那些带着浓厚业务黑话的字段名，大模型也是两眼一抹黑，生成的SQL在业务语义上错得离谱。 这就好比让一个刚毕业的名校高材生，直接去接手一个跑了五年、文档全无、充满祖传代码的老系统，不翻车才怪。以前我们总迷信大力出奇迹，觉得模型参数够大、提示词写得够花哨就能搞定一切。现在看，脱离业务场景谈AI取数纯属耍流氓。不把这些脏活累活拆解成工程化的多步任务，单靠大模型裸奔，永远只能在演示环境里自嗨。 既然让大模型一口吃成个胖子行不通，那就只能把活儿拆碎了分给不同的人干。Shopee团队在复盘了初代Demo的惨痛教训后，果断抛弃了单模型一步生成SQL的幻想，转而搞起了Multi-Agent架构和Skill机制。 以前的思路是，一个Prompt塞进所有上下文，指望大模型自己理清表关系和业务逻辑。现在他们把整个取数流程大卸八块。先上路由Agent做意图识别和任务拆解，判断用户到底是要查数据还是做分析。接着，专门的找表Agent接手，不再盲目依赖向量检索，而是结合业务元数据去精准定位。最关键的是引入了语义模型和Skill机制，把那些晦涩的业务黑话和计算逻辑封装成一个个可调用的技能插件。大模型不需要自己去猜字段含义，直接调用对应的Skill去拿标准答案。 这种架构重构，本质上是把大模型从无所不能的全能神降级成了各司其职的专业打工人。路由Agent像个项目经理，负责统筹调度；执行Agent像是一线开发，专注搞定具体的SQL生成；而Skill机制就是现成的代码库和工具包，随取随用。通过这种多智能体协作，原本容易出错的长链路被切分成了多个可控的短链路，每个环节都能单独加校验和做兜底。 别总指望大模型能靠悟性解决所有业务痛点。把复杂任务拆解成标准化模块，用Multi-Agent去分工，用Skill机制去补齐领域知识，这才是让AI真正在企业级场景里干活的靠谱路径。靠模型自己顿悟不如靠工程架构兜底，把不确定性降到最低，Agent才算真正具备了生产力。 数据取数那边刚把架构理顺，IT运维的可观测性场景也迎来了同样的价值跃迁。以前运维兄弟怎么干活？半夜被报警电话叫醒，盯着满屏红彤彤的监控大盘，挨个去翻日志、查链路，熬到凌晨三点才定位到一个隐蔽的内存泄漏。如果这时候你指望丢个裸大模型进去，它顶多给你甩一句CPU使用率异常，纯属正确的废话。看见报警和解决问题中间，隔着十万八千里。 现在搞可观测性Agent，思路跟前面一样，绝对不能靠大模型裸奔。报警一响，系统先让诊断Agent接手，去精准拉取相关的调用链、指标和日志。诊断Agent结合团队沉淀的运维标准作业程序进行根因推理，锁定具体的故障节点。接着，执行Agent接管战场，直接调用预先封装好的修复技能插件，比如自动扩容、重启服务或者流量降级。 这就把以前纯靠人肉盯盘的流程，变成了从发现、诊断到修复的自动化闭环。大模型在这里不再是只会写分析报告的嘴炮，而是真正能下场干活的运维老兵。别总想着给大模型喂点监控数据让它自己顿悟，得用工程化的Multi-Agent架构给它配齐手脚，它才能真正跨越从看见问题到解决问题的鸿沟。 前面拆了架构也看了场景，咱们得面对一个现实：别再死磕单点Prompt调参了。不少团队Agent效果上不去，第一反应就是回去改提示词，天天在那儿咬文嚼字调参数。这方向从一开始就歪了。企业级Agent真正的护城河，从来不是你那几句精心编排的咒语，而是背后的工程化底座和数据运营闭环。 以前做传统AI应用，模型一调、提示词一写，发个版就算完事。现在搞企业级Agent完全是另一套逻辑。Shopee团队在复盘时就明确提到，他们是靠工程底座与运营闭环，才把一个简单的取数工具逐步雕琢成可靠的生产力工具。 这话听着虚，落到实处全是不折不扣的脏活。Agent上线根本不是终点，而是起点。你得有个坚实的工程底座去统管那些Skill插件、业务元数据和复杂上下文。更关键的是数据运营闭环，用户查错数据了、运维诊断跑偏了，系统必须能自动捕获这些Bad case。人工介入修正后，这些纠错数据得实时反哺到语义模型和知识库里。 没有这个闭环，你的Agent就是个只会犯同样错误的复读机，用得越久用户流失越快。有了这套数据飞轮，系统才能吸收真实业务反馈持续进化。别总盯着大模型厂商又卷出了什么新参数，把精力砸在搭建自己的工程底座和运营闭环上。当你的系统能靠业务数据自己长出脑子时，这才是竞品根本抄不走的真壁垒。 折腾了这么多架构和闭环，咱们得认清一个现实：通用大模型救不了企业级应用。以前大家总幻想找个最聪明的模型，写几句神仙提示词就能让业务方乖乖掏钱。现在呢？模型再聪明，不懂你们公司那套祖传的业务黑话，生成的结果也是垃圾。放下对通用大模型一键解决问题的执念吧，去啃企业级场景里的脏活累活才是正经事。 什么是脏活累活？不是让你在后台调调参数。是去跟业务部门拍桌子理清那些模糊的需求，是去清洗那些连文档都没有的历史遗留数据，是把那些只可意会不可言传的老员工经验，硬生生拆解成机器能懂的技能插件。王新波在分享里说得很透彻，他们团队花大量精力去雕琢语义模型和元数据，这才是让数据智能体真正落地的基石。 通用大模型顶多算个算力充沛的发动机，但企业级应用是一辆要在泥泞烂路上跑的重卡。你不给它装上多智能体的传动轴，不铺好工程化底座的底盘，发动机马力再大也只能原地打滑。别再盯着大模型厂商又发了什么千亿参数模型了，那跟你的具体业务没半毛钱关系。 真正聪明的做法，是把大模型拉下神坛，当成一个随时可调用的基础组件。把主要精力砸向业务场景的深度结合，去构建那些别人不愿意干的工程细节。当你的系统能靠着一堆脏活累活垒起来的底座，稳稳当当帮业务解决一个具体问题时，它才真正具备了商业价值。别做梦等下一个大模型奇迹了，卷起袖子去泥坑里干活吧。