很多人以为“AI工程”就是写个提示词、调一下API、让大模型吐出几句像样的话，再包一层Web界面就算完事。真正上手做过一两个项目之后你会发现，事情远没有这么简单：提示词写得再漂亮，换一个模型版本可能就失效；Agent跑着跑着上下文就乱了；每次的人工评测结果都不一样；上线之后成本一天比一天高。我在几个从零到一的AI项目里反复踩过这些坑之后，才逐渐意识到——AI工程的核心不是“让模型说话”，而是围绕模型搭起一整套可控、可测、可持续迭代的系统。这篇文章就基于我自己从一个只会写提示词的初学者，到把AI能力真正落到业务里的整个过程，把里面的关键环节、设计思路和踩坑经验都摊开来说，希望能给准备入坑或者正在硬扛的朋友一点参考。
1. 先搞清楚：AI工程到底在解决什么问题
1.1 AI工程不是“调接口”，而是一套链路
刚开始接触大模型API时，我的认知和大多数人一样：模型给你一个对话接口，你把问题丢进去，它返回一个回答，完事。做第一个原型确实可以这样，但一旦要交付一个“能用的系统”，你会发现真正的工作量不在对话本身，而在对话前后的整条链路：用户的输入要清洗、要补全上下文、要根据业务规则做兜底；模型的输出要校验格式、要过滤敏感内容、要落库、要触发后续动作；中间还要考虑失败重试、超时处理、日志追踪、效果评估。
举个我实际做过的例子：给团队搭一个内部知识库问答助手。用户问“上个月的报销截止日期是什么”，表面上看只需要把问题发给模型就行。但实际上，我要先决定走RAG还是让模型直接答，要准备知识库的切分和检索，要在Prompt里塞入检索结果和提示不捏造，还要在输出后做一个“回答是否基于资料”的判定。这些环节任何一步出问题，用户感知到的就是“这AI瞎说”。
所以AI工程本质上解决的问题是：如何把“不稳定的模型能力”封装成“稳定的业务功能”。模型是发动机，工程是底盘、变速箱、刹车系统和仪表盘。没有工程，发动机再猛也上不了路。
1.2 从零起步前，先画清的三个边界
动工之前，我建议先花时间把这几个问题想清楚，比起急着写代码收益大得多。
第一个是能力边界。大模型擅长的是“理解、生成、归纳、改写、初步推理”，不擅长精确计算、不擅长处理超长文本的细节保持、不擅长完全不出错的规矩判断。任何一个新项目，先把“哪些环节必须模型做、哪些环节用传统代码做”这个分工划出来。比如我做的表格数据提取，数字加减一定用代码，模型只负责理解表头和语义，绝不让它做运算。
第二个是数据边界。模型不知道你的业务数据，不要指望它“凭经验”回答。内部制度、产品文档、私有库表结构，这些要么通过检索喂给它，要么在微调时灌进去。没有数据支撑的AI功能，做得再炫也是空中楼阁。
第三个是成本边界。模型调用按token计费，对话多了、上下文长了，费用指数级上升。我在第三个项目里把系统提示写成几百字，每次请求固定烧掉一千多token，一天上万次调用，光提示词成本就够买一台开发机。所以从第一天就要有成本和延迟的预算意识，不能只看功能好不好。
2. 提示工程：AI工程的第一块基石
2.1 一套能复用的提示词骨架
提示词工程经常被讲得很玄，但落到工程上，无非是要让模型在多变场景下稳定输出。我摸索出一套固定骨架，几乎所有任务都能套用：角色定义、任务说明、上下文输入、输出格式、边界与禁忌、示例。每一块都有明确作用。
角色定义的作用是设定模型的语言风格和立场，比如“你是企业内部的IT支持工程师，回答要简洁、步骤化”。任务说明要具体到动词级别，不要写“帮我分析”这种模糊话，要写“根据下面的日志，判断故障根因，并输出处理建议”。上下文输入就是你要喂给模型的数据，比如检索到的文档片段、用户填写的表单。输出格式一定要强制，最好要求JSON，且给一个字段级别的示例。边界与禁忌最容易被忽视，比如“如果资料中没有答案，直接说资料未覆盖，不要编造”。示例则是给模型作模仿样本，一个高质量示例胜过十句描述。
我见过太多人把提示词写成一长段“自由表达”，模型发挥极不稳定。工程化的提示词应该像接口规范：字段清晰、约束明确、输出可解析。这不仅是写给模型看的，也是写给未来接手的人看的。
2.2 上下文窗口管理：别让小模型干大活，也别让大模型记流水账
上下文窗口有限，这是AI工程里最容易被忽略的硬约束。一长段对话累积下来，早期信息会被挤掉，模型开始“失忆”；塞入太多无关内容，回答质量和速度都会下降。
我的做法是给上下文分分类：系统级信息（角色、任务规则）、会话级信息（用户的多轮对话摘要）、任务级信息（本次请求的检索结果、表单数据）。系统级每次都在，但要压缩到最精简；会话级用“摘要+最近N轮原文”的方式管理，超过阈值就滚动摘要；任务级只放与本次请求最相关的内容。做知识库问答的时候，我见过直接把整篇文档塞进去的，结果又贵又慢，切块检索再拼装才是正路。
另外要留意模型对上下文中间的注意力不如开头和结尾。重要的指令放开头，最新的用户诉求放结尾，中间放参考材料。这个位置效应是我实测下来最直观、最值得利用的一个特性。
2.3 结构化输出与参数设置的几个实测经验
工程上最怕解析模型自由文本。我的习惯是：能用JSON就不说人话，能用枚举就不让模型自由发挥。设置JSON输出时，在提示词里给一个完整的字段示例，比单纯说“输出JSON”靠谱得多。对输出再做一层代码校验，比如用JSON Schema或者简单的正则，不合格就让模型重试，一般重试一两次就能拿到干净结果。
温度参数方面，凡是做抽取、分类、改写这类确定性任务，我把温度压到0或0.1；做创意文案、头脑风暴才提到0.7以上。top_p和temperature通常只调一个，两个一起动容易打架。还有一个细节：max_tokens别设置得太小，否则长回答会被截断成一个残缺句子。我在做周报生成时就吃过这个亏，输出被截断成半句话，看起来特别糟糕，后来调大了上限，并在提示词里要求模型“必须输出完整段落”，问题才解决。
3. AI Agent与Harness Engineering：把单次对话变成可持续的自动化流程
3.1 为什么需要“编排层”而不是直接怼API
单次问答做到一定程度后，你会遇到一个天花板：很多真实任务不是“一问一答”能解决的。比如“帮我查一下昨天的线上报错，分析原因并给出修复建议”，这个任务需要查日志、看代码、读文档、可能还要跑个测试，一次对话调用根本做不完。这时候就要上Agent——让模型自己规划工具调用序列，一步一步完成目标。
最近圈子里一直在讲harness engineering，说白了就是给Agent搭一个“脚手架”：模型负责决策和表达，你负责把工具注册好、把执行环境管住、把循环和退出条件定义清楚、把失败处理兜住。我在实际项目中体会最深的，是这个脚手架比模型本身更决定成败。模型想得很好，但步骤一多就乱；工具返回了意外格式，模型就不知道怎么处理；循环没有上限，一次任务能跑几十轮。这些都要靠工程手段来约束。
3.2 从0到1搭建一个带工具调用的Agent（完整案例）
拿我最近做的一个“工单智能处理Agent”来拆解。目标是：用户提交一个故障工单，Agent自动检索知识库、查询工单状态、生成处理建议，并把工单分类。工具集我注册了三个：知识库检索工具、工单系统查询工具、分类规则校验工具。
系统提示写清楚：你是工单处理助手，必须按“理解问题 -> 收集信息 -> 给出结论”的顺序执行，工具结果不足时禁止臆测。工具描述也花了不少功夫，因为模型靠描述来决定调用哪个工具。比如检索工具我写的是“当需要查阅内部运维文档时使用，输入为关键词，返回匹配文档片段”，描述里的触发条件越明确，模型选错工具的概率越低。
主循环逻辑我也不用复杂框架，自己写了几十行代码：组装消息列表，调模型，如果返回里有工具调用请求，就执行对应函数，把结果追加回消息列表，再调模型，直到模型不再请求工具。整个过程设了最大循环次数和总时长上限，防止死循环和超时。第一次跑通时，我兴奋地点了几个真实工单，效果竟然还不错，最意外的是它会在信息不足时主动选择“询问用户”而不是瞎猜，这在工程上意义很大。
3.3 任务规划、循环控制与失败回退机制
Agent跑起来之后，问题集中在三类：规划跑偏、执行失控、工具报错。规划跑偏的典型表现是模型跳过某些步骤，直接给出结论，我的办法是在系统提示里放大步骤检查指令，并让它在每轮输出前先写“当前进度与下一步计划”，虽然多花一点token，但可控性明显提升。
执行失控主要靠循环限制来防：最大步数、最大token消耗、单步超时，三个参数设成硬性上限，达到就终止并把“中间结果+终止原因”返回给调用方。工具报错则是必然事件，我做了双重兜底：工具层把异常转成对模型友好的错误描述（比如“数据库连接超时，请稍后重试”），模型层在收到错误后自动调整策略，比如改用备用工具或者降低检索范围。
这套编排层的核心价值，是把模型的自由发挥限制在业务允许的轨道里。懂行的人都知道，Agent项目里真正值钱的不是那几次华丽的模型回应，而是那些能让系统稳定不脱轨的工程细节。
4. 评估与测试：AI工程的“质检车间”
4.1 LLM输出的不确定性决定了测试方法不同
传统软件测试有明确预期结果，函数输入3，断言输出6，错就是错。但大模型的输出没有固定答案，同一个问题问十次可能有十种说法，这就逼着我们换一套测试思路。
我把测试分成两个层次：单元级和场景级。单元级测的是“某个提示词模板在固定输入下的输出是否符合格式要求、是否包含关键字段”，我写了一批自动化的规则断言，比如“日期格式必须为YYYY-MM-DD”“分类字段必须属于枚举值之一”。场景级测的是“整个流程跑下来是否满足业务目标”，比如给Agent一个模拟工单，看它最终输出的建议是否合理、是否调用了正确的工具。场景级我用人工抽检+模型评分结合，人工保证质量，模型评分提高覆盖广度。
4.2 一套实用的评测集与评分标准
评测集建设是我觉得投入产出比最高的环节。我按业务场景整理了五十个典型样本，覆盖正常、边界、异常三类：正常的包括标准工单、常见问题；边界的包括超长文本、模糊问题、多意图问题；异常的包括空输入、乱码、违反假设的提问。每个样本除了输入，还写了期望行为描述，比如“应该触发知识库检索”“应该追问用户澄清”。
评分标准我拆成几项：格式合规、内容准确性、逻辑一致性、可操作性、幻觉程度。每项打分1到5分，最后取加权平均。为了减少人工打分的主观偏差，我让两个同事背靠背各评一次，分歧大的样本再讨论归因——多数情况是提示词意图不清晰导致的，改提示词比调模型更有效。
4.3 自动化回归与幻觉防护的落地做法
一版Prompt改完，最怕的是旧功能退化。我把评测集接进了CI流程：每次修改提示词或Agent逻辑，自动跑一遍评测集，给出分数对比。这个方法看起来笨，但确实帮我拦住过不少回归问题。有一次我把系统提示精简了一些，工单分类的准确率下降了四个百分点，回归测试一眼就看出来了。
幻觉防护是又一个重点工程。我在知识库问答里加了一个“引用来源”机制：模型必须在回答末尾列出所依据的文档编号，如果模型输出的内容在检索资料中找不到对应片段，我就判定为可疑。再加上一个后置校验函数，用相似度匹配把“无中生有”的比例压得很低。这套做法不完美，但对绝大多数内部工具性质的AI应用已经够用。
5. 落地过程中的常见坑与排查实录
5.1 上下文溢出与“失忆”
做Agent之后，上下文溢出成了我最常遇到的坑。工单Agent处理复杂任务时，对话轮数一多，前面的工具结果和中间推理就被挤出去了，表现为模型突然忘了自己查过什么数据，或者重复调用同一个工具。
我的排查思路分三步：第一步看日志里消息列表的token消耗，确认是否接近窗口上限；第二步检查消息拼接逻辑，看是原始消息保留了太多无关轮次；第三步对会话做摘要压缩。后来我改成“滚动窗口+按需摘要”的混合策略：保留最近五轮完整消息，更早的内容用一段摘要代替，工具返回结果只保留关键字段，去掉冗长的原始输出。这么一改，长任务的完成率提高了不少。
5.2 工具调用解析失败的排查
工具调用依赖模型输出结构化的调用参数，而模型有时候就是会返回格式不标准的JSON，或者参数缺东少西。刚开始我遇到参数缺失就直接报错，后来发现加一层“容错解析”非常管用：先正则适配最规范的格式，失败就用宽松模式提取字段，再不行就重试一次，给模型返回“你上一个工具调用格式有误，请重新生成”。重试机制加上去之后，解析失败率从百分之十几降到了个位数。
更根本的解决办法是精简工具参数。工具一多、参数一复杂，模型就容易出错。我给每个工具的参数都做了最小化设计，能用字符串就不用嵌套对象，能用默认值就不让模型填。这里的原则很像给同事设计接口：越简单越不容易用错。
5.3 成本与延迟失控怎么办
一次长对话Agent跑下来，几十万token并不稀奇，费用涨起来非常快。我的措施是分层治理：第一层是缓存，固定不变的系统提示和知识库检索结果做预处理缓存，省掉重复计费；第二层是控制上下文长度，工具返回结果做截断和摘要，不把整块日志塞进对话；第三层是设置熔断机制，单次任务token消耗超过阈值就强制终止，返回部分结果并提示管理员。
延迟方面，最大的敌人是对话轮次太长。每轮模型调用都要一两秒，五轮就是十秒，用户根本等不了。我减少不必要的中间轮次，尽量让模型一次调用完成多步工作，同时把不影响主流程的步骤异步化。实测下来，平均响应时间从十几秒降到了五六秒，虽然不算快，但至少能用。
5.4 模型迭代导致行为漂移的处理
模型供应商升级版本是件让人又爱又恨的事。升级往往带来更强的能力，但也可能悄悄改变输出风格和格式偏好。我有一次没看更新说明直接切了新版模型，结果所有输出从纯JSON变成了带Markdown代码块的JSON，解析函数全部罢工。
现在我的处理策略是：版本固定优先，生产环境锁定一个具体模型版本，不轻易跟随默认更新；升级前用评测集跑一遍对比，重点看格式合规率和关键场景分数；如果确认升级，再检查提示词里是否需要补充格式示例。这个流程虽然保守，但能避免很多线上故障。
常见问题速查表
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 输出JSON解析失败 | 模型返回了带Markdown的JSON | 提示词中明确“不要代码块”，加容错解析 |
| Agent重复调用同一工具 | 上下文过长导致信息丢失 | 缩短工具返回结果，增加会话摘要 |
| 回答在资料外编造 | 检索结果不足/幻觉 | 加引用来源要求，做后置校验 |
| 统一请求费用猛增 | 上下文过长或循环无上限 | 设置token熔断和最大轮数 |
| 模型版本更新后行为异常 | 输出偏好漂移 | 锁定版本，升级前跑评测集 |
| 长文本回答被截断 | max_tokens太小 | 调大上限，提示词要求完整输出 |
| 效果时好时坏 | 温度设置过高 | 确定性任务温度压到0~0.1 |
6. 回看：从零到一的最小可行路线
6.1 我个人建议的起步顺序
如果让我重新走一遍，我会先按这个顺序推进。第一周只做一件事：选一个极小的场景，比如“把客服问答里的常见问题分类”，用现成模型加提示词跑通端到端，先不看工程化，只看业务价值是否成立。第二周开始加规整：拆分提示词模块、设计输出格式、接上评测集，把这一件事做到稳定。第三周再上Agent和工具调用，只加一个必要的工具，跑通“模型决策+工具执行”的闭环。
这个顺序的核心是“先窄后宽”：先用小场景验证价值，再用工程手段加固，最后才扩展复杂度。我见过不少团队一上来就搞多Agent协同、复杂工作流，结果连最基础的单Agent都不稳定，翻车概率极高。
6.2 一个小技巧和后续扩展方向
最后分享一个我一直在用的技巧：所有提示词和Agent配置都当作代码一样管理，进版本库、写变更记录、配好测试集。每次改动都能回溯，出了问题能快速回滚。这个习惯看起来简单，但真的是我在AI项目里收益最大的一件事。
这套体系后续还能往多个方向扩展，比如接入更多业务系统做真正意义上的自动化、引入多Agent协作处理跨部门流程、对高频场景做针对性微调。但万变不离其宗，底层的工程思维是一致的：先把不可控的模型能力关进可控的笼子里，再谈创新。希望这篇“从零开始”的记录，能帮你少走那些我自己走过的弯路。
