Claude 不能本地跑？企业这样部署更安全可控

发布人：慈云数据-客服中心发布时间：7小时前阅读量：4

Claude 私有化部署方案｜一键部署

在大模型落地企业应用的过程中，很多团队都会遇到一个共同问题：既想使用 Claude 这类高质量大语言模型的能力，又希望满足企业内部对数据安全、权限管理、成本控制和系统集成的要求。因此，“Claude 私有化部署”成为不少企业关注的关键词。

需要先说明一点：Claude 是 Anthropic 提供的商业闭源大模型，目前并不支持像开源模型那样将完整模型权重下载到本地服务器进行真正意义上的离线私有化部署。因此，本文所说的“Claude 私有化部署方案”，更准确地说，是指围绕 Claude API 或云平台托管能力，构建一套企业内部可控、可管理、可审计、可一键部署的私有化访问系统。

这类方案通常包括：统一入口、权限认证、API Key 管理、用量统计、日志审计、模型路由、知识库接入、聊天前端、后端代理服务、Docker 一键部署以及企业内网访问控制等能力。通过这种方式，企业可以在不暴露原始 API Key 的前提下，让内部员工、业务系统或智能体应用安全地调用 Claude。

一、为什么企业需要 Claude 私有化部署方案？

Claude 在长文本理解、代码生成、复杂推理、多轮对话、文档分析等方面表现出色，尤其适合企业级场景。例如：

法务合同审查；
客服知识库问答；
研发代码辅助；
内部文档总结；
财务报告分析；
市场材料生成；
智能办公助手；
多智能体自动化流程。

但是，企业在直接使用 Claude 官方服务时，往往会面临以下问题。

1. API Key 管理风险

如果每个员工或每个业务系统都直接持有 Claude API Key，就会产生很大的安全隐患。一旦 Key 泄露，攻击者可能直接调用模型接口，造成费用损失甚至数据泄露。

通过私有化网关统一托管 Key，可以做到：

员工不直接接触真实 API Key；
不同用户分配不同访问权限；
统一限流、统计和审计；
Key 泄露后可以快速切换；
支持多供应商 API 统一管理。

2. 内部权限体系难以打通

企业一般已经有自己的账号体系，例如 LDAP、企业微信、钉钉、飞书、OAuth2、OIDC、SSO 等。如果直接使用第三方 AI 平台，往往无法很好地与内部组织架构、部门权限、岗位角色联动。

私有化部署后，可以将 Claude 能力封装成企业内部服务，实现：

员工账号统一登录；
部门级权限控制；
项目级访问隔离；
管理员后台配置；
用户调用记录追踪；
离职人员自动禁用访问权限。

3. 数据合规与审计需求

很多企业对数据合规要求较高，尤其是金融、医疗、政务、制造、法律等行业。企业希望知道：

谁在什么时间调用了模型；
输入了什么类型的数据；
输出结果是否被保存；
是否存在敏感信息传输；
是否需要脱敏处理；
是否满足内部审计要求。

通过私有化部署 Claude 访问层，可以在请求进入 Claude API 之前，增加敏感词检测、数据脱敏、内容过滤、日志脱敏、审计留痕等机制。

4. 成本控制需求

大模型调用费用往往与 Token 用量直接相关。如果没有统一管理，很容易出现无节制调用、重复调用、测试环境滥用等问题。

一套完善的私有化部署方案，可以实现：

用户级用量限制；
部门级预算控制；
项目级账单统计；
高成本模型调用审批；
缓存复用；
提示词模板优化；
自动切换更低成本模型。

5. 统一接入多模型能力

企业通常不会只使用 Claude 一个模型，还可能同时使用 GPT、Gemini、通义千问、智谱、DeepSeek、Moonshot、Llama、Qwen 等模型。私有化网关可以对上层应用提供统一 API，对下层模型进行灵活路由。

例如：

普通问答使用低成本模型；
复杂推理使用 Claude Sonnet 或 Opus；
本地敏感数据使用开源私有模型；
长文档总结使用 Claude；
代码任务使用适配效果更好的模型。

