每次 AI 编码助手用到后半程我心里都会冒出一阵熟悉的不安它开始反复读同一个文件回答速度肉眼可见地变慢更气人的是它还会把上一轮已经纠正过的错误再次犯一遍。把会话记录翻出来看原因从来都不神秘——上下文里塞满了整段编译日志、没有裁剪的文件内容、连续几轮和当前任务毫无关系的对话。真正的问题从来不是模型不够聪明而是它本来就不多的注意力被无关信息提前耗光了。这就是“上下文浪费”。最近在开发者圈子里看到 Pi Agent Harness 这个项目定位非常直接极简 AI 编码代理、终端优先、告别上下文浪费。这三个词放在一起与其说是一个功能列表不如说是一套关于 AI 编程工具应该怎么设计的判断。这里我不打算复述项目介绍而是想把“上下文浪费”这件事拆开讲清楚它到底浪费在哪、为什么终端优先和极简设计能对症下药以及普通人把它落地到工作流里最该注意什么。1. 先搞清楚“上下文浪费”到底丢掉了什么1.1 上下文不是单纯的 token 数量问题而是注意力分配问题很多开发者聊上下文首先想到的是“窗口有多大”。从社区里常见的提问就能看出来60K 上下文能干什么本地模型的上下文长度怎么看128K、200K、1M 的窗口是不是越大越好我对这些问题的看法比较直接窗口长度是上限不是保证。模型在窗口里做注意力计算时会把预算分散到所有内容上。上下文越长并不意味着模型越“记得住”反而可能是关键信息被稀释。一项任务的答案可能就藏在一个报错栈里、一个函数签名里、一段十行的配置里如果它周围堆了三百行无关日志模型找到它的概率就会下降找到它的成本也会上升。所以上下文管理的核心不是“塞得下”而是“放得对”。哪怕只有 8K 的窗口只要内容全部围绕当前任务效果往往比 128K 窗口里堆满噪音要好。这也是为什么我把“上下文浪费”理解为注意力浪费而不是单纯的 token 浪费。1.2 四种最常见的上下文浪费用过几款 AI 编码助手之后我总结出四类最常出现的浪费源。第一种整文件读取。让模型“看一下这个文件”它就把整个文件塞进上下文。一个 500 行的模块真正和问题相关的可能只有 30 行但其余 470 行全都成了背景噪音。如果这个文件又被读了两三次浪费还会翻倍。第二种日志洪流。调试时最常见。一条错误信息背后往往跟了 200 行堆栈和应用日志模型不得不全部接收。日志里真正有价值的信息通常不到 10%剩下的都是重复的框架输出和上下文无关的运行记录。第三种历史对话膨胀。会话越聊越长模型每轮都要把之前的全部对话重读一遍。前面几个无害的闲聊、几次试探性修改、几个失败方案都会长期占用预算直到把关键信息挤出去。第四种工具回传未裁剪。AI 编码代理不是只靠对话工作它还会调用命令、读取文件、访问 MCP 服务或插件。有些工具会把一次完整的分页查询结果、一个大 JSON、一整张表直接回传给模型。这类“结构化噪音”往往体积最大也最容易被忽略。判断一次上下文是否浪费可以问自己一个问题如果这些内容全部删掉当前这个任务还能不能正常做如果答案是能那它就是浪费。1.3 为什么“自动总结”不能根治问题很多工具已经做了自动总结也就是把前面的对话压缩成摘要再继续新对话。听起来合理但实际用过的开发者应该都有同感摘要会丢细节。模型做总结时会把一些当时觉得不重要、但后面恰恰需要的线索丢掉。更麻烦的是摘要本身也要占上下文而且多轮摘要层层压缩之后信息损耗会叠加。社区里那句“已经进行了多次自动总结但上下文大小仍然超出限制”就是这种情况的真实写照。另外一个被低估的问题是自动总结只处理“已经发生的内容”不能阻止“新的浪费继续进来”。你前脚刚压缩完后脚又让模型读了一个 800 行的文件预算很快又爆了。所以治理上下文不能只靠事后压缩更要靠事前的输入控制。这正是终端优先和极简设计的切入点。2. 终端优先不是风格选择而是一种上下文治理策略2.1 终端是默认的“低噪音”界面很多人看到“终端优先”四个字第一反应是“怀旧”或者“极客范”。我的理解不一样终端优先是一种上下文治理策略。终端界面天然是纯文本的。没有按钮、没有动效、没有自动弹出的面板、没有渲染后的页面截图。这意味着终端里什么内容能进入模型几乎完全由你主动决定。相比之下图形界面工具更容易在不经意间把界面状态、后台事件、当前打开的文件、最近的交互记录一起打包进上下文。这种“顺手带上”的机制就是噪音的来源。2.2 文本接口让每一步都可检查、可过滤、可复用终端优先的另一层价值是它把 Unix 工具链变成了上下文过滤器。你想让模型看一个文件不用把整个文件丢进去而是先用工具定位# 先看目录结构别急着读文件 find src -type f -name *.py | head -20 # 定位关键函数只看那一小段 grep -n def process_order src/order.py sed -n 120,180p src/order.py这段命令虽然朴素但背后是一个很关键的思路先检索再读取先缩小范围再放进上下文。这样的输入在进入模型前就已经被压缩过模型拿到的每一行都是有价值的。这个过程完全可检查、可复用、可记录而且每一步都是确定性的。如果换成一个只靠图形界面和全量读取的工具很难做到这种精细控制。这就是“终端优先”真正打动我的地方它不只是在选一个界面而是在选一种输入治理方式。2.3 控住输入才能控住上下文上下文管理的核心矛盾是你不能控制模型怎么思考但你可以控制模型看到什么。终端优先的最大好处是把“控制输入”这件事从用户的可选项变成了工具的默认状态。打个比方这就像开会。一个高效的会议不是把所有人都拉进群里不停刷消息而是提前发一份议程只让相关人员进来只讨论议题内的事情。上下文对模型来说就是这个“会议室”终端优先则相当于会议纪律什么材料才被允许带进来由你说了算。3. 极简 AI 编码代理的核心设计取舍这里说回 Pi Agent Harness 这类工具的定位。它给自己贴的标签是“极简”这个“极简”不是功能少而是懂得不做多余的事。对一个 AI 编码代理来说不做什么往往比做什么更重要。3.1 不做什么比做什么更重要一个 AI 编码代理最容易犯的错是过度主动。用户刚说“帮我看看这个项目”它就自动扫描全目录、读取所有文件、生成一个宏大的重构计划。看起来很强大实际上是在用一次操作把大量无关内容灌进上下文。极简设计的思路相反默认不读、默认不展开、需要什么才加载什么。模型只有在得到明确指令后才读取某个文件而且读取范围可以通过行号、模式匹配来限制。这样看起来“笨”了一点但换来的是可预期性和低噪音。对编码代理来说可预期比聪明更重要因为上下文预算一旦被浪费再聪明也发挥不出来。3.2 短会话加任务边界让上下文滚动而不是堆积极简设计还体现在会话管理上。传统方式是开一个超长会话把所有任务都往里面堆堆不动了再开新会话说“继续”。问题在于新会话通常会丢失上下文记忆老会话又过于臃肿两边的体验都不好。更合理的做法是任务式会话一个会话只做一个任务任务结束就关闭。跨任务的信息放在外部比如任务说明文件、TODO、commit 信息、设计摘要。这样每个会话启动时上下文都干净聚焦当前目标不用担心历史问题残留。从工程经验看这种“短会话加外部记忆”的方式在长期使用中要比“一条长会话走到底”稳定得多。损失的那点“记住我之前聊过什么”的便利换来的是每次任务的准确性和可控性。3.3 把“上下文工程”下沉到工具层“上下文工程”这个词最近很热指的是一套如何组织、压缩、筛选上下文的方法。很多人在教大家怎么自己管理上下文比如写更精简的提示词、手动清空会话、手动粘贴关键文件片段。这些方法有用但都依赖人的自觉。极简工具的思路是把这些自动做掉一部分。比如自动截断过长的命令输出、只回传 diff 而非完整文件、在接近上下文上限时主动提醒、在会话开始时就指定一个更窄的“注意力范围”。这些能力把上下文工程从“使用者的经验”变成了“工具的默认行为”。这其实是一个更健康的演进方向不是让开发者天天为 token 操心而是让工具主动保护上下文预算。4. 四步实操把“告别上下文浪费”落到工作流里工具是工具真正的效果要看怎么用。以下是一套我实践下来比较有效的流程适合任何“终端优先、注重上下文控制”的编码代理也适合自己手动搭配大模型终端来用。4.1 第一步定义任务的“注意力范围”开始一个任务前先写两三行任务说明告诉模型目标是什么、约束是什么、涉及哪些文件、怎样算完成。不要一上来就说“帮我看看”而是说任务修复 src/order.py 中 process_order 函数在订单金额为 0 时会抛异常的问题。 约束只改这一个函数不重构其他逻辑保持现有返回结构。 验证运行 src/test_order.py 中的相关测试。这几十个字看起来简单但对上下文管理意义很大。它相当于给模型划定了注意力范围让它可以忽略范围外的内容。这不是浪费而是投资——花很少的 token换来后续所有步骤不跑偏。4.2 第二步先检索再读取这是整个流程里最核心的一步。不要直接让模型读文件而是先用 grep、find、sed 这些工具定位相关代码段。以之前的订单函数为例执行流可以是这样# 找文件和函数位置 grep -rn def process_order src/ # 查看函数周围的代码 sed -n 100,150p src/order.py # 找到异常相关逻辑 grep -n amount\|total\|raise src/order.py | head -20拿到这些片段后再把它放进上下文。模型看到的是一段聚焦的代码而不是整个文件的四千行。这里的关键是每当你觉得“看完整个文件才能懂”先问自己——是不是可以先画个函数调用图、先看关键分支、先看最近改动的 diff。日志也是同样的道理。不要丢整段日志先筛# 只看错误和异常行 tail -500 app.log | grep -iE error|exception|traceback | head -60把这一步养成习惯之后上下文的消耗会成倍下降而且准确率通常不会下降反而会因为噪音减少而提升。4.3 第三步限制工具回传和单次输出很多编码代理允许执行命令或调用工具这很方便但也是上下文浪费的重灾区。一旦工具回传了一个大 JSON 或一整屏表格模型的注意力就被砸开了。我的做法是给回传加边界命令输出默认加head -xx截断只保留前几十行大对象用jq选择关键字段而不是整体回传文件对比用diff而不是把两个文件都贴进去需要模型分析长日志时先让它看摘要再按需打开细节。# 只回传关键字段而不是整个 JSON cat result.json | jq .data[] | {id, status, error} # 用 diff 表达改动节省大量上下文 diff -u src/order.py.bak src/order.py这里有一个反直觉但很有效的原则宁可多轮交互也不要一轮堆冒。一次只给模型一小块关键信息让它给出反馈再给下一块。交互次数会多一点但每轮的质量会高很多总体的上下文消耗反而是下降的。4.4 第四步用外部检查点接管长期记忆“新开会话就会丢失上下文记忆”是很多人的痛点。这个痛点的解法不是硬着头皮把会话拉长而是把记忆迁移到外部。经常遇到的多步任务建议在项目里放一个轻量的进度文件或者用 commit 信息、TODO 注释记录决策。每完成一个子任务就把有效结论写进去。这样即使新开一个会话只要把进度文件交给模型它就能快速进入状态。# docs/order-fix-notes.md ## 现状 - process_order 在 amount 0 时触发 ZeroDivisionError - 根因是除以未加保护的费用率不是金额本身 ## 已做 - 已在 process_order 内增加 amount 0 的早期返回 - 已补充 test_order.py 中的一个边界用例 ## 待做 - 跑完整测试 - 确认订单状态字段在返回时仍保持一致这个文件就是“外部检查点”。它比自动总结更可靠因为它是你自己写的结构清晰、没有损耗。每次新会话打开时把这份文件交给模型再开始新任务上下文又会回到一个干净但信息完整的状态。核心原则是上下文只负责“当前任务”跨任务记忆交给外部载体。别让模型替你背一整天的历史。5. 当上下文还是爆了一套可复用的排查链路即使做了以上所有事情上下文还是可能超限。这时候不要急着换一个更大的窗口模型先按顺序排查通常问题出在下面这几层。第一层看会话里到底有什么。不要猜直接把会话记录导出按内容来源做一次粗略统计。常见情况是某个大文件被读了三次或者某次命令回传了上千行结果。如果这两种情况出现说明前面的“先检索再读取”和“限制回传”没有执行到位。这一步的目的不是追究责任而是找到占比最高的那几项。第二层看最近几次工具调用。上下文突然从前一次正常变成爆掉几乎都出现在某次工具调用之后。尤其是开启了 MCP 服务或插件的场景一次全量同步、一次列表查询、一次状态返回都可能带着很大的数据量。如果你发现某次调用后模型开始变慢或者报超限就先去看对应服务是不是回传了不必要的大对象。很多服务支持分页或字段筛选在调用前加上限制通常能解决一半问题。第三层看自动总结的触发时机和频率。如果看到“已进行多次自动总结但上下文大小仍超出限制”这类提示说明问题已经不在历史长度而在每个新步骤仍然持续引入大量新内容。继续自动总结只是在给漏水的水桶换更大的盖子。正确做法是停下来把当前任务拆成两个更小的会话。一个会话只保留一个目标上下文自然就降下来了。第四层看上下文窗口配置与真实可用长度。特别是本地模型不要只看模型的宣传支持长度。量化、显存、推理框架都会影响实际可用窗口。怎么确认可以看模型配置里的n_ctx或max_tokens参数也可以直接查推理框架的 API 接口返回。如果拿不准用一小段递增长度的输入做压测到哪个长度开始丢内容真实窗口就在哪附近。这个检查值得做因为很多“上下文超限”其实不是窗口不够而是配置没有对齐。第五层最后才考虑换更大窗口。换大窗口只是缓解症状。更大的窗口意味着更大的注意力稀释面也意味着更贵的推理成本。如果你还没有做好输入治理就算从 64K 换成 1M同样一个整文件读取、同样一段日志洪流很快又会把你的新预算耗尽。所以顺序一定是先治理输入再考虑扩容。排查顺序很重要先解决“怎么放进去的”再解决“空间够不够”。大部分上下文超限都不是因为窗口小而是因为入口没把好。6. 这类工具适合谁不适合谁Pi Agent Harness 这类“极简、终端优先”的编码代理有自己的适用边界。它不是什么场景下的万能答案这一点必须说清楚。维度适合不适合使用者画像熟悉命令行、愿意主动控制输入习惯全自动图形界面、不希望在终端里折腾任务规模局部修改、单文件调试、小范围重构跨几十个文件的大型架构重构代码库规模中小型、模块边界清晰巨型