从提示工程到智能体：AI应用技术栈演进与实战解析

1. 从“玩具”到“工具”：AI应用技术的演进脉络

最近和不少同行交流，发现一个挺有意思的现象：大家聊起AI，尤其是大语言模型，已经从最初的“哇，它能写诗！”变成了“我们怎么用它把客服成本降下来？”。这个转变背后，其实就是AI应用技术栈在过去一两年里，经历了一场从概念验证到生产落地的快速演进。今天，我就结合自己踩过的坑和做过的项目，把这套技术演进的主线串一串，希望能给正在探索AI应用落地的朋友一些参考。

简单来说，这条主线可以概括为：从基础的Prompt Engineering（提示工程）起步，解决“如何让模型听懂话”的问题；到引入RAG（检索增强生成），解决“如何让模型说正确的话”的问题；再到构建Agent（智能体），解决“如何让模型自主完成复杂任务”的问题。这不仅仅是技术的叠加，更是AI应用从“单次问答”走向“持续工作流”，从“信息助手”走向“业务伙伴”的必然路径。无论你是开发者、产品经理，还是业务负责人，理解这条脉络，都能帮你更清晰地规划自己的AI项目，避免在技术选型上走弯路。

2. 基石：Prompt Engineering——与模型高效沟通的艺术

如果把大语言模型比作一个拥有海量知识但思维跳跃的天才，那么Prompt Engineering就是教会我们如何向这位天才清晰、准确地提问，从而得到我们想要的答案。这绝不是简单的“把问题打进去”，而是一门需要精心设计的沟通艺术。

2.1 核心原则：从模糊指令到结构化提示

早期的尝试往往很直接：“写一篇关于气候变化的文章”。结果模型可能给你一篇科普文、一篇议论文，甚至是一首诗歌，质量也参差不齐。Prompt Engineering的核心，就是通过增加约束和上下文，将模糊的指令转化为结构化的提示。

一个经典的范式是角色-任务-格式三部曲。例如，一个糟糕的提示是：“总结一下这份会议纪要。” 而一个经过工程化处理的提示则是：“你是一位专业的项目经理助理。请阅读以下会议纪要，提取出关键决策项、待办任务（包含负责人和截止日期）以及需要跟进的风险点。请以表格形式输出，表格包含‘类别’、‘内容’、‘负责人’、‘截止日期’四列。”

这里面的门道在于：

• 角色设定：让模型进入特定语境，调用相关的知识风格。
• 任务具体化：明确要执行的动作（提取、总结、分类）和具体对象（决策、任务、风险）。
• 输出格式化：指定结构化输出（如JSON、表格、Markdown列表），极大方便了后续的程序化处理。

我个人的一个实操心得是，把Prompt当作一个可调试的“程序”来对待。为重要的Prompt创建版本库，记录每次修改和对应的输出效果。比如，在要求模型生成SQL语句时，在Prompt中明确提供数据库的Schema描述（表名、字段名、字段类型、示例数据），比单纯说“根据用户问题写SQL”成功率要高出好几个数量级。

2.2 进阶技巧：思维链与少样本学习

当任务变得复杂时，我们需要引导模型进行“思考”。思维链技术就是让模型“把思考步骤说出来”。例如，直接问“小明有5个苹果，吃了2个，又买了3个，现在有几个？”模型可能直接输出“6”。但如果我们提示：“让我们一步步思考。首先，小明一开始有5个苹果。然后，他吃了2个，所以剩下5-2=3个。接着，他又买了3个，所以现在有3+3=6个。因此，答案是6。” 经过这种训练后，模型在解决复杂逻辑、数学或推理问题时，准确率会显著提升。在实际应用中，这可以用于让模型拆解一个复杂的业务问题，先分析涉及哪些因素，再逐步推导结论。

少样本学习则是给模型提供几个输入-输出的例子，让它“照葫芦画瓢”。比如，你想让模型把用户口语化的需求转化为标准的产品功能描述，你可以提供2-3对示例：

输入：“我想要个能快速把图片背景去掉的功能。” 输出：“需求：开发或集成一键抠图功能，支持常见图片格式，处理速度需在3秒内。” 输入：“这里能不能加个提醒，别让我忘了。” 输出：“需求：在关键操作节点增加消息提醒机制，支持站内信或邮件通知。”

然后让模型处理新的输入。这种方法对于格式固定、规则相对明确的任务非常有效，比如实体抽取、情感分类、文本标准化等。

