AI Agent全栈架构

主题

高频面试题

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

这道题的关键不是再讲一遍工具调用流程，而是说明当 API 数量、权限、版本和失败场景都变复杂时，Agent Runtime 如何把“动态”变成可控的工程系统。

适合阶段：Agent 平台架构 / 工具治理深挖核心能力：Tool Discovery · OpenAPI/MCP · Tool Routing · Runtime Guardrails

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

  • 动态 API 调用和普通 Function Calling 差在哪？
    考工具面很大时要运行时发现、筛选、挂载，而不只是静态 tools 数组。

  • 模型生成的参数哪些能信？
    考服务端兜底：schema、鉴权、幂等、错误恢复，模型不能自己决定任意 URL。

  • 动态挂载的安全和失败怎么治理？
    考工具检索、权限、长结果处理、审计，以及分页和重试策略。

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

text
动态 API 调用不是让模型直接拼 HTTP 请求，而是让 Agent Runtime 在运行时从 Tool Registry、OpenAPI 或 MCP 中发现候选 API，再按用户权限、任务意图、风险等级和上下文预算筛选一小组工具给模型。模型只负责选择工具和生成结构化参数，真正执行前由应用层做 schema 校验、业务校验、鉴权、高危确认和服务端身份注入。结果要以稳定 observation 回灌，错误要带可重试性和可纠正字段。高分点是安全治理：白名单、最小权限、防注入、防 SSRF、幂等、审计和停止条件。

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

这篇是对 LLM Agent 如何进行动态 API 调用？ 的深挖。基础题重点讲“动态调用的基本链路”，这里重点讲“API 面很大、权限很复杂、生产环境会失败时，怎么设计一套可靠运行时”。

1. 先把“动态”拆成三层 ​

动态 API 调用不是让模型自由拼 URL。真正动态的通常有三层：

  • 动态发现：运行时从 Tool Registry、OpenAPI 文档、MCP Server 或连接器市场拿到候选工具。
  • 动态裁剪：根据用户身份、租户、任务意图、风险等级、工具健康状态和上下文预算筛选工具。
  • 动态决策：模型在当前挂载的一小组工具中选择 API、填参数，并根据 observation 决定下一步。

稳定的部分也同样重要：

  • 模型不能直接拿生产密钥。
  • 模型不能越过服务端权限。
  • 模型不能调用任意 URL。
  • 写操作不能缺少审批、幂等和审计。

2. 标准运行链路 ​

可以用这条链路回答：

text
用户目标
  -> 任务理解和实体抽取
  -> 工具目录检索 top-k API
  -> 权限、风险、版本、健康状态过滤
  -> API 描述转成模型 tool schema
  -> LLM 输出 tool_call 和 arguments
  -> Runtime 做 schema / 权限 / 业务规则校验
  -> Connector 或 API Gateway 执行真实调用
  -> 返回结构化 observation
  -> LLM 继续调用、追问、总结或停止

面试里要强调：LLM 负责“选择”和“填参”，Runtime 负责“校验”和“执行”。如果把执行权完全交给模型，就是把安全边界放错了位置。

3. API 如何变成模型能用的工具 ​

OpenAPI 规范里每个 operation 通常包含 operationId、summary、description、parameters、requestBody、responses 和安全配置。MCP 则把外部能力抽象成 tools、resources、prompts 等 primitives。它们都不能原样塞给模型，需要做一层转译：

text
OpenAPI operation / MCP tool
  -> 规范化工具名
  -> 改写成面向模型的使用说明
  -> 提取 JSON Schema 参数
  -> 标注权限、风险、owner、版本
  -> 定义返回 observation schema
  -> 加入正反例和错误码说明

关键设计点：

  • 工具名要窄：create_refund_request 比 call_payment_api 更安全。
  • 描述要写边界：说明何时使用、何时不要使用、需要哪些前置条件。
  • 参数要强约束：类型、枚举、范围、格式、必填项都要尽量明确。
  • 身份参数要服务端注入：user_id、tenant_id、token 不能相信模型生成。
  • 返回值要稳定：给模型消费的是结构化事实，不是原始接口大包。

4. 工具选择不能把所有 API 一次性塞给模型 ​

企业系统里可能有几百甚至上千个 API。如果全部暴露给模型，会出现 tool confusion、上下文浪费和误调用。更稳妥的是“两阶段工具路由”：

text
用户任务 -> 工具检索 / 分类器 -> 候选工具 top-k -> LLM 精选和填参

候选工具筛选可以看这些信号：

  • 用户意图、领域实体和当前任务阶段。
  • API 标签、描述 embedding、历史调用样例。
  • 用户、租户、项目、数据域权限。
  • 工具风险等级：只读、写入、高危、外发。
  • 工具健康状态：是否限流、是否降级、版本是否过期。
  • 上下文预算：只挂载当前步骤真正需要的少量工具。

一个成熟回答可以补一句：高危工具不要常驻上下文，应该在用户确认或流程进入特定节点后临时挂载。

5. 参数生成后的 Runtime 校验 ​

