本周营业的朋友做完实验 发现智能体跑到第 170 轮成本翻倍的故事

本周营业的朋友做完一组实验，发现 Claude（注，一款主流 AI 对话工具）的成本曲线不是线性的。这个发现来自一个叫 lordbron 的开发者，他在 HN 上发了一篇长帖，标题是 Claude innerworkings turn 170 costs 2.1x turn 20。他在帖子里给的数据非常硬，他分析了 144 个会话，总共 14，640 轮对话。结果发现同一个会话里，第 170 轮的单轮成本是第 20 轮的 2.1 倍。把这件事的逻辑推到底层，其实反映了一种典型的做事方式。不是一次性把所有环节做完美，而是先抓住最核心的环节跑通，其他环节在迭代过程中逐步补全。



这个 2.1 倍是怎么算出来的？他在文章里给了一个非常具体的拆解。Claude 每次生成回复前，都会把整个对话历史重新读一遍。这个重新读取的成本在第 20 轮大概是 8 万个 token，到了第 170 轮就涨到了 11.4 万个 token。重新读取的 token 量在涨，单轮的实际回复 token 量却没怎么变，于是单轮总成本就被重新读取的成本推高了。从这个案例出发往更大的行业背景看，能跑出来的团队往往在某个具体环节做出了同行做不到的深度，而这种深度才是再往后真正的护城河。



他还给了一组再往后让人意外的数据。最贵的几轮对话不是发生在处理复杂任务的时候，而是发生在批量任务里。他原来为了让 Claude 同时处理多个独立任务，会把好几个子任务打包到同一个会话里。批量打包看起来省了启动开销，但实际账单拉出来一看，批量会话的成本是单任务会话的 1.4 倍。原因同样出在重新读取那一步，批量会话的历史记录更长，重新读取的 token 也更多。



他自己总结出来的经验有三条。首条条是尽量避免长会话，能拆开的任务就拆成多个短会话，每个会话不要超过 50 轮。再往后一条条是不要批量打包任务，每个独立任务单独起会话，虽然启动开销会重复，但总账算下来反而更便宜。再加一条条是把已经处理完的任务状态写到外部存储里，让新会话从外部存储里读上下文，而不是从对话历史里读。换个视角从行业外的普通人看这件事，给到的启发其实很简单，先想清楚自己最在意哪个具体环节，再围绕这个环节去搭建整个体系。比起一上来就追求全链路覆盖，从一个具体的痛点切入往往更现实。



这三条经验对于正在用 Claude 做生产环境的团队来说非常具体。他在文章里附了一张曲线图，横轴是会话轮数，纵轴是单轮 token 消耗。从图上能看到曲线在第 50 轮到第 80 轮之间有一段明显的拐点，过了拐点之后成本上升速度明显加快。他建议工程团队把拐点位置作为一个工程指标，长期监控。一旦单会话轮数超过拐点，就自动提醒用户考虑拆会话。把这件事放在整个行业生态里看，其实是再往后容易出现的一种规律，能抓住这个节奏的团队通常会比同行跑得更稳。



这篇帖子发出去以后，HN 上有不少团队跟帖说自己也观察到类似的现象。一个做客户支持的团队说，他们原本一个客服会话能持续 200 多轮，接入 lordbron 的成本曲线分析以后，他们强制规定每个会话最多 100 轮，超出就转人工。再往后单次客服对话的平均成本下降了 32%，客户满意度反而上升了 4 个百分点。把视野放宽一点看，这种做事方式的本质其实是把不确定性变成可量化的指标。能清楚衡量每一项决策的成本与收益，是判断团队成熟度的最直观标准。



这条经验背后其实是一个更普适的道理，AI 工具的成本曲线不是线性的，长会话看似省了启动开销，但累积起来的重新读取成本会反噬整体收益。能看清楚这条曲线拐点在哪里，是 AI 工具真正能落地的关键。换个视角从行业外的普通人看这件事，给到的启发其实很简单，先想清楚自己最在意哪个具体环节，再围绕这个环节去搭建整个体系。比起一上来就追求全链路覆盖，从一个具体的痛点切入往往更现实。



创业找资源，上乌鸦部落。