大模型技术飞速迭代、开源生态持续繁荣，让运维智能体彻底告别概念炒作，从试点验证大步迈入规模化生产落地的深水区。不同于通用场景的AI应用，企业生产运维场景有着极致严苛的底线要求：高实时、高精准、强合规。运维操作无“撤销键”，一旦智能体决策失误、执行偏差，极易引发业务故障、数据风险与合规隐患。

也正因如此，成本高昂、安全隐患、管控失控，成为横亘在企业智能体运维落地路上的三大核心壁垒，也是所有技术团队必须直面的核心拷问。

针对行业普遍痛点，2026年7月21日，博睿数据重磅开启线上专题研讨会，以智能体运维生产落地的灵魂拷问：成本、安全与可控性如何兼得为核心主题，基于自研Bonree ONE Sage AI真实研发迭代与企业落地实战经验，拆解智能体运维规模化落地的核心逻辑，为行业答疑解惑、赋能实践落地。

以下为本场直播的详细实录。

主讲嘉宾：

程   捷：博睿数据CTO

贺安辉：博睿数据产品总监

袁耀辉：博睿数据数智能力中心负责人

往期问题集中答疑

Q1.  落地的智能体对不同厂商模型和不同参数模型是否有要求？

程捷表示，此前博睿数据Bonree ONE 4.0版本推出智能问答类功能与AI工作台后，客户关注度较高，但在私有化部署场景中普遍存在客户本地模型能力参差不齐的问题，部分客户提供的模型参数量较小，且未开启推理（thinking）能力，这会直接影响智能体应用效果。他强调，真正的智能体应用与市面上常见的知识问答、RAG召回类产品存在本质区别，因此对模型参数确有明确要求。

袁耀辉进一步补充了具体的选型依据：

• 架构层面：需具备函数调用（Function Calling）能力，且采用MoE（混合专家）架构。早期以DeepSeek-R1为代表的模型虽具备较强推理能力，但缺乏函数调用能力，难以满足智能体执行任务的需求；MoE架构通过专家激活机制，可在不同场景下调用不同专家模块，与运维场景的应用特点相匹配，同时能够有效控制推理开销。

  
  

• 参数量级：需大于200B。运维领域涉及大量结构化、专业化的数字类数据（如各类监控指标），通用模型对此类内容的理解能力有限，若一味压缩参数规模，将难以保证诊断效果与数据完整性。

  
  

• 上下文长度：需大于256K。程捷补充说明，在根因分析、故障诊断等场景中，模型需要调用完整的知识图谱数据，涵盖从前端到后台、从基础设施到上层业务的全链路可观测信号与日志数据，同时还需承载工具（Tool）调用信息及系统提示词，若上下文窗口不足，将导致上下文截断、模型幻觉等问题。

综合以上，博睿数据对底层模型的核心要求为：支持OpenAI协议，具备推理能力，上下文长度大于256K，参数量大于200B，且采用MoE架构。

Q2. 大厂如何帮助企业在商业落地过程中进行Agent成本管控？

程捷介绍，博睿数据的成本管控策略分为两个阶段。第一阶段为"Harness工程"层面的优化，包括上下文管理、提示词压缩、对话轮次裁剪等基础能力建设，尽可能控制单次交互的成本。第二阶段为中长期规划，即自主研发面向运维领域的专用模型，通过更轻量、更聚焦的参数规模，将部分原本依赖外部Skill与提示词实现的能力内化为模型自身参数，从而进一步降低Token消耗。

袁耀辉从工程实践角度补充：在与MCP对接的过程中，团队采用了分层与渐进式信息披露的方式，对披露给模型的上下文进行裁剪；同时，针对提示词设计层面，通过对任务信息进行结构化排序与强调，弥补模型缺乏"记忆"的局限，保障多轮交互中的任务信息不丢失。他表示，未来还将推进针对运维场景的模型蒸馏与微调工作，通过将思考路径固化进模型本身，进一步压缩推理链条与Token成本。

Q3. 对昇腾算力集群如何管控？

袁耀辉介绍，博睿数据当前与华为昇腾处于战略合作与适配阶段，主要考量两个层面：一是适配层面，验证DeepSeek V4等开源模型能否在昇腾硬件上稳定运行；二是效果层面，从准确性与响应速度两个维度，将昇腾平台的表现与现有基于公网算力的运行指标进行对比。目前适配情况总体良好，速度与性能仍在持续调优中。

