大模型应用开发实战（6）——做一个能上线的 AI 应用，最小技术栈到底需要哪些东西

‍♂️ 个人主页小李同学_LSH的主页✍ 作者简介LLM学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注目录一、最小技术栈不是“越多越好”而是“刚好够上线”二、模型层次第一层模型层——你总得先有一个“会思考”的核心方案 A直接调用模型 API方案 B自托管推理服务第二层应用后端——没有这一层你的 AI 只是脚本不是产品这一层至少负责什么第三层数据与状态层——没有数据库很多 AI 应用都活不过第二周推荐 PostgreSQL 作为最小方案这层最少要建哪些表第四层检索层——不是每个应用都要 RAG但很多应用迟早会要为什么“最小技术栈”里建议优先考虑 pgvector一个最简单的 RAG 视图第五层观测与评测层——这是很多团队最晚补、但最不该晚补的一层这一层最少看哪些指标第六层部署与交付层——真正的“上线”从这里开始为什么 Docker 几乎是最小标配三、如果要做 Agent 或 MCP技术栈要不要立刻升级关于 Agent关于 MCP四、最小可上线不等于最小可运行这两年做 AI 应用的门槛确实比以前低了很多。你甚至可以只写几十行代码就调一个模型 API做出一个看起来还不错的 Demo。但真正的问题不在于“能不能跑”而在于它能不能上线。上线的意思不是把代码推到服务器就结束了而是至少要满足下面几件事用户真的能访问应用能稳定返回结果出错时你知道错在哪成本不会失控以后还能继续迭代如果从这个角度看很多“AI Demo”其实离“AI 应用”还差得很远。当前官方和工程实践的共识也越来越清晰模型调用只是其中一层。OpenAI 现在把 Responses API 定位成构建 agent-like 应用的统一接口内置工具、多轮交互、远程 MCP 和多模态能力Anthropic 也强调真正成功的实现通常不是最复杂的框架而是简单、可组合的模式。FastAPI 官方则把自己定位为高性能、基于类型提示、适合生产的 Python API 框架LangSmith 则把 tracing、monitoring、evaluation 放在从开发到生产的一体化流程里。(developers.openai.com, )所以这篇文章我想回答一个很实际的问题如果我现在就要做一个能上线的 AI 应用最小技术栈到底该配到什么程度我的结论是一个最小可上线的 AI 应用通常至少需要6 层模型层应用后端层数据与状态层知识检索层可选但很多场景很快会需要观测与评测层部署与交付层前端不一定是最先复杂化的部分。很多项目最开始就是一个很简单的聊天页面甚至只有 API。一、最小技术栈不是“越多越好”而是“刚好够上线”很多人问“最小技术栈”潜台词其实是我到底哪些东西不能省哪些东西可以后补我的判断标准很简单必须有没有它应用很难稳定上线建议有不做也能上线但很快会痛暂时可不做先别加复杂度结合当前官方文档和工程实践一个很稳的“最小可上线”组合通常长这样层级最小方案作用是否必须模型层一个稳定的模型 API 或自托管推理服务负责生成能力必须后端层FastAPI对外提供 API、鉴权、流式输出、编排业务逻辑必须数据层PostgreSQL存用户、会话、消息、配置、任务状态必须检索层pgvector 或先不做有知识库需求时接入向量检索视场景观测层日志 tracing 基本评测知道系统哪里坏了、贵不贵、慢不慢必须部署层Docker 一台可访问的服务环境真正上线交付必须这个表的依据并不是某个单一框架“规定你必须这样做”而是把当前官方能力和工程上最稳的最小集做了抽象OpenAI 的 Responses API 已经把模型、多轮、工具、MCP 放到统一接口FastAPI 提供高性能 API、自动文档和异步能力pgvector 让你能直接在 Postgres 里做向量搜索LangSmith 这类观测平台则把 tracing、monitoring、evaluation 拉到了生产工作流里。FastAPI 作为 API 层模型层负责推理Postgres 负责业务数据pgvector 在需要 RAG 时补上观测层保证你能调试与评估部署层负责交付。二、模型层次第一层模型层——你总得先有一个“会思考”的核心任何 AI 应用的起点都是模型层。这个层不一定意味着你要自己训模型绝大多数团队一开始都不会这么做。当前更实际的选择通常是两种方案 A直接调用模型 API这是最适合 MVP 和中小团队的方式。OpenAI 当前把Responses API定位成统一接口支持多轮交互、内置工具、远程 MCP 和多模态输入输出所以你不必再把“聊天、工具调用、多轮上下文、MCP”拆成一堆分散接口来拼。developers.openai.comhttps://developers.openai.com/api/docs/guides/migrate-to-responses?utm_sourcechatgpt.com方案 B自托管推理服务如果你对数据、延迟或成本更敏感后面可能会走自托管路线。但从“最小技术栈”出发这通常不是第一步。所以最小方案里模型层你只需要回答一个问题我是用外部 API还是后面再演进到自托管刚开始我更建议先用一个稳定模型 API把产品链路跑通再决定是不是有必要自托管第二层应用后端——没有这一层你的 AI 只是脚本不是产品很多人第一次做 AI 项目会直接在前端调用模型。短期看很快长期几乎一定会出问题API Key 暴露业务逻辑散落在客户端无法稳定做流式输出无法做鉴权、限流、审计很难接数据库、检索和工具所以后端层是必须的。在 Python 技术栈里FastAPI 是一个非常稳的最小选择。它是一个现代、高性能、基于标准 Python 类型提示的 Web 框架同时自带 OpenAPI、Swagger UI 和 ReDoc 文档这对 AI 应用的 API 开发特别友好。fastapi.tiangolo.comhttps://fastapi.tiangolo.com/?utm_sourcechatgpt.com这一层至少负责什么最小后端至少负责接收用户请求调模型管理 Prompt / 上下文存对话记录做鉴权返回标准 API记录日志在需要时接 RAG / 工具 / MCP也就是说后端不是“模型调用的搬运工”而是你的 AI 应用真正的业务中枢。如果你把这条链路都放在前端基本就没有什么“上线”可言了。FastAPI 之所以适合这层是因为它本身就适合做生产 API同时异步模型也很适合处理 AI 场景里的 I/O 密集请求。第三层数据与状态层——没有数据库很多 AI 应用都活不过第二周很多 Demo 最大的问题就是它没有状态。你问完一句它答完就结束了。但一旦上线你很快就会需要这些东西用户信息会话记录Prompt 版本系统配置任务状态反馈数据人工审核结果这时候你就需要数据库。推荐 PostgreSQL 作为最小方案因为 Postgres 最大的优势是通用成熟事务可靠后续还能直接接 pgvector也就是说它既能当普通业务数据库又能在你需要做 RAG 时继续往上长而不用马上拆第二套系统。pgvector 官方 README 也明确写了它让你在 Postgres 里做向量相似度搜索同时保留 ACID、JOIN、PITR 等数据库能力。这层最少要建哪些表你可以非常克制地只建这几类userssessionsmessagesapp_configsfeedback已经够很多单体 AI 应用了。第四层检索层——不是每个应用都要 RAG但很多应用迟早会要一个非常常见的误区是做 AI 应用就必须先上向量数据库、上 RAG、上复杂检索。如果你的应用只是改写总结头脑风暴结构化输出那可能一开始根本不需要 RAG。但如果你的应用开始回答这些问题公司内部知识问答产品手册问答法务/财务/医疗文档问答基于私有资料的客服那你基本很快就会需要一层检索系统。为什么“最小技术栈”里建议优先考虑 pgvector因为 pgvector 可以让你把业务数据文档元数据向量索引放在同一个 PostgreSQL 体系里先别急着上独立向量数据库。官方说明里写得很明确它支持 exact / approximate nearest neighbor search也支持 cosine、inner product、L2 等距离。这对“最小上线版本”特别重要少一套基础设施就少一套运维复杂度。一个最简单的 RAG 视图这两个式子都表达同一个意思先从文档集合 D 里找相关内容再让模型基于问题 q和文档 d 生成答案。如果你不做知识型应用这一层可以暂时先不加。但如果你做的是“企业 AI 应用”这层通常会很快成为刚需。pgvector 之所以适合做第一版是因为它把向量搜索放进了你本来就大概率会用的 Postgres 里。第五层观测与评测层——这是很多团队最晚补、但最不该晚补的一层很多 AI 应用上线以后最先崩的不是模型而是不知道为什么慢不知道为什么贵不知道哪一步出错不知道用户为什么不满意这时候普通 Web 应用那套“看看 Nginx 日志”就不够了因为 AI 应用天然多了Prompt上下文检索结果工具调用模型延迟Token 成本输出质量所以Tracing 和 Evaluation不再是高级功能而是最小可运营能力。LangSmith 官方文档把 observability、evaluation、deployment 直接放进了一条工作流里它对 tracing 的定义也很直白trace 是一次请求从输入到输出经过的完整步骤记录。这一层最少看哪些指标最小版我建议你至少跟 4 个成功率平均延迟单次请求成本人工抽样满意度这条式子非常适合你上线后排查“到底慢在哪”是后端接收慢、检索慢、模型推理慢还是后处理慢。第六层部署与交付层——真正的“上线”从这里开始当你说“我要上线”最后总要落到交付方式。FastAPI 官方的部署文档强调了你最终还是要面对进程、服务、容器、网络这些生产概念。对一个最小 AI 应用来说建议部署层尽量克制Docker统一运行环境一个可访问的服务环境云主机、容器平台都行HTTPS / 域名 / 反向代理按平台配环境变量管理API Key、数据库连接、开关配置为什么 Docker 几乎是最小标配因为 AI 应用里依赖很容易乱模型 SDK向量库驱动系统库Python 版本部署环境差异一旦不容器化开发环境能跑、线上不能跑会非常常见。“上线”这件事到这里才真正完整。前面五层决定你能不能做出一个像样的 AI 应用最后这一层决定别人到底能不能稳定用到它。FastAPI 的部署文档本身就是围绕这些概念组织的。三、如果要做 Agent 或 MCP技术栈要不要立刻升级这部分很多人容易加早了。关于 AgentAnthropic 的实践建议很值得记住最成功的 agentic systems 往往来自简单、可组合的模式不是一上来就上最复杂框架他们还明确区分了 workflow 和 agent。所以如果你的任务只是一次问答一次检索后回答固定的工作流那先别急着上 Agent。关于 MCPMCP 官方把自己定义成一种连接 AI 应用与外部系统的开放标准并把它类比成 AI 应用的 USB-COpenAI 当前也已经在 Responses API 里支持 MCP tools。‘所以 MCP 适合什么时候上你接的外部系统开始变多不想每个工具都手写一套接法想把工具、数据源、工作流统一暴露给模型应用也就是说Agent解决的是“怎么决策和执行”MCP解决的是“怎么标准化接外部世界”四、最小可上线不等于最小可运行级别组成特点最小可运行模型 API 简单前端能演示但不稳定、难维护最小可上线模型层 后端 数据库 观测 部署能交付、能排障、能继续迭代可扩展版本再加 RAG / Agent / MCP / 评测体系能走向更复杂业务场景