行业动态

运行时实例:Amazon Bedrock AgentCore 上生产级AI代理的持久计算

Key takeaway: Amazon Web Services (AWS) 在 Amazon Bedrock AgentCore 服务中正式推出了 runtime instances 计算选项,提供面向生产级 AI 代理的持久计算基础设施。Runtime instances 基于 AWS 托管的 EC2 实例,支持单次会话最长持续 14 天,可运行多个协作代理并共享文件系统,从而实现在同一主机上通过共享目录直接交换数据而无需 API 调用。该服务还支持 GPU 加速实例类型,适合需要长时间运行、多步骤状态保持或 OS 级访问的复杂工作负载。与此前支持最长 8 小时无状态调用的 runtime microVMs 形成互补,两者可通过统一的 AgentCore API 进行混合编排,例如轻量级编排代理运行在 microVM 上,将计算密集型任务分派给 runtime instances 上的工作者代理。用户可使用任何框架(如 CrewAI、LangGraph、LlamaIndex、Strands Agents)和任何模型,仅需通过 @app.entrypoint 装饰器打包应用为 zip 或容器镜像。文章通过代码编写代理和代码审查代理的演示,展示了从创建 capacity provider、部署代理到在同一会话中协作的完整流程。定价为 EC2 标准费用加 AgentCore 管理费,首发区域覆盖美东、美西、亚太和欧洲多个区域。

Key Takeaways
  1. AWS 推出 Amazon Bedrock AgentCore 的 runtime instances 计算选项,面向生产级 AI 代理提供持久计算能力。
  2. Runtime instances 支持最长 14 天的会话持久化、GPU 加速以及多代理共享文件系统的协作模式。
  3. 可与现有的 runtime microVMs 混合使用,通过同一套 API 实现编排代理与工作者代理的灵活分工。
  4. 支持任何代理框架和模型,开发人员只需用 @app.entrypoint 装饰器打包应用即可部署。
  5. 服务已在美国东部、西部、亚太和欧洲的多个区域上线,按 EC2 实例费用加管理费计费。
将 AI 代理从原型推向生产,基础设施往往成为最大瓶颈。AWS 今天发布的 Bedrock AgentCore runtime instances 直面这一痛点,提供最长 14 天的持久会话、GPU 加速和多代理文件系统级协作。这意味着开发团队再也无需自建复杂的 EC2 集群和会话管理层,只需一个简单的 @app.entrypoint 装饰器,就能让任意框架和模型的代理在托管环境中长期稳定运行。文中通过编码与审查两个代理的零 API 协同演示,清晰展示了这种共享文件模式如何大幅降低多代理系统的构建复杂度。对于正在探索 Agentic AI 落地的前线工程师和架构师来说,这绝对是一项值得立即试用的新能力,它将显著缩短复杂代理工作流的上市时间。

AWS 推出 Amazon Bedrock AgentCore 的 runtime instances 计算选项,面向生产级 AI 代理提供持久计算能力。

—— 络石智能编辑部 · Editor's Pick

运行时实例:Amazon Bedrock AgentCore 上生产级AI代理的持久计算

当您将AI代理从原型迁移到生产环境时,基础设施挑战成倍增加。您的代理需要在运行数小时或数天的多步骤工作流中保持状态。它们需要与其他代理协调、共享上下文,有时还需要访问GPU以执行专门任务。Amazon Bedrock AgentCore 运行时微虚拟机(runtime microVMs)为可持续运行长达8小时的调用提供完全托管的环境,并通过托管会话存储支持有状态工作流。某些工作负载还需要专用的、更大容量的环境——例如,当代理需要连续运行数天、访问GPU或底层操作系统,或在同一主机上运行多个协作代理时。

今天,我很高兴宣布运行时实例(runtime instances),这是 Amazon Bedrock AgentCore 运行时中一项新的补充计算选项,为复杂的代理工作负载提供持久、托管的专用基础设施。

您将获得什么

