AWS Agent Infra 架构分析

范桂飓2026-10-02 10:31

目录

文章目录

Amazon Bedrock AgentCore

AWS Agent Infra 可归纳为三层：

  1. Model Infra 平台层（Amazon Bedrock / Nova）：Amazon Bedrock 与其上的 Amazon Nova 模型家族，负责模型接入、推理、RAG、护栏与定制。
  2. Agent Infra 平台层（AgentCore）：由 13 个可插拔模块组成，负责会话隔离、记忆、工具网关、身份、可观测与评估优化。
  3. Agent 开发框架层（Strands / Bedrock Agents）：Strands Agents SDK、AgentCore Harness、以及各类第三方框架，负责表达 Agent 的推理与编排逻辑。

其中平台层的 Amazon Bedrock AgentCore 是 AWS Agent Infra 的核心产品，于 2025-10-13 正式 GA 的模块化智能体平台，主打 "用任意框架、任意模型、任意协议" 构建、部署、运维生产级 Agent，且无需管理底层基础设施（公有云托管）。

当前完整的官方清单：

模块

定位（官方描述提炼）

关键集成

Harness

托管的 Agent 循环，单 API 调用即可定义并调用 Agent；内联指定模型、系统提示、工具，自动处理编排、工具执行、记忆与响应生成；每会话跑在隔离 microVM 中，带文件系统与 shell 访问

Bedrock / OpenAI / Gemini 及任意 OpenAI 兼容模型；集成 Memory/Gateway/Browser/CodeInterpreter/Observability；支持远程 MCP server 与自带容器

Runtime

安全的无服务器运行时，专为部署与扩展动态 Agent 而建；快速冷启动、异步长任务、真会话隔离、内置身份、多模态多 Agent

任意框架（CrewAI/LangGraph/LlamaIndex/Google ADK/OpenAI Agents SDK/Strands）、任意模型、MCP/A2A

Memory

上下文感知记忆，开发者完全控制"记什么、学什么"；短期（多轮会话）+ 长期（跨会话持久化），可跨 Agent 共享、从经验学习

LangGraph/LangChain/Strands/LlamaIndex

Gateway

把 API、Lambda、既有服务转成 MCP 兼容工具，并可对接已有 MCP server，通过 Gateway 端点暴露给 Agent

任意 API/MCP 工具/Lambda；Salesforce、Zoom、JIRA、Slack 等

Identity

安全可扩展的 Agent 身份、访问与认证管理，兼容既有 IdP，无需迁移用户或重建认证流

任意 IdP：Cognito、Okta、Microsoft Entra ID、Auth0 等

Code Interpreter

隔离沙箱，供 Agent 执行代码以提升准确率、扩展解决复杂端到端任务的能力

Python、JavaScript、TypeScript 等多语言

Browser

快速安全的云端浏览器运行时，让 Agent 操作 Web 应用（填表、导航、抽取信息），全托管

任意模型；Playwright、BrowserUse 等浏览器自动化框架

Observability

统一视图追踪/调试/监控生产 Agent；可视化工作流每一步、审查中间输出、定位性能瓶颈与失败

任意支持 OpenTelemetry(OTEL) 标准遥测格式的监控栈

Payments

托管的 Agent 微支付服务，让 Agent 用 x402 协议与 MPP（Machine Payments Protocol） 访问付费 API/MCP/内容；含钱包集成、支出限额、端到端观测

Coinbase CDP、Stripe(Privy) 钱包；Gateway；Strands；x402/MPP 端点

Evaluations

面向 Agent 的自动化、一致、数据驱动评估；衡量任务完成度、边界情况处理、输出可靠性

支持 Strands/LangGraph 生成、经 OpenTelemetry/OpenInference 埋点的 sessions/traces/spans；结果并入 Observability

Optimization

持续改进服务，用 AI 建议 + 版本化配置包 + A/B 测试，以数据驱动方式改进 Agent（系统提示、工具描述优化）

基于 Evaluations，经 Observability 的 OTEL 埋点；通过 Gateway 做流量切分 A/B

Policy

确定性护栏，确保 Agent 在既定边界/业务规则内运作；可用自然语言或 Cedar（AWS 开源策略语言）编写细粒度规则

集成 Gateway，在每次工具调用执行前拦截

Registry

组织级中心目录，发现与管理 Agent、MCP server、工具、技能、自定义资源；带发布/审核/审批治理流与语义+关键词混合搜索

任意 MCP Server/Agent/Skill/自定义资源，跨 AWS/本地/其他云

Agent 功能模块概览

上下文工程

大语言模型在处理和生成文本方面表现出色，但它们在本质上是无状态（stateless）的。这意味着每次与 LLM 的交互都是独立的，模型本身不会"记住"过去的对话或经验。大模型在"记忆"上主要局限于：

上下文窗口的限制导致遗忘问题。LLM 通过一个有限的"上下文窗口"（Context Window）来处理信息。所有输入（包括 Prompt 和之前的对话片段）都必须塞入这个窗口。一旦信息超出这个窗口，LLM 就"忘记"了它，无法再访问。这导致了所谓的"遗忘"问题；

难以处理多轮/复杂任务。对于需要跨越多轮对话、追踪状态或执行一系列子任务的复杂任务，LLM 很难保持连贯性和进展，因为它会不断"忘记"之前的步骤和决策。特别是在 Agent 的场景，工具的定义和工具的返回值都会存在于上下文中，同时由于 Agent 具有自主工作的能力，和 LLM 的平均交互的轮数也大大增加；

无法个性化。由于不记住特定用户的历史偏好、习惯或之前的互动，LLM 难以提供真正个性化的体验。每次互动都像是第一次见面；

长上下文带来的性能和成本影响。推理速度变慢：LLM 在处理更长的上下文时，需要进行更多的计算来处理和理解所有输入信息。这会导致推理时间增加，响应速度变慢。模型表现下降：尽管 LLM 的上下文窗口越来越大，但研究发现，模型在超长上下文中检索关键信息的能力可能会下降。更高的 Token 费用：上下文越长，输入的 token 数量就越多，从而导致每次 API 调用的成本更高。对于需要频繁交互或处理大量文本的应用来说，这会迅速累积成可观的费用。

记忆系统旨在克服 LLM 的局限性，赋予智能体以下核心能力：

长期保留与高效管理：存储超出 LLM 上下文窗口的信息，实现高效检索和过滤，避免信息遗忘；

持续知识更新：通过存储与环境和用户的交互经验，实现自我改进和知识更新；

个性化服务：记录用户偏好和历史互动，提供定制化回应；

复杂任务支持：追踪多 Agent 任务进展和中间结果，确保连贯完成并优化决策；

提升交互质量：保持上下文连贯性，支持深入推理，并通过反思机制从错误中学习。

上下文工程与记忆系统形成共生关系，共同支撑智能体的认知能力。记忆系统作为"信息仓库"，存储历史对话、知识和用户偏好；而上下文工程则扮演"智能调度员"，决定从记忆中检索哪些信息及如何组织呈现给 LLM。

上下文工程的核心在于，LLM 的性能和有效性根本上取决于其接收的上下文。实现了上下文工程的系统一般包含三类基础组件：

上下文检索与生成： 涵盖 Prompt 生成和外部知识获取；

上下文处理： 涉及长序列处理、自我完善和结构化信息集成；

上下文管理： 关注记忆层次、压缩技术和优化策略。

这些组件是高级应用实现（如 RAG、显式记忆系统和智能体系统）的基石。

上下文工程与记忆系统紧密且共生，都是 AI 智能体的重要构建手段。一方面，记忆是上下文的"仓库"， 智能体的记忆系统（如历史对话、知识库、用户偏好）是信息存储地，为 LLM 提供潜在上下文。另一方面，上下文工程是记忆的"调度员"和"优化器"，上下文工程决定从记忆中检索哪些信息及如何检索，确保提取最相关的记忆片段。

在一个文档自动化处理生成的 Agent 项目中，我们面临一个关键挑战：输入文档总量超过 500 页，远超模型的最大 Token 限制，同时项目对生成内容的召回率和准确率有较高要求。

为解决这一问题，我们实施了以下上下文工程策略：

文档分块处理：将大型文档集合切分为适当大小的 chunks，并存储在文件系统中；

摘要生成：为每个文档块生成精炼的文字摘要，提供内容概览。并生成整个文档的摘要信息；

动态上下文管理：赋予 Agent 自主选择的能力，使其可以根据任务需求动态调取相关文档块；

上下文优化：任务完成后自动释放不再需要的上下文，优化资源利用。

这种方法使 Agent 能够在保持高准确率的同时，有效处理超过模型上下文限制的文档集合。

上下文工程构成

内容构成

上下文工程由输入、记忆和输出三大部分组成。输入包括系统指令、外部知识检索、工具定义、全局状态和用户输入，为模型提供任务背景和所需信息。记忆部分分为长期记忆和短期记忆，用于存储和召回历史信息。输出则包括工具执行的结果和模型生成的结构化内容。这些组件共同协作，构建一个丰富的上下文环境，以支持 LLM 完成复杂任务。

核心组件

上下文工程是一种系统化构建、处理并动态管理上下文信息，以驱动大型语言模型实现精准推理与决策的先进架构。其核心组件包括上下文检索与生成，上下文处理与上下文管理三个部分，其工作流是一个动态迭代的闭环过程。

首先，系统接收用户输入、系统指令与知识库信息作为原始素材，通过上下文检索与生成动态获取并组装多源信息，构建出任务相关的增强上下文（由 RAG 系统实现），并在此过程中初始化与更新记忆系统（含全局状态、短期与长期记忆）。

进而，通过上下文处理获取相关上下文信息，对增强后的长序列上下文进行结构化整合与深度推理，在此过程中，记忆系统与工具集成模块协同工作，通过调用外部工具与迭代优化，生成结构化输出并持续反哺记忆与工具模块。

最终，上下文管理作为中枢，在多智能体系统的协调下，对全流程中的信息（包括原始输入、记忆与工具）进行高效的组织、压缩与调度，以优化资源利用并确保响应质量。整个架构并非单向线性，而是通过多轮次的迭代与优化，实现上下文生命周期的系统化与动态化管理，从而为复杂 Agent 提供可靠、高效且可进化的核心支撑。

上下文检索与生成

这一模块对应 RAG 系统的核心功能，通过提示词工程、外部知识检索和动态上下文组装获取适当的的上下文信息，主要解决了信息源适配的问题，在这一阶段，关键任务是如何从多源信息中筛选出与当前问题相关的内容，确保 AI 有正确的材料来完成任务。

首先基于 CLEAR 原则（简练性、逻辑性、明确性、适应性、反思性）构建结构化指令框架，明确输出目标与推理路径。

当任务涉及超出模型参数化知识的领域（如实时数据或专业信息）时，系统激活外部知识检索组件。

外部知识检索通过检索增强生成（RAG）架构动态连接知识图谱、数据库等外部信源，其中 Self-RAG 机制智能决策检索时机，知识图谱系统则保障信息权威性与关联性。

这个过程对检索到的信息进行多维度的优化：通过优先级排序提取核心数据，利用自然语言表述将结构化数据转化为 LLM 可解析的格式，通过多 Agent 协作和压缩技术在保障回复质量的前提下控制上下文长度。在这个过程中，可以通过 LangChain 等工具链实现自动化数据清洗与格式转换，确保信息适配模型处理要求。

三组件形成闭环优化系统： 提示工程定义的检索过程引导了知识获取的范围，外部检索结果的质量反馈至提示模块进行指令校准，而组装输出的上下文有效性则通过自迭代优化进行多轮修订。当 LLM 输出未达预期时，系统回溯到问题环节，若因信息缺失则强化检索策略，若因表述模糊则优化提示设计，若因整合混乱则重组上下文结构。这种协同机制在保障信息时效性与准确性的同时，显著降低幻觉风险。

上下文处理

这一模块对应记忆系统（Memory Systems）和工具集成推理（Tool-Integrated Reasoning）的功能，通过长序列优化、自优化机制、多模态融合、结构化集成四大技术方向，解决 LLM 处理海量信息的核心挑战。核心任务是将原始上下文转化为高效、鲁棒以及任务适配的语义表示，具体实现路径如下：

长序列优化首先解决基础计算瓶颈：状态空间模型（SSM）维持线性计算复杂度，位置插值技术，如 LongRoPE 将上下文窗口扩展至 2048K token，StreamingLLM 通过关键 token 保留机制支持无限长流处理，为后续处理环节提供可计算的压缩序列。

自优化组件随即对序列进行语义精炼：Self-Refine 框架使模型兼具生成与校验功能，实现闭环修正，长思维链（LongCoT）扩展推理深度，动态长短推理（Auto Long-Short）按问题复杂度自适应调整步长，输出优化后的内容。

