Amazon AWS 将自主商业洞察变成一个配置问题

Amazon AWS 推出了一种 AgentCore 架构，以托管式配置取代了跨系统商业智能背后大量的自定义代码。该设计通过 Model Context Protocol 服务器将 AI agent 连接至多个企业系统，同时利用策略控制限制每位用户可访问的内容。

这种组合正是其中真正的张力所在。自然语言分析已存在多年，但可信赖的跨系统访问仍然需要集成工作、身份映射、会话管理和安全审查。AWS 现在主张，其托管 agent 平台能够承担更多这类运营负担。

目标并不是在单一仪表盘之上再叠加一个聊天机器人，而是一个能够选择获批工具、从多个系统收集证据、保留有用上下文并综合生成答案的 agent。同时，它还必须保留提问者原本已有的访问边界。

这给传统的自定义集成技术栈带来了压力。企业通常一次一个接口地将分析助手连接至数据库和应用程序。每项连接都带来独立的认证逻辑、模式、权限、错误处理和维护工作。

AWS 推出的商业洞察架构提供了另一条路径。管理员可配置标准化连接器、策略、身份流程和记忆，而不必将每条规则都嵌入 agent 代码中。

这一主张值得谨慎看待。托管组件可以减少重复工程工作，但配置并不能消除架构设计、测试或治理。它只是将这些责任转移到企业必须理解并持续检查的控制层中。

Amazon AWS 将商业问题转化为受治理的 Agent 工作

重要的变化不在于 agent 能够回答问题，而在于它能够通过一次对话请求协调多个受治理的系统。

设想一位区域销售负责人询问，为什么某个市场的续约表现走弱。一份有价值的回应可能需要客户记录、支持工单、账户活动、产品使用情况和历史业绩。这些数据源很少共享同一套模式或权限模型。

传统助手通常只搜索一个已建立索引的资料库。更具雄心的系统则依赖开发人员为每个数据源构建的自定义函数。应用程序必须决定调用哪个函数、转换参数、对请求进行认证，并解读响应。

Amazon AWS 的设计将 AgentCore 置于对话 agent 与这些系统之间。AgentCore 是 AWS 用于部署和运营 agents 的托管基础，包括网关、身份、记忆、运行时、策略和可观测性服务。

MCP，即 Model Context Protocol，为 agents 提供了一种发现和调用外部工具的标准方法。MCP 服务器通过一致的接口描述可用能力、接受的输入和返回的信息。

预构建的 MCP 服务器连接器降低了从零开始创建该接口的需求。团队无需在 agent 内部编写独立的集成逻辑，而是可以注册获批服务器，并通过 AgentCore Gateway 公开其工具。

该网关提供一个统一入口。AWS 文档称，它可以将 MCP 目标聚合为一个虚拟服务器，使客户端能够通过标准发现操作获得合并后的许可工具列表。

这很重要，因为工具发现可以根据身份作出响应。财务主管可能看到收入和支出工具，而销售经理则获得区域和销售管道能力。agent 不需要向每位员工提供同一套不受限制的工具目录。

随后，agent 会解读问题、发现可用工具，并选择完成任务所需的数据源。它可以将返回的证据组合成回应，而无需用户手动在多个应用程序之间切换。

持久记忆带来了连续性。AgentCore Memory 存储对话事件和存续时间更长的信息，使 agent 能够在交互之间保留相关上下文。其用途不只是重放聊天记录。

经理可能在此前的交流中设定偏好的区域、报告周期或业务定义。记忆可在已配置的命名空间和保留规则约束下保存这些细节，从而让后续请求减少重复说明。

AWS 表示，AgentCore Memory 支持加密信息、按时间顺序的事件存储，以及用于组织和访问控制的分层命名空间。其持久 agent 记忆还可以在最长 365 天的配置期限内保留原始事件。

最终工作流之所以看起来具有自主性，是因为 agent 会选择并编排工具。不过，可执行的操作仍来自管理员控制的环境。自主性是在既定边界内运行，而非取代这一边界。

这一区别对于商业智能至关重要。agent 应足够灵活，能够调查一个问题；同时也应受到足够约束，避免访问无关记录、受限功能或未经批准的外部服务。

