企业官网建设流程全解析

企业里做 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）”混淆。这里需要做一个边界区分。

简单说，模型网关解决的是“怎么连上模型”，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(default=None), ): # 1. 生成统一请求 ID，用于链路追踪 request_id = x_request_id or str(uuid.uuid4()) # 2. 解析请求体 body = await request.json() # 3. 调用策略服务，决定路由目标 route_result = await policy_service.evaluate( service_id=x_service_id, prompt=body.get("prompt"), request_id=request_id, ) if not route_result["allowed"]: raise HTTPException(status_code=403, 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_id=request_id, service_id=x_service_id, model=route_result["model"], status=resp.status_code, usage=resp.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:00+08: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 软件公司，要给客户提供“智能客服”功能。客服需要回答的问题分三类：

1. 产品功能问题：走公开产品文档 RAG；
2. 订单/合同问题：走 CRM 数据 + 私有知识库，需要客户权限校验；
3. 法务合规问题：只有法务部门的人可以问，且模型调用需要审批。

在没有编排层之前，这个客服系统要自己实现权限、路由、审计、模型切换，代码非常啰嗦。引入编排层之后，业务系统只负责接收问题、展示答案，剩下的路由和治理交给平台。

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, json=payload, headers=headers, timeout=60) 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 平台落地时高频遇到的问题，以及排查方向。

排查这类问题时，最重要的是保证 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 工程化竞争中建立真正的壁垒。