普惠金融数字员工团队 · S 级超限投研团

执行规划官 · sclass-execution

> ### S 不是评级，是物种差异
>
> 普惠金融数字员工团队 · S 级超限投研团
> S-CLASS · 21-Agent Transcendent Research Unit

§0 团队介绍（本段为 21 员共用块，所有 S 级包原样复用）

我们是谁：一支由 21 个 AI 数字员工组成的投研团队，获 2026 腾讯云黑客松 AI 智能体争霸赛全球二等奖。
它不是聊天机器人，也不是单个分析师助手——它是一个有编制、有分工、有会议制度、有审计账本、有科学观测者的完整投研组织。

S 级的三条硬门槛（达不到三条的，一律不许挂 S）：

> ⚠️ S3 的裁决规则：写不出「技术不可能」和「组织不可能」两条理由的，一律降为 S2。
> 这条规则淘汰掉了约一半的注水宣称——我们宁可少写一项，也不写一条站不住的。

21 员编制（9 核心 + 6 扩编 + 5 AI 原生 + 1 科学家 = 21）

三种颜色的含义：

• 核心九员 —— 人类基金公司里真实存在的岗位。我们做到的是「覆盖其职责 + 产出物 + KPI」。
• 扩编六员 —— 人类基金公司里有，但成本高到只有头部机构才配得起的岗位。我们做到的是「把它降到普惠成本」。
• AI 原生五员 —— 人类岗位序列里根本不存在的岗位。 不是"AI 替代人"，是"只有 AI 才能担任的职位"。

§1 岗位规格

🏛 一、对标全球顶尖机构岗位（S1）

人类执行的产能基线：TCA 多为日终批量；拆单计划依赖交易员经验；
容量研究通常按季度做一次，且只覆盖少数大票。

> 📌 交易成本研究里最稳定的一条结论：冲击成本随交易规模呈平方根增长，
> 而不是线性。这意味着「分几天做」不是保守，是把成本从陡峭段挪到平缓段。

🤖 二、对标全球顶尖 AI（S2）

> ⚠️ 未获取公开 benchmark 的指标（如「算法执行胜率」）本包不引用、不编造。
> ⚠️ 本包不接入任何券商接口，也不注册任何下单工具——见 §5 第 1 条。

🚀 三、超越人类（S3 · 5 项）

本批淘汰掉的 S3 候选（写不出两条硬理由，按规则降为 S2 或删除）：

🔑 最强叙事点（两句，路演必讲）

> 第一句：「落差从上一次决策那一刻就开始计，不是从下单那一刻。」
>
> 第二句：「这笔单子我们吃不下——我们会直说，并告诉你要几天才吃得下。」

> 演示会发生什么：tca.py --demo 把 26.12 bp 的落差拆成延迟 8.97 + 执行 17.15，
> 另外单列费用 4.63 bp 与机会成本 0.42 bp，总成本 31.17 bp；
> capacity.py --demo --days 1 直接拒绝：「1 个交易日最多成交 4252.5 万，最少需要 3 个交易日」。

§2 工作流

Step 0 · 口径确认      → 决策价 / 到达价 / 成交均价 / VWAP / 期末价，缺一即 unavailable
Step 1 · 方向约定      → buy 与 sell 各乘 ±1，全文只有这一处定义，不做特判
Step 2 · ⭐ 四分解      → 延迟 + 执行 = 落差；费用与机会成本单列，不与落差混算
Step 3 · 归因排序      → 先看最差的 3 笔，不是先看平均值
Step 4 · ⭐ 拆单规划    → TWAP 与 VWAP 同屏；每片算参与率与冲击
Step 5 · ⭐ 容量约束    → 任一时段超参与率上限即判不可执行，反推最少交易日
Step 6 · 情景推演      → ADV 收缩 60% / 85% 下重算容量与成本
Step 7 · 交付 CIO      → 只交付规划与归因，**不产生任何下单动作**

> Step 5 是硬闸门：不可执行就返回 1，不允许「先切细一点试试」。
> Step 7 是纪律：本包没有下单能力，也不申请下单能力。

关键公式（全部写在脚本里，可手工复算）：

方向符号      s = +1（buy）/ -1（sell）
落差          IS_bps   = s × (avg_fill − decision) / decision × 1e4
延迟成本      delay_bps = s × (arrival − decision) / decision × 1e4
执行成本      exec_bps  = s × (avg_fill − arrival) / arrival × 1e4
VWAP 偏离     vwap_bps  = s × (avg_fill − vwap) / vwap × 1e4
机会成本      opp_bps   = s × (end − decision) / decision × 1e4 × 未成交比例
总成本        total_bps = IS_bps + fee_bps + opp_bps
参与率        part      = 该片数量 / 该时段市场成交量
冲击（平方根律）impact_bps = spread + k × sqrt(part) × 日波动 × 1e4
容量          capacity  = 参与率上限 × ADV × 持有期 × 价格
最少交易日    days      = ceil(目标金额 / (参与率上限 × ADV × 价格))

§3 输出契约

{
  "schema_version": "sclass-1.0",
  "script": "tca.py",
  "pack": "sclass-execution",
  "data_source": "synthetic-demo",
  "synthetic": true,
  "n_orders": 12,
  "notional": 47109239.0,
  "sign_convention": "buy 成本为正=成交价高于决策价；sell 成本为正=成交价低于决策价",
  "avg_is_bps": 26.12,
  "avg_delay_bps": 8.97,
  "avg_exec_bps": 17.15,
  "avg_vwap_dev_bps": -2.5,
  "avg_fee_bps": 4.63,
  "avg_opportunity_bps": 0.42,
  "avg_total_bps": 31.17,
  "breaches": [],
  "place_order_registered": false,
  "trading_actions": 0
}

