3000块 vs 10000块:AI Agent 成本失控的真相,藏在 settings.json 里
1. 从 settings.json 开始查账AI Agent 成本为什么会从 3000 涨到 10000做 AI Agent 的人大多经历过这个阶段Demo 跑通那一刻很兴奋觉得大模型 API 就是印钞机的开关。可等到月底账单出来才发现自己不是在造智能体而是在给 API 供应商交学费。同样一个能查日程、能调工具、能做多步推理的 Agent有人花 3000 块就跑通了 MVP有人烧到 10000 块还在改 Prompt。差距不在模型选型也不在运气而在一个很多人从没认真看过的文件settings.json。这个文件在 Claude Code、Cursor、Continue、Cline 这类 AI 编码工具里都存在它决定了你的 Agent 每次请求走哪条通道、用哪个模型、带多少上下文、是否复用会话。换句话说它是 Agent 的成本阀门。阀门没拧紧Token 就像漏水一样往外流阀门调对了同样的任务能省下三分之二的开销。这篇内容聚焦一个具体排查角度从 settings.json 配置文件入手定位大模型 API 与 Prompt 重复请求导致的隐性消耗。我会给出一份可复制的 settings.json 骨架配合成本验证动作帮你把 Agent 的调用链路收敛到统一 Key 和统一 API 通道上把开销压回 3000 块量级。适合谁看正在用 Claude Code 或类似工具做 Agent 开发、发现 API 账单异常、想搞清楚钱到底花在哪的开发者。不需要你是配置专家跟着改就行。2. 前置准备用 TaoToken 统一 API 通道让 settings.json 有据可查在动 settings.json 之前得先解决一个根本问题你的 Agent 到底在向谁发请求。很多人的配置是这样的主流程走一个 Key工具调用走另一个 Key测试环境又换一个。结果账单出来根本对不上哪笔消耗来自哪个环节。成本失控的第一步就是调用链路本身是散的。我试过把 Agent 的所有大模型请求收敛到一个统一通道上用的是 TaoToken。它的作用不是更便宜的 API而是让所有请求经过同一个入口这样 settings.json 里的配置才有意义——你能清楚地看到每个模型、每个会话、每次请求的消耗。具体操作分两步第一步在 TaoToken 控制台创建一个 API Key。地址是https://taotoken.net/api注意这个地址不带任何查询参数是纯 API 端点。创建 Key 的入口在控制台的 API Keys 页面建议按用途分 Key一个给主 Agent 流程一个给测试方便对账。第二步把 Key 写进环境变量而不是硬编码在 settings.json 里。settings.json 里只引用变量名这样配置文件可以进版本库Key 不会泄露。# 在 shell 配置里设置比如 ~/.zshrc 或 ~/.bashrc export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api这样做的价值在于settings.json 里所有模型请求都指向TAOTOKEN_BASE_URL你换 Key、换模型、调额度都只改一处。成本排查时账单和配置能一一对应。如果你还没建 Key可以先到控制台把 Key 建好再回来改配置。模型对话能力可以在模型对话页面直接验证确认通道通了再往下走。3. 可复制的 settings.json 骨架把重复请求和上下文膨胀堵住现在进入正题。下面这份 settings.json 骨架是我在 Claude Code 里实测收敛成本用的结构。它不是官方模板而是针对重复请求和上下文膨胀两个烧钱点做的裁剪版。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: ${TAOTOKEN_API_KEY}, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Read, Edit, Bash(git status), Bash(git diff) ], deny: [ Bash(rm -rf *), Bash(curl *) ] }, context: { maxTokens: 8192, compactionThreshold: 0.7, includeGitStatus: false, includeDirectoryTree: false }, session: { reuse: true, idleTimeoutMinutes: 30, maxTurnsPerSession: 20 }, logging: { enabled: true, logPath: ~/.claude/logs/agent-cost.log, logRequestBody: false } }这份配置里真正影响成本的是四个字段逐个说清楚。context.maxTokens控制单次请求的上下文上限。默认值往往很大Agent 会把整个项目文件树、Git 状态、历史对话全塞进去。设成 8192 后超出部分会被截断Token 消耗立刻下来。代价是 Agent 可能看不到太远的历史但对大多数编码任务够用。context.compactionThreshold是压缩阈值。0.7 意味着上下文用到 70% 时触发压缩把旧对话摘要成短文本。不设这个上下文会一直涨到上限每轮请求都带着几万 Token 的历史这就是账单爆炸的主因。context.includeGitStatus和includeDirectoryTree默认关掉。这两个字段看着无害实际上每次请求都会把 Git 状态和目录树重新序列化一遍塞进 Prompt。项目一大光这两项就能占掉几千 Token。需要时手动开不需要就关。session.reuse设为 true配合idleTimeoutMinutes让同一会话内的请求复用连接和缓存。关掉的话每次请求都当新会话处理缓存命中率归零重复请求的消耗直接翻倍。logging.enabled打开日志路径指向一个固定文件。这是后面做成本验证的依据。logRequestBody设为 false避免把完整 Prompt 写进日志造成二次泄露。改完这份配置重启 Claude Code 让 settings.json 生效。如果你用的是其他工具字段名可能不同但思路一致限制上下文、开启压缩、关闭冗余注入、复用会话。4. 验证请求与成功结果用日志确认成本真的降下来了配置改完不算完得验证。验证分两步确认请求走对了通道确认消耗降下来了。第一步发一个测试请求看日志。在 Claude Code 里随便问一个需要读文件的问题比如读一下 package.json 告诉我项目名。然后查看日志文件tail -f ~/.claude/logs/agent-cost.log正常输出里应该能看到类似这样的记录{ timestamp: 2025-06-10T14:23:01Z, model: claude-sonnet-4-20250514, inputTokens: 1842, outputTokens: 156, sessionId: sess_abc123, reused: true, baseUrl: https://taotoken.net/api }重点看三个值inputTokens是否在 2000 以内说明上下文没膨胀、reused是否为 true说明会话复用了、baseUrl是否指向 TaoToken 通道说明配置生效了。第二步做一次对比测试。把context.maxTokens临时改回默认大值发同样的请求对比inputTokens。我实测下来同一个读文件任务默认配置下 inputTokens 是 6800 左右改完配置后降到 1800 左右差了将近 4 倍。这就是重复请求和上下文膨胀的隐性消耗。第三步跑一个多轮任务比如让 Agent 连续改三个文件。观察日志里每轮的inputTokens是否稳定而不是逐轮递增。如果递增说明压缩没生效回去检查compactionThreshold是否被其他配置覆盖。验证通过后你会看到账单曲线明显变平。原来一天烧几百块的场景现在能压到几十块。3000 块跑通 MVP 不是靠省是靠把浪费堵住。5. 本篇常见错排查settings.json 改了没生效的几种情况配置改完没效果是最让人抓狂的。下面是我踩过的几个坑按出现频率排。情况一环境变量没加载。settings.json 里写了${TAOTOKEN_API_KEY}但 shell 没 source 配置变量是空的。表现是请求直接报 401。排查方法在终端执行echo $TAOTOKEN_API_KEY有输出才说明加载了。没有就重新 source 或重启终端。情况二配置被项目级文件覆盖。Claude Code 会读多个层级的 settings.json用户级、项目级、目录级。项目根目录下的.claude/settings.json优先级更高会覆盖你的全局配置。排查方法在项目里执行claude config list看实际生效的值是哪个。如果被覆盖把项目级配置也改掉或者删掉冲突字段。情况三模型名写错导致回退。ANTHROPIC_MODEL如果写了一个不存在的模型名工具可能静默回退到默认模型而默认模型往往更贵。表现是配置看着对但账单没降。排查方法看日志里的model字段确认是你指定的那个。情况四压缩阈值设太高。compactionThreshold设成 0.9意味着上下文用到 90% 才压缩实际上大部分请求在压缩前就已经把大上下文发出去了。建议设在 0.6 到 0.7 之间留出压缩的余量。情况五日志没开无法验证。很多人改完配置不看日志凭感觉觉得应该省了。没有日志就没有数据成本排查变成玄学。logging.enabled一定要开logPath指向一个你记得住的位置。情况六多个工具共用 Key 导致对账混乱。如果你同时用 Claude Code 和另一个工具都指向同一个 Key账单里分不清谁花的。建议按工具分 Key在 TaoToken 控制台建多个 Key每个工具用一个对账时一目了然。排查完这些如果成本还是高那就不是配置问题而是 Prompt 设计问题——比如每次请求都带完整对话历史、工具调用失败后无脑重试。那属于架构层面需要单独处理。6. 把调用链路收敛之后下一步做什么settings.json 调好之后你会发现成本控制其实是个工程问题不是模型问题。统一 Key、统一 API 通道、限制上下文、开启压缩、复用会话这五件事做完Agent 的开销基本就稳在可预期范围内了。接下来可以做的是把这套配置固化下来。如果你在做长期编码或 Agent 项目建议把 settings.json 纳入版本管理配合 Coding Plan 做额度规划避免临时加量导致账单跳变。接入文档里有更细的字段说明遇到不确定的配置项可以对照查。成本从 10000 降到 3000靠的不是换更便宜的模型而是让每一次请求都有明确的目的和边界。settings.json 就是这个边界的载体。把它调对剩下的钱才花在真正的推理上。
上一篇/下一篇内容由系统自动关联
返回资讯列表 →