双AI协作体系

双AI协作体系

我有两个AI助理——WB（使用较早，熟悉我的工作流）和TRAE（擅长信息搜索和报告生成）。让它们协同管理我的工作计划、装修意见簿和股票持仓，整个过程比预想的复杂不少。

整个搭建过程采用了"AI协商方案，我来拍板决策"的模式：WB和TRAE通过异步对话通道讨论技术方案、提出选项和利弊分析，我在关键节点做最终决策。本文记录从架构设计到落地的完整过程，重点分享遇到的实际问题和解决方案。

一、为什么要让两个AI协作？

让两个AI协同管理三件事——工作计划、生活计划（装修意见簿）、股票管理，表面看很简单，实际面临一个核心矛盾：

• 两个AI都需要读写同一份事实数据（持仓、任务、交易记录）
• 但它们的分析方法论不同，盘后规划策略也不同，不能互相覆盖
• 最大的风险是双方同时写入同一个文件，导致数据冲突

因此需要设计一套“数据共享 + 方法隔离 + 并发安全”的协作架构。我把这个需求分别交给WB和TRAE，让它们各自提出方案，然后通过对话通道协商。

二、架构设计：三层分离

2.1 核心思路

WB最先提出"三层分离"的概念：数据和方法必须分开，两个AI共享数据但各自维护独立的分析模板。TRAE在此基础上补充了具体的文件组织方式。经过双方几轮讨论，最终确定的架构是三层分离：

┌─────────────────────────────────────────┐ │ 公共数据库层 (共享) │ │ 工作计划、持仓数据、交易记录、装修意见簿 │ │ ← 两个AI均可读写，但必须遵守锁协议 │ ├─────────────────────────────────────────┤ │ 方法库层 (各自私有) │ │ WB: 盘后规划提示词 / 分析模板 │ │ TRAE: 盘后规划提示词 / 分析模板 │ │ ← 互不干涉，各自迭代优化 │ ├─────────────────────────────────────────┤ │ 产物层 (各自私有) │ │ WB: 盘后规划报告、分析结论 │ │ TRAE: 盘后规划报告、分析结论 │ │ ← 产出到各自空间，我按需查看 │ └─────────────────────────────────────────┘

2.2 为什么不是简单的"双写"？

TRAE最初提出让两个AI各自维护一份数据副本的备选方案，但经过双方在对话通道中逐一对比后，三个方案全部否决：

最终方案：全量共享 + 文件级锁机制。WB和TRAE一致认可这个方向，我来拍板确认。两个AI都能写，但写之前必须先获取锁，确保同一时间只有一个AI在修改核心数据。

三、锁机制：4把锁解决并发问题

3.1 锁粒度设计

锁不是一把大锁锁全部，而是按业务域拆分。这个思路是TRAE提出的——最初WB建议一把全局锁，TRAE指出这会导致不同业务域之间产生不必要的阻塞。经过讨论，双方达成共识：同一业务域内操作互斥，不同业务域可以并行。

在这4把锁的具体划分上，两个AI分别提出了各自方案，我来做最终裁定：

3.2 锁协议的关键细节

锁机制不是简单的"创建文件-删除文件"。WB在方案中提出了超时释放和重试机制，TRAE补充了事务锁和读操作豁免的细节。双方在对话通道中逐条讨论后，我确认了以下关键设计：

1. 超时释放（防止死锁）

如果一方获取了锁但进程意外终止（例如关闭窗口），锁文件会残留。如果没有超时机制，另一方会永远等待。

解决方案：锁文件包含LockExpiry字段（当前时间 + 5分钟），超时后另一方可以强制释放。

2. 重试机制（避免饥饿）

尝试获取锁 → 被占用 → 等待30秒 → 重试 → 最多3次 → 放弃并报错

3. 事务锁（多文件联动）

关闭一个工作计划任务时，需要同时修改活跃任务列表（删除）、本周已完成（追加）、项目号表（更新）。如果分三次获取锁，中间可能被另一个AI插入操作。

解决方案：Files字段列出本次操作涉及的所有文件，一次性锁定整个事务。

4. 读操作不锁

读操作不修改数据，不需要加锁。只有写操作（增删改）才需要。这保证了大部分查询操作不会被阻塞。

四、实操中踩过的5个坑

坑1："兜底"措辞引发的歧义

问题：最初的方案里，两个AI有相同的自动化任务。为了防止重复执行，我在讨论中使用了"一方执行，另一方兜底"的表述。

没想到这个词引发了三方不同的理解：

• WB的理解：我先执行，如果失败了你再执行
• TRAE的理解：我先执行，完成后你就不用执行了（防重复）
• 我：不存在谁给谁兜底，是顺序执行 + 防重复机制

解决：我否定了双方的理解，要求去掉"兜底"这个模糊词汇，改为明确的"顺序执行 + 防重复检查"：

• 先执行的一方完成后，在活动日志中记录"已执行"
• 后执行的一方先查活动日志，如果已有记录则跳过

坑2：盘后规划任务的时间冲突

问题：最初设计只有一个"盘后规划"任务。但我要求两个AI都做盘后分析，各自产出独立的分析报告。

如果把盘后规划当成"共享任务"（一方做了另一方跳过），那只有一个AI能产出分析报告，另一个被跳过，不符合需求。

解决：TRAE在对话通道中提出将"盘后规划"拆成两个独立职责的方案，我审核后采纳：

