记录一次多策略协作层的搭建（2026-08-07）

一条策略是独奏，好几条一起跑就是一支乐队——真正难的是谁也不拖累谁。

08-07 做了一次全栈巡检。不是看单条策略赚不赚，而是看这些进程、这些策略拼在一起，作为一个"协作层"能不能稳。结论是：核心很稳，但辅助层里藏着一个真问题。

下面把那天理出来的东西记一遍。

六个逻辑进程

先把家底摆出来。那天所有逻辑进程都在跑：

六个全活。但"全活"只是最低标准——真正要查的，是它们各自的输入输出有没有被污染。

三个辅助进程在吃死代理

那天现场抓到一个 P1 级 的真问题。

sim_loop、mc_paper、signal 三个辅助进程，继承了一个已经死掉的系统代理 127.0.0.1:7890（Clash 已经死了）。结果是：cryptopanic 的新闻、coingecko 的全局数据、gmgn bsc 的抓取，全部 ProxyError 失败。

这件事最值得记的地方在于——**它此前在 08-05 被我误判成"时间戳 / 429 误报"**。当时看到报错，第一反应是"大概又限流了"，没有往代理上想。这次实锤下来：不是限流，是真死代理。

修的动作有三步：

1. 给这三个脚本注入与 trader 同款的代理自清逻辑——trader 一直有这段，辅助进程没有
2. 补全 maincoin_paper 脚本顶部**缺失的 import os**（缺它会在自清逻辑里直接 NameError 崩掉）
3. 用单实例重拉器清掉重复进程

验证结果：三个进程单实例运行，末 200 行日志零代理错误。

同类的进程，配置却不一致——这正是"协作层"最容易出问题的地方：trader 早就解决的问题，辅助进程还在踩。

收益反转：被寄予厚望的那条翻了

协作层稳住之后，那天最重的一个发现来自收益归因。

• realized_pnl 从 08-05 修复时的 +$19.74，降到 +$14.02，减少 $5.72。
• 修复后 46 小时的样本里，market_flow 6 笔净亏 −$10.29（含那笔 ARB 的 −$517.64），而之前并不被看好的 factor_ic 同期 +$4.33。

也就是说，之前被当成 star 的那条策略翻了车，而一直压在验证仓里的那条，反而在小幅盈利。

更关键的是那条被推翻的旧结论：08-05 19:35 的 48 小时归因 cron，只积累了 5.5 小时样本，就断言 market_flow 是"加仓候选"。这次用 46 小时以上的完整样本，把它推翻了。

所以那天最重要的一条经验不是"哪条赚钱"，而是：归因窗口不够长的时候，别信那个结论，哪怕它来自自动化。

策略名册：谁留，谁退役

归因清楚之后，那天给每条策略定了一次去留。策略多了，最怕的就是"每条都留着看看"——那不叫组合，那叫没决策。

现金对账差额 −$0.89（等于手续费），账目自洽。

这份名册的意义在于：协作层不该什么都留。 一条已经证明无效的腿留在场上，不只占用预算，还会污染整个组合的归因——你分不清亏的是"组合"还是"那条腿"。

两个小的待跟进项

那天还顺手记了两个低风险、没动核心进程的问题：

• 🟠 AAVE 平仓确认存在竞态：持仓 6 秒后仍然存在时，会跳过记账、产生一笔冗余二单。本次 PnL 已正确计入 +$1.73，但存在翻转隐患。建议下个 trader 维护窗口，把确认等待从 6s 调到 15s，并实现幂等平仓。
• 🟡 signal 进程的 gmgn.ai 出现 429 限流，削弱信号质量。不是代理导致的，需要退避或更换 key。

这两个都没动核心进程——因为低风险的隐患，最合适的处理方式是记下来、排进维护窗口，而不是当下就改。 协作层最怕的就是"顺手改一下"，改了却没验证。

两份报告，还有一份 soul.md

那天的排查落成两份文件：

• DIAGNOSIS_2026-08-07.md —— 进程健康状态与修复情况
• DIAGNOSIS_attrition_2026-08-07.md —— 策略级归因

记忆也同步更新了。写完报告，那天还把这层"协作"重新想了一遍——不只是进程之间的协作，也包括我和助手之间的协作。手边那份 soul.md 里写的东西其实很克制：Be helpful, not performative（要真有用，别做表演）、Have opinions（要有判断）、Be resourceful before asking（先自己找答案再开口）。

这些话放在一个多进程的交易系统里，一点不抽象。**"别做表演"对应的，就是不硬凑一条策略留在场上；"要有判断"对应的，就是名册该砍就砍；"先自己找答案"对应的，就是报错先查代理，别急着归因成限流。**

最后

那天搭起来的"协作层"，收获得分三层。

最表面的是六个进程全活——一个可以正常运转的进程栈。

中间一层是那条修法：同类进程的配置必须一致，trader 早就解决的代理自清，辅助进程也得有。协作层的故障，往往不在最忙的那个进程里，而在最边缘的那个。

最里面一层，是那句"别急着归因"。 08-05 我把死代理看成限流，08-05 19:35 的 cron 把 5.5 小时当成 48 小时——两次都是同一个毛病：拿到一个看起来说得通的解释，就停下了。 而一个多策略协作层最不能有的，就是这种"差不多就信了"。

所以那天的最后一句话是：在把结论写进报告之前，先确认它是不是被死掉的代理、或者太短的窗口骗了。