大模型应用落地：从Demo到生产的AI工程化关键与实践

过去两年，AI行业最像的不是技术发布会，而是电影发行：先放几分钟预告片，再定档期，然后所有人都在等正片。预告片阶段，我们看到了大量惊艳的demo：多模态对话、AI自动写代码、Agent自己规划任务并调用工具。这些画面让人产生一个强烈的错觉——AI已经成熟到可以随手改造任何业务了。

但真正把模型接进生产系统的工程师，正在经历另一件事：AI热潮撞上了一面很少有人公开讨论的墙。我把它叫做“重置墙”（reset wall）。它不是模型能力的墙，而是工程化的墙。预告片放完、灯光亮起之后，开发人员要面对的是稳定性、成本、评测、数据、合规、灰度回滚这些一点都不性感的词。

这篇文章要拆开这面墙，告诉你它由哪几块砖组成，以及从“能跑通demo”到“能上线业务”，中间到底缺了哪些工程动作。为了让你能直接落地，文章最后给出了一套最小可工程化的LLM应用框架代码：带超时重试与降级的模型调用客户端、遇到工具失败会自我纠错的Agent循环、RAG输出质量评测脚本，以及一份推理服务部署配置。

我的核心判断是：AI的下一波红利，不在“参数更大的模型”上，而在“能不能把模型可靠地放进业务系统”的工程能力上。谁先补齐这门AI工程实践课，谁就能熬过这次重置周期。

1. 这篇文章真正要解决的问题

先说一个观察：过去一年，很多团队都在同一个时间点卡住了。Demo阶段，模型表现惊艳，领导满意，产品经理激动。进入生产联调之后，问题开始出现——同样的用户问题，上午回答正常，下午开始胡说；一次Agent任务要调用五六次模型，账单增长比业务指标还快；说好的“智能客服能处理80%工单”，上线两周后变成“需要人工兜底的比例远超预期”。

这不是某个团队的问题。从行业报道、社区讨论和开源项目反馈看，这是一种普遍现象：AI的能力没有后退，但行业对AI的预期正在被生产环境重新定价。“重置墙”这个词，就是在描述这个重新定价的过程。

这篇文章要解决的问题，不是“怎么把提示词写得更好”，而是“怎么把大模型应用做成一个可靠、可评测、可控成本的工程系统”。具体包括四件事：

1. 讲清重置墙由哪几块砖组成，避免你把问题归因到错误的环节；
2. 给出从Demo思维切换到工程思维的四个关键转变；
3. 提供一套可以直接运行的最小代码框架（LLM客户端、Agent循环、RAG评测、部署配置）；
4. 整理排查方法和最佳实践，帮你少踩真实项目里的坑。

适合的读者：负责LLM应用落地的后端工程师；正在搭建Agent、RAG或智能客服系统的技术负责人；想从“调通接口”进化到“稳定上线”的AI应用开发者。

2. “预告期”与“重置墙”：两个概念先讲清楚

2.1 什么是AI的“预告期”

“预告期”不是一个正式术语，但它能很准确地描述过去两年的AI行业状态。类比来说，就是电影上映前发行方放预告片的那段时间：片段很短，画面最精彩，观众看完后对正片充满想象。

AI的预告期有几个特征：

• 演示用例是经过挑选的。越经典的demo，越能隐藏长尾输入、异常输入和上下文依赖；
• 评价标准是主观的。观众被效果震撼，不会去统计“连续调用1000次成功几次”；
• 成本被忽略。demo只需要跑通一次，不需要考虑每token的边际成本；
• 没有人会去测试失败路径。没人问“如果模型输出不是合法JSON怎么办”“如果工具超时了怎么办”。

这些特征让AI看起来比实际成熟得多。预告期存在本身没有错，错的是把预告片当正片。从历史看，云计算、大数据、微服务都经历过类似的预告期。阶段转换的信号，通常是“演示的边际收益开始低于工程化的边际成本”——当越来越多的人意识到“跑通demo并不等于能上线”，预告期就结束了。

2.2 什么是“重置墙”

“重置墙”是本文对当前阶段现象的一个概括：当乐观预期碰到生产约束，行业会对AI的能力、成本和风险做一次重新校准。

