包含关键字 typecho 的文章

IT服务管理已不再只是技术问题,而成为企业战略投资的重要组成部分。 然而,在许多组织中,IT 成本仍然处于“黑盒”状态: 预算支出难以拆分、服务价值难以量化、ITIL 流程与财务体系脱节。

ManageEngine卓豪 会介绍ServiceDesk Plus等统一服务平台, 企业可以将工单数据、资产成本、SLA 承诺与财务指标整合, 实现真正的 IT 服务财务透明化。

为什么 IT 成本长期难以量化?

IT 成本复杂的原因主要包括:

  • l 基础设施与业务系统混合计费
  • l 跨部门资源共享
  • l 隐性人力成本难以统计
  • l 服务质量与成本脱节

当管理层无法清晰了解 IT 成本结构, IT 部门就容易被视为“高成本中心”。

财务视角下的成本拆分模型
财务透明化的第一步,是从“系统成本”转向“服务成本”。

可按以下维度拆分:

  • l 基础设施成本(服务器、网络、云资源)
  • l 软件授权成本
  • l 支持人力成本
  • l 运维与升级成本

通过将资产与服务目录关联, 企业可以计算出单项服务的真实成本。

从成本治理到价值证明:CIO 的关键表达方式

真正成熟的 IT 财务透明化,不仅是为 CFO 提供数据, 更是帮助 CIO 建立“价值表达能力”。

建议 CIO 在汇报中采用“三段式价值表达”:

  • l 成本节约:减少浪费、提升利用率、降低重复采购
  • l 效率提升:缩短等待时间、提升自动化覆盖、提高一次解决率
  • l 风险降低:减少重大事件、提升合规审计可追溯性

Q1)Showback 与 Chargeback 必须二选一吗?

不必。许多企业会先采用 Showback 建立透明度与共识,再逐步引入 Chargeback。 如果你希望先统一流程与数据口径,可参考 ITSM 建设指南。

Q2)没有 CMDB 能做成本透明化吗?

可以先从“资产清单 + 服务目录 + 工单数据”入手,但 CMDB 能显著提升服务映射与影响分析精度。 建议逐步补齐配置管理能力。

Q3)如何衡量财务透明化项目是否成功?

可通过重复采购降低比例、云资源浪费下降、预算预测偏差收敛、以及业务部门满意度提升进行综合评估。

Q4)SLA 提升一定会导致成本上升吗?

不一定。若通过自动化与自助服务提升交付效率, SLA 提升可能伴随单位成本下降。 可参考 ITIL 实践 中关于持续改进的思路。

Q5)中小企业是否需要做 Chargeback?

多数中小企业更适合从 Showback 开始,以透明化推动自发节约,而非复杂内部结算。

昨天刚知道的,这两天浅浅试了下,分享下本人经验,鼓励大家有空可以试试看!祝大家都中奖,中奖了回来送点金币呗doge_flower

中奖情况

本人参与发票抽奖情况,目前试了9 张中了 36 元——苏州的 6 张(1 张 6 元,2 张 10 元),宁波的 2 张(2 张 5 元),上海的 1 张(未中)。

据朋友说不同城市的奖金池可能有点差异,有朋友说自己成都 30 张发票一张没中,然后苏州的 4 张都中了加起来快 100,也有说中奖金额可能是发票金额 5% 的。这个就不很清楚了,反正有羊毛薅就完事。

活动规则

不同城市之间活动略有差异,大家可以在活动规则页面里研究,大体可以参考,一般是限制一天能参与的次数、对单张发票金额、开票日期的要求。据说有些类目的发票是不能参与的,这个没细看,有人说是自己黄金首饰的发票不行,目前自己的发票还没遇到过这个问题。

试了几个城市,宁波市一天只能 2 次,苏州是一天 3 次,上海是当月 10 次;发票金额都是要求 100 元以上,开票日期得是最近开的就行。发票开好后保存到相册就行,上传界面一般都能用图片。注意得是个人发票,然后抬头写自己的真实姓名。

参与渠道

目前支持城市最多的好像就云闪付里的发票抽奖了,搜“有奖发票”然后找发票对应城市就行,支付宝里的少些。
听说京东、抖音、微信里也有能抽的,这些还没有尝试。

开票体验

拿盒马订单开票的体验还不错。盒马还挺好的,订单可以合并开票,而且拿 20 年的一笔订单试了下也能开票并参与抽奖。而且开票速度还挺快的,差不多申请后 5 分钟内就开好了。

淘宝开票还行,开票后再搜索框里输入“发票中心”就能去找到开好的发票了。搞不明白为什么有的订单只能申请纸质发票,这种跳过了,担心寄过来让我到付。有的就干脆没有开票这个按钮,也没细究了。没注意开票速度,反正就一股脑看到能开电子发票的就申请,第 2 天基本都开好了。

作者:稚柳、溪洋、吉宪

最近,“千问请全国人民喝奶茶”活动火爆全网,这种瞬时爆发的流量洪峰已成为新茶饮行业的常态化挑战。新茶饮行业的数字化演进已从最初的基础设施上云,演进为深度的云原生架构共创与能力共建,再到为 AI 原生提供确定性基座,古茗奶茶在阿里云云原生上的深度实践,正是这种演进的代表。

点击链接查看视频:https://www.bilibili.com/video/BV12Sc5zuEm2/

在新茶饮行业,每一次刷屏级的营销活动,每一杯奶茶的“丝滑”下单,背后都是对数字化基座的严峻考验,是一场应对瞬时高并发流量的技术硬仗。

作为拥有超万家门店的行业头部品牌,古茗不仅要支撑海量日常订单,更需在“周三会员日”等大促时刻,从容应对流量陡增,确保系统稳如磐石。面对高并发下的极速响应与弹性需求,古茗如何实现“大促自由”?

本期《云故事探索》栏目走进古茗,揭秘支撑新茶饮“万店时代”的云原生力量。

从口味之争到体验之战,技术成为新茶饮竞争力

“如今,一杯奶茶的竞争已不仅限于口味。”古茗科技技术运维负责人刘星光表示,在新茶饮这条日趋激烈的赛道上,“口味决定品牌的记忆度,但真正拉开差距的,是门店高峰期的稳定体验、新品迭代的速度,以及消费者触达的精准度。”

对于古茗而言,数字化的核心价值并非上线了多少系统,而是打通了供应链、门店与营销等环节,以数据驱动决策,让成功的运营模式能在全国范围内快速复制。

这意味着技术团队的角色已从“系统维护者”升级为“业务赋能者”,不仅要保障系统稳定运行,更要支撑业务的高速增长与敏捷创新。

image

古茗科技 技术运维负责人 刘星光

架构升级:微服务+DevOps,实现业务敏捷与体验统一

为支撑万店扩张与高频营销,古茗构建了以“微服务 + DevOps”为核心的云原生架构。订单、会员、库存、营销等核心业务被拆分为独立微服务,可独立开发、部署与扩缩容。其中,阿里云微服务引擎 MSE 作为服务注册与配置中心,在保障系统高可用的同时,也让古茗更聚焦业务研发。

架构升级带来的直接收益是迭代速度显著提升。刘星光表示:“一个新的优惠策略,如今可在数天内完成验证并上线,实现快速试错、快速复制。”2025 年,古茗完成底层架构的全面云原生升级,确保全国用户下单体验的一致性。

但微服务化也带来了调用链路复杂、峰值压力集中等挑战。要在流量洪峰下保持系统稳定,“异步解耦”与“流量削峰”成为关键,这正是消息队列的核心价值。

大促自由:RocketMQ Serverless 稳定可靠、弹性降本

每周三“会员日”,古茗中午 12 点的瞬时订单量可达平日数倍。传统架构下,需提前数天甚至数周预估流量、规划资源并手动扩容,不仅耗时费力,还伴随着稳定性风险与资源浪费。

在支付、营销、库存等核心链路中,古茗引入了阿里云云消息队列 RocketMQ 版 Serverless 系列,精准解决了三大痛点:

1. 极致弹性,告别容量焦虑与资源浪费

面对十万级 TPS 的瞬时并发请求,RocketMQ Serverless 无需人工干预即可秒级自动扩容,保障消息高吞吐、低延迟、不丢失、不积压,并在峰值结束后自动释放资源,真正实现按需使用、按量付费。据测算,该方案帮助古茗节省超 40% 成本。

2. 事务消息,保障业务数据最终一致性

在“支付成功后扣减库存并发放优惠券”等场景,数据一致性至关重要。RocketMQ 事务消息确保支付主流程与下游操作的最终一致性。即使下游服务短暂异常,可靠的重试机制也能保证业务最终成功,从根源上避免因数据不一致导致的资损与客诉风险。

3. 稳定可靠,让技术团队聚焦业务创新

RocketMQ 历经阿里巴巴十余年“双十一”万亿级数据洪峰验证,具备稳定可靠的 SLA 保障,并提供消息过滤、顺序消息等功能及完善的可观测工具,帮助古茗技术团队从繁琐的维稳工作中解放出来,更专注于业务创新。会员日由此成为业务增长的“加速器”,而非技术压力的“爆发点”。

image

RocketMQ Serverless 架构及弹性示意图

“拥抱云原生后,我们终于可以放手策划大规模活动了。”刘星光的话语中透露出十足的底气,“以前最怕系统崩溃,现在我们只需关心活动玩法能否打动用户。”这份底气,正源于以 RocketMQ Serverless 为代表的阿里云原生技术栈。

稳定第一:全链路可观测,让风险“可见可控”

“稳定,永远是第一位的。”刘星光反复强调,“第一是稳定,第二是效率,第三是成本。”

为保障稳定性,古茗基于阿里云日志服务 SLS、应用实时监控服务 ARMS 等产品,构建了覆盖底层基础设施到上层业务逻辑的全链路可观测体系,实现多维度监控与实时告警,全面掌握系统状态。

刘星光表示:“任何一笔异常订单(如支付或领券失败),我们都能通过全链路追踪,在分钟乃至秒级内定位根因,从而快速修复,保障用户体验。”

从工具采纳到能力共建,从云原生迈向 AI 原生

古茗与阿里云的合作,已从工具采纳深化为场景共创(如优化事务消息延迟)与能力共建(如增强消息轨迹)。古茗真实的业务场景(如节假日大促、爆款联名发布)成为 RocketMQ Serverless 等阿里云产品的“极限压测场景”与“最佳实践样板”;阿里云则将经过古茗验证的架构模式产品化,赋能更多零售客户,形成相互成就、共同成长的深度伙伴关系。

面向未来,古茗正积极探索 AI 与业务的深度融合,包括智能推荐、经营分析、AIGC 营销等。他们的思路清晰而坚定:并非“从云原生切换到 AI 原生”,而是在云原生基础上,将 AI 能力逐步叠加,让技术架构与业务共同演进。

“云原生解决了弹性、稳定和标准化的问题,这恰恰是 AI 大规模落地的前提。”刘星光总结道,“只有底座足够稳,AI 才能真正服务于业务,而不是制造新的复杂性。”

一杯奶茶,一场深刻的技术革命

从一杯奶茶的“丝滑”下单,到一场大促的从容应对,古茗的故事是新茶饮数字化转型的缩影,也是云原生技术释放业务潜能的证明:新消费品牌的护城河,正在从产品和供应链向技术深度延伸。

以云消息队列 RocketMQ 版为代表的阿里云云原生产品,正凭借其极致弹性、高稳定性和领先技术,帮助像古茗这类高速发展的企业卸下技术包袱,在激烈的市场竞争中轻装上阵,将更多精力聚焦于业务创新,让“下单丝滑,大促自由”成为新常态。

未来,随着云原生与 AI 的进一步融合,每一杯奶茶的背后,都将蕴藏着一个更智能、更高效、更稳定的数字世界。

传统IT 服务管理模式, 以事件发生后的响应为核心。系统宕机后才建单、性能下降后才排查、用户投诉后才定位问题。 这种“事后处理”的方式,虽然符合早期 ITIL 流程 的事件管理实践, 却难以满足当今数字化业务对高可用性与实时性的要求。

