Serverless Framework 部署 AWS Bedrock AgentCore：在 serverless.yml 中一键编排 AI 智能体、记忆、工具与网关-迪斯科星球

Serverless Framework 部署 AWS Bedrock AgentCore：在 serverless.yml 中一键编排 AI 智能体、记忆、工具与网关

【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless

本文以 Serverless Framework 内置的 Bedrock AgentCore 插件（源码位于 packages/serverless/lib/plugins/aws/bedrock-agentcore）为核心，系统讲解如何通过新增的ai顶层配置属性，把 AWS Bedrock AgentCore 的 Runtime Agent、Memory、Tools、Gateway、Browser、CodeInterpreter 六类 AI 资源"声明式"地纳入 CloudFormation 部署管线。读完本文，你将掌握从零配置一个带 Docker 镜像/代码部署的 AI 智能体、为其挂接共享记忆与多类工具网关、以及通过自定义 IAM 角色和部署命令把它发布到 AWS 的完整实操路径，同时了解插件在 Serverless Framework 打包/编译阶段的底层实现原理。

插件是什么：功能与加载条件

Bedrock AgentCore 插件是 Serverless Framework 内部（AWS provider 侧）的一个生命周期插件，作用是把serverless.yml中新增的ai顶级配置编译为一整套 AWS Bedrock AgentCore 云资源，并自动补齐 IAM 角色、标签、命名与 CloudFormation 输出。其核心能力包括：

在serverless.yml中用ai顶层属性直接定义 AgentCore 资源；
支持六类资源类型：Runtime Agents（ai.agents）、Memory（ai.memory）、Tools（ai.tools）、Gateways（ai.gateways）、Browsers（ai.browsers）、CodeInterpreters（ai.codeInterpreters）；
自动生成遵循最小权限原则的 IAM 角色；
自动套用命名约定与标签合并规则；
为每种资源生成可用于跨栈引用的 CloudFormation 输出。

插件按需加载：在插件主入口 index.js 中，静态方法shouldLoad检查配置对象里是否存在非空的ai字段——没有ai配置的普通服务不会引入该插件的任何开销。ai配置可以从service.ai、initialServerlessConfig.ai或configurationInput.ai三处任一位置读取（见 index.js）。

快速开始：最小可用配置

最简用法只需一个ai.agents定义，前提是服务目录中存在 Dockerfile（构建上下文默认是当前目录.）：

service: my-agent provider: name: aws region: us-east-1 ai: agents: myAgent: description: My AI agent artifact: image: path: . file: Dockerfile protocol: http network: mode: public

执行sls deploy后，插件会依次完成配置校验、本地构建 Docker 镜像、把资源写入 CloudFormation、部署前推送镜像到 ECR，并在部署成功后打印 Runtime ARN、调用 URL 等信息。

ai 配置总览：六个独立分区，无 type 判别字段

与很多资源插件"一个对象加 type 字段"的做法不同，AgentCore 插件为每种资源单独开辟一个分区，类型由"所在的顶级键"决定：

ai: agents: # Runtime agent definitions memory: # Shared memory definitions tools: # Tool definitions (Lambda, OpenAPI, Smithy, MCP) gateways: # Gateway definitions with tool assignments browsers: # Custom browser definitions codeInterpreters: # Custom code interpreter definitions

从源码的编译编排看，这一结构在 compilation/orchestrator.js 中被按"多次遍历"的方式消费：先编译 gateways 及其工具，再依次编译共享 memory、browsers、codeInterpreters，最后才编译运行时 agent，并把 gateway 与 memory 的引用注入到 agent 上。

Runtime Agents（`ai.agents`）：容器化与纯代码两种部署形态

Runtime Agent 是承载智能体逻辑的运行资源，支持以"容器服务"或"Python 代码包"两种方式发布。

Docker 构建部署

框架会自动探测当前目录下的Dockerfile，因此最简单的配置可以是一个空对象：

