基于大模型的 API 调用链自动构建技术调研报告

调研主题： 基于大模型的 API 调用链自动构建技术 所属领域： Agent / LLM Tool Use / Workflow Orchestration 调研日期： 2026-04-07 报告版本： 1.0

目录

1. 维度一：概念剖析
2. 维度二：行业情报
3. 维度三：方案对比
4. 维度四：精华整合
5. 参考文献与资源

维度一：概念剖析

1. 定义澄清

通行定义

基于大模型的 API 调用链自动构建技术（LLM-based Automatic API Call Chain Construction）是指利用大型语言模型（LLM）的语义理解、逻辑推理和代码生成能力，将用户的自然语言需求自动转换为可执行的多步 API 调用序列的技术。该技术的核心在于让 LLM 不仅理解"做什么"，还能自主规划"怎么做"——包括 API 的选择、参数填充、调用顺序编排、错误处理以及结果整合。

这一技术是 Agentic AI（代理式人工智能）的核心能力之一，代表了 AI 系统从被动响应到主动执行的范式转变。

常见误解

边界辨析

2. 核心架构

┌──────────────────────────────────────────────────────────────────┐
│                    API 调用链自动构建系统架构                      │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  用户自然语言请求                                                  │
│         ↓                                                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    理解层（Understanding）                │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │    │
│  │  │ 意图识别     │→ │ 实体抽取     │→ │ 约束条件解析     │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘  │    │
│  └─────────────────────────────────────────────────────────┘    │
│         ↓                                                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    规划层（Planning）                     │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │    │
│  │  │ API 检索匹配  │→ │ 依赖分析     │→ │ 执行顺序生成     │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘  │    │
│  │         ↓                ↓                ↓              │    │
│  │  ┌─────────────────────────────────────────────────┐    │    │
│  │  │              调用链 DAG 生成                       │    │    │
│  │  └─────────────────────────────────────────────────┘    │    │
│  └─────────────────────────────────────────────────────────┘    │
│         ↓                                                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    执行层（Execution）                    │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │    │
│  │  │ 参数填充     │→ │ API 调用执行  │→ │ 结果收集整合     │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘  │    │
│  │         ↓                ↓                ↓              │    │
│  │  ┌─────────────────────────────────────────────────┐    │    │
│  │  │           错误处理 / 重试 / 回滚机制                │    │    │
│  │  └─────────────────────────────────────────────────┘    │    │
│  └─────────────────────────────────────────────────────────┘    │
│         ↓                                                        │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    输出层（Output）                       │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │    │
│  │  │ 结果格式化   │→ │ 自然语言总结  │→ │ 执行 trace 记录   │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘  │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    支撑组件                               │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │    │
│  │  │ API Registry │  │ Schema Store │  │ Auth Manager    │  │    │
│  │  │ (API 注册表)  │  │ (Schema 库)   │  │ (认证管理)      │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘  │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

各组件职责说明：

3. 数学形式化

3.1 调用链的形式化定义

一个 API 调用链可形式化为有向无环图（DAG）：

其中：

• $\mathcal{A} = \{a_1, a_2, ..., a_n\}$ 是 API 调用节点集合
• $\mathcal{E} \subseteq \mathcal{A} \times \mathcal{A}$ 是依赖边集合，$(a_i, a_j) \in \mathcal{E}$ 表示 $a_j$ 依赖 $a_i$ 的输出
• $\Phi: \mathcal{A} \rightarrow \mathbb{P}(\text{Params})$ 为每个 API 分配参数映射

解释： 调用链是一个 DAG，节点是 API 调用，边表示数据依赖关系。

3.2 参数填充的约束满足问题

参数填充可建模为约束满足问题（CSP）：

其中：

• $\mathcal{D}_i$ 是参数 $p_i$ 的定义域（由 API schema 约束）
• $C_j$ 是业务逻辑约束（如"结束时间必须晚于开始时间"）

解释： 参数填充需要同时满足类型约束和业务规则约束。

3.3 执行成功率模型

调用链的整体成功率可建模为：

其中：

• $P_{\text{plan}}$ 是 LLM 生成正确执行计划的概率
• $P_{\text{fail}}^{(i)}$ 是第 $i$ 个 API 调用的失败率
• $r_i$ 是第 $i$ 个 API 的最大重试次数

解释： 整体成功率取决于规划正确率和各 API 的可靠性，重试可以提升单点可靠性。

3.4 延迟模型

端到端延迟由序列化执行和并行执行两部分组成：

其中：

• $T_{\text{LLM}}^{(k)}$ 是第 $k$ 步 LLM 推理延迟
• $T_{\text{API}}^{(k)}$ 是第 $k$ 步 API 调用延迟
• CriticalPath 是 DAG 的关键路径（最长依赖链）

