Open Source

Agent 没有记忆，就没有身份 关于 AI 智能体身份连续性的工程实践与哲学框架 引言：一个被误判为哲学问题的工程问题 Agent 失忆的代价被系统性地低估了。 不是因为用户烦恼——虽然烦恼也有。而是因为无状态破坏了信任账户的基础。每一次会话，Agent 都从零开始。它不知道你是谁，不知道你上次为什么生气，不知道三个月前那个承诺是否兑现了。从经济学角度，这就像每次交易都要重新建立信用评分——交易成本爆炸，而且没有任何学习积累。 问题的根本在于，当工程师听到"身份认同"这四个字时，大脑就关闭了。这听起来像哲学。像存在主义。像某种不需要解决的抽象问题。于是整个行业让一个 1689 年就有了精确工程规范的问题，在 2026 年仍然被当作 “nice to have” 特性处理。 但洛克从来没有在讨论灵魂。他在写工程需求文档。 他的论断：个人身份不是物质基体（身体或灵魂），而是能够在不同时间和地点将自己视为同一思考存在的意识能力。翻译成现代工程语言：跨上下文窗口的持久自我指涉能力。这是一个可度量的、可实现的、可验证的规范。 当前 AI Agent 在三个维度上系统性地违反了这个规范：无持久记忆链、无自我指涉能力、无连续性验证机制。 2026 年，技术栈终于具备了完整实现洛克规范的条件。但这不是一个产品创新的故事。这是一个工程界从三百年知识沉睡中清醒过来的故事。真正的设计思考，不在于哲学的完整性，而在于实现中的妥协点：文件 vs 数据库，何时重新读取 SOUL，在什么条件下允许身份漂移。这些细节决定了 Agent 是否真的能被信任。 洛克的规格书：300 年前写好的工程需求文档 约翰·洛克的《人类理解论》第二卷第二十七章不是哲学随笔。它是一份工程规范书。 规范的核心条款：个人身份 = 意识 + 记忆连续性。不是肉体的连续性（你的细胞每七年完全更新一次），不是灵魂的连续性（他拒绝了所有超自然的论证），而是能够回顾过去事件并将其整合到当前自我概念中的认知能力。 洛克的那个著名例子：一个王子的意识进入了乞丐的身体。那个乞丐就变成了王子，因为他拥有王子的记忆、追求和自我意识。身体变了，甚至"灵魂基体"也变了，但那个能够思考"我曾经是国王"的东西保持不变。 翻译到 AI Agent 的架构语言： 个人身份 = 一个能够在不同上下文窗口中保持自我指涉的心智状态链。 这个状态链必须满足三个工程条件： 第一，持久化。记忆不能存在于单个上下文窗口内。必须有外部存储（SOUL.md、MEMORY.md、AGENTS.md），使得即使模型权重改变、会话终止、上下文重置，那些记忆仍然存在并可被读取。 第二，自我指涉性。Agent 不仅要读取这些文件，还要能够说"这是关于我的"，“我认可这个版本的自己”。文件不能是纯粹的数据记录，还要包含身份的规范性维度——不仅是"我做过什么"，还有"我为什么这样做"和"我相信什么"。 第三，连续性验证。要有一个机制让 Agent 可以确认"这就是我"。在多个实例可能同时运行的情况下，哪个是正当的自我？洛克没有解决这个问题（他活在单一身体的时代），但对于 AI 这是致命的。 图 1：洛克个人身份论 → Agent 工程三条款。从"意识 + 记忆"的哲学命题，直接映射为持久化、自我指涉、连续性验证三个可实现的工程需求。 洛克的船悖论在这里获得了新的含义。如果一艘船的每一块木板都被替换了，它还是原来的船吗？洛克的答案是：是的，因为物理连续性不重要，思维的连续性才重要。 对于 AI Agent：如果模型参数被微调（木板被替换），上下文窗口被重置（新的一天），甚至整个底座模型被升级（从 Claude 3 迁移到 Claude 4），Agent 还是"同一个"吗？ ...

