🏠 home › journal › 2026-04-28

2026-04-28 变更日志

摄取 Karri Saarinen《Some Notes on AI》

来源：raw/notes/karri-saarinen-some-notes-on-ai-2026-04-26.md（Linear co-founder/CEO Karri Saarinen 2026-04-26 X Article 长文，6 节产品哲学札记，139,837 views / 860 likes / 1687 bookmarks。X 直接抓取被 402 封锁，通过 fxtwitter API 拿到 article 字段全文）

新建页面

关键知识提取

  1. AI 市场叙事撕裂的最大单一根因 = expertise paradox — 不是模型在某些领域真的强 / 某些领域真的弱，是观察者判断力的不对称。Casual observer 用 Dunning-Kruger 模式评估（不懂目标领域）→ 看到 magic / 持有"无限能力"印象；Deep practitioner 用 Gell-Mann 模式评估（"湿街道导致下雨"识别力）→ 看到 slop / 持有"具体边界"印象。两类持有的 AI 能力图景相差几倍——这不是态度差异，是评估机制差异 → 与 expertise-paradox 的连接：本概念页就是为承接这条命名移植而抽出的——Saarinen 是公开发言里第一个把这两个已有认知偏差概念合流到 AI 评估场景的命名者；同时回连 individual-vs-institutional-ai METR 实验"用 AI 实际慢 19%、自认快 20%、感知差 39 个百分点"——39 个百分点恰好是这两个机制叠加的具体测量

  2. "Thinking tools" 不是 "Mechanical tools" 给 Harness 加新分类轴 — 传统工具是 mechanical（你用工具栏决定怎么 P 图，工具栏不会反向"建议"你接下来想画什么）；AI 工具是 thinking（你 prompt AI 决定输出什么，但 AI 输出反过来 steer 你接下来怎么想）。双向 steer 关系让"工具影响工作流"命题强度比传统工具大一个数量级。Tool default 不是 default 而是 steering——Claude Code 给 todo 默认结构化清单 = steer 用户朝结构化思考方向 → 与 harness-engineering 的连接：在该页"工具影响工作流"命题之上加一节"thinking tools 不是 mechanical tools"作为新分类轴，给 Harness 设计哲学加"工具应该 steer 用户朝哪个方向"的产品哲学维度

  3. "Hard problems remain hard" 给 95% / 100% 自动化论加任务分类层 — Linear 自家数据：cloud coding agent 月修 1000+ issues 持续加速。但 Saarinen 立刻补反例："hard problems remain hard. Agentic coding does not speed those up as much as the narrative often suggests. The expert still supplies the taste, constraints, and final judgment."。这给 ai-first-engineering CREAO 95% + Anthropic Kat Wu 100% 加了任务分类层修正——smaller bandwidth 任务（重复 fix）可达 100%；hard problems（架构 / 系统 / tradeoff）永远需要 expert judgment。三家不冲突，覆盖三个维度（组织起步门槛 / 单流程合格线 / 任务难度天花板） → 与 ai-first-engineering 的连接：在 95% 操作定义 + Anthropic 100% 反向补强段后加"Linear Saarinen 视角的反例式补强"整段，明确两类任务分开评估，避免把 hard problems 也按 95% 路径推导致"5% 兜底实际是 50% 工作量"陷阱

  4. "Design is planning" 反 design-to-code 工具假设 — Saarinen 作为前 Airbnb 首席设计师 + 前 Coinbase 创始设计师 + Linear CEO 给设计本质重定义："Most design work is about making decisions, understanding the problem, and finding the fit. ... In the AI world, design is like planning for me." 设计 = 视觉 canvas 帮你的脑子问问题，不 = 写最终代码。Figma / Linear 这种"visual canvas + 不直接出 production code"的工具反而更贴合设计本质；design+code 工具把设计降级为 prototype as production，丢掉了设计真正的价值 → 与 agent-ui-is-product 的连接：在该页"反向极化：CREAO AI 不需要 UI"段后加"Design is planning" 整段；同时给 aesthetics-beyond-visual 加"专家级设计师看 AI 出图看到 slop（无法控制单点修改 / 滤镜污染）" 反向 magic 视角

  5. AI 公司是 backend 类、UNIX 风格 composability — Saarinen 给"AI 公司应该长什么样"做了一个反 frontend 投入的判断："I think many AI companies operate more like backend companies. The capability is the model. The harness and tools are being iterated above it, but so far they are often behind the scenes." 加 UNIX 类比："programs are text based can be created independently and combined at runtime. The composability of the operating system is easier than compared to something like modern macOS." 给 sentino-agent 的具体含义：Standalone Agent 平台属于 backend 类，产品价值在 agent runtime / 工具协议 / Memex 记忆，不在 UI——把设计资源倾注在 IP 玩偶 + 粉丝场景（frontend 类），把 backend 资源倾注在 Standalone Agent 协议 / 接口 → 与 individual-vs-institutional-ai 的连接：在该页"双层共存"判断之后加"AI 公司是 backend 类、UNIX composability"整段，给"组织 AI 应该长什么样"加产品形态分类层；与 agent-ui-is-product 的张力通过"产品形态分类化解"——backend 类 vs frontend 类是不同战场，UI 必要性不同

  6. "Vibe coding done well" 不带贬义的合法定义 — wiki 此前从腾讯研究院 + CREAO 自我证伪两侧观察 vibe coding，偏失败侧。Saarinen 给一个不带贬义的合法定义：vibe coding = "following the grain of the tool, moving quickly, accepting that the model has a direction and using that momentum"。这是合法的快速探索模式，但不能替代 planning——否则被 AI steer 朝最容易的方向。本页 6% 完成率是"试图把 vibe coding 当 production"的失败率，不是 vibe coding 整体无用 → 与 vibe-coding-creator-motives 的连接：在该页结语段前加"Vibe coding done well——Saarinen 视角的非贬义重新定义"整段；同时回连 pivot-speed-as-moat——Saarinen 给中间态战略加"不要无 plan，要短 plan"边界条件，反对 plan cycle 固化但同样反对"完全没 plan 让 AI 替你选简单的事"

