你的 Agent 会思考，但它不会记忆：把“会做事”升级成“会持续做事”

AI Agent 这两年进化得非常快。它会推理会规划会调用工具会写代码甚至还能陪你聊很久。可真正落到生产里你很快就会发现一个很致命的问题它能处理当下却很难沉淀过去。这一次做过的事下一次可能就忘了这一次写过的文件下一次可能找不到这一次跑通的流程换个会话又得重来。原文提出的核心观点就是“Agent 不是不够聪明而是缺一个真正适合它生存的基础设施”。01 先会思考不代表能长期工作很多人做 Agent 系统时第一反应是往外拼装组件数据库一套、记忆模块一套、搜索一套、文件存储一套、沙箱执行再来一套。看起来都能用实际上却很容易变成“胶带式架构”——能连起来但不好维护能跑起来但很脆。原文就直指这一点当记忆、搜索、文件、执行都分散在不同服务里Agent 自己很难统一理解和管理这些资源。问题不在于工具少而在于缺少统一的工作空间。对人来说我们习惯在一个系统里完成写笔记、查资料、存文件、跑脚本、回看历史记录。可很多 Agent 架构却把这些能力拆得太散最后变成“Agent 能干活但干活的上下文不在同一个地方”。02 真正适合 Agent 的不是传统数据库思维传统数据库是为“长期稳定保存”设计的要选云厂商、选区域、配资源、做备份、做容灾目标是长期运行、持续维护。对人类业务来说这很合理但对 Agent 来说很多任务其实是短生命周期的一次会话、一次实验、一次审查、一次分析做完就可以丢掉。原文把这种思路概括为数据库应该像分支一样被创建和销毁而不是像祖产一样被供起来。这也是 Ghost 想解决的问题。它提供的是即时、可丢弃、可 Fork 的 Postgres 数据库支持通过 CLI 或 MCP 使用适合并发会话和短任务场景原文还强调它是 Postgres-native 的方案而不是再造一套专有接口。你可以把它理解成这样一个 Agent 会话 一个临时数据库一次实验 一个可 Fork 的副本结果好 保留结果差 删除这套模式非常像 Git而不是传统 RDS 运维。03 只给数据库还不够Agent 还需要“记忆、搜索、文件、执行”如果说数据库是底座那么 Agent 还需要四个关键能力第一记忆。Agent 不能每次都从零开始。它需要知道自己上次做过什么、用户偏好是什么、哪些结论已经过时、哪些信息仍然有效。原文提到的 Memory Engine就是把这种能力直接放进 Postgres 里并且支持按时间维度查询让“某个时刻什么是真实的”变得可追溯。它不只是存事实还会记录事实在什么时候成立、什么时候被更新。第二搜索。Agent 面对的不是单条记录而是大规模上下文。原文提到 Ghost 默认结合了全文检索和向量检索能力用来支持关键词、语义和混合搜索这样一来Agent 不必再额外维护一套独立的搜索集群。第三文件。Agent 会不断生成文档、代码、日志、图片、数据集。原文中提到 TigerFS 的定位是“Postgres-backed filesystem”也就是把文件系统和数据库打通让文件不再只是散落在对象存储里的孤岛而是能被事务化、可查询、可协作的数据。第四安全执行。Agent 迟早要跑代码但“能跑”不等于“能安全地跑”。原文提到 Ox 提供的是与数据联通、同时又隔离的沙箱环境既能让 Agent 调用自己的数据又避免直接伤到主环境。这四个能力放在一起Agent 才算真正有了“工作能力”而不是只有“聊天能力”。04 为什么“全放在 Postgres 里”反而更简单很多人第一眼看到“一个数据库承载记忆、搜索、文件、沙箱协作”会觉得这是不是把系统做重了。恰恰相反原文的思路是统一底层减少胶水代码。当所有东西都围绕 Postgres 运转时认证模型、事务模型、查询语言、权限边界都能尽量统一系统复杂度反而下降。这点特别适合 Agent 场景。因为 Agent 最怕的不是“功能不够”而是“每个功能都在不同系统里各说各话”。一旦记忆、检索、文件、执行分别放在不同服务开发者就要自己写同步逻辑、状态映射、权限串联和失败恢复。系统一复杂Agent 的稳定性就会直线下降。原文之所以反复强调 Postgres并不是因为它“时髦”而是因为它足够成熟、足够稳、足够通用。对 Agent 来说稳定比炫技重要得多。05 这些场景才是真正的 Agent 生产力原文列了几个非常典型的 Agent 使用方式我把它们翻译成更适合国内开发者理解的表达代码审查 Agent它拿到一个 PR 之后先 Fork 一份当前状态再把测试和回归跑一遍同时去回看历史审查记录看看之前哪里踩过坑、团队偏好什么风格、作者上次哪里被指出问题。最后把审查结论存下来下次还能继续用。研究分析 Agent它会把抓到的公司资料、竞品对比、价格信息统一存起来文档写到文件系统里分析时再去回看是否研究过类似对象、过去的结论有没有变化。需要算数据时再扔到沙箱里跑不污染原始结果。多 Agent 协作团队一个写代码一个写文档一个跑测试。大家各自处理任务但共享底层数据和记忆不会因为文件冲突或者上下文丢失而互相拆台。数据探索 Agent用户问“如果把定价模型改掉结果会怎样”Agent 直接 Fork 数据库在副本里改逻辑、回放历史交易、比较多个方案最后给你三个结果。真正的关键不是它会不会算而是它能不能安全地试。这几类场景有一个共同点Agent 不只是生成内容而是在持续经营上下文。06 结语Agent 的下一步不是更会说话而是更会积累现在很多 Agent 方案都停留在“会回答、会调用、会跑流程”的层面。可一旦进入真实业务问题立刻变成能不能记住上次做了什么能不能复用上次积累的资料能不能在不污染主环境的情况下做实验能不能让多个 Agent 在同一底座上协同工作。原文给出的答案非常明确给 Agent 一个真正适合它的工作底座。让数据库、记忆、搜索、文件、执行都围绕统一的 Postgres 体系展开Agent 才能从“聪明的工具”变成“靠谱的生产力”。你可以把这句话记住Agent 不是缺推理能力它缺的是一个能把“推理结果”变成“持续资产”的地方。如果你正在搭建 Agent 系统真正值得优先解决的已经不是“它会不会想”而是“它能不能把想过的东西留下来”。