1. 从零到一AI应用开发的核心思路与工具选型最近几年AI工具的发展速度让人有点跟不上趟。作为一名开发者我明显感觉到单纯调用API写个聊天机器人已经不够看了。市场需要的是能真正理解业务、具备复杂逻辑、甚至能自主规划任务的“智能体”。这背后是开发范式的转变。过去我们写的是“if-else”逻辑现在我们要写的是“意图-规划-执行”的智能流程。为了应对这种变化我花了不少时间研究市面上主流的AI应用开发框架最终把目光锁定在了三个工具上OpenAI的ChatGPT API、微软的Semantic Kernel以及风头正劲的LangChain。这三个工具各有侧重组合起来能覆盖从原型验证到生产部署的完整链路。ChatGPT API是基石提供了强大的语言理解和生成能力。但直接裸用API你会很快遇到瓶颈如何管理复杂的对话上下文如何集成外部工具和知识如何实现稳定的链式调用这时候就需要框架来帮你管理这些复杂性。Semantic KernelSK和LangChain就是为解决这些问题而生的。简单来说SK更像是一个“智能体操作系统”它强调将AI能力称为“技能”像插件一样集成到传统应用中特别适合在.NET生态或需要与现有业务系统深度集成的场景。它的核心概念是“规划器”可以让AI自己决定调用哪些技能来完成一个复杂目标。而LangChain则是一个更“Pythonic”、更专注于构建基于大语言模型LLM的应用程序链的框架。它提供了海量的“链”、“代理”和“工具”组件让你能像搭积木一样快速构建出文档问答、数据分析等应用生态极其丰富。我的选择逻辑是如果你要做的是一个创新型的、以AI为核心驱动的独立应用或者需要快速验证想法LangChain的丰富组件和活跃社区会让你事半功倍。如果你是在一个成熟的企业级应用中尤其是基于C#/ .NET引入AI能力希望AI能安全、可控地调用内部API和数据库那么Semantic Kernel提供的规划能力和与微软生态的天然集成会是更好的选择。当然很多时候并不是二选一理解两者的设计哲学能让你在架构设计时做出更明智的决策。注意工具选型没有绝对的好坏只有是否适合你的场景。在项目早期我建议先用LangChain快速搭建原型验证核心AI流程的可行性。当流程跑通需要向生产环境迁移并考虑安全性、性能和企业集成时再评估是否引入或转向Semantic Kernel来重构核心的编排逻辑。1.1 环境搭建与依赖管理避开第一个坑无论选择哪个框架一个干净、可复现的Python环境是第一步。很多新手会直接在自己的全局Python环境里pip install这会导致后期依赖冲突到怀疑人生。我的做法是为每个AI项目单独创建虚拟环境。对于这个聚焦AI工具整合的项目我创建了一个新的conda环境用venv或pipenv也一样conda create -n ai-apps-course python3.10 conda activate ai-apps-course选择Python 3.10是一个比较稳妥的决定它在稳定性和对新库的兼容性之间取得了很好的平衡。接下来是安装核心依赖。根据课程资料库的提示我们需要同时处理ChatGPT API、Semantic Kernel和LangChain。这里有一个关键的实操心得不要一次性安装所有包而应该分步安装并立即测试基本功能。因为这几个库的依赖树可能很复杂混在一起安装容易出问题。首先安装OpenAI的官方库这是与ChatGPT API对话的基础pip install openai安装后不要急着写代码先在Python交互环境里做个极简测试验证你的API密钥是否有效网络是否通畅import openai openai.api_key 你的-sk-开头的密钥 try: response openai.ChatCompletion.create( modelgpt-3.5-turbo, messages[{role: user, content: Hello, world!}], max_tokens10 ) print(API连接成功) except Exception as e: print(f连接失败: {e})这个测试能帮你排除80%的初期配置问题。接下来安装LangChain。由于它的组件模块很多我建议先安装核心包和与OpenAI相关的接口pip install langchain langchain-openailangchain-openai是LangChain社区维护的OpenAI集成包比直接用通用的langchain.llms更稳定。安装完LangChain后再安装Semantic Kernel。需要注意的是Semantic Kernel有Python和.NET两个版本我们这里当然用Python版pip install semantic-kernel完成以上步骤后你的requirements.txt文件雏形就出来了。我强烈建议使用pip freeze requirements.txt命令生成确切的依赖列表但在这之前可以手动整理一个更清晰、带版本约束的列表便于团队协作openai1.0.0 langchain0.1.0 langchain-openai0.0.5 semantic-kernel0.9.0b1 python-dotenv1.0.0 # 用于管理环境变量这里我特意加上了python-dotenv这是一个至关重要的开发习惯永远不要将API密钥等敏感信息硬编码在代码中。你应该使用.env文件来管理它们。# .env 文件 OPENAI_API_KEYsk-你的真实密钥然后在代码开头通过python-dotenv加载from dotenv import load_dotenv load_dotenv() import os api_key os.getenv(OPENAI_API_KEY)这套环境配置流程虽然看起来繁琐但它能为你后续的开发和调试节省大量时间是专业开发的起点。2. 叩开智能之门深入理解ChatGPT API的编程接口很多开发者对ChatGPT API的理解还停留在“发一个问题得一个回答”的层面。实际上从OpenAI API升级到ChatCompletions格式后它提供的是一个结构化对话管理的能力。理解这一点是你构建复杂AI应用的基础。API的核心是messages参数它是一个字典列表每个字典代表对话中的一条消息包含role和content两个关键字段。role只有三个值system,user,assistant。system角色用于设定AI助手的背景、行为和人格它在整个对话中拥有最高的优先级是控制AI行为最有效的手段。例如你可以这样定义一个翻译官角色messages [ {role: system, content: 你是一位专业的英汉互译专家。请严格翻译用户输入的内容不添加任何额外解释或评论。}, {role: user, content: The relentless pursuit of innovation drives progress.} ]user和assistant则构成了对话的主体。API的设计要求你必须维护一个完整的、交替出现的对话历史。这意味着如果你想进行多轮对话你必须在每次请求时将之前所有的user和assistant消息都带上。例如# 第一轮 messages [{role: user, content: 什么是机器学习}] # 获取assistant回复后假设回复是“机器学习是...” # 第二轮请求时messages必须包含历史 messages [ {role: user, content: 什么是机器学习}, {role: assistant, content: 机器学习是人工智能的一个分支使计算机能够在没有明确编程的情况下学习。}, {role: user, content: 它有哪些主要类型} # 新的用户问题 ]这种设计把对话状态管理的责任完全交给了开发者。好处是灵活你可以实现任何复杂的对话逻辑坏处是你需要自己处理上下文窗口Token数限制的问题。当对话历史太长时你必须决定截断或总结哪些部分这是一个常见的工程挑战。除了messages另一个关键参数是model。目前对于绝大多数应用gpt-3.5-turbo是性价比最高的选择它在响应速度和成本之间取得了最佳平衡。对于需要更强推理能力、代码生成或复杂指令跟随的场景gpt-4或gpt-4-turbo是更好的选择但成本也显著增加。我的经验是在原型阶段统一使用gpt-3.5-turbo仅在最终测试时对关键环节换用gpt-4进行效果对比和优化。temperature和max_tokens是两个直接影响输出结果的参数。temperature控制输出的随机性范围0到2。值越高输出越随机、有创造性值越低输出越确定、保守。对于需要稳定、可重复结果的场景如数据提取、分类设置为0到0.3。对于创意写作、头脑风暴可以设置为0.7到1.0。千万不要忽略这个参数它对你应用效果的稳定性影响巨大。max_tokens则限制AI单次回复的最大长度。你需要根据场景合理设置设置过小会导致回答被截断设置过大会浪费Token费用并可能收到不完整的思考链。提示一个高级技巧是使用streamTrue参数开启流式响应。这对于构建需要实时显示生成过程的聊天界面至关重要能极大提升用户体验。处理流式响应需要稍微不同的代码逻辑但LangChain和Semantic Kernel都对其有很好的封装。2.1 超越简单问答利用Function Calling实现“真”交互ChatGPT API最强大的特性之一是Function Calling函数调用。它彻底改变了AI与外部世界的交互方式。在此之前AI的“知识”和“能力”被禁锢在训练数据截止日之前且无法执行具体操作。Function Calling让AI能够根据对话内容决定是否需要调用你预先定义好的函数工具并生成符合函数参数的调用请求。这个过程分为三步定义工具你告诉AI你有哪些可用的函数每个函数是做什么的需要什么参数。AI决策与请求AI在理解用户请求后判断是否需要调用工具。如果需要它会返回一个标准的JSON对象包含要调用的函数名和具体的参数值。执行与回调你的代码解析这个JSON在本地执行对应的函数可能是查询数据库、调用天气API、发送邮件等然后将函数执行的结果以特定格式再次发给AI。AI整合回复AI收到工具执行的结果后会将这些信息整合生成最终面向用户的自然语言回复。例如你定义了一个get_current_weather的函数描述是“获取指定城市的当前天气”。当用户问“北京天气怎么样”时AI不会去编造天气而是会返回{name: get_current_weather, arguments: {location: Beijing}}。你的程序收到后调用真实天气API拿到数据比如{temperature: 22, condition: sunny}然后将这个结果连同之前的对话历史一起再次发送给AI。AI就会生成“北京目前天气晴朗气温22摄氏度。”这个模式的精妙之处在于AI只负责“思考”和“规划”——决定什么时候、用什么工具、传什么参数。具体的“执行”完全由你的代码控制。这既扩展了AI的能力边界又保证了执行过程的安全和可控。无论是Semantic Kernel的“原生函数”还是LangChain的“Tool”其底层理念都与此一脉相承。掌握Function Calling是构建能真正“做事”的AI应用的关键一步。3. Semantic Kernel实战构建可规划的智能体应用Semantic Kernel的设计哲学非常吸引我它试图将传统编程的确定性与AI的模糊智能结合起来。在SK的世界里一切都被抽象为“技能”。一个“技能”可以是一个纯文本提示词它称之为“语义函数”也可以是一个用C#或Python写的、能执行具体逻辑的“原生函数”。SK的核心工作就是把这些技能连接起来并让一个叫做“规划器”的组件来决定如何组合它们以完成用户的目标。3.1 内核、技能与提示词模板一切始于一个“内核”实例。你可以把它理解为一个技能注册中心和执行引擎。import semantic_kernel as sk from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion # 创建内核 kernel sk.Kernel() # 配置AI服务这里是OpenAI api_key, org_id sk.openai_settings_from_dot_env() kernel.add_chat_service( chat_completion, OpenAIChatCompletion(gpt-3.5-turbo, api_key, org_id) )接下来你可以注册技能。最简单的技能是“语义函数”——本质上就是一个带有变量的提示词模板。SK使用一种叫“SK模板”的语法来定义它们变量用{{$变量名}}表示。# 定义一个自我介绍技能的提示词模板 intro_prompt 你好我是{{$name}}一名{{$role}}。 我的专长领域包括{{$expertise}}。 很高兴为你服务 # 将提示词模板注册为语义函数 intro_function kernel.create_semantic_function( intro_prompt, description根据提供的姓名、角色和专长生成一段自我介绍。 )使用这个函数时你需要提供一个“上下文”对象来填充变量context kernel.create_new_context() context[name] 张伟 context[role] 全栈工程师 context[expertise] Python后端开发、React前端框架和云原生架构 result await intro_function.invoke_async(contextcontext) print(result.result) # 输出你好我是张伟一名全栈工程师...这种将提示词参数化、函数化的做法使得我们可以像管理代码一样管理提示词便于复用和测试。3.2 原生函数与技能编排“原生函数”就是普通的Python函数通过一个装饰器注册到内核里从而能被AI发现和调用。这是实现Function Calling的关键。from semantic_kernel.skill_definition import sk_function class WeatherSkill: sk_function( description获取指定城市的当前温度, nameget_temperature ) def get_temperature(self, city: str) - str: # 这里应该是调用真实天气API的逻辑我们模拟一下 weather_data {北京: 22℃, 上海: 25℃, 深圳: 28℃} return f{city}的当前温度是{weather_data.get(city, 未知)}。 # 将包含原生函数的类作为一个技能导入内核 weather_skill kernel.import_skill(WeatherSkill(), skill_nameWeather)现在内核里就有了一个名为Weather.get_temperature的技能。接下来是神奇的部分规划。SK内置的规划器如SequentialPlanner可以分析用户的目标“北京和上海哪个更热”自动查找内核中可用的技能并生成一个调用这些技能的计划。from semantic_kernel.planning import SequentialPlanner planner SequentialPlanner(kernel) ask 北京和上海哪个更热 plan await planner.create_plan_async(goalask) # 执行这个计划 result await plan.invoke_async() print(result.result) # 输出北京的当前温度是22℃。上海的当前温度是25℃。因此上海比北京更热。在这个过程中规划器会自动决定需要调用Weather.get_temperature两次分别获取北京和上海的温度然后可能再调用一个LLM来比较这两个数值并生成最终答案。你不需要手动编写调用逻辑只需要定义好基础技能规划器会尝试组合它们来解决问题。这对于构建能够处理复杂、多步骤任务的智能体至关重要。注意事项规划器并非万能。它依赖于LLM对目标的理解和对技能描述的匹配。技能的描述description参数必须清晰、准确否则规划器可能无法正确调用。在实际应用中复杂的规划可能失败或效率低下通常需要结合确定性的工作流如预定义的对话流程和规划能力形成混合策略。4. LangChain实战快速构建文档问答与智能代理如果说Semantic Kernel像是一个精心设计的企业级中间件那么LangChain就像一个充满活力的开源工具箱。它的学习曲线起初可能更陡峭因为概念和组件非常多但一旦掌握你构建AI应用的速度会快得惊人。LangChain的核心思想是“链”——将不同的模块LLM调用、提示词模板、工具调用、记忆等连接起来形成一个处理管道。4.1 文档加载、切割与向量化构建知识库的基石让AI回答你私有文档的问题是当前最实用、需求最广的场景之一。其核心技术路线称为“检索增强生成”。整个过程分为离线处理和在线查询两大部分。第一步文档加载与切割LangChain支持超过百种文档加载器从简单的TXT、PDF到Notion、Confluence页面。from langchain.document_loaders import PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档 loader PyPDFLoader(./path/to/your/document.pdf) documents loader.load() # 切割文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个文本块的最大字符数 chunk_overlap50, # 块之间的重叠字符数防止上下文断裂 separators[\n\n, \n, 。, , , , , ] # 中文优先的分隔符 ) split_docs text_splitter.split_documents(documents)这里有几个关键参数的经验值chunk_size不宜过大或过小。过大则包含无关信息影响检索精度过小则丢失上下文影响生成质量。对于通用文档500-1000是个不错的起点。对于代码或结构化文本可以更大。chunk_overlap必须设置。这是保证语义连贯性的关键通常设为chunk_size的10%-20%。separators对于中文文档必须调整分隔符列表将中文标点放在前面这是很多教程忽略但至关重要的一点。第二步向量化与存储切割后的文本需要转换为向量嵌入并存入向量数据库以便后续进行相似度搜索。from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma # 初始化嵌入模型 embeddings OpenAIEmbeddings(openai_api_keyos.getenv(OPENAI_API_KEY)) # 将文档向量化并存入Chroma一个轻量级向量数据库 vectorstore Chroma.from_documents( documentssplit_docs, embeddingembeddings, persist_directory./chroma_db # 指定持久化目录 ) vectorstore.persist() # 保存到磁盘OpenAIEmbeddings会调用OpenAI的文本嵌入接口将每一段文本转换为一个高维向量。这个向量捕捉了文本的语义信息。语义相近的文本其向量在空间中的距离也更近。Chroma是一个本地运行的向量数据库非常适合开发和中小型应用。生产环境可以考虑Weaviate、Pinecone或Qdrant等专业服务。4.2 构建检索链与问答链让AI“引经据典”知识库准备好后就可以构建在线问答系统了。核心是RetrievalQA链。from langchain.chains import RetrievalQA from langchain.chat_models import ChatOpenAI # 初始化LLM llm ChatOpenAI(model_namegpt-3.5-turbo, temperature0, openai_api_keyapi_key) # 从磁盘加载已有的向量库 vectorstore Chroma(persist_directory./chroma_db, embedding_functionembeddings) # 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 检索最相关的4个文本块 # 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 最常用的方式将检索到的文档“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 返回源文档便于调试 chain_type_kwargs{ prompt: PROMPT # 可以自定义提示词控制AI如何利用检索到的上下文 } ) # 进行问答 query 文档中提到的核心项目目标是什么 result qa_chain({query: query}) print(f答案{result[result]}) print(f参考来源{result[source_documents]})这个链的工作流程是自动化的1. 接收用户问题2. 通过retriever从向量库中查找与问题最相关的几个文本片段3. 将这些片段和原始问题一起按照chain_type指定的方式如stuff是简单拼接组合成一个新的提示词4. 发送给LLM生成最终答案。chain_type的选择很有讲究stuff最简单直接将所有检索到的文档内容都放入提示词。优点是信息完整缺点是可能超出Token限制。map_reduce先为每个检索到的文档单独生成一个答案map再将这些答案汇总成一个最终答案reduce。适合处理大量文档但成本高、速度慢。refine迭代式处理用第一个文档生成初始答案然后用后续文档不断精炼和修正这个答案。质量通常较高但调用次数多。map_rerank为每个文档生成答案并打分选择分数最高的。在特定场景下效果好。对于大多数知识库问答stuff方式配合合适的chunk_size和检索数量k已经能取得很好的效果。关键在于设计一个好的提示词PROMPT明确告诉AI“请仅根据提供的上下文信息回答问题如果上下文没有足够信息就回答不知道。” 这能有效防止AI“胡编乱造”。4.3 智能代理让AI自主使用工具LangChain的“代理”是其最强大的概念之一。一个代理一个LLM 一系列工具 决定如何使用这些工具的思考逻辑。这其实就是对OpenAI Function Calling的更高层级封装让你能轻松构建出能自主使用搜索引擎、计算器、数据库的AI助手。from langchain.agents import initialize_agent, AgentType from langchain.agents import load_tools from langchain.llms import OpenAI # 加载工具需要先安装相关包如pip install wikipedia tools load_tools([serpapi, llm-math, wikipedia], llmllm) # 初始化代理 agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 最通用的代理类型 verboseTrue, # 打印思考过程便于调试 handle_parsing_errorsTrue # 优雅处理解析错误 ) # 向代理提问 result agent.run(特斯拉汽车最新的股价是多少这个价格比去年同期上涨了百分之几)当你运行这段代码时如果verboseTrue你会看到类似以下的思考过程Thought: 用户需要特斯拉的最新股价和同比涨幅。我需要先查股价再计算涨幅。我可以使用搜索引擎工具。 Action: Search Action Input: Tesla stock price today Observation: 特斯拉股价为250美元... Thought: 现在我有了当前股价。我还需要一年前的股价来计算涨幅。 Action: Search Action Input: Tesla stock price one year ago Observation: 一年前特斯拉股价为200美元... Thought: 现在我有两个价格。我需要计算涨幅百分比。我可以使用数学工具。 Action: Calculator Action Input: (250 - 200) / 200 * 100 Observation: 25 Thought: 我现在可以给出最终答案了。 Final Answer: 特斯拉当前股价为250美元比一年前的200美元上涨了25%。这就是“ReAct”推理行动框架的体现。代理通过“思考-行动-观察”的循环自主决定调用哪个工具、传入什么参数并整合工具返回的结果最终完成任务。AgentType.ZERO_SHOT_REACT_DESCRIPTION是一种通用的代理它不预设任何具体任务的示例完全依靠LLM对工具描述的理解来决策。对于更复杂的任务可以使用AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION等类型它们能更好地处理多输入参数的工具。实操心得代理虽然强大但也是最不稳定的环节。LLM的思考过程可能出错导致行动选择错误或陷入死循环。在生产环境中使用代理必须设置超时、最大步数限制并做好异常处理。通常对于确定性的、流程清晰的任务使用预定义的“链”更可靠对于需要动态决策、探索性强的任务才使用“代理”。5. 避坑指南与效能优化来自一线的经验在实际开发和部署这些AI应用的过程中我踩过不少坑也总结出一些能显著提升稳定性、效果和性价比的经验。5.1 提示词工程稳定输出的艺术提示词的质量直接决定AI表现的上限。经过大量实践我总结出一个高效的提示词结构我称之为“角色-指令-上下文-格式”四段法角色设定Role明确AI的身份。这能极大地引导其行为模式。例如“你是一位严谨的软件架构师”、“你是一位乐于助人的客服专家”。核心指令Instruction清晰、具体地交代任务。避免模糊用语。使用“请逐步推理”、“请先列出要点再详细阐述”等引导思考过程。上下文信息Context提供完成任务所需的所有背景信息、参考示例或约束条件。在RAG中这就是检索到的文档片段。输出格式Format明确指定输出的格式。例如“请用JSON格式输出包含summary和keywords两个字段。”、“请用Markdown列表呈现。”一个结合了Semantic Kernel模板语法的例子analysis_prompt 你是一位资深技术分析师Role。 请分析以下代码片段指出其潜在的性能瓶颈和安全风险Instruction。 代码片段{{$code_snippet}}Context 请按照以下格式输出Format **性能瓶颈** 1. [具体问题1]解释与建议。 2. [具体问题2]解释与建议。 **安全风险** 1. [具体风险1]解释与修复方案。 此外少样本学习Few-Shot Learning是提升复杂任务准确率的利器。在提示词中提供一两个输入输出的示例能极大地帮助AI理解你的意图和期望的格式。5.2 成本与延迟优化让应用变得实惠可用直接使用GPT-4处理大量文本成本会迅速攀升。优化策略是分层处理路由策略简单的任务如拼写检查、基础分类用更小、更便宜的模型如gpt-3.5-turbo甚至本地小模型。只有复杂的分析、推理、创意任务才路由到GPT-4。缓存策略对频繁出现的、结果确定的查询如“公司的核心价值观是什么”进行缓存。可以使用简单的键值对缓存也可以使用向量相似度缓存即对语义相似的问题返回缓存答案。摘要与压缩在RAG场景中如果检索到的文档块太大可以先让一个小模型或专用摘要模型对其进行摘要再将摘要送入大模型生成答案能有效节省Token。延迟方面除了使用流式响应改善用户体验还可以并行处理如果应用需要调用多个独立的工具或查询多个数据源务必使用异步编程asyncio并行执行而不是串行。设置超时与重试对所有外部API调用LLM、向量库、工具API设置合理的超时时间并实现指数退避的重试机制以提高系统的鲁棒性。5.3 常见错误与排查清单API调用返回权限错误或模型不存在检查项1API密钥是否正确是否设置了环境变量。检查项2你的OpenAI账户是否有该模型的访问权限例如GPT-4 API通常需要单独申请。检查项3模型名称字符串是否拼写正确例如是gpt-3.5-turbo而不是gpt-35-turbo。RAG效果差AI回答“不知道”或胡编乱造检查项1文本切割的chunk_size是否合适过大或过小都会影响检索相关性。尝试调整大小和重叠度。检查项2检索数量k是否足够尝试增加k值让AI看到更多上下文。检查项3提示词是否明确要求AI“基于给定上下文回答”强化这部分指令。检查项4嵌入模型是否合适对于中文可以尝试text-embedding-3-small或专门的多语言/中文嵌入模型。Semantic Kernel规划器无法找到或错误调用技能检查项1技能的描述description是否清晰、无歧义用自然语言准确描述函数的功能和输入。检查项2用户的目标goal描述是否清晰尝试用更具体、更直接的语言重新表述目标。检查项3规划器返回的计划是否合理打开详细日志查看规划器的推理过程。LangChain代理陷入循环或执行无关操作检查项1是否为代理设置了max_iterations最大迭代次数必须设置防止无限循环。检查项2工具的描述是否准确不清晰的描述会导致LLM误解工具用途。检查项3考虑使用更高级的代理类型如STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION它对复杂工具的支持更好。应用处理长文本时速度慢或Token超限检查项1是否在处理前对输入文本进行了长度检查对于超长文本必须实现“截断”或“摘要后再处理”的逻辑。检查项2是否使用了流式处理来逐步输出结果而不是等待全部生成完毕检查项3考虑对历史对话进行摘要。在多轮对话中不要无脑拼接全部历史而是定期将过往对话总结成一段摘要用摘要代替冗长的历史记录。开发AI应用是一个持续迭代和调试的过程。没有一劳永逸的配置最好的方法就是构建一个清晰的评估流程准备一组标准测试问题在每次调整提示词、参数或流程后运行测试集客观地评估效果的变化。将这些经验固化下来你的AI应用就会越来越聪明、可靠。