解释： 总延迟由关键路径上的 LLM 推理和 API 调用时间决定，优化需聚焦关键路径。

3.5 成本模型

调用链的经济成本包括 LLM Token 成本和 API 调用成本：

其中：

• $\alpha$ 是 LLM 每 Token 的单价
• $\text{Tokens}_{\text{input/output}}$ 是规划阶段的输入输出 Token 数
• $\text{Cost}_{\text{API}}^{(i)}$ 是第 $i$ 个 API 的调用成本

解释： 总成本是 LLM 使用成本和外部 API 成本之和，优化需权衡两者。

4. 实现逻辑（Python 伪代码）

from dataclasses import dataclass
from typing import List, Dict, Any, Optional
from enum import Enum


class ExecutionStatus(Enum):
    PENDING = "pending"
    RUNNING = "running"
    SUCCESS = "success"
    FAILED = "failed"
    RETRYING = "retrying"


@dataclass
class APISpec:
    """API 规范定义"""
    name: str
    endpoint: str
    method: str
    input_schema: Dict[str, Any]
    output_schema: Dict[str, Any]
    description: str


@dataclass
class APICall:
    """单次 API 调用实例"""
    api_spec: APISpec
    parameters: Dict[str, Any]
    status: ExecutionStatus = ExecutionStatus.PENDING
    result: Optional[Any] = None
    error: Optional[str] = None
    depends_on: List[str] = None  # 依赖的前置调用 ID


@dataclass
class CallChain:
    """API 调用链"""
    chain_id: str
    calls: List[APICall]
    dependency_graph: Dict[str, List[str]]  # 调用 ID -> 依赖的调用 ID 列表
    status: ExecutionStatus = ExecutionStatus.PENDING


class APIChainOrchestrator:
    """API 调用链编排器——核心系统类"""

    def __init__(self, config: Dict[str, Any]):
        """
        初始化编排器

        Args:
            config: 配置字典，包含：
                - llm_client: LLM 客户端
                - api_registry: API 注册表
                - max_retries: 最大重试次数
                - timeout: 超时时间
        """
        self.llm_client = config["llm_client"]
        self.api_registry = config["api_registry"]  # 可用 API 的 schema 库
        self.max_retries = config.get("max_retries", 3)
        self.timeout = config.get("timeout", 30)
        self.execution_store = {}  # 存储执行状态

    def parse_user_intent(self, user_request: str) -> Dict[str, Any]:
        """
        解析用户意图，提取任务目标和约束

        核心抽象：将自然语言映射到结构化任务表示
        """
        prompt = self._build_intent_prompt(user_request)
        response = self.llm_client.generate(prompt)
        return self._parse_intent_response(response)

    def retrieve_relevant_apis(self, intent: Dict[str, Any]) -> List[APISpec]:
        """
        根据意图检索相关 API

        核心抽象：语义匹配 + 关键词检索的混合检索策略
        """
        all_apis = self.api_registry.list_all()
        # 使用 LLM 进行语义匹配
        prompt = self._build_api_retrieval_prompt(intent, all_apis)
        response = self.llm_client.generate(prompt)
        matched_ids = self._parse_api_ids(response)
        return [api for api in all_apis if api.name in matched_ids]

    def generate_call_chain(self, intent: Dict[str, Any],
                            candidate_apis: List[APISpec]) -> CallChain:
        """
        生成 API 调用链 DAG

        核心抽象：将任务规划转换为 DAG 生成问题
        """
        prompt = self._build_planning_prompt(intent, candidate_apis)
        response = self.llm_client.generate(prompt)
        chain_data = self._parse_chain_response(response)

        calls = []
        for call_data in chain_data["calls"]:
            api_spec = next(a for a in candidate_apis if a.name == call_data["api_name"])
            call = APICall(
                api_spec=api_spec,
                parameters=call_data["parameters"],
                depends_on=call_data.get("depends_on", [])
            )
            calls.append(call)

        return CallChain(
            chain_id=chain_data["chain_id"],
            calls=calls,
            dependency_graph=chain_data["dependency_graph"]
        )

    def execute_chain(self, chain: CallChain) -> Dict[str, Any]:
        """
        执行调用链，支持并行执行和错误恢复

        核心抽象：基于 DAG 的拓扑排序执行
        """
        chain.status = ExecutionStatus.RUNNING
        completed = set()
        results = {}

        # 拓扑排序，支持并行执行
        execution_order = self._topological_sort(chain.dependency_graph)

        for batch in self._group_by_parallel(execution_order):
            # 并行执行同一批次的调用
            batch_tasks = []
            for call_id in batch:
                call = next(c for c in chain.calls if id(c) == call_id)

                # 等待依赖完成
                if call.depends_on:
                    self._wait_for_dependencies(call, completed, results)

                # 填充参数（可能需要前置调用的输出）
                call.parameters = self._fill_parameters(call, results)

                batch_tasks.append(self._execute_single_call(call))

            # 等待批次完成
            batch_results = self._wait_all(batch_tasks, timeout=self.timeout)

            # 处理结果
            for call_id, result in batch_results.items():
                call = next(c for c in chain.calls if id(c) == call_id)
                if result.success:
                    call.status = ExecutionStatus.SUCCESS
                    call.result = result.data
                    completed.add(call_id)
                    results[call_id] = result.data
                else:
                    # 重试逻辑
                    call = self._handle_failure(call, result.error)
                    if call.status == ExecutionStatus.FAILED:
                        chain.status = ExecutionStatus.FAILED
                        return {"status": "failed", "error": call.error, "partial_results": results}

        chain.status = ExecutionStatus.SUCCESS
        return {"status": "success", "results": results}

    def _execute_single_call(self, call: APICall) -> Dict[str, Any]:
        """执行单次 API 调用"""
        call.status = ExecutionStatus.RUNNING
        try:
            response = self._http_request(
                method=call.api_spec.method,
                url=call.api_spec.endpoint,
                params=call.parameters
            )
            return {"success": True, "data": response}
        except Exception as e:
            return {"success": False, "error": str(e)}

    def _handle_failure(self, call: APICall, error: str) -> APICall:
        """错误处理：重试或失败"""
        retry_count = getattr(call, "_retry_count", 0)
        if retry_count < self.max_retries:
            call._retry_count = retry_count + 1
            call.status = ExecutionStatus.RETRYING
            self._exponential_backoff(retry_count)
            return self._execute_single_call(call)
        else:
            call.status = ExecutionStatus.FAILED
            call.error = error
            return call

    def generate_response(self, chain: CallChain,
                         execution_result: Dict[str, Any]) -> str:
        """
        生成自然语言响应

        核心抽象：将结构化执行结果转换为自然语言总结
        """
        prompt = self._build_response_prompt(chain, execution_result)
        return self.llm_client.generate(prompt)

