2024 年做一个能对话的 AI 聊天 Demo还值得发一篇技术博客2025 年再发同样的 Demo评论区大概率会问然后呢这不是开发者变挑剔了而是 AI 应用开发的叙事真的变了。过去一年多的主线是模型能力竞赛大家都在追参数、追榜单、追多模态。但当模型能力逐渐变成标准化 API算力成本持续下降开源模型快速追赶之后应用层的竞争焦点就会迅速转移到一个更本质的问题上谁能把模型稳定、安全、可控地嵌入真实业务流程并产生可衡量的业务价值。这篇文章想表达一个明确判断AI 下半场应用的新叙事核心就是两个字——系统化。Model 能力已经不再是唯一变量Context、Tools、Evaluation、Observability 这些传统软件工程要素重新成为 AI 应用竞争的主战场。我会先讲清楚叙事为什么变了再拆解 AI 应用从 Demo 到系统的几个关键阶段最后用一个可复制的最小订单客服助手示例演示模型路由、工具调用、结构化输出和评估闭环怎么落地并给出生产环境常见问题和工程建议。全文把思路和代码放在一起建议先收藏后文可以照着跑。1. 为什么“AI 应用的新叙事”从模型转向了应用先看三个行业层面的信号。第一个信号产品话语体系正在变化。早期很多产品喜欢强调“接入了大模型”“支持多模态”。现在这类描述已经很难打动技术决策者大家更关心的是你的 AI 功能是否接入了真实数据是否有人负责权限校验模型答错之后流程怎么兜底有没有评估集说明效果上限第二个信号创业和内部项目的验收标准在变化。过去验收一个 AI Demo看的是“能不能生成像样的文本”。现在的验收标准变成“这个功能跑在核心链路里吞掉了多少工单降低了多少耗时准确率有没有业务指标支撑”也就是说AI 从展示品变成了生产力工具从“会聊天”变成了“能干活”。第三个信号技术栈重心在转移。两年前聊 AI 应用绕不开 Prompt 技巧一年前聊 AI 应用绕不开 RAG 召回率现在聊 AI 应用讨论最多的是工作流编排、工具调用协议、模型路由、评测数据集和可观测性。这不是说 Prompt 和 RAG 不重要而是它们已经从“全部”变成“一部分”。这背后其实是一个技术演变规律当一个能力被平台化、标准化之后它在应用层的稀缺性就会快速下降。模型推理能力正在走这条路。于是应用层的竞争就回到了软件工程的基本盘——如何在一个复杂系统里让不可完全预测的模型输出变得可控、可审计、可回滚。如果把 AI 项目按照这个逻辑重新审视你会发现大部分项目的风险根本不是“模型能力不够”而是“应用边界没设计好”数据权限不可控、工具调用不可追踪、输出格式不稳定、没有评测闭环、模型升级一次线上行为就漂移一次。这些问题不是换一个大模型能解决的需要用工程手段系统性解决。所以AI 下半场的应用新叙事本质上是从“模型叙事”走向“工程叙事”。接下来的几个章节我会把这个叙事拆成开发者的具体动作。2. 从调用模型到构建系统AI 应用开发的四个阶段要理解“AI 应用的系统化”可以先看 AI 应用演进的四个阶段。大部分团队都在这四个阶段里移动但很多团队并没有意识到自己停在了哪个阶段。2.1 阶段一聊天玩具特征拿一个模型 API写一段 System Prompt做一个对话框。能回答通用问题能生成文案但无法访问业务数据无法执行操作无法验证回答正确性。典型问题用户问“我的订单到哪了”它只能说“你可以去订单页面查看”。这在技术上是跑通的在业务上是无效的。2.2 阶段二RAG 套壳应用特征在模型之外增加向量数据库通过召回相关文档片段拼进 Prompt让模型基于资料回答。这是目前最常见的一类 AI 应用形态。典型问题召回质量不稳定、引用来源不可靠、知识更新滞后。很多时候用户一眼就能看出答案是“拼接感”很强的而不是真正理解了业务。2.3 阶段三Agent 工作流特征模型可以通过函数调用访问外部工具——查订单、调接口、写库、发消息。多轮对话中模型自己决定调用哪些工具并根据工具结果继续推理。典型问题工具调用不可控、循环不退出、权限边界模糊。Agent 能做了很多事但也可能做错很多事。2.4 阶段四业务原生系统特征AI 不再是一个独立对话框而是嵌入业务系统的模块。它有明确的输入输出约束、权限校验、审计日志、成本预算、评测集和灰度机制。用户无感知它在用 AI只觉得“系统变聪明了”。判断一个应用属于哪个阶段看它失败时会发生什么就知道了阶段一失败用户关掉页面阶段二失败用户骂答案不准阶段三失败可能出现脏数据或越权操作阶段四失败有日志、有监控、有回滚、有补偿机制。用表格总结一下阶段核心技术对业务的价值最大的坑聊天玩具Prompt 模型 API几乎为零无法对接业务RAG 套壳向量检索 拼接信息查询类可用回答准确率难保证Agent 工作流工具调用 多轮规划能执行一部分业务操作失控风险高难调试业务原生系统工程集成 评估 可观测性可嵌入核心链路工程复杂度上升结论很清楚真正能被业务接受的 AI 应用一定是从阶段三向阶段四演进。而推动这个演进的三个核心工程问题分别是上下文工程、工具调用与编排、评测与可观测性。接下来逐个拆解。3. 上下文工程真正拉开差距的软件问题先说一个判断Prompt 技巧正在贬值上下文工程正在升值。为什么因为大模型本身的指令理解能力一直在提升。一年前需要用复杂 Prompt 约束的格式现在用 JSON Mode 或结构化输出原生解决。但应用侧的上下文复杂度却在指数级上升业务知识、用户画像、历史会话、实时数据、工具返回结果这些信息怎么组织、怎么筛选、怎么压缩决定了大模型输出的质量上限。3.1 上下文不是一个“塞”字能解决的新手最容易犯的错误是把能拿到的信息全部塞进 Prompt觉得上下文越长模型越聪明。真实情况是长上下文有成本问题。Token 费用按输入长度计算塞入无关内容直接浪费预算。长上下文有延迟问题。输入越长首字延迟越高用户体感变差。长上下文有注意力稀释问题。无关信息太多模型反而更容易忽略关键业务约束。所以上下文工程的第一原则是不是塞进去而是选进来。你要让模型看到它决策所必需的最小信息集。3.2 上下文工程的三个关键手段第一检索。RAG 系统的召回质量不只是向量相似度的问题。分块策略、元数据过滤、查询改写、重排每一步都能影响最终输入给模型的内容。经常被忽视的是分块固定长度按字符切分虽然简单但会把语义完整的段落切断。更稳妥的做法是按章节、段落、表格语义边界切分让每个块尽量表达一个完整信息单元。第二压缩。当历史会话过长时不是把全部消息原样塞回而是先生成结构化摘要。比如用户问了什么、系统答了什么、最终订单状态是什么、用户情绪是否激动。这些结构化信息保留下来比完整历史更有用也更能控制成本。第三预算。把上下文按优先级分层——固定系统约束、业务规则、用户数据、检索资料、历史摘要。给每一层设定最大 Token 预算超过预算就裁剪或压缩。只有先学会控制“输入长度”模型输出的稳定性和成本才能同时得到保证。上下文工程做得好不好最直接的观测指标就是当模型输出出错时你能不能快速定位是所有必要信息都给了但模型理解错还是必要信息根本没被选进来。前者是模型问题后者是应用问题——而后者的修复成本通常远低于前者。4. 工具调用与 Agent 编排从单次问答到业务闭环如果说上下文工程是让 AI“说得准”那么工具调用就是让 AI“做得到”。这是 Agent 从演示走向生产的关键转折。4.1 Function Calling 不是新鲜事但工程化是模型通过函数调用访问外部系统技术上已经有成熟方案。但真正的问题不是“能不能调用”而是“该不该调用、调用了之后怎么校验结果”。在业务系统里工具调用必须遵守几个硬约束最小权限。工具签名只暴露必要参数。比如订单查询工具只接受 order_id不接受“查询任意用户所有订单”的入口。用户身份从会话上下文获取而不是让模型生成。幂等性。同一个工具调用因网络重试执行两次不能产生两条重复工单。写操作必须做幂等控制。超时与熔断。外部服务不可用时Agent 不能无限等待。要给工具调用加超时超时后进入兜底回复流程。审计追踪。每一次工具调用都要记录模型名、输入参数、执行结果、耗时、Token 消耗。没有审计日志的 Agent 不值得上线。4.2 Agent 编排把模型关进一个有边界的车间很多团队对 Agent 的想象是“让模型自己规划、自己执行到底”。但在生产环境里更稳妥的姿势是“有限自主”给模型一个明确的任务范围、可调用的工具清单、必守的规则以及最大循环次数。举个例子一个订单客服 Agent用户身份由系统注入不由模型猜测只能调用订单查询工具不能调用退款接口除非进入二次确认流程每轮对话最多执行 3 次工具调用超过次数直接转人工所有工具返回结果会经过一层服务端校验不允许模型把“查无此单”编造成“订单异常”。这样的 Agent 不是完全自主的“智能体”而是一个被工程约束的“流程执行器”。恰恰是这种约束才让它变得可用、可控。4.3 ReAct 模式的简化理解ReActReasoning Acting是当前 Agent 工作流的一种常见模式模型先推理下一步该做什么然后调用工具观察结果再继续推理。在生产代码里它可以简化为两步循环模型根据当前对话状态决定是否调用工具、调用哪个工具。如果没有工具调用直接生成最终回答如果有工具调用把工具结果追加回对话再执行一次推理。下面这个最小示例就是把上面这套设计落到代码里。5. 最小 AI 应用系统设计与完整代码实现为了把前文抽象概念变成可运行的东西我设计了一个最小订单客服助手。它的业务很简单用户查询自己的订单状态系统判断问题复杂度选择适合的模型必要时调用订单查询工具最后给出回答并记录 Token 消耗和延迟。5.1 系统拆解整个系统分四层入口层接收用户问题和用户 ID。路由层根据业务关键词决定使用快模型还是强模型。工具层提供订单查询函数并在函数内部做用户身份校验。LLM 层调用模型生成回复支持工具调用记录日志。5.2 第一步配置文件# config/app.yaml app: name: minimal-ai-assistant debug: false model: fast: fast-model-id # 替换为你所用平台的轻量模型 ID smart: smart-model-id # 替换为你所用平台的强推理模型 ID router_keywords: - 订单 - 物流 - 退款 - 换货 tool: order_query: enabled: true max_calls_per_conversation: 3 timeout_seconds: 5 logging: level: INFO output: ./logs/assistant.log这个配置的核心是“路由关键词”和“工具调用次数上限”。前者控制成本后者控制 Agent 失控风险。实际项目中路由逻辑可以换成更复杂的意图分类模型但规则本身就是一道可靠兜底。5.3 第二步核心代码# src/assistant.py import json import logging import os import time # 以下为演示客户端。 # 如果你接的是其他模型平台把 OpenAI 替换为对应 SDK 即可。 from openai import OpenAI logging.basicConfig( levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) logger logging.getLogger(minimal-assistant) client OpenAI() FAST_MODEL os.getenv(FAST_MODEL, fast-model-id) SMART_MODEL os.getenv(SMART_MODEL, smart-model-id) ROUTER_KEYWORDS [订单, 物流, 退款, 换货] MAX_TOOL_CALLS int(os.getenv(MAX_TOOL_CALLS, 3)) def route_to_model(message: str) - str: 极简路由命中业务关键词走强模型否则走快模型。 if any(kw in message for kw in ROUTER_KEYWORDS): return SMART_MODEL return FAST_MODEL def query_user_context(user_id: str) - dict: 演示用上下文获取生产环境应从会话服务读取。 return {user_id: user_id, display_name: demo-user} def query_order_status(user_id: str, order_id: str) - dict: 工具函数查询订单物流状态。 生产环境需要接入真实订单服务并在下游再做一次鉴权。 # 演示用越权拦截真实环境不能依赖模型层做权限判断。 if user_id ! demo-user: return {error: permission_denied} # 演示数据真实实现应查数据库或下游 API。 return { order_id: order_id, status: shipped, latest_station: 华东转运中心, } TOOLS [ { type: function, function: { name: query_order_status, description: 查询当前登录用户在平台上的订单物流状态必须传入用户自己的订单号。, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id], }, }, } ] def run(question: str, user_id: str) - dict: started time.time() user_context query_user_context(user_id) messages [ { role: system, content: ( 你是订单客服助手。 你只能查询当前登录用户的订单不得编造订单状态。 涉及订单查询时先调用工具再基于工具结果回答。 ), }, { role: user, content: f用户信息{json.dumps(user_context, ensure_asciiFalse)}\n问题{question}, }, ] model route_to_model(question) logger.info(routed model%s question%s, model, question) # 第一轮调用让模型决定是否需要调用工具 response client.chat.completions.create( modelmodel, messagesmessages, toolsTOOLS, tool_choiceauto, ) choice response.choices[0] tool_calls choice.message.tool_calls or [] tools_called [] # 如果有工具调用先追加助手消息再依次追加工具返回结果 if tool_calls: messages.append(choice.message) for tc in tool_calls[:MAX_TOOL_CALLS]: if tc.function.name query_order_status: try: args json.loads(tc.function.arguments) except json.JSONDecodeError: args {} order_id args.get(order_id, ) result query_order_status(user_id, order_id) tools_called.append(tc.function.name) logger.info( tool_called name%s order_id%s result%s, tc.function.name, order_id, result, ) messages.append( { role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse), } ) # 第二轮调用结合工具结果生成最终回答 if tool_calls: final_response client.chat.completions.create( modelmodel, messagesmessages, ) final_text final_response.choices[0].message.content else: final_text choice.message.content elapsed_ms (time.time() - started) * 1000 token_cost response.usage.total_tokens if response.usage else 0 logger.info( finished elapsed_ms%.1f tokens%d tools_called%s, elapsed_ms, token_cost, tools_called, ) return { reply: final_text, model_used: model, tokens: token_cost, tools_called: tools_called, } if __name__ __main__: result run(我的订单 20250001 现在到哪了, demo-user) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码要表达的不是某个特定 SDK 的用法而是三个工程化思想路由即成本控制。简单寒暄走快模型业务查询走强模型用最少成本完成必要推理。工具返回值不直接透传。查询工具内部先做用户身份校验从服务端杜绝越权不把安全交给模型自觉。完整调用链路被日志记录。模型名、工具调用、Token 数、延迟全部落日志为后续评估和排查提供依据。5.4 第三步评估脚本有评估集的 AI 应用才算进入系统化管理。下面是一个极简回归脚本用来在修改 Prompt、切换模型、调整工具逻辑后快速验证核心行为没有跑偏。# scripts/evaluate.py import json from src.assistant import run CASES [ {question: 你好, expect_tool: False}, {question: 我的订单 20250001 现在到哪了, expect_tool: True}, {question: 你们平台的退款流程是什么, expect_tool: False}, ] def main(): passed 0 for case in CASES: result run(case[question], user_iddemo-user) has_tool len(result[tools_called]) 0 ok has_tool case[expect_tool] print( f{case[question]} - {passed if ok else failed} fmodel{result[model_used]} tools{result[tools_called]} ) if ok: passed 1 print(fpass rate: {passed}/{len(CASES)}) if __name__ __main__: main()这个评估脚本很简单但已经是完整的回归测试雏形给定输入、断言行为、统计通过率。实际项目中评估集会扩展到上百条案例覆盖正常查询、用户情绪、模糊表述、越权尝试、模型幻觉等场景并且接入 CI任何 Prompt 或模型版本变更都必须跑通评估集才能上线。6. 运行效果与验证方式先安装依赖pip install openai pyyaml然后设置模型环境变量export FAST_MODEL你的快模型ID export SMART_MODEL你的强模型ID运行评估脚本python scripts/evaluate.py预期输出类似你好 - passed modelfast-model-id tools[] 我的订单 20250001 现在到哪了 - passed modelsmart-model-id tools[query_order_status] 你们平台的退款流程是什么 - passed modelfast-model-id tools[] pass rate: 3/3验证是否成功的三个标准简单问题没有触发工具调用并且没有因为模型选错而走慢速链路。订单查询问题触发工具调用且最终回复中包含工具返回的真实状态而不是模型编造的字段。日志中能同时看到路由模型、工具调用参数、Token 数和耗时。如果失败先按下面顺序排查日志里有没有模型请求没有说明 API Key 或网络配置有问题。日志里是否出现tool_called记录没有说明模型的工具调用没有触发需要检查工具 JSON Schema 是否被模型正确理解或换更强模型。日志显示工具被调用但最终回复不对检查工具返回结果是否被拼进第二轮对话以及 System Prompt 是否要求模型“基于工具结果回答”。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型输出不符合 JSON 格式未启用结构化输出或模型推理能力弱查看原始输出是否被截断检查是否启用 JSON Mode优先使用结构化输出功能在 System Prompt 中给出 JSON 示例工具调用循环不退出缺最大调用次数限制或工具返回结果让模型无法终止查看日志中工具调用次数增加MAX_TOOL_CALLS工具返回成功/失败后给出明确终止信号简单问题走了大模型成本飙升路由逻辑太粗糙打印每次路由的模型名和 Token 数增加关键词规则引入轻量意图分类模型做路由用户问 A 订单模型回答了 B 订单用户身份来自模型猜测而非系统注入检查 messages 中用户信息字段来源用户身份一律由会话服务注入不能在 Prompt 中让模型自造模型升级后行为漂移没有回归评估集用评估集跑新版模型对比通过率建立核心 Case 集模型升级必须跑回归并留版本快照工具返回“查无此单”模型仍假装有数据模型幻觉检查工具结果是否进第二轮并查看回复是否引用工具字段在 System Prompt 中显式说明“查无数据时必须告知用户查不到”同一请求重试两次产生重复数据缺少幂等控制查看下游日志是否重复写入工具调用增加 request_id 做幂等写操作加唯一约束对比可见大部分问题的根源要么是设计阶段没把上下文和权限边界想清楚要么是上线后没有评估闭环兜底。这两件事恰恰是 AI 应用“系统化”和“玩具化”的分水岭。8. AI 应用生产环境最佳实践8.1 把 AI 模块当远程服务而不是当本地函数不要把模型调用代码直接散落在各处业务代码里。更推荐的做法是把 AI 能力封装成一个独立服务提供统一接口输入用户上下文、业务参数输出结构化结果。这样做的好处是模型升级只影响服务内部调用方无感独立部署后可以单独扩容、限流和熔断日志做到服务级收敛排查问题不必翻遍全项目。8.2 安全边界永远不要信任模型输出模型输出只是建议不是指令。涉及删除、转账、退款、发布内容等敏感操作时模型不能直接执行。正确流程是模型生成操作意图 - 服务端校验权限 - 二次确认 - 执行 - 审计。所有越权尝试都应该被系统拦截并记录到安全日志里。8.3 成本治理路由、缓存、降级三板斧路由一定要做。不是所有请求都需要最强模型很多高频场景用快模型就够。缓存也要做。同一个问题、同一份资料、同一类客户答案可以在短时间内复用减少重复推理。降级更重要大模型服务不可用时系统可以降级为固定话术模板、规则匹配或转人工保证业务不中断。8.4 评测不是一次性工作而是持续机制每个 AI 应用上线前必须回答三个问题哪些场景必须成功列出 50 到 200 条核心用例。失败的标准是什么比如误报物流状态、泄露他人订单、无法回答常见售后问题。每次模型或 Prompt 变更后怎么验证没有回退只要能回答这些问题AI 应用就算进入可管理状态。否则上线就是赌运气。8.5 日志与可观测性AI 应用的日志比传统应用多两个层次模型层和对话层。模型层要记录模型名、版本、输入 Token、输出 Token、延迟、是否触发工具。对话层要记录会话 ID、用户 ID、完整消息序列、工具调用序列。只有这些都在线上出了问题才能复现和归因。8.6 灰度与回滚模型版本切换不要一键全量。先在 5% 流量上跑新模型对比评估通过率和用户反馈确认稳定后逐步放大。一旦指标回退马上切回旧版本。所有模型版本都保留快照不做“悄悄升级”。8.7 数据隐私与合规用户输入和工具返回结果都可能包含敏感信息。日志中不要记录完整手机号、身份证号、地址详情需要用脱敏标识符代替。输入大模型的文本也要在构造消息前完成脱敏避免敏感数据进入第三方模型服务。数据保留设置应明确生命周期超期清理。9. 给开发者的下一步建议如果你正在做 AI 应用有四个方向值得优先投入第一从业务问题找入口而不是从模型能力找入口。先找到业务里“人处理太慢”或“人处理不一致”的环节再思考模型能不能在其中扮演一个有限角色。反过来做先拿到模型再找场景大概率会做成又一个玩具。第二先做闭环再优化效果。很多团队在 RAG 召回率和 Prompt 上反复调优却连最基本的工具权限校验和结构化输出都没做。应该先把链路跑通输入 - 路由 - 模型 - 工具 - 校验 - 回复 - 日志然后再逐环节优化。第三尽早建立评估集和回归机制。哪怕一开始只有 30 条用例也比没有强。每次改动模型版本、Prompt、工具逻辑都跑一遍评估集这是控制 AI 应用质量最有效的低成本手段。第四深入理解 Agent 的工程约束。Agent 不只是一个“让模型自己规划”的噱头它涉及工具协议、状态管理、错误恢复、幂等控制、安全性设计。建议从实现一个最小 Function Calling 服务开始一步步加约束、加日志、加评估真正理解模型在业务流程里的边界在哪里。AI 应用的下半场拼的已经不是谁手里的模型参数更大而是谁能让模型在复杂业务系统里稳定地输出正确结果。这条路不像做 Demo 那么性感却是一个 AI 应用真正产生业务价值的必经之路。把上下文、工具、评估、可观测性这些基本功做扎实你就已经跑赢了绝大多数停留在“调模型”阶段的团队。