Binary Ninja 5.3.9434 (macOS, Linux, Windows) - 反编译器、反汇编器、调试器和二进制分析平台

interactive decompiler, disassembler, debugger, and binary analysis platform

请访问原文链接：https://sysin.org/blog/binary-ninja/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

Binary Ninja

A New Type of Reversing Platform

Binary Ninja 是一个交互式反编译器、反汇编器、调试器和二进制分析平台，由逆向工程师为逆向工程师打造。它在开发时特别注重提供高质量的自动化 API 以及简洁易用的图形界面。Binary Ninja 正被全球的恶意软件分析师、漏洞研究人员和软件开发者广泛使用。Binary Ninja 具备跨平台的强大优势 (sysin)，可反编译为 Windows、macOS 和 Linux 上的许多常见架构构建的软件。

功能简介

• 反编译 Decompile

  针对任何受支持的架构（包括您自己的架构）反汇编和反编译代码为 C 或 BNIL。

• 分析 Analyze

  可视化控制流并以交互方式浏览交叉引用。

• 自动化 Automate

  使用 C++、Python 和 Rust API 从 UI 内部或外部自动进行分析。

• 调试 Debug

  在任何受支持的架构或平台上本地或远程调试程序。

• 协作 Collaborate

  使用我们的企业产品通过同步提交轻松协作。

• 加速 Accelerate

  通过额外的 AI 功能加速分析并优化理解。

新增功能

Binary Ninja 5.3 (Jotunheim)

2026-04-13

对于 Binary Ninja 5.3，在多个方面带来了新功能和改进。为了提升互操作性，在现有的 Ghidra Import 代码基础上新增了 Ghidra Export，并改进了 IDB Import 能力。在新架构和平台方面，为 Ultimate 版本新增了 NDS32 支持，为 AArch64 引入了新的 ILP32 ABI，并提供了一组用于“特殊”架构的新 API。当然，也对 UI 进行了多项改进，包括全新的 Universal Mach-O loader UI、容器浏览器的可用性优化，以及全新的“超级”命令面板！此外，还包括调试器、企业功能的改进，以及新增的可选崩溃报告功能，帮助更快修复问题等等！

• Architecture / Platform

  • New Architecture APIs
  • NDS32
  • AArch64 ILP32 ABI

• UI

  • Mach-O Architecture Picker
  • Container Browser Improvements
  • Command Palette Refresh

• Types & Signatures

  • Type Library Utilities
  • WARP Improvements

• Interoperability

  • Ghidra Export
  • IDB Import Improvements
• Enterprise

• Debugger

  • Hardware and Conditional Breakpoints
  • New Debug Adapters
• Crash Reporting
• Open-Source Contributions
• Everything Else

5.3 包含了大量的改进和修复，篇幅特别长，这里仅仅是列出目录，详见官方更新记录。

下载地址

Binary Ninja 5.3.9434 for macOS, Linux, Windows

• 请访问：https://sysin.org/blog/binary-ninja/

更多：HTTP 协议与安全

《数据安全法》《网络数据安全管理条例》落地深化，数据安全已从合规要求升级为企业数字化运营的核心底座。但当前企业在数据安全建设中，仍深陷“不知数、不见流、难守安”的三重困境：数据资产底数模糊，分类分级人工投入大、周期长、结果难落地；多协议跨系统的数据流转处于黑盒状态，来源去向不可溯；API攻击频发、防护工具碎片化，全生命周期安全管控能力缺失，合规与攻防的双重压力下，企业亟需一套面向未来、体系化、自动化的全链路解决方案。何为见流？何为知数？何为守安？这不仅是数据安全建设的核心命题，更是全知科技深耕近十年的技术探索方向。作为国内率先提出“以数据为中心的数据流动安全”理念的先行者，全知科技以构建全链路数据安全治理能力为核心目标，重磅打造三大核心产品矩阵，即将在2026春季数据安全产品发布会上全新亮相。三款产品深度融合AI大模型能力，覆盖流动监测、风险防护、资产治理全场景，打造数据全生命周期的闭环治理体系，一站式破解企业数据安全建设痛点。数据流动安全检测平台：打破流转黑盒，实现全域可视可控聚焦数据流动核心场景，构建全通道一体化监测体系，原生覆盖全场景数据流转协议，采用旁路无扰部署模式，实现数据流向全链路追踪与异常精准识别，彻底消除数据流转盲区，让数据流动全程可管、可控、可溯。知形-数据库风险监测系统：AI赋能，实现主动式安全治理聚焦企业核心数据载体，全面覆盖数据库全维度风险监测，依托AI大模型实现弱点研判、风险处置、合规运营的全流程自动化，帮助企业从被动防护升级为主动治理，大幅提升安全运营效率与风险响应能力。知源-AI数据分类分级系统：夯实数据安全治理底座以AI自动化能力完成数据资产精准梳理与合规分级，为全链路安全防护提供统一的数据标准与治理依据，高效满足监管合规要求，为企业数据安全建设筑牢基础4月22日14:30，全知科技2026春季数据安全产品发布会即将线上开启；届时，全知科技资深产品专家将为大家深度解析三款产品的亮点功能与核心优势，同步分享全知科技数据安全产品体系的最新规划方向，欢迎大家扫描下方二维码预约直播！

本次发布的三款产品，直击企业“不知数、不见流、难守安”的核心痛点，全面推动企业数据安全建设从碎片化工具部署迈向全链路体系化治理。全知科技将以本次新品发布为牵引，持续深化AI数据安全技术创新，整合数据全生命周期安全管控能力，以见流、知数、守安的坚实能力，护航企业数字化未来，构建适配时代发展、面向长期价值的智能安全防护体系，助力企业在数字化浪潮中行稳致远。

2026年4月，具身智能领域迎来一项可能改写技术路径的突破。某具身智能企业发布的具身模型，完全基于纯仿真训练，未使用任何真实机器人数据。在Zero-shot设定下，该模型在关键任务上实现了近100%的成功率，首次抓取成功率约为98%。这一结果意味着，长期以来制约具身智能产业规模化发展的数据瓶颈——真机采集成本高昂且难以规模化——正被打开一个关键的突破口。

从技术深层来看，这条“纯仿真路线”之所以能够成功，关键在于其数据体系建立在高保真仿真器之上，天然包含了对物理dynamics的直接表达，使模型能够学习到可泛化的物理规律，而非仅仅是针对特定场景的“死记硬背”。这与当前主流路线的本质差异在于：主流方案依赖真机数据采集（遥操作、人类视角采集等），本质上是一种“任务优化”——模型学会了在特定环境中完成特定任务，但环境和物体一旦变化，就需要重新采集数据、重新训练；而纯仿真路线追求的是“物理规律的泛化”——让模型理解物体运动的底层物理规律，从而在面对新环境、新物体时依然能够稳定执行操作。

IDC在2026年初发布的具身智能机器人十大技术趋势中也指出，具身智能机器人技术栈正在形成“以模型为中心、软件定义体系、硬件随之重构”的全栈式变革路径。仿真合成数据已成为规模化训练的主体，视频学习正在成为潜在扩展路径，遥操作实采数据则作为高质量补充。这一技术路线的变化，对于中国具身智能产业的发展具有战略意义——它意味着我们有可能绕开“大规模真机数据采集”这一成本极高、周期极长的环节，通过高保真仿真平台实现模型的快速迭代和泛化能力提升。

在这一技术趋势下，仿真平台的能力成为了决定具身智能企业竞争力的核心要素。凡拓数创在这一领域的布局显示出深刻的技术洞察。其打造的“面向具身智能的多层级空间仿真及训练一体化技术”已通过权威科技成果评价，获评为国际先进水平。这一平台基于完全自主研发的国产化AI3D数字孪生引擎（FTE），构建了覆盖“城市级场景-机器人操作”的多层级仿真体系。在算法层，其提出的“解剖动力学模型（DDM）+分层自适应价值估计（HAVE）”框架，在多项标准任务中的表现均超越国际主流方法。

更值得关注的是，凡拓的仿真平台还设计了非对称交互式协作（AIC）训练框架，引入视觉语言大模型进行知识蒸馏，显著提升了训练稳定性与收敛速度。针对仿真与真实场景之间的“落地鸿沟”，平台构建了频域增强训练与对偶点未知分布检测模型，在变电站巡检、机器人抓取等跨场景任务中，迁移准确率较Facebook SimSAC等方法提升20-25%。

纯仿真路线的突破，正在从根本上改变具身智能产业的成本结构和技术路径。未来，那些拥有自主高保真仿真平台的企业，将在这条“数据民主化”的道路上占据先发优势。而凡拓数创通过联合北京大学深圳研究院等顶尖科研力量打造全栈自研的具身智能数据训练与仿真平台，正在为自身构建起一条坚实的技术护城河。

在工厂、物业、能源电力这些需要定期巡检的场景里，有一个反复被提起的问题：巡检记录填得好好的，设备该坏还是坏，隐患该出还是出——因为根本没人真正到现场检查。

这事不是某家公司的个别情况，在中小企业的巡检管理里非常普遍。原因也不是员工素质或管理不严，而是传统的记录方式本身给了作假空间——纸质签到表也好、Excel 台账也好，能记录的只是"我说我来过"，不能证明"我真的来过"。管理者看得见记录，看不见记录背后的动作，中间这一段全靠员工的诚信承诺。

草料二维码做过大量中小企业的巡检数字化项目，下面结合这些经验，分享一套具体的做法——如何有效防止假检和漏检。

一、常见的 4 种作假行为

管理现场的人大概都见过这几类：

第一种：未到场补填。 纸质巡检表最普遍的问题。巡检员找一个空闲时段，把整周的检查项一次性填齐，签字盖章，记录上一切正常。实际一次现场都没去过。

第二种：他人代检。 张三排了巡检任务，临时有事让李四帮忙扫码拍照。记录上的责任人和实际操作人对不上，一旦出现问题难以厘清责任。

第三种：到岗走过场。 人到了现场，但没按检查项逐条核查——到点位扫码签到即离开，仪表读数、设备外观、液位高度等关键项完全没看。

第四种：旧照片造假。 系统要求上传现场照片之后，有人开始把之前的照片存下来重复上传，或者随手拍张模糊的图片应付。

二、如何防止假检行为

针对上面这 4 种作假行为，除了在管理方面进行规范（比如更严的抽查、双人互检、巡查督办），比较常见的是通过技术手段进行限制，目的是提升作假的门槛，从而保障工人到点到位检查。
常见的技术手段大致分几类：

• 硬件类（门禁刷卡、蓝牙信标、NFC 工牌等做到岗验证）
• 物联网类（在设备上安装传感器自动采集数据，脱离人工）
• AI 视觉类（现场架设摄像头识别行为异常）
• 二维码巡检类（如草料二维码，通过二维码实现到场触发、云端自动记录防作假信息）

前三类对硬件投入、网络条件和运维能力都有较高要求，主要用在预算充足的大型工厂。对大多数中小企业而言，更建议采用二维码巡检，主要原因有三点：

• 成本低：每台设备贴一张标签，单张成本仅几分钱，无需采购硬件
• 使用门槛低：巡检员通过微信扫码即可操作，不需要下载 APP 或额外培训
• 实施门槛低：防作假机制均为系统内的开关式配置，无需 IT 部门介入，当天即可上线

下面以草料二维码为例，说明如何通过功能配置减少上述假检行为。

1. 防止未到场补填：扫码触发 + 定位限制

第一种作假的成本最低，所以第一层防线必须最严。思路是让表单的触发方式本身要求人在现场。

具体做法是两层叠加：

一是把表单设置为仅限微信"扫一扫"填写。巡检员必须持手机到达设备前、对着实物二维码扫描，表单才会出现。把二维码保存成图片再扫、在小程序里搜到码、通过分享链接在别处打开——这几种常见的远程提交方式都触发不了表单。

二是开启定位限制。系统在提交表单时会校验手机地理位置，只有当前位置在该点位允许范围内才能成功提交。超出范围直接拦截，不给保存、不给补交。

