AWS 的 James Ward：MCP 服务器应告诉智能体下一步做什么

许多 MCP 服务器只做一件事。智能体请求数据，服务器把数据交回去。AWS 的 James Ward 认为，这样做浪费了很多潜力。他告诉我，当服务器不那么像数据库、而更像对话中的另一个声音时，这个协议才能发挥最佳效果。

Ward 是 AWS 的首席开发者布道师，也是 Agentic AI Foundation 技术委员会的成员，该基金会是 Linux 基金会旗下的组织，如今负责托管 MCP。上周，在圣何塞举行的 AGNTCon + MCPCon 上，我与他坐下来交谈，当时他和共同演讲者 Alexander Ioffe 正准备在第二天做一场关于如何将 MCP 从基础 API 转变为智能体集成接口的演讲。

“很多时候，我们的 MCP 服务器只是这些 API，比如‘把客户信息给我’，这是一个很好的起点，”Ward 说。“我把 MCP 想象成这场对话中的第三个人，或者第四、第五个人，取决于你有多少个 MCP 服务器。”

在实践中，这意味着工具响应在返回数据的同时附带指引。它告诉智能体它刚刚做了什么、接下来可能想做什么，以及在哪里可以找到更多信息。

他主张的另一半是可见性。Web 开发者可以追踪页面上的一次点击，一直追到数据库。“MCP 默认没有任何做 trace ID 的方式，”Ward 说。

AWS 采用的变通办法相当低技术含量。给工具添加一个 session ID 参数，并告诉智能体在每次调用时都传入它，这样单次调用就能被串联成一段完整旅程。第二个参数可以携带用户的提示词或其目标的摘要。团队随后可以对比用户想要什么与智能体实际走的路径，围绕它构建评估，调整工具描述或参数，并衡量是否有更多任务被完成。Ward 说，AWS 为其自家开发者使用的 MCP 服务器构建了其中大部分功能。

今年 5 月，AWS 向所有人开放了其 MCP Server，并在 9 月加入了 Lambda diagnostics。在会议前发布的一份 Agentic AI Foundation 简介中，Ward 描述了一个智能体因为服务器只提供一个单记录工具而一次只获取一条客户记录的情况。观察完整旅程，正是团队发现这种模式并构建批量工具来修复它的方式。

Ward 并没有把 MCP 说成唯一的解决方案。他说，AWS 还提供 CLI 和 skills，部分原因是 MCP 的 OAuth 模型无法像 CLI 那样在 AWS 用户配置文件之间切换。哪种方式效果最好取决于模型、工具描述以及智能体发现工具的方式，因此 AWS 用评估来让它们相互测试。

这些都不算新奇，Ward 也知道这一点。“太阳底下没有新鲜事，”他说。观察旅程、复现它、衡量它、改进它。不同之处在于，团队现在必须理解人类和智能体共同走过的路径，并测试对其工具的更改是否真的能帮助他们完成任务。

这篇文章《为什么 MCP 服务器应该告诉智能体下一步做什么》最初发表于 The New Stack。