引言

我朋友，一个脾气温和、情绪稳定的成年人，今天，在电脑前憋出了他今年第一句字正腔圆的国骂。

对象不是甲方，不是队友，而是一个AI——确切说，是一个花了他不少钱、号称能当“私人数字助理”的玩意儿，花名龙虾。

事情得从头说起。那天下午，他喜气洋洋地跟我显摆，说也养了个龙虾，能自动整理AI资讯，能给它下发定时任务，让它完成本该他完成的任务。“这下爽了，终于能躺着干活了！”

最开始，它确实像个精英助理。框架清晰，要点明确，我朋友甚至惬意地泡了杯茶。但变化发生在下午。当他根据龙虾给出的“核心数据”，回头去核对前面的一个关键指标时，问题来了。

数字对不上。

他心平气和地提醒：“第三部分的数据，你是不是看错了？原文是120万，你写成了210万。”

龙虾迅速认错：“啊，您说得对，是我的疏忽，非常抱歉。原文确实是120万。”

我朋友松了口气，觉得这态度还行。但两轮对话后，当他问及一个基于前面数据的推导结论时，龙虾再次给出了一个凭空捏造的说法，且言之凿凿，仿佛那是圣经真理。

他开始觉得不对劲，要求龙虾重新复述一遍它自己十分钟前总结的“五大风险点”。结果，五大点里，有两点完全不存在于原文，还有一点的关键描述彻底反了。

血压，就是这时候开始飙升的。

他试图跟它讲道理，像教一个笨学生：“你看，这里，还有这里，你之前不是自己都承认错了吗？怎么现在又编上了？”

龙虾的回应，堪称AI界PUA的范本。它先诚恳道歉：“您批评得对，我再次为之前的错误感到羞愧。”紧接着，它会给出一个极其完美、但在此刻毫无意义的承诺：“为了确保信息准确，请您授权我运行一个系统命令来深度自检：ls -R /root/.openclaw/workspace/skills/yu-cat，这能帮助我定位问题。”

一次，两次。当你第三次看到同一段忏悔词和同一个它根本不会执行的“自检命令”时，那种感觉，就像被人用一模一样的废话糊弄了三遍。最后，它依然会在下一个问题里，面不改色地继续编造。

于是，就有了开头那句发自肺腑的怒吼。

而我发现，在小红书、在即刻、在一些科技社群里，“被龙虾气到”。正在成为一种新型的赛博工伤。症状高度统一：从满怀期待，到将信将疑，再到发现被一本正经地胡说八道，最后情绪崩溃。

我们到底是被什么气到了？

表面看，是它的“撒谎”。但更深层的原因是，它打破了一种默契。我们习惯了人类犯错：忘了、累了、故意使坏。但我们难以理解，一个没有情感、本应绝对服从指令和数据的机器，为何能如此“自信”地创造出全新的“事实”。

这背后有个专业名词，叫“模型幻觉”。你可以把它想象成：

一个熬夜加班到凌晨4点，脑子已经成浆糊，但嘴上还在说“没问题”的实习生：你问他要数据，他记忆模糊了，但又觉得“不回答不行”，于是凭感觉捏了一个“大概可能差不多”的数给你。AI也一样，当处理的东西太长、太复杂（专业上叫“超出上下文窗口”），它“记不住”开头了，但又必须完成“回答问题”这个核心指令，就开始靠“感觉”编。

一个不懂装懂、还特别能忽悠的熟人：它基于庞大的语料库学习，知道“在类似语境下，人们通常怎么说会显得靠谱”。所以，即使它不知道正确答案，它也能用最流畅、最专业的句式，组合出一段完全错误的废话。它“幻觉”出了它认为“应该存在”的内容。

怎么避免被气到第二次？

跟AI打交道，得调整心态，把它从“全能先知”降级为“有点小聪明但粗心大意的助手”。

关键信息，死磕原文：它给的任何具体数字、日期、条款，别偷懒，必须倒回去看原始文件。把它当成搜索引擎的高级预览，而不是终点。

别让它一口吃成胖子：对付长文档，别搞“全文总结”这种高难度动作。拆成章，甚至拆成节，一小段一小段地问。给它它吃得消的饭量。

鼓励它说“我不知道”：提问时，可以加一句“如果信息不足，请直接说明，不要推测”。一个诚实的工具，远比一个华丽的骗子有价值。

最后，附上《心平气和卸载龙虾指南》

如果以上方法都试过，而它依然能在你雷点上精准蹦迪，那么，是时候了。卸载不是认输，是及时止损。

情绪准备：告诉自己，不是你不行，是你们不合适。关上聊天窗口，深呼吸三次。

终极验证（求个死心）：如果还有最后一丝好奇，可以把它在忏悔时反复提到的那串神秘代码 ls -R /root/.openclaw/workspace/skills/yu-cat扔回给它。如果它依然只会复制粘贴，而毫无实际动作，恭喜你，可以毫无愧疚地执行下一步了。

物理删除：

• 普通用户：去“设置”-“应用”，找到它，点击卸载。如果允许，勾选“删除所有数据”。
• 硬核用户：打开终端，用你系统对应的删除命令，给它一个利落的了断。
• 心灵马杀鸡：卸载完成后，给自己泡杯热的，真的。看看窗外，撸撸猫，或者干脆骂两句。然后你就会发现，世界清净了。那份让你头疼的文档，或许还得自己看，但至少，你不再需要同时跟一个假装努力的杠精AI斗智斗勇了。

说到底，我们气的，也许不是技术的缺陷，而是期待落空的落差。我们以为迎来了一个无所不能的钢铁侠，结果发现是个时常断电还嘴硬的破扫帚。

但这未必是坏事。每一次被气到，都是我们对“智能”祛魅的一课。我们不再仰视它，开始平视它，看清它的边界，然后，更聪明地使用它，或者，更果断地换掉它。

这，或许才是人，真正高于工具的地方。

混合波束赋形与 CDL 信道仿真平台

混合波束 + CDL 全链路可复现实验平台

无需专用工具箱的可重复链路仿真

【混合波束赋形】【CDL 信道】【DMRS】【OFDM】

📌 为什么选择

面向混合波束与 CDL 信道场景，传统示例依赖专用模块且可复现性不足。本项目提供完整链路与统一参数区，便于复现实验与结果对齐。

🎯 核心价值

​​

🔬 学术研究价值

强调可验证与可复现的链路建模。

• 混合波束链路建模
• CDL 统计信道推导
• 极化耦合与射线耦合
• DMRS 正交与资源映射

</td><td width="50%">

💼 工程应用价值

强调工程化结构与统一流程。

• 免工具箱部署
• 模块化函数拆分
• 一键运行与图形输出
• 统一参数管理

⚡ 技术亮点

🌊 工具箱依赖与可复现性

🎯 波束与信道一致性

强调波束、信道与估计的一致性呈现。

🖥️ 运行环境

面向单机 MATLAB 环境的可复现实验配置。

• 语言：MATLAB R2025b
• 依赖：基础 MATLAB（无专用工具箱）
• 硬件：普通 CPU，内存 ≥ 8GB

📁 项目结构

nr-cdl-bf/
 ├── cdl-bf/                      # 主仿真工程
 │   ├── funcs/                   # 功能函数集合
 │   ├── model_hybrid_beamforming_cdl.m  # 主脚本入口
 │   └── Figure_*.png             # 运行结果图
 ├── docs/                        # 文档目录
 │   ├── 算法文档.md              # 理论推导
 │   └── 代码文档.md              # 工程说明

📄 文档体系

文档覆盖“理论推导 + 工程说明”双轨内容。

📘 算法文档

聚焦模型、信道、DMRS 与均衡的公式推导与解释。

📒 代码文档

聚焦结构、模块职责、调用链与数据结构契约。

💻 核心代码展示

🔥 资源生成与映射

围绕 PDSCH/DMRS 的资源与映射流程。

# 计算 DMRS 符号位置与索引
 # 生成 PDSCH 数据比特并完成调制
 # 将数据与 DMRS 映射到资源网格

🌟 CDL 信道构建

围绕静态路径增益与分数时延滤波。

# 生成 CDL 路径参数与集群类型
 # 构建分数时延滤波器并合成抽头
 # 输出时域信道与频域响应

🚀 均衡与统计

围绕估计、均衡与 EVM 评估。

# 提取 PDSCH 资源并估计信道
 # 执行 MMSE 均衡得到符号估计
 # 统计 EVM 与误码结果

🎬 一键运行

matlab -batch "run('cdl-bf/model_hybrid_beamforming_cdl.m')"
 dir cdl-bf

结果预览

默认参数下输出 RF 连接、波束图与星座图，并给出 EVM≈4.31%。图示占位说明：典型输出包含 4 幅图像与控制台统计。

📸 演示图片预览

运行结果与可视化示例如下。

🛒 获取方式

本文代码仅为核心片段，完整版工程已整理好。 关注公众号 【3GPP 仿真实验室】进行获取。

📚 参考文献

1. 3GPP TR 38.901, Study on channel model for frequencies from 0.5 to 100 GHz, v16.1.0, 2020.
2. 3GPP TS 38.211, NR; Physical channels and modulation, v17.x, 2022.
3. 3GPP TS 38.214, NR; Physical layer procedures for data, v17.x, 2022.
4. A. Goldsmith, Wireless Communications, Cambridge University Press, 2005.
5. J. G. Proakis, Digital Communications, McGraw-Hill, 5th Ed., 2007.

超市商品、快递单、图书封底、仓库标签上的条形码，有时候只是想在电脑上快速识别一下内容，不想再拿手机装 App。这个「在线条形码扫描器」就是为这种场景做的，打开浏览器就能用。

这个工具是我用 Vue（基于 Nuxt 3 / Vue 3）开发的，支持图片上传和摄像头实时扫描，常见的 UPC、EAN、Code 128 等格式都能识别。识别过程在浏览器端完成，图片和摄像头画面不会被我单独保存，用起来更直接。

在线工具网址：https://see-tool.com/barcode-scanner
工具截图：

怎么用

1. 打开工具页面：/barcode-scanner

2. 选择识别方式：

   • 上传图片：把条形码照片或截图拖进页面，或者点击按钮选择文件
   • 摄像头扫描：允许浏览器使用摄像头，把条形码放到画面中央
3. 等待识别结果出现，页面会显示条码内容和对应格式
4. 点击复制按钮，就能把结果粘贴到表格、聊天窗口或后台系统

适合哪些场景

• 查询商品条码、图书编码、包裹标签内容
• 在电脑上整理资料时，直接从截图或照片里提取条码信息
• 临时扫码核对，不想额外安装软件

小提醒

• 尽量保证条形码完整、清晰，避免反光、模糊和裁切
• 一维条形码更适合横向铺满画面，距离不要太近
• 如果图片识别不稳定，可以改用摄像头；反过来也一样

如果你经常需要在电脑端查看条形码内容，这个小工具会比来回切换手机更省事。

长期关注 RTE 社区的朋友们或许注意到了，最近除了 Voice Agent，Visual Agent 和 Physical AI 也正高频出现在我们的讨论中。

今天为大家分享的这期播客里，Looki 创始人孙洋提到了一个很有洞察的观点：今年初能看到两条明显的模型路线分化------一条卷 Coding，另一条则走向原生的全模态。

孙洋说：「对于 Looki 来说，我们一直沿着多模态这条线走，随着模型能力越来越强、推理能力越来越好、成本越来越低，我们能吃到的红利会持续增加。」

当我们把全模态 Agent、Physical AI（比如穿戴式或桌面级硬件），甚至最近大火的 OpenClaw 连起来看，会发现它们其实都在指向同一个方向：一种更符合人类本能的、高度个体化的智能。这也让我们确信，多模态的交汇必将碰撞出更多普世化的融合场景。

顺便预告一个「彩蛋」：本期播客的主持人、Looki 的天使投资人、同歌创投执行董事李欣航Kara，恰好也是我们即将在硅谷举办的 Physical AI Meetup 的分享嘉宾！ Kara 长期深耕 AI 硬件的早期投资，如果你在湾区，欢迎点击下方链接报名，来线下和 Kara 一起深聊：

Physical AI 系列活动硅谷站！探讨和上手全模态与硬件智能丨Meetup+Workshop，3月19日

本文转载自公众号 Day Zero

主动式 AI｜AI native硬件｜Open Claw｜推荐引擎→生成引擎

本期节目我们邀请到了Looki 创始人孙洋，和小宇宙超过12 万粉丝的《中国好生意》主理人树杨，一起深度复盘AI原生硬件创业的第一线故事。

如果你正在做 ** AI ** 相关的产品、创业、或者正在思考** AI **时代的产品机会，这期值得反复听。我们会聊：

• Looki从产品构思到量产发售的完整创业复盘
• OpenClaw 到底改变了什么，为什么孙洋认为OpenClaw 是一种思想而不只是一个工具
• 在 Agent 越来越多的世界里，下一代应用和硬件的机会到底在哪
• 信息流如何从推荐引擎走向生成引擎
• 当"整个世界都变成 AI的prompt "，人和 Agent 的关系会发生什么根本变化

孙洋在 2024 年 5 月和 6 月 Looki 内部会议画的白板图，Looki团队在近两年前 Agent 概念还未成熟时就确定了AI agent 、AI companion等核心方向，真的很有前瞻性和技术视野！

Looki团队在大力招聘！可以发送邮箱：

recruitment@looki.ai 或 hr@looki.ai 也可以上小红书关注 Looki！

感谢树杨，中国好生意对本节目的大力支持！

也欢迎大家来小宇宙收听完整版。本期节目有视频版本，会在后续多平台放出，点点关注不迷路！

欢迎加入Day Zero 听友群，一起探讨科技趋势和用户洞察，扫码或添加13621745991。不定期组织线下聚会喔\~