二、Claude 私有化部署的几种常见模式

由于 Claude 不能直接下载权重本地运行，因此企业通常采用以下几种部署模式。

方案一：基于 Claude API 的企业内网代理部署

这是最常见、最容易落地的一种方式。核心思路是：企业内部部署一个统一的 AI 网关服务，所有内部应用都通过该网关调用 Claude API。

架构说明

典型架构如下：

企业用户 / 内部系统
        │
        ▼
企业统一认证系统
        │
        ▼
AI 网关服务 / Claude Proxy
        │
        ├── 权限校验
        ├── Token 统计
        ├── 请求审计
        ├── 敏感词过滤
        ├── 数据脱敏
        ├── 模型路由
        └── 限流熔断
        │
        ▼
Claude API / Anthropic API

在这种模式下，企业只需要将 Claude API Key 配置在服务端环境变量中，员工通过企业内部网页或业务系统访问，不再直接接触真实 Key。

适用场景

这种方案适合大多数中小型团队，也适合快速验证 Claude 能力的企业：

希望快速上线内部 AI 助手；
希望统一管理 Claude API；
希望低成本完成 POC；
对完全离线部署没有强制要求；
能接受请求经过外部 Claude 服务处理。

优点

部署简单；
成本较低；
可以快速上线；
灵活扩展；
便于集成企业内部系统；
可与多个大模型供应商统一管理。

缺点

模型本体不在企业本地；
仍然依赖外部 API 可用性；
对高合规场景需要额外评估；
网络访问质量会影响体验。

方案二：基于云平台的专有网络部署

Claude 也可以通过部分云平台提供的模型服务进行调用，例如某些地区和云服务中支持 Anthropic Claude 模型。企业可以将应用部署在云平台的专有网络中，通过云服务商提供的安全访问机制调用 Claude。

架构说明

企业内网
   │
VPN / 专线 / 云连接
   │
云上 VPC
   │
   ├── 应用服务
   ├── AI 网关
   ├── 日志审计
   ├── 数据库
   └── 对象存储
          │
          ▼
云平台模型服务中的 Claude

这种模式相较于直接访问 Anthropic API，更适合已经深度使用某云平台的企业。企业可以利用云平台本身的安全、网络、审计和权限能力。

适用场景

企业已经在云平台部署核心业务；
希望通过云厂商统一账单；
希望使用云平台 IAM 权限控制；
希望通过专有网络和安全组加强隔离；
对数据治理和审计要求较高。

优点

更容易与云上资源集成；
权限体系成熟；
可利用云平台日志审计；
网络链路相对稳定；
适合企业级生产部署。

缺点

部署复杂度略高；
成本可能更高；
受区域、账号权限和模型可用性影响；
仍不等于模型权重本地化部署。

方案三：Claude + 本地开源模型混合部署

对于数据敏感度较高的企业，可以采用混合架构：敏感数据在本地开源模型中处理，非敏感或复杂推理任务再调用 Claude。

例如，企业可以在本地部署 Qwen、Llama、DeepSeek、Mistral 等开源模型，用于初步处理、分类、脱敏、摘要或内部知识库检索；当任务需要更高质量推理时，再将脱敏后的内容发送给 Claude。

架构说明

用户请求
   │
   ▼
企业 AI 网关
   │
   ├── 本地敏感信息识别
   ├── 本地模型脱敏处理
   ├── 本地知识库检索
   ├── 任务分类与模型路由
   │
   ├── 敏感任务 → 本地大模型
   └── 非敏感复杂任务 → Claude

适用场景

对隐私和合规有较高要求；
希望降低 Claude 调用成本；
已具备 GPU 服务器资源；
希望兼顾本地可控和模型效果；
业务任务类型较复杂。

优点

数据控制能力更强；
可降低外部 API 调用成本；
支持更灵活的模型路由；
适合企业长期建设 AI 中台；
可以逐步替换或扩展模型供应商。

缺点

系统复杂度较高；
需要维护本地模型推理服务；
对运维、GPU、调度能力要求更高；
需要设计数据脱敏和路由策略。

