感谢我的那个独一无二的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，从输入中屏蔽掉不需要的信息。
以上。