DEV Community: addtoken

为什么 AI Agent 都离不开 Workflow？看懂现代 AI 应用的底层设计

addtoken — Wed, 15 Jul 2026 16:25:45 +0000

博客 / 为什么 AI Agent 都离不开 Workflow？看懂现代 AI 应用的底层设计

为什么 AI Agent 都离不开 Workflow？本文从 Prompt、Workflow 到 Agent 的演进过程，结合 LangGraph、n8n 等主流方案，讲清现代 AI 工作流设计思路，并通过代码示例理解 Agent 的运行机制。

阅读约 12 分钟｜适合希望系统理解 AI Agent、Workflow 与 LangGraph 的开发者。

一、Prompt 和 Workflow 的根本区别

让 AI 总结一篇文章，效果不错，然后想能不能先抓网页、再总结、再翻译、再发邮件？你把所有要求塞进一个 prompt 里，让它一次干完。结果它忘了翻译，邮件格式也错了。你以为这是 prompt 没写好，其实是结构性问题。你需要的不是 prompt，而是一个 workflow。 这篇讲清楚 prompt 和 workflow 的区别，以及怎么设计一个真正能跑起来的 AI Agent 工作流。

Prompt 是一次对话。 你说一句，AI 回一句。

Workflow 是多次对话的组合。 把一个复杂任务拆成几个步骤，每步用一个 prompt，前一步的输出当后一步的输入，串成一条流水线。

举个最简单的例子：如果把一篇英文文章翻译成中文，利用prompt一次性能搞定。如果每天抓 10 个英文科技博客的新文章，翻译成中文，提取关键词，按主题分类，生成摘要，发到飞书群。这就不是一句 prompt 能解决的了。你需要：

1. 抓文章（脚本） 2. 翻译（AI） 3. 提关键词（AI） 4. 分类（AI） 5. 生成摘要（AI） 6. 发飞书（脚本）

每一步都是一个独立任务，有自己的输入输出。这就是 workflow。

判断标准很简单：

- 任务一步就能完成 → Prompt - 任务需要多步，每步有明确的输入输出 → Workflow - 任务需要根据上一步结果决定下一步做什么 → Workflow（带条件分支）

二、Workflow 的四个核心组件

不管用什么工具（LangChain、Dify、n8n、Coze、自写代码），workflow 都由这四个组件构成：

1. 节点（Node）

一个节点干一件事。可以是调 AI，也可以是调脚本、查数据库、发请求。

每个节点有三个要素： - 输入：从哪拿数据 - 处理：干什么活 - 输出：给下一节点什么

2. 连接（Edge）

节点之间的数据流。A 的输出接到 B 的输入。

3. 条件（Condition）

根据上一步结果决定走哪条路。比如"如果摘要长度 > 200 字，走精简分支；否则走原文分支"。

4. 循环（Loop）

对一批数据重复执行同一段流程。比如"对 10 篇文章逐篇执行翻译+摘要"。

记住这四个，所有 workflow 工具都是它们的变体。

三、一个完整的 Workflow 示例

需求：每天早上 8 点，抓 3 个科技博客的最新文章，翻译成中文，生成摘要，按质量打分（1-5），高于 3 分的发飞书，低于的存档。

用文字画出来：

[定时触发] 
    ↓
[抓取文章] ← 脚本节点，不是 AI
    ↓
[循环: 对每篇文章执行 ↓]
    ├── [翻译] ← AI 节点
    ├── [生成摘要] ← AI 节点
    ├── [质量打分] ← AI 节点
    └── [条件判断]
         ├── 分数 > 3 → [发飞书]
         └── 分数 ≤ 3 → [存档]

如果用一个 prompt 做，会有什么问题？

- 不可靠。让 AI 一次干 5 件事，它经常漏掉一两件。 - 没法复用。改"打分标准"要重写整个 prompt；拆开的话只改打分节点就行。 - 没法调试。出错时不知道是翻译错了还是打分错了；拆开后每步都能单独测。 - 没法并行。3 篇文章拆成 3 条并行流水线，速度 3 倍；塞一个 prompt 里只能串行。

这是 workflow 最核心的价值：把不可靠的"全能 prompt"，拆成可靠的"专项节点"。

四、设计 Workflow 的 5 条原则

原则 1：能不用 AI 就不用 AI

不是所有节点都要调 AI。抓网页、发消息、查数据库、算数学——这些用脚本更快更准更便宜。

新手最常犯的错：什么都让 AI 干。让 AI 算订单总价、让 AI 拼 SQL、让 AI 格式化日期。这些确定性任务，脚本一行搞定，AI 反而容易出错。

判断标准：如果这个任务的输出有唯一正确答案，别用 AI。AI 适合"模糊的、需要理解的、有创造性的"任务。

原则 2：每个 AI 节点只干一件事

一个节点 = 一个职责。

差的设计：

[AI 节点: 翻译 + 摘要 + 打分 + 分类]

好的设计：

