AI 智能体如何安全地连接数据并执行业务流程？Amazon Bedrock AgentCore 架构解析

AI 智能体正在为企业运营自动化开辟一种新方式：它不再只是按要求回答问题或生成内容，而是能主动搜索信息、分析数据、选择工具并执行多个处理步骤来完成任务。但要让智能体在企业环境中运行，一个重大挑战随之而来：如何让智能体访问正确的数据、使用正确的工具，并在被允许的权限范围内采取行动？在 Machine Learning cơ bản 群组的一篇帖子中，作者 David Nguyen 介绍了 AWS 推出的 Agentic AI 架构——Amazon Bedrock AgentCore，其中包含支持构建、连接、保护和运营 AI 智能体的组件，而通过 MCP 的连接、身份管理、工具使用权限控制和活动监视是其中的关键要素。

快速回答

• 通过 MCP 与 AgentCore Gateway 连接：数据和业务功能散落在数据库、CRM、ERP、数据仓库和内部应用中；Amazon Bedrock AgentCore Gateway 是中间层，把 API、AWS Lambda 函数和 MCP 服务器连接成智能体可以发现和使用的工具。MCP（Model Context Protocol）提供了智能体与外部工具和数据源通信的标准协议——发现工具、了解工具的功能与参数、发送执行请求并接收结果。
• Context Engineering 帮助智能体正确理解数据与业务：Amazon Bedrock Knowledge Bases 支持 RAG 机制，让智能体检索信息作为模型的上下文；Semantic Layer 提供关于数据的语义信息——Schema、表之间的关系和业务指标定义——让智能体确定需要挖掘的数据，而不是仅凭表名判断。
• 工具调用让智能体从回答问题走向执行任务：在 AWS 的 Data Mesh 架构中，get_user_tables（用户有权访问的表）、get_schema（表结构）、run_query（通过 Amazon Athena 的只读 SQL 查询）和 kb_search（Knowledge Bases 语义搜索）等 MCP 工具，让智能体执行一连串操作：发现数据、了解结构、选择来源、查询并用结果回答。
• 在系统层面进行安全与访问控制，而不只是依靠模型自我约束：AgentCore Identity 管理身份与身份验证，并通过 On-Behalf-Of（OBO）令牌交换机制转发用户身份上下文；AgentCore Policy 制定策略，控制智能体可以使用哪些工具；Amazon Bedrock Guardrails 控制输入/输出内容并发现 prompt injection 等风险；Gateway Interceptors 检查、转换或拦截智能体、Gateway 与后端工具之间的请求与响应。
• Runtime 与 Observability 让智能体像其他技术应用一样被运营：AgentCore Runtime 提供智能体的部署与运营环境，支持会话隔离；AgentCore Observability 跟踪执行过程与工具调用步骤，帮助企业评估性能并发现运营中出现的问题。

为什么安全连接是把 AI 智能体引入企业时最大的挑战？

AI 智能体与聊天机器人的区别在于它会采取行动：搜索信息、分析数据、选择工具并执行多个处理步骤来完成任务。正是这种行动能力，引发了帖子置于核心的问题：如何让智能体访问正确的数据、使用正确的工具，并在被允许的权限范围内采取行动？

在企业中，数据和业务功能通常分布在多个不同的系统上——数据库、CRM、ERP、数据仓库和内部应用。每个系统都有自己的访问方式、数据定义和授权机制。如果智能体连接这些系统时没有标准化的中间层、没有业务上下文、没有系统级的权限控制，企业将同时面临两种风险：智能体因为不理解数据而无法工作，或者智能体因为不受限制而越权行事。AWS 通过 Amazon Bedrock AgentCore 推出的架构，如帖子所述，用五组组件同时解决了这两个方面。

1. 通过 MCP 把 AI 智能体连接到企业系统

第一个组件是连接层。AWS 推出了 Amazon Bedrock AgentCore Gateway——中间层，把 API、AWS Lambda 函数和 MCP 服务器连接成智能体可以发现和使用的工具。

该架构中的一个关键组件是 Model Context Protocol（MCP）——AI 智能体与外部工具和数据源通信的标准协议。通过 MCP，智能体可以：

