24 KiB

Raw Blame History

方案（定稿）：给动作引擎加「新建仓」动作

V3，2026-08-06。四条取舍已拍板；决策系统侧已评估；按「不影响原有业务系统」这条原则重新过了一遍，改掉与补上的地方见第三节。待你点头即可动手。 全部依据来自实际代码，不引用设计文档的结论。部署：PMS 源码打进镜像，改码必须 make deploy，跑完 make test 见 ALL SUITES PASS；决策系统挂载卷，git pull 后 docker compose restart backend-api worker-brain 即可。

〇、拍板结果

#	问题	决定
1	档位	单独一个开关，默认开启。新建仓不跟随全局档位，自己一个参数，默认自动执行
2	每日节流	不做。逻辑进逻辑出，由既有的上限、资金、候选池与择时自己收敛
3	研判闸	这一轮一并加上，双侧改到位
4	漂移防护	做，首答锁定加偏离即停

一、动别的系统之前先问的三件事（新立的规矩）

决策系统本来就不管仓位——它是一套聚合了大量信号的判断系统，仓位是 PMS 的活。往它里面塞仓位信息，最容易出的事不是这次的功能不好用，而是把别的、已经在跑的逻辑带偏。所以凡是改 tradingSystem 以外的系统，动手前先答这三题，答不上就先别动：

这段代码是不是只有我这条路径会走到？ 如果是共用的（提示词模板、裁决解析、上下文组装、配置项），就不能在里面加只对我有意义的分支。
我加进去的字段，会不会被别的逻辑读到并当真？ 尤其是写共享表、写共享缓存、往共享 context 里塞键。
我的东西全删掉，原系统能不能一字不差地回到今天？ 答不上「能」，就说明它不是加法。

按这三题重新核过这次的决策系统改动，见下一节。

二、决策系统侧：三处改动全部落在 PMS_JUDGE 块内

结论先说

workers/tasks_intraday.py 的 process_intraday_audit 是一个按 direction 分流的大函数。 PMS 相关的代码本来就已经被圈在两段 if direction == "PMS_JUDGE": 里面（第 439 到 523 行的入口与素材段，第 632 到 656 行的收口与出口段）。 我要改的三处，全部在这两段之内，一行都不碰共用代码。

改什么	在哪	是不是共用
加一条 OPEN 建仓判据	第 495 到 511 行的 `_task_by_action` 字典	不是。这个字典整个定义在 PMS_JUDGE 块内，别的 direction 看不见它
OPEN 且现价缺失时回不可用	第 449 到 456 行现价链路之后，块内早退	不是。早退返回的结构与既有 UNAVAILABLE 出口同形
边界声明按动作分岔	第 513 到 514 行的 `core_task +=`	不是。`core_task` 只在 PMS_JUDGE 块内被赋值

不碰的东西，逐条点名：第 557 到 576 行那个所有 direction 共用的提示词模板不动；第 579 到 590 行共用的裁决解析不动；第 530 到 555 行的资金分布与板块动量注入不动（PMS_JUDGE 本来就在它们的白名单里）；decision_ledger 一个字不写（每晚判分是全表扫描，写进去会污染既有功能，这条第一版就核实过）； config/settings.py 不加任何字段。

留痕仍然只写 strategy_audit_log，verdict 列仍然只有 PMS_PASS / PMS_REJECT / PMS_UNAVAILABLE 三个值——不新增第四种。而 pms_advisor._today_exit_verdict 读这张表时明确跳过 PMS_ 开头的行（第 102 行），所以我们写进去的东西不会反过来影响择时应答。

「全删掉能不能回到今天」这一题的答案是能：把 _task_by_action 里那一项删掉、把两段早退和分岔删掉，代码就回到今天的样子，git revert 一次搞定。

送过去的东西也要干净：仓位数字不进研判请求

比改哪几行更要紧的是别把仓位概念送过去。

