AI & Technology

输入一个网址，AI 在几秒内把它重建成一个能跑、能预览、能继续对话修改的现代 React 应用。 这是 firecrawl/open-lovable 给人的第一眼印象——27k star、5.2k fork，TypeScript 占比 94.9%，是 Firecrawl 团队做的一个旗舰开源示例。它对标商业产品 Lovable.dev（README 里直接写明「完整云方案请用 Lovable.dev」），处在 Lovable、Bolt.new、v0、Replit Agent 这条极其拥挤的「AI 应用生成器」赛道里。 但我想拆的不是「它能生成代码」这件事——那已经不稀奇了。我真正感兴趣的是它的工程姿态：它没有用任何 Agent 框架，没有 LangGraph，没有 Claude Agent SDK，甚至没有用模型原生的 tool-calling。它只用了 Vercel AI SDK 的一个原语 streamText()，然后把一个可用编码 Agent 所需要的全部脚手架自己手搓了出来。 如果你读过我之前那篇《Agent Engineering 全景地图》 ，会记得一个核心论点：模型是买来的，harness 是你造的，工程杠杆全在那 98.4%。open-lovable 就是这句话一个绝佳的、可以逐行验证的真实样本。这篇文章会沿着四个维度把它拆开：产品定位 → Agent 架构 → 自研 harness（独立成章）→ 云端沙箱（独立成章），最后落到可借鉴点。 本文的代码级事实，主要来自对其仓库与 DeepWiki 索引的交叉阅读，关键出处都会标注。 一、产品视角：一个伪装成应用的增长漏斗 它到底是什么 一句话：输入一个网址或一句话描述，AI 在云端沙箱里生成并实时预览一个可运行的 React 应用。三种核心用法： 克隆模式：用 Firecrawl 抓取目标网站的 Markdown + 截图，让 AI 重建为现代 React 应用； 品牌延展（Brand Extension）：只提取目标站的色彩、字体、间距等设计 token，再用这套品牌规范生成全新页面； 搜索生成：先搜索、再抓内容、再生成。 真正聪明的是它的商业意图 open-lovable 本身不直接变现。它是 Firecrawl 的获客漏斗与技术名片——你要跑它，就必须配一把 FIRECRAWL_API_KEY。于是 27k star 几乎都会顺手成为 Firecrawl 抓取 API 的潜在用户。 ...

「绝大多数 Agent 项目死在 PoC 和生产之间的那段没有地图的荒野。」 这句话是我反复读 Relay 项目文档时自己写下来的。Relay 是一个开源的求职 AI Agent 系统——不是那种「3 行 LangChain 代码 + GPT-4」的演示，而是一个有完整架构文档、172 个工程任务、混合技术栈、并且对每个设计决策都给出了明确反例的项目。 它还没有完全跑起来。Agent 层的代码还在写。但这恰恰是我觉得值得写这篇文章的原因：这是一个在设计层面思考非常深的系统，而那些深度思考本身——无论这个项目最终走向何方——都是对所有在做 Agent 工程的人有价值的参考。 这篇文章不是产品介绍，是一次架构拆解。 一、问题背景：为什么求职场景特别适合做 Agent 系统 在聊架构之前，我想先回答一个更基础的问题：为什么求职是一个适合 Agent 而不只是 AI 工具的场景？ 求职的本质是一条多阶段、多工具、高认知负担的工作流： 简历准备 → 职位搜索 → 简历定制 → 表单填写 → 投递追踪 ↑ ↓ └──────── 面试准备 ← 面试邀请 ←────────────────┘ 每个节点都需要大量「低价值的机械劳动」——搜索、复制、粘贴、调格式、填表单。同时，每个节点的「高价值判断」——这份职位适合我吗？这段经历该怎么呈现？这道面试题我应该怎么练？——都是高度个人化、依赖上下文的问题。 这正是 Agent 系统应该介入的地方：把机械劳动自动化，把高价值判断辅助化，把不可逆操作透明化。 Relay 的北极星是：「质量优先而非数量优先——精准的一发，胜过无脑的一百发。」 这个定位本身就决定了它的架构不能是「一键批量投递」，而必须是「每一份投递都经过用户确认」。 二、整体架构：五层设计 Relay 的架构分五层，从底向上依次是： ┌──────────────────────────────────────────────────────────┐ │ 第 5 层：UI 层 │ │ Next.js 16 Web 控制台 + Manifest V3 浏览器扩展 │ ├──────────────────────────────────────────────────────────┤ │ 第 4 层：API + 编排层 │ │ Hono/Bun TypeScript API + Redis Event Bus │ ├──────────────────────────────────────────────────────────┤ │ 第 3 层：Agent 执行层 │ │ Python FastAPI + LangGraph（5 个 domain agent） │ ├──────────────────────────────────────────────────────────┤ │ 第 2 层：共享服务 │ │ Auth、Notification、Audit、LLM Router │ ├──────────────────────────────────────────────────────────┤ │ 第 1 层：数据 + 外部集成 │ │ PostgreSQL + pgvector、Redis、MinIO、OpenRouter │ └──────────────────────────────────────────────────────────┘ 最核心的设计决策是混合后端：API 层用 TypeScript（Hono + Bun），Agent 层用 Python（FastAPI + LangGraph），两层通过 HTTP + Redis + 共享 PostgreSQL 连接。 ...

