AI辅助开发令牌效率分析工具

人工智能辅助开发中的令牌效率：工具集成模式的比较分析

摘要

这项研究调查了五种不同的将人工智能助手与开发工具集成的方法中的代币消费模式。使用500行数据集的受控数据分析任务，我们测量了令牌使用、API调用效率和可扩展性特征。结果表明，与基线代码生成方法相比，优化的工具集成可以将令牌消耗减少高达81%，这对生产部署成本和系统设计具有重大影响。

主要发现：

• 优化的MCP方法：60K代币（与基线相比减少81%）
• 渐进式发现代理：81K-155K代币（与基线相比减少50-75%）
• UTCP代码模式方法：182K-240K令牌（意外高于基线）
• 基线代码生成：108K-158K令牌
• 普通MCP方法：204K-309K令牌（由于数据传递，效率最低）

1.目的

1.1研究目标

现代人工智能辅助开发依赖于大型语言模型（LLM），这些模型消耗令牌作为输入和输出。随着组织将人工智能集成扩展到生产工作流程中，代币效率成为关键的成本和性能因素。本研究旨在：

1. 量化代币效率 跨不同的工具集成架构
2. 确定可扩展性特征 数据集大小各不相同
3. 评估权衡 在灵活性、效率和实现复杂性之间
4. 建立循证指南 用于生产系统设计
5. 基准新兴协议 （MCP、UTCP、渐进式发现）

1.2行业背景

代币消费直接影响：

• 运营成本：在规模上，代币效率转化为显著的成本节约
• 延迟：更少的令牌减少了处理时间和网络开销
• 上下文窗口利用率：高效的方法保留了复杂推理的上下文
• 可扩展性：数据传递方法在处理大型数据集时失败；基于文件的方法可以线性扩展

1.3研究问题

1. 工具集成架构如何影响代币消费？
2. 跨方法的数据集大小和令牌效率之间的关系是什么？
3. 渐进式工具发现能否减少初始上下文开销？
4. 声明性代码生成方法（UTCP）是否提高了效率？
5. 生产部署的实施权衡是什么？

2.方法

2.1实验设计

受控变量：

• 任务描述：所有方法都有相同的160字提示
• 数据集：500条员工记录（7个部门，7个地点，现实分布）
• 所需产出：4项统计分析+4项可视化
• 型号：克劳德十四行诗4.5（Claude-Sonnet-4-5-20250929）
• 环境：带网络检测的Claude Code CLI

独立变量：

• 工具集成方法（5种变体）

因变量：

• 令牌总消耗量（输入+输出+缓存）
• API调用计数
• 按请求分配令牌
• 累计代币增长

2.2测试方法

方法1：代码技能（基线）

架构： LLM在技能指导下生成和执行Python脚本

实施：

• 技能在没有明确工具的情况下提供领域指导
• LLM编写完整的Python脚本用于分析和可视化
• 通过脚本生成进行迭代细化

假设： 最大的灵活性，但由于代码冗长，令牌开销更高

方法2:MCP香草

架构： 具有直接数据传递的模型上下文协议

实施：

• MCP服务器公开了以下工具： read_csv_data, analyze_data, create_visualization
• 作为工具参数传递的完整数据数组
• 每个操作的顺序工具调用

假设： 减少了API调用，但大型数据集的令牌成本较高

方法3:MCP优化

架构： 基于文件路径的MCP工具

实施：

• 工具接受文件路径而不是数据数组： analyze_csv_file, create_visualization_from_file
• 服务器在内部读取文件
• 启用并行工具调用（单个请求中的多个可视化）

假设： 最小的令牌开销，可随数据集大小而扩展

方法4:MCP代理（一个MCP）

架构： 通过元工具进行渐进式工具发现

实施：

• 初始上下文：2个元工具(describe_tools, use_tool)约400个代币
• 按需加载的工具与预先加载的工具（所有工具约10000+个代币）
• 初始管理费用减少90%以上

假设： 降低初始开销，提高会话效率

方法5:UTCP编码模式

架构： 带有TypeScript代码生成的通用工具调用协议

