一家企业最近公开了一个技术支持 Agent 的搭建细节：2000+ 篇文档、本地检索、离线交付。最值得看的不是"用了 RAG"，而是他们定的两条硬约束——必须能离线交付、个人 Token 配额。这两条几乎一票否决了"云端大模型问答"路线。我们由此看到一个常被忽略的事实：企业 AI 落地的瓶颈，往往不是模型能力，而是交付形态和成本结构。

这是什么

RAG（Retrieval-Augmented Generation，检索增强生成），说白了就是"先查资料、再回答"。它针对大模型的三个老毛病：会编内容、知识过时、没见过你的内部文档。

这家企业做的事：把 2000+ 篇文档离线打包成本地知识库，安装时索引随包分发。用户提问时，先在本地搜出相关片段，再喂给模型"照着材料写"。关键设计是双模式——没 Token（调用大模型的凭证）也能直接出检索结果，有 Token 再让模型润色。

两个细节值得记：混合检索（同时用语义相似度 + 关键词匹配）能抓 API 标识符；更重要的是"检索是主能力、LLM 是增强层"这个优先级——它决定了产品能不能在严苛环境下跑。

行业怎么看

支持方认为这是务实路线：企业要的是"可用、可控、不烧钱"，不是"最强大"。RAG 把答案绑回来源文档，技术支持场景天然契合。

但反对意见也值得听。一种质疑：把"没 Token 也能用"当卖点，本质上是把模型降级为搜索引擎——能查文档不等于 Agent（能自主完成多步任务的 AI 程序），长期可能拉低用户对 AI 的预期。深一层风险：离线打包意味着知识更新延迟，文档改了一行，前线要等下一版安装包；这在 SDK 频繁更新的行业是隐患。还有声音指出，这类项目很容易做成"高级搜索"，但距离真正的 Agent 自主处理工单还差几个量级。

对普通人的影响

对企业 IT：评估 AI 项目时，别只问"用哪个模型"，先问"在哪儿跑、谁付费、合规怎么过"。交付形态和成本结构，往往比模型选型更早定生死。

对个人职场：如果你的工作内容是"反复回答文档里已经写过的问题"，这类 Agent 会最先冲击你的岗位；但反过来说，能用好它做"高级检索"的人，效率会被放大。

对消费市场：短期内你不会直接感受到。但当企业把"用 AI 替代初级客服/技术支持"列为降本手段时，售后体验可能出现"答得快但答得浅"的退化——值不值得警惕，留给消费者自己判断。