企业官网建设流程全解析

1. 这不是“又一个API网关教程”，而是一套能真正落地的密钥分发中枢系统

你有没有遇到过这样的场景：团队里5个工程师、3个产品经理、2个测试，每人手里都攥着一串大模型API密钥——有的是Qwen的，有的是Claude的，有的是Minimax的，还有的是自建微调模型的。大家各自管理、各自轮换、各自填坑。某天凌晨三点，线上Agent服务突然报错401 Unauthorized，排查两小时才发现是某位同事上周离职时没交出他本地配置的Claude密钥，而那个密钥恰好被写死在生产环境的CLI脚本里。这不是段子，是我上个月在三个不同客户现场亲眼见过的真实事故。

“大模型网关集成MCP与CLI的调用指南（自动分配密钥工具）”这个标题，表面看是讲技术对接，实际解决的是密钥生命周期失控这个高危痛点。它不是把API代理层再包装一层，而是构建一个带身份上下文、权限策略、审计日志和自动分发能力的密钥中枢。MCP（Model Control Protocol）在这里不是协议栈里的抽象概念，而是密钥分发的“交通信号灯”——它定义了谁能在什么时间、以什么方式、调用哪个模型的哪类能力；CLI也不是简单的命令行入口，而是终端用户与密钥中枢之间的可信信使，它不接触明文密钥，只携带由网关签发的短期凭证（JWT），并在本地完成安全解密与透传。

我把它称为“密钥呼吸系统”：密钥不再静止存储，而是在网关、CLI、模型服务之间动态流转、按需生成、限时生效、自动回收。你不需要记住任何密钥字符串，只需要执行mcp-cli call --model qwen2.5 --task summarize --input ./report.txt，背后就完成了身份鉴权、策略匹配、密钥申请、临时令牌签发、模型路由、结果回传、密钥销毁全过程。整个链路里，人只负责“做什么”，系统自动决定“用谁的密钥、怎么用、用多久”。

这套方案特别适合三类人：一是正在搭建内部AI中台的技术负责人，你需要统一管控模型调用成本与合规风险；二是频繁切换模型供应商的算法工程师，你不想每次换模型都重写CLI参数和密钥配置；三是给非技术人员提供AI能力的产品经理，你得确保销售同事用Figma插件调用AI时，既不能看到密钥，也不能越权访问财务模型。它不依赖特定云厂商，不绑定某个大模型平台，核心逻辑全部跑在你自己的网关服务里——这才是真正的自主可控。

2. 整体架构设计：为什么必须绕开“密钥硬编码”这条死路

2.1 传统密钥管理的三大致命缺陷

我们先直面现实：当前90%的团队还在用Excel表格管理密钥，或者把密钥写进.env文件再Git忽略。这种做法在小规模验证阶段看似省事，但一旦进入真实业务场景，立刻暴露三个结构性缺陷：

第一是权限颗粒度粗放。你给张三分配了一个Qwen API Key，他就拥有了该Key下所有模型、所有端点、所有请求频率的完整权限。他可以调用/v1/chat/completions，也能调用/v1/embeddings，甚至能发起/v1/models列表查询——而实际上他只需要用chat能力做会议纪要。没有RBAC（基于角色的访问控制），就没有最小权限原则，也就没有安全底线。

第二是密钥生命周期不可控。密钥一旦生成，有效期动辄数月甚至永久。当员工离职、设备丢失、或发现密钥泄露时，你无法精准吊销某台机器上的某个密钥，只能全局重置——这意味着所有正在运行的服务都会中断。我见过一家公司因运维误操作导致密钥轮换，结果连带停掉了客服对话机器人、文档摘要服务、代码补全插件，整整47分钟业务不可用。

第三是调用行为不可审计。密钥本身不携带上下文信息。当你在Prometheus里看到Qwen接口的429 Too Many Requests告警时，你根本不知道是哪个业务线、哪个用户、哪段代码触发的超额调用。日志里只有IP和User-Agent，没有“谁在什么场景下调用了什么模型”。没有审计溯源，就无法做成本分摊、异常归因和SLA保障。