ai: agents: chatbot: {}

显式指定镜像构建参数、网络、鉴权与生命周期配置的完整形态：

ai: agents: myAgent: description: My AI agent artifact: image: path: . file: Dockerfile repository: my-agent buildArgs: NODE_ENV: production protocol: http network: mode: public authorizer: type: custom_jwt jwt: discoveryUrl: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxx/.well-known/openid-configuration allowedAudience: - my-client-id requestHeaders: allowlist: - X-User-Id - X-Session-Id - Authorization lifecycle: idleRuntimeSessionTimeout: 900 maxLifetime: 28800

镜像构建走本地 Docker、不触发任何 AWS 操作（挂载于before:package:createDeploymentArtifacts阶段），真正推送到 ECR 发生在部署前的before:deploy:deploy钩子——这两个阶段分别由 index.js 中的buildDockerImages()与pushDockerImages()驱动。

使用已构建好的镜像

如果镜像已经存在于 ECR，直接给出完整 URI 字符串即可：

ai: agents: myAgent: artifact: image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-agent:latest

Python 纯代码部署（免 Docker）

对 Python 智能体可以跳过镜像构建，直接声明入口文件与运行时：

ai: agents: myAgent: handler: agent.py runtime: python3.13

也可以把代码制品放到自定义 S3 位置，由框架在打包阶段上传后引用：

ai: agents: myAgent: handler: agent.py runtime: python3.12 artifact: s3: bucket: my-bucket key: agent.zip

配置校验允许的 Python 运行时来自 validators/schema.js 中的单一事实源SUPPORTED_AGENT_RUNTIMES，该数组覆盖python3.10到python3.14（README 的属性表列到python3.13，schema 层实际还放行了python3.14，两处不一致时以编译产物为准）。handler会被编译为entryPoint、运行时会被映射为PYTHON_3_12这类 CFN 枚举，归一化逻辑位于 orchestrator.js。

Runtime Agent 属性总表

Property	Required	Description
`description`	No	Agent description (max 1200 chars)
`artifact.image`	No	Container image URI (string) or build config (object)
`artifact.image.path`	No	Docker build context path (default:`.`)
`artifact.image.file`	No	Dockerfile name (default:`Dockerfile`)
`artifact.image.repository`	No	ECR repository name
`artifact.image.buildArgs`	No	Docker build arguments (key-value pairs)
`artifact.s3.bucket`	No	S3 bucket for code artifact
`artifact.s3.key`	No	S3 key for code artifact
`handler`	No	Python entry point file (e.g.,`agent.py`)
`runtime`	No	`python3.10`,`python3.11`,`python3.12`, or`python3.13`
`protocol`	No	`http`,`mcp`, or`a2a`
`network.mode`	No	`public`or`vpc`
`network.subnets`	No	VPC subnet IDs (required for vpc mode)
`network.securityGroups`	No	VPC security group IDs (required for vpc mode)
`authorizer`	No	String (`none`,`custom_jwt`) or object with`type`and`jwt`
`authorizer.jwt.discoveryUrl`	No	OIDC discovery URL (*required for custom_jwt)
`authorizer.jwt.allowedAudience`	No	Array of allowed audience values
`authorizer.jwt.allowedClients`	No	Array of allowed client IDs
`lifecycle.idleRuntimeSessionTimeout`	No	Session idle timeout in seconds (60-28800)
`lifecycle.maxLifetime`	No	Max session lifetime in seconds (60-28800)
`requestHeaders.allowlist`	No	Headers to forward to runtime (max 20)
`memory`	No	Inline memory config (object) or reference to`ai.memory`entry (string)
`gateway`	No	Reference to a gateway defined in`ai.gateways`
`environment`	No	Environment variables (same as Lambda)
`package.patterns`	No	File include/exclude patterns for packaging
`package.artifact`	No	Pre-built artifact path
`endpoints`	No	Runtime endpoint definitions
`role`	No	IAM role ARN (string) or customization object
`tags`	No	Resource tags (key-value pairs)