实施：

• LLM生成调用MCP工具的TypeScript代码
• 生成代码的单次执行
• 声称速度快60%，令牌减少68%，API调用减少88%

假设： 代码生成+工具集成=两全其美

2.3数据收集

网络仪表：

// networkLog.js - Intercepts all HTTP(S) requests
process.on('fetch', (request, response) => {
  // Capture full request/response including token usage
  logAPICall({
    url, method, status, duration,
    requestBody, responseBody,
    parsedMessage: { usage: { input_tokens, output_tokens, ... } }
  });
});

捕获的指标：

• input_tokens：常规输入令牌
• output_tokens：生成的令牌
• cache_creation_input_tokens：提示缓存创建
• cache_read_input_tokens：提示缓存命中
• total_tokens：所有令牌类型的总和
• duration：请求延迟
• model：型号标识符
• stop_reason：完成原因

数据管道：

1. 原始数据收集：包含完整请求/响应的网络日志（包括PII）
2. PII编辑：删除API密钥、用户ID、工作区路径、电子邮件、电话号码
3. JSONL转换：每行一个API调用用于分析
4. 可视化：用于比较图表的Python matplotlib

2.4隐私和道德

所有收集的数据都经过了自动PII编辑：

• API密钥和令牌→ [REDACTED]
• 用户/帐户/会话ID→ [ID_REDACTED]
• 工作区路径→ /workspace
• 电子邮件地址→ [EMAIL]
• 电话号码→ [PHONE]
• 操作系统版本详细信息→ [OS_VERSION]

保留内容和工具交互以供分析。

2.5统计分析

每种方法的会话： 3（用于方差测量） 聚合： 各时段的平均值和方差 可视化： 按请求和累计令牌使用图表 比较： 内部方法（会话差异）和交叉方法（效率排名）

3.结果

3.1整体代币效率排名

3.2按方法划分的详细结果

MCP优化（获胜者）

Session 1: 60,307 tokens (4 calls, 15,077 avg)
Session 2: 60,144 tokens (4 calls, 15,036 avg)
Session 3: 60,808 tokens (4 calls, 15,202 avg)

Variance: ±0.6% (extremely consistent)
Efficiency: 81% better than worst approach, 44% better than baseline

主要特征：

• 最小的上下文消耗（仅文件路径）
• 并行工具执行（单个请求中有4个可视化）
• 随数据集大小线性缩放
• 会话间差异最小

架构优势：

// Single API call generates 4 visualizations in parallel
{
  "tool_uses": [
    { "name": "create_visualization_from_file", "input": { "path": "...", "type": "bar" } },
    { "name": "create_visualization_from_file", "input": { "path": "...", "type": "scatter" } },
    { "name": "create_visualization_from_file", "input": { "path": "...", "type": "pie" } },
    { "name": "create_visualization_from_file", "input": { "path": "...", "type": "bar" } }
  ]
}
// Total context: ~400 tokens vs ~10,000+ if passing data arrays

MCP代理（第二名）

Session 1: 154,734 tokens (8 calls, 19,342 avg) - Initial discovery overhead
Session 2:  81,528 tokens (5 calls, 16,306 avg) - Optimized after discovery
Session 3:  81,415 tokens (5 calls, 16,283 avg) - Stable performance

Variance: ±47% (session 1 vs 2-3)
Efficiency: 50% better than baseline in steady state

主要特征：

• 渐进式发现：最初有2个元工具，而完整的工具描述有10多个
• 跨期摊销的初始管理费用
• 前期工具环境减少90%
• 发现后收敛到高效模式

渐进式发现模式：

Session 1: describe_tools() → load needed tools → use_tool()
           High overhead from discovery process

Sessions 2+: Tools cached, direct use_tool() calls
             Steady-state efficiency achieved

代码技能基线

Session 1: 157,749 tokens (8 calls, 19,719 avg)
Session 2: 132,702 tokens (7 calls, 18,957 avg)
Session 3: 108,566 tokens (6 calls, 18,094 avg)

