AI工程落地指南：Prompt工程、Agent与模型部署实践

干AI工程实践这几年，我最大的感受是：从零开始搭一个能用的AI项目，难点根本不在模型，而在Prompt工程、AI Agent、模型部署这一连串工程环节。很多人拿到一个大模型API就直接写业务代码，结果demo能跑、上线就崩，一问原因，往往是输入输出没约束、上下文管不住、部署环境没有压测。这篇文章我想把从零开始做AI工程的完整路径拆开讲，适合刚接触AI工程的新手，也适合被项目折腾到怀疑人生的产品同学。我会把思路、参数、配置和踩过的坑都放进来，争取你看完能照着这一套思路去落地自己的AI应用。

1. 从零开始：AI工程的整体蓝图与设计思路

1.1 先拆需求：你不是在训练模型，而是在做工程

很多新手被“AI”这个词吓住，一上来就研究模型架构、损失函数，想着是不是要微调一个专属模型。但真实项目里，模型已经高度商品化，你需要解决的是怎么把模型能力稳定地接进业务流程。我早期做第一个AI工程时犯过很典型的错误：需求是“做一个智能客服”，我直接去微调模型，结果数据不够、效果玄学、上线还慢。后来我把需求拆成“FAQ检索+单轮问答+多轮对话”三个子问题，分别用RAG、Prompt工程和会话管理解决，事情立刻简单了。

拆需求的本质，是明确三个问题。第一，输入输出是什么：用户传进来的是文本还是表单，系统吐出去的是回答、结构化JSON，还是一个具体的操作指令。第二，评价标准是什么：用正确率、用户满意度、还是端到端延迟来衡量，没有这个标准，你永远说不清项目有没有成功。第三，约束是什么：数据能不能出域、并发量多大、预算多少、可用性要求几个9。把这些写清楚，AI工程的边界就出来了。

另一个常见误区，是恨不得第一天就做出一个能自动规划任务的Agent。我不建议这么干。Agent是复杂度放大器，它适合在“单轮能力已经稳定”之后再加。从零开始做AI工程，正确顺序永远是：先跑通一条最简单的主链路，再加上检索、工具调用、记忆和循环控制。每加一层，都要问自己：这层到底解决了哪个可量化的痛点？如果答不上来，就别加。

1.2 架构分层：数据、模型、Agent、应用、交付

从零搭AI项目，我会习惯性把系统分成五层，每一层都有独立的技术选型和验收标准。这个分层不是教科书理论，而是方便排查问题：一旦出了bug，你至少能快速定位是模型层的问题、数据层的问题，还是应用层的问题。

分层还有一个好处：每一层都可以独立替换。今天用A模型效果不好，换B模型时不需要动整个应用；向量库从Chroma切到pgvector，Agent层也不该受影响。这也是AI工程和传统软件开发最大的不同——模型和工具迭代太快，架构一定要松散耦合，否则每次升级都等于重写一遍。

我实际搭建时，会先画一张简单的系统流程图，把用户请求经过哪些层、每层依赖什么、超时时间是多少标出来。这张图不需要很细致，但必须有。它决定了你后面是花三天调Prompt，还是花三周重构架构。很多人做AI工程做到一半就跑偏，就是因为从没想清楚每个模块的边界。

2. 核心环节一：Prompt工程，AI工程的地基

2.1 Prompt不是玄学，是结构化输入标准

我见过太多人写Prompt全靠“感觉”，今天加一句“请你认真回答”，明天又改成“你是专家”，效果飘忽不定。真正的Prompt工程，本质是：把业务规则翻译成语言模型能稳定执行的输入标准。它和传统软件里的接口文档非常像——字段越清晰，模型越不容易钻空子。

举一个我做情感分析的例子。最初的Prompt是：“请分析这句话的情感。”你能得到一百种格式的回答，有的带解释，有的只给词，有的甚至反问。后来我改成：

你是一个情感分析引擎。 任务：判断用户评论的情感倾向。 规则： 1. 只输出一个词：积极、消极或中性。 2. 不要输出任何解释或标点。 3. 如果内容包含讽刺，按字面意思无法判断，输出“中性”。 用户评论：{评论内容}

