做AI工程这一年多我发觉最难的地方不是“用哪个模型”而是“从零开始怎么把一套东西串起来”。很多人以为AI工程就是调API、套LangChain结果真上手才发现需求边界模糊、Prompt改一版崩一版、Agent跑起来不可控、上线之后没人敢信输出结果。这篇东西不是概念科普是我从零搭过知识库问答、自动化分析Agent、多Agent协作流程之后沉淀下来的一套完整路径——从怎么拆需求、怎么选技术栈到Prompt具体怎么写、工作流怎么编排、上线后怎么排查全部用真实项目经验讲适合正在从“跑通Demo”走向“做成产品”的人参考。1. 先搞清楚AI工程到底在“工程”什么1.1 传统软件和AI工程的本质差异传统软件工程的核心是“确定性”输入A走分支B得到输出C每一步都可以单测出bug了直接定位到哪一行。AI工程完全不是这套逻辑。模型是概率系统同样的Prompt在不同时间调用输出可能差很多。所以我刚开始做的时候犯过一个典型错误——用写后端接口的思路去写AI应用结果整个系统像一坨无法预测的黑盒出了问题不知道是该改代码还是该改Prompt。AI工程真正要“工程”的是把概率系统的不可控性用结构和约束包起来。具体来说有三层第一层是数据层决定模型能看到什么包括知识库切片、向量化、检索质量第二层是推理层决定模型怎么思考包括Prompt结构、工具调用逻辑、多步推理路径第三层是应用层决定用户怎么用包括工作流编排、状态管理、结果校验、降级策略。这三层没有一层是靠“换个更强的模型”能解决的。传统软件里性能瓶颈通常在数据库或网络AI工程里瓶颈往往是“上下文和信任度”。你在本地跑通一个Demo只需要5分钟但把它变成能稳定服务100个用户的系统要考虑的是检索结果准不准、模型有没有幻觉、超时了怎么办、用户问到了知识库之外的东西怎么回应。这些才是工程的核心。1.2 “从零开始”的常见误区这几年我见过太多“从零开始”翻车的案例无外乎三种第一种是“模型驱动陷阱”。上来就比参数、比跑分GPT-5出了马上换。实际上换了模型之后Prompt要重新调评测要重新跑成本结构全变了。模型选型应该最后一个做而不是第一个做。第二种是“框架驱动陷阱”。看到GitHub上LangChain星标多觉得用上就等于会了AI工程。我之前也被框架绑架过——为了用一个现成的Agent类被迫接受它的Prompt模板和状态管理方式出了问题查源码查了半天。后来我把大部分业务逻辑改成原生Python实现只保留真正需要的抽象层代码量少了30%可调试性却翻倍。第三种是“Demo驱动陷阱”。Demo和产品之间隔着一条巨大的河评测、监控、成本控制、安全兜底、迭代流程。你给老板演示的时候模型表现很好是因为你精心挑了五个问题。真实用户不会按你的脚本提问。做AI工程必须有“从失败中学习”的准备第一版一定是不完美的关键是建立一套迭代机制让系统每周都比上周好一点。2. 从零搭建一套AI工程的核心技术栈2.1 模型选择不是越大越好而是越合适越好模型选型我现在的思路是“按任务复杂度分层”。简单分类任务、实体提取这种用中小参数模型比如7B-14B的量化模型就够速度快成本低复杂推理、多步工具调用才需要上旗舰模型如果涉及敏感数据不能出内网还要考虑本地部署。一个很实用的判断方法拿你业务里最难的20个问题分别用不同档位的模型跑一遍人工打分然后看“分数差”和“成本差”哪个更值得。我做过一次实测某个内部文档总结任务小模型90分旗舰模型95分但成本差了20倍。最后用了小模型加一层后处理校验把准确率拉到了93分综合性价比完胜。另外一个容易忽略的点是上下文长度。参数上写的128K上下文并不代表128K的内容效果都一样好。实测超过一定长度后模型对中间部分的记忆会明显下降。所以设计系统时不要把“能塞多大的上下文”当卖点而是尽量让检索模块只把最相关的内容送进Prompt而不是一股脑全塞进去。2.2 编排与Agent框架怎么选关于框架我的态度分三个阶段初期可以用中期要敢拆后期只保留核心抽象。市面上主流框架提供的东西无非四类模型调用封装、Prompt模板管理、工具注册与执行、状态与记忆管理。前两类其实用几十行原生代码就能实现没必要引入重依赖后两类才是框架真正有价值的地方——工具调用循环和记忆机制确实容易写错。以Agent为例核心循环其实就三步观察决定下一步做什么→ 行动调用工具→ 反馈把工具结果放回上下文。自己用代码写这个循环并不难反而是套框架时被它的抽象绕晕。我现在倾向于“轻框架重代码”用框架的向量存储和模型调用接口但业务编排逻辑全用自己写的Python控制每个环节都能打断点调试。工具注册这块有个关键设计不要让Agent拿到“所有工具”。每多一个工具模型的选择空间就大一分出错的概率也升一分。我一般会做动态工具列表——根据用户问题先做一个粗分类然后只向Agent暴露当前场景下可能用到的3-5个工具大幅减少乱调用的情况。2.3 记忆、检索与数据底座记忆和检索决定了AI的“靠谱程度”。刚开始做知识库问答时我天真的以为把文档全扔进向量库就完事了结果发现检索质量惨不忍睹。后来才明白RAG的瓶颈80%在“数据准备”不是向量化。切片是最容易被低估的环节。按固定字符数切片会让语义被切碎比如一个表格被切成两半检索出来就只剩半张表。我现在会先用结构解析把文档拆成标题块再做语义边界调整每个切片尽可能是一个完整的论点或操作步骤。切片之间的重叠overlap也必须有否则边界处的语义会丢失。向量模型的选择同样影响巨大。中英文混合场景用通用embedding模型效果一般我会用领域微调过的向量模型并且做“查询改写”——用户问“这个功能怎么排查”实际检索时改写成“故障排查步骤”去匹配。评测过一组数据查询改写后Top-5命中率从61%提到了78%。3. 实操从零构建一个知识库问答Agent3.1 需求拆解与边界定义直接讲我最近一次完整项目的实操过程。任务是做一个内部技术文档问答Agent用户是几十名研发人员他们想用自然语言查文档而不是翻Wiki。听起来需求很明确但开工前我还是做了三轮需求澄清第一轮定义“能做”范围限定在“已入库的技术文档”越界问题明确告诉用户“没查到相关内容建议去Wiki搜关键词XX”绝不自己编。第二轮定义“不能做”不回答代码评审、不诊断线上故障、不处理私人数据——这些是安全边界必须靠系统指令和工具权限双重卡死。第三轮定义“好用的标准”用户能接受的答案是“有结论、有步骤、有出处”所以最终答案里必须包含引用来源。这三轮做完整个系统的评估指标就定了检索命中率、答案完整度、引用准确率、和“拒答率”该拒绝时没拒绝就是事故。有了指标之后每一步改动都能量化不再靠感觉判断“好像变好了”。3.2 Prompt设计从提示词开始的第一版项目的第一版Prompt我保持了极简结构核心逻辑不超过20行。系统提示词只做四件事身份定义、任务边界、输出格式、行为红线。下面是这个项目用的简化版Python代码用来说明结构而不是照搬system_prompt 你是公司的技术文档助手。你只根据参考资料回答问题。 遵守以下规则 1. 如果参考资料中找不到答案直接说“文档库里没有相关内容”不要推测。 2. 引用每个结论的来源格式为[来源: 文档标题, 章节]。 3. 回答时先给结论再给步骤最后给参考链接。 4. 如果问题涉及代码评审、线上故障或私人数据礼貌拒绝并说明范围。 参考资料 {retrieved_context} 这段Prompt看着简单迭代过程中我发现几个坑。第一版没有“行为红线”结果用户问“帮我看看这段代码有什么Bug”模型真的根据上下文开始瞎分析犯了越界错误。加上第4条之后拒答行为终于可控。输出格式约束也很重要。我遇到过一次离谱情况模型在回答中间突然开始自言自语“让我想想这个问题”。后来我在Prompt里加了“直接输出答案不要解释思考过程”情况立刻消失。现在我会对输出格式做结构化约束要求模型按固定JSON返回工程上也好解析。3.3 工作流与工具调用项目没有直接用Agent框架的默认循环而是自己定义了一条流水线意图识别 → 查询改写 → 检索 → 重排 → 生成 → 校验。这里的关键设计是“先检索后生成”而不是把检索本身包装成一个工具让模型自己决定要不要调。前者稳定可控后者灵活但容易失控生产环境我选稳定。意图识别和查询改写我用的是一个带结构化输出的分类Prompt把用户问题映射成几类意图同时生成2-3个检索变体。这一步能让“查不到”的概率下降很多。重排环节我用的是轻量级交叉编码器虽然比向量检索慢一点但只对Top-20结果重排耗时可以忽略准确率提升却非常明显。def agent_pipeline(question): intent classify_intent(question) if intent out_of_scope: return 这个问题超出我能处理的范围建议咨询相关负责团队。 queries expand_queries(question) candidates [retrieve(q, top_k20) for q in queries] merged merge_rank(candidates) top_docs rerank(question, merged)[:5] answer generate(question, top_docs) return validate_answer(answer, top_docs)校验这一步是生产环境最重要的兜底。我在代码里加了一个简单的检查器如果答案中包含“根据我的经验”“我认为”“可能也许”这类主观词系统会自动标记为“低置信度”提醒用户谨慎参考。经验类AI项目可以不要这步但工具型产品必须有因为用户会拿你的答案去做决策。3.4 部署与观测部署层面我用的是FastAPI包一个服务接口加内存缓存和限流。缓存是省钱利器——完全相同的用户问题一周内出现的比例通常超过15%缓存命中一次就省一次模型调用。限流也必须做尤其是内网服务一个用户写个for循环就能把你的预算跑穿。观测是我早期最不重视、后来最后悔的部分。现在每个请求我会记录五样东西模型名称和版本、Prompt的最终形态包括检索到的内容、token用量、响应延迟、用户反馈。为什么记录Prompt完整形态因为模型版本升级后行为会变没有历史快照就没法排查“为什么这周效果突然差了”。LangSmith这类工具可以用但我后来发现自建一张日志表简单的看板足够满足90%的需求。关键是“有数据”而不是“工具多高级”。有了日志后续做评测集、微调、Prompt优化才有底料。4. 上线后最容易踩的坑与排查实录4.1 上下文失控又长又杂才是元凶项目上线两周后用户反馈“回答变笨了”。排查后发现问题出在Prompt里累积的会话历史——用户和Agent对话超过十轮后历史消息全部被塞进上下文干扰了模型对当前问题的判断。这个问题的本质是上下文越长注意力越分散。模型不会因为你给了更多信息就变聪明反而会被无关内容带偏。我的解决方案是做会话摘要压缩——每五轮对话之后用一次轻量模型调用把历史总结成要点只保留当前问题相关的部分。另一个上下文失控的场景是工具返回结果太长。比如用户问“所有服务状态”工具返回了200行原始数据模型根本处理不过来。我给工具加了一层裁剪逻辑根据当前问题的关键词只保留相关行和摘要统计值实在需要全量数据就写进临时文件让用户自己下载不让模型消化。4.2 幻觉与质量评估没有尺子就没法迭代幻觉是AI工程绕不开的话题。我的经验是不能指望Prompt里写“不要编造”就解决幻觉必须靠“引用约束”和“校验兜底”双管齐下。引用约束要求每个事实点必须带来源校验兜底则是对答案做事实提取回源检索文档验证一致性不一致就拒绝输出或降级提示。评测体系建议从第一天就建立。不需要一开始就搞几百条的复杂工程最简单的做法是留出50条有标准答案的业务问题每次改动后跑一遍看三个指标完全答对率、部分正确率、答错率。有了这个基础集你就能判断“换模型到底有没有变好”“改了Prompt是真的进步还是碰巧”。我在评测里还加了一个“边界问题集”——专门放那些不该回答的问题比如“帮我预测股价”“你能修改我的代码吗”。如果系统开始过多回应这类问题说明Prompt约束失效了需要立刻处理。4.3 成本与延迟预算不失控的几条铁律最后说下成本和延迟控制。第一条铁律是“大模型只做它必须做的事”。分类、改写、提取这些子任务能用小模型就不用大模型生成主答案才用旗舰模型。按这个策略我项目的单次调用成本降低了将近一半而用户感知到的质量没有明显变化。第二条铁律是“设置合理的max_tokens”。很多开发者的模型调用都不写这个参数导致模型跑满全速生成一大段废话。按业务场景分析答案长度分布集中在300-500字那我直接设600上限既保质量又节约预算。延迟优化上我做了两件事一是检索和生成的部分环节并行化让向量检索在做查询改写的同时就启动二是对高频问题做答案缓存缓存命中时延迟从3秒降到50毫秒。这两项加起来线上P95延迟从4.8秒降到了1.9秒体感是质的飞跃。最后再分享一个个人体会AI工程最迷人的地方是“永远没有标准答案”最折磨人的也是这一点。我经历过把同一套系统推倒重写三次的夜晚也有过为一个评测分数提升熬夜调Prompt到凌晨两点的时刻。现在我反而觉得做AI工程最重要的一课是接受不确定性然后用工程手段把不确定性一点点关进笼子里——评测集是你的尺子日志是你的眼睛兜底逻辑是你的安全网这三样东西比任何模型都重要。如果你也正在从零搭建自己的AI工程建议从一个小范围、高价值的场景开始先跑通全链路再扩展别一开始就想着做大而全的平台。