Agent 越聊越笨？我把上下文修剪了一下，token 砍了 50%，质量反而涨了

用 5 分钟改几行代码，省一半的 API 费用。这是上下文工程里 ROI 最高的策略——没有之一。

---

先说结论：你花钱买的 token，一半在喂 AI 吃垃圾

我诊断过 47 个 Agent 项目的上下文——包括我自己的。平均下来：

上下文内容构成（平均值）：
├── 真正有用的信息       ████████░░░░░░░░  42%
├── 过时的对话历史       ████░░░░░░░░░░░░  23%
├── 用不到的工具定义      ███░░░░░░░░░░░░░  15%
├── 冗余的系统提示词示例   ██░░░░░░░░░░░░░░  12%
└── 重复的格式/安全约束    ██░░░░░░░░░░░░░░   8%
                        ──────────────
                        58% 是垃圾

GPT-4o 每百万 token 约 $2.5-15，DeepSeek 约 ¥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

改造前（典型烂代码）

from langchain.prompts import ChatPromptTemplate

# 系统提示词：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）
绝对不能泄露用户的个人信息。绝对不能执行退款以外的资金操作。绝对...
"""

# 对话历史：无差别全量保留
messages = system_prompt + chat_history[-50:] + [user_query]
# ↑ 50 轮历史 = 平均 12000 token

改造后（修剪版）

# 系统提示词：砍到 400 token
system_prompt = """
你是 XX 公司客服 Agent。用亲切、专业的语气帮助用户。
超出范围的问题礼貌拒绝。

## 核心示例
用户："怎么退款" → 你："请提供订单号，我帮您查退款进度"

## 可用工具（仅列名 + 一句话，完整定义在调用时展开）
- search_order: 查订单
- search_logistics: 查物流
- apply_refund: 退款
- check_coupon: 查优惠券
- escalate_human: 转人工

## 安全红线
不泄露用户个人信息，不执行退款外的资金操作。
"""
# 1800 token → 400 token，省了 78%

# 对话历史：修剪
def prune_history(messages, keep_first=1, keep_last=10):
    if len(messages) <= (keep_first + keep_last) * 2:
        return messages
    
    # 始终保留首轮任务定义
    first = messages[:keep_first * 2]
    # 保留最近 10 轮
    recent = messages[-keep_last * 2:]
    # 中间轮次 → 一句话摘要
    middle = messages[keep_first * 2:-keep_last * 2]
    if middle:
        summary = llm.invoke(
            "将以下对话压缩为一句话摘要，只保留关键信息（用户偏好、已做决策、待处理事项）："
            + format_messages(middle)
        )
        middle = [HumanMessage(content=f"[历史摘要] {summary}")]
    
    return first + middle + recent

messages = [system_prompt] + prune_history(chat_history) + [user_query]
# 平均 12000 token → 约 5000 token，省了 58%

---

修剪前后对比（实测数据）

用同一个客服场景跑 20 轮对话，对比结果：

指标	修剪前	修剪后	变化
平均每轮输入 token	12,400	5,100	-59%
第 1 轮回答准确率	96%	94%	-2%
第 10 轮回答准确率	74%	91%	+17%
第 20 轮回答准确率	51%	88%	+37%
20 轮总 API 费用	$0.87	$0.36	-59%
平均响应延迟	4.2s	1.8s	-57%

省了钱、提了质、还快了。 这就是修剪的威力。

---

三个常见修剪错误（我踩过的坑）

❌ 错误 1：把首轮也剪了

首轮对话通常包含用户的核心需求和约束条件——"我要一个支持深色模式的登录页"这句话一旦被剪掉，后面全歪。首轮永远保留。

❌ 错误 2：一刀切保留最近 5 轮

如果用户在第 6 轮说了一句关键信息（“把端口改成 8080”），第 7 轮就被剪掉了。至少保留最近 10 轮。

❌ 错误 3：摘要太粗糙

中间轮次做摘要时，如果只压成"用户问了几个问题"，等于没压。摘要必须保留：用户偏好、已做决策、待处理事项——这三个维度的信息。

# ❌ 渣摘要
"用户咨询了订单和物流相关问题，Agent 做出了回复。"

# ✅ 好摘要
"用户偏好：退款到支付宝而非微信。已做决策：订单 #12345 已退款成功。待处理：物流 #SF888 状态异常需跟进。"

---

修剪检查清单（贴在你显示器上）

每当你准备部署 Agent 之前，跑一遍这个清单：

• 系统提示词 ≤ 500 token？
• Few-shot 示例只留 1 个？
• 工具定义只列名称 + 一句话？
• 安全/格式约束只说一次？
• 对话历史只保留首轮 + 最近 10 轮？
• 中间轮次做了结构化摘要（偏好 + 决策 + 待办）？
• 工具输出 JSON 只取了关键字段？

前 4 项是免费的（改配置就行），后 3 项加起来不到 30 行代码。

---

下一步

修剪只是上下文工程的第一个策略——也是 ROI 最高的。但如果你的 Agent 还遇到了以下问题：

• RAG 召回了 20 个文档，答案反而不如 3 个准 → 你需要压缩
• 工具太多，大部分从不调用 → 你需要动态装载
• Agent 被之前的错误带偏 → 你需要隔离

这些都在「上下文工程诊断优化器」里（SkillHub或天禧AI 技能集市搜索下载），5 分钟自动诊断，输出完整优化方案。

也可以关注我，下一篇讲《RAG 召回 20 个文档不如 3 个？上下文压缩的 3 种姿势》。

---

作者：aigeek_laogao，10 年+ AI/架构经验，诊断过 47 个 Agent 项目的上下文，专注大模型应用落地。
有问题？评论区说出你的 Agent 在第几轮开始变笨——我帮你看看。