用 Nacos 3.3.0 ARD 让 Agent 按任务发现工具和 Skill

作者:席翁

如今,工作中用 Agent 帮忙已经越来越常见。研发同学用 Coding Agent 写代码、补测试、排查问题,业务同学用 Work Agent 整理资料、分析表格、制作演示文稿。不少过去需要自己一步步操作的事情,现在可以把需求交给 Agent,让它协助完成。

月底的经营汇报就是一个例子:看看华东区这个月卖得怎么样,和上个月比有哪些变化,再整理成几页 PPT。这类任务很适合让 Agent 帮忙。

不过,在 Agent 开始干活之前,员工往往还得自己做不少准备。

一份经营汇报背后的准备工作

假设 Agent 还没有接入公司的销售系统。你得先找数据团队,说明要查华东区哪两个月、需要哪些指标,请他们导出 Excel 或 CSV。拿到文件后,再确认字段含义、检查数据有没有缺漏,才能交给 Agent。

有了数据,还得交代怎么分析。销售额按下单还是按回款统计?退款要不要扣除?产品之间的增减怎么比较?一张表并不能告诉 Agent 这些业务口径,你还需要把计算规则和注意事项写进 Prompt。

到了做汇报的时候,又要说明一共几页、先讲哪些指标、图表用什么格式、哪些问题要单独列出来。来回调整几次后,你可能会把这些要求存成本地模板,或者整理成 Skill,留到下个月继续用。

自己一直用同一个 Agent,暂时还能管得过来。一旦换了电脑或 Agent,就得重新找文件、复制 Prompt、安装 Skill,再确认是不是上次改好的那一份。

多人一起做时更麻烦。你负责华东,同事负责华北,各自让 Agent 生成汇报。等到合并时才发现,一份按回款算销售额,另一份按订单金额算;一份先讲产品,另一份先讲渠道,图表样式和页数也不一样。区域可以分开分析,统计口径和汇报格式却得统一,否则还要返工。

规范其实一直都在,只是散在人的脑子里、之前的对话中,以及各自电脑上的 Prompt、Skill 和模板文件里。最后用了哪套规则,往往取决于谁来做、用哪个 Agent 做。

团队可以把销售数据查询做成 API,或通过 MCP 提供给 Agent,再把分析口径、汇报结构整理成 Skill 和 Prompt,供大家复用。

这些资源准备好以后,员工仍然得知道有哪些服务可用、地址在哪里、哪份 Skill 适合这次任务、团队现在用哪一版规范,再逐个交给 Agent。

如果 Agent 能根据需求,自己去团队资源库里寻找数据接口、MCP、Skill 和 Prompt,员工就可以直接说“帮我做华东区这个月的经营汇报,和上个月对比,按团队规范整理成 5 页 PPT”,让 Agent 查找合适的资源,获取有权访问的数据,再按团队的分析口径和汇报要求继续工作。

负责华东和华北的同事可以各自分析,复用同一套规范;即使换了 Agent,也有共同的资源入口。

Nacos 3.3.0 新增的 ARD 资源发现提供了这样的入口:让 Agent 按当前任务搜索 Nacos 中的 Agent、MCP、Skill 和 Prompt,再按各类资源的使用方式继续操作。(Nacos 3.3.0 发布介绍 [ 1] 。)

ARD 给 Agent 一个找能力的入口

ARD 的全称是 Agentic Resource Discovery,是一套描述、搜索和发现 AI 资源的开放规范,通过 ARD 官网 [ 2] 发布,在 GitHub 仓库 ards-project/ard-spec [ 3] 中公开维护。

参与制定规范的工作组成员来自 Microsoft、Google、Hugging Face、GoDaddy 等公司。目前规范仍处于提案阶段,社区可以通过公开仓库参与讨论和完善。(工作组介绍 [ 4] 、规范正文 [5 ] 。)

使用时,Agent 把任务需求交给资源库,资源库返回候选项,说明每项资源叫什么、能做什么、属于什么类型,以及从哪里获取内容。能找的资源包括:

