Agent 越聊越笨?我把上下文修剪了一下,token 砍了 50%,质量反而涨了 Agent 越聊越笨我把上下文修剪了一下token 砍了 50%质量反而涨了用 5 分钟改几行代码省一半的 API 费用。这是上下文工程里 ROI 最高的策略——没有之一。先说结论你花钱买的 token一半在喂 AI 吃垃圾我诊断过 47 个 Agent 项目的上下文——包括我自己的。平均下来上下文内容构成平均值 ├── 真正有用的信息 ████████░░░░░░░░ 42% ├── 过时的对话历史 ████░░░░░░░░░░░░ 23% ├── 用不到的工具定义 ███░░░░░░░░░░░░░ 15% ├── 冗余的系统提示词示例 ██░░░░░░░░░░░░░░ 12% └── 重复的格式/安全约束 ██░░░░░░░░░░░░░░ 8% ────────────── 58% 是垃圾GPT-4o 每百万 token 约 $2.5-15DeepSeek 约 ¥1-2。你每一次调用都在为那 58% 的垃圾付全款。而修剪Pruning就是专治这 58%。修剪什么、怎么剪、省多少一张表修剪对象具体操作省 token风险优先级对话历史-中间轮次保留首轮 最近 10 轮其余做摘要40-60%低 最高系统提示词-冗余示例2 个示例删成 1 个15-25%极低 最高未使用的工具定义看日志删掉从没调过的工具10-30%中需确认无用 高重复安全/格式约束“你必须用中文”“请用中文回答”语言中文→ 只留一处5-10%极低 高已解决的中间步骤Agent 推理过程CoT只保留最终结论20-30%中 中工具输出的冗余字段取 JSON 的关键字段删掉 metadata/timestamp 等15-25%低 中实操5 分钟改造一个 LangChain Agent改造前典型烂代码fromlangchain.promptsimportChatPromptTemplate# 系统提示词1800 token塞了一堆用不到的东西system_prompt 你是一个专业的客服 Agent。你的职责是帮助用户解决问题。 ## 角色定义 你是 XX 公司的智能客服你的名字叫小智。你的语气要亲切、专业、有耐心。 如果用户骂你你要保持冷静。如果用户问超出范围的问题你要礼貌地拒绝。 ...此处省略 800 字角色设定... ## 示例这里塞了 3 个 Few-shot 示例占了 600 token 示例 1用户问怎么退款→ 回答请提供订单号我帮您查询退款进度... 示例 2用户问物流到哪了→ 回答请提供运单号我帮您查询物流状态... 示例 3用户问优惠券怎么用→ 回答在结算页面输入优惠码即可使用如有问题我帮您手动处理... ## 工具列表5 个工具全量列出每个 200 token 1000 token 1. search_order —— 查询订单信息。参数order_id (str)。返回订单详情 JSON。 2. search_logistics —— 查询物流信息。参数tracking_number (str)。返回物流状态 JSON。 3. apply_refund —— 申请退款。参数order_id (str), reason (str)。返回退款结果。 4. check_coupon —— 查询优惠券。参数coupon_code (str)。返回优惠券状态。 5. escalate_human —— 转接人工客服。参数summary (str)。返回转接结果。 ## 安全约束重复了 3 遍占了 200 token 绝对不能泄露用户的个人信息。绝对不能执行退款以外的资金操作。绝对... # 对话历史无差别全量保留messagessystem_promptchat_history[-50:][user_query]# ↑ 50 轮历史 平均 12000 token改造后修剪版# 系统提示词砍到 400 tokensystem_prompt 你是 XX 公司客服 Agent。用亲切、专业的语气帮助用户。 超出范围的问题礼貌拒绝。 ## 核心示例 用户怎么退款 → 你请提供订单号我帮您查退款进度 ## 可用工具仅列名 一句话完整定义在调用时展开 - search_order: 查订单 - search_logistics: 查物流 - apply_refund: 退款 - check_coupon: 查优惠券 - escalate_human: 转人工 ## 安全红线 不泄露用户个人信息不执行退款外的资金操作。 # 1800 token → 400 token省了 78%# 对话历史修剪defprune_history(messages,keep_first1,keep_last10):iflen(messages)(keep_firstkeep_last)*2:returnmessages# 始终保留首轮任务定义firstmessages[:keep_first*2]# 保留最近 10 轮recentmessages[-keep_last*2:]# 中间轮次 → 一句话摘要middlemessages[keep_first*2:-keep_last*2]ifmiddle:summaryllm.invoke(将以下对话压缩为一句话摘要只保留关键信息用户偏好、已做决策、待处理事项format_messages(middle))middle[HumanMessage(contentf[历史摘要]{summary})]returnfirstmiddlerecent messages[system_prompt]prune_history(chat_history)[user_query]# 平均 12000 token → 约 5000 token省了 58%修剪前后对比实测数据用同一个客服场景跑 20 轮对话对比结果指标修剪前修剪后变化平均每轮输入 token12,4005,100-59%第 1 轮回答准确率96%94%-2%第 10 轮回答准确率74%91%17%第 20 轮回答准确率51%88%37%20 轮总 API 费用$0.87$0.36-59%平均响应延迟4.2s1.8s-57%省了钱、提了质、还快了。这就是修剪的威力。三个常见修剪错误我踩过的坑❌ 错误 1把首轮也剪了首轮对话通常包含用户的核心需求和约束条件——我要一个支持深色模式的登录页这句话一旦被剪掉后面全歪。首轮永远保留。❌ 错误 2一刀切保留最近 5 轮如果用户在第 6 轮说了一句关键信息“把端口改成 8080”第 7 轮就被剪掉了。至少保留最近 10 轮。❌ 错误 3摘要太粗糙中间轮次做摘要时如果只压成用户问了几个问题等于没压。摘要必须保留用户偏好、已做决策、待处理事项——这三个维度的信息。# ❌ 渣摘要用户咨询了订单和物流相关问题Agent 做出了回复。# ✅ 好摘要用户偏好退款到支付宝而非微信。已做决策订单 #12345 已退款成功。待处理物流 #SF888 状态异常需跟进。修剪检查清单贴在你显示器上每当你准备部署 Agent 之前跑一遍这个清单系统提示词 ≤ 500 tokenFew-shot 示例只留 1 个工具定义只列名称 一句话安全/格式约束只说一次对话历史只保留首轮 最近 10 轮中间轮次做了结构化摘要偏好 决策 待办工具输出 JSON 只取了关键字段前 4 项是免费的改配置就行后 3 项加起来不到 30 行代码。下一步修剪只是上下文工程的第一个策略——也是 ROI 最高的。但如果你的 Agent 还遇到了以下问题RAG 召回了 20 个文档答案反而不如 3 个准 → 你需要压缩工具太多大部分从不调用 → 你需要动态装载Agent 被之前的错误带偏 → 你需要隔离这些都在「上下文工程诊断优化器」里SkillHub或天禧AI 技能集市搜索下载5 分钟自动诊断输出完整优化方案。也可以关注我下一篇讲《RAG 召回 20 个文档不如 3 个上下文压缩的 3 种姿势》。作者aigeek_laogao10 年 AI/架构经验诊断过 47 个 Agent 项目的上下文专注大模型应用落地。有问题评论区说出你的 Agent 在第几轮开始变笨——我帮你看看。