智能体会读取错误
当 MCP 服务器的工具调用失败时,错误信息会成为智能体上下文的一部分。智能体阅读该错误并决定下一步动作:是否重试?是否换个思路?是否向用户求助?决策完全取决于错误信息所传达的内容。
仅写"Error: ECONNREFUSED"的错误,只告诉智能体连接被拒,却未说明缘由或下一步该怎么办。而"Error: 无法连接到位于 localhost:5432 的 PostgreSQL。可能是数据库未启动,或端口配置不正确。请检查 PostgreSQL 是否已启动、连接设置是否与您的数据库配置一致。"则提供了足够信息,使智能体能向用户解释问题并提出具体修复建议。
优良错误信息支撑恢复
面向 AI 消费的工具,最佳错误信息通常遵循一个范式:发生了什么、可能为何发生、可如何修复。"查询返回 0 行。表 \"users\" 存在但可能为空,或 WHERE 子句 \"created_at > 2026-12-01\" 未匹配任何记录。请尝试放宽日期范围或检查表内容。"——这就为智能体提供了足够上下文,使其无需求助用户便可尝试修改后的查询。
错误分类同样有用。若错误指向权限问题,智能体便知重试无济于事;若指向网络瞬时问题,重试或可成功;若指向参数无效,智能体可尝试不同参数。清晰的分类支撑更聪明的恢复策略。
糟糕的错误会导致循环
"Internal server error"或"Something went wrong"之类的含糊错误,等于不给智能体任何可用信息。它可能会再次重试同一失败调用(浪费 token),换一个稍有不同但同样会失败的方式,或者在仅需调整参数即可解决问题时彻底放弃。
最糟糕的范式是错误被完全吞掉,根本不发出任何异常信号。智能体收到空白或残缺的结果,继续按其正确的假设推进。这会引发下游的级联错误。
给 MCP 服务器构建者
如果您正在构建 MCP 服务器,请在错误信息上多花心思。每条错误路径都应返回一条能帮助语言模型理解问题并提出修复建议的信息。把错误信息当作给一位无权访问您日志或数据库的初级开发者的指引——他需要知道哪些内容,才能定位并修复问题?
请在错误中纳入相关上下文:尝试了哪项操作、使用了哪些参数、预期行为是什么、实际发生了什么。这些上下文只多出几行代码,却能显著改善智能体与您的服务器的交互体验。