让每次语音唤醒都可靠,公牛沐光重构可观测体系

作者:公牛集团,周施乐 王雷 欧阳绩新;阿里云,顾思 白玙 珞希

本文详细介绍了公牛沐光团队如何从开源监控方案 SkyWalking 成功迁移到阿里云 ARMS,构建起一套集观测、追踪、日志分析与智能告警于一体的全栈式可观测平台的实践历程。文章不仅揭示了技术选型的关键考量维度,更重点呈现了 ARMS 在大模型与 IoT 融合场景中的独特价值——从语音识别瓶颈定位、大模型推理性能优化到语音合成质量保障,实现了从"被动响应"到"主动治理"的转型。

整体观测链路:用户本地网关→用户语音输入→语音识别(ASR)→MultiAgent->IOT 指令执行→回复文本生成→语音合成(TTS)→设备响应。

企业背景与架构升级背景

作为国内领先的电工电气企业,公牛集团始终致力于为用户提供安全、智能、可靠的用电解决方案。随着企业数字化转型的深入,业务规模持续扩张,应用架构也由传统单体系统逐步演进为微服务化、云原生化的技术体系。这一变革在提升系统灵活性与可扩展性的同时,也带来了日益复杂的系统拓扑、频繁的服务调用链路以及海量的运行时数据,对系统的可观测性提出了前所未有的挑战。

此前,公牛集团采用基于开源 SkyWalking 监控体系,虽然在初期满足基础的链路追踪需求,但随着微服务数量激增、调用关系日益复杂,原有系统逐渐暴露出性能瓶颈。运维团队常常在故障发生后才被动介入,难以实现问题快速定位与根因分析,严重影响线上服务稳定性与用户体验。面对这一挑战,公牛集团决定重构其可观测性体系,目标是构建一套集观测、追踪、日志分析与智能告警于一体的全栈式可观测平台,实现从“被动响应”向“主动治理”的转型。

技术选型维度与对比

SkyWalking 作为一款优秀的开源 APM(应用性能监控)工具,其轻量级部署、对主流微服务框架的良好支持,使其成为在项目初期技术选型的理想选择。随着SkyWalking 逐渐暴露出其在企业级场景的局限性,公牛集团意识到,仅靠开源方案已难以支撑其向“高可用、智能化、自动化”运维体系迈进的目标。技术团队启动对新一代企业级应用可观测解决方案的评估。

在进行应用监控体系建设的过程中,选择商业方案还是开源方案往往需要在多个关键维度之间进行权衡与取舍。接入复杂度是首要考量因素,商业方案提供标准化探针、自动发现机制和图形化配置界面,大幅降低部署门槛,尤其适合技术储备相对有限或希望快速上线的团队;而开源方案虽然具备一定灵活性,但依赖于团队自行完成探针集成、数据格式定义和采集链路搭建,尤其在异构技术栈并存的复杂架构中,需要投入大量人力进行适配与维护。

同时,链路查询能力直接关系到问题排查效率,商业方案提供语义清晰的查询语言、可视化检索条件和多维度过滤能力,支持快速定位异常请求;相比之下,开源方案在跨系统调用链的关联查询上往往需要自研补全,查询体验依赖于二次开发程度。下钻分析能力则体现可观测系统对问题根因的洞察深度,商业方案将拓扑关系、依赖分析、异常指标联动集成于统一平台,支持从应用性能波动逐层下钻至具体实例、线程甚至数据库慢查询,形成闭环分析路径;开源生态虽可通过组合不同组件实现类似能力,但各组件间的数据割裂问题普遍存在,实现端到端的无缝下钻往往需要复杂的集成工作和统一的数据模型设计。

此外,监控探针对系统本身的性能影响也不容忽视,商业方案经过多年生产环境打磨,普遍在资源占用、采样策略和数据上报机制上做了深度优化,能够在低开销下保持高采集频率;而开源探针虽然透明,但在高并发场景下可能出现 CPU 或内存占用偏高、日志堆积等问题,配置不当甚至可能反向影响业务稳定性。

image