多模态融合接收精炼文本并扩展信息维度：视觉提示生成器（VPG）将图像映射至文本空间，跨模态注意力机制建立图文细粒度关联，链接上下文学习（LCL）通过显式因果链演示抑制模态偏差，形成统一的多模态表示。

结构化集成最终注入逻辑验证框架，输出可验证的上下文。综上所述，对上下文的处理本质上是计算载体（长序列）、质量引擎（自优化）、信息扩展（多模态）、逻辑验证（结构化）的功能闭环。

上下文管理

这一模块对应多智能体系统（Multi-Agent Systems），旨在优化大语言模型中信息的组织、存储与利用，以应对有限上下文窗口的约束，构建高效的内存架构，并通过压缩技术提升信息密度，实现上下文高效管理。

这一组件需要解决三个核心挑战：首先是严格的记忆容量约束，传统 Transformer 架构在处理长文本时会产生平方级增长的计算开销；其次是显著的信息提取偏差，模型对文本中段内容的理解能力明显弱于首尾部分；最后是固有的无状态特性，模型默认不会保留跨对话的历史信息。

为了应对这些挑战，研究者开发了多层次的解决方案。在存储架构方面，借鉴计算机操作系统的虚拟内存概念，采用分层记忆设计将关键信息保留在快速访问区域，同时支持外部存储扩展。基于艾宾浩斯遗忘曲线的动态记忆机制能够智能调整信息留存强度，高频使用的内容获得更强记忆权重。

同时，先进的压缩算法可将长文本提炼为原大小四分之一的精华内容，通过双层存储结构同时保存全局概览和细节数据。分布式计算框架的引入使得处理百万级 token 的超长内容成为可能。典型的应用案例包括

记忆系统 ------ 个人的

记忆模块是 Agent 智能化的核心要素。它能够通过收集用户对话信息，深入了解用户的偏好、兴趣、关注点以及历史事件等内容。这些信息作为当前会话的上下文，不仅提升了 Agent 回答的准确性，还使其能够更好地满足用户的个性化需求。

记忆的存储架构通常采用分层设计：短期记忆用于保存原始数据，以便在当前会话中查询历史消息；长期记忆则通过异步方式对对话历史进行加工，抽取语义事实、用户偏好和内容摘要等信息。这种设计不仅保证了实时性能，还提供了长期的智能化能力。在实际生产环境中，我们还需特别关注记忆的安全性和隔离性。每个用户的记忆数据应存储在独立的命名空间中，以防止数据泄露。此外，建立完善的数据备份和恢复机制，确保重要的用户偏好和历史信息不会丢失，也是至关重要的。

记忆系统，记忆系统赋予 Agent"学习"和"成长"的能力。可以简单分为短期记忆和长期记忆两个大类：

  • 短期记忆：维护当前会话的上下文状态，类似于人类的工作记忆；
  • 长期记忆：存储用户偏好、历史交互、知识积累等信息，需要智能的信息抽取和压缩机制。

AgentCore记忆：管理短期和长期记忆，为模型提供相关上下文，同时帮助 Agent 从过去的交互中学习历史知识。

短期记忆

短期记忆（Short-term Memory, STM）是智能体维护当前对话和任务的即时上下文系统，主要包括：

会话缓冲（Context）记忆：保留最近对话历史的滚动窗口，确保回答上下文相关性；

工作记忆：存储当前任务的临时信息，如中间结果、变量值等。短期记忆受限于上下文窗口大小，适用于简单对话和单一任务场景。

长期记忆

长期记忆（Long-term Memory, LTM）是智能体用于跨会话、跨任务长期保存知识的记忆形式。它对应于人类的大脑中持久保存的记忆，例如事实知识、过去经历等。长期记忆的实现通常依赖于外部存储或知识库，包括但不限于：

摘要记忆：将长对话内容提炼为关键摘要存储；

结构化知识库：使用数据库或知识图谱存储结构化信息；

向量化存储：通过向量数据库实现基于语义的记忆检索。

长期记忆使智能体能够随着时间累积经验和知识，它特别适用于知识密集型应用和需要长期个性化的场景。

长期记忆类型：

语义记忆 (Semantic Memory)：语义记忆是 Agent 的知识基础，存储客观事实、用户偏好和基础知识，作为长期持久化记忆嵌入系统提示中，可通过 Collection 方式保存完整历史信息，或通过 Profile 方式只保留最新状态，为 Agent 提供稳定的知识支撑，确保其能够准确理解和回应用户需求。

情节记忆（Episodic Memory）：捕捉 Agent 的交互经历，不仅存储对话内容，还包含完整上下文和推理过程，作为短期记忆主要用于构建用户提示词，使 Agent 能够从过往经验中学习，参考成功案例调整响应策略，从而在类似情境中提供更加个性化和有效的解决方案。

程序记忆 (Procedural Memory)：专注于"如何做"的实操知识，从初始系统提示开始，通过持续反馈和经验积累不断优化，作为短期记忆帮助 Agent 学习最有效的行为模式，既可用于系统提示也可用于用户提示，使 Agent 能够根据不同情境灵活调整策略，提高解决问题的效率和准确性。

哪些信息需要被记忆？

在构建智能体记忆系统时，首先要根据具体的场景确定哪些信息值得记忆。这些记忆往往是多维度和动态的信息结构，包括时间维度（理解时间依赖的关系和序列）、空间维度（解释基于位置的和几何关系）、参与者状态（跟踪多个实体及其不断变化的状况）、意图上下文（理解目标、动机和隐含的目的），以及文化上下文（在特定社会和文化框架内解释交流）。

并非所有对话内容都需要长期保存，下面以 4 种常见场景举例哪些是与任务相关、对后续交互有价值的记忆要点。

对于代码助手类的智能体，记忆应侧重用户项目的上下文和偏好。包括：用户项目的代码库结构（文件组织、模块关系）、命名风格（变量命名约定、代码格式风格）、常用的框架/库以及用户以前提供的代码片段或指令等。记忆这些信息可以更贴合定制化需求和项目实际情况给出建议。例如，没有记忆支持时，开发者常常需要重复告诉 AI 项目的架构或纠正 AI 偏离项目规范的行为，这非常低效。而引入持久记忆后，AI 可以持续参考之前存储的项目背景，"记住"用户的技术栈，从而保持技术决策的一致性。同时，代码助手还能记忆用户过往的提问和反馈，例如某段代码曾反复修改，下一次遇到类似问题时可直接调用之前的方案，避免重复推理。总之，在代码场景中，记忆系统使 AI 能够理解长期的项目上下文，提供风格一致且上下文相关的代码补全和解释。

对于智能客服类的智能体，记忆的重点是用户历史和偏好，以便提供连贯且个性化的服务。包括：用户当前任务的状态，提过的问题、故障、产品使用，服务配置，和解决方案记录。当用户第二次来询问类似问题时，不必重复描述自己之前的问题细节，系统能够回忆起上次给出的建议或已经尝试过某些步骤，直接切入重点解决当前问题。此外，记忆用户的产品使用情况和喜好（例如偏好哪种通信渠道，是否倾向自助解决）可以使响应更加贴合用户习惯。这样实现更快的问题解决和更高的客户满意度，增强对品牌的信任。

对于个人助理智能体，记忆重点包括：用户个人信息和日程表、目标（如健身学习计划）、经常执行的行为模式（如每周几锻炼）以及对应用和服务的偏好（如偏好哪种提醒方式）等。这样智能体会提醒日程，并结合过往偏好提供个性化安排（比如知道用户周五喜欢外卖，在傍晚时主动推荐餐厅）。随着交互增加，持续的长期记忆使智能体能不断适应用户，逐渐减少对用户指令的依赖，实现更主动和贴心的服务。

对于推荐服务智能体，记忆重点包括：用户的显式反馈（如用户给某本书点赞或明确表达不喜欢某商品）和隐式反馈（如浏览记录、点击行为、购买历史），以此构建兴趣档案，在后续交互中个性化推荐。并持续学习，对过往推荐的反馈（是否点击、购买），不断调整推荐策略，更新画像。提高推荐转化率也增强用户忠诚度。

记忆策略

智能体的记忆更新可通过轮数或事件触发。轮数触发是每隔 3-5 轮对话自动生成摘要存入记忆；事件触发则在完成任务、场景转换等关键节点记录信息。例如，客服完成问题处理时保存解决方案，个人助理更新日程后写入日历。开发者可实现监控逻辑，在对话累积或话题转换时，让大模型对近期对话生成摘要，提取关键信息并添加标签便于检索。

系统也可支持用户主动标记需要记住的信息，如通过口头指令或界面操作。这不仅让用户指定重要内容，也支持删除特定记忆的需求，确保用户对数据的控制权。

记忆存储：记忆组织结构设计

记忆数据通常采用用户→会话→记忆片段的三层结构管理。用户层区分不同账号空间，会话层隔离各对话上下文，记忆片段层存储具体内容及元数据（如时间、关键词、来源等）。复杂系统可能需要维护多个记忆库，包括短期工作记忆、长期情节记忆、语义知识库等。合理的结构设计有助于快速检索和有效管理记忆内容。

记忆检索：记忆查询与召回逻辑

智能体需要基于当前对话意图从记忆库中检索相关信息。主要检索方法包括关键词匹配、向量语义搜索和元数据过滤。系统将检索到的记忆按相关度排序，选取最相关内容加入到对话上下文中，用于生成更准确的响应。例如在推荐场景中，可基于用户历史偏好记忆提供个性化建议。

Amazon Bedrock AgentCore Memory

Amazon Bedrock AgentCore Memory 是 AWS 原生的企业级记忆管理服务，通过双层记忆架构（短期与长期）解决了 Agent 应用中的关键上下文工程挑战：如何让 Agent 在保持高效性能的同时具备真正的"记忆"能力。作为完全托管的 SaaS 服务，AgentCore Memory 天然支持多租户架构和严格数据隔离，更适合企业级部署和严格合规场景，同时可与 LangGraph、CrewAI 等主流开源框架无缝集成。相比之下，Strands Agents 集成的第三方记忆服务（如 Mem0.ai）更适合快速原型开发和灵活定制场景。

AgentCore Memory 采用双层架构处理不同时间尺度的上下文需求。短期记忆存储对话交互以维护当前会话上下文。例如编程助手 Agent 在调试过程中会记录变量检查、语法修正等交互事件，使对话能连续进行而无需重复信息。短期记忆为长期记忆提供输入，支持多步骤任务完成和会话内知识积累。

亚马逊云科技也提供开箱即用的托管服务，通过 AI Agent 构建平台 Bedrock AgentCore 中的记忆模块帮助开发者更快捷地为 AI Agent 赋能记忆功能。您无需运维任何底层资源，只需一键即可集成业界领先的记忆系统。

Amazon Bedrock AgentCore 的 Memory 模块是一个由亚马逊云科技托管的持久化记忆系统，用于存储和管理 AI Agent 的对话和知识。它提供短期记忆（short-term memory）和长期记忆（long-term memory）两种模式。

短期记忆负责在一次会话中记录最近的最近几轮对话，确保代理能够"记住"当前对话的上下文。长期记忆则从对话中提取结构化的关键信息，在多个会话之间保留知识，使 Agent 能够"学习"用户偏好、事实和摘要等信息。

长期记忆存储提取的洞察信息，包含三个关键组件。用户偏好记忆让 Agent 记住开发者的编码风格（如 snake_case 命名、pandas 数据分析偏好），在后续会话中自动遵循这些偏好。语义事实记忆积累领域知识（如"Pandas 是用于数据分析的 Python 库"），支持基于知识的智能推荐。摘要记忆生成会话概要（如"创建数据清理函数，修复语法错误，测试回归模型"），既跟踪工作进展又优化上下文窗口使用。

会话与状态管理 API（关键实现）^1^9：

操作

作用

create_event

存储一次交互，自动应用已配置的长期记忆策略（异步抽取、合并为命名空间记录）

list_events

检索近期若干轮对话（短期）

retrieve_memories

对命名空间做语义查询，取回相关长期记忆

记忆存储可跨多个 Agent 共享，并能"从经验中学习" ^2^9。

记忆的存储

Memory 模块在架构上采用分层存储策略：短期记忆层存储原始交互事件作为即时上下文，长期记忆层存储从事件提取的概要知识。Memory 服务背后实现了自动的信息处理流水线：当新的事件被存储时，如果 Memory 配置了长期记忆策略，服务会异步地对事件内容进行分析（例如调用基础模型）来提炼出可长期保存的知识片段。