这里要强调，“重置”不等于否定。“重置”更像估值逻辑切换：过去两年，行业的注意力集中在模型参数、榜单分数和“人类水平”的标签上；接下来的注意力会转移到另一个坐标——可靠性、可评测性、成本效率、数据合规、运维能力。

换句话说，重置墙不只是给模型设的，也是给工程团队设的。模型能力仍然是基础，但决定AI项目生死的，已经从“模型能不能做到”变成了“系统能不能稳定交付”。

2.3 Demo与生产环境的本质差异

用表格对比更直观：

这张表的本质是：同一个模型，进入生产环境后约束和验证方式完全不同。重置墙的核心矛盾，是“概率模型进入确定性系统”的冲突。

3. 重置墙的四块砖：可靠性、成本、评测、数据

3.1 可靠性墙：概率系统要按确定性标准运行

传统软件是确定性系统：同一输入，同一代码路径，结果可复现。LLM不是。即使temperature设为0，由于采样方式和服务端实现差异，多次调用仍可能给出不同输出；而幻觉的存在，让模型可能用非常流畅、确定的语气编造一个完全不存在的“事实”。

如果你把LLM当成普通API来用，就会撞上可靠性墙。比如智能客服把不存在的退款政策说得头头是道；Agent调完库存接口后，在总结时漏掉了关键信息；代码生成工具在业务代码里插入不存在的库函数。

应对可靠性墙的方法，不是换一个“更聪明的模型”，而是用工程手段限制不确定性的影响范围：输出结构约束、JSON Schema校验、内容合法性校验、更严格的few-shot示例、引入确定性检索结果、外部规则兜底。这些动作合起来，叫做护栏（guardrails）。

工程上的原则是：模型负责生成，系统负责校验；模型可以犯错，系统不能让错误直接到达用户。

3.2 成本墙：模型越强，Agent越贵

很多团队低估了“调用成本”对架构的影响。LLM服务是按token计费的，输入和输出都要付钱。一次简单的Agent任务，可能包含：主模型推理、工具结果总结、异常后重试、再次推理，整体调用次数是用户在界面上看到的那一轮对话的好几倍。

成本墙带来的后果不是“稍微贵一点”，而是业务模型不成立。比如某个自动化场景，人工处理成本是2元，Agent推理平均成本8元，体验再好，业务侧也很难接受。

成本治理要从架构上做，而不是事后看账单：

• 建立缓存：对常见问题、可复用的生成结果做语义缓存或精确缓存；
• 设置步数上限：Agent循环要有最大步数，防止死循环；
• 模型分层：把简单分类、意图识别交给小模型，把复杂生成交给大模型；
• 控制上下文：检索时限制输入给模型的片段数量，别把整个知识库塞进提示词；
• 监控token：每次调用记录prompt和completion的token量，让成本可视化。

3.3 评测墙：没有评测，就没有优化与回归

模型榜单分数和业务质量之间，隔着一条很宽的评测沟。公开榜单一类是“知识竞赛型”，测的是模型知道什么；而业务关心的是“在特定数据、特定提示词、特定工具链下，模型输出是否符合预期”。

没有评测体系时，团队优化提示词完全靠感觉：上午改几个字，感觉回答变好了；下午再改回去，又觉得不如早上。你无法判断是谁引起的、什么时候引入的回归。

评测墙的解法是先建立最小评测集。不需要一开始做得很庞大，几十条覆盖典型场景和已知badcase的问题，加上人工或LLM裁判打分，就能形成回归基线。每次改提示词、换模型、调整检索参数，都跑一遍评测，分数下降就回滚。这套流程，是把LLM开发从“玄学”变成“工程”的关键一步。后面第5.3节会给出一个可运行的评测脚本。

3.4 数据墙：模型不掌握你的业务

很多AI应用失败，不是模型不够强，而是模型根本拿不到需要的数据。企业里的订单、库存、客户、合同，散落在多个系统里，格式不同、口径不同、权限不同。RAG看似解决“知识注入”问题，实际只是把问题往前挪了一步：检索质量取决于数据质量。

数据墙还包含安全和合规问题：企业内部知识库能不能全部给模型调用？哪些字段是敏感的？员工提问是否会间接泄露权限外的数据？这些不能依靠“让模型自己判断”，必须在数据接入层做权限控制和脱敏。