因此,最终方案的选择不仅取决于技术能力,更需结合团队运维能力、长期投入意愿以及业务对可观测性的实际要求,在灵活性、效率与可持续性之间找到平衡点。也是基于以上考量,公牛集团最终选择阿里云应用实时监控服务 ARMS 作为可观测性体系的升级路径。

从“用上”到“用好”的公牛集团可观测进阶路径

3.1 平滑迁移,业务零扰动

面对可观测性体系的升级需求,公牛集团最关注的不仅是功能增强,更在于迁移过程的稳定性、兼容性与业务零扰动。在保障核心业务连续性的前提下,顺利完成从 SkyWalking 到阿里云应用实时监控服务 ARMS 的全面切换。对此,阿里云应用实时监控服务 ARMS 提供多种保障机制确保平滑、高效、低风险的迁移体验:

  • 一键式接入:用户只需在云产品控制台启用链路追踪开关,即可直接查看调用链,大幅简化链路采集成本。
  • 自动埋点能力:ARMS 提供自研探针,针对 Java/Go/Python 等主流语言提升链路插桩质量、性能和稳定性,无需大量代码改造。
  • OpenTelemetry 标准支持:基于行业标准协议,为分布式应用提供完整调用链路还原、链路拓扑和应用依赖分析工具。

image

3.2 从“用上”到“用好”的进阶路径

迁移至 ARMS 后,公牛集团实现对微服务架构下数百个应用节点的端到端观测覆盖。ARMS 提供的高性能链路追踪、实时指标分析、智能异常检测与一体化告警能力,显著提升系统可观测深度。运维团队可实时掌握服务调用链路、识别性能瓶颈、预测潜在风险,并通过丰富的可视化仪表盘进行多维度数据分析,大幅缩短了故障排查时间(MTTR 降低 60% 以上),有效保障了关键业务的高可用性。公牛集团成功实现从“基础监控”到“主动治理”的跨越,运维效率显著提升,系统稳定性迈上新台阶,其中:

3.2.1 基于链路视图的主动巡检

在主动巡检层面,ARMS 的链路分析功能成为运维团队的“智能导航仪”。通过散点图与全链路聚合分析视图,团队可以对核心链路进行健康度量化评估,快速定位异常波动的服务节点。运维人员借助可视化拓扑图清晰呈现服务间的依赖关系,不仅精准识别了单点故障,还发现了隐藏的循环依赖问题,从而提前实施架构优化。面对海量调用数据,系统支持上亿条调用链的实时聚合与深度下钻分析,帮助团队快速锁定异常调用的分布特征。

3.2.2 内部稳定性治理闭环

在稳定性治理闭环建设中,ARMS 的价值进一步凸显。针对某日均调用量达 8000 万次的核心接口,团队通过 ARMS 深度链路分析定位到某集群读写性能瓶颈,经代码级优化后,该接口平均响应时间降幅达 45%。同时,ARMS 的根因分析能力帮助团队穿透式追踪问题根源,例如某次IoT 设备控制指令延迟事件中,系统通过全链路追踪定位到 LLM 服务的响应阻塞,最终通过扩容和请求队列优化解决问题。更关键的是,团队将链路性能指标融入 CI/CD 流程,在新版本发布前自动检测接口响应时间、错误率等关键指标,使问题发现从人工巡检变成自动定位。

3.3 意外收获:跨领域可观测价值

在实现微服务监控体系升级的基础上,ARMS 可观测性能力意外延伸至跨领域场景,为公牛集团带来超出预期的业务价值。特别是在大模型与 IoT 深度集成场景中,ARMS 展现了强大的全链路分析能力。

3.3.1 大模型与 IoT 全链路优化

ARMS 通过端到端链路追踪技术,完整覆盖了从 LLM 推理、控制指令下发到 IoT 设备响应的完整路径,实现了对 100-200ms 级延迟的精准分析。过去需要跨多系统拼接日志才能定位问题,耗时长达数小时;如今通过 ARMS 一站式链路还原,团队可在分钟级定位异常环节。同时,ARMS 对 LLM 服务 API 调用质量、响应延迟和错误率进行实时监控,为模型版本迭代提供关键数据支撑。

