从记不住手机号，到看懂AI的“脑子”：聊聊短期记忆与长期记忆的奥秘

你有没有过这样的经历：刚查到一个验证码，转头输入时就忘了前几位；但自己的手机号、身份证号，却能脱口而出。这背后，其实藏着大脑一套精妙的“记忆分工”机制。今天，我们就从这些日常小事出发，聊聊短期记忆、长期记忆，以及它们和AI大模型的“上下文”之间，那些有趣的关联。

大脑的“记忆团队”：谁管临时存储，谁管永久归档？

我们的大脑，从来不是靠一个“记忆抽屉”来存东西的，而是由多个脑区组成的“协作团队”，各司其职又相互配合。

首先是负责“临时记事”的工作记忆，也就是我们常说的短期记忆。它的“总指挥”是前额叶皮层，就像大脑的“智能工作台”——你思考问题、做决策时，暂时存放的信息都在这儿。比如记一串陌生手机号，前额叶皮层会协调“语音环路”让你在心里默念，还会调动“视空模板”帮你想象数字的形状。最近的研究还发现，屏状核会像“信息整合中心”一样，帮前额叶皮层高效整合不同感官的信息，而海马体也会参与进来，帮短期信息和长期记忆搭上线。

而长期记忆的“管理员”，则是海马体。它不直接存记忆，而是像图书馆的图书管理员：把新的、重要的信息编码整理后，“归档”到大脑皮层的不同区域永久储存。比如事实知识、个人经历，主要由海马体和大脑皮层负责；而骑自行车、弹钢琴这类技能记忆，则更多依赖小脑和基底神经节。

至于我们常说的“学习总结”，更是全脑协同的结果：前额叶皮层负责逻辑分析、归纳推理，海马体负责把新知识和已有知识网络连接起来，最终把零散信息变成能长期使用的“干货”。

记手机号：一场大脑的“信息接力赛”

当你尝试记住一串陌生手机号时，大脑正在上演一场高效的“接力赛”：

第一步，信息先闯进“感觉记忆”——就像一道闪光，只保留不到一秒；第二步，如果你集中注意力，数字就会进入“工作记忆”，前额叶皮层开始指挥，你可能会在心里默念，也可能在脑子里“写”下数字；第三步，如果你反复复述，海马体就会介入，判断这串信息是否重要。如果重要，就帮它从“临时工作台”转移到大脑皮层，变成长期记忆。

那为什么陌生手机号很难一次性念出来，自己的却能脱口而出？答案很简单：陌生号码只在工作记忆里“暂住”，而工作记忆容量有限（通常是7±2个组块）、保持时间短（几秒到几十秒），一分心就没了；而自己的手机号，经过成千上万次重复，早被海马体“归档”到长期记忆里，就像读熟的书，能随时毫不费力地提取出来，这叫“自动化提取”。

所以，记不住陌生号码不是大脑“不好用”，而是它在高效执行“信息筛选”的职责——把认知资源留给更重要的事。

验证码为什么是6位数？藏着“7±2法则”的智慧

你有没有想过，验证码为什么大多是6位数？这其实和人类工作记忆的容量限制直接相关。

早在1956年，心理学家乔治·米勒就提出“7±2法则”：普通人的短时记忆容量，大约是7个信息单位，范围在5到9之间。6位数正好落在这个“舒适区”内，既没超出大多数人的记忆负荷，又足够复杂。

更妙的是，6位数还能被轻松“组块化”——分成3-3（如123-456）或2-2-2（如12-34-56）的模式，特别符合大脑的记忆习惯。要是换成5位数，很难平均分割，反而容易记错；要是换成8位、10位，就超出了工作记忆容量，得反复查看才能记全，体验会很差。

而且，6位数的组合有100万种，比4位数的1万种安全得多，结合验证码的短时效性，既能防破解，又不牺牲用户体验——这简直是“安全性”和“便利性”的完美平衡。

转头就忘？是大脑在帮你“减负”

短暂记住手机号后很快遗忘，其实是大脑的“自动清理”机制在起作用。

一方面，工作记忆本身就有“容量+时间”的双重限制：信息只能停留15到30秒，不复述就会消失。另一方面，“事件边界”会加速遗忘——当你记住号码后转身、开门，大脑会把这当成“新事件的开始”，自动清理上一个事件的临时信息，为新的任务腾出空间。

更重要的是，这种“转头就忘”是大脑高效的“认知策略”：我们每天接收海量信息，如果所有临时信息都保留下来，大脑很快会被“垃圾信息”塞满。快速遗忘能帮我们过滤掉没长期价值的内容，把注意力、记忆力这些宝贵资源，集中用在更重要的事上。

所以，忘记刚看的手机号，恰恰说明你的大脑在高效工作，帮你保持思维清晰。

AI的“上下文”，就是它的“短期记忆”

聊完人类记忆，我们再来看看AI——其实AI大模型的“上下文”，就和人类的短期记忆一模一样。

这个“短期记忆”有个物理上限，叫“上下文窗口”，可以把它想象成一个固定大小的“记事本”：里面装着当前对话历史、你的提问、系统预设指令；容量有限，以“Token”为单位衡量；而且是临时的，对话结束或内容超出容量，最早的信息就会被“挤出”并永久遗忘。

理解这一点，就能看懂AI的局限性：比如对话太长，它会“失忆”，忘了最开始聊的内容；默认情况下，它没有真正的“长期记忆”，每次新聊天都是“全新开始”；还会“迷失在中间”，更容易记住上下文开头和结尾的内容，忽略中间信息。

这和人类的工作记忆太像了：容量有限、内容临时、不重复就遗忘。

AI智能体的关键：从“长期记忆”提取信息到“上下文”

那AI怎么像人类一样，把“长期记忆”里的信息提取到“短期记忆”里？这正是构建AI智能体的关键，核心技术叫“检索增强生成”。

比如你问AI：“我们上周讨论的那个项目预算是多少？”它会先把问题“向量化”，用语义搜索在长期记忆库（通常是向量数据库）里，找和问题最相关的信息片段；然后把检索到的预算相关内容，作为新上下文“塞进”短期记忆；最后结合问题和历史记忆，生成精准回答。

更前沿的智能体设计，还会让模型“自主管理记忆”：把检索、添加、总结、遗忘当成工具，让AI自己判断什么时候该找历史记忆、什么时候该压缩对话腾空间、什么时候该存重要信息。这就像给AI装上了“主动思考”的能力，是通往更智能AI的关键一步。

refs:

• 神奇数字7±2: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
• 工作记忆模型: https://en.wikipedia.org/wiki/Baddeley%27s_model_of_working_memory
• Lost in the Middle: 语言模型如何用长上下文: https://zhuanlan.zhihu.com/p/645690934

如何把长期记忆（Long-term Memory）里的东西，精准、少量、不污染地提取到上下文（短期记忆）中？

这件事是 整个 AI 系统是否可靠的决定性因素。

换句话说：

Agent能不能聪明，除了取决于模型参数，更取决于“有没有把对的东西放进上下文”。

1. 上下文 = 工作记忆（短期）

• 容量有限
• 容易被噪音干扰
• 内容过多会导致幻觉
• 每轮对话都会刷新或丢失

就像人类的“意识层”。

2. 长期记忆 = 外部知识库（Long-term Memory）

可能包含：

• 文档
• 代码
• embeddings
• Skills（能力型记忆）
• 用户偏好
• 历史任务
• 系统状态
• 动态数据库数据

容量巨大，可无限扩展，就像人的“潜意识 + 已学习的知识与经验”。

3. 真正的难点：

如何从无限大的长期记忆中，取出最 relevant 的小片段加载到有限上下文中？

这是整个 AI 体系最关键的问题，因为：

• 太少 → 信息不足，模型做不出好判断
• 太多 → 上下文爆掉，出现幻觉
• 提取错了 → 直接跑偏
• 噪音太多 → 严重干扰 reasoning

“提取什么”比“模型怎么推理”更重要。

AI记忆系统的设计是一个重大课题

研究界和工业界对这个问题有几个不同方向的研究，你可以看到它们非常核心：

① Retrieval（检索）

也就是传统的 RAG。

问题在于：

• 文档颗粒度怎么切？
• 如何避免召回噪音？
• 多轮任务上下文如何保持一致性？
• 如何做 hierarchical retrieval？

这已经是一个大课题。

② Routing（路由）

即：

给定长期记忆，我们应该让哪个 Agent 或 Skill 上场？

这是 Multi-Agent System 的另一个根本难题。

Routing 不好 → Agent 用不对的信息、做不对的事。

③ Memory Ranking（记忆排序）

系统要决定：

• 哪些信息最重要？
• 哪些信息应该遗忘？
• 哪些技能应该更优先？
• 哪些历史内容应该合并成总结？

这其实是“AI 大脑的注意力系统”。

④ Context Compression（上下文压缩）

包括：

• 压缩句子
• 压缩任务状态
• 压缩之前 agent 的决策链

比如：

• ReAct traces
• 思维链（CoT）
• Agent state

这些不能无限增长，需要压缩，不然会爆。

⑤ Memory Rewriting（记忆重写）

类似人类会“总结成脑内模型”：

• 动态总结
• 抽象
• 合并
• 提炼为新技能（Skill）

这其实是 AI 的“学习过程”。

未来最强的 AI 可能是：

通过 Memory Rewriting 持续把经验写成 Skills 的系统

⑥ Grounding（事实校验）

避免幻觉最关键的一步：

• 提取到上下文的内容是否真实？
• 是否对应正确来源？
• 是否经过验证？

美国大厂内部都在研究“Retrieval → Grounding → Reasoning”三段式 pipeline。

总结

未来所有强 AI 系统的核心都不是模型本身，而是：

如何管理记忆 → 如何提取记忆 → 如何在短期记忆中构建思考链条。

这就是 AI 的“前额叶皮层 + 海马体”类比。

• 工作记忆（上下文）= 前额叶皮层 = 推理区
• 长期记忆（RAG/Skills/知识库）= 海马体 + 大脑皮层
• 检索模块 = 注意力系统
• 压缩与抽象模块 = 人类的梦境与学习过程

AI 的智能 = 模型能力 × 上下文质量 × 记忆检索质量

你有没有这样的体验：问 ChatGPT 一个问题，它回答得头头是道、引经据典，你差点就信了——直到你发现它引用的那篇论文根本不存在。

这就是所谓的”幻觉”（Hallucination）。

围绕幻觉，业界有各种各样的解释：训练数据有噪音、模型参数不够大、RLHF 没对齐好……这些说法都对，但都没有触及最本质的那一层。

今天我想聊聊，大模型幻觉到底是怎么回事，以及一个正在被越来越多人重视的解决思路——上下文工程（Context Engineering）。

先搞清楚一件事：大模型在干什么

要理解幻觉，得先理解大模型的工作原理。

大模型本质上是一个条件概率机器。给定前文，它预测下一个 token 出现的概率分布，然后从中采样。整个生成过程，就是一连串的”下一个词最可能是什么”的概率接龙。

注意，是最可能，不是最正确。

这两者的区别，恰恰就是幻觉的根源。

林黛玉倒拔垂杨柳

我们来做一个思想实验。

假如你问模型：”请描述林黛玉倒拔垂杨柳的情节。”

这句话里有两个强信号：林黛玉和倒拔垂杨柳。前者指向《红楼梦》里那个弱柳扶风、多愁善感的少女，后者指向《水浒传》里鲁智深酒后逞威的经典桥段。这两个信号指向截然不同的语义空间，把它们拼在一起，就构成了一个信息熵极高的上下文。

什么是信息熵高？简单说就是”不确定性大”。模型拿到这个 prompt 后，陷入了纠结：到底该往《红楼梦》的方向生成，还是往《水浒传》的方向生成？两边的概率势均力敌，上下文没有提供足够的约束来把不确定性降下来。

但模型不能不回答，它必须输出点什么——因为自回归语言模型的本质就是”给定前文，生成续文”，它没有”我不知道”这个内建选项。

于是它开始做最擅长的事情：统计补全。

它会综合两边的语义，编出一段看上去合理但事实上荒谬的文字。比如它可能写出：”林黛玉走到大观园的垂杨柳前，气运丹田，双手抱住树干，一声娇叱之下连根拔起……”——语言通顺，文笔甚至还不错，但内容纯属一本正经地胡说八道。

这就是幻觉的本质：在信息熵高或信噪比低的上下文中，模型为了完成概率语言建模而进行的统计补全。

它不是”故意骗你”，也不是”太笨了不知道”。它只是一台概率机器，在信号不明确的时候，依然忠实地执行自己的使命——生成统计上最合理的下文。

再看几个日常例子

理解了这个本质，你会发现生活中大量的幻觉案例都可以用这个框架解释。

例一：捏造论文引用

你让模型”列出近五年关于xxx的重要论文”。模型的训练数据里确实见过大量论文标题、作者名和期刊名，但这些信息是碎片化的——它知道”Attention Is All You Need”是 Vaswani 等人写的，也知道 Nature 和 Science 发过很多文章，但它并没有一个结构化的论文数据库。当你要求它生成一个它不确定的引用时，它会把”看起来像论文标题的词组”+”看起来像作者名的人名”+”看起来像期刊名的名词”拼在一起。每一个局部都符合统计规律，但组合起来就是一篇不存在的论文。

这就是典型的信噪比低的场景：模型脑子里有大量关于论文的”噪声”，但缺少指向具体某篇论文的”信号”。

例二：信誓旦旦地算错数

问模型”17 × 24 等于多少”，它可能回答 able 408（正确答案），也可能回答 388 或者 418。因为乘法运算在语言模型的概率空间里本身就是一个高熵事件——从纯语言统计的角度看，”17 × 24 = 408”和”17 × 24 = 418”在 token 概率上并没有天壤之别。模型从来就不是在”算”，它是在”猜一个看起来像答案的数字”。只是“17 × 24 = 408”在他看到过的文本里出现的概率最高。如果有数据投毒，训练时喂给他大量的“17 × 24 = 418”，那它大概率输出418这个错误答案。

例三：编造 API 参数

你让模型写一段调用某个冷门 SDK 的代码。主流的 SDK 它见过足够多的示例，能写对；但遇到冷门的，训练数据里可能只出现过寥寥几次，信号极弱。于是它根据”类似 SDK 通常长这样”的统计规律，编造出一组似是而非的 API 签名。函数名像那么回事，参数顺序看着合理，但跑起来就是报错。

一个统一的解释框架

把上面的例子汇总，我们可以得到一个简洁的框架：

幻觉 = f(上下文的信息熵, 上下文的信噪比)

信息熵越高（不确定性越大），幻觉概率越高。信噪比越低（有效信息越少、干扰信息越多），幻觉概率越高。

反过来说，如果你能把上下文的信息熵降下来、把信噪比提上去，幻觉就会大幅减少。

这就引出了我们今天的主角：上下文工程。

什么是上下文工程

Prompt Engineering（提示词工程）你一定听过。上下文工程可以理解为它的进化版本——不只是关心怎么写 prompt，而是关心模型在生成时，整个上下文窗口里都装了什么。

一个大模型在推理时，它看到的全部信息就是上下文窗口里的内容。这包括：

• 系统提示词（System Prompt）
• 用户输入（User Message）
• 检索增强的文档（RAG 结果）
• 工具调用的返回值
• 历史对话记录
• 中间推理步骤

上下文工程的核心命题就是：如何精心组织这些信息，让模型在生成每一个 token 时，都处于一个低信息熵、高信噪比的上下文环境中。

说白了，就是帮模型”开卷考试”，而且是把正确答案翻到对应页码、用荧光笔划好重点地那种开卷。

上下文工程怎么治幻觉

1. RAG：把”闭卷”变成”开卷”

最直接的一招。模型不知道某个事实？没关系，帮它查好资料、塞进上下文。

比如前面”捏造论文”的例子。如果你先通过学术搜索引擎检索出真实的论文列表，把标题、作者、摘要、发表年份等结构化信息放进上下文，模型就不再需要”猜”了——它只需要把这些已有的事实用通顺的语言组织起来。信噪比直接拉满。

但 RAG 不是万能药。塞太多不相关的文档进去，反而会降低信噪比，引入新的混乱。所以 RAG 的关键不在于”检索”，而在于精准检索和结果筛选。

2. 结构化 Prompt：给不确定性上约束

信息熵高的本质是”模型不知道该往哪个方向生成”。那我们就用 prompt 把方向限死。

回到林黛玉的例子。如果 prompt 改成：”以下是一道测试题，请判断’林黛玉倒拔垂杨柳’这个说法是否正确，并说明理由。”——这就给模型施加了一个强约束：输出空间从”写一段情节描写”缩小到了”判断正误”。模型很容易就能给出正确答案，因为判断真假比无中生有容易得多——信息熵一下子就降下来了。

再比如，要求模型以 JSON 格式输出、给定输出字段的枚举值、限定回答长度、要求分步骤推理——这些都是在用结构化约束来降低输出空间的不确定性。

3. 工具调用：让模型调用外部能力而非硬猜

算数会出错？让模型调计算器。不知道今天星期几？让模型调日期 API。不确定某个函数的签名？让模型查文档。

工具调用的本质是：把模型不擅长的高熵任务，外包给确定性的外部系统，然后把确定性的结果注入回上下文。模型拿到精确结果后，只需要做它最擅长的事——用自然语言把结果讲清楚。整个过程中，模型始终处于低熵、高信噪比的舒适区。

4. 上下文精简：少即是多

很多人以为上下文越长越好，128K 的窗口恨不得填满。其实正好相反。

上下文窗口就像模型的”工作记忆”。你往里面塞了一大堆跟当前问题无关的对话历史、冗余的系统提示、检索出来但不相关的文档片段，模型就像一个在嘈杂菜市场里试图听清你说话的人——它能听到的有效信息被噪声淹没了。

好的上下文工程会做”减法”：对历史对话做摘要压缩，对检索结果做相关性过滤，对系统提示做精简聚焦。让每一个 token 都是有效信号。

5. 思维链与多步推理：化整为零

一道复杂的推理题，如果让模型一步给出答案，信息熵很高——因为可能的答案空间巨大。但如果引导模型分步骤思考，每一步的输出空间都很小、确定性都很高，最终组合起来就能得到正确答案。

这就像你问一个人”从北京到纽约的最优路线是什么”，如果要求他一口气答出来，很容易出错。但如果拆成”先选交通方式→再选出发机场→再选航线→再选中转站”，每一步的决策都简单明确得多。

思维链的本质，就是用中间步骤不断往上下文注入确定性，把一个大的高熵问题分解成一连串小的低熵问题。

小结

让我们回到最初的那个判断：

幻觉不是 bug，而是概率语言模型在信息不充分时的必然行为。

既然根源在于上下文的信息质量，那解药自然也在上下文里。上下文工程做的事情，说到底就一句话：

在模型生成每一个 token 的那个瞬间，确保它眼前摆着的是低熵、高信噪比、指向明确的上下文。

Prompt Engineering 教你”怎么问问题”，上下文工程教你”怎么准备考场”。

一个准备充分的考场里，学生很难答错题——哪怕这个学生只是一台概率机器。

这篇文章我想整理一下深度神经网络的进化之旅。从CNN到Transformer，再到GPT，这些模型架构设计过程中是怎么进化的，每个模型解决了什么问题。

深度学习的发展并非一蹴而就，而是在不断解决实际问题的过程中逐步演进的。每一次架构创新，都是针对前一代模型的局限性提出的解决方案。这个过程就像计算机产业的发展一样，遵循着”问题-突破-新问题-新突破”的螺旋上升规律。

卷积神经网络(CNN)：视觉的突破

1998年，Yann LeCun（杨立昆）在贝尔实验室提出了LeNet-5，这是第一个真正意义上的卷积神经网络。它被用于手写数字识别，准确率达到了惊人的99%以上。LeCun的工作奠定了CNN的基础架构，但在当时并未引起广泛关注——计算能力不足，数据集太小，传统机器学习方法在小规模问题上表现也不错。

但CNN真正引起轰动是在2012年。多伦多大学的Geoffrey Hinton（杰弗里·辛顿）教授带领学生Alex Krizhevsky和Ilya Sutskever，用AlexNet在ImageNet图像识别竞赛中以压倒性优势夺冠，错误率比第二名低了10个百分点。这个突破不是偶然的：Hinton在1980年代就开始研究神经网络，提出了反向传播算法的改进版本，几十年如一日地坚持这个方向。AlexNet的成功证明了深度学习的潜力，也标志着AI的”寒冬”彻底结束。