约束要点：artifact.image、handler与自动探测的 Dockerfile 三者必须有其一；省略authorizer时默认使用 IAM 鉴权（详见下文）。

Agent 鉴权配置

authorizer支持字符串简写与对象两种写法：

# String shorthand — no auth authorizer: none # Object form — JWT auth authorizer: type: custom_jwt jwt: discoveryUrl: https://example.com/.well-known/openid-configuration allowedAudience: - my-client-id allowedClients: - my-app-client allowedScopes: - read - write

省略authorizer时默认回落到 IAM 鉴权。编译阶段有一个值得注意的实现细节：authorizer会被先统一为大写形式（aws_iam→AWS_IAM、custom_jwt→CUSTOM_JWT）以兼容 CloudFormation 枚举，见 orchestrator.js 的normalizeAuthorizer。

Memory（`ai.memory`）：带语义检索的记忆底座

Memory 用于保存会话历史并提供语义检索与摘要能力，既可以作为共享资源定义在ai.memory，也可以内联在单个 agent 上。

共享 Memory

ai: memory: conversationMemory: description: Conversation memory with semantic search expiration: 90 strategies: - SemanticMemoryStrategy: Name: ConversationSearch Namespaces: - /conversations/{sessionId} - SummaryMemoryStrategy: Name: SessionSummary Namespaces: - /sessions/{sessionId} - UserPreferenceMemoryStrategy: Name: UserPrefs Namespaces: - /users/{userId}/preferences

Agent 内联 Memory

ai: agents: chatbot: memory: expiration: 30

Memory 属性表

Property	Required	Description
`expiration`	No	Days to retain events (3-365, default: 30)
`strategies`	No	Memory strategies array
`description`	No	Memory description (max 1200 chars)
`encryptionKey`	No	KMS key ARN for encryption
`role`	No	IAM role ARN (string) or customization object
`tags`	No	Resource tags (key-value pairs)

schema校验中expiration的取值范围是 3–365（见 validators/schema.js），与文档表格一致；用户友好的属性名会映射到 CFN 字段，例如expiration → EventExpiryDuration、encryptionKey → EncryptionKeyArn。

Memory 策略类型

SemanticMemoryStrategy- 对会话内容做语义检索：

- SemanticMemoryStrategy: Name: Search Namespaces: - /sessions/{sessionId}

SummaryMemoryStrategy- 对长对话做摘要：

- SummaryMemoryStrategy: Name: Summary Namespaces: - /sessions/{sessionId}

UserPreferenceMemoryStrategy- 追踪用户偏好：

- UserPreferenceMemoryStrategy: Name: Preferences Namespaces: - /users/{userId}

CustomMemoryStrategy- 自定义记忆处理逻辑：

- CustomMemoryStrategy: Name: Custom Configuration: key: value

EpisodicMemoryStrategy- 带反思（reflection）的情景记忆：

- EpisodicMemoryStrategy: Name: Episodes Namespaces: - /episodes/{sessionId} ReflectionConfiguration: enabled: true

内联 Memory 的编译细节

从源码看，agent 上的memory字段如果是字符串则被解析为对ai.memory中共享资源的引用；如果是对象则在编译期自动生成一个名为<agent>-memory的独立 Memory 资源，并让 Runtime 资源通过DependsOn依赖它，见 orchestrator.js。更为实用的是：只要 runtime 关联了 memory，插件会自动往它的环境变量里注入BEDROCK_AGENTCORE_MEMORY_ID（值为Fn::GetAtt解析出的MemoryId），让智能体代码无需手写资源查找即可知道该把会话写进哪块记忆（见 orchestrator.js）。

Tools（`ai.tools`）：四类工具目标