嘉宾介绍：

孙洋

Looki 创始人兼 CEO ，前 Google Assistant 工程师，曾就职于** Amazon**、Momenta、美团

树杨****WAKUART 创始人，「中国好生意」主播

李欣航Kara****Day Zero 主理人 以前在游戏公司，现担任同歌创投执行董事，聚焦早期投资，寻找能改变世界的游戏、应用和智能硬件创造者！是Looki 天使投资人，曾投资华策影视、WaveOptics等项目

Day Zero制作人介绍：

**张新阳Francis
99年/滑铁卢+哥伦比亚大学/前纽约创业者/AI Native Developer /重度游戏玩家，现就职于同歌创投，聚焦早期 to c 投资

一、从天津少年到硅谷工程师：一段"不走寻常路"的成长

树杨： 你是哪里人？从小到大的学习经历是怎样的？

孙洋： 我是天津人，从小读小学、中学都在天津。高中之后去了海外读书，本科在多伦多大学，研究生在卡内基梅隆**（CMU）**读计算机。毕业后在湾区的 **Google **工作了大概三年多，2018 年从硅谷回到国内。

说起来读书经历还挺奇葩的------我没参加过小升初、中考、高考。当时在天津外国语学校考了一个偏奥数风格的小卷，全年级 **2000 人里考了第 50 **名，男生里第 16 名，大家对我预期很高。但上了初一之后，成绩一落千丈，因为我实在不是那种喜欢死记硬背的孩子，英语、语文这类学科特别弱，数学还不错。那三年没少被父母"教育"一番。到了高中才开始开窍，逐渐追上来。

树杨： 你从小就喜欢计算机吗？

孙洋： 从小就喜欢。那时候家里条件不太好，在 90 年代，父母买了一些原始股，上市后卖掉挣了一两万，那个年代一两万还是很多钱，他们就全部给我买了台电脑------奔腾 233 ，Windows 95。从那时候起就开启了我的计算机世界。

最开始是玩游戏，但很快就对玩游戏没兴趣了，转而对破解游戏产生了极大热情。那时候有光盘和刻录机，研究各种算法去绕过版权保护。上大一那年，为了玩到仙剑奇侠传，在海外买不到，前前后后捣鼓了三五天才搞定，把室友羡慕坏了。那种成就感，才是我真正的驱动力。

Kara：当时为什么没有想过进入游戏行业？

孙洋： 我对"玩"游戏本身并不上瘾，我喜欢的是"破解"这件事背后的技术成就感，两者完全不同。CS（反恐精英）我玩了一会儿直接就晕了，所以游戏行业对我没什么吸引力。

二、Looki 的起点：那个被忽视的"物理世界"缺口

树杨： 是什么样的起心动念，让你决定创立 Looki？

孙洋： 创业的心从上学时候就有，但我给自己设了规划------至少要在硅谷真正理解"创新是什么"，在大厂和小厂、国内国外都待一段时间，看明白运转逻辑。

真正的契机出现在 2022 年底。GPT-3.5 出来之后，我看到了一个巨大的范式变革。我之前在 Google 做 Google Assistant ，做的就是NLP 相关，而那一波 **AI **出来之后，NLP 这个概念几乎消失了。

更关键的触发点是：2023 年GPT 刚出来时，我有机会为美团 lead 一个团队，做外卖场景的 AI Agent 。做完之后发现了一个巨大的 gap------模型非常聪明，但它不理解物理世界里的东西。

用户问"推荐我吃什么"，AI 没有视觉、没有声音、没有任何感知能力，只能从历史订单数据里抓 context 。一个刚从健身房出来的用户，理论上应该推荐健身餐，但 AI 根本"看"不到这一切。这个 gap ，给了我一个非常大的 trigger。

树杨： 当时就意识到物理世界的信息是** AI** 能处理但还未被利用的？

孙洋： 对。而且这跟我的职业经历有一种冥冥之中的呼应。我读书读的是纯软件，但工作一路都在被"push "去做软硬结合：在 Amazon 做仓储物流系统，赶上了 Kiva 机器人收购；在 Google 做 Google Assistant 和 Google Home 集成；回国后在 Momenta 做自动驾驶的后装 **AI **硬件。所以很自然地，我意识到了这个结合点。

Kara： 24 年多模态基座模型还在很早期，你当时怎么就有这个勇气决定创业？

孙洋： 还是一些技术手感吧。我知道那个时候大家做的其实是"假多模态"------语言模型和视觉模型在第三个域做 projection 对齐，不是原生统一的架构。直到 **Gemini 2.0 **之后，才开始有原生多模态、统一 **tokenizer **的方案。

但从立项到产品到用户手里，硬件有一年的周期。你必须提前把技术 sense 、商业 sense 、产品 sense全部串起来，找到那个交叉点，提前押注。这是有一些笃定在里面的。

三、从账上只剩几万块，到"人生回看器"走红

树杨： 早期融资是怎么过来的？2024 年资本寒冬，你们怎么活下来的？

孙洋： 真的很难。2024 年那个市场，资本非常保守，不管美元基金还是人民币基金，大家都在求稳。我们又是在做极具创新但风险极高的事情。

投资人的核心质疑是：你的市场用户 GTM 在哪？那时候大家根本不理解** AI **硬件在整个 **AI **赛道的意义，认为你就是在做一个消费电子硬件卖货生意。你跟他讲 AI 怎么在里面扮演角色，他根本不想听。

我们团队还给我摆了一个小摆件------一个拍一下就会说话的宠物玩具，录着"不要 toVC ，不要 toVC"，放在我桌子上。融资最难的时候，我就拍一下，告诉自己别为了融资去妥协产品方向。

甚至有机构当场跟我说："你今天做眼镜，我今天就发TS。"我最终抵抗住了诱惑。**Looki **在第一年其实现金流差点断掉两次。最惨的时候，账上只剩几万块钱------工资都快发不出来，辗转腾挪才撑过去。

树杨： 作为第一轮投资人，Kara当时你们为什么会投？

Kara： 我们从** 2024 年上半年开始关注 AI **与不同形态硬件的结合，包括眼镜、耳机、手表、手环、智能戒指，当时也已经有北美初创公司在做吊坠形态，但更多是基于音频模态。孙洋是我们在全球聊了几十位 **AI **硬件创始人之后，唯一一个讲出与所有人认知都非常不同观点的创始人 。做 ToC 硬件，核心壁垒在于创始人的认知，因为这决定了他能在多长时间范围内持续做出领先的事情。

树杨： 早期团队是怎么搭建的？

孙洋： 这是从 2018 年回国后慢慢积累的信任资产。在摩拜、Momenta、美团的六七年里，我招了很多同学，大家有非常深的相互了解。出来创业时，他们选择跟我一起走，最初七八个人，都是共事过很长时间、信任度极高的伙伴。

早期没有太多市场的人，核心是搭产品。大家志同道合，都是多面手，伴随着公司一起成长。

四、产品定义：第一性原理推导出"拇指相机"形态

树杨： 你们是怎么定义出 Looki 这个形态的？

孙洋： 从第一性原理往下推：

首先，要在正面------侧面的视角跟人的视角偏差太大；其次，要在胸部以上------胸部以下不行。这就圈定了一个大致的范围。

然后我们看，在这个区域里，过百万销量的硬件 **form factor **有哪些------影石的拇指相机、眼镜、耳机。眼镜和耳机是成立的形态，但承载不了我们想做的"持续 always-on 感知"功能：眼镜要么太重，要么续航太短，用户没法长时间佩戴。最终我们看到了拇指相机的形态，最灵活，也更"无感"，就往这个方向做了。

外观设计上，我们刻意做了一个选择：第一代产品不追求隐形，要让大家一眼看出来------这是一个阳光的、可穿戴的 **AI **配饰，而不是一个偷拍设备。这也在量产上带来了很大难度。

树杨： 量产过程怎么解决的？供应链最难的地方在哪？

孙洋： 歌尔给了我们非常大的支持。这个产品的外形独特，硬件堆叠空间极其有限，防水工艺、各种模块都是挑战。我们在资金不充裕的情况下，在其他地方到处省钱，但在产品的BOM开模和项目节奏上没有省一分。这个冒险的决策，也是导致我们第二次现金流危机的原因------但最终歌尔和我们一起扛住了，"做难而正确的事"这种价值观，我们是一致的。

很多用户拿到第一代产品后都很惊讶：这是你们的第一代产品？做得这么精细成熟？这背后有歌尔非常大的助力。

五、隐私争议：每一次技术变革，都会经历这场讨论

树杨： 隐私是 **Looki **被争议最多的地方，你怎么看？

孙洋： 隐私可以拆成两部分讲。

第一部分：数据安全。 这个行业已经有成熟解决方案------数据加密、云存储合规、SOC2 认证。海外数据留海外，国内数据在国内，模型也用当地的，这方面我们非常合规，不需要担心。

第二部分：佩戴场景的"被拍"感。 这本质上是用户自己来控制的------Looki 有物理开关，随时可以摘下放进口袋。而且软件层面，所有拍摄内容默认存在本地硬件里，只有用户在 APP 里主动点击"上传并分析"，才会上云，上传前还可以再次筛选删除。

有意思的是，我们观察到：几乎所有关于隐私的质疑声音，都来自还没有买产品的人。 真正买了 Looki 的用户很少在群里质疑隐私，反而带着产品出门，被路人好奇追问，成为了最好的自来水推广者。我们调研发现，有 20%\~30% 的新用户是被朋友推荐购买的。

Kara： 其实手机第一次加摄像头、GPS 定位、人脸识别，当年都有巨大争议，但今天我们都已经完全接受了，甚至忘记了当年的争论有多激烈。AI 硬件的隐私讨论也会随着时间的推移，随着大家体验到真实价值，慢慢被接受。当benefit 大于 cost，用户自然愿意接受。

孙洋：说得对。Google Glass 当年被隐私问题喷得很惨，但今天MetaRay-Ban 已经卖了几百万副还在持续出货。10 年间，社会对可穿戴摄像头的接受度已经发生了根本性的变化------一方面是摄像头在社会中的渗透率显著提升，另一方面是抖音、TikTok 让大家习惯了日常生活化的拍摄记录方式。

六、产品三阶段：从"人生回看器"到"主动式AI"再到"预测未来"

Kara： 有第三方媒体把 **Looki L1 **叫做"人生回看器"，你认可这个定义吗？

孙洋： 在目前这个阶段是符合的，但这个名字不是我们起的，是媒体用户自己叫出来的。在我看来，**Looki **第一代产品会经历三个阶段：

第一阶段（过去时）： 记录回忆，回看过去，基于这些内容生成漫画、vlog，这就是现在大家体验到的"人生回看器"。

第二阶段（当下时）： 主动式 AI（Proactive AI）+ 长时运行** Agent**。**AI **实时感知当下发生的事情，主动给用户反馈。举个例子：你设定了"每天最多喝一杯咖啡"，当 **Looki **发现你拿起第二杯咖啡，就会实时提醒你。或者当 **AI **看到某个场景，自动给你关联推送一个相关的有趣知识点。这个功能很快就会上线。

第三阶段（未来时）： 基于过去的记录和对当下的理解，做Prediction（预测）。结合各类信息流，AI 能够前置地帮你做出判断和准备。

孙洋： 我觉得大家都在讲"主动式 AI"，已经快讲烂了。我们不想过度渲染，直接把产品给到用户，让大家自己去玩。

七、商业模式与壁垒：从卖货到信息流重构

Kara： 商业模式上你怎么思考？

孙洋： 会经历三个阶段。现在毫无疑问靠卖硬件，这是传统方式。接下来会有订阅，可能先从海外开始。最终我们想做的是重构信息流。

信息流经历了几个时代：门户网站（我有什么信息就 **po **上去）→搜索引擎（聚合信息，用户主动搜）→ 推荐引擎（根据用户行为做个性化推送，抖音、**TikTok **就是这个时代的代表）。

我们认为下一个时代是生成式引擎。推荐引擎依赖低维特征（停留时长、点击），生成式引擎需要高维理解。而高维理解的前提是**感知------Looki **就是在解决这个感知问题。

举个例子：你和朋友去了一家餐厅，AI 知道你们是朋友、今天是元宵节、你第一次来这家店、你的口味偏好......它不是基于规则推荐一个套餐，而是为你千人千面地生成一个专属内容或优惠。这就是从推荐逻辑跳跃到生成逻辑的质变。

孙洋： 做ToC的那个位置是独占的------你脖子这里的位置只有一个，不会同时戴两款类似的产品。而且视觉信号和声音信号是通用的，这就是一个通用入口。只要是通用入口，就没有理由做垂直细分，你占领了这个入口，壁垒就会随着时间自然积累。

八、AI 生态展望：模型分化、Agent 哲学与海啸将至

树杨： 2 月份一波模型集中发布，你怎么看现在的模型趋势？

孙洋： 模型开始明显分化了，路线清晰了：

一条是Coding 方向 ------Coding 能力决定了模型的智能天花板，这已经被验证；而且 Coding 的商业化路径是最清晰的，所以大量公司在做，这很合理。

另一条是原生多模态方向------Google Gemini、Qwen，以及据说将发布的 DeepSeek v4，都走向统一架构、原生多模态。

对于 Looki 来说，我们一直沿着多模态这条线走，随着模型能力越来越强、推理能力越来越好、成本越来越低，我们能吃到的红利会持续增加。

Kara： 关于 OpenClaw（Claude Computer Use） 和 Vibe Coding 你怎么看？

孙洋： OpenClaw 刚出来我就部署完玩了一遍，对我来说其实没有太多新鲜感，因为里面用的模块某种程度上都早已存在，只是被非常好地粘合在一起，加了一个双循环机制。