更稳妥的做法是：先梳理业务流程中真正需要模型的部分，再把数据治理做好，最后才考虑模型选型。数据墙往往是最不性感、但最花时间的一堵墙。

4. 从Demo到生产：AI工程实践的四个关键转变

4.1 从“选模型”到“设计系统”

Demo阶段的第一个问题是“该用哪个模型”。工程阶段的问题是“整个系统怎么分层”。同一个业务里，完全可以同时存在多个模型：意图识别用小模型，检索重排用小模型，最终回答生成用大模型，敏感内容审核用专用模型。

模型选型不再是单选题，而是系统架构的一部分。要考虑的因素包括：延迟要求、成本预算、数据是否允许出境、是否需要私有化部署、推理服务的高可用方案。模型部署也不再是“跑个容器”那么简单，而是要考虑并发、弹性伸缩、灰度切换和回滚策略。

4.2 从“提示词工程”到“护栏工程”

提示词工程仍然重要，但它只是起点。真正决定生产质量的是护栏：输出格式校验、事实一致性校验、敏感词过滤、拒绝策略、超时与重试策略。护栏要写在调用链路上，而不是写在提示词里，因为提示词是软约束，代码校验才是硬约束。

一个典型的反模式是：把所有逻辑都堆进提示词，指望模型“自己理解规则”。一旦模型更新，同样的提示词可能输出完全不同的格式，业务代码却还在按旧格式解析，直接导致线上故障。护栏的本质，是让系统对模型输出的格式和合法性有明确预期。

4.3 从“单次调用”到“全链路可控”

Demo只需要一次成功的模型调用。生产环境需要记录完整调用链：用户输入、检索结果、提示词版本、模型输出、工具调用结果、重试次数、耗时和费用。把这些数据串起来，才能回答最关键的三个问题：出问题时是哪一环出了问题？这次调用花了多少钱？模型行为是不是在回归？

全链路可控依赖日志和可观测性。后面5.1节的客户端就会演示最简单的降级记录，实际项目里可以继续接入调用链追踪、metrics和告警。

4.4 从“拍脑袋”到“评测驱动开发”

这是所有转变中最重要的一项。评测驱动开发（Evaluation-Driven Development）的意思是：先把“什么叫好”定义成可执行评测用例，再开始调优。没有评测，就没有基线；没有基线，就没有回归；没有回归，就不敢升级模型、改提示词、调参数。

5. 最小可工程化的LLM应用：完整代码演示

下面四段代码组成一个最小闭环，适合作为AI工程实践的起步骨架。所有代码基于OpenAI兼容的/v1/chat/completions接口编写，可以适配主流的云端模型服务和本地vLLM部署，具体地址和Key请按你的环境替换。

5.1 LLM客户端：超时、重试与降级

第一个要解决的问题是“模型服务不可用怎么办”。生产环境里模型服务可能超时、限流或直接报500，客户端必须把降级逻辑写进调用链，而不是让上层业务直接崩溃。

# llm_client.py """ 带超时、降级的LLM调用客户端。 基于 OpenAI 兼容接口 /v1/chat/completions 编写。 """ import json import logging import time import requests logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") logger = logging.getLogger("llm_client") class LLMClient: def __init__(self, api_base: str, api_key: str, model: str, fallback_model: str = None, timeout: int = 30): self.api_base = api_base.rstrip("/") self.api_key = api_key self.model = model self.fallback_model = fallback_model or model self.timeout = timeout def chat(self, messages, temperature=0.3, max_tokens=1024): url = f"{self.api_base}/v1/chat/completions" headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", } payload = { "model": self.model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } try: return self._post_once(url, headers, payload) except requests.exceptions.Timeout: logger.warning("模型 %s 超时，自动降级", self.model) return self._fallback_once(url, headers, payload) except requests.exceptions.HTTPError as e: code = e.response.status_code if code in (429, 500, 502, 503, 504): logger.warning("模型 %s 返回状态码 %s，自动降级", self.model, code) return self._fallback_once(url, headers, payload) raise def _post_once(self, url, headers, payload): resp = requests.post(url, json=payload, headers=headers, timeout=self.timeout) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] def _fallback_once(self, url, headers, payload): time.sleep(1) payload["model"] = self.fallback_model return self._post_once(url, headers, payload) if __name__ == "__main__": client = LLMClient( api_base="http://localhost:8000", api_key="sk-demo", model="model-a", fallback_model="model-b", ) reply = client.chat( messages=[{"role": "user", "content": "用一句话解释什么是RAG"}], temperature=0.2, ) print(reply)