为什么配置改变了商业智能的经济性

AWS 正将集成负担从应用程序特定代码转向可复用基础设施，使其能够服务多个 agents 和业务团队。

自定义分析助手会迅速积累代码。一个团队为客户平台编写连接器，另一个团队构建略有不同的版本，第三个团队又为同一服务创建独立的认证处理。

这种重复会拖慢部署，并造成控制措施不一致。安全团队必须检查多个访问同一底层数据的实现。API 或身份提供商的变更可能会触发对多个应用程序的修复。

配置驱动层改变了团队投入精力的位置。他们仍需定义数据源、权限、工具说明和业务规则，但无需在每个 agent 内部重复构建相同的传输和凭据模式。

AgentCore Gateway 是这一转变的核心。AWS 将该网关描述为一个标准化入口，agents 可通过它发现并与工具、其他 agents 和模型交互。

对于 MCP 目标，该网关会聚合能力并通过单一接口公开。它可以连接现有 MCP 服务器、API、Lambda functions，以及该服务支持的其他目标类型。

该网关还将入站授权与出站授权分离。入站控制决定 agent 或客户端能否进入网关；出站控制则决定网关调用目标系统时如何进行认证。

这一划分很容易被忽略，但它解决了一个常见的企业问题：用于访问 agent 的身份，不应自动变成拥有不受限制下游权限的可复用凭据。

AgentCore Identity 可以管理这些下游调用所需的凭据和 token 交换。根据目标和部署方式，该平台支持基于 AWS IAM 的授权和 OAuth 模式。

配置也让连接器更具可复用性。一旦获批的 MCP 服务器公开某项业务能力，另一位已获授权的 agent 便可发现该能力，无需将原始集成复制到新的代码库中。

这并不意味着每台服务器都应公开原始数据库访问。更安全的设计是提供范围有限、面向业务的工具，例如获取获批的账户指标，或汇总已授权的支持趋势。

清晰的工具说明也会影响 agent 的行为。模型会部分依据工具名称、模式和说明来选择工具。即使身份控制运行正常，定义不佳的能力仍可能导致错误路由。

因此，经济优势来自标准化，而不是工程工作的消失。团队创建可复用的集成和治理层，再针对具体角色在该层之上配置 agents。

AWS 已将 AgentCore 定位为生产级基础，而不是仅限于某一模型的 agent 构建器。该平台于 2025 年 10 月正式全面推出时，公司表示其软件开发工具包的下载量已超过一百万次。

这一生产级 agent 平台还支持包括 CrewAI、LangGraph、LlamaIndex、Google ADK、Strands Agents 和 OpenAI Agents SDK 在内的框架。它并不局限于单一编排框架。

这种灵活性可以帮助企业避免将每项集成都绑定到单一模型或 agent 库。当推理组件发生变化时，网关和 MCP 层仍可保持稳定。

它也扩大了 AWS 的竞争地位。云服务提供商、企业软件厂商和自动化平台正日益希望掌控 agents 与企业系统之间的连接层。

最有价值的一层可能并非生成最终段落的模型，而是受治理的目录：它决定 agent 能发现哪些工具、获得哪些凭据，以及记录哪些操作。

对于企业买家而言，实际问题在于，连接器复用能否在不隐藏关键控制措施的前提下缩短部署时间。只有当管理员仍能追踪访问、检查策略并纠正故障时，更快的设置才有意义。

自定义集成技术栈如今面临压力

主要竞争在于可复用、受策略治理的配置，与历史上将助手连接至企业数据的自定义胶水代码之间。

自定义开发仍保留明显优势。它让团队能够精确控制查询、转换、故障行为和应用程序接口。它也可以支持缺少可用 API 或 MCP 服务器的特殊遗留系统。

这种控制伴随着运营成本。定制连接器需要明确归属、测试、凭据轮换、监控和更新。这项工作会在最初的演示成功后持续存在。

MCP 标准化了 agent 与工具之间的接口，但它并未标准化每个工具的质量。两台服务器可能公开相似的系统，却拥有不同的模式、授权行为和运营可靠性。

