Smartsheet 如何在 AWS 上构建远程 MCP 服务器

AWS ML Blog 2026-07-17T21:16:33.676554

如何在 AWS 上构建远程 MCP 服务器：Smartsheet 实践

Smartsheet 是一个企业级工作管理平台，数十万组织都在使用它。随着企业团队开始采用 AI 代理，这些代理需要以结构化方式访问 Smartsheet 这类系统中的数据，但大多数系统并没有为此做好准备。为了解决这个问题，Smartsheet 在 AWS 上构建了一个远程模型上下文协议（Model Context Protocol，MCP）服务器，让 AI 客户端可以直接访问其数据和功能。像 Amazon Quick 和 Claude Desktop 这样的 AI 助手，可以通过自然语言帮助用户使用 Smartsheet 的功能——分析项目数据、更新任务、创建表格、管理工作区等等。企业也在构建自定义 AI 代理，用于那些无需人工提示即可运行的工作负载。这些 AI 代理可以自主工作，通过 MCP 在 Smartsheet 平台上进行协调。举例来说，它们可以捕捉需求、接取任务、附加测试结果、撰写文档。这些操作都在人类同事使用的同一张表格中完成，从而把原本需要数周的工作流程压缩到几天甚至几小时。

MCP 服务器连接到 Smartsheet 现有的 API 和中央智能层。此外，它还在上层增加了一个针对 AI 优化的接口，旨在降低 Token 消耗、减少幻觉，并帮助大语言模型（LLM）可靠地处理企业数据。根据内部遥测数据，自上线以来，Smartsheet 通过这些优化节省了超过 30 亿个 Token。本文将从宏观层面介绍 Smartsheet 远程 MCP 的架构，重点讲解其背后的 AWS 基础设施，包括安全、治理、扩展与部署，以及 Smartsheet 在 AWS 上构建的 AI 特定优化。

架构

单一 MCP 层同时服务于内部和外部代理。Smartsheet 自身的内置 AI 体验 Smart Assist，以及 Amazon Quick 等外部连接的 AI 客户端，都运行在同一套基础设施上，使用相同的工具、优化和智能栈。这种对等设计是刻意的架构选择：Smartsheet 只需构建一次，所有客户端代理都能立刻受益。

在数据路径中，架构关键的 AWS 服务包括：AWS Fargate（用于 Amazon ECS，运行无状态服务器容器）、Amazon Kinesis Data Streams 和 Amazon Managed Service for Apache Flink（用于将变更事件导入 Amazon S3）、Amazon Bedrock 和 Amazon Neptune（用于大语言模型推理和知识图谱，支撑跨项目洞察）。详细的架构流程如下：

图1：Smartsheet 在 AWS 上的 MCP 服务器架构。边缘防护、容器注册表、可观测性、密钥管理等支持服务将在后续章节的相关部分介绍。

部署与扩展

在扩展方面，AI 流量与传统请求模式不同。智能体（Agent）会自动编排一系列工具调用，在完成一个任务时每秒可能发出多个请求，然后模型在推理时又安静下来。这种突发模式要求扩展策略既能应对突然的峰值，也能承载持续吞吐量。为了应对和验证这种模式，Smartsheet 将 MCP 服务器构建为运行在 AWS Fargate 上（基于 Amazon ECS）。ECS Auto Scaling 采用目标跟踪策略，将流量与计算利用率结合起来。基于计算负载的扩展在此处至关重要，因为每个请求都涉及服务端处理（例如针对 LLM 优化的序列化），而不仅仅是代理转发。

通过在接近生产环境的流量模式下进行大量负载测试，验证了基础设施能够吸收智能体突发流量而不降级。部署方面，在不中断活跃智能体会话的前提下推送更新同样至关重要。容器镜像存储在 Amazon Elastic Container Registry（Amazon ECR）中，并通过持续集成/持续交付（CI/CD）管道配合分层安全网进行版本发布。ECS 部署断路器在发布过程中检测故障容器，并自动回滚到最后一个稳定版本，无需人工干预，避免影响用户。部署遵循 AWS Well-Architected 原则（缩小影响范围），先从最小的区域开始推送。每个区域部署后，自动化端到端测试会针对真实环境验证工具行为。金丝雀测试每 15 分钟运行一次，通过完整的认证和网关路径执行多步骤 MCP 工作流，结果反馈到监控堆栈中，从而在用户报告问题之前发现性能下降。基于 ECS Fargate 与 ALB 的模式已在 AWS Guidance for Deploying MCP Servers 中做了详细说明。

治理与可观测性