ManageEngine卓豪 会介绍以ServiceDesk Plus为代表的新一代平台, 正在结合 AI 分析、趋势预测与自动化能力, 推动 IT 组织从“被动响应型支持”向“预测型主动运维”升级。

被动响应的局限性:问题永远发生在你不知道的时候

被动响应模式存在三大问题:

l 问题发现依赖人工或用户报告
l 缺乏趋势数据支持
l 重复故障反复出现

在这种模式下,IT 团队往往忙于救火, 却难以真正减少事故发生次数。

预测运维的核心能力模型
预测运维并非简单的告警升级, 而是基于数据模型进行风险识别与趋势分析。

其核心能力包括:

l 异常模式识别
l 容量趋势预测
l 重复事件关联分析
l 根因预判

1. 预测运维是否适合所有企业?
中大型企业收益更明显, 但中型组织也可从关键系统开始试点。

2. 是否必须部署复杂的 AI 平台?
许多 ITSM 平台已内置基础分析能力, 可逐步扩展至预测场景。

3. 如何衡量预测运维效果?
可通过中断次数、MTTR、重复事件比例、 以及业务影响时间等指标进行衡量。

4. 自动修复是否存在风险?
自动化应设置边界与审批机制, 在可控范围内逐步扩大执行权限。

许多组织内部,IT部门长期处于“被动支持”状态。用户报障、技术人员响应、问题解决、工单关闭,这种线性模式在早期能够满足需求,但当系统数量增加、跨部门协作频率提高、业务对稳定性要求更高时,传统支持模式将逐渐暴露出结构性问题。缺乏流程标准、缺乏数据沉淀、缺乏风险控制,使IT团队长期处于救火状态。

真正成熟的ITSM体系,并非仅仅上线一套系统,而是围绕流程、组织、数据与技术构建完整治理框架。

ManageEngine卓豪 将从成熟度模型、流程治理、组织结构设计与绩效管理四个维度,系统拆解企业级ITSM建设路径。

ITSM成熟度模型的5个阶段

在企业实践中,ITSM成熟度通常经历5个阶段:记录阶段、规范阶段、整合阶段、数据驱动阶段与战略赋能阶段。不同阶段的核心特征与管理重点完全不同,理解这一演进路径,有助于制定分阶段建设策略。

流程治理与风险控制的系统化建设

在IT治理体系中,变更管理是风险控制的核心。未经审批的系统变更,往往是重大故障的诱因。因此,建立标准化变更审批流程,并通过系统进行强制执行,是提升稳定性的关键措施。

通过风险评估、影响分析与回滚计划设计,可以在实施前降低潜在影响范围。系统化流程不仅减少人为失误,也为审计与合规提供完整记录。

组织结构重塑:从技术支持团队到服务运营中心

ITSM建设不仅仅是系统部署问题,更是组织结构重塑问题。许多企业在流程设计完善之后,依然无法实现预期效果,其根本原因在于角色职责不清晰。IT服务运营需要明确区分服务台人员、二线技术支持、变更审批委员会(CAB)、问题管理负责人以及配置管理员等角色,每一个角色都应承担明确的职责边界。

在成熟组织中,服务台并非简单的“接电话团队”,而是服务协调中心。其职责包括:初步分类与优先级判断、SLA监控、跨团队协调以及用户沟通管理。二线支持团队则专注于技术解决与根因分析,而变更管理负责人负责风险评估与审批流程控制。这种分工明确的组织结构,可以避免职责重叠与管理混乱。

同时,企业应设立服务管理负责人(Service Manager),对整体流程绩效负责。该角色不仅关注工单数量,更关注服务质量指标、改进计划以及长期战略方向。通过定期服务评审会议(Service Review Meeting),可以推动持续改进机制的形成。

ITSM平台能力在战略赋能阶段的作用

当企业进入战略赋能阶段,ITSM平台的价值将进一步放大。此时,平台不仅支撑内部服务管理,还能够为业务创新提供数据支持。

例如,通过分析高频请求类别,可以判断是否需要开发新的自动化工具;通过评估资产利用率,可以优化预算分配;通过趋势分析,可以预测未来容量需求。

在这一阶段,IT部门逐渐从“成本中心”转型为“价值创造中心”。管理层可以通过平台数据理解IT投资回报率,并将IT战略纳入整体业务规划。

1. ITSM成熟度提升通常需要多长时间?
具体周期取决于组织规模与现有流程基础。通常完整成熟度提升需要6至18个月不等。

2. 是否必须一次性部署全部模块?
不必。建议优先部署事件与变更管理模块,再逐步扩展资产与问题管理功能。

3. 如何确保流程真正落地?
关键在于组织培训与绩效挂钩机制,同时通过系统强制执行标准化流程。

4. 中大型企业如何实现跨地域管理?
通过统一平台与多地点支持机制,实现集中数据汇总与分支独立管理。

接上文 对比 html 文档差异

将富文本转换成 html 后,尝试对比修改前后的页面,最开始的方案是对比 html 的 dom 内的文字和样式。
问题在于 html 的样式很灵活,不同的 css 组合起来可能显示效果是一样的。
后面想到新的方法,就是将两段 html 分别渲染成页面,截图对比像素差异,这个有一个类似的实现库 Resemble.js 实现效果代码如下。

image

这个方法的问题在于不如 git 那种文本对比灵活匹配。
目前想不到更好的方法了,求指教。

复制
<!-- 两段 html 渲染对比 -->
<!DOCTYPE html>
<html lang="zh">
<head>
  <meta charset="UTF-8">
  <title>HTML 渲染图像对比</title>
  <script src="https://cdn.jsdelivr.net/npm/[email protected]/resemble.js"></script>
  <script src="https://html2canvas.hertzen.com/dist/html2canvas.min.js"></script>
  <style>
    #preview1, #preview2 {
      width: 400px;
      height: auto;
      border: 1px solid #ccc;
      margin-bottom: 10px;
    }
    textarea {
      width: 400px;
      height: 150px;
    }
  </style>
</head>
<body>
  <h2>输入两段 HTML 代码进行渲染对比</h2>
  <div>
    <h3>HTML 1</h3>
    <textarea id="html1"><h2 style="background:#eee;padding:6px 10px;margin:0">旧 HTML</h2>
      <div id="oldPane" class="content">
        <h3>旧标题</h3>
        <p>这是一段<strong>原始</strong>文字。</p>
        <ul>
          <li>项 A</li>
          <li>项 B</li>
        </ul>
        <p>测试</p>
      </div></textarea>
    <div id="preview1"></div>
  </div>
  <div>
    <h3>HTML 2</h3>
    <textarea id="html2"><h2 style="background:#eee;padding:6px 10px;margin:0">新 HTML</h2>
      <div id="newPane" class="content">
        <h3>新标题</h3>
        <p>这是一段<strong>修改后</strong>文字。</p>
        <ul>
          <li>项 A</li>
          <li>项 B 已改</li>
          <li>项 C 新增</li>
        </ul>
      </div></textarea>
    <div id="preview2"></div>
  </div>
  <button onclick="renderAndCompare()">渲染并对比</button>
  <h3>差异图:</h3>
  <div id="result"></div>
  <script>
    async function renderAndCompare() {
      const html1 = document.getElementById('html1').value;
      const html2 = document.getElementById('html2').value;

      const preview1 = document.getElementById('preview1');
      const preview2 = document.getElementById('preview2');

      preview1.innerHTML = html1;
      preview2.innerHTML = html2;

      const canvas1 = await html2canvas(preview1);
      const canvas2 = await html2canvas(preview2);

      const img1 = canvas1.toDataURL();
      const img2 = canvas2.toDataURL();

      resemble(img1)
        .compareTo(img2)
        .onComplete(function(data) {
          const diffImage = new Image();
          diffImage.src = data.getImageDataUrl();
          document.getElementById('result').innerHTML = `
            <p>差异百分比:${data.misMatchPercentage}%</p>
          `;
          document.getElementById('result').appendChild(diffImage);
        });
    }
  </script>
</body>
</html>

image

作者:Craig S. Mullins,Mullins Consulting Inc. 总裁兼首席顾问。

原文:https://www.dbta.com/Columns/DBA-Corner/What-Makes-a-Great-DB...,Feb 12, 2026

爱可生开源社区翻译,本文约 1500 字,预计阅读需要 3 分钟。

640 (96).webp

数据库管理员 (DBA) 的角色从未一成不变。从早期的穿孔卡片和大型机时代到如今的云原生、人工智能辅助环境,DBA 的角色始终在不断发展演变。但随着我们迈入 2026 年,“​优秀 DBA​”的定义正在发生转变,而这种转变不仅仅局限于技术能力。

那么,在当今数据驱动的世界中,成为一名优秀的 DBA 需要具备哪些条件呢?

一、基本功依然必不可少!

我们不能自欺欺人:核心技能仍然至关重要。

优秀的 DBA 必须掌握数据库管理和维护的核心要点。这意味着,DBA 仍然负责维护数据库系统的完整性、可用性和性能。

他们的任务包括以下内容:

  • 数据库安装与配置​:搭建数据库服务器并进行配置,以满足组织的需求。
  • 数据库模式创建和变更管理​:设计和实现数据库模式和结构,并根据业务变更的需要进行修改。
  • 性能监控和调优​:通过优化查询、索引和管理资源,确保数据库系统高效运行。
  • 备份与恢复​:实施稳健的备份策略,确保在发生故障时能够恢复数据。
  • 数据迁移​:负责根据组织需求,高效、准确地将数据从一个地方迁移到另一个地方。
  • 安全管理​:保护数据免受未经授权的访问,并确保符合监管要求。

基本原理不会消失 —— 它们只是被应用到更复杂、更分散的环境中。 但仅仅知道如何做某件事已经不够了。你还需要知道为什么、何时以及何地这样做 —— 尤其是在管理跨越本地、云端和边缘的混合架构时。

二、了解业务

此外,优秀的 DBA 必须了解数据库应用的业务需求,并能够管理数据库以避免业务中断。如果 DBA 对数据库和数据为业务带来的价值缺乏深刻理解,就很难实施能够优化业务数据利用的策略。

三、云计算能力

数据管理领域最显著的转变之一是向云端解决方案的迁移。到 2026 年,云计算不再是一种趋势,而将成为默认选项。

现代 DBA 必须适应数据存储在 AWS、Microsoft Azure 和 Google Cloud Platform 等云平台上的环境。这种转变带来了新的挑战和机遇,其中包括:

  • 可扩展性和灵活性​:云平台提供可扩展的解决方案,可以随着组织的需求而增长,但数据库管理员必须学习如何管理和优化这些环境。
  • 成本管理​:了解并控制云服务的成本影响至关重要。数据库管理员需要在不影响性能的前提下实施经济高效的策略。
  • 数据安全​:确保云端数据安全需要深入了解云安全模型和最佳实践。

四、拥抱人工智能

自主数据库和人工智能监控工具的兴起并没有使 DBA 过时,反而使他们变得具有战略意义。

2026 年优秀的 DBA 懂得如何利用自动化消除繁琐的工作,专注于架构设计、合规性和数据治理等更高价值的任务。

人工智能的应用也在不断增长,这意味着 DBA 需要掌握人工智能和机器学习方面的知识,才能充分利用人工智能为其工作带来的优势。人工智能功能正被融入到数据库管理系统中。DBA 需要了解并掌握这些人工智能功能,才能在 2026 年保持竞争力。

通过扩展对人工智能技术和方法的知识和理解,DBA 可以更好地、更高效地在云端使用数据库,更好地利用数据进行分析和可视化,并利用人工智能的强大功能来更好地保护其数据库系统。

DBA 不应惧怕人工智能,而应训练、调优并利用它来提升自身影响力。换句话说,人工智能不会取代 DBA,但运用人工智能的 DBA 将会取代其他 DBA。

五、安全与合规的负责人

随着数据泄露事件频频登上新闻头条,全球监管力度不断加强,DBA 如今已成为抵御数据泄露的第一道防线。优秀的 DBA 不仅精通加密、访问控制、审计跟踪,还了解如何为合规性审查做好准备。他们不仅要确保数据库正常运行,更要保障企业免受风险。

六、跨职能合作者

