内容提要
AWS的James Ward认为,MCP服务器不应只充当数据接口,而应像对话中的第三方,在返回数据时附带下一步指引。他强调可观测性:MCP默认没有追踪ID,AWS通过会话ID和目标参数串联调用,以复现并评估智能体路径,从而优化工具。AWS已开放其MCP服务器并加入Lambda诊断,同时保留CLI等替代方案。
延伸解读
MCP服务器应提供对话式引导
James Ward指出,许多MCP服务器仅返回数据,但协议的最佳用法是让服务器像对话中的第三方,在响应中附带指引:告诉智能体刚做了什么、下一步可能做什么、去哪里找更多信息。这要求工具响应不仅包含数据,还携带行动建议,从而帮助智能体更连贯地完成任务。
可观测性:用会话ID串联调用
MCP默认没有追踪ID,AWS的变通方法是给工具添加会话ID参数,并要求智能体每次调用都传递,从而将分散的调用拼接成完整旅程。另一个参数可携带用户提示或目标摘要,便于团队对比用户意图与智能体实际路径,构建评估并调整工具描述或参数,衡量任务完成率是否提升。
从旅程观察中发现工具改进点
Ward举例,智能体因服务器只提供单条记录工具而逐条获取客户记录。通过观察完整旅程,团队能识别此类模式并构建批量工具来修复。AWS已将其MCP服务器开放,并加入Lambda诊断,同时保留CLI等替代方案,因为MCP的OAuth模型无法像CLI那样切换AWS用户配置文件。
MCP并非唯一方案,需用评估对比
Ward并未将MCP视为唯一解。AWS同时提供CLI和技能,哪种方式更有效取决于模型、工具描述和智能体发现工具的方式。AWS通过评估让它们相互对比。核心方法并不新奇:观察旅程、复现、测量、改进,但团队现在需要理解人与智能体共同走过的路径,并测试工具变更是否真正帮助完成任务。
Q&A
MCP服务器除了返回数据,还应该做什么?
MCP服务器应在返回数据时附带下一步指引,告诉智能体它刚做了什么、接下来可能想做什么以及在哪里找到更多信息,从而像对话中的第三方一样参与交互。
为什么MCP默认缺乏可观测性,AWS如何解决?
MCP默认没有追踪ID,无法串联调用。AWS的变通方法是给工具添加会话ID参数,并要求智能体在每次调用时传递,同时用第二个参数携带用户提示或目标摘要,从而将单个调用拼接成完整旅程。
如何利用追踪信息来优化智能体工具?
团队可以比较用户意图与智能体实际路径,围绕此构建评估,调整工具描述或参数,并测量任务完成率是否提升,从而优化工具。
AWS在MCP方面有哪些具体行动?
AWS在5月向所有人开放了其MCP Server,并在9月加入了Lambda诊断功能。此外,AWS还为其开发者使用的MCP服务器构建了大部分可观测性功能。
MCP是唯一的选择吗?AWS还提供了哪些替代方案?
不是。AWS还提供CLI和技能(skills),部分原因是MCP的OAuth模型无法像CLI那样在AWS用户配置文件之间切换。最佳方案取决于模型、工具描述和智能体发现工具的方式,AWS通过评估来比较它们。
如何发现并修复智能体低效的工具使用模式?
通过观察智能体的完整旅程,团队可以发现诸如服务器只提供单条记录工具导致智能体逐条获取客户记录的模式,然后构建批量工具来修复。