3.3.2 AI 大模型语音全链路监控与性能优化

ARMS 实现了从用户语音输入到最终设备响应的全路径追踪,涵盖 ASR 语音识别、LLM 意图解析、TTS 语音合成等关键环节,每个环节的耗时和状态清晰可见。在跨领域可观测性实践基础上,ARMS 针对大模型的特性开发了深度分析能力,为 AI 工程化落地提供了关键支撑。不仅能追踪链路耗时等基础指标,并通过上下文关联分析实现价值跃升。在异常治理层面,ARMS 的异常模式自动学习学习能力极大提升了问题发现效率,系统通过分析历史链路数据,自动识别出"模型卡死""响应截断"等典型异常模式。ARMS 的成本-性能平衡帮助团队在资源投入与业务效果间找到最优解。此外,多模型版本对比功能也为模型迭代提供了数据化决策依据。这些能力在语音识别瓶颈定位、大模型推理性能优化、语音合成质量保障等场景中,发挥了关键作用:

1)语音识别瓶颈定位:

当用户反馈语音指令响应慢,平均延迟达 1.8 秒时,运维团队通过 ARMS 的链路追踪功能快速定位问题根源。系统显示 ASR 服务耗时占比达 65% 且存在大量重试请求,团队针对性调整 ASR 服务参数并为方言识别场景配置专用资源池,最终将端到端延迟降低至 600ms。这一过程避免盲目扩容带来的成本浪费,充分体现 ARMS 精准定位技术瓶颈的价值。

2)大模型推理性能优化:

在日常巡检过程中,运维团队观察到 LLM 服务响应时间波动剧烈,P99 延迟高达 2.5 秒。通过 ARMS 发现长文本生成场景下,Token 生成速度下降明显。研发团队据此实施动态批处理策略并针对长文本场景优化缓存机制。经过优化,长文本生成延迟降低 40%,P99 延迟稳定在 1.6 秒以内。ARMS 的散点图(展现了文本长度与延迟的非线性关系)成为此次优化的关键,帮助团队从海量数据中抓住核心矛盾。

3)语音合成质量保障:

针对用户反馈的方言场景 TTS 质量下降问题,运维团队通过 ARMS 发现特定方言模型的调用失败率上升是主因。团队据此建立方言模型质量监控看板,当某方言模型的合成失败率超过阈值时,系统自动触发预警,推动研发团队及时修复。如今,ARMS 不仅观测技术指标,更实现了从"技术参数"到"用户体验"的映射,使质量保障从被动响应转向主动预防。

3.3.3 开发效能提升

ARMS 的可观测性能力不仅改变了运维模式,更深度融入开发流程,开发团队通过 ARMS 的链路驱动 Code Review 实现精准代码改进。对新人而言,无需翻阅海量文档,通过直观的调用关系图即可理解系统交互逻辑。在跨团队协作层面,ARMS 打破了部门间的"数据孤岛"。所有团队共享同一套可观测数据,这种数据驱动的协同模式使跨部门问题解决效率提升 50% 以上。

让可观测成为企业基础能力,公牛集团的思考与实践

在使用过程中,公牛集团积极从采集策略、告警规则设计、自定义指标规划等维度探索适合自身业务特征的最佳实践。

4.1 结合业务特征与场景,灵活规划可观测体系配置

4.1.1 基于业务需求进行采样策略优化,平衡存储成本与可观测性

在构建高可用、高可观测性的应用监控体系过程中,合理的配置策略不仅是技术落地的关键支撑,更是保障系统稳定性与业务连续性的核心环节。采样策略的设定需兼顾数据完整性与资源成本,尤其在大规模微服务架构中,盲目全量采集将带来高昂的存储与传输开销,因此应根据业务重要性实施差异化采样:对支付、订单、核心接口等关键链路实行 100% 采样,确保任何异常请求均可追溯;而对于低频或非关键路径,则可引入自适应采样机制,依据请求量、错误率或响应延迟动态调整采样率,在保障可观测性的同时有效控制数据洪峰。