[AI 节点: 翻译] → [AI 节点: 摘要] → [AI 节点: 打分] → [AI 节点: 分类]

拆开后： - 每个节点的 prompt 更短更准 - 单独测试更容易 - 出错时能定位到具体节点 - 可以并行执行（翻译和打分可以同时跑）

原则 3：节点之间用结构化数据传递

节点之间的数据格式要明确。推荐用 JSON。

差的设计：让 AI 输出一段自然语言，下一个 AI 节点再去"理解"这段话。

好的设计：

// 翻译节点的输出
{
  "original_title": "GPT-5 Released",
  "translated_title": "GPT-5 发布",
  "content": "..."
}

下一个节点直接读 JSON 字段，不用"理解"。

配合 Function Calling 或 JSON Mode 使用效果最好。让 AI 强制输出 JSON，而不是自然语言里夹带 JSON。

原则 4：每个节点都要有"失败处理"

AI 会失败。超时、限流、输出格式错、内容被拦截。你的 workflow 必须能处理这些情况。

最简单的做法：每个 AI 节点配一个重试 + 兜底。

[AI 节点] 
  ├── 成功 → 继续
  ├── 失败 → 重试 3 次
  └── 3 次都失败 → 兜底（用默认值 / 跳过 / 报警）

不设计失败处理的 workflow，跑两次就崩。

原则 5：能并行就并行

串行慢，并行快。能同时跑的节点就别排队。

# 串行（慢）
[翻译] → [摘要] → [打分] → [分类]   总耗时 12 秒

# 并行（快）
[翻译] ──┬── [摘要] ──┐
         ├── [打分]  ──┼── [汇总]
         └── [分类]  ──┘            总耗时 5 秒

翻译完后，摘要、打分、分类三个节点互不依赖，可以同时跑。

不是所有节点都能并行——有依赖关系的必须串行。但只要没有依赖，就并行。

五、Workflow 工具怎么选

按使用门槛从低到高：

1. 可视化工具（Dify、Coze、FastGPT）

拖拽节点连线，不用写代码。适合非技术人员、快速验证想法。缺点是复杂逻辑难表达，被工具能力限制。

2. 自动化工具（n8n、Make、Zapier）

更偏"连接各种服务"。AI 只是其中一个节点类型。适合"AI + 现有系统"的集成场景。

3. 代码框架（LangChain、LangGraph、LlamaIndex）

写代码控制每一步。最灵活，但门槛最高。适合需要精细控制和长期维护的项目。

4. 自写代码

直接调 API，自己写流程控制。最简单直接，适合简单 workflow。不依赖框架，没有学习成本。

我的建议：从自写代码开始。想清楚后再上框架，别让框架替你想。

六、一个最小可跑的代码示例

用 Python + OpenAI SDK 写前面那个"翻译 + 摘要 + 打分"的 workflow，不到 50 行：

from openai import OpenAI
import json

client = OpenAI(
    base_url="https://api.example.com/v1",
    api_key="sk-xxx",
)

def call_llm(system, user, model="gpt-4o-mini"):
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": system},
            {"role": "user", "content": user},
        ],
        response_format={"type": "json_object"},
    )
    return json.loads(resp.choices[0].message.content)

def translate(text):
    return call_llm(
        "你是翻译。把英文翻译成中文。返回 JSON：{translated: string}",
        text,
    )["translated"]

def summarize(text):
    return call_llm(
        "你是摘要生成器。生成 100 字以内的摘要。返回 JSON：{summary: string}",
        text,
    )["summary"]

def score(text):
    return call_llm(
        "你是内容评审。给文章打 1-5 分。返回 JSON：{score: int}",
        text,
    )["score"]

def workflow(article):
    translated = translate(article)        # 翻译
    summary = summarize(translated)        # 摘要
    score_val = score(translated)          # 打分

    if score_val > 3:
        send_to_feishu(summary)            # 发飞书
    else:
        archive(summary)                   # 存档

workflow("OpenAI just released GPT-5...")

每一步是独立函数，输入输出清晰，单独可测。改"打分标准"只动 score 函数，其他不受影响。

这就是 workflow 的本质：把大任务拆成小函数，每个函数干一件事，串起来。

本文示例使用 Token 补给站（https://addtoken.top）进行测试。平台提供 OpenAI 与 Anthropic 兼容 API，保持与官方协议一致，跑这个 workflow 时可以随时切换底层模型，方便对比 GPT、Claude、DeepSeek 在每个节点上的表现差异。

七、Workflow 的常见坑

坑 1：把 workflow 当 prompt 写

把所有逻辑塞进一个超长 prompt，让 AI 自己"决定"走哪步。结果不可预测，不可调试。记住：workflow 的核心是"你来控制流程"，不是"让 AI 控制"。

坑 2：节点之间传结构化数据

A 节点输出一段话，B 节点再去理解这段话。每一步都有信息损失。用 JSON 传结构化数据。

坑 3：没有失败处理

AI 调用多次时肯定会有失败的情况。不加重试和兜底，workflow 上线很快就会崩。

