实现智能体调用海量api

针对成百上千个数据 API 接口的场景，单纯依靠 LLM 的上下文（Context Window）硬塞是行不通的。目前业界公认的主流方案是 "RAG for Tools"（基于检索的工具增强生成）。

其核心思想是："先检索，再调用"。只在运行时动态地将最相关的 3-5 个 API 挂载给 LLM，从而保证准确率并节省 Token。

以下是一个完整的、可落地的技术方案，包含架构设计、核心代码实现和优化策略。

一、整体架构设计

我们将系统分为两个阶段：离线准备阶段 和 在线运行阶段。

二、核心实现步骤

1. 技术栈推荐

编排框架: LangChain (Python 版 v0.2/v0.3)
大模型: GPT-4o, Claude 3.5 Sonnet (Tool Calling 能力强), 或 Qwen-2.5-72B (私有化推荐)
向量库: FAISS (轻量), Milvus (生产级)
API 描述标准: OpenAPI (Swagger)

2. 代码实现详解

这里提供一个基于 LangChain 的核心实现 Demo。

第一步：定义 API 并建立索引 (Mock 数据)

在真实场景中，你需要写脚本遍历 Swagger JSON，提取 path, description, parameters。

python 复制代码

from langchain_core.tools import StructuredTool
from langchain_core.documents import Document
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
from pydantic import BaseModel, Field

# --- 1. 定义数据 API 的 Schema (模拟从 Swagger 解析而来) ---

class SalesQuerySchema(BaseModel):
    start_date: str = Field(description="开始日期, 格式 YYYY-MM-DD")
    end_date: str = Field(description="结束日期, 格式 YYYY-MM-DD")

def query_sales_data(start_date: str, end_date: str):
    """查询指定时间范围内的公司销售总额。"""
    # 模拟真实 HTTP 请求
    return {"total_sales": 100000, "currency": "CNY", "period": f"{start_date} to {end_date}"}

class UserInfoSchema(BaseModel):
    user_id: str = Field(description="用户ID")

def get_user_profile(user_id: str):
    """根据 ID 获取用户的详细画像和等级信息。"""
    return {"id": user_id, "name": "Alice", "level": "VIP"}

# 假设你有 1000 个这样的工具
all_tools_map = {
    "query_sales_data": StructuredTool.from_function(
        func=query_sales_data,
        name="query_sales_data",
        description="查询指定时间范围内的公司销售总额",
        args_schema=SalesQuerySchema
    ),
    "get_user_profile": StructuredTool.from_function(
        func=get_user_profile,
        name="get_user_profile",
        description="根据 ID 获取用户的详细画像和等级信息",
        args_schema=UserInfoSchema
    ),
    # ... 更多工具 ...
}

# --- 2. 建立向量索引 (Indexing) ---
# 将工具的功能描述向量化
docs = []
for name, tool in all_tools_map.items():
    docs.append(Document(
        page_content=tool.description, # 检索的关键：描述必须准确
        metadata={"tool_name": name}
    ))

embeddings = OpenAIEmbeddings()
# 使用 FAISS 建立索引
vector_store = FAISS.from_documents(docs, embeddings)
retriever = vector_store.as_retriever(search_kwargs={"k": 3}) # 每次只找最相关的3个

第二步：构建"检索-执行"智能体

这是运行时的逻辑：用户提问 -> 检索 -> 动态组装 Agent。

python 复制代码

# --- 3. 运行时逻辑 ---