AgentCore 试图通过托管网关来容纳这种差异。它的角色类似一个企业服务层，只是面向模型驱动的工具选择，而非固定的应用程序调用。

这种区别改变了新用例进入生产环境的方式。沿用自定义路径时，团队可能需要设计应用程序、编写每项集成、实现会话存储，并在之后补充监控。

沿用配置路径时，团队则从获批能力出发。它选择网关目标、映射身份、定义策略、配置记忆，并提供塑造 agent 决策的指令。

这可以减少重复代码，尤其是在多个 agents 需要访问同一系统时。同时，它也使中央平台团队变得更加重要，因为本地产品团队依赖于其连接器目录和治理选择。

Amazon AWS 并非唯一在布局这一层的厂商。ServiceNow 已通过其 AI Control Tower 推出受治理的企业 MCP 注册中心。Workato 则推广了面向企业应用的预构建 MCP 服务器目录。

这些产品反映出相同的市场方向。企业希望智能体能够使用现有系统，但不希望每个开发团队各自连接未经审核的工具。

因此，竞争边界远不止 AWS 与其他云服务商之间的较量。它还涵盖集成平台、企业应用厂商、数据平台和内部开发者门户。

每个竞争者都希望成为工具注册与控制的可信入口。胜出的那一层将获得对智能体活动的可见性，并影响企业向模型开放业务运营能力的方式。

当一家组织的数据、应用和身份基础设施已运行在 AWS 云上时，AWS 具备优势。IAM、Lambda、CloudWatch、PrivateLink 及其他 AWS 服务可在同一运行环境中协同参与。

然而，许多业务问题会跨越云平台和软件供应商。客户记录可能存放在 Salesforce，文档位于 Microsoft 365，工单在 ServiceNow，而分析数据则位于独立的数据仓库中。

因此，这一架构必须能够超越原生 AWS 资源而成功运作。OAuth 支持、第三方 MCP 兼容性以及代表用户执行的身份流，比一长串 AWS 集成更为重要。

AgentCore Gateway 在 2026 年新增了更广泛的 MCP 功能，包括动态列表、会话、提示词、资源、流式传输和委托身份验证。AWS 表示，动态列表允许目标仅返回当前用户可用的能力。

这一功能缩小了授权与发现之间的差距。如果用户无权合法调用某项工具，智能体就不应在其工具目录中获得该工具。

该网关的扩展 MCP 控制功能还包括 OAuth 2.0 代表用户令牌交换。这使下游系统能够同时评估智能体和原始调用者。

自定义代码同样可以实现这一模式。区别在于，托管服务能否在不削弱控制措施的前提下，使数十个团队能够充分重复使用这一模式。

这正是正在接受检验的承诺。AWS 并未声称业务逻辑会消失。它主张，连接、身份、记忆和策略应成为共享基础设施，而不是反复编写的应用代码。

Amazon Bedrock AgentCore 如何连接工具、策略与记忆

只有当身份、工具发现、授权、执行和记忆在整个请求过程中始终保持一致时，这一架构才能发挥作用。

用户以自然语言提出问题。客户端对该用户进行身份验证，然后将请求发送给一个以独立工作负载身份运行的智能体。

这种分离至关重要。智能体并非简单地冒用员工身份并附带其全部权限。它拥有自身身份，同时代表已验证身份的用户行事。

智能体评估请求，并向网关询问有哪些工具可用。在动态列表模式下，MCP 目标可以返回用户专属的工具列表，而非固定目录。

随后，模型选择一项或多项能力。对于营收问题，它可能会先请求获批准的销售汇总数据，再从另一系统中检索相关客户趋势。

在执行前，策略控制会评估拟议调用是否应继续。此时，诸如数据库访问这样的宽泛权限，可以转化为涉及用户角色、工具名称和请求参数的精细决策。

AgentCore Policy 可以集中处理这些决策。AWS 表示，策略可采用其授权策略语言 Cedar 表达，也可由自然语言描述创建并转换为正式规则。

策略执行必须发生在工具运行之前。事后过滤答案，无法可靠地撤销未经授权的数据库查询或外部操作。

获准调用会经由网关传递至 MCP 目标。网关会提供适当的下游凭据，或将用户令牌交换为面向该资源的范围受限令牌。