提示：不要试图用“加密.env文件”或“Git Hooks拦截密钥提交”来修补这些缺陷。它们只是把问题从明处藏到暗处，反而增加了排查复杂度。真正的解法是让密钥“活起来”，而不是“藏起来”。

2.2 MCP协议作为密钥分发的语义层

MCP（Model Control Protocol）在这里不是用来替代HTTP或gRPC的传输协议，而是为密钥分发建立一套可编程的语义契约。它的核心价值在于把“密钥”这个静态字符串，升级为“能力凭证”这个动态实体。

举个具体例子：当CLI执行mcp-cli call --model claude-3-haiku --task code-review --repo-id 12345时，CLI并不向网关发送“请给我Claude的密钥”，而是发送一条MCP请求：

{ "intent": "code-review", "model": "claude-3-haiku", "context": { "repo_id": "12345", "pr_number": "789", "file_paths": ["src/main.py", "tests/test_main.py"] }, "constraints": { "max_tokens": 2048, "timeout_ms": 30000 } }

网关收到后，会基于预设策略引擎进行三重决策：

1. 身份校验：CLI携带的JWT是否由网关签发？签名是否有效？是否在有效期内？
2. 策略匹配：当前用户角色（如devops-admin）是否被授权调用claude-3-haiku模型？code-review任务类型是否在白名单内？repo_id=12345是否属于该用户有读取权限的仓库？
3. 密钥调度：根据repo_id哈希值，从密钥池中选择一个未被高频使用的Claude Key（避免单Key被限流），生成一个仅对该次请求有效的临时Token（含exp=180s），并注入X-MCP-Trace-ID用于全链路追踪。

这个过程的关键在于：密钥的分配决策，完全由MCP请求中的语义字段驱动，而非CLI的硬编码参数。你可以轻松实现“同一用户，调用不同任务时使用不同密钥”，“同一模型，不同业务线隔离密钥池”，“敏感任务强制启用双因素认证后再发放密钥”等高级策略。MCP把密钥管理从运维操作，升级为产品功能。

2.3 CLI作为可信信使的设计哲学

市面上很多CLI工具（比如codex-cli、claude-code-cli）本质上仍是密钥搬运工——它们把用户输入的密钥存进本地Keychain，再拼接成HTTP Header发出请求。这违背了零信任原则：CLI进程本身可能被恶意软件劫持，本地存储的密钥随时可能被dump出来。

我们设计的CLI走的是另一条路：它永远不持有长期密钥，只管理短期凭证。安装时，用户通过OIDC流程（如企业微信扫码、钉钉审批）向网关换取一个初始Refresh Token，存于操作系统安全区（macOS Keychain / Windows DPAPI / Linux Secret Service）。此后每次调用：

• CLI用Refresh Token向网关申请Access Token（JWT）
• 网关验证Refresh Token有效性，并根据当前上下文（如--task参数、$PWD路径、git remote地址）动态生成Access Token的scope字段
• CLI将Access Token放入Authorization: Bearer <token>Header，直接转发给网关
• 网关解析Token，提取scope，匹配策略，签发本次调用专用的模型密钥Token

整个链路里，CLI就像一个“数字身份证读卡器”：它不存储身份证号（长期密钥），只负责读取并出示实时签发的“临时通行码”（Access Token）。即使CLI进程被攻破，攻击者最多拿到一个15分钟有效期的Token，且该Token无法用于其他任务类型或模型。

注意：CLI二进制文件必须启用代码签名（Apple Notarization / Microsoft Authenticode），启动时校验自身完整性。我们实测发现，未签名的CLI在macOS上会被Gatekeeper拦截，导致首次运行失败——这不是bug，而是安全基线。

2.4 自动分配密钥工具的核心定位

标题里的“自动分配密钥工具”，不是指一个独立的keygen命令，而是网关内置的密钥调度引擎。它包含三个协同模块：

• 密钥注册中心（Key Registry）：支持手动录入、API批量导入、云厂商IAM同步（如AWS Secrets Manager、阿里云KMS）三种方式纳管密钥。每条密钥记录包含：模型类型、服务商、区域、配额上限、健康状态、标签（如env=prod,team=ai-platform）。
• 策略决策引擎（Policy Engine）：基于Open Policy Agent（OPA）实现，策略规则用Rego语言编写。例如一条典型规则：

  package mcp.authz default allow = false allow { input.user.role == "data-scientist" input.model == "qwen2.5" input.intent == "data-analysis" input.context.dataset_size_mb < 100 }

