---

6 月 23 日，亚马逊云科技在中国峰会上正式发布了《企业生产级智能体开发指南白皮书》。白皮书的核心不是讲"怎么用模型"，而是讲**"怎么把 Agent 管住"**——这恰好是大多数团队真正卡住的地方。

---

是什么

白皮书提出了一个核心概念：Agentic AI 爆发的拐点已经到来。

这个拐点有两个驱动力同时发生：

• 模型能力在持续突破（推理、代码生成、多模态）
• 工程体系在快速成熟（Prompt Engineering → Context Engineering → Harness Engineering）

前两个概念大家已经不陌生，第三个"驾驭工程（Harness Engineering）"才是白皮书真正想强调的东西——怎么通过工程手段，让 Agent 在生产环境里可靠、可控、可衡量，而不是靠人盯着跑。

白皮书还给出了一个五层技术栈地图：

层级	说明	代表服务
AI 基础设施	GPU/TPU 算力	Trainium、SageMaker AI
模型层	统一访问各类大模型	Amazon Bedrock
数据和知识层	让企业数据变成 AI 可用的知识	Bedrock Knowledge Bases、S3 Vectors
Agentic 平台层	Agent 全生命周期管理	Bedrock AgentCore（核心新服务）
Agent 应用层	开箱即用的垂直场景 Agent	Kiro、Amazon Q 等

---

为什么

白皮书指出了一个本质问题：Agent 和传统软件有根本区别，传统的工程方法不够用了。

具体体现在三个维度：

1. Agent 会推理，不只是响应

单个用户请求可能触发多次 LLM 调用、多次工具调用、记忆检索、跨 Agent 通信。每次都带来延迟、成本和新的失败面。传统的"请求-响应"优化思路，根本应对不了 Agent 的迭代推理循环。

2. Agent 行为是随机的

LLM 驱动的决策本质上是非确定性的——同样的输入可能产生不同的输出。可靠性策略必须通过行为监控、评估框架和优雅降级来应对，而不是靠传统测试。

3. Agent 会失控

Agent 调用工具、修改数据、与外部系统交互，每一步不需要人类明确指令。这意味着它可能烧掉大量 token（死循环），可能调用错误的工具，可能产生不在预期范围内的行为。

企业现在面临的已经不是"能不能做 Agent"的问题，而是"能不能让 Agent 稳定、可靠、低成本地跑在生产环境里"。

---

怎么做

白皮书给出了两套实操框架。

框架一：评估驱动的 Agent 开发生命周期

这不是一个线性流程，而是一个循环：

定标准 → 开发实现 → 效果评估 → 上线 → 持续监控 → 改进循环

每个环节的核心动作：

• 定标准：定义 Agent 角色、成功标准、工具边界
• 开发实现：原子化任务设计、最小权限指令、输入输出验证
• 效果评估：建立 Ground Truth 数据集，LLM-as-Judge 自动化评估（白皮书配套开源了评估集代码）
• 上线：IaC 自动化部署，Agent 版本和别名管理
• 持续监控：全链路追踪（模型调用 → 向量检索 → 应用 → 用户反馈）
• 改进循环：量化 ROI，持续优化认知管道

这套方法论的核心洞察是：先有评估标准，再有开发迭代。没有基线评估，Agent 改到什么时候算改好了都不知道。

框架二：Agent 运维全流程（5 阶段）

AWS 的 AI Agents Operational Framework 提供了从 0 到 1 的完整运营路径：

阶段	关键动作
Prepare	评估业务需求是否真的需要 Agent；制定成本控制策略；设计容灾架构
Build	超时重试防死循环；Agent Memory 会话持久化；OpenAPI Schema 结构化工具定义；HITL 人工确认
Deploy	IaC 自动化（CDK/Terraform）；CI/CD 流水线；版本和别名管理
Operate	全链路追踪；CloudWatch 统一仪表盘；Guardrails 过滤有害内容
Evolve	Ground Truth 数据集积累；新模型评估；Token 压缩优化

框架选型参考

白皮书对主流 Agent 框架做了横向对比：

框架	特点	适用场景
Strands Agents	AWS 开源，Model-first，多 Agent 原生支持（MCP + A2A）	AWS 原生项目，企业级安全和合规需求
LangGraph	生态最成熟，状态机编排灵活	快速原型，多模型实验，深度定制
CrewAI	角色驱动，强调任务分工与 Agent 间协作	多角色协作场景
AutoGen	微软出品，对话式协作，支持人工参与循环	对话密集型场景

对于不想维护基础设施的团队，白皮书还推荐了 AgentCore Harness（2026 年 4 月发布预览版）——AWS 提供完整的 Agent 运行时，只需调用 API 描述指令和工具，AWS 负责跑完整循环。

Agent 治理的四个关键机制

1. 身份体系：每个 Agent 有独立认证身份，清晰授权边界
2. 权限边界（Bounded Autonomy）：Agent 只在明确定义的范围边界内运行，超出必须升级
3. 可追溯性：每次决策、调用、交互都有日志记录，支持审计回放
4. 分级人工监督（HITL）：低风险自动执行，中风险确认后执行，高风险必须人工审批

---

Java 开发者：Spring AI 能对上哪些能力

这份白皮书里的框架示例基本是 Python 生态（Strands Agents、LangGraph、CrewAI），Java 开发者看完可能会想——Spring AI 在 Agent 方向有什么能对上的？

如果把白皮书的核心能力拆解开来，Spring AI 其实能覆盖不少：

白皮书对应能力	Spring AI 对应实现	现状
工具调用（Tool Calling）	@Tool 注解 + FunctionCallbackWrapper	✅ 成熟，和 MCP 协议天然对接
记忆管理（Memory）	ChatMemory 接口 + TokenWindowMemory	✅ 成熟，支持多会话和向量检索
多模型接入	ChatModel 接口统一抽象（Bedrock / OpenAI / Azure / 本地模型）	✅ 成熟，切换模型基本不改业务代码
RAG 检索增强	VectorStore + RetrievalAugmentedProvider	✅ 成熟，支持 PGVector、Milvus、Elasticsearch 等
MCP 协议支持	Spring AI 2.0 集成 MCP SDK 2.0	⚠️ 新支持，生态还在建立中
提示词模板	PromptTemplate + ChatOptions	✅ 成熟，支持结构化和参数化
可观测性	Micrometer 集成，埋点监控	✅ 成熟，Spring 生态标配
Agent 抽象层	SimpleChatAgent、ConversationalAgent	⚠️ 基础，高级编排需自己封装
评估框架	Advent of AI 项目（spring-ai-advent）	⚠️ 在建中，参考 LangChain 的评估思路

Spring AI 目前真正短板的地方：

• 多 Agent 协作的编排能力（Graph、Swarm 这类模式需要自己实现状态机）
• 评估驱动的开发流程（目前没有开箱即用的评估框架）
• Agent 生命周期管理的上层抽象

Spring AI 的定位更像是"Agent 开发的基础设施"，而不是"开箱即用的 Agent 框架"。白皮书强调的"驾驭工程"在 Spring AI 侧是有完整基础的——完全可以在 Spring AI 上构建自己的编排层和评估层，用 Java 写一个类似 LangGraph 的状态机，这在工程上是完全可行的。

---

相关阅读：

• AWS Well-Architected Agentic AI Lens
• AWS Prescriptive Guidance - Agentic AI Frameworks
• AWS AI Agents Operational Framework