先给背景下一个判断这两年AI工程化被说滥了但真正把一套AI功能从零做成稳定线上服务的人其实没那么多。我见过太多团队把提示词当作文案模板、把Agent跑通一次demo就以为交付了结果一上真实流量就露馅。这篇东西是我自己从零搭过好几轮AI工程之后的实践沉淀核心想聊清楚一件事所谓的AI工程到底在工程化什么以及从零开始要怎么一步步把它立住。适合正在搭AI应用的开发者、想把提示词和Agent做成可控流程的测试与运维同学也适合被老板一句“做个AI能力”砸晕了的产品经理。1. AI工程的核心把不确定性变成可维护性1.1 会调API不等于会做AI工程市面上大量教程教的是怎么调用大模型接口这属于“会用工具”离“做工程”还有很大距离。AI工程真正解决的是三件事输出不稳定怎么兜底输入千变万化怎么收敛模型升级换代怎么不崩。我自己踩过的最深的一个坑是早期做AI写作助手时直接把用户输入拼接进提示词希望模型“自由发挥”。结果同一个主题上午输出结构清晰下午就变成车轱辘话用户反馈说“AI变笨了”。后来排查了半天才确认不是模型变笨而是我们没有对输出做任何约束和验证模型在长上下文中漂移了。这件事让我彻底理解了AI工程的第一性原理不是“让模型更聪明”而是“让系统的行为方差足够小”。从这个角度看AI工程更像传统的可靠性工程而不是算法调优。你不需要把模型调成神你需要让它在边界条件内稳定发挥。所以真正的AI工程路线图一半时间花在提示词和模型调用上另外一半花在外层工程上输入清洗、输出校验、兜底策略、链路追踪、回归测试。1.2 典型链路是什么样的一套正经的AI工程从零到一至少要经过六个环节问题定义搞明白到底要解决什么业务问题以及AI在其中扮演什么角色方案选型选模型、选应用形态、选工具链这一步决定后续所有工作的复杂度数据准备收集和清洗样例、构建评估集注意原始脏数据不能直接进提示词能力接入写模型调用层、设计提示词、编排Agent逻辑把“能跑”跑通评估测试建立自动化评估机制覆盖正常路径和边界路径让效果可度量上线运营做日志、监控、版本管理在运行中持续发现问题并迭代这个链路的顺序不能乱。我见过有人先写代码再想需求结果模型业务边界没想清楚代码写了一半就推翻重来。也见过有人一上来就研究微调模型其实业务只需要调参提示词就能解决白费了两个月。六步里面最容易被跳过的是第一步和第五步也是最致命的。问题定义不清后面全是返工没有评估机制任何改动都靠“感觉还行”这不是工程是赌博。2. 从零开始的方案选型模型、形态与工具链2.1 模型选择的成本逻辑第一步是选模型。大模型市场已经形成了明显的分层通用旗舰模型适合复杂推理和创意生成轻量模型适合高并发低成本的分类抽取任务开源可私有化模型适合数据敏感场景。选型时主要权衡三个维度效果下限、成本上限、数据合规约束。我个人的经验是先让业务方收集一百条真实问题拿两三个候选模型跑一遍不要只看答案好不好要看答案的“坏法”是否可控。比如做客服场景模型回答得不完美没关系但绝对不能出现幻觉乱承诺那就要选能够通过提示词严格约束住的模型或者干脆在输出层加规则拦截。成本上有一个常被忽略的点token消耗不仅是用户输入和模型输出的长度还包括你为了让模型稳定而注入的系统提示词和示例。我见过一个项目系统提示词加示例一共四千多token单次调用成本比用户问题本身还高三倍。所以提示词不是越长越好要在“表达清晰”和“成本可控”之间找平衡。2.2 应用形态决定复杂度AI应用大致有三种形态复杂度递增第一种是“单轮问答”用户问一句模型回一句。这种最简单适合知识问答、内容生成开发量集中在提示词设计上。第二种是“检索增强问答”先根据用户问题检索相关资料再交给模型总结回答。这种形态适合企业内部知识库、文档问答复杂度在于检索质量与提示词上下文的配合。第三种是“Agent自主执行”模型不只是回答问题还会调用工具、读取数据、做出决策跑完一个多步骤任务。这个复杂度直接上一个台阶涉及工具协议设计、状态管理、异常恢复、多轮纠错。说句实在话大部分场景根本不需要Agent强行上Agent只会给自己制造一堆可观测性和维护性的麻烦。我建议没有经验的同学从第二种形态切入也就是RAG式的问答系统。它比单轮问答更有落地价值又不会像Agent那样动不动就失控。等检索、提示词、评估体系都跑顺了再往Agent方向演进会稳很多。2.3 工具链怎么搭配技术选型这块我倾向务实。Python是AI工程的主流语言生态最全遇到问题资料也多。框架层面如果你只是调API直接上requests或者openai sdk就够了没必要为了“架构感”引一堆依赖。等确实要做复杂Agent编排了再看LangGraph、CrewAI这类框架因为它们的抽象能省掉不少样板代码。但有一件事要提醒不要迷信框架。框架解决的是通用编排问题你的业务一定有一些独特逻辑要自己写。盲目套框架的结果就是框架升级你不敢动框架的默认行为跟你的需求不匹配一堆workaround堆上去最后比不用框架还乱。3. 提示词工程第一道也最容易被低估的关卡3.1 提示词到底是什么圈内对提示词工程有两种极端看法一种觉得它是核心魔法一种觉得它很快会消失。我的判断是提示词工程不会消失但它会越来越像“需求文档”和“接口协议”的混合体。它的本质是把模糊的业务需求翻译成模型能稳定执行的指令同时堵住那些模型容易犯错的口子。一个好的提示词不是文采好而是约束到位。要写清楚任务目标、输入格式、输出格式、边界条件和失败兜底。我用一个例子来说明同样是让AI写工作周报弱提示词“帮我写一份周报。”这种提示词模型只能靠猜。你不知道它会按什么结构写不知道它会不会编造你根本没做过的事更别说稳定输出JSON给下游程序解析了。有工程意识的提示词至少要包含这些信息你是项目助理请根据我提供的本周工作记录生成一份周报。 要求 1. 只使用我提供的事实不得补充任何虚构内容。 2. 按“本周完成 | 遇到的问题 | 下周计划”三个板块输出。 3. 遇到信息不足时在对应板块写“暂无”而不是编造。 4. 输出为Markdown格式不要添加任何开场白。 本周工作记录 【这里放原始记录】这个版本看起来没什么魔法但它做的事情是很实在的定义了角色、限定了事实来源、规定了结构、给了兜底策略、锁定了输出格式。这五件事恰好就是AI工程里最关心的稳定性问题。3.2 提示词模板的版本管理提示词是会持续演化的。今天发现模型在某种问法下会漏答明天发现某种措辞会触发幻觉你总要改提示词。这就带来一个工程问题提示词也是代码它需要版本管理。我的做法是把提示词模板单独建目录存好和代码仓库放一起。每条模板用yaml或者json维护元信息包括用途、适用模型、作者、修改日期、变更理由。改一句提示词要像改代码一样能回溯。别信“我就临时改一下不影响”我见过太多线上事故就是临时改提示词改出来的。3.3 一个可复用的提示词设计模板我自己沉淀出了一套提示词设计模板套用了很多场景都稳定角色你在系统中承担什么职责需要有什么样的行为准则。 任务用户希望你完成的具体事项描述到不可歧义。 上下文完成任务需要依赖的信息放在显眼位置。 约束绝对不能做的事以及信息不足时的处理方式。 输出格式结构化程度、字段定义、示例格式。 验证模型自检要求如“回答前确认是否遗漏了关键字段”。这六段式不需要每次都写全但关键场景里每段都要过一遍。尤其是“约束”和“输出格式”这两段是防止模型胡说和保证下游可解析的核心屏障。4. Agent与多步骤任务编排把事情做成闭环4.1 Agent的本质是循环如果只把Agent理解成“AI能调用工具”那等于没理解。Agent真正的价值是它能形成一个感知-决策-行动-观察的循环模型判断下一步该做什么调用对应工具拿到结果后更新对任务的理解再决定下一步。我最早做Agent的时候直接在while循环里反复调用模型接口传完整个对话历史。效果还行但token消耗大得惊人。后来才发现问题不在循环本身而在于没有做“状态压缩”——每一轮都把全部历史塞给模型而很多历史信息对当前决策根本没有帮助。工程化的做法是给Agent维护一个精简的工作记忆任务目标、已完成步骤、当前待决问题、工具返回的关键结果。每轮只把这几块拼进上下文而不是倒出一整本流水账。这一步优化能让成本下降一半以上还能减少模型被无关历史干扰的概率。4.2 工具调用的协议设计工具调用是Agent的四肢协议设计得不好Agent就会“手忙脚乱”。核心要设计清楚三样东西工具名、入参描述、返回结构。工具名要直观且语义清晰比如search_stock_price而不是f1否则模型压根不知道何时该用这个工具。入参描述要写清楚每个参数的语义、类型、取值范围最好附上一个示例。模型不是程序员你给它一个“date: 2024-01-01”的示例它就知道这个参数该怎么填。返回结构一定要统一。我见过有人写工具返回自由文本结果模型被一堆无关返回值干扰判断直接跑偏。我自己的习惯是所有工具返回统一用JSON并且带上一个status字段标识成功、失败、无数据等状态。Agent看到status是failure就知道不用硬猜答案而是转而去问用户或者换一种方式。4.3 多Agent协作的编排思路多Agent协作在热词里叫harness engineering。我最早做多Agent是被业务逼的——一个Agent又要查数据、又要写方案、又要做质检上下文越长效果越差单项能力也被稀释。拆成多个专职Agent之后每个Agent的提示词可以做得非常聚焦效果显著改善。但多Agent不是拆得越碎越好。拆得太碎会出现两个问题一是Agent间通信开销大冗余token成倍增长二是责任边界模糊问题出现时不知道该优化哪个环节。我目前的编排思路是“主控Agent加执行Agent”的模式。主控Agent负责拆解任务、调度分工、汇总结果、判断中止执行Agent只负责做好自己的专业活。两者之间走结构化消息而不是自由对话。这样每次失败都能快速定位是哪个环节出了问题该优化谁的提示词该给谁加工具。4.4 Agent的终止与兜底Agent最让人头疼的问题是什么是它停不下来。模型在任务边界模糊的时候会反复调用工具、反复尝试既浪费钱又拖慢响应。我的经验是给Agent三个硬性终止条件目标已完成、达到最大步数、无法取得进展。第三点容易漏但它其实是最重要的。需要判断的是连续两步之间关键结果有没有实质变化如果没有立即终止并返回已收集到的信息而不是继续空转。5. 评估、测试与可观测性AI工程的分水岭5.1 没有评估集就没有AI工程AI工程的评判标准和传统软件开发很不一样。传统代码的行为是确定的输入定了输出就定了AI应用则每次可能给出不同的回答。所以必须建一套针对性的评估集。构建方式也很简单从真实业务日志里挑一百到三百条代表性输入涵盖常见提问、边界异常、易错陷阱。不需要一开始就搞得多齐全先跑起来再慢慢补充。我给每条评估数据打上标签分类包括正常类、边界类、对抗类。以后每次改提示词、换模型、调参数都拿这套数据跑一遍分数不降才算安全。打分维度我常用四类准确性、完整性、格式合规性、兜底合理性。前三个容易理解第四个是看模型在信息不足时是否正确地拒绝回答或者明确说明局限而不是生硬编造。5.2 自动化测试怎么下沉到代码里评估集跑分是离线层的但要真正守住线上质量还需要把测试变成开发流程的一部分。具体我会在CI里挂两类测试示例断言测试对一批固定的输入断言输出里是否包含关键信息、是否满足格式要求这种测试成本和价值比极高评估集跑分任务每次改动都触发一批较大规模的评估汇总分数差异人工确认分数变化是否合理这些测试跑起来之后开发节奏明显稳了。以前改提示词是“这次感觉好一点”现在改成“从92分升到了94分没有回归项”。这感觉完全是两回事。5.3 日志和追踪怎么设计AI应用的日志和传统应用差别很大。传统日志看的是报错和堆栈AI日志要看的是模型的推理轨迹。我把每次请求的日志拆成三层入参层记录用户原始输入、系统提示词版本、模型参数过程层记录Agent每步工具调用、中间结果、决策依据出参层记录模型最终输出、token用量、耗时、打分结果。这三层日志配合一个trace_id串起来一旦出了线上事故能快速回放整个过程。这种可观测性设计是AI工程里最容易被忽视但最救命的部分。没有trace出了问题只能靠用户复述和猜。6. 常见问题与排查经验速查6.1 输出频繁变差或一致性差大概率不是模型抽风而是提示词缺少约束。优先检查三点是否给定了输出格式、是否限制了信息范围、是否设置了兜底逻辑。还有一个偏门原因是示例与任务不对齐模型在模仿示例的风格而不是执行任务。6.2 模型持续重复某句话或某个动作这常见于Agent场景模型在一个失败动作上反复循环。解法是加“连续两次结果无变化即终止”的硬逻辑同时给工具调用增加频次上限。注意这种问题不是调参能彻底解决的必须在代码层做硬性闸门。6.3 上下文越长效果越差怎么优化这叫做“中间迷失”现象。解法有三把最关键信息放在提示词开头和结尾做上下文压缩只保留对当前决策有用的信息把长文本拆成子任务阶段分步处理而不是一次性全塞进去。6.4 改了提示词评分反而下降先别急着回滚看是哪类样本降了。如果是一两个边界样本降了而整体上升可能只是那些样本需要单独优化如果是整体分数下跌大概率是改了核心结构或者模型采用的是另一种输出风格。建议每次只改一个变量不要一次性大改否则你根本不知道是哪个改动导致了变化。6.5 token成本失控优先检查三个环节系统提示词是不是过长、Agent是不是有过多的无效循环调用、日志是不是把所有输入输出都原样落库了。优化手段包括启用上下文缓存、压缩历史、限制最大输出长度、给Agent一个步数上限。成本问题永远是流程问题不是某一行代码的问题。7. 一些经验收尾说实话AI工程走到今天核心竞争力已经不在乎你会不会调用某个模型而在于你能不能把一个不确定的系统做成稳定可控的服务。从零开始做AI工程这几年我最大的体会是越是在黑盒模型面前越要注重白盒工程。把提示词管好、把评估建起来、把日志做透很多看起来玄学的问题最后都能落实到具体环节。最后再分享一个小技巧。如果你今天只能做一件事来提升AI应用的稳定性那就去建评估集。哪怕只有五十条数据它也会倒逼你想清楚这个系统到底在哪些输入上必须表现好哪些边界必须守住。想清楚这件事比换任何模型和框架都管用。