• 动态分发器（Dynamic Distributor）：根据实时指标（当前QPS、错误率、密钥剩余配额）选择最优密钥。它采用加权轮询算法，权重=（剩余配额 × 健康分）/ 当前QPS，避免把流量集中到某条即将耗尽的密钥上。

这个工具的价值，不在于“自动化”本身，而在于把密钥分配这个高危操作，变成可版本化、可灰度发布、可AB测试的软件功能。你可以为新上线的模型密钥设置10%灰度流量，观察错误率；可以为VIP客户创建专属密钥池，保证SLA；可以在财报季自动提升财务分析模型的密钥配额——所有这些，都不需要运维SSH登录服务器改配置。

3. 核心细节解析：从零搭建密钥中枢的实操要点

3.1 网关服务选型：为什么放弃Kong/Nginx，选择Traefik+OPA组合

很多人第一反应是用Kong或Nginx做API网关，再挂载一个密钥管理插件。这条路理论上可行，但实操中会撞上三个硬伤：

第一是策略执行深度不足。Kong的ACL插件只能基于Header或Path做黑白名单，无法解析MCP请求体里的intent和context字段做细粒度鉴权。你想实现“只允许intent=translation时调用model=qwen2.5”，就得写Lua脚本解析JSON，而Kong的Lua沙箱限制严格，调试极其痛苦。

第二是密钥生命周期耦合度高。Nginx的auth_request模块只能返回200/401，无法携带密钥分发结果。你得在上游服务里二次调用密钥中心，导致链路变长、超时风险上升。更麻烦的是，Nginx本身不支持JWT Token刷新，Refresh Token机制得另起服务维护。

第三是可观测性割裂。Kong的Prometheus指标只到HTTP层，看不到intent=code-review这类业务维度的QPS。你想统计“本周Claude用于PR Review的调用量”，得在应用层埋点，失去了网关层的统一视图。

我们最终选择Traefik v2.10 + OPA v0.60 + PostgreSQL组合，原因很实在：

• Traefik原生支持Middleware链式处理，可插入自定义Auth Middleware解析MCP请求；
• OPA的Rego语言专为策略即代码设计，input对象天然映射HTTP请求体，写input.body.intent == "summarize"比写Lua直观十倍；
• PostgreSQL作为策略规则存储，支持Row-Level Security（RLS），不同团队只能看到自己命名空间下的策略，避免策略冲突。

部署时，我们把Traefik配置拆成三层：

1. 入口层（EntryPoints）：监听443端口，TLS证书由Let's Encrypt自动续期；
2. 路由层（Routers）：匹配Host(mcp-gateway.yourcompany.com) && PathPrefix(/v1/mcp)；
3. 中间件层（Middlewares）：依次执行jwt-auth→opa-policy→key-distribution→rate-limit。

其中key-distribution中间件是核心，它接收OPA返回的allow=true响应后，从PostgreSQL查出匹配的密钥ID，调用密钥调度引擎生成临时Token，并注入到X-MCP-Key-TokenHeader中传递给下游模型服务。

实操心得：Traefik的Middleware必须用Go语言编写（而非YAML配置），因为密钥分发需要访问数据库和缓存。我们用github.com/traefik/traefik/v2/pkg/middlewares包开发，编译成.so插件加载。别试图用File Provider做动态策略更新——它不支持热重载，每次改策略都要重启Traefik。

3.2 MCP协议的最小可行实现：不必等待标准，先跑通闭环

网络上关于MCP的讨论很多，但至今没有RFC级别的标准。蓝湖MCP、Figma MCP、Workbuddy MCP各自实现差异很大。我们的策略是：不追求协议兼容性，先定义团队内部最小可行语义集。

我们只实现MCP的四个必选字段：