注意：Prompt Engineering的上限取决于模型本身的“理解”和“推理”能力。对于事实性、实时性知识，或者需要精确执行多步骤操作的任务，仅靠Prompt优化是远远不够的。这时，我们就需要引入外部知识和工作流。

3. 升级：RAG——为模型注入精准的知识血液

大语言模型有一个众所周知的短板：知识可能过时，且会产生“幻觉”（即编造看似合理但实际错误的信息）。当你需要模型基于最新的公司财报、内部技术文档或特定的专业知识来回答问题时，单纯的Prompt Engineering就力不从心了。RAG技术正是为了解决“知识精准性”和“事实来源”问题而生的。

3.1 RAG的核心工作流：检索、增强、生成

RAG的流程可以形象地理解为“先查资料，再写答案”。其核心分为三步：

1. 检索：当用户提出一个问题（Query）时，系统首先从外部的知识库（如向量数据库）中，检索出与问题最相关的若干文档片段。
2. 增强：将这些检索到的文档片段，作为额外的上下文信息，与用户的原始问题一起，组合成一个新的、信息更丰富的Prompt。
3. 生成：将这个增强后的Prompt提交给大语言模型，让模型基于给定的参考文档来生成最终答案。

这样做的好处显而易见：答案来源于你提供的可信知识库，减少了幻觉；可以方便地更新知识库来更新模型的知识，无需重新训练模型；并且生成的答案可以附带引用来源，增强了可信度。

3.2 构建生产级RAG系统的关键细节

搭建一个可用的RAG原型可能很快，但要让它在生产环境中稳定、准确，则需要关注大量细节。

首先是知识处理（索引阶段）：

• 文档解析与分块：PDF、Word、HTML、Markdown，每种格式都需要正确的解析器提取纯文本。分块大小是门艺术：块太大，可能包含无关信息，干扰检索精度；块太小，可能丢失完整上下文。通常，我会尝试256-512个token的块大小，并对齐自然段落或章节边界。对于代码、表格等特殊内容，需要特殊处理策略。
• 向量化与嵌入模型选择：文本块需要被转化为向量（嵌入）。嵌入模型的选择至关重要。通用场景下，text-embedding-ada-002或其后续版本是很好的起点。但对于专业领域（如法律、医疗），使用在该领域语料上微调过的嵌入模型，检索效果会有质的飞跃。记住，检索的精度上限在索引阶段就已经决定了。
• 向量数据库选型：Pinecone、Weaviate、Qdrant、ChromaDB、Milvus都是热门选择。对于初创项目或中小规模知识库，ChromaDB简单易用；对于需要云托管、高性能和大规模数据，Pinecone或Weaviate更省心；如果需要极强的自定义和可控性，开源自建的Milvus是选项。我的经验是，前期优先考虑开发速度和易用性。

其次是检索与生成（查询阶段）：

• 检索策略优化：简单的“向量相似度检索”可能不够。可以结合关键词检索（如BM25）进行混合搜索，兼顾语义相似度和字面匹配。更进一步，可以采用重排序技术，即先用向量数据库召回Top K个结果（比如50个），再用一个更精细的交叉编码器模型对这50个结果进行精排，选出最相关的Top N个（比如5个）送入生成阶段，这能显著提升最终答案的质量。
• Prompt设计优化：在RAG中，给模型的Prompt需要精心设计，以强制它使用提供的上下文。例如：“请严格依据以下提供的参考信息来回答问题。如果信息不足以回答问题，请直接说‘根据已知信息无法回答’。参考信息：{context}。问题：{question}”。这能有效抑制模型基于自身知识进行编造。
• 上下文管理：当用户进行多轮对话时，需要将历史对话和本次检索到的上下文巧妙地组合在一起，送入模型。这涉及到如何避免上下文窗口被撑爆，以及如何让模型更好地理解对话脉络。

我踩过的一个经典坑是：知识库文档质量不高，包含大量重复、过时或矛盾的信息。这导致检索系统总是返回垃圾信息，无论后面的RAG流程多精巧，产出也是垃圾。所以，构建RAG系统的第一步，必须是知识库的清洗与治理，这常常是耗时最长、但收益最高的一步。

4. 进化：Agent——让AI成为自主的任务执行者

如果说RAG让模型有了“准确的记忆”，那么Agent则是赋予模型“行动的手脚”和“规划的大脑”。Agent的核心思想是让大语言模型扮演“大脑”的角色，通过感知（理解用户指令和当前环境）、规划（拆解任务、制定步骤）、行动（调用各种工具API）和反思（评估结果、调整策略）的循环，来自主完成一个复杂目标。