三、一键部署 Claude 企业访问平台

下面介绍一种适合企业快速落地的“一键部署”思路。该方案并不是将 Claude 模型本身部署到本地，而是将 Claude 访问平台、AI 网关、Web 聊天界面、权限系统和管理后台 部署到企业服务器中。

1. 推荐部署组件

一个完整的 Claude 私有化访问平台，通常包含以下组件：

组件	作用
Web 前端	提供聊天界面、会话管理、文档上传等能力
API 网关	统一转发 Claude 请求，隐藏真实 API Key
用户认证	支持账号密码、LDAP、OAuth2、企业微信、飞书等
管理后台	管理用户、模型、额度、调用记录
数据库	保存用户、会话、权限、配置等数据
Redis	用于缓存、限流、队列、会话状态
日志系统	记录调用日志、错误日志和审计日志
对象存储	存储上传文档、知识库文件等
向量数据库	用于企业知识库检索增强生成
监控系统	监控服务状态、调用量、费用和延迟

2. 服务器配置建议

根据使用规模不同，可以选择不同配置。

小团队试用环境

适合 10 到 50 人内部使用：

CPU：4 核
内存：8GB
磁盘：100GB SSD
系统：Ubuntu 22.04 LTS
网络：可访问 Claude API
部署方式：Docker Compose

中型企业生产环境

适合 100 到 1000 人使用：

CPU：8 核以上
内存：32GB 以上
磁盘：500GB SSD
数据库：独立 PostgreSQL / MySQL
缓存：独立 Redis
负载均衡：Nginx / SLB
部署方式：Docker Compose 或 Kubernetes

大型企业高可用环境

适合多部门、多业务系统接入：

应用服务：多副本部署
数据库：主从或云数据库
缓存：Redis Cluster
日志：ELK / Loki
监控：Prometheus + Grafana
网关：Kong / APISIX / Nginx
部署方式：Kubernetes
安全：WAF、堡垒机、专线、零信任访问

四、Docker Compose 一键部署示例

下面给出一个通用化的部署示例，用于说明整体思路。实际生产环境中，可以根据企业内部规范进行调整。

1. 准备服务器环境

以 Ubuntu 为例，先安装 Docker 和 Docker Compose。

sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable docker
sudo systemctl start docker

创建部署目录：

mkdir -p /opt/claude-private
cd /opt/claude-private

2. 编写环境变量文件

创建 .env 文件：

cat > .env << 'EOF'
# Claude API 配置
ANTHROPIC_API_KEY=your_claude_api_key_here
CLAUDE_MODEL=claude-3-5-sonnet-latest

# 平台配置
APP_NAME=Claude Enterprise Gateway
APP_ENV=production
APP_PORT=3000

# 数据库配置
POSTGRES_DB=claude_platform
POSTGRES_USER=claude_user
POSTGRES_PASSWORD=please_change_this_password

# Redis 配置
REDIS_PASSWORD=please_change_redis_password

# 管理员账号
ADMIN_EMAIL=admin@example.com
ADMIN_PASSWORD=please_change_admin_password

# 安全配置
JWT_SECRET=please_change_to_a_long_random_secret
ENCRYPTION_KEY=please_change_to_32_chars_secret
EOF

注意：生产环境中不要使用弱密码，建议通过密码管理器生成高强度密钥。

3. 编写 docker-compose.yml

version: "3.9"

