Claude 中断对 Trae 供应，背后的损失到底是谁更大？

（谁的损失最大呢？

其实，不能简单说是谁亏了，而是Claude正在布局一个更大的战略。

一开始Cursor就像是粘合剂，但现在Cursor2.0已经有了自己的编程模型。

不过，这也不是能立即见效的事，毕竟在编程AI的江湖里，最强的还是GPT和Claude这对双雄。

TRAE虽然不如Cursor，但因为有Claude和GPT的加持，也能分得一杯羹。

这还是在Claude Code和GPT5-Codex未推出的时候。

但是现在，随着Claude Code和GPT5-Codex的登场，AI编程就像是用原生大模型去干掉那些外壳包裹的编程工具。

目前GPT因为资金问题还不会停止供应，只要它能继续保持领先并赚得更多，GPT和Gemini也可能会断供。

不仅仅是Claude在行动，GPT也想独占鳌头。

Claude去除了地域限制，最大的优势是它有自己的底气，不再需要依赖其他编程产品来推广。

全靠自己就能行。

AI编程中最大的挑战就是Tokens的成本太高。

无论怎样的AI编程，都逃不出这个高昂的Tokens费用。

我从Claude的角度来看，Claude在11月份已经有了新的突破，Claude Code的效率提升显著，从150K Tokens直接降到2K Tokens完成同样的工作。

这个成本降低了整整98%！！！

前几天看到Anthropic发布的新技术指南，老实说，看完我只剩沉默。

150,000个Tokens一下减少到2,000，这简直不是优化，而是降维打击！

这比Deepseek的3.2大幅降价还要震撼……

既然自己也能做到，为什么还要为他人做嫁衣呢？

我直言不讳，这可能是我在2025年看到的最牛的AI代理优化方案。

如实告诉你们，我之前做的多工具代理项目，API账单让我心惊——一个月要$360,000，这谁能承受得住？

现在Anthropic直接把这个费用砍到$4,800，节省了98.7%的成本。

而且，响应时间也从20秒减少到5.5秒。

传统方法把AI模型当成数据中转站，所有中间数据都要经过模型，这简直是自寻死路！

这次Anthropic直接把数据处理放在执行环境中，模型只负责生成代码和接收结果，决策层和执行层彻底分开了。

看完这篇文章后，我总结出了三个最牛的点：

1. 环境内处理 – 中间数据根本不进模型，Tokens节省超过99%
2. MCP代码API化 – 代理变成了程序员，想要什么工具自己引入
3. 真金白银验证 – 不再是纸上谈兵，生产环境每月节省$355,200

搞过多工具代理的朋友都知道，当前的问题根本不是优化能解决的，而是架构性bug。

想要功能全，就得接一大堆工具；想要节省Token，就只能削减功能。

这不是简单的两难选择，而是进入了死循环。

说实话，企业级代理没有50到200个工具根本无法运作。

数据库查询、发邮件、对接Salesforce、Slack协作、GitHub集成，这些都是基本配置。

我之前的项目，光工具接入就花了两个月的时间。

更棘手的是调用频次。

一个复杂的工作流动不动就得调用10到30次工具，链式依赖的感觉真是酸爽——工具A的输出给工具B，B的结果再给C，每次数据都要在上下文中转一圈。

传统架构没法并行，只能乖乖地串行运行，眼睁睁地看着延迟堆积。

调用次数与成本的关系：

任务复杂度	调用次数	数据量	Token消耗
简单任务	3-5次	<1KB	2K-5K
中等任务	10-15次	10-50KB	20K-50K
复杂任务	20-50次	100-500KB	100K-500K

MCP (模型上下文协议)的出现无疑是个好消息，统一了工具接入的标准。

以前每个服务都得搞独立的SDK、认证和数据格式，现在用JSON Schema来定义工具签名，list_tools() API自动发现工具，节省了不少麻烦。

但是！