2024年，Hinton因为在人工神经网络领域的开创性工作获得了诺贝尔物理学奖。这个看似跨界的奖项其实有其深刻逻辑：神经网络的训练过程本质上是一个能量优化问题，与统计物理学中的玻尔兹曼机、自旋玻璃等概念密切相关。Hinton早期的工作就是从物理学的角度理解神经网络，他提出的玻尔兹曼机就借鉴了统计力学的思想。诺贝尔委员会认为，神经网络不仅是计算机科学的突破，更是用物理学原理解决复杂系统问题的典范。

2018年，Hinton、LeCun和另一位深度学习先驱Yoshua Bengio（约书亚·本吉奥）共同获得了图灵奖，被称为”深度学习三巨头”。LeCun因为发明了卷积神经网络和推动其在工业界的应用而获奖，Bengio则因为在循环神经网络和注意力机制方面的贡献而获奖。这三位科学家在AI的”寒冬”期坚持研究神经网络，最终迎来了深度学习的春天。

CNN解决的核心问题是：如何让神经网络理解图像？

传统的全连接神经网络处理图像时，会把每个像素当作独立的输入。一张224×224的彩色图片就有150,528个输入参数，这导致参数量爆炸，训练困难，而且完全忽略了图像的空间结构。

CNN的核心思想是通过层层降维，从高维的像素数据中提取出低维的语义特征。一张224×224的彩色图片（ImageNet的标准输入尺寸）就有15万个像素点，而现实中的高清照片动辄几百万像素。但最终我们只需要判断”这是不是一只猫”这样一个简单的结论。CNN就是在做这个从高维到低维、从具体到抽象的转换。

三个关键设计巧妙地实现了这个过程：

局部连接：神经元只关注图像的一小块区域，就像人眼的感受野一样。这大幅减少了参数量，也符合图像的局部相关性特征——理解一个物体不需要同时看整张图片，先识别局部特征就够了。

权值共享：同一个卷积核在整张图片上滑动，用相同的参数提取不同位置的特征。这意味着无论猫出现在图片的左上角还是右下角，都能被同一个”猫特征检测器”识别出来。这种特性叫做平移不变性。但要注意，CNN对旋转、缩放等变换并不天然具备不变性——一只倒立的猫可能就识别不出来了。

有趣的是，这和人类视觉系统很相似。你试着把书倒过来读，会发现识别文字变得困难，需要在脑海中”旋转”回来。人眼也不是对所有变换都天然不变的，而是通过大量的视觉经验学会了处理各种变换。CNN也是如此，训练时需要做数据增强，通过旋转、翻转、缩放等操作让模型见过各种变换后的图片，就像人类从小到大积累视觉经验一样。

池化层：通过下采样直接降低特征图的分辨率。比如2×2的最大池化会把4个像素压缩成1个，数据量减少75%。这不仅减少了计算量，还让模型对位置变化更加鲁棒——猫的耳朵偏移几个像素，不影响我们认出它是猫。

整个CNN就像一个漏斗：输入是高维的像素矩阵，经过多层卷积和池化，特征图的空间尺寸不断缩小，但通道数（特征的种类）不断增加。最底层提取边缘、纹理等低级特征，中间层组合成形状、部件等中级特征，顶层形成物体、场景等高级语义。最终，几万维的像素被压缩成几百维的特征向量，再通过全连接层输出分类结果。

从LeNet到AlexNet，再到VGG、GoogLeNet、ResNet，CNN的演进主要围绕着”如何加深网络”展开。理论上，网络越深，能学习的特征就越抽象，性能应该越好。但实践中却遇到了两个棘手的问题：梯度消失和梯度爆炸。

神经网络的训练依赖反向传播算法，就像接力赛一样，误差信号从输出层一层层往回传。每经过一层，误差都要乘以该层的权重。如果权重普遍小于1，连续相乘几十次后，误差信号会变得极其微小，就像声音在传播中不断衰减，传到前面几层时已经听不见了。这就是梯度消失，导致前面的层几乎学不到东西。

反过来，如果权重普遍大于1，连续相乘后误差会指数级增长，就像雪崩一样越滚越大。这就是梯度爆炸，会让训练过程变得极不稳定，参数更新幅度过大，模型无法收敛。

ResNet在2015年提出的残差连接巧妙地解决了这个问题。它在网络中增加了”跳跃连接”，让信息可以直接跨越若干层传递，就像在接力赛中增加了直通车道。即使某些层的梯度消失了，误差信号也能通过这些捷径传回去。这个简单而优雅的设计让网络深度从十几层跃升到上百层甚至上千层，性能也随之大幅提升。

CNN在计算机视觉领域取得了巨大成功，但它的设计天然适配的是图像这种具有空间局部性的数据。当面对序列数据，比如文本、语音时，CNN就显得力不从心了。

循环神经网络(RNN)：记忆的引入

序列数据的特点是前后有依赖关系。”我吃苹果”和”苹果吃我”，虽然用了相同的三个词，但意思完全相反。要理解这句话，必须记住词的顺序和上下文关系。这种时序依赖性是CNN无法处理的。

在RNN出现之前，自然语言处理主要依赖词袋模型(Bag of Words)。这种方法把句子看作一个装满词的袋子，只统计每个词出现的次数，完全忽略词的顺序。就像把”我吃苹果”和”苹果吃我”都变成{我:1, 吃:1, 苹果:1}，两句话在模型眼中完全一样。

为了提升效果，研究者们在词袋模型基础上做了各种改进。TF-IDF通过降低常见词(如”的””是”)的权重，突出关键词的重要性。BM25进一步考虑了文档长度和词频饱和效应，成为搜索引擎的标配算法。这些方法在信息检索领域非常成功，Google早期的搜索引擎就大量使用了这类技术。

但词袋模型的本质缺陷无法克服：它丢失了词序信息。在一些简单任务上还能凑合，比如垃圾邮件分类——只要看到”中奖””转账”这些关键词，不管顺序如何，大概率是垃圾邮件。但面对需要理解语义的任务，比如机器翻译、问答系统，词袋模型就彻底失效了。

RNN在1986年就被提出，但直到2010年代才真正流行起来。它的核心思想是引入”记忆”：神经网络在处理当前输入时，会参考之前的隐藏状态。这就像人阅读文章时，会记住前面读过的内容来理解当前的句子。

RNN的结构看起来很简单：在每个时间步，网络接收当前输入和上一时刻的隐藏状态，输出当前的结果和新的隐藏状态。这个隐藏状态就是网络的”记忆”，它会随着序列的推进不断更新。

但标准RNN有个致命缺陷：长期依赖问题。当序列很长时，早期的信息在反向传播过程中会因为梯度消失而丢失。就像传话游戏，传的人越多，信息失真越严重。

1997年，Sepp Hochreiter和Jürgen Schmidhuber提出了LSTM(长短期记忆网络)，通过引入门控机制解决了这个问题。LSTM有三个门：遗忘门决定丢弃哪些旧信息，输入门决定接收哪些新信息，输出门决定输出什么。这种设计让网络能够选择性地记住重要信息，忘记无关信息。

2014年，Kyunghyun Cho提出了GRU(门控循环单元)，它简化了LSTM的结构，只用两个门就实现了类似的效果，训练速度更快。

RNN及其变体在机器翻译、语音识别、文本生成等任务上取得了显著成果。2016年，Google推出的神经机器翻译系统就是基于LSTM的，翻译质量相比之前的统计方法提升了60%。

但RNN也有无法克服的局限：它的序列化处理方式导致无法并行计算，训练速度慢；即使有LSTM的改进，处理超长序列时仍然会丢失信息；更重要的是，RNN的”记忆”是隐式的，我们无法直观地看到模型在关注序列的哪些部分。

Transformer与注意力机制：并行化的革命

2017年，Google的研究团队发表了论文《Attention is All You Need》，提出了Transformer架构。这篇论文的标题本身就是一种宣言：我们不需要RNN，不需要CNN，只需要注意力机制。

注意力机制的思想其实很直观。当你阅读”小明把书放在桌子上，然后他就去睡觉了”这句话时，你会自动知道”他”指的是”小明”而不是”桌子”。这种能力就是注意力——在理解当前词时，动态地关注句子中的相关部分。

Transformer的核心是自注意力(Self-Attention)机制。对于序列中的每个位置，模型会计算它与所有其他位置的相关性，然后根据这些相关性加权聚合信息。这个过程可以用三个矩阵来描述：

• **Query(查询)**：当前位置想要什么信息
• **Key(键)**：每个位置能提供什么信息
• **Value(值)**：每个位置的实际内容

通过计算Query和Key的相似度，模型决定应该关注哪些位置，然后加权求和对应的Value。这个过程完全可以并行化，因为每个位置的计算是独立的。

Transformer还引入了多头注意力(Multi-Head Attention)，让模型能够同时关注不同类型的信息。就像人在理解句子时，会同时考虑语法结构、语义关系、上下文等多个维度。

相比RNN，Transformer有三个显著优势：

并行化：所有位置可以同时计算，训练速度提升了数十倍。在GPU集群上，这种并行性的优势更加明显。

长距离依赖：任意两个位置之间的路径长度都是1，信息可以直接传递，不会像RNN那样经过多次传递而衰减。

可解释性：注意力权重是显式的，我们可以可视化模型在关注什么，这对理解和调试模型非常有帮助。

原始的Transformer采用了Encoder-Decoder架构，专为机器翻译设计。Encoder负责理解源语言（比如英语），Decoder负责生成目标语言（比如德语）。两者之间通过交叉注意力机制连接，让Decoder在生成每个词时都能关注到源语言的相关部分。这个设计在WMT 2014英德翻译任务上刷新了记录。

但Transformer的影响远不止于机器翻译。研究者很快发现，Encoder和Decoder可以单独使用，分别适合不同的任务。Encoder擅长理解和表示，Decoder擅长生成和预测。这为后来BERT和GPT的分野埋下了伏笔。

更令人惊讶的是，Transformer的通用性超出了所有人的预期。2020年，Google提出的Vision Transformer（ViT）把图片切成小块，当作序列来处理，在图像分类任务上超越了CNN。这打破了”CNN是视觉任务专用架构”的认知。随后，Transformer被应用到语音识别、视频理解、蛋白质结构预测、强化学习等各个领域，几乎无往不利。

原本为不同任务设计的专用架构——CNN处理图像、RNN处理序列、GNN处理图结构——正在被Transformer这个统一架构逐步替代。这种”大一统”的趋势背后，是一个深刻的洞察：无论是文本、图像还是语音，本质上都是数据序列，都可以用注意力机制来建模关系。

更重要的是，Transformer的可扩展性极强。通过增加层数、增大隐藏维度、使用更多数据，模型性能可以持续提升。这种”scaling law”（规模定律）为后来的大语言模型奠定了基础。OpenAI的研究表明，只要有足够的计算资源和数据，Transformer的性能可以预测性地提升，不会遇到明显的瓶颈。这让”暴力美学”成为可能——用更大的模型、更多的数据，就能获得更强的能力。

BERT(理解)与GPT(生成)：预训练的分野

有了Transformer这个强大的架构，下一个问题是：如何训练它？

传统的监督学习需要大量标注数据。在计算机视觉领域，ImageNet这个包含1400万张标注图片的数据集推动了CNN的突破。但在自然语言处理领域，情况完全不同。文本的标注比图像更复杂，成本也更高昂——给图片打标签只需要说”这是一只猫”，但标注文本的语义、情感、实体关系需要专业知识。更重要的是，语言任务千差万别，为每个任务都标注大量数据不现实。

能否让模型先在海量无标注文本上学习语言的通用知识，然后再针对具体任务微调？这就是预训练的思想。

2018年，两个里程碑式的模型几乎同时出现：Google的BERT和OpenAI的GPT。它们都基于Transformer，都采用预训练+微调的范式，但训练目标截然不同。

BERT：双向的理解者

BERT的全称是Bidirectional Encoder Representations from Transformers，核心是”双向”。它使用Transformer的编码器部分，通过掩码语言模型(Masked Language Model)进行预训练：随机遮住句子中15%的词，让模型根据上下文预测被遮住的词。

这种训练方式让BERT能够同时利用左右两侧的上下文，形成深层的双向表示。就像完形填空，你需要理解整个句子才能填对空。

BERT在11个NLP任务上刷新了记录，包括问答、文本分类、命名实体识别等。它特别擅长需要深度理解的任务，比如判断两个句子是否语义相似，或者从文章中找出问题的答案。

GPT：单向的生成者

GPT(Generative Pre-trained Transformer)采用了完全不同的路线。它使用Transformer的解码器部分，通过自回归语言模型进行预训练：根据前面的词预测下一个词。

这种训练方式是单向的，模型只能看到左侧的上下文。但这恰恰符合文本生成的场景——你在写作时，只能根据已经写下的内容来决定下一个词。

GPT-1在2018年6月发布时并没有引起太大关注，因为它在很多任务上不如BERT。但OpenAI坚持了这个方向，并在2019年发布了GPT-2，参数量从1.17亿增加到15亿。

GPT-2展现出了惊人的生成能力，给定一个开头，它能续写出连贯、有逻辑的长文本。更令人惊讶的是，它在零样本(zero-shot)设置下就能完成很多任务，不需要针对性的微调。

两条路线的本质差异

BERT和GPT代表了两种不同的AI哲学：

BERT是”理解型”模型，它通过双向上下文建立深层语义表示，擅长判断、分类、匹配等需要理解的任务。但它不是为生成设计的，生成文本时需要额外的解码策略。

GPT是”生成型”模型，它通过预测下一个词学习语言的概率分布，天然适合文本生成。虽然是单向的,但通过足够大的规模和数据，它也能展现出强大的理解能力。

2020年，GPT-3的发布彻底改变了游戏规则。1750亿参数的规模让它展现出了”涌现能力”——仅通过少量示例(few-shot)甚至零样本就能完成各种任务，不需要微调。这证明了生成式预训练的路线具有更好的可扩展性。

从此，大语言模型的主流范式转向了GPT的自回归生成路线。BERT仍然在特定的理解任务上有价值，但在通用人工智能的道路上，GPT代表的生成式模型走得更远。

这个分野不仅是技术路线的选择，更反映了对智能本质的不同理解：智能是理解世界，还是生成世界？或许两者本就是一体两面，而生成能力恰恰是更高层次的理解。

MoE专家模型：稀疏激活的智慧

当GPT-3用1750亿参数震惊世界时，人们开始思考一个问题：模型是不是越大越好?如果是，那么训练和推理的成本会不会成为瓶颈?

2021年，Google发布了Switch Transformer，参数量达到1.6万亿，是GPT-3的9倍多。但令人惊讶的是，它的训练成本反而更低，推理速度也更快。秘密就在于MoE(Mixture of Experts，混合专家模型)架构。

专家分工的哲学

MoE的核心思想来自一个朴素的观察：人类社会的高效运作依赖于专业分工。你不需要每个人都懂所有知识，而是让不同的专家处理不同的问题。医生看病，律师打官司，工程师写代码，各司其职。

传统的密集模型就像一个”全能选手”，每次推理都要激活所有参数。而MoE模型则像一个”专家团队”，包含多个子网络(专家)，每次只激活其中的一部分。一个门控网络(Gating Network)负责决定对于当前输入应该咨询哪些专家。

具体来说，MoE层会替换Transformer中的前馈网络(FFN)。对于每个token，门控网络计算一个概率分布，选择Top-K个专家来处理，然后将这些专家的输出加权求和。其他专家则完全不参与计算，参数保持”休眠”状态。

这个过程对用户是完全透明的。你无法直接指定”用数学专家来回答这个问题”——即使在提示词中写”你是一个数学专家”，这也只是在引导模型的输出风格，而不是在激活某个特定的MoE专家。MoE的专家是模型内部的神经网络模块，它们的激活是由门控网络根据每个token的特征自动决定的。

但提示词的内容确实会间接影响专家的选择。当你输入”计算这个积分”时，后续生成的token（数学符号、公式）会让门控网络倾向于激活在数学数据上训练较多的专家；当你输入”写一段Python代码”时，生成的代码token会激活擅长编程的专家。这种专业化是在训练过程中自动涌现的——不同的专家在不同类型的数据上获得了更低的损失，门控网络学会了根据token特征来路由到合适的专家。

有趣的是，研究者通过分析发现，专家的分工并不总是按照人类理解的”领域”来划分。有的专家可能专注于处理长句子，有的专注于处理罕见词汇，有的专注于某种语法结构。这种分工是数据驱动的，而非人为设计的。你在提示词中指定的”角色”，只是在语义层面引导模型，而MoE专家的激活发生在更底层的token处理层面。

稀疏激活的优势

这种设计带来了三个关键优势：

参数效率：虽然总参数量巨大，但每次推理只使用一小部分。Switch Transformer有1.6万亿参数，但每个token只激活其中的0.1%，实际计算量相当于一个10亿参数的密集模型。

训练加速：由于每次只更新部分参数，训练时的计算量和通信开销都大幅降低。Switch Transformer在相同的计算预算下，训练速度比T5快了7倍。

专业化能力：不同的专家会自动学习处理不同类型的输入。有的专家擅长处理数学问题，有的擅长处理代码，有的擅长处理对话。这种专业化分工让模型在各个领域都能有更好的表现。

从理论到实践

MoE的思想其实在1991年就被提出了，但直到深度学习时代才真正发挥作用。早期的尝试面临两个主要挑战：

负载均衡：如果所有输入都倾向于选择同一个专家，那么专家分工就失效了。为了解决这个问题，研究者引入了辅助损失函数，鼓励门控网络均匀地使用各个专家。

训练稳定性：稀疏激活导致梯度更新不均匀，容易出现训练不稳定。Switch Transformer通过降低专家容量、使用更小的初始化等技巧解决了这个问题。

2022年，Google的GLaM模型(1.2万亿参数)在少样本学习任务上超越了GPT-3，但训练成本只有GPT-3的三分之一。同年，OpenAI也在GPT-4中采用了MoE架构(虽然官方没有公开确认，但多方证据表明如此)。

2024年，Mistral AI发布的Mixtral 8x7B成为开源社区的明星。它有8个专家，每次激活2个，总参数量47B，但激活参数只有13B。在多个基准测试中，它的表现接近甚至超越了GPT-3.5，但推理成本要低得多。

2024年底，中国的DeepSeek团队将MoE技术推向了新的高度。DeepSeek-V3采用了创新的多token预测和细粒度专家分割技术，用不到600万美元的训练成本就达到了GPT-4级别的性能。更令人震惊的是，2025年初发布的DeepSeek-R1通过强化学习进一步提升了推理能力，在数学和编程等任务上超越了OpenAI的o1模型。DeepSeek证明了，通过精心设计的MoE架构和训练策略，可以用极低的成本训练出世界级的大模型，这彻底改变了人们对AI训练成本的认知。

专家模型的挑战

尽管MoE展现出巨大潜力，但它也带来了新的挑战：

内存占用：虽然计算量减少了，但所有专家的参数都需要加载到内存中。这对硬件提出了更高要求，也限制了模型的部署场景。

通信开销：在分布式训练中，不同的专家可能分布在不同的设备上，门控决策需要跨设备通信，这会成为新的瓶颈。

专家坍塌：如果训练不当，可能出现只有少数专家被频繁使用，其他专家退化的情况。这需要精心设计的训练策略来避免。

推理优化：如何在保持稀疏性的同时优化推理速度，如何在边缘设备上部署MoE模型，这些都是工程上的难题。

从密集到稀疏的范式转变

MoE代表了深度学习的一个重要趋势：从密集计算走向稀疏计算。这不仅是工程优化，更是对智能本质的新理解。

人脑有860亿个神经元，但在处理特定任务时，只有一小部分神经元被激活。这种稀疏激活机制让大脑能够在有限的能量预算下实现强大的智能。MoE模型正是在模仿这种机制。

更深层次地看，MoE体现了”规模”与”效率”的平衡。过去十年，深度学习的进步主要靠暴力堆砌参数和数据。但这条路不可能无限走下去，能源、成本、环境的约束都在逼近。MoE提供了一条新路：通过更聪明的架构设计，用更少的计算实现更强的能力。

这种思路在计算机产业史上并不陌生。从单核到多核，从CPU到GPU，从集中式到分布式，每一次架构创新都是在追求更高的性价比。MoE或许只是开始，未来还会有更多稀疏化、模块化的架构出现。

毕竟，智能的本质不是”知道所有事情”，而是”知道在什么时候调用什么知识”。这正是专家模型想要实现的。

进化的逻辑

回顾深度学习的进化之路，我们可以看到清晰的演进逻辑：

CNN解决了空间局部性问题，让神经网络能够理解图像的层次化特征。它的成功证明了深度学习的潜力，但也暴露了对特定数据结构的依赖。

RNN引入了记忆机制，让神经网络能够处理序列数据。但序列化的计算方式限制了它的规模化能力，长期依赖问题也始终没有完美解决。

