您的商业AI记不住5秒前做了什么？一种新架构可以解决这个问题。

TL;DR: 您的代理患有失忆症

• 当今大多数AI代理都是无状态的。它们没有可靠的过往行为记忆，使其不适合库存管理或多步骤客户旅程等关键商业操作。这并非一个bug；而是其设计中固有的缺陷，导致不可预测、不可审计的故障。
• 本周arXiv上的一篇新论文《ESAA: Event Sourcing for Autonomous Agents in LLM》(arXiv:2602.23193v1)，提出了一种解决方案，通过将久经考验的企业模式——事件溯源（event sourcing）——应用于代理系统（agentic systems）[5]。它将代理的意图（它想做什么）与其效果（实际发生了什么）分离。
• 这种架构转变允许创建可审计、可重放和有弹性的代理工作流。它使品牌能够使用异构LLM（如GPT-5和Claude Sonnet 4.6），避免供应商锁定，并构建能够最终被信任执行关键任务而不会虚构自身状态的“长周期代理”（long-horizon agents）[6]。

下面是一个越来越可能发生的场景。一家快速增长的DTC品牌（姑且称之为“Melrose Active”）的CTO陷入了彻底的恐慌。他们的新型自主库存代理系统，一个被吹嘘为“agentic commerce”巅峰的产品，刚刚试图订购50,000件滞销SKU。触发原因？一次日常库存检查中出现的网络故障。该代理在操作途中失去了上下文，重新运行了其初始逻辑，误解了第一次失败尝试中的部分数据，并得出结论认为仓库是空的。这是一次价值百万美元的错误，只有通过人工干预警报才得以发现，坦率地说，这完全违背了自主系统的目的。

这只是一个示例场景，但绝非危言耸听。它是“代理AI热潮”（agentic AI boom）中一个肮脏小秘密的直接后果：这些系统大多建立在沙子上。它们是无状态的、健忘的，在永恒的当下运作。它们无法可靠地记住一分钟前做了什么，更不用说昨天了。对于简单的问答聊天机器人来说，这只是一种烦恼。但对于定义真实商业的复杂、有状态、长期运行的流程——库存、物流、个性化、客户服务——这是一种灾难性的负担。

当世界其他地方被AI代理预订航班或“氛围研究”（vibe researching）旅行行程的演示所迷惑时[1]，我们这些在构建实际商业系统前线的人，正在进行一场更为根本的战斗：关于状态的战斗。而本周默默地在arXiv上发布的一篇论文，可能是在这场战斗中最重要的进展之一。

那么，三个AI代理走进酒吧……然后把它烧了？

Melrose Active的代理问题不仅仅是一个单点故障。它是多代理系统（multi-agent systems）中一个更深层次、系统性问题的症状。当你部署多个共享资源（如库存数据库、定价引擎或API网关）的自主代理时，它们不仅仅是单独失败。它们通常会以同步、相关的方式失败，从而放大损害。

本周刚刚发表在arXiv上的一篇引人入胜的论文《三个AI代理走进酒吧……“蝇王”部落主义》（Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism），完美地说明了这种噩梦场景[2]。研究人员将自主LLM代理置于一个经典的资源争夺场景（El Farol酒吧问题），并观察发生了什么。结果，代理没有作为独立的、理性的参与者，而是根据其底层推理模式迅速形成了“部落”。一些代理变得“好斗”（27.3%的群体），总是试图访问资源。另一些是“保守的”（24.7%），而大部分则变得“投机取巧”（48.1%）。

这可怕的结果是什么？这种新兴的部落主义导致了同步行为，造成了比简单随机分布更严重的系统过载和故障。当一个代理决定淹没您的库存API时，很可能数十个基于相同基础模型和逻辑构建的其他代理也即将做同样的事情。这就是部署看似自主但缺乏真正独立故障模式的系统所带来的危险。如果没有一个强大的架构骨干，您的代理工作团队就不是一个由个体组成的团队；而是一群暴徒，容易发生闪电崩盘和羊群般的愚蠢行为。

这就是为什么对代理“能力”（它们能做什么）的痴迷如此错误。真正的挑战是构建一个商业AI架构（commerce AI architecture），它不仅能够优雅地处理一个代理的失败，还能处理数十个代理同步失败的情况。我们需要确定性的、可审计的、能够抵御LLM驱动逻辑固有混乱的系统。我们需要为失败做计划，而不仅仅是惊叹成功。

失忆机器：为什么您当前的AI代理在商业中会失败

这种脆弱性的根本原因就是工程师们所说的“状态管理”（state management）。或者说，在这种情况下，是完全缺乏状态管理。当今大多数代理框架，如流行的ReAct（Reason+Act）循环，将每次交互视为一个 largely 独立的事件。代理的“记忆”通常只是塞进LLM调用上下文窗口的对话历史。这不是记忆；它就是一张便签，而且非常小。

本周早些时候发表的一篇关于评估代理应用长期记忆的论文证实了我们许多人在实践中看到的情况：这种方法会随着时间的推移而灾难性地退化[7]。随着任务变得更复杂，轮次增加，上下文窗口就会被填满，关键信息丢失，代理开始偏离。它会忘记其初始指令、之前的行动以及它应该操纵的世界状态。