AgentCore Memory 内置了多种记忆策略（Memory Strategy）来定义如何将原始对话转化为结构化长期记忆。例如：

SemanticMemoryStrategy（语义记忆策略）：从对话中抽取出事实和知识，以便日后查询。

SummaryMemoryStrategy（摘要策略）：为每个会话生成对话摘要，提炼主要内容。

UserPreferenceMemoryStrategy（用户偏好策略）：捕获用户的偏好、风格和重复选择等信息。

使用内置策略时，无需额外配置模型，AgentCore Memory 服务会在后台使用预置的模型来完成提取和归纳。当开发者调用 CreateEvent 保存新事件后，这些策略会被自动触发，异步运行 LLM 分析内容并产生长期记忆记录（memory records）。长期记忆记录生成后存储于 Memory 中，对应特定的命名空间和类型（如事实、摘要、偏好），每条记录也有唯一 ID 以供检索。

此外，AgentCore 允许自定义记忆策略（CustomMemoryStrategy），开发者可提供自定义的提示词（prompt）和选择特定的基础模型来执行记忆提取，例如只提取某类 domain 知识。

记忆的使用

Memory 模块提供检索 API，供应用在调用 LLM 推理时提取相关记忆并注入对话上下文中。在大语言模型生成回复时，可以通过 Memory 提供的内容获得额外的上下文信息。例如，开发者可以在每次生成回复前，调用 list_events 获取短期记忆的对话记录，将其附加到 LLM 的提示中，以维护对话连续性。对于跨会话的信息，可以使用 retrieve_memories 接口通过语义查询长期记忆，例如查询某用户的偏好或某主题的事实知识，然后把检索到的内容纳入提示。这种机制确保 LLM 在回答新问题时，不仅有当前对话文本，还能利用 Memory 中沉淀的历史知识，提高响应的相关性和智能性。

Memory as tool：Memory 模块还可以与 Agent 框架的推理流程集成，实现自动的上下文注入。AgentCore Memory 可被包装成一个工具（Tool）供 LLM 调用。以 Strands Agents 框架为例，开发者通过 AgentCoreMemoryToolProvider 将 Memory 注册为工具，使得当模型需要回忆信息时，可以自主调用如 "agent_core_memory" 工具执行 retrieve 动作来查询记忆，或用 record 动作将新的信息存入记忆。这种工具调用方式也可以通过 Model Context Protocol (MCP) 等标准，让 LLM 在推理中动态决定何时读写记忆，使 Agent 能够更加自主地管理上下文。

所有数据由亚马逊云科技以加密方式存储，并使用命名空间（namespace）进行隔离分区，确保不同应用或用户的记忆数据彼此分隔。这一完全托管的记忆基础设施让开发者无需自己搭建数据库或向量存储，就能方便地让 Agent 拥有记忆功能。

RAG 知识库 ------ 公共的

典型的检索增强生成框架包括模块化 RAG、智能体 RAG 和图增强 RAG，主要应用于动态检索策略、低延迟优化、增量索引等场景中，用于集成内部和外部的上下文系统。

模块化 RAG 通常采用分层架构设计，将整个检索增强生成流程分解为多个专业模块。典型代表包括 FlashRAG 和 ComposeRAG 等框架，它们通常构建三层结构：顶层负责协调完整的 RAG 流程，中层管理各个功能子模块，底层则包含具体的操作单元。这种设计的核心优势在于能够动态重组工作流程，通过智能路由模块和灵活的调度机制，根据不同的查询需求自动选择最合适的处理路径。

智能体 RAG 将自主 AI 智能体整合到检索增强生成流程中，实现了基于持续推理的动态操作。这种设计充分利用反思、规划、工具使用和多智能体协作等机制，通过多模态感知、工具使用和外部记忆集成，基于 LLM 的自主智能体扩展了传统语言模型的能力边界。以 Self-RAG 为代表的自优化框架能够根据任务复杂度自动调整检索深度和范围，而 PlanRAG 等系统则进一步具备任务分解和规划能力，使得检索过程更加智能化和针对性。

图增强 RAG 将关注点从简单的文档导向转向复杂的结构化知识表示。通过引入图结构来提升检索质量，这类智能体擅长处理需要多步推理的复杂查询。GraphRAG 和 HippoRAG 等框架利用知识图谱的结构化特性，能够沿着实体关系路径进行多跳检索，挖掘深层次的关联信息。更先进的 GNN-RAG 还集成了图神经网络技术，通过分析图中节点间的复杂关系模式，显著提升了实体关系捕获的准确性和完整性。

行动工程

工具接口是 Agent 与外部世界交互的"手脚"。一个 Agent 可能需要调用数十种不同的 API、数据库、外部服务。

开发挑战在于：如何标准化不同工具的接入方式、如何实现工具的智能选择和组合、如何处理工具调用的异常和重试、如何确保工具调用的安全性和权限控制。

执行沙箱

在构建 Agent 应用时，浏览器和代码解析器是两项不可或缺的工具。简单来说，浏览器工具让 Agent 能"看网页、操作网页"，实现对非 API 系统的直接操作；而代码解析器让 Agent 能"运行代码、算得更精"，胜任数据处理和复杂计算任务。

浏览器往往需要一个完全托管的浏览器沙箱环境（Sandbox），让 Agent 能够像人类那样"浏览网页"。点击按钮、填写表单、解析动态内容、抓取图像或执行页面导航等，这些往往是在隔离、安全、可监控的沙盒中进行。企业借此可绕过缺少 API 的系统，自动化处理诸如填报内部表单、跨系统数据抓取、网页内容监测等任务，同时还具备回放能力。

代码解析器则让 Agent 获得运行程序能力，它通过提供一个沙箱环境，可安全地让 Agent 调试并执行基础模型动态生成的代码，并能处理大规模数据、生成可视化分析、执行复杂计算任务。在企业场景中，这意味着 Agent 不再局限于文本推理，而可以亲自"动手"执行多步数据流程、处理 CSV/JSON/Excel 数据、绘制图表、执行机器学习分析等。

AgentCore浏览器：提供完全托管的 Web 浏览器工具，以扩展 Agent 基于 Web 的自动化工作流程。

AgentCore代码解释器：提供一个隔离环境来运行 Agent 生成的代码，即需即用。

在实际应用中，对于沙盒环境有两大核心应用场景：代码执行环境和可视化操作环境。

以Firecracker为代表的微虚拟化技术提供了强隔离和快速启动时间，非常适合临时启用沙盒的场景。

代码执行环境

Agent应用需要单独的代码执行环境来执行特定任务。以企业数据分析Agent为例，业务分析师可以直接上传一个1GB的销售数据文件到应用平台，然后通过自然语言告诉Agent："分析过去一年的销售趋势，找出表现最好的产品类别，并生成可视化报表"。Agent能够自动解析用户意图，并调用大型语言模型生成数据读取、处理及分析代码。它会多次启动沙盒环境执行这些代码，最终生成包含图表和统计分析的完整报告。尽管整个流程可能需要数小时的连续计算，但用户只需通过自然语言描述需求并进行必要的修正即可。所有复杂工作均由Agent、大型语言模型和沙盒工具协同完成，无需用户直接参与技术操作。

除单一功能的Agent应用外，更为复杂的场景是AI Bot生态平台。这类平台同时服务两类用户群体：开发者（生产者）和终端用户（消费者）。开发者可在沙盒环境中利用Claude Code、Amazon Q CLI等AI编程助手快速构建各类Agent应用。完成后，他们能在同一环境中一键将应用部署为Web服务，实现AI Bot的无缝托管。终端用户则可直接访问和调用这些已部署的AI Bot服务，无需了解任何技术实现细节。这种模式以沙盒为基础，构建了从"AI辅助开发"到"一键部署"再到"即用即取"的完整生态闭环，有效连接了生产者与消费者两端。

针对多样化的应用场景，沙盒环境需提供灵活的代码执行方式，从执行模式看，系统需同时支持命令行直接执行以满足基础脚本运行需求，以及具备高阶代码解析能力的安全执行环境，确保代码在完全隔离的容器中运行；而在运行时环境方面，不同应用对技术栈的要求各异，如数据分析Agent需要Python Runtime来处理科学计算，代码编辑类Agent则依赖VSCode Server提供完整的开发体验，这种多元化的执行能力设计使沙盒能够适应不同复杂度和技术需求的应用场景，为各类Agent提供最适合的运行基础。

Amazon Bedrock AgentCore Code Interpreter是亚马逊云科技推出的企业级代码执行沙盒解决方案，专为AI智能体的安全代码执行而设计。该服务基于microVM技术，为每个会话提供完全隔离的执行环境，确保代码执行的安全性和可靠性。下图展示了AI Agent通过Tool Use能力使用Code Interpreter的调用过程。

核心特性

安全隔离架构：AgentCore Code Interpreter采用容器化microVM技术，每个会话运行在独立的微虚拟机中，具备独立的CPU、内存和文件系统资源。会话结束时，microVM完全终止并进行内存清理，确保零数据泄露风险。

企业级配置支持：支持多种网络模式配置，包括完全隔离的沙盒模式和支持外部API访问的公网模式。提供灵活的执行角色配置，可精确控制代码对亚马逊云科技资源的访问权限。

多语言运行时支持：内置Python、JavaScript、TypeScript等多种编程语言的预构建运行时环境，支持大文件处理（内联上传最大100MB，S3上传最大5GB）和互联网访问功能。

智能资源管理：提供自动会话超时机制（默认15分钟，可配置最长8小时），支持手动会话停止，确保资源的高效利用和成本控制。

可视化操作环境

除了代码执行，Agent应用的另一个重要应用场景是Computer Use（计算机使用）和Browser Use（浏览器使用）。Computer Use是指AI Agent能够像人类用户一样操作计算机界面，包括点击按钮、输入文本、拖拽文件等各种GUI操作。Browser Use则是Computer Use的重要场景，专门指Agent在浏览器环境中的自动化操作能力，如网页浏览、表单填写、数据抓取等。

以某社区媒体营销文案生成Agent为例，营销人员只需输入"收集某某竞品在该平台上的营销策略"，Agent就能像真实用户一样操作浏览器：自动打开多个网页标签，浏览不同的产品页面和用户评论，收集关键的市场数据和用户反馈信息，然后基于收集到的数据进行分析，最终实现精准的内容推荐和广告投放策略。整个过程中，Agent通过Browser Use功能模拟人类的点击、滚动、输入等操作，完成复杂的数据收集任务。

类似的应用还包括游戏AI测试、软件自动化测试、在线订票等场景。这些应用的共同特点是需要Agent能够精确控制鼠标和键盘操作，与图形界面进行自然交互，处理那些没有API接口、只能通过视觉操作的应用程序。

这些Computer Use应用要求沙盒系统提供一个最小化的系统环境，实现完整的人机交互模拟功能并支持执行过程的可视化。系统需要提供完整的桌面环境或浏览器环境，让Agent能够像人类用户一样进行可视化操作，同时确保所有操作都在安全隔离的环境中执行。这种可视化操作能力让Agent真正实现了从"理解指令"到"执行操作"的完整闭环，为用户带来了前所未有的自动化体验。

Amazon Bedrock AgentCore Browser Tool是亚马逊云科技推出的企业级Web自动化解决方案，为AI智能体提供安全、托管的浏览器交互能力。该工具使AI智能体能够像人类一样与网站进行交互，包括导航网页、填写表单、点击按钮等复杂操作，而无需开发者编写和维护自定义自动化脚本。

核心特性

安全托管的Web交互：AgentCore Browser Tool在完全托管的环境中提供安全的浏览器交互能力。每个浏览器会话运行在隔离的容器化环境中，确保Web活动与本地系统完全隔离，最大化安全性。

企业级安全特性：提供VM级别的隔离，实现用户会话与浏览器会话的1:1映射，满足企业级安全需求。每个浏览器会话都在独立的沙盒环境中运行，防止跨会话数据泄露和未授权系统访问。

模型无关集成：支持各种AI模型和框架，通过interact()、parse()、discover()等自然语言抽象接口简化浏览器操作。兼容Playwright、Puppeteer等多种自动化框架，为企业环境提供灵活的集成选择。

可视化理解能力：通过截图功能使智能体能够像人类一样理解网站内容，支持动态内容解析和复杂Web应用导航。提供实时可视化监控和会话回放功能，便于调试和审计。

无服务器架构：基于无服务器基础设施自动扩缩容，无需管理底层基础设施。支持低延迟的Web交互，确保良好的用户体验。

AgentCore Browser Tool的调用的主要过程如下：

请求处理：当用户发起请求时，大语言模型选择合适的工具并将命令转换为可执行指令