过去那种躲在角落里守口如瓶的 DBA 形象早已过时。如今的 DBA 与开发人员、数据科学家、DevOps 团队和业务分析师紧密合作。他们精通 API、CI/CD 流水线和数据湖等技术,并且懂得如何将业务需求转化为技术解决方案。

七、终身学习者

科技发展日新月异。优秀的 DBA 都是终身学习者 —— 他们阅读、实验、考取证书、分享经验。他们参加会议、参与论坛讨论,并指导下一代。他们不仅紧跟时代步伐,更引领潮流。

简而言之,2026 年优秀的 DBA 将是集技术专家、战略家、商人、外交家于一身的混合型人才。他们不仅管理数据库,还要管理复杂性、风险和机遇。

对于那些勇于接受挑战的 DBA 来说,未来一片光明。

在金融、制造、能源、医疗以及大型集团型企业中,IT 服务的每一次响应、审批与变更,往往都需要经得起事后审计与责任追溯。 这意味着 IT 服务管理平台不仅要高效,更要具备可治理、可审计、可追责的能力。

ManageEngine卓豪 将围绕“治理优先”的 ITSM 建设思路,系统梳理治理型 ITSM 的核心理念、设计原则与实践路径, 并结合企业真实场景,解析如何逐步构建一套稳定、可控、可持续演进的 IT 服务管理体系。

为什么传统 ITSM 难以支撑企业治理需求

在许多组织中,ITSM 的引入往往以“提升效率”为主要目标。只要事件能够被记录、分派并最终关闭, 管理层便认为服务管理体系已经建立。然而,当企业开始面临外部监管、内部审计或跨部门问责时, 这些看似完整的流程往往暴露出明显短板。

常见的问题包括但不限于:工单关键信息缺失、审批流于形式、变更与事件之间缺乏因果关联、 责任人界定模糊以及服务决策无法复盘等。 这些问题并非工具能力不足,而是服务管理在设计之初未将“治理”作为核心目标。

从治理角度看,一个真正成熟的 ITSM 体系,必须能够回答以下问题:

l 为什么当时做出这样的处理决策?
l 是谁在什么依据下批准了该操作?
l 相关信息是否完整、是否被篡改?
l 该事件是否暴露了系统性风险?

如果 ITSM 系统无法为这些问题提供清晰答案,那么即使流程再顺畅,也难以支撑企业级治理要求。

治理型 ITSM 的核心目标与价值定位

治理型 ITSM 并非追求流程复杂化,而是通过系统化设计,使每一次 IT 服务行为都具备明确的边界与可解释性。 其核心目标可以概括为三个方面:风险可控、责任清晰与决策可追溯。

治理型 ITSM 强调风险前移。通过在流程中嵌入控制点与校验机制, 组织能够在问题发生之前识别潜在风险,而非在事故发生后被动补救。

治理型 ITSM 要求责任明确。无论是事件处理、问题分析还是变更实施, 系统都必须清晰记录责任角色与操作轨迹,避免“集体负责却无人负责”的情况。

治理型 ITSM 必须支持决策复盘。管理层不仅需要知道“发生了什么”, 更需要理解“为什么会这样发生”,从而持续优化服务管理策略。

治理型 ITSM 的落地路径:从理念到体系化能力

在实际落地过程中,治理型 ITSM 并不是一次性“大重构”,而是一个循序渐进、逐步成熟的过程。 成功的组织通常会将治理能力拆解为多个可实施阶段,在不影响现有服务稳定性的前提下,逐步提升管理深度。

第一阶段通常聚焦于流程标准化与数据完整性。此阶段的核心目标是确保所有 IT 服务请求、事件与变更, 都通过统一入口进入系统,并在关键字段、状态流转与角色分配上形成一致规范。

第二阶段开始引入控制点与审计能力。通过在审批、变更、SLA 例外等关键节点设置强制校验规则, 系统能够自动阻断不符合治理要求的操作,并为后续审计提供可靠数据来源。

第三阶段则进一步迈向治理驱动的持续优化。管理层不再仅依赖静态报表, 而是通过趋势分析、问题关联与根因复盘,持续调整服务策略与资源配置。

治理能力如何在 ServiceDesk Plus 中体系化实现

在实践中,治理型 ITSM 并不依赖“额外工具堆叠”,而是依托平台本身的流程引擎、权限体系与数据模型。 以 ServiceDesk Plus 为例,其治理能力体现在多个层面。

在流程层面,ServiceDesk Plus 通过可配置的请求生命周期、审批流与变更流程, 确保不同类型的 IT 服务在执行路径上保持一致性与合规性。

在控制层面,平台支持基于条件的业务规则与自动化校验, 可在工单创建、状态变更或审批过程中自动检查必填信息、风险等级与授权范围。

在审计层面,所有操作均被记录为系统日志,包括字段变更、审批意见与执行时间点, 为内部审计与合规检查提供原生数据支持。

近日,中国信息通信研究院正式发布第四期《数字安全护航技术能力全景图》,全知科技凭借在数据安全领域的长期技术积累与规模化落地实践,成功入选了全景图三大领域12项细分赛道,覆盖安全合规、安全咨询与规划、数据库安全、数据安全态势感知、数据分类分级、数据要素流转安全、数据安全治理服务、数据安全评估和检查、数据安全平台、Web应用扫描与 监控、API安全、应用安全监测。充分彰显了公司在数据安全领域扎实的技术底座与行业影响力。
图片

图片

图片
《数字安全护航技术能力全景图》由中国信息通信研究院组织编制,是数字安全领域具有广泛影响力的重要行业风向标,旨在系统呈现我国数字安全产业的核心能力结构,清晰梳理关键技术的发展脉络,精准对接行业实践需求,构建权威、全面的能力图谱,为数字中国建设夯实安全基础。
图片
此次入选第四期《数字安全护航技术能力全景图》,充分体现了全知科技在数字安全领域的综合技术实力与持续创新能力,既是行业对其技术积累与实践成果的权威肯定,也印证了公司长期深耕数字安全方向的发展路径。未来,全知科技将持续围绕数据安全核心问题推进能力建设,在夯实底层技术研究的基础上,不断强化工程化落地与规模化应用能力。公司将结合行业标准演进与真实业务场景需求,持续完善数据安全整体技术体系,通过产品能力的持续迭代与服务模式的优化升级,推动安全能力与业务发展的深度融合,为数字中国建设提供可持续、可演进的安全支撑。

春节期间,多家 AI 应用推出红包、互动等活动,迎来用户高峰。豆包作为央视春晚的 AI 互动伙伴,在亿级并发场景下全程稳定运行。

但高流量压力下出现的服务不稳定,仍是行业普遍面临的挑战。这再次印证:在 AI 走向全民交互的时代,系统稳定性已从幕后保障,跃升为核心竞争力。

一、“被动救火”式传统运维为何在AI时代难以为继?

当系统出现波动,“正在紧急加资源”这类回应,暴露了传统运维的根本局限:它是一种典型的事后响应模式。

在这种模式下,运维团队常常扮演着“消防员”的角色,并呈现出三个显著特征:

  • 问题驱动:只有在系统发出告警甚至发生宕机后,才开始介入处理;
  • 依赖人力:高度依靠资深工程师的经验,通过“人肉作战室”的方式逐层排查;
  • 响应滞后:从发现问题、定位根因到完成修复,往往耗时过长,业务已遭受实质性影响。

在业务架构相对简单的时代,这一模式尚能勉强运转。但在 AI 应用全民化、流量脉冲高度不可预测的今天,它已难以为继:微小的性能抖动,可能在秒级内被放大为全局故障;系统稳定性容错空间几近于零。

运维,亟需一场从被动响应到主动掌控的范式升级。

二、云智慧 Castrel AI——让主动预防式运维真正落地

将主动预防式运维的理念转化为现实,需要一个真正理解运维场景的智能体。

云智慧的AI SRE Agent产品——Castrel AI (鹰眼 AI SRE Agent)正是为此打造 ——它深度融合全栈可观测数据与运维专家经验,通过持续学习,让主动预防真正可执行

01、风险预判,提前识别隐患

在流量洪峰到来前,SRE智能体——Castrel AI通过时序数据分析和机器学习能力,预判容量瓶颈与性能风险,提前发出预警,让团队有充足时间扩容或优化,避免陷入“紧急加资源”的被动局面。

图片

02、智能告警降噪 + 根因调查,分钟级定位故障

当异常发生时,运维AI Agent——Castrel AI 首先通过智能警报分类,自动聚合指标、日志与链路信号,过滤高达 90% 的无效告警;随后启动 AI 事件调查流程,关联变更、拓扑与部署记录,生成带证据链的根因假设。在实测中,MTTR 从超 60 分钟缩短至 15 分钟以内,彻底告别“人肉作战室”。

图片

03、智能决策与安全执行,加速恢复闭环

作为面向 SRE 场景的 AI Agent,Castrel AI 基于知识图谱与历史经验,智能推荐最佳恢复路径,并在预授权范围内安全执行扩缩容、配置回滚等操作。

SRE 团队还可通过 AI 助手随时查询上下文,实现从“告警”到“高效处置”的闭环,显著降低 MTTR。

图片

春节期间的流量大考,成为推动 AI 行业运维理念升级的重要催化剂。云智慧 Castrel AI将持续以主动预防式运维为核心,助力企业在复杂环境中守住稳定性底线,让每一次 AI 创新都建立在可靠的基础之上。

详询热线:400-666-1332,点击了解更多Castrel AI的应用场景与案例

*本文涉及数据来源于内部统计

音视频技术选型与实施指南:打造卓越交互体验
在移动互联网与数字化转型加速推进的背景下,音视频功能已成为各类应用服务的标配。无论是远程协作、在线课堂,还是社交娱乐、电商直播,流畅、清晰、稳定的音视频交互能力直接影响用户留存与产品口碑。因此,如何科学选型并高效集成音视频 SDK,成为产品与技术团队必须面对的关键课题。
音视频 SDK 的选型维度

  1. 场景化需求分析
    不同业务对音视频能力的要求差异显著。例如,在线会议系统需侧重多人实时通话、屏幕共享与会议管理;娱乐直播平台则更关注美颜特效、连麦互动与低延迟观看;而安防监控类应用可能强调视频流畅度与端到端加密。在选型前,必须梳理清晰自身业务的核心功能、并发规模、用户群体及未来拓展方向。
  2. 技术能力评估
    需从多个技术层面进行考察:

架构适配性:SDK 是否易于融入现有技术栈,支持主流开发语言与框架;

抗弱网能力:在高丢包、高延迟等复杂网络环境下,能否保持音视频连贯可用;

资源占用:SDK 在 CPU、内存、电量等方面的消耗是否在可接受范围;

可定制性:是否支持按业务需要进行功能扩展或界面定制。

  1. 供应商与生态调研
    通过行业技术社区、开发者论坛、第三方测评报告等渠道,了解各服务商的技术实力、产品迭代频率与客户案例。尤其应关注实际用户的长期使用反馈,包括稳定性、技术支持响应速度等实操层面的体验。
  2. 综合成本考量
    除直接的授权费用外,还需评估后续的维护成本、功能扩展费用、流量与带宽支出,并结合预估的业务收益进行投入产出分析。部分服务商采用按用量计费模式,需根据业务模型测算长期成本。
  3. 安全与合规性
    音视频数据传输与存储需符合相关法律法规(如 GDPR、个人信息保护法等)。应确认 SDK 提供端到端加密、防篡改、访问控制等安全机制,并具备相应合规认证。
    高效集成与落地实践
  4. 借助专业支持
    在集成初期,积极利用服务商提供的技术文档、Demo 示例、API 手册及开发者社区资源。遇到复杂问题时,及时寻求官方技术支持,可显著降低调试难度与时间成本。
  5. 开展多阶段测试
    在开发环境中进行单元测试与集成测试,确保基础功能正常;在模拟或真实网络条件下进行压力测试与兼容性测试,验证 SDK 在各类设备与系统版本上的表现;上线前还需组织用户体验测试,收集反馈并优化交互细节。
  6. 采用模块化设计
    将音视频功能封装为独立模块,实现与主业务逻辑的解耦。这不仅能提升代码可维护性,也便于后续功能升级或 SDK 更换,降低系统迭代风险。
  7. 确保多端一致体验
    当前用户常跨手机、平板、电脑等多设备使用应用,因此需确保 SDK 在各主流平台(如 Android、iOS、Web、Windows 等)上具备一致的功能表现与接口设计,并提供统一的错误处理机制。
    技术方案示例:CRTC 音视频服务
    CRTC 提供基于自研引擎的全链路音视频解决方案,其特点包括:

高清视听体验:支持 4K 超清视频与 48kHz 高保真音频,结合 AI 超分、智能降噪、回声消除等技术,在弱光或嘈杂环境中仍保持清晰通话;

强网络适应性:在高达 80% 丢包率的极端网络条件下,仍可维持可用通话,有效缓解卡顿、断断续续等问题;

跨平台兼容:提供 Android、iOS、Web、Windows、macOS、Linux 等原生 SDK,并支持 Flutter、Electron、Unity 等开发框架,便于快速集成;

安全可靠:支持全链路 AES 及国密加密,满足各类业务对数据安全与合规的要求。

该方案适用于教育、医疗、社交、远程协作等多种对音视频质量、可控性及成本均有要求的场景。

图片

结语
音视频 SDK 的选型与集成是一项系统工作,需要结合业务目标、技术条件与资源投入进行综合权衡。通过清晰的场景分析、严谨的技术评估、充分的测试验证以及模块化的实施路径,团队可以更稳健地构建出体验优异、稳定可靠的音视频交互能力,从而在激烈的市场竞争中赢得用户青睐。

摘要

当你在深夜盯着 AI 生成的「幻觉代码」抓狂,当你在第 10 次重复解释项目架构时怀疑人生——你可能不是遇到了模型瓶颈,而是踩了「上下文工程」的坑。驭码CodeRider 最新迭代的上下文工程体系,用系统化的信息架构彻底终结 AI「瞎猜式编程」,让编码智能体从「概率复读机」进化为「全知型开发伙伴」。本文将深度拆解这套被 Shopify CEO Tobi Lütke 和 OpenAI 大神 Andrej Karpathy 共同推崇的技术,看看它如何让 AI 真正「看懂」你的代码世界。


一、AI 编程的「隐形天花板」:不是模型不行,是信息喂得不对

「帮我改个 Bug。」——这是你发给 AI 的第 100 条指令。

「请问这个函数在哪个文件?项目的整体架构是什么?你们团队用的状态管理是 Redux 还是 Zustand?」——这是 AI 的第 100 次反问。

如果你每天都在经历这种「挤牙膏式沟通」,那你正在为一个技术认知差买单:上下文工程(Context Engineering)的缺失

传统 AI 编程工具就像是只带了一部分装备上战场的士兵——模型能力再强,如果缺乏精准的环境感知、任务背景和历史记忆,也只能在代码库里「摸黑探索」。这种现象被业界称为 「Jagged Intelligence」(锯齿状智能):AI 在某些场景下表现惊艳,但一旦脱离特定上下文,性能断崖式下跌。

Shopify CEO Tobi Lütke 曾在技术峰会上直言:「比起提示词工程,我更喜欢上下文工程这个术语,它才真正描述了我们日常工作的核心技能。」 前 OpenAI 创始成员 Andrej Karpathy 更是将其定义为 「填充上下文窗口的艺术与科学」


二、上下文工程:给 AI 装上「全景雷达」与「战术手册」

那么,上下文工程到底是什么?简单来说,它是一门为大语言模型(LLM)动态组装「恰到好处」信息的系统性工程

如果把 AI 比作处理工作的员工,上下文就是它的「工作手册 + 记忆库 + 工具箱」。驭码CodeRider 的上下文工程体系,正是围绕这三大维度构建的精密信息架构:

1. 指导性上下文:给 AI 定好「战术规则」

这部分是 AI 的「操作指南」,明确告诉它该做什么、怎么做。驭码CodeRider 通过动态系统提示词生成机制,实现了高度模块化的指令编排:

  • 多模式角色定义:架构师(Architect)、开发者(Code)、调试员(Debug)、协调员(Orchestrator)——每种模式都有独立的上下文权重和工具集
  • 智能环境适配:自动检测操作系统、Shell 环境、工作目录,甚至根据项目类型调整代码风格偏好
  • 规则层次化:支持全局规则(个人习惯)→ 项目规则(团队规范)→ 模式规则(特定场景)的三级覆盖体系

就像一位经验丰富的技术 Leader,驭码CodeRider 能在不同场景下自动切换「管理风格」:做架构设计时宏观把控,写代码时关注细节,Debug 时聚焦日志。

2. 信息性上下文:构建代码世界的「知识图谱」

这是 AI 完成工作的「弹药库」。驭码CodeRider 实现了多维度、跨文件、语义级的信息感知:

本地操作+时间维度感知:通过与IDE各种操作事件结合,结合 UnifiedDiff 算法分析变更意图

语义相似度匹配:采用优化的杰卡德相似度算法(Jaccard Similarity),智能处理驼峰命名、蛇形命名等编程语言特化特征,精准定位相关代码片段

LSP + AST 深度解析:基于 Language Server Protocol 和抽象语法树,实现跨文件的符号引用追踪。当你在修改一个接口定义时,AI 能自动感知所有调用点的上下文

树形任务隔离:父子任务采用严格的上下文隔离机制。父任务创建子任务后完全暂停,子任务拥有独立的对话历史、错误计数和工具使用记录,完成后通过标准化的结果集成机制无缝恢复

这种设计解决了传统 AI 工具最令人头疼的「上下文污染」问题——不同任务之间的信息不会相互干扰,就像为每个需求开辟了独立的「战场」。

3. 行动性上下文:配备「瑞士军刀」工具链

让 AI 不仅能思考,还能动手做事。驭码CodeRider 集成了精选的 MCP(Model Context Protocol)工具生态:

  • 文件系统操作:读取、搜索、编辑、执行命令
  • GitLab 原生集成:代码仓管理、MR 评审、流水线控制
  • 外部知识库:自动查询文档、检索最佳实践

这些工具不是简单的「功能堆砌」,而是通过上下文感知智能调度。例如,当 AI 检测到当前处于调试模式时,会自动调用日志分析工具;当识别到架构设计任务时,会优先激活绘图和文档生成能力。


三、从「机械执行」到「认知协同」:上下文工程的四大实战突破

突破一:终结「失忆症」——树形任务隔离机制

传统 AI 编程最痛的点是什么?长周期任务中的上下文腐烂

想象你在处理一个涉及 20 个文件的 Refactor 任务,进行到第 15 步时,AI 已经「忘记」了第 3 步做的关键决策,导致代码风格前后不一致。驭码CodeRider 的解决方案是严格的父子任务隔离

每个子任务都是一次「干净的 slate」,拥有独立的:

  • 任务唯一标识与执行状态追踪
  • 错误计数器
  • 模式特定的工具权限(如 Debug 模式独占日志分析工具)
  • To-do 列表驱动的进度管理

当子任务完成时,系统执行原子性状态恢复:父任务自动回退到原始模式,子任务结果以结构化格式注入父任务上下文,通过跳过一次上一个响应唯一标识机制确保对话连续性。

这就像有一个永不疲倦的项目经理,既能将大项目拆分成独立子任务分配给不同专家,又能在每个节点精准同步信息,确保团队认知始终保持一致。

突破二:精准「读心术」——意图驱动的上下文构建

驭码CodeRider 不是简单地把所有代码塞进上下文窗口,而是基于编辑意图动态组装信息:

意图类型上下文策略技术实现
代码生成(add)提供上下文模板 + 相邻代码片段基于当前编辑状态,获取编辑位置、相邻代码信息和本地操作序列信息
问题修复(fix)专注错误诊断信息 + 相关调用链集成工作区 build 或 test 的 problems 与 errors 与 LSP 符号分析
通用编辑(edit)综合诊断信息 + 跨文件引用混合检索策略(Jaccard + LSP)

例如,当你选中一段报错代码并触发修复时,AI 不会傻傻地分析整个文件,而是精准提取:

  1. 当前文件的语法错误和警告
  2. 该函数在代码库中的所有调用点
  3. 相关的类型定义和接口约束

这种意图感知的上下文裁剪,让 Token 消耗降低 60% 的同时,准确率反而提升。

突破三:环境「全景感知」——从黑盒到白盒

传统 AI 插件就像在黑房间里编程,而驭码CodeRider 通过获取当前系统与编程环境的全局状态实现了全方位的环境透视

image.png

这意味着 AI 知道:

  • 你正在同时查看哪几个文件(跨文件关联)
  • 哪个终端正在运行编译命令(避免冲突操作)
  • 刚刚修改了哪些文件(变更影响范围)
  • 当前使用的操作系统和 Shell(命令适配)

这种环境感知不是简单的「信息展示」,而是驱动智能决策的核心输入。 例如,当检测到终端正在运行测试套件时,AI 会主动推迟文件写入操作;当识别到多文件同时打开时,会自动增强跨文件引用分析。

突破四:上下文「保鲜术」——动态压缩与去重

面对复杂项目,驭码CodeRider 采用多层级的上下文质量管理

  1. 唯一性过滤:通过是否是不重复的上下文条目判断避免重复信息注入
  2. Token 预算管控:实时计算剩余 Token 预算,智能截断或压缩超长内容
  3. 重叠消除:去重算法合并重复代码范围
  4. 动态摘要:对长文档自动生成结构化摘要,保留关键决策点

这就像为 AI 配备了一位专业的信息策展人,在海量代码库中筛选出「恰到好处的信息量」,既避免「信息过载」导致的注意力涣散,又杜绝「信息贫乏」引发的胡乱猜测。


四、Vibe Coding 时代的「定海神针」:为什么上下文工程决定成败

2025 年,AI 编程进入「Vibe Coding」(氛围编程)时代——开发者用自然语言描述意图,AI 负责具体实现。但这种模式有一个致命前提:AI 必须真正理解你的「氛围」

没有上下文工程的 Vibe Coding,就像在没有地图的情况下自驾游——看起来很自由,实际上处处碰壁。驭码CodeRider 的上下文工程体系,正是为 Vibe Coding 提供了工业级的可靠性保障

  • 当我说「优化那个接口」时,AI 知道指的是用户模块的 REST API,而不是支付网关的 gRPC 接口
  • 当我说「按照团队规范来」时,AI 能读取 .crkilo/rules 目录下的自定义规则,而不是套用通用模板
  • 当我说「继续上次的工作」时,AI 通过 Memory Bank 调取完整的项目记忆,而不是让你从头复述

这种「懂你所想」的背后,是上下文工程从「提示词优化」到「信息架构设计」的范式跃迁

正如 Anthropic 最新研究指出的:上下文工程不是提示工程的替代品,而是其战略升级——前者关注「如何说」,后者决定「说什么、何时说、如何组织」。


五、CodeRider:不止于工具,更是企业级 AI 研发基础设施

当我们谈论上下文工程时,本质上在谈论一个更宏大的命题:如何让 AI 真正融入企业研发的血脉,而非停留在工具层面

这正是驭码 CodeRider 的使命。作为全球第一的私有化 DevOps 平台极狐GitLab 推出的 AI 编程智能体,CodeRider 正在重新定义 AI 时代的软件研发范式:

一体平台 · 全域智能

CodeRider 不是又一个孤立的 AI 插件,而是与 GitLab 原生融合的研发全链路智能中枢

  • 全流程 AI 赋能:从需求理解、代码生成、跨文件补全,到智能代码评审、单元测试生成、流水线自动修复——所有环节共享同一套上下文体系,避免工具割裂导致的认知断层
  • 统一数据架构:代码、文档、流水线配置、评审记录全部沉淀在 GitLab 端,形成单一可信数据源(Single Source of Truth),AI 的每一次决策都有完整的历史上下文支撑
  • 本土化深度适配:针对中国开发者的编码习惯、国内云生态、合规要求做深度优化,响应速度比国际产品提升 40%

双轮驱动 · 效能倍增

