AgentCore 上的多智能体

场次笔记

挑战

故障期间的传统工作流

• 检查云资源状态
• 发生故障
• 查看事件历史记录
• 检查配置
• 检查告警
• 分配工单
• 分析日志
• 推测根本原因
• 搜索解决方案
• 检查指标
• 分析依赖关系
• 查看最近的更新
• 搜索调用链
• 查看运维手册
• 查询服务控制面板
• 执行缓解措施
• 通知同事
• 查询异常指标
• 阅读手册
• 监控恢复状态。核心挑战
• 及时减轻损失
• 故障隔离
• 在可接受的时间内解决问题
• 将故障限制在隔离边界内，防止对其他服务产生级联影响，从而缩小故障影响范围
• 确保服务满足用户预期和 SLA

解决方案演进

• 从单智能体解决方案演进到多智能体解决方案。理想解决方案：系统通知和告警
• 告警指标：5xx 比率超过 30%
• 告警详情：服务、端点、触发时间。补充根本原因分析。主要发现：API 错误率 100%，DB 无错误，S3 bucket policy 已更新。
• 立即操作：检查 S3 bucket policy 的 Deny 设置
• 置信度：90%。确认自动操作
• 消息：系统 Revered。
• RCA：S3 bucket policy 已设置为 Deny
• MTTR：5 分钟
• 将故障恢复时间从数小时缩短到数分钟。SRE 专家的工作范围
• 为什么我的 User Service 错误率在过去一小时内达到 5%？
• 因为 RDS MySQL 实例在过去一小时内发生了 12 次超出连接数限制的问题
• 熟悉当前系统
• 找出服务关联关系
• 分析日志
• 分析审计日志
• 分析配置
• 分析指标。思考两个问题

1. 如果系统复杂度高、故障排查工作流很长，而且日志量庞大，单个智能体能否顺畅运行？

2. 是否可以将 SRE 专家的经验复制到智能体中，以取代问答方式，让智能体能够自主决策并采取行动？

多智能体架构设计

• “Planner”创建工作流
• “Executor”负责执行分配的任务
• “Evaluator”负责评估每一步的结果是否有益，然后返回给“Planner”进行后续规划
• 结果在返回前也需要由“Evaluator”审核
• “Planner”可以根据“Evaluator”的反馈调整流程。多智能体 vs 单智能体

1. 适合更复杂的任务

2. 责任和权限边界更清晰

3. 更容易进行上下文工程

4. 更便于扩展。AgentCore 最佳实践：智能体专用运行时环境简介

• 从“试用”到“落地”的挑战
• 从 PoC 到生产环境落地的挑战
• 性能
• 弹性
• 安全性
• 创造业务价值
• 合规性

智能体运行时环境 v1.0

• 接口与协议 (MCP/A2A)
• 智能体部署
• 智能体框架
• 大语言模型
• 记忆
• 提示
• 工具/资源
• 防护机制
• 可观测性
• 评估。智能体运行时环境 v2.0
• 接口与协议 (MCP/A2A)
• 智能体部署
• Amazon Bedrock
• AgentCore
• 智能体框架
• 大语言模型运行时
• 记忆
• 提示
• 工具/资源
• 身份工具
• 防护机制
• Gateway
• 可观测性
• 评估。专用型
• Amazon Q Agents。完全托管
• Amazon Bedrock Agents。自行构建
• OSS 框架、Strands Agents SDK