Transformer通过注意力机制实现了并行化，打破了序列处理的瓶颈。它的通用性和可扩展性使其成为深度学习的新基础架构。

BERT和GPT则探索了两条不同的预训练路线，最终GPT的生成式范式因为更好的可扩展性和涌现能力而成为主流。

每一次架构创新，都不是凭空产生的，而是针对前一代模型的局限性提出的解决方案。这个过程遵循着”问题驱动”的规律：当一个架构在某些任务上遇到瓶颈时，新的架构就会应运而生。

更重要的是，这些架构的演进体现了深度学习从”特定任务”走向”通用智能”的趋势。CNN是为图像设计的，RNN是为序列设计的，而Transformer是通用的。GPT-3的出现更是证明了，通过足够大的规模和数据，单一的生成式模型可以处理几乎所有的语言任务。

这种从专用到通用的演进，与计算机产业的发展何其相似。从专用计算机到通用计算机，从单一功能的软件到操作系统，从垂直应用到平台生态，技术的进化总是朝着更通用、更可扩展的方向前进。

而现在，大语言模型正在成为新的”操作系统”，为各种AI应用提供基础能力。这或许就是深度学习进化的下一站。

2012 - 2015 年：深度学习大爆炸

2016 - 2018 年：感知到理解的飞跃

2019 - 2021 年：参数爆炸与生成预热

2022 年：大模型觉醒之年

2023 年：多模态 + 开源崛起

2024 年：Agentic 智能体元年

2025 年：规范驱动 + 技术融合爆发年

• Cursor Changelog
• Claude Code Changelog
• OpenCode Changelog
• Kiro Changelog
• Qoder Changelog
• Manus更新日志
• Copilot Changelog
• OpenAI Changelog
• Anthropic Changelog
• Huggingface 论文排行榜

视觉检测演进专项

NLP (自然语言处理) 专项

语音处理 (Speech) 专项

多模态生成 (AIGC) 专项：从像素重组到物理模拟

该领域完成了从“乱涂乱画”到“理解物理世界规律”的跨越。

具身智能 (Embodied AI) 专项：AI 走进现实世界

这是 AI 的“终极战场”，让算法拥有实体，在物理空间执行任务。

AI for Science 专项：AI 改变科研范式

AI 开始解决人类几十年无法攻克的科学难题（生物、材料、气象）。

音乐生成 (Music AI) 专项演进史

智能体 (Agentic Workflow) 专项：从工具到员工

不仅是对话，而是 AI 能够自主规划、使用工具、完成闭环任务。

2025年结束，过去一年里，AI火爆的一批。从开年梁文峰深度求索的DeepSeek爆火，再到Cursor / Claude Code这种AI编码工具出现，真的颠覆了程序员的三观。AI终于从只会聊天的机器人，变成了能真正赋能工作的生产力工具。而这都归功于AI Agent，所以2025年也被称为AI Agent元年。

年底的时候姚顺雨入职腾讯的事儿爆火了，回国前他写了篇《The Second Half》(中文版：AI进入下半场)。

看了一下他的几篇论文，ToT思维树: 利用大型语言模型进行有意识的问题解决和ReAct Agent架构（中文版：LLM Agent 的开山之作）最具影响力。其中ReAct是Prompt工程时代的“分水岭论文”，也是Agent时代的“理论起点”。

这篇文章我记录一下我对AI Agent的一些思考和代码实践。

AI Agent = LLM 作为决策器（Planner） + 工具执行循环（Act Loop）

AI本质是基于统计的经验主义的概率模型

1. 数据的“炼金术”：词嵌入 (Word Embeddings)

AI 并不认识“苹果”或“开心”这些词。在它的世界里，一切都是数字。

• 向量空间： AI 会把每一个词转化成一串长长的数字坐标（向量）。
• 语义相近： 在这个高维空间里，“猫”和“狗”的坐标离得很近，而“猫”和“手机”就离得很远。
• 逻辑运算： 著名的例子是：$国王 - 男人 + 女人 = 女王$。AI 通过这种数学关系来理解人类世界的逻辑。

只不过这个向量是在高维空间中表示，比如常见的预训练模型：

• BERT-base: 768 维
• BERT-large: 1024 维
• BGE-small (v1.5): 384 维
• BGE-base (v1.5): 768 维
• BGE-large (v1.5/M3): 1024 维
• GPT的text-embedding-ada-002: 1536 维
• GPT的text-embedding-3-large: 3072 维

既然是“炼金术”，训练模型的数据质量也决定了模型的智能程度，也就是计算机领域常说的“Garbage in, Garbage out”。DeepSeek训练成本低的原因出了极其省钱的架构 (MLA/MoE)和极致的硬件压榨，还有关键的一点是高质量数据。这就像从小看名著长大的小孩和从小看言情小说爽文长大的小孩，自然思考能力差距很大。你用知乎或者维基百科等语料数据训练出来的模型输出的都是结构化表达、知识科普、多角度分析，你用微博、抖音等语料数据训练出来的模型输出的都是情绪偏见、互联网流行梗。。。

2. 核心引擎：Transformer 架构与注意力机制

2017 年 Google 提出的Transformer是现在所有大模型的基石。

• 注意力机制 (Attention)： 当 AI 读到“他把苹果给了小明，因为它熟透了”时，它能精准地通过“注意力”判断出“它”指代的是“苹果”而不是“小明”。
• 并行处理： 以前的 AI 是一字一句读，现在的 AI 是把整篇文章“瞬间”吞下，同时分析所有词与词之间的联系。

3. 本质：超级“接龙”游戏

不管外表看起来多么像人类，AI 的底层逻辑始终是预测概率。

• 概率预测： 当你问“今天天气”，AI 并不是在“思考”，而是在计算：在“今天天气”后面，出现“不错”的概率是 80%，出现“火星”的概率是 0.001%。
• 涌现能力： 当模型规模大到一定程度（比如几千亿个参数）时，这种简单的“接龙”突然表现出了推理、编程、甚至幽默感。科学家管这叫“涌现”（Emergence）。用通俗的话说就是“读书百遍，其义自见”

AI 工作流程 = 将文字变数字 → 在高维空间找关系 → 计算下一个字出现的最高概率。

ReAct

现在的大模型更像是一个知识渊博的学者，他读了全世界文档、书籍、论文，但是大模型的知识只停留在训练完成前采集的数据，没有新的数据喂给他。

所以在此之前大模型的方向是通过RAG去检索外部的文档数据，这在之前的一篇文章中有过记录。RAG就是在模型生成答案前，先从外部系统检索相关知识，再把这些知识作为上下文交给模型生成回答返回给用户。

但是RAG仍然只是停留在信息的检索，没有对外部世界产生影响。即使是GraphRAG 本质上仍然是在解决“回答得更准”的问题，而不是“把事情做完”。

当问题只需要一个确定答案时，检索足够；但一旦任务需要决策、执行和反馈，仅仅把外部信息塞进上下文提示词就显得力不从心。模型无法根据中间结果调整行为，也无法主动调用外部能力去改变系统状态。

从工程角度看，RAG 的能力边界非常清晰：它只能“读”，不能“写”。

检索系统负责把外部世界的状态投射进模型的上下文，但模型本身并不具备改变这些状态的能力。无论是调用接口、修改配置、触发任务，还是根据中间结果重新规划流程，RAG 都无法完成闭环。

一旦目标从“生成答案”升级为“完成任务”，大模型就必须具备行动能力，而这正是 Agent 架构出现的直接原因。RAG可以作为Agent的信息来源，辅助大模型决策。

ReAct结合Reasoning和Action，将推理的内容转化成可实践的任务，再根据任务执行后环境反馈的错误再进行反思，如此循环最终达到目标。

1

生成提示词 → 调用 AI → 解析响应 → 执行工具 → 重复直到完成

稍微工程化成这样：

1
2
3
4
5
6

1. 构造上下文 / 提示词（Prompt + State）
2. 调用 LLM（决策 / 生成下一步行动）
3. 解析 LLM 输出（结构化 Action / Tool Call）
4. 执行工具（代码 / API / 系统操作）
5. 更新状态（Memory / Observation）
6. 判断是否完成，否则回到 1

这就是 Agent Loop（ReAct / Tool-Use Loop）。

The Rise and Potential of Large Language Model Based Agents: A Survey
中文版：大型语言模型智能体的兴起与潜力的调查

真实 Agent 一定比这几步复杂，这只是 “能跑起来的最小 Agent”，工业级通常会加这些层：

1. 状态（State / Memory）

• short-term memory（当前任务上下文）
• long-term memory（历史、向量库）
• working memory（中间结果）

否则 Agent 会“失忆”。

2. 约束与控制（Guardrail）

• 最大循环次数（防止死循环）
• 工具白名单
• 输出 Schema 校验
• 成本 / token 限制 （上下文工程）

3. 失败处理（Recovery）

• Tool 执行失败 → 反馈给 LLM
• 解析失败 → 让 LLM 重试 / 修正格式
• 结果不满足目标 → 自我反思（self-critique）

4. 终止条件（Done / Stop）

终止不只是：

• “LLM 说完成了”

而是：

• 达成目标条件
• 没有可执行 Action
• 达到最大迭代
• 置信度 / 评分达标

这也是为什么目前最成功的Agent是Cursor、Claude Code这类编程工具，因为编程这类工作可以通过判断代码编译是否成功，测试用例能不能过(Spec Driven Development)，来判断任务是否达成目标。程序的结果机器是可以验证的。还有一个关键的因素是，代码因为有git做版本控制，即使模型出现幻觉，也可以回滚。所以Coding Agent是目前落地最成功的Agent场景。

像Manus这样的想做成通用的Agent受限于模型自身能力，目前实际体验效果并没有编程领域Agent带来的震撼性强。

维度	Coding	GUI
状态可观测	高	低
行为可回滚	是（git）	否
结果可验证	是（test）	难
噪音	低	极高
权限风险	可控	极高

Agent 可行性 ≈ 状态可观测 × 行为可回滚 × 结果可验证 ÷ 风险

计算机可验证（machine-verifiable）是 Agent 是否可行的核心分水岭。Agent 能不能落地，和模型强不强关系反而没那么大。

没有可验证性的 Agent，只能当“助手”，不可能当“执行者”。

原因很简单，Agent 必须能判断：我做对了吗？要不要 retry？要不要升级策略？如果失败/成功不可判定，就不可能形成闭环。这相当于ReAct-Loop的临界条件，什么时候才能停止这个循环很关键。

Agent 的未来是「Verification-Driven」而不是「Model-Driven」。现在行业最大误区是：模型越强 → Agent 越可用，但真实情况是：可验证性越强 → Agent 越可靠。Spec-Driven Development 为计算机（而不是人）编写的“可验证契约”。

模型的各项指标都已经超过人类了，为什么还是没有牛逼的AI应用？问题不在执行者这个执行者的能力，而在任务定义方式。可验证性，就像给博士下达一个可量化的任务。不能量化的主观任务，就算博士也无法判断自己是否完成。

这个抽象，本质就是一个「状态机」

从工程角度看，Agent = 一个可控的状态机：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

┌────────┐
│ Prompt │
└───┬────┘
    ↓
┌────────┐
│  LLM   │  ← 决策器
└───┬────┘
    ↓
┌────────┐
│ Parser │  ← 协议层
└───┬────┘
    ↓
┌────────┐
│ Tools  │  ← 世界接口
└───┬────┘
    ↓
┌────────┐
│ State  │  ← 记忆 / 上下文
└────────┘
    ↑
    └──── loop

LangGraph/AutoGen/CrewAI/Spring AI Agent等AI Agent框架本质都是在管这个循环。

工程化落地：AI Agent框架

ReAct 循环本身很简单，Agent框架不是为“能跑”而生的，而是为“能长期稳定地跑在真实世界”而生的。

最小 ReAct 循环真的很简单，最简版 ReAct，大概就这么点逻辑：

1
2
3
4
5
6

while not done:
  prompt = build_prompt(state)
  response = call_llm(prompt)
  action = parse(response)
  observation = run_tool(action)
  state.update(observation)

我这里有rust版本实现的ReAct-Loop可以运行起来看一看

模型输出不稳定（这是第一个地狱）

你以为 LLM 会乖乖按照你系统提示词里要求的格式输出：

1

{ "tool": "search", "args": { "q": "xxx" } }

现实可能是： JSON 少个括号、字段拼错、输出半截自然语言、tool name 拼错

大模型并不像传统应用程序一样是“严格执行指令的程序”，大模型的本质是基于概率的token权重模型：在给定上下文的情况下，预测下一个 token 的概率最大值，从而组合成最终的文本返回。即使是相同prompt，相同上下文，重复调用也不一定得到相同的返回，有篇文章专门介绍了《在LLM推断中击败非确定性》。你要求大模型严格按json格式输出，但模型会觉得加一句解释，或者返回markdown更友好，人类友好性 vs 机器友好性冲突时，模型常选前者。

Tool的模式

Agent开发的核心就是提供Tool供大模型决策调用。目前Agent的Tool有三个运行模式：Function Call、MCP、SubAgent。

1、 Function Call

我写的ReAct-Loop这个例子就是Function Call，这是最简单的模式：就是Agent自身提供一个函数调用作为“Tool”丢给大模型。对于有参数的函数还要把参数和返回值的schema喂给大模型。

2、 MCP

MCP是‌Anthropic公司‌于‌2024年11月提出来的。MCP相当于把Function Call做成了可被调用的JSON-RPC服务，这样的好处是Agent与Tool解耦。MCP-Server通过标准的协议定义并暴露自己提供的服务：

1
2
3
4
5
6
7
8
9
10

{
  "name": "create_order",
  "description": "Create an order",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "number" }
    }
  }
}

Agent注册MCP服务供大模型调用。

MCP 本质上就是把「function call」标准化、外部化、服务化

3、 SubAgent / MultiAgent

SubAgent ≈ 把一个 agent 封装成一个 tool，供主 agent 调用。这么做的目的是把复杂性问题拆分成子问题交给SubAgent，这主要是解决上下文复杂度，防止主问题prompt爆炸。

这里有篇文章专门讲了多Agent架构 / 选择合适的多Agent架构

4、 A2A：Agent间的远程编排协议

和MCP类似，Agent间为了解耦也搞了个JSON-RPC协议。A2A协议由Google于2025年4月提出的，这和微服务很像：Agent-to-Agent (A2A) 协议支持在运行于不同服务器上的 Agent 之间进行对话转移，这些服务器可能位于不同的数据中心或由不同的组织管理。此能力支持分布式 Agent 架构和微服务部署。

你可能和我一样有个疑问：既然Agent可以作为Tool，那自然也可以通过MCP远程暴露给调用方，为什么还多此一举再搞个A2A协议？

A2A官网有句话定位很准：

Build with ADK (or any framework), equip with MCP (or any tool), and communicate with A2A, to remote agents, local agents, and humans.

目前各大厂的Agent框架

RAG相关开源项目：

• https://github.com/microsoft/graphrag
• https://github.com/infiniflow/ragflow
• https://github.com/HKUDS/LightRAG
• https://github.com/Tencent/WeKnora

Agent框架：

• https://github.com/microsoft/autogen
• https://github.com/google/adk-python
• https://github.com/openai/openai-agents-python
• https://github.com/anthropics/anthropic-sdk-python
• https://github.com/crewaiinc/crewai
• https://github.com/pydantic/pydantic-ai

AI时代的UI：

• https://github.com/google/A2UI

国内大厂的：

• https://github.com/agentscope-ai/agentscope
• https://github.com/TencentCloudADP/youtu-agent
• https://github.com/spring-ai-alibaba/DataAgent
• https://github.com/alibaba/spring-ai-alibaba/tree/main/spring-ai-alibaba-agent-framework

Rust社区相关库

• https://github.com/zavora-ai/adk-rust
• https://github.com/Abraxas-365/langchain-rust
• https://github.com/sobelio/llm-chain

推荐阅读：

• https://www.blog.langchain.com/context-engineering-for-agents/
• https://cognition.ai/blog/dont-build-multi-agents
• https://www.blog.langchain.com/choosing-the-right-multi-agent-architecture/

国内外大厂开源的GUI-Agent

• https://github.com/TencentQQGYLab/AppAgent
• https://github.com/X-PLUG/MobileAgent
• https://github.com/bytedance/UI-TARS-desktop
• https://deepwiki.com/microsoft/UFO
• https://github.com/droidrun/droidrun
• https://github.com/web-infra-dev/midscene

最近读了两篇文章，这两篇文章分别从宏观（InfluxData官方博客）和微观（掘金社区技术解析）的角度深入探讨了 FDAP 架构（Flight, DataFusion, Arrow, Parquet）及其在现代数据系统中的应用。

FDAP：新一代数据系统的基石架构

在当今数据爆炸的时代，传统的“大一统”数据平台已难以满足日益多样化和高性能的需求。针对特定场景（如时间序列、日志分析、金融交易等）构建的专用系统，往往能获得10到100倍的性能与成本优势。然而，从零开始构建一个高性能数据库或分析引擎，意味着要重复发明无数个复杂的轮子——内存布局、网络协议、查询优化器、存储格式……这不仅耗时耗力，而且极易出错。

正是在这样的背景下，FDAP 架构应运而生，并迅速成为构建下一代云原生、高性能数据系统的事实标准。FDAP 并非一个单一的产品，而是由四个强大的开源项目组成的协同技术栈：

• Flight: 高效的数据传输层
• DataFusion: 灵活的查询执行引擎
• Arrow: 统一的内存数据格式
• Parquet: 开放的列式存储格式

这套组合拳，让开发者能够将精力聚焦于业务逻辑本身，而非底层基础设施的重复建设。

FDAP 的核心组件：各司其职，协同增效

1. Apache Arrow：内存中的通用语言

Arrow 定义了一套标准化的、面向列式的内存数据格式。它解决了不同系统间数据交换时昂贵的序列化/反序列化（SerDe）开销问题。想象一下，Python 的 Pandas、Java 的 Spark、C++ 的计算库，如果都使用 Arrow 作为内存表示，它们之间的数据传递就无需任何转换，如同在同一语言内部操作一样高效。

对于 InfluxDB 3.0 这样的系统而言，采用 Arrow 意味着：
省去了自研内存模型的复杂性：无需再纠结于如何表示空值、处理字节序、设计向量化计算等底层细节。
无缝集成生态：查询结果可以直接被 Pandas、Spark、DuckDB 等工具消费，极大地简化了数据分析工作流。

2. Apache Parquet：经济高效的持久化存储

Parquet 是一种开放的、列式存储文件格式，以其卓越的压缩比和高效的谓词下推（Predicate Pushdown）能力而闻名。令人惊讶的是，在 InfluxData 的实践中，通用的 Parquet 格式在综合考虑索引等结构后，其压缩效率甚至比许多专为时间序列设计的私有格式高出5倍。

选择 Parquet 为 InfluxDB 3.0 带来了巨大的互操作性红利：
即插即用：任何支持 Parquet 的系统（如 Snowflake、Presto、Databricks）都可以直接读取 InfluxDB 存储的数据，无需复杂的 ETL 管道。
未来可扩展：依托于庞大的 Parquet 生态，系统可以轻松接入未来的分析、BI 或机器学习工具。

3. Apache Arrow Flight & FlightSQL：超高速的数据高速公路

Flight 是一个基于 gRPC 和 Arrow 构建的高性能 RPC 框架，专为在系统间高效传输 Arrow 数据而设计。在其之上，FlightSQL 定义了一套标准的 SQL 接口。

这对 InfluxDB 3.0 的意义是革命性的：
告别驱动地狱：传统数据库需要为每种语言（JDBC、ODBC、Python DB-API等）维护一套复杂的客户端驱动。而通过实现 FlightSQL，InfluxDB 3.0 自动获得了所有现有 FlightSQL 驱动的支持，省去了一个完整的驱动开发团队。
极致性能：Flight 避免了数据在网络传输过程中的编解码开销，使得大规模数据集的传输速度得到数量级的提升。正如 Dremio 的实践所证明，其性能相比传统 ODBC/JDBC 可提升20-50倍。

4. Apache DataFusion：开箱即用的查询大脑

DataFusion 是一个用 Rust 编写的现代化、可扩展的查询引擎，它天然使用 Arrow 作为内存模型。它内置了SQL解析、查询优化、向量化执行、并行处理等企业级OLAP引擎所需的核心功能。

对于 InfluxData 而言，这意味着：
站在巨人的肩膀上：无需投入数十人年的精力去从头构建一个查询引擎。他们只需在 DataFusion 的基础上，专注于实现时间序列特有的功能，如 InfluxQL 语言支持、数据去重、时间窗口填充等。
持续受益于社区：DataFusion 的每一次功能增强和性能优化，都会自动惠及 InfluxDB 3.0。