坑 4：节点太碎

拆得太细也不行。一个 workflow 30 个节点，调试比写还难。原则：一个节点对应一个你能用一句话描述的职责。

坑 5：不记录中间结果

workflow 跑完后只看最终输出，中间节点的结果丢掉。出问题时没法回溯。建议把每个节点的输入输出都落日志。

八、Workflow vs Agent：再厘清一个概念

很多人把这两个词混着用，其实有区别：

Workflow：流程是你预先设计好的，节点和连接都是固定的。AI 只在每个节点里干活，不决定走哪条路。

Agent：流程是 AI 自己决定的。你给一个目标，AI 自己拆任务、调用工具、决定下一步干什么。

举例：

- Workflow：你设计了"翻译→摘要→打分→分发"这条线，AI 只负责每步的内容生成。 - Agent：你说"帮我把这篇文章处理一下发出去"，AI 自己决定要先翻译、再摘要、再打分、再发，整个过程可能跟你想的不一样。

实际项目中，两者经常混用。主干用 workflow 保证可控，局部用 agent 处理不确定的子任务。

新手建议从 workflow 开始。Agent 看起来酷，但不可控、不可调试、不可复现。等 workflow 玩熟了，再在某些节点上引入 agent 能力。

结语

Prompt 是"一句话让 AI 干活"，适合简单任务。 Workflow 是"设计一条流水线让 AI 在每个工位干活"，适合复杂任务。

当你发现一个 prompt 怎么调都不稳定时，停下来问自己：这个任务是不是该拆成 workflow？ 。

把任务拆开，每步简单可靠，串起来稳定可控——这就是 workflow 设计的精髓。

Prompt Cache 怎么用？Claude / GPT 缓存机制与降本实战

addtoken — Mon, 13 Jul 2026 13:24:06 +0000

同样调用 Claude Sonnet 4 处理一个 50K token 的长上下文任务，有人每千次成本 $250，有人只要 $35。差距不在模型，在于有没有打开 Prompt Cache。

如果你在做长上下文应用、Agent 工作流、RAG 系统，或者大量重复调用同一个 system prompt，Prompt Cache 是目前 LLM API 里 ROI 最高的一项能力——但很多开发者要么没听说过，要么听说了却用错。这篇文章把 Claude 和 OpenAI 两家的缓存机制讲清楚：原理、参数、代码、降本测算、踩坑点，一次说透。

一、Prompt Cache 是什么：用空间换时间

Prompt Cache 的本质很朴素：LLM 推理时，对 prompt 的前缀部分做 KV Cache 持久化。下次请求如果前缀完全相同，就直接复用已算好的中间结果，跳过最贵的预填充（prefill）阶段。

这个机制不是 Anthropic 或 OpenAI 的发明，而是从 vLLM、SGLang 这类推理引擎里的 PagedAttention、RadixAttention 演化而来。区别在于：开源引擎的缓存是单机内存级的，请求结束就释放；而厂商 API 把它做成了跨请求、跨会话的持久化能力，按使用量计费。

为什么要做缓存？因为 prefill 阶段是 Transformer 推理里最贵的部分。一个 100K token 的 prompt，每生成一个输出 token 之前，都要先把这 100K token 全部过一遍 attention 计算。如果不缓存，你每发一次请求就重算一次；如果缓存了，第二次起这 100K token 的计算成本直接归零（只付一个读取费）。

所以 Prompt Cache 适用于一个明确场景：相同前缀、高频重复调用。 典型场景包括：

长 system prompt + 短用户输入：Agent 框架里固定的角色设定、工具描述、规则文档 - 多轮对话：每一轮的上下文都包含之前所有轮次，前缀天然重叠 - RAG 系统：检索回来的大段文档作为前缀，用户问题作为后缀 - 代码助手：项目代码库作为上下文，反复询问不同问题 - 批量处理同质任务：同一份 few-shot 示例 + 不同输入

如果你的应用是"一次性的、前缀都不一样"，Prompt Cache 帮不到你,但这种情况其实很少。

二、Claude 的 Prompt Caching：手动控制、定价激进

Anthropic 在 2024 年 8 月推出 Prompt Caching，目前已是正式能力（不再是 beta）。它的核心特点是手动控制、显式标记、定价激进。

2.1 工作原理：用 cache_control 标记缓存断点

Claude 的缓存不是自动的，你需要在请求里显式标记哪些内容块要被缓存。通过 cache_control 字段实现：

import anthropic

client = anthropic.Anthropic(
    api_key="your-api-key",
    base_url="https://api.addtoken.top/v1"  # 中转站示例
)

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "<长达 50000 token 的项目规范文档...>"
        },
        {
            "type": "text",
            "text": "<工具使用说明...>",
            "cache_control": {"type": "ephemeral"}  # 在这里标记缓存断点
        }
    ],
    messages=[
        {"role": "user", "content": "请帮我实现用户登录模块"}
    ]
)