• intent（字符串）：明确的任务意图，如chat、summarize、translate、code-review。禁止使用模糊词如query或request。
• model（字符串）：模型标识符，格式为{vendor}/{name}/{version}，如qwen/qwen2.5/1.0、anthropic/claude-3-haiku/20240307。版本号强制要求，避免latest带来的不确定性。
• context（对象）：任务上下文，必须包含业务关键字段。例如code-review必须有repo_id和pr_number；translate必须有source_lang和target_lang。
• constraints（对象）：调用约束，包含max_tokens、timeout_ms、temperature等。网关据此做前置校验，拒绝超出范围的请求。

其他字段如session_id、trace_id、user_agent作为可选，由CLI自动填充。重点在于：所有字段都参与策略匹配，没有“装饰性字段”。当你写opa-policy规则时，每个字段都是决策依据。

我们用OpenAPI 3.0规范定义MCP Schema，并生成TypeScript客户端SDK供CLI调用。Schema里对intent做了枚举限制：

components: schemas: MCPRequest: type: object required: [intent, model, context] properties: intent: type: string enum: [chat, summarize, translate, code-review,>curl -X POST https://api.qwen.ai/v1/chat/completions \ -H "Authorization: Bearer $KEY" \ -d '{"model":"qwen2.5","messages":[{"role":"user","content":"test"}]}'

记录响应时间、HTTP状态码、错误消息。连续3次超时（>5s）或返回429，标记为unhealthy，暂停分发。

2. 配额计算器（Quota Calculator）
从服务商API获取实时配额（如Qwen的X-RateLimit-RemainingHeader），结合历史调用量预测未来1小时消耗。公式：

predicted_usage = (current_qps × 3600) + (peak_qps_last_hour × 0.3) remaining_quota = api_quota - predicted_usage

当remaining_quota < 100时，自动降权，减少分配概率。

3. 负载均衡器（Load Balancer）
不用简单轮询，而用加权随机算法：

let weights: Vec<f64> = keys.iter() .map(|k| { let health_score = if k.health == Healthy { 1.0 } else { 0.3 }; let quota_score = (k.remaining_quota as f64 / k.total_quota as f64).max(0.1); let load_score = (1.0 - k.current_qps as f64 / k.max_qps as f64).max(0.1); health_score * quota_score * load_score }) .collect(); // 按weights数组做加权随机选择

确保健康、配额充足、负载低的密钥获得更高分配权重。

4. 临时Token签发器（Token Issuer）
不直接返回原始密钥，而是签发JWT：

{ "sub": "mcp-key-token", "jti": "uuid4", "iat": 1717023456, "exp": 1717023756, "model": "qwen2.5", "intent": "summarize", "scope": ["read:messages"], "key_id": "qwen-prod-003" }

网关下游服务用公钥验签，提取key_id查出对应密钥，完成调用。Token过期后自动失效，无需主动吊销。

这套引擎部署为独立服务（key-distributor），通过gRPC与Traefik通信。我们用Redis做分布式锁，防止多实例同时更新同一密钥状态。实测在1000 QPS压力下，平均分配延迟<15ms。

4. 实操过程：手把手部署你的密钥中枢（含完整配置）

4.1 环境准备与依赖安装

我们假设你有一台干净的Ubuntu 22.04服务器（4核8G，50GB SSD），域名已解析到该IP（如mcp-gateway.yourcompany.com）。全程无需root权限，所有服务运行在普通用户下。

第一步：安装基础依赖

# 更新系统并安装必要工具 sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget git unzip jq # 安装Docker CE（用于运行PostgreSQL和Redis） curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER newgrp docker # 刷新组权限 # 安装Docker Compose v2.24+ sudo curl -L "https://github.com/docker/compose/releases/download/v2.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose

第二步：克隆网关代码库

# 创建项目目录 mkdir -p ~/mcp-gateway && cd ~/mcp-gateway # 克隆我们开源的网关模板（已预置Traefik+OPA+PostgreSQL） git clone https://github.com/your-org/mcp-gateway-template.git . git checkout v1.2.0 # 使用稳定版本 # 目录结构说明 ls -l # ├── docker-compose.yml # 主编排文件 # ├── traefik/ # Traefik配置 # │ ├── dynamic/ # 动态配置（Middleware、Router） # │ └── static.yml # 静态配置（EntryPoints、Providers） # ├── opa/ # OPA策略规则 # │ └── policies/ # Rego规则文件 # ├── scripts/ # 部署脚本 # └── .env # 环境变量配置

第三步：配置环境变量

# 复制环境变量模板 cp .env.example .env # 编辑.env，填入你的信息 nano .env # DOMAIN=mcp-gateway.yourcompany.com # LETSENCRYPT_EMAIL=ops@yourcompany.com # POSTGRES_PASSWORD=your-strong-postgres-password # OPA_SECRET=your-opa-jwt-secret-32-bytes-long # JWT_SECRET=your-jwt-signing-key-32-bytes-long # KEY_DISTRIBUTOR_URL=http://key-distributor:8080

关键点：JWT_SECRET和OPA_SECRET必须是32字节随机字符串，用openssl rand -hex 32生成。不要用短密码，否则JWT易被暴力破解。

4.2 启动网关服务集群

运行一键启动脚本：

# 给脚本加执行权限 chmod +x scripts/start.sh # 启动所有服务（PostgreSQL、Redis、OPA、Traefik、Key Distributor） ./scripts/start.sh # 检查服务状态 docker-compose ps # Name Command State Ports # ------------------------------------------------------------------------------------------------------------------ # mcp-gateway_key-distributor_1 /app/key-distributor Up 0.0.0.0:8080->8080/tcp # mcp-gateway_opa_1 /opa run --server --addr ... Up 0.0.0.0:8181->8181/tcp # mcp-gateway_postgres_1 docker-entrypoint.sh postgres Up 0.0.0.0:5432->5432/tcp # mcp-gateway_redis_1 docker-entrypoint.sh redis ... Up 0.0.0.0:6379->6379/tcp # mcp-gateway_traefik_1 /entrypoint.sh traefik Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp

验证Traefik是否正常工作：

# 访问Traefik仪表盘（需先配置DNS或hosts） echo "123.45.67.89 mcp-gateway.yourcompany.com" | sudo tee -a /etc/hosts curl -k https://mcp-gateway.yourcompany.com/dashboard/ # 应返回Traefik Dashboard HTML，证明HTTPS和路由正常

初始化PostgreSQL数据库：

# 运行初始化脚本（创建表、导入默认策略） ./scripts/init-db.sh # 输出：Database initialized successfully. # Default policy 'allow-all' loaded.

4.3 注册第一条密钥并测试MCP调用

第一步：用CLI注册密钥下载预编译的CLI二进制（支持Linux/macOS/Windows）：

# Linux x64 wget https://github.com/your-org/mcp-cli/releases/download/v1.1.0/mcp-cli-linux-x64 -O ~/mcp-cli chmod +x ~/mcp-cli # 首次认证（会打开浏览器） ~/mcp-cli auth login --gateway https://mcp-gateway.yourcompany.com # 注册Qwen密钥（替换为你的真实密钥） ~/mcp-cli key register \ --model qwen/qwen2.5/20240307 \ --key sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \ --tags env=prod,team=ai-platform \ --quota 10000 \ --region cn-shanghai # 输出：Key registered successfully. ID: qwen-prod-001

第二步：构造MCP请求体创建测试文件request.json：

{ "intent": "summarize", "model": "qwen/qwen2.5/20240307", "context": { "text": "人工智能是计算机科学的一个分支，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。该领域的研究包括机器人、语言识别、图像识别、自然语言处理和专家系统等。" }, "constraints": { "max_tokens": 512, "temperature": 0.3 } }

第三步：发起MCP调用

# 使用CLI发送请求 ~/mcp-cli call \ --gateway https://mcp-gateway.yourcompany.com \ --request @request.json # 或直接用curl（验证网关底层） curl -X POST https://mcp-gateway.yourcompany.com/v1/mcp/call \ -H "Authorization: Bearer $(~/mcp-cli auth token --raw)" \ -H "Content-Type: application/json" \ -d @request.json

预期响应：

{ "id": "cmpl-9abc123def456", "object": "chat.completion", "created": 1717023456, "model": "qwen2.5", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "人工智能是计算机科学的分支，旨在理解智能本质并制造类人智能机器，研究领域包括机器人、语言识别、图像识别、自然语言处理和专家系统。" }, "finish_reason": "stop" }], "usage": { "prompt_tokens": 42, "completion_tokens": 38, "total_tokens": 80 }, "headers": { "X-MCP-Trace-ID": "trace-7890123456abcdef", "X-MCP-Key-ID": "qwen-prod-001", "X-MCP-Rate-Limit-Remaining": "9920" } }

