2026年1月

Smart-HR 智能招聘与面试助手

项目适合人群

  • Spring AI 的基本使用
  • Milvus 向量知识库的集成实践
  • Neo4j 作为知识图谱的建模与查询
  • 适配器模式实现多模型切换(OpenAI/百炼/等)
  • Docker Compose 一键启动前后端与依赖

项目源代码地址

Github地址
建议直接打开源代码 对照学习每一个部分

https://github.com/LQF-dev/smart-hr

1. 项目简介 🚀

  • 面向 HR 与面试官的智能招聘助手,覆盖简历解析、岗位匹配、面试题生成与模型切换。
  • 引入 Neo4j 知识图谱(预置约 200 个技能节点及依赖关系)作为 HR 匹配的图谱评判依据;
  • 引入 Milvus 向量数据库 作为 RAG 知识库,分为“企业特定金融知识”与“通用知识”两部分,支撑面试官题库生成与语义检索。
  • 采用 模型适配器模式,可插拔接入多种大模型(当前支持阿里云百炼、OpenAI);新增模型只需实现 Adapter 并注册到 ModelRouter。
  • 后端基于 Spring Boot + Spring AI,整合 Milvus/Neo4j/PostgreSQL;前端基于 React + Ant Design。

2. 技术栈与架构 🧰

  • 前端:React 18、TypeScript、Vite、Ant Design、Zustand。
  • 后端:Spring Boot 3、Spring Security + JWT、Spring AI。
  • 数据与存储:PostgreSQL、Neo4j、Milvus。
  • 运维:Docker / Docker Compose。

3. 系统架构图 🧭

HR 流程:简历/岗位 → Neo4j 知识图谱 → 混合打分(图谱评分 + LLM 评估)

面试官流程:岗位/技能 → RAG(Milvus 题库/技能向量)→ LLM

HR 通过 Neo4j 图谱进行技能匹配后送入 LLM;面试官流程以 Milvus RAG 检索题库/技能语义,再送入 LLM。

4. 功能特性 🎯

HR 🤝

  • 岗位管理:岗位创建/编辑/删除,岗位列表。
  • 简历处理:上传简历、技能提取、查看简历详情。
  • 匹配分析:岗位 ⇄ 简历互相匹配,支持混合打分报告,匹配历史/详情查看。
  • 记录管理:匹配结果列表、历史查询。
    image-20260127174532526
    image-20260127174638611

面试官 🎤

  • 题目生成:按岗位或技能生成面试题,可选难度与题量。
  • 记录管理:生成历史查看、记录删除。
    image-20260127174807667
    image-20260127174824125
    image-20260127174851037

通用 🧩

  • 认证:登录/注册(JWT),当前用户信息。
  • 模型:AI 模型列表与切换(阿里云百炼 / OpenAI,适配器模式)。
  • API:Swagger UI。
    image-20260127174423668

5. 目录结构

  • back/:Spring Boot 后端。
  • front/:React 前端。
  • docker/:基础设施与一键部署的 Compose 文件、初始化脚本。

6. 环境准备

  • JDK 21、Maven 3.8+。
  • Node.js 18+(含 npm)。
  • Docker Desktop(含 Docker Compose)。

7. 快速开始 ⚡

详细步骤请参见 Github 代码仓库下的 DEV_GUIDE.md。 这里仅仅列出基本使用
  1. 启动基础设施(本地开发)
cd docker
docker-compose -f docker-compose.dev.yml up -d
12
  1. 初始化 Neo4j 知识图谱
  • 浏览器执行 docker/neo4j/init.cypherdocker/neo4j/init-skills-extended.cypher,或使用 cypher-shell(详见 DEV\_GUIDE)。
  1. 配置大模型 API Key(至少需阿里云百炼,OpenAI 可选)
export DASHSCOPE_API_KEY=你的阿里云百炼API_KEY
export OPENAI_API_KEY=你的OpenAI_API_KEY   
12
  1. 启动后端(本地开发)
cd back
./mvnw spring-boot:run
12
  1. 启动前端(本地开发)
cd front
npm install
npm run dev
123
  1. 全栈 Docker 一键启动(可选)
cd docker
export DASHSCOPE_API_KEY=你的阿里云百炼API_KEY
export OPENAI_API_KEY=你的OpenAI_API_KEY   
docker-compose up -d
1234
  • Swagger API 文档:http://localhost:8080/swagger-ui.html
  • 默认端口:后端 8080,前端 5173(开发)/ 3000(容器),Postgres 15432(dev)/5432(prod compose),Neo4j 7474/7687,Milvus 19530/9091。