judge.request（PMS 侧 app/services/judge.py 第 65 到 72 行）现在是把 candidate["hard_numbers"] 整个塞进请求体，而决策系统会把它逐键渲染成「【硬数字 (PMS 已算好, 勿重算)】」贴进提示词。如果新建仓的 hard_numbers 里装着名额、可投金额、批次比例、组合占比这些东西，等于当面请一个不该管仓位的系统去看仓位—— 哪怕提示词后面跟着一句「仓位纪律不归你管」，模型该被带偏还是会被带偏。

所以加一条 PMS 侧的过滤：新建仓送研判时，只送定性材料，不送仓位数字。

送：现价、候选池给的分数、主题、档位、预期空间、热度、榜内名次。这些回答的是「这只票凭什么被选出来」，正是要它裁的问题。
不送：名额、可投金额、批次数量与比例、组合占比、总规模。这些回答的是「买多少」，是 PMS 自己的活。

实现上在 judge.py 里加一个显式的键白名单常量，只对 OPEN 生效，并把「为什么」写在常量旁边。账本那边不受影响——pms_action_ledger.hard_numbers_json 照旧存全量，判分锚一个字不少。

必答清单放在决策系统那一侧

DCA 那条「下跌是杀逻辑还是杀情绪」现在两边都写了一份（PMS 的 must_answer 传一次，决策系统的判据里又写一次）。新建仓不照抄这个做法：必答只写在决策系统的 OPEN 判据里， PMS 侧的 must_answer 对 OPEN 留空。 道理是分工——「建仓该问什么」属于仲裁哲学，是决策系统的知识；PMS 不需要懂。

部署方式

只改 worker 代码，不加配置、不动 .env。config/settings.py 第 208 到 226 行那段自己写着「全部有默认值，不新增必填 env → 重启 backend-api + worker-brain 即生效」。所以走常规路径：git pull 之后 docker compose restart backend-api worker-brain。 哪天真要往 .env 里写值（比如切研判独立队列），那才必须 docker compose up -d --force-recreate。

三、重新过一遍之后改掉与补上的（V2 → V3）

改掉的两处

1. 去掉 PMS_OPEN_TARGET_PCT，落指令时不再建持仓行。

V2 说落指令前先 ensure_position 建一行再写 target_pct。重想之后这条不划算： target_pct 只有在它与 PMS_STOCK_TARGET_DEFAULT 不同时才有意义，而那种差异化本来就该由建仓命令去表达；为它一个参数，要引入建行、写列、以及窗口耗尽作废后清理僵尸空持仓行三处新逻辑。

改成：自主新建仓一律用 PMS_STOCK_TARGET_DEFAULT，与后续的回踩补足、盈利加仓天然同口径，落指令时不建行。持仓行由首次成交时 ledger_service._apply_action 里既有的 ensure_position 自然建出来——这条路径命令驱动建仓已经走通并判收过。少一个参数、少三处逻辑、不产生僵尸行。

2. 去掉 PMS_OPEN_MIN_SCORE。

它和候选池已有的 PMS_PLAN_MIN_SCORE 是同一件事。两个旋钮管一件事，将来一定会有一次调错地方。

补上的六处

3. 候选之间要滚动扣减，否则一跳内几条加起来会超上限。

这是个真问题。_route_one 里每条候选各自调 caps_ctx(view, ...)，而 view 是本轮开始时取的快照，不会因为前面几条已经落了指令而更新。后果是一次心跳产出五条新建仓，每条单独看都不超上限，五条加起来超了，而规则闸拦不住——它每次看到的都是同一个旧快照。

命令那条路没有这个问题，因为 plan_increase_exposure 用 _ctx_after 在循环里滚动更新。自主这条路要照做：滚动放在 scan_open 里，边遍历边扣名额、扣可投金额、累加行业市值，并直接复用 planner.check_all_caps（规则闸用的就是它，口径天然一致）。 rule_gate 已经在 from app.core.planner import check_all_caps，core 层内部互相引用是既有模式。

