“大模型时代 SaaS 可以没有了，但数据不能没有。”这句话点出了一个正在发生的结构变化：用户未必继续逐页操作传统 SaaS，智能体可以直接完成查询、分析和流程编排；但无论交互入口如何变化，业务记录、权限关系、知识资产和审计日志仍然必须被可靠地保存。
对开源基础软件来说，生存方向不是再复制一个带聊天框的 SaaS，而是成为任何模型、智能体和应用都绕不开，同时又能够被替换和迁移的数据基础设施。
被压缩的是应用界面，不是数据责任
传统 SaaS 通常把三层能力打包销售：交互界面、业务流程和数据存储。大模型与智能体开始压缩前两层。用户不再需要记住菜单路径，只需提出“汇总本周退款原因，并找出异常客户”，智能体便可以调用多个系统完成任务。
然而，智能体不能凭空生成可信的业务事实。它仍然需要读取订单、合同、工单和权限配置，并将执行结果写回系统。由此可以推导出几个更稳定的需求：
- 持久化：模型上下文会结束，业务数据不能随会话消失。
- 一致性：一次智能体任务可能横跨数据库、对象存储和消息系统。
- 权限：模型能够理解数据，不等于模型有权读取数据。
- 溯源：企业需要知道答案引用了哪些记录、由哪个模型生成、执行过哪些操作。
- 可迁移性：模型和 SaaS 供应商可以更换，数据不能被锁死在某个产品内部。
因此，开源数据库、对象存储、消息队列、检索引擎和身份系统的价值不会因为聊天界面兴起而消失。真正需要改变的是产品边界：它们不能只等待某个 SaaS 后端来调用，而要主动提供适合智能体消费的接口、元数据和治理能力。
开源项目可以争夺的四个位置
1. 成为可信的数据平面
数据平面负责保存原始事实，而不是保存模型临时整理出的答案。开源基础软件应继续强化事务、复制、备份、恢复和审计，因为这些能力很难由提示词补齐。
一个重要边界是：向量索引适合检索，不应自动取代业务主库。Embedding 可以重建，订单状态、资金流水和访问控制记录通常不能靠重新计算恢复。
2. 用开放协议连接智能体
未来的调用方不只是 Web 服务，也包括智能体、工作流引擎和模型工具。项目可以提供稳定的 HTTP API、SQL、事件订阅以及结构化工具描述，让调用者不必解析管理后台页面。
接口开放并不意味着允许模型直连生产数据库。更稳妥的方式是在数据层之前放置受控 API，实施行级权限、参数校验、速率限制和操作审批。
3. 把元数据升级为产品能力
仅仅存下数据还不够。智能体需要理解字段含义、数据负责人、更新时间、敏感等级和血缘关系。没有这些信息，模型很容易把 created_at 当成业务发生时间，或者将测试表误认为生产事实表。
开源项目可以把 schema、数据目录、血缘和策略接口组合起来。这样，模型不仅能“搜到数据”，还能够判断数据是否适合回答当前问题。
4. 保持可替换，反而建立信任
开源基础软件不应通过私有格式制造依赖。稳定的导入导出、标准协议和可验证备份，会降低企业采用门槛。项目的竞争力应来自运行可靠性、治理能力和生态兼容性，而不是让数据难以离开。
可以这样实践：先搭一个可迁移的数据底座
下面是一个简化的实践示例，不代表来源中给出了特定技术选型。它使用 PostgreSQL 保存结构化业务事实，使用兼容 S3 接口的 MinIO 保存文档和模型产物。运行前需要安装 Docker，并把示例密码替换为本地安全值。
创建 compose.yaml：
services:
postgres:
image: postgres:16
environment:
POSTGRES_DB: business
POSTGRES_USER: app
POSTGRES_PASSWORD: change-me-postgres
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app -d business"]
interval: 5s
timeout: 3s
retries: 10
minio:
image: minio/minio:latest
command: server /data --console-address ":9001"
environment:
MINIO_ROOT_USER: admin
MINIO_ROOT_PASSWORD: change-me-minio
ports:
- "9000:9000"
- "9001:9001"
volumes:
- object_data:/data
volumes:
postgres_data:
object_data:
启动服务并检查状态：
docker compose up -d
docker compose ps
随后创建一张带来源和审计字段的事实表：
docker compose exec -T postgres psql -U app -d business <<'SQL'
CREATE TABLE IF NOT EXISTS customer_events (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id text NOT NULL,
event_type text NOT NULL,
payload jsonb NOT NULL,
source_system text NOT NULL,
occurred_at timestamptz NOT NULL,
ingested_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO customer_events
(customer_id, event_type, payload, source_system, occurred_at)
VALUES
('c-1001', 'refund_requested', '{"amount": 199, "currency": "CNY"}', 'billing-api', now());
SELECT id, customer_id, event_type, source_system, occurred_at
FROM customer_events;
SQL
这个例子刻意保留了 source_system、occurred_at 和 ingested_at。智能体生成总结时，可以说明事实来自哪个系统，并区分业务发生时间与数据进入平台的时间。
还要验证数据确实能够离开当前运行环境：
docker compose exec -T postgres \
pg_dump -U app -d business --format=custom > business.dump
ls -lh business.dump
生产环境还需要补充加密、密钥管理、对象版本控制、异地备份、恢复演练和细粒度授权。尤其不要把数据库管理员凭据直接交给模型；智能体应通过权限受限、可审计的服务接口访问数据。
采用 AI 能力前，先检查数据主权
开源基础软件可以围绕下面这份清单调整路线：
- 数据能否通过标准格式完整导出，并在另一套环境恢复？
- 智能体的每次读取和写入是否关联用户身份与审计记录？
- 模型生成内容是否与原始业务事实分开保存？
- 向量索引损坏后，能否从原始数据重新构建？
- schema、字段语义、敏感级别和数据血缘是否可被机器读取？
- 更换模型、智能体框架或 SaaS 供应商时，核心数据是否无需迁移格式？
AI 可能让一部分 SaaS 页面和固定工作流失去价值，但它不会替企业承担数据完整性、安全性和合规责任。开源基础软件真正值得守住的，不是旧应用的外壳，而是可验证、可治理、可迁移的数据层。只要这一层仍由开放协议和透明实现承载，模型越强，可靠基础设施的重要性反而越清晰。