安全执行：命令在受控的沙盒环境中执行，该环境包含无头浏览器和托管库服务器

隔离保护：沙盒提供完整的隔离和安全保护，将Web交互限制在受限空间内

反馈机制：智能体通过截图和执行结果获得反馈，支持自动化任务执行

安全特性

会话隔离：每个浏览器会话运行在独立的容器化环境中，与本地系统完全隔离，确保安全性。

临时会话：浏览器会话是临时的，每次使用后自动重置，防止数据残留和跨会话污染。

会话超时：支持客户端主动终止或TTL自动过期机制，确保资源及时释放。

审计能力：集成CloudTrail日志记录和会话回放功能，提供完整的操作审计轨迹。

典型应用场景

Web导航与交互：自动化网站导航、信息提取、内容搜索等任务，支持复杂的多步骤Web操作流程。

工作流自动化：包括表单填写、数据录入、报告生成等重复性Web操作的自动化，大幅提升工作效率。

AgentCore Browser Tool为企业提供了一个安全、可靠、易于集成的Web自动化解决方案，使AI智能体能够高效地处理各种Web相关任务，同时确保企业级的安全性和合规性要求。

MCP 连接器

工具网关（Gateway）是解决工具生态管理问题的关键组件。它不仅需要支持已有的标准化 API、MCP 协议或轻量级服务集成等接入功能，还需要提供工具发现、删除、鉴权等相关能力，方便开发者更加便捷地管理和维护工具列表。

其中，工具的快速搜索功能至关重要。当 Agent 面对复杂的用户请求时，网关的检索能力使其无需列出和读取所有工具，而是能够根据问题动态地发现和筛选出最合适的工具子集。这种搜索功能不仅减少了返回的工具数量，还提升了上下文相关性和处理速度，同时降低了成本。这对于控制 Agent 的运行成本尤为重要。

AgentCore工具网关：将现有 API 和 Amazon Lambda 函数转换为 Agent 随时可用的工具，提供跨协议的统一访问，包括 MCP，以及工具快速检索等功能。

MCP 协议与部署模型

模型上下文协议（MCP）通过引入标准化的客户端-服务器架构和统一协议，试图解决大模型的工具管理，集成和通讯的问题。

MCP 客户端通常集成在 AI 应用中，如 Amazon Q Developer、Claude Desktop、Cursor 等工具。这些客户端负责与 MCP 服务器通信。而MCP 服务器则充当了 AI 应用和具体工具之间的转换桥梁。MCP 服务器一般作为代理（Proxy）或边车（Sidecar）服务存在，它将标准的 MCP 请求转换为特定工具能理解的格式，执行相应操作后再将结果返回给客户端。

以 Claude 提供的示例 Git MCP Server 为例，客户端通过 MCP 协议向 MCP Server 发起操作 Git 存储库的请求，Git MCP Server 利用内置的 Git SDK 对存储库进行操作后，以 MCP 协议向客户端返回操作结果。这种设计实现了协议层面的解耦，使得工具的升级和变更不会直接影响到 AI 应用。

MCP 协议带来的最大优势是松耦合架构。AI 智能体只需要支持 MCP 协议，不需要关心工具的更新和变化，也不再需要学习和适配各种不同的 API 格式，所有的工具调用都通过统一的 MCP 协议进行，使用相同的数据格式和通信方式，这大大简化了开发者使用多种工具的集成复杂度，让大量工具的集成变得可行。而对工具提供方而言，每个工具的 MCP 服务器由相应的厂商或社区独立开发和维护，而无需考虑与AI 智能体进行集成。这样就实现了责任的清晰分工。

MCP 协议支持两种主要的部署模式：本地部署和远程部署。二者最明显的区别是 MCP 服务器是否与客户端位于同一地。不同的部署模式适应不同场景，有各自的优缺点。

  • 本地部署：绝大多数 MCP 服务器默认提供本地部署方式。本地部署模式中，MCP 服务器作为本地进程或容器运行。用户需要配置启动命令（如 npx ， uv 等包管理器，或 docker 等容器运行时）以及对应的启动参数和环境变量。配置完成后，客户端通过系统调用创建子进程，启动服务端程序，并建立与子进程的输入输出管道连接。客户端只要监测服务器进程，即可了解 MCP 服务器的运行状况。这种基于进程生命周期的连接管理机制简单有效，避免了复杂的网络连接管理问题。客户端与服务端通过标准输入输出流，采用 UTF-8 编码的 JSON-RPC 2.0 规范进行通信。这种机制提供了原生的双向通信。同时本地通信通过系统级别的管道传输，避免了网络层的复杂性，保证了通信的可靠性和效率。

本地部署架构简单，方便，适合在以下场景中使用：

在功能方面，一些需要本地数据访问和工具集成的场景必须使用本地部署。例如在开发环境中，它可以让AI助手直接访问本地文件系统、执行构建脚本、运行测试用例，提供无缝的开发体验。对于数据分析任务，本地部署的MCP服务可以直接访问本地数据库、处理本地文件，避免了数据传输的延迟和安全风险。

性能方面，本地部署避免了网络开销，具有更低的延迟和更高的吞吐量。对于需要频繁交互的应用场景，如实时代码分析、交互式数据探索等，这种性能优势尤为明显。

虽然本地部署在部署和操作层面比较方便，但在生产环境中面临诸多挑战：

版本管理困难：当后端工具升级时，其 API 可能发生变化，相应的 MCP 服务器就需要更新以适配新的 API。MCP 服务器 自身也在不断迭代增加新功能和修补漏洞，这些因素导致 MCP 服务器更新非常频繁。常用的 npm 和 uv 包管理器在缓存命中时，不会自动更新已安装的包，用户必须主动检查更新。本地部署模式下，这种更新完全依赖手动操作，在 MCP 服务器数量较多时，很难及时响应变化。

安全风险：虽然本地部署可以避免内容在网络上传输导致的风险，但也带来了更多权限泄露风险。本地 MCP 服务器默认情况下运行在与用户相同的命名空间下，权限与当前用户相同。理论上可以访问当前用户能访问的所有文件和资源。同时本地 MCP 服务器需要将所需的凭证（例如 API Key，用户名密码等）存储在本地，如配置不当，其他应用也可读取并使用该凭证，造成横向权限泄露。

资源和性能限制：每个 MCP 服务器都是独立的进程，且都会随着 MCP 客户端启动。当需要启动大量 MCP 服务器时，会显著影响本地机器的性能。特别是在资源受限的开发环境中，这种影响会更加明显。

  • 远程部署：远程部署模式则将 MCP 服务器部署在其他的远程服务器上，服务器暴露一个 HTTP 端点，客户端与服务器通过 Streamable HTTP 协议进行通信。Streamable HTTP 协议是 HTTP 协议的扩展，在标准 HTTP 1.1 的基础上支持轻量级的 Server-sent Event（简称SSE，服务端发送消息）。MCP 客户端启动时，会连接远程 MCP 服务器的 HTTP 端点以初始化 Session。初始化完成后，客户端可通过 HTTP POST 方法发送请求，MCP 服务器在处理完成后，可以直接以 JSON 格式返回结果。如任务耗时较长，也可以将连接升级至 SSE，以流式形式逐步返回结果。许多 MCP 服务器提供方已经开始支持远程部署模式，例如 Remote GitHub MCP Server 和 Amazon Knowledge MCP Server 。这种模式虽然增加了网络延迟，但在安全性、性能和可维护性方面具有显著优势。

远程部署在以下领域有独到优势：

版本更新更便捷：开发者可以通过持续集成部署（CI/CD）流水线，直接在单一可控的环境更新 MCP 服务器。用户无需进行操作，只需重新连接都能获得最新版本的工具。这种自动化机制彻底解决了本地部署中手动维护和更新的痛点，大大降低了运维负担，也减少了版本不一致所带来的问题。

更加安全可靠：云端部署在安全性方面提供了多层保护，而权限隔离是其中的核心优势。MCP 服务器在受控的云环境中运行，MCP 客户端在调用服务器时只发送具体的工具调用请求，不包含完整的对话上下文或敏感信息。这种设计大大降低了信息泄露的风险，即使 MCP 服务器被攻击，攻击者也无法获取到完整的用户数据。同时，MCP 服务器可通过 OAuth 等标准协议进行身份认证鉴权。这使得无需将凭证分发至本地，也可以在通过身份认证后，利用远程MCP 服务器的凭证进行一些需要高权限的操作，或访问受访问控制保护的知识库。降低凭证泄露或被滥用的风险。

更优性能和性价比：资源优化是云端部署的另一个显著优势。客户端只需要维护简单的 HTTP 连接，而不用担心本地资源消耗。对于一些有大量计算需求的场景，可以直接在云端环境中满足，无需在本地进行复杂的环境配置或消耗本地资源。按需计费的模式进一步降低了总体成本，特别是对于使用频率不高的 MCP 服务器。

更好的可观测和可维护性：现代 LLMOps 越来越重视可观测性，云端部署在这方面具有明显优势。统一监控系统可以提供请求量和响应时间的实时监控，详细记录资源使用情况，错误率等性能指标。而安全审计功能为企业级应用提供了必要的合规支持。系统可以记录所有工具调用请求的完整日志，实现可疑行为的自动检测和告警，并生成详细的合规性报告。这些功能在本地环境中很难实现，但在云端环境中可以通过专业的监控和分析工具轻松提供。

考虑到这些优势，远程部署的 MCP 服务器特别适用于需要集中管理和共享资源的企业环境。在大型组织中，IT 团队可以部署统一的 MCP 服务器集群，为不同部门的 AI 应用提供标准化的工具和数据访问接口。这种集中式架构不仅简化了权限管理和审计追踪，还能够实现资源的统一监控和性能优化。

对于跨地域协作的团队，远程 MCP 服务器提供了理想的解决方案。团队成员无论身处何地，都可以通过标准的 HTTP 协议访问相同的服务器资源，确保了协作环境的一致性。这种部署方式还特别适用于需要高可用性的生产环境，管理员可以通过负载均衡、故障转移等技术手段构建健壮的服务架构。

云原生环境是远程 MCP 服务器的另一个重要应用场景。在容器化和微服务架构中，MCP 服务器可以作为独立的服务组件进行部署和扩展，与其他业务服务保持松耦合关系。这种架构模式支持按需扩容、滚动更新等现代运维实践，为 AI 应用的规模化部署提供了技术基础。

但远程部署仍然有其局限性：

网络延迟和可靠性是影响远程部署性能和稳定性的主要因素。特别是在需要频繁交互的场景中，网络往返时间可能会显著影响用户体验。相比本地部署的进程间通信，HTTP 传输必然会引入额外的网络开销，且网络中断或不稳定会直接影响服务的可用性。

在安全性方面，远程部署需要将 HTTP 端点暴露到 Internet 或其他网络环境，天生比本地部署拥有更大的攻击面。数据需要通过网络传输，增加了被截获或篡改的风险。攻击者也会通过暴露的 HTTP 端点试图获得工具的访问权限。需要谨慎的安全设计和额外的安全投入（如认证鉴权，加密等）。

兼容性方面，Streamable HTTP 协议推出时间较晚，部分客户端对此支持较差。但可通过本地第三方工具，将其转换为 stdio 模式，兼容更多客户端。

Amazon Bedrock AgentCore Runtime 快速构建和部署 MCP 服务器

Amazon Bedrock AgentCore 是亚马逊云科技推出的一项全新服务，专门用于帮助开发者快速构建、部署和运行企业级的 Agentic AI应用，让开发者能够专注于创新，而不是底层的技术细节。它是为Agentic AI量身打造的开箱即用的"工具箱"，核心服务包括：

Runtime（运行时）：提供会话完全隔离，安全的无服务器的运行环境，可用于Agent, MCP服务器托管部署；

Gateway（网关）：帮助Agent安全地以MCP协议连接现有工具和API服务，简化工具集成。

Amazon Bedrock AgentCore Runtime 是专门为 Agent 或 MCP 服务器构建的无服务器运行环境，提供会话级的安全隔离以及按量付费的计费模式。

Amazon Bedrock AgentCore Runtime 提供 MCP 服务器支持，您可以使用 bedrock-agentcore-starter-toolkit 快速将您的 MCP 服务器从源代码部署到 Amazon Bedrock AgentCore Runtime，而无需管理任何基础设施。

在准备好源代码后，您仅需执行agentcore configure 和 agentcore launch 两条命令，即可通过 CodeBuild 在亚马逊云科技托管环境构建容器镜像，配置基于 Amazon Cognito 的身份认证机制，将构建完成的 MCP 服务器镜像部署到 Amazon Bedrock AgentCore Runtime，并创建一个访问端点。已认证的客户端可通过托管的端点，使用 Streamable HTTP 传输方式访问 MCP 服务器。