运行时实例提供 AWS 托管的 EC2 基础设施,您可以在单个运行时中部署多个代理,每个代理拥有自己的依赖项和工件类型。您的代理可以在同一主机上协作,在持续长达14天的共享会话中工作。该服务支持 GPU 加速以处理计算密集型任务,支持会话停止/重启以在空闲期间节省成本,并支持容器化部署,方便团队独立发布。对于需要跨会话存续的知识,运行时实例可与 Amazon Elastic Block Store(Amazon EBS)和 AgentCore Memory 自然搭配,后者为您的代理提供跨会话和跨环境的长期记忆。

在今天之前,如果您想让代理运行数天、需要 GPU 访问或多代理协调,您必须自行构建和管理这些基础设施。您需要预置 EC2 实例、配置网络、设置会话管理、处理扩展并组装监控。运行时实例为您处理所有这些工作,同时与您已在 AgentCore 运行时微虚拟机中使用的 AgentCore API、身份控制和可观测性集成。

一些让代理开发者感到欣喜的功能:您的代理可以在共享会话中互相调用对方作为工具,自主迭代直至任务完成。您可以使用任何框架(CrewAI、LangGraph、LlamaIndex、Strands)和任何模型。打包非常简单,只需一个 @app.entrypoint 装饰器和一个 zip 文件或容器镜像。如果您的工作流跨越数天,可以在周一晚上休眠,周三早上恢复,一切保持原样。

运行时微虚拟机和运行时实例是互补的计算选项,您可以通过相同的 AgentCore 运行时 API 独立或组合使用。微虚拟机上轻量级编排代理可以协调并将工作分派给在实例上运行的专用工作代理。编排器使用运行时微虚拟机的快速扩展处理 API 调用、任务路由和结果聚合,而实例上的工作代理则执行需要持久状态和直接操作系统访问的计算密集型任务,如代码编译、安全扫描或 GUI 自动化。

让我向您展示它是如何工作的

我为这个演示构建了两个代理:一个代码编写代理,根据自然语言描述生成 Python 代码;一个代码审查代理,分析生成的代码中的错误、安全问题和风格改进。两个代理共享相同的文件系统,因此审查者可以直接读取编写者生成的内容,无需任何数据传输或 API 调用。

这是代码编写代理(简化版,无错误处理):

writer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a senior Python engineer. "
        "Given a task, return ONLY a single Python code block — no prose."
    ),
)

@app.entrypoint
def handler(event, context):
    task = event.get("task") or event.get("prompt")
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / "code.py").write_text(code)

    return {"agent": "writer", "wrote": str(session_dir / "code.py"), "code": code}

这是代码审查代理(简化版,无错误处理):

reviewer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a strict Python code reviewer. "
        "Given code, return 3 bullet points: bugs, style, suggestions."
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(reviewer(f"Review this code:\n\n{code}"))

    return {"agent": "reviewer", "read": str(code_path), "review": review}

每个代理都是一个使用 Strands Agents 的 Python 应用程序,带有 @app.entrypoint 装饰器和自选模型。我将每个代理打包为 zip 文件。对于此演示,我使用 AWS 管理控制台。您也可以使用 AgentCore CLI、AWS 命令行界面(AWS CLI)或基础设施即代码。

步骤 1:创建容量提供程序

容量提供程序定义了您的代理所运行的 EC2 基础设施。在 AgentCore 控制台中,我在左侧导航中选择 Runtime,然后选择 Capacity providers 选项卡,再点击 Create capacity provider。

我为其命名,选择 Linux (64-bit ARM) 作为操作系统,并选择 c7g.2xlarge 作为 Allowed instance types。这提供了 8 个 vCPU 和 16 GiB 内存,足以让两个代理舒适地并排运行。

进一步向下,我配置 VPC、子网和安全组以进行网络访问。在 Storage configuration 下,我保留默认的 gp3 卷。在 Service access 下,我选择 Create a new service role,让控制台创建代表我管理 EC2 实例的基础设施角色。

我选择 Create capacity provider 并等待几秒钟。状态变为 Active。

请注意容量提供程序的配置摘要:操作系统、实例类型、子网、安全组、实例配置文件和基础设施角色。创建后,只能编辑描述,因此请务必在继续之前验证您的设置。

