1. Agent 架构：为什么是真正的 Agent 而不是 Workflow

Jansen 的书看起来像一个干净的 pipeline — Data → Factors → Backtest → ML → Execution — 你的第一反应可能是把它编码成一个 agentic workflow，一个 DAG，每个节点是一个结构化步骤。

但那是教科书的呈现方式，不是 RS 实际工作的方式。

看看 factor research 实际上是怎么发生的：算 IC，发现 turnover 太高，加个 smoothing filter，重新跑 tearsheet，IC 还行但集中在小盘股，做 sector neutralization，再跑一遍。这不是 pipeline，这是一个以判断力控制退出的循环。RS 根据 taste 来决定"够好了"，不是某个阈值。

ML 那边也一样。RS 不会机械地 for model in [LR, XGB, LSTM]: train(model)。他们看线性模型的残差，注意到某些 regime 下的异方差性，猜测 tree model 可能捕捉非线性，试一下，检查 feature importance，发现 volume feature 有前瞻偏差，修数据 pipeline，从头来过。

Agentic workflow 预定义执行图，在你能枚举状态和转换时才有用。RS 工作中最有价值的步骤恰恰是你无法预定义的：

• "IC 看着不错，但我不信——会不会只是 sector momentum 的代理？" → 创造性假设-验证循环
• "Sharpe 2.3 但 turnover 疯了——换一种 portfolio construction 试试" → 在 pipeline 阶段间跳转
• "一个可疑 feature 的 importance 很高——跑个 permutation test" → 向回走

这些都是判断驱动的路由。Workflow graph 要么无法捕捉它们，要么退化成 "loop: {do anything, check if done}" — 本质上就是一个更差的 agent。

所以架构是：single agent + CodeAct + domain-aware Skills。

Agent 拿到一组 atomic tools（python_exec、file_read 等，见第 2 节），整个量化研究工具包通过 sandbox 中的代码访问。结构化的工作流知识编码在 Skills 里 — 不是 pipeline 节点，而是按需拉取的可执行模板，相当于 Jansen 各章节翻译成代码模式。Agent 自己决定 什么时候调用哪个 skill，以什么顺序，根据任务和中间结果。Skills 通过 progressive disclosure 按需拉取，不是预接线到 DAG 中。具体的 skill 设计和优先级见第 3 节。

有一个窄的例外：如果 RS 给出完全指定的任务（"用标准 backtest pipeline 跑这个 signal 出个 tearsheet"），那就是一个直通脚本，单次 python_exec 搞定。CodeAct 处理确定性序列毫不费力。

2. 工具设计：8 个工具，两层架构

两层，一条边界

Manus 和 Claude Code 的收敛告诉我们 action space 是一个层级：

Layer 1: Function-calling（LLM 直接调用的工具）
         ↓  [context management 边界]  ↓
Layer 2: Sandbox（通过代码执行访问的一切）

每个能力住在且只住在一层。判断标准：LLM 是否需要一个独立的推理步骤来决定使用它（→ Layer 1 工具），还是它自然属于更大计算的一部分（→ Layer 2，sandbox 内代码）？