很多人一看到AI工程从零开始这个题目都会本能地以为是从搭一个神经网络开始训大模型。其实我在一线做了这么久的AI项目落地最真实的感受正好相反——从零开始的AI工程第一步不是炼丹而是搞清楚你要解决的问题到底是什么形状。这年头大模型本身的智力已经够用卡住大多数团队的反而是那些看起来不起眼的工程问题提示词不稳定、Agent一跑就失控、多模型协作互相甩锅、效果评估只能靠肉眼。这篇文章我就把自己从零搭建AI工程体系的实际经历拆开讲包括提示词工程怎么做才不玄学、Agent怎么从一个玩具变成能交付的任务闭环、多AI协作怎么编排以及测试和监控怎么落地。内容偏实操适合正在做AI应用开发、想从调接口进阶到搭系统的开发者也适合技术负责人拿来当团队路线图参考。1. 从零开始的真实起点不是训练模型而是定义问题1.1 AI工程为什么不是调API很多刚入行的朋友会困惑我明明已经把大模型的API调通了能聊天能写摘要为什么一放到真实业务里就废掉这其实很正常因为你做的只是模型调用不是AI工程。我之前接手过一个小项目对方说想要一个懂产品的智能客服听起来很简单对不对写个Prompt扔给大模型就行。结果一上线就出事客户问你们和XX家比哪个好模型一本正经地编了个根本不存在的产品参数客户问什么时候发货模型完全不知道自己应该去查订单系统只顾着用话术安抚。这就是典型的调通API和做了AI工程之间的鸿沟——前者只是证明模型能说话后者要让模型在真实业务里按规矩办事、调得动系统、说错话能被拦住。从零开始做AI工程第一件事其实是把会说话变成会干活。这意味着你要在模型外面包一层东西把业务知识喂给它、把工具接口暴露给它、把输出格式限制死、把不该说的话挡回去。这一整套东西才是AI工程的主体也恰恰是从零开始最花时间的部分。1.2 三层结构模型层、编排层、应用层我习惯把AI工程拆成三层来看这也决定了一个项目从零开始时的资源分配思路。模型层这是最底下的一层负责理解与生成。可以是商用大模型API也可以是开源模型自己部署甚至可以是微调过的垂直模型。对绝大多数业务场景你不需要自己训练直接用现成模型就行。编排层这是AI工程的核心负责怎么把模型塞进业务流程。包括提示词的管理、上下文组装、工具调用的规划与执行、多步任务的拆解、以及模型输出之后的校验与修正。很多团队在这一层的代码量占比最高但也是最容易被忽视的。应用层这是用户真正能摸到的东西包括前端界面、交互逻辑、权限与计费、以及和现有业务系统的对接。比如客服机器人要接到工单系统、订单系统、知识库这个接的动作基本都是在应用层完成的。我的建议是从零开始做AI工程不要在模型层自嗨也不要在应用层过早堆功能把60%的精力放在编排层。因为模型能力是市场给的应用体验是产品经理该操心的唯独编排层的工程质量直接决定你的AI系统是偶尔聪明还是稳定可用。打个比方模型层是发动机应用层是车身编排层就是底盘、转向和刹车——发动机再强刹车失灵的车你也不敢开上路。2. 提示词工程把自然语言淬炼成稳定接口2.1 一套可复用的提示词骨架提示词工程看着最玄学但它其实是AI工程里最适合结构化的部分。我自己用过各种花哨的写法之后最终沉淀下来一套固定骨架每个项目套用再调整比每次自由发挥稳定得多。这套骨架一共五块角色定义明确让模型以什么身份工作。别只写你是一个客服要写你是XX品牌官方客服语气专业但不机械不知道的信息必须明说不知道绝对不允许编造。任务说明一句话讲清楚这轮要做什么。这里要注意区分任务和目标——回答用户问题是任务让用户满意并减少人工转接是目标提示词里写任务就够了目标由评估体系去衡量。上下文输入把需要的信息塞进来比如用户订单信息、知识库片段、对话历史。这块最考验工程能力因为上下文窗口有限怎么截断、怎么排序、保留哪些删除哪些直接决定效果。输出格式约束需要JSON就给JSON的schema示例需要表格就给表格示例。格式写死了下游解析才不会崩。边界与兜底明确什么不能做比如如果用户问价格回复请咨询销售顾问如果无法回答输出{unknown:true}。这套骨架我用了快两年最深的体会是提示词不是写出来的是测出来的。你别指望一次到位每次改动用户反馈差就需要抽几条case看模型输出找到规律再改。当你的提示词改到第十版还不稳定问题往往不在措辞而在上下文里缺信息或者在指令本身有歧义。2.2 输出约束与参数配合很多从零开始的人会忽略模型输出参数的重要性我建议每切换一个模型或场景就要重新过一遍这些参数。Temperature控制随机性。客服、代码生成这类任务建议调到0.2以下因为我们需要稳定答案头脑风暴、文案灵感类可以到0.8以上让模型发挥得更开放。Top_p和温度类似二选一配合即可。有些场景我更习惯固定top_p因为它控制的是候选词的累积概率直觉上更接近思维发散度。Max tokens别舍不得限制。一个人越自由越容易漫无边际模型也一样。把输出上限卡死逼着它学会精简也避免超时和费用失控。函数调用Function Calling这是把提示词工程推向接口化的关键能力。与其让模型从一段话里手动解析意图不如直接定义好函数列表让模型输出结构化的调用参数。我用这个方式做意图识别和工具调用准确率和可维护性比自由文本规则解析高出一个量级。如果一定要给个建议早期做原型时放开所有参数怎么爽怎么来一旦准备上线温度调低、格式写死、函数调用拉满把模型的创造力先按住。2.3 提示词的版本管理与回归提示词本质上是代码但很多团队仍然拿它当Word文档在维护。这个问题在AI工程里特别典型——模型是外部依赖你没法保证厂商升级后行为不变所以提示词的版本管理相当于对不可控依赖的补偿机制。我目前的实践是每个提示词模板都是一个独立的Git文件采用类似代码的PR流程——改动前先写一组测试用例说明当前输出应该是什么样改完之后跑一遍全部用例确认没有破坏其他场景。比如有一次我把客服Prompt里不知道信息必须明说改成了尽量引导用户提供信息结果是销售线索获取变好了但用户投诉率也涨了正是靠回归测试在灰度期就发现了异常。再补充一个容易被忽略的点提示词里的上下文变量名要规范。别用根据上面的信息这种模糊指代给每个上下文块加明确的标签比如order_info、knowledge_base。这样模型其实更容易区分信息来源而且对你后续定位问题也方便。这算是让提示词工程代码化的第一步。3. Agent工程化从会聊天到能干活的跨越3.1 Agent的三大子系统如果说提示词工程解决的是单次对话的质量Agent工程要解决的就是多步任务的闭环。这几年AI Agent被炒得很热但我看下来真正可用的Agent其实就三大子系统规划子系统Planner拿到一个任务先拆解成步骤。现在的主流做法是大模型直接输出一个计划必要时配合任务分解的Prompt模板。也可以用目标-子目标的树形结构把复杂目标拆成多个子任务再逐个执行。工具子系统Tool ExecutorAgent必须能调用外部工具否则它就是个只会说的嘴炮。每个工具本质上是给模型提供的一个函数声明包含名称、参数、返回值、以及什么时候该用的说明。工具不是越多越好每多一个工具模型选错工具的几率就高一分。记忆子系统Memory短期记忆是对话上下文长期记忆是向量数据库或结构化存储。做Agent最容易忽略的是过期记忆的问题——三天前的用户需求今天还拿来当依据结果就是越跑越偏。所以记忆系统一定要带时间戳和衰减机制。我的经验是规划子系统决定Agent的上限工具子系统决定Agent的下限记忆子系统决定Agent能不能长期稳定干活。三者缺一个Agent就还是一堆Prompt的拼凑。3.2 用AI编程工具搭建可控harness的完整案例这里重点说一下Harness Engineering——这个词在AI工程里指的是给Agent套上缰绳也就是一套约束、监控和兜底机制让Agent不能乱跑。我最近在用CodeBuddy这类AI编程工具辅助实现Agent harness流程还挺有代表性列出来供参考。首先是设计阶段。我们先用CodeBuddy对话生成一版Agent框架骨架把规划、工具、记忆三个模块的接口先定义清楚。这一步AI编程工具很强它能根据你描述的架构风格快速生成工整的基础代码。但注意别让它一把梭生成整个系统而是让它按模块渐进生成每生成一个模块就人工review一次。AI写的代码尤其是涉及异步调用和错误处理的逻辑第一版大概率有边界问题。然后是harness的落地。我们实际要做的是三层护栏输入过滤在用户输入进入Agent之前先做一轮安全与合规检查以及格式校验。输出校验模型生成的内容先用规则引擎和另一个小模型做双重校验比如检查是否包含敏感内容、JSON是否合法、字段是否完整。行为兜底给Agent设一个最大工具调用次数和超时阈值一旦循环超过限制就强制终止避免死循环烧钱。这三层护栏用CodeBuddy实现时我最大的体会是AI编程工具擅长从对话到代码的翻译但它不理解你的业务兜底逻辑。比如用户如果问竞品对比我们应该返回什么这类业务规则还是需要我们自己沉淀、写进harness的配置中心里。AI编程工具能帮你搭的是骨架里的管道可管道里流的水—业务规则—必须自己定义清楚。最后是测试。我们给harness写了一套注射测试用例故意让Agent去调用不存在的工具、故意传超大上下文、故意让工具返回异常验证兜底逻辑是否生效。这些用例本身也可以用AI编程工具批量生成但每条用例的预期行为必须人工确认。现在这套harness跑了两个多月Agent的失控率从最初的百分之十几降到了1%以下核心靠的就是这三层护栏。3.3 Agent工程的常见事故与处理Agent工程踩坑是常态我把自己踩过和见过的几类高频事故列出来每个都给出应对方案。死循环Agent调完工具A发现结果不对又调工具BB返回还是不对又回头调A来回烧钱。应对方案设置最大调用次数比如默认5次达到阈值就转人工兜底逻辑每次工具调用都做结果摘要让模型在循环中能感知我已经试过什么。工具幻觉模型虚构了一个根本不存在工具返回的结果。这通常发生在工具说明不清晰或者返回值太复杂的时候。应对方案工具返回值做实体的schema校验字段不匹配直接判定调用失败而不是把原始输出塞回去。任务漂移本来要做A任务做着做着跑去处理B的边角问题。比如让Agent整理文档它突然开始给文档调格式。应对方案把任务分解结果展示给用户确认用户点击继续才执行下一步或者在每个步骤的开始把当前目标重新注入上下文。上下文爆炸Agent一步步把之前的输出全塞回对话里最后超出窗口限制。应对方案用摘要压缩历史每一步只保留上一步的关键输出摘要原始的完整输出存到外部存储按需加载。从我的实际感受来说Agent工程的问题大多不是模型不够聪明而是控制不够严密。把上面四个问题系统性解决掉你的Agent就已经超过市面上80%的Demo了。4. 多AI协作把单体智能拆成微服务4.1 为什么一个模型扛不住所有任务很多人一开始喜欢一模型走天下让一个大模型干所有事意图识别、对话生成、文档总结、代码分析全塞给它。结果往往是每个任务都不差但没有一个任务能做到极致。单模型扛全场的核心问题有三个第一不同任务对能力的要求差异极大代码生成要严谨、情感对话要温度、信息抽取要精确一个模型很难在多个维度同时做到最优第二任务一多提示词之间会互相干扰为了让模型兼顾所有场景提示词就得写得模棱两可第三大模型按token计费让最强的模型去处理识别一句话意图这种简单任务纯粹是浪费钱。我在做了几个实际项目之后越来越倾向多AI协作的架构本质上是把单体智能拆成微服务——每个AI只负责一件小事做得专、做得稳、做得便宜。4.2 工作流编排的四种基本模式多AI协作不能想到哪写到哪我总结下来编排就四种基本模式组合使用就能覆盖绝大多数场景顺序模式任务有明确的先后依赖前一个模型输出喂给下一个模型。最典型的例子是模型A做信息抽取模型B基于抽取结果写摘要。这个模式要注意前一步的错误不能向后传递每一步都要有校验节点。并行模式多个独立任务同时跑最后合并。比如分析一份合同让三个模型分别看条款风险价格合理性法律合规性最后集成为一个综合结论。并行能省时间但合并环节要小心不同模型的偏好冲突。路由模式先用一个轻量模型做意图识别再根据意图把请求分发给不同的专业模型。这是性价比最高的模式——简单问题走小模型复杂问题走大模型平均成本可以降一半以上。评审模式一个模型负责生成另一个模型负责评审不合格的退回修改。这个模式像极了团队里的Code Review。我在做文案生成时就用生成器评审器双模型生成器负责发散评审器按规范打分不达标的重新生成效果比单模型加精细提示词好得多。这四种模式看着简单但真正落地时你会发现最难的其实是定义每一步的输入输出格式。格式不统一模型A的输出模型B就读不懂整条流水线就卡住。我的习惯是所有模型间的通信统一走JSON结构并且每个字段给一个示例值宁可多写几行schema也不要让模型自由发挥。4.3 成本、延迟与质量的三角权衡谈到多AI协作就必须直面成本、延迟、质量这个三角。实话说不存在三项全优的方案你只能在特定阶段做取舍。如果你的场景是B端企业问答质量优先级最高那就别心疼成本用强模型做最终回答路由模型只做粗筛如果你是C端高频交互延迟一点就能劝退用户那就宁可接受质量略降也要用小模型快速响应如果你是内部效率工具成本和延迟都敏感那就用小模型初稿大模型抽查精修的混合策略用25%的大模型调用去保住80%的质量体感。我实际跑过一个文档处理流水线先用一个小模型做全文的章节切分和粗提取再让大模型只精修那些置信度低的段落。配合一个置信度判断器最终大模型调用量降了40%而整体输出质量没有明显下降。这里有个容易被忽视的细节多AI协作的延迟不是简单的链路求和而是最慢那个环节的延迟。所以性能瓶颈往往出现在大模型调用上优化手段就两个方向一是减少大模型的输入输出tokens比如先压缩上下文二是用并行模式让慢的环节和其他环节同时跑把等待时间藏起来。5. 质量保障给AI系统装上仪表盘和刹车5.1 传统测试思维在AI场景的失效点很多团队把这个项目当普通软件开发上来就写单元测试、搞自动化测试结果发现AI系统的行为根本没法用断言去锁死。传统测试讲究输入确定、输出可预期但大模型的本质是概率性的同一个Prompt你今天问和明天问输出就可能不一样。这不是模型的Bug而是它的属性。所以在做AI质量保障时我强烈建议接受三个现实你不能期望输出完全一致但可以要求输出在可接受范围内。你不能只在开发期测一次线上效果必须持续回流。你不能只看单次输出对不对还要看整条任务链路最终目标达没达成。如果团队非要用传统思路去卡精确匹配那这个AI项目大概率会死在测试阶段。5.2 评测集与回归机制的构建真正有效的AI测试核心是建立一套评测集回归机制。评测集就是一批有标注的输入输出对每个用例标注了什么是好答案。构建评测集我建议用三层Golden Cases黄金用例由业务专家手工标注的少量高质量样本比如50到100条覆盖高频场景和关键风险场景。这是后续一切测试的地基。对抗样本故意刁难模型的输入比如绕弯子提问、诱导模型编造信息、超长文本输入。对抗样本的作用是验证护栏有没有兜住。真实流量采样从线上日志里随机抽一批真实请求人工标注质量。真实流量会不断变化所以这个样本集要定期更新。有了评测集回归机制就好办了。每次改提示词、换模型、调参数都跑一遍评测集算出整体及格率再和上一次对比。及格率下降说明改动引入了回归。我再补充一个关键动作评测不只是人工打分要引入自动评测器。现在很多团队会让一个大模型当裁判给另一个模型输出按维度打分。但这个玩法有个坑大模型裁判也有偏好所以我习惯是自动评测筛掉明显差的人工只审边界模糊的两者各司其职。5.3 灰度、监控与反馈闭环线上质量监控这块很多团队是在事故发生后才发现模型抽风了。我的建议是AI系统必须有比传统系统更细的灰度策略和监控指标。灰度上别一把把所有流量切到新版本。可以先放1%的流量观察核心指标和错误案例确认没问题再逐步提高到5%、20%、100%。这个机制不复杂但要落地必须提前在代码里打好开关位也就是在做harness时就设计好。监控上除了传统的基础设施指标调用量、延迟、错误率AI系统还要额外看三件事用户反馈点赞点踩、对话结束后满意度打分、转人工率。转人工率是一个特别灵敏的质量信号模型一旦开始胡说用户就倾向转人工。兜底触发率harness里每一层护栏被触发的次数比如输入过滤拦截了多少次、输出校验不通过多少次。这个指标快速上涨往往意味着线上有新的攻击模式或业务变化。成本健康度每一单的平均token消耗、每千次对话的成本。模型一次大输出可能比一次正常的推理贵十倍成本异常往往是效率恶化的信号。最重要的一步是反馈闭环线上监控发现异常案例定期抽样加进评测集和对抗样本再驱动提示词或harness迭代。这个闭环一旦转起来AI系统的质量就是越跑越稳而不是越跑越随机。6. 从零到一的可执行路线图6.1 第一阶段跑通最小闭环如果你刚进入AI工程千万别一上来就搭复杂的Agent和多人协作系统。我的建议是先用两周到一个月集中精力跑通一个最小闭环。所谓最小闭环就是选定一个具体到不能再具体的场景比如根据工单标题自动生成回复草稿然后完成提示词初版、接一个数据源、做一个最简单的输出解析、人工评估结果。这个阶段的目的有两个。第一个是让你真实感受到大模型在你业务场景里的能力上限——它能做到80分还是只有30分这决定你后面的架构复杂度。第二个是让你把数据摸透——你的知识库格式是什么、用户问题长什么样、期望输出有没有明确标准。很多项目做到后面才发现问题不在模型而是数据所以这个阶段一定要把数据形态了解清楚。我在这个阶段的经验是不要用工程化的眼光去审视初版效果。初版只要证明了这条路可能走得通就算成功。如果一开始就要求完美你会在提示词打磨里浪费大量时间。6.2 第二阶段引入Agent框架当最小闭环证明了可行性下一步就是引入Agent框架。这个阶段的目标是把一个单轮问答扩展成能自主完成多步任务的系统。引入Agent不用从零写框架现在开源生态已经有不少成熟的Agent编排框架我的建议是先用一种框架快速搭起来跑通规划-工具-记忆的最小循环再根据你的业务场景做定制。这个阶段最容易踩的坑就是过早优化Agent还没跑稳就开始设计复杂的提示词模板引擎、多模型路由、分布式部署。我见过太多团队倒在还没学会走就想跑上。Agent工程恰恰相反先把一个场景跑穿再把方案复制到其他场景。6.3 第三阶段建设评测体系当Agent从demo走向准生产评测体系就是生死线。这个阶段要做的事基本就是我前面第五部分写的内容建立Golden Cases评测集、搭建自动评测器、设计灰度发布流程、部署线上监控仪表盘。所有这些动作目标是一致的——让你每一次改动都有数据依据让系统的行为越来越可预测。我对评测体系的定位可以类比成给AI系统装仪表盘和刹车。仪表盘让你随时知道当前系统在什么状态刹车让你在发现异常时能快速踩住。缺了仪表盘的AI系统跑得再快你也不知道它什么时候会掉下悬崖。6.4 我的一点个人体会最后说几句从零做到现在的大实话。AI工程给我的最大教训是不要迷信单个模型的智力要相信工程系统的约束。再聪明的模型没有可靠的输入过滤、输出校验、状态管理和评测反馈放在真实业务里也是定时炸弹。反过来一套约束严密的harness能让一个平庸的模型也输出稳定的结果。后者才是工程的价值所在。第二个体会是从零开始做AI工程前期的慢是为了后期的快。我见过太多团队想省掉评测集构建和harness设计的步骤直接上生产结果后面的每一次模型升级、每一个提示词微调都变成赌博。把护栏和仪表盘先装好后面所有的迭代都是在安全通道里进行速度反而更快。如果你现在正处于API调通了但不知道下一步干什么的阶段我的建议很简单找一个具体的业务场景把prompt写成可管理的代码把Agent的缰绳套上再给系统装好仪表盘。沿着这条路径走你会发现自己做的已经不是调模型的Demo而是一个真正能交付的AI工程产品。
很多人一看到AI工程从零开始这个题目都会本能地以为是从搭一个神经网络开始训大模型。其实我在一线做了这么久的AI项目落地最真实的感受正好相反——从零开始的AI工程第一步不是炼丹而是搞清楚你要解决的问题到底是什么形状。这年头大模型本身的智力已经够用卡住大多数团队的反而是那些看起来不起眼的工程问题提示词不稳定、Agent一跑就失控、多模型协作互相甩锅、效果评估只能靠肉眼。这篇文章我就把自己从零搭建AI工程体系的实际经历拆开讲包括提示词工程怎么做才不玄学、Agent怎么从一个玩具变成能交付的任务闭环、多AI协作怎么编排以及测试和监控怎么落地。内容偏实操适合正在做AI应用开发、想从调接口进阶到搭系统的开发者也适合技术负责人拿来当团队路线图参考。1. 从零开始的真实起点不是训练模型而是定义问题1.1 AI工程为什么不是调API很多刚入行的朋友会困惑我明明已经把大模型的API调通了能聊天能写摘要为什么一放到真实业务里就废掉这其实很正常因为你做的只是模型调用不是AI工程。我之前接手过一个小项目对方说想要一个懂产品的智能客服听起来很简单对不对写个Prompt扔给大模型就行。结果一上线就出事客户问你们和XX家比哪个好模型一本正经地编了个根本不存在的产品参数客户问什么时候发货模型完全不知道自己应该去查订单系统只顾着用话术安抚。这就是典型的调通API和做了AI工程之间的鸿沟——前者只是证明模型能说话后者要让模型在真实业务里按规矩办事、调得动系统、说错话能被拦住。从零开始做AI工程第一件事其实是把会说话变成会干活。这意味着你要在模型外面包一层东西把业务知识喂给它、把工具接口暴露给它、把输出格式限制死、把不该说的话挡回去。这一整套东西才是AI工程的主体也恰恰是从零开始最花时间的部分。1.2 三层结构模型层、编排层、应用层我习惯把AI工程拆成三层来看这也决定了一个项目从零开始时的资源分配思路。模型层这是最底下的一层负责理解与生成。可以是商用大模型API也可以是开源模型自己部署甚至可以是微调过的垂直模型。对绝大多数业务场景你不需要自己训练直接用现成模型就行。编排层这是AI工程的核心负责怎么把模型塞进业务流程。包括提示词的管理、上下文组装、工具调用的规划与执行、多步任务的拆解、以及模型输出之后的校验与修正。很多团队在这一层的代码量占比最高但也是最容易被忽视的。应用层这是用户真正能摸到的东西包括前端界面、交互逻辑、权限与计费、以及和现有业务系统的对接。比如客服机器人要接到工单系统、订单系统、知识库这个接的动作基本都是在应用层完成的。我的建议是从零开始做AI工程不要在模型层自嗨也不要在应用层过早堆功能把60%的精力放在编排层。因为模型能力是市场给的应用体验是产品经理该操心的唯独编排层的工程质量直接决定你的AI系统是偶尔聪明还是稳定可用。打个比方模型层是发动机应用层是车身编排层就是底盘、转向和刹车——发动机再强刹车失灵的车你也不敢开上路。2. 提示词工程把自然语言淬炼成稳定接口2.1 一套可复用的提示词骨架提示词工程看着最玄学但它其实是AI工程里最适合结构化的部分。我自己用过各种花哨的写法之后最终沉淀下来一套固定骨架每个项目套用再调整比每次自由发挥稳定得多。这套骨架一共五块角色定义明确让模型以什么身份工作。别只写你是一个客服要写你是XX品牌官方客服语气专业但不机械不知道的信息必须明说不知道绝对不允许编造。任务说明一句话讲清楚这轮要做什么。这里要注意区分任务和目标——回答用户问题是任务让用户满意并减少人工转接是目标提示词里写任务就够了目标由评估体系去衡量。上下文输入把需要的信息塞进来比如用户订单信息、知识库片段、对话历史。这块最考验工程能力因为上下文窗口有限怎么截断、怎么排序、保留哪些删除哪些直接决定效果。输出格式约束需要JSON就给JSON的schema示例需要表格就给表格示例。格式写死了下游解析才不会崩。边界与兜底明确什么不能做比如如果用户问价格回复请咨询销售顾问如果无法回答输出{unknown:true}。这套骨架我用了快两年最深的体会是提示词不是写出来的是测出来的。你别指望一次到位每次改动用户反馈差就需要抽几条case看模型输出找到规律再改。当你的提示词改到第十版还不稳定问题往往不在措辞而在上下文里缺信息或者在指令本身有歧义。2.2 输出约束与参数配合很多从零开始的人会忽略模型输出参数的重要性我建议每切换一个模型或场景就要重新过一遍这些参数。Temperature控制随机性。客服、代码生成这类任务建议调到0.2以下因为我们需要稳定答案头脑风暴、文案灵感类可以到0.8以上让模型发挥得更开放。Top_p和温度类似二选一配合即可。有些场景我更习惯固定top_p因为它控制的是候选词的累积概率直觉上更接近思维发散度。Max tokens别舍不得限制。一个人越自由越容易漫无边际模型也一样。把输出上限卡死逼着它学会精简也避免超时和费用失控。函数调用Function Calling这是把提示词工程推向接口化的关键能力。与其让模型从一段话里手动解析意图不如直接定义好函数列表让模型输出结构化的调用参数。我用这个方式做意图识别和工具调用准确率和可维护性比自由文本规则解析高出一个量级。如果一定要给个建议早期做原型时放开所有参数怎么爽怎么来一旦准备上线温度调低、格式写死、函数调用拉满把模型的创造力先按住。2.3 提示词的版本管理与回归提示词本质上是代码但很多团队仍然拿它当Word文档在维护。这个问题在AI工程里特别典型——模型是外部依赖你没法保证厂商升级后行为不变所以提示词的版本管理相当于对不可控依赖的补偿机制。我目前的实践是每个提示词模板都是一个独立的Git文件采用类似代码的PR流程——改动前先写一组测试用例说明当前输出应该是什么样改完之后跑一遍全部用例确认没有破坏其他场景。比如有一次我把客服Prompt里不知道信息必须明说改成了尽量引导用户提供信息结果是销售线索获取变好了但用户投诉率也涨了正是靠回归测试在灰度期就发现了异常。再补充一个容易被忽略的点提示词里的上下文变量名要规范。别用根据上面的信息这种模糊指代给每个上下文块加明确的标签比如order_info、knowledge_base。这样模型其实更容易区分信息来源而且对你后续定位问题也方便。这算是让提示词工程代码化的第一步。3. Agent工程化从会聊天到能干活的跨越3.1 Agent的三大子系统如果说提示词工程解决的是单次对话的质量Agent工程要解决的就是多步任务的闭环。这几年AI Agent被炒得很热但我看下来真正可用的Agent其实就三大子系统规划子系统Planner拿到一个任务先拆解成步骤。现在的主流做法是大模型直接输出一个计划必要时配合任务分解的Prompt模板。也可以用目标-子目标的树形结构把复杂目标拆成多个子任务再逐个执行。工具子系统Tool ExecutorAgent必须能调用外部工具否则它就是个只会说的嘴炮。每个工具本质上是给模型提供的一个函数声明包含名称、参数、返回值、以及什么时候该用的说明。工具不是越多越好每多一个工具模型选错工具的几率就高一分。记忆子系统Memory短期记忆是对话上下文长期记忆是向量数据库或结构化存储。做Agent最容易忽略的是过期记忆的问题——三天前的用户需求今天还拿来当依据结果就是越跑越偏。所以记忆系统一定要带时间戳和衰减机制。我的经验是规划子系统决定Agent的上限工具子系统决定Agent的下限记忆子系统决定Agent能不能长期稳定干活。三者缺一个Agent就还是一堆Prompt的拼凑。3.2 用AI编程工具搭建可控harness的完整案例这里重点说一下Harness Engineering——这个词在AI工程里指的是给Agent套上缰绳也就是一套约束、监控和兜底机制让Agent不能乱跑。我最近在用CodeBuddy这类AI编程工具辅助实现Agent harness流程还挺有代表性列出来供参考。首先是设计阶段。我们先用CodeBuddy对话生成一版Agent框架骨架把规划、工具、记忆三个模块的接口先定义清楚。这一步AI编程工具很强它能根据你描述的架构风格快速生成工整的基础代码。但注意别让它一把梭生成整个系统而是让它按模块渐进生成每生成一个模块就人工review一次。AI写的代码尤其是涉及异步调用和错误处理的逻辑第一版大概率有边界问题。然后是harness的落地。我们实际要做的是三层护栏输入过滤在用户输入进入Agent之前先做一轮安全与合规检查以及格式校验。输出校验模型生成的内容先用规则引擎和另一个小模型做双重校验比如检查是否包含敏感内容、JSON是否合法、字段是否完整。行为兜底给Agent设一个最大工具调用次数和超时阈值一旦循环超过限制就强制终止避免死循环烧钱。这三层护栏用CodeBuddy实现时我最大的体会是AI编程工具擅长从对话到代码的翻译但它不理解你的业务兜底逻辑。比如用户如果问竞品对比我们应该返回什么这类业务规则还是需要我们自己沉淀、写进harness的配置中心里。AI编程工具能帮你搭的是骨架里的管道可管道里流的水—业务规则—必须自己定义清楚。最后是测试。我们给harness写了一套注射测试用例故意让Agent去调用不存在的工具、故意传超大上下文、故意让工具返回异常验证兜底逻辑是否生效。这些用例本身也可以用AI编程工具批量生成但每条用例的预期行为必须人工确认。现在这套harness跑了两个多月Agent的失控率从最初的百分之十几降到了1%以下核心靠的就是这三层护栏。3.3 Agent工程的常见事故与处理Agent工程踩坑是常态我把自己踩过和见过的几类高频事故列出来每个都给出应对方案。死循环Agent调完工具A发现结果不对又调工具BB返回还是不对又回头调A来回烧钱。应对方案设置最大调用次数比如默认5次达到阈值就转人工兜底逻辑每次工具调用都做结果摘要让模型在循环中能感知我已经试过什么。工具幻觉模型虚构了一个根本不存在工具返回的结果。这通常发生在工具说明不清晰或者返回值太复杂的时候。应对方案工具返回值做实体的schema校验字段不匹配直接判定调用失败而不是把原始输出塞回去。任务漂移本来要做A任务做着做着跑去处理B的边角问题。比如让Agent整理文档它突然开始给文档调格式。应对方案把任务分解结果展示给用户确认用户点击继续才执行下一步或者在每个步骤的开始把当前目标重新注入上下文。上下文爆炸Agent一步步把之前的输出全塞回对话里最后超出窗口限制。应对方案用摘要压缩历史每一步只保留上一步的关键输出摘要原始的完整输出存到外部存储按需加载。从我的实际感受来说Agent工程的问题大多不是模型不够聪明而是控制不够严密。把上面四个问题系统性解决掉你的Agent就已经超过市面上80%的Demo了。4. 多AI协作把单体智能拆成微服务4.1 为什么一个模型扛不住所有任务很多人一开始喜欢一模型走天下让一个大模型干所有事意图识别、对话生成、文档总结、代码分析全塞给它。结果往往是每个任务都不差但没有一个任务能做到极致。单模型扛全场的核心问题有三个第一不同任务对能力的要求差异极大代码生成要严谨、情感对话要温度、信息抽取要精确一个模型很难在多个维度同时做到最优第二任务一多提示词之间会互相干扰为了让模型兼顾所有场景提示词就得写得模棱两可第三大模型按token计费让最强的模型去处理识别一句话意图这种简单任务纯粹是浪费钱。我在做了几个实际项目之后越来越倾向多AI协作的架构本质上是把单体智能拆成微服务——每个AI只负责一件小事做得专、做得稳、做得便宜。4.2 工作流编排的四种基本模式多AI协作不能想到哪写到哪我总结下来编排就四种基本模式组合使用就能覆盖绝大多数场景顺序模式任务有明确的先后依赖前一个模型输出喂给下一个模型。最典型的例子是模型A做信息抽取模型B基于抽取结果写摘要。这个模式要注意前一步的错误不能向后传递每一步都要有校验节点。并行模式多个独立任务同时跑最后合并。比如分析一份合同让三个模型分别看条款风险价格合理性法律合规性最后集成为一个综合结论。并行能省时间但合并环节要小心不同模型的偏好冲突。路由模式先用一个轻量模型做意图识别再根据意图把请求分发给不同的专业模型。这是性价比最高的模式——简单问题走小模型复杂问题走大模型平均成本可以降一半以上。评审模式一个模型负责生成另一个模型负责评审不合格的退回修改。这个模式像极了团队里的Code Review。我在做文案生成时就用生成器评审器双模型生成器负责发散评审器按规范打分不达标的重新生成效果比单模型加精细提示词好得多。这四种模式看着简单但真正落地时你会发现最难的其实是定义每一步的输入输出格式。格式不统一模型A的输出模型B就读不懂整条流水线就卡住。我的习惯是所有模型间的通信统一走JSON结构并且每个字段给一个示例值宁可多写几行schema也不要让模型自由发挥。4.3 成本、延迟与质量的三角权衡谈到多AI协作就必须直面成本、延迟、质量这个三角。实话说不存在三项全优的方案你只能在特定阶段做取舍。如果你的场景是B端企业问答质量优先级最高那就别心疼成本用强模型做最终回答路由模型只做粗筛如果你是C端高频交互延迟一点就能劝退用户那就宁可接受质量略降也要用小模型快速响应如果你是内部效率工具成本和延迟都敏感那就用小模型初稿大模型抽查精修的混合策略用25%的大模型调用去保住80%的质量体感。我实际跑过一个文档处理流水线先用一个小模型做全文的章节切分和粗提取再让大模型只精修那些置信度低的段落。配合一个置信度判断器最终大模型调用量降了40%而整体输出质量没有明显下降。这里有个容易被忽视的细节多AI协作的延迟不是简单的链路求和而是最慢那个环节的延迟。所以性能瓶颈往往出现在大模型调用上优化手段就两个方向一是减少大模型的输入输出tokens比如先压缩上下文二是用并行模式让慢的环节和其他环节同时跑把等待时间藏起来。5. 质量保障给AI系统装上仪表盘和刹车5.1 传统测试思维在AI场景的失效点很多团队把这个项目当普通软件开发上来就写单元测试、搞自动化测试结果发现AI系统的行为根本没法用断言去锁死。传统测试讲究输入确定、输出可预期但大模型的本质是概率性的同一个Prompt你今天问和明天问输出就可能不一样。这不是模型的Bug而是它的属性。所以在做AI质量保障时我强烈建议接受三个现实你不能期望输出完全一致但可以要求输出在可接受范围内。你不能只在开发期测一次线上效果必须持续回流。你不能只看单次输出对不对还要看整条任务链路最终目标达没达成。如果团队非要用传统思路去卡精确匹配那这个AI项目大概率会死在测试阶段。5.2 评测集与回归机制的构建真正有效的AI测试核心是建立一套评测集回归机制。评测集就是一批有标注的输入输出对每个用例标注了什么是好答案。构建评测集我建议用三层Golden Cases黄金用例由业务专家手工标注的少量高质量样本比如50到100条覆盖高频场景和关键风险场景。这是后续一切测试的地基。对抗样本故意刁难模型的输入比如绕弯子提问、诱导模型编造信息、超长文本输入。对抗样本的作用是验证护栏有没有兜住。真实流量采样从线上日志里随机抽一批真实请求人工标注质量。真实流量会不断变化所以这个样本集要定期更新。有了评测集回归机制就好办了。每次改提示词、换模型、调参数都跑一遍评测集算出整体及格率再和上一次对比。及格率下降说明改动引入了回归。我再补充一个关键动作评测不只是人工打分要引入自动评测器。现在很多团队会让一个大模型当裁判给另一个模型输出按维度打分。但这个玩法有个坑大模型裁判也有偏好所以我习惯是自动评测筛掉明显差的人工只审边界模糊的两者各司其职。5.3 灰度、监控与反馈闭环线上质量监控这块很多团队是在事故发生后才发现模型抽风了。我的建议是AI系统必须有比传统系统更细的灰度策略和监控指标。灰度上别一把把所有流量切到新版本。可以先放1%的流量观察核心指标和错误案例确认没问题再逐步提高到5%、20%、100%。这个机制不复杂但要落地必须提前在代码里打好开关位也就是在做harness时就设计好。监控上除了传统的基础设施指标调用量、延迟、错误率AI系统还要额外看三件事用户反馈点赞点踩、对话结束后满意度打分、转人工率。转人工率是一个特别灵敏的质量信号模型一旦开始胡说用户就倾向转人工。兜底触发率harness里每一层护栏被触发的次数比如输入过滤拦截了多少次、输出校验不通过多少次。这个指标快速上涨往往意味着线上有新的攻击模式或业务变化。成本健康度每一单的平均token消耗、每千次对话的成本。模型一次大输出可能比一次正常的推理贵十倍成本异常往往是效率恶化的信号。最重要的一步是反馈闭环线上监控发现异常案例定期抽样加进评测集和对抗样本再驱动提示词或harness迭代。这个闭环一旦转起来AI系统的质量就是越跑越稳而不是越跑越随机。6. 从零到一的可执行路线图6.1 第一阶段跑通最小闭环如果你刚进入AI工程千万别一上来就搭复杂的Agent和多人协作系统。我的建议是先用两周到一个月集中精力跑通一个最小闭环。所谓最小闭环就是选定一个具体到不能再具体的场景比如根据工单标题自动生成回复草稿然后完成提示词初版、接一个数据源、做一个最简单的输出解析、人工评估结果。这个阶段的目的有两个。第一个是让你真实感受到大模型在你业务场景里的能力上限——它能做到80分还是只有30分这决定你后面的架构复杂度。第二个是让你把数据摸透——你的知识库格式是什么、用户问题长什么样、期望输出有没有明确标准。很多项目做到后面才发现问题不在模型而是数据所以这个阶段一定要把数据形态了解清楚。我在这个阶段的经验是不要用工程化的眼光去审视初版效果。初版只要证明了这条路可能走得通就算成功。如果一开始就要求完美你会在提示词打磨里浪费大量时间。6.2 第二阶段引入Agent框架当最小闭环证明了可行性下一步就是引入Agent框架。这个阶段的目标是把一个单轮问答扩展成能自主完成多步任务的系统。引入Agent不用从零写框架现在开源生态已经有不少成熟的Agent编排框架我的建议是先用一种框架快速搭起来跑通规划-工具-记忆的最小循环再根据你的业务场景做定制。这个阶段最容易踩的坑就是过早优化Agent还没跑稳就开始设计复杂的提示词模板引擎、多模型路由、分布式部署。我见过太多团队倒在还没学会走就想跑上。Agent工程恰恰相反先把一个场景跑穿再把方案复制到其他场景。6.3 第三阶段建设评测体系当Agent从demo走向准生产评测体系就是生死线。这个阶段要做的事基本就是我前面第五部分写的内容建立Golden Cases评测集、搭建自动评测器、设计灰度发布流程、部署线上监控仪表盘。所有这些动作目标是一致的——让你每一次改动都有数据依据让系统的行为越来越可预测。我对评测体系的定位可以类比成给AI系统装仪表盘和刹车。仪表盘让你随时知道当前系统在什么状态刹车让你在发现异常时能快速踩住。缺了仪表盘的AI系统跑得再快你也不知道它什么时候会掉下悬崖。6.4 我的一点个人体会最后说几句从零做到现在的大实话。AI工程给我的最大教训是不要迷信单个模型的智力要相信工程系统的约束。再聪明的模型没有可靠的输入过滤、输出校验、状态管理和评测反馈放在真实业务里也是定时炸弹。反过来一套约束严密的harness能让一个平庸的模型也输出稳定的结果。后者才是工程的价值所在。第二个体会是从零开始做AI工程前期的慢是为了后期的快。我见过太多团队想省掉评测集构建和harness设计的步骤直接上生产结果后面的每一次模型升级、每一个提示词微调都变成赌博。把护栏和仪表盘先装好后面所有的迭代都是在安全通道里进行速度反而更快。如果你现在正处于API调通了但不知道下一步干什么的阶段我的建议很简单找一个具体的业务场景把prompt写成可管理的代码把Agent的缰绳套上再给系统装好仪表盘。沿着这条路径走你会发现自己做的已经不是调模型的Demo而是一个真正能交付的AI工程产品。