步骤 2:创建运行时并部署第一个代理

回到 Runtime 页面,我选择 Create runtime。我为其命名,选择 Instances 作为 Compute type,并选择上一步创建的容量提供程序。

在 Agent source 下,我选择 S3 Source,然后点击 Upload to S3。我选择我的代理 zip 文件(ACIDemoWriter.zip),将 Language runtime 设置为 Python 3.13,,并指定 agent.py 作为 Agent entry point。这是包含我的 @app.entrypoint 装饰函数的文件。在 Permissions 下,我选择 Create default role 让控制台预置我的代理所需的 IAM 角色。

我选择 Create runtime 并等待状态变为 Ready。

我为代码审查代理重复相同的过程。我创建第二个运行时,选择相同的容量提供程序,上传我的审查代理 zip 文件,并等待其变为 Ready。现在两个代理共享相同的底层 EC2 基础设施。

控制台向我展示了一个 View invocation code 部分,其中包含随时可用的 Python、TypeScript 和 JavaScript 代码片段,用于以编程方式调用我的代理。但对于此演示,我使用内置的测试功能。我在编写代理的页面上选择 Test。

步骤 3:调用代理并观察协作

Runtime 游乐场打开。在顶部,我看到三个字段:Runtime agent、Endpoint 和 Session ID。控制台自动生成一个会话 ID。我记下它,因为我会在审查代理中重复使用它。

在 Input 字段中,我输入一个 JSON 负载,要求编写代理生成代码:

{"prompt": "write a fibonacci suite"}

我选择 Run。几秒钟后,Output 面板显示代理的响应。编写代理生成了一个 Python 模块,其中包含斐波那契数列的两种实现(一个基于列表的函数和一个生成器),并将其写入 /tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py。请注意文件路径中的会话 ID。该目录是此会话的共享文件系统。

步骤 4:在同一个会话中调用审查代理

现在我将 Runtime agent 下拉列表切换到 ACIDemoReviewer。重要部分:我在 Session ID 字段中粘贴相同的会话 ID(ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2)。这是连接两个代理的关键。

我输入一个简单的提示:

{"prompt": "review the code"}

我选择 Run。审查代理从共享会话目录中读取编写者生成的文件,并返回详细的代码审查。它没有发现严重错误,但建议添加类型提示、输入验证并简化边缘案例处理。

这两个代理从未交换消息或调用彼此的 API。它们通过运行时实例在会话中提供的共享文件系统进行协作。您可以将此模式扩展到任意数量的代理:一个运行代码的测试代理、一个生成 README 文件的文档代理、一个扫描漏洞的安全代理,所有代理共享同一个工作目录。

关键细节

以下是您开始使用时需要了解的一些事项:

  • 支持的操作系统:Linux(ARM64 和 x86_64)在发布时支持。
  • 会话持久性:会话最多持续 14 天。
  • 运行时:Python 3.11-14,支持原生代码。也支持容器镜像。
  • GPU:支持 GPU 加速实例类型。
  • 集成:使用与 AgentCore 运行时相同的 AgentCore API、身份、可观测性和策略控制。
  • 定价:标准 EC2 定价加上 AgentCore 编排的管理费。
  • 区域:美国东部(俄亥俄、弗吉尼亚北部)、美国西部(俄勒冈)、亚太地区(孟买、新加坡、悉尼、东京)和欧洲(法兰克福、爱尔兰)

要开始使用,请访问 Amazon Bedrock AgentCore 文档中的运行时实例,并创建您的第一个容量提供程序。

资源


关注

Tags

Related Topics

Expert Comment

This article is curated by the editorial team from public sources for reference only.

FAQ

