7.6
深览指数
科技Bestblogs·腾讯云开发者··AI 生成
真正烧 Token 的不是代码，而是模型反复看同一份上下文
本文基于 DevFlow 多 Agent 研发工作流实践，揭示了长上下文在多轮请求中被反复携带是 Token 消耗被放大的核心根因，而非代码本身。作者系统阐述了四层优化方案：信息生命周期治理（短生命周期Agent、按需加载）、响应级批量、工具级批量编辑 replace_batch、Hook降级机制。通过两个模型在真实需求上的量化验证，Developer和Test Engineer阶段Token消耗分别下降26.58%-62.94%和35.05%-50.47%。文章将人工经验沉淀为规则引擎的思想具有可复用价值，适合从事AI Agent系统开发与成本优化的工程师阅读。原文 ↗
核心观点
- ▍长上下文在多轮请求中被反复携带是 Token 消耗放大的核心根因，而非代码本身。放大公式为：已有长上下文 × 额外模型请求。
- ▍核心 Harness 设计原则：模型擅长判断应该做什么，工具和运行时负责稳定执行。
- 01DevFlow 中 Developer 的上下文达到 120K tokens，即使修改只有几十行代码，也会因多轮请求而反复携带长上下文。
- 02代码探索改为短生命周期 Code Explorer，只返回约 500 字的结构化摘要，原始搜索结果随 Agent 生命周期结束而退出。
- 03replace_batch 工具支持同一文件多处修改和多文件修改，通过原始快照、预校验、事务写入和失败回滚保证一致性。
- 04Hook 机制中 PreToolUse Hook 探活成功则阻断单点编辑，探活失败或超时则 fail-open 允许原生编辑降级执行。
- 05在涉及 6 个 HTTP 接口改造的真实需求中，Claude Opus 5 的 Test Engineer 单阶段 Token 下降 35.05%，Developer 下降 26.58%；GLM 5.2 的 Developer 下降 62.94%，Test Engineer 下降 50.47%。完整流程 Token 分别下降 25.69% 和 41.95%。
反方 / 局限
- — 两个模型的优化方向一致，但绝对幅度差别大，不适合写成固定收益承诺。
- — 批量不是越大越好，批次边界由'这些修改能否基于同一份代码状态同时确定和验证'决定，强行合并未确定或相互依赖的修改会降低成功率。
6 分钟 · 4 卡片 · 8 资料
读原文 →