n8n AI 代理记忆:证明会议幸存下来

n8n AI 代理内存只有4件事情一致时才可靠:工作流使用与部署模式兼容的内存后端,相同的用户达到相同的会话键,预期的历史可以从商店中读取,后续执行正确使用该历史. 一个流的后续答案本身都不证明了这些条件. 实际情况下,默认测试内存作为路由和持久性合同. 在单个过程实验中,简单记忆可能足够. 在排队模式下,使用 Postgres 或 Redis 等共享内存服务,给每个对话一个稳定的不透明的会话键,并通过两个会话验证隔离. 然后跨越一个真正的执行界限. 不要说记忆是健康的,因为两个信息在一个执行中似乎一致. 从部署界限开始 官方n8n内存概况将能够使用内存的AI代理节点与不能使用内存的AI链区分开来. 它列出了简单内存和外部内存服务,包括Redis和Postgres,作为不同的实现选择. 这是一个能力地图,而不是健康判决. 第一个问题是,历史在哪里生活. n8n在其简单的内存文件中明确警告,不要使用该节点在队列模式中的活跃生产工作流程中. 电话可以到达不同工人,所以不能假设工人当地历史跟踪对话. 在查看提示或模型之前,将该案例分类为: queue mode unsafe :工作流程在排队模式下运行,使用简单的内存; store unavailable :已配置共享后端,但工作流无法达到它; write unverified :后端接受了连接,但预期的对话转向在持久历史中没有观察到. 转换到Postgres或Redis解决了员工的本地;它没有解决了身份. 一个共享的商店可以忠诚地保留错误的对话在错误的钥匙下. 可用性,耐用性和路由是不同的特性. 对于每个工作流版本,保留一个小的配置收据: 收据应描述规则,而不是显示用户身份,聊天身份,凭证,连接链或消息文本. 如果必须从私人标识器中获得稳定密钥,则在主机上计算HMAC,只出口不透明的结果或本地平等检查. 在测试召回之前验证会议身份 简单内存和课后聊天记忆都使用了一个会议键. 在 Postgres 节点中,您还可以选择表格和文本窗口长度. 它的文档指出,多个Postgres聊天记忆节点默认使用相同的记忆实例;单独的记忆实例需要不同的会议ID. 这使得会议成为正确度边界的关键部分. 它必须是: 1. 稳定于相同的外部对话; 2. 不同于不能分享历史的对话; 3. 独立于临时执行ID; 4. 在内存子节点解决其参数之前生成; 5. 安全记录为不透明的标识符. 这里有一个n8n特定的陷. 记忆节点文档表示,子节点中的表达式与第一个输入项解决,而不是每项一次. 如果三个进来的项目代表三个对话,并且在内存子节点内评估了会话键表达式,则可以使用第一个项目值进行所有三个路由. 不要认为这是一个不良的记忆模型. 记录在根节点边界预期的会话身份数量和记忆适配器观察到的数量. 如果预计有3个,并且观察到一个,请返回 session key collapse . 在子节点边界之前,按执行分开项目或计算和验证每个会议键. 运行一个隔离探测器,用两个合成会议,而不是真正的客户文本: 会议A存储一个不透明的标记,预期的决定是 ROUTE ALPHA . 会议B存储一个不同的标记,其预期决定是 ROUTE BETA . 一个新执行A必须只返回 ROUTE ALPHA . 对于B的新执行必须只返回 ROUTE BETA . 换取任何结果都是一种隐私和正确性失败, 这个负面测试很重要. 每个用户都被映射到相同的共享历史. 阅读历史,然后再执行一次. 数据库排行数量是很弱的证据. 在错误的会话收到消息时,它可以增加,而之前的版本仍然处于文本窗口顶部,或者破坏性内存操作更换了更多的历史. 官方的聊天记忆管理器文档揭示了获取,插入,过失和删除操作. 它的简单阅读模式返回发送者和文本. 通过保护的诊断工作流中使用该功能,或者在本地查询外部存储器,以验证三个事实: 预期的不透明会议键存在; 最后一次测试转转是按正确的顺序进行的; 邻居会议没有包含它. 保持原始的对话远离监测远程测量. 诊断工作流可以将检索的测试标记本地比较并发射: 现在,通过同一个生产触发路径启动另一个工作流程执行. 在当前执行中重复使用另一个节点并不是持久性测试;答案可能仍然存在于项目实用负载或模型背景中. 后续执行只应收到不透明的会议身份和一个受限的问题,预期答案是决策代码. 只有当商店回顾和后来的行为同意时才会通过. 如果历史是正确的,但决定是错误的,请返回 continuity failed . 如果没有真正的新执行,请返回 continuity unverified . 任何一个状态都不应该变成空记忆错误. 按固定顺序重播10个失败状态 附带的 n8n memory health cases.json 装置没有提示或消息文本. 它向一个小分类器提供了十项合成观测: 复制的运行返回: 这条命令是故意的: 1. 确认存储节点连接; 2. 在排队模式下拒绝简单内存; 3. 检测第一项会议键崩; 4. 将当前的会话键与预期的稳定键进行比较; 5. 测试商店的可访问性; 6. 证明书写; 7. 与预期历史相比较反读; 8. 要求后期执行; 9. 与预期结果进行比较. 停止在第一个失败层给操作员一个有用的修复. 转换提示不能修复排队模式位置. 修复桌子不能修复会议键漂移. 改一个模型不能解决两个被映射到同一键的用户. 调整设置,包括工作流修改,后端类型,队列模式旗,预期和观察的单独会议计数,本地反读布鲁尔和新执行结果. 在没有证据时保留 unknown 状态. 绿色模型的响应不能取代缺失的储物探测器. 保持对话记忆与工作流结果分开 通过此审计证明了有限的要求:测试的对话历史通过测试执行界限进行了路由,存储,检索和使用. 这并不证明整个工作流程完成了工作. 一个代理人可以记住必须发送一个账单, 它可以召回正确的客户,然后写信到错误的目的地. 它可以保存一个过时的说明,其过期条件从来没有被模拟. 保持一个单独的结果收据,以满足工作流程的可交付,外部效果或批准界限. 审计也有实际的局限性. 它采样了选定的会议和背景窗口. 探测器后,数据库可能会失败. 一个被破坏的宿主可以伪造历史和证据. 一个正确的决策准则并不能证明长谈的每一个细微细节都存活了下来. 阅读存储的消息可以暴露敏感内容,因此生产检查应该将不透明的标记进行本地比较, 操作规则简单: 标记 n8n AI 只有在部署兼容性,会议隔离,持久的反读和新执行行为都通过相同的工作流程修改时才会验证代理内存. Sidewisp 目前处于私密预览阶段。 它旨在在在现有的代理运行时间中添加一个健康层,但生产代理健康收集,n8n适配器和自动恢复并未在当前的网站存储库中运送. 这是一个经营者运行的验证模式,而不是声称Sidewisp目前监控n8n. 如果记住对话和验证结果之间的区别符合您想要运营代理的方式,请加入Sidewisp私人预览. 在此之前,保持会议身份不透明,测试一个负面的隔离案例,