锡安的自留地 https://gendlee.github.io/ 这是一个由NotionNext生成的站点 Wed, 15 Apr 2026 14:37:59 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, zion <![CDATA[0024 Claude Code顶级Harness工程图纸 ：来自那泄漏的51万行代码]]> https://gendlee.github.io/claude-code-design https://gendlee.github.io/claude-code-design Mon, 06 Apr 2026 16:00:00 GMT
近期泄漏的51万行Claude Code源代码为我们揭开了这个顶级AI编程助手的神秘面纱。本文将深入剖析其核心架构设计和工程实现原理。

🏗️ 整体架构设计

核心组件架构

Claude Code采用了模块化的Harness架构，主要包含以下几个核心层次：
  • Agent层：负责任务规划、决策制定和执行协调
  • Tool层：提供文件操作、代码执行、搜索等基础能力
  • Context层：管理会话上下文、代码库索引和知识检索
  • Execution层：安全沙箱环境，执行代码和命令
  • Interface层：与用户交互的前端接口
 

Harness框架特点

从代码中可以看出，Harness框架具有以下显著特点：
  • 高度可扩展性：插件化的工具系统，易于添加新能力
  • 安全隔离：多层沙箱机制确保代码执行安全
  • 状态管理：完善的会话状态持久化和恢复机制
  • 错误处理：细粒度的异常捕获和优雅降级策略

架构图（概览）

 

🔧 核心技术实现

1. 智能代码理解系统

Claude Code使用了多层次的代码理解机制：
  • AST解析：通过抽象语法树深度理解代码结构
  • 语义分析：结合类型系统和符号表进行语义理解
  • 依赖图构建：自动分析模块间依赖关系
  • 上下文索引：建立代码库的高效检索索引

2. 任务规划与执行引擎

系统采用分层的任务规划策略：

3. 工具调用系统

Claude Code实现了一个强大的工具调用框架：
  • 工具注册：动态注册和发现可用工具
  • 参数验证：严格的类型检查和参数校验
  • 结果处理：标准化的返回值格式
  • 错误重试：智能的失败重试和回退机制

4. 安全沙箱机制

多层安全防护确保代码执行安全：
  • 容器隔离：使用Docker容器隔离执行环境
  • 资源限制：CPU、内存、网络等资源的严格限制
  • 文件系统保护：只读挂载和路径白名单机制
  • 权限控制：最小权限原则和能力限制

💡 关键设计模式

Agentic Pattern

Claude Code采用了Agent设计模式，使系统具备自主规划和决策能力：
  • 感知（Perception）：理解用户意图和当前环境状态
  • 规划（Planning）：制定达成目标的行动计划
  • 执行（Action）：调用工具执行具体操作
  • 反思（Reflection）：评估结果并调整策略

Tool Use Pattern

标准化的工具使用模式：

📊 性能优化策略

代码索引优化

从源码中可以看到多项索引优化技术：
  • 增量索引：只索引变更的文件，避免全量重建
  • 多级缓存：内存、磁盘多级缓存策略
  • 并行处理：多线程并行索引大型代码库
  • 智能预加载：根据使用模式预测性加载代码

上下文管理优化

  • 上下文窗口管理：智能选择最相关的代码片段
  • 压缩算法：高效压缩历史会话数据
  • 分层存储：热数据内存，冷数据磁盘

🔐 安全与隐私保护

数据安全

  • 端到端加密：敏感数据传输加密
  • 本地优先：尽可能在本地处理敏感代码
  • 数据脱敏：自动识别和脱敏敏感信息
  • 访问控制：细粒度的权限管理系统

代码执行安全

  • 静态分析：执行前的危险代码检测
  • 运行时监控：实时监控异常行为
  • 回滚机制：支持操作撤销和状态恢复

🚀 工程亮点总结

通过对51万行代码的分析，Claude Code的工程亮点包括：
  1. 模块化架构：清晰的分层设计，高内聚低耦合
  1. 智能Agent系统：具备自主规划和决策能力
  1. 强大的工具生态：可扩展的工具框架
  1. 完善的安全机制：多层防护确保执行安全
  1. 高性能实现：多项优化技术支撑大规模代码库
  1. 优秀的错误处理：健壮的异常处理和恢复机制

