企业 AI 平台怎么搭：从模型接入到业务闭环的分层设计

企业做 AI 平台，最容易出现的误区是先搭一个“模型门户”，把模型列表、密钥和聊天页面放在一起，然后等待业务自己找到用法。真正进入生产后，团队需要解决的却是另一组问题：数据能不能被安全使用，模型输出能不能被评测，Agent 能不能调用业务系统，成本和故障能不能定位。

平台的价值是把一次项目里反复出现的能力沉淀下来，让业务团队专注于任务和流程。平台边界应围绕可复用能力划分，而不是围绕某个模型或某个项目划分。

六层平台模型

可以把企业 AI 平台拆成六层：

这六层可以共享基础设施，但不应该把所有逻辑塞进一个“AI 服务”里。清晰的层次有助于定位问题：答案错误可能来自材料版本、召回、提示词、模型，也可能来自工具返回的数据，排查时不能只盯着模型。

数据层先建立可追溯性

平台接入数据时，需要同时记录内容、来源和使用范围。一个文档至少应有来源系统、业务空间、版本、生效时间、失效时间、保密级别和访问主体。只保存一段文本而没有这些元数据，后续很难处理版本冲突和权限过滤。

数据处理最好是可重复的流水线：原始文件保留不可变快照，中间产物记录处理器版本，最终索引可以从指定快照重建。这样当用户问“为什么上周的答案和今天不同”时，平台能还原当时使用的材料，而不是只能猜测。

模型层关注路由和契约

模型层不只是保存 API 地址。平台需要统一请求和响应结构，包括模型标识、版本、输入输出 token、延迟、错误码和安全策略。业务应用通过统一接口调用模型，避免把某个供应商的字段直接扩散到每个项目。

模型路由可以参考任务难度、数据敏感级别、延迟目标和预算。路由结果也要进入 trace，方便解释为什么这次调用选择了某个模型。对模型能力的描述要以可测试的契约为准，例如结构化输出通过率、上下文长度和工具调用格式，而不是只写一个“强模型”的标签。

知识层不要只追求召回数量

知识库的质量不等于向量库里有多少条记录。一个可用的知识层至少要处理：

1. 文档结构：标题、段落、表格和附件关系不能在切分时全部丢失。
2. 版本和权限：检索候选必须先过滤可访问范围，再进行排序。
3. 证据引用：答案中的事实要能关联到具体文档和片段。
4. 更新和删除：源文档失效后，缓存、索引和引用都要同步处理。

检索参数、重排器和知识快照都应该可配置、可版本化。评测时固定这些条件，才能判断是模型变化还是知识链路变化导致结果不同。

推理层分开工作流和 Agent

固定顺序的步骤使用工作流表达，条件分支和重试规则写在代码里；只有在需要理解自然语言目标、选择资料或决定下一步时，才使用 Agent。两者可以组合：工作流负责边界，Agent 负责其中一个受约束的决策节点。

平台应提供统一的任务对象和执行记录：任务输入、步骤状态、模型调用、检索证据、工具调用和最终结果都能关联起来。这样业务应用不需要各自实现一套日志，也能在平台侧复现一个任务。

评测层必须和发布流程连接

评测不是项目结束时的一次打分。平台应支持三类数据集：代表日常流量的回归集，覆盖高风险边界的安全集，以及来自线上失败案例的修复集。每次提示词、模型、检索策略或工具改动，都使用固定数据集跑对比。

指标要分层记录，例如检索是否找到证据、答案是否引用正确、工具参数是否有效、任务是否完成、延迟和成本是否达标。一个总分可以用于趋势观察，但不能替代这些分项结果。评测结果还应能定位到具体的 trace 和材料版本。

运营层把成本和风险变成可见数据

生产运营至少需要看到四类视图：请求量和错误率，端到端延迟和各步骤耗时，token 与工具成本，安全策略命中和人工审批情况。对 Agent 来说，一次请求可能包含多轮模型调用和多个工具调用，只看 HTTP 成功率会掩盖真正的问题。

发布可以采用灰度方式：先对内部用户开放，再扩大到指定业务空间；为新版本设置自动回滚条件；对关键任务保留旧流程作为降级路径。运营系统中的每一条指标都应该能回到任务和版本，避免只留下无法解释的曲线。

用平台能力支撑第一个业务闭环

平台不需要一开始就覆盖所有模型、所有数据源和所有 Agent 形态。可以先选择一条业务链路，打通统一模型调用、一个知识源、两个工具、基础评测和 trace，然后再从真实失败中补齐能力。

好的平台会让新项目更快开始，也让旧项目更容易被替换和审计。它的边界不是“能调用多少模型”，而是能否让数据、推理、评测和运营形成一条稳定的工程链路。