不要把“接入 AI”理解成一次架构跃迁

一个传统工具演进为 Agent，通常不该从确定性程序直接跳到自主循环。更稳妥的路径有四层，每一层只在上一层暴露出真实限制时再增加能力。

确定性工具 → AI 增强应用 → 工具型 Agent → 长任务研究 Agent

这条路线的重点不是逐级追求“更智能”，而是始终保住系统已有的正确性。

第一层：确定性工具

a-stock-strategy 已经具备这一层的关键结构。数据集有 manifest 和 hash；实验请求先经过 validate_request；策略通过 registry 构建；回测输出交易、净值、事件和指标；JobManager 保存任务状态；报告记录数据、参数、策略版本和代码来源。

在这一层，用户知道自己要跑什么，程序知道每一步怎样执行。它最大的价值是可复现：输入相同，就能追查结果为何相同或不同。

第二层：AI 增强应用

AI 可以先出现在不控制事实的地方。例如：

  • 把自然语言实验意图转换为候选配置；
  • 解释指标、交易记录和警告；
  • 比较两份已经完成的报告；
  • 把底层异常翻译成可执行的排查建议。

系统中现有的可选 LLM 摘要就是这种形态。关键约束是：模型输出必须和原始报告分开；没有网络、没有 API Key 或调用失败时，回测仍能正常完成；模型不能改写指标，也不能悄悄改变策略参数。

这一层尚不需要 Harness，因为调用边界和后续动作都是应用代码预先决定的。

第三层：工具型 Agent

当用户只描述研究目标，模型需要在若干受控工具之间选择，系统才进入 Agent 形态。例如用户问：

固定科创 50 ETF 和动态横截面排名，在不同滑点和持有期下谁更稳健？

模型不能凭语言回答。它要先列出数据集和策略，构造有限实验矩阵，调用校验，等待用户批准，运行回测，读取报告，再比较结果。如果某个实验因缺失数据失败，它还要决定是换数据、缩小范围还是停止。

此时需要一个最小 loop：

目标 → 计划 → 工具调用 → 观察 → 判断 → 下一步 / 终止

但工具接口必须是窄的。模型调用 run_backtest，而不是获得任意 shell；调用 read_report，而不是遍历服务器文件系统。自主性越高，能力边界越应收窄。

第四层：长任务研究 Agent

当一次研究跨越多个任务、需要暂停恢复、人工审批、成本预算和多客户端访问时，轻量 loop 会逐渐长成 Harness：Session 日志、tool call/result 配对、取消、checkpoint、上下文压缩、插件生命周期和权限都要统一处理。

这正是 DSH 可能发挥价值的阶段。它解决的是通用 Agent 的运行问题，不是量化领域本身的问题。

分层之后，谁拥有真相

合理的结构是：

DSH / 研究助手
  ├─ 保存会话、计划、工具轨迹和用户批准
  └─ 通过 HTTP / MCP / CLI 调用
        ↓
a-stock-strategy 应用边界
  ├─ 校验实验、管理任务、读取报告
  └─ 调用
        ↓
确定性研究核心
  └─ 数据、信号、策略、撮合、指标、报告

Harness 拥有“研究过程”的状态，a-stock-strategy 拥有“实验事实”的状态。任务 ID、数据 hash、配置、报告和指标只能以后者为准。不要让 Harness 自己维护一份可修改的净值或交易记录，也不要让两边都认为自己能恢复同一个回测任务。

每次升级都会新增成本

从工具到 AI 增强应用，会增加 prompt、结构化输出、隐私和降级处理；升级到工具型 Agent，会增加 loop、权限、预算和错误恢复；升级到长任务 Harness，会增加事件存储、版本兼容、观测和运维。

因此，每一步都应该回答一个可验证的问题：

  • AI 解释是否明显减少理解报告的时间？
  • Agent 是否能完成原本需要人工串联的研究任务？
  • Harness 是否比自建 loop 更易恢复、更易审计、更便宜维护？

如果答案只是“Demo 更像 Agent”，就不值得升级。

对两个项目的不同路线

Agent Evidence Lab 从一开始就是开放式证据任务，受限 loop 是产品核心，继续强化 trace、checkpoint 和验证器合理。a-stock-strategy 则应先保持工具属性，逐步增加解释、实验助手和外层研究编排。

两者最终都可能出现 LLM、Context 和 Harness，但组合比例不同。前者用 Harness 组织取证；后者用确定性引擎产生事实，Harness 只组织实验。理解这个差别，比选择哪个框架更重要。