朋友找我帮忙看一个项目标题叫“ai-engineering-from-scratch”。乍一看像是仓库名再一看实际上是个很典型的工程实践命题从零开始把AI能力做成一个真正能跑、能迭代、能交付的系统。很多人会误以为这事就是调个API、套个Prompt实际上真正落地的时候涉及的东西远比想象中多。这篇文章我就用自己踩过一遍坑之后的思路把一条完整的“从零到一”AI工程项目路径拆开给你看。无论你是个人开发者、正打算转型做AI应用的技术人还是团队里负责技术选型的同学这里面的东西应该都能帮你少走一些弯路。先说实话我见过太多项目死在了第一步根本没有想清楚“AI工程”和“写段调用模型代码”的区别。如果你只是想要一个能回答问题的窗口那确实不用往下看。但如果你要做的是能接入业务、能处理真实数据、能在出问题的时候被排查、能持续演进的系统那你需要的是完整的工程思维。1. 先搞清楚从零开始AI工程的边界1.1 “从零”不等于“从造发动机开始”很多第一次接触AI工程的人看到“from scratch”这个词就紧张以为要从数学推导、手写反向传播开始。但实际上在2025年的工程语境里AI工程的“从零”指的是从一个空目录开始用现有的模型能力、开发框架、开源工具搭出一套属于你自己的AI应用系统。这有点像盖房子——你不会从烧砖开始但你得从平整土地、画图纸、打地基开始。我理解“from scratch”包含的其实是三个阶段第一阶段是“零基础理解”也就是你能清楚说出AI系统里每个环节为什么存在第二阶段是“零依赖搭建”所有核心逻辑都自己掌控不盲目信任某个黑盒平台第三阶段是“零经验落地”也就是你已经具备把想法变成可运行demo并逐步完善的能力。换句话说AI工程不是一门“调参艺术”而是一门“系统科学”。它关心的是输入什么数据、模型如何被调用、Prompt如何被管理、输出如何被校验、失败如何被恢复、整个链路如何被观察和度量。这跟写一个普通的Web服务不一样因为引入了不可完全确定性的模型推理你的错误处理、边界控制、结果验证都要比传统软件多一个维度。1.2 AI工程的五层体系我自己在梳理AI工程时一直沿用一套五层结构每次跟团队对齐都用它效果很好。有了这套结构你再看任何AI项目都能快速定位它卡在哪一层。第一层是数据层。包括数据采集、清洗、切分、向量化、存储。不要觉得只有做大模型训练才需要数据工程即使是做RAG问答数据做不好后面全白搭。第二层是模型层。这里要决策是用商用API还是开源模型要不要微调需不需要本地部署用什么推理框架。这一层相对容易被高估其实很多项目根本不用微调。第三层是提示词与上下文管理层也就是大家常说的Prompt Engineering。这个层级的职责包括把任务描述清楚把格式化输出约束住把上下文窗口管理好把系统提示词和人设稳定住。第四层是Agent与应用编排层。也就是让模型能调用工具、能访问外部系统、能按计划执行多步任务。这里涉及的框架有LangChain、LlamaIndex、自家写的状态机等等选择很多但核心是控制流。第五层是评估、监控与运维层。这是最容易被新手忽略、却决定项目能否长期存活的层。你需要有一套评测集来判断模型改Prompt之后是变好还是变坏了你还需要记录每次调用的输入输出、token用量、延迟、错误率这样才能在线上问题出现时快速定位。记住这五层缺一不可。缺了数据层你的模型再聪明也没有依据缺了评估层你的项目就是开盲盒。2. 选型与架构开工前的第一场硬仗2.1 先拆需求再选模型我在做项目规划时第一步永远不是打开ChatGPT页面或者下载模型权重而是先写一份需求拆解文档。这个文档不需要很长但必须回答几个问题用户是谁输入是什么输出需要什么样的结构允许的延迟是多少数据敏感程度如何容错率多高举个例子你想要做一个“行业问答机器人”。这个需求看起来简单但拆开之后会发现很多变体是面向C端用户的闲聊型问答还是面向企业内部员工的文档检索型问答用户提问时是否可能涉及多轮上下文答案是需要引用原文出处还是只需要一段自由生成的结果如果模型给错了答案后果有多严重这些问题直接决定了后续的技术选型。闲聊型问答可以靠一个通用大模型API加系统提示词解决但文档检索型问答大概率需要RAG架构要引入向量数据库、文本切分、召回排序一整套流程。如果你不做需求拆解就直接选型很可能做出一个“听起来很酷但根本没法用”的东西。2.2 API、开源模型、本地推理怎么权衡选型的第二个关键决策是你的模型能力从哪里来。目前市面上有两条主流路径调用云端大模型API或者部署开源模型到自己的服务器。综合考虑成本、隐私、定制自由度、运维复杂度和效果具体对比可以看这张表。维度商用API开源模型本地部署初始成本低按量付费高需要GPU服务器单次调用成本相对较高边际成本低但固定成本高数据隐私出网存在合规风险可控数据留在本地定制能力有限只能靠Prompt可微调、可换模型结构运维复杂度基本为零需要处理推理框架、并发、监控效果上限通常更高取决于你选的模型和部署手段我的经验是对于初创项目、快速验证行为的场景先无脑用商用API让业务逻辑跑通最重要。当项目有了一定规模的用户和收入或者数据合规要求变得敏感再考虑迁移到开源模型。不要一上来就自建推理集群那是给自己找罪受。如果你确实需要本地部署也有个折中方案先用Ollama这类工具把模型跑起来再通过OpenAI兼容接口接入你的应用层代码。这样你在应用层写的代码从第一天起就不依赖具体厂商后面想换模型很轻松。2.3 Prompt工程和Agent框架怎么选Prompt工程这个说法很容易让人误会好像只是写几句提示词而已。实际上一个成熟项目的Prompt管理应该纳入版本控制要有模板系统要支持不同场景下的动态拼装。我建议不要直接把Prompt写死在业务代码里而是单独维护一个配置文件或者用专门的Prompt管理工具把系统提示词、用户前缀、示例样本、输出格式三段分开。至于Agent框架我的忠告是不要为了用框架而用框架。LangChain确实火但很多简单需求用代码手写一个带if-else的Agent循环就够了。你只需要定义一个工具列表、一个模型调用函数、一个解析模型输出的函数再加上一个循环判断是否需要继续调用工具。这套手写的控制流也许看起来土但它可读性强、调试方便、没有版本升级带来的破坏性变更。只有当你的任务确实涉及复杂路由、多工具协作、动态规划、记忆管理等需求时才值得考虑引入成熟的Agent框架。请一定记住框架解决的是通用问题你的项目解决的是特定问题中间必然存在适配成本。3. 实操案例从零构建一个带记忆的行业问答Agent3.1 场景定位与数据准备为了讲清楚整套流程我拿一个最近做过的项目举例帮一家做企业资质服务的公司搭一个“政策咨询Agent”。用户会问“我们公司想申请高新技术企业认定需要哪些材料”“研发费用占比要求是多少”“去年有一项知识产权不满足条件怎么办”这类问题。这个场景有几个特点第一答案不能瞎编必须对应具体政策条文第二不同年份、不同地区政策不一样第三用户会提供公司自身信息Agent需要记住这些信息并在多轮对话中使用。所以一个裸的通用模型完全不够必须做知识库检索加上对话记忆。数据准备阶段的工作量远超预期。我先从客户那里拿了一批政策文件PDF和Word第一步是清洗格式去掉页眉页脚、处理全角半角、统一表格样式。然后做段落切分不能让一个超长条款占满整个向量库片段也不能把一个问题切成两半。经过测试按三级标题和条款编号进行切分平均每个片段控制在200500字效果最好。之后我把每个片段喂给一个Embedding模型生成向量存入向量数据库。这里我用了轻量级的开源Embedding方案不需要很大模型几百MB的模型在CPU上都能跑速度可以接受。切分时还有一个细节相邻片段之间保留少量重叠文字大概50字左右防止检索时因为边界跳过关键信息。3.2 Prompt设计与上下文压缩这个项目的Prompt我改了很多版。最初版的系统提示词只写了“你是一位资深政策咨询顾问”结果模型回答得倒是流畅但经常自由发挥把一些不存在的要求说得头头是道。后来我改成“你只能根据给定资料回答如果资料中没有明确依据必须回复‘资料中未找到相关内容’”。并且给Prompt加了检索结果引用格式每个回答至少要标注引用了哪一份文件的哪个条款。这样做以后模型的“幻觉”明显减少而且用户能看到出处信任度也高很多。关于上下文管理你的第一直觉可能是“把用户多轮对话全部塞进提示词”但这样很快会撞到上下文窗口和成本限制。我的做法是每一轮对话结束后用一个轻量级模型或规则对历史对话做摘要把关键信息比如公司名称、行业、人员规模、已具备的知识产权数量抽出来放进一个结构化的“记忆字段”。下一轮生成时只把摘要和最近的3轮对话传给模型。举个例子用户第一轮说“我们是一家软件公司有120人研发人员45个”这些数据不在资料库里但对后续回答有用。我把它存进记忆字段之后第二轮他问“我们符合小微企业的标准吗”模型就能结合记忆里的“120人”和召回的政策文本给出判断。这个功能用LangChain的Memory也能做但手写更灵活。3.3 Agent编排与工具调用问答型Agent的流程可以简化成三件事检索相关资料、分析用户问题、组织回答。但真实的业务中还需要Agent具备主动追问和基于时间条件做分支判断的能力。比如用户问“今年高企申报什么时候截止”资料库里只有各地方的通知没有统一的截止日期。这时候只靠向量检索并不足够因为不同的政策文件时间不一样。我把“查询当前日期”和“查询政策数据库”分别封装成两个工具让Agent决定先调用哪个。为此我写了一个很小的控制循环第一轮调用工具把工具结果塞回上下文第二轮让模型综合回答。如果你把两轮调用合并成一步模型就更容易胡编时间。另一个实用的设计是“澄清机制”。模型判断用户问题模糊时不直接回答而是生成一个反问句“请问您申报的是哪个省份的高企认定”我把这个行为定义成Prompt里的一个分支指令并给出一个结构化输出要么是answer字段要么是clarify_question字段。业务代码根据字段值决定直接展示答案还是继续追问。这是最简单的Agent决策逻辑但非常有效。3.4 评估指标与回归测试项目上线前我们建立了一套评估集包含50个真实用户问题和对应的正确答案等级。这里的正确答案不要求逐字一致而是标记为三类完整正确、部分正确、错误。每次调整Prompt或换模型版本时我都会跑一遍这套评估集计算“完整正确率”和“部分及以上正确率”。不到一周我就发现改Prompt经常是“东边日出西边雨”某几个问题的回答质量大幅提升另几个却意外变差。所以光看平均值不够我还会按业务模块分组看结果。比如“申报条件类问题”和“政策时间类问题”分开统计这样能更清晰定位哪部分退化了。我还加了一个“拒答正确率”指标当问题明显超出知识库范围时模型应该明确说不知道而不是硬答。这个指标和“幻觉率”紧密相关宁可多拒绝也不要乱回答。没有这套评估你根本无法进行科学的Prompt迭代基本就是瞎试。4. 常见问题与排坑技巧4.1 模型“胡说八道”的根治办法大模型幻觉是绕不开的问题。我常用的手段有哪些首先是强约束输出格式要求模型在给出答案时附带引用编号并且编号必须对应到输入的“资料列表”。如果模型生成了一个不存在的编号业务代码就要拦截掉重新请求。其次是用“二次校验”。对于高风险回答比如涉及金额、期限、资质要求的问题我让模型先生成一个待定答案然后把这个答案连同原始资料一起去问另一个模型“请判断以下回答是否完全基于给定资料若存在超出资料内容的信息请指出。”等于让一个“评审”模型去审计“回答”模型。这个方法会多一倍token开销但准确率提升非常明显。4.2 Token开销失控与控制我第一次做Agent时控制流写得太随意一次问题来回调用七八次模型单次成本飙升十倍。后来我给工具调用设置了“最大迭代次数”默认3次超过就不再执行下一次调用让模型基于已有信息直接作答。同时对于Agent的中间结果不全部塞回上下文而是只保留工具输出的摘要。还有一个容易忽略的坑系统提示词和示例也会按token计费。如果你每个请求都带超长示例并发一高成本很快就刹不住。建议把常见示例做成一个单独的“示例库”按分类动态注入而不是每次把所有示例都带上。4.3 多AI协作的同步与信任“多AI协作”是最近很火的方向但我的体验是别轻易上因为它带来了一个新的工程问题Agent之间如何建立信任。如果你的主Agent调用了另一个子Agent你得考虑子Agent返回的结果是否可靠、格式是否正确、是否可能陷入死循环。建议采用“白板模式”多个Agent之间的通信不靠自然语言对话而是统一写到一个结构化的状态文件里。比如主Agent决定调用工具时往状态文件里写入工具名、入参和状态工具执行完往状态文件里写入结果字段。这样你随时可以检查每条链路的输入输出重放问题、定位bug都容易得多。如果让Agent自由对话你会陷入“两个模型尬聊到死循环”的窘境。4.4 从demo到生产的8个细节很多项目demo跑通了一上生产就崩。我列几个最容易翻车的地方第一没有设置超时和重试模型接口偶尔会慢必须给请求设置超时时间并建立指数退避重试机制第二没有做并发控制一压测就把模型服务打满了第三没有日志追踪线上问题无从查起第四没有数据版本管理向量库里的资料更新了你都不知道第五Prompt和代码没有一起做版本管理导致历史行为无法复现第六没有做安全和合规检查用户输入可能带恶意注入第七没有做内容审核模型输出可能涉及违规内容第八没有做成本监控没有预警阈值。这八点看着琐碎但任何一个都能让项目在关键时刻崩掉。具体踩得多了你就知道AI工程里所谓的“工程”往往就体现在这些细节上。5. 最后说点个人体会做“ai-engineering-from-scratch”这类项目我最深的体会是技术选型真的不是最难的环节最难的是建立一套“反馈闭环”。从数据准备、Prompt调整、Agent逻辑设计到评估指标每一环都需要你能够快速知道“刚才那个改动到底有没有效果”。还有一个小建议把AI项目当成一个持续演进的产品而不是一次性的交付物。你上线第一个版本只解决60%的问题没关系重点是你要有一套机制不断发现剩余40%的问题并且能低成本地把它们一个个修好。拿政策咨询Agent来说我每周都会看用户提问记录把那些模型答错的、拒答不该拒的、还有被用户反复追问的问题整理成新的测试用例塞进评估集。这样迭代到第三周整个系统的稳定性就肉眼可见地提升了。这个项目做完之后我明显感觉到AI工程已经不像一两年那样充满魔法感了。它越来越像一个常规软件工程只是它的核心组件有一定不确定性。你只要把这种不确定性关进一个结构化的笼子里——用评测、校验、监控去管理它它就会慢慢变得可靠。希望这篇东西能帮你把从零到一的路走得更顺一点。
AI工程从零到一：构建可交付智能系统的完整落地路径
朋友找我帮忙看一个项目标题叫“ai-engineering-from-scratch”。乍一看像是仓库名再一看实际上是个很典型的工程实践命题从零开始把AI能力做成一个真正能跑、能迭代、能交付的系统。很多人会误以为这事就是调个API、套个Prompt实际上真正落地的时候涉及的东西远比想象中多。这篇文章我就用自己踩过一遍坑之后的思路把一条完整的“从零到一”AI工程项目路径拆开给你看。无论你是个人开发者、正打算转型做AI应用的技术人还是团队里负责技术选型的同学这里面的东西应该都能帮你少走一些弯路。先说实话我见过太多项目死在了第一步根本没有想清楚“AI工程”和“写段调用模型代码”的区别。如果你只是想要一个能回答问题的窗口那确实不用往下看。但如果你要做的是能接入业务、能处理真实数据、能在出问题的时候被排查、能持续演进的系统那你需要的是完整的工程思维。1. 先搞清楚从零开始AI工程的边界1.1 “从零”不等于“从造发动机开始”很多第一次接触AI工程的人看到“from scratch”这个词就紧张以为要从数学推导、手写反向传播开始。但实际上在2025年的工程语境里AI工程的“从零”指的是从一个空目录开始用现有的模型能力、开发框架、开源工具搭出一套属于你自己的AI应用系统。这有点像盖房子——你不会从烧砖开始但你得从平整土地、画图纸、打地基开始。我理解“from scratch”包含的其实是三个阶段第一阶段是“零基础理解”也就是你能清楚说出AI系统里每个环节为什么存在第二阶段是“零依赖搭建”所有核心逻辑都自己掌控不盲目信任某个黑盒平台第三阶段是“零经验落地”也就是你已经具备把想法变成可运行demo并逐步完善的能力。换句话说AI工程不是一门“调参艺术”而是一门“系统科学”。它关心的是输入什么数据、模型如何被调用、Prompt如何被管理、输出如何被校验、失败如何被恢复、整个链路如何被观察和度量。这跟写一个普通的Web服务不一样因为引入了不可完全确定性的模型推理你的错误处理、边界控制、结果验证都要比传统软件多一个维度。1.2 AI工程的五层体系我自己在梳理AI工程时一直沿用一套五层结构每次跟团队对齐都用它效果很好。有了这套结构你再看任何AI项目都能快速定位它卡在哪一层。第一层是数据层。包括数据采集、清洗、切分、向量化、存储。不要觉得只有做大模型训练才需要数据工程即使是做RAG问答数据做不好后面全白搭。第二层是模型层。这里要决策是用商用API还是开源模型要不要微调需不需要本地部署用什么推理框架。这一层相对容易被高估其实很多项目根本不用微调。第三层是提示词与上下文管理层也就是大家常说的Prompt Engineering。这个层级的职责包括把任务描述清楚把格式化输出约束住把上下文窗口管理好把系统提示词和人设稳定住。第四层是Agent与应用编排层。也就是让模型能调用工具、能访问外部系统、能按计划执行多步任务。这里涉及的框架有LangChain、LlamaIndex、自家写的状态机等等选择很多但核心是控制流。第五层是评估、监控与运维层。这是最容易被新手忽略、却决定项目能否长期存活的层。你需要有一套评测集来判断模型改Prompt之后是变好还是变坏了你还需要记录每次调用的输入输出、token用量、延迟、错误率这样才能在线上问题出现时快速定位。记住这五层缺一不可。缺了数据层你的模型再聪明也没有依据缺了评估层你的项目就是开盲盒。2. 选型与架构开工前的第一场硬仗2.1 先拆需求再选模型我在做项目规划时第一步永远不是打开ChatGPT页面或者下载模型权重而是先写一份需求拆解文档。这个文档不需要很长但必须回答几个问题用户是谁输入是什么输出需要什么样的结构允许的延迟是多少数据敏感程度如何容错率多高举个例子你想要做一个“行业问答机器人”。这个需求看起来简单但拆开之后会发现很多变体是面向C端用户的闲聊型问答还是面向企业内部员工的文档检索型问答用户提问时是否可能涉及多轮上下文答案是需要引用原文出处还是只需要一段自由生成的结果如果模型给错了答案后果有多严重这些问题直接决定了后续的技术选型。闲聊型问答可以靠一个通用大模型API加系统提示词解决但文档检索型问答大概率需要RAG架构要引入向量数据库、文本切分、召回排序一整套流程。如果你不做需求拆解就直接选型很可能做出一个“听起来很酷但根本没法用”的东西。2.2 API、开源模型、本地推理怎么权衡选型的第二个关键决策是你的模型能力从哪里来。目前市面上有两条主流路径调用云端大模型API或者部署开源模型到自己的服务器。综合考虑成本、隐私、定制自由度、运维复杂度和效果具体对比可以看这张表。维度商用API开源模型本地部署初始成本低按量付费高需要GPU服务器单次调用成本相对较高边际成本低但固定成本高数据隐私出网存在合规风险可控数据留在本地定制能力有限只能靠Prompt可微调、可换模型结构运维复杂度基本为零需要处理推理框架、并发、监控效果上限通常更高取决于你选的模型和部署手段我的经验是对于初创项目、快速验证行为的场景先无脑用商用API让业务逻辑跑通最重要。当项目有了一定规模的用户和收入或者数据合规要求变得敏感再考虑迁移到开源模型。不要一上来就自建推理集群那是给自己找罪受。如果你确实需要本地部署也有个折中方案先用Ollama这类工具把模型跑起来再通过OpenAI兼容接口接入你的应用层代码。这样你在应用层写的代码从第一天起就不依赖具体厂商后面想换模型很轻松。2.3 Prompt工程和Agent框架怎么选Prompt工程这个说法很容易让人误会好像只是写几句提示词而已。实际上一个成熟项目的Prompt管理应该纳入版本控制要有模板系统要支持不同场景下的动态拼装。我建议不要直接把Prompt写死在业务代码里而是单独维护一个配置文件或者用专门的Prompt管理工具把系统提示词、用户前缀、示例样本、输出格式三段分开。至于Agent框架我的忠告是不要为了用框架而用框架。LangChain确实火但很多简单需求用代码手写一个带if-else的Agent循环就够了。你只需要定义一个工具列表、一个模型调用函数、一个解析模型输出的函数再加上一个循环判断是否需要继续调用工具。这套手写的控制流也许看起来土但它可读性强、调试方便、没有版本升级带来的破坏性变更。只有当你的任务确实涉及复杂路由、多工具协作、动态规划、记忆管理等需求时才值得考虑引入成熟的Agent框架。请一定记住框架解决的是通用问题你的项目解决的是特定问题中间必然存在适配成本。3. 实操案例从零构建一个带记忆的行业问答Agent3.1 场景定位与数据准备为了讲清楚整套流程我拿一个最近做过的项目举例帮一家做企业资质服务的公司搭一个“政策咨询Agent”。用户会问“我们公司想申请高新技术企业认定需要哪些材料”“研发费用占比要求是多少”“去年有一项知识产权不满足条件怎么办”这类问题。这个场景有几个特点第一答案不能瞎编必须对应具体政策条文第二不同年份、不同地区政策不一样第三用户会提供公司自身信息Agent需要记住这些信息并在多轮对话中使用。所以一个裸的通用模型完全不够必须做知识库检索加上对话记忆。数据准备阶段的工作量远超预期。我先从客户那里拿了一批政策文件PDF和Word第一步是清洗格式去掉页眉页脚、处理全角半角、统一表格样式。然后做段落切分不能让一个超长条款占满整个向量库片段也不能把一个问题切成两半。经过测试按三级标题和条款编号进行切分平均每个片段控制在200500字效果最好。之后我把每个片段喂给一个Embedding模型生成向量存入向量数据库。这里我用了轻量级的开源Embedding方案不需要很大模型几百MB的模型在CPU上都能跑速度可以接受。切分时还有一个细节相邻片段之间保留少量重叠文字大概50字左右防止检索时因为边界跳过关键信息。3.2 Prompt设计与上下文压缩这个项目的Prompt我改了很多版。最初版的系统提示词只写了“你是一位资深政策咨询顾问”结果模型回答得倒是流畅但经常自由发挥把一些不存在的要求说得头头是道。后来我改成“你只能根据给定资料回答如果资料中没有明确依据必须回复‘资料中未找到相关内容’”。并且给Prompt加了检索结果引用格式每个回答至少要标注引用了哪一份文件的哪个条款。这样做以后模型的“幻觉”明显减少而且用户能看到出处信任度也高很多。关于上下文管理你的第一直觉可能是“把用户多轮对话全部塞进提示词”但这样很快会撞到上下文窗口和成本限制。我的做法是每一轮对话结束后用一个轻量级模型或规则对历史对话做摘要把关键信息比如公司名称、行业、人员规模、已具备的知识产权数量抽出来放进一个结构化的“记忆字段”。下一轮生成时只把摘要和最近的3轮对话传给模型。举个例子用户第一轮说“我们是一家软件公司有120人研发人员45个”这些数据不在资料库里但对后续回答有用。我把它存进记忆字段之后第二轮他问“我们符合小微企业的标准吗”模型就能结合记忆里的“120人”和召回的政策文本给出判断。这个功能用LangChain的Memory也能做但手写更灵活。3.3 Agent编排与工具调用问答型Agent的流程可以简化成三件事检索相关资料、分析用户问题、组织回答。但真实的业务中还需要Agent具备主动追问和基于时间条件做分支判断的能力。比如用户问“今年高企申报什么时候截止”资料库里只有各地方的通知没有统一的截止日期。这时候只靠向量检索并不足够因为不同的政策文件时间不一样。我把“查询当前日期”和“查询政策数据库”分别封装成两个工具让Agent决定先调用哪个。为此我写了一个很小的控制循环第一轮调用工具把工具结果塞回上下文第二轮让模型综合回答。如果你把两轮调用合并成一步模型就更容易胡编时间。另一个实用的设计是“澄清机制”。模型判断用户问题模糊时不直接回答而是生成一个反问句“请问您申报的是哪个省份的高企认定”我把这个行为定义成Prompt里的一个分支指令并给出一个结构化输出要么是answer字段要么是clarify_question字段。业务代码根据字段值决定直接展示答案还是继续追问。这是最简单的Agent决策逻辑但非常有效。3.4 评估指标与回归测试项目上线前我们建立了一套评估集包含50个真实用户问题和对应的正确答案等级。这里的正确答案不要求逐字一致而是标记为三类完整正确、部分正确、错误。每次调整Prompt或换模型版本时我都会跑一遍这套评估集计算“完整正确率”和“部分及以上正确率”。不到一周我就发现改Prompt经常是“东边日出西边雨”某几个问题的回答质量大幅提升另几个却意外变差。所以光看平均值不够我还会按业务模块分组看结果。比如“申报条件类问题”和“政策时间类问题”分开统计这样能更清晰定位哪部分退化了。我还加了一个“拒答正确率”指标当问题明显超出知识库范围时模型应该明确说不知道而不是硬答。这个指标和“幻觉率”紧密相关宁可多拒绝也不要乱回答。没有这套评估你根本无法进行科学的Prompt迭代基本就是瞎试。4. 常见问题与排坑技巧4.1 模型“胡说八道”的根治办法大模型幻觉是绕不开的问题。我常用的手段有哪些首先是强约束输出格式要求模型在给出答案时附带引用编号并且编号必须对应到输入的“资料列表”。如果模型生成了一个不存在的编号业务代码就要拦截掉重新请求。其次是用“二次校验”。对于高风险回答比如涉及金额、期限、资质要求的问题我让模型先生成一个待定答案然后把这个答案连同原始资料一起去问另一个模型“请判断以下回答是否完全基于给定资料若存在超出资料内容的信息请指出。”等于让一个“评审”模型去审计“回答”模型。这个方法会多一倍token开销但准确率提升非常明显。4.2 Token开销失控与控制我第一次做Agent时控制流写得太随意一次问题来回调用七八次模型单次成本飙升十倍。后来我给工具调用设置了“最大迭代次数”默认3次超过就不再执行下一次调用让模型基于已有信息直接作答。同时对于Agent的中间结果不全部塞回上下文而是只保留工具输出的摘要。还有一个容易忽略的坑系统提示词和示例也会按token计费。如果你每个请求都带超长示例并发一高成本很快就刹不住。建议把常见示例做成一个单独的“示例库”按分类动态注入而不是每次把所有示例都带上。4.3 多AI协作的同步与信任“多AI协作”是最近很火的方向但我的体验是别轻易上因为它带来了一个新的工程问题Agent之间如何建立信任。如果你的主Agent调用了另一个子Agent你得考虑子Agent返回的结果是否可靠、格式是否正确、是否可能陷入死循环。建议采用“白板模式”多个Agent之间的通信不靠自然语言对话而是统一写到一个结构化的状态文件里。比如主Agent决定调用工具时往状态文件里写入工具名、入参和状态工具执行完往状态文件里写入结果字段。这样你随时可以检查每条链路的输入输出重放问题、定位bug都容易得多。如果让Agent自由对话你会陷入“两个模型尬聊到死循环”的窘境。4.4 从demo到生产的8个细节很多项目demo跑通了一上生产就崩。我列几个最容易翻车的地方第一没有设置超时和重试模型接口偶尔会慢必须给请求设置超时时间并建立指数退避重试机制第二没有做并发控制一压测就把模型服务打满了第三没有日志追踪线上问题无从查起第四没有数据版本管理向量库里的资料更新了你都不知道第五Prompt和代码没有一起做版本管理导致历史行为无法复现第六没有做安全和合规检查用户输入可能带恶意注入第七没有做内容审核模型输出可能涉及违规内容第八没有做成本监控没有预警阈值。这八点看着琐碎但任何一个都能让项目在关键时刻崩掉。具体踩得多了你就知道AI工程里所谓的“工程”往往就体现在这些细节上。5. 最后说点个人体会做“ai-engineering-from-scratch”这类项目我最深的体会是技术选型真的不是最难的环节最难的是建立一套“反馈闭环”。从数据准备、Prompt调整、Agent逻辑设计到评估指标每一环都需要你能够快速知道“刚才那个改动到底有没有效果”。还有一个小建议把AI项目当成一个持续演进的产品而不是一次性的交付物。你上线第一个版本只解决60%的问题没关系重点是你要有一套机制不断发现剩余40%的问题并且能低成本地把它们一个个修好。拿政策咨询Agent来说我每周都会看用户提问记录把那些模型答错的、拒答不该拒的、还有被用户反复追问的问题整理成新的测试用例塞进评估集。这样迭代到第三周整个系统的稳定性就肉眼可见地提升了。这个项目做完之后我明显感觉到AI工程已经不像一两年那样充满魔法感了。它越来越像一个常规软件工程只是它的核心组件有一定不确定性。你只要把这种不确定性关进一个结构化的笼子里——用评测、校验、监控去管理它它就会慢慢变得可靠。希望这篇东西能帮你把从零到一的路走得更顺一点。
