Agent 已经能查日志、读代码、整理线索、提出假设。但在真实工程现场，关键判断从来不只来自一个人。Memoria 想展示的是：如何用共享记忆，把 Oncall、Dev、Ops 和团队经验接入同一个协作回路。
过去，我们常说 Human in the Loop：模型输出结果，人来检查、纠正、确认。
但在复杂排障里，这个 “Human” 往往不是一个人，而是一整个团队。
Oncall 有第一现场，Dev 有模块经验，Ops 有业务操作记录，其他同事也会根据历史经验判断哪条线索更值得继续追。真正有价值的，不只是某一次对话里的答案，而是团队如何一起决定：哪些事实值得沉淀，哪些推断还需要验证，下一位接手的人如何不从零开始。
这正是 Memoria 要解决的问题：让团队里的每一次判断、每一次修正、每一次确认，都可以进入一个可审查、可回滚、可接力的共享记忆工作流。
从 Human in the Loop 到 Team in the Loop
很多 Agent 产品里的 Human in the Loop，更像是“一个用户 + 一个 Agent”的来回对话。
这当然适合个人助手，但并不完全适合工程团队。
因为真实排障很少是一个人从头查到尾。一次线上问题里，可能是 Oncall 先发现异常，群里同事判断方向，熟悉模块的 Dev 接手深挖，最后 Ops 从业务侧补上关键证据。每个人都掌握一部分上下文，也都拥有不同的判断能力。
从 Agent 的视角看，这些人有点像一组“人类 subagent”：每个人都带着不同的经验、权限和确认机制。
- Oncall 负责打开现场
- Dev 负责理解系统逻辑
- Ops 负责核对外部事实
- 团队成员负责审查证据强度
Memoria 做的不是让 Agent 绕过人，而是让这些人的经验不再散落在聊天记录里。它把团队判断接入同一条记忆链路：可以先探索，可以再审查，可以只把确认过的事实写入主线。
这篇 demo 改编自一次真实 debug：dev 环境升级后出现异常，部分应用无法连接。重点不是“Agent 自动找出根因”，而是 Oncall、团队同事、Dev 和 Ops 如何围绕同一份共享记忆完成接力确认。
下面这 5 段动画，会把这条协作链路拆开来看：一个人打开现场，一群人审查上下文，一个人接手深化，最后由拥有外部事实的人完成确认。
Scene 1：Oncall 打开现场
故事从一个很普通的 oncall 输入开始：
昨晚升级之后，dev 集群不太正常，有些应用连不上。
真实排障往往就是这样开始的：信息不完整，现象不清晰，但问题已经发生。
Agent 首先帮 Oncall 把现场展开：
- 定位异常环境
- 收窄时间窗口
- 汇总连接失败、锁、事务等信号
- 形成一个阶段性解释
这个解释不是最终答案，但它给团队提供了一个可以讨论的起点。
这里最重要的设计，不是 Agent 猜得有多快，而是：早期探索先进入临时分支，而不是直接写入团队主线。
分支让 Agent 可以大胆串线索，也让团队保留审查空间。真实排障一定会有中间态，而中间态既值得记录，也必须有边界。
Scene 2：团队进入上下文
Oncall 把阶段性判断同步到群里后，协作真正开始。
A 关注事务方向，B 提醒大家区分“现象”和“原因”，Dev 则注意到升级状态里那个“差一个”的异常点，认为它更值得继续追。
这不是简单的“谁对谁错”，而是团队经验开始共同作用在同一份上下文上。
第一轮调查提供材料，群里的讨论帮助团队判断：
- 哪些内容可以沉淀
- 哪些还只是阶段性推测
- 谁更适合接着查
- 哪条线索更值得投入
这就是 Team in the Loop 的价值。Agent 的输出没有被直接接受，也没有被直接否定，而是被放进团队经验里重新评估。
Human in the Loop，不再只是一个人点确认，而是一群人共同校准上下文。
Scene 3：只把事实写入共享记忆
接下来，Oncall 回到 Agent，让它列出准备写入的 memories。
这一步非常关键：里面既有事实，也有伴随现象，还有因果推断。团队最后决定，只把最适合交给下一位同事的内容写入主线：时间、环境、实例，以及那个异常升级状态。
换句话说，Memoria 并不是“自动总结所有内容”。
它更像一个记忆工作流：
Branch → Diff → Review → Apply → Main先放在分支里，再看差异，最后只把团队认可的事实 apply 到 main。
这让“Agent 到底靠不靠谱”这个抽象问题，变成了一个更具体的问题：这条新增记忆到底是什么？是事实、现象，还是推论？
不同类型的内容，可以有不同去处。
Main 保存的是团队认可的事实，而不是所有看起来合理的猜测。
Scene 4：Dev 接手继续推进
接下来，熟悉相关模块的 Dev 接手。
他不需要从头问背景，也不需要翻完整聊天记录，而是启动一个新的 Code Agent，从共享记忆里拿到已经确认过的事实。
然后，Dev 基于 main 创建新的调查分支，并行验证两个方向：
- 主线：升级期间是否发生过租户操作
- 支线：事务和锁异常是否能独立解释现场
这不是为了展示“多 Agent 很酷”，而是为了让不同假设各自有边界。
事务和锁这条线能解释后续放大现象，但解释不了最核心的“差一个”。租户操作这条线更能解释核心状态。于是 Dev discard 掉低价值分支，把注意力收敛到更可能的方向上。
这也是 Memoria branch 的另一层价值：探索可以被启动，也可以被干净地丢弃。
不是每条调查路径都值得进入团队记忆。有些分支最大的价值，就是帮团队确认：这条路不够解释核心问题。
Scene 5：Ops 补上最后一块事实
技术侧能看到迹象，但业务操作记录在 Ops 那里。
Dev 可以说“看起来像”，但最终还需要 Ops 从业务侧确认：那段时间到底有没有发生租户删除操作。
于是 Dev 把 Memoria 分支名交给 Ops，Ops 带着这条时间线去核对业务侧日志。很快，Ops 确认：业务侧记录里确实删除了 3 个租户，时间也对得上。
到这里，问题才从技术侧的强迹象，变成跨角色确认过的事件链。
这一步说明了一个很现实的事实：复杂排障里的“真相”往往分布在不同系统、不同角色、不同权限里。日志只能解释一部分，代码只能解释一部分，业务记录也只能解释一部分。
Memoria 的价值，不是把这些线索强行融合成一个漂亮故事，而是让拥有不同事实来源的人，可以快速接入同一条调查分支。
单人对话很难覆盖所有事实来源。共享记忆让 Ops 不必从头听事故复盘，而是直接接入已经整理好的上下文。
Memoria 扩展的不是记忆容量，而是协作回路
这个 demo 想表达的，不是“Agent 取代人”，也不是“模型自动记住所有东西”。
我们真正关心的是：当 Agent 进入工程工作流之后，团队如何共同决定什么值得被记住。
在这个故事里：
- Oncall 负责打开现场
- 群里同事负责审查和收敛
- Dev 负责基于模块经验继续推进
- Ops 负责补上业务侧事实
- Memoria 负责把这些贡献沉淀为团队可以 diff、review、apply 和 rollback 的共享上下文
过去是：
一个人 + Agent现在是：
一个团队 + Agent这听起来不如“全自动查根因”刺激，但更接近真实工程工作的样子。
Agent 负责加速探索，人负责判断、补充和确认，Memoria 负责把这些贡献沉淀为团队可以继续使用的上下文。
这就是我们想展示的 Team in the Loop：不是让人站在最后点一下确认，而是让团队里的每一种经验，都能成为 Agent 工作流的一部分。
如果你也在思考：当 Agent 进入真实工程工作流之后，团队记忆应该如何被记录、审查、接力和回滚，欢迎来体验 Memoria。
Memoria 是面向 AI Agent 的共享记忆基础设施，让团队可以像管理代码一样管理 Agent 记忆：Branch、Diff、Review、Apply、Rollback，让每一次关键判断都有上下文、有边界、可追溯。
👉 访问官网，了解更多并开始体验：<https://thememoria.ai/>