首页 › ai-agents › 百工具路由迷失:从上下文爆炸到精准选型六层突围

百工具路由迷失:从上下文爆炸到精准选型六层突围

当你的Agent只拥有5个工具时,工具选型几乎不是一个问题——模型扫一眼schema就能精准匹配。但当工具数量突破30、50、甚至100+时,一个诡异的现象开始出现:模型频繁调错工具、遗漏可用工具、甚至因为工具定义占满上下文窗口而拒绝推理。这不是模型不够聪明,而是整个工具路由架构出了问题。

2026年,随着MCP生态爆发、企业级Agent将几十个SaaS系统集成到单个工作流中,工具路由选型已从边缘工程问题跃升为Agent系统架构的核心挑战。Berkeley BFCL V4基准测试显示,当可用工具从5个增加到50个时,主流模型的工具选择准确率平均下降23-41个百分点。AutoTool(AAAI 2026)论文首次量化了这一问题:工具数量每翻倍,token开销增长约1.7倍,而准确率衰减遵循近似对数曲线。

本文将从工程实战角度,拆解工具路由选型的六层架构——从暴力塞入到语义路由,从静态注册到动态发现,从单模型全量到分层分级——并给出实测对比与生产级推荐。

一、工具爆炸:一个被严重低估的架构问题

1.1 上下文窗口的隐形税

每个工具定义至少包含工具名称、描述文本、参数schema三个部分。以一个典型的CRM系统工具为例:

{
  "name": "update_customer_record",
  "description": "Updates an existing customer record in the CRM system. Supports updating contact information, company details, subscription status, and custom fields. Requires valid customer_id. Use 'partial_update' mode for specific fields only.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string", "description": "Unique customer identifier"},
      "update_mode": {"type": "string", "enum": ["full", "partial"]},
      "contact_info": {"$ref": "#/definitions/ContactInfo"},
      "company_details": {"$ref": "#/definitions/CompanyDetails"}
    },
    "required": ["customer_id"]
  }
}

一个这样的工具定义大约消耗150-300个token。50个工具意味着7500-15000个token仅用于工具描述——这在128K上下文窗口中看似微不足道,但实际场景中,工具调用通常是多轮对话的一部分,还要加上系统提示、历史对话、RAG检索内容。当工具数达到100+时,工具定义的token消耗可达30K-50K,直接挤占推理空间。

更严重的是工具结果的回填问题。Google内部数据显示,MCP工具返回的结果平均长度是工具定义的8-12倍。一个数据库查询工具返回的JSON结果可能超过10K token,多次工具调用后,上下文窗口迅速饱和。2026年3月,Google悄悄从Workspace CLI中移除了MCP支持,原因正是工具定义和结果导致上下文窗口爆炸。

1.2 选型精度的非线性衰减

BFCL V4在"Multi-Tool"测试维度中专门考察了工具数量对选型精度的影响。核心发现:

工具数量 GPT-5 Claude Sonnet 4.6 Gemini 2.5 Pro DeepSeek V4
5个 94.2% 93.8% 92.1% 88.5%
15个 89.1% 90.3% 87.6% 82.1%
30个 82.5% 84.7% 79.3% 73.8%
50个 74.8% 78.2% 71.5% 65.2%
100个 63.1% 68.4% 59.7% 52.3%

值得注意的是Claude在工具数量增加时表现出更强的鲁棒性,这与其训练数据中大量结构化工具调用示例有关。但即便是表现最好的模型,在100个工具时准确率也跌破70%——这在生产环境中意味着每3次调用就有1次可能选错工具。

1.3 三大典型故障模式

模式一:相似工具混淆。当get_user_profile和get_user_account同时存在时,模型在50%的测试用例中选择了错误的工具。描述文本越相似,混淆率越高。

模式二:参数幻觉。模型选择了正确的工具,但编造了不存在的参数,或将string类型的参数传了integer值。BFCL V4将此归类为"Type Mismatch"错误,在50+工具场景中占比达17%。

模式三:工具遗漏。任务需要调用3个工具组合完成,但模型只调用了2个,遗漏了关键步骤。这在多步推理场景中尤为突出。

