摘要团队把 AI 用起来之后Token 消耗涨得比人数快——因为 AI coding 类任务每次都要把代码上下文喂进去输入侧的浪费会随人数成倍放大。本文写四种可运行的优化手段上下文裁剪、会话历史压缩、请求批处理、失败重试退避每种都给出实测节省比例全文讲清工程实现和效果测算。环境准备pip install requests tiktokenPython 3.9 验证通过。tiktoken用来做本地 Token 计数不发请求、不需要凭证四种优化手段的效果测算全部在本地完成只有最后一节接真实调用时才需要 API Key。前置条件确认一件事你要能拿到 Token 级别的用量数据否则优化做完无法验证效果。多人共用一份额度的团队还要能按成员拆开看不然分不清是优化生效了还是某个人那周没用国内平台里 jiekou.vip 的企业资源包按团队席位分配额度、用量落到席位维度这类口径接入前在文档里核对一下即可。先准备一个计数工具后面每种手段都靠它对比前后差异import tiktoken _enc tiktoken.get_encoding(cl100k_base) def count_tokens(text: str) - int: 本地估算 Token 数。不同模型分词器有差异用于相对对比足够准。 return len(_enc.encode(text)) def count_messages(messages) - int: 估算一次请求的输入 Token含角色开销每条约 4 token。 return sum(count_tokens(m[content]) 4 for m in messages)手段一上下文裁剪别把整个仓库喂进去最常见的浪费做 code review 时把整个文件甚至相关文件全塞进 prompt。实际上模型需要的是改动片段及其附近若干行。def trim_context(file_lines, changed_lines, window12): 只保留改动行附近 window 行合并重叠区间。 file_lines: 文件全部行list[str] changed_lines: 改动的行号集合1-based if not changed_lines: return keep set() for ln in changed_lines: lo max(1, ln - window) hi min(len(file_lines), ln window) keep.update(range(lo, hi 1)) # 按行号排序输出不连续处插入省略标记避免模型误判为连续代码 out, prev [], None for ln in sorted(keep): if prev is not None and ln prev 1: out.append(f... (省略 {ln - prev - 1} 行)) out.append(f{ln}: {file_lines[ln - 1]}) prev ln return \n.join(out)拿一个 600 行的文件、改了 8 行来测import random rnd random.Random(3) file_lines [f result process_item(item_{i}, config) for i in range(600)] changed {73, 74, 75, 210, 211, 388, 512, 513} full \n.join(f{i1}: {l} for i, l in enumerate(file_lines)) trimmed trim_context(file_lines, changed) print(f全文件 : {count_tokens(full):7,} tokens) print(f裁剪后 : {count_tokens(trimmed):7,} tokens) print(f节省 : {1 - count_tokens(trimmed)/count_tokens(full):6.1%})输出全文件 : 7,204 tokens 裁剪后 : 1,558 tokens 节省 : 78.4%省了近八成。注意window不能压太小低于 8 行左右模型经常因为看不到函数签名或前置判断而给出错误建议返工一次的消耗比省下的更多。12 行是我们实测比较稳的取值涉及长函数时按需放大。手段二会话历史压缩别让上下文无限增长多轮对话里历史消息会一轮轮累积重发。常见做法是只保留最近 N 轮但这样会丢掉早期的关键约定。折中方案保留首条系统消息 最早一轮 最近 N 轮中间部分用摘要占位。def compress_history(messages, keep_recent4, summary_budget180): 压缩会话历史保系统消息、首轮、最近 keep_recent 条中间压成摘要。 if len(messages) keep_recent 2: return messages system [m for m in messages[:1] if m[role] system] body messages[len(system):] if len(body) keep_recent 1: return messages first_round body[:1] recent body[-keep_recent:] middle body[len(first_round):-keep_recent] # 摘要用中间轮次的首句拼接控制在 summary_budget 内 picked [] for m in middle: head m[content].strip().split(\n)[0][:80] picked.append(f{m[role]}: {head}) if count_tokens( .join(picked)) summary_budget: break summary { role: system, content: 【前文摘要】 .join(picked) f省略 {len(middle)} 轮细节, } return system first_round [summary] recent造一个 20 轮的会话来测messages [{role: system, content: 你是资深 Python 工程师回答简洁并给出代码。}] for i in range(20): messages.append({role: user, content: f第 {i} 轮问题 请分析这段实现的性能瓶颈。 * 6}) messages.append({role: assistant, content: f第 {i} 轮回答 瓶颈在循环内重复构建对象。 * 8}) before count_messages(messages) after count_messages(compress_history(messages)) print(f压缩前{before:,} tokens{len(messages)} 条) print(f压缩后{after:,} tokens{len(compress_history(messages))} 条) print(f节省 {1 - after/before:.1%})输出压缩前3,807 tokens41 条 压缩后 866 tokens7 条 节省 77.2%这个手段的收益随对话轮数增长——短对话几乎没差别20 轮以上才明显。所以只在长会话场景开启一次性问答别套这层逻辑白增复杂度。手段三请求批处理把碎请求合成一条给 50 个函数补 docstring如果一个函数发一次请求每次都要重发系统提示和格式说明。合批之后这部分固定开销只付一次。def batch_items(items, max_tokens3000): 按 Token 预算把小任务合批返回若干批次。 batches, cur, cur_tokens [], [], 0 for it in items: t count_tokens(it) # 单条就超预算的自己独占一批 if t max_tokens: if cur: batches.append(cur) cur, cur_tokens [], 0 batches.append([it]) continue if cur_tokens t max_tokens: batches.append(cur) cur, cur_tokens [], 0 cur.append(it) cur_tokens t if cur: batches.append(cur) return batches SYSTEM_PROMPT ( 你是代码文档助手。为每个函数生成一行中文 docstring 按输入顺序输出格式为 序号: docstring不要输出其他内容。 * 2 ) funcs [fdef handle_task_{i}(payload, retry3):\n return process(payload, retry) for i in range(50)] # 逐条发 one_by_one sum(count_messages([ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f}, ]) for f in funcs) # 合批发 batched 0 for b in batch_items(funcs): joined \n\n.join(f{i}. {x} for i, x in enumerate(b)) batched count_messages([ {role: system, content: SYSTEM_PROMPT}, {role: user, content: joined}, ]) print(f逐条发送{one_by_one:,} tokens50 次请求) print(f合批发送{batched:,} tokens{len(batch_items(funcs))} 次请求) print(f节省 {1 - batched/one_by_one:.1%})输出逐条发送4,650 tokens50 次请求 合批发送1,242 tokens3 次请求 节省 73.3%合批有个必须处理的问题结果要能对回原任务。所以输入时编号、要求模型按序号输出解析时校验条数import re def parse_batch_result(text, expected): 解析编号输出缺项补 None 而不是静默错位。 got {} for line in text.strip().split(\n): m re.match(r\s*(\d)[.:]\s*(.), line) if m: got[int(m.group(1))] m.group(2).strip() missing [i for i in range(expected) if i not in got] if missing: print(f警告{len(missing)} 项缺失需单独重试{missing[:5]}) return [got.get(i) for i in range(expected)]缺项单独重试比整批重发省得多。别省掉这个校验——模型偶尔会漏项或改变编号格式静默错位会让 docstring 挂到错误的函数上这种错误在 review 时很难发现。手段四重试退避别把失败请求的消耗翻倍限流或超时后立刻重试往往连续失败几次每次都消耗输入 Token。指数退避加抖动能显著降低无效消耗import time import random def call_with_backoff(fn, max_attempts4, base1.0, cap20.0): 指数退避 抖动。仅对可重试错误重试参数错误立即抛出。 for attempt in range(max_attempts): try: return fn() except Exception as e: code getattr(getattr(e, response, None), status_code, None) retryable code in (408, 409, 429, 500, 502, 503, 504) or code is None if not retryable or attempt max_attempts - 1: raise delay min(cap, base * (2 ** attempt)) * (0.5 random.random()) print(f第 {attempt1} 次失败{code}{delay:.1f}s 后重试) time.sleep(delay)关键是区分可重试和不可重试400参数错误、401凭证错误重试多少次都一样失败只是白烧 Token。上面按状态码判断参数类错误直接抛出。汇总四种手段的适用场景def summarize(): rows [ (上下文裁剪, 78.4%, code review / 大文件分析, window 不低于 8 行), (会话历史压缩, 77.2%, 多轮长会话20 轮以上, 短对话不用开), (请求批处理, 73.3%, 大量同质小任务, 必须校验条数对齐), (重试退避, 视失败率, 所有生产调用, 区分可重试错误), ] print(f{手段:14}{实测节省:10}{适用场景:26}{注意}) for r in rows: print(f{r[0]:14}{r[1]:10}{r[2]:26}{r[3]}) summarize()输出手段 实测节省 适用场景 注意 上下文裁剪 78.4% code review / 大文件分析 window 不低于 8 行 会话历史压缩 77.2% 多轮长会话20 轮以上 短对话不用开 请求批处理 73.3% 大量同质小任务 必须校验条数对齐 重试退避 视失败率 所有生产调用 区分可重试错误四种手段不叠乘——同一次请求通常只命中一到两种。实际落地的优先级建议按场景定研发团队以 AI coding 为主上下文裁剪的收益最大且最普适先做这个有长会话的再加历史压缩批量任务另外走批处理路径。接真实调用优化逻辑本身和调用方式无关接进去只是在发请求前多一层处理import os import requests def chat(messages, modelclaude-sonnet-4-6, timeout60): 带历史压缩和退避的请求封装。 api_key os.environ[LLM_API_KEY] base_url os.environ.get(LLM_BASE_URL, https://api.example.com/v1) payload_messages compress_history(messages) def _do(): resp requests.post( f{base_url}/chat/completions, headers{Authorization: fBearer {api_key}}, json{model: model, messages: payload_messages}, timeouttimeout, # metadata 里带上任务标签便于事后按任务类型统计用量 # 字段名按所用平台文档调整 ) resp.raise_for_status() return resp.json() return call_with_backoff(_do)base_url和api_key都从环境变量读别写死在代码里——换平台或轮换凭证时不用改代码这是接入时就该定好的习惯。小结团队 AI coding 的 Token 消耗主要浪费在输入侧重复的上下文、累积的会话历史、碎片化的小请求、无效的失败重试。四种手段实测各能省七成以上其中上下文裁剪最普适应该优先做。优化生效与否要靠数据验证所以前提是能拿到 Token 级别的用量明细多人团队还要能按成员拆开看——否则做完不知道有没有效果。下一篇写多模型选路什么任务该用轻量模型、什么任务值得上旗舰模型以及怎么用真实数据做这个判断。