
Agent 工具注册表的分发路径有三种常见实现：每次反射 `MethodInfo.Invoke`、启动时缓存强类型委托、表达式树编译成统一签名委托。本文在 .NET 10.0.5 / Apple M4（macOS arm64）上把这条链路拆开量了：分发层已经不是问题，**参数绑定才是**。

结论先行：

- 反射 `Invoke` 一次约 20ns、72~112B 分配，只比直接调用慢 10 倍，绝对值微不足道；
- 缓存强类型委托与直接调用同价（约 2ns，0 分配），表达式树委托约 11~14ns；
- 但从 JSON 参数走到方法调用，**全链路 135~159ns，其中 JSON 解析+取参占约 119ns（76%）**，分发方式只影响剩下的 20 多纳秒。

## 实验设置

一个真实工具 `int Add(int a, int b)`，JSON 参数 `{"a":3,"b":4}`，模拟 Agent 每收到一次工具调用要走的路。三组分发方式 + 一组纯 JSON 底价，每组 200 万次调用 × 5 轮取中位数，GC.GetAllocatedBytesForCurrentThread 统计分配。跑两轮，中位数偏差小于 3%。

可复现步骤：

1. `dotnet new console` 建 ToolDispatchLab，无第三方依赖；
2. 反射路径：`typeof(Program).GetMethod("Add")` + `Invoke(null, args)`；
3. 委托路径：`mi.CreateDelegate<Func<int,int,int>>()`；
4. 表达式树路径：`Expression.Lambda<Func<object?[], object?>>(Expression.Convert(Expression.Call(mi, unbox each arg), typeof(object)))`，`Compile()` 一次、调用百万次；
5. 全链路：`JsonDocument.Parse(ArgsJson)` → `GetProperty` 取参 → 三种方式之一调用。

## 分发层：三种方式的开销

| 方式 | ns/op | 分配 B/op |
|---|---|---|
| 直接调用（下限） | 1.9~2.1 | 0 |
| 反射 Invoke（每次新建参数数组） | 20.5~20.7 | 112 |
| 反射 Invoke（复用数组，仅重填装箱） | 19.7~19.9 | 72 |
| 强类型委托缓存 | 2.1~2.1 | 0 |
| 表达式树委托（每次新建参数数组） | 13.9~14.0 | 112 |
| 表达式树委托（复用数组） | 11.5~11.6 | 72 |
| 注册表 Dictionary 查找 | 10.7~10.8 | 0 |

三个反直觉的点：

1. **反射不再贵**。教科书里"反射慢几十倍"指的是 `GetMethod` 这类元数据查找，不是 `Invoke` 本身。`Invoke` 稳态约 20ns，慢的是它每次强制装箱参数（int → object，24B × 2）加上参数数组（40B）。把数组复用掉，分配从 112B 降到 72B，时间几乎不变——省的全是分配，不是调用本身。
2. **强类型委托缓存 = 直接调用**。`CreateDelegate` 出来的委托调用被 JIT 处理得和普通调用完全一样，2.1ns、零分配。委托缓存唯一要付的成本在启动期。
3. **表达式树委托 11~14ns**，介于两者之间。它签名为 `object?[] → object?`，天然要拆箱+装箱返回值，比强类型委托慢 5 倍但仍比反射快 1.7 倍。它的优势是签名统一、能覆盖任意工具，不用为每个签名写适配代码。

## 全链路：JSON 绑定吃掉 76%

| 路径 | ns/op | 分配 B/op |
|---|---|---|
| 仅 Parse + GetProperty（底价） | 118.9~119.4 | 72 |
| 反射全链 | 156.6~159.0 | 184 |
| 表达式树全链 | 146.2~146.6 | 184 |
| 强类型委托全链 | 134.8~135.3 | 72 |

全链路账单这样拆：反射全链约 157ns，减去 JSON 底价 119ns，分发只占约 38ns（与 B1+B10 的 20.7+10.8 对得上）。也就是说，**换分发实现只能动 38ns 里的一小段；从反射全链换到委托全链，总共省 24ns，约 15%**。

分配也一样：JSON 解析 + GetProperty 本身就产生 72B，分发层装箱再加 40~112B。B7/B8 的 184B 里，77% 来自绑定层。

## 什么时候值得做委托缓存

按上面的数推算不同场景：

- **每秒几千次工具调用的 Agent 服务**：分发方式无关紧要。反射全链 157ns 意味着每秒 10 万次调用也才 15.7ms CPU，JSON 解析才是大头，优化它比优化分发有效 4 倍以上。
- **单进程高频本地调度**（如本地 LLM 的函数调用循环）：委托缓存或表达式树编译能把全链压到 135ns，省 15%，顺带把分配从 184B 压到 72B（省 61%），GC 压力敏感时值得。
- **工具签名五花八门**：表达式树是唯一能"一套代码吃所有签名"的方案，11ns 的代价比每签名手写适配便宜得多。

## 落地建议

1. 注册表直接 `Dictionary<string, MethodInfo>`（10.8ns/0B），查表不是瓶颈；
2. 默认用反射即可，别为 20ns 引入复杂度；但**复用参数数组**——免改一行逻辑省 40B/次；
3. 真要压尾延迟，把 `CreateDelegate` 或表达式树编译做在启动期，运行期零反射；
4. 别动分发层了，去优化参数绑定：JsonDocument.Parse 是 119ns/72B 的固定税，重解析同一 schema 的场景可以换 `Utf8JsonReader` 增量解析或缓存 PropertyName 的 Span 比较（本站 2026-11-06 那篇输出解析文有对应的增量思路）。

## 方法说明

- 环境：.NET 10.0.5，Apple M4（10 核），macOS 26.7.1 arm64，Release；
- 每组 500k 次预热到稳态，5 轮 × 200 万次取中位数；B1 每轮前两次因分层编译偏高（39~40ns），中位数已剔除影响，两轮中位数复现偏差 <3%；
- B2/B5 复用数组时 int 装箱（24B × 2）无法避免，故 72B 是这两组的地板；
- 待测：表达式树委托的拆箱成本随参数个数线性增长，多参数工具（>4 参数）时与反射的差距需要单独量。


Agent 工具注册表的分发路径有三种常见实现：每次反射 MethodInfo.Invoke、启动时缓存强类型委托、表达式树编译成统一签名委托。本文在 .NET 10.0.5 / Apple M4（macOS arm64）上把这条链路拆开量了：分发层已经不是问题，参数绑定才是。

LLM 工具调用分发实测：反射 Invoke 只要 20 纳秒，真正的瓶颈是 JSON 参数绑定，占 76%

人工智能

编程语言

后端

Agent工具注册表分发：反射Invoke稳态仅20ns/112B，强类型委托2ns零分配，表达式树11-14ns。但全链路135-159ns中，JSON解析+取参占119ns（76%），分发方式仅影响15%。缓存委托或复用参数数组可省40B分配，高频率调用场景建议启动期编译委托，优化重点应转向JSON绑定层。

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

LLM 工具调用分发实测：反射 Invoke 只要 20 纳秒，真正的瓶颈是 JSON 参数绑定，占 76%-腾讯云开发者社区-腾讯云

LLM 工具调用分发实测：反射 Invoke 只要 20 纳秒，真正的瓶颈是 JSON 参数绑定，占 76%

LLM 工具调用分发实测：反射 Invoke 只要 20 纳秒，真正的瓶颈是 JSON 参数绑定，占 76%

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