• 发现现有的工具。
• 接收关于工具功能与参数的信息。
• 发送执行请求。
• 接收结果以继续处理任务。

帖子强调的实际好处是：企业无需为每个工具单独构建集成机制，而是可以使用统一的通信层来扩展 AI 智能体的连接能力。当新增系统时，企业通过 Gateway 和 MCP 添加连接，而不必为每个智能体重写集成。

2. Context Engineering：帮助 AI 智能体正确理解数据与业务

部署 AI 智能体的挑战之一，是在企业语境中正确理解数据的含义。帖子举例：当用户要求分析收入时，智能体需要确定合适的数据来源、理解收入指标的定义以及相关表之间的关系。只知道表名和列结构是不够的——这个系统中的「收入」定义可能与另一个系统不同。

AWS 提到了支持这一过程的两个组件：

• Amazon Bedrock Knowledge Bases——支持 Retrieval-Augmented Generation（RAG）机制，让智能体从知识来源检索信息，并将搜索结果用作模型的上下文。
• Semantic Layer——提供关于数据的语义信息，包括 Schema、表之间的关系和业务指标定义。

在帖子引用的 AWS Autonomous Business Insights 架构中，智能体可以在选择 MCP 连接器从 Amazon Redshift、Amazon Aurora 和 S3 Tables 等系统检索数据之前，先探索 Semantic Layer。这样，智能体就有了更多信息来确定需要挖掘的数据，而不是仅凭表名或原始数据结构判断。这正是 Context Engineering 的含义：准备上下文让模型正确理解，而不是让模型自行猜测。

3. 工具调用：从回答问题到执行任务

工具调用（tool calling）是让 AI 智能体与外部系统交互并执行具体处理步骤的要素——也是智能体与只根据已有信息生成回复的系统的区别所在。

在 AWS 的 Data Mesh 架构中，帖子列出了支持智能体发现和查询数据的四个 MCP 工具：

工具	功能
get_user_tables	获取用户有权访问的数据表列表，通过 AWS Glue Data Catalog 和 Lake Formation
get_schema	获取表结构，包括列名、数据类型和描述
run_query	通过 Amazon Athena 在 Iceberg 表上执行只读 SQL 查询，并结合数据访问控制
kb_search	在 Amazon Bedrock Knowledge Bases 上进行语义搜索，带元数据过滤

通过这些工具，智能体可以执行一连串操作：发现数据、了解结构、选择信息来源、查询并用结果回答请求。值得注意的是，run_query 只执行只读 SQL——一个有意的限制：智能体可以读取和分析数据，但不能通过这个工具擅自修改数据。这就是工具设计对安全的贡献，此外还有下一节中的控制层。

4. 安全与访问控制：确保 AI 智能体在权限范围内运行

当 AI 智能体可以访问数据并执行工具时，安全就成为架构中不可分割的要求。帖子列出了 AWS 提供的四种控制智能体活动的机制：

• Amazon Bedrock AgentCore Identity——支持身份管理、身份验证和凭证管理，让智能体访问 AWS 资源或外部服务。On-Behalf-Of（OBO）令牌交换机制还支持将用户的身份上下文转发到后端系统——意味着后端知道请求是代表哪位具体用户发出的，而不只是看到一个共享的智能体身份。
• Amazon Bedrock AgentCore Policy——允许制定策略，控制智能体可以使用哪些工具，基于已确定的条件和权限。
• Amazon Bedrock Guardrails——支持控制输入和输出内容，发现 prompt injection、不当内容和敏感信息等风险。
• Gateway Interceptors——允许在智能体、Gateway 与后端工具交互过程中检查、转换或拦截请求与响应。

帖子强调，AWS 方法中的重要一点是不只依赖 AI 模型自我约束的能力。访问权限和执行必须由系统级的安全机制来控制。模型可以被指示「只做这个、别做那个」，但语言指示不是访问控制——真正的控制在于身份、策略、网关和基础设施中的拦截层。

5. Agent Runtime 与 Observability：运营和监视 AI 智能体

企业环境中的 AI 智能体需要像其他技术应用一样被部署和监视——不能是一个运行在某处、无人能跟踪的「黑盒」。