工具是供 agent 通过 gateway 调用的能力单元，共支持四种目标类型，且一次定义恰好需要其中一种。

Lambda 函数工具

把既有 Lambda 函数包装成带 JSON Schema 入参声明的工具：

ai: tools: calculator: function: calculatorFunction toolSchema: - name: calculate description: Perform basic arithmetic inputSchema: type: object properties: expression: type: string description: Arithmetic expression required: - expression functions: calculatorFunction: handler: handlers/calculator.handler runtime: nodejs24.x

OpenAPI 工具

直接引用 OpenAPI 规范文件：

ai: tools: weatherApi: openapi: ./schemas/weather-api.yml

Smithy 工具

引用 Smithy 模型文件：

ai: tools: myService: smithy: ./schemas/service.smithy

MCP Server 工具

指向远端 MCP Server 的 HTTPS 端点：

ai: tools: knowledge: mcp: https://knowledge-mcp.global.api.aws

Tool 属性表

Property	Required	Description
`function`	No	Lambda function name (string) or`{ name, arn }`object
`openapi`	No	OpenAPI schema file path or inline content
`smithy`	No	Smithy model file path or inline content
`mcp`	No	MCP server HTTPS endpoint URL
`toolSchema`	No	Tool schema array (required for`function`tools)
`credentials`	No	Credential provider configuration
`description`	No	Tool description (max 200 chars)

约束要点：function、openapi、smithy、mcp四选一。每个工具最终会被编译成一个GatewayTarget类型的 CloudFormation 资源挂到所属 gateway 之下；同一工具若出现在多个 gateway 中，其逻辑 ID 会自动拼接 gateway 名以避免冲突（见 orchestrator.js）。

Tool 凭据（Credentials）

当工具调用需要访问受保护的外部 API 时，可以声明凭据提供方：

ai: tools: externalApi: function: apiFunction toolSchema: - name: fetch_data description: Fetch external data inputSchema: type: object properties: query: type: string credentials: type: oauth provider: arn:aws:secretsmanager:us-east-1:123456789012:secret:oauth-creds scopes: - read - write grantType: client_credentials

Credential Type	Properties
`gateway_iam_role`(default)	No additional config needed
`oauth`	`provider`(Token Vault ARN),`scopes`,`grantType`,`defaultReturnUrl`,`customParameters`
`api_key`	`location`(`header`or`query_parameter`),`parameterName`,`prefix`

编译编排器会探测 gateway 下是否挂有使用 OAuth/API Key 凭据的工具，进而决定是否把 Token Vault / Workload Identity / Secrets Manager 相关权限条件式地并入 gateway 执行角色（见 orchestrator.js）。

Gateways（`ai.gateways`）：经 MCP 协议向 agent 路由工具

Gateway 通过 MCP 协议把工具路由给 agent。特别地：当定义了ai.tools却没有定义ai.gateways时，插件会自动创建一个默认 gateway 并绑定全部工具（这是向后兼容的自动模式）。

显式多 Gateway 与鉴权隔离

同一批工具可以按暴露面拆到多个 gateway，例如把公开工具与内部工具用不同鉴权策略隔离：

ai: tools: calculator: function: calculatorFunction toolSchema: - name: calculate description: Perform arithmetic inputSchema: type: object properties: expression: type: string required: - expression internalLookup: function: internalLookupFunction toolSchema: - name: lookup_user description: Look up internal user info inputSchema: type: object properties: userId: type: string required: - userId gateways: publicGateway: authorizer: none tools: - calculator privateGateway: authorizer: aws_iam tools: - internalLookup agents: publicAgent: gateway: publicGateway privateAgent: gateway: privateGateway

这里两个 agent 各自通过gateway字段指认 gateway。源码层面，gateway 的逻辑 ID 统一为AgentCoreGateway<资源名>（默认 gateway 是AgentCoreGateway，见 utils/naming.js），agent 只有在"显式指定了 gateway"或"仅有默认 gateway"两种情况下才会被注入 gateway 相关环境变量。