4. 候选数的上界是剩余名额，不是候选池大小——这修正了 V2 对研判负载的估计。

因为名额和金额在 scan_open 里边走边扣，产出的候选数天生不会超过剩余名额。组合已建满就一条都不产、一行账本都不写；还剩三个名额就最多三条。

冷启动那天是上界：名额 20 只，但组合上限 70% × 200 万 = 140 万，单只 6% = 12 万， 金额先约束到 11 只左右。11 只 × 最多 90 秒研判 ≈ 990 秒，靠第五节的时间预算摊到七八跳，也就是七八分钟做完。之后每天只会有个位数。

5. 研判驳回要做当日去重，只对新建仓生效。

_rejected_today_keys 只读 arbiter='rule' 的拒绝，研判驳回不在里面；而 _inflight_keys 只认在途提议与在途指令，被研判驳回的候选两样都不产生。于是一条被研判驳回的新建仓候选会每分钟重来一次：决策系统那侧有半小时缓存，所以不烧大模型，但 PMS 这边每分钟往 pms_action_ledger 写一行一模一样的驳回记录。半小时三十行，几只票就是几百行——这正是代码注释里记着的 2026-07-29 那个教训 （十六只深亏票的补仓候选每分钟被拒一次，一天几千行，把判分锚淹了）。

处理：新增一个只读函数 judge_rejected_today（读 arbiter='judge' 的当日驳回），组装跳过集合时只把其中动作为 OPEN 的键并进去。既有四类动作的行为一个字不变—— 它们「研判结论会变、有意不做当日去重」那条设计保持原样。新建仓不一样：「这只票今天不该从零建仓」这个结论当天基本不会翻转。

6. 可投金额要用真实可用资金封顶。

V2 只按仓位口径算可投金额（总仓上限 × 总规模 − 组合市值）。但 2026-07-30 那次教训就是这么来的：总规模两百万而账户实际只有九十八万，方案一路排出来，规则闸一路放行，要等下游回资金不足才被拒，而拒了不自动重发。

所以 scan_open 的可投金额要在仓位口径与 cash_avail 之间取小，并且新增 PMS_OPEN_REQUIRE_WS_CASH（默认开）：拿不到真实资金快照时不自动新建仓，写进 skipped 留痕。这不是节流，是和「必须实时价」同一类的输入质量闸—— 建新仓是可以等的，而规则闸那条「拿不到资金只告警不拦」的降级口径，是为已经排好的命令设计的，不适合无人值守地从零建仓。

7. 行业名一次批量取，本轮复用。

滚动扣减要算行业集中度，所以得先有行业名。industry.get_many 走 gp_stock_category 时是逐只查库（第 231 到 237 行），没有缓存。所以在 proposal_service 里对候选代码一次性取一遍，塞进候选， scan_open 与 _route_one 都用这一份，不重复查。

顺带提一条建议但需要你单独拍板的：给 industry.get_many 的 gp_stock_category 分支加按日缓存，与 _hybk_many 同一口径（行业归属本来就是日频的）。收益是每跳少几十次库查询。但它改的是既有函数的时序行为，按第一节的规矩， 这次不夹带，要做就单独一条。

8. 研判预算用尽的候选整条跳过，不入人工队列。

预算用尽时，已经过了规则闸但还没送研判的候选，处理方式是整条跳过并写 skipped，下一跳重来。不把它们当成「研判不可用」入人工确认队列——那会在自动档位下凭空造出一个人工队列，与这次要解决的问题正好相反。规则闸白跑一次的成本是毫秒级。

四、选票规则：动作引擎只管名额、钱、批次

候选池那边已经筛过（分数降序、档位白名单、分数与来源数与预期空间下限、同主题限额、剔除 ST、剔除已持仓、剔除黑名单）。规则闸后面还会管一手整百、冻结、全局暂停买入、黑名单、昨夜定性、涨停不追、当日涨幅不追高、距 MA5 不追高、组合与单股与持仓数与行业集中度上限、预留现金、真实可用资金。择时再管现价在不在买入区间。

