技术 · 熟练
工具返回的那一坨，别让它住进上下文
让 agent 写代码去分析数据，而不是读数据
agent 的上下文不是被「对话」撑爆的，多半是被工具的返回撑爆的 —— 一次 Playwright 快照 56 KB、二十个 issue 59 KB、跑半小时吃掉几万 token，而那些原始数据往往只用过一次。这一页给的是同一条纪律的两个面：一是把工具输出关进沙箱（原始数据留在子进程 / 索引里，只把提炼后的结果带回上下文）；二是把「读数据」改成「算数据」—— 需要看一大块内容时，让 agent 写一小段代码去分析，而不是把整份内容读进窗口。社区实测的量级是从 315 KB 压到 5.4 KB。
方法 · 一图看懂
1
先量体量，再谈优化 — 记录每个工具调用的返回大小，找出「一次用、长期占」的那几个
2
拦截在入口 — 在 MCP / hooks 层拦下返回，原始数据留在沙箱不进窗口
3
改「读」为「算」 — 要看大块数据时写代码去分析，只把结论带回上下文
4
结果要可寻回 — 沙箱里的原始数据留索引或会话记忆，需要时能按引用取回
5
只在真需要时分离 — 小返回不值得包一层，别把沙盒变成新的负担
原理 · 为什么有效
上下文窗口的稀缺性不在「能装多少」，而在装进去的东西会稀释注意力。原始日志、整份 DOM、几十条 issue 的正文，属于「一次性事实」—— 你只需要从里面得到一个判断，却把整份原料留在了窗口里。这跟压缩不同：压缩是事后补救，而沙盒化是事前不让它进来。判据很简单：这份数据是「要在推理里反复看的」，还是「看一眼得出结论就丢的」？后者一律走沙盒。
适用场景
适用：跑自动化 / 抓取 / 日志 / 代码库探索的 agent；工具返回动辄几十 KB 的场景；上下文费用敏感或频繁触顶的团队。
⛔ 不适用：返回本来就只有几百字节的小工具 —— 包一层拦截只会增加复杂度。
⚠️ 前提：能改到工具调用层（MCP server 或 agent hooks）；纯对话式使用没有这个抓手。
自测 · 5 问
我说得出自家 agent 里返回最大的那个工具调用是哪个、大概多大吗？
那些大返回里，有多少是「结论只用一句、原文却全进了窗口」？
我有没有一个地方，能让 agent 写代码去处理数据、只把结果带回来？
沙箱里被丢下的原始数据，需要时我还能取回吗（索引 / 会话记忆）？
我是不是把所有工具都套了沙盒 —— 包括那些本来就很小、根本不需要的？
怎么上手 · 验证步骤
第一步只做一件事：跑一次日常任务，把每个工具调用的返回大小记下来（多数框架有日志或用量面板）。挑出最大的那一个，只对这一个做沙盒化：把它的原始返回落到子进程或本地索引，只在上下文里留「提炼后的结论 + 一个可寻址的引用」。跑完对照两件事 —— 上下文占用降了多少、结论质量有没有变差。一个工具验证有效再铺开，不要一次性给所有调用套壳。
自检动作：在下一次长任务结束后，看两个数 —— ① 工具返回占上下文的峰值 ② 最终答案里真正用到原始数据的比例。第一个数明显下降、第二个数没变，说明这一步做对了；如果答案开始丢细节，说明沙盒放错了层。