先给结论

判断一个系统是否需要 Harness，关键不是“它有没有调用大模型”，而是：下一步动作是否必须由模型在运行时持续决定。

如果输入、计算过程和输出都能提前写成稳定流程，那么普通应用层、任务队列和状态机通常更可靠。只有当任务需要模型反复观察环境、选择工具、修正路径，并且这些分支无法在开发时穷举，Harness 才开始提供独特价值。

用两个项目做对照

a-stock-strategy 的核心链路是确定性的：

数据集 → 校验 → 市场信号 → 选股 → 回测撮合 → 指标 → 报告

同一份数据、配置和代码版本应得到同一个结果。DatasetRepository 管数据，validate_request 拒绝非法实验，BacktestEngine 执行撮合，write_report 固化结果，JobManager 管异步任务。这些职责适合显式代码，不适合交给模型临场发挥。

Agent Evidence Lab 则不同。用户提出开放问题后，系统需要判断还缺什么证据、调用哪个检索工具、如何处理冲突，以及证据是否足以停止：

问题 → 选择工具 → 观察结果 → 更新上下文 → 决定继续或结束
                  ↑__________________________|

这里的循环路径取决于中间观察，Harness 正好负责承载这种运行时决策。

六个判断问题

1. 流程能否在运行前画完

能画完的流程优先写成 workflow。批量下载行情、校验数据、跑回测、生成报告，即使步骤很多，也仍是工作流，而不是 Agent。

如果只能定义目标和边界，无法预先确定工具顺序，例如“找出这次回测异常的原因，并根据发现继续取证”，才更像 Harness 问题。

2. 模型是生成一次，还是持续决策

让模型解释 summary.json 是一次推理；让模型决定下一组参数、启动实验、读取结果、发现异常后再追加实验，是循环决策。前者只需要受控的 LLM adapter，后者才需要 loop、tool protocol、budget、trace 和 recovery。

3. 外部动作有多少、风险多大

工具越多，副作用越强，越需要 Harness 的统一审批、超时、取消和审计。但 Harness 只提供执行秩序，不会自动让动作安全。下载数据、覆盖文件和启动昂贵任务仍需业务层做权限和幂等控制。

4. 任务是否跨越较长时间

一个数秒完成的摘要调用无需复杂会话恢复。一个可能持续数小时、经历多个任务和人工确认的研究过程，需要 append-only 事件、checkpoint、恢复和资源收敛。此时 Harness 的基础设施价值才会显现。

5. 正确性来自哪里

量化回测的正确性来自数据时点、交易规则、费用模型和可复现计算；Harness 无法替代这些约束。研究 Agent 的正确性还依赖“观察过什么、为何调用工具、结论引用什么”，因此需要保存完整交互轨迹。

6. 引入后是否真的减少系统总复杂度

不能只数少写了多少 loop 代码，还要把 Node 运行时、插件 API、版本升级、跨进程协议、两套状态存储和排障成本算进去。如果新增基础设施比省下的编排代码更多，就不应接入。

一个实用的决策表

确定步骤 + 确定输出                     → 普通服务 / workflow
确定步骤 + 需要自然语言解释             → LLM 增强应用
不确定步骤 + 少量工具 + 单次会话         → 轻量自建 loop
不确定步骤 + 多工具 + 长任务 + 恢复/审批  → Harness

这不是成熟度等级。一个可靠的确定性工具并不比 Agent “低级”。架构应该服从问题形状，而不是技术潮流。

对 a-stock-strategy 的判断

它的交易研究核心目前不需要 DSH。数据、信号、撮合、绩效和推荐都必须保持确定性。可选的大模型摘要层也不构成接入理由，因为模型只解释已经生成的事实。

未来若要支持“围绕一个研究目标自主设计多轮实验”，可以在核心外增加 Harness：它读取可用数据和策略，提出实验，经过校验与批准后运行，比较多份报告，再决定是否继续。此时 DSH 承担的是研究编排，而不是交易逻辑。

最容易误判的三种情况

  • “用了 Tool Calling，所以是 Agent”：一次结构化调用仍可能只是普通应用逻辑。
  • “步骤很多，所以需要 Harness”：复杂 workflow 仍可以完全确定。
  • “接入框架就获得安全和正确性”：Harness 提供机制，业务系统仍要定义规则和事实源。

真正的分界线始终是：系统是否需要让模型在一个受限循环中，根据新观察改变下一步。