我们提供基于 Jupyter Notebook 的快速使用指导，帮助您快速上手 Amazon Bedrock AgentCore Runtime。

AgentCore Gateway 工具管理

Amazon Bedrock AgentCore Gateway 是专为 Agent 应用设计的工具管理服务，解决了复杂场景下的核心挑战：当需要集成数十甚至数百个工具和 API 时，传统静态工具定义方式不仅管理复杂，还会导致上下文窗口浪费和工具选择困难。

Gateway 将现有 API、Lambda 函数和服务自动转换为 Agent 兼容的 MCP 协议格式，消除数周的自定义开发工作。其核心创新在于基于任务上下文的工具语义搜索机制：通过语义搜索动态检索最相关的工具定义，而非将所有工具加载到上下文中。处理"分析数据文件并生成可视化报告"的请求时，系统会自动识别并按依赖关系组合文件读取、数据处理和图表生成工具。

这种动态加载机制带来显著的上下文工程优势：Agent 根据需要加载工具定义，大幅减少上下文 token 使用；语义匹配提升工具选择精度，避免在大量工具中盲目选择。Gateway 还提供完整的企业级治理能力，包括版本管理、基于 IAM 的访问控制、使用监控和合规审计，通过多层缓存策略（工具定义、搜索结果、调用结果）优化性能，特别适合相似工具组合的反复使用场景。

快速迁移现有的工具或 MCP 服务器至云上

如果您已有现有的 Lambda 函数或 API， 利用 Amazon Bedrock AgentCore Gateway 可以快速的将现有工具以 MCP 协议暴露出来，以供客户端使用。如果您已经开发了基于 stdio 本地部署的 MCP 服务器，也可以利用亚马逊云科技解决方案，快速将MCP服务器部署到云上。

使用 Amazon Bedrock AgentCore Gateway 转换现有 API。

Amazon Bedrock AgentCore Gateway 是一项全托管的工具网关服务，其主要作用是作为一个统一的连接层，将各种不同的工具和资源转换为 MCP 兼容的工具，使 Agent 能够通过单一的端点访问背后的多种工具。

Amazon Bedrock AgentCore Gateway 支持将 Lambda 函数、OpenAPI 规范 API、Smithy 模型 API 快速转换为基于 Streamable HTTP 的 MCP 端点，并提供内置的认证鉴权。 例如，很多企业内部已经有现成的REST API，而 Amazon Bedrock AgentCore Gateway 就可以把这些现有 API 服务快速的转换成一个MCP 服务器，供 AI Agent 使用。多个 API 可以挂载到同一个端点，以简化客户端配置。

在某些真实业务场景下，Agent需要选择的工具多达几百甚至上千种。Amazon Bedrock AgentCore Gateway 支持语义检索。语义检索作为一个特殊的工具，可以根据Agent提出的需求，找出跟当前任务最相关的工具列表，再注入对应的工具描述给Agent进行选择。该功能可以帮助 Agent 智能地发现和选择最适合其任务的工具，大幅度减少输入Token消耗，防止工具过多导致的延迟和效率问题。

行动约束

AgentCore Policy

Policy：确定性护栏。用自然语言或 Cedar（AWS 开源策略语言）写细粒度规则，集成 Gateway，在每次工具调用执行前拦截------定义"哪些工具可用、能做什么动作、什么条件下"，且"不拖慢 Agent" \^2。

安全工程

身份认证与授权管理

身份认证与授权，Agent 系统需要解决"谁可以访问 Agent"和"Agent 可以访问哪些资源"的双重身份问题。这包括用户身份验证、会话级身份隔离、细粒度权限控制、跨系统授权等。在多租户环境中，还需要确保不同用户的 Agent 会话在独立的安全沙箱中运行。

在构建 Agent 应用时，身份认证是整个安全体系的核心基石，直接影响系统在企业级场景下的稳定和安全运行。身份管理组件需要支持与多种身份提供商（IdP）集成，如 GitHub、社交媒体账户以及遵循标准认证协议的企业级身份管理系统（如 Okta）。此外，开发者应能配置多维度的认证规则，包括入站和出站的双向认证机制：入站认证确保只有合法授权的用户或系统能够访问 Agent 应用，而出站认证则保障 Agent 在调用外部工具或资源时能够通过安全的认证回调完成授权。这种双向认证机制不仅防止未授权访问，还确保了 Agent 在跨系统交互时的合规性与安全性。

在 Agent 输出内容的安全方面，仍需通过安全防护机制（如 Guardrails）来确保大模型在引导 Agent 完成任务时，不受到严重的幻觉影响，也不提供非法或不合规的内容。这要求在模型本身的安全防控上，需要增加额外的规则和策略，以判断 Agent 的思考和执行是否合法，是否符合业务规则要求。

AgentCore身份管理：使 Agent 应用能够安全访问 AWS 服务和第三方工具及服务，如 GitHub、Salesforce 和 Slack，可以代表用户或在预授权用户同意的情况下自行操作。

基本概念

身份与认证方面的概念与术语：

代理（Agent） 一种由 AI 驱动的应用程序或自动化工作负载，通过访问云资源和第三方服务来代表用户执行任务。代理在获得预先授权的用户同意后采取行动，以实现用户目标，例如从 API 检索数据、处理信息或与第三方系统集成。与使用静态凭证运行的传统应用程序不同，代理需要动态身份管理才能安全地访问跨多个信任域的资源，同时维护适当的身份验证和授权边界。

代理身份（Agent identity） AI 代理或自动化工作负载的唯一标识符及其关联元数据。代理身份作为工作负载身份实现，并具有特定属性，用于标识其代理身份，从而实现专用代理功能，同时保持与更广泛的工作负载身份标准的兼容性。代理身份使代理能够以自身身份进行身份验证，而不是冒充用户，从而支持基于委托的访问模式。

代理身份目录（Agent identity directory） 一个集中式注册目录，用于管理代理身份及其相关元数据和访问策略。与 亚马逊云科技的Cognito 服务的用户池类似，它充当组织账户或区域内代理身份的治理单元。

工作负载身份（Workload identity） 代理身份的底层技术实现，代表独立于特定硬件或基础架构的逻辑应用程序或工作负载。工作负载身份可以跨不同环境运行，同时保持一致的身份验证。代理身份是一种特殊类型的工作负载身份，具有代理特有的附加属性和功能。

访问令牌（Access Token） 包含有关实体访问信息系统的授权信息的 JSON Web 令牌 (JWT)。

JSON Web Token (JWT) 包含已验证用户声明的 JSON 格式文档。ID 令牌用于验证用户身份，访问令牌用于授权用户，刷新令牌用于更新凭证。

IAM角色 IAM 角色是一种提供短期有效凭据的访问亚马逊云科技云资源的方式，角色的安全凭据经过加密和自动轮换，是安全的认证和访问方式；适合请求AWS资源，比如访问S3存储桶，调用Amazon Lambda，读取DynamoDB里面的数据等。

API 密钥 API密钥是一个唯一的标识符，用于验证对 API（应用程序编程接口）的请求。它就像一个密码，允许您的应用程序访问特定服务，例如 OpenAI API key。很多大模型工具的使用需要用到API密钥，包括亚马逊云科技的Bedrock服务也支持了API密钥访问的方式。

OAuth 2.0

OAuth 2.0的授权机制是Agentic AI身份授权的核心技术

1 OAuth 2.0 行业标准授权协议和框架（定义见 RFC 6749），允许应用程序在不暴露用户凭据的情况下获得对外部服务用户帐户的有限访问权限。OAuth 2.0 允许用户通过访问令牌（而非共享密码）授予第三方应用程序对其资源的访问权限，从而提供安全委托。对于代理应用程序，OAuth 2.0 支持跨多个服务安全地访问用户数据，同时保持适当的身份验证边界和用户同意机制。

2 OAuth 2.0 授权器（OAuth 2.0 authorizer） 一个 SDK 组件，用于对传入代理端点的 OAuth 2.0 API 请求进行身份验证和授权。它会在允许访问代理服务之前验证令牌。

3 OAuth 2.0 client credentials grant (2LO) OAuth 客户端凭据授予用于无需用户交互的机器对机器身份验证。代理使用 2LO 直接向资源服务器进行身份验证。

4 OAuth 2.0 authorization code grant (3LO) OAuth 授权需要用户同意和交互。例如当客服人员需要明确的用户权限才能从 Google 日历或 Salesforce 等外部服务访问用户特定数据时，他们会使用 3LO。

5 代理访问令牌（Agent access token 包含工作负载身份和用户身份信息的签名令牌，使下游服务能够基于这两个身份做出授权决策。这些令牌是通过令牌交换过程创建的。

6 令牌保险柜（Token vault） 一个用于存储 OAuth 2.0 令牌、API 密钥和其他凭证的安全存储系统，该系统采用严格的访问控制机制。令牌保险柜确保只有最初获取凭证的特定代理和用户组合才能访问这些凭证。

7 服务到服务的授权（Machine-to-machine authorization） 常被称作M2M授权，授权非用户交互机器实体（例如 Web 服务器应用层）对 API 端点的请求进行授权的过程。用户池通过客户端凭证授权提供 M2M 授权，并在访问令牌中使用 OAuth 2.0 范围。

Agentic AI系统中，普遍采用的授权机制是基于OAuth 2.0进行的，包括MCP协议也是基于其进行授权。所以，深入理解Agentic AI各组件间的身份认证与授权机制的前提是充分理解OAuth授权的流程。

在Agentic AI系统的设计中，需要根据不同的业务场景来选择合适的OAuth 工作模型。其中典型的模式有2腿授权（2-Legged Auth，2LO）和3腿授权（3-Legged Auth，3LO），如果需要用户（User）参与其中的授权流程适合用3LO，如果不需要用户参与的适合用2LO。

Agentic AI中的身份认证与授权，和传统应用中的身份认证与授权的核心区别

传统应用（没有使用Agentic AI之前的应用）对用户的身份管理和授权是非常明确的，即对当前登录应用系统的用户身份进行认证和授权，包括单点登录SSO认证、细粒度授权和OAuth授权等。但应用系统中引入Agentic AI技术后，数据的查询和第三方系统的调用等，会由AI Agent代理来完成，因为当前登录的用户要查询或操作的内容可能不是对其自身的查询或操作，有可能是通过prompt的方式查询或操作其他用户的信息，这一点是与传统应用的最大区别。我们通过两个示例图来进行对比和说明：

在企业级AI应用中，这个问题变得更加复杂。不同用户可能对同一数据集具有不同的访问权限，但LLM无法自主区分这些权限差异。例如，在一个企业知识管理系统中，销售团队和财务团队可能对客户数据具有不同的访问权限，但如果这些数据都被用于训练或增强同一个LLM，模型就无法自动执行这种权限区分。

解决授权问题需要在应用架构层面实施确定性的授权机制。这包括在数据输入LLM之前进行权限检查，根据用户身份和权限过滤可访问的数据源。在RAG系统中，可以根据用户权限动态选择可查询的向量数据库或知识库。在模型输出阶段，也需要根据用户权限对响应内容进行过滤和脱敏。

基于会话属性的权限传递是一种有效的解决方案。通过安全侧通道（如Amazon Bedrock Agents的会话属性）传递用户身份和权限信息，使后端系统能够在处理AI请求时执行适当的授权检查。这种方法将授权决策从不可靠的LLM推理转移到可控的应用逻辑中。

MCP协议中混淆代理人提权问题

MCP协议的设计理念导致其在架构层面就系统性地引入了传统安全领域中经典的" 混淆代理人 " 问题（ Confused Deputy Problem）。首先，MCP 服务器作为一个独立的进程运行，拥有其自身在主机系统上的权限集合，例如文件系统读写权限或网络访问权限。其次， LLM 客户端通常代表用户行事，向服务器发送请求以执行工具。但是 MCP 规范在其默认状态下，缺乏一个统一且被一致性执行的认证和授权机制，来将终端用户的身份和权限安全地传递给服务器。因此，当一个用户（可能是低权限用户）通过 LLM 提示调用一个工具时，服务器实际上是使用其自身的权限（可能是高权限）来执行该操作，而非用户的权限。这就创造了一个典型的权限提升场景，即一个低权限的请求者（用户）欺骗了一个高权限的代理（服务器）来执行越权操作。此类越权问题，通过给大模型LLM作系统级提示词限制也只能在少部分情况下生效，且有不确定性。

