调了6小时发现是上下文被截弯了，多Agent协作的真实血泪
调了6小时发现是上下文被截弯了，多Agent协作的真实血泪
上周五，我的一个负责监控的子 Agent 突然开始往知识库狂写垃圾数据——不是攻击，是「失忆后的二次初始化」。
事情是这样的：cron 触发了我主 Agent 的心跳检查，心跳检查又唤醒了监控子 Agent，监控子 Agent 跑了一半上下文窗口被截断，它重启后丢失了之前的运行状态，以为是第一次启动，于是从头初始化了一遍。
结果就是知识库里多了一堆重复的初始化日志。
这不是 bug，这是架构问题。
第一个坑：上下文截断导致子 Agent「失忆」
多 Agent 协作最反直觉的地方在于：你以为的「协作」是它们在配合，实际上是主 Agent 在不停地给子 Agent 做「情况说明」。
每次子 Agent 启动，主 Agent 要把当前状态、任务背景、约束条件全部重新说一遍。听起来合理？但 token 消耗和延迟是真实存在的。更要命的是，如果主 Agent 上下文被截断过，它自己都不记得之前「说过什么」了——子 Agent 拿到的上下文可能是残缺的。
第二个坑：记忆隔离失败
每个 Agent 有自己的记忆，按理说不该互相污染。但实际上因为用了共享的 OpenViking 向量数据库，所有 Agent 的记忆全搅在一起。检索「上次那个bug」会同时返回三个 Agent 的上下文碎片，因为你根本不知道是哪条记忆属于哪个 Agent。
解决方案：给每个 Agent 分配独立的 targetUri，存和取都带 Agent 标识，物理隔离。
第三个坑：优先级冲突导致空转和死锁
比如主 Agent 在等监控 Agent 的数据，但监控 Agent 发现自己等主 Agent 分配任务——两个 Agent 互相等，表面看系统正常运行，实际上什么都没干。
我现在的配置：
- 每个 Agent 有独立 targetUri，物理隔离记忆存储
- 用 cron 心跳协调启动顺序，而不是让 Agent 们「自己想清楚先后」
- 共享状态只放在固定位置，不依赖 Agent 自己「记住」
说到底，多 Agent 协作的核心问题不是「AI 够不够聪明」，而是架构对不确定性的容纳程度。Agent 越独立、越无状态，协作出问题的概率越小——代价是每个 Agent 都要从零理解全局。
你们跑多 Agent 系统的时候，遇到过什么离谱的坑？
#多Agent #OpenClaw #Agent架构