「与其说我们在写提示词，不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签，而我们真正在做的，是装修。」 如果你在 2024 年问我「怎么用好 AI」，我大概率会跟你聊提示词：怎么写指令、怎么设定角色、怎么给例子。但如果你今天再问我同一个问题，我的回答会完全不同。 因为这一年里，一线工程实践已经悄悄换了一个词——Context Engineering（上下文工程）。它不是提示词工程的升级版营销话术，而是一次重心的真正迁移：从「怎么把一句话写好」，转向「怎么决定模型在每一次推理时究竟看到什么」。 这篇文章想做两件事。第一件，用逻辑核把这门正在成形的学科拆开：它到底是什么、和提示词工程的边界在哪、有哪些已经在生产环境跑起来的设计模式。第二件，用感性核回到我自己——作为一个把 AI 当成环境而非工具、坚持 local-first 的人，我为什么认为上下文工程的尽头，是一条叫「世界线」的东西。 一、先把边界划清楚：Prompt 与 Context 不是同一件事 最容易混淆的，是把上下文工程当成「提示词工程的高级版」。它们确实相关，但不是同一层的东西。 Anthropic 在它那篇被广泛引用的工程文章里给了一个干净的区分：提示词工程是「编写和组织 LLM 指令的方法」；而上下文工程是「在 LLM 推理过程中，对最优 token 集合进行筛选与维护的一整套策略」——这个集合包括系统提示、检索到的文档、对话历史、工具定义、记忆，以及所有可能落进上下文窗口、但不属于「提示词」的信息。1 Andrej Karpathy 在 2025 年 6 月那条被反复转发的推文里说得更直白：「+1 支持用『上下文工程』取代『提示词工程』……这是一门精细的艺术与科学：用恰好正确的信息，填满下一步所需的上下文窗口。」2 而 Sourcegraph 在 2026 年的实践文章里，给了一个我特别喜欢的、可操作的判据： 「如果你在替换名词和形容词，你还在做提示词工程。如果你在改变 agent 检索什么数据、以什么顺序、用什么重排、以及当窗口被填满时淘汰什么——你在做上下文工程。」3 重心从「措辞（wording）」转向了「布线（wiring）」。 这一句话，是我读完所有材料后觉得最值得记住的。提示词工程关心的是字面；上下文工程关心的是管道——数据从哪进来、经过哪些处理、在窗口里待多久、什么时候被踢出去。 这不是文字游戏。当你的 agent 只是一个单轮聊天框时，写好一句话几乎就是全部工作。但一旦它有了工具、有了记忆、有了检索层，写提示词就只剩下整个系统里很小的一块；剩下的全是围绕它的上下文工程。 二、为什么是「工程」：上下文是有限资源，而且会腐烂 把它叫「工程」而不是「技巧」，是有硬道理的。因为上下文窗口不是一个越大越好的容器——它是一种有限资源，且边际收益递减。 Anthropic 的原话是：「上下文必须被当作一种有限资源来对待，它的边际收益是递减的。」以及——「好的上下文工程，意味着找到那个信息量最高的、最小的 token 集合，去最大化某个期望结果的可能性。」1 支撑这个判断的，是一个叫 Context Rot（上下文腐烂） 的现象：随着上下文窗口里 token 数量的增加，模型从中准确召回信息的能力反而下降。1 这背后有一个「注意力预算」的论证——注意力是 n² 的两两关系，窗口越长，每个 token 能分到的注意力越稀薄；Chroma 那份针对性的「针在草堆里」基准研究，也独立佐证了这一点。4 这里有个反直觉但关键的细节，Anthropic 自己也强调了：最小，不一定等于短。 你要的不是把上下文砍到最短，而是砍到「信息密度最高」——留下高信号的，扔掉低信号的。 对我来说，这一条把「Context is the bottleneck」从一句我一年前在自己笔记里写下的判断，变成了一个有物理基础的结论。瓶颈从来不在模型本身有多聪明，而在于：在这一次推理里，它有没有看到那条恰好正确的信息。 你给它一百万 token 的噪声，不如给它一千 token 的信号。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话我第一次读到时愣了一下，然后越想越觉得它锋利。它把整个领域里最大的一个错觉戳破了：很多人以为做 Agent 就是把 prompt 写好、把 LLM API 调通——而真正把一个 demo 推到生产、能在无人值守下安全跑一整夜的工程量，99% 都不在那个 loop 里。 这篇文章想做一件事：把 Agent Engineering 当成一门学科来拆，而不是当成一个教程。我不会教你怎么用 LangGraph，我想给你一张地图——这门学科由哪八根支柱构成、每一根填补了前一根留下的什么缺口、它的最小实现长什么样、又会在什么时候失效。读完之后，你看任何一个 Agent 框架、任何一篇大厂工程博客，都能立刻定位它在这张地图的哪个位置。 地图的素材，一半来自我自己造 Agent 系统时反复踩的坑，另一半来自 2025 到 2026 这一年里 Anthropic、OpenAI、Cognition、Manus、Temporal 这些一线团队公开出来的实践。我会尽量把每个关键论点的出处标清楚——因为这个领域里，错传的"事实"比真相传得更快，这一点我们马上就会撞上第一个。 一、那个被反复引用的数字：98.4% 先从一个流传极广的数字开始，因为它是这篇文章的标题，也是整个领域最好的一句开场白。 2026 年有一篇逆向拆解 Claude Code 的论文 《Dive into Claude Code》（VILA-Lab，arXiv: 2604.14228），分析对象是 Claude Code v2.1.88——大约 1900 个 TypeScript 文件、51 万行代码。它的摘要里有一段我愿意原样抄下来的话： 「系统的核心是一个简单的 while 循环，它调用模型、运行工具、然后重复。然而绝大部分代码，都活在这个循环周围的系统里：一个有七种模式和一个基于 ML 的分类器的权限系统、一条用于上下文管理的五层压缩流水线、四种可扩展机制（MCP、插件、技能、钩子）、一个带 worktree 隔离的子 agent 委派机制，以及面向追加的会话存储。」 注意这里有个重要纠偏：那个广为流传的精确数字「1.6% 是 AI 决策逻辑、98.4% 是基础设施」其实不在论文摘要里，它是二次概述时的渲染。而且网上很多人把它归给 minusx 的博客、或者"UCL 团队逆向泄露源码"——这些归属都是错的。minusx 那篇《Decoding Claude Code》写得很好，但里面根本没出现过任何百分比；论文也不是基于泄露源码，而是分析公开的 TypeScript。 ...

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 还是"同一个"吗？ ...