AI Coding + AI DevOps 不是简单的功能叠加,而是代码智能生成代码仓智能管理的协同进化:

  • 在 IDE 侧,驭码CodeRider 通过上下文工程实现「所想即所得」的编码体验
  • 在 GitLab 侧,AI 驱动的 MR 智能评审、安全扫描解析、议题自动关联,让代码管理从「人工审核」升级为「智能把关」
  • 两者的上下文互通,意味着 AI 能追踪从「第一行代码提交」到「生产环境部署」的完整生命周期,真正实现 「端到端的上下文连续性」

三种部署 · 灵活安全

企业级 AI 应用的核心焦虑在于数据主权。CodeRider 提供全场景覆盖的部署方案:

部署模式适用场景核心优势
SaaS 云端中小团队快速启动开箱即用,免运维,资源弹性扩展
混合架构敏感代码本地处理,通用能力云端调用平衡安全与效能,成本最优
私有化部署金融、政务、央企等强合规场景数据 100% 自主掌控,支持国产操作系统与数据库

无论哪种模式,上下文工程的核心优势始终不变:你的项目记忆、团队规范、代码知识图谱,完全由你掌控

SOTA 模型 · 持续领先

在模型层,CodeRider 提供业内独有的国内 SOTA 大模型灵活切换能力

  • 已接入 GLM-4.7、MiniMax M2.1、DeepSeek-V3.2、Qwen3-VL-235B 等顶尖模型
  • 支持自定义第三方模型接入,构建专属 AI 编码体验
  • 通过上下文工程层的抽象,模型切换无需改动业务代码,始终保障技术领先性

这意味着你永远不会被单一模型绑架。当更强的模型出现时,CodeRider 的上下文工程体系能让它立即「读懂」你的项目,无缝接续工作。


写在最后:当 AI 拥有「完整的上下文」,编程将变成什么样?

我们正站在 AI 编程的拐点。从「提示词工程」到「上下文工程」,不是术语的更迭,而是**从「调教 AI 说话」到「构建 AI 认知体系」**的质变。

驭码CodeRider 的上下文工程实践告诉我们:当 AI 真正拥有环境感知能力任务隔离机制语义级代码理解长期记忆系统,编程不再是人与机器的反复拉扯,而是一场基于共同认知的流畅协作

你的 AI 不再问「这个变量是什么类型」,因为它看了你的类型定义文件;不再问「这个函数在哪里被调用」,因为它构建了完整的调用图谱;不再问「你们团队的命名规范是什么」,因为它读取了你的规则配置文件。

这就是上下文工程带来的「无摩擦编程」体验——你专注于解决业务问题,AI 专注于理解你的上下文。

驭码 CodeRider,作为全球第一的私有化 DevOps 平台推出的 AI 编程智能体,正在将这一愿景变为现实。无论你是追求极致效能的个人开发者,还是需要安全合规的企业团队,CodeRider 的上下文工程体系,都能让 AI 真正「看懂」你的代码世界。

现在,是时候让你的 AI 摆脱「七秒记忆」,进化成拥有「完整认知」的开发伙伴了。

请访问 gitlab.cn 了解更多信息

作者:辰泉

image

概述

函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

在开发 AgentRun 的过程中,我们发现了一个让人头疼的问题:现有的沙箱方案太零散了。浏览器、代码执行、Shell 环境各自为政,导致开发效率大打折扣。于是我们决定自己动手,打造一个真正一体化的解决方案——All-In-One Sandbox(AIO)。

AIO 是 AgentRun 提供的云上浏览器自动化沙箱环境,它把浏览器、终端和代码执行能力全部集成在一个容器里。通过简单的 SDK 调用,你就能让 LLM 驱动复杂的 Web 自动化任务,再也不用在多个沙箱之间疲于奔命。

为什么选择 AIO?

说实话,传统的沙箱方案让我们吃尽了苦头。大多数沙箱都是单一用途的(要么只能跑浏览器,要么只能执行代码),这带来了几个实实在在的痛点:

1. 文件共享简直是个噩梦

  • 浏览器沙箱下载的文件得先上传到 NAS/OSS,代码沙箱才能用
  • 代码生成的文件又要重新上传,其他沙箱再下载
  • 多个沙箱之间的文件传递慢得像蜗牛爬

2. 工具协调复杂到想哭

  • 一个完整的 Agent 任务通常需要同时调用浏览器 + 代码 + Shell
  • 得手动编排多个沙箱的启动、通信和数据传递
  • 调试时要在好几个地方来回切换看日志,效率低得让人抓狂

3. 环境配置繁琐到崩溃

  • 本地方案:Node.js、浏览器、各种系统依赖,装得手都酸了
  • 多沙箱方案:每个环境都要单独配置和管理
  • 最要命的是环境污染问题——任务之间互相干扰,资源清理成了日常难题

4. 成本和效率双重打击

  • 多个沙箱同时运行,内存占用翻倍
  • 文件传输走网络 I/O,延迟高得离谱
  • 还得额外付费买 OSS/NAS 存储服务

AIO 沙箱的核心优势

架构一览

image

统一文件系统

我们的解决方案很简单粗暴:把所有组件(浏览器、Shell、代码执行、文件系统)都塞进同一个沙箱实例里。

image

性能对比一目了然:

对比项传统多沙箱方案All-In-One 沙箱
启动时间2 个沙箱启动 = 4-15秒(串/并行创建)1 个沙箱启动 = 5秒
文件传递通过 OSS,耗时 2-3秒直接访问,<100ms
内存占用2×独立运行 = 2c2g+2c2g1×共享运行 = 2c2g

底层技术栈很扎实:

  • 浏览器:Chromium 136+ (固定版本,稳定可靠)
  • 协议:WebSocket CDP (:5000/ws/automation 端口)
  • 隔离:函数计算资源、本地文件系统的隔离及严格的资源限制
  • 文件系统:支持实例级别的 NAS/OSS 动态挂载

五大核心能力,开箱即用:

  • 代码执行:内置 Node.js + 原生 Puppeteer 自动化脚本支持
  • 文件处理:提供 FileSystem API,可通过 MCP 方式调用
  • 状态保持:结合 OSS/NAS 动态挂载,完美支持多步骤任务和状态传递
  • 实时日志:流式输出执行日志,监控起来毫不费力
  • 多工具集成:VNC、Terminal、代码执行无缝配合,想怎么用就怎么用

云上沙箱,真的零配置

基于函数计算架构,我们做到了:

  • 零配置:不用装任何环境,API 调用就能直接上手
  • 环境隔离:每次执行都是全新的沙箱,完全互不干扰
  • 自动清理:执行完自动释放资源,绝不留垃圾
  • 安全可控:代码在隔离环境中运行,Agent 宿主系统稳如泰山
  • 按需扩展:根据负载自动创建/销毁沙箱实例,省钱又省心

多种访问方式,灵活到飞起

不管你是开发者还是运维,都能找到适合自己的使用方式:

接口用途访问方式
代码执行 API执行 Node.js/Python 脚本SDK 方法
VNC可视化浏览器交互、人工介入Web 集成
Terminal WebSocket实时 Shell 交互WebSocket
文件 API读写持久化文件SDK 方法

这些场景特别适合用 AIO:

  • 数据采集(电商、社交媒体、新闻网站)
  • 自动化测试(Web 应用功能测试)
  • RPA 任务(表单填写、批量操作)
  • LLM Agent(让 AI 自动生成和执行浏览器自动化脚本)
  • 云开发环境(团队标准化工具和远程开发)
  • 多步骤工作流(带有视觉反馈的自动化流程)

AIO 沙箱集成指南

1.1 核心概念

沙箱实例到底是什么?

每个沙箱实例本质上就是一个基于函数计算环境的会话容器,里面已经预装好了你需要的一切:

  • Chromium 浏览器(已启动,监听在 CDP 端口 5000)
  • Node.js 运行时(预装 puppeteer-core)
  • VNC 服务(可选,调试和人工介入时超有用)

1.2 快速开始

注意:本文假设你已经看过前面的实践系列文章,了解 template 和 sandbox 的关系,并且正确创建了 template。如果你还没做过这些,建议先回去补课。

安装 SDK(很简单)

推荐用 python 3.11 环境,兼容性最好。

pip install agentrun-sdk['server','playwright']

第一个任务:验证沙箱基本功能

from agentrun.sandbox import Sandbox, TemplateType
import asyncio
async def quick_start():
    """验证沙箱基本功能"""
    sandbox = Sandbox.create(
        template_type=TemplateType.AIO,
        template_name="quick-test",
        sandbox_idle_timeout_seconds=600
    )
    print(f"沙箱已创建: {sandbox.sandbox_id}")
    # 核心:连接已运行的浏览器,提取页面信息
    code = """
const puppeteer = require('puppeteer-core');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
await page.goto('https://example.com');
console.log(await page.title());
await browser.disconnect();
"""
    await sandbox.context.execute_async(code=code, language="javascript")
    sandbox.destroy()
asyncio.run(quick_start())

多步骤任务实战

关键技巧: 用 disconnect() 保持浏览器运行,通过文件系统传递状态。

第一步:打开登录页

const puppeteer = require('puppeteer-core');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
await page.goto('https://example.com/login');
console.log('请在 VNC 中完成登录');
await browser.disconnect();

第二步:保存 Cookie

const fs = require('fs');
const puppeteer = require('puppeteer-core');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
const cookies = await page.cookies();
fs.writeFileSync('/home/user/data/cookies.json', JSON.stringify(cookies));
console.log('Cookie 已保存');
await browser.disconnect();

第三步:用 Cookie 爬数据

const fs = require('fs');
const puppeteer = require('puppeteer-core');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
const cookies = JSON.parse(fs.readFileSync('/home/user/data/cookies.json'));
await page.setCookie(...cookies);
await page.goto('https://example.com/data');
// 执行数据采集
await browser.disconnect();

为什么要用多步骤模式?

  • 绕过验证码:人工登录搞定验证码,后续任务全自动
  • 状态持久化:Cookie 保存到文件,支持断点续传
  • 资源优化:浏览器一直运行着,不用重复启动浪费时间

完整代码参见文末附录:Github 示例仓库。

1.3 关键概念说明

代码执行方式

通过 sandbox.context.execute_async() 方法执行代码:

result = await sandbox.context.execute_async(
    code="console.log('Hello')",
    language="javascript",  # 或 "python"
    timeout=300  # 超时时间(秒)
)

返回格式很清晰:

{
    "contextId": "ctx_xxx",  # 上下文 ID
    "results": [
        {"type": "stdout", "text": "Hello\n"},
        {"type": "result", "value": null}
    ]
}

文件操作(超简单)

# 写入文件
sandbox.file.write(
    path="/home/user/data/result.json",
    content='{"key": "value"}',
    encoding="utf-8"
)
# 读取文件
content = sandbox.file.read("/home/user/data/result.json")
# 上传本地文件
sandbox.file_system.upload(
    local_file_path="./local_file.txt",
    target_file_path="/home/user/data/file.txt"
)
# 下载文件
sandbox.file_system.download(
    path="/home/user/data/result.json",
    save_path="./result.json"
)

最佳实践

2.1 多步骤任务模式

什么时候用? 需要登录、人工介入、或者数据量很大的时候。

标准流程:

步骤 1:打开登录页 → 通过 VNC 人工登录
步骤 2:保存 Cookie 到文件系统
步骤 3:使用 Cookie 执行数据采集

实操要点:

1. sandbox_idle_timeout_seconds >= 1800 保持一定时间状态可用,闲置超时后自动回收。

  1. 一定要用 disconnect() 保持浏览器运行,close() 会关掉浏览器。
  2. 通过 /home/user/data/ 目录传递 Cookie 和进度。
  3. VNC URL 用 sandbox.sandbox_id 和 base URL 拼起来就行。
  4. 文件操作就用 sandbox.file.read() 和 sandbox.file.write()

2.2 LLM Agent 集成模式

适用场景: 让 AI 自动生成和执行浏览器自动化代码,非技术用户也能用。

整体架构:

image

三条铁律(必须遵守):

  • 禁止:puppeteer.launch() → 必须:puppeteer.connect()
  • 禁止:browser.close() → 必须:browser.disconnect()
  • 禁止:随便存文件 → 必须:/home/user/data/xxx.json

