背景：每个团队都在重复接模型
2024 年之后，几乎每个业务线都想做自己的 AI 功能。做法也很像：申请一个模型 Key，写一段提示词，接一个向量库，再做一个聊天窗口。demo 很快，但一旦要上线，问题就集中爆发：提示词散落在代码里、知识库没有权限、回答无法追溯、成本没人管、模型一升级效果就漂移。
平台化的目标不是做一个“万能聊天框”，而是把可复用的部分抽出来：模型接入、检索、Agent 运行时、评测和治理。业务团队只需要描述自己的数据和工具，剩下的交给平台。
核心难点
- 幻觉与可追溯：答案必须能回到原始文档和具体片段，而不是一段看起来合理的文本。
- 权限与多租户：检索前就要做权限过滤，不能先召回再过滤，否则等于把数据暴露给了模型。
- 延迟与成本：一次问答可能包含改写、检索、重排、生成多个步骤，必须做缓存、并发控制和模型分级。
- 评测与灰度：模型、提示词、切片策略、重排模型任一变化都要可比较，不能靠感觉上线。
方案：四层拆开
1. 统一模型网关
所有调用经过网关：模型路由、租户配额、超时重试、降级兜底、内容安全与审计。业务不直接持有模型 Key，换模型时只改路由配置。对高价值请求走更强模型，对摘要、分类等任务走小模型，成本可以差一个数量级。
2. RAG 管道
文档解析、清洗、切片、元数据抽取、向量化、混合检索、重排、引用拼装。切片不是越小越好：要保留标题层级和上下文，表格与扫描件单独处理。检索采用向量 + 关键词的混合方式，再用重排模型收敛 top-k，最后把引用和页码一并返回。
3. Agent 运行时
工具注册、参数校验、最大步数、超时、人工确认和沙箱执行。Agent 的权限边界必须比人更窄：能查什么、能改什么、哪些动作必须二次确认，都要在运行时强制执行，而不是写在提示词里。
4. 评测与可观测
离线评测集覆盖高频问题和边界问题；线上记录 trace、检索命中、token 消耗、失败原因和用户反馈。每次发布 prompt 或模型都跑一遍回归，指标不达标就不放量。灰度按租户和流量比例推进，保留一键回退。
结果
平台把“接一个 AI 功能”从每个团队各自摸索，变成一套可复用的接入流程：统一鉴权、统一检索、统一评测、统一成本口径。业务侧关注自己的数据和场景，平台侧关注稳定性、效果与治理。
更重要的是，答案开始带引用、请求开始有 trace、成本开始按租户可查。只有这些基础设施到位，AI 功能才谈得上“上线”，而不是“演示”。
复盘
AI 平台最容易犯的错，是把模型能力当成产品能力。模型只是其中一层，真正决定能不能落地的是数据治理、权限、评测和运维。平台不追求支持所有模型和所有玩法，而是把最高频的三件事做稳：查得准、答得可追溯、成本可控。