资源放到日常工作里是什么
MCP查询销售数据、读取工单、访问业务系统的工具服务
Skill分析销售变化的方法、生成团队文档的规则
Prompt可以复用的任务指令和输出要求
Agent已经部署好、可以承担一类任务的远程助手

找到资源后,Agent 仍需按对应协议或内容格式使用:连接 MCP 服务,读取并遵循 Skill,或按远程 Agent 支持的协议发起调用。(ARD 协议介绍 [ 6] 。)

使用者先接上资源库,需要时再找与当前工作有关的工具和规则,不必在任务开始前全部准备好。前提是团队已经接入服务、整理好规范;ARD 帮助发现和复用已有资源,不能凭空补出尚未建设的能力。

Nacos 3.3.0 把资源管理和资源发现接起来

如果团队已经用 Nacos 管理 MCP 或 Skill,可以继续通过控制台和管理接口创建、更新、发布资源,维护好描述,无需为 ARD 另建一份资源清单。

ARD 从中检索最新的在线版本,并按调用者身份和资源可见性筛选。草稿、已下线的版本,以及调用者无权读取的内容,不会出现在候选结果中。维护者发布的资源,由此有了 Agent 可以直接搜索的入口。(Nacos AI Registry 适配器规范 [ 7] 。)

image

检索默认使用关键词,也可以选配向量检索及 JEV 模型辅助判断。可以先用关键词搜索,等资源多了、需要处理更自由的问法时,再配置向量检索和 JEV 模型。向量模型、向量存储和 JEV 模型需要另外配置,开启 ARD 不会自动完成这些配置。

从找资源到交付一份经营汇报

假设数据团队已经开发好销售数据 MCP,并发布到 Nacos。我们之前在 Agent 里反复调整的分析方法和汇报要求,也分别整理成了销售分析 Skill、经营汇报 PPT Skill,发布在同一个资源库中,供团队成员使用。

这时,我们开启一个全新的 Codex 会话,通过 ARD 项目的 AgentFinder Skill [ 8] 接入这个“企业资源库”。会话已配置发现入口和访问凭据,也具备通用 HTTP 和 PPT 工具。至于本次任务用哪个销售 MCP、哪份分析和汇报规范,就让 Codex 从资源库里查找。

先让 Codex 看看有哪些资源能帮上忙

我们先说明要分析的区域、对比月份,以及汇报的交付形式:

我要做华东区 2026 年 9 月的经营汇报,需要和 8 月对比,最终整理成 5 页 PPT。先帮我从企业资源库找找有哪些合适的数据服务、分析方法和汇报规范。

Codex 通过 AgentFinder 向 Nacos 发起 ARD 搜索,找到了团队提前准备好的销售 MCP、分析 Skill 和汇报 Skill。

image

图 1:Codex 列出找到的三项资源,解释各自的用途,并提供资源入口。

这三项资源各有用途:销售 MCP 可以查询华东区 8 月、9 月的销售额和订单量;分析 Skill 用于计算环比和产品贡献;汇报 Skill 规定了 5 页汇报的结构和统一版式。Codex 把它们与本次需求的对应关系列了出来。

从资源描述也能判断是否够用。销售 MCP 的描述写明没有利润、预算达成率和渠道数据,这次汇报就应围绕它能提供的指标展开;如果还要分析利润,就得继续找数据来源。

这一步已经找到了取数、分析和制作汇报所需的资源入口。具体的计算规则和制作要求,要等获取资源内容后才能读到。

选好资源后,让 Codex 取数并分析变化

确认这三项资源能覆盖本次任务后,我们让 Codex 继续:

就用这些资源,查询两个月的数据,分析主要变化,先把分析结论给我。

Codex 沿返回的链接读取两份 Skill,从 MCP 服务描述中取得连接信息,再连接销售 MCP,调用 query_sales_data 查询两个月的数据。这次就不用另外导出 Excel,也不用把分析规则重新贴进对话了。

