大概两年前我第一次把大模型接进业务系统的时候觉得自己站在了浪潮之巅。Demo跑通的那个晚上聊天窗口里的回复一句接一句往外蹦我心想AI工程不过如此不就是调接口、拼提示词嘛。后来项目真正上了生产环境三个月里模型输出漂移、Token账单失控、Agent循环死锁、评测集没有守住回归——每一件事都在反复教我重新认识AI工程这四个字。今天这篇内容就是我从零起步做AI工程化改造的全过程记录。它不聊已经烂大街的什么是大模型而是聚焦真正决定项目生死的那些事怎么把模型能力变成可控的产品行为、Agent架构从单次调用到自主任务有哪些绕不开的坎、为什么评测集比提示词更重要、以及上线之后靠什么维持稳定。适合两类人看刚接触大模型、想把AI能力落地到实际产品里的开发者以及已经在用API做简单调用、但总感觉方案差点意思的工程师。我会把选型逻辑、Prompt设计、数据准备、评测回归、部署监控里真正花了时间的环节讲清楚也坦白交代哪些地方我栽过跟头。1. 先搞清楚AI工程师和会用AI的人分水岭在哪1.1 从一次看似成功的Demo说起我最初的项目很简单做一个基于大模型的内部知识问答工具把公司文档喂给模型员工提问模型回答。Demo阶段一切顺利模型对测试文档的理解很到位领导看了很满意。但到了真正接入内部系统那天问题像约好了一样涌出来——大文档超出上下文窗口直接报错同一个问题早上和下午的回答风格完全不同有人把敏感合同传进去之后对话记录里到处是它的影子。那一刻我意识到所谓从零开始做AI工程难点根本不在模型本身而在于模型之外的那一整圈工程系统。模型是一个高度不稳定的计算核心工程化要做的事情就是用稳定的框架去约束它、评估它、兜住它。1.2 工程化的五个基本盘我后来把AI工程需要打的地基归纳成五块这五块是我后来所有工作的骨架能力边界评估模型能做什么、不能做什么、在什么输入下会崩溃。不是看评测榜单而是用你自己的数据、你自己的任务去测。上下文与数据工程怎么把知识组织成模型能高效利用的形式。检索、切片、摘要、动态拼装这一层直接决定回答质量的上限。可控性设计通过提示词结构、参数设置、结构化输出约束让模型的输出从散文变成接口可以消费的数据。评测与回归体系没有评测集你永远说不清一个改动是变好还是变坏。这是AI项目和普通软件项目最大的差异。成本与运维体系Token消耗、延迟、并发、降级策略。模型调用是要付钱的而且比普通API贵得多花出去的钱必须能追踪、能优化。很多教程把注意力全放在第一块和第三块上但实际项目里后面三块才是大量消耗时间的黑洞。1.3 环境与依赖管理第一个容易翻车的地方说到落地第一个实操层面的问题是环境。很多AI项目一开始就在Jupyter Notebook里跑跑通了再说。但Notebook跑通和代码库可维护之间隔着整整一层工程规范。我当时定的规矩是所有AI相关代码必须走标准Python项目结构依赖用pipenv或poetry锁定版本模型API的密钥统一走环境变量或密钥管理服务绝不允许硬编码在代码里。这个决定看似平凡却在后来救了我好几次——比如有一次底层SDK升级后默认参数变了如果没有锁版本几十个服务可能同时出问题。提示如果你要从零开始先把src/目录、tests/目录、.env.example、依赖锁定文件这些基础设施搭好再开始写第一行调用模型的代码。AI项目迭代极快没有版本管理的代码库两周后就是一团你不敢碰的乱麻。2. 提示词工程把不可控的模型变成可控的接口2.1 提示词工程正在进化为Harness Engineering聊到控制模型绕不开提示词。Anthropic在2025年提出过一个概念叫harness engineering——中文圈子里有人翻译成驾驭工程。它说的是一件事提示词只是整个控制框架的一部分真正决定模型表现的是你围绕它搭建的完整系统输入的组织方式、输出的校验逻辑、上下文的管理策略、以及模型在不满足条件时的处理路径。我自己的经验也是这样。早期我迷信万能提示词觉得只要把Prompt写得足够精妙模型就无所不能。后来发现把同样的任务拆成系统提示词 上下文数据 输出约束 后置校验四层来设计稳定性远高于把一切都塞进一段玄学Prompt里。下面是我沉淀出的一套通用提示词结构直接能抄角色与目标你是谁你要完成什么输出给谁用 任务规则明确的步骤、约束、禁止事项 输入数据结构化传递不要粘贴大段无格式文本 输出格式JSON Schema、Markdown结构或字段列表 示例1-3个高质量few-shot示例重点展示边界情况这套结构的关键在于把规则和数据分开。规则是稳定不变的数据是每次请求变化的部分。分开之后你才能对规则做版本管理对数据做清洗变换两者互不污染。2.2 参数旋钮到底在控什么除了提示词模型API还有几个参数很多新手直接抄默认值结果出了问题都不知道往哪儿查参数控制什么我的常用配置典型坑temperature输出的随机性和多样性0.2事实问答/ 0.7创意生成事实类任务用高温会频繁出现幻觉top_p采样的候选集范围0.9 配合temperature使用和temperature同时调高输出接近失控max_tokens单次生成的最大长度按任务设置绝不设太高设太高时模型会输出一堆废话账单翻倍response_format是否强制结构化输出需要机器解析时必选JSON不强制时模型经常给你来一段Markdown包裹的JSONseed部分平台支持固定随机种子测试环境固定生产不依赖依赖seed保证完全一致是不现实的只是减少抖动我在实践中最重要的认知是写提示词之前先把参数想清楚。一个知识问答任务temperature设成0.2会让答案明显更忠于原文而一个头脑风暴类功能temperature低于0.5会显得非常无趣。参数是产品体验的一部分不是调试用的后置选项。2.3 结构化输出让模型和代码握手AI工程和普通API开发最大的区别在于模型返回的是自然语言而代码需要的是字段。你当然可以用正则表达式去扒输出里的JSON但这是最脆弱的方案——模型稍微加个注释、换行符号正则就断了。我现在的标准做法是在提示词里给出目标JSON Schema并强制开启API的结构化输出能力如果平台支持的话再用一层轻量校验兜底。比如我需要模型抽取一个工单的关键信息{ type: object, properties: { priority: {type: string, enum: [low, medium, high]}, category: {type: string}, summary: {type: string}, deadline: {type: string, format: date} }, required: [priority, category, summary] }Schema定义的枚举值本身就会约束模型的输出空间比在提示词里写你只能输出这几个值有效得多。配合后置的JSON解析和字段级校验模型输出才能真正被当作可靠的接口数据来用。2.4 Prompt要像代码一样做版本管理和评测这是我踩过最大的坑之一改了一段提示词觉得这么写更清楚上线之后业务方反馈回答质量下降但我完全说不清是哪一次改动导致的因为Prompt根本没有版本管理。后来我把所有提示词模板收进代码库用Git管理每次修改都走Pull Request并且强制关联一个评测结果。规则只有一条没有经过评测集验证的Prompt改动不允许合并。这个习惯彻底改变了项目的可控性。提示词和代码一样是会被不断迭代的资产你不给它上版本管理就等于开着没有仪表盘的飞机。3. 从单次调用到自主Agent架构跃迁的关键一步3.1 为什么单次调用撑不起真实需求我的知识问答工具有个天然缺陷当用户问最近一个季度各事业部的人效数据对比时文档里根本没有现成答案。模型不知道应该先去查数据库、再调报表接口、最后汇总计算。单次调用的本质是一次性作答它没有行动能力。这时候就需要Agent——让模型在思考-行动-观察的循环里自主完成任务。这个跃迁不是功能增强而是架构级别的变化你需要引入工具系统、循环控制、状态管理以及最重要的终止条件。3.2 Agent循环的骨架实现我自己实现的第一个Agent其实非常简单核心就是下面这个循环def run_agent(task, tools, max_steps10): messages [{role: system, content: SYSTEM_PROMPT}, {role: user, content: task}] for step in range(max_steps): response llm.chat(messages, toolstool_schemas) if response.finish_reason stop: return extract_answer(response.content) # 模型请求调用工具 for tool_call in response.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) messages.append({role: assistant, content: response.content}) raise AgentTimeoutError(超过最大步数)这里最容易被忽视的地方是max_steps。现实中模型会在复杂任务里无限循环下去尤其是在调用工具出错之后它会反复尝试同样的调用。我见过一个Agent在一个错误参数上重试了17次直到把上下文窗口塞满。每一个Agent都必须有步数上限而且要有超时兜底这两个参数是生产环境的安全底线。3.3 工具设计决定Agent的能力边界Agent能干多少活完全取决于你给它提供了什么工具。工具设计有几条我总结的经验每个工具的定义要让模型容易理解描述里写清楚功能、参数、返回值格式、典型用法。工具的输入要做严格校验模型传参数经常不合规则工具侧必须做防御性处理。错误信息要足够可读模型会根据错误信息调整策略你返回Error: 500它就真的傻眼你返回参数due_date格式应为YYYY-MM-DD当前收到2025/3/1它下一轮大概率能自己改对。工具数量控制在合理范围一次性给模型50个工具它会频繁选错。按任务域分组成子Agent比把所有工具堆在一个Agent里靠谱得多。业界那股多Agent协作的风潮本质上就是人们发现把工具按职责分组、交给不同的Agent去调用比一个大杂烩Agent更可控。DeepSeek也公开过智能体训练的新方法核心方向之一就是让模型学会在复杂工具轨迹上做决策——但那是训练阶段的事情对应用工程师来说先把工具边界设计好比追求模型智能更重要。3.4 什么时候不应该用Agent说了这么多我最想强调的反而是一句泼冷水的话绝大多数需求根本不需要Agent。我在社区里看到太多团队明明只是一个根据用户输入查知识库并返回答案的需求非要上个ReAct循环再编排三个子Agent结果延迟从1秒涨到8秒Token消耗翻了5倍回答稳定性反而下降。判断标准其实很简单如果你的任务可以在一次调用内完成就绝对不要拆成多步循环。Agent的价值在于处理路径未知、需要动态规划的问题如果路径是固定的用工作流编排workflow硬编码步骤就行确定性高、成本低、好调试。4. 数据、评测与回归AI工程里最容易被忽视的三大件4.1 先有评测集再谈优化很多AI项目的失败路径是高度相似的功能开发完-凭感觉调Prompt-感觉变好了-上线-效果波动-不知道原因。问题根源在于没有评测集。我做的第一件事是把过去三个月里真实用户的问题收集起来人工标注出标准答案整理成一份50条左右的黄金评测集。数量不大但覆盖了各种边界超长问题、多轮歧义、专业术语、无答案场景。之后每一次Prompt改动、模型版本升级、知识库调整都先在评测集上跑一遍。提示评测集里的标准答案不需要是唯一答案但必须有明确的评分标准。我当时用了1-5分的打分制5分完整命中且有额外价值3分核心信息正确但细节缺失1分关键事实错误。评分标准比评分本身更重要否则多个评测员之间没法对齐。4.2 指标不只是准确率评测集打分是质量维度但AI项目上线之后光有质量远远不够。我建议至少同时跟踪四类指标指标类别具体指标为什么重要质量指标答案准确率、相关度评分、幻觉率直接反映用户体验性能指标首Token延迟、完整响应时长、并发上限决定服务能不能扛住业务流量成本指标单次请求Token数、每日消耗金额、缓存命中率决定项目能不能长期Run稳定性指标输出格式合法率、超时率、错误率决定系统可不可靠一个有意思的发现质量指标和成本指标经常打架。为了让答案更准确我一度把检索上下文从3段加到8段准确率确实涨了5个点但Token消耗涨了80%。后来我把上下文中与问题不相关的段落过滤掉用Embedding相似度做裁剪质量几乎不变成本回落了60%。这件事说明任何优化都必须同时看四类指标单看任何一类都会做出偏颇的决策。4.3 回归测试让Prompt像代码一样可管理我前面提到Prompt要上版本管理这里补充配套的另一半自动化回归。我搭了一套简单的CI流程每当Pull Request改动提示词、知识库切片策略、或者检索参数CI会自动跑一遍黄金评测集生成一份对比报告列出每个用例的评分变化。这个机制的威力在于它能挡住那些主观上感觉更好了客观上让5个用例崩掉的改动。实测中最有价值的是回归测试能直观暴露修复A问题导致B问题恶化的耦合。有一次我为了提升对专业术语的理解在提示词里加强了你是领域专家的角色设定结果评测集里几个幽默反问类的用例全部翻车——模型变得过于严肃丢失了对话感。这种副作用凭感觉根本发现不了只有回归报告能第一时间抓出来。4.4 日志与追踪AI排错的唯一线索AI系统的排错难度远高于传统系统因为同样的输入可能产生不同的输出你很难复现Bug。我前几次线上问题排查几乎都是瞎猜直到把日志体系建起来。具体做法不复杂每次请求记录一个唯一的Trace ID把用户的原始输入、检索到的上下文片段、最终的Prompt组装内容、模型的完整输出、各环节的耗时和Token消耗全部串起来存进日志。这样线上任何一次异常回复都能顺着Trace ID回溯看到底是检索没召回、Prompt被截断还是模型本身抽风。我印象最深的一次排错用户反馈某个行业术语的回答总是偏题。顺着Trace发现检索阶段召回了几个相似度高但主题完全不同的文档片段污染了上下文——问题出在Embedding模型的语义区分度上跟提示词和模型输出一点关系都没有。没有Trace日志这个Case我可能永远定位不到。5. 模型部署与上线从Notebook到生产环境的最后一公里5.1 选型托管API还是自部署这是每个团队起步都会纠结的问题。我给一个实操视角的对比维度托管API如各平台大模型服务自部署开源模型起步成本低按量付费零运维高需要GPU资源和部署团队数据安全取决于服务商协议敏感数据有顾虑数据完全在内部合规可控模型能力通常最强迭代不用自己管受限于开源模型的版本和能力延迟与容量受公共服务质量影响可自主扩容但运维复杂度高总成本曲线随调用量线性增长固定成本高规模越大越划算我的建议是分阶段走起步期用托管API验证产品逻辑等业务量稳定、对延迟和成本有了真实数据之后再评估把高频路径迁移到自部署模型。不要一开始就背上GPU集群的运维包袱也不要在业务规模大了之后还无脑用API烧钱。5.2 缓存与成本控制别让账单调消费失控AI应用的成本模型和传统API完全不同——成本与输入长度强相关而用户感知的质量又与输入准备的精细度强相关。控制成本的手段里缓存是见效最快的一个。我实现了两级缓存第一级是语义缓存把用户问题的Embedding向量存起来新问题进来先算相似度超过阈值就直接返回缓存的答案不再调用大模型。第二级是组件缓存把高频检索命中的文档切片、常用Prompt模板的渲染结果缓存住省的是Prefill阶段的Token。这两级缓存上线之后整体成本降了四成左右体验几乎无损。另一个容易被忽略的点是Token用量上报。每个请求用了多少输入Token、多少输出Token必须按业务线、按用户维度记下来。没有这个数据你连哪个功能在烧钱都说不清。我见过一个团队上线AI功能半个月后收到账单才知道有一个测试页面被爬虫反复调用烧掉了预算的一大半。5.3 可靠性与降级策略大模型服务再稳也做不到五个九。API超时、限流、模型服务方维护都是现实里会遇到的事。我在设计系统时把降级策略作为必选项超时兜底大模型调用设置合理的超时时间超时后返回降级结果不要让用户无限转圈。模型回退链主模型失败后依次尝试备用模型不同厂商的模型都配上避免单点依赖。规则兜底对核心业务场景准备一套不依赖模型的规则逻辑。比如工单分类在模型超时时按关键词规则分到待人工处理总比直接报错强。熔断机制连续失败达到阈值后一段时间内不再调用模型直接走降级路径给模型服务喘息时间。这些策略听起来像传统后端开发的常识但我在很多AI项目里看到团队把这些全忘了——仿佛模型是魔法不需要容错。模型恰恰是系统里最不稳定的组件必须用最强的工程手段去兜底。5.4 监控告警盯住延迟、Token与异常率上线之后我建了一块监控看板核心指标就是前面说的四类里最要紧的几项请求量、首Token延迟、完整响应时长、Token消耗、异常率、缓存命中率。全部按分钟粒度聚合异常率超过阈值就触发告警。这里有个AI项目特有的监控点输出格式合法率。模型随时可能在结构化输出里掺入意外内容导致下游解析失败。我在解析层做了兜底——解析失败时自动重试一次降temperature的请求同时把这条记录标记为高风险方便后续排查。上线第一个月这个指标帮我抓到了三次模型行为漂移一次是平台更新了默认参数一次是提示词里的示例被误删一次是模型的JSON输出开始带多余注释。6. 从零到一的过程中我踩过的那些坑6.1 Token消耗被严重低估第一次上线时我估算的成本模型只算了模型生成答案的部分完全没算输入侧的开销。实际运行后发现知识问答场景里每生成1个字的回答往往要消耗50到100个Token的输入上下文如果检索策略召回太宽输入Token甚至能占单次请求的九成。后来我引入两个习惯才把账算明白所有场景的Token消耗必须拆成输入和输出分开统计而且每次调整检索策略都要用真实请求日志复盘Token分布。6.2 模型的不确定性在测试里被忽略传统开发里同一个测试用例跑一百次结果都一样。AI项目不是这样。我有一次优化检索效果在评测集上跑了一遍平均分从3.9涨到4.2满心欢喜准备上线。旁边同事问了一句你跑了几轮我愣住了。补跑五轮之后发现每次的分数都在4.0到4.3之间波动所谓优化可能只是运气。从那以后我在评测时所有用例至少跑三轮最终结论看均值而不是单次结果涉及A/B对比时必须在同一批模型版本和参数下进行否则对比没有意义。模型的不确定性是整个工程里最反直觉、也最容易让工程师栽跟头的地方。6.3 过度设计Agent的代价前面我说过不是所有场景都需要Agent这里补充一个反面案例。我做工单处理功能时一开始设计了三个Agent协作一个分析工单、一个查询资料、一个生成回复。架构听起来很漂亮但实际运行效果惨不忍睹三个Agent之间的上下文传递经常丢失关键信息每次任务要调用十几次模型延迟飙到十几秒成本高到业务方直接问这功能能不能关了。后来我痛定思痛把三个Agent合并成一个工单处理工作流一个Agent负责分析和查询回复模板用规则生成。同样任务的延迟降到了原来的五分之一成本降了七成效果反而更稳。架构的复杂度和效果不是正相关的AI项目里尤其如此。6.4 一些自认为有用的习惯最后分享几个踩过坑之后沉淀下来的工作习惯每次改动只动一个变量。改Prompt时不动检索参数调temperature时不动提示词。变量混在一起出了问题根本分不清是谁的锅。好的错误信息胜过千言万语。让模型返回缺少参数due_date而不是调用失败Agent的自我纠错能力会大幅提升。人工智能项目的里程碑要以可评测的稳定表现来定义而不是功能跑通了。功能跑通只是起点能在评测集上稳定达到某个分数才是真正能交付的时刻。定期和模型服务方的更新日志保持同步。模型版本升级、参数默认值调整、API行为变更都会在悄无声息间改变你系统的表现。回看从零到一这段路最大的体会是AI工程不是某一招鲜的技术诀窍而是一个把不确定性逐步约束成可预期的过程。提示词、Agent、评测、监控每个环节都在做同一件事——给模型这头猛兽套上缰绳。缰绳套得好不好比猛兽本身厉不厉害更决定你能跑多远。