领域 on Albert Intelligence

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

Thu, 14 May 2026 00:00:00 +0000

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

💡 一句话立场

你让 Claude Code 写电商网站，它给的栈是对的——但你要会问。 50 个用户和 10000 个用户，差出来的不只是流量，是整个架构。

我有一个执念：架构是长出来的，不是设计出来的。

每次看到有人 demo 阶段就上 K8s + 微服务全家桶，我都想问一句：你的数据库连过 100 次都没有吧？

下面这套是 Claude Code 在 2025 年的实战默认栈，按用户量分 4 档。第一档你今晚就能跑起来，第四档烧钱烧到怀疑人生。

👤 < 50 👥 50-200 👥👥 200-1000 👥👥👥 1000+
 🌱 🌿 🌳 🌲🌲🌲
 MVP 小型上线 中型电商 大型电商
Tier 0 Tier 1 Tier 2 Tier 3

全景一图流

 ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
 │ 🌱 Tier 0│───►│ 🌿 Tier 1│───►│ 🌳 Tier 2│───►│ 🌲 Tier 3│
 │ < 50 并发│ │ 50-200 │ │ 200-1000 │ │ 1000+ │
 │ 全栈一体 │ │+异步+缓存│ │前后端分离│ │微服务+K8s│
 └──────────┘ └──────────┘ └──────────┘ └──────────┘
 MVP 小型上线 中型电商 大型电商

下面一档一档拆。

🌱 Tier 0 · MVP / Demo（并发 < 50）

📝 用在哪

个人项目 · 原型 · 客户演示 · 小程序店铺

关键词：一把梭，几乎无运维。

你能想到的所有麻烦事——服务器、数据库、CDN、邮件——这一档都不用碰。

长什么样

 ┌─────────────────────────┐
 │ 🖥️ Vercel 一键部署 │
 │ ┌───────────────────┐ │
 │ │ ⚛️ Next.js 全栈 │ │
 │ │ (前 + 后 + API) │ │
 │ └─────────┬─────────┘ │
 └────────────┼────────────┘
 │
 ┌──────▼──────┐
 │ 🐘 Supabase │
 │ Postgres │
 └─────────────┘
 💳 Stripe Checkout (托管页)

Claude Code 默认推荐栈

层	默认推荐
前端	Next.js 15（App Router）+ TS + Tailwind + shadcn/ui
状态	`useState` / `useContext`（不上 Redux）
后端	Next.js API Routes / Server Actions
ORM	Prisma
数据库	SQLite 本地 / Supabase Postgres 免费层
鉴权	Auth.js (NextAuth v5) + Email / Google OAuth
支付	Stripe Checkout（托管页最省事）
文件	Supabase Storage / Cloudinary 免费层
部署	Vercel（一键）

这一档的本质

**全栈一体，零运维。**Claude Code 默认就给你这套，别自作聪明加东西。

🌿 Tier 1 · 小型上线（并发 50-200）

📝 用在哪

正式上线的小店 · 垂直品类 · SaaS 早期

关键词：仍是单体，但开始引入「异步」和「缓存」两个观念。

长什么样

 📱 浏览器
 │
 ▼
 ┌────────────────────┐
 │ ⚛️ Next.js (BFF) │ ◄──── 📨 Resend (邮件)
 │ + TanStack Query │
 │ + Zustand │
 └─────┬──────────────┘
 │
 ┌────▼────┐ ┌──────────┐
 │ 🐘 PG │◄──►│ ⚡ Upstash│
 │ (Neon) │ │ Redis │
 └─────────┘ └──────────┘
 │
 ▼
 ┌────────────┐
 │ ⏱️ Inngest │ ──► 订单后续动作
 └────────────┘

比 Tier 0 多了什么

层	升级点
🎨 前端	加 TanStack Query（服务端状态）+ Zustand（客户端轻量状态）
📋 表单	React Hook Form + Zod（校验和类型同源，神器）
🔁 后端	抽出 service 层 / 用 tRPC 或 Server Actions
🐘 数据库	PostgreSQL 托管（Supabase / Neon / Railway）
⚡ 缓存	Upstash Redis（serverless，按请求计费，便宜）
🔍 搜索	DB 自带 `pg_trgm` / `tsvector` 全文检索（别急着上 ES）
📨 邮件	Resend（发货通知、找回密码）
👀 监控	Sentry 免费层 + Vercel Analytics
⏱️ 队列	Inngest 或 Trigger.dev
🌐 CDN	Vercel / Cloudflare 自带

心法

缓存 + 异步是两个分水岭。 你的代码开始有「立刻返回」和「稍后处理」两条路，这是离开玩具阶段的标志。

🌳 Tier 2 · 中型电商（并发 200-1000）

⚠️ 架构拐点

这一档开始拆了。 前后端分离 + BFF 出现。能不能扛住活动峰值，就看这一档的底子打得稳不稳。

长什么样

 👤 用户
 │
 ┌───────────────────▼───────────────────┐
 │ 🌐 边缘层 Cloudflare / Vercel Edge │
 │ ┌──────────┐ ┌──────────────────┐ │
 │ │ 图片 CDN │ │ Edge Runtime │ │
 │ │ CF Images│ │ 地理路由 / A/B │ │
 │ └──────────┘ └──────────────────┘ │
 └───────────────────┬───────────────────┘
 ▼
 ┌───────────────────────────────────────┐
 │ 🎨 前端 BFF │
 │ ⚛️ Next.js (SSR + ISR + RSC) │
 └───────────────────┬───────────────────┘
 ▼
 ┌───────────────────────────────────────┐
 │ 🔁 独立 API 服务 │
 │ 🦅 NestJS / FastAPI / Hono │
 └──────┬──────────────────────────┬─────┘
 │ │
 ┌───────────▼──────────┐ ┌──────────▼──────────┐
 │ 💾 数据层 │ │ ⏱️ 异步层 │
 │ 🐘 Postgres 主从 │ │ BullMQ / Celery │
 │ ⚡ Redis 会话/购物车 │ │ Inngest / │
 │ 🔍 Meilisearch │ │ Redis Streams │
 │ 📦 R2 / S3 │ │ │
 └──────────────────────┘ └─────────────────────┘

