从提示工程到智能体架构：大模型应用开发实战指南

1. 从“调教”到“驾驭”大模型应用开发的认知跃迁最近和不少从传统开发转过来的朋友聊天发现一个挺有意思的现象很多人一提到大模型应用开发脑子里蹦出来的第一个词就是“提示工程”Prompt Engineering。这没错提示词确实是敲门砖但如果你只停留在“如何写出更好的提示词”这个层面那可能就错过了大模型应用开发最核心、也最迷人的部分。这就像你买了一辆顶级跑车却只学会了怎么用钥匙开门和启动引擎而从未真正踩下油门去感受它澎湃的动力和精准的操控。我自己的实践路径是从最初小心翼翼地“调教”提示词到后来构建能够自主规划、使用工具、持续学习的智能体Agent这个过程让我深刻认识到大模型应用开发的核心认知必须完成一次从“工程”到“架构”的跃迁。今天我就以腾讯的混元大模型作为实践基础和大家完整地走一遍这条路从最基础的提示词撰写到构建一个具备初步自主能力的智能体。你会发现真正的价值不在于让大模型“回答得更好”而在于让它“做得更多、更准、更自动”。2. 基石超越“咒语”的提示工程实战很多人把写提示词比作念“咒语”似乎找到正确的“咒语组合”就能召唤出理想的结果。这种想法其实很危险它把大模型当成了一个黑盒魔法而开发者则成了不断试错的“巫师学徒”。真正的提示工程其内核是清晰、结构化地定义任务边界和思维框架。2.1 从“角色-任务-格式”三角框架开始一个健壮的提示词绝不是一句灵光乍现的提问。我习惯用一个三角框架来构建它角色Role、任务Task、格式Format。这个框架能极大地提升大模型输出的稳定性和可用性。以混元大模型为例假设我们需要它帮忙生成一份产品需求文档PRD的竞品分析部分。反面例子模糊提问“帮我分析一下竞品。” 这种提问方式混元可能会给你一段笼统的、散文式的描述缺乏重点也无法直接用于文档。正面例子三角框架角色你是一名拥有5年经验的互联网产品经理擅长市场分析与竞品调研。 任务针对“智能日程管理App”这个产品方向分析其主要竞品“应用A”和“应用B”。请从核心功能、目标用户、商业模式、用户体验优缺点四个维度进行对比。 格式请以Markdown表格形式输出表格应包含“对比维度”、“应用A”、“应用B”、“我们的潜在机会点”四列。在每个产品的优缺点描述后用标注优势用-标注劣势。为什么这个框架有效角色设定它限定了大模型输出的“人格”和知识背景。让混元扮演“产品经理”它会自然调用与产品分析相关的知识结构和表达方式避免给出过于技术化或市场化的偏颇回答。任务拆解明确了分析对象、维度和比较目标。这相当于给大模型的思考画了一个清晰的路径图避免了其自由发挥导致的偏离。格式要求强制结构化输出。Markdown表格不仅人类阅读友好更重要的是它让输出结果变成了结构化数据。你的后续程序可以轻松解析这个表格将其自动插入文档或导入数据库进行进一步分析。这是提示工程从“给人看”到“给机器用”的关键一步。在实际调用混元API时你可以这样组织消息以常见的OpenAI格式为例messages [ {role: system, content: 你是一名拥有5年经验的互联网产品经理擅长市场分析与竞品调研。}, {role: user, content: 针对‘智能日程管理App’这个产品方向分析其主要竞品‘应用A’和‘应用B’。请从核心功能、目标用户、商业模式、用户体验优缺点四个维度进行对比。\n\n请以Markdown表格形式输出表格应包含‘对比维度’、‘应用A’、‘应用B’、‘我们的潜在机会点’四列。在每个产品的优缺点描述后用标注优势用-标注劣势。} ] # 然后调用混元的 chat.completions.create 类似接口注意system消息中的角色设定非常强大它会在整个会话上下文除非被覆盖中持续生效比在单条用户消息中说明角色更稳定。2.2 思维链Chain-of-Thought与少样本示例Few-Shot的进阶配合对于更复杂的任务比如让混元根据一段用户模糊的需求描述推导出详细的功能列表和技术可行性评估单纯的三角框架可能不够。这时需要引入思维链CoT和少样本示例Few-Shot。思维链是引导大模型“一步步思考”的技术。你不直接问答案而是要求它展示推理过程。少样本示例则是给它一两个输入输出的例子让它“照葫芦画瓢”。实战场景用户说“我想要一个能帮我自动总结每天开会重点并生成待办事项的工具。”基础提问“根据以上需求列出核心功能点。”——输出可能笼统。CoTFew-Shot增强提问请按照以下步骤分析用户需求并生成输出 步骤1解析用户原始陈述提取关键动词和名词。 示例用户说“记录开支并分析趋势”。关键动词记录、分析。关键名词开支、趋势。 步骤2将关键需求转化为具体、可执行的功能模块。 示例对应“记录开支” - “手动记账功能”、“拍照账单OCR识别功能”对应“分析趋势” - “月度支出图表生成”、“超支预警功能”。 步骤3评估每个功能模块的初步技术实现复杂度高/中/低。 现在请分析这个新需求“我想要一个能帮我自动总结每天开会重点并生成待办事项的工具。” 请严格遵循上述三个步骤并以JSON格式输出键名为parsed_keywords, feature_modules, complexity_assessment。通过这个组合拳你不仅得到了更可靠的功能列表还获得了一个结构化的JSON数据。这个JSON可以直接被你后端的任务管理系统读取自动创建产品卡片。这就是提示工程从“交互界面”走向“生产流水线”的体现。我的踩坑心得初期我总想用一个超级复杂的提示词解决所有问题结果往往适得其反模型更容易“精神错乱”。后来我学乖了采用“分而治之”策略用多个简单的、顺序执行的提示词调用替代一个复杂的、要求过多的提示词。比如先调用一次让混元做需求解析再把解析结果作为输入调用第二次让它做技术选型建议。这样每一步的成功率都更高也更容易调试。3. 进化从静态响应到动态交互的智能体构建当你熟练运用提示工程能让混元稳定输出优质内容后下一个问题自然浮现如何让它不仅能“答”还能“做”比如用户问“今天北京天气怎么样”理想的体验不是让混元回答“我不知道我没有实时数据”而是它能自动去调用一个天气查询API获取真实数据后组织语言回复。这就是智能体Agent要解决的问题。智能体的核心是赋予大模型使用工具Tools、进行规划Planning、并基于结果持续执行Execution的能力。它不再是一次性的问答而是一个拥有感知-决策-行动循环的自主系统。3.1 智能体的核心组件工具、记忆、规划构建一个实用的智能体离不开三大核心组件的设计工具Tools这是智能体的“手”和“脚”。工具可以是任何能被API调用的功能搜索引擎、数据库查询、代码执行器、内部业务系统接口等。为混元装配工具本质上是将它的自然语言理解能力转化为对特定功能接口的精确调用。记忆Memory这是智能体“记住过去对话”的关键。记忆分为短期记忆当前会话上下文和长期记忆向量数据库存储的历史重要信息。没有记忆每次对话都是全新的开始智能体就无法进行多轮复杂协作。规划Planning这是智能体的“大脑”。对于复杂任务智能体需要能将其分解为子任务Plan并决定调用哪个工具、按什么顺序执行Action。常见的规划模式有ReAct思考-行动-观察循环、ToT思维树等。3.2 基于混元大模型构建一个查询智能体让我们动手用一个简单但完整的例子演示如何基于混元构建一个能查询天气和股票价格的智能体。这里我们会用到LangChain这个流行的框架来简化流程但原理是通用的。第一步环境准备与工具定义首先你需要安装必要库并准备好混元大模型的API密钥。pip install langchain langchain-community然后我们定义两个简单的工具函数实际应用中这里应调用真实的API# 假设的工具函数 def get_weather(city: str) - str: 根据城市名查询天气。 # 这里应集成真实天气API如和风天气、OpenWeatherMap等 # 为演示返回模拟数据 return f{city}的天气是晴天温度25度。 def get_stock_price(symbol: str) - str: 根据股票代码查询价格。 # 这里应集成真实股票API # 为演示返回模拟数据 return f股票{symbol}的当前价格是100元。 # 使用LangChain的Tool装饰器包装它们 from langchain.tools import tool tool def weather_tool(city: str) - str: 查询指定城市的天气。输入应为城市名如‘北京’。””” return get_weather(city) tool def stock_tool(symbol: str) - str: 查询指定股票代码的当前价格。输入应为股票代码如‘00700’。””” return get_stock_price(symbol)第二步创建混元大模型实例并装配智能体我们需要使用LangChain的混元集成假设已存在或使用兼容OpenAI API的封装。这里以假设的HunyuanChat为例。from langchain_community.chat_models import HunyuanChat # 假设的导入 from langchain.agents import initialize_agent, AgentType from langchain.memory import ConversationBufferMemory # 1. 初始化混元模型 llm HunyuanChat( hunyuan_api_key你的API密钥, model混元-pro, # 指定模型版本 temperature0.1 # 低温度保证输出更确定适合工具调用 ) # 2. 初始化记忆短期会话记忆 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 3. 定义工具列表 tools [weather_tool, stock_tool] # 4. 初始化智能体 # 使用ZERO_SHOT_REACT_DESCRIPTION类型这是一个基于ReAct范式的智能体 agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, memorymemory, verboseTrue, # 开启详细日志方便观察思考过程 handle_parsing_errorsTrue # 优雅处理解析错误 )第三步运行与观察现在让我们向智能体提问。query “先查一下北京天气然后告诉我腾讯控股00700的股价。” result agent.run(query) print(result)当verboseTrue时你会在控制台看到类似以下的思考过程Log这是理解智能体工作的关键 Entering new AgentExecutor chain... 思考用户问了两个问题一个是天气一个是股价。我有查询天气和股票的工具。我应该按顺序执行。 行动我将先使用天气查询工具。 动作{ action: weather_tool, action_input: {city: 北京} } 观察北京的天气是晴天温度25度。 思考我已经回答了第一个问题。现在需要回答第二个关于股票的问题。 动作{ action: stock_tool, action_input: {symbol: 00700} } 观察股票00700的当前价格是100元。 思考我得到了两个信息现在需要组织成最终答案回复用户。 最终答案北京今天的天气是晴天温度25度。腾讯控股00700的当前股价是100元。 Finished chain.这个过程揭示了什么规划与分解智能体识别出这是一个包含两个独立子任务天气、股价的查询。工具选择它正确地分别为每个子任务选择了weather_tool和stock_tool。执行与观察它执行工具调用并接收工具的返回结果作为“观察”。总结与回复最后它综合所有观察组织成一段连贯的自然语言回复给用户。我的踩坑心得工具描述tool装饰器下的文档字符串至关重要混元或其他大模型完全依赖这段描述来决定是否以及何时调用该工具。描述必须精确、无歧义并明确输入参数的格式和含义。初期我写的描述太模糊比如“获取金融数据”结果智能体在需要股价时却错误地调用了这个工具去查汇率。后来我把工具描述改成“查询指定股票代码的当前价格。输入应为股票代码如‘00700’。”问题就解决了。4. 深化智能体的记忆、规划与复杂任务处理基础智能体能处理简单的、线性的任务。但现实世界的需求往往更复杂比如“对比一下北京和上海本周的天气并建议我哪几天更适合出差”。这需要智能体具备更深的记忆和更复杂的规划能力。4.1 为智能体注入长期记忆ConversationBufferMemory只能记住当前会话。要让智能体记住跨会话的信息比如用户偏好就需要长期记忆通常用向量数据库实现。from langchain.embeddings import HuggingFaceEmbeddings # 使用开源嵌入模型 from langchain.vectorstores import Chroma from langchain.text_splitter import CharacterTextSplitter from langchain.docstore.document import Document # 1. 准备一些历史“记忆”文档例如从过去的对话日志中提取 historical_chats [ “用户曾表示喜欢在周五下午进行项目复盘。”, “用户是产品经理经常关注竞品动态和用户体验数据。”, “用户出差常去北京、上海、深圳。” ] documents [Document(page_contenttext) for text in historical_chats] # 2. 分割文本并创建向量存储 text_splitter CharacterTextSplitter(chunk_size500, chunk_overlap50) split_docs text_splitter.split_documents(documents) embeddings HuggingFaceEmbeddings(model_nameall-MiniLM-L6-v2) # 一个小型高效的嵌入模型 vectorstore Chroma.from_documents(split_docs, embeddings) # 3. 将向量存储作为检索器集成到智能体中作为一种特殊的工具或记忆组件 # 这通常通过创建一个“检索工具”来实现让智能体在需要背景信息时主动查询。 from langchain.tools import Tool retriever vectorstore.as_retriever() def retrieve_memory(query: str) - str: docs retriever.get_relevant_documents(query) return \n.join([doc.page_content for doc in docs]) retrieval_tool Tool( nameuser_preference_memory, funcretrieve_memory, description当需要了解用户的历史偏好、习惯或背景信息时使用此工具。输入是一个关于用户的问题或关键词。 ) # 将检索工具也加入智能体的工具列表 tools.append(retrieval_tool) # 重新初始化智能体...现在当用户提出“安排下周的复盘会议”时智能体在规划过程中可能会主动调用user_preference_memory工具查询“用户 复盘 习惯”从而得知用户喜欢周五下午并在建议中体现这一点。4.2 处理复杂任务让智能体学会“拆解”与“反思”对于“对比北京上海本周天气并给出差建议”这种任务我们需要更强大的规划能力。ZERO_SHOT_REACT_DESCRIPTION可能力有不逮。这时可以考虑更高级的Agent类型或者采用Plan-and-Execute架构。Plan-and-Execute 架构的核心思想是用一个“规划者”大模型Planner先把复杂任务拆解成一个清晰的、顺序或并行的子任务列表然后由一个“执行者”大模型Executor或一个标准的智能体去逐个执行这些子任务最后可能还有一个“反思者”来评估结果是否达成目标。我们可以用LangChain的PlanAndExecute代理来简单模拟这个思想from langchain_experimental.plan_and_execute import PlanAndExecute, load_agent_executor, load_chat_planner # 使用混元作为规划者和执行者的大脑 planner load_chat_planner(llm) executor load_agent_executor(llm, tools, verboseTrue) agent PlanAndExecute(plannerplanner, executorexecutor, verboseTrue) complex_query “对比一下北京和上海未来三天的天气并基于天气情况建议我哪一天从北京飞上海出差最合适同时考虑一下我讨厌雨天。” result agent.run(complex_query)在这个架构下规划者可能会生成如下计划调用天气工具获取北京未来三天天气。调用天气工具获取上海未来三天天气。综合分析两地天气找出北京和上海都是非雨天的日期。结合用户“讨厌雨天”的偏好可能从记忆工具中查询或直接从问题中得知给出最终建议。我的踩坑心得复杂智能体的调试是噩梦。当任务失败时你很难定位是规划出错、工具调用出错还是大模型的理解出错。我的经验是开启详细日志verboseTrue是第一步第二步是为关键步骤设置检查点并输出中间结果。例如在规划完成后先把规划列表打印出来看拆解是否合理在每个工具调用后立即验证返回的数据格式是否正确。此外给智能体的任务指令必须极度清晰模糊的指令会导致规划路径混乱。与其说“分析数据”不如说“请先计算A列的平均值再找出B列大于该平均值的所有行最后统计这些行的数量”。5. 工程化智能体应用的开发、评估与部署构建出一个在笔记本里跑通的智能体原型只是第一步。要让它成为一个可靠的生产级应用我们必须考虑工程化问题如何开发、如何评估效果、如何部署服务。5.1 开发范式从LangChain到纯代码编排LangChain等框架极大地降低了入门门槛但它们在复杂生产场景中可能带来额外的抽象层开销和灵活性限制。对于核心业务逻辑非常复杂的智能体我越来越倾向于“纯代码编排”的模式。什么是纯代码编排就是不依赖LangChain的AgentExecutor等高级抽象而是直接用代码Python来显式地控制与大模型的交互、工具调用和流程逻辑。你把自己当作“总调度”混元大模型只是你调度的一个“超级员工”。# 伪代码示例一个手动编排的客服工单分类与路由智能体 import asyncio from my_hunyuan_client import HunyuanClient # 假设的混元SDK from my_tools import classify_ticket, query_knowledge_base, notify_human_agent class CustomerServiceAgent: def __init__(self, api_key): self.llm HunyuanClient(api_key) async def handle_ticket(self, user_query: str, user_history: list): # 步骤1意图分类使用提示工程 classification_prompt f 请将以下用户问题分类{user_query} 可选类别[产品使用, 账单问题, 技术故障, 投诉建议, 人工服务] 只输出类别名称。 category await self.llm.chat(classification_prompt) # 步骤2根据分类执行不同流程 if category in [产品使用, 技术故障]: # 先尝试从知识库找答案 kb_result query_knowledge_base(user_query) if kb_result.confidence 0.8: return kb_result.answer else: # 知识库置信度低需要进一步分析 analysis_prompt f 用户问题{user_query} 初步分类{category} 知识库提供的参考信息{kb_result.snippet} 请进一步分析问题可能的原因并生成一条安抚用户并告知已升级处理的回复。 analysis await self.llm.chat(analysis_prompt) # 异步通知人类客服介入 asyncio.create_task(notify_human_agent(user_query, category)) return analysis elif category 账单问题: # 调用账单查询工具链... pass # ... 其他分类处理 # 步骤3记录本次交互到记忆/数据库 self.save_interaction(user_query, category, final_response) return final_response这种模式的优点是流程透明、完全可控、易于调试和测试。你可以对每一个步骤进行单元测试可以方便地加入重试、降级、熔断等工程机制。缺点是需要自己写更多的胶水代码。我的建议是原型验证阶段用LangChain快速试错一旦核心流程跑通在向生产系统迁移时应认真评估是否要重构为更直接的代码编排模式。5.2 效果评估超越准确率的综合指标体系如何判断你的智能体应用是“好”还是“坏”不能只看最终答案的准确率。我通常从四个维度建立评估体系任务完成度智能体是否理解了用户的全部意图是否完成了所有子任务例如用户要求对比A和B智能体是否只回答了A工具调用准确率在需要调用工具的场景中调用正确工具的比例是多少参数传递是否准确响应质量回复是否准确、有用、无害是否符合业务规范和语气要求效率与成本平均处理一个查询需要调用多少次大模型API即多少轮思考总耗时和Token消耗是多少建立一个评估数据集至关重要。这个数据集应包含典型用户查询覆盖你的智能体设计要处理的主要场景。预期工具调用序列对于每个查询你认为理想的工具调用顺序和参数是什么。预期最终答案/状态任务成功的标准输出是什么。你可以编写自动化脚本用这个数据集定期测试你的智能体并生成上述维度的评估报告。对于无法自动判断的响应质量则需要定期进行人工抽样评估。5.3 部署与监控让智能体稳定服务将智能体部署为API服务时除了常规的Web服务考量如并发、负载均衡、监控还需要特别注意大模型应用的特殊性API密钥与成本管理集中管理混元等大模型的API密钥实施用量监控和成本预警。为不同优先级的请求设置不同的速率限制和模型版本如高优先级用混元-Pro低优先级用混元-Lite。超时与重试大模型API响应时间有波动。必须设置合理的请求超时并对可重试的错误如网络抖动、429过多请求实现退避重试机制。上下文长度管理混元等模型有上下文窗口限制如32K Token。你需要设计策略来修剪或总结过长的对话历史确保不超出限制。长期记忆最好存储在外部向量库只在需要时检索相关片段注入上下文。可观测性在日志中不仅记录输入输出更要记录完整的思维链Chain-of-Thought日志。这是排查问题最宝贵的资料。你需要能看到智能体每一步的“思考”、“行动”和“观察”。兜底与降级当智能体多次尝试后仍失败或遇到无法处理的输入时必须有明确的兜底策略。例如转接给人工客服、返回一个保守但安全的预设回答、或者引导用户换一种方式提问。我的踩坑心得不要低估非功能需求的复杂性。我曾有一个智能体在测试环境表现完美一上生产就频繁超时。排查后发现生产环境的网络延迟和测试环境不同加上用户并发请求导致上下文组装逻辑出现瓶颈。后来我们引入了上下文缓存、优化了向量检索的粒度并设置了更激进的超时降级策略例如如果工具调用超时则跳过该工具直接基于已有信息回复并告知用户部分信息可能缺失。监控方面我们不仅监控API的HTTP状态码更关键的是监控“任务完成率”和“工具调用错误率”这两个业务指标它们能更早地预示智能体是否“生病”了。从精心设计的提示词到能自主使用工具的智能体再到一个稳定、可评估、可运维的生产级应用这条路每一步都充满了挑战但也充满了将想象力变为现实的乐趣。混元大模型作为强大的基座提供了丰富的可能性但最终能创造出什么取决于我们开发者如何将这些核心认知通过扎实的工程实践一步步构建成真正解决用户问题的智能应用。记住最好的学习永远是动手去做从解决一个你自己的具体问题开始。