FDAP 的威力：不止于 InfluxDB

FDAP 架构的价值已被众多前沿项目所验证。除了作为其命名来源的 InfluxDB 3.0，我们还能看到：

• CeresDB：分布式、云原生时间序列数据库。已捐献给apache/horaedb
• Coralogix：全栈可观测平台
• Greptime：云原生时间序列数据库
• Synnada：统一的流媒体和分析平台
• OpenObserve：专为日志、指标和追踪构建的可观测性平台
• Dremio：数据即服务平台。这个分布式 SQL 查询引擎深度利用 Arrow 作为其内存核心，并贡献了 Gandiva（一个基于 LLVM 的高性能表达式编译器）来加速 Arrow 上的计算。
• Spice.ai：一个旨在简化 AI/ML 应用开发的运行时，它通过 Arrow 和 Flight 在数据源与 AI 引擎之间建立高效通道，将可处理的数据规模提升了10-100倍。

总结：拥抱开放标准，释放创新潜能

FDAP 架构的成功，本质上是开放标准和模块化设计理念的胜利。它将构建一个现代数据系统所需的复杂技术分解为几个清晰、独立且高度优化的组件。开发者不再需要“重复造轮子”，而是可以像搭积木一样，组合这些世界级的开源组件，快速构建出高性能、高兼容性的专属解决方案。

正如 LAMP（Linux, Apache, MySQL, PHP/Python/Perl）堆栈曾赋能了第一代互联网应用的繁荣，我们有理由相信，FDAP 架构将成为驱动下一代数据密集型应用（尤其是云原生、AI/ML 和实时分析场景）创新的核心引擎。对于任何希望在数据领域有所建树的团队和个人来说，理解和掌握 FDAP，无疑是把握未来的关键一步。

如果你想用一句话解释过去 70 年计算机产业的全部变化，那就是：

每一次时代变革，都是分层计算栈中某几层发生了质变，然后反过来重塑了整条技术链。

不论是巨型机、PC、互联网、移动互联网、云计算还是 AI，每一次浪潮的内部逻辑，都可以用一张“分层计算栈”概括。

计算机不是一个单一技术，而是一个自下而上层层堆叠的巨大系统。
一种经典划分方式是将产业分成七层技术栈：

1. 硬件层（Hardware）
2. 系统软件层（OS / Compiler / VM）
3. 平台层（DB、Middleware、Cloud Runtime）
4. 网络与连接层（Internet、协议、CDN）
5. 数据层（Data、Search、Index、Analytics）
6. 应用层（Application）
7. 用户与社会层（User / Economy / Behavior）

只要某一层出现跨越式变化，整个产业就会迎来新一轮重构。
这就是 IT 行业始终“周而复始”的原因。

零、军事需求的奠基：战争催生计算需求

现代计算机并不是从民用或学术需求中诞生的，而是直接起源于战争，尤其是二战时期的军事需求

军事活动出现了几个人力无法承受的计算问题：弹道计算、密码破译、雷达与防空、原子弹研发。这些问题的共同点是：计算量巨大、时间要求极高、人工或机械计算根本来不及。

二战中英国的艾伦·图灵设计了Bombe机通过“机器穷举”破解德军 Enigma 密码，并提出了图灵机计算模型。计算机科学领域的诺贝尔奖——图灵奖，也为了纪念这位先驱而设立。

二战中参与美国曼哈顿计划的冯·诺依曼因计算导弹弹道的需要，为适配不同的武器系统设计军事通用平台提出了冯·诺依曼计算架构，让“通用计算机”成为现实工程。

二战中美国的克劳德·香农为避免通信传输中的噪声干扰、信息截获等问题，设计了纠错和加密等系统，并提出了《信息论》为现代网络通信和密码学奠定了基础。

一、巨型机时代：硬件是王，软件只是附属品

1950s—1970s：硬件层第一次突破

• 电子管、晶体管的发明，使计算机从军事走向科研与国家机构。
• 操作系统还十分原始，编程依赖纸带、批处理。
• 应用层非常薄，只能运行企业记账、科学计算等简单任务。

这是计算栈高度不平衡的时代：
硬件占据主导地位，系统软件和应用极弱。

二、小型机与 UNIX：系统软件成为新中心

1970s—1980s：操作系统层第一次觉醒

IBM 推出大型机IBM System 360和370，DEC推出PDP系列小型机，AT&T 推出 UNIX(C语言也因此诞生)。
第一次，计算机具备了现代意义上的操作系统：

• 多任务调度
• 用户/权限模型
• 文件系统（“一切皆文件”的设计哲学）
• 程序接口（API -> POSIX标准）

系统软件层变得强大之后，应用层得以爆发：

• 终端机
• 企业 MIS 系统
• 商业数据库（Oracle）

这是第一次产业重心从“硬件 → 软件”迁移。

三、PC 时代：微处理器+桌面操作系统塑造了软件业

1980s—2000s：硬件和系统软件共同成熟

两项突破改变世界：

1. Intel x86 微处理器
2. Windows / macOS 图形化操作系统

PC 技术栈快速完整化：

• 硬件：集成电路的发明使得 CPU 可以量产。CPU指令集标准化，x86成为 PC 时代的事实标准。
• OS：图形界面变成主流，施乐公司发明的鼠标也有了用武之地。

  1983年Borland基于Pascal语言开发Turbo Pascal，1987年基于C语言开发了Turbo C成了IBM PC上首个C语言IDE，1990年Turbo C++取代了Turbo C，1995年Turbo Pascal被Delphi取代。
  另一边微软在1983年也推出了Microsoft C由于不符合ANSI C标准只在微软内部使用，直到1985年才作为产品发布，1993年C++也被微软应用到自己的图形软件开发(VC++/MFC)。

• 网络：TCP/IP 占据互联网基座
• 平台：关系数据库、Visual Studio
• 应用：Office、金山WPS、QQ、杀毒软件
• 用户：计算机进入千家万户

这个时代最典型的结构就是：

OS＋应用捆绑的单机软件生态。

四、互联网时代：网络层成为产业主导

1995—2008：网络层突破引发应用层爆炸

• 1966 年：高锟提出可行理论 → 光纤通信概念诞生。
• 1970 年：康宁制造出世界上第一根实用低损耗光纤 → 光纤真正诞生。
• 1977 年：第一条商用光纤通信线路。
• 1980–1990年，欧美和日本开始用光纤铺设长距离主干网，中国赵梓森推动“八纵八横”国家光纤骨干网建设。
• 1994年5月21日，在钱天白教授和德国卡尔斯鲁厄大学的协助下，中国科学院计算机网络信息中心完成了中国国家顶级域名（CN）服务器的设置，改变了中国的CN顶级域名服务器一直放在国外的历史。
• 1995–2005：光纤全球爆发普及（互联网时代），1998年中国光纤覆盖绝大多数地级市。

万维网（HTTP/HTML）、浏览器、搜索引擎三件事重新定义应用形态：

• 应用不再是“装在你电脑上的东西”
• 而是 通过网络实时获取与渲染的超文本

应用从C/S架构向B/S架构演进。计算栈的力量第一次从设备迁移到了网络：

应用层从“软件”变成了“服务”，C/S架构时期为专用程序定制协议催生了ftp、smtp、pop3等协议百花齐放，而B/S架构后浏览器的出现HTTP协议逐渐成为应用层协议的事实标准。B/S 倒逼着很多 C/S 应用也不得不 HTTP 化。

在系统软件层：Windows Server因为收费闭源，而且GUI占用大量硬件资源；UNIX系列商业收费的System V 和 学术系的 BSD碎片化严重；所以基于Minix开发的免费开源的Linux成了互联网时代的“隐形操作系统”，也是LAMP开源套件里的核心。用户不关心你的服务端程序师运行在GUI还是CLI的服务器，返回的HTML最终都会在浏览器端渲染，所以。Intel 也是乘着互联网的东风从桌面市场真正进入服务器领域，Intel第一款专为服务器市场设计的芯片是Pentium Pro‌，它于1995年发布，标志着Intel在服务器工作站领域迈出关键一步；1998–2001年：Xeon + Linux，x86 正式成为主流服务器架构；2006年后：Intel 基本统治通用服务器 CPU 市场。

可以说互联网不仅重塑了应用形态，也彻底改变了服务器的形态。

在互联网之前，服务器的默认形态是：UNIX 操作系统、RISC 架构 CPU（SPARC、POWER、PA-RISC、Alpha）、昂贵的小型机 / 大型机、纵向扩展（Scale Up）。

而互联网带来的，是一类完全不同的计算需求：大量并发 Web 请求、单个请求计算量很小、容忍单机故障、依赖集群而非单机可靠性。

五、移动互联网：终端硬件 + 分发平台重写应用层

2008—2020：硬件层与用户层的同步胜利

iPhone + App Store = 移动互联网最强方程式。

硬件层改变了交互方式：

• ARM 架构配合 SoC 高度集成，使单位能耗计算能力大幅提升，高通等芯片厂商在移动终端计算领域取代了以 x86 为核心的 Intel 体系，成为移动互联网时代的主导芯片。
• 多点触控改变用户输入方式，语音、摄像头等硬件被整合进终端。过去只能打电话发短信的手机变成更加“智能”的移动终端，重塑了应用层软件形态。

系统层：开源与闭源之争

另一边基于Linux内核开发的Android又因为开源免费，迅速风靡全球，与闭源的iPhone iOS分庭抗礼。Java因其庞大的生态被Android选为应用层开发语言，得以再次繁荣。

iOS 赢得了利润（Apple 拿走行业 80%+ 利润），Android 赢得了用户（覆盖全球 30 亿+ 智能手机用户）——这是两种不同的“胜利”。

分发层改变了应用生态：

• App Store / 应用商店
• 隐私沙盒模型
• 严格权限系统

应用层进一步重构：

• 微信：超级应用
• 抖音：短视频新交互
• 移动电商：支付、位置、摄像头等能力整合

这是第一次：用户层需求反过来驱动技术栈演进。

六、云计算时代：平台层成为核心竞争力

2010—2020：平台层统治企业计算

云计算把基础设施彻底抽象化：

• IaaS(Infrastructure as a Service，基础设施即服务)：弹性算力取代IDC机房
• PaaS(Platform as a Service，平台即服务)：数据库、消息队列、对象存储成为服务
• Kubernetes：在抽象层面上承担了传统操作系统对计算资源的管理职责，因此常被称为“分布式云原生操作系统”。对底层管理分布式硬件资源：IaaS（VM、网络、磁盘）；对上层提供容器运行环境、调度、服务发现、扩缩容。

这意味着：系统软件层的一部分与平台层融合成“云操作系统”。

应用从单体 → 分布式 → 微服务，IT 架构全面升级。

谷歌选择开发Golang并作为Kubernetes的实现语言，Golang得以在云原生时代成为基础设施级语言。

七、AI 时代：数据层与模型层成为新的操作系统

2022—？：AI 让技术栈再次重写

这一次变革极其特殊：不是硬件、不是网络，而是 数据与模型 反过来吞并系统软件。

AI 时代的计算栈正在重构：

1. 硬件层

NVIDIA GPU、AI 加速器成为计算核心。

2. 操作系统层（重新定义）

GPT / Qwen / DeepSeek 这样的模型 = 新一代“语义操作系统”。

它们具备传统 OS 不具备的能力：

• 理解自然语言
• 执行跨应用任务
• 自动调用工具和 API
• 多 Agent 协作

3. 平台层

• 向量数据库
• RAG
• 自动化工作流
• AI 代理平台（MCP）

4. 数据层

数据变成模型能力的源头（训练集 → 推理 → 反馈 → 自学习）。

5. 应用层

App 开始消失，被“AI 工作流”“AI 助手”取代。

6. 用户层

从“点击” → “对话” → “让 AI 自动完成任务”。

AI 时代的关键变化是：

应用从“人写的逻辑”变成“模型执行的意图”。

八、未来十年：计算栈将出现三大重构趋势

趋势 1：AI OS 取代传统OS 交互

应用程序不再前台运行，而是由 AI agent调度：

• “帮我整理这批数据”
• “把我网站的 SEO 提升”
• “自动完成这个流程”

手机、电脑界面会大幅简化。比如最近发布的AI眼镜

趋势 2：网络从数据包通信转向语义通信

未来的协议不是 HTTP/JSON，而是：

• “我需要一个符合以下目标的任务”
• “这是我当前的上下文”

Agent 协议（如 MCP）将成为新基座。

趋势 3：数据变成个人资产，模型在本地运行

端侧模型 + 私有数据 + 隐私计算
将让 AI 成为每个人的“第二大脑”。

之前一直都是用hexo-theme-webstack做内网导航，这就像公司的门户网站一样，对内网所有的系统手动做索引。

但是手动做索引太慢了，而且维护成本高，自然而然地就有了从门户升级到搜索引擎的需求。目前看到最流行的就是Fess这个企业级的搜索引擎。

官方文档1中如何安装和配置搜索引擎爬虫的功能。

官方文档7还提到了内网中需要带认证的系统如何爬取。

具体可以看一下官方的教程，在公司里部署一个这个搜索引擎，就可以对企业内部所有的文档做索引，方便员工进行信息检索。这就相当于公司内网的百度，可以指定爬取的网站必须是内网的域名或ip。

fess在github有提供docker方式的部署文件，底层的存储使用elasticsearch或者开源替代品opensearch。

部署完成后需要配置爬虫规则，目前系统支持web爬虫和文件爬虫等多种爬网方式。

公司涉及到业务团队与IM团队的数据同步，为了解耦避免修改我们这边的代码，同时为了性能考虑，打算用canal来处理。

具体步骤都是参考了canal官方的文档

1、安装canal-admin

一个canal-admin是可以管理多个canal集群的。所以我把canal-admin安装在了base命名空间下。

配置好canal-manager数据库后，安装admin到base命名空间下。

1
2
3
4

## 切换至base命名空间
kubens recircle-industry-base-system
## 安装admin
helm install canal-admin -f ./admin-values.yaml ./canal-admin

我们现在是每个命名空间一个canal集群，dev、test、pre分别对应了三个环境。

2、安装zookeeper集群

1
2
3
4

## 切换到preview命名空间
kubens recircle-industry-platform-preview
## 创建zk集群
helm install canal-zookeeper oci://registry-1.docker.io/bitnamicharts/zookeeper

安装完成后，把zookeeper的k8s service地址填到canal-admin中。

然后可以针对这个集群添加主配置，这个配置就是集群下所有canal-server的instance默认的配置，在这里可以配置canal-admin地址、记录表结构发生变化的tsdb的地址、消息队列的地址：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190

#################################################
######### common argument#############
#################################################
# tcp bind ip
canal.ip =
# register ip to zookeeper
canal.register.ip =
canal.port = 11111
canal.metrics.pull.port = 11112
# canal instance user/passwd
canal.user = admin
canal.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441

# canal admin config
canal.admin.manager = canal-admin.recircle-industry-base-system:8089
canal.admin.port = 11110
canal.admin.user = admin
canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441
# admin auto register
#canal.admin.register.auto = true
#canal.admin.register.cluster =
#canal.admin.register.name =


canal.zkServers = canal-zookeeper.recircle-industry-platform-preview:2181
# flush data to zk
canal.zookeeper.flush.period = 1000
canal.withoutNetty = false
# tcp, kafka, rocketMQ, rabbitMQ, pulsarMQ
canal.serverMode = rocketMQ
# flush meta cursor/parse position to file
canal.file.data.dir = ${canal.conf.dir}
canal.file.flush.period = 1000
## memory store RingBuffer size, should be Math.pow(2,n)
canal.instance.memory.buffer.size = 16384
## memory store RingBuffer used memory unit size , default 1kb
canal.instance.memory.buffer.memunit = 1024 
## meory store gets mode used MEMSIZE or ITEMSIZE
canal.instance.memory.batch.mode = MEMSIZE
canal.instance.memory.rawEntry = true

## detecing config
canal.instance.detecting.enable = false
#canal.instance.detecting.sql = insert into retl.xdual values(1,now()) on duplicate key update x=now()
canal.instance.detecting.sql = select 1
canal.instance.detecting.interval.time = 3
canal.instance.detecting.retry.threshold = 3
canal.instance.detecting.heartbeatHaEnable = false

# support maximum transaction size, more than the size of the transaction will be cut into multiple transactions delivery
canal.instance.transaction.size =  1024
# mysql fallback connected to new master should fallback times
canal.instance.fallbackIntervalInSeconds = 60

# network config
canal.instance.network.receiveBufferSize = 16384
canal.instance.network.sendBufferSize = 16384
canal.instance.network.soTimeout = 30

# binlog filter config
canal.instance.filter.druid.ddl = true
canal.instance.filter.query.dcl = false
canal.instance.filter.query.dml = false
canal.instance.filter.query.ddl = false
canal.instance.filter.table.error = false
canal.instance.filter.rows = false
canal.instance.filter.transaction.entry = false
canal.instance.filter.dml.insert = false
canal.instance.filter.dml.update = false
canal.instance.filter.dml.delete = false

# binlog format/image check
canal.instance.binlog.format = ROW,STATEMENT,MIXED 
canal.instance.binlog.image = FULL,MINIMAL,NOBLOB

# binlog ddl isolation
canal.instance.get.ddl.isolation = false

# parallel parser config
canal.instance.parser.parallel = true
## concurrent thread number, default 60% available processors, suggest not to exceed Runtime.getRuntime().availableProcessors()
#canal.instance.parser.parallelThreadSize = 16
## disruptor ringbuffer size, must be power of 2
canal.instance.parser.parallelBufferSize = 256

# table meta tsdb info
canal.instance.tsdb.enable = true
#canal.instance.tsdb.dir = ${canal.file.data.dir:../conf}/${canal.instance.destination:}
canal.instance.tsdb.url = jdbc:mysql://db.irecircle.com:3306/canal_tsdb?useUnicode=true&characterEncoding=UTF-8&useSSL=false
canal.instance.tsdb.dbUsername = root
canal.instance.tsdb.dbPassword = 123456
# dump snapshot interval, default 24 hour
canal.instance.tsdb.snapshot.interval = 24
# purge snapshot expire , default 360 hour(15 days)
canal.instance.tsdb.snapshot.expire = 360



#################################################
######### destinations#############
#################################################
canal.destinations =
# conf root dir
canal.conf.dir = ../conf
# auto scan instance dir add/remove and start/stop instance
canal.auto.scan = true
canal.auto.scan.interval = 5
# set this value to 'true' means that when binlog pos not found, skip to latest.
# WARN: pls keep 'false' in production env, or if you know what you want.
canal.auto.reset.latest.pos.mode = false

#canal.instance.tsdb.spring.xml = classpath:spring/tsdb/h2-tsdb.xml
canal.instance.tsdb.spring.xml = classpath:spring/tsdb/mysql-tsdb.xml

canal.instance.global.mode = manager
canal.instance.global.lazy = false
canal.instance.global.manager.address = ${canal.admin.manager}
#canal.instance.global.spring.xml = classpath:spring/memory-instance.xml
#canal.instance.global.spring.xml = classpath:spring/file-instance.xml
canal.instance.global.spring.xml = classpath:spring/default-instance.xml

##################################################
#########       MQ Properties      #############
##################################################
# aliyun ak/sk , support rds/mq
canal.aliyun.accessKey =
canal.aliyun.secretKey =
canal.aliyun.uid=

canal.mq.flatMessage = true
canal.mq.canalBatchSize = 50
canal.mq.canalGetTimeout = 100
# Set this value to "cloud", if you want open message trace feature in aliyun.
canal.mq.accessChannel = local

canal.mq.database.hash = true
canal.mq.send.thread.size = 30
canal.mq.build.thread.size = 8

##################################################
#########      Kafka      #############
##################################################
kafka.bootstrap.servers = 127.0.0.1:6667
kafka.acks = all
kafka.compression.type = none
kafka.batch.size = 16384
kafka.linger.ms = 1
kafka.max.request.size = 1048576
kafka.buffer.memory = 33554432
kafka.max.in.flight.requests.per.connection = 1
kafka.retries = 0

kafka.kerberos.enable = false
kafka.kerberos.krb5.file = ../conf/kerberos/krb5.conf
kafka.kerberos.jaas.file = ../conf/kerberos/jaas.conf

# sasl demo
# kafka.sasl.jaas.config = org.apache.kafka.common.security.scram.ScramLoginModule required \\n username=\"alice\" \\npassword="alice-secret\";
# kafka.sasl.mechanism = SCRAM-SHA-512
# kafka.security.protocol = SASL_PLAINTEXT