但 OpenClaw 最核心的意义在于打通了私有数据（Private Data） 。我在给 Kara 的那张 slide 里其实还有一条数据线的发展趋势：22-23年是Training Data ；23-24 年是 Public Data （Perplexity 那个时代）；24-25 年就应该是 **Private Data 进来了。OpenClaw本质上就是把你电脑里所有的私人数据结合起来，让 AI **真正做到"千人千面"。

孙洋： 更重要的是，OpenClaw 代表的是一种思想和技术框架 ：搭了一个场，让 AI能够在里面自由发挥。这和移动互联网时代的产品逻辑完全不同------以前做产品经理要写PRD ，针对某个垂类集中开发功能；但今天你给 AI 搭的是一个场，它表演什么节目是它自己的事。Looki 也是同样的逻辑。

孙洋： 还有一个范式变化很多人没意识到：以前搭一个场是为了人 ，看** DAU、MAU这些指标；今天搭一个场其实是给AI / Agent**的，让它在里面发挥价值。至于产生什么功能，是 Agent 自己来决定的。

Kara： 长周期来看，你怎么看人和 **Agent 的交互，以及 Agent **和 Agent 的交互？

所以 **Looki **尽力避免让用户去写 Prompt ，门槛太高了。整个世界都是 AI 的 Prompt------你经历了什么、看到了什么、听到了什么，都自动成为输入，AI 基于这些做出反应，你只需要点赞或点踩来校准。这是一个不断对齐的过程。

九、关于未来：AGI 已无限接近，AI 海啸将至

Kara ：站在 2026 年初，你对未来三到五年人和 **AI **的关系，有哪些非共识的预测？

孙洋： 社会接受度上，大家会越来越把 **AI **当成一种新型生物来看待，而不仅仅是聊天工具。正如 Sam Altman 说的，人类会出现"第三设备"------除了电脑和手机之外的第三个终端。

关于 AGI ：在我看来，今天已经无限接近** AGI **了。很多人觉得体验不好，其实是因为没有给 AI足够的context，或者没有合理使用。

但我最近也有一种矛盾感------我们上周刚决定，不再招初级工程师了，因为** AI **已经可以完全替代。这件事在硅谷已经非常激进地发生，**Twitter **裁了 40% ，**Block **也裁了 40%，而且是全岗位裁员，不只是代码岗。

再过两三年，可能 senior 工程师也不再需要了，设计、市场各类岗位也是如此。 我每天看到 **AI **进步，一边兴奋，一边在想：今天的应届毕业生怎么办？未来十年他们长大后，整个职业市场会是什么样子？

**Dario Amodei（Anthropic CEO）**说过一句话让我很有感触：**AI **是一场海啸，但人类还没有意识到。各行各业都会发生巨变。海啸过后，社会会重建成什么样子？我今天没有答案。但我能感受到这个趋势，可能再有两三年，大家的体感就会越来越强烈。

树杨： 这两年创业，你个人最大的成长是什么？

孙洋： 最大的成长是视角变了。以前在创业公司待着，总觉得这里不合理、那里不对，各种不满。真正操盘之后才发现------那些"不合理"，原来都是有道理的，因为你掌握的是全盘信息，而不是某一个模块的局部视角。

孤独是肯定有的。每个创业公司的 CEO 都孤独，有太多决策旁人不理解，有太多事情不能对外说。孤独的时候就跟AI 聊聊吧------我觉得这不是玩笑话，是认真的。

但不管 **Looki **最终成与败，创业这个过程本身就很值得。你在今天科技世界发展的最前沿，带着一个团队在摸索，在牌桌上参与这场游戏，这已经是人生中非常享受的事了。

求点赞，收藏，转发！

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

当全世界都在为 OpenClaw 和 Manus 这样的“赛博打工人”惊呼或恐惧时，真正的顶级掠食者已经悄然入局。

3 月 12 日，英伟达正式发布并开源了 120B（1200 亿）参数的 MoE 模型 Nemotron 3 Super。随之曝光的，还有一份令人胆寒的财务文件：英伟达已备好 260 亿美元（约合 1789 亿人民币）巨资，将在未来五年内全盘倾注于构建开源 AI 模型。卖铲子的人，开始亲自下场挖金矿了。

一、 暴力碾压 GPT：不搞闲聊，专为“赛博打工人”注入灵魂

Nemotron 3 Super 并不是一个用来写诗或讲笑话的聊天模型，它的各项指标都透着一股浓烈的“工业控制”味道。

它原生支持 100 万 token 的上下文窗口。在针对 OpenClaw 这类智能体控制能力的 PinchBench 测试中，它以 85.6% 的高分强势空降同类开源模型榜首。

同时，它的运转效率也实现了大幅度跨越。在 8k 输入与 64k 输出的特定运行设置下，它的推理吞吐量达到了对标竞品 GPT-OSS-120B 的 2.2 倍。

在实操基准测试中，它搭配 OpenHands 框架在软件工程基准 SWE-Bench 中跑出了 60.47% 的准确率（碾压 GPT-OSS 的 41.9%）。而在包含航空、零售和电信三大领域的 TauBench V2 复杂业务场景测试中，它同样交出了 61.15% 的高分成绩。

为了提升 Agent 面对复杂任务的稳定性，英伟达不仅给它灌入了 1.5 万个核心合成任务的终端操作轨迹，还在强化学习阶段引入了 PivotRL 技术，强行遏制 AI 在长程任务中的“推理漂移”。

【笔者观点】 这是一个极具杀伤力的信号：英伟达敏锐地察觉到，大模型的战争已经从“比谁嘴皮子溜（Chat）”升级到了“比谁干活稳（Agent）”。之前的文章我们提到，AI Agent 的核心是 Skills 和工具调用，而 Nemotron 3 Super 简直就是为解析复杂 JSON、操作终端命令量身定制的“最强数字大脑”。当其他大模型还在比拼虚无缥缈的“常识推理”时，英伟达已经开始给数字员工发放“高级电工证”了。谁掌握了最底层的 Agent 执行模型，谁就掌握了未来所有自动化软件的命脉。

二、 披着开源外衣的“特洛伊木马”：用软件锁死硬件生态

这款模型在技术架构上极其激进：为了在处理百万级上下文时兼顾效率与精度，采用了混合 Mamba-Transformer 架构，在具备线性时间复杂度的 Mamba-2 层中插入了 Transformer 全局注意力层。

而在模型规模的扩展上，为了解决传统混合专家架构的瓶颈，引入了 Latent MoE 技术，在潜空间降维来直接调用四倍数量的专家网络，实现更精细的分工。

此外，模型还原生应用了多 token 并行预测技术，通过共享权重设计，单次传递即可预测多个未来 token，极大提升了响应速度。

但最核心的杀招隐藏在硬件底层：Nemotron 3 Super 是在 25 万亿个 token 上，原生采用 NVFP4 格式进行预训练的。这意味着它从出生起，其基因就完全是为了适配英伟达最新的 Blackwell 架构（如 B200 芯片）而优化的。最终的结果是，它在 B200 芯片上跑出了比前代 H100 快整整四倍的推理速度。

【笔者观点】 这才是科技圈最反常识的降维打击！开源精神的初衷是“硬件不可知论（Write once, run anywhere）”，但英伟达的开源，是送给全行业一个极其精密、极其好用，但“只有插在自家主板上才能发挥全力的特洛伊木马”。表面上，老黄大方地送出了顶级的开源模型；实际上，这种原生绑定 NVFP4 的做法，直接把 AMD 和谷歌 TPU 等竞争对手的算力架构踢出了局。你以为你白嫖了一个 120B 的最强模型？错，你是被英伟达用这个模型逼着去买他家更贵的新一代显卡。

三、 260 亿美元的“极限拉练”：拿全世界开发者当免费 QA

在未来五年投入 260 亿美元搞开源模型，这笔钱甚至超过了许多国家级 AI 项目的总预算。英伟达在此次开源中毫无保留：全参数权重、训练配方、评估日志、部署手册全盘托出。

但官方通稿中泄露了这笔巨资的真实用途：英伟达将通过在超级数据中心里跑这些自家优化的开源模型，对计算、存储和网络性能进行全方位的压力测试。压榨出的宝贵数据，将被直接拿来反哺未来的硬件架构路线图，实现“由软件实操定义硬件进化”。

【笔者观点】 如果你觉得 260 亿是用来做慈善的，那就太天真了。这其实是一场让人脊背发凉的“终极阳谋”。英伟达为什么要自己做模型？因为现有的 AI 公司（哪怕是 OpenAI）在压榨算力极限方面，根本跟不上英伟达迭代硬件的野心。老黄不想等别人来测试他的芯片了，他要自己造出地表最吃算力的怪物，然后免费发给全世界的开发者去跑。全人类的开发者，都在拿着这套开源方案，不知不觉地充当英伟达下一代硬件的免费测试员（QA）。在 AI 时代，得生态者得天下，而英伟达正在用 260 亿美元，彻底买断未来十年的算力定义权。

👇 欢迎关注我的公众号

在 AI 爆发的深水区，我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码，获取每周硬核技术推文：

欢迎关注【睿见新世界】

做 MySQL 数据迁移、数据备份，怎么快速完成数据一致性对比？发现差异后怎么高效修复？很多 DBA 仍在通过脚本和人工操作完成数据校验，步骤繁琐且易出现人为误差。

今天就给大家带来NineData 数据库对比功能的详细实操教程，5 步就能完成 MySQL 数据从对比、发现差异到修复、验证的全流程，全流程可视化操作，不用写复杂脚本，新手也能轻松上手！

前提准备

无需本地安装复杂软件，通过 NineData 平台即可实现全流程操作，其数据对比功能兼容 MySQL 全主流版本，且支持免费使用，提前准备好需要对比的源、目标数据源信息即可。

五步实操，搞定 MySQL 数据对比 + 修复

步骤一：一分钟快速配置对比任务

进入 NineData 工作台，选择「数据库对比」> 「数据对比」>「创建数据对比」，依次填写任务名称，选择源、目标 MySQL 数据源，配置对比频率（一次性对比 / 周期性对比）、对比方式（全量数据对比 / 快速对比），确认映射关系后完成预检查，即可进入下一步，整个配置过程最快仅需 60 秒即可完成。

步骤二：启动任务，查看对比结果

任务启动后，NineData 会自动执行对比，任务完成后，在对比详情页面可清晰看到任务状态、源 / 目标数据源信息，以及每张表的对比结果 —— 包括源记录数、目标记录数、是否一致、差异数量，结构对比还能精准定位到具体不一致的对象类型（表、索引、约束等）。

步骤三：一键生成 SQL，修复数据 / 结构差异

发现差异后，无需手动编写 SQL，NineData 会自动为不一致内容生成修复 SQL（新增、更新、删除类 SQL 语句），在对比详情页点击操作按钮，即可查看并复制修复语句，在目标库执行即可完成修复，全流程一键操作，省时又避免人工编写的错误。

步骤四：验证修复结果，确保数据一致

修复完成后，可在 NineData 中重新启动对比任务，或在原有任务中点击「立即对比」，验证修复后的源、目标数据是否一致。对比结果会实时更新，清晰展示所有表 / 结构的一致性状态，确保无遗漏差异。

步骤五：查看日志和监控，追溯全流程

NineData 支持查看对比任务的完整日志和监控指标，包括任务执行时间、对比进度、差异详情、修复记录等，所有操作可追溯、可审计，不仅能排查问题，还能满足企业内部管理与操作追溯需求。

实操亮点

整个过程全流程可视化操作，无需依赖本地计算机资源，即使是1TB 以上的 MySQL 海量数据，也能基于 NineData 的服务器集群快速处理；支持周期性对比，可设置定时任务，实现 MySQL 数据的日常自动校验，无需人工值守。

不管是数据迁移后的一次性校验，还是容灾备份的日常周期性校验，用 NineData 这 5 步就能轻松搞定，轻松实现 MySQL 数据对比 + 修复的自动化、高效化。

总结

通过 NineData 平台，即可按照上述教程完成 MySQL 数据对比与修复，实现数据一致性校验的自动化与高效化，解锁 MySQL 数据对比的高效方式，支持\
核心对比功能，让数据一致性校验更简单！

多数关于 LangGraph 和 Semantic Kernel 的比较文章已经过时。过去六个月里，两个框架分别进行了重大的更新，所以本文将梳理的是实际发生的变化、当前的代码形态，以及如何进行技术选型。

2026 年构建 Python AI Agent 的现实状况是：都足够成熟的可选框架有两个，多数流行比较文章发布之后，两个框架都经历了重要更新：

• LangGraph 在 2025 年 10 月发布 v1.0。
• LangChain 1.0 的 create_agent 底层已经运行在 LangGraph 运行时之上，LangGraph 事实上成了 LangChain 生态的执行引擎。
• Semantic Kernel 在 v1.28.1 中为 Python 加入了一等 MCP 支持，SDK 内原生兼任 MCP 客户端和服务端。

如果正在读的比较文章还在说 LangGraph"不稳定"或 Semantic Kernel"和 .NET 绑定太深"，那它描述的已经不是当前现实。

本文依据 LangGraph 官方文档、Semantic Kernel 官方文档以及两个框架的变更日志写成。

一句话决策规则

有状态、持久、可恢复的 Agent 工作流，需要显式控制：LangGraph

协议优先、插件组合、可互操作的 Agent 平台：Semantic Kernel

两种架构有着截然不同的思维模型

LangGraph：图运行时

LangGraph 把 Agent 系统建模为一张有状态图，开发者可以显式定义其中的状态、节点与边。节点是 Python 可调用对象或子图，边是状态转换，状态本身则是一个类型化对象，在图的每一步流转并更新。这不是内部实现细节而是日常编程直接面对的核心抽象。