image

图 2:分析结果同时列出月度指标、产品变化和后续核查事项,便于检查结论的依据。

结果显示,9 月销售额为 148 万元,比 8 月的 160 万元下降了 7.5%。产品明细解释了这 12 万元的差额:会议耳机减少 20 万元,办公显示器和扩展坞合计增加 8 万元,抵消了部分下降。

截图底部写明了分析口径:销售额按已支付订单金额统计,与上一个自然月比较,产品变化与总变化核对一致。这些要求来自分析 Skill,换同事或换 Agent 来做,也能读取同一份规则。

还需要查清的是,会议耳机的订单为什么减少。Codex 列出了渠道订单、缺货记录等核查方向,我们可以找业务同学确认,再决定是否补充进正式汇报。

分析确认后,再整理成团队要求的 PPT

看过分析结果后,再让 Codex 整理成 PPT:

把这份分析整理成 5 页可编辑的经营汇报 PPT。

先前读取的汇报 Skill 已经规定了每页内容和版式。Codex 按这些要求组织内容,使用现有的 PPT 工具生成文件,不用我们再从头交代。

image

图 3:左侧是交付的 PPT 文件,右侧可以查看封面和五页缩略图。

右侧预览中的汇报共 5 页,采用统一版式,包含经营总览、产品对比和后续核查事项。文字、表格和图表都可以继续编辑,便于补充业务判断,或按评审意见调整。

这次新会话用上了数据团队的查询服务,以及之前在其他会话中积累的分析和汇报经验。以后换同事接手,也可以从 Nacos 找到这些资源,沿用团队的规范。

快速上手

可以先准备一个数据 MCP、一个分析 Skill 和一个汇报 Skill,走一遍上面的流程。案例中的三项资源用于演示,并非 Nacos 内置服务,实际体验时需要自行创建或接入。

第一步 在 Nacos 中开启 ARD

准备一套能正常启动和登录的 Nacos 3.3.0,在服务端 conf/application.properties 中配置:

# 开启 ARD 协议入口,默认关闭
nacos.ai.ard.enabled=true
# AI Registry 适配器的独立端口,默认是 9080
nacos.ai.registry.port=9080
# 共享资源检索默认开启;如果此前关闭过,需要恢复
nacos.ai.resource.search.enabled=true
# 返回给调用者的资源链接所使用的适配器公开地址
# 这里按本机试用填写,跨机器访问时应改成实际可达的地址
nacos.ai.ard.catalog.base-url=http://127.0.0.1:9080

重启服务后,通过适配器端口访问 ARD。默认直连时,搜索地址为:

http://127.0.0.1:9080/v3/ai/ard/search

如果 Agent 在另一台机器或容器里,127.0.0.1 指向的是它自己所在的环境。搜索地址和 catalog.base-url 都要改为 Agent 实际能访问的 Nacos 适配器地址;如果经过网关并设置了路径前缀,地址也要带上完整前缀。

使用外部数据库或从旧版本升级时,需要先完成 3.3.0 对应的数据库脚本更新,包括 AI 资源检索所需的表。配置项与接口路径可查阅 3.3.0 适配器规范 [ 9] 。

第二步 把资源准备好并发布

在 Nacos 控制台创建或导入资源:为 MCP 配置可用的服务连接信息,为 Skill 上传内容,再发布上线。用于调用的账号需要有这些资源的读取权限。

写资源描述时,可以想想别人会怎么找它。比如销售 MCP:

按区域和月份查询销售额、订单量及产品明细,适用于月度经营分析和环比对比。

分析 Skill 可以这样写:

统一月度销售分析口径,计算销售额环比和各产品的增减贡献,列出需要进一步核查的问题。

只写“销售工具”或“分析助手”,人和 Agent 都难以判断是否适用。比起取一个好名字,写清业务范围、可查询维度和适用任务往往更有用。