MCP虽然解决了接口碎片化的问题，理论上想接多少工具都可以，但实际上还是被上下文窗口限制得死死的。

比如说，有个项目需要从10万条记录中筛选出5条生成报告。

传统方式的流程简直是个天坑：

阶段1 – 工具定义预加载：

• 50个工具定义全塞进上下文里
• 还没开始工作，5,000 tokens就没了
• 我当时就觉得不对劲

阶段2 – 数据检索（这是最大的问题）：

• 代理调用database.query()
• 100,000条记录 → 全部进上下文
• Token消耗：100,000条 × 50 tokens = 5,000,000 tokens
• 延迟：序列化、传输、解析，15秒跑不掉
• 问题是：10万条里99,995条都是垃圾数据，全都进上下文了

阶段3 – 数据过滤：

• 调用filter()工具
• 再传一遍10万条（没错，又传一遍）
• 最终返回5条结果

阶段4 – 生成报告：

• 终于只传5条了
• 但前面已经炸了

总账单：

• Token：5,006,000（约500万）
• 往返：3次
• 延迟：20秒
• 最搞笑的是：10万条数据走了一圈，真正有用的只有5条

流程为：

这说明了什么呢？

传统架构把AI模型当成数据总线，所有的数据都得经过模型这一关。

模型不仅要做决策，还要当搬运工，Token消耗和数据量成正比，这能不出问题吗？

工具定义预加载就是第一个大坑。代理一启动就要把所有工具定义塞进去：功能描述、参数说明（类型、必填、默认值、验证规则）、返回格式、2到3个使用示例。

50个工具算下来：50 × 100 tokens = 5,000 tokens的基础开销。但规模效应是最令人头疼的：

200个工具直接就得20,000 tokens起步。

更搞笑的是工具的利用率。

统计下来，单次任务平均用到的工具只有3到5个，利用率仅有2.5%。

也就是说97.5%的工具定义tokens完全是浪费。

为什么不能按需加载呢？

因为传统架构要求预先声明所有工具，模型必须“看到”所有选项才能做选择。

中间结果传递，数据重复传输的天坑。

Salesforce的真实案例：

# 传统方式 - 三次独立工具调用（每次都是煎熬）

# 第一次：搜索
search_result = agent.call_tool("search_salesforce", {
    "query": "active accounts",
    "fields": ["name", "revenue", "status"]
})
# 1000条记录，20,000 tokens，心在滴血

# 第二次：过滤
filtered = agent.call_tool("filter_records", {
    "data": search_result,  # 20K tokens的数据又传一遍
    "condition": "revenue > 1000000"
})
# 过滤完50条，2,500 tokens

# 第三次：汇总
summary = agent.call_tool("create_summary", {
    "data": filtered  # 又传一遍
})
# 终于完事了，500 tokens

# 工具定义：5,000
# 第一次搜索：20,000
# 传给filter：20,000（重复传输！）
# 过滤结果：2,500
# 传给summary：2,500（又重复！）
# 最终结果：500
# 总计：51,000 tokens，每次看到这个数字我都想哭

每次往返耗时500ms，三次加起来1.5秒光在网络上耗费。

数据序列化还有隐性成本。

原始1KB数据转换为JSON时会膨胀到1.5-2KB，膨胀比例1.5-2倍。

模型还得花时间去理解JSON结构。

Anthropic的解决方案很简单：不优化，直接换架构。代理不再是工具的使用者，而是代码的编写者。MCP服务器不再作为函数调用接口，而是作为代码模块。

核心理念听起来简单，实施起来却很复杂：模型不执行工具，而是生成执行工具的代码。

代码在独立环境中运行，数据处理全在环境内完成，模型只负责接收最终结果。

MCP服务器重构为代码API，从函数调用变为模块导入（这个变化至关重要）。

// 传统方式（每次调用都是灾难）
agent.call_tool("search", {query: "..."})

// 代码执行方式（简洁清爽）
import { search } from 'mcp-server'