默认 Gateway（自动创建）

定义了工具但没有定义 gateway 时，所有工具会进入自动创建的默认 gateway：

ai: tools: calculator: function: calculatorFunction toolSchema: - name: calculate description: Perform arithmetic inputSchema: type: object properties: expression: type: string agents: chatbot: {}

注意这种模式下 agent 不写gateway字段也能拿到工具的调用入口——插件会在 Runtime 环境变量中注入BEDROCK_AGENTCORE_GATEWAY_URL，值来自默认 gateway 的GatewayUrl属性（见 orchestrator.js）。

Gateway 的 JWT 鉴权与 MCP 协议参数

ai: gateways: secureGateway: authorizer: type: custom_jwt jwt: discoveryUrl: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxx/.well-known/openid-configuration allowedAudience: - my-client-id allowedClients: - my-app-client allowedScopes: - read - write protocol: instructions: Use these tools for external API access searchType: semantic tools: - myTool

Gateway 属性表

Property	Required	Description
`authorizer`	No	String (`none`,`aws_iam`,`custom_jwt`) or object with`type`and`jwt`
`tools`	No	Array of tool names referencing entries in`ai.tools`
`protocol`	No	MCP protocol configuration
`protocol.instructions`	No	Instructions for the agent (max 2048 chars)
`protocol.searchType`	No	`semantic`
`protocol.supportedVersions`	No	Supported MCP versions
`description`	No	Gateway description (max 200 chars)
`role`	No	IAM role ARN (string) or customization object
`kmsKey`	No	KMS key ARN for encryption
`exceptionLevel`	No	`debug`
`tags`	No	Resource tags (key-value pairs)

从编译结果看，gateway 最终被写成AWS::BedrockAgentCore::Gateway类型的 CFN 资源，携带AuthorizerType（枚举CUSTOM_JWT/AWS_IAM/NONE）与ProtocolType: MCP（见 compilers/gateway.js）。

Browsers（`ai.browsers`）：浏览器自动化能力

默认情况下，AWS 托管浏览器会被 agent 自动探测，无需任何配置。只有在需要会话录制、VPC 模式等进阶场景时，才需要显式定义自定义浏览器：

ai: browsers: customBrowser: description: Custom browser with session recording network: mode: public signing: enabled: true recording: enabled: true s3Location: bucket: my-recordings-bucket prefix: browser-sessions/

Property	Required	Description
`network.mode`	No	`public`or`vpc`(default:`public`)
`network.subnets`	No	VPC subnet IDs (required for vpc mode)
`network.securityGroups`	No	VPC security group IDs (required for vpc mode)
`signing.enabled`	No	Enable request signing
`recording.enabled`	No	Enable session recording
`recording.s3Location.bucket`	No	S3 bucket for recordings (*required when recording enabled)
`recording.s3Location.prefix`	No	S3 prefix for recordings (*required when recording enabled)
`description`	No	Browser description (max 1200 chars)
`role`	No	IAM role ARN (string) or customization object
`tags`	No	Resource tags (key-value pairs)

CodeInterpreters（`ai.codeInterpreters`）：沙箱代码执行

默认的 AWS 托管代码解释器（sandbox 模式）同样无需配置；自定义解释器用于需要公网或 VPC 网络模式的场景：

ai: codeInterpreters: publicInterpreter: description: Code interpreter with public internet access network: mode: public

Property	Required	Description
`network.mode`	No	`sandbox`(default),`public`, or`vpc`
`network.subnets`	No	VPC subnet IDs (required for vpc mode)
`network.securityGroups`	No	VPC security group IDs (required for vpc mode)
`description`	No	CodeInterpreter description (max 1200 chars)
`role`	No	IAM role ARN (string) or customization object
`tags`	No	Resource tags (key-value pairs)

IAM 角色定制：既有 ARN、自定义语句与 CloudFormation 内建函数