目标检索经授权的信息，并返回结构化结果。智能体可以检查这些结果，判断是否需要另一项工具，并继续推理流程。

这正是自主行为进入工作流的环节。开发者无需预先规定每一条路径。模型会根据问题、可用能力、中间发现及其指令选择执行序列。

智能体最终将证据整合为回复。生产系统应尽可能保留引文或可追溯的来源引用，尤其是在答案会影响财务或运营决策时。

记忆随后可以存储交互中的选定内容。短期记忆支持会话内的连续性，而长期策略则可提取持久的偏好、事实或摘要。

记忆命名空间应反映与工具相同的组织边界。为某位员工、部门或租户记住的有用事实，不得在之后未经授权的上下文中悄然出现。

AgentCore 会话也会在网关调用之间保留状态。AWS 文档称，经过身份验证的网关会话会将其会话标识符绑定到经验证的用户身份。

默认网关会话超时时间为一小时，可配置范围为 15 分钟至八小时。这一会话功能不同于长期业务记忆，尽管两者都会促进连续性。

可观测性使整个闭环得以完成。管理员需要追踪记录，以了解发现了哪些工具、智能体尝试了哪些调用、哪些策略阻止了请求，以及最终答案是如何构建的。

没有这些记录，配置会变得比代码更难调试。故障可能源于模型的工具选择、模式描述、策略规则、过期凭据，或源数据本身。

因此，这一架构改变了开发者的工作，而不是消除了它。投入到重复连接代码的精力会减少，而投入到工具设计、评估、策略测试和运行检查的精力会增加。

对知识工作者而言，可见的结果更简单。他们可以提出一个问题，而无需手动核对多个系统。在这场对话背后，是一条必须在每一步都保留身份信息的基础设施链路。

这一模式也类似于知识融合：当相关上下文能够在不丢失来源的情况下被组合时，答案会更有价值。企业智能体增加了更严格的要求，因为每个来源都带有访问规则。

细粒度访问控制仍是真正的考验

这一架构的成败取决于其权限能否经受多步骤推理的考验，而非最终答案是否流畅。

一段润色完善的回复可能掩盖严重错误。智能体可能使用未经授权的来源，将两个分别获准的数据集组合为受限推断，或在共享记忆中保留敏感细节。

基于角色的访问控制通过将权限与组织角色关联，提供了初始边界。然而，大型企业往往还需要地理位置、账户归属、租户、数据分类和交易类型等属性。

当智能体动态规划多个步骤时，这些条件会变得更加复杂。每一次调用都必须携带足够经验证的身份和上下文，使目标系统能够作出正确决策。

AWS 的多租户指南建议在策略、调用和数据层面实施控制。其中包括运行时策略、工具级验证，以及对底层记录实施基于属性的限制。

这种分层方法必不可少，因为仅凭网关决策无法保证数据隔离。源系统在返回信息时仍应强制执行行级或资源级规则。

该多租户设计还采用代表用户的令牌交换，使下游服务能够识别原始调用者。这在智能体与服务边界之间保留了上下文。

然而，策略可能出错。由自然语言规则转换而来的 Cedar 规则，仍需要审查、测试和版本控制。管理员必须确认正式结果与预期的业务限制相符。

工具描述可能带来另一项弱点。如果两项能力看起来相似，模型可能选择范围更广的那一项。权限应防止造成损害，但令人困惑的目录会增加失败调用和不可预测行为。

MCP 服务器本身也需要审查。该协议定义的是通信模式，而非通用安全认证。企业需要获批准的注册中心、所有权记录、依赖项审查以及服务器更新流程。

提示词注入带来相关风险。嵌入在检索文档中的恶意指令可能试图重定向智能体、泄露信息或调用另一项工具。

控制层应将检索到的内容视为数据，而非权威指令。在智能体读取不可信来源后，工具权限、策略检查、验证和模型安全防护仍必须持续生效。

持久记忆会形成第二条污染路径。如果记忆策略在缺乏充分过滤的情况下保存误导性或敏感性陈述，这些内容可能在原始会话结束后依然存在。