伪代码说明：

5. 性能指标

6. 扩展性与安全性

水平扩展

垂直扩展

安全考量

维度二：行业情报

1. GitHub 热门项目（15+ 个）

基于 2025-2026 年最新数据，按影响力和活跃度排序：

数据来源： GitHub 公开数据，检索日期 2026-04-07

2. 关键论文（12 篇）

按影响力和时效性选择，覆盖奠基性工作和前沿进展：

3. 系统化技术博客（10 篇）

按内容深度和作者权威性选择：

4. 技术演进时间线

2022 ─┬─ OpenAI Function Calling 发布 → LLM 工具调用能力首次商业化
      │
2023 ─┼─ LangChain Agents 发布 → 开源 Agent 框架生态兴起
      │
2023 ─┼─ AutoGen 发布（微软） → 多 Agent 对话式任务求解
      │
2024 ─┼─ FlowMind / AutoFlow 论文发布 → 自动化工作流生成研究突破
      │
2024 ─┼─ LangGraph 发布 → 图状态机 Agent 编排成为新标准
      │
2024 ─┼─ NESTFUL / ComplexFuncBench 基准发布 → 评测体系成熟
      │
2025 ─┼─ OpenAI Agents SDK 发布 → 官方轻量 Agent 框架
      │
2025 ─┼─ MCP (Model Context Protocol) 标准提出 → 工具连接协议标准化
      │
2025 ─┼─ LangChain/LangGraph 1.0 发布 → 框架进入生产就绪阶段
      │
2026 ─┼─ 并行工具调用优化（SimpleTool, LLMOrch） → 延迟大幅降低
      │
2026 ─┴─ 当前状态：多 Agent 编排标准化，评测体系成熟，生产应用爆发

关键里程碑影响：

维度三：方案对比

1. 历史发展时间线

2022 ─┬─ Function Calling（OpenAI） → 首次将工具调用能力集成到 LLM API
      │
2023 ─┼─ LangChain ReAct Agent → 开源框架实现 ReAct 推理模式
      │
2023 ─┼─ AutoGen Conversable Agents → 多 Agent 对话协作模式
      │
2024 ─┼─ LangGraph State Machine → 图状态机精确控制工作流
      │
2024 ─┼─ CrewAI Role-Based Teams → 基于角色的 Agent 团队抽象
      │
2025 ─┼─ OpenAI Agents SDK Handoffs → 官方 Handoff 机制
      │