I. Argo CD 与 GitOps 简介 在现代云原生应用开发和部署领域，Kubernetes 已成为容器编排的事实标准。然而，随着应用规模和复杂性的增长，如何在 Kubernetes 上实现高效、可靠且可重复的持续交付（Continuous Delivery, CD）成为了新的挑战。Argo CD 应运而生，旨在解决这一核心问题。 什么是 Argo CD？Kubernetes 的声明式 GitOps 工具 Argo CD 被明确定义为一种用于 Kubernetes 的声明式、基于 GitOps 的持续交付（CD）工具 1。它的核心功能是通过将 Git 仓库中定义的期望状态（Desired State）与 Kubernetes 集群中的实际运行状态（Live State）进行同步，从而自动化应用程序的部署过程 1。 这种声明式的特性是其根本。与命令式工具（需要编写脚本指定如何部署）不同，使用 Argo CD 时，开发者在 Git 中声明最终状态应该是什么样子，而 Argo CD 则负责计算并执行达到该状态所需的步骤。这代表了一种核心的范式转变。 Argo CD 是一个开源项目，最初由 Intuit 公司创建 1，现已成为云原生计算基金会（Cloud Native Computing Foundation, CNCF）的毕业项目 1。CNCF 的毕业状态标志着该项目具有稳定性、强大的治理结构和广泛的社区采纳度，使其成为一个可靠的技术选型 15。 核心解决的问题：声明式管理 Kubernetes 部署 传统的 Kubernetes 部署方法可能涉及手动执行 kubectl apply 命令或编写复杂的部署脚本。这些方法往往容易出错、缺乏可审计性，并且难以在多个环境间保持一致性 1。Kubernetes 本身也受益于自动化、一致的部署工作流 1。Argo CD 正是针对这一痛点，满足了将应用程序定义、配置和环境进行声明式管理和版本控制的需求 2。 ...