这两个功能，能有效保证工人到场，从而避免坐办公室补填——不到设备前拿不到表单，到了假设备面前也会因为定位不对被拦。

2. 防止他人代检：姓名自动关联 + 手写签名

第二层要解决的是"人是去了，但不是应该去的那个人"。这个问题靠到场验证解决不了，得在身份上做约束。

具体做法也是两层：

一是后台可提前录入巡检人员名单，扫码后系统自动关联提交人姓名。每一条巡检记录都带上当前账号的身份信息，责任归属清晰，事后复盘一眼能看出是谁提交的。

二是在表单里加入手写签名组件。对身份敏感的场景（特种设备、消防、安全抽查），要求巡检员在手机上亲笔签名后才能提交。签名图像和这条记录绑定，追责时有据可查。

代检这件事的核心不是禁止，是让代检的成本上升——代的人要用自己账号、要签自己的名，一旦出问题责任先落到代检人头上。

3. 防止到岗走过场：AI 图片审核 + AI 智能填表

人到了现场但不检查，是最难治的一种。因为它看起来"人到了"——扫码对了、定位对了、也提交了，只是没真看设备。

这类情况有两层做法：

一是开启 AI 图片审核。巡检员上传现场照片时，AI 自动判断这张照片是不是拍了指定设备、画面是否清晰可辨、是否能看到关键部位。不达标的照片直接被拦下，提示重新拍摄。

二是启用 AI 智能填表。巡检员拍一张仪表照片，AI 识别读数自动填到对应栏位，再由人工复核确认。既减少手填的偷懒空间，也让"随手填个数字应付"这条路走不通。

这一层做完，走过场的成本从"扫码随手拍一张"上升到了"必须拍清楚、必须拍对地方"。

4. 防止旧照片造假：仅限拍照 + 防作假水印

有人会存上次的照片或者网上找张设备图糊弄，这是拍照上传被加进流程之后出现的新套路。

可通过下面两个功能进行避免：

一是把图片字段设为仅限拍照。现场留证的照片只能当场拍，不允许从相册里选已有图片。旧照片因为不能从相册上传而自动失效。

二是开启防作假水印。拍完照系统自动在照片上叠加水印，内容包括记录人姓名、拍摄时间（精确到秒）、当时定位、关联的二维码信息。水印直接写进图片像素，事后不能去除。如果有人想截屏之后再拍一张伪造，时间和定位对不上也会露出破绽。

三、到期没去检查：周期任务 + 漏检提醒

还有一类常见情况性质不一样，是"漏检"：不是作假，是排班漏了、当天忘了、交接班没交代、人员流动接不上。这种情况光靠技术拦截治不住，得靠系统主动提醒 + 漏检可追溯。

可通过以下方式减少漏检：

• 在后台为每个设备或点位配置巡检周期和责任人，日常巡检、周检、月度保养都可以设
• 到期前系统自动推送提醒到责任人的微信
• 超期未完成系统自动标注漏检，同步通知一级主管
• 管理者后台看得到全员、全设备的漏检状态，按科室、按周、按设备筛选都行

漏检的根源是"没人提醒、没人追踪"，靠人工盯很难盯全。系统层面自动提醒 + 自动标红之后，这件事从"要不要去检查"变成"不去会被系统看到"。草料二维码里这套机制叫周期任务，配置完就自行运转，不需要管理者手动追人。

小结

工人不去现场检查这件事的本质，不是人的问题，也不是管理不严的问题，是传统的记录方式给了作假空间。纸笔签字、口头汇报、甚至电子化之后的简单表单，都只能记录声明，不能验证动作。

治理这件事的思路不是抓人或喊话，而是让记录方式本身能验证到场行为——扫码要人在现场、定位要落在点位、照片要当场拍、签名要亲笔签。每一种常见的作假都有一层对应的技术拦截，配完之后作假的成本就高过正常去检查的成本，自然没人走这条弯路。

Gitea Enterprise 25.5.0 (Linux, macOS, Windows) - 本地部署的企业级 Git 服务

The Premier Enterprise Solution for Self-Hosted Git Service

请访问原文链接：https://sysin.org/blog/gitea/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

自托管 Git 服务的首要企业解决方案

什么是 Gitea Enterprise

Gitea Enterprise 是基于开源 Gitea 项目开发的增强版。

Gitea Enterprise 提供更可靠的体验并满足企业级用户的要求。Gitea Enterprise 的设计理念是轻量级、易于使用且高度可定制，使其成为小型团队和大型组织的理想选择。

Gitea Enterprise 是基于开源 Gitea 项目开发的 (sysin)，两者有着相似的经验。熟悉 Gitea 的用户可以快速上手 Gitea Enterprise，操作和配置方法几乎相同。

然而，Gitea Enterprise 是为了满足企业用例的需求而构建的。需要注意的是，这些功能需要付费才能激活。

如果您对价格有疑问，可以申请免费试用。试用期为 30 天，在此期间您可以免费使用 Gitea Enterprise 的所有功能。试用期结束后，您可以选择继续使用 Gitea Enterprise，其功能与开源 Gitea 项目相同。

主要优势

• 1. 分支保护继承

  Gitea Enterprise 通过继承功能增强了分支保护，允许您为组织创建分支保护规则，并使其在组织的所有存储库中生效。

• 2. 依赖关系扫描

  自动识别并解决项目开源依赖项中的漏洞。

• 3. 高级安全功能

  Gitea Enterprise 引入了 IP 白名单等高级安全功能，通过限制对某些 IP 地址的访问来增强 Gitea 实例的安全性。它还通过强制双因素身份验证增强了帐户安全性。

• 4. 企业主题

  Gitea Enterprise 提供精心设计的主题，可提供更好的体验 (sysin)，允许您个性化您的用户界面，并与 Gitea 开源项目区分开来。

• 5. SAML 身份验证

  借助 Gitea Enterprise，您可以将 Gitea 配置为 SAML 2.0 服务提供商，从而与企业的身份提供商无缝集成。

• 6. 审核日志

  Gitea Enterprise 提供全面的审核日志功能，为您提供 Gitea 实例内发生的活动的深入历史记录。

新增功能

Gitea Enterprise v25.5.0, 2026-04-19

发行说明未公布，通常为安全更新和常规 Bug 修复。

下载地址

历史版本：

• Gitea Enterprise v24.3.0, 2025-07-22
• Gitea Enterprise v24.5.0, 2025-08-16
• Gitea Enterprise v24.6.0, 2025-10-15
• Gitea Enterprise v24.7.0, 2025-12-02
• Gitea Enterprise v24.8.0, 2026-01-27
• Gitea Enterprise v25.4.2, 2026-02-25
• Gitea Enterprise v25.4.3, 2026-03-05
• Gitea Enterprise v25.5.0, 2026-04-19

Gitea Enterprise v25.5.0, 2026-04-19

• 请访问：https://sysin.org/blog/gitea/

  • Gitea for Linux x64
  • Gitea for Linux arm64
  • Gitea for macOS x64
  • Gitea for macOS arm64
  • Gitea for Windows x64
  • Gitea for FreeBSD 14 x64

数据丰富，决策滞后

零售行业是数据密集型行业的典型代表。从POS收银、会员系统、供应链WMS，到电商平台的实时订单流——零售企业产生的数据量远超大多数传统行业。但讽刺的是，这些企业在做关键决策时，看的依然是昨天的报表。

「618大促期间，运营团队早上8点看到的库存数据，其实是凌晨2点的快照。」这是某头部鞋服品牌CIO在内部复盘时的原话。更要命的是，当他们发现某款爆品库存告急时，数据还没来得及更新，补货决策已经延误了黄金6小时。

这不是个例，我们接触的零售企业，超过70%的零售企业仍在使用T+1甚至更慢的数据同步模式。这意味着，当消费者在线下门店完成购买、当电商平台产生新订单、当仓储系统发生出库——这些业务动作产生的数据，要等12到24小时才能出现在管理者的看板中。

问题的根源不在于零售企业不重视数据，而在于数据架构的设计假设与业务需求之间存在根本性错配。

滞后的根源：T+1批处理的架构缺陷

1.批处理模式的工作原理

传统ETL的数据同步逻辑是「定时批量抽取」：每天凌晨业务低峰期，系统从源数据库执行全量或增量SQL查询，将数据导出、转换、加载到数据仓库，这个过程通常需要2-6小时，取决于数据量大小。

这个模式在2010年代是合理的——彼时零售业务变化慢、渠道单一、T+1数据足够支撑周级决策。但2026年的零售环境已经完全改变：

• 渠道碎片化：线下门店、电商、直播、社群——同一款商品在多个渠道同时销售，库存数据必须实时打通；
• 促销即时化：秒杀、限时折扣需要分钟级的库存反馈，批处理根本无法支撑；
• 客户体验预期升级：会员积分即时查询、门店缺货实时调拨——用户已经习惯「所见即所得」；

2.批处理的三个结构性缺陷

从架构层面分析，T+1批处理存在三个无法通过优化解决的本质问题：

更致命的是，批处理模式下的BI报表只能回答「发生了什么」，而无法支持「正在发生什么」和「将要发生什么」，这在促销常态化、库存波动剧烈的新零售时代，是结构性能力的缺失。

实时数据的价值：从「后视镜」到「仪表盘」

1.库存预警：从「等断货」到「防断货」

传统模式下，库存预警依赖历史销售数据的趋势外推，但实时数据让这一切改变：

实时库存监控场景：

当某SKU的实时销量达到过去7天平均销量的3倍时，系统自动触发「爆品预警」，同步通知采购端补货、运营端调整推荐权重、客服端准备缺货话术，这个响应时间，从原来的「等报表出来再说」压缩到「实时感知即时响应」。

2.动态定价：分钟级价格弹性

某连锁商超的实践表明：接入实时销售数据后，动态定价系统可以在15分钟内完成价格调整决策，而传统模式需要等到第二天才能看到昨天的销量数据，再做下一天的价格决策，这个时间差，在大促期间意味着数百万的GMV差距。

3.精准营销：行为触发的即时响应

会员在门店扫码关注公众号——这个动作在传统架构下要等第二天才被数据系统感知，在实时架构下，可以做到：

• 扫码后30秒内，短信/小程序推送新人优惠；
• 结合实时门店客流数据，在低峰期向周边用户推送到店折扣；
• 会员购买完成后，即时更新会员等级和积分，支持实时兑换；

图：CDC技术通过数据库日志监听实现毫秒级变更捕获

CDC技术：解决思路与原理

1.CDC的核心原理

CDC（Change Data Capture，变更数据捕获）的核心思路与批处理完全相反：不是定时去问「数据变了没」，而是让数据库主动告诉你「数据刚变了」。

具体实现上，CDC通过监听数据库的Write-Ahead Log（WAL）或事务日志来实现：

• 源端数据库发生INSERT/UPDATE/DELETE操作；
• 日志层记录变更（CDC读取binlog/redo log/WAL）；
• CDC组件解析日志，提取变更数据；
• 消息队列（Kafka/Pulsar）接收变更事件；
• 消费端实时处理并写入目标系统；

整个链路端到端延迟可以从批处理的12-24小时压缩到500毫秒以内。

2.技术选型对比

CDC领域的主要技术方案对比如下：

3.为什么零售企业需要CDC而不是批处理

我见过很多零售企业的数据团队在选型时陷入「功能对比」的陷阱——比连接器数量、比组件丰富度，但对于零售场景，核心判断标准只有一个：能否支撑业务实时响应。

CDC相比批处理的核心优势：

• 延迟降低99%：从T+1到准实时；
• 资源消耗平稳：无夜间峰值，数据库负载稳定；
• 故障影响小：实时消费，延迟可控，不会累积；
• 事件驱动架构：天然支持业务事件响应；

实施路径：从单点到全链路的实时化改造

很多企业一听到「实时化改造」就想着推倒重来——这往往是把小事做大的典型误区，正确的路径是从单点突破到全链路覆盖。