模块拆解

前端

⚛️ Next.js（SSR + ISR）+ Edge Runtime（地理路由 / A/B）
🧩 React Server Components 分担首屏
🖼️ next/image + Cloudflare Images / imgix
📑 商详 ISR 重生成；首页/列表混合 SSR + CSR

后端：独立 API 服务出场

选型	适用
🦅 NestJS	TypeScript 体系
🐍 FastAPI	有 AI / 推荐需求
⚡ Hono / Elysia	轻量 + 边缘部署

API 风格：REST + OpenAPI 或 tRPC（全 TS 时）
BFF 层：Next.js 充当前端的 BFF，聚合下游

数据

🐘 PostgreSQL 主 + 读写分离 / 主从复制
⚡ Redis（Upstash 或自建）：会话、购物车、热门商品缓存、限流
🔍 Meilisearch / Typesense（轻量、自托管友好，别急着上 Elasticsearch）
📦 Cloudflare R2 / AWS S3

异步与事件

⏱️ BullMQ（Node）/ Celery（Python）：订单状态机、库存扣减、发邮件、生成发票
📡 事件驱动：Inngest 或自建 Redis Streams

鉴权与支付

🔐 Clerk 或 Auth.js + 自管 session
💳 Stripe + Webhook + 幂等键（敲黑板）
🛡️ 风控：Stripe Radar + 自定义规则

Tier 2 的真实痛点

不是性能，是数据一致性。 订单、库存、支付三者一旦异步化，就要开始想"如果中间挂了会怎样"。这一档就是从「能跑」到「能扛」的分水岭。

可观测性

🐛 Sentry（异常）
📜 Axiom / Better Stack（日志）
📊 PostHog（产品分析 + Session Replay）
🔭 OpenTelemetry 开始接入

部署

🚀 前端：Vercel / Cloudflare Pages
🐳 后端：Railway / Fly.io / Render（容器化）
🐘 DB：Neon（分支这个 feature 救命）/ Supabase / PlanetScale

🌲 Tier 3 · 大型电商（并发 1000+）

这已经不是 vibe coding 的范畴了

这一档让 Claude Code 一把梭基本翻车。但它仍然有一套主流默认推荐——作为参考可以，作为执行不行。

关键词：微服务 + 事件驱动 + K8s 全家桶。

长什么样（电商六大域）

 👤 海量用户
 │
 ▼
 ┌───────────────────────────────┐
 │ ☁️ Cloudflare │
 │ CDN + WAF + Bot + Rate Limit │
 └───────────────┬───────────────┘
 ▼
 ┌───────────────────────────────┐
 │ 🚪 API Gateway │
 │ Kong / APISIX │
 └───────────────┬───────────────┘
 │
 ┌──────────┬──────────┬───────┴──────┬──────────┬──────────┐
 ▼ ▼ ▼ ▼ ▼ ▼
🪪 Identity 📚 Catalog 🔍 Search 🛒 Cart 📦 Order 💳 Payment
 /Reco
 │
 ┌──────────┬──────────┬──────────┐ │
 ▼ ▼ ▼ │ │
📊 Inventory 🎁 Promo 📨 Notif │ │
 │ │ │ │ │
 └──────────┴──────────┴──────────┴───────────┬────────────┘
 ▼
 ┌──────────────────────────────────┐
 │ 📡 Kafka / NATS 事件总线 │
 └─────────────────┬────────────────┘
 ▼
 ┌──────────────────────────────────┐
 │ ⏰ Temporal 订单履约工作流 │
 └──────────────────────────────────┘

 数据层（按服务路由）:
 ─────────────────────────────────────────────────────────
 🐘 Postgres 集群 + PgBouncer ◄── Order / Inventory / Cart
 🔎 Elasticsearch + pgvector ◄── Search / Reco
 ⚡ Redis Cluster ◄── Cart / Promotion
 📈 ClickHouse ◄── Notification 埋点 / 大盘

整体架构思路

🧩 微服务 或 模块化单体（Modular Monolith） 二选一（别教条）
🔌 前后端彻底分离，多端共用 API Gateway
📖 CQRS（读写分离）在订单、库存、商品三大领域常见
📡 Event-Driven：Kafka / NATS / Redpanda 做事件总线

前端

端	默认
🖥️ Web 主站	Next.js（SSR + ISR）
📱 App	React Native / Expo
🛍️ Storefront	Vercel Commerce / Medusa / Shopify Hydrogen 思路
🧱 Design System	独立仓库（Turborepo monorepo + 自建组件库）
⚡ 边缘渲染	Cloudflare Workers / Vercel Edge

后端服务拆分（典型电商域）

服务	职责	默认技术
🪪 Identity	用户、鉴权、权限	NestJS / Go
📚 Catalog	商品、SKU、类目	NestJS / Go（读多写少）
🔍 Search	搜索、推荐	Elasticsearch / OpenSearch + 向量（pgvector / Qdrant）
🛒 Cart	购物车	Redis 主存 + Node/Go
📦 Order	订单状态机	Go / Java（Saga 模式）
📊 Inventory	库存（强一致）	Go + Redis Lua 扣减
💳 Payment	支付、对账	独立服务，严格幂等
🎁 Promotion	优惠券、活动	规则引擎
📨 Notification	邮件/短信/Push	异步 worker
✨ Recommendation	个性化	Python + 向量库