##################################################
#########     RocketMQ     #############
##################################################
rocketmq.producer.group = preview-canal
rocketmq.enable.message.trace = false
rocketmq.customized.trace.topic =
rocketmq.namespace =
rocketmq.namesrv.addr = 192.168.110.46:9876
rocketmq.retry.times.when.send.failed = 0
rocketmq.vip.channel.enabled = false
rocketmq.tag =

##################################################
#########     RabbitMQ     #############
##################################################
rabbitmq.host =
rabbitmq.virtual.host =
rabbitmq.exchange =
rabbitmq.username =
rabbitmq.password =
rabbitmq.deliveryMode =


##################################################
#########       Pulsar         #############
##################################################
pulsarmq.serverUrl =
pulsarmq.roleToken =
pulsarmq.topicTenantPrefix =

3、部署canal-server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 主要配置
server:
  config: |
    canal.port = 11111
    canal.metrics.pull.port = 11112

    # register ip
    canal.register.ip =

    # 配置canal-admin地址
    canal.admin.manager = canal-admin.recircle-industry-base-system:8089
    canal.admin.port = 11110
    canal.admin.user = admin
    canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441
    # admin auto register
    canal.admin.register.auto = true
    canal.admin.register.cluster = pre # 配置集群

部署canal-server

1

helm install canal-server -f ./server-values.yaml ./canal-server

这个canal-server是可以部署多个replica的

instance 实例创建

1
2
3
4
5
6
7
8
9
10

# 配置你要监听的数据库
canal.instance.master.address=127.0.0.1:3306
canal.instance.dbUsername=****
canal.instance.dbPassword=****

# 过滤监听哪些表
canal.instance.filter.regex=.*\\..*

# 如果是推送到rabbitmq，需要配置 Routing Key
canal.mq.topic=你的Routing Key

之前在Scrum敏捷管理制度设计一文中，针对公司存在的诸多问题，基于scrum设计了一套产研管理制度。并在最后给出了产研团队量化考核的指标。

但是这套制度如果没有实际落地的绩效激励制度，那就是空中楼阁。

马云曾说过：十个人的公司、一百人的公司、五百人的公司、一千人的公司和一万人的公司, 带队伍的方法是完全不一样的, 但管理的最低要求是一致的。这个最低要求就是十六个字：⽬标清晰，职责明确，赏罚分明，超越伯乐。

其中呢赏罚分明就需要考验公司激励制度如何设计。激励如果不能引起团队其他人的眼红，那这个激励是无效的；惩罚如果不痛不痒不能震慑团队中其他同类型的人，那这个惩罚也是无效的。

但是在赏罚分明的同时如何保证团队的凝聚力，这又是一个管理的重大大挑战。

很多团队在推行 Scrum 时都会遇到类似挑战：

• Scrum 强调 自组织、团队协作与持续改进，但现实中又必须面对 绩效考核、奖惩与个人激励 的管理要求。
• 如何在不破坏 Scrum 精神的前提下，建立 赏罚分明 且 团队凝聚力强 的绩效制度，是一个非常考验管理设计的课题。

一、核心原则（必须遵守的三条底线）

1. 以团队为中心，兼顾个人贡献
   Scrum 的目标是交付价值、促进协作，不应把绩效考核变成“个人功劳榜”。
   核心是：团队绩效优先，个人绩效只在团队绩效基础上分配。

2. 透明、公正、可度量
   所有指标应公开、客观，不靠主观印象，避免暗箱操作。

3. 鼓励正向激励，慎用惩罚
   Scrum 关注持续改进，惩罚只用于底线问题（如消极怠工），主流策略应是激励与辅导。

二、绩效考核体系设计（3+2 模型）

3+2 模型指的是：3 个团队维度 + 2 个个人维度

团队维度（占比 60%）

这 3 项构成团队绩效，影响团队整体奖金/绩效系数。

个人维度（占比 40%）

注意：不建议用故事点直接衡量个人绩效，会导致“抢任务”、“不帮人”问题。
更好的做法是用“团队贡献”+“协作行为”综合打分。

三、绩效计算与奖惩设计

1. 绩效评分

• 团队绩效：权重 60%，每个团队平均绩效得分
• 个人绩效：权重 40%，基于个人贡献与Scrum行为
• 最终得分 = 0.6 × 团队得分 + 0.4 × 个人得分

2. 奖励机制

• 团队奖励：团队绩效优秀，发放团队奖金 + 公开表彰 + 团建基金

• 个人奖励：

  • 个人得分优秀的，额外奖励/晋升优先权
  • 个人得分中等，但团队表现优异，也能共享团队成果
  • 鼓励“跨界协作”和“帮助他人”的行为

3. 惩罚机制（轻惩 + 辅导为主）

• 低绩效连续2个周期 → 约谈辅导、设立改进目标
• 态度消极/破坏团队协作 → 书面警告
• 严重失职 → 绩效扣分或组织调整，罚款收录到团建基金

四、周期与反馈机制

关键：绩效体系应“可调整”，根据团队成熟度、目标变化持续优化。

五、团队凝聚力保障机制

为了防止绩效制度破坏团队氛围：

1. 协作行为纳入考核
   鼓励“帮助他人”“知识共享”“技术分享”等正向行为。

2. 公开透明
   所有评估标准与结果均公开，避免“暗箱”与“政治斗争”。

3. 团队目标统一
   所有人都围绕共同目标，形成“我们一起赢”的氛围。

4. 奖励团队，不惩罚个体（除非极端）
   强调团队共进退，问题先由团队自省，再个人改进。

5. Scrum Master 的文化守护者角色
   Scrum Master要负责防止考核制度异化为“绩效内卷”。

refs:

• 敏捷团队绩效考核: https://zhuanlan.zhihu.com/p/568575458
• 深入浅出了解 OKR（一）：揭开 OKR 的神秘面纱: https://zhuanlan.zhihu.com/p/130722558
• OKR与Scrum: https://www.zhihu.com/column/OKRScrum

一、背景

2003年国务院国资委成立后，各省也陆续成立省级国资委，承担 出资人职责。原先“行业主管部门管企业”的格局逐步淡出，国资委统一负责监管。
在这个过程中，江西省也对原来的 省属企事业单位、专业公司、集团公司 进行了多轮整合。

二、江西的主要省级国资平台

上图提到的几家，功能定位不同：

1. 江西省国兴资产管理有限公司

   • 主要做“非主业、低效无效资产”处置和“历史遗留问题”化解。
   • 有点类似“国有坏账资产处理平台”。
   • 承接一些改革过程中剥离出来的资产、债务、办社会职能。

2. 江西省国有资本运营控股集团有限公司（简称“省国控”）

   • 定位为 国有资本投资、运营公司试点，承担资本运作、股权管理职能。
   • 类似央企里的国新控股、北京的“首都国资公司”、广东的“粤科金控”。
   • 偏向于“管资本”，比如金融股权、混改股权投资平台。
   • 下属大部分是 大型、垄断性国企，比如能源、电信、金融、医药等。
   • 这些企业 利润率高、现金流稳定，是江西的“利润奶牛”。
   • 国控集团通过持股、资本运作来对这些企业进行“管资本”，而不是直接去管经营。
   • 把强势行业的优质企业集中到国控下面，有两个目的：
     • 财政分红：省国控每年能给省财政贡献稳定收益。
     • 资本运作：便于混改、上市、股权转让，增强国资的资本流动性。

3. 江西省投资集团有限公司

   • 原来是以“能源、交通、重大基建投资”为核心的综合投资集团。
   • 早期承担很多省里的 重点工程投融资 任务。
   • 下属企业通常与电力、交通、基建、金融投资相关的城投类公司（基建投融资平台）。
   • 这些公司承担了很多地方政府基建融资职能，也就是典型的“城投债”主体。
   • 省投在某种程度上成了 全省城投资源的二级整合平台，既帮助地方融资，又形成了一个债务池。
   • 逻辑：城投公司本身盈利能力差，多靠财政兜底，放在“投资集团”下面，契合其“基建融资工具”的定位。

4. 江西省农业发展集团有限公司

   • 承接农业、粮食、林业、供销等原先分散的省属企事业单位。
   • 定位是 服务“三农”、粮食安全、乡村振兴。
   • 有一定的政策性功能，比如粮食储备、农资供应。

简单总结逻辑：

• 国兴资产是“处理旧账”的，做资产的“清道夫”和“修理工”。
• 江西国控是“总账房”和“操盘手”，管着最大的资本盘子，进行战略性投资。
• 江投集团是“基础建设者”，负责能源、交通等“硬”基础设施。
• 省农发集团是“现代农业领军者”，负责农业这个“软”的基础产业。

“高风险、低收益”的城投平台 → 丢给省投，作为投融资职能的一部分。省投更像一个 债务池 + 基建融资工具。基建融资平台，承接大量城投公司，风险偏高，功能性强。
“高收益、低风险”的垄断企业 → 放到省国控，作为财政收入和资本运作的抓手。省国控是 利润中心 + 股权运作平台。持股运营优质垄断企业，收益稳定，是财政的现金牛。

三、为什么要这么划分？

逻辑上是为了适应 “管企业”向“管资本”转型，避免“大杂烩式国企”。主要出于三个考虑：

1. 职能分化

   • 国兴：历史遗留、剥离资产的“兜底公司”。
   • 国控：管股权、资本运作。
   • 投资集团：投重大基建。
   • 农发集团：管农业涉农业务。

2. 历史沿革

1). 早期的“散、小、弱”阶段（2013年以前）：
在过去，省属国企数量众多，业务重叠交叉，“大而不强”的问题突出。很多企业主业不清晰，什么赚钱就做什么，导致同质化竞争严重，资源配置效率低下。

2). 新一轮国企改革启动（2013年至今）：
国家层面启动了以“管资本”为主的新一轮国企改革。核心思想是：国资委从“管人、管事、管资产”转变为主要“管资本”，通过组建国有资本投资、运营公司（两类公司）作为中间层，来具体履行出资人职责，管理旗下的实体企业。

• 江西国控的升级（2020-2022年）：这是最关键的一步。江西省委省政府决定打造一个属于江西的“万亿级”国有资本运营平台。通过将江西铜业集团、新钢集团等多家大型工业企业的股权划转至江西国控，使其资产规模急剧膨胀，成为省属国企的“航母舰队”。其目的是增强省级国资的融资能力、资源配置能力和市场竞争力，更好地服务全省经济发展战略。

3). 专业化整合浪潮：
“让专业的公司做专业的事”成为共识。为了避免业务混杂，开始按照产业板块进行大刀阔斧的重组。

• 江投集团的重组：原本江投集团业务也较多，后来通过改革，将其非能源主业的业务（如房地产等）剥离，使其更加专注于能源和基础设施核心主业。
• 省农发集团的新建（2022年）：这是最新的一次专业化整合。江西是农业大省，但缺乏一个大型农业领域的龙头企业。因此，省农发集团是“无中生有”、全新组建的。它整合了省内多个涉农企业和资源（例如从江投集团划转了江西省粮油集团有限公司，从其他单位整合了种业、农机等资源），旨在打造一个贯穿农业全产业链的综合性集团，引领江西农业现代化发展。

4). 处理历史遗留问题——国兴资产的使命：
在各大集团聚焦主业的过程中，必然会剥离出大量的非主业资产和低效无效资产。谁来接手？这就是国兴资产管理公司成立的核心目的。它类似于一个“资产池”，承接这些资产后，通过专业化手段进行清理、整合、盘活或退出，为其他主业集团“减负”，从而优化全省国有资本的总体质量。

• 江西曾有大量“条条块块”的行业公司（比如省电力、省粮食、省供销、省地矿）。
• 改制后不可能全并成一个大集团，就形成了几个“专业板块型”的集团。

3. 对标中央做法

   • 中央有国新控股（资产管理）、诚通控股（资本运营）、中投/国投（重大投资）、中粮/中储粮（农业粮食）。

     

   • 江西这几个集团，基本上是地方版的对应关系。

   但是“两桶油”、三大电信、电网、航运、军工等是由国务院国资委直接管理全国性的大型垄断性企业。
   这些企业通常是 战略性行业、关系国计民生，而且规模极大，单个集团的总资产可能就超过一个省的全部省属国企，所以保持“国资委—央企集团”的直管模式。

   

四、子公司众多的原因

• 历史包袱：很多子公司是计划经济时代遗留的厂矿、科研所。
• 投资扩张：集团化改革后，为了做产业链布局，设立了大量二级、三级子公司。
• 政策任务：比如粮食储备公司、电力项目公司，往往“一项目一公司”。

总而言之，这个划分格局：

• 是历史演进的结果：从过去的分散混乱，到今天的清晰分类。
• 是顶层设计的产物：积极响应中央关于国企改革的号召，构建“国资委—国有资本投资/运营公司—实体企业”的三层监管架构。
• 是江西发展的需要：通过打造江西国控这个超级平台来增强实力，通过组建省农发集团来抓住农业这个省之根本，通过专业化整合让江投等集团更高效，并通过国兴资产来处理改革中的历史包袱。

总结一句话：江西省国资委下属这些集团的划分逻辑，是在国企改革“管资本”大背景下，参照中央和其他省份模式，把原先分散在各厅局和行业公司的资产，分别整合到“资产处置平台、资本运营平台、投资平台、农业平台”四大块，以实现功能分工明确、提高国资监管效率。

你有没有想过AI到底是怎样推理的？这篇文章将带领读者钻进AI的大脑，把它的思考过程一层一层的剥开，让你彻底的搞明白它的那些惊艳的答案到底是通过严密的推理一步一步推导出来的，还是像复读机一样从它以前背过的内容里抄过来的。

这篇文章的内容来自于谷歌DeepMind团队的首席科学家Denny Zhou在斯坦福大学CS25 《Transformers United V5》课程中的讲座。相信通过这篇文章的讲解，你将对AI的理解和使用方式都会发生根本性的改变，你会彻底搞懂为什么AI会一本正经的胡说八道，你会发现其实AI根本没有你想象的那么聪明，但是也没有你想象的那么笨。

首先我们从AI的这个出厂设置说起。其实一个最基础的AI大模型，它的逻辑非常简单，它读过全球几乎所有的书和网站，当你问他的时候，他就会根据读过的资料来连续的预测下一个可能出现的字。就跟很多人说为什么AI不能一次性地把答案输出，非要一个字一个字地去吐，以前还有人跟我说，这是特效，其实不是的。

比如你说“天空是”，它就会从亿万份的资料里面去统计，发现“蓝”这个字跟在后面的概率最高，然后它就会输出“蓝”；接着AI又会把“天空是蓝”作为一个整体重复上面的预测过程，就会发现“色”这个字出现的概率最高，他就继续输出“色”，所以这就有了“天空是蓝色”。

这个机制有个名字叫“贪婪解码”。为什么叫“贪婪”，因为它只顾眼前，这就是为什么早期的AI经常是一本正经的胡说八道。比如你问AI一个脑筋急转弯：汤姆的妈妈有三个儿子，老大叫大毛，老二叫二毛，那老三叫什么？它很可能就会回答你三毛。为什么呢？因为“大毛二毛三毛”在它读过的数据里出现的概率太高了，它就直接“贪”了这个最省事的回答，它不会考虑问题里的关键信息就是“汤姆的妈妈”。

那怎么解决这个“贪婪”的问题，那后来科学家就发现了一个点石成金的提示词咒语——“一步一步想”。这个提示词真的很神奇，为什么我们在技术上不做任何的优化和调整，就只是给AI加上这么一句话，AI的正确率就能大大提升。其实很简单，你加上这句话就相当于强行给他塞了一张草稿纸，并且改变了他要做的任务，那他的任务就不再是直接去预测“汤姆”这个最终的答案，而是变成先预测解题过程中的第一句话，然后在预测第二句话，最后再到解题的结果。虽然表面上还是在预测下一个字，但是实际上他是在预测解题的过程，所以他会从读过的大量的问题里找到相似的解题过程套用过来。比如说他会生成这样的草稿：问题是汤姆妈妈第三个儿子的名字，题目里已经明确提到了汤姆的妈妈，并且提到了两个儿子大毛和二毛，根据人类的语言习惯，汤姆就是他妈妈的儿子，所以第三个儿子就是汤姆。当他把这个完整的逻辑链条以文字的形式一步一步的生成出来之后，汤姆这个正确答案就形成了这个链条末端最高概率的那个词。

所以你看，所谓的AI推理本质上就是在生成最终的答案之前，先生成一串作为草稿的中间步骤，这个草稿打的越长越详细逻辑越严密，那么最终结果就越靠谱。我们并没有给AI装上一个新大脑，只是用一个聪明的指令，逼着他把恐怖的算力用在了打草稿这个正确的事情上面。这个“一步一步想”的提示词也被叫做CoT（Chain of Thought 思维链）

那么下一个问题就来了，我们不能每次都在AI的屁股后面提醒他吧。那怎么把它从一个需要去监督的学生，训练成天生就懂推理的大师呢？这就引入了AI推理能力的进化三部曲。

其实这个三部曲很有意思，第一步就是“题海战术”，我们可以雇佣成千上万的人类专家，手写出无数道完美的解题草稿，然后再把这些标准答案一股脑地全部喂给AI，让他去死记硬背，他就像是一个刷题无数的学生，考卷里的所有题型，他都见过，那自然就能考出好成绩，但是如果稍微换一个问法，他马上就抓瞎了，因为他学到的是题，而不是方法，这个学名就叫做“监督微调”。

第二个阶段呢就是“自我博弈”。那档次就完全不一样了，我们不需要再喂给AI标准答案，而是让AI自己天马行空用各种你想的到想不到的方法去解题，就相当于是让他随便去试。然后这里边就生成了大量的无数的千奇百怪的草稿。然后我们再给他一个判断这个答案是正确还是错误的程序，如果你答对了，我就给这个学生AI的这个解题路径一个大大的奖励。如果你答错了，我就给它一个惩罚，它在经历了几亿万次的自我的试错和奖惩之后，这个学生AI他自己就悟了。他不再是模仿人类，而是真正从这个底层的规律上面就掌握了到底什么才是通往正确答案的最优雅最高效的推理路径。这就是常说的“强化学习”。

但是这还不够，一个大师也有偶尔失手的时候，所以第三个阶段叫做“集体智慧”，我们可以给AI 99个分身，让他的这个回答增加一点随机性，把同一个问题用不同的思路独立的去算100遍，然后我们把100个答案放在一起公开投票，哪一个答案出现的次数最多，那我们就采信哪一个。这就是用最朴素的统计学原理把这个偶然犯错的可能性降到了最低。这叫“自洽性投票”。

一个顶尖AI的思考能力，其实就是这么一步步进化过来的，从一个只会联想的超级输入法进化成一个被逼着打草稿的普通学生，然后再进化成一个自我博弈的学霸宗师，最终进化成由100个宗师分身组成的学术委员会。

所以回到这个最根本的问题。AI到底是在推理还是在背答案，Denny Zhou就说，我们不要拘泥于这个定义，AI就是在检索中推理，在推理中检索。明白了这一点，我们就可以让AI的效果超越90%的人，那么这里就教大家非常有用的三招。

比如你在解决一个几何题。如果你直接去问，AI有可能会答错，但是如果你在提示词里加上一句话：“回忆相关的问题”，然后再去解决这个问题，那模型他可能会去先回忆检索出来一个关于计算两点之间距离的公式，然后在利用这个知识成功解决当前的面积计算的问题。其实我们在解决复杂问题的时候，可以先去引导模型后退一步，先去思考解决这一类问题所需要的一般性的原则，或者抽象的概念，然后再把这些原则用在这个具体的问题里面。

第二招是“步骤分解法”，你要像一个项目经理一样，主动的把你的任务给拆解掉，你主动帮他搭好一个思考的架子，它就能够通过检索的这种方式在你的这个框架里面填出一个最完美的内容。比如你不要去说给我做一个云南的旅游攻略，而是要说我们来规划一个为期7天的云南家庭游。第一步请列出适合家庭游的三个核心城市及理由，第二步为我们规划每一天的详细行程，包括景点和交通，第三步估算一下人均的预算。这个方法其实特别适合于没有深度思考能力的模型。

第三招是“自我审查法”，我们没办法直接用AI的百人投票，但是我们可以让AI自己检查自己，你得到一个答案之后，你不要先着急采纳，你可以去追问AI说，你确定吗，你重新审视一下你的答案，找出其中可能存在的3个逻辑漏洞。这招相当于是让AI自己跟自己打架，他立刻就会启动更深度的思考，去检查和修正之前的一些答案，准确率会再上一个台阶。

所以看懂了这些你就会发现AI虽然不是一个有感情的人，但是他可以被精确的引导，被严格的塑造，它是一个究极的逻辑机器。所以未来真正能够拉开人与人差距的，不是你掌握了多少知识，而是你能不能设计出一个高明的问题，一个明妙的指令，去帮助这个地球上最强的外挂，帮你一步一步的想出颠覆整个牌桌的答案。

