Agent 一接 MCP 大结果集就开始失忆：从 Result Summarization 到 Cursor Paging 的工程实战

一、MCP 一接大结果集Agent 最先坏掉的不是推理而是记忆 很多团队把 MCP 当成 Agent 的万能扩展层只要把数据库、工单、代码检索、指标平台都挂进去模型就能“边查边做”。真正上线后最先暴露的问题却很一致一次工具调用返回几百条记录时Agent 并不是不会查而是会在后续轮次里逐步失忆。它前一轮还记得对象 ID后一轮就开始把状态、负责人、更新时间串在一起。⚠️这类故障最常见于列表检索、日志搜索、工单中心和对象存储目录。返回结果越多模型越容易把“看过很多信息”误当成“已经掌握关键信息”。真正丢失的往往是下一步动作最关键的定位字段比如主键、版本号、tenant、cursor 或最后更新时间。图 1MCP 工具一旦返回大结果集问题会从检索层迅速传导到执行层二、根因不在上下文长短而在“结果表达”没有做工程收敛 很多人第一反应是换长上下文模型实际收益很有限。大结果集故障通常不是“放不下”而是“没有分层表达”。MCP 工具把原始 JSON、长日志、字段冗余对象直接塞给模型相当于把数据库扫描结果原样扔进思考链路。模型看到的是海量近似片段不是可执行证据。更糟的是结果集如果没有稳定排序和游标边界Agent 下一轮再翻页时很容易把新旧页面混在一起。于是它明明引用了同一个列表却在第 2 次和第 3 次回答里给出不同结论。这不是幻觉问题而是分页协议和摘要协议都没立住。失稳点典型表现直接后果原始结果过长大段 JSON / 日志直接返回关键信息被噪声淹没无字段裁剪同时暴露 20 字段模型抓错主键或状态无游标协议翻页只靠“下一页”新旧结果串页无摘要锚点每轮重新读全量结论漂移、重复查找[外链图片转存中…(img-1wtfGvqg-1779358485951)]图 2分页不稳定时Agent 的结论会随翻页过程漂移三、实战修法先摘要再分页最后要求对象级确认 ️工程上更稳的做法是把 MCP 返回分成三层第一层只给summary第二层给top_items第三层才开放cursor翻页。模型先根据摘要判断有没有必要继续展开而不是一上来吞全量。✅{summary:{total:428,top_status:[open,pending],latest_updated_at:2026-05-21T09:42:10Z},top_items:[{id:INC-1842,title:MCP timeout,owner:ops-a,updated_at:2026-05-21T09:42:10Z}],next_cursor:eyJvZmZzZXQiOjEwMH0}关键不是把内容“压短”而是把模型真正需要决策的字段提前。比如列表页默认只保留id / title / state / updated_at只有当 Agent 明确声明“继续读取详情”时工具再展开正文、评论、附件或 trace。这样模型不会在第一轮就把注意力浪费在低价值字段上。再往前一步可以要求 Agent 在执行动作前输出对象级确认例如“将操作对象锁定为INC-1842来源于 page 1cursor 版本为eyJv...”。这类确认看上去啰嗦却能显著减少串对象和跨页误操作。图 3结构化摘要先行能把模型注意力锁定到可执行字段四、结果摘要不是压缩文本而是建立“检索到执行”的中间层 笔者认为很多 MCP 失败案例本质上都缺一个中间表示层。工具返回若只分“原始结果”与“最终动作”两档中间没有摘要、游标、字段裁剪和版本锚点模型就只能硬吃全量数据再靠自然语言维持状态。这样在 demo 里能跑到了生产就会反复失忆。更可靠的设计是把result summarization当成协议能力而不是提示词技巧把cursor paging当成一致性边界而不是普通翻页按钮。谁先把 MCP 结果做成可验证、可续读、可引用的对象流谁的 Agent 才能真正接住企业级工具面。接下来 3 到 6 个月MCP 工具层会越来越像数据库驱动层比拼的不是接了多少工具而是谁能把大结果集稳定地压成模型可执行的证据单元。对于正在做企业 Agent 的团队这比单纯换更大模型更值得优先投入。你们现在的 MCP 返回已经有 summary 和 cursor 了吗