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 Agent 优化方案。

坦白讲，之前我参与的多工具 Agent 项目，API 账单看得我心惊胆战——一个月竟花费 $360,000，这谁能承担得起？

而现在，Anthropic 直接将成本压至 $4,800，节省了 98.7% 的费用。

这还不算完，响应时间也从 20 秒缩短至 5.5 秒。

传统方法将 AI 模型视为数据的中转站，所有中间数据都需经过模型，这不是自毁前程吗？

Anthropic 这次将数据处理直接丢入执行环境，模型只负责生成代码和接收结果，实现了决策层与执行层的彻底分离。

读后，我总结出三个最具突破性的要点：

1. 环境内处理 – 中间数据不进入模型，Tokens 节省超过 99%
2. MCP 代码 API 化 – Agent 变成程序员，所需工具自行导入
3. 真实验证成果 – 不是纸上谈兵，生产环境每月节省 $355,200

参与过多工具 Agent 开发的人都知道，现阶段的问题并非简单的优化，而是 架构性缺陷。

若想实现全面功能，就不得不整合一堆工具；想节省 Tokens，功能则必然受限。

这不是两难选择，而是一种死循环。

说实话，企业级 Agent 若没有 50 到 200 个工具根本无法运转。

数据库查询、发送邮件、对接 Salesforce、Slack 协作、GitHub 集成，这些都是必不可少的组件。

我之前的项目，仅工具接入就花费了两个月。

更棘手的是调用频率。

一个复杂的工作流可能需要 10 至 30 次工具调用，链式依赖 的复杂性令人头痛——工具 A 的输出作为工具 B 的输入，B 的输出又要传递给 C，每次数据都要在上下文中循环。

传统架构无法并行处理，只能顺序执行，致使延迟不断增加。

调用次数与成本之间的关系如下：

MCP（Model Context Protocol）协议的推出无疑是个好消息，它统一了工具接入的标准。

以前每个服务都需要独立的 SDK、认证和数据格式，而现在只需用 JSON Schema 定义工具签名，list_tools() API 可自动发现工具，节省了大量时间。

但是！

虽然 MCP 解决了接口碎片化的问题，理论上可以接入任意数量的工具，但实际上仍然受到上下文窗口的限制。

例如，处理一个项目时需要从 10 万条记录中筛选出 5 条生成报告。

传统流程的沉重负担：

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

• 50 个工具定义全部塞入上下文
• 尚未开始工作，就消耗了 5,000 tokens
• 当时我就觉得不对劲

阶段 2 – 数据检索（这里是重灾区）：

• Agent 调用 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 消耗与数据量成正比，这能不崩溃吗？

工具定义的预加载是第一个大坑。Agent 一启动就必须将所有工具定义传入：功能描述、参数说明（类型、必填项、默认值、验证规则）、返回格式、2- 3 个使用示例。

50 个工具的开销计算：50 × 100 tokens = 5,000 tokens 的基础费用。但规模效应是最令人厌恶的：

200 个工具的 Token 消耗直接从 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 的解决方案可以简述为一句话：不再优化，直接重构架构。Agent 不再是工具的使用者，而是代码的创作者。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 限制，OOM killer 保护宿主机。

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

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 倍等等……