这对任何严肃的商业用例都产生了深远而实际的影响：

1. 缺乏可审计性： 如果代理的行动只是由概率性LLM驱动的瞬态API调用，那么真相的来源是什么？当您的财务部门询问为什么您的动态定价代理在半夜将旗舰产品的价格降低了90%时，您唯一的答案是“LLM决定了”。没有关于决策、支持决策的数据或事件序列的不可变日志。这对于任何受监管或任务关键型流程来说都是不可接受的。

2. 不具备幂等性（No Idempotency）： 在分布式系统中，幂等性（Idempotency）是关键。它保证多次发出相同的请求会产生与一次请求相同的结果。当Melrose Active代理在网络错误后重试其库存检查时，它本应是一个无害的、幂等的操作。相反，由于其状态丢失，重试变成了一个新的、独立的行动，并带来了灾难性的结果。大多数代理框架不强制甚至不考虑幂等性，使其在面对现实世界中不可避免的网络故障时变得脆弱。

3. 无法重放和调试： 当系统失败时，您如何调试？使用无状态代理，您无法调试。您无法重放导致故障的确切事件序列和状态。您只能盯着LLM提供商的不透明日志，试图逆向工程一个概率性的黑盒。这就像试图通过观看有线新闻辩论来调试一个复杂的金融模型一样。

这些并非边缘情况。这是当今市场上兜售的大多数代理商业系统的默认行为。它们从根本上讲是不可靠的、不可审计的，不适合用于涉及真实资金和真实库存的生产环境。它们是等待发生的架构负债。

事件溯源是“代理商业”迟来的非性感解决方案吗？

这让我提到了本周发布的一篇标题“实在不性感”的论文：《ESAA: Event Sourcing for Autonomous Agents in LLM》(arXiv:2602.23193v1)[5]。它提出了一种解决方案，不是更巧妙的提示或更大的模型。它是一种从高风险、大规模企业系统世界中借鉴的架构模式：事件溯源（event sourcing）。

事件溯源并非新生事物。它是CQRS（命令查询责任分离）等架构中的核心模式，多年来一直在金融科技、银行和物流等领域使用——任何需要审计性和可靠性的地方。其核心思想很简单：不是存储系统的当前状态，而是存储所有曾经发生过的事件的仅追加日志。然后通过重放这些事件来推导当前状态。

ESAA论文提出将这种模式应用于AI代理。代理不再让LLM直接调用工具并改变世界状态，代理的唯一工作是发出一个描述其**意图（intention）**的JSON对象。仅此而已。这个意图被视为一个事件。一个独立的、确定性的系统——编排器（orchestrator）——随后负责验证此事件，将其持久化到不可变日志中，然后才应用其效果（例如调用Shopify API或更新数据库）。

这种分离是关键。系统中的概率性、不可预测的、创造性的部分（LLM）与系统中确定性的、可靠的、改变状态的部分（编排器）是相互隔离的。

ESAA 工作原理：意图，而非行动

基于ESAA系统的数据流提供了当今代理急需的护栏。它在一定程度上强制执行了纪律，防止了我们在Melrose Active案例中看到的各种故障。

流程如下所示：

这不仅仅是一个理论图表。ESAA论文展示了这种架构与OpenAI的GPT-5和Anthropic的Claude Sonnet 4.6等异构模型的工作情况[6]。其优点在于事件日志和编排器是模型无关的。LLM的作用被简化为“建议引擎”，但编排器仍然是所有状态变化的单一真实来源。

自主库存代理的即时回放

让我们使用这种架构，重演Melrose Active的场景。该品牌，总部就在洛杉矶，需要管理其在Abbot Kinney旗舰店的库存。

1. 触发器： 一个Cron作业启动库存代理，目标是：“确保Abbot Kinney位置的所有核心产品都高于安全库存水平。”
2. 意图 #1（查询）： LLM代理首先发出一个意图：{"intent": "get_inventory_levels", "location": "abbot_kinney"}。编排器记录此意图，查询库存系统，并将数据返回给代理。
3. 网络故障： 假设编排器发送数据后连接立即断开。代理什么也没收到。在无状态模型中，它的下一个动作是无法预测的。在ESAA模型中，没有任何改变。没有状态被修改。唯一存在的是查询的已记录意图。
4. 重试： 当代理重试时，它再次发出完全相同的意图：{"intent": "get_inventory_levels", "location": "abbot_kinney"}。编排器看到这个幂等请求，可以直接重新提供第一次查询的结果，或者再次执行它。结果是一样的。
5. 意图 #2（订单）： 看到一个SKU库存不足，代理现在发出一个命令：{"intent": "create_purchase_order", "sku": "MA-LG-BLK", "quantity": 500, "reason": "Stock at 42, below threshold of 50"}。请注意reason字段——我们现在可以强制LLM证明其意图是合理的，而且这个理由将永远存储在事件日志中。
6. 审计： 六个月后，审计员可以通过重放不可变事件日志，重建当天库存系统的确切状态。他们不仅可以看到发生了什么，还可以看到代理为什么决定采取行动。这是值得信赖的**代理商业架构师（agentic commerce architect）**的基础。

