1. 从“玩具”到“工具”AI应用的技术演进脉络如果你在2022年底第一次接触ChatGPT大概率会觉得它是个有趣的“玩具”——能写诗、能聊天、能编故事但真要让它帮你处理点正经工作比如分析一份财报或者从公司内部文档里找答案它要么一本正经地胡说八道要么干脆告诉你“作为AI我无法访问实时数据”。短短两年过去情况已经天翻地覆。今天一个合格的AI应用已经不再是那个只会天马行空聊天的“玩具”而是一个能理解复杂指令、调用专属知识、执行多步任务的“工具”。这个转变背后是一系列关键技术的快速迭代与组合。从最初简单的Prompt Engineering到构建专属知识库的RAG再到能自主规划行动的Agent每一次演进都让AI离解决实际问题更近一步。这篇文章我们就来串讲一下这条从“玩具”到“工具”的核心技术演进路径看看每个阶段解决了什么问题又引入了哪些新的挑战。2. 第一站Prompt Engineering——让模型“听懂人话”的艺术当大语言模型LLM的能力被释放出来我们遇到的第一个现实问题是如何有效地与它沟通你问它“公司的营收情况”它可能给你编一个故事你让它“总结这篇文档”它可能漏掉最关键的数据。Prompt Engineering提示工程就是解决这个“沟通效率”问题的第一把钥匙。它的核心思想是通过精心设计输入给模型的文本即Prompt来引导模型输出更准确、更符合预期的结果。2.1 从零样本到思维链Prompt的进化最初的交互是“零样本”Zero-Shot的即直接给一个任务指令比如“将以下英文翻译成中文”。这种方法简单但对复杂任务效果有限。很快“少样本”Few-Shot学习成为主流即在指令中提供几个输入-输出的例子让模型通过类比来学习任务格式和逻辑。例如在让模型进行情感分析前先给它几个“评论-情感倾向”的配对示例。然而真正的突破来自“思维链”Chain-of-Thought, CoT提示。研究人员发现对于需要多步推理的复杂问题如数学应用题如果在示例中展示出一步步的推理过程模型模仿这种“思考”过程后其推理能力会大幅提升。这不再是简单的指令-输出映射而是教会模型一种解决问题的方法论。在实际应用中CoT提示让模型在代码生成、逻辑分析等任务上的表现产生了质的飞跃。注意思维链提示的成功揭示了LLM的一个重要特性它不仅仅是在做模式匹配而是在一定程度上能够进行隐式的逻辑推理。但这也对Prompt设计者提出了更高要求你需要为模型“搭建”好推理的脚手架。2.2 结构化提示与角色扮演提升稳定性的实战技巧在工程实践中我们很快发现随意编写的Prompt就像不稳定的API输出结果波动很大。为了提高稳定性和可控性一系列结构化的Prompt设计模式被广泛采用。最经典的是“角色-指令-上下文-输出格式”四段式结构。例如角色你是一位资深的数据分析师。 指令请分析以下销售数据表格找出销售额环比下降超过10%的产品线并分析可能的原因。 上下文[此处粘贴销售数据表格] 输出格式请以JSON格式输出包含字段product_line产品线sales_drop_rate销售额下降率possible_reasons可能原因列表。这种结构明确了模型的“身份”、具体任务、所需信息以及我们期望的回应形式能极大减少模型的“自由发挥”使其输出更规范、更易于被下游程序处理。另一个重要技巧是“系统提示词”System Prompt与“用户提示词”User Prompt的分离。在像OpenAI的API中系统提示词用于设定模型的整体行为准则和角色如“你是一个有帮助且无害的助手”而用户提示词则承载具体的任务指令。合理利用系统提示词可以更稳固地锁定模型的行为模式。2.3 Prompt Engineering的局限与天花板尽管Prompt Engineering极大地提升了人机交互的效能但它存在一个根本性的天花板模型的知识截止日期和幻觉问题。无论你的Prompt设计得多么精妙模型的知识都局限于其训练数据截止的那个时间点例如GPT-4是2023年4月。它无法知晓之后发生的新闻、公司最新的财报数据或者你私有的技术文档。更棘手的是“幻觉”Hallucination即模型会以高度自信的语气编造看似合理但完全错误的事实、引用不存在的文献或数据。当你问及它训练数据之外或边界模糊的信息时幻觉尤其容易出现。这意味着仅靠Prompt Engineering无法构建一个基于实时、私有、精确知识的可靠应用。要突破这个天花板我们需要引入新的技术——RAG。3. 第二站RAG——为模型注入“专属知识”的桥梁检索增强生成Retrieval-Augmented Generation, RAG的出现正是为了攻克LLM的“知识固化”和“幻觉”难题。它的核心思想非常直观当用户提问时先从外部的、可更新的知识库如你的文档、数据库、网页中检索出与问题最相关的信息片段然后将这些信息片段和原始问题一起作为上下文提供给LLM让LLM基于这些“证据”来生成答案。3.1 RAG的核心工作流程与组件拆解一个标准的RAG系统通常包含三个核心环节索引Indexing、检索Retrieval和生成Generation。索引环节是准备知识库的过程。你需要将原始的非结构化文档如PDF、Word、网页进行“切分”Chunking转换成更小的文本片段例如每段500字。然后使用嵌入模型Embedding Model将这些文本片段转换为高维向量Vector并存储到向量数据库如Chroma、Pinecone、Milvus中。这个过程相当于为你的知识库创建了一个可供快速语义搜索的“地图”。检索环节发生在用户提问时。系统首先将用户的问题同样转换为向量然后在向量数据库中进行相似度搜索如余弦相似度找出与问题向量最接近的若干个文本片段。这些片段就是模型生成答案所需的“参考材料”。生成环节则是将检索到的文本片段作为上下文和用户原始问题组合成一个新的、信息丰富的Prompt提交给LLM。指令通常是“请基于以下上下文信息回答问题。如果上下文不包含答案请直接说‘根据提供的信息无法回答’。” 这样LLM的答案就有了依据既扩展了知识边界又在一定程度上被“锚定”在事实材料上减少了幻觉。3.2 从基础RAG到高级RAG解决“找不到、用不好”的痛点基础的RAG管道听起来完美但在实际应用中会暴露一系列问题催生了“高级RAG”技术的演进。痛点一检索精度不足。简单的向量相似度检索可能找到一些语义相关但并非直接回答问题的文档或者漏掉关键信息。解决方案包括查询重写Query Rewriting在检索前先用LLM对原始问题进行扩展或改写生成多个相关查询并行检索后再合并结果。例如将“苹果财报如何”重写为“Apple Inc. 2024 Q1 financial report revenue net income”、“苹果公司最新季度财务表现”等。混合检索Hybrid Search结合传统的基于关键词的检索如BM25和向量检索。关键词检索保证术语匹配的精确性向量检索保证语义匹配的灵活性两者结果加权融合效果通常优于单一方法。重排序Re-ranking在初步检索出一批文档例如100个后使用一个更精细但计算成本更高的重排序模型如Cohere的rerank模型对这批文档进行二次排序选出最相关的几个例如5个送入生成环节。这好比先用搜索引擎找出一堆网页再用人工判断挑出最靠谱的那几个。痛点二上下文窗口限制与信息整合难题。即使检索到了多个相关片段如何将它们有效地组织成连贯的上下文直接拼接可能超出模型上下文长度也可能逻辑混乱。高级RAG会采用更智能的上下文管理策略比如基于文档结构进行分层次检索或者使用LLM先对检索结果进行摘要和整合。痛点三无法处理复杂、多跳问题。例如“我们公司去年销量最高的产品其主要竞争对手是谁”这个问题需要两步先查出“去年销量最高的产品”再根据这个产品去查“主要竞争对手”。基础RAG一步检索难以完成。这就需要引入更复杂的Agentic RAG让一个智能体Agent来规划并执行这个多步检索-推理流程。3.3 RAG的实战心得与避坑指南在实际搭建RAG系统时有几个细节决定了成败文档切分是门艺术。切得太碎会丢失上下文连贯性切得太大会引入无关噪声且容易超出模型窗口。一个实用的策略是重叠切分即让相邻的文本块有一小部分重叠例如50-100字确保边界信息不丢失。同时可以尝试按语义段落或章节进行切分而非固定字符数。选择合适的嵌入模型至关重要。不同嵌入模型在不同语种和领域的表现差异巨大。对于中文场景不能盲目使用OpenAI的text-embedding-ada-002而应考虑BGE、M3E等针对中文优化的开源模型。在投入生产前务必在自己的业务语料上做一个小规模的检索效果评估。必须设立“拒答”机制。这是控制幻觉的最后一道防线。在你的系统Prompt中必须明确要求“仅根据提供的上下文信息回答问题。如果上下文信息不足以回答或者问题与上下文无关请明确告知用户无法基于现有信息回答。” 并在测试中反复验证这一机制是否生效。一个总是试图回答所有问题的RAG系统是危险的。尽管RAG解决了知识更新和部分幻觉问题但它本质上还是一个“被动应答”系统。它等待用户提问然后检索-生成答案。对于需要主动规划、执行多步操作、与环境交互的复杂任务我们需要更强大的范式——Agent。4. 第三站Agent——赋予模型“规划与执行”的能力如果说Prompt Engineering是让模型“听懂话”RAG是给模型“喂资料”那么Agent智能体就是让模型“自己动手做事”。一个AI Agent可以被理解为一个由LLM驱动的大脑它能够理解复杂目标自主规划执行步骤调用各种工具如搜索引擎、计算器、API、数据库来完成任务并根据执行结果动态调整计划。4.1 Agent的核心架构思考、行动、观察的循环一个典型的Agent遵循经典的“思考-行动-观察”循环这通常通过ReActReasoning Acting等框架来实现。思考ThoughtAgent分析当前状态包括用户目标、已有信息、历史步骤决定下一步该做什么。是时候调用某个工具了吗还是已经可以给出最终答案了行动Action根据思考的结果Agent执行一个具体的动作。这通常表现为调用一个预定义的工具Tool并传入相应的参数。例如Action: Search[“上海今日天气”]。观察Observation工具执行后返回结果。例如Observation: 上海今日晴气温15-22摄氏度。这个结果会被添加到Agent的上下文记忆中。循环Agent基于新的观察再次进入“思考”阶段决定后续动作如此循环直至任务完成或达到终止条件。这个循环的核心在于LLM不仅用于生成最终答案更用于每一步的推理和决策。它需要理解工具的功能描述、判断何时使用何种工具、解析工具返回的结果并从中提取有价值的信息。4.2 工具使用与规划Agent的“手脚”与“蓝图”Agent的能力边界很大程度上取决于它所能调用的“工具集”。常见的工具包括信息获取工具网络搜索API、数据库查询、企业内部系统API。计算与处理工具计算器、代码解释器可执行Python进行数据分析或图表生成、文档处理工具。控制工具发送邮件、操作日历、控制智能家居通过API。为了让LLM能正确使用工具我们需要以结构化的方式如OpenAI的Function Calling格式或LangChain的Tool定义向模型描述每个工具它的名称、功能描述、所需的参数及其格式。这就像给模型一本工具说明书。对于复杂任务单步思考可能不够Agent需要具备任务分解Task Decomposition和规划Planning的能力。例如用户请求“帮我策划一个周末杭州的旅行计划”。一个具备规划能力的Agent可能会自动分解为“1. 搜索杭州周末的天气。2. 查找杭州热门景点及开放时间。3. 查询上海到杭州的高铁班次。4. 根据景点位置和交通时间排出一个初步日程。5. 估算大致费用。” 然后逐步执行这些子任务。像LangGraph这样的框架就是用来定义和管理这种有状态、多步骤的Agent工作流的。4.3 Agent开发中的核心挑战与应对策略开发一个稳定可靠的Agent远比搭建一个RAG系统更具挑战性。挑战一规划与推理的不可靠性。LLM的规划能力并不完美它可能制定出不合逻辑的步骤或者在多步推理中迷失方向。应对策略包括提供示例Few-Shot Planning在系统提示词中提供几个复杂任务被成功分解和执行的示例引导模型模仿。设置检查点与人工审核对于关键业务流程可以在Agent执行到某些步骤如“准备发送邮件”时暂停将计划或内容提交给人工审核确认。采用更稳健的框架使用如CrewAI、AutoGen等多Agent协作框架让不同的Agent专注于特定角色如规划者、执行者、审核者通过分工协作降低单个Agent出错的概率。挑战二工具调用的精确性。模型可能误解工具描述传错参数格式。除了精心编写工具描述外可以采用验证层在工具被真正调用前用一个简单的规则或轻量级模型对参数进行预校验。或者设计“工具使用确认”环节让Agent在调用关键工具前先将其意图用自然语言描述给用户确认。挑战三长程任务中的记忆与状态管理。Agent在长时间、多步骤的任务中需要记住之前做了什么、得到了什么结果。简单的将全部历史对话放入上下文会很快耗尽Token。因此需要外部记忆Memory系统如向量数据库存储历史关键信息或者总结性记忆将长段历史压缩成摘要。挑战四成本与延迟。Agent的每一步思考、每一次工具调用都可能涉及LLM API调用复杂任务可能导致高昂的成本和较慢的响应速度。需要对非关键路径的思考使用更小、更快的模型并对工具调用结果进行缓存。Agent代表了当前AI应用的前沿它将LLM从一个强大的文本生成器转变为一个可以嵌入真实业务流程、自动完成任务的“数字员工”。从简单的自动化脚本到复杂的决策支持系统Agent的范式正在被广泛应用。5. 技术融合与工程化落地构建下一代AI应用当我们回顾Prompt Engineering、RAG、Agent这三项技术时会发现它们并非相互替代而是层层递进、相互融合的关系。一个成熟的、面向生产的AI应用往往是这三者的有机结合体。5.1 架构模式RAG作为Agent的“记忆体”一个非常强大的模式是“Agent with RAG”。在这个架构中RAG系统充当了Agent的长期、可更新的专属记忆库或知识库。当Agent在执行任务过程中需要查询特定知识如公司制度、产品手册、历史数据时它不是去调用可能不准确或信息滞后的通用搜索引擎而是调用内嵌的RAG模块从权威的内部知识库中获取精准信息。例如一个客户服务Agent在回答用户关于“产品A的保修政策”时其内部流程可能是1. 思考需要查询产品A的保修信息。2. 行动调用内部RAG查询工具输入“产品A 保修期限 条件”。3. 观察RAG返回从最新产品手册中检索到的相关条款。4. 思考整合信息生成对用户友好的回答。5. 行动输出最终答案。这样Agent获得了精准执行的能力而RAG也从一个被动的问答系统升级为主动赋能智能体的知识引擎。5.2 工程化考量超越原型走向生产将AI应用从演示原型推向稳定可靠的生产系统需要跨越巨大的工程鸿沟。评估与监控如何衡量AI应用的效果不能只靠人工抽查。需要建立一套评估体系包括忠实度Faithfulness答案是否严格基于提供的上下文这用于对抗幻觉。相关性Relevance答案是否直接回答了问题毒性/安全性输出内容是否安全合规延迟与成本平均响应时间、每次查询的Token消耗和API成本。 可以设计自动化测试集定期跑分并在生产环境对用户查询和模型输出进行采样分析。稳定性与容错LLM API可能不稳定工具调用可能失败。系统必须有重试机制、降级策略如当主要模型超时时切换至备用模型或返回缓存结果和清晰的错误处理向用户提供友好的错误信息而不是崩溃或输出乱码。可观测性系统必须提供详细的日志记录每一次用户查询、模型的思考过程、工具调用的输入输出、最终响应等。这不仅是调试和排查问题的生命线也是理解模型行为、优化Prompt和工具的关键数据来源。使用LangSmith、Arize AI等专门针对LLM应用的可观测性平台可以极大提升效率。5.3 未来展望更自主、更专业、更集成技术的演进不会停止。当前我们正看到几个清晰的发展趋势Agent能力的深化从单一Agent向多Agent协作Multi-Agent Collaboration发展。不同的Agent扮演不同角色如策划、执行、审核通过辩论、协商共同完成复杂任务这能有效提升任务完成的可靠性和质量。垂直化与专业化通用大模型LLM作为“大脑”底座结合垂直领域的专业工具、工作流和知识库形成行业专属的超级助手。在金融、法律、医疗、编程等领域这种“LLM领域知识领域工具”的范式正在创造巨大价值。与现有软件生态的深度融合AI能力不再是一个独立的聊天窗口而是以“副驾驶”Copilot的形式深度集成到IDE、办公软件、CRM、ERP等所有生产力工具中。通过插件、API、SDKAI将成为软件交互的新一层自然语言界面。从精心设计Prompt与模型对话到为模型连接海量知识库再到赋予模型规划与执行的能力AI应用的技术栈正在快速成熟。这条演进路径的本质是不断拓展LLM的能力边界将其从语言模型逐步升级为能够解决实际问题的“行动模型”。对于开发者而言理解并掌握这条技术链上的每一个环节并能够根据具体场景灵活组合运用是构建有价值、可落地的下一代AI应用的关键。 从Prompt到Agent：AI应用核心技术演进与工程实践
1. 从“玩具”到“工具”AI应用的技术演进脉络如果你在2022年底第一次接触ChatGPT大概率会觉得它是个有趣的“玩具”——能写诗、能聊天、能编故事但真要让它帮你处理点正经工作比如分析一份财报或者从公司内部文档里找答案它要么一本正经地胡说八道要么干脆告诉你“作为AI我无法访问实时数据”。短短两年过去情况已经天翻地覆。今天一个合格的AI应用已经不再是那个只会天马行空聊天的“玩具”而是一个能理解复杂指令、调用专属知识、执行多步任务的“工具”。这个转变背后是一系列关键技术的快速迭代与组合。从最初简单的Prompt Engineering到构建专属知识库的RAG再到能自主规划行动的Agent每一次演进都让AI离解决实际问题更近一步。这篇文章我们就来串讲一下这条从“玩具”到“工具”的核心技术演进路径看看每个阶段解决了什么问题又引入了哪些新的挑战。2. 第一站Prompt Engineering——让模型“听懂人话”的艺术当大语言模型LLM的能力被释放出来我们遇到的第一个现实问题是如何有效地与它沟通你问它“公司的营收情况”它可能给你编一个故事你让它“总结这篇文档”它可能漏掉最关键的数据。Prompt Engineering提示工程就是解决这个“沟通效率”问题的第一把钥匙。它的核心思想是通过精心设计输入给模型的文本即Prompt来引导模型输出更准确、更符合预期的结果。2.1 从零样本到思维链Prompt的进化最初的交互是“零样本”Zero-Shot的即直接给一个任务指令比如“将以下英文翻译成中文”。这种方法简单但对复杂任务效果有限。很快“少样本”Few-Shot学习成为主流即在指令中提供几个输入-输出的例子让模型通过类比来学习任务格式和逻辑。例如在让模型进行情感分析前先给它几个“评论-情感倾向”的配对示例。然而真正的突破来自“思维链”Chain-of-Thought, CoT提示。研究人员发现对于需要多步推理的复杂问题如数学应用题如果在示例中展示出一步步的推理过程模型模仿这种“思考”过程后其推理能力会大幅提升。这不再是简单的指令-输出映射而是教会模型一种解决问题的方法论。在实际应用中CoT提示让模型在代码生成、逻辑分析等任务上的表现产生了质的飞跃。注意思维链提示的成功揭示了LLM的一个重要特性它不仅仅是在做模式匹配而是在一定程度上能够进行隐式的逻辑推理。但这也对Prompt设计者提出了更高要求你需要为模型“搭建”好推理的脚手架。2.2 结构化提示与角色扮演提升稳定性的实战技巧在工程实践中我们很快发现随意编写的Prompt就像不稳定的API输出结果波动很大。为了提高稳定性和可控性一系列结构化的Prompt设计模式被广泛采用。最经典的是“角色-指令-上下文-输出格式”四段式结构。例如角色你是一位资深的数据分析师。 指令请分析以下销售数据表格找出销售额环比下降超过10%的产品线并分析可能的原因。 上下文[此处粘贴销售数据表格] 输出格式请以JSON格式输出包含字段product_line产品线sales_drop_rate销售额下降率possible_reasons可能原因列表。这种结构明确了模型的“身份”、具体任务、所需信息以及我们期望的回应形式能极大减少模型的“自由发挥”使其输出更规范、更易于被下游程序处理。另一个重要技巧是“系统提示词”System Prompt与“用户提示词”User Prompt的分离。在像OpenAI的API中系统提示词用于设定模型的整体行为准则和角色如“你是一个有帮助且无害的助手”而用户提示词则承载具体的任务指令。合理利用系统提示词可以更稳固地锁定模型的行为模式。2.3 Prompt Engineering的局限与天花板尽管Prompt Engineering极大地提升了人机交互的效能但它存在一个根本性的天花板模型的知识截止日期和幻觉问题。无论你的Prompt设计得多么精妙模型的知识都局限于其训练数据截止的那个时间点例如GPT-4是2023年4月。它无法知晓之后发生的新闻、公司最新的财报数据或者你私有的技术文档。更棘手的是“幻觉”Hallucination即模型会以高度自信的语气编造看似合理但完全错误的事实、引用不存在的文献或数据。当你问及它训练数据之外或边界模糊的信息时幻觉尤其容易出现。这意味着仅靠Prompt Engineering无法构建一个基于实时、私有、精确知识的可靠应用。要突破这个天花板我们需要引入新的技术——RAG。3. 第二站RAG——为模型注入“专属知识”的桥梁检索增强生成Retrieval-Augmented Generation, RAG的出现正是为了攻克LLM的“知识固化”和“幻觉”难题。它的核心思想非常直观当用户提问时先从外部的、可更新的知识库如你的文档、数据库、网页中检索出与问题最相关的信息片段然后将这些信息片段和原始问题一起作为上下文提供给LLM让LLM基于这些“证据”来生成答案。3.1 RAG的核心工作流程与组件拆解一个标准的RAG系统通常包含三个核心环节索引Indexing、检索Retrieval和生成Generation。索引环节是准备知识库的过程。你需要将原始的非结构化文档如PDF、Word、网页进行“切分”Chunking转换成更小的文本片段例如每段500字。然后使用嵌入模型Embedding Model将这些文本片段转换为高维向量Vector并存储到向量数据库如Chroma、Pinecone、Milvus中。这个过程相当于为你的知识库创建了一个可供快速语义搜索的“地图”。检索环节发生在用户提问时。系统首先将用户的问题同样转换为向量然后在向量数据库中进行相似度搜索如余弦相似度找出与问题向量最接近的若干个文本片段。这些片段就是模型生成答案所需的“参考材料”。生成环节则是将检索到的文本片段作为上下文和用户原始问题组合成一个新的、信息丰富的Prompt提交给LLM。指令通常是“请基于以下上下文信息回答问题。如果上下文不包含答案请直接说‘根据提供的信息无法回答’。” 这样LLM的答案就有了依据既扩展了知识边界又在一定程度上被“锚定”在事实材料上减少了幻觉。3.2 从基础RAG到高级RAG解决“找不到、用不好”的痛点基础的RAG管道听起来完美但在实际应用中会暴露一系列问题催生了“高级RAG”技术的演进。痛点一检索精度不足。简单的向量相似度检索可能找到一些语义相关但并非直接回答问题的文档或者漏掉关键信息。解决方案包括查询重写Query Rewriting在检索前先用LLM对原始问题进行扩展或改写生成多个相关查询并行检索后再合并结果。例如将“苹果财报如何”重写为“Apple Inc. 2024 Q1 financial report revenue net income”、“苹果公司最新季度财务表现”等。混合检索Hybrid Search结合传统的基于关键词的检索如BM25和向量检索。关键词检索保证术语匹配的精确性向量检索保证语义匹配的灵活性两者结果加权融合效果通常优于单一方法。重排序Re-ranking在初步检索出一批文档例如100个后使用一个更精细但计算成本更高的重排序模型如Cohere的rerank模型对这批文档进行二次排序选出最相关的几个例如5个送入生成环节。这好比先用搜索引擎找出一堆网页再用人工判断挑出最靠谱的那几个。痛点二上下文窗口限制与信息整合难题。即使检索到了多个相关片段如何将它们有效地组织成连贯的上下文直接拼接可能超出模型上下文长度也可能逻辑混乱。高级RAG会采用更智能的上下文管理策略比如基于文档结构进行分层次检索或者使用LLM先对检索结果进行摘要和整合。痛点三无法处理复杂、多跳问题。例如“我们公司去年销量最高的产品其主要竞争对手是谁”这个问题需要两步先查出“去年销量最高的产品”再根据这个产品去查“主要竞争对手”。基础RAG一步检索难以完成。这就需要引入更复杂的Agentic RAG让一个智能体Agent来规划并执行这个多步检索-推理流程。3.3 RAG的实战心得与避坑指南在实际搭建RAG系统时有几个细节决定了成败文档切分是门艺术。切得太碎会丢失上下文连贯性切得太大会引入无关噪声且容易超出模型窗口。一个实用的策略是重叠切分即让相邻的文本块有一小部分重叠例如50-100字确保边界信息不丢失。同时可以尝试按语义段落或章节进行切分而非固定字符数。选择合适的嵌入模型至关重要。不同嵌入模型在不同语种和领域的表现差异巨大。对于中文场景不能盲目使用OpenAI的text-embedding-ada-002而应考虑BGE、M3E等针对中文优化的开源模型。在投入生产前务必在自己的业务语料上做一个小规模的检索效果评估。必须设立“拒答”机制。这是控制幻觉的最后一道防线。在你的系统Prompt中必须明确要求“仅根据提供的上下文信息回答问题。如果上下文信息不足以回答或者问题与上下文无关请明确告知用户无法基于现有信息回答。” 并在测试中反复验证这一机制是否生效。一个总是试图回答所有问题的RAG系统是危险的。尽管RAG解决了知识更新和部分幻觉问题但它本质上还是一个“被动应答”系统。它等待用户提问然后检索-生成答案。对于需要主动规划、执行多步操作、与环境交互的复杂任务我们需要更强大的范式——Agent。4. 第三站Agent——赋予模型“规划与执行”的能力如果说Prompt Engineering是让模型“听懂话”RAG是给模型“喂资料”那么Agent智能体就是让模型“自己动手做事”。一个AI Agent可以被理解为一个由LLM驱动的大脑它能够理解复杂目标自主规划执行步骤调用各种工具如搜索引擎、计算器、API、数据库来完成任务并根据执行结果动态调整计划。4.1 Agent的核心架构思考、行动、观察的循环一个典型的Agent遵循经典的“思考-行动-观察”循环这通常通过ReActReasoning Acting等框架来实现。思考ThoughtAgent分析当前状态包括用户目标、已有信息、历史步骤决定下一步该做什么。是时候调用某个工具了吗还是已经可以给出最终答案了行动Action根据思考的结果Agent执行一个具体的动作。这通常表现为调用一个预定义的工具Tool并传入相应的参数。例如Action: Search[“上海今日天气”]。观察Observation工具执行后返回结果。例如Observation: 上海今日晴气温15-22摄氏度。这个结果会被添加到Agent的上下文记忆中。循环Agent基于新的观察再次进入“思考”阶段决定后续动作如此循环直至任务完成或达到终止条件。这个循环的核心在于LLM不仅用于生成最终答案更用于每一步的推理和决策。它需要理解工具的功能描述、判断何时使用何种工具、解析工具返回的结果并从中提取有价值的信息。4.2 工具使用与规划Agent的“手脚”与“蓝图”Agent的能力边界很大程度上取决于它所能调用的“工具集”。常见的工具包括信息获取工具网络搜索API、数据库查询、企业内部系统API。计算与处理工具计算器、代码解释器可执行Python进行数据分析或图表生成、文档处理工具。控制工具发送邮件、操作日历、控制智能家居通过API。为了让LLM能正确使用工具我们需要以结构化的方式如OpenAI的Function Calling格式或LangChain的Tool定义向模型描述每个工具它的名称、功能描述、所需的参数及其格式。这就像给模型一本工具说明书。对于复杂任务单步思考可能不够Agent需要具备任务分解Task Decomposition和规划Planning的能力。例如用户请求“帮我策划一个周末杭州的旅行计划”。一个具备规划能力的Agent可能会自动分解为“1. 搜索杭州周末的天气。2. 查找杭州热门景点及开放时间。3. 查询上海到杭州的高铁班次。4. 根据景点位置和交通时间排出一个初步日程。5. 估算大致费用。” 然后逐步执行这些子任务。像LangGraph这样的框架就是用来定义和管理这种有状态、多步骤的Agent工作流的。4.3 Agent开发中的核心挑战与应对策略开发一个稳定可靠的Agent远比搭建一个RAG系统更具挑战性。挑战一规划与推理的不可靠性。LLM的规划能力并不完美它可能制定出不合逻辑的步骤或者在多步推理中迷失方向。应对策略包括提供示例Few-Shot Planning在系统提示词中提供几个复杂任务被成功分解和执行的示例引导模型模仿。设置检查点与人工审核对于关键业务流程可以在Agent执行到某些步骤如“准备发送邮件”时暂停将计划或内容提交给人工审核确认。采用更稳健的框架使用如CrewAI、AutoGen等多Agent协作框架让不同的Agent专注于特定角色如规划者、执行者、审核者通过分工协作降低单个Agent出错的概率。挑战二工具调用的精确性。模型可能误解工具描述传错参数格式。除了精心编写工具描述外可以采用验证层在工具被真正调用前用一个简单的规则或轻量级模型对参数进行预校验。或者设计“工具使用确认”环节让Agent在调用关键工具前先将其意图用自然语言描述给用户确认。挑战三长程任务中的记忆与状态管理。Agent在长时间、多步骤的任务中需要记住之前做了什么、得到了什么结果。简单的将全部历史对话放入上下文会很快耗尽Token。因此需要外部记忆Memory系统如向量数据库存储历史关键信息或者总结性记忆将长段历史压缩成摘要。挑战四成本与延迟。Agent的每一步思考、每一次工具调用都可能涉及LLM API调用复杂任务可能导致高昂的成本和较慢的响应速度。需要对非关键路径的思考使用更小、更快的模型并对工具调用结果进行缓存。Agent代表了当前AI应用的前沿它将LLM从一个强大的文本生成器转变为一个可以嵌入真实业务流程、自动完成任务的“数字员工”。从简单的自动化脚本到复杂的决策支持系统Agent的范式正在被广泛应用。5. 技术融合与工程化落地构建下一代AI应用当我们回顾Prompt Engineering、RAG、Agent这三项技术时会发现它们并非相互替代而是层层递进、相互融合的关系。一个成熟的、面向生产的AI应用往往是这三者的有机结合体。5.1 架构模式RAG作为Agent的“记忆体”一个非常强大的模式是“Agent with RAG”。在这个架构中RAG系统充当了Agent的长期、可更新的专属记忆库或知识库。当Agent在执行任务过程中需要查询特定知识如公司制度、产品手册、历史数据时它不是去调用可能不准确或信息滞后的通用搜索引擎而是调用内嵌的RAG模块从权威的内部知识库中获取精准信息。例如一个客户服务Agent在回答用户关于“产品A的保修政策”时其内部流程可能是1. 思考需要查询产品A的保修信息。2. 行动调用内部RAG查询工具输入“产品A 保修期限 条件”。3. 观察RAG返回从最新产品手册中检索到的相关条款。4. 思考整合信息生成对用户友好的回答。5. 行动输出最终答案。这样Agent获得了精准执行的能力而RAG也从一个被动的问答系统升级为主动赋能智能体的知识引擎。5.2 工程化考量超越原型走向生产将AI应用从演示原型推向稳定可靠的生产系统需要跨越巨大的工程鸿沟。评估与监控如何衡量AI应用的效果不能只靠人工抽查。需要建立一套评估体系包括忠实度Faithfulness答案是否严格基于提供的上下文这用于对抗幻觉。相关性Relevance答案是否直接回答了问题毒性/安全性输出内容是否安全合规延迟与成本平均响应时间、每次查询的Token消耗和API成本。 可以设计自动化测试集定期跑分并在生产环境对用户查询和模型输出进行采样分析。稳定性与容错LLM API可能不稳定工具调用可能失败。系统必须有重试机制、降级策略如当主要模型超时时切换至备用模型或返回缓存结果和清晰的错误处理向用户提供友好的错误信息而不是崩溃或输出乱码。可观测性系统必须提供详细的日志记录每一次用户查询、模型的思考过程、工具调用的输入输出、最终响应等。这不仅是调试和排查问题的生命线也是理解模型行为、优化Prompt和工具的关键数据来源。使用LangSmith、Arize AI等专门针对LLM应用的可观测性平台可以极大提升效率。5.3 未来展望更自主、更专业、更集成技术的演进不会停止。当前我们正看到几个清晰的发展趋势Agent能力的深化从单一Agent向多Agent协作Multi-Agent Collaboration发展。不同的Agent扮演不同角色如策划、执行、审核通过辩论、协商共同完成复杂任务这能有效提升任务完成的可靠性和质量。垂直化与专业化通用大模型LLM作为“大脑”底座结合垂直领域的专业工具、工作流和知识库形成行业专属的超级助手。在金融、法律、医疗、编程等领域这种“LLM领域知识领域工具”的范式正在创造巨大价值。与现有软件生态的深度融合AI能力不再是一个独立的聊天窗口而是以“副驾驶”Copilot的形式深度集成到IDE、办公软件、CRM、ERP等所有生产力工具中。通过插件、API、SDKAI将成为软件交互的新一层自然语言界面。从精心设计Prompt与模型对话到为模型连接海量知识库再到赋予模型规划与执行的能力AI应用的技术栈正在快速成熟。这条演进路径的本质是不断拓展LLM的能力边界将其从语言模型逐步升级为能够解决实际问题的“行动模型”。对于开发者而言理解并掌握这条技术链上的每一个环节并能够根据具体场景灵活组合运用是构建有价值、可落地的下一代AI应用的关键。