发布后,资源索引需要一定时间更新。如果刚上线还搜不到,可以稍后重试,同时检查命名空间是否正确、是否已有在线版本,以及调用账号是否有读取权限。

第三步 让 Agent 接入企业资源库

把 AgentFinder Skill 放进所用 Agent 支持的 Skill 目录,就可以让它按这份 Skill 查找资源。Agent 还需要具备发送 HTTP POST 请求的能力。

AgentFinder 在 ~/.agentfinder/finders.json 中保存资源发现服务和当前选中的资源库。首次配置可以这样写;如果文件中已有其他条目,保留它们,追加企业资源库并更新 selected:

{
  "selected": "nacos-team",
  "finders": [
    {
      "id": "nacos-team",
      "name": "企业资源库",
      "description": "团队在 Nacos 中维护的数据服务、分析方法和工作规范",
      "search": "http://127.0.0.1:9080/v3/ai/ard/search?namespaceId=public"
    }
  ]
}

search 填完整搜索地址,namespaceId 换成资源所在的命名空间 ID。这个示例只保存发现入口,访问凭据需要由 Agent 的 HTTP 工具或连接配置携带。

配置好后,就可以向 Agent 提出需求:

使用 AgentFinder,从已配置的“企业资源库”查找资源。
通过当前环境配置的凭据访问 Nacos。
我要做华东区 2026 年 9 月的经营汇报,和 8 月对比,
最后整理成 5 页 PPT。
先找能查询销售数据的 MCP、规定分析口径的 Skill,
以及团队经营汇报的格式规范,列出它们分别能帮我做什么。

找到合适的资源后,再根据任务读取 Skill、接入 MCP 或调用远程 Agent。需要生成 PPT 时,还得准备相应的文件生成工具。(AgentFinder 配置与发现流程 [10] 。)

也可以先用 HTTP 验证搜索

直接请求搜索接口,可以先确认服务端能否返回资源。下面以 Nacos 默认鉴权插件的 Bearer 令牌为例,假定本地环境变量 NACOS_ACCESS_TOKEN 中已有有效令牌:

curl --fail-with-body --silent --show-error \
  'http://127.0.0.1:9080/v3/ai/ard/search?namespaceId=public' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${NACOS_ACCESS_TOKEN:?请先配置有效的 Nacos 访问令牌}" \
  --data '{
    "query": {
      "text": "销售"
    },
    "pageSize": 5,
    "federation": "none"
  }'

federation: "none" 表示本次只查询当前资源库。先用资源名称或描述中已有的关键词搜索,便于检查入口、权限和索引是否正常。接入向量检索后,再试试不同自然语言问法的检索效果。

搜索响应的候选资源位于 results 中,可以先看这四个字段:

字段怎么看
displayName找到了什么资源
description它是否能解决当前问题
type应该按哪一种资源格式处理
url去哪里获取这项资源的描述或内容

沿 url 获取内容时,要保留完整链接和参数。Nacos 返回的 Skill 通常是 ZIP 包,包含 SKILL.md 和附属文件。MCP 返回的是服务描述,要从中读取连接信息,再按 MCP 协议初始化、发现工具。搜索结果里的资源链接,不等于业务工具的调用地址。(3.3.0 ARD 资源获取契约 [ 11] 。)

搜索成功后,可以把 query.text 换成自己的任务描述,再按需要增加类型等过滤条件,缩小范围。

搜不到或用不起来时,先检查以下内容

现象优先检查
搜索接口连不上或返回 404是否已开启 ARD 并重启服务,访问的是否为适配器端口,网关路径是否正确
返回 401是否携带有效凭据,令牌是否过期,当前部署采用哪种鉴权方式
请求成功但没有结果命名空间、在线版本、读取权限、索引更新状态,以及查询词是否覆盖资源描述
能搜到但资源链接打不开catalog.base-url 是否从 Agent 所在环境可达,资源获取请求是否也携带所需凭据
能取到 MCP 描述但查不到数据业务 MCP 是否运行、连接信息是否正确,以及业务服务自己的访问权限是否齐备