Variance: ±31% (session-to-session)
Efficiency: Reference baseline

主要特征：

• 由于代码生成路径不同，差异较大
• 顺序脚本生成和执行
• 每次迭代上下文中的完整代码
• 调试开销增加了API调用

差异分析： 不同的解决方案路径会导致不可预测的令牌使用：

• 会话1：更多的调试迭代（8次调用）
• 第2节：中等复杂度路径（7次调用）
• 会话3：找到有效路径（6次调用）

UTCP代码模式（性能不佳）

Session 1: 190,113 tokens (9 calls, 21,124 avg)
Session 2: 182,377 tokens (9 calls, 20,264 avg)
Session 3: 239,542 tokens (11 calls, 21,777 avg)

Variance: ±23% (session-to-session)
Efficiency: 40-68% WORSE than baseline ⚠️

主要特征：

• 生成TypeScript代码以调用MCP工具
• 令牌开销高于直接工具调用
• API调用多于预期
• 未实现声称的效率提升

意外结果分析： 与声称的“代币减少68%，API调用减少88%”相反：

1. 与直接工具调用相比，代码生成增加了冗长性
2. TypeScript编译/执行开销
3. 错误处理需要额外的迭代
4. 未针对基于文件的操作进行优化

假设： UTCP可能擅长不同的用例（复杂的工作流、条件逻辑），但不擅长数据分析任务。

MCP香草（效率最低）

Session 1: 299,908 tokens (9 calls, 33,323 avg)
Session 2: 309,053 tokens (9 calls, 34,339 avg)
Session 3: 204,099 tokens (7 calls, 29,157 avg)

Variance: ±34% (session-to-session)
Efficiency: 88-195% WORSE than baseline ❌

主要特征：

• 在每次工具调用中传递完整的500行数据集
• 跨多个操作的数据复制
• 上下文窗口饱和度
• 不随数据集大小而缩放

代币细分分析：

Example tool call with data passing:
{
  "data": [
    {"name": "Alice", "dept": "Engineering", "salary": 95000, ...}, // Row 1
    {"name": "Bob", "dept": "Marketing", "salary": 75000, ...},     // Row 2
    ... // 498 more rows
  ]
}

Token cost: ~8,000-12,000 tokens per call just for data
Total across 9 calls: ~80,000 tokens wasted on data duplication

3.3可扩展性分析

数据集大小与令牌消耗：

关键发现： 文件路径方法（MCP优化）随数据集大小呈次线性扩展，而数据传递方法（MCP香草）呈超线性扩展，对于大型数据集来说成本过高。

外推到10000行：

• MCP优化：约65K代币（最小增加）
• MCP香草：约50万个代币（不可持续）

3.4差异和一致性

3个疗程的变异系数（CV）：

*注：MCP代理差异主要来自会话1的发现开销；第2-3节是一致的（CV~0.5%）

释义：

• 基于工具的方法与确定性工作流（MCP优化）显示出极好的一致性
• 由于解决方案路径差异，代码生成方法（代码技能，UTCP）显示出较高的方差
• 渐进式发现（MCP代理）需要预热期，但随后会稳定下来

3.5成本分析

假设： Claude Sonnet 4.5定价（约3美元/M输入代币，约15美元/M输出代币）

每节课费用（平均）：

投资回报率分析（1000次/月）：

盈亏平衡分析：

MCP优化服务器开发成本在以下时间后摊销：

• 约10次会议 如果开发时间为1周（价值1000美元）
• 约50次会议 如果开发时间为1个月（价值5000美元）

每年1000次会议： 投资回报率=548% （假设开发1个月）

3.6并行化影响

顺序与并行工具调用：

影响：

• 延迟减少： 并行操作的挂钟时间缩短了4倍
• 代币减少： 每个操作没有重复的上下文
• 仅在以下情况下可行： 独立工具+文件路径架构

3.7会话进度模式

MCP代理学习曲线：

Session 1 (Discovery):
  describe_tools() → 17 API calls → 154,734 tokens
  High overhead from exploring available tools

