三个月前我画了一个「热→温→冷」的线性管道。跑下来发现，纵向晋升是必要条件，但不是充分条件。知识不是沿管道流动的液体，它是根系——向下扎根的同时，横向蔓延、交叉嫁接。管道负责把信息从对话层送到知识层，但知识到达目的地之后的关联、腐化、可发现性，是另一组问题。

起点：一条管道

最初的想法很简单：对话中的信息，提炼后存下来，需要时拿出来。

对话（热）→ 提炼（温）→ 沉淀（冷）

这个模型没有错。context-infrastructure 的 Observer→Reflector→GC Pipeline 证明了纵向晋升是可行的。温记忆压缩到 100 行，任何平台秒加载，这个设计确实好用。

但跑了三个月，三个管道解决不了的问题冒出来了。

问题一：知识孤岛

wiki 里建了 40 个页面。AI 可观测性和 Agent 护栏各自写得很好，但没人发现它们说的是同一件事——LLM 系统的可信度防御。一个管输出质量评估，一个管行为约束，底层逻辑是同构的。

纵向管道不负责这个——它的职责是把信息从热送到冷，不是让冷知识之间互相认识。这就像图书馆买了很多书，每本都分类入库了，但没有目录卡，也没有「相关推荐」。信息到了终点，但终点之间没有路。

解法：横向关联

wikilinks（双向链接）
  页面 A 引用页面 B，B 的反向链接自动显示 A
  → 不需要主动维护，写的时候随手一链就行

标签聚类
  同标签的页面自动归类
  `agent` 标签下：agent-architecture, agent-memory, agent-guardrails, harness-engineering
  → 浏览一个标签就能看到整个领域地图

横向扫描（LINT 检查项之一）
  同周创建 + 共享 2+ 标签 + 未互链 → 自动报告
  → 发现隐性关联，人脑记不住所有页面的创建时间和标签组合

跨域桥接
  科技洞察 → 投资判断（如 AI 推理成本归因 → 算力股估值逻辑）
  哲学思考 → 决策框架（如 Goodhart's Law → TDD 失效 → 管理指标陷阱）
  → 这是 wiki 最核心的价值，靠标签交叉和 wikilinks 实现

知识不是一棵树，是一张网。纵向管道处理深度，横向关联处理广度。两者不矛盾——管道把书买进来，关联让书和书之间产生对话。

需要说明的是，横向关联和活性维护之间有交叉。比如 LINT 的「横向链接缺失」检查项——它既是横向关联的发现工具（找到应该连接但没连接的页面对），也是活性维护的一部分（定期巡检）。这不是设计缺陷，是两个维度在边界处自然重叠，就像城市里「修路」（横向）和「市政巡检」（活性）本来就有交叉。

问题二：知识腐化

40 个页面，如果不维护，三个月后：

• 有些过时了（工具版本、API 变化）
• 有些互相矛盾（三月的认知和五月的新信息冲突）
• 有些变成孤岛（创建后没人再链接过）
• 标签体系漂移（随手加了不在分类法里的标签）

纵向管道只管往里灌，不管清淤。

解法：活性维护

Wiki LINT（每周自动运行，7 项检查）
  1. 矛盾检测 — frontmatter contradictions 字段 + 内容冲突扫描
  2. 孤立页面 — 入站链接 = 0
  3. 缺失概念页 — 被引用 2+ 次但不存在的 wikilink
  4. 过时内容 — updated 超过 60 天
  5. 标签一致性 — 不在分类法中的标签
  6. 横向链接缺失 — 同周 + 共享标签但未互链
  7. Index 同步 — 实际文件 vs index.md 条目差异

  → 只报告不修改，人确认后才执行

公理反馈回路
  应用记录追踪：每次公理被引用/用于决策，记一行
  → 日期 / 场景 / 触发 / 结果
  → 应用次数 ≥ 5 → 升级候选
  → 周报推送提醒评审
  → 确认升级 → 进入公理正式序列
  → 否决 → 重置计数，记录理由

  → 知识库不是博物馆，是活的系统

纵向管道的 GC 只管”这条记忆过不过期”。活性维护管的是”整个知识库健不健康”。

但不是所有冷知识都需要同等强度的维护。有些知识是稳定态——数学定理、经典文献、思维模型（比如二阶效应），写完基本不用动。有些是快速变化态——工具版本、API 变化、市场数据，一两个月就过时。LINT 检查的「过时内容」项（updated 超过 60 天）是一个粗粒度的过滤，实际操作中我会看内容性质决定是否更新，而不是机械地刷日期。

问题三：找不到

冷知识存在 Obsidian wiki 里，40 个页面，几千行内容。你说”之前讨论过 Agent 文件系统的三代演化”，我需要能找到它。

两个问题：

1. 精确回忆 — 你提到了具体关键词，FTS5 全文搜索能搞定
2. 模糊关联 — 你说”那个关于知识怎么长的模型”，关键词匹配失效，需要语义检索

解法：多层检索

MEMORY.md（Prompt Memory）
  每轮注入，~2K 字符，最紧急的信息
  → 不需要搜索，永远在眼前

Session Search（FTS5）
  历史对话全文检索
  → 精确回忆：关键词、人名、项目名
  → 跨 session 回忆：两个月前讨论过什么

ObsidianRAG（向量检索）
  287 notes → 2120 chunks
  all-MiniLM-L6-v2 本地 embedding
  → 语义搜索：描述性查询、模糊关联
  → 不依赖精确关键词

Wiki Index + Wikilinks（导航）
  index.md → 领域地图
  wikilinks → 页面间跳转
  → 浏览式探索：不知道要找什么时用

四层检索各有边界。不是谁替代谁，是不同场景用不同工具。

三维模型

把三个问题的解法合在一起：

graph TD
    subgraph 纵向晋升
        H[热记忆<br/>对话采集] --> W[温记忆<br/>核心画像]
        W --> C[冷知识<br/>Wiki 页面]
    end

    subgraph 横向关联
        WL[wikilinks<br/>双向链接]
        TAG[标签聚类<br/>同标签发现]
        LAT[横向扫描<br/>隐性关联]
    end

    subgraph 活性维护
        LINT[LINT 巡检<br/>7 项检查]
        AX[公理反馈<br/>应用追踪]
        RET[RAG + FTS5<br/>语义+精确检索]
    end

    C --- WL
    C --- TAG
    C --- LAT
    C --- LINT
    C --- AX
    C --- RET
    LAT -.->|边界交叉| LINT

• 纵向晋升（热→温→冷）：信息的密度递减、持久性递增
• 横向关联（链接/标签/扫描）：知识节点之间的语义连接
• 活性维护（LINT/反馈/检索）：保持整个系统的健康和可发现性

原文的「热→温→冷」没有错，但它只描述了一个维度。就像只说”树要扎根”——没错，但根系也会横向蔓延，土壤也需要定期松土施肥。

实际数据

跑了三个月的 Obsidian wiki：

说明几个数据点：

287 vs 40：wiki 页面只有 40 个，是经过提炼的结构化知识。RAG 索引覆盖整个 Obsidian vault（287 篇），包括日记、剪藏、非 wiki 笔记——这些是原始素材，还没消化进 wiki。两个数字不矛盾，正好对应了三层模型中的「冷知识（wiki）」和「收集层（全库）」。

公理从 43 到 25：不是简单去重。三轮审计做了三件事：合并语义重叠的条目（比如「做减法」和「简单优先」合并成一条）、淘汰实践中反复不被引用的条目、升级从实践经验中涌现的新条目。审计过程记录在 公理审计报告。

效果层面：横向关联最具体的例子是「AI 是品位的放大器」这条公理——它链接到投资领域的复利职业策略，又链接到哲学层的认知框架。三个领域的页面因为 wikilinks 形成了三角连接。这不是规划出来的，是写的时候自然发生的。但坦诚说，目前只有一个这样的跨域三角连接案例，大部分 wikilinks 还是在同领域内（AI 页面链 AI 页面）。横向关联的潜力已经能看到，但密度还不够。

和原文的关系

本文是对 跨平台AI人格与记忆架构设计 中「第二层：记忆」的实战演进。原文定义了纵向晋升模型，本文补上了横向关联和活性维护两个维度。

如果把记忆架构比作图书馆：

• 纵向晋升是入库流程 — 新书从采购（热）到编目（温）到上架（冷）
• 横向关联是目录卡和推荐架 — 让读者发现「借了这本的人也借了那本」
• 活性维护是馆员巡检 — 定期清查过时书籍、修复断裂的目录引用、补充缺失的交叉推荐

只有入库没有目录，书在架子上但找不到。只有入库和目录没有巡检，几年后目录卡和实际书籍对不上了。

至于这套体系值不值得——40 个页面的 wiki，LINT 每周运行一次，确认时间大概 5 分钟。公理反馈回路是自动追踪，只在周报时才需要人看。RAG 索引构建一次，后续增量更新。目前这个规模下，维护成本可以接受。如果 wiki 涨到 400 页，可能需要重新评估 LINT 的噪声水平和人工确认的负担。

MCP 标准化了工具调用，AGENTS.md 正在统一指令格式——但 Agent 的灵魂、记忆、知识，每个平台还是各管各的。该有人管管了。

30 秒读完

痛点： 你用 8 个 AI Agent 平台（OpenClaw、Claude Code、Codex、Cursor、Windsurf、Copilot、Trae、CatPaw），每个平台有自己的配置文件格式。换一个平台，Agent 就失忆——人格没了、偏好没了、好不容易教会的东西全没了。

本质： 不是文件格式问题，是架构问题——身份、记忆、知识没有统一的跨平台层。

解决方案：agent-sync — 一个 CLI，把 AI Agent 的身份、记忆、知识定义在一个地方（universal-agent/），自动同步到所有平台。

三层架构：

1. 身份 — Soul → Identity → User（一个源头，按平台适配）
2. 记忆 — 三维模型：纵向晋升（热→温→冷）+ 横向关联（wikilinks/标签聚类/跨域桥接）+ 活性维护（LINT/公理反馈/RAG检索）
3. 指令+技能 — Directives（怎么思考）+ Skills（怎么做），都需要你确认

和 agentinit 的区别： agentinit 只管规则同步。agent-sync 管的是身份 + 记忆 + 知识 + 技能——完整的 Agent 生命周期。

离线可用： 内网 Git + 本地 Obsidian，不需要任何云服务。

我们卡在哪

2026 年，AI Agent 的 Harness 层已经跑通了三件事：

1. 工具标准化 — MCP 被所有主流平台采纳，一个协议搞定工具调用
2. 指令格式收敛 — AGENTS.md 成为 Codex、OpenCode、Windsurf 兼容的事实标准
3. 沙箱与权限 — 各平台的审批模式、隔离机制基本成熟

但有一个问题没人解决：你换了工具，Agent 就失忆了。

在 Claude Code 里你教了它用 pnpm、写中文注释、走 feature branch 工作流。切到 Cursor，这些全没了——你得重新写一遍 .cursorrules。OpenClaw 知道你的沟通偏好和风险提示，Copilot 一点都不知道。每个工具都是白纸，每次都要从零培养。

这不是体验问题，这是架构问题。

同一件事，8 种文件名

先看现状：

本质都一样——告诉 AI 你是谁、项目怎么工作、该怎么做。但格式、位置、语法全部不同。

八个平台的真实差异

上表已经列出了基本信息。以下是踩完坑之后对几个重点平台的评价。其他平台（Codex、Windsurf、Copilot、Trae、CatPaw）要么配置极简（一个文件搞定），要么没有人格/记忆概念——核心问题都一样：没有跨平台统一层。

OpenClaw — 唯一认真对待「灵魂」的

SOUL.md → 元人格：行为边界、核心信条
IDENTITY.md → 具体人格：名字、风格、价值观
USER.md → 用户画像：服务对象是谁

OpenClaw 把「灵魂」做成了和「规则」平级的一等公民。SOUL.md 里写的是 “你不是用户的代言人”、“先试再问”，不是编码规范。这让 AI 有了性格，不是只有服从。

这是目前唯一原生支持人格分层的平台。缺点是格式非标准，只有 OpenClaw 生态能读。

Claude Code — 配置体系最成熟

全局 ~/.claude/CLAUDE.md → 项目 CLAUDE.md → .claude/rules/*.md
Auto Memory → AI 自动从交互中学习偏好

三层配置 + Auto Memory，用起来最舒服。但人格和规则混在 CLAUDE.md 里——“用 pnpm” 和 “说话别端着” 写在同一个文件，身份和指令不分家。

Cursor — 作用域控制最灵活

.cursor/rules/*.mdc → 4 种激活模式
  alwaysApply / 智能应用 / globs 匹配 / 手动 @引用

Cursor 的 .mdc 激活模式是所有平台里最精细的作用域控制——写 React 的规则只在 .tsx 文件触发，API 规范只在 api/ 目录生效。社区甚至有人用 rules 创建了完整人格（比如 “Luna” persona）。

但 Cascade Memory 是个痛点，持久化记忆需要社区插件补。

架构：三层分离

各平台差异在表层（文件名、格式），深层处理的是同一组问题：身份、记忆、知识。该把它们拆开。

第一层：人格（Identity）

人格是分层的，不是复制的：

Soul → 元人格
  行为边界、核心信条、气质
  平台无关，所有 AI 通用

Identity → 具体人格
  名字、沟通风格、价值观
  根据平台微调，核心不变

User Context → 用户画像
  服务对象、偏好、状态
  所有平台共享同一份

在一个源头定义，其他平台引用。 不是复制，是映射。

OpenClaw 是目前唯一原生支持这个分层的平台。其他平台通过适配器翻译：SOUL.md 里写的”你不是用户的代言人”，到 CLAUDE.md 里变成一段行为约束，到 .cursorrules 里变成一条 guardrail——同一个意思，不同表达。

第二层：记忆（Memory）

三个维度，不只是纵向晋升：

纵向：按密度分层
热记忆（每次对话）
  自动采集：观察、日志、决策
  ↓ Reflector 提炼
温记忆（跨会话）
  核心画像 + 关键偏好 + 风险提示
  压缩到 ~100 行，任何平台秒加载
  ↓ GC 清理
冷记忆（长期知识）
  Obsidian wiki / 知识库
  结构化笔记（entity/concept/comparison）

横向：跨节点关联
  wikilinks 双向链接 — 页面间的语义连接
  标签聚类 — 同标签跨域自动发现
  横向扫描 — 同周创建、共享标签但未互链的页面对
  跨域桥接 — 科技→投资、哲学→决策的隐性关联

活性：自洁与验证
  LINT 定期检查 — 孤立页面、矛盾、过时内容、链接缺失
  公理反馈回路 — 应用记录追踪，实践验证后晋升/淘汰
  RAG 向量检索 — 全库语义搜索，不依赖精确关键词
  Session Search — 历史对话全文检索（FTS5），跨 session 回忆

单纯的「热→温→冷」是一条管道——东西只能往上流。但知识不是这样长的。两个概念在不同领域各自发展，突然发现它们说的是同一件事（比如 AI 的 reward hacking 和管理中的 Goodhart’s Law）。这需要横向扫描，不是纵向晋升能发现的。

温记忆的存在是为了把核心信息压缩到任何平台都能快速加载的体积。活性维护的存在是为了不让知识库变成垃圾场——定期清理、验证、关联，保持知识的新鲜度和连通性。

context-infrastructure 的 Observer→Reflector→GC Pipeline 解决了纵向晋升。Obsidian wiki 的 wikilinks + 标签 + 反向链接解决了横向关联。两者结合才是完整的记忆架构。

第三层：指令 + 技能（Directives + Skills）

两个不同的东西：

Directives — 我怎么思考

不是 SOUL 里的「我是谁」，而是「我怎么思考」。不是公开知识（像 “Python 的 list comprehension 语法”），而是个人的决策偏好和认知沉淀。比如「设计哲学的天花板决定了系统的上限」——这是价值观判断，不是事实陈述。

Skills — 我会做什么

不是”我怎么想”，而是”我怎么操作”。可复用的工具流程和标准操作。比如「用 Jina Reader 抓网页 → 存 Obsidian Clippings/」——这是可执行的操作序列。

按领域组织，带唯一 ID 和路由索引：

directives/
├── INDEX.md              # 路由索引 + 关键词触发
├── ai/                   # AI 协作领域
├── technical/            # 技术决策
├── management/           # 管理哲学
└── cross-domain/         # 跨域隐喻

skills/
├── jina-clip/SKILL.md    # 网页剪藏流程
├── deploy/SKILL.md       # 部署标准操作
└── review/SKILL.md       # 代码审查 checklist

INDEX.md 做路由——“管理 AI” 这个关键词自动触发 AI 领域的相关指令。Agent 不用每次读全部文件，按需检索就行。

外挂大脑

Obsidian（或 Notion、Logseq）作为「查看层」覆盖在 Agent 执行层之上：

Agent 工作空间（执行层）      知识库（查看层）
├── SOUL.md                 ├── （引用，不复制）
├── IDENTITY.md             ├── （引用，不复制）
├── MEMORY.md               ├── （引用，不复制）
├── directives/             ├── directives/ ← 同一份数据
├── memory/diary/ ─软链─→  └── 日记/diary/

Agent 工作空间是 AI 的世界——读写文件来工作。知识库是人的世界——浏览、搜索、反思。数据只有一份，入口不同。

agent-sync

把以上架构变成一个 CLI：

┌──────────────────────────────────────────┐
│          universal-agent/（Git 仓库）      │
│                                           │
│  人格: soul → identity → user            │
│  记忆: 热 → 温 → 冷                      │
│  指令: directives/（索引 + 详情）          │
│  技能: skills/（MCP + SKILL.md）          │
└──────────────────┬───────────────────────┘
                   │
              agent-sync
             （双向适配）
                   │
   ┌───────┬───────┼───────┬────────┐
   ↓       ↓       ↓       ↓        ↓
OpenClaw  Claude  Codex  Cursor  Windsurf  Copilot

一个命令同步所有平台。改了 SOUL.md，CLAUDE.md、AGENTS.md、.cursorrules 自动刷新。记忆通过 Git 在平台间流转。

和 agentinit 的区别：agentinit 只管规则文件同步。我们管的是身份 + 记忆 + 知识 + 技能——完整的 Agent 生命周期。

记忆→技能的自动发现

温记忆中反复出现的操作模式，Reflector 会自动识别为 skill 候选：

claude-mem 观察记录（热）
       ↓ Reflector.collect_observations()
温记忆 core.md（每条自动分类）
       ↓ category = procedure / tool_pattern
       ↓ Reflector.discover_skill_candidates()
  只提取可重复流程类条目 + 出现次数 >= 2
       ↓ agent-sync skills discover
  列出候选，问用户确认
       ↓ --confirm
  skill-creator 生成 skills/<name>/SKILL.md 脚手架

不是所有观察都能变成 skill。Reflector 在晋升温记忆时就分类（insight / procedure / tool_pattern / preference），只有 procedure 和 tool_pattern 才会被推荐为 skill 候选。用户确认后才创建，避免噪声。

详细的架构设计文档见 → agent-sync Architecture Spec（GitHub）

记忆架构的实战演进

上面的三维模型是设计阶段的框架。跑了三个月后，横向关联和活性维护的实际效果超出了预期——详见 AI记忆架构的三维进化。

不适用的场景

说清楚边界：

• 纯规则场景（代码审计、CI lint）不需要人格，只需要规则
• 团队协作需要的是共识和 code review 标准，不是个人认知沉淀
• 单平台用户用不上跨平台同步

离线 & 内网环境

agent-sync 完全支持离线使用，不依赖任何云服务：

• Git 同步：用内网 GitLab CE、Gitea 或任何自建 Git，不需要 GitHub
• 知识库：Obsidian 本地 vault，不走外网
• 记忆采集：只配 OpenClaw 源（markdown 文件），跳过 claude-mem
• 冷知识输出：公司内只沉淀到 directives/，不绑 Obsidian；个人环境可以绑

# memory.yaml — 公司/离线模式
sources:
  - type: openclaw
    path: ../memory/    # 纯本地 markdown 文件

全程无外部 API 调用，无云服务依赖。

参考

• OpenClaw — 目前最完整的 AI Agent 人格系统
• context-infrastructure — Observer/Reflector 记忆 Pipeline
• agentinit — 规则同步工具（覆盖 Claude Code、Cursor、Windsurf、Copilot）
• OpenAI: Harness Engineering — Harness Engineering 概念提出

挑三个有难度的展开写，其余列在末尾表里。

#1158 — Session 切换从 800ms 到 40ms

起因

WebUI 跑在远程服务器上，我在国内，切一个长对话的 session 要等 1-2 秒，loading 闪烁看着烦。

打开 session 本来就想看最后几句话，但后端把 400 条完整历史全序列化打包传过来，前端再全部渲染——然后你才看到那几句。

这不是 bug，是设计假设和实际使用场景的错位。WebUI 最早是本地开发的工具，localhost 下传 86KB 一眨眼的事。放到远程部署，一次 HTTP 往返 200ms，86KB payload 再乘以 2 是 400ms，前端渲染几百条 DOM 节点又是几百 ms。1+1=2。

四个串行瓶颈

对着代码翻了几个小时：

1. 展开的目录挨个请求 — 每个展开的目录一个 HTTP 请求，一个等一个。5 个目录 = 5 × RTT。
2. 语法高亮堵住目录加载 — 前端先跑 Prism.js 高亮，跑完才发目录请求。两个不相关的任务硬串了。
3. Git 信息三个子进程串行 — git status、git rev-list --ahead、git rev-list --behind 用 subprocess.run 一个一个跑。三次 shell 子进程启动 = 三次开销。
4. 每次拉全场消息 — 不管 100 条还是 500 条，后端全量序列化。最长 session 压缩后还 86KB，用户能看到的屏幕范围最多 30 条。

做法

消息分页：后端加 msg_limit/msg_before 参数，默认取最后 30 条（~16KB，降 70%），前端滚动到顶部懒加载老消息。

有个麻烦：重试、撤销、压缩这些操作需要全量消息。加了一个 _ensureAllMessagesLoaded() 先全拉再做操作。代价是前端要维护 _messagesTruncated 布尔值，在所有路径下正确重置。

并行化：

• 展开目录：for...of + await → Promise.all()
• 高亮和目录加载：互换顺序，先发目录请求再跑 Prism.js，两个并行
• Git 信息：三个 subprocess.run → ThreadPoolExecutor(max_workers=3)

代码改动不大。难的是判断串行之间有没有隐含依赖——比如高亮和目录加载的顺序有没有人依赖了某种副作用。这种优化的通用矛盾：不是并行化难，而是得搞清楚为什么之前是串行的。

效果

~800ms → ~40ms，loading 闪烁消失。

PR 过程

5 个 commit 提上去。reviewer 对分页部分提了 hold——担心 _messagesTruncated 在边界路径（重试、撤销、错误恢复）没重置，界面会显示错误的加载提示。补了 cancellation safety 修复后 merge。

这个项目的测试覆盖率让我意外：test/ 下 150+ 文件、4 万行，覆盖渲染器到 CSRF 到 i18n 几乎每个角落。给这种项目做贡献最大的安全感不是代码写得多漂亮，而是改完东西知道不会被静默打破什么。

PR: #1158

#1350 / #1355 — SSE 实时推送 Approval 和 Clarify 通知

起因

Agent 发起 approval（执行终端命令前等确认）或 clarify（向用户提问）时，前端靠轮询拿状态，延迟 5-10 秒。用户体验上就是点了个按钮，等半天才有反应。

架构选择

轮询 → SSE（Server-Sent Events）。没有选 WebSocket，因为这里只需要服务端推、客户端收，不需要双向通信。SSE 的好处是原生浏览器支持、自动重连、HTTP 协议兼容、不需要额外的连接管理。

设计

后端维护一个 per-session 的事件队列。客户端通过 /api/sse/subscribe 建立长连接，事件发生时 put 到队列，SSE 流推给前端。

几个要处理的点：

跨 session 隔离 — 每个 session 有自己的订阅，不能把 A session 的 approval 推给 B。用 session_id 做 key 管理订阅字典。

队列溢出 — 如果客户端断连但服务端还在推，队列会无限增长。加了 maxlen 限制，满了就丢弃最老的事件（反正客户端重连后会重新拉全量状态）。

并发订阅 — 同一个 session 理论上可能在多个浏览器标签页打开。允许多个订阅同时存在，事件广播到所有订阅者。

生命周期管理 — 客户端断连时自动 unsubscribe（SSE 的 EventSource 关闭触发后端清理）。

测试

写了 subscribe/unsubscribe 生命周期、跨 session 隔离、队列溢出、并发订阅几组测试。reviewer 专门提了测试质量。

#1350（Approval）先做，#1355（Clarify）是把同样的模式移植到 clarify 流程——同样的事件队列机制，不同的事件类型和前端 UI 渲染。

PR: #1350 / #1355

#1884 — 侧边栏折叠：点击当前 rail 按钮切换

起因

WebUI 侧边栏可以折叠成一条窄 rail（只显示图标），但折叠后想展开只能点汉堡菜单。移动端或窄屏上汉堡菜单不一定可见，rail 上又没有明确的展开入口。

做法

点击 rail 上已经激活（高亮）的按钮，触发侧边栏展开/折叠。逻辑很简单——判断点击的按钮是否是当前激活项，是就 toggle。

有趣的部分：合并 PR

另一个贡献者 @spektro33 同时提了 #1924 做同样的事，方案几乎一样。维护者把我们两个的 PR 合成一个 #2054，给了双作者署名（Co-authored-by）。

第一次遇到开源项目里这种合并方式。维护者的原话：“Fusing this into a stealth-mode PR — they were both proposing the same UX from different angles.”

PR: #1884

#2186 — 并发 send() 竞态：消息丢失和流吞没

起因

WebUI 用 S.busy 布尔值防止用户在 agent 回复过程中重复发送消息。但 setBusy(true) 在 send() 内部第一个 await 之后才执行——也就是说，两次快速 send() 调用之间有个时间窗口，第二次能通过 busy 检查，两条流并发跑。

结果：第二条消息的流覆盖第一条的输出，或者前端渲染混乱。

做法

把 setBusy(true) 移到 send() 函数的最顶部，在任何 await 之前。改动只有几行，但需要确认所有错误路径（catch / finally）都正确重置了 busy 状态。

PR: #2186

#2236 — 静默失败检测扫了全量消息

起因

当 provider 返回错误（401、429、rate-limit），agent 没有生成新回复，WebUI 需要检测这个”静默失败”并给用户显示错误。

问题在于检测逻辑在 _assistant_added 里扫的是 session 的 全部历史消息，而不是刚跑完的这轮新增消息。长 session 下这不是性能问题——是因为全量扫描碰到了旧消息里的错误标记，误判为新失败，弹出不该出现的错误提示。

做法

改成只扫描本轮新增的消息。需要在调用点传入消息范围（result["messages"] 里新消息的起始 index），检测函数只看这个窗口。

代码 217 行 additions，主要因为补了对应的测试覆盖。

PR: #2236

#2187 — Steer 消息在聊天界面显示

起因

WebUI 有个 busy_input_mode=steer 功能——agent 忙的时候，用户输入的消息不会排队等 agent 处理，而是直接注入 agent 的 context（“steer”它的方向）。

问题是注入后消息就消失了，用户看到输入框闪了一下，不知道消息去哪了。

做法

Steer 注入的消息现在在聊天界面显示——半透明的斜体气泡，带一个 Steer 标记。用户能看到消息被投递了，也知道它走的是 steer 通道。

PR: #2187

#2185 — Session 切换触发压缩状态 404

起因

切 session 时前端调用 GET /api/session/compress/status 检查有没有正在跑的压缩任务。没任务时后端返回 None（从 j() 函数），Flask 把 None 当成 404 处理。控制台一堆红字，虽然不影响功能但碍眼。

做法

空状态返回 {"active": false} 而不是 None。3 个文件改了 144 行（含测试），1 行删除。

PR: #2185

全部 PR 一览

几点感受

自用驱动。 每个 PR 都从自己的使用痛点出发——session 切换慢、通知延迟、UI 不顺手。这种贡献比”为了贡献而贡献”自然，也更容易写好 PR 描述，因为你就是用户。

Reviewer 的严格对双方都好。 不是”能跑就行”，而是要求覆盖边界路径、状态重置、并发安全。#1158 的 _messagesTruncated 被 hold 了两天直到补全 cancellation 路径。代码质量在这种反馈循环里实打实地涨。

Batch release 模式。 维护者不直接 merge，而是把多个 PR 打包成 batch release，统一跑 CI 后发布。PR 状态显示 “CLOSED” 而不是 “MERGED”，但代码确实进了主分支。

腾讯从”高回购+稳增长”的防御标的，变成”缩减回购+加码AI”的成长叙事。Forward PE 13.8x，扣投资组合后主营PE仅10.6x。市场给出了悲观定价，问题是：这是机会还是陷阱？

一、核心财务数据

营收低于预期（共识~1994亿，差近30亿），利润超预期（IFRS净利581亿 vs 预期578亿）。增速从Q4的13%放缓到9%，AI投入砍掉一半利润增速。

二、业务拆解

2.1 增值服务 961亿（占比49%，同比+4%）

关键细节：

• 《王者荣耀》《和平精英》《三角洲行动》三款季度流水均创新高
• 《三角洲行动》2月DAU突破5000万，成核心增量
• 《洛克王国世界》3月上线，9天注册破3000万，首月流水约10亿
• 《皇室战争》DAU和流水创历史新高
• 游戏收入递延意味着Q2有释放空间

2.2 营销服务 382亿（占比19%，同比+20%）⭐

本季最大亮点。增速较Q4的17%进一步提速。

驱动因素：

• 视频号用户时长同比+20%+，广告负载仍低于同行
• AIM+智能投放已覆盖广告主约30%投放金额
• 微信搜一搜AI增强后查询量快速增长
• 京东、美团等头部商家小程序广告投放需求增长

2.3 金融科技及企业服务 599亿（占比31%，同比+9%）

腾讯云Q1两轮涨价：

• 3月：混元模型API提价5.6倍
• 4月：AI算力、容器服务涨价5%

三、多方法估值分析

3.1 PE 估值

腾讯 PE 历史区间约10-45x，当前处于偏低位置（约30-35%分位）。

3.2 投资组合扣除法（核心）

总市值：39,261 亿 RMB（463 HKD × 91.18亿股）

投资组合（2025年末，打折后）：
  上市投资公允价值：6,727 亿 × 0.8 = 5,382 亿
  非上市投资账面价值：3,631 亿 × 0.6 = 2,179 亿
  投资组合合计（打折后）：7,560 亿

净现金：1,469 亿

主营市值 = 39,261 - 7,560 - 1,469 = 30,232 亿
2026E Non-IFRS净利润 = 2,850 亿
主营PE = 30,232 / 2,850 = 10.6x

10.6x 主营PE，对一个年增10%+、FCF充裕的平台公司，偏低。

3.3 SOTP 分部估值

3.4 DCF 折现

假设：Base FCF 1,800亿，5年增速10%，之后进入永续。

中性情景（WACC 10%，永续3%）：436 HKD 乐观情景（WACC 8%，永续3%）：609 HKD

3.5 FCF Yield

TTM FCF：1,922 亿
市值：39,261 亿
FCF Yield = 4.9%

接近5%的吸引力门槛。中国10年国债利率~1.8%，FCF Yield 超出国债+3%。

3.6 PEG

Forward PE = 13.8x
3年预期EPS增速 ≈ 12%
PEG = 13.8 / 12 = 1.15

PEG略高于1，在合理区间上沿，不算便宜但也不贵。

估值汇总

当前 463 HKD → 处于中性区间偏下沿。

四、护城河与竞争

护城河层级

🧱 第一层（最深）：微信社交网络效应

• 14.02亿月活，用户迁移成本极高
• 社交关系链不可复制
• C2C网络效应 > C2Creator > C2B

🧱 第二层（深）：游戏IP+运营能力

• PVP游戏自带网络效应
• 长青游戏组合（王者/和平精英/三角洲行动）形成飞轮
• 全球最大游戏公司，海外收入首破100亿美元

🧱 第三层（中等）：支付+金融牌照

• 支付双寡头之一（微信支付+支付宝）
• 低费率+高渗透，护城河来自监管+规模

🧱 第四层（较浅）：AI+云

• 混元3.0处于追赶阶段，非领先
• 但微信生态是AI Agent的天然载体

竞争对手对比

腾讯在港股互联网中估值中等偏低，增速优于阿里，但低于Meta。

五、风险与催化剂

风险

催化剂

六、击球区判断

当前是否在击球区？

结论：刚进入击球区下沿，值得关注但不必急。

理由：

• 463 HKD 处于综合估值中性区间偏下（460-490下沿）
• 悲观估值支撑约390-400 HKD，下行空间约15%
• 乐观估值580-620 HKD，上行空间约25-35%
• 风险回报比约 1:2，可以开始关注

不急于重仓的原因

1. Q1营收低于预期，增速放缓趋势未止
2. AI投入对利润的侵蚀刚开始，下半年可能更大
3. 回购缩水后缺乏股价支撑，短期可能继续承压
4. 市场情绪从”AI受益”转向”AI烧钱”，估值可能继续压缩

分批建仓参考

止损参考

• 如果主营PE跌破7x（约330 HKD），意味着基本面出现重大恶化
• 如果AI投入持续扩大但6个季度内看不到收入贡献，需重新评估

等待的触发条件

1. Q2财报（2026年8月）：游戏递延收入释放+广告能否持续加速
2. 混元3.0商业化数据：API调用量、付费用户数、对企业服务的收入贡献
3. 回购指引：管理层是否给出明确的2026年回购+分红方案
4. 微信AI Agent：从概念到实际可用的产品，这是最大的潜在催化剂

数据截止：2026年5月13日。本文为个人分析，不构成投资建议。

一个自然的问题是：AI 怎么学会操作电脑的？ 训练数据从哪来？模型怎么学会”看到这个按钮该点”的？

答案比你想的有趣。

学术数据集：够做 demo，不够做产品

在 Anthropic 和 OpenAI 动手之前，学术圈已经攒了不少 UI 操作数据集——GUI-360、OSWorld、WebArena 这些。格式没问题：一张截图配一个操作目标。

但拿来训练产品级 Agent，有三个硬伤：

应用覆盖太窄。 学术数据集覆盖几十种软件，真实世界有上千种。每多一类界面，模型要学的布局规律就多一个维度。长尾填不上。

场景太干净。 打开菜单、填表单、保存文件——这些简单操作占了大头。真实工作中的弹窗打断、加载延迟、表单校验报错，在数据集里很少出现。

轨迹太短。 真实操作是一串连续动作：“打开软件 → 点这个 → 填那个 → 等加载 → 关弹窗 → 继续填”。学术数据以单步或短轨迹为主，缺少多步之间的依赖关系。

三件事叠在一起：学术数据集能训出一个跑 benchmark 的 prototype，训不出一个在各种软件上都能用的产品。

Anthropic 的做法：把操作变成推理数据

2025 年 10 月，一项 Anthropic 的专利（U.S. 12,437,238）获批。它保护的不是”AI 怎么操作电脑”——那叫推理，每家都在做。它保护的是训练数据的采集和生成管线。

这条管线的核心思路：不只是记录”做了什么”，还要记录”为什么这么做”。

学术数据集的样本是”看到这个界面 → 做这个动作”，一组静态映射。Anthropic 的管线产出的样本是”看到这个界面 → 理解当前状态 → 判断下一步该做什么 → 做这个动作”，一条推理链。

具体怎么做？三个环节。

第一步：截获

在用户和软件之间放一个透明中间层。用户正常操作——点按钮、填表、滚动页面——中间层记录每一步操作前后的界面状态（截图 + 可访问性元数据 + 文本内容）。

最有意思的部分写在专利 Claim 5 里：用户可以附加”思考标注”——“我点这个按钮是因为它通常在右下角”、“应该选第三个选项，因为前两个是灰色的”。这些标注是人类在当前界面做决策的推理过程，直接编码进训练数据。

对模型来说，训练信号不再是”模仿这个点击”，而是”理解为什么要点这里”。

第二步：翻译

原始操作——“(342, 157) 点击”——送进一个多模态 transformer 模型。模型结合界面截图和上下文，推断用户意图，输出语义化命令：“识别到文本为’提交’的按钮元素，在 (330, 150, 400, 170) 区域内，执行点击”。

关键不是坐标转换，是让模型推理出操作背后的意图——用户不是随机点了一个像素，用户是想提交表单。

第三步：合成扩展

一条真实轨迹经过截获和翻译，变成一份带推理链的训练样本。然后 Anthropic 用一个更强的模型对这份样本做扩展——给同一张操作前截图，让强模型生成多种合理的操作变体。一条真实轨迹扩展出几十条训练样本，每条都包含完整的”看界面 → 推理 → 做动作”链路。

三个环节做的事是同一件：把原始操作转换为推理数据。 第一步从人类那里获取推理标注，第二步用模型补齐意图推断，第三步用更强的模型生成更多推理变体。

OpenAI 的做法：让 Agent 自己学

OpenAI 的 Operator 背后是一个叫 CUA（Computer-Using Agent）的模型。它基于 GPT-4o，但训练方法和 Anthropic 完全不同——走的是强化学习（RL） 路线。

核心区别：Anthropic 靠人类操作数据+模型翻译来制造训练样本，OpenAI 让 Agent 在虚拟环境里自己探索学习。

具体怎么做的：

搭建 Web Gym

不让没训练过的 Agent 在真实网站上乱点——那会点出事。OpenAI 搭建了模拟真实网站的沙箱环境（Web Gym），Agent 在里面随便试，不会搞坏任何东西。

好的 Gym 要满足五个条件：足够真实（DOM 和真实网站接近）、可以探索（按钮真的能点）、数据多样（不能让 Agent 过拟合）、验证器准确（自动判断任务有没有完成）、基础设施稳定（训练环境不能老崩）。

设计好任务

任务设计直接影响学习效果。“买个衬衫”太模糊，Agent 学不到东西。“买最便宜的蓝色 M 码棉衬衫”才是好任务——它迫使 Agent 学会搜索、筛选、比价、验证属性，每一步都有明确的对错标准。

RL 训练

Agent 反复在 Gym 里尝试任务。成功了拿奖励，失败了扣分。关键难点是保持模型的推理能力——RL 训练容易让模型变得”短视”，只会追求即时奖励，丧失长程规划能力。OpenAI 专门做了处理来防止这个问题。

CUA 的运行方式是一个循环：截图（感知）→ 想一想当前状态和下一步（推理，Chain-of-Thought）→ 点击/输入（动作）。每一步都有内部独白，不是直接输出坐标。

两条路线，一个规律

把两家放在一起看：

Amazon AGI Lab 也发了类似的研究，结论基本一致：好的环境 + 好的任务设计 + 准确的验证器 + 保持推理能力，四层缺一不可。

独立 Browser Agent 的死局

2026 年 5 月 4 日，Google 无预告关掉了 Project Mariner——去年 I/O 大会的 AI Agent 旗舰产品。官方页面只留了一句话：“Technology voyaged to other Google products.”

有意思的是，Anthropic 和 OpenAI 也得出了同样的结论。OpenAI 的 Operator 关了，Instant Checkout 也关了。Anthropic 的 Computer Use 发布 18 个月仍然 beta，官方自己都说”从低风险任务开始”。三家做同类产品的公司，几乎同时放弃了独立 browser agent 路线。

不是技术不行，是结构性死局。

你在和反爬系统打仗

独立 browser agent 的部署方式（headless Chrome、云托管浏览器、独立 VM）会创建全新的浏览器会话——没有 cookie、没有浏览历史、没有人类行为特征。这正是网站反爬系统十几年来擅长探测的目标。

OpenAI 的 Operator 连 ChatGPT.com 都访问不了——自己公司的网站都把它当爬虫。Amazon 在 2026 年 3 月对 Perplexity Comet 拿到了法院禁令，法官依据《计算机欺诈和滥用法》判定：Comet 访问 Amazon 账户”有用户许可但没有 Amazon 授权”。

做独立 browser agent 的团队，工程资源不在提升模型能力上，而在和有几十年反爬经验、有直接经济激励的平台打军备竞赛。而且你的每一轮规避策略都会触发下一轮检测升级。

Browser Agent vs Computer Use

先厘清一个关键区分：

Browser Agent 瞄准的场景（订机票、比价、购物）对可靠性要求极高。用户容忍不了偶尔买错，而”买错”和自己操作的区别只是几分钟——认知上的收益太小。

真正的需求在 Computer Use 这边：医院 90 年代的病历系统、保险理赔软件、Bloomberg Terminal（API 访问要六位数美元的额外合同）。这些不会因为 AI 出现就自动装上 API，而且它们绝大多数不是网页应用。

需求没错，品类错了。

解法：共享用户的真实会话

三家公司最后都走向了同一个方向——不让 Agent 开新浏览器，而是直接操作用户已在用的浏览器或桌面。从网站角度看，分不出是用户在点还是 Agent 在点。

• Google：把 Mariner 技术做进了 Chrome（auto-browse），跑在用户真实浏览器里
• OpenAI：Codex Computer Use 走 macOS 桌面插件路线，直接跑在用户真实 Mac 上，共享桌面环境和浏览器登录态
• Anthropic：Claude for Chrome 跑在用户真实浏览器里，活得很好

到 Computer Use（控制用户整个桌面）的时候，优势更明显：用户桌面有真实人类操作轨迹——鼠标移动速度、打字节奏、标签切换模式。这些信号 bot 几乎不可能伪造。

Benchmark 现实

说完方向，说现实。当前的成绩离”可靠”还很远：

最好的 Agent 在全桌面任务上的成功率刚过人类的三分之一。这就是为什么三家公司都在换方向——不是训练方法的问题，是部署环境的问题。在 headless 浏览器里训得再好，反爬系统一拦就白搭。换到共享真实会话的部署方式，同样的模型能力立刻能发挥出来。

如果你想自己做

总结一下，如果是一个公司或团队想开发桌面操作 Agent：

选对部署方式比选对训练方法更重要。 不要做独立 headless browser agent，那是死路。做浏览器扩展、桌面插件、或者直接接用户桌面——共享真实会话。

最快的起步方式：做一个浏览器扩展或桌面插件，用大模型的 vision 能力做 zero-shot——截图扔给 GPT-4o 或 Claude，让它输出坐标和动作。不用专门训练，先跑通。

要提升成功率：收集失败案例，人工标注正确操作，训练专门的视觉定位模型。加入异常处理：弹窗、加载中、报错、页面滚动。引入 accessibility tree 作为截图的补充信号。

要规模化：建数据飞轮——用户使用产生轨迹 → 人工审核 → 训练模型 → 模型变强 → 吸引更多用户。或者走 RL 路线，搭虚拟环境让 Agent 自己学。

至于 Anthropic 的专利——它保护的是”截获层 + 思考标注 + 翻译 + 合成扩展”的特定管线组合。如果你走 RL 路线，或者用纯 API 调用（截图 → 大模型 → 坐标），根本不在专利覆盖范围内。

一个更深的观察

Computer Use 的竞争，表面上是模型能力的竞争，实际上是训练数据的生产效率 × 部署环境的选择的竞争。

谁家的 Agent 能覆盖更多软件、更稳定地完成任务，取决于两件事：训练数据的质量和规模，以及 Agent 跑在什么环境里。Anthropic 的专利卡的是数据生产，Google 关掉 Mariner 说明部署环境同样关键。最好的训练数据配上 headless 浏览器，打不过一般的训练数据配上用户真实会话。

方向是确定的：AI 操作电脑这件事，不是一个功能，是一个新的交互范式。 但范式落地的路径已经从”给 Agent 一个独立浏览器”转向了”让 Agent 操作用户已有的浏览器和桌面”。这个转向不是退步，是把工程资源从打反爬战争转移到真正提升模型能力上。

有个观察让我困扰了挺久：医生越老越值钱，程序员越老越尴尬。

医生看了一万个病例，临床直觉会长出来。那个直觉不可替代，也不可压缩——你没法把它写成文档让新手直接用。程序员呢？你写了十年 Java，Spring 那套东西确实熟了，但 AI 现在写得比你快。你花三年搞明白的分布式系统调优，Claude Code 五分钟给你一个比你好一点的方案。

不是夸张。我自己用 Claude Code 和 Hermes Agent 做开发，一个下午干完以前两三天的活。如果”写代码”是我的核心价值，那我确实在被替代的路上。

但这个类比本身就有问题。

医生的护城河不是你想的那样

医生真正不可替代的不是诊断能力——这块 AI 已经在碾压了。影像识别的准确率，AI 超过大部分放射科医生。IBM Watson 几年前就能根据症状列表给出比主治医师更全的鉴别诊断。

医生真正值钱的是三样东西：执照（制度性壁垒）、患者信任（关系壁垒）、出了事找他（责任壁垒）。前两个跟技能无关，是制度和社会契约在保护。程序员没有这些保护，所以焦虑来得更早更直接。

但反过来说，你也不需要这些保护。因为程序员的价值锚点本来就不在”写代码”上。只是大部分人——包括之前的我——把它搞混了。

代码成本坍塌之后，什么在涨价

我写过一篇长文聊”当人类智力不再稀缺”，从宏观角度拆了这个问题。这次换个角度，从个人出发。

一句话：执行层价值归零，判断层价值放大。 每次技术革命都是这个规律。计算器干掉了算术能力，会计师没消失，但他们的活从”算对”变成了”知道该算什么”。摄影干掉了写实绘画，画家没消失，但价值从”画得像”变成了”画什么”。

AI 干掉的是代码执行。那程序员应该积累什么？

品味

品味听着玄，拆开看就是：你见过足够多好的和差的，形成了”这个方向对了/错了”的直觉，并且能把直觉说出来。

我有一个买房评分体系，13 个维度，每个维度有权重。AI 可以帮我搜任何一个维度的数据，但”这 13 个维度各占多少分”是我定的。别人拿到同样的数据，可能觉得学校比交通重要，或者噪音根本不算事儿。没有标准答案，但做判断的是人。

还有一个”去 AI 味五条”写作规范，是我改了几十篇文章之后提炼出来的。每一条都是踩过坑才知道的——“动词 unnatural”这条，是我发现自己写完的东西读出来像翻译腔，才意识到问题在哪。

品味的本质是压缩了无数次试错的结果。你可以把最终结论告诉别人，但他没法从结论反推出压缩过程。这就是不可替代的部分。

问题定义

最近半年我一直在用 AI 做开发，发现一件事：花时间最多的不是”让 AI 写代码”，是”写清楚验收标准”。

举个例子，让 AI 做一个翻译功能。如果你只说”翻译这段文字”，你会得到一堆中英混杂、术语不一致的东西。但如果你写清楚：翻译后不能有中文字符、术语表必须前后一致、每个技术术语第一次出现要标注英文原文——那 AI 一次就能过。

这个过程让我意识到，“定义什么是对的”比”做出对的东西”难得多。前者需要你理解领域、理解约束、理解边界情况。AI 可以帮你执行任何标准，但标准本身得有人定。

上下文积累

我有一个 Obsidian wiki 系统，里面 20 多个页面，记录了技术判断、投资分析、思维公理。这些东西的价值不只是”存了资料”，而在于形成了只有我拥有的语义网络。每个页面之间的链接——比如公理 A03（IC→Manager）连到 T05（认知是资产）再连到具体的代码案例——这是我的思维路径。别人拿到同样的原始材料，建不出同样的结构。

Hermes Agent 的记忆系统也是这个思路。四层记忆分离，从即时上下文到长期知识库，每次交互都被蒸馏成可复用的认知。这个东西越用越值钱，因为上下文在叠加。

跨域连接

在程序员里我懂投资，在投资者里我懂技术，在技术人里我关心哲学——佛学无常、认知科学、决策框架。这种跨域视角是自然长出来的，不是刻意学的。

AI 能在每个领域给我信息，但它不会主动把”佛学的无常""投资的周期""技术的范式转移”连在一起讲。而这三件事其实是同一个模式：旧的稳态在崩塌，新的还没建立，过渡期最危险也最有机会。这种连接是人的活儿。

我在怎么做

不是理论，是过去半年实际在做的事。

把判断力外化。 每次做一个重要决策——技术选型、投资判断、产品方向——我把思路写成结构化文档。不是记录结论，是记录”我当时的判断依据是什么”。过一阵回头看，有些对了，有些错了。对了的沉淀成公理，错了的变成教训。这个过程本身就在练品味。

练习写验收标准。 每次用 AI 完成一个任务，先写验收标准再动手。一周之后回头看：哪些标准写得好（AI 一次过），哪些写得差（反复修改）。好和差之间的差距，就是品味在生长的地方。

建了一个 wiki 系统当第二大脑。 前面说的那个。三层信息流：收集层（原文不动）、结构层（消化后的笔记）、稳定层（从实践中提炼的核心认知，我管它叫”公理”，改动的频率是季度级的）。这个系统越用越顺，因为认知在叠加而不是每次从零开始。

继续跑步和力量训练。 跟 AI 没直接关系，但身体技能是不可自动化的。42 公里只能用自己的腿跑。说极端一点，能跑半马、能爬山的人，在未来可能比能写代码的人更稀缺。不是比喻，是字面意思——物理共在的服务在涨价。

身份这件事

说到底，焦虑的根源不是”程序员会不会失业”，是把”自我”绑在了”程序员”这个身份上。

我之前有一篇自我评估，结论是”觉醒的工程师”。工程师不是”写代码的人”，是”解决问题的人”。代码是当前时代的工具，就像铁锤是铁匠时代的工具。下一个时代的工具会变，但”定义问题、分解任务、验收结果、承担责任”这些能力不变。

佛学讲无常，不是说”一切都会变所以躺平”，是说”一切都会变所以别把锚钉在会变的东西上”。代码会变，框架会变，语言会变。判断力、品味、跨域理解——这些沉淀得慢，但不会过期。

我不确定的地方

品味能不能被 AI 学习？现在看起来不能——它需要真实的体验和反馈闭环。但如果 AI 开始模拟反馈闭环呢？

“AI 编排者”这个角色会不会也被 AI 化？如果”定义验收标准”可以自动化，那人的价值又在哪？也许在于定义”验收标准的标准”——但这听着像无限递归。

物理世界的不可替代性能维持多久？具身智能的进展速度比我预期的快。

这些问题没有答案。但把不确定说出来，比假装确定好。假装确定的人死得最快。

这篇是 compound-career-ai-era 的博客化版本，更完整的框架和学习方向见 wiki。

我有一个 Obsidian wiki 系统当第二大脑，63 个页面，覆盖 AI、投资、哲学、运动四个领域。页面之间有 wikilink 交叉引用，三层信息流（收集→结构→公理）。平时想查一个概念，得自己翻目录、点链接、拼上下文。

这就引出一个自然的需求：给 wiki 加一个问答入口。输入”佛学无常和投资周期有什么关系”，系统从 63 个页面里找到相关的段落，拼好上下文，生成回答。

这就是 RAG——Retrieval-Augmented Generation。技术本身不复杂，但 RAG 的基础 pipeline 正在被平台快速吸收。2023 年要自己搭的 chunk → embed → retrieve → generate 全链路，现在 OpenAI File Search 一个配置就搞定了。Anthropic 有 Contextual Retrieval，Google 有 Vertex AI RAG Engine，AWS 有 Bedrock Knowledge Bases。

真正值得花时间的是三件事：评估体系、Agentic Workflow、数据治理。 平台替代不了，也是 RAG 从”能用”到”好用”的关键。

三个阶段

第一阶段：基础 RAG 系统设计

目标不是搭 demo，是建立”组件之间怎么配合”的直觉。

要搞明白的东西：

• 文档处理：PDF/HTML/Markdown 的解析策略，表格和图片怎么处理
• Chunking 策略：按长度切、按语义切、按结构切，各适合什么场景。没有万能方案，但要知道 trade-off
• Embedding 模型选择：OpenAI text-embedding-3-large vs 开源（BGE、E5、GTE），中文场景的选型差异
• 检索方式：Dense retrieval（向量搜索）+ Sparse retrieval（BM25），Hybrid Search 为什么比单一方式好
• Reranking：检索后的重排序，Cohere Rerank 或 cross-encoder 模型

产出标准： 独立完成一个支撑 1000+ 文档的问答系统，跑通”用户提问 → 检索 → 生成 → 返回答案”全链路，能用真实数据验证检索质量。

时间参考： 2-3 周（每天 2-3 小时）。

第二阶段：评估与可观测性

RAG demo 和生产系统最大差距在于：你能不能区分出了什么问题。

demo 时检索不好手动调两下就行，生产环境出了问题你得知道是检索的锅还是生成的锅。评估能力通用性很高——学会了，换到推荐系统、搜索系统都能用。

要搞明白的东西：

• 测试集构建：怎么造出覆盖面够广的（问题，相关文档，正确答案）三元组。不能只测 happy path
• 分层指标：
  • Retrieval 层：Precision@K、Recall@K、MRR、nDCG
  • Generation 层：Faithfulness（生成内容是否忠于检索结果）、Answer Relevancy（回答是否切题）、Citation Coverage（引用覆盖度）
• 工具链：Ragas、TruLens、DeepEval 这类评估框架怎么用
• 线上监控：用户反馈闭环、回归测试、检索质量漂移检测

产出标准： 给第一阶段搭的系统加上评估层，能自动化跑评测、输出指标报告、定位问题出在哪一环。

时间参考： 2 周。

第三阶段：纵深方向

基础打好了，根据你的项目选一个方向深挖。

方向 A：Agentic Workflow / Context Engineering

从”写一段固定的检索代码”变成”设计一个能自己做检索决策的 Agent”。

• 检索变成 Agent 的工具调用：搜几轮、换关键词、追线索、判断什么时候该停止
• Multi-step retrieval：先检索概览，再根据概览细化查询
• Tool use + RAG：Agent 自己决定用哪个知识库、要不要搜索、要不要调 API
• 长上下文信息密度管理：context window 在变大，但塞太多不相关信息会稀释答案质量

以我的 wiki 问答系统为例：用户问”无常和投资周期有什么关系”，Agent 要决定——先查哲学分区的无常概念，再查投资分区的周期理论，然后查有没有现成的跨域对比页面。每一步都可能需要换关键词、扩大检索范围、或者判断”够了，可以生成回答了”。

方向 B：数据治理与权限控制

企业场景下这个能力直接决定系统敢不敢上线。

• RBAC/ABAC 访问控制模型
• 向量检索层的 metadata 预过滤
• 多租户场景下的数据隔离
• 审计日志和合规追溯

适合 ToB 业务或有合规要求的场景。

方向 C：评估体系专家

第二阶段继续深化，成为”AI 系统质量”方向的专家。不只 RAG 评估，而是所有 LLM 应用的评测方法论。通用性最强，迁移成本最低。

实战项目：Wiki 问答系统

拿自己的 Obsidian wiki 做实战项目。63 个页面，四个领域（AI、投资、哲学、运动），有 wikilink 交叉引用，有分层结构。数据量适中，内容熟悉，能快速判断检索质量好坏。

阶段一 → Wiki RAG Pipeline
├── 数据源：63 个 wiki Markdown 页面
├── Chunking：按 section 切（每个 ## 块为一个 chunk）
├── Embedding：BGE-M3（中英混合内容）
├── 检索：Hybrid Search（向量 + BM25）
├── Rerank：cross-encoder
└── 生成：基于检索片段 + 页面 wikilink 上下文生成回答

阶段二 → 加评估层
├── 测试集：手写 30 个跨领域问题 + 预期相关页面
├── 指标：检索命中率 + 回答 faithfulness + wikilink 覆盖率
└── 监控：回答质量主观评分（1-5）

阶段三 → Agentic 升级
├── 简单事实查询 → 单次检索直接回答
├── 跨领域问题 → Agent 多步检索，先查一个领域再追线索到另一个
├── 概念对比 → Agent 主动查找 comparison 类页面
└── 反馈闭环 → 用户修正的答案回流为新的知识条目

这个项目的好处：做完之后 wiki 真的能用了，输入问题就能检索知识，比手动翻目录快得多。学以致用。

学习资源

按优先级排：

基础概念：

• LangChain RAG 从零到一（官方 tutorial，概念清晰）
• LlamaIndex 官方文档（比 LangChain 更聚焦 RAG 场景）
• Pinecone 的 Learning Center（向量数据库基础 + RAG 模式）

评估体系：

• Ragas 文档（最成熟的 RAG 评估框架）
• TruLens（RAG 三元组评估：context relevance, groundedness, answer relevance）

Agentic RAG：

• LangGraph 的 Agentic RAG 示例
• Contextual Retrieval（Anthropic 的方案，contextual chunk 提升检索质量）

中文 RAG 实战：

• BGE 系列模型（BAAI 出的中文 embedding，开源好用）
• Chroma / Milvus 向量数据库选型

几个坑提前知道

1. Chunk size 不是调参游戏。 50 tokens 和 500 tokens 的差距是文档结构决定的。结构化文档按结构切，自由文本按语义切，别迷信固定窗口。
2. Embedding 模型的选择对中文场景影响巨大。 用英文模型跑中文，检索质量直接拉胯。BGE-M3 或 GTE-Qwen2 是目前中文场景比较好的选择。
3. 评估应该在搭系统之前做。 先定义”好的回答长什么样”，再搭系统。不然搭完了没法判断改好了还是改差了。
4. 平台化是趋势但覆盖不了所有场景。 OpenAI File Search 能搞定 80% 的情况，多租户权限、复杂 Agent 编排、评估体系这些，还得自己来。

我的策略

用 4-6 周把三个阶段跑完，基础不恋战，重点放在评估和 Agent 方向。Wiki 问答系统是最好的实战场地——做完直接能用到自己的知识管理流程里。

RAG 不会长期作为一个独立技术存在，它会变成 AI 工程的基础能力。但”懂 RAG”的含义在快速变化：两年前是”会搭 pipeline”，现在是”懂评估、能做 Agent 编排、理解数据治理”。再往后，可能所有 RAG 都是 Agentic 的，那时候比的就不是”会不会 RAG”，而是”能不能设计出让 Agent 在正确时机获取正确信息的系统”。

腾讯从52周高点683港元跌到470，回撤31%。这篇文章不是要告诉你”买入”或”卖出”，而是把几种估值方法算清楚，你自己判断。

一、核心财务数据（2025全年）

分部收入

几个值得注意的点：

• 游戏出海加速。国际市场游戏首次年入超100亿美元，增速33%远超本土18%。这不是偶然，Supercell、Riot持续产出，叠加新兴市场渗透。
• 广告是增速最稳的板块之一，19%的增速主要来自视频号。视频号广告加载率还很低，天花板还在上面。
• 金融科技增速放缓到8%，但腾讯云在这个板块里实现了规模化盈利，AI相关云服务需求上升是增量。

股东回报

2025年回购约800亿港元（1.534亿股注销），末期股息5.30港元/股（+18%）。2024-2025两年累计回购1,920亿港元，注销约4.6亿股。管理层表态2026年回购可能低于800亿，因为AI投入需要资本，同时提高现金分红。

二、投资组合（关键项）

腾讯的估值绕不过投资组合。

一个有意思的变化：联营公司账面值（3,424亿）和公允价值（3,493亿）差距只有69亿（不到2%）。2021年峰值时这个差距非常大，因为京东等持仓的市值远超账面值。后来通过实物分派京东（~130亿美元）和美团（~200亿美元），加上市场估值收缩，差距基本消失了。

三、多方法估值分析

当前股价470港元，总股本91.2亿股。港元兑人民币约0.93。

总市值 = 470 × 91.2亿 ÷ 0.93 ≈ 46,097亿港元 ≈ 42,870亿人民币

3.1 PE估值

IFRS PE = 42,870 ÷ 2,248 = 19.1x

Non-IFRS PE = 42,870 ÷ 2,596 = 16.5x

Forward PE（2026E Non-IFRS净利 2,850亿，增速10%）= 42,870 ÷ 2,850 = 15.0x

历史分位：Non-IFRS PE 16.5x处于10年约17%分位。5年平均PE约21x，当前折价约21%。

3.2 PB估值

PB = 42,870 ÷ 净资产（约12,800亿）= 3.3x

10年中位数PB约6.0x，当前低于中位数44%。但腾讯是轻资产公司，PB意义有限，主要看PE和现金流。

3.3 SOTP分部估值

中性SOTP估值约505港元，当前470有约7%的安全边际。

3.4 投资组合扣除法

这个方法最能反映腾讯”主营业务”的真实估值。

总市值：约 42,870 亿人民币
上市投资（打折后）：6,727 × 0.8 = 5,382 亿
非上市投资（打折后）：3,631 × 0.6 = 2,179 亿
投资组合合计（打折后）：7,561 亿
净现金：1,071 亿
主营市值 = 42,870 - 7,561 - 1,071 = 34,238 亿
主营 PE = 34,238 ÷ 2,596 = 13.2x

主营PE 13.2倍。一个年增速17%、自由现金流1,826亿的公司，主营PE只有13倍。这个数字比表面看到的16.5倍便宜很多。

3.5 DCF自由现金流折现

Base Year FCF: 1,826 亿（2025年）
总股本: 91.2 亿股
净负债: -1,071 亿（现金净额为正）

假设：

• 未来5年FCF增速：10%（保守，考虑AI投入期CapEx上升）
• 永续增长率：3%
• WACC：10%

WACC 10%偏保守。敏感性分析：

中性场景（WACC 9%、永续3%）对应 484港元。当前470略低于这个值。

3.6 FCF Yield

FCF Yield = 1,826 ÷ 42,870 = 4.3%

中国10年期国债收益率约1.7%。FCF Yield高出2.6个百分点。一般FCF Yield > 国债+3%（即4.7%）算有吸引力，4.3%接近但未到。

如果用投资组合扣除后的主营市值算：

主营 FCF Yield = 1,826 ÷ 34,238 = 5.3%

5.3%超过国债+3%的门槛，有吸引力。

3.7 PEG

Forward PE ≈ 15.0x
预期3年增速 ≈ 10-12%
PEG = 15 / 11 ≈ 1.36

PEG略高于1，不便宜但不算贵。腾讯不是高速成长股了，PEG参考意义下降。

3.8 估值汇总

当前470港元大致在中性偏下的位置。

四、护城河

腾讯的护城河不是一个点，是一套系统：

🧱 微信超级入口。13亿+月活，用户每天打开的次数最多的App。几乎所有新业态（支付、视频号、小程序）都可以在微信里长出来，收一道”过路费”。

🎮 游戏IP+发行能力。王者荣耀、和平精英是现金牛，Supercell和Riot提供海外管线。游戏的生命周期远超市场预期，头部游戏可以活5-10年。

📱 社交网络效应。用户在微信/QQ上的关系链是最大壁垒，迁移成本极高。

📊 数据+AI飞轮。广告精准投放、游戏内容生产、云服务，AI正在每个业务板块里提效。

💰 资本配置能力。两年1,920亿港元回购+实物分派京东美团，管理层用行动证明愿意把现金还给股东。

同行对比

腾讯Non-IFRS PE在同行里几乎最低，但增速并不差。对标Meta和谷歌，腾讯有明显的估值折价。

五、风险与催化剂

风险

催化剂

六、击球区判断

综合评估

结论

470港元在击球区边缘，偏下沿。

中性估值区间约490港元，当前价格有约4%的安全边际。如果市场继续恐慌（比如AI投入超预期拖利润、宏观进一步走弱），可能跌到400-420区间，那是更确定的击球区。

但话说回来，“等更低”是价值投资者最常见的心理陷阱。一家Non-IFRS PE 16.5倍（主营13.2倍）、年增速17%、FCF 1,826亿的公司，在470买入长期不会亏大钱。

参考建仓方案

注意：5月13日Q1财报是一个关键节点。如果数据超预期，第一笔可能就是最低点；如果不及预期，可能很快到第二笔的位置。

数据来源：腾讯2025年年报、雪球、GuruFocus、Investing.com、财联社、证券时报。数据截止2026年5月7日。

两个 Agent 都用纯文本文件做记忆，都不依赖向量数据库。但冻结注入 vs 实时注入、硬上限 vs 无上限、fork 子 Agent review vs 手动 skill，每个差异背后都是不同的工程取舍。

一、记忆系统的核心矛盾

所有 LLM 都是无状态的。每次 API 调用，模型从空白开始，看到的只有你塞进去的 token。所谓的”记忆”——用户偏好、上下文、跨 session 知识——全靠 Agent 框架自己在调用之间拼装。

这就引出了三个要回答的问题：

1. 存什么？ 哪些东西值得记住，哪些该忘掉
2. 怎么存？ 文件、数据库、向量，还是混合
3. 怎么喂？ 什么时候注入 context、什么时候检索、什么时候压缩

Hermes Agent 和 OpenClaw 对这三个问题的答案完全不同。

二、概览

三、核心差异逐层拆解

3.1 冻结注入 vs 实时注入

这是两个框架最本质的差异。

Hermes 的冻结注入：

Session 开始:
  → 读 MEMORY.md + USER.md 全文
  → 制作"快照"注入 system prompt
  → 首次 API 调用 → 建立 KV Cache（Prefix Cache）

对话进行中（system prompt 不变）:
  → 每次 API 调用命中 KV Cache ⚡

mid-session 写入:
  → 文件已更新
  → 但 system prompt 里的快照不变

下个 Session:
  → 重新读取（含新内容）
  → 制作新快照，重建 KV Cache

设计逻辑：性能优先，延迟生效。system prompt 不变才能保住 prefix cache，省下 80%+ 的输入 token 重计算成本。

OpenClaw 的实时注入：

每轮对话:
  → 重读 MEMORY.md
  → 重注入 context

写入时:
  → 文件更新
  → 下一轮直接生效

设计逻辑：即时感知优先。写入即生效，但代价是每轮 system prompt 变化 → Prefix Cache 完全失效。

实际影响：

对于一个 24/7 运行的 Agent，每天几十到几百次 API 调用，每轮破 cache 的额外累积成本很大。Anthropic 的 Prefix Cache 定价是缓存命中输入 token 打 90% 折扣——这意味着 OpenClaw 每轮都在付全额。

但这个取舍不是单方面的好或坏。对于 Cursor 这种交互式 IDE 插件，用户期望写完就生效，延迟一轮会感觉很蠢。对于后台运行的 agent，延迟一轮可以接受，省钱更重要。

3.2 记忆容量管理

Hermes 的硬上限：

为什么要设上限？

正常情况下，2000 tokens 的记忆内容中，每条约占 0.26% 的注意力权重。膨胀到 5000 tokens 后，每条只剩 0.02%。上限就是一道硬约束，迫使 Agent 只保留最有价值的信息。超过上限时触发压缩，优先保留用户偏好和环境事实。

上限不是随便定的。2200 字符刚好能装 15-20 条记忆条目，每条约 100-150 字——够一个 session 用。1375 字符也是一个精炼的用户快照，快速加载。

OpenClaw 的无上限：

没有硬性容量限制。Agent 自己决定写什么、删什么。

理论上更灵活——你可以记住更多东西。但实践中暴露的问题：记忆膨胀到几千甚至上万字符后，注意力稀释严重。LLM 的压缩行为不可预测，你不知道它在写了很多行后，会去掉哪些。

Nishant Soni 那篇《I’ve Seen a Thousand OpenClaw Deploys》的 HN 文章里提到：OpenClaw 的 MEMORY.md 在 context 溢出时可能被压缩，而且 LLM 做压缩时可能会删除你认为重要的信息。你都不知道它丢了什么。

3.3 MemoryProvider 插件架构

Hermes 的插件体系：

MemoryProvider（ABC）
├── initialize()        → 连接、创建资源
├── system_prompt_block() → 注入 system prompt 的静态文本
├── prefetch()          → 每轮对话前的 recall
├── sync_turn()         → 每轮对话后的写入
├── get_tool_schemas()  → 工具 schema
├── handle_tool_call()  → 工具调用分发
├── shutdown()          → 清理退出
└── 可选 hooks:
    ├── on_turn_start()
    ├── on_session_end()
    ├── on_pre_compress()
    ├── on_memory_write()
    └── on_delegation()

内置 BuiltinMemoryProvider 始终激活（MEMORY.md + USER.md）。可以挂载一个外部 provider——Honcho、Hindsight、Mem0、Holographic、Supermemory、RetainDB、OpenViking 均有官方插件。外部 provider 是增量的，不会取代内置的。

只允许一个外部 provider 的原因：避免 tool schema 膨胀和记忆后端冲突。

OpenClaw： 无官方插件机制。社区有人用 Mem0 等外部工具补强，但需要自己写胶水代码。

3.4 Skill 自动收集

Hermes 的闭环系统：

复杂任务完成（工具调用 ≥ 10 次）
  → 返回最终回答给用户
  → 后台 fork 子 Agent
  → 子 Agent 冷启动 Review：
      1. 有试错过程？
      2. 有思路转变？
      3. 用户有特别偏好？
      4. 下次还用得上？
  → 任一回答"是"且无现成 skill → skill_manage(action='create')
  → 有类似 skill 需补充 → skill_manage(action='patch')
  → 不值得 → 跳过
  → 通知用户

为什么 fork 子 Agent 而不是主 Agent 直接处理？

SKILL.md 文件结构：

~/.hermes/skills/
├── my-skill/
│   ├── SKILL.md          ← 核心文件（触发条件+步骤+避坑）
│   ├── references/       ← 参考资料
│   ├── templates/        ← 模板文件
│   └── scripts/          ← 辅助脚本
└── category-name/
    └── another-skill/
        └── SKILL.md

安全机制：命名校验（小写+连字符+最长64字符）、大小限制（SKILL.md 最大 100KB）、安全扫描（注入/外泄）、回滚机制、只读保护。

OpenClaw： 有 skill 目录（~/.openclaw/skills/），但无自动发现机制。需要用户或 Agent 手动创建。没有 review 阶段，不会在任务完成后自动提炼可复用知识。

3.5 记忆 vs Skill：数据模型差异

两个系统在 Hermes 里的定位：记忆是”事实”（用户喜欢 pnpm），skill 是”过程”（用 pnpm 搭建 monorepo 的步骤）。两者共享同一个 nudge 机制触发，但写入路径和处理逻辑完全分开。

3.6 对话历史检索

Hermes： session_search 工具使用 SQLite FTS5 全文检索。Agent 可以主动搜索过去所有 session——“我们之前讨论过什么什么”——生成摘要后注入当前上下文。用的时候能回忆起来，不用的时候不占空间。

压缩后的子 session 通过 parent_session_id 链回原 session，跨 session 也能追溯到完整对话链。

OpenClaw： 无内置跨 session 搜索。依赖 MEMORY.md 中的摘要记录。如果 Agent 当时没记，后面就找不到了。

四、关键设计决策总结

五、适用场景

Hermes 更合适的场景：

• 24/7 后台运行，对成本敏感
• 需要可靠的跨 session 记忆
• 工作流固定，需要技能复利累积
• 用户习惯先思考再做，不要求即时感知

OpenClaw 更合适的场景：

• 交互式 IDE 使用，写完就想生效
• 需要精细的人格分层（多人格切换）
• 对实现简单性要求高，不关心插件扩展
• 单 session 为主，跨 session 需求少

两个框架在记忆逻辑上的差异，说到底就是一句话：你是愿意多付一点钱换来即时生效，还是愿意等一轮换来稳定省心。 没有对错，取决于你的使用模式。

参考资料

• Hermes Agent 官方架构文档
• Inside Hermes Agent: How a Self-Improving AI Agent Actually Works
• OpenClaw’s memory is unreliable, and you don’t know when it will break
• OpenClaw GitHub

2026-04-08 | 布伦特约95-110美元/桶 | 港股0883 收盘26.10 HKD | A股600938 约37.57 CNY

一、当前宏观局势：美伊冲突与石油供应

1.1 事件背景

2026年2月28日，美国与以色列联合对伊朗发动军事打击，轰炸伊朗军事设施并实施斩首行动。伊朗随后封锁霍尔木兹海峡作为反击。截至4月8日，冲突已持续约40天。

关键事实：

• 霍尔木兹海峡每天通过约2,000万桶石油，占全球原油贸易量的48%，全球日消费量的20%
• 伊朗控制海峡通航，对通过船只收取过境费（每艘最高200万美元），并选择性放行——中国、越南、马来西亚、菲律宾的船只优先，美欧关联船只被拦截
• 3月波斯湾船只通行量暴跌至2月的5%，约400艘大型油气轮滞留在海湾内
• 4月初通行量小幅回升（4月1日16艘），但仍远低于正常的135艘/天
• 冲突已外溢：伊朗轰炸沙特、阿联酋、卡塔尔能源设施，以色列突袭伊朗南帕尔斯气田
• 这四国（伊朗+沙特+阿联酋+卡塔尔）2025年日均产量约1,950万桶

1.2 油价走势

现货市场更极端：部分实物原油现货价超过140美元/桶。

1.3 对中国海油的影响分析

直接影响：

• 中国海油是中国近海油气生产商，资产不在中东，不受直接军事打击
• 霍尔木兹海峡封锁不影响海油的生产端——它的油田在渤海、南海、东海
• 中国作为伊朗优先放行国家，进口原油受影响相对较小
• 但国际油价上涨直接推高海油实现油价，利好营收和利润

间接影响：

• 如果全球因高油价陷入衰退，石油需求下降，中长期油价可能回落
• 但达拉斯联储模拟分析：封锁1个季度，全球GDP年率下降2.9%；封锁2个季度，油价升至115美元，全球GDP连续两季负增长
• IEA成员国已释放4亿桶战略储备（约全球4天消费量），杯水车薪

核心判断： 短期（3-6个月）油价维持90-110美元高位概率较大。即使停火，能源设施修复需要数月，供应恢复缓慢。中长期（12-24个月）取决于冲突是否结束以及全球需求变化。上海社科院徐明棋的判断：即使停火，油价回到60美元的概率较小，90美元可能是新中枢。

二、公司基本面：5年财务数据

数据来源：S&P Global Market Intelligence，单位：亿人民币。

2.1 利润表

2.2 利润率

说明：2023年起毛利率大幅下降，主因是石油特别收益金（暴利税）征收和成本上升。但EBITDA率5年稳定在56-63%区间，经营质量未恶化。

2.3 资产负债表

2.4 现金流量表

三、核心财务指标计算

3.1 ROE（净资产收益率）

ROE = 归母净利润 / 平均归母净资产

*2021年初净资产取4,146亿（2020年末数据）

5年平均ROE = 19.4%

杜邦分解（2025年）：

• 净利率：30.7%
• 资产周转率：3,982 / 10,273 = 38.7%
• 权益乘数：10,986 / 8,028 = 1.37

ROE = 30.7% × 38.7% × 1.37 ≈ 16.3%（与实际15.7%差异来自少数股东权益）

结论：ROE主要由净利率驱动，而非杠杆。权益乘数仅1.37，这是低杠杆的高质量盈利。

3.2 ROA（总资产收益率）

2025年：1,221 / 10,273 = 11.9%

3.3 资产负债率

2025年：2,934 / 10,986 = 26.7%

5年趋势：38.7% → 35.6% → 33.6% → 29.0% → 26.7%，持续下降。

3.4 净现金/市值

净现金1,709亿 / 港股市值约4,430亿 = 38.6%

意味着你买港股海油，有接近4成付的是现金。实际油气资产只花了2,721亿。

四、DCF 估值

4.1 基础参数

4.2 情景假设

情景A：基准（中性偏保守）

• 阶段1（2026-2030）：增长3%/年（产量增长7%对冲油价下行）
• 阶段2（2031-2035）：增长0%
• 永续增长：2%

情景B：悲观

• 阶段1（2026-2030）：增长0%（油价快速回落至60美元）
• 阶段2（2031-2035）：增长-2%
• 永续增长：1%
• WACC提升至12%（高风险溢价）

情景C：乐观（油价高位持续）

• 阶段1（2026-2030）：增长8%/年（美伊冲突持续，油价维持90+）
• 阶段2（2031-2035）：增长3%
• 永续增长：2.5%

4.3 情景A 计算

阶段1现金流（2026-2030）：

阶段1现值合计：4,124亿

阶段2现金流（2031-2035）：零增长，每年1,130亿

阶段2现值合计：2,856亿

永续价值：

TV = 1,130 × (1.02) / (0.09 - 0.02) = 16,466亿

折现到今天：16,466 × 0.4224 = 6,957亿

情景A DCF = 4,124 + 2,856 + 6,957 = 13,937亿

4.4 情景B 计算（悲观）

WACC=12%，阶段1零增长（每年975亿），阶段2每年-2%递减，永续1%。

阶段1（2026-2030）：

阶段1现值：3,515亿

阶段2（2031-2035）：每年-2%递减

阶段2现值：1,886亿

永续价值：

TV = 881 × 1.01 / (0.12 - 0.01) = 8,091亿

折现：8,091 × 0.3220 = 2,605亿

情景B DCF = 3,515 + 1,886 + 2,605 = 8,006亿

4.5 情景C 计算（乐观）

WACC=9%，阶段1增长8%，阶段2增长3%，永续2.5%。

阶段1（2026-2030）：

阶段1现值：4,742亿

阶段2（2031-2035）：增长3%

阶段2现值：3,939亿

永续价值：

TV = 1,660 × 1.025 / (0.09 - 0.025) = 26,177亿

折现：26,177 × 0.4224 = 11,056亿

情景C DCF = 4,742 + 3,939 + 11,056 = 19,737亿

4.6 DCF 估值汇总

即使最悲观的情景（WACC 12%、油价持续低迷、负增长），DCF估值仍比当前港股市值高出80%。

注： 以上计算不含净现金1,709亿（已体现在资产负债表中但未单独加回）。如单独考虑净现金，悲观情景下的下行保护更强。

五、交叉验证

5.1 PE

港股PE 7.2x。国际同行Exxon 12-14x，Shell 10-12x。

5.2 PB

港股：4,430 / 8,028 = 0.55x —— 花5毛5买1块钱净资产。

5.3 FCF Yield

975 / 4,430 = 22.0%

每投入100元，公司当年产生22元自由现金流。

5.4 股息率

全年股息1.28 HKD / 26.10 HKD = 4.9%

5.5 EV/EBITDA

企业价值 = 市值4,430 - 净现金1,709 + 少数股东 = ~2,800亿

EV/EBITDA = 2,800 / 2,501 = 1.12x

这个数字低得离谱。Exxon的EV/EBITDA是6-7x。

六、估值矩阵：不同油价×不同PE

当前港股市值4,430亿。即使油价跌到60美元、只给7x PE，合理市值也有5,600亿，仍有26%上行空间。

七、风险提示

7.1 油价崩跌

最大风险。如果美伊停火、霍尔木兹海峡完全恢复通航、OPEC+增产、全球经济衰退叠加，油价可能快速回落至60美元以下。按60美元测算，净利润降至800亿左右，港股PE升至约5.5x，仍然不贵，但股价可能短期承压。

7.2 地缘冲突升级

如果伊朗 Saudi/UAE/Qatar 能源设施遭到更大规模破坏，全球石油供应可能减少1,950万桶/日（占全球20%），油价可能冲高至150-200美元。这短期内利好海油利润，但全球衰退风险急剧上升，需求端可能崩塌，最终反噬油价。

7.3 能源转型

5-10年维度，新能源替代加速。但石油在化工、航空、航运领域的替代远比乘用车难。海油也在布局海上风电。

7.4 A股估值偏高

A股PE 14.6x，理杏仁3年分位点96.97%。如看好海油，港股性价比远优于A股。

八、结论

数据来源：

• S&P Global Market Intelligence（利润表、资产负债表、现金流量表）
• 上海社科院徐明棋（美伊冲突宏观分析）
• Fortune / Bloomberg / Guardian（霍尔木兹海峡通航数据）
• Trading Economics（布伦特油价）
• 理杏仁（A股PE分位点）
• 华创证券（2026-2028盈利预测）

本文为个人投资分析记录，不构成投资建议。