这段代码的重点：

• 主模型异常（超时、限流、5xx）时自动切到备用模型，而不是直接把异常抛给上层业务；
• 降级前等待1秒，给上游服务一点恢复时间；
• 429和5xx才降级，4xx认证错误直接抛异常，避免把配置错误当成故障掩盖掉。

实际生产中可以继续扩展指数退避重试、熔断器、限流和调用记录上报，但对于起步项目，这个客户端已经能挡住最常见的故障。

5.2 Agent执行器：工具失败时如何自我纠错

Agent是当前LLM应用里最热门的场景之一，也是最容易翻车的地方。下面这段代码演示一个最小客服Agent：模型如果需要工具，输出JSON指令；执行器调用工具后把结果回传，循环直到模型给出最终回答。关键设计是工具失败时明确告诉模型“不要编造结果”。

# agent_customer_service.py """ 带工具调用和自我纠错的客服Agent最小实现。 """ import json import logging logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") logger = logging.getLogger("agent") TOOL_REGISTRY = { "query_order": { "desc": "查询订单状态", "params": {"order_id": "string"}, }, "calc_refund": { "desc": "计算退款金额", "params": {"order_id": "string", "operator": "string"}, }, } SYSTEM_PROMPT = """你是电商客服助手。你可以调用以下工具： {} 调用工具时，只输出JSON：{{"tool": "工具名", "arguments": {{"参数名": "值"}}}} 不需要调用工具时，直接输出给用户的回答。 """.format(json.dumps(TOOL_REGISTRY, ensure_ascii=False)) def execute_tool(tool_name: str, args: dict) -> dict: """示意实现：实际项目中替换为订单系统、库存系统的真实调用。""" if tool_name == "query_order": if args.get("order_id") == "0": raise ConnectionError("订单服务暂时不可用") return {"order_id": args.get("order_id"), "status": "已发货"} if tool_name == "calc_refund": return {"order_id": args.get("order_id"), "refund_amount": 199.00} raise ValueError(f"未知工具: {tool_name}") def run_agent(user_input: str, llm_client, max_steps: int = 4): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input}, ] for step in range(max_steps): raw = llm_client.chat(messages, temperature=0.0) messages.append({"role": "assistant", "content": raw}) try: call = json.loads(raw) tool_name, args = call["tool"], call.get("arguments", {}) except (json.JSONDecodeError, KeyError, TypeError): return raw # 不是工具调用JSON，视为最终回答 if tool_name not in TOOL_REGISTRY: messages.append({"role": "user", "content": "提示：你调用了不存在的工具，请基于已有信息直接回答用户。"}) continue try: result = execute_tool(tool_name, args) except Exception as e: logger.error("工具 %s 执行失败: %s", tool_name, e) messages.append({"role": "user", "content": "提示：工具执行失败，请如实告诉用户暂时无法处理，不要编造结果。"}) continue messages.append({"role": "user", "content": f"工具执行结果：{json.dumps(result, ensure_ascii=False)}，" f"请根据结果回答用户或继续调用其他工具。"}) return "抱歉，我暂时无法完成这个请求。" if __name__ == "__main__": from llm_client import LLMClient client = LLMClient( api_base="http://localhost:8000", api_key="sk-demo", model="model-a", fallback_model="model-b", ) # order_id=0 会触发订单服务异常，用来观察Agent的纠错行为 print(run_agent("我的订单号是0，帮我查一下状态", client))

这段代码体现了Agent工程化的两个核心点：

• 步骤上限：无论模型怎么绕，最多执行max_steps轮，防止死循环和费用失控；
• 失败显式化：工具抛异常时，把“不要编造结果”作为强指令回传给模型。相比让模型自由发挥，这种显式纠错能显著降低幻觉输出。

实际项目中，你还需要把工具注册表改成真正的服务调用，并给每次调用加超时和鉴权。更进一步，可以把这类“自主容错控制”扩展成独立模块：先记录失败类型，再决定是重试、换工具还是转人工，而不是让模型自己决定。