📖 延伸阅读

这次代码泄漏为我们提供了难得的学习机会，让我们能够深入了解顶级AI编程助手的工程实现。无论是架构设计、技术选型还是工程实践，都值得我们深入研究和借鉴。
如果你对AI Agent系统设计感兴趣，可以从以下几个方向深入学习：
  • Agent架构模式与最佳实践
  • Tool Use Pattern的实现细节
  • 代码理解与索引技术
  • 安全沙箱的设计与实现
 
]]> <![CDATA[0023 OpenClaw底层原理]]> https://gendlee.github.io/open-claw-info https://gendlee.github.io/open-claw-info Sun, 05 Apr 2026 16:00:00 GMT

OpenClaw 底层原理：从 Agent 运行时到工具调用的全链路拆解

🦞
本文面向希望“看懂 + 跑通”的读者：先讲 OpenClaw 的核心抽象与运行时机制，再给出一套可复现的本地实操教程，并补充常见坑位与调优建议。

1. OpenClaw 是什么：它解决了哪类问题

OpenClaw 可以理解为一套 Agent Runtime（智能体运行时）：
  • 把“大模型能力”封装成可控的 任务执行系统。
  • 用 工具（Tools）、记忆（Memory）、规划（Planning）、执行（Execution） 等模块，把一次对话变成可重复、可观测、可评估的流程。
  • 将“模型输出文本”升级为“在约束内完成目标”的工程化能力。
典型适用场景：
  • 多步骤任务自动化（信息收集、对齐、生成、校验、落库）。
  • 带外部依赖的工作流（调用 API、数据库、文件系统、浏览器）。
  • 需要回溯与审计的生产任务（可观测、可重放、可评测）。

2. 核心抽象：OpenClaw 的关键对象

从底层实现视角，OpenClaw 通常会围绕这些“稳定抽象”组织：
  1. Agent
      • 对外暴露的执行入口。
      • 绑定模型、工具集、策略与状态。
  1. Model Adapter（模型适配层）
      • 统一不同厂商、不同接口范式（Chat Completions / Responses / Function Calling）。
      • 产出结构化的 assistant_message，包含 tool call 或普通文本。
  1. Tool（工具）
      • 标准化的可执行动作：name、schema、handler。
      • 运行时会进行参数校验、超时控制、重试、隔离。
  1. Planner / Policy（规划与策略）
      • 决定“要不要调用工具、调用哪个工具、何时停止”。
      • 常见实现：ReAct、Plan-and-Execute、Graph/State Machine。
  1. Memory（记忆）
      • 短期记忆：当前对话窗口内的信息。
      • 长期记忆：向量检索、知识库、历史轨迹。
      • 关键在于“写入策略”和“读取策略”。
  1. State / Trace（状态与轨迹）
      • 每一步的输入、输出、工具调用、耗时、错误，形成可观测链路。
      • 支持回放、评测与问题定位。

3. 运行时全链路：一次请求是如何被执行的

下面用“任务 → 规划 → 工具 → 汇总”的典型链路说明底层原理。
关键点拆解：
  • Prompt 不是一次性模板：运行时会把系统提示、工具描述、上下文、记忆检索结果、上一步工具结果按策略拼装。
  • 工具调用是强约束出口：LLM 只能“声明要调用工具”，真正执行由 Tool Executor 完成。
  • Stop 条件是工程策略：不是“模型说结束就结束”。可以结合最大步数、置信度、评估器结果、预算等限制。

4. 工具调用（Tool Calling）的底层机制

4.1 工具的“接口契约”

工具本质是一个可被运行时调用的函数，但必须具备可机器理解的协议：
  • name: 全局唯一标识。
  • description: 给模型看的行为说明。
  • input_schema: JSON Schema 或等价的参数约束。
  • handler(ctx, args): 真正执行。
这样，运行时才能做到：
  • 参数校验（缺字段、类型不对、越界）。
  • 结果格式化（让模型更稳定地消费工具结果）。
  • 观测与审计（每次调用可追踪）。

4.2 Tool Executor 的工程职责

