用 Amazon Bedrock 与 Spring AI 构建自主 AI 智能体

#用 Amazon Bedrock 与 Spring AI 构建自主 AI 智能体

Java 团队已经有成熟的 JVM 工具链、持续集成与持续交付（CI/CD）流水线以及运维模式，但把 AI 智能体（AI agent）从原型做到生产仍然困难：智能体框架默认并不解决可扩展性、治理、安全与运维问题。Amazon Bedrock 与 Spring AI 补上这些缺口，使 Java 团队能够构建可以规划、调用工具和 API、并在多轮对话中保持上下文的自主 AI 智能体。智能体式 AI（Agentic AI）正在从提示—回答交互，转向能够执行复杂多步骤任务的自主系统。

Java 仍是企业软件中广泛使用的编程语言之一。团队已有围绕 JVM 建立的 CI/CD 流水线、运维经验和既有模式。Spring AI 通过熟悉的 Spring 模式把 AI 能力带到 JVM：自动配置、依赖注入以及可组合的顾问（advisor）。开发者可以用构建 REST API、安全与数据访问时相同的写法来构建 AI 智能体。

Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，不限定框架或模型。借助 AgentCore，你可以大规模构建、部署和运行 AI 智能体。它与框架无关、与模型无关：你带来自己偏好的智能体框架和基础模型（foundation model，FM）。借助 AgentCore，你可以获得生产所需的基础设施：托管运行时、记忆、浏览器自动化、代码执行和身份管理。

本文说明如何使用 Spring AI、Amazon Bedrock 以及 spring-ai-agentcore，用 Java 构建自主 AI 智能体。我们考察两套系统的关键实现模式。第一套是单智能体旅行助手，演示工具调用与记忆。第二套是多智能体智能文档处理（intelligent document processing，IDP）系统，展示专长智能体、规则引擎和告警如何协同。

前置条件

要跟随本演练，你需要：

• Java – JDK 21（必需）
• Spring Boot – 4.1（搭配 Spring AI 2.0 与 spring-ai-agentcore 2.0）
• Maven – 3.9+。
• Node.js – 18+（用于 React 前端）
• Terraform – 1.5+。
• Docker – 带 Buildx，用于多架构构建。
• AWS Command Line Interface（AWS CLI） – v2，并已配置凭证。
• 一个 AWS 账户。

什么使系统成为智能体

一次聊天补全调用可以生成文本，但不能决定下一步做什么、触及外部系统，或记住昨天发生了什么。智能体可以，因为它把三种能力合在一起：

• 规划（Planning） – 给定目标后，模型将其拆成步骤、排定优先级，并在新信息到来时修订计划。
• 工具使用（Tool use） – 除生成文本外，模型还可以选择并调用外部函数，例如 API、数据库和代码解释器，从而在现实世界中行动。
• 记忆（Memory） – 上下文跨轮次延续（短期），也跨会话延续（长期），因此每一次决策都建立在此前发生的事情之上。

检索增强生成（Retrieval Augmented Generation，RAG）应用只有有限的工具使用（检索），没有规划循环。智能体三者兼备，在目标导向的循环中运行，直到任务完成，或它判定无法继续。

下图展示这些能力如何出现在端到端智能体流水线中，从请求到有依据的回答。

图 1：智能体参考架构。请求经过运行时、护栏、分类、专长智能体、工具、基础模型、记忆、规则和人工复核，到达有依据的回答；韧性与可观测性是横切关注点

该流水线有 11 个阶段。客户端提交文档和问题。请求经过运行时网关做身份认证与速率限制，然后输入护栏筛查有害内容。路由器对文档分类，并路由到专长智能体；专长智能体规划工作流，并按需调用工具、Amazon Bedrock 基础模型、记忆和规则引擎。低置信度或被标记的结果进入人工复核队列，然后有依据的回答返回客户端。韧性、可观测性、日志，以及最小权限的 AWS Identity and Access Management（IAM）适用于全部阶段。

方案概览

该方案由两套可部署系统组成，它们共享通用模式：

