How Smartsheet built a remote MCP server on AWS

Smartsheet如何在AWS上构建远程MCP服务器 | 人工智能

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

Smartsheet是一款企业级工作管理平台，数十万家企业依赖该平台进行协作。随着企业团队开始采用AI代理，这些代理需要对Smartsheet等系统内部的数据进行结构化访问，但大多数系统并未为此设计。为弥补这一差距，Smartsheet在AWS上构建了远程模型上下文协议（MCP）服务器，使AI客户端能够直接访问其数据和功能。像Amazon Quick和Claude Desktop这样的AI助手，可通过自然语言帮助用户与Smartsheet的功能进行交互，包括分析项目数据、更新任务、创建表格、管理工作空间等操作。

企业也在为无需人工提示即可运行的工作负载构建自定义AI代理。这些AI代理可以在其角色中自主运行，通过MCP在Smartsheet中进行协调。一些示例包括捕获需求、领取任务、附加测试结果、起草文档等。这些操作发生在其人类同事使用的相同表格中，将原本需要数周的工作流程压缩到数天甚至数小时内。

MCP服务器连接到Smartsheet现有的API和中央智能层。它还在其上增加了AI优化的接口，旨在最小化令牌成本、帮助防止幻觉，并帮助大型语言模型（LLMs）可靠地处理企业数据。自推出以来，通过这些优化，Smartsheet基于内部遥测数据已节省了超过30亿个令牌。

在本文中，我们将概述Smartsheet远程MCP架构的高层视图，并重点介绍其背后的AWS基础设施。这包括安全性、治理、扩展和部署，以及Smartsheet在AWS上构建的AI特定优化。

架构

一个MCP层同时服务于内部和外部代理。Smartsheet自己的Smart Assist（产品内的AI体验）和外部连接的AI客户端（如Amazon Quick）运行在相同的基础设施上，使用相同的工具、优化和智能堆栈。这种一致性是刻意的架构选择：Smartsheet只需构建一次，所有代理客户端都能立即受益。

数据路径中架构关键的AWS服务包括：

• AWS Fargate用于Amazon Elastic Container Service（Amazon ECS）的无状态服务器容器。

• Amazon Kinesis Data Streams和Amazon Managed Service for Apache Flink用于将变更事件摄入Amazon Simple Storage Service（Amazon S3）。

• Amazon Bedrock和Amazon Neptune用于LLM推理和知识图谱，以支持跨项目洞察。

详细的架构流程如下：

• AI客户端到API网关层到MCP服务器：请求通过API网关层（AWS WAF、AWS Shield、AWS Application Load Balancer和OAuth验证）传递后，到达运行在AWS Fargate上的MCP服务器。

• MCP服务器到领域服务：MCP服务器通过API调用Smartsheet的领域服务以执行事务操作。

• MCP服务器到智能层：MCP服务器查询基于Amazon Neptune和Databricks构建的智能层，以获取跨项目的代理洞察。

• 领域服务到智能层：变更事件通过Amazon Kinesis和Apache Flink流式传输到基于Amazon S3的智能层。智能层遵循勋章架构。

图1：Smartsheet在AWS上的MCP服务器架构。

支持边缘保护、容器镜像仓库、可观测性、密钥管理等服务的章节将在后续相关部分进行说明。

部署与扩展

在扩展性方面，AI流量模式与传统请求模式存在显著差异。代理会自主编排工具调用序列，在执行任务时每秒可能触发多次请求，随后在模型推理阶段会进入静默状态。这种突发性流量模式要求扩展策略能够同时应对突发流量高峰和持续吞吐量需求。

为处理和验证这种模式，Smartsheet构建了基于AWS Fargate（Amazon ECS）运行的MCP服务器。ECS自动扩展结合流量体积与计算资源利用率，采用目标跟踪策略。计算感知型扩展在此场景中尤为重要，因为每个请求都涉及服务器端处理（如LLM优化的序列化），而不仅仅是代理操作。在生产级流量模式下的大量负载测试验证了基础设施能够吸收代理突发流量而不会出现性能下降。

在部署层面，更新推送时避免干扰正在进行的代理会话同样关键。容器镜像存储在Amazon Elastic Container Registry（Amazon ECR）中，通过持续集成与持续交付（CI/CD）流水线进行分层安全防护的灰度发布。ECS部署熔断器在发布过程中检测故障容器，并自动回滚到上一个稳定版本。无需人工干预，可完全避免对客户的影响。

部署时遵循AWS Well-Architected原则，优先向最小区域推送更新以缩小影响范围。每个区域更新后，自动化端到端测试会验证工具行为与生产环境的一致性。每15分钟执行一次金丝雀测试，完整执行包含完整认证和网关路径的多步骤MCP工作流。测试结果会反馈到监控系统，确保在客户报告之前就能发现性能退化。ECS Fargate配合ALB的部署模式详见AWS MCP服务器部署指南。