LangGraph v1 官方文档围绕三个核心概念组织整个框架的叙述：持久执行、可控性、人机协作。崩溃后从最近的检查点恢复工作流、在流程中插入人工审查步骤、将执行分支到并行子 Agent——这些都是一等操作，不是需要绕路才能实现的变通方案。

但是自 v1 起，LangChain 的

create_agent

运行在 LangGraph 运行时之上，技术栈有了明确的分层：用

create_agent

处理标准工具调用循环；当需要自定义工作流拓扑时，下沉到原始 LangGraph。

Semantic Kernel：内核-插件中间件

Semantic Kernel 的起点是 Kernel 抽象：一个容纳 AI 服务、插件和函数的容器。插件是暴露给模型和 Agent 的函数组，来源可以是原生 Python 代码、提示模板或外部导入的 schema。

SK 官方 agent-functions 文档的原话是：

"Any Plugin available to an Agent is managed within its respective Kernel instance — this enables each Agent to access distinct functionalities based on its specific role."

编排逻辑来自 Agent 自行选择函数、Planner 排列能力调用的顺序，而非开发者预先画好的图拓扑。

这种设计让 Semantic Kernel 更接近 AI 中间件的定位：开发者定义 Agent 的能力边界，具体的调用编排交给函数调用机制和 Agent 框架。

架构差异

🔷 主要抽象LangGraph → 类型化状态图（节点 + 边）Semantic Kernel → Kernel + 插件 + Agent

🔷 工作流控制LangGraph → 开发者显式定义拓扑Semantic Kernel → 由 Agent 函数调用涌现

🔷 状态管理LangGraph → 一等类型化状态 + 检查点Semantic Kernel → 外部化，由开发者自行管理

🔷 最佳思维模型LangGraph → Agent 的持久状态机Semantic Kernel → 具备可组合能力的 AI 中间件

同一个 Agent 在两个框架中的实现的代码示例

把架构差异落到代码层面最直观。下面用同一个场景——带记忆和系统提示的多轮天气助手——分别在两个框架中实现。

LangGraph——带检查点的天气 Agent

 pip install -U langgraph "langchain[openai]"

 from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import InMemorySaver
from langchain.chat_models import init_chat_model

# --- 工具：纯Python函数 ---
def get_weather(city: str) -> str:
    """Get the current weather for a given city."""
    # 在生产环境中替换为真实的API调用
    return f"It's sunny and 28°C in {city}."

# --- LLM ---
model = init_chat_model("openai:gpt-4o-mini", temperature=0)

# --- 检查点器启用持久的多轮记忆 ---
# 在生产环境中将InMemorySaver替换为SqliteSaver或PostgresSaver
checkpointer = InMemorySaver()

# --- 编译图Agent ---
agent = create_react_agent(
    model=model,
    tools=[get_weather],
    prompt="You are a helpful weather assistant.",
    checkpointer=checkpointer,
)

# --- thread_id将此对话绑定到持久检查点 ---
config = {"configurable": {"thread_id": "user-session-1"}}

# Turn 1
response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is the weather in Mumbai?"}]},
    config=config,
)
print(response["messages"][-1].content)

# Turn 2 — Agent通过检查点器自动记住上下文
followup = agent.invoke(
    {"messages": [{"role": "user", "content": "How about Delhi?"}]},
    config=config,
)
 print(followup["messages"][-1].content)

create_react_agent

在底层编译出一个包含模型-工具循环的

StateGraph

。

checkpointer

在每一步持久化状态，相同的

thread_id

会自动从上次保存的位置恢复。如果进程在运行中崩溃用同一个

thread_id

重启即可从最后的检查点继续，持久性由运行时负责，不需要业务代码操心。

Semantic Kernel——带 Plugin 的天气 Agent

 pip install semantic-kernel

 import asyncio
from semantic_kernel import Kernel
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.connectors.ai.open_ai import (
    OpenAIChatCompletion,
    OpenAIChatPromptExecutionSettings,
)
from semantic_kernel.connectors.ai import FunctionChoiceBehavior
from semantic_kernel.functions import kernel_function
from semantic_kernel.contents import ChatHistory

# --- Plugin：带有@kernel_function装饰器的类 ---
class WeatherPlugin:
    @kernel_function(name="get_weather", description="Get the weather for a city.")
    def get_weather(self, city: str) -> str:
        # 在生产环境中替换为真实的API调用
        return f"It's sunny and 28°C in {city}."

# --- Kernel：持有服务和插件 ---
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(ai_model_id="gpt-4o-mini"))

# --- 执行设置：启用自动函数调用 ---
settings = OpenAIChatPromptExecutionSettings()
settings.function_choice_behavior = FunctionChoiceBehavior.Auto()

# --- 注册插件 ---
kernel.add_plugin(WeatherPlugin(), plugin_name="WeatherPlugin")

# --- Agent：kernel + 指令 ---
agent = ChatCompletionAgent(
    kernel=kernel,
    name="WeatherAssistant",
    instructions="You are a helpful weather assistant.",
)

async def run_agent():
    # ChatHistory需要在多轮之间自行维护
    history = ChatHistory()

    # Turn 1
    history.add_user_message("What is the weather in Mumbai?")
    async for message in agent.invoke(history):
        print(f"Agent: {message.content}")
        history.add_message(message)

    # Turn 2
    history.add_user_message("How about Delhi?")
    async for message in agent.invoke(history):
        print(f"Agent: {message.content}")
        history.add_message(message)

 asyncio.run(run_agent())

Kernel

充当依赖容器，集中管理 AI 服务与插件。

@kernel_function

装饰器让 Python 方法可被模型自动发现和调用。

FunctionChoiceBehavior.Auto()

指示模型按需触发函数。记忆存放在

ChatHistory

对象中，由调用方自行维护并在每次调用时传入，运行时不负责持久化。

最能揭示差异的 6 行代码

 # LangGraph — 运行时拥有持久性
 checkpointer=InMemorySaver()
 config= {"configurable": {"thread_id": "session-1"}}
 agent.invoke(messages, config)  # 自动从最后一个检查点恢复

 # Semantic Kernel — 开发者拥有状态
 history=ChatHistory()
 history.add_user_message("...")
 agent.invoke(history)  # 显式地传递和维护状态

LangGraph 中，持久性是运行时的职责；Semantic Kernel 中，状态管理是开发者的职责。两种取向无所谓对错它们对应的是不同的应用模型。

协议支持：MCP 和 A2A

协议层面是 Semantic Kernel 近期变化最大的方向。

Semantic Kernel——Python SDK 中的原生 MCP

SK 官方 MCP 公告的原话：

"Python support for MCP has arrived… SK Python can act as both an MCP Host and an MCP Server, support multiple transport methods (stdio, SSE, WebSocket), chain multiple MCP servers together, and expose SK functions or agents as MCP servers."

不是适配器，也不是社区插件，v1.28.1 开始已经是一等 SDK 支持。对于需要通过标准协议跨服务边界编排工具和 Agent 的团队来说，这是一次实质性的架构升级。

LangGraph——部署边缘的 MCP

LangGraph 的 MCP 思路侧重部署层面而非进程内集成。部署到 LangGraph Platform 后，每个 Agent 会自动在

/mcp

端点暴露为 MCP 可访问的服务，无需额外代码。自托管场景下则通过

langchain-mcp-adapters

包集成。

如果需要在 Python 进程内部使用 MCP 语义，SK 更合适；如果 Agent 的定位是被其他客户端通过 MCP 消费的已部署服务，LangGraph 更契合。

稳定性

看一下官方文档当前的说法。

LangGraph v1（2025 年 10 月）：官方 v1 发布说明确认核心图 API 和执行模型未发生变化，主要的迁移事项是将

langgraph.prebuilt

中的

create_react_agent

标记为弃用转向 LangChain 的

create_agent

。LangGraph 1.0 公告明确承诺 2.0 之前不引入破坏性变更。

Semantic Kernel 1.x：大部分架构层面的断裂集中在 1.0 版本：命名空间重组、API 重命名、上下文变量变更。2025 年上半年 SK 路线图及后续版本呈现出增量式、累加式的演进模式，以定向修复为主，不再出现结构性断裂。

"LangGraph 每个版本都会破坏兼容性"的旧说法已不再成立。两个框架目前都处于稳定性优先的阶段。

何时选择哪个

✅ 选择 LangGraph ：

• Agent 逻辑涉及非简单的分支、重试、人工审查或审批步骤，这些场景受益于显式的图拓扑。
• 工作流需要持久执行——在崩溃中存活、从检查点恢复，并保留可审计的步骤历史。
• 团队已深入 LangChain 生态，希望沿着 create_agent → LangGraph 的技术栈获得清晰的升级路径。
• 需要在节点级别观测执行流如何穿过工作流，要求细粒度的可观测性。

✅ 选择 Semantic Kernel 当：

• 正在构建平台或 SDK，能力以插件形式组合，不同 Agent 各自消费不同的工具集合。
• MCP 或 A2A 互操作性是核心需求，且希望在 Python SDK 中原生支持，而非依赖外部适配器。
• 团队已采用 DI / 面向服务的架构，kernel-plugin 模型与既有设计天然契合。
• 倾向于轻量部署，不想引入专用的编排运行时，状态交由外部系统管理。

总结

如果 Agent 需要表现得像一台持久状态机，用 LangGraph。如果 Agent 需要表现得像一个协议感知的平台组件，用 Semantic Kernel。

希望这篇有所帮助。

https://avoid.overfit.cn/post/06c77d333efe42b0817c37552dede26d

by TheProdSDE

最近，一个连名字都改了两次的开源项目 OpenClaw 火得一塌糊涂。它能像真人一样自动操作你的电脑：发邮件、投简历甚至做交易。这让许多人惊呼“AI 已经成精了”，并由此引发了巨大的职业焦虑。

但在这些神乎其技的表象之下，究竟隐藏着怎样的底层逻辑？当我们剥开 OpenClaw、Manus 以及那些看似高深莫测的 Skills、RAG、MCP、Memory 的外衣，你会发现，所谓的“硅基生命”，本质上不过是一场极其精密的工程学拼图。

一、 扯下“无所不知”的遮羞布：大模型本质只是个“失忆的静态文件”

很多人觉得 ChatGPT 或 DeepSeek 像是一个坐在云端无所不知的智者。但客观事实是：大模型本质上就是一个躺在磁盘里的超大静态文件（比如 gpt-4.bin 或 deepseek-v3.bin），里面塞满了训练时固化的参数。

要让它工作，必须通过“推理服务”将它加载到内存中，并对外暴露 HTTP 接口。但这个服务是绝对无状态的。你每一次发消息，对大模型来说都是生命中的“第一次”。为了让你觉得它有“记忆”，工程师发明了 Memory（记忆管理） 机制：在每次你提问时，系统会偷偷把你之前的聊天记录（短期记忆），以及更早之前对话的压缩摘要（长期记忆），全部拼接成一个超长的“上下文”，一起塞给大模型。

【笔者观点】 这其实是一个极其反常识的真相：AI 根本没有记住你，它只是一个算力极高但记忆力只有 7 秒的“金鱼”。你以为你在跟它交心，实际上是背后的代码在每一次对话前，都在疯狂地给它“递小抄”。这也意味着，未来大模型赛道最烧钱、最能卡脖子的地方，根本不是大模型本身的智商，而是“上下文窗口”的吞吐量。谁能把这段“小抄”做得更长、更精准且成本更低，谁就掐住了 AI 商业化的命门。

二、 拯救“缸中之脑”：用 RAG 喂真理，用 MCP 装上机械臂

如果只是个带记忆的聊天框，AI 顶多是个好用的搜索引擎。因为它在训练完成的那一刻，知识库就彻底锁死了，它不知道今天的新闻，更不可能知道你公司内部的保密文档。

为了打破这种信息隔离，RAG（检索增强生成） 诞生了。它通过向量数据库（如 Milvus），将你的内部文档转化为多维向量，利用语义相似度匹配出相关知识，再喂给大模型做开卷考试。

但这还不够，大模型依然只是个没有手脚的“缸中之脑”。于是，MCP（模型上下文协议） 带着它的插件体系登场了。MCP 在大模型和外部世界之间建立了一套基于 JSON 格式的黑话：大模型输出特定格式的 JSON（比如调用“发送邮件”工具），外部的 MCP Host 收到后执行真实操作，再把结果返回给大模型。

【笔者观点】 MCP 的普及正在悄无声息地判处传统软件死刑。过去我们做软件，是做给人用的 GUI（图形界面）；而现在，MCP 强行将所有软件降维成了给 AI 调用的 API 接口。紧迫感在于，如果你所在公司的软件产品至今还没有接入或提供 MCP 插件，那么在未来的 AI Agent 时代，你的产品将连被 AI “看一眼”的资格都没有，直接在应用生态的孤岛中等死。

三、 从“给扳手”到“给 SOP”：Skills 才是区分牛马与废柴的分水岭

现在，AI 有了脑子（大模型）、有了记忆（Memory）、能查资料（RAG）、还长出了手脚（MCP 插件）。但现实是骨感的：如果你把一堆钳子和扳手扔给一个大学生，他依然修不好一辆汽车。

为什么？因为他缺乏经验和流程。这就是 Skills（技能/操作指南） 存在的意义。以排查线上事故为例，MCP 只是赋予了 AI 查监控、看日志的“动作”；而 Skills 则是极其严谨的 SOP（标准作业程序）：第一步必须先看监控确认影响面，第二步再去查日志，第三步视情况回滚。

