一、Agent 的"基础设施时刻"到了#
2024-2025 年，编程 Agent 爆发了。
Claude Code 能直接帮你写代码、跑测试、修 Bug。Cursor 把 AI 编程助手做成了 IDE 的原生体验。Devin 号称是第一个 AI 软件工程师。这些工具已经开始改变程序员的日常工作方式。
但当你仔细观察这些 Agent 的工作方式时，会发现一些令人惊讶的事情。
它们的底层操作极其"原始"——Claude Code 直接读写文件系统，裸跑 bash 命令，没有沙箱，没有权限控制，没有状态管理。它能用 rm -rf / 删掉你的整个硬盘，唯一阻止它的是模型本身的"道德约束"。
这让我想起了 1980 年代的 DOS。
DOS 也能用。你可以在上面写程序、编辑文档、玩游戏。但它缺乏现代操作系统的一切：没有内存保护，没有多任务，没有标准化的设备接口。每个应用都直接操作硬件，程序员要自己处理所有底层细节。
我们花了 30 年，才从 DOS 演化到 Linux。从"能用"到"好用"，从"黑客玩具"到"全球基础设施"。
现在，AI Agent 正站在同一个起点。
这篇文章想要回答几个问题：
- Agent 从 demo 走向生产，中间缺了什么？
- 这个"缺失的中间层"长什么样？
- 谁会成为 AI 时代的 Linux？
- PostgreSQL 在这个新世界中扮演什么角色？
我的核心论点是：用操作系统的演化历史来理解 Agent 基础设施的未来。这个类比不仅能帮我们理解现状，还能预测接下来 2-3 年最关键的技术方向——以及最大的商业机会。
二、核心类比：Agent OS 的架构映射#
2.1 硬件层：LLM 是新 CPU，Context 是新内存#
让我们从最基础的类比开始。
在传统计算机中，CPU 是算力的来源，RAM 是临时存储，磁盘是持久存储。这三者的配合构成了冯·诺依曼架构的核心。
在 Agent 世界中，我们可以找到精确的对应：
| 传统计算机 | Agent 世界 | 关键特征 |
|---|---|---|
| CPU | LLM 推理引擎 | 算力、智能、但无状态 |
| RAM | Context Window | 昂贵、有限、易失 |
| 磁盘 | 外部存储（DB/文件） | 廉价、持久、需要检索 |
| GPU | GPU 集群 | 加速推理 |
这个类比揭示了一个关键洞察：Context Window 就像 1980 年代的 640KB RAM。
1981 年，IBM PC 的设计者们认为 640KB 内存"应该够用了"。这个判断成为了计算机历史上最著名的错误预言之一。今天，当我们说 128K tokens 的 Context Window 很大时，我们正在犯同样的错误。
128K tokens 看起来很多，但：
- 一个中型代码仓库就能轻松填满
- 一次复杂的多轮对话就能耗尽
- 企业文档、知识库动辄几百 MB
更关键的是 LLM 的无状态特性。每次推理完成后，所有状态都消失了。想象一下，如果你的电脑每次执行完一个程序就清空所有内存——这就是当前 Agent 面临的现实。
这意味着：所有状态管理都必须外部化。这正是我们需要"操作系统"的原因。
2.2 内核层：Agent Runtime 是新操作系统#
如果 LLM 是 CPU，Context 是 RAM，那么我们需要什么？
我们需要一个操作系统——一个管理资源、提供抽象、协调各组件的中间层。
让我尝试画出这个"Agent OS"的完整架构：
┌─────────────────────────────────────────────────────────────────┐
│ 应用层 (Applications) │
│ Claude Code, Cursor, Devin, 各种垂直 Agent │
├─────────────────────────────────────────────────────────────────┤
│ Agent OS (内核层) │
│ ┌───────────┬───────────┬───────────┬───────────┬───────────┐ │
│ │ 进程管理 │ 内存管理 │ 文件系统 │ I/O管理 │ 安全 │ │
│ │ LangGraph │ Context │ PostgreSQL│ MCP │ Sandbox │ │
│ │ Temporal │Engineering│ VectorDB │ Tool Call │ 权限控制 │ │
│ └───────────┴───────────┴───────────┴───────────┴───────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 硬件抽象层 (HAL) │
│ 模型路由、负载均衡、多模型调度 │
├─────────────────────────────────────────────────────────────────┤
│ 硬件层 (Hardware) │
│ CPU = LLM推理 │ RAM = Context Window │ GPU集群 │
└─────────────────────────────────────────────────────────────────┘这张图展示了一个完整的层次结构。最上层是用户看到的应用——各种 Agent 产品。最下层是"硬件"——LLM 推理能力和 Context Window。中间就是我们缺失的"操作系统"。
2.3 五大子系统的精确映射#
让我们把这个类比展开，看看 Agent OS 需要哪些核心子系统：
进程管理：Agent 的生命周期与任务编排
在传统 OS 中，进程管理负责创建、调度、终止进程。在 Agent 世界中，这对应于：
- Agent 的创建和销毁
- 多 Agent 之间的协调
- 任务的分解和编排
- 工作流的状态机管理
当前的实现包括 LangGraph（状态图编排）、Temporal（持久化工作流）等。这个领域相对成熟，因为编排本身不是新问题。
内存管理：Context Engineering
这是最复杂也最重要的部分。传统 OS 的内存管理包括虚拟内存、页面置换、内存保护。在 Agent 世界中，这对应于：
- Context Window 的高效利用
- 信息的"换入换出"策略
- 长期记忆与短期记忆的管理
- RAG（检索增强生成）
当前的实现非常原始。MemGPT/Letta 尝试用"虚拟内存"思路管理 Context，但整体仍处于早期阶段。
文件系统：状态持久化与记忆存储
传统 OS 的文件系统负责数据的持久化存储。在 Agent 世界中，这对应于：
- Agent 状态的持久化
- 长期记忆的存储
- 知识库的组织
- Checkpoint 和恢复
PostgreSQL + pgvector 是当前最成熟的选择。这也是为什么我认为数据库在 Agent 架构中会扮演核心角色。
I/O 管理：工具调用与外部交互
传统 OS 通过设备驱动管理硬件 I/O。在 Agent 世界中，这对应于：
- 工具调用（Tool Use / Function Calling）
- MCP（Model Context Protocol）等标准协议
- API 集成
- 与外部系统的交互
Anthropic 推出的 MCP 是这个方向最重要的尝试，试图标准化 Agent 与外部世界的交互方式。
安全：隔离与权限控制
传统 OS 的安全机制包括用户权限、进程隔离、沙箱。在 Agent 世界中，这对应于：
- Agent 执行环境的隔离
- 权限的细粒度控制
- 操作的审计和追溯
- 防止恶意行为
当前这个领域几乎是空白。E2B、Firecracker 提供了一些沙箱能力，但远未形成完整的安全体系。
让我用一张表总结这五大子系统的现状：
| 子系统 | 传统 OS | Agent OS | 当前实现 | 成熟度 |
|---|---|---|---|---|
| 进程管理 | fork/exec/调度器 | Agent 生命周期、任务编排 | LangGraph, Temporal | ⭐⭐⭐ |
| 内存管理 | 虚拟内存、页面置换 | Context Engineering、RAG | MemGPT/Letta | ⭐⭐ |
| 文件系统 | ext4/ZFS | 状态持久化、记忆存储 | PostgreSQL + pgvector | ⭐⭐⭐ |
| I/O 管理 | 设备驱动 | 工具调用、MCP | Anthropic MCP | ⭐⭐ |
| 安全 | 权限、沙箱 | Agent 隔离、审计 | E2B, Firecracker | ⭐ |
三、历史定位：Claude Code 处于什么阶段？#
3.1 操作系统的演化简史#
要理解我们在哪里，需要先回顾我们来自哪里。
操作系统的演化大致经历了这些阶段：
批处理系统 (1960s)
↓
分时系统 (1970s)
↓
Unix (1970s-80s)
↓
个人电脑 OS: DOS/Mac/Windows (1980s-90s)
↓
现代 OS: Linux/Windows NT (1990s-2000s)
↓
云原生: 容器/K8s (2010s)每一次跃迁都带来了关键的抽象层：
- 批处理 → 分时：从一次处理一个任务，到多任务并发
- 分时 → Unix：统一的文件抽象，“一切皆文件”
- Unix → 个人电脑 OS：图形界面，用户友好
- 个人电脑 → 现代 OS：网络原生，内存保护，多用户
- 现代 OS → 云原生：容器化，编排，弹性伸缩
3.2 我们在哪里？DOS/CP-M 阶段#
我的核心判断：当前的 Agent（如 Claude Code）大约处于 DOS/CP-M 阶段。
这不是贬低——DOS 在当时是革命性的。但它确实缺乏很多我们今天认为理所当然的东西。
让我做一个精确的对比：
| 特征 | DOS 时代 | Claude Code 现状 |
|---|---|---|
| 内存模型 | 实模式，直接访问物理内存 | 直接塞 Context，无管理 |
| 文件操作 | 直接操作 FAT 文件系统 | 直接 cat/echo/rm |
| 多任务 | 无 | 无（单 Agent 串行执行） |
| 隔离性 | 无 | 无（Agent 可以 rm -rf） |
| 标准接口 | 几乎没有统一标准 | 没有统一标准 |
| 权限控制 | 无 | 依赖模型"自律" |
DOS 程序员需要自己处理内存管理、显卡驱动、磁盘 I/O。今天的 Agent 开发者也要自己处理 Context 管理、工具调用、状态持久化。
这不是巧合，而是技术演化的必然阶段。
3.3 下一阶段：从 DOS 到 Unix#
如果历史可以指引未来，那么接下来会发生什么？
从 DOS 到 Unix 的跃迁，带来了几个关键变化：
- 虚拟内存：程序不再直接操作物理内存，而是通过虚拟地址空间
- 标准系统调用：统一的 API 访问系统资源
- 进程隔离：一个程序崩溃不会影响整个系统
- 文件抽象：统一的文件接口，“一切皆文件”
我预测 2025-2026 年，Agent 领域会出现类似的跃迁：
| 维度 | Stage 1 (现在) | Stage 2 (即将到来) |
|---|---|---|
| 接口 | 裸 bash 命令 | 标准化"系统调用"（MCP 成熟） |
| 隔离 | 无 | 沙箱执行环境 |
| 内存 | Context 硬塞 | 虚拟记忆（自动换入换出） |
| 状态 | 无持久化 | Checkpoint + 恢复 |
| 多任务 | 单 Agent 串行 | 多 Agent 并发协作 |
一句话总结：从"Agent 直接操作物理世界"到"Agent 通过标准抽象层操作虚拟化的资源"。
这个转变的意义在于：
- 对开发者：不再需要处理底层细节，可以专注于业务逻辑
- 对用户：更安全、更稳定、更可预测的 Agent 行为
- 对生态：标准化接口催生更丰富的工具和服务
四、最复杂的战场：内存管理（Context Engineering）#
在 Agent OS 的五大子系统中，我认为内存管理是最复杂、也是价值密度最高的方向。
4.1 为什么内存管理最重要？#
回顾操作系统的历史，虚拟内存是 Unix 最重要的创新之一。
在虚拟内存出现之前，程序员必须自己管理物理内存的分配。程序只能使用机器实际拥有的 RAM。如果程序需要的内存超过物理内存，就只能崩溃或手动实现复杂的内存换入换出逻辑。
虚拟内存改变了这一切。它给每个程序一个"幻觉"——好像它拥有整个地址空间。操作系统在背后自动处理页面置换，把不常用的数据换出到磁盘，需要时再换入。
这个抽象释放了巨大的生产力。程序员不再需要关心物理内存的限制，可以专注于算法和业务逻辑。
在 Agent 世界，我们正需要同样的革命。
Context Window 是 Agent 最稀缺的资源。128K tokens 看起来很大，但考虑到：
- 系统提示词可能占用 10-20K tokens
- 工具定义可能占用 10-20K tokens
- 上下文文档、代码可能占用 50-80K tokens
- 留给实际对话的空间可能只剩 20-30K tokens
这就像 1980 年代的 640KB 限制一样窘迫。
4.2 Agent 的内存层次结构#
让我用一个类比来描述 Agent 应该有的内存层次：
┌─────────────────────────────────────────────────────────┐
│ Agent 内存层次 │
├─────────────────────────────────────────────────────────┤
│ L0: 寄存器 │ 当前 token 的注意力权重 │
│ L1: Cache │ 最近几轮对话（在 context 内） │
│ L2: RAM │ Context Window 全量（128K tokens） │
│ L3: Swap │ 向量数据库热数据（可快速检索） │
│ L4: Disk │ PostgreSQL / 文件系统（冷数据） │
└─────────────────────────────────────────────────────────┘这个层次结构的关键洞察是：
- 越往上越快、越贵、越小：L0（当前注意力）是瞬时的，L4（磁盘）是永久的
- 需要自动管理：就像 CPU 不需要程序员手动管理 L1/L2 Cache，Agent 也不应该需要显式管理记忆的层次
- 需要智能换入换出：系统应该自动判断什么信息应该在 Context 中，什么应该在外部存储中
4.3 MemGPT 的洞察：虚拟记忆#
2023 年，Berkeley 的研究者发表了 MemGPT 论文，核心思想惊人地简单：
用操作系统虚拟内存的思路来管理 LLM 的 Context。
MemGPT 的核心机制：
- 给 Agent 一个"无限记忆"的幻觉：Agent 认为它有无限的记忆空间
- Agent 自己决定换入换出：通过特殊的工具调用，Agent 可以主动"保存"或"加载"记忆
- 背后是自动的页面置换：系统在背后管理实际的 Context 使用
这就像虚拟内存给程序一个"无限 RAM"的幻觉，而操作系统在背后默默处理页面置换。
MemGPT（现在改名为 Letta）的实践表明，这个思路是可行的。但它仍然是一个研究原型，距离生产级的"虚拟记忆系统"还有很长的路要走。
4.4 为什么"长上下文"不能替代内存管理？#
一个常见的误区是：只要 Context Window 够大，内存管理就不重要了。
这是错误的，原因有三：
成本问题： 更长的 Context = 更高的 API 费用。以 Claude 为例，输入 token 按量计费。如果每次调用都塞满 1M tokens，成本会是 128K 的 8 倍。对于高频 Agent 应用，这个成本差异是致命的。
延迟问题： 更长的 Context = 更慢的推理。LLM 推理的时间复杂度与 Context 长度相关。1M token 的首 token 延迟可能是 128K 的数倍。对于需要快速响应的 Agent，这是不可接受的。
质量问题： 信息太多反而会"迷失"。研究表明，LLM 在处理长上下文时，对中间部分的信息利用效率显著下降（“Lost in the Middle” 现象）。把所有信息都塞进 Context，不如精心挑选最相关的信息。
结论：即使 Context Window 变成 10M tokens，我们仍然需要智能的内存管理。
就像今天的电脑有 128GB RAM，我们仍然需要虚拟内存和页面置换。不是因为 RAM 不够大，而是因为高效的内存管理本身就是价值。
五、PostgreSQL 的机会：成为 Agent 的"海马体"#
如果 Context Engineering 是最复杂的技术战场，那么数据库则是最稳的商业机会。
5.1 数据库在 Agent OS 中的角色#
让我用一个认知科学的类比：
- Context Window = 工作记忆（Working Memory）：容量有限，用于当前任务
- 数据库 = 长期记忆（Long-term Memory）：容量巨大，持久存储
在人脑中，海马体负责将短期记忆转化为长期记忆，也负责在需要时检索长期记忆。
PostgreSQL 可以成为 Agent 的"海马体"。
但这个类比还不够完整。数据库在 Agent 架构中扮演的角色，远不只是"存数据"：
- 记忆中枢：存储 Agent 的长期记忆、知识库、上下文
- 状态持久化：保存 Agent 的状态，支持断点恢复
- 审计追溯：记录所有操作，支持回放和调试
- 协调中心：多 Agent 之间的状态同步和通信
- 检索引擎：语义搜索、向量检索、全文搜索
这意味着数据库不是 Agent 架构的"边缘组件"，而是核心基础设施。
5.2 为什么是 PostgreSQL？#
在众多数据库中，为什么 PostgreSQL 最有潜力成为 Agent 的标准存储？
| Agent 需求 | PostgreSQL 的优势 |
|---|---|
| 结构化状态 | JSONB + 关系模型，灵活且强大 |
| 向量检索 | pgvector + pgvectorscale |
| 全文搜索 | tsvector + BM25 |
| 事务一致性 | ACID，可靠性有保障 |
| 可扩展性 | 440+ 扩展，几乎能做任何事 |
| 生态成熟度 | 30+ 年历史，全球开发者社区 |
关键在于：PostgreSQL 不只是一个关系型数据库，它是一个可扩展的数据平台。
通过扩展机制，PostgreSQL 可以成为：
- 向量数据库（pgvector）
- 时序数据库（TimescaleDB）
- 图数据库（Apache AGE）
- 文档数据库（JSONB）
- 搜索引擎（ParadeDB）
这种"一个数据库满足所有需求"的能力，对 Agent 架构特别有价值。因为 Agent 需要同时处理结构化数据、向量嵌入、全文搜索、时序日志等多种数据类型。
5.3 TigerData 的实践：“Agentic Postgres”#
TigerData（原 Timescale）最近发布了他们对"Agentic Postgres"的愿景，值得关注。
他们的核心观点是：
“The database is the ideal place to manage all agent state and memory.”
他们提出了四个关键能力：
- Interface（接口）：通过 MCP 服务器暴露数据库能力给 Agent
- Search（搜索）：pgvectorscale + BM25 混合检索
- Memory（记忆）：Agent 状态的持久化存储
- Forkable（可分叉）：零拷贝数据库分叉，支持 Agent 的"假设分析"
特别是第四点——可分叉数据库——是一个独特的洞察。
想象一个 Agent 在执行复杂任务时，需要探索多条路径。如果数据库可以瞬时"分叉"出多个副本，每条路径可以在自己的数据库副本中独立探索，最后选择最优路径"合并"回来——这就像 Git 的分支模型，但用于数据库状态。
这种能力在传统应用中很少需要，但对于 Agent 来说可能是刚需。
5.4 开源的机会#
TigerData 做的是云托管服务。但在 Agent 时代，开源和私有化部署有其独特价值：
企业数据安全：很多企业不愿意把敏感数据放到第三方云服务。私有化部署的 Agent 基础设施会是刚需。
定制化需求：不同场景对 Agent 存储的需求差异很大。开源方案提供了更大的灵活性。
可观测性：这是一个被忽视的领域。Agent 的调试、监控、性能优化都需要深度的可观测性支持。开源方案更容易与现有的监控体系集成。
六、预测：2025-2027 的演化路径#
基于操作系统的历史类比，我尝试预测 Agent 基础设施在未来 2-3 年的演化。
6.1 短期（2025-2026）：标准化之战#
这个阶段的核心主题是标准的诞生。
就像 1970 年代 Unix 确立了 POSIX 标准，Agent 领域也需要标准化：
- MCP 或类似协议成为事实标准：Anthropic 的 MCP 是目前最有力的候选。如果它被广泛采纳，将成为 Agent 与工具交互的"POSIX"。
- 几个 Runtime 框架胜出：LangGraph、Temporal、或者新的竞争者，会在这个阶段决出优胜。
- Context Engineering 成为热门技术方向：MemGPT 的思路会被更多团队探索和实现。
这个阶段的关键问题是：谁来定义标准？ 是模型厂商（OpenAI、Anthropic）、云厂商（AWS、Google）、还是开源社区？
6.2 中期（2026-2027）：平台化整合#
这个阶段的核心主题是平台的形成。
就像 1990 年代 Windows 和 Linux 确立了各自的生态，Agent 领域也会出现平台级玩家：
- 云厂商推出 Agent PaaS：AWS、Google、Azure 会推出完整的 Agent 开发和运行平台。
- 开源 Agent OS 出现：类似 Linux 的开源 Agent 操作系统会出现，成为私有化部署的标准选择。
- 数据库层整合：PostgreSQL 生态可能会胜出，成为 Agent 存储的事实标准。
这个阶段的关键问题是：开源还是闭源？ 历史表明，基础设施层往往由开源赢得。但 AI 时代可能有所不同。
6.3 长期（2027+）：Agent 容器化#
这个阶段的核心主题是容器化和编排。
就像 Docker 和 Kubernetes 改变了应用部署，Agent 也需要类似的抽象：
- Agent 打包标准：类似 Docker Image，定义 Agent 的标准打包格式。
- Agent 编排系统：类似 Kubernetes，管理多 Agent 的调度、扩缩容、健康检查。
- Agent 云：专门为 Agent 优化的云平台，提供 LLM 推理、存储、编排的一体化服务。
这个阶段的关键问题是：Agent 会取代传统应用吗？ 还是与传统应用共存？
6.4 谁会成为赢家？#
让我尝试预测各层的可能赢家：
| 层次 | 可能的赢家 | 确定性 |
|---|---|---|
| 硬件层（LLM） | OpenAI, Anthropic, 开源模型 | 高 |
| Runtime 层 | LangGraph? 云厂商? 新玩家? | 低 |
| 存储层 | PostgreSQL 生态 | 中高 |
| 可观测性 | Datadog? Grafana? 新玩家? | 中 |
几个观察：
- LLM 层格局已定：OpenAI 和 Anthropic 是第一梯队，开源模型是重要补充。
- Runtime 层高度不确定：这个领域还在快速变化，可能被大厂收割，也可能出现 Linux 式的开源标准。
- 存储层相对稳定：PostgreSQL 的优势明显，但需要有人来整合 Agent 场景的需求。
- 可观测性是蓝海：当前几乎是空白，有很大机会。
七、行动建议：如何在这个生态中找到位置？#
7.1 对基础设施从业者#
如果你从事基础设施领域，有几个建议：
关注 Context Engineering。 这是最复杂、也是最有技术含量的方向。如果你能做出生产级的"虚拟记忆"系统，价值巨大。
数据库会成为核心，不是边缘。 不要把数据库仅仅看作"存储"。在 Agent 架构中，数据库是记忆中枢、状态管理器、协调中心。
可观测性是被低估的机会。 Agent 的调试极其困难——非确定性、长链路、多组件。谁能解决 Agent 的可观测性问题，谁就能占领一个重要位置。
7.2 对数据库从业者#
如果你从事数据库领域，Agent 时代带来了新的机会：
PostgreSQL 有独特优势，但需要主动拥抱 Agent 场景。 不要等着别人来定义"Agentic Database"。主动研究 Agent 的需求，构建相应的能力。
向量能力是必备，但不是全部。 pgvector 只是起点。结构化状态管理、审计追溯、实时协作同样重要。
“一个数据库满足所有需求"是可行的叙事。 Agent 需要同时处理多种数据类型。PostgreSQL 的可扩展性使它有潜力成为这个"统一数据平台”。
7.3 对创业者和投资人#
如果你在考虑 Agent 领域的创业或投资机会：
通用 Runtime 赛道风险高。 这个领域容易被大厂收割。一旦 OpenAI 或 Anthropic 推出官方的 Agent 框架，独立的 Runtime 公司会很难生存。
垂直场景 + 数据平面是更稳的切入点。 选择一个垂直场景（如法律、医疗、金融），深入理解其 Agent 需求，构建专门的数据和工具基础设施。
窗口期 12-24 个月。 标准化正在快速发生。如果要入局，现在是最好的时机。等到标准定型，机会窗口就关闭了。
八、结语：我们正在见证历史#
让我回顾这篇文章的核心论点：
- AI Agent 生态正在重演操作系统的演化史——从混沌到秩序，从原始到标准化。
- 当前处于 DOS 阶段，即将进入 Unix 阶段——标准接口、虚拟化抽象、进程隔离正在诞生。
- 最大的技术机会在 Context Engineering——谁能做出 Agent 的"虚拟内存"，谁就能定义下一代基础设施。
- 最稳的商业机会在 Database——存储层变化慢，但价值持久。PostgreSQL 生态有明显优势。
- PostgreSQL 有潜力成为 Agent 的"海马体"——不只是存储，而是记忆、状态、协调的核心。
1991 年，一个芬兰大学生在邮件列表里发帖：
“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu)…”
没有人预料到，这个"业余爱好"会成为云时代的基石，运行着全球 90% 以上的云服务器和几乎所有的超级计算机。
2025 年，我们正站在一个类似的十字路口。
AI Agent 的"操作系统"正在诞生。它还很原始，就像 1991 年的 Linux 0.01。但在未来的某一天，它可能会成为 AI 时代的基础设施，运行着数十亿 Agent，处理着人类社会的各种任务。
问题是：谁来写那个内核？谁来建那个文件系统？谁来定义那些标准？
答案正在被书写。
而你，正在见证历史。
作者：Vonng 日期：2025年1月
