（一）Agent 开发与 AgentOps 总览
解读 AWS 系列（一）——Agent 开发为何是新范式、AgentOps 与 DevOps/MLOps 的本质差异、平台建设两条路径的取舍。
业界实践解读 · 对应 ETCLOVG 整体框架（跨层）。以下是对原文的解读，保留其核心概念、关键决策；完整叙述请读原文： https://aws.amazon.com/cn/blogs/china/agentive-ai-infrastructure-practice-series-1/
AWS 系列共 9 篇，其主题域与 ETCLOVG 七层近乎 1:1 对应；本节各篇按此对应关系标注所属层。
解构 Agent 开发：为什么它是新范式
原文的核心判断是：Agent 开发不是”传统应用开发 + 调大模型”，而是一个多维度、多层次的工程挑战——你要构建的是一个具备 推理、记忆、行动能力的智能体。它把系统抽象为四个核心模块，每个模块都对应一类开发难题：
- 推理引擎（“大脑”）：真正决定 Agent 智能水平的地方，开发上的功课是提示词模板、推理链优化、以及推理成本控制—— 后者常被忽视，却是长程 Agent 的成败点。
- 记忆系统：分短期（会话上下文）与长期（偏好/历史），难在存储架构、高效检索、智能更新。
- 编排模块：协调其余三者、管理整体执行流（任务分解、异常处理、并发、状态），不同框架实现不同（Strands 任务编排器、 LangGraph 图执行器）。
- 工具接口（“手脚”）：一个 Agent 可能要调数十种 API，难点在标准化接入、智能选择与组合、异常重试、以及权限控制。
光有核心模块还不能上生产，原文补了四个支撑服务模块：质量评估（LLM-as-a-Judge + 人工）、身份认证与授权（“谁能访问 Agent”与”Agent 能访问什么”的双重身份 + 会话隔离）、安全与隐私（基于 OWASP Agentic AI 威胁模型的分层防护）、可观测性 （把 Agent 的”思维过程”可视化）。
这些需求最终被抽象成六个”统一”基础设施单元——这是全篇的骨架，也是理解 AgentCore 的钥匙：
- 统一运行时：会话隔离 + 生命周期管理（状态持久化/故障恢复）+ 接口标准化。它要”在 Agent 业务价值尚未明确时动态调整 资源以省成本”——一句话点破了 Agent 早期的经济现实。
- 统一工具接入（Gateway）：除接入/发现/鉴权外，特别强调工具快速搜索——网关按问题动态筛出最合适的工具子集， 而非把所有工具都塞给模型。原文明说这”减少返回工具数、提升相关性与速度、降低成本”，对控制运行成本尤为重要。
- 统一记忆单元：短期存原始数据、长期异步抽取语义事实/偏好/摘要；每用户独立命名空间。
- 统一通用基础工具：浏览器（“看网页、操作网页”，绕过无 API 系统）与代码解析器（“运行代码、算得更精”）。
- 统一认证鉴权与安全防护：入站/出站双向认证——入站控”谁能进”、出站控”Agent 出去调工具时如何安全授权”，再加 Guardrails 防幻觉与违规输出。
- 统一可观测性：基础设施层/应用层/业务层三层。
从 DevOps 到 AgentOps：本质是不确定性在升级
原文用一条清晰的递进解释 AgentOps 为何是新东西：DevOps 管确定性系统（同输入→可预期输出）；MLOps 引入了第一层不 确定性（模型性能随时间衰减、需持续数据反馈）；而 AI Agent 叠加了”智能行为”——自主决策、调外部工具、持续演化，把 不确定性推到新高度，对可复现性、成本、合规提出更高要求。它进一步把生成式 AI 的运维分成模型侧的 FMOps/LLMOps 与应用侧的 PromptOps/RAGOps，而 AgentOps 是把 DevOps/MLOps 扩展到 Agent 系统的运维范式。
落到技术需求，几个关键决策值得记住：把 Agent/工具打包为镜像或函数保证一致与隔离；用 IaC（CDK/Terraform/Helm）+ CI/CD 可重复地供应环境；建标准化记忆生产模板避免各团队重复造轮子；“提示词即代码”——提示词像代码一样可 diff/ 回滚/审查，一旦发现逻辑或合规问题能迅速回到已验证版本；安全上坚持最小权限 + 短期凭证、入站出站访问控制、流水线合规 扫描、密钥仅运行时注入并限定生命周期；发布用金丝雀/蓝绿、指标恶化则自动回滚。
构建平台：两条路径是一道选择题
原文不给”银弹”，而是把落地拆成一道按组织画像做的选择题：
- 平台工程型可扩展平台：借内部开发者平台（IDP）理念，把 AgentOps 能力产品化——开发者门户与治理、CI/CD 流水线、统一 容器运行时（Docker/K8s）、观测日志（Prometheus/Grafana、ELK）、集中密钥与 Guardrails。强治理、高可定制、能长期演进， 但前期投入与团队要求高，适合成熟组织与严格合规场景。
- 轻量托管/Serverless 快速落地：充分用云托管服务减少基础设施依赖——AgentCore / Lambda / ECS Fargate 做运行环境 （AgentCore 更适合 Agent 与 MCP）、Bedrock 托管模型、Gateway 把 API 转 MCP、CloudWatch 监控、IAM + Secrets Manager。 快上线、低成本、按量付费，适合小团队/PoC。
原文强调二者”并无绝对优劣”，是面向不同规模与治理需求的差异化选择——这正是要带走的判断：先按组织成熟度和 GTM 时效 选路径，而非盲目自建。
在亚马逊云上”生产就绪”：AgentCore 七单元
原文点出一个真问题：Strands/CrewAI/LangGraph 等框架降低了开发门槛，但运行时、记忆、浏览器、代码解析器、安全、认证、 工具管理、可观测、AgentOps 平台这些”不直接创造业务价值、却是生产必需品”仍有巨大差距——所以越来越多人选云端专业基础 设施，把精力留给业务。Bedrock AgentCore 就是把前面”六个统一”产品化为七大单元：
| 单元 | 作用 |
|---|---|
| Runtime | 低延迟无服务器环境部署 Agent/MCP，会话隔离，兼容各框架与长时运行 |
| Memory | 管理短期与长期记忆，提供上下文并从历史学习 |
| Browser | 完全托管的 Web 浏览器工具 |
| Code Interpreter | 隔离环境运行 Agent 生成的代码，即需即用 |
| Identity | 安全访问 AWS 与第三方（GitHub/Salesforce/Slack），可代表用户或预授权自行操作 |
| Gateway | 把现有 API 与 Lambda 转为工具、跨协议（含 MCP）统一访问 + 工具快速检索 |
| Observability | 逐步可视化：元数据标记、自定义评分、轨迹检查、调试过滤 |
原文的结语把整篇的立场收住：真正的挑战不在 Agent 本身的开发，而在让它在生产环境稳定、安全、可靠地运行；企业应把精力 投在业务创新上，而把基础设施复杂性交给专业平台——这也是 AgentCore 存在的理由。
本页是对原文的解读，保留其核心概念与关键决策；完整叙述与图示请以 AWS 原文 为准。