• Amazon Bedrock AgentCore Runtime 提供部署和运营智能体的环境，支持会话隔离并处理智能体的交互。
• AgentCore Observability 支持跟踪智能体的活动，包括执行过程和工具调用步骤。

这些能力帮助企业跟踪活动、评估性能并发现运营中出现的问题：智能体调用了哪些工具、按什么顺序、带什么参数、结果如何——所有这些都需要留痕，以便在发生事件时复查或在需要改进时参考。

将 Runtime、Gateway、Identity、Policy 和 Observability 结合起来，企业可以构建一个环境，让 AI 智能体在受管理的范围内与外部系统交互——这是帖子的结论，也是对其开篇问题的回答：智能体的安全不是来自单一组件，而是来自多层架构的协同工作。

常见问题

MCP 在连接 AI 智能体与企业系统中起什么作用？

MCP（Model Context Protocol）是 AI 智能体与外部工具和数据源通信的标准协议。通过 MCP，智能体发现可用工具、了解其功能与参数、发送执行请求并接收结果。结合 Amazon Bedrock AgentCore Gateway——连接 API、AWS Lambda 函数和 MCP 服务器形成工具的中间层——企业获得了一个统一的通信层，而不必为每个工具单独构建集成。

Context Engineering 与仅仅给智能体数据库访问权限有什么区别？

数据库访问只让智能体看到表名和列结构；Context Engineering 让它理解企业语境中数据的含义。按帖子的说法，Amazon Bedrock Knowledge Bases 支持 RAG，让智能体检索知识作为上下文，而 Semantic Layer 提供 Schema、表之间的关系和业务指标定义——例如「收入」是如何定义的。这样，智能体就能确定需要挖掘的正确数据，而不是从表名猜测。

AWS Data Mesh 架构中的四个 MCP 工具是做什么的？

get_user_tables 获取用户有权访问的表（通过 AWS Glue Data Catalog 和 Lake Formation）；get_schema 获取表结构，包括列名、数据类型和描述；run_query 通过 Amazon Athena 在 Iceberg 表上执行只读 SQL 并结合访问控制；kb_search 在 Amazon Bedrock Knowledge Bases 上进行带元数据过滤的语义搜索。这一连串工具让智能体发现数据、理解结构、选择来源、查询并回答。

如何确保 AI 智能体在执行工具时不越权？

按帖子的说法，AWS 在系统层面进行控制，而不是只依赖模型自我约束：AgentCore Identity 管理身份并通过 OBO 令牌交换机制转发用户上下文；AgentCore Policy 制定智能体可用工具的策略；Amazon Bedrock Guardrails 控制内容并发现 prompt injection；Gateway Interceptors 检查、转换或拦截智能体、Gateway 与后端工具之间的请求/响应。工具设计也有贡献——例如 run_query 只允许只读 SQL。

在企业中运营 AI 智能体需要监视什么？

按帖子的说法，AgentCore Runtime 提供带会话隔离的部署与运营环境，AgentCore Observability 跟踪执行过程和工具调用步骤。企业由此可以跟踪活动、评估性能并发现问题——智能体调用了哪些工具、按什么顺序、结果如何——就像监视其他技术应用一样。

结语

David Nguyen 的帖子展示了企业 AI 智能体的完整架构图景：Gateway 和 MCP 负责连接，Knowledge Bases 和 Semantic Layer 负责上下文，工具调用负责执行，Identity/Policy/Guardrails/Interceptors 负责权限控制，Runtime 和 Observability 负责运营。核心信息是：AI 智能体的安全不是来自对模型的叮嘱，而是来自多层架构——每一层各负其责，各层协同工作，让智能体只访问正确的数据、只使用正确的工具、在正确的权限范围内行动。这是 AI 智能体从令人印象深刻的演示走向企业实际运营的条件。

来源：David Nguyen 于 2026 年 11 月 11 日在 Facebook 群组 Machine Learning cơ bản 发布的帖子，介绍 AWS 推出的 Agentic AI 架构与 Amazon Bedrock AgentCore。由 Wotech Electronics 编辑整理。插图：原帖附带的架构图。