HyDE: HY Data Engine 架构设计

HyDE 的定位：驱动模型进化的”智能引擎”——持续生产演进、全球 SoTA 基准、前瞻布局下一代 Scaling Law 所需的非公开高复杂度数据。

---

一、设计理念

1.1 三个核心目标

目标	含义
持续生产演进	构建让数据持续生产、持续改善模型的系统能力，而非单一的数据交付
全球 SoTA 基准	聚焦 Agent 核心赛道，数据质量对标全球 SoTA 水平
前瞻布局	布局下一代 Scaling Law 所需的非公开、高复杂度数据

1.2 双受众设计

HyDE 的门户站点（hyde.woa.com）同时服务两类用户：

面向人：

• 各个数据生产管线的实时运行情况
• 技术方案文档与 Case 抽样审阅
• 模型侧使用效果反馈管理

面向 AI（Agent-Friendly Design）：

• 定义好数据规范，做好生产过程的 Memory 管理
• 让 AI 可以获取全面的 context，自主参与数据生产

---

二、三层架构总览

┌─────────────────────────────────────────────┐
│  Layer 3: Portal — hyde.woa.com 数据门户     │  ← 可视化 / 监控 / 审阅 / API
├─────────────────────────────────────────────┤
│            ▲ 状态上报 · 轨迹回传              │
├─────────────────────────────────────────────┤
│  Layer 2: Pipelines — 数据合成管线集群        │  ← 框架的实例化
├─────────────────────────────────────────────┤
│            ▲ 实例化 · 角色调度 · 沙箱分配      │
├─────────────────────────────────────────────┤
│  Layer 1: Foundation — HyDE Core Framework  │  ← Agent 编排框架
├─────────────────────────────────────────────┤
│  🧠 Memory Layer（贯穿三层）                  │  ← 统一记忆管理
└─────────────────────────────────────────────┘

---

三、Layer 1: Foundation — HyDE Core Framework

底层是一个通用的 Agent 编排框架，所有管线的共同底座。

3.1 核心模块

模块	职责	关键能力
Multi-Agent 编排	定义角色、编排协作流程	声明式角色定义（YAML/DSL）；角色间消息传递与协作协议；DAG / 循环 / 条件分支流程图；渐进提示 & 人机协作模式
工具 & 能力层	连接外部模型和工具	MCP Server 集成（标准协议）；Skills 注册与发现；模型路由（Opus/Sonnet/本地 vLLM）；Code Interpreter / Shell
沙箱 & 环境	安全隔离的执行环境	Docker 容器生命周期管理；Git 状态快照 & 恢复；网络隔离 / 资源限制；环境模板（Python/TS/Go/Rust）
遥测 & 上报	运行状态实时同步	结构化事件流（轨迹/状态/产出）；与 Portal 实时同步；管线健康度指标；自动告警 & 重试
数据规范	统一的输入输出标准	统一 Schema 定义（任务/轨迹/产出）；版本管理 & 血缘追踪；质量元数据自动附加；输出格式适配（JSONL/Parquet）
插件 & 扩展	可扩展性	自定义 Hook（pre/post 每步操作）；Reward 函数注册；自定义 Reviewer 逻辑；第三方 API 适配器

3.2 设计原则

• 声明式优先：管线定义用 YAML/DSL，不写 Python 胶水代码
• 沙箱隔离：每次执行都在独立 Docker 容器中，可复现
• 遥测内置：不是可选插件，每一步操作自动上报，Portal 实时可见
• 规范先行：所有管线产出遵循统一 Schema，跨管线数据可组合

---

四、Layer 2: Pipelines — 数据合成管线集群

中间层是 Framework 的实例化——每条管线是一组 Agent 角色 + 工具链 + 沙箱配置的组合。

4.1 当前管线

管线	用途	Agent 流程
🏗️ HarnessForge	从 repo 历史合成长程复合开发任务 + 完整探索轨迹	Architect → PM → Test Crafter → Dev → Reviewer
🧬 SkillSynth	技能图谱驱动的终端 Agent 数据合成	Skill Sampler → Task Gen → Executor → Verifier
🔬 ScienceForge	论文复现 + 科研实验数据合成	Paper Parser → Hypothesis → Experiment → Analyst
🛡️ SafetyForge	对抗性安全数据 + 对齐偏好对合成	Red Team → Attacker → Defender → Judge
📊 DataBench	NL2SQL / 数据分析任务合成	Schema Miner → Query Gen → Executor → Validator

4.2 管线创建方式

通过框架 DSL 定义角色 + 工具 + 沙箱即可创建新管线：

pipeline:
  name: "HarnessForge"
  description: "从 repo 历史合成长程复合任务"
  
  roles:
    - name: "Architect"
      model: "claude-sonnet-4.5"
      tools: [git_log, file_tree, semantic_search]
      output: "clusters.jsonl"
      
    - name: "PM"
      model: "claude-opus-4.6"
      input_from: "Architect.clusters"
      tools: [read_diff, read_pr]
      output: "tasks.yaml"
      hint_protocol:
        enabled: true
        levels: [L1, L2, L3]
      
    - name: "Dev"
      model: "claude-sonnet-4.5"
      input_from: "PM.tasks"
      sandbox: { type: "docker", image: "repo-base", network: "none" }
      tools: [read_file, edit_file, bash, grep]
      max_turns: 50
      
    - name: "Reviewer"
      model: "claude-opus-4.6"
      input_from: "Dev.trajectories"
      output: "verified_tasks/"
  
  telemetry:
    report_to: "portal"
    events: [step_complete, test_result, hint_released, task_verdict]

