在实际开发团队里很多人对 AI 的担忧并不来自技术本身而是来自不确定性。担心模型回答不可控担心 Agent 接入业务后出错难以回溯担心投入人力和算力后收益不明显也担心同行先一步把 AI 嵌入研发流程导致迭代差距越拉越大。这种焦虑放到竞争环境中看其实是正常的工程决策压力。缓解它的方式不是反复争论概念而是尽快把 AI 当做一个可测试、可监控、可回滚、可评估的普通工程组件来实践。下面这条路线会带你走过本地模型部署、Spring AI 最小问答服务、Agent 工具调用、质量评估、部署监控和问题排查最终形成一份可以在团队内部落地的 AI 工程实践清单。1. 先看清 AI 焦虑到底来自哪里1.1 大多数焦虑不是“技术替代”而是“工程不可控”很多开发者刚开始接触 AI 时第一反应是怕自己写的代码被模型生成代码替代。但真正上手后会发现问题并不在“替代”上而在“不可控”上模型今天回答正确明天换了提示词就答错同一个问题在不同温度参数下结果不同模型输出格式不稳定程序一解析就报错模型明明不知道答案却一本正经地编造事实。这些都是 AI 工程实践里更常见的阻力。“不可控”带来的直接后果是团队不敢把 AI 接入核心流程。因为普通后端服务可以靠单元测试、日志、链路追踪来验证和回溯而模型输出是概率性的没法用“断言返回等于某一串文本”的方式写测试。如果团队对这个差异没有准备就容易在第一个 AI 项目里连续踩坑然后把问题归结为“AI 不可靠”。1.2 用工程化思维替代概念争论团队里经常有两种极端声音一种认为大模型什么都能做另一种认为大模型什么都不该用。实际上这两种判断都缺少工程度量。正确的问题是这个任务是否适合用大模型错误成本是多少做了评估和兜底之后是否比传统规则方案更稳定。工程化思维的核心是给不确定性分层管理。比如“模型生成答案”这一步允许概率性输出但在它上游要控制输入和工具范围在它下游要增加格式校验、内容过滤、人工确认或自动回退。只要每一层都有明确职责模型的不确定性就会被限制在一个可接受的范围内。常见顾虑本质问题工程对策模型回答不可信缺少事实来源和校验引入 RAG 检索材料输出前做引用校验输出格式不稳定缺少结构化约束使用 JSON Schema 约束并做解析重试Agent 调用工具后乱操作工具权限边界模糊工具参数白名单化高风险操作需要人工确认换了提示词结果就变缺少回归测试建立评估集每次改动跑基线对比成本不可控缺少用量与预算监控设置调用限额、缓存和模型分级2. 跑通一条最小 AI 工程链路建立可复现基线2.1 学习环境与生产环境的边界在进入具体实现之前先确认环境定位。学习环境的目标是快速跑通示例、理解调用链路所以优先选择本地模型和最小代码。生产环境则还要考虑权限、审计、限流、高可用、模型版本管理和回滚方案二者不能混用。这里选择本地 Ollama 作为模型服务原因有三个不依赖公网 API环境可复现。模型权重和配置完全可控便于学习推理参数。成本低适合团队内部做概念验证。学习环境建议使用至少 16GB 内存的机器运行 7B 级别模型。如果要部署给线上用户建议换成 GPU 服务器或接入企业统一的模型网关。2.2 本地模型方案Ollama 安装与模型准备安装 Ollama 后直接拉取一个中文能力较好的开源模型。示例如下# 安装完成后启动服务默认端口 11434 ollama serve # 在新终端拉取模型 ollama pull qwen2.5:7b # 验证模型是否可用 ollama list拉取完成后可以先用命令行做一次简单对话ollama run qwen2.5:7b 请用一句话解释什么是 RAG看到模型返回结果后说明本地推理链路正常。这一步是后续所有示例的基础如果模型没有正确拉取Spring AI 服务启动后会在调用时出现连接错误。2.3 基于 Spring AI 写一个最小问答服务Spring AI 为 Java 生态提供了统一的模型接入抽象。下面代码用于说明最小结构实际项目要根据自己使用的 Spring AI 版本和 Spring Boot 版本调整坐标。先创建一个 Spring Boot 项目并在pom.xml中加入依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-ollama/artifactId version1.0.0-M6/version /dependency然后在application.yml中配置 Ollama 服务地址和默认模型spring: application: name: ai-practice ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:7b temperature: 0.2温度参数建议在工程应用里调低到 0.1 到 0.3。温度越低输出越稳定越适合需要确定性回答的场景。接着写一个最简 ControllerRestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam(defaultValue 你好) String message) { return chatClient.call(message); } }这里的ChatClient是 Spring AI 提供的统一调用入口。它屏蔽了底层模型协议差异让业务代码只关心“传入用户消息拿到模型回复”。2.4 用 curl 验证和压测启动 Spring Boot 应用后执行curl http://localhost:8080/chat?message请用一句话介绍你自己如果一切正常会返回一段模型生成的文本。此时最小链路已经跑通用户请求进入 Spring MVCChatClient调用本地 OllamaOllama 加载模型并返回结果结果再回到浏览器或命令行。顺手可以做一个简单压测确认延迟和吞吐# 连续调用 20 次观察耗时分布 for i in $(seq 1 20); do curl -s -o /dev/null -w %{time_total}\n \ http://localhost:8080/chat?messagehello done如果单次请求超过几秒需要检查模型大小、CPU 内存占用、并发线程数和连接池配置。生产环境还应在模型网关层做超时和重试限制避免一个慢模型拖垮整个服务。3. 从问答服务到 Agent核心是“工具调用”而不是“提示词炫技”3.1 Agent 的最小结构问答服务有一个明显局限模型只能根据自身训练数据回答不能查询实时天气、不能查数据库、不能调用内部接口。Agent 的作用就是让模型具备“使用工具”的能力。一个最小 Agent 结构通常包含三个部分模型负责理解任务和决定调用哪个工具。工具对外部能力的封装比如查询订单、查天气、发邮件。执行循环模型输出工具调用请求程序执行工具把结果返回给模型模型再生成最终回答。可以简单理解为Agent 不是单独一个模型实例而是“模型 工具 循环控制”的组合。3.2 用 Function Calling 让模型操作外部工具以下代码演示了如何在 Spring AI 中注册一个工具方法。这里用一个虚构的订单查询服务作为示例实际项目要换成自己的业务实现。Service public class OrderToolService { Tool(description 根据订单号查询订单状态) public String getOrderStatus(String orderId) { // 实际项目中这里会查询数据库或调用订单中心 if (A1001.equals(orderId)) { return 订单 A1001 已发货预计明天送达; } return 未找到订单 orderId; } }当模型判断用户需要查询订单时会输出一个工具调用请求Spring AI 负责调用getOrderStatus方法并把返回结果回传给模型模型再基于结果生成自然语言回复。这里要特别注意工具方法必须有明确的参数定义和返回值说明否则模型不知道什么时候该调用、调用时传什么参数。工具描述写得越清晰Agent 的调用准确率越高。3.3 RAG 不是 Agent而是 Agent 的一个记忆来源很多资料会把 RAG检索增强生成和 Agent 混在一起讲。更准确的区分是RAG 解决“模型不知道私有知识”的问题Agent 解决“模型不能执行动作”的问题。一个典型 Agent 系统往往会同时使用 RAG 和工具RAG 提供知识材料工具提供操作能力。RAG 最简流程是用户问题 - 向量检索 - 得到相关资料 - 拼接提示词 - 模型生成回答在工程落地时RAG 的难点不在调用大模型而在文档切片、向量索引、召回质量和相关性排序。后面评估环节会专门讲如何衡量 RAG 效果。3.4 Agent 编排中的三个高频误区第一个误区是“工具的权限边界不清晰”。如果 Agent 能调用发送短信、删除订单这类高影响操作一旦模型误判后果会很严重。推荐做法是高风险操作拆成两个步骤先让 Agent 生成操作意图再由用户确认后执行。第二个误区是“循环没有上限”。Agent 执行循环可能因为错误理解而反复调用同一个工具最终浪费大量 token。工程上一定要限制最大迭代次数比如 3 到 5 次。第三个误区是“把业务规则全部交给模型”。模型适合做语义理解和生成不适合执行严格的金额计算、权限校验和状态机流转。这些逻辑应该写在工具代码里而不是靠提示词约束模型。4. AI 应用的质量评估这是消除“不可信”最关键的一步4.1 传统单测为什么覆盖不了模型输出普通单测可以断言一个函数返回是否等于期望值但模型输出是开放文本。对同一道题模型可以给出多种合法回答不能简单用“包含某个关键词”来断言。质量评估要换一个思路不再判断“这一次输出是否等于答案”而是持续收集一批代表性问题和期望结果在每一次提示词修改、模型更换、参数调整后重新跑一遍对比整体指标是否下降。这也就是 AI 工程实践里的“回归基线”。4.2 一套可落地的最小评估维度对大多数业务问答和 Agent 场景可以先从四个维度入手维度定义常见测量方式相关性回答是否贴合用户问题人工打分 / 模型打分忠实度回答是否基于给定材料是否出现幻觉比对回答与参考材料完整性是否遗漏了关键信息人工打分 / 模型打分格式合规是否满足 JSON、长度、标签等硬性要求程序自动校验格式合规必须用程序校验不能只靠模型自己保证。4.3 用本地模型做 LLM-as-judge 的示例脚本可以用本地 Ollama 模型作为评估助手对回答进行打分。下面是一个 Python 示例用于说明评估流程import requests OLLAMA_URL http://localhost:11434/v1/chat/completions def judge(question, answer, reference): prompt f 你是质量评估助手。请从三个维度评估模型回答 1. 相关性回答是否贴合问题。 2. 忠实度回答是否依据参考材料是否存在编造。 3. 完整性回答是否包含关键信息。 请严格输出 JSON格式如下 {{相关性: 1-5, 忠实度: 1-5, 完整性: 1-5, 原因: 简短说明}} 问题{question} 参考材料{reference} 模型回答{answer} payload { model: qwen2.5:7b, messages: [{role: user, content: prompt}], temperature: 0 } resp requests.post(OLLAMA_URL, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: q RAG 的主要作用是什么 ref RAG 通过检索外部知识库为模型提供相关资料从而减少幻觉。 ans RAG 是从数据库里拿数据再让模型复述一遍。 print(judge(q, ans, ref))这个脚本只是评估闭环的第一版。真实项目还要把评估结果落库、计算平均分、记录模型版本和提示词版本这样每次改动都能对比。4.4 构建回归基线让每次改动都有对照评估集建议准备 50 到 200 条真实业务问题。规模不需要很大但必须覆盖正常问题、边界问题、缺参数问题、需要拒绝回答的问题。评估集维护在 Git 仓库中提示词或代码改动时运行一次把结果写入报告。当指标出现下降时优先排查三件事提示词是否改变了模型对任务的理解。模型版本或温度参数是否变化。RAG 召回内容是否有新增或删除文档。5. 部署、监控与成本把 AI 服务当成普通后端服务运维5.1 部署链路与模型服役方式AI 应用在部署时比普通后端服务多了一个模型依赖。模型可以本地部署也可以走企业模型网关。无论哪种方式都要在部署文档中明确模型服务地址、模型名称、版本号和超时时间。推荐将模型服务独立于业务应用部署。业务应用至少部署两个实例模型服务单独扩容。这样模型推理变慢时不会直接阻塞业务应用的全部线程。5.2 监控指标与日志规范只监控 CPU 和内存是不够的还要关注模型调用层面的指标指标说明排查价值请求延迟 P95模型生成耗时判断是否需要换小模型或加机器输入/输出 token 数单次请求成本发现提示词过长、循环调用问题工具调用失败率Agent 工具执行失败比例判断业务接口稳定性幻觉命中率回答与参考材料不一致比例判断 RAG 和提示词质量模型调用错误码超时、限流、连接错误快速定位服务异常日志中至少要记录用户输入摘要、模型返回摘要、模型名称、token 数、耗时时长和是否命中兜底逻辑。不要把完整敏感业务数据写入日志必要时做脱敏处理。5.3 成本与性能的量化选型模型选型不能只看效果还要结合调用频率和延迟要求做量化对比方案适用场景注意点开源小模型本地部署数据敏感、低频调用效果可能不如大模型需要评估集验证企业级模型服务高并发生产业务注意成本单价和调用限额混合路由简单问题用小模型难题用大模型需要先做问题分类复杂度更高生产环境建议先选一个保守方案跑通全链路再根据评估指标逐步切换更合适的模型不要一开始就追求“最强模型”。6. 常见问题排查链路6.1 现象、根因与检查顺序排查 AI 服务问题时建议按“输入是否正确 - 模型是否可用 - 提示词是否生效 - 工具是否执行正确 - 数据是否泄漏 - 监控是否覆盖”的顺序推进不要一上来就怀疑模型能力。问题现象常见原因检查方式处理建议调用 Ollama 超时模型未下载或服务未启动执行ollama list访问/api/tags启动服务并确认模型存在输出格式不稳定未设置格式约束或温度过高打印原始模型返回使用 JSON Schema温度调到 0.2 以下Agent 多次调用同一工具循环上限缺失查看日志中的工具调用序列设置最大迭代次数和中途停止条件回答中编造信息RAG 未命中或提示词未强制引用检查检索召回内容增加“没有材料就拒绝回答”的提示词约束模型返回为空内容过滤或超时截断查看响应头和日志错误码增加错误处理分支记录失败原因6.2 一份可直接复用的常见坑清单第一个坑提示词里让模型“一定不要编造”但没有给它足够的事实来源。模型会尽力猜测结果更容易产出含糊回答。正确做法是把检索到的资料直接放入提示词并明确说明“只能基于以下材料回答”。第二个坑评估时只看一两次输出就下结论。模型输出有随机性哪怕温度是 0不同模型版本和输入格式也可能导致差异。必须建立评估集用多次运行的平均表现做判断。第三个坑把工具执行结果直接拼进提示词却没有做数据清洗。如果工具返回的是异常堆栈或敏感数据模型可能把这些内容原样输出。工具返回前要经过白名单、脱敏和长度限制。第四个坑生产环境没有超时和重试机制。模型服务偶发变慢时调用线程会被长时间占用最终拖垮整个应用。必须为模型调用设置合理的超时、重试和熔断阈值。7. 从零进入 AI 工程实践的落地清单7.1 团队启动 AI 项目的七个检查点在实际项目中建议团队按下表逐项确认再进入开发[ ] 确认模型服务地址、模型名称和版本已写入配置支持环境隔离。[ ] 准备不少于 50 条真实评估问题覆盖正常、边界和拒绝回答场景。[ ] 定义模型输出的格式约束和解析失败后的兜底逻辑。[ ] 明确 Agent 可调用的工具清单、参数权限和高风险操作确认流程。[ ] 为每次模型调用记录 token 数、耗时、错误码和版本信息。[ ] 设置模型调用超时、重试次数和最大循环次数。[ ] 建立提示词、评估集、模型版本三者的对应关系保证改动可追溯。这七项不需要一次性做全但任何一项缺失都会在线上暴露成具体故障。7.2 学习路径与扩展方向如果你想从“会调用模型”进阶到“能落地 AI 系统”可以按下面的顺序继续学习深入理解提示词工程重点学习结构化输出和少样本示例。掌握 RAG 的关键环节文档切分、向量化、召回排序和引用溯源。学习 Function Calling 的协议细节理解工具参数约束和异常回传。实践 Agent 编排框架重点看任务拆解、循环控制和人工介入机制。学习模型评估与可观测性把评估集、日志、指标和成本数据串联起来。AI 工程实践本质上还是软件工程。你不需要在概念争论里站队也不需要恐惧模型会不会带来颠覆性变化只需要把问题拆成可评估、可验证、可回滚的工程任务一步步缩短从模型输出到业务价值之间的距离。这才是竞争环境下最稳妥的应对方式。