模型输出的 arguments 只是“候选请求”，不是可信请求。Runtime 至少要做五类检查：

  • 语法检查：JSON 是否可解析，是否符合 schema。
  • 语义检查：日期范围、金额范围、枚举值、业务状态是否合法。
  • 权限检查：当前用户是否能访问目标资源、执行目标动作。
  • 风险检查：删除、付款、发邮件、改权限、部署等是否需要人工确认。
  • 注入检查：参数中是否包含可疑 URL、系统提示泄露请求、跨租户 ID 或外部指令。

服务端还要补齐可信上下文：

text
模型参数：{"ticket_title": "...", "priority": "high"}
服务端注入：tenant_id、operator_id、access_token、idempotency_key、trace_id

这样即使模型被诱导，也只能在当前权限和策略允许的范围内行动。

6. Observation 设计决定下一轮能不能修正 ​

很多 Agent 失败不是因为 API 调不通，而是因为工具结果回灌得太糟。好的 observation 应该给模型“足够继续决策”的结构化信息：

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

成功结果也要控制长度：

  • 长列表用分页、游标和 top-k 摘要。
  • 大文件或完整 JSON 落 artifact，只回传引用和关键字段。
  • 需要证据的任务保留 source id、时间戳、URL 或记录 id。
  • 数值类结果保留单位、时区和口径，避免模型二次解释出错。

7. 失败恢复：不是无限重试 ​

动态 API 调用常见失败类型和处理方向：

  • 参数错误：返回可纠正字段，让模型修正一次或两次。
  • 权限不足：不要绕路，说明缺少权限或请求用户授权。
  • 资源不存在：尝试检索候选资源，或向用户确认。
  • 限流 / 超时：指数退避、降级为异步任务、返回部分结果。
  • 工具不可用：切换备选 API 或停止并说明外部依赖故障。
  • 业务冲突：比如订单已关闭，应该让模型解释状态而不是继续强行调用。

生产里要有最大步数、最大重试次数、超时、预算和重复动作检测。否则动态调用很容易变成昂贵的循环。

8. 安全治理是高分点 ​

动态 API 调用的风险来自“可调用面扩大”。可以按层回答：

  • 入口层：识别 prompt injection、敏感意图和高危请求。
  • 工具层：工具白名单、最小权限、读写分离、风险分级。
  • 参数层：schema 校验、业务校验、服务端注入可信身份。
  • 网络层：禁止任意 URL 请求，防 SSRF、内网探测和凭据外带。
  • 执行层：高危操作人工确认、幂等 key、事务和回滚。
  • 审计层：记录用户目标、模型决策、工具参数、执行结果和停止原因。

一句话收束：动态 API 调用越强，越要把“模型的自主性”限制在“平台允许的动作空间”里。

面试官追问3个问题 ​

追问一：OpenAPI 自动转工具会有什么坑？ ​

  • 考察点：是否理解 API 文档和模型工具描述不是一回事。
  • 回答方向：自动转换能提取参数和 schema，但工具名、描述、业务前提、权限、风险等级、返回摘要通常要清洗。否则模型会选错工具、漏填参数，或者把高危 API 当普通查询用。

追问二：如果工具有 1000 个，怎么让模型选？ ​

  • 考察点：工具路由和上下文治理。
  • 回答方向：先做检索或分类，按意图、领域、权限、风险和健康状态筛出 top-k，再把少量 tool schema 给模型。必要时分层：先选工具组，再选具体 API。高危工具只在确认后挂载。

追问三：模型能不能决定访问哪个 URL？ ​

  • 考察点：网络安全边界。
  • 回答方向：一般不能让模型任意访问 URL。应该通过白名单 connector、域名 allowlist、URL 参数校验和 SSRF 防护限制网络访问。模型可以表达意图，真实网络请求由受控工具执行。

扩展知识 ​

OpenAPI、MCP、Function Calling 的分工 ​

  • OpenAPI：描述 HTTP API 的机器可读契约，适合从已有 REST 服务生成工具。
  • MCP：描述 Agent Host 与外部工具/资源之间的标准连接方式，适合跨工具生态复用。
  • Function Calling / Tool Calling：模型 API 层表达“调用哪个工具和参数”的结构化输出能力。
  • Agent Runtime：真正负责循环、校验、执行、回灌、停止和审计。

工具描述为什么要重写 ​

很多 OpenAPI 文档是写给后端工程师看的，不是写给模型做选择的。常见问题包括：

  • operationId 命名重复或太抽象。
  • description 只写“create item”，没有说明业务前提。
  • 参数嵌套太深，模型难以一次填对。
  • 返回值包含大量字段，模型抓不住关键事实。
  • 安全规则在网关或代码里，文档里没有体现。

所以生产系统常常会给 API 增加一层 agent-facing metadata。

评估动态 API 调用要看什么 ​

  • 工具选择准确率：是否选对 API。
  • 参数准确率：必填、类型、枚举、业务规则是否正确。
  • 权限违规率：是否尝试访问不该访问的资源。
  • 恢复成功率：API 报错后能否修正或停止。
  • 成本和延迟：工具检索、模型轮次、API 调用是否可接受。
  • 审计可读性：出问题时能否复盘每一步为什么发生。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构