按照马克思的理论，生产力的三要素：劳动者，劳动资料和劳动对象。劳动者从原始社会到现在都没有发生过根本性的改变，我们还是使用原始人的身躯。
那从劳动资料和劳动对象两个角度分析生产资料在历史上的变化。在数字化智能化的时代，如何获取生产资料。

下面我将按照马克思主义政治经济学的理论，从劳动资料和劳动对象的演变进行分析，并最终探讨在数字化智能化时代如何获取生产资料。

第一部分：从历史角度分析生产资料的变化

从生物学角度看，劳动者的“身躯”并未发生根本性改变。人类生产力的巨大飞跃，主要驱动力量正是劳动资料（特别是生产工具）和劳动对象的深刻革命。

1. 劳动资料的演变（人类如何改造自然）

劳动资料是劳动者用来作用于劳动对象的物或物的综合体，其中生产工具是最具决定性的因素。它的演变历史就是人类生产力发展的刻度尺。

• 原始社会：

  • 劳动资料： 简陋的石器（石斧、石刀）、木棒、骨器等。这些是自然物的简单加工品，极大地依赖劳动者的自身体力。
  • 特点： 劳动资料是对自然物的直接利用，延伸了人的肢体，但能力和效率极其有限。

• 农业社会：

  • 劳动资料： 金属工具（铜器、铁器）的出现是革命性的。犁、锄头、镰刀、畜力（牛、马）的使用，以及水车、风车等简单机械。
  • 特点： 人类开始利用金属材料和驯化畜力，实现了从“采集”到“耕作”的革命，劳动资料成为了系统化开发土地资源的前提。

• 工业社会：

  • 劳动资料： 蒸汽机的发明是里程碑。此后，机床、内燃机、电动机、自动化生产线等机械系统成为主导。劳动资料从代替人的体力（工具机）发展到代替人的能量（动力机）。
  • 特点： 劳动资料实现了机械化、自动化，构成了庞大的机器体系。劳动者从“使用工具”变为“服侍机器”，生产资料（机器）成为资本占有并支配劳动的关键。

• 信息社会/自动化社会：

  • 劳动资料： 计算机、工业机器人、数控机床、通信网络（互联网）。这些工具开始替代人的部分脑力劳动，如计算、控制、记忆等。
  • 特点： 劳动资料实现了信息化和初步智能化，生产效率和对全球资源的调配能力空前提高。

2. 劳动对象的演变（人类改造什么）

劳动对象是劳动加工所作用于其上的一切东西。它的扩展意味着人类对自然界和自身创造物的利用广度和深度的增加。

• 原始社会：

  • 劳动对象： 天然的自然资源，如野兽、野果、鱼类、现成的石块、树木等。
  • 特点： 完全是自然界直接提供的“现成物”。
  • 生产资料占有方式：共同占有。由于个人无法单独对抗自然，必须集体劳动。
  • 生产关系：原始公有制。人们共同生产，平均分配，没有剩余产品，因此没有阶级和剥削。

• 农业社会：

  • 劳动对象： 土地、驯化的动植物（农作物、家畜）、以及经过初级加工的材料（丝绸、毛皮、陶土、矿石）。
  • 特点： 劳动对象从“现成自然物”扩展到“人工培育的自然物”，开始了对自然界的深度干预和改造。
  • 生产资料占有方式：私人占有。奴隶主占有土地和奴隶本身；封建主占有土地，农民（或农奴）依附于土地。
  • 生产关系：
    • 奴隶制：奴隶主占有全部生产资料和奴隶劳动成果，奴隶自身也属于生产资料。
    • 封建制：地主占有土地，农民租种土地并向地主缴纳地租（劳役、实物或货币）。生产关系表现为人身依附关系。

• 工业社会：

  • 劳动对象： 深度加工的原材料成为主体，如钢铁、水泥、石油、化工原料、橡胶等。此外，电能成为一种前所未有的、非实体的劳动对象（被转换、传输、利用）。
  • 特点： 劳动对象绝大部分不再是自然直接赐予的形态，而是人类工业活动的产物（“人造物”），人类进入了“加工材料的时代”。
  • 生产资料占有方式：高度集中的私人资本占有。资本家拥有工厂、机器、原料等一切生产资料。
  • 生产关系：雇佣关系。无产阶级（工人）被剥夺了生产资料，为了生存，只能向资本家出卖自己的劳动力。资本家支付工资，并占有工人创造的剩余价值。这种关系掩盖了剥削，形式上看似“自由”、“平等”。

• 信息社会/自动化社会：

  • 劳动对象： 出现了一种新的、非实体的劳动对象——信息（数据）。代码、程序、算法、知识产权等都成为被加工、处理和创造的核心对象。
  • 特点： 劳动对象实现了从实体化到虚拟化的重大飞跃。对数据的加工和处理，创造出巨大的价值。
  • 生产资料占有方式：依然由资本主导，但出现了新形态。平台公司（如Google, Facebook, 亚马逊）占有关键生产资料——数据、平台、算法和网络效应。
  • 生产关系：雇佣关系依然主体，但形式更加灵活和隐蔽（如零工经济、平台用工）。数据剥削成为新特征：用户无偿提供数据（劳动对象），平台通过算法（劳动资料）将其转化为有价值的产品并进行垄断。

第二部分：数字化智能化时代如何获取生产资料

数字化智能化时代是信息社会的深化和高级阶段，其核心特征是数据成为关键生产要素，人工智能成为核心生产工具。这使得生产资料的获取方式发生了颠覆性变化。

1. 劳动资料的获取：从“拥有”到“接入”

传统的工业时代，获取强大的劳动资料（如一条自动化生产线）意味着巨大的资本投入。而在数字化时代，获取最先进的劳动资料的方式变得前所未有的民主化和轻资产化。

• 云计算与算力（新型动力机）： 您不再需要购买和维护庞大的服务器集群。像AWS、Azure、阿里云这样的云服务商，让您可以通过网络按需租用世界顶级的计算能力（CPU、GPU、TPU）。获取生产资料（算力）的方式从“购买产权”变成了“购买服务”。
• 软件与算法（新型工具机）： 许多核心的生产工具是软件。企业无需从零开发，可以通过：
  • 开源社区（Open Source）： 免费获取和使用世界上最优秀的软件、框架和库（如Linux, Apache, TensorFlow, PyTorch）。这是集体智慧共创共享的模式。
  • SaaS（软件即服务）： 订阅使用各类专业软件服务（如CRM、设计软件、管理工具），无需购买和安装。
• 平台与生态： 对于创业者和小微企业，可以直接接入大型平台（如微信、抖音、Shopify、Amazon AWS）提供的开发工具、流量和支付系统。这些平台本身就是一个庞大的、现成的“数字劳动资料综合体”。

结论： 在智能化时代，获取劳动资料的核心不再是资本规模的竞争，而是知识、创意和连接能力的竞争。你可以用很少的初始资本，通过接入云端、使用开源工具和平台服务，获得与大型企业相近的生产能力。

2. 劳动对象的获取：数据成为“新石油”

在智能化时代，最核心的劳动对象是数据。如何获取、清洗、标注和处理数据，成为了价值创造的关键。

• 数据的获取途径：
  • 用户产生： 通过提供免费的数字服务（搜索、社交、娱乐、工具）来获取用户的行为数据。这是互联网平台公司的核心模式。“如果你免费，那你就是商品”（你的数据是产品）。
  • 传感器采集（IoT物联网）： 通过部署物理世界的传感器，从工业设备、汽车、家电、城市基础设施中持续采集海量数据。
  • 公共数据： 政府和企业开放的各类公共数据集（开放数据运动）。
  • 合成数据： 利用AI技术自行生成和模拟数据，用于训练AI模型，尤其在真实数据稀缺或敏感的领域。
  • 数据购买与交换： 从数据市场或第三方数据经纪公司购买所需的数据。

重要变化：

• 非竞争性： 数据作为一种劳动对象，具有非竞争性。我使用一组数据训练AI，并不妨碍你同时使用同一组数据。这与传统的土地、石油等竞争性生产资料有本质区别。
• 价值源于处理： 原始数据的价值有限，其巨大价值需要通过算法（劳动资料）进行加工、分析和建模后才能释放。数据与AI算法结合，才能成为真正的生产资料。

总结

从马克思主义的视角看，数字化智能化时代的生产资料变革是历史性的：

1. 劳动资料的形态从庞大的实体机器变为无形的算法、软件和云端算力。其获取方式从依赖巨额资本的“所有权”模式，转向更灵活的“接入权”和“服务订阅”模式，极大地降低了创造活动的门槛。
2. 劳动对象的范围从实体物质扩展到虚拟的数据。数据作为一种非竞争性的新资源，其获取依赖于提供数字服务、部署物联网和利用数据市场，其价值通过智能算法的“劳动”来实现。

最终，这个时代的核心矛盾也在演变：生产资料（数据、算法、平台）的私人占有与社会化生产之间的矛盾以新的形式出现。谁掌握了核心数据和海量算力，谁就掌握了这个时代最关键的生产资料，从而在生产和分配中占据主导地位。如何让这些数字生产资料更好地服务于社会整体，而不是被少数巨头垄断，是当今时代面临的全新课题。

这可能是对于大语言模型（LLM）原理最清晰、易懂的解读。

前段时间，Google DeepMind 的首席科学家兼研究总监 Denny Zhou 在斯坦福大学课程中，分享了大语言模型推理的深刻洞见。

作为人工智能领域的领军人物，Denny Zhou 通过这场讲座对 LLM 推理机制及其优化方法进行了系统阐述，揭示了大模型推理的核心原理和最新进展。

Denny Zhou 总结了四个关键点：

• LLM 中的推理仅仅意味着在得出最终答案之前生成一系列中间 token，这是否与人类推理相似并不重要，关键在于，Transformer 模型通过生成许多中间 token，可以变得极其强大，而无需扩展模型的大小。
• 预训练模型即使未经任何微调，也具备推理能力。挑战在于，基于推理的输出往往不会出现在输出分布的顶部，因此标准贪婪解码无法将它们呈现出来。* 提示技巧（例如思维链提示或「让我们一步一步思考」）和监督式微调曾是引发推理的常用方法，现在强化学习微调已成为最强大的方法，这一技巧被多个实验室独立发现。在谷歌，这要归功于团队成员 Jonathan Lai，基于理论，扩展强化学习应该专注于生成长响应，而不是其他目标。
• 通过生成多个响应然后将它们聚合起来，而不是依赖于单个响应，可以极大地提高 LLM 推理能力。

Denny Zhou 不仅是 Google DeepMind 的顶尖科学家，还曾在 Google Brain 创立并领导了推理团队（Reasoning Team），现在该团队是 DeepMind 的一部分，专注于开发具备推理能力的大语言模型，以推动人工智能通用智能的发展。

他的研究聚焦于链式思考提示（chain-of-thought prompting）、自一致性（self-consistency）和 LLM 优化等领域，在 Google Scholar 上累计获得超过 83,000 次引用，对机器学习和 AI 领域贡献显著。

此外，他还共同创办了语言建模大会（CoLM），并担任 2024 年大会的总主席，曾荣获 2022 年 Google Research Tech Impact Award 和 WSDM Test of Time Award，并在 KDD 2023 等活动中发表主题演讲。他常在斯坦福、哈佛等大学进行邀请讲座，分享关于 LLM 的观点。

他参与教学的 CS25 《Transformers United V5》课程，目前已是斯坦福大学最热门、最具研讨性的课程之一，汇聚了 Geoffrey Hinton、Ashish Vaswani 和 Andrej Karpathy 等我们耳熟能详的 AI 顶尖研究人员。该课程在斯坦福大学内外都广受欢迎，YouTube 上的观看次数更是高达数百万。每个星期，人们在课上都会深入探讨人工智能领域的最新突破，从 GPT 等大型语言模型到艺术、生物和机器人领域的应用。

课程页面：https://web.stanford.edu/class/cs25/

接下来，让我们看看 AI 领域的顶级学者是如何解读大模型「推理」这一至关重要的能力的。

如今，很多人都已经相信大语言模型（LLM）是可以推理的了。实际上，我们还不知道这是否成立，这可能取决于对推理的定义。在这里，我们认为推理是输入问题 - 输出答案之间的中间步骤（生成的 token）。

LLM 中的推理仅仅意味着在得出最终答案之前生成一系列中间 token，这是否类似于人类的推理并不重要，关键在于，Transformer 模型可以通过生成大量中间 token 而变得几乎任意强大，而无需扩展模型大小。

为什么中间 token 在推理中至关重要？

Denny 认为，在推理中 中间 token 的作用至关重要。他与斯坦福大学的 Tayma 教授及其学生合作，提出了一个理论：任何可以通过布尔电路解决的问题，都可以通过生成中间 token 来用恒定大小的 transformer 模型解决。

这个理论表明，逻辑电路的大小（即电路中逻辑门的数量）决定了解决问题的能力。比如，使用 GPU 集群时，逻辑门的数量可能达到数千万、数十亿甚至数万亿。如果直接生成最终答案，可能需要极深的模型结构，甚至无法解决问题。而通过生成中间 token，模型就能以恒定大小的 transformer 架构有效地解决问题。这种思路提供了一种从理论角度理解推理的方式。

推理过程的技术细节

关于推理的一个常见看法是，语言模型不能推理，除非进行进一步的提示工程，比如安全提示或候选答案的微调，我同意这个观点。我们可以简单地认为，语言模型已经具备了推理能力，关键在于解码过程。

举个例子。这道简单的数学问题：「我有 3 个苹果，我爸爸比我多 2 个苹果。我们一共有多少个苹果？」如果你使用任何预训练模型，比如 Llama、DeepSeek 或 Qwen，直接输入这个问题，模型可能会输出「5 个苹果」，这是错误的。

这是因为使用了「贪婪解码」方法，模型直接输出最可能的答案。

贪婪解码（Greedy Decoding）通常出现在机器翻译、文本生成（如GPT）、语音识别等序列生成任务中，是一种最简单的解码策略。

核心思想就是：
在生成序列的过程中，模型在每一步都会输出一个概率分布（softmax 后的 token 概率）。贪婪解码就是每一步都选择概率最大的那个 token，然后把它作为当前步的输出，并继续输入到下一步，直到遇到终止符（如 <eos>）或者达到最大长度。

但是，如果我们多考虑一些候选答案，而不是只选择一个最可能的候选答案，模型就能产生一个更正确的答案，这就是「链式推理解码」的概念。

链式推理 (Chain-of-Thought, CoT) 的核心思想是：
在生成答案时，让模型 显式地输出推理步骤，而不是直接给出最终结果。

而 链式推理解码 指的就是在推理型任务（比如数学题、逻辑题、多跳问答）中，通过 在解码时引导模型输出逐步推理链条，从而提升正确率。

它包含两个步骤：第一步，超越贪婪解码，检查更多的生成候选；第二步，选择那些最终答案置信度更高的候选。

链式推理解码是一个非常简单的方法，但它需要一些程序设计工作。我们还可以尝试其他方法，如通过简单的自然语言提示，直接指导模型进行链式推理，这就是「链式思维提示」奏效的原因。通过这种方法，我们可以使推理过程自然地出现在输出空间中，而不需要复杂的计算步骤。

这些提示方法确实非常简单，而且效果也非常好，但我们也能看到一些问题，例如安全提示方法就需要任务特定的示例。而另一个方法叫做「逐步思考」，它是一个通用的方法。你不需要找到类似的示例，只需说「让我们一步步思考」，然后奇迹般的结果就会出现。不过，它的表现比少量示例的提示差得多。

虽然这两种方法看起来都不错，但「逐步思考」方法有些怪。如果我问某人一个问题，然后要求他们跟我一步步思考，否则他们就无法继续思考，这显然不符合我们的期望。

现在有一种流行的方法：监督微调（SFT）。

实际上思路非常简单，我们可以从人工标注者那里收集一系列问题及其逐步解决的方案，然后我们最大化人类解决方案的可能性，标记一些实际上用于 LLM 训练的网络代码。在那之后，我们就可以在任何地方应用这个模型。Denny Zhou 等人在 2017 年的一系列研究中展示了这种能力，他们收集了大量文字问题及人工标注的解决方法。在 2021 年，这一方法被用来解决大规模问题，随后 OpenAI 扩展了这一方法。

这是简单的工作原理示意：用一系列例子、问题和答案微调你的模型，然后就可以在新的问题上进行测试了。比如这里就是众多大模型难以回答的 strawberry 单词里有多少个 r 的问题。很多人一度认为这个问题是用于测试 AGI 是否出现的「重大问题」。

SFT 实际上是一个通用的方法，如果这就能解决 AI 的推理问题，那事情就太简单了，然而它的泛化能力是有限的。DeepMind 在 2021 年夏天意识到了这个问题，怎么办？只有 Scaling,Scaling,Scaling，找到更多数据来进行训练，看看效果如何。

但这里有个教训，不要盲目扩展规模，方向错了就什么也得不到。

如何解决 SFT 泛化失败的问题？有两个重要方面，首先是解决人类标注错误的问题。实际上谷歌一个发明 finetuning 研究的成员曾表示，他们发现机器生成的数据可能还要优于人类构建的数据。这是个有点反直觉的经验。

让 AI 实现自我提升

所以第一波尝试被称作自我提升，与其从人类那里生成、收集数据，我们可以直接让模型生成数据。所以收集问题的数据集，你的模型要逐步生成解决方案，然后再次最大化正确答案的可能性。

比如一个数学问题，你有问题和答案，让大模型生成解决问题的步骤，依据是否获得正确答案来选择正确的步骤。这就是 Reject Sampling，这里唯一的区别在于数据来自于你的模型，而非人类。

该研究的论文即《STaR: Bootstrapping Reasoning With Reasoning》，其本意是减少昂贵的人工标注成本。但从另一个角度来理解，一旦更好的模型生成了响应或训练数据，模型就可以自我改进。

模型获得了改进之后，又该从哪里收集数据呢？我们可以重复这个过程。

我们注意到字节跳动研究人员在 2024 年 1 月发在 arXiv 上的《ReFT: Reasoning with Reinforced Fine-Tuning》，这可能是 RL finetuning 的最早的学术出版物。甚至论文标题都叫做《基于强化调优的推理》。随后，在 OpenAI 的 o1 公开之后，每个人都开始意识到要使用强化学习微调了。

可能有很多研究团队独立意识到了这个方向。

强化学习先驱 Rich Sutton 在《Verification, the key to AI》中曾提到，在 RL 微调中，可靠的验证器是最关键的，而非 RL 算法。

那么问题来了，除了效率问题以外，为什么机器生成的训练数据反而比人类的更好？

这与机器学习中的第一性原理相关，即直接优化我们想要的东西。如果我们想构建一个用于推理的模型，或者只是一般地用于生成有趣的内容，我们就需要优化衡量生成质量的指标。一旦你有了一个度量标准，我们所需要做的就是计算该度量标准的梯度并进行反向传播。

因此，假设模型是一个先验的模型，我们需要最大化该指标的期望值。那么该怎么做呢？我们需要进行采样来计算期望值，这就是你得到策略梯度的原因。

这里没有魔法（比如如何激励你的模型进行同步，激活多个位置），不需要那些词汇，这里只使用标准的机器学习术语，定义你的指标，计算梯度并进行反向传播。

现在，这个方法运行良好，那么就该 Scaling 了。朝哪个方向扩展呢？粗略地考虑，似乎随着 COT 的增长，一个模型可以解决所有的问题，这都不需要模型尺寸的增长，只需要最小的固定大小的迁移模型，这样也没关系。

所以你如果查阅早期文献会发现，人们认为 RL finetuning 效果好于 SFT。

这里不得不说到 LLM 推理的美妙之处了。这个类似于人类的推理过程源自逐个 token 的预测，而非像传统 AI 那样依赖搜索排序。

举个例子，2024 年 12 月，谷歌发布了 Gemini 2.0 思考模式，这里尝试了一个训练集里没有的问题。使用 1 到 10 的数字来组成 2025，并且明智地使用每个数字以及加法和乘法这两种基本运算。

右边可以看到 Gemini 2.0 的思考过程，让我们看看模型是如何进行思考的。这不是通过搜索。你可以看到，在一开始，模型就表示这是一个相对较大的数字，这表明乘法运算将大量涉及。这就像人类思考一样。值得注意的是，2025 是 45 的平方，即 45 乘以 45。接着模型开始思考如何得到中间产物，使用乘法……

这就是模型训练如此强大的原因。

再次引用 Rich Sutton 在《苦涩的教训》中的话：Scaling 的发现只会让我们更难看清发现过程是如何完成的。

