别再让 Agent 盲着跑 —— 错误提示得像指令一样直

在推行自动化工作流时，我碰到一个又低级又贵的设计陷阱：开发们习惯往“偶尔看看日志的人类”那写错误提示，却忘了 LLM 时代的真正接收者，是 Agent。

人类看到报错，会找线索：查服务状态、回想配置变更、群里问同事。但 Agent 不同，报错字符串就是它感知的全部。要是报错有误导，它可没怀疑余地，会笃定地花 Token 和时间，解决个根本不存在的问题。

我做浏览器自动化时就栽进去了。所有页面加载报 NS_ERROR_UNKNOWN_HOST，我第一反应是 DNS 死了，在 shell 里 ping 来 ping 去都通。折腾一个多小时，才知道 SOCKS 代理挂了，但浏览器把代理失败粗暴报成“域名未知”。这类对人勉强、对 Agent 就是“谎言”的报错，是目前最浪费研发时间的。

为 LLM 设计工具时，错误提示得从“告知结果”变“提供指令”，得满足三点：

报错信息是否指明了具体的故障层级？

第一，必须指出故障层级，不能只说对象。很多接口报“无法访问 example.com”，对 Agent 毫无用处。该写“无法连接到 10.200.0.2:1080 的上游代理”。Agent 不知道你的网拓，报错是它唯一窗口。层级不清，它可能去改域名或检查 URL 拼写，而忽略了代理链路断了。

第二，得明确告诉 Agent 重试是否有意义。这信息熵最高。如果是参数类型错或权限不足，重试十次也白搭，得直接说：“参数类型不匹配，除非改参数，不然请求都会失败”。如果是网络抖动，应提示：“临时故障，建议 5 秒后重试”。

如何区分空结果与执行失败的报错？

第三，得严格分清“空结果”和“执行失败”。这坑很隐蔽：查失败时返回空列表 []，Agent 会把空列表当作“对象不存在”，写进记忆，后续所有环节基于错假设跑，最后全是幻觉。

传统逻辑中，我们给运维写详日志，给客户端回简短错误码（如 ERR_7734），因客户端是硬编码程序，只认代码。但现在客户端变 LLM，它懂自然语言，却对随机错误码 盲。

如何通过提高信息带宽来提升 Agent 效率？

得反过来设计：把报错当成留给一个能力强、却看不见你屏幕的同事的便签。描述越详细越自然，信息带宽越高，Agent 效率才真提升。