Nacos 的资源读取权限和业务系统的调用权限要分别满足。能搜到销售 MCP,并不意味着自动获得了它背后所有销售数据的访问权限。

先让一个高频任务用起来

第一次接入,可以从月度经营汇报开始:准备好数据服务、分析方法和汇报规范,让 Agent 通过同一个入口找到它们,完成一次交付。

等流程稳定下来,再逐步把工单分析、项目周报、研发评审中常用的工具和经验放进资源库。

数据同学维护服务,业务同学完善分析口径,团队维护汇报规范。使用者按任务查找和复用这些资源,换一个 Agent 或有新成员加入时,也能从同一个入口找到它们。

相关链接:

[1] Nacos 3.3.0 发布介绍

https://nacos.io/blog/release-330/

[2] ARD 官网

https://agenticresourcediscovery.org/

[3] GitHub 仓库 ards-project/ard-spec

https://github.com/ards-project/ard-spec

[4] 工作组介绍

https://agenticresourcediscovery.org/#who-is-behind-ard

[5] 规范正文

https://agenticresourcediscovery.org/spec/

[6] ARD 协议介绍

https://agenticresourcediscovery.org/spec/

[7] Nacos AI Registry 适配器规范

https://github.com/alibaba/nacos/blob/3.3.0/specs/zh-cn/ai/ai-registry-adaptor-spec.md

[8] AgentFinder Skill

https://github.com/ards-project/ard-connectors/tree/main/skills/agentfinder

[9] 3.3.0 适配器规范

https://github.com/alibaba/nacos/blob/3.3.0/specs/zh-cn/ai/ai-registry-adaptor-spec.md

[10] AgentFinder 配置与发现流程

https://github.com/ards-project/ard-connectors/blob/main/skills/agentfinder/SKILL.md

[11] 3.3.0 ARD 资源获取契约

https://github.com/alibaba/nacos/blob/3.3.0/specs/zh-cn/ai/ai-registry-adaptor-spec.md

相关推荐

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率,阿里云特别推出“通义灵码陪你备战求职季”活动,精心挑选百道历史校招技术面试/笔试题,借助通义灵码智能问答、代码智能生成、代码优化等核心功能,帮助开发者更加准确地了解程序员职业所需的核心技能,加强对问题解决思维和解题能力的练习。

阿里巴巴云原生的博客 1381

通义灵码 Visual Studio 下载安装指南(附安装包)

本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。

阿里巴巴云原生的博客 4435

让复杂任务由团队完成:阿里云 AgentCore 多 Agent 协作架构及实践

Alibaba Cloud AgentCore 以身份、通信、团队和任务为基础,让专业 Agent 与人类成员共同参与业务协作。企业可以按职责组合知识、工具、Skill 和模型,用任务系统持续追踪工作,再结合 AgentLoop 评估效果、优化配置。

阿里巴巴云原生的博客 301

易点天下:AI 驱动 IT 运维组织提效的实践

易点天下作为一家专注品牌全球化的营销科技公司,由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。

阿里巴巴云原生的博客 284

阿里云可观测 2026 年 10 月产品动态

阿里云可观测 2026 年 10 月产品动态

阿里巴巴云原生的博客 188

HiRoute 新版本发布:结合自己的真实工作选择最佳模型

HiRoute[1]是一个开源、运行在本地的 Agent 智能路由引擎。你继续用 Codex、Claude Code、Qoder、Pi、OpenCode、Hermes、DeepSeek Harness 等熟悉的 Agent,由 HiRoute 判断每一步交给哪个模型。

阿里巴巴云原生的博客 377

用户说 App“下不了单”:用 Session Replay 看清流程卡在哪一步

Session Replay(会话回放)将采集到的页面变化重建为可回看的过程。研发可以沿着这次会话,查看操作前后的界面变化,先确认流程停在了哪里,再结合当时的事件、日志和代码检查原因。