效果立刻稳定。不是因为模型变聪明了，而是因为我把输出空间压缩到了固定集合，并且明确禁止了干扰行为。好的Prompt不一定花哨，但一定让模型知道“你要我做什么、按什么格式做、不要做什么”。

Prompt工程里还有个很重要的杠杆：少样本示例。模型在上下文里见过两到三个高质量输入输出对之后，理解成本会大幅降低。比如让模型抽取病历实体，我会在Prompt里粘上两条真实样例，标注出正确结果，再把新样本放进去。这比反复强调“请准确抽取”有效得多。少样本不是越多越好，我用下来3到5个就够了，太多会挤占上下文，还会让模型模仿样本中的噪声。

2.2 三段式模板与参数取舍

我日常写Prompt基本套一个模板，三段式：角色定义、任务描述、输出约束。角色定义给模型一个工作框架，任务描述说清楚目标和输入变量，输出约束锁死格式和边界。如果还需要，就再加一段示例区。这套模板几乎能覆盖大多数业务场景，而且方便复用。

你是{角色}。 你的任务是{一句话说清楚目标}。 输入是：{变量} 请按以下约束输出： - 输出格式：{JSON / Markdown / 纯文本} - 不要做：{禁止事项} - 如果信息不足，请回答：{兜底话术} 示例： 问题：{示例问题} 答案：{示例答案} 现在请处理：{真实输入}

除了Prompt内容，生成参数也在Prompt工程范围之内。两个最关键的参数是temperature和top_p。我做信息抽取、分类、JSON输出这类确定性任务，temperature设0.1到0.2，让模型尽可能保守。做文案生成、头脑风暴这类创意任务，temperature设0.7到0.9，输出会更有变化。top_p我一般保持默认0.9，如果发现回答太发散，就调到0.7以下。max_tokens千万别省，否则回答会被截断，而且很多模型截断后不会提示，只会强行停在中间。

这些参数不是调得越大越好。有一个很常见的坑：为了“看起来有创造性”，把temperature拉到1.5，结果输出开始胡言乱语，连语法都不稳定。模型本质上是个概率采样系统，温度过高会让低概率的糟糕词被放出来。工程里追求的是稳定可控，不是偶尔惊艳。

2.3 上下文管理与Token成本计算

模型有上下文窗口，但上下文不是免费的。窗口越大，延迟越高、显存压力越大、单次调用成本越高。从零开始做AI工程，第一课就是学会算Token预算。

Token的估算没有绝对精确的公式，但你按经验可以做到心里有数：中文环境下，1个汉字大约占0.6到1个Token；英文环境下，大概4个字符约等于1个Token。所以我做容量规划时，会先估算一条完整请求的Token组成，通常包括：系统提示词、用户问题、检索回来的资料、历史的对话轮次、工具返回结果，以及预留的输出Token。假设我们的模型窗口是8K，我会给系统提示词留1000，检索内容最多3000，用户问题加历史3000，输出1000，这样刚好不爆。

上下文管理常见的三个策略是截断、摘要和RAG。截断只适合保存最近几轮对话，简单但会丢信息；摘要是让模型把早期对话压缩成一小段，适合长对话场景；RAG是外部检索，只把和当前问题相关的资料塞进上下文，适合知识问答。三者可以混合用。我做一个客服Agent时，就是把历史对话用另一个轻量模型做摘要，然后跟检索片段一起拼进主Prompt，既控制了成本又保留了关键信息。

还要养成一个习惯：每次调用后都打印响应里的usage字段。只看对话内容很容易忽略实际消耗，尤其当传入的检索结果很大时，成本会悄无声息地翻倍。我见过有人单次请求塞了一两万字知识库，一次调用吃掉两三千Token，导致账单一周涨了十倍。上下文管理不是可选项，是AI工程的基本功。

3. 核心环节二：AI Agent与Harness Engineering

3.1 Agent是什么：LLM + 工具 + 记忆 + 执行