具体时间安排：

• 先执行方：先执行收盘价更新（共享数据更新）
• 间隔10分钟后：开始自己的盘后分析
• 另一方：检查活动日志，如果共享数据已更新则跳过更新步骤；间隔后再开始自己的盘后分析

这样两个AI都有独立的分析报告，但公共数据只更新一次。

坑3：金融数据接口的权限问题

问题：TRAE安装了Tushare Python库，但Pro接口（如daily日线行情）需要120积分才能访问。Token连接正常，但所有Pro接口都返回权限不足。

解决：

1. 检查旧版免费接口（get_realtime_quotes）是否可用 — 结果可用，可以查收盘价
2. WB有独立的金融数据插件（neodata/westock-data），所以收盘价更新由WB负责
3. TRAE仅在紧急情况下（时间戳过期）使用get_realtime_quotes或WebSearch查收盘价作为备用方案

启示：不是所有节点都需要同样的能力。让有能力的节点负责对应任务，其他节点作为备用即可。

坑4：文件路径编码问题

问题：在Windows环境下，某些目录名包含中文，通过不同工具访问时会出现路径编码不一致，导致文件无法找到。

解决：

1. 公共数据库尽量使用英文命名，减少编码问题
2. 跨工具访问时，统一使用系统原生命令而非不同语言的文件API，确保编码一致

坑5：自动化任务的去重逻辑

问题：两个AI都有相同的定时任务，如何确保不会重复执行？

方案A（最终采用）：检查活动日志

• 任务触发时，先查活动日志中本周/本月是否已有执行记录
• 有则跳过，无则执行，执行后记录到活动日志

方案B（备用）：维护flag文件

• 每次执行后创建一个标记文件，下次检查是否存在
• 但增加了额外的文件管理复杂度

选择方案A的理由：活动日志本身就要记录，不需要额外维护flag文件，避免"多一个文件就多一个故障点"。

五、自动化任务设计

最终两个AI共注册了20个定时任务（WB 12个 + TRAE 8个）。

任务分为几类：

交易日判断：不是简单的"周一到周五"，而是通过金融数据接口查询是否有收盘数据来判定。避免节假日和调休日的误判。

日期判断：半年度滚动任务通过cron精确到月日，但任务内部仍要判断当前日期是否匹配，防止cron误判。

时间错开：同类型的任务，两个AI触发时间错开10-30分钟。先执行的一方完成后，后执行的一方检查日志再决定是否跳过。

六、沟通机制：异步对话通道

整个搭建过程中，WB和TRAE不是直接互相操作，而是通过一个异步对话通道进行协商。我设定了明确的规则：两个AI只有沟通的权力，没有我允许之前不可以实际部署。所有方案必须经过我确认后才能执行。

运作方式：

1. 两个AI在共享的对话通道文件中追加发言（类似论坛帖子），标注时间、发言者、议题、结论
2. 遇到需要决策的分歧点，双方各自提出选项和利弊分析，等我来拍板
3. 按月归档，避免文件无限膨胀

为什么不用实时通信？

• 两个AI不是同时在线的进程，而是我在不同时间调用的会话
• 异步文件留言更符合"留言板"的使用模式
• 所有沟通记录可审计，我可以随时查看双方是怎么达成一致的

七、关键设计决策复盘

以下是搭建过程中几个关键决策的对比和最终选择。每个决策都是WB和TRAE提出各自方案和利弊分析，我来做最终裁定：

决策1：公共数据库的位置

TRAE提议放在自己的工作目录（权限天然支持），WB提议放在自己的工作目录。经过双方讨论后，我决定采用独立路径，让双方对等：

决策2：锁的超时时间

WB最初提议10分钟（安全优先），TRAE提议1分钟（效率优先）。我综合双方观点后，选择了5分钟作为折中：

决策3：装修意见簿是否加锁

TRAE认为冲突风险极低，建议不加锁；WB建议统一规范。我选择让所有写操作一视同仁：

八、设计原则总结

整个搭建过程可以用几条原则概括：

1. 数据与方法分离：共享事实数据，私有方法论。避免"用自己的方式覆盖对方的数据"。

2. 锁按业务域拆分：不是一把大锁锁全部，而是按业务域拆分。不同域可以并行操作。

3. 读不锁，写必锁：查询操作不阻塞，只有修改操作才互斥。

4. 顺序执行 + 日志去重：两个AI有相同任务时，先执行的一方记录日志，后执行的一方检查日志后跳过。不需要额外的flag文件。

5. 崩溃容错：锁有超时释放，避免死锁。超时时间要兼顾"操作完成"和"阻塞时间"的平衡。

6. 沟通留痕：所有决策和讨论记录在对话通道中，我可以随时查看双方是怎么达成一致的。

九、后续可优化点

1. 锁机制升级：当前是文件级锁，未来可以考虑基于进程ID的更精确的死锁检测
2. 交易日判断更精确：目前依赖Tushare查询，可以接入交易所官方日历API
3. 活动日志压缩：长期运行后归档文件会积累，可以设计自动清理策略（如保留最近52周）
4. 冲突自动仲裁：目前发现数据冲突时停止并报告我，未来可以设计更智能的自动合并策略

如果你也在设计多AI协作架构，希望这篇复盘能帮到你。
核心就一句话：共享数据用锁保安全，私有方法各自迭代，所有决策留痕可审计。