一 什么是专家模式–以一个股票策略回测为例
1.1 默认的工作流模式
- 我们开启了一个新的工作流，并让AI按照我们的策略想法“A股主板打板策略回测”生成了一整套策略回测的工作流，如下图所示;
- 在代码输入节点，主要是策略逻辑实现。点开可以让AI把逻辑讲清楚，不认可的地方可以让他修改，也可以自己手动修改关键参数和逻辑;
- 股票回测节点，主要是一些资金、时间区间、交易频率等基础参数的设置；
- 策略回测结果中，可以查看策略的回测表现、历史持仓，以及你在代码输入节点中，为了观察策略的一些实现细节，要求工作台输出的一些内容（在查看日志中）。
1.2 专家模式长什么样
- 打开侧边栏的专家模式按钮，即可看到我们的三个工作流节点的py文件
- 分别对应了前面Python代码输入、股票回测节点、策略回测结果展示节点；
1.3 从专家模式中的代码看整个工作流做了什么事
1.3.1 Python代码输入节点
这个节点的职责很简单：接收用户输入的 Python 代码字符串，做安全校验，然后原样输出，供下游节点（如因子构建、回测）使用。
四个核心部分
① 输入模型 CodeInputModel
接收一个 code 字符串，在输入时自动触发两个校验：
- 语法检查：用 BaseCodeChecker 检查 Python 语法是否合法，报错码 10026
- 危险代码检查：检查是否包含危险操作（如 os.system、文件读写等），报错码 10027
② 输出模型 CodeOutputModel
结构和输入一样，就是把校验通过的 code 字符串传出去。
③ 节点类 CodeControl
run() 方法极其简单——什么都不做，直接把输入的 code 包装成输出返回。核心逻辑都在输入校验阶段完成了。
④ 节点注册装饰器
一些显示格式的设置
总的来说，这个节点，本身不执行代码，它只是一个"代码容器+安全门卫"。在这个节点里写的策略代码，要连线到下游的 因子构建节点 或 回测节点 才会真正被执行。
1.3.2 股票回测节点
节点职责：接收策略代码 + 各种回测参数，调用后台回测引擎 panda_backtest 真正跑回测，返回一个 backtest_id。
四个核心部分
① 输入校验 StockBacktestInputModel
两层校验：
因子校验：确保传入的 factors 是 pd.DataFrame 类型
日期校验：
格式必须是 YYYYMMDD
结束日期必须晚于开始日期
时间跨度不能超过 3 年（超过直接报错）
② 输出 StockBacktestOutputModel
只输出一个 backtest_id 字符串。回测是异步跑的，拿到 ID 之后再去查结果。
③ 核心执行逻辑 run()
back_test_id = get_backtest_id() # 生成唯一任务ID
self.logger.info(f"BacktestNodeIdentifier: {back_test_id}") # 前端靠这行日志识别并特殊渲染
start(back_test_id=…, code=…, …) # 真正调用回测引擎
④ 异常处理
回测报错时，会把策略源码附加到异常信息里，方便定位是代码哪一行出了问题。
1.3.3 策略回测结果节点
整体职责：拿到上一个节点输出的 backtest_id，去 MongoDB 里查回测数据，包装成 JSON 返回。
核心函数 get_backtest_result_info_json()
分四步走：
第一步：解析 ID
把传入的字符串转成 MongoDB 的 ObjectId，失败则记录错误事件。
第二步：查数据库
_db.mongo_find_one(
db_name=config[“MONGO_DB”],
collection_name=“panda_back_test”, # ← 回测结果存在这个集合里
query={"_id": oid},
projection={"_id": 0}, # 不返回 _id 字段本身
)
第三步：组装响应结构
{
“status”: “ok / error / empty”,
“backtest_result_info”: { …回测数据… },
“events”: [“错误日志…”] // 只有出错时才有
}
第四步：安全序列化
用 json_util.dumps 而不是普通 json.dumps，是因为 MongoDB 返回的数据可能包含 ObjectId、datetime 等特殊类型，普通 JSON 库无法处理。
总的来说，三个环节写代码 → 跑回测 → 查结果非常清晰。
二 专家模式能够为我们的策略研发带来哪些灵活性
1. 突破内置节点的边界
普通模式只能用平台提供的积木块，专家模式让你能看到每个节点的"合同"——输入输出的数据结构、校验逻辑、调用接口。知道接口长什么样，才能真正扩展它。
2. 数据结构完全透明
比如从这三个节点已经能推断出：
- 因子是 pd.DataFrame 格式
- 回测结果存在 MongoDB 的 panda_back_test 集合
- 节点间传递的核心货币是 backtest_id 字符串
这些信息在普通模式下是黑箱，专家模式下一览无余。
3. 自定义节点可以无缝接入流水线
自己写的自定义节点只要遵守同一套 BaseWorkNode + Pydantic 模型的规范，就能和官方节点任意组合，不需要改平台代码。
三 一些方向性的建议
① 先摸清数据契约再写代码
重点看每个节点的 input_model 和 output_model，搞清楚字段名、类型、默认值。比如因子节点输出的 DataFrame 列名是什么、索引是日期还是股票代码，这些决定了自定义因子代码能不能正确对接。
② 复制官方节点改造
不要从零写，把官方节点的代码复制过来作为模板，只改 run() 里的逻辑。校验、注册、日志这些脚手架代码直接复用，省大量时间。
③ 在自定义节点里引入外部数据
官方节点的数据来源是平台内置的，但可以自己写一个节点去调用外部 API（比如 Tushare、AKShare），把数据包装成 pd.DataFrame 输出，接到官方的因子构建或回测节点上。这是专家模式最有价值的用法之一。
④ 利用 events 机制做调试
从结果节点的代码可以看到，它有一套 events 错误日志机制。自己写节点时也可以模仿这个模式，把中间过程记录下来，出错时能快速定位。