2025 ─┼─ MCP Standard → Model Context Protocol 统一工具接口
      │
2026 ─┴─ 当前状态：多范式并存，按场景选择最优方案

2. 六种方案横向对比

3. 技术细节对比

4. 选型建议

选型决策树：

是否需要多模型支持？
├─ 是 → LangChain / LangGraph
└─ 否 → 继续
    │
是否仅使用 OpenAI 模型？
├─ 是 → OpenAI Agents SDK（首选）或 LangChain
└─ 否 → 继续
    │
工作流复杂度？
├─ 简单（<5 步） → LangChain ReAct
├─ 中等（5-20 步） → LangGraph 或 CrewAI
└─ 复杂（>20 步/动态） → LangGraph 或 AutoGen
    │
是否需要可视化/低代码？
├─ 是 → n8n / Flowise
└─ 否 → 继续
    │
是否需要人机交互？
├─ 是 → LangGraph
└─ 否 → 根据团队技术栈选择

维度四：精华整合

1. The One 公式

用一个悖论式等式概括 API 调用链自动构建的核心本质：

解读： 该技术的本质是用 LLM 的语义能力解决传统方法难以处理的意图理解和灵活规划问题，但需要克服 LLM 固有的不确定性带来的规划错误。

2. 一句话解释（费曼技巧）

API 调用链自动构建就像让一个懂技术的秘书帮你办事：你只需要说"帮我订下周三去北京的机票和酒店"，秘书会自动理解需要调用哪些系统（航司 API、酒店 API），按正确顺序操作（先查航班再订酒店），最后把结果整理好告诉你——整个过程不需要你亲自登录每个网站操作。

3. 核心架构图

用户自然语言 → [理解层] → [规划层] → [执行层] → 自然语言响应
                   ↓          ↓          ↓
              意图提取    DAG 生成    API 调用
              实体识别    依赖分析    结果整合
              约束解析    参数填充    错误处理

4. STAR 总结

5. 理解确认问题

问题： 为什么 API 调用链自动构建不能简单理解为"多次调用 Function Calling"？请从依赖关系、状态管理和错误处理三个角度解释。

参考答案：

1. 依赖关系：Function Calling 是原子操作，每次调用独立；调用链中后续 API 的输入可能依赖前置 API 的输出（如用订单 ID 查询物流），需要构建 DAG 显式表达依赖，并保证执行顺序。

2. 状态管理：单次调用无状态，调用链需要维护跨调用的中间状态（如已获取的用户 ID、认证 token），并在失败时支持回滚或补偿操作。LangGraph 等框架引入状态机正是为了解决这一问题。

3. 错误处理：Function Calling 失败直接返回错误；调用链需要策略性处理——重试可恢复错误、跳过非关键步骤、在关键节点失败时回滚已执行操作，这些都需要编排层的状态感知能力。

简言之，调用链是有状态的、依赖感知的、可恢复的执行过程，而多次 Function Calling 只是无状态的、独立的、失败即终止的调用序列。

参考文献与资源

GitHub 资源

1. LangChain - https://github.com/langchain-ai/langchain
2. LangGraph - https://github.com/langchain-ai/langgraph
3. AutoGen - https://github.com/microsoft/autogen
4. CrewAI - https://github.com/crewAIInc/crewAI
5. OpenAI Agents SDK - https://github.com/openai/openai-agents-python
6. LlamaIndex - https://github.com/run-llama/llama_index
7. ComplexFuncBench - https://github.com/zai-org/ComplexFuncBench
8. AwesomeAgentPapers - https://github.com/HuggingAGI/AwesomeAgentPapers

核心论文

1. FlowMind: arXiv:2404.13050
2. AutoFlow: arXiv:2407.12821
3. NESTFUL: EMNLP 2025, ACL Anthology
4. Tool Use Evolution: arXiv:2603.22862
5. Multi-Step Orchestration Training: arXiv:2603.24709
6. SimpleTool: arXiv:2603.00030
7. Workflow Optimization Survey: arXiv:2603.22386

技术博客

1. LangChain Blog - https://blog.langchain.dev
2. Anthropic Engineering - https://www.anthropic.com/engineering
3. OpenAI Developers - https://developers.openai.com/blog

评测基准

1. NESTFUL - 嵌套 API 调用评测（IBM, EMNLP 2025）
2. ComplexFuncBench - 复杂函数调用评测（ZAI Org, 2025）
3. MCPVerse - MCP 协议评测（2025）

报告完成日期： 2026-04-07 总字数： 约 8500 字 调研方法论： WebSearch + WebFetch 实时数据采集 + 文献分析 + 技术对比