Session 2 (Optimized):
  Direct tool usage → 6 API calls → 81,528 tokens
  47% reduction from session 1

Session 3 (Stable):
  Efficient workflow → 6 API calls → 81,415 tokens
  Consistent performance achieved

含义： 反复使用的系统在初始预热后从逐步发现中受益匪浅。

4.决策指标和权衡

4.1多维决策空间

选择一种方法需要在三个主要维度上平衡相互竞争的目标：

1. 上下文效率与API调用计数
2. 差异容差（一致性要求）
3. 任务重复性（一次性与生产）

这些维度是相互依存的，并为每种方法创建了不同的优化配置文件。

4.2维度1：上下文效率与API调用计数

基本权衡：

• 更少的API调用 每次调用通常需要更多的上下文（复杂的指令、数据传递）
• 每次通话的上下文更少 可能需要更多的API调用（迭代细化、顺序操作）

进场定位：

分析：

MCP优化：帕累托最优

• 实现最少的令牌总数和最少的API调用
• 文件路径体系结构消除了上下文/API调用的权衡
• 并行执行在不增加上下文的情况下进一步减少了API调用
• 通过建筑创新消除权衡

MCP香草：两个世界中最糟糕的

• 由于顺序操作，API调用次数高（7-9）
• 由于数据传递，每次通话的最高令牌（29-34K）
• 糟糕的设计选择放大了权衡

代码技能：经典权衡

• 来自迭代开发的中等API调用（6-8）
• 由于代码冗长，每次调用的上下文适中（18-20K）
• 传统折衷方案

UTCP代码模式：意外的反模式

• 尽管有代码生成声明，API调用次数仍很高（9-11）
• 每次调用的高令牌（20-22K）来自代码+工具开销
• 额外的抽象层加剧了权衡

MCP代理：时间依赖的权衡

• 会话1：高令牌（154K），高调用（8）-发现开销
• 会话2+：中等令牌（81K），中等调用（5-6）-优化
• 权衡随着使用而改善

决策规则：

IF context_budget_critical AND api_latency_acceptable:
    → MCP Optimized (minimizes both)

IF api_calls_must_minimize AND context_abundant:
    → Still MCP Optimized (parallel execution wins)

IF budget_constrained AND high_variance_tolerable:
    → Code-Skill (moderate both, high flexibility)

IF large_tool_catalog AND repeated_usage:
    → MCP Proxy (amortizes discovery cost)

NEVER:
    → MCP Vanilla (loses on both dimensions)
    → UTCP Code-Mode (for data tasks)

定量阈值：

4.3维度2：方差公差

定义： 针对相同任务的会话之间的令牌消耗和API调用的可接受变化

差异来源：

1. 解决方案路径多样性 （代码生成方法）
2. 调试迭代 （试错执行）
3. LLM采样变化 （温度，非确定性）
4. 工具选择的不确定性 （多个有效序列）

实测方差（变异系数）：

*MCP代理：仅会话2-3：CV=0.5%（预热后表现良好）

差异对生产系统的影响：

低方差系统（CV<5%）：

• 可预测成本： 准确的预算预测
• 一致的延迟： 可靠的SLA合规性
• 稳定监测： 异常检测效果良好
• 容量规划： 确定性资源分配

高方差系统（CV>15%）：

• 成本不确定性： 20-40%的预算差异
• 延迟不可预测性： P99延迟2-3x P50
• 监测挑战： 正态方差掩盖了实际问题
• 过度配置： 必须为最坏的情况做好计划

权衡分析：

MCP优化：设计确定性

• 为什么方差低： 固定工具顺序，无调试迭代
• 权衡： 需要预先定义工作流
• 可接受时： 生产系统、SLA驱动的应用程序
• 成本： 对新要求不灵活

代码技能：本质上是非确定性的

• 为什么差异大： 不同的代码解决方案，不同的调试路径
• 权衡： 最大的灵活性，不可预测的成本
• 可接受时： 探索性工作、研究、原型制作
• 好处： 无需修改即可处理新任务

MCP代理：方差随时间收敛

