在多智能体设置中，持久化记忆应该存放在哪里？一个小型研究框架

在运行了几个月涉及AI智能体的长期项目后（有些项目持续数周，多个专业智能体处理相同的文件），我反复遇到相同的失败模式。专业智能体在其狭窄任务上表现良好，但项目记忆却崩溃了。第一周做出的决定到第四周就遗失了。被否决的选项悄悄复活。'单一真相来源'总是当前打开的聊天窗口。我开始研究那些已经进行了数十年长期工作的地方如何处理这个问题。咨询公司运营持续数月、人员轮换的项目，他们通过转型办公室或项目管理办公室（PMO）来维持：节奏、决策日志、风险登记册、一个规范的当前状态工件、一位参与经理来框定问题并委派工作流。有趣的部分是运营模式，而不是咨询表演。还有相关的学术线索。Kasvi等人（2003）区分了项目记忆（可用于指导当前工作的知识）与项目记忆系统（存储、检索、传播、使用）。Mariano和Awazu（2024）将项目记忆视为一种主动实践而非存储库。在LLM方面，Anthropic的多智能体研究系统、OpenAI Agents SDK的交接模式，以及最近的工作如LEGOMem和AgentSys，都指向了具有层级或模块化记忆的编排者-工作者模式。我提出的假设很狭隘。持久化记忆应该归属于项目所有者。任务专家应接收最小化、限定的上下文。持久化的单位是项目文件夹，而不是对话。一个持久的'项目经理灵魂'维护规范记忆，框定模糊请求，分解工作，为专业智能体编写简洁的交接简报，验证返回的工作，并且只将基于证据的事实写入记忆。该仓库是一个研究框架，而非验证过的结果。它包含一个智能体合约、记忆文件和交接简报的模板、带有来源的咨询工作流图、一个案例研究，以及一个评估准则（重复上下文事件、交接简报长度、决策闭合时间、专业智能体重做循环等）。下一步是在实际项目上进行一周的现场试验，然后再做出任何断言。我最希望收到反馈的是记忆边界。当前规则是专业智能体看不到完整的项目历史，只看到交接简报和它们需要的文件。我不确定这在什么地方会出问题。我怀疑，在专业智能体需要知道之前选项被否决原因的任务中，简报会悄悄增长，直到再次成为完整的记忆。好奇是否有人遇到过这种情况，或者以不同的方式解决了它。