def run_data_agent(user_query: str):
    print(f"--- 用户提问: {user_query} ---")
    
    # 3.1 检索阶段：找到相关工具
    retrieved_docs = retriever.invoke(user_query)
    # 根据名字找回真实的工具对象
    selected_tools = [all_tools_map[d.metadata["tool_name"]] for d in retrieved_docs]
    
    print(f"Step 1: 检索到的相关接口 -> {[t.name for t in selected_tools]}")
    
    if not selected_tools:
        return "抱歉，没有找到相关的数据接口。"

    # 3.2 动态构建 Agent
    llm = ChatOpenAI(model="gpt-4o", temperature=0)
    
    prompt = ChatPromptTemplate.from_messages([
        ("system", "你是一个数据分析助手。当前时间是 2025-12-23。请根据用户的要求，选择合适的工具获取数据。"),
        ("human", "{input}"),
        ("placeholder", "{agent_scratchpad}"),
    ])
    
    # 将检索到的 tools 绑定给 LLM
    agent = create_tool_calling_agent(llm, selected_tools, prompt)
    agent_executor = AgentExecutor(agent=agent, tools=selected_tools, verbose=True)
    
    # 3.3 执行与回答
    result = agent_executor.invoke({"input": user_query})
    return result["output"]

# --- 测试 ---
# 用户问模糊的时间，LLM 需要结合 System Prompt 里的当前时间推算 API 参数
response = run_data_agent("帮我查一下上个月的销售额")
print(f"Final Answer: {response}")

三、关键难点与解决方案

在处理"成百上千"个接口时，你会遇到准确率和性能问题，以下是进阶优化方案：

1. 提高检索准确率 (The Precision Problem)

如果只用简单的语义检索，可能会出现查错接口的情况（比如"查询订单"和"查询退单"描述很像）。

方案 A：元数据过滤 (Metadata Filtering)
- 在 Swagger 中提取 tags (如 Finance, HR, SupplyChain)。
- 先用一个轻量级 LLM 判断用户意图属于哪个领域（例如判断为 Finance）。
- 并在向量检索时加上过滤条件 filter={"tag": "Finance"}。
方案 B：混合检索 (Hybrid Search)
- 结合 BM25 (关键词匹配) 和 Vector (语义匹配) 。如果用户准确说出了接口名或特有的参数名（如 SKU_ID），关键词匹配权重更高。

2. 处理复杂参数 (The Parameter Problem)

用户提问通常很模糊（"查那个谁的订单"），而 API 需要精准的 ID。

方案：多步推理 (ReAct)
- Agent 发现参数缺失时，不要瞎填。
- 可以在 Prompt 中设定："如果缺少参数（如 user_id），请先调用搜索接口（search_user）获取，或者反问用户。"

3. 降低 Token 消耗 (The Context Problem)

Swagger 文档通常极其冗长。

方案：Schema 瘦身
- 不要把完整的 Swagger JSON 喂给 LLM。
- 编写脚本清洗 Swagger，只保留 description, parameters (name, type, required), 和 return 的简要描述。剔除 404/500 等错误码定义。

4. 安全性控制 (Safety)

方案：只读原则
- 对于数据问数场景，建议严格过滤 GET 请求。
- 对于 POST/DELETE 等修改操作，必须在 Agent 执行前增加 "人机确认 (Human-in-the-loop)" 环节，让用户点击"确认执行"。

四、推荐的数据流转图

text 复制代码

用户: "上个月北京地区的空调销售额是多少？"
      |
      v
[意图分析] -> 提取关键词: "销售额", "上个月", "北京", "空调"
      |
[向量检索] -> 在 1000 个 API 中找到 Top 3:
            1. get_sales_summary(date_range, region, category)  <-- 命中
            2. get_inventory(product_id)
            3. get_weather(city)
      |
[LLM 推理] -> 选中 API 1
            -> 转换参数: 
               date_range="2025-11-01 to 2025-11-30" (根据当前时间推算)
               region="Beijing"
               category="Air Conditioner"
      |
[API 执行] -> 调用后端接口 -> 返回 JSON { "amount": 500000 }
      |
[LLM 生成] -> "上个月（11月）北京地区空调销售额为 50 万元。"

总结

要实现这个系统，不要试图训练一个能记住所有 API 的模型。LangChain + 向量数据库 + 动态工具挂载 是目前最成熟、性价比最高的方案。