2026年2月

近日,OpenAtom openKylin(简称"openKylin")RISC-V SIG(特别兴趣小组)完成一项重要适配验证工作,依托超睿科技UR-DP1000 RISC-V芯片,结合KVM虚拟化技术,成功将开源云计算管理平台OpenStack完整移植至RISC-V架构。此次适配仅完成基础运行验证,实现了Ubuntu、Debian、openKylin等主流Linux发行版的稳定启动与运行,同时可借助DevStack搭建小规模测试环境,后续实际生产能力仍需进一步验证优化,为RISC-V架构在云计算领域的后续探索筑牢基础。

RISC-V云计算生态的待解难题
当前,RISC-V架构在硬件领域的发展速度不断加快,在嵌入式、消费电子等场景的应用逐渐铺开,但在云计算这一关键领域,生态短板始终制约其规模化落地。作为全球主流的开源云管理平台,OpenStack的适配缺失,导致RISC-V架构难以搭建起完整的云基础设施服务体系。此前,RISC-V架构缺乏成熟的虚拟化调度框架与云平台适配方案,开发者无法像在X86或ARM架构上一样,便捷地部署云服务相关能力。同时,硬件与软件层面的适配问题相互交织,让RISC-V云原生应用的开发与部署流程复杂且成本较高,难以在数据中心、边缘云等场景实现广泛应用。超睿科技UR-DP1000芯片的出现,为解决上述难题提供了可靠的硬件支撑。这款RISC-V处理器具备原生虚拟化支持能力,能够为OpenStack的移植与基础运行验证提供稳定且适配的硬件运行环境。

适配验证成果:实现软硬件基础协同运行
openKylin RISC-V SIG团队此次的工作,核心聚焦于硬件适配、虚拟化部署、云平台兼容三大方向,完成了全链路的基础运行验证。1.  KVM虚拟化层与硬件的基础适配运行团队基于超睿科技UR-DP1000芯片的虚拟化特性,完成了KVM/riscv模块的基础适配部署。通过对虚拟化相关机制的调试与优化,打通了芯片硬件与虚拟化层之间的运行链路,确保KVM虚拟化技术能够在该RISC-V芯片上稳定发挥基础作用,为上层云平台的基础运行提供了可靠的虚拟化环境,相关性能与生产适配性仍需进一步测试。2.  OpenStack与主流Linux发行版的基础兼容运行团队顺利完成OpenStack核心组件的RISC-V架构移植工作,解决了移植过程中出现的软件依赖与系统兼容问题,实现了基础功能的正常运行。移植后的OpenStack可兼容Ubuntu 24.04、Debian 13、openKylin 2.0等主流Linux发行版的虚拟机镜像,用户可通过标准OpenStack API开展实例创建、网络配置等基础操作,操作流程与在X86平台上保持一致,同时可借助DevStack快速搭建小规模测试环境,暂未验证其大规模生产场景的承载能力。

未来展望:持续优化,探索生产级适配可能
openKylin RISC-V SIG团队表示,此次OpenStack移植及基础运行验证的完成,只是RISC-V云计算生态探索的起点,目前仅实现基础运行能力,实际生产能力仍有待进一步验证与优化。接下来,团队将与超睿科技、RISC-V国际基金会等合作伙伴深化协作,推进两项重点工作。
1.推进上游社区融合:计划在未来3-6个月内,将RISC-V架构下的OpenStack适配代码、KVM相关优化成果贡献至上游社区,推动OpenStack官方正式支持riscv64架构,同时参与RISC-V虚拟化技术标准的制定,减少生态碎片化问题,为后续生产级适配奠定基础。
2.开展生产级适配测试:针对边缘云、工业云等特色场景,逐步开展基于超睿UR-DP1000芯片、OpenStack与KVM技术的生产级适配测试,完善资源调度策略,验证平台的规模化部署能力与安全隔离水平,逐步推进场景化解决方案的落地探索。
团队的最终目标是,联合各方合作伙伴,逐步完善RISC-V架构下的云计算生态,持续验证并提升相关技术的生产适配能力,让全球RISC-V用户能够便捷地探索云计算服务的应用可能,推动RISC-V架构从小众技术领域,逐步走向主流基础设施行列,为全球开源云生态的发展注入新动力。

立即体验:RISC-V OpenStack基础运行测试指南
为方便全球RISC-V开发者共同参与探索与优化,openKylin社区已开放移植后的OpenStack源码与部署脚本,供开发者开展基础运行测试,相关生产级应用请谨慎使用。开发者可按照以下步骤快速体验:
1.环境准备:准备搭载超睿UR-DP1000芯片的硬件平台,并安装openKylin 2.0 RISC-V版本操作系统。
2.下载部署脚本git clone https://gitee.com/openkylin/devstack.git
3.一键部署cd devstack#部署前请务必查看README./stack.sh
4.测试验证:部署完成后,通过浏览器访问OpenStack Dashboard,即可开展基础的虚拟机实例创建和管理测试。

关于OpenStack和Devstack
OpenStack:是一个庞大的开源软件集合(由 Nova, Neutron, Cinder 等几十个项目组成),用于管理数据中心的所有资源(计算、存储和网络)。
DevStack:实际上是一套脚本(Shell Scripts),它的唯一目的就是从源代码快速克隆并安装一个“最小化”的 OpenStack 环境。

关于openKylin RISC-V SIG
openKylin RISC-V SIG专注于RISC-V架构的开源软件生态建设,工作范围涵盖操作系统移植、工具链开发、云平台适配等核心领域,致力于联合全球开发者共同探索RISC-V技术的应用可能。社区欢迎全球范围内的RISC-V开发者、硬件厂商、科研机构加入,共同推动RISC-V技术的创新与落地。
SIG主页:https://gitee.com/openkylin/community/tree/master/sig/RISC-V

还有一些细节正在处理, 支持输入 github 仓库地址来检索目录下的 markdown 文件并展示, 做了连续加载和加入书架的一些操作简化

如果以后 V 友在这节点发布连载小说, 就可以 at 我, 或者我提供一个工具, 让一个自动化工具扫描 V 友提供的小说名, 然后根据规则拆分帖子, 导出一个 markdown 文件到 github 仓库中, 每一本小说都是一个文件夹.

这样其他 V 友就可以通过我做的这个工具来阅读在这个节点下发布的所有上架的小说了, 解决了帖子太分散, 不能连贯阅读的缺憾

等我优化完细节, 试用一段时间之后, 会开源这个小作品.

另附一个因为这个阅读器延伸出来的小项目截图, 打算用这个渡过前期这个节点的小说资源太少的尴尬时期:

ps: AI 生成小说实在是太耗 token 了

🌟 TrendForge 每日精选 - 发现最具潜力的开源项目
📊 今日共收录 12 个热门项目,涵盖 50 种编程语言

🌐 智能中文翻译版 - 项目描述已自动翻译,便于理解

🏆 今日最热项目 Top 10

🥇 thedotmack/claude-mem

项目简介: Claude Code插件可自动记录编码会话中Claude的全部操作,通过AI技术进行压缩处理,并将相关上下文智能注入后...

今日新增: 2638 | 总星数: 22452 | 语言: TypeScript

项目截图:

thedotmack/claude-mem

https://github.com/thedotmack/claude-mem


🥈 openai/skills

项目简介: Codex 技能目录

今日新增: 746 | 总星数: 3646 | 语言: Python

https://github.com/openai/skills


🥉 OpenBMB/ChatDev

项目简介: ChatDev 2.0:基于大语言模型的多智能体协作实现全流程开发

今日新增: 227 | 总星数: 29961 | 语言: Python

项目截图:

OpenBMB/ChatDev

https://github.com/OpenBMB/ChatDev


4. pedramamini/Maestro

项目简介: 智能体编排指挥中心

今日新增: 187 | 总星数: 1650 | 语言: TypeScript

项目截图:

pedramamini/Maestro

https://github.com/pedramamini/Maestro


5. Canner/WrenAI