• 旅行智能体（Travel agent） – 单个自主智能体，具备工具调用（天气查询、行程搜索）、流式响应、对话记忆和韧性模式。这是建议的起点。
• IDP 多智能体系统 – 多智能体智能文档处理平台，包含五个专长智能体（Lawyer、Mortgage、Insurance、Tax、General）、规则与工作流引擎、告警和可观测性。它演示规模化的生产模式。

两套系统共享以下架构：

• 使用 Spring AI ChatClient、Spring AI agentcore 和 Amazon Bedrock Converse API 的 Spring Boot 应用。
• AgentCore runtime 是 Amazon Bedrock AgentCore 的一项能力，为托管部署定义契约（POST /invocations，GET /ping）。
• 通过 AgentCore memory（Amazon Bedrock AgentCore 的一项能力）提供对话记忆，同时覆盖短期与长期上下文。
• 使用带 @Tool 注解的方法进行工具调用。
• 结构化输出映射到 Java record。
• 针对 AWS Graviton 优化的 ARM64 容器镜像。
• 用于基础设施供给的模块化 Terraform。

旅行助手是建议的起点。下图说明 Spring Boot 智能体如何与 AgentCore runtime、工具、记忆以及 Amazon Bedrock 上可用的模型交互。

图 2：单智能体旅行助手。Spring Boot 应用同时暴露给 React UI 的 REST 端点，以及 AgentCore runtime 契约；它通过 Converse API 调用 Amazon Bedrock，而工具调用、流式传输和记忆在同一代码库内运行。

旅行助手运行单个 Spring Boot 应用，有两个入口，即 AgentCore runtime 要求的 /invocations 与 /ping 契约。Spring AI 通过 Converse API 编排对 Amazon Bedrock 的调用，并在同一进程内本地解析工具调用。服务器发送事件（Server-Sent Events）在令牌生成时将其流式发给客户端。AgentCore memory 同时提供会话内的短期上下文和跨会话的长期上下文，因此智能体保留对话历史，而无需外部状态管理。

下图展示 IDP 多智能体系统的架构。

图 3：IDP 多智能体系统架构。专长智能体通过共享的 ChatClient 模式处理文档，结果流经规则引擎和告警服务。

IDP 多智能体系统把文档路由到五个专长智能体（Lawyer、Mortgage、Insurance、Tax 和 General），每个都建立在共享的 AbstractDocumentAgent 模板上。ClassifierAgent 读取每份文档，并转发给合适的专长智能体。专长智能体使用 Amazon Bedrock 的多模态 Converse API，提取带置信度分数的结构化 JSON。规则引擎根据抽取结果，评估来自 application.yml 的 Spring Expression Language（SpEL）表达式。严重级别为 ALERT 或 BLOCK 的规则通过 AlertService 分发。低置信度文档进入人工复核。指标、审计轨迹、韧性和可观测性适用于全部阶段。

智能体协作模式

多个智能体一起工作时，它们如何协调决定了系统行为。本方案使用三种模式：

下图比较本方案使用的三种协调模式。

图 4：智能体协作模式

三种模式并排展示。路由器按文档类型把每个请求分发给一个专长智能体。评估器把专长智能体的发现交给规则引擎，规则引擎按严重级别处理，并分发告警或拦截以供人工复核。并行扇出把一个请求同时发给多个专长智能体，并在规则引擎运行前聚合结果。

路由器模式（Router pattern）： 一个轻量编排器检查传入请求，并路由到合适的专长智能体。在 IDP 多智能体系统中，路由器检查文档类型元数据，并转发到 Lawyer、Mortgage、Insurance、Tax 或 General 智能体。路由器不持有领域逻辑。它只是分发层。

并行扇出（Parallel fan-out，可选扩展）： 基础方案实现了路由器和评估器模式。批处理端点按顺序处理文档。当一份文档需要同时获得多种视角时，你可以加入并行扇出作为即插扩展。并发分发给专长智能体，并在规则引擎运行前聚合其结果。合并分析的墙上时钟时间于是受最慢的单次智能体调用限制，而不是所有调用之和。