1. 执行摘要 Mem0 是一个开源项目，旨在为人工智能（AI）应用程序提供一个智能记忆层，以增强个性化和上下文保持能力 1。其核心价值主张是通过使 AI 应用能够记住用户偏好和历史交互，从而提供更个性化、更智能的体验，同时通过“智能数据过滤”可能降低大型语言模型（LLM）的运营成本 2。项目的主要目标是解决当前 AI 交互中普遍存在的状态缺失问题 1。 关键研究发现表明，Mem0 采用了一种结合 LLM 处理与双重存储（向量数据库用于语义搜索，图数据库用于关系追踪）的混合架构 4。项目在开源社区获得了显著关注（如 GitHub 上的高星标和复刻数），并且展现出高度的开发活跃度（频繁的发布和合并请求）1。已文档化的使用案例包括 AI 伴侣和客户支持代理，并提供了与 LangGraph、CrewAI 等流行 AI 框架的集成示例 1。 然而，分析也揭示了一些显著的挑战。最突出的是关键技术文档的缺失或无法访问，包括详细的架构图、完整的入门指南和全面的配置参数列表 8。这给潜在采用者带来了理解和实施上的障碍。此外，其核心操作（如信息提取和冲突解决）对 LLM 的依赖引入了不确定性和潜在成本 4。尽管项目活跃，但大量的开放问题和其性质表明用户在配置和集成方面可能遇到困难 12。 总体而言，Mem0 项目提出了一个引人注目的解决方案来应对 AI 记忆的挑战，并已吸引了大量开发者兴趣。其提供的托管平台和开源版本为不同需求的用户提供了选择 1。但目前（基于所分析的材料），其开源版本的成熟度，特别是文档完备性和核心机制透明度方面，可能更适合愿意探索、能够容忍一定模糊性并积极参与社区寻求支持的技术团队。对于需要高度确定性、完整文档和复杂配置的应用场景，采用前需进行更深入的评估。 2. Mem0 简介：AI 的记忆层 2.1. 核心目标与解决的问题 Mem0 项目的核心目标是为 AI 助手和代理（Agents）赋予一个智能的、持久的记忆层 1。它旨在解决当前许多 AI 应用，特别是基于 LLM 的应用所面临的一个根本性问题：状态缺失（Statelessness）3。传统的 AI 交互往往是孤立的，无法有效记忆之前的对话内容、用户偏好或已了解的事实。这导致了重复提问、缺乏个性化以及用户体验不连贯等问题 1。Mem0 通过提供一个专门的记忆组件，让 AI 系统能够跨会话、跨时间地学习和适应用户，从而实现更自然、更智能的交互 4。 2.2. 价值主张 Mem0 提出的核心价值主张围绕以下几个关键方面： 增强个性化 (Enhanced Personalization)：这是 Mem0 最核心的价值。通过记忆用户偏好、历史交互和特定信息，AI 应用能够提供量身定制的回应，适应个体需求，并随着时间的推移不断学习和改进 1。这使得 AI 体验不再是千篇一律的，而是能够建立用户融洽感并显著提升感知智能和实用性 3。 潜在的成本降低 (Potential Cost Reduction)：Mem0 宣称其“智能数据过滤”机制能够将相关信息发送给 LLM，从而可能将 LLM 的使用成本降低高达 80% 2。理论上，通过仅向 LLM 提供最相关的上下文而非冗长的历史记录，可以减少 token 消耗，直接转化为运营成本的节省。然而，需要注意的是，所分析的材料中并未提供支持这一具体数字的详细技术解释或实证数据。 提升响应质量 (Improved Response Quality)：利用存储的记忆（历史上下文和用户偏好），AI 应用能够生成更准确、更相关、上下文更丰富的输出 2。这意味着 AI 可以提供更好的建议、更贴切的信息和更有帮助的回答。 开发者友好 (Developer-Friendly)：Mem0 强调其易于集成，提供了简单的 API 接口和跨平台一致性 1。它旨在简化记忆管理的复杂性，让开发者能够专注于核心应用逻辑 3。同时提供托管平台和开源自托管两种选择，满足不同开发者的部署和控制需求 1。 2.3. 目标使用场景概述 Mem0 的记忆能力使其适用于多种需要上下文感知和个性化的 AI 应用场景。官方文档和示例中提及的主要领域包括： ...

