AI Agent全栈架构

主题

高频面试题

LLM Agent 如何进行动态 API 调用？

动态 API 调用的难点不是把 HTTP 请求发出去，而是让 Agent 在运行时安全地发现可用 API、选择正确接口、生成合法参数、处理错误并把结果纳入下一轮决策。

适合阶段：Agent 工具调用 / 平台架构面核心能力：Function Calling · Tool Registry · OpenAPI · MCP · Guardrails

面试官角度分析，想考什么 ​

  • 什么叫动态 API 调用？
    考运行时发现并挂载 API，而不是把所有接口写死在 prompt 里。

  • 模型如何选接口、填参数？谁执行？
    考 schema 给模型、模型填参、应用层校验鉴权后真正调用。

  • 失败、超长返回和安全风险怎么处理？
    考错误回灌、结果摘要、白名单和最小权限，禁止通用 http_request 裸奔。

可直接抄走的 30 秒参考答案 ​

text
LLM Agent 做动态 API 调用时，一般不会让模型自由拼 HTTP 请求，而是把 API 通过工具注册表、OpenAPI 或 MCP 转成受控 tool schema。运行时先根据任务和权限筛选当前可用 API，把少量工具描述给模型；模型返回工具名和结构化参数；应用层做 schema 校验、鉴权、风险审批和真实 HTTP / RPC 调用；结果再作为 observation 回灌给模型。如果失败，要返回结构化错误让模型重试、换工具、追问或停止。安全上要做最小权限、服务端注入身份、危险动作确认和完整审计。

面试回答详解，知其所以然 ​

动态 API 调用不是“让模型随便拼 URL”。成熟做法是把 API 包装成受控工具，让模型只在白名单和 schema 约束内选择和填参。

1. 动态 API 调用解决什么问题 ​

固定工具调用通常是工程师提前写好几个函数：

text
get_weather(city)
create_ticket(title, description)

动态 API 调用更进一步：Agent 可以在运行时根据任务、用户权限和工具元数据，从一批候选 API 中选择合适接口，甚至从 OpenAPI / MCP 描述中加载新工具。

典型场景：

  • 企业 Agent 根据用户任务调用 CRM、工单、日历、知识库、数据平台 API。
  • API 很多，不可能每个都手写 prompt。
  • 不同用户、租户、项目可见 API 不同。
  • 任务中途发现需要某个新能力，再动态挂载对应工具。

2. 基本架构 ​

一个稳妥的动态 API 调用链路是：

text
用户目标
  -> 识别意图和权限
  -> 从 Tool Registry / OpenAPI / MCP 发现候选 API
  -> 过滤和压缩成当前可用 tool schema
  -> LLM 选择工具并生成参数
  -> Runtime 校验 schema、权限和风险
  -> API Gateway / Connector 执行真实调用
  -> 返回结构化 observation
  -> LLM 继续推理或输出最终答案

核心原则是：动态的是“选择哪些 API、如何填参数、下一步是否继续”，不是“绕过治理随便访问网络”。

3. API 来源：工具注册表、OpenAPI 和 MCP ​

常见 API 来源有三类：

  • 工具注册表：平台把内部 API 封装成工具，维护名称、描述、参数 schema、权限、风险等级、owner、版本和示例。
  • OpenAPI 文档：从机器可读 API 描述中提取 endpoint、method、parameters、requestBody 和 response schema，再转换成 tool schema。
  • MCP Server：工具提供方通过 MCP 暴露 tools、resources 和 prompts，Agent Host 动态列出工具并调用。

面试里可以强调：无论来源是什么，最终都要转成模型能理解的工具描述和参数 schema，并经过权限和策略过滤。

4. 从 API 到 tool schema ​

模型不适合直接阅读几百页 API 文档。平台通常会做一层适配：

text
OpenAPI operation / MCP tool
  -> 规范化名称
  -> 简化描述
  -> JSON Schema 参数
  -> 返回值摘要说明
  -> 权限和风险元数据
  -> few-shot 示例

设计 tool schema 时要注意：

  • 工具名清晰，避免 call_api 这种万能入口。
  • 描述写明何时使用、何时不要使用。
  • 参数类型、必填项、枚举值和格式要严格。
  • 危险参数要单独标记。
  • 返回值要结构化，避免把原始长 JSON 直接塞回模型。
  • 同类 API 太多时，先做路由或检索式工具选择。

5. 模型选择 API，应用层执行 ​

调用时，模型看到的是当前允许使用的一小组工具。它返回类似：

json
{
  "tool": "create_support_ticket",
  "arguments": {
    "title": "用户无法登录",
    "priority": "high"
  }
}

然后应用层执行：

  • 校验 JSON schema。
  • 校验用户是否有权限。
  • 检查是否高危操作。
  • 补充服务端可信参数，例如 tenant_id、user_id。
  • 调用真实 HTTP / RPC API。
  • 处理错误、重试、限流和超时。
  • 把结构化结果回传给模型。