• 为什么初始方差： 工具发现探索
• 为什么最终一致性： 缓存的工具知识
• 权衡： 必须容忍初始不稳定
• 可接受时： 具有预热期的长时间运行系统

决策矩阵：

定量阈值：

IF p99_latency_sla_required OR cost_budget_strict:
    variance_tolerance = LOW
    → MCP Optimized ONLY

IF exploratory_task OR prototype_phase:
    variance_tolerance = HIGH
    → Code-Skill acceptable

IF production BUT budget_flexible:
    variance_tolerance = MEDIUM
    → MCP Proxy (after warm-up)

IF sla_critical AND novel_requirements:
    → CONFLICT: Cannot satisfy both
    → Recommendation: Code-Skill prototype → MCP Optimized migration

4.4维度3：重复性（一次性与生产）

定义： 这个任务将被执行多少次？

经济模型：

Total_Cost = Development_Cost + (Per_Execution_Cost × Execution_Count)

Where:
  Development_Cost = Time to implement approach
  Per_Execution_Cost = Token cost per execution
  Execution_Count = Number of times task runs

方法经济学：

盈亏平衡分析：

MCP优化与代码技能：

Development_Cost = $2,500 (1 week engineer time)
Savings_Per_Execution = $0.44 - $0.21 = $0.23

Break_Even = $2,500 / $0.23 = 11 executions

At 100 executions:
  Total savings = $0.23 × 100 = $23
  ROI = $23 / $2.5 = 920%

At 1,000 executions:
  Total savings = $0.23 × 1,000 = $230
  ROI = $230 / $2.5 = 9,200%

MCP代理与代码技能：

Development_Cost = $1,000 (3 days engineer time)
Savings_Per_Execution = $0.44 - $0.35 = $0.09

Break_Even = $1,000 / $0.09 = 11 executions

At 100 executions:
  Total savings = $9
  ROI = 900%

可重复性决策框架：

时间范围考虑因素：

一次性任务（1-5次执行）：

• 针对以下方面进行优化： 第一个结果的速度
• 接受： 每次执行成本高，差异大
• 选择： 代码技能
• 例子： 季度董事会演示，一次性数据迁移

重复任务（20-100次执行）：

• 针对以下方面进行优化： 总体拥有成本
• 接受： 前期开发时间
• 选择： MCP优化或MCP代理
• 例子： 每周销售报告、每月分析仪表板

生产工作流程（100+次执行）：

• 针对以下方面进行优化： 执行效率、可靠性
• 接受： 重大发展投资
• 选择： MCP优化（始终）
• 例子： 实时数据处理、自动化报告系统

不确定重复性的混合策略：

Phase 1: Use Code-Skill (executions 1-10)
  → Validate task, understand requirements
  → Total cost: ~$4.40

Phase 2: Decision point (after 10 executions)
  IF task_stabilized AND execution_count_forecast > 20:
      → Invest in MCP Optimized
      → Development: $2,500
      → Future savings: $0.23/execution
  ELSE:
      → Continue with Code-Skill
      → Re-evaluate at 50 executions

Phase 3: Monitor (ongoing)
  → Track actual execution count
  → Measure token cost trends
  → Migrate to MCP Optimized when break-even certain

权衡总结：

代码技能优化用于：

• ✅ 未知的可重复性（无前期投资）
• ✅ 快速变化的需求
• ✅ 需要立即取得成果
• ❌ 执行20次以上的死刑很差（昂贵）

MCP优化了以下方面：

• ✅ 高重复性（卓越的投资回报率）
• ✅ 稳定、定义明确的工作流程
• ✅ 生产系统
• ❌ 一次性亏损（投资浪费）

MCP代理针对以下方面进行优化：

• ✅ 中等可重复性（20-100次执行）
• ✅ 不断变化的工具要求
• ✅ 大型工具目录
• ❌ 一次性差或频率很高

4.5综合决策框架

多维优化：

使用此决策树根据您的约束选择最佳方法：

START

Q1: Is this a one-off task (< 5 executions)?
    YES → Code-Skill (end)
    NO → Continue to Q2