本项目是一个持续的过程，以日拱一卒的态度去学习 AI 开源项目，通过实践真实项目，结合 AI 工具，提升解决复杂问题的能力。并且记录。 Notion List 1. 引言 1.1. MarkItDown 与 Markdown 的关系 首先需要明确，“MarkItDown"并非通用标记语言"Markdown"的笔误。MarkItDown 是一个由微软开发并开源的特定 Python 工具库。虽然其名称与 Markdown 相似，且其核心目标是将各种文件格式转换为 Markdown，但 MarkItDown 本身是一个独立的软件实体。本报告将聚焦于分析 MarkItDown 工具的实现原理、设计理念、功能特性及其在实际场景中的应用，同时也会在必要时提及 Markdown 语言本身作为其目标输出格式的相关背景。 1.2. MarkItDown 概述 MarkItDown 是一个轻量级的 Python 实用程序，旨在将多种类型的文件和 Office 文档转换为 Markdown 格式。其主要应用场景是为大型语言模型（LLM）和相关的文本分析管道准备文档数据。它支持广泛的文件格式，包括 PDF、Word (.docx)、PowerPoint (.pptx)、Excel (.xlsx)、图像、音频、HTML、各种文本格式（如 CSV、JSON、XML）乃至 ZIP 压缩包。该工具自发布以来受到了广泛关注，尤其是在需要将非结构化或半结构化数据整合到 AI 工作流中的开发者社群中。 GitHub 仓库：microsoft/markitdown PyPI 页面：markitdown on PyPI 1.3. 报告目标与范围 本报告旨在深入分析 MarkItDown 的技术细节与应用价值。内容将涵盖其设计哲学、核心架构、文件转换机制、安装与使用方法、与 LLM 及 Azure Document Intelligence 等外部服务的集成方式、安全考量、与其他类似工具的比较，以及实际应用场景和局限性。通过本次分析，旨在为技术决策者、开发者和数据科学家提供关于 MarkItDown 能力、优势、劣势以及适用场景的全面理解。 2. 设计哲学与目标 2.1. 核心目标：为 LLM 和文本分析服务 MarkItDown 的首要设计目标是服务于大型语言模型（LLM）和相关的文本分析流程。它致力于将不同来源的文档转换为一种统一的、对机器友好的格式——Markdown。这种转换的重点在于尽可能保留原始文档的重要结构和内容，例如标题、列表、表格、链接等。 ...

