你的 Agent 每跑一步都在烧钱？一篇论文告诉你怎么把 100 万 Token 压到 6 万
目录
- 你的 Agent 每跑一步都在烧钱？一篇论文告诉你怎么把 100 万 Token 压到 6 万
- 一个让你心疼钱包的场景
- 一篇最近很火的论文说：你确实不需要
- 核心洞察，一句话
- ReAct vs. SKILL.state：书包 vs. 便利贴
- 关键机制：patch 而不是重写
- 三个反直觉的关键点
- ① "把推理痕迹扔了，模型不会变笨吗？"
- ② "为啥不用 summary / 压缩历史？"
- ③ "这不就是数据库/程序变量吗？"
- 你现在的架构，处在哪一档？
- 什么时候你**真会**用得上
- 一个可能被忽略的隐性代价
- 深一层的思考：LLM 到底该是什么
- 我的判断
一个让你心疼钱包的场景
假设你正在写一个 Agent，让它帮你跑 100 步的仓库管理任务：收单、分配、发货、盘点、退货……
跑到第 100 步，你打开日志，看到最新一次 LLM 调用的 prompt 长这样：
[system] 你是一个仓库管理员... [obs_1] 收到订单 O_001, SKU_A × 5 [thought_1] 检查库存，SKU_A 还有 50 件，可以分配... [action_1] allocate(O_001, BAY_2) [obs_2] BAY_2 分配成功 [thought_2] 现在处理下一个... ...（略过 96 步，节约你的滚轮）... [obs_100] 收到退货申请 R_045 [thought_100] 让我在前面找找 R_045 对应的订单......Prompt 长度：约 31,000 tokens。
这一步的费用：让我们算算——Claude Opus 输入 15 美元/百万，一步就是0.46 美元。
跑完 100 步累计：约 106 万 tokens，约 15 美元一次任务。
如果这只是一次线上流程，你要跑 1 万次，就是15 万美元。
有没有一种可能，你根本不需要把那 100 步的历史每次都塞进去？