4.3 管线间数据复用

不同管线的产出可以互相作为输入：

• HarnessForge 产出的 verified tasks → 可作为 DataBench 的复杂查询参考
• ScienceForge 发现的实验模式 → 可反馈到 SkillSynth 的技能图谱
• SafetyForge 发现的攻击向量 → 可注入其他管线做鲁棒性测试

---

五、Layer 3: Portal — hyde.woa.com

最上层是面向人和 AI 的统一入口。

5.1 面向人的功能

功能	说明
管线仪表盘	所有管线实时运行状态、产出量、成功率、异常告警
Case 抽样审阅	每条管线的产出样本抽检、人工标注审批、质量趋势追踪
效果反馈环	模型训练后的 benchmark 变化、A/B 测试结果、数据-效果归因
技术方案库	每条管线的设计文档、参数配置、迭代历史

5.2 面向 AI 的功能（Agent API）

接口	用途
管线元数据	AI 查询管线配置、运行状态、历史产出统计
数据规范	AI 获取任务/轨迹/产出的 Schema 定义，确保输出合规
Context 注入	AI 获取当前任务的完整上下文（相关管线历史、类似 case、质量标准）
Memory 读写	AI 读写 Pipeline Memory，积累跨次运行的经验

5.3 Portal 与管线的数据流

Pipeline (运行中)
  → 每一步操作产生结构化事件
  → 通过 Framework 遥测层上报
  → Portal 实时接收并渲染

Portal (审阅)
  → 人工审阅 Case
  → 标注质量评分
  → 反馈写入 Pipeline Memory
  → 下次运行时 Agent 读取反馈调整行为

---

六、Memory Layer — 贯穿三层的统一记忆

Memory 不属于任何单一层级，而是由 Framework 实现、Pipeline 消费、Portal 展示的横切关注点。

6.1 四级记忆架构

层级	生命周期	内容	访问者
Global Knowledge	永久	数据规范文档、Repo 元信息库、评测基准映射表	所有管线 + Portal
Pipeline Memory	管线级	管线运行历史、成功/失败模式库、Prompt 模板版本、质量趋势	同一管线的所有运行
Agent Session	单次运行	当前任务状态、Tool 调用历史、中间产物缓存	当前运行的 Agent
Feedback Loop	跨周期	模型训练效果回传、数据→效果归因、参数自动调优信号	Pipeline + Portal

6.2 Memory 访问模式

• Framework 提供 Memory 的存储引擎和 API（实现层）
• Pipeline 通过 API 读写自己的运行历史和经验模式（消费层）
• Portal 读取 Memory 展示全局状态和趋势（展示层）

6.3 为什么 Memory 在 Framework 层实现

Memory 是框架的核心基础设施，而不是某条管线的私有功能。原因：

1. 跨管线共享：Global Knowledge 需要所有管线都能访问
2. 统一存储：不同管线的 Memory 用同一套存储引擎，便于检索和分析
3. Portal 直接读取：Portal 不需要经过 Pipeline 中转就能读取 Memory
4. 持久化保障：Framework 管理生命周期，确保管线异常退出时 Memory 不丢失

---

七、关键设计决策

决策	选择	替代方案	理由
管线定义方式	声明式 YAML/DSL	Python 代码	降低创建门槛，Portal 可直接解析展示
沙箱方案	Docker	Firecracker / E2B	Docker 够用且免费，大规模时可升级
Agent 框架	自研 HyDE Core	OpenHarness / LangGraph	需要深度定制遥测和 Memory，现有框架不满足
Memory 存储	结构化文件 + 向量索引	纯数据库	文件便于 Agent 直接读取，向量索引支持语义搜索
遥测协议	结构化事件流	OpenTelemetry	需要 Agent 特有的事件类型（hint、direction_change），标准协议太通用

---

八、与 HarnessForge 的关系

HarnessForge 是 HyDE 管线集群中的旗舰管线——它体现了 HyDE 的所有核心能力：

HyDE 能力	HarnessForge 中的体现
Multi-Agent 编排	5 个角色（Architect → PM → Test Crafter → Dev → Reviewer）
渐进提示协议	PM 的 L0-L3 四级提示机制
沙箱环境	Docker + Git 快照，30 个 repo 环境模板
遥测上报	每步操作上报 Portal，含 hint_released、direction_change 等自定义事件
Memory	Pipeline Memory 积累成功/失败模式，Reviewer 判断写回 Memory 供后续运行参考
数据规范	统一的 task.yaml → trajectory.jsonl → verified_task.yaml 格式

其他管线（SkillSynth、ScienceForge 等）复用同一套框架能力，只是角色定义和工具组合不同。