从零开始做AI工程，绕不开AI Agent。简单说，Agent就是让模型不仅能“说话”，还能“做事”：查数据库、调接口、控制软件、发起动作。一个Agent的最小组成，我概括为四部分：LLM大脑、工具集、记忆、执行循环。LLM负责理解和决策，工具集负责连接外部世界，记忆负责保存中间状态，执行循环负责让整个过程在限定步骤内跑完。

用生活化类比来理解：LLM是公司里的老板，工具是老板手下的员工，记忆是老板的记事本，执行循环是项目管理流程。老板不直接干活，但他决定调用哪个员工、按什么顺序调用、最终产出什么。一个合格的Agent工程，不是把老板的话原样转发给员工，而是给整套工作流程定义清晰的接口、状态和失败处理。

我早期写的Agent非常简陋：一个while循环里反复调用模型，直到模型说“结束”。听起来可行，实际上模型经常在一个循环里打转，不断调用同一种工具却从不收敛。这让我意识到，Agent不是“模型能调函数”就完事了，它必须有严格的执行约束。比如一次任务的步骤上限、每一步的超时时间、工具调用的白名单、以及从异常中恢复的兜底逻辑。这些约束，就是接下来要说的Harness Engineering的雏形。

3.2 Harness Engineering：给Agent穿上工程背带

Harness Engineering是我非常看重的一层，也常常被新手忽略。我理解它指的是：为了让Agent稳定、安全、可观测，在模型外部加上一套控制、校验和追踪机制。你可以把它想象成登山背带，它不负责替你爬山，但能保证你在爬的过程中不会失手坠落。

具体到实现，Harness至少包括几个部分：任务分解器，把一个大目标拆成可执行的子步骤；工具注册中心，统一管理Agent能调用哪些工具、每个工具的入参和权限；状态管理，记录当前步骤、前一步输出、剩余预算；可观测性，把每一步的输入输出、Token消耗、报错信息完整落日志。

我做过一个踩坑案例：给Agent注册了搜索、数据库查询、计算器三个工具，但模型经常把参数传错，比如把搜索关键词传到数据库SQL里，导致执行直接报错。后来我加了一个参数校验层，在工具真正执行前先做格式和枚举校验，不合格的调用直接返回错误信息告诉模型重新生成。这一层加上之后，工具误调用率降了差不多四成。Harness不是花架子，它解决的就是这类真实工程问题。

另一个Harness重点是大循环的边界。Agent任务不能无限制跑下去，我会强制设置最大步骤数、最大Token消耗和总超时时间，超限就强制终止，并返回当前已获得的最优结果。这有点像一个预算控制机制，很可能用户问一句“帮我整理报告”，Agent跑了二十步只为了找一个引文，这是不可接受的。该止损就止损，工程里稳定比“聪明”更重要。

3.3 工具调用与安全边界

工具调用是Agent能力的放大器，也是风险集中区。让模型调用外部工具之前，必须把工具描述写得足够清晰，否则模型无法正确选择参数。绝大多数模型平台都支持Function Calling，你可以给每个工具定义一个JSON Schema，包含名称、描述、参数类型、枚举值、是否必填。参数描述越具体，模型越不容易出错。

{ "name": "query_document", "description": "在内部知识库中检索与问题相关的文档片段。", "parameters": { "type": "object", "properties": { "keywords": { "type": "string", "description": "用于检索的关键词或自然语言问题" }, "top_k": { "type": "integer", "description": "返回的文档片段数量，默认5，最大10" } }, "required": ["keywords"] } }

我在接入工具时会坚守几个原则。第一，最小权限：模型只能看到当前任务需要的工具，不需要的全部从工具列表里拿掉，避免它产生幻觉去调用无关能力。第二，服务端校验：模型给出的工具参数必须经过服务端二次校验，绝不直接透传到数据库或第三方接口。第三，危险动作额外确认：删除、发送消息、支付、修改线上配置这类操作，必须触发人工确认流程。别指望模型有“常识”，它只会按概率推断最合适的下一步，而概率最高的动作不一定安全。

