RAG 智能体产品化边界：Internal、Web 与 Token 工厂为什么要分开
前两篇分别讲了企业 RAG 智能体的生产架构和知识生命周期。到了产品化阶段，另一个更现实的问题会出现：这个系统到底卖什么？
如果回答是“卖模型 token”，那项目会被拉进通用模型 API、价格战、GPU SLA、开发者生态和基础模型能力对标里。
如果回答是“卖知识库问答”，那还不够，因为普通问答工具很容易被认为是低门槛应用。
更准确的定位应该是：企业级 RAG 知识库智能体平台。它卖的是企业知识、权限边界、引用可信、审计可查、可控联网和可计费调用。
1. 先把三类业务分清楚
这个项目里最需要避免的误区，是把“模型售卖 PoC”“公网通用模型服务”和“企业 RAG 智能体”混为一谈。
三者听起来都在调用大模型，但商业承诺完全不同。
| 类型 | 卖的是什么 | 技术核心 | 当前更适合的定位 |
|---|---|---|---|
| 模型售卖 PoC | 把模型通过 NewAPI / vLLM 暴露成 API，验证调用、鉴权、额度和计费 | API 网关、模型接入、usage、基础推理 | 可以做 |
| 公网通用模型服务 | 面向公网开发者售卖类似 DeepSeek / OpenAI 的通用模型 API | 基础模型、训练、安全、推理集群、SLA、生态 | 当前不应承诺 |
| 企业 RAG 智能体 | 基于客户知识库回答问题，带引用、权限、审计和可控联网 | NewAPI + Adapter + RAGFlow + Evidence Gate + vLLM | 当前主线 |
产品定位如果一开始说错，后面技术再努力也会变成补窟窿。
2. 为什么不包装成公网通用模型服务
公网通用模型服务卖的是“基础模型能力 + 平台可信度”，不是单纯把 vLLM 接到 API 网关。
要做 DeepSeek / OpenAI 式的公网服务，至少要长期投入：
| 能力 | 需要什么 |
|---|---|
| 模型能力 | 训练、微调、蒸馏、对齐、长上下文、多轮和工具调用优化 |
| 安全体系 | 内容安全、越狱防护、滥用识别、红队测试 |
| 评测体系 | 通用能力、行业能力、安全能力和回归评测 |
| 推理平台 | GPU 池、批处理、KV cache、冷热模型、弹性扩缩容 |
| SRE | 公网 SLA、限流、熔断、降级、多地域、故障恢复 |
| 合规 | 日志留存、隐私保护、数据边界、行业监管 |
| 商业生态 | SDK、开发者文档、控制台、工单、账单、客户成功 |
当前项目里的 vLLM 定位很清楚：它只负责加载模型并生成 token。
vLLM 不保存知识库，不决定是否联网，不负责内容安全最终责任，也不承担公网模型服务的生态承诺。
所以，当前项目可以验证模型 API 调用和有限计费闭环，但不应对外宣称已经具备公网通用模型服务能力。
3. 企业 RAG 智能体卖的是可信知识服务
企业客户真正愿意付费的，往往不是“又一个聊天框”，而是以下能力：
| 能力 | 客户价值 |
|---|---|
| 私有知识问答 | 把制度、手册、项目资料、运维文档变成可查询资产 |
| 引用来源 | 每个答案能回到文档、chunk、页面或标题路径 |
| 权限隔离 | tenant、KB、user、ACL 在检索前生效 |
| 证据不足拒答 | 不用模型常识补企业私有规则 |
| 可控联网 | 最新公开信息可以查，但必须显式授权和审计 |
| 反馈修复 | 坏答案能沉淀为 golden question、负例和知识点修正 |
| 多模型接入 | DeepSeek、GLM、MiniMax 或本地 vLLM 可以切换 |
| 统一计费 | API Key、额度、usage 和成本可归集 |
这才是企业 RAG 智能体的产品价值。
它不是“模型更聪明”，而是“企业知识被组织成了可追溯、可治理、可运营的服务”。
4. Internal RAG 和 Web RAG 要产品化分开
Internal RAG 和 Web RAG 不能只是配置项差异，最好在产品入口、模型名、权限策略和审计字段上都明确区分。
我更建议把它们设计成不同产品入口，而不是同一个入口里加一个“允许联网”的开关。入口一旦混在一起，用户很难知道当前问题会不会外发，审计也很难解释这次联网到底是谁授权的。
推荐模型名类似：
DeepSeek-V4-Flash-RAG-Internal
DeepSeek-V4-Flash-RAG-Web
GLM-5.1-FP8-RAG-Internal
GLM-5.1-FP8-RAG-Web
Internal RAG 适合：
| 场景 | 要求 |
|---|---|
| 内部制度助手 | 禁止联网，证据不足拒答 |
| 运维手册助手 | 只基于内部 runbook、故障记录和配置说明 |
| 研发知识库助手 | 不把代码片段、内部域名、日志外发 |
| 客户资料助手 | 权限和审计优先 |
Web RAG 适合：
| 场景 | 要求 |
|---|---|
| 政策和公告查询 | 显式授权后查官方来源 |
| 版本和漏洞信息 | 区分内部知识和外部网页 |
| 竞品和公开资料研究 | 外部证据只作为临时证据 |
| 市场和售前资料 | 来源可信度和时间戳必须可见 |
这样拆开后，客户也更容易理解：Internal 是可信内部知识助手，Web 是带授权的外部证据增强助手。
5. Web 检索不是默认福利，而是高风险能力
很多产品会把“可联网”包装成增强能力，但在企业场景里，它首先是风险能力。
联网检索至少有四类风险：
| 风险 | 说明 |
|---|---|
| 敏感查询外发 | 用户可能把客户名、密钥、日志、内网域名带进搜索 |
| 网页提示注入 | 外部页面可能包含诱导模型忽略规则的内容 |
| 来源污染 | SEO 农场、镜像站、采集站可能污染证据 |
| 长期知识污染 | 临时网页如果自动写入企业 KB，会污染知识库真相来源 |
所以 Web Retrieval 必须由 Evidence Gate 和策略层控制：
内部证据优先
-> 证据不足或需要时效性
-> 检查全局、租户、KB、用户和请求策略
-> 显式授权后才联网
-> 外部网页作为临时证据
-> 答案区分内部来源和网页来源
一句话：能联网不代表应该联网，授权联网也不代表可以写入长期知识库。
6. Token 工厂可以做，但它是另一条产品线
如果要做“模型卖 token”或“Token 工厂”，它应该作为并行产品线，而不是塞进 RAG 智能体里。
Token 工厂卖的是：
按模型、按 token、按并发、按 SLA 提供标准化模型推理服务。
它的核心组件更像这样：
NewAPI / API Gateway
-> Model Gateway
-> Model Router
-> vLLM / Triton / External Provider
-> Usage Ledger
-> Observability / FinOps
和 RAG 智能体相比，Token 工厂关注的是 token 计量、流式落账、失败扣费、模型路由、推理成本和 SLA。
RAG 智能体关注的是知识库、引用、权限、证据门和反馈修复。
两者可以共享 NewAPI、Model Router、vLLM、GPU 资源池和监控，但不能共享同一个产品承诺。
7. usage ledger 是 Token 工厂的事实源
如果要卖 token，计费不能只看接口返回里的 usage 字段，更不能只依赖普通访问日志。
服务端需要一个不可变或可对账的 usage ledger，至少记录：
| 字段 | 作用 |
|---|---|
| request_id | 幂等落账，避免重试重复扣费 |
| tenant_id / api_key_id | 归属客户和调用凭证 |
| model_alias / upstream_model | 对外模型名和实际推理模型 |
| prompt_tokens / completion_tokens | 输入和输出 token 分开计价 |
| cached_prompt_tokens | prefix cache 折扣和成本核算 |
| latency_ttft / latency_total | 性能和 SLA 统计 |
| status / finish_reason | 成功、失败、超时、取消和内容过滤 |
| charge_policy_version | 扣费规则可追溯 |
| charge_status | pending、charged、waived 或 failed |
流式请求尤其要小心。最终 chunk 没返回、客户端断开、上游超时、平台故障，这些情况是否扣费，必须提前写进规则。
否则 Token 工厂最先出问题的不是推理，而是对账。
8. Phase 1 可以承诺什么
不管是 RAG 智能体还是 Token 工厂，第一阶段都应该克制承诺。
企业 RAG 智能体 Phase 1 可以承诺：
| 可以承诺 | 不应承诺 |
|---|---|
| Internal/Web 两类智能体 | 无限联网问答 |
| 文档入库、检索、引用、拒答 | 千万级向量和高并发 P99 |
| NewAPI + Adapter + RAGFlow + vLLM 闭环 | 自研完整 RAG 平台 |
| Codex tool_calls 保真验收 | 所有模型工具调用天然兼容 |
| usage、sources、trace、audit | 金融级账务和复杂多地域 |
Token 工厂 Phase 1 可以承诺：
| 可以承诺 | 不应承诺 |
|---|---|
| 单集群、1-2 个模型、静态 vLLM | 公网通用模型平台 |
| API Key、额度、模型渠道、价格表 | 自动 GPU 调度和百模型市场 |
| Model Gateway、Router、usage ledger | 训练、微调、对齐平台 |
| 流式收尾落账和失败扣费规则 | OpenAI 全量产品语义 |
| TTFT、TPOT、tokens/s、GPU 利用率 | DeepSeek/OpenAI 级生态 |
克制不是保守，而是让产品承诺和工程能力对齐。
9. 推荐的商业路线
企业 RAG 智能体可以按能力包来包装，而不是按模型名来卖。
| 产品包 | 适合客户 | 收费口径 |
|---|---|---|
| 基础知识库问答包 | 单部门、中小团队 | 知识库数量、席位、调用量 |
| 企业内部智能体包 | IT、研发、运维、客服 | 项目制 + 年费 + 调用量 |
| 联网增强智能体包 | 研究、政策、售前、市场 | 年费 + 联网检索用量 |
| 私有化部署包 | 政企、金融、制造 | 一次性交付 + 运维服务 |
| 行业知识包 | 特定行业客户 | 行业模板 + 持续更新 |
| API 集成包 | 有自研系统客户 | API 调用量 + 技术支持 |
这样包装的好处是，客户购买的是业务结果，而不是某个模型后缀。
模型可以升级，检索策略可以演进，RAGFlow 后端可以从 Elasticsearch 切到 Infinity 或 Milvus，但产品价值仍然稳定。
10. 小结
企业 RAG 智能体和 Token 工厂都可以成为产品，但它们不是同一个产品。
RAG 智能体卖的是企业知识服务：引用可信、权限隔离、证据门、可控联网、反馈修复和审计计费。
Token 工厂卖的是模型推理服务：模型 API、token、并发、SLA、usage ledger、成本核算和推理运行时。
它们可以共享底座，但不能混淆承诺。RAGFlow 不应该被改造成 Token 工厂，vLLM 不应该被描述成知识库，NewAPI 也不应该被包装成完整智算中心。
我认为这是这个项目最有价值的收敛：避开“我要做一个公网大模型平台”的重资产叙事，回到企业真正会付费、也真正需要治理的地方。
企业不是缺一个会聊天的模型，而是缺一个能把知识、权限、来源、审计和成本放进同一条链路的智能体系统。