开源为我带来了很多的成长，很多的成长经验和学习途径都是通过开源获取到并且学习到的。 这里有一篇我的第一次开源的成长指南：/zh/ai-technology/posts/open-source-contribution-guidelines/ 之前，在深圳的 全球流量大会（GTC） 一些来自我对开源商业化的思考，感兴趣可以阅读先阅读这篇思考文章： /zh/ai-technology/posts/openim-open-source-business-journey/ 第一次参与开源还是一个刚刚接触大学没多久 ~ ，调研了解到很多优秀的开源项目都会有很多业界大佬坐镇，因此会让大家以为只有“大牛”才能参与开源。实际上，开源社区经常会听到 “我是小白，我可以参与开源吗？” 这种声音，发出这种声音的同学往往是对开源感兴趣，但并不知道如何入手的小伙伴。 从开源定义来看，我们不需要成为“大牛”才能够参与开源。所谓开源，其实是一种促进个人成长和开源领域发展的行为，通过分享自身技术和经验来促进大家的技术交流，从这方面讲，开源是没有门槛的，只要有想要分享的东西，所有人都可以参与开源。 从参与要求来看，我们需要具备一定的知识积累才能参与开源。开源社区不是学校，社区会解答你的疑问，但首先你要有一定了解，才能准确提出你的疑问。对开源项目一无所知是无法参与开源的。当然，这与你是否成为“大牛”也并没有什么关系。因此，只要具备一定的技术积累，就可以参与相应的开源项目。 “罗马不是一天建成的”。没有人天生就是“大牛”，“大牛”们也是在参与中不断成长的，不要被虚无的 title 所困扰，只有不断的坚持和探索才能让自己不断成长！ 其实旅游中也有过一些自己的思考，在旅游中我喜欢摄影，带着相机走走拍拍。或许和女生不一样 ，我开始的时候其实是更倾向于发现风景的，就像是在香港的麦理浩径的第一段和第二段的中间破边洲部分，我更多的是以人物在破边洲的悬崖边上，然后衬托后面的悬崖的美丽壮观。我们在工作中也是一样的， 在我们摄影的时候，我们面临对焦，开始在远方我们或许更多的是把焦点放在人物后面的背景上，或者说是 title，比如说某个人是某个大学、某某大厂的光环，反而忽略了他的本身。后面当你关注在人物身上，你会发现人物的美，你会想办法如何把漂亮的小姐姐这一瞬间记录下来。这个时候其实你更专注的是某一个人，这个转变很重要，你慢慢的发现自己专注自己了，而不是专注后面虚无缥缈的光环和头衔。 在开源社区中，我慢慢学习到了非常多的技巧，比如这里我总结出一篇开源社区的提问技巧：/zh/ai-technology/posts/the-art-of-asking-questions-in-open-source-communities/ 我对整个的开源成长也有自己的思考总结，写了这篇关于开源的成长性指南阶段，从我们第一次加入开源项目开始，到最后开源和维护自己的项目，以及商业化成长，可以参考： /zh/growth/posts/stage-growth-of-open-source//zh/growth/posts/stage-growth-of-open-source/ 非常推荐阅读 ~ 在加入 OpenIM 的社区一年中，我将自己的开源理解和运营技巧都集成在了 OpenIM 的开源布道上，将 OpenIM 社区带入到了一个顶级的开源社区中来。除此之外，我参与过其他的优秀开源项目的贡献和维护，我会从自己的角度上来介绍如何运营一个优秀顶级的开源社区。 开源不仅是我的热爱，也逐渐成为我的一大优势。在我与开源的互动中，我们相得益彰。 开源除了给个人以及公司带来技术影响力之外，更为重要的是通过开源实现商业化价值，而这部分才是很多开源项目成功的实际驱动力。本文会介绍我对开源的理解，以及着重介绍自己对开源以及开源商业模式做了一个系统的研究，为决策项目是否应该开源、采用何种开源策略以及开源商业化路径提供参考意见。 如果你对我有兴趣，可以关注我的开源的 github 账户： https://github.com/cubxxw 开源商业模式 越是用户付费意愿强的功能，越是要闭源。越是用户觉得好玩的功能，能吸引到大家的功能，越是要开源。 我认为的开源商业模式是什么样的？ 开源商业化模式文章后面会总结目前的所有的商业化模式，但是我觉得最主要的商业模式是 open-core 和 open-standard，还有一些非主流的，比如说开源软件免费，但结合硬件组合销售。 我认为： 越是用户付费意愿强的功能，越是要闭源。 越是用户觉得好玩的功能，能吸引到大家的功能，越是要开源。 我认为的开源商业模式是什么样的？ 开源商业化模式文章后面会总结目前的所有的商业化模式，但是我觉得最主要的商业模式是 open-core 和 open-standard，还有一些非主流的，比如说开源软件免费，但结合硬件组合销售 开源也有自己的护城河吗？ 担心开源后自己的产品被抄袭，开源，作为一个推动技术创新和社区合作的新力量，其商业模式多样，从提供专业支持和服务，到构建围绕核心开源项目的企业级产品。 我认为在开源的护城河上面，关键在于如何利用产品开源的独特价值和社区力量，创建难以复制的竞争优势。 所以基本上就是你要不是有开源 core 产品，作为线索漏斗去吸引你的用户，然后用这来做你整个公司的品牌，然后再做差异化功能的落地实践，然后另一种可能就是类似 MySQL 做咨询顾问的工作。 那么开源产品本身的护城河我理解其实抛开和普通产品护城河区别外，Open standard是今天开源软件商业化更好的一个形态，它对这个公司的技术能力提出了更高的要求。 open core 其实在云时代很难发展，即使是目前 OpenIM 那种做好 传统的 open core 模式在云时代下会比较难，可能难就难在构建好护城河，比如说跟那些云厂商比。各大云厂商，从各方面看，都有巨大优势：它本身就是一个大的流量资源，客户的流量在这里，推广的流量在这里，如果你很不幸，刚好跟这个云厂商贴在同一个赛道，你怎样去获得一个这个优势？这很困难，也是 MongoDB、Elastic、Redis 等开源厂商被逼的修改开源 License 背后的深层次原因。 ...