实操心得：如果返回401 Unauthorized，检查CLI是否成功获取Token（~/mcp-cli auth token --debug）；如果返回403 Forbidden，检查OPA策略是否允许该intent和model组合（curl http://localhost:8181/v1/data/mcp/authz/allow）；如果返回503 Service Unavailable，检查Key Distributor日志（docker logs mcp-gateway_key-distributor_1）确认密钥健康状态。

4.4 配置高级策略：实现业务级密钥隔离

默认策略是allow-all，现在我们添加一条生产环境策略：只有ai-platform团队成员，才能在prod环境调用qwen2.5模型做summarize任务。

编辑opa/policies/mcp-authz.rego：

package mcp.authz import data.mcp.keys import data.mcp.users # 默认拒绝 default allow = false # 允许条件 allow { # 1. 用户角色匹配 user := users[input.user.id] user.team == "ai-platform" user.env == "prod" # 2. 模型和意图匹配 input.model == "qwen/qwen2.5/20240307" input.intent == "summarize" # 3. 上下文校验（必须有text字段） input.context.text count(input.context.text) > 10 # 至少10字符 # 4. 密钥存在且健康 key := keys[input.model] key.status == "healthy" key.tags.env == "prod" } # 错误消息（用于调试） error_msg = msg { not allow msg := sprintf("Policy denied: user=%v, model=%v, intent=%v", [input.user.id, input.model, input.intent]) }

