388 lines
24 KiB
Markdown
388 lines
24 KiB
Markdown
# 方案（定稿）：给动作引擎加「新建仓」动作
|
||
|
||
> 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 以外的系统，动手前先答这三题，答不上就先别动：
|
||
|
||
1. **这段代码是不是只有我这条路径会走到？** 如果是共用的（提示词模板、裁决解析、
|
||
上下文组装、配置项），就不能在里面加只对我有意义的分支。
|
||
2. **我加进去的字段，会不会被别的逻辑读到并当真？** 尤其是写共享表、写共享缓存、
|
||
往共享 context 里塞键。
|
||
3. **我的东西全删掉，原系统能不能一字不差地回到今天？** 答不上「能」，就说明它不是加法。
|
||
|
||
按这三题重新核过这次的决策系统改动，见下一节。
|
||
|
||
---
|
||
|
||
## 二、决策系统侧：三处改动全部落在 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 行的注释把边界钉死了——上限、一手、冻结不在动作引擎重复判。
|
||
所以新建仓求值器只回答三个问题，且**边算边扣**：
|
||
|
||
1. **还能开几只**：`最大持仓数 − 当前持仓数`，每产出一条减一。
|
||
2. **还有多少钱可投**：`min(总仓上限 × 总规模 − 组合市值, 真实可用资金)`，
|
||
每产出一条减去该条的实际金额。
|
||
3. **这一批买多少股**：按 `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`）
|
||
|
||
1. **`app/core/action_engine.py`**
|
||
加 `A_OPEN = "OPEN"`，加进 `JUDGE_ACTIONS`；新增 `eval_open()` 与 `scan_open()`
|
||
（含名额、金额、行业的滚动扣减，复用 `planner.check_all_caps`）；
|
||
**既有 `scan()` 一个字不动**，既有单测继续全绿。
|
||
|
||
2. **`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 分支（见第七节）。
|
||
|
||
3. **`app/services/judge.py`**
|
||
加 OPEN 专用的 `hard_numbers` 键白名单，只送定性材料；`must_answer` 对 OPEN 留空。
|
||
|
||
4. **`app/services/exec_advisor.py`**
|
||
`_advice` 把应答 `observed` 里的支撑、压力、买入区间存进缓存；当日首答锁进
|
||
`prog["ref_lock"]`；之后每答比对，偏离超过 `PMS_OPEN_REF_DRIFT_MAX` 就把本轮判定
|
||
改成等待，返回的决策里带 `ref_drift` 说明。**只对 `action == "OPEN"` 生效。**
|
||
|
||
5. **`app/services/executor.py`**
|
||
`run_tick` 的等待分支里，看到 `d.get("ref_drift")` 就额外落一条评审账本 `WARN`。
|
||
放这里而不放 `exec_advisor`，是为了不给后者引入落表副作用。
|
||
|
||
6. **`app/repo/pms_repo.py`**
|
||
新增只读函数 `judge_rejected_today`；新增只读的当日新开票数统计（供页面显示，不做上限）。
|
||
|
||
7. **`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`。
|
||
|
||
8. **测试脚本**（纯逻辑，不连库）
|
||
名额已满、组合钱不够、真实资金不足、拿不到资金快照、买不足一手、取不到实时价、
|
||
候选池取数失败、**多条候选的滚动扣减**、研判预算用尽、参考位漂移超阈值、
|
||
档位分流的三种取值、研判驳回当日去重。
|
||
|
||
### 决策系统侧（`192.168.16.188`，`git pull` + `restart backend-api worker-brain`）
|
||
|
||
9. **`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` 管读不到参数表的故障情况。
|
||
|
||
---
|
||
|
||
## 九、两个已知的交互
|
||
|
||
1. **命令驱动的 OPEN 拒绝记录会挡住自主 OPEN。**
|
||
`command_service._ledger_rejects` 写的是 `action="OPEN"`、`arbiter="rule"`、
|
||
`verdict="REJECT"`，而 `_rejected_today_keys` 读的正是这张表的（股票，动作）。
|
||
所以某只票今天因为一条升仓命令在规划期被上限拦过，自主新建仓当天不会再提它。
|
||
多数情况下这是对的（同一组约束），但两边算的目标金额不同，
|
||
一手不足这类拒绝口径可能不一样。先记下来，观察一天。
|
||
|
||
2. **升仓命令的候选没有排除已有在途方案的票。**
|
||
`_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` 就跳过，
|
||
判收从第四步开始。
|
||
|
||
---
|
||
|
||
## 十一、第一周要盯的四个数
|
||
|
||
不设人为上限之后，这四个数替代了「每天开几只」这个旋钮：
|
||
|
||
1. **每天有几只候选落在自己的买入区间内**——实际建仓速度，
|
||
也是「让系统自己判断」到底判成什么样的直接答案。
|
||
2. **研判驳回率**——驳得太狠说明 OPEN 判据写窄了，一条不驳说明写宽了。
|
||
3. **`intraday_exec` 一跳的耗时分布**——预算够不够，要不要开研判独立队列。
|
||
4. **评审账本每天的行数**——第三节第 5 条那个去重有没有真的生效。
|