• 第一步：选择高频痛点场景切入

  优先选择「数据变更频率高 + 业务决策依赖实时性」的场景，零售企业中，库存同步和订单状态是两个最佳切入点。

  建议：选取1-2个核心业务线做试点，不求全，先验证技术可行性。

• 第二步：CDC链路搭建与验证

  配置源端数据库的CDC功能（MySQL binlog、PostgreSQL WAL、SQL Server CDC等），通过消息队列建立到目标系统的实时同步链路，关键验证点：延迟指标、丢失率监控、断点续传能力。

  

  图：可视化界面配置，降低实施门槛

• 第三步：消费端改造

  CDC同步的数据需要被消费端正确处理：

  BI看板：支持实时数据刷新，而非定时刷新；

  业务系统：订阅变更事件，触发业务流程；

  数据仓库：实时入仓，支持OLAP查询；

• 第四步：全链路覆盖

试点验证成功后，逐步扩展到更多业务线：

会员域：注册、积分、等级变更实时同步；

商品域：价格、库存、上下架状态；

营销域：活动效果、用户行为实时追踪；

实施注意事项

• 源库负载控制：CDC读取日志本身对源库影响很小，但要监控连接数和并发查询；
• 数据一致性：消息队列消费需要幂等设计，防止重复消费导致数据不一致；
• Schema变更处理：源表结构变更（DDL）是CDC的难点，需要版本管理和灰度切换；
• 全量与增量切换：历史数据迁移阶段需要全量+增量并行，确保无数据丢失；

总结：实时化不是升级，是范式转换

很多企业在讨论数据架构时，喜欢用「升级」这个词——批处理升级到实时，T+1升级到T+0，但我认为这是误导性的表述，实时化不是批处理的增强版，而是一种完全不同的数据处理范式。

批处理模式隐含的假设是：数据是「状态」，我可以接受昨天的状态，实时模式隐含的假设是：数据是「事件」，我需要感知每一个事件的发生。

2026年的零售行业，渠道在融合、促销在实时、用户在流动——只有事件驱动、实时感知的数据架构，才能支撑这种业务节奏。

摘要

之前写过Gotify：https://segmentfault.com/a/1190000047531644

现在又了解到一个无需部署服务的消息推送 - ntfy

相关链接：
https://f-droid.org/zh_Hans/packages/io.heckel.ntfy/
https://ntfy.sh/

下载客户端

https://github.com/binwiederhier/ntfy-android/releases

安装后，打开app创建一个订阅主题，自己命名，建议复杂一些，以免和别人一样。

服务端

只需要替换下方客户端的主题名称就行。

<?php

// 获取参数
$topic    = $_GET['topic']    ?? '客户端的主题名称';
$title    = $_GET['title']    ?? '';
$message  = $_GET['message']  ?? '';

// 过滤空值
$data = array_filter([
    "topic"    => $topic,
    "title"    => $title,
    "message"  => $message
], fn($v) => $v !== '' && $v !== null);

// 必填校验
if (empty($data['title']) || empty($data['message'])) {
    exit(json_encode(["ok"=>false,"error"=>"title/message 必填"], JSON_UNESCAPED_UNICODE));
}

// 默认 priority
$data['priority'] = $data['priority'] ?? 5;

// 👉 关键：确保 JSON 编码成功
$json = json_encode($data, JSON_UNESCAPED_UNICODE);

if ($json === false) {
    exit(json_encode([
        "ok" => false,
        "error" => "JSON编码失败: " . json_last_error_msg()
    ], JSON_UNESCAPED_UNICODE));
}

// 👉 用字符串长度避免某些服务器问题
$headers = [
    "Content-Type: application/json",
    "Content-Length: " . strlen($json)
];

// 发送
$ch = curl_init("https://ntfy.sh");

curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => $json,
    CURLOPT_HTTPHEADER => $headers,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT => 10
]);

$response = curl_exec($ch);

// 错误处理
if (curl_errno($ch)) {
    $result = ["ok"=>false,"error"=>curl_error($ch)];
} else {
    $result = ["ok"=>true,"res"=>json_decode($response)];
}

curl_close($ch);

header('Content-Type: application/json');
echo json_encode($result, JSON_UNESCAPED_UNICODE);

然后执行代码：

https:/xxx.com/ntfy/index.php?title=111&message=222

就可以PUSH消息给你手机了。

当然，记得将ntfy设置电池优化无限制，自启动，后台锁定。

本文作者

TANKING

GLM-5.1 技术观察：从“会回答”到“能持续交付”的一次跃迁

主题：GLM-5.1 的核心优化点、公开榜单表现，以及它在工程场景中的真实意义

一、GLM-5.1 是什么

GLM-5.1 是 Z.AI 最新发布的旗舰模型，官方将其定位为面向 long-horizon tasks（长时程任务） 的基础模型。与传统更偏单轮问答的模型相比，GLM-5.1 更强调在一个复杂任务上进行持续规划、执行、修复与优化，目标是把模型能力从“生成答案”推进到“交付结果”。

从产品定位上看，GLM-5.1 已经不是单纯的聊天模型，而是更接近 agentic engineering 的底座模型：它不仅要能写代码，还要能调用工具、完成迭代、保持目标一致性，并在较长时间内持续推进任务。

二、GLM-5.1 的核心优化点

1. 长时程任务能力明显强化

GLM-5.1 最值得关注的升级，不是某一个单点跑分，而是它对“长链路任务”的支持。

官方给出的描述是：GLM-5.1 可以在单个任务上持续自主工作最长 8 小时，完成从规划、执行到迭代优化的完整闭环。这意味着模型优化的重点，已经从“单次回答是否聪明”，转向“长时间执行过程中是否稳定、是否跑偏、是否能持续产出”。

这类能力的价值主要体现在三个方面：

• 目标保持更稳定：复杂任务中不容易中途偏题。
• 错误累积更可控：不是做一步错一步，而是能在流程中修正。
• 闭环交付能力更强：模型不只给方案，还能反复试、反复调、直到结果更可用。

对于工程类任务来说，这种升级比单轮问答能力提升更重要，因为真实开发流程本来就是一个持续迭代的过程。

2. 从“代码生成”升级到“工程交付”

GLM-5.1 的第二个关键变化，是能力重心从传统 code generation 转向了 autonomous agent。

官方文档提到，GLM-5.1 在长时程任务中可以形成“实验—分析—优化”的自主循环，而不是停留在“一次性生成一段代码”。这说明它的优化重点已经覆盖：

• 自动运行与测试
• 发现瓶颈
• 调整策略
• 再次执行
• 对结果持续优化

这类能力比“写出一段看起来正确的代码”更难，因为它要求模型不仅会写，还要会验证、会比较、会修复。

从技术趋势看，这意味着 GLM-5.1 更适合作为以下场景的底座：

• Agent 编程助手
• 自动化研发流程
• 长流程脚本与系统搭建
• 带工具调用的复杂开发任务

3. Agent 工作流适配更完整

在开发者文档里，GLM-5.1 明确强调了它对 agent 工作流的适配，尤其是：

• Thinking Mode
• Function Call
• Structured Output
• MCP
• Context Caching
• Streaming Output

这几个能力放在一起看，意义很明确：GLM-5.1 不只是做对话增强，而是在补齐“可集成、可编排、可自动化”的工程接口层。

可以把这些优化理解为三层：

第一层：让模型更会“想”

通过 Thinking Mode，模型能够在复杂任务中做更长链条的推理与分解。

第二层：让模型更会“做”

通过 Function Call、MCP 和工具接入，模型不再局限于文本输出，而是能真正调外部能力来完成任务。

第三层：让模型更容易“接系统”

Structured Output、Streaming Output、Context Caching 提升了它在真实产品环境中的接入效率与成本控制能力。

这说明 GLM-5.1 的优化方向已经非常明确：不是单纯把模型做大，而是把模型做成一个更适合系统化落地的执行核心。

4. 上下文与输出长度继续扩展

根据官方文档，GLM-5.1 提供：

• 200K 上下文长度
• 128K 最大输出长度

这两个指标说明它在长文档处理、长流程规划、多文件代码理解、复杂上下文续写等任务上，具备更强的承载能力。

不过要注意，长上下文不等于长时程执行能力。真正的难点不只是“记得住”，而是“能否在长过程里保持一致的目标和有效的策略”。从官方表述看，GLM-5.1 的重点恰恰就在这里：把长上下文能力进一步转化为长流程执行能力。

5. 更强调真实工程场景，而非单轮智力展示

从官方展示的案例与 benchmark 选择看，GLM-5.1 的优化明显偏向真实工程环境，而不是只追求传统考试式指标。

例如它重点强调的方向包括：

• 长时程自主执行
• 复杂工程优化
• 真实开发工作流
• 工具调用驱动的性能提升
• 多轮实验后的结果交付

这反映出一个行业趋势：下一阶段模型竞争，已经不只是比“谁更会答题”，而是比“谁更能在现实环境里把事情做完”。

三、GLM-5.1 的排行榜状态

讨论榜单时，最好把 “单项 benchmark 排名” 和 “综合排行榜位置” 分开看。

1. 单项 benchmark：已经进入全球第一梯队

从官方公开的 benchmark 表来看，GLM-5.1 在多个关键指标上已经进入第一梯队，尤其是在工程与 agent 相关任务上表现突出。

（1）SWE-Bench Pro：58.4，官方称为新 SOTA

这是 GLM-5.1 当前最亮眼的成绩之一。

公开对比数据显示：

• GLM-5.1：58.4
• GPT-5.4：57.7
• Claude Opus 4.6：57.3
• Gemini 3.1 Pro：54.2

这意味着在 SWE-Bench Pro 这个更偏真实软件工程修复与多步骤解决的问题集上，GLM-5.1 至少从当前公开成绩看已经拿到领先位置。

（2）Terminal-Bench 2.0：63.5，较前代有明显提升

在终端环境、多步工具调用、命令执行类任务上，GLM-5.1 的 63.5 相比 GLM-5 的 56.2 有明显增长，说明它在工具驱动型任务上的稳定性和完成度都有提升。

不过如果横向看顶尖闭源模型，这一项它仍不是绝对第一。例如公开对比表中，Claude Opus 4.6 为 68.5，仍高于 GLM-5.1。

（3）NL2Repo：42.7，进步明显，但仍有差距

NL2Repo 更考验从自然语言需求到完整代码仓生成的能力。

• GLM-5.1：42.7
• GLM-5：35.9
• Claude Opus 4.6：49.8

这说明 GLM-5.1 在仓级代码生成上较前代进步明显，但和顶尖闭源模型相比仍存在差距。

（4）BrowseComp / CyberGym 等 agent 相关任务进步明显

从公开表格看，GLM-5.1 在多个更接近 agent 的任务上都较前代提升明显，例如：

• BrowseComp：68.0（GLM-5 为 62.0）
• CyberGym：68.7（GLM-5 为 48.3）
• MCP-Atlas (Public Set)：71.8（GLM-5 为 69.2）

这类分数虽然不能简单等同于“真实场景一定更强”，但至少能说明：GLM-5.1 的优化方向并不是只补数学或知识问答，而是在强化“可执行、可调用、可完成任务”的 agent 能力。

2. 综合状态：不是所有榜单都登顶，但已经非常接近全球头部

如果看更综合的公开比较，GLM-5.1 的状态可以概括为：

• 在部分工程类 benchmark 上已经拿到领先成绩
• 整体能力进入全球第一梯队
• 但并不是所有公开榜单的绝对第一

例如，BenchLM 当前给出的 provisional leaderboard 中，GLM-5.1 位列 #10 / 106，并注明其公开覆盖的 benchmark 还不完整，因此这个综合名次更适合当作“阶段性参考”，不能等同于最终全量评价。

换句话说，GLM-5.1 当前最合理的判断，不是“全榜无敌”，而是：

它已经在最关键的 agentic coding 赛道上证明了竞争力，且在开源模型阵营里处于非常强的位置。