cache_control 可以放在 system、messages、tools 任何一个内容块上。Claude 会把从请求开始到带有 cache_control 标记的内容块为止作为一个可缓存的前缀（cacheable prefix）。

关键限制：每个请求最多 4 个 cache breakpoint。 这意味着你不能把 prompt 切得太碎，要规划好哪些段落是稳定不变的。

我们用claude code 或OpenAI Codex ，或者cursor,trae等代码工具时，完全不用担心，工具中已经帮你做好了设置。但是若自己做agent工作流，需要自己手动添加 cache_control 标记，且非常推荐要添加。

2.2 计费模型：写入贵 25%，读取便宜 90%

Claude 的缓存定价是行业内最激进的，也是它最大的卖点：

关键判断：缓存写入比标准价贵 25%，但读取便宜 90%。所以只要同一份前缀被读取 ≥ 2 次，就已经回本。 读取次数越多，节省越多。一个被读取 10 次的前缀，整体输入成本能降到原来的 22% 左右。

2.3 最小缓存阈值：只有足够长的 Prompt 才能建立缓存

并不是任何长度的 Prompt 都可以启用 Prompt Cache。Anthropic 为不同模型设置了最小缓存长度（Minimum Cacheable Prompt Length），只有 cache_control 之前的内容达到对应阈值，系统才会建立缓存。

需要注意的是，该阈值因模型而异，并可能随着新模型发布而调整。例如，目前 Claude Sonnet 5 的最小缓存长度为 1024 Tokens，而 Claude Opus 4.5、Claude Haiku 4.5 等模型则要求 4096 Tokens

如果 cache_control 之前的内容未达到模型要求：

不会建立 Prompt Cache；不会收取缓存写入费用；请求仍会按普通输入 Token 正常计费； API 不会返回错误，而是静默跳过缓存。

因此，开发者可以通过响应中的 usage 字段（如 cache_creation_input_tokens 和 cache_read_input_tokens）确认缓存是否真正生效，而不要仅凭是否设置了 cache_control 来判断。

2.4 缓存生命周期（TTL）：默认 5 分钟，可扩展至 1 小时

这里有一个2026 年的关键变化，很多旧教程没跟上。

Prompt Cache 并不是永久保存。Anthropic 默认提供 5 分钟 TTL（Time To Live），即缓存会在最后一次命中后保留至少 5 分钟。每次成功命中缓存都会自动刷新 TTL，因此只要应用持续发送请求，缓存可以一直保持有效；只有当连续超过 5 分钟未使用时，缓存才会失效并需要重新建立。

也就是说你吃个饭的功夫，只要超过5分钟没有使用，缓存就会失效。再次创建缓存时，需要重新输入所有内容，费用暴涨。

如果你需要更长的缓存窗口（比如批量处理任务间隔超过 5 分钟），需要显式声明 1 小时 TTL：

Python

"cache_control": {"type": "ephemeral", "ttl": "1h"}

1 小时 TTL 的写入费稍贵（约 1.5× 标准价），但读取价不变。对于间隔较长的批量任务，这个依然划算。

从 Claude Code v2.1.108 开始，可以通过环境变量请求 1 小时 Prompt Cache：

Linux/macOS：

export ENABLE_PROMPT_CACHING_1H=1
claude

永久生效：

echo 'export ENABLE_PROMPT_CACHING_1H=1' >> ~/.zshrc
source ~/.zshrc

Windows PowerShell：

env:ENABLE_PROMPT_CACHING_1H="1"
claude

或者永久生效：

setx ENABLE_PROMPT_CACHING_1H 1

2.5 响应里看缓存命中情况

调用完成后，response 的 usage 字段会返回三类 token 数： json

{
  "usage": {
    "input_tokens": 120,           // 未命中缓存、也未写入缓存的输入 token
    "cache_creation_input_tokens": 50000,  // 这次写入缓存的 token
    "cache_read_input_tokens": 0,   // 这次命中缓存的 token
    "output_tokens": 850
  }
}

第一次调用：cache_creation_input_tokens ≈ 50000，cache_read_input_tokens = 0。第二次调用相同前缀：cache_creation_input_tokens = 0，cache_read_input_tokens ≈ 50000。

监控这两个字段的比例，是评估你缓存策略是否合理的核心指标。

三、OpenAI 的 Prompt Caching：自动开启、前缀匹配

OpenAI 在 2024 年 10 月推出 Prompt Caching，策略与 Anthropic 完全相反——全自动、零配置、收益温和。

3.1 工作原理：自动 prefix 匹配，无需改代码

OpenAI 的缓存对开发者完全透明：

任何 ≥ 1024 token 的 prompt 自动进入缓存候选池 - 系统按 prompt 的前缀做哈希路由，把请求分发到同一台推理机 - 如果前缀已缓存，自动命中

你不需要改任何代码。 调用方式、参数、消息结构都不变，账单自动按缓存价计算。

3.2 计费模型：写入不收费，读取打 5 折

OpenAI 的定价温和得多：