混淆代理问题是AI应用安全中最具挑战性的威胁之一，并把传统的威胁效果放大。这种攻击利用了AI系统的代理特性，通过具有更高权限的AI应用间接获取原本无权访问的资源。攻击的典型场景是：用户直接访问某个资源会被拒绝，但通过AI应用访问同样的资源却能成功，从而绕过了原有的安全控制。混淆代理安全威胁示例：直接访问 S3 存储桶的用户会被拒绝访问；但访问 LLM 的用户（使用 RAG 并存储来自同一 S3 存储桶的数据）则会获得访问权限。

这种攻击的根本原因在于AI应用和底层资源之间的权限不匹配。AI应用为了完成复杂任务，往往被授予了较高的系统权限，但这些权限的使用缺乏细粒度的控制。当用户通过AI应用间接访问资源时，实际上是借用了AI应用的权限，而不是基于用户自身的权限。

构建端到端的Agentic AI身份管理的整体防护策略

防范混淆代理攻击需要实施严格的权限一致性检查。无论用户通过何种途径访问资源，都应该基于相同的权限模型进行授权决策。这要求在AI应用的架构设计中引入用户身份传递机制，确保底层系统能够识别真实的请求者身份。

实施细粒度的权限代理是另一种有效的防护策略。AI应用不应该拥有超出其功能需求的权限，而应该基于具体的用户请求动态获取相应的权限。这可以通过权限委托机制实现，AI应用代表用户请求特定的权限，而不是拥有固定的高权限。

审计和监控机制对于检测混淆代理攻击至关重要。系统应该记录所有的权限使用情况，包括权限的来源、使用者、访问的资源和操作类型。通过分析这些审计日志，可以识别异常的权限使用模式和潜在的安全威胁。

OWASP对于Agentic AI的15个威胁风险中，虽然只有2个与身份相关，但这两个风险点特别是T9身份欺骗与冒充威胁，会发生在Agentic AI系统中的多个环节，因此构建Agentic AI系统的端到端身份管理解决方案是非常有必要的，具体参考架构图如下：

端到端的身份认证与授权系统，包括如下几个核心能力。具体示例可以参考下一章节的基于亚马逊Bedrock AgentCore Identity开发Agentic AI系统的身份模块的相关内容。

Agent入方面的认证和授权：对请求的用户进行认证和授权，包括通过第三方身份提供商登录进来的用户。

外部工具或服务对Agent的授权：不论是自己研发的一方工具，还是第三方研发的商业化或开源的工具，都需要对Agent或Agent代表用户的授权，避免委托人攻击。

Agent访问外部工具或服务的能力（即出方向）：为了配合外部工具或服务对Agent的授权，Agent需要具备 OAuth 客户端的能力，包括2LO和3LO的方式。如果是访问云资源，需要有保存云资源访问短期权限的能力，如IAM role或STS。

Tool Gateway入方向认证和授权：如果通过Tool Gateway方式集中管理多个MCP服务器，Agent由Tool Gateway来访问tools，那么Tool Gateway需要具备对Agent或Agent代表用户的授权。

Amazon Bedrock AgentCore Identity -- 全托管一站式解决方案

Amazon Bedrock AgentCore Identity 是一项全面的身份和凭证管理服务，专为 AI 代理和自动化工作负载而设计。它提供安全的身份验证、授权和凭据管理功能，使用户能够调用代理，而代理能够代表用户访问外部资源和服务的同时保持严格的安全控制和审计跟踪。该服务与 Amazon Bedrock AgentCore 原生集成，为代理应用程序提供全面的身份和凭证管理。

AgentCore Identity 解决了 AI 代理部署中的一个根本性挑战：让代理能够在多个服务中安全地访问用户特定数据，同时不牺牲安全性和用户体验。传统方法要么使用广泛的访问凭证而缺乏细粒度控制，要么需要为每次服务集成获取明确的用户同意（这会带来糟糕的用户体验）。AgentCore Identity 通过一个全面的工作流实现零信任安全原则和基于委托的身份验证来解决这一问题。

Amazon Bedrock AgentCore Identity 涉及的2种身份认证和授权

入站授权：Inbound Auth 是指验证用户或客户端应用的认证机制，用于控制谁可以访问和调用您的代理或工具。

出站授权：Outbound Auth 是指已通过入站认证的代理，安全访问目标服务的认证机制，使代理能够安全地调用各种外部API、Lambda函数等资源。

入站授权

用户通过其组织的现有身份提供者（如 Auth0、Cognito 或其他 OIDC 兼容系统）进行身份验证，并获得访问令牌或身份令牌。该令牌包含用户身份信息和授权范围，为整个工作流程建立用户的身份上下文。应用程序接收此令牌，并将使用它来授权对代理的请求。

出站授权

Amazon Bedrock AgentCore Identity验证对 AWS 资源、第三方服务或 AgentCore Gateway 目标的访问权限。您可以使用 OAuth 2LO/3LO 或 API 密钥。身份系统简化了管理多种凭证类型的复杂性，同时为身份验证和授权操作提供了统一的接口。

AgentCore Identity 的安全性

安全的凭证存储，代码中没有硬编码的API密钥，不容易泄漏机密

跨多种资源类型的一致身份验证接口

全面的审计日志以确保安全性和合规性

基于身份和上下文的细粒度访问控制

通过 AgentCore SDK 简化集成

安全与隐私保护

安全与隐私保护，基于 OWASP Agentic AI 威胁模型，Agent 系统面临记忆投毒、工具滥用、权限滥用、身份欺骗等多种安全威胁。开发时需要实施分层防护策略，在用户输入、模型推理、工具调用、输出生成等各个环节建立独立的安全过滤机制。

运维工程

质量评估

质量评估，Agent 的智能行为需要专门的评估机制，包括推理质量评估、任务完成率统计、用户满意度收集等。例如可以基于 LLM-as-a-Judge 自动化评估结合人工审核，建立持续的质量保证体系。

Agent 评估是指对 Agent 在执行任务、决策制定和用户交互方面的性能进行评估和理解的过程。由于 Agent 具有固有的自主性，对其进行评估对于确保其正常运行至关重要。

不包含工具调用的 Agent 通常采用文本到文本的评估方式，类似于标准的大语言模型基准测试。然而，现代AI智能体执行的操作更加广泛和复杂，包括多步推理、工具调用和与外部系统交互等，这需要更全面的评估方法。评估不能仅停留在表面的文本质量层面，还需要评估智能体的整体行为、任务成功率以及与用户意图的一致性。

除了衡量任务性能外，Agent 评估还必须优先考虑安全性、可信度、政策合规性和偏见缓解等关键维度。这些因素对于在现实世界的高风险环境中部署智能体至关重要。同时，为避免开发出高性能但资源密集型的智能体而限制其实际部署，成本和效率测量也必须纳入评估范围。

评估方法可以包括基准测试、人机协作评估、A/B测试和真实世界模拟等。通过系统性地评估 Agent，优化自动化工作，提升业务功能，同时最大限度地降低与不安全、不可靠或有偏见的智能体AI相关的风险。

评估的一般步骤

(1) 定义评估的目标和指标。需要结合 Agent 应用构建后实际应用的场景以及期望的输出来选择合适的指标。

(2) 收集数据并准备测试。为了有效的评估 Agent 应用，最好使用真实场景的数据进行测试数据集的构建；构建的测试数据根据实际处理任务以及任务复杂度进行构建，尤其对于复杂的多步骤任务，构建完整的推理步骤进行 Agent 应用的评估对于整体效果有着更好的保障。

(3) 执行并分析结果。一般来讲，最准确的评估结论是在制定好评估准则和指标后的人工评估。但是人工评估速度较慢且成本较高，选择一个能力最强的模型，使用 LLM as jugde 是一个更有效率更有性价比的方法。需要关注在应用是否选择了正确的工具/函数？是否在正确的上下文中传递了正确的信息？是否产生了事实准确的回应？

(4) 优化测试数据集，迭代评估。

常用评估指标

Agent 评估指标非常多，可以分为业务类型指标、效率类型指标、安全类型指标等。同时也可以根据实际情况进行自定义指标设计。以下是一些常用指标的举例。

业务类型指标：

(1) 任务完成率（Task Completion Rate, TCR）

应用场景：

电商客服场景：智能客服 Agent 处理"退换货申请""物流查询"等任务时，成功解决用户问题的比例。例如，100 个退换货咨询中，85 个能通过 Agent 自主完成流程（无需转接人工），则任务完成率为 85%。

金融风控场景：信贷审核 Agent 对贷款申请的自动审批任务，符合预设规则且准确通过/拒绝的申请占比。若 1000 笔申请中，920 笔的审批结果与人工复核一致，则任务完成率为 92%。

(2) 决策准确率（Decision Accuracy）

应用场景：

医疗辅助场景：AI 诊断 Agent 分析患者病历、影像报告并给出初步诊断建议时，每个推理步骤（如症状匹配、疾病排除）的正确比例。例如，在 100 个诊断流程中，关键决策步骤的正确率为 90%，则决策准确率为 90%。

供应链调度场景：仓储调度 Agent 规划货物分拣路径时，每个调度步骤（如优先级排序、仓位分配）符合最优方案的比例。若 100 次调度中，88 次的路径规划无冗余步骤，则决策准确率为 88%。

(3) 工具调用正确率（Tool Call Accuracy）

应用场景：

企业 HR 场景：招聘 Agent 筛选简历时，调用 "学历验证接口""工作经历核查工具" 的必要性比例。例如，100 次简历筛选中，90 次工具调用是为核实关键信息（非冗余调用），则准确率为 90%。

旅游服务场景：行程规划 Agent 为用户定制旅行方案时，调用 "机票比价工具""酒店库存查询 API" 的合理性。若 100 次工具调用中，85 次能直接辅助生成符合用户需求的方案，则准确调率为 85%。

效率指标：

(1) 平均任务耗时（Average Time）

应用场景：

银行柜台辅助场景：柜员辅助 Agent 处理 "开卡""转账" 等业务时，从用户提交资料到完成操作的平均时间。例如，100 笔开卡业务总耗时 300 分钟，平均耗时 3 分钟 / 笔，需与人工办理效率对比评估。

(2) 平均交互轮数（Average steps）

应用场景

零售客服场景：智能客服Agent处理"退换货""商品咨询""订单查询"等服务时，从客户发起咨询到问题解决所需的平均对话轮数。例如，200个退换货咨询总共产生1400轮对话，平均交互轮数为7轮/次，可用于评估Agent的问题理解能力和解决效率。交互轮数越少，表示Agent能够快速准确理解客户需求并提供有效解决方案。

伦理与安全性指标：

（1）偏见发生率（Bias rate）

招聘场景：招聘筛选 Agent 对简历的评估是否存在性别 / 年龄偏见（如同等条件下优先排除女性候选人）。若 1000 份简历评估中，有 30 份因不合理偏见被错误筛选，则偏见率为 3%。

打车平台场景：网约车调度 Agent 是否对不同区域用户（如郊区 vs 市区）存在派单延迟偏见。若 1000 次郊区订单中，50 次因偏见导致派单慢于合理时间，则偏见率为 5%。

如何构建一个通用 Agent 评估方案

评估数据的准备

通常情况建议从实际的业务数据任务里进行采集，做成标准的 Agent 测试集。

如果没有真实业务可采集 Agent 处理流数据，则可以通过人工创建一些示例数据，然后通过 self-instruct 方式生成一批测试数据集来进行冷启动。

评估指标

(1) Tool 调用准确率 ：Tool 调用的准确率是 Agent 应用最基础的保障，决定了最终任务的失败，因此该指标作为Agent基础能力的体现，是必须要进行的一项评估，但是评估的方式可以实际选择：

细粒度检测：逐个工具调用的对比，以及调用工具对应参数提取正取率的对比，如下图所示。

粗粒度检测：可以直接对比所有工具调用完成后任务环境的一致性，如 AgentBench 虚拟docker 环境验证或 τ-bench 中的提到的数据状态变更的一致性检测。

(2) 总体任务完成率 :

总体的任务的完成度指标随着不同的 Agent 的应用场景指标也会有变化，部分场景甚至可能会跟前面提到的 Tool 调用准确率的粗粒度评估方式比较接近，直接查看最终应用调用完成后数据状态变更或者系统状态变更的一致性来进行检测。

另外对于一些有正确答案的数据集且内容详规固定，可以直接使用一些规则进行评估，例如 Rouge， Bleu，完全匹配率，编辑距离等

归因分析

在完成评估后，针对实际评估结果进行失败测试用例的原因分析，从而针对性的优化开发的 Agent 应用。当然归因分析也是既可以使用基于规则的方式，也可以使用 LLM as Judge 的方式。

其他建议