Q2: Is total token budget < 100K AND variance < 5% required?
    YES → MCP Optimized (end)
    NO → Continue to Q3

Q3: Do you have > 20 tools AND task repeats > 50 times?
    YES → MCP Proxy (end)
    NO → Continue to Q4

Q4: Is execution count > 20 AND requirements stable?
    YES → MCP Optimized (end)
    NO → Continue to Q5

Q5: Is high variance acceptable (CV > 15%)?
    YES → Code-Skill (end)
    NO → MCP Optimized (end, invest in stability)

NEVER CHOOSE:
  - MCP Vanilla (always suboptimal)
  - UTCP Code-Mode (for data analysis tasks)

权衡可视化：

                    Context Efficient
                           ▲
                           │
                           │  MCP Optimized
                           │     ●
                           │   /   \
                           │  /     \
                           │ /       \
    High Variance ◄────────┼─────────► Low Variance
    (Flexible)             │           (Predictable)
                           │    ●
                           │  Code-Skill
                           │     \
                           │      \
                           │   ●   ● MCP Proxy
                           │  UTCP  (post-warmup)
                           │   \
                           │    ● MCP Vanilla
                           ▼
                    Many API Calls

帕累托前沿：

只有三种方法处于帕累托前沿（并非在所有维度上都占主导地位）：

1. MCP优化： 最佳上下文效率、最佳一致性、最佳可重复性
2. MCP代理： 预热后效率高，适用于大型工具组
3. 代码技能： 最佳灵活性、零开发成本、一次性最佳

主导方法（从未达到最优）：

• MCP香草： 以MCP为主导，全方位优化
• UTCP代码模式： 以代码技能为主（成本更低，灵活性相似）

5.结论

5.1主要发现

1. 架构比协议更重要

   • 文件路径方法（60K令牌）与数据传递（309K令牌）=5倍差异
   • 协议选择（MCP与UTCP）比架构设计影响更小
   • 结论：关注数据流设计，而不是协议选择

2. 并行化未得到充分利用

   • MCP Optimized通过并行执行实现了4倍的延迟减少
   • 仅适用于独立的基于文件的工具
   • 在生产系统中具有显著的竞争优势

3. 渐进式发现显示出希望

   • 预热期后代币减少47%
   • 适用于大型工具目录
   • 需要会话持久性才能有效

4. 数据任务的UTCP代码模式性能不佳

   • 比基线差40-68%（与声称相反）
   • 可能擅长不同领域（需要进一步研究）
   • 不建议用于数据分析工作流

5. 可扩展性特征是非线性的

   • 文件路径方法：亚线性缩放（从20到1.5倍→500 rows)
   • 数据传递方法：超线性缩放（从20到2.9倍→500 rows)
   • 生产部署的关键考虑因素

5.2生产准备

5.3影响评估

对于个人开发者：

• 节省时间： 30-50%来自并行执行
• 降低成本： 200-500美元/年的代币成本
• 学习曲线： 2-4周熟悉工具

对于团队（10名工程师）：

• 成本节约： 2000-5000美元/年
• 速度提升： 调试减少15-25%
• 基础设施投资： 10000-20000美元（工具开发）
• 投资回报时间线： 3-6个月

对于组织（100多名工程师）：

• 成本节约： 50000-100000美元/年
• 竞争优势： 更快的功能交付
• 平台机会： 内部工具市场
• 战略价值： 差异化人工智能能力

5.4最终建议

第1级（最高优先级）：

1. 立即： 部署MCP针对前5个常见操作进行了优化
2. 第1个月： 衡量代币减少和投资回报率
3. 第2个月： 扩展到前20名业务

第2级（中等优先级）：

1. 第3个月： 用于大型工具目录的Pilot MCP代理
2. 第4个月： 开发混合路由逻辑
3. 第6个月： 全混合架构部署

第3级（研究）：

1. 不间断的： 监控UTCP协议的发展
2. 问题2： 重新评估UTCP的工作流编排
3. 问题3： 跨模型验证研究

附录

A.实验元数据

