/images/avatar.png

你好,我是傲来说 👋

Codex 和 Hermes Agent:小孩才选边,大人看场景

Codex 和 Hermes Agent:小孩才选边,大人看场景

说实话,这两个东西根本不是一类。

但在 AI Agent 这个赛道上,所有人都在问同一个问题:“该选哪个?"——好像世界上只能有一个 Agent 活下来似的。

我的看法可能让你意外:两个都值得用,但用法完全不同。

先说结论,再讲道理:

  • Codex 桌面端 = 软件工程的编码指挥台。写代码、跑测试、看 diff、提交 Git,它是干活的。
  • Hermes Agent = 长期运行的自托管智能体底座。记忆、技能、自学习、跨平台消息交互,它是陪你长大的。

一句话说透:Codex 是你雇佣的工程师,Hermes 是你培养的助手。 工程师按项目结算,助手跟你一起成长。


Codex:围绕代码项目的工程闭环

Codex App 的定位很清晰——一个用于并行处理 Codex 线程的桌面体验,内置 worktree、automations 和 Git 功能。macOS 和 Windows 都支持。

它的强项从来不是"陪你聊天”,而是围绕代码项目形成一个近乎封闭的工作流:

选一个项目文件夹,让 Agent 读取项目、运行命令、修改代码。通过 Git checkpoint、diff、worktree 管理风险。多个线程并行处理不同任务。最后审查、提交、推送或发 PR。

从头到尾,你看得到它改了什么。

官方 Quickstart 说得很直白:Codex IDE 扩展默认以 Agent mode 启动,可以读取文件、运行命令并在项目目录中写入修改。Codex Cloud 更进一步——连接 GitHub 仓库、后台运行任务、完成后审查变更和创建 PR。

说白了,Codex 最好的使用场景就四个:

明确的工程任务。 修 bug、补测试、重构、解释项目结构、生成脚手架。这些活 Codex 干起来最利索。

多线程并行开发。 一个线程做登录模块,一个线程修 UI,一个线程写测试。Codex App 的 worktree 可以让多个任务互不干扰——官方文档原话是,worktree 可以让 Codex 在同一项目中跑多个独立任务而不互相冲突。

Codex 桌面端的翻盘:不是它变强了,是它重新定义了战场

Codex 桌面端的翻盘:不是它变强了,是它重新定义了战场

2025 年 4 月,OpenAI 发布 Codex CLI。社区的排名毫不留情——“Cursor > Claude Code > Codex CLI”。

十一个月后,2026 年 3 月,Codex 周活用户突破 200 万,增长 5 倍(Reuters, 2026-03-10)。开发者社区最热的讨论不再是"选哪个",而是"怎么搭配着用"。

一个产品从"差远了"到"重新定义赛道",中间到底发生了什么?答案比你想的要简单,也比你以为的要深刻。


从"追赶者"到"重新定义者"

低谷:5% 的使用量

Codex CLI 发布的时机其实不差——2025 年 4 月 16 日,与 o3、o4-mini 模型同期亮相(TechCrunch, 2025-04-16)。开源、免费、运行在终端里。但发布后的反馈泼了一盆冷水:Zack Proser 的评测记录了 40%-60% 的一次成功率(Zack Proser, 2025-05-18);Reddit 上的排名直接把它排在第三位(r/ChatGPTCoding, 2025-04);2025 年 8 月,Check Point Research 发现了一个关键安全漏洞 CVE-2025-61260,恶意 .env 文件可以在开发者机器上静默执行任意命令(Check Point Research, 2025-08-07)。

到 2025 年 9 月,Codex 的使用量大约只有 Claude Code 的 5%(WIRED, 2026-03-11)。Medium 上一篇评测的标题直白得刺眼:“So, OpenAI’s Codex CLI is Claude Code, but worse?”

我用纯 Python 手搓了一个 RAG 知识库:不用 LangChain,也能让文档开口说话

我用纯 Python 手搓了一个 RAG 知识库:不用 LangChain,也能让文档开口说话

全文约 3000 字,阅读需要 6 分钟


起因

最近工作里有个很具体的痛点:文档太多,而且太杂。

合同扫描件、行业报告、内部资料、会议截图、Word、Markdown、PDF,格式五花八门。真正要用的时候,最麻烦的不是“有没有这份资料”,而是“我到底在哪份资料里见过这句话”。

我想要的东西其实很简单:

把这些文档丢进一个系统里,以后直接用自然语言提问,它能从资料里找依据、给答案、贴出处。

市面上当然有很多方案。但试了一圈,总觉得不完全合适:

  • 有的太重,依赖链很长,调一个小功能要理解一堆抽象;
  • 有的太贵,OCR、Embedding、LLM 全走 API,文档量一大成本就上来了;
  • 有的隐私边界不够清楚,公司资料直接传第三方服务器,这事很难放心。

于是我干脆自己写了一个。

项目名叫 RagLite:轻量、透明、尽量把重计算放在自己手里。


它能干什么?

一句话:把你的文档变成一个可对话的知识库。

比如扔进去 35 张截图,或者一本 459 页的扫描版 PDF,等它完成 OCR、分块、向量化和入库之后,就可以直接问:

“将军崖岩画是什么?”

它会先从知识库里检索相关片段,再调用大模型生成回答,并把来源一起贴出来。这样你既能快速得到结论,也能回到原文核对。

目前支持这些文件:

  • Markdown / 纯文本
  • Word(.docx
  • PDF,包括纯图片扫描件
  • 图片截图(PNG / JPG)

我最看重的是两点:

第一,原始文件不必交给第三方平台。OCR 和向量化默认都可以在本机完成。

第二,代码路径足够短。出了问题,你能直接打开对应文件看懂它在做什么。


为什么不用 LangChain?

不是 LangChain 不好。

它解决的是“快速搭建复杂 LLM 应用”的问题,生态、集成、抽象都很完整。但我的需求没有那么复杂:文档解析、OCR、分块、Embedding、检索、生成,链路清楚,能跑稳就行。

很多时候,框架的抽象层会在前期让你觉得省事,到了调试阶段又把问题藏起来。链条、Agent、Tool、Memory,每个概念都包了一层。检索结果不对时,你可能要一路穿过好几层封装,才能找到真正影响结果的那个参数。

RagLite 的思路更朴素:

每个模块自包含,能少一层就少一层。

项目结构大概是这样:

config.py          # 配置,一个 dataclass
ingest/
  ocr.py           # OCR,调用本地 Ollama
  chunker.py       # 文档分块
  embed.py         # 向量化,支持多种模式
  pipeline.py      # 入库流水线
serve/
  store.py         # ChromaDB 存储
  retriever.py     # 混合检索
  api.py           # FastAPI 接口
  mcp_server.py    # MCP 协议

没有太多魔法。哪一步出问题,就看哪一个文件。

RAG 选型不踩坑:15 个项目的真实数据告诉你谁在裸泳

RAG 选型不踩坑:15 个项目的真实数据告诉你谁在裸泳

数据采集日期:2026 年 5 月 26 日。所有量化数据来自 GitHub REST API 实时采集,社区评价来自 GitHub Issues、Reddit、HackerNews、知乎等 8+ 独立信源的交叉验证。


一、为什么 RAG 赛道值得重新审视

2023 年,RAG(检索增强生成)还是 LLM 应用的"标配架构",几乎每个 AI 项目的技术选型讨论都从"用 LangChain 还是 LlamaIndex"开始。到了 2026 年,局面已经截然不同——框架之间开始分化,“去框架化"的声音越来越响,LlamaIndex 创始人 Jerry Liu 公开承认"框架时代正在结束”。

这不是说 RAG 本身不重要了。恰恰相反,几乎所有企业级 AI 落地场景都绕不开它——客服知识库、合同审查、技术文档检索、合规问答,每个场景背后都需要"让 LLM 基于你的私有数据回答问题"的能力。真正变化的是选择变得困难了:GitHub 上叫得出名字的 RAG 相关项目就有几十个,每个都宣称自己是"最佳实践"。选错一个框架的代价不只是技术债——团队时间、项目窗口期、甚至是领导层对 AI 战略的信任,都是沉没成本。

我们做了一件事:用数据说话。采集了 15 个主流 RAG 相关项目的实时 GitHub 数据,加上对 LangChain、LlamaIndex、Dify、RAGFlow、Haystack、LightRAG 六个核心项目在 Reddit、HN、知乎、GitHub Issues 等多源的社区口碑交叉验证,形成这份面向技术决策者的全景扫描报告。


二、15 个项目,六个赛道:一张全景图

先看全貌。这 15 个项目并非都在做同一件事,它们可以归入六个差异明显的赛道:

赛道项目头部 Stars核心定位
RAG 框架LangChain、LlamaIndex、Haystack、LangChain4JLangChain 122.7K提供构建 RAG 管道的抽象层与集成生态
端到端平台Dify、RAGFlowDify 129.4K从数据摄入到应用交付的一站式方案
Agent 框架AutoGen、CrewAI、Semantic KernelAutoGen 55.6K多 Agent 协作与工作流编排
向量数据库Qdrant、Milvus、Chroma、WeaviateQdrant 29.9K向量检索的基础设施层
RAG 系统R2R7.8K专注 RAG 的完整解决方案
工具库Instructor6.2K结构化输出的辅助工具

一个反直觉的发现:Stars 最高的不是 RAG 框架,而是端到端平台 Dify(129.4K Stars),比排名第二的 LangChain(122.7K)还多出近 7000 颗星。这背后反映的趋势是越来越多的团队不想自己拼积木了——从数据解析、向量化、检索、到 Prompt 编排和前端交付,他们想要一个完整的、可视化的解决方案。

国内新闻网站/APP排名分析报告——以手机新闻APP为视角

国内新闻网站/APP排名分析报告——以手机新闻APP为视角

编制时间: 2026年5月
数据截止: 2025年12月(部分数据更新至2026年Q1)


摘要

截至2024年底,中国网络新闻用户达8.11亿(CNNIC第55次报告),覆盖超七成网民,新闻资讯APP端独立覆盖用户4.79亿(月狐iApp数据)。然而,一个根本性变化正在发生:87%的用户通过短视频获取新闻,仅57.1%通过传统资讯APP获取(腾讯研究院T-ask调研)。中国新闻消费的主渠道已从"读新闻"转向"刷新闻"。

本报告以手机新闻APP为核心视角,综合APP市场格局、Web端流量排名与竞争深度分析三维度数据,呈现2024-2025年中国新闻资讯行业的竞争格局与演进趋势。核心发现如下:

  • 今日头条以3.91亿MAU稳居新闻资讯APP首位(QuestMobile 2025Q2),但短视频平台(尤其是抖音)正以9.78亿去重月活的规模,成为新闻分发的真正霸主。
  • Web端全面边缘化:排名第一的搜狐网月访问量仅17.11M(Semrush),今日头条Web端4.65M不足其APP端用户量的1.2%。
  • AI已深入渗透新闻生产与分发:92%头部APP采用AI推荐算法(QuestMobile),腾讯新闻AIGC日均产能12万条,内容成本下降41%(腾讯财报)。但从业者普遍认为AI当前角色以"辅助"为主(50.5%认同),而非"颠覆"(腾讯研究院)。
  • 市场呈现"头部集中+垂直分化"的双轨格局:头部平台占据超65%用户活跃时长,但财经等垂直领域仍保持70%以上增长。

一、行业概述与调研背景

1.1 宏观市场概况

中国网民总量已达11.08-11.25亿(CNNIC第55/57次报告),其中移动网民占比99.6%(CNNIC第57次报告)。网络新闻用户8.11亿(CNNIC第55次报告,2024年12月),占网民总量的72%以上,是渗透率最高的互联网应用之一。

行业市场规模方面,人人文库行业报告估算2025年新闻类APP市场规模约420亿元,2030年有望突破780亿元。但需指出:该数据为行业报告估算值,原始出处不明,置信度为低。本报告引用此数据时均标注来源与置信度,供读者审慎参考。

在线新闻资讯APP覆盖用户4.79亿(月狐iApp数据),T1、T3两份研究报告对此数据交叉验证一致。这表明APP端用户约为网络新闻总用户规模的59%,余下用户通过浏览器、社交平台等其他渠道获取新闻。

1.2 调研背景与方法

本报告综合三份独立研究报告的数据进行交叉验证与分析:

  • T1《APP市场格局报告》:聚焦APP端MAU/DAU排名、用户画像与市场格局
  • T2《网站排名与流量报告》:聚焦Web端流量排名(Semrush、Chinaz等工具采集)
  • T3《竞争深度分析与行业趋势报告》:聚焦商业模式、技术路线与竞争策略

三份报告共引用22项数据来源,涵盖官方统计(CNNIC)、行业数据平台(QuestMobile、月狐iApp)、上市公司财报(腾讯、新华网、人民网)、第三方流量监测工具(Semrush、Chinaz)等。本报告对数据冲突进行了仲裁(详见各章节注释),对置信度进行了分级标注。

1.3 核心命题

本报告围绕一个核心命题展开:中国新闻消费的渠道范式是否正在发生根本性转变? 如果是,这种转变对平台格局、商业模式和行业未来意味着什么?


二、手机新闻APP市场格局

2.1 APP端竞争梯队

第一梯队:超级平台(MAU > 1亿)

平台APP MAU核心数据来源
今日头条3.91亿(2025Q2)[高]日均使用时长58.3分钟QuestMobile,21经济网引用
腾讯新闻渗透率同比+42%[中]依托微信生态分发月狐iApp数据
新浪新闻1.29亿(APP端)+3.5亿(生态流量)[高]与微博重合用户7312万QuestMobile,T1/T2/T3一致
抖音(含新闻入口)9.78亿(去重月活)[高]87%用户通过短视频获取新闻QuestMobile;腾讯研究院T-ask

说明: 抖音9.78亿为全平台去重月活,非新闻功能独立用户数。抖音本质是短视频平台,新闻只是其功能之一,但87%的用户通过短视频获取新闻的事实使其成为新闻分发的实质霸主。

今日头条以3.91亿MAU稳居独立新闻资讯APP首位。需注意:2024年Q4月狐iApp数据记录其MAU约2.6亿,半年后增至3.91亿(QuestMobile 2025Q2),增幅达50%。两个数据点可能存在统计口径差异(月狐与QuestMobile方法论不同),不宜简单线性推算增速,但方向性结论清晰——今日头条仍在增长。

腾讯新闻虽未公开精确MAU,但渗透率同比+42%(月狐iApp数据),叠加微信、QQ双端入口协同,实际触达规模可能高于独立APP统计。腾讯2025年Q4财报显示营销服务收入1449.73亿元,其中腾讯新闻贡献份额未单独披露。

第二梯队:垂直/特色平台

平台核心数据来源
央视新闻下载量2.19亿,进入行业Top 10 [高]QuestMobile
澎湃新闻累计下载2.817亿,日均阅读量4.5亿 [高]澎湃新闻2024年度社会责任报告
搜狐新闻渗透率持续增长,Web端17.11M/月 [中]月狐iApp;Semrush
网易新闻历史MAU约9800万,Chinaz排名第37 [中]T2报告

央视新闻是传统媒体转型最为成功的案例之一,其进入行业Top 10标志着官方媒体在移动互联网时代找到了新的增长路径。澎湃新闻以时政原创为定位,日阅读量4.5亿,用户中高收入群体占比突出(澎湃新闻2024年度社会责任报告)。

Cherry Studio 口碑与测评综合报告

Cherry Studio 口碑与测评综合报告

报告日期:2026-05-24
数据来源:GitHub Issues、知乎、CSDN、阿里云开发者社区、LINUX DO、B站测评、各技术博客


一、产品概况

Cherry Studio 是一款开源、免费的跨平台 AI 对话客户端,由 Cherry HQ 团队开发。支持 Windows、macOS、Linux,核心定位是"多模型聚合 AI 生产力工具"。主要特性包括:

  • 多模型支持:兼容 OpenAI、Claude、Gemini、DeepSeek、Mistral 等主流 LLM 服务商,内置 300+ 预配置 AI 助手
  • 本地模型接入:深度支持 Ollama、LM Studio 等本地大模型
  • 知识库与 RAG:支持多种文件格式的本地知识库构建和检索增强生成
  • 思考过程可视化:展示 AI 推理步骤
  • AI 绘画、翻译等多功能集成
  • 高度自定义:支持本地按需开发

GitHub 仓库:CherryHQ/cherry-studio,约 1.8k Stars,Issues 活跃(10+ open issues)。


二、正面评价汇总

2.1 UI/UX 设计获广泛认可

多个测评文章一致称赞 Cherry Studio 的界面设计:

“Cherry Studio 在设计上明显更加精致,有着类似高端应用的质感,界面更为美观。” —— Apiyi 对比测评

“优雅精致,注重视觉美感。柔和舒适,护眼配色。空间感强,层次分明。” —— 阿里云开发者社区横评

2.2 知识库与 RAG 功能突出

“Cherry Studio 在本地知识库构建和 RAG 功能上表现突出,支持多种文件格式,对需要处理大量本地文档的用户非常实用。” —— 2025 年跨平台桌面 AI 客户端评测报告