Tool Executor 往往比你想象得“重”，核心职责包括：
  • 参数校验与反序列化：将 LLM 输出的 arguments 变成安全的结构化输入。
  • 超时与取消：防止工具卡死拖垮链路。
  • 重试与幂等：对可重试错误做退避重试，并避免重复副作用。
  • 沙箱隔离：不同工具可在独立进程或容器内执行。
  • 结果截断与脱敏：避免把过长或敏感数据直接喂回模型。

5. 记忆系统：如何“记得住”又“不乱记”

建议把记忆设计成三层：
  • 会话记忆（Conversation Buffer）：始终存在，但窗口有限。
  • 摘要记忆（Summarization Memory）：对长会话做压缩，保留决策与结论。
  • 检索记忆（RAG / Vector Store）：把事实与文档索引起来，按需检索。
一个实用的写入策略：
  • 只有当信息满足“长期可复用”才写入检索记忆。
  • 只有当信息满足“对后续决策重要”才写入摘要记忆。

6. 规划与执行：从“想”到“做”的两段式

常见的工程落地方式是：
  1. 规划（Plan）：先输出一个可执行计划（若干步骤）。
  1. 执行（Execute）：按步骤逐个执行，每步允许调用工具，并把结果写入状态。
优点：
  • 可控：可以审计计划，也可以让人类在关键步骤审批。
  • 可评测：每个步骤可以做单独指标（成功率、成本、耗时）。
  • 可恢复：失败时只重试失败步骤。

7. 架构图：推荐的工程分层

落地建议：
  • Runtime 只做编排与通用能力，不要把业务逻辑写在 Runtime。
  • Tool 层与业务系统集成要“窄接口”，避免把业务复杂度泄漏给模型。

8. 实操体验教程：本地跑一个最小可用 Agent

下面是一套“最小闭环”示例：
  • 一个 Agent
  • 两个工具：calculator 与 http_get
  • 一次任务：先计算，再拉取网页，再总结
说明：不同 OpenClaw 版本或实现会有差异。你可以把下面示例当作“工程骨架”，按你的实际 SDK/接口名替换。

8.1 环境准备

  • Node.js 18+ 或 Python 3.10+
  • 一个可用的大模型 API Key

8.2 定义工具（示例：Python）

8.3 运行时循环（工具调用 + 继续推理）

核心是一个 loop：
  1. 把 tools 描述传给模型。
  1. 如果模型返回 tool call，就执行工具。
  1. 把 tool result 再喂给模型。
  1. 直到模型返回最终答案，或达到最大步数。

8.4 你应该看到什么

  • Trace 里有清晰的步骤：
    • tool: calculator
    • tool: http_get
    • assistant: final answer
  • 每一步都有耗时与 token 使用（如果你的运行时接入了观测）。

9. 常见问题与调优建议

  1. 模型乱编工具参数
      • 给工具 schema 加严格约束。
      • 对关键字段做白名单校验。
  1. 工具结果太长导致上下文爆炸
      • 工具层做截断与结构化摘要。
      • 把原文放存储，模型只拿到引用与摘要。
  1. 循环不停止
      • 设定 max_steps。
      • 增加“完成条件”评估器（例如：是否已满足用户要求）。
  1. 成本与延迟过高
      • 先用小模型做规划或筛选，再用大模型做关键生成。
      • 缓存工具结果与检索结果。

10. 结语：把 OpenClaw 当作“可控的执行系统”

理解 OpenClaw 的底层原理，关键不在于“提示词写得多漂亮”，而在于：
  • 通过稳定抽象把模型放进工程体系。
  • 通过工具与状态让执行可控、可观测、可评测。
  • 通过记忆与规划让任务可复用、可扩展。
 
]]> <![CDATA[0022 AI淘金新时代：DeepSeek+工具矩阵的7大变现路径]]> https://gendlee.github.io/deepseek https://gendlee.github.io/deepseek Sun, 22 Dec 2024 00:00:00 GMT

AI淘金新时代：DeepSeek+工具矩阵的7大变现路径

一、智能创作矩阵（0基础启动）

