1. 项目缘起一个反直觉的发现最近在折腾几个不同规模的LLM Agent项目时我遇到了一个挺有意思的现象让我停下来琢磨了很久。事情是这样的我手头有几个任务比如一个需要复杂逻辑推理的文本转SQL任务还有一个需要多轮对话和状态管理的客服助手Agent。我分别用了一个“大模型”比如GPT-4级别的闭源API、一个“中模型”比如一些70B参数的开源模型和一个“小模型”比如7B或13B参数的精调模型来构建这些Agent的“大脑”。按照常理我们总会觉得模型能力越强用它构建的Agent在复杂任务上的表现就应该越稳定、越“敏感”——这里说的“敏感”指的是Agent对任务指令、上下文变化或者环境反馈的响应能力和鲁棒性。换句话说大模型Agent应该像经验丰富的老手一点就透微调即灵小模型Agent可能就笨拙一些需要更明确的指令和更稳定的环境。但实测结果却让我大跌眼镜。在某些特定的、结构化的评测任务比如用Harness这类评估框架设定的基准测试中我发现了一个非单调Non-Monotone的现象并不是模型越大Agent的“敏感度”就越高。有时候中等规模的模型构建的Agent在某些任务上对提示词工程或环境扰动的“敏感度”反而比超大模型更高表现得更“脆弱”或更“不稳定”而小模型Agent在某些极其规范的任务上其行为模式可能异常地“迟钝”或者说“稳定”对变化不敏感。这个发现直接挑战了“能力即一切”的朴素认知。它暗示着当我们谈论LLM Agent的“好坏”时不能只看底层模型在标准基准测试如MMLU、GSM8K上的分数。Agent作为一个系统其“敏感度”——即系统整体行为对输入、流程、工具调用等细微变化的响应特性——是一个独立的、至关重要的评估维度而且这个维度和模型能力层级的关系并非简单的线性增长。这就像评价一辆车不能只看发动机马力模型能力还得看底盘调校、转向系统和电子稳定程序Agent的架构与敏感度。一辆马力巨大的跑车如果底盘松散在颠簸路面上可能还不如一辆调校扎实的普通轿车来得可控。本文就想结合我最近的实验和思考深入聊聊这个“敏感度非单调”的现象它背后的原因以及对我们设计、评估和部署LLM Agent有什么实实在在的启示。2. 核心概念拆解能力、Harness与敏感度在深入讨论之前我们需要先对齐几个关键概念因为标题里的每个词都有其特定的指向。2.1 LLM的“能力”层级当我们说“LLM Agent Tiers”时通常指的是基于不同能力级别的大语言模型构建的智能体。这个层级划分可以很粗略顶级/重型Agent通常基于最强大的闭源或开源模型如GPT-4、Claude 3 Opus、一些顶尖的70B参数模型。它们拥有最强的通识理解、复杂推理、代码生成和指令跟随能力。中级/均衡型Agent基于性能优秀的中等规模模型如Llama 3 70B、Qwen 72B或一些在特定领域精调的30B-70B模型。它们在成本、速度和能力之间取得平衡是许多实际应用的首选。轻型/边缘型Agent基于参数量较小的模型如7B、13B参数模型经过精调后可以在特定垂直任务上达到可用水平。它们部署成本低响应速度快但泛化能力和复杂任务处理能力有限。2.2 Harness不只是评估框架“Harness”在这里有双重含义。首先它直接指代像DeepSeek Harness、OpenCompass、AgentBench这类用于系统化评估LLM或LLM Agent的基准测试框架。这些框架提供了一系列标准化的任务如数学推理、代码生成、工具使用、多轮对话并定义了清晰的评估指标如准确率、通过率、F1分数。但“Harness”更深刻的含义是“约束与引导系统”。一个好的评估框架Harness就像一套精密的测试夹具和马具它不仅能“测量”Agent的性能更能通过其设定的任务场景、交互协议、评分规则“暴露出”Agent在特定压力或变化下的行为特质。例如一个Harness可能会测试当用户指令存在轻微歧义时Agent是否要求澄清当工具调用返回意外错误时Agent是否会尝试备选方案这些测试点就是在探测Agent的“敏感度”。2.3 敏感度Agent系统的“应激反应”指标这是本文最核心的概念。这里的“Sensitivity”不是指模型对输入词元的梯度那个是训练时的概念而是指整个LLM Agent系统其输出或行为对于系统内部或外部某些因素变化的响应程度和模式。哪些因素的变化会引发“敏感度”测试呢我总结了几类提示词工程系统提示System Prompt或用户指令User Instruction的细微改动。比如在指令末尾加上“请逐步思考” vs 不加改变few-shot示例的顺序或内容调整角色扮演描述的详细程度。上下文管理长对话历史中的信息密度、噪声无关轮次的引入、关键信息的位置在开头还是淹没在中间。工具使用与流程工具API的schema描述方式变化、工具调用失败后的重试策略、多个工具间的调用顺序逻辑。评估环境扰动在Harness测试中对标准问题题干做不影响答案的语义改写同义替换、增加干扰性上下文、改变输出格式要求。一个“高敏感度”的Agent意味着它的行为会因为这些细微变化而产生显著波动可能变好也可能变坏说明其行为边界不清晰可控性差。一个“低敏感度”的Agent则对这些变化“不感冒”行为稳定一致但这不一定好——如果是因为模型能力太弱对所有变化都“理解不了”而只能输出平庸或错误答案这种“稳定”是无益的。我们追求的往往是在关键决策点上具有“适当敏感度”的Agent该敏锐时敏锐如察觉指令歧义该稳健时稳健如面对无关干扰。3. 现象深描非单调性是如何发生的基于我自己的实验和一些公开研究的观察这种“敏感度非单调”现象在以下几种典型场景中尤为突出。3.1 场景一结构化任务中的“过度思考”与“机械执行”任务示例使用类似text2jsontext2sql的流水线。先让LLM Agent根据用户自然语言描述抽取出结构化的查询条件JSON再根据固定的模板将这个JSON转换为SQL。顶级模型Agent的表现它能力太强了。当看到抽取JSON的任务时它可能会“过度解读”。比如用户说“找出去年销售额超过100万且客户在上海的产品”它会思考“‘去年’是指自然年还是财年‘销售额’是含税还是不含税‘上海’是仅指市区还是包含郊区” 它可能会在JSON中增加一些原文未明确、但逻辑上合理的字段或注释或者要求用户澄清。在Harness测试中如果标准答案期望一个严格的、仅基于字面的JSON那么这种“过度思考”导致的输出差异就会被判为错误表现为对任务指令细节如“严格按原文信息抽取”高度敏感。中级模型Agent的表现它的能力恰好匹配这个任务。它能较好地理解指令抽取关键信息但不会进行太多“脑补”。对于上述例子它大概率会规规矩矩地输出{“time”: “last year”, “sales”: “1000000”, “location”: “Shanghai”}。它对指令中明确的格式要求如键名、数据类型敏感但对语义上的模糊地带不敏感行为相对稳定。轻型模型Agent的表现它能力有限可能只学会了最简单的模式匹配。对于稍微复杂一点的描述它可能无法完整抽取所有条件或者格式混乱。但有趣的是正因为其能力局限它对指令的细微调整比如加一句“请逐步思考”可能毫无反应因为它根本执行不了“逐步思考”这个元指令。它的错误是系统性的、可预测的表现为一种低敏感度的稳定错误。在这个场景里敏感度曲线可能是一个“倒U型”中级模型Agent最“稳定”敏感度适中顶级模型因“过度思考”而敏感度升高轻型模型因“能力不足”而敏感度看似低实则是僵化。3.2 场景二多轮对话与状态管理中的“记忆负担”任务示例一个客服Agent需要处理包含多轮信息确认、变更请求的对话。顶级模型Agent的表现拥有强大的长上下文理解和记忆能力。但这也意味着对话历史中的每一句话包括用户的随口抱怨、无关的寒暄都可能被纳入其决策考量。用户如果在第三轮说“算了刚才说的不要了”顶级Agent能很好地理解并修正状态。但如果用户说了一句有潜在歧义的话比如“和之前那个差不多就行”顶级Agent可能会翻遍历史记录去寻找“之前那个”的每一个细节导致响应缓慢或决策复杂化。它对上下文中的任何噪声都高度敏感。中级模型Agent的表现其长上下文能力可能稍弱或者我们为了效率故意限制了其关注的上下文窗口如只关注最近5轮。这反而成了一种“正则化”。它能记住关键信息但会自动“遗忘”或淡化更早的、不重要的细节。对于上述歧义句它可能更依赖最近的明确指令行为反而更直接、稳定。它对核心指令的变更敏感但对历史噪声的敏感度较低。轻型模型Agent的表现其上下文窗口和理解能力都很有限。它可能严重依赖外部设计的状态机或记忆模块。如果状态机设计得好它的行为可以非常稳定对对话中的多数自然语言变化“视而不见”只对状态机定义的触发词有反应。这种低敏感度是强架构约束的结果而非模型本身的能力。3.3 场景三工具使用与流程编排中的“灵活性陷阱”任务示例Agent需要调用搜索工具和计算工具来完成一个复杂查询。顶级模型Agent的表现它深谙各种工具的组合之道。当预设流程先A后B因为工具A暂时失败而受阻时它可能会灵活地尝试备用方案或者调整工具调用顺序。这种灵活性是强大的体现。但在Harness的标准化测试中如果测试用例默认所有工具始终可用且顺序最优那么这种“灵活应变”反而可能导致它偏离标准路径产生非预期的工具调用序列从而被扣分。它对工具可用性和环境反馈高度敏感。中级/轻型模型Agent的表现它们通常更严格地遵循预设的流程或规划plan。这可能是由于模型本身规划能力不足或者是开发者出于可控性的考虑用更严格的逻辑如基于DSL的规划器约束了它们。在工具可用的标准测试环境下它们能一丝不苟地走完流程表现稳定。但对工具失效等异常情况它们可能就直接“卡住”或报错缺乏应变能力。它们对流程本身的正确性敏感但对运行时环境变化的敏感度较低。注意这里的“非单调”不是一个绝对的定律它高度依赖于具体的任务定义、评估框架Harness的度量方式以及Agent的架构设计。同一个Agent在评估“准确性”的Harness和评估“鲁棒性”的Harness中其“敏感度”排名可能完全不同。4. 根因探究为什么大模型不等于高稳定Agent看到这里你可能会问为什么能力更强的模型反而可能构建出更“脆弱”或更“敏感”的Agent呢这背后有多层次的复杂原因。4.1 模型能力的“双刃剑”效应涌现与过度对齐大语言模型的“能力”尤其是顶级模型很大程度上来自于海量数据训练中产生的“涌现能力”。这种能力使得模型能够进行深度推理、把握微妙语义、进行联想和创造。然而在构建Agent时这些特性可能带来副作用对隐含上下文的过度探索大模型倾向于为任何输入构建一个丰富、连贯的“心理模型”。当任务指令或上下文存在一点点模糊或信息缺失时它会主动用自己的知识去“补全”而不是像小模型那样可能直接忽略或报错。在需要严格遵循明确规则的场景如代码生成、数据抽取这种“补全”就是不受控的偏差来源。对指令的“过度对齐”为了遵循“有帮助且无害”的指令大模型会对用户指令中的每一个修饰词都极其认真。例如指令中说“请详细说明”它可能就会生成冗长的解释而如果说“请简洁回答”它可能省略掉关键步骤。这种对指令字面意义的极度忠诚在动态交互的Agent场景中反而放大了提示词工程差异的影响。4.2 评估框架的“盲区”与“偏见”我们使用的Harness评估框架本身就是现象的重要塑造者。静态 vs 动态评估大多数Harness提供的是静态的、一次性的测试集。它们评估的是Agent在“理想路径”上的表现。但真实的Agent运行环境是动态的、充满不确定性的。一个在静态测试中因“灵活”而失分的Agent可能在真实动态环境中更有价值。我们的“敏感度”测量被限制在了Harness定义的静态维度里。答案唯一性假设很多Harness尤其是涉及客观知识或代码的任务预设了“标准答案”。但对于需要创造性、策略性或多步骤决策的Agent任务可能存在多个合理的解决路径等效路径。大模型Agent更可能探索出非标准但正确的路径而这在只认“标准答案”的Harness中会被判为错误表现为“不稳定”。度量指标的片面性Harness通常只报告最终的成功率、准确率。它很少量化“行为路径的方差”、“对扰动的鲁棒性”、“失败模式的可解释性”。一个Agent如果10次任务8次成功但成功的8次用了8种完全不同的策略而失败的2次原因莫名其妙那么即使它成功率不错其“敏感度”也是很高的运维和调试成本会很大。4.3 Agent架构的“放大器”与“阻尼器”作用模型只是Agent的大脑而整个Agent系统还包括记忆、规划、工具使用、反思等模块。这些架构设计会显著调制模型的原始“敏感度”。规划模块一个强大的规划器Planner可以将模糊的用户目标分解为明确的子步骤这实际上是为大模型的“自由发挥”套上了缰绳降低了其对原始指令模糊性的敏感度。相反一个简单的“ReAct”式提示则把更多的规划负担留给了模型本身放大了模型间的差异。记忆与状态管理使用向量数据库存储长期记忆还是依赖模型的上下文窗口记忆的检索策略是精确匹配还是语义搜索这些选择决定了Agent对历史信息的“敏感”程度。外置的、结构化的记忆模块可以带来更稳定、可控的记忆访问降低敏感度。工具抽象层工具的描述名称、功能、参数是如何呈现给模型的一个清晰、结构化、范例丰富的工具描述可以降低不同模型在理解和使用工具上的差异即降低系统层面的敏感度。而模糊的工具描述则会放大模型自身理解能力的差异。5. 实战启示如何设计并评估一个“稳健”的Agent理解了“敏感度非单调”的现象和原因我们在实际开发和评估LLM Agent时就应该调整思路从单纯追求“模型能力天花板”转向追求“系统行为可控性”。5.1 设计阶段为Agent系统注入“稳定性”任务与模型匹配不要无脑上最大模型。仔细分析你的任务高度结构化、规则明确的任务如数据提取、格式转换考虑使用能力适中但行为更可预测的中型模型甚至通过大量精调让小模型达到极高且稳定的准确率。避免大模型的“过度思考”。开放域、创造性、需复杂协商的任务大模型的优势明显但需要为其配备更强的“约束机制”如严格的输出格式规范、分步规划的提示、事后验证模块。架构作为稳定器强化规划与分解即使使用大模型也引入明确的规划步骤。让模型先输出计划Plan这个计划可以被解析、验证甚至由用户确认然后再执行。这能将模型的“一次敏感”决策转化为“分步可控”的过程。标准化工具交互为工具调用设计严格的、机器可读的接口如JSON Schema并让模型以固定格式如function_call输出调用请求。这减少了自然语言描述可能带来的歧义。引入外部状态机对于对话流固定的场景如客服、审批可以用一个外部的、确定性的状态机来主导流程LLM只负责处理每个状态下的自然语言理解和生成。这能极大降低整个系统对LLM输出波动的敏感度。提示词工程去敏感化明确边界在系统提示中明确指出“禁止臆测”、“仅使用提供的上下文”、“严格按给定格式输出”。提供范例Few-shot提供高质量、多样化的范例是校准模型行为、降低其对指令不同表述敏感度的最有效方法之一。范例应覆盖各种边界情况。结构化思维链要求模型使用如“Thought: ... Action: ... Observation: ...”这样的固定格式进行推理这不仅能提升可解释性也能让模型的行为模式更一致。5.2 评估阶段超越准确率测量“敏感度”我们需要建立更全面的Agent评估体系将“敏感度”或“鲁棒性”作为核心指标之一。构建“扰动测试集”在你的标准测试集基础上为每个测试用例创建多个变体指令扰动同义改写、增加无关句、调整语气正式/随意。上下文扰动在对话历史中插入无关轮次、打乱关键信息顺序。环境扰动模拟工具调用延迟、失败或返回意外结果。定义并计算敏感度指标行为一致性对于同一个核心任务在不同扰动下Agent输出的中间步骤如调用的工具、生成的计划是否一致计算杰卡德相似系数或编辑距离。性能稳定性计算Agent在原始测试集上的性能如准确率P_original与在扰动测试集上的性能P_perturbed的差值或比值。差值越小说明对这类扰动越不敏感。失败模式可归类性Agent失败的原因是否集中、可解释还是散乱无章可解释的失败模式意味着敏感度来源明确易于修复。进行分层评估不要只给一个总分。分别报告理想性能在标准、无扰动环境下的表现。鲁棒性能在扰动环境下的平均表现及方差。极端情况处理在故意设计的、具有挑战性的边缘案例上的表现。通过这样的评估你可能会发现对于你的具体业务那个在标准测试中排名第二的中型模型Agent因其极高的行为一致性和鲁棒性反而是生产环境部署的更优选择。6. 未来展望走向“可控的智能”“It‘s Not the Capability”这个观察揭示了当前LLM Agent研究与应用中的一个关键认知转折点。我们正在从对“模型能力”的盲目崇拜转向对“智能体系统特性”的工程化探索。敏感度的非单调性告诉我们更大、更强的模型并不自动意味着更好、更稳的Agent。未来的方向我认为会集中在以下几个方面模型与架构的协同设计不再将LLM视为一个黑盒而是将其作为具有特定行为特性的组件与外部架构规划、记忆、工具进行深度集成和协同优化。可能会出现更多为Agent任务专门训练或微调的模型它们在通用能力上或许有取舍但在规划可靠性、工具使用规范性、指令跟随精确性上表现更佳。评估范式的演进像DeepSeek Harness这样的评估框架将会纳入更多动态的、交互式的、测量鲁棒性和行为一致性的测试单元。评估报告将不再是单一分数而是一个多维度的“Agent特性画像”。敏感度的主动管理我们将开发出更精细的技术来主动调节Agent的敏感度。例如通过提示词、推理参数如temperature, top_p或适配器微调让同一个模型在需要创造性的任务中表现出高敏感度灵活多变在需要严格执行的任务中表现出低敏感度稳定可靠。最终我们的目标不是消除敏感度而是理解它、测量它、并最终驾驭它。就像驾驭一匹骏马我们需要的是理解它的脾气敏感度配上合适的马具架构在正确的赛道上任务发挥它的能力而不是一味地追求它跑得有多快单纯的能力指标。构建一个真正强大可用的LLM Agent这场马拉松才刚刚开始而关注其“敏感度”曲线无疑是我们找到正确配速的关键一步。
