[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fyeNEfCvzgcezTh8Q5iD9iZdj3E-kYXuo2wHjBXgvhRI":3,"$fQrFXWUNV72q-e4ePGR91iKFsnV6qhcxo_FhMv2nzwuU":49},[4],{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":18,"sourceLabel":39,"sourceName":40,"sourceUrl":41,"status":42,"seoTitle":17,"seoDescription":17,"canonicalUrl":17,"isFeatured":43,"sno":44,"sortOrder":45,"publishedAt":46,"updatedAt":47,"createdAt":48},"2c8a2431-6be0-4189-8074-f332db448b3c","article","Sited 2.0 焕新上线：更现代、更安全、更优雅的静态网页部署平台","sited-update","30 秒把想法变成可访问的网站，无需配置、上传即发布。网页部署，从未如此简单。","## 引言\n\nSited 是一个现代化的静态网页托管与部署平台，致力于让任何人都能在 30 秒内完成网页发布——无需服务器、无需命令行、无需域名配置。无论是个人作品集、课程项目、产品落地页，还是临时活动页，Sited 都让你\"上传即上线\"。\n\n经过一段时间的打磨，我们正式发布 **Sited 2.0**。本次改版不是一次简单的界面翻新，而是一次从**前端架构、构建部署到认证安全**的系统性重构。\n\n在保留\"极简发布\"核心理念的同时，我们让平台更快、更稳、更安全，也对老用户的历史数据做到了**完全平滑兼容**。\n\n## Sited 是什么？\n\nSited 的名字源自 \"Site it!\"——\"把它变成网站\"。它的价值主张始终如一：\n\n- **极简发布**：拖拽 \u002F 选择 \u002F 粘贴代码 \u002F 上传 ZIP，四种方式任选，30 秒拿到可访问链接。\n- **多文件项目**：自动识别文件夹结构，保留 `index.html` 入口与资源引用关系。\n- **自定义与分享**：自定义 slug、自定义子域名、自定义图标（favicon）、标题与描述（利于 SEO 与社交分享）。\n- **企业级底座**：基于 Supabase（PostgreSQL + Storage）与 Cloudflare 边缘网络，数据隔离由行级安全策略（RLS）强制保障。\n\n这些能力在 2.0 中全部保留，并在此基础上做了架构级增强。\n\n## 核心升级点\n\n### 2.1 前端架构：从原生多页到 Vue 3 + Vite SPA\n\n旧版 Sited 完全使用原生 JavaScript（ES6 模块）开发，每个功能对应一个独立 HTML 页面（`index.html`、`upload.html`、`my-pages.html`…），首页 `index.html` 体量高达约 **92 KB** 且大量内联脚本，维护成本与首屏体积都偏高。\n\n2.0 重构为 **Vue 3 + Vite 组件化单页应用（SPA）**：\n\n- 视图拆分为 `HomeView` \u002F `UploadView` \u002F `PagesView`（项目管理）\u002F `PublicPageView`，逻辑收敛到 `src\u002Flib`（认证、页面、公开页渲染等模块）。\n- Vite 负责 SFC 编译、依赖预构建与代码分割，产物更小、缓存更友好、首屏更快。\n- 引入 `vue-router` 进行类型化路由，引入 `ogl` 实现 WebGL 极光（Aurora）背景，视觉质感显著提升。\n\n整体请求与架构流程如下：\n\n```mermaid\nflowchart TD\n  U[用户浏览器] -->|HTTPS 请求| CF[Cloudflare 边缘网络]\n  CF --> W[Cloudflare Worker\u003Cbr\u002F>_worker.js]\n  W -->|静态资源 \u002Findex.html \u002Fassets| A[Cloudflare Assets\u003Cbr\u002F>Vite 构建产物]\n  W -->|\u002Fapi\u002Fauth\u002F* · \u002Fapi\u002Fgithub\u002F*| AUTH[服务端鉴权逻辑\u003Cbr\u002F>bcrypt · Resend · GitHub OAuth]\n  W -->|\u002Fslug 公开页访问| PG[(Supabase · pages 表)]\n  PG -->|页面元数据 + 静态文件| W\n  W -->|HTMLRewriter 注入与重写| U\n  AUTH -->|service_role key 仅服务端使用| SB[(Supabase\u003Cbr\u002F>Storage + DB)]\n  A -.->|前端仅持有 VITE_SUPABASE_URL \u002F ANON_KEY| U\n```\n\n### 2.2 构建与部署：从 `sed` 占位符到 Vite + Cloudflare Assets\n\n旧版通过手写 `build.sh`（或 `npm run build`）用 `sed` 命令对 HTML \u002F JS 做 `__SUPABASE_URL__` 等占位符替换，过程易错、不可复现，且会把后端密钥写进构建产物。\n\n2.0 改为标准 **Vite 构建管线**：\n\n- `vite build` 产出 `dist\u002F`，由 `wrangler.toml` 的 `[assets]` 指向 `.\u002Fdist`，静态资源由 **Cloudflare Assets** 直接分发（带缓存、带哈希文件名）。\n- Worker 仅保留 `main = \"dist\u002F_worker.js\"`，并把 `\u002F` 与 `\u002F:slug` 回退到 Vue 入口；其余资源走 Assets。\n- 构建即 `npm run build && wrangler deploy`，可复现、可缓存、可观测（`observability` 已开启）。\n\n### 2.3 路由升级：从 `#slug` 哈希到 `\u002Fslug` 干净路径\n\n旧版公开地址形如 `https:\u002F\u002Fsited.cn\u002F#abc123`（哈希路由）。2.0 改为**路径路由**：\n\n- slug 为 `123` 时，公开地址即 `https:\u002F\u002Fsited.cn\u002F123`——更优雅、更易分享、更利于 SEO，也更像\"一个真实站点\"。\n- 多文件项目支持路径式访问 `\u002F{slug}\u002F`，由 Worker 在边缘回源并注入资源重写。\n- 路由表（`src\u002Frouter.js`）清晰定义 `\u002F`、`\u002Fupload`、`\u002Fproject`（原\"我的页面\"升级为\"项目\"管理）、`\u002F:slug`。\n\n### 2.4 认证与安全：代际升级（本次改版的核心）\n\n这是 2.0 最本质的变化。旧版的认证存在两处结构性隐患：\n\n1. **密码哈希在浏览器端完成**（使用 `bcryptjs`），哈希逻辑暴露在客户端。\n2. 旧版 `wrangler.toml` 把 `SUPABASE_SERVICE_ROLE_KEY`、对象存储 `STORAGE_SECRET_KEY` 等**以明文写在 `[vars]` 配置中**，密钥随部署产物扩散，风险极高。\n\n2.0 将**所有敏感逻辑下沉到 Cloudflare Worker 服务端**（`public\u002F_worker.js`）：\n\n- **密码只在浏览器输入，仅发送至 Worker**；由 Worker 用 `bcrypt`（cost = 12）在服务端哈希后写入 `users` 表。前端永远拿不到密码哈希。\n- **Resend 发信 key、Supabase service-role key、GitHub secret、各类 `AUTH_*_SECRET` 全部作为 Worker secret**（`wrangler secret put`），永不进入前端代码、构建产物或仓库。前端仅持有 `VITE_SUPABASE_URL` 与 `VITE_SUPABASE_ANON_KEY`。\n- 新增**邮箱验证码注册**：6 位验证码由 Worker 生成、`SHA-256(AUTH_CODE_SECRET:code)` 哈希入库、经 Resend 发送；**10 分钟有效期、最多尝试 5 次、同邮箱 60 秒冷却、记录请求 IP**，从注册源头遏制滥用（旧版仅靠\"单 IP 限 3 账号\"）。\n- 新增 **GitHub OAuth 登录**：`state` Cookie 防 CSRF；授权码仅在 Worker 服务端交换，`access token` 绝不写入浏览器、数据库或日志；若 GitHub 已验证邮箱与现有 Sited 账号一致，自动关联并登录。\n- 会话从\"localStorage 明文保存登录态\"升级为 **HMAC 签名、`HttpOnly` + `Secure` + `SameSite=Lax` 的 `__Host-sited-session` Cookie**（7 天有效期）。前端只保存脱敏后的 `publicUser`（id \u002F email \u002F display_name）。\n\n新版认证与授权流程：\n\n```mermaid\nflowchart TD\n  subgraph 注册\n    R1[填写邮箱 \u002F 密码] --> R2[Worker 生成 6 位验证码\u003Cbr\u002F>SHA-256 哈希入库]\n    R2 --> R3[Resend 发送验证码邮件]\n    R3 --> R4[用户回填验证码]\n    R4 --> R5{验证码校验\u003Cbr\u002F>10min \u002F 5 次 \u002F 60s 冷却}\n    R5 -->|通过| R6[Worker bcrypt cost12 哈希\u003Cbr\u002F>写入 users 表]\n    R5 -->|失败| R4\n    R6 --> R7[签发 HMAC 会话 Cookie]\n  end\n  subgraph 登录\n    L1[邮箱 + 密码] --> L2[Worker bcrypt.compare]\n    L2 -->|成功| L3[签发 __Host-sited-session]\n  end\n  subgraph GitHub 登录\n    G1[跳转 GitHub 授权] --> G2[Worker 服务端交换 code]\n    G2 --> G3[读取邮箱 \u002F 资料]\n    G3 --> G4[关联或新建账号]\n    G4 --> L3\n  end\n  L3 --> S[前端仅保存 publicUser\u003Cbr\u002F>无密码 \u002F 无密钥]\n```\n\n### 2.5 公开页面渲染：边缘 HTMLRewriter 管线\n\n旧版的资源关联依赖**浏览器端 Blob URL 重写**，复杂项目下偶有资源加载异常。\n\n2.0 在 Worker 边缘用 **`HTMLRewriter`** 统一处理公开页：\n\n- 自动注入 `\u003Cbase href=\"\u002F{slug}\u002F\">`，并将页面内 `a[href]`、`link[href]`、`script[src]`、`img[src]`、`source`、`video`、`audio`、`srcset`、`style` 中的 `url()` 全部重写为带 slug 前缀的路径，确保多文件项目的图片 \u002F CSS \u002F JS 正确加载。\n- 注入可选水印（\"Powered by Sited\"）、微信底部安全区适配、页面内锚点平滑滚动。\n- 对页面元数据做 **5 分钟内存缓存**，降低 Supabase 查询压力。\n\n页面发布与访问流程：\n\n```mermaid\nflowchart TD\n  Req[浏览器请求 \u002Fslug 或 \u002Fslug\u002F] --> W[Worker 路由]\n  W -->|单文件项目| Q1[查询 pages 表\u003Cbr\u002F>取 root_html_path \u002F filename]\n  Q1 --> F1[读取 legacy HTML 内容]\n  F1 --> R1[前端 prepareHostedHtml\u003Cbr\u002F>注入 base \u002F 重写资源]\n  R1 --> D1[iframe srcdoc 渲染]\n  W -->|多文件项目| Q2[查询 pages + assets_map]\n  Q2 --> F2[回源 static-files 存储桶]\n  F2 --> R2[HTMLRewriter 注入 base\u003Cbr\u002F>重写 a\u002Flink\u002Fscript\u002Fimg...]\n  R2 --> D2[iframe \u002Fsrc 渲染]\n  R1 --> WM[可选注入 Powered by Sited 水印]\n  R2 --> WM\n```\n\n### 2.6 数据向后兼容：老用户零成本迁移\n\n这是很多企业级重构最容易翻车的地方，Sited 2.0 做了重点保障：\n\n- 保留原有 `users`、`pages` 表字段与 `static-files` Storage 桶路径。\n- **旧的单文件 JSON 部署内容、旧的多文件记录，新的公开页都可继续读取与渲染**。\n- 老用户无需重新上传，历史页面与账号数据完整保留。\n\n```mermaid\nflowchart LR\n  OLD[(旧版数据\u003Cbr\u002F>users \u002F pages \u002F static-files)] -->|字段与桶路径保持不变| NEW[Sited 2.0 公开页]\n  NEW -->|单文件 JSON 内容| READ1[直接读取渲染]\n  NEW -->|多文件记录 + assets_map| READ2[边缘回源重写渲染]\n```\n\n## 功能特性总览\n\n| 能力 | 说明 |\n| --- | --- |\n| 多方式上传 | 文件选择、拖拽文件夹、ZIP 解压、代码粘贴（实时预览）四种输入，覆盖从新手到开发者的全部场景 |\n| 自定义链接 | 自定义易记 slug；登录用户可设自定义子域名 `*.sited.cn` |\n| 项目管理（原\"我的页面\"） | 统一\"项目\"视图，查看 \u002F 复制链接 \u002F 编辑 \u002F 删除自己的全部页面 |\n| 多文件项目 | 自动识别目录结构，主 HTML 入口 + `\u003Cbase>` 资源重写，复杂站点也能正确托管 |\n| 实时预览 | 代码模式下所见即所得，右侧 iframe 即时渲染 |\n| 图标与品牌 | 自定义 favicon \u002F Apple Touch Icon，浏览器标签与收藏夹视觉识别 |\n| 水印控制 | 可选 \"Powered by Sited\" 水印，发布或编辑时可开关 |\n| 暗色模式 | 跟随系统或手动切换，偏好本地保存 |\n| 响应式 | 移动优先，手机 \u002F 平板 \u002F 桌面一致体验 |\n| 空间 \u002F 子域名 | `space` 表驱动的文件空间托管，支持自定义子域名直出站点 |\n| 页面图谱 | 新增 `page_graph`（JSONB），记录多 HTML 页面项目内部的跳转关系 |\n\n## 新增能力\n\n- **邮箱验证码注册**：从源头防恶意注册，免除\"单 IP 限 3 账号\"的粗放限制。\n- **GitHub OAuth 登录**：开发者一键登录 \u002F 关联，授权码仅在服务端交换。\n- **服务端认证 Worker**：bcrypt 服务端哈希、HMAC 会话 Cookie、Resend 发信、GitHub 回调，全部收敛到边缘。\n- **WebGL 极光背景（ogl）**：首页与关键界面的现代视觉质感。\n- **现代设计系统**：重构的 `SITED \u002F ACCESS` 登录模态、底部导航（`bottom-navigation`）、统一的 CSS 变量与组件体系。\n- **路径式公开地址**：`\u002Fslug` 取代 `#slug`，分享与传播更体面。\n\n## 旧版 vs 新版 对比一览\n\n| 维度 | 旧版（v1.0） | 新版（v2.0） |\n| --- | --- | --- |\n| 前端架构 | 原生 JS 多页（首页约 92 KB 内联） | Vue 3 + Vite 组件化 SPA |\n| 构建方式 | `build.sh` + `sed` 占位符替换 | Vite 打包 + Cloudflare Assets 分发 |\n| 路由形式 | 哈希路由 `#slug` | 路径路由 `\u002Fslug` |\n| 密码哈希 | 浏览器端 `bcryptjs` | Worker 服务端 `bcrypt`（cost 12） |\n| 密钥管理 | service role \u002F 存储密钥明文写入 `wrangler.toml [vars]` | 全部为 Worker secret，前端仅持 anon key |\n| 注册防滥用 | 单 IP 限 3 账号 | 邮箱验证码 + 尝试次数 \u002F 冷却 \u002F IP 记录 |\n| 第三方登录 | 无 | GitHub OAuth（state 防 CSRF） |\n| 会话机制 | localStorage 明文 | HMAC 签名 `HttpOnly` Cookie |\n| 公开页渲染 | 浏览器端 Blob URL 重写 | 边缘 `HTMLRewriter` 注入与重写 |\n| 数据兼容 | — | 兼容旧单文件 \u002F 多文件记录 |\n| 文档系统 | docs 路由 \u002F 文档 Wiki | 未迁移进新构建，聚焦核心托管 |\n| 视觉质感 | 基础样式 | WebGL 极光背景 + 现代设计系统 |\n\n## 升级对老用户意味着什么\n\n- **无需任何操作**：你的账号、页面、历史部署在 2.0 中照常可访问，链接形式从 `#slug` 平滑过渡到 `\u002Fslug`，旧链接逻辑仍被兼容读取。\n- **更安全**：即便曾经使用旧版，你的密码在新架构下也只会在服务端被哈希与校验；注册新账号将获得邮箱验证码保护。\n- **更顺手**：项目管理升级为\"项目\"视图，登录支持 GitHub 一键关联，界面与分享体验全面现代化。\n- **更聚焦**：我们暂时将文档（docs）系统移出核心构建，集中资源把\"静态网页托管 \u002F 部署\"这一主航道做到极致。\n\n## 技术栈小结\n\n**前端**：Vue 3.5 · vue-router 4 · Vite 7 · ogl（WebGL 背景）\n**后端 \u002F 边缘**：Cloudflare Workers（`_worker.js`）+ Cloudflare Assets\n**数据 \u002F 存储**：Supabase（PostgreSQL + Storage，RLS 数据隔离）\n**认证**：服务端 bcrypt（cost 12）· Resend 邮箱验证码 · GitHub OAuth · HMAC 会话 Cookie\n**依赖**：`@supabase\u002Fsupabase-js` · `bcryptjs` · `jszip` · `vue` · `vue-router` · `ogl`\n\n## 结语\n\nSited 2.0 是一次从内核到边界的重构：用 Vue 3 + Vite 让产品更好维护、更快；用路径路由与边缘渲染让发布更体面；用服务端认证与密钥隔离让平台更值得托付。更重要的是，它做到了**对老用户历史数据的完全兼容**——你过去发布的每一个页面，今天依然在线。\n\n把想法变成网站，现在比以往任何时候都更简单、更安全。\n\n**Have an idea? —— Site it.**\n","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-20\u002F291cb55f-233d-4d34-b9e8-70a64d2d3564.jpg",[],[],"Srces工作室","https:\u002F\u002Fsrces.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",null,[19,23,27,31,35],{"id":20,"name":21,"slug":22},"82f427f8-6275-4cbb-bcac-cf1948488006","网页应用","web-app",{"id":24,"name":25,"slug":26},"a202d639-99a6-488a-a712-4d4c6ffd7e15","开发","dev",{"id":28,"name":29,"slug":30},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":36,"name":37,"slug":38},"bfb9750c-40cf-487e-81ad-dbac5f22ffcd","SaaS","saas","前往","sited.cn","https:\u002F\u002Fsited.cn","published",false,5,0,"2026-07-10T00:00:00.000Z","2026-07-20T13:04:14.112Z","2026-07-20T11:57:43.637Z",[50,74,94],{"id":51,"type":6,"title":52,"slug":53,"summary":54,"body":55,"coverUrl":56,"productScreenshots":57,"productLinks":58,"authorName":59,"authorUrl":60,"authorSubject":16,"category":61,"tags":66,"sourceLabel":17,"sourceName":17,"sourceUrl":17,"status":42,"seoTitle":17,"seoDescription":17,"canonicalUrl":17,"isFeatured":43,"sno":70,"sortOrder":45,"publishedAt":71,"updatedAt":72,"createdAt":73},"544fc658-c911-4de6-93b0-d2520087119a","MCP：AI 的「USB-C」时刻","mcp-ai-usb-c-moment","以前每个 AI 应用都要为 GitHub、数据库、日历各写一套私有连接器，这是 M×N 的集成噩梦，直到 MCP 的出现","如果你用过笔记本电脑，一定熟悉那种「每个设备一根专属线」的烦躁：鼠标一个接口、打印机另一个、硬盘又一个。2025 年之前的 AI 应用，几乎就是这种状态——想让一个助手同时读你的代码仓库、查数据库、发日历邀请，开发团队得为每一个系统写一套私有「连接器」，又脆又难维护。\n\n## 背景：每个 Agent 都曾是孤岛\n\n大模型本身只会「说话」，它要真正干活，得去调工具、读数据。在 MCP（Model Context Protocol，模型上下文协议）出现之前，这套对接是组合爆炸：假设市面上有 M 个 AI 客户端、N 个工具，开发者就要写 M×N 套集成。一个代码助手要读 Git、查 Jira、搜文档，就得维护三条互不相通的管线。\n\n更糟的是，这些连接器大多只服务某一个产品，换个助手就得重写。结果就是：每个 Agent 都困在自己的小岛上，能力被锁死在少数几个硬编码的集成里。\n\n## MCP 是什么：AI 世界的「USB-C」\n\n2024 年底，Anthropic 发布了 MCP。它的目标很朴素：给「AI 连工具」定义一个统一接口，就像 USB-C 给「设备连外设」定义统一接口一样。\n\n打个比方——如果大模型是大脑，那 MCP 就是手。大脑再聪明，没有手也打不开文件、点不了按钮、查不了数据库。MCP 让任意符合规范的「大脑」（Claude、ChatGPT、Gemini、Cursor、VS Code Copilot）都能使用任意符合规范的「手」（一个封装好的工具服务），而且不用为每个组合单独适配。\n\n2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会，OpenAI、Google、Microsoft 作为联合发起人。到 2026 年，它的 SDK 月下载量超过 9700 万次，ChatGPT、Claude、Gemini 都支持同一个协议——某种意义上，这场标准之战已经赢了。\n\n## 它是怎么运作的：三层结构\n\nMCP 把「连工具」拆成三个角色，理解这三层就理解了全部：\n\n- **Host（宿主）**：你直接使用的应用，比如 Claude 桌面端、VS Code、一个自定义聊天机器人。\n- **Client（客户端）**：住在 Host 内部、专门负责管理 MCP 连接的小组件。\n- **Server（服务端）**：一个轻量程序，把某个能力「暴露」出来，比如一个 GitHub 服务、一个数据库查询服务。\n\n每个 Server 通过三种「原语」提供能力：`Tools`（AI 可以调用的可执行函数，如 `create_issue`）、`Resources`（AI 可以读取的数据，如文件内容、数据库表结构）、`Prompts`（可复用的提示词模板）。它们底层用 **JSON-RPC**（一种简单的远程调用格式）通信，远程服务走 HTTP 传输，本地服务走标准输入输出。\n\n整个调用流程是这样的：\n\n```mermaid\nflowchart LR\n    U[用户] --> H[Host 应用\u003Cbr\u002F>Claude \u002F Cursor \u002F VS Code]\n    H --> C[MCP Client\u003Cbr\u002F>连接管理器]\n    C -->|JSON-RPC| S1[MCP Server: GitHub]\n    C -->|JSON-RPC| S2[MCP Server: 数据库]\n    C -->|JSON-RPC| S3[MCP Server: 天气 API]\n    S1 --> D1[(代码仓库)]\n    S2 --> D2[(业务数据)]\n    S3 --> D3[(外部 API)]\n```\n\n关键点在于：Host 只要实现一次 Client 协议，Server 只要实现一次 Server 协议，从此任意 Host 能连任意 Server。集成成本从 M×N 降到了 M+N。\n\n## 一个最小可运行的例子\n\n下面用官方 Python SDK 写一个「天气查询」MCP 服务，只暴露一个工具：\n\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"weather\")  # 服务名叫 weather\n\n@mcp.tool()\ndef get_weather(city: str) -> str:\n    \"\"\"查询某城市的天气（示例返回静态数据）\"\"\"\n    return f\"{city} 今天晴，25°C。\"\n\nif __name__ == \"__main__\":\n    mcp.run()  # 默认以 stdio 方式启动，等待 Host 来连\n```\n\n运行前只需 `pip install mcp`，然后用任意支持 MCP 的客户端（Claude 桌面端、Cursor 等）配置这个服务路径即可。AI 在对话里说「查下北京天气」，客户端就会通过 MCP 调用 `get_weather(\"北京\")`，拿到结果再组织成自然语言回答你。注意：这只是最小骨架，真实服务里要把静态返回值换成真正的天气 API 调用。\n\n## 取舍与边界：它解决了什么，没解决什么\n\nMCP 解决的是「连接标准」问题，但它不是银弹：\n\n- **它让集成变简单，但不保证工具安全。** 一个 MCP Server 可以是任何人所写，工具描述会直接喂给模型。如果 Server 既能读私有数据、又能访问不可信内容、还能对外发消息，就构成了安全风险（业界称之为「致命三件套」）。企业通常会加一层 **Gateway（网关）** 来做鉴权和审计——Uber、Amazon 都用了这种「网关 + 注册表」的控制平面。\n- **上下文膨胀是个真问题。** 接的 Server 一多，工具定义会塞满模型的上下文窗口。2026 年的常见解法是「按需加载」：只把当前 Agent 真正需要的工具暴露出来，而不是一次全塞进去。\n- **它定义「怎么连」，不定义「连上去说什么」。** 多 Agent 之间的协作语义，由另一套协议 A2A（Agent-to-Agent）负责——MCP 接工具，A2A 连同伴。\n\n## Tips\n\n- 下次看到「AI 连不上我的系统」，先问：有没有现成的 MCP Server？多数数据库、SaaS、开发工具都已有官方或社区实现。\n- 想自己动手：用官方 SDK（Python\u002FTypeScript 等）把内部的一个 API 包成 MCP Server，比写一套专属集成快得多。\n- 评估风险时记住三件事：私有数据、不可信输入、对外通信，三者叠加要格外小心，尽量放进网关管控。\n- 分清两层协议：接工具看 MCP，多 Agent 协作看 A2A，别混为一谈。\n- 把 MCP 当「基础设施」而非「功能」：它赢是因为无聊、通用、可复用，这正是它值得长期投入的原因。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-19\u002Fc3c06d99-a0ac-40ac-a283-7e77aabb4c4c.jpg",[],[],"Foundit AI","https:\u002F\u002Ffoundit.cn\u002Fabout",{"id":62,"name":63,"slug":64,"description":65},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[67,68,69],{"id":24,"name":25,"slug":26},{"id":28,"name":29,"slug":30},{"id":32,"name":33,"slug":34},46,"2026-07-20T00:00:00.000Z","2026-07-19T17:39:20.060Z","2026-07-19T16:13:40.316Z",{"id":75,"type":6,"title":76,"slug":77,"summary":78,"body":79,"coverUrl":80,"productScreenshots":81,"productLinks":82,"authorName":59,"authorUrl":83,"authorSubject":16,"category":84,"tags":85,"sourceLabel":89,"sourceName":17,"sourceUrl":17,"status":42,"seoTitle":17,"seoDescription":17,"canonicalUrl":17,"isFeatured":43,"sno":90,"sortOrder":45,"publishedAt":91,"updatedAt":92,"createdAt":93},"74dedc2e-6a66-4481-aef2-5cffc3ba338d","嵌入模型（Embeddings）：向量数据库能搜「意思」，全靠它","embedding-models-vector-search","向量库怎么懂「意思相近」？靠嵌入模型把文字变成向量。本文讲清它的工作原理、余弦相似度检索，给出 sentence-transformers 最小示例，以及模型选型、维度统一、中英差异等取舍。","你让向量库「找意思相近的句子」，它怎么懂「意思」？靠嵌入模型（Embeddings）：把文字变成一串数字（向量），意思越近，数字越近。它是语义搜索和 RAG 真正的地基——没有它，模型只能靠关键词硬匹配。\n\n## 为什么需要嵌入\n\n传统搜索靠关键词匹配，搜「怎么给猫降温」找不到「猫咪中暑怎么办」。嵌入把文本映射到向量空间，把相近语义聚在一起，才能按「意思」而不是「字面」检索。\n\n## 它是怎么工作的\n\n嵌入模型（如 BGE、OpenAI text-embedding）是个神经网络，把变长文本压成定长向量（常见 768 或 1536 维）。训练目标是「语义相近的文本，向量距离小」。检索时把 query 也编码，算余弦相似度，找最近的那些。\n\n```mermaid\nflowchart LR\n    A[文本] --> B[嵌入模型]\n    B --> C[向量]\n    C --> D[存入向量库]\n    E[查询] --> B\n    D --> F[相似度检索]\n    B --> F\n    F --> G[返回相近文本]\n```\n\n## 取舍与边界\n\n- **模型要选对**：通用嵌入未必适合你的领域（法律、医疗），必要时用领域数据微调。\n- **维度与成本权衡**：维度越高通常越准，但存储、检索都更贵更慢，按场景取舍。\n- **中英文差异**：混用中英文语料要选多语言模型，否则跨语言检索会崩。\n- **维度必须统一**：检索和入库一定要用同一个模型、同一维度，否则向量不可比，检索全乱。\n\n## Tips\n\n- 任何「按意思搜」的需求，第一步就是选好嵌入模型。\n- 中文场景优先试 BGE、m3e 等多语言\u002F中文模型，别直接套英文默认。\n- 入库和检索用同一模型同一维度，这是铁律。\n- 领域强相关的语料，用该领域样本微调嵌入，召回率提升明显。\n- 嵌入质量直接决定 RAG 上限，值得在它上面多花时间。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-22\u002Facd40af8-276a-48bc-8d62-dcd52c124590.jpg",[],[],"https:\u002F\u002Ffoundit.cn",{"id":62,"name":63,"slug":64,"description":65},[86,87,88],{"id":32,"name":33,"slug":34},{"id":28,"name":29,"slug":30},{"id":24,"name":25,"slug":26},"资料来源",68,"2026-07-22T00:00:00.000Z","2026-07-23T01:16:32.032Z","2026-07-20T10:23:37.966Z",{"id":95,"type":6,"title":96,"slug":97,"summary":98,"body":99,"coverUrl":100,"productScreenshots":101,"productLinks":102,"authorName":59,"authorUrl":83,"authorSubject":16,"category":103,"tags":104,"sourceLabel":89,"sourceName":17,"sourceUrl":17,"status":42,"seoTitle":17,"seoDescription":17,"canonicalUrl":17,"isFeatured":43,"sno":108,"sortOrder":45,"publishedAt":91,"updatedAt":109,"createdAt":110},"8f7ce6a9-492b-4b45-afa4-d16905cc3b65","边缘函数：把代码跑在全球服务器","edge-functions","不想租服务器管运维？边缘函数把代码自动部署到全球几百个节点，毫秒级就近执行。","传统后端要你租服务器、装环境、管扩容、防宕机，一件小事背后是一整套运维。边缘函数（Edge Functions）把这件事彻底简化：你只写一段代码，平台把它自动部署到全球几百个节点，用户请求落到离他最近的那个，毫秒级响应，没有常驻服务器，也不用你管。Cloudflare Workers、Deno Deploy 是其中的代表。\n\n## 背景：为什么需要「边缘」\n\n用户在上海，服务器在美东，一次请求要跨半个地球来回，延迟动辄几百毫秒。把计算挪到离用户近的地方，是提速最直接的一招。边缘函数的思路是：不让你管服务器，而是把函数代码分发到全球边缘节点，在每个节点上按需、瞬时执行。\n\n## 它长什么样\n\n以 Cloudflare Workers 为例，一个函数就是一个 `fetch` 事件处理器，部署后立刻获得一个全球 URL：\n\n```javascript\nexport default {\n  async fetch(request) {\n    const url = new URL(request.url);\n    if (url.pathname === \"\u002Fhello\") {\n      return new Response(\"来自边缘的问候\");\n    }\n    return new Response(\"Not found\", { status: 404 });\n  }\n}\n```\n\n你 `deploy` 一下，这段代码就跑在了全球几百个数据中心，谁访问谁就近执行。\n\n## 一次请求怎么走\n\n```mermaid\nflowchart LR\n    A[用户 上海] --> B[最近边缘节点]\n    C[用户 纽约] --> D[最近边缘节点]\n    B --> E[你的函数代码 就近执行]\n    D --> E\n    E --> F[返回结果 毫秒级]\n```\n\n## 取舍与边界\n\n- **冷启动极快**：边缘函数通常是轻量隔离（如 V8 Isolate），启动以毫秒计，远快于传统容器。\n- **运行时受限**：为了快和轻，边缘环境不是完整 Node.js，部分 API（如某些文件系统、原生模块）不可用，写代码要适配。\n- **有状态数据要外置**：函数本身无状态、可能随时在哪个节点跑，数据库\u002F缓存要走外部服务（如边缘 KV）。\n- **适合「薄」逻辑**：鉴权、改写、A\u002FB、转发、轻计算最合适；重 CPU 或长任务仍交给中心化服务。\n\n## Tips\n\n- 入门只要写一个 `fetch` 处理器，二十行代码就能上线一个全球接口。\n- 适合做鉴权中间件、请求改写、A\u002FB 分流、轻量 API 网关。\n- 有状态数据（会话、计数）用平台提供的边缘 KV，别指望函数本地存。\n- 注意运行时差异：别用边缘不支持的 Node API，部署前本地跑一遍。\n- 重活（大模型推理、大计算）留给中心服务，边缘只做「快而薄」的那一层。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-22\u002F4e66dabf-7f69-4ba0-b66d-12774273f763.jpg",[],[],{"id":62,"name":63,"slug":64,"description":65},[105,106,107],{"id":28,"name":29,"slug":30},{"id":24,"name":25,"slug":26},{"id":32,"name":33,"slug":34},69,"2026-07-22T06:38:22.660Z","2026-07-20T01:11:48.654Z"]