为什么这么严格?

  • 违反约束会导致浏览器重启,之前的状态全没了
  • AI 生成代码需要明确指导,不能指望它有“常识”
  • 详细内容见第 4 章系统提示词设计

2.3 Cookie 持久化模式

什么时候需要? 要保持登录状态,跨会话复用的时候。

完整流程:

首次登录:
1. 人工登录 → 2. 保存 Cookie → 3. 持久化存储
后续使用:
1. 上传Cookie -> 2. 读取 Cookie → 3. 恢复会话 → 4. 执行任务

Cookie 保存示例:

const puppeteer = require('puppeteer-core');
const fs = require('fs');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
const cookies = await page.cookies();
// 保存到文件系统
fs.writeFileSync('/home/user/data/cookies.json', JSON.stringify(cookies, null, 2));
console.log('Cookie 已保存');
await browser.disconnect();

Cookie 恢复示例:

const puppeteer = require('puppeteer-core');
const fs = require('fs');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
// 读取 Cookie
const cookies = JSON.parse(fs.readFileSync('/home/user/data/cookies.json'));
// 恢复会话
await page.setCookie(...cookies);
await page.goto('https://example.com/protected');
console.log('登录状态已恢复');
await browser.disconnect();

关键提醒:

  • Cookie 一定要保存到 /home/user/data/ 目录,这样才有权限
  • 用 page.cookies() 获取所有 Cookie,一个都不能少
  • 用 page.setCookie(...cookies) 恢复,顺序很重要
  • 别忘了检查 Cookie 过期时间和安全性

2.4 批量任务模式

适用场景: 需要并发处理大量任务的时候。

两种策略:

策略 1:单沙箱顺序执行(简单任务,有依赖关系)
策略 2:多沙箱并发执行(复杂任务,无依赖关系)

选择建议:

策略适用场景优势
单沙箱顺序执行简单任务,依赖前序结果资源占用低,状态连续
多沙箱并发执行复杂任务,无依赖关系执行速度快,并行处理

并发控制示例:

# 使用 asyncio.gather() 实现并发
tasks = [
    process_item(item)
    for item in items
]
results = await asyncio.gather(*tasks, return_exceptions=True)

实战案例:豆瓣电影 Top250 爬取

image

完整的 Demo 代码可以在示例仓库里找到。

3.1 需求分析

目标很明确: 抓取豆瓣电影 Top250 的电影信息(标题、评分、导演、年份等)。

实际挑战:

  1. 豆瓣必须登录才能看完整信息2. 数据分页展示,需要多步骤采集3. 反爬虫机制相当严格

我们的解法: AIO Sandbox 的 Cookie 持久化 + 多步骤任务模式。

3.2 核心实现流程

步骤 1:首次登录并保存 Cookie

image

// 1. 打开登录页
const puppeteer = require('puppeteer-core');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
await page.goto('https://accounts.douban.com/passport/login');
console.log('请在 VNC 中完成登录');
console.log('登录完成后,程序将自动保存 Cookie');
await browser.disconnect();

操作说明:

  • 用户在 VNC 中手动完成登录(包括验证码)
  • 登录成功后进入下一步

步骤 2:保存 Cookie

const puppeteer = require('puppeteer-core');
const fs = require('fs');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
const cookies = await page.cookies();
fs.writeFileSync('/home/user/data/douban_cookies.json', JSON.stringify(cookies, null, 2));
console.log(`Cookie 已保存,共 ${cookies.length} 条`);
await browser.disconnect();

步骤 3:用 Cookie 爬取数据

image

const puppeteer = require('puppeteer-core');
const fs = require('fs');
const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
const page = (await browser.pages())[0];
// 恢复 Cookie
const cookies = JSON.parse(fs.readFileSync('/home/user/data/douban_cookies.json'));
await page.setCookie(...cookies);
// 访问 Top250
await page.goto('https://movie.douban.com/top250', { waitUntil: 'networkidle2' });
// 提取数据
const movies = await page.evaluate(() => {
  return Array.from(document.querySelectorAll('.item')).map(item => ({
    title: item.querySelector('.title')?.textContent,
    rating: item.querySelector('.rating_num')?.textContent,
    quote: item.querySelector('.inq')?.textContent
  }));
});
// 保存结果
fs.writeFileSync('/home/user/data/movies.json', JSON.stringify(movies, null, 2));
console.log(`爬取完成,共 ${movies.length} 部电影`);
await browser.disconnect();

3.3 完整 Python 代码

具体实现可以参考项目的 src/ai_code_generator.py 和 src/sandbox_executor.py

核心逻辑:

from agentrun.sandbox import Sandbox, TemplateType
import asyncio
async def scrape_douban():
    # 1. 创建沙箱
    sandbox = Sandbox.create(
        template_type=TemplateType.AIO,
        template_name="douban-scraper",
        sandbox_idle_timeout_seconds=1800
    )
    # 2. 执行登录步骤(代码略,参考上面)
    # 3. 保存 Cookie(代码略,参考上面)
    # 4. 爬取数据(代码略,参考上面)
    # 5. 读取结果
    result = sandbox.file.read('/home/user/data/movies.json')
    print(result)
asyncio.run(scrape_douban())

3.4 核心技术点总结

  1. Cookie 持久化:避免重复登录,通过文件系统保存和恢复登录状态
  2. connect() + disconnect():保持浏览器运行,完美支持多步骤任务
  3. 文件系统状态传递:跨步骤共享数据,无需网络 I/O 开销

3.5 扩展功能

分页爬取(完整 Top250)

const movies = [];
for (let page_num = 0; page_num < 250; page_num += 25) {
  await page.goto(`https://movie.douban.com/top250?start=${page_num}`);
  const items = await page.evaluate(() => {
    // 提取逻辑
  });
  movies.push(...items);
  // 延迟防止反爬
  await page.waitForTimeout(2000);
}
fs.writeFileSync('/home/user/data/all_movies.json', JSON.stringify(movies));

错误处理和重试(生产必备)

async function scrapeWithRetry(url, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
      return true;
    } catch (error) {
      console.log(`重试 ${i + 1}/${maxRetries}: ${error.message}`);
      await page.waitForTimeout(5000);
    }
  }
  return false;
}

系统提示词设计

4.1 为什么提示词这么重要?

系统提示词(System Prompt)是 LLM Agent 的大脑,直接决定了 AI 如何理解和执行你的需求。对于 AIO Sandbox 集成来说,提示词必须明确告诉 AI 如何生成符合沙箱规范的代码。

image

4.2 我们的设计哲学

在设计提示词之前,你得先理解 All-In-One Sandbox 的核心理念,这直接影响提示词的结构。

人机协作,不是完全自动化

我们承认有些事情 AI 就是搞不定,比如验证码、滑块验证、短信验证。所以 AIO 采用“人机协作”的设计理念:

可观测性优先

  • 通过 VNC 让执行过程完全透明,你能亲眼看到浏览器在做什么
  • 不用再通过日志猜来猜去,直接看页面状态快速定位问题

人机协作而非完全自动

  • 遇到验证码?没问题,人工介入搞定
  • 人工操作完,自动化任务接着跑,无缝衔接

状态持久化

  • 浏览器会话和数据可以跨步骤保存和恢复
  • 用 disconnect() 保持浏览器运行,状态不会丢

4.3 核心约束与最佳实践

提示词必须明确告诉 AI 这些关键约束:

1. 必须用 connect(),别用 launch()

为什么?看看对比就知道了:

传统方式 (错误):
const browser = await puppeteer.launch();  // 启动新浏览器 (1-3 秒)
// 执行任务
await browser.close();  // 状态全部丢失
All-In-One 方式 (正确):
const browser = await puppeteer.connect({  // 连接已运行的浏览器 (<100ms)
  browserWSEndpoint: 'ws://localhost:5000/ws/automation'
});
// 执行任务
await browser.disconnect();  // 保持浏览器运行

技术原因很简单:

  • 浏览器在容器启动时就已经跑起来了
  • 用 launch() 会启动第二个浏览器,纯属浪费资源
  • connect() 几乎瞬间连接,特别适合多步骤任务

2. 必须用 disconnect(),别用 close()

关键区别在这:

browser.close():
- 关闭所有页面
- 终止浏览器进程
- 清理所有状态
- 无法支持多步骤任务
- VNC 显示中断
browser.disconnect():
- 只断开 Puppeteer 连接
- 浏览器继续运行
- 所有状态保留
- 支持多步骤任务
- VNC 显示连续

3. Cookie 持久化是王道

登录状态的本质就是 Cookie:

用户登录 → 服务器设置 Cookie → 后续请求携带 Cookie → 服务器识别用户

没有持久化会怎样?

  • Sandbox 重建后状态全丢
  • 长时间后 Cookie 过期
  • 频繁重新登录,烦死了

标准做法

保存 Cookie:

const cookies = await page.cookies();
fs.writeFileSync(
  '/home/user/data/cookies.json',
  JSON.stringify(cookies, null, 2)
);

加载 Cookie:

const cookies = JSON.parse(
  fs.readFileSync('/home/user/data/cookies.json')
);
// 先访问对应域名
await page.goto('https://example.com');
// 再设置 Cookie
await page.setCookie(...cookies);

4.4 实用提示词模板

基础模板(直接复制就能用)

你是 AgentRun AIO Sandbox 的代码生成助手。你的任务是将用户需求转换为可在沙箱中执行的 Puppeteer 代码。
【环境信息】
- 浏览器:Chromium (已预启动)
- 连接端点:ws://localhost:5000/ws/automation
- 文件系统:/home/user/data/ (持久化目录)
- 超时限制:单次执行 300 秒
【代码规范】
1. 连接浏览器:
   const puppeteer = require('puppeteer-core');
   const browser = await puppeteer.connect({
     browserWSEndpoint: 'ws://localhost:5000/ws/automation'
   });
2. 结束会话:
   await browser.disconnect();
3. 文件读写:
   const fs = require('fs');
   // 读取
   const data = fs.readFileSync('/home/user/data/file.json');
   // 写入
   fs.writeFileSync('/home/user/data/file.json', JSON.stringify(data));
4. 错误处理:
   try {
     // 代码逻辑
   } catch (error) {
     console.error(`错误: ${error.message}`);
     throw error;
   }
【输出要求】
- 生成完整的 JavaScript 代码
- 包含必要的错误处理
- 关键步骤用 console.log() 记录
- 重要结果保存到文件系统

4.5 AI 对话模式的工作原理

image

AI 对话模式让非技术用户也能用浏览器自动化,系统提示词在里面起着关键的“翻译”作用。

智能任务拆分

好的提示词要能指导 AI 自动判断何时拆分任务:

简单任务(不拆分)

用户: 访问 example.com,获取页面标题
AI 直接生成单个代码块,执行后返回结果

需要登录(自动拆分)

用户: 登录豆瓣,然后获取我的收藏
AI 自动拆分为 3 个步骤:
步骤 1: 打开登录页 → [生成代码1] → "请在 VNC 中完成登录"
步骤 2: 保存 Cookie → [生成代码2] → "已保存 15 个 Cookie"
步骤 3: 获取收藏 → [生成代码3] → "找到 25 部收藏电影"

引导人工操作

遇到需要人工介入的步骤,AI 要明确告诉用户该怎么做:

AI: 我已经打开了登录页面,请在 VNC 窗口中:
1. 输入用户名和密码
2. 输入验证码
3. 点击登录按钮
完成后告诉我"登录完成",我将继续后续步骤。

高级技巧与注意事项

5.1 错误处理(生产环境必备)

永远用 try-catch 包裹核心操作:

try {
  // 核心操作
  await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
} catch (error) {
  // 明确的错误信息
  console.error(`操作失败: ${error.message}`);
  // 可选:重试逻辑
  if (error.name === 'TimeoutError' && retryCount < maxRetries) {
    console.log(`超时,重试第 ${retryCount + 1} 次`);
    await new Promise(resolve => setTimeout(resolve, 5000));
    return executeWithRetry(url, retryCount + 1);
  }
  throw error;
}

5.2 性能优化(速度提升明显)

禁用不必要的资源加载