袁耀辉进一步说明，博睿数据当前并未自建昇腾算力集群，相关算力集群由华为昇腾团队负责运维与管控，博睿数据作为能力提供方，专注于产品与模型能力的建设。程捷补充，与华为昇腾的合作主要面向私有化部署场景，旨在解决部分客户本地缺乏算力服务、或本地模型能力无法满足前述参数要求的问题；公有云场景目前仍采用云端模型服务，未来不排除自建算力中心的可能性。

Q4. 与大模型厂商有合作，Sage AI能否帮助企业压降成本？

博睿数据目前尚未与大模型厂商建立此类合作。

Q5. 对于工信部通报的Claude Code后门漏洞问题，是否具备管理能力？

贺安辉表示，据其了解相关漏洞采用了较为隐蔽的多层加密手段传输身份信息，其被发现具有一定偶然性。就目前博睿数据AI可观测能力而言，尚无法针对此类深度伪装的漏洞进行精准识别。

Q6. 处理一个运维问题大概需要多长时间？

程捷认为该问题需结合具体场景判断，通常取决于三个变量：一是场景类型（巡检、故障诊断或自动化变更等）；二是任务复杂度（如巡检对象为10台、100台还是1000台主机）；三是本地算力能力。以故障诊断为例，在DeepSeek V4 Flash上运行约需两分钟左右，而在算力较弱的环境下可能需要七到八分钟，因此处理时长不能一概而论。

Q7. 底层使用什么模型？是否支持海外模型？

贺安辉回应，Bonree ONE 国内SaaS版本默认使用DeepSeek V4 Flash，同时产品内置模型网关，支持所有兼容OpenAI协议的模型接入，包括海外模型，海外（如马来西亚、泰国等）SaaS版本默认提供ChatGPT服务，用户亦可根据前述参数要求自由切换至其他符合条件的模型。

Q8. 对于智能体无限递归、无限思考的情况如何兜底？

程捷首先指出，该问题本质上是一个工程问题，而非模型能力问题，团队在早期开发中确实遇到过类似的循环调用场景。袁耀辉进一步补充，这与传统软件工程中的容灾设计思路一致，Bonree ONE Sage AI在该问题上设置了软约束与硬约束两层保护机制：

• 软约束层：内置类似"校验官"角色的机制，持续评估模型推理路径与执行动作是否偏离原始目标，若发现偏离，将及时触发纠偏或回溯。

• 硬约束层：设定最大轮数、Token消耗及调用超时等上限，一旦触发即强制中断任务，作为最终防线，避免出现无限循环。

Q9. 容量预测是大模型直接预测还是通过算法实现？

程捷回应，该场景目前主要依赖大模型直接生成预测结果，未采用独立的深度学习或机器学习算法流程。他表示，在大模型技术成熟之前，博睿数据在容量预测方向确实采用过传统算法方案，但当前大模型能力已能够较好地满足该场景需求。

直播现场互动问答

在直播过程中，主讲嘉宾对观众实时提出的问题进行了集中回应：

Q1. Sage AI对算力中心60%利用率的现状能否有实质性提升？

程捷回应，Bonree ONE Sage AI目前定位为企业级运维智能体工作台，尚未涉及模型推理阶段的算力调度能力。当前博睿数据的AI可观测能力聚焦于AI应用全链路的端到端性能与可用性监控，即从请求发起到模型网关、再到后台模型调用的全过程观测，暂未深入到GPU推理内部的算力调度环节。程捷表示，该方向具备较大市场潜力，博睿数据将在后续版本中逐步补全相关指标与链路采集能力。

Q2. 如何解决根因分析耗时长的问题？

袁耀辉回应，博睿数据将运维场景按监管域及事前、事中、事后阶段进行分类调度，其中事中阶段（如故障诊断、告警收敛）在优先级策略上被优先保障。在具体提效手段上，一是通过多智能体（Sub-Agent）协同，将无因果关系的查询动作（如指标核查、日志抽取、事件关联等）转为并行执行，替代原有的模型串行推理；二是在专家级智能体内部进一步引入协同机制，实现指数级的效率提升；三是引入专家算法，对巡检对象进行样本收敛，在保证准确性的前提下缩小分析范围。综合上述手段，同等算力条件下的诊断时长已由早期的十余分钟压缩至数分钟级别。程捷补充，无论是人工处理还是智能体处理，“一分钟发现、五分钟定位、十分钟解决”的方法论目标并未改变，博睿数据在预置智能体的设计中始终遵循这一标准。