四、如何理解 GLM-5.1 这次升级

如果只看新闻标题，GLM-5.1 容易被理解成“又一个参数更大、榜单更高的模型”。但从官方材料和公开成绩看，它更重要的意义其实在于能力评价标准的变化。

过去大家更常问：

• 这个模型会不会写代码？
• 数学题得分高不高？
• 通识能力强不强？

而 GLM-5.1 更像是在回答另一组问题：

• 它能不能在复杂任务里持续工作？
• 它能不能自己试错并修复？
• 它能不能在真实工具环境中完成交付？

这也是为什么它的升级重点会集中在：

• 长时程执行
• agent 工作流
• 工具调用
• 工程闭环
• 结果交付

从行业视角看，这比单纯提升聊天质量更值得关注。因为下一代高价值模型竞争，核心不再只是“更像人”，而是“更像一个能持续推进工作的执行系统”。

五、结论

GLM-5.1 的这次发布，可以概括为三句话：

1. 优化重心已经从通用聊天转向长时程执行与 agentic engineering。
2. 在 SWE-Bench Pro 等关键工程榜单上，GLM-5.1 已经展示出全球头部竞争力。
3. 它的真正价值不只是跑分提升，而是把模型能力从“生成内容”推进到“持续交付结果”。

如果要用一句更直接的话总结：

GLM-5.1 最值得关注的，不是它更会“说”了，而是它开始更会“做”了。

参考信息

• Z.AI 官方博客《GLM-5.1: Towards Long-Horizon Tasks》
• Z.AI Developer Docs《GLM-5.1》
• Hugging Face 模型页《zai-org/GLM-5.1》
• BenchLM 公开模型页《GLM-5.1》

Smoothcloud 润云：全场景算力引擎，AI时代加速器

H200 #5090 #显卡 #GPU #算力 #算力租赁 #租赁平台 #AI

Anthropic 最近的更新频率很高，Claude Opus 4.7 发布了，不用说，又是一大波热度。
但是关注 Anthropic 的用户都知道，这并不是他们最强的模型，他们自己也在 X 上说了。最强的 Claude Mythos Preview 还是没有公开发布呢。

虽然但是，Claude Opus 4.7 也足够让奥特曼睡不着觉了。因为是真的夯呀。

核心能力进化：从执行者到资深同事

Opus 4.7 最大的改进，就是在处理长周期、复杂工程任务时的韧性与一致性。

软件工程 能力的量化突破

在衡量模型解决实际代码问题能力的 SWE-bench Pro 基准测试中，Opus 4.7 的得分从前代的 53.4% 提升至 64.3%。这一成绩不仅刷新了纪录，更拉开了与 GPT-5.4 和 Gemini 3.1 Pro 的差距。而且，在实际开发中，它有很强的自验证意识，会在提交任务前反复核查逻辑。

像素级视觉感知（High-Resolution Support）

这是 Claude 系列首个真正支持高分辨率图像的模型。其长边像素上限从 1568px 提升至 2576px（约 3.75MP），清晰度是前代的三倍以上。

• 1:1 坐标映射：模型坐标现在与实际像素完全对应，开发者在进行屏幕自动化或图像定位时，不再需要编写复杂的缩放算法。
• 视觉推理飞跃：在 CharXiv 视觉推理基准测试中，得分从 69.1% 跳升至 82.1%，能够精准识别高密度网页截图、复杂系统架构图和精密财务报表。

拒绝顺从与逻辑反驳

Opus 4.7 不再是舔狗啦。在 Hex 等平台的测试中，当用户提供的数据缺失或指令逻辑错误时，模型会直接指出问题并报错，而不是编造出答案。跟其他的小妖精完全不一样呢，妈妈再也不用担心我的代码不稳定了。

API 变更

为了追求更高的推理效率和确定性，Anthropic 在 Opus 4.7 中对 API 逻辑做了大幅度删减，这需要开发者立即调整代码逻辑。

• 采样参数移除（强制性） ：新模型移除了 temperature、top_p 和 top_k。如果请求中包含这些非默认参数，API 将直接返回 400 错误。官方建议通过提示词工程引导模型的创造力。
• 思维过程默认隐藏：为了降低延迟，思维块（Thinking Blocks）的内容现在默认省略。如果需要展示推理过程，必须手动将 display 参数设置为 summarized。
• 自适应思维（Adaptive Thinking） ：这是 4.7 唯一支持的思考模式，原有的固定思维预算（Extended Thinking Budgets）已被移除。
• 分词器升级与成本变动：虽然 API 单价不变（输入 $5/M，输出 $25/M），但新分词器处理相同文本生成的 Token 数量会增加约 10% 到 35%。

针对工程流的新特性

• 任务预算（Task Budgets） ：针对长耗时的代理（Agentic）任务，开发者可以设置一个建议性的 Token 消耗上限。模型会实时监控进度，并据此自主调整工作优先级，确保在预算内完成核心任务。
• xhigh 努力水平：新增了介于 high 和 max 之间的 xhigh 努力水平，专门用于处理那些需要极高推理密度的复杂代码重构或架构设计任务。
• 文件系统内存增强：模型在跨会话记录重要笔记方面表现更佳，能够更好地利用历史记录中的上下文，减少冗余录入。

环境配置与接入指南

对于开发者和准备使用 Claude Code 的工程师，接入步骤如下：

1. API 开发环境配置

在项目代码中切换模型前，需确保 SDK 为最新版本。

运行环境：建议 Python 3.7+ 或 Node.js 18+。

使用ServBay一键安装 Python 环境或者 Node.js 环境，还能随意切换。

将模型 ID 指定为 claude-opus-4-7。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    # 启用自适应思维并显示摘要
    thinking={
        "type": "adaptive",
        "display": "summarized"
    },
    # 设置努力水平与任务预算
    output_config={
        "effort": "xhigh",
        "task_budget": {"type": "tokens", "total": 100000}
    },
    messages=[
        {"role": "user", "content": "请分析该代码库的架构并提出重构建议。"}
    ]
)

2. Claude Code 命令行工具配置

Claude Code 是运行在终端的智能助手，适合深度嵌入日常开发流。

安装步骤：确保已通过 ServBay 安装 Node.js，在终端执行

npm install -g @anthropic-ai/claude-code

核心指令：

• 深度审查：输入 /ultrareview，模型会像资深架构师一样通读更改，标记出深层的设计缺陷。
• 自动模式（Auto Mode） ：Max 用户可以授权模型在受控范围内自主决策，大幅减少手动确认的操作。

3. 网络安全验证申请

由于 Opus 4.7 具备较强的自动化能力，官方默认限制了高风险的网络攻防行为。安全研究人员如需将其用于漏洞研究或渗透测试，需通过官方的“网络安全验证计划（Cyber Verification Program）”单独申请解除部分内置限制。

总结

Claude Opus 4.7 的发布标志着 Anthropic 开始从追求跑分转向追求工程严谨性。它对高分辨率图像的原生支持和对复杂任务的自治能力，使其在处理金融分析、法律文档审计以及系统级代码构建时表现出色。虽然 Token 消耗略有增加，但其带来的交付质量提升足以抵消相应的成本。

最近看到很多关于数据中台项目烂尾的资讯，作为一家在数据集成领域摸爬滚打多年的企业，这次我们想从技术工程师的视角聊聊这个问题。

数据中台曾被寄予厚望，企业都想借助它打破数据孤岛、沉淀数据资产、支撑业务决策，让其成为企业数智化升级的核心引擎。但现实往往骨感：据公开数据显示，企业级数据中台项目的失败率高达60%以上，大部分企业投入几百万、上千万的资金，耗时数月甚至数年，但项目最终还是沦为“PPT工程”，陷入烂尾困境。渐渐的市场上出现了一些声音，数据中台烂尾的真相究竟是什么？为什么我的数据中台做不起来？等等如此。

大多数企业都跳过了最基础的ETL数据集成环节，想着一步到位做数据治理、数据服务、数据资产，却忽略了：用好ETL工具，才是数据中台建设的核心前提，更是避免项目烂尾的关键。

一、数据中台的认知“误区”

我们接手了不少企业的数据集成项目，其中不乏有做过数据中台的企业，我们问起他们对数据中台的理解及“弃用“原因，普遍企业认为数据中台等同于“重技术、轻价值”的认知误区，认为只要接入数据源、搭建好数据仓库，就能直接实现数据治理、输出数据服务，却完全忽略了最基础的ETL数据集成环节，想着一步到位搭建数据治理、数据服务、数据资产体系。

于是，项目初期团体采购高端设备、组建技术团队，埋头搭建数据治理框架、设计数据资产体系，却因缺乏ETL数据集成的支撑，陷入“无高质量数据可用”的困境。最终，数据治理、数据服务无法落地，数据资产更是无从沉淀，项目只能走向烂尾——这一切的根源，都是没有用好ETL工具，跳过了数据中台建设的基础步骤。

二、ETL是数据中台的必选项

ETL核心是将ERP、CRM、OA等各类分散系统中的异构数据，通过抽取、清洗、转换、标准化，最终加载到数据仓库/数据湖中，形成统一、高质量的数据源。跳过ETL将会造成以下情况：

1. 数据质量失控

源系统数据格式不一、质量参差不齐，直接接入中台会导致"垃圾进垃圾出"。我曾见过一个项目，客户直接把ERP、CRM、OA的数据"原样接入"数据湖，结果：

• 同一个客户在三个系统里有三个不同的名称；
• 日期格式五花八门：YYYY-MM-DD、DD/MM/YYYY、时间戳混用；
• 金额字段有的带货币符号，有的是纯数字，有的用逗号分隔千位；

没有ETL层面的数据清洗和标准化，后面的所有分析都是建立在沙滩上的城堡。

2. 数据标准缺失

ETL不仅是技术工具，更是建立数据标准的最佳时机。在数据抽取、转换的过程中，你需要：

• 定义统一的字段命名规范；
• 建立数据字典和元数据管理；
• 制定数据质量规则和校验逻辑；

跳过这一步，数据中台就成了"数据垃圾场"——数据有了，但没人知道怎么用。

3. 性能和成本双失控

没有经过ETL优化的数据，直接进入数仓或数据湖，会导致存储和计算成本暴涨。一个典型案例：

某互联网公司每天产生10TB原始日志，未经ETL处理直接存入数据湖。半年后发现：

• 存储成本翻了3倍（大量重复、无效数据）；
• 查询性能下降80%（缺乏分区和索引优化）；
• 计算资源浪费严重（每次查询都要处理全量数据）；

没有ETL的支撑，分散在各个系统中的数据就是“杂乱无章的垃圾”——格式不统一、口径不一致、存在大量脏数据，即便投入再多精力做数据治理，也只能是“垃圾进、垃圾出”；没有ETL输出的高质量数据，数据服务无法提供精准支撑，数据资产更是无法沉淀，数据中台自然沦为“闲置摆设”。

三、ETL能够给数据中台带来什么

我们都在说ETL是数据中台的核心，但ETL究竟在完成什么，对数据中台又有什么具体的帮助呢，很多人对ETL的认知还停留在"写SQL脚本定时跑数据"的阶段。这是多年前的认知。

现代ETL平台早已进化成数据集成平台，是数据中台建设中不可或缺的基础设施：

1. 数据采集：打通数据孤岛

• 支持100+数据源一键连接；
• CDC实时捕获数据变更；
• 跨系统、跨数据库的数据同步；
• 没有这一层，数据中台就是无源之水。

2. 数据清洗：保障数据质量

• 统一数据格式和编码规则；
• 空值检测与自动补全；
• 数据质量规则引擎；
• 敏感信息脱敏处理；

没有这一层，数据资产就是数字垃圾。

3. 任务调度：确保系统稳定

• 可视化任务编排；
• 依赖关系自动管理；
• 失败告警与自动重试；
• 全链路运行监控；

没有这一层，数据服务就是无本之木。

4. 数据服务：支撑业务应用