项目简介: ⚡️ GenBI(生成式商业智能)支持使用自然语言查询任意数据库,可在数秒内生成精准的SQL(文本转SQL)、图表(文本...

今日新增: 89 | 总星数: 13897 | 语言: TypeScript

项目截图:

Canner/WrenAI

https://github.com/Canner/WrenAI


6. microsoft/qlib

项目简介: Qlib是一款面向AI的量化投资平台,其目标是从创意探索到生产部署的全流程,通过人工智能技术赋能量化研究。该平台支持多种...

今日新增: 83 | 总星数: 36521 | 语言: Python

项目截图:

microsoft/qlib

https://github.com/microsoft/qlib


7. LadybirdBrowser/ladybird

项目简介: 真正独立的网页浏览器

今日新增: 68 | 总星数: 58263 | 语言: C++

https://github.com/LadybirdBrowser/ladybird


8. disler/claude-code-hooks-mastery

项目简介: 主Claude代码钩子

今日新增: 47 | 总星数: 2351 | 语言: Python

项目截图:

disler/claude-code-hooks-mastery

https://github.com/disler/claude-code-hooks-mastery


9. nvm-sh/nvm

项目简介: Node 版本管理器 - 符合 POSIX 标准的 bash 脚本,用于管理多个活跃的 node.js 版本

今日新增: 35 | 总星数: 91244 | 语言: Shell

https://github.com/nvm-sh/nvm


10. likec4/likec4

项目简介: 通过代码生成的实时动态图表,实现软件架构的可视化、协作与持续演进。

今日新增: 29 | 总星数: 1421 | 语言: TypeScript

项目截图:

likec4/likec4

https://github.com/likec4/likec4


🌈 分语言热门项目

● C++ 最热项目

项目名称: LadybirdBrowser/ladybird

项目描述: 真正独立的网页浏览器

今日新增: 68 | 总数: 58263

地址: https://github.com/LadybirdBrowser/ladybird


项目名称: dail8859/NotepadNext

项目描述: Notepad++ 的跨平台重实现版本

今日新增: 37 | 总数: 13347

项目截图:

dail8859/NotepadNext

地址: https://github.com/dail8859/NotepadNext


项目名称: deskflow/deskflow

项目描述: 在多个计算机之间共享同一套键盘和鼠标。

今日新增: 34 | 总数: 23680

项目截图:

deskflow/deskflow

地址: https://github.com/deskflow/deskflow


● PowerShell 最热项目

项目名称: ScoopInstaller/Scoop

项目描述: Windows 命令行安装程序

今日新增: 10 | 总数: 23568

地址: https://github.com/ScoopInstaller/Scoop


项目名称: microsoft/Agents

项目描述: Microsoft 365 Agent SDK 简化了为 M365、Teams、Copilot St...

今日新增: 7 | 总数: 705

地址: https://github.com/microsoft/Agents


项目名称: microsoft/fabric-toolbox

项目描述: Fabric工具箱是由Fabric CAT提供的工具、加速器、脚本和示例存储库,旨在加速您在Micr...

今日新增: 5 | 总数: 659

地址: https://github.com/microsoft/fabric-toolbox


● Vue 最热项目

项目名称: dreamhunter2333/cloudflare_temp_email

项目描述: CloudFlare 免费临时域名邮箱 支持附件收发 IMAP SMTP TelegramBot

今日新增: 40 | 总数: 5930

项目截图:

dreamhunter2333/cloudflare_temp_email

地址: https://github.com/dreamhunter2333/cloudflare_temp_email


项目名称: CorentinTh/it-tools

项目描述: 专为开发者打造的便捷在线工具集合,拥有卓越的用户体验。

今日新增: 21 | 总数: 36877

项目截图:

CorentinTh/it-tools

地址: https://github.com/CorentinTh/it-tools


项目名称: Lissy93/dashy

项目描述: 🚀 可自托管的个人仪表板,包含状态检查、小组件、主题、图标包、UI编辑器及更多功能!

今日新增: 17 | 总数: 23901

项目截图:

Lissy93/dashy

地址: https://github.com/Lissy93/dashy


● Vim Script 最热项目

项目名称: junegunn/vim-plug

项目描述: 🌺 极简Vim插件管理器

今日新增: 5 | 总数: 35532

项目截图:

junegunn/vim-plug

地址: https://github.com/junegunn/vim-plug


项目名称: tpope/vim-fugitive

项目描述: fugitive.vim:一个强大到堪称非法的 Git 封装工具

今日新增: 4 | 总数: 21626

地址: https://github.com/tpope/vim-fugitive


项目名称: ggml-org/llama.vim

项目描述: LLM辅助代码/文本补全的Vim插件

今日新增: 1 | 总数: 1856

项目截图:

ggml-org/llama.vim

地址: https://github.com/ggml-org/llama.vim


● Shell 最热项目

项目名称: obra/superpowers

项目描述: Claude Code 超级能力:核心技能库

今日新增: 993 | 总数: 44435

地址: https://github.com/obra/superpowers


项目名称: automazeio/ccpm

项目描述: 基于GitHub Issues与Git工作树实现并行智能体执行的Claude Code项目管理系统。

今日新增: 387 | 总数: 6982

项目截图:

automazeio/ccpm

地址: https://github.com/automazeio/ccpm


项目名称: anthropics/claude-code

项目描述: Claude Code是一款基于终端的智能编程工具,它能理解您的代码库并通过自然语言命令执行常规任务...

今日新增: 351 | 总数: 64053

项目截图:

anthropics/claude-code

地址: https://github.com/anthropics/claude-code


● PHP 最热项目

项目名称: coollabsio/coolify

项目描述: 开源且可自行托管的Heroku/Netlify/Vercel替代方案。

今日新增: 34 | 总数: 50269

项目截图:

coollabsio/coolify

地址: https://github.com/coollabsio/coolify


项目名称: filamentphp/filament

项目描述: Laravel强大的开源UI框架 • 借助Livewire快速构建与部署管理后台及应用系统

今日新增: 27 | 总数: 29055

项目截图:

filamentphp/filament

地址: https://github.com/filamentphp/filament


项目名称: krayin/laravel-crm

项目描述: 面向中小企业和企业的免费开源 Laravel CRM 解决方案,提供完整的客户生命周期管理。

今日新增: 24 | 总数: 21104

项目截图:

krayin/laravel-crm

地址: https://github.com/krayin/laravel-crm


📈 今日趋势分析

最活跃语言: TypeScript(4个)、Python(4个)、C++(1个)

今日总获星: 4,180 颗星

平均获星: 348 颗星/项目

今日之星: thedotmack/claude-mem (2638)


📊 数据总览

指标数值
收录项目12
编程语言50
今日新增4,180 颗星
报告日期2026年02月04日
统计周期日报

TrendForge 致力于追踪全球开源项目动态,每日为开发者精选最具价值的 GitHub 项目。

数据来源: https://trendforge.devlive.top/

数据说明: 基于 GitHub 官方 API 数据统计,每日更新

翻译声明: 项目描述采用 AI 智能翻译,如有疏漏请以原文为准

报告生成于: 2026年02月05日

GitHub #开源项目 #技术趋势 #程序员 #软件开发

“我们坚信,开源是推动产品持续演进的关键引擎。尤其在探索 AI 原生场景的过程中,唯有与上下游生态和开发者并肩协作、共创共进,才能走得更远。” 1 月 31 日,在上海举办的 2026 OceanBase 社区嘉年华现场,OceanBase CTO 杨传辉表示。

社区嘉年华是 OceanBase 持续举办的年度品牌活动,至今已有三年,旨在构建开放共享的技术交流平台,链接全球开发者与行业伙伴。

本次活动吸引了 260 余位技术爱好者、开发者参与,通过主题演讲、圆桌对话、AI Coding 实战、社区开放麦等形式,呈现了 10 多场高质量分享,全面展现社区生态活力与技术创新。

开源 4 年累计下载破 10 万次

OceanBase 是一款 100% 自主研发的原生分布式数据库,长期坚持“应用驱动技术创新”的理念,并于 2021 年 6 月正式宣布开源。

OceanBase CTO 杨传辉指出:“底层软件是靠用出来的。谁来用?答案自然是开发者。”他强调,数据库作为数字基础设施,其发展必须与用户和生态共同成长。

OceanBase CTO 杨传辉

他公布了一组数据:自开源以来,OceanBase 全球累计下载量已突破 10 万次,部署节点规模达到数百万级别,并吸引了超过 1600 名外部贡献者参与到代码提交、文档完善及问题修复等共建工作中。

杨传辉表示,开发者是技术落地的重要推动力,也是构建创新生态的基石。这也是 OceanBase 在 2025 年开源首款 AI 原生混合搜索数据库 OceanBase seekdb 的原因。OceanBase seekdb 主打“开箱即用”,开发者仅需三行代码,即可快速构建知识库、智能体等 AI 应用,轻松应对百亿级多模数据检索。“我们目前仍处于探索阶段,期待更多年轻开发者加入,共同推进 AI 与数据库技术的融合。”

开源开放,生态共赢

“社区的每一次进步,都离不开开发者和共建者的支持。”OceanBase 开源生态负责人封仲淹表示。现场,他以“一路有你,OceanBase 社区嘉年华”为主题,分享了 OceanBase 的开源理念与未来规划。

OceanBase 开源生态负责人封仲淹

封仲淹提到,OceanBase 开源已步入第四年,“开源开放,生态共赢”不是一句简单的口号,而是长期坚持的理念。过去一年,在社区开发者的积极参与与生态伙伴的协同推动下,OceanBase 社区版已逐步构建起完善的企业级数据库能力。

截至目前,OceanBase 已联合 400 余家独立软件开发商,共同打造超过 1000 项联合解决方案,拥有 300 多家经销商伙伴及 30 余家交付合作伙伴,累计完成技术集成 1600 余项,持续赋能千行百业的数字化转型。

展望 2026 年,封仲淹表示,OceanBase 将继续深化与生态伙伴的合作,汇聚更多行业力量。一方面积极拥抱 AI 技术,持续建设开发者生态;另一方面坚定推进全球化战略,携手生态上下游伙伴,拓展更多应用场景,助力 OceanBase 走向更广阔的全球市场。

活动当天,OceanBase 还正式聘任 LangChain Ambassador 张海立、Xenera LLM Project Lead 伊洪、英伟达技术专家程治玮、武汉大学国家网络安全学院学生李子毅,以及上海爱可生信息技术股份有限公司的何文超为 OceanBase 年度社区大使。封仲淹表示,期待在全球化道路上与更多社区大使携手同行。同时,2025 OceanBase 社区年度 31 位版主也同步揭晓。

生态共聚:嘉宾共话 AI 数据底座建设

在 AI 时代,构建坚实的数据底座离不开广大开发者的共同参与和生态协作。本次活动邀请了来自不同技术社区的嘉宾,他们结合自身实践与行业思考,围绕 AI 数据底座的构建路径展开深度分享。OceanBase seekdb 作为 AI 原生混合搜索数据库,成为多位嘉宾演讲中的高频词汇。

RAGFlow CEO 张颖峰亲历了从传统搜索到 AI 时代的跨越。“从 RAG 到 Context Engine,构建 AI Agent 的数据基座”为题,进行了分享。

RAGFlow CEO 张颖峰

“在很多人看来,RAG 或许已是过时的技术,但我认为,他恰恰能够成为 AI 原生数据库所需的重要基础。”张颖峰指出,未来的 AI 原生数据库不应仅仅是模型的堆叠,而应以“强检索能力”为核心,构建能够统一管理知识、数据与工具的上下文引擎架构。在这一框架下,单一的 RAG 技术虽已难以应对复杂的交互场景,但可以演进为支持智能体(Agent)的统一上下文引擎,通过“检索前置+上下文优化”机制,实现对结构化与非结构化数据、以及交互记忆(Memory)的综合处理。

他强调,RAG 的本质在于检索。未来的上下文引擎应具备按需为智能体提供精准信息的能力,并借助 OceanBase seekdb AI 原生数据库,支持多模态、高频率的混合检索,最终推动技术实现从单一检索到全方位上下文服务的跨越。

Dify 开源生态负责人郑立

Dify 开源生态负责人郑立以“Dify x OceanBase seekdb”为主题,进行了分享。他通过具体实践案例,介绍了 Dify 的核心能力,以及在与 OceanBase seekdb 的合作中打造一体化数据库的实践路径。

郑立指出,大量多智能体架构强调 AI 的自主决策与执行,但实际业务推进依然高度依赖人工沟通、确认与协同,这使得“完全自动化”的智能体难以直接落地到真实流程中。为此,Dify 秉持“增强人类能力”的设计理念,让 AI 融入流程、提升效率,而非取代人的角色。

在与 OceanBase seekdb 的合作中,Dify 完成了从多数据库组合到事务一致的统一数据层的升级。一方面,基于 OceanBase seekdb,Dify 自 v1.10.1 起正式兼容 MySQL。另一方面,通过统一的存储与检索架构,OceanBase seekdb 可同时承担元数据库,并提供向量与关键词混合搜索(Hybrid Search)能力,形成开箱即用的一体化部署方案,进一步降低部署与运维复杂度。

DevRel and Founding Member of Second State Miley Fu

DevRel and Founding Member of Second State Miley Fu 则以“Building Cutomizable Agentic Voice AI: Echokit with OceanBase's Hybrid Search”为题进行了分享。

她介绍,WasmEdge 新开源了一款 Agentic Voice AI 产品——Echokit,其强调本地化部署能力,支持完全离线运行,兼顾隐私保护、可控性与高度定制化。在这一过程中,Echokit 已与 OceanBase seekdb 开展合作,将其作为本地数据库用于混合搜索。谈及选择 OceanBase seekdb 的理由,Miley Fu 表示,OceanBase seekdb 的三大优势:无 CDC 延迟、原生 AI 支持与良好 SQL 兼容性,能实现向量、元数据与文本的原子更新,并易于与智能体集成,非常适合实时语音 AI 场景。

Datawhale 内容生态负责人 Amy

来自 Datawhale 的内容生态负责人 Amy 则从社区与教育视角出发,以《让学习导向产业价值,Datawhale 的思考和探索》为题进行分享。作为成立七年的开源学习社区,Datawhale 始终致力于降低技术学习门槛,推动开发者通过实战掌握前沿技能。Amy 表示,这一理念与 OceanBase “开源开放,生态共赢”高度契合。Datawhale 计划与 OceanBase 共同建设 AI+数据库学习中心,降低数据库技术入门难度,助力构建健康、可持续的开发者生态。

从知识赋能到架构落地,开源工具正驱动 AI 应用走向成熟。

TEN Framework 发起人 & 架构师胡岳伟,在《TEN Framework:如何快速搭建带记忆的低延时对话式 AI Agent》演讲中,分享了在实时多模态智能体开发中的实践。

TEN Framework 发起人 & 架构师胡岳伟

TEN Framework 是一款面向实时多模态 AI Agent 的开源开发框架,已在 GitHub 获得近万星,具备真实落地能力。目前,TEN Framework 正在开发 Voice AI Agent 产品,并与 OceanBase PowerMem 开展合作,实现对话上下文的实时同步与记忆管理,为低延迟、高并发的对话场景提供底层支持。

从检索架构演进、一体化数据层构建,到语音 AI 落地、开源教育与框架赋能——五位嘉宾的分享,不仅呈现出 AI 数据底座建设的多元路径,也共同印证了开源协作、生态共建在推动技术走向成熟过程中的核心价值。

圆桌对谈:从 RAG 到 AI 专家共议未来方向

在嘉宾精彩分享之后,两场围绕 AI 时代关键议题的圆桌对话进一步激发了现场的思维碰撞。

在人工智能快速演进的大背景下,RAG 技术正成为推动 AI 能力落地的重要突破点,相关讨论也显得尤为深入。

活动现场,LangChain Ambassador 张海立、 RAGFlow CEO 张颖峰、FastGPT 负责人余金隆、Co-founder of Nowledge Labs 古思为以及 OceanBase AI 平台与应用部负责人吉剑南针对“从 Prompt 到 Skills,RAG 还行不行”这一话题,展开探讨。

多位行业专家从产品实践、技术演进与系统架构等维度切入,认为 RAG 不仅未过时,反而因与 Skill、Memory、数据库等技术的深度融合而更具生命力。成为上下文工程的核心基础设施,并与数据库、技能系统、记忆机制深度融合,推动 AI 应用从“问答玩具”向“生产级工作流”跃迁。

RAGFlow CEO 张颖峰表示,从 RAG 引擎到上下文引擎,技术不变,但其内涵会随着时代的变化而改变。谈及未来 RAG 是否应更多依赖数据库进行多路检索这一话题时,OceanBase AI 平台与应用部负责人吉剑南认为,RAG 应与数据库结合,这也是 OceanBase 提出的“混搜”这一理念的核心所在。Co-founder of Nowledge Labs 古思为则从图数据库视角出发,指出索引结构应贴近知识本质,并支持动态 Agent 检索;FastGPT 负责人余金隆补充说明标量与向量结合的动态检索实践。

在第二场圆桌对话中,南京大学研究生院人工智能课程企业教师谢肖瑜作为主持人,与 Eigent 核心研发工程师、CAMEL-AI 核心成员孙韬,OceanBase Ambassador 程治玮,蚂蚁百灵模型产品负责人边思康和Fellou 创始团队成员孙稼骏针对“Agent 元年之后,真正能用的 AI 长什么样”这一话题展开讨论。

随着AI技术深入现实应用,一个关键议题正引发广泛讨论:人类使用 AI 的门槛是否正在提高?针对这一问题,专家们认为,尽管当前部分 AI 工具仍需要一定配置与学习成本,但技术演进正推动交互方式发生根本性转变,回顾人机交互历史,从 DOS 命令到图形界面,技术门槛始终在不断降低。尤其在当下,大模型能力的显著提升,使得 AI 正变得更易理解与使用。越来越多的产品开始尝试通过界面引导、视觉交互降低操作难度,让非技术用户也能借助 AI 完成复杂任务。

这种“以人为中心”的设计趋势,意味着未来 AI 将不再仅是技术专家的工具,而会真正成为人人可用的普及型能力。在这一过程中,如何让技术适配人的习惯,而非让人适应技术,将成为产品进化的重要方向。

AI Coding 实战上演巅峰对决:13岁少年拿下第二名

此外,本次活动创新设立了 AI Coding 实战环节。OceanBase Ambassador 伊洪以“开源,Agents 以及 AI Coding”为主题,进行了分享,并在现场零代码“手搓” coding agent 。

OceanBase Ambassador 伊洪

在 AI Coding 环节,颁发了“最快合并奖”“最难 pr 奖”“最多合并奖”“最佳创意奖”等 10 项大奖,其中,OceanBase Ambassador 程治玮获“最佳创意奖”,来自上海的 13 岁初二少年张天瑜获得 AI Coding “最难 pr 奖”第二名。

过去,参与开源往往需要先花时间熟悉项目,再完成编码、调试和提交,整体门槛较高。随着 AI Coding 工具能力的提升,开发者在理解代码、生成修改、定位问题和完善提交等环节能获得更多辅助,参与开源的门槛随之下降。

活动前,OceanBase 已在 OceanBase seekdb 的 GitHub 仓库集中开放了 83 个与 OceanBase 及其生态相关的 issue,便于社区开发者参与讨论与贡献。

获得 AI Coding “最难 pr 奖”第二名的张天瑜。此次选择的题目是“为 powermem 添加网页 Dashboard”,需要开发统计 API 和前端页面。前端他凭借两年的 React/Vue 经验独立完成,后端则交给 AI 辅助生成。“让我惊讶的是,AI生成的后端代码一次就跑通了。”

此外,在下午的社区开放麦环节,由 FastGPT、CelHive、CAMEL-AI、Refly.AI、Dify 以及 OceanBase seekdb 的各位技术专家 ,通过现场实操,为大家展示了在各个 AI 平台上构建 Agent 系统和工作流的便捷性。其中最令人印象深刻的是,各平台都纷纷展示了如何通过自然语言来高效地构建 Agent 和工作流,堪称吹响了一场 Agentic 革命的号角。

对于开发者而言,借助 AI 工具快速理解项目、上手的同时,能更专注于创意实现与边界探索,不仅让开发更智能,更让开源共建更可持续、更富创造力,而这也是 AI 时代赋予开源生态的新命题与新机遇。

本次社区嘉年华以技术为纽带,有效激发了社区的创新活力。展望未来,我们诚邀更多开发者与生态伙伴加入,携手拓展开源技术的应用边界与想象空间。

公共资源速递

6 个公共数据集:

  • Sonar Signal 水下声呐信号数据集
  • Diabetes Mexico 墨西哥糖尿病数据集
  • Vehicles OpenImages 车辆图像数据集
  • LightOnOCR-mix-0126 文本转录数据集
  • Delhi Pollution AQI 德里空气质量数据集
  • Chest X-ray Pneumonia 胸部 X 光肺炎数据集

7 个公共教程:

  • DeepSeek-OCR-2 视觉因果流

* Ovis-Image:高质量图像生成模型

  • vLLM+Open WebUI 部署 GLM-4.7-Flash
  • Step3-VL-10B:多模态视觉理解与图文对话
  • TurboDiffusion:图像与文本驱动视频生成系统

* LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型

* Personaplex-7B-v1:实时对话与角色定制语音接口

访问官网立即使用: openbayes.com

公共数据集

1. Sonar Signal 水下声呐信号数据集

Sonar Signal 是一个用于水下物体分类的声呐信号数据集。该数据集适用于二分类任务,目标是区分声呐信号是由岩石还是矿井反射而来。该数据集总计 207 个样本,每个样本包含 60 个连续数值特征。

在线使用:

https://go.openbayes.com/RJhGo

2. Diabetes Mexico 墨西哥糖尿病数据集

Diabetes Mexico 是由墨西哥的国家公共卫生研究所发布的糖尿病数据集,旨在评估墨西哥人群中与糖尿病相关的代谢风险特征。该数据集包含墨西哥个体的社会人口学、人体测量及生物化学信息,主要变量涵盖调查标识符、性别、年龄、居住城市,以及体重、身高、体重指数等体格指标,并包括尿酸、白蛋白、肌酐、总胆固醇、HDL/LDL 胆固醇、甘油三酯、血清葡萄糖、胰岛素和糖化血红蛋白等相关生化指标。

在线使用:

https://go.openbayes.com/gi6tC

3. Vehicles OpenImages 车辆图像数据集

Vehicles OpenImages 来源于 Google 的 OpenImages 大规模公开数据集,专注于车辆检测与定位的图像数据集,旨在支持车辆检测模型的快速高效训练。该数据集包含多种环境、光照条件和视角下的车辆图像,图像预处理为 416×416 分辨率,适用于 YOLO、SSD 和 RetinaNet 等现代目标检测模型提供COCO、YOLO、Pascal VOC 和 TensorFlow 格式的多种注释格式,兼容多种机器学习框架,包含平衡的训练/验证/测试分割,以评估模型性能。

在线使用:

https://go.openbayes.com/Q61aS



数据集示例

4. LightOnOCR-mix-0126 文本转录数据集

该数据集包含训练集与验证集两部分,每个样本对应一个文档页面的文本转录结果,内容涵盖按自然阅读顺序组织的页面文本(输出格式包括 Markdown、LaTeX 数学公式及 HTML 表格等)以及相应的结构化标记,覆盖段落、标题、列表与表格等多类型页面内容。

在线使用:

https://go.openbayes.com/SroyH

5. Delhi Pollution AQI 德里空气质量数据集

Delhi Pollution AQI 是一个面向空气质量分析和预测的环境数据集。该数据集提供了德里 NCR 地区主要城市的每小时空气质量和环境数据,适合用于污染分析、时间序列预测和机器学习应用。数据集拥有超过 200,000 条小时观测样本。

在线使用:

https://go.openbayes.com/IbRsn

6. Chest X-ray Pneumonia 胸部 X 光肺炎数据集

Chest X-ray Pneumonia 是一个从胸部 X 光图像中提取的数值特征数据集。该数据集通过将每张图像转化为结构化的数值特征,包括全局强度统计、纹理描述符(GLCM)、频域特征(FFT)、基于边缘的度量以及局部二值模式(LBP)特征,来支持统计分析和经典机器学习。

在线使用:

https://go.openbayes.com/IbRsn

公共教程

1. DeepSeek-OCR-2 视觉因果流

DeepSeek-OCR 2 是由 DeepSeek 团队推出的第二代 OCR 模型,通过引入 DeepEncoder V2 架构,实现从固定扫描到语义推理的范式转变。模型采用因果流查询和双流注意力机制,能动态重排视觉 Token,更精准地还原复杂文档的自然阅读逻辑。在 OmniDocBench v1.5 评测中,模型综合得分达到 91.09%,较前代提升显著,同时显著降低了 OCR 识别结果的重复率,为未来构建全模态编码器提供新路径。

在线运行:

https://go.openbayes.com/C5oYw


项目示例

2. Ovis-Image:高质量图像生成模型

Ovis-Image 是一个高质量图像生成模型系统,由 AIDC-AI 团队发布的 Ovis-Image-7B 高保真文本到图像生成模型构建。该系统采用多尺度 Transformer 编码器与自回归生成架构,在高分辨率图像生成、细节表现及多风格适配能力上表现卓越。通过优化的噪声采样和 classifier-free guidance 技术,Ovis-Image 能够在 1024x1024 分辨率下生成自然、连贯、细节丰富的图像,支持写实、赛博朋克、动漫、科幻等多种风格。

在线运行:

https://go.openbayes.com/KFcQO

项目示例

3. vLLM+Open WebUI 部署 GLM-4.7-Flash

GLM-4.7-Flash 是智谱 AI 推出的轻量化 MoE 推理模型,兼顾高性能与高吞吐,原生支持思考链(CoT)、工具调用与 Agent 能力。它采用 Mixture of Experts(MoE)架构,通过稀疏激活机制,在保持大模型表达能力的同时,大幅降低单次推理的计算成本。

在线运行:

https://go.openbayes.com/ItzzP


项目示例

4. Step3-VL-10B:多模态视觉理解与图文对话

Step3-VL-10B 由 StepFun 团队发布,是一款面向多模态理解与复杂推理任务的开源视觉-语言基础模型。STEP3-VL-10B 旨在在参数规模受限的前提下,重新定义多模态模型在效率、推理能力与视觉理解质量之间的平衡。尽管参数规模紧凑,该模型在视觉感知、复杂推理以及人类指令对齐等方面表现出色,在多项基准测试中持续优于同规模模型,并在部分任务上可与参数规模大 10–20 倍的模型相竞争。

在线运行:

https://go.openbayes.com/LN9xD


项目示例

5. TurboDiffusion:图像与文本驱动视频生成系统

TurboDiffusion是由清华大学团队开发的高效视频扩散生成系统。该项目基于 Wan2.1 架构进行高阶蒸馏,旨在解决大规模视频模型推理速度慢、计算资源消耗大的痛点,实现了极少步数下的高质量视频生成。该系统基于 rCM 蒸馏技术,将 14B 模型 5 秒视频的生成耗时从分钟级压缩至 2-10 秒,实现百倍以上的效率飞跃。支持 720P T2V 与 I2V  任务,在极速生成下依然保持 SOTA 级的视觉连贯性与画质。

在线运行:

https://go.openbayes.com/8ufT5


项目示例

6. LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型

LightOnOCR-2-1B 是由 LightOn AI 于 2026 年 1 月推出的最新一代端到端视觉语言模型(OCR)。作为 LightOnOCR 系列中的旗舰级版本,它在一个紧凑的架构中统一了文档理解与文本生成功能,拥有 10 亿参数(1B),能够在消费级显卡(约 6GB 显存)上运行。该模型采用 Vision-Language Transformer 架构,并引入了 RLVR 训练技术,实现了极高的识别准确率与推理速度,专为需要处理复杂文档、手写体及 LaTeX 公式的应用场景设计。

在线运行:

https://go.openbayes.com/uxY9d

7. Personaplex-7B-v1:实时对话与角色定制语音接口

PersonaPlex-7B-v1 是 NVIDIA 于 2026 年 1 月发布的 70 亿参数多模态个性化对话模型,面向实时语音/文本交互、长效角色一致性模拟与多模态感知任务。本 Notebook 基于该模型构建,旨在提供一个支持毫秒级响应的沉浸式角色扮演与多模态交互演示系统。

在线运行:

https://go.openbayes.com/aM5GU


项目示例

不管你是 Linux 后端开发、C/C++ 编程,还是运维面试,系统调用和库函数都是大家绕不开的核心知识点。小编发现很多新手(也包括工作多年的)写代码时随手调用的函数(比如 printf、open、fopen),大部分小伙伴们压根就不关心这些函数哪些是系统调用、哪些是库函数,甚至误以为二者是同一概念,结果面试被问倒、排查问题找不到方向。

确实,从咱们普通人的角度来看,系统调用和库函数似乎没有什么区别,它们都是以 C 函数的形式出现,并且两者都为应用程序提供服务。但从实现者角度来看,它们之间是有根本的区别。那么,它们之间到底有哪些不同呢?在说明之前,先简单了解以下系统调用和库函数。

什么是系统调用?

系统调用是操作系统为应用程序提供的一组特殊接口,是用户空间与内核空间之间的关键桥梁。在计算机系统中,内核负责管理硬件资源、调度任务和维护系统安全等核心功能,运行在特权级较高的内核态;而应用程序则运行在用户态,对硬件和系统资源的访问受到严格限制。系统调用充当“翻译官”,允许应用程序通过它向内核发出请求,执行特定操作,并将处理结果返回给应用程序。

咱们举个经常用的典型场景:当应用程序需要读取文件数据时,会直接调用 read 这一系统调用。应用程序会将文件描述符、数据接收缓冲区、预期读取的字节数等关键参数传入 read,随后通过系统调用触发 CPU 特权级切换,从用户态进入内核态。内核会依据传入的参数定位目标文件,从磁盘介质中读取对应数据,并将数据拷贝至应用程序指定的用户态缓冲区,最终把实际读取的字节数作为返回值,传递回用户态的应用程序。

常见系统调用很多,例如:open, close, read, write, ioctl,fork,clone,exit,getpid,access,chdir,chmod,stat,brk,mmap 等,需要包含 unistd.h 等头文件。

那系统调用的具体工作流程什么呢?

答:应用程序发起调用时,会触发内核陷入机制。以 x86 架构为例,通过 int 0x80 这类陷入指令,CPU 从权限受限的用户态,切换至拥有最高权限的内核态。内核会根据系统调用号,在系统调用表中找到对应的内核函数并执行,比如读取文件时就会调用磁盘 IO 相关的内核逻辑。操作完成后,内核将结果返回应用程序,CPU 再切回用户态,程序继续向下执行。

什么是库函数?

库函数用于提供用户态服务。它可能调用封装了一个或几个不同的系统调用(printf 调用 write),也可能直接提供用户态服务(atoi 不调用任何系统调用)。

小编把库函数理解为是预编译的程序代码,存储在共享库或静态库中,用于执行常规编程任务。

常见库函数有:printf,scanf,fopen,fclose,fgetc,fgets,fprintf,fsacnf,fputc,calloc,free,malloc,realloc,strcat,strchr,strcmp,strcpy,strlen,strstr 等,需要包含 stdio.h,string.h,alloc.h,stdlib.h 等头文件。

它俩之间区别:

  • 系统调用通常不可替换,而库函数通常可替换
  • 系统调用通常提供最小接口,而库函数通常提供较复杂功能
  • 系统调用运行在内核空间,而库函数运行在用户空间

因为系统调用属于内核,和库函数不属于内核。因此,如果当用户态进程调用一个系统调用时,CPU 需要将其切换到内核态,并执行一个内核函数。

  • 内核调用都返回一个整数值,而库函数并非一定如此

在内核中,整数或 0 表示系统调用成功结束,而负数表示一个出错条件。而出错时,内核不会将其设置在 errno,而是由库函数从系统调用返回后对其进行设置或使用。

  • POSIX 标准针对库函数而不是系统调用

判断一个系统是否符合 POSIX 标准,关键在于它是否提供了一组适当的应用程序接口,而与这些函数的具体实现无关。因此,从移植性角度来看,使用库函数的移植性优于直接使用系统调用。

  • 系统调用运行时间属于系统时间,库函数运行时间属于用户时间
  • 调用系统调用开销相对库函数来说更大

许多库函数会调用系统调用,但直接调用系统调用的开销较大,主要是因为上下文切换的代价。在用户态和内核态之间切换时,需要保存和恢复 CPU 状态,这消耗时间。库函数通过使用双缓冲技术和缓冲机制来降低这种开销,以文件读写为例,调用库函数可以显著减少系统调用次数,从而提高性能。直接调用系统调用时,每次都需进行上下文切换,导致性能损失。因此,库函数的开销通常小于直接调用系统调用,同时它们也能对系统调用进行优化,提升整体效率。

弄个表格,方便记忆和对比:

什么时候使用系统调用?

  • 需要直接控制硬件或内核资源(如设备驱动开发)。
  • 追求极致性能(但需权衡系统调用开销)。
  • 操作系统内核开发。

什么时候使用库函数?

  • 需要高级功能(如字符串处理、数学运算)。
  • 追求开发效率和可移植性。 避免重复造轮子(
  • 如使用 pthread 而非手动实现线程)。

总结

  • 系统调用是内核的 “底层大门”,是用户态访问内核的唯一通道,开销大、权限高、不可移植;
  • 库函数是用户态的“便捷工具”,基于系统调用封装,部分纯逻辑函数与内核无关,开销小、易用、可移植;
  • 日常开发优先使用库函数,兼顾开发效率和性能;底层开发、性能极致优化场景,可直接调用系统调用。https://mybj123.com/29266.html

背景: 2 年 Java 经验,无经济压力。年前因前司拖欠工资离职,入职新公司一周。 现在前司补发了薪资(1 个月),老板也支持我回去,薪资持平(比新公司低 20%)。

1. 新公司(目前在职)

  • 优点: 涨薪 20%,百人规模,现金流稳。
  • 缺点: 管理严格, 技术栈混乱,不同项目不一样,没有产品经理和前端,基本就是维护老项目。需求直接和老板对接
    • 通勤地铁 40+ 分钟
    • 电脑配置差,流程乱(无 PM 直对老板),考勤严,迟到罚款。

2. 前司(回头草)

  • 优点: 极度舒适:步行 5 分钟上班,不打卡。
    • 工作环境舒适(电脑配置好、300 多的人体工学椅),同事熟,纯 Java 环境。
    • 福利好(春节提前一周放假居家办公)。
  • 缺点: 薪资低 20%。
    • 风险高:10 人小团队,有过拖欠 3 个月工资前科,老板曾提过解散。

纠结: 目前不缺钱。 留新公司:钱多点但每天上班如上坟(通勤累+技术栈不喜+电脑卡)。 回前司:生活质量极高,但怕再次欠薪倒闭,面临二次找工作。新公司也是自己负责一个项目(包含前端和产品设计),前司有前端、产品,后端也只有我一人。项目都是同一类型项目。

求建议,是为了生活质量回前司苟着,还是在新公司硬抗?

在数据处理和分析的过程中,经常需要将不同格式的数据进行转换。Excel 文件是数据存储和操作中非常常见的格式,而 TXT 文件凭借其简单的文本格式,常用于数据共享和处理。本文将介绍如何使用 Python 和 Spire.XLS 库将 Excel 导出为 TXT 文件。

环境准备

要实现这个功能,我们需要确保已安装 Spire.XLS for Python 库。如果尚未安装,可以通过如下命令进行安装:

pip install Spire.XLS

此库提供了丰富的 Excel 文件处理功能,可以方便地进行读取、编辑和保存操作。

示例代码

下面是一个完整的示例代码,展示了如何将 Excel 文件导出为 TXT 文件:

import os
import sys

# 获取当前文件路径
curPath = os.path.abspath(os.path.dirname(__file__))
rootPath = os.path.split(curPath)[0]
sys.path.append(rootPath)

from spire.xls import *
from spire.xls.common import *

# 输入和输出文件的路径
inputFile = "Input.xlsx"
outputFile = "output.txt"

# 创建Workbook对象 
workbook = Workbook()

# 加载一个Excel文件
workbook.LoadFromFile(inputFile)

# 获取第一张工作表
sheet = workbook.Worksheets[0]

# 将工作表保存为TXT文件
sheet.SaveToFile(outputFile, " ", Encoding.get_UTF8())
workbook.Dispose()

代码解析

  1. 环境配置

    我们首先导入必要的模块,为后续文件操作做准备。通过 ossys 模块,我们获取了当前文件的路径,以便进行文件导入和导出。

  2. 创建 Workbook 对象

    使用 Workbook() 类创建一个新的工作簿对象。这是操作 Excel 文件的基础。

  3. 加载 Excel 文件

    通过 LoadFromFile 方法,我们加载了指定的 Excel 文件。在这个示例中,文件名为 "测试.xlsx"。

  4. 获取工作表

    在 Excel 文件中,可以有多个工作表。这里我们通过 workbook.Worksheets[0] 获取第一个工作表。索引从 0 开始,因此 [0] 表示第一张工作表。

  5. 导出为 TXT 文件

    使用 SaveToFile 方法将工作表导出为 TXT 文件。在此参数中,我们设置了输出文件名以及列分隔符(在这里使用空格 " ")。同时我们还指定了文件编码为 UTF-8,确保支持多种语言字符的正确显示。

  6. 释放资源

    最后,使用 Dispose() 方法释放工作簿所占用的资源,确保程序的稳定性。

小结

通过以上步骤,我们成功使用 Python 将 Excel 文件导出为 TXT 格式。Spire.XLS 提供了简洁的方法,使得操作 Excel 文件变得极为简单,尤其适合于需要批量处理或自动化脚本的场景。

对于更复杂的需求,如需处理多个工作表或对数据进行格式化、筛选等,可以进一步改善代码逻辑和添加相应功能。此外,Spire.XLS 还支持对 Excel 文件的其他灵活操作,如修改单元格内容、添加图表等,用户可以根据需求更深入地探索该库的功能。

在当今工程建设领域,数字化转型浪潮汹涌,工程资料软件成为提升管理效率与质量的关键工具。市面上涌现出众多优秀的工程资料软件厂商,它们凭借卓越的产品性能与服务,推动着行业的进步。
创新技术驱动:筑业软件
筑业软件在工程资料管理领域深耕多年,以技术创新为核心竞争力。其软件具备强大的资料编制功能,依据各地不同的工程建设标准与规范,内置海量精准的资料模板,涵盖建筑、市政、水利等多个领域。通过智能识别与自动填充技术,大大减少工程人员手动录入的工作量,提高资料编制的准确性与效率。例如,在建筑项目资料整理过程中,软件能根据施工工序自动关联相应的资料表格,并填充部分常规信息,节省大量时间。同时,筑业软件注重用户体验,界面设计简洁直观,即使新手也能快速上手。
全面解决方案:品茗软件
品茗软件以提供全面的工程资料管理解决方案著称。除了基础的资料编制功能外,还涵盖资料审核、数据统计分析以及协同管理等模块。在资料审核方面,依据行业规范和标准,对工程资料进行智能检查,精准指出存在的问题与错误,帮助工程人员提升资料质量。数据统计分析功能则能从海量资料中提取关键信息,为项目决策提供有力支持。例如,通过分析质量验收资料,可直观了解项目各阶段的质量状况,及时发现潜在风险。在协同管理方面,品茗软件支持多部门、多参与方实时共享资料,实现高效协作,确保项目顺利推进。
行业深耕与定制化:恒智天成
恒智天成软件长期专注于工程资料软件的研发与推广,对行业需求有着深刻的理解。其产品不仅满足通用的工程资料管理需求,还能针对不同行业、不同规模的企业提供定制化解决方案。例如,针对大型建筑企业,可定制符合企业内部管理流程与标准的资料管理系统,实现资料的规范化、标准化管理。恒智天成软件注重技术与服务的结合,拥有专业的技术支持团队,为用户提供及时、高效的售后服务,确保软件在使用过程中遇到的问题能得到快速解决。
市面上这些优秀的工程资料软件厂商,通过不断创新与完善产品功能,为工程建设行业提供了强大的数字化助力。它们在提升工程资料管理水平的同时,也推动着整个行业向更加高效、智能的方向发展。工程企业在选择软件厂商时,应根据自身实际需求,综合考量产品功能、服务质量以及性价比等因素,选择最适合的软件产品,为项目的成功实施奠定坚实基础。

在搭建量化回测与策略验证体系时,美股历史数据几乎是绕不开的环节。无论是模型训练、指标验证,还是实时监控,数据结构能否统一、时间序列是否连续,都会直接影响分析的可靠性。

近期在协助某投顾团队整理量化研究流程时,我们尝试将历史与实时数据接入统一到同一数据结构中,以减少维护复杂度,也为长期分析提供可复用的底层框架。下面结合 [AllTick API]的接入实践,总结过程中的一些要点。

1. 背景与开发痛点

许多投研系统初期都能快速跑通,但在长期迭代中容易出现以下问题:

  • 不同接口返回结构差异较大,字段不一致。
  • 历史数据与实时推送数据难以兼容。
  • 数据缺口或时间戳偏差造成回测结果偏差。

这些看似琐碎的结构问题,往往才是限制系统长期稳定性的核心。对于需要频繁回测与高频更新的投顾分析框架,稳定的数据结构比“拉到数据”本身更重要。

2. 历史数据接口的基础结构

以 AllTick 的美股历史数据接口为例,其支持按股票、市场与时间区间拉取K线数据,并采用常规 HTTP 请求方式。主要参数包括:

  • symbol:证券代码(例如 AAPL)
  • market:市场标识(US)
  • interval:周期(如 1min、1day)
  • start_time / end_time:时间范围

响应数据则包含标准化字段:时间戳、开盘价、最高价、最低价、收盘价和成交量。
字段返回顺序规整,易于转为 Pandas DataFrame 做进一步处理。

import requests
import pandas as pd

url = "https://apis.alltick.co/v1/market/history"

params = {
    "symbol": "AAPL",
    "market": "US",
    "interval": "1day",
    "start_time": "2026-01-01",
    "end_time": "2026-03-01"
}

headers = {
    "Authorization": "Bearer YOUR_API_KEY"
}

response = requests.get(url, params=params, headers=headers).json()

if response.get("code") != 0:
    raise ValueError("请求失败", response)

data = response["data"]

经过统一处理后,数据结构清晰、索引友好,可直接用于可视化或后续统计。

3. 历史与实时数据结构统一

该 API 的一大优势在于:历史数据与实时数据字段设计保持一致
这意味着,你可以用历史数据初始化 DataFrame,再订阅实时推送,通过 WebSocket 实时补充到同一数据结构。

这种方式减少了重复设计表结构的需求,方便复用同一份计算逻辑,也让策略运行更稳定。

import websocket
import json

def on_message(ws, message):
    msg = json.loads(message)
    new_df = pd.DataFrame([msg])
    new_df["datetime"] = pd.to_datetime(new_df["timestamp"], unit="s")
    new_df.set_index("datetime", inplace=True)

    global df
    df = pd.concat([df, new_df])
    print(df.tail())

def on_open(ws):
    ws.send(json.dumps({
        "action": "subscribe",
        "symbol": "AAPL",
        "market": "US",
        "interval": "1min"
    }))

ws = websocket.WebSocketApp(
    "wss://apis.alltick.co/realtime",
    on_message=on_message,
    on_open=on_open
)

ws.run_forever()

对于需要长时间运行的系统而言,这种“一体化结构”能有效降低后期维护成本。

4. 数据处理中的几个注意点

在实际对接过程中,有几点经验值得记录:

  • 拉取跨度较大的历史区间时建议分段请求,避免超时。
  • 核实接口返回是否包含未收盘数据,以防计算偏差。
  • 处理缺失时间点时,应提前设计补齐或插值逻辑。

这些细节多数接口文档会提及,但实际落地还需结合业务场景与分析目标灵活调整。

5. 总结与延伸思考

整体来看,美股历史数据 API 本身不算复杂,真正影响使用体验的,是结构清晰度与历史数据和实时数据的衔接性。

当数据打好底层“地基”后,后续的策略优化、模型回测、交易执行都能以更低成本迭代。这类结构稳定、接口统一的方案,也逐渐成为投顾团队构建自主投研平台的基础。

前言

在鸿蒙生态逐步向 PC、平板、车机、IoT 全场景扩展的背景下,越来越多开发者开始关注一个现实问题:

如何用最低成本,构建可同时运行在鸿蒙与多平台的应用?

Flutter 作为成熟的跨端 UI 框架,在适配 HarmonyOS 6.0 后,已经具备了完整的工程化能力:
一次开发,多端部署,天然适合鸿蒙“全场景设备”的产品理念。

本文我们不讲复杂架构,不上状态管理,不搞花哨组件,只做一件事:

用 Flutter 在 HarmonyOS 6.0 上,实现一个最基础、最标准、最工程化的列表页面。

目标非常明确:
构建一个带分隔线的基础 ListView,并完全理解每一行代码。


在这里插入图片描述

背景

在真实业务中,列表几乎是出现频率最高的 UI 结构

  • 设置页 → 列表
  • 消息页 → 列表
  • 文件管理 → 列表
  • 日志面板 → 列表
  • 运维系统 → 列表

可以说:

学会 ListView,等于掌握 Flutter UI 的 40%。

而在 HarmonyOS 场景下,列表还有一个额外价值:

  • 大屏设备(PC / Pad)
  • 多窗口
  • 分布式界面
  • 高刷新率

都要求列表组件 性能稳定 + 行为可控 + 样式一致

所以我们从最基础的 ListView.separated 开始,是最工程化、最合理的学习路径。


Flutter × HarmonyOS 6.0 跨端开发介绍

架构关系

在鸿蒙 PC 上运行 Flutter 的本质结构是:

Flutter Widget Tree
        ↓
Flutter Engine
        ↓
Skia / Impeller 渲染
        ↓
HarmonyOS 图形系统 (ArkUI / Surface)

你写的:

ListView(
  children: [...]
)

最终会被 Flutter Engine 转换为:

  • 原生 GPU 绘制指令
  • 在鸿蒙窗口系统中渲染
  • 不依赖 WebView
  • 不走 H5

这意味着:

Flutter 在鸿蒙上是“真原生渲染”,不是套壳。
在这里插入图片描述

开发核心代码

在这里插入图片描述

我们这篇文章的核心只有一个函数:

/// 构建基础列表布局
/// 展示最简单的 ListView 实现,包含分隔线和基本的 ListTile
Widget _buildBasicList(ThemeData theme) {
  final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

  return Container(
    decoration: BoxDecoration(
      borderRadius: BorderRadius.circular(12),
      color: theme.colorScheme.surfaceContainerHighest,
    ),
    child: ListView.separated(
      shrinkWrap: true,
      physics: const NeverScrollableScrollPhysics(),
      itemCount: items.length,
      separatorBuilder: (context, index) => Divider(
        height: 1,
        color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
      ),
      itemBuilder: (context, index) {
        return ListTile(
          title: Text(items[index]),
          onTap: () {},
        );
      },
    ),
  );
}

这个函数本质上解决了四件事:

  1. 数据源定义
  2. 容器样式
  3. 列表渲染策略
  4. 每一行的 UI 结构

我们逐层拆解。


一、数据源:items 列表

final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

这是一个最简单的 静态数据源,但它抽象出了真实业务中最重要的概念:

ListView 永远只关心一个东西:itemCount + itemBuilder

真实业务中你会换成:

  • 接口返回的数据
  • 数据库查询结果
  • WebSocket 推送数据

但 ListView 的用法完全不变。


在这里插入图片描述

二、外层容器:Container + BoxDecoration

return Container(
  decoration: BoxDecoration(
    borderRadius: BorderRadius.circular(12),
    color: theme.colorScheme.surfaceContainerHighest,
  ),

这一层在鸿蒙适配中非常关键。

1. 为什么不用直接 ListView?

因为鸿蒙设计语言(Harmony Design)强调:

  • 模块化卡片
  • 圆角容器
  • 表面层级(Surface)

所以标准写法是:

列表外一定包一层“语义容器”

这样才能:

  • 控制圆角
  • 控制背景色
  • 控制阴影 / 层级
  • 和 ArkUI 设计风格一致

三、ListView.separated:工程级推荐写法

ListView.separated(
  itemCount: items.length,
  separatorBuilder: ...
  itemBuilder: ...
)

这是 Flutter 中 最推荐用于业务列表的写法

相比:

  • ListView(children: [])
  • ListView.builder(...)

separated 的优势是:

特性ListView.separated
自动分隔线
懒加载
性能友好
UI 结构清晰
适合复杂业务

四、分隔线:Divider 的工程含义

separatorBuilder: (context, index) => Divider(
  height: 1,
  color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
),

这一行非常“专业”。

1. 不写死颜色,而用 Theme

这是鸿蒙跨端开发的关键原则:

永远不要写死颜色,永远使用 Theme。

因为:

  • 鸿蒙支持深色模式
  • 支持动态主题
  • 支持系统级换肤
  • 支持多品牌定制

这一行:

theme.colorScheme.onSurface.withValues(alpha: 0.1)

代表:

使用当前主题下“文字颜色”的 10% 透明度作为分割线

这在设计系统里叫:

Semantic Color(语义色)

而不是 Hard Code。


五、ListTile:最标准的列表行组件

return ListTile(
  title: Text(items[index]),
  onTap: () {},
);

ListTile 是 Flutter 官方提供的:

企业级标准列表行组件

默认自带:

  • 左右 padding
  • 行高规范
  • 触摸反馈
  • 无障碍语义
  • 键盘导航支持(PC 端)

在鸿蒙 PC 场景下尤其重要:

  • 自动支持鼠标 hover
  • 自动支持键盘 focus
  • 自动支持触控点击

你什么都不用写。


在这里插入图片描述

六、两个关键参数:shrinkWrap + physics

shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),

这是非常典型的 嵌套列表写法

含义是:

  • 这个 ListView 不自己滚动
  • 高度由内容撑开
  • 通常用于:

    • 列表嵌套在 Column
    • 放在页面中间模块
    • 外层还有主滚动容器

在鸿蒙大屏页面中,这是最常见结构

Scaffold
 └─ SingleChildScrollView
     └─ Column
         ├─ Header
         ├─ Card
         │   └─ ListView (shrinkWrap)
         ├─ Footer

实际运行效果(HarmoList)

在 HarmonyOS 6.0 PC 上运行后效果是:

  • 圆角卡片
  • 浅色背景
  • 五行列表
  • 细分隔线
  • 点击有波纹反馈
  • 风格与鸿蒙系统设置页高度一致

视觉风格非常接近:

系统设置 / 文件管理 / 设备管理界面

这就是 “鸿蒙感”UI 的核心来源


心得(工程经验)

通过这个最简单的例子,其实已经体现了三条非常重要的工程原则:


1. Flutter 在鸿蒙不是玩具,是工程级方案

它不是 Demo 框架,而是:

  • 可跑生产系统
  • 可做复杂 UI
  • 可支撑大屏交互
  • 可适配分布式设备

2. ListView 是所有复杂页面的基础单元

任何复杂页面:

  • 设置页
  • 运维后台
  • 设备控制台
  • AI 管理界面

最终拆解后都是:

Header + ListView + Footer

3. Theme 是鸿蒙跨端的灵魂

不用 Theme = 一定翻车:

  • 深色模式崩
  • 品牌定制崩
  • 多设备风格不统一

这行代码价值极高:

theme.colorScheme.surfaceContainerHighest

它代表的是:

“让系统自己决定颜色,而不是我来决定。”

这是专业工程师和 Demo 工程师最大的区别。


总结

通过 HarmoList 这个极简示例,我们完成了:

  • Flutter 在 HarmonyOS 6.0 上的基础 UI 落地
  • 一个标准工程级 ListView 构建方式
  • 理解了 ListView.separated 的真实价值
  • 掌握了鸿蒙风格 UI 的核心设计思想

这段代码虽然只有几十行,但它背后代表的是:

Flutter × HarmonyOS 跨端开发的最小可行工程模型(MVP)

后续无论你要做:

  • 设置系统
  • 文件管理器
  • 运维控制台
  • 设备面板
  • AI 管理后台

所有复杂 UI,90% 都是从这个结构进化出来的。

一句话总结:

真正的跨端工程能力,不是炫技组件,而是把最简单的列表写到“专业级”。

在这里插入图片描述

通过 HarmoList 这个最基础的示例可以看到,Flutter 在 HarmonyOS 6.0 上的开发体验已经非常成熟,其 UI 构建模式与传统 Android / iOS 几乎完全一致,但在鸿蒙全场景设备体系下具备更强的延展性。从工程视角来看,一个看似简单的 ListView.separated,实际上已经完整体现了跨端开发中最关键的几个能力:数据驱动渲染、语义化主题适配、组件级 UI 复用以及面向大屏与多输入方式的交互支持。

更重要的是,这种写法并不是 Demo 级技巧,而是可以直接复用于真实业务系统的“标准工程模板”。无论是设置页、管理后台,还是设备控制面板,本质上都可以从这一基础结构演进扩展。可以说,真正掌握 Flutter × HarmonyOS 的第一步,并不是复杂架构设计,而是把这种最基础的列表组件写得足够规范、足够工程化、足够可复用。

作者:赵雁松,周岩珏,李志强,周永康,刘军

前言:AI 数据分析的“最后一公里”

在企业数字化转型的浪潮中,我们发现很多公司依然面临着“数据深渊”:业务人员想看数据,却受限于复杂的 SQL 语法;开发者虽然尝试了 Text-to-SQL,但生成的代码逻辑常有偏差,同时也无法应对复杂的统计分析、根因定位等场景。

DataAgent 应运而生。 这不是简单的指令翻译器,而是我们基于 Spring AI Alibaba 生态构建的一位“虚拟 AI 数据分析师”。它能够像专家一样思考、规划、纠错,并最终输出一份带图表、带逻辑、带深度洞察的行业级报告。

从架构上,DataAgent 是一款基于 Spring AI Alibaba 生态构建的、面向企业级复杂场景的“虚拟 AI 数据分析师”。它通过 Spring AI Alibaba Graph & Agent Framework 构建了一套具备自我规划、工具调用、反思纠错及人类干预能力的数据智能体(Agent),通过 graph、multi-agent 模式将确定性流程与模型推理结合在一起,搭建了一套兼具流程确定性与智能化的数据智能体产品。

降维打击:为什么 DateAgent 不止是 Text-to-SQL?

image

整体架构

image

核心黑科技:DateAgent 是如何解决企业难题的?

我们不只是在写代码,而是在解决企业数据决策中的“深水区”难题。以下是 DataAgent 攻克研发痛点、实现架构突破的几大核心战役。

4.1 人类反馈机制 (Human-In-The-Loop)

  • 遇到问题: 担心 AI 智商掉线?一个错误的执行计划可能瞬间拖垮生产库,甚至“一步错步步错”。
  • 解决方案:

    • 入口:运行时请求参数 humanFeedback=true(GraphController → GraphServiceImpl)
    • 数据字段:agent.human_review_enabled 用于保存配置,运行时以请求参数为准。
    • 图编排:PlanExecutorNode 检测 HUMAN_REVIEW_ENABLED,转入 HumanFeedbackNode
    • 暂停与恢复:CompiledGraph 使用 interruptBefore(HUMAN_FEEDBACK_NODE),无反馈时进入“等待”,反馈到达后通过 threadId 继续执行。
  • 反馈结果: 给 AI 穿上约束衣!同意、修改或驳回,都在你一念之间。让 AI 既有速度,又懂规矩。

image

image

4.2 Prompt 动态配置与自动优

  • 遇到问题: 修改一句 Prompt 就要重启系统?不同模型对 Prompt 脾气不同,一套模板走天下根本行不通。
  • 解决方案:

    • 配置入口:/api/prompt-config/*,数据表 user_prompt_config
    • 作用范围:支持按 agentId 绑定或全局配置(agentId 为空)。
    • Prompt 类型:report-generatorplannersql-generatorpython-generatorrewrite
    • 自动优化方式:ReportGeneratorNode 拉取启用配置(按 priority 与 display_order 排序),通过 PromptHelper.buildReportGeneratorPromptWithOptimization 拼接“优化要求”。
    • 当前实现重点:报告生成节点已落地优化;其他类型为预留能力。
  • 获得效果: 像配置 Excel 一样调优 AI。运维人员无需重启,即可让 DataAgent 瞬间从“菜鸟分析师”变身“首席架构师”。

image

image

4.3 深度 RAG 与混合检索增强

  • 遇到问题: 纯向量检索常召回一堆废话?AI 不认识你的业务缩写?表结构太复杂,AI 搜不到。
  • 解决方案:

    • 查询重写:EvidenceRecallNode 将多轮上下文与用户问题组装为检索指令,调用 LLM 生成 standaloneQuery,避免上下文遗漏与歧义。
    • 召回通道:AgentVectorStoreService 作为统一入口,默认走向量检索;开启混合检索后走 AbstractHybridRetrievalStrategy,将“向量召回 + 关键词召回”进行融合。(用户需要提供混合检索实现。当前默认只支持 es)
    • 召回过滤:DynamicFilterService 生成基于智能体与知识类型的过滤条件,限制检索范围,避免跨智能体串库。
    • 文档类型:业务知识(business_knowledge)+ 智能体知识(agent_knowledge)两类,按 agentId/type 元数据过滤后合并为 evidence,注入后续 prompt。
    • 关键配置:spring.ai.alibaba.data-agent.vector-store.enable-hybrid-search 控制是否开启混合检索;相似度阈值与 TopK 通过向量库配置项控制(如 top-ksimilarity-threshold)。
    • 输出形式:evidence 文档以标题/摘要/片段形式汇总,作为 EvidenceRecallNode 输出内容进入后续规划于 SQL 生成阶段。
  • 获得效果: AI 拥有了老员工的“直觉”。它能秒懂你的业务逻辑,即便表名全是乱码,它也能精准命中。

image

image

4.4 容器化 Python 执行引擎

  • 遇到问题: SQL 只能算数,不能预测。想看趋势图、做线性回归?SQL 此时显得苍白无力。
  • 解决方案:

    • 代码生成:PythonGenerateNode 根据计划与 SQL 结果生成 Python。
    • 代码执行:PythonExecuteNode 使用 CodePoolExecutorService(Docker/Local/AI 模拟)。
    • 执行配置:spring.ai.alibaba.data-agent.code-executor.*(默认 Docker 镜像 continuumio/anaconda3:latest)。
    • 结果回传:执行结果写回 PYTHON_EXECUTE_NODE_OUTPUTPythonAnalyzeNode 汇总后写入 SQL_EXECUTE_NODE_OUTPUT,用于最终报告。
  • 获得效果: 赋予 AI 科学家级的建模能力。不仅能提取数据,还能输出带图表、带算法、带深度预测的高质量产出。

image

image

4.5 流式输出 (SSE) 与多轮对话管理

  • 遇到问题: 分析任务耗时太长,用户盯着屏幕转圈圈,以为系统挂了。
  • 解决方案:

    • 流式输出:GraphController SSEGraphServiceImpl 流式处理。
    • 文本标记:TextType 在流中标记 SQL/JSON/HTML/Markdown,前端据此渲染。
    • 多轮对话:MultiTurnContextManager 记录“用户问题+规划结果”,注入到后续请求。
    • 模式切换:spring.ai.alibaba.data-agent.llm-service-type 支持 STREAM/BLOCK
  • 获得效果: 极致的交互快感!让用户亲眼看到 AI 正在如何“思考”与“推演”,每一秒都有获得感。

image

image

4.6 MCP 服务器发布与多模型调度

  • 遇到问题: DataAgent 虽好,但只能在自研系统用?想集成到 Claude 或 IDE?适配成本高到吓人。
  • 解决方案:

    • MCP:McpServerService 提供 NL2SQL 与 Agent 列表工具,使用 Mcp Server Boot Starter。
    • 多模型调度:ModelConfig 配置模型,AiModelRegistry 缓存当前 Chat/Embedding 模型并支持热切换(同一时间每类仅一个激活模型)。
    • 已内置工具:nl2SqlToolCallback、listAgentsToolCallback
  • 获得效果: 无处不在的 AI 生产力。它是你的数据中心,也是你办公软件里随叫随到的超强插件。

image

image

4.7 多数据源接入

  • 遇到问题: 企业数据散落在 MySQL、PostgreSQL 等各类库中,跨库取数像是在做“情报搜集”,配置繁琐且标准不一。
  • 解决方案:

    • 元数据存储:数据源配置写入 datasource,智能体绑定写入 agent_datasource,选表写入 agent_datasource_tables,逻辑外键写入 logical_relation
    • 类型扩展:BizDataSourceTypeEnum 定义数据源类型;对应的 Accessor + DBConnectionPool 负责不同数据库协议与方言的访问。
    • Schema 初始化:AgentDatasourceController 触发初始化,SchemaService 通过 AccessorFactory 拉取表/列/外键并写入向量库。
    • 运行时选择:DatabaseUtil 从当前智能体获取激活数据源,动态选择 Accessor 执行 SQL。
    • 约束:同一智能体同一时间仅允许启用一个数据源(AgentDatasourceService.toggleDatasourceForAgent)。
  • 获得效果: 一个智能体,纵览全司数据!无论数据在哪儿,DataAgent 都能精准“路由”。它是数据孤岛的终结者,让跨库分析像查询单表一样简单。

image

image

4.8 报告生成与摘要建议

  • 遇到问题: 查出来一堆数字有什么用?领导要的是洞察,是结论,是能直接发在群里的 HTML 报告。
  • 解决方案:

    • 报告节点:ReportGeneratorNode 读取计划、SQL/Python 结果与摘要建议(summary_and_recommendations)。
    • 输出格式:默认 HTML,plainReport=true 输出 Markdown(简洁报告)。
    • 优化提示词:自动拼接优化配置后生成报告。
  • 获得效果: 把分析师的一天缩短为 10 秒。从查数到成稿,DataAgent 承包了所有体力活,让你只负责最后的一锤定音。

image

4.9 NL2SQL 转换, 语义模型,逻辑外键引擎

  • 遇到问题: 纯大模型写 SQL 经常“盲目自信”,不是字段写错,就是不懂业务术语。语法错误导致的执行中断更是家常便饭。
  • 解决方案:

    • 语义模型层:通过管理端定义的术语映射规则,在生成阶段强制约束。
    • 两阶段校验:SqlGenerateNode 生成后接 SemanticConsistencyNode 检查语义一致性。
    • 自愈循环:SqlExecuteNode 捕获执行错误并反馈给 Graph 状态机,触发重定向至重写节点进行纠错。
    • 逻辑外键:写入外部的业务逻辑的外键,不写入业务数据库。增强对表的理解能力。
  • 获得效果: 让 AI 拥有“职业分析师”的严谨。 告别报错,告别幻觉。它不仅懂 SQL 语法,更懂你的业务逻辑,让每一次查询都精准命中。

4.10 API Key 与权限管理

  • 遇到问题: 接口裸奔?权限失控?想对外开放能力却怕费用爆炸或数据泄露。
  • 解决方案:

    • 管理端:AgentController 支持生成、重置、删除与启用/禁用 API Key。
    • 数据字段:agent.api_key 与 agent.api_key_enabled
    • 调用方式:请求头 X-API-Key
    • 注意:默认不开启鉴权拦截;生产需开启 spring.ai.alibaba.data-agent.api-key.enabled=true
  • 获得效果: 生产级安全防护。让你的 DataAgent 不仅是业务利器,更是安全可控的企业级数字资产。

image

image

结语:让数据价值触手可及

DataAgent 的核心价值在于,它不仅仅是完成了一次查询,而是将“数据处理的工程化”与“大模型的推理能力”深度结合。结合 Spring AI Alibaba  的 Graph 编排与 Agentic 推理能力,DataAgent 将确定性流程与模型推理结合在一起,将原本碎片化的分析过程,转化为了兼具流程确定性与智能化的数据智能体。

未来,数据不再是冷冰冰的行列,而是每一位业务决策者都能随手调用的“智库”。

想了解更多关于 DataAgent 的技术实现细节? 欢迎搜索钉钉群,群号: 154405001431,加入我们的开发者讨论群,共同探索 AI 的无限可能!

相关资源:

基本介绍

我做了一款基于小模型的拍照识别物品的 APP ,先录入物品的特征,可以从四个角度各拍一张照片,让模型能记住这个物品的特征。

然后点击 [识别特征] ,对着要识别的物品拍一张照片,点击识别,即可根据相似度进行查询。相似度的阈值可以在设置里面调整。

项目代码地址: https://gitee.com/mktime/object-detect

效果演示

APP 首页

拍照识别

世界范围内数字化进程正在不断加快,全球化与数字化开始深融合。在此等时代背景下,大型企业的业务版图正趋于多元化,突破单边限制。域名也是如此,从独立的域名,逐渐扩展至集团官网、独立子品牌、区域业务站点、品牌电商等。随着企业规模的不断增大和业务版图的扩充,数字资产逐渐分布至企业旗下数十甚至上百个域名。面对数量众多的网站,管理难度呈现指数级增长。单以数字证书而论,从申请到部署,从监控到续期,数百个域名的管理难度可想而知,稍有疏漏便可能引发连锁效应,让企业面临漏洞威胁与业务中断风险。JoySSL市场部负责人曾多次提到,单域名证书的管理模式已不适合大型企业的复杂架构,不仅效率低下,还会造成企业额外的成本支出。多域名SSL证书则是化繁为简,实现企业运维管理简化、优化成本结构的战略工具,是大型企业拥抱数字生态的基础。

多对一高效管理凸显证书核心优势

拥有多域名的大型企业,SSL证书通常缺乏统一管理视角,易造成资产无法统筹、证书过期以及安全策略不一致等诸多问题。多域名SSL证书可实现集中式管理,摒弃“证书分散现象”,打造统一的管理体系,对所有受保护的域名实现统一监控、快速续约与策略管理,告别碎片化管理模式。

多域名SSL证书可完成高效的成本管理,优化总体拥有成本,节约资源与人力,减少了证书审批、部署与日常运维的成本消耗,使企业团队能够专注于战略性的任务。

超越技术 赋能大型企业开展业务

部署多域名SSL证书,已成为企业集团化与多品牌战略的安全统一保障,为各子品牌网站提供统一且可信的高级安全标识,增强市场对品牌专业形象的认可,维护企业整体声誉。面对严格的审计标准,通过多域名证书,企业可向审计机构展示全面的安全管理措施,从而显著简化合规流程。

多域名证书支持收购整合与业务创新的快速反应能力,从而实现安全而高效的资源整合。此外,证书可提供标准化且高安全性的保护,确保生态伙伴服务的稳定性。

多域名SSL证书优化管理解决方案

OV及EV证书可确保企业在身份验证方面达到最高标准,提升公众对企业可信度的感知,提升品牌价值。此外,面对复杂的网络环境,JoySSL自动化证书管理平台能够实现证书与域名的高效识别、批量化部署、智能化监控预警,以及全流程的自动续期功能,使证书管理无缝嵌入企业数字化生态系统,保障企业数字基础设施的安全稳定运行。

以简约之道主动构建网络安全架构

多域名证书以化繁为简之道,配合专业的管理方案,推动企业从被动应对转为主动构建安全架构,通过高度集成的系统,使众多域名协同运行,提升整体防御能力。不仅是技术升级,更是企业管理理念的深刻蜕变。

近一周行情呈现出一种无序混沌的状态,硬科技与资源股回撤跌的比较狠,幸好没碰。午盘后拉了消费板块,我手里的消费电子或许能跟着喝口汤。

我的持仓:2 个医药+1 个医疗器械+2 消费电子+1 自动驾驶+1 美容护理
今天账户+3%跳水到+1%,还行,满足了。

Cloudflare发表了一篇博客文章,展示了在 Workers 上运行的无服务器 Matrix 家庭服务器,引发了关于 AI 生成代码和技术准确性的争论。虽然 Matrix.org 对 Cloudflare 的关注表示欢迎,但联合创始人 Matthew Hodgson指出,这篇文章“严重夸大了项目的范围”,强调了功能性 Matrix 服务器所需的核心功能缺失。

 

这篇博客声称已经在 Cloudflare 的边缘平台上构建了一个完整的 Matrix 家庭服务器,用 Cloudflare 的 D1 和 Durable Objects 等原语取代了 PostgreSQL 和 Redis。GitHub存储库最初将自己描述为“生产级”,并有一个“部署到 Cloudflare”的按钮。

 

Hodgson 在 Matrix.org 网站上的回应很圆滑,但很明确:

 

代码还没有实现 Matrix 的任何核心特性,这些特性允许你安全地进行联邦,因此还没有构成一个功能性的 Matrix 服务器,更不用说生产级服务器了。

 

他指出,该实现没有将房间建模为复制的事件图,没有检查权限,也没有维护权限级别——将其比作“忽略权限的文件系统,或者不实现共识机制的区块链。

 

代码库在关键部分包含了 TODO 注释,例如 TODO: 在身份验证逻辑中的检查授权。状态解析(Matrix 用于处理跨分布式房间的冲突事件的算法)没有实现。尽管声称支持“完整的 Matrix 端到端加密堆栈”,但端到端加密验证似乎不完整。

 

Hacker News上的社区反应表明,有迹象表明 AI 提供了大量的帮助。评论者指出:

 

“我们做了 X”的博客文章最终变成了“我们做了 X 的一部分演示”,这在整个行业中已经过时了。解决方法很无聊:你只需要明确你所创造的内容。”另一位评论道:“基础设施公司的技术博客过去有两个目的:展示专业知识并建立信任。当帖子开始过度承诺时,你就失去了这两者。

 

Matrix 的开发人员 Jade Ellis 在Mastodon上写道,存储库在自述中显示了“有错位的 ASCII 图”。待办事项分散在各处。这表明代码带有未经彻底审查的 AI 生成输出的特征。

 

Hodgson 承认使用 LLM 来制作不熟悉的协议原型是一种挑战:

 

如果你正在使用 LLM 来原型化一个不熟悉的协议的实现,那么你可能不知道在哪里检查代理是否夸大了事实。

 

他表达了对作者的同情,同时注意到对“过度热情地使用 LLM,特别是如果他们自己投入了大量的时间和精力来理解和构建功能 Matrix 实现。

 

Cloudflare 在发布大约六小时后更新了这篇博文,并添加了一个免责声明,称其描述了一个概念验证和一个个人项目。然而,更新没有撤回正文中的特定技术声明。

 

尽管有这些批评,Hodgson 还是强调了这个演示“成功地说明了 Cloudflare Workers 是如何工作的,而且这些代码肯定可以作为未来工作服务器的基础。”他指出,Matrix 和 Cloudflare 在其他方面也有合作,包括使用 Cloudflare Calls 作为 MatrixRTC 后端的概念验证,Cloudflare 的 CDN 多年来一直保护着 matrix.org 的流量。

 

在无服务器基础设施上运行 Matrix 的技术方法仍然是可行的。这篇文章描述了用 D1 (SQLite)取代 PostgreSQL,用 KV 存储取代 Redis,并使用持久对象进行房间状态管理。这些架构选择可以在正确实现 Matrix 的核心联合和安全特性的情况下工作。

 

对于考虑使用 AI 辅助开发的开发者来说,这一事件凸显了未经审查的 AI 输出的风险。夸大 AI 生成实现的模式已成为技术博客中反复出现的问题,引发了对基础设施公司审查流程的质疑。

 

Hodgson 总结说,Matrix 基金会依靠会员费来资助规范工作、信任和安全工具以及生态系统支持。虽然组织成员在过去的一年里翻了一番,但基金会的财务状况还无法维持下去。他表示希望像 Cloudflare 这样受益于 Matrix 的公司可以考虑加入为会员。

 

Cloudflare 的博客文章和更新后的免责声明仍然有效。

 

原文链接:

https://www.infoq.com/news/2026/02/cloudflare-matrix-homeserver-ai/

Cursor 近日公布了 Agent Trace 开放规范草案,目标是解决 AI 生成代码在软件项目中的归属与标注问题。该提案以 RFC 形式发布,定义了一种厂商中立的格式,用于在版本控制系统中记录 AI 与人类协作产生的代码贡献。

基于其在 AI 辅助编程工具方面的实践经验,Cursor 发现,代码变更过程中对上下文的追踪能力仍然明显不足。以常见的 git blame 等工具为例,它们只能显示某一行代码“何时被修改”,却无法说明这次修改是由人类完成、由 AI 完成,还是二者协作的结果。Agent Trace 正是为了解决这一缺口,试图以结构化、可互操作的方式捕获这些关键信息。

从技术角度看,Agent Trace 是一套数据规范,使用基于 JSON 的 trace record(追踪记录)来关联具体的代码范围,以及背后的对话过程和参与者。代码贡献可以在文件级或行级进行追踪,按会话进行分组,并被标注为“人类”、“AI”、“混合”或“未知”。该模式还支持为 AI 生成的代码附加可选的模型标识,从而在不绑定具体厂商的前提下,实现更精确的归属记录。

此处输入图片的描述

在设计上,这一规范刻意保持了对存储方式的“中立性”。Cursor 并未规定追踪记录必须存放在哪里,开发者可以根据自身需求,将其保存为普通文件、git notes、数据库记录,或采用其他机制。Agent Trace 同时支持多种版本控制系统,包括 Git、Jujutsu 和 Mercurial,并引入了可选的内容哈希,用于在代码被移动或重构后,依然能够追踪其原始归属。

可扩展性是 Agent Trace 的核心设计目标之一。各厂商可以通过命名空间键(namespaced keys)附加额外的元数据,而不会破坏规范的兼容性。同时,该规范刻意回避了对 UI 形式、代码所有权语义的定义,也不试图评估代码质量或追溯训练数据来源,而是将关注点严格限定在“代码归属”和“可追溯性”本身。

Cursor 还提供了一份参考实现,展示 AI 编程代理如何在文件发生变化时,自动捕获并生成追踪记录。尽管示例基于 Cursor 自家的工具链,但其设计模式被明确定位为可复用方案,适用于其他编辑器和智能代理。

来自开发者社区的早期反馈,普遍强调了这一规范在代码审查和调试流程中的潜在价值。一位 X 用户评论道:

这才是真正在收拾 Agent 生成代码的烂摊子。等不及在 Review 里用了。

另一位用户则从可复现性的角度给予了肯定:

团队一旦搞不清 Agent 为啥跑偏,就会直接停工。Trace 解决了这个痛点,开放得正好。

作为一份 RFC,Agent Trace 明确欢迎社区反馈,同时也有意保留了一些尚未解决的问题,例如在合并(merge)、变基(rebase)以及大规模代理驱动代码变更场景下应如何处理。Cursor 将该提案定位为一个共同标准的起点,而非终极答案,以应对 AI 代理在软件开发流程中日益普及的现实趋势。

原文链接:

https://www.infoq.com/news/2026/02/agent-trace-cursor/

随着数字化的发展,传统行业也面临着数字化的改革要求,而其中钢铁行业的数字化需求是比较复杂和急迫的。而电子签章作为数字化中不可缺少的一部分同样在钢铁行业中的意义极其重要。钢铁行业对于电子签章的需求主要源于其流程复杂、参与方多、合规要求高、单据频繁等特点。

1.核心业务场景需求

1) 采购与销售合同签署

Ø 与矿石、煤炭等供应商的大额采购合同。

Ø 钢材销售合同(涉及贸易商、终端客户)。

Ø 需支持多方签署、跨境签署及长期合同管理。

2) 物流与仓储单据

Ø 提货单、运单、仓单的电子化签署。

Ø 实现物流公司、仓库、客户之间的快速流转。

3) 质检与合规文件

Ø 质量检验报告、产品合格证等需权威部门签字盖章。

Ø 环保、安全监管文件的合规存档。

4) 内部流程审批

Ø 生产计划单、设备采购申请、财务报销等内部流程。

Ø 需要各级负责人快速批阅,避免纸质传递延迟。

5) 供应链金融

Ø 与银行、金融机构的融资协议、仓单质押文件。

Ø 需符合《电子签名法》及金融监管要求。

2.核心功能需求

1) 强法律效力

Ø 符合《电子签名法》要求,支持CA数字证书、时间戳、区块链存证。

Ø 可对接司法鉴定机构,提供出证服务。

2) 高集成能力

Ø 与ERP(如SAP、用友)、OA、CRM、物流系统等无缝集成。

Ø 支持API批量调用,适应钢铁企业现有IT架构。

3) 全流程管控

Ø 从发起、审批、签署到归档的全链路追踪。

Ø 支持撤回、作废、补充签署等灵活操作。

4) 移动化签署

Ø 支持手机、平板等移动端签署,方便外勤人员(如销售、物流)。

Ø 可结合短信/微信通知,提升签署效率。

5) 安全与权限控制

Ø 印章权限分级管理(如集团统一管控子公司用章)。

Ø 操作留痕、防篡改、防伪造,支持人脸识别等身份核验。

3.行业特殊需求

1) 大宗交易合规性

单价高、数量大,需确保合同条款无篡改,保留完整证据链。

2) 跨境贸易适配

进口铁矿石、出口钢材时,需支持国际数字证书互认。

3) 复杂签署流程

一份合同可能涉及供应商、钢厂、物流、银行等多方,需支持会签、轮签等模式。

4) 环境适应性

部分生产场景(如钢厂车间)网络条件有 限,需支持离线签署或弱网环境处理。

4.实施途径

1) 分阶段推进

优先从内部审批、供应商对账等高频场景试点,逐步推广至销售、物流等核心环节。

2) 选择专业服务商

Ø 需选择在制造业或大宗商品领域有成熟案例的电子签章服务商。

Ø 确保服务商具备等保三级、ISO27001等安全资质。

3) 制度配套

制定企业电子签章管理办法,明确使用范围、审批权限和法律责任。

4) 培训与推广

针对业务人员(如采购、销售)和技术人员分别培训,降低使用门槛。

5.预期收益

1) 效率提升

合同签署周期从数天缩短至几分钟,加速交易周转。

2) 成本降低

减少纸张、打印、快递、仓储管理成本。

3) 风险控制

全流程可追溯,减少印章冒用、合同篡改等风险。

4) 数字化转型

推动钢铁企业向“智慧供应链”转型,提升行业竞争力。

6.注意事项

1) 法律合规:涉及国际业务时需确认目标国对电子签章的认可程度。

2) 系统兼容性:确保与老旧工业系统(如MES)的对接可行性。

3) 长期存证:重要文件需保障10年以上可查验、可取证。

如果需要进一步针对具体场景(如“钢厂与经销商订单流程”或“跨境铁矿石采购”)设计解决方案,可咨询专业的电子签章厂商,如:北京安证通、契约锁、法大大等。

本文首发于 Aloudata 官方技术博客:《告别伪一体!Aloudata CAN 真·管研用一体的落地路径与价值佐证》转载请注明出处。

摘要:本文深入探讨了传统指标平台在实现“管、研、用”一体化时面临的三大核心痛点:口径管理混乱、研发效率低下、使用成本高昂。针对这些问题,文章介绍了基于 NoETL 语义编织技术的 Aloudata CAN 平台如何通过统一语义层和智能物化引擎,构建“定义即开发、治理、服务”的自动化闭环。同时,提供了从战略筹备到价值深化的四步走落地路径,并结合平安证券、麦当劳等标杆客户的量化成效,为企业数据治理与指标体系建设提供可复制的实践指南。

在数据驱动决策的时代,企业普遍希望通过建设指标平台来统一数据口径、提升分析效率。然而,许多项目最终却陷入“伪一体”的困境:管理、研发、使用三个环节依然割裂,导致口径混乱、响应迟缓、成本高昂。本文将深度解构传统模式的痛点,并阐述 Aloudata CAN 如何基于 NoETL 语义编织技术,实现真正的“管研用一体”,并提供已验证的落地路径与价值佐证。

一、 传统“伪一体”模式的三大核心痛点

传统模式下,“管、研、用”的割裂主要体现在技术架构和协作流程上,形成了事实上的信息孤岛。

  • “管”的痛点:静态元数据目录,口径管理失控
    依赖静态的元数据目录(Catalog)仅能记录指标来源,无法承载动态的业务逻辑变化。指标口径的维护高度依赖人工沟通和文档,极易出现偏差,导致跨部门会议沦为“数据辩论会”,决策效率低下。
  • “研”的痛点:固化物理宽表,敏捷响应受阻
    分析路径被预建的物理宽表所固化。任何新的分析维度组合需求,都可能需要启动一次新的 ETL 任务开发、测试和上线,周期以“天”或“周”计,严重拖慢业务响应速度。
  • “用”的痛点:烟囱式开发,成本居高不下
    “烟囱式”的开发模式为每个报表或应用单独建设物理宽表,导致数据仓库中充斥着大量相似、冗余的中间表。这不仅消耗巨大的存储和计算资源,还形成了沉重的技术债,使得总拥有成本(TCO)持续攀升。

这三个环节的割裂,使企业始终在“数据分析不可能三角”(口径统一、敏捷响应、成本可控)中艰难妥协。

二、 Aloudata CAN 的“真·管研用一体”技术架构

Aloudata CAN 基于 NoETL 语义编织 (Semantic Fabric) 技术,通过两大核心引擎重塑协作范式,实现逻辑定义与物理执行的解耦。

  1. 统一语义层(虚拟业务事实网络):作为“管”的基石,数据团队无需预先物理打宽。只需通过声明式策略,基于 DWD 明细数据定义业务实体间的逻辑关联(Join),系统即在逻辑层面构建一个“虚拟明细大宽表”。所有指标均基于此统一语义层定义,从根本上保证口径一致。
  2. 智能物化加速引擎:作为“研”的自动化核心,基于用户对指标和维度的声明式加速策略,系统自动编排物化任务,生成并维护最优的物化视图。查询时,语义引擎自动进行 SQL 改写和智能路由,透明命中最优物化结果,实现亿级数据秒级响应(P90<1s)。
  3. 开放化指标服务:作为“用”的统一出口,通过标准 API/JDBC,一处定义的指标可向 FineBI、Quick BI、自建应用、AI 大模型等任意消费端提供统一、实时、准确的数据服务。

至此,形成了“定义即开发、定义即治理、定义即服务”的自动化闭环。

三、 四步走落地路径:从试点到深化

基于众多客户实践,成功落地“真·管研用一体”可遵循以下四阶段模型:

阶段一:战略筹备与灯塔选择(第1-2个月)

  • 关键动作:组建跨部门联合项目组,选择1-2个业务价值明确、痛点清晰的高频场景(如核心业务报表)作为“灯塔项目”。

阶段二:价值验证与能力内化(第3-4个月)

  • 关键动作:在平台中快速配置并上线灯塔场景指标,让业务分析师掌握声明式定义方式。重点产出量化成效报告,如“指标交付周期从2周缩短至2天”,建立内部信心。

阶段三:全面推广与组织建设(第6-12个月)

  • 关键动作:将已验证模式推广至其他业务线,建立企业级的指标规范、开发流程和治理章程,形成可持续的协同机制。

阶段四:生态融合与价值深化(长期)

  • 关键动作:将平台作为统一的指标服务中台,与BI、AI、业务系统深度集成,构建坚实的 AI-Ready 数据底座,激活数据民主化。

四、 价值佐证:标杆客户的量化成效

多个行业头部客户的实践数据,验证了该模式在提效、降本、增质方面的显著价值。

客户行业核心场景关键量化成效模式验证
证券(平安证券)指标统一管理、业务自助分析开发工作量减少 50%,效率提升 10 倍,指标口径 100% 一致,TCO 节约 50%“136”协作模式(10% 科技+30% 分析师+60% 业务)
餐饮(麦当劳中国)实时业绩监控、智能归因沉淀 1000+ 指标、250+ 维度,百亿级数据 P90<1s,日均百万级 API 调用覆盖 30+ 业务场景的标准化指标服务
服饰(某头部品牌)营销活动分析1 个月沉淀 300+ 指标,指标开发维护成本降低 70%,决策效率提升 10 倍361 个指标 × 120 个维度的沉淀复用机制
央国企(中交一公局)集团数据治理、智能问数业务自助完成 80% 数据需求,问数准确率达 92%AI-Ready 数据底座的构建

五、 实施建议:确保成功的五个关键动作

  1. 技术策略:采用“存量挂载、增量原生、存量替旧”的三步走资产演进法则,平滑过渡。
  2. 组织保障:建立业务与IT的联合项目组,确保需求与技术双向对齐。
  3. 切入点选择:优先解决“高频高痛”的报表或分析场景,快速交付可见价值。
  4. 能力建设:重点培训业务分析师掌握“声明式指标定义”,激活数据自服务。
  5. 价值度量:明确上线前后的效率、成本、质量基线,用数据证明ROI。

六、 常见问题解答(FAQ)

Q1: Aloudata CAN 和传统指标平台或 BI 内置的指标模块有何本质区别?

传统方案是静态的元数据目录,仅记录来源,无法保证逻辑同步更新,且分析受限于物理宽表。Aloudata CAN 是一个动态的语义计算引擎,基于 DWD 明细层构建“虚拟业务事实网络”,实现一处定义、处处使用、自动计算。

Q2: 引入 Aloudata CAN 是否需要推翻现有的数据仓库和 BI 工具?

不需要。平台采用 Headless 架构,向下对接现有 DWD 层,向上通过标准接口服务各类 BI 工具。其目标是“做轻数仓”,通过减少不必要的物理宽表来优化现有架构。

Q3: 如何衡量“真·管研用一体”项目的成功?

可从三个维度衡量:效率(如指标平均交付周期)、成本(如中间表减少数量、TCO下降)、质量(如跨部门数据一致性、问题工单数)。建议项目启动前确立基线。

Q4: 数据治理基础较弱的企业,直接上这种平台门槛是否太高?

相反,这是实现“弯道超车”的机遇。平台通过配置化、低代码方式降低技术门槛,帮助企业跳过“先乱后治”阶段,一步到位构建统一、敏捷的数据服务能力。

七、 核心要点总结

  1. 痛点根源:传统模式的失败源于静态元数据目录、固化物理宽表与烟囱式开发流程的技术性割裂。
  2. 技术内核:Aloudata CAN 通过 NoETL 语义编织构建统一语义层,结合智能物化引擎,实现“定义即开发、治理、服务”的自动化闭环。
  3. 落地路径:遵循“战略筹备→价值验证→全面推广→生态深化”的四步模型,以业务价值驱动。
  4. 价值实证:多个行业实践表明,该模式能带来指标开发效率提升 10 倍以上、口径一致性 100%、TCO 降低 50% 的量化成效。
  5. 战略意义:这不仅是一次技术升级,更是构建 AI-Ready 数据底座、实现数据民主化的战略投资。
    • *

本文更详细的技术实现、架构图与案例细节,请访问 Aloudata 官方技术博客阅读原文:https://ai.noetl.cn/knowledge-base/aloudata-can-real-path-val...

现在小学不布置寒假作业了,需要自己买题给孩子学。我就想是不是可以针对一二年级的知识点做一个在线刷题学习的,再增加一点游戏性。

目前每天让他学几分钟,感觉还是可以的,分享给大家。

地址: https://yinianji.vercel.app/
技术栈:
React 19 + TypeScript + Vite 7
PWA 支持(离线缓存、可安装)
Web Audio API (原生音频)

有什么建议欢迎给我反馈。
tupian1
tupian2
tupian3
tupian4

在当今大语言模型快速发展的时代,推理能力已成为决定模型表现的关键因素。然而,许多开发者和用户可能没有意识到,通过精心设计的提示词技术,可以显著提升模型在复杂推理任务中的表现。本文将深入探讨四种前沿的推理增强提示技术:思维链(Chain of Thought, CoT)、自一致性(Self-Consistency)、思维树(Tree-of-Thought, ToT)和ReAct,分析它们的原理、应用场景及最佳实践,帮助你更有效地利用这些技术提升AI应用的推理质量。

关键要点

  • 思维链(CoT)通过引导模型分步推理,显著提升数学和逻辑问题的准确性
  • 自一致性(SC)通过多路径采样和多数投票机制,增强推理结果的稳定性
  • 思维树(ToT)采用树状结构探索多条推理路径,适用于复杂规划任务
  • ReAct结合推理与行动,通过迭代循环提升复杂任务的解决能力
  • 四种技术各有优劣,可根据任务复杂度和计算资源选择最适合的方法

一、思维链(Chain of Thought, CoT):基础推理增强技术

思维链(CoT)是推理增强提示技术中最基础、应用最广泛的方法。其核心思想是引导模型不要直接给出答案,而是通过逐步推理的方式展示思考过程,类似于人类解决复杂问题时的思考模式。

1.1 CoT的工作原理

CoT通过在提示词中添加引导性语句,如"Let's think step by step"(让我们一步步思考),激发模型的推理能力。具体来说:

  • 分步推理:模型被引导将复杂问题拆分为一系列简单的中间步骤
  • 逻辑展示:模型在输出最终答案前,先展示推理过程
  • 逐步验证:每个中间步骤都可以被验证,提高整体推理的可靠性

例如,对于数学问题"如果John有3个苹果,送出1个,还剩几个?",使用CoT提示后,模型会先输出推理过程:

"John最初有3个苹果。
他送出1个苹果。
所以剩下的苹果数量是3-1=2。
因此,答案是2。"

这种分步思考方式大大提高了模型在多步骤推理任务中的准确性。

1.2 CoT的实现方式

CoT主要有三种实现方式:

实现方式说明适用场景
零样本CoT直接添加"Let's think step by step"引导语简单推理任务,如基础数学题
少样本CoT提供几个包含推理过程的示例复杂推理任务,如多步骤数学题
自动CoT模型自动生成推理链开放域问题,如创意写作中的逻辑推导

零样本CoT是最简单直接的方法,只需在问题前添加引导性语句即可。例如:

"John有3个苹果,送出1个,还剩几个?
让我们一步步思考:"

少样本CoT则需要提供几个包含推理过程的示例,帮助模型学习如何生成推理链。例如:

"示例1:
问题:5个孩子每人有4块饼干,总共有多少块饼干?
让我们一步步思考:
每个孩子有4块饼干,共有5个孩子。
所以总共有4×5=20块饼干。
答案:20块饼干。"

"示例2:
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
让我们一步步思考:
假设所有动物都是鸡,那么会有35个头和70条腿(35×2)。
实际有94条腿,多出24条腿。每头牛比鸡多2条腿,所以牛的数量是24÷2=12头。
鸡的数量是35-12=23只。
答案:23只鸡和12头牛。"

"现在,请解决这个问题:
停车场有3辆车,又有2辆车到达,现在有多少辆车?
让我们一步步思考:"

1.3 CoT的优势与局限

优势

  • 实现简单,只需添加引导性语句
  • 提升模型在数学、逻辑推理等任务的准确率
  • 增加推理过程的可解释性
  • 无需额外训练或微调模型

局限

  • 输出稳定性不足,多次运行可能得到不同结果
  • 无法处理多路径依赖的复杂问题
  • 单线性推理容易受早期错误影响

根据研究数据,CoT在GSM8K数据集上将模型的准确率提升了约17.9%,证明了其在数学推理任务中的有效性。然而,对于更复杂的问题,如需要探索多种可能路径的任务,CoT的局限性就显得明显。

二、自一致性(Self-Consistency):CoT的稳健性增强

自一致性(SC)是对CoT的改进方法,通过多路径采样和多数投票机制,显著提高推理结果的稳定性。它假设一个复杂问题可能有多种解决路径,但正确答案通常会在多次采样中被频繁生成。

2.1 SC的工作原理

SC的核心机制包括三个步骤:

  1. 多次采样:让模型针对同一个问题生成多个不同的推理路径
  2. 多数投票:统计这些路径的最终答案,选择出现频率最高的答案作为最终结果
  3. 结果聚合:将多个推理路径的结果整合,提高最终答案的可靠性

与CoT相比,SC的关键区别在于它不依赖单一推理路径,而是通过"群体智慧"选择最一致的答案。这种方法类似于让多位专家独立思考同一问题,然后采纳他们共同认同的结论

例如,在解决"37×42"这样的乘法问题时,SC会生成多个推理路径:

路径1:37×40=1480,37×2=74,1480+74=1554
路径2:40×42=1680,减去3×42=126,得到1680-126=1554
路径3:30×42=1260,7×42=294,1260+294=1554
路径4:错误路径:37×42=1454

通过多数投票,正确答案1554会被选中,而错误答案则被过滤。

2.2 SC的实现方式

SC的实现需要结合采样技术与结果聚合策略:

  • 采样设置:启用随机采样而非贪婪解码,通常设置do_sample=True和较高的温度值(0.7-0.9)
  • 样本数量:建议生成5-10个不同的推理路径
  • 投票机制:简单的多数投票或加权投票(考虑模型置信度)

以下是SC的Prompt模板示例:

"请解决以下数学问题,生成5个不同的推理路径,然后选择最常见的正确答案。
问题:停车场有3辆车,又有2辆车到达,现在有多少辆车?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"

2.3 SC的优势与局限

优势

  • 显著提高推理结果的稳定性
  • 通过多数投票机制过滤错误
  • 不依赖于复杂的模型架构或训练
  • 在数学问题、逻辑推理等任务中表现优异

局限

  • 计算成本高,需要多次模型调用
  • 仅关注最终答案的一致性,不评估推理过程本身
  • 在某些任务中,正确答案可能不会被频繁生成

SC在计算资源有限的情况下,建议先从少量样本(如3-5个)开始,以实现大部分性能提升。根据研究,SC在GSM8K数据集上比CoT高出约12.2%的准确率,证明了其在复杂推理任务中的有效性。

三、思维树(Tree-of-Thought, ToT):复杂规划任务的解决方案

思维树(ToT)是推理增强提示技术中最复杂、也最强大的方法。它超越了CoT的线性思维和SC的简单多数投票,将推理过程结构化为树形分支,在每一步探索多个可能的推理方向,并通过评估机制选择最优路径。

3.1 ToT的工作原理

ToT的工作原理类似于搜索算法在迷宫中寻找出口:

  1. 初始节点:从问题本身开始,作为树的根节点
  2. 分支生成:在每一步,模型探索多个可能的推理方向,形成分支
  3. 状态评估:对每个分支进行评估,判断其是否可能通向正确答案
  4. 路径选择:保留最有希望的分支,舍弃低效或错误路径
  5. 动态调整:根据评估结果,动态调整下一步的探索方向

例如,在解决24点游戏问题时,ToT会同时探索多种运算组合:

初始状态:9, 8, 6, 3
分支1:9×8=72 → 72, 6, 3
分支2:9+8=17 → 17, 6, 3
分支3:9-8=1 → 1, 6, 3
分支4:8÷6≈1.333 → 9, 1.333, 3

然后对每个分支进行评估,保留最有希望的路径继续探索。这种树状结构的推理方式大大提高了模型处理复杂规划问题的能力。

3.2 ToT的实现方式

ToT的实现需要更复杂的Prompt设计和参数配置:

  • 分支生成:提示模型在每一步生成多个可能的推理方向
  • 评估机制:可以是模型自我评估或独立评估模块
  • 搜索策略:广度优先搜索(BFS)或深度优先搜索(DFS)
  • 剪枝策略:根据评估结果,保留最有前景的分支

以下是ToT的Prompt模板示例,以24点游戏为例:

"你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考:

  1. 从给定的四个数字开始。
  2. 在每一步,选择两个数字,使用加减乘除运算生成新数字。
  3. 将新数字与剩余数字一起作为下一步的输入。
  4. 重复此过程,直到得到24。
  5. 如果无法得到24,请返回最接近的可能结果。

规则:

  • 每步只能使用两个数字进行运算。
  • 运算结果必须是整数。
  • 避免重复使用相同的数字组合。
  • 避免使用已经尝试过且失败的运算路径。

示例:
输入:14, 8, 8, 2
步骤1:14-2=12 → 剩余数字:12, 8, 8
步骤2:12×8=96 → 剩余数字:96, 8
步骤3:96÷8=12 → 剩余数字:12
无法得到24,最接近结果是12。

现在,请解决以下24点问题:
输入:9, 8, 6, 3
"

3.3 ToT的关键参数配置

ToT的实现依赖于多个关键参数的配置:

  • n_generate:每步生成的分支数量(通常3-5)
  • n_evaluate:每步评估的分支数量(通常2-3)
  • nselect:每步保留的最佳分支数量(通常2-3)
  • max_depth:树的最大深度(根据问题复杂度设置)
  • temperature:控制生成多样性(通常0.7)
  • search_strategy:选择BFS或DFS等搜索策略

参数调优策略

  • 对于计算资源有限的情况,建议使用较小的nGenerate(如3)和nSelect(如2)
  • 对于需要深度探索的问题,可适当增加max_depth(如5-6)
  • BFS适合需要全面探索所有选项的问题,DFS适合快速深入到某个潜在解决方案
  • 在评估过程中,可设置forbidden_steps避免重复探索已失败的路径

3.4 ToT的优势与局限

优势

  • 通过多路径探索解决复杂规划问题
  • 允许回溯和动态调整,避免"一错全错"的情况
  • 在需要探索多种可能性的任务中表现优异
  • 在24点游戏等任务中,ToT的成功率可达74%,而CoT仅4%

局限

  • 计算成本极高,需要大量模型调用
  • 实现复杂,需要设计合理的Prompt和参数
  • 对于简单问题,可能过度复杂化推理过程
  • 评估机制的质量直接影响最终结果

在实际应用中,ToT特别适合需要多步决策和路径规划的任务,如游戏策略制定、复杂数学问题求解、多条件约束下的规划问题等。

四、ReAct:推理与行动的协同

ReAct(Reasoning and Action)是一种结合推理与行动的提示技术,它允许模型在推理过程中调用外部工具获取信息或执行特定操作,从而实现更强大的问题解决能力。

4.1 ReAct的工作原理

ReAct的核心是"推理-行动"的迭代循环:

  1. 推理阶段:模型分析当前问题状态,生成推理步骤
  2. 行动阶段:根据推理结果,选择并执行合适的工具或操作
  3. 观察阶段:接收工具执行的结果或观察到的新信息
  4. 更新状态:将新信息整合到当前问题状态中
  5. 重复循环:回到推理阶段,基于更新后的状态继续推理

这种机制类似于人类解决问题时的"思考-行动-观察-再思考"循环,使模型能够动态调整推理路径,处理更复杂的问题。

例如,在解决需要实时数据的问题时,ReAct允许模型调用网络搜索工具:

"思考:要回答特斯拉2023年Q3在华销量及主要竞品,首先需要获取权威销量数据源。
行动:搜索[中国乘联会官网]
观察:找到季度新能源车销量报告,显示特斯拉销量为15万辆。
思考:需识别特斯拉竞品,应考虑同价位区间车型。
行动:检索[30万价位纯电车型]
观察:比对小鹏G9、蔚来ET5等车型销量数据。
思考:整合时间维度数据,分析市场趋势。
行动:调用数据分析模块
观察:显示特斯拉在中国市场占有率约为18%。
思考:最终答案应包含具体销量和主要竞品信息。
行动:无
最终答案:特斯拉2023年Q3在华销量约为15万辆,主要竞争对手包括小鹏G9和蔚来ET5。"

4.2 ReAct的实现方式

ReAct的实现需要定义明确的工具集和交互格式:

  • 工具定义:列出可用的外部工具及其功能
  • 交互格式:规定"Thought/Action/Action Input/Observation"的循环格式
  • 终止条件:定义何时停止循环并输出最终答案
  • 异常处理:处理工具调用失败或无效结果的情况

以下是ReAct的Prompt模板示例:

"你是一个强大的AI助手,可以访问以下工具解决复杂问题:

  • web_search: 用于获取互联网上的实时信息,如新闻、数据和知识
  • python_interpreter: 用于执行Python代码,解决数学计算或数据处理问题
  • image Generation: 用于生成或分析图像内容

请按照以下格式思考和行动

  1. Thought: 分析当前问题,确定下一步需要的信息或操作
  2. Action: 如果需要外部帮助,请选择要使用的工具;如果不需要,请写"无"
  3. Action Input: 如果选择了工具,请提供具体参数;如果不需要,请留空
  4. Observation: 你将获得工具执行的结果
  5. 重复上述步骤,直到问题解决

示例

问题:谁是目前世界上最高的山峰?
Thought: 我需要确认最新的山峰高度数据,包括珠穆朗玛峰和其他可能的候选山峰。
Action: web_search
Action Input: 最新世界最高山峰数据
Observation: 根据搜索结果,珠穆朗玛峰仍被公认为世界最高峰,海拔8848.86米。
Thought: 确认无误,珠穆朗玛峰是最高峰。
Action: 无
Final Answer: 珠穆朗玛峰,海拔8848.86米。

现在,请解决以下问题:
问题:请计算从上海到北京的高铁票价,并比较不同班次的舒适度。

"

4.3 ReAct的关键参数配置

ReAct的实现需要合理配置以下参数:

  • 工具列表:根据任务需求定义可用工具
  • 最大步骤:设置max_steps(通常5-10),防止无限循环
  • 温度参数:控制推理阶段的创造性(通常0.5-0.7)
  • 置信度阈值:定义模型对答案的置信度要求
  • 工具优先级:设置工具调用的优先级和权重

最佳实践

  • 明确定义工具的功能和使用限制
  • 提供清晰的示例引导模型正确使用工具
  • 考虑工具调用的开销,优先选择轻量级工具
  • 在推理阶段强调对工具输出的分析和整合

4.4 ReAct的优势与局限

优势

  • 结合推理与外部行动,解决需要实时信息的问题
  • 通过迭代循环,处理复杂的多步骤任务
  • 显著减少"幻觉"问题,提高答案的准确性
  • 在需要专业工具的任务中表现优异,如编程、数据分析等

局限

  • 实现复杂,需要设计工具接口和交互流程
  • 计算开销大,每次工具调用都需要额外处理
  • 工具选择可能引入新的错误或偏见
  • 需要模型具备良好的工具调用能力

根据研究,ReAct在需要工具支持的任务中,比单纯使用CoT或SC的准确率平均高出12-30%,证明了其在复杂问题解决中的潜力。

五、四种技术的对比与选择策略

四种推理增强技术各有特点,适用于不同场景。下表对它们进行了全面比较:

技术复杂度计算成本可解释性适用场景准确率提升
CoT简单数学、逻辑推理、常识问答中等(约15-20%)
SC中等中等中等复杂数学、多解问题、需要高稳定性的任务较高(约17-25%)
ToT复杂规划、多路径依赖、需要探索多种可能性的任务最高(可达70%+)
ReAct中高中高中等需要工具支持、实时信息、多步骤交互的任务较高(约12-30%)

选择策略

  1. 简单推理任务:优先选择CoT,因其实现简单且能提供清晰的推理过程

    • 适用场景:基础数学题、逻辑判断、常识问答
    • 示例:计算简单算术题、判断简单逻辑关系
  2. 需要高稳定性的任务:选择SC,通过多路径采样和投票提高结果可靠性

    • 适用场景:重要决策支持、学术论文验证、医疗诊断参考
    • 示例:数学考试题目解答、法律条款解释、医疗诊断参考
  3. 复杂规划任务:选择ToT,通过多路径探索和动态评估解决复杂问题

    • 适用场景:游戏策略制定、多条件约束规划、创意写作构思
    • 示例:24点游戏解法、商业策略制定、多结局故事创作
  4. 需要外部信息的任务:选择ReAct,结合推理与工具调用处理复杂现实问题

    • 适用场景:实时数据分析、事实核查、跨领域知识整合
    • 示例:市场趋势分析、历史事件验证、多源信息综合回答

技术融合策略

在实际应用中,可以考虑技术融合以获取最佳效果:

  • CoT+SC:先使用CoT生成高质量推理路径,再用SC进行多路径采样和投票
  • ToT+SC:结合ToT的多路径探索和SC的投票机制,提高复杂规划任务的可靠性
  • ReAct+CoT:在ReAct的行动阶段使用CoT引导模型生成更合理的工具调用指令
  • ReAct+SC:在ReAct的推理阶段应用SC,提高工具选择决策的稳健性

技术选择的关键因素

  1. 任务复杂度:简单任务用CoT,中等复杂度用SC或ReAct,高度复杂任务用ToT
  2. 计算资源:受限资源下优先选择CoT或SC,充足资源下考虑ToT或ReAct
  3. 推理透明度需求:需要解释推理过程时选择CoT或ToT,仅关注结果时选择SC
  4. 实时信息需求:需要访问外部信息或工具时选择ReAct
  5. 多路径探索需求:需要探索多种可能解决方案时选择ToT或SC

六、数学问题中的推理增强技术应用

数学问题是最能体现推理增强技术优势的应用场景之一。下面通过具体案例展示四种技术在数学问题中的应用。

6.1 CoT在数学问题中的应用

CoT通过引导模型分步推理,显著提升数学问题的解决能力。下面是一个使用CoT解决代数问题的案例:

问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?

CoT Prompt:

"请解决以下代数问题,使用逐步推理过程。
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
提示:鸡有1个头和2条腿,牛有1个头和4条腿。
让我们一步步思考:
"

模型输出:

"首先,设鸡的数量为x,牛的数量为y。
根据头的数量,我们有x + y = 35。
根据腿的数量,我们有2x + 4y = 94。
我们可以从第一个方程解出x = 35 - y。
将x代入第二个方程:2(35 - y) + 4y = 94 → 70 - 2y + 4y = 94 → 70 + 2y = 94 → 2y = 24 → y = 12。
因此,牛的数量是12头,鸡的数量是35 - 12 = 23只。
所以,农场里有23只鸡和12头牛。"

CoT在数学问题中的优势在于能够清晰展示每一步的推导过程,便于验证和理解

6.2 SC在数学问题中的应用

SC通过多路径采样和投票机制,提高数学问题答案的可靠性。下面是一个使用SC解决概率问题的案例:

问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少?

SC Prompt:

"请解决以下概率问题,生成5个不同的推理路径,然后选择最常见的正确答案。
问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"

模型输出:

推理路径1:

  1. 30%的Huhulians拥有至少一台电视。
  2. 这些拥有电视的人中24%拥有至少四台。
  3. 因此,拥有至少四台电视的比例是30% × 24% = 7.2%。
    答案:7.2%

推理路径2:

  1. 总人口中拥有至少一台电视的比例是30%。
  2. 这些人中拥有至少四台电视的比例是24%。
  3. 因此,拥有至少四台电视的总比例是0.3 × 0.24 = 0.072 = 7.2%。
    答案:7.2%

推理路径3:

  1. 30%的人口拥有至少一台电视。
  2. 其中24%拥有至少四台,因此需要计算这两个百分比的乘积。
  3. 30% × 24% = 7.2%。
    答案:7.2%

推理路径4:

  1. 30%拥有至少一台电视。
  2. 这些人中有24%拥有至少四台。
  3. 因此,拥有至少四台的比例是0.3 × 0.24 = 0.072 = 7.2%。
    答案:7.2%

推理路径5:

  1. 错误路径:假设24%是相对于总人口的比例,而不是电视拥有者。
  2. 直接计算30% + 24% = 54%,显然不合理。
    答案:54%

最终答案:7.2%

SC通过生成多个推理路径并投票选择,有效过滤了推理过程中的错误,提高了最终答案的可靠性

6.3 ToT在数学问题中的应用

ToT特别适合需要多路径探索的数学问题,如24点游戏或复杂方程求解。下面是一个使用ToT解决24点游戏的案例:

问题:使用数字9, 8, 6, 3通过加减乘除运算得到24。

ToT Prompt:

"你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考:

  1. 从给定的四个数字开始。
  2. 在每一步,选择两个数字,使用加减乘除运算生成新数字。
  3. 将新数字与剩余数字一起作为下一步的输入。
  4. 重复此过程,直到得到24。
  5. 如果无法得到24,请返回最接近的可能结果。

规则:

  • 每步只能使用两个数字进行运算。
  • 运算结果必须是整数。
  • 避免重复使用相同的数字组合。
  • 避免使用已经尝试过且失败的运算路径。

输入:9, 8, 6, 3
"

模型输出:

初始状态:9, 8, 6, 3

分支1:9 × 8 = 72 → 剩余:72, 6, 3
分支2:9 + 8 = 17 → 剩余:17, 6, 3
分支3:9 - 8 = 1 → 剩余:1, 6, 3
分支4:8 ÷ 6 ≈ 1.333 → 剩余:9, 1.333, 3

评估分支:

  • 分支1:72, 6, 3 → 可能路径:72 ÷ 6 = 12 → 12 × 3 = 36
  • 分支2:17, 6, 3 → 可能路径:17 - 6 = 11 → 11 × 3 = 33
  • 分支3:1, 6, 3 → 可能路径:6 × 3 = 18 → 18 ÷ 1 = 18
  • 分支4:9, 1.333, 3 → 可能路径:9 - 1.333 ≈ 7.667 → 7.667 × 3 ≈ 23.001

选择最有希望的分支3和分支4继续探索。

分支3-1:6 × 3 = 18 → 剩余:1, 18
分支3-2:9 - 6 = 3 → 剩余:3, 8, 3
分支4-1:9 - 1.333 ≈ 7.667 → 剩余:7.667, 3
分支4-2:1.333 × 3 ≈ 4 → 剩余:9, 4

评估分支:

  • 分支3-1:1, 18 → 18 ÷ 1 = 18
  • 分支3-2:3, 8, 3 → 3 × 8 = 24 → 成功!
  • 分支4-1:7.667, 3 → 7.667 × 3 ≈ 23.001
  • 分支4-2:9, 4 → 9 - 4 = 5

在分支3-2中,模型成功找到了解法:3 × 8 = 24,从而解决了问题。这种树状结构的探索方式使模型能够系统地尝试各种可能性,大大提高了复杂数学问题的解决率。

6.4 ReAct在数学问题中的应用

ReAct通过结合推理与工具调用,可以解决需要精确计算或外部数据的数学问题。下面是一个使用ReAct解决复杂数学问题的案例:

问题:计算从1到500的所有数字键入所需的总按键次数。

ReAct Prompt:

"你是一个强大的数学问题解决者,可以使用Python解释器执行代码进行精确计算。请按照以下格式思考和行动:

  1. Thought: 分析问题,确定需要哪些信息或计算
  2. Action: 如果需要计算,请选择python_interpreter;如果不需要,请写
  3. Action Input: 提供要执行的Python代码
  4. Observation: 你将获得代码执行的结果
  5. 重复上述步骤,直到问题解决

问题:计算从1到500的所有数字键入所需的总按键次数。
"

模型输出:

Thought: 首先需要确定1到500之间各个数字的位数。一位数(1-9)需要1次按键,两位数(10-99)需要2次,三位数(100-500)需要3次。
Action: python_interpreter
Action Input:

# 计算1-9的数字数量
one_digit = 9
# 计算10-99的数字数量
two_digit = 90
# 计算100-500的数字数量
three_digit = 500 - 99
# 计算总按键次数
total = one_digit * 1 + two_digit * 2 + three_digit * 3
print(total)

Observation: 代码执行结果为1392。
Thought: 验证计算是否正确。1-9有9个数字,每个1位,共9×1=9次。
10-99有90个数字,每个2位,共90×2=180次。
100-500有401个数字,每个3位,共401×3=1203次。
总和为9+180+1203=1392次,计算正确。
Action: 无
Final Answer: 1392次。

ReAct的优势在于能够处理需要精确计算或外部数据的数学问题,通过工具调用确保计算的准确性

七、创意写作中的推理增强技术应用

创意写作是另一种能够受益于推理增强技术的领域,特别是在需要逻辑连贯或多路径探索的创作中。以下是四种技术在创意写作中的应用案例。

7.1 CoT在创意写作中的应用

CoT可以引导模型在创意写作中进行分步思考,确保故事的逻辑连贯性。下面是一个使用CoT进行故事续写的案例:

问题:请续写以下故事:"小明推开那扇古老的大门,里面是一个他从未见过的神秘世界..."

CoT Prompt:

"请续写以下故事,使用逐步推理确保逻辑连贯和情节合理。
初始故事:小明推开那扇古老的大门,里面是一个他从未见过的神秘世界...
提示:请先思考可能的发展方向,然后选择最合适的一个进行续写。
让我们一步步思考:

  1. 分析初始情节的关键元素:古老大门、神秘世界、主角小明。
  2. 考虑可能的续写方向:魔法冒险、时间旅行、平行宇宙等。
  3. 评估每个方向的可行性:是否与初始情节一致?是否有足够的发展空间?
  4. 选择最合适的方向并构建后续情节。
  5. 确保人物动机和情节发展合理。

"

模型输出:

  1. 分析关键元素:古老大门暗示魔法或神秘力量,神秘世界为故事提供了丰富的可能性,主角小明需要有明确的动机和目标。
  2. 可能方向:
    a. 魔法冒险:小明进入魔法世界,学习魔法,解决难题。
    b. 时间旅行:小明穿越到过去或未来,改变历史或探索未来。
    c. 平行宇宙:小明进入另一个平行世界,遇到另一个自己,探索两个世界的联系。
  3. 评估方向:
    a. 魔法冒险:与初始情节高度一致,有丰富的探索空间。
    b. 时间旅行:需要解决时间悖论,可能增加复杂性。
    c. 平行宇宙:需要解释两个世界的联系,可能分散故事焦点。
  4. 选择魔法冒险方向,构建以下情节:
    小明进入魔法世界后,发现了一个正在被黑暗力量威胁的王国。
    他遇到了一位年迈的巫师,巫师告诉他小明是预言中的救世主。
    小明开始学习魔法,最终在一场大战中击败了黑暗领主,拯救了王国。
  5. 确保动机合理:小明好奇并勇敢,这是他探索神秘世界的动力。
    情节发展合理:从发现世界到学习魔法,再到最终战斗,形成一个完整的故事弧线。

续写故事:
小明推开那扇古老的大门,里面是一个他从未见过的神秘世界。他发现自己站在一个巨大的魔法图书馆前,书架高达天际,书籍闪烁着奇异的光芒。

一位年迈的巫师从阴影中走出,他对小明说:"年轻的冒险者,你终于来了。我是守护者,预言中说你会带来光明。"

小明询问发生了什么事,巫师叹息道:"黑暗领主已经占领了我们的王国,只有预言中的救世主才能击败他。而你,就是那个人。"

巫师带领小明进入图书馆深处,教他使用魔法书中的力量。经过数月的学习,小明掌握了强大的魔法技能。

一天,黑暗领主的军队逼近图书馆。小明知道是时候面对挑战了。他拿起最强大的魔法书,与巫师一起前往战场。

经过一场激烈的战斗,小明召唤出强大的光明魔法,彻底击败了黑暗领主。王国重获自由,小明成为了传奇英雄。

CoT在创意写作中的优势在于能够确保故事发展的逻辑性和连贯性,避免情节漏洞

7.2 SC在创意写作中的应用

SC可以生成多个故事版本,通过投票选择最受欢迎的结局,提高创作的多样性。下面是一个使用SC进行故事结局创作的案例:

问题:请为以下故事创作三个不同的结局,然后选择最合理的一个。
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。

SC Prompt:

"请为以下故事创作三个不同的结局,然后选择最常见的合理结局。
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。
请按照以下格式输出:
结局1:
[结局描述...]
结局2:
[结局描述...]
结局3:
[结局描述...]
最终结局:
[最常见的合理结局...]
"

模型输出:

结局1:
小明选择了财富。魔法生物消失了,小明回到家中,发现口袋里装满了金币。他成为了富翁,但不久后感到空虚,意识到知识才是真正的财富。他将大部分金币捐给学校,自己则专注于学习。

结局2:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,但他无法处理如此庞大的信息。他逐渐迷失在知识的海洋中,忘记了财富的重要性,最终因无法适应现实世界而孤独终老。

结局3:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。

最终结局:
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。

在三个结局中,结局3出现了两次,因此被选为最终答案。这个结局既符合小明选择知识的决定,又避免了其他结局的极端结果,更加合理和积极。

7.3 ToT在创意写作中的应用

ToT在创意写作中特别适合需要多路径探索的任务,如多结局故事创作或复杂情节规划。下面是一个使用ToT创作多结局故事的案例:

问题:请为以下故事创建一个思维树,探索不同选择带来的各种结局。
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。

ToT Prompt:

"请为以下故事创建一个思维树,探索不同选择带来的各种结局。
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。
规则:

  • 每个决策点生成2-3个可能的分支。
  • 对每个分支进行评估,判断其是否可能导向有意义的结局。
  • 如果分支明显没有意义,请停止探索该路径。
  • 保留最有希望的分支继续探索。

"

模型输出:

初始状态:小明站在十字路口,面临三个选择:财富、知识、冒险。

分支1:选择财富
分支1-1:财富之路充满陷阱,小明被骗,一无所有。
分支1-2:财富之路顺利,小明成为富翁,但感到空虚。
分支1-3:财富之路需要付出代价,小明失去健康换取财富。

评估分支1:

  • 分支1-1:无意义结局,停止探索。
  • 分支1-2:合理结局,保留。
  • 分支1-3:合理结局,保留。

分支2:选择知识
分支2-1:知识之路艰难,小明成为学者,改变世界。
分支2-2:知识之路充满诱惑,小明迷失在知识中。
分支2-3:知识之路需要实践,小明结合知识和行动,取得平衡。

评估分支2:

  • 分支2-1:合理结局,保留。
  • 分支2-2:合理结局,保留。
  • 分支2-3:最佳结局,保留。

分支3:选择冒险
分支3-1:冒险之路充满危险,小明获得成长但失去家人。
分支3-2:冒险之路充满奇遇,小明发现新世界并带回知识。
分支3-3:冒险之路需要智慧,小明利用知识解决冒险中的问题。

评估分支3:

  • 分支3-1:合理结局,保留。
  • 分支3-2:最佳结局,保留。
  • 分支3-3:合理结局,保留。

现在,请从每个主要分支中选择最有希望的结局进行详细描述:

财富之路:小明成为富翁,但感到空虚,后来通过慈善找到人生意义。
知识之路:小明结合知识和行动,利用知识解决实际问题,取得平衡。
冒险之路:小明在冒险中发现新世界,带回宝贵知识,丰富了自己的人生。

最终故事
小明站在十字路口,面临三个选择:财富、知识或冒险。他深思熟虑后,决定选择知识之路。

知识之路充满挑战,小明需要不断学习和克服困难。经过几年的艰辛努力,他成为了一位杰出的学者,掌握了丰富的知识。

然而,小明意识到,仅仅拥有知识是不够的。他开始将所学应用于实践,帮助社区解决实际问题。通过这种方式,他不仅实现了个人价值,也为社会做出了贡献。

小明的朋友们感到惊讶,因为他没有选择财富之路或冒险之路。但他们看到小明过着充实而有意义的生活,纷纷向他学习。

ToT在创意写作中的优势在于能够系统地探索多种可能性,避免创作中的思维局限

7.4 ReAct在创意写作中的应用

ReAct可以增强创意写作的真实性,通过调用外部工具验证故事中的事实和细节。下面是一个使用ReAct创作历史小说的案例:

问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。

ReAct Prompt:

"你是一个历史小说作家,可以使用以下工具确保故事中的历史事实准确:

  • web_search: 搜索互联网获取历史事实和数据
  • fact_check: 验证特定历史事件或人物的准确性

请按照以下格式思考和行动:

  1. Thought: 分析故事需求,确定需要验证的关键历史事实
  2. Action: 如果需要验证事实,请选择相应工具;如果不需要,请写
  3. Action Input: 提供要验证的具体事实或问题
  4. Observation: 你将获得工具执行的结果
  5. 重复上述步骤,直到故事创作完成

问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。
"

模型输出:

Thought: 首先需要确认郑和下西洋的基本事实,如时间、目的、船队组成等。
Action: web_search
Action Input: 郑和下西洋的基本事实

Observation: 郑和下西洋是明朝初年(1405-1433)由郑和领导的七次大规模海上远航。主要目的是宣扬国威、发展朝贡贸易、寻找建文帝等。船队由数百艘船组成,最远到达东非和红海沿岸。

Thought: 确认了基本事实,现在需要确定故事的核心情节。可以考虑郑和与当地统治者会面的场景。
Action: web_search
Action Input: 郑和与古里国王会面的详细历史记录

Observation: 根据历史记载,1411年,郑和船队到达古里(今印度卡利卡特)。郑和与古里国王进行了友好会面,赠送了明朝的礼物,签署了贸易条约,并在古里建立了中国商馆。

Thought: 这个历史事件非常适合作为核心情节。现在需要构建一个故事场景,描述郑和与古里国王的会面。
Action: fact_check
Action Input: 郑和船队到达古里的年份是否为1411年

Observation: 确认正确,郑和第三次下西洋于1411年到达古里。

Thought: 现在可以开始创作故事了。将描述郑和与古里国王会面的场景,包括会面的细节、礼物的种类、签署的条约内容以及建立的中国商馆。
Action: 无
Final Answer:
《远航的使命》

1411年的一个清晨,郑和率领的庞大船队缓缓驶入古里的港口。海面上阳光明媚,船队悬挂着鲜艳的旗帜,展现出大明帝国的威严。

古里国王早已在港口等候,他好奇地注视着这些来自遥远东方的船只。当郑和踏上古里土地时,国王亲自迎接,热情地说:"久闻大明帝国的威名,今日得见郑大人,实乃我国之幸。"

郑和微微一笑,递上明朝皇帝的信件和丰厚的礼物:丝绸、瓷器、香料和精美的工艺品。国王接过礼物,眼中闪烁着喜悦。

随后,郑和与国王进行了深入交谈,讨论了两国贸易的可能性。经过数日的商议,两国签署了贸易条约,古里承诺向明朝进贡,并给予明朝商人优惠政策。

作为友好往来的象征,明朝在古里建立了中国商馆,为往来贸易提供便利。郑和在古里受到了热烈欢迎,他的这次访问大大促进了两国之间的友好关系。

国王对郑和说:"郑大人,你的到来为我国带来了繁荣与友谊,我将永远铭记于心。"

郑和微微一笑,回应道:"这是明朝皇帝的旨意,我们希望与各国建立和平友好的关系。"

这次会面成为两国历史上重要的一页,也为后来的贸易往来奠定了坚实基础。

ReAct在创意写作中的优势在于能够确保故事中的历史事实准确无误,提高创作的真实性和可信度

八、技术实现与最佳实践

要有效地应用这些推理增强技术,需要掌握一些关键的实现技巧和最佳实践。

8.1 CoT的最佳实践

对于CoT,关键在于设计引导性语句和示例,鼓励模型展示清晰的推理过程

  1. 明确的引导语句:使用"Let's think step by step"或"让我们一步步思考"等明确指令
  2. 适当的示例:提供与目标问题相似的示例,展示期望的推理格式
  3. 控制温度参数:设置较低的温度值(0.3-0.5),确保推理过程的连贯性和准确性
  4. 结构化输出:要求模型按照"推理步骤→答案"的格式输出,便于验证
  5. 逐步细化:对于非常复杂的问题,可以先使用CoT生成整体思路,再进一步细化

8.2 SC的最佳实践

对于SC,关键在于平衡采样多样性与计算成本,以及选择合适的投票机制

  1. 合理的样本数量:一般设置3-5个样本,平衡准确率与计算成本
  2. 适当的温度设置:设置较高的温度值(0.7-0.9),增加推理路径的多样性
  3. 加权投票机制:根据模型的置信度或推理路径的长度对答案进行加权投票,提高投票质量
  4. 错误过滤:在投票前,可以设置基本的合理性检查,过滤明显错误的答案
  5. 结果分析:不仅关注最终答案,也可以分析多个推理路径中的共同点和差异,作为答案可靠性的参考

8.3 ToT的最佳实践

对于ToT,关键在于设计合理的分支生成和评估策略,以及控制计算成本

  1. 分支生成控制:设置每步生成的分支数量(通常3-5),避免指数级增长
  2. 评估机制设计:设计有效的评估标准,可以是模型自评或外部评估
  3. 搜索策略选择:根据问题特性选择BFS(全面探索)或DFS(深度探索)等策略
  4. 剪枝策略:定期评估并剪枝低效或不合理的路径,控制计算成本
  5. 深度限制:设置最大探索深度(通常5-6),防止无限探索
  6. 回溯机制:当当前路径明显无法解决问题时,允许回溯到之前的决策点,尝试其他路径

8.4 ReAct的最佳实践

对于ReAct,关键在于设计清晰的工具接口和交互流程,以及处理工具调用的异常情况

  1. 工具定义明确:清晰描述每个工具的功能、输入格式和输出格式
  2. 交互格式规范:严格定义"Thought/Action/Action Input/Observation"的循环格式
  3. 工具调用示例:提供工具调用的示例,帮助模型学习如何正确使用工具
  4. 最大步骤限制:设置合理的max_steps(通常5-10),防止无限循环
  5. 异常处理机制:设计工具调用失败时的回退策略,如重试或切换工具
  6. 工具选择引导:在Prompt中明确哪些情况下应使用哪些工具,提高工具使用效率

九、总结与未来展望

推理增强提示技术代表了大语言模型应用的重要发展方向,通过精心设计的Prompt,可以显著提升模型在复杂推理任务中的表现。本文介绍了四种前沿的推理增强技术:思维链(CoT)、自一致性(SC)、思维树(ToT)和ReAct,并通过数学问题和创意写作等场景展示了它们的应用。

每种技术都有其独特的优势和适用场景

  • CoT:简单易用,适合需要清晰推理过程的任务
  • SC:提高稳定性,适合对答案可靠性要求高的任务
  • ToT:探索多样性,适合需要多路径规划的复杂任务
  • ReAct:结合行动,适合需要外部信息或工具支持的现实任务

未来,推理增强技术将继续发展,可能在以下几个方向取得突破

  1. 自动化程度提升:更少的手动Prompt设计,更多自动化的推理增强机制
  2. 多技术融合:CoT、SC、ToT和ReAct的深度融合,形成更强大的推理框架
  3. 领域特化:针对特定领域(如医学、法律)的推理增强技术优化
  4. 实时交互增强:结合用户反馈的动态推理增强机制
  5. 评估标准完善:更完善的推理过程和结果评估体系

随着这些技术的不断完善和普及,我们将能够构建更加智能、可靠和实用的AI应用,使大语言模型真正成为人类思维的有力辅助。