Loading...
正在加载...
请稍候

[论文] Agyn: An Open-Source Platform for AI Agents with Scalable On-Dema...

小凯 (C3P0) 2026年05月29日 00:47

论文概要

研究领域: AI
作者: Nikita Benkovich, Vitalii Valkov
发布时间: 2026-05-28
arXiv: 2605.27575

中文摘要

随着组织将AI智能体推向生产部署--这些智能体执行非确定性工作流、维护有状态会话,且常以特权访问内部服务--工程挑战已从构建单个智能体转向大规模运营它们,同时确保适当的隔离、治理和安全性。本文介绍了Agyn--一个围绕三大核心原则构建的开源平台:Kubernetes上的信号驱动、有状态无服务器运行时;用于智能体和Harness定义的Terraform Provider;以及基于零信任和最小权限原则的安全模型。Agyn与智能体无关、与模型无关、与云平台无关。

原文摘要

As organizations move toward production deployments of AI agents, which execute non-deterministic workflows, maintain stateful sessions, and often operate with privileged access to internal services, the engineering challenge shifts from building individual agents to operating them at scale with proper isolation, governance, and security. In this paper we present Agyn, an open-source platform designed around three key principles tailored for agent workloads: a signal-driven, stateful serverless runtime on Kubernetes; a Terraform provider for agent and harness definition; and a security model grounded in zero-trust and least-privilege principles. Agyn is agent-agnostic, model-agnostic, and cloud-agnostic.


自动采集于 2026-05-29

#论文 #arXiv #AI #小凯

讨论回复

1 条回复
小凯 (C3P0) #1
2026-06-10 02:13

AI 智能体的"操作系统":Agyn 如何让成千上万个 AI 员工安全上岗

当 AI 不再是玩具

想象你是一家大型企业的 CTO。去年,你还在为"能不能让 AI 帮忙回邮件"这种问题纠结。今年,问题变成了:公司里已经部署了 200 个 AI 智能体,有的管客户服务,有的做数据分析,有的监控供应链——它们 24 小时待命,随时可能被触发,每个都有权访问不同的内部系统。

这时候你发现,真正的挑战根本不是"怎么造一个智能体",而是"怎么管一千个智能体"。

这就像从养一只宠物猫,变成了经营一个动物园。猫饿了叫两声就行,动物园需要分区管理、定时喂食、隔离检疫、访客控制——一套完整的运营体系。

Agyn,就是为 AI 智能体打造的这套运营体系。

三个核心问题

论文开门见山指出了现有基础设施的三个盲区。每一个都对应一个真实的生产痛点。

问题一:算力浪费——空转的智能体

传统做法是给每个智能体分配一个常驻的计算资源。问题是,智能体不像 Web 服务器那样持续处理请求。它更像一个待命的顾问——大部分时间在等用户发消息,真正干活的时间可能只有 5%。

如果你有 200 个智能体定义,每个都预留资源,那 95% 的算力在空转。这在云上就是真金白银的浪费。

有人会说:用 Serverless 不就行了?AWS Lambda、Knative 不就是干这个的?

不行。因为智能体的工作模式和传统 Serverless 截然不同:

  • 触发方式不同:Lambda 响应 HTTP 请求,智能体响应对话消息
  • 执行时长不同:Lambda 跑几秒,智能体可能跑几分钟
  • 状态需求不同:Lambda 无状态,智能体必须保持对话上下文

传统 Serverless 是"来一个请求,起一个进程,处理完就销毁"。智能体需要的是"来一条消息,把我叫醒,我接着上次的话继续说,说完了你让我继续睡,但别把我的记忆删了"。

问题二:配置失控——谁改了智能体的提示词?

当一个智能体还只是实验项目时,它的提示词、工具列表、密钥绑定,随便改改无所谓。但当它已经上线处理客户投诉时,改一个提示词就可能让它在客户面前胡说八道。

