企业官网建设流程全解析

一、AI多模型路由

多模型路由（Model Routing）的核心思想，是大厂 AI 产品标配的架构。

豆包这类产品不会把所有请求都丢给同一个模型，而是在网关层做意图识别，然后转发到最适合的后端。

1.1 🧭 路由的决策依据

网关拿到用户请求后，会先做一轮轻量级分类，判断这是什么类型的任务。判断依据通常包括：

• 输入模态：纯文本、图片、音频、视频

• 任务类型：图片识别、图片生成、数学解题、写作、代码、翻译

• 复杂度：简单问答 vs 需要多步推理

• 实时性要求：流式对话 vs 批量处理

• 成本敏感度：免费用户 vs 付费用户

这个分类本身通常用一个小模型或规则引擎完成，不会用大模型来做，因为要控制延迟。

1.2 🏗️ 路由后的后端类型

不同任务会打到不同的服务：

豆包的模型矩阵本身就包含多个专用模型：Doubao-pro（通用）、Doubao-lite（轻量低成本）、Doubao-vision（视觉）、Doubao-embedding（向量）、Seedream（文生图）、Seedance（视频生成）。网关路由就是把这些模型按需分配。

1.3⚙️ 路由的实现层次

第一层：模态路由最简单也最必要。图片请求走视觉模型，纯文本走语言模型。这一层几乎不涉及语义理解，看输入类型就能判断。

第二层：任务路由需要理解用户意图。比如同样是文本，“解这道题”和“写一篇作文”会走不同的模型或不同的 Prompt 模板。这一层通常用分类模型或规则引擎。

第三层：复杂度路由同一个任务类型内部，根据难度分流。简单问题用轻量模型（快、便宜），复杂问题用大模型（慢、贵）。这叫LLM Cascade或Router模式，学术上有 RouteLLM 这类专门研究。

第四层：成本/优先级路由免费用户走轻量模型，付费用户走大模型；或者高峰期降级、低峰期升级。

1.4 🔀 和网关护栏的关系

“护栏部署在网关前侧还是后侧”？和这里的路由是同一个网关的不同职责：

用户请求 ↓ 网关层 ├── 身份认证 ├── 输入护栏（越狱检测、注入检测） ├── 意图分类 + 路由决策 ← 这里 ├── 转发到对应后端 ├── 输出护栏（幻觉检测、敏感信息检测） └── 返回用户

路由决策和护栏检测可以共用同一个轻量级分类模型，也可以分开。

大厂通常会在网关层做一次推理，多个用途——同一个分类结果既用于路由，也用于判断是否需要触发安全策略。

💭 对医学问答 Agent 的启示

目前的医学 Agent 目前是“一个问题 → 一个 RAG 流程 → 一个 Ollama 模型”。如果后续要扩展，可以考虑加一层轻量路由：

• 分诊类问题→ 走规则引擎或小模型，快速返回

• 知识问答→ 走 RAG + qwen2.5:7b

• 用药建议→ 走 RAG + 更大模型 + 强制输出护栏 + 人工审批

• 图片识别（如看化验单）→ 走视觉模型

路由层不需要很重，一个基于规则的分类器或一个小模型就能覆盖大部分场景。关键是把不同风险等级的任务分开处理，高风险任务走更严格的流程。

二、技术路线

这样的网关在实现上，通常不是自己从零写一个 Nginx 或 Spring Cloud Gateway，而是利用已有的 AI 网关开源项目或云服务，把精力集中在路由策略和护栏配置上。

2.1🏗️ 技术选型：别自己造轮子

目前开源生态已经很成熟，核心选择如下：

对你最现实的路径：如果你的 Agent 已经用 vLLM 做推理后端，vLLM Semantic Router + Production Stack是自然延伸；

如果只是想先跑起来，LiteLLM最省事。

2.2 LiteLLM配置路由和护栏

LiteLLM 的路由和护栏集成，核心逻辑都是在config.yaml里声明规则，然后由 Proxy 执行。你可以把它理解成一个“声明式”的 AI 流量网关。

2.2.1🛣️ 如何做路由

LiteLLM 的路由主要有两种玩法，你可以根据场景选择：

1. 基于模型的显式路由（最直接）这是最基础的方式，客户端在请求里指定model名称，LiteLLM 根据model_name找到背后真实的部署。它天然支持一个名称对应多个后端（负载均衡）。