4.1.2 基于 P99 延迟设计动态阈值告警,避免固定阈值导致告警疲劳

告警机制的设计则跳出传统固定阈值的思维定式,避免因业务流量周期性波动或业务活动场景下的正常延迟上升频繁触发无效告警,进而导致运维人员产生“告警疲劳”甚至忽略真实故障;采用基于 P99、P95 等高分位延迟的动态基线告警,结合同比、环比趋势分析,能够更精准地识别性能劣化趋势,提升告警的敏感性与准确性。

4.1.3 结合业务特性,扩展自定义指标

与此同时,观测不局限于系统层指标或通用调用链数据,而应深度融入业务语义,通过自定义指标扩展实现技术与业务的双向对齐,例如将 IoT 设备的响应成功率等关键业务健康度指标注入追踪上下文,使链路数据不仅反映“系统是否正常”,更能回答“业务是否可用”。

4.1.4 模型专项监控配置,为 AI 创新保驾护航

面对当前大模型服务的广泛应用,监控配置也需随之演进,针对其独特的性能特征和用户体验敏感点进行专项优化:为大模型推理服务建立独立的指标分组,重点采集 Token 生成速度、首 Token 延迟(Time to First Token)、上下文长度处理效率等核心性能指标,全面刻画模型响应行为;通过配置 Prompt 长度与响应时间的关联分析看板,识别输入长度对推理性能的影响曲线,辅助模型优化与资源预估;对于语音识别、语音合成等实时性要求极高的场景,还需建立端到端的 SLA 观测体系,从用户发起请求到语音播放完成的全链路进行延迟建模,划分关键阶段(如 ASR、NLU、TTS)并设置分段告警阈值,确保用户体验始终处于可接受范围。这些配置建议并非孤立存在,在统一的可观测性平台上协同运作,形成从数据采集、存储、分析到告警与可视化的一体化闭环,最终实现对复杂分布式系统的深度洞察与主动治理。

4.2 将可观测文化作为团队重点能力与工作方式

在推动应用监控体系落地的过程中,技术工具的部署只是起点,真正决定其价值能否释放的关键在于团队的认知水平与协作方式。当可观测性从一项“附加功能”演变为团队默认的工作范式,技术团队将不再被动响应告警,而是具备预见问题、洞察趋势、主动优化的能力,最终构建起以数据为依据、以协同为路径、以稳定为目标的现代化研发治理体系。对此,公牛集团从多个角度、不同形式积极培养团队可观测能力与文化。

链路分析能力的提升不能依赖零散的经验传递或被动的问题应对,而是通过系统性的实践训练逐步沉淀为组织能力。对此,公牛集团定期开展基于真实生产事件的 ARMS 分析工作坊,选取典型故障场景——还原完整的调用链路,引导研发、运维和测试人员共同参与从现象定位到根因挖掘的全过程,在实战中掌握上下文关联、异常模式识别和跨系统协作排查的技巧,使链路数据不再只是可观测平台上的可视化线条,而成为解决问题的思维路径。

与此同时,可观测性不应停留在工具层面,更需融入团队的文化基因,通过将链路健康度、关键接口 P99 延迟、错误率等指标纳入各研发团队的 OKR 考核体系,建立起对系统稳定性的共同责任感,推动从“我写完代码就交付”向“我负责系统持续可用”的思维转变,配合“问题不过夜”的快速响应机制,鼓励团队在当日定位并闭环处理潜在隐患,从而形成主动发现、快速反馈、持续优化的良性循环。

这种文化氛围进一步反哺开发行为,促使工程师在设计和编码阶段就前瞻性地考虑系统的可观测性,践行“观测驱动开发”的理念:在服务间调用中注入可追踪的业务标识,如订单 ID、用户会话 Token 或请求场景标签,确保关键路径上的每一个环节都能被精准归因;在日志输出中保留结构化上下文,与链路 ID 强关联,实现日志、指标、追踪三位一体的协同分析;甚至在接口设计之初就定义好核心埋点和监控看板原型,让可观测成为软件交付的必要组成部分而非事后补救手段。

