AWS开发者倡导者James Ward：MCP服务器应成为对话中的第三个声音，用指引和会话追踪驱动工具迭代

在AGNTCon + MCPCon大会上，AWS资深开发者倡导者James Ward提出了一个关于MCP服务器设计的核心主张：协议的最佳用法不是让服务器充当数据库，而是让它成为对话中的第三个声音。他设想的是，当你有多个MCP服务器时，它们分别扮演第四、第五个对话参与者的角色，而不仅仅是被查询的数据源。

Ward给出的具体机制是：工具响应不应只返回数据，还应携带指引——告诉agent它刚刚做了什么、接下来可能想做什么、以及去哪里找到更多信息。这意味着MCP服务器从被动的查询接口变成了主动的参与者，它的输出本身就是agent下一步推理的输入。

可观测性是这一主张的另一半。Ward指出，Web开发者可以从一次页面点击追踪到数据库，但MCP默认没有任何trace ID机制。AWS的解决方案相当朴素：给工具添加一个会话ID参数，要求agent在每次调用时都传递它，从而把零散的调用拼成一条完整路径。第二个参数可以携带用户的原始提示或目标摘要。团队随后可以对比用户想要什么和agent实际走了哪条路，围绕这条路径建立评测，调整工具描述或参数，再测量任务完成率是否改善。

一个具体例子说明了这套方法的价值。在Agentic AI Foundation发布的一篇人物介绍中，Ward描述了一个agent逐条获取客户记录的场景——因为服务器只提供了单条查询工具。正是通过观察完整的调用路径，团队才发现了这个模式，并据此构建了一个批量工具来修复它。如果没有端到端的可见性，这种低效调用可能长期隐藏在正常运行的表象之下。

Ward并没有把MCP当作唯一解。他承认AWS也提供CLI和技能接口，部分原因是MCP的OAuth模型无法像CLI那样在AWS用户配置文件之间切换。哪种方式最有效取决于模型、工具描述和agent发现工具的方式，所以AWS用评测把它们放在一起对比测试。他也坦承这套方法论并不新奇——观察路径、复现问题、测量改进、迭代工具，这些是软件工程的老原则，只是现在需要理解的是人与agent共同走过的路径，并验证工具改动是否真的帮助完成了任务。

值得注意的是，这篇文章由AWS Marketplace赞助，Ward本人是AWS员工，所描述的实践是AWS内部开发者使用的MCP服务器。这是一个厂商视角的工程主张，而非独立第三方验证的结果。会话ID方案依赖agent配合传递参数，不是协议层面的强制约束；它能否在更广泛的MCP生态中推广，取决于各实现是否愿意接受这种约定。