数据层

 📥 写
 ↓
 ┌────────────┐
 │ 🐘 Postgres │ ─────► 各服务垂直拆分
 │ 主库 │
 └─────┬──────┘
 │ 读写分离
 ┌─────▼──────┐
 │ 🔄 PgBouncer│
 └────────────┘

 ⚡ Redis Cluster ─── 缓存 / 会话 / 限流 / 分布式锁 / 热点 key
 🔎 ES / OpenSearch ─ 商品搜索 + 日志 (ELK)
 📈 ClickHouse ────── 埋点 / 订单分析 / 实时大盘
 📦 S3 / R2 ────────── 图片、静态资源 + CDN

消息与异步

🚌 Kafka / Redpanda / NATS JetStream：领域事件
⏰ Temporal：复杂工作流（订单履约、退款流程）—— Claude Code 在 2025 年很爱推这个

流量层

☁️ Cloudflare（CDN + WAF + Bot 管理 + Rate Limit）
🚪 API Gateway：Kong / APISIX / 自建（Hono on Edge）
🔌 gRPC 内部通信，REST/GraphQL 对外

可观测性（必须三件套）

 📊 Metrics ─── Prometheus + Grafana
 📜 Logs ────── Loki / ClickHouse / ES
 🕸️ Traces ──── Tempo / Jaeger（OpenTelemetry 统一）
 🐛 Errors ──── Sentry
 📈 业务大盘 ── ClickHouse + Grafana

基础设施

🚢 Kubernetes（EKS / GKE / ACK）
🏗️ Terraform / Pulumi 管 IaC
🔄 ArgoCD / Flux 做 GitOps
🐳 Docker + 多阶段构建
⚙️ CI/CD：GitHub Actions + 自托管 runner

大促 / 高并发的关键技术

技术	用法
📦 库存预扣 + 异步落库	Redis Lua + Kafka
🚦 限流	令牌桶 / 漏桶（Redis + Lua）
🛡️ 熔断降级	商详降级到静态、推荐降级到热销
🧠 本地缓存	Caffeine（JVM）/ 进程内 LRU
⚡ CDN 边缘缓存	商品页 ISR + `stale-while-revalidate`
🆔 分布式 ID	Snowflake / ULID
🔒 幂等	订单创建、支付回调强制幂等键

一张总览表（横向对比）

维度	🌱 Tier 0 (<50)	🌿 Tier 1 (50-200)	🌳 Tier 2 (200-1000)	🌲 Tier 3 (1000+)
架构形态	全栈单体	单体 + 异步任务	前后端分离 + BFF	微服务 / 模块化单体
前端	Next.js	Next.js + RQ	Next.js + Edge	Next.js + RN + Monorepo
后端	API Routes	API Routes + Service	NestJS / FastAPI	多服务 + Gateway
数据库	SQLite / Supabase	Postgres 托管	Postgres 主从 + Redis	PG 集群 + Redis Cluster + ES + ClickHouse
搜索	LIKE / pg_trgm	Postgres FTS	Meilisearch	Elasticsearch + 向量
队列	无	Inngest	BullMQ / Celery	Kafka + Temporal
部署	Vercel	Vercel + Railway	Vercel + Fly.io	K8s + Cloudflare
监控	Sentry	Sentry + PostHog	+ Axiom + OTel	Prom + Grafana + Loki + Tempo
支付	Stripe Checkout	Stripe + Webhook	Stripe + 风控	多渠道 + 对账系统

实战心法（用 Claude Code 时记住这 3 条）

💡 心法 1 · 不要一上来就 Tier 3

Claude Code 默认会给你 Tier 0/1，这是对的。等真有流量再迁。为想象中的流量买单，是创业失败的常见死法。

💡 心法 2 · 跨档迁移优先级

数据库和搜索最容易踩坑，跨档迁移时优先重构这两块。其他模块（缓存、CDN、监控）几乎可以无痛升级。

⚠️ 心法 3 · 国内场景特别提示

Vercel / Stripe / Supabase 在国内访问有问题，可替换为：

☁️ 阿里云函数计算 / Sealos

🌐 腾讯 EdgeOne CDN

🐘 PingCAP TiDB Serverless

💴 连连 / 微信支付 / 支付宝

📌 vibe coding 隐藏陷阱

让 Claude Code 在每个 tier 之间只迁移一两个组件，不要让它一次性大重构。 它在大重构里容易引入回归——它越自信，你越要 review。

决策导图：什么时候该升级？

不是看时间，是看信号。

 📈 流量上来了
 │
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ DB CPU > 70% ? │────────►│ 升 Postgres 主从 │
 └─────────┬────────┘ │ + Redis 缓存 │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 首页 P95 > 2s ? │────────►│ 上 ISR / Edge │
 └─────────┬────────┘ │ + CDN 缓存 │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 订单峰值堆积 ? │────────►│ 拆异步队列 │
 └─────────┬────────┘ │ BullMQ / Celery │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 搜索慢 / 不准 ? │────────►│ 换 Meilisearch │
 └─────────┬────────┘ │ / Elasticsearch │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐
 │ ✅ 保持现状 │
 │ 继续观察 │
 └──────────────────┘

这张图比任何架构师的脑补都靠谱。 让数据告诉你升不升。

核心关键词

电商架构 vibe coding Claude Code 渐进式架构 Tier 0-3 Next.js 微服务 单体 BFF PostgreSQL Redis Stripe Vercel K8s Kafka Temporal CQRS 事件驱动 可观测性 阿里云/国内替换

写在最后

架构是长出来的，不是设计出来的。

先让 Claude Code 给你 Tier 0/1，把生意跑起来。

用户说慢了再上缓存。订单堆了再拆队列。团队大了再拆服务。

别为想象中的流量买单。

这一句话，能省掉你创业前两年 80% 的架构焦虑。

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

Tue, 05 May 2026 00:00:00 +0000

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

一句话开场

我手头有两个 AI Agent，核心代码量几乎一样：3110 行 vs 3084 行。但跑同一个任务——「给笔记画张架构图」——一个 8 秒搞定且越跑越准，另一个一分钟出来还经常翻车。差在哪？