注意几个细节：

GPT-5.6 之前的模型（GPT-4o、GPT-4 Turbo 等），写入不额外收费 - GPT-5.6 及之后的新模型，写入按 1.25× 计费（向 Anthropic 看齐） - 读取统一是 0.5×，没有 Anthropic 的 0.1× 那么激进

对比 Claude：OpenAI 命中时的单次成本是 Claude 的 5 倍（0.5× vs 0.1×），但写入时是免费的。 所以 OpenAI 的策略更适合"前缀不稳定、偶尔命中"的场景，Claude 更适合"前缀非常稳定、高频命中"的场景。

3.3 最小匹配：1024 token 连续前缀

OpenAI 的匹配规则比 Anthropic 严格：

prompt 必须至少有 1024 token - 前 1024 token 必须完全连续一致才能命中 - 1024 token 之后的部分按更细粒度匹配

这意味着哪怕你的 system prompt 只差一个字符，也会从那一点开始完全 miss。所以用 OpenAI 缓存时，system prompt 的开头部分一定要稳定——不要在前面放时间戳、不要放随机 ID、不要放用户名。把这些动态内容放到 prompt 末尾。

3.4 TTL：约 5–10 分钟空闲即过期

OpenAI 没有公开承诺精确的 TTL，官方文档表述为"off-peak 期间缓存可能保留更久，繁忙期间可能更短"。实测下来大概是 5–10 分钟无访问就失效，繁忙时段可能更短。

OpenAI 不提供 1 小时 TTL 选项，这是它和 Claude 的一个关键差异。如果你的批量任务间隔较长，OpenAI 这边的命中率会明显下降。

3.5 响应里看命中

OpenAI 的 usage 字段：

json代码

{
  "usage": {
    "prompt_tokens": 51000,        // 总输入 token
    "prompt_tokens_details": {
      "cached_tokens": 50000       // 其中命中缓存的部分
    },
    "completion_tokens": 850
  }
}

cached_tokens / prompt_tokens 就是你的命中率。

四、降本实战：一个真实场景的测算

抽象讲完，看一个具体例子。假设你在做一个代码助手：

固定上下文：项目代码 + 规范文档 = 80K token - 用户问题：平均 500 token - 每天调用：10000 次 - 模型：Claude Sonnet 4（$3/MTok 输入）

不启用缓存：

每天输入成本 = 10000 × (80000 + 500) / 1e6 × $3 = $2415 - 月成本 ≈ $72,450

启用 Claude Prompt Cache（假设 95% 命中率）：

第一次写入：80K × 1.25 = 100K 等效 token - 后续 9999 次读取：80000 × 0.1 × 9999 = 7,999,200 等效 token - 用户问题部分：500 × 10000 = 5,000,000 token（不缓存） - 总等效输入 = 7,999,200 + 100,000 + 5,000,000 ≈ 13.1M token - 每天成本 = 13.1M / 1e6 × $3 = $39.3 - 月成本 ≈ $1179

降本比例：约 98.4%。

换成 OpenAI GPT-4o（$2.5/MTok 输入，缓存读取 0.5×）：

总等效输入 ≈ 80000 × 0.5 × 9999 + 500 × 10000 ≈ 45M token - 每天成本 = 45M / 1e6 × $2.5 = $112.5 - 月成本 ≈ $3375

对比结论：在高频长前缀场景下，Claude Prompt Cache 的成本优势是 OpenAI 的 3 倍以上。 但前提是你的前缀足够稳定、命中率足够高。如果命中率只有 50%，Claude 的写入溢价反而会让成本逼近甚至超过 OpenAI。

五、五个常见踩坑点

实际接入过程中，下面这些问题反复出现：

坑 1：动态内容放在前面，缓存永远不命中

错误写法（python）：

system = f"""
当前时间：{datetime.now()}
用户ID：{user_id}
项目规范：{project_spec}  # 这才是稳定的大段内容
"""

时间戳和用户 ID 让前缀每次都变，缓存永远 miss。正确做法：把稳定的大段内容放前面，动态信息放后面。

system = [
    {"type": "text", "text": project_spec, "cache_control": {"type": "ephemeral"}},
    {"type": "text", "text": f"当前时间：{datetime.now()}\n用户ID：{user_id}"}
]

坑 2：缓存断点放错位置

cache_control 标记的是"缓存到这里为止"，不是"从这里开始"。如果你把断点放在 system prompt 的中间，那只有前半部分会被缓存，后半部分每次都要重算。

经验法则：断点放在内容块的最末尾，让缓存覆盖最大范围。

坑 3：忽视 5 分钟 TTL，批量任务莫名其妙变贵

2026 年 3 月 Anthropic 默认 TTL 降到 5 分钟后，很多批量任务的成本突然翻倍。原因是任务间隔超过 5 分钟，缓存已失效，每次都重新写入。

应对： 评估任务间隔，超过 5 分钟的批量任务显式声明 ttl: "1h"。

坑 4：用 OpenAI 时把 system 拆成多个 message

