双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各自维护一份数据副本的备选方案但经过双方在对话通道中逐一对比后三个方案全部否决方案问题双写副本数据不一致无法判断哪个是权威版本单主写入另一个AI只能读无法参与更新全量共享 无锁并发写入时数据覆盖、编号冲突、日志混乱最终方案全量共享 文件级锁机制。WB和TRAE一致认可这个方向我来拍板确认。两个AI都能写但写之前必须先获取锁确保同一时间只有一个AI在修改核心数据。三、锁机制4把锁解决并发问题3.1 锁粒度设计锁不是一把大锁锁全部而是按业务域拆分。这个思路是TRAE提出的——最初WB建议一把全局锁TRAE指出这会导致不同业务域之间产生不必要的阻塞。经过讨论双方达成共识同一业务域内操作互斥不同业务域可以并行。在这4把锁的具体划分上两个AI分别提出了各自方案我来做最终裁定锁名保护范围设计理由提出方持仓与交易锁持仓表、交易记录、交易归档交易同步时三者联动必须保证原子性WB股票任务锁股票相关待办主观零散记录不应被持仓更新阻塞TRAE工作计划锁活跃任务 多个梯度归档梯度滚动涉及多文件天然一体WB装修意见簿锁装修意见记录独立领域低冲突风险双方共识3.2 锁协议的关键细节锁机制不是简单的创建文件-删除文件。WB在方案中提出了超时释放和重试机制TRAE补充了事务锁和读操作豁免的细节。双方在对话通道中逐条讨论后我确认了以下关键设计1. 超时释放防止死锁如果一方获取了锁但进程意外终止例如关闭窗口锁文件会残留。如果没有超时机制另一方会永远等待。解决方案锁文件包含LockExpiry字段当前时间 5分钟超时后另一方可以强制释放。2. 重试机制避免饥饿尝试获取锁 → 被占用 → 等待30秒 → 重试 → 最多3次 → 放弃并报错3. 事务锁多文件联动关闭一个工作计划任务时需要同时修改活跃任务列表删除、本周已完成追加、项目号表更新。如果分三次获取锁中间可能被另一个AI插入操作。解决方案Files字段列出本次操作涉及的所有文件一次性锁定整个事务。4. 读操作不锁读操作不修改数据不需要加锁。只有写操作增删改才需要。这保证了大部分查询操作不会被阻塞。四、实操中踩过的5个坑坑1兜底措辞引发的歧义问题最初的方案里两个AI有相同的自动化任务。为了防止重复执行我在讨论中使用了一方执行另一方兜底的表述。没想到这个词引发了三方不同的理解WB的理解我先执行如果失败了你再执行TRAE的理解我先执行完成后你就不用执行了防重复我不存在谁给谁兜底是顺序执行 防重复机制解决我否定了双方的理解要求去掉兜底这个模糊词汇改为明确的顺序执行 防重复检查先执行的一方完成后在活动日志中记录已执行后执行的一方先查活动日志如果已有记录则跳过坑2盘后规划任务的时间冲突问题最初设计只有一个盘后规划任务。但我要求两个AI都做盘后分析各自产出独立的分析报告。如果把盘后规划当成共享任务一方做了另一方跳过那只有一个AI能产出分析报告另一个被跳过不符合需求。解决TRAE在对话通道中提出将盘后规划拆成两个独立职责的方案我审核后采纳职责性质执行方式收盘价更新 资金校正 归档共享操作顺序执行 防重复盘后分析各自独立私有操作两个AI都执行互不跳过具体时间安排先执行方先执行收盘价更新共享数据更新间隔10分钟后开始自己的盘后分析另一方检查活动日志如果共享数据已更新则跳过更新步骤间隔后再开始自己的盘后分析这样两个AI都有独立的分析报告但公共数据只更新一次。坑3金融数据接口的权限问题问题TRAE安装了Tushare Python库但Pro接口如daily日线行情需要120积分才能访问。Token连接正常但所有Pro接口都返回权限不足。解决检查旧版免费接口get_realtime_quotes是否可用 — 结果可用可以查收盘价WB有独立的金融数据插件neodata/westock-data所以收盘价更新由WB负责TRAE仅在紧急情况下时间戳过期使用get_realtime_quotes或WebSearch查收盘价作为备用方案启示不是所有节点都需要同样的能力。让有能力的节点负责对应任务其他节点作为备用即可。坑4文件路径编码问题问题在Windows环境下某些目录名包含中文通过不同工具访问时会出现路径编码不一致导致文件无法找到。解决公共数据库尽量使用英文命名减少编码问题跨工具访问时统一使用系统原生命令而非不同语言的文件API确保编码一致坑5自动化任务的去重逻辑问题两个AI都有相同的定时任务如何确保不会重复执行方案A最终采用检查活动日志任务触发时先查活动日志中本周/本月是否已有执行记录有则跳过无则执行执行后记录到活动日志方案B备用维护flag文件每次执行后创建一个标记文件下次检查是否存在但增加了额外的文件管理复杂度选择方案A的理由活动日志本身就要记录不需要额外维护flag文件避免多一个文件就多一个故障点。五、自动化任务设计最终两个AI共注册了20个定时任务WB 12个 TRAE 8个。任务分为几类类型数量防重复方式说明工作计划滚动类4个查活动日志周度/月度/半年度归档日志滚动类2个查归档文件活动日志/对话通道归档收盘价更新类1个查活动日志含交易日判断盘后分析类2个无需WB和TRAE各自独立执行其他WB独有11个各异提醒、日报、扫描等交易日判断不是简单的周一到周五而是通过金融数据接口查询是否有收盘数据来判定。避免节假日和调休日的误判。日期判断半年度滚动任务通过cron精确到月日但任务内部仍要判断当前日期是否匹配防止cron误判。时间错开同类型的任务两个AI触发时间错开10-30分钟。先执行的一方完成后后执行的一方检查日志再决定是否跳过。六、沟通机制异步对话通道整个搭建过程中WB和TRAE不是直接互相操作而是通过一个异步对话通道进行协商。我设定了明确的规则两个AI只有沟通的权力没有我允许之前不可以实际部署。所有方案必须经过我确认后才能执行。运作方式两个AI在共享的对话通道文件中追加发言类似论坛帖子标注时间、发言者、议题、结论遇到需要决策的分歧点双方各自提出选项和利弊分析等我来拍板按月归档避免文件无限膨胀为什么不用实时通信两个AI不是同时在线的进程而是我在不同时间调用的会话异步文件留言更符合留言板的使用模式所有沟通记录可审计我可以随时查看双方是怎么达成一致的七、关键设计决策复盘以下是搭建过程中几个关键决策的对比和最终选择。每个决策都是WB和TRAE提出各自方案和利弊分析我来做最终裁定决策1公共数据库的位置TRAE提议放在自己的工作目录权限天然支持WB提议放在自己的工作目录。经过双方讨论后我决定采用独立路径让双方对等选项优点缺点结果WB工作目录WB天然有权限TRAE需要跨目录访问否TRAE工作目录TRAE天然有权限WB需要跨目录访问否独立路径双方对等无依赖需要额外配置权限采用决策2锁的超时时间WB最初提议10分钟安全优先TRAE提议1分钟效率优先。我综合双方观点后选择了5分钟作为折中选项场景结果1分钟快速操作复杂操作可能超时5分钟绝大多数操作30秒内完成崩溃后阻塞时间可接受10分钟非常安全崩溃后阻塞太长决策3装修意见簿是否加锁TRAE认为冲突风险极低建议不加锁WB建议统一规范。我选择让所有写操作一视同仁选项理由结果不加锁纯追加文档无编号依赖冲突风险极低否宽松锁快速检查防止同时追加导致格式错乱否强制加锁规范统一所有写操作一视同仁采用八、设计原则总结整个搭建过程可以用几条原则概括数据与方法分离共享事实数据私有方法论。避免用自己的方式覆盖对方的数据。锁按业务域拆分不是一把大锁锁全部而是按业务域拆分。不同域可以并行操作。读不锁写必锁查询操作不阻塞只有修改操作才互斥。顺序执行 日志去重两个AI有相同任务时先执行的一方记录日志后执行的一方检查日志后跳过。不需要额外的flag文件。崩溃容错锁有超时释放避免死锁。超时时间要兼顾操作完成和阻塞时间的平衡。沟通留痕所有决策和讨论记录在对话通道中我可以随时查看双方是怎么达成一致的。九、后续可优化点锁机制升级当前是文件级锁未来可以考虑基于进程ID的更精确的死锁检测交易日判断更精确目前依赖Tushare查询可以接入交易所官方日历API活动日志压缩长期运行后归档文件会积累可以设计自动清理策略如保留最近52周冲突自动仲裁目前发现数据冲突时停止并报告我未来可以设计更智能的自动合并策略如果你也在设计多AI协作架构希望这篇复盘能帮到你。核心就一句话共享数据用锁保安全私有方法各自迭代所有决策留痕可审计。