主角登场

先认识下这俩。

O-easy Agent：我们自己用 Rust 写的小工具，专门干一件事——在 Obsidian 里读写笔记。5 个工具，3110 行代码。

GenericAgent：lsdefine 在 GitHub 开源的通用 AI Agent 框架（lsdefine/GenericAgent），口号是「不预装能力，让 Agent 自己长出来」。9 个工具，3084 行代码。

记住这两个数字：3110 和 3084。

它们差不多，但下文你会看到，能力差出一个数量级。这就是今天要说的事。

第一眼看不出门道，第二眼吓一跳

先把两边架构画出来。

flowchart TB
 subgraph OE["O-easy Agent (Rust · 3110 行)"]
 direction TB
 OE_main["ACP 入口"]
 OE_loop["Prompt Loop
max_turns = 10"]
 OE_tools["5 个笔记专用工具"]
 OE_mem["单层 history
(进程内)"]
 OE_main --> OE_loop --> OE_tools
 OE_loop --> OE_mem
 end

 subgraph GA["GenericAgent (Python · 3084 行)"]
 direction TB
 GA_main["Agent 主循环"]
 GA_loop["Agent Loop
~100 行 / max_turns = 70"]
 GA_tools["9 个原子工具
含 code_run"]
 GA_mem["5 层记忆
L0 → L4"]
 GA_evo["Self-Evolving SOP
(任务自动结晶)"]
 GA_main --> GA_loop --> GA_tools
 GA_loop --> GA_mem
 GA_mem -.写入.-> GA_evo
 GA_evo -.读出.-> GA_loop
 end

 style OE fill:#fef3c7,stroke:#92400e,color:#000
 style GA fill:#dbeafe,stroke:#1e3a8a,color:#000
 style GA_evo fill:#fbcfe8,stroke:#9d174d,color:#000

注意右下那块粉色的 Self-Evolving SOP。

这是 GenericAgent 的灵魂。它让 Agent「今天学会的事，明天直接做」。O-easy 完全没有这块。

下面拆开讲，差异在哪。

差异 1：5 个专用工具 vs 9 个万能工具

flowchart LR
 subgraph A["O-easy: 任务专用"]
 T1[read_note]
 T2[write_note]
 T3[edit_note]
 T4[search_vault]
 T5[list_notes]
 end
 subgraph B["GenericAgent: 原子万能"]
 U1[file_read]
 U2[file_write]
 U3[file_patch]
 U4["code_run ★"]
 U5[web_scan]
 U6[web_execute_js]
 U7[ask_user]
 U8[update_working_checkpoint]
 U9[start_long_term_update]
 end

 style U4 fill:#fde68a,stroke:#b45309,color:#000

O-easy 的 5 个工具都长一个样：xxx_note。它的能力天花板就是这 5 个事，写死了。

想画图？没工具。想跑统计？没工具。想抓网页？没工具。

GenericAgent 这边有个杀手锏叫 code_run。

这个工具的本质是「图灵完备的钥匙」。你想干啥它都能干——只要那件事能用代码表达。

💡 举例：让 Agent 给你画一张 mermaid 架构图

O-easy 怎么做：让大模型脑补输出 mermaid 字符串，写进笔记。没人验证语法对不对。

GenericAgent 怎么做：先 code_run 跑一段 Python 提取笔记结构 → 让大模型基于结构出 mermaid → 再 code_run 调 mermaid-cli 真的渲染一遍 → 错了重画。

多了一层验证。质量差距就这么来的。

差异 2：思考 10 步 vs 思考 70 步

O-easy ███████████ (10 turns)
GenericAgent ███████████████████████████████████████████████████████████████████████ (70 turns)
 0 10 20 30 40 50 60 70

复杂任务的天然节奏：读 → 想 → 试 → 错 → 改 → 再试 → 验证 → 写。

10 步通常不够。70 步才有「自我纠错」的空间。

这就像考试：限时 10 分钟你只能写完，限时 70 分钟你能写完还能检查三遍。

差异 3：单层记忆 vs 5 层记忆（业界最大短板）

绝大多数 Agent 框架的记忆都很简单：要么没有，要么就一层「对话历史」。

GenericAgent 不一样。它有 5 层。

flowchart TD
 subgraph OE["O-easy 的记忆"]
 H1["对话 history
(进程内, max 20 轮)"]
 H1 -.进程死.-> X1["全部清零"]
 end

 subgraph GA["GenericAgent 的 5 层记忆"]
 L0["L0 · Meta Rules
行为底线"]
 L1["L1 · Insight Index
能力索引"]
 L2["L2 · Global Facts
长期事实"]
 L3["L3 · Task SOPs ★
会做的剧本"]
 L4["L4 · Session Archive
历史归档"]
 L0 --- L1 --- L2 --- L3 --- L4
 end

 style H1 fill:#fee2e2,stroke:#991b1b,color:#000
 style X1 fill:#fee2e2,stroke:#991b1b,color:#000
 style L0 fill:#e0e7ff,stroke:#3730a3,color:#000
 style L1 fill:#c7d2fe,stroke:#3730a3,color:#000
 style L2 fill:#a5b4fc,stroke:#3730a3,color:#000
 style L3 fill:#fbcfe8,stroke:#9d174d,color:#000
 style L4 fill:#818cf8,stroke:#312e81,color:#fff

层	作用	一句话说人话
L0	行为约束	「什么不能做」（比如不能删 vault 文件）
L1	能力索引	「我知道我能干哪些事」（轻量目录）
L2	长期事实	「这个用户喜欢用 mermaid 画图」
L3	任务剧本	「画 RAG 架构图的标准流程」 ← 关键
L4	历史档案	「上周做过的任务都在这」

⚠️ L3 是真正的杀手锏

LangChain 没有这层，AutoGPT 没有这层，Claude Code 也没有这层。L3 不是简单的「对话历史」，而是结构化的「做事剧本」。Agent 干完一件事会自动总结成 SOP 写进来，下次类似任务直接照着剧本演。

打个比方：

L4 是档案室（散乱的过去记录）
L2 是公司维基（稳定的事实库）
L3 是部门 SOP 手册（让新人快速上手的关键资料）

绝大多数 Agent 框架只有档案室和维基，没有 SOP 手册。GenericAgent 把这一层做出来了。

差异 4：能力增长方式（这是最大的范式跃迁）

我把这条放最重要的位置。

传统 Agent 框架的能力公式：

能力 = Σ(预装的工具)

要新能力 = 写新代码 + 改框架 + 发新版 + 用户更新。一条龙重资产。

GenericAgent 的能力公式：

能力 = Σ(L3 里积累的 SOP)

要新能力 = Agent 自己摸索 + 跑通 + 结晶成 SOP + 写入 L3。完全不用碰代码。

flowchart LR
 subgraph TRAD["传统模式"]
 direction TB
 A1[新需求] --> B1[人写新工具]
 B1 --> C1[改框架代码]
 C1 --> D1[发新版本]
 D1 --> E1[用户更新]
 E1 -.重复.-> A1
 end

 subgraph GA["GenericAgent 模式"]
 direction TB
 A2[新需求] --> B2[Agent 自己探索]
 B2 --> C2[跑通 → 结晶为 SOP]
 C2 --> D2[写入 L3 记忆]
 D2 --> E2[下次秒级复用]
 E2 -.->|越用越快| A2
 end

 style TRAD fill:#fef3c7,stroke:#92400e,color:#000
 style GA fill:#dbeafe,stroke:#1e3a8a,color:#000

类比一下：

传统模式 = 建工厂。要新能力等于加新车间，重资产，慢。
GenericAgent = 学徒工。每做一件事，工艺手册就厚一页。自己越来越熟练。

教程里给的数据：同一类任务从「自然语言描述 → SOP → 直接 code 调用」三阶段进化，token 消耗下降 89.6%。

关键差距

传统 Agent 上线第一天和第一年表现一样。GenericAgent 用了一年的能力是用了一天的 N 倍。

差异 5：上下文管理——反潮流的反向操作

业界都在卷长上下文。Claude 卷到 200K，Gemini 卷到 1M，Qwen 也跟上来了。

GenericAgent 反着来：死磕 30K。

项	O-easy	GenericAgent
策略	按消息轮数粗略剪	4 阶段压缩管道
目标	保最近 N 轮	维持 30K token 高密度
长任务表现	容易塞满重复 read 结果	自动压缩、提取要点、丢冗余
方向	跟随业界	反向操作

为什么反潮流？

📝 业界都在装着不知道的事实

LLM 的 attention 机制在 30K 之后衰减明显，长上下文是「花更多钱、办更少事」。

GenericAgent 把这个问题反过来——不堆长度，堆密度。同样 30K 的窗口，塞最有用的东西，劣质信息及时压缩或丢掉。

教程里说，这个策略让 GenericAgent 比 Claude Code 节省 65% token（消耗约 35%）。

实战对比：让 Agent 给笔记画一张架构图

干了这么多铺垫，看看真打起来什么样。

任务：「把这篇 RAG 技术笔记总结一下，给我画张架构图」。

O-easy 怎么做

sequenceDiagram
 autonumber
 participant U as 用户
 participant O as O-easy
 participant L as LLM (Qwen)
 participant V as Vault

 U->>O: 给 RAG 笔记画架构图
 O->>V: read_note("RAG技术.md")
 V-->>O: 全文内容
 O->>L: 帮我画架构图
 L-->>O: mermaid 字符串
(可能语法错)
 O->>V: write_note(追加 mermaid)
 V-->>O: 写入完成
 O-->>U: 完成
 Note over U,V: 没有验证 · 错了用户才发现

5 步搞定，但没有验证。LLM 输出语法错你也不知道，要等用户在 Obsidian 里渲染失败才回头看。

GenericAgent 怎么做

sequenceDiagram
 autonumber
 participant U as 用户
 participant G as GenericAgent
 participant L as LLM
 participant C as code_run
 participant F as 文件系统

 U->>G: 给 RAG 笔记画架构图
 G->>L: 检查 L3 SOP "画架构图"
 L-->>G: 找到上次的 SOP

 G->>F: file_read("RAG技术.md")
 F-->>G: 全文

 G->>C: 跑 Python 提取章节结构
 C-->>G: 结构化 JSON

 G->>L: 基于结构生成 mermaid
 L-->>G: mermaid 代码

 G->>C: mermaid-cli 渲染验证
 C-->>G: 语法正确

 G->>F: file_patch(追加到笔记末尾)
 F-->>G: 完成

 G->>G: update_working_checkpoint
(优化 L3 SOP)
 G-->>U: 完成 + 已自我改进
 Note over U,F: 有验证 · 有改进 · 下次更快

10 步，多了 3 件事：

先查 L3 有没有现成 SOP
用 code_run 真的跑一遍验证 mermaid
完事更新 SOP，下次更快

质量和效率全在这 3 步上拉开。

代码量真相：3000 行 vs 3000 行，谁花得更聪明

项目	核心源码	工具数	记忆层数	自演化	测试
O-easy	3,110 行	5 个专用	1 层	否	0
GenericAgent 核心	3,084 行	9 个原子	5 层	是	未统计

两边代码行数几乎一样，能力密度天差地别。

差在哪？看 GenericAgent 的 3000 行花在哪：

pie title GenericAgent 3084 行核心代码分布
 "agent_loop.py (核心循环)" : 118
 "agentmain.py (入口与模式)" : 266
 "ga.py (9 个工具实现)" : 558
 "llmcore.py (多 LLM 抽象)" : 988
 "simphtml.py (HTML 瘦身)" : 870
 "TMWebDriver.py (浏览器)" : 284

注意 agent_loop.py 才 118 行——作者宣传的「100 行核心循环」是真的，不是营销话术。整个 Agent 大脑就这 118 行。

而 O-easy 的 3110 行：

pie title O-easy 3110 行代码分布
 "tools/* (5 个笔记工具)" : 1026
 "protocol/* (ACP 协议)" : 522
 "llm/* (LLM 客户端)" : 292
 "vault/path_guard.rs (安全)" : 194
 "config.rs" : 140
 "其他" : 936

1026 行花在 5 个工具——平均每个工具 200 行。每个工具都在做差不多的事：path 校验、permission 流程、转 JSON。重复造轮子的味道很浓。

同样 3000 行

GenericAgent 把每行都用在让 Agent 能自我成长的脚手架上。O-easy 的每行都被锁死在「这 5 件事」里。

GenericAgent 的真正创新（一句话每条）

业界对比下，能拍着胸脯说「这是我的原创」的，就这 5 条：

1. 能力 = 记忆，不是代码 —— Agent 框架从「工具盒」变成「学习者」。这是范式跃迁，不是迭代。

2. 5 层记忆 + L3 SOP 这一层 —— LangChain 没有，AutoGPT 没有，Claude Code 也没有。第一次有框架认真做「Agent 自己的 SOP 手册」。

3. 9 个原子工具 + code_run 元工具 —— 用 9 个原语组合出无限能力，而不是堆一百个专用工具。

4. 信息密度优先（反 1M context 潮流） —— 业界都在卷长度，它在卷密度。结果 token 消耗只有 Claude Code 的 35%。

5. 真实浏览器注入（不开 headless） —— 直接操作用户已登录的 Chrome，不用绕验证码、不用模拟登录。RPA 圈子有人做，Agent 圈子做的没几家。

给读者的两条启示

如果你将来想自己设计一个 Agent，记住这两条：

启示 1：选「原子工具 + 代码执行」，不要堆专用工具

反例（O-easy 走的路）	正解（GenericAgent 走的路）
加 send_email 工具	加 code_run，让 Agent 写 smtplib
加 query_db 工具	加 code_run，让 Agent 写 SQL
加 generate_chart 工具	加 code_run，让 Agent 用 matplotlib
工具数量爆炸 → 维护噩梦	9 个原子工具搞定一切

工具集合是 Agent 的天花板。专用工具 = 低天花板 + 高维护成本。原子工具 + code_run = 天花板由 LLM 能力决定，不由你预设。

启示 2：把能力增长留给「运行时」，不要全压在「开发时」

flowchart LR
 A[开发时
写脚手架] --> B[运行时
积累 SOP]
 B --> C[使用时间越长
越聪明]

 style A fill:#dbeafe
 style B fill:#fbcfe8
 style C fill:#bbf7d0

长期复利。这是 GenericAgent 真正甩开同行的一招。

你该用哪个

flowchart TD
 Q{你的需求}
 Q -->|做单一类型任务
如笔记 CRUD| A[O-easy 类
专用 Agent]
 Q -->|做开放式任务
每天都不同| B[GenericAgent 类
通用 Agent]
 Q -->|想理解 Agent 架构
做研究| C[直接读 GenericAgent 源码
3000 行 一周看完]

 style A fill:#fef3c7,stroke:#92400e,color:#000
 style B fill:#dbeafe,stroke:#1e3a8a,color:#000
 style C fill:#dcfce7,stroke:#166534,color:#000

场景	推荐
我只想给 Obsidian 加个写笔记 AI	O-easy Agent（轻、快、专）
我想要一个能干所有杂活的 AI 助手	GenericAgent
我想学 Agent 架构内功	读 GenericAgent 源码

结尾一句话

代码量决定下限，记忆密度决定上限。

GenericAgent 的真正创新，不在于「少」，而在于把少省下来的精力，全部投在了让 Agent 能自我成长上。

3000 行不是它的天花板。它的天花板是用户每多用一次，就被推高一点。

这才是 Agent 框架的未来。

网站密码加盐的原理

Tue, 05 May 2026 00:00:00 +0000

密码哈希与加盐：从原理到实战

核心命题：假设数据库一定会被拖走，怎么让攻击者拿到也没用？

在本仓库中的位置

这是 Claude Code Vibe Coding 应用的架构分档手册中「鉴权与支付」一节的深度展开。任何 Tier ≥ 1 的应用，密码存储方案都要按本文执行。

一、为什么密码不能明文存？

❌ 明文存储
┌────────────────────────────────┐
│ 用户名 | 密码 │
│ albert | 123456 │ ← 拖库 = 灾难
│ zhangsan | qwerty │
└────────────────────────────────┘

一旦数据库泄露（拖库），所有用户密码瞬间暴露。更糟的是用户常在多个网站用同一密码 → 一处泄露，处处沦陷（撞库攻击)。

📌 2011 年 CSDN 拖库事件，600 万账号明文密码泄露，引爆中国互联网密码安全意识。

二、第一层防御：哈希算法

哈希 = 单向的数学函数。

 hash()
"123456" ───────► e10adc3949ba59abbe56e057f20f883e
 （永远是这个值，不可反推）

三大特性

特性	含义
确定性	同样输入 → 同样输出，永远成立
不可逆	从哈希值反推不出原密码
雪崩效应	输入变一点点，输出天差地别

雪崩效应直观感受

"123456" ──► e10adc3949ba59abbe56e057f20f883e
"123457" ──► f1887d3f9e6ee7a32fe5e76f4ab80d63
 ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
 完全没有规律可言

哈希到底怎么算的？（以 MD5 为例）

"123456"
 │
 ▼ 编码成二进制
[00110001 00110010 ...]
 │
 ▼ 填充到 512 位倍数
[512 位数据块]
 │
 ▼ 4 个魔法初值
A=0x67452301 B=0xefcdab89 C=0x98badcfe D=0x10325476
 │
 ▼ 64 轮"揉面"：AND / OR / XOR / 左旋 / 加常数
 │ 每一轮：新B = B + 左旋(A + F(B,C,D) + M[i] + K[i], s)
 │
 ▼ 最终拼接 A|B|C|D
e10adc39 49ba59ab be56e057 f20f883e ✅

为什么不可逆？ 因为大量使用了 AND / OR 这种有损运算——1 AND 0 = 0，但反过来你不知道原本是什么。

三、单纯哈希也不够：彩虹表攻击

攻击者会预先计算常见密码的哈希，做成超大对照表：

🌈 彩虹表（攻击者一次性投入几个月算好）
┌──────────────────────────────────────────────┐
│ 123456 → e10adc3949ba59abbe56e057f20f883e│
│ password → 5f4dcc3b5aa765d61d8327deb882cf99│
│ qwerty → d8578edf8458ce06fbc5bb76a58c5ca4│
│ ...（数十亿条） │
└──────────────────────────────────────────────┘

拖库 → 拿哈希 → 查表 → 瞬间还原 1000 万个密码 💀

“算一次表，破解所有人”——成本极低。

四、第二层防御：加盐（Salt）🧂

给每个用户生成随机字符串作为盐，拼到密码后再哈希：

注册流程
─────────────────────────────────────────────
用户输入: "123456"
随机生成: 盐 = "x7Kp9mQ2"
计算: hash("123456" + "x7Kp9mQ2") = a3f5b8c1...
存储:
┌──────────┬────────────┬──────────────┐
│ 用户名 │ 盐 │ 哈希 │
├──────────┼────────────┼──────────────┤
│ albert │ x7Kp9mQ2 │ a3f5b8c1... │
│ zhang │ Lp4nR8wX │ 9d2e7f4a... │ ← 同样密码，盐不同，哈希也完全不同
└──────────┴────────────┴──────────────┘

关键认知颠覆 ⚠️

盐是公开存储的，不是秘密！

那加盐有什么用？看对比：

没加盐 🌈
─────────────
攻击者：算一次彩虹表 → 破解所有用户 ✅
成本：低

加盐后 🧂
─────────────
攻击者：每个用户盐不同
 → 用户1 算一张表（几个月）
 → 用户2 盐不一样，再算一张表（几个月）
 → 1000 万用户 = 1000 万张表 ❌
成本：彩虹表攻击经济上完全不可行

盐的作用不是"保密"，而是"让批量破解失去经济意义"。

五、第三层防御：慢哈希算法

加盐后，攻击者还能针对单个用户暴力破解：

拿 albert 的盐 + 哈希
 ↓
试遍所有密码组合 → 找到匹配

普通 SHA-256 太快——GPU 一秒能算几十亿次。

解决方案：故意把哈希算法设计得很慢。

普通 SHA-256: 每秒 1,000,000,000 次 → 试遍 8 位密码只需几小时
bcrypt (cost=12): 每秒 300 次 → 同样的破解需要几百年
Argon2: 每秒 100 次 → 还要消耗大量内存，GPU 加速无效

算法	特点	推荐度
MD5 / SHA-1	已破解，禁用	❌
SHA-256	太快，不适合密码	❌
bcrypt	经典，自带盐	✅
scrypt	抗 GPU/ASIC	✅
Argon2	2015 密码哈希竞赛冠军	⭐ 首选

对单次登录用户无感（0.1 秒），对暴力破解者来说成本提高几亿倍。

六、第四层防御：Pepper（胡椒）🌶️

如果想再加一层——

	Salt（盐）	Pepper（胡椒）
存哪里	数据库，和哈希一起	应用代码 / 环境变量 / KMS
每用户	不同	全局共用一个
拖库会泄露吗	会	不会（除非服务器也被入侵）

hash = Argon2(密码 + 盐 + Pepper)
 ▲
 └── 不进数据库，藏在应用层

双层物理隔离：要破解必须同时攻破数据库 + 应用服务器。

💡 落到你的真实环境

Pepper 应该存在哪？参考你已经在用的两台服务器 —— 阿里云服务器代码资产盘点-2026-04-23 与云服务器代码资产盘点-2026-04-23 推荐做法：写进各服务的 systemd Environment 文件 / .env 并 chmod 600， 绝不进 Git；如果上了阿里云 KMS，就用 KMS 凭据 API 拉取。

七、完整防御链总览

 密码安全分层防御 🛡️
 ┌─────────────────────────────────────────┐
 │ │
 │ ┌──────────────────────────────────┐ │
 │ │ ❌ 明文 │ │ 拖库 = 死
 │ └──────────────────────────────────┘ │
 │ ⬇ │
 │ ┌──────────────────────────────────┐ │
 │ │ 🔒 哈希 防明文裸奔 │ │ 防彩虹表？❌
 │ └──────────────────────────────────┘ │
 │ ⬇ │
 │ ┌──────────────────────────────────┐ │
 │ │ 🔒 + 🧂 加盐 防彩虹表 │ │ 防暴力？⚠️
 │ └──────────────────────────────────┘ │
 │ ⬇ │
 │ ┌──────────────────────────────────┐ │
 │ │ 🔒 + 🧂 + 🐌 慢算法 防暴力破解 │ │ 防服务器入侵？⚠️
 │ └──────────────────────────────────┘ │
 │ ⬇ │
 │ ┌──────────────────────────────────┐ │
 │ │ 🔒+🧂+🐌+🌶️ Pepper 分层隔离 │ │ ✅ 现代最佳实践
 │ └──────────────────────────────────┘ │
 └─────────────────────────────────────────┘

注册流程

用户密码 ──► 生成随机盐 ──► Argon2(密码 + 盐 + Pepper) ──► 入库
 ┌────────────────┐
 │ 用户 | 盐 | 哈希 │
 └────────────────┘

登录流程

用户输入 ──► 查出该用户的盐 ──► Argon2(密码 + 盐 + Pepper) ──► 比对哈希
 ↓
 相等 → 登录成功
 不等 → 拒绝

八、相关攻击术语

术语	含义
拖库	攻击者把整个数据库下载走
洗库	在拖到的数据中筛选高价值信息（VIP、管理员等）
撞库	用 A 网站泄露的密码去 B/C/D 网站尝试登录
彩虹表	预先计算的"密码 → 哈希"对照表
碰撞攻击	找到两个不同输入产生同一哈希值（MD5 已被攻破）

九、给开发者的实践清单

永远不要自己实现密码哈希算法
使用成熟库：Python passlib / Node bcrypt / Rust argon2 crate
首选 Argon2id，备选 bcrypt（cost ≥ 12）
盐至少 16 字节，密码学安全的随机数生成器生成（不要用 Math.random()）
Pepper 存在环境变量或 KMS，永不进代码仓库
配套措施：登录失败次数限制、2FA、异常登录告警

📝 在你已有项目里落地

给Hermes Agent装上Open WebUI：从零到一的完整实践中如果开放了用户登录，建议把默认 Open WebUI 的密码哈希策略升级为 Argon2id + Pepper。而 Claude Code Vibe Coding 应用的架构分档手册的 Tier 0 → Tier 1 升级时， Auth.js / Clerk 默认已用 bcrypt，如果走自管 session 就要手动选算法。

十、给用户的自保清单

不在多个网站用同一密码（用 Bitwarden / KeePass 等密码管理器）
重要账户开启 2FA / TOTP（Google Authenticator、Authy）
定期上 haveibeenpwned.com 查邮箱是否在已知泄露库
长密码 > 复杂密码（correct horse battery staple > P@ssw0rd!）

💡 移动端体验小贴士

wiki-iphone-pwa-使用指南-2026-05-02 里提到的 PWA 形态，配合 iOS Keychain / Face ID 可以做到长密码 + 一键登录两不误，是用户侧自保清单的最佳工程实现。

一句话总结

哈希防明文裸奔，加盐防彩虹表，慢算法防暴力破解，Pepper 防数据库单点失陷。 现代密码学不追求"绝对安全"，而是让攻击成本翻几个数量级，最终让攻击者放弃。

🔗 本仓库相关笔记

强相关（同一架构链路）

Claude Code Vibe Coding 应用的架构分档手册 —— 鉴权与支付一节的纵向展开
阿里云服务器代码资产盘点-2026-04-23 —— Pepper / KMS 实际落地的服务器
云服务器代码资产盘点-2026-04-23 —— 同上，多机部署时同步 Pepper

中等相关（应用层接入）

给Hermes Agent装上Open WebUI：从零到一的完整实践 —— Web 应用用户登录系统
wiki-iphone-pwa-使用指南-2026-05-02 —— 移动端密码体验与 Face ID

知识体系入口

从零搭建Obsidian全栈知识系统 —— 这条笔记在领域库的位置
Obsidian核心用法指南 —— 如何用反向链接组织安全知识

占位（待补建的笔记）

数据库安全
Web 安全基础
OWASP Top 10
2FA 与 TOTP 原理
KMS 密钥管理服务

%% 整理日期: 2026-05-05 · 来源: Downloads/网站密码加盐的原理.md，已嵌入领域库双向链接 %%

领域 on Albert Intelligence

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

全景一图流

🌱 Tier 0 · MVP / Demo（并发 < 50）

长什么样

Claude Code 默认推荐栈

🌿 Tier 1 · 小型上线（并发 50-200）

长什么样

比 Tier 0 多了什么

🌳 Tier 2 · 中型电商（并发 200-1000）

长什么样

模块拆解

🌲 Tier 3 · 大型电商（并发 1000+）

长什么样（电商六大域）

整体架构思路

前端

后端服务拆分（典型电商域）

数据层

消息与异步

流量层

可观测性（必须三件套）

基础设施

大促 / 高并发的关键技术

一张总览表（横向对比）

实战心法（用 Claude Code 时记住这 3 条）

决策导图：什么时候该升级？

核心关键词

写在最后

相关笔记

架构与部署实践

基础设施与运维

Obsidian 用法

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

主角登场

第一眼看不出门道，第二眼吓一跳

差异 1：5 个专用工具 vs 9 个万能工具

差异 2：思考 10 步 vs 思考 70 步

差异 3：单层记忆 vs 5 层记忆（业界最大短板）

差异 4：能力增长方式（这是最大的范式跃迁）

差异 5：上下文管理——反潮流的反向操作

实战对比：让 Agent 给笔记画一张架构图

O-easy 怎么做

GenericAgent 怎么做

代码量真相：3000 行 vs 3000 行，谁花得更聪明

GenericAgent 的真正创新（一句话每条）

给读者的两条启示

启示 1：选「原子工具 + 代码执行」，不要堆专用工具

启示 2：把能力增长留给「运行时」，不要全压在「开发时」

你该用哪个

结尾一句话

延伸阅读

网站密码加盐的原理

密码哈希与加盐：从原理到实战

一、为什么密码不能明文存？

二、第一层防御：哈希算法

三大特性

雪崩效应直观感受

哈希到底怎么算的？（以 MD5 为例）

三、单纯哈希也不够：彩虹表攻击

四、第二层防御：加盐（Salt）🧂

关键认知颠覆 ⚠️

五、第三层防御：慢哈希算法

六、第四层防御：Pepper（胡椒）🌶️

七、完整防御链总览

注册流程

登录流程

八、相关攻击术语

九、给开发者的实践清单

十、给用户的自保清单

一句话总结

🔗 本仓库相关笔记

强相关（同一架构链路）

中等相关（应用层接入）

知识体系入口

占位（待补建的笔记）