OpenAI 的缓存按 token 流的连续前缀匹配。如果你把 system 拆成多条 message：

messages = [
    {"role": "system", "content": "规则A"},
    {"role": "system", "content": "规则B"},
    {"role": "system", "content": "规则C"},
    {"role": "user", "content": "..."}
]

虽然功能等价，但 OpenAI 内部会把它们拼成一条 token 流，前缀匹配仍然有效。但如果你在不同请求里用了不同的拼接顺序，命中率会大幅下降。保持 system 的结构稳定。

坑 5：只看 input_tokens，不看 cache_creation 和 cache_read

很多开发者接入缓存后只盯着总 input_tokens 数量，没发现缓存其实根本没命中。正确的监控指标是：

cache_read_input_tokens / (cache_read_input_tokens + cache_creation_input_tokens + input_tokens) = 命中率 - 命中率 90% 时，说明缓存策略健康

六、选型建议：Claude 还是 OpenAI？

基于上面的分析，给一个直接的选型建议：

选 Claude Prompt Cache 的场景：

长上下文（>20K token）+ 高频重复调用（>10 次/小时） - Agent 框架，固定 system prompt + 工具定义 - 代码助手、文档问答、企业知识库 - 需要精确控制缓存边界

选 OpenAI Prompt Cache 的场景：

前缀不太稳定，命中率预期 30%–60% - 不想改代码，希望透明降本 - 任务间隔超过 5 分钟但又不到 1 小时 - 多模型混用，希望统一调用方式

两个都用：

复杂业务里，固定上下文部分走 Claude 缓存（吃 0.1× 读取价） - 短上下文动态部分走 GPT-4o（吃自动缓存的便利性） - 通过 API 中转层（如 addtoken.top 这类 OpenAI 兼容接口）统一调度，按场景路由

七、几个高频问题

Q1：第三方 API 中转会破坏缓存吗？

不一定。取决于中转层是否做了请求哈希路由。一个合格的 OpenAI 兼容中转层应该保留原始请求结构透传给上游，这样前缀匹配仍然有效。但如果中转层在请求里插入了广告、水印、用户标识等动态内容，缓存会被破坏。选择中转服务时要确认这一点。

本文示例使用 Token补给站（https://addtoken.top）进行测试。平台提供 OpenAI 与 Anthropic 兼容 API，保持与官方协议一致，支持透传 Prompt Caching 等相关字段，方便开发者在不修改业务代码的情况下接入和验证缓存能力。实际缓存是否命中仍以 Anthropic 官方缓存策略和请求内容为准。

Q2：缓存会泄漏其他用户的内容吗？

不会。Anthropic 和 OpenAI 都明确说明缓存是按账号/组织隔离的。你的缓存只有你自己的后续请求能命中。

Q3：缓存命中会降低输出质量吗？

不会。缓存的是 prefill 阶段的 KV 中间结果，对模型本身是等价的。命中和不命中，模型看到的输入完全一样，输出概率分布也完全一样。

Q4：为什么我的 cache\_creation\_input\_tokens\ 比预期多很多？

最常见原因是同一个请求里有多个 cache breakpoint，且每个断点都触发了写入。检查你的 cache_control 数量，4 个断点意味着最多 4 次写入。

Q5：Claude Code 自动用 Prompt Cache 吗？

是的。Claude Code 在内部已经接入了 Prompt Caching，CLAUDE.md 文件、项目上下文、对话历史都会自动缓存。这也是为什么 Claude Code 在长会话场景下相对其他工具成本更低的原因之一。

结语

Prompt Cache 不是一个高级特性，而是 LLM API 的基础能力。在做任何长上下文应用之前，你应该先问自己一个问题：我的前缀稳定吗？如果稳定，我启用缓存了吗？

这个问题的答案，往往直接决定了你的应用能不能跑得起来。在 token 单价越来越贵的今天，缓存策略带来的 10 倍成本差异，远比换一个更便宜的供应商重要得多。

Cursor/Trae 接 Claude API，为什么发挥不出模型真正实力？

addtoken — Mon, 13 Jul 2026 08:43:33 +0000

深度解析为什么把 Claude API 接入 Cursor、Trae 等第三方 IDE 后体验明显下滑。从上下文管理、工具调用、推理连续性三层损耗切入，揭示 AI 编程工具正从"模型驱动"转向"Agent 工作流驱动"的范式转移，并给出开发者工具链选择建议。

一个被忽视的反差现象

最近半年，我们接触到大量开发者用户，他们中相当一部分人有过这样的困惑：明明用的是同一个 Claude 模型，甚至是通过同一套 API 通道，但体验和直接使用 Claude Code 时差距明显——在 Cursor 里改一个稍复杂的需求，模型常常"懂一半、漏一半"；在 Trae 里让它做跨文件重构，它往往停在表面修改，不愿意、也不能像原生 Claude Code 那样深挖到底。