全部六类资源都支持role定制：要么直接复用已有角色 ARN，要么在自动生成的角色上叠加自定义策略。

复用已有角色 ARN

ai: agents: myAgent: role: arn:aws:iam::123456789012:role/MyCustomRole

定制自动生成的角色

可自定义角色名、追加 IAM 语句、附加托管策略或设置权限边界：

ai: agents: myAgent: role: name: MyAgentRole statements: - Effect: Allow Action: - s3:GetObject Resource: arn:aws:s3:::my-bucket/* managedPolicies: - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess permissionsBoundary: arn:aws:iam::123456789012:policy/MyBoundary tags: Team: AI

role属性还支持 CloudFormation 内建函数，例如在需要引用同一模板中其他自定义角色时：

role: Fn::GetAtt: - MyCustomRole - Arn

实现上的判定规则是：只要role未提供或提供的是"定制对象"（而不是现成 ARN 字符串），插件就会调用 iam/policies.js 中对应的generate*Role生成最小权限角色，并在模板中附加一个<逻辑ID>Role资源及RoleArn输出。注意当 runtime 关联 memory 或 gateway 时，生成的角色会自动携带访问对应 Memory / Gateway 所需权限，权限 ARN 通过 CFNFn::GetAtt构造（见 orchestrator.js）。角色定制对象的 schema（name最长 64 字符、托管策略与权限边界必须是合法 ARN）定义在 validators/schema.js。

常用命令

sls deploy # Deploy to AWS sls dev # Local development with hot reload sls invoke --agent myAgent -d "Hello" # Invoke a deployed agent sls logs --agent myAgent # Fetch agent logs sls package # Generate CloudFormation sls remove # Remove deployed resources

插件通过生命周期钩子把这些命令串起来：initialize时把ai配置同步到service.ai供其他插件使用；before:package:initialize执行配置校验；package:compileEvents到before:package:finalize之间的多个节点调用compileAgentCoreResources（通过resourcesCompiled标志保证只编译一次）；before:deploy:deploy推送镜像；after:deploy:deploy打印部署信息（见 index.js）。

全局配置项

默认标签（Default Tags）

通过custom.agentCore.defaultTags给所有 AgentCore 资源统一打标：

custom: agentCore: defaultTags: Project: MyProject Environment: ${self:provider.stage}

标签合并遵循"资源级覆盖全局级"的顺序，合并与格式化为 CloudFormationTags数组的逻辑在 utils/tags.js 中实现。

VPC 配置

对支持vpc模式的资源统一给出网络参数：

network: mode: vpc subnets: - subnet-12345678 - subnet-87654321 securityGroups: - sg-12345678

注意network.mode: vpc下subnets与securityGroups为必填项（各类资源属性表中均已标注）。

命名约定：不同资源的不同 AWS 命名规则

为了满足 AWS 对不同 AgentCore 资源差异化的命名约束，插件在 utils/naming.js 中维护了一套命名策略：

Resource	Pattern	Separator	Max
Runtime, Memory, Browser, CodeInterp.	`[a-zA-Z][a-zA-Z0-9_]{0,47}`	`_`	48
Gateway, GatewayTarget	`^([0-9a-zA-Z][-]?){1,100}$`	`-`	100
WorkloadIdentity	`[A-Za-z0-9_.-]+`	`-`	255

实际生成的 AWS 资源名遵循service_name_stage（下划线连接、首字母必须是字母、截断到 48 字符）与service-name-stage（连字符连接、截断到 100 字符）两套规则；而 CloudFormation 逻辑 ID 则由 PascalCase 资源名加类型后缀构成，例如music-agent+Runtime→MusicDashagentRuntime。这解释了为什么配置里资源名随意包含-/_，而最终产物总是合法资源。

CloudFormation 输出：开箱即用的跨栈引用

插件会为每类资源自动生成标准命名的 CFN 输出，并且 Runtime、Memory、Gateway、Browser、CodeInterpreter 的 ARN 输出会同时附带Export名称（形如${service}-${stage}-${name}-RuntimeArn），便于跨栈Fn::ImportValue引用：

{Name}RuntimeArn- Runtime ARN
{Name}RuntimeId- Runtime ID
{Name}MemoryArn- Memory ARN
{Name}MemoryId- Memory ID
{Name}GatewayArn- Gateway ARN
{Name}GatewayUrl- Gateway URL
{Name}BrowserArn- Browser ARN
{Name}BrowserId- Browser ID
{Name}CodeInterpreterArn- CodeInterpreter ARN
{Name}CodeInterpreterId- CodeInterpreter ID

额外值得一提的输出是：每个 Runtime 都会生成一个InvocationUrl输出，其值通过Fn::Sub拼装为https://bedrock-agentcore.${Region}.amazonaws.com/runtimes/${RuntimeArn}/invocations（见 orchestrator.js），可直接用于外部集成。

支持的 AWS 区域

AWS Bedrock AgentCore 仅在部分区域开放。部署前请以 AWS 官方文档的最新区域可用性为准；配置里的provider.region需要落到 AgentCore 已开放的区域，否则会在部署阶段报资源类型不可用。

完整示例库

插件自带覆盖 Python 与 JavaScript（LangGraph / Strands）的完整可运行示例，源码位于 examples 目录。

Python 示例：

langgraph-basic-docker - Minimal LangGraph agent with Docker
langgraph-basic-code - LangGraph agent with code deployment
langgraph-gateway - LangGraph agent with custom Lambda tools via Gateway
langgraph-multi-gateway - Multiple gateways with different authorization
langgraph-memory - LangGraph agent with conversation persistence
langgraph-browser - LangGraph agent with browser automation
langgraph-browser-custom - Custom browser with session recording
langgraph-code-interpreter - LangGraph agent with code execution
langgraph-code-interpreter-custom - Custom code interpreter with public network
strands-browser - Strands Agents with browser automation

JavaScript 示例：

langgraph-basic - LangGraph JS agent (no Dockerfile)
langgraph-basic-dockerfile - Minimal LangGraph JS agent with Dockerfile
langgraph-browser - LangGraph JS agent with browser automation
langgraph-browser-custom - Custom browser with session recording
langgraph-code-interpreter - LangGraph JS agent with code execution
langgraph-code-interpreter-custom - Custom code interpreter with public network
langgraph-gateway - LangGraph JS agent with Lambda tools via Gateway
langgraph-memory - LangGraph JS agent with conversation persistence
langgraph-multi-gateway - Multiple gateways with different authorization
mcp-server - JavaScript MCP server
strands-browser - Strands Agents JS with browser automation

以 JS 侧的最小示例 langgraph-basic 为例，它演示了不借助 Dockerfile、通过BedrockAgentCoreApp运行时入口构建 LangGraph 智能体的方式，与 README 中"无 Dockerfile 自动模式"的配置一一对应。

小结

Bedrock AgentCore 插件把 AWS 上零散的 AI 运行时、记忆、工具、网关、浏览器与代码解释器收敛为一个ai声明块，借助 Serverless Framework 既有的打包/编译/部署生命周期完成 Docker 构建推送、资源编译、最小权限 IAM 生成与可跨栈引用的 Output 输出。对开发者而言，掌握ai.agents、ai.memory、ai.tools、ai.gateways、ai.browsers、ai.codeInterpreters这六个分区的字段语义与组合关系（特别是"默认 gateway 自动创建""authorizer 默认 IAM""memory/gateway 引用自动注入环境变量"这三个隐含行为），就能用纯 YAML 快速搭建可复用的生产级 AI Agent 服务，并通过仓库内覆盖 LangGraph/Strands 双技术栈的示例库直接对照落地。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析