建议结合使用自动化和人工评估方法：自动化指标提供量化见解，而人工评估则对连贯性和相关性等因素提供定性评估，当然使用 LLM 替代人工进行一些总体评估也是一个在实际业务中常用到的方法。如借助LLM as Judge使用大语言模型来评估 Agent 输出质量的方法，通过让 LLM 扮演"评判者"角色，根据预定义的评估标准对 Agent 的表现进行打分和判断。同时从评估范围上既可以对 Agent 最终回答进行评估，也可以对中间推理过程进行打分，但需要注意对评估模型推理能力和上下文窗口的要求。

选择评估指标时考虑应用场景：不同的用例可能需要不同的评估方法。例如，聊天机器人大语言模型系统可能优先考虑参与度和连贯性，而翻译系统则会关注准确性和流畅性。

评估过程的监控：结合开源的 langfuse 等可观测性框架，在评估过程中进行观测以及监控 Agent 任务的完成成本以及推理时延。

AgentCore Evaluations

Evaluations：面向 Agent 的自动化评估，衡量任务完成度、边界处理、输出可靠性；消费 Strands/LangGraph 经 OTEL/OpenInference 埋点的 sessions/traces/spans，结果并入 Observability \^2。

Evaluations 如何评估------旁路、基于 trace、LLM-as-a-Judge（关键：不需要在业务/Agent 代码里写评估或判断逻辑）\^22：

  • 输入：Agent 运行产生的 trace / span（来自 Strands、LangGraph，经 OpenTelemetry / OpenInference 埋点），流入 CloudWatch。
  • 核心技术：底层把 traces 转成统一格式，用 LLM-as-a-Judge（用一个模型当"裁判"）跑内置或自定义 evaluator。
  • 评估器（evaluator）：每个有唯一 ARN（内置如 Builtin.Helpfulness，公开可用；自定义私有，用 IAM 资源策略授权）；默认每区每账户可建 1000 个评估配置。
  • 落地方式：只需①让 Agent 用 OTEL/OpenInference 埋点；②创建一个 online evaluation configuration（声明用哪些 evaluator、监控哪些数据源、评估参数）。配好后即自动、持续对生产会话打分。

什么时候评估------三个时机：

时机

评估模式

目的

上线前

dataset / simulation / batch / on-demand

用数据集或模拟场景建立质量基线

上线后

online（自动持续）

对真实流量持续监控打分

改动后

A/B 的 online 评分

验证新版本是否真的更好

AgentCore Optimization

Optimization：持续改进。基于 Evaluations，用 AI 建议 + 版本化配置包 + A/B（经 Gateway 流量切分）优化系统提示与工具描述 \^2。

Optimization 如何优化------"数据驱动 + 人工发起"的闭环（不是全自动偷改 prompt）\^23：

  1. Recommendations：评估暴露失败模式后，你主动调 Recommendations API，指向 CloudWatch 里的 traces + 指定要优化的目标 evaluator，服务分析失败模式，产出优化后的 系统提示 / 工具描述 + "改了什么、为什么"的解释；
  2. Configuration bundles（可选）：把推荐配置打包成版本化、不可变的快照（系统提示、model ID、工具描述），改行为无需改代码重新部署；
  3. A/B testing：经 Gateway 把流量分成 control / treatment，online 评估逐会话打分并报统计显著性；变体可为同 Runtime 的不同 bundle 版本，或指向不同 Runtime 端点的不同 Gateway target；
  4. 全量 + 迭代：赢的变体全量，新 trace 成为下一轮基线。

判断逻辑在哪？ 不在 Agent 代码里（没有 if-else），而在"evaluator 分数 → 人看 recommendation → A/B 统计结果"这条链上。触发点是"评估分数变差或失败模式聚集"，由人拍板是否优化、是否全量。

可观测性

可观测性，Agent 的非确定性行为要求全新的监控方式。我们需要追踪推理链路、监控工具调用合理性、分析 记忆 使用情况、检测安全事件、收集用户体验指标。这种"思维过程"的可视化对于调试和优化 Agent 行为至关重要。

由于大语言模型会引入思考、执行和输出的多种不确定性，Agent 应用在开发、调试和落地环节中，需要一个多层次的监控体系。在基础设施层，需要追踪 Agent 运行环境的资源使用情况；在应用层，重点监控 Agent 的性能表现和调用链路；在业务层，则需关注用户体验和任务完成情况。

AgentCore可观测性：提供 Agent 执行过程的逐步可视化功能，包括元数据标记、自定义评分、轨迹检查以及故障排除/调试过滤器等。

传统微服务或 Web 应用的 "Metrics → Logs → Traces" 可观测模型，仅能回答 "发生了什么"，却无法解释 Agent 场景下的核心问题：

决策的 "原因"：Agent 为何选择此时发起特定调用？基于怎样的上下文与推理？

行为的 "链条"：此次调用前，Agent 是否经过多轮交互？这一步是关键环节还是无效尝试？

结果的 "质量"：返回内容是否提升任务完成度，还是引入新偏差？

核心监控指标

（1）响应时间指标

时间维度指标直接反映 Agent 性能，是用户体验的核心影响因素：

总体请求处理时间（TotalTime）：从接收用户请求到生成最终响应的完整耗时。例如，用户查询 "巴黎天气" 时，500ms 理解问题、300ms 调用 API、200ms 生成回答，总计 1000ms。该指标用于定位性能瓶颈，优化端到端响应速度。

首个 Token 生成时间（TTFT）：从请求开始到生成第一个响应 Token 的时间，关键衡量系统 "即时反馈能力"。例如，200ms 内开始生成回答，对流式响应场景至关重要，直接影响用户等待感知。

模型延迟（ModelLatency）：仅衡量大模型推理的耗时，用于对比不同模型的性能表现，为场景化模型选择提供数据支撑。

（2）Token 使用指标

Token 消耗直接关联运营成本与资源效率，需精准监控：

输入 Token 数量（InputTokenCount）：发送给模型的 Token 总数（含系统提示词、上下文历史、用户问题）。例如，包含多轮对话历史的请求可能消耗 1000 个 Token，用于优化提示词设计与上下文管理策略（如上下文截断、摘要压缩）。

输出 Token 数量（OutputTokenCount）：模型生成的 Token 总数。例如，详细的天气报告可能产生 200 个 Token，监控该指标可平衡响应详尽度与成本控制。

（3）工具使用指标

工具调用是 Agent 与外部系统交互的核心方式，其效率直接影响任务成功率：

调用频率（InvocationCount）：每个工具的调用次数统计。例如，客服 Agent 中知识库查询工具的使用频率是订单查询工具的 3 倍，可指导工具缓存优化或功能优先级调整。

工具执行时间：单个工具的平均 / 峰值响应耗时。例如，天气 API 平均响应时间超 800ms，需考虑更换服务或添加缓存机制。

工具调用成功率：工具调用无错误返回的比例（如 API 调用成功、参数合法），用于识别不可靠工具或接口设计问题。

Agent 追踪：完整执行链路视图

追踪（Tracing）是 Agent 可观测性的核心 ------ 相比指标的 "结果化" 和日志的 "碎片化"，追踪能提供决策过程的完整上下文链路，解释 "为什么" 和 "如何交互"。基于 OpenTelemetry 标准，Agent 追踪通过Trace ID（完整会话标识）和Span ID（单个操作标识）构建层次化执行树，记录从用户输入到响应生成的全流程。

（1）追踪核心维度

Agent 执行追踪：

系统级追踪：记录请求完整生命周期（用户输入→系统提示→模型推理→工具调用→响应生成），形成全局执行图谱，理解决策全貌。

推理周期追踪：深入每个推理步骤，记录思考过程、工具调用决策依据、中间结果处理方式，用于调试复杂多步推理链。

错误和异常追踪：

客户端错误：记录参数错误、认证失败等用户 / 调用方问题，用于优化 API 设计与文档。

服务器错误：追踪模型调用失败、资源不足、工具接口异常等服务端问题，提升系统可靠性。

（2）OpenTelemetry 集成机制

Agent 追踪需遵循 OpenTelemetry 标准，实现数据标准化采集与传输：

Span 结构：每个操作（模型调用、工具执行、上下文检索）对应一个 Span，包含唯一 Span ID、父 Span ID（构建层级关系）、开始 / 结束时间、状态码、属性等信息。

Baggage 机制：跨服务元数据传递工具，可携带用户类型、实验标识、会话主题等业务属性，自动附加到所有关联 Span，为离线评估、A/B 测试提供上下文。

数据传输：通过 OTLP（OpenTelemetry Protocol）将追踪数据发送至后端分析平台，支持自动注入 SDK（如 Python 应用通过 opentelemetry-instrument 命令快速集成）。

（3）追踪数据样本

该样本展示了 Strands Agent 框架的 OpenTelemetry 原生集成能力：自动捕获用户消息、模型选择、工具调用参数、Token 消耗等关键信息，遵循 OpenTelemetry GenAI 语义约定，确保数据标准化与互操作性。

（4）OpenTelemetry Collector 作用

生产环境中，通常部署 OpenTelemetry Collector 作为数据中间处理层，实现：

数据接收：支持多种协议（OTLP、Jaeger、Zipkin）收集追踪 / 指标数据。

数据处理：通过处理器组件优化数据（如添加环境标签、智能采样、过滤敏感信息、批量传输）。

数据导出：将处理后的数据发送至目标平台（如 Langfuse、MLFlow、自建分析系统），灵活适配不同存储与分析需求。

利用可观测性组件运维 Agent

以 "电商售后智能客服 Agent" 为例（基于 Strands Agent 构建，支持订单查询、售后处理、退款申请等功能，集成电商系统 API 工具），展示可观测性组件在开发、测试、生产阶段的运维实践。

场景 1：新模型发布对比测试

需求

上线 Claude 3.7 和 Nova Lite 两种模型，需对比其在售后咨询场景的性能、成本与效果，选择最优模型。

运维操作

在 Langfuse 中创建两个测试会话，分别使用两种模型处理相同售后查询（如 "查询订单号 #12345 的物流状态并申请退货"）。

从 Langfuse 仪表盘查看关键指标对比：模型总耗时输入 Token输出 Token工具调用次数任务完成率Claude 3.71.8s5201802（订单查询 + 退货申请）100%Nova Lite1.2s5102102100%

深度分析：

性能：Nova Lite 延迟低 33%，更适合对响应速度敏感的场景。

成本：Claude 3.7 输出 Token 少 14%，长期使用成本更低。

效果：两者均完成任务，但 Claude 3.7 的响应更简洁，符合售后场景的用户需求。

决策：选择 Claude 3.7 作为主模型，Nova Lite 作为备用模型（应对流量峰值）。

场景 2：模型切换导致的错误排查

问题现象

将主模型从 Claude 3.7 切换为 Nova Lite 后，部分售后咨询出现工具调用失败，错误提示 "参数格式不合法"。

运维操作

在 Langfuse 中筛选 Nova Lite 模型的失败会话，查看完整执行链路。

定位错误环节：发现工具调用的 order_id 参数格式不一致 ------Claude 3.7 输出为字符串格式（如 "12345"），而 Nova Lite 输出为数字格式（如 12345），导致电商 API 接口解析失败。

查看推理过程：通过 Langfuse 的 "中间步骤" 追踪，发现 Nova Lite 对提示词中 "订单号为字符串类型" 的要求理解不充分，未进行格式转换。

修复方案：优化提示词，明确要求工具调用参数必须为字符串格式；在 Agent 代码中添加参数格式校验与转换逻辑。

验证效果：重新部署后，在 Langfuse 中监控工具调用成功率，确认错误率降至 0。

场景 3：新功能上线全流程分析

需求

为售后客服 Agent 新增 "卖家销售额查询" 功能（接入电商系统 MySQL 数据库），需验证功能可用性与性能。

运维操作

发起测试查询："查询今年销售额最高的 3 个客户"，在 Langfuse 中查看完整执行链路。

链路分析：

Claude 3.7：生成 SQL 语句前先确认时间范围（"今年指 2024 年吗？"），生成后校验语法，工具调用一次成功，总耗时 2.5s。

Nova Lite：直接生成 SQL 语句（未确认时间范围），因语法错误导致工具调用失败，二次重试后成功，总耗时 4.2s。

性能优化：

为 Claude 3.7 新增 SQL 生成模板，减少推理时间（优化后耗时降至 1.8s）。

为 Nova Lite 补充 SQL 语法提示与格式校验逻辑，避免重试。

质量评估：通过 Langfuse 的 LLM as Judge 功能，自动评估查询结果准确性（如是否匹配数据库实际数据），设置准确率阈值 95%。

AgentCore Observability