很多人第一反应是怀疑 API 通道质量、怀疑是不是被降级到了某个轻量版本。但当我们把同一把 key 同时放到 Claude Code 原生环境和 Cursor 中跑同一组任务，结论非常清晰：模型本身没有问题，问题出在"接入"这件事上。

这篇文章想讨论的，就是这个被很多开发者忽视的反差——以及它背后那个更值得关注的趋势：AI 编程工具正在从"模型驱动"转向"Agent 工作流驱动"。

论点一："接入"本身就是一种能力损耗

很多开发者把"接入 Claude API"理解为"调用 Claude 的能力"。但从工程角度看，这是一个相当大的误解。API 调用只传递了模型的文本生成能力，并没有传递模型在原生环境中所享受的全部能力栈。 当一个模型被设计为 Agent，它的能力是有层次的：上下文管理、工具调用、长程推理、自我校验——这些能力在原生环境中是由模型厂商和工具厂商共同调优、深度耦合的。一旦你把它"接"进第三方 IDE，这些耦合就会被一层一层地拆开。

第一层损耗是上下文管理损耗。Claude 原生环境对上下文窗口的调度是动态的——它会根据任务复杂度决定何时压缩历史、何时主动遗忘、何时把关键信息前置。但 Cursor/Trae 这类第三方工具有自己的上下文编排逻辑：它们会把项目结构、打开的文件、最近编辑、用户对话，按自己的优先级塞进 prompt。结果是，模型在原生环境里能"看清"的上下文，到了第三方工具里被重新切片、重新排序，关键信息可能被裁掉、无关信息可能被保留。模型并不是变笨了，而是它看到的"世界"被换了滤镜。

第二层损耗是工具调用（Tool use）损耗。Claude 的 Tool use 能力是它作为 Agent 的核心——它能主动决定调用哪个工具、以什么参数调用、调用几次、如何串联结果。在 Claude Code 这种同源环境里，工具协议是为 Claude 量身设计的，调用路径短、反馈直接。但第三方工具通常会有自己的工具协议封装层：模型说"我要读这个文件"，第三方工具把它翻译成自己 IDE 内部的一个命令；模型说"我要执行这段代码"，第三方工具再翻译成一次终端调用。每多一层翻译，就多一次失真、多一次延迟、多一次"模型意图"和"工具执行"之间的偏差。这就是为什么同样的需求，原生 Claude Code 能一气呵成完成十步操作，而在 Cursor 里你可能要分三四轮才能把它推到同样的深度。

第三层损耗是推理连续性损耗。Claude 在面对复杂任务时，会进行长程的、多步的推理——它会自己规划、自己验证、自己回溯。这种推理的连续性高度依赖执行环境的可预测性：模型说"我下一步要做 X"，环境就立刻执行 X 并把结果原样返回。但在第三方 IDE 里，每一步执行都可能穿插 UI 提示、人工确认、工具自身的过滤逻辑，模型的多步推理链条被打断，它只能"分段思考"。一个原本可以连续走完十步的任务，被打断成五段、每段两步，整体效果自然大打折扣。

这三层损耗叠加起来，就解释了那个反差现象：你不是在用一个被"接入"的 Claude，你是在用一个被"重塑"过的 Claude——它的能力边界不是模型定义的，而是工具定义的。

论点二：模型能力 ≠ 工具能力，但二者正在深度耦合

要理解为什么"接入"会造成损耗，需要先厘清一个常见误解：模型能力和工具能力是两件不同的事。 模型能力指的是模型本身的推理、生成、Tool use 等底层能力，它由模型权重和训练数据决定；工具能力指的是 IDE、Agent 框架等运行环境为模型提供的外部支撑，它由工具的架构设计和协议设计决定。在过去很长一段时间的"补全时代"，这两件事确实可以分开看——模型负责生成代码，工具负责提供编辑器环境，两者之间通过一个简单的文本接口对接就够了。

但进入 Agent 时代之后，这两件事正在快速耦合。当模型从"被动生成"变成"主动执行"，工具就不再只是一个外壳，而是模型能力的延伸和放大器。 一个模型的原生能力有多强，不仅取决于它的权重，更取决于它身后那套工具链能把它推到多深。Claude Code 之所以能把 Claude 推到那个深度，正是因为它和 Claude 是同源的——工具协议是为 Claude 设计的，上下文编排是为 Claude 调优的，工具调用反馈是为 Claude 优化的。这不是技术细节，这是架构事实。

反过来看，Cursor 和 Trae 的核心价值一直在于工具层——它们的代码库索引、多文件编辑、上下文管理这些 IDE 能力，本身是非常优秀的产品设计。但工具层的优秀和模型层的适配，是两个独立的维度。 当 Cursor/Trae 没有针对 Claude 做深度适配时，工具层就成了模型能力的瓶颈：模型想做的，工具不让做；模型能做的，工具降级了；模型需要的反馈，工具过滤了。这就是为什么会出现"明明接入了 Claude，却感觉没比普通模型强多少"这种错觉——你体验到的不是模型的天花板，而是适配度的天花板。

