智能摘要
Agent 与简单调用大模型API的根本区别在于对话多轮下的上下文管理问题：当轮次增多导致 token 超出模型窗口时，核心不是删减信息而是按价值进行取舍以避免“贵、慢、不准”。解决方案是对历史消息按复用概率分类并打分（用户指令、关键决策、任务状态、时间衰减等），在触及窗口80%阈值时对高分保留原文、中分生成摘要、低分激进压缩或丢弃，同时预留约20% token 用于摘要自身以防溢出。实践数据表明：100轮对话中采用周期性摘要可将token消耗从约500万降至305万（节省约40%），且用小模型执行摘要能进一步降低成本；工程挑战集中在信息价值评估、预算分配、多轮摘要质量控制与触发时机优化。
— 此摘要由AI生成仅供参考。
面试中常被质疑 “Agent 只是调大模型 API”，但实际落地面临关键挑战：当对话轮次增加（如 50 轮），上下文 token 超过模型窗口（如 128K）时，需解决信息取舍问题，而非简单删除或全量发送。
大语言模型上下文窗口存在硬限制（常见 128K-20 万，Gemini 达 100 万），但实际交互中：
- 固定开销：System Prompt + 工具说明约 4000 tokens
- 动态开销：每轮对话（输入 + 输出）500-2000 tokens、Agent 思考过程 200-1000 tokens、工具调用记录 200-500 tokens
- 50 轮交互后易突破窗口限制，导致三大痛点：API 成本高、首 token 延迟慢、模型 Lost in the Middle（中间信息丢失）问题，最终体现为 “贵、慢、不准”。
根据信息复用概率，历史消息分为四类，处理方式不同：
- 用户指令（如 “帮我写支持代理的爬虫”）：原文保留，不压缩。
- 关键状态（如 “已完成登录模块，下一步大数据解析”）：结构化摘要。
- 中间推理（如 “先试方案 a，不行换方案 b”）：激进摘要，仅保留结论。
- 失败记录（如 “用 request 库报错 403”）：保留失败原因，删除过程。
核心思路是对每条消息打分，按分数决定处理方式：
- 打分规则：用户指令（0.4 分）、包含关键决策（0.3 分）、任务状态变更（0.2 分）、时间衰减（0.1 分）。
- 处理逻辑：当上下文 token 超过阈值（如窗口的 80%）触发摘要：
-
- 高分（>0.6）：保留原文；
-
- 中分（0.3-0.6）：生成摘要；
-
- 低分（<0.3）：激进压缩或丢弃。
- 摘要时机：触发阈值设为窗口的 80%，预留 20% token 用于摘要本身（摘要 prompt 约 2000 tokens，输出 1-2000 tokens），避免摘要过程撑爆窗口。
- 成本对比：100 轮对话下，不做摘要累计 500 万 tokens，做摘要累计 305 万 tokens（含 10 次摘要调用），节省 40%；若用小模型（如 GPT-4o-mini）做摘要，成本更低。
- 信息价值评估：定义 “有价值信息”，非简单删除。
- Token 预算分配：有限资源下的最优分配策略。
- Token 质量控制：多轮摘要可能导致信息失真，需校验机制。
- 触发时机优化：平衡成本与效果。
- 类比：上下文管理类似 OS 的虚拟内存管理，是复杂的工程系统难题。
文章评论