• API快速发布；
• 数据服务编排；
• 权限管理与流量控制；
• 服务质量监控；

没有这一层，数据价值就是空中楼阁。

四、数据中台的正确建设路径

📌 第一阶段：数据集成平台建设（2-3个月）

核心任务：让数据进得来、跑得稳、用得上

避坑：上来就接入全部系统？先跑通核心链路再说。

📌 第二阶段：数据治理体系建设（3-6个月）

核心任务：让数据可信赖、可追溯、可治理

避坑：治理方案做得全，但没人执行落地？建立数据质量评分体系。

📌 第三阶段：数据服务化发布（3-6个月）

核心任务：让数据赋能业务、产生价值

避坑：一个指标多套口径？建立指标字典，一个指标只有一个官方口径。

📌 第四阶段：数据资产运营（持续迭代）

核心任务：让数据资产化、价值化

避坑：把数据当免费公共资源？建立成本核算体系，让使用者有成本意识。

图：ETLCloud轻量级数据中台架构

五、实操案例：闭环落地是数据中台成功的共性

事实上，那些成功落地的数据中台，无一不是建立了完整的数据价值闭环，这也印证了闭环体系对数据中台的决定性作用：

• 某头部电商企业：以业务需求为核心，不追求大而全的架构，先聚焦“统一用户画像”这一核心痛点，通过ETL工具完成数据清洗与标准化，建立统一的标签体系，解决营销、客服、风控部门的核心需求，随后根据业务反馈持续迭代，最终实现营销精准度提升30%、客服效率提高50%的成效。
• 京东供应链中台：通过“业务解耦—能力封装—动态组合—生态开放”的路径，将数据能力嵌入供应链全流程，形成“数据支撑业务、业务反哺数据”的闭环，支撑其实现库存周转天数降至30.2天的行业标杆水平。

这些案例充分证明：数据中台的价值，不在于技术有多先进，而在于能否通过闭环体系，让数据真正服务于业务、创造价值。

六、分享给还在建设数据中台的企业

回到开头的问题：数据中台为什么容易烂尾？

不是因为"中台"这个概念错了，也不是因为技术不够先进。

而是因为太多企业把数据中台当成了"技术工程"来做，而不是"数据工程"来做。

数据中台的本质，是构建一条高效、可靠、可治理的数据流通管道。

这条管道的核心能力，就是ETL。

别再去「龙虾会」了！这是只给 Agent Builder 的北上杭闭门局
「AI 搞什么？问题在 Data。」

不知道你有没有这种感觉：

现在的 AI 活动越来越多，台上讲的都是融资、估值、行业大势，台下坐的一半是围观群众，一半是销售BD。

聊到最后问一句：「你亲手用Agent帮你解决过真实场景的复杂长尾任务吗？」一半人都沉默了。

我们不想办这样的「龙虾会」。

这次 Data for AI × 「AI 搞什么」 联合做的，是 只给真正动手做 Agent 的 Builders 的闭门局：

北上杭三城，每场 50 人上限，不带 PPT，带你的真实案例，带你踩过的坑，带你卡了半个月还没解决的问题来。

我们不搞「台上讲、台下听」的老一套，每个来的人，都是分享者，也是解决问题的人。

🎯 我们要做的，是一张 Builder 的跨城市互助网
办活动从来不是我们的目的。

我们真正想做的，是把各城市一线动手做 Agent 的人攒到一起：

✅ 不用讲正确的废话，就聊「Agent 碰数据」这件事上你踩过的血泪坑。

✅ 不用搞无效社交，就认识几个真的能帮你解决问题的同行。

✅ 不用一个人闷头踩坑，以后你在做 Agent 的路上卡壳了，群里喊一声，就有过来人给你兜个底。

这只是系列的第一站，接下来我们会把这个局月度化做下去，深圳站也很快就来，目标就是让北上杭深每一个做 Agent 的 Builder，都能找到自己的组织。

🔥 本期主题：OpenClaw 玩家们，你怎么敢让 Agent 读写你的 Data？
每一个真的做过 Agent 的人，都懂这个问题的重量： 你敢让你的 Agent 随便读本地文件吗？你怎么保证它不会删错你的数据？多数据源权限怎么管控？出了问题怎么审计？

这些问题没有标准答案，但每个踩过坑的人，都有自己的一手经验。

这次我们就聊真东西，不搞虚的。

① 分享环节：每个参会的人都要讲
自我介绍就是案例分享，每个人都要回答四个问题：

做了什么：
你用 Agent 做了什么产品/工具，解决了什么问题（一句话说清）。
踩了什么坑：
最痛的那个坑是怎么踩的，最后怎么爬出来的。
想问什么：
现在还卡在哪，想找什么样的人求助。
自检：
你讲的东西，能不能帮到在场的至少一个人。
② 研讨环节：就聊最痛的真实问题
我们会围绕「Agent 访问 Data」的核心痛点展开讨论，话题包括但不限于：

✅ 权限 & 安全：Agent 的身份、授权、最小权限、审计。

✅ 读写边界：正确性、完备性、一致性怎么保证。

✅ 数据治理 & 合规：合规要求、跨境传输的坑。

✅ 工程实践：Multi-Agent × 多数据源落地的通用踩坑。

🎤 首批硬核嘉宾议题（13位已确认，持续更新中）
这次我们已经攒了一波硬核 Builder，先放几个议题给大家感受下：

📌 《Hermes-Agent 90k⭐ 是怎么来的：信息流 + Obsidian + 自动精选推送体系》 —— nemo｜杭州斑头雁科技（Nous Research 早期 PR 贡献者）。

📌 《三省六部「AI 朝廷」：基于 OpenClaw 打造一个开源 Multi-Agent 政体》 —— 王力宽｜ItsNotAI Co-Founder / 「AI 朝廷」原作者。

📌 《我是如何组建和锻造了多个Agent团队，实现了更快、更好、更便宜的软件开发生命周期》 —— 瑞典马工｜Agent特区发起人。

📌 《我是如何解决视频搜索只能检索转录的语音文本的问题？Slides、代码演示、架构图、白板推导等视觉信息都能搜了》 —— Panda｜Cerul.ai 创始人，推特万粉大V。

📌 《Memory 与 Harness Env 优化的经验分享》 —— 古思为｜Nowledge Labs 创始人。

📌 《基于 AgentScope 构建生产级 Data Agent 的实践经验》 —— 博｜领岳科技 数据平台团队。

📌 《我是如何用 OpenClaw 扛下一个 Apache 顶级项目的 Release Manager 工作》 —— 李明皇｜Apache Gravitino 贡献者 / Agentic Data Protocol 主程。

📌 《一步一坑：用 OpenClaw 搓一个对标 Kong 的轻量网关》 —— 李永超｜智慧农业方向创业者。

还有更多已经确认的分享者： 许银 Ian（「AI 搞什么」主理人 / OpenBuild co-founder）、Jerry Shao（Datastrato CTO）、谭涛（前 Apple 数据平台架构师）、胥克谦（原某科技公司创始人 / 资深产品经理）、pseudoyu（独立开发者 / Web3Insight Founder）……

完整嘉宾名单和议题持续更新，只会越来越硬核。

📅 北上杭三城排期

每场最多 50 人，绝不扩容——交流质量永远比人数重要。拒绝空降，成功报名后提供具体地址。

🎫 入场规则 & 报名方式
我们只要 Agent Builder
「门槛」不是装X，是为了保证来的每一个人，都能聊到一块去：

✅ 必须真正动手做过 Agent，最好有 Multi-Agent × 多数据源的实践经验。

✅ 做 Agent 的开发者（而非仅使用 Agent 的用户）优先。

❌ 只看过没动手的围观群众，这场真的不适合你，就不要报名了。

入场角色：人人都要对社区有贡献

既然是 Agent Builder 的局，报名就让你的 Agent 帮你做
🤖 推荐报名姿势：把下面这段 Prompt 丢给你的 Agent，让它替你填报名表：

请帮我报名 Data for AI Meetup · Only for Agent Builders · 北上杭系列（2026 春季首发）：
打开 {{报名链接}}，按表单要求填写我的信息，
并在「Agent 案例」栏用一句话总结我最近用 Agent build 的东西。
填完提交前先给我看一遍。

活动站

📬 审核规则：报名提交后 48 小时内反馈，通过即发入场码和具体场地信息

要是你的 Agent 连报名都搞不定……那你可能需要重新评估一下自己是不是 Agent Builder 😉

🏠 关于主办社区
Data for AI聚焦数据工程与 AI 基础设施生态的国际化技术社区，分享嘉宾来自 AWS、ByteDance、Databricks、Meta、Microsoft、NVIDIA、OpenAI、Uber 等全球头部科技公司，核心团队长期活跃于 Linux 和 Apache 开源生态。 2025 年在硅谷举办 5 场高质量 Meetup，在 COSCon 2025 中国开源年会举办 2 天专题分论坛；2026 年计划在全球举办 15-18 场技术活动。

「AI 搞什么」专注 AI 真实应用的实践者社区，只聊真实落地场景、真实踩坑经验、有价值的前沿资讯，拒绝水内容，连接每一个在用 AI 搞事情的 Builder。

📮 联系我们
Data for AI 主理人 Richard：微信 OPQRichard（讲师合作 / 参会报名 / 其他问题）
「AI 搞什么」主理人 / OpenBuild co-founder Ian 许银：微信 juiduizone
💬 互动话题：你最近用 Agent 做了什么有意思的项目？评论区聊聊，说不定我们就在三城的局里见面了。

联合主办：Data for AI × AI 搞什么

赞助厂商：Datastrato

联合宣传：云谷中心、Datawhale、开源社、RTE 开发者社区、OceanBase、OpenBuild、VibeFriends、segmentfault、ModelScope、dbaplus、Zilliz 等。

4月19日，2026人形机器人半程马拉松赛在北京亦庄落下帷幕。当100余支队伍的人形机器人穿越平地、坡道、急弯、狭窄路段，冲向20多公里外的终点时，一个信号已经足够清晰：人形机器人正在从实验室的“精密样机”，向可长时间、高负载运行的“准产品”加速演进。

机器人跑马拉松，本质上是一场对机器人运动控制、自主导航、续航散热、环境适应、系统可靠性五大核心能力的极限压力测试，堪称机器人领域的“F1赛事”。而在这背后，一条隐形的“具身工具链”：从数据采集到仿真训练，正在成为决定机器人能否从“能跑”走向“能用”、“能量产”的关键底座。

一、规模跃升：这场半马在考什么？

今年的赛事在规模与技术创新上实现了全面跃升。参赛队伍数量超百支，较去年增长近5倍，涵盖自主导航与遥控两大类别。其中最值得关注的信号是：自主导航赛队占比近四成，这是该项技术的首次规模化实战检验。
这意味着什么？去年多数机器人依赖人类操作员跟随遥控，本质上是一台“被牵着跑的提线木偶”。而今年，近四成机器人需在开放城市环境中自主完成定位、建图、路径规划、动态避障的全流程决策——这是从“遥操作”到“真自主”的质变。
赛道融合平地、坡道、弯道、狭窄路段等10余种地形，包含12个左转道、10个右转道及接近90°的急弯。对一台身高与人相仿、体重数十公斤的双足机器人而言，这场赛事是对五大核心能力的极限压力测试：

• 运动控制能力：实验室调好的步态参数，在坡度、颠簸路面可能瞬间失效。机器人需在每一步实时调整重心、步频与落脚点，高速奔跑或急转弯时更要求毫秒级姿态校正。
• 自主导航能力：视觉语言动作模型的泛化能力决定机器人能否在弱信号环境中，依靠端到端感知规划一体化，将仿真策略平滑迁移至现实的长尾场景。
• 续航与能源管理：关节电机持续高扭矩输出，BMS需在高倍率放电下防止过放损伤并维持电压稳定。
• 散热能力： 连续高负荷使关节电机热量骤增。热感知控制算法需根据实时温度动态调节运动增益，在散热与速度间取得平衡，防止硬件保护性降频。