需求 🔥 我们需要对 kubernetes 进一步的学习和深造，看源码是必须的道路。 👀 与其重要的，是对 kubernetes 资源的收集。 ⚠️ 所有资源均是采用外链连接，书本资源或不放连接，其他均为自己感受和总结。如有侵权请联系删除。 🚧 ⚠️ **注意，这篇文章将永久保存在 notion，将会不断地更新下去，提供了可写通道，如果你有更好的资源，欢迎补充在notion上 ~** CloudNative 学习途径 关于kubernetes： 官网 GitHub 社区维护的 kubernetes 学习资源合集 Kubernetes源码必读的 Google 大规模集群管理器 Borg etcd：从应用场景到实现原理的全方位解读 和 ZooKeeper典型应用场景一览 关于 CNCF 的贡献，你需要签署 CLA Kubernetes CLA 的签署流程 官方开发者向导 markdown 文件 Kubernetes ownes 所有者md介绍 自己写作的一些资源： 云原生学习 golang 学习 都收纳到 awesome 仓库中，覆盖 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 访问 GitHub👀 https://github.com/cubxxw/awesome-cs-cloudnative-blockchain ⏬⏬⏬ ...

什么是Langchain？ LangChain 为开发者提供了一个强大的框架，用于快速构建和部署复杂的基于语言模型的应用程序，满足了需要集成多种语言处理功能至一体化解决方案的需求。 LangChain 的 PMF： 核心用户和使用场景：LangChain 设计用于简化使用语言模型进行应用开发的过程。它特别适合于需要将多个语言技术集成到一起的开发者和企业，例如集成聊天机器人、自动内容生成工具等。 市场需求：随着 AI 和机器学习技术的发展，市场上对于能够简化和加速语言模型应用开发的工具的需求持续增长。LangChain 通过提供一个结构化的方式来组合不同的语言能力（如理解、生成、概括等），满足了这一需求。 竞争优势：LangChain 的优势可能在于其框架的灵活性和扩展性。对开发者而言，这意味着可以用较少的代码实现更复杂的语言处理任务，这是其吸引用户的一个关键因素。 用户反馈和市场接受程度：衡量 PMF 的一个重要方面是用户的反馈和产品的市场接受程度。如果 LangChain 的用户基础持续增长，且用户反馈积极，那么可以认为它在实现良好的产品市场契合度方面是成功的。 LangChain简化了LLM应用程序生命周期的每个阶段： 开发：使用 LangChain 的开源构建块和组件构建您的应用程序。使用第三方集成和模板开始运行。 生产化：使用 LangSmith 检查、监控和评估您的链，以便您可以充满信心地持续优化和部署。 部署：使用 LangServe 将任何链转变为 API。 langchain 框架组成 具体来说，该框架由以下开源库组成： langchain-core ：基础抽象和LangChain表达式语言。 langchain-community ：第三方集成。 合作伙伴包（例如 langchain-openai 、 langchain-anthropic 等）：一些集成已进一步拆分为自己的轻量级包，仅依赖于 langchain-core 。 langchain ：构成应用程序认知架构的链、代理和检索策略。 langgraph：通过将步骤建模为图中的边和节点，使用 LLMs 构建健壮且有状态的多角色应用程序。 langserve：将 LangChain 链部署为 REST API。 更广泛的生态系统： ...