model_list: # 医学问答走本地 Ollama - model_name: "medical-qa" litellm_params: model: "ollama/qwen2.5:7b" api_base: "http://localhost:11434" ​ # 代码辅助走另一个模型 - model_name: "coding-assistant" litellm_params: model: "openai/qwen-coder" api_base: "http://vllm.internal:8000/v1"

2. 基于语义/复杂度的自动路由（更智能）如果不想让客户端指定模型，LiteLLM 可以自动判断请求的“意图”或“复杂度”，把它分发给合适的后端。这通过auto_router实现：

• 分类方式：默认用启发式评分（零 API 调用，亚毫秒级），检测关键词、代码片段、推理标记等。也可以配LLM 分类器，用一个小模型来判断，但会增加延迟和成本。

• 分层路由：根据分类结果，把请求映射到不同的“层级”（tier），每个层级可以配置一个或多个模型。

model_list: - model_name: "smart-router" litellm_params: model: "auto_router/complexity_router" complexity_router_config: tiers: SIMPLE: "ollama/qwen2.5:7b" # 简单问题走本地 COMPLEX: "openai/gpt-4o" # 复杂问题走大模型

2.2.2🛡️ 如何集成护栏

护栏集成同样是声明式的。你可以在config.yaml里配置使用内置护栏、第三方护栏（如 Akto, Straiker），或者自定义护栏。

配置示例（混合使用内置和第三方）：

guardrails: # 使用内置的 PII 检测（快速、确定性） - guardrail_name: "pii-check" litellm_params: guardrail: "presidio" # 内置或第三方 mode: "pre_call" # 在请求发往 LLM 前检查 default_on: true # 对所有请求生效 ​ # 使用 Akto 做基于模型的深度检测（防注入、语义 PII 泄露） - guardrail_name: "akto-guard" litellm_params: guardrail: "akto" mode: "pre_call" api_key: "os.environ/AKTO_API_KEY"

关键特性：

• 执行时机：pre_call在输入时检查，post_call在输出时检查。

• 策略控制：可以通过policies将护栏组合成策略，并精确地附加到特定的团队、密钥或模型上，实现精细化的权限管理。

• 流式处理：对于流式响应，post_call护栏默认只能审计，无法阻断。但可以使用async_post_call_streaming_iterator_hook来实时处理每个数据块，实现流式阻断。

💭 针对之前医学 Agent 的落地方案

结合你的场景，可以这样设计：

1. 路由层：定义medical-qa和medical-triage等model_name。对于“分诊”这类简单意图，可以用启发式路由直接分发给轻量模型；对于“用药咨询”等复杂且高风险的任务，强制路由到能力更强的模型。

2. 护栏层：

   • Pre-call：启用 PII 检测（脱敏患者信息），并可以接入一个第三方护栏（如 Straiker）来防御 Prompt 注入。

   • Post-call：对于医学输出，可以使用Policy Flow Builder配置一个更严格的检查管道，比如先用快速规则过滤，如果通过再调用一个基于模型的护栏进行深度审核。

LiteLLM 的优势在于，路由和护栏的配置是分离但可组合的，你可以先让路由跑起来，再逐步叠加护栏策略，验证效果后再全量开启。

2.3 护栏分类

不是必须每次都调用一个独立的模型。护栏的实现方式分几个层次，模型调用只是其中成本最高的一种。

2.3.1🧱 护栏的四种实现方式

1. 规则/正则（零模型调用）最快、最便宜。用关键词、正则表达式、黑名单匹配。比如检测“ignore previous instructions”这类越狱关键词，或者匹配身份证号、手机号格式。延迟在微秒级，但容易被绕过。

2. 小模型分类器（一次轻量推理）用 BERT 级别的模型做分类判断，比如判断“这段话有没有害”“是不是 Prompt 注入”。模型很小（几千万参数），CPU 就能跑，延迟在毫秒级。你之前看的 SemGuard 就是这类，2270 万参数，延迟 21-40 毫秒。

3. 大模型裁判（一次完整 LLM 推理）用 LlamaGuard、QwenGuard 这类专门微调的安全模型，或者直接用一个通用大模型做 judge。判断更准，但延迟和成本都高。实测中，一个 20B 的裁判模型单次判定平均需要12.74 秒。

4. 混合分层（生产环境常用）先跑规则，不确定的再升级到小模型，还不确定的才调大模型。这样绝大多数请求走快速路径，只有少数可疑请求触发昂贵推理。

2.3.2 🎯 输入护栏和输出护栏的差异