评估器模式（Evaluator pattern）：专长智能体返回发现后，规则引擎对照可配置的业务规则评估合并输出。触发 ALERT 或 BLOCK 严重级别的规则，通过可插拔的 AlertService 分发以供人工复核。

演练

以下各节带你走过关键实现模式，从 AgentCore runtime 契约开始，再依次经过工具调用、记忆、韧性和多智能体编排。

满足 AgentCore runtime 契约

Amazon Bedrock AgentCore runtime 管理智能体生命周期与扩缩。当前费率见 Amazon Bedrock AgentCore 定价与 Amazon Bedrock 定价。运行时把传入请求路由到你的智能体，并监控其健康状况。你的智能体必须暴露两个端点：

• POST /invocations – 接收请求，并以 JSON 或服务器发送事件（Server-Sent Events，SSE）流返回响应。
• GET /ping – 报告健康状态（Healthy 或 HealthyBusy）。长时间运行的任务必须发出忙碌状态，否则运行时可能会缩减该智能体。

下图展示 Spring AI 开发者模型如何映射到 AgentCore runtime、Memory、Browser、Code Interpreter 和 Evaluations。

图 5：Amazon Bedrock AgentCore 上的 Spring AI AgentCore SDK。注解、ChatClient、工具回调和顾问经 spring-ai-agentcore SDK 映射到 AgentCore runtime、AgentCore memory、AgentCore Browser、AgentCore Code Interpreter 和 AgentCore Evaluations。

两层由 spring-ai-agentcore SDK 连接。应用层使用 Spring AI 组件：用于端点接线的 @AgentCoreInvocation、用于模型交互的 ChatClient、@Tool 回调，以及用于记忆和护栏的顾问。基础设施层提供 AgentCore runtime、AgentCore memory、AgentCore Browser、AgentCore Code Interpreter 和 AgentCore Evaluations，这些都是 Amazon Bedrock AgentCore 的能力。SDK 连接两者，因此开发者编写标准 Spring AI 代码，而 AgentCore 负责生产基础设施。

使用 Spring AI AgentCore SDK 时，一个注解会自动处理该契约：

@Service
public class TravelAgent {
    private final ChatClient chatClient;

    public TravelAgent(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @AgentCoreInvocation
    public Flux<String> chat(PromptRequest request) {
        return chatClient.prompt()
                .user(request.prompt())
                .stream()
                .content();
    }
}

Java

@AgentCoreInvocation 注解自动配置 /invocations 与 /ping 端点，处理 JSON 序列化，管理流式响应的 SSE 分帧，并报告健康状态。同一项目也为 React UI 暴露 REST 端点，因此智能体从同一代码库同时服务 AgentCore runtime 和浏览器。

关于流式传输的说明：前面的最小示例直接返回模型流，这对聊天 UI 很合适。当智能体进行多参数工具调用时，先用阻塞的 call() 组装响应，再把结果分块用于流式传输，这样工具参数才能可靠绑定。旅行助手用同一个服务方法同时服务 AgentCore runtime 和 React UI：

@RestController
public class AgentController {
    private final AgentService agentService;

    public AgentController(AgentService agentService) {
        this.agentService = agentService;
    }

    // One annotation wires up POST /invocations + GET /ping, JSON/SSE framing, and health.
    @AgentCoreInvocation
    public Flux<String> invoke(PromptRequest request, AgentCoreContext context) {
        String sessionId = context.getHeader(AgentCoreHeaders.SESSION_ID);
        return agentService.streamChat(request.prompt(), sessionId,
                request.guardrailsEnabled(), request.memoryEnabled());
    }

