北京
一个人，五个大洲，21万条招标信息。Davor Jerković 是 Lucius AI 的创始人，这家公司做的是招标情报，市场覆盖英国、欧盟、美国、加拿大、澳大利亚、新西兰、印度、新加坡，还包括世界银行在非洲和亚洲资助的采购公告。整个数据平台，只有他一个操作者。
平台每晚从十三个公共采购源抓取数据，目录里躺着超过 21 万条招标信息，其中数万条正在开放投标。生产环境跑在两个区域：欧洲，以及澳大利亚——后者部署在独立的 AlloyDB 集群上，用客户自管加密密钥（CMEK），服务的是国防相关客户。
没有专职数据工程团队，也没有数据库管理员。这套系统能转起来，靠的是两件事：把核心数据全部收进 AlloyDB for PostgreSQL，以及让一个 AI 智能体通过 Model Context Protocol（MCP）去执行数据库操作。
不建三套库，只留一个引擎
很多团队的做法是关系库、向量库、日志存储各来一套。Lucius AI 没这么干。招标目录、文档元数据、审计日志、向量嵌入，全部住在同一个数据库引擎里。
向量嵌入和关系行放在一起，省掉了单独维护向量存储的麻烦，备份计划统一，身份管理也集中。认证严格走 Cloud IAM，服务用专门的 Google Cloud 服务账号连接，映射到按访问需求划分的数据库角色，应用环境里不存数据库密码。可靠性交给 AlloyDB 原生处理，自动备份加点对点恢复，不用自己写灾难恢复流程。
生产环境里，这套合并架构支撑着这些数字：
- 目录中超过 21 万条招标信息，嵌入向量直接存在旁边
- 用 Gemini 嵌入模型重建语义索引，115,820 条记录耗时 10.6 分钟，API 花费约 3 美元；AlloyDB 的自动嵌入功能现在负责保持这些向量最新
- 检索重排直接在数据库内用 ai.rank 函数执行，平均延迟 77 毫秒，不需要单独的重排微服务
从 1.14 秒到 24 毫秒
语义搜索最初靠未索引的向量比较，一个代表性查询要跑 1.14 秒。把这个负载迁到 AlloyDB 的 ScaNN 索引之后，查询延迟降到 24 毫秒，提升 47 倍。
有意思的是索引建议的来源。它出自 AI 智能体的一次自动化性能审计——智能体先对查询计划做了基准测试，然后才准备索引迁移。
MCP 这条线负责的是日常运维。Lucius AI 配置了开源 MCP Toolbox for Databases，用的是预置的 alloydb-postgres 服务器。权限卡得很死：智能体用一个专门的 PostgreSQL 角色连接，整个 schema 只有 SELECT 权限，UPDATE 只开放给一张运营表。DROP、DELETE、TRUNCATE 这类破坏性命令直接不给，智能体的动作被限制在授权边界内。
在这个配置下，AI 智能体承担四类常规数据库操作：
- 按需分析：通过临时 SQL 查询汇总留存队列、激活漏斗、按国家划分的目录覆盖情况，不用再搭和维护手动仪表盘或复杂分析管道
- 性能优化：检查查询计划、分析索引，比如识别出 ScaNN 索引策略
- 事故取证：面对一次外部安全探测，智能体解析审计日志，几分钟内重建请求时间线，确认租户隔离完好
- 数据质量自动检查：每天早上评估全部十三个采购源的数据摄入水位和新鲜度
对于想采用这套架构的团队，渐进式权限结构提供了清晰的护栏：从只读权限起步，再逐步放开。
一个人管五个大洲的招标平台，听起来像不可能完成的任务。但把系统收敛到一个数据库引擎，再把日常运维交给一个权限受限的智能体，这件事就变成了可执行的工程问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