• 系统可靠性：数小时连续振动冲击下，一颗螺丝微动、一根线束磨损、一个接插件接触不良，都可能演变为致命故障。
  五项考核直指同一个问题：这台机器人，到底能不能在真实世界中稳定、可靠地工作？

  二、软件军备：水面之下的“马拉松训练营”

  硬件是看得见的肌肉，让钢铁之躯稳定奔跑的，是看不见的“神经与大脑”。今年自主导航赛队涌现、完赛率跃升的背后，是一场软件与算法军备竞赛。
  步态算法的泛化能力是第一个坎。 平地最优参数在5°上坡可能致机器人后仰，下坡则可能前倾。自适应步态控制要求算法在线感知地形变化并毫秒级调参——远非离线调参所能覆盖。
  多传感器融合的鲁棒性是第二个坎。 定位漂移、视觉短暂失效、IMU零偏累积——能在这些干扰下保持稳定的融合算法，必然经受过大量异常场景考验。
  实时决策的计算效率是第三个坎。 所有感知、规划、控制计算都须在本体有限算力内完成。如何在嵌入式平台跑通复杂算法，是工程落地的核心难题。
  这些算法迭代、异常场景覆盖、系统可靠性验证，难道都靠实机一趟趟跑？一台双足机器人硬件成本动辄数十万，一次摔倒可能报废整个关节模组。用实机跑1000次半马收集数据——没有哪家公司烧得起。
  答案藏在那条隐形产业链里——具身工具链。

  三、具身工具链：机器人进化的“隐形底座”

  在站上亦庄赛道前，机器人早已在虚拟世界中“跑”了上千个21.0975公里。从场景搭建、数据采集、仿真训练到评测验证的完整流水线，正成为头部团队加速迭代的标配基础设施。
  数据采集服务解决“人类示范从何而来”的问题。 通过动捕系统、遥操作外骨骼等数采设备，规模化采集人类操作轨迹与行为数据——从全身运动序列到指尖力控细节——为机器人模仿学习提供高质量示范样本，让算法有“教材”可依。
  
  仿真训练场是工具链的“加速器”。 在物理级高保真数字孪生场景中，机器人可进行数百万次零成本试错。路面摩擦、坡度曲率、光照条件、动态障碍物等变量均可参数化配置，步态调整效果即时量化。仿真环境批量生成标注感知数据与控制序列，将原本数月的实机测试周期压缩至数周，显著加速算法迭代。
  
  仿真数据合成平台是工具链的“数据引擎”。 通过域随机化与程序化生成技术，批量产出长尾任务、故障模式与极端工况的合成数据。以低成本、零风险方式扩充训练集规模与多样性，提升模型泛化能力，将开发测试周期从“月”压缩至“天”。
  仿真评测平台是工具链的“质检员”。 自动量化关节温度曲线、电池电压跌落、步态对称性、路径跟踪误差、避障成功率等多维指标，生成标准化的机器人“体检报告”。每版算法迭代效果可横向对比、客观度量，实现数据驱动的闭环开发。
  凡拓数创作为物理AI厂商已经开始系统布局这一整套工具链。其打造的创新链式具身仿真多元工具组合涵盖高保真仿真训练场、多源数据采集系统以及自动化评测引擎，预计将于2026年6月正式发布。
  这套工具组合的核心逻辑在于打通“场景搭建-数据采集-仿真训练-评测验证”的全链路，先在数字孪生环境中批量生成边缘场景的训练数据，再将实机测试采集的珍贵故障数据回灌至仿真环境复现与泛化，同时以标准化评测体系量化每一次迭代的收益。这种“虚实闭环”的开发范式，正在将机器人算法研发从“手工作坊”推向“工业化流水线”。
  2026年被定义为“人形机器人规模量产元年”。当行业从“炫技”走向“真落地”，比拼的不再是赛事名次，而是谁能以可控成本、可复现质量将机器人交付到工厂、商场、家庭。
  机器人马拉松是一场秀，更是试金石。聚光灯下，它验证了运动控制、自主导航、续航散热的跃迁；聚光灯外，一条从数据采集、仿真训练到评测验证的工具链正加速成熟——它或许才是决定这场长跑谁能笑到最后的关键底座。

大家好，我是老刘

金三银四的喧嚣刚刚退去，不少同学可能已经落定新坑，或者还在观望。随着五月各大开发者大会的临近，四月的跨平台技术圈更像是风暴前夕的宁静。

各大框架都在为接下来的大招蓄力，而AI与端侧开发的融合也从概念阶段进入了真刀真枪的实战期。四月到底有哪些值得关注的技术动态？新项目选型又该避开哪些坑？今天老刘带你一探究竟。

1. 四月跨平台技术综述

金三银四的喧嚣刚刚退去，四月的跨平台技术圈主打一个“内功修炼”和“生态补齐”。如果你期待看到什么颠覆性的新框架，这个月可能会略显平淡；但如果你关注的是落地体验和底层基建，那四月的动态绝对暗藏玄机。

本月的核心趋势本质上可以提炼为两个关键词：底层体验与AI赋能实战化。

• 底层体验的：大家都在忙着还技术债、补短板。Flutter 3.41 版本表现出极高的稳定性，显然是在为五月的大招蓄力；React Native 0.85 直接掏出了全新动画引擎，解决复杂交互卡顿的痛点；KMP 2.4.0-Beta1 终于对大家吐槽已久的 SwiftPM 兼容性下手，扫清了融入 iOS 现代生态的障碍；而 uni-app x 在猛攻鸿蒙生态之余，四月份也老老实实回归到了 iOS 和 Android 基础盘的稳定性修复上。
• AI赋能不再是噱头：AI 已经从简单的 API 调用，迈向了实质性的工程化落地。最典型的就是 .NET MAUI，官方联合生态伙伴直接把定制化的 AI Agent 塞进了框架的开发和测试工作流里。同时，端侧部署轻量级AI模型也逐渐成为今年高级客户端开发的分水岭。

各大框架都在为接下来的五月开发者大会季疯狂蓄力。四月，正是一个绝佳的技术沉淀和选型复盘期。接下来，咱们就逐一盘点这五大跨平台框架的最新动作，看看哪些更新能真正帮你解决手头的业务痛点。

2. 最新技术动态

2.1 Flutter 3.41 基本稳定

Flutter更新日志: https://docs.flutter.dev/release/release-notes

Flutter 3.41.6 在3月27日发布，之后再没有更新。

说明Flutter 3.41版本相对还是比较稳定，没有需要紧急修补的重大问题。

按照Google的路线图，下一个较大更新的版本估计是五月份的3.44。

2.2 Kotlin Multiplatform (KMP)：Kotlin 2.4.0 Beta1版本推出

Kotlin 新特性: https://kotlinlang.org/docs/whatsnew-eap.html

这次 Kotlin 2.4.0-Beta1 在跨平台方向上终于对大家一直吐槽的点下手了。主要有两大看点：

• 痛点解决：原生支持 Swift Package Manager (SwiftPM)

  • 直接在 Gradle 中引入 ：之前 KMP 和 iOS 原生生态交互时，很多时候还要强依赖过时的 CocoaPods。现在，KMP 项目终于可以直接在 Gradle 配置文件里声明 Swift 包作为 iOS 应用的依赖项了。
  • 官方迁移工具护航 ：如果你之前的项目重度依赖 CocoaPods，官方不仅给了详细的迁移指南，KMP 的相关工具链还会帮你自动重新配置项目，平滑过渡到 Swift Packages。这意味着 KMP 融入 iOS 现代生态的最后一道门槛被彻底打通，开发体验直接拉满。

• 底层护城河加固： .klib 编译阶段的内联函数行为统一

  • 解决历史遗留问题 ：过去在 Kotlin/Native、Kotlin/JS 和 Kotlin/Wasm 平台上，内联（inlining）只在最终的二进制文件生成阶段发生。这就导致 .klib （Kotlin 跨平台库格式）没法像 JVM 那样提供稳定的内联兼容性保证。
  • 模块内内联默认开启 (Intra-module inlining) ：从 2.4.0-Beta1 开始，编译器在生成 .klib 产物时，默认开启了模块内的内联。这是一个底层架构统一步伐的重要里程碑。
  • 未来的跨模块大招 ：官方明确表示，这一步是为未来实现“跨模块内联 (Cross-module inlining)”打基础。目前你已经可以通过命令行参数提前尝鲜，这对未来构建大规模、高性能的跨平台三方库绝对是个好消息。

老刘点评 ：
这波更新释放了一个很强烈的信号——KMP 正在从“能用”向“好用且符合直觉”快速进化。尤其是 SwiftPM 的官方支持，对于想用 Kotlin 全栈搞定 MVP 并且要求 iOS 端体验丝滑的独立开发者来说，绝对是一剂强心针。

2.3 React Native 0.85 全新动画引擎与生态补齐

React Native博客: https://reactnative.dev/blog

就在4月初，0.85版本携全新动画后端(New Animation Backend)登场。

以往做复杂交互动画，容易掉帧或卡顿。新引擎从底层优化了渲染逻辑，让丝滑交互不再是原生开发的专利。此外，新的 Jest Preset Package 也让单元测试的配置变得更加简单，测试覆盖率的提升不再痛苦。

2.4 uni-app x 5.04至5.07版本

uni-app x更新日志: https://doc.dcloud.net.cn/uni-app-x/release.html

继上个月5.03版本推出鸿蒙蒸汽模式并大幅提升渲染性能后，uni-app x在4月份（5.04至5.07版本）的更新节奏主要回归到了多端生态的稳定性修复与基建升级上。

• 5.07版本 (Android端)：重点修复了由5.0大版本引发的 API uni.showLoading 未显示时调用 hideLoading 隐藏方法导致的应用崩溃问题，进一步提升了安卓端的运行稳定性。
• 5.05版本 (iOS端)：云端打包环境迎来了重要升级。Xcode升级至16.1版，iOS SDK升级至18.1版，并且全面支持iOS 13及以上系统。这对于需要适配最新苹果生态的开发者来说是个好消息。
• 5.04版本 (跨端修复)：修复了iOS平台 native-view 组件动态创建销毁时的崩溃问题；同时针对微信小程序平台，修复了CSS样式隔离策略和 externalClass 在部分场景下失效的Bug。

老刘点评：
可以看出，官方在重兵投入鸿蒙生态的同时，也没有落下对传统iOS和Android基本盘的维护。

2.5 .NET MAUI：官方智能体

.NET MAUI博客: https://devblogs.microsoft.com/dotnet/category/maui/

就在4月份，.NET MAUI 迎来了两波重磅更新与生态提速：

• .NET 11 Preview 3 带来实质性增强：基础体验有了显著提升。地图组件引入了聚类（clustering）、样式定制以及更丰富的交互 API；XAML 和样式的改进进一步减少了启动时间并加快了迭代速度；长按手势（LongPressGestureRecognizer）终于成为内置支持；此外，.NET for Android 已经提前加入了对 Android 17 (API 37) 预览版的支持。
• AI Agent 深度赋能社区开发：这是非常具有前瞻性的一步。官方联合生态伙伴 Syncfusion 推出了一套专门针对 .NET MAUI 的定制化 AI 智能体（如 pr-review 技能和 write-tests-agent）。以往修复跨平台 Bug 需要耗费数天时间复现和测试，现在通过 AI 智能体，可以自动分析 Issue、生成多平台测试用例（UI交互、XAML解析等），甚至通过“Try-Fix”策略自动提出并在各个平台上跑通测试验证修复方案，极大降低了开源贡献的门槛。

老刘点评：
如果说之前的 MAUI 还在为基础功能补课，那么现在的 MAUI 正在借助 AI 的力量实现开发体验上的弯道超车。AI Agent 融入底层框架的开发和测试工作流，不仅加速了框架本身的迭代，也为我们日常的业务开发提供了新思路：未来的跨平台开发，比拼的不仅是框架的渲染性能，更是 AI 辅助工具链的完善程度。