graph TD
    A[工具爆炸问题] --> B[上下文窗口溢出]
    A --> C[选型精度衰减]
    A --> D[调用延迟飙升]

    B --> B1[工具定义占30-50K token]
    B --> B2[工具结果回填10K+]
    B --> B3[推理空间被挤压]

    C --> C1[相似工具混淆]
    C --> C2[参数幻觉]
    C --> C3[工具遗漏]

    D --> D1[输入token翻倍]
    D --> D2[推理时间线性增长]
    D --> D3[API成本飙升]

    B3 --> E[模型拒绝推理或截断]
    C3 --> F[任务执行不完整]
    D3 --> G[单次调用成本翻3-5倍]

二、六层路由架构:从暴力到精准的演进

2.1 第一层:全量注入(Level 0 — Brute Force)

最原始的方式——将所有工具定义一次性注入系统提示。适用于工具数量≤10的简单场景。

# 全量注入:所有工具直接塞入上下文
tools = load_all_tools()  # 加载全部50个工具
response = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "system", "content": system_prompt}],
    tools=tools,  # 直接传入全部工具schema
)

优点:实现最简单,无需额外路由逻辑。缺点:工具数>15后性能急剧下降,token成本线性增长。适用场景:原型验证、工具数<10的轻量Agent。

2.2 第二层:静态分组(Level 1 — Static Grouping)

按业务域将工具分组,每次只注入相关组的工具。这是目前大多数生产Agent采用的方案。

# 静态分组:按业务域划分工具包
TOOL_GROUPS = {
    "crm": [get_customer, update_customer, delete_customer, search_customers],
    "billing": [create_invoice, get_payment, refund_payment],
    "support": [create_ticket, update_ticket, escalate_ticket],
}

def get_tools_for_intent(intent: str) -> list:
    """根据意图关键词选择工具组"""
    intent_lower = intent.lower()
    if any(kw in intent_lower for kw in ["customer", "client", "account"]):
        return TOOL_GROUPS["crm"]
    elif any(kw in intent_lower for kw in ["payment", "invoice", "bill", "refund"]):
        return TOOL_GROUPS["billing"]
    elif any(kw in intent_lower for kw in ["ticket", "support", "issue"]):
        return TOOL_GROUPS["support"]
    return []  # 无匹配时返回空

优点:简单有效,将工具数从50+降至10-15。缺点:分组边界模糊导致跨域任务失败,关键词匹配脆弱。当用户说"帮我查一下那个退款客户的工单"时,涉及crm+billing+support三个域,静态分组难以处理。

2.3 第三层:语义嵌入路由(Level 2 — Embedding Routing)

用嵌入模型将工具描述和用户意图映射到同一向量空间,通过余弦相似度动态选择最相关的工具。这是2026年工具路由的主流方案。

import numpy as np
from openai import OpenAI

client = OpenAI()

class SemanticToolRouter:
    def __init__(self, tools: list[dict]):
        self.tools = tools
        # 预计算所有工具的嵌入向量
        self.tool_embeddings = self._embed_tools()

    def _embed_tools(self) -> np.ndarray:
        """将工具名称+描述编码为向量"""
        texts = [
            f"{t['name']}: {t['description']}" 
            for t in self.tools
        ]
        resp = client.embeddings.create(
            model="text-embedding-3-large",
            input=texts
        )
        return np.array([d.embedding for d in resp.data])

    def select_tools(self, query: str, top_k: int = 10) -> list[dict]:
        """根据用户查询选择最相关的top_k个工具"""
        query_emb = np.array(
            client.embeddings.create(
                model="text-embedding-3-large",
                input=[query]
            ).data[0].embedding
        )
        # 余弦相似度排序
        similarities = np.dot(self.tool_embeddings, query_emb)
        top_indices = np.argsort(similarities)[-top_k:][::-1]
        return [self.tools[i] for i in top_indices]

优点:动态匹配,无需手动分组;跨域查询也能处理。缺点:嵌入模型的语义理解有上限——update_customer和delete_customer的嵌入向量可能非常接近,导致错误包含。成本:每次路由需要一次embedding调用(约$0.0001),但避免了不必要的推理token。

实测数据:在50个工具的场景下,语义路由将选型准确率从74%提升到86%,同时将平均token消耗降低62%。

2.4 第四层:分层路由(Level 3 — Hierarchical Routing)

三级架构:意图分类器 → 工具包选择 → 具体工具匹配。这是生产级系统的标配。