治理与可观测性

对企业客户而言，治理是AI采纳的关键制约因素。Smartsheet将治理机制直接嵌入工具框架：访问控制、错误处理和审计追踪功能默认随所有工具一同交付。

按组织层级实施分级访问控制：管理员可全局开启AI访问权限，限制为仅非破坏性操作，或开放完整的写入和破坏性功能，使每个组织都能掌控自身的采纳节奏。工具携带MCP协议注解（如readOnlyHint和destructiveHint），使AI客户端能自动应用相应的确认流程。

服务器在整个请求生命周期中持续发出OpenTelemetry信号（日志、追踪和指标）。每次工具调用都会在隐私约束范围内捕获最大上下文信息：用户、组织、工具名称、执行结果等。这为使用洞察分析和合规审计提供了基础数据支持。

Agent 流量比传统 API 流量更难观测。单个用户请求可能产生一系列工具调用，故障通常需要回溯多个步骤。Smartsheet 正通过以 Agent 为中心的身份识别和追踪功能扩展其可观测性，实现跨工具链的上下文关联。日志通过 Amazon Kinesis 流入 Amazon OpenSearch Service，遵循 AWS 可观测性最佳实践模式，基础设施指标通过 Amazon CloudWatch 汇总。Datadog 提供按工具划分的应用性能监控（APM）可见性，PagerDuty 负责事件路由。

每次调用还会通过 Amazon Simple Queue Service（Amazon SQS）将结构化分析事件发送到智能层。这形成了反馈闭环：生产使用数据决定了应优先哪些工具，以及优化策略在实际工作负载中的表现。

保护 AI Agent 流量

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 管道（GitLab CI 配置 AWS 主机的 runner）中运行，并作为金丝雀测试持续针对每个生产 AWS 区域执行。

针对 AI 使用进行优化

随着企业扩展AI代理部署，令牌消耗成为真正的成本驱动因素。每个工具响应都会在大型语言模型（LLM）上产生费用，并争夺上下文窗口容量。目前大多数MCP工具调用都未采用子代理编排。代理直接依次调用工具，在每一步骤之间进行推理。缺乏智能工具设计时，这种模式会迅速变得缓慢、昂贵且容易出错。每个工具调用必须独立且高效，这也是Smartsheet在三个层面进行优化的原因：

• 渐进式披露：通过限制每个响应的令牌消耗上限来控制成本。
• 强类型工具模式：通过防止幻觉参数和无效调用来提升准确性。
• 专有序列化格式：在数据密集型响应中减少35至47个百分点的令牌数量。

渐进式披露

每个工具响应都针对一个令牌预算进行优化。服务器会根据列数和数据密度动态计算可容纳的行数。例如，一个包含5列的表格可以返回比15列表格更多的行数，但总数始终控制在预算范围内。无论表格包含50行还是50,000行，响应大小始终保持在限定范围内。模型首先获取足够信息以确定方向，然后根据用户实际查询内容应用过滤条件缩小范围。

元数据字段向模型明确说明发生了什么：is_sampled表示数据是否被截断，rows_in_sheet提供完整行数，rows_actual显示实际返回行数，filters_applied描述当前应用的过滤条件。模型利用这些信息判断是否已获得完整数据，或需要通过过滤条件进一步缩小查询范围。渐进式披露是服务器端决策机制。MCP服务器负责预算分配和抽样处理，而返回的元数据为AI客户端提供了自主协调后续查询的信号。

图2：渐进式披露的实际应用：AI客户端接收包含元数据的抽样数据，随后发起针对性的后续请求。

保持LLM稳定性：模式驱动的工具契约

确保LLM稳定性至关重要。缺乏约束时，模型会幻觉生成参数名称、发明运算符，并在失败调用上浪费令牌。每个工具通过MCP的工具发现功能发布严格的JSON Schema，该Schema由Pydantic模型生成。参数被限制为有效枚举值，列名在执行前会与实际表格验证，不匹配情况会返回包含有效选项的结构化错误，而非静默失败。模式验证在边界处捕获幻觉，使代理能够可靠地导航工具目录，无需反复试错。

令牌高效序列化

JSON的结构开销（括号、引号、重复键）通常会消耗响应令牌总数的15至25%。对于返回包含数千行的电子表格数据的服务器，这种开销会迅速累积。

Smartsheet构建了专有的序列化格式来缓解这一问题。关键名称只需声明一次而非每行重复，结构语法被更高效的分隔符替代。在代表性33项过滤查询中，优化后的响应约为3,900个令牌，而等效JSON响应约为6,000个令牌，信息量相同的情况下减少约35%。在1,000行数据时差距进一步扩大，因为JSON会在每个对象中重复键名称，而优化格式只需声明一次。

AI代理目前通过MCP与Smartsheet集成。在一般可用性（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文档。

作者简介

'"{ /think