工具越多，智能体反而越容易犯错
给智能体接工具这件事，工程团队普遍经历过一个反直觉的阶段：一开始只接三五个工具时，效果稳定；随着工具目录扩大，表现不是线性变好，而是开始变差。
来自 UIUC 的研究者在 2026 年 9 月的一篇论文里，把这个现象拆成了两个具体问题。
一个是工具之间的交互脆弱性。多步骤、多轮推理中，模型需要把前一个工具的输出正确映射成后一个工具的输入。但现实里的工具 API 结构异构，输出格式五花八门，模型很容易在这一步错位——不是能力不够，而是接口之间的语义缝隙太宽。
另一个是大工具目录下的性能退化。论文给出的数据是，当工具规模从 8K token 扩到 120K token 量级时，准确率下降幅度在 7% 到 85% 之间。这个区间跨度很大，说明退化程度与任务类型、工具描述质量密切相关，但方向是确定的：把上百个工具的 schema 全部塞进上下文，模型会失焦。
针对这两点，论文提出了 HEART，全称是 Harness Engineering via Agent-native, Reusable Tool Primitives，即「通过智能体原生的可复用工具原语做 harness 工程」。
核心动作：把接口描述从 schema 换成自然语言
HEART 里最关键的设计叫 Tool Primitives，工具原语。它的做法是用自然语言接口替代传统的 API schema。
这个替换的意义值得展开。传统做法里，一个工具的能力边界由它的参数结构定义：有哪些字段、什么类型、是否必填、取值范围是什么。模型必须准确理解这套结构化描述，并按要求构造调用参数。这要求模型的输出严格符合格式，任何字段名或嵌套层级上的偏差都会导致调用失败。
换成自然语言接口后，工具对外暴露的是「我能做什么」的说明，而不是「你必须怎么填参数」的规格。参数映射与调用分派的职责被移交给框架内部的专门组件。这样做的直接效果是把格式正确性的负担从模型侧转移到工程侧，模型只需要表达意图，不需要同时当接口工程师。
第二个组件叫 ToolFace，可以理解成一个工具仓库。它支持动态检索——不是把全部工具塞进上下文，而是根据当前任务按需取出相关工具。这直接对应前面提到的退化问题：控制进入上下文的内容量，是缓解大目录失焦最直接的手段。
第三个组件是 HEART 本身的多智能体结构，由 Planner、Router、Verifier 三个角色组成。Planner 做意图分析并检查信息是否充足，不足时向用户索取缺失的细节；Router 负责参数映射并把调用分派给 ToolFace 中对应的工具原语；Verifier 评估任务完成情况、参数一致性、执行有效性与约束满足情况。如果验证不通过，会向 Planner 返回结构化反馈，触发重新规划。
这三个角色构成的循环，本质上把「调用工具」这件原本由单个模型一口气完成的事，拆成了规划、执行、校验三段。它的代价是更多的模型调用与更长的链路；收益是每一段都有明确的输入输出契约，出错时能定位到是哪一段失效。
五个基准上的结果，以及一个安全侧的观察
论文报告在五个基准上给出了结果，重点是性能对比与成本优势。摘要层面的信息到这里为止，具体的基准名称、对照组设置与绝对数值需要查阅论文原文。
有一个方向值得单独提出来：论文提到该方法在提示注入攻击场景下表现出免疫性。这个说法需要谨慎理解。工具原语把自然语言描述作为接口，理论上减少了攻击者通过伪造结构化 schema 来诱导调用的空间，但这不等于消除了提示注入风险——注入可以发生在工具返回的内容里、发生在用户输入里，也可以发生在被检索到的知识库文本里。更准确的理解应该是：这套设计在架构上减少了某一类攻击面，而不是让系统对提示注入免疫。
论文也明确列出了限制。一是 token 消耗问题——多智能体循环、动态检索、验证反馈都会增加调用量，成本不是免费的。二是人工 schema 维护的问题——工具原语虽然换成了自然语言，但这些描述仍然需要人写、需要人维护，且随着工具演进要持续更新。这实际上是把维护工作从「写结构化定义」变成了「写清晰的说明文档」，工作量未必减少，但对人的技能要求变了：更依赖表达能力，而不是对某个格式规范的熟练度。
中立思辨
需要辩证看待几件事。其一，自然语言接口与结构化 schema 之间不是简单的替代关系。结构化描述的优势是确定性与可校验性，机器可以在调用前完成参数合法性检查；自然语言描述的优势是灵活与容错，但把校验责任推给了框架。在强约束场景，例如金融交易与医疗操作，结构化契约仍然有不可替代的位置。更可能的演化方向是两者并存：对外暴露自然语言说明，内部保留结构化校验。
其二，多智能体结构的收益与成本需要按场景核算。Planner、Router、Verifier 三段循环在复杂多步任务上能提升可靠性，但在单步简单任务上是纯粹的额外开销。判断是否引入，取决于任务的失败代价——如果一次错误调用的后果可以轻易回滚，那么多一层验证未必划算。
其三，论文中关于准确率下降 7% 到 85% 的区间表述，说明大工具目录下的退化并没有统一规律。这提示工程团队不应把这组数字当作普适结论，而应把「工具数量对自家任务的影响」当成一个需要实测的变量。
其四，本文引用的技术细节与结论来自对该论文的二手整理与摘要信息，工程团队在据此调整架构前，应查阅原文核对实验设置、对照组与完整数值。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
对工程实践的三点启发
无论这套框架最终是否被广泛采用，它指向的三个做法都有直接的实践价值。
一是控制进入上下文的工具数量。当工具目录超过一定规模，全量注入几乎必然导致表现下降。按任务动态检索相关工具，是当前性价比最高的优化之一。很多团队的工具调用质量问题，本质上是上下文管理问题。
二是给工具写「人话」说明。工具描述的质量直接决定模型能否正确选择与使用它。一个常见的失误是把内部接口文档原样贴进去，里面满是缩写与实现细节，而模型需要的是「什么情况下该用这个工具、用它会得到什么、有什么副作用」。
三是在关键链路上加一层验证。不是所有调用都值得校验，但涉及写入、对外发送、资金变动这类不可逆动作时，一个独立的校验环节能拦住大部分因为参数错位导致的错误。这层校验用模型做还是用规则做，可以按成本决定，但位置应该留在那里。