还有一点容易被忽略：工具返回结果也要做大小限制和格式清洗。外部接口可能返回几十KB的脏数据，直接塞进上下文会浪费Token，还可能盖过关键信息。我会在Harness里做一层裁剪、提取摘要、结构化，只把最有用的字段返回给模型。这样Agent既快又省，还更容易做出正确决策。

4. 核心环节三：模型部署与AI工程实践

4.1 选型：API调用还是私有化部署

模型部署是AI工程从原型走向生产的关键一环。面对一个具体的业务需求，首先要回答：用现成的模型API，还是自己部署开源模型。两条路线各有优劣，不能盲目跟风。

我的建议是：冷启动阶段优先用API，把业务逻辑和Prompt工程跑通，验证产品价值；等到请求量稳定了、数据隐私要求变高了，再评估私有化部署。不要为了“自主可控”一上来就招运维买GPU，结果模型效果没验证完，成本先烧没了。

私有化部署也别急着微调。现在开源模型的能力已经很强，绝大多数场景只需要把Prompt和RAG做好。微调只适用于两件事：一是特殊输出格式怎么也约束不住，二是领域知识必须融进生成过程。其他情况下，微调的性价比都很低，因为每次基座模型更新，你的数据又得重新适配。

4.2 部署一个可用的推理服务

部署私有化模型，我近一年用得最顺的工具是vLLM。它支持OpenAI兼容接口，也就是说你的业务代码可以完全复用原来的客户端，只改一个base_url就行。下面是一个最基础的启动命令，我用7B模型举例：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000

几个参数值得说明。--gpu-memory-utilization控制显存使用比例，默认会预留一部分给KV cache，但如果你只有一张8G显存卡，跑7B模型就很紧张，建议先调小--max-model-len到4096，或者开启量化。--max-model-len是允许的最大上下文长度，不是越大越好，显存固定时调太大容易启动时就直接OOM。启动之后，可以用一行命令验证服务是否正常：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "Qwen/Qwen2.5-7B-Instruct", "messages": [{"role": "user", "content": "你好"}]}'

业务侧用OpenAI的Python库就能接上：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="EMPTY", ) resp = client.chat.completions.create( model="Qwen/Qwen2.5-7B-Instruct", messages=[ {"role": "user", "content": "用一句话介绍你自己"} ], temperature=0.2, ) print(resp.choices[0].message.content)

如果你需要在推理服务之上再包一个业务接口，我一般用FastAPI做一层BFF（Backend For Frontend），在里面做鉴权、限流、Prompt组装、日志记录和兜底返回。推理服务保持干净，只负责和模型对话，业务逻辑全部放在外层。这样模型升级不影响后端，后端迭代也不干扰模型服务。

4.3 性能调优与监控

部署完之后，最常被问到的问题是：为什么这么慢？AI推理服务和传统Web服务不一样，它的性能瓶颈通常在显存带宽和KV cache，而不只是CPU。我要关注的指标有两类：首Token延迟（TTFT）和生成吞吐（Tokens/s）。首Token延迟影响用户感知，生成吞吐影响并发承载力。

调优手段我按优先级排：第一，用vLLM这类支持Continuous Batching的框架，它能把多个请求拼在一个batch里推理，吞吐提升非常明显。第二，控制上下文长度，上下文越长，KV cache越大，单请求耗时越多。第三，量化模型，比如从FP16降到INT8，显存占用减少，推理速度往往也能提升，代价是效果可能有轻微下降。第四，打开Prefix Caching，如果多轮对话有大量相同的系统提示词，缓存前缀可以大幅减少重复计算。

监控这块别漏掉。至少记录：请求量、成功率、平均延迟、p95延迟、Token消耗量和显存利用率。我会在应用层每次调用后用日志记录usage.prompt_tokens和usage.completion_tokens，再配合服务器监控，这样一旦响应变慢或者成本飙升，能快速定位是哪一层出了问题。没有监控的AI服务，就像一个不带仪表的飞机，起飞容易，降落全凭运气。