4.3 未来规划

随着可观测的使用逐渐深入,可观测文化深入人心。公牛集团对自身可观测建设以及 ARMS 产品功能提出了更高要求,整个可观测性体系将在智能化、成本可控、跨平台协同和深度业务融合的方向上持续演进,最终成为支撑业务创新与系统稳定的核心基础设施。也为更多企业提供了更多可参考、借鉴的方向:

4.3.1 AI 驱动的根因分析

随着系统架构的持续演进和业务复杂度的不断提升,可观测性建设正从“看得见”向“看得懂、能预测、可优化”的方向深化。在这一进程中,AI 技术的引入成为关键推动力,融合 ARMS 的全链路追踪数据与日志服务中的海量非结构化信息,构建具备上下文理解能力的根因分析模型,自动识别异常模式、关联跨服务的性能劣化信号,并在多因并发的复杂场景中快速收敛到最可能的问题源头,大幅缩短 MTTR(平均修复时间),使运维响应从“人工排查”迈向“智能推荐”甚至“自动修复”的新阶段。

4.3.2 成本精细化管理

与此同时,随着数据量指数级增长,成本问题日益凸显,单纯的存储扩容已不可持续,必须建立精细化的资源治理机制;借助 ARMS 的智能采样能力,系统根据请求重要程度、错误状态或调用路径动态调整数据采集密度,在保障核心链路完整性的前提下有效削减冗余数据;结合数据分级存储策略,将高频访问的热数据保留在高性能存储中,而将历史归档数据自动迁移至低成本存储介质,实现性能与成本之间的动态平衡,让可观测性体系在规模化扩展中依然保持经济可持续性。

4.3.3 混合云统一观测

面对企业 IT 基础设施日益普遍的混合云格局,数据孤岛问题也亟待破解,未来重点探索 ARMS 与公有云多账号及私有云的深度集成路径,通过标准化的数据接入协议和统一的元数据模型,打通混合云环境下的调用链路、指标数据与事件日志,构建全局视角的统一观测平台,无论应用部署在哪里,都能实现一致的观测体验与统一的告警策略管理。

4.3.4 深化大模型可观测

而在大模型广泛应用的背景下,对 AI 服务本身的观测需求也正从外围指标向纵深发展,未来的可观测能力将不再局限于 Token 生成速度等表层性能参数,而是进一步深入模型推理内部,捕捉 GPU 利用率波动、KV 缓存命中率、批处理效率等细粒度运行状态,结合 Prompt 语义分类与响应质量评估,建立模型性能与输入特征之间的关联分析模型,支持按模型版本、租户、业务场景进行多维性能对比,从而为模型优化、资源调度和 SLA 履约提供更精准的数据支撑。

总结

通过从 SkyWalking 到 ARMS 的升级,公牛集团构建了覆盖全链路、全维度的可观测体系,实现了三个关键转变:从被动响应到主动预防、从单点监控到全局洞察、从技术指标到业务价值的映射。ARMS 不仅解决原有观测体系的痛点,更成为业务创新的重要支撑,特别是在大模型与 IoT 融合场景中展现出独特价值。

尤其在 AI 大模型语音服务监控方面,ARMS 提供从语音输入到设备响应的全链路追踪能力,以及针对大模型特有的观测指标体系,帮助公牛集团精准定位性能瓶颈、优化用户体验、控制服务成本。相比传统监控工具,ARMS 的大模型观测能力实现了从"看到问题"到"理解问题"再到"预防问题"的跃升。

ARMS 作为可观测性建设的核心平台,持续释放其最大价值,特别是在 AI 与业务深度融合的今天,强大的可观测性能力已成为企业数字化转型不可或缺的基础设施。

点击此处,了解更多产品详情。

相关推荐

推荐一款好用的刷题工具

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

阿里巴巴云原生的博客 1383

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

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

阿里巴巴云原生的博客 4436

生产更可信,订阅更耐用丨Higress 社区进展报告

阿里巴巴云原生的博客 136

让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站精彩回顾 & PPT 下载