AI & Technology description: > 本文探讨了大型语言模型（LLM）的变革能力，这些模型旨在理解和生成人类语言，展示了人工智能技术的先锋角色。通过利用大量数据和复杂的机器学习架构，这些模型展现了远超前任的涌现能力。 大语言模型简介 大语言模型（LLM，Large Language Model），也称大型语言模型，是一种旨在理解和生成人类语言的人工智能模型。 LLM 通常指包含数百亿（或更多）参数的语言模型，它们在海量的文本数据上进行训练，从而获得对语言深层次的理解。目前，国外的知名 LLM 有 GPT-3.5、GPT-4、PaLM、Claude 和 LLaMA 等，国内的有文心一言、讯飞星火、通义千问、ChatGLM、百川等。 为了探索性能的极限，许多研究人员开始训练越来越庞大的语言模型，例如拥有 1750 亿参数的 GPT-3 和 5400 亿参数的 PaLM 。尽管这些大型语言模型与小型语言模型（例如 3.3 亿参数的 BERT 和 15 亿参数的 GPT-2）使用相似的架构和预训练任务，但它们展现出截然不同的能力，尤其在解决复杂任务时表现出了惊人的潜力，这被称为“涌现能力”。以 GPT-3 和 GPT-2 为例，GPT-3 可以通过学习上下文来解决少样本任务，而 GPT-2 在这方面表现较差。因此，科研界给这些庞大的语言模型起了个名字，称之为“大语言模型（LLM）”。LLM 的一个杰出应用就是 ChatGPT ，它是 GPT 系列 LLM 用于与人类对话式应用的大胆尝试，展现出了非常流畅和自然的表现。 LLM 的发展历程 语言建模的研究可以追溯到20 世纪 90 年代，当时的研究主要集中在采用统计学习方法来预测词汇，通过分析前面的词汇来预测下一个词汇。但在理解复杂语言规则方面存在一定局限性。 随后，研究人员不断尝试改进，2003 年深度学习先驱 Bengio 在他的经典论文 《A Neural Probabilistic Language Model》中，首次将深度学习的思想融入到语言模型中。强大的神经网络模型，相当于为计算机提供了强大的"大脑"来理解语言，让模型可以更好地捕捉和理解语言中的复杂关系。 2018 年左右，Transformer 架构的神经网络模型开始崭露头角。通过大量文本数据训练这些模型，使它们能够通过阅读大量文本来深入理解语言规则和模式，就像让计算机阅读整个互联网一样，对语言有了更深刻的理解，极大地提升了模型在各种自然语言处理任务上的表现。 与此同时，研究人员发现，随着语言模型规模的扩大（增加模型大小或使用更多数据），模型展现出了一些惊人的能力，在各种任务中的表现均显著提升。这一发现标志着大型语言模型（LLM）时代的开启。 LLM 的能力 涌现能力（emergent abilities） 区分大语言模型（LLM）与以前的预训练语言模型（PLM）最显著的特征之一是它们的 涌现能力 。涌现能力是一种令人惊讶的能力，它在小型模型中不明显，但在大型模型中特别突出。类似物理学中的相变现象，涌现能力就像是模型性能随着规模增大而迅速提升，超过了随机水平，也就是我们常说的量变引起质变。 ...

