结业项目成果

面向生产环境的 MCP 集成并不只是一个能够调用工具的 agent。它是一个将 AI agent 连接到经批准的工具或数据、通过 MCP 客户端协调每个请求，并让用户可靠了解处理结果的应用。在本结业项目中，你将使用真实场景中的请求来设计和评估这条完整链路，其中包括含义不明确、不安全或无法完成的请求。

明确区分各个角色。主机是负责管理 agent 体验及其 MCP 客户端的应用。MCP 客户端负责维护与 MCP 服务器的连接。服务器公开工具或资源等能力。模型可以协助选择操作，但主机仍负责策略决策、用户交互和结果报告。不要将模型指令或工具描述视为授权边界。

定义请求和边界

从一个具体的工作流开始，例如对支持工单进行分流。明确记录用户可以提出哪些请求、应用可以访问哪些数据，以及哪些操作能够改变外部状态。一组有用的初始能力包括只读工单查询，以及添加内部备注等会改变状态的操作。在连接 agent 之前，先为每项操作规定允许的输入、预期结果和授权要求。

将信息收集与会产生后果的决策分开。应用可以检索工单并起草建议备注，而不做任何更改。在用户确认确切的操作和目标之前，应用不得添加备注或更改工单状态。如果请求未明确指定工单，或检索到的信息仍存在重大不确定性，应提出澄清问题，而不是自行猜测。开发和评估时使用沙箱数据；不要为了让演示显得真实而使用真实客户记录。

构建 MCP 链路

使用所选 SDK 和传输方式支持的 MCP 客户端连接服务器。对于本地服务器，标准输入/输出可能是合适的选择；对于远程服务器，应使用受支持的 HTTP 传输，并有意识地配置其安全机制。将传输方式、SDK 和服务器版本视为明确的项目依赖。在启动时记录预期的服务器身份和能力；如果缺少必需工具，或其声明的输入 schema 与应用不兼容，则应清晰地报告失败。

将 MCP 的发现和调用作为协议操作来使用，而不是将其视为专为模型臆造的名称。客户端可以通过 tools/list 发现可用工具，并通过 tools/call 调用选定的工具。服务器也可以公开资源，客户端可通过相应的资源操作发现并读取这些资源。只请求此工作流所需的能力。在调用工具之前，宿主应用应检查自身策略，根据应用预期验证参数，并在需要时获取确认。调用之后，应先验证结果，再将其传回智能体或将其作为事实呈现。

强化安全性与可靠性

工具模式和描述有助于智能体理解某项能力，但它们并不能证明调用是安全的。只读或破坏性操作等注释提示是有用的元数据，但不能替代应用策略。通过服务器权限和宿主应用自身的授权检查来实施访问控制。仅向服务器提供其所需操作和记录的凭据，将密钥存储在 prompt 和源代码管理系统之外，并使用适合所选传输方式的远程授权机制。

将模型生成的参数和服务器返回的内容都视为不受信任的输入。验证标识符、允许的状态值、文本长度以及任何相关的用户权限。工具输出可能包含错误数据，或包含旨在操纵智能体的指令；它不能覆盖宿主应用策略。设置超时，并提供明确的失败处理路径。仅重试已知可安全重复的操作，因为在超时状态不确定时重试状态变更请求，可能造成重复效果。在支持的情况下，处理取消操作，并妥善关闭客户端与服务器连接。

端到端评估

测试完整的用户工作流，而不仅仅是 MCP 连接是否能够建立。应包括直接查询、需要澄清的请求、要求执行变更的请求、拒绝确认的用户，以及超时或返回错误的服务器。增加一个工具输出包含与应用策略冲突的指令的测试用例。为每个用例明确预期的用户可见响应，以及是否允许调用工具。

衡量可观察行为。记录是否选择了预期工具、传入的参数是否通过验证、是否完成了必要的审批，以及最终响应是否与实际工具结果一致。只有当应用拒绝不安全的调用并准确描述失败情况时，测试才算通过。检查日志和追踪信息，确保其中包含足以诊断失败请求的细节，同时对凭据进行脱敏并限制敏感用户数据。应报告测试覆盖率和已知限制，而不是声称小规模测试套件能够证明系统具有普遍安全性。

发布与审查

发布之前，固定依赖版本，记录 MCP 服务器和传输配置，并确保在所需配置或能力不可用时，应用默认拒绝操作。审查访问控制、凭据处理、网络暴露范围、超时设置和日志保留策略。将开发、测试和生产环境的服务器配置分开。工具模式或服务器实现发生变更时，应在部署前触发兼容性和安全性测试。

结课项目的交付物应是一个可重复运行的应用，而不是一张成功截图。交付内容应包括设置步骤、信任边界、需要审批的操作以及测试结果。审查者应能够使用沙盒数据运行该应用，复现一次成功的查询和一次被拒绝或失败的操作，并验证最终消息不会在服务器确认之前声称变更已经发生。这些标准使集成更易于理解、测试和安全运行。