7.0
热点
AI SCORE
编程提效2026-07-29 23:34
Bedrock Agent 和 MCP 驱动无代码商业智能
AWS ML Blog#Agent#AWS#MCP
Editor brief · 编辑速览
展示 Amazon Bedrock AgentCore 通过 MCP 服务器连接器实现无代码跨系统数据查询，支持自然语言交互多个数据源。对想快速构建 Agent 应用的开发者有参考价值。
Sarah Chen 管理着 12 条装配线和 2,000 台机器。在上午 10 点的生产评审会之前，她需要得到一个答案：本周哪些生产线需要重点关注？
问题很简单，过程却令人痛苦。
她先打开 IoT 仪表板。4 号生产线的电机温度比基准值高出 12°C，而且这种情况已经持续了三天。是校准漂移，还是轴承故障？仪表板只能显示信号，无法说明原因。于是，她转到 ERP 系统中查看维护历史记录。42 号机器的轴承在八个月前更换过。保修期标注为 12 个月，但埋藏在另一个历史数据库中的运行时长日志显示，自 1 月以来，这台机器一直以额定产能的 130% 运行。
这些上下文在 IoT 仪表板中完全不存在。
她调出过去 30 天的 OEE 趋势。4 号生产线的可用率从 94% 降至 87%。9 号生产线的吞吐量也下降了 6%。两者是否相关？它们共用一个冷却液回路，但任何系统都没有对这种关系进行建模。她又查看缺陷率。上周二，4 号生产线的废品率上升了 2.3%。9 号生产线目前还没有异常。是冷却液的推测错了，还是 9 号生产线的异常只是尚未显现？
她给三位主管发送了电子邮件。直到上午 11:15，她终于得到了一个有把握的答案。
在楼下两层，生产线主管 Raj Patel 正在对 7 号生产线进行同样的分析，但他无权访问分析仪表板，只能使用一份数据已经过时三天的 PDF 导出文件。维护技术员 Priya Nair 只想知道，她上周标记的 42 号机器振动问题是否变得更加严重。数据确实存在，但她没有查看数据的访问凭证。她询问 Raj，Raj 再去询问 Sarah 的分析师。四小时后，一份 CSV 文件终于送达。此时，Priya 已经开始处理下一张工单。
三个人，三种不同的访问级别，五个彼此割裂的系统，却使用着相同的底层数据。为了获得本应在几秒内得到的答案，他们不得不花费数小时手动拼接数据、反复切换上下文并等待。数据明明存在，却无法用同一个声音说话。
普通企业每天会使用五到八个运营和分析系统。每个系统都有自己的登录方式、查询界面和访问模型。当管理者需要跨系统视图——也就是真正能够推动决策的视图——人就成了集成层。传统 BI 仪表板只能展示昨天发生了什么。单一 AI 助手只能回答彼此孤立的问题。但两者都无法自主协调企业的整个技术栈，在恰当的时机提供具备上下文且可付诸行动的智能洞察。复杂 ETL 管道、碎片化的数据存储与访问模式，以及多个 AI 助手和 AI 智能体的管理，都会给最终用户带来更多挑战。自定义多智能体框架理论上可以覆盖完整技术栈，但从零开始构建这样一个框架需要投入数月的工程工作：自定义连接器、会话隔离、记忆基础设施、安全代码、扩缩容逻辑和编排逻辑——而这些工作都必须在回答第一个业务问题之前完成。
企业不应该仅仅为了查询自己的数据，就需要一支工程团队。真正的成本也不在于工程时间，而在于人们根据陈旧、片面的信息做出决策，而正确答案其实就存放在某个没人有时间查看的系统中。
Amazon Bedrock AgentCore 颠覆了这一模式。你不必从头构建自主智能系统，只需对其进行配置。Amazon Bedrock AgentCore 负责处理编排、安全、记忆和扩缩容，你只需提供数据源和业务规则。最终，Sarah、Raj 和 Priya 都可以使用自然语言提问，并获得综合整个技术栈、针对个人定制的答案，而无须知道答案中的每一部分来自哪个系统。
该模式分为三个步骤：
使用预构建的 MCP 服务器连接器连接现有系统，无须编写自定义集成代码。
使用简单的英文策略规则定义谁可以查看哪些内容，Amazon Bedrock AgentCore 会将这些规则转换为强制执行逻辑。
使用自然语言提问，其余工作交由 Amazon Bedrock AgentCore 编排完成。
该架构分为五层，每一层都构建在下一层之上。这种分层结构是有意设计的：它将面向用户的智能、编排、工具执行和数据访问彼此分离，使每一层都能够独立扩展和替换。
用户位于最上层，Amazon Bedrock AgentCore 是整个架构的核心，预构建的 MCP 服务器连接器位于中间层，数据基础设施则构成底层基础。每一次用户交互都要经过 Amazon Bedrock AgentCore，包括身份验证、策略、记忆和智能体，然后才能到达数据源。
图 1——使用 Amazon Bedrock AgentCore 构建的自主 BI 架构
该架构采用分层设计。用户首先通过 Amazon Bedrock 使用自然语言发起查询，由其完成意图分类和响应合成；随后查询进入 Amazon Bedrock AgentCore，由智能体在隔离运行时、网关、身份与策略强制执行、持久化记忆以及受治理的工具注册表之间编排执行。在选择数据连接器并进行路由之前，智能体会查询由 SageMaker Data Catalog 支持的语义层。该语义层会公开正确的数据源，使智能体无须硬编码逻辑，就能了解整个企业中存在哪些数据以及这些数据位于何处。借助这些元数据，智能体会将查询路由到适当的预构建 MCP 服务器连接器，例如设备、IoT 遥测、供应链、分析或自定义低代码连接器；连接器随后从底层基础设施中提取数据，包括 SageMaker Lakehouse、Redshift、S3 Tables、OpenSearch 或 Aurora。通过将元数据发现与数据检索分离，只需在 Data Catalog 中注册新数据源即可完成接入，无须编写自定义集成代码，从而让系统仅通过配置就能保持可扩展性。完整的可运行实现已在 GitHub 上提供。
架构中的每一层都对应一组独立的能力。下面将结合 Sarah、Raj 和 Priya 的实际体验，逐一介绍各个组件。
数据基础构建在 Amazon SageMaker Lakehouse 之上。这是一种完全兼容 Apache Iceberg 的开放式湖仓架构，可统一 Amazon S3 数据湖（包括 S3 Tables）、Amazon Redshift 数据仓库，以及通过零 ETL 集成连接的运营数据存储中的数据。智能体通过预构建 MCP 服务器和自定义 MCP 服务器访问这些统一数据：
预构建 MCP 服务器（配置后即可使用）：
自定义 MCP 服务器（适用于没有预构建选项的服务）：
为 Timestream 等服务构建自定义 MCP 服务器时，只需定义工具接口，并将具体工作委托给 AWS SDK：
from mcp.server import FastMCP
mcp = FastMCP("IoT Telemetry Server", port=8002)
@mcp.tool(description="Get sensor readings for a specific machine")
def get_sensor_readings(machine_id: int, metric: str = "temperature", days: int = 7) -> str:
# Validate input, query Timestream via boto3, return JSON
...
注册完成后，自定义 MCP 服务器的行为与预构建 MCP 服务器完全相同：智能体通过同一个 MCP 协议发现其工具，并以相同方式调用这些工具。这意味着，企业可以先使用面向常见服务的预构建连接器，然后逐步为专用系统或遗留系统添加自定义服务器，而无须更改智能体或编排逻辑。
模型上下文协议（MCP）是一项开放标准，定义了 AI 智能体如何发现和调用工具。在这种架构中，业务的每个领域——设备状态、IoT 遥测、供应链、质量管理——都由专属的 MCP 服务器代表。每个服务器公开一组类型化工具：get_equipment_status、detect_anomaly、check_parts_inventory。智能体调用这些工具，就像开发人员调用 API 一样。对企业来说，实用之处在于你无需从头构建这些服务器。Amazon Bedrock AgentCore 为常见系统提供了预构建的 MCP 连接器：Amazon Redshift、Amazon Aurora、Amazon OpenSearch，以及通过 OAuth 的第三方系统。对于专有或自定义系统，Amazon Bedrock AgentCore Runtime 上的低代码 MCP 服务器模板将工作量从开发降低到配置。
连接选项涵盖企业系统的全个频谱：
通过 Amazon SageMaker Catalog 的语义存储，用于正确的数据源识别、选择和查询。
关系数据库：Amazon Aurora、RDS。引入操作数据。
流服务（如 Amazon MSK），用于实时 IoT 传感器数据和事件流到 SageMaker Lakehouse。
向量存储：Amazon OpenSearch Service，支持语义搜索、通过 Amazon MSK 进行实时向量嵌入，以及 Amazon S3 中非结构化数据的混合关键字-向量查询。
具有零 ETL 功能的数据仓库和数据湖，可将数据从各种数据存储复制到 Amazon S3 Tables/Amazon Redshift（在 SageMaker Lakehouse 中）。从而存储多年的历史记录。
第三方 SaaS：通过 Amazon Bedrock AgentCore Gateway OAuth 集成的 REST 或 GraphQL API（例如 Salesforce、SAP、ServiceNow）。
MCP 服务器可以以无状态模式运行（默认，每次调用独立）或有状态模式（用于需要在会话中维护中间结果的多步骤操作）。
优势
权衡
Gateway 是每个智能体到工具的调用都经过的单一入口点。注册新的 MCP 服务器时，Gateway 执行协议握手并索引其可用工具——它们的名称、输入架构和描述。智能体不需要知道 MCP 服务器的地址。它通过 Gateway 按名称调用工具，Gateway 将请求路由到适当的服务器。Gateway 实现了三层缓存策略，旨在减少重复查询的延迟。组织范围缓存保存所有用户共享的参考数据——设备目录记录、产品列表、阈值——并每日刷新。用户范围缓存保存特定用户的最近查询结果，并尊重其访问权限。Policy 引擎确定哪些响应可以跨用户共享，哪些必须保持隔离。对于精密制造而言，这意味着工厂经理关于整个车队状态的查询可以部分从缓存提供，而 Priya 关于机器 42 的查询则限制在她的范围内。
Amazon Bedrock AgentCore Runtime 将智能体部署到 Firecracker microVM 环境中，提供隔离和安全性——与驱动 AWS Lambda 和 AWS Fargate 相同的技术——无需管理服务器并自动扩展。当 Sarah 提交她的查询时，Runtime 旋转一个专属的 microVM。Raj 的会话在另一个 microVM 中运行。Priya 的在第三个。没有共享文件系统、没有共享内存、没有共享网络。会话结束时，microVM 被销毁。多租户是运行时属性，而不是软件惯例。
在我们的实现中：deploy/agentcore/deploy_all.py 配置完整堆栈——Cognito 身份、带 Lambda 工具目标的 Gateway、Cedar 策略和请求/响应拦截器。Amazon Bedrock AgentCore Gateway 然后自动处理会话隔离、身份传播和策略执行，无需对智能体代码进行任何更改。
Amazon Bedrock AgentCore Identity 提供了强大的身份和访问管理，使智能体能够代表用户或自身访问资源或工具，具有预授权的用户同意，最小化了对自定义访问控制和身份基础设施开发的需求。Identity 与你的现有提供者（Okta、IAM、Cognito、OAuth 2.0 系统）集成，并通过 Mcp-Session-Id 头在整个调用链中传播用户上下文。支持两种流程：智能体级访问（服务对服务）和用户委派访问（智能体代表具有其限定范围令牌的特定用户）。在实践中，对于精密制造而言：
这些限制来自身份提供者。Amazon Bedrock AgentCore 通过调用链传播它们并自动执行。如果 Raj 在 Cognito 中的范围改变，系统立即反映它，无需代码更改。
在我们的实现中：src/identity/models.py 定义了三个具有显式范围的用户身份。在生产环境中，这些来自 AgentCore 自动传播的 Cognito 声明。
Amazon Bedrock AgentCore 中的 Policy 与 Gateway 集成，实时拦截每个工具调用，验证智能体保持在定义的边界内。团队使用自然语言创建策略，自动转换为 Cedar——AWS 开源策略语言——具有自动化推理，在部署前验证策略的完整性。Policy 执行发生在 Gateway 级别，在执行前拦截每个工具调用。规则跨越多个维度运行：用户角色、地理范围、数据分类、时间以及特定工具参数。一个策略可能如下所示："生产线主管只能为其分配的工厂内的生产线调用 get_equipment_status。"当 Raj 询问生产线 4 时，Gateway 评估他的身份对该规则，并在 MCP 服务器被调用前返回拒绝决定。每个决定都被记录到 AWS CloudTrail。
在我们的实现中：部署到 Amazon Bedrock AgentCore Gateway 的 Cedar 策略在基础设施级别执行细粒度访问——在 Lambda 工具目标执行前。当 Raj 查询生产线 4 时，Gateway 的 Policy 引擎根据 Cedar 规则评估他的 JWT 声明并返回拒绝。MCP 服务器不被接触。对于没有已部署 Gateway 的本地开发，src/identity/gateway_hook.py 使用 Strands Agents 的 BeforeToolCallEvent 钩子模拟此执行。
以下图表阐明了 Amazon Bedrock AgentCore Gateway 实现的端到端访问控制流程。它们展示了用户身份（通过来自 Cognito 的 JWT 声明）如何流经 REQUEST 拦截器，被 Cedar Policy 引擎评估，以及如何确定是调用 MCP 工具还是拒绝请求——所有这一切都发生在数据离开系统之前。
该 UML 风格的序列图展示了请求的完整生命周期，从用户通过 Cognito 的身份验证，到智能体的 LLM 推理，通过 Amazon Bedrock AgentCore Gateway 的充实和授权层，最后到工具执行或拒绝。
身份验证：Cognito 签发带有自定义声明（角色、line_scope、plant_scope、equipment_scope）的 JWT，编码用户的数据边界。
充实：REQUEST 拦截器解码 JWT 并将 user_context 注入工具调用参数——智能体/LLM 看不到或控制此步骤。
授权：Cedar 根据策略评估充实的请求。permit_all 基线允许访问，而 forbid_* 规则检查请求的参数是否落在用户范围内。
如果 Cedar 允许，Gateway 会将请求转发到 Lambda 工具目标。如果 Cedar 拒绝，MCP 服务器不会被调用 — 避免数据泄露。
综合：智能体接收工具结果或拒绝消息，并组成自然语言响应。拒绝时，它解释访问边界并建议范围内的替代方案。
这个对比图表演示了相同的智能体界面如何为不同用户产生不同的结果。每一行代表一个角色，从左到右流经系统组件。角色包括：
Sarah Chen（工厂经理） — 完整访问权限。查询不被拒绝，因为她的角色拥有 'has_full_access' 属性，绕过所有禁止规则。
Raj Patel（生产线主管） — 范围限定到生产线 7，工厂 2。访问生产线 4 数据的尝试在 Cedar 层被拒绝。Lambda 工具不会被调用。
Priya Nair（维护技术员） — 范围限定到机器 41-45。访问机器 72 的尝试被拒绝。智能体建议改为检查机器 42。
Amazon Bedrock AgentCore 组件突显：图表中紫色阴影区域包围了两个 Amazon Bedrock AgentCore 管理的组件：Gateway（及其 REQUEST Interceptor）和 Cedar Policy Engine。这些组件在服务器端运行，外部于智能体流程，确保 LLM 和应用代码都无法绕过授权。
确定性授权：Cedar 评估是纯逻辑 — 相同的输入产生相同的输出。不管提示注入如何，LLM 都无法影响政策决定。
故障安全：如果拦截器崩溃，上下文不被注入。Cedar 没有什么可以允许，所以结果是 DENY（默认拒绝）。
MCP 服务器隔离：被拒绝的请求不会到达 MCP 服务器。工具 Lambda 不会被调用。数据处理不会发生。计算不会被浪费。
优雅降级：智能体接收拒绝消息作为工具结果，并智能地响应：解释它可以访问的内容，建议替代方案，不会重试被拒绝的调用。
Amazon Bedrock AgentCore 内存使智能体能够从经验中学习和适应，随着时间推移构建知识，支持情节记忆以创建更类似人类的交互。内存在两个级别运行：短期内存在单个会话中捕获逐轮上下文。当 Priya 询问"显示我机器 42 上的振动趋势"，然后跟上"将其与上周比较"，第二个问题可以在上下文中理解，而无需重复机器 ID。长期内存在会话中持久化选定的见解。Amazon Bedrock AgentCore 自动提取并存储偏好、循环查询模式和会话摘要，组织到命名空间中：
在我们的实现中：src/memory/manager.py 提供两个内存层 — SessionMemory 用于对话中的逐轮上下文，MemoryManager 用于组织到用户范围和团队范围命名空间的长期见解。Priya 的长期内存保留了上周机器 42 的振动基线（3.8 mm/s），所以当她询问"它变得更差了吗？"时，智能体比较存储的读数，而无需重复上下文。在生产中，Amazon Bedrock AgentCore 内存在会话中持久化这些见解并在检索时强制执行政策 — 用户只看到来自他们授权访问的数据的内存。
Amazon Bedrock Agent 注册表使组织能够通过带有发布和批准工作流的受管目录，在组织内发现、共享和重用智能体、工具和智能体技能。新的 MCP 服务器进入注册表处于草稿状态。管理员审查并批准它们。批准后，智能体在下一次调用时自动发现新工具 — 无需重新部署。注册表还启用版本控制：更新的连接器可以与当前版本一起分阶段、测试和推广，而不会中断实时会话。这个治理模型意味着系统增量增长。新的数据源、新的工具和新的连接器通过结构化的发布和批准工作流添加，而不是对编排层的代码更改。
在我们的实现中：Semantic Layer MCP 服务器（src/servers/semantic_layer_server.py）维护数据源注册表 — 每个条目声明其可用工具、术语表、数据来源和刷新频率。智能体首先调用 discover_data_sources，它对目录进行关键词匹配并返回排名的建议。载入新数据源意味着向 DATA_SOURCES 注册表添加一个条目 — 无需智能体逻辑更改，无需重新部署其他服务器。
任何多租户系统的真正测试不是它是否对一个用户工作 — 而是它是否对许多用户同时正确工作，每个用户看到恰好他们应该看到的内容而不是更多。下面是相同的 Amazon Bedrock AgentCore 部署如何以不同方式服务 Sarah、Raj 和 Priya。
Sarah 问："这周哪些装配线需要关注？"
Amazon Bedrock AgentCore Runtime 为 Sarah 的会话创建了一个 microVM。Gateway 通过 Okta 验证她 — 角色：工厂经理，范围：所有相关装配线。智能体将意图分类为多源和操作性。它并行调用 Equipment MCP 服务器（get_equipment_status，所有工厂）和 IoT Telemetry MCP 服务器（detect_anomaly，所有生产线）。政策评估每个调用：Sarah 的角色允许所有这些。内存回忆 Sarah 偏好严重性排名的输出。合成的响应 — 装配线的排名列表，带有来自设备和传感器数据的支持证据 — 在几秒内到达。
Raj 问："生产线 7 的当前状态是什么？"
Raj 的会话在单独的 microVM 中运行。他的 Okta 令牌将他限制到仅限工厂 2、生产线 7。智能体将相同的工具调用路由到 Equipment 和 IoT MCP 服务器 — 但政策拦截调用并强制执行范围限制。