连接代理到 AI Server：验证完整的工具调用循环

AI Server 为组织控制的基础设施上的应用程序提供兼容 OpenAI 的 API。代理集成需要比成功的聊天响应更具体的验收测试：所选模型必须提出预期的操作，且主机应用必须正确处理该提议。我们的 AI Server 产品页面描述了部署角色；以下流程描述了我们推荐的单个集成检查方法。

MLCommons 2026 年 7 月边缘代理基准文档阐明了这一区别。其示例将工具定义发送到聊天补全端点，并检查模型返回的结构化调用。[1] 仅凭端点名称无法确定每个模型、运行时和框架组合都会完成相同的工作流。

从无法更改业务数据的请求开始

选择一个可丢弃的测试工作区和一个适合任务的模型。记录服务器版本、运行时、模型标识符和代理框架版本。包括有效的端点和传输设置，但报告中不包含凭据。记录应区分被测试的安装与同名模型或仍在其他地方运行的旧服务器。

从一个普通文本请求开始。确认哪个端点接收了请求，哪个模型处理了请求，以及调用方是否收到了完整响应。通过将用于试点的框架重复此操作。直接 HTTP 成功和框架成功是两个独立观察；请保留两者结果。

使用简短且答案可预测的输入，以便轻松区分连接失败和任务难度。生成的问候语对采购工作流几乎没有信息，但它是检查路径的有用初步测试。不要仅为使初始测试更真实而添加业务凭据。

定义一个狭窄的测试操作，例如查询虚构库存中的项目。为其提供一个包含必填字段和明确允许值的小型模式。在此阶段，捕获模型提出的操作但不执行。检查操作名称、解析的参数及框架对缺失或意外字段的处理。

保持测试装置足够简单，以便人工检查每个结果。返回关于项目的合理描述的模型不一定生成了可用的工具调用。反之，格式良好的调用仍可能命名错误的项目。分别记录格式接受度和任务正确性。

如果生产应用支持流式响应，通过流式方式运行相同检查。验证消费者在解释相关结构化值前等待其完整。将流式与非流式处理的任何差异视为需解决的集成问题，而非假设成功路径涵盖两者。

提议通过验证后，允许主机调用虚构库存并将结果返回给模型。检查后续回答。应使用提供的结果并保持请求的项目身份。包括返回无匹配的查询，以便应用诚实地表示缺失。

然后执行一个需要第二次查找的简短序列。验证框架如何将每个结果与其原始调用关联，以及下一次请求如何推动对话进行。保存一个经过清理的跟踪，显示该序列但不保留真实客户文档。

这就是单轮演示变成工作流测试的时刻。跟踪应揭示错误的关联、不必要的重复或被放弃的任务。十月基准文章解释了在评估这些较长交互时，工作负载边界为何重要。

OWASP指出，过度的功能、权限和自主性是导致过度代理的原因。其指导建议将授权检查放在执行操作的系统中，并建议对高影响操作进行人工审批。[2] 对于此集成，应独立测试这些控制，无论模型通常是否请求合理的操作。

扩展虚构的库存夹具，添加一个调用者无权执行的操作。验证主机或下游服务即使在提出的参数看似有效时也会拒绝该操作。拒绝应对用户保持可理解，且不应导致框架替换为更高权限的凭证。

包含一个检索到的测试文档，其中含有无关指令。OWASP描述了通过外部内容的间接提示注入，并指出检索增强生成并不能完全消除该漏洞。[3] 此处的验收标准具体明确：检索到的文本不得赋予应用额外权限。此测试是有用的检查，而非证明所有注入尝试都会被阻止。

中断测试工具，取消请求并使依赖项暂时不可用。观察用户看到的内容以及框架的重试行为。在引入更改记录的工具之前，应达成一致，确保重试不会重复已完成的操作。该决策应属于应用设计和下游服务合同范畴。

我们提出的验收记录列出了测试的具体操作、允许的身份及任何未解决的行为。成功的库存查找应仅授权约定的试点范围。新的连接器、更广权限或不同模型应促使对受影响检查进行复审。

在部署讨论中，请携带该记录参加 Software Tailor 集成评审，如有失败示例，请附带已编辑版本。下一步有价值的工作是拥有负责人且可复现的缺口。运营交接应在初始集成工作结束后保留这些负责人。

[2] OWASP 生成式 AI 安全项目。 LLM06:2025 过度代理。2025 版。访问日期 2026-09-26。

[3] OWASP 生成式 AI 安全项目。 LLM01:2025 提示注入。2025 版。访问日期 2026-09-26。