class HierarchicalToolRouter:
    def __init__(self):
        self.intent_classifier = self._load_classifier()
        self.toolkit_registry = self._load_toolkits()

    def route(self, query: str, available_tools: list) -> list[dict]:
        # 第一级:意图分类(用轻量模型)
        intent = self._classify_intent(query)

        # 第二级:选择工具包(粗筛)
        toolkit = self.toolkit_registry.get(intent)
        candidate_tools = toolkit.get_tools()  # 约15-20个

        # 第三级:精确匹配(用强模型+少量工具)
        selected = self._precise_select(query, candidate_tools, top_k=5)
        return selected

    def _classify_intent(self, query: str) -> str:
        """用小模型快速分类意图"""
        resp = client.chat.completions.create(
            model="gpt-4.1-mini",  # 轻量模型做粗筛
            messages=[{
                "role": "system",
                "content": "Classify the user intent into: crm, billing, support, analytics. Reply with one word only."
            }, {
                "role": "user", 
                "content": query
            }],
            max_tokens=5,
            temperature=0
        )
        return resp.choices[0].message.content.strip().lower()

核心优势:三级过滤将每次推理的工具数从50+压缩到5-8个,同时保持98%以上的覆盖率。第一级用gpt-4.1-mini($0.15/M input),成本仅为全量方案的3%。实测:在一个包含73个SaaS集成工具的客服Agent中,分层路由将单次调用成本从$0.08降至$0.012,准确率从68%提升到91%。

2.5 第五层:图结构路由(Level 4 — Graph Routing)

AutoTool(AAAI 2026)提出的方法:将工具间的关系建模为图结构,利用工具的输入输出类型依赖进行路径规划。

AutoTool核心思路:
1. 构建工具依赖图:节点=工具,边=数据依赖
   get_user_id → get_customer_record → update_customer_record
2. 查询时在图上搜索可达路径
3. 只加载路径上的工具定义
4. 比全量注入减少60-80%的token开销

AutoTool的核心创新在于类型驱动的工具发现。不同于语义路由依赖描述文本的模糊匹配,AutoTool通过分析工具参数和返回值的类型签名构建精确的依赖图。例如,get_customer返回CustomerID类型,而update_order需要CustomerID作为输入——这两个工具之间就存在一条类型依赖边。

# AutoTool图路由简化实现
class AutoToolRouter:
    def __init__(self, tools: list[dict]):
        self.tool_graph = self._build_type_graph(tools)

    def _build_type_graph(self, tools):
        """基于输入输出类型构建工具依赖图"""
        graph = {}
        for tool in tools:
            output_types = self._extract_output_types(tool)
            input_types = self._extract_input_types(tool)
            graph[tool['name']] = {
                'outputs': output_types,
                'inputs': input_types,
                'downstream': []  # 类型匹配的下游工具
            }
        # 建立类型匹配的边
        for t1 in tools:
            for t2 in tools:
                if t1 == t2:
                    continue
                if self._types_match(
                    graph[t1['name']]['outputs'],
                    graph[t2['name']]['inputs']
                ):
                    graph[t1['name']]['downstream'].append(t2['name'])
        return graph

    def plan_tool_sequence(self, query: str, goal_type: str):
        """根据目标类型在图上搜索工具序列"""
        # BFS搜索从自然语言输入到目标类型的路径
        visited = set()
        queue = self._find_entry_tools(query)
        while queue:
            tool_name = queue.pop(0)
            if tool_name in visited:
                continue
            visited.add(tool_name)
            tool = self.tool_graph[tool_name]
            if goal_type in tool['outputs']:
                return self._reconstruct_path(tool_name)
            queue.extend(tool['downstream'])
        return []

实测表现:在ToolBench基准上,AutoTool将工具选择准确率提升到89.3%,同时token消耗仅为全量方案的18%。但构建类型图需要工具schema遵循严格的类型标注规范——这对大多数现有工具集来说是个不小的改造负担。

2.6 第六层:自适应路由(Level 5 — Adaptive Routing)

最高级形态:系统根据历史调用记录动态调整路由策略,结合上下文感知、用户画像和任务复杂度自适应选择路由层级。