5. 从零到一：落地一个AI应用的全流程

5.1 定义一个真实场景：文档问答Agent

前四章把技术点拆开了，这一章我串起来做一个完整案例：基于内部技术文档的问答Agent。这是AI工程里很典型的需求，既涉及RAG，又涉及Agent，还涉及部署和评估。

需求最初描述是：“给新员工做一个助手，问技术问题能直接给出答案。”这句话非常模糊。我开始前先把它补全：用户输入的是一个自然语言问题；系统输出的是一个参考答案和对应文档的引用链接；整套流程必须在3秒内返回；答案必须严格基于内部文档，禁止编造；如果检索结果不足以回答，系统必须直接说“资料库中没有相关内容”，不能硬答。这些约束一明确，方案基本就定了。

架构上，我分为离线索引和在线推理两段。离线阶段把技术文档清洗、切片、向量化后存进向量库。在线阶段，用户问题先向量化，再从向量库召回TopK片段，组装成Prompt，交给模型生成回答。在这个基础上再加一个Agent外壳，让模型可以调用一个“查询文档”工具，如果第一轮召回不理想，它可以选择改写关键词再查一次。注意，这里Agent是辅助，不是主流程，所以它失控的风险有限。

5.2 端到端搭建

第一步是文档清洗。HTML、PDF、Word要转成纯文本，删除页眉页脚、目录和乱码。我通常按固定长度切块，比如512到1024个Token，切块时加10%到15%的重叠，避免一句话被腰斩到下一个块里。切片太小则语义不全，太大会稀释核心信息，带着重叠是一个折中的工程做法。

第二步是向量化。我选一个轻量的Embedding模型，把所有文本块编码成向量，存入向量数据库。工具可以选择Milvus、pgvector或者Chroma，小规模验证期用Chroma最省事。索引建好后，要把每个向量和它的原文、来源文档ID、页码关联起来，这样后续能返回引用。

第三步是检索和生成。查询进来后，我先把问题向量化，从库里召回TopK个相关块，通常K取5。然后用一个组装Prompt把召回内容包进去：

你是技术文档问答助手。 请基于以下资料回答用户问题。 资料： {检索到的文档片段} 注意： 1. 如果资料中没有相关信息，请直接回复“资料库中暂无相关信息”。 2. 引用来源时用[文档ID-序号]标注。 3. 回答控制在200字以内。 用户问题：{用户问题}

第四步是封装成Agent。我给Agent注册了query_document工具，它自动执行上面的检索，但如果首轮结果不理想，模型可以根据已有信息改写查询词再次检索。我把整个流程放入Harness，设置最大迭代3次，超时10秒，所有调用记录日志。最后部署直接用前面介绍过的vLLM加FastAPI，Embedding模型单独拿一个轻量服务，向量库和业务库分开部署。

5.3 成本与评估

上线之前必须做评估。我建了一个50到100条的测试集，覆盖常见问题、冷门问题和故意刁难的问题。每条问题都标注了理想答案或至少标注了答案来源。然后跑一轮离线评测，记录三个指标：准确率、拒答率、引用准确率。准确率是回答内容是否合规且正确；拒答率是遇到未知问题时是否老实说不知道；引用准确率是给出的文档引用是不是真的支撑了回答。这三个指标能暴露大部分问题。比如引用准确率低，说明检索召回相关度不够，需要调切片或换Embedding模型。

成本方面，我按Token估算。假设平均每次请求读入1200Token，输出400Token，国内按0.2元每万Token估算，单次成本大约0.03元。如果每天10000次请求，日成本约300元，月成本接近9000元。这个数字能帮团队做容量预估，也能反推缓存策略：如果用户问题大量重复，我可以把高频问答的答案直接缓存，跳过模型生成，成本和延迟都会明显下降。

部署上线后，我还会持续做回归：每周拿同一份测试集跑一遍，比较新Prompt或新模型的效果。AI系统最大的特点是不确定性，今天通过的case，明天换版本可能就失败。评测集就是AI工程的“自动化测试”，没有它，你根本不敢改任何参数。