action_engine.py 第 17 行的注释把边界钉死了——上限、一手、冻结不在动作引擎重复判。所以新建仓求值器只回答三个问题，且边算边扣：

还能开几只：最大持仓数 − 当前持仓数，每产出一条减一。
还有多少钱可投：min(总仓上限 × 总规模 − 组合市值, 真实可用资金)，每产出一条减去该条的实际金额。
这一批买多少股：按 PMS_BATCH_SPLIT 拆批，只提底仓那一批（默认 50%）， lot_qty(金额, 现价)，不足一手就不提。

只提底仓批是刻意的：后续的回踩补足与盈利加仓，等持仓真建立起来之后由已有的 eval_fill 与 eval_add 自然接管。这条路上一条 GATED 方案都不产生。

价格必须是实时价。 market.plan_price 拿不到实时价会回落昨收，它自己的注释写着「拿昨收当现价去做不追高这类判断会出错，只给规划期定量用」。自主建仓要真下单，所以走 market.get_price，取不到就整只跳过并写进 skipped。

不节流的自然收敛点有两个：一是名额与金额在求值器里边走边扣，候选数天生有界；二是择时的买入区间——只有现价正好落在 [支撑×0.99, 支撑+(压力−支撑)×0.3] 里的票才会真出手，高于上沿一律「不追，接受买不上」。每天实际建成几只，取决于当天有几只落在自己的区间内。这正是「让系统自己判断」，第一周主要盯的就是这个数。

一条已知的降级：新建仓在退实现B时，day.support 是空的（新票没有参考位取数），内置择时的「回踩带」判据用不上，只剩「现价不高于当日均价」一条，比已有持仓弱。这是可接受的降级，但要在决策理由里写明白，别让人以为两条判据都过了。

五、研判的时间预算（不是节流）

app/scheduler.py 第 45 行给所有调度任务设了软超时 240 秒、硬超时 300 秒，而 judge.request 是同步阻塞、单次超时上限 90 秒。三只票送研判就是 270 秒，已经顶破软超时。 今天没出事，是因为送研判的只有三只持仓票且多数轮次被去重挡掉。冷启动那天新建仓会有十来条，第一跳就会捅穿——任务被中途杀掉，而且是在已经落了一部分表之后。

新增 PMS_JUDGE_TICK_BUDGET_SEC（默认 150 秒）。每次要调研判前先看这一轮花了多久，如果「已花 + 单次超时上限」会顶破预算，本轮不再送后面的候选，写进 skipped，理由写「本轮研判时间预算用尽，下一跳继续」。

这不是节流：一条候选都没丢，没有任何按天计的上限，只是把一次心跳做不完的活挪到下一分钟。候选按分数降序排，预算用尽时先做完的一定是分数最高的那些。决策系统那侧的裁决缓存是按「日期 + 股票 + 动作」存半小时的，所以同一批候选在半小时内的重复扫描都是秒回，真正慢的只有缓存过期后的第一跳。

决策系统那侧还预埋了研判独立队列（接口文档 §5.2）。现在不用开—— 那是给 brain_queue 拥堵准备的，而我们的瓶颈是 PMS 自己的心跳时长，不是对端排队。真出现频繁超时再开，而且开它要改 .env，必须 force-recreate。

六、要动的文件与改法

PMS 侧（`factor@factorevaluation`，改完 `make deploy`）

