从构建、部署到规模化运行：加速企业Agent工程化

从构建、部署到规模化运行加速企业Agent工程化 李国强|阿里云智能云原生应用平台产品负责人 Agent在企业落地趋势 $2,019亿 2026年全球Agentic AI支出预测同比增长141%Gartner WorldwideAI Spending Forecast 2026.01 70%的企业会在生产环境中运行AI Agents 40% 企业应用将在2026年底嵌入AI Agent（2025年仅不到5%）Gartner The Future of Agentic AIin Enterprise Applications Google Cloud AI Agent Trend 2026 企业构建Agent时的挑战/痛点 多智能体如何治理协作 复杂架构运维问题发现慢，修复难 如何洞察智能体运行稳定成本可控 如何效果评估和持续优化 智能体架构依赖多如何快速构建部署 Agent弹性高，依赖多，成本不可控，如何洞察运行状态，及时发现问题，从运维与运营多个视角进行管理 智能体进一步带来系统的复杂性。如何用智能化的方式保证新兴智能业务的延续性 Agent效果是关键，但运行是黑盒，效果评估难，不知道如何优化 多智能体成为企业落地趋势，如何进行统一的治理及管控，以及提高多人多智能体协同效率 智能体开发框架多，依赖多，运行环境隔离性弹性要求高，如何快速构建，部署上线验证 阿里云AgentInfra覆盖智能体开发构建-运行-治理-运维-优化全周期 分论坛议程介绍 感谢聆听 全域智能运维平台STAROps工程实践分享 刘嘉鹏，阿里云智能技术专家 010203可观测智能体STAROps面向AgenticOps的上下文面向长周期AgenticOps的架构04总结 刘嘉鹏 阿里云智能技术专家 ApacheSkyWalkingCommitter，AlibabaLoongcollectorCommiter，长期深耕可观测性领域。负责阿里云MetricStore时序引擎核心研发，参与海量时序数据存储与查询引擎的设计与优化，对高性能数据处理、分布式系统架构有深入的工程实践。目前专注于STAROps智能运维平台核心工程建设，致力于构建自主监控、分析、自愈的AIOps产品，通过实时多维数据集、AI友好型运维工具链、领域专家经验库三大核心能力，为客户打造7×24自主运维的智能体团队。作为核心工程负责人，主导了Agent安全操作生产环境的工程设计，解决长周期任务执行、人机协同审批及全链路可观测等关键工程挑战。 企业运维领域面临的挑战 被动响应、效率低 工具多、数据散 门槛高、依赖深 MTTR平均数小时以上 70%时间维护工具 平均使用5+套运维工具 监控/日志/链路/事件/变更等系统分散，运维人员多平台切换，跨系统分析困难；运维经验无法固化为可复用能力，新人上手慢，运维依赖个人。 查询语句复杂、监控配置繁琐，排查强依赖经验；异常维度多、关联关系复杂，人工排查耗时长、根因定位困难；工具维护成本非常大。 规则阈值固化、告警风暴频发、无效告警多、缺乏智能收敛机制；只能事后救火处置，缺少主动巡检、风险预判、智能预警与自愈能力。 AI应用 云原生应用 大模型、智能体架构、推理服务 分布式应用 微服务、容器、云服务、Serverless SOA、ESB、数据库、缓存 基础架构、数据库 全域智能运维平台STAROps 从被动响应到智能自治，7×24小时保障业务连续稳定 STAROps三大核心功能 从即时分析到持续守护，构建面向生产系统的Agentic Ops能力 智能助手·即时洞察 数字员工·专属SRE 长期任务·持续守护 通过自然语言完成资源查询、指标解读、日志分析、事件调查和告警诊断等，将复杂查询转化为即时可读的分析结论，帮助用户快速理解系统状态、定位异常原因，降低运维信息获取门槛。 围绕运维目标创建跨天、跨周、跨月的异步任务，一次目标对齐，即可把重复巡检和被动排查变成持续自动流程，提前发现风险、收敛告警噪音，推动运维从“事后响应”走向“主动保障”。 构建企业专属SRE智能体，可自定义配置职责、权限、工具、技能等，让Agent按企业的流程和规范工作。沉淀专家经验和团队最佳实践，让企业逐步形成可复制、可扩展的智能运维能力。 Kubernetes容器巡检 个人Agent与STAROps对比 STAROps=模型+可信上下文+长周期Agent运行 面向AgenticOps的上下文 复杂的服务拓扑 大模型时代的AIOps面临的认知难题 TheCognitiveChallenge for AIOps in the LLM Era 运维领域的语义鸿沟 系统拓扑的认知迷宫 根因分析的逻辑断链 从数据孤岛到智能运维 Trace、Log、Metrics让系统被看见；UModel把运行数据连接成“运维世界模型”；STAROps让智能体完成感知、分析、决策、执行与验证闭环。 第二阶段| UModel建立链接 第一阶段|数据孤岛 从“看见数据”到“理解系统”，再到“安全行动” 数据只是现象 模型连接世界 智能体完成闭环 日志、指标、链路、事件、变更都是局部事实；没有统一实体和关系，AI只能总结信号，难以判断真实系统状态。 UModel把对象、关系、字段语义、存储位置和分析入口组织成图，让AI知道“这是谁、关联谁、数据在哪、该怎么查”。 STAROps叠加Mission、数字员工、ToolService、Skill、Sandbox和HIL，把可观测升级为7x24自主运维控制面。 可观测性的下一步，不是接入更多数据，而是把运行事实编译成Agent可理解、可验证、可授权、可行动的世界模型。 模型上下文来源UModel UnifiedModel数据融合查询 获取日志中存在报错的IP的某个指标，并对这些IP的指标进行异常检测 .lethosts=.logstore with(logstore='test',query='error')|distinct ip|project ip.promql with(query='memory_usage{}')|where labels.up=$hosts.ip|series_anomaly_detect 接收到某个告警事件，查询对应实体跳数5之内实体的事件 .letabnormalEntity=.event with(query='alertType="PodOOM"')|project domain,type,entity_id.letrelated_entity=.topo|graph-call getNeighborNodes('sequence',5)|where__src_entity_id__=$entity.entity_id and__src_entity_type__=$entity.type and__src_entity_domain__=$entity.domain.event|where entity_id=$related_entity.__entity_id__and domain=$related_entity.__domain__andentity_type=$related_entity.__entity_type__ 从Metrics中实时提取出Entity（进程信息），和EntityStore一起构建Graph（进程所属主机），并和存储中的GraphUnion，执行Cypher Query（从进程找到关联的主机、从主机找到关联的EIP），并从EIP日志中查询出这个主机访问的外部IP .letprocess_infos=.promql with(query='ecs_cpu{}')|distinct labels.process|project labels.process.letnodes=.logstore with(logstore='test',query='* | project node_id=__entity_id__,node_type=__entity_type__') ;.letedges=.logstore with(logstore='test',query='* and 172.16.20.9 | project src_id,dest_id,src_type,dest_type,edge_type,src,dest');.letexternal_graph=$edges|make-graph src_id,src_type-->dest_id,dest_type with$nodes onnode_id,node_type.leteips=.topo|graph-join$external_graph|graph-match(src:infra@process)-[contains]->(e:infra@host)->[bind]->(e1:infra@eip)where e1 in (xxx)|project eip.logstore with(logstore='eip_logs',query='* | project _eip_, _external_ip')|where_eip_=$eips.eip|projectexternal_ip 面向长周期AgenticOps的架构 Agent的普遍问题 •控制缺位：多以模型、Prompt、工具为中心，缺少生产级控制面。•职责过重：同时承担推理、状态、权限、工具调用，故障边界不清晰。•无法连续：无法追问，多轮对话经常失忆。•执行高危：Shell、CLI、云API直接暴露，权限和审计风险高。 STAROps总体架构 知识的管理 •版本缺失：Prompt、Skill、Agent、Tool缺少统一版本治理。•评估失真：配置漂移会让评估结果不可对齐，无法稳定比较效果。•归因困难：行为变化后，难判断来自模型、Prompt、Skill还是Tool。•灰度困难：能力更新缺少灰度、回滚、热更新机制，迭代风险高。 面向评估的动态配置设计 面向评估的动态配置设计 大脑的无用负载 •上下文爆：工具说明、Skill、文件全量注入，容易撑爆模型窗口。 •选择不稳：工具数量多时，模型注意力分散，难稳定选择正确工具。 •来源割裂：内置工具、远程工具、CLI工具风格各异。 •暴露过量：Agent需要探索能力，但不应默认看到所有能力细节。 •成本升高：上下文越大，推理成本越高，响应稳定性越差。 渐进式披露文件系统 渐进式披露文件系统 Agent长期运行的挑战 •周期过长：运维任务常跨小时、跨天，不是一次对话能完成。•中断频繁：服务重启、工具失败、HIL暂停、外部重试都会打断链路。•历史膨胀：长持续产生对话、工具结果、日志、证据，历史不断变长。•重跑危险：缺少checkpoint时，失败后只能重跑，容易重复执行。•追踪困难：执行过程不可恢复、不可回放，就难以审计和复盘。 Mission阶段 面向容灾设计的长周期任务 长周期运行样例 长周期会话 长周期会话 安全风险 •凭证常驻：默认信任本机，AK/SK、profile、kubeconfig长期存在。•执行不信：LLM和Sandbox必须视为不可信执行端，不能接触凭证。•越权风险：写操作需要HIL、黑白名单、权限收敛和失败关闭。•审计缺失：工具调用如果绕过统一网关，就难以追踪和复盘。•代签缺口：云API既要自动化调用，又要避免凭据外溢和越权。 ToolService认证体系 总结 总结 •生产可控：不把Agent做成单体大脑，而是拆出Gateway、Master、ToolService、Sandbox等工程控制面。•长期可靠：用Mission承接跨小时、跨天任务，支持状态托管、HIL暂停、失败恢复和回放