对于企业客户而言，治理是采用 AI 的关键门槛。Smartsheet 将其内置于工具框架本身：每个工具默认自带访问控制、错误处理和审计追踪。访问权限按组织分级：管理员可以全局开启 AI 访问、限制为仅允许非破坏性操作，或者开放全部写入和破坏性权限，从而让每个组织自行控制其采用节奏。工具携带 MCP 协议注解（如 readOnlyHint 和 destructiveHint），AI 客户端会自动触发对应的确认流程。服务器在整个请求生命周期中发射 OpenTelemetry 信号（日志、追踪和指标）。每次工具调用都在隐私约束范围内捕获尽可能多的上下文信息：用户、组织、工具名称、结果等，为使用洞察和合规审计奠定基础。智能体流量比传统 API 流量更难观察。

一个用户请求可能触发一连串工具调用，而失败的原因往往要追溯好几个步骤。Smartsheet 正在用「以智能体为先」的身份与追踪机制来增强可观测性，让整个工具链的上下文关联起来。日志通过 Amazon Kinesis 流入 Amazon OpenSearch Service（遵循 AWS 可观测性最佳实践），基础设施指标则通过 Amazon CloudWatch 展示。Datadog 负责每个工具的应用性能监控（APM），PagerDuty 处理事件路由。每一次调用还会通过 Amazon Simple Queue Service（Amazon SQS）向 Intelligence Layer 发送一个结构化的分析事件。这样就形成了一个反馈闭环：生产环境的使用数据会告诉你哪些工具该优先优化，以及优化策略在实际负载下的表现如何。

AI 智能体流量的安全防护
MCP 服务器运行在 Smartsheet 生产 API 的同一套安全基础设施之后。边缘层部署了 AWS WAF 和 AWS Shield，私有子网放在虚拟私有云（VPC）内，服务间调用使用双向 TLS（mTLS），还有一个 OAuth2 代理，能在请求到达计算层之前就拒绝未认证的请求。MCP 服务器遵循 AWS 的《MCP 服务器部署指南》中的纵深防御模型。API 网关层负责认证和作用域校验，领域服务层处理细粒度权限。如果用户通过 UI 无法访问某个表格，那通过 MCP 也同样无法访问。

AI 流量带来了独特的限速挑战。用户一个问题可能在几秒内触发多个工具调用。许多企业用户都位于共享企业代理之后，基于 IP 的限速方法并不可靠。为了解决这个问题，Smartsheet 通过 AWS WAF 实现了分层限速。三个层次协同工作：外层提供全局保护，基于用户身份头部的自定义聚合键进行单用户计量，路径级别的控制针对高开销操作。单用户计量意味着每个会话单独计量，而不是按 IP 聚合。这种分层限速遵循了 AWS WAF 中最重要的三种基于速率的规则模式。

测试非确定性AI工作流

Smartsheet 保留了标准的测试层级：单元测试、集成测试和工具级验证。但 MCP 服务器带来了一项传统 API 服务不曾遇到的测试难题。传统 API 的响应由 UI 以确定性方式渲染呈现；而 MCP 工具的响应则要经过大语言模型（LLM）处理——模型先解读响应内容，进行推理，然后生成用户实际看到的结果。这一层“非确定性”让测试中的“正确”标准彻底变了样。

为此，Smartsheet 大力投入端到端工作流测试，将 LLM 纳入测试闭环。这些测试模拟真实的业务场景：创建工作空间、写入数据、查询结果，并验证模型的解读是否能被最终用户理解。这些测试在 CI/CD 管道（使用托管在 AWS 上的 GitLab CI 运行器）中执行，同时作为金丝雀测试持续针对每个生产环境的 AWS 区域运行。

为AI消费场景优化

随着企业大规模部署 AI 代理，Token 消耗已成为实实在在的成本驱动力。每一次工具响应，在 LLM 层面都要花钱，还要抢占上下文窗口的容量。目前大多数 MCP 工具调用都没有子代理编排——代理直接逐个调用工具，每步之间进行推理。如果工具设计不够智能，这个过程很快就会变得缓慢、昂贵且易出错。每个工具调用必须自成一体且高效运转，这正是 Smartsheet 从三个层面进行优化的原因：

渐进式披露

每个工具响应都设定了一个 Token 预算。服务器会根据列数和数据密度动态计算可返回的行数。例如，一个包含5列的工作表可以比15列的工作表返回更多行，但总 Token 数始终控制在预算之内。无论工作表有50行还是50000行，响应大小都被限制在预算内。模型看到足够的信息来定位问题，然后根据用户实际询问的内容，通过筛选条件逐步缩小范围。

