这一讲解决什么问题从这一讲开始我们进入第二篇LLM 应用基础篇前四讲主要解决“Agent 是什么”和“Agent 技术生态怎么看”的问题。但真正动手构建 Agent 之前还必须先理解大模型调用的基础。因为 Agent 的底层仍然离不开一次又一次模型调用。无论你后面学习的是Tool CallingRAGMemoryWorkflowSkillMCPA2A最终都绕不开一个基础问题如何把用户输入、系统约束、历史上下文、工具结果组织成一次有效的大模型请求这一讲要讲的就是模型调用中最常见、也最容易被低估的几个概念PromptSystem / User / Assistant消息上下文Token模型参数很多初学者会以为 Prompt 就是一句话。例如请你帮我总结这段文字。这当然是 Prompt但在工程系统里Prompt 通常不是一句话而是一组结构化信息。它可能包含系统角色用户问题历史对话外部资料工具结果输出格式要求安全边界当前任务状态也就是说在真实 Agent 系统里Prompt 更像一次“任务上下文打包”。本讲学完后你应该能够理解 Prompt 不只是提示词而是模型输入的一部分区分System、User、Assistant消息的职责理解上下文窗口为什么会限制 Agent 能力知道 Token 如何影响成本、延迟和效果理解常见模型参数的作用和使用场景从开发者角度设计一份清晰、稳定、可维护的模型请求这一讲不追求使用某个具体模型厂商的所有参数细节而是建立通用理解。后续无论你使用 OpenAI、Claude、Gemini、DeepSeek、通义、豆包还是企业内部模型这些基础概念都会反复出现。小白也能懂的类比解释我们先不用技术术语。想象你要请一个助理帮你写一份会议纪要。如果你只说帮我写个会议纪要。助理可能会问会议内容是什么 写给谁看 要正式一点还是口语一点 需要包含待办事项吗 要不要标注负责人这说明一个问题任务描述越模糊输出越不稳定。如果你给助理的信息更完整你是一名专业行政助理。 请根据下面的会议录音整理会议纪要。 要求 1. 使用正式风格。 2. 输出会议背景、讨论要点、决策事项、待办事项。 3. 待办事项要包含负责人和截止时间。 4. 如果资料中没有负责人请标注“待确认”。助理就更容易给出符合预期的结果。这里面其实已经包含了 Prompt 的几个核心元素角色你是一名专业行政助理任务整理会议纪要输入资料会议录音或转写内容输出格式背景、要点、决策、待办约束规则没有负责人时标注待确认再看上下文。如果你和助理前面已经聊过这份纪要是给 CEO 看的。 不要写太长。 重点突出风险和决策。后面你只说继续整理下一段。助理需要记住前面的要求。这些前面说过的信息就是上下文。但人的记忆有限模型也一样。模型不是无限记忆。它只能看到当前请求里放进去的内容。这就是上下文窗口。再看 Token。Token 可以简单理解为模型处理文本时使用的“文本单位”。它不是完全等于汉字也不是完全等于单词。你可以先粗略理解为模型不是按整篇文章一次性理解而是把文本切成很多小块来处理这些小块就是 Token。Token 越多通常意味着请求越长成本越高延迟越大上下文空间占用越多最后是模型参数。如果你让助理写文章可以告诉他写得稳妥一点写得有创意一点最多写 500 字不要废话结果要严格按格式输出这些就类似模型参数。模型参数不是任务内容本身但会影响模型生成方式。一句话总结Prompt 像任务说明书 消息角色像沟通身份 上下文像当前能参考的资料 Token 像文本处理预算 模型参数像生成风格和限制开关核心概念拆解1. Prompt 是什么Prompt 通常被翻译为“提示词”。但在工程场景里把 Prompt 理解成“提示词”还不够。更准确的理解是Prompt 是为了让模型完成任务而组织出来的输入信息。它可以是一句话也可以是一大段结构化内容。一个简单 Prompt请解释什么是 Agent。一个更工程化的 Prompt你是一名面向软件开发者授课的 AI 课程讲师。 任务 解释什么是 Agent。 要求 1. 面向初学者语言通俗。 2. 不使用复杂数学公式。 3. 先用生活类比再给技术解释。 4. 最后给出开发者视角的理解。 输出格式 1. 一句话定义 2. 生活类比 3. 技术拆解 4. 常见误区两者的差异非常明显。前者只告诉模型“做什么”。后者告诉模型扮演什么角色面向谁做什么任务有哪些约束用什么风格按什么格式输出1.1 Prompt 不是魔法咒语很多人刚接触大模型时会把 Prompt 当成“咒语”。他们会不断搜索最强 Prompt万能 Prompt让模型变聪明的 Prompt一句话提升回答质量这类技巧有时有用但不应该成为工程学习的核心。从开发者视角看Prompt 更像接口协议。一个好的 Prompt 应该目标明确输入清晰约束具体输出格式稳定可测试可版本管理如果 Prompt 每次都临时手写就很难维护。在真实项目中Prompt 应该像代码一样被管理。1.2 Prompt 通常包含哪些部分一个比较完整的 Prompt 可以包含角色设定任务说明背景信息输入数据约束规则输出格式示例禁止事项质量标准例如角色 你是一名资深 Python 后端开发工程师。 任务 请审查下面的代码变更找出可能的正确性、性能和安全问题。 背景 这是一个订单服务的接口改动主要影响订单创建流程。 输入 这里放 Git diff 约束 1. 优先指出真实风险不要泛泛而谈。 2. 如果没有明确问题请说明未发现高风险问题。 3. 不要要求大规模重构除非存在明确收益。 输出格式 - 严重级别 - 文件位置 - 问题描述 - 影响 - 修复建议这就是适合工程场景的 Prompt。2. 消息角色System、User、Assistant很多现代大模型 API 不再只接收一个字符串而是接收一组消息。常见结构类似[{role:system,content:你是一个专业的技术课程讲师。},{role:user,content:请解释什么是 Token。}]这里的role表示消息角色。常见角色包括systemuserassistant不同模型厂商可能还有tool、developer等角色但初学阶段先理解这三个就够了。2.1 System 消息system消息通常用于定义模型的整体行为。例如你是一名严谨的软件架构师。 回答时优先考虑工程可落地性。 如果信息不足请先提出需要补充的信息。System 消息适合放角色定位总体风格安全边界长期约束输出原则例如在本课程对应的 Agent 系统中System 消息可以是你是一个面向初学者和开发者的 Agent 课程助手。 请使用通俗语言解释概念避免复杂数学公式。 涉及代码时优先使用 Python 示例。 当用户的问题不明确时先澄清再回答。System 消息不适合频繁塞入大量业务数据。它更像系统级规则。2.2 User 消息user消息代表用户输入。例如请解释 Agent 和 Workflow 的区别。User 消息适合放用户问题用户目标用户提供的资料当前任务输入在多轮对话中每次用户输入通常都会成为一条新的 User 消息。2.3 Assistant 消息assistant消息代表模型之前的回答。它用于保留对话历史。例如[{role:user,content:什么是 Agent},{role:assistant,content:Agent 是一种能够围绕目标调用工具并执行任务的软件系统。},{role:user,content:那它和 Chatbot 有什么区别}]最后一条用户问题中的“它”指的是 Agent。如果没有前面的 Assistant 消息模型可能不知道“它”指什么。所以 Assistant 消息的作用是帮助模型理解对话历史。2.4 消息角色不是装饰初学者容易觉得反正都是文字放在哪里都一样。这不准确。不同角色会影响模型理解优先级和任务结构。一个常见做法是System长期规则 User当前任务 Assistant历史回答不要把所有东西都堆进 User 消息。更好的做法是分层组织。3. 上下文是什么上下文指模型在当前请求中可以看到的信息。它可能包括当前用户问题历史对话系统规则外部检索结果工具返回结果用户画像当前任务状态代码片段文档片段模型不是人类它不会天然记住你所有历史。它只能基于当前请求里的上下文进行生成。这句话非常重要模型能用的信息必须被放进上下文。如果没有放进去模型就只能依靠训练时的知识或猜测。3.1 上下文不是越多越好很多人会想那我把所有资料都塞给模型不就行了吗这也不对。上下文太多会带来几个问题成本变高延迟变大重要信息被淹没模型可能关注错误内容超出上下文窗口限制所以上下文管理的关键不是“塞更多”而是只放当前任务真正需要的信息。这也是 RAG、Memory、上下文压缩存在的原因。3.2 上下文窗口上下文窗口是模型一次请求最多能处理的 Token 数量。你可以把它理解成模型一次能看到的“页面大小”。如果上下文窗口是 128k Token意味着本次请求中输入和输出合计不能超过这个范围。注意这里通常包括System 消息User 消息Assistant 历史工具结果检索资料模型输出如果输入太长可能出现请求失败早期对话被截断输出空间不足成本过高3.3 Agent 中的上下文更复杂普通 Chatbot 的上下文可能只是历史对话。Agent 的上下文通常更复杂。例如一个代码修复 Agent 的上下文可能包括用户目标项目文件结构失败测试日志相关代码片段已经尝试过的修改工具调用结果当前错误信息终止条件如果这些信息组织不好Agent 就会混乱。所以后面讲 Agent 状态管理时我们会继续深入。4. Token 是什么Token 是模型处理文本的基本单位。它可以是一个汉字一个英文单词的一部分一个标点一段常见词组不同模型的分词方式不同。为了学习你不需要记住精确规则先掌握几个工程结论。4.1 Token 影响成本大多数模型调用按 Token 计费。通常会区分输入 Token输出 Token输入越长成本越高。输出越长成本也越高。在 Agent 系统中成本更需要关注因为 Agent 可能会多轮调用模型。例如第 1 次理解任务 第 2 次选择工具 第 3 次总结工具结果 第 4 次继续决策 第 5 次生成最终答案一次用户任务可能触发多次模型调用。4.2 Token 影响延迟Token 越多模型处理时间通常越长。尤其是长输入、长输出场景延迟会明显上升。例如总结 500 字文本很快总结 10 万字文档会慢很多让模型输出一篇长报告也会慢很多如果你要做在线交互产品Token 控制非常重要。4.3 Token 影响效果Token 多不一定效果好。如果你把很多无关资料塞进上下文模型可能会受到干扰。例如用户问请总结订单模块的接口设计。你却把整个项目所有模块的文档都放进去。模型可能会混入支付、库存、物流模块的信息。所以高质量上下文比大上下文更重要。4.4 输出 Token 也要预留空间上下文窗口不是只给输入用的。模型输出也要占 Token。如果你把上下文窗口几乎全部塞满模型可能没有足够空间生成完整回答。例如上下文窗口最大 10000 Token你输入已经用了 9900 Token又要求模型输出 1000 Token系统可能无法满足。这就是为什么工程上要控制输入长度。5. 常见模型参数模型参数会影响生成结果。不同模型 API 参数名称可能略有差异但常见概念类似。这一节先讲最常见的几个。5.1 Temperaturetemperature通常用于控制输出的随机性。简单理解temperature 越低回答越稳定、保守。 temperature 越高回答越发散、有创意。常见使用建议场景建议代码生成较低结构化输出较低事实问答较低文案创意可适当提高头脑风暴可适当提高例如代码审查、SQL 生成、结构化 JSON 输出更适合低 temperature 广告文案、标题创意、故事创作可以使用较高 temperature在 Agent 系统中多数决策场景更适合稳定输出。所以 Agent 的工具选择、参数生成、风险判断通常不建议过于发散。5.2 Max Tokensmax_tokens通常用于限制模型最多输出多少 Token。它不是输入限制而是输出限制。例如max_tokens500表示希望模型最多输出约 500 个 Token。它的作用是控制成本控制输出长度避免模型生成过长内容防止任务失控但设置太小也会有问题。如果你要求模型输出完整报告却把max_tokens设得很低输出可能被截断。5.3 Top Ptop_p也是控制随机性的参数。它和temperature都会影响生成多样性。初学阶段不需要深究数学含义可以先这样理解temperature 控制整体发散程度 top_p 控制候选词范围工程上通常不建议同时大幅调整temperature和top_p。如果没有明确经验先保持默认值。5.4 Stopstop用于告诉模型遇到某些内容时停止输出。例如stop[\n用户]这在某些对话格式、模板生成中有用。但在普通 Chat API 中不一定经常手动使用。5.5 Seed有些模型支持seed用于提高可复现性。但要注意即使设置 seed也不代表所有模型调用都能完全稳定复现。因为还可能受到模型版本、服务端实现、并发环境等影响。5.6 模型选择模型本身也是重要参数。不同模型适合不同任务轻量模型便宜、快适合简单分类、摘要、路由强模型贵、慢但适合复杂推理、代码、规划长上下文模型适合处理长文档多模态模型适合处理图片、音频、视频在 Agent 系统中不一定所有步骤都用最强模型。例如任务分类轻量模型 工具参数提取轻量或中等模型 复杂分析强模型 最终总结中等或强模型这种分层使用可以控制成本。一次模型请求通常包含什么从工程视角看一次模型请求通常包含模型名称消息列表参数设置工具定义输出格式要求超时和重试策略请求标识日志追踪信息一个简化结构如下{model:some-llm-model,messages:[{role:system,content:你是一个专业的软件开发课程讲师。},{role:user,content:请解释 Prompt、上下文和 Token 的区别。}],temperature:0.3,max_tokens:1200}对于普通问答来说这已经够了。对于 Agent 来说请求会更复杂。例如{model:some-llm-model,messages:[{role:system,content:你是一个研发助手 Agent请在安全边界内帮助用户完成任务。},{role:user,content:帮我分析订单服务接口超时原因。},{role:assistant,content:我需要先确认服务名称、时间范围和是否允许查询日志。},{role:user,content:服务是 order-service时间范围是最近 30 分钟可以查询日志。}],tools:[{name:query_logs,description:查询指定服务在指定时间范围内的日志。}],temperature:0.2,max_tokens:1500}这里已经包含了系统规则用户目标历史对话授权信息可用工具参数设置这就是 Agent 请求复杂的原因。Prompt 设计的基本原则1. 明确角色角色不是为了好玩而是帮助模型确定回答视角。例如你是一名面向初学者的 AI 课程讲师。和你是一名资深后端架构师。这两个角色会产生不同回答风格。前者更通俗。后者更工程化。2. 明确任务任务要具体。不好的写法帮我看看这个。更好的写法请审查下面这段 Python 代码重点关注异常处理、性能问题和潜在安全风险。3. 明确输入边界如果你提供了资料要告诉模型资料在哪里。例如下面 document 标签中的内容是需要总结的原文。 请只基于这部分内容回答。 document ... /document这样可以减少模型把指令和资料混淆。4. 明确输出格式模型自然语言输出很灵活。但工程系统通常需要稳定格式。例如请按以下格式输出 ## 总结 ## 关键风险 ## 建议下一步如果后续程序要解析输出更应该使用 JSON 或结构化格式。这个内容会在第 7 讲详细展开。5. 明确禁止事项在高风险场景中要写清楚不能做什么。例如如果资料中没有明确证据不要编造结论。 如果无法判断请回答“当前信息不足无法确认”。 不要输出任何未脱敏的敏感信息。这些约束不能替代系统权限控制但能帮助模型减少不合规输出。6. 给出示例有时示例比解释更有效。例如你希望模型输出固定格式可以给一个示例示例输出 问题缺少超时处理 位置order_client.py:42 影响下游接口卡住时可能拖慢整个请求链路 建议为 HTTP 请求增加超时参数并处理超时异常示例能帮助模型学习你想要的输出风格。开发者视角的系统设计从开发者视角看不应该把 Prompt 写散在业务代码里。例如不建议到处写prompt你是一个助手请回答用户问题user_input这种写法短期能跑但长期会遇到问题Prompt 难以复用难以版本管理难以测试难以审查难以定位效果变化原因更好的做法是把 Prompt 当成工程资产管理。1. Prompt 模板化例如你是一名{role}。 任务 {task} 背景 {background} 输入 {input} 输出要求 {output_requirements}模板化后不同任务可以复用结构。2. Prompt 版本管理Prompt 改动可能影响系统效果。所以应该记录版本。例如code_review_prompt_v1 code_review_prompt_v2 incident_analysis_prompt_v1当线上效果变化时至少能知道当前使用哪个版本改动了什么是否需要回滚3. Prompt 与业务逻辑分离Prompt 应该尽量与业务代码分离。例如prompts/ ├── code_review.md ├── incident_analysis.md └── doc_summary.md或者存储在配置系统中。这样产品、运营、算法、工程团队可以更清晰地协作。4. 上下文组装层Agent 系统中真正复杂的不是写一句 Prompt而是组装上下文。例如代码审查 Agent 需要组装用户要求Git diff相关文件项目规范历史讨论输出格式可以设计一个上下文构建函数defbuild_code_review_context(user_request,diff,related_files,guidelines):return{user_request:user_request,diff:diff,related_files:related_files,guidelines:guidelines,}这个函数的职责不是调用模型而是准备模型需要看的信息。5. Token 预算管理Agent 系统应该有 Token 预算意识。例如系统规则1000 Token 用户问题500 Token 历史对话2000 Token 检索资料6000 Token 工具结果3000 Token 预留输出2000 Token如果总预算有限就要决定哪些历史对话可以压缩哪些资料最相关哪些工具结果需要摘要输出长度应该限制多少这就是上下文工程。Python 示例或伪代码下面用 Python 伪代码演示几个关键思想。1. 构造基础消息defbuild_messages(user_question:str)-list[dict]:return[{role:system,content:你是一个面向初学者和开发者的 Agent 课程助手。,},{role:user,content:user_question,},]这里把系统规则和用户问题分开。这比直接拼成一个字符串更清晰。2. 使用 Prompt 模板defrender_prompt(task:str,background:str,output_format:str)-str:returnf 任务{task}背景{background}输出格式{output_format}.strip()模板的好处是结构稳定。后续如果要修改输出格式只需要调整模板而不是到处改业务代码。3. 控制历史上下文长度deftrim_history(messages:list[dict],max_messages:int10)-list[dict]:system_messages[msgformsginmessagesifmsg[role]system]other_messages[msgformsginmessagesifmsg[role]!system]# 关键逻辑保留系统规则再保留最近的对话历史returnsystem_messagesother_messages[-max_messages:]这只是一个简化示例。真实系统中不能只按消息数量裁剪还要按 Token 数、重要性和任务状态处理。4. 简单 Token 预算估算defestimate_token_count(text:str)-int:# 简化估算真实项目应使用模型对应的 tokenizerreturnmax(1,len(text)//2)这里不是精确计算只是提醒你上下文长度需要被管理而不是无限增长。5. 按场景设置参数defget_model_params(task_type:str)-dict:iftask_typestructured_output:return{temperature:0.1,max_tokens:1000,}iftask_typecreative_writing:return{temperature:0.8,max_tokens:1500,}return{temperature:0.3,max_tokens:1200,}参数应该根据任务类型选择而不是所有场景一套配置。6. 组装一次模型请求defbuild_llm_request(user_question:str,task_type:str)-dict:messagesbuild_messages(user_question)paramsget_model_params(task_type)return{model:your-model-name,messages:messages,**params,}这就是一个最小的请求组装层。后续第 6 讲会继续扩展如何发送请求如何处理超时如何记录日志如何做重试如何追踪成本典型场景判断场景 1写广告文案用户希望生成 10 个有创意的广告标题。更适合较高 temperature 较宽松输出格式 允许多样化表达因为这个任务需要创意。场景 2生成 JSON 配置用户希望模型输出一段程序可以解析的 JSON。更适合较低 temperature 严格输出格式 明确字段约束 最好配合结构化输出能力因为这个任务需要稳定不需要发散。场景 3总结长文档用户希望总结一篇长文档。需要重点关注上下文窗口 Token 成本 文档切分 摘要策略 输出长度限制如果文档太长不应该直接全部塞进请求。可以先分段摘要再汇总。场景 4多轮客服对话用户连续多轮咨询问题。需要重点关注历史对话保留 用户当前意图 关键信息提取 无关历史压缩不是所有历史都要原样保留。场景 5Agent 调用工具前的决策Agent 需要判断是否调用工具。更适合低 temperature 明确工具描述 明确风险边界 结构化决策输出因为工具调用前的决策不应该过于发散。常见误区误区 1Prompt 越长越好Prompt 不是越长越好。长 Prompt 可能包含更多约束但也可能引入噪声。好的 Prompt 是清晰、必要、可执行。误区 2把所有历史对话都塞进去保留全部历史会增加成本也可能干扰模型。更好的做法是保留当前任务相关信息压缩历史摘要结构化保存关键状态误区 3Token 只影响价格Token 不只影响价格。它还影响延迟上下文容量输出完整性模型关注重点误区 4Temperature 越高模型越聪明Temperature 控制随机性不代表智能水平。高 temperature 可能让回答更有创意也可能更不稳定。对于代码、工具调用、结构化输出通常不适合太高。误区 5System 消息可以解决所有安全问题System 消息可以表达规则但不能替代权限控制。例如你写不要泄露敏感信息。这有帮助但不够。系统仍然需要数据脱敏权限校验工具白名单审计记录误区 6模型会自动记住所有信息模型不会自动记住你所有历史。如果信息没有放进当前上下文模型不一定知道。长期记忆需要系统设计不能依赖模型“自己记得”。误区 7参数配置可以一劳永逸不同任务需要不同参数。同一套参数不可能适合所有场景。工程系统中应该按任务类型、风险等级、输出要求选择参数。本讲小结这一讲我们学习了 LLM 调用中的几个基础概念。可以这样记Prompt为了完成任务而组织出来的输入信息 System系统级规则和长期约束 User用户当前输入或目标 Assistant模型历史回答 上下文模型本次请求中能看到的全部信息 Token模型处理文本的基本单位也影响成本和延迟 模型参数控制生成风格、长度和稳定性的配置本讲最重要的观点是在工程系统中Prompt 不是一句提示词而是一次上下文组织。对于初学者来说要先理解告诉模型什么信息模型才可能基于什么信息回答。对于开发者来说要进一步建立工程意识Prompt 要模板化 上下文要管理 Token 要预算 参数要按场景设置 输出要可控后续课程会在这个基础上继续深入。下一讲会讲一次 LLM 调用的完整过程我们会从工程链路角度看清楚用户输入如何变成模型请求模型如何返回结果请求失败怎么办超时和限流怎么处理日志和调用追踪怎么设计理解了这些才能真正把模型调用接入到一个可靠的软件系统里。
第 5 讲：Prompt、上下文、Token、模型参数
这一讲解决什么问题从这一讲开始我们进入第二篇LLM 应用基础篇前四讲主要解决“Agent 是什么”和“Agent 技术生态怎么看”的问题。但真正动手构建 Agent 之前还必须先理解大模型调用的基础。因为 Agent 的底层仍然离不开一次又一次模型调用。无论你后面学习的是Tool CallingRAGMemoryWorkflowSkillMCPA2A最终都绕不开一个基础问题如何把用户输入、系统约束、历史上下文、工具结果组织成一次有效的大模型请求这一讲要讲的就是模型调用中最常见、也最容易被低估的几个概念PromptSystem / User / Assistant消息上下文Token模型参数很多初学者会以为 Prompt 就是一句话。例如请你帮我总结这段文字。这当然是 Prompt但在工程系统里Prompt 通常不是一句话而是一组结构化信息。它可能包含系统角色用户问题历史对话外部资料工具结果输出格式要求安全边界当前任务状态也就是说在真实 Agent 系统里Prompt 更像一次“任务上下文打包”。本讲学完后你应该能够理解 Prompt 不只是提示词而是模型输入的一部分区分System、User、Assistant消息的职责理解上下文窗口为什么会限制 Agent 能力知道 Token 如何影响成本、延迟和效果理解常见模型参数的作用和使用场景从开发者角度设计一份清晰、稳定、可维护的模型请求这一讲不追求使用某个具体模型厂商的所有参数细节而是建立通用理解。后续无论你使用 OpenAI、Claude、Gemini、DeepSeek、通义、豆包还是企业内部模型这些基础概念都会反复出现。小白也能懂的类比解释我们先不用技术术语。想象你要请一个助理帮你写一份会议纪要。如果你只说帮我写个会议纪要。助理可能会问会议内容是什么 写给谁看 要正式一点还是口语一点 需要包含待办事项吗 要不要标注负责人这说明一个问题任务描述越模糊输出越不稳定。如果你给助理的信息更完整你是一名专业行政助理。 请根据下面的会议录音整理会议纪要。 要求 1. 使用正式风格。 2. 输出会议背景、讨论要点、决策事项、待办事项。 3. 待办事项要包含负责人和截止时间。 4. 如果资料中没有负责人请标注“待确认”。助理就更容易给出符合预期的结果。这里面其实已经包含了 Prompt 的几个核心元素角色你是一名专业行政助理任务整理会议纪要输入资料会议录音或转写内容输出格式背景、要点、决策、待办约束规则没有负责人时标注待确认再看上下文。如果你和助理前面已经聊过这份纪要是给 CEO 看的。 不要写太长。 重点突出风险和决策。后面你只说继续整理下一段。助理需要记住前面的要求。这些前面说过的信息就是上下文。但人的记忆有限模型也一样。模型不是无限记忆。它只能看到当前请求里放进去的内容。这就是上下文窗口。再看 Token。Token 可以简单理解为模型处理文本时使用的“文本单位”。它不是完全等于汉字也不是完全等于单词。你可以先粗略理解为模型不是按整篇文章一次性理解而是把文本切成很多小块来处理这些小块就是 Token。Token 越多通常意味着请求越长成本越高延迟越大上下文空间占用越多最后是模型参数。如果你让助理写文章可以告诉他写得稳妥一点写得有创意一点最多写 500 字不要废话结果要严格按格式输出这些就类似模型参数。模型参数不是任务内容本身但会影响模型生成方式。一句话总结Prompt 像任务说明书 消息角色像沟通身份 上下文像当前能参考的资料 Token 像文本处理预算 模型参数像生成风格和限制开关核心概念拆解1. Prompt 是什么Prompt 通常被翻译为“提示词”。但在工程场景里把 Prompt 理解成“提示词”还不够。更准确的理解是Prompt 是为了让模型完成任务而组织出来的输入信息。它可以是一句话也可以是一大段结构化内容。一个简单 Prompt请解释什么是 Agent。一个更工程化的 Prompt你是一名面向软件开发者授课的 AI 课程讲师。 任务 解释什么是 Agent。 要求 1. 面向初学者语言通俗。 2. 不使用复杂数学公式。 3. 先用生活类比再给技术解释。 4. 最后给出开发者视角的理解。 输出格式 1. 一句话定义 2. 生活类比 3. 技术拆解 4. 常见误区两者的差异非常明显。前者只告诉模型“做什么”。后者告诉模型扮演什么角色面向谁做什么任务有哪些约束用什么风格按什么格式输出1.1 Prompt 不是魔法咒语很多人刚接触大模型时会把 Prompt 当成“咒语”。他们会不断搜索最强 Prompt万能 Prompt让模型变聪明的 Prompt一句话提升回答质量这类技巧有时有用但不应该成为工程学习的核心。从开发者视角看Prompt 更像接口协议。一个好的 Prompt 应该目标明确输入清晰约束具体输出格式稳定可测试可版本管理如果 Prompt 每次都临时手写就很难维护。在真实项目中Prompt 应该像代码一样被管理。1.2 Prompt 通常包含哪些部分一个比较完整的 Prompt 可以包含角色设定任务说明背景信息输入数据约束规则输出格式示例禁止事项质量标准例如角色 你是一名资深 Python 后端开发工程师。 任务 请审查下面的代码变更找出可能的正确性、性能和安全问题。 背景 这是一个订单服务的接口改动主要影响订单创建流程。 输入 这里放 Git diff 约束 1. 优先指出真实风险不要泛泛而谈。 2. 如果没有明确问题请说明未发现高风险问题。 3. 不要要求大规模重构除非存在明确收益。 输出格式 - 严重级别 - 文件位置 - 问题描述 - 影响 - 修复建议这就是适合工程场景的 Prompt。2. 消息角色System、User、Assistant很多现代大模型 API 不再只接收一个字符串而是接收一组消息。常见结构类似[{role:system,content:你是一个专业的技术课程讲师。},{role:user,content:请解释什么是 Token。}]这里的role表示消息角色。常见角色包括systemuserassistant不同模型厂商可能还有tool、developer等角色但初学阶段先理解这三个就够了。2.1 System 消息system消息通常用于定义模型的整体行为。例如你是一名严谨的软件架构师。 回答时优先考虑工程可落地性。 如果信息不足请先提出需要补充的信息。System 消息适合放角色定位总体风格安全边界长期约束输出原则例如在本课程对应的 Agent 系统中System 消息可以是你是一个面向初学者和开发者的 Agent 课程助手。 请使用通俗语言解释概念避免复杂数学公式。 涉及代码时优先使用 Python 示例。 当用户的问题不明确时先澄清再回答。System 消息不适合频繁塞入大量业务数据。它更像系统级规则。2.2 User 消息user消息代表用户输入。例如请解释 Agent 和 Workflow 的区别。User 消息适合放用户问题用户目标用户提供的资料当前任务输入在多轮对话中每次用户输入通常都会成为一条新的 User 消息。2.3 Assistant 消息assistant消息代表模型之前的回答。它用于保留对话历史。例如[{role:user,content:什么是 Agent},{role:assistant,content:Agent 是一种能够围绕目标调用工具并执行任务的软件系统。},{role:user,content:那它和 Chatbot 有什么区别}]最后一条用户问题中的“它”指的是 Agent。如果没有前面的 Assistant 消息模型可能不知道“它”指什么。所以 Assistant 消息的作用是帮助模型理解对话历史。2.4 消息角色不是装饰初学者容易觉得反正都是文字放在哪里都一样。这不准确。不同角色会影响模型理解优先级和任务结构。一个常见做法是System长期规则 User当前任务 Assistant历史回答不要把所有东西都堆进 User 消息。更好的做法是分层组织。3. 上下文是什么上下文指模型在当前请求中可以看到的信息。它可能包括当前用户问题历史对话系统规则外部检索结果工具返回结果用户画像当前任务状态代码片段文档片段模型不是人类它不会天然记住你所有历史。它只能基于当前请求里的上下文进行生成。这句话非常重要模型能用的信息必须被放进上下文。如果没有放进去模型就只能依靠训练时的知识或猜测。3.1 上下文不是越多越好很多人会想那我把所有资料都塞给模型不就行了吗这也不对。上下文太多会带来几个问题成本变高延迟变大重要信息被淹没模型可能关注错误内容超出上下文窗口限制所以上下文管理的关键不是“塞更多”而是只放当前任务真正需要的信息。这也是 RAG、Memory、上下文压缩存在的原因。3.2 上下文窗口上下文窗口是模型一次请求最多能处理的 Token 数量。你可以把它理解成模型一次能看到的“页面大小”。如果上下文窗口是 128k Token意味着本次请求中输入和输出合计不能超过这个范围。注意这里通常包括System 消息User 消息Assistant 历史工具结果检索资料模型输出如果输入太长可能出现请求失败早期对话被截断输出空间不足成本过高3.3 Agent 中的上下文更复杂普通 Chatbot 的上下文可能只是历史对话。Agent 的上下文通常更复杂。例如一个代码修复 Agent 的上下文可能包括用户目标项目文件结构失败测试日志相关代码片段已经尝试过的修改工具调用结果当前错误信息终止条件如果这些信息组织不好Agent 就会混乱。所以后面讲 Agent 状态管理时我们会继续深入。4. Token 是什么Token 是模型处理文本的基本单位。它可以是一个汉字一个英文单词的一部分一个标点一段常见词组不同模型的分词方式不同。为了学习你不需要记住精确规则先掌握几个工程结论。4.1 Token 影响成本大多数模型调用按 Token 计费。通常会区分输入 Token输出 Token输入越长成本越高。输出越长成本也越高。在 Agent 系统中成本更需要关注因为 Agent 可能会多轮调用模型。例如第 1 次理解任务 第 2 次选择工具 第 3 次总结工具结果 第 4 次继续决策 第 5 次生成最终答案一次用户任务可能触发多次模型调用。4.2 Token 影响延迟Token 越多模型处理时间通常越长。尤其是长输入、长输出场景延迟会明显上升。例如总结 500 字文本很快总结 10 万字文档会慢很多让模型输出一篇长报告也会慢很多如果你要做在线交互产品Token 控制非常重要。4.3 Token 影响效果Token 多不一定效果好。如果你把很多无关资料塞进上下文模型可能会受到干扰。例如用户问请总结订单模块的接口设计。你却把整个项目所有模块的文档都放进去。模型可能会混入支付、库存、物流模块的信息。所以高质量上下文比大上下文更重要。4.4 输出 Token 也要预留空间上下文窗口不是只给输入用的。模型输出也要占 Token。如果你把上下文窗口几乎全部塞满模型可能没有足够空间生成完整回答。例如上下文窗口最大 10000 Token你输入已经用了 9900 Token又要求模型输出 1000 Token系统可能无法满足。这就是为什么工程上要控制输入长度。5. 常见模型参数模型参数会影响生成结果。不同模型 API 参数名称可能略有差异但常见概念类似。这一节先讲最常见的几个。5.1 Temperaturetemperature通常用于控制输出的随机性。简单理解temperature 越低回答越稳定、保守。 temperature 越高回答越发散、有创意。常见使用建议场景建议代码生成较低结构化输出较低事实问答较低文案创意可适当提高头脑风暴可适当提高例如代码审查、SQL 生成、结构化 JSON 输出更适合低 temperature 广告文案、标题创意、故事创作可以使用较高 temperature在 Agent 系统中多数决策场景更适合稳定输出。所以 Agent 的工具选择、参数生成、风险判断通常不建议过于发散。5.2 Max Tokensmax_tokens通常用于限制模型最多输出多少 Token。它不是输入限制而是输出限制。例如max_tokens500表示希望模型最多输出约 500 个 Token。它的作用是控制成本控制输出长度避免模型生成过长内容防止任务失控但设置太小也会有问题。如果你要求模型输出完整报告却把max_tokens设得很低输出可能被截断。5.3 Top Ptop_p也是控制随机性的参数。它和temperature都会影响生成多样性。初学阶段不需要深究数学含义可以先这样理解temperature 控制整体发散程度 top_p 控制候选词范围工程上通常不建议同时大幅调整temperature和top_p。如果没有明确经验先保持默认值。5.4 Stopstop用于告诉模型遇到某些内容时停止输出。例如stop[\n用户]这在某些对话格式、模板生成中有用。但在普通 Chat API 中不一定经常手动使用。5.5 Seed有些模型支持seed用于提高可复现性。但要注意即使设置 seed也不代表所有模型调用都能完全稳定复现。因为还可能受到模型版本、服务端实现、并发环境等影响。5.6 模型选择模型本身也是重要参数。不同模型适合不同任务轻量模型便宜、快适合简单分类、摘要、路由强模型贵、慢但适合复杂推理、代码、规划长上下文模型适合处理长文档多模态模型适合处理图片、音频、视频在 Agent 系统中不一定所有步骤都用最强模型。例如任务分类轻量模型 工具参数提取轻量或中等模型 复杂分析强模型 最终总结中等或强模型这种分层使用可以控制成本。一次模型请求通常包含什么从工程视角看一次模型请求通常包含模型名称消息列表参数设置工具定义输出格式要求超时和重试策略请求标识日志追踪信息一个简化结构如下{model:some-llm-model,messages:[{role:system,content:你是一个专业的软件开发课程讲师。},{role:user,content:请解释 Prompt、上下文和 Token 的区别。}],temperature:0.3,max_tokens:1200}对于普通问答来说这已经够了。对于 Agent 来说请求会更复杂。例如{model:some-llm-model,messages:[{role:system,content:你是一个研发助手 Agent请在安全边界内帮助用户完成任务。},{role:user,content:帮我分析订单服务接口超时原因。},{role:assistant,content:我需要先确认服务名称、时间范围和是否允许查询日志。},{role:user,content:服务是 order-service时间范围是最近 30 分钟可以查询日志。}],tools:[{name:query_logs,description:查询指定服务在指定时间范围内的日志。}],temperature:0.2,max_tokens:1500}这里已经包含了系统规则用户目标历史对话授权信息可用工具参数设置这就是 Agent 请求复杂的原因。Prompt 设计的基本原则1. 明确角色角色不是为了好玩而是帮助模型确定回答视角。例如你是一名面向初学者的 AI 课程讲师。和你是一名资深后端架构师。这两个角色会产生不同回答风格。前者更通俗。后者更工程化。2. 明确任务任务要具体。不好的写法帮我看看这个。更好的写法请审查下面这段 Python 代码重点关注异常处理、性能问题和潜在安全风险。3. 明确输入边界如果你提供了资料要告诉模型资料在哪里。例如下面 document 标签中的内容是需要总结的原文。 请只基于这部分内容回答。 document ... /document这样可以减少模型把指令和资料混淆。4. 明确输出格式模型自然语言输出很灵活。但工程系统通常需要稳定格式。例如请按以下格式输出 ## 总结 ## 关键风险 ## 建议下一步如果后续程序要解析输出更应该使用 JSON 或结构化格式。这个内容会在第 7 讲详细展开。5. 明确禁止事项在高风险场景中要写清楚不能做什么。例如如果资料中没有明确证据不要编造结论。 如果无法判断请回答“当前信息不足无法确认”。 不要输出任何未脱敏的敏感信息。这些约束不能替代系统权限控制但能帮助模型减少不合规输出。6. 给出示例有时示例比解释更有效。例如你希望模型输出固定格式可以给一个示例示例输出 问题缺少超时处理 位置order_client.py:42 影响下游接口卡住时可能拖慢整个请求链路 建议为 HTTP 请求增加超时参数并处理超时异常示例能帮助模型学习你想要的输出风格。开发者视角的系统设计从开发者视角看不应该把 Prompt 写散在业务代码里。例如不建议到处写prompt你是一个助手请回答用户问题user_input这种写法短期能跑但长期会遇到问题Prompt 难以复用难以版本管理难以测试难以审查难以定位效果变化原因更好的做法是把 Prompt 当成工程资产管理。1. Prompt 模板化例如你是一名{role}。 任务 {task} 背景 {background} 输入 {input} 输出要求 {output_requirements}模板化后不同任务可以复用结构。2. Prompt 版本管理Prompt 改动可能影响系统效果。所以应该记录版本。例如code_review_prompt_v1 code_review_prompt_v2 incident_analysis_prompt_v1当线上效果变化时至少能知道当前使用哪个版本改动了什么是否需要回滚3. Prompt 与业务逻辑分离Prompt 应该尽量与业务代码分离。例如prompts/ ├── code_review.md ├── incident_analysis.md └── doc_summary.md或者存储在配置系统中。这样产品、运营、算法、工程团队可以更清晰地协作。4. 上下文组装层Agent 系统中真正复杂的不是写一句 Prompt而是组装上下文。例如代码审查 Agent 需要组装用户要求Git diff相关文件项目规范历史讨论输出格式可以设计一个上下文构建函数defbuild_code_review_context(user_request,diff,related_files,guidelines):return{user_request:user_request,diff:diff,related_files:related_files,guidelines:guidelines,}这个函数的职责不是调用模型而是准备模型需要看的信息。5. Token 预算管理Agent 系统应该有 Token 预算意识。例如系统规则1000 Token 用户问题500 Token 历史对话2000 Token 检索资料6000 Token 工具结果3000 Token 预留输出2000 Token如果总预算有限就要决定哪些历史对话可以压缩哪些资料最相关哪些工具结果需要摘要输出长度应该限制多少这就是上下文工程。Python 示例或伪代码下面用 Python 伪代码演示几个关键思想。1. 构造基础消息defbuild_messages(user_question:str)-list[dict]:return[{role:system,content:你是一个面向初学者和开发者的 Agent 课程助手。,},{role:user,content:user_question,},]这里把系统规则和用户问题分开。这比直接拼成一个字符串更清晰。2. 使用 Prompt 模板defrender_prompt(task:str,background:str,output_format:str)-str:returnf 任务{task}背景{background}输出格式{output_format}.strip()模板的好处是结构稳定。后续如果要修改输出格式只需要调整模板而不是到处改业务代码。3. 控制历史上下文长度deftrim_history(messages:list[dict],max_messages:int10)-list[dict]:system_messages[msgformsginmessagesifmsg[role]system]other_messages[msgformsginmessagesifmsg[role]!system]# 关键逻辑保留系统规则再保留最近的对话历史returnsystem_messagesother_messages[-max_messages:]这只是一个简化示例。真实系统中不能只按消息数量裁剪还要按 Token 数、重要性和任务状态处理。4. 简单 Token 预算估算defestimate_token_count(text:str)-int:# 简化估算真实项目应使用模型对应的 tokenizerreturnmax(1,len(text)//2)这里不是精确计算只是提醒你上下文长度需要被管理而不是无限增长。5. 按场景设置参数defget_model_params(task_type:str)-dict:iftask_typestructured_output:return{temperature:0.1,max_tokens:1000,}iftask_typecreative_writing:return{temperature:0.8,max_tokens:1500,}return{temperature:0.3,max_tokens:1200,}参数应该根据任务类型选择而不是所有场景一套配置。6. 组装一次模型请求defbuild_llm_request(user_question:str,task_type:str)-dict:messagesbuild_messages(user_question)paramsget_model_params(task_type)return{model:your-model-name,messages:messages,**params,}这就是一个最小的请求组装层。后续第 6 讲会继续扩展如何发送请求如何处理超时如何记录日志如何做重试如何追踪成本典型场景判断场景 1写广告文案用户希望生成 10 个有创意的广告标题。更适合较高 temperature 较宽松输出格式 允许多样化表达因为这个任务需要创意。场景 2生成 JSON 配置用户希望模型输出一段程序可以解析的 JSON。更适合较低 temperature 严格输出格式 明确字段约束 最好配合结构化输出能力因为这个任务需要稳定不需要发散。场景 3总结长文档用户希望总结一篇长文档。需要重点关注上下文窗口 Token 成本 文档切分 摘要策略 输出长度限制如果文档太长不应该直接全部塞进请求。可以先分段摘要再汇总。场景 4多轮客服对话用户连续多轮咨询问题。需要重点关注历史对话保留 用户当前意图 关键信息提取 无关历史压缩不是所有历史都要原样保留。场景 5Agent 调用工具前的决策Agent 需要判断是否调用工具。更适合低 temperature 明确工具描述 明确风险边界 结构化决策输出因为工具调用前的决策不应该过于发散。常见误区误区 1Prompt 越长越好Prompt 不是越长越好。长 Prompt 可能包含更多约束但也可能引入噪声。好的 Prompt 是清晰、必要、可执行。误区 2把所有历史对话都塞进去保留全部历史会增加成本也可能干扰模型。更好的做法是保留当前任务相关信息压缩历史摘要结构化保存关键状态误区 3Token 只影响价格Token 不只影响价格。它还影响延迟上下文容量输出完整性模型关注重点误区 4Temperature 越高模型越聪明Temperature 控制随机性不代表智能水平。高 temperature 可能让回答更有创意也可能更不稳定。对于代码、工具调用、结构化输出通常不适合太高。误区 5System 消息可以解决所有安全问题System 消息可以表达规则但不能替代权限控制。例如你写不要泄露敏感信息。这有帮助但不够。系统仍然需要数据脱敏权限校验工具白名单审计记录误区 6模型会自动记住所有信息模型不会自动记住你所有历史。如果信息没有放进当前上下文模型不一定知道。长期记忆需要系统设计不能依赖模型“自己记得”。误区 7参数配置可以一劳永逸不同任务需要不同参数。同一套参数不可能适合所有场景。工程系统中应该按任务类型、风险等级、输出要求选择参数。本讲小结这一讲我们学习了 LLM 调用中的几个基础概念。可以这样记Prompt为了完成任务而组织出来的输入信息 System系统级规则和长期约束 User用户当前输入或目标 Assistant模型历史回答 上下文模型本次请求中能看到的全部信息 Token模型处理文本的基本单位也影响成本和延迟 模型参数控制生成风格、长度和稳定性的配置本讲最重要的观点是在工程系统中Prompt 不是一句提示词而是一次上下文组织。对于初学者来说要先理解告诉模型什么信息模型才可能基于什么信息回答。对于开发者来说要进一步建立工程意识Prompt 要模板化 上下文要管理 Token 要预算 参数要按场景设置 输出要可控后续课程会在这个基础上继续深入。下一讲会讲一次 LLM 调用的完整过程我们会从工程链路角度看清楚用户输入如何变成模型请求模型如何返回结果请求失败怎么办超时和限流怎么处理日志和调用追踪怎么设计理解了这些才能真正把模型调用接入到一个可靠的软件系统里。