阿里巴巴云原生的博客 55

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

阿里巴巴云原生的博客 132

运维走出控制台:阿里云 AgentCore AI Native 运维实践

UModel 让现场能够被关联,运维数字员工让经验能够被调用,AgentCore Team 让分析能够协作,AgentLoop 让质量能够被检验。这些建设共同服务于一件事:让团队对系统的理解,成为每个人处理问题时都能接上的能力。

阿里巴巴云原生的博客 291

从长程 Agent 到 Super-agent,解锁更多场景

Deepseek Harness 提升了架构的透明度,但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype,是对 Agent “连续实体”能力的工程拆解。

阿里巴巴云原生的博客 232

排查提效 50%:淘大集新核心系统的观测护航之路

供应链运维,缺的不是更多机器,是“一条能把指标、日志、链路串起来的线”。阿里云 ARMS+SLS+云监控2.0+STAROps 重构观测底座。

阿里巴巴云原生的博客 147

概率、插座与 5000 个爱因斯坦:专访阿里云研发副总裁周琦

这次访谈发生在 2026 年云栖大会之后。大会期间,阿里云发布了智能体构建和治理平台 AgentCore,将企业级 Agent 基础设施进一步标准化和托管化。

阿里巴巴云原生的博客 152

Agent 数据飞轮平台的选型和实践

用统一标准判断修改效果,积累覆盖不同路径的测试样本,沿执行记录排查失败,并将典型问题纳入后续回归。而这也是宙斯接入 AgentLoop 要解决的问题。

阿里巴巴云原生的博客 28

Durable Agent 详解:如何让 Agent 在云端长期稳定运行

本文使用一个具体的用户任务示例“向五位客户发送通知邮件”,解释为什么保存聊天记录还不够,再以 AgentScope 构建的 Agent 为例,展开任务状态、持久提交和故障恢复的通用设计,最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力,讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。

阿里巴巴云原生的博客 334

Qoder × AgentLoop:智能体规模化应用,敏感数据保护如何跟上?

智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志,将发现的风险线索关联到具体会话、工具调用、成员和环境,帮助安全团队回查任务过程、明确需要整改的环节,并复查处理效果。

阿里巴巴云原生的博客 288

完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践

阿里云 STAROps 是一个生产运维 Agent,通过连接多域数据、运维工具与专家经验,从被动响应走向智能自治,7×24 保障业务连续、稳定运行。本文将分享 STAROps 的评测和调优实践。

阿里巴巴云原生的博客 198

阿里云云原生四项 AI 应用工程化实荣获“鼎新杯”优秀案例

第五届“鼎新杯”由中国通信标准化协会主办、中国信息通信研究院承办,自2026年05月正式启动,历时近 5 个月,聚焦国内政企数智化转型领域的创新成果,旨在为行业提供可复制、可推广的实践参考。

阿里巴巴云原生的博客 321

交付周期从 51 天缩短到 14 天,多 Agent 协作产品⾃进化背后的组织重构

本⽂结合这段实践,介绍评测如何驱动产品持续进化、⼈机协作的边界如何设定,以及团队如何通过统⼀⽬标、结果标准和责任分⼯,减少跨岗位交接,降低沟通损耗,把技术能⼒转化为实际交付效果。

阿里巴巴云原生的博客 327

从部署上线到运维优化:STAROps 与 ROS Agent 的资源运维自动化实践

STAROps 数字员工提供统一的运维对话入口,结合日志、指标、告警等信息理解问题,并通过 alibabacloud-ros-agent 技能,将基础设施规划和变更任务委派给 ROS Agent。

阿里巴巴云原生的博客 128

车企数据隐私保护必修课:如何用 SLS mask 守住日志中的敏感信息

阿里云日志服务 SLS 的 mask 函数可在采集或写入阶段替换匹配的敏感值,同时保留业务状态与调用链,并结合访问控制和保留期限管理减少暴露。下文通过车辆与车主服务、海外联网订阅、智能座舱交互三类业务中的四组日志,介绍规则选择与脱敏效果。