元数据字段告诉模型发生了什么

元数据字段能清晰告知模型刚才的数据处理情况：is_sampled 表示数据是否被截断，rows_in_sheet 给出表格的总行数，rows_actual 显示实际返回了多少行，而 filters_applied 则描述了当前激活的过滤条件。模型利用这些信息判断自己是否拿到了完整全貌，还是需要进一步用过滤条件缩小查询范围。

渐进式数据披露（Progressive disclosure） 是由服务端决定的策略。MCP 服务器负责预算管理与采样控制，而它返回的元数据则为 AI 客户端提供了自主编排后续查询的信号。

图 2：渐进式数据披露的实际演示：AI 客户端收到带元数据的采样结果后，再发起针对性的二次请求。

让大语言模型（LLM）保持脚踏实地：基于 schema 的工具契约

约束 LLM 的行为至关重要。如果缺乏限制，模型可能会凭空编造参数名、发明不存在的操作符，并在失败的调用中浪费 token。借助 MCP 的工具发现机制，每个工具都会发布一份严格的 JSON Schema（从 Pydantic 模型生成）。参数被限制在有效的枚举值范围内；列名在执行前会与实际表格进行校验；一旦出现不匹配，系统不会静默失败，而是返回带有有效选项的结构化错误信息。

Schema 校验能够在边界处捕获模型的幻觉行为，这意味着 AI 代理可以可靠地浏览工具目录，而无需反复尝试和猜测。

更高效的 Token 序列化

JSON 格式的结构性开销（花括号、引号、重复的键名）通常会占用响应中 15%–25% 的 token 数量。对于返回数千行表格数据的服务器来说，这种开销会快速累积。Smartsheet 构建了一套专有的序列化格式来缓解这一问题：键名只出现一次而无需每行重复，结构语法也被替换为能更高效分词的定界符。

以一个典型的 33 条过滤查询为例，优化后的响应大约消耗 3,900 个 token，而等价的 JSON 则需超过 6,000 个 token——在携带相同信息的前提下，token 数量减少了约 35%。当数据行数增加到 1,000 行时，差距会进一步拉大，因为 JSON 在每个对象中重复键名，而优化格式只需声明一次。

Smartsheet AI 代理的未来发展

目前，AI 代理已经能够通过 MCP 与 Smartsheet 集成。

标题：Smartsheet 如何在 AWS 上搭建远程 MCP 服务器

在正式上线（GA）后的头四周内，Smartsheet 的用户周环比增长超过了 87%。MCP 是这层分发能力的基础。下一步的智能能力将直接嵌入到连接点本身。一个例子是资源可以根据使用它的人、团队和组织自行调整形态。另一个例子是能在工作流上自主运行的智能体，以及一个路由层，让不同专业领域的智能体可以把推理过程互相交接，而不必每一步都从头开始。同样的 MCP 连接，给不同客户提供不同的智能体验，而且无需部署。AWS 正在演进其基础设施以满足这些新兴的智能体需求。Amazon Bedrock AgentCore 默认提供了运行时执行、发现、个性化和治理能力。Smartsheet 正在与 AWS 一同采用并塑造这些能力。MCP 协议本身也在持续演进。Elicitations（征求意见）机制允许在破坏性操作前加入人工确认环节。MCP Apps 将交互式 UI 直接带入 AI 对话中。Tasks 支持异步、长时间运行的操作。Smartsheet 正在评估这些功能，等待它们成熟。AI 发展速度极快。借助 AWS 的基础设施，我们能够跟上节奏——无论是新协议、新模型，还是全新的智能体架构。要连接 Smartsheet 的 MCP 服务器，请访问 AWS Marketplace 列表，或查阅 Smartsheet MCP 文档。

关于作者

Vasil Kosturski
Vasil 是 Smartsheet 的首席工程师，他带领团队从概念到正式上线，打造了 Smartsheet 的远程 MCP 服务器。他主导了系统设计、AWS 架构以及本文中提到的 AI 专属优化。更广泛地，他参与 Smartsheet 开发者生态系统的建设，并塑造其公开 API 平台。加入 Smartsheet 之前，他在分布式系统和实时数据领域有超过十年的经验，最近一段经历是在 Sportradar 担任首席开发者，构建基于 Kafka 的大流量事件处理管道。他现居保加利亚普罗夫迪夫。

Galina Jordanowa
Galina 负责将复杂的 AI 和产品能力转化为清晰、有策略的市场叙事和推向市场（GTM）动作。

查看原文