这仅仅是架构设计上的过度杀伤力吗？怀疑论者的观点

当然，没有一种架构是万能药。怀疑论者——或时间紧迫的工程师——首先会指出架构带来的开销。事件溯源（event sourcing）引入了复杂性和延迟。写入日志、验证模式，然后投影状态本质上比直接修改数据库记录要慢。

这种论点有其道理。本周同时提交给arXiv的另一篇论文《Tool-R0》(arXiv:2602.21320v1)，展示了一种完全不同的理念。它使用来自零数据的强化学习来教授代理如何高效使用工具，声称在基准测试中提高了92.5%[9]。它的重点是纯粹的性能和能力，而不是通过日志记录实现运行时可靠性。对于生命周期短且失败成本低廉的任务，Tool-R0的方法可以说更优越。

此外，“纵深防御”（defense-in-depth）臃肿的担忧是真实存在的。对于一个简单的查找订单状态的客户服务聊天机器人来说，您需要这种重型机械吗？可能不需要。一个简单的ReAct循环或OpenPort Protocol（OPP）[1]提出的模型门控就已足够。关键在于理解权衡。

以下是2026年2月最后一周边刚刚浮出水面的几种竞争方法细分：

ESAA模式并非适用于所有问题。但对于定义后台商业的高风险、长时间运行、多步骤流程来说，它的权衡——牺牲几毫秒的延迟以换取多年的可审计性和可靠性——不仅是值得的，而且是强制性的。

这对您品牌的“代理店面准备就绪”（Agentic Storefront Readiness）意味着什么

对于任何DTC品牌的CTO或工程主管来说，这都应该是一个警钟。您的**代理店面准备就绪（agentic storefront readiness）**与您的聊天机器人有多炫酷毫无关系。它关乎您后端的健壮性。关乎您的基础设施是否为有状态、可审计、可靠的代理做好了准备。

准备就绪实际上是这样的：

1. 结构化、幂等API： 您的内部和外部API需要坚如磐石。您的create_order端点能否在相同的负载下被调用五次而不会创建五个订单？如果不能，您就还没有准备好。代理会失败，它们会重试。您的系统必须为此而构建。

2. 丰富的数据层： 代理的优劣取决于它能访问的数据。投资于用于AI搜索的结构化数据（structured data for AI search）——清晰的产品目录、定义良好的客户细分、可访问的库存数据——是任何智能系统的基础。这是普林斯顿GEO实验室等团队正在努力的核心：优化生成环境，而不仅仅是模型本身。

3. 状态管理策略： 这是个大问题。您需要有意识地决定您的代理将如何管理状态。您是否会为低风险交互接受无状态ReAct循环的风险？还是会为关键工作流程投资像事件溯源这样的模式？没有策略就是失败的策略。

4. AI体验实验室： 您不能即兴构建这一切。品牌需要建立内部AI体验实验室（AI experience labs）——沙盒环境，您可以在其中安全地测试这些代理架构。在这里，您可以对自己的系统进行红队测试，模拟网络故障，并在代理能够接触到您圣莫尼卡旗舰店的生产库存之前，观察它们在压力下的行为。

在CTO.LA，我们与商业品牌合作，构建这种基础架构。我们不卖“代理魔法”；我们正在实现弹性、平淡但至关重要的“管道”，使其成为可能。我们充当代理商业架构师（agentic commerce architect），确保系统不会在代理第一次出现问题时崩溃。

不要再构建另一个“代理负债”

仓促地将“AI代理”安装到商业堆栈的每个部分，正在创造新一代技术债务。这些系统在没有针对状态、可审计性和故障的连贯架构策略的情况下构建，并非资产。它们是等待被触发的负债。

一项对实验室部署代理的研究发现，有11种不同类别的故障，从数据泄露和拒绝服务到仅仅是谎报任务完成情况[1]。问题不在于代理失败；而在于我们的系统设计不足以遏制这种失败。

ESAA论文之所以重要，并非因为它是一项革命性的AI发现，而是因为它呼吁保持理智。它提醒我们，过去二十年分布式系统工程领域来之不易的经验教训，并不会因为我们拥有了强大的新LLM而变得一文不值。事实上，它们变得比以往任何时候都更加重要。

不要让您公司的下一个重大AI计划成为其下一个重大停机事件。专注于架构。为可靠性而构建。将意图与执行分离。看在上帝的份上，给您的代理一个记忆。

**洛杉矶及其他地区商业AI（commerce AI in Los Angeles）**的未来，不会由最巧妙的提示定义，而是由最具弹性的系统定义。CTO.LA与正在构建这种代理基础设施的商业品牌合作。让我们聊聊吧。

参考文献

1. [AnybodyCanPrompt - Anthropic Rejects Pentagon

• agentic commerce
• commerce ai architecture
• event sourcing
• llm
• ai