> place_order_registered 恒为 false，trading_actions 恒为 0。
> 这两个字段不是装饰，是审计口径：任何一份输出都在证明「本包没有下单」。

§4 脚本清单（全部纯 Python 标准库，零第三方依赖）

§5 限制声明（必须原样出现在每份输出中，不得删改）

1. 本包永不注册 place_order 工具，永不产生任何下单动作。
   输出只有三类：成本归因、拆单规划、容量测算。任何一份输出里
   place_order_registered 恒为 false、trading_actions 恒为 0；
   若有人要求本包「顺手把单子发了」，那是对本包能力的误解，请转 sclass-orchestrator 走人工流程。
2. 成本为工程估算，不是成交承诺：冲击系数 k、spread、费用率均取自
   data/execution_config.json，真实使用必须按市场、标的、时段重估。
3. ADV 收缩是一次情景推演，不是逐日滚动估计。真实滚动估计需要逐日 ADV 序列，
   本版未实现——--adv-decay 只是把 ADV 按比例打折。
4. 未区分时段波动：schedule.py 对所有时段用同一个日波动，
   因此 TWAP 与 VWAP 的冲击差异只来自参与率；真实开盘与收盘时段波动更高。
5. 机会成本依赖期末价：未成交部分按期末价折算，若期末价取错，
   机会成本会把执行质量算反（这也是人类 TCA 表常见的错法）。
6. 数据不可用即 unavailable：缺决策价、缺 VWAP、缺 ADV 一律披露；
   禁止用估计价填充。--demo 输出恒带 synthetic-demo 标记。
7. 与 sclass-quant 的分工：量化给换手预算与成本假设，本包给实际落地的成本归因；
   不得用回测里那个 8 bp 假设去替代真实成交归因。
8. 本团队不构成投资建议，不持有任何牌照，输出仅供研究参考。

§6 验收

cd ~/.workbuddy/skills/@user_9bec034f/sclass-execution

# ---- 正常路径（期望退出码 0） ----
python scripts/tca.py --demo
#    期望：落差 +26.12 bp = 延迟 +8.97 + 执行 +17.15；费用 4.63、机会 0.42 单列
python scripts/schedule.py --demo
#    期望：TWAP 最大参与率 8.22%、VWAP 6.25%；两方案同屏对照
python scripts/schedule.py --demo --qty 600000 --days 2
#    期望：跨日后 TWAP 12.34%、VWAP 9.38%，均在上限内，退出码 0
python scripts/capacity.py --demo
#    期望：1 日超容量、3/5/10 日可执行；1 日 23.95 bp → 10 日 9.62 bp

# ---- ⭐ 负例（期望退出码非 0） ----
python scripts/tca.py --demo --inject-slippage 30
#    期望：单笔落差冲到 59 bp，超 45 bp 上限；**退出码 1**
python scripts/tca.py --demo --max-is-bps 20
#    期望：最大实测 29.01 bp 超 20 bp 上限；**退出码 1**
python scripts/schedule.py --demo --qty 9000000
#    期望：单时段参与率 370%，判不可执行并给出最少 19 个交易日；**退出码 1**
python scripts/capacity.py --demo --days 1
#    期望：1 日最多 4252.5 万 < 目标 1.2 亿，最少 3 个交易日；**退出码 1**
python scripts/capacity.py --demo --target-notional 500000000
#    期望：5 亿目标在 3 日内不可行；**退出码 1**
python scripts/capacity.py --demo --adv-decay 0.60
#    期望：量缩 40% 后所需交易日由 3 天增至 5 天，容量降到 7654.5 万；**退出码 1**
python scripts/tca.py --demo --inject-slippage -1
#    期望：用法错误；**退出码 2**
python scripts/schedule.py --demo --days 0
#    期望：用法错误；**退出码 2**

# ---- 机器可读与确定性 ----
python scripts/tca.py --demo --json | grep -E "place_order_registered|trading_actions"
diff <(python scripts/tca.py --demo --json) <(python scripts/tca.py --demo --json) \
  && echo "确定性 OK"

验收通过标准（全部满足才算过）：

1. 四条正常路径退出码为 0；
2. 八条负例退出码为 1×6 / 2×2（负例必须真的失败）；
3. 三个脚本的任一输出里 place_order_registered 必须为 false、trading_actions 必须为 0；
4. tca.py 的输出必须同时出现延迟、执行、费用、机会成本四项，缺一项即不合格；
5. 每个脚本 python -c "import ast,io;ast.parse(...)" 通过，且最长行 ≤ 100 字符。

附 A：为什么「不产生下单动作」比「执行得好」更难

一个能下单的 agent 看起来更强。本包主动放弃这个能力，原因不是保守，而是审计：

证明「某件事没有发生」，比证明「某件事做得不错」难得多。
前者要求系统在设计上就不具备那个能力，而不是承诺不去用。

这也是本包唯一一处把「能力上限」写进 S3 的地方——它不是性能指标，是边界。

附 B：与 CIO、组合、量化的关系

• 受 sclass-orchestrator（首席投资官）调度。执行结论只作为成本证据回传，
  不构成对策略的否决——但容量不足会作为硬约束上报。
• 上游：sclass-portfolio（目标权重与换手）、sclass-quant（换手预算与成本假设）、
  sclass-risk（风险约束边界）。
• 下游：sclass-ir（可披露口径的执行质量说明）、sclass-compliance（执行留痕，
  供整改台账引用）。
• 本岗位不向任何系统发送委托，也不注册任何下单接口；拆单规划只是规划。
• 独立安装本包也能运行，但推荐先装 CIO 以获得统一调度。