团队需要明确规定系统记住什么、保留多久、谁可以检索，以及用户如何更正或删除。记忆不应变成一个不可见的次级数据库。

准确性同样仍未解决。访问更多系统并不保证正确解读。不同应用对营收、活跃客户或续约率的定义可能彼此不兼容。

负责任的实施应公开来源谱系和业务定义。它应区分检索到的事实与模型生成的解读，并标记冲突，而不是悄然选择某一项指标。

自主业务洞察也需要超越标准答案质量的评估。团队应测试权限拒绝、跨角色隔离、格式错误的工具结果、过期凭据、不完整数据以及操纵智能体的尝试。

对于重要决策，人类审查仍然适当。智能体可以加速调查并汇集证据，但不应获得批准支出、修改预测或更改客户记录的权限。

配置可以让这些边界更易于复用，但也可能广泛传播错误。一个有缺陷的共享策略或连接器可能同时影响多个智能体。

这种集中化既是平台的优势，也是其最大的运营风险。共享控制减少重复工作，而共享故障则提高了分阶段发布、审计追踪和快速回滚的重要性。

AWS 提供了构建此类控制平面的组件。企业仍需负责数据分类、策略意图、服务器审批、评估标准和事件响应。

三个信号将显示这一模式是否有效

下一项考验是，企业能否大规模复用这些组件，而不以配置复杂度取代自定义代码复杂度。

第一个信号是连接器能否在真实部门间复用。买方应关注，一台获批准的 MCP 服务器能否支持多个智能体，而不必为每次部署分别进行权限工作。

成功的复用将强化 AWS 的论点。这将表明，标准化工具和集中式凭据确实能够减少反复出现的集成工作。

反复出现的例外情况会削弱这一能力。若每个业务部门都需要专用服务器、自定义 schema 或独立的身份验证变通方案，配置就会变成另一种形式的定制工程。

第二个信号来自授权测试的证据。企业应公布或讨论：在贴近实际的多步骤任务中，AgentCore 策略拦截未授权工具、记录和记忆的频率。

简单演示通常只分配一个角色并提出一个问题。生产环境评估则必须测试职责重叠、负责区域变化、临时访问权限，以及多个下游系统的用户场景。

有力的结果应表明，授权会跟随原始用户，贯穿网关发现、工具调用、数据检索和记忆全过程。同时还应为每一次被拒绝或获准的操作提供清晰记录。

任何一个阶段出现故障，都会动摇这一核心承诺。安全网关无法弥补目标范围过宽的问题，而限制严格的数据库也无法纠正已存入共享记忆的机密信息。

第三个信号是持续部署带来的运营证据。团队应衡量答案可追溯性、工具选择错误、策略拒绝、连接器故障、延迟，以及新增或修改数据源所需的时间。

这些指标将揭示托管组件是否能减少总体持有与运维工作量。若持续调试仍需要专家检查多个不透明层级，那么短暂的初始设置并不足够。

竞争对手的反应同样重要，但属于辅助证据。ServiceNow、Workato、Microsoft、Google Cloud、数据平台供应商和内部平台团队都在构建受治理的 agent 连接层。

它们的进展将促使 AWS 支持更多第三方系统，提供更清晰的策略工具、可移植的 MCP 部署，以及覆盖混合环境的一致可观测性。

对企业买家而言，当前行动并不是连接所有系统。应先从一个范围明确的问题入手：它已需要两个或三个获批数据源，并且业务定义清晰。

定义预期答案、允许访问的记录、禁止访问的记录，以及可接受的工具调用顺序。然后使用多个角色、对抗性输入、缺失数据和相互矛盾的指标，对同一请求进行测试。

在扩展访问权限前检查每一条追踪记录。应将记忆视为受治理的数据存储，而非方便的配置选项。要求每个 MCP server 都有明确负责人、有限用途和已记录的身份验证路径。

Amazon AWS 已令人信服地表明，自主商业智能可以变得更易配置、也更可复用。接下来的几个月必须证明，当真实组织、身份和例外情况出现时，这一控制层是否仍然易于理解。

对你的团队而言，实际问题很直接：你们能否证明，一条自然语言答案遵守了其底层系统已实施的每一项边界？