重新加载OPA策略：

# 将策略推送到OPA curl -X PUT localhost:8181/v1/policies/mcp-authz \ -H "Content-Type: text/plain" \ --data-binary @opa/policies/mcp-authz.rego # 验证策略生效 curl -X POST localhost:8181/v1/data/mcp/authz/allow \ -H "Content-Type: application/json" \ -d '{ "input": { "user": {"id": "u-123", "team": "ai-platform", "env": "prod"}, "model": "qwen/qwen2.5/20240307", "intent": "summarize", "context": {"text": "test"} } }' # 返回 {"result": true}

在Traefik中启用OPA Middleware：编辑traefik/dynamic/middlewares.yml：

http: middlewares: opa-auth: plugin: opa: addr: http://opa:8181 query: data.mcp.authz.allow timeout: 5s headers: - X-OPA-Input

然后在traefik/dynamic/routers.yml中为MCP路由添加该Middleware：

http: routers: mcp-router: rule: "Host(`mcp-gateway.yourcompany.com`) && PathPrefix(`/v1/mcp`)" service: mcp-service middlewares: - jwt-auth - opa-auth # 新增这一行 - key-distribution

重启Traefik：

docker-compose restart traefik

现在，任何不符合策略的请求都会被OPA拦截，返回403 Forbidden和详细的error_msg。你可以用curl测试不同用户ID，验证策略效果。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “Unable to locate the codex cli binary”类错误的根因分析

网络上大量搜索unable to locate the codex cli binary，但这个问题在我们的MCP CLI里根本不会出现——因为我们的CLI是静态链接的单二进制文件，不存在“找不到binary”的问题。那么为什么其他CLI会报这个错？我们拆解了23个主流CLI的安装包，发现根本原因只有两个：

第一是PATH污染。用户执行npm install -g codex-cli后，codex命令被软链接到/home/user/.nvm/versions/node/v18.17.0/bin/codex。但当用户切换Node版本（如用nvm use 20）时，旧软链接指向的路径失效，而which codex仍返回旧路径，导致command not found。解决方案不是重装，而是清理PATH：

# 查看codex真实位置 which codex # /home/user/.nvm/versions/node/v18.17.0/bin/codex # 删除旧软链接 rm /home/user/.nvm/versions/node/v18.17.0/bin/codex # 用新Node版本重装 nvm use 20 npm install -g codex-cli

第二是权限继承错误。在macOS上，用户从Homebrew安装CLI后，`/