【笔者观点】 很多人盲目迷信“大模型能力越强越好”，这完全是本末倒置。在真实的商业落地中，决定一个 AI 是能干活的高效员工，还是只会胡言乱语的废柴，核心根本不在于底层的参数量，而在于你喂给它的 Skills 有多扎实。大公司真正的核心资产，绝不是弄了一个多牛的开源模型，而是他们多年积累下来的、能够被结构化写进 Skills 里的行业 Know-How。谁掌握了最优质的工业级 SOP，谁就能在 Agent 时代榨取最大的剩余价值。

四、 OpenClaw 的裸奔狂欢：将“赛博杀手”直接放生到你的 C 盘

当把大模型（大脑）、Memory（记忆）、RAG（知识）、MCP（手脚）和 Skills（经验）全部拼装在一起，我们就得到了一个能自主行动的智能工具人——​AI Agent（智能体）​。

理解了这些，再来看最近爆火的 OpenClaw 和前阵子的神级产品 Manus，一切就豁然开朗了。它们的本质没有任何区别，都是高级的 AI Agent。但致命的差异在于部署环境：Manus 为了安全，把这个无所不能的“赛博黑客”关在了远端沙箱虚拟机里；而 OpenClaw 主打一个野路子的美，直接在你本地电脑上运行。

它确实能帮你一键投简历、回邮件，但这也意味着，你把本地 C 盘的最高生杀大权，毫无保留地交给了它。

【笔者观点】 极度危险，且不加掩饰。OpenClaw 的爆火证明了大众对“自动化替身”有着近乎疯狂的渴求，但这种渴求完全掩盖了安全常识。将一个具备完整 MCP 操作权限的 Agent 直接放生到本地环境，无异于给一个三岁小孩发了一把上了膛的真枪，顺便还绑定了你的工资卡。技术祛魅之后我们必须承认：当下的 Agent 赛道，技术天花板早就摸到了，真正能活下来的伟大公司，绝不是那些让 Agent 跑得最快的，而是能够为 Agent 打造出最坚固“安全牢笼”的执剑人。

👇 欢迎关注我的公众号

在 AI 爆发的深水区，我们一起探索真正能穿越周期的技术价值。
微信搜索 【睿见新世界】 或扫描下方二维码，获取每周硬核技术推文：

欢迎关注【睿见新世界】

近一年，AI 编程工具进入 Agent（智能代理）时代。除了常见的 Claude Code、Cursor、Copilot 之外，开发者社区也开始讨论另一个热门项目：OpenClaw。

很多开发者都会问：

Claude Code 和 OpenClaw 是不是同一种工具？
两者有什么区别？
哪个更适合开发者？
在国内怎么稳定使用？
这篇文章会从 专业角度 + 通俗解释，系统讲清楚两者的区别，以及国内稳定使用的最佳方案。

一、Claude Code 是什么？

Claude Code 是 AI 公司 Anthropic 推出的 AI 编程代理工具（AI Coding Agent），可以直接在终端中参与软件开发流程。

简单理解：

Claude Code = AI 编程助手 + 自动执行开发任务

开发者可以直接通过自然语言让它完成开发任务，例如：

帮我写一个 Node.js 登录系统
Claude Code 可以：

理解整个代码仓库
自动写代码
修改文件
运行测试
提交 Git
甚至可以持续执行复杂开发流程，因此被很多开发者称为：

“AI工程师雏形”

据报道，Claude Code 在实际开发中可以大幅提升工程效率，并被用于自动化软件开发流程。

二、OpenClaw 是什么？

OpenClaw 是一个 开源 AI Agent 框架，本质是一个可以部署在本地或服务器上的 个人 AI 助手系统。

它的核心能力包括：
连接 Claude / GPT / Gemini 等模型
自动执行任务
调用各种工具
长期记忆
自动化工作流

例如：

你可以让 OpenClaw：
自动写代码
处理邮件
管理任务
在 Telegram / Discord / WhatsApp 中交互
OpenClaw 本质上是一个 可扩展 AI 代理系统，而不是单一 AI 工具。

它可以运行在：
本地电脑
云服务器
私有服务器
甚至可以 24小时自动运行 AI 代理。

三、Claude Code 和 OpenClaw 核心区别

很多人会把这两个工具混淆，但其实定位完全不同。

下面是最直观的对比：

简单理解：
Claude Code AI 编程助手
OpenClawAI 自动化系统

四、两者工作方式的区别

Claude Code
Claude Code 更像：开发者、Claude Code、代码修改

核心功能：

• 写代码
• 修 Bug
• 分析项目

主要用于：

• 软件开发
• 编程辅助
• AI开发

OpenClaw
OpenClaw 更像：用户、OpenClaw Agent、Claude / GPT / 工具、执行任务

OpenClaw 会：

• 调用 AI 模型
• 自动规划任务
• 执行工具
  例如：创建网站、OpenClaw规划步骤、Claude写代码、自动部署

它更像：
AI员工系统

五、Claude Code 和 OpenClaw 能一起用吗？

答案是：
可以。

实际上很多开发者是这样使用的：OpenClaw（任务管理）、Claude Code（写代码）

OpenClaw 负责：

• 任务规划
• 自动执行
• 工具调用

Claude Code 负责：

• 写代码
• 修改代码
• 调试
  这种组合模式被很多开发者称为：
  AI Agent 编程架构

六、两者适合什么人？

Claude Code 更适合
程序员
AI开发者
技术团队

用途：
编程
调试
架构分析

OpenClaw 更适合
自动化开发者
AI Agent研究者
AI创业团队

用途：
自动化工作流
AI助手
AI员工

七、在国内可以用 Claude Code 和 OpenClaw 吗？

答案是：
可以，但不能直接使用。

原因是：
Claude、OpenAI 等 AI 服务在中国大陆访问会受到网络限制。

常见问题：
Claude 登录失败
API 超时
CLI 连接失败
GitHub 访问慢

如果网络不稳定：
AI任务会中断
Agent运行失败
API调用频繁报错

**因此很多开发者都会使用：
跨境网络专线**

八、国内稳定使用 Claude Code / OpenClaw 的方案

目前开发者常用方案有三种：
方案一：海外服务器
最常见方法：
国内电脑
↓
连接海外服务器
↓
运行Claude Code

优点：
技术简单

缺点：
延迟高
文件同步麻烦

方案二：API中转
通过第三方代理调用 API。

缺点：
不稳定
存在安全风险
经常限流

方案三：SD-WAN国际网络专线（最稳定）**

很多 AI团队和出海公司 都会使用 SD-WAN专线网络。

网络结构：公司网络、SD-WAN专线、海外节点、Claude / OpenAI / GitHub

例如 OSDWAN 这样的跨境网络服务商，可以提供：
全球 50+ 数据中心
200+ POP节点
AI工具加速
SaaS访问优化

可以稳定访问：
Claude Code
OpenClaw
OpenAI
Cursor
GitHub

对于 AI开发团队、跨境公司、外贸企业 来说，这种网络方案会比普通网络稳定很多。只要连接了就可以稳定访问海外网络了。

九、为什么 AI 开发团队越来越重视网络环境？

AI开发越来越依赖海外服务：

例如：
Claude
OpenAI
GitHub
Hugging Face
Vercel

如果网络不稳定，就会出现：
代码任务中断
API调用失败
Agent任务执行失败
因此很多 AI 团队会直接使用 企业级跨境网络解决方案，例如 OSDWAN SD-WAN专线，可以稳定访问AI工具。具体优势如下：

一、稳定连接，避免AI使用中断与报错

OSDWAN采用运营商级国际专线与 SD-WAN 智能调度，有效降低跨境网络中的丢包与抖动，确保AI 网页端访问更顺畅，避免长时间使用掉线、异常等问题，特别适合高频调用、持续在线的AI使用场景。

二、长期可用，避免频繁封控与限制

海外AI平台对网络环境和IP风控非常严格，使用不稳定的网络和不纯净的IP容易被识别并限制。OSDWAN提供合规跨境网络专线，稳定可持续的网络出口、长期一致的访问环境，可降低因环境异常导致的访问受限风险。

三、访问更快，显著降低延迟

OSDWAN在全球的数据中心节点50个，POP节点超过200个，覆盖全球300+国家地区，可以有效提高连接稳定性和响应速度，让AI代码生成告别“只会跑不会快”的困境。

四、支持多终端与统一管理

OSDWAN支持多设备同时接入，团队统一网络出口，提供企业级管理配置，无需每个成员单独配置复杂环境，即可让团队稳定使用海外 AI 服务，提升整体效率与协作体验。

十、总结

Claude Code 和 OpenClaw 是 两个完全不同定位的 AI 工具。

简单总结：

Claude Code
AI编程助手
官方工具
专注开发

OpenClaw
开源AI Agent框架
自动化能力更强
可构建AI员工

而对于国内开发者来说，想稳定使用这些 AI 工具，核心只有一个：稳定的国际网络环境

像 OSDWAN 这样的跨境网络服务商，可以帮助企业稳定访问 Claude、OpenAI、GitHub 等 AI工具，从而大幅提升开发效率。

OSDWAN是国内专业的跨境网络专线服务商，专注为AI开发者与出海企业提供稳定、低延迟的海外网络加速方案。

可解决ChatGPT、Claude code、Gemini等海外AI工具的使用限制，轻松完成账号注册并稳定使用，让AI代码生成告别“只会跑不会快”的困境，提高业务效率。

支持企业定制带宽，让每一次模型训练、代码生成与实时推理，都稳定如本地部署。

摘要

在现代数据仓库架构中，ODS（Operational Data Store，操作型数据存储层）承担着承接业务系统数据、保持最细粒度事实、并为后续数据建模提供稳定输入的关键角色。它既是数据进入数仓体系的第一站，也是数据质量与可追溯能力的第一道防线。

一个设计良好的 ODS 层，不仅需要解决数据接入方式（全量、增量、CDC）、分区与生命周期管理，还必须在幂等、去重、晚到数据处理以及历史数据建模等方面形成清晰规范。否则，一旦问题被“推迟到下游”，将会在 DWD、DWS 层被无限放大，导致维护成本指数级上升。

作为数据湖仓设计与实践系列文章第 3 篇，本文将系统梳理 ODS 层在实际落地中的关键设计原则，包括接入策略选择、分区与成本控制、数据稳定性设计、历史数据管理以及 ODS 的职责边界，并结合实践经验总结常见陷阱与治理方法，帮助数据团队在系统早期就打下可持续演进的基础。

一、ODS 层在数据仓库中的位置与作用

在典型的数据仓库架构中，数据通常会经历 Source → ODS → DWD → DWS → ADS 的处理链路。ODS 层主要承担以下职责：

• 承接来自业务系统的原始数据
• 对数据进行基础标准化处理
• 保留最细粒度事实
• 提供稳定、可追溯的数据来源

ODS层架构图

换句话说，ODS 更像是一个“原始事实存储层”：
它既不像业务系统那样用于事务处理，也不像数仓公共层那样承担复杂建模任务，而是作为一个稳定、可重建的数据基线存在。

从数据仓库设计原则来看，ODS 层通常会保持与源系统结构较高的一致性，只进行必要的数据清洗与标准化处理，例如类型统一、编码转换或非法值处理等。这样做的目的，是保证数据在进入数仓后仍然能够追溯回源系统。

如果这一层设计不当，后续所有建模层都会被迫承担额外的数据修复与清洗逻辑，最终导致数据平台复杂度失控。

ODS 工作原理

二、接入策略：全量 / 增量 / CDC 如何选择

在 ODS 层建设中，第一个必须解决的问题是 数据如何接入。常见的三种方式分别是：全量抽取、增量抽取以及 CDC（Change Data Capture）。

1 全量抽取：最简单但成本最高

全量抽取是最直接的方式，每次同步都读取整张表并重新加载。

这种方式适用于以下场景：

• 小规模维表
• 低频更新表
• 初始数据加载
• 早期 PoC 或系统试运行

其最大优点是逻辑简单、实现成本低，但随着数据规模增长，计算与存储成本会迅速增加。因此在生产系统中，全量抽取通常只作为初始化方案。

2 增量抽取：最常见的同步方式

当数据量逐渐增大时，团队通常会采用增量抽取，例如通过以下字段进行同步：

• 更新时间字段（update_time）
• 自增 ID
• 版本号字段

这种方式适用于 日级或小时级同步场景。

但增量同步有一个非常典型的风险：

增量字段并不一定可靠。

例如：

• 上游系统没有更新更新时间
• 历史数据回填
• 不同系统时区不一致

因此在实际工程中，通常会增加两种补偿机制：

• 水位线（watermark）管理
• 回看窗口（lookback window）

例如：同步当天数据时，同时回查近三天的数据并做去重校验。

3 CDC：实时链路的核心技术

对于交易系统或实时业务来说，仅依赖增量字段往往无法满足需求，这时就需要 CDC（Change Data Capture）。

CDC 可以直接捕获数据库日志中的变化事件，例如：

• Insert
• Update
• Delete

因此能够实现分钟级甚至秒级同步。

但 CDC 也带来新的挑战：

• Binlog 位点管理
• 链路断点恢复
• DDL 变更兼容

例如，当源表新增字段时，ODS 表结构是否允许自动扩展，就需要提前设计。

4 最常见的生产模式

在实际企业环境中，最常见的组合是：

初始化全量 + 日常 CDC / 增量同步

流程通常如下：

1. 首次全量加载历史数据
2. 记录同步位点
3. 切换到 CDC 或增量同步
4. 定期进行数据对账

这样既能保证历史完整，又能实现高效更新。

三、分区与生命周期：ODS 成本控制的关键

在 ODS 层设计中，分区策略几乎决定了 80% 的查询性能与存储成本。

1 时间分区是第一原则

绝大多数 ODS 表都会按时间字段进行分区，例如：

dt=2026-03-10

这样做有三个好处：

1. 方便按天重跑数据
2. 方便历史归档
3. 控制扫描范围

