工作代理是否应直接写入内存？一种我正测试的策展-代理模式

在搭建项目级内存所有者一段时间后，困扰我的问题变得更加细致。即使有项目范围编排器，工作代理仍然直接写入共享内存，存储库迅速被污染。临时猜测被保存为持久事实。特定于项目的决策最终出现在可复用的团队规则中。私有上下文泄露到公共工件中，因为工作代理不知道它正在写入哪个作用域。 我现在测试的模式在工作代理和内存存储之间放置了一个专门角色。工作代理完全不写入内存。它们发出带有建议作用域和证据的结构化内存事件。一个独立的内存策展代理对事件进行验证、修订、去重，并将其路由到四个作用域之一，或直接丢弃。 我使用的四个作用域是：代理仓库内存（单个代理的持久设计决策）、代理团队内存（跨代理流程、交接标准、安全规则）、项目内存（一个项目的当前状态、决策、风险）和会话暂存（可能不应保留的临时观察）。 我心中的映射是人类和组织记忆类别：个体专家记忆、交互性团队记忆（Ren和Argote）、项目记忆和短期工作记忆。 默认路由规则是保守的。如果事件是临时的、无支撑的、模糊的或私有的，则进入会话暂存或被丢弃。持久内存是挣来的，而不是自动的。 事件模式是JSON格式，包含事实、决策、偏好、风险、流程、假设的类型标签，以及证据引用和建议作用域。策展人可以覆盖建议的作用域，并且是持久存储的唯一写入者。 我认为这个模式所处的谱系包括：用于内存层次结构的MemGPT和MemoryBank，用于模块化和层次化代理内存的LEGOMem和AgentSys，以及用于将观察提炼为长期记忆的反思模式的Generative Agents。团队与个体区分的来源是组织研究中的交互记忆工作。 有两件事我不确定。第一，事件发出要求是否给工作代理增加了足够的摩擦，以至于它们开始要么过度发出（一切都成为候选事件），要么发出不足（工作代理悄悄停止费心，有用的观察丢失）。第二，路由准确性是否随着项目数量的增长而保持，因为在长时间会话中会话与项目的界限模糊，当一个项目的经验实际上具有普遍性时，项目与团队的界限模糊。 仓库：回复 好奇是否有人运行多代理设置尝试过类似方法。具体来说：你是让工作代理直接写入，然后稍后运行清理过程，还是通过策展人预先控制写入？事后清理在操作上更容易，但我怀疑污染积累的速度快于被清除的速度。