1. 先拆题这到底在探讨一个什么问题Agent 圈最近有个很有意思的争论一个 LLM Agent 表现好到底是它“知道得多”信息访问能力还是它“想得清楚”推理能力很多团队在复盘项目时会发现把某一个模块换了之后整体效果提升明显但再深入一层问“为什么提升”能答上来的人就不多了。这个标题要做的正是把这件事拆开通过实验设计把 Agent 的性能差异归因到信息访问和推理能力这两个变量上而不是笼统地说“模型更强了”。这个思路特别适合两类人一类是正在做 Agent 应用落地、需要优化 Prompt 和工具链的开发者另一类是做大模型评测、想建立更细粒度评估指标的研究者。它能帮你回答一个很实际的问题——当 Agent 答错或答对时到底是哪个环节在起作用。我自己的看法是这类归因实验的价值不在于“证明哪个更重要”而在于给优化指明方向。如果发现瓶颈在信息访问那换更强的模型没用应该去调检索和上下文构造如果瓶颈在推理那堆资料也没用应该在思维链和规划策略上下功夫。方向错了投入产出比差一个量级。在展开实验细节前先把两个核心概念定义清楚因为整个实验设计都建立在这两个定义之上。2. 核心概念界定与实验设计思路2.1 信息访问能力Agent 能从外部获取和利用信息的效率与广度信息访问我理解为 Agent 获取任务所需外部信息的全过程包括但不限于以下环节检索阶段从知识库、搜索引擎、数据库、API 中查找相关信息。上下文构建将检索到的信息拼接进模型输入的当前窗口。关键信息命中从大量候选信息中选出真正有助于当前问题的内容。这个概念的核心指标是信息覆盖率即所需信息是否已出现在上下文中和信息精准度即上下文里的信息是否有用、是否冗余。做这个归因实验时需要把“模型是否看到了正确答案所需的信息”作为单独变量控制住。2.2 推理能力模型基于给定信息进行逻辑推导、规划与决策的能力这里的推理能力是狭义的是指在信息已经充分提供的前提下模型能否通过多步推理、逻辑判断、规划分解来得出正确结论。它不考验知识面而是考验思维链路。在实验设计中推理能力要排除信息获取的干扰。也就是说把“信息已经给了”作为前提只观察模型的推导过程。一个常见的类比是开卷考试信息全都摊在桌上能不能做对题看的是推理而闭卷时能不能考好才涉及信息访问。2.3 实验设计思路控制变量 交叉组合做归因实验最朴素也最有效的框架是 2×2 交叉设计组别信息访问条件推理条件说明A组信息完整强推理模型基准最优B组信息完整弱推理模型考察强信息下推理差异C组信息缺损强推理模型考察弱信息下模型是否靠推理弥补D组信息缺损弱推理模型下限参考以这个框架为骨架再针对任务特点做以下变化信息完整组和缺损组用同一套问题保证题目难度一致。强推理和弱推理的区分在工程上通常用不同规模的模型实现也可以用同一模型加不加思维链来模拟。这样四组跑完之后性能差异就能拆成两部分信息访问带来的边际收益、推理能力带来的边际收益。这个设计的核心优势在于能算“效应量”。比如 A 组准确率 80%C 组准确率 60%那在强推理条件下信息访问带来的增量就是 20 个百分点同理A 组与 B 组的差值就是在信息充分条件下推理能力的增量。交叉对比下来两个因素分别贡献多少一目了然。2.4 为什么用“实验”而非“观察”随机化与对照的意义很多团队分析 Agent 性能时习惯做“事后观察”就是从日志里找表现好和差的例子再倒推原因。这种方式并非没用但容易陷入选择偏差和相关性误导。比方说日志里某个 Agent 遇到长尾问题时表现差可能既因为检索没命中又因为推理链路本来也长两个因素裹在一起说不清楚。实验方法的核心是主动干预我故意构造信息缺损的情况故意搭配不同类型的推理链路用随机化分组来切断混淆变量。这样做虽然费工夫但结论的执行性要强得多。拿到的结论可以直接告诉工程团队调检索、调上下文、加大模型还是调整推理策略每一个决策都有数据支撑。3. 环境准备与归因指标设定3.1 基础环境配置首先说明我做这类实验的基础环境配置上不需要太特别的设备中高端开发机即可模型推理框架使用支持 OpenAI 接口兼容的本地推理服务方便统一调用。API 封装层用 Python 的 AsyncOpenAI 客户端统一管理多模型调用。评测框架采用自研轻量评测脚本前置于模型调用统一管理题目注入、结果采集和指标回调。版本控制所有实验配置、Prompt 模板和评测结果按日期归档方便回溯。在实际操作时我会把评测脚本和模型调用逻辑解耦评测脚本只负责发题目、收答案、算指标模型调用层负责按配置加载不同的模型。这样切模型就像换配置文件不用动评测逻辑。3.2 数据集的构造策略数据集是归因实验的灵魂构造策略我总结为三条原则任务必须同时依赖信息和推理如果任务过于简单信息充分与否不影响最终结果那实验就没有区分度。信息缺损度要可量化、可复现缺损不是随机的是人为设计的。像把一个关键数字从文档中删掉或把一段必要的背景说明替换为无关内容。推理深度要有梯度题目里既要有单步推理也要有多步推理这样后续可以分析推理复杂度对归因结果的影响。具体到构造方法我采用“基础题面 信息文档 受控扰动”的套路先定义一批问题每道题配一份参考文档包含解题所需的所有信息再构造受控扰动版本将文档中关键信息替换为无关或干扰内容。这样同一个题面就拥有了完整信息与缺损信息两个条目。3.3 归因指标的设计边际提升率与相对贡献度为了量化两个因素的贡献我设计了几个核心指标在每个指标的定义和公式上做个说明供参考实现。指标计算公式含义信息边际提升率(A - C) / (1 - C)或(B - D) / (1 - D)在固定推理条件下补全信息带来的效果提升比例推理边际提升率(A - B) / (1 - B)或(C - D) / (1 - D)在固定信息条件下增强推理带来的效果提升比例相对贡献度信息边际提升率 / (信息边际提升率 推理边际提升率)两个维度贡献的占比比较这个公式的选择基于一个前提准确率是百分制指标直接差值会受基线影响。用归一化提升率更能反映“相对空间内的提升比例”也方便在不同任务之间做横向比较。3.4 基线打点与有效性检验动手跑实验前我建议先做一个“有效性检验”用强推理模型 完整信息跑一遍所有题目准确率应显著高于随机水平。如果连这一步都做不到说明题目本身有问题比如文档里信息不足或题面有歧义。用弱推理模型 信息缺损跑一遍准确率应接近最低水平用来确认实验的区分空间足够。每组随机抽样 5~10 个样本人工复核确认答错的原因确实是信息缺失或推理错误而不是题目表述问题。把这三个步骤走完再进入正式实验能避免后期出现“结果很漂亮但不可解释”的尴尬。4. 核心实验实现与执行细节4.1 信息访问条件的搭建双向配置法我先定义一个信息访问控制函数用配置开关控制注入策略def build_context(task_info: dict, info_mode: str) - str: 根据信息模式构建上下文。 info_mode: full - 完整信息 missing - 关键信息缺失 noisy - 信息完整但混入干扰 doc task_info[source_doc] if info_mode full: return doc elif info_mode missing: critical_para task_info[critical_paragraph] # 将关键段落替换为无害占位描述保证文档结构不被破坏 redacted doc.replace(critical_para, [此部分内容涉及无关背景略过]) return redacted elif info_mode noisy: # 保留关键信息同时额外注入一段与任务无关但主题相关的干扰描述 noise task_info.get(noise_blob, [此处有一段与当前问题无直接关联的补充背景]) return doc \n\n noise操作系统层面的流程控制则这样实现先按info_mode生成上下文再喂给不同模型每一组记录原始输出最后统一跑后处理脚本从原始输出中提取答案文本和推理痕迹。在实测中missing模式的替换点选择很关键。不能简单把整段删掉否则模型会因为格式不连续而做出明显异常的判断——这会把“信息缺失”和“上下文异常”混在一起。用语义相近的占位描述替代能确保模型没有感知到格式破坏只是真的看不到关键信息。noisy模式是额外加入的对照。它回答的问题是信息是完整的但混入了无关材料模型能不能排除干扰这考察的是信息过滤的稳健性和单纯的信息缺失是两个维度。4.2 推理条件的分层用模型选择与策略注入实现推理条件的区分我采用两种方式配合使用一是模型尺寸梯度。选择同一系列的不同规格模型比如轻度量级与中等级量级。这样可以在尽量控制训练数据分布差异的前提下拉开推理能力层次。注意不要跨系列对比否则训练数据、对齐方式的差异会污染归因结果。二是推理策略注入。当只能部署一个模型时可以用“是否显式要求思维链”来制造推理强度的差异。启用思维链时附加“请逐步思考并输出推理过程”的指令关闭时附加“请直接给出答案不要输出分析过程”。两种方式建议结合使用先用策略注入做小范围验证确认题目有区分度再用模型梯度做大范围实验得到更稳定的归因结论。4.3 Agent 执行主循环与评测解耦Agent 的运行并不复杂但评测和解耦需要提前设计好。核心执行代码如下async def run_agent(session, task_item, info_mode, prompt_mode): ctx build_context(task_item, info_mode) if prompt_mode cot: instruction 请逐步思考最后给出答案。 else: instruction 请直接给出答案。 messages [ {role: system, content: 你是一个严谨的问题解答助手。}, {role: user, content: f背景资料\n{ctx}\n\n题目{task_item[question]}\n{instruction}}, ] resp await session.chat.completions.create( modeltask_item[model_name], messagesmessages, temperature0.0, max_tokens1024, ) return resp.choices[0].message.content这里有几个工程细节值得注意temperature 固定为 0确保每组之间只受变量影响不受采样随机性干扰。max_tokens 给到 1024因为思维链模式会输出较长推理过程太小会截断模型导致指标失真。异步并发按批次控制比如每批 16 条并发避免请求限流和超时。评测解耦就是把模型输出先落盘记录 JSONL 文件再用另一套脚本统一评测而不是在模型调用时动态算分。这样做的好处是一旦发现评分规则有问题能直接重跑评分脚本不用重新调用模型成本完全可控。4.4 Prompt 模板的控制避免变量污染归因实验最隐蔽的坑在 Prompt 模板。不同模型、不同条件模板必须保持一致除了推理策略注入的差异外任何差异都会变成额外变量。比如你给强模型写的 Prompt 背景更详细那提升就不能归因于推理能力而是信息访问的差异——这就直接破坏了实验设计。具体落到操作层面模板使用统一占位符只允许{context}和{question}两个变量外加一个可选的策略指令切换位。策略指令用固定文本不要在不同组之间改写措辞。每个模型的 system prompt 保持一致不因为模型能力差异而调整描述方式。4.5 样本量与实验收敛的取舍实验样本量直接影响结论的可信度。我的经验是小规模探索期验证题目区分度每组 30~50 条足够。正式实验期每组 200 条以上涉及多步推理的题目建议 300 条以上因为多步推理的方差更大。类目均衡确保缺损类型分布均匀关键信息缺失、部分冗余、完全无关避免某类题目占比过高导致归因偏差。实验运行完之后所有结果写入一张总表任务 ID、模型组、信息模式、推理模式、答案、得分、耗时。这张表是整个归因分析的基础后续所有结论都从这里出。4.6 推理链路数据的采集不只记录答案还要记录过程归因分析依赖过程数据。如果只记答案出现错误时很难判断错在信息理解还是推理步骤——所以我在输出采集时同时记录以下字段模型回答原文可保留格式提取出的推理步骤列表用分隔符切分模型输出的中间步骤每一步是否命中参考文档中的关键信息用关键词匹配或语义相似度判断最终答案及判定结果有了这种结构化的过程数据归因分析就可以从“结果归因”升级为“过程归因”定位到具体的失败环节。这才是这个标题真正有价值的产出。5. 典型实验结果解读四个维度的交叉归因这一部分用一个模拟实验结果来说明分析和归因方式。假设有 100 道题四组结果如下组别准确率平均耗时可忽略典型错误模式A完整 强推理82%低少数复杂多步推理错误B完整 弱推理65%低信息虽全但链路过长导致遗漏C缺损 强推理51%中能识别信息缺口尝试推断但依据不足D缺损 弱推理38%中信息缺失后直接蒙答案无有效推导加测 E噪音 强推理76%低干扰信息挤压上下文部分关键信息被忽略基于上表可以计算以下关键指标信息边际提升率强推理下(82 - 51) / (100 - 51) ≈ 63.3%推理边际提升率信息完整下(82 - 65) / (100 - 65) ≈ 48.6%相对贡献度信息访问约占 63.3 / (63.3 48.6) ≈ 56.6%推理约占 43.4%这个结果说明在模拟场景中信息访问的边际贡献略高于推理能力的贡献。但需要强调的是这个比例高度依赖任务类型和数据分布换一套题目比例可能完全反转。归因实验的意义就是给出这种弹性的量化依据而不是给出一个固定的“重要性排名”。再看加测组 E信息完整但混入噪音准确率从 82% 掉到 76%。这说明强推理模型也不能完全免疫干扰信息。在真实业务中用户往往不会给精确、干净的信息噪音场景下的信息过滤能力值得单独优化。5.1 信息访问占主导的场景特征哪些任务更吃信息访问从实验规律来看有三类特征知识密度高题目需要大量外部事实支撑比如产品规格、法律条文、专业术语。信息熵高资料库中可用信息占比低需要从海量候选中捞关键线索。长尾分布常见知识覆盖不到必须依赖实时检索或特殊数据源。针对这类任务优化重点应放在检索质量和上下文构建上。比如提升召回率、优化重排逻辑、压缩无关上下文。换更大模型效果不明显因为瓶颈不在“想”而在“看”。5.2 推理能力占主导的场景特征另一类任务则更吃推理能力典型特征多跳推理需要把分散在不同段落的信息串起来。此时只要中间一跳断了结果全错。规划与分步执行任务需要先拆解再执行中间可能需要自我纠错。逻辑约束强有明确的 if-else 或组合约束解决涉及条件分支。这种情况下增量信息再多也没用模型自身推导能力就是天花板。优化方向是换更强的推理模型或者用思维链、子目标分解和自一致性采样这类策略。5.3 组合策略的启示从实验归纳出一个通用策略先定位短板再做针对性增强。如果任务里信息访问贡献占比高优先优化 RAG 链路加元数据过滤、重排细化、查询改写、上下文压缩等手段并且重点测试噪音场景。如果推理贡献占比高优先优化推理策略比如引入思维链诱导、增加自校验步骤、给模型提供中间思考草稿空间。混合场景下两个方向按贡献度排序投入避免资源浪费。6. 实操中的坑与排查一次真实复盘这一节把我在类似实验中踩过的坑挑几个典型的整理成速查表。都是真金白银换来的教训。6.1 常见坑一缺损信息与模型上下文窗口的错位初期做信息缺损实验时我用简单字符串替换把关键段落删了但模型仍然答对了。排查后发现文档里同一信息在另一处又出现了一遍。模型不过是因为首处缺失但在后文里找到了线索。这直接说明信息“缺损”必须做到全局层面不能只改动一处。修复方法对每份文档做信息抽取找出所有提到关键信息的位置统一做替换或者在构造数据集时就保证关键信息在全文中只出现一次。6.2 常见坑二推理策略注入改变了信息利用方式另一个有意思的坑加了“请逐步思考”之后模型不仅推理更充分了还会更仔细地回看上下文中的细节导致它在信息缺损条件下反而更早发现自己缺信息进而给出“信息不足”的回答而不是强行作答。这在评测系统中如果标准答案只允许“作答对/错”这类回答会被记成“错”从而低估了模型的元认知能力。处理建议评测标签应该至少分为三类——正确 / 错误 / 拒绝回答信息不足。把“拒绝回答”单独统计能反映模型对信息完备性的判断力这也是信息访问能力的一个重要侧面。6.3 常见坑三多模型并发导致评测结果混杂用异步并发跑多模型、多任务时一旦某个模型请求超时或返回异常整个任务批次的结果就会缺失导致后续统计有偏。我经历过一次线上评测某模型在并发压力下大量触发限流导致它那组只有别人一半的样本对比就很难说了。排查方法每个任务执行时记录请求状态码和耗时结束后先做质量检查脚本确定各组样本数量一致且无异常输出再进入统计阶段。不规范宁可不发表结论。6.4 常见坑四题目难度方差太大导致归因失真如果 100 道题里 60 道是送分题40 道是极难题那么归因结果会被送分题稀释表现不出真实差异。这种情况我在初版数据上吃过亏四组准确率都在 70%~85%差异不大结论没法用。修正策略先做难度预筛用强模型跑一遍全部题目对每道题打一个难度分或基于错误率统计难度最后在正式实验中按难度分层抽样确保每组包含类似比例的简单和困难题目。或者全部选中等偏难题让实验区隔度更大。6.5 问题排查速查表现象可能原因排查方法处理建议缺损组和完整组差异极小信息在文档多处冗余检索文档是否多处包含关键信息构造数据时保证信息唯一性强推理模型在缺损组频繁拒答思维链激活元认知识别信息缺口查看推理过程是否出现“信息不足”标记将拒答单列为有效输出类别弱模型表现异常高任务过简单或文档信息过密计算基线模型的准确率分布提升题目难度或减少冗余噪音组反而更好噪音与关键信息主题相关形成额外上下文线索查看噪音注入后的模型关注段落用语义不相关但字面相关的噪音并发组样本数不一致限流/超时导致任务中断检查每个任务的状态码和耗时添加重试机制与样本量校验6.6 两个值得一试的高级动作第一个是“交叉替换探针”。在缺口条件下故意把缺失的信息用别的关键信息替换看模型是坚持按现有信息推理还是会误用干扰信息。这个探针能精细化定位信息处理的哪个环节掉链子——是没看见还是看见了没用上。第二个是“推理步骤截断测试”。给思维链中间过程加一个“Stop”信号让模型在中途停止输出再对比不同模型的中间结果质量。这能反映推理的逐步正确率看出错误是累积还是突发的。这个动作做起来成本不高但信息量很大。7. 对实验结果负责几个容易被忽略的前提条件做归因实验最怕的是结论在一种条件下成立换掉条件就失效。有几个前提条件我在实验过程中发现它们对结论的可靠性影响巨大第一模型版本必须锁死。实验中不能出现“今天跑 A 模型的 3 月版本明天跑同名的 5 月版本”这种情况。模型迭代太快同名字不同实力的现象很常见版本不锁归因结果没有可信度。第二Prompt 模板冻结。所有组共用一套模板系统只允许信息注入和策略注入两个变量。工程上用一个模板管理配置文件模板变更走 Git 记录跑实验前确认当前分支。第三评测标准透明可复核。建议保留所有模型的原始输出供人工复核。自动评测规则也要记录在案像“多选任务的判定标准”这类细节不提前定义清楚后期统计口径很容易打架。第四实验结论的时间窗口标注。这个不是形式主义而是实际工程需要。技术迭代快同一个 Agent 用半年后的新模型重测归因结果可能会变化。在报告上写好“实验时间、模型版本、题库版本”这是对结论负责的态度。最后分享几个实操体会这个实验做下来我最大的体会是归因不是一次性的而是一个可以复用的基础设施。第一次搭建完整流程确实繁琐但之后每换一个业务场景把数据、模型、模板三个配置换掉整套流程可以快速跑出新结论。第二个体会是别纠结于“哪个能力更重要”这种抽象问题把结论绑定到具体行动上才有效。如果你发现信息访问的边际贡献高那就去调检索链路和上下文策略如果推理贡献高那就去换策略和模型。“信息访问占主导”这类结论价值在于帮你决策要不要换大模型以及如何投入成本。最后分享一个小操作实验完不要急着删中间结果把所有 JSONL 输出、打分脚本、Prompt 模板按日期归档到独立目录。不少项目在几周后会面临“这个结论当时是怎么得出来的”的追问归档完整就能快速复盘差异省下重头跑实验的时间。这套流程经历过几次迭代之后你会越来越清楚——Agent 的能力提升到底该从哪下手。