1. 项目概述当长上下文遇上渐进式披露最近在跟几个做Agent的朋友聊天大家都在头疼同一个问题模型上下文窗口是越做越大了从4K到128K甚至现在动辄百万token但我们的智能体真的因此变得更“聪明”了吗或者说我们是不是只是简单地把一堆文档、一堆历史对话、一堆工具调用记录一股脑地塞给模型然后指望它自己能“大海捞针”这感觉就像给了你一个能装下整个图书馆的书包但没给你目录和索引真要用的时候你还是得把书全倒出来一本本翻。这效率想想都头大。这恰恰引出了我们今天要深入探讨的核心问题“Is Progressive Disclosure All You Need for Long-Context Agents?”翻译过来就是对于长上下文智能体而言渐进式披露是唯一的解药吗这个标题背后其实是在拷问我们构建复杂Agent时的一个根本性设计哲学。Progressive Disclosure渐进式披露是一种经典的交互设计原则核心思想是“按需展示”只在用户需要的时候才提供更详细的信息或更复杂的功能避免一次性信息过载。把它应用到长上下文Agent上意味着我们不应该在每次调用模型时都把所有的历史、所有的知识、所有的工具描述都塞进上下文而是应该设计一套机制让Agent能够主动地、动态地、按需地从外部存储比如向量数据库、知识图谱、记忆系统中检索和引入相关信息。那么这真的是解决长上下文困境的“银弹”吗Long-Context Agents的挑战远不止是“装得下”更是“找得到”、“用得好”。而Agent Skills的繁荣特别是最近大家热议的MCPModel Context Protocol与各种自定义技能生态的涌现让这个问题变得更加立体。MCP等协议旨在标准化Agent与外部工具、数据源的连接方式这本质上就是在为“渐进式披露”提供基础设施——让Agent能按需调用技能而不是把所有技能说明书都背下来。这篇文章我想从一个一线实践者的角度拆解“渐进式披露”在长上下文Agent设计中的真实定位、价值边界、落地挑战以及与新兴技能生态如MCP的协同关系。这不是一篇理论综述而是结合了我们在构建企业级AI助手、复杂工作流自动化Agent过程中踩过的坑、试过的方案和得出的一些粗浅心得。无论你是在设计一个需要处理多轮复杂对话的客服机器人还是一个能调用几十个API完成跨系统任务的自动化助手或许都能从中找到一些共鸣和启发。2. 长上下文Agent的核心痛点与渐进式披露的引入2.1 长上下文从“容量竞赛”到“效用危机”模型上下文窗口的扩大无疑是技术进步的直接体现。从早期的GPT-3的2K到Claude的100K、200K再到一些开源模型宣称的1M甚至更长我们似乎进入了一个“容量无忧”的时代。然而在实际构建Agent时我们很快发现了几个尖锐的问题成本与延迟的线性增长绝大多数Transformer架构的模型其计算复杂度与上下文长度成平方关系O(n²)。这意味着即使模型支持长上下文将128K的token全部送入模型进行推理其计算成本和生成延迟是极其高昂的。对于需要实时交互的Agent应用这往往是不可接受的。信息检索的“大海捞针”难题即使你负担得起成本把大量信息塞进上下文模型从中提取关键信息的能力也会随着上下文长度增加而衰减。著名的“大海捞针”测试已经证明当关键信息被淹没在无关文本的海洋中时模型的召回率会显著下降。你的Agent可能“知道”答案就在它刚读过的100页文档里但它就是找不到。无关信息的干扰与幻觉过多的上下文不仅包含有用信息也包含大量噪声。这些噪声可能会干扰模型的判断导致其生成的内容偏离核心任务甚至基于不相关的上下文片段产生“幻觉”编造出看似合理实则错误的信息。状态管理的复杂性在长对话或多步骤任务中我们需要维护一个不断增长的上下文。如何更新这个上下文是简单追加导致无限增长还是选择性删除删除哪些部分这本身就是一个复杂的决策问题处理不好会导致关键历史信息的丢失。这些问题共同构成了长上下文Agent的“效用危机”我们拥有了巨大的容量却无法高效、精准、低成本地利用它。2.2. 渐进式披露一种朴素而强大的设计哲学面对上述危机“渐进式披露”提供了一种思路上的转变。它不再追求“一次性全知全能”而是转向“按需知按需能”。其核心运作机制可以概括为以下几步轻量级入口Agent在初始状态下只携带最精简的上下文。这可能包括系统指令定义角色和目标、当前用户查询、以及极少量最相关的近期历史或元数据。意图识别与需求分析Agent基于当前精简的上下文分析用户的意图和完成任务所需的信息与能力。这一步的关键是判断“我还需要知道什么”和“我需要能做什么”。主动检索与技能调用根据需求分析的结果Agent主动触发检索动作。这可能是知识检索从外部向量数据库、知识图谱或文档存储中查询与当前任务相关的片段。技能/工具检索从技能库中查找能解决当前子任务的工具或技能例如计算器、查询数据库、调用某个API。记忆检索从长期记忆存储中提取与当前用户或任务相关的历史信息。上下文动态更新将检索到的相关信息知识片段、工具描述、历史记忆动态地、增量地添加到Agent的上下文中。此时上下文的增长是目标驱动的、有选择的。执行与迭代Agent基于更新后的、信息更丰富的上下文生成下一步行动思考、调用工具、回复用户。如果需要重复步骤2-4形成“分析-检索-执行”的循环。这种模式的优势是显而易见的降低成本大部分时间模型都在较短的上下文下工作只有必要时才引入额外内容显著减少了平均计算开销。提升精度通过检索引入的信息与当前任务高度相关减少了噪声干扰提升了模型处理关键信息的专注度和准确性。增强可扩展性Agent的能力不再受限于其初始上下文窗口。理论上只要外部存储足够大它能访问的知识和技能就是无限的。这为构建超大规模、多功能的Agent系统奠定了基础。改善可解释性我们可以清晰地记录Agent在每一步检索了哪些信息、调用了哪些技能这为调试和优化Agent行为提供了透明链路。注意渐进式披露不是一个具体的技术而是一个架构范式。它的实现依赖于一系列底层技术的支持其中最核心的就是检索系统RAG和工具调用Function Calling机制。这两者共同构成了Agent“按需获取”信息与能力的两条腿。3. 渐进式披露的实践架构与核心组件理解了理念我们来看看如何落地。一个基于渐进式披露思想的长上下文Agent系统其架构通常包含以下几个核心层。我会结合我们实际项目中的选型聊聊背后的考量。3.1. 控制中枢智能路由与规划模块这是整个Agent的“大脑”负责执行前述的“意图识别与需求分析”。它决定在什么时候、去什么地方、获取什么。这个模块通常由一个“规划器”或“路由器”模型来担任。轻量级模型优先这个模块不需要处理长上下文它的任务是快速理解用户意图并将其分解或路由。因此我们通常选择一个速度快、成本低的小模型例如GPT-3.5 Turbo或更小的开源模型如Qwen2.5-7B。它的输入是精简的上下文输出是一个结构化的“行动计划”。行动计划的格式行动计划可能是一个简单的工具调用请求如{action: search_knowledge_base, query: 用户问题的关键词}也可能是一个更复杂的任务分解序列如[“检索产品A的规格” “查询用户历史订单” “调用折扣计算API”]。我们团队目前采用基于JSON Schema的标准化输出方便后续模块解析。与技能生态的对接这里就涉及到Agent Skills和MCP等概念。规划器需要知道“有什么技能可用”。传统的做法是把所有工具的Function Calling描述都写死在系统提示词里但这显然不可扩展。MCP这类协议的价值在于它提供了一种动态注册和发现技能的机制。规划器可以通过查询一个技能注册中心实时获得可用技能的列表和描述从而做出更精准的路由决策。Skills和MCP的区别可以简单理解为Skills是具体的功能点如“发送邮件”、“查询数据库”而MCP是管理和调用这些Skills的一套协议和基础设施。MCP让Skills的接入和使用变得更标准化、更动态。3.2. 记忆与知识库外部存储与检索系统这是Agent的“外部大脑”负责存储海量信息并在需要时快速提供精确的片段。分层存储设计我们不会把所有东西都塞进一个向量数据库。短期/工作记忆存放最近的对话轮次、临时变量等通常用内存或高速KV存储如Redis。这部分信息活跃度高检索速度要求极快。长期记忆存放用户画像、历史会话摘要、长期偏好等。这里对检索精度要求高通常使用向量数据库如Chroma, Weaviate, Pinecone结合元数据过滤。领域知识库存放产品文档、FAQ、规章制度等静态知识。这是RAG检索增强生成的主战场需要精心设计文档分块、向量化模型和检索策略。检索策略是关键混合检索单纯依靠向量相似度搜索语义搜索可能不够。我们通常结合关键词搜索BM25进行混合检索以提高对特定术语、代码、产品型号等精确信息的召回率。重排序初步检索可能返回10-20个相关片段用一个更小的、专门针对重排序优化的模型如BGE-Reranker对这些片段进行相关性打分和重新排序只将Top-3或Top-5最相关的片段注入上下文。这能极大提升信息质量是渐进式披露中“精准投放”的关键一步。递归检索与查询改写对于复杂问题一次检索可能不够。规划器可以指导进行多轮检索或先对用户问题进行改写、扩展后再检索以获取更全面的信息。3.3. 技能执行层工具调用与动作执行这是Agent的“手和脚”负责具体执行规划器下达的指令。这一层的稳定性、安全性和错误处理至关重要。标准化接口所有技能工具都应提供统一的调用接口。这可以是简单的HTTP API也可以是更复杂的gRPC服务。MCP的价值在这里再次凸显它定义了技能描述、调用和返回值的标准格式让Agent能以一种统一的方式与成千上万个异构技能交互。技能描述与发现每个技能都需要一个清晰、机器可读的描述包括功能、输入参数、输出格式、错误码等。这个描述会被注册到技能注册中心供规划器查询。描述的质量直接影响了规划器选择的准确性。执行与容错技能执行层必须要有完善的超时、重试、降级和错误处理机制。一个技能调用失败不应该导致整个Agent崩溃。规划器需要能根据错误信息调整计划例如换用备用技能或向用户请求澄清。权限与安全这是企业级应用的生命线。必须有一套严格的权限控制系统定义每个Agent、每个用户可以调用哪些技能访问哪些数据。技能执行层需要集成身份认证和授权校验。3.4. 上下文管理引擎动态窗口的调度者这是渐进式披露范式的“舞台监督”负责管理模型眼前那个有限的上下文窗口。它接收来自各方的信息原始查询、检索结果、工具返回、历史摘要并决定如何编排、压缩、修剪它们以形成下一次模型调用的有效提示。策略一选择性注入这是最直接的方式。规划器决定需要哪些知识片段和技能结果上下文管理器就把它们按特定模板格式拼接到提示词中。关键在于模板设计要清晰地区分系统指令、历史对话、检索知识、工具结果等不同部分帮助模型理解信息的来源和用途。策略二摘要与压缩对于长对话历史不能无限追加。一种常见做法是维护一个“对话摘要”。在每一轮或每几轮对话后用一个模型对之前的对话进行总结生成一段精炼的摘要。后续的对话以上一轮的摘要和最新几轮原始对话作为历史上下文。这相当于用摘要“代表”了过去的漫长交流。策略三优先级排序与淘汰当上下文即将超过窗口限制时需要决定淘汰哪些旧信息。一个简单的策略是LRU最近最少使用但更智能的策略可能会基于信息的重要性例如系统指令和当前任务描述永远保留、与当前问题的相关性通过向量相似度计算来综合打分淘汰得分最低的片段。策略四结构化上下文更高级的做法是不仅管理文本还管理结构化的上下文对象。例如将对话历史、知识片段、工具调用记录分别存放在不同的“上下文槽”中并在每次调用模型时根据任务类型动态决定每个槽的填充内容和填充方式。这需要模型本身具备理解结构化提示的能力。4. 渐进式披露的局限性它并非“银弹”看到这里你可能会觉得渐进式披露近乎完美。但作为一名踩过无数坑的实践者我必须指出它远非万能甚至在某些场景下会引入新的复杂性和问题。盲目套用此范式可能会让你的Agent项目陷入困境。4.1. 对规划器能力的过度依赖整个范式的第一个环节——意图识别与需求分析——就建立在规划器足够聪明的假设上。如果规划器“判断失误”整个链条就会跑偏。冷启动问题当用户问题非常模糊或开放时例如“帮我分析一下业务数据”规划器可能无法准确判断需要检索哪些知识或调用哪些技能。它可能检索了一堆不相关的文档或者调用了错误的工具导致后续步骤低效甚至错误。误差累积与循环依赖规划、检索、执行是一个循环。如果某一步产生误差这个误差可能会在循环中放大。例如规划器基于不完整的检索结果做出了错误的任务分解导致调用了错误的技能技能返回错误结果又影响了下一轮的规划。系统可能陷入一个错误的循环而无法自拔。规划本身的成本引入一个专门的规划步骤意味着增加了一次模型调用和额外的延迟。对于极其简单、明确的任务例如“今天的天气怎么样”直接使用具备长上下文能力的模型进行端到端处理可能比“规划-检索-执行”的路径更简单、更快。4.2. 检索系统的固有缺陷RAG是渐进式披露的基石但RAG本身并非完美。检索精度与召回率的永恒权衡再好的检索系统也无法保证100%找到所有相关信息且不返回任何无关信息。漏检召回率低会导致信息不足误检精度低会污染上下文。特别是在知识边界模糊、问题涉及多领域交叉时检索质量很难保证。上下文丢失问题检索返回的是知识“片段”。当答案需要综合多个分散片段的信息进行深度推理、对比或总结时仅仅把这些片段并列放在上下文里模型可能无法像人类一样有效地建立它们之间的复杂联系。长上下文模型的一个潜在优势正是能在单个上下文中进行这种复杂的跨段落推理而渐进式披露的“片段化”供给可能削弱这种能力。对结构化、非文本数据的处理乏力现有的向量检索主要针对非结构化文本。对于复杂的表格数据、代码、图谱关系简单的文本片段检索往往力不从心需要设计特殊的索引和检索方式。4.3. 技能调用的协调与状态管理挑战当任务需要按特定顺序协调多个技能时复杂度急剧上升。技能编排的复杂性规划器不仅要决定调用哪个技能还要决定调用的顺序、参数如何从前序技能的结果中传递、如何处理分支和循环逻辑。这本质上是在让LLM编写一个程序其可靠性远低于人类编写的确定性代码。技能间的状态传递技能A的输出如何成为技能B的输入这个状态是放在上下文中让模型自己提取还是由编排框架显式管理显式管理增加了框架的复杂性而放在上下文中则对模型的指令跟随和信息提取能力要求很高。技能描述的完备性与歧义技能描述必须极其精确否则规划器会误解。例如一个“发送消息”的技能需要描述清楚是发送邮件、短信还是即时通讯消息参数是收件人列表、主题、正文还是富文本描述不清晰会导致调用错误。4.4. 延迟与用户体验的权衡渐进式披露的“按需获取”模式在复杂任务中可能导致多次连续的模型调用和外部服务调用总延迟可能远超单次长上下文调用。链式延迟用户问一个问题Agent背后可能发生了规划1次LLM调用 延迟- 检索网络IO 向量搜索延迟- 执行技能可能涉及多个API调用各有延迟- 最终生成回答又一次LLM调用。整个链条的延迟是累加的可能达到数秒甚至十几秒这对实时对话体验是致命的。不确定性带来的等待感在端到端的长上下文模型中用户知道模型在“思考”。在渐进式披露的Agent中用户可能经历多次“停顿-响应-再停顿”的过程体验可能不够流畅。需要精心设计流式输出和中间状态提示如“正在查询资料…”、“正在为您计算…”来改善体验。5. 混合策略在渐进式披露与长上下文之间寻找平衡那么我们是否应该回到粗暴的长上下文填充老路当然不是。更务实的策略是采用一种混合架构根据任务的特性和场景智能地选择最合适的路径。我认为未来的主流Agent架构将是“渐进式披露为主长上下文能力为辅”的协同模式。5.1. 场景化路径选择我们可以设计一个更智能的“元规划器”或路由规则在请求入口处就进行分流简单QA与信息查询对于事实明确、答案可能在已知知识库中的问题直接走“检索-生成”的RAG路径。这是渐进式披露最擅长的。复杂分析与创作对于需要深度理解长文档、进行文学创作、代码生成或复杂逻辑推理的任务如果相关文档可以控制在模型有效窗口内例如一篇50页的报告则可以考虑将整个文档或其主要部分一次性送入一个强大的长上下文模型进行端到端处理。这避免了检索可能带来的信息丢失和碎片化。多步骤工具调用对于需要协调多个工具的任务如“订机票-租车-订酒店”采用渐进式披露的规划-执行循环是更自然的选择。但可以尝试将整个工作流的“计划”或“状态机”描述以及相关工具的简洁描述保持在同一个上下文中让模型维持对全局任务的理解。5.2. 长上下文作为“工作内存”与“缓存层”我们可以重新定义长上下文窗口的角色高频交互的“工作内存”在一个会话中将最核心的对话历史、任务状态、用户意图摘要、以及最近几次检索和工具调用的关键结果维护在一个中等长度例如8K-16K的上下文中。这相当于Agent的“工作记忆”保证了对话的连贯性和对当前任务焦点的把握。检索结果的“缓存与融合层”当通过RAG检索到多个相关文档片段后不是简单拼接而是可以先送入一个长上下文模型进行摘要、去重、信息融合生成一个更精炼、更连贯的背景知识摘要再将这个摘要而非原始片段注入主Agent的上下文。这样既利用了检索的精准又发挥了长上下文模型的信息整合能力。5.3. 动态上下文窗口管理我们可以开发更智能的上下文管理策略而不是非此即彼预测性预加载基于对话历史和用户画像预测用户接下来可能需要的知识或技能在后台异步进行预检索和预加载。当用户真的提出相关问题时相关信息已经准备就绪可以瞬间注入上下文减少等待时间。重要性感知的保留策略不是简单地按时间顺序淘汰旧信息而是基于信息与当前任务的相关性、信息本身的密度和价值是否包含关键决策、承诺、数字等动态计算每个信息片段的“重要性分数”优先保留高分片段。分层压缩对上下文中的不同部分采用不同的压缩策略。例如对遥远的对话历史进行高度摘要对刚使用过的工具结果保留完整输出对系统指令永久保留但可以置于提示词末尾等次要位置。6. 实操心得与避坑指南结合我们团队在过去一年里构建多个Agent系统的经验分享一些具体的实操心得和踩过的坑希望对你有所帮助。6.1. 规划器模型选型不要盲目追求大模型很多人觉得规划是核心就应该用最强大的模型如GPT-4。但我们的实践证明对于大多数规划任务一个速度快、成本低的模型如GPT-3.5 Turbo经过精心设计的提示工程Prompt Engineering其表现与GPT-4的差距远小于它们的价格和速度差距。我们的做法我们使用GPT-3.5 Turbo作为主要规划器。关键在于设计结构化的输出格式严格的JSON Schema和提供清晰、丰富的示例Few-shot Learning。我们在提示词中内置了5-10个高质量的任务分解示例覆盖了各种常见场景。这极大地稳定了规划器的输出质量。避坑点不要给规划器过于开放的任务。尽量用模板和选项限制其输出空间。例如与其说“请规划如何回答用户”不如说“请从以下动作中选择一个或多个并填写参数search_knowledge_base,call_calculator,query_user_profile”。6.2. 检索质量是生命线90%的失败源于糟糕的检索如果你的Agent给出了错误答案首先检查检索系统十有八九是这里出了问题。分块策略是基石文档如何切割成片段Chunk对检索效果有决定性影响。我们试过按固定长度、按段落、按标题等多种方式。最终发现对于技术文档按章节/子标题分块并重叠一部分内容例如重叠100个token效果最好。对于对话或文章按语义完整性分块使用句子嵌入模型检测语义边界比固定长度更优。向量模型需要微调开箱即用的通用向量模型如text-embedding-ada-002对于特定领域如医疗、法律、金融效果可能一般。如果条件允许使用领域内的数据对向量模型进行微调哪怕只是少量数据的轻量级微调也能带来显著的检索精度提升。必须引入重排序这是提升RAG效果性价比最高的步骤。我们使用BGE-Reranker将初步检索的20个片段重排后取Top-3。实测表明这能将最终答案的准确率提升15%以上。重排序模型的输入可以不仅仅是查询和片段还可以加入元数据如片段来源、类型效果更好。避坑点不要只依赖语义搜索。一定要结合关键词BM25进行混合检索。很多专有名词、产品型号、错误代码用关键词搜索召回率更高。我们搭建的检索服务默认走“关键词初筛 - 向量精搜 - 重排序”的三级流水线。6.3. 工具/技能设计的“契约精神”设计一个供Agent调用的工具和设计一个供人类开发者调用的API思路完全不同。描述必须精确无歧义工具的名称、功能描述、每个参数的名称、类型、描述、是否必需、示例值都必须极其清晰。避免使用“处理数据”、“获取信息”这种模糊描述。要写成“根据用户ID查询其最近30天内的订单列表并按创建时间倒序排列”。错误处理要机器可读工具返回的错误信息不能只是给人看的“出了点问题”。必须是结构化的错误码和错误信息让规划器能够理解错误类型如“参数无效”、“资源不存在”、“权限不足”并据此决定下一步行动如请求用户重新输入、尝试备用方案、直接向用户报错。功能要原子化一个工具最好只做一件事。不要设计一个“万能”工具比如一个handle_user_request的工具里面根据参数不同做几十件事。这会让规划器难以理解和选择。应该拆分成query_order,update_profile,cancel_subscription等多个原子工具。避坑点工具调用要有超时和重试机制但重试策略要谨慎。对于幂等操作如查询可以快速重试。对于非幂等操作如创建订单、支付绝不能自动重试必须将错误明确返回给Agent由Agent或人工决定如何处理。6.4. 上下文管理的艺术平衡新鲜度与连贯性管理好那个有限的上下文窗口是让Agent显得“聪明”还是“健忘”的关键。维护一个“对话核心”摘要我们实现了一个独立的“摘要生成器”微服务。每经过3-5轮对话或者当检测到话题明显切换时就用一个小模型如GPT-3.5将之前的核心对话内容用户目标、已做出的决策、已确认的事实总结成一段100-200字的文本。后续的对话历史就用这个摘要加上最新的2-3轮原始对话来代表。这有效控制了上下文长度并保留了关键信息。系统指令要“活”系统指令不是一成不变的。可以根据对话状态动态调整系统指令的强调部分。例如当用户进入“订票”流程时可以在系统指令中临时加入“你目前正在协助用户预订航班请专注于收集出发地、目的地、时间等信息。”这相当于给模型一个即时的“角色提示”。避坑点不要频繁地、大幅度地替换整个上下文。这会导致模型“失忆”。每次更新上下文时尽量采用“增量”方式保留最核心的部分。如果必须进行大的替换如切换任务主题最好在给用户的回复中做一个平滑的过渡例如“好的我们刚才已经解决了X问题。现在来帮您处理Y问题...”。7. 未来展望超越渐进式披露回到最初的问题“Is Progressive Disclosure All You Need for Long-Context Agents?” 我的答案是它是当前阶段构建实用、高效、可扩展Agent不可或缺的核心架构范式但绝非“All You Need”。它更像是一套优秀的“战术”帮助我们克服长上下文模型在成本、精度和扩展性上的局限。然而真正的“战略”突破可能来自模型架构本身的演进。我们正在目睹一些令人兴奋的方向更高效的长上下文模型如基于状态空间模型SSM的Mamba架构其推理复杂度与上下文长度呈线性关系有望从根本上降低长上下文处理的成本。如果未来主流模型都能以低成本处理超长上下文那么“按需检索”的必要性就会下降。内置的检索与工具调用能力未来的模型可能会原生集成检索和工具调用模块。想象一下模型内部有一个“虚拟指针”可以直接指向外部知识库中的某个位置或者内部封装了常用工具的操作无需通过复杂的规划-调用循环。这类似于人类在思考时能无缝地调用记忆和技能。更强大的内在规划与推理能力如果模型自身的复杂任务分解和规划能力得到质的提升能够在一个超长上下文中自主地进行多步骤推理和子目标规划那么对外部显式规划器的依赖也会减少。但在这些未来成为现实之前渐进式披露以及与之配套的RAG、工具调用、智能体框架如LangChain, LlamaIndex, Semantic Kernel等仍是我们手中最强大、最实用的工具箱。理解它的原理掌握它的实践看清它的边界然后灵活地将其与模型本身的长处结合这才是构建下一代智能应用的正道。最后分享一个我们最近在项目中的小技巧我们开始尝试让规划器在输出行动计划时同时输出一个“信心分数”表示它对这个规划有多确定。对于高信心分数的简单任务我们走精简高效的渐进式披露流程对于低信心分数的复杂模糊任务我们则切换到一个“审慎模式”可能会调用一个更大的模型进行二次评估或者直接将更多背景信息通过检索获得和任务描述一起送入一个长上下文模型进行“深度思考”。这种动态的、基于信心的混合策略在实际应用中取得了比单一策略更好的效果。这或许也说明了在AI工程的世界里没有银弹只有针对具体问题精心调配的复合解药。
