From 5e015f680e4b7ef41b9e7319a4e4b336850207db Mon Sep 17 00:00:00 2001 From: zlt Date: Fri, 28 Aug 2026 09:51:45 +0800 Subject: [PATCH] =?UTF-8?q?=E5=A4=84=E7=90=86pms=E7=B3=BB=E7=BB=9F?= =?UTF-8?q?=E5=AF=B9=E6=8E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/选股计划入池_对接说明.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/选股计划入池_对接说明.md b/docs/选股计划入池_对接说明.md index 2bb461f..eb2a467 100644 --- a/docs/选股计划入池_对接说明.md +++ b/docs/选股计划入池_对接说明.md @@ -98,3 +98,28 @@ docker compose exec -T akg-factor-bridge python run.py push-pool 出现 SELL/AVOID 的闲置票进回收站，且决策系统随后把它们标 DROPPED。 判收纪律照旧：代码就绪 ≠ 接通 ≠ 判收。判收 = 上面这四条在实机各看到一次。 + + +## 7. 池深与 PMS 下单候选的关系（2026-08-27 查明并定稿） + +这一节回答一个真问题：一只票能被 PMS 下单、却不在本分析池里，是不是出错了。答案是不出错，但两边的深度本来该对齐，这次把它对齐了。 + +先分清两个深度，它们同源，但不是一回事。 + +一个是本分析池的深度，参数是 POOL_TOP。它决定决策系统每晚深度分析多少只票，一只约两三分钟。 + +另一个是 PMS 的下单候选深度，参数是 PMS_PLAN_TOP_N，在 tradingSystem 的 config/settings.py 里。PMS 建仓不读本 Mongo 池，而是直接调选股计划接口 plan_api，取主榜按分数前 PMS_PLAN_TOP_N 名，作为真正的下单候选。 + +问题出在两个深度不一致。改之前 POOL_TOP 是 20，PMS_PLAN_TOP_N 是 30。于是主榜第 21 到 30 名的强传导票，PMS 能下单，却不在本分析池里，买它们的时候没有当晚的支撑压力位和定性结论托底。有个缓冲：买入即成持仓，而持仓永远进池，所以当晚池子重建后会补上分析。但买入当天到当晚那一段，是没有夜间结论的。2026-08-27 的 688599（天合光能，主榜第 25 名，强传导）正是这情形。那天它还叠了一层：自动闸先判拒，理由是资金净流出、无盘中买入信号、证据不足，随后被页面人工裁决改成通过并成交，所以那一笔是人工强下的，不是自动越界。 + +用户拍板：本分析池要做成 PMS 下单候选的超集。这样能买的票一定先在夜间被分析过，用户也能观察到更宽的一批。 + +要长期守的不变式：POOL_TOP 必须不低于 PMS_PLAN_TOP_N。日后在 PMS 侧调大 PMS_PLAN_TOP_N，必须同步把这里的 POOL_TOP 调到不低于它，否则「能买、没分析」的缺口又会回来。 + +本次取值：POOL_TOP 由 20 提到 50，盖住 30 名的候选，另留 20 只强传导做观察；POOL_MAX 由 60 提到 100，容纳更深的计划加持仓加留池观察。 + +成本要心里有数：夜间每只全量分析约两三分钟，POOL_MAX 决定夜扫总时长。100 只大约四小时，22:30 起约次日 02:40 完，仍在早上 08:40 盘前拉计划之前。嫌久就把 POOL_MAX 调小。 + +自动维护：入池、留池、出池由 pool.push() 每天在盘前链里维护，持仓永不出池，掉榜但形态没恶化的票留在池里继续观察，形态恶化的进回收站。名单不需要手工维护。 + +参数在哪：POOL_TOP 和 POOL_MAX 在 akg-factor-bridge 的 .env 里；PMS_PLAN_TOP_N 在 tradingSystem 的 config/settings.py 里，也可被 PMS 的 param_store 覆盖。改完 .env 要重建容器让新值生效，见第 5 节部署，注意 restart 不重读 env。