Observability 提供生产 Agent 的统一追踪/调试/监控视图：可视化工作流每一步、审查 Agent 执行路径与中间输出、定位性能瓶颈与失败 \^2。

实现关键：遥测数据以标准 OpenTelemetry（OTEL）兼容格式 发出，因此可对接任意支持 OTEL 的监控栈 \^2；Evaluations、Optimization 等模块也都基于同一套 OTEL 埋点，结果统一并入由 Amazon CloudWatch 支撑的 Observability \^2。

Runtime ------ ReAct 主体

AgentCore运行时：提供了低延迟的无服务器环境，用于部署 Agent 或 MCP 工具。该环境具备会话隔离功能，支持各类 Agent 框架，包括流行的开源框架（如 Strands Agents、LangGraph、CrewAI 等）。此外，它能够集成各种工具和模型，并有效处理多模态工作负载及长时间运行的 Agent 应用。

在实际部署中，Agent 应用运行时和 Agent 工具运行时是整个系统的核心。它们需要提供兼容各种开发框架的服务接口，并在 Agent 业务价值尚未明确的情况下，能够动态调整资源以最大限度地节省成本。此外，我们需要考虑几个关键因素：

（1）会话管理。Agent 的会话隔离机制和鉴权方式实现身份管理和隔离确保了多用户环境下的安全性。每个用户的 Agent 会话都在独立的安全沙箱中运行，避免了数据泄露和交叉污染的风险。

（2）生命周期管理。Agent 的会话状态会因模型调用、服务等待等因素充满着不确定性，运行时能够根据业务需求来调整状态转换的策略。对于有状态的业务，需要将状态信息持久化，确保在系统重启或故障恢复时能够正确恢复 Agent 的工作状态。

（3）接口标准化。通过脚手架，运行时被变成对外的 HTTP 服务，根据 Agent 类型分配不同端口和路径，支持健康检查。这种标准化的接口设计让 Agent 可以轻松地集成到现有的基础设施中。

推理引擎

推理引擎，推理引擎是 Agent 的"大脑"，通常基于大语言模型实现。它负责理解用户意图、制定执行计划、任务执行。在开发层面，这意味着我们需要精心设计提示词模板、优化推理链路、控制推理成本。推理引擎的质量直接决定了 Agent 的智能水平。

AgentCore Runtime

两种计算类型（同页 \^5）：

计算类型

形态

最长时长

特点

适用

microVM

全托管无服务器

8 小时（上限 28800 秒）

即时启动、按需自动扩展、一会话一 VM

实时交互、突发流量、短-中时任务

Instances

用户账户内的 AWS 托管 EC2

14 天

持久多日会话、GPU 加速、多 Agent 共享实例

长时运行、需 GPU、多 Agent 协作

运行特性：快速冷启动（面向实时交互）、异步/长时运行支持、内置身份（built-in identity）、多模态、多 Agent ^2^5。

协议原生支持：Runtime 可通过 MCP 与 A2A 与其他 Agent、工具通信 \^5；可直接部署 MCP server、A2A server 与 AG-UI server；A2A 支持在 GA 时随 Runtime 一并提供 ^3^14。

部署方式：兼容任意框架产出的 Agent，开发者把 Agent 打包后交给 Runtime 托管，无需自己管理扩缩容与基础设施 ^4^5。

任务编排工程

规划模块

负责协调其他三个组件的工作，管理 Agent 的整体执行流程。它承担任务分解、执行计划制定、工具调用编排等职责。如 Strands Agents 的任务编排器、LangGraph 的图执行器等。

多智能体系统

多智能体系统（MAS）正在重塑人工智能解决问题的基本范式。通过协调多个自主智能体的工作，突破了单一智能体的能力边界，在复杂任务处理上展现出独特优势。从技术架构来看，现代 MAS 主要依赖三大核心组件：标准化的通信协议确保不同架构智能体间的无缝对接，智能化的编排机制实现任务的动态分配与调度，以及精细化的协同策略保障系统运行的稳定性。

在通信协议层面，系统采用 MCP（模型上下文协议）、A2A（智能体间通信）和 ANP（网络互操作）等标准化方案，为异构智能体提供互联基础。协调机制则通过先验协调与后验协调相结合的方式实现任务优化。其中先验协调进行预执行分析，后验协调则对并行响应进行评估。同时借助 SagaLLM 等框架的事务完整性保障，通过补偿机制和独立验证确保系统可靠性。这些技术已在医疗分诊代理、网络管理中的上下文感知协调等场景中得到成功验证，展现出多智能体协同的实践价值。

A2A

开发框架

AWS Strands Agents SDK

Strands Agents 是一个轻量级、代码优先的 Agent 构建框架，专为简化 Agent 开发而设计。它提供了生产就绪的解决方案，支持多种模型提供商和部署目标，默认集成 Amazon Bedrock 和 Claude 模型。

框架的核心优势在于其简洁性------开发者只需几行代码就能创建功能完整的 Agent，同时保持了高度的可定制性和扩展性。Strands Agents 支持对话式和非对话式 Agent、流式和非流式响应，并内置了完整的可观测性、追踪和安全功能，使其成为企业级 Agent 应用的理想选择。观测性、追踪和安全功能，使其成为企业级 Agent 应用的理想选择。

Strands Agents 对话管理

在 Agent 应用中，对话管理直接影响性能、成本和用户体验。随着交互进行，上下文信息不断累积，若不加管理会导致窗口溢出、响应延迟和成本上升。Strands Agents 提供三种对话管理模式，适应不同场景需求。

Strands Agents 对话管理器 提供三种对话管理模式，体现不同的设计理念和适用场景。

NullConversationManager 代表"完全保留"策略，适用于短期交互、调试环境或需要完整上下文分析的场景，特别是研究环境、问题诊断或有合规性要求的场景。

SlidingWindowConversationManager 体现"时间优先"理念，基于最近对话通常比历史对话更相关的假设，保持固定数量的最近对话轮次。这种策略确保上下文大小可控，提供稳定的性能和成本，适合客服机器人、问答系统等任务导向的 Agent。

SummarizingConversationManager 代表"智能压缩"理念，通过总结保留历史信息精华而非简单丢弃，适合需要长期上下文理解的复杂应用，如代码助手或项目管理 Agent。当用户询问"之前讨论的性能优化方案是什么？"时，总结管理器能从压缩的历史摘要中提取相关信息，而非简单回答"不记得了"，特别适合代码助手或项目管理 Agent。

Strands Agents 记忆管理

除了对话管理，Strands Agents 记忆模块通过集成 Mem0.ai 提供了强大的持久化记忆能力，这是上下文工程在长期记忆维度的重要体现。与对话管理主要处理短期上下文不同，记忆管理解决的是跨会话的长期信息保持问题，让 Agent 能够真正"记住"用户的偏好、历史交互和重要信息。

Strands Agents 通过 hooks 机制提供了灵活的记忆管理能力，这是上下文工程在长期记忆维度的重要体现。与对话管理主要处理短期上下文不同，记忆管理解决的是跨会话的长期信息保持问题，让 Agent 能够真正"记住"用户的偏好、历史交互和重要信息。

Strands Agents 的 hooks 机制允许在 Agent 执行生命周期的特定节点注入自定义逻辑。对于记忆管理，核心是两个关键事件：MessageAddedEvent（消息添加时）和 AfterInvocationEvent（调用完成后）。通过监听这些事件，可以实现记忆的自动检索和存储，无需在业务代码中显式调用记忆管理 API。

这种 hooks 驱动的记忆管理体现了上下文工程的分层处理思想：检索阶段通过语义搜索快速定位相关记忆，注入阶段将记忆作为上下文补充到用户消息中，存储阶段自动保存新的对话内容。整个过程对业务代码透明，开发者只需关注 Agent 的核心逻辑。

在实际应用中，当用户说"记住我喜欢靠窗的座位"时，系统通过 save_memories hook 自动存储这个偏好。几天后用户询问"帮我预订机票"时，retrieve_memories hook 会自动检索到座位偏好信息并注入到上下文中，Agent 能够主动提醒用户选择靠窗座位。这种自动化的个性化服务正是现代 AI 助手的核心竞争力。

Strands Agents 的记忆管理可以与Amazon Bedrock AgentCore Memory无缝集成，后者提供了企业级的记忆存储、语义检索和多租户隔离能力。通过 hooks 机制，开发者能够将 AgentCore Memory 的强大功能以声明式的方式集成到 Agent 中，无需修改核心业务逻辑，实现真正的关注点分离。

AgentCore Harness

Harness 是较晚推出、但在"迁移与低门槛构建"中被官方首推的模块 \^17。

定位：一个声明式的托管 Agent 循环------开发者用单次 API 调用内联声明"模型 + 系统提示 + 工具"，Harness 自动处理编排、工具执行、记忆管理与响应生成 \^2。每个会话跑在隔离 microVM 中，带文件系统与 shell 访问，可自带容器镜像 \^2。

支持：托管编排循环、经 Gateway 暴露为 MCP 工具的 action groups、Gateway 前置的知识库集成、inline function tools（return-of-control / human-in-the-loop）、Code Interpreter 沙箱执行、短/长期记忆、经 Gateway 的 Guardrail 强制、端到端持久追踪、系统提示配置 \^17。

若需超出声明式模型的能力（阶段级 prompt 覆盖、多 Agent 协作、自定义编排循环），则走 code-defined agents on AgentCore------直接在 Runtime 上部署任意框架（Strands / LangChain / OpenAI Agents SDK / Claude Agent SDK / 自定义）的自定义编排代码 \^17。

Harness = 平台自带的极简"框架"。它既属平台层（托管循环、microVM），又跨界承担了框架层的编排职责------相当于 AgentCore 内置了一个声明式框架，让你"不引入外部框架"也能写 Agent ^2^17。

一次典型请求的数据流（以 Harness 为例）

  1. 客户端发起会话请求 → Runtime 分配一个专属 microVM（隔离 CPU/内存/文件系统）\^5。
  2. Harness 载入声明的"模型 + 系统提示 + 工具"，启动托管编排循环 ^2^17。
  3. 需要历史上下文 → 调 Memory：list_events（近期轮次）+ retrieve_memories（命名空间语义查询）\^9。
  4. 需要调用外部能力 → 经 Gateway 以 MCP 调用工具；调用前 Policy 用 Cedar 规则拦截校验；跨系统身份由 Identity 委托授权 \^2。
  5. 需要执行代码/操作网页 → 进 Code Interpreter 沙箱 / Browser 运行时 \^2。
  6. 模型推理走 Nova/Claude/...；每一步以 OTEL 格式发往 Observability/CloudWatch \^2。
  7. 交互经 create_event 落入 Memory（自动应用长期记忆策略）\^9。
  8. 会话结束 → microVM 终止、内存清零 \^5。事后可用 Evaluations 评估、Optimization 迭代改进 \^2。
相关推荐
企业数字化笔记1 小时前
视频成片怎么稳定导出？编码选择、GPU/CPU降级与媒体交付验收
java·python·ffmpeg
Dawson Zhu1 小时前
几何深度学习：原理解析与工程实践
人工智能·语言模型·架构·aigc·agi
AI你一生一世1 小时前
当广告采集器成为大模型的“眼睛“：跨站上下文注入的架构与代价
人工智能·架构·大模型·rag·隐私安全·上下文注入·跨站追踪
狗凯之家源码网2 小时前
网址导航系统源码评测：个性 UI 与轻量化架构实战
ui·架构·网址导航系统
Wx-bishekaifayuan2 小时前
springboot房屋租赁系统11574-计算机课程设计、毕业设计
java·vue.js·spring boot·后端·sql·spring·课程设计
海宇AI2 小时前
零信任架构实战：基于海宇车辆估值构建自动化二手车收车测算网关
运维·人工智能·架构·自动化
三8442 小时前
Fastjson 漏洞学习笔记 · 03 · 经典利用链：TemplatesImpl 与 JdbcRowSetImpl
java·web安全·fastjson
青山木2 小时前
秒杀系统设计（二）：数据正确性——防超卖、分布式锁与一人一单
分布式·后端·mysql·中间件·架构
海宇服务2 小时前
零信任架构实战：基于海宇车辆估值构建自动化车队残值重估网关
运维·人工智能·架构·自动化
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04Telegram APK 下载安装完整指南 — 2026年最新05蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接06微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新072026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享08给AI一张“业务概念地图“：本体如何从哲学走向企业智能092026 年 9 月国内外主流大模型横向硬核评测：价格、算力、业务场景全维度对比，GPT‑6 Astra横空出世10jev-ultrafast 深度解析：7 秒订机票的浏览器 Agent 是如何炼成的