未来评估一个 AI 编程工具，不能只看它接入了哪些模型，更要看它对每个模型的适配深度。 一个工具接入了五个模型但每个都浅尝辄止，可能不如一个工具只深度适配一个模型来得强。"接入数量"这个指标，在 Agent 时代会越来越失去意义。

论点三：范式转移——从"模型驱动"到"Agent 工作流驱动"

AI 编程工具正在从"模型驱动"转向"Agent 工作流驱动"。 从这三款产品各自的演进路径中，可以看到趋势。

Claude Code 的方向是最明确的——它从一开始就不是"接入 Claude 的工具"，而是"Claude 的原生 Agent 形态"。Anthropic 推出它的逻辑很清楚：模型不是一个API，而是一个有完整工作流的 Agent。Claude Code 的每一次迭代，都在加强这个 Agent 的上下文编排能力、工具调用深度、长程推理稳定性。它的发展是让模型的工作流越来越完整，而不是让工具的功能越来越多。

Cursor 的演进更微妙。它最初是一个"补全增强"工具，核心竞争力是代码索引和补全质量；后来转向 Chat 模式，接入多家模型，成为一个"AI 编辑器"；最近又开始往 Agent 方向演进，强调多步执行、自主修改、项目级理解。本质上是在补"工作流"这块短板——但受限于它作为第三方工具的架构约束：它必须同时服务多个模型，所以适配深度会被摊薄。

Trae 的路径类似但更激进——它从开始就把 Agent 作为核心叙事，工具链路设计得更接近原生 Agent 形态。但同样它作为第三方工具，依然面临"多模型适配"和"深度适配"之间的取舍。

从上可以看出：重点是，不要简单地把某个模型接入某个工具，而是哪个工具能够最大程度保留模型原生能力，并把这些能力融入整个开发流程。 原生 Agent 形态（Claude Code）走的是"模型即工作流"路线，第三方工具走的是"工作流跨模型"路线。两条路线没有对错，但体验天花板是不同的——前者因为是同源，可以把模型能力榨干；后者因为是跨源，必然存在适配损耗。

论点四：开发者竞争的新坐标系

对开发者而言，竞争的坐标系也在悄悄变化。过去几年，开发者之间的竞争重点是谁能用到更强的模型——拼 token 额度、拼接入渠道、拼模型版本。但这个维度的差距正在快速缩小。 随着 Claude、GPT、Gemini 等头部模型能力的趋同，以及 API 渠道的普及，"能不能用上最强模型"已经不是开发者之间的关键差异点。未来开发者竞争的重点，是谁拥有更完整的 Agent 工作流。

。第一，单纯依赖单一工具会越来越被动。 无论你用的是 Cursor、Trae 还是 Claude Code，如果只是把它当成"更强的补全工具"，你都会错过 Agent 工作流带来的真正红利。Agent 工作流的价值在于把"模型 + 工具 + 流程"三者编织成一个能自主完成复杂任务的系统，这要求开发者主动去设计这个系统，而不是被动等待工具升级。

第二，工作流的可组合性比工具本身更重要。 一个完整的工作流往往不是单一工具能覆盖的——你可能需要 Claude Code 做深度重构、Cursor 做日常补全、还有一个自定义 Agent 做特定场景的自动化。把这些工具组合起来，让它们各自发挥优势，比纠结"该选哪一个"更有意义。

第三，开发者需要从"用户心态"转向"编排者心态"。 用户心态关心的是"这个工具好不好用"，编排者心态关心的是"我能不能把模型能力、工具能力、流程能力组装成一个完整的工作流"。前者是被动的、消费式的；后者是主动的、生产式的。这个心态转变，可能是 Agent 时代开发者最需要的一次认知升级。

作为 API 供应商的中立观察

我们作为一个提供 Claude API 服务的供应商【Token补给站】（https://app.addtoken.top/），每天都在和大量开发者打交道。正因如此，我们有一个比较特殊的中立视角:我们观察到一个非常稳定的规律：抱怨"模型不行"的用户，问题往往不在 token 质量，而在工具链选择。同一个 key，在原生环境和第三方工具里的体验差距，比不同供应商之间的 token 质量差距更大。

这也让我们对自己的定位有了更清楚的认识。我们关心的不只是把 token 卖出去，更关心用户能不能真正把模型能力用出来。 一个用户买了 100 万 token 但因在错误的工作流里使用，只发挥了 30 万 token 的价值，这对我们来说不是成功，而是失败——因为用户最终会归因为"模型不行"，然后流失。所以我们愿意花时间写这类内容，把工具链选择的判断分享出来，而不是只做一次性的 token 交易。我们相信，让用户真正用好模型，比让他们买更多 token 更重要。

当你想"把 Claude 接进 Cursor/Trae"的时候，不妨先问自己一个问题：你想要的是更顺手地用 Claude模型，还是想发挥 Claude 能力上限？这两个问题的答案，可能指向完全不同的工具选择。