技术实现（支持TypeScript和Python双平台）！

TypeScript版本：

// mcp-servers/salesforce/index.ts
export class SalesforceClient {
  async search(params: SearchParams): Promise {
    // 这里的实现全在执行环境，模型根本不知道
    const results = await this.api.query(params);
    return results;
  }
  
  async update(id: string, data: object): Promise {
    // 所有操作都在环境内，秒啊
    return await this.api.update(id, data);
  }
}

Python版本：

提升开发体验的秘密武器

说到类型提示，真的是个好东西！它让IDE自动补全、类型检查和文档悬停功能变得轻而易举，开发的感觉简直飞起来了。同时，async/await的原生支持也让并发性能上升不少。

懒加载机制也是个省Token的好办法！

传统的做法是预加载50个工具，结果消耗5K tokens；而现在只需导入2个工具，就能实现0 tokens的消耗。

你可能会问，为啥是0呢？

因为导入语句并不会占用模型的上下文！

动态导入的实现方式：

// 运行时按需导入，想用啥导啥
const toolName = determineRequiredTool(task);
const module = await import(`mcp-servers/${toolName}`);
const tool = new module.Client();

工具发现API（search_tools）的设计真是聪明！

async function search_tools(query: string): Promise {
  // 轻量级元数据，每个工具 
    tool.tags.includes(query) || 
    tool.description.includes(query)
  );
  
  // 按相关性和流行度排序
  return matches.sort(byRelevance).map(t => ({ 
    name: t.name, 
    summary: t.summary 
  }));
}

元数据索引在启动时只需构建一次，后面查询的响应时间小于10ms。利用倒排索引和内存缓存的组合，性能真是拉满。

举个例子：

1. Agent想要“发邮件”；
2. 调用search_tools("email")，返回3个邮件工具（150 tokens）；
3. Agent选择了“Gmail Sender”；
4. import { GmailSender } from 'mcp-servers/gmail'；
5. 只加载了这个工具，其它197个完全没影响。

工具选择的逻辑主要是基于描述的匹配度、历史使用频率和上下文的相关性。

这时候，Agent变成了码农，模型的角色从“执行者”转变为“编排者”。它生成代码，但并不直接执行工具调用，这就需要保证代码的质量：

• 使用ESLint和Pylint自动检查语法；
• TypeScript和Python的类型系统来做类型校验；
• 复用代码模板库中的最佳实践。

这些模板库能有效减少生成错误，比如数据库查询的标准模板和API调用的重试模板，都是经过验证的。

数据处理还是在环境内部进行，确保数据不出环境。

执行环境的安全隔离至关重要！

安全第一，架构设计包括：沙箱 + 资源限制 + 实时监控。

沙箱技术（结合Docker和seccomp的多层防护）

• 网络隔离：只能访问MCP服务器，其他外部连接全都禁止；
• 文件系统隔离：代码库是只读的，只有/tmp可以写，防止破坏；
• 进程隔离：独立容器，进程之间完全隔离。

资源配额（写死的规则）

• CPU：2核；
• 内存：4GB；
• 执行

超时后会用SIGALRM信号强制终止，如果内存溢出则会通过cgroup限制来保护宿主机。

核心技术在于数据流的重定向！

Salesforce案例的改写（对比效果太明显了）

// Agent写的代码 - 单个函数搞定所有事
import { salesforce } from 'mcp-servers';