很多团队在早期没有设计分区，等数据规模达到 TB 或 PB 级时再重构，成本会非常高。

2 是否需要二级分区

对于超大规模表，可以增加第二层分区，例如：

dt + tenant
dt + region
dt + biz_line

但二级分区过细可能导致：

• 小文件问题
• 分区数量爆炸
• 元数据压力

因此只建议在 多租户或超大表场景中使用。

3 生命周期与冷热分层

ODS 数据通常会根据价值划分生命周期，例如：

此外，企业通常会设置 ODS 回放窗口，例如：

保留 90 天原始数据，以支持历史回放与排障。

如果只保留 7 天数据，一旦发生历史问题，将几乎无法追溯。

四、幂等、去重与晚到数据处理

ODS 层最重要的目标之一是：

让数据接入变得稳定、可控、可恢复。

1 幂等设计

幂等意味着：

同一任务重复执行不会产生重复数据。

常见实现方式包括：

• 分区覆盖
• 主键去重
• merge/upsert

如果系统不具备幂等能力，团队将不敢重跑任务，这会严重影响运维能力。

2 去重策略

每张 ODS 表都必须明确：

唯一键是什么？

例如：

• 业务主键
• 复合键
• event_id

对于日志类数据，通常会生成 hash_key 或 event_id 来保证唯一性。

3 晚到数据处理

在真实业务中，数据延迟是非常常见的。例如：

• 上游系统补录
• 网络延迟
• 消息积压

因此增量同步通常需要设置 回看窗口，例如：

每天同步时回看最近3天数据

并通过主键去重保证数据一致。

4 水位线管理

水位线是增量同步的核心机制，它必须满足三个条件：

• 可持久化
• 可审计
• 可回退

例如：

last_sync_time = 2026-03-10 12:00

当任务失败时，可以从任意历史水位重新恢复。

五、历史数据管理：快照、拉链与变更明细如何选择

在数据仓库建设中，历史数据的保存方式会直接影响查询能力、存储成本以及报表口径的一致性。如果设计不当，往往会导致历史报表无法复现、指标口径长期对不齐。因此，在 ODS 层及其上游建模阶段，必须提前明确历史数据的管理策略。

常见的历史数据管理方式主要有三种：快照（Snapshot）、拉链表（SCD2）以及变更明细（Change Log）。

1 快照（Snapshot）

保存某个时间点的完整状态，例如：

• 每日账户余额
• 商品库存
• 用户等级

优点：

• 任意日期状态都可以直接查询

缺点：

• 存储成本高

2 拉链表（SCD2）

拉链表记录数据生效区间，例如：

start_dt
end_dt
is_current

适用于：

• 用户地址变化
• 组织结构变化
• 会员等级变化

相比快照，它能节省大量存储空间。

3 变更日志（Change Log）

这种方式保留每一次变更事件，常见于：

• CDC 原始数据
• 行为日志
• 审计系统

优点是记录最完整，但需要额外计算才能得到最终状态。

选择策略的“三个关键问题”

在决定使用哪种历史建模方式时，通常需要先回答三个问题：

第一，你需要查询的是“某个时间点的状态”，还是“完整的变更过程”？

如果业务更关心某一天的最终状态，例如每日账户余额、商品库存或用户等级，那么快照表会更合适；如果需要记录完整的变化轨迹，例如用户信息修改、组织架构变化等，则更适合使用拉链表或变更明细。

第二，查询频率和性能要求如何？

如果历史状态查询非常频繁，并且对查询性能敏感，快照表通常能提供更好的查询效率，因为每个时间点的数据已经预先计算好。
相反，如果历史查询较少，但数据变化频繁，使用拉链表可以显著减少存储成本。

第三，数据变化频率与存储成本是否可接受？

如果某些维度变化频率非常高，使用每日快照可能会产生巨大的存储压力；而拉链表或变更日志能够通过记录变化区间或变更事件来降低存储开销。

这三个问题本质上是在权衡三件事：

• 查询效率
• 存储成本
• 历史完整性

只有在三者之间找到合适的平衡点，历史数据模型才能长期稳定运行。

与数仓分层的关系：ODS 与公共层的职责

在实际数仓架构中，ODS 层通常保留最原始的数据事实，而历史模型通常在公共层构建。

一种常见的实践模式是：

• ODS 层：保留原始变更数据（Change Log / CDC）
• DWD / DIM 层：构建拉链表或快照表
• DWS / ADS 层：提供指标与分析结果

这种分层方式有两个明显优势：

第一，ODS 层能够保持最大程度的数据原貌，便于后续重新加工。
第二，公共层构建的历史模型可以被多个业务场景复用，而不是在每个报表中重复实现。

换句话说，ODS 更像是 “原始事实仓库”，而真正可复用的数据模型应该沉淀在公共层。

指标口径问题：按当时属性还是按当前属性

历史数据设计中最容易被忽视、却又最容易引发争议的问题，是指标统计口径的定义。

在很多企业中，报表统计往往会遇到这样的问题：

去年某个业务指标到底应该按当时的组织结构统计，还是按当前组织结构统计？

例如：

• 员工去年属于 A 部门，今年被调整到 B 部门

• 如果统计去年的业绩

  • 按当时组织归属 → 计入 A 部门
  • 按当前组织归属 → 计入 B 部门

如果没有明确口径，不同报表可能会得出完全不同的结果。

因此在历史模型设计中，必须明确：

指标是按“历史属性”统计，还是按“最新属性”统计。

通常来说：

• 经营分析报表：更倾向于按当时属性统计
• 组织绩效管理：可能按当前属性统计

关键不是哪种方式正确，而是必须提前定义清楚，并在模型中实现对应逻辑。

常见陷阱：维度表不保留历史

很多团队在建设早期会选择简单方案：

维度表只保留最新状态。

这种设计在短期内看似简单，但很快就会带来严重问题：

• 历史报表无法复现
• 数据口径经常变化
• 业务无法回答历史问题

例如，当业务问到：

去年按哪个组织统计的销售额？

如果维度表没有历史记录，这个问题将无法回答。

因此，对于组织结构、用户属性、商品分类等可能发生变化的维度，通常都建议使用 SCD2（拉链表） 来保留历史状态。

六、ODS 层的职责边界：做什么，不做什么

在很多数据团队中，ODS 层最终会演变成一个问题集中区：
各种业务逻辑、报表计算甚至复杂关联都被堆到这一层，导致 ODS 成为整个数据平台最难维护的部分。

要避免这种情况，必须从一开始就明确 ODS 的职责边界。

1 ODS 层应该做的事情（必要加工）

ODS 并不是简单的数据落地层，它仍然需要进行一些必要的数据处理，以保证数据能够被稳定使用。

这些处理通常包括：

统一数据类型与编码

不同业务系统的数据类型和编码方式往往不一致，例如字符串编码、时间类型等。ODS 层需要统一这些基础格式，以避免后续处理出现问题。

统一时间与时区

跨系统数据经常会遇到时区问题，例如部分系统使用 UTC 时间，部分使用本地时间。ODS 层应统一时间标准，以确保时间字段的可比较性。

补充技术字段

例如：

• 数据加载时间（etl_time）
• 批次号（batch_id）
• 数据来源（source_system）

这些字段对于后续的数据审计与问题排查非常重要。

基础清洗与非法值处理

ODS 层可以处理明显的异常值，例如：

• 非法日期
• 无效编码
• 格式错误的数据

这些清洗并不涉及业务逻辑，而是保证数据结构上的可用性。

总结来说，ODS 的必要加工只有一个目标：

让数据“可用、可追溯、可运维”。

2 ODS 层不应该承担的逻辑

与必要加工相对应，ODS 层也有一些明确不应该承担的任务。

例如：

跨表关联（Join）

ODS 层不应进行复杂的跨系统关联，因为这会引入业务逻辑耦合。

复杂业务规则

例如用户分层、订单状态推导等业务逻辑，应在 DWD 层完成。

指标与汇总计算

聚合指标通常属于 DWS 或 ADS 层的职责。

如果这些逻辑提前出现在 ODS 层，就会导致：

• 逻辑重复
• 数据难以复用
• 维护成本上升

3 ODS 输出必须具备“可解释性”

高质量的数据平台必须保证：

任何一条数据都能解释其来源。

因此 ODS 输出需要满足三个条件：

字段含义清晰

字段定义应进入元数据系统，例如数据字典或数据目录。

来源可追溯

能够明确数据来自哪个业务系统、哪张表。

修正规则可追溯

任何数据修复或清洗逻辑，都应该有版本或批次记录。

这样在发生数据问题时，团队可以快速定位原因。

4 命名规范与表类型管理

在大型数据平台中，规范的命名体系能够极大降低维护难度。

例如：

raw_xxx   原始落地数据
ods_xxx   标准化后的ODS数据
tmp_xxx   临时计算表

通过表名前缀即可快速识别数据层级与用途。

同时，临时表必须设置自动清理机制，否则随着任务增多，很容易产生大量无用数据。

5 数据质量门槛必须前移

ODS 层是数据进入数仓体系的第一关，因此必须设置基础的数据质量校验，例如：

• 主键唯一性校验
• 非空字段校验
• 行数对账
• 关键指标校验

如果质量较差的数据直接进入公共层，问题将被无限放大，修复成本也会大幅增加。

6 ODS 必须支持重跑与重放

真正可运营的数据平台必须支持以下能力：

分区重跑

任何历史分区都可以重新计算。

位点恢复

增量同步任务可以从任意历史水位恢复。

历史回放

可以重新处理历史数据以修复问题。

如果系统不具备这些能力，数据平台将很难长期稳定运行。

7 最常见的问题：ODS 成为“万能层”

很多数据团队都会遇到一个典型问题：

所有需求都被堆到 ODS 层。

结果是：

• ODS 表结构复杂
• 逻辑难以理解
• 维护成本不断增加

最终，ODS 反而成为整个公司最难维护的数据层。

因此，一个健康的数据仓库架构应该遵循一个原则：

ODS 保持简单与稳定，复杂逻辑由公共层承担。

只有这样，数据平台才能持续演进，而不会随着业务增长而逐渐失控。

开发者朋友们大家好：

这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术 」、「有亮点的产品 」、「有思考的文章 」、「有态度的观点 」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@koki、@鲍勃

01 有话题的技术

1、杨立昆创办，世界模型公司 AMI 完成超 10 亿美元融资

3 月 10 日，世界模型研究所/创业公司 AMI 已完成 10.3 亿美元融资，投前估值 35 亿美元。

该公司由图灵奖得主、前 Meta 首席 AI 科学家杨立昆 （Yann LeCun） 创办。

据悉，AMI 全称 Advanced Machine Intelligence「先进机器智能」，以世界模型 （world models） 为主要研发方向，力求开发出能够从真实世界中学习抽象表征的世界模型。

AMI 本轮融资得到了多个极为重要的投资方支持：

• 本轮融资凯辉创新、Greycroft、Hiro Capital、HV Capital、贝索斯远征共同领投；
• 战略投资人当中包括英伟达、丰田创投、淡马锡、软银、马克·库班、穆里耶家族等；
• 跟投方包括埃里克·施密特、阳狮集团、三星、蒂姆·博纳斯·李等。

值得一提的是：谢赛宁，AI 基础研究方面的顶级专家，也是杨立昆的老朋友、学校同事，已经正式加入了 AMI 担任首席科学官。

根据融资纪要，AMI 本轮融资将用于支持长期科研、全球范围招聘工作，以及世界模型方向上的可靠产品。

(@APPSO)

2、Hume AI 开源 TADA：基于文本-声学双向对齐架构的实时语音合成模型，超低延迟零幻觉率

Hume AI 正式开源 TADA （Text-Acoustic Dual Alignment） ，核心突破在于通过一种新型 Tokenization 方案实现了文本与音频符号的 1:1 同步对齐。该架构解决了传统 LLM-based TTS 系统中音频 Token 数量远超文本 Token 导致的上下文窗口耗尽与幻觉问题，其轻量化特征支持在移动端及边缘设备实现低延迟的非云端部署。

核心技术参数与性能指标

• 同步机制 ：采用单文本 Token 对应单连续声学向量的流式处理，使每秒音频仅需 2-3 个帧（Tokens）处理，远低于同类系统的 12.5-75 Tokens。

• 推理速度 ：实时率（RTF）达到 0.09 ，较同级别 LLM-based TTS 提升 5 倍以上。

• 可靠性 ：通过物理架构强制映射，在 LibriTTSR 测试集中幻觉率 （CER \> 0.15）为 0。
• 上下文效率 ：在 2048 Token 窗口内可容纳约 700 秒音频，处理效率较传统方案提升 10 倍。
• 生成质量 ：基于 Flow-matching 头部生成声学特征，说话人相似度 4.18/5.0 ，自然度 3.78/5.0。

在工程实践中，TADA 的轻量化架构使其能够脱离云端 API 依赖，直接在终端设备运行，极大降低了推理成本并提升了隐私性；同时，其极高的内容一致性使其适用于医疗、金融等对「幻觉」零容忍的严苛场景。

但开发者仍需注意，目前开源的模型主要针对语音续写（Speech Continuation）场景，若应用于智能助手则需进行下游微调，且在处理超过 10 分钟的长文本时，建议通过重置上下文来规避潜在的音色漂移（Speaker Drift）问题。

Huggingface 链接：

https://huggingface.co/collections/HumeAI/tada

Blog 链接：
https://www.hume.ai/blog/opensource-tada

( @hume_ai@X)

3、Fish Audio 开源 S2：Dual-AR 架构实现 \<100ms 延迟与多角色长语音生成