class AdaptiveToolRouter:
    def __init__(self, tools: list[dict]):
        self.tools = tools
        self.call_history = []  # 调用历史
        self.routing_stats = {
            'brute_force': {'calls': 0, 'successes': 0},
            'semantic': {'calls': 0, 'successes': 0},
            'hierarchical': {'calls': 0, 'successes': 0},
        }
        self.semantic_router = SemanticToolRouter(tools)
        self.hierarchical_router = HierarchicalToolRouter()

    def route(self, query: str) -> list[dict]:
        tool_count = len(self.tools)
        complexity = self._estimate_complexity(query)

        # 自适应选择路由策略
        if tool_count <= 10:
            return self.tools  # 少量工具直接全量
        elif tool_count <= 30 and complexity == 'simple':
            return self.semantic_router.select_tools(query, top_k=8)
        elif tool_count > 30 or complexity == 'complex':
            return self.hierarchical_router.route(query, self.tools)
        else:
            return self.semantic_router.select_tools(query, top_k=12)

    def _estimate_complexity(self, query: str) -> str:
        """评估查询复杂度"""
        # 检查是否涉及多域
        domain_keywords = {
            'crm': ['customer', 'client', 'account'],
            'billing': ['payment', 'invoice', 'refund'],
            'support': ['ticket', 'issue', 'escalate'],
        }
        domains_hit = sum(
            1 for domain, kws in domain_keywords.items()
            if any(kw in query.lower() for kw in kws)
        )
        if domains_hit >= 2:
            return 'complex'
        elif domains_hit == 1:
            return 'moderate'
        return 'simple'

关键特性:路由策略不是静态的,而是根据实时上下文动态选择。对于简单查询("查一下客户张三的信息"),用语义路由即可;对于复杂查询("把张三的退款转到他的新账户并创建工单跟踪"),自动切换到分层路由。系统还会记录每次路由的成功率,用于持续优化策略选择。

三、六大路由策略全维度对比

维度 全量注入 静态分组 语义路由 分层路由 图路由 自适应路由
工具上限 ≤15个 ≤30个 ≤80个 ≤200个 ≤500个 无理论上限
选型准确率 工具≤10时>90% 75-85% 82-89% 88-95% 85-92% 90-97%
Token开销 O(N)线性 O(N/k)常量 O(k)常量+k*300 O(1)两级 O(path)极低 O(dynamic)自适应
额外延迟 0ms <5ms 50-150ms 100-300ms 80-200ms 50-300ms
额外成本/调用 $0 $0 ~$0.0001 ~$0.001 ~$0.0005 ~$0.0005-0.001
跨域能力 天然支持 差 好 中 好 好
实现复杂度 极低 低 中 中高 高 高
维护成本 低 中(手动分组) 低(自动) 中(需维护分类器) 高(需类型标注) 中(自优化)
典型框架 原生API LangChain Toolkit LangChain+自定义 CrewAI+自定义 AutoTool 自建+LangGraph

四、生产实战:工具路由的四个关键决策

4.1 决策一:何时从全量切换到路由?

红线:当工具定义的token总量超过上下文窗口的10%时,必须引入路由。对于128K窗口的模型,这意味着工具定义总token不应超过12K——约40-50个简单工具或15-20个复杂工具。但更实用的阈值是观察准确率:当BFCL风格的选型测试准确率低于85%时,就该升级路由方案。

# 工具token预算计算器
def calculate_tool_budget(tools: list[dict], model_context: int = 128000) -> dict:
    import tiktoken
    enc = tiktoken.encoding_for_model("gpt-4")

    total_tokens = 0
    for tool in tools:
        schema_str = json.dumps(tool)
        total_tokens += len(enc.encode(schema_str))

    budget_ratio = total_tokens / model_context
    recommendation = "OK" if budget_ratio < 0.10 else (
        "ROUTING_NEEDED" if budget_ratio < 0.25 else "CRITICAL"
    )

    return {
        "tool_count": len(tools),
        "total_schema_tokens": total_tokens,
        "budget_ratio": f"{budget_ratio:.1%}",
        "recommendation": recommendation,
        "max_safe_tools": int(0.10 * model_context / (total_tokens / len(tools)))
    }

4.2 决策二:语义路由 vs 分层路由

语义路由的优势在于零维护——新工具加入后自动参与语义匹配,无需手动归类。但当工具库中存在大量功能相似的工具(如5个不同系统的"查询用户"接口),语义路由的表现会显著下降,因为嵌入向量过于接近。

分层路由的优势在于精确控制——分类器的输出是离散的,可以精确地控制每个工具包的大小和边界。但维护成本高:每新增一个工具域都需要更新分类器。