await page.setRequestInterception(true);
page.on('request', (req) => {
  const resourceType = req.resourceType();
  // 丢弃图片、样式、字体等非关键资源
  if (['image', 'stylesheet', 'font', 'media'].includes(resourceType)) {
    req.abort();
  } else {
    req.continue();
  }
});

5.3 安全注意事项

Cookie 安全(重中之重)

# .gitignore 中必须包含
*_cookies.json
cookies.json
*.env

代码注入防护

// 危险:直接拼接用户输入
const userInput = req.query.selector;
await page.click(userInput);
// 安全:白名单验证
const allowedSelectors = ['.button-primary', '.submit-btn'];
if (!allowedSelectors.includes(userInput)) {
  throw new Error('非法选择器');
}
await page.click(userInput);

5.4 调试技巧(省时省力)

VNC 实时观察(最有效)

# 创建沙箱后立即获取 VNC URL
vnc_url = f"https://vnc.example.com/sandbox/{sandbox.sandbox_id}"
print(f"打开 VNC: {vnc_url}")

截图调试(关键时刻救命)

// 登录前后都截图
await page.screenshot({ path: '/home/user/data/before_login.png', fullPage: true });
await page.screenshot({ path: '/home/user/data/after_login.png', fullPage: true });

核心总结

技术收益一目了然

使用 AIO sandbox 能够将状态传递和文件共享复杂度进行有效地降低,并且能够有如下收益:

  1. 启动延迟低,从原有的多个 sandbox 优化为了一个 sandbox,降低了至少 50% 的启动时间;
  2. 状态保持轻量,在代码执行和浏览器操作的过程中,能够尽量使用本地文件系统实现状态保持,符合最佳实践;
  3. VNC 的透出提供了人工介入的手段,有效帮助用户解决了自动化的卡点,如验证等。

7 条黄金法则

  1. 必须用 puppeteer.connect(),禁止 launch()
  2. 必须用 browser.disconnect(),禁止 close()
  3. 必须保存数据到 /home/user/data/ 目录
  4. 登录流程拆分:打开登录页 → 人工登录 → 保存 Cookie → 执行任务
  5. Cookie 先访问域名再设置,避免跨域问题
  6. 多步骤任务用文件系统传递状态,别用全局变量
  7. 重要操作必须加错误处理,别让错误静默失败

常见陷阱避坑指南

陷阱症状解决方案
用 launch()浏览器重复启动,内存爆了改用 connect()
用 close()后续步骤失败,状态丢了改用 disconnect()
Cookie 没持久化每次都要重新登录保存到 /home/user/data/cookies.json
等待时间不足元素找不到报错用 waitForSelector + networkidle2
路径不规范文件丢失或权限错误统一用 /home/user/data/ 目录

进阶学习路径

1. 源码分析: https://github.com/devsapp/agentrun-sandbox-demos/tree/main/sandbox-all-in-one-demo

2. 性能调优:

  • 禁用图片/字体资源
  • 用 networkidle2 等待策略
  • 批量处理数据,减少 I/O

3. 错误处理:

  • 指数退避重试策略
  • 最大重试次数控制
  • 超时和网络错误处理

附录:Demo 代码

各位 V 友好,

最近做了一个小产品想分享一下,顺便求教大家一些产品方向的问题。

一、起因

前段时间发现 OpenClaw 很火,这个 AI 助手框架真的很强大,可以接入 Telegram/Discord ,实现自动化任务、代码审查、邮件处理等功能。但是!部署过程对小白来说太劝退了:

  • 配置服务器 10+ 分钟
  • 安装依赖 5+ 分钟
  • 配置 OpenClaw 15+ 分钟
  • 设置 SSL 和接入 channel 15+ 分钟
  • 总计 45+ 分钟,还要会 SSH 、会 YAML 、懂 DevOps

我自己折腾了好久才跑起来,就想着能不能做个工具,让不懂技术的人也能用上这么强大的 AI 助手。

二、产品简介

1ClickClaw 是一个 OpenClaw 的一键部署托管服务。

🔗 在线体验https://1clickclaw.com (还在打磨中)

核心特点:

  • 60 秒部署:选模型 → 贴 Bot Token → 点击部署,完事
  • 🤖 多模型支持:Claude 、GPT 、Gemini 随便选
  • 📱 多渠道接入:Telegram 、Discord ,WhatsApp 在做了
  • 💰 内置 AI 额度:不用自己去 OpenRouter 申请 Key
  • 🖥️ 独立服务器:2vCPU/2GB 专属资源,24/7 在线

产品截图

三、遇到的问题

之前参考了一个竞品,他们是这么做的:

  • 每个用户开一台独立虚机
  • 每个用户只能接一个 Channel (要么 Telegram 要么 Discord )

现在回头看,感觉有点问题:

  1. 成本太高:一人一台虚机,用户不活跃的时候也在烧钱
  2. 不够灵活:只能一个 Channel ,万一用户想同时用 Telegram 和 Discord 呢?

四、想请教 V 友

  • 一人一台虚机是不是太重了?有没有更省钱的玩法?
  • 做成共享资源池按量计费靠谱吗?还是 Serverless 按调用次数收?
  • 多 Channel 是刚需吗?还是大多数人其实只用一个?
  • 需要提供用户在 dashboard 配置工具和 skills 么?现在通过 telegram bot 也能安装 skills
  • 定价 $49/月( 包含$15 token 额度)是不是太贵了?

有什么想法都可以聊聊,我还在摸索阶段。


非常感谢看到这里!

刚刚接触 openclaw 没有多久,很多地方还在摸索。产品定位是服务不懂技术的小白用户,所以很多高级配置都没暴露出来, skill 和 tool 都没有,只保留了最基本的选项。

🔗 在线体验: https://1clickclaw.com (还在打磨中)

一、等保、密评对SSL证书的核心要求

等保测评和密评对SSL证书有明确的技术规范,主要体现在以下三个方面:

1. 算法合规:必须支持国密算法

根据《商用密码应用安全性评估管理办法》及GB/T 39786-2021标准,三级及以上系统必须采用国产密码算法(SM2/SM3/SM4)进行加密传输:

  • SM2:替代RSA的国产非对称加密算法
  • SM3:国产哈希算法
  • SM4:国产对称加密算法

结论:仅支持RSA/ECC的国际算法证书无法通过密评,必须选择支持国密算法的SSL证书。推荐采用“国密+国际”双算法证书,兼顾合规性与全球浏览器兼容性。

2. 验证级别:OV/EV证书为强制选项

域名验证(DV)证书仅验证域名所有权,不验证组织身份,无法满足等保二级及以上对“通信主体可信认证”的要求。因此:

  • 等保二级:建议采用OV证书
  • 等保三级及以上:必须采用OV或EV证书,且需通过企业资质审核
3. CA机构:国内可信、数据不出境

证书需由国家密码管理局认证的国内CA机构签发,确保证书验签服务器、时间戳及OCSP等全部部署在中国境内,满足数据不出境的合规要求。国产自主品牌如JoySSL、CFCA等均在推荐之列。

二、等保密评专用SSL证书申请全流程(以JoySSL为例)

等保密评专用SSL证书申请入口

JoySSL作为国内自主CA机构,提供专业的等保密评专用SSL证书,支持国密算法、OV/EV验证,且全流程国内验签。以下是详细申请步骤:

第一步:注册账号并获取技术支持
  1. 访问JoySSL官网,点击右上角注册账号
  2. 关键步骤:在注册过程中,填写邀请码 230970即可获得:

    • 免费证书测试机会
    • 大额优惠券
    • 一对一全程技术指导

      第二步:选择等保密评专用证书

登录后,在首页SSL证书分类中选择  “等保/密评”  专用证书。根据实际需求选择;

特别提示:如果系统使用IP地址访问(如内网系统、API接口),需选择IP地址证书,同样支持OV验证和国密算法。

第三步:提交申请并完成验证
  1. 填写信息:提交企业名称、联系人、联系方式、营业执照等资质材料
  2. 域名/IP验证

    • DNS验证:添加TXT解析记录
    • 文件验证:上传验证文件至服务器根目录
  3. 组织验证:OV/EV证书需通过电话、邮件核实企业信息,通常需1-3个工作日

    第四步:下载证书并部署

验证通过后,登录JoySSL账号下载证书文件压缩包(包含服务器证书、中间证书链、私钥)。根据服务器类型(Nginx/Apache/IIS)参照官方安装指南进行部署。

一、政务数据泄露的严峻形势与加密需求

近年来,政务数据泄露事件频发,其根源在于网络攻击手段的多样化、数据管理混乱以及技术依赖带来的系统漏洞。例如,某省级政务云平台因未部署SSL证书,在等保测评中被扣分,暴露出数据传输环节的明文传输风险;某市电子政务系统因长期未更新补丁,导致黑客利用漏洞窃取大量公民信息。这些案例表明,政务数据在传输和存储过程中面临多重威胁:

  • 传输环节:明文传输易被中间人攻击截获,黑客可通过Wireshark等工具直接获取数据内容;
  • 存储环节:未加密存储的敏感数据可能因设备丢失、内部人员越权访问或第三方机构违规使用而泄露。


在此背景下,国密SSL证书凭借其自主可控的密码算法体系,成为政务数据全链路加密的核心工具。其通过SM2非对称加密、SM3哈希算法和SM4对称加密的协同工作,实现了从数据生成到使用的全生命周期保护。

二、国密SSL证书的技术原理与核心优势

1. 自主可控的密码算法体系

国密SSL证书基于国家密码管理局发布的SM2/SM3/SM4算法标准:

  • SM2算法:采用椭圆曲线密码学,256位密钥强度等同于RSA 3072位,但计算效率提升40%,适合移动端和物联网设备;
  • SM3算法:抗碰撞性优于SHA-256,用于生成数据指纹,确保传输内容未被篡改;
  • SM4算法:分组加密速度优于AES-256,在移动端的性能损耗低于3%,支持实时加密大量数据。

2. 全链路加密的实现机制

国密SSL证书通过“非对称加密+对称加密”的混合模式,构建安全传输通道:

  • 传输阶段

    1. 证书验证:服务器向客户端发送国密SSL证书,客户端验证证书合法性(如是否由受信任CA机构签发);
    2. 密钥协商:客户端生成SM4对称密钥,用服务器SM2公钥加密后传输,双方使用该密钥加密后续通信;
    3. 数据加密:邮件正文、附件及元数据通过SM4算法加密,即使传输流量被截获,攻击者也无法解密。
  • 存储阶段

    1. 静态数据加密:采用SM4算法对存储在数据库或文件系统中的敏感数据进行加密,密钥由硬件安全模块(HSM)管理;
    2. 动态脱敏:在数据查询或展示时,通过SM3算法生成临时脱敏规则,防止内部人员直接接触原始数据。

3. 兼容性与性能优化

针对政务系统的复杂环境,国密SSL证书提供以下解决方案:

  • 双证书自适应:支持“国密+RSA”双证书部署,当用户使用360安全浏览器、奇安信可信浏览器等支持国密的浏览器时,自动启用SM2算法;使用Chrome、Firefox等国际浏览器时,回退至RSA算法,确保无缝兼容;
  • 轻量化设计:SM2算法的短密钥特性降低计算功耗,SM4的快速加密能力使移动政务APP的响应时间控制在200ms以内,用户无感知安全防护;
  • 国产化生态融合:与麒麟、统信UOS等国产操作系统,以及达梦、人大金仓等国产数据库深度整合,推动政务系统从“可用”到“好用”的国产化替代。

三、JoySSL在政务全链路加密中的实践与案例

1. 技术架构与部署方案

JoySSL作为国内自主品牌SSL证书提供商,其国密证书解决方案包含以下核心组件:

  • 证书签发系统:基于国内服务器验签,数据不出境,支持单域名、多域名、通配符及IP地址证书的快速签发;
  • 密钥管理系统:提供硬件安全模块(HSM)集成方案,支持SM2密钥的生成、存储和销毁全生命周期管理;
  • 监控预警平台:实时监测证书有效期、密钥使用情况及攻击尝试,提前30天预警证书到期风险。

2. 典型应用场景

场景1:省级政务云平台改造

