有金融能力的 Agent 的决策内存设计

"memory" 的重要性远比听起来更深远

想象一个能花真金白银的 agent。如果它忘记了自己过去的决定，坏事就会悄悄发生：它可能会尝试两次购买同一件物品，或重复犯上周已经学过的同样错误，或根本没有它曾经拒绝购买某件商品原因的记录。一个会遗忘的聊天机器人很烦人。一个握着钱包还会遗忘的 agent，风险就大了。

所以每当我的 agent 完成一个决定——买了、被拒了，或等待人类批准时超时了——它就会把该决定写入 CockroachDB。在下一个决定前，它会问数据库："我以前见过类似的情况吗，我当时怎么做的？" 这就是 "agentic memory" 的全部理念：agent 的判断会随着时间改进，因为它的过去是一个真实的、可搜索的记录，而不是它必须从零开始重新猜测的东西。

为什么 CockroachDB 适合这项工作

我本可以用几乎任何数据库来存储行数据。CockroachDB 因为几个具体原因在这里赢得了一席之地：

它永远不会超售，自动进行。 当许多人在完全同一时刻尝试购买库存中的最后一件物品时，CockroachDB 确保其中只有一个人真正得到它——即使在重并发负载下也是如此。我通过同时对库存为 3 的产品发送 50 次购买尝试来测试了这一点，数据库从未让超过 3 个成功。没有额外的代码，没有我必须自己编写的锁。

它使用普通 SQL，与 Postgres 相同的语言。 如果你已经知道如何编写 SELECT 或 UPDATE，你已经大致了解 CockroachDB。没有新的查询语言需要学习。

它在与其他所有内容相同的地方存储 AI 记忆。 CockroachDB 可以保存 "embeddings"——一种将句子转换为数字列表的方式，以便计算机可以比较两个句子的相似程度——就在你的普通表旁边，并有为快速搜索它们而构建的索引。我不需要仅为 agent 的记忆而使用单独的向量数据库。

它能够承受失去整个地区的情况。 我将我的集群设置在三个地区（新加坡、雅加达和孟买），并将其配置为即使其中一个完全消失也能继续工作。对于应该可靠地记住事情的 agent，"记忆本身不能宕机" 正是你想要的特性。

它让 AI 工具能够直接安全地与其交互。 CockroachDB Cloud 有一个内置的 "MCP Server"——可以把它看作一个安全的通道，让 AI assistant（如 Claude）查看你的数据库并回答关于它的问题，默认情况下以只读模式。我用它来字面上用英文问 AI，"向我展示 agent 最近的购买决定和原因"——不需要自定义代码。

它如何实际工作，逐步分解

该 agent 通过一个小网站检查当前库存。

它问 CockroachDB："我以前做过类似的决定吗？" 并获得最接近的匹配项。

如果有库存，它写下一个简短的原因（有时参考它记得的内容），并使用简单网页要求人类批准或拒绝。

如果获得批准，它购买该物品——无论接下来发生什么（购买、售罄、拒绝或超时），它都会将该结果直接保存回 CockroachDB。

该 agent 本身是一个 Python 程序（使用称为 Strands Agents 的框架），由 Amazon Bedrock 上的 Claude 驱动，并在 Amazon Bedrock AgentCore Runtime 上运行——AWS 的 AI agent 托管服务——所以它不仅仅在我的笔记本电脑上运行。"please approve this" 步骤使用 Amazon DynamoDB 作为短期等待室；一旦人类做出决定，该决定的永久记忆就会转移到 CockroachDB。

值得一提的错误

早期，"要求批准" 和 "实际购买物品" 是两个独立的步骤。这意味着如果模型获得了批准，但随后忘记调用第二步，购买——以及它的记忆——都会悄悄消失。我没有通过在提示中更礼貌地询问 AI 来解决这个问题。我通过完全移除间隙来修复它：批准和购买现在在一个单一步骤内发生，所以没有地方让结果丢失。

实时演示与源代码

实时演示：wallet-memory.vercel.app

完整源代码：github.com/yama3133/wallet-memory

如果你很好奇一个拥有真实记忆的 AI agent——不仅仅是更长的提示——在底层实际上是什么样的，代码都在那里。

对于进一步的操作，你可以考虑屏蔽此人和/或举报滥用。