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 场景一：结构化任务中的“过度思考”与“机械执行”
任务示例：使用类似text2json+text2sql的流水线。先让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，这场马拉松才刚刚开始，而关注其“敏感度”曲线，无疑是我们找到正确配速的关键一步。
