作者：李国强
过去一年里，Agent 的发展可以说是风起云涌，有非常多的落地案例以及新技术出现。到底在 Agent 的落地场景中有哪些核心场景，以及现在 Agent 的形态有什么发展趋势？
从我来看，在 Agent 的发展过程中，从去年的万众创新、要去创建更多的 Agent，到了今年，大家对于 Agent 的期待会更加理性，到了一个要结果的阶段。
Agent 落地场景及形态趋势
从场景来看，会有两类大的场景。第一类就是职能岗位的智能化，非常典型的场景就是个人桌面助手、数字员工以及软件研发的智能化。在这个场景里，它有一些比较显著的特征。第一个就是它面向企业内部全员，包括技术人员和非技术人员，所以在做这件事情的过程中，需要考虑非技术人员能不能低门槛、便捷地用到 Agent，甚至是一些非技术人员能不能快速创建 Agent。在这个过程中，企业需要考虑怎么能够把个人的效率提升变成企业的效率提升，以及当每个人有很多智能体的时候，怎么实现桌面端和云端智能体协同。这是在这个场景里的核心特征。对企业来说，它最后验收的结果就是：人效的提升。
在这个场景之下，如果看 Agent 的形态，大致有两类。第一类就是今年年初从 OpenClaw 开始的各种各样的开源 Harness。很多技术实力强一点的企业，会基于这些开源 Harness 框架，为自己的企业员工构建一些智能体。另外一类，就是今年各大厂商推出的非常多的商业化通用 Agent，比如我们阿里的千问办公，其实就是这一类面向职能岗位智能化的典型智能体。
另外一类智能体场景就是业务场景智能化。从去年开始，所有企业都在探索怎么能让智能化能力融入自己的业务中，真正带来业务结果。今年也是一样，典型场景包括智能客服、智能物流、营销、音视频等等。我能看到，今年在场景的丰富度上比去年已经多了非常多，基本上每个行业都能找到一些和业务紧密相关联的场景去落地。
企业级 Agent 的新特征
首先，它不仅仅需要技术参与，业务人员在这个过程中的参与度也非常高。不管是一开始的业务场景探索和整体构建，还是更关键的、智能体上线之后的效果持续调优，都需要业务人员深度参与。在技术特征上，对于复杂场景，往往需要做主子智能体的多智能体协同。在业务场景里，企业也会更加关注安全、合规、隔离等能力。从效果来看，最后企业验收时往往会和直接的业务指标挂钩。举个例子，在客服场景里，客户满意度有没有提升？人工介入的比例是不是降低了？企业会用最直接的业务指标去衡量智能体的结果。
从类型来看，它更加丰富，因为往往在这个场景里复杂度更高。有一些简单场景，可以直接用开源 Harness 去实现，写点 Skill，稍微配置一下，可能就能解决。真正复杂的场景里，用高代码模式编写智能体仍然非常常见。还有一类，可能大家也会注意到，就是工作流这种形态。去年工作流非常火爆，有很多开源方案，但到今年，它明显处于收敛、热度降低的状态，会更聚焦到对确定性要求很高、合规要求也很高的场景里。所以基本上来讲，今年 Agent 就收敛成了这三种形态。
去年和今年跟很多客户聊下来之后，我们有一个感受，就是 Agent 构建本身的门槛越来越低，对于很多企业来讲，已经不是最难的事情了。什么是后面更难的？就是在规模化拿到业务结果的时候，怎么做好协作、沉淀、进化和治理，其实是很多企业拿到业务结果的关键。
比如第一个点，协作。前面也讲到了，在复杂场景里，必然会涉及多个智能体。这多个智能体到底以什么样的形态协作？它们之间要不要做好上下文隔离？如果是一个复杂的长程任务，对这种多智能体的协作是不是看得清楚，能不能及时人工干预？这些是在协作里要做好的关键。
企业资产的沉淀也很重要。能不能把个人的经验和能力变成企业级的经验和能力，以及在资产沉淀的时候能不能做好把控，也是很关键的一个点。
进化这件事情，也是智能体和传统应用非常不一样的地方。对于传统应用来说，上线可能是非常重要的一个节点。对智能体来说，上线只是第一步，之后如何基于线上的用户反馈持续进化，是拿到结果的关键。
最后，很多企业也会看到，安全和成本的底线没有变。智能体比以前更聪明了，具有更强的自主性，也就意味着它带来安全问题的可能性更大了。怎么做好安全以及成本可控，这四个点是我看到的今天企业在规模化落地、要结果的过程中需要重点关注的点。
阿里云 AgentCore 能做些什么？
AgentCore 的目标，就是一个一站式的企业级 Agent 构建与治理平台。一方面，它会帮助用户快速把智能体构建起来，支持各种各样的构建类型，包括前面讲到的基于高代码编写的智能体，或者基于流行的 Harness 快速把一个智能体运行起来。如果客户已经有一些智能体跑在线下或者桌面端，有没有办法把它们纳管在一起，形成一个统一的管理面？这些方面能够帮助用户快速把 Agent 的构建过程运行起来。
构建过程中，我们也会把阿里云各种各样的重要基础设施，在 AgentCore 平台上为大家一站式提供，包括沙箱能力、记忆能力、知识库能力、模型连接等等。这些都会作为构建用的基础设施，在平台上统一管理，供给上层智能体使用。
智能体有了之后，治理是刚才讲到的比较关键的环节。这上面包括智能体的可观测性、后续的评估优化，是不是每一个 Agent 都会有一个唯一的身份来标识它，资产怎么管理，以及安全、审计、协作等等一系列能力。只要把智能体运行在 AgentCore 平台上，或者被它纳管，都能够默认开启企业级的治理能力，让企业真正管得住，并且能够把它治理好。后面我会分部分和大家做一些分享。
Agent 的构建与运行
首先说一下 Agent 的构建与运行。简单来讲，企业大致可以有两类构建模式，一种是复杂的高代码模式，一种是偏无代码的模式，在 AgentCore 里都进行了支持。
在高代码创建模式下，用户可以继续选择任何一个已经用得比较习惯的开源 SDK，比如比较流行的 LangChain，还有阿里开源的 AgentScope 等等，都可以选择。对于用户的高代码框架没有任何绑定，用户可以用任何自己习惯的框架。同时，AgentCore 也会提供自己的一套 SDK，降低用户使用平台内 Skill、模型、凭证等等这些资产的门槛，进一步加速企业构建 Agent 的速度。
从部署角度来讲，其实和传统的软件流程是一致的。你可以用代码的方式、镜像的方式、CI/CD 的方式，真正把一个 Agent 像一个软件一样在你的体系里管理起来。
对于一些非技术人员或者门槛要求低的模式，我们提供了托管 Harness 这种纯粹的无代码模式去运行一个 Agent。我们支持像阿里开源的 Qwen-Paw、Qoder CLI 等多种 Harness 形式进行托管。用户简单做一些 Skill 配置、提示词配置、MCP 配置之后，就可以把这个智能体运行起来了。所以这两种模式，可以认为是最主要的构建智能体的模式。
纳管可以覆盖平台之外的智能体，包括桌面端的智能体。纳管进来之后，一方面，它可以成为 Team 模式以及主子智能体协作的对象；另一方面，它也可以实现在平台上的统一观测和治理能力。所以这三类是今天 AgentCore 支持的构建方式。再往后，我们还规划了快速创建模式和注册模式等等。
同时，这个平台也提供了全托管的运行环境。也就是说，当你把 Agent 构建、运行起来之后，用户不需要关心底层的运行环境到底是什么，只需要关注 Agent 自己的生命周期。平台会为 Agent 创建一个完全隔离的沙箱，并且和 Agent 的生命周期紧耦合在一起。其中包含极致的弹性，可以根据负载情况伸缩，以满足客户诉求，并且在性能和成本之间构成一种平衡。还有版本管理、灰度发布等等能力，在运行态都是完全提供的。
在集成方面，当你构建完一个 Agent 之后，一定会需要集成到已有系统中使用。这时候，平台支持标准的 AG-UI 协议、A2A 协议，包括和我们的 IM 机器人、钉钉打通，这些都是平台默认提供的能力，可以快速让我们构建出来的智能体被自己的系统使用起来。
Agent 的协作
协作也是非常重要的一点。构建完成之后，因为前面讲到了，随着任务复杂度逐渐提升，如何做好协作很关键。我也总结了一下，现在市面上能看到的、面对不同场景的协作模式，我把它总结成了三类，和大家做一些分享。
首先第一类，当智能体接到一个复杂任务时，它发现其实可以拆解成多个相同的、可并行执行的任务。比较典型的是，当我去做一些市场调研时，可能会发现有多个方向需要调研，这时通过 Harness 内置的 Sub-Agent，可以快速创建多个智能体并行执行。这些智能体会共享主智能体的上下文、权限等能力，执行完之后做一个汇总。所以这是第一种，叫即时并发型协作模式。这种模式往往在 Harness 框架中默认支持。
第二类，我称之为按需编队。就是当我的智能体运行时，它可能会有几个确定的步骤，先做什么，再做什么。比如说我要编写一篇文章，先要做调研，然后做写作，最后还要做审查。这时可以通过预先布置的一些 Agent 模板，按顺序拉起一些 Agent，完成这些工作，最后实现协作。在这种情况下，子 Agent 的生命周期和任务是完全关联的。
还有一种更常见的情况，就是在企业内部，当我把一种能力服务化并且固定化之后，会沉淀出非常多长期运行的数字员工。比如刚才讲到的研发场景里，可能会有一个长期运行的 Agent，扮演产品经理的角色。它具有相关权限，可以访问一些内部系统；同时，我可能要对这个角色进行长期观测以及进化，这时就适合用长期数字员工的方式去构建它。每个智能体需要执行子任务时，就会调用这些长期数字员工完成自己的任务，实现主子智能体协同。所以这三种模式，是我看到的企业内部各种场景落地过程中最常见的三种协作模式。
AgentCore 的协作模式
在 AgentCore 里面，协作方面我们提供了一种最典型的 Team 模式，称为多人多智能体协作，它把人和智能体放在对等的位置。人和智能体可以在同一个工作中实现协作。这张图呈现了一个常见形态，比如今天在部门内部有多个人类员工，同时我把不同任务拆解给两层不同的 Agent。第一个 Agent 是 Leader Agent，往往负责直接和人类员工交互，承接任务、拆解任务，以及把任务分配给更加具体的每一个 Worker Agent。就像这张图上看到的，大多数情况下，人是和 Leader Agent 交互的，而 Leader Agent 会负责和 Worker Agent 交互，观测它的状态，做一些纠偏以及反馈。所以在这种架构之下，能够更好地实现多智能体协同。
在多智能体协同中，我们观察到一个现象：对于长程的多智能体任务，长期执行过程中还是可能发生偏差。所以在这种情况下，企业对于长程的多人多智能体协作的可见性、透明性和可干预性要求比较高。也就是说，执行到一半，我想知道到底执行得怎么样；如果有问题，我能不能及时纠偏。针对这种场景，我们设计了一个类似群聊或者叫数字会议室的模式。在这个模式之下，所有智能体之间的交互和产出，都会以聊天的形式透明地呈现给用户。
还有一个更重要的点，因为人与智能体在这个模式下是对等的，人可以在任何时间像与一个智能体聊天一样，对它进行干预。比如执行过程中，你认为它有点跑偏了，可以直接 @某个智能体，告诉它要聚焦到哪个点，不要去做什么。这让整个长程任务的多智能体协作的透明性、可见性和可控性变得非常好。所以，这是我们看到的企业内部落地复杂任务的多智能体协作时，一个最佳实践模式。
多 Agents 协同下的上下文工程
上下文这件事情也非常关键，它涉及协作和沉淀两个方面。首先，在 AgentCore 里面，我们和阿里云的多款知识库和 Memory 产品进行了集成。比如知识库方面，我们默认集成了阿里云的百炼知识库以及 OTS 知识库。用户只需配置一次知识库连接，就可以非常便捷地用在所有智能体里。Memory 也是一样，通过 MCP 协议，我们可以对接阿里云的 OTS 记忆、PolarDB 记忆等，使用起来非常便捷。同时，AgentCore 也自带了一个记忆服务，对于一些想简化使用的用户也非常方便。它是整个上下文工程的底层服务能力，用户可以直接使用。
同时，在规划中我们看到了一些未来趋势，也正在做一些事情。我们发现，记忆和知识的边界正在变得模糊。我们的长期记忆很多是从对话历史中提取出来的，长期记忆通过不断沉淀，其中有一些东西可以进一步沉淀成知识库和 Skill。这在业界已经越来越多地被企业实践。所以在上下文工程方面，我们规划做一件事情：如何把线上每天执行的任务中有价值的东西，自动沉淀为我的知识库和 Skill。再往上一层来讲，当知识库和记忆逐步融合之后，如何在统一层面做上下文管理，比如对整个记忆和知识库做混合检索，包括语义的构建，这对于最终提升 Agent 的效果非常关键。
还有一个方面，在多人多智能体协作模式下，对于记忆和知识库，我们要做好更好的权限隔离。有些时候，我们希望这些记忆能够被多个智能体共享，让它们能够更清楚地了解上下文；但有些情况下，我又希望做比较好的隔离。这一层我们都会在上下文工程中进行构建。
Agent 资产管理
点击查看视频：mp.weixin.qq.com/s/myyCv_CuE...
Agent 资产的沉淀也比较关键。到底有哪些资产在企业内部？我总结大概有四类，就是 Skill、MCP、模型和 Agent 模板，它们承载的作用不一样。首先说一下 Skill。对于很多企业来说，Skill 正逐渐变成其核心业务的描述。以前，当我们要实现一个业务时，往往需要写代码。最常见的情况是，我向研发提一个需求，研发写一段代码把这个业务实现。但今天，Skill 以及模型语义理解能力的提升，让所有人都可以用自然语言描述需求，并且能够直接上到生产执行。Skill 就是最核心的载体。所以对于企业来说，我能看到一些企业里 Agent 已经变得不重要，甚至 Skill 变成了最重要的业务逻辑承载者。
这时，我们就需要一系列体系来管理企业内部的 Skill，包括建立企业内部私有的 Skill 市场，做好企业内部 Skill 的管理和流动，以及把 Skill 本身作为核心业务资产、核心 SOP 来沉淀。它的版本管理、安全扫描、权限控制、评估调优，这一系列需求都会出现在平台里，我们会支持用户做这些事情。
工具连接方面，MCP 是 Agent 和外部世界的连接。同样，我需要有一个市场来承载 MCP，供内部使用。这里面包括如何把存量业务，比如原来是 RESTful 的业务，快速变成 MCP，给我的 Agent 使用。更重要的一点是，MCP 的权限控制会成为这里面的关键。模型连接也是一样，当企业足够复杂时，我们会发现，企业不同部门、不同 Agent 能用的模型连接和供应商是需要区隔的。这时，如何对多供应商进行统一管理，以及按照不同 Agent、不同部门的需求定义模型列表，这些能力也需要提供给用户。在运行时，模型调用的智能路由、降级、流控、限额，都会是需要关注的点。
最后，Agent 模板也是一样，它往往是企业一些最佳实践的沉淀，内部包含了 Soul、Skill、MCP 等。能不能基于模板一键克隆出一个 Agent？这一系列能力，都是在企业整个层面上拉平这些能力的关键。
Skills 企业级生命周期管理
Skill 这个方面，我想重点和大家分享一下。前面也讲到了，很多企业已经把 Skill 作为一种核心资产进行管理，它在企业内部的整个生命周期越来越像软件资产。所以在这张图里我们也呈现了，未来对企业来说，Skill 的所有管理流程会和原有的软件核心资产一样。比如从开发阶段开始，要提供多样的 Skill 开发方式，手工编写、AI 生成或者打包知识上传等方式，在 AgentCore 里都可以支持。之后，基于 AgentCore 内置的 Nacos，可以实现 Skill 的多版本管理以及变更记录留痕。
所有 Skill 在上线之前都要进行安全扫描。大家都知道，Skill 本质上大概由两类文件构成：一类是描述性文件，用来描述我的 SOP 和业务逻辑；还有一类是脚本。对于这些内容，静态代码扫描、依赖漏洞检测和提示词注入审查都很关键。如果 Skill 的描述里有一些恶意内容，可能会给生产带来非常严重的问题，所以安全扫描这件事也很关键。
再往后是 Skill 如何分发。是分发给企业员工的本地智能体使用，还是分发到特定的 Agent 里面？这里面的分发方式和权限管理，在 AgentCore 里面也进行了全面支持。最后，评估调优也是一样的。当 Agent 变成一种固化的通用 Agent 之后，Skill 本身的调优反而成了关键点。所以，从开发阶段一直到后续整个流程，要形成一个完整的生命周期，在 AgentCore 里面帮助用户把这件事情做好。
企业内资产的 Catalog 管理
资产沉淀离不开 Catalog 管理。总要有一个地方承载我的这些资产，并且做好共享和管理。从我的观点来看，在企业内部，资产至少有三层管理模式。首先，我们要支持每个员工的创新和使用。他要能够创建自己的 Agent，创建自己的 Skill，解决自己的问题。这些 Agent 的权限范围和可见范围只有用户自己。其中比较优秀的，可以申请成为企业内部共享的资产，这时我们就需要一个企业级的 Catalog。这里面的来源可能是前面讲的，某个员工做了一个很好的 Skill，想分享给整个企业；或者按照部门推出一些部门级的 Skill，比如财务部门推出的一些 Skill，这些都是来源。
另外，还有一些从外部市场引入的资产，需要放在我的企业 Catalog 里面。企业 Catalog 本身的上架审批流程管理、安全扫描和权限管理，都会是这里面比较重要的。外部市场引入刚才也提到了，比如阿里云有自己的官方 Agent、官方 Skill，企业可以选择性地引入内部。所以从这三层来看，我认为这是企业内部做资产沉淀时非常关键的设计。
在 AgentCore 里面，我们通过权限隔离的方式，也实现了个人和企业两层 Catalog 的管理。Catalog 管理也有一些很重要的元素，包括元数据管理、权限管理、上架标准，以及后期的经营，也就是我的这些 Skill 有没有人在用、调用方多不多、SLA 好不好。这些内容在整个 Catalog 里面也很关键。
Agent 观测与持续优化
进化这个话题前面也提到了，Agent 上线之后，如何做好它的持续演进和进化是很关键的。AgentCore 集成了 AgentLoop 这个产品里的观测和持续优化能力，帮助用户在整个生命周期里，以数据飞轮的方式持续提升自己的效果。关于数据飞轮，我也做一个简单的分享。一开始，我需要把线上运行的 Agent 的所有数据采集下来，要看清楚 Agent 执行的每一步：什么时候调用了模型，什么时候调用了工具，什么时候做了知识库召回。
所有这些信息都要采集下来，作为后续分析和评估的数据基石。有了这些数据之后，就可以做一些基础分析。刚才讲到，我的 Agent 效率到底高不高，一个简单的办法就是看执行这个任务进行了多少轮，每轮用了多少工具。这是非常容易从观测数据中分析出来的 Agent 效率。效率之后，还有一个很重要的问题，就是怎么看它的效果。
效果这件事情在 Agent 时代发生了一个本质变化：因为大模型的随机性，所有输出都是随机的，没有办法通过确定性的规则进行评估。这时候就引出了评估这个概念，我们需要引入模型的能力，对线上执行的效果进行评估。在这个过程中，我会发现线上效果好与不好等各种各样的 case。引入内部专家之后，我会形成优化建议，再次上到线上。所以整个过程是 Agent 效果提升的一个核心数据飞轮，要做好采集、分析、评估、优化这一整套步骤，才能让我的 Agent 不断往前进化。
Agent 观测实现洞察与分析
借助阿里云的可观测能力，可以实现对市面上所有流行框架和平台的支持，包括大家能叫得上来的 OpenClaw、Hermes、Dify、AgentScope，这些能力全都是默认集成的。在 AgentCore 里面也是一样，默认集成了可观测能力。只要把 Agent 部署在这个平台上，它的数据采集就能完成。
之后在分析层面，前面也分享到了，你可以非常容易地看到每一个 Agent 的多轮调用到底发生了什么。做单点问题诊断的时候可以用这个，你可以看到它的性能指标，看到这次执行的时长是多少，还可以进一步细分到模型调用时长、工具调用时长等。这些都可以在这里做到，Token 成本分析也是一样。我可以看到每次调用了多少 Token，你就可以生成一个关于成本的分析大盘。这些在分析阶段都是能够做到的。
Agent 的评估器设计
另外一个很重要的点，就是效果评估这件事情，已经有非常多企业在实践。我们在和企业交流的过程中发现，这里面最大的痛点就是人工评估占比太高。如果涉及一项业务的评估，评估的人要懂业务规则，这时候往往就需要我的业务专家。业务专家人数有限，在上线初期、业务量不大的时候，还有这种可能性：我每天在线上抽取一些执行情况，请业务专家做人工标注。我相信很多企业现在都在做这样的事情。但大家想一想，当我的线上调用量变到十万、几十万、上百万的时候，人工标注是不是就变得完全不可行？所以这时候，自动化评估器就成了效果评估能否规模化的一个非常关键的点。
现在市场上的评估器大概有三类。
第一类是 LLM-as-a-Judge，就是我把一次调用直接丢给大模型，让它帮我判断。这种方式往往用于语义层的校验，比如模型对问题的回答与问题的相关性是不是好。这种纯语义层面的判断，用大模型直接作为评判器是可以的。
第二类是 Code-as-a-Judge，就是用代码做评估器。比如对于确定性的业务规则，包括数字校验、是否出现了特定的词，Code-as-a-Judge 是可以的。但是，只要评估和业务规则相关，LLM-as-a-Judge 和 Code-as-a-Judge 都搞不定。这时候就必然会引入 Agent-as-a-Judge 这种新型评估器的逻辑，有点像用魔法打败魔法：线上业务关联性很强，我就只能用一个带有业务属性的 Agent 去评估它。我们可以把企业内部的私域知识、自己的工具以及专家的评判规则，都沉淀到这个 Agent 评估器里面。
在我们和一些客户的实践过程中发现，通过 Agent-as-a-Judge，它的准确率和专家人工标注大概能达到 90% 以上的一致性。在后续的线上持续评估中，用这样的评估器基本可以替代人工评估。也就是说，前期我的业务专家要参与 Agent-as-a-Judge 的创建阶段，到了后续使用这个评估器时，基本上就不需要再做人工标注了。这对于后续 Agent 在线上的持续进化、持续发现问题，包括发现问题之后形成告警，都是非常关键的基础设施。
这些能力都在 AgentCore 里面提供给用户。包括 Agent-as-a-Judge 的创建过程，我们也采用了 AI 的方式，业务专家可以通过自然语言描述把这个 Agent 创建出来。
Agent 的治理：身份与安全
最后一个话题是治理。前面讲到了，安全和成本已经成了非常重要的关注点。在 Agent 的世界里，它越来越像一个独立的个体，所以首先要为 Agent 创建一个独立的身份。借助阿里云的 Agent Identity 能力，所有在 AgentCore 里面创建的 Agent，我们默认都会给它一个身份，也就是它的唯一标识。同时，在之后的权限校验中，我们会基于 Agent 的身份，单独定义它的权限和校验规则。
在"入"和"出"两个方向上，我们同时也提供了权限管理。第一个是"入"，问题非常简单：这个用户有没有权限调用这个 Agent？这就是"入"要回答的问题。在这里，AgentCore 实现了和企业 IDP，也就是身份供应商的默认集成，可以支持钉钉身份、飞书和企微身份，以及企业内部身份系统的对接，完成能不能调用 Agent 的权限校验。
第二件事情是 Agent 能干什么，比如能不能调用这个 MCP，能不能访问某个外部系统。在 AgentCore 里面，这也是通过内置的 AI 网关完成的。它可以详细定义这个用户有没有权限调用这个 MCP、这个 Agent 有没有权限调用这个 MCP，实现全方位管控。同时，所有调用过程都通过可观测形成了 Tracing，可回溯、可审计。当线上真的出现问题，你发现有一个东西被 Agent 改了，就可以看到到底是哪个 Agent 干的，以及是不是某个人通过这个 Agent 干的。这样的安全性要求，在一些大型企业客户的落地中已经成了一种刚需。
Agent 的治理：成本
成本也是一样。前面讲到，通过 Agent 的可观测，我们可以看清楚成本：每次请求用了多少 Token，每一个 Agent 用了多少 Token，每一个用户用了多少 Token，通过可观测数据都能看清楚。看清之后有两个关键的事情。
第一是设置告警，因为等你到月底看账单的时候，其实已经为时已晚。所以在成本这件事情上，看清之后第一件事情就是做告警。借助 AgentCore 里的观测能力和后续的告警能力，我们可以支持告警。第二件事情是要能控制住：当超过阈值之后，能不能直接不让它使用？借助内置 AI 网关的能力，我们可以定义明确的规则，这个用户只能用多少 quota，这个 Agent 只能用多少 quota。当超过 quota 之后，我们可以采取动作，比如限流、降级、阻断。这些能力在 AgentCore 里面通过内置 AI 网关提供给用户，让用户真正对成本看得清、控得住。
AgentCore Demo
点击查看视频：mp.weixin.qq.com/s/myyCv_CuE...
最后再回到 AgentCore 的定位，它到底在做什么？它就是企业级的 Agent 构建与治理平台。最底层的构建是基础设施能力，可以帮助企业快速完成构建。但更重要的是，在企业的规模化落地中，我们通过协作、沉淀、进化和治理，帮助用户拿到最终的业务结果。
欢迎加入 AgentCore 服务群，钉群群号：185130001370。