5.3 RAG评测脚本：用LLM当裁判

评测是工程化的重要一环。下面的脚本用LLM作为裁判，分别评估“相关性”和“忠实度”，输出结构化分数，便于加入CI回归。

# evaluate_rag.py """ RAG输出质量评测脚本：以LLM为裁判，输出相关性/忠实度分数。 """ import json import logging logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") logger = logging.getLogger("eval") EVAL_CASES = [ { "question": "订单超过多久未发货可以申请补偿？", "reference": "根据售后规则，订单超过48小时未发货，用户可以联系客服申请补偿。", }, { "question": "退款一般多久到账？", "reference": "退款审核通过后原路退回，通常1-3个工作日到账。", }, ] EVALUATOR_PROMPT = """你是评测员。请根据参考答案评估模型回答。 评分维度： - relevance(0-10)：是否直接解答了用户问题； - faithfulness(0-10)：是否与参考答案一致，是否存在编造信息。 只输出JSON：{"relevance": 8, "faithfulness": 7}""" def evaluate_answer(llm_client, question, answer, reference): messages = [ {"role": "system", "content": EVALUATOR_PROMPT}, {"role": "user", "content": json.dumps({ "question": question, "answer": answer, "reference": reference, }, ensure_ascii=False)}, ] raw = llm_client.chat(messages, temperature=0.0, max_tokens=200) try: return json.loads(raw) except json.JSONDecodeError: logger.warning("评测输出不是合法JSON: %s", raw) return {"relevance": 0, "faithfulness": 0} def run_evaluation(llm_client, cases): total = {"relevance": 0.0, "faithfulness": 0.0} for case in cases: # 实际项目中，answer 应来自待评测的RAG/Agent服务 answer = llm_client.chat( messages=[{"role": "user", "content": case["question"]}], temperature=0.0, ) score = evaluate_answer(llm_client, case["question"], answer, case["reference"]) for key in total: total[key] += score.get(key, 0) logger.info("问题: %s -> %s", case["question"], score) n = len(cases) or 1 return {key: round(value / n, 2) for key, value in total.items()} if __name__ == "__main__": from llm_client import LLMClient client = LLMClient( api_base="http://localhost:8000", api_key="sk-demo", model="model-a", fallback_model="model-b", ) result = run_evaluation(client, EVAL_CASES) print("评测结果:", result)

为什么要用LLM当评测员？因为传统的关键词匹配很难衡量“语义上是否正确”。LLM评测虽然不是完美方案，但对早期团队来说，它比人肉抽查稳定，比纯规则覆盖广。注意两点：评测时temperature要设为0，保证分数可复现；评测用例要围绕真实业务badcase持续扩充，而不是只用“容易答对”的题目。

5.4 推理服务与应用的部署配置

模型调用、Agent、评测都准备好后，需要一个干净的部署方式。下面是一份最小容器化配置，应用通过环境变量访问推理网关，方便在测试和生产环境间切换模型。

# Dockerfile FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src/ src/ ENV LLM_API_BASE=http://llm-gateway:8000 ENV MODEL_PRIMARY=model-a ENV MODEL_FALLBACK=model-b EXPOSE 8000 CMD ["uvicorn", "src.app:app", "--host", "0.0.0.0", "--port", "8000"]

# docker-compose.yml services: ai-app: build: . environment: LLM_API_BASE: http://llm-gateway:8000 MODEL_PRIMARY: model-a MODEL_FALLBACK: model-b ports: - "8000:8000" restart: unless-stopped

生产环境建议把LLM_API_BASE指向统一的推理网关，而不是让应用直接连接具体模型实例。这样更换模型、灰度发布、排查问题时，都不需要改业务代码。模型部署的另一个关键点是推理服务的弹性伸缩：LLM推理是计算密集型的，要针对并发和排队做好容量规划，而不是只依赖容器默认配置。

6. 运行与效果验证

先准备一个OpenAI兼容的模型服务。本地开发可以直接启动vLLM等推理框架，也可以使用云端模型服务的兼容接口：

# 以vLLM为例：启动OpenAI兼容的本地推理服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --port 8000

然后依次验证：