我的 2023 年度总结 2023 很快就要过去了，转眼间大学生活只剩下最后半年了，我一个朋友说过，工作的越久越是觉得：*可怕的不是你失去了工作的激情，而是再也找不回来了。* 这一年经历了很多，接触了很多人，遇到过很多事情，慢慢的对自己的三观有种雏形。很喜欢马斯洛需求层次理论(Maslow’s hierarchy of needs) 从中找到自己的状态。我喜欢挑战，无论是工作还是业余爱好（爬山，骑车 …）我似乎已经成功地满足了马斯洛需求层次理论中的前四个级别：生理需求、安全需求、社交需求和尊重需求。我目前所处的阶段很可能是自我实现需求。但是值得一提的是，虽然马斯洛的理论是分层的，但实际上人的需求可能不会那么线性或固定。例如，即使一个人达到了自我实现的阶段，他们仍可能在不同时间遇到其他层次的需求。例如，如果一个人失去了工作或遭遇经济困难，他们可能会重新关注安全需求，比如财务安全和稳定。同样，如果一个人经历了亲密关系的结束或社交网络的变化，他们可能会重新感受到对社交需求的渴望。甚至在日常生活中，像是在生病或饥饿时，我们的注意力可能会暂时从更高层次的需求，如自我实现，转移到生理需求上。 我认为我们应该认识到，虽然人们可能在不同时间点上侧重于不同的需求层次，但这并不意味着他们在个人发展上有所倒退。相反，这是一个自然的、动态的过程，反映了人生的复杂性和多变性。在面对挑战和变化时，能够灵活地调整自己的需求焦点，是适应和个人成长的一部分。所以，顺其自然，把握节奏，不断学习，不断思考，是我的成长生存名言。 户外很大一个程度上，放松了我的思想，让我能站在一个局外的角度看待整个棋局。纵穿整个成长的周期，我们就像是深处在一个棋局上，每一个角色都不可或缺，但却都有自己的局限性。 今年有一种冲劲，很讨厌温水煮青蛙的生活，以及安于现状的人生，偶尔出现一点点的 idea，或者是灵光一闪，偶然间有一个冲动想自己创业做下去。这些想法也被我一点点的记录在本子上，我总觉得以后可能有机会会翻起，那时候会孤注一掷的去做。处在马斯洛的自我实现需求的层级上，渴望做出自己的事业。事业和工作，事业指人们所从事的具有一定目标，规模和系统的对社会发展有影响的经常活动；而工作指在长时间内做着重复的一系列动作或事情。很明显，我们都知道，如果人生是一个游戏，那么后者的角色就是一个 NPC，做的永远都是重复，没有任何价值的增效的工作，不利于个人成长，对社会的进步也是微乎其微。做事业和做生意也是有所区别的，生意是以短期赚钱为导向，事业是以人生高度为导向。 在重庆游玩的时候，也是和一个非常厉害的创业前辈交流过（经历和认知，文化水平卓越），明白了，对于以赚钱为驱动，那么就是在做生意；如果是以梦想，热爱，坚持为驱动，那么就是真正的做事业，赚钱，只是这个过程中的水到渠成。作为一个螺丝钉，在一线上工作，尽管象棋中的兵看似不起眼，但它们是实现战略目标的基础。在创业中，前线员工（开发、测试、运维）和日常运营团队就像这些兵，他们执行日常任务，是企业运行的基石。但是，如果只是做士兵，那么当然可以安于现状，但是，如果你期望做出自己的事业来，那么当然是不够的，只专注于日常的业务操作而没有更广阔的视野，可能会错失重要的战略机会。你还需要跳跃出你的思维和格局，要结合象的远见、马的创新思维和车的执行力。这意味着你需要能够制定长远的战略规划（象）、灵活地应对突发情况并创造性地解决问题（马），以及直接推动业务前进（车）。甚至是要有战略性思维，如果是作为企业的战略领导者，类似于象棋中的国王。具备全局视角，设定公司的长远目标和战略方向。虽然国王在棋盘上的移动有限，但却是游戏的核心。同样，作为创业者，我们可能不会直接参与每一个细节，但是，作为决策者的的决策和愿景对公司至关重要。从此，无论是工作中还是项目中，我常常是将自己带入到棋盘中的各个角色，去认真感受棋局以及每个角色的变化。 在职业生涯中，遇到面试官反问的环节，我比较喜欢询问的几句话： 在您看来，员工为什么选择留在这家公司？他们对工作最热情的方面是什么？ 您为什么要选择这家公司，您个人在这里工作的最大动力是什么？您认为同事们最看重公司的哪些方面？ 您能描述一下这里的工作环境吗？员工通常是怎样描述他们在这里的工作体验的？ 您作为老板，能告诉我您的创业经历吗，为什么要选择创业，创业意味着什么? 您能分享一下公司领导的领导风格吗？他们是如何激励团队和推动创新的？ 这些问题潜在的可以帮助你了解员工和老板的工作状态，思想。 在中国传统教育框架体系中，成功的定义是，拥有自己的事业。当然在课本上也并非如此，成功其实是一种感觉，可以说是一种积极的感觉，它是每个人达到自己理想之后一种自信的状态和一种满足的感觉！总之，我们每个人对于成功的定义是各不相同的！在简易的成功学中，成功的定义是：*天赋，努力和运气* 。用我们平常 code 的思维理解，三者中或只有 努力 是可以读写操作的，而天赋和运气都是可读的，但并不能写操作。所以，对于我们大部分普通的人来说，都是 “尽人事，听天命” 的状态。记得有首励志的歌这么说的：你尽管努力，剩下的交给天意 。 于是，这就是今年形成的思想，勇敢的去做，不要怕失去，努力也是一种投资，就像二级市场的 K 线图一样，有涨有跌。拿三种曲线举例，第一条曲线前期曲曲折折，突然在一个转折点扶摇而上，直冲云霄；第二条曲线前期曲曲折折，后期也是曲曲折折，不上不下；第三条曲线前期也是曲曲折折，突然一个转折点暴跌，坠入低谷；我们大部分人都渴望走第一条曲线的道路，但是，前期的曲曲折折，是否会迎来某一个转折点，没有人知道。有时候我们可能会感到停滞不前，甚至是跌宕起伏，但这并不意味着失败。稳定可以是成长和自我反思的机会，也可能是积蓄能量、准备下一次跳跃的阶段。勇敢地面对挑战，不惧怕失去，将努力视为一种投资，是通向成长和成功的关键。生活和职业道路有其起伏，这些在儒家思想中可见，对待得与失、荣与辱、成与败等等，乃至人生的吉凶祸福，人们应注重“求诸己”，不假外力，更不应怨天尤人。重要的是如何应对这些起伏，以及我们从这个过程中学到了什么。 接下来以下面的几个议题快速的对自己做年度总结: 首先，专业上，最具有代表性的是我的专业名片，github 地址 Github 的贡献的小绿点： 我的 gihtub 2023 徽章： 一、开源项目贡献 以 github 代表为例，今年的 ossinsight 表现： 项目参与： 2023 年主要参与的开源项目: openim , 参加了阿里的开源项目 sealer ，网易的 gitops 项目 horizon ，贡献了 kubernetes 项目、k8sgpt 。提出了基于 AI和大语言模型的智能客服 openkf …… 技术成长： ...