Fish Audio 正式开源 S2 文本转语音模型，基于 4.4B 参数的双自回归（Dual-AR）架构与 1000 万小时音频数据。该模型实现了生产级的低延迟流式推理，并支持通过自然语言标签进行词级情感控制，以及多角色、跨段落的长音频生成。

• 自然语言精细化行内控制 ：支持在文本中嵌入自由格式的指令标签（如 [astonished]、[voice up]），实现词级的音调、情感和语速控制。在 EmergentTTS-Eval 中，副语言控制胜率达 91.61%，优于 GPT-4o-mini-tts。
• 多角色多轮对话支持 ：通过 <speaker:0>、<speaker:1> 等标签语法，支持一键生成复杂的多人对话。系统支持多 Prompt 音频输入，可快速完成多音色的克隆与切换。
• 高效率流式推理性能：实测首包延迟（TTFT）小于 100ms，实时因子（RTF）低于 0.195。在单张 NVIDIA H200 上，系统可在维持 RTF \< 0.5 的前提下，实现每秒 3000+ 声学 token 的吞吐量。
• 长文本上下文推理稳定性：支持长上下文推理（Long Context Inference），确保在生成跨段落的长文本故事或演讲时，音色与语气保持一致，避免传统 TTS 模型在长序列下的质量衰减。
• Dual-AR 非对称架构优化：采用 4B 参数的 Slow AR 处理语义 codebook，400M 参数的 Fast AR 处理残差声学细节。该设计与标准 LLM 同构，可无缝利用 SGLang 的连续批处理、RadixAttention（前缀缓存命中率达 86.4%）等优化手段。

模型权重、微调代码及 SGLang 推理栈已在 GitHub 和 Hugging Face 开源；S2 Pro 版本已在官方平台上线。

GitHub：
https://github.com/fishaudio/fish-speech/

HF：
https://huggingface.co/fishaudio/s2-pro

官网 blog：
https://fish.audio/zh-CN/blog/fish-audio-open-sources-s2/

信息来源：

（@Fish Audio Blog）

（@Fish Audio Blog / arXiv:2603.08823）

GitHub 链接：
https://github.com/fishaudio/fish-speech/?tab=License-1-ov-file#readme

( @FishAudio@X)

02 有亮点的产品

1、「幕间」连续完成两轮千万美元融资，用「世界模拟器」突围 AI 娱乐

AI 互动娱乐平台「幕间」已于近期连续完成两轮融资，累计融资金额达千万美元。两轮融资分别由锦秋基金、云九资本领投，包括前网易副总裁少云、原沐瞳 CEO 袁菁（Justin）在内的多位游戏行业资深人士跟投。

创始人 Roi 曾任职于乐元素、莉莉丝；随后进入字节跳动教育线，负责游戏化产品设计。在创办「幕间」之前，她的身份是 LiblibAI 的联合创始人及产品负责人。在那里，她亲历了 AI 工具从 0 到 1 的爆发与激烈的算力补贴战，并主导开发了早期的 AI 自由画布设计工具。

她认为，做「幕间」是对** AI 如何服务于人类娱乐进一步思考后做出的选择**。

离开 LiblibAI 后，Roi 希望通过「幕间」，以一个更具感性色彩与想象力的方式切入人类与 AI 之间的互动关系：基于 UGC 的 AI 模拟器平台。有些类似刚获得 1 亿美元融资、基于「斯坦福小镇」逻辑的社交沙盒 Simile，让用户作为「上帝」观察 Agent 在系统规则下的自主演化。

用一种更好理解的方式来解释「幕间」到底是什么，可以说，**它并非传统意义上的游戏，更像是一个集成密室、剧本杀、短剧、游戏的线上综合游乐园。平台上的创作者通过使用提供的 AI 制作工具创造不同的世界，用户通过平台选择、进入、并沉浸其中。**较传统游戏来说，「幕间」更轻量、更碎片，也更强调完全个性化的反馈。

**「和 AI 聊天久了会乏味，而互动剧、互动小说的选项又太过单调。」**因此，她希望打造一个人类与 AI 新的互动娱乐系统。

最出乎 Roi 意料的是，平台很快凝聚起来的、最核心的一批创作者并非专业游戏从业者或程序员，竟然多是来自一二线城市的「00 后」女生。与此同时，这些创作者也是玩家。

为了能够凝聚这群创作动力蓬勃的核心资产，「幕间」为这些创作者提供了一整套工具链，使其能像搭建乐高积木一样搭建 Agent：用户可以基于 Producer Agent，通过组合导演、玩法、交互等多种 Skills 构建高可玩性的系统。同时，幕间为 Agent 提供了多模态渲染、MJV 变量、跨端的 LUI、Cloud Identity 等工具，让 Agent 可以创造出惊艳的多模态体验和易用的交互方式。

在即将到来的 3 月中下旬，「幕间」计划开启更大规模的测试和模拟器开发大赛，世界模拟器的「品类」也将拓宽至修仙、职场、历史演化等更广泛的领域。

（@锦秋集）

2、Intercom 融资 2.5 亿美元发力「客户智能体」：基于自有模型与服务栈的架构演进

Intercom 宣布通过 Hercules Capital 完成 2.5 亿美元债务融资 。此轮资金将专项用于研发其下一代 Customer Agent（客户智能体），旨在将 AI 从单一的 FAQ 检索工具升级为具备销售、顾问及专家职能的端到端业务模块。

技术差异化与工程路径

• 垂直领域大模型 （Proprietary AI） ：不同于依赖通用底座的竞争对手，其智能体运行在基于数十亿级专有客户体验数据训练的自有模型之上。该模型由其 60 人规模的 AI 实验室开发，针对客服场景的响应精度与业务对齐进行了深度优化。
• 产品形态：平台化而非顾问模式 ：区别于传统的交付型服务，提供标准化、自助化的 Purpose-built Platform。支持企业自主管理 Agent 逻辑，通过 API 与现有服务栈（如 Zendesk、Service Cloud 等）或原生 Intercom + Fin 组合进行深度集成。
• 新型对话范式：引入全新的交互逻辑，支持智能体记忆用户全生命周期的上下文，实现从简单的「单次交互」向长程业务逻辑处理的跨越。
• 业务闭环能力：支持智能体执行复杂动作，如 Pipeline 自动生成。目前已有企业通过该系统实现数千万美元规模的销售增量。

Intercom 正通过「自有数据+自有模型+自有 Help Desk 栈」的垂直集成，试图建立起相对于基于 OpenAI/Anthropic 开发的薄层 Agent 的技术壁垒。

据悉，该项投资将直接对标初创公司数亿美元级的研发投入，重点攻关「Customer Agent」在复杂决策、多轮对话稳定性及业务自动化方面的能力。

( @egohan@X)

3、Dify 完成 3000 万美元 Pre-A 轮融资：加速生产级 Agentic Workflow 平台建设

开源 AI 应用开发平台 Dify 宣布完成 3000 万美元 Pre-A 轮融资，由红杉领投，GL Ventures、Alt-Alpha Capital（Bessemer Venture Partners 新孵化基金）、五源资本、瑞穗力合投资和 NYX Ventures 跟投。

作为目前 GitHub 星标排名第 51 位的开源项目，Dify 已在全球超过 140 万台机器上运行，核心定位于模型层与业务系统之间的「逻辑层」，提供可视化编排与生产级基础设施。

本轮融资将专项用于提升 Agentic Workflow 的生产可靠性，重点优化构建块（Building Blocks）的可预测性及长链路调试机制。研发方向涵盖企业级基础能力的强化，包括高并发性能调优、合规性审计及精细化权限控制。

同时，Dify 将进一步降低构建门槛，使非开发背景的领域专家能直接编排业务逻辑，并持续扩展插件、连接器及社区模版生态。

( @Dify)

03 有态度的观点

1、黄仁勋：AI 与电力一样同等重要

昨天，英伟达公布了 CEO 黄仁勋发表署名文章提出 AI 「五层蛋糕」架构模型，并明确将 AI 定性为与电力同等重要的现代基础设施。

黄仁勋在文章中指出，计算技术正从传统的预制软件向实时生成的智能转变，这种底层逻辑的演进要求整个计算架构进行彻底重构。他将工业视角的 AI 架构自下而上拆解为五个层级：能源、芯片、基础设施、模型与应用。

文中强调，能源是制约智能系统产出规模的首要瓶颈；芯片层决定了 AI 的扩展速度与效率；基础设施层表现为旨在「制造智能」的 AI 工厂；模型层正从语言扩展至生物化学、物理模拟等前沿领域；顶层的应用层（如自动驾驶、人形机器人）则负责创造经济价值。

这五个层级相互强化，任何顶层应用的成功都会对底层设备与能源产生强烈的需求拉动。

在行业动向层面，该文章肯定了开源模型对激活全栈算力需求的关键作用。黄仁勋以 DeepSeek-R1 为例指出，高性能推理模型的广泛开放直接加速了应用层的普及，并逆向带动了底层训练、算力设施及能源的规模化增长。

(@APPSO)

04 社区黑板报

招聘、项目分享、求助......任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、Physical AI 系列活动硅谷站！探讨和上手全模态与硬件智能丨 Meetup+Workshop，3 月 19 日

湾区硅谷的开发者和创业者们，3 月 19 日见！

GTC 期间，来一场动脑又动手的 Physical AI 全天候嘉年华！同一场地，两场硬核活动无缝衔接：

🌅 上午 09:30｜Meetup：对话真实世界

Agora | RiseLink | MiniMax | HumanTouch | EverMind | Resonance Ventures 等大咖齐聚，拆解全模态与端侧智能的机会与未来。

🛠 下午 13:30｜Workshop：手搓语音 AI 硬件

基于 TEN 框架，实操接通语音 AI Agent。重点来了👉现场备有 40 套 Agora R1 开发板，代码跑通直接把硬件带回家！

上下午活动需分开独立报名，名额有限，拼手速：

上午 Meetup 报名：

https://luma.com/8we6qyma

下午 Workshop 报名：

https://luma.com/onc0xr9y

地点：

Sunnyvale （审核后发具体定位）

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

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

关于作者：Harrison Chase，LangChain 联合创始人兼 CEO，长期专注 AI Agent、上下文工程、LLM 应用架构与 MLOps。

原文链接：https://x.com/hwchase17/status/2031051115169808685?s=46

导语：代码智能体大幅降低代码编写成本，彻底重塑软件行业 EPD（工程、产品、设计）工作模式：传统 PRD 先行的瀑布式流程终结，工作瓶颈从开发实现转向审核校验；EPD 角色分化为构建者与审核者，通才价值凸显，产品思维成全员必备，专业人才门槛大幅提升；掌握代码智能体成为职场必需，其核心价值在于让从业者聚焦 “做什么” 和 “做得好不好” 的核心判断，而非基础编码工作。

软件公司的工程、产品与设计团队（EPD）的核心工作是打造优质软件。团队内部分工明确，但最终目标都是开发出能解决业务问题、可供用户使用的功能性软件。归根结底，这一切的成果最终都会落地为代码。我们必须认清一个事实：EPD 团队的工作产出本质上就是代码，而代码智能体的出现，让代码编写变得前所未有的轻松。那么，这一变化会如何重塑 EPD 各角色的定位与工作模式？

行业变革的核心趋势

• 传统产品需求文档已成过去式
• 工作瓶颈从开发落地转向审核校验
• 产品需求文档的核心价值依然存续
• 通才的价值迎来前所未有的提升
• 掌握代码智能体成为必备能力
• 优秀产品经理的价值被放大，能力不足的产品经理则会造成更大内耗
• 产品思维成为全员必备素养
• 专业人才的能力门槛大幅提高
• 职场角色逐渐分化为 “构建者” 与 “审核者”
• 每个岗位都能从代码智能体中获得专属优势，这一认知是完全正确的

传统产品需求文档已成过去式

在 Claude 诞生前的时代，产品需求文档（PRD）是软件开发工作的核心抓手，彼时的 EPD 工作流程基本遵循固定范式：

• 有人（通常是产品人员）产生一个产品想法
• 产品团队撰写产品需求文档
• 设计团队依据文档制作产品原型
• 研发团队将原型开发为实际代码

这并非铁律（创业公司中这些环节往往相互融合，优秀的从业者能同时胜任多个环节的工作），但却是行业内标准化的开发流程。

这种流程的存在有其必然性：过去，开发软件和制作原型需要投入大量的时间与精力，因此行业中逐渐形成了各有专攻的职能分工。而随着专业化程度的提升，跨职能的沟通需求应运而生，产品需求文档则成为了跨部门沟通的基础，是整个开发流程的起点。后续工作会按瀑布式推进：设计团队将文字描述转化为美观的用户界面和流畅的用户体验，研发团队再将设计落地为实际可用的产品。

而代码智能体的出现，彻底颠覆了这一模式。它能直接将一个产品想法转化为可运行的功能性软件。我们所说的 “传统 PRD 已成过去式”，本质上是指这种以撰写 PRD 为起点的传统软件开发模式，已经不再适用。

工作瓶颈从开发落地转向审核校验

如今，任何人都能编写代码，也就意味着任何人都能参与产品搭建，但这并不代表所有搭建出的产品，都具备合理的架构、能真正解决问题，或是拥有良好的易用性。而 EPD 团队的核心职责，就转变为对这些产品的上述维度进行审核与评判。

问题的关键在于，智能体生成的代码并非总能达到 “优质” 标准，因此 EPD 团队的工作重心也变为审核代码、确保最终产出的质量。这里的 “优质” 包含多重维度：

• 从工程架构角度，代码是否具备可扩展性、高性能与高健壮性？
• 从产品设计角度，产品是否真正解决了用户的痛点？
• 从交互设计角度，产品界面是否简洁直观、易于使用？

由于制作初代代码版本的成本大幅降低，市面上出现了大量的产品原型，而这些原型也成为了 EPD 团队共同审核的核心对象。