4.1 Agent的核心架构：大脑、工具与工作流

一个典型的Agent系统包含几个关键部分：

1. 规划器：通常由LLM本身担任，负责理解用户目标，并将其分解为一系列可执行的子任务或步骤。例如，用户说“帮我分析一下上个月销售数据的主要趋势，并做一份PPT摘要”，规划器需要拆解为：1. 连接数据库获取数据；2. 调用数据分析工具进行趋势分析；3. 根据分析结果生成文字总结；4. 调用PPT生成工具创建幻灯片。
2. 工具集：这是Agent能力的延伸。工具可以是任何可通过API调用的功能：搜索引擎、数据库查询、代码执行器、发送邮件、操作文件、调用第三方服务（如天气、股票）等。LangChain、LlamaIndex等框架提供了大量内置工具和便捷的定义方式。
3. 执行器与工作流引擎：负责按照规划器的调度，依次或并行地调用工具，并管理工具之间的数据传递。对于复杂、有固定模式的任务，我们可以用工作流来预先定义步骤（如使用LangGraph、Dify Workflow），让Agent在框架内执行；对于开放式的探索性任务，则更需要Agent的自主规划和决策能力。
4. 记忆模块：让Agent记住之前的交互历史、工具执行结果，从而在长对话中保持一致性，并基于历史进行学习优化。这可以是简单的对话历史缓存，也可以是更复杂的向量化记忆存储。

4.2 从单智能体到多智能体协作

简单的任务，一个Agent足以应对。但现实世界的复杂问题，往往需要多个各有所长的Agent协同工作。这就引出了多智能体系统的概念。

想象一个产品需求评审场景：

• 产品经理Agent：负责理解原始的用户故事，并用标准的产品需求文档格式进行细化。
• 工程师Agent：接收PRD，评估技术可行性，识别技术风险，并估算工作量。
• 设计师Agent：根据PRD，生成初步的界面布局或交互流程描述。
• 协调员Agent（或通过一个主Agent调度）：主持这几个Agent之间的“讨论”，收集各方的意见，处理冲突（如工程师认为某个功能实现成本过高），并最终推动形成一个共识方案。

这些Agent之间可以通过共享的工作区、消息总线或直接的API调用进行通信和协作。多智能体系统能够模拟一个虚拟团队，处理需要多领域专业知识交叉的复杂任务，是当前AI应用的前沿探索方向。

在开发Agent时，最大的挑战之一是可靠性。LLM作为规划器，其输出具有不确定性，可能制定出不合逻辑或无法执行的计划。因此，必须为关键的工具调用设置严格的验证和回退机制。例如，在Agent执行“发送邮件”动作前，可以设计一个子步骤，让另一个LLM或规则引擎来检查邮件内容是否包含敏感词、收件人格式是否正确。如果检查不通过，则触发人工审核或重新规划。没有这些安全护栏，Agent很容易在生产环境中“闯祸”。

5. 实战融合：构建一个完整的AI应用技术栈

理论讲完了，我们来看一个融合了PE、RAG和Agent思想的综合案例：构建一个智能技术客服助手。

5.1 需求拆解与架构设计

这个助手需要能：

1. 回答用户关于公司产品API、SDK的技术问题。
2. 能查询最新的服务状态（如某区域是否故障）。
3. 在复杂问题无法解决时，能自动收集问题上下文，并创建工单。

对应的技术栈设计如下：

• 知识来源：产品官方文档（Markdown/PDF）、API参考（Swagger/OpenAPI）、历史工单知识库、实时系统状态API。
• 核心架构：
  • RAG子系统：处理产品文档和历史工单知识，用于回答常见技术问题。这里需要精细的文档分块策略，特别是对API文档，需要将每个端点及其参数、响应示例作为一个独立的块，便于精准检索。
  • 工具集成：为Agent配备工具，包括：查询服务状态工具（调用内部状态API）、搜索最新公告工具（调用公告板API）、创建工单工具（调用工单系统API）。
  • Agent大脑：一个具备规划能力的LLM。它首先判断用户问题类型：是文档问题、状态查询还是需要人工介入。然后规划执行路径。

5.2 工作流与Prompt设计

一个典型的用户会话处理流程如下：