Amazon Bedrock AgentCore 的 runtime instances 是什么?它和 runtime microVMs 有什么区别?
Runtime instances 是 AWS 为生产级 AI 代理提供的持久计算选项,底层基于托管的 EC2 实例,支持最长 14 天的会话持久化、GPU 加速以及多代理共享文件系统。它与 runtime microVMs 形成互补:microVMs 适用于无状态、最长 8 小时的轻量级调用,而 instances 则针对需要长时间运行、持续状态和底层操作系统访问的复杂工作负载。两者可通过同一套 AgentCore API 混合编排。
如何在 runtime instances 中实现多个 AI 代理的协作?
多个代理可以部署在同一个 runtime instance 并共享一个会话 ID,从而访问同一共享文件系统。例如,代码编写代理将生成的代码文件写入会话目录,代码审查代理从同一目录读取文件进行审查,整个过程无需 API 调用。这种共享文件模式可以扩展到任意数量的代理,如测试、文档生成、安全扫描等。
Amazon Bedrock AgentCore runtime instances 支持哪些框架和模型?
Runtime instances 不限制框架和模型,支持任何 Python 代理框架,如 CrewAI、LangGraph、LlamaIndex、Strands Agents 等,以及任何可通过 API 调用的语言模型。用户只需用 @app.entrypoint 装饰器包裹处理函数,打包为 zip 或容器镜像即可部署。

Related Articles

资深前部署工程师,GenAI,Google Cloud(日语、英语)

Google Cloud 发布 Senior Forward Deployed Engineer, GenAI 职位招聘,工作地点位于日本东京。该职位属于 Google Cloud 的 Go-To-Market 团队,要求候选人具备 Python 和机器学习框架(如 Keras、PyTorch、HF Transformers)的 5 年以上经验,以及应用 AI 构建系统的能力,包括提示工程、微调、检索增强生成(RAG)和编排模型与外部工具交互。候选人还需有在云平台(如 Google Cloud Platform)上架构、部署或管理解决方案的经验,并精通日语和英语。优先条件包括 AI 或计算机科学硕士/博士学位,以及使用 LangGraph、CrewAI 或 Google Agent Development Kit (ADK) 实现多智能体系统的经验,熟悉 ReAct、自我反思、层级委托等模式,并了解大语言模型原生指标(如 tokens/sec、cost-per-request)及状态管理和细粒度追踪优化。职位核心职责是将 AI 应用从原型转化为生产级智能体工作流,架构并编码连接 Google AI 产品与客户现有基础设施,构建评估流水线和可观测框架以确保智能体系统的准确性、安全性和延迟达标,识别可复用的现场模式并将其转化为可复用模块或产品功能需求,以及联合客户工程团队灌输 Google 级开发最佳实践。该职位强调嵌入式构建者的角色,弥合前沿 AI 产品与客户生产现实之间的鸿沟,并将现场洞察反馈至 Google Cloud 产品路线图。Google 提供包括 Gemini 前沿模型和 Vertex AI 平台在内的最先进 AI 产品组合,以及直接接触 DeepMind 工程和研究团队的协作文化。

Read More

前场部署工程师,AI赋能(UR和MiR,North Reading, MA)职位详情

Teradyne 于 2026 年 7 月 2 日发布了一则 FDE 前线部署工程师 AI 赋能方向的招聘信息,工作地点位于美国马萨诸塞州 North Reading。该职位隶属于首席人工智能官(Chief AI Officer)领导的 AI 转型团队,核心使命是通过 AI 增强工作流来增强员工能力,并将智能嵌入关键业务流程。FDE 需利用 Microsoft Copilot Studio/Foundry、LangChain、LlamaIndex 等现代平台,设计并部署 AI 增强工作流,构建自然语言界面和对话式 AI 系统,并与销售、工程、运营、财务和产品团队合作,将 AI 能力转化为可衡量的业务价值。职位要求 3-5 年软件工程经验,熟练使用 Cursor、OpenAI Codex、Claude Code 等 AI 原生开发工具,并具备全栈开发能力。此外,具备智能体 AI 框架(如 OpenClaw、LangGraph)、本地模型推理(Ollama)、MCP、RAG 架构及向量数据库等经验者优先。该岗位薪资范围为 169,700 至 271,500 美元,体现了 Teradyne 对 AI 前线部署人才的高度重视。

Read More

Forward Deployed Engineers (FDE): 完整指南 (2026)