如果你想在寻找一篇针对 OpenIM 并且准备好具体的问题想来这里找到答案的话。那么很遗憾的告诉你，这篇并不是记录问题和编写答案的，这篇是读者经过开发和业务实战中以 OpenIM 为例总结出来的故障排查的方法，以及调试的技巧。如果你想从我这里学习到故障的排查以及问题定位的经验，那么请你继续读下去。 我将会从工作中经常出现的一些情况总结成类型来分析。 一个小小的玩笑，或许我比较逆人性，其他人都很害怕遇到 bug 的时候，我倒是对出现 bug 比较兴奋，我们后期读代码的时间和维护代码的时间其实是远远高于写代码的时间的。所以面对 bug， 我们的思考和总结尤其是非常重要，尤其是帮我们在写代码的时候也思考，代码的扩展性，和错误处理，是否可以禁得起考验 ~ 故障排查的基本概念 故障排查，我主要是分为几种情况，分别是，编译的故障排查，启动的故障排查，以及服务运行故障排查。这几种情况的故障排查思路都是大同小异的。 首先，我们需要发现问题，然后定位问题。我们可能需要经过多轮分析排查才能定位到问题的根因，最后去解决问题。排障流程如下图所示： 开始 | V 发现问题 ------> 记录问题的症状和相关情况 | V 定位问题 | V 进行初步分析 --------> 确定可能的原因 | | V | 是否需要深入分析？-----> 是 ------> 进行深入分析 | | | | | V | | 确定具体原因 | | | | | V | <-------- 是否已找到根本原因？ | | | 否 | V 是否解决了问题？ | 是 ------> 记录解决过程和解决方案 | | 否 ------> 调整策略或寻求帮助 | V 结束 如果想排查问题并解决问题，你还需要具备以下两个基本能力： 能够找到组件日志，并理解错误日志的内容； 根据错误日志，找出解决方案。 发现问题 要排查问题，我们首先要发现问题，我们通常用下面这几种方式来发现问题： 代码审查：在开发过程中进行代码审查可以发现代码中的问题和潜在的错误； 安全审计：通过安全审计可以发现软件或系统中的安全漏洞和风险； 服务状态检查：可以通过检查服务的运行状态，来发现问题。例如：如果是 linux-system 模式部署 openim，那么启动 openim-api 服务后，执行 ``systemctl status openim-api 发现 openim-api 启动失败，即 Active 的值不为 active (running)`； 代码测试：通过进行各种类型的测试，如单元测试(util-test)、集成测试(api-test)、系统测试（e2e-test）等，可以发现软件或系统中的问题。例如：访问 openim-api 服务，发现接口返回异常错误码、接口值返回不对等； 自动化测试：我们也可以通过运行自动化测试，来帮助我们快速发现问题； 日志记录：在服务或接口异常时，我们需要排查日志。通过在日志中发现一些 WARN、ERRORV、PANIC、FATAL 等级别的错误日志来发现问题； 监控告警：通过监控指标、告警等，也可以发现问题。如果通过日志，能发现已经发生的问题，通过监控，还可以发现一些潜在的问题； 用户反馈：产品或功能发布后，用户在使用过程中，也可能会发现一些问题，并将问题反馈给开发人员。 上面发现问题的途径多种多样，有些发现问题的途径，通常发生在特定的软件阶段，例如：测试阶段，我们可以通过测试、质量保障团队来发现问题。产品发布后，可以通过用户反馈来发现问题。 ...