async function getSalesforceSummary() {
  // 阶段1：数据检索（在环境内，模型根本不知道）
  const results = await salesforce.search({
    query: "active accounts",
    fields: ["name", "revenue", "status"]
  });
  // 1000条记录在环境内存里
  // 关键：模型完全不知道这1000条的存在
  
  // 阶段2：过滤（原生JS，环境内操作）
  const filtered = results.filter(record => 
    record.revenue > 1000000
  );
  // 50条结果，还是在环境内
  // 模型依然不知道
  
  // 阶段3：聚合计算（原生reduce和sort）
  const summary = {
    total_accounts: filtered.length,  // 数量统计
    total_revenue: filtered.reduce((sum, r) => 
      sum + r.revenue, 0),  // 收入求和
    top_account: filtered.sort((a, b) => 
      b.revenue - a.revenue)[0]  // 排序取TOP1
  };
  
  // 阶段4：返回结果（只有这个小对象给模型）
  return summary;
  // 模型收到的就是：
  // { total_accounts: 50, total_revenue: 150000000, top_account: {...} }
}

// Token消耗：约100（就这个summary对象）

数据流向图：

数据库 → 执行环境内存(1000条，模型不可见)
       ↓ filter操作
       执行环境内存(50条，模型不可见)
       ↓ 计算聚合
       执行环境内存(summary对象)
       ↓ return
       模型上下文(仅summary，~100 tokens)

执行耗时：

• 数据库查询：2秒；
• 环境内过滤：0.05秒；
• 环境内聚合：0.05秒；
• 总计：2.1秒。

Token节省的效果显著：1000条信息从未序列化，50条从未传输，只有summary返回。这样节省了从51K到100，节省率高达99.8%。

中间数据的内存管理也很到位，100K条记录都在环境内存中，模型完全无感知。数据结构的选择尤为重要，JavaScript数组和Python列表的原生性能最好。

对于超大数据集，可以用Generator逐条处理，避免一次性加载：

function* processLargeDataset(data) {
  for (let item of data) {
    yield transformItem(item);  // 逐条处理，省内存
  }
}

实时监控内存情况：

const memUsage = process.memoryUsage();
if (memUsage.heapUsed > threshold) {
  // 内存快爆了，切换流式处理
}

将50次调用合并成1次（这个优化真是厉害）

// 传统：50次工具调用 = 50次往返 = 25秒等死

// 代码执行：一个循环搞定
const results = [];
for (let i = 0; i < 50; i++) {
  const result = await processItem(items[i]);
  results.push(result);
}
// 总

进阶并发版本：

// 50个并发请求，0.5秒搞定
const results = await Promise.all(
  items.map(item => processItem(item))
);

并发控制能有效防止服务器崩溃：

import pLimit from 'p-limit';
const limit = pLimit(10);  // 最多10并发
const results = await Promise.all(
  items.map(item => limit(() => processItem(item)))
);

错误重试机制增强了容错能力：

async function retry(fn, times = 3) {
  for (let i = 0; i < times; i++) {
    try { 
      return await fn(); 
    } catch (e) { 
      if (i === times-1) throw e;
      await sleep(1000 * (i + 1));  // 指数退避，别立即重试
    }
  }
}

效果对比：真实的数据表现：

Token节省率的计算：

延迟的改进：

Claude的这手操作，真的是优势多多！

自己能搞定的事情，再也不用指望别人来帮忙了……

1. Token效率提升：成本直降

不同规模的真实成本对比，这个表格能让多少老板心疼啊！

实施成本大概就是这样：

• 环境搭建：$50K（一次性费用）；
• 月维护费用：$5K。

中规模回本时间约为：$50K ÷ $355K = 0.14月，也就是大概3.6天。

3年总拥有成本对比（传统方式与代码执行）：

传统方式：$360K × 36 = $12.96M
代码执行：$50K + ($4.8K + $5K) × 36 = $402.8K

3年节省：$12.96M – $403K = $12.56M，节省率高达96.9%！

2. 渐进式工具发现：不再需要预加载

search_tools的完整实现，这个API设计真的是精妙绝伦！

// 元数据索引结构
interface ToolMetadata {
  name: string;           // 工具名
  category: string;       // 分类
  tags: string[];         // 标签
  description: string;    // 描述
  summary: string;        // 摘要 <50 tokens
  popularity: number;     // 使用频率
}