输入护栏通常在请求到达主模型前执行。可以用规则 + 小模型组合，因为输入文本相对短，且需要在低延迟下完成。

输出护栏更复杂。如果主模型是流式输出，输出护栏面临一个两难：

• 逐 chunk 检查：每个 chunk 都调一次模型，成本爆炸，且上下文不完整容易误判

• 等完整输出后检查：失去流式意义，用户要等全部生成完才能看到

• 滑动窗口检查：每累积一定长度（比如一句话）跑一次检查，是折中方案

2.4 常见护栏

工程中最常用的护栏工具，可以按技术分类分为三类：编程框架、分类器模型、托管 API。

它们的核心差异在于“谁来做判断”——框架用你定义的规则组合，分类器用预训练模型，托管 API 则把判断逻辑封装成一次远程调用。

根据你的要求，以下是加入 Bastion Prompt Protection、PromptShield Guard、Fendrix 和 subcanopy-guard 后的完整护栏对比表格。

📊 主流护栏工具对比（更新版）

🔍 几个免费的模型关键定位

Bastion Prompt Protection是当前检测精度最高的开源选择。它的 70M 模型在四个 held-out 基准上平均 AUC 达 0.991，而 Meta 的 Prompt Guard 2 只有 0.299。INT8 ONNX 构建下单次推理仅 5-10ms，适合作为你的第一道输入过滤。注意它的许可证是 AGPL-3.0，如果作为网络服务运行需要开源对应代码，商业许可可向官方申请。

PromptShield Guard的核心卖点是极致隐私。所有计算在本地完成，零遥测、零网络调用，对于患者数据不能出网的医学场景很有吸引力。延迟 <0.2ms，几乎不增加感知延迟。它的 Guard Edition 在 Gumroad 上标价 $19，核心代码在 GitHub 开源。

Fendrix的三层架构很适合工程集成：第一层纯规则匹配（零成本），第二层启发式评分，第三层才调用 LLM 处理模糊情况。这种设计让它在处理海量流量时成本极低，同时保留了处理复杂攻击的能力。返回结果包含layer_triggered和rule_matches，方便调试和调整策略。

subcanopy-guard走的是完全无 ML 的纯规则路线。它用滑动窗口测量局部指令密度，在 AgentDojo 基准上以 0.85ms 延迟达到 86.5% 检出率，比 Meta Prompt Guard 2（149ms，1% 检出）快约 130 倍。如果你的场景对延迟极度敏感且不需要应对高度变形的攻击，这是最轻量的选择。

🏗️ 框架 vs 分类器 vs API 的本质区别

编程框架（NeMo、Guardrails AI）给你的是“乐高积木”。你定义规则、组合检测器、控制流程。适合需要精细策略控制的场景，比如“仅在检测到医疗建议时触发人工审核”。代价是需要工程投入，且性能取决于你调用的底层模型。

分类器模型（Llama Guard）给你的是一个“训练好的判断器”。你把文本丢进去，它返回 safe 或 unsafe 加上违规类别。适合不想自己写规则、只想快速加一层安全过滤的场景。代价是“黑盒”，你无法精确控制它的判断逻辑，且对抗性攻击可能绕过它。

托管 API（PromptGuard、Azure）给你的是“即插即用的服务”。一行改 URL 就能接入，无需部署和维护。适合快速上线、不想运维的场景。代价是数据要出你的网络，且按量计费。

🎯 对医学 Agent 的选型建议

结合之前的架构讨论：

PII 脱敏（输入侧）：Presidio是首选。它专门做这件事，支持中文实体（需配置），可以集成到 LiteLLM 的护栏链里。你之前问的pii-check底层就是它。

输出安全（输出侧）：Llama Guard 3可以本地部署，检查模型输出是否包含有害内容（如 S6 专业医疗建议、S7 隐私泄露）。对于医学 Agent，S6 和 S7 是需要重点关注的类别。

首选 Bastion Prompt Protection：精度最高、速度够快、本地部署、无数据外泄。作为输入护栏的第一道防线，配合你已有的 Presidio 做 PII 脱敏，基本覆盖输入侧的主要风险。

PromptShield Guard 作为备选：如果你的合规要求极端严格（任何数据都不能离开服务器进程），它的零网络调用特性最安全。

Fendrix 作为架构参考：它的“规则→评分→LLM”分层思想可以直接借鉴到你的 LiteLLM 网关配置中，用于设计低成本的一级初筛。