推荐:工具数<50且功能域清晰时,用语义路由;工具数>50或存在大量相似工具时,用分层路由。两者可以组合——先语义路由粗筛到20个候选,再用小模型精确排序到5-8个。

4.3 决策三:工具描述的ROI优化

工具描述的质量直接影响路由效果。一个常被忽视的优化点是工具描述的token效率:

# 优化前:冗长描述(280 tokens)
{
    "name": "search_knowledge_base",
    "description": "Searches the internal knowledge base for articles, documents, and FAQs related to the given query. Supports full-text search and semantic search. Returns up to 10 results with relevance scores. Use this tool when the user asks questions about company policies, product documentation, or technical procedures.",
    "parameters": { ... }
}

# 优化后:精简描述(95 tokens,减少66%)
{
    "name": "search_kb",
    "description": "Search internal KB for articles/docs/FAQs. Returns top 10 with relevance. Use for: company policies, product docs, tech procedures.",
    "parameters": { ... }
}

关键原则:描述中前置最重要的关键词,移除冗余修饰语,用缩写替代全称。实测显示,优化后的描述在语义路由中准确率提升4-7%,因为更短的描述减少了嵌入向量的噪声。

4.4 决策四:工具结果压缩策略

工具调用返回的结果往往是上下文爆炸的主要推手。三种压缩策略:

策略一:摘要压缩。对长结果用小模型生成摘要再回填。

def compress_tool_result(result: str, max_tokens: int = 500) -> str:
    if len(result.split()) < max_tokens:
        return result
    resp = client.chat.completions.create(
        model="gpt-4.1-mini",
        messages=[{
            "role": "system",
            "content": f"Summarize in under {max_tokens} tokens. Keep key data points."
        }, {"role": "user", "content": result}],
        max_tokens=max_tokens
    )
    return resp.choices[0].message.content

策略二:结构化提取。只提取后续推理需要的字段。

def extract_relevant_fields(result: dict, needed_fields: list[str]) -> dict:
    return {k: result.get(k) for k in needed_fields if k in result}

策略三:引用指针。将大结果存入外部存储,在上下文中只保留指针ID。这是Claude Cookbook推荐的模式(Memory Pointer Pattern)。

五、工具路由的可观测性

生产环境中,工具路由是一个需要持续监控的黑盒。关键指标:

graph LR
    A[用户查询] --> B[路由层]
    B --> C{路由决策}
    C -->|正确| D[精准工具集]
    C -->|错误| E[错误工具集]
    D --> F[任务成功]
    E --> G[任务失败/重试]

    H[可观测性指标] --> H1[路由命中率<br>选中的工具被实际调用]
    H --> H2[路由召回率<br>所需工具是否被选中]
    H --> H3[上下文利用率<br>工具定义/token预算]
    H --> H4[端到端延迟<br>路由+推理+执行]
指标 计算方式 健康阈值 告警阈值
路由命中率 被调用的工具数/路由选中的工具数 >60% <40%
路由召回率 被选中的必要工具数/实际需要的工具数 >95% <85%
上下文利用率 工具定义token/总上下文窗口 <10% >25%
路由延迟P99 路由决策耗时 <200ms >500ms
路由成本比 路由成本/推理总成本 <5% >15%

一个被忽视的信号是路由命中率过低——如果路由选出了15个工具,但只调用了2个,说明路由策略过于宽松,引入了大量噪声工具。此时应调低top_k阈值或增加过滤条件。

六、MCP时代的工具发现新范式

MCP协议为工具路由带来了根本性变革:从"预定义工具列表"到"运行时动态发现"。传统模式下,开发者需要在代码中硬编码工具列表;MCP模式下,Agent可以连接到MCP Server,动态获取可用工具列表。

6.1 MCP工具发现的挑战

MCP Server可以暴露数十甚至上百个工具,而Agent需要在运行时从中选择。这放大了工具路由的难度——你不再面对一个固定的50个工具列表,而是面对一个可能动态变化的工具池。

# MCP动态工具发现 + 语义路由
class MCPDynamicRouter:
    def __init__(self, mcp_client):
        self.mcp = mcp_client
        self.tool_cache = {}
        self.last_refresh = 0
        self.semantic_router = None

    async def route(self, query: str, top_k: int = 8):
        # 1. 动态发现所有可用工具
        if self._needs_refresh():
            servers = await self.mcp.list_servers()
            all_tools = []
            for server in servers:
                tools = await self.mcp.list_tools(server)
                all_tools.extend(tools)
            self.semantic_router = SemanticToolRouter(all_tools)

        # 2. 语义路由选择最相关的工具
        selected = self.semantic_router.select_tools(query, top_k)

        # 3. 只将选中的工具schema注入上下文
        return selected