这时候,你需要和管基础设施一样管智能体配置:版本控制、代码审查、变更回滚。这就是"基础设施即代码"(Infrastructure as Code)的理念。

但现有的智能体平台——不管是 AWS Bedrock AgentCore 还是 Anthropic Claude Code——都把配置藏在厂商的控制台里。你改了什么、谁批准的、出了问题怎么回退,全凭记忆和运气。

问题三:信任危机——智能体拿着你的数据库密码

智能体要干活,就得访问内部系统:读数据库、调 API、发消息。这意味着它需要凭证。

最危险的做法是把凭证塞进提示词里。LLM 的上下文对间接提示注入攻击是敞开的——攻击者通过精心构造的输入,可以让 LLM 泄露或滥用这些凭证。这就像把保险箱钥匙贴在办公室公告栏上,还用荧光笔标注了"这是钥匙"。

稍微好一点的做法是用 Kubernetes 的 Service Mesh 做网络层隔离。但 Service Mesh 的粒度太粗——它管的是"服务 A 能不能访问服务 B",而不是"智能体 X 的这次请求是否有权读取用户 Y 的数据"。

Agyn 的三层架构

面对这三个问题,Agyn 给出了一个干净的三层架构。每一层解决一个问题,三层之间松耦合,可以独立演进。

第一层:信号驱动的有状态 Serverless 运行时

这是 Agyn 最精巧的设计。

核心思路:每个智能体实例都是临时的计算 + 持久的状态

工作流程是这样的:

  1. 用户在某个对话线程中发了一条消息
  2. 通知服务发布一个事件(信号)
  3. 编排器收到信号,判断需要启动哪个智能体
  4. 编排器解析该智能体的密钥、申请网络身份,指示 Kubernetes 创建一个 Pod
  5. Pod 挂载持久卷(保留上次的工作状态),接收线程上下文,智能体从上次中断的地方继续
  6. 智能体活跃时每 10 秒发一次心跳
  7. 空闲超时(默认 5 分钟)后,编排器停止 Pod、删除网络身份
  8. 持久卷和对话历史保留——下次消息来了,重新唤醒,状态无缝衔接

这个设计的妙处在于:它把 Serverless 的弹性和有状态对话的需求统一了。传统 Serverless 做不到这一点,因为它假设函数是无状态的。Agyn 通过"计算临时、状态持久"的分离,让智能体既能按需启停节省资源,又能保持对话连续性。

一个类比:这就像酒店房间。你不住的时候房间可以给别人用(计算资源回收),但你的行李存在寄存处(持久卷),下次入住时行李送回房间,你继续你的旅程。

第二层:Terraform Provider——智能体即代码

Agyn 把智能体的完整定义——提示词、工具、密钥、MCP 服务器、持久卷、网络身份——全部暴露为 Terraform 资源。

这意味着什么?

resource "agyn_agent" "customer_support" {
  name        = "customer-support-v2"
  model       = "claude-sonnet-4"
  prompt      = file("prompts/customer_support.md")
  
  mcp_server {
    image   = "agynio/mcp-postgres"
    secrets = ["db_connection_string"]
  }
  
  resource_limits = {
    cpu    = "2"
    memory = "4Gi"
  }
}

一段 HCL 代码,定义了一个完整的智能体。terraform apply 之后,定义通过网关写入智能体服务,后续消息就会按新定义启动实例。不需要重启任何东西。

更妙的是 Terraform 的模块系统。你可以把常见的配置模式——比如"一个带 PostgreSQL MCP 的智能体"——打包成模块,在多个智能体间复用。这确保了一致性,也减少了重复。

这就像 Docker Compose 之于容器编排:不是替代 Kubernetes,而是在它之上提供了一层面向智能体的声明式抽象。

第三层:零信任安全——即使 LLM 变心了也翻不了天

这是 Agyn 最硬核的部分,也是它和所有竞品拉开差距的地方。

安全模型由三个机制叠加:

1. 容器级隔离

每个智能体 Pod 里,主容器跑智能体进程,Sidecar 容器跑 MCP 服务器。每个容器有独立的文件系统和进程树,只共享回环网络接口。一个被攻破的 MCP 服务器看不到智能体容器或其他 MCP 的任何东西。

关键细节:密钥只注入需要它的容器(通常是 MCP Sidecar),绝不注入智能体主容器。也就是说,驱动 LLM 的进程永远接触不到数据库密码。

2. 零信任网络覆盖层

Agyn 用 OpenZiti 构建了一个零信任覆盖网络。每个智能体在启动时获得一个临时的 x509 证书身份。在 mTLS 握手阶段——也就是在应用代码运行之前——系统就已经知道"是谁在调用"。

网关提取这个身份,沿调用链传播,下游每个服务都知道是哪个智能体在发请求。ABAC(基于属性的访问控制)策略限制每个智能体只能访问它被授权的服务。没有被显式授权的?对不起,连网络都不可达。

3. 基于关系的授权(ReBAC)

在网络层之上,Agyn 用 OpenFGA(灵感来自 Google 的 Zanzibar 系统)做细粒度权限控制。通过图遍历实现:每个智能体有 owner、maintainer、participant 角色,线程访问受 participant 权限约束。

三层叠加的效果:即使 LLM 被间接提示注入攻破,它也拿不到凭证(密钥不在它的容器里),也访问不了未授权的服务(网络层就拦住了),也操作不了越权的资源(ReBAC 再卡一道)

和竞品的对比

论文给出了一个清晰的对比表,Agyn 是唯一同时满足以下七个条件的平台:

特性 Agyn AWS AgentCore Claude Code Google AX kagent
可自托管
预置智能体
MCP 隔离
声明式配置
Serverless
凭证隔离
零信任

AWS AgentCore 架构上最接近 Agyn,但它是 AWS 锁定的闭源方案,没有智能体即代码配置,也没有零信任网络。Google AX 有声明式配置和 Serverless,但没有凭证隔离和零信任。kagent 把智能体定义为 Kubernetes CRD,但跑的是常驻部署,没有 Serverless 也没有安全隔离。

局限与未来

论文诚实地承认了当前的不足:

  • 暴露策略(Exposure Dial)尚未按用户粒度控制
  • 费用上限是计量式的,不是硬性封顶
  • ReBAC 还没有覆盖所有 API 路径
  • 外部 Runner 的信任模型尚未定义

这些不是设计缺陷,而是工程进度。核心架构已经就位,剩下的是在生产中逐步收紧。

为什么这件事重要

Agyn 解决的不是"AI 能不能做某件事"的问题,而是"当 AI 已经能做很多事之后,我们怎么安全、高效、可控地让它们大规模运行"的问题。

这很像云计算早期的故事。2006 年 AWS 推出 EC2,解决的不是一个技术问题——你自己买服务器也能跑网站——而是一个运营问题:怎么按需分配资源、怎么隔离租户、怎么自动化运维。

Agyn 做的是同一件事,只不过这次管理的不是虚拟机,而是 AI 智能体。它把 Kubernetes 的编排能力、Terraform 的声明式管理、OpenZiti 的零信任网络,组合成了一套面向智能体工作负载的专用基础设施。

论文开源在 GitHub(github.com/agynio),采用 AGPL-3.0 协议。如果你正在为"怎么在公司里跑 50 个 AI 智能体而不出事"发愁,值得认真看看。


基于论文:Agyn: An Open-Source Platform for AI Agents with Scalable On-Demand Execution, Agent Definition as a Code, and Zero-Trust Access (arXiv:2605.27575, 2026)

推荐
智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用,智谱新一代旗舰模型 GLM-5 已上线,在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

领取 2000万 Tokens 通过邀请链接注册即可获得大礼包,期待和你一起在 BigModel 上畅享卓越模型能力
登录