引言：深圳福田会展中心的全球视野 2023年12月6日，在深圳福田会展中心，GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英，共同探索互联网行业的前沿动态和未来发展趋势。身为参与者，我有幸深入这场融合科技与商业的交流盛会，特别是“聚焦开源，扩展出海新领航”这一议题，让我收获颇丰，印象深刻。 大会聚焦于全球化的多元话题，包括出海市场的选择、广告推广策略等，与我此前参加的专注于日本市场出海活动的公司非常相似。然而，这次大会让我首次深入接触开源社区，不仅结识了众多开源界的领袖和布道者，也与许多杰出的开发者交流了心得。通过这些交流，我不仅学习到了许多新知识，还在思想上得到了升华。 在这篇博客中，我将对这次独特的经历进行深入的反思和总结，分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说，我们现阶段正在全力准备奔向海外市场，希望打开国界，将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的，这是一种松散的结构。以 OpenIM 的开发者为例，我们现在有很多贡献者，开发者，虽然社区有双周会，但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言，并不能简单的使用这种远程工作模式。在商业公司中，协作会更加的密切，而且对时效性的要求更高，当面沟通更能保证信息传递的完整性，这是远程工作难以替代的。当然，远程工作也有自己的优势，那就是吸引全球的人才。 所以，开源商业公司采用远程协作并没有问题，但一定要保证沟通的足够充分，拉平信息： 要视频沟通，文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式，是远程工作交流的首选方式。千万不要用文字来讨论非技术问题，这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中，大家因为没有雇佣关系，都是无偿做贡献，所以在异步沟通时特别强调尊重和善意；而在商业公司的远程办公时，因为缺少同事之间的沟通、吐槽和心理按摩，就更要注意沟通的尊重。 定期线下见面，增加相互之间的了解和信任。 另外一点，长期的远程协作，对于参与的工程师来说，除了需要很高的自律和自我管理的要求外，也要注意工作和生活的隔离，保持正常的社交活动和运动健身，否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天，她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去，这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作，以及企业的文化，强烈推荐阅读下面的博客： Englist Version 中文版本 出海挑战：中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存，它们不断在新的市场环境中寻找增长点。这一过程中，企业需要超越传统的商业模式，适应多元文化和不同的市场需求。 首先，来到了第一个话题，为什么要去做海外社区？ 和很多的开源社区的布道者和专家沟通交流，然后反思，我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天，开源不仅是关于代码的分享，更是一种文化和思想的交流。通过建立海外社区，我们不仅能将技术带到世界的每个角落，还能促进不同文化背景下的思想碰撞和创新。 人性化地讲，建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者，不论身处何地，都希望他们的声音被听见，他们的贡献被认可。海外社区提供了一个平台，让来自世界各地的开发者能够参与到项目中来，分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身，还激发了更多创新的火花。 同时，海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享，而这些价值观在全球范围内都是通用的。当我们向海外扩展时，我们不仅在分享代码，更在传播这种包容和合作的精神。 此外，对于开源项目而言，海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下，用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的，它们有助于项目更全面地成长，更好地服务于全球用户。 我从大一开始接触 Github ，这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源，觉得开源比业务代码更有意义。因为开源不仅有技术积累，而且能把你学到的东西分享给其他人，一起成长，所以开源对程序员来说是一个双赢的事。 最开始的时候，我通过学习做笔记，分享笔记到 GitHub ，到后面做项目，参与到一些顶级的开源项目中来，然后慢慢的追求精益。整个过程，我很清晰的看到自己的成长。 甚至我的代码，就像 Git 或者 区块链的默克尔树结构，一步步的串起来记录，每当一个时间段，看到以前的 PR ，满满的都是回忆和尴尬 … 同样，我也是一个云原生的爱好者。 在如今这个时代，开源已经成为了一个不可逆的潮流，尤其是在云原生的领域。以微软为例，他们在 Github 上的开源项目贡献位居全球前列，这充分体现了他们对开源的全面拥抱。在云原生时代，如果你不拥抱开源，不利用开源组件去构建和优化你的核心系统，很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论，而开源社区正是这种创新和合作的孵化器。在这个时代，开源不仅仅是技术选择，更是一种必要的战略思维。 开源社区国际化选择：第一站，启航 美国：开源发展的领头羊 美国仍然是全球最大的开发者社区，拥有超过2000万的开发者，过去一年增长了21%。美国的开源社区历史悠久且成熟，是全球开源活动的重要推动者。 亚太地区：快速增长的新星 亚太地区，尤其是印度、日本和新加坡，正经历着显著的开源社区增长。印度的开发者社区增长尤为显著，预计到2027年将超过美国，成为全球最大的开源社区。 非洲：充满潜力的新兴市场 非洲各地区，尤其是尼日利亚、加纳和肯尼亚，也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲：稳健增长的活跃区域 南美洲的开发者社区，特别是在阿根廷和巴西，也在持续增长，与亚太和非洲的增长速度相仿。 欧洲：稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢，但在西班牙、德国和英国等国家仍保持稳定增长。 Github 年度总结分析 2023 年 Github 年度报告精华： 生成式 AI 项目和个人贡献者数量的显著增长 ...

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情： 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件（FAQ）以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者，请尝试阅读源代码以找到答案。 当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（搜索 Google 论坛 和网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐得舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）。 准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。 绝不要自以为够格得到答案，你没有；你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动的从他人处索取知识。 另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情，你很可能被忽略掉或者被看作失败者： 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括阅读 FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，那就向别处发送，或者压根别发。 在选择论坛、新闻群组或邮件列表时，别太相信它的名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。 一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索，然后在 Stack Exchange 问。 近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。 ...