本文是 Kizzy Consulting 创始人兼 CEO Sanjeet Mahajan 撰写的 2026 年前线部署工程师(Forward Deployed Engineer, FDE)完整指南,系统阐述了 FDE 这一将深度全栈工程能力与客户现场咨询相结合的混合角色的定义、起源、架构职责、技术栈、技能要求和行业实践。文章指出,随着生成式 AI 和 Agentic AI 的普及,85% 的顶级 AI 企业已雇佣 FDE 进行实施交付,FDE 可将客户实现价值的速度提升 3 倍,中级 FDE 起薪超过 13 万美元,资深级别可达 30 万美元以上。FDE 角色源自 Palantir Technologies 的实践,现已拓展至 OpenAI、Anthropic、Databricks 等 AI 公司。文章深入分析了 FDE 在 Agentic AI 编排、Agentic RAG 架构、Model Context Protocol 等方面的具体工作,对比了 LangGraph、CrewAI、Semantic Kernel 等框架的适用场景,并提供了 90 天企业实施路线图和最佳实践,涵盖语义缓存、Human-in-the-Loop 安全护栏、混合搜索优化等关键策略。

Read More

前部署工程师,生成式人工智能,Google Cloud(英语,普通话)

Google Cloud 在 Cake 平台上发布了生成式 AI 领域的前线部署工程师(Forward Deployed Engineer, FDE)招聘信息,工作地点位于新加坡,要求具备中英文双语能力。该职位不同于传统顾问角色,FDE 将作为嵌入客户的构建者,直接深入客户环境进行编码、调试和交付定制化的代理式 AI 解决方案,弥合前沿 AI 产品与生产落地之间的鸿沟。职位要求包括计算机科学或相关领域学士学位、5 年 Python 开发经验、在 Google Cloud Platform 上架构 AI 系统的经验,以及使用向量数据库和检索增强生成(RAG)架构构建企业 AI 解决方案的实践经验。优先考虑具有多代理系统框架(如 LangGraph、CrewAI、Agent Development Kit)和复杂模式(ReAct、自我反思、层级委派)落地经验,以及服务过加密行业客户的人选。核心职责涵盖开发复杂代理工作流、架构与编码客户基础设施的集成、建立高精度评估和可观测性框架、识别可复用的现场模式并转化为产品需求,以及手把手带领客户团队掌握 Google 级开发最佳实践。该岗位代表了 AI 落地从咨询转向深度共建的趋势,突出了生产级 AI 系统的多代理、RAG、全栈工程和评估能力要求。

Read More

Forward-deployed engineering in the age of agentic AI: From vibe coding to governed autonomy - Tiatra, LLC

本文由 Tiatra, LLC 发布,系统阐述了前线部署工程(FDE)在 Agentic AI 时代从“氛围编程”到“受控自治”的演进。核心论点在于,当 AI Agent 从单纯回答问题转向规划、调用工具、读写企业数据、更新系统并跨多步执行时,生产成功不再依赖模型演示,而取决于业务上下文、工作流边界、控制、可观测性和人工问责的工程化设计。FDE 通过将工程能力嵌入业务现场,弥补了原型与可信生产系统之间的鸿沟。文章详细描述了 FDE 的运营模式:明确业务成果、分解工作流、构建包含真实鉴权与监控的“薄片”生产系统、迭代优化并转移运维知识。在治理方面,文章提出了五层模型——意图、数据、工具、决策和运行时治理,并引用了 Gartner、Forrester、IDC 及 Everest Group 的分析作为支撑。安全部分则强调最小权限、工具白名单、审批门、间接提示注入防御和完整审计轨迹。文章还探讨了 FDE 与 vibe coding 的关系,认为前者为后者提供了必要的工程纪律。最后,通过 LangGraph、Microsoft AutoGen 与 Microsoft Agent Framework、CrewAI 三个具体案例,展示了 FDE 如何在不同编排栈上实现可审计、可恢复、有人工介入的受控 Agent 系统,并提供了六层参考架构和十条最佳实践。

Read More