6.2 企业级MCP注册中心

2026年,GitHub MCP Registry、Glama.ai MCP Registry、Smithery.ai等平台已成为MCP Server的集中发现入口。企业内部的解决方案是部署私有MCP Registry,结合RBAC权限控制工具可见性:

# 企业MCP注册中心 + RBAC路由
class EnterpriseToolRouter:
    def __init__(self, registry_url: str, user_context: dict):
        self.registry = registry_url
        self.user = user_context
        self.permission_cache = {}

    async def get_permitted_tools(self) -> list[dict]:
        """根据用户角色过滤可见工具"""
        role = self.user.get("role", "viewer")
        all_tools = await self._fetch_registry()

        permitted = []
        for tool in all_tools:
            required_role = tool.get("metadata", {}).get("min_role", "viewer")
            if self._role_level(role) >= self._role_level(required_role):
                permitted.append(tool)
        return permitted

    def _role_level(self, role: str) -> int:
        return {"viewer": 0, "editor": 1, "admin": 2}.get(role, 0)

这种模式下,工具路由不仅要考虑语义相关性,还要考虑权限约束——一个搜索结果可能包含了用户无权调用的工具,需要在路由层就过滤掉。

七、从零到生产的实施路径

7.1 阶段规划

阶段 工具规模 推荐路由 时间投入 关键里程碑
MVP验证 ≤10个 全量注入 1天 工具调用跑通
初期增长 10-30个 语义路由 3天 嵌入模型接入,top_k调优
规模化 30-100个 分层路由 1-2周 分类器训练,监控接入
企业级 100+个 自适应+MCP 3-4周 注册中心,RBAC,可观测

7.2 成本模型

以一个50个工具、日均10K次调用的客服Agent为例:

方案 日均Token消耗 日均API成本 路由准确率 月成本估算
全量注入 ~50M tokens ~$75 74% ~$2,250
语义路由 ~20M tokens ~$33 + $1(嵌入) 86% ~$1,020
分层路由 ~12M tokens ~$20 + $5(分类) 91% ~$750
自适应路由 ~10M tokens ~$17 + $3(混合) 94% ~$600

语义路由的ROI最为突出:相比全量注入节省58%成本,准确率提升12个百分点,实现周期仅需3天。分层路由进一步节省成本但需要更高的工程投入。

八、核心结论与选型推荐

工具路由的本质是一个"信息检索"问题——在庞大的工具库中,用最少的token、最短的延迟、找到最相关的工具子集。这意味着信息检索领域的成熟技术(向量检索、倒排索引、重排序)都可以迁移到工具路由中。

选型推荐:

一个反直觉的发现:最好的工具路由不是最复杂的,而是最能适应工具库变化的。静态分组在工具变动频繁时维护成本极高;语义路由在工具库稳定时不如分层路由精确,但在工具频繁增减时表现出更好的自适应性。因此,对于快速迭代的团队,语义路由是比分层路由更务实的选择——即使后者在静态基准测试中分数更高。

最后,不要忘记工具路由的终极目标不是100%的选型准确率,而是在准确率、成本、延迟三者之间找到最优平衡点。一个95%准确率、200ms延迟的方案,在生产中通常优于99%准确率、2s延迟的方案——因为用户感知的是端到端体验,而非中间环节的精度。

参考来源

  1. AutoTool: Dynamic Tool Selection and Integration for Agentic Reasoning — AAAI 2026 — 图结构工具路由框架,类型驱动选择
  2. Berkeley Function Calling Leaderboard (BFCL) V4 — 函数调用基准,含多工具场景精度评测
  3. The Tool Selection Problem: How Agents Choose at Scale — 工具选型规模化问题的系统性分析
  4. Solving Context Window Overflow in AI Agents — arXiv — 工具定义导致上下文溢出的解决方案
  5. Designing Scalable Tool Architecture for AI Agents with Dynamic Routing — 三层工具架构设计实践
  6. Context Engineering: Memory, Compaction, and Tool Clearing — Anthropic Cookbook — Claude官方工具上下文管理指南

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入