// search_tools实现
async function search_tools(query: string): Promise {
  // 1. 加载轻量级索引
  const allTools: ToolMetadata[] = await loadToolMetadata();
  // 200工具 × 50 tokens = 10K tokens（只加载一次）
  
  // 2. 关键词匹配
  const keywordMatches = allTools.filter(tool => 
    tool.tags.some(tag => tag.includes(query.toLowerCase())) ||
    tool.description.toLowerCase().includes(query.toLowerCase())
  );
  
  // 3. TF-IDF相关性
  const scored = keywordMatches.map(tool => ({
    tool,
    score: calculateRelevance(tool, query)
  }));
  
  // 4. 排序：相关性70% + 流行度30%
  const sorted = scored.sort((a, b) => 
    (a.score * 0.7 + a.tool.popularity * 0.3) - 
    (b.score * 0.7 + b.tool.popularity * 0.3)
  );
  
  // 5. 返回TOP10
  return sorted.slice(0, 10).map(s => s.tool);
}

// 相关性计算
function calculateRelevance(tool: ToolMetadata, query: string): number {
  const words = query.toLowerCase().split(' ');
  let score = 0;
  
  for (const word of words) {
    if (tool.name.toLowerCase().includes(word)) score += 10;  // 名字匹配权重最高
    if (tool.summary.toLowerCase().includes(word)) score += 5;
    if (tool.tags.some(t => t.includes(word))) score += 3;
  }
  
  return score;
}

启动时构建倒排索引，查询响应时间小于10ms：

// 启动构建倒排索引
const invertedIndex = new Map<string, Set>();

for (const tool of allTools) {
  const words = [...tool.tags, ...tool.description.split(' ')];
  for (const word of words) {
    if (!invertedIndex.has(word)) {
      invertedIndex.set(word, new Set());
    }
    invertedIndex.get(word).add(tool.name);
  }
}

// 查询O(1)复杂度，贼快
function fastSearch(query: string): string[] {
  const words = query.split(' ');
  let results = invertedIndex.get(words[0]) || new Set();
  
  for (let i = 1; i  wordResults.has(x)));
  }
  
  return Array.from(results);
}

Token对比（这个节省真是夸张）：

• 传统方式：预加载200个工具，消耗20K tokens；
• search_tools：返回3个匹配工具，仅需150 tokens；
• 动态导入：import语句消耗为0 tokens；
• 总节省：99.25%。

3. 大数据处理：再也不怕数据量了

性能曲线对比，数据量越大，优势越明显！

性能的拐点在于100行。

小于50行用传统方式会更简单，但超过100行，代码执行绝对胜出。

动态策略的选择：

async function processData(dataSource) {
  const estimatedSize = await estimateDataSize(dataSource);
  
  if (estimatedSize < 50) {
    return await traditionalApproach(dataSource);  // 小数据集，传统够用
  } else {
    return await codeExecutionApproach(dataSource);  // 大数据集，代码执行起飞
  }
}

数据管道的构建：

// 链式操作，内存峰值低
const pipeline = data
  .filter(cleanData)           // 清洗
  .map(transformFormat)        // 转换
  .reduce(aggregateByGroup)    // 聚合
  .map(calculateMetrics);      // 计算

// 流式处理超大数据
async function* streamProcess(dataSource) {
  for await (const batch of dataSource.batches(1000)) {
    const processed = batch
      .filter(validate)
      .map(transform);
    yield processed;  // 逐批处理，内存可控
  }
}

处理100K行数据时，内存峰值只需500MB，而非全量加载的5GB。

除此之外，还有编程控制流，循环、条件和错误处理都是原生支持，50次调用变成1次执行，延迟降低了整整25倍；隐私安全，敏感数据不进模型，GDPR和HIPAA合规也没问题；状态持久化，检查点机制，长时间任务可以跨会话运行，3小时的任务可分为3次完成；技能生态SKILL.MD文档化，能力可复用，团队效率提升3到5倍等等……