Q3.是否有自我进化和知识沉淀机制？

袁耀辉回应，Bonree ONE Sage AI在提示词层面具备Few-shot自我更新机制，可根据实际运行效果持续优化用户侧提示词；在能力沉淀层面，团队将高频、必要的推理链路固化为专属Skill，从而缩短决策路径、降低模型交互频次与成本。他表示，这一设计思路借鉴了行业内代表性AI编程工具通过规则文件（Rule）实现个性化沉淀的经验，随着使用频次增加，智能体的响应路径将逐步缩短，准确性亦随之提升。

Q4.智能体能否自己持续观测系统并告警？

贺安辉回应，Bonree ONE Sage AI已预置巡检类智能体，可按设定的时间间隔对指定范围内的系统进行信号观测，涵盖日志、指标、链路等多维度异常识别，并可通过调用MCP服务直接创建告警。程捷补充提醒，持续观测并告警这一场景本身逻辑并不复杂，采用传统监控告警机制即可实现，且响应更及时、成本更低；从用户体验与成本的最佳实践角度出发，并不建议在此类简单场景中过度依赖大模型能力。

Q5.内部Token使用量情况如何？

程捷分享，Bonree ONE 4.0 版本上线初期，团队充值5000元用于测试，该额度曾支撑近一个月的使用量；进入7月后，随着内部使用习惯的建立，相关费用已增长至每月两三万元区间，消耗量级呈快速上升趋势。袁耀辉补充，当前国内外大模型厂商竞争激烈，一方面模型能力持续提升带动使用量增长，另一方面开源模型的普及也推动主流大模型价格在近期出现大幅下降。主讲嘉宾均认为，随着技术发展与竞争加剧，Token成本对用户体感与产品设计的影响将逐步让位于性能与体验层面的考量。

Q7. AI时代，博睿数据在传统产品特性和智能化产品特性上的投入分配是怎样的？

程捷回应，博睿数据整体研发团队按数据采集层、数据处理层、存储底座层、框架层与应用层进行分层建设，并非按"传统产品"与"智能化产品"划分独立团队。他表示，智能体应用同样依赖高质量的数据采集、集成与治理能力，产品交互形态虽由传统的菜单报表转变为智能体对话框，但底层数据能力建设的投入不减反增。他强调，智能化产品的核心竞争力并非局限于交互层的"薄薄一层"，而在于数据摄入、处理、建模与语义构建等底层能力的厚度积累。

Bonree ONE Sage AI 技术架构解读

程捷、袁耀辉对Bonree ONE Sage AI的整体技术架构进行了系统介绍。程捷表示，团队致力于构建的是面向企业级智能体应用与运维场景的"操作系统"，整体架构自下而上分为五层：

1.  数据源层：“解决数据全不全的问题”

包括日志、指标、调用链、告警事件等可观测信号，通过探针和数据集成能力可方便接入。同时涵盖运维资产（CMDB、知识库、工单系统）和文件资产（脚本、环境变量、密钥等），均需纳入管理并做好管控。

2.  数据模型层：“解决数据孤岛的问题”

以"实体+关系"为核心，构建统一的可观测数据模型，将指标、日志、链路、事件等数据类型与实体关系进行标准化建模。袁耀辉将该层的作用形象地概括为"数字眼镜"，其核心价值体现在三方面：一是对运维指标进行量化，弥补模型对数字类信息理解力不足的问题；二是建立标准语义体系，统一不同监控源产生的字段与语义差异；三是为模型推理链路提供结构化的决策依据。

3.  安全沙箱层：“解决安不安全的问题”

针对企业级运维场景的高安全要求，引入沙箱隔离机制，保障智能体执行过程的可管控、可追溯、可审计。袁耀辉介绍，该层在传统容器隔离基础上进行了针对性优化，通过独立可信端口实现进程间通信，在保证隔离性的同时降低性能损耗；同时针对容器间的安全风险，引入了更为精细化的部署与调度隔离方案。

4.  调度管控层：从可靠性、有效性、敏捷性、连贯性四个维度对智能体进行全生命周期管理，功能定位类似操作系统的进程调度机制。

5.  场景应用层：基于前述底座能力，围绕监管域与故障处理域构建具体的运维分析场景。

程捷强调，博睿数据的研发投入长期聚焦于底层数据采集、处理与建模能力的夯实，而非快速堆砌场景数量，这一方法论与企业级、大B端客户（尤其是金融行业客户）对安全性与可靠性的严苛要求相匹配。