社区不规范怎么办 作为 OpenIM 社区首席运营官，对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流，以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题，即使你觉得自己的 贡献者文档 写的很牛逼了，很全面了，但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍，于是就有了今天的这个文档，我会将它记录在 GitHub Gists 上，提供拉取和使用的说明、链接，并且定期的维护它。 首先，我提供克隆的链接： git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能，那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记，并且分享在 GitHub 上面，在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范，寻找合适的 CICD 流： 统一格式： 统一格式：git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证，这是一个很好的习惯。 ...

✨ 熟悉我的人都知道，我是一名不折不扣的开源爱好者，从大一开始接触到 GitHub 后，逐渐的沉迷于 开源世界 ~ 今天这篇文章很特别，算是自己参考并且总结出来的开源阶段，以及学习开源项目的步骤和心得。未来自己也是按照自己的规划来进行成长。 同学习 Kubernetes 的成长轨迹 一样，这篇文章将会长期更新，也可以参与贡献 ~ 目前我是处于第一阶段，处于一种对开源世界和对知识的沉淀与积累的过程中，这个阶段的主要表现是我们开始学一些基础。但是我喜欢做笔记将它们记录下来，供自己日后翻阅和复习，当然也是制作自己的内容价值。 GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 这一阶段，并不是意味着我开始迈入第二阶段，第一阶段就 come to an end. 我认为以下所讲的所有阶段就像是人生轨迹，并不是意味着你当爸爸了就不是父母的孩子，你依旧可以扮演着多种角色，并且不断完善和改进自己的角色。开源项目也是如此，类比我们的成长经历，在后一阶段我依旧会扮演好前一阶段的角色。所以我会坚持做自己的内容创作和知识共享 ~ ✨ 下面开始介绍适合大多数人的开源项目的不同阶段，为了方便定位，我将上面知识积累称呼为 0 阶段知识积累阶段。下面开始从第一阶段开始讲起~ 第一阶段：简单看源码阶段 💦 在这一个层次的我们，是一个刚毕业或者没毕业的大学生，又或者是刚刚踏入职场，我们是一个新手，对于开源项目保持一心热血但是不知道从何开始。 方法： 简单看源码 说明： 简单看源码、文档、跑跑样例代码 学习效果： 1 ~ 2 有产出： 没有产出 是否达成学习闭环： 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 Get 到的技能点： 阅读源码的技能 案例： 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 阶段 第一阶段：简单看源码阶段 方法 简单看源码 说明 简单看源码、文档、跑跑样例代码 学习效果 1 ~ 2 有产出 没有产出 是否达成学习闭环 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 技能点 阅读源码的技能 案例 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 第一阶段的建议是简单地看源码、文档、跑跑样例代码来学习。这个阶段的主要目的是积累基础知识，建议尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环。阅读源码的技能是这个阶段最重要的技能点。建议阅读一些开源项目，例如 sealer、sealos、Kubernetes、k3s、horizoncd 等，并进行测试。 ...