数据集特征：

• 行数：500
• 列：6（姓名、部门、工资、工作年限、业绩、地点）
• 大小：~45KB CSV
• 分布：具有经验相关性的现实薪酬范围

环境：

• 型号：翻盖式连接器-4-5-20250929
• 接口：克劳德代码CLI v2.0.42
• 操作系统：macOS（Darwin 24.6.0）
• Node.js：v24.4.1
• 网络：使用自定义日志记录

会议： 每种方法3个（共15个） 数据收集期： 2025年11月 分析工具： Python（matplotlib、pandas）、Node.js

B.存储库结构

tool-metrics/
├── experiments/data-analysis/
│   ├── code-skill-approach/
│   ├── mcp-approach/
│   ├── mcp-approach-optimized/
│   ├── mcp-proxy-approach/
│   ├── otcp-code-approach/
│   └── shared/sample-data.csv
├── raw-data/experiments/        # Network logs with PII
├── data/experiments/             # Cleaned JSONL data
├── visualizations/               # Comparative charts
├── clean-data.js                 # PII redaction pipeline
├── sessions-comparison.js        # Within-approach analysis
├── approaches-comparison.js      # Cross-approach analysis
└── README.md

C.工具和协议参考

协议和框架：

1. 模型上下文协议（MCP）

   • 官方规范：https://modelcontextprotocol.io/
   • 描述：用于将AI模型连接到外部工具和数据源的协议
   • 用于：MCP香草、MCP优化、MCP代理方法

2. 通用工具调用协议（UTCP）-代码模式

   • 存储库：https://github.com/universal-tool-calling-protocol/code-mode
   • 描述：允许编写在单次执行中调用MCP工具的TypeScript代码
   • 声明：速度快60%，令牌少68%，API调用少88%
   • 用于：UTCP代码模式方法
   • 注： 本研究中未验证数据分析任务的声明

3. 一个mcp（mcp代理）

   • 存储库：https://github.com/AgiFlow/aicode-toolkit/blob/main/packages/one-mcp
   • 描述：智能MCP代理提供渐进式工具发现
   • 功能：最初加载2个元工具（~400个令牌），而不是预先加载所有工具（~10000+个令牌）
   • 减少：90%+初始管理费用
   • 用于：MCP代理方法

克劳德代码：

• 官方网站：https://code.claude.com/
• CLI存储库：https://github.com/anthropics/claude-code
• 使用的版本：v2.0.42
• 说明：Claude AI助手的官方CLI

分析工具：

• Python：matplotlib、pandas、numpy用于可视化
• Node.js：网络检测和数据处理
• API克劳德：https://docs.anthropic.com/en/api

D.再现性

要重现结果：

1. 克隆存储库并安装依赖项
2. 使用API键设置Claude Code CLI
3. 配置MCP服务器（请参阅特定方法的自述文件）
4. 运行实验： node run-experiment.js data-analysis <approach> <session-name>
5. 干净数据： node clean-data.js
6. 生成可视化： node sessions-comparison.js && node approaches-comparison.js

工具设置：

• UTCP桥： npm install -g @utcp/mcp-bridge （有关配置，请参阅存储库）
• 一个mcp： npm install -g @agiflowai/one-mcp （参见mcp-config.yaml的存储库）
• 自定义MCP服务器： 每个方法目录中的Node.js实现

数据可用性：

• 已清理数据（PII已编辑）：已发布在存储库中
• 原始日志：未发布（包含PII）
• 可视化代码：开源

E.致谢

本研究旨在深化对人工智能辅助开发中令牌效率的理解。结果被公开分享，以造福更广泛的工程界。

工具确认：

• Anthropic 用于克劳德代码和MCP规范
• 通用工具调用协议团队 用于UTCP码模式网桥
• AgiFlow 对于一个mcp渐进式发现代理

F.版本历史

• v1.0 （2025年11月）：首次发表5种方法，500行数据集

作者 人工智能系统研究首席工程师 联系人： [为保护隐私而修改] 许可证： 麻省理工学院-见 许可证 详细信息文件