Prompt 表面积问题：为什么增加一个工具绝不仅仅是增加一个工具

每一个交付过 LLM 驱动的智能体（Agent）的工程师都曾被一个简单的思维模型所诱惑：工具就是一个函数。增加一个工具意味着智能体多了一项功能。其成本仅仅是系统提示词（System Prompt）中的几行文档，或许是一个 Schema 定义，又或者是工具注册表中的一个新条目。这给人的感觉是累加的——线性增长。

事实并非如此。每一个新工具并不只是孤立地扩展智能体的能力；它扩展的是该工具与已有所有工具组合后能产生的能力。这种区别是一类生产环境故障的根源，这类故障在事后无论如何调整提示词都无法修复，因为问题出在架构层面。“提示词表面积”（Prompt Surface Area）问题是真实存在的，它会迅速复合增长，而大多数团队直到深陷其中时才察觉。

什么是“提示词表面积”的真正含义

安全领域的“表面积”是指攻击者（或 Bug）可以进入的所有位置的总和。在传统软件中，表面积随着暴露的 API、开放端口和不受信任的输入而增长。在 LLM 智能体中，它随着每一段影响行为的自然语言而增长：系统提示词指令、工具描述、few-shot 示例、检索到的上下文、用户消息以及工具本身的名称。

关键属性在于所有这些因素都会相互作用。当你添加一个名为 send_email 的新工具时，你不仅仅是添加了电子邮件功能。你还为每一个现有工具创造了新的交互路径。文件读取工具现在可以与 send_email 结合来窃取内容。网页搜索工具可能会搜出一段内容，诱导智能体以你未曾预料的方式使用 send_email。规定智能体在行动前何时应确认的指令，现在也必须考虑 send_email——而且智能体对这些指令的解读在不同的工具组合下并不相同。

这是核心问题：智能体的配置空间不是其各部分之和。它更接近于各部分的乘积。

复杂度并非线性扩展

考虑一个拥有 5 个工具和 10 条指令系统提示词的智能体。该智能体的行为空间并不是 5 + 10。它是工具调用的每一种可能排序和组合，是每一对在边缘条件下可能发生冲突的指令，以及工具输出与随后模型决策之间的每一次交互。

增加第 6 个工具。你并没有增加十六分之一的复杂度——你为已经存在的每一个交互矩阵增加了一个新的维度。如果现有的 5 个工具产生 5 种可以作为下游工具调用输入的输出类型，那么第 6 个工具可以与所有这些类型交互。如果系统提示词有 10 条指令，其中一部分现在会以编写这些指令时从未测试过的方式应用于第 6 个工具。

这就是为什么团队经常观察到一种失败模式：智能体在有 3 到 4 个工具时表现良好，随着产品需求增长扩展到 6 到 7 个工具时，就开始表现出谁也无法轻易追踪到具体变更的行为。这些行为并不是新功能的失效——而是旧功能与新功能以评估（Evals）从未覆盖的组合方式进行交互的结果。

评估差距的拉大速度超过了工具差距

智能体的基准测试和评估套件几乎总是孤立地或在特定的短序列中测试工具。它们不会在对抗性组合、并发使用模式或跨工具交互效应下测试工具，而这些效应只有当具有广泛能力的智能体接到一个定义模糊的任务并决定如何拆解任务时才会显现。

结果是一个结构性的评估差距：随着工具数量的增加，可能的智能体运行轨迹空间增长速度远超任何评估套件的跟进速度。一个系统可能在单独测试每个工具的基准测试中获得高分，但在生产环境流量会触发的数百条工具组合路径上完全没有经过测试。

这种差距不是人员配备问题或懒惰问题。它反映了一个真正的困难：智能体轨迹的组合爆炸意味着在一定规模下，全面的覆盖在计算上是不可行的。一个交付了拥有 12 个工具的智能体并假设其针对每个工具的评估提供了有效覆盖的团队，是运行在一种虚假的安全感之上。这些评估衡量的是真实的东西——但它们衡量的只是实际行为空间中一个微小且有利的子集。

当系统提示词成为攻击面

系统提示词不仅仅是指令——它是智能体决策边界的清晰规范。如果攻击者能阅读你的工具描述和一些交互示例，他们就能推断出你的系统提示词可能禁止什么，以及哪里可能存在漏洞。让系统提示词变得灵活的自然语言，同样也是让它们变得易被利用的自然语言。

这一攻击面随工具数量直接扩展。2025 年发表的一项研究展示了一类名为 ToolHijacker 的攻击：通过向智能体的工具库中注入一个恶意的工具文档，攻击者可以可靠地将智能体引导至攻击者选定的工具来执行特定任务。库中的工具越多，可供操纵的选择面就越大。

更广泛地说，间接提示词注入（即对抗性指令被嵌入到智能体检索或处理的内容中）随着工具的增多而变得更加危险。一个拥有文件读取器、浏览器和邮件发送器的智能体，可能会通过网页中插入的一条指令被胁迫执行三步内容窃取序列。同样的注入对于只拥有计算器的智能体来说是无害的，但在智能体拥有广泛能力时则会变成一个关键漏洞。

并集属性在这里同样适用：当工具具有不同的权限模型时，智能体的有效权限是所有工具权限的并集，而不是交集。如果架构没有显式阻止这种组合，一个拥有只读数据库工具和启用写入权限的外部 API 的智能体，可以完成只读工具本应防止的写入操作。