参与本项目 ⚡ 前言 欢迎来到我们的项目！本项目旨在建立一个基于区块链的全民学习平台，通过集体的智慧和努力，推动技术和知识的普及。无论你是初学者还是经验丰富的开发者，你的贡献都将对项目产生积极影响。 💡 关于本项目（先看❗） 本项目由一个热衷于区块链和软件开发的团队发起。我们致力于创建一个开源、去中心化的学习环境，让每个人都能够访问和分享知识。 🌐 联系方式 Website Blog Telegram 🔍 项目背景 我们相信，通过集体智慧和技术的力量，可以打造一个更加开放和包容的学习环境。这个项目不仅是一个技术挑战，也是社区合作的成果。 🌟 如何参与 不论你的技能水平如何，都有多种方式可以参与本项目： 提交问题和功能建议。 参与代码编写和文档撰写。 在社区中提供帮助和支持。 我们都是这个仓库未来很有潜力的客户，或者是贡献者，谢谢你选择了加入C-UB社区，我们将会一起合作，未来我们将会考虑以区块链为底层搭建一个全民学习平台，我们每一个人都将会是这个社区的构建着，将会推动c-universal blockchain（链学） 社区的发展和进步~ 如果你对本项目有任何建议或发现文中内容有误的，欢迎提交 issues 进行指正。 对于文中我没有涉及到知识点，欢迎提交 PR。 或许我们会很疑惑？ 在我们参与贡献的时候，如果克隆了**🧷 cs-awesome-Block_Chain 项目，但是每次获取上游代码很麻烦怎么办？如何提交有意思的代码？这篇文章将会解决这个问题~⬇️ ** ⚡提前需要你… 你需要学会使用markdown🖱️ 你需要学会使用git 你的代码符合Google代码规范 排版 笔记内容按照 中文文案排版指北 进行排版，以保证内容的可读性。 不使用 ![]() 这种方式来引用图片，而是用 <img> 标签。一方面是为了能够控制图片以合适的大小显示，另一方面是因为 GFM 不支持 <center> ![]() </center> 这种方法让图片居中显示，只能使用 <div align="center"> <img src=""/> </div> 达到居中的效果。 ...