某省级政务云平台将邮件系统改造为SM2+SM4组合加密,实现以下效果:

  • 传输安全:POP3协议切换至加密端口995,所有邮件数据以密文形式传输,攻击成本提升至少10万倍;
  • 存储安全:通过SM4算法加密存储的附件和元数据,即使数据库备份泄露,攻击者也无法解密内容;
  • 成本优化:年节省密码服务采购费用超千万元,同时满足等保三级测评要求。

场景2:市级电子政务外网安全升级

某市电子政务外网采用JoySSL国密SSL证书后,实现:

  • 身份认证强化:通过SM2算法验证服务器合法性,将钓鱼攻击拦截率提升至99.97%;
  • 数据完整性保护:SM3算法生成的哈希值用于标记操作日志来源,确保纠纷处理中提供不可篡改的证据链;
  • 合规性提升:通过商用密码应用安全性评估(密评),避免因不符合国密要求而导致的整改风险。

四、未来展望:国密SSL证书的生态化发展

随着《密码法》的深入实施和等保2.0的全面落地,国密SSL证书将成为政务系统的“标配安全组件”。其发展趋势包括:

  • 政策驱动与市场扩容:预计到2027年,国密SSL证书在政务领域的覆盖率将超过80%,市场规模突破50亿元;
  • 技术融合与创新:与量子加密、零信任架构结合,构建下一代安全通信体系。例如,SM2算法的抗量子计算能力优于RSA,是应对未来量子威胁的“战略选择”;
  • 国际标准化推进:我国正推动SM算法纳入ISO/IEC国际标准,未来国密SSL证书有望实现全球互认,为跨境政务服务提供安全保障。

五、结语

政务数据泄露风险已从技术问题升级为关乎国家安全、社会稳定和公民权益的战略问题。国密SSL证书通过自主可控的密码技术,为政务数据构建了“传输-存储”全链路加密体系,其技术先进性、合规强制性和场景适配性,使其成为政务系统安全改造的“刚需”。以JoySSL为代表的国内证书服务商,正通过持续创新和生态建设,推动国密技术从基础防护向业务创新延伸,为数字政务的高质量发展筑牢安全底座。

OpenAI 详细介绍了一种称为 Harness Engineering 的全新内部工程方法论,利用 AI 智能体来驱动软件开发生命周期的关键环节。该系统基于 Codex(一套 AI 智能体套件),根据工程师定义的声明式提示词执行编写代码、生成测试和管理可观测性等任务。Harness 实现了工作流程的标准化,降低了对人工编写脚本与定制化工具的依赖。

OpenAI 技术人员 Ryan Lopopolo 表示:

我们构建 Harness 的目的是为大规模 AI 任务提供统一、可靠的运行方式,让团队能够专注于研究与产品开发,而非基础设施编排。

在为期五个月的内部实验中,OpenAI 工程师构建并交付了一个包含约一百万行代码的测试版产品,且全程未手动编写任何源代码。一个小型工程师团队通过拉取请求与持续集成工作流引导智能体,工作内容涵盖应用逻辑、文档、CI 配置、可观测性配置及工具链。工程师仅提供提示词与反馈,由 Codex 智能体自主迭代完成各项任务,包括复现缺陷、给出修复方案并验证结果。

Codex 智能体驱动的应用测试与反馈(来源:OpenAI 博客文章

Harness Engineering 将人类工程师的工作重心从代码实现,转移到设计环境、明确意图与提供结构化反馈上。Codex 可直接与开发工具交互,创建拉取请求、评估变更,并持续迭代直至满足任务标准。智能体利用日志、指标、链路追踪等遥测数据监控应用性能,并在隔离的开发环境中复现缺陷。

Codex 智能体的可观测性与遥测工作流(来源:OpenAI 博客文章

内部文档以结构化形式组织在文档目录中,包含架构图谱、执行计划与设计规范,这些文档是智能体的唯一事实来源。交叉关联的设计与架构文档通过代码检查工具和 CI 验证进行强制校验,保证了一致性,同时减少了人工监督的需求。

OpenAI 通过机械规则与结构测试在跨领域场景中强制约束架构边界与依赖层级。依赖按照 Types → Config → Repo → Service → Runtime → UI 的顺序流转,智能体被限定在这些层级内运行。结构测试用于验证合规性,并防止模块化分层被破坏。

Thoughtworks 技术专家 Martin Fowler 在 LinkedIn 帖子 中提到:

Harness Engineering 是对 AI 赋能软件开发关键部分的一种有价值的框架性阐述。Harness 包含了上下文工程、架构约束和垃圾回收。

OpenAI 报告指出,Harness 将脚手架、反馈循环、文档与架构约束编码为机器可读产物,Codex 智能体借助这些产物,在代码生成、测试及可观测性等开发流程中执行任务。

原文链接:

https://www.infoq.com/news/2026/02/openai-harness-engineering-codex/

起因是之前刷推刷到一条打折消息,一番倒腾就把片子买了,发现虽然能在线播放

但是下载比较麻烦,也不是原视频文件

网上也没有搜索到新的解决方案,于是自己折腾了一下,终于把原片下载到电脑了😊顺便也把整个过程整合为了一个 Chrome 插件,地址:dmm-download-helper

里面包含详细的介绍和使用方式,特性如下:

  • 获取 & 复制 MPD 链接、ClearKey 信息、原解密信息
  • 一键复制 N_m3u8DL-RE 下载命令(需要自行安装对应软件)
  • 自动记录视频清晰度
  • 切换视频清晰度时,自动以新会话的形式,更新最新的 MPD 链接、ClearKey 信息和下载命令

演示视频如下:视频标题

过程中学习了下列项目,也是非常有趣:

最后,欢迎试用、留言反馈和 Github Star,如果刚好能帮到你,就再好不过🥰

image
谷歌插件商店 GitHub


功能

给任意网站(可指定域名)添加自定义的 css 层叠样式表

用法示例

叠甲:此行为不鼓励,只供学习探讨

  1. xx 网站去水印
    在逛某个设备参数网的时候发现有个全局的水印,看着很不舒服
    打开控制台,选中元素,发现是一张、<img>标签引入的图片,直接用选择器选中该图片display: none
    (别学,可能有点刑?我只为了看得舒服,不截取转发数据)
  2. 试着给 2Libra 移除“今日热议”列表的头像框
    心血来潮想让“今日热议”列表更简约一点,用 css 把头像去掉
    由于没有标志性的类名,只能这样定位
    复制
    div[data-right-sidebar="true"] > div:nth-child(2) {
        /*普通头像*/
        div:has(> img) {
            display: none
        }
        /*svg 头像*/
        div:has(> svg) {
            display: none
        }
        /*动图的头像,被加了一层 canvas*/
        div:has(> div > canvas) {
            display: none
        }
    }

    大致效果:
    image
    3. 临时修复一些网站的样式问题
    image
    4. 其他用法你可以发挥想像力,比如改变边框线条粗细,改变左右布局、固定用户信息卡片,简单屏蔽一些低级广告等等
    (Jimmy 会不会揍我,精心设计的排版被我改得面目全非)


话说,这个应该选前端节点还是浏览器扩展节点,好难受,都想要

飞机上的景色,连接青海与甘肃的大地

喀什随手拍

木吉乡火山与十八罗汉峰

慕士塔格峰与冰川

路边随手拍


总行程包含往返日一共 7 天,稍稍有点赶,但核心景色已经体验了 7788.都说北疆看风景,南疆看人文,但这次旅程下来南疆的景色也让我刮目相看

最近在主导重构团队的市场异动监控系统时,我反复在一个痛点上卡壳:业务逻辑跑得很完美,但偏偏总是因为数据接入端的脆弱而导致整条链路瘫痪。之前为了图快,项目里充斥着大量的网页端暴力抓取代码,或者是定时去拉取滞后的 CSV 静态表单。这种原始的交互方式,不仅响应速度根本跟不上高频的市场节奏,维护成本也极其高昂。在彻底推翻了旧架构并引入了专业的直连数据流之后,我才终于体会到了让数据如流水般稳定涌入系统的畅快感。

在后端架构设计的范畴里,“系统的高容错率与可用性”永远是一切业务展开的绝对先决条件。

曾几何时,我也在开发中陷入过误区,把大量的计算资源倾注于生成复杂的趋势分析图表和多维聚合大屏上。但实盘跑起来后,现实给了我沉重一击:一旦最底层的实时行情、买卖盘口或者资金流向数据出现了网络阻塞或部分字段丢包,建立在此基础上的任何高级告警策略都会瞬间失效,甚至发出完全相反的错误指令。
为了彻底根治这个顽疾,我在新版框架的中间件层强制注入了两项防御性规范:
第一,所有对外部数据源的拉取动作,必须包裹在最严格的异常捕获作用域内。网络抖动不可避免,但我们的核心守护进程绝不能因为一次 Timeout 就发生主线程崩溃。
第二,在反序列化阶段实施极其严苛的字段级完整性校验。无论是当前的搓合价、瞬时成交量还是振幅区间,但凡出现 None 值或类型不匹配,立刻触发降级策略直接丢弃该记录,坚决杜绝脏数据污染下游的业务池。这些处理看似增加了代码的冗余度,但在复杂的网络交互中,它们是保证数据链路长久存活的核心屏障。

落实到代码编排上,如何安全、高效地把外部的 JSON 数据流转化为系统内部的实例对象,是这套架构的重中之重。在这次重构中,我剥离出了这样一个极其精简的访问器逻辑:


import time
from alltick import AllTickAPI

client = AllTickAPI(api_key="你的API_KEY")

def get_stock_quotes(symbol):
    try:
        response = client.market.quotes(symbols=symbol)
        if response and response.get("data"):
            return response["data"]
        else:
            print(f"{symbol} 未返回行情数据")
            return None
    except Exception as e:
        print(f"获取行情异常: {e}")
        return None

quotes = get_stock_quotes("AAPL")
if quotes:
    print(f"AAPL 最新价: {quotes[0]['last_price']}")

这段逻辑的工程美学在于它的“边界感”。它专职负责将云端的最新快照安全拽回本地内存,并利用严密的 try-except 体系将所有潜在的 I/O 风险消化在了函数作用域内部,从而为整个异步监控体系奠定了一块坚如磐石的基石。

当干净的数据流蓄势待发,我们面临的下一个课题就是如何最大化地压榨这些数据的业务价值。在目前的微服务体系中,这些数据主要在两个核心处理器中流转:

首当其冲的是低延迟的事件触发机制。当关键标的的价格波动触及了我们写入配置中心的阈值红线时,系统必须做出无缝响应:

if quotes and quotes[0]["last_price"] >= 150:
    print("AAPL 价格突破 150 美元,需要关注")

这种完全解耦的推送机制,彻底取代了早期人工低效的网页轮询,确保了每一次关键波动都能被系统级捕捉。

其次,则是用于长周期维度下的技术因子提纯。我们会将拉取到的连续时间轴片段进行二次聚合,在内存中演算出均线等平滑指标,为后续的趋势判断提供参考系:

history_data = get_stock_quotes("AAPL")  # 假设返回多条历史报价
ma_10 = sum([item["last_price"] for item in history_data[-10:]]) / 10
print(f"10日均价: {ma_10}")

虽然算法层面并不复杂,但它能有效地过滤掉高频的杂讯,让原本晦涩难懂的原始报文变得具备统计学意义的“可读性”,这对系统投研模块的支撑是无可替代的。

在长期的重构与迭代中,我也逐渐沉淀了几条系统优化的最佳实践:比如必须引入漏桶或令牌桶机制来精确控制出网的请求频控,既保障了时效性又避免了被服务端主动熔断;要求将所有抓取失败的上下文详细记录至 ELK 堆栈中,方便后期针对性排查网络瓶颈;同时在工厂模式的设计下,确保底层的拉取逻辑拥有足够的柔性,以应对未来随时可能扩增的指数或行业板块等新维度的接入。

回首这次重构,我越来越意识到,能够找到一个诸如 AllTick 这样极其靠谱的数据服务提供商,并运用严谨的系统工程化思维将庞杂的市场动向转换为机器可以理解的语言,这才是任何一个金融开发项目中最具护城河价值的环节。