app/core/action_engine.py 加 A_OPEN = "OPEN"，加进 JUDGE_ACTIONS；新增 eval_open() 与 scan_open() （含名额、金额、行业的滚动扣减，复用 planner.check_all_caps）； 既有 scan() 一个字不动，既有单测继续全绿。
app/services/proposal_service.py
- scan_and_route 追加：取候选池、批量取行业、算名额与可投金额、调 scan_open，两批候选合并走同一个 _route_one。
- 候选池取数失败（PlanFeedError）时不产生新建仓候选，原因写进 skipped；已有持仓的四类动作照常扫描。
- 跳过集合并入 judge_rejected_today 里动作为 OPEN 的键。
- 研判时间预算：记本轮起始时刻，送研判前判预算，用尽则跳过并留痕。
- _route_one 给 OPEN 两处特判：现价取候选自带的（_pos_of 对新票没有 price，取它会是 0，规则闸直接 PRICE_MISSING）；组合上下文改成 caps_ctx(view, ts_code=code, is_new_name=True, sector=<批量取到的行业>) ——必须显式传行业，否则行业集中度那道硬拦截会静默跳过。
- 档位分流加 OPEN 分支（见第七节）。
app/services/judge.py 加 OPEN 专用的 hard_numbers 键白名单，只送定性材料；must_answer 对 OPEN 留空。
app/services/exec_advisor.py _advice 把应答 observed 里的支撑、压力、买入区间存进缓存；当日首答锁进 prog["ref_lock"]；之后每答比对，偏离超过 PMS_OPEN_REF_DRIFT_MAX 就把本轮判定改成等待，返回的决策里带 ref_drift 说明。只对 action == "OPEN" 生效。
app/services/executor.py run_tick 的等待分支里，看到 d.get("ref_drift") 就额外落一条评审账本 WARN。放这里而不放 exec_advisor，是为了不给后者引入落表副作用。
app/repo/pms_repo.py 新增只读函数 judge_rejected_today；新增只读的当日新开票数统计（供页面显示，不做上限）。
app/services/param_store.py 与 config/settings.py 新增四个参数（第八节），同步补 DESC 中文说明、_range_check 或 _RANGES 校验、以及 FAIL_CLOSED。param_store.py 第 46 行那条注释记着一次教训—— 加参数不同步加白名单，set_param 只回 ok=False 不抛异常，调用方又把返回值丢了，那条纪律就静默失效。这次一并照做。另把 PMS_JUDGE_ACTIONS 默认值改成 FILL,ADD,DCA,SWITCH,OPEN。
测试脚本（纯逻辑，不连库）名额已满、组合钱不够、真实资金不足、拿不到资金快照、买不足一手、取不到实时价、候选池取数失败、多条候选的滚动扣减、研判预算用尽、参考位漂移超阈值、档位分流的三种取值、研判驳回当日去重。

决策系统侧（`192.168.16.188`，`git pull` + `restart backend-api worker-brain`）

workers/tasks_intraday.py：_task_by_action 加 OPEN 判据（含必答）； OPEN 且现价缺失时块内早退回 UNAVAILABLE；边界声明按动作分岔。 三处全在 if direction == "PMS_JUDGE": 块内，不动共用代码，不动 .env。

七、档位：一个开关，默认开启

新增 PMS_OPEN_AUTONOMY，取值 full / propose_only / off，默认 full。它同时充当总开关，不再单设第二个：off 就是不扫描新建仓。

_route_one 第 132 行那行不动，在它之外给 OPEN 加一个分支： full 过完两道闸直接落指令；propose_only 落待确认队列；off 根本不扫描。

三条无条件优先的规矩不变：减持方向永远自动执行；深档补仓永远要人点头； 研判不可用时一律入队待确认——最后这条对新建仓尤其重要，它是「拿不到意见绝不当成通过」这条纪律在新链路上的落点。

部署时机提醒：默认 full 意味着 make deploy 一跑完，下一个整分钟的心跳就可能真的建仓。建议收盘后部署，让第一次真实运行发生在次日开盘、你在场的时候。

八、新增参数（四个）

