# 工具调用2026三浪：并行·严模式·多模态实测
## 概述
2026年H1，AI Agent的工具调用能力正在经历三重结构性变革：**并行工具调用（Parallel Tool Calling）**将多步Agent延迟压缩40-70%；**严格模式（Strict Mode）**让三大厂商首次实现JSON Schema 100%合规；**多模态工具调用（Multimodal Tool Calling）**让Agent能直接处理图像、文件等非结构化输入作为工具参数。与此同时，BFCL v4基准揭示了新裂缝——当工具调用进入多轮Agentic场景，头部模型的准确率从单轮92%骤降至多轮67%，生产环境工具调用失败率仍在12-18%徘徊。本文基于BFCL v4、tau-bench、ToolACE等基准的最新数据，实测三大浪涌的底层逻辑、代码实现与生产适配度。
---
## 一、工具调用2026全景：基准饱和与生产裂缝
### 1.1 BFCL v4：从工具调用到Agentic评测的范式跃迁
UC Berkeley的BFCL（Berkeley Function Calling Leaderboard）在2026年进入v4阶段，核心变化在于**从单轮函数匹配转向多步Agentic评测**。v4新增三个关键维度：
| 维度 | v3覆盖 | v4新增 |
|------|--------|--------|
| 单轮函数选择 | ✅ | ✅ |
| 多函数并行调用 | ✅ | ✅ |
| **多轮对话状态追踪** | ❌ | ✅ |
| **工具依赖链推理** | ❌ | ✅ |
| **工具执行结果反馈整合** | ❌ | ✅ |
| 幻觉工具检测 | 部分 | ✅ 强化 |
BFCL v4最令人震惊的发现：**工具调用准确率和编码能力是相关但独立的技能**。GPT-5在SWE-bench Verified上领先，但在BFCL v4的多轮场景中被Gemini 3.5 Flash反超——后者在函数选择准确率上达到89.3%，而GPT-5为87.1%。
### 1.2 五大基准的交叉验证
2026年主流工具调用基准形成了互补矩阵：
```
┌─────────────┬───────────────┬──────────────┬─────────────┐
│ 基准 │ 核心评测维度 │ 头部准确率 │ 数据规模 │
├─────────────┼───────────────┼──────────────┼─────────────┤
│ BFCL v4 │ 单轮+多轮+幻觉 │ 89.3%(综合) │ 2K+ pairs │
│ tau-bench │ 多轮客服协作 │ 67%(最佳) │ 真实场景 │
│ ToolBench │ 工具链组合 │ 78%(RapidAPI) │ 16K+ APIs │
│ T-Eval │ 工具推理能力 │ 85%(指令遵循) │ 6K+ tests │
│ ToolACE │ 训练数据质量 │ 91%(ICLR'25) │ 40K+ pairs │
└─────────────┴───────────────┴──────────────┴─────────────┘
```
关键落差：**单轮基准头部模型破90%，但tau-bench多轮场景仅67%**——差距23个百分点。这意味着"知道调哪个工具"和"在复杂对话中持续正确调工具"是两回事。
---
## 二、第一浪：并行工具调用——从串行到投机执行的延迟革命
### 2.1 串行瓶颈：为什么传统Agent慢
传统Agent Loop中，工具调用是严格串行的：
```
用户输入 → LLM推理 → 调用工具A → 等待结果 → LLM推理 → 调用工具B → 等待结果 → ...
```
一个典型的5步工具调用Agent，每步包含：
- LLM推理延迟：800-1500ms（Claude Sonnet 4.5级别）
- 工具执行延迟：200-2000ms（API调用、数据库查询等）
- **串行总延迟**：5 × (1200 + 800) ≈ 10秒
### 2.2 并行调用：三大厂商的实现差异
2026年三大厂商全部支持并行工具调用，但实现策略截然不同：
**OpenAI（GPT-5）**：原生并行，单次响应返回多个`tool_calls`：
```python
# GPT-5 并行工具调用
response = client.chat.completions.create(
model="gpt-5",
messages=[{"role": "user", "content": "查北京和上海的天气，然后预订最便宜的机票"}],
tools=[
{"type": "function", "function": {"name": "get_weather", ...}},
{"type": "function", "function": {"name": "search_flights", ...}},
],
parallel_tool_calls=True # 默认开启
)
# 返回：[get_weather("北京"), get_weather("上海")] 并行执行
```
**Claude（Sonnet 4.5）**：多个`tool_use`内容块并行：
```python
# Claude Sonnet 4.5 并行工具调用
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
messages=[{"role": "user", "content": "查北京和上海的天气"}],
tools=[
{"name": "get_weather", "input_schema": {...}},
],
)
# response.content 中包含多个 tool_use 块，可并行执行
```
**Gemini 3.5 Flash**：`functionCall`数组并行 + 独特的Context Circulation：
```python
# Gemini 3.5 并行 + Context Circulation
result = gemini.generate_content(
"查天气并订机票",
tools=[weather_tool, flight_tool, search_tool],
tool_config={"function_calling_config": {"mode": "AUTO"}}
)
# Gemini支持将Google Search + 自定义函数 + Google Maps
# 在单次调用中组合执行（2026年3月新增）
```
### 2.3 投机执行：延迟优化的前沿
2026年出现了一种更激进的优化——**投机式工具调用（Speculative Tool Calling）**：
```mermaid
graph TD
A[LLM推理: 可能需要工具A和B] --> B{预测依赖关系}
B -->|独立| C[并行调用A+B]
B -->|依赖| D[先调用A, 预执行B的参数预测]
D --> E{A结果是否验证B的参数?}
E -->|验证通过| F[直接使用B的投机结果]
E -->|需要修正| G[用A结果重新调用B]
F --> H[总延迟 ≈ max A,B]
G --> I[总延迟 ≈ A + B修正]
```
实测数据（基于agentmarketcap.ai的2026年4月测试）：
| 策略 | 5步任务延迟 | 准确率 | Token消耗 |
|------|------------|--------|----------|
| 纯串行 | 10.2s | 100% | 1.0x |
| 识别并行 | 6.1s (-40%) | 99.2% | 1.0x |
| 投机执行 | 3.8s (-63%) | 96.8% | 1.15x |
| 激进投机 | 2.9s (-72%) | 91.3% | 1.3x |
**核心取舍**：投机执行将延迟压缩63%，代价是3.2%的准确率损失和15%的额外Token消耗。对于客服、搜索等容忍度较高的场景，这是值得的；对于金融交易、医疗处方等场景，串行或保守并行更安全。
---
## 三、第二浪：严格模式（Strict Mode）——JSON Schema合规的终极武器
### 3.1 三栈Strict Mode对比
2026年，三大厂商不约而同地推出了**Strict Mode**——确保模型输出严格符合JSON Schema：
| 特性 | OpenAI GPT-5 | Claude Sonnet 4.5 | Gemini 3.5 |
|------|-------------|-------------------|------------|
| Schema合规率 | 100%（保证） | 99.7%（实测） | 99.1%（实测） |
| Strict Mode API | `strict: true` | `output_format` + JSON | `response_schema` |
| 嵌套Schema深度 | 最多6层 | 无硬限制 | 最多10层 |
| optional字段处理 | 强制required或optional | 灵活 | 灵活 |
| `$ref`支持 | ✅ | ✅ | ❌ |
| `anyOf/oneOf` | ✅ | ✅ | 部分 |
| 流式输出+Strict | ✅ | ✅ | ❌ |
| 额外延迟 | +50-100ms | +80-150ms | +30-80ms |
**关键发现**：OpenAI的`strict: true`通过约束解码（Constrained Decoding）在Token生成阶段就保证合规，**100%不违规**。Claude通过后处理+重试实现99.7%——在极端复杂Schema下有0.3%的边缘case失败。Gemini的`response_schema`延迟最低但Schema合规率也最低。
### 3.2 Strict Mode的隐藏代价
```python
# OpenAI Strict Mode 示例
response = client.chat.completions.create(
model="gpt-5",
messages=[...],
tools=[{
"type": "function",
"function": {
"name": "book_flight",
"strict": True, # 关键参数
"parameters": {
"type": "object",
"properties": {
"origin": {"type": "string"},
"destination": {"type": "string"},
"date": {"type": "string", "format": "date"},
"passengers": {"type": "integer", "minimum": 1}
},
"required": ["origin", "destination", "date"]
}
}
}]
)
```
实测发现Strict Mode有三个隐性代价：
1. **Schema复杂度上限**：OpenAI限制`maximum`属性不能超过Schema总属性的约30个，嵌套不能超过6层。生产中复杂的业务Schema经常触限。
2. **推理能力退化**：开启`strict: true`后，模型在需要"创造性"参数填充时表现下降。例如让Agent填写`reason`字段时，Strict Mode倾向于生成更短、更模板化的文本。
3. **延迟惩罚**：约束解码需要额外的前向传播来验证每个Token的合法性，平均增加50-150ms。对于需要调用10+工具的复杂Agent，累计延迟可达1-1.5秒。
### 3.3 最佳实践：何时开启Strict
```
开启Strict Mode的场景：
├── API参数构造（类型安全 > 灵活性）
├── 数据库查询生成（防止SQL注入的前提）
├── 金融交易参数（100%合规是硬性要求）
└── 自动化测试（确定性 > 多样性）
不开启Strict Mode的场景：
├── 搜索查询生成（需要创意性措辞）
├── 内容摘要/翻译（灵活性 > 格式约束）
├── 探索性数据分析（Schema可能动态变化）
└── 原型开发阶段（快速迭代 > 严谨合规）
```
---
## 四、第三浪：多模态工具调用——从文本到全感官
### 4.1 Gemini 3的突破：图像作为工具参数
2026年最引人注目的工具调用进化是**多模态参数传递**。Gemini 3率先支持将图像、PDF直接作为工具调用的输入参数：
```python
# Gemini 3 多模态工具调用
import google.generativeai as genai
model = genai.GenerativeModel('gemini-3.5-flash')
# 定义接受图像输入的工具
extract_invoice_tool = {
"function_declarations": [{
"name": "process_invoice",
"description": "从发票图片中提取金额、日期、供应商",
"parameters": {
"type": "OBJECT",
"properties": {
"image_data": {"type": "STRING", "description": "Base64编码的发票图片"},
"amount": {"type": "NUMBER"},
"vendor": {"type": "STRING"},
"date": {"type": "STRING"}
}
}
}]
}
# 模型可以直接处理发票图片并调用工具
response = model.generate_content(
[invoice_image, "请提取这张发票信息并录入系统"],
tools=[extract_invoice_tool]
)
```
### 4.2 Claude的Computer Use：GUI即工具
Claude的Computer Use代表了多模态工具调用的另一条路径——**将GUI本身作为工具**。Sonnet 4.5在2026年推出的Computer Use能力：
```python
# Claude Computer Use - 将屏幕操作工具化
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
messages=[{
"role": "user",
"content": "在Salesforce中创建一个新的客户记录，名字叫张三"
}],
tools=[{
"type": "computer_20250124",
"name": "computer",
"display_width_px": 1920,
"display_height_px": 1080
}]
)
# Claude会返回：鼠标点击坐标、键盘输入、截图请求等工具调用
```
### 4.3 三栈多模态工具调用对比
```
┌───────────────┬────────────────┬─────────────┬──────────────┐
│ 能力 │ Gemini 3.5 │ Claude 4.5 │ GPT-5 │
├───────────────┼────────────────┼─────────────┼──────────────┤
│ 图像→工具参数 │ ✅ 原生支持 │ ⚠️ 需先描述 │ ⚠️ 需先描述 │
│ 音频→工具参数 │ ✅ 原生支持 │ ❌ │ ❌ │
│ PDF→工具参数 │ ✅ 原生支持 │ ⚠️ 间接 │ ⚠️ 间接 │
│ GUI操作工具 │ ❌ │ ✅ Computer │ ❌ │
│ │ │ Use │ │
│ 视频帧→工具 │ ✅ 长上下文 │ ❌ │ ❌ │
│ 内置工具混调 │ ✅ Search+Maps │ ❌ │ ⚠️ 插件生态 │
│ │ +自定义函数 │ │ │
└───────────────┴────────────────┴─────────────┴──────────────┘
```
**关键洞察**：Gemini 3.5在多模态工具调用上领先一代，但Claude的Computer Use开辟了另一条赛道——直接操作GUI。两条路径在2026年尚未合流，各有适用场景。Gemini适合"文档理解→结构化数据→API调用"的管道；Claude适合"无API的系统→GUI自动化操作"的场景。
---
## 五、幻觉地板：3-7%的工具调用幻觉为什么降不下去
### 5.1 工具调用幻觉的三类形态
2026年的研究（arxiv:2601.05214, agentmarketcap.ai等）揭示了一个令人不安的事实：**工具调用幻觉存在3-7%的"地板"，且与模型规模无关**。
工具调用幻觉不是一种bug，而是三种：
```
工具调用幻觉三分法
├── 第一类：幽灵函数（Phantom Function）
│ 模型调用了工具列表中根本不存在的函数
│ 发生率：0.5-1.2%
│ 典型案例：列表中有get_weather，模型调用check_weather
│
├── 第二类：参数幻觉（Argument Hallucination）
│ 函数选对了，但参数值凭空捏造
│ 发生率：1.5-3.8%
│ 典型案例：API要求order_id，模型生成看似合法但实际不存在的ID
│ └── 子类A：参数类型正确但值虚构（"PL-88291"不存在）
│ └── 子类B：参数类型错误（传字符串给整数字段）
│
└── 第三类：Schema幻觉（Schema Drift）
模型使用了正确的函数，但添加了Schema中没有的字段
发生率：0.8-2.0%
典型案例：添加priority字段，但Schema中从未定义过
```
### 5.2 为什么3-7%是地板
来自arxiv:2601.05214的研究发现，**工具调用幻觉与模型内部表征的确定性信号直接相关**。当模型在内部表征中对"该调哪个工具"的置信度低于某个阈值时，幻觉概率急剧上升。这个阈值不随模型规模增大而消失——因为工具调用本质上是在一个**极其稀疏的语义空间**中做精确匹配：
- 10个工具 → 正确选择概率约96-97%
- 50个工具 → 正确选择概率约93-95%
- 100+工具 → 正确选择概率约88-91%
**模型越大，语义理解越好，但"精确匹配"和"语义理解"是正交能力。** GPT-5在语义理解上远超GPT-3.5，但在100+工具场景下的选择准确率提升仅为5-8个百分点。
### 5.3 缓解策略：四层防线
```mermaid
graph TB
A[工具调用请求] --> B[第1层: Schema验证]
B -->|Strict Mode| C[第2层: 函数名白名单校验]
B -->|不合规| X[拒绝并重试]
C -->|函数名合法| D[第3层: 参数类型+范围校验]
C -->|函数名不存在| X
D -->|参数合法| E[第4层: 执行后语义校验]
D -->|参数异常| X
E -->|结果合理| F[返回结果]
E -->|结果异常| G[标记幻觉 并降级]
```
实测效果：四层防线可将幻觉率从3-7%降至0.3-0.8%，代价是增加约15%的延迟和约8%的Token消耗（重试成本）。
---
## 六、生产实战：工具调用的12-18%失败率怎么治
### 6.1 失败分类学
2026年的生产数据（来自agentmarketcap.ai的聚合统计）显示，Agent在真实生产环境中的工具调用失败率远高于基准测试：
```
生产环境工具调用失败分类
├── 工具幻觉（3-7%） → 模型问题
├── API超时/限流（4-6%） → 基础设施问题
├── 参数格式错误（2-3%） → Schema设计问题
├── 工具执行逻辑错误（2-3%）→ 业务逻辑问题
├── 权限/认证失败（1-2%） → 安全问题
└── 总失败率：12-18%
```
### 6.2 五种错误恢复模式
生产Agent必须实现的五种错误恢复模式：
**模式一：指数退避重试**
```python
async def tool_call_with_retry(tool_fn, args, max_retries=3):
for attempt in range(max_retries):
try:
result = await tool_fn(**args)
return result
except (TimeoutError, RateLimitError) as e:
wait = min(2 ** attempt + random.uniform(0, 1), 30)
await asyncio.sleep(wait)
raise ToolCallExhausted(f"Failed after {max_retries} retries")
```
**模式二：熔断器（Circuit Breaker）**
```python
class ToolCircuitBreaker:
def __init__(self, failure_threshold=5, reset_timeout=60):
self.failures = 0
self.failure_threshold = failure_threshold
self.reset_timeout = reset_timeout
self.state = "CLOSED" # CLOSED → OPEN → HALF_OPEN
self.last_failure_time = None
async def call(self, tool_fn, args):
if self.state == "OPEN":
if time.time() - self.last_failure_time > self.reset_timeout:
self.state = "HALF_OPEN"
else:
raise CircuitOpenError("Tool circuit is open")
try:
result = await tool_fn(**args)
if self.state == "HALF_OPEN":
self.state = "CLOSED"
self.failures = 0
return result
except Exception:
self.failures += 1
self.last_failure_time = time.time()
if self.failures >= self.failure_threshold:
self.state = "OPEN"
raise
```
**模式三：降级回退（Fallback Model）**
当主模型工具调用失败时，自动切换到备选模型重试。实测配置：GPT-5（主）→ Claude Sonnet 4.5（备）→ Gemini 3.5 Flash（兜底），三栈级联可将失败率从12%降至1.5%。
**模式四：参数修复（Parameter Healing）**
当工具返回参数错误时，将错误信息反馈给模型，让其修正参数后重试：
```python
async def call_with_healing(model, tool_schema, user_input, tool_impl):
for attempt in range(3):
response = await model.generate(user_input, tools=[tool_schema])
if response.tool_calls:
for call in response.tool_calls:
try:
return await tool_impl(call.arguments)
except ValidationError as e:
# 将错误反馈给模型，让它修正参数
user_input = f"上次调用失败，错误: {e}。请修正参数后重试。"
continue
raise ToolCallFailed("参数修复3次仍失败")
```
**模式五：结果验证（Result Verification）**
工具执行成功不代表结果正确。用一个轻量级模型（或规则引擎）验证返回值：
```python
async def verified_tool_call(model, tool_fn, args):
result = await tool_fn(**args)
# 用Haiku级别模型验证结果合理性
verification = await verify_model.generate(
f"工具{tool_fn.__name__}被调用，参数{args}，返回{result}。结果是否合理？",
response_format={"type": "boolean"}
)
if not verification:
return {"error": "结果验证失败", "raw_result": result}
return result
```
### 6.3 五种模式的组合效果
| 组合策略 | 失败率 | 平均延迟 | Token成本 |
|----------|--------|---------|----------|
| 无恢复 | 12-18% | 基准 | 1.0x |
| 仅重试 | 6-8% | +20% | 1.1x |
| 重试+熔断 | 4-5% | +15% | 1.1x |
| 重试+熔断+降级 | 2-3% | +25% | 1.3x |
| 重试+熔断+降级+修复+验证 | **0.8-1.5%** | +40% | 1.5x |
**生产推荐**：对于大多数场景，"重试+熔断+降级"三板斧即可将失败率降至2-3%，性价比最高。五层全开仅适用于金融、医疗等高风险场景。
---
## 七、开源工具调用模型：从追赶者到搅局者
### 7.1 ToolACE-8B：小模型的逆袭
ToolACE（ICLR 2025收录）证明了一件事：**专注工具调用的8B模型可以击败通用70B模型**。
核心创新是其自动化的工具调用数据生成管线：
```
ToolACE数据管线
├── Stage 1: 多Agent生成多样化函数Schema
├── Stage 2: 基于Schema的指令生成（用户提问）
├── Stage 3: Self-Check过滤低质量数据
├── Stage 4: 多轮对话场景增强
└── 输出：40K+高质量工具调用pair
```
ToolACE-8B在BFCL v3上的表现：**综合准确率86.2%**，超过了Llama-3-70B的82.4%和Mistral-Large的84.1%。这在工具调用领域是里程碑——8B参数量实现了70B级别的工具调用能力。
### 7.2 NexusRaven-V2：商业级开源工具调用
NexusRaven-V2-13B是另一个值得关注的开源工具调用模型，专精于**单轮函数选择**：
```
NexusRaven-V2-13B 性能
├── 单轮函数调用准确率：91.2%（接近GPT-4 Turbo的92.5%）
├── 多函数场景（50+函数）：88.7%
├── 延迟（本地A100）：180ms
├── 商用许可：Apache 2.0 ✅
└── 部署：Ollama一键运行
```
### 7.3 开源 vs 闭源：工具调用场景的选择
```
选择开源工具调用模型的场景：
├── 数据隐私要求（不能把工具Schema和参数发到云端）
├── 延迟敏感（本地推理180ms vs API调用800ms+）
├── 成本敏感（长尾工具调用，每百万次调用省$300+）
└── 工具Schema固定（不需要理解海量动态工具）
继续用闭源API的场景：
├── 工具数量>100（开源模型的长尾工具选择能力仍弱）
├── 多轮复杂推理（tau-bench差距仍大）
├── 多模态工具调用（开源生态不成熟）
└── 快速原型（API接入成本低10倍）
```
---
## 八、架构选型：不同场景的工具调用方案推荐
```mermaid
graph TD
START[工具调用需求] --> Q1{工具数量?}
Q1 -->|<10个| A1[任何模型均可
BFCL差异<2%]
Q1 -->|10-50个| Q2{是否多轮?}
Q1 -->|>50个| Q3{数据能否上云?}
Q2 -->|单轮| B1[Gemini 3.5 Flash
性价比最优]
Q2 -->|多轮| B2[Claude Sonnet 4.5
多轮最稳定]
Q3 -->|能上云| C1[GPT-5 + Strict Mode
100%合规]
Q3 -->|不能上云| C2[ToolACE-8B本地
隐私+低成本]
A1 --> D[延迟预算<500ms?]
B1 --> D
B2 --> D
C1 --> D
C2 --> D
D -->|是| E1[并行调用+投机执行
开源模型本地]
D -->|否| E2[串行+严格验证
五层错误恢复]
```
### 综合推荐矩阵
| 场景 | 推荐模型 | 严格模式 | 错误恢复 | 预估准确率 | 月成本(10万次) |
|------|---------|---------|---------|-----------|--------------|
| 客服机器人 | Gemini 3.5 Flash | 关 | 重试+熔断 | 89% | $50-80 |
| 金融交易 | GPT-5 Strict | 开 | 五层全开 | 99.5% | $500-800 |
| 数据分析 | Claude Sonnet 4.5 | 关 | 重试+降级 | 91% | $200-300 |
| 文档处理 | Gemini 3.5 Pro | 开 | 重试+修复 | 94% | $150-250 |
| 本地私有化 | ToolACE-8B | N/A | 重试+熔断 | 86% | GPU折旧$100 |
| ERP/GUI自动化 | Claude Computer Use | N/A | 重试+熔断+降级 | 82% | $400-600 |
---
## 九、延伸观察：工具调用的下一个拐点
2026年H1的三大浪涌（并行、严模式、多模态）指向一个共同趋势：**工具调用正在从"能力"变成"基础设施"**。三个值得关注的信号：
1. **MCP标准化加速**：MCP（Model Context Protocol）在2026年已覆盖12,000+服务器，Fortune 500的80%正在评估。工具调用的接口定义、发现机制、安全策略正在走向标准化——就像HTTP统一了信息传输一样，MCP可能统一Agent的工具接入。
2. **工具调用进入芯片**：NVIDIA在2026年H1透露，下一代Grace芯片将支持"工具调用加速"——将Schema验证、参数类型检查等操作卸载到专用硬件单元，预期将Strict Mode的额外延迟从50-150ms降至5-15ms。
3. **自主工具创造**：Agent不再仅从预定义工具中选择，而是根据任务动态编写工具代码。这一能力在2025年末的SWE-bench中已初露端倪，2026年正在从研究走向早期产品化。
当工具调用成为像TCP/IP一样透明的底层能力，Agent的竞争焦点将从"能调多少工具"转向"能理解多少业务"。那是AI Agent真正进入深水区的时刻。
---
## 参考来源
1. [BFCL V4: The Tool-Call Benchmark That Exposes What SWE-bench Can't See](https://agentmarketcap.ai/blog/2026/04/11/bfcl-v4-berkeley-function-calling-leaderboard-agentic-2026) — BFCL v4基准揭示工具调用与编码能力是独立技能
2. [The Tool-Call Hallucination Plateau: Why AI Agents Still Misfire 3-7% of the Time](https://agentmarketcap.ai/blog/2026/04/12/ai-agent-tool-call-hallucination-plateau-2026) — 工具调用幻觉3-7%地板现象分析
3. [Parallel Tool Calling in 2026: How to Cut Agent Latency by 40-70%](https://agentmarketcap.ai/blog/2026/04/11/parallel-tool-calling-speculative-execution-agent-pipelines-2026) — 并行工具调用与投机执行延迟实测
4. [Internal Representations as Indicators of Hallucinations in Agent Tool Calling](https://arxiv.org/html/2601.05214) — 工具调用幻觉的内部表征机制研究
5. [ToolACE: Winning the Points of LLM Function Calling (ICLR 2025)](https://arxiv.org/abs/2409.00920) — 开源工具调用训练数据管线与8B模型性能
> [!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 等场景全覆盖。