工具组合：DeepSeek+Gamma+Midjourney+CapCut
  • PPT工业化生产：
  1. 用DeepSeek生成结构化大纲（/format ppt指令）
  1. Gamma自动排版设计（支持团队协作功能）
  1. Midjourney定制主题插画
      2. 变现案例：某团队承接企业路演PPT，单份报价3000-8000元，日产能达5份
  • 短视频流水线：
  1. DeepSeek生成分镜脚本（包含场景/台词/特效提示）
  1. RunwayML生成视频素材
  1. CapCut智能剪辑（AI自动卡点功能）
      2. 实战数据：某MCN机构用此模式单月产出300+带货视频，ROI提升400%

二、专业服务增强方案

工具组合：DeepSeek+Wolfram Alpha+Overleaf
  • 教育服务升级：
  1. 数学建模：DeepSeek解析问题→Wolfram验证计算
  1. 论文辅导：Latex模板自动生成（Overleaf协作）
      2. 定价策略：复杂问题按步骤收费（50-200元/题）
  • 商业咨询2.0：
  1. 输入企业数据→获取SWOT分析框架
  1. 自动生成可执行方案（附甘特图代码）
  1. Tableau可视化呈现
      2. 服务溢价：某咨询公司收费标准提升60%，交付时间缩短70%

三、技术开发生态

工具组合：DeepSeek-API+GitHub Copilot+Replit
  • 敏捷开发流程：
  1. 自然语言转技术文档（自动生成API文档）
  1. Copilot实时代码补全
  1. Replit云端调试（支持协同编程）
      2. 接单技巧：在Upwork承接紧急开发需求，报价可达$50-150/小时

四、科研加速方案

工具组合：DeepSeek+ResearchRabbit+Zotero
  • 文献综述革命：
  1. 输入关键词获取领域知识图谱
  1. 自动生成文献评述框架
  1. Zotero智能引用（支持跨格式导出）
      2. 学术服务：指导SCI论文写作，单篇收费5000-20000元

五、变现渠道矩阵

  1. 知识付费：Notion模板商店出售工作流
  1. 众包平台：承接Fiverr复杂订单
  1. 企业服务：通过Pipedrive管理定制化需求
  1. 自媒体运营：用AI生成的内容矩阵获客

六、风险控制指南

  1. 版权声明：使用AI生成内容需添加免责条款
  1. 质量校验：重要交付物保留人工审核环节
  1. 数据安全：通过ZeroTrust架构保护客户隐私

七、进化路线图

  • 2024Q3：建立自动化工作流（Zapier集成）
  • 2024Q4：训练垂直领域微调模型
  • 2025：构建AI代理协作网络
当前行动清单：
  1. 选择2-3个优势领域建立最小可行性产品
  1. 在LinkedIn/电鸭平台创建专家身份
  1. 用AI生成100个精准客户画像
]]> <![CDATA[0021 跨境支付流程]]> https://gendlee.github.io/inter-payment https://gendlee.github.io/inter-payment Thu, 31 Oct 2024 00:00:00 GMT

情景假设

跨境扫码支付场景

1. 付款方用户支付的是人民币。
2. 付款方的借记卡是国内银行 A 发行的，简称买家开户行。
3. 第三方支付公司的备付金账户在国内银行 B，简称第三方开户行。
4. 收款方接受的是美元。
5. 收款方的借记卡是国外银行 C 发行的，简称卖家开户行。
6. 第三方公司是通过银行 D 进行外币兑换业务，简称汇兑提供行。
 
由于国内对人民币相关的外汇交易有管制，本外币交易需要满足一定要求，比如要求电商平台有对应的交易明细。为了方便你理解，我们假设已经在其他部分完成了相应的合规流程。那么接下来，我会分 4 个部分给你讲解整个支付过程：用户扫码支付、第三方公司进行本币代收、外汇交易以及外币代付。
 

用户扫码

扫二维码支付显然是以用户扫码作为整个业务的起点。从终端用户的角度来看，扫码由鉴权、支付和拉取状态三个步骤组成。接下来，我们就来详细看看这几个步骤。

鉴权

