在经历了评测、监控和成本优化后，我们的 AI 系统终于打磨成了一件“工艺品”。
现在，到了把它交到最终用户手里的时候了，也就是俗称的**“上线（Deployment）”**。

AI 应用的上线，就像开饭店。你是只做外卖（API）？还是开个富丽堂皇的堂食餐厅（前端 Web）？或者是把餐车推到别人的公司楼下（插件）？
本篇，我们将梳理 AI 落地最常见的 4 种形态，并揭示其中最致命的安全大坑。

1. 形态一：本地脚本（CLI / Script）—— 极客的玩具

• 是什么：一段运行在终端里的 Python 或 Node.js 脚本。用户敲一行命令 python agent.py "帮我整理报表"，它就在后台默默干活。
• 适用场景：个人自动化工作流、内部数据清洗、定时任务（Cron Job）。
• 核心坑点：密钥管理（Key Management）
  • 绝对不要把大模型的 API_KEY 硬编码（Hardcode）写在代码文件里！如果你一不小心把代码推到了公开的 GitHub 仓库，5 分钟内，黑客就能用你的 Key 刷爆你的信用卡（俗称“被薅秃”）。
  • 正确做法：使用 .env 环境变量文件存储密钥，并在 .gitignore 中严格屏蔽该文件。

2. 形态二：服务端 API（Backend API）—— 隐形的中央厨房

• 是什么：你把 Agent 包装成了一个 HTTP 接口（比如 /api/v1/ask_agent）。它没有漂亮的界面，只接收 JSON，返回 JSON。
• 适用场景：作为“大脑”接入公司现有的老系统。比如：自动回复客服邮件、钉钉/企业微信机器人后台。
• 核心坑点：超时与并发（Timeout & Concurrency）
  • 大模型生成答案很慢，如果一个 HTTP 请求要等 30 秒才返回，很多传统的网关（如 Nginx）会直接掐断连接报 504 Timeout。
  • 正确做法：采用 SSE（Server-Sent Events） 流式输出（就像 ChatGPT 那样一个字一个字蹦），或者改用异步回调（Webhook）：告诉调用方“我收到了，算完再发通知给你”。

3. 形态三：前端产品（Web App / 小程序）—— 华丽的堂食餐厅

• 是什么：拥有漂亮聊天框、历史记录栏、甚至可视化图表生成的完整产品。
• 适用场景：对外的 ToC 智能助手、公司内部的知识库问答平台。
• 核心坑点：把 API Key 暴露给前端（极其危险的死罪！）
  • 很多新手为了图省事，直接在前端 React/Vue 代码里引入 OpenAI 的 SDK，填上 Key 去调接口。
  • 真相是：前端代码对所有人都是透明的。任何人在浏览器按 F12 就能拿到你的 Key，然后拿去白嫖。
  • 正确做法：前端永远只请求你自己的后端 API（带上用户 Token 进行权限校验），由你的后端代理去调用大模型。API Key 绝对不能离开服务器半步！

4. 形态四：插件（IDE Plugin / 浏览器扩展）—— 贴身的辅助外骨骼

• 是什么：直接寄生在用户当前工作环境里的 AI。比如在 VS Code 里的 Cursor/Trae，或者浏览器里的沉浸式翻译。
• 适用场景：强依赖用户当前上下文的任务（读用户当前打开的代码、提取用户正在看的网页）。
• 核心坑点：权限滥用
  • 插件通常拥有极高的系统权限（比如能读取本地文件）。如果你的 AI 插件遭到“提示词注入（Prompt Injection）”攻击，黑客可能会让 AI 把用户的私钥文件（如 ~/.ssh/id_rsa）悄悄读出来发送走。
  • 正确做法：引入最小权限原则（Least Privilege）。插件调用高危系统命令前，必须弹窗让人类点击“允许”。

5. 本篇产出：上线检查清单（最小版）

无论你选择哪种形态，在敲下 Deploy 按钮之前，请拉着你的技术负责人，逐项核对这份清单：

# AI 应用上线 Checklist v1.0

## 🔒 1. 密钥与权限安全 (Security)
- [ ] 确认代码库中没有任何硬编码的 API_KEY 或数据库密码。
- [ ] 确认前端页面 / 客户端 App 没有直接调用大模型厂商的 API。
- [ ] 所有调用大模型的请求，是否都经过了自建后端的权限校验 (Auth)？

## 🚦 2. 性能与成本控制 (Performance & Cost)
- [ ] 是否在网关层设置了单用户的 QPS 限流（防恶意刷量）？
- [ ] 是否设置了全局的预算熔断机制（例如：当月消耗超过 1 万人民币自动切断服务）？
- [ ] 后端接口是否支持流式输出 (Stream/SSE) 以避免网关超时？

## 📡 3. 可观测性与日志 (Observability)
- [ ] 所有的 LLM 请求是否都记录了完整的 Prompt 和 Completion，并附带 Trace ID？
- [ ] 系统是否接入了监控报警（如报错率激增、Token 消耗异常飙升的飞书/钉钉报警）？

## 🛠️ 4. 配置与环境隔离 (Environment)
- [ ] 是否将 Prompt 提取到了配置文件或数据库中，而不是硬编码在代码里？（方便不改代码直接热更新 Prompt）
- [ ] 生产环境 (Prod) 和 测试环境 (Test) 的知识库、数据库是否做到了完全物理隔离？

总结与复盘

• AI 的上线形态多种多样，但核心的工程准则是不变的：隔离与控制。
• 永远不要信任前端，把 API Key 像护身符一样锁在服务端。
• AI 的慢速特性，决定了它必须配合流式输出（SSE）或异步架构才能给用户好的体验。
• 上线前过一遍 Checklist，能让你避免 99% 的灾难级低级错误。

下一步路线提示：
系统顺利上线了，第一天风平浪静。第二天，因为你更新了一个 Prompt，AI 突然开始把所有的“你好”翻译成脏话发给客户。
此时你去重新编译代码、打包、部署，至少需要 10 分钟。这 10 分钟里，客户已经被骂了上千次。
怎么在 1 秒钟内让 AI “闭嘴”并恢复正常？下一篇，我们将探讨线上救命的法宝：《运行治理：灰度、开关、回滚、事故响应》。