阿里巴巴云原生的博客 111

切换模型会损失缓存,智能路由还省钱吗?

智能路由会把不同的工作交给不同的模型。很多人随之会问:模型一换,之前积累的缓存就用不上了,这笔损失会不会把省下的钱又花回去?

阿里巴巴云原生的博客 209

LiteLLM 半年两度被投毒,大模型的“钥匙串”该放在哪里?

开源 Higress 把扩展代码关进 Wasm 沙箱,把发布链路锁成不可变;Higress 企业版再把凭证、供应链和防护交给平台托管。选哪一种,取决于你的团队想把精力花在哪里。想先试试托管形态的话,Serverless 标准版 0 元起步,不用先付实例费。

阿里巴巴云原生的博客 315

用 Kimi K3.1 Pro 重新介绍 AgentCore

今天凌晨 Kimi 发布 K3.1 Pro,在前端页面、Three.js 交互场景有明显提升。本文使用 Qoder 上提供的 K3.1Pro 模型,设计并排版了介绍 AgentCore 的全新方式。

阿里巴巴云原生的博客 13

从 Jev 范式决策模型接入,到参与 Team 协作的完整实践

本文将以一个工单分诊助手为例,把开发、打包和上线的过程串起来:用 AgentScope Java 与百炼决策模型(国内网络无法使用 Jev)实现分诊,通过代码包部署到阿里云 AgentCore[1],再验证普通调用和流式调用。文章最后,再看这个助手如何加入 Team,参与任务分工与报告审核。

阿里巴巴云原生的博客 338

MCP 服务无状态,任务状态存哪?RocketMQ LiteTopic 给每个任务一本账

AI Agent 调用一个工具,有时几百毫秒就能返回,有时却要运行好几分钟——比如检索一大批资料、生成一段长内容,或执行一次批处理。让请求一直挂着等结果,会长期占用连接和资源,也很难支撑大规模并发。

阿里巴巴云原生的博客 295

Personal Agent 观察:拆解全天候运行的技术挑战

本文将探讨一下,为什么 Personal Agent 成为了当前新的 AI 应用竞争点,底层技术以及后续国内跟进的可能方向。

阿里巴巴云原生的博客 289

Agent as a Service:驱动 Personal Agent 与企业智能体的服务架构

本文以 AgentScope 为基础,围绕 Sandbox as Tool 展开这条建设路径:将 Harness 托管为远端服务,将 Context、Memory 与恢复状态接入云端状态服务,通过执行权交接支持本地与远端续做,再通过 Brain/Hands 分离连接不同位置的工具执行端。

阿里巴巴云原生的博客 155

非算法工程师也能看懂,推理框架的来龙去脉

虽然 Model、Harness 的概念已深入人心,但推理框架这个算法工程师才会使用的概念似乎还略显陌生。不过,它和我们使用模型的费用和体验息息相关,例如为什么的输出价格是输入的 4 倍,缓存命中的价格是未命中的1/50(以 DeepSeek 当前的定价为例)等等,相信本文对这些疑问会提供一些通俗易懂的解答。

阿里巴巴云原生的博客 148

阿里云微服务引擎 MSE 及 API 网关 2026 年 9 月产品动态

阿里云微服务引擎 MSE 及 API 网关 2026 年 9 月产品动态

阿里巴巴云原生的博客 104

Agent 自进化的数据底座:阿里云 SLS Session Store

阿里云 SLS Session Store 将 Agent 的运行记录组织为可查询、可复用的标准轨迹,为观测、数据集、LLM 评估和 RSI 自进化提供共同的数据底座。

阿里巴巴云原生的博客 365
上一篇: HiRoute 新版本发布:结合自己的真实工作选择最佳模型
下一篇: 阿里云可观测 2026 年 10 月产品动态
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3143原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值