企业里做 AI 落地很多团队可能都有过这样的体会大模型本身越来越强模型选择也越来越多但真正把 AI 接进业务系统时问题反而不在模型而在模型外围的“脏活累活”。用户要审阅哪份数据、该调用哪个模型、一次请求要经过哪些校验、怎么留痕审计、成本怎么分摊、模型升级了怎么平滑切换……这些事如果全靠业务系统自己实现每个项目重复造轮子团队很快就会失控。“Show HN: Sixb – the operating layer for enterprise AI” 这个项目想解决的正是这一类问题。本文不涉及 Sixb 的具体安装和私有 API 细节而是围绕它提出的“operating layer运营/操作层”理念拆解企业 AI 落地时这层“控制面”到底是什么、为什么需要、以及工程上如何落地。适合正在做企业级 AI 平台、AI 中台或者准备把大模型能力对接到生产系统的后端开发、AI 平台工程师、架构师阅读。1. 为什么企业 AI 需要“operating layer”1.1 模型能力过剩编排能力不足过去两年大模型的能力在快速膨胀但企业真正用它解决生产问题时最卡脖子的往往不是“模型不够聪明”而是“不知道怎么把模型安全地接入业务”。举个例子一个智能客服系统看起来只需要“用户提问 - 调大模型 - 返回回答”但这中间至少还隔着这么几道工序用户问了什么这个问题属于哪个业务域该用通用模型还是走私有知识库的 RAG 流程这个问题能不能直接回答会不会触发敏感数据调用模型时上下文里最多塞多少内容成本要不要控制模型返回的结果要不要做内容安全校验每次请求都要记录 trace出了问题怎么查这些逻辑如果直接写在业务代码里会出现三种局面每个业务线各写一套逻辑重复且版本混乱模型厂商 SDK 一升级所有业务系统跟着改权限、审计、成本这些横切关注点和具体业务逻辑缠绕在一起。换句话说模型只是“算力”真正让 AI 在企业里合法、合规、可控地跑起来还需要一层隔离和编排。这个需求就是 “operating layer” 要回答的问题。1.2 从“点对点集成”到“平台化编排”在没有 operating layer 的时候业务系统和 AI 能力之间是点对点连接。业务系统 A --- OpenAI SDK 业务系统 B --- 私有化大模型 业务系统 C --- 内部向量数据库 RAG这种模式下每个业务系统都要自己理解模型供应商、自己处理鉴权、自己写回退逻辑、自己记日志。系统越多管理成本越高安全风险也越分散。引入 operating layer 之后架构变成了这样业务系统 A -- 业务系统 B ---- Operating Layer -- 模型供应商 1 业务系统 C -- | -- 模型供应商 2 | -- 内部知识库/RAG | -- 企业审批/审计系统业务系统不再直接依赖具体模型而是面向一个统一的服务层。这个服务层负责路由、鉴权、限流、质量校验、审计、成本计量等通用能力。它和 Kubernetes 在微服务架构里的位置有点像K8s 管的是容器编排Sixb 这样的 operating layer 管的则是 AI 应用和模型之间的“编排”。1.3 它和“模型网关”“Agent 编排”有什么区别很多人会把 operating layer 和已有的“模型网关AI Gateway”混淆。这里需要做一个边界区分。概念关注的核心典型能力局限模型网关模型 API 的访问接入多模型路由、负载均衡、API Key 管理、基础限流偏向“网络层”不关心业务语义、权限审批、数据策略Agent 编排框架多步骤任务调度工具调用、Plan 生成、上下文维护偏向“任务层”缺少企业治理能力Operating LayerAI 在企业落地的全流程治理权限、审批、审计、策略、成本、合规、模型路由一体化属于更上层的“治理/运营”闭环简单说模型网关解决的是“怎么连上模型”Agent 编排解决的是“怎么拆解任务”而 operating layer 解决的是“整个 AI 服务怎么在企业里稳定、合规、可审计地运行”。2. 什么是 Sixb企业 AI 的“控制面”2.1 一次 AI 请求的“全旅程”为了理解 operating layer 的职责范围我们可以假设企业里已经部署了 Sixb 这一类编排层看一次用户请求从进入到返回中间会经历哪些环节。用户请求 | v [1] 统一接入网关识别调用方、校验身份 | v [2] 策略引擎该调用方有没有权限访问 AI 服务 | v [3] 语义路由判断该走通用模型/RAG/私有模型 | v [4] 数据准备拼接上下文、按权限过滤数据 | v [5] 模型调用限流、重试、超时控制、成本计数 | v [6] 输出校验内容检测、格式修正、敏感信息过滤 | v [7] 审计与日志完整记录请求、trace、结果、费用 | v 返回业务系统这一整条链路如果由每个业务系统自己实现很难做到统一标准。而 Sixb 这类产品想做的就是把这套链路沉淀成平台能力让业务系统只关注“我要完成什么业务”不关心“底下调了哪个模型、怎么鉴权、怎么审计”。2.2 operating layer 的六大核心能力结合企业 AI 落地的实际痛点我理解这类平台至少需要具备以下六种能力。1统一模型接入与抽象屏蔽底层模型供应商差异业务系统只面向统一 API。无论底层用的是 OpenAI、Claude、国产大模型还是私有化部署的模型上层都不需要感知。业务系统 -- Sixb 统一 API -- 模型供应商 A / B / C / 私有模型2身份、权限与审批这是企业场景和开发者个人场景最大的差异。个人用 API 只需要 Key企业里要控制“谁能调 AI”“能调哪类模型”“调用前要不要走审批”。比如普通研发可以调通用大模型但不能访问带客户数据的 RAG财务部门访问财务知识库前需要部门管理员审批夜间批量任务调用模型需要走预授权的服务账号不能依赖个人 Key。3策略与路由根据请求内容、用户身份、成本预算、模型可用性等因素动态决定这一次请求到底走哪个模型。一条典型的策略可能是if 用户属于普通员工 and 问题属于通用知识: 路由到 便宜的快模型 elif 问题属于合规法务 and 发起人属于法务部: 走审批 - 路由到 最强模型 私有知识库 else: 拒绝访问/提示无权限4可观测性与审计企业 AI 最大的风险不是模型答错而是“模型答错了但你不知道也没法追溯”。operating layer 需要记录每一次请求的发起人、调用服务输入摘要注意隐私过滤路由到的模型模型响应延迟、费用、错误码是否经过人工审批。5安全与合规控制包括输入侧的敏感信息识别、输出侧的内容检测、以及数据驻留data residency控制。例如涉及客户个人信息的请求只能路由到符合合规要求的私有化模型不能发送到公有云模型。6成本治理与配额管理大模型按 token 计费企业 AI 用量上来之后成本治理会变成一个财务问题。operating layer 需要按部门、项目、应用维度计量 token 使用量和费用并且可以设置配额上限。2.3 Sixb 的边界它不做什么理解一个技术平台除了知道它能做什么还要知道它不做什么否则很容易产生错误预期。operating layer 不应该替代以下能力不替代业务系统它不实现“售后工单怎么流转”只提供 AI 服务的编排与治理不替代模型本身它不做微调、不做预训练模型能力仍然来自底层模型供应商不替代数据中台RAG 的数据清洗、切分、向量化仍然需要专门的数据工程operating layer 可以做衔接但不替代采集和建模不替代 Agent 业务逻辑如果要做一个多步骤的智能体业务闭环逻辑仍然要业务方自己编排operating layer 提供承载和治理环境。一句话概括Sixb 这类产品的价值不是让你“更会写提示词”而是让你的 AI 服务在企业里跑得更稳、更合规、更可管。3. 从概念到落地企业 AI 编排层的核心设计理解了 operating layer 的理念之后很多人可能更关心如果我要自己搭一套类似能力或者要为接入 Sixb 做技术准备我该关注哪些模块下面给出一个偏工程视角的拆解。3.1 统一网关层Gateway这是最靠近调用方的一层负责API 认证服务账号、OAuth2、API Key请求解析与规范校验转发到内部策略引擎统一返回结构。这里可以参考下面这个精简的 Python 网关示例仅演示设计思想实际生产建议用 Java Spring Cloud Gateway 或 Go 写高性能网关。# 文件路径gateway/app.py # 说明示例代码演示统一网关的基本拦截逻辑需要按实际框架调整 from fastapi import FastAPI, Header, HTTPException, Request import httpx import uuid app FastAPI() # 模拟一个模型路由地址表 MODEL_ROUTES { general: https://api.llm.internal/general, rag: https://api.llm.internal/rag, private: https://llm.private.internal/completion, } app.post(/v1/ai/completion) async def completion( request: Request, x_service_id: str Header(...), x_request_id: str Header(defaultNone), ): # 1. 生成统一请求 ID用于链路追踪 request_id x_request_id or str(uuid.uuid4()) # 2. 解析请求体 body await request.json() # 3. 调用策略服务决定路由目标 route_result await policy_service.evaluate( service_idx_service_id, promptbody.get(prompt), request_idrequest_id, ) if not route_result[allowed]: raise HTTPException(status_code403, detail无权限访问该模型) target_url MODEL_ROUTES[route_result[model]] # 4. 转发到实际模型服务 async with httpx.AsyncClient() as client: resp await client.post( target_url, json{prompt: body.get(prompt), max_tokens: body.get(max_tokens)}, headers{X-Request-Id: request_id}, ) # 5. 记录审计日志 audit.log( request_idrequest_id, service_idx_service_id, modelroute_result[model], statusresp.status_code, usageresp.json().get(usage, {}), ) return { request_id: request_id, data: resp.json(), model: route_result[model], }实际工程中网关层还需要考虑限流降级策略避免单个调用方打满模型配额超时控制不同模型供应商响应速度差异很大请求/响应脱敏日志中不能存储完整用户个人信息。3.2 策略引擎层Policy Engine策略层是 operating layer 和企业内部权限系统打通的关键模块。常见的策略来源有三类组织架构数据来自 HR 系统 / SSO数据分级标签来自数据中台模型接入策略由 AI 平台管理员配置。策略配置可以用规则引擎实现也可以直接写成配置表。一个简化示例# 文件路径policy/rules.yaml policies: - name: 普通员工-通用模型 subjects: [role:employee] actions: [llm:call] resources: [model:general] effect: allow - name: 法务专用-私有RAG subjects: [role:legal] actions: [llm:call] resources: [model:legal-rag] conditions: requires_approval: true effect: allow - name: 禁止外部服务调用私有模型 subjects: [app:external-partner] actions: [llm:call] resources: [model:private] effect: deny策略引擎的价值在于把“能不能调用某个 AI 能力”这件事从业务代码里抽离出来变成平台可配置的规则。业务系统不需要知道法务私有知识库的权限怎么控只需要在请求时带上调用方身份由策略引擎裁决。3.3 数据与上下文管理企业 AI 应用离不开 RAG而 RAG 落地时最麻烦的问题是数据权限。同一份知识库里不同角色能检索的内容不一样。比如公司规章制度所有人可见但薪酬制度只有 HR 相关角色可见。如果直接在知识库层面做过滤会非常痛苦因为同一份文档的可见范围可能因请求上下文而异。operating layer 在这里可以做一层调用方把用户身份和权限 token 传给编排层编排层在构建检索条件时自动加上权限过滤条件向量检索返回的结果再做一次权限复核防止“检索到但无权看”的数据泄漏给大模型。这里有一个容易被忽略的坑很多团队只在检索时过滤了权限但没有对检索后的上下文内容做二次校验。一旦向量召回逻辑出现漏洞敏感内容仍然可能进入大模型上下文。更安全的做法是检索结果进入模型之前经过一道“字段级脱敏/过滤”的管道。3.4 审计与链路追踪AI 系统的审计和传统接口审计不完全一样。传统审计记录“谁在什么时间调用什么接口”AI 审计还需要记录“输入了什么提示词”“模型返回了什么内容”“检索到了哪些知识片段”。一个简化版的审计数据结构如下{ request_id: 8f14e45f-cea9-4a5a-9b1a-8b2f3c0d5e11, timestamp: 2025-06-18T10:24:0008:00, caller: { service_id: crm-service, user_id: U10023, role: sales }, policy_decision: { allowed: true, policy_name: 普通员工-通用模型 }, model_call: { provider: internal-llm, model: general-v3, prompt_tokens: 1280, completion_tokens: 320, cost_usd: 0.0012, latency_ms: 850 }, rag_retrieval: { source_ids: [doc_alpha_001, doc_alpha_002], filtered_by_permission: true } }这类审计数据至少要保留一段时间同时对接企业 SIEM安全信息与事件管理系统方便安全团队做异常行为分析。4. 一个最小落地方案企业智能客服的编排层改造概念聊完下面用一个具体场景把思路串起来。假设我们是一家 To B 软件公司要给客户提供“智能客服”功能。客服需要回答的问题分三类产品功能问题走公开产品文档 RAG订单/合同问题走 CRM 数据 私有知识库需要客户权限校验法务合规问题只有法务部门的人可以问且模型调用需要审批。在没有编排层之前这个客服系统要自己实现权限、路由、审计、模型切换代码非常啰嗦。引入编排层之后业务系统只负责接收问题、展示答案剩下的路由和治理交给平台。4.1 场景流程设计用户输入问题 | v 客服系统判断问题类型可调用分类模型 | v 构造统一请求调用 operating layer API | v 编排层完成权限校验 - 路由选择 - RAG 检索 - 模型调用 - 输出过滤 | v 返回结构化结果给客服系统4.2 编排配置示例这里给出一个 YAML 形式的编排配置演示“根据问题类型路由到不同流程”的设计思路。# 文件路径orchestration/flow.yaml workflow: name: customer-service-chat version: 1.0 steps: - id: classify type: llm_classify model: classifier-small input: {user_query} output: intent labels: [product, order_contract, legal_compliance, other] - id: route type: router condition: intent: product - rag_product_docs intent: order_contract - rag_crm_data intent: legal_compliance - approval_legal_model intent: other - general_model - id: rag_product_docs type: rag_retrieval datasource: product_docs permission: public - id: rag_crm_data type: rag_retrieval datasource: crm_orders permission: caller_client_owner - id: approval_legal_model type: approval_required approver_role: legal_admin model: strong-private-model - id: output_filter type: content_filter rules: [pii_detection, custom_denylist]4.3 简化版请求代码业务系统只需要向编排层发起一次请求不必关心路由细节。以下是一个 Python 调用示例# 文件路径client/example.py # 说明演示业务侧调用编排层统一 API非 Sixb 官方 SDK import requests import os ORCHESTRATOR_URL os.getenv(ORCHESTRATOR_URL, http://localhost:8080/v1/ai/completion) payload { prompt: 客户 A 的订单 SZ20250618 现在到什么状态了, conversation_id: conv_12345, user: { id: U10023, role: sales, department: sales-dept }, intent: order_contract } headers { X-Service-Id: crm-service, X-Request-Id: req_8f14e45f, } resp requests.post(ORCHESTRATOR_URL, jsonpayload, headersheaders, timeout60) if resp.status_code 200: data resp.json() print(答案:, data[data][completion]) print(模型:, data[model]) print(耗时:, data[latency_ms], ms) print(费用:, data[cost_usd], USD) else: print(请求失败, resp.status_code, resp.text)在这个模型下业务系统只感知到“一个统一的 AI 服务”而真正的模型选择、权限校验、审计、成本计算都收口到了编排层。4.4 这个方案解决了什么通过上述改造至少带来四个直接收益权限逻辑统一客服系统不再自己判断“哪些客户数据能问”编排层统一拦截模型切换不影响业务底层模型升级、供应商切换业务代码不用动审计完整每一次客服回答都能追溯到调用方、输入、模型、RAG 片段成本一目了然按业务线、按天看 token 消耗和费用可以反向推动业务优化提问质量。5. 企业 AI 落地的关键工程问题即使有了 operating layer也不代表万事大吉。真正上线时下面这些问题仍然需要平台团队提前设计。5.1 模型路由与成本治理模型路由不只是简单的“贵模型/便宜模型”切换。实际生产中还需要考虑延迟成本同一个问题不同模型延迟差异可能是 2 倍以上可用性成本一个模型供应商故障要能快速切到备援模型效果成本提问复杂度低时用便宜模型复杂推理才用旗舰模型。建议在配置里把路由策略做成可灰度调整的。不要写死在代码里而是由平台配置中心下发方便随时调整成本策略。5.2 输出安全与幻觉防护幻觉是生成式 AI 在企业落地中绕不开的问题。operating layer 能做的是为 RAG 回答增加“引用来源”标识让使用方知道答案来自哪份文档对关键数据订单号、金额做校验比如让模型返回结构化 JSON再由业务系统做逻辑校验对高风险场景设置“置信度阈值”低置信度回复改为转人工。这里提醒一点不要指望模型输出层做绝对防泄漏。更可靠的手段是在输入层就限制上下文、在权限层阻断敏感数据输出过滤只是最后一道防线。5.3 数据权限隔离数据权限隔离是企业 AI 最容易被攻击的环节。常见问题包括RAG 检索时没有把用户权限传递给检索服务导致返回了用户无权查看的文档片段日志里记录了完整上下文导致敏感数据从日志侧泄漏模型供应商侧数据留存策略没有确认企业数据被第三方模型服务商留存。建议做法权限 token 贯穿整个调用链路日志默认截断输入输出只保留摘要和模型供应商的合同里明确数据留存和删除策略。5.4 灰度发布与回滚模型升级和新功能发布一样需要灰度。一个推荐的发布流程是新模型/新流程 | v 内部种子用户试用占 5% 流量 | v 效果/成本/延迟指标对比 | v 逐步放大到 30% / 60% / 100% | v 出现问题时快速回滚到上一个稳定版本operating layer 因为收口了路由天然具备灰度能力只需要修改路由配置就能控制多少流量走向新模型。6. 常见问题与排查思路下面整理几个企业 AI 平台落地时高频遇到的问题以及排查方向。问题现象常见原因解决思路请求被 403 拒绝调用方身份或角色未同步到策略引擎检查 SSO/用户同步任务确认角色映射某些用户能访问到无权限数据RAG 检索阶段未带上权限上下文或检索后未二次过滤增加上下文字段传递并在组装 prompt 前做权限复核同一问题有时走贵模型、有时走便宜模型路由策略配置了不稳定的分类模型调整分类置信度阈值增加兜底路由规则模型调用延迟飙升上下文过长或多层 RAG 重试优化知识库切片长度开启缓存设置超时上限审计日志里缺请求内容日志脱敏规则把输入输出全部丢弃改为“摘要 原始内容加密存储”策略成本明显超预算没有配额限制下游应用无节制调用按服务设置 token 月配额超限自动降级或阻断模型供应商故障影响所有业务没有做多供应商冗余配置故障转移主供应商超时后自动切备援排查这类问题时最重要的是保证 request_id 贯穿全链路。很多平台出问题查不动就是因为每个环节各自记日志没有统一标识。7. 最佳实践与工程建议结合目前企业 AI 平台的落地经验写几条工程建议供正在做类似架构的同学参考。1权限设计要在第一版就做不要后期补AI 服务的权限不像传统接口那么直观。模型本身也会“透露”输入内容所以权限边界等于“输入数据边界”加上“输出查看边界”。如果一开始不做等业务量大了再补改造面会非常大。2日志与审计要默认脱敏默认策略是完整请求内容加密存储普通日志只记录 token 数量、模型名、延迟、错误信息。只有在需要排查特定 request_id 时才通过授权解密查看原始内容。3把“模型选择”配置化业务代码里不要出现具体模型名。哪怕今天只有一种模型也要通过抽象层调用。否则明天换模型、增加备援模型时会改到怀疑人生。4建立效果评估闭环operating layer 提供了路由、日志、成本数据但模型效果回答质量仍需要专门的评估集。建议团队维护一份覆盖核心场景的评测集每次模型升级、prompt 调整、RAG 参数变化都跑一遍用数据说话而不是靠“感觉回答变好了”。5灰度发布要配套监控指标没有监控的灰度等于裸奔。至少要看这几个指标调用成功率平均延迟 P50/P95无效回答率用户最终是否转人工平均成本。6与安全团队提前对齐合规要求企业 AI 涉及的数据合规、审计留存、跨境数据限制每个公司差异很大。建议 AI 平台团队在方案设计阶段就拉安全和法务团队介入而不是等上线前才补。8. 下一步学习路线如果你对 Sixb 这类 “operating layer” 方向感兴趣可以从以下维度继续深入。第一个方向AI Gateway / 模型路由。可以先从开源的 AI 网关项目入手了解统一模型接入、多供应商切换、限流熔断是怎么实现的。重点学习它的策略配置模型和插件机制。第二个方向RAG 的企业化改造。理解向量检索、混合检索、rerank、权限过滤在 RAG 链路里的位置。企业 RAG 的复杂度通常不在算法而在“数据权限怎么和检索结果对齐”。第三个方向平台工程设计。学习如何设计一个多租户的 AI 服务治理平台包括 API 设计、策略引擎设计、审计链路设计、成本模块设计。这比单纯调模型接口要偏工程得多也是企业 AI 平台工程师的核心竞争力。第四个方向组织与流程。企业 AI 落地不止是技术问题。模型审批流程怎么定、异常由谁负责、成本预算怎么分配、外包和正式员工权限怎么区分……这些问题需要平台团队和业务、安全、法务、财务持续对齐。回到 Sixb 这个项目本身。如果它真的能把“模型路由、权限策略、审计日志、成本治理、审批流程”做成一套开箱即用的平台能力对企业 AI 落地的价值会非常直接。不过需要提醒的是“operating layer” 目前还属于快速演进的细分方向各种产品和开源项目的边界能力差异很大。选型时还是要结合自己企业的技术栈、数据合规要求、现有运维体系来评估不要只看概念新不新。AI 模型的竞争已经非常激烈但模型能力距离企业生产环境之间仍然隔着一层“脏活累活”。谁能把这层做好谁就可能在下一阶段的 AI 工程化竞争中建立真正的壁垒。