PPIO发布Agent Runtime:让Agent部署像Serverless一样简单

PPIO发布Agent Runtime:让Agent部署像Serverless一样简单

近期,PPIO 发布了基于 Sandbox(沙箱)自研的新产品:Agent Runtime,一个轻量级的 Agent 运行时框架。

Agent Runtime 是为了顺应 Agent 的专属需求而推出,其定位与 AWS AgentCore Runtime 类似。AgentCore 是 AWS 在 2025 年推出的专为 Agent 设计的基础设施平台,AgentCore Runtime 则是其中一个子产品,是基于 Firecracker 微虚拟机的 Serverless 运行时环境,旨在解决 Agent 低成本、高效率的部署问题。

PPIO Agent Runtime 通过简单易用的 SDK 与强大的沙箱运行环境来简化 Agent 的部署过程。用户无需关心基础设施配置、容器编排、服务暴露等复杂细节,只需专注于 Agent 的业务逻辑开发。

PPIO Agent Runtime 构建在 PPIO 的 Sandbox 之上。Sandbox 提供了硬件级的安全隔离和资源管理,而 Agent Runtime 则在此基础上实现了会话管理、状态保持和快速部署能力。两者结合,为开发者提供了一个可靠的 Agentic Infra 选择。

Sandbox 与 Agent Runtime 的出现,标志着云计算从云原生向 AI 原生基础设施的重要演进。


# 01 

开发者为什么需要 Agent Runtime?

Agent Runtime 的推出并非偶然,而是一个明确市场需求的回应:如何将 Agent 从实验室原型快速、安全、经济地推向生产环境。

Agent 生产环境背后是巨大的商业市场空间。根据市场研究,Agentic AI 市场预计将从 2024 年的 52.5 亿美元增长到2032 年的 961.8 亿美元。但是,也有市场研究机构警告,到 2027 年底将有 40% 的 Agent 项目因部署复杂度、成本失控和价值不清而被取消。

这种矛盾的背后有很多原因,而最核心的关键问题在于,现有的云基础设施并不是为 Agent 的独特执行模式设计的。

以当前云计算的主流架构 Serverless 为例,其特点与 Agent 存在天然的冲突。

首先,Serverless 的生命周期短,而 Agent 的生命周期较长。

Serverless 能够按照任务请求自动弹性伸缩,但本质上是短生命周期执行环境,适合事件驱动的小任务。出于成本和架构设计考虑,Serverless 一般都强制限制最大执行时长,例如AWS Lambda 是 15 分钟,执行超时会被系统强制终止。

然而,一个执行复杂任务的 Agent,尤其是带工具使用、多轮推理、长尾任务的,例如长文档结构化、Deep Research,通常需要数十分钟甚至数小时才能完成任务。

其次,Serverless 架构针对的是无状态任务,而 Agent 天然就是有状态任务。

所谓的无状态意味着一次执行结束后,所有内存状态都被销毁,下一次执行必须从外部重新读回来。而 Agent 需要在多轮交互中保持上下文和会话状态,来统一管理 Agent 的记忆、工具调用历史和任务计划。传统的无状态架构需要频繁的外部存储读写,严重影响性能。

容器理论上可以运行 Agent ,但容器在成本与管理复杂度上挑战很大。

首先是空闲计费。即使 Agent 任务没有在运行,容器也在占据资源,CPU、内存、GPU 都要付钱。而 Agent 任务的工作负载波峰波谷极大,导致容器浪费惊人。其次是管理复杂。面对容器,开发者需要管理生命周期,管理日志、监控、调度、扩容,管理镜像/版本,管理网络、权限、安全组,对小团队、需要快速迭代的 Agent 应用来说都是极高的负担。

基于以上差异,Agent Runtime 应运而生。

Agent Runtime 可提供长时间的有状态会话,实现了 Agent 专用的 Serverless 运行环境。这标志着云计算从通用计算平台向 AI 原生基础设施的重要演进。


# 02

PPIO Agent Runtime 的核心能力:轻量级,低成本

PPIO 针对 Agent 任务所需要的持久性、状态性和自主性的特点而打造的 PPIO Agent Runtime,是一个轻量级 Agent 运行时框架,能够 快速、低成本地将 Agent 部署上线。

PPIO Agent Runtime 的核心能力包括以下几点:

第一,会话级隔离,每个用户会话都会创建一个全新的 Sandbox 实例

