企业级AI代理的安全工具发现方案：注册表、网关与策略机制。
面向金融服务代理的设计：工具注册表、过滤式发现机制、确定性工具网关、意图级授权以及持久性副作用处理。
来源: From Chatbots to Action-Bots: Designing Safe Tool Discovery and Authorization for Agentic AI
智能体工具背后的问题
只要为智能体提供几个API，让模型自行选择要调用的接口，工具访问问题似乎就迎刃而解了。但企业环境则完全不同——那里的工具目录中可能包含数百甚至数千种工具。有些只是无害的只读查询工具，有些则能修改客户数据或个人敏感信息，还有少数工具可以发起金融交易、重新配置账户或执行管理操作。“智能体如何找到合适的工具？”这个问题的答案相对简单，更难的问题在于如何确保智能体只能查看和使用针对特定用户请求而被允许使用的工具。
本文以此作为设计研究进行探讨，它是一种针对金融服务领域的合理架构设计，不应被视作已部署支付系统的实际报告。
将模型置于安全边界之外
实际应用中的机器学习给出了一个重要的教训：对业务至关重要的流程并不存在于模型内部。模型可以用于预测、推荐或分类，而安全保障、数据验证、业务规则、权限控制以及事务处理则属于模型之外的确定性软件。智能体能让这些规则更加严格而非宽松，因为智能体能够执行相应操作。尽管大型语言模型具备强大的推理能力，但它们仍可能不适合作为企业系统安全边界的选择。
一个简单的金融场景就能说明原因。有客户要求智能体查看最近的一笔交易，并判断是否已办理退款。智能体需要理解该请求，并使用客户查询和交易查询工具，这属于常规操作。
现在修改请求：如果退款尚未处理完成，则立即执行退款操作。此时代理不再只是获取信息，因为这可能会带来财务方面的影响。这一细微的变化正是其他所有原则的基础：
代理可以针对某个操作进行推理并提出建议，而该操作是否真正执行则由确定性平台决定。
将推理与执行分开，使得系统能够利用大语言模型的优势，同时不必依赖它们来完成那些无法可靠处理的任务。
工具注册表而非庞大的列表
智能体应如何了解有哪些工具可用？一种方法是向模型提供一份非常长的工具定义列表，让其自行判断相关性。这种方法适用于原型开发，但在企业级应用中行不通。数千条描述会带来上下文处理和延迟成本，而无限制的探索则会在没有实际益处的情况下增加安全风险。
更合适的方案是工具注册表，即企业级的能力目录。它包含的不仅仅是 API 名称和架构信息，每条记录还带有元数据，平台可以利用这些元数据进行工具发现、治理以及策略决策：
- 业务领域、负责人及版本
- 工具是只读还是可写入
- 风险等级及所需能力
- 数据分类
- 输入和输出架构
- 幂等性特征
- 审计要求
在区分不同类型的操作时，元数据最为重要。交易查询属于风险较低的读取操作，退款则是影响较大的财务写入操作，而管理操作可能带来更高的风险。这些区别无法仅体现在文档中，必须存在于平台上，这样才能让确定的基础设施据此采取行动。
发现不等于授权
这或许是整个设计中最有用的区分点：发现某个工具与获得使用它的授权是两回事。
发现功能用于确定针对某项任务应向该代理提供哪些工具；而授权功能则用于判断当前是否允许执行特定的调用。
因此，注册表的元数据会驱动在大型语言模型考虑各种选项之前的过滤步骤。首先，平台会确定用户身份、执行操作的代理、租户信息、上下文环境以及请求的目标。接着，它会筛选出符合该意图的工具，再根据代理的能力、用户的权限、租户限制、地区规定以及风险策略对候选工具进行进一步筛选。模型最终只能看到经过筛选后的结果。
不过这种过滤机制仍不能作为最后的防御手段。模型可能会发出出乎意料的调用、误解用户的意图，或受到提示注入的影响。因此，每次调用在传递到底层企业 API 之前，都必须经过受控的工具网关处理。
从概念上讲，网关会综合评估一系列事实（用户是谁、哪个代理在发起请求、请求了什么、针对哪个资源、使用何种参数、在何种上下文中），然后应用相应的匹配策略。
授权意图而非仅工具
退款示例揭示了另一个要点：授权不能仅仅取决于使用了哪种工具，还必须考虑用户的意图以及由此产生的操作。
查询退款状态与发起退款并非相同的功能：前者属于读取操作，后者则涉及财务处理。平台应明确区分这两种操作。被归类为退款状态查询的请求虽然可能会传递给客户和交易查询工具，但这一分类并不会自动授权执行退款操作。即便系统错误地判定需要发放退款，授权层仍可对比实际请求的操作与允许的意图，从而予以拒绝。
在此情况下，安全考虑的重点从“该操作员是否有权限访问退款API”转变为“在当前场景下，该用户、操作员、意图、资源及操作是否被允许”。
当工作流半途失败时
一旦某个操作被允许，就会出现第二个问题：如果工作流中的某个部分成功而另一部分失败怎么办？假设退款成功了，但确认邮件却发送失败。重新启动整个代理工作流可能会导致退款被执行两次。
一种更安全的方案是将这种副作用作为持久化工作流中的一个步骤。授权环节批准退款，随后退款API执行操作，并将成功结果存储下来。该存储的结果会触发RefundCompleted事件，进而启动通知发送。如果邮件发送失败，只会触发通知的重新发送，而财务操作则不会被重复执行。
系统中存在大语言模型并不意味着传统的企业工具集就不再需要了。重试与去重、断路器与补偿机制、幂等操作、持久化状态以及事件驱动处理依然适用。智能体可以参与决策应采取何种操作，而确定性基础设施则负责处理关键状态的变化。
审批属于策略范畴
大型语言模型也不应决定何时需要人工审批某事项，这是政策层面的问题。某个组织可能会允许低于特定阈值的退款自动处理，而高于该阈值的退款则必须经过审批；同时要求所有管理操作都必须获得批准，并对目的地异常或风险较高的交易增设控制措施。模型可以提示可能需要采取某种行动，由政策系统来判断是否需要审批，再由工具网关来执行这一决定。由于规则明确、可审查、可版本控制且可审计，并不会隐藏在提示语中，因此也有助于提升治理水平。
控制平面与执行平面
经过对这些场景的探讨后，该设计已不再像是简单的“用户→大型语言模型→工具”流程，而更像是一个企业治理平台，自然而然地分为两个部分。
控制平面是组织编写规则的场所。它包括代理目录、工具注册表、功能定义、风险等级、授权与审批策略以及通用治理设置。
执行平面则是实际运行部分。其中包含API和代理的网关、代理本身、经过过滤的发现功能、策略执行、凭证交换、正在运行的工具、工作流状态以及审计事件流。规则可以集中管理，而策略执行则更靠近工作负载运行的位置。
在大规模应用中，这种分离至关重要。当拥有成百上千个智能体以及海量工具时，没人希望每次授权检查都依赖单一的中央服务。策略在一处进行管理，而执行点则分布在各处，策略数据也会在适当情况下被缓存或复制。
评估行为，而不仅仅是答案
该设计与企业级机器学习紧密契合，同时引入了新的问题类型。传统机器学习关注准确性、数据质量、数据漂移、延迟、安全性、监控以及运行可靠性。智能体则保留了所有这些考量因素，同时还增加了对行为的评估功能。
仅有一个正确的最终答案并不足以解决问题。审核人员还需要了解该智能体是否选择了正确的工具并传入了正确的参数、是否在授权范围内行事、是否避免了不被允许的操作、是否遵循了预定的工作流程、在需要时是否向人类寻求批准，以及是否产生了预期的副作用。评估的重点从对答案的评分转向对行为的评分。
核心原则
有一条原则始终被强调：将大型语言模型视为不可信任的决策组件，绝不能将其当作安全边界。智能体可以进行推理、发现相关功能并提出行动方案。而确定性的企业基础设施则负责决定智能体可以做什么、能够访问哪些资源、哪些参数是可接受的、是否需要人类批准、如何安全地处理副作用，以及如何对整个流程进行审计。
这正是代理型人工智能所面临的真正架构挑战。让代理具备足够智能以调用工具其实还算容易，而要构建一个能让数千个代理为数百万用户提供服务、同时还能掌控其身份识别、权限管理、业务规则以及运行可靠性的平台，才是真正的难题。
相关阅读
- 能在 SQLite 数据库与网络搜索之间切换的医疗代理 —— 构建一个 LangChain 代理，使其能够判断医疗问题是需要对三个数据集进行 SQL 查询还是进行实时网络搜索，此外还介绍了两次改变设计的关键问题。