近日,让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站圆满落幕。本场活动吸引了 100+ 名技术从业者深度参与,深度分享了企业 Agent 趋势、AgentCore 构建与治理、Agent 观测与优化、STAROps 智能运维及 AI 网关等相关议题,并设置了动手实操环节。

阿里巴巴云原生的博客 105

如何用 STAROps Elasticsearch 智能助手看穿“搜索变慢”

某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起,业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上,部分请求超时。值班工程师打开控制台:集群状态为 Green,没有未分配分片,集群平均 CPU 约 40%,乍看不像资源已经吃紧。

阿里巴巴云原生的博客 312

满帮基于阿里云 AgentCore 打造生产级 SRE 稳定性数字人

满帮基于阿里云 AgentCore 构建“稳定性数字人”:满帮提供业务知识、专业工具与处置流程,AgentCore 提供智能体运行、协作和治理支撑。数字人已在核心链路的巡检与根因分析中得到应用,受控处置能力也在持续建设,让满帮积累的稳定性能力能够在具体任务中得到复用。

阿里巴巴云原生的博客 113

稳定复现超 70% 的缺陷,报警到自动修复的 Agent 流水线实践

本文将分享我们在 PolarDB-X 团队做的一些工程实践:让 Agent 从一条报警或工单出发,自主完成排查、复现、修复和验证,再把结果交给研发评审。

阿里巴巴云原生的博客 295

从“自证清白”到“因果链条”:智能体如何重塑运维排障效率

STAROps 做全域关联分析,把范围从「五个团队依次自证清白」收拢到一条具体链路;证据指向对象存储后,OSS Agent 接手,基于真实配置、访问日志和用量数据往下挖,给出根因和支撑它的证据链。你面对的始终是一个对话框:路由归它管,说清现象、拍板方案归你。

阿里巴巴云原生的博客 125

TechTalk丨从能买奶茶到能进企业,Agent 绕不开同一组问题

史明伟所在的 Alibaba Cloud AgentCore 是企业级 Agent 构建和治理平台,为 Agent 在业务场景下的规模化落地提供基础设施,所以这场对话,他和 Datawhale 主持人从个人助理一路聊到企业 Agent:权限该怎么一步步放开?进了企业,账号打通、数据权限、沙箱隔离又会带来哪些新问题?没有强技术团队的企业,该从哪里起步?

阿里巴巴云原生的博客 208

AgentCore + Codex 构建生产级 Agent 的原理与实践

本文章演示 AgentCore[1]的自定义代码/镜像能力,目的是展示如何基于自定义的 Harness 框架(Codex) 结合 AgentCore 提供的身份、模型、工具、技能、凭证 、观测评估等能力实现一个端到端的 Agent 应用,内容包含两个部分,技术方案和实践教程,文末附相关源码和本次的测试数据,可以根据需要自行查阅。

阿里巴巴云原生的博客 188

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

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

阿里巴巴云原生的博客 340

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

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

阿里巴巴云原生的博客 303

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

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

阿里巴巴云原生的博客 199

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

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

阿里巴巴云原生的博客 314

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

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

阿里巴巴云原生的博客 388

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

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

阿里巴巴云原生的博客 55

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

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

阿里巴巴云原生的博客 145

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

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

阿里巴巴云原生的博客 302

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

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

阿里巴巴云原生的博客 237

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

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

阿里巴巴云原生的博客 148

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

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

阿里巴巴云原生的博客 155

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

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

阿里巴巴云原生的博客 29

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

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

阿里巴巴云原生的博客 336

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

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

阿里巴巴云原生的博客 292

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

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

阿里巴巴云原生的博客 199

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

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

阿里巴巴云原生的博客 324

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

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

阿里巴巴云原生的博客 330

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

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

阿里巴巴云原生的博客 131

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

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

阿里巴巴云原生的博客 113

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

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

阿里巴巴云原生的博客 209
上一篇: 聚焦 AI 应用基础设施,云栖大会 Serverless AI 全回顾
下一篇: 阿里云 AI 中间件重磅发布,打通 AI 应用落地“最后一公里”
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3151原创
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值