基于 PPIO Sandbox 的系统级隔离,每个任务运行在独立环境中,防止数据泄露和越权操作,获得独立的计算资源、内存空间和文件系统。当会话结束时,整个 Sandbox 被彻底销毁,所有会话上下文被安全清除。

这种设计使得会话之间的数据交互必须通过显式的外部服务(如数据库或消息队列),从架构层面杜绝了数据泄露风险。对于处理敏感信息的企业 Agent 应用,这种硬隔离比容器级隔离提供了更强的安全保障。

第二,基于轻量级 Sandbox 实现毫秒级冷启动。

PPIO Sandbox 采用轻量级虚拟化技术,实现了接近容器的启动速度与硬件级的环境隔离。冷启动时间 < 200ms(包含运行时初始化)。且天生适配大量并发场景。这意味着即使是第一次请求,用户也能获得亚秒级的响应速度,远优于传统虚拟机方案。

第三,长时间有状态运行,实现真正的“有状态Serverless”

与传统 Serverless 的短生命周期不同,PPIO Agent Runtime 支持:

- 会话时长:单个会话可持续运行数小时

- 状态保持:会话期间所有内存状态、文件、连接自动保持

这种“有状态 Serverless”模式特别适合需要多轮交互的 Agent 应用,如数据分析助手、代码调试助手、文档处理等。

第四,框架无关性。

PPIO Agent Runtime 不绑定特定的 Agent 开发框架,支持包括 LangGraph、OpenAI Agents SDK、Google ADK、CrewAI、AutoGen 在内的主流框架,以及任何自定义实现。只需添加简单的几行代码即可完成集成。

from ppio_sandbox.agent_runtime import AgentRuntimeApp

# 创建 Agent Runtime 应用实例
app = AgentRuntimeApp()

# 使用装饰器定义 Agent 入口点
@app.entrypoint
def my_agent(request: dict) -> dict:
    prompt = request.get("prompt", "")

    # Agent 业务逻辑
    # 这里可以调用 LLM、使用 Agent 框架、或任何自定义逻辑
    result = f"收到消息: {prompt}"

    return {"result": result}

if name == "__main__":
    app.run()

详情可查看集成指南:

https://ppio.com/docs/sandbox/agent-runtime-frameworks


第五,分钟级部署

PPIO Sandbox CLI 支持一键配置、部署 Agent 到 PPIO Agent 沙箱生态。通过 PPIO Sandbox CLI 工具,从代码到生产环境只需两个命令:

# 初始化项目
ppio-sandbox-cli agent configure

# 部署
ppio-sandbox-cli agent launch

部署成功后,只需在后端服务中集成 PPIO 的 SDK,调用一个方法即可完成调用。

from ppio_sandbox.agent_runtime import AgentRuntimeClient as PPIOAgentRuntimeClient

client = PPIOAgentRuntimeClient(
  api_key=os.getenv("PPIO_API_KEY")
)

response = await client.invoke_agent_runtime(
  agentId=os.getenv("PPIO_AGENT_ID"),
  payload=payload,
)

第六,生产级特性支持

健康检查机制:

@app.ping
def health_check() -> dict:
    return {"status": "healthy", "service": "My Agent"}

用户可以在应用中定期调用 /ping 端点检查 Agent 状态,确保服务可用性。

流式响应支持:

async def stream_response(query):
    async for chunk in agent.process_stream(query):
        yield f"data: {chunk}\n\n"

支持 Server-Sent Events (SSE) 协议,实现实时的流式输出,提升用户体验。您只需使用 Generator 或 AsyncGenerator 返回数据,即可自动实现流式响应。


第七,成本优势。

相比传统部署方式,PPIO Agent Runtime 通过简单易用的 SDK 与强大的沙箱运行环境来简化 Agent 的部署过程,用户无需关心基础设施配置、容器编排、服务暴露等复杂细节,只需专注于 Agent 的业务逻辑开发。

这不仅降低了开发成本,还降低了运维成本,PPIO Agent Runtime 支持全托管服务,实现自动扩缩容。

开发者可基于 PPIO Agent Runtime 实现成本优化,仅为实际使用时间付费。

关于 PPIO Agent Runtime 的部署流程和进阶功能,可查看开发者文档:

https://ppio.com/docs/sandbox/agent-runtime-introduction


# 03

结语