键	默认	说明
`PMS_OPEN_AUTONOMY`	`full`	新建仓档位兼总开关：full 自动执行 / propose_only 待确认 / off 不扫描
`PMS_OPEN_REQUIRE_WS_CASH`	`True`	拿不到真实资金快照时不自动新建仓（写 skipped 留痕）
`PMS_OPEN_REF_DRIFT_MAX`	`0.03`	参考位盘中被改写的容忍幅度，超过则该票当日暂停新建仓
`PMS_JUDGE_TICK_BUDGET_SEC`	`150`	单轮提议扫描用于研判的时间预算（秒），用尽则剩下的候选留到下一跳

改默认值的既有参数：PMS_JUDGE_ACTIONS 从 FILL,ADD,DCA,SWITCH 改成 FILL,ADD,DCA,SWITCH,OPEN。

FAIL_CLOSED 加一条 PMS_OPEN_AUTONOMY: "off"——参数表读不到时不自动建仓。这与「默认开启」不冲突：默认值管正常情况，FAIL_CLOSED 管读不到参数表的故障情况。

九、两个已知的交互

命令驱动的 OPEN 拒绝记录会挡住自主 OPEN。 command_service._ledger_rejects 写的是 action="OPEN"、arbiter="rule"、 verdict="REJECT"，而 _rejected_today_keys 读的正是这张表的（股票，动作）。所以某只票今天因为一条升仓命令在规划期被上限拦过，自主新建仓当天不会再提它。多数情况下这是对的（同一组约束），但两边算的目标金额不同，一手不足这类拒绝口径可能不一样。先记下来，观察一天。
升仓命令的候选没有排除已有在途方案的票。 _dispatch_planner 算出了 exclude = _codes_with_live_plans() 却只传给降仓分支。既有现象，不属本次范围；自主这条路有 _inflight_keys 兜底，命令那条路没有。 这次不动，先观察。

十、上线与判收

判收标准是真机各见一次。

步	动作	判收标准
1	决策系统侧先上：`git pull` + `restart backend-api worker-brain`	手工发一条 `action=OPEN` 的研判请求，回 PASS 或 REJECT，理由读得出是在谈从零建仓而不是加仓；请求体里确认没有仓位数字
2	PMS 侧 `make deploy` + `make test`（收盘后做）	ALL SUITES PASS
3	次日盘前先把 `PMS_OPEN_AUTONOMY` 设成 `propose_only` 看一轮	提议队列出现 OPEN，理由读得懂；`make t-gate` 看到 arbiter=judge 的行；多条候选时确认名额与金额是滚动扣减的
4	确认无误后改成 `full`	一条 OPEN 提议直接落指令，`make t-ins` 看到 `origin_type=proposal`、`action=OPEN`、`is_command=false`
5	盘中观察	现价在买入区间内时出手，`last_decision.source=A`，限价等于区间上沿
6	成交之后	`pms_position` 出现该票、`opened_date` 有值、`status=HOLDING`；次日起 `eval_fill` 能看见它
7	研判预算与账本	日志里出现过「本轮研判时间预算用尽」且下一跳接上了；`intraday_exec` 一次都没触发软超时；评审账本没有被同一条驳回刷屏
8	漂移防护	只靠单测判收，不在生产人为制造（盘中跑 push-pool 触发补扫风险太大）。生产侧只观察账本里有没有 `REF_DRIFT` 的 WARN 行

第三步那轮 propose_only 是我加的一道自保，代价一个交易日；想直接上 full 就跳过，判收从第四步开始。

十一、第一周要盯的四个数

不设人为上限之后，这四个数替代了「每天开几只」这个旋钮：

每天有几只候选落在自己的买入区间内——实际建仓速度，也是「让系统自己判断」到底判成什么样的直接答案。
研判驳回率——驳得太狠说明 OPEN 判据写窄了，一条不驳说明写宽了。
intraday_exec 一跳的耗时分布——预算够不够，要不要开研判独立队列。
评审账本每天的行数——第三节第 5 条那个去重有没有真的生效。

24 KiB Raw Blame History Unescape Escape