services:
  claude-web:
    image: your-registry/claude-enterprise-web:latest
    container_name: claude-web
    restart: always
    ports:
      - "3000:3000"
    environment:
      APP_ENV: ${APP_ENV}
      APP_NAME: ${APP_NAME}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
      CLAUDE_MODEL: ${CLAUDE_MODEL}
      DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
      REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379
      JWT_SECRET: ${JWT_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      ADMIN_EMAIL: ${ADMIN_EMAIL}
      ADMIN_PASSWORD: ${ADMIN_PASSWORD}
    depends_on:
      - postgres
      - redis
    networks:
      - claude-net

  postgres:
    image: postgres:16
    container_name: claude-postgres
    restart: always
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - claude-net

  redis:
    image: redis:7
    container_name: claude-redis
    restart: always
    command: redis-server --requirepass ${REDIS_PASSWORD}
    volumes:
      - redis_data:/data
    networks:
      - claude-net

  nginx:
    image: nginx:1.25
    container_name: claude-nginx
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - ./nginx/certs:/etc/nginx/certs
    depends_on:
      - claude-web
    networks:
      - claude-net

volumes:
  postgres_data:
  redis_data:

networks:
  claude-net:
    driver: bridge

这里的 claude-web 可以是企业自研服务，也可以是基于开源 AI 聊天平台二次开发后的镜像。实际项目中，建议将 Claude API 调用逻辑放在服务端，不要暴露到前端。

4. 配置 Nginx 反向代理

创建目录：

mkdir -p nginx/conf.d nginx/certs

创建 Nginx 配置：

cat > nginx/conf.d/claude.conf << 'EOF'
server {
    listen 80;
    server_name claude.example.com;

    client_max_body_size 50m;

    location / {
        proxy_pass http://claude-web:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
EOF

如果需要 HTTPS，可以使用企业证书或通过内网 CA 签发证书。生产环境强烈建议开启 HTTPS，避免账号、会话和请求内容被明文传输。

5. 一键启动

执行：

docker compose up -d

查看服务状态：

docker compose ps

查看日志：

docker compose logs -f claude-web

浏览器访问：

http://服务器IP

或绑定域名后访问：

https://claude.example.com

五、核心功能设计建议

为了让 Claude 私有化访问平台真正满足企业需求，建议至少实现以下功能。

1. 统一模型网关

模型网关是整个系统的核心。它负责接收上层应用请求，并将请求转发给 Claude 或其他模型。

建议支持：

Claude API；
OpenAI 兼容接口；
Azure OpenAI；
Google Gemini；
本地 Ollama；
vLLM；
Qwen、Llama、DeepSeek 等开源模型；
自定义 HTTP 模型服务。

这样可以避免企业应用直接绑定某一个供应商，提高未来迁移能力。

2. 用户与权限管理

企业内部使用时，必须避免“所有人一个账号”的模式。建议至少支持：

用户注册关闭；
管理员邀请用户；
用户分组；
部门管理；
角色权限；
模型访问权限；
API 调用权限；
管理员、普通用户、审计员角色区分。

例如，普通员工只能使用 Claude Sonnet，研发部门可以使用代码模型，管理层可以查看统计报表，审计员只能查看脱敏后的调用日志。

3. 调用额度和限流

为了避免成本失控，平台需要支持多维度限流：

单用户每日 Token 限额；
单用户每分钟请求次数；
单部门月度预算；
单应用 API Key 调用额度；
高成本模型调用审批；
超额自动降级模型；
异常调用自动封禁。

例如，一个员工如果一天内连续发起大量长文本请求，系统可以自动限流或提醒管理员。

4. 日志审计与脱敏

日志审计非常重要，但不能简单粗暴地保存所有原始输入输出，因为这可能带来二次泄露风险。

建议采用以下策略：

默认不保存完整原文；
只保存请求时间、用户、模型、Token 数、状态码；
对输入输出进行摘要化记录；
敏感字段自动打码；
支持管理员按权限查看；
日志定期归档和删除；
对审计日志进行防篡改设计。

敏感信息包括但不限于：

身份证号；
手机号；
银行卡号；
客户姓名；
医疗信息；
合同金额；
内部项目代号；
源代码密钥；
数据库连接串。

5. 企业知识库接入

Claude 本身具备很强的长文本理解能力，但企业知识通常分散在 PDF、Word、Excel、网页、Wiki、数据库、工单系统中。为了让 Claude 回答企业内部问题，需要引入 RAG，即检索增强生成。

知识库模块通常包括：

文档上传；
文本解析；
分段切块；
向量化；
向量存储；
相似度检索；
上下文拼接；
Claude 生成回答；
引用来源展示。

推荐支持的文档类型包括：

PDF；
DOCX；
XLSX；
PPTX；
Markdown；
TXT；
HTML；
企业 Wiki 页面；
数据库记录；
工单系统内容。

为了提升可信度，回答中应展示引用来源，避免模型产生无法追溯的幻觉内容。

六、安全加固方案

Claude 私有化访问平台上线前，安全加固是必不可少的环节。

1. 网络安全

建议：

平台仅开放内网访问；
外部访问通过 VPN 或零信任网关；
管理后台限制 IP 白名单；
禁止数据库和 Redis 暴露公网；
使用 HTTPS；
配置 WAF；
限制上传文件大小和类型。

2. 密钥安全

Claude API Key 是核心资产，必须严格保护：

不要写死在前端代码中；
不要提交到 Git 仓库；
使用环境变量或密钥管理服务；
定期轮换 Key；
设置最小权限；
对 Key 使用加密存储；
发生泄露后立即吊销。

3. 数据安全

建议：

请求内容按需脱敏；
日志不保存敏感原文；
会话记录支持用户删除；
管理员查看敏感内容需审批；
上传文件加密存储；
设置数据保留周期；
对数据库进行定期备份。

4. 应用安全

建议：

开启 CSRF 防护；
防止 XSS 注入；
防止提示词注入；
文件上传病毒扫描；
设置强密码策略；
支持 MFA 多因素认证；
定期进行漏洞扫描。

七、生产环境高可用部署建议

如果 Claude 平台要成为企业级基础服务，就不能只部署单机版本。生产环境建议采用高可用架构。

1. 应用多副本

通过 Nginx、Kubernetes 或云负载均衡，将请求分发到多个应用实例：

用户请求
   │
   ▼
负载均衡
   │
   ├── Claude Gateway 1
   ├── Claude Gateway 2
   └── Claude Gateway 3

2. 数据库高可用

数据库建议使用：

云数据库；
主从复制；
自动备份；
定期恢复演练；
慢查询监控；
数据加密。

3. Redis 高可用

Redis 可用于限流、缓存和任务队列。生产环境建议使用 Redis Sentinel 或 Redis Cluster。

4. 监控告警

至少监控以下指标：

服务存活状态；
请求总量；
请求失败率；
平均响应时间；
Claude API 延迟；
Token 消耗量；
用户调用排行；
部门成本统计；
数据库连接数；
Redis 内存使用；
服务器 CPU、内存、磁盘、网络。

当出现接口失败率升高、费用异常增长或服务不可用时，应自动发送告警到企业微信、飞书、钉钉或邮件。

八、成本优化策略

Claude 能力强，但如果使用不当，成本可能快速增长。企业可以从以下几个方面优化。

1. 模型分级

不是所有任务都需要使用最强模型。可以设置模型策略：

场景	推荐策略
简单问答	使用低成本模型
文档总结	使用 Claude Sonnet
复杂推理	使用更强模型
敏感数据处理	使用本地模型
批量任务	使用异步队列和限额
测试环境	使用低成本模型或 Mock

2. Prompt 优化

减少无效提示词和重复上下文，可以显著降低 Token 成本。建议：

使用标准提示词模板；
避免每次传入过长背景；
对历史会话进行摘要压缩；
RAG 检索只传入相关片段；
对长文档先分段再汇总。

3. 缓存机制

对于重复问题，可以引入缓存：

相同问题直接返回缓存答案；
相似问题复用历史结果；
知识库检索结果缓存；
文档解析结果缓存；
Prompt 模板缓存。

4. 用量报表

建议每天自动生成用量报表：

总 Token 消耗；
总费用估算；
用户排行；
部门排行；
模型调用比例；
异常高频调用；
失败请求统计。

九、常见问题解答

1. Claude 可以完全离线部署到本地吗？

目前不可以。Claude 是闭源商业模型，不提供本地权重下载。因此不能像部署 Llama、Qwen、DeepSeek 等开源模型那样完全离线运行。所谓 Claude 私有化部署，通常是指企业内部部署访问层、网关、权限系统和应用平台，通过受控方式调用 Claude API。

2. 这种方案是否安全？

安全性取决于具体架构和管理措施。通过内网部署、统一认证、API Key 托管、日志脱敏、权限控制、审计留痕、数据脱敏等手段，可以显著提升安全性。但对于极高合规要求场景，仍需要由企业法务、安全和合规团队评估。

3. 是否可以接入企业知识库？

可以。建议通过 RAG 方式接入企业知识库，将内部文档向量化后，在用户提问时检索相关内容，再交给 Claude 生成答案。

4. 是否支持多人使用？

支持。私有化平台的核心价值之一就是支持企业多人协作，并提供用户管理、权限控制、用量统计和审计功能。

5. 是否可以同时接入其他模型？

可以。推荐将 Claude 平台设计成统一 AI 网关，而不是单一模型调用工具。这样未来可以灵活接入 GPT、Gemini、Qwen、DeepSeek、本地模型等。

十、总结

Claude 私有化部署的关键，不是把 Claude 模型本身搬到本地，而是构建一套企业内部可控的 Claude 访问与治理平台。这套平台通过统一网关、权限认证、密钥托管、日志审计、用量统计、知识库接入、模型路由和安全加固，让企业能够以更安全、更规范、更低成本的方式使用 Claude。

对于大多数企业来说，推荐的落地路径是：

第一阶段：部署 Docker Compose 单机版，完成内部试用；
第二阶段：接入企业账号体系和知识库；
第三阶段：加入用量统计、限流、审计和脱敏；
第四阶段：扩展多模型网关和本地模型混合部署；
第五阶段：迁移到 Kubernetes，实现高可用和规模化运营。

如果企业只是想快速体验，可以采用 Claude API + Web 前端 + Docker Compose 的一键部署方式；如果企业要进入生产环境，则需要重点关注安全、合规、成本和高可用。

总之，Claude 私有化部署不是一个单纯的技术安装问题，而是一个面向企业 AI 能力建设的系统工程。只有将模型能力、业务场景、数据安全、权限体系和运维治理结合起来，才能真正让 Claude 成为企业内部稳定、可信、可持续使用的智能生产力平台。

文章标签： Claude私有化部署 AI网关权限审计一键部署

上一篇：Claude 进企业内网？2026 年安全接入与混合部署全方案

下一篇：Claude 不能离线部署？企业内网一键搭建可控 AI 平台方案

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们

Claude 不能本地跑？企业这样部署更安全可控

Claude 私有化部署方案｜一键部署

一、为什么企业需要 Claude 私有化部署方案？

1. API Key 管理风险

2. 内部权限体系难以打通

3. 数据合规与审计需求

4. 成本控制需求

5. 统一接入多模型能力

二、Claude 私有化部署的几种常见模式

方案一：基于 Claude API 的企业内网代理部署

架构说明

适用场景

优点

缺点

方案二：基于云平台的专有网络部署

架构说明

适用场景

优点

缺点

方案三：Claude + 本地开源模型混合部署

架构说明

适用场景

优点

缺点

三、一键部署 Claude 企业访问平台

1. 推荐部署组件

2. 服务器配置建议

小团队试用环境

中型企业生产环境

大型企业高可用环境

四、Docker Compose 一键部署示例

1. 准备服务器环境

2. 编写环境变量文件

3. 编写 docker-compose.yml

4. 配置 Nginx 反向代理

5. 一键启动

五、核心功能设计建议

1. 统一模型网关

2. 用户与权限管理

3. 调用额度和限流

4. 日志审计与脱敏

5. 企业知识库接入

六、安全加固方案

1. 网络安全

2. 密钥安全

3. 数据安全

4. 应用安全

七、生产环境高可用部署建议

1. 应用多副本

2. 数据库高可用

3. Redis 高可用

4. 监控告警

八、成本优化策略

1. 模型分级

2. Prompt 优化

3. 缓存机制

4. 用量报表

九、常见问题解答

1. Claude 可以完全离线部署到本地吗？

2. 这种方案是否安全？

3. 是否可以接入企业知识库？

4. 是否支持多人使用？

5. 是否可以同时接入其他模型？

十、总结