做一个能上线的 AI 功能，需要哪些模块？（从 RAG 到工具调用到观测）
做一个能上线的 AI 功能，需要哪些模块？（从 RAG 到工具调用到观测）
面向：开发者 / 技术负责人
关键词：RAG、Tool Use、评测、可观测性、成本、灰度
TL;DR
- 能上线的 AI 功能不是“接个大模型就完了”，而是一套工程系统：数据→检索→推理→工具→安全→评测→观测→成本→发布。
- 最容易翻车的不是模型能力，而是：权限与副作用、缺少验收标准、没有回放评测、线上不可观测。
- 推荐落地路径：先做 Workflow（确定性），再用 LLM 做“理解与生成”，最后在受控范围内加 Agent 能力。
1）先澄清：你在做“功能”，不是在做“聊天”
很多团队的第一步是做一个聊天窗口：用户提问→模型回答。
但“能上线”的 AI 功能通常有更明确的交付：
- 输出一个可用的结构化结果（表格、JSON、工单字段）
- 触发一个可追踪的动作（创建工单、发消息、写文档）
- 生成一个可复用的产物（周报、方案、测试用例）
所以第一件事不是选模型，而是写清楚两句话：
- 成功=什么（验收标准）
- 失败=什么（什么时候必须让人介入/降级）
没有验收标准，就没有工程迭代；没有失败定义，就没有安全边界。
2）一张“可上线 AI 功能”的分层图
你可以把一个 AI 功能拆成 9 层，每一层都能单独迭代：
- 入口层：UI/API、鉴权、限流
- 任务层：任务定义、输入规范、输出契约
- 数据层：知识源、权限、更新策略
- 检索层：RAG、搜索、重排
- 推理层：模型路由、Prompt/约束、输出解析
- 工具层：内部 API、数据库、外部系统（副作用）
- 安全层：权限最小化、注入防护、敏感信息处理
- 评测层：离线回放、指标、回归
- 观测层：链路、成本、失败原因、人工介入率
落地时不要“全都做完再上线”。正确姿势是：先用最薄的版本跑通链路，再逐层补齐短板。
3）数据层：RAG 之前先搞清楚“数据是什么”
RAG 的本质是：把模型不知道的内容，变成它在回答/决策前可读取的上下文。
但很多失败并不是检索算法，而是数据本身：过期、权限混乱、不可追溯来源。建议至少做到知识源分级、每条数据带来源/更新时间/owner、权限可映射。
4）检索层：不是“向量库=RAG”，而是“检索策略”
一个上线可用的 RAG，至少包含：召回、过滤、重排、截断。关键指标：命中率（答案是否在 TopK）与上下文成本（token 预算）。
5）推理层：把输出变成“可解析的契约”
建议输出契约优先（JSON schema/枚举/表格），解析失败要可恢复（重试→降级人工）。
6）工具层（Tool Use）：副作用要当成“生产事故源”来设计
建议：读写分离、参数约束、幂等键、审计日志。写操作必须确认。
7）安全层：你至少要防 3 类问题
提示注入、数据泄露、越权动作。最小方案：工具白名单+细粒度权限+高风险动作确认；对检索内容做引用标注；对输出做敏感信息检测。
8）评测层：没有回放评测，就别谈迭代
你需要任务集、回放、指标（成功率/人工介入率/成本/P95 延迟），并记录失败原因标签，才能精确补短板。
9）观测层：Agent 的 bug 往往不是报错，而是“做错”
最低配：每次请求一条 trace，记录版本、检索命中、工具调用、结果标签与原因。
10）一条推荐的落地路线（从 0 到可上线）
阶段 0 定义验收；阶段 1 先跑通 Workflow；阶段 2 LLM 只做理解与生成并契约化输出；阶段 3 受控 Tool Use；阶段 4 持续补齐评测与观测。
11）上线前 Checklist
- [ ] 验收标准清晰（成功/失败/需要人工）
- [ ] 输出可解析
- [ ] 权限打通
- [ ] 写操作有人类确认
- [ ] 回放评测可运行
- [ ] 线上观测可定位
- [ ] 成本/延迟有预算与降级
结语
AI 功能的核心竞争力，往往不是“模型更大”，而是你如何定义验收、把不确定性关进笼子，并让系统可控、可观测、可迭代。
把这 9 层搭起来，你的 AI 才有资格叫“上线”。