单人创始人用 AlloyDB 和 MCP 营全球招标平台

Lucius AI 是一家做全球招标情报的创业公司，覆盖五大洲市场，整个数据平台跑在 AlloyDB for PostgreSQL 上，运营者只有一个人。它把语义搜索迁移到 ScaNN 索引后，查询延迟从 1.14 秒降到 24 毫秒，提速 47 倍；同时通过 Model Context Protocol（MCP）让 AI 代理接管日常数据库运维。

平台目前收录超过 21 万条招标信息，覆盖英国、欧盟、美国、加拿大、澳大利亚、新西兰、印度、新加坡，以及世界银行在非洲和亚洲的捐赠方公告。系统每晚从 13 个公共采购源抓取数据，生产环境跑在两个 Cloud Run 区域：欧洲一个，澳大利亚一个——后者使用独立 AlloyDB 集群和客户管理加密密钥（CMEK），服务国防相关客户。Lucius AI 用 Gemini 分析招标文件，生成合规矩阵、投标建议和引用原始来源的草拟回复，替代中小供应商数天的人工文档审阅和昂贵的外部咨询。

架构上，Lucius AI 没有拆分散装关系库、向量库和日志存储，而是把所有核心数据放进 AlloyDB：关系型招标目录、文档元数据、审计日志和向量嵌入都在同一个数据库引擎里。这样做的直接收益是免去单独的向量库运维、统一备份策略、集中身份管理。认证完全依赖 Cloud IAM，服务用专用 Google Cloud 服务账号映射到数据库角色，按最小权限分配，应用环境里不存数据库密码。可靠性由 AlloyDB 原生托管，包括自动备份和按时间点恢复，不需要自建灾备流程。

几个关键数字值得注意。重建语义索引时，用 Gemini 嵌入模型在 10.6 分钟内嵌入了 115,820 条记录，API 花费约 3 美元；AlloyDB 的 auto embeddings 后续自动保持向量更新。检索重排直接在数据库内用 ai.rank 函数完成，平均延迟 77 毫秒，不需要单独的重排微服务。语义搜索最初用的是无索引向量比较，代表查询耗时 1.14 秒；迁移到 ScaNN 索引后降到 24 毫秒。有意思的是，这个索引迁移建议来自 AI 代理——它在一次自动化性能审计中检查了查询计划，然后准备了索引迁移方案。

运维自动化方面，Lucius AI 用开源的 MCP Toolbox for Databases，跑预构建的 alloydb-postgres 服务器。访问控制很严格：代理用专用 PostgreSQL 角色连接，只授予跨 schema 的 SELECT 和单张运维表的 UPDATE，DROP、DELETE、TRUNCATE 这类破坏性命令全部排除。在这个配置下，AI 代理承担四类日常操作：按需分析（用临时 SQL 生成留存队列、激活漏斗、按国家统计目录覆盖，省去手工仪表盘和分析管道）、性能优化（检查查询计划和索引，比如识别 ScaNN 索引策略）、事件取证（一次外部安全探测后，代理在几分钟内解析审计日志重建请求时间线，验证租户隔离未被破坏）、每日数据质量检查（每天早上评估全部 13 个采购源的数据水位和新鲜度）。

Lucius AI 的下一步有三件事：用 AlloyDB AI 的自动向量嵌入，在验证 ai.initialize_embeddings 后，每周维护任务用 ai.refresh_embeddings 更新向量；启用列式引擎和自动列式化，数据库在一天内识别并内存存储了四张表中 40 个高频查询列，加速报表查询；从自托管的 Toolbox 进程迁移到 Google Cloud 全托管的 Remote MCP Server for AlloyDB，省掉 MCP 服务器本身的托管维护。

这个案例的核心信号是：一个 solo founder 用托管数据库加 MCP 协议，把多区域、高并发的数据平台运维压缩到一个人能承受的范围。关键不是某个单一功能，而是把向量存储、索引、重排、审计、运维全部收敛到一个托管引擎里，再让 AI 代理在最小权限边界内处理日常操作。