从“玩具”到“工具”的跨越困境许多企业在初期尝试引入 Agent 时往往采取“单点突破”的策略——由个别极客员工或小型团队基于开源框架或云 API 快速搭建原型。这种模式在 POC概念验证阶段行之有效但当企业试图将 Agent 规模化推广至全公司时混乱随之而来。数据孤岛、权限失控、成本黑洞、安全漏洞等问题接踵而至。传统的IT治理体系在面对具有高度自主性、动态交互性和复杂依赖关系的 AI Agent 时显得捉襟见肘。例如某企业中可能存在如下角色基础设施团队负责底层 Agent 实例的创建、VPC/RDS/OSS 等资源的配置和运维但他们不直接开发业务 Agent也不应该参与业务层面的权限分配。企业管理和运维人员需要制定资源策略、审批权限申请、监控整体用量但如果没有管理平台只能通过人工流程或直接在云控制台操作既低效又容易出错。业务开发者需要快速创建和迭代 Agent 来解决实际问题但在没有自助平台的情况下他们要么过度依赖基础设施团队提需求、等排期要么被迫直接操作底层资源安全风险高、学习成本大。这三类角色关注的是完全不同的抽象层面如果没有一个中间平台承接业务语义层的治理协作链路就会变得冗长、脆弱且不可追溯。以上基础层面痛点在企业实际操作中会具象化为一系列具体困境跨团队协作效率低业务开发者创建 Agent 需要向基础设施团队提需求、等排期一个权限变更走工单链路耗时数天团队间数据互相可见市场部和研发部共用同一个 Agent 实例两边的 Prompt、知识库、调用记录彼此可见缺乏隔离人员变动导致权限失控员工离职后无法自动回收 Agent 使用权限也无法追溯该员工创建和管理了哪些 Agent成本超支无感知某个团队大量调用高规格模型月底结算时才发现 Token 消耗远超预期事前没有配额和预警机制审计无法支撑合规企业需要回答哪个团队创建了多少 Agent、“某个 Agent 的完整生命周期是什么”但现有工具只能记录 API 调用日志AgentRun 团队推出的AgentRun 开放平台正是为了解决这一“规模化落地难”的核心痛点而生。它并非仅仅是一个 Agen t开发工具而是一个基于 AgentRun 底层强大算力与运行时能力构建的企业级AI 运维中台。该平台以员工权限管理为核心通过三层多租户体系、精细化的资源隔离机制以及全流程的合规审计能力为企业构建了一个安全、可控、高效的 Agent 生产与管理环境。1.企业 Agent 规模化落地的四大核心挑战在企业内部推广 Agent本质上是一场组织变革与技术重构的双重实验。在这个过程中基础设施团队、管理层与业务开发者三类角色之间的张力构成了云资源管理体系的核心难点。1.1 抽象层级错位IAM 体系与业务语义的断裂传统的企业身份与访问管理IAM系统如阿里云 RAM其设计初衷是控制对云产品 API 的操作权限。例如它可以精确控制“谁可以调用 CreateAgent 接口”或“谁可以读取 OSS 存储桶”。然而企业内部的实际管理需求往往是基于业务语义的。管理者需要的权限策略通常是“市场部的所有员工可以使用已审批通过的‘营销文案生成’类 Agent但不能访问‘财务数据分析’类 Agent”或者“实习生只能在使用沙箱环境中测试 Agent且无法导出知识库数据”。若强行使用 RAM 来实现这些需求需要编写极其复杂且难以维护的政策脚本Policy且无法原生支持“申请-审批-授权-回收”这样的动态流程。这种抽象层级的不匹配导致权限配置要么过于宽松存在安全隐患要么过于僵化阻碍业务创新。1.2 隔离粒度粗糙数据泄露与资源争抢的风险在缺乏专用中台的情况下多个团队往往共用同一个 AgentRun 实例或云账号。这意味着市场部的 Prompt 模板、研发部的代码片段、甚至包含敏感客户信息的知识库可能在同一存储空间中彼此可见。这种“裸奔”状态带来了巨大的数据泄露风险。更严重的是由于缺乏细粒度的资源隔离某个团队的高并发调用可能耗尽共享实例的计算资源导致其他关键业务 Agent 响应延迟甚至服务中断。企业急需一种轻量级、逻辑严密且易于管理的隔离机制既能保障数据安全又能避免资源争抢。1.3 协作链路断裂敏捷性与规范性的博弈在没有统一平台载体时Agent 的生命周期管理依赖于人工流程。业务开发者想要创建一个新的 Agent可能需要向基础设施团队提交工单等待 VPC 配置、数据库初始化、API Key 分配等一系列操作。这个过程短则数天长则数周严重拖慢了业务迭代速度。反之如果为了追求速度而赋予业务开发者过高的底层权限让他们直接操作云控制台则极易引发配置错误、密钥泄露等安全事故。企业陷入两难要么牺牲效率换取安全要么牺牲安全换取效率。这种协作链路的断裂是阻碍 Agent 大规模普及的主要人为障碍。1.4 成本黑盒与审计缺失不可控的运营隐患大模型调用的 Token 成本高昂且波动巨大。在传统模式下企业很难实时监控每个团队、每个用户甚至每个 Agent 的 Token 消耗情况。往往直到月底收到账单时才发现某项非核心业务的调用量激增导致预算超支。此外合规审计也是一大难题。当发生数据泄露或违规操作时企业需要回答“是谁创建的 Agent ”、“该 Agent 访问了哪些数据”、“它的完整生命周期是怎样的”。现有的云日志仅记录 API 调用缺乏业务层面的上下文关联使得追溯变得异常困难。2.以权限为核心的三层多租户治理体系面对上述挑战AgentRun 开放平台没有选择修补式的解决方案而是从底层架构出发构建了一套以员工权限管理为核心的三层多租户体系。这一体系将复杂的云资源管理封装在后台向前台暴露出符合人类直觉的业务语义接口实现了“平台级→团队级→个人级”的分层治理。2.1 第一层用户组User Group—— 批量管理的基石用户组是平台中核心的权限隔离和资源分配单元。它解决了企业中用户众多、逐个配置权限不现实的难题。批量继承与高效管理管理员只需配置一次用户组的权限策略组内所有成员自动继承。例如将“研发部全员”加入“研发用户组”该组被赋予访问特定高性能模型和内部代码知识库的权限。新员工入职时只需将其加入该组即可瞬间获得相应权限极大降低了运维成本。**硬性资源隔离与成本控制**不同用户组拥有独立的工作空间配额、AgentRuntime 数量限制以及 Token 月度上限。这种组级配额机制从源头上防止了资源滥用。例如限制“实习生组”每月只能使用低规格模型且 Token 上限较低而“核心算法组”则享有更高配额。存储空间与广场配置不同的用户组配置不同的存储空间不同的存储空间相互不可见从根本上控制了资源隔离的问题。同时增加了广场配置功能不同的用户组下面的用户所见广场的内容各不相同相互隔离。2.2 第二层用户管理User—— 个性化配置的灵活补充在用户组提供的标准化权限之上用户管理层提供了个性化的微调能力以应对企业中的特殊场景。统一管控中心管理员可以通过集中入口查看、搜索、编辑所有开发者用户的状态。支持启用/禁用账号对于离职或异常用户可一键阻断其对所有 Agent 资源的访问确保安全性。细粒度权限叠加除了继承用户组的权限管理员可以为单个用户配置额外的资源权限。例如某位资深工程师虽然属于普通研发组但因负责特定重点项目需要额外访问一个高密级的知识库。这种“基础权限额外授权”的模式既保持了管理的规范性又保留了足够的灵活性。注册与身份集成平台支持与企业现有的身份提供商IdP通过SSO单点登录集成支持 OIDC协议支持企业微信登录飞书登录钉钉登录。这不仅简化了用户的登录体验更确保了身份源的统一性和权威性。2.3 第三层用户空间UserSpace—— 团队协作的独立沙箱用户空间是开发者在平台上进行实际工作的独立单元也是权限落地的最终场景。每个用户空间都是一个逻辑上完全隔离的沙箱。资源隔离与数据隐私不同用户空间之间的 AgentRuntime、Prompt、知识库、记忆库等资源完全隔离。市场部的空间无法看到研发部的任何数据彻底解决了数据泄露问题。角色分权协作在每个用户空间内部进一步细化为 Owner所有者、Admin管理员、Member成员三级角色。Owner 拥有最高权限负责空间的整体配置Admin 可以管理成员邀请和资源绑定Member 仅能使用已配置好的 Agent 进行对话或调试。这种内部的分权机制模拟了真实项目团队的协作结构。动态配额优先级用户空间的配额来源遵循严格的优先级逻辑空间级自定义配额 所有者用户额外配额 用户组默认配额 系统全局默认值。这种设计允许在必要时对特定项目进行资源倾斜而不影响整体治理框架。2.4多维协同 —— 构建精细化的资源隔离与访问体系AgentRun 开放平台中新增了用户组用户以及用户空间的概念这些概念在 AgentRun 中是不存在那么它们的之间的关系是怎样的呢对于 AgentRun资源之间的隔离是通过账号级别以及 Workspace 工作空间来实现的这种权限的隔离方式是与阿里云的账号体系的 RAM 深度绑定但是对于企业级的不同的用户不同的用户组之间的隔离却没有做到那么精细。用户组关联多个工作空间用户组可以具有多个工作空间的权限也就是在该用户组下的用户均可以访问用户组对应的工作空间的资源例如 Agent, Skill知识库等。在 AgentRun 开放平台中每个用户组需绑定一个唯一的存储工作空间用于资源落地。当组内成员创建 Agent、知识库等资源时这些资源物理上均存入该存储工作空间。隔离机制虽然用户组可能拥有其他工作空间如工作空间 A、B的访问权限, 但其绑定的存储工作空间如工作空间 C默认对组内其他成员不可见。权限规则只有资源的创建者Owner拥有该存储工作空间内对应资源的访问权组内其他成员无法查看或使用他人创建的资源。示例说明若用户组拥有工作空间 A 和 B 的访问权但绑定工作空间 C 为存储空间。当成员甲在组内创建资源时资源实际存入 C。此时成员乙虽能访问 A 和 B 中的共享资源却无法看到或访问成员甲存放在 C 中的私有资源从而实现了“资源统一存储”与“个人数据隔离”的双重保障。用户关联工作空间用户关联了多个工作空间用户关联的工作空间是对用户组的补充。该用户不仅继承了用户组的资源权限并且又具备他本身的资源权限。用户空间用户空间是属于该用户的空间用户 A 和用户 B 都位于同一个用户组下面那么用户 A 创建的 Agent 资源用户 B 是看不到的。例如用户 A 创建了专属于自己的知识库他是不想让用户 B 看到和使用的这个资源隔离是通过用户空间进行的隔离。用户组用户用户空间 共同构建了资源的隔离和访问的基石使不同用户组之间资源相互隔离不同的用户的资源也能进行隔离。3.构建端到端的 Agent 全生命周期服务体系依托于 AgentRun 强大的底层能力AgentRun 开放平台不仅解决了“管”的问题更在“用”的层面提供了丰富的功能矩阵形成了完整的 Agent 生产力闭环。3.1 核心能力矩阵一站式 Agent 工厂平台提供了从 Agent 创建、调试到运行、监控的全链路能力AgentRuntime支持对话型和流程编排型两类智能体。每个智能体拥有独立的运行环境和可观测数据开发者可以在用户空间内轻松复制、版本化管理 Agent 实例。工具与技能生态内置了浏览器、搜索引擎、VPC 访问等常用技能并支持注册 Function Call 工具和 MCPModel Context Protocol协议工具。管理员可以集中配置平台级技能用户按需安装实现了能力的复用与标准化。知识库与 RAG 增强支持本地文件上传、OSS 同步、飞书知识库同步以及对接百炼、Ragflow 等外部知识库。通过内置的高效检索增强生成RAG引擎企业可以快速构建基于私有数据的智能问答系统。记忆库与长期学习为智能体提供长期记忆和短期记忆能力支持配置独立的 LLM 和 Embedding 模型。Agent 能够持续学习交互内容随着使用时间的推移变得越来越“懂”业务。3.2 差异化竞争力安全、成本与体验的全面优化相较于通用的云控制台或开源方案AgentRun 开放平台在以下方面展现了显著的差异化优势极致安全的密钥管理这是企业最关心的痛点之一。在平台上API Key 等敏感凭据由管理员统一配置并加密存储。Agent 运行环境中无法直接获取明文 Key开发者无需在代码中硬编码密钥从根源上杜绝了凭证泄露风险。灵活多样的成本控制策略节省模式针对低频使用的场景提供按量付费实例页面关闭即回收资源显著降低闲置成本。精细化配额支持系统默认配额与用户级自定义配额相结合事前预警事后审计。多档规格选择提供从 1c1g 到 4c8g 共六档算力规格企业可根据业务负载灵活选择避免算力浪费。持久化与无缝体验通过挂载 OSS 实现工作空间持久化实例重启后所有文件和配置原样保留。同时支持钉钉、飞书、企业微信、个人微信等多渠道即时通讯接入除钉钉外均支持扫码配对让 Agent 真正融入员工的日常沟通场景。可观测性与运维透明化基于 OpenTelemetry 构建开箱即用的可观测大盘实时展示 Token 消耗、响应延迟、错误率等关键指标。内置阿里云 CLI方便高级用户进行自动化运维操作。3.3 角色分工与协作流程的重构AgentRun 开放平台重新定义了企业内部各角色在 AI 时代的工作方式基础设施团队聚焦于 AgentRun 实例的创建、VPC、RDS、OSS 等底层资源的稳定运维不再介入具体的业务 Agent 开发。管理和运维人员通过管理后台制定全局资源策略、审批权限申请、监控整体用量、管理平台级技能和模板。他们成为了企业 AI 治理的“守门人”。业务开发者通过开发者控制台专注于业务逻辑的实现。他们可以自助创建 Agent、调试 Prompt、管理知识库并通过简单的配置即可将 Agent 发布到钉钉或微信等渠道。这种清晰的分工使得各方各司其职既保障了底层设施的稳定性与安全性又释放了业务层的创新活力。3.4 资源审批单功能当用户 A 开发出一款高效实用的 Agent 并渴望将其推广至全公司时如何平衡资源共享的便捷性与企业数据的安全性成为关键。为此开放平台借鉴阿里内部成熟的权限治理体系设计了一套严谨且流畅的“资源发布与审批”流程旨在实现从个人私有到团队共享的安全过渡。平台遵循“默认最小权限”原则。用户创建的所有 Agent 资源初始状态均严格限定为“仅本人可见”其他同事无法检索或访问从而从源头杜绝了敏感逻辑或未成熟功能的意外泄露。当用户 A 确认其 Agent 具备推广价值时可发起“公开申请”。在资源管理界面用户需点击“公开资源”按钮。此时系统不仅会触发审批流还要求用户填写简要的功能说明与应用场景以便管理员评估。审批请求将实时推送至拥有相应权限的管理员工作台。管理员在收到通知后可查看 Agent 的详细元数据、潜在风险评级及用户描述。经过合规性与安全性审核后管理员执行“批准”操作。一旦审批通过系统将自动更新该资源的访问控制列表指定的用户组即刻获得查看与使用权限无需人工逐个配置。这一机制既保留了开发者快速迭代的自由度又通过中心化审批确保了企业级应用的分发规范。它不仅降低了内部工具推广的门槛更构建了一道坚实的安全防线。4.构建企业 AI 时代的操作系统AgentRun 开放平台的推出标志着企业 AI 应用进入了一个新的阶段从野蛮生长走向有序治理从单点试用走向体系化运营。4.1 合规与审计的可追溯性通过三层多租户体系和完整的生命周期管理平台记录了每一个 Agent 的创建者、修改者、使用者以及所有的交互日志。当面临合规审查时企业可以轻松导出报表回答“哪个团队创建了多少 Agent”、“某个 Agent 在何时访问了哪些敏感数据”等问题。这种可追溯性是企业规模化应用 AI 的法律与安全基石。4.2 降本增效的量化实现精细化的配额管理和节省模式使得企业能够将大模型调用成本控制在合理范围内。据初步测算通过合理的配额限制和资源回收机制企业可降低 30%-50% 的非必要 Token 消耗。同时自助式的服务模式大幅缩短了 Agent 的开发与上线周期提升了业务响应速度。4.3 激发全员创新的文化氛围当安全与成本的顾虑被平台化解后业务人员不再畏惧尝试新技术。低门槛的使用体验和丰富的模板库鼓励更多非技术人员参与到 Agent 的创新中来。这种全员参与的文化氛围将是企业在 AI 时代保持竞争力的核心源泉。结语AgentRun 开放平台不仅仅是一个技术产品它是 AgentRun 为企业量身打造的AI 业务操作系统。它以AgentRun 为坚实底座以员工权限管理为核心纽带巧妙地平衡了安全合规与敏捷创新之间的矛盾。对于渴望在 AI 浪潮中乘风破浪的企业而言选择一个具备完善治理能力的中台系统比单纯追求模型的参数规模更为重要。AgentRun 开放平台所提供的隔离、权限、流程、角色分工、成本与安全六大核心价值正是企业从“能用 Agent”迈向“能管好 Agent”最终实现“用好 Agent”的必经之路。在未来随着 AI 技术的进一步演进这样一个具备高度弹性、安全性和可扩展性的中台系统必将成为企业数字化基础设施中不可或缺的一部分。了解更多阿里云 AgentRun 产品文档AgentRun 控制台https://functionai.console.aliyun.com/cn-hangzhou/agent/runtime
Agent从“能用“到“管好“，中间差了什么？
从“玩具”到“工具”的跨越困境许多企业在初期尝试引入 Agent 时往往采取“单点突破”的策略——由个别极客员工或小型团队基于开源框架或云 API 快速搭建原型。这种模式在 POC概念验证阶段行之有效但当企业试图将 Agent 规模化推广至全公司时混乱随之而来。数据孤岛、权限失控、成本黑洞、安全漏洞等问题接踵而至。传统的IT治理体系在面对具有高度自主性、动态交互性和复杂依赖关系的 AI Agent 时显得捉襟见肘。例如某企业中可能存在如下角色基础设施团队负责底层 Agent 实例的创建、VPC/RDS/OSS 等资源的配置和运维但他们不直接开发业务 Agent也不应该参与业务层面的权限分配。企业管理和运维人员需要制定资源策略、审批权限申请、监控整体用量但如果没有管理平台只能通过人工流程或直接在云控制台操作既低效又容易出错。业务开发者需要快速创建和迭代 Agent 来解决实际问题但在没有自助平台的情况下他们要么过度依赖基础设施团队提需求、等排期要么被迫直接操作底层资源安全风险高、学习成本大。这三类角色关注的是完全不同的抽象层面如果没有一个中间平台承接业务语义层的治理协作链路就会变得冗长、脆弱且不可追溯。以上基础层面痛点在企业实际操作中会具象化为一系列具体困境跨团队协作效率低业务开发者创建 Agent 需要向基础设施团队提需求、等排期一个权限变更走工单链路耗时数天团队间数据互相可见市场部和研发部共用同一个 Agent 实例两边的 Prompt、知识库、调用记录彼此可见缺乏隔离人员变动导致权限失控员工离职后无法自动回收 Agent 使用权限也无法追溯该员工创建和管理了哪些 Agent成本超支无感知某个团队大量调用高规格模型月底结算时才发现 Token 消耗远超预期事前没有配额和预警机制审计无法支撑合规企业需要回答哪个团队创建了多少 Agent、“某个 Agent 的完整生命周期是什么”但现有工具只能记录 API 调用日志AgentRun 团队推出的AgentRun 开放平台正是为了解决这一“规模化落地难”的核心痛点而生。它并非仅仅是一个 Agen t开发工具而是一个基于 AgentRun 底层强大算力与运行时能力构建的企业级AI 运维中台。该平台以员工权限管理为核心通过三层多租户体系、精细化的资源隔离机制以及全流程的合规审计能力为企业构建了一个安全、可控、高效的 Agent 生产与管理环境。1.企业 Agent 规模化落地的四大核心挑战在企业内部推广 Agent本质上是一场组织变革与技术重构的双重实验。在这个过程中基础设施团队、管理层与业务开发者三类角色之间的张力构成了云资源管理体系的核心难点。1.1 抽象层级错位IAM 体系与业务语义的断裂传统的企业身份与访问管理IAM系统如阿里云 RAM其设计初衷是控制对云产品 API 的操作权限。例如它可以精确控制“谁可以调用 CreateAgent 接口”或“谁可以读取 OSS 存储桶”。然而企业内部的实际管理需求往往是基于业务语义的。管理者需要的权限策略通常是“市场部的所有员工可以使用已审批通过的‘营销文案生成’类 Agent但不能访问‘财务数据分析’类 Agent”或者“实习生只能在使用沙箱环境中测试 Agent且无法导出知识库数据”。若强行使用 RAM 来实现这些需求需要编写极其复杂且难以维护的政策脚本Policy且无法原生支持“申请-审批-授权-回收”这样的动态流程。这种抽象层级的不匹配导致权限配置要么过于宽松存在安全隐患要么过于僵化阻碍业务创新。1.2 隔离粒度粗糙数据泄露与资源争抢的风险在缺乏专用中台的情况下多个团队往往共用同一个 AgentRun 实例或云账号。这意味着市场部的 Prompt 模板、研发部的代码片段、甚至包含敏感客户信息的知识库可能在同一存储空间中彼此可见。这种“裸奔”状态带来了巨大的数据泄露风险。更严重的是由于缺乏细粒度的资源隔离某个团队的高并发调用可能耗尽共享实例的计算资源导致其他关键业务 Agent 响应延迟甚至服务中断。企业急需一种轻量级、逻辑严密且易于管理的隔离机制既能保障数据安全又能避免资源争抢。1.3 协作链路断裂敏捷性与规范性的博弈在没有统一平台载体时Agent 的生命周期管理依赖于人工流程。业务开发者想要创建一个新的 Agent可能需要向基础设施团队提交工单等待 VPC 配置、数据库初始化、API Key 分配等一系列操作。这个过程短则数天长则数周严重拖慢了业务迭代速度。反之如果为了追求速度而赋予业务开发者过高的底层权限让他们直接操作云控制台则极易引发配置错误、密钥泄露等安全事故。企业陷入两难要么牺牲效率换取安全要么牺牲安全换取效率。这种协作链路的断裂是阻碍 Agent 大规模普及的主要人为障碍。1.4 成本黑盒与审计缺失不可控的运营隐患大模型调用的 Token 成本高昂且波动巨大。在传统模式下企业很难实时监控每个团队、每个用户甚至每个 Agent 的 Token 消耗情况。往往直到月底收到账单时才发现某项非核心业务的调用量激增导致预算超支。此外合规审计也是一大难题。当发生数据泄露或违规操作时企业需要回答“是谁创建的 Agent ”、“该 Agent 访问了哪些数据”、“它的完整生命周期是怎样的”。现有的云日志仅记录 API 调用缺乏业务层面的上下文关联使得追溯变得异常困难。2.以权限为核心的三层多租户治理体系面对上述挑战AgentRun 开放平台没有选择修补式的解决方案而是从底层架构出发构建了一套以员工权限管理为核心的三层多租户体系。这一体系将复杂的云资源管理封装在后台向前台暴露出符合人类直觉的业务语义接口实现了“平台级→团队级→个人级”的分层治理。2.1 第一层用户组User Group—— 批量管理的基石用户组是平台中核心的权限隔离和资源分配单元。它解决了企业中用户众多、逐个配置权限不现实的难题。批量继承与高效管理管理员只需配置一次用户组的权限策略组内所有成员自动继承。例如将“研发部全员”加入“研发用户组”该组被赋予访问特定高性能模型和内部代码知识库的权限。新员工入职时只需将其加入该组即可瞬间获得相应权限极大降低了运维成本。**硬性资源隔离与成本控制**不同用户组拥有独立的工作空间配额、AgentRuntime 数量限制以及 Token 月度上限。这种组级配额机制从源头上防止了资源滥用。例如限制“实习生组”每月只能使用低规格模型且 Token 上限较低而“核心算法组”则享有更高配额。存储空间与广场配置不同的用户组配置不同的存储空间不同的存储空间相互不可见从根本上控制了资源隔离的问题。同时增加了广场配置功能不同的用户组下面的用户所见广场的内容各不相同相互隔离。2.2 第二层用户管理User—— 个性化配置的灵活补充在用户组提供的标准化权限之上用户管理层提供了个性化的微调能力以应对企业中的特殊场景。统一管控中心管理员可以通过集中入口查看、搜索、编辑所有开发者用户的状态。支持启用/禁用账号对于离职或异常用户可一键阻断其对所有 Agent 资源的访问确保安全性。细粒度权限叠加除了继承用户组的权限管理员可以为单个用户配置额外的资源权限。例如某位资深工程师虽然属于普通研发组但因负责特定重点项目需要额外访问一个高密级的知识库。这种“基础权限额外授权”的模式既保持了管理的规范性又保留了足够的灵活性。注册与身份集成平台支持与企业现有的身份提供商IdP通过SSO单点登录集成支持 OIDC协议支持企业微信登录飞书登录钉钉登录。这不仅简化了用户的登录体验更确保了身份源的统一性和权威性。2.3 第三层用户空间UserSpace—— 团队协作的独立沙箱用户空间是开发者在平台上进行实际工作的独立单元也是权限落地的最终场景。每个用户空间都是一个逻辑上完全隔离的沙箱。资源隔离与数据隐私不同用户空间之间的 AgentRuntime、Prompt、知识库、记忆库等资源完全隔离。市场部的空间无法看到研发部的任何数据彻底解决了数据泄露问题。角色分权协作在每个用户空间内部进一步细化为 Owner所有者、Admin管理员、Member成员三级角色。Owner 拥有最高权限负责空间的整体配置Admin 可以管理成员邀请和资源绑定Member 仅能使用已配置好的 Agent 进行对话或调试。这种内部的分权机制模拟了真实项目团队的协作结构。动态配额优先级用户空间的配额来源遵循严格的优先级逻辑空间级自定义配额 所有者用户额外配额 用户组默认配额 系统全局默认值。这种设计允许在必要时对特定项目进行资源倾斜而不影响整体治理框架。2.4多维协同 —— 构建精细化的资源隔离与访问体系AgentRun 开放平台中新增了用户组用户以及用户空间的概念这些概念在 AgentRun 中是不存在那么它们的之间的关系是怎样的呢对于 AgentRun资源之间的隔离是通过账号级别以及 Workspace 工作空间来实现的这种权限的隔离方式是与阿里云的账号体系的 RAM 深度绑定但是对于企业级的不同的用户不同的用户组之间的隔离却没有做到那么精细。用户组关联多个工作空间用户组可以具有多个工作空间的权限也就是在该用户组下的用户均可以访问用户组对应的工作空间的资源例如 Agent, Skill知识库等。在 AgentRun 开放平台中每个用户组需绑定一个唯一的存储工作空间用于资源落地。当组内成员创建 Agent、知识库等资源时这些资源物理上均存入该存储工作空间。隔离机制虽然用户组可能拥有其他工作空间如工作空间 A、B的访问权限, 但其绑定的存储工作空间如工作空间 C默认对组内其他成员不可见。权限规则只有资源的创建者Owner拥有该存储工作空间内对应资源的访问权组内其他成员无法查看或使用他人创建的资源。示例说明若用户组拥有工作空间 A 和 B 的访问权但绑定工作空间 C 为存储空间。当成员甲在组内创建资源时资源实际存入 C。此时成员乙虽能访问 A 和 B 中的共享资源却无法看到或访问成员甲存放在 C 中的私有资源从而实现了“资源统一存储”与“个人数据隔离”的双重保障。用户关联工作空间用户关联了多个工作空间用户关联的工作空间是对用户组的补充。该用户不仅继承了用户组的资源权限并且又具备他本身的资源权限。用户空间用户空间是属于该用户的空间用户 A 和用户 B 都位于同一个用户组下面那么用户 A 创建的 Agent 资源用户 B 是看不到的。例如用户 A 创建了专属于自己的知识库他是不想让用户 B 看到和使用的这个资源隔离是通过用户空间进行的隔离。用户组用户用户空间 共同构建了资源的隔离和访问的基石使不同用户组之间资源相互隔离不同的用户的资源也能进行隔离。3.构建端到端的 Agent 全生命周期服务体系依托于 AgentRun 强大的底层能力AgentRun 开放平台不仅解决了“管”的问题更在“用”的层面提供了丰富的功能矩阵形成了完整的 Agent 生产力闭环。3.1 核心能力矩阵一站式 Agent 工厂平台提供了从 Agent 创建、调试到运行、监控的全链路能力AgentRuntime支持对话型和流程编排型两类智能体。每个智能体拥有独立的运行环境和可观测数据开发者可以在用户空间内轻松复制、版本化管理 Agent 实例。工具与技能生态内置了浏览器、搜索引擎、VPC 访问等常用技能并支持注册 Function Call 工具和 MCPModel Context Protocol协议工具。管理员可以集中配置平台级技能用户按需安装实现了能力的复用与标准化。知识库与 RAG 增强支持本地文件上传、OSS 同步、飞书知识库同步以及对接百炼、Ragflow 等外部知识库。通过内置的高效检索增强生成RAG引擎企业可以快速构建基于私有数据的智能问答系统。记忆库与长期学习为智能体提供长期记忆和短期记忆能力支持配置独立的 LLM 和 Embedding 模型。Agent 能够持续学习交互内容随着使用时间的推移变得越来越“懂”业务。3.2 差异化竞争力安全、成本与体验的全面优化相较于通用的云控制台或开源方案AgentRun 开放平台在以下方面展现了显著的差异化优势极致安全的密钥管理这是企业最关心的痛点之一。在平台上API Key 等敏感凭据由管理员统一配置并加密存储。Agent 运行环境中无法直接获取明文 Key开发者无需在代码中硬编码密钥从根源上杜绝了凭证泄露风险。灵活多样的成本控制策略节省模式针对低频使用的场景提供按量付费实例页面关闭即回收资源显著降低闲置成本。精细化配额支持系统默认配额与用户级自定义配额相结合事前预警事后审计。多档规格选择提供从 1c1g 到 4c8g 共六档算力规格企业可根据业务负载灵活选择避免算力浪费。持久化与无缝体验通过挂载 OSS 实现工作空间持久化实例重启后所有文件和配置原样保留。同时支持钉钉、飞书、企业微信、个人微信等多渠道即时通讯接入除钉钉外均支持扫码配对让 Agent 真正融入员工的日常沟通场景。可观测性与运维透明化基于 OpenTelemetry 构建开箱即用的可观测大盘实时展示 Token 消耗、响应延迟、错误率等关键指标。内置阿里云 CLI方便高级用户进行自动化运维操作。3.3 角色分工与协作流程的重构AgentRun 开放平台重新定义了企业内部各角色在 AI 时代的工作方式基础设施团队聚焦于 AgentRun 实例的创建、VPC、RDS、OSS 等底层资源的稳定运维不再介入具体的业务 Agent 开发。管理和运维人员通过管理后台制定全局资源策略、审批权限申请、监控整体用量、管理平台级技能和模板。他们成为了企业 AI 治理的“守门人”。业务开发者通过开发者控制台专注于业务逻辑的实现。他们可以自助创建 Agent、调试 Prompt、管理知识库并通过简单的配置即可将 Agent 发布到钉钉或微信等渠道。这种清晰的分工使得各方各司其职既保障了底层设施的稳定性与安全性又释放了业务层的创新活力。3.4 资源审批单功能当用户 A 开发出一款高效实用的 Agent 并渴望将其推广至全公司时如何平衡资源共享的便捷性与企业数据的安全性成为关键。为此开放平台借鉴阿里内部成熟的权限治理体系设计了一套严谨且流畅的“资源发布与审批”流程旨在实现从个人私有到团队共享的安全过渡。平台遵循“默认最小权限”原则。用户创建的所有 Agent 资源初始状态均严格限定为“仅本人可见”其他同事无法检索或访问从而从源头杜绝了敏感逻辑或未成熟功能的意外泄露。当用户 A 确认其 Agent 具备推广价值时可发起“公开申请”。在资源管理界面用户需点击“公开资源”按钮。此时系统不仅会触发审批流还要求用户填写简要的功能说明与应用场景以便管理员评估。审批请求将实时推送至拥有相应权限的管理员工作台。管理员在收到通知后可查看 Agent 的详细元数据、潜在风险评级及用户描述。经过合规性与安全性审核后管理员执行“批准”操作。一旦审批通过系统将自动更新该资源的访问控制列表指定的用户组即刻获得查看与使用权限无需人工逐个配置。这一机制既保留了开发者快速迭代的自由度又通过中心化审批确保了企业级应用的分发规范。它不仅降低了内部工具推广的门槛更构建了一道坚实的安全防线。4.构建企业 AI 时代的操作系统AgentRun 开放平台的推出标志着企业 AI 应用进入了一个新的阶段从野蛮生长走向有序治理从单点试用走向体系化运营。4.1 合规与审计的可追溯性通过三层多租户体系和完整的生命周期管理平台记录了每一个 Agent 的创建者、修改者、使用者以及所有的交互日志。当面临合规审查时企业可以轻松导出报表回答“哪个团队创建了多少 Agent”、“某个 Agent 在何时访问了哪些敏感数据”等问题。这种可追溯性是企业规模化应用 AI 的法律与安全基石。4.2 降本增效的量化实现精细化的配额管理和节省模式使得企业能够将大模型调用成本控制在合理范围内。据初步测算通过合理的配额限制和资源回收机制企业可降低 30%-50% 的非必要 Token 消耗。同时自助式的服务模式大幅缩短了 Agent 的开发与上线周期提升了业务响应速度。4.3 激发全员创新的文化氛围当安全与成本的顾虑被平台化解后业务人员不再畏惧尝试新技术。低门槛的使用体验和丰富的模板库鼓励更多非技术人员参与到 Agent 的创新中来。这种全员参与的文化氛围将是企业在 AI 时代保持竞争力的核心源泉。结语AgentRun 开放平台不仅仅是一个技术产品它是 AgentRun 为企业量身打造的AI 业务操作系统。它以AgentRun 为坚实底座以员工权限管理为核心纽带巧妙地平衡了安全合规与敏捷创新之间的矛盾。对于渴望在 AI 浪潮中乘风破浪的企业而言选择一个具备完善治理能力的中台系统比单纯追求模型的参数规模更为重要。AgentRun 开放平台所提供的隔离、权限、流程、角色分工、成本与安全六大核心价值正是企业从“能用 Agent”迈向“能管好 Agent”最终实现“用好 Agent”的必经之路。在未来随着 AI 技术的进一步演进这样一个具备高度弹性、安全性和可扩展性的中台系统必将成为企业数字化基础设施中不可或缺的一部分。了解更多阿里云 AgentRun 产品文档AgentRun 控制台https://functionai.console.aliyun.com/cn-hangzhou/agent/runtime
