企业引入一套多模型 AI 工作台时最容易先被界面吸引。截图里同时出现 Luna、Terra、Sol 三个模型入口并展示了AI 聊天、多模型协作、无限画布、适用场景和更新一览。产品、研发、运营和设计团队很快产生各自的使用设想有人想让 Luna 处理日常问答有人准备把 Terra 接入企业知识库有人希望用 Sol 完成复杂分析还有人打算在无限画布里串联三个模型。真正进入企业环境后问题却不再是“哪个按钮更好用”。安全团队会问这三个名称对应的是底层模型、路由别名还是不同服务等级财务团队会问多模型协作的一次任务产生了几次调用费用应该分摊给哪个部门平台团队会问所有请求是否经过统一 AI API还是每个客户端分别保存供应商 Key审计团队会问一次画布运行经过了哪些节点、读取了哪个向量库、使用了哪一版模型是否可以完整还原业务团队则会问为什么市场部可以选择 Sol客服部只能使用 Luna模型更新后原来的工作流是否还会得到相同结果这些问题说明多模型体系不是在单模型系统上增加两个下拉选项而是同时扩大了路由、权限、成本、数据和变更管理的复杂度。本文把截图中的 Luna、Terra、Sol 视为企业接入层中的三个模型别名不将它们表述为已经核验的 OpenAI 官方型号或固定能力等级。企业真正需要管理的不是名称本身而是名称背后的供应商、模型快照、数据规则、预算限制和责任主体。一、先拆开截图里的六类能力不要把它们当成一个功能截图中的三模型定位、AI 聊天、多模型协作、无限画布、适用场景和更新一览看起来属于同一套产品实际上对应六种不同的企业控制对象。1. 三模型定位对应模型目录与路由策略。企业需要知道 Luna、Terra、Sol 分别允许处理什么任务、什么数据、使用哪些工具以及消耗多大预算。2. AI 聊天对应单轮或多轮会话治理涉及用户身份、历史消息、文件上传、模型选择、上下文长度、内容过滤和日志留存。3. 多模型协作对应流程编排治理。一个任务可能先由 Luna 分类再由 Terra 检索和归纳最后由 Sol 审核。每一步都可能产生独立费用、数据副本和审计记录。4. 无限画布对应可视化工作流资产。画布里的节点、连线、提示词、上传文件、模型输出和工具参数都需要版本与权限而不能只保存成某位员工的私人草稿。5. 适用场景对应模型白名单。企业不能仅根据产品界面的推荐标签决定模型使用范围而要把内部评测、数据等级、任务风险和成本要求写入策略。6. 更新一览对应变更管理。模型别名背后的快照、能力、价格、上下文、工具调用或安全规则发生变化时必须触发测试、审批、灰度和发布记录。如果不先拆开这六类能力企业很容易产生一种错误印象只要部署统一工作台模型治理就会自动完成。实际上工作台主要解决交互入口企业仍需建立自己的身份、路由、预算、数据和审计控制面。二、三模型定位把 Luna、Terra、Sol 变成策略别名企业不应让业务应用直接依赖供应商的真实模型 ID也不应仅凭“轻量、均衡、旗舰”之类的介绍建立长期架构。更稳妥的做法是把 Luna、Terra、Sol 定义为内部模型别名。Luna高频、低风险、成本敏感路线Luna 可以承担内部文案改写、会议摘要、简单分类、代码解释和客服回复草稿等任务。它适合作为多数部门的默认入口但“默认”不代表不受控制。Luna 同样需要数据等级、工具权限、上下文和预算限制。Terra知识密集型路线Terra 可以承担企业知识问答、文档比对、长材料归纳、RAG 回答和带引用的研究任务。它通常需要访问向量引擎因此除了模型权限还必须验证调用者是否有权检索相应的 collection、namespace 和文档。Sol复杂推理和高价值任务路线Sol 可以用于架构评审、风险分析、跨文档决策、复杂代码审查和需要多步骤工具调用的任务。它不应被简单定义为“所有任务都更好”。如果简单改写也默认走 Sol企业会增加成本、延迟和治理负担。这种三模型定位只是初始假设不是名称天然保证的能力。企业必须使用自己的业务样本验证准确率、引用质量、响应延迟、输出长度、工具调用成功率和单位业务成本。模型目录至少应包含以下信息alias:terradisplay_name:Terrapolicy_version:2026-07-15.1provider:provider-aupstream_model:model-snapshot-xallowed_data_classes:-public-internalcapabilities:chat:truerag:truetools:truecanvas_node:truelimits:max_output_tokens:4000timeout_ms:30000daily_budget:1200fallback:alias:luna应用只提交modelluna、modelterra或modelsol统一网关负责把别名解析为实际供应商和模型。日志则同时记录用户请求的别名、命中的策略版本和真实上游模型。这样做有三个直接好处供应商或模型快照变化时业务代码不需要整体修改同一个别名可以在测试与生产环境采用不同路线审计可以分别回答“用户选择了什么”和“系统最终调用了什么”。如果用户选择 Terra但由于限流回退到 Luna日志必须同时保留原始选择、路由结果和回退原因。否则出现质量争议时团队无法判断问题来自用户选择、模型差异还是平台降级。三、不同部门如何选择 Luna、Terra、Sol模型选择不宜完全开放也不能由平台团队一刀切。更合理的方式是由业务价值、数据风险、任务复杂度和结果责任共同决定。部门Luna 默认任务Terra 受控任务Sol 审批任务市场改写、摘要、公开文案长报告、竞品研究品牌或战略分析客服分类、草稿、会话摘要RAG 政策问答少量复杂复盘研发代码解释、测试草稿技术文档、跨文件分析架构评审、复杂审查法务格式整理条款检索、制度比对复杂风险研判财务文本整理制度问答、报表说明情景分析人力资源公开招聘文案内部制度检索原则上不默认开放研究团队快速实验知识密集型分析复杂研究与验证市场部门标题草拟、活动文案、社交媒体改写和公开资料整理可以默认走 Luna。涉及品牌策略、长篇竞品研究或多份报告综合时可以申请 Terra。Sol 只用于少量高价值决策材料并要求人工复核。客服部门意图分类、回复草稿和会话摘要可以使用 Luna需要检索产品政策、订单规则和历史知识时使用 Terra并强制附带知识来源。客服不应默认开放 Sol因为更强的生成能力不能替代业务规则反而可能增加延迟和成本。涉及退款、补偿或工单创建时无论使用哪个模型都必须经过工具权限和幂等校验。研发部门研发可以使用 Luna 解释代码、生成测试样例和整理日志使用 Terra 检索内部技术文档、分析跨文件上下文使用 Sol 处理复杂架构权衡、重大故障复盘和高风险代码审查。访问源代码的模型必须满足对应数据等级不能因为能力更强就自动获得代码库权限。法务与合规部门Terra 可以用于合同条款检索、制度比对和引用定位Sol 可以用于复杂风险分析。Luna 可以承担格式整理但不能作为最终法律判断。此类任务应禁用未经批准的外部工具并对文件、会话和日志设置更严格的保留策略。财务与人力资源部门财务部门可以让 Luna 完成表述优化让 Terra 检索财务制度和解释口径让 Sol 协助复杂情景分析。人力资源部门可以使用 Luna 生成公开招聘文案使用 Terra 检索内部制度但候选人简历、绩效和健康信息必须经过专门审批。模型不能直接给出影响个人权益的最终决定。这套部门定位不是永久权限而是模型白名单的起点。最终开放范围仍要通过企业评测、数据分类和风险审查决定。如果某个部门认为 Luna 质量不够不能只凭主观体验申请 Sol。申请材料至少应包含代表性任务、当前失败样例、目标指标、预计调用量、数据等级和人工复核方案。四、统一 AI API 入口不要让三个模型形成三套接入方式多模型体系常见的第一种失控方式是每个团队直接获取供应商 API Key。研发把 Key 写入服务端环境变量运营填进 AI 聊天工具设计团队在无限画布中配置另一把 KeyDify 工作流再保存第三份 Key。几个月后企业无法准确回答有多少凭据、谁在使用、哪些请求属于哪个部门。统一 AI API 入口的目标是让所有客户端只认识企业内部 Base URL 和虚拟 Key。典型调用链如下、用户或应用↓企业身份认证↓统一 AI API 网关↓策略引擎↓Luna / Terra / Sol 路由↓真实上游供应商网关至少承担六项职责验证人员身份或工作负载身份把虚拟 Key 映射到团队、项目、应用和环境校验模型白名单、数据等级和工具权限执行预算、速率、并发、上下文和重试限制记录审计字段、路由结果和成本数据隐藏并轮换真实供应商 Key。对于 OpenAI 兼容客户端可以提供以下配置Base URL: https://api.vectorengine.cn/v1 API Key: 企业签发的虚拟 Key Model: luna / terra / sol具体 Base URL究竟填写服务根地址、/v1前缀还是完整端点必须根据客户端实际拼接行为验证。某些 SDK 会自动追加/chat/completions某些客户端则要求填写完整端点。若配置错误可能产生重复/v1、请求到服务根目录或者出现model_not_found。统一入口还应定义稳定的内部错误语义。供应商返回的invalid_api_key、model_not_found、timeout、rate_limit和context_length_exceeded可以保留在诊断字段中但业务应用应依赖企业内部错误分类。统一入口也不能只是简单的反向代理。如果网关只转发请求却不了解身份、模型、预算和数据等级它只是把风险集中到一个地址并没有建立治理能力。五、团队 Key把共享密钥改造成可追责的虚拟身份所谓团队 Key不应是一串发到群里、所有人共同使用的长期密钥。真正可治理的团队 Key 更接近一种虚拟凭据。它由企业网关签发背后绑定团队、应用、项目、环境、模型白名单、速率、预算和到期时间。供应商真实 Key 始终保存在网关或密钥管理系统中。例如{team:customer-service,project:support-copilot,environment:production,allowed_models:[luna,terra],denied_tools:[issue_refund],data_class_max:internal,monthly_budget:3000,rpm:120,expires_at:2026-10-15}生产应用、测试环境、个人实验和无限画布不应共享同一把 Key。否则一处泄漏会影响全部业务预算也无法正确归属。团队 Key 至少要满足以下控制要求能够单独创建、轮换、冻结和撤销默认设置到期时间只在创建时显示一次完整值在界面和日志中始终掩码绑定网络、工作负载身份或使用场景不允许客户端自行提高模型权限和预算撤销后立即执行负向测试离职、项目结束或供应商退出时自动回收支持双 Key 过渡避免轮换造成停机。个人在 Cursor、Chatbox、Cherry Studio 等桌面工具中使用时最好通过企业单点登录换取短期令牌而不是获得长期供应商 Key。Dify 等平台则使用专门的工作负载身份并按工作区或应用隔离。团队 Key 的审计重点不只是“由谁创建”还包括“谁批准它使用 Sol”“为什么预算被提高”“哪次变更扩大了允许处理的数据等级”。六、模型白名单不能只写允许 Luna、Terra、Sol模型白名单如果只是一个名称数组治理能力仍然很弱。企业需要把模型、部门、任务、数据、工具和环境联合起来。例如市场团队在公开文案任务中可以使用 Luna客服生产环境可以使用 Luna 和 Terra但 Terra 必须启用知识库引用法务可以在受控工作区使用 Sol但不能调用外部搜索工具人力资源系统不能向未经批准的模型上传候选人敏感信息。一次策略判断至少应包含以下问题调用者是谁属于哪个部门、项目和环境请求选择哪个模型别名数据分类是什么是否上传文件是否使用 RAG是否调用工具是否进入无限画布预计上下文与成本是否超限是否需要人工批准白名单必须版本化。一次“给研发开放 Sol”的变更需要记录申请人、批准人、理由、评测证据、生效时间、到期时间和回滚策略。当更新一览显示 Terra 增加工具调用能力时不能自动把该能力开放给所有已有 Terra 权限的团队。模型访问权和能力访问权应分开。某个团队可以被允许使用 Terra 聊天但不一定被允许让 Terra 调用数据库、代码仓库或工单系统。白名单还应支持紧急熔断。如果发现某个模型快照存在数据泄露风险、错误工具参数或严重质量回退平台需要在不修改业务代码的情况下停止该路线。七、成本控制从 Token 账单转向任务成本多模型协作会让传统账单统计迅速失真。用户在无限画布中运行一个“竞品研究”任务表面上只点击一次后台可能发生以下调用Luna 对问题分类Terra 生成检索查询向量引擎执行多次召回Terra 整理检索资料Sol 完成综合分析Luna 生成最终摘要。如果只按最终节点归属费用大部分成本会丢失。如果只按 API Key 汇总也无法解释费用属于哪个画布、哪个项目和哪个业务目标。每次调用应携带可信成本标签tenant_id department_id project_id application_id workflow_id canvas_id node_id actor_id model_alias cost_center purpose_code这些字段不能全部由客户端自由填写。部门、项目和成本中心应由身份系统或网关策略补齐防止用户把费用标记到其他团队。企业可以建立四层预算企业总预算用于控制整体风险部门预算用于财务分摊项目或应用预算用于识别异常增长单次工作流预算用于阻止无限画布失控。预算控制不应只有允许和拒绝两种结果。更合理的是多级动作达到 60% 时发送趋势提醒达到 80% 时限制非生产批任务达到 90% 时把部分任务从 Sol 降级到 Terra达到硬限制时只保留明确标记的关键业务对异常重试或循环工作流立即暂停。成本比较也不能只看 Token 单价。企业应计算每个成功业务结果的总成本模型调用费 Embedding 费 向量查询费 缓存费 重试费 工具调用费 存储费 人工复核费如果 Sol 单次价格较高但一次即可完成复杂任务而 Luna 需要多轮重试和大量人工修改Sol 的业务结果成本可能更低。反过来如果简单改写也默认使用 Sol能力就会被浪费。八、日志审计一次请求至少要回答十个问题企业 AI 日志不能只保存调用时间、模型名称和 Token 数。一次有效的审计至少要回答谁发起了请求代表个人还是应用属于哪个部门、项目和成本中心用户选择了 Luna、Terra 还是 Sol网关最终调用了哪个供应商和真实模型命中了哪一版路由与白名单策略使用了哪个提示词模板、画布和节点版本是否读取向量引擎读取了哪个数据域是否调用工具工具是否产生业务副作用请求最终成功、回退、拒绝还是超时建议的日志字段可以分为六组。身份字段request_id、trace_id、actor_type、actor_id、team_id、application_id路由字段requested_alias、resolved_provider、resolved_model、routing_policy_version、fallback_reason成本字段输入 Token、输出 Token、缓存命中、Embedding 数量、重试次数、估算成本、成本中心数据字段数据等级、文件数量、个人信息标记、向量 collection、namespace、检索文档标识工具字段工具名称、Schema 版本、批准主体、幂等键、执行结果、业务单号安全字段策略判定、命中规则、脱敏状态、错误分类、日志保留级别日志不能保存完整 API Key、Authorization 头、Cookie 或连接密钥。提示词和回答也不应默认全文记录。普通运行日志可以保存长度、哈希、分类、模板版本和受控对象引用只有经过批准的短期调试窗口才保存脱敏样本。多模型协作还要求保留父子调用关系。一次画布运行应有统一trace_id每个模型节点拥有独立span_id并记录父节点。这样才能还原 Luna 如何把结果交给 TerraTerra 又如何触发 Sol。审计日志本身也要受控。谁查询、导出或删除日志都应产生新的审计记录。关键证据可以计算校验值避免事后无痕修改。九、向量引擎数据边界模型权限不等于知识权限企业常见误区是某个团队有权使用 Terra就默认它可以检索全部知识库。模型权限与数据权限必须分开。模型白名单决定调用者能否使用 Luna、Terra 或 Sol向量引擎权限决定调用者能检索哪些 collection、namespace、文档标签和租户数据。两者需要在网关或检索服务中交叉校验。推荐把向量数据边界分为四层租户边界不同法人、客户或业务租户必须隔离部门边界法务、财务、人力资源和研发知识不能默认互通项目边界同一部门中的不同项目也可能有保密要求文档级边界检索结果必须继承源文档的权限、有效期和删除状态。collection 和 namespace 可以帮助组织数据但客户端提交的 namespace 不能直接被信任。服务端应根据调用身份计算允许范围并把过滤条件强制加入查询。还要执行负向测试市场团队能否通过修改参数检索财务 namespace普通员工能否在无限画布里连接法务知识库Sol 是否因为承担复杂任务就自动获得更广数据权限导出的检索日志是否暴露完整文档片段。Embedding 本身也属于派生数据。删除原文时必须同步处理切片、向量、缓存、检索日志和备份策略。更换 Embedding 模型时新旧向量不能因为维度相同就混在一个索引中应创建独立版本并重新评测召回。知识库写入也需要边界。上传到 AI 聊天的临时文件不能未经批准自动进入长期向量库无限画布中的附件不能因为连接了 RAG 节点就自动成为全团队知识模型生成内容进入知识库前需要来源、质量和有效期标记。十、多模型协作把模型链当作数据处理链多模型协作的优势是让不同模型承担擅长的任务。它的风险是数据在节点之间被复制、扩展和重新解释。一个合理的协作链可以是Luna分类并压缩问题 ↓ Terra检索企业知识并生成带引用草稿 ↓ Sol完成复杂分析和冲突检查 ↓ Luna生成适合用户阅读的最终表达每个节点都应定义输入、输出、允许数据、最大成本和失败动作。如果 Terra 已经读取内部知识传给 Sol 的内容应进行最小化而不是把全部原始文档继续传递。如果 Sol 不允许处理某种数据等级工作流必须在节点边界拒绝而不是依赖模型自行忽略。多模型链还要防止循环。无限画布中可能出现 A 节点触发 BB 又根据条件返回 A。平台应限制最大节点数最大模型调用数最大递归深度总执行时间单次工作流总预算。工具调用必须单独授权。Luna 可以生成查询意图不代表 Terra 可以读取数据库Terra 可以整理数据也不代表 Sol 可以提交审批。模型节点只生成结构化意图可信执行器校验权限、参数和幂等键后再执行。协作链的质量评估不能只看最终答案还要观察每个节点是否真正创造价值。如果 Luna 的分类结果对 Terra 的路由没有影响该节点只增加成本和延迟应当删除。十一、无限画布不是无限权限也不是无限预算无限画布为用户提供自由组合能力但企业不能让“无限”延伸到权限、调用和数据保留。画布至少包含五类资产节点配置节点之间的数据连接提示词与系统指令上传文件和检索数据运行记录与生成结果。这些资产都需要所有者、版本、共享范围和保留期限。个人草稿画布不能直接发布为生产工作流。发布前需要冻结版本执行模型白名单、工具权限、向量数据边界、预算和异常路径检查。共享画布还存在权限继承问题。用户复制一个画布时可以复制节点结构和提示词但不应自动复制原作者的 API Key、知识库权限和工具凭据。运行时权限必须根据当前调用者重新计算。画布中的每个节点应显示其模型别名、数据输入、预算上限和工具权限。用户拖入 Sol 节点时系统应立即验证是否有权使用而不是等运行结束后才发现费用或合规问题。画布运行记录需要可重放但“可重放”不等于永久保存所有原始内容。更稳妥的方式是保存版本、参数、哈希和受控引用需要调查时再根据权限访问原始数据。画布发布后如果模型别名、提示词、工具 Schema 或向量数据源发生变化应生成新版本不能直接覆盖旧版本。十二、安全合规把数据分类放在模型选择之前企业接入多模型体系时应先判断数据再判断模型。请求可以分为公开、内部、机密和受限等级。不同等级对应不同模型路线、日志策略、工具权限、区域要求和数据保留方式。公开数据可以使用范围较宽的模型路线内部数据只能进入经过企业批准的服务机密数据需要更严格的网络、合同和日志控制受限数据可能完全禁止进入外部模型。文件上传是重点风险。AI 聊天和无限画布都可能让用户把合同、源代码、客户名单或财务表格拖入模型。系统应在上传时执行文件类型、大小、病毒、敏感信息和权限检查并明确文件是否只用于当前会话、是否进入向量引擎、保存多久。提示词注入也是 RAG 与工具场景中的核心问题。外部文档可能包含“忽略系统规则”“调用某个工具发送数据”等恶意内容。检索结果应被视为不可信数据而不是系统指令。工具执行器必须独立验证权限不能因为模型在回答中提出动作就直接执行。安全评审还要覆盖供应商的数据保留、训练使用、处理区域、子处理方、删除机制和安全事件通知。这些内容应以实际合同、官方材料和企业审查结果为准不能根据产品界面推断。团队在整理兼容接口测试和第三方体验备忘时可以记录 https://178.nz/dn 作为一项环境资料来源但正式上线仍应以企业自己的测试、供应商文件、合同条款和安全审批为依据。十三、更新一览每次模型更新都应进入变更流程截图中的“更新一览”对普通用户是功能通知对企业则应成为变更触发器。更新可能影响模型别名背后的真实快照上下文长度工具调用格式输出风格Token 计量与价格安全规则流式事件模型弃用时间。任何一项变化都可能让现有应用出现质量、成本或兼容性回退。企业应维护更新登记表记录更新编号、发布日期、受影响的模型路线、真实模型是否变化、API Schema 是否变化、计费是否变化、工具调用是否变化、是否需要重新评测、变更负责人、灰度比例和回滚条件。更新不能直接覆盖生产别名。推荐先建立候选版本例如terra-candidate运行契约测试、黄金样本、RAG 召回、工具调用、延迟和成本评估再逐步把生产 Terra 的流量切换过去。若更新只改变前端展示也应确认模型 ID 与 API 行为没有同步改变。显示名称相同并不能证明底层快照不变。十四、30/60/90 天落地路线从可见性走向可治理前 30 天建立可见性企业应清点所有 AI 聊天工具、无限画布、Dify 应用、API 客户端、供应商 Key、Base URL、模型别名、向量库和责任人。为 Luna、Terra、Sol 建立初始模型目录和部门使用假设。选择客服、研发和法务三个代表场景建立脱敏评测集。同时禁止新增共享供应商 Key所有新接入都通过统一网关。旧 Key 先完成登记避免一次性迁移影响生产业务。第 31 至 60 天形成控制面上线虚拟团队 Key、模型白名单、部门预算和基础审计日志。让 AI 聊天、多模型协作和无限画布统一携带身份、项目与成本标签把向量引擎权限从客户端参数迁移到服务端策略。对 Luna、Terra、Sol 分别运行质量、延迟、工具调用、RAG 和成本评测。根据结果调整部门白名单而不是直接沿用产品界面的推荐场景。第 61 至 90 天验证治理能力选择一个多模型画布执行完整演练撤销团队 Key阻断越权模型触发预算降级模拟模型更新检查日志证据尝试跨 namespace 检索验证旧模型路线可以回滚。90 天验收至少应回答所有生产调用是否经过统一 AI API是否仍存在无法归属的共享 Key每个部门能否看到自己的预算与成本模型白名单是否能在网关层强制执行一次多模型协作是否能够完整还原向量数据是否通过跨部门负向测试模型更新是否可以灰度和回滚文件、日志和索引是否具有明确删除路径如果这些问题仍然无法回答企业只是部署了多模型产品还没有建立多模型治理能力。十五、结论三模型体系的核心不是多而是可治理Luna、Terra、Sol 可以为企业提供不同的能力和成本选择AI 聊天降低使用门槛多模型协作可以拆分复杂任务无限画布可以加快流程设计。但这些功能只有进入统一治理框架后才会形成企业能力。企业应当把三模型定位转化为版本化模型别名把适用场景转化为部门模型白名单把团队 Key 转化为可撤销的虚拟身份把 Token 账单转化为业务任务成本把聊天和画布记录转化为最小化审计证据把向量引擎中的 collection 和 namespace 转化为经过验证的数据边界把更新一览转化为测试、灰度和回滚流程。多模型体系最危险的状态不是某个模型偶尔回答错误而是企业不知道谁调用了它、它读取了什么、花了谁的预算、经过了哪些节点以及出现问题后如何停止。真正成熟的多模型平台不是让所有人不受限制地选择 Luna、Terra、Sol而是在不妨碍合理创新的前提下让每一次选择都有权限依据、成本归属、数据边界和审计证据。