这里不能让模型提供所有敏感参数。比如 tenant_id、操作者身份、鉴权 token 应由服务端注入，而不是从模型参数中相信。

6. 动态工具选择：不要一次给模型所有 API ​

如果企业有几百个 API，全部塞进上下文会带来 tool confusion。常见做法是两阶段：

text
任务 -> 检索候选工具 top-k -> 给模型少量工具 schema -> 模型选择并填参

筛选依据包括：

  • 用户意图和实体。
  • 工具描述和标签。
  • 用户、租户、项目权限。
  • API 风险等级。
  • API 健康状态和版本。
  • 当前任务阶段。

高风险 API 可以只在用户确认后临时挂载。

7. 错误处理和结果回灌 ​

API 调用失败时，不要只返回“失败了”。更好的 observation 包括：

  • 错误类型：权限、参数、网络、限流、业务校验、资源不存在。
  • 是否可重试。
  • 可纠正字段。
  • 部分结果。
  • 建议下一步。

例如：

json
{
  "status": "error",
  "code": "VALIDATION_ERROR",
  "retryable": false,
  "message": "priority must be one of low, medium, high",
  "field": "priority"
}

模型拿到结构化错误后，才能修正参数、换 API、询问用户或停止。

长结果也要治理：

  • 分页和游标。
  • 只返回 top-k 关键字段。
  • 工具层先摘要。
  • 大结果落 artifact，只把引用和摘要放进上下文。
  • 需要精确证据时保留 source id。

8. 安全边界 ​

动态 API 调用的风险比固定工具更高，因为可调用面更大。必须控制：

  • 工具白名单：模型只能调用当前授权工具。
  • 最小权限：按用户、租户、项目过滤 API。
  • 服务端身份注入：不要让模型决定 tenant、user、token。
  • 危险动作审批：删除、支付、发信、改权限、部署等需要确认。
  • 参数校验：JSON schema、业务规则、枚举、范围、正则。
  • 网络边界：防止 SSRF、任意 URL 请求和内网探测。
  • Prompt injection 防护：网页或工具结果不能指挥 Agent 扩权。
  • 审计和幂等：记录谁在何时因什么任务调用了哪个 API，写操作要有 idempotency key。

动态 API 调用的成熟度，主要看治理，而不是 API 数量。

面试官追问3个问题 ​

追问一：Agent 怎么从几百个 API 中选对一个？ ​

  • 考察点：工具路由和上下文预算。
  • 回答方向：先按权限和任务意图过滤，再用工具描述、标签、embedding / BM25 检索候选 top-k，只把少量相关 schema 给模型。必要时用二级路由或让模型先选 domain，再选具体工具。

追问二：能不能给 Agent 一个通用 http_request 工具？ ​

  • 考察点：安全和可控性。
  • 回答方向：一般不建议。万能 HTTP 工具容易造成 SSRF、越权和不可审计。更稳的是把 API 封装成明确工具，限制域名、路径、方法、参数和权限；少数内部调试场景也要强沙箱和审批。

追问三：模型生成的参数不合法怎么办？ ​

  • 考察点：错误恢复。
  • 回答方向：执行前做 JSON schema 和业务规则校验，把结构化错误回传给模型，让它修正。多次失败后停止或追问用户。不要把非法参数直接透传给后端。

扩展知识 ​

OpenAPI 到 Function Calling 的常见转换 ​

OpenAPI 的 operation 可以转换成模型工具：

text
operationId -> tool name
summary / description -> tool description
parameters + requestBody -> JSON Schema
responses -> tool result schema / summary
security -> permission metadata

但转换后通常要人工或自动清洗描述。很多 OpenAPI 文档是给开发者看的，不一定适合模型选择工具；描述过短、命名重复、参数过深都会降低调用质量。

MCP 在动态 API 调用中的位置 ​

MCP 解决的是 Agent 和外部工具 / 资源的标准化连接。对于动态 API 调用，MCP Server 可以把一组外部能力暴露成 tools，Host 在运行时列出工具，再把它们转换给模型使用。

可以这样理解：

text
Function Calling = 模型如何表达“我要调哪个工具”
MCP = 工具提供方如何被 Agent 标准化发现和调用
OpenAPI = HTTP API 如何被机器可读地描述

三者经常组合使用。

动态 API 调用和 API Gateway ​

企业里通常不会让 Agent 直接访问每个后端服务，而是通过 API Gateway 或 connector 层：

  • 统一鉴权。
  • 统一限流和熔断。
  • 统一审计。
  • 统一脱敏。
  • 统一错误格式。
  • 统一 schema 版本。

这能把 Agent 的非确定性隔离在平台层，避免后端服务直接暴露给模型决策。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构