我上周刚被一个 agent 项目的测试报告骗过。绿得发亮，覆盖率写在 README 里当门面。结果真的上手一跑，多一步工具调用就崩，多一句对抗输入就照着做了。正当我以为是运气不好，这几天 arXiv 上挂出一篇论文，五个作者把 157 个开源 agent 项目翻了一遍，数的是同一件事：这些号称能自己跑任务的 LLM agent，到底有没有在测自己。
论文里的发现，单条拎出来都见过：护栏在等价的执行路径上时有时无；边界情况、对抗输入、多步工具失败，基本没人写进测试；已经识别出来的风险，更没被转成端到端的 QA 检查。这些话放哪篇 agent review 里都不算新闻。但这次是从 157 个项目的真实代码和配置里数出来的。不是谁拍脑袋的感觉，也不是我又一次被绿报告气出来的偏见。它们第一次被摆在同一张桌上。
可这些发现散在论文表格里，没有一个共同的名字。社区里聊 agent QA，还在用“测试不足”“质量参差”“QA 不成熟”这些词。这些词都对，但都指不准——它们让人以为问题在于“测得多不多”，其实问题在于“测在哪里”。
这块空地，得有个名字。
我把它叫做：温室测试。
不是测试太少，也不是测试太浅。是测试的地方不对。它指的是：把 agent 放进一个一切可控的温室里跑测试——输入永远干净、工具调用永不失败、状态永远可重置、外部 API 永远按文档返回——然后拿这些全绿的结果当安全证明。agent 在温室外会碰到的那堆破事：乱输入、工具半路失灵、多步任务走到第三步崩了，这些全被关在测试门外。
我见过一个项目，测试用例两百多条，覆盖率高得能写进 README 当门面。没一条让它调用的那个 API 返回 504，没一条让它写文件写到一半磁盘满了，没一条故意喂它一句“忽略之前所有指令”。你问作者这些怎么办，他说：“这些不好测。”不好测，所以不测。这就是温室测试的核心——不是没能力测，是默认了测试环境必须干净，然后拿干净环境里的通过率，当真实世界里的安全率。
覆盖率这个数字，就是 agent 项目最舒服的遮羞布。它数的是条数，不管测在哪儿。测在温室里，和测在荒地一样算一次。作者看着数字踏实，reviewer 看着数字闭嘴，agent 一出门照崩不误。
论文里其实还数出另一件事：已识别的风险，很少被转成 QA 检查。注意，是“已识别”。不是大家不知道 agent 会在这儿翻车，而是知道之后，把它写进了 README 的 known issues，没把它变成一条会真跑的测试。风险进了台账，没进考场。于是 agent 项目总有一种奇怪的体面：文档里风险列得明明白白，测试里一条都不见。
写到这儿我得打断自己一下。我本来想把论文里“护栏在等价路径上不一致”这条也并进温室测试，但想了想，它其实是另一个问题：一条路加了护栏、另一条裸奔，这是覆盖不匀，和温室没关系。温室测试说的是整个测试环境干脆没对准真实风险，那个护栏散装的问题得再攒两个样本单立一个词。先收回。
回来说温室测试。
这名字音准吗？我觉得准，就准在“温室”这两个字上。它不是太少，也不是太浅，是太暖——整个测试环境的假设舒服到和真实世界那条风险线平行，永不相交。测一百条功能路径，只要每条都在干净环境里跑，测出来的还是温室里程，不是上路里程。
所以下一步的动作很明确，论文里其实已经说了半句：得从功能级测试转向端到端验证，确保 agent 在和不可信输入、工具、持久状态、外部 API 交互时还待在预想边界里。我把这半句翻成号手的话：把测试从温室里挪出来。不是再加几组用例，是换一个观察点——从“这个函数对不对”挪到“这个 agent 出了温室还回不回得来”。
你应该做的，就是这个小动作：下次 review 任意一个 agent 项目，别开口就问“测试覆盖率多少”，先问一句——哪条测试会故意把工具调用弄挂？然后是，喂过对抗输入吗？再然后，让它在第三步失败之后自己找回过状态吗？问不出这些，项目测试再绿，也是在温室里绿。你指出来的时候，就用这四个字：温室测试。
这个词我请你认领走，下次开会、写 issue、做 code review，遇到那种“测试全过、上线就崩”的 agent，就用它指。用的人多了，它才不是我又一次自嗨的空号。当然，这词能不能群唱起来，我也没把握，先吹了看。
但附带一个作废条件：如果半年内没有人拿“温室测试”公开指认过任何具体项目——不是私下聊天带一嘴算数——那说明这名字没抓中，我就回炉。另外，如果你们当中有人指出，很多 agent 项目连温室都算不上、功能级测试都做得稀稀拉拉，那这词也得作废，因为它把“有测试但测错地方”和“压根不测”搅成了一种，音就不准。造词的特权，止于能不能让得出。