1. 意图识别与路由：用户输入：“Python SDK里上传文件的upload方法最近报404错误，怎么回事？”
2. RAG优先检索：Agent大脑首先将问题送入RAG流程，检索产品文档中关于upload方法的部分。如果检索到的信息明确指出了原因（例如，“该端点已于v2.1版本废弃，请改用upload_v2”），则直接生成答案返回。
3. 工具调用介入：如果RAG返回的信息无法解释“最近报错”，或者用户问题中包含“最近”、“现在”等时效性词汇，Agent大脑会规划调用查询服务状态工具和搜索最新公告工具，检查是否有相关的服务故障或变更公告。
4. 综合分析与行动：Agent大脑综合RAG的文档信息、工具返回的实时状态和公告信息，生成最终答案。例如：“根据文档，upload方法运行正常。但根据系统状态，您所在区域的存储服务在1小时前发生了短暂故障，目前已恢复，可能是这个原因导致。建议您重试操作，如果仍报错，我可以为您创建工单联系工程师深入排查。”
5. 工单创建（如果需要）：如果用户要求或问题确实复杂，Agent调用创建工单工具，自动将对话历史、检索到的相关文档片段、工具查询结果作为附件，生成一个信息完整的预填工单。

在这个流程中，每一个环节的Prompt都需要精心设计。例如，给“Agent大脑”的Prompt需要明确其角色、可用工具列表、工具调用格式，以及决策逻辑的指导原则（如“优先使用RAG知识，当涉及实时信息时再调用工具”）。

5.3 避坑经验与性能调优

在实施这类综合系统时，有几个关键点需要特别注意：

• 成本控制：RAG的索引和查询、Agent的多次LLM调用都会产生费用。需要对检索到的文档块进行“去重”和“精筛”，避免将过多无关上下文塞给LLM。对于Agent的规划步骤，可以考虑使用更小、更快的模型（如GPT-3.5-Turbo）进行初步规划，只在最终答案生成时使用更强大的模型（如GPT-4）。
• 延迟优化：串行执行RAG检索、工具调用、LLM生成会导致总延迟很高。可以考虑并行化操作，例如，在用户问题输入后，同时发起RAG检索和可能用到的工具查询（基于对问题的预判），然后再由LLM进行综合，能有效降低响应时间。
• 评估体系：如何衡量这个客服助手的好坏？不能只看人工感觉。需要建立评估体系，包括：回答准确率（基于已知问题集）、幻觉率、工具调用准确率、用户满意度评分（CSAT）以及问题解决率（一次对话解决 vs. 需要转人工）。定期用评估集测试，是持续优化系统的唯一可靠方法。

6. 未来展望：技术趋势与个人思考

回顾这条从Prompt Engineering到RAG再到Agent的演进路径，本质是AI应用从“交互界面”走向“系统核心”的过程。未来的趋势，我认为会集中在以下几个方面：

1. 模型专业化与小型化：通用大模型是强大的“大脑底座”，但在特定领域（如代码、法律、医疗），经过高质量领域数据微调的专业模型，或参数更小、推理更快的模型，在成本、速度和效果上会更具优势。我们不再追求一个模型解决所有问题，而是组建一个“模型团队”。

2. 工作流设计的工程化：像LangGraph、Dify Workflow这样的可视化工作流编排工具会越来越重要。它们降低了构建复杂Agent系统的门槛，让关注点从代码细节转移到业务逻辑和流程设计上。如何设计健壮、可调试、可监控的工作流，将成为AI工程师的核心技能之一。

3. 评估与可观测性成为标配：随着AI应用深入核心业务，其输出的稳定性、公平性、安全性变得至关重要。构建全面的评估基准、建立贯穿开发到生产全链路的可观测性（监控每一次LLM调用、工具调用、上下文内容），将是产品能否上线的关键门槛。

4. 多模态能力常态化：未来的Agent不仅能理解和生成文本，还能处理图像、音频、视频，甚至操控机器人。这要求技术栈具备更强的多模态信息理解和生成能力，RAG的知识库也将从纯文本扩展到多模态内容。

从我个人的实践来看，当前最大的机会不在于追逐最前沿的模型，而在于如何将PE、RAG、Agent这些相对成熟的技术，与具体的、有痛点的业务场景进行深度结合。技术是锤子，但首先要找到那颗钉子。理解业务，定义清楚问题，往往比选择哪个框架更重要。同时，保持对技术演进的关注，在架构设计上留有弹性，以便在更好的“锤子”出现时，能够快速整合进来。AI应用开发，正从一个探索性的技术实验，转变为一门需要深厚工程化能力的严肃学科。