Agent 的大规模应用需要专门的基础设施支持。AWS AgentCore 的推出验证了这一市场需求,而 PPIO Agent Runtime 为国内开发者提供了一个轻量、安全、易用的选择。

如果你正在开发 Agent 应用,正在为部署和运维发愁,不妨试试 PPIO Agent Runtime——也许它正是你需要的那块拼图。

如果你是 PPIO 新用户,用邀请码【24CGOJ】注册可得代金券:

https://ppio.com/ai-computing/sandbox

企业级用户可以扫码获取企业级服务权益与报价。

Read more

当Agent计算规模扩大100倍,我们需要什么样的Agentic Infra?

当Agent计算规模扩大100倍,我们需要什么样的Agentic Infra?

近期,PPIO Sandbox(沙箱)发布了一个重要功能:沙箱克隆。 沙箱克隆旨在助力提高 Agent 的并行计算能力,也就是经典的“Scale up”规模扩展问题。 今年最流行的 Agent 产品是 Deep Research,它可以看作对单个研究问题持续追踪、推演、迭代直到形成洞察的长链路串行推理过程。 那么,如果将 Deep Research 的能力 Scale up 一百倍会发生什么?像 Manus 这样的 Agent 正在解决这类挑战,并将这种并行计算架构的 Agent 称之为 Wide Research。 从 Agent 的串行计算到并行计算,离不开“沙箱克隆”这一核心技术的助力,这是 PPIO 在 Agentic Infra

By PPIO
PPIO上线Kimi K2 Thinking,兼容Anthropic协议

PPIO上线Kimi K2 Thinking,兼容Anthropic协议

今天,PPIO 上线 Kimi K2 Thinking,这是 Kimi 最新、功能最强大的开源思考模型。 Kimi K2 Thinking 基于 Kimi K2 后训练而来的混合专家模型(MoE),总参数达 1T,激活参数 32B,上下文长度 256K。该模型支持深度思考、Function Call、结构化输出、json_schema、json_object 等功能。 现在,你可以到 PPIO 官网在线体现 Kimi K2 Thinking,也可以将 PPIO 的模型 API 部署到 AI 应用中。 PPIO 在线体验地址: https:

By PPIO
PPIO独家上新GPU实例模板,一键部署Kimi-Linear

PPIO独家上新GPU实例模板,一键部署Kimi-Linear

昨晚,月之暗面发布了混合线性注意力架构新模型 Kimi-Linear,旨在解决大语言模型在长上下文推理中的计算瓶颈。 Kimi-Linear 的核心亮点: * Kimi Delta Attention(KDA),一种通过细粒度门控机制改进门控规则的线性注意力架构。 * 混合架构:采用 3:1 的 KDA 与全局 MLA 比例,在保持甚至超越全注意力质量的同时降低内存占用。 * 卓越性能:在 1.4T Token 的训练规模下,经公平对比,KDA 在长文本与类强化学习基准等多项任务上均优于全注意力。 * 高吞吐:在 1M 上下文中实现最高 6 倍的解码吞吐量,显著缩短单输出 Token 耗时(TPOT)。 今天,PPIO 独家上新 GPU 实例模板,可一键部署 Kimi-Linear-48B-A3B-Instruct 的专属模型。 PPIO 算力市场的

By PPIO
为什么说“Spot GPU实例”是AI算力体系的战略级补充?

为什么说“Spot GPU实例”是AI算力体系的战略级补充?

在云计算的成本优化领域,有一种独特的计费模式,它允许用户以极低的折扣获取计算资源,堪比“捡漏”。这就是 Spot 实例。 早期的 Spot 实例是“闲置资源的低价甩卖”,本质是供需调节。但在今天的云原生与 AI 生态中, Spot 实例——尤其是 Spot GPU 实例,变成了 AI 算力编排体系中的战略一环。 对于希望最大化利用云预算的开发者和企业来说,理解并善用 Spot GPU 实例是实现成本效益最大化的关键。 # 01 什么是 Spot 实例? Spot 实例,又被称为竞价实例、抢占式实例,是云服务提供商将数据中心内的闲置计算容量以动态变化的价格进行售卖的一种机制。 Spot 实例在性能上与标准的按需实例(On-Demand Instance)并无二致,但价格却能提供高达 50%~90% 的折扣。 而低价的代价是,当云服务商需要收回这些容量以满足按需或其他更高优先级用户的需求时,

By PPIO