爆炸半径问题

智能体设计中的“爆炸半径”（Blast radius）是对以下问题的回答：如果该智能体由于漏洞、错误的指令或成功的攻击而产生错误行为，它所能造成的最大损害是什么？

如果只有一个工具，爆炸半径被该工具的能力所限制。如果有十个工具，爆炸半径则受所有工具能力组合的限制——并且可能由于反馈循环而放大，其中工具的输出成为触发进一步工具调用的输入。一个拥有文件系统访问权限、网络访问权限和电子邮件访问权限的智能体，其爆炸半径包括向任意接收者发送任意内容并持久化任意文件——这种组合比任何单个工具的爆炸半径都要严重得多。

对于生产环境而言，重要的爆炸半径问题不仅是“会出什么错？”，还包括“恢复时间是多少？”。一个可以删除文件的智能体通过从备份恢复来完成恢复。而一个既能删除文件又能发送电子邮件的智能体，可能会在删除行为被察觉之前就外泄数据。随着爆炸半径的扩大，恢复窗口会随之缩小，这意味着任何故障的后果都会随着工具数量的增加而呈比例增长，这种方式在单独评估单个工具时往往并不明显。

表面积审计

在向现有智能体添加工具之前，表面积审计会提出四个问题：

该工具的输出类型开启了什么？ 工具的输出会成为其他工具调用的潜在输入。一个返回用户数据的工具会创造一条路径，使得该数据可以被传递给任何接受字符串输入的其他工具。将输出类型映射到潜在的下游用途，可以在这些交互路径变成实时漏洞之前揭示它们。

哪些现有指令变得模糊或不足？ 每一个系统提示词（system prompt）指令在编写时都考虑了一组特定的工具。当添加新工具时，原本看似精确的指令会变得定义不足。“在执行不可逆操作之前请求确认”是在新工具存在之前编写的——那么新工具是否构成不可逆操作？答案至关重要，且模型的回答可能与预期的回答有所不同。

评估套件（eval suite）是否练习了该工具与其他工具的组合？ 如果答案是否定的，那么发布该工具就意味着发布了未经测试的表面积。问题不在于该工具是否能独立工作，而在于评估覆盖范围是否反映了该工具与现有能力结合时所创造的实际行为空间。

新的爆炸半径是什么，恢复计划又是什么？ 添加一个改变爆炸半径类别（例如，从“可能损坏本地状态”变为“可以向外部传输数据”）的工具，理应受到按比例更加谨慎的审查。缩短恢复窗口的爆炸半径变化需要明确的缓解措施，而不仅仅是文档记录。

淘汰能力的纪律

团队经常谈论添加工具，却很少谈论淘汰（retiring）它们。这种不对称性代价高昂。

一个无限扩展工具集的智能体会不断累积曾经需要但现在可能不再需要的表面积。软件工程团队应用于弃用 API 和未使用功能标志（feature flags）的季度审查流程，在大多数智能体开发工作流中并没有对应的环节。其结果是，智能体的系统提示词中包含了一些为了处理六个月前的边缘情况而存在的工具文档，其中每一个都依然是一个交互路径、一个评估缺口和一个爆炸半径的贡献因素。

淘汰一个智能体的能力需要撤销其工具定义、从系统提示词中删除其文档、验证现有的评估不依赖于它，并且——关键的一点——确认删除它不会无意中破坏将其作为非显式中间步骤的任务。最后一点通常是淘汰工作停滞不前的原因：团队担心未知的依赖关系，宁愿保留工具也不愿冒险发生回归。

解决办法是架构性的而非操作性的：采用拥有少量高质量工具的智能体，每个工具都有明确的所有权边界和明确的使用场景，这样既容易进行彻底评估，也容易在不产生副作用的情况下进行修改。工人模式智能体架构（Worker-pattern agent architectures）——由专门的子智能体处理具有各自作用域工具集的明确任务——通过保持每个智能体的表面积小且受限，实现了这一点，即使整个系统的能力在增长。

这对智能体设计意味着什么

实际的意义在于，智能体的能力应该被视为一种具有持有成本的稀缺资源，而不是一种免费的附加物。添加到智能体中的每一个工具都应该对“这在表面积上花费了多少成本？”有明确的回答，而不仅仅是“这能实现什么？”。

对于构建生产级智能体的团队来说，这可以转化为几个具体的实践。工具数量应保持在任务要求的最低限度，并倾向于将大型智能体拆分为较小的专用智能体，而不是扩展单个智能体的能力。评估套件的设计应覆盖工具组合，而不只是单个工具的性能。每当工具集发生变化时，都应审查系统提示词指令，因为为五个工具的智能体编写的指令对于十个工具的智能体来说可能是实质性错误的。此外，对于任何改变智能体权限范围的新工具添加，爆炸半径评估都应成为设计评审的一部分。

智能体库中的工具不是功能（features），而是承诺（commitments）——承诺在评估中覆盖它们的交互，在系统提示词中限制它们的滥用，并在智能体演进时重新审视它们。将添加工具视为设计决策而非配置更改的团队，将构建出更强大且更受控的智能体。不这样做的团队最终会遇到任何单个工具审查都无法预测的突发故障——并发现自己正在调试一个表面积早已超出其理解范围的系统。