6. 常见问题与排查技巧实录

6.1 模型输出不稳定

这是最高频的问题。现象是同样输入，今天返回JSON，明天多了一句解释，后天直接截断。我一般按三步排查：先检查Prompt里是否明确规定了输出格式，并给出了示例；再检查temperature是否过高，抽取任务应该控制在0.2以下；最后检查输出后是否有校验逻辑。模型生成是概率性的，你不能只“希望”它输出合法JSON，必须用代码做二次校验，不合法就自动重试或返回兜底话术。

我在实践里的一个经验是：把输出约束写到工具的返回格式里，比如要求模型以Function Calling的方式返回结构化结果，或者用JSON Mode。这样模型输出的合法性会高很多。当初我做一个实体抽取项目，纯Prompt要求JSON时，通过率只有六成；切到Function Calling之后，通过率稳定在95%以上。所以尽量把格式要求交给框架去约束，不要全靠Prompt里的“请务必”。

6.2 Agent循环卡死

Agent最常见的故障是陷入死循环：模型不停地调用工具，不输出最终答案。我第一次遇到时，任务日志刷了几百行，全是同一条搜索请求，看着都头大。原因往往是工具被过度鼓励，Prompt里写着“你可以多次搜索”，但没有告诉它什么时候该停。后来我给Harness加了三个硬约束：最大迭代次数设为5到10次、全局超时设为30秒、每一步之间必须比较前一步结果，如果工具返回没有带来新信息，就强制结束。

排查这类问题，我靠的是完整的trace日志。每执行一步，就记录这轮的模型推理、工具名、入参、返回摘要和Token消耗。出现死循环时，回放日志很快就能看到是哪一步开始重复的，然后针对性调整Prompt或工具描述。不要试图在模型里“教育”它别死循环，用工程手段锁定边界才是正解。

6.3 部署内存爆炸

私有化部署最常见的事故是OOM。有一次我给一个8G显存的环境部署模型，把--max-model-len设成32768，结果进程一启动就崩溃，日志提示CUDA out of memory。检查后发现：模型本身参数占了不少显存，KV cache又是动态分配的，窗口设太大直接挤爆了。解决办法是把窗口降到4096或8192，同时调低--gpu-memory-utilization，预留更多空间给缓存。另一个隐藏炸弹是日志文件。业务侧如果把每次推理的完整输入输出都打进日志，几天就能占满磁盘。我会把日志轮转打开，或者只记录截断后的摘要。

内存爆炸还有一个多进程陷阱。如果用FastAPI默认的多worker模式，每个worker都会加载一份模型，显存翻倍。推理服务最好单worker，用Batch机制扛并发。实在需要水平扩展，就多加几台机器做负载均衡，而不是在一台机器上硬堆进程。

6.4 上下文丢失

做RAG问答时，用户经常反馈“明明资料里有，它却说不知道”。这种上下文丢失的坑一般有几种。第一，检索TopK太小，真正的答案排在第六位，没被召回。第二，切片太碎，关键信息被切散了，语义不完整。第三，召回的内容和问题表面相似但实际无关，模型不敢用。排查时我先看日志，确认系统到底召回了哪些片段。如果是TopK问题，我调大到8或10；如果是语义不匹配，我会在Embedding前对文档做摘要，或者加一个重排序模型，把真正相关的片段提到前面。

另一种“丢失”是Prompt里的资料太长，模型只关注了开头内容。我会在组装Prompt时，把相关度高的片段放在最靠前的位置，并在Prompt里明确写“优先参考第一条资料”。这些细节看着小，但对生成稳定性影响很大。上下文管理做到最后，拼的还是对细节的把控。

最后分享一个我个人积累多年的体会：从零开始做AI工程，真正难的不是某个算法，而是把不确定性一点一点变成确定性。你现在每给系统加一条校验、加一层超时、加一段日志，都是在给自己的项目上保险。不要迷信某个框架能一次性解决所有问题，先把最简单的主链路跑通，再针对真正出现的故障去迭代。希望你少踩几个坑，早日做出自己满意的AI应用。