    // The same app also serves the React UI from the same code base.
    @PostMapping(value = "/api/chat", produces = MediaType.TEXT_PLAIN_VALUE + ";charset=UTF-8")
    public Flux<String> chatStream(@Valid @RequestBody PromptRequest request) {
        return agentService.streamChat(request.prompt(), request.sessionId(),
                request.guardrailsEnabled(), request.memoryEnabled());
    }
}

Java

实现工具调用

有了工具调用，模型可以在推理过程中调用外部函数。在 Spring AI 中，你用 @Tool 注解一个方法，由模型决定何时调用以及使用什么参数：

@Tool(description = "Get a short weather forecast for a city")
public String getWeather(
        @ToolParam(description = "City name") String city) {
    return forecastService.lookup(city);
}

Java

你在 ChatClient 上注册工具，由模型决定何时调用它们：

ChatClient chatClient = chatClientBuilder
        .defaultSystem(properties.getSystemPrompt())
        .defaultTools(new DateTimeTools(), new TravelTools())
        .build();

Java

对于结构化输出，请求一个 Java record 类型。对于多模态输入，把媒体附加到用户消息：

ProcessedDocument review = chatClient.prompt()
        .system(personaSystemPrompt)
        .user(u -> u.text(question).media(mimeType, fileResource))
        .call()
        .entity(ProcessedDocument.class);

Java

说明： 我们用 Amazon Bedrock 上的 Anthropic Claude Sonnet 4.5 验证了该示例。Spring AI 把 record 的模式加入提示，并把回复解析回 Java 类型。其他模型家族的行为可能不同，因此请参阅 Spring AI 结构化输出文档和 Amazon Bedrock 文档以了解当前支持情况。这是尽力而为，意味着模型偶尔会返回与模式不匹配的输出。若要更严格的结果，使用具备原生模式强制的提供方，或使用 Spring AI 的校验与重试。

模型把工具定义作为上下文的一部分接收，推理何时一次工具调用有助于满足用户请求，并返回结构化的工具调用响应。Spring AI 拦截该响应，调用被注解的方法，并把结果送回模型以继续推理。

添加对话记忆

真实世界的智能体必须记住用户在一次对话中较早说过的话（工作记忆），以及它们随时间学到的内容（持久记忆）。Spring AI AgentCore SDK 通过顾问模式与 AgentCore memory 集成：这些拦截器在提示到达模型之前用上下文丰富提示。

chatClient.prompt()
        .advisors(agentCoreMemory.advisors)
        .advisors(a -> a.param(
                ChatMemory.CONVERSATION_ID, "user:" + sessionId))
        .user(prompt)
        .stream()
        .content();

Java

会话 ID 变成 actor:session 形式的对话 ID，因此每个用户的历史保持隔离。对于面向用户的部署，应从已验证的 OAuth 2.0（JWT）身份派生 actor，而不是使用客户端提供的值，这样用户就不能访问彼此的历史。

此外，AgentCore memory 提供长期记忆支持，采用以下策略从对话中识别并捕获关键洞察：

• 语义（Semantic） – 关于用户的事实信息（例如，“User works in finance”）
• 用户偏好（User preference） – 明确的设置与选择（例如，“Metric units preferred”）
• 摘要（Summary） – 压缩后的对话历史，用于跨会话的连续性。
• 情节（Episodic） – 过去的交互以及学到的经验。

长期记忆抽取是异步且可选的。你在创建记忆时选择启用哪些策略，AgentCore 在每次对话之后于后台抽取并合并记录，因此它从不阻塞智能体的响应。按工作负载选择策略：旅行助手使用用户偏好，以便记住单位和座位选择。会话跨很多轮时使用摘要。智能体应复用过去任务的经验时使用情节。要保留关于用户的持久事实时使用语义。

配置规则引擎

阅读文档只是工作的一半。根据它发现的内容采取行动是另一半。IDP 多智能体系统包含一个规则引擎，使运维人员可以添加业务检查而无需改动代码。这是一个进程内规则评估器，把 SpEL 条件应用到抽取结果，而不是 AWS Step Functions 这类工作流编排服务。规则位于 application.yml，每个条件都是针对抽取结果求值的 SpEL 表达式：

idp:
  review:
    enabled: ${REVIEW_ENABLED:true}
    confidence-threshold: ${REVIEW_CONFIDENCE_THRESHOLD:0.7}
    rules:
      - id: legal-unsigned
        agentType: LAWYER
        condition: "field('signaturePresent') == 'false' || missing('signaturePresent')"
        severity: ALERT
        message: "Document appears unsigned; get all parties to sign before relying on it."
      - id: mortgage-high-dti
        agentType: MORTGAGE
        condition: "field('dtiRatio') != '' && T(java.lang.Double).parseDouble(field('dtiRatio')) > 0.43"
        severity: WARN
        message: "Debt-to-income ratio exceeds 0.43; likely needs manual underwriting."
      - id: low-confidence
        agentType: ALL
        condition: "confidence < 0.6"
        severity: WARN
        message: "Low extraction confidence; consider human verification."

YAML

严重级别控制引擎行为。INFO 和 WARN 会被记录，而 ALERT 通过可插拔的 AlertService 分发。默认实现记录日志并发出指标，但你可以提供自己的 bean，替换为 Amazon Simple Notification Service（Amazon SNS）、Slack 或电子邮件。BLOCK 把文档留待人工复核。因为规则是运维人员配置而不是终端用户输入，它们提供安全且可审计的扩展点。添加新工作流是配置变更，不是一次部署。

评估器模式由规则引擎和可插拔的 AlertService 实现。默认实现记录告警并发出指标。你提供自己的 bean，以路由到 Amazon SNS、Slack 或电子邮件：

public class LoggingAlertService implements AlertService {
    @Override
    public void send(RuleResult result, AgentType agentType, ProcessedDocument document) {
        registry.counter("idp.alerts.sent",
                "severity", result.severity().name(), "type", agentType.name()).increment();
        logger.warn("ALERT [{}] rule={} type={} message=\"{}\"",
                result.severity(), result.ruleId(), agentType, result.message());
    }
}

Java

生产就绪模式

以下模式处理原型通常会跳过的常见生产要求。

韧性

每次模型调用都使用带指数退避的 Resilience4j 重试、在模型调用反复失败或超时时快速失败的断路器，以及超时。流式路径发出回退消息，而不是原始错误。当流量超过你的账户和区域服务配额时，AgentCore runtime 返回 HTTP 429，由重试处理。当前限制见 Amazon Bedrock AgentCore quotas documentation。

十二要素配置

每个可配置值（区域、模型 ID、记忆 ID、超时、速率限制、系统提示）都是绑定到带类型的 @ConfigurationProperties 类的环境变量。应用无状态，启动快，在缩容时排空进行中的轮次，并作为一张不可变的 ARM64 镜像发布，从开发到生产原样晋升。

安全与身份

Agentcore runtime 默认使用 AWS Identity and Access Management（IAM）身份认证。对于面向用户的智能体，增加 OAuth 2.0（JWT）授权方（例如 Amazon Cognito），并从已验证身份派生记忆 actor ID（actorId）。IAM 执行角色遵循最小权限：

• Amazon Elastic Container Registry（Amazon ECR）拉取。
• 限定范围的 Amazon CloudWatch Logs 与 AWS X-Ray。
• Amazon Bedrock InvokeModel 操作。
• 针对该智能体工作负载身份、限定范围的工作负载访问令牌（GetWorkloadAccessTokenForJWT）。
• 仅限于特定 Memory 资源 ARN 的 AgentCore memory 操作。

AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，它强制入站身份认证（作为 OAuth 2.0 资源服务器，通过 Cognito、Okta、Auth0 或你自己的 OIDC 提供方校验 JWT 持有者令牌），并支持在网关层配置速率限制。速率限制默认失败开放（fail-open），因此它们应补充你的核心安全控制，而不是取代它们。

负责任 AI 控制

在现实世界中采取行动的自主智能体，需要把安全控制作为一等关注点。示例附带一个名为 GuardrailService 的轻量进程内预检查的占位演示。该服务筛查提示中不允许的意图和提示注入，并用 guardrailsEnabled 标志按请求开关。生产部署把 Amazon Bedrock Guardrails 用作应用到每个请求的标准控制，而不是按请求开关。

要把演示服务升级到生产，在智能体前面放置 Amazon Bedrock Guardrails。护栏在模型调用之外应用可配置策略，同时覆盖输入和输出：

1. 内容过滤。基于可配置阈值，阻止提示和响应中的有害或离题内容。
2. 拒绝主题。阻止智能体涉入你定义为超出范围的主题。
3. 敏感信息过滤器。检测并脱敏提示和响应中的个人身份信息（PII），以支持 GDPR 和 HIPAA 等要求。

对于检索外部知识的智能体，启用依据性检查，以在智能体根据具有现实副作用的工具调用采取行动之前降低幻觉风险。

要把 Bedrock Guardrails 接入 Spring AI，实现调用 ApplyGuardrail API 的 CallAdvisor 与 StreamAdvisor 函数，并用 ChatClient 上的 defaultAdvisors 注册它。因为策略位于护栏中，安全团队可以独立于应用发布周期更新过滤器。

可观测性

该示例使用 Micrometer Observation API（@Observed）做埋点，产生计时器；当你加入追踪桥（OTLP 到 AWS X-Ray）时，这些计时器成为分布式追踪跨度。系统发出领域指标：

idp.documents.processed{type,status}
idp.extraction.confidence{type}
idp.alerts.sent{severity,type}
idp.processing.duration{type}

纯文本

这些指标通过 /actuator/prometheus 暴露。应用还向标准输出发出结构化 JSON 日志，Amazon Bedrock AgentCore runtime 将其采集到 Amazon CloudWatch Logs。

本文未实现的可选扩展：示例包含 Micrometer OpenTelemetry 桥和 OTLP 导出器依赖，但本文的部署不供给 OpenTelemetry 收集器，也不启用追踪采样。你可以通过设置非零的 TRACING_SAMPLING 值、把 OTLP_TRACES_ENDPOINT 指向 OpenTelemetry 或 AWS Distro for OpenTelemetry 收集器，并配置收集器把追踪转发到 AWS X-Ray，来加入分布式追踪。

本文未实现的可选扩展：示例没有实现自动评估或优化反馈环。你可以通过把应用指标、追踪、审计事件和人工复核结果持久化为评估数据集来加入一个。然后 AgentCore evaluations 或单独的评估流水线可以把带版本的提示、模型、工具和路由规则，与质量、安全、延迟和成本阈值进行比较。仅在评估和人工批准之后晋升变更。

部署该方案

这个 GitHub 仓库 包含两个 AI 智能体应用，演示自主 AI 的不同用例。本指南说明如何使用 Amazon Bedrock AgentCore runtime 把它们部署到 AWS。

下图展示部署架构：一张 Arm64 镜像经模块化 Terraform 晋升到 AgentCore runtime，并有一条可选的 Amazon Elastic Kubernetes Service（Amazon EKS）路径。

可选：在 Amazon EKS 上运行。 已经把 Kubernetes 作为标准的团队，可以在 Amazon EKS 上运行同一张 Arm64 镜像，使用现有集群做扩缩，并对 /ping 端点做健康检查，用 IAM Roles for Service Accounts（IRSA）实现对 Amazon Bedrock 和 AgentCore memory 的、限定范围的、最小权限的 Pod 级访问。容器相同，因此应用中没有任何东西需要改变。

图 6：部署架构。模块化 Terraform 供给 Amazon ECR、最小权限 IAM 执行角色和 Bedrock AgentCore runtime，另有一条可选的 Amazon EKS 与 IRSA 路径复用同一张 Arm64 镜像。

三个阶段：构建并发布、Terraform，以及在 AWS 上运行。CI 流水线把应用打包成 linux/arm64 镜像，并以不可变标签推送到 Amazon ECR。三个 Terraform 模块供给 ECR 仓库、最小权限 IAM 执行角色和 AgentCore runtime。智能体在 AgentCore runtime 上以无服务器方式运行，调用 Amazon Bedrock 和 AgentCore memory。可选的 Amazon EKS 路径用 IRSA 复用同一镜像，以获得限定范围的 Pod 级凭证。

按以下步骤部署任一应用。

步骤 1：克隆仓库

打开终端并运行：

git clone https://github.com/aws-samples/sample-build-autonomous-ai-agents-with-amazon-bedrock-and-spring-ai.git

Bash

步骤 2：进入你要部署的智能体目录

• 部署自主智能体：

cd build-autonomous-ai-agents-with-amazon-bedrock-and-spring-ai/code/autonomous-agent

Bash

• 部署 IDP 多智能体系统：

cd build-autonomous-ai-agents-with-amazon-bedrock-and-spring-ai/code/idp-agent

Bash

步骤 3：配置 Terraform 变量

部署基础设施之前，在 terraform 目录下的 terraform.tfvars 文件中配置 Terraform 变量。

基本配置

该方案对大多数设置使用默认值，但你可以在 terraform.tfvars 文件中自定义以下项：

• AWS 区域：部署资源的 AWS 区域。
• 环境：用于资源命名的环境 ID（例如 dev 或 prod）。
• bedrock_model：Amazon Bedrock 基础模型（例如：global.anthropic.claude-sonnet-4-5-20250929-v1:0）。各区域的模型可用性见 Supported models by AWS Region in Amazon Bedrock。

步骤 4：运行部署脚本

Linux/macOS：

./scripts/deploy.sh dev

Bash

Windows PowerShell：

.\scripts\deploy.ps1 dev

PowerShell

部署脚本做以下事情：

• 创建 Amazon ECR 仓库。
• 构建 Java 应用。
• 创建并推送 Docker 容器镜像。
• 创建 IAM 执行角色。
• 部署 AgentCore runtime。

步骤 5：运行应用

部署完成后，可以用以下命令运行应用。

Linux/macOS：

./scripts/run.sh dev

Bash

Windows PowerShell：

.\scripts\run.ps1 dev

PowerShell

清理

AgentCore runtime 会缩放到零，并按调用计费，因此空闲智能体几乎不产生费用。你的主要可变成本是 Amazon Bedrock 令牌用量，外加少量 Amazon CloudWatch 和 Amazon ECR 存储费用。当前费率见 Amazon Bedrock AgentCore 定价与 Amazon Bedrock 定价。为避免今后产生费用，完成后拆除基础设施：

Linux/macOS：

./scripts/cleanup.sh dev

Bash

Windows PowerShell：

.\scripts\cleanup.ps1 dev

PowerShell

使用 AWS CLI 删除你不再需要的任何 AgentCore memory 资源和 Amazon ECR 镜像。

结论

本文说明了如何使用 Spring AI 和 Amazon Bedrock，用 Java 构建自主 AI 智能体。我们覆盖了把模型变成智能体的三种能力：规划、工具使用和记忆。我们也展示了 Amazon Bedrock AgentCore 服务如何把智能体带到生产。Spring AI AgentCore SDK 通过注解和熟悉的 ChatClient，把这些能力映射到符合 Spring 习惯的写法。最后，我们概述了多智能体协作的架构模式。其中包括路由器模式、由规则引擎实现的评估器模式，以及作为可选扩展的并行扇出。

给 Java 团队的关键结论：你不必离开自己的环境就能构建生产质量的智能体。你已经信任的模式（依赖注入、配置属性、顾问、Actuator、Micrometer）直接进入智能体世界。AgentCore 提供生产所要求的运行时、记忆、身份和治理。

作为后续步骤，考虑以下事项：

• 通过 AgentCore Gateway 和 模型上下文协议（Model Context Protocol，MCP） 连接企业系统
• 加入 Amazon Bedrock Knowledge Bases 这一全托管 RAG 能力，以及网页搜索，使智能体基于你的数据推理。
• 实现 Amazon Cognito JWT 身份认证，并按用户隔离记忆。
• 自定义 Amazon Bedrock Guardrails 策略：增加领域特定的拒绝主题，收紧内容过滤阈值，并启用针对你的知识来源调优的依据性检查。
• 使用 AgentCore Evaluations 为生产追踪评分，并在复核后晋升提示或模型变更。

每一项都是对你在这里建成的基础的增量添加，而不是重写。 PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-autonomous-ai-agents-with-amazon-bedrock-and-spring-ai