看起来，Sutton 在看到 DeepMind 的 AlphaGo 和 AlphaZero 的成功之后，写出了《苦涩的教训》。真正可扩展的只有两个过程，一个是学习，另一个是搜索。在这里我只想强调一件事。学习是可扩展的，我们只需要学习。

RL finetuning 的优势在于它的泛化很好，但并不是所有任务都是可以由机器自己进行验证的，比如写作，甚至代码编程。

我们必须牢记，LLM 是进行预测的模型，他们不是人类。

从数学角度来看，这意味着什么？我们来思考一下 LLM 的解码过程。给定问题和生成器推理，然后输出最终答案，接着是通过网格解码关键找到的响应，那么关键点就是匹配概率。

对我们来说，需要选择概率最大的答案。所以它们没有对齐，我们只需要再进一步。如果我们生成推理过程，我们应该有一些整体推理过程来找出最终答案在机器学习方面的概率，这被称为边缘化。所有这些原因实际上本质上都只是潜在变量。如果我们刚开始接触机器学习，实际上就会知道这个和可以通过采样来计算。

因此，通过随机抽样生成多个响应，然后选择出现频率最高的答案。我们不看推理通过率，它只选择最常见的答案，而不是最常见的任务通过率。这就是诀窍。这在实证中被称为边缘化。如果你采用这种方法，就会看到巨大的改进。

另一种方法是检索。我知道关于检索推理有很多辩论，很多人说语言模型可能只是做检索而不是推理，对我来说，实际上总是很难区分检索和推理。

我每年都会参加几乎每一场会议，每次我们都会讨论每篇论文的新颖性。其实，检索和推理的辩论就像是类似的争论。我看到过一个实验，尝试不同的模型并行运行，这样做可能会让结果更混乱。比如，使用 4 个不同的模型回答同一个问题，最后再对比答案，挑选出最一致的结果。

如果从不同模型中生成回答，这更像是一种「模型组合」（model assembly）方法，通过多个模型的输出进行对比，选择一个最佳答案，类似于随机选择。虽然数学原理不完全相同，但它们的实现方式是类似的。

关于检索和推理的争论，我个人并不太关注。我在工业界工作，更关注的是实际性能。对我来说，如果检索能够获得 A + 级的答案，那为什么还要争论是否属于推理呢？所以，2024 年我们发布了一篇关于类比推理的论文。我可以用一个小例子来展示检索在推理中的重要性。

考虑这样一个问题：一个正方形的四个顶点的坐标是…… 那么它的面积是多少？这个红色高亮部分是我添加的提示：「回忆一个相关的问题，然后解决这个问题。」

当时，我尝试了 GPT 3.5 和我们自己的模型，但它们在没有提示的情况下无法解答这个问题。然而，添加了相关问题的提示后，模型就能解决这个问题了。

发生了什么呢？当我告诉模型回忆相关问题时，模型找到了一个相关但不同的问题。其实，这是一个与当前问题相关的问题，涉及计算坐标平面上两点之间的距离，并给出了公式。然后，模型说：「哦，我现在知道如何计算距离了，接着我就可以计算面积。」这个例子展示了检索在推理中的重要性。

另一个例子是「后退一步」的方法。在解决问题之前，我们给模型提供了一些简短的例子，让它理解如何抽象化思考。例如，在解决实际问题之前，我们可以让模型「后退一步」，思考更抽象的原则，然后再应用到实际问题中。这就是检索在推理中的作用。

我想现在大家都明白，深度学习研究（Deep Research）团队的理念也与此类似。我们有一个叫做「深度研究」的团队，其中一位负责人曾是我的实习生。后来，他加入了 OPI 并发明了「深度研究」方法。你们看到的区别就在于，他们通过检索相关问题或知识，帮助解决实际问题，基本思路其实非常简单。

最后，Denny Zhou 进行了总结：其实大家不必再纠结 AMS 是否能够推理，至少在语言模型中，推理总是比没有推理更好，Alpha 微调比 SFT（监督微调）更好，聚合多个答案比只选一个答案更好，当然，这会更昂贵。而检索和推理的结合比单纯的推理要好得多。

对于未来的突破，Denny Zhou 表示，他非常期待看到如何解决那些超出唯一、可验证答案的任务。他认为，基准测试很快会趋于饱和，更多的研究应该集中在构建真正的应用程序上，而不仅仅是解决学术性基准测试问题。

Denny Zhou 引用了 Richard Feynman 的名言：「真理总是比你想象的更简单。」他强调，这句话对于机器学习研究尤其适用。很多学术论文过于复杂，但实际上，我们的研究可以保持简洁明了。

参考链接：

• https://dennyzhou.github.io/LLM-Reasoning-Stanford-CS-25.pdf
• https://www.youtube.com/watch?v=ebnX5Ur1hBk&amp
• https://x.com/denny_zhou/status/1948499173986201915
• https://zhuanlan.zhihu.com/p/1940422869269087692

OpenObserve是目前用过的性能最好的观测性平台，底层基于Rust写的，采用的是parquet列式存储，数据压缩效率极高，单机版的性能就已经超过很多市面上其他技术了。

观测性数据属于时序数据范畴，所以OpenObserve和大多数时序数据库一样使用的是LSM-Tree的存储数据结构。这就导致数据并发采集量过大的时候，经常出现MemoryTableOverflowError的问题。

1
2
3
4
5
6
7
8
9
10
11
12
13

2025-06-18T07:40:22.074188063+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:22.074317749+00:00 INFO actix_web::middleware::logger: 10.233.71.119 "POST /api/default/v1/traces HTTP/1.1" 503 74 "1706" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000299    
2025-06-18T07:40:22.449896048+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:22.450004619+00:00 INFO actix_web::middleware::logger: 10.233.80.211 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2230" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000270    
2025-06-18T07:40:22.517553812+00:00 INFO actix_web::middleware::logger: 10.233.71.0 "POST /api/default/v1/metrics HTTP/1.0" 503 74 "3826" "-" "OpenTelemetry Collector Contrib/0.111.0 (linux/amd64)" 0.000867    
2025-06-18T07:40:23.572270669+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:23.572416843+00:00 INFO actix_web::middleware::logger: 10.233.71.1 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2278" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000371    
2025-06-18T07:40:23.657375098+00:00 INFO actix_web::middleware::logger: 10.233.71.247 "POST /api/default/v1/metrics HTTP/1.1" 503 74 "20634" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000578    
2025-06-18T07:40:23.803923763+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:24.635078516+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:24.635189325+00:00 INFO actix_web::middleware::logger: 10.233.71.223 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2162" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000268    
2025-06-18T07:40:25.119413710+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:25.120251549+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError

所以不得不迁移到集群版的OpenObserve。

OpenObserve高可用架构中分以下几个角色：

• Router、Querier、Ingester、Compactor 和 AlertManager 节点都可以水平扩展以适应更高的流量。
• NATS 用作集群协调器并存储节点信息。它还用于集群事件。
• MySQL / PostgreSQL 用于存储元数据，如组织、用户、函数、警报规则、流模式和文件列表（parquet 文件的索引）。
• 对象存储（例如 s3、minio、gcs 等）存储 parquet 文件的所有数据。

官方提供了基于helm charts的部署方式，我这边选用的是本地minio的存储方式。Router、Querier、Ingester、Compactor 和 AlertManager等节点是通过控制ZO_NODE_ROLE环境变量来实现不同角色的任务处理，官方文档有提到不同组件的作用。

• Ingester(数据采集器)：数据采集器用于接收数据采集请求，并将数据转换为 Parquet 格式并存储在对象存储中。在将数据传输到对象存储之前，它会将数据临时存储在 WAL 中。
  Ingester 包含三部分数据：
  • Memtable 中的数据
  • Immutable 中的数据
  • wal 中的 parquet 文件尚未上传到对象存储。
• Querier(查询器): 查询器用于查询数据。查询器节点完全无状态。
• Compactor(压缩器): 压缩器将小文件合并为大文件，以提高搜索效率。压缩器还强制执行数据保留策略、全流删除以及文件列表索引的更新。
• Router(路由器): 路由器将请求分发给Ingester或Querier。它还会通过浏览器中的 GUI 进行响应。路由器是一个超级简单的代理，用于在Ingester和Querier之间发送适当的请求。
• AlertManager: AlertManager 运行标准警报查询、报告作业并发送通知。

核心概念概述

1. 检索（Retrieval）：在信息检索中，指的是从一个大规模文档集合中找到与用户查询相关的文档子集的过程。这是搜索引擎、问答系统等的核心步骤。
2. 表示（Representation）：如何用计算机可处理的形式来表示查询和文档，是检索效果好坏的关键。

1. 稀疏检索

• 核心思想：

  • 使用高维、稀疏的向量来表示查询和文档。
  • 向量的维度通常对应于词汇表中的所有词项（Term）。
  • 每个维度的值表示该词项在查询或文档中的重要性（权重）。
  • 权重计算通常基于词频（TF）、逆文档频率（IDF）等统计信息。
  • 关键特征：向量的大部分维度值为 0（稀疏），只有文档或查询中实际出现的词对应的维度值不为 0。

• 代表算法：

  • TF-IDF：词频-逆文档频率，经典权重计算方法。
  • BM25：TF-IDF 的改进和概率化版本，是目前最主流的稀疏检索算法，效果稳定且优异。它考虑了词频、文档长度、逆文档频率等因素。
    以下是 TF-IDF 和 BM25 的完整计算公式，使用 LaTeX 格式呈现：

  1. TF-IDF 公式
     TF-IDF 由两部分组成：词频 (TF) 和 **逆文档频率 (IDF)**。

     • 词频(TF)
       其中：
     • ：词项 在文档 中的出现次数
     • ：文档 的总词项数

     • 逆文档频率 (IDF)
       其中：

       • ：语料库中文档总数
       • ：包含词项 的文档数量

     • TF-IDF 最终分数
       

  2. BM25 公式
     BM25 在 TF-IDF 基础上引入了词频饱和控制和文档长度归一化。
     完整 BM25 分数
     
     组件详解：

     • 逆文档频率 (IDF)
       

       • ：文档总数
       • ：包含词项 的文档数量
       • ：平滑因子，避免除零错误

     • 词频饱和控制
       

       • ：词项 在文档 中的频率
       • ：饱和度参数（默认值 ）
       • 作用：抑制高频词的过度影响（非线性增长）

     • 文档长度归一化
       

       • ：当前文档长度（词项数量）
       • ：语料库中文档平均长度
       • ：长度归一化参数（默认 ）
       • 作用：惩罚长文档，避免长度偏差
     3. 关键改进对比

     组件	TF-IDF	BM25 改进
     词频 (TF)	线性增长：	非线性饱和：
     文档长度处理	无	显式归一化：
     IDF 平滑	基础：	鲁棒平滑：
     可调参数	无	参数化： (控制饱和度) 和 (控制长度惩罚)

     4. 核心优势总结
        BM25 通过 非线性 TF 饱和 和 文档长度归一化 解决了 TF-IDF 的两大缺陷：
     • 避免长文档主导结果（例如一篇 10,000 词的文档偶然多次出现查询词）
     • 抑制关键词重复堆砌（例如关键词重复 100 次不代表相关性线性增加 100 倍）
     • 参数可调（通过 和 适配不同场景的数据分布）
       

• 计算相关性：

  • 查询向量 q 和文档向量 d 的相关性得分通常通过它们向量的点积（Dot Product）q · d 计算。
  • 点积的结果本质上是查询和文档中共同出现的词项权重乘积之和。

• 优点：

  • 可解释性强：得分直接来源于共同词项及其权重，容易理解为什么某文档被召回。
  • 效率高：可以利用倒排索引（Inverted Index）实现非常高效的检索（仅需处理包含查询词的文档）。索引构建和查询速度通常很快。
  • 无需训练数据：经典方法（如BM25）不需要特定的训练语料来学习参数（虽然参数可以调优）。
  • 对精确匹配效果好：当查询包含明确关键词时，效果通常很好。

• 缺点：

  • 词汇鸿沟问题：无法处理同义词（car vs automobile）、近义词（big vs large）、一词多义（bank 可以是河岸或银行）等问题。查询和文档必须包含相同的词项才能匹配。
  • 语义理解有限：主要基于词形（lexical）匹配，缺乏对深层语义的理解。
  • 长尾/复杂查询效果可能不佳：对于表述模糊、依赖语义而非关键词的查询效果可能不如稠密检索。

• 典型应用：

  • 传统搜索引擎（如早期的Google，现在核心BM25仍是重要组成部分）。
  • 需要高效、可解释检索结果的场景。
  • 作为更复杂检索系统的第一级召回器（快速筛选候选文档）。

2. 稠密检索

• 核心思想：
  • 使用低维、稠密的向量（通常称为嵌入向量）来表示查询和文档。
  • 向量维度通常在几百到几千维。
  • 关键特征：向量的每个维度通常都有非零值（稠密），每个维度代表某种潜在的语义特征。这些特征是通过深度神经网络学习得到的。
• 代表模型：
  • 双塔模型（Dual Encoder）：最常见架构。一个神经网络编码器将查询映射为向量 q，另一个（通常共享参数）将文档映射为向量 d。
  • 预训练语言模型驱动：如基于BERT的模型（DPR, ANCE, ColBERT等）。这些模型利用大规模语料上预训练得到的强大语义理解能力。
• 计算相关性：
  • 查询向量 q 和文档向量 d 的相关性得分通过计算它们之间的向量相似度得到，最常用的是余弦相似度（Cosine Similarity）cos(q, d)。
  • 相似度衡量的是它们在低维语义空间中的“距离”或“方向一致性”。
• 优点：
  • 强大的语义表示能力：能有效捕捉同义词、近义词、语义关联（AI 和 机器学习），缓解词汇鸿沟问题。
  • 对复杂/模糊查询效果好：能更好地理解查询的意图和上下文语义。
  • 迁移学习潜力：预训练语言模型的知识可以迁移到特定领域任务。
• 缺点：
  • 可解释性差：难以解释为什么某个向量代表了某个语义，以及为什么两个向量相似。是一个“黑盒”。
  • 需要大量训练数据：训练高质量的稠密检索模型通常需要大量的标注数据（查询-相关文档对）。
  • 计算开销大：
    • 训练成本高：需要GPU资源和时间训练模型。
    • 索引构建复杂：需要为所有文档生成稠密向量（嵌入），存储空间需求大（比稀疏索引大得多）。
    • 检索效率挑战：计算所有文档向量的余弦相似度在大规模库中非常慢（O(N)）。通常需要借助近似最近邻搜索技术来加速。
  • 对精确匹配可能不如BM25：如果查询就是精确的关键词组合，BM25可能更直接有效。
• 典型应用：
  • 开放域问答（Open-Domain QA）。
  • 需要深度语义理解的检索任务（如对话系统、推荐系统）。
  • 作为稀疏检索的补充，提高召回结果的相关性和多样性（混合检索）。

RAG 详细分步流程

第一阶段：数据准备（预处理，通常是离线完成）

这一步是构建RAG系统的基础，类似于为模型准备一个“参考图书馆”。

1. 加载数据（Loading）：从指定的数据源（如公司内部的PDF、Word文档、API文档、网页、数据库等）获取原始数据。
2. 转换数据（Splitting）：将文档转换成更小的、具有语义的文本片段（chunks）。这是因为大模型有上下文窗口限制，且小块文本更易于精准检索。
   • 方法：通常使用文本分割器（Text Splitter），按字符、标记（token）或标题等自然断点进行分割。
3. 向量化（Embedding）：使用嵌入模型（Embedding Model）（如OpenAI的text-embedding-ada-002、Cohere的模型、开源的BGE模型等）将每个文本块转换为一个高维数值向量（Vector）。这个向量代表了该文本的语义信息。
4. 存储（Storing）：将这些向量及其对应的原始文本内容，存入一个专门的向量数据库（Vector Database）（如Chroma, Pinecone, Weaviate, Qdrant等）。向量数据库的优势在于能高效地进行相似性搜索。

第二阶段：检索（Retrieval - 实时）

当用户提出一个问题时，系统会在这个“参考图书馆”里查找最相关的资料。

5. 查询向量化（Query Embedding）：当用户输入一个问题（Query）时，系统使用同一个嵌入模型将这个问题也转换为一个向量。
6. 向量相似性搜索（Similarity Search）：系统在向量数据库中，搜索与“查询向量”最相似的前K个文本块向量（K是一个可设定的数量，例如Top 5）。
   • 度量标准：通常使用余弦相似度（Cosine Similarity）等方法来计算向量间的相似度。
7. 获取上下文（Retrieve Context）：系统根据上一步找到的向量，从数据库中取出对应的原始文本块（Chunks）。这些文本块就是与用户问题最相关的“证据”或“上下文”。

第三阶段：增强生成（Augmented Generation - 实时）

现在，大模型拿到了“参考资料”，开始生成答案。

8. 构造提示词（Prompt Construction）：系统构造一个最终的提示词（Prompt），发送给大语言模型（如GPT-4等）。这个提示词通常由三部分组成：

   • 指令（Instruction）：告诉模型它的角色和任务（例如：“你是一个有帮助的助手，请根据以下上下文回答问题。”）
   • 检索到的上下文（Retrieved Context）：将第7步中获取到的所有相关文本块作为背景信息。
   • 用户问题（User Question）：原始的用户问题。
   • 示例：

     指令： 请严格根据提供的上下文内容来回答问题。如果答案不在上下文中，请回答“根据已知信息无法回答该问题”。
     上下文： {这里插入从向量数据库检索到的相关文本块1、2、3…}
     问题： {用户的原始问题}
     答案：

9. 生成回答（Generation）：大语言模型接收到这个精心构造的提示词后，会基于提供的上下文（而不是仅凭其内部记忆）来生成一个准确、可靠的答案。

10. 返回答案（Response）：将生成的答案返回给用户。

3. 知识图谱增强检索

• 核心思想：
  • 不是独立的检索模型，而是利用外部结构化的知识图谱来增强现有的检索模型（稀疏或稠密）。
  • 知识图谱是一个由实体（Entity）、实体属性（Attribute）和实体间关系（Relation）组成的语义网络。
  • 目标是将KG中包含的丰富语义信息（实体链接、关系、类型、描述等）融入到检索过程中，提升对查询和文档的理解。
• 增强方式：
  1. 查询扩展/重写：
     • 识别查询中的实体。
     • 利用KG查找该实体的别名、同义词、相关实体（如：Steve Jobs -> Apple Inc. 创始人 -> Apple 产品 iPhone）。
     • 将扩展得到的信息（别名、相关实体词）加入到原始查询中，再用稀疏/稠密模型检索。
  2. 文档表示增强：
     • 识别文档中的实体。
     • 将实体在KG中的信息（类型、关系、描述文本的嵌入）融入到文档的向量表示中（稀疏或稠密）。
  3. 联合检索/排序：
     • 在检索或排序阶段，不仅考虑查询-文档的匹配度，也考虑文档中实体与查询中实体的语义关联度（通过KG中的路径、关系等计算）。
     • 构建图神经网络模型，同时建模文本信息和KG结构信息。
  4. 实体链接（Entity Linking）：将文本中提到的实体指称项链接到KG中对应的实体，这是很多增强方法的基础步骤。
• 优点：
  • 引入结构化知识：提供额外的、明确的语义信息，弥补纯文本理解的不足。
  • 提升语义理解深度：更好地理解实体间关系、实体类型、背景知识。
  • 缓解歧义：帮助区分一词多义（利用实体上下文）。
  • 可解释性潜力：通过实体链接和关系路径，可以提供部分解释（如：文档被召回是因为提到了与查询实体相关的另一个实体X）。
• 缺点：
  • 依赖高质量KG：检索效果高度依赖于所使用的知识图谱的覆盖面、准确度和时效性。构建和维护高质量KG成本高昂。
  • 实体链接错误传播：如果实体链接步骤出错，后续增强可能引入噪声甚至错误。
  • 系统复杂度增加：需要集成实体识别、链接、KG查询等多个模块，系统架构更复杂。
  • 领域依赖性强：特定领域的KG可能难以获取或构建。
• 典型应用：
  • 需要深度领域知识的检索（如医疗、金融、法律）。
  • 百科问答、事实核查。
  • 需要理解实体间复杂关系的场景。
  • 任何希望利用结构化知识提升纯文本检索效果的领域。

在RAG中Embdding Model不存在“绝对最好”，只有“最合适”：

• 中文为主的 RAG：BGE 系列（bge-m3 / bge-large-zh）是目前性价比和效果最均衡的选择
• 中英混合 / 通用检索：bge-m3 或 text-embedding-3-large（OpenAI）
• 极致效果、不差钱：OpenAI embedding（text-embedding-3-large）