扫码支付最终会用买家的银行卡进行支付。在你开始扫码支付之前，第三方公司需要核实你是否有这张卡的使用权，俗称“绑卡”。
那第三方公司是怎么验证用户的使用权呢？
在国内，我们一般采用下面这 4 个要素来进行验证：用户姓名用户身份证号码银行卡号码银行注册的手机号这 4 个要素都是银行记录的信息，因此虽然看起来你是在第三方支付公司的 App 上进行绑卡操作，其实是银行在背后进行相关信息的验证工作。
由于这 4 个要素都是电子信息，可能会被人盗用，所以为了进一步增强安全性，银行在验证手机号码的时候还需要验证你是否拥有这个手机号码。具体的方式是发一条验证码给在你在银行柜台办借记卡时注册的手机号码。
 
结合前面的内容，我们可以把鉴权的过程分为 4 步：
第 1 步，用户填写前 3 个要素和手机号码；
第 2 步，银行发短信验证码给用户手机号；
第 3 步，用户将前 3 个要素和短信验证码发给第三方支付公司；
第 4 步，第三方支付公司再将所有信息发送给银行进行确认。
所以鉴权的过程其实是验证了 5 个信息，其中 4 个是静态信息，1 个是动态信息。在用户绑卡通过之后，银行会返回给第三方支付公司这个用户的内部 ID 信息（也叫 Token）。之后第三方支付公司就可以拿这个 ID 进行所有合法的操作。刚才给你讲解的流程示意图如下：
notion image
 

支付

鉴权完成之后，就可以扫二维码，进行支付了。二维码其实是一个图形化的字符串，背后是这笔交易对应的订单。当用户点击“确认”之后，就会开始整个支付流程。
 

拉取支付状态

那为什么需要拉取支付状态呢？
我们还是从台前转到幕后，从系统功能的角度思考。用户 App 的支付确认按钮是有局限的，它只能确认后台是否已经收到了支付请求，并不能确认支付是否已经成功。这是因为支付后台需要花一些时间和银行沟通，在这个期间后台并不知道银行的支付流程进行到了哪一步。
由于不知道支付什么时候才能完成，用户 App 需要每隔一段时间就向支付后台拉取交易情况，我们通常会把这个过程叫作轮询。这个过程一般在几百毫秒内就能结束，所以你一般察觉不到延时。
那为什么会出现轮询这种系统对接方式呢？金融机构每天会面对大量的用户资金操作，这些操作的时间和频率有很大的偶然性。
 
为了应对用户操作的峰值情况，金融机构普遍通过异步消息处理的架构来对极端流量进行削峰填谷。如果流量突然增大，异步消息架构会缓存所有请求，慢慢处理。这样就能避免核心金融系统超载。异步消息架构的结果就是用户不会及时得到处理结果，需要自己不断地去查询处理情况。
当银行处理完支付后，银行会把支付成功的消息推送给用户和第三方支付公司。第三方支付公司也会推送给你支付成功的消息。所以你在扫码支付成功后，通常还能听到两个手机消息通知的声音。
到这里我们看到了两种不同的获取最新状态的方式。一种是用户定期去拉取状态，另一种是服务器将状态消息实时推送给用户。这种推拉结合的消息通知方式，其实是架构设计中常见的异步系统处理方式。支付状态获取的流程图如下
notion image

本币代收

前面我们假设了这笔支付涉及到外汇交易，由于买家的和卖家使用的币种不同，就无法直接转账。这时候就需要第三方支付公司这个中间人来帮忙了。中间人角色要做 3 件事情：
1. 本币代收
2. 外汇交易
3. 外币代付
 
我先给你说说本币代收，也就是第三方支付公司代收用户资金。通俗一点来说，本币代收就是将你该付的钱先打到第三方支付公司账上。
由于第三方支付公司的账号和买家的银行卡在两家不同的银行，本币代收需要进行跨行转账。跨行转账会涉及到整个银行系统的大小额系统和超级网银等，非常复杂。所以这里我们对场景进行一些简化，但是会和现实有一些出入，主要是方便你理解。
 

央行和清算机构