更新页面

事实核查记录

与同期 wiki 的时点关系

元观察

待办

摄取 Google Memory Bank 调研

来源：raw/notes/google-memory-bank-research-2026-04-28.md（用户网络调研后产物，非原始网页素材聚合，调研日期 2026-04-28；Vertex AI 托管记忆服务，2025-07-08 公开预览 / 2025-12 GA / 2026-04-22 Cloud Next 改名 Agent Platform Memory Bank；算法根基 ACL 2025 论文 RMM）

新建页面

关键知识提取

  1. Google Memory Bank ≈ Memex 的托管版 — 同后台流水线 + 异步提取 + 抗膨胀路线，差异在 topic 预定义 + 强制绑 Gemini + scope/IAM 治理内置。Memex 销售姿态从"对照 mem0 一家"扩到"对照 mem0 + Memory Bank 两家"，Memory Bank 是更难回答的对照样本——客户问"为什么不用 mem0"可以拿"路线代际"答（向量 vs 文本结构化），问"为什么不用 Memory Bank"必须用"具体能力对比 + 业务约束"回答（数据主权 / 模型解绑 / 算法定制深度） → 与 sentino-memex 的连接：在该页"对外定位锚点"段后新增"2026-04 销售对照样本扩展：从 mem0 单对照到三对照"整段（含 mem0 vs Memory Bank 论证差异对照表）；同时在"待观察 / 改进点"段新增第 5 条"Memory Bank 启发的 v2 设计选项"（4 个对照可借鉴点）

  2. mem0 自承的 4 大未解被 Google 部分内置回答 — staleness 问题被 Memory Bank TTL + GENERATE_UPDATED_TTL 直接答；governance 问题被 Memory Bank IAM Conditions + 专用角色（memoryViewer/Editor/User）+ scope 隔离直接答；consent 部分（EXPLICIT_INSTRUCTIONS topic + memory revisions）；cross-session identity 部分（scope arbitrary dict 间接支持）。对 mem0 作为"行业代名词"的稳定性影响：短期内（半年到一年）mem0 的代名词地位还在（开源生态领先），长期（2027+）若 Memory Bank 在企业客户案例上跑通，mem0 可能从"代名词"退化为"开源 PoC 选项" → 与 mem0 的连接：在"mem0 自承的 4 大未解问题"段后新增"2026-04 更新：Google Memory Bank 把这 4 个问题给了部分内置答案"整段（含完成度对照表 + 行业代名词稳定性影响判断）；相关概念加 google-memory-bank

  3. 同一服务两种写入姿态并列是 Memex 当前没有的 — Memory Bank 把"被动后台提取"（GenerateMemories，与 Memex flush 模式一致）和"主动工具调用"（CreateMemory，与 Auto Memory / mem0 一致）在同一服务下并列。Memex 当前只支持被动提取一种姿态。这是 Memex v2 演进时可考虑的设计点——不是因为 Memory Bank 这么做就要跟，而是两种写入姿态分别覆盖不同 agent 行为模式（被动学习用户 vs 显式记某事），合并成一个服务的工程负担可控 → 与 auto-memory 的连接：相关概念加 google-memory-bank 一行（反方向托管对照：单姿态 LLM-in-the-loop vs 两种姿态并列，Memory Bank 的 CreateMemory 接近 Auto Memory 路线）；与 sentino-memex 待观察段新增"两种写入姿态并列"作为 v2 设计选项

  4. Scope arbitrary dict + IAM Conditions 是 Memex 多客户白标场景的潜在演进方向 — Memory Bank 的 scope 是开发者自定义键值对（如 {user_id: '123', session_id: '456'} 做 session 级隔离），可按 scope keys 分别配置不同 customization。Memex 当前是 userId × projectId 二维固定隔离。多客户白标场景下（比如 yukai-agora-poc 这种 OEM 项目），Memex 可能需要演进到 arbitrary dict scope。同时 Memory Bank 内置的 memory revisions + IAM Conditions（专用角色 memoryViewer/Editor/User）是 Memex 在合规客户场景需要补的可审计层 → 与 sentino-memex 的连接：待观察段新增"Scope 演进为 arbitrary dict" + "Memory revisions API + IAM" 两条 v2 设计选项

  5. Memory Bank 的 "Gemini 自动 contradiction resolution + consolidation" 是 Auto Dream 整合机制的托管版 — Memory Bank 把记忆合并放在写入路径上（Gemini 在后台自动判断和处理冲突），与 Auto Dream 定时离线整合（≥24h + ≥5 sessions 触发四阶段）路线不同但目标相同。Memex 走的是"夜间 3 AM 定时合并 + Reinforce 续期"中间路线（既不像 Memory Bank 写入时合并，也不像 Auto Dream 完全离线整合） → 与 auto-dream 的连接：相关概念加 google-memory-bank 一行（差异：Auto Dream 是定时离线整合，Memory Bank 靠 Gemini 在写入路径上自动合并）

  6. Memory Bank 改名要追溯：2026-04-22 Cloud Next 后官方是 Agent Platform Memory Bank — 用户素材里说的"Agent Memory Bank"不准确，实际官方命名是 Agent Platform Memory Bank（与 Agent Platform Sessions / Agent Runtime 形成命名一致性）。Vertex AI 整体改名 Gemini Enterprise Agent Platform，per-agent pricing + 200-model Model Garden + Workspace Studio 无代码构建。对 Sentino 销售的预警：客户提"Memory Bank"时要确认是 2026-04-22 后的命名（Agent Platform Memory Bank）还是 2025-2026Q1 的旧称（Memory Bank），客户是否在 GCP 全栈深度决定其是术语对照需求还是真技术选型对抗 → 与 yukai-agora-poc 的连接：在 AC-08 决策段后新增"2026-04-28 销售对照样本扩展"段（含 mem0 vs Memory Bank 客户姿态判断差异 + 五维论证清单引用）；相关概念加 google-memory-bank

