Agent 为什么越聊越贵：先删掉这四类上下文

为了从导航站里挑趣味网站，我读取了网站列表接口。完整响应有 315 条记录，序列化后约 102436 个字符；只保留 ID、标题、URL、分类和状态后变成 38380 个字符，减少 62.5%。继续筛到趣味分类的 19 条，只剩 1471 个字符，比完整响应少 98.6%。

三个版本表达的业务事实并没有同比例减少。区别在于，完整响应还带着描述、排序、访问量、图标和检查时间——这些字段对本次选题没有帮助，却会在后续对话中反复占位。

“先了解整个项目”听起来谨慎，实际常把几百个无关文件塞进上下文。更稳的顺序是先按文件名和关键词定位入口，再打开命中区域；需要理解调用链时逐层展开，而不是一次读取整个目录。

这不要求 Agent 永远少读。改认证、权限或数据迁移时，遗漏关联代码代价很高；此时应扩大检索范围。省 Token 应按风险读取，不能统一缩短。

一次构建可能输出几千行，真正需要的是退出状态、错误附近片段和生成页面摘要。搜索接口同样如此：先返回文件名与行号，再读取局部；大 JSON 先筛字段和记录，再交给模型判断。

完整原始输出可以保存为文件，供失败时追查。把“保留证据”和“把证据全部放进对话”分开，往往是最直接的节省。

项目说明、系统提示和用户补充里反复写同一要求，不只增加字符，还可能彼此冲突。稳定规则应有一个权威位置；本轮特殊要求只描述差异。规则发生变化时，更新原位置或明确覆盖关系。

删规则也有风险。把构建、来源核验和权限边界删掉，输入会短一点，却可能换来多轮返工。OpenAI 的成本优化建议同样把模型选择、减少请求、减少 Token 与批处理放在完整工作流里考虑，而不是只盯一次调用。

先改首页，再写文章，又调数据库，最后回头讨论字体，每个新目标都会携带旧历史。阶段完成后，把历史压缩成“决定、改动、证据、待办”，或把真正独立的任务放进隔离上下文，只带回可复用结论。

但不要每两轮就重开。频繁丢弃上下文会让 Agent 重新定位文件、重复阅读规则。合适的切点是目标完成、工作类型改变或历史已经无法压缩，而不是单纯觉得对话变长。

记录输入、缓存输入、输出、调用次数、是否一次通过和人工返工分钟数。一个方案把单次 Token 降了 30%，却让成功率从九成跌到六成，通常只是把账单转成了人的时间。

这次接口实验给出的结论很朴素：先过滤 98.6% 的无关内容，再让模型判断哪几个网站值得打开。优化上下文的第一步，往往是一把愿意提前工作的筛子，提示词技巧排在后面。