从零搭建AI工程：模型选型、Agent闭环与评测落地的实战指南

有一类项目叫 ai-engineering-from-scratch真正做完做完、做扎实的人不多。它不是什么算法刷榜也不是拿个开源模型跑通 demo 就收工而是从零开始把一个 AI 想法变成稳定、可维护、可评估、能上线的东西。这几年我做过不少类似的项目从最早用 Prompt Engineering 堆逻辑到后面引入 AI Agent、做工具调用、搭评测回归踩过的坑比收获的赞美多得多。这篇我想把整个过程拆开讲模型怎么选、Prompt 怎么写才不容易塌、Agent 的最小闭环怎么做、数据评测怎么介入以及上线前哪些地方最容易翻车。适合谁看刚接触 AI 工程的同学或者已经跑过几个 demo 但总觉得离生产还差一口气的开发者。下面的内容尽量按真实项目推进顺序来不是教科书是实际操作时的经验和教训。1. AI 工程从零开始第一件事不是写代码1.1 先分清“AI 工程”和“算法 Demo”很多同学拿到“AI 工程”这个标题第一反应是去 Hugging Face 找个模型、跑个 notebook、把准确率刷得好看一点。我特别理解因为我自己刚接触时也是这样。但这里有个非常重要的分界线算法 Demo 的目标是证明“模型可以做这件事”AI 工程的目标是证明“这件事可以长期稳定地在生产环境跑下去”。前者只需要一个 GPU、一个数据集、一份结果表后者需要需求澄清、边界定义、异常处理、评测体系、成本控制、灰度回滚缺一个环节项目就可能在下一次模型升级或流量冲击时翻车。我之前带过一个项目团队一开始三天就把对话模型接上了demo 效果让业务方很兴奋说“这周就能上”。结果一接入真实用户请求出现三类问题同样的 Prompt 时好时坏、模型偶尔输出格式乱掉、上下文一长就开始胡编。这些问题在一个简单的 notebook 里完全看不出来因为 demo 只跑了十几条精心挑选的例子。所以我现在的习惯是任何 AI 项目动手前先问自己一句我要交付的是一个“能演示的东西”还是一个“能运维的东西”如果是后者那么前面 30% 的时间都应该花在写需求和定边界上而不是先急着点“运行”按钮。1.2 从业务问题拆解到 AI 可行性判断从一个原始业务想法到真正开始搭系统中间有一个很关键的桥把业务问题翻译成 AI 可以解决的问题。举个我常用的例子业务方说“我想做一个智能客服助手”这听起来很明确但往下拆你会发现有完全不同的几条路用户问“我的订单到哪了”这是查询型任务可能用传统规则加接口查询就解决了不一定要大模型。用户问“我买了两个东西能一起退货吗”这是规则 判断型任务需要理解语义还要结合退货政策。用户发来一段投诉情绪很激动这是情感分析和摘要型任务需要生成式模型。用户说“我不小心点了退款能撤销吗”这是一个需要动作和权限的任务AI 只能做辅助判断不能代替执行。你看同一个“客服助手”需求落到系统上可能是一套规则引擎、一个检索系统、若干个大模型调用以及一个人工审批流。AI 工程的第一课不是选模型而是判断“哪里真的需要 AI哪里用不上 AI”。我自己列过一张检查清单大致是这个任务是否需要理解非结构化文本或生成新内容不需要的话优先用传统方法。错误容忍度是多少如果是人脸识别门禁99% 准确率也不够如果是文案润色80% 也有价值。数据是否存在、是否可获取、是否允许用于模型请求响应时间是秒级还是分钟级这决定能否在线调用大模型。任务是否需要多步推理和外部工具是的话就要考虑 Agent 架构。这张清单看起来简单但真的能帮团队避免“锤子钉子”心态。我以前看过有人用大模型做整数加法结果延迟 2 秒、成本还不低换成一个函数调用不到 1 毫秒。AI 工程不是“用 AI 解决所有问题”而是“在正确的地方用 AI”。这一段想清楚了后面所有选型和架构才有依据。2. 选型决定你后面三个月是省心还是填坑2.1 模型选型开源闭源、大中小怎么权衡聊到从零开始造 AI 工程大部分人最纠结的就是模型选型。市面上从几百亿参数的闭源 API 到 7B、13B 的开源权重眼花缭乱。我的建议很直接先按“数据敏感度 最终效果 成本预算”三个维度切别一上来就追最强模型。如果数据完全公开、追求效果、团队没有部署能力直接用闭源 API 最省事如果数据不能出域、需要在私有环境部署那就只能从开源模型里选如果两者都不是那就先拿小模型跑通流程再逐步升级。我有一个很深的体会模型选型不是一次性的而是分阶段的。第一版系统我建议用一个“够用且便宜”的模型甚至可以把开源小模型和闭源大模型都接上通过配置开关切换。不要在一开始就赌某个模型是永远最优的因为这个领域三个月就换一批榜单。我列过一张选型参考表日常项目基本够用决策维度闭源 API开源私有化本地小模型推理效果高适合复杂语义取决于参数和微调中低适合简单任务数据安全依赖服务商协议数据可控完全本地部署成本按量付费起步低需要 GPU 资源成本低运维复杂度低中中定制能力受限可微调可微调实际操作中我还会额外关注上下文长度和函数调用能力。尤其是做 Agent 项目如果模型不支持可靠的 function call后续做工具调用会非常痛苦。不要只看跑分要把你自己典型的 Prompt 和工具 schema 拿过去实测。经常有模型跑分很高真到复杂 JSON 输出时却频繁出错这时候再强的“推理能力”也补不上解析的坑。2.2 编排层LangChain、LlamaIndex 还是自研模型选完之后紧接着就是“怎么把这些调用串起来”。所有 AI 工程都会遇到这么一层东西大家叫它编排层。市面上的选项基本是三类LangChain、LlamaIndex、或者自己手写的服务。我的看法可能和很多教程不一样初期最好少依赖框架先手写一个最小流程理解每一步发生了什么再决定要不要引入框架。原因很简单框架本身有很强的抽象它把 Prompt 模板、记忆、检索、Agent 循环都封装好了初学者跑起来觉得轻松一旦出了诡异 bug根本不知道问题在链路的哪一环。我之前试着用 LangChain 搭一个带记忆的问答机器人遇到很典型的问题历史消息多了之后模型开始变得“答非所问”。我第一反应是调 Prompt后来发现其实是框架内部把记忆内容拼接得过大甚至把工具返回的原始日志也塞进了上下文。排查这个问题的过程比我自己写一个带滑动窗口的对话循环还要花时间。所以现在我的原则是链路简单、只有两三次模型调用自己写用代码控制 Prompt 拼接、工具返回和重试。检索场景明显、需要大量文档切分和向量化排序用 LlamaIndex 的检索组件但不要让它接管全部业务逻辑。需要复杂多智能体协作、工具循环、状态机可以引入 LangGraph 之类的框架但你必须自己能复现这些循环。框架的价值是省时间代价是让你丢失控制感。对 ai-engineering-from-scratch 这个项目来说我宁愿先用最朴素的代码把闭环跑通再逐步引入抽象。很多“生产级”问题其实都出在框架的隐藏行为上比如自动重试、自动截断、自动把消息转成某种格式。你如果不知道这些行为线上事故就很难定位。2.3 Prompt Engineering 基础写 Prompt 不是写作文说到 AI 工程Prompt Engineering 是一个绕不开的名字。有人觉得它“太软”不算工程但真正做过生产项目的人会反驳Prompt 是一等公民它需要版本管理、评测和回归。所谓“写 Prompt 不是写作文”意思是不要追求辞藻华丽而是追求“在同样的输入下模型输出的结构稳定性”。我写 Prompt 时通常遵守一个“三层结构”系统层声明角色和全局约束用户层给出具体任务最后附上 Few-shot 示例。比如给一个文档摘要助手写系统 Prompt我会写清楚“你是文档分析助手输出严格 JSON包含 summary 和 key_points 两个字段不要输出任何额外解释。”这句话比“请你帮我总结一下”管用一百倍。因为模型是概率生成你越明确格式、字段、禁止项它越少自由发挥。另外Prompt 一定要做版本化。不要漫不经心地在线编辑器里改几个字然后忘了改了什么。我的习惯是把所有 Prompt 模板放进代码仓库每次修改都过 review并且关联评测集。任何 Prompt 变更都必须跑一遍回归测试防止“修好一个场景、弄坏三个场景”。这一点其实是 AI 工程里最容易忽略、但影响最大的基础工作。3. 手搓一个最小可用的 AI Agent跑通再谈优化3.1 Agent 的本质与最小架构现在很多 AI 工程项目都会扯到 AI Agent尤其是“智能体”这个词已经被讲得非常玄。我自己理解得比较朴素Agent 大模型 规划 工具调用 记忆。你可以把它想象成给一个很聪明的实习生配了一本工作手册、一套工具箱和一个记事本。工作手册是 System Prompt工具箱是函数列表记事本用来记录上下文和中间结果。从零搭一个最小 Agent不需要一开始就做得很复杂。一个最简单但完整的架构是用户输入进来模型决定调用哪个工具拿到工具返回值后再决定下一步直到它能回答用户或者达到最大轮数。这里最核心的循环代码其实没有想象的那么复杂for step in range(max_steps): response llm.chat(messages, toolstools) if response.tool_calls: tool_name response.tool_calls[0].name tool_args response.tool_calls[0].arguments result execute_tool(tool_name, tool_args) messages.append(tool_result_message(tool_name, result)) else: return response.content return fallback_message()这个循环是 Agent 的骨架。很多人一开始就想做多 Agent 协作、记忆向量化、自动反思我建议把这些往后放。先把这个最小循环跑通你才真正理解“模型不是执行者模型是决策者”这句话。3.2 工具调用与上下文管理的实现要点在最小 Agent 里工具调用是最容易出问题的地方。模型输出一个“我想调用 xxx 工具参数是 xxx”你的代码必须把它解析成真实函数调用。现在主流模型都支持 function call底层原理一般是让模型输出一个 JSON 结构里面包含工具名和参数。你需要处理的情况有模型输出的 JSON 不合法、参数类型不对、工具本身执行超时、工具返回的结果太长。我踩过最经典的坑是 JSON 被模型加了额外的反引号和注释导致 json.loads 直接报错。解决办法不是一味责怪模型而是设计一个容错的解析函数。第一层用标准 JSON 解析第二层用正则把代码块包裹的 JSON 提取出来第三层如果是常见错误可以替换非法字符再解析。你还可以把“输出必须合法 JSON不要包含 markdown 代码块”明确写进 Prompt通常能减少 80% 的格式问题。上下文管理也要从一开始就设计好。不要把工具返回的原始内容全部塞进下一轮消息因为工具返回可能是一个巨大的数据库查询结果很容易撑爆上下文窗口。常见做法是截断、压缩或只保留关键字段。我用过一个交易日行情查询工具返回 JSON 有几万字符但用户只想关心某只股票的收盘价。我直接在工具侧做后处理只返回几个常用指标Agent 的下一轮预测立刻就准了也省了 token。3.3 多 AI 协作把一个大 Agent 拆成多个小角色等你把单 Agent 跑顺了会发现有些任务要么步骤太多、要么角色混杂一个 Prompt 里既要“查资料”又要“写结论”还要“检查错误”效果往往很差。这时候可以考虑多 AI 协作也就是多 Agent 架构。它的核心不是“多个模型一起跑”而是把复杂任务拆成多个角色每个角色有自己的 Prompt、工具和记忆角色与角色之间通过结构化消息协作。我经手的一个知识库问答项目早期是单 Agent 直接读文档生成答案经常出现引用不准确、答案不够深的问题。后来拆成三个角色第一个负责检索资料输出带来源的候选片段第二个负责判断这些片段是否足够回答问题第三个负责综合生成最终答案。每个角色都是独立 Prompt、独立模型调用消息通过内部 JSON 传。拆分之后效果提升非常明显因为“检索质量”和“生成质量”被分开评测你可以准确知道是哪一环出了问题。但多 Agent 不是银弹。它带来的新麻烦是调试链路变长、token 消耗变大、偶尔还会出现两个 Agent 来回踢皮球。我的建议是单 Agent 能解决的坚决不拆单 Agent 明显出现“角色混乱”或“上下文过载”时再拆。而且拆分时要给每个 Agent 定义清晰的退出条件不能让它无限循环下去。很多工程事故都是因为循环条件没写好线上多花了几百次调用才悻悻结束。4. 数据、评测和迭代把 AI 从“能跑”变成“能用”4.1 构造评测集没有评估就没有迭代AI 工程最容易被低估的环节是评测。很多项目跑通 demo 后就急着上线上线后效果靠用户反馈来感知今天好一点、明天差一点完全没有头绪。我现在的做法是项目第一天就要建立评测集。不用特别大100 到 300 条精心挑选的样本就够。关键是覆盖三类情况正常输入、边界输入、异常输入。正常输入保证基本能力边界输入包括超长文本、模糊措辞、少见说法异常输入包括空输入、恶意输入、明显无法回答的问题。评测集的答案由人写不要靠模型生成至少在早期不要。因为它代表的是“标准答案”是用来约束模型行为的锚点。我团队里有个习惯评测集建立后任何人改 Prompt 或换模型都必须把这份评测集跑一遍出一份对比报告。报告里一定要有硬指标和软指标。硬指标是字段提取准确率、JSON 格式合法率、工具调用是否命中期望软指标是语义相似度、答案相关性、话术自然度。软指标可以用一个强大的模型当裁判也就是 LLM-as-judge但要注意裁判模型本身有偏好最好定期抽查它给的分是否合理。4.2 迭代闭环从 badcase 出发评测集跑完不是终点而是迭代的起点。我最常用的方法是badcase 驱动迭代每次从真实日志里收集失败案例聚成几类再针对性修复。做这一步最怕的是“头痛医头”。用户说“你答错了”你就把这条 case 硬塞进 Prompt结果模型从此对所有相似问题都变得敏感反而过拟合。正确做法是先把 50 个 badcase 归类看看它们是属于意图识别错误、检索不到位、工具数据错了还是生成阶段引用错误。根因不同修改策略完全不同。举一个例子我们的文档问答机器人一开始经常引用了不相关的内容。起初我们以为是生成模型的问题改了好几版 Prompt效果一直不稳定。后来给 badcase 分类后发现绝大多数根因在检索阶段文档被切成很多 chunk但 chunk 之间没有标题层级关系导致检索到一个无上下文的片段模型自然找不到有效信息。于是我们改了解析策略把 Markdown 标题信息带进 chunk答案准确率立刻上了一个台阶。这个案例给我最大的提醒是AI 工程里的“坏效果”有大半不是模型的问题而是数据流和工具链的问题。4.3 AI 测试开发工程化测试不是点几下说 AI 工程就一定要说 AI 测试开发。传统测试主要测“逻辑正确性”AI 系统还得测“行为稳定性”。我习惯把测试分成四层单元测试每个工具函数、解析函数输入期望输出跑一遍。Prompt 测试固定测试集跑 Prompt 变更前后的输出差异。集成测试端到端跑一遍 Agent 流程验证工具链路通畅。性能与压力测试并发上调到预期峰值的几倍看延迟和错误率。单元测试和普通代码没区别比如计算器工具我就写了类似这样的用例def test_calculator_tool(): result execute_tool(calculator, {expression: (35)*2}) assert result 16真正难的是集成测试。因为模型的输出有随机性你不能指望两次完全一样。所以测试断言要写成“结构断言”而不是“逐字断言”。比如 JSON 里必须有 required 字段、引用来源必须存在于知识库中、输出结论不能包含敏感词等。这样即使模型换个说法只要关键结构正确测试就通过。AI 测试的目标不是追求零失败而是把失败控制在可容忍范围内并且让每次模型升级都能被自动发现。5. 投产前的常见坑位成本、延迟、稳定性与责任边界5.1 上下文爆炸与记忆管理所有从零搭 AI 工程的人最后都会撞上“上下文爆炸”这堵墙。模型窗口从 4K 到 128K 越来越长但你的对话历史不会永远装得下。最朴素的对话工程是“把最近 N 轮消息全塞进去”短时间能用用户多聊十分钟就开始超限超限后要么报错要么程序默默截断最早的对话用户发现模型“失忆”了。这个问题必须提前设计。我常用的记忆策略有三种按成本递增排列滑动窗口、摘要记忆、向量检索记忆。滑动窗口最简单只保留最近 5 到 10 轮消息适合客服场景摘要记忆是在每过几轮后用模型把前面的核心信息压缩成一段摘要再放进上下文向量检索记忆则是把历史消息向量化每次按相关性取回几条。大多数项目用到“滑动窗口 摘要记忆”就够了。不要一上来就上向量库因为向量库本身有运维成本还会引入“检索不准导致记忆污染”的新风险。5.2 工具调用失败与重试策略Agent 工程上线后工具调用的失败率是你最需要盯的指标之一。真实世界里第三方接口会超时、数据库连接会断开、返回的数据会脏到让你怀疑人生。如果你不处理这些失败Agent 可能会把报错文本原样当成“工具结果”喂给模型模型再一本正经地编出一个错误答案用户看到的就是“胡说八道”。我的做法是给每种工具定义明确的失败语义。工具成功时返回结构化数据失败时返回包含 error_code 和 message 的结果Agent 循环里看到 error_code 就决定是重试、换一个工具、还是老老实实告诉用户“当前无法完成查询”。另外还要设置最大重试次数和超时时间防止一个慢接口拖死整个 Agent。生产环境里我在调用外部搜索接口时设了三秒超时、两次重试超过就直接走答案生成兜底用户体感比一直转圈好得多。5.3 成本与延迟优化清单AI 工程的最后一个大坑是账单和延迟。很多人做 demo 时不关注成本上线后才发现一次复杂的多 Agent 协作要消耗十几万 token费用高得惊人。成本控制的核心不是砍功能而是让每一轮调用都尽量“小而准”。我常用的优化手段有模型分级路由简单请求用小模型复杂请求才用大模型。Prompt 压缩把冗余的 system 说明压缩到必要长度删掉已经不需要的 few-shot 示例。结果缓存相同或高度相似的问题直接命中缓存不重复调用更进一步可以用语义缓存按 embedding 相似度召回。流式输出首字延迟会大幅降低用户感知更流畅。批量处理离线任务集中跑利用 API 的批量折扣。成本公式其实很朴素单次成本 输入 token 数×输入单价 输出 token 数×输出单价总体成本再乘以调用次数。所以你能优化的就是减小 token 数和调用次数。我习惯每次改完 Prompt 或流程都跑一批真实流量日志对比“修改前/修改后”的平均 token 消耗。不要让优化变成玄学拿数据说话。5.4 上线不是终点可观测性与灰度发布最后想聊一个说得最多、做得最少的事可观测性。传统服务上线要接日志、监控、报警AI 服务也一样甚至更需要。因为输出是概率性的你不仅要看有没有报错还要看回答质量有没有下滑。我的要求是每次用户请求都要记录 Prompt 的最终版本、模型名称、上下文长度、工具调用序列、响应时间、token 消耗以及用户反馈入口。没有这些你没法复盘任何一起“AI 胡言乱语”事故。灰度发布也很关键。换模型、改 Prompt、调工具都先对一小部分流量生效观察指标稳定后再全量。我见过一个团队把 Prompt 从“结果输出简洁”改成“结果输出详细”结果线上成本直接翻倍他们过了两三天才从账单里发现。如果有基础的灰度机制这种问题在 5% 流量时就会触发报警。AI 系统不是“上完线就完事”它更像一个需要持续喂养和修剪的花园评测集是标尺日志是镜子灰度发布是护栏。根据我个人在多个从零起步 AI 工程里的体会最值钱的部分往往不是那个最聪明的模型而是你把它弄明白、护得住的那套工程体系。给新手一个建议不要想着一口气造出完美智能体先老老实实把一个最小 Agent 跑通、接上评测、记录日志、控住成本你才能真正理解 AI 工程到底难在哪以及为什么差距总在“最后一步”拉开。