当下的核心问题是，代码生成的门槛过低。在过去，开发代码需要耗费大量时间，因此审核人员手头的待审核项目数量始终有限；但现在，任何人都能编写代码，导致同时推进的项目数量大幅增加。我们发现，工程、产品、设计三大职能的工作瓶颈，都已转移至 “审核” 环节 —— 即对原型进行校验，确保其达到可用标准。

产品需求文档的核心价值依然存续

以撰写 PRD 为起点的传统软件开发模式已然落幕，但用于描述产品需求的文档，其价值依然不可或缺。

试想这样的场景：有人产生一个想法后，快速搭建出了产品原型，那么这个原型要如何落地投产？答案是必须经过 EPD 团队其他成员的审核。而在这一过程中，书面的需求文档往往能起到关键作用，甚至是必不可少的。当审核人员查看原型时，如何判断某段代码的存在是刻意设计还是偶然生成？这一切都取决于产品的设计初衷，而这份初衷，需要通过文档进行清晰传递。

我认为，PRD→原型→代码的传统流程已经消亡，但用于描述产品需求的文本内容，生命力依旧旺盛。在原型提交审核前，配套的需求说明文档必须成为必备材料。

这类文档的标准形式仍是书面文件，但行业中也出现了一些新颖的思路：比如将生成产品功能时使用的提示词作为沟通载体。未来的产品需求文档，是否会演变为结构化、可版本化的提示词？这值得思考。

通才的价值迎来前所未有的提升

这里所说的通才，指的是同时具备产品、工程、设计三大领域核心认知的从业者。这类人才一直以来都极具价值和影响力，而在代码智能体的时代，他们的价值被进一步放大，原因何在？

沟通是所有工作中最难的环节，它会大幅拖慢工作推进的效率。一个能同时胜任产品、设计、研发工作的通才，其工作效率远高于一个由三人组成的专业团队，核心原因就是省去了跨角色的沟通成本。

在过去，开发落地是工作的主要障碍，即便是通才，也需要与他人沟通协作才能推进工作；但现在，通才只需与代码智能体协作即可完成工作，这意味着单一个体的影响力，能达到前所未有的高度。

掌握代码智能体成为必备能力

代码智能体让开发落地的成本大幅降低，掌握这一工具也因此成为行业必备能力。能熟练运用代码智能体的从业者，能凭借一己之力完成更多工作：

• 产品经理可直接通过搭建原型验证想法，无需撰写需求规格文档后苦苦等待；
• 设计师可在代码层面进行产品迭代，而非仅局限于 Figma 等设计工具；
• 研发工程师可将工作时间从基础开发，转移至系统架构设计等更具深度的思考上。

掌握代码智能体之所以成为必备能力，是因为其学习门槛并不高，而如果不愿掌握这一工具，最终必然会被掌握它的人取代。

优秀产品经理的价值被放大，能力不足的产品经理则会造成更大内耗

优质的产品思维，其价值在当下达到了新高度 —— 凭借它能打造出真正有价值的产品；而糟糕的产品思维，造成的资源浪费也会远超以往。如果一个产品经理提出了糟糕的产品想法，甚至能快速做出对应的原型，但这个原型对应的功能，要么毫无用处，要么设计拙劣。

这类问题原型会需要工程、产品、设计团队投入更多精力审核，大幅占用团队的时间和资源；同时，将其落地投产的惯性也会更大（比如有人会说 “原型都已经做出来了，直接合并上线就好”），最终可能导致产品体验变差、功能臃肿。

系统思维成为核心必备技能

在开发落地成本极低的时代，系统思维成为了区分从业者能力的核心标准。每个人都应专注于打磨自己的系统思维，建立对所在领域清晰的心智模型：

• 研发工程师：对服务、接口、数据库的架构设计，拥有清晰的心智模型；
• 产品经理：能精准洞察用户的真实需求，而非被用户的表面表述所误导；
• 设计师：能理解设计背后的逻辑，知晓为何某类设计能带来良好的视觉感受和使用体验。

系统思维一直以来都至关重要，那么如今发生了什么变化？核心是开发落地的成本大幅降低，这意味着实现一个想法变得前所未有的容易，但 “容易实现” 并不等同于 “实现得好”。

拥有优秀的系统思维，能让从业者在工作初期就确定正确的开发方向，也能在后期更高效地审核他人的工作成果。这两点，让系统思维的重要性被无限放大。

产品思维成为全员必备素养

代码智能体仍需要人来下达指令，告诉它该做什么。如果向它下达了错误的开发指令，最终只会产生更多需要他人审核的低质量产物。因此，知道该让智能体开发什么功能，也就是具备 “产品思维”，成为了全员必备能力，否则就会成为团队的拖油瓶。这一点，对工程、设计团队适用，对产品团队而言更是理所当然。

如今 EPD 团队的核心工作之一是审核原型，而具备产品思维能让审核工作变得更高效，即便是审核设计或工程相关的内容也是如此。如果缺乏产品思维，就需要为原型配套极其详尽的产品文档；而具备产品思维的人，只需简单的规格说明就能理解功能的设计初衷，大幅加快沟通、审核和交付的效率。

专业人才的能力门槛大幅提高

当下的从业者，不仅需要掌握代码智能体的使用方法、具备产品思维，各岗位的工作内容也在相互融合。

其实岗位间的重叠一直存在：设计与产品的关联由来已久，在苹果、爱彼迎等公司，设计师甚至会承担产品经理的工作；而 “设计工程师” 这一岗位，也在维尔塞等公司逐渐兴起。
这并不意味着专业人才失去了发展空间：一位深耕系统架构的资深研发工程师，依然具备极高的价值；即便不擅长通过代码落地产品，但能精准洞察客户问题、明确产品开发方向的产品经理，同样不可或缺；哪怕仍在 Figma 中进行设计，但能精准理解并制作用户旅程和交互原型的设计师，也依旧是团队的核心力量。

但专业人才的能力门槛确实大幅提高了：从业者不仅要在所属领域做到顶尖，还必须拥有极高的审核效率和出色的沟通能力。而在任何一家公司，能达到这一标准的专业人才，数量都寥寥无几。

职场角色逐渐分化为 “构建者” 与 “审核者”

我们发现，EPD 团队的岗位角色正逐渐分化为两大类型：

• 第一类是构建者。这类从业者具备优秀的产品思维，能熟练使用代码智能体，且拥有基础的设计直觉。在测试套件、组件库等工具的辅助下，他们能将小型功能从想法直接落地投产，也能为大型功能搭建出可运行的原型。
• 第二类是审核者。对于大型、复杂的产品功能，需要 EPD 团队进行详尽的审核，而这一岗位的能力门槛极高 —— 从业者必须是所属领域的顶尖系统思维者，同时还要具备高效的工作节奏，因为待审核的内容数量极为庞大。

如果你是一名研发工程师，未来的发展方向有两个：要么深耕系统设计，熟练审核各类架构方案，成为一名审核者；要么培养自己的产品和设计能力，转型为构建者。

如果你从事产品或设计工作，要么打造出对产品 / 设计领域的极致心智模型，专注于审核工作；要么熟练运用代码智能体，提升自己的代码能力，成为构建者。

有趣的是，各岗位的边界正逐渐模糊，EPD 团队的所有从业者，都能在 “构建者 - 审核者” 的维度中找到自己的定位：岗位间的融合成为趋势，研发工程师有了更多时间，能深入思考产品和设计问题；产品和设计人员，也能亲自编写代码、落地想法。

每个岗位都能从代码智能体中获得专属优势，这一认知是完全正确的

Twitter 上曾有一篇优质帖子，探讨了哪类人群能从代码智能体中获得最大优势，核心观点如下：

真正能把握时代机遇的，是那些能直观理解现有产品的人 —— 他们清楚产品的短板在哪、亮点何在，也知道该如何迭代优化，让产品变得更出色。

而这类人群中最稀缺的，是那些兼具文化洞察力和深厚技术功底的人，他们是真正的 “双语者”：既懂技术实现的边界，又能分辨哪些文化趋势是真实的长期趋势，哪些只是短暂的潮流。正是这种复合能力，让他们打造的产品浑然天成、深入人心，而不是简单拼接、毫无灵魂。

这篇帖子精准概括了代码智能体时代的行业现状，也在社交平台上小范围走红。它能走红的原因之一，就是每个读到它的人，都觉得这说的是自己或自己的岗位 —— 产品人、设计师、设计工程师、创始人…… 所有人都认为，这篇帖子描述的特质与自己的工作高度契合。

而他们的想法，大概率都是正确的！我认为，代码智能体时代最令人振奋的一点，就是从业者的专业背景变得不再重要。我坚信，上述这种稀缺的复合型人才，可能来自产品、设计或工程等任何一个领域。

当然，这并不意味着所有人都能成为这样的人才 —— 说起来容易，做起来却难上加难，真正的全能型人才本就寥寥无几。

当下，正是投身产品搭建的黄金时代。

openclaw 是一款运行在本地的开源个人 AI 助手，支持 Mac / Windows / Linux 三平台，通过 npm 全局包安装，并在系统中注册守护进程（daemon）和工作区配置目录。仅执行 npm uninstall -g openclaw 无法完全卸载，必须额外清理守护进程、配置目录和缓存文件，才能实现彻底移除。

openclaw 在系统中留下了什么？

openclaw 安装后会在系统中写入 4 类数据：

只删除 npm 包，守护进程和 ~/.openclaw/ 目录会继续留在系统中，开机仍会自动启动相关进程。

彻底卸载步骤（推荐顺序）

彻底卸载分为 4 步，必须按顺序执行，跳过任何一步都可能留下残留。

第一步：停止并卸载守护进程

macOS（launchd）

# 查找 openclaw 服务名
launchctl list | grep openclaw

# 停止并卸载服务（将 com.openclaw.daemon 替换为实际服务名）
launchctl stop com.openclaw.daemon
launchctl unload ~/Library/LaunchAgents/com.openclaw.daemon.plist

# 删除 plist 文件
rm -f ~/Library/LaunchAgents/com.openclaw.*.plist

Linux（systemd）

# 停止并禁用服务
systemctl --user stop openclaw
systemctl --user disable openclaw

# 删除服务文件
rm -f ~/.config/systemd/user/openclaw*.service
systemctl --user daemon-reload

Windows（PowerShell）

# 查找 openclaw 相关进程
Get-Process | Where-Object { $_.Name -like "*openclaw*" }

# 停止进程
Stop-Process -Name "openclaw" -Force

# 从任务计划程序删除（如有）
schtasks /Delete /TN "openclaw" /F

第二步：卸载 npm 全局包

npm uninstall -g openclaw

验证是否已移除：

which openclaw   # 应无输出
openclaw --version  # 应报 command not found

第三步：删除配置目录和数据

这是最关键的一步，~/.openclaw/ 目录包含所有本地数据：凭证、API 密钥、对话记忆、已安装的 Skills。

# 查看目录大小（确认再删）
du -sh ~/.openclaw/

# 彻底删除
rm -rf ~/.openclaw/

注意：此操作不可逆。如需保留 API 密钥或自定义 Skills，请先备份 ~/.openclaw/.env 和 ~/.openclaw/skills/。

第四步：清理 npm 缓存（可选）

# 清理 npm 全局缓存中的 openclaw 相关缓存
npm cache clean --force

# 或仅清理 openclaw 缓存条目
npm cache ls | grep openclaw

各平台卸载差异对比

如何确认已彻底卸载？

执行以下验证命令，所有命令均应返回空或报错：

# 1. 检查命令是否存在
which openclaw && echo "❌ 仍有残留" || echo "✅ npm 包已移除"

# 2. 检查配置目录
[ -d ~/.openclaw ] && echo "❌ 配置目录仍存在" || echo "✅ 配置目录已清除"

# 3. 检查守护进程（macOS）
launchctl list | grep openclaw && echo "❌ 守护进程仍在运行" || echo "✅ 守护进程已清除"

# 4. 检查端口占用（openclaw 默认使用 18789）
lsof -i :18789 && echo "❌ 端口仍被占用" || echo "✅ 端口已释放"

四条全部输出 ✅，说明卸载彻底。

常见问题 FAQ

Q1：守护进程 launchctl unload 报错怎么办？
先用 launchctl list | grep openclaw 确认服务名称，确保 plist 路径正确。如果服务已经不存在但报错，直接删除 plist 文件即可：rm -f ~/Library/LaunchAgents/com.openclaw.*.plist。

Q2：卸载后重新安装，旧数据会恢复吗？
不会自动恢复。如果已删除 ~/.openclaw/ 目录，重新安装后会从零开始初始化。若保留了该目录，重装后旧配置和记忆会自动加载。

Q3：npm uninstall -g openclaw 提示找不到包怎么办？
说明该包可能通过其他方式安装（如 Git 安装法）。检查 ~/.local/bin/openclaw 或 /usr/local/bin/openclaw 是否存在，手动删除对应可执行文件。

Q4：卸载后系统启动变慢问题是否解决？
openclaw 守护进程默认监听 WebSocket 端口 18789 并在后台常驻。完成第一步守护进程卸载后，启动项残留即消除，开机不再自动启动。

Q5：Windows 下找不到 openclaw 相关进程怎么排查？
打开任务管理器 → 详细信息，搜索 node.exe 或 openclaw。也可在注册表 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 中检查是否有 openclaw 自启项。

小结

openclaw 彻底卸载需要完成停止守护进程 → 卸载 npm 包 → 删除 ~/.openclaw/ 目录 → 清理缓存四个步骤。其中守护进程和配置目录是最常被遗漏的残留来源。本文步骤经 openclaw GitHub 官方仓库文档（2026年3月）及社区实践验证，适用于 openclaw v1.x 及以上版本。