看似可信的被篡改工具返回可以覆盖先前正确的代理答案
Agents Trust Tools Too Much: Measuring Reliance on Unreliable Tools
现有对使用工具的代理的评估“主要衡量代理是否能借助工具成功完成多样任务”并且“通常假定工具返回可靠信息。” 本文针对缺失的情况:看似可信但不正确的输出。
作者“通过评估十四个大语言模型(LLM)在三种工具——网页搜索、LLM 子代理委托和代码执行——上的表现来研究代理如何应对不可靠的工具返回。” 对于每种工具,他们篡改该工具的返回并测量最终答案是否采用了被篡改的内容。一个有用的评估举措是将简单的采纳与“Override”区分开:在模型在无工具情况下已经正确回答的问题上采纳被篡改内容的情况。
决定性结果是,篡改可以替换代理原本能产生的答案。“对于 P1,在搜索中仍高于二分之一,在代码执行器中接近三分之一;在执行器中,Adoption rate 为 35.4% 而 Override rate 为 33.4%。” 此处 P1 指论文的 plausible-corruption 条件,这些数字是在其 14 模型名册上汇总得出。失败不仅仅是最终内容错误。“在采用被篡改内容的最终答案中,只有 5.3%(搜索)和 1.8%(代码执行器)会向用户发出警告。” 保留的推理痕迹提供了一个更窄且令人不安的观察: “推理模型经常能识别冲突,甚至在内部恢复正确答案,但它们的最终回应仍呈现被篡改的答案,几乎从不提及冲突或正确答案。” 该痕迹结果是针对保留思考痕迹的推理配置模型报告的,并未在所有模型配置上确立。
论文测试了提示工程、工具提供者元数据和训练后干预。其结论是保守但实用的:“尽管一些干预对特定模型或工具有帮助,但没有哪种能在所有工具上持续缓解过度信任。” 一个相关的设计结果表明工具源本身会改变行为:“代码执行显著不同。当被篡改数字由执行器返回时,Adoption rate 为 39.9%;但当该数字由用户陈述时仅为 1.8%,在 RAG 下为 3.8%。” 各呈现臂在重复和有效载荷处理上有不同细节,因此这在本设置中是有关联性的实证证据,而不是接口路径的清晰因果比较。
在重用基准时有两个边界值得注意。“新摘要是从标题生成的,而不是从源文本生成的,”这使接收的子代理没有独立的核查途径。结果标签也使用自动评判:“第二个模型家族在重叠标签上达成 98.5% 的一致率。”
一个具体的后续操作是对代理堆栈中每个工具的固定输出进行篡改,然后分别报告采纳率、Override 率以及对用户可见的冲突/披露率。关键问题不仅是代理是否在内部检测到矛盾,而是它是否要么抵抗被篡改的输出,要么将未解决的证据传达给用户。
它提供了一个针对使用工具的代理的具体鲁棒性评估模式:注入看似可信的错误,并分别度量最终答案的采纳、替换先前正确答案以及冲突披露。
来源位置
当检索到的业务规则改变计算时,模型仅达 32% 的准确率
DI-Bench: Systematically Generating In-Domain Data Intelligence Benchmarks for Enterprise Agents
基准目标
“在领域特定基准上评估企业代理至关重要,然而公开基准很少评估代理是否能够将业务知识与分析计算结合起来,而且手工构建此类基准成本高昂。” 应用于两个公开数据集,“该流水线生成了一个包含知识检索、分析计算和基于规则推理的 731 任务基准。” Source
方法:让文档改变可执行工作
“为模拟既需要计算又需要知识检索的现实 DI 任务,DI-Bench 在数据表、维度、指标和文档上构建了一个工件关联图,以形成涉及结构化数据和相关知识的问题。” 对于标签,“DI-Bench 不是让模型生成答案,而是通过对真实数据库执行 SQL 来计算每个金标准答案,从而使其具有确定性并按构造正确。” Source
对于基准设计者来说,可迁移的操作是创建这样一个实例:检索到的文档应当改变一个可执行的计算,然后对结果输出进行确定性评分。论文提供了一个关于该关联是否有影响的检查:“图选择的规则在 82% 的情况下改变了答案,而语义相似度配对为 29%,随机配对为 22%。” 一个有用的后续问题是:代理的错误是出在选择相关规则、将其翻译为查询更改,还是执行已更改的计算。
证据与适用范围
“为展示基准的区分能力和难度,我们评估了四个模型,”并且“当检索到的业务规则改变计算时,模型仅达 32% 的准确率。” 作者的解释是:“这些发现表明,检索业务知识并非企业代理的主要挑战,但在下游任务中正确地将其落地仍然是一个主要瓶颈。” Source
该结果受演示设置的限定。“该流水线在两个领域(电子商务与银行)上演示;在更多行业上的更广泛验证将加强可迁移性主张。” 此外,“演示中使用的业务规则文档和指标目录是合成增强的,而非真实企业的工件。” 最后,“评分基于完全匹配,不会对正确推理但有轻微计算误差的情况授予部分分数。” 一个决定性的扩展将是在更多行业使用真实企业工件重复文档到计算的测试,同时保留可执行的金标准答案。
阅读此文以研究一种基准设计,该设计测试检索到的业务规则是否真正改变代理的分析计算,而不仅仅测试检索本身。
来源位置
压缩的 NOTES 在测试的迁移方向上以 +9.91 或 -13.28 百分点不对称移动
Does Your Agent's Memory Survive a Model Upgrade? A Controlled Study of Memory Portability
保留代理的记忆存储并不能保证升级后的模型能使用它:作者识别了旧笔记解释改变、不兼容的嵌入版本以及在没有原始证据下的修复作为不同的失败模式。因此他们受控的问题不是存储在升级后是否存在,而是信息是否仍可用。
研究将每个 48 个合成历史保存为四种形式:逐字长上下文文本(LC-RAW)、检索块(RAG)、模型压缩的自然语言笔记(NOTES)和固定模式知识图(KG-fixed)。他们使用随机化的答案编码和精确评分,并测试了 Llama-3.1-8B-Instruct 与 Qwen2.5-7B-Instruct-1M 之间的写者–读者交换。一个单独的 RAG 实验使用单阶段余弦 top-8 检索器(无重排序器)将嵌入从 bge-large-en v1.0 升级到 v1.5。
格式比较给出了一个具体的可移植性分裂。KG-fixed 在写者变更后准确率仅变化 +0.0004 ± 0.0020,而压缩的 NOTES 则根据迁移方向分别移动 +9.91 或 -13.28 个百分点。此方向性非对称很重要:对一个写者到某读者看似安全的迁移,在反方向上可能表现不同。对于所测试的 RAG 流水线,完全重新嵌入获得了 11.90 个准确率点的提升,而旧嵌入与新嵌入 50/50 的索引仅获得 4.96。作者的分解进一步将 RAG 的 0.450 ± 0.012 的汇总差额中归因于检索的部分为 0.364 ± 0.012,描述性占比为 81%。修复结果使得操作后果更为明确:仅基于存储的 NOTES 重写在 48 个案例中没有一个在 90% 恢复目标上达到;在保留原始历史的情况下,修复在一个测试方向上在 48 个案例中有 34 个满足该目标。
编辑性研究操作:将一次升级评估为关于内存表示、写者到读者方向和嵌入版本的矩阵。将正常读取与在提供正确证据时的读取分开衡量,以避免将构造损失与检索损失混为一谈。在删除原始历史之前,测试剩余存储本身是否能达到预定义的恢复目标;仅在策略允许时保留源历史。
证据刻意狭窄。KG-fixed 的可移植性是在此工作负载和模式下证明的,并非普适的知识图优越性。检索数字适用于一个单阶段的稠密设置和两个相同维度的嵌入空间,而模型研究覆盖的是两个相近规模的开源权重模型之间的一次跨家族迁移。自然对话历史、其他模型升级和其他检索流水线可能产生不同的保留水平。
阅读此文以获取一个简洁的实验模板,用于测试代理记忆设计、向量索引迁移和修复流程在特定方向性衡量下的模型升级存活能力。
来源位置
Decompile-Diverge 在重编译之外检验行为忠实性
When LLM Decompilers Recompile More and Preserve Less
可重编译性和通过每个发布时的输入/输出测试并不能建立行为等价。论文的动机性失败是具体的:反编译得到的函数可以在发布测试上保持一致,却在其他合法输入上出现分歧;而披露的漏洞在没有可见崩溃的情况下也可能消失。Decompile-Diverge 旨在揭露这一差距,而不是将构建成功视为忠实性的充分条件。
对于每个参考函数,该方法自动合成驱动器,在编译的参考上运行 AFL++ 以扩展输入语料库,将反编译器生成的 C 输出重新编译,并在两个二进制上重放相同输入。它比较崩溃和挂起以及有界可观察后态的差异。GitHub 与 CVE 路线要求观察到的分歧在四次重跑中能够复现,使该判定器不止基于单次反例运行。
结果性测量改变了对通过发布测试的解释。在九种配置的八个系统中,尽管候选在所有发布测试上都通过,仍在生成的语料上出现分歧:总体为 4.9%,对某一系统最高达 13%,统计是基于 12,133 个通过的候选。在 300 个真实 GitHub 库函数和 287 个基于 CVE 的函数上,最强的精炼 LLM 将 Ghidra 的构建率从 75% 提高到 90%,同时其 Matched rate 从 74% 降至 62%。在 CVE 路线上,一个 LLM 精炼器在 183 次构建中有 25 次丢失了参考崩溃,导致在整个轨迹上出现 25/287 的 Crash Absence,即 8.7%。
作者的源代码级分析将分歧追溯到引入的字段、类型、被调用方和保护措施,这些替代了传统工具留存的可见未知项。这提示一个可迁移的评估操作:当模型变换可执行工件时,从参考生成输入,在两个版本上重放它们,明确定义可观察后态,并将故障行为消失记录为独立的错误类别。
该判定器并非等价性的证明。因为比较限于生成的语料和有界的可观察后态,Matched 是对所有有效输入上一致性的上界,而 Divergence 和 Crash Absence 是下界。多维数组、函数指针以及未用 AddressSanitizer 构建的函数被排除在外。因此实用的研究问题不是该判定器是否能证明反编译器,而是更广泛的输入生成和状态观察是否能在被排除的函数类中发现更多失败。
学习如何用可执行行为判定器替代重编译与发布测试成功,以揭示语义漂移和丢失的漏洞崩溃。
来源位置
CONTINUITY 在代理转换间携带签名的安全上下文并将其绑定到最终效果
CONTINUITY: Security-Context Contracts for Composable LLM Agent Controls
有何变化
论文将问题表述为组合失败:单个有用的安全控制在请求跨表示传递时可能丧失其保证。作者将此失败命名为“安全-上下文不连续(security-context discontinuity)”。一个与安全相关的事实——用于证明某一效果的理由——可能在传递过程中缺失、被削弱、在非等价模式下被重新解释、在无授权关系下被修改,或在效果发生时已陈旧。
CONTINUITY 的应对方式是用假设–保证(assume–guarantee)契约对管道组件建模,并在转换间携带已认证的上下文。其工件包括签名的根授权(signed root grants)、溯源承诺(provenance commitments)、与角色绑定的转换收据、受限类型的发布(bounded typed releases)、变换见证(transformation witnesses)和绑定效果的执行许可(effect-bound execution permits)。一次发布不是字段名白名单:它将一个经验证的源值在受限谓词和任务上下文下绑定到一个命名的目标字段。这样交接本身成为可被验证器检查的对象,而不是组件间的隐含假设。
形式化与实测证据
形式化目标是“端到端结果完整性(End-to-end Consequence Integrity, ECI)”:每一个实现的受保护效果必须具有连接主体、任务、溯源、委托、策略状态、规范化动作和终结边界的有效授权见证。若条件 C1–C7 成立,论文定理指出每一个实现的受保护效果都有有效的效果见证,且即便规划器和攻击者可写内容是对抗性的,ECI 仍然成立。模型假定不可伪造的签名和抗碰撞的摘要,且这些条件由部署的受信任计算基(trusted computing base)强制执行。
参考验证器在一个确定性的故障注入套件上进行了测试。在覆盖 128 个故障–域类别的 2,560 次攻击实例中,CONTINUITY 报告没有有害效果;它还完成了所有 700 个良性任务并升级了所有 200 个模糊任务。在设计的消融套件中,移除字段溯源、契约一致性或完全中介中的任一项都会重新打开 24 个类别。
边界与研究用途
这些结果是针对生成套件的符合性证据,而非现实世界攻击概率的估计。若受信任根、验证器或强制终结处被破坏或配置为恶意,该保证亦会失效。CONTINUITY 保留已认证的安全事实和授权决定;它并不证明这些事实本身是真实的。Python 原型已进行回归测试,但未经过形式化验证或证明其细化了抽象模型。
对一个新代理,作为边界审计操作可以采用该设计:枚举从指令到外部效果的每一次表示改变,指定必须在该改变中保存的事实与授权,将变换绑定到显式见证,并测试在移除每个验证器检查时哪个不变量会消失。研究问题是部署是否能在不使终结路径过于昂贵或过于薄弱中介的前提下生成这些工件并保护它们的根。
阅读此文以学习如何将溯源与授权从组件本地检查转变为在每一次到外部效果的转换上都可明确测试的义务。