跨行转账的时候，钱是在不同的银行。因此我们想要实现跨行转账，就需要解决两个问题:
第一个问题是怎么将钱在两家银行之间转来转去，另一个问题是转的金额是多少。
我们先看第一个问题，那就是怎么跨行搬钱。最直接的方法是用汽车将钱从一家银行的金库搬到另一家银行。但这个方法其实不太实用，汽车能运的钱重量有限，路上也不太安全。所以钱最好不要挪动地方。这时候又需要另一个第三方机构出马了。所有银行都在这个新的第三方机构里放足够多的钱，一般叫做存款准备金。
当两家银行之间需要转账的时候，第三方机构在内部搬运一下就好。比如美国的黄金交易所就是这种工作模式，每个客户都有自己专属的黄金仓库，很多小车在仓库之间搬运黄金。
如果这个第三方机构足够可信，那么连内部搬运都不需要。这个第三方机构只需要记录一下谁的钱有多少，以及从哪里搬了多少到另一个地方就行。信用级别最高的金融机构就是国家的中央银行，简称央行。所以央行解决了真实资金的转移问题。
 
我们再来看另一个问题，那就是怎么知道转移的金额有多少。
会有这个问题的原因是每天银行之间的跨行交易非常多，不可能每一笔都通过央行转一次钱。
所以银行系统对跨行转账的流程进行了优化。那就是在白天只做记录，不进行任何实质性的跨行转账。等每天结束的时候计算一下两个银行之间交易金额的差额是多少，最后通过央行进行一笔跨行转账就可以了。
这种计算交易差额的方式叫做轧差。这个记录白天跨行转账细节和晚上进行交易轧差的第三方机构叫作清算机构。你熟悉的银联及网联，以及国外的万事达，它们都是清算机构。前面我们在介绍拉取支付状态的时候，讲过金融系统采用异步消息处理架构应对支付流量。轧差是另一种金融机构应对大流量的一种处理方式。
轧差的本质是实时消息的批量处理，从某种程度来讲是延时更大的异步处理框架。
 

跨行转账

流程讲完央行和清算机构之后，我们就可以对跨行转账过程做一个详细的梳理了。整个过程分为七步：
第一步，第三方支付公司发送指令给第三方开户行，要求将钱从用户的买家开户行转到第三方开户行。
第二步，第三方支付公司拥有用户在买家开户行的 Token，所以可以合法发起这笔转账。跨行转账流程开始。
第三步，第三方开户行将所有信息交给清算机构。清算机构作为第三方负责记录这些信息，并通知买家开户行和第三方开户行记录这笔转账。
第四步，买家开户行记录的结果是对用户的账号进行扣款。扣款结束后用短信的方式通知用户。
第五步，第三方开户行记录的结果是对第三方支付公司的账号进行打款。打款结束后第三方支付公司可以通过银行网页看到对公账户金额发生变化。白天的工作到此结束。此时买家开户行的账面上的资金虽然减少，但是减少的钱并没有实质性到达第三方开户行。
第六步，到了晚上，清算机构对白天发生的交易进行盘存，发现有一笔从买家开户行到第三方开户行的跨行转账还没有真正完成。清算机构会将这笔未完成的跨行转账信息发送给央行。
最后一步，央行收到信息之后，将买家开户行在央行的存款准备金调低，并将第三方开户行在央行的存款准备金调高。这样钱就真正地从买家开户行转到了第三方开户行。这七步的示意图如下：
notion image

外汇交易

转账交易的第二步是第三方支付公司进行外汇交易。当第三方支付公司完成了用户的本币代扣之后，第三方支付公司账上就有了对应的人民币。接下来的一步是将这些人民币变成美元，这样才能将美元转给国外的卖家。那么外汇交易的过程又是怎样的呢？按照交易量的大小，可以分为 C 端外汇零售业务和 B 端外汇批发业务两个部分。
 

C 端外汇零售业务

外汇交易和电商一样，也是一个买卖的过程。第三方支付公司作为中间人，需要用人民币购买美元。那美元从哪里购买呢？人民币有外汇管制，不能随意买卖，需要通过一些有特殊资质的银行才行。如果外汇不涉及到人民币，那么选择面会宽泛很多，银行、投行或者其他金融机构都可以。
账务原理建议一个账号只处理同一个币种的交易。
外汇交易涉及到两个币种的货币，因此需要两个不同的账号。
假设了第三方支付公司是通过汇兑提供行进行外汇交易的。那么第三方公司需要在汇兑提供行里建两个账号，一个人民币账号和一个美元账号。
同时，汇兑提供行内部也需要有对应两个币种的账号，一个对应着人民币资金池，另一个则是美元资金池。所以，一笔外币的购买涉及到 4 个账号之间的 2 笔支付订单。交易过程的示意图如下：
notion image
 
外汇交易完成之后，第三方支付公司在汇兑提供行的人民币账户金额减少，美元账户金额增加。这样第三方支付公司就有了足够的美元来支付给卖家。
我们需要注意的是，外汇交易是有成本的。第一个成本是时间成本。当天购买的外汇可能隔天才到账。
另一个成本是交易成本。外汇交易一般会按照交易次数收费。
因此为了节省成本，第三方支付公司通常会提前购买大量的外汇，用来应对日间的业务。只有当外汇储备下降到警戒线之后再做下一笔大额外汇的购买。
讲到这里，我们解决了第三方支付公司美元账户不足的问题，但是它用来购汇的人民币账户一直在往外出钱，总会有枯竭的一天，又该怎么办呢。
所以我们还需要考虑从外部调资金进来。由于第三方支付公司的备付金账户在第三方开户行，因此需要做从第三方开户行到汇兑提供行的跨行转账，示意图如下：
notion image
 
但是第三方公司在第三方开户行的账户也在一直出钱，我们往上推演一步，就会发现第三方开户行账户也需要有进来资金的渠道。这个是由前面我们提到的本币代收的过程实现的。我们把买家出资的流程补充完整。整个过程的示意图如下：
notion image
 
这样梳理下来，你是不是觉得我们已经考虑得足够全面了呢？
其实这里还有一个问题需要我们考虑：汇兑提供行帮助第三方支付公司实现了外汇购买。但是汇兑提供行的美元账户一直在出钱。那这个美元账户钱不够了怎么办？这时候汇兑提供行需要从其他银行寻求帮助。这个过程就涉及到了 B 端外汇批发交易。
 

B 端外汇批发业务

前面提到的电商相关的外汇交易属于外汇的零售业务。银行、投行和其他外汇提供商之间形成了一个有层级的跨国组织，专门从事外汇的批发业务。批发业务的业务量非常巨大，通常每天都有几万亿美元的规模。
外汇市场是按照交易量大小来划分层次的。最底层的是面对终端用户的外汇零售商。这些零售商负责给一般用户提供小额的外汇交易。这些小笔的外汇交易汇集在一起之后，就会形成一笔大的外汇订单，然后继续往上层交易。
和底层的外汇零售商一样，上一层的机构将所有外汇交易汇集在一起之后，形成更大的外汇订单，再往更上一层交易。一直往上汇集这种事情不会永无止境地进行下去。
这个流程的尽头是全球最大的外汇做市商，一般是巨型的跨国商业银行。这些跨国商业银行面对的是全球不同国家大量的储蓄用户，所以它们手上就拥有不同币种的巨额存款。这些做市商之间通过交换不同币种的大额固定利息存折来实现外汇交易，从而决定最终汇率。示意图如下：
notion image
 
之前我给你提到过外汇交易有时间成本，当天购买的外汇需要隔天才能到账。在这一天的时间间隔之内，外汇市场可能会有巨大的波动，从而造成金融机构账面上的资金亏损。所以，参与外汇业务的金融机构都会处理外汇相关的市场风险，比如用期货、期权等衍生品来对冲风险。这些金融衍生品，我们会在后面的章节详细展开，这里你先有个印象就行。
为了方便你理解，我们把到目前为止的流程画一个简单的示意图：
notion image

外币代付

外币代付流程和本币代收流程在原则上是一样的。不同点在于外币代付的金额是美元，流出账号是第三方支付公司的美元账号。由于卖家的账号在卖家开户行，第三方支付的美元账号在汇兑提供行，这时候需要走的是国际的清结算过程。流程的核心思想和之前的类似，只是具体的细节会更加复杂。下图展示了简化版的支付流程。
notion image
 

小结

用户在扫码支付前需要证明自己合法拥有银行卡，需要给开卡行提供 4 要素：姓名、身份证、银行卡号和手机号。验证通过后便可以开始支付流程。支付完成后用户可以通过轮询的方式异步获取支付状态。
异步处理是金融机构应对支付流量的一种架构设计。
在第三方支付公司收到支付请求后，开始进行本币代收业务。由于账号设立的关系，需要进行跨行转账。此时清算中心和央行一起提供了跨行转账功能。
跨行转账一般采用了日间交易、日终轧差结算的方式进行。轧差处理是金融机构应对支付流量的另一种架构设计。
第三方支付公司在完成本币代收业务之后，还要进行汇兑业务，具体分为外汇零售业务和批发业务。如果涉及外币代付业务，第三方支付公司还需要借助国际清结算组织的相关功能。
你需要注意的是，二维码支付涉及的大多数环节都是异步系统，比如用户 App 的异步支付状态查询，以及清算中心和央行及银行之间的跨行转账清结算过程。异步系统不会将结果同步返回给调用方。因此，我们在设计系统的时候，就需要支持状态的查询以及状态消息的推送功能。
总结脑图
notion image
 
（原文：https://time.geekbang.org/column/article/323701）
 
]]> <![CDATA[0002 LRU算法浅析]]> https://gendlee.github.io/lru https://gendlee.github.io/lru Thu, 14 Oct 2021 00:00:00 GMT
✏️原理概述：LRU（Least Recently Used)，最近最少使用原则实现的缓存淘汰算法。
 
❌“最近最少”的误解：很多人看字面意思很可能理解为“最近使用和最少使用的被淘汰”，理解几乎完全相反了。
 
✔️“最近最少”的正确理解：基于这一种准则：刚使用过的、最新添加的元素，被（再次）使用到的概率更大，因此要放到队列读取的最前端，最先淘汰队列尾端的元素（说明它被添加的时间很长了而且很少被访问到过，若是新添加的、经常被访问过的应该在靠近读取端头部）。
 
看这样一个例子：面试题 16.25. LRU 缓存

✏️下面是图解:

notion image
 

💠实现方式① ：利用LinkedHashMap的accessOrder

💠实现方式②：继承LinkedHashMap重写

LinkedHashMap的最大价值就是缓存淘汰实现，其内部已经被实现了LRU基础功能，需要修改的是removeEldestEntry方法，即在什么情况下才会触发删除策略，我们这里是当容器满了的时候，触发删除策略。

💠实现方式③：HashMap + 双向链表

操作方式：读取在链表尾，删除在链表头，所以要增加移动到链表尾的操作。
注意，双向链表中，head和tail是哨兵节点，不存储实际值，实际链表的值在两者之间。

💠实现方式④：HashMap + 单向链表

]]> <![CDATA[0003 Redis数据结构及应用]]> https://gendlee.github.io/redis-structure https://gendlee.github.io/redis-structure Sat, 20 Nov 2021 00:00:00 GMT
以下是个人学习总结的redis知识内容，供学习参考。
 
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
参考资料：
[1] 黄健宏 《redis设计与实现》 [2] http://www.redis.cn/articles.html [3] https://www.bilibili.com/video/BV1xv41137Yj?from=search&seid=440206642219339402&spm_id_from=333.337.0.0 [4] https://try.redis.io/ (可在线玩耍) [5] https://www.lammertbies.nl/comm/info/crc-calculation (crc算法) [6] https://www.cnblogs.com/itplay/p/10030292.html (取余等价于与运算) [7] https://edgar615.github.io/raft.html (raft算法详解) [8] http://thesecretlivesofdata.com/raft/ (raft算法理解动画) [9] https://www.bilibili.com/s/video/BV1Fi4y147ad (raft算法动画视频) [10] https://github.com/alibaba/canal#readme (canal组件) [11] https://llimllib.github.io/bloomfilter-tutorial/zh_CN/ (布隆过滤器） [12] 吴军 《数学之美》——布隆过滤器在谷歌搜索中的应用 [13] https://github.com/gendlee/user_register_center/ （demo地址）
 
]]>