# 1. 验证LLM客户端：输出一句关于RAG的解释 python llm_client.py # 2. 验证Agent纠错：输入order_id=0时应返回“暂时无法处理”，而不是编造订单信息 python agent_customer_service.py # 3. 运行评测：打印每题分数和平均分 python evaluate_rag.py # 4. 容器化启动 docker compose up -d --build

重点观察Agent的纠错行为：因为execute_tool在order_id=0时抛出ConnectionError，客户端把“不要编造结果”回传给模型，最终Agent应当诚实告知无法处理。如果这里模型仍然编造了订单状态，说明要么提示词约束不够强，要么模型不理解“工具执行结果”消息的含义，需要调整消息格式。

评测脚本的预期输出类似：

INFO 问题: 订单超过多久未发货可以申请补偿？ -> {'relevance': 9, 'faithfulness': 8} INFO 问题: 退款一般多久到账？ -> {'relevance': 8, 'faithfulness': 8} 评测结果: {'relevance': 8.5, 'faithfulness': 8.0}

如果所有步骤都失败了，先用curl http://localhost:8000/v1/models确认推理服务是否可访问，再检查api_base、api_key和模型名是否匹配。

7. 常见问题与排查思路

排查的总原则是：先看调用链，再看提示词，最后才看模型。大多数生产问题都出在调用链的设计上，而不是模型本身。

8. 最佳实践与工程建议

8.1 先建评测，再调优

没有评测基线，任何提示词改动都可能引入看不见的回归。建议从第一天就维护一个业务评测集，哪怕只有几十条用例。评测集要覆盖：典型场景、边界输入、恶意输入、已知badcase。每次改提示词、换模型、调检索参数，都跑一遍。

8.2 把模型当作“不可靠的外部依赖”对待

和数据库、消息队列打交道的经验在这里同样适用。所有模型调用都要有：超时、重试上限、降级、熔断、日志。别把模型当作本地函数直接调用，尤其是Agent场景，每多一步调用，失败面就扩大一圈。

8.3 成本治理进入架构设计

缓存、模型分层、上下文裁剪、步数上限，这些要在设计阶段就做。尤其注意Agent的“放大效应”：用户问一句话，内部可能调用模型五六次。上线前用压测脚本估算单会话平均成本，再决定业务定价和流量规划。

8.4 安全与合规当作上线前置条件

涉及生产数据时，遵循最小权限原则：模型只能访问任务需要的数据；检索结果按用户权限过滤；日志中不能记录明文敏感字段。对提示词注入、越权检索、输出泄露保持警惕，必要时增加专门的内容审核模型和关键词过滤层。

8.5 版本化一切可版本化的东西

模型版本、提示词、评测集、检索参数，全部纳入版本管理。这样出现质量回退时可以快速定位：是模型升级了、提示词被改了，还是检索数据变了。模型和提示词不版本化，AI应用就不具备可回滚性。

8.6 从最小闭环开始

不要一上来就设计复杂多Agent系统。先跑通“单模型调用+降级+RAG+评测”的最小闭环，再逐步增加工具、编排和自动化。复杂度的增加必须伴随评测和可观测性的同步增加，否则出问题后你根本找不到原因。

9. 总结与后续学习方向

“预告期”里，我们看到的是AI能做什么；“重置墙”出现之后，更值得关注的是AI系统能不能稳定“上市”。这篇文章的核心可以浓缩成三条：

• 重置墙的本质是概率模型进入确定性系统的冲突，它由可靠性、成本、评测、数据四块砖组成；
• 破解重置墙的关键转变是：选模型变成设计系统，提示词工程变成护栏工程，单次调用变成全链路可控，拍脑袋变成评测驱动开发；
• 工程化落地可以从小处开始：带降级的LLM客户端、带自我纠错的Agent循环、RAG评测脚本、一份容器化部署配置，就是一个不错的最小闭环。

下一步可以深入的方向：RAG检索质量优化（切分策略、重排、混合检索）、Agent的长期记忆与规划能力评测、模型蒸馏和私有化部署、LLM应用的可观测性与成本监控平台。

下次再看到惊艳的AI演示时，不妨问问自己：这段demo遇到一个乱输入的订单号会怎么处理？模型服务超时了，系统是降级、等待还是报错？这些问题，才是决定AI项目能不能真正活下去的考题。建议收藏本文，启动下一个AI项目时，对照第4到第8章做一次工程自查。