目前北京智源人工智能研究院的BGE几乎是当前检索领域开源 Embedding 的事实标准，中文语义检索明显强于 sentence-transformers

总结对比表

发展趋势与融合

• 混合检索：当前最先进的检索系统通常结合稀疏检索和稠密检索。例如：
  • 第一级：用BM25快速召回一批候选文档（高召回）。
  • 第二级：用稠密检索模型对候选文档进行精细化重排（高精度）。
  • 或者，将稀疏检索分数和稠密检索分数线性融合（如 score = α * BM25 + β * Dense）。
• 知识融入稠密模型：研究者致力于将KG知识直接编码到预训练语言模型中（如在预训练或微调阶段融入KG信息），让模型本身学习到更多结构化知识，减少对外部KG查询的依赖。
• 端到端学习：探索将KG信息、检索、排序甚至答案生成整合到一个端到端的可训练框架中。

公司章程不能高于《公司法》，它必须在《公司法》框架内制定和发挥作用。《公司法》是上位法和强制法，而公司章程是下位法和自治法。

一、 基本关系：服从与补充

1. 《公司法》是根本大法，具有强制性和普适性

   • 《公司法》是国家制定的法律，规定了公司组织与行为的基本原则、基本制度和底线要求。
   • 它包含大量强制性规范，这些规范是公司必须遵守的，不能通过公司章程予以排除或修改。例如：
     • 公司股东滥用公司法人独立地位和股东有限责任，应对公司债务承担连带责任（“法人人格否认”）。
     • 董事、监事、高级管理人员对公司负有忠实和勤勉义务。
     • 公司必须遵守财务会计制度。
     • 股东会的某些核心职权（如修改公司章程、合并、分立、解散等）是法定的，不能通过章程下放给董事会。

2. 公司章程是“公司的宪法”，具有自治性和具体性

   • 公司章程是公司股东共同制定的内部最高行为准则。
   • 它的效力主要来源于《公司法》的授权，在《公司法》留下的自治空间内，公司章程可以做出更具体、甚至不同于《公司法》默认安排的规定。

二、 公司章程与《公司法》的互动关系（具体表现）

我们可以通过几个具体领域来看待这种关系：

三、 核心结论：效力层级与冲突解决

1. 效力层级：《公司法》是 “上位法” ，公司章程是 “下位法” 。下位法不能违反上位法。
2. “另有规定”是关键：当《公司法》的条文中出现 “但是，公司章程另有规定的除外” 这类表述时，意味着法律明确授权公司章程可以做出不同于默认规则的规定。在这种情况下，公司章程的效力优先于《公司法》的默认规定。
3. 冲突解决：
   • 如果公司章程的规定落入《公司法》的授权（自治）范围，则该规定有效且优先适用。
   • 如果公司章程的规定违反了《公司法》的强制性规范（例如，试图排除股东的法定知情权，或免除董事的忠实义务），则该部分章程条款无效。
   • 在实践中，如果公司章程的条款与《公司法》的强制性规定相冲突，该条款自始无效，法院或监管部门将不予认可，并会适用《公司法》的相应规定。

一个形象的比喻：

• 《公司法》 就像国家的 《宪法》 ，它设定了基本的游戏规则和公民的权利底线。
• 公司章程 就像一所 大学的《学生手册》 ，它可以在《宪法》和法律允许的范围内，制定更具体的校内规则（比如宿舍管理规定、学分计算办法），但这些校规绝不能违反国家的法律。

总结：

公司章程的自治权是《公司法》所赋予的，它只能在法律划定的“自治跑道”上奔跑，而不能冲出跑道、违反法律的强制性规定。因此，公司章程不能高于《公司法》，它是《公司法》框架下的内部治理核心文件。 在制定和修改章程时，必须仔细甄别哪些是法律的强制性规定，哪些是法律授权的自治空间。

公司章程是公司的“宪法”，其制定、保存和执行直接关系到公司的健康运营和风险防范。以下是一份详细的指南，涵盖公司章程的制定、保存与实践执行。

第一部分：如何制定公司章程

公司章程的制定绝非简单地填写一份工商局的标准模板，而应是一个深思熟虑、量身定制的过程。

制定流程

1. 发起人起草：

   • 对于有限责任公司，由初始股东共同制定。
   • 对于股份有限公司，由发起人制订。
   • 在实践中，通常由核心股东或律师在充分协商的基础上起草草案。

2. 关键内容协商：

   • 股东们必须对章程的核心条款进行充分讨论和谈判，确保所有重要问题达成一致。这是最重要的一步。

3. 正式审议与通过：

   • 有限责任公司：必须经全体股东一致同意并签名、盖章。
   • 股份有限公司：在创立大会上由出席会议的认股人所持表决权过半数通过。

4. 报送登记与生效：

   • 公司章程是公司设立登记的必备文件，需报送市场监督管理局（工商部门）进行审核。
   • 公司章程自公司正式成立（领取营业执照）之日起生效。

核心内容与个性化设计（超越模板）

工商局会提供标准模板，但切忌直接使用。必须在以下关键领域进行个性化设计：

强烈建议：在制定章程，特别是涉及多位股东时，咨询专业律师。律师能帮助您预见潜在纠纷，并将对各股东最有利的保护条款写入章程。

第二部分：如何保存公司章程

公司章程不应被锁在柜子里蒙尘，而应作为活文件被妥善管理和使用。

1. 物理保存：

   • 正本：将市场监督管理局盖章核准的公司章程正本，与营业执照、公章等重要文件一起，存放在公司的安全场所（如保险柜），由专人负责管理。
   • 副本：制作多份副本，供日常使用。

2. 电子保存：

   • 将章程的电子版（PDF/Word）保存在公司的共享服务器或加密云盘中，确保管理层和股东可以方便地查阅。
   • 确保电子版与工商登记备案的版本一致。

3. 分发与告知：

   • 应确保每位股东、董事、监事和高级管理人员都持有一份章程副本，并已阅读和理解其内容。
   • 新加入的股东或高管，应在入职或入股时第一时间获取并学习章程。

第三部分：如何实践执行公司章程

章程的生命在于执行。否则，它只是一纸空文。

1. 作为日常行为的最高准则：

   • 决策依据：公司召开股东会、董事会，作出任何重大决策，都必须首先查阅章程，确保权限和程序符合规定。
   • 合同与授权：在对外签订重要合同时，应核查签约人（如法定代表人、授权代表）的权限是否与章程规定一致。
   • 避免程序瑕疵：例如，章程规定召开股东会需提前15日通知，若只提前了10日，则形成的决议可能因程序违法而被撤销。

2. 解决内部纠纷的准绳：

   • 当股东之间、股东与公司之间发生争议（如分红、股权转让、投票权等），公司章程是解决争议的第一位和最重要的依据。
   • 例如，关于股权转让的争议，完全取决于章程是如何约定的，而不是《公司法》的默认规定。

3. 对抗外部风险的盾牌：

   • 对于董事、高管来说，只要其行为是依据公司章程和相关法律作出的，就可以在很大程度上去主张免除个人责任。
   • 规范的章程执行记录（如股东会决议、董事会决议）是证明公司行为独立、避免“法人人格否认”（股东连带责任）的重要证据。

4. 定期审查与修订：

   • 公司章程不是一成不变的。当公司发生以下情况时，应及时启动章程的修订程序：
     • 增加或减少注册资本。
     • 股东结构发生变化（如新股东加入、老股东退出）。
     • 公司业务模式或战略发生重大调整。
     • 法律法规出现重大变更。
   • 修订章程必须遵循章程本身规定的程序（通常是经持有三分之二以上表决权的股东通过），并重新报送市场监督管理局备案。

总结：最佳实践清单

• [ ] 量身定制：拒绝简单套用模板，围绕股东关系和公司战略设计核心条款。
• [ ] 专业把关：在制定和修订时，寻求法律专业人士的帮助。
• [ ] 全员知晓：确保所有股东和管理层熟悉章程内容。
• [ ] 严格遵循：在做出任何重大决策前，养成“先查章程”的习惯。
• [ ] 完整记录：妥善保管与章程执行相关的所有会议记录和决议。
• [ ] 动态更新：根据公司发展和法律变化，定期审视并适时修订章程。

将公司章程真正融入到公司的血液中，是公司实现规范治理、基业长青的根本保障。

最近给所有的java应用加了就绪探针和存活探针，并且通过kubectl rollout status deploy命令让Gitlab流水线能检测应用是否已经就绪。

1

kubectl rollout status deploy $DOCKER_APP_NAME --context=dev-admin@cluster.dev -n recircle-industry-platform-dev

但是又遇到一个新的问题，OpenTelemetry的java-agent默认也会把探针的请求上报到后端的监控服务。

由于探针请求的频率有点高，而且每个应用都会有探针请求，结果导致OpenObserver处理不过来，报MemoryTableOverflowError：

1
2
3
4
5
6
7
8
9
10
11
12
13

2025-06-18T07:40:22.074188063+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:22.074317749+00:00 INFO actix_web::middleware::logger: 10.233.71.119 "POST /api/default/v1/traces HTTP/1.1" 503 74 "1706" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000299    
2025-06-18T07:40:22.449896048+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:22.450004619+00:00 INFO actix_web::middleware::logger: 10.233.80.211 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2230" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000270    
2025-06-18T07:40:22.517553812+00:00 INFO actix_web::middleware::logger: 10.233.71.0 "POST /api/default/v1/metrics HTTP/1.0" 503 74 "3826" "-" "OpenTelemetry Collector Contrib/0.111.0 (linux/amd64)" 0.000867    
2025-06-18T07:40:23.572270669+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:23.572416843+00:00 INFO actix_web::middleware::logger: 10.233.71.1 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2278" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000371    
2025-06-18T07:40:23.657375098+00:00 INFO actix_web::middleware::logger: 10.233.71.247 "POST /api/default/v1/metrics HTTP/1.1" 503 74 "20634" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000578    
2025-06-18T07:40:23.803923763+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:24.635078516+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:24.635189325+00:00 INFO actix_web::middleware::logger: 10.233.71.223 "POST /api/default/v1/traces HTTP/1.1" 503 74 "2162" "-" "OTel-OTLP-Exporter-Java/1.40.0" 0.000268    
2025-06-18T07:40:25.119413710+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError    
2025-06-18T07:40:25.120251549+00:00 ERROR openobserve::service::traces: [TRACES:OTLP] ingestion error while checking memtable size: MemoryTableOverflowError

目前找到几种解决方法。

java-agent上报时过滤掉actuator的请求

opentelemetry-java-instrumentation#1060和discussions#6605中提到了这个问题，但是agent并不打算实现Exclude URL的功能。

opentelemetry有一个三方提供的samplers包，可以做到过滤actuator请求。需要你将其打包成java-agent-extension，并对java-agent-extension进行配置

通过opentelemetry-spring-boot-starter过滤actuator请求

还有一种方式是通过opentelemetry-spring-boot-starter过滤掉actuator请求。

但是这种方式需要侵入代码，比较好的方式是把这个功能和spring-boot-actuator一起封装成二方包。但是需要对业务开发人员灌输这个二方包的作用，仍然不够优雅。

通过opentelemetry-collector丢弃掉actuator请求

第三种方式就是在java应用和openobserver之间添加一个opentelemetry-collector的组件，这个好处是让opentelemetry-collector统一收集所有java应用上报的OTEL消息，然后批量发给openobserver可以缓解openobserver的压力（openobserver底层使用LSM数据结构，有后台merge的过程），其次就是有非常多的processor可以对OTEL消息进行处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  filter/skip_actuator:
    error_mode: ignore
    traces:
      span:
        # 丢弃包含actuator或healthz请求
        - attributes["http.route"] != nil and IsMatch(attributes["http.route"], ".*actuator.*")
        - attributes["http.target"] != nil and IsMatch(attributes["http.target"], ".*/healthz")
        - attributes["url.path"] != nil IsMatch(attributes["url.path"], ".*actuator.*")
        # 丢弃kube-probe发出的探针请求
        - attributes["http.user_agent"] != nil and IsMatch(attributes["http.user_agent"], "^kube-probe.*")

exporters:
  otlphttp/openobserve:
    endpoint: "http://openobserve.recircle-industry-platform-dev:5080/api/default"
    headers:
      Authorization: Basic cm9vdEBleGFtcGxlLmNvbTpjNEVxU1Jhb0F5SHNWTDVn
      stream-name: default

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [filter/skip_actuator, memory_limiter, batch]
      exporters: [otlphttp/openobserve]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/openobserve]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/openobserve]

这里推荐一个网站otelbin.io可以可视化opentelemetry-collector的配置。

一、公司的有限责任内涵

“有限责任”是公司制度的基石，它包含两个相互关联但又独立的层面，理解这一点至关重要。

1. 公司自身的责任 - 独立法人责任

• 内涵：公司是独立的企业法人，拥有独立的法人财产。这意味着公司在法律上被视为一个独立的“人”，拥有独立的人格，能够以自己的名义拥有财产、签订合同、起诉和应诉。
• 责任承担：公司以其全部财产对自己的债务承担责任。这里的“全部财产”包括公司的注册资本、经营积累的固定资产、现金、知识产权等所有资产。
• 简单来说：公司的债，用自己的家当来还。

2. 股东的责任 - 有限出资责任

• 内涵：股东在履行其出资义务后，其对公司的责任即告完成。
• 责任承担：
  • 有限责任公司的股东以其认缴的出资额为限对公司承担责任。
  • 股份有限公司的股东以其认购的股份为限对公司承担责任。
• 简单来说：股东对公司债务的责任，上限就是他们投资进去的钱。如果公司资不抵债破产，股东最多损失全部投资，但其个人财产与公司债务完全隔离，债权人无权要求股东用个人财产来偿还公司债务。

核心关系图示：

flowchart TD    A[公司债务] --> B[“公司（独立法人）”]    B --> C[“以公司全部财产
承担责任”]        D[股东] --> E[“履行出资义务
（认缴额/认购股份）”]    E --> F[“责任上限
（仅损失其投资）”]        G[债权人] -- 只能向 --> B    G -- 不能向 --> D

举例说明：
小明、小红和小刚三人共同出资100万元成立了一家“创想科技有限公司”，小明认缴50万，小红认缴30万，小刚认缴20万。公司经营中欠下供应商500万元债务，但公司全部资产只剩80万元。

• 公司责任：创想公司需用这80万元资产来偿还债务，不足部分，因公司无力偿还，可以破产清算。
• 股东责任：小明、小红和小刚无需用自己的个人存款、房产或车辆来偿还剩余的420万元债务。他们最多就是损失了自己已经投入的50万、30万和20万。
• 这就是“有限责任”的保护作用：它鼓励了投资和创业，将股东的风险控制在其出资范围之内。

二、有限责任的例外：“刺破公司面纱”或“法人人格否认”

“有限责任”不是绝对的护身符。如果股东滥用这层“保护罩”来从事不法行为、损害他人利益，法律就会揭开这层面纱，让躲在公司背后的股东直接承担责任。这就是“法人人格否认”制度。

根据中国《公司法》第23条（2023年修订版）的规定，主要有以下两种例外情况：

1. 纵向人格否认：股东滥用公司独立人格

• 情形：公司股东滥用公司法人独立地位和股东有限责任，逃避债务，严重损害公司债权人利益的。
• 法律后果：该股东应当对公司债务承担连带责任。
• 常见行为：
  • 人格混同：公司与股东在财产、业务、人员、场所等方面界限不清，无法区分。俗称“一套人马，两块牌子”。（这是最常见的类型）
    • 表现：公司账户与股东个人账户混用，公款私用；公司业务与股东个人业务不分；公司账簿与股东账簿不分。
  • 过度控制与支配：股东像操作木偶一样完全操控公司，使公司失去独立意志，成为股东谋取私利的工具。
  • 资本显著不足：股东投入的资本与公司经营所隐含的风险相比明显不匹配，实质上是利用少量资本从事高风险业务，将风险转嫁给债权人。

2. 横向人格否认：股东滥用股东有限责任

• 情形：公司股东利用其控制的两个以上公司实施上述滥用行为，逃避债务，严重损害公司债权人利益的。
• 法律后果：各公司应当对任何一个公司的债务承担连带责任。
• 常见行为：
  • 股东设立多个“兄弟公司”或“母子公司”，彼此之间财产、利益随意输送。
  • 当其中一个公司负债时，迅速将资产转移至其他公司，导致债权人无法执行。

法人人格否认制度的历史沿革

中国法律上的“法人人格否认”制度在2023年新《公司法》修订之前就已经确立并存在了多年。 下面我们来详细梳理一下这个制度的发展历程：

一、 制度起源与确立（2005年）

在2005年之前，中国法律并没有成文法的明确规定“法人人格否认”制度。但在司法实践中，已经出现了一些基于公平原则和禁止权利滥用原则的类似判决。

里程碑式的节点是2005年《公司法》的修订。

• 2005年《公司法》第二十条：

  公司股东应当遵守法律、行政法规和公司章程，依法行使股东权利，不得滥用股东权利损害公司或者其他股东的利益；不得滥用公司法人独立地位和股东有限责任损害公司债权人的利益。

  公司股东滥用股东权利给公司或者其他股东造成损失的，应当依法承担赔偿责任。

  公司股东滥用公司法人独立地位和股东有限责任，逃避债务，严重损害公司债权人利益的，应当对公司债务承担连带责任。

• 意义：

  • 这是中国首次在成文法中明确确立“法人人格否认”（或“刺破公司面纱”）制度，具有划时代的意义。
  • 它为解决实践中普遍存在的股东滥用公司独立人格和有限责任的问题提供了明确的法律武器。

二、 制度的司法实践与发展（2005-2023）

在2005年《公司法》生效后，最高人民法院通过一系列司法解释和指导性案例，进一步细化和发展了这一制度的适用规则。

1. 《公司法》司法解释（二）（2008年）：在清算环节，规定了股东因怠于履行义务导致公司无法清算时，应对公司债务承担连带责任，这被视为法人人格否认在清算程序中的具体化。
2. 《公司法》司法解释（三）（2011年）：规定了股东出资不足、抽逃出资等情况下的责任，也为否认公司人格提供了相关依据。
3. 《九民纪要》（2019年）：这是司法实践中关于法人人格否认最重要的指导性文件之一。
   • 明确了判断标准：它详细阐述了如何认定“人格混同”，核心标准是“公司是否已丧失独立意志”，最关键的判断因素是财产混同（如公司账户与股东账户不分，公款私用等）。
   • 强调了审慎适用原则：要求法官必须严格掌握适用标准，不能轻易否认公司的独立人格。
   • 明确了横向否认：《九民纪要》虽然不属于司法解释，但它首次在官方文件中系统地提出了“横向刺破公司面纱”的思路，即当多个关联公司人格高度混同，难以区分时，可以判令它们相互之间承担连带责任。

三、 2023年新《公司法》的完善与升级

2023年修订的《公司法》（2024年7月1日生效）在总结近二十年司法实践经验的基础上，对法人人格否认制度进行了系统的整合和升级。

• 新《公司法》第二十三条：

  公司股东滥用公司法人独立地位和股东有限责任，逃避债务，严重损害公司债权人利益的，应当对公司债务承担连带责任。

  股东利用其控制的两个以上公司实施前款规定行为的，各公司应当对任何一个公司的债务承担连带责任。

• 主要变化和进步：

  1. 结构整合：将原本散见于不同条款和司法解释中的精神，整合为一个更为精炼和核心的条款。
  2. 明文规定“横向否认”：这是最大的进步。新法第二款明确将《九民纪要》中探索的“横向人格否认”正式写入法律，使其有了明确的法律依据。这意味着，不仅股东和公司之间可以被“刺破”，关联公司之间也可以被“刺破”。
  3. 法律位阶提升：将实践中已经成熟适用的规则从司法解释层面提升到了基本法律层面，权威性更高。

总结

中国的法人人格否认制度自2005年起就已正式确立，并经过近二十年的司法实践不断丰富和发展。2023年的修订是对这一成熟制度的法定化、系统化和升级，使其更能适应复杂的商业实践，更好地保护债权人的合法权益。

总结与实践提示

给创业者和公司股东的建议：

1. 尊重公司的独立性：建立独立的财务制度，公司账户与股东个人账户严格分开。
2. 规范治理：按时召开股东会，制作并保存完整的会议记录和财务报告。
3. 避免公私不分：不要随意将公司资金用于个人消费，也不要把个人财产和公司财产混为一谈。
4. 依法出资：按时足额缴纳认缴的出资，避免“空壳”运营。

有限责任是法律赋予的“保护伞”，但绝不是“欺诈的护身符”。 一旦被法院认定为人格混同或滥用公司形式，这层保护将瞬间消失，股东将面临无限连带责任的风险。