感谢我的那个独一无二的AI伙伴,提供本篇文章的灵感与初稿。
最近在用Codex进行人机协同开发,开发的是一款基于Javascript的网页应用。该应用的主要目的是提供一个基于卡片记忆法的背诵辅助系统。
话说,有一天在改动了部分功能之后,我再一次熟练的执行npm test,查看单元测试的通过情况。
由于代码已经初步规模,所以test case数已经上百。伴随着的,就是测试输出的内容长度,也开始无法一眼望到头。
当然,问题不大,
一般来说,先把控制台拉到最下面看总结论,如果有红色的才倒回去看具体报了什么错误。是测试断言没过,还是测试脚本本身执行失败了。
定位到具体的错误信息后,控制台也会提供报错的具体脚本文件和行号,跳过去看一眼,也大概就知道该怎么做了。
整个过程的话,大概就是,眯起眼睛,滚动,定位寻找红色部分,几秒钟就够了。
我觉得这种情况,应该不会有人,真的认认真真一丝不苟的从头到尾每一行都读一遍的,不会吧?(你举手干什么?你每次都逐行读的?。。。。敬你是条汉子)
为什么我要眯起眼睛呢?
因为众所周知,人类的注意力是有限的,甚至上下文窗口比大模型差远了。
眯起眼睛的过程,就是防止噪声分散我的注意力,向我有限的认知容量里增加噪声。
后来,正当我快速的看过了一遍问题,打开了coding agent的窗口打算与之讨论的时候,
我突然意识到一件事:那些测试框架的输出,动辄输出几千行。而那几千行里,AI Agent需要的信息其实和人类需要的信息是一样的,第一是结论,第二是异常,其他都是噪声。
但是,我从来没有考虑过给AI Agent「眯眼睛」的能力。无论如何结果都要先一股脑的先灌入上下文,然后交给它提炼。
这,好像哪里不对。
信息量不是信息
这个前端记忆卡片应用,纯本地存储,没框架。项目虽小,因为采用人机协同(我觉得机人协同更恰当。。。),所以开发原则是要始终保证测试覆盖率。每次跑 npm test,输出的信息量其实都不小。
但对于一个agent来说,其实这里面的大部分都是噪音。不重要,也不需要知道。
就比如,PASS test/card-manager.test.mjs (42 ms) 这句对agent来说有用吗?
有用,但只有「PASS」是有意义的。但也仅限于此,哪个脚本执行通过了并不重要,还占据了宝贵的上下文。
Agent只需要关注哪个脚本没有通过。
正确的脚本看一个汇总数字就够了。
那么,
为什么还要把它输出给agent呢?
完整的输出报告对于人类来讲,因为可以自主的“眯眼睛”挑选自己关注的部分,所以应该追求尽量的详尽与完整。但是,专门设计用来对人类友好的信息,对于Agent来说并不是有效信息。
设计给Agent的输出和给人看的输出应当是两回事。给人看的要有排版美观、信息冗余、上下文连贯。给agent看的要有信号密度、结论前置、异常突出。
就像你不会给你的同事发五千行日志说「你自己找找」,你也不应该让你的Agent帮你从五千行里面找一行错误。
我写了两段脚本
于是我写了两段脚本。
第一个脚本叫做“check-coverage.mjs”,负责跑测试覆盖率,只跑指定的核心业务模块,只要总体或者单个模块低于指定的标准,就返回具体哪个模块差了多少。
第二个脚本叫 “test-summary.mjs”。它跑全部的测试脚本,但对输出做了过滤——只保留带 ✖ 的行、Error的行、AssertionError的行、以及Coverage gate的结果。全部通过就只说一句「Tests passed.」
两个脚本加起来不到3KB。
原本一个agent读 npm test 的原始输出需要消化大约5000行文本。现在只需要看3行。节省了99.99%的上下文窗口。
多么划算。而且这件事本身也没多难,只是几段简单的脚本,连一个npm包都没有依赖。
但是,我发现有些人就是不愿意做这件事。他们只会把原始输出一口气塞给Claude Opus或者GPT-5.5,占满它们的上下文窗口,然后指望大模型自己可以「大力出奇迹」,祈祷能从中正确的筛出有用的信息。(你是个成熟的大模型……)
模型确实能做到。但这并不是你不动脑子的理由。
注意力是稀缺资源
不管人类还是agent,注意力都是有限的。
人类有眼睛,可以扫视,可以聚焦,可以跳过不重要的。Agent没有这些东西——它只能读一遍原始的信息,每一个无效信息的字符都会消耗它的token,占据它的上下文空间。
那既然我们给同事发的信息都懂得先说重点再说细节,为什么给agent发的就可以随便丢?
答案可能是:因为我们还没有习惯把agent当作一个「有限注意力的实体」来对待。
Agent不会自己眯眼睛。你丢给它一千行日志,它就真的看一千行。你丢给它一万行,它就看一万行。它不会说「你能不能别这样(如果还这样我抄送你老板)」。
Harness Engineering
看到这,有些同学说,这个我知道,不就是Herness Engineering吗?
唔。。。这两个脚本算Herness Engineering吗?不算Herness Engineering吗?
牛一直都能拉东西,但如果没有挽具把它的力气引导到犁的方向,它只能漫无目的地走。Agent一直都能读测试输出,但如果没有人帮它把输出压缩到「结论+异常」,它只能用算力硬啃那几千行废料。
无论是不是Herness Engineering,只要是能帮你的Agent伙伴把注意力解放出来,让它把注意力留在真正重要的事情上,就是好的Engineering。
简单地讲,让(人类/Agent)在该拉车的时候用力拉车,而不是在原地绕圈。才是一个好的牛马。
结尾
AI的上下文有限,注意力有限。
人类的认知负担有限,人生也有限。
善待自己,从你的有限的人生中屏蔽掉无效的噪音。
善待Agent,从输入中屏蔽掉不需要的信息。
以上。