(更多启动、调试与排障说明,请查看 DEV_GUIDE.md

8. 开发指南:扩展新的大模型 🛠️

  1. 引入 SDK 依赖:在 back/pom.xml 添加对应模型的官方 SDK 或 HTTP 客户端依赖,并配置密钥环境变量。
  2. 实现适配器:参考 AliyunAdapter,实现 AIModelAdapter 接口,封装 chat / embedding 调用和模型 ID。
  3. 注册模型:在模型注册/路由处(如 ModelRegistryModelRouter)将新 Adapter 注册并开放配置。
  4. 配置密钥:在 application.yml 或环境变量中新增该模型的 API Key/Endpoint。
  5. 前端暴露:如需在前端选择模型,补充模型枚举/下拉项即可,无需改后端协议。

今天,数式Oinone发布 Oinone7 早鸟体验版。作为面向企业级数字化交付场景的关键版本,本次迭代在夯实技术底座、打通协作链路、优化交互体验的同时,将AI Native能力深度融入日常使用,核心目标是帮助企业在数字化进程中少踩坑、少返工,把时间和精力真正花在创造业务价值上。

Oinone7不仅实现JDK 17的完整适配,带来启动速度提升30%的显著优化,也将其确立为后续版本迭代的基础版,一方面适配伙伴出海需求,另一方面支撑AI Native的深度融合落地。

在产品设计上,Oinone7始终聚焦企业真实需求:以JDK 17底层支撑强化系统稳定性,借工作流流程优化打通团队协作衔接堵点,靠交互体验升级降低工具使用门槛。这三大升级方向协同发力,切实帮助企业突破“系统运行波动、协作效率低下、工具上手复杂”的数字化瓶颈,让整体交付过程更可控、更顺畅。

Oinone 7核心能力升级

Oinone7的核心升级围绕企业实际使用需求展开,从技术支撑到协作、操作体验,每一处调整都聚焦“解决问题、创造价值”,让企业在数字化交付中少走弯路。

  1. 稳定技术底座,降低企业长期成本

凭借对JDK 17的全面适配,且将其作为后续版本迭代的基础版本,Oinone7为企业提供更扎实的使用保障:

● 在系统性能上:

Oinone7运行更稳定,即便是处理复杂业务场景,也很少出现卡顿或中断情况,能确保交付工作按计划推进;

● 在依赖衔接上:

Oinone7同步将基础依赖升级至Spring Boot 3.3.x、Dubbo 3.2.x,与JDK 17技术基线深度适配,企业现有系统与Oinone7的新功能搭配使用时,无需担心兼容性问题,无需额外处理版本适配相关事务;

● 在智能能力接入上:

Oinone7整合Spring AI,企业无需构建复杂的智能基础设施,就能轻松用上智能能力,快速跟上AI应用的发展趋势。

  1. 优化工作流衔接,让协作更顺畅

针对企业团队协作中的常见堵点,Oinone7对工作流进行针对性升级:

● 面对人员调整:

审批流程自动衔接新负责人,已完成的审批记录完整保留,不用人工重新梳理或补录,避免审批断层;

● 新增流程运行状态视图:

异常、超时情况直观呈现,从流程到具体实例的问题定位更快速,不用在海量数据中逐一排查;

● 同时强化审计合规能力:

协作过程中的关键操作全程留痕,符合企业对内管理、对外合规的双重需求。

  1. 升级交互体验,降低工具使用门槛

从“好用、易用”出发,Oinone7让工具操作更贴近用户习惯:

● 表格、表单等常用视图预设优化:

开箱就能直接用于业务场景,减少初始搭建的时间成本;

● 分散的功能开关整合为清晰选项:

不同团队成员对操作的理解更统一,不用反复沟通确认;

● 图表操作面板实现刷新、导出、数据联动一体化:

业务人员分析数据时不用切换多个界面,处理效率显著提升。

  1. AI Native深度融合,从研发工具到智能决策

Oinone7打破“AI落地难、复用性低”的行业痛点,以AI Native能力将工具平台升级为企业的智能化引擎。基于Oinone元数据为基础的AI Native能力、整合其他智能升级能力,让AI真正融入业务:

● 在模型管理上:

支持多厂商大模型接入与管理,企业可按需选择适配业务的模型;

● 在模型训练上:

提供通用的从数据集自动采集、标注,到模型微调,再到AI员工/智能决策助手开发全生命周期能力;

● 整体体验上:

带来全新的企业级应用交互体验,智能助手不仅懂系统、懂业务、更会操作。

Oinone7不仅完成JDK17的全面适配,带来启动速度提升30%的显著优化,且同步将基础依赖更新至Spring Boot 3.3.x、Dubbo 3.2.x,也将其确立为后续所有版本迭代的基础版,一方面适配伙伴出海需求,保障复杂场景下系统稳定运行;另一方面支撑AI Native的深度融合落地,通过整合Spring AI帮企业省去搭建独立系统的成本,同时实现现有系统与新功能的无缝衔接。

关于Oinone7的详细升级说明、适配要点及操作指南,可以通过技术文档中获取:

https://doc.oinone.top/version/25243.html

AI写代码
帮助企业快速掌握升级要点,平稳完成版本过渡。

这不仅是一版升级,更是数式Oinone“企业级产品化引擎:用低代码驱动标准化研发与敏捷交付的一体化平台”的持续兑现——以稳定的JDK 17基线、可感知的协作与交互优化,以及可落地的AI Native能力,帮助软件公司与ISV把产品做得更标准、交付更敏捷、成本更可控。

OceanBase 社区嘉年华上午 Keynote

全程高能! 活动流程如下 👇

主题分享之外,AI 技术圆桌巅峰对话来袭

解锁技术前沿实践与思考!

下午属于 AI Coding 专场,issue 已公开,Everything is ready to go. Have fun!

复制下方链接到浏览器查看
https://github.com/oceanbase/seekdb/issues/123

Mentor 已就位,现场除了能 Prompt AI,还可以向他们请教哦~

与此同时,超有料的社区开放麦等你来打卡!

心动不如行动!点击 https://ask.oceanbase.com/t/topic/35638331 ,解锁 OceanBase 社区嘉年华当日路线图、交通指南及全套实用攻略!1 月 31 日,上海,我们不见不散~

阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么

合并单元格是指将两个或多个独立的单元格合并为一个较大的单元格,常用于需要创建跨多列显示的标题或标签。本文将演示如何使用 Spire.XLS for .NET 库,通过 C# 和 VB.NET 在 Excel 中实现单元格的合并与取消合并操作。

安装 Spire.XLS for .NET

首先,需要在你的 .NET 项目中添加 Spire.XLS for .NET 包中包含的 DLL 文件作为引用。你可以通过官网下载 DLL 文件手动添加,也可以直接通过 NuGet 安装该库。

PM> Install-Package Spire.XLS

使用 C# 和 VB.NET 合并 Excel 单元格

以下是通过代码在 Excel 中合并单元格的基本步骤:

  1. 创建一个 Workbook 实例。
  2. 使用 Workbook.LoadFromFile() 方法加载 Excel 文件。
  3. 通过 Workbook.Worksheets[sheetIndex] 获取需要操作的工作表。
  4. 访问指定的单元格区域,并调用 XlsRange.Merge() 方法将其合并为一个单元格。
  5. 将合并后单元格中的文本水平居中,可将 CellRange.Style.HorizontalAlignment 属性设置为 HorizontalAlignType.Center。
  6. 最后,使用 Workbook.SaveToFile() 方法保存生成的结果文件。

示例代码如下:

using Spire.Xls;

namespace MergeCells
{
    class Program
    {
        static void Main(string[] args)
        {
            // 创建一个 Workbook 实例
            Workbook workbook = new Workbook();
            // 加载 Excel 文件
            workbook.LoadFromFile("Sample.xlsx");

            // 获取第一个工作表
            Worksheet sheet = workbook.Worksheets[0];
            // 将单元格 A1–D1 合并为一个单元格
            CellRange range = sheet.Range["A1:D1"];
            range.Merge();
            // 将合并后的单元格内容设置为水平居中
            range.Style.HorizontalAlignment = HorizontalAlignType.Center;            

            // 保存结果文件
            workbook.SaveToFile("MergeCells.xlsx", ExcelVersion.Version2013);
        }
    }
}

在 C# 和 VB.NET 中取消合并 Excel 单元格

下面是取消合并 Excel 单元格的具体操作步骤:

  1. 创建一个 Workbook 对象。
  2. 使用 Workbook.LoadFromFile() 方法加载 Excel 文件。
  3. 通过 Workbook.Worksheets[sheetIndex] 获取需要操作的工作表。
  4. 访问指定的单元格区域,并调用 XlsRange.UnMerge() 方法取消单元格合并。
  5. 使用 Workbook.SaveToFile() 方法保存结果文件。

示例代码如下:

using Spire.Xls;

namespace UnmergeCells
{
    class Program
    {
        static void Main(string[] args)
        {
            // 创建一个 Workbook 实例
            Workbook workbook = new Workbook();
            // 加载 Excel 文件
            workbook.LoadFromFile("MergeCells.xlsx");

            // 获取第一个工作表
            Worksheet sheet = workbook.Worksheets[0];
            // 取消合并单元格 A1–D1
            CellRange range = sheet.Range["A1:D1"];
            range.UnMerge();

            // 保存结果文件
            workbook.SaveToFile("UnMergeCells.xlsx", ExcelVersion.Version2013);
        }
    }
}

申请临时许可证

如果您希望去除生成文档中的评估提示,或解除功能限制,请为自己申请一个有效期为 30 天的试用许可证。

前期准备

注册域名选择域名:优先选择.com 域名,其次可考虑.co 或.net。域名应简洁易记,最好包含品牌名或核心关键词,避免使用连字符和数字(除非是品牌的一部分)。

注册域名:推荐使用 Namecheap、NameSilo 等国际知名域名注册商,它们性价比高且提供免费隐私保护。在注册商网站搜索心仪的域名,加入购物车并完成支付。

选择主机主机选择:外贸独立站的访问者可能来自全球各地,因此选择支持全球访问的主机服务商非常重要。建议选择:

CDN 加速:推荐使用 Cloudflare(免费计划足够起步),它可以将网站的静态文件缓存到全球各地的边缘服务器,大幅提升全球访问速度。

安装 SSL 证书:SSL 证书可以保障网站数据传输的安全,大多数主机商都提供免费的 SSL 证书安装服务,确保网站以 HTTPS 协议运行。

1、主机控制面板宝塔安装 WordPress 程序

使用宝塔的用户越来越多,使用 VPS 的朋友,宝塔几乎成了标配,下面简站 WordPress 为大家写一个用宝塔搭建 WordPress 网站详细教程,以图文的形式一步一步按步骤讲明白搭建过程。

1、第一步:添加网站

c95ef9a5dda2cffa67c7dced26cf6807.png

登陆宝塔后台,找到“网站”,点击进入后,点“添加站点”,输入域名后,选择创建“FTP”和“数据库“,点”确定“网站就创建成功了。(”数据库“必须得创建,”FTP“可创建,也可以不创建。另外,如果是安装了多个版本的 PHP,可以选择 PHP 的版本。WordPress 目前的最新版是 6.5,建议使用 8.0 版本的 PHP。)

1ba76978aefe63d4e1dd7fdddae875df.png

网站添加成功后,需要对网站进行,基础的设置,比如,伪静态设置,如上图所示。

点“伪静态”,在出来的选项中选择“wordpress”

9cfbde8b5cf7a67249b5a8eb64104cdd.png

出现如所所求代码时,“保存”即可成功设置伪静态。

3fcaf8e5d1eec33c2d4c95fd9968193d.png

SSL 证书添加,将该域名的 SSL 证书相应的代码,复制到密钥(KEY)和证书(PEM 格式)中,“保存并启用证书”即可成功安装 SSL 证书。

1a11028cd3e544598039467d2e908f6e.png

SSL 安装成功后,可以查看到对应的域名信息和到期日期。

2、第二步:上传 WordPress 程序

到 WordPress 官方,下载最新版的 WordPress 程序:

https://cn.wordpress.org/download/

注意官方的环境要求:官方推荐 PHP 7.4+ 以及 MySQL 版本 8.0+ 或 MariaDB 版本 10.4+。建议 PHP 版使用 php8.0。

b592c6e1754a4c472bad9dd03dbaaa44.png

下载完成后在宝塔面板中找到“文件”,选择“wodepress.com“文件夹,打开文件夹后,将下载好的 WordPress 程序上传到该目录。

21e6419accec2891999a8a03f688b913.png

上传成功后

c7bffa987fc6f9b0180e58826b9c3166.png

“解压”该文件

765e3e08b8a633cc08542cb84f19c637-yVCa.png

解压后的文件在“wordpress”文件夹中,将该文件夹中的全部文件复制到网站根目录中

3aa993cd646fdaa44d799a819cb9d775.png

从根目录中删除 wordpress 文件夹和 WordPress 程序文件包.zip 文件

3、第三步:安装 WordPress

989023d617a0df9faee2ed006fcdbce0.png

输入网站域名 www.wodepress.com 会出现如图所显的安装界面

点“现在就开始安装”

eedc0e87c224586c5bc976686d8dcefd.png

在出现的界面里录入相应的数据库信息“数据库名”、“数据库用户名”、“数据库密码”,并“提交”。

b6da0c9223fe48d908427b2bf358cad3.png

按提示操作即可,点“运行安装程序”

89898ab8139915dac00fa52c8961da20.png

录入网站的标题、管理员用户名、密码和邮箱后点“安装 WordPress”即可。

eccb3ab5607f073d39f67017dfcc3867.png

至此在宝塔搭建 WordPress 网站的步骤全部完成

接下来就是输入自己的域名/wp-admin,登陆到网站的后台,进行 WordPress 网站的其它设置。

先安装好 WordPress 程序,确认 WordPress 程序可以正常运行。

2、安装 WordPress 主题

2.1、导入数据

2.1.1、先删除原数据表

fc31110af9ee87971bb41e74527607ae.png

在宝塔后台找到“数据库”,点击进入后,再找到自己网站对应的数据库点“管理”

4132026e77e8f013f66643385ffb797f.png

选择进入数据库,此处注意,一定要选择数据库,进入后才能看到数据表。

6b8a1304d0e1fccfcb15f6a675d99e2b.png

“全选”数据表,“选中项”、“删除”,即可删除全部的数据表,删除完成后数据库内没有任何数据表。

9f8e957250f2bc2ce7691e429fc318d5.png

这个时候再输入域名访问网站时,是 WordPress 初始化的安装状态,这里不用安装,也不用管,跳过就可以。

2.1.2、导入演示站数据

967a56c376bf5be3eb4fb8365aca4ad0.png

ecb04c331acccfe0b396dd23da9b9874.png

找到“导入”,“选择文件”将邮件中的.sql 格式的数据库文件选择后,再点击“导入”即可完成演示数据的导入。

2.1.3、修改域名和邮箱

5eafbf5e4030123e94536c98563b5055.png

数据导入成功后找到 wp_options 表

将两个的链接改为自己的域名 www.wodepress.com(使用了 SSL 用 https,没使用 SSL 用 http)。

将邮箱处改为自己的邮箱

0593879ee347808b9d9735eec2bf9d45.png

再找到 wp_users 表

将此处的邮箱改为自己的

2.2、上传并解压主题文件

d529f1f0d9ff6c1905032491b7670aa9.png

在宝塔后台找到“文件”,进入到自己网站的目录 wodepress.com,再进入到 wp-content 目录,再进入 themes 目录。将邮件中的.zip 格式的主题文件上传到 themes 这个文件夹中,并解压。

2.3、上传并解压插件文件

c1742fef102cdc3d554f1211b438d7d1.png

在宝塔后台找到“文件”,进入到自己网站的目录 wodepress.com,再进入到 wp-content 目录,再进入 plugins 目录。将邮件中的插件文件上传到 plugins 目录中并解压。

提示:此主题使用到的插件为 contact-form-7,只需要上传这个插件就可以。其它主题如果使用了其它的插件,操作方法是一样的,将主题使用到的所有插件都上传到 plugins 目录并解压。

到此 WordPress 主题安装完成

3、设置主题

3.1、登录后台

www.wodepress.com/wp-admin

默认帐号 admin 123456

885c9ab37790fa261a434e769b5be486.png

登录成功后第一件事,修改初始密码。重点提示:这个一定要改,非常重要。

3.2、启用主题

在后台“外观”-“主题”中启用主题

3.3、重置主题选项

157188070652b9c7e5b4d255d7ae4051.png

在后台“外观”-“主题选项”中,点击“重置”,成功重置主题后,再点“保存”。

3.4、设置菜单

f9ab431c7de4833844ace383b2ef169f.png

在后台“外观”-“菜单”中可以看到有 4 个菜单,如果需要对各菜单里的项目进行修改,选择相应的菜单编辑,编辑完成保存即可。

60174d59e00e89cf5978423abddcf3ae.png

比如,要编辑 header(顶部导入)中的 home 的链接,就选择这个菜单并点“选择”,然后再点“home”后面的三角图标,对出来的链接进行修改就可以。

a6f71bf937d581696e42f7929380c209.png

另外提示,4 个菜单与在最底部的 4 个位置相互对应,如果某个位置的菜单没有显示出来,可能就是没有选择这里的位置。

3.5、首页各模块及基础设置

653d6c5d407924d0b98a247940fa1c7f.png

主题后台采用主题选项来管理,在“基础设置”里可以设置 logo、联系方式、地图等;首页的各模块也有相应的位置可以设置。比如,首页大图、关于我们在主题选项里有对应的位置可以设置。提示:设置完了,一定要点最下面的“保存”。

每个主题的后台不完全一样,设置方法也不完全相同。以上设置方法是以 WordPress 主题为例,其它主机面板下、其它主题的方法也类似,基本上是大同小异,可以以这个作为参考来设置。

Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

文章代表作者个人观点,少数派仅对标题和排版略作修改。


前言

胶囊胃镜和无痛胃镜到底有什么不同?去年因为身体原因,加上对无痛胃镜的恐惧,我选择了胶囊胃镜。今天和大家讲一下具体流程以及我的个人感受。

先说为什么会选择价格较高的胶囊胃镜,主要还是因为害怕,心理上始终无法接受传统胃镜。

先简单解释一下胶囊胃镜的原理,前期准备和普通胃镜基本一致,只是检查时不需要插管,而是吞下一颗带摄像头的胶囊。胶囊会顺着食道进入胃部,在胃里拍摄一圈,将内部情况完整记录下来,随后通过消化道自然排出体外。

整个过程中基本没有不适感,只是吞服胶囊后按照医生要求变换体位,医生会实时查看拍摄画面,直到检查结束即可。

时间:2024年3月15日

地点:深圳市南山区深圳大学总医院

两种胃镜方式到底有什么区别?

无痛胃镜

无痛胃镜通常会与肠镜一起进行检查,这样覆盖范围更全面,有助于更准确地查找病因,也能在一次麻醉中同时完成两项检查。

从操作方式上看,无痛胃镜与早期传统胃镜并没有本质区别,只是增加了全身麻醉环节。麻醉后人处于无意识状态,医生会从口腔插入胃镜进入胃部进行检查,同时肠镜则从肛门进入肠道完成检查。

优点:检查全面、有胃息肉可以直接拿掉、进行活检

缺点:麻药对于人脑有一定伤害、插管对于嗓子、屁股会有一定影响。心理阻碍大。

胶囊胃镜

胶囊胃镜的检查方式是吞下一颗内置摄像头的胶囊,然后躺在床上由医生操控设备。胶囊会在胃内旋转拍摄,记录胃部内部情况。完成胃部检查后,患者需要穿上一件带有接收装置的马甲,胶囊继续进入肠道进行录像,所有影像都会被设备同步记录下来。第二天胶囊会通过正常排便排出体外。

它的主要缺点在于只能进行观察,无法像传统胃镜或肠镜那样取活检或切除息肉。同时,对肠道的覆盖也不如肠镜全面,尤其是对大肠的检查效果有限。一般来说,多数肠道疾病集中在大肠,小肠病变的发生率较低;如果小肠出现明显问题,通常意味着病情较为严重。

优点:不用插管、不用喝麻药、心理阻碍小、不会对食道等造成损伤。

缺点:大肠位置检查不全面、发现息肉无法取出、价格昂贵。

我到底应该怎么去做胶囊胃镜呢?

接下来我会讲一下从挂号、预约检查,到完成胶囊胃镜以及最终领取检查结果的整个流程。

消耗时间:消耗时间2周,实际时间2天。

费用:4200元RMB

医院:深圳大学总医院

科室:胃肠内科、体检科

挂号

首先我选择的是深圳大学总医院,因为胶囊胃镜在很多医院尚未普及,费用较高、接受的人也相对较少。即使在深圳这样的城市,也只有少数三甲医院能够开展这项检查,建议提前通过电话或线上渠道咨询确认。

我本人在深圳,提前在网上查询并电话确认深圳大学总医院可以进行胶囊胃镜检查后,通过医院小程序挂了胃肠科门诊的号。主治医师、副主任医师或主任医师都可以选择,选好日期并完成挂号即可。

医院签到

问诊当天来到医院后,我先去医院先去一楼自助缴费机器缴费(网上挂号我没缴费,看医院情况)。缴费完成后直接去科室所在楼层,去签到机器签到等待叫号即可。

问诊开检查

轮到我叫号后进入诊室,直接向医生说明了我的不适部位和具体症状,并提出希望进行胶囊胃镜检查。医生在了解情况后,会讲解胶囊胃镜与常规胃镜的区别以及相关注意事项。

由于这项技术尚未全面普及,在深圳大学总医院是归体检科负责操作,医生需要在系统中进行对应项目的开单。检查单开好后,前往一楼完成缴费。

缴费后携带相关药品前往体检科,由体检科医生负责具体检查流程。检查结束并拿到结果后,再回到主治医生处进行解读和后续处理即可。

体检科医生沟通

过程中还出现了一个小插曲。我先将检查单拿给体检科医生确认,对方建议更换其中一种用药,于是又返回主治医生处重新调整检查用药方案。具体药品名称我并不熟悉,都会清楚标注在检查单上,可自行查看。

确认所有所需药品和检查项目无误后,再次前往楼下缴费并领取药品。

缴纳费用

我看了一下价格是一共花费了4038元,这个就是整个胶囊胃镜的价钱,加上做胃镜需要喝的药等等。

因为我本人在深圳缴纳的是二档社保,这个胶囊胃镜需要一档社保才可以报销,我的全部都是自费,所以很贵。

缴费拿药

缴费完拿药后,因为胶囊胃镜需要提前一天清空肠胃、医院还需要提前安排人、安排时间、机器等。周日体检科这边还休息。

所以我做胶囊胃镜检查的时间就定在了下周六早上八点。医生在这个时候提前告知我注意事项。

  • 做检查前一天晚上七点后,不允许在吃东西
  • 七点后开始用热水冲服电解质散(图片中蓝白色盒子那个)一共需要喝4L水左右。
  • 前一天晚上喝3L左右,第二天早上四点起来再喝1L水。
  • 早上八点到医院体检科,拿着胶囊和剩下的药

一共两种喝的药和一个胶囊(分别为下方两张图),胶囊当时没有拍照,所以找了网图。胶囊大小比正常吃药的胶囊大许多,但喝水吞咽下去绝对没问题。

网图

正式开始胶囊胃镜检查

检查前准备

周五晚上七点之后我就停止进食,并提前在超市买了三瓶怡宝 1.5L 的水备用。

打开电解质散,里面是两大包的药粉、我需要把药粉用热水冲一下。我用了一个热水壶,烧开后把药粉撒在里面,倒在碗里喝。

这个药粉喝起来有一点微甜,但仔细品尝味道又有点咸,喝多了就味道感觉怪怪的。我在喝到第二碗的时候药效已经开始发作,我就开始上厕所。上厕所后我又回来继续喝,开始喝起来的感觉还好,但是后期喝起来越来越难喝,已经喝到快要吐了,喝到一瓶水之后,就已经开始「拉水」。肚子里已经没有任何东西了。终于在最后十点左右,我喝下了我所需的量。

这个时候我整个人已经有点虚弱,因为没有吃饭,加上上厕所次数过多,并且还有一点恶心,那个电解质喝多了真的恶心。

一夜辗转难眠,早上四点的闹钟把我早早叫了起来。我开始继续喝药。

但是这个药喝到后期真的喝不下去了,我查了一下主要是用来清空肠胃的。我现在肠胃里估计什么都没了。早上这个药量实在喝不下去了,我只喝了一半,我就打车去了医院。

正式开始检查

早上我早早来到了医院,等待医生。见到医生后我和她说明了我的情况,她说没有问题。

让我打开了另一包药,上图黄色小盒那个「二甲硅油散」让我喝了一个纸杯的水,喝下去后,过几分钟,带着我去了检查室,让我吃下了那个胶囊,那个胶囊很顺利的被我吃了下去,接下来就开始正式检查。

吃完胶囊后,我能清晰感觉到它在我的胃里,我躺在床上,医生那边的机器开始操控那个胶囊,我清晰的感觉到胶囊在我胃里边四处转动。这个期间大概持续20分钟,中途会让你继续喝一点药。来回变换几个姿势。

  • 平躺
  • 左侧躺
  • 右侧躺
  • 喝药三次左右,一次不多

全程大概持续了20多分钟,人就需要躺在床上即可,没有任何痛苦,没有任何不舒服,过程很快。

检查完之后,医生会大概告诉你胃部的情况,因为她操控机器那边可以清晰看到。这个时候你的胃部就算是检查完了。

检查完之后,会让你穿上一个机器马甲,穿上后,下午三点前/机器马甲没电之前不可以吃东西。

因为胶囊需要时间走完大肠小肠,这个马甲,是可以把胶囊走大肠小肠的过程录制下来,传到马甲里面。隔天早上再送回医院即可,大概结果下周就可以出来。马甲如下图所示。

穿在身上有点重量,但不耽误什么,就是下午之前不可以吃东西,真的饿的难受,还比较热。

网图
网图

检查完毕

我穿着马甲离开医院后就正常去玩即可,等待马甲没电后就可以吃东西了。大概三四天左右,我的结果就出来了,直接去线下取并拿着最终结果去找医生去诊断即可。

写在最后

这篇文章写在2026年。24年做的检查,时刻两年,可能现在的检查情况要比之前还要好一点。

如果在超一线城市,这种检查基本条件都有。但这个检查相对无痛胃镜来说贵很多,缺点也很明显,不是有很大心理障碍,一定要慎重考虑这个。

最后还是祝大家身体健康,希望医学对于这种检查可以有一个重大突破,特别是AI的到来,一定会让医学有一个更大进步。

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    作者:恰橙、席翁、濯光

    AgentScope 基于 A2A 协议与 Nacos Agent Registry,实现智能体的统一发现、治理与跨生态协作。

    随着企业逐步落地 AI 应用架构,从原来测试 POC workflow/简单 Agent 开始逐步构建生产级可用 Agent,真正解决线上问题,构建 Agent 在企业是面相全员提升效率的路径,不再是简单业务流程面临问题更加复杂,可能企业就会遇到如下挑战:

    • 语言栈多样化:企业内核心业务团队可能是 Java/Golang,算法团队使用 Python,面临 Agent 架构选型多语言栈怎么做无缝协作?
    • Agent 框架割裂:LangChain、AutoGPT、AgentScope 等不同框架以及 Agent 各自为政,如何实现跨框架调用?
    • 多团队Agent协同:Agent 如果有一个团队做,不懂业务做不深,Agent 分布在不同的服务、团队、项目中,内部选型会有 Dify、n8n 低代码和高代码平台选型,如何统一发现和管理?
    • 协议不统一:REST、gRPC、自定义协议...每个 Agent 都有自己的接口规范,集成成本高、维护困难。

    image

    A2A(Agent-to-Agent)协议正是为解决这些问题而生。 它是 Google 提出一套面向分布式多 Agent 互联互通的开放标准,定义了统一的消息结构和能力描述,让不同语言、不同框架、不同运行时上的 Agent 都能被发现、被调用、被编排。基于 A2A,Agent 之间可以在不共享代码、不耦合底层实现的前提下,完成文本对话、thinking、多模态内容、工具调用等丰富交互,真正实现“一次定义,处处可用”。

    image

    Agent 跨语言、跨框架调用最佳实践

    AgentScope 是阿里巴巴推出的一款以开发者为核心,专注于多智能体开发的开源框架。它的核心目标是解决智能体在构建、运行和管理中的难题,提供一套覆盖“开发、部署、监控”全生命周期的生产级解决方案。

    在 AgentScope 最新版本中,我们全面支持 A2A 协议,并集成 Nacos 作为 A2A Registry 的默认实现,构建了一套从开发到部署的完整分布式多智能体协作体系,让智能体协作从“单打独斗”走向“开放互联”。

    image

    • 告别“Agent 孤岛”:通过 A2A 协议,AgentScope 的 Agent 可以与任何实现 A2A 的 Agent 无缝互操作,不论由谁开发、用何种技术栈构建,都能在统一的协作框架下高效协同,打破技术壁垒,共同构建跨语言、跨框架的开放生态。
    • 统一开发体验,告别适配烦恼:在 AgentScope 中,调用本地 Agent 和调用远端 A2A Agent 使用同一套 API。框架自动处理协议转换、错误重试和路由选择,我们可以专注业务,不必为适配不同 Agent 编写冗余代码,从而提升效率与可维护性。
    • 生产级治理,开箱即用:基于 Nacos 3.0 智能体注册中心,AgentScope 应用具备服务发现、健康检查、命名空间隔离等成熟能力。选择 Nacos 作为默认 A2A Registry,不仅因为它经过大规模生产验证,也因为它与企业现有运维体系兼容,让智能体治理无需重复造轮子,加速规模化落地。

    在 AgentScope 中使用 A2A

    1. AgentScope:连接外部 A2A 网络,像调用本地 Agent 一样简单

    AgentScope 提供统一的 A2A 对接能力,我们可以像调用本地工具一样自然地调用远端 A2A Agent,实现跨语言、跨框架的协同,告别繁琐的协议适配工作:

    • 双向消息转换: 实现框架内部消息格式与 A2A Message 的双向转换,支持文本、thinking、多模态、工具调用等 Block 类型,保留必要元信息,确保语义一致。
    • 统一交互范式: 支持直接调用和 observe() 两种方式。直接调用 agent(msg) 可立即拿到结果;observe() 先累积上下文,后续再连同当前输入一起发送,适合长会话、多轮协作场景。
    • 任务与中断管理: 内建长任务状态管理与 Artifact 处理机制,支持长时间任务的平滑中断,覆盖超时与取消场景。
    • 统一的服务发现能力: 通过 AgentCardResolver 扩展点标准化“发现”能力,任何实现该接口的组件,例如:FixedAgentCardResolverFileAgentCardResolverWellKnownAgentCardResolverNacosAgentCardResolver 等都可按需加载,轻松适配不同基础设施。

    image

    通过 A2AAgent 以及 AgentCardResolver,我们可以按名称、分组或标签从 A2A Registry 中发现并调用其他 Agent,实现跨团队、跨项目甚至跨语言的智能体复用。基于 A2A Registry,智能体拥有统一的服务发现与治理能力,可与现有配置中心、网关、熔断限流及安全体系协同,为大规模分布式智能体应用打好底座。

    以下示例展示如何使用 NacosAgentCardResolver 从 Nacos Registry 中发现并调用 Agent:

    注意在对应版本以上使用 demo, Python (AgentScope v1.0.11 、AgentScope Runtime v1.0.4 )和  Java (AgentScope v1.0.6 ,AgentScope Runtime v1.0.0

    Python 代码示例

    查看详细文档:https://doc.agentscope.io/zh_CN/tutorial/task_a2a.html

    from agentscope.agent import A2AAgent
    from agentscope.a2a import NacosAgentCardResolver
    from agentscope.message import Msg
    # Python AgentScope v1.0.11以上
    # 创建 Nacos AgentCard Resolver
    nacos_resolver = NacosAgentCardResolver(
        remote_agent_name="my-remote-agent",  # Nacos 中注册的智能体名称
        nacos_client_config=ClientConfig(
            server_addresses="http://localhost:8848",  # Nacos 服务器地址
            # 其他可选配置项
        ),
    )
    # 使用 Resolver 创建 A2AAgent,通过名称从 Nacos 发现 Agent
    agent = A2AAgent(
        agent_card=await nacos_resolver.get_agent_card()
    )

    Java 代码示例

    查看详细文档:https://java.agentscope.io/zh/task/a2a.html

    使用 NacosAgentCardResolver 从 Nacos Registry 中发现 Agent:

    import io.agentscope.agent.A2AAgent;
    import io.agentscope.extensions.a2a.nacos.NacosAgentCardResolver;
    import java.util.Properties;
    import com.alibaba.nacos.api.PropertyKeyConst;
    import com.alibaba.nacos.api.ai.AiFactory;
    import com.alibaba.nacos.api.ai.AiService;
    Properties properties = new Properties();
    properties.put(PropertyKeyConst.SERVER_ADDR, "localhost:8848");
    // 其他可选配置项
    AiService aiService = AiFactory.createAiService(properties);
    NacosAgentCardResolver agentCardResolver = new NacosAgentCardResolver(aiService);
    A2AAgent agent = A2AAgent.builder()
            .name("MyAgent")
            .agentCardResolver(agentCardResolver)
            .build();

    Nacos 3.0 作为智能体注册中心,其在生产环境中久经验证的服务发现与配置管理能力,能够助力企业构建统一的智能体服务治理平台。

    2. AgentScope Runtime:暴露 A2A Agent 服务,启动即注册

    AgentScope Runtime 提供统一的 A2A 服务暴露能力,帮助我们把本地 Agent 应用包装成符合 A2A 规范的服务端点。通过 A2A 协议适配器,应用在启动时会自动完成:

    • 结构化配置体系:通过 A2A 扩展配置 a2a_config 灵活定义 AgentCard(name、description、version、skills、default_input_modes/default_output_modes 等)、传输层配置(host、port、path 等)、Registry 参数和任务超时等。
    • 自动服务包装:启动时由 A2A 协议适配器将 Agent 应用封装成符合 A2A 规范的服务端点,自动处理协议转换、消息路由等底层细节。
    • 生产级部署支持:与主流框架无缝集成,Python 侧支持 AgentApp 配置体系,Java 侧支持 Spring Boot Starter,让智能体服务自然融入现有基础设施。
    • 自动服务注册与治理:通过 A2ARegistry 抽象接口,Python 与 Java 都能开箱即用地集成 Nacos Agent Registry。Agent 能力描述(AgentCard)和网络端点会自动注册到 Registry,让其他 Agent 可发现、可调用。

    image

    以下示例展示如何在 Runtime 层使用 Nacos Registry 进行服务注册:

    Python 代码示例

    查看详细文档:https://runtime.agentscope.io/zh/a2a_registry.html

    方式一:参数配置

    在构造 AgentApp 时,通过 A2A 配置扩展字段 a2a_config 参数的 registry 字段指定 Registry 实例或列表:

    from agentscope_runtime.engine.app import AgentApp
    from agentscope_runtime.engine.deployers.adapter.a2a import (
        AgentCardWithRuntimeConfig,
    )
    from agentscope_runtime.engine.deployers.adapter.a2a.nacos_a2a_registry import (
        NacosRegistry,
    )
    from v2.nacos import ClientConfigBuilder
    # 创建 Nacos Registry 实例
    registry = NacosRegistry(
        nacos_client_config=ClientConfigBuilder()
            .server_address("nacos-server:8848")
            # 其他可选配置项
            .build()
    )
    app = AgentApp(
        app_name="TestAgent",
        app_description="TestAgent",
        # 在 a2a_config 中配置 registry
        a2a_config=AgentCardWithRuntimeConfig(registry=registry),
    )

    方式二:使用环境变量配置

    环境变量可以通过 .env 文件或系统环境变量设置:

    # .env 文件示例
    A2A_REGISTRY_ENABLED=true
    A2A_REGISTRY_TYPE=nacos
    NACOS_SERVER_ADDR=localhost:8848
    # 其他可选配置项

    Java 代码示例

    查看详细文档:https://java.agentscope.io/zh/task/a2a.html

    在最新版本的 Java AgentScope 中,应用可以直接暴露 A2A 服务,只有在需要使用 Sandbox 时,才需要使用 Runtime。

    对于非最新版本,Java 开发者可以将 AgentScope Agent 无缝融入现有的 Spring Boot 基础设施体系。通过引入 spring-boot-starter-agentscope-runtime-a2a-nacos 依赖,应用在启动时会自动暴露 A2A 服务并注册到 Nacos Registry。

    Maven 依赖配置

    <dependency>
        <groupId>io.agentscope</groupId>
        <artifactId>spring-boot-starter-agentscope-runtime-a2a-nacos</artifactId>
        <version>1.0.3</version>
    </dependency>

    application.yaml 配置

    agentscope:
      a2a:
        server:
          card:
            description: "基于 A2A 协议的 Java 智能体"
            provider:
              organization: 您的组织名称
              url: https://your-organization.com
          nacos:
            server-addr: ${NACOS_SERVER_ADDRESS:127.0.0.1:8848}
            # 其他可选配置项

    通过上述配置,Spring Boot 应用在启动时会自动:

    • 暴露符合 A2A 规范的 JSONRPC 服务端点(默认路径:/a2a/jsonrpc)。
    • 暴露 AgentCard 的 Well-Known 端点(默认路径:/.well-known/agent-card.json),用于其他 Agent 发现和了解当前 Agent 的能力。
    • 自动处理 A2A 协议的消息转换和路由,将 A2A 消息格式转换为应用内部的消息处理逻辑。
    • 支持任务超时、中断等 A2A 协议规定的运行时特性。
    • 将 Agent 的能力描述(AgentCard)注册到 Nacos,基于 Nacos 3.0 智能体注册中心进行统一治理。

    得益于这一机制,AgentScope 应用启动即完成在 Nacos 的 A2A Agent 注册,为后续的发现、路由、灰度与监控奠定基础。对于已经大规模采用 Java 技术栈的团队,这意味着智能体服务能自然长在同一套基础设施上,大幅降低引入成本与运维负担。

    总结

    AgentScope 全面支持 A2A 协议和 Nacos Agent Registry,标志着智能体从“单点能力”迈向“开放互联生态”的关键一步,为企业构建统一的智能体管理平台,助力大规模 Agent 化落地:

    • AgentScope 层:借助 A2AAgent 与 AgentCardResolver,我们提供统一的 A2A 对接能力和灵活的发现策略,默认集成 Nacos,支持动态 Agent 发现与调用。
    • AgentScope Runtime 层:通过 A2A 协议适配器和 A2ARegistry 抽象接口,提供统一的 A2A 服务暴露能力,支持自动服务注册与治理,与 Python AgentApp 和 Java Spring Boot Starter 无缝集成。

    未来,我们会继续围绕 A2A 与 Registry 深耕,在发现与路由、版本与灰度、安全与访问控制等方向迭代,让面向生产的智能体应用更稳、更易用。

    扩展链接

    AgentScope:https://doc.agentscope.io/

    AgentScope Python A2A 文档:https://doc.agentscope.io/tutorial/task_a2a.htmlAgentScope

    Java:https://java.agentscope.io/AgentScope

    Java A2A 文档:https://java.agentscope.io/en/task/a2a.html

    Nacos:https://nacos.io/docs/latest/manual/user/ai/agent-registry

    收藏工具是很多开发者的习惯。在 GitHub 上点 Star,然后放进收藏夹吃灰,好像这样就能自动拥有了这种能力

    没错,就跟减肥健身一样,收藏了=做过了,吓吓身上的肥肉。

    当大多数人还在手动写 CRUD、用肉眼盯着模型训练、在繁杂的项目文档中溺水时,极少数大聪明就开始用工具构建了自动化体系。

    如果在 24 小时内部署好这8个工具,就会彻底告别低效的体力劳动。

    Ivy

    解决痛点: 深度学习 框架的生殖隔离

    image.png

    做 AI 开发的时候,好不容易找到一篇绝佳论文,代码是 PyTorch 写的,而基础设施全套是 TensorFlow。重写模型需要一周,放弃又不甘心。

    这时候 Ivy 就能派上用场了,它是一个机器学习框架的转换器(Transpiler)。它能把代码转译成框架无关的中间表示,让你可以用 PyTorch 写代码,然后在 TensorFlow 的后端上运行,或者反之。它打破了框架之间的壁垒,让复用开源模型变得不再痛苦。

    安装方式:

    pip install ivy

    MLflow

    解决痛点:实验过程的失忆

    redundant_retrievals-17b12e1e6c05c41cc4958e38006d6b64.gif

    两周前训练出一个准确率 95% 的模型,今天想复现,却死活想不起当时的参数是 0.01 还是 0.001。老祖宗说的好,好记性不如烂笔头。

    MLflow 就是全自动烂笔头,它能记住所有东西。它不干涉怎么写模型,只负责记录。它会追踪每一次实验的代码版本、数据哈希、超参数设置和最终指标。当项目变得复杂时,它是保证实验可追溯、模型可复现的基础设施。

    安装方式:

    pip install mlflow

    Evidently

    解决痛点:模型上线后的数据漂移

    dashboard_llm_tabs.gif

    模型在训练集上准确率 99%,上线一个月后效果却莫名其妙下降。这通常是因为“数据漂移”(Data Drift),带清都亡了,你的模型还在搞反清复明那一套。

    Evidently 专门用来监控这种现象。它不看 CPU 内存,只看数据。它通过对比训练数据和线上实时数据的分布差异,生成直观的报告。一旦发现输入特征发生偏移,或者模型预测倾向出现异常,它能立刻发出警报。这是防止 AI 系统在生产环境中撒谎的必要工具。

    Prefect

    解决痛点:脆弱的 Crontab 和胶水代码

    image.png

    很多数据流水线最初只是几个 Python 脚本,用 Crontab 定时跑。一旦任务失败、依赖卡死或者需要重试,维护成本就直线上升。

    Prefect 是现代化的流程编排工具。它接管调度、日志、重试和通知。原本需要写满 try-except 的脏活,现在只需要一个装饰器。让数据流转像瑞士钟表一样精准,而不是像摇摇欲坠的积木。

    安装方式:

    pip install evidently

    Huly Platform

    解决痛点:项目管理工具的割裂

    image.png

    Linear 追任务,Slack 聊需求,Notion 记文档。每天在三个网页间切换 500 次,你的注意力就是这样被撕碎的。

    Huly 是一个开源的一体化平台,把项目管理、即时通讯和知识库整合在一起。它基于 Node.js 构建,不仅能替代 Jira/Linear,还允许通过 AI 智能体来自动化处理任务流转。对于希望数据私有化且厌倦了 SaaS 订阅费的团队,这是一个极佳的替代方案。

    安装方式:直接下载即可

    但需要使用 npm 进行身份验证:

    npm login --registry=https://npm.pkg.github.com

    OpenCode

    解决痛点:被 IDE 插件锁死,AI 编程缺乏掌控感

    image.png

    市面上的 AI 编程助手都在试图把你锁死在他们的 IDE 里,强推闭源模型。你以为你在用 AI,其实你是被 AI 厂商圈养的数据工。

    OpenCode (opencode.ai) 就不是这样,它是终端优先(Terminal-first)的 AI 编程 智能体。它不依赖浏览器或特定编辑器,而是直接在终端里通过自然语言与代码库交互。

    • 拒绝被宰:支持 75+ 种模型。用 Claude 3.5 写逻辑,用本地 Ollama 跑隐私数据,完全由你掌控。
    • 双脑协作:Plan Agent 负责思考,Build Agent 负责执行,逻辑严密。
    • 拒绝幻觉:深度集成 LSP,它能看懂代码结构,而不是瞎猜变量名。

    对于习惯命令行、重视隐私且不想被大厂生态绑架的开发者,OpenCode 是目前最自由的替代方案。

    安装方式

    npm i -g opencode-ai

    Krayin CRM

    解决痛点: CRM 系统只进不出,缺乏生产力

    image.png

    销售人员最恨录入数据。一个只能记录不能产出的 CRM,就是企业的僵尸资产。

    Krayin 引入了 AI 模块来提升效率:

    • 内容生成:自动起草跟进邮件、整理会议纪要,销售只需简单修改即可发送。
    • 智能补全:在详情页辅助填充客户信息,减少手动录入工作量。
    • 上下文增强:在记录日志时,AI 能根据简短的关键词扩充成完整的业务记录。

    对于熟悉 PHP 技术栈的团队,Krayin 是一个兼具灵活性和智能化的高性价比选择。

    安装方式:需要PHP 8.1及以上版本;Node 8.11.3 LTS 及以上版本;还有 MySQL 或 MariaDB 数据库

    composer create-project
    
    # 找到根目录中的.env文件,并将APP_URL参数更改为您的域名。
    # 另外,请在.env文件中配置邮件和数据库参数。
    
    php artisan krayin-crm:install

    IDURAR

    解决痛点:ERP 系统僵化,难以二开

    image.png

    中小企业需要 ERP/CRM,但市面上的 SaaS 软件要么太贵,要么功能太死板。IDURAR 基于 Node.js (MERN 栈),天生就是为了被修改和集成设计的。

    它的 AI 集成策略非常务实:通过 API 连接外部 AI 服务。系统本身提供稳固的业务流程(销售、库存、发票),同时留出接口让开发者挂载自定义的 AI 逻辑。比如连接一个微调过的模型来分析销售数据,或者自动更新库存状态。这种松耦合设计非常适合开发者进行定制。

    安装方式:需要创建 MongoDB 帐户和数据库集群

    git clone https://github.com/idurar/idurar-erp-crm.git
    cd idurar-erp-crm
    cd backend
    npm install

    把上面这些工具跑起来,就会发现技术栈挺杂的。

    • Ivy, MLflow, Prefect, Evidently:深度依赖 Python,且对版本敏感。
    • Huly, OpenCode, IDURAR:基于 Node.js,前后端依赖包复杂。
    • Krayin CRM:基于 PHP (Laravel),需要配置 Web Server 和数据库。

    如果在本地电脑上混装这些环境,光是处理环境变量冲突、依赖打架就能折腾一天。

    为了保持开发环境的纯净,可以使用 ServBay

    image.png

    它不是虚拟机,也不需要编写 Dockerfile,主要作用就是环境隔离与快速切换。ServBay 允许在同一台机器上共存多个版本的 Python、Node.js 和 PHP。

    • 想跑 Krayin?一键切换到 PHP 8.2 环境。
    • 想试用 Huly?切到 Node.js 20。
    • 搞深度学习?切回 Python 3.10。

    image.png

    它自动处理了路径和依赖问题,让这些工具能互不干扰地运行。对于喜欢折腾各种开源项目但又不想把系统搞乱的开发者来说,这是一个非常实用的工具。

    更名说明:Clawdbot 项目已更名为 Moltbot,当前官方仓库为 https://github.com/moltbot/moltbot。 本文基于最新仓库内容和 README 编写。

    一、什么是 Clawdbot?

    Clawdbot 是一个开源的、自托管的个人 AI 助手框架。它以本地服务或守护进程的形式运行,通过接入不同的消息通道(如 Telegram、Discord、Slack 等)与用户交互,并根据配置执行自动化任务。

    从官方 README 可以明确以下几点:

    • 完全自托管:非 SaaS,数据和运行完全由用户控制
    • CLI + Gateway 服务:核心运行方式,支持多种部署模式
    • 配置驱动:通过配置文件定义 Bot 的行为和接入通道
    • 长期运行:适合作为后台服务持续运行

    该项目更偏向“可编排的 AI 助手代理”,而不是传统意义上的云服务或平台组件。

    二、为什么在 KubeSphere 上运行 Clawdbot?

    虽然 Clawdbot 可以直接在本地或单台服务器上运行,但在团队或长期运行场景中,使用 Kubernetes 平台更具优势,而 KubeSphere 提供了完整的可视化运维能力。

    将 Clawdbot 部署在 KubeSphere 上可以解决以下问题:

    • 部署标准化:避免手动维护本地守护进程
    • 配置集中管理:通过 ConfigMap / Secret 管理 Bot 配置和密钥
    • 运行状态可观测:统一查看日志和 Pod 状态
    • 可重复部署:同一套定义可在不同环境复用

    对于希望将 Bot 类服务纳入云原生运维体系的团队,这是一种更稳妥的方式。

    三、部署前准备

    环境要求

    • KubeSphere 集群:已部署完成,版本要求 v4.x 及以上
    • 已安装扩展:KubeSphere Gateway 及 cert-manager 扩展
    • 镜像仓库:可访问公有或私有镜像仓库

    四、在 KubeSphere 中部署 Clawdbot

    步骤一:安装扩展组件

    将 Clawdbot 扩展组件推送到 KubeSphere 扩展商店,并进行安装。在安装过程中,通过扩展组件配置加载相关密钥:

    您需要将相关秘钥通过扩展组件配置加载到 Clawdbot。

    clawdbot:
      secrets:
        create: true
        data:
          # Set via --set or environment variables
          anthropicApiKey: ""
          openaiApiKey: ""
          discordBotToken: ""
          telegramBotToken: ""
          gatewayToken: ""  # Auto-generated if empty

    注意: 当前配置中禁用了控制界面中的设备识别和配对功能。

    步骤二:配置 Ingress

    您可以通过 KubeSphere Gateway 扩展配合 cert-manager 扩展,使用 HTTPS 协议将 Clawdbot 服务以 Ingress 的方式对外暴露。

    首先,在集群中创建并启用集群网关,作为统一的 Ingress 入口。随后,在该网关之上为 Clawdbot 服务创建对应的应用路由,并通过 cert-manager 自动签发和管理 TLS 证书,从而实现安全的 HTTPS 访问。

    kind: Ingress
    apiVersion: networking.k8s.io/v1
    metadata:
      name: clawdbot
      namespace: extension-clawdbot
      annotations:
        cert-manager.io/cluster-issuer: default-issuer       # 借助 cert-manager, 为 ingress 自动生成和创建证书
        kubesphere.io/creator: admin
    spec:
      ingressClassName: kubesphere-router-cluster
      tls:
        - hosts:
            - 172.31.19.4.nip.io
          secretName: clawdbot-cert
      rules:
        - host: 172.31.19.4.nip.io
          http:
            paths:
              - path: /
                pathType: ImplementationSpecific
                backend:
                  service:
                    name: clawdbot
                    port:
                      number: 18789
    

    步骤三:访问控制页面

    使用如下命令获取 Gateway token:

    kubectl get secret clawdbot -n extension-clawdbot \
      -o jsonpath='{.data.gatewayToken}' | base64 --decode

    然后在浏览器中输入以下地址访问 Clawdbot 控制页面:

    https://{ingress 暴露地址}/?token=${token}

    五、运维建议

    在生产或长期运行场景中,建议遵循以下最佳实践:

    • 资源限制:为 Clawdbot 设置合理的 CPU / 内存限制,避免资源争用。
    • 配置管理:通过修改 ConfigMap 调整 Bot 行为,而非重新构建镜像。
    • 版本更新:定期更新镜像,跟进上游版本变更,获取新功能和修复。
    • 密钥轮换:对 Secret 中的 Token 进行定期轮换,增强安全性。

    需要注意的是,Clawdbot 本身并不负责外部平台的权限管理,相关 OAuth 或 Bot Token 仍需在对应平台侧正确配置。

    六、总结

    Clawdbot 并不是一个“即开即用”的 SaaS 产品,而是一个强调自主可控、可编排、可长期运行的 AI 助手框架。这类服务一旦进入稳定使用阶段,其运行可靠性、配置管理能力和运维成本,往往比功能本身更重要。

    通过 KubeSphere,将 Clawdbot 纳入 Kubernetes 的统一管理体系,可以在不改变其原有架构和使用方式的前提下,获得标准化部署、可观测运维以及安全可控的运行环境。对于希望长期运行 Bot 服务、或在团队内复用 AI 助手能力的用户来说,这是一条非常自然、也非常稳妥的路径。

    如果你正在寻找一种更工程化、更可持续的方式来运行自托管 AI 服务,不妨试试 KubeSphere ——它不仅适合管理传统应用,也同样适合承载新一代的 AI Agent 与自动化服务。

    欢迎大家体验 KubeSphere,也欢迎在社区中分享你自己的 AI + 云原生实践。

    整理 | 华卫

     

    凌晨,OpenAI 发布了新一代 AI 科研利器 Prism,该平台由 GPT-5.2 加持,供科学家们撰写和协作研究,即日起向所有拥有 ChatGPT 个人账户的用户免费开放。用华人 AI 创业者 Yuchen Jin 的话说,“每篇论文都将把 ChatGPT 列为合著者。”

     

    而在昨日,OpenAI 副总裁、新成立的 OpenAI for Science 团队负责人 Kevin Weil 就在 X 上发文预热道,“我们的目标是赋予每位科学家 AI 超能力,让他们能做更多事情,让世界在 2030 年就能开展 2050 年的科学研究。”

     

    自 ChatGPT 爆红面世后的三年里,OpenAI 的技术颠覆了日常生活中方方面面的行为模式。如今 OpenAI 正明确发力科研领域,面向科研人员布局。10 月,该公司宣布成立全新的 OpenAI for Science 团队,核心致力于探索其大语言模型(LLM)助力科研人员的路径,并优化旗下工具为科研人员提供支持。过去数月,社交媒体上涌现出大量相关内容,学术期刊也刊发了诸多研究成果,数学家、物理学家、生物学家等领域研究者纷纷撰文,讲述大语言模型、尤其是 GPT-5 如何助力他们取得新发现或是为他们指引方向,让他们找到原本可能错失的解决方案。

     

    那么,OpenAI 为何选择此时入局?此番布局,究竟想要达成怎样的目标?发力科研领域,与该公司更宏大的使命如何契合?在这一领域,OpenAI 已然姗姗来迟。谷歌 DeepMind 早在数年前便已成立 AI-for-science 团队,打造了 AlphaFold、AlphaEvolve 等具有开创性的科学模型。2023 年,谷歌 DeepMind 的 CEO 兼联合创始人 Demis Hassabis 曾就该团队的情况在采访中表示,“这是我创立 DeepMind 的初衷。事实上,这也是我整个职业生涯深耕 AI 领域的原因。”

     

    近日,Kevin Weil 在一次访谈中不仅正面回应了这些问题,还对当前模型的实际能力给出了比先前更为保守的评价:目前模型还达不到取得颠覆性新发现的水平,但倘若能让人不必把时间浪费在已经解决的问题上,也是对科研的一种加速。有意思的是,据其透露,一位 OpenAI 主动接触且开通了 GPT-5 付费服务的科研人员反馈,GPT-5 会犯一些低级错误,比人犯的错误更加愚蠢,不过一直在进步。

     

    此外,按照 OpenAI 在 AI 科研领域的布局,接下来其将对模型整体设计作两大思路优化:一是让 GPT-5 在给出答案时降低置信度,具有认知层面上的谦逊性;另一方向,是利用 GPT-5 反向对自身输出进行事实核查。

     

    “2026 年对于科研领域的意义,将堪比 2025 年之于软件工程。”Weil 表示,“2025 年初,若有人借助 AI 完成大部分代码编写,还只是早期尝鲜者;而 12 个月后的现在,若还未用 AI 编写大部分代码,就可能已经落后。现在,科研领域正显现出与编程领域类似的早期发展势头。一年后,倘若一名科研人员还未深度运用 AI 开展研究,就将错失提升思考质量、加快研究进度的机会。”

    模型能力早已超过 90%研究生,AGI 最大价值在于推动科学进步

    数年前,Weil 加入 OpenAI 出任首席产品官,他曾担任 Twitter 和 Instagram 的产品负责人官。但他的职业起点是科研领域:在斯坦福大学攻读粒子物理博士学位期间,他完成了三分之二的学业,随后为追寻硅谷梦离开学术界。Weil 也乐于提及自己的这段学术背景,他说:“我曾以为自己余生都会做一名物理教授,现在度假时还会读数学相关的书籍。”

     

    当被问及 OpenAI for Science 与公司现有的白领生产力工具、爆火的视频应用 Sora 如何契合时,Weil 脱口而出:“OpenAI 的使命是研发通用人工智能(AGI),并让这项技术为全人类带来福祉。”他表示,不妨想象这项技术未来能为科研领域带来的变革:全新的药物、材料、器械。

     

    “试想一下,它能帮助我们探索现实的本质,攻克悬而未决的科学难题。或许 AGI 能为人类创造的最重大、最积极的价值,正是其推动科学进步的能力。”他补充道:“GPT-5 的出现,让我们看到了这种可能。”

     

    在 Weil 看来,如今的大语言模型已足够优秀,能成为科研人员的得力协作伙伴。它们能提出各种想法,建议新的研究方向,并在新问题和几十年前发表在冷门期刊或外语期刊上的旧解决方案之间找到富有成效的联系。但在大约一年前,情况并非如此。自 2024 年 12 月发布首个推理模型(一种能够将问题分解成多个步骤并逐一解决的逻辑学习模型)以来,OpenAI 一直在不断拓展这项技术的边界。推理模型的问世,让大语言模型解决数学和逻辑问题的能力得到大幅提升。

     

    “放在几年前,模型能在 SAT 考试中拿到 800 分,就足以让我们所有人惊叹不已。”Weil 称。而如今,大语言模型能在数学竞赛中夺冠,解出研究生阶段的物理难题。去年,OpenAI 和 谷歌 DeepMind 均宣布,其研发的大语言模型在国际数学奥林匹克竞赛中取得金牌级成绩,该赛事是全球难度最高的数学竞赛之一。Weil 表示,“这些模型的能力,早已不只是超过 90% 的研究生,而是真正达到了人类能力的极限。”

     

    这一论断非常大胆,却也并非无懈可击。但毋庸置疑的是,搭载了推理模型的 GPT-5,在解决复杂问题方面较 GPT-4 有了质的飞跃。行业基准测试 GPQA 包含 400 多道选择题,专门考察生物、物理、化学领域的博士级专业知识,GPT-4 在该测试中的正确率仅为 39%,远低于人类专家约 70% 的基准线;而据 OpenAI 数据,2024 年 12 月推出的 GPT-5 最新版本 GPT-5.2,正确率达到了 92%。

    读遍 30 年来的论文,模型也做不出颠覆性新发现

    Weil 的这种兴奋之情显而易见,却或许有些过头了。去年 10 月,Weil 等 OpenAI 高管曾在 X 平台高调宣称,GPT-5 已为多个数学未解难题找到解决方案。但数学家们很快指出,GPT-5 实际只是从早期研究论文中挖掘出了已有的答案,其中至少还有一篇德文文献。这样的能力虽有价值,却绝非 OpenAI 宣称的那般突破性成就。事后,Weil 与其同事删除了相关帖子。

     

    当时,这件事闹出了不小的风波。刚开始疯传的是:GPT-5 解决了 10 个此前未解决的埃尔德什问题(Erdős problems),并在另外 11 个问题上取得了进展,而之后被负责维护埃尔德什问题网站的数学家 Thomas Bloom 澄清为;GPT-5 只是找到了一些能解决这些问题的参考文献。DeepMind 首席执行官 Demis Hassabis 对此指出,该团队的沟通方式“过于草率”。前 Meta 首席 AI 科学家 Yann LeCun 则讽刺道, OpenAI“被自己的炒作所反噬”(hoisted by their own GPTards),“搬起自己的 GPT 石头砸了自己的脚”。

     

    但就在前几天,又有消息称,GPT-5.2 Pro 破解了一道埃尔德什猜想,题目是埃尔德什问题库中的第 281 号。这次证明由数学家 Neel Somani 推动,且论证过程由菲尔茨奖得主陶哲轩证明没有问题,并评价其是“AI 解决开放性数学问题中“最明确的案例之一”。目前,GPT-5.2Pro 对该问题的证明结果已被埃尔德什问题网站收录。

     

    据悉,GPT-5.2Pro 对这个问题提出了新的证明方法,虽然忽略了此前已有的相关证明,但陶哲轩指出 GPT-5.2Pro 的证明思路与之前的方法“相当不同”,只在概念上有些重叠。现在这道题有了两条论证思路,一是 GPT-5.2 Pro 采用的遍历理论框架,策略是“弗斯滕伯格对应原理”的变体;二是两个早在 1936 年和 1966 年就已经存在的定理组合:达文波特-埃尔多斯定理和罗杰斯定理,且解法更简单。

     

    不过,如今的 Weil 也更加谨慎了。他表示,能找到那些已存在却被遗忘的答案,本身就已意义重大:“我们都站在巨人的肩膀上前行,倘若大语言模型能整合这些知识,让我们不必把时间浪费在已经解决的问题上,这本身就是对科研的一种加速。”他也淡化了大语言模型即将取得颠覆性新发现的说法:“我认为目前模型还达不到那个水平,未来或许能做到,我对此持乐观态度。”

     

    但他强调这并非团队的核心使命:“我们的使命是加速科学发展,而加速科学发展的标准,并非一定要像爱因斯坦那样对整个领域进行彻底的重新构想。”在 Weil 看来,核心问题只有一个:科学发展速度是否真的更快了?“当科研人员与模型协作时,能比独自研究完成更多工作、效率也更高。我认为我们已经看到了这一点。”

     

    去年 11 月,OpenAI 发布了一系列由公司内外科研人员提供的案例研究,以真实案例展现了 GPT-5 的实际应用及助力科研的过程。Weil 表示,“这些案例的研究者,大多早已在研究中直接使用 GPT-5,他们通过各种方式找到我们,告诉我们‘看看这些工具能让我做到什么’。”GPT-5 擅长的关键事情是:找到科研人员尚未意识到的现有研究成果及关联线索,这有时能催生新的思路;协助科研人员草拟数学证明过程;为科研人员在实验室验证假说提供实验思路。

     

    “GPT 5.2 几乎阅读了过去 30 年发表的每一篇论文。它不仅理解科学家所处领域的内容,还能从其他不相关的领域中提炼出可类比的思路。”Weil 称,“这太强大了。你总能在相关领域找到人类合作者,但要在所有可能相关的上千个相关领域找到上千个合作者,那就难上加难了。除此之外,我还能在深夜与模型一起工作,它从不需要休息,也能同时向它提出十个问题,这些事若是对人做,难免会显得尴尬。”

    GPT-5 犯错比人更愚蠢,机器人更愿意听它的指挥?

    据悉,OpenAI 为佐证 Weil 的观点,接触了多位科研人员,其中绝大多数都对此表示认同。范德堡大学物理与天文学教授 Robert Scherrer 此前仅将 ChatGPT 当作消遣工具把玩,他告诉我:“我曾让它以《贝奥武夫》的文风改写《吉利根岛》的主题曲,它完成得非常出色。”直到同在范德堡大学的同事、如今任职于 OpenAI 的物理学家 Alex Lupsasca 告诉他,GPT-5 帮其解决了一个研究中的难题,他才改变了对这款模型的看法。

     

    Lupsasca 为 Scherrer 开通了 GPT-5 Pro,这是 OpenAI 每月 200 美元的高级订阅服务。Scherrer 说,“我和我的研究生为一个问题钻研了数月都毫无头绪,GPT-5 却成功解决了它。”但他也坦言,这款模型并非完美:“GPT-5 还是会犯一些低级错误。当然,我自己也会出错,但 GPT-5 犯的错误更愚蠢。”不过他表示,其进步速度有目共睹,“如果当前的发展趋势能持续下去,我想很快所有科研人员都会用上大语言模型。当然,这只是个假设。”

     

    非营利性研究机构杰克逊实验室的生物学教授 Derya Unutmaz,在其免疫系统相关研究中,会借助 GPT-5 进行头脑风暴、论文总结和实验规划。在他向 OpenAI 分享的案例研究中,其团队曾分析过一组旧数据集,而 GPT-5 对这组数据的分析,得出了全新的见解和解读。他说:“大语言模型对科学家来说已经至关重要了。以前需要几个月才能完成的数据集分析,现在用大语言模型就能完成了,不用大语言模型已经行不通了。”

     

    加州大学伯克利分校的统计学家 Nikita Zhivotovskiy 表示,从 ChatGPT 首个版本发布开始,他就在研究中使用大语言模型了。和 Scherrer 一样,他认为大语言模型最有用的地方在于,能挖掘出其研究工作与一些未知现有研究成果之间的意外关联。“我相信大语言模型正在成为科学家们必不可少的技术工具,就像曾经的计算机和互联网一样。那些拒绝使用这类工具的人,将会长期处于劣势。”但他并不指望大语言模型能在短期内取得什么新发现,“我几乎没见过模型能提出真正值得单独发表的全新观点或论证。到目前为止,它们似乎主要是在整合现有的研究成果,有时还会出错,而非创造真正的全新研究方法。”

     

    也有与 OpenAI 无任何关联的科研人员,态度则没那么乐观。

     

    利物浦大学化学教授、勒沃休姆功能材料设计研究中心主任 Andy Cooper 表示,“到目前为止,我们尚未发现大语言模型从根本上改变了科学研究的方式,但我们近期的研究结果表明,这类工具确实有其用武之地。Cooper 正牵头研发一款所谓的 AI scientist,该系统能实现部分科研工作流程的完全自动化。他表示,其团队并不会借助大语言模型构思研究思路,但这项技术已开始在更庞大的自动化系统中显现实用价值,比如大语言模型可协助操控机器人。

     

    “我猜测,大语言模型或许会更多应用于机器人工作流程,至少在初期会是如此。因为我不确定人们是否愿意听从大语言模型的指挥,我自己当然是不愿意的。”Cooper 称。

    团队重点发力:让 GPT 少点自信、更加谦逊

    大语言模型的实用性或许与日俱增,但保持谨慎仍是关键。去年 12 月,研究量子力学的科学家 Jonathan Oppenheim 指出,某本科学期刊中出现了一处由大语言模型导致的错误。他在 X 平台发文称,“OpenAI 的管理层正在推广《Physics Letters B》上的一篇论文,其中的核心思路由 GPT-5 提出,这或许是首篇由大语言模型贡献核心观点且通过同行评审的论文。但有个小问题:GPT-5 提出的思路,验证的对象完全错了。研究人员让 GPT-5 设计一个能检测非线性理论的验证实验,它却给出了一个检测非定域性理论的方案。二者看似相关,实则截然不同。这就好比你想要一个新冠检测试剂盒,大语言模型却兴冲冲地递给你一个水痘检测试剂盒。”

     

    显然,许多科研人员正以富有创意、贴合实际的方式运用大语言模型。但同样显而易见的是,这项技术所犯的错误可能极为隐蔽,甚至连专家都难以察觉。这一问题的成因,部分源于 ChatGPT 的交互特性,它总能以迎合的语气让使用者放松警惕。正如 Jonathan Oppenheim 所言,“核心问题在于,大语言模型的训练目标是迎合用户,而科学研究需要的是能够挑战我们的的工具。”曾有一个极端案例,一名非科研领域的普通人被 ChatGPT 误导,长达数月都坚信自己发明了一个新的数学分支。

     

    当然,Weil 也深知大语言模型的幻觉问题,但他强调,新一代模型产生幻觉的概率已大幅降低。即便如此,他认为,仅仅关注幻觉可能就偏离了重点。

     

    “我的一位同事曾是数学教授,他说过的一番话让我印象深刻:‘我做研究时,和同事交流碰撞想法,自己的观点 90%都是错的,但这正是意义所在。我们都在大胆畅想思路,只为找到一条可行的研究路径。’”Weil 表示,“这其实是科研中最理想的状态。当你提出足够多的错误观点,有人偶然发现了一丝真理,另一人抓住这一点继续探讨:‘你说的这点并不完全正确,但如果我们换个思路’。就这样,人们便能在科研迷雾中逐渐摸索出前行的道路。”

     

    这正是 Weil 为 OpenAI for Science 设定的核心愿景。他认为,GPT-5 固然优秀,但它并非万能灵药。这项技术的价值在于引导人们探索新的方向,而非提供最终答案。事实上,OpenAI 目前正着手优化 GPT-5 的一项特性:让它在给出答案时降低其置信度。它不会再直接说“答案在这里”,而是会以更委婉的方式告诉科研人员:“以下思路可供参考。”“这正是我们目前投入大量精力在做的事:努力让模型具备某种认知层面的谦逊性。”Weil 称。

     

    据透露,OpenAI 正在探索的另一方向,是利用 GPT-5 对自身输出进行事实核查。实际应用中常有这样的情况:如果你把 GPT-5 的某个答案重新输入到模型中,它会逐条分析并指出其中的错误。Weil 表示,“我们可以让模型充当自身的校验者。如此便能搭建一套工作流程:模型先完成初步推理,再将结果交由另一模型审核;如果这个模型发现了可以改进的地方,就会把结果反馈给原模型,并提示‘注意,这部分内容有误,但这部分思路有价值,可保留’。这就像两个智能体协同工作,只有当输出内容通过校验者的审核后,才会最终呈现。”

     

    这一机制,与谷歌 DeepMind 为 AlphaEvolve 打造的模式高度相似。AlphaEvolve 是一款工具,它将大语言模型 Gemini 封装在一个更大的系统中,该系统能够筛选出优质回复,并将其反馈给模型进行改进。谷歌 DeepMind 已借助 AlphaEvolve 解决了多个现实中的科研难题。

     

    如今,OpenAI 面临着竞争对手的激烈角逐,这些企业的大语言模型即便无法实现 OpenAI 为其模型宣称的全部功能,也能完成绝大部分。倘若如此,科研人员为何要选择 GPT-5,而非同样在逐年迭代升级的 Gemini 或 Anthropic 旗下的 Claude 系列模型?归根结底,OpenAI for Science 的布局,很大程度上也是为了在这一新领域抢占先机。而真正的技术创新,尚未到来。 

     

    参考链接:

    https://www.technologyreview.com/2026/01/26/1131728/inside-openais-big-play-for-science/

    https://openai.com/zh-Hans-CN/prism/

     

    V3.0 新一代架构突破------从 "集中汇总" 到 "分布式协同"

    KaiwuDB V2.x 版本中的分布式执行引擎传统架构采用的是"管理节点(Master Engine,即 ME)--- 执行节点(TS Engine)"二级架构的集中式设计:

    • 通信链路:ME 向各执行节点下发 Flowspec 任务,执行节点间无直接通信链路,所有交互均通过 ME 中转。

    • 计算汇总:所有执行节点计算结果需全量回传至 ME,由 ME 承担二次汇总计算职责。

    为了减少冗余编解码的操作以及传输与计算的开销,进一步提升分布式执行的性能,KaiwuDB 在 V3.0 中将新一代架构通过四项核心改造实现架构层面的突破性升级,其关键组件与数据流转逻辑如下。

    1. 基于 Pipeline 架构:释放并行潜力,提升扩展弹性

    支撑高并发查询调度,满足 AP 场景横向扩展需求。采用 Pipeline 流式执行架构,通过任务拆分与流水线化执行,实现单设备高效并行;引入优先级调度机制,支持资源弹性分配与高优先级任务倾斜。

    查询并发承载能力大幅提升,架构扩展性适配从百级到万级查询的弹性需求,资源利用率显著提高。

    2. 统一编码:强化效率与兼容性,提速大数据处理

    统一编码标准,提升大规模数据集传输与处理效率。标准化采用 DataChunk 作为默认执行编码,依托其统一规范与高效的序列化 / 反序列化特性,单机处理 160 万行结果集场景下可提速 3 秒。整体消除编码层面性能损耗,为 TB 级数据分析提供高效、兼容的编码支撑,数据处理吞吐量显著提升。

    3. 执行节点间 BRPC 传输:优化分布式协同,降低传输开销

    实现节点间低延迟、高可靠数据传输,减少资源占用。采用 BRPC 作为执行节点间核心传输协议,依托其原生 C++ 接口与高效通信机制,简化传输链路、减少冗余开销;内置统一 Shuffle 机制,保障数据分发有序性。使得分布式传输延迟与网络带宽占用显著降低,节点间协同效率提升,支撑大规模分布式查询稳定执行。

    4. 算子全下推与能力升级:完善算力支撑,适配复杂场景

    提升算子性能与功能覆盖度,支撑大规模、复杂计算需求。推进算子全下推架构,减少数据回传开销;新增 Join 算子完善跨模计算能力,为 Hash Agg 算子适配落盘机制规避内存溢出,优化 Sort 算子执行逻辑提升大规模数据排序性能。算子层功能与性能双升级,可高效支撑复杂查询、高基数聚合、TB 级数据排序等重负载任务,适配 AP 场景多样化计算需求。

    KaiwuDB 3.0 分布式执行架构

    上述四项核心改造的具体作用机制如下:

    BRPC 通信层改造:在执行节点节点间构建专用通信链路,采用与本地算子同源的数据格式传输中间结果,彻底消除节点间的数据转换开销。

    全算子下推执行改造:将所有计算算子从 ME 迁移至执行节点部署执行,仅由 Root 执行节点承担最终结果汇总职责,其余执行节点仅向 ME 反馈执行状态,数据传输量降幅超 90%。

    Block Filter 机制引入:将数据过滤规则下推至存储层,存储节点基于 Block 元数据统计信息预过滤无效数据,显著降低计算层的输入数据量,提升计算效率。

    Pipeline 流水线调度改造:基于 Pipeline 模型对查询任务进行拆分与并行化编排,实现任务高效并行处理,其核心架构与数据流转逻辑如下:

    !
    Pipeline 模型

    Pipeline 模型沿用传统数据处理的流水线设计范式,将复杂查询任务解耦为若干细粒度、可并行调度的子任务;各子任务被编排为多个 Pipeline Stage(流水线阶段),每个 Stage 由一组 Operator(算子)构成协同处理单元。数据在算子间遵循流水线机制逐阶段流转处理,最终达成查询任务的高效执行目标。

    分布式执行调度流程

    调度层承担逻辑执行计划的分布式改写职责,将其解耦为执行节点级计划片段(Flowspec),并对各片段的执行时序与并发度进行精细化编排,保障多模分布式执行结果的一致性与准确性。

    针对时序数据查询,分布式执行调度层会将所有算子全量下推至执行节点端执行,以下为全新执行架构的调度流程示例(以具体 SQL 查询为例):

    KaiwuDB 3.0 分布式执行流程

    总结与展望

    综上,KaiwuDB 分布式执行引擎通过一系列核心优化举措,系统性破解了传统架构的多重瓶颈,构建起高效、稳定、可扩展的分布式执行体系,为高并发、大规模时序数据及多模数据分析业务提供了坚实的技术支撑。

    • 统一引擎架构适配 AP 场景

    通过全算子下推、BRPC 统一通信及 Pipeline 标准化调度机制,有效突破传统架构的性能与扩展性约束,可稳定支撑未来高并发、大规模分析型处理 AP 场景的查询负载需求。

    • 核心性能实现跨越式提升

    依托计算全量下推、统一编码规范及 BRPC 零转换传输技术,显著降低冗余数据传输及编解码开销;借助 Block Filter 预过滤机制,进一步提升海量数据处理效率与 CPU 资源利用率,优化系统资源配置。

    • 降低系统复杂度

    明确管理节点(ME)的调度职责、根执行节点的结果汇总职责及普通执行节点的计算职责边界,降低模块间耦合度,可快速定位问题节点及流水线阶段(Stage),提升 Debug 的效率与精准性。

    • 分布式处理能力全面升级

    以 Pipeline 流水线调度与 Block Filter 预过滤机制保障核心性能输出,依托统一架构设计提升系统可维护性与可扩展性,通过算子落盘优化策略改善存储 I/O 资源利用率,全面支撑复杂大规模业务场景的稳定运行需求。

    未来,KaiwuDB 将基于现有架构持续深化技术迭代,聚焦复杂业务场景的功能完善,推动引擎向更智能、更可靠、更贴合用户核心业务需求的方向演进,助力业务实现数据价值的高效挖掘与转化。

    作者:青瑭、聪言

    背景与挑战

    行业背景:Agent 工具生态迈向规模化

    随着 AI Agent 在企业场景中的深度应用,开发者普遍为 Agent 配置大量工具——从天气查询、地图导航,到数据库接口、内部 API 等,以支撑复杂任务的执行。然而,当工具数量从几十个激增至上百甚至上千时,传统的“全量暴露”模式便难以为继:Agent 不仅要处理冗长的工具列表,还容易选错工具、响应变慢、调用成本飙升。如何让 Agent 在海量工具中快速、准确地选出真正需要的那几个,既决定了任务能否顺利完成,也直接影响系统的运行成本与响应效率。

    AgentScope Java 框架作为面向生产级智能体的开源开发框架,致力于为 Java 开发者提供高内聚、低耦合、可扩展的 Agent 构建能力。面对日益膨胀的工具库,我们期望不再把所有工具一股脑塞给 Agent,而是按需、精准、安全地动态供给——这才是大规模 Agent 落地的关键所在。

    企业级 Agent 工具管理的核心挑战

    尽管 Agent 开发框架 AgentScope Java 提供了灵活的工具集成机制,但在真实生产环境中,工具规模扩大反而带来“越强越笨”的悖论。主要体现在以下六大维度:

    • Prompt 膨胀,上下文资源被严重挤占:每个工具需在 Prompt 中声明名称、描述与参数 Schema。工具越多,输入越长,迅速耗尽 LLM 的上下文窗口,限制任务复杂度。
    • 推理成本不可控:冗长 Prompt 直接推高 Token 消耗,在高频调用或大规模部署场景下,LLM 调用费用呈指数级增长。
    • 工具选择准确率下降:面对功能相近或无关的工具列表,大模型易混淆误判,导致调用错误、任务失败或结果偏差。
    • 响应延迟增加:处理超长上下文显著延长 LLM 推理时间,拖慢端到端响应速度,损害用户体验。
    • 维护复杂度飙升:开发者需手动筛选“哪些工具对哪个任务可见”,难以实现动态、按需的工具分配,系统可扩展性受限。
    • 安全与稳定性风险加剧:无关甚至敏感工具若被误选执行,可能触发无效调用、数据污染,甚至引发安全漏洞。

    破局之道:构建语义驱动的智能工具精选体系

    要真正释放大规模工具库的价值,必须摒弃“全量推送”的粗放模式,转向一种以任务语义为中心、按需披露的现代化工具供给范式。

    为此,AgentScope 深度集成 Higress AI Gateway,推出 Higress 扩展插件——基于语义化工具检索,在运行时动态为 Agent 注入与其当前意图最匹配的工具子集,实现精准供给、轻量推理与安全隔离。

    这一机制本质上是一种面向智能体的渐进式能力披露:Agent 仅在需要时“看见”相关能力,既遵循最小权限原则,又显著降低上下文开销与决策噪声,从而全面提升系统的可扩展性、可观测性与鲁棒性。

    AgentScope Java Higress 扩展:智能工具精选

    核心价值

    Higress 源自阿里巴巴内部,是一款开源的云原生 API 网关, 将流量网关、微服务网关、安全网关三合一。在 AI 时代,Higress 演进为 AI 原生网关的技术底座,将 LLM 调用、SSE 流式响应、Agent 工具交互等 AI 工作负载视为一等公民。阿里云基于 Higress 推出了商业化 AI 网关,提供 99.99% 高可用保障,已稳定支撑通义千问、百炼、PAI 等阿里内部 AI 业务,并服务零一万物、FastGPT 等头部 AIGC 企业。

    AI 网关推出 MCP 语义检索功能,通过自然语言理解用户意图,动态返回最相关的工具子集,实现精准供给、降本增效、安全可控。核心能力包括:

    • 统一入口管理:所有 Agent 通过单一端点访问全部 MCP 工具,简化接入,集中治理。
    • 智能语义匹配:基于 Qwen 大模型与 AnalyticDB 向量数据库,Agent 仅需描述需求(如“查北京天气和附近餐厅”),即可自动匹配最相关工具。
    • 双阶段高精度检索:先通过 Qwen Embedding 向量召回候选工具,再可选使用 Qwen Rerank 模型精排,显著提升推荐准确性。
    • 实时元数据同步:MCP Server 的增删改操作自动触发工具元信息采集与向量化更新,确保检索结果与实际服务状态一致。
    • 一键开通,零配置上手:在控制台启用语义检索后,系统自动完成向量库初始化、模型配置、路由下发等全流程,即开即用。

    性能表现

    该语义检索功能使用 Weight 混合算法,与其他算法性能对比如下:

    1)准确性:

    image

    2)时间延迟:

    image

    根据准确性和时间延迟的性能比较,Weight 算法在准确度上微幅领先并且搜索时间控制在 350 毫秒以内,相比纯向量搜索仅增加约 30 毫秒延迟,满足实时检索需求。

    AgentScope Java Higress扩展

    因此,AgentScope Java 推出了 Higress 扩展,深度集成 Higress AI Gateway 的语义检索能力,覆盖 Agent 从工具发现、筛选、加载到调用的完整生命周期,全面支撑低成本、高精度、高效率的 Agent 运行。该插件提供以下能力:

    • 语义驱动的工具精选:用户可以告别硬编码工具列表,基于用户自然语言描述动态检索最相关工具。
    • 无缝集成 MCP 客户端:提供标准化、响应式的 Java 客户端,零侵入兼容现有 AgentScope 生态。
    • 企业级可观测与安全:依托阿里云 AI Gateway,提供认证鉴权的安全能力。

    快速开始

    前提条件

    1. 创建包年包月或按量付费的阿里云 AI Gateway 实例:https://common-buy.aliyun.com/?commodityCode=apigateway_aipos...
    2. 在 AI Gateway 中注册 MCP 工具服务:https://help.aliyun.com/zh/api-gateway/ai-gateway/user-guide/...

    image

    1. 在 MCP 管理 > 语义检索页签中启用语义检索功能  

    image

    1. (可选)配置消费者认证,提升安全性

    使用 Higress 插件为 Agentscope Java Agent 添加工具

    1. 添加依赖

    <dependency>
        <groupId>io.agentscope</groupId>
        <artifactId>agentscope-extensions-higress</artifactId>
        <version>${agentscope.version}</version>
    </dependency>

    2. 启用语义工具搜索

    通过使用 toolsearch 方法,您可以指定召回的与描述最相关的 topK 个工具,以供 Agent 调用。

    // 构建带语义搜索的客户端
    HigressMcpClientWrapper higressClient =
                    HigressMcpClientBuilder.create("higress")
                            .streamableHttpEndpoint(HIGRESS_ENDPOINT)
                            // .sseEndpoint(HIGRESS_ENDPOINT + "/sse")  // Alternative: SSE transport
                            // .header("Authorization", "Bearer xxx")   // Optional: Add auth header
                            // .queryParam("queryKey", "queryValue")   // Optional: Add query param
                            .toolSearch("your agent description", 5) // Optional: Enable tool search
                            .buildAsync()
                            .block();
    // 2. Register with HigressToolkit
    Toolkit toolkit = new HigressToolkit();
    toolkit.registerMcpClient(higressClient).block();
    // 创建 Agent
    ReActAgent agent =
                    ReActAgent.builder()
                            .name("HigressAgent")
                            .sysPrompt(
                                    "You are a helpful assistant. Please answer questions concisely and"
                                            + " accurately.")
                            .model(
                                    DashScopeChatModel.builder()
                                            .apiKey(apiKey)
                                            .modelName("qwen-max")
                                            .stream(true)
                                            .enableThinking(false)
                                            .formatter(new DashScopeChatFormatter())
                                            .build())
                            .toolkit(toolkit)
                            .memory(new InMemoryMemory())
                            .build();

    完整示例见 agentscope-examples/HigressToolExample.java:https://github.com/agentscope-ai/agentscope-java/blob/main/agentscope-examples/quickstart/src/main/java/io/agentscope/examples/quickstart/HigressToolExample.java

    加入我们,共建 AgentScope Java、Higress 生态

    AgentScope Java 与 Higress 都是开放的开源项目,我们诚邀所有对 Agent 与 AI网关感兴趣的开发者参与共建!

    作者:青瑭、聪言

    背景与挑战

    行业背景:Agent 工具生态迈向规模化

    随着 AI Agent 在企业场景中的深度应用,开发者普遍为 Agent 配置大量工具——从天气查询、地图导航,到数据库接口、内部 API 等,以支撑复杂任务的执行。然而,当工具数量从几十个激增至上百甚至上千时,传统的“全量暴露”模式便难以为继:Agent 不仅要处理冗长的工具列表,还容易选错工具、响应变慢、调用成本飙升。如何让 Agent 在海量工具中快速、准确地选出真正需要的那几个,既决定了任务能否顺利完成,也直接影响系统的运行成本与响应效率。

    AgentScope Java 框架作为面向生产级智能体的开源开发框架,致力于为 Java 开发者提供高内聚、低耦合、可扩展的 Agent 构建能力。面对日益膨胀的工具库,我们期望不再把所有工具一股脑塞给 Agent,而是按需、精准、安全地动态供给——这才是大规模 Agent 落地的关键所在。

    企业级 Agent 工具管理的核心挑战

    尽管 Agent 开发框架 AgentScope Java 提供了灵活的工具集成机制,但在真实生产环境中,工具规模扩大反而带来“越强越笨”的悖论。主要体现在以下六大维度:

    • Prompt 膨胀,上下文资源被严重挤占:每个工具需在 Prompt 中声明名称、描述与参数 Schema。工具越多,输入越长,迅速耗尽 LLM 的上下文窗口,限制任务复杂度。
    • 推理成本不可控:冗长 Prompt 直接推高 Token 消耗,在高频调用或大规模部署场景下,LLM 调用费用呈指数级增长。
    • 工具选择准确率下降:面对功能相近或无关的工具列表,大模型易混淆误判,导致调用错误、任务失败或结果偏差。
    • 响应延迟增加:处理超长上下文显著延长 LLM 推理时间,拖慢端到端响应速度,损害用户体验。
    • 维护复杂度飙升:开发者需手动筛选“哪些工具对哪个任务可见”,难以实现动态、按需的工具分配,系统可扩展性受限。
    • 安全与稳定性风险加剧:无关甚至敏感工具若被误选执行,可能触发无效调用、数据污染,甚至引发安全漏洞。

    破局之道:构建语义驱动的智能工具精选体系

    要真正释放大规模工具库的价值,必须摒弃“全量推送”的粗放模式,转向一种以任务语义为中心、按需披露的现代化工具供给范式。

    为此,AgentScope 深度集成 Higress AI Gateway,推出 Higress 扩展插件——基于语义化工具检索,在运行时动态为 Agent 注入与其当前意图最匹配的工具子集,实现精准供给、轻量推理与安全隔离。

    这一机制本质上是一种面向智能体的渐进式能力披露:Agent 仅在需要时“看见”相关能力,既遵循最小权限原则,又显著降低上下文开销与决策噪声,从而全面提升系统的可扩展性、可观测性与鲁棒性。

    AgentScope Java Higress 扩展:智能工具精选

    核心价值

    Higress 源自阿里巴巴内部,是一款开源的云原生 API 网关, 将流量网关、微服务网关、安全网关三合一。在 AI 时代,Higress 演进为 AI 原生网关的技术底座,将 LLM 调用、SSE 流式响应、Agent 工具交互等 AI 工作负载视为一等公民。阿里云基于 Higress 推出了商业化 AI 网关,提供 99.99% 高可用保障,已稳定支撑通义千问、百炼、PAI 等阿里内部 AI 业务,并服务零一万物、FastGPT 等头部 AIGC 企业。

    AI 网关推出 MCP 语义检索功能,通过自然语言理解用户意图,动态返回最相关的工具子集,实现精准供给、降本增效、安全可控。核心能力包括:

    • 统一入口管理:所有 Agent 通过单一端点访问全部 MCP 工具,简化接入,集中治理。
    • 智能语义匹配:基于 Qwen 大模型与 AnalyticDB 向量数据库,Agent 仅需描述需求(如“查北京天气和附近餐厅”),即可自动匹配最相关工具。
    • 双阶段高精度检索:先通过 Qwen Embedding 向量召回候选工具,再可选使用 Qwen Rerank 模型精排,显著提升推荐准确性。
    • 实时元数据同步:MCP Server 的增删改操作自动触发工具元信息采集与向量化更新,确保检索结果与实际服务状态一致。
    • 一键开通,零配置上手:在控制台启用语义检索后,系统自动完成向量库初始化、模型配置、路由下发等全流程,即开即用。

    性能表现

    该语义检索功能使用 Weight 混合算法,与其他算法性能对比如下:

    1)准确性:

    image

    2)时间延迟:

    image

    根据准确性和时间延迟的性能比较,Weight 算法在准确度上微幅领先并且搜索时间控制在 350 毫秒以内,相比纯向量搜索仅增加约 30 毫秒延迟,满足实时检索需求。

    AgentScope Java Higress扩展

    因此,AgentScope Java 推出了 Higress 扩展,深度集成 Higress AI Gateway 的语义检索能力,覆盖 Agent 从工具发现、筛选、加载到调用的完整生命周期,全面支撑低成本、高精度、高效率的 Agent 运行。该插件提供以下能力:

    • 语义驱动的工具精选:用户可以告别硬编码工具列表,基于用户自然语言描述动态检索最相关工具。
    • 无缝集成 MCP 客户端:提供标准化、响应式的 Java 客户端,零侵入兼容现有 AgentScope 生态。
    • 企业级可观测与安全:依托阿里云 AI Gateway,提供认证鉴权的安全能力。

    快速开始

    前提条件

    1. 创建包年包月或按量付费的阿里云 AI Gateway 实例:https://common-buy.aliyun.com/?commodityCode=apigateway_aipos...
    2. 在 AI Gateway 中注册 MCP 工具服务:https://help.aliyun.com/zh/api-gateway/ai-gateway/user-guide/...

    image

    1. 在 MCP 管理 > 语义检索页签中启用语义检索功能  

    image

    1. (可选)配置消费者认证,提升安全性

    使用 Higress 插件为 Agentscope Java Agent 添加工具

    1. 添加依赖

    <dependency>
        <groupId>io.agentscope</groupId>
        <artifactId>agentscope-extensions-higress</artifactId>
        <version>${agentscope.version}</version>
    </dependency>

    2. 启用语义工具搜索

    通过使用 toolsearch 方法,您可以指定召回的与描述最相关的 topK 个工具,以供 Agent 调用。

    // 构建带语义搜索的客户端
    HigressMcpClientWrapper higressClient =
                    HigressMcpClientBuilder.create("higress")
                            .streamableHttpEndpoint(HIGRESS_ENDPOINT)
                            // .sseEndpoint(HIGRESS_ENDPOINT + "/sse")  // Alternative: SSE transport
                            // .header("Authorization", "Bearer xxx")   // Optional: Add auth header
                            // .queryParam("queryKey", "queryValue")   // Optional: Add query param
                            .toolSearch("your agent description", 5) // Optional: Enable tool search
                            .buildAsync()
                            .block();
    // 2. Register with HigressToolkit
    Toolkit toolkit = new HigressToolkit();
    toolkit.registerMcpClient(higressClient).block();
    // 创建 Agent
    ReActAgent agent =
                    ReActAgent.builder()
                            .name("HigressAgent")
                            .sysPrompt(
                                    "You are a helpful assistant. Please answer questions concisely and"
                                            + " accurately.")
                            .model(
                                    DashScopeChatModel.builder()
                                            .apiKey(apiKey)
                                            .modelName("qwen-max")
                                            .stream(true)
                                            .enableThinking(false)
                                            .formatter(new DashScopeChatFormatter())
                                            .build())
                            .toolkit(toolkit)
                            .memory(new InMemoryMemory())
                            .build();

    完整示例见 agentscope-examples/HigressToolExample.java:https://github.com/agentscope-ai/agentscope-java/blob/main/agentscope-examples/quickstart/src/main/java/io/agentscope/examples/quickstart/HigressToolExample.java

    加入我们,共建 AgentScope Java、Higress 生态

    AgentScope Java 与 Higress 都是开放的开源项目,我们诚邀所有对 Agent 与 AI网关感兴趣的开发者参与共建!

    本文首发于 Aloudata 官方技术博客:《列级血缘为何在 EAST 报送中“对不准”?算子级解析的降维打击》转载请注明出处。

    摘要:在金融监管报送(如 EAST)场景中,传统列级血缘因 SQL 解析精度低(<80%)、无法处理复杂逻辑,导致指标口径追溯不全、人工盘点耗时数月。本文深入剖析了列级血缘的技术局限,并介绍了以算子级血缘为核心的新范式。通过 AST 深度解析、行级裁剪和白盒化口径提取等技术,算子级血缘将解析准确率提升至 >99%,实现监管指标“一键溯源”与自动化盘点,为数据治理和 DataOps 流程提供精准的溯源基座。

    在金融监管报送(如 EAST、1104)领域,数据血缘的准确性直接关系到合规风险与运营效率。传统列级血缘技术因解析精度不足,已成为指标口径“对不准”、人工盘点“盘不动”的症结所在。本文将对比分析列级血缘的固有缺陷,并深入解读以算子级血缘(Operator-level Lineage) 为核心的技术新范式,如何通过 >99% 的解析准确率与行级裁剪能力,为监管报送构建可靠的自动化数据溯源基座。

    一、核心痛点:EAST 报送中的数据溯源困局

    金融监管指标背后是跨越数仓多层(ODS、明细层、汇总层、报表层)的复杂加工链路,涉及大量 SQL 转换、存储过程及临时表处理。传统数据血缘(表级/列级)在此场景下普遍失效,具体表现为:

    1. 盘点效率低下:面对成千上万的监管指标,数据团队需投入数周至数月进行人工“扒代码”和访谈,成本高昂。
    2. 追溯结果不可靠:行业反馈显示,开源列级血缘工具对 Hive SQL 的解析准确率通常低于 70%,近三分之一的依赖关系错误或缺失,为合规埋下隐患。
    3. 变更风险失控:无法精准评估上游字段或逻辑变更对下游报送指标的影响,导致“牵一发而动全身”,易引发数据错误或报送延误。

    二、技术剖析:列级血缘为何“力不从心”?

    列级血缘的局限源于其技术原理,它通常基于正则匹配或浅层语法分析,只能识别“A 表的 X 列出现在 B 表 Y 列的 SELECT 语句中”,但无法理解其间的计算逻辑。这导致三大硬伤:

    • 解析精度天花板低:对包含 CASE WHEN、窗口函数、多层嵌套子查询的复杂 SQL 解析能力弱,准确率普遍低于 80%。
    • 无法穿透黑盒逻辑:对 DB2、Oracle 的 PL/SQL 存储过程、动态 SQL、临时表加工等场景几乎无法解析,造成血缘链路断点。
    • 影响分析过度泛化:缺乏对 WHEREJOIN ON 等过滤条件的识别。例如,一个仅影响特定分行的源数据变更,会触发所有相关下游任务的告警,噪音率可超过 80%。
    对比维度传统列级血缘算子级血缘 (如 Aloudata BIG)
    解析粒度列级,仅知“从哪列到哪列”算子级,可知“经过怎样的计算(过滤、连接、聚合)从哪列到哪列”
    解析准确率通常 < 80%,复杂 SQL 下更低> 99%,基于 AST 深度解析
    复杂场景支持弱,难以处理存储过程、动态 SQL、临时表强,深度支持 DB2、GaussDB 等 PL/SQL,穿透临时表
    影响分析精度粗粒度,易泛化,噪音大行级裁剪,精准识别过滤条件,聚焦真实影响范围
    口径提取需人工拼接多层代码白盒化口径提取,自动生成可读、可验证的最终加工逻辑

    三、新范式:算子级血缘的核心原理与“降维打击”

    算子级血缘实现了技术范式的跃迁。它深入 SQL 内部,将数据加工过程解析为最细粒度的算子(Operator)序列,如 Filter(过滤)、Join(连接)、Aggregation(聚合)等。结合以下核心技术,实现对传统方法的“降维打击”:

    1. 行级裁剪 (Row-level Pruning):精准识别 SQL 中的过滤条件(WHEREJOIN ON)。当上游数据变更时,系统能自动判断变更是否落入下游任务所关心的数据子集内,从而剔除无关的上游分支,使影响评估范围平均降低 80% 以上,实现精准风险预警。
    2. 复杂场景全覆盖:基于对多 SQL 方言(Hive, Spark, Oracle, DB2 等)及 PL/SQL 的深度解析能力,可穿透存储过程、动态 SQL、临时表等传统黑盒,构建端到端的完整血缘链路。
    3. 白盒化口径提取:针对跨多层加工的监管指标,系统能自动将沿途的所有 SELECTCASE WHEN、函数调用等逻辑,“压缩”成一段从最终指标反向追溯到源字段的、可读性极高的“加工口径”,直接替代人工“扒代码”。

    四、实践验证:算子级血缘在金融场景的落地成效

    该技术已在多家金融机构的 EAST 报送场景中得到验证:

    浙江农商联合银行:通过部署具备算子级血缘能力的 Aloudata BIG 平台,实现了监管指标溯源人效提升 20 倍,全量指标口径盘点从数月缩短至 8 小时;对核心 DB2 存储过程的解析准确率达到 99%,攻克技术难关;自动生成符合监管要求的指标加工口径报告。

    共性价值:算子级血缘实现的“一键溯源”能力,不仅大幅提升合规效率,更将管理动作从事后补救转向事前防控与事中协同,精准管控上游变更对下游报送指标的影响。

    五、实施路径:构建 EAST 报送的数据溯源基座

    企业可遵循以下三步,系统性构建高可靠的数据溯源能力:

    1、基座先行:优先接入核心数仓(Hive, Oracle)、ETL/ELT 平台(DataStage, Kettle)及 BI 系统,快速构建覆盖“入仓->加工->服务”全链路的算子级血缘图谱。

    2、场景驱动:选择 EAST、1104 等具体监管报表作为首场景,利用“一键溯源”快速验证价值,赢得业务与合规部门支持。

    3、流程嵌入:将血缘能力深度嵌入 DataOps 与合规流程:

    • 研发侧:代码提交前自动进行变更影响分析,识别波及的报送指标。
    • 运维侧:发生数据异常时,利用血缘图谱快速定位根因。
    • 合规侧:建立基于血缘的自动化口径报告与审计机制。

    六、常见问题(FAQ)

    Q1: 列级血缘和算子级血缘的核心区别是什么?

    最本质的区别是解析粒度。列级血缘仅知道字段的流向,而算子级血缘能还原完整的计算逻辑,例如“A.X 列经过 WHERE 过滤后,与 C 表 Z 列 LEFT JOIN,再 GROUP BY 生成 B.Y 列”,实现加工过程的白盒化。

    Q2: 对复杂的存储过程和嵌套查询,算子级血缘解析效果如何?

    这是算子级血缘的核心优势。它针对 DB2、Oracle 等 PL/SQL 存储过程、动态 SQL 及多层嵌套查询进行了深度优化,解析准确率可超过 99%,能有效穿透这些传统血缘工具的解析盲区。

    Q3: 引入算子级血缘对 EAST 报送的具体价值是什么?

    主要体现在三方面:效率提升(盘点从数月缩短到几小时)、准确性保障(>99% 解析准确率确保口径完整正确)、风险防控(精准评估上游变更影响,实现主动预警)。

    核心要点

    1. 精度是核心:传统列级血缘低解析精度(<80%)是 EAST 报送“对不准”的根源。
    2. 算子级是解药:算子级血缘通过 AST 深度解析 Filter、Join 等算子,实现 >99% 的解析准确率。
    3. 行级裁剪提效:行级裁剪技术能精准识别数据子集,将变更影响分析范围平均降低 80% 以上。
    4. 案例验证价值:在标杆案例中,算子级血缘已将监管指标盘点从数月缩短至 8 小时,人效提升 20 倍。
    5. 构建溯源基座:企业应优先建设全链路算子级血缘,并以此驱动 DataOps 与自动化合规流程。

    再次提醒:本文更详细的图表与案例细节,请访问Aloudata官方技术博客阅读原文:https://ai.noetl.cn/knowledge-base/why-column-level-lineage-m...

    买了年费的 GLM Lite 套餐,现在根本是用不了的情况,白天动不动就是限流不让用。想弃用了,换成 minimax 试试,这次不开年费了。想开一个月体验一下,有没有真实用户反馈一下

    随着中国在国际中的地位越来越高,国内企业也发展得越来越全面,很多国内企业都将目光瞄向了国外市场,尤其是近年来的电子签市场,北京安证通、E签宝、法大大等国内优秀电子签章企业纷纷走出国门,开始布局海外市场,但是国内和海外有关电子签章的侧重点和应用场景都不尽相同,我们还得正确看待。那我们拥有海外分公司并且有海外业务的各企业在选择相关海外版电子签章产品时,要了解哪些情况呢?我们简单的来看看。

    1. 法律基础与合规要求

    1) 国内电子签章

    Ø 核心法律:《中华人民共和国电子签名法》(2005年实施,2020年修订),规定“可靠电子签名”与手写签名或盖章具有同等法律效力。

    Ø 重点要求:强调“实名认证”和“技术可控”,要求通过权威第三方认证机构(CA)颁发数字证书,并采用符合国密标准的加密技术。

    Ø 行业规范:金融、政务、司法等领域有专门规定(如《证券法》对电子合同的要求)。

    2) 海外电子签章

    区域性法规:

    Ø 欧盟:eIDAS法规(2014年)将电子签名分为简单签名(SES)、高级签名(AES)、合格签名(QES),其中QES在欧盟内跨境通用,法律效力最强。

    Ø 美国:ESIGN法案(2000年)和UETA法案承认电子签名的普遍合法性,但各州可能存在细节差异。

    Ø 国际兼容性:更注重跨境互认(如eIDAS的QES在成员国间自动认可),部分国家接受云签名或生物特征签名。

    Ø 灵活性:普通场景(如商务邮件)可能无需严格CA认证,但高价值合同需强化验证。

    1. 技术标准与安全性

    1) 国内

    Ø 强制国密算法:要求使用SM2/SM3/SM4等国密算法,证书需由国内CA机构颁发。

    Ø 本地化部署:政务、国企场景通常要求服务器部署在国内,支持私有化部署。

    Ø 身份认证:需对接公安部、工商系统或运营商实名认证。

    2) 海外

    Ø 国际通用标准:普遍支持RSA、ECDSA等国际算法,兼容PKI体系。

    Ø 技术中立性:部分法域(如美国)不限定具体技术,更注重“意图签署”和“过程可追溯”。

    Ø 云签名普及:SaaS模式(如DocuSign、Adobe Sign)广泛采用,支持跨平台协作。

    1. 应用场景侧重

    1) 国内

    Ø 政务与国企主导:广泛应用于电子政务、政府采购、银行开户、房地产交易等强监管场景。

    Ø 行业渗透深:司法存证、医疗病历、电子发票等与国家级平台(如法院区块链、税务系统)对接。

    Ø B2B为主:企业间合同签署普及率高,个人使用逐步上升(如租房、借款合同)。

    2) 海外

    Ø 市场化驱动:企业自发应用较多,尤其在跨境贸易、人力资源、房地产等领域。

    Ø C端场景广泛:个人日常签约(如保险、网购协议)接受度高。

    Ø 创新场景:区块链签名、生物识别签名(如Apple ID签名)在部分国家被认可。

    1. 监管与司法实践

    1) 国内

    Ø 强监管模式:工信部、密码局、公安部等多部门监管,CA机构需持牌运营。

    Ø 司法存证配套:电子证据规则明确(如《最高人民法院在线诉讼规则》),要求与时间戳、区块链存证结合。

    2) 海外

    Ø 自律与司法并存:美国等普通法国家依赖判例积累,欧盟通过eIDAS建立统一框架。

    Ø 争议解决机制:服务商常提供审计日志、身份验证报告作为证据,部分国家允许电子公证。

    1. 跨境互认挑战

    1) 国内:跨境互认尚在探索,中国企业出海时需适应当地规则(如eIDAS的QES)。

    2) 海外:欧盟、新加坡等通过双边协议推动互认,但全球统一标准仍未形成

    引言:Claude 虽好,但你真的能用上吗?

    在当前席卷全球的“Vibe Coding”浪潮中,Anthropic 推出的 Claude 系列模型 + 终端工具 Claude Code,凭借极强的逻辑推理能力,成为了开发者眼中的“白月光”。但现实是残酷的:对于中国开发者而言,账号随时被封、海外信用卡支付遭拒、API 额度受限以及复杂的网络环境,构成了一道难以逾越的门槛。

    虽然最近国产编程模型不断发力,Claude Code + GLM-4.7的表现非常出色,但面对复杂问题,Claude系列模型依然完胜。难道我们只能眼馋Claude全家桶的编程体验吗?

    作为一名追求极致生产力的开发者,我发现了一个绝佳的完美替代方案:OpenCode + GitHub Copilot。这个组合不仅能让你享受如 GLM-4.7 一样的性价比,还能更方便的使用 Claude 的顶级模型。

    Claude Code 的开源免费平替:OpenCode

    想要复刻 Claude Code 的体验,核心在于拥有一个强大的“AI 编程代理(Coding Agent)”。OpenCode 正是目前社区中最接近、甚至在某些维度超越 Claude Code 的工具。

    OpenCode

    OpenCode 的强大源于其深厚的社区根基,其核心数据足以证明其统治力:

    • 高社区认可度: 在 GitHub 上拥有超过 90,000 Stars、由 600 多名贡献者共同维护,并积累了超过 7,500 次 commits。
    • 庞大的用户基数: 每月有超过 150 万名开发者活跃在该工具链中。
    • 全场景覆盖: 不同于仅限终端的工具,OpenCode 提供了 Terminal、IDE 插件以及支持 macOS/Windows/Linux 的 Desktop(桌面端)应用。

    更硬核的是,OpenCode 秉持隐私优先理念,不存储任何代码或上下文数据,且能自动加载适配 LLM 的 LSP(语言服务协议)。这种自动化的环境感知,让它在执行复杂重构任务时,比手动配置的工具更具“专家感”。

    隐藏的顶级模型分发器:GitHub Copilot

    很多开发者忽略了一个事实:GitHub Copilot 已不再仅仅是一个补全插件,它正进化为一个聚合顶级模型的低成本分发平台。

    通过 OpenCode 提供的 “Log in with GitHub” 桥接功能,开发者可以直接调用 Copilot 账户下的模型能力。这意味着你不需要折腾海外信用卡去充值 Anthropic API,只需一个 GitHub 账号,就能实现对顶级模型的“一键接入”。

    在 Copilot 计划中,你可以访问到的顶级模型矩阵(严格遵循来源名称)包括:

    • Anthropic 系列: Claude Sonnet 4.5/4、Claude Opus 4.1/4.5、Claude Haiku 4.5。
    • OpenAI 系列: GPT-5、GPT-5 mini、GPT-5.1/5.2、GPT-4.1 以及多款 GPT-5-Codex 预览版。
    • Google 系列: Gemini 2.5 Pro、Gemini 3 Pro/Flash (Preview)。
    • 新锐力量: xAI Grok Code Fast 1 以及 Raptor mini (Preview)。

    性价比之王:每月 $10 搞定顶级模型访问

    这套方案最具杀伤力的地方在于其经济逻辑。直接订阅 ChatGPT Plus 或直接使用 Claude API 的成本极高,而 GitHub Copilot Pro 的定价策略对独立开发者极其友好。

    GitHub Copilot

    • 月费仅需 $10: 即可享受针对 GPT-5 mini 的无限量聊天与 Agent 模式请求,以及无限量的代码补全。
    • 高级请求配额: Copilot Pro 计划每月提供 300 次 Premium requests(高级请求),用于调用 Claude Opus 4.5 或 GPT-5 等昂贵的旗舰模型;如果你是重度用户,升级至 Pro+ 计划,该配额将飙升至 1500 次。
    • 完全免费通道: 针对经认证的学生、教师及流行开源项目维护者,上述所有能力均为 $0/月。

    GitHub Copilot

    这种“小钱办大事”的模式,完美解决了“复杂场景下 Opus 模型最有效”但“直接接入成本高”的矛盾。

    总结

    OpenCode + GitHub Copilot 的组合比起其他平替方案而言,从工具、模型、价格等多个维度都是最优选择。所以,强烈推荐尝试一下这个编码组合。下面是这两个工具的官方地址,想要试试的可以直接前往:

    最后,做个小调研,目前你正在用什么工具和模型套件呢?留言区聊一聊吧。更多关于Vibe Coding的内容分享也可以关注我的博客: 程序猿DD