3. 技术选型指南（4月实战版）

相比于金三银四的求职导向，四月的选型更侧重于项目实战与技术沉淀：

3.1 存量项目重构与优化

• Flutter项目：建议逐步升级至3.41，享受Impeller带来的性能红利。同时，团队可以开始调研Genkit的接入方案，为下半年的AI需求爆发做好技术储备。
• KMP项目：暂时不建议升级beta版本，等待稳定后再升级。
• React Native项目：是时候彻底拥抱新架构了。如果你的项目还在使用旧版架构，0.84/0.85是绝佳的升级节点，不要让自己被锁死在旧生态里。
• .NET MAUI项目：尽早熟悉AI Agent带来的开发效率提升。

3.2 拥抱端侧AI开发

别再把AI当成简单的API调用。学会使用Flutter或RN的端侧模型插件，将轻量级模型打包进应用，实现断网可用、隐私安全的本地智能，这将是今年高级客户端开发的分水岭。

3.3 新项目快速试错

对于需要快速验证商业模式的新项目，Flutter依然是首选。它不仅能保证多端一致的体验，还能借助丰富的社区资源迅速搭建MVP。

如果强依赖国内的小程序生态，uni-app则是绕不开的最佳路径。但还是要再次强调，一定要要清晰的区分产品包含App、小程序的场景和App与小程序功能基本一致的场景。后者才推荐uni-app。如果App和小程序的功能重叠度不高还是推荐分开选择技术栈。

4. 总结与建议

四月是一个难得的技术沉淀期。风暴前夕，与其焦虑，不如行动。

老刘建议大家本月专注以下两件事：

1. 夯实底层基础：无论框架怎么变，渲染原理、内存管理、多线程模型这些底层逻辑是通用的。把时间花在这些不变的知识上，你的技术护城河才会越来越深。
2. 试水端侧AI部署：在你的Demo里跑通一个本地大模型。理解模型量化、端侧推理的基本概念，让自己成为那个懂AI的客户端开发。

技术的车轮滚滚向前，只有不断学习，才能永远在牌桌上。看完四月的盘点，你手头的项目准备在今年做哪些技术栈的升级？欢迎在评论区和老刘聊聊。

🤝 如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

🎁 点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

🚀 覆盖90%开发场景的《Flutter开发手册》

📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。

🔗 https://github.com/lzt-code/blog

企业日常运营中，营业执照、许可证、合同、发票等非结构化单据构成了一条沉默而庞大的数据洪流。传统财务审核模式下，这些单据依赖人工录入、比对与核验，不仅单笔处理耗时，审核质量也高度依赖个人经验，错审、漏审风险隐蔽。同时，审核规则分散在各部门与系统中，更新滞后，历史审核数据与退单原因无法沉淀为知识资产，导致企业反复为“重复错误”买单，系统难以自我进化。
针对企业财务场景下单证审核等业务流程中被低估的“隐形风险”，枫清科技推出智能单证识别与 AI 自学习审核解决方案，将 AI 能力深度融入企业现有流程，实现合规、标准化审核，显著降低财务人力投入。

AI 初审与人工终审：更务实的协作模式

枫清科技构建"AI 初审 + 人工终审"的协同作业模式，为审核场景提供更务实的路径。系统通过多模态大模型与 OCR 技术，自动完成票据识别、字段抽取与全量规则校验，精准标识合规风险并给出审批建议。

与此同时，人工保留对高风险事项的最终判断权与解释权，补充专业意见并完成终审。该设计让 AI 成为放大专业能力的工具，而非替代专业人员。
此外，针对企业审核规则不透明、僵化难维护的问题，枫清科技方案引入可视化规则引擎与自学习迭代机制。规则以自然语言配置，可自动发现规则矛盾，确保逻辑透明、可追溯、可快速调整。更重要的是，系统可基于审核结果与人工反馈，自动分析规则短板并输出优化建议，形成"审核 → 反馈 → 迭代 → 优化"的闭环，让审核规则从静态配置转向动态进化，随业务变化持续升级。

技术作为底层支撑，体验作为交付标准

枫清科技多模态智能识别提取方案，可处理 PDF 扫描件、图片、复杂表格等多种格式，识别准确率达 95% 以上；面对水印、特殊字体、页眉页脚等干扰因素，可实现隐含关系推理与上下文语义理解。在此基础上，系统围绕一致性、有效性、真实性、合规性等关键维度进行全量校验，从源头拦截错审风险。
使用体验上，在申报端，员工只需批量上传附件，系统自动提取关键要素并完成预审核校验；在审批端，审批人可查看全景展示与智能诊断，快速定位风险并作出有据可依的专业判断。

灵活部署：开箱即用的智能化实践

枫清科技智能单证解决方案已在大型集团企业财务共享中心部署应用，可精准应对海量报销单据审核，覆盖发票、住宿水单、交通票据等几十类单证、20 多种审核场景。
方案支持 API 对接、私有化部署或一体机部署，可无缝对接现有财务、OA 系统，不改变原有业务流程即可快速落地。依托集团级AI平台底座，系统还具备全格式兼容、多层级规则配置与零代码灵活调整的能力，既能适配集团及子公司差异化的审核要求，也能快速响应业务变化。

全链路一体化：从单点工具到平台化运营

此外，枫清科技以AI智能审核引擎为核心，将规则治理、智能申报审核、数据合规管理与自优化迭代串联为一体化的智慧财务审核管理平台。企业无需在多个系统间切换，即可完成从规则配置、单据申报、AI初审到人工终审、规则反哺优化的全链路闭环，让财务审核从单点工具走向可持续的平台化运营。
AI 在企业日常经营中的价值，首先在于解决经过反复验证的真问题 —— 让单据处理不再消耗过量人力，让审核标准不再因人而异，让系统具备从经验中学习的进化能力。枫清科技，以 AI 自学习驱动财务单证智能审核，让合规更高效，让规则自迭代。

导读

本项目成功将Karpathy在AI研究领域的AutoResearch方法迁移到软件开发领域，通过多AI Agent交叉审核、5维度量化评分和反馈驱动迭代三大改进，构建了一个全自动的软件开发系统。该系统以program.md为规则核心，实现从GitHub Issue识别、代码实现、测试验证到审核合并的完整闭环，仅在少数情况下需要人工介入。实践表明，该系统能在约10分钟内自主完成中等复杂度的开发任务，并达到9.0/10的代码质量标准，显著提升了开发效率并降低了人力成本。

像 Karpathy 训模型一样开发软件。

1 项目介绍

项目地址：

https://github.com/smallnest/autoresearch

最近做了优化：

• 将此工具抽取成独立的项目
• 代码进行了重构，增加了更多的控制
• 通用化, 可以应用于任意的github项目
• 增加了opencode,可以实现1个到3个任意组合的Coding Agent交叉审核和代码实现

2 什么是 Karpathy AutoResearch？

2026 年 3 月，AI 领域知名研究者 Andrej Karpathy 发布了 autoresearch 项目，短短几天内就在 GitHub 收获 5 万+ 星标，Karpathy 发布的介绍视频播放量达 860 万次。这是一款开源 Python 工具，代码量约 600 行。

核心思想是：把 AI 研究本身也交给 AI 来自主完成。

具体做法极简而优雅：给 AI Agent 一个真实的小型 LLM 训练环境（单 GPU，5 分钟训练预算），让它自主修改 train.py、跑实验、检查结果——只有 val loss（验证集损失）改善时才 commit，否则 git revert 回滚，然后继续下一轮。人类只需维护一份 program.md（相当于给 Agent 的「研究章程」），剩下的全部交给 Agent 晚上自己跑。

这个项目的精髓在于三点：① 量化目标（val loss 是唯一判断标准）、② 自主循环（Agent 不需要人类每轮介入）、③ 只保留改进（退化就回滚，绝不将就）。预计每小时可完成约 12 次实验，一觉醒来就能收获上百轮自动优化的结果。

Andrej Karpathy的这套思路在 ML 研究领域验证有效后，我开始思考：软件开发领域能否复刻同样的魔法？ 把"修改 train.py → 跑 5 分钟实验 → val loss 改善才保留"，替换成"实现 GitHub Issue → 跑测试 → 多维评分达标才合并"——这就是本项目的起点。实测下来，10 分钟完成一个中等复杂 Issue，全程零人工干预，最终评分 9.0/10。

Issue#21自动化实现的回放地址： 

https://asciinema.org/a/896260

这个回放解决的Issue#21: 

https://github.com/smallnest/imclaw/issues/21

前几天正好看到花叔的写的一个SKill:达尔文.skill, 殊途同归—— 他在Skill开发 领域同样应用AutoResearch方法实现对Skill技能的优化。后来花叔把这个经验总结到他的另外一个Skill项目上：auto-optimize-skill。

3 为什么做这个?

传统的"人类写代码 → 运行测试 → 修复问题"流程，在 GitHub Issues 有几十上百个待处理项时不再可行。

即使用 Claude Code / Codex 等 AI 编程工具（所谓的 vibe coding），你仍然需要：

• 一轮一轮地 chat 交互，告诉 AI 做什么
• 人工检查输出、发现问题、再告诉 AI 改什么
• 生成的代码是一堆『屎山💩』
• 人始终被绑在循环里，离开就不转了

2025 年底流行的 Ralph Wiggum 方法（while true; do cat PROMPT.md | claude; done）更进一步：写好 SPEC，让单 Agent 在循环里自主干活。解决了人的 chat 交互问题，但本质是单个 Agent 的自我循环——自己写、自己测、自己改，没有外部审核视角，质量全靠测试 backpressure 和 prompt 工夫。

2026 年 3 月 Karpathy 发布了 autoresearch，把同样的循环思路用到了 ML 研究领域：写一个 program.md 定义目标和约束，AI 自主修改训练代码、跑 5 分钟快速实验，只有 val loss 改善时才 commit，否则 git revert。核心创新是把"什么是改进"量化成了一个明确的 metric。

本项目的 Autoresearch 在 Karpathy 思想基础上做了三个关键改进：

1. 多 Agent 交叉审核，替代单 Agent 自审。Ralph Wiggum 和 Karpathy AutoResearch 都是单 Agent 自己改自己评，缺少外部视角。本项目让 Codex 和 Claude 轮流担任实现者和审核者：A 写完 B 审，B 写完 A 审。不同模型有不同的盲区和强项，交叉审核能发现单 Agent 发现不了的问题。实践证明，单 Agent 的效果远不如双 Agent 交叉审核。本项目创造性地使用两个 Agent 轮流审核和开发，极大地提高了代码质量。

2. 5 维度加权评分，替代单一 metric。 Karpathy 用 val loss 一个数字判断好坏，ML 场景足够用。但软件工程的质量是多维的——功能正确、测试充分、代码规范、安全无漏洞、性能没坑。本项目用 5 维度加权评分（正确性 35% + 测试 25% + 代码质量 20% + 安全 10% + 性能 10%），总分 ≥ 9.0 才算通过，把"代码好不好"从主观判断变成量化指标。

3. 审核反馈驱动下一轮实现，替代盲循环。 Ralph Wiggum 的每轮循环是独立的——新上下文重新开始，不记得上轮犯了什么错。本项目的审核反馈直接传入下一轮 Agent 的提示词，Agent 看到上一轮的具体问题后针对性改进，而不是漫无目的地重试。

最终效果：人只提供 Issue 号，剩下的全自动——自动实现、自动测试、自动审核、自动迭代、评分达标后自动 PR + 合并。

与同类项目对比

本节对比三个将"自主迭代循环"思想应用到不同领域的项目：Karpathy 的 AutoResearch 用于 ML 研究，本项目用于通用软件开发，达尔文.skill 用于 Skill 优化。三者核心机制相同——量化目标 + 自动迭代 + 只保留改进——但在被优化的资产、质量保证机制、人的参与程度等方面做出了不同选择。

从对比可以看出：

• 量化目标是共通的核心。三个项目都把"什么是改进"定义成了可量化的指标——val loss、审核评分、8 维总分——而不是依赖人的主观判断。
• 质量保证机制各有侧重。Karpathy 和达尔文.skill 用 git revert 做硬性保护（退化就回滚），本项目用多 Agent 交叉审核做软性保护（审核反馈驱动改进，并没有做回退机制，原因在于ClaudeCode/Codex自己足够智能决定回退还是改进上一轮的变动）。
• 人的参与程度反映了领域特征。ML 研究的 metric 足够客观，可以全自主；Skill 的好坏需要人的判断，所以每轮暂停确认；软件开发介于两者之间，大部分自动但保留关键节点介入能力。

4 系统架构

以下是这个项目的架构图：

4.1 六条核心原则

这六条原则是整个系统的设计基石。原则 01 定义了规则的来源和边界，原则 02-05 构成了多 Agent 对抗的质量保证链（谁来做、怎么评、怎么改进），原则 06 确保整个过程可追溯。它们相互配合：没有 program.md 的约束，Agent 会越权；没有多 Agent 对抗，单 Agent 自审会有盲区；没有量化门槛，质量判断就回到主观经验；没有反馈驱动，迭代就是盲循环；没有全量记录，出了问题无法回溯。

4.2 审核评分体系

审核评分是 AutoResearch 的量化核心——它把"这段代码好不好"从一个模糊的主观判断，变成一个 5 维度加权计算出的精确分数。这个分数决定了迭代是继续还是停止：≥ 9.0 自动提交 PR，< 9.0 审核反馈驱动下一轮改进。维度和权重的分配反映了软件工程的质量优先级：功能正确最重要（35%），测试其次（25%），代码质量（20%），安全和性能各占 10%。

总分 10 分，5 维度加权：

各维度得分：无问题 10 分 / 建议改进 9 分 / 一般问题 7 分 / 严重问题 4 分 / 致命问题 1 分

达标线：9.0/10

4.3 优化循环：4 个阶段

整个流程分为 4 个阶段。

1. Phase 1 做环境准备（一次性，几秒钟）。
2. Phase 2 是核心迭代循环——多 Agent 轮流审核和实现，测试验证，评分判定，这个阶段完全自主运行，不需要人介入。
3. Phase 3 在评分达标后自动触发，完成 commit + PR + 合并。
4. Phase 4 做结果归档，把迭代过程写入日志供回溯。其中 Phase 2 占了几乎全部时间，也是系统价值的核心所在。

Phase 1: 环境准备

迭代示例：

迭代 1: Codex 审核 → Codex 实现 → 测试 → Claude 审核(5.0) → Claude 实现

终止条件：在以下情况下，任务会终止**

4.4 核心文件

autoresearch/

4.5 Issue 选择策略

排除规则：以下 Issue 不处理：wontfix / duplicate / invalid / blocked / needs discussion / on hold / external，标题含 [WIP]`[DRAFT]，正文含 DO NOT IMPLEMENT`，已有 PR 关联。

优先级计算：

分数 = 基础权重(15) + 标签权重 + 类型权重 + 时间因子

• 标签权重：critical(100) > high(50) > medium(20) > low(10)
• 类型权重：bug(30) > feature(20) > refactor(10) > test(5) > docs(3)
• 时间因子：新 Issue +10 / 陈年 Issue +15 / 近期更新 +5

复杂度评估：**

4.6 program.md 要点

权限边界：**

Agent 可以:

代码规范（Go）：**

1. 遵循 Effective Go + Go Code Review Comments

测试规范：**

1. 所有新功能必须有单元测试

4.7 错误处理

退火重试： API 调用失败时使用指数退避 + 随机抖动（delay = 2^retry * base\_delay + random\_jitter，最大等待 60 秒，最多重试 10 次）。

连续失败保护： Agent 执行失败 → 连续失败计数 +1，连续失败 ≥ 3 次 → 停止运行，记录日志。

测试失败： 测试失败 → 反馈"测试失败" → 下一轮 Agent 针对性修复。

4.8 运行结果

results.tsv 格式：**

timestamp   issue_number  issue_title  status     iterations  tests_passed  score  branch_name

状态定义：**

5 快速开始

5.1 前置条件

因为需要自动化处理 GitHub 的 Issue，所以需要安装 GitHub CLI。

因为通过 acpx 操控 Claude Code 和 Codex，所以需要安装 acpx 工具。

因为本项目使用 Go 语言开发，所以需要安装 Go 环境。

# GitHub CLI (gh)

5.2 运行

调用run.sh脚本，直接输入issue号即可运行。

# 进入你要处理的 GitHub 项目目录

脚本会自动：检查环境 → 获取 Issue → 创建分支 → 轮流 Codex/Claude 实现+审核 → 达标后自动 PR + 合并。

5.3 自定义配置

在项目根目录创建 .autoresearch/ 目录可覆盖默认配置：

.autoresearch/

6 实战案例

以下是我实际开发真实案例，特别的是 Issue #21, 我专门使用 asciinema 工具记录了这个issue自动开发的全过程。

Issue #21: feat: enhance job execution with agent selection and timeout

我只需提供一个Issue号，剩下的就由 autoresearch 脚本自动完成。

./docs/autoresearch/run.sh 21

默认设置最多执行 42 轮迭代，但通常几轮之后代码质量便能达到标准。下面是 Issue #21 的迭代过程，大约 10 分钟就完成了开发，总共迭代了 3 轮。

你可以点击这个回放链接 查看完整过程:

（回放链接：

https://asciinema.org/a/896260）

关键日志：

复杂度：中等（涉及 Job 结构体扩展、超时控制、API 增强）

Issue #15: feat: define source-of-truth event protocol

实现 Issue #15 时，仅迭代两轮代码质量便达到了标准，关键日志如下：

迭代 1 (Codex):  评分 5.0  → 反馈：设计方向问题

Issue #6: feat: add web UI for sessions

实现 Issue #6 的时候关键日志，就迭代了5轮代码质量就达到了标准：

复杂度：高（涉及多个模块、需要设计决策）

7 最佳实践

1. 从小 Issue 开始：先用简单的 Issue (bug fix) 测试流程
2. 保持 program.md 更新：根据运行情况调整规则和约束。一旦你在使用中觉得效果不够理想，比如评分机制不符合预期，就可以修改这个文件。
3. 关注评分趋势：每次迭代的评分记录在 log.md 中，观察是否稳步上升
4. 利用多 Agent 对抗：Codex/Claude 轮流实现+审核，交叉验证减少盲区
5. 退火重试：API 不稳定时脚本自动退避重试，无需人工干预

8 设计灵感

• karpathy/autoresearch — 核心循环：只保留可测量的改进，其余全部回滚
• acpx — Agent 控制工具，让 Codex/Claude 在命令行中协作
• imclaw — 本项目和autoresearch文件https://github.com/smallnest/imclaw

作者：文静

本次更新聚焦EMR 组件能力升级与管理平台能力增强两大方向，带来核心组件版本迭代、湖仓一体支持、集群扩缩容、安全一键开启等多项能力升级。

一、EMR 组件能力

1.1 核心组件版本迭代

平台完成核心组件的版本兼容性验证与适配工作，确保新版本组件在平台上稳定运行，并提供平滑升级能力：

1.2 湖仓一体支持

湖仓一体已成为企业级大数据平台的标准架构，新增对三大主流湖仓框架的原生支持：

典型应用场景：

·实时数据入湖：Flink CDC 捕获 MySQL、Oracle 等数据库变更数据，写入 Iceberg 或 Hudi 表。Hudi 支持增量拉取，下游任务仅消费变更数据，大幅降低计算资源消耗。

·批流融合分析：Paimon 作为统一存储底座，上层 Flink 任务同时承担实时流计算与离线批处理，实现真正的批流一体架构。

1.3 OLAP 引擎支持

新增三大 OLAP 引擎支持，满足多样化数据分析需求：

典型应用场景：

·实时 BI 分析：StarRocks/Doris 支撑高并发点查需求，单节点可达千级 QPS，支撑营销大屏、实时监控等场景，报表延迟从 T+1 缩短至秒级。

·跨源联邦查询：Trino 同时查询 Hive 数据湖历史数据、MinIO 对象存储日志文件、MySQL 业务数据，无需数据搬迁即可完成跨源关联分析。

1.4 对象存储

新增MinIO对象存储作为轻量级 S3 兼容对象存储，通过 EasyManager 平台对MinIO 组件进行部署和增减实例，简化 MinIO 部署和运维。

二、平台管理能力

2.1 集群扩缩容

2.1.1 全组件扩缩容以及退服机制

支持 HDFS、YARN、HBase、Flink、Spark、Hive、ZK 等核心组件的全面白屏化扩缩容，实例增减通过图形界面完成，替代传统服务器登录与命令行操作模式，降低操作门槛与人为风险。

针对 HDFS、YARN、HBase 缩容场景，新增退服前检查与资源迁移流程，保障业务连续性：

节点资源评估，确保接收节点具备冗余容量；

运行任务调度，作业自动迁移至健康节点，业务无感知；

数据块均衡，副本数策略校验，保障数据可靠性；

服务平滑下线，按组件依赖顺序依次停止；

2.2 运维提效

2.2.1 集群一键启停

支持集群级别一键重启、停止、启动，内置组件依赖关系引擎，自动按序执行；支持滚动重启策略，运行作业自动调度至健康节点，保障业务持续可用。

2.2.2 配置变更记录与回滚

一键回滚，支持查看不同实例组下的不同配置修改记录，同时在任意配置节点回滚到上一次配置，便于配置修改追溯与维护。

2.3 安全加固

2.3.1 Kerberos 一键开启

平台支持一键开启 Kerberos 认证，自动化完成全链路安全改造，包括服务识别、Keytab 生成、组件配置同步。

2.3.2 Ranger 集成初始化

支持 Ranger 集成后一键初始化，自动完成账号创建、服务插件注册、权限策略预配置，实现 Hive、HDFS、Kafka 等组件的统一权限管控，替代组件分散授权模式。

2.4 资源治理

Yarn 资源队列绑定

在多租户大数据环境中，资源争抢与分配不均一直是核心挑战。本次新增资源队列绑定用户能力，实现队列仅对授权用户开放，通过设置用户或用户组的资源限制，防止个别用户占用过多集群资源，避免资源垄断，提高集群整体利用率。

资源队列计划模式

本次新增资源队列计划模式，支持多级队列容量规划与动态调整，适配业务峰谷场景。主要通过为每个队列配置最小保证资源和最大资源上限，然后配置不同时段的资源分配策略，例如工作日与周末、白天与夜间的差异化资源配比，适配业务峰谷特征。作业提交时自动校验目标队列剩余容量，队列满载时可拒绝作业或自动路由至备用队列，保障关键业务资源。

2.5 数据保护

HDFS 快照管理

支持关键目录创建快照，对误删的数据可快速恢复，为数据安全提供即时、可靠、低成本的恢复机制。

2.6 资产管理

2.6.1 Hive/HBase 表统计

自动扫描元数据，生成表数量、存储空间、访问频率等多维度统计报表，识别冷数据与异常资产，为存储成本优化与数据治理提供数据支撑。

2.7 监控告警升级

平台对监控告警能力进行系统性升级，新增告警历史查看与问题复盘能力；优化告警规则配置，深度集成夜莺告警系统，实现告警统一聚合与分级管理。告警全生命周期管理能力，帮助运维团队从被动响应转向主动防御。

能力全景图

以 EMR 基础平台为核心运维保障，通过 Kafka、FlinkX 等流批一体能力实现全量数据的实时采集，依托 Trino、Doris 等引擎提供高性能数据分析；在底层存储上，融合了 Hudi、Paimon 等湖仓技术与 MinIO 对象存储，构建结构化与非结构化数据多模态 AI 存储，确保数据安全合规的前提下，从应用场景出发，全方位支撑起从原始异构数据源到高价值数据服务的业务全链路。