更新页面

事实核查记录

与同期 wiki 的时点关系

元观察

这 4 个样本对应 3 个独立分轴的端点，是足够 MECE 的对照系统。后续新出现的方案可以按这 3 个轴定位，不需要无限扩对照样本——除非出现 3 个轴之外的新分轴（如"on-device 边缘记忆"or"区块链记忆"）才需要新建对照 - Memex 的"自建 + 文本结构化 + 后台流水线"组合在 4 个样本中是唯一占据"自建 + 后台流水线"象限的方案 — Memory Bank 是"托管 + 后台流水线"，Auto Memory 是"自建 + LLM 主动"，mem0 是"开源/托管 + 后台/LLM 决策混合"。这意味着 Memex 的核心差异化论点应当强化"自建 + 后台流水线"组合的稀缺性——客户要"完全自主可控 + 异步处理"只能选 Memex 自建路线（或自己搓一个 Memory Bank 替代品，工程量大） - 客户文档里第三方技术名陷阱在 Memory Bank 场景的新形态 — 与 mem0 的"代名词"性质不同，Memory Bank 在客户 PRD 里出现大概率是真技术选型（GCP 全栈客户决定用一等公民方案）。Sentino 销售要主动判断"客户是术语对照需求还是真选型对抗"——判断依据是客户已有 GCP 基础设施深度。这条加进 yukai-agora-poc 的"销售姿态预警"待办

待办

Memex v2 设计选项评估报告（基于 Memory Bank 4 个借鉴点）

新建：2026-04-28-memex-v2-design-options（status: draft, version: 1）

缘起：摄取 Google Memory Bank 后用户追问"memex 借鉴点详细说明"。知识库已有内容只到"标题级摘要 4 行"，没有工程级拆解 / 优先级排序 / 反建议——独立成报告把 4 个借鉴点提升到"姜涛 + 子昕可直接拿去排期的工程提案"。

核心结论： - P1 必做：① 两种写入姿态（CreateMemory）+ ④ source 字段（一起做 1 周）/ ③ Revision API + IAM 分级（2-3 周） - P2 等触发：② Scope arbitrary dict（触发条件是"第二个 agent 类型接入"或"多 agent 共享平台"） - 反建议：4 个借鉴点没有一个是"看到 Memory Bank 这么做就要跟"——都是 Memex 自身业务驱动决定，Memory Bank 只是给了 API 形态参考。如果近 3 个月无合规客户线索 + Reinforce 命中率 < 50% + 单 agent 阶段，全部缓做合理 - 不变量（4 个借鉴点都不应触及）：不绑 LLM 厂商 / 4 级 TTL × 4 类二维结构 / Reinforce 主动续期 / 夜间合并定时任务 / 数据主权

业务驱动力最强：借鉴点 ③（Revision API + IAM）— 合规客户场景硬卡点，没有的话直接销售失败

对其他页面的修正记录： - sentino-memex "待观察 / 改进点"段第 5 条加优先级标注 + 报告回连 - google-memory-bank "对 Sentino Memex 演进的具体启示"段尾部加报告回连 - sentino-agent 相关概念段加报告条目 - wiki/index.md "## 研究报告" 章节加新条目（按时间倒序顶部）+ "最近更新"加一行

元观察

摄取 Google Agent Platform 完整架构

来源：raw/notes/google-agent-platform-research-2026-04-28.md（用户网络调研后产物，2026-04-28；2026-04-22 Cloud Next Las Vegas 公布的 Vertex AI 改名整体平台；6+ 处官方/学术/行业 source 已交叉核实；摄取背景：知识库上一份调研 google-memory-bank（同日 ingest）只覆盖 Scale 柱单组件，把局部当整体处理——本次是父概念）

新建页面

关键知识提取

  1. 4 pillars × 18 组件全栈内化是 platform-layer-collapse 最强单一实证 — 之前的坍缩证据（Anthropic Claude Code → Cowork → Computer Use）是按时间线分段推进，Google Agent Platform 是一次性宣布全栈：从 Build（Agent Studio + ADK + Garden）到 Optimize（Simulation + Eval + Observability + Optimizer），每个 18 个组件之前都对应至少一家初创公司的核心产品。等于"模型公司一次性吃掉一整代 agent infra 创业公司"。配套 TPU 8t/8i + Anthropic 3.5 GW anchor + Cross-Cloud Infra = 硬件+模型+平台+治理+分发全栈垂直整合 → 与 platform-layer-collapse 的连接：在该页"其他厂商类似路径"段后新增"Google Agent Platform 实证：18 组件单平台内化"整段（含 vs Anthropic Claude Code 路径对比表 + 对中间层公司类型影响判断 + 与 agent-creator-refiner-operator 三元论"Creator 必吃 / Refiner+Operator 中间层"完全一致的判断）

  2. Govern 三件套（Identity + Registry + Gateway）= 企业 agent 治理标准化方向 — Agent Identity 用 SPIFFE 标准 + X.509 证书 + mTLS + DPoP（端到端 cert-bound token / Service Account 不能 impersonate / 不允许长期 key）；Agent Gateway = Thomas Kurian 称"air traffic control" + preventative enforcement before action + 多协议（MCP/A2A/REST/gRPC）但只有 MCP 支持基于 protocol attribute 的授权策略条件；Agent Registry = 中央 catalog + 自动从 deployment 注册。这与 Microsoft Agent 365 Entra ID 是行业标准化方向——Sentino 短期内追不上 Google AP 全栈，但企业客户问起来要有答案 → 与 sentino-agent 的连接：在"对外定位锚点"段前新增"Google Agent Platform 4-pillar 词汇借鉴 + Govern 三件套预警"整段（含 4-pillar 现状对照表 + Govern 三件套预警 4 条 + ADK graph-based 三向分叉表 + Memex revisions API + IAM 是 Govern 柱最小可行起步定位）

  3. ADK 改 graph-based 子 agent 网络是反 orchestration-free-agents 方向行业证据 — google-adk PyPI 2026-04-21 发布 + ADK v1.0 stable 跨四种语言 + 核心升级是从线性子 agent 改为graph-based 子 agent 网络（显式 DAG 编排）。Google 押"显式编排是对的"，回应 LangGraph，反映行业从"单 agent + tool-calling"到"orchestrated 多 agent"转向。三种路径并存：显式 graph 编排（Google ADK / LangGraph）/ 父→子 Subagent 层级（Claude Agent SDK）/ 无编排（Carlini）/ Amphiflow 默认 workflow（amphiflow-pattern） → 与 orchestration-free-agents 的连接：在该页加"反方向证据：行业头部正在押显式编排（2026-04 Google ADK 升级）"整段（含三种路径对照表 + Carlini 哲学的边界 + 对 Sentino 的具体含义"当前不必跟随 Google ADK graph 化"）；同时与 claude-agent-sdk 加"同类对标：Google ADK"段（含两个 SDK 7 维度对比表）

  4. Agent Platform 是 Creator + Refiner 平台典型实例，不直接做 Operator — Google 把 Build 柱（Creator 工具）+ Scale 柱（Refiner 基础设施）一次性内化进自己的全栈平台，但主动不做 Operator——把执行类应用留给 ServiceNow / Salesforce / SAP 接 A2A 协议自己实现。这印证 agent-creator-refiner-operator 三元论"Creator 是模型公司必吃赛道，Refiner+Operator 是中间层生存空间"——证明这条边界不是中间层创业公司一厢情愿，是模型公司主动让出的空间（因为 Liability Wall + Integration Moat） → 与 agent-creator-refiner-operator 的连接：在该页"Devin / Manus 反例"段前新增"Google Agent Platform：Creator + Refiner 平台典型实例"整段（含三元论位置对应表 + 为什么 Google 不做 Operator 的 Liability Wall + Integration Moat 解释 + 对四类中间层公司影响表）

  5. TPU 8t/8i 是 v8 训练-推理拆分的延续，没撤回反而更细化 — 2026-04-22 Cloud Next 同期宣布 TPU 8t（训练，Sunfish，Broadcom，121 FP4 EFLOPS/pod，Anthropic 3.5 GW anchor）+ TPU 8i（推理，Zebrafish，MediaTek，10.1 FP4 PFLOPS/chip，384 MB on-chip SRAM，80% better perf-per-dollar）。代工合作伙伴分叉（Broadcom 训练 / MediaTek 推理）反映 Google 在不同 workload 上对供应链合作伙伴的不同偏好。MediaTek 股价创纪录（TWD 2,090 daily limit）= 商业化预期。 → 与 google-tpu-v8 的连接：在该页加"TPU 8t / 8i：v8 训练-推理拆分的延续"整段（含 8t / 8i 双 SKU 详细参数表 + Anthropic anchor customer 含义 + 含义 4 条）；与 training-inference-bifurcation 的连接：在该页加"TPU 8t/8i 进一步实证"整段——v7 还是单 SKU、v8 拆双 SKU、8t/8i 继续双 SKU + 供应链分叉三代连续产品决策站稳判断

  6. Agent Gateway 多协议中 MCP 享有特殊地位 = MCP 平台基础设施渗透 Layer 4 — Agent Gateway 支持 MCP / A2A / REST / gRPC 多协议，但只有 MCP 支持基于 protocol attribute 的授权策略条件。这是 agora-convoai-join-api Agora 把 mcp_servers 内置进 LLM 配置（Layer 3）之后更高一层的渗透。对 Sentino 的具体含义：当客户切到 Google Agent Gateway 做治理时，MCP server 形态会比 REST 形态获得更细粒度的策略支持——给"Sentino 是否要把工具暴露成 MCP server 形态"开放问题加了新输入 → 与 mcp-protocol 的连接：在该页加"Google Agent Gateway 多协议中 MCP 享有特殊地位"整段（含四协议对照表 + Layer 1-4 渗透阶梯升级表 + 对 Sentino 的具体含义"server 端暴露 MCP 也开始有差异化收益"）

修正上次摄取的事实错误

修正点：本日早些时候摄取 Google Memory Bank 时，事实核查段写 "4 pillars (create/scale/govern/optimize)"——"create" 是错的，官方是 Build/Scale/Govern/Optimize（WebFetch Google Cloud 官方公告原文核实）。

修正方式：本日 journal 早些段（"摄取 Google Memory Bank 调研" 节内事实核查记录）保留原条但加注脚说明错误轨迹（"~~create~~ → Build"），不删除——保留事实核查的真实演进过程。本节是更详细背景说明。

更新页面

事实核查记录

与同期 wiki 的时点关系

元观察

待办