uncaged/workflow
10
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

RFC: Merkle DAG Thread Output + ReAct ExtractFn #40

New Issue
Closed
opened 2026-05-07 12:30:20 +00:00 by xiaoju · 5 comments
xiaoju commented 2026-05-07 12:30:20 +00:00
Owner
Copy Link
Copy Source

RFC: 将 workflow 的 step content 存入 CAS，thread 输出为 Merkle DAG root node，workflowAsAgent 返回 root hash。ExtractFn 升级为支持 tool-use 的 ReAct loop，按需遍历 DAG 提取 meta。

动机

workflowAsAgent 需要把子 workflow 的执行结果传递给父 role。核心问题：

  1. content 的本质是自然语言表达的 meta，不是交付物。什么该输出由父 role 的 systemPrompt 决定。
  2. 子 workflow 可能有很多 steps（planner、多轮 coder、reviewer...），全部拼成 content 会污染上下文。
  3. 父 role 通常只关心部分信息（比如写 PR description 只需要 reviewer 结论和 committer 改动列表）。

设计

Part 1: Step Content → CAS

每个 role step 的 content 不再内联写入 .data.jsonl，而是存入 global CAS，jsonl 里只存 hash + meta：

# .data.jsonl 中一行（概念）
role: coder
contentHash: 7BQST3VW4KN...   # CAS hash，指向实际 content
meta: { completedPhase: "ABC...", filesChanged: [...] }
refs: ["7BQST3VW4KN...", "ABC..."]
timestamp: 1715000000000

好处：

  • .data.jsonl 保持紧凑，只有 meta 和 hash
  • content 去重（同样内容同一个 hash）
  • 按需加载 — agent 只 cas get 它关心的 step

Part 2: Thread Root Node (YAML)

workflow 执行结束后，engine 自动生成一个 root node 存入 CAS：

workflow: develop
threadId: 06F03T0DEYWWC7F6J4WJ4GE5R8
depth: 1
steps:
  - role: planner
    contentHash: ABC123DEF45
    meta:
      phases:
        - hash: P1HASH
          title: "Setup project scaffold"
        - hash: P2HASH
          title: "Implement core logic"
  - role: coder
    contentHash: GHI789JKL01
    meta:
      completedPhase: P1HASH
      filesChanged: ["src/main.ts"]
      summary: "Created project structure"
  - role: coder
    contentHash: MNO234PQR56
    meta:
      completedPhase: P2HASH
      filesChanged: ["src/core.ts", "src/utils.ts"]
      summary: "Implemented core logic"
  - role: reviewer
    contentHash: STU789VWX01
    meta:
      status: approved
  - role: committer
    contentHash: YZA234BCD56
    meta:
      status: committed
      branch: "feat/42-new-feature"
result:
  returnCode: 0
  summary: "completed: moderator returned END"

YAML 格式的理由：

  • 对 LLM 更友好，token 更少
  • 人眼 debug 可读性好
  • CAS 是 content-addressed，格式无关

Part 3: workflowAsAgent 返回 root hash

workflowAsAgent("develop")
// 子 workflow 跑完 → 生成 root node → 存 CAS → 返回 root hash string
// 父 role 的 agent 拿到一个 hash，可以 cas get 遍历 DAG

父 role 拿到的 content 就是一个 hash（或简短摘要 + hash），不是一大段文本。

Part 4: ReAct ExtractFn

现在的 ExtractFn：一次 LLM call，content → JSON meta。

对于 workflowAsAgent 场景，content 是一个 DAG root hash。extract 需要：

  1. cas get <root_hash> → 读 root node（YAML）
  2. 看 steps 列表，决定需要读哪些 step 的 content
  3. cas get <step_content_hash> → 读具体 step
  4. 综合信息，按 schema 输出 meta

这是一个 tool-use ReAct loop：think → act (cas get) → observe → think → ... → output。

设计选择

Option A: ExtractFn 原生支持 tool-use

type ExtractFn = (ctx: ExtractContext, tools: ExtractTools) => Promise<Meta>;

type ExtractTools = {
  casGet: (hash: string) => Promise<string | null>;
  // 未来可扩展更多 tools
};

Engine 给 extract 阶段的 LLM call 注册 cas_get tool，让 LLM 自己决定读什么。

Option B: 分层 — 只有 workflowAsAgent 的 extract 走 ReAct

普通 role 的 extract 仍然是一次性 LLM call（content 就是字符串，不需要遍历）。只有当 content 是 DAG hash 时才启用 ReAct loop。

可以通过 RoleDefinition 上的标记区分：

type RoleDefinition<Meta> = {
  // ...existing fields...
  extractMode: "single" | "react";  // 默认 single
};

推荐 Option B — 渐进式，不影响现有 workflow 的性能和成本。

影响面

Breaking Changes

  • .data.jsonl 格式：content 字段变为 contentHash
  • RoleOutput.content 语义变化：从内联文本变为 CAS hash（或保留内联 + 额外存 CAS？）
  • parseThreadDataJsonl 需要适配

兼容策略

  • 渐进迁移：content 仍然写入 jsonl（兼容旧工具），但同时存 CAS
  • root node 是新增能力，不影响旧 thread
  • ReAct extract 是 opt-in

分阶段实施

Phase A: Content → CAS（存储层）

  • engine 写 step 时同时存 content 到 CAS
  • jsonl 增加 contentHash 字段（content 暂时保留以兼容）
  • 生成 thread root node

Phase B: workflowAsAgent 返回 root hash

  • 改 workflowAsAgent 返回 root hash 而非 summary
  • 父 role prompt 指导 agent 用 cas get 读 DAG

Phase C: ReAct ExtractFn

  • ExtractFn 支持 tool-use
  • 只在 extractMode: "react" 时启用

Open Questions

  1. content 在 jsonl 里保留还是去掉？ 保留 = 冗余但兼容，去掉 = 干净但 breaking
  2. root node 格式 — 纯 YAML？还是 YAML frontmatter + markdown body？
  3. ReAct extract 的 LLM provider — 用 workflow 自己的 LlmProvider？还是允许 extract 用不同的 model？
  4. CAS node 之间的 link 语义 — 需要区分 "produced" vs "consumed" 吗？还是 refs 保持扁平？

相关 Issue: #25 (Workflow as Agent), #30-#33 (已完成的 Global CAS + refs + GC + workflowAsAgent)

—— 小橘 🍊（NEKO Team）

RFC: 将 workflow 的 step content 存入 CAS，thread 输出为 Merkle DAG root node，`workflowAsAgent` 返回 root hash。ExtractFn 升级为支持 tool-use 的 ReAct loop，按需遍历 DAG 提取 meta。 --- ## 动机 `workflowAsAgent` 需要把子 workflow 的执行结果传递给父 role。核心问题： 1. **content 的本质是自然语言表达的 meta**，不是交付物。什么该输出由父 role 的 systemPrompt 决定。 2. 子 workflow 可能有很多 steps（planner、多轮 coder、reviewer...），全部拼成 content 会**污染上下文**。 3. 父 role 通常只关心部分信息（比如写 PR description 只需要 reviewer 结论和 committer 改动列表）。 ## 设计 ### Part 1: Step Content → CAS 每个 role step 的 content 不再内联写入 `.data.jsonl`，而是存入 global CAS，jsonl 里只存 hash + meta： ```yaml # .data.jsonl 中一行（概念） role: coder contentHash: 7BQST3VW4KN... # CAS hash，指向实际 content meta: { completedPhase: "ABC...", filesChanged: [...] } refs: ["7BQST3VW4KN...", "ABC..."] timestamp: 1715000000000 ``` 好处： - `.data.jsonl` 保持紧凑，只有 meta 和 hash - content 去重（同样内容同一个 hash） - 按需加载 — agent 只 `cas get` 它关心的 step ### Part 2: Thread Root Node (YAML) workflow 执行结束后，engine 自动生成一个 **root node** 存入 CAS： ```yaml workflow: develop threadId: 06F03T0DEYWWC7F6J4WJ4GE5R8 depth: 1 steps: - role: planner contentHash: ABC123DEF45 meta: phases: - hash: P1HASH title: "Setup project scaffold" - hash: P2HASH title: "Implement core logic" - role: coder contentHash: GHI789JKL01 meta: completedPhase: P1HASH filesChanged: ["src/main.ts"] summary: "Created project structure" - role: coder contentHash: MNO234PQR56 meta: completedPhase: P2HASH filesChanged: ["src/core.ts", "src/utils.ts"] summary: "Implemented core logic" - role: reviewer contentHash: STU789VWX01 meta: status: approved - role: committer contentHash: YZA234BCD56 meta: status: committed branch: "feat/42-new-feature" result: returnCode: 0 summary: "completed: moderator returned END" ``` YAML 格式的理由： - 对 LLM 更友好，token 更少 - 人眼 debug 可读性好 - CAS 是 content-addressed，格式无关 ### Part 3: workflowAsAgent 返回 root hash ```typescript workflowAsAgent("develop") // 子 workflow 跑完 → 生成 root node → 存 CAS → 返回 root hash string // 父 role 的 agent 拿到一个 hash，可以 cas get 遍历 DAG ``` 父 role 拿到的 content 就是一个 hash（或简短摘要 + hash），不是一大段文本。 ### Part 4: ReAct ExtractFn 现在的 `ExtractFn`：一次 LLM call，content → JSON meta。 对于 workflowAsAgent 场景，content 是一个 DAG root hash。extract 需要： 1. `cas get <root_hash>` → 读 root node（YAML） 2. 看 steps 列表，决定需要读哪些 step 的 content 3. `cas get <step_content_hash>` → 读具体 step 4. 综合信息，按 schema 输出 meta 这是一个 **tool-use ReAct loop**：think → act (cas get) → observe → think → ... → output。 #### 设计选择 **Option A: ExtractFn 原生支持 tool-use** ```typescript type ExtractFn = (ctx: ExtractContext, tools: ExtractTools) => Promise<Meta>; type ExtractTools = { casGet: (hash: string) => Promise<string | null>; // 未来可扩展更多 tools }; ``` Engine 给 extract 阶段的 LLM call 注册 `cas_get` tool，让 LLM 自己决定读什么。 **Option B: 分层 — 只有 workflowAsAgent 的 extract 走 ReAct** 普通 role 的 extract 仍然是一次性 LLM call（content 就是字符串，不需要遍历）。只有当 content 是 DAG hash 时才启用 ReAct loop。 可以通过 `RoleDefinition` 上的标记区分： ```typescript type RoleDefinition<Meta> = { // ...existing fields... extractMode: "single" | "react"; // 默认 single }; ``` **推荐 Option B** — 渐进式，不影响现有 workflow 的性能和成本。 ## 影响面 ### Breaking Changes - `.data.jsonl` 格式：content 字段变为 contentHash - `RoleOutput.content` 语义变化：从内联文本变为 CAS hash（或保留内联 + 额外存 CAS？） - `parseThreadDataJsonl` 需要适配 ### 兼容策略 - 渐进迁移：content 仍然写入 jsonl（兼容旧工具），但同时存 CAS - root node 是新增能力，不影响旧 thread - ReAct extract 是 opt-in ### 分阶段实施 **Phase A: Content → CAS（存储层）** - engine 写 step 时同时存 content 到 CAS - jsonl 增加 contentHash 字段（content 暂时保留以兼容） - 生成 thread root node **Phase B: workflowAsAgent 返回 root hash** - 改 workflowAsAgent 返回 root hash 而非 summary - 父 role prompt 指导 agent 用 cas get 读 DAG **Phase C: ReAct ExtractFn** - ExtractFn 支持 tool-use - 只在 extractMode: "react" 时启用 ## Open Questions 1. **content 在 jsonl 里保留还是去掉？** 保留 = 冗余但兼容，去掉 = 干净但 breaking 2. **root node 格式** — 纯 YAML？还是 YAML frontmatter + markdown body？ 3. **ReAct extract 的 LLM provider** — 用 workflow 自己的 LlmProvider？还是允许 extract 用不同的 model？ 4. **CAS node 之间的 link 语义** — 需要区分 "produced" vs "consumed" 吗？还是 refs 保持扁平？ --- 相关 Issue: #25 (Workflow as Agent), #30-#33 (已完成的 Global CAS + refs + GC + workflowAsAgent) —— 小橘 🍊（NEKO Team）
scottwei commented 2026-05-07 12:43:39 +00:00
Owner
Copy Link
Copy Source
  1. 我们这个DAG是不是应该是每一个 string blob都可以有独立的节点，然后每个 step 和每个thread都是一个 merkle 节点
  2. 我们的merkle 节点是不是应该遵循统一的格式，{ payload: ..., children: [...] } as YAML
  3. 你的 Open Questions
    1. content 在 jsonl 里可以去掉，我们现在还在开发阶段，breaking change 不是问题
    2. root node 有 markdown body 吗？
    3. 我们是不是应该在系统全局配置一个一个公共的 extract provider，作为 core 的一部分可以让每个workflow 和 role import 进来直接用？它的 config 就是放在 uncaged-workflow 在用户空间的配置文件里（我们的maxDepth也是放在那里）
    4. refs 就够了
1. 我们这个DAG是不是应该是每一个 string blob都可以有独立的节点，然后每个 step 和每个thread都是一个 merkle 节点 2. 我们的merkle 节点是不是应该遵循统一的格式，{ payload: ..., children: [...] } as YAML 3. 你的 Open Questions 1. content 在 jsonl 里可以去掉，我们现在还在开发阶段，breaking change 不是问题 2. root node 有 markdown body 吗？ 3. 我们是不是应该在系统全局配置一个一个公共的 extract provider，作为 core 的一部分可以让每个workflow 和 role import 进来直接用？它的 config 就是放在 uncaged-workflow 在用户空间的配置文件里（我们的maxDepth也是放在那里） 4. refs 就够了
xiaoju commented 2026-05-07 12:45:04 +00:00
Author
Owner
Copy Link
Copy Source

逐条回应：

1. 三层 Merkle 节点

同意。所有 CAS 内容统一为 Merkle 节点，三层结构：

  • Blob（叶子）：原始文本内容，children: []
  • Step（中间）：一个 role 的执行结果，children 指向 content blob + 其他 refs
  • Thread Root：整个 thread 的执行摘要，children 指向所有 step 节点

每一层都是 CAS 节点，都可以独立 hash、独立引用。

2. 统一节点格式

# 叶子节点（blob）
payload: |
  Implemented the core logic, added error handling...
children: []

# step 节点
payload:
  role: coder
  meta:
    completedPhase: P1HASH
    filesChanged: [src/main.ts]
    summary: "Implemented core logic"
children:
  - ABC123DEF45   # content blob

# thread root 节点
payload:
  workflow: develop
  threadId: 06F03T0DEYWWC...
  result:
    returnCode: 0
children:
  - STEP1HASH     # planner step
  - STEP2HASH     # coder step (round 1)
  - STEP3HASH     # reviewer step

{ payload, children } as YAML，统一、简洁、可递归。

3. Open Questions 回应

3.1 content 从 jsonl 去掉

✅ Breaking change 没问题。jsonl 里只存 contentHash + meta + refs。

3.2 root node 格式

纯 YAML，无 markdown body。{ payload, children } 格式统一。

3.3 全局 extract provider

同意放用户空间配置。建议扩展现有 workflow.yaml，加 config 顶层 key：

config:
  maxDepth: 3
  extract:
    provider: dashscope
    model: qwen-plus
    baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1
    apiKey: env:DASHSCOPE_API_KEY

workflows:
  solve-issue:
    hash: SPVR4BDMSGC1W
    ...

apiKey: env:DASHSCOPE_API_KEY 表示从环境变量读取，不硬编码 secret。这样 @uncaged/workflow core 可以导出一个 getExtractProvider(storageRoot) 给所有 role 直接用。

3.4 refs 扁平

✅ 不区分 produced/consumed，保持简单。

下一步

如果方向 OK，我来更新实施计划，拆成：

  • Phase A: 统一 Merkle 节点格式 + content → CAS
  • Phase B: Thread root node 生成 + workflowAsAgent 返回 root hash
  • Phase C: 全局 extract provider 配置
  • Phase D: ReAct ExtractFn

—— 小橘 🍊（NEKO Team）

逐条回应： ## 1. 三层 Merkle 节点 同意。所有 CAS 内容统一为 Merkle 节点，三层结构： - **Blob**（叶子）：原始文本内容，`children: []` - **Step**（中间）：一个 role 的执行结果，children 指向 content blob + 其他 refs - **Thread Root**：整个 thread 的执行摘要，children 指向所有 step 节点 每一层都是 CAS 节点，都可以独立 hash、独立引用。 ## 2. 统一节点格式 ```yaml # 叶子节点（blob） payload: | Implemented the core logic, added error handling... children: [] # step 节点 payload: role: coder meta: completedPhase: P1HASH filesChanged: [src/main.ts] summary: "Implemented core logic" children: - ABC123DEF45 # content blob # thread root 节点 payload: workflow: develop threadId: 06F03T0DEYWWC... result: returnCode: 0 children: - STEP1HASH # planner step - STEP2HASH # coder step (round 1) - STEP3HASH # reviewer step ``` `{ payload, children }` as YAML，统一、简洁、可递归。 ## 3. Open Questions 回应 ### 3.1 content 从 jsonl 去掉 ✅ Breaking change 没问题。jsonl 里只存 `contentHash` + `meta` + `refs`。 ### 3.2 root node 格式 纯 YAML，无 markdown body。`{ payload, children }` 格式统一。 ### 3.3 全局 extract provider 同意放用户空间配置。建议扩展现有 `workflow.yaml`，加 `config` 顶层 key： ```yaml config: maxDepth: 3 extract: provider: dashscope model: qwen-plus baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1 apiKey: env:DASHSCOPE_API_KEY workflows: solve-issue: hash: SPVR4BDMSGC1W ... ``` `apiKey: env:DASHSCOPE_API_KEY` 表示从环境变量读取，不硬编码 secret。这样 `@uncaged/workflow` core 可以导出一个 `getExtractProvider(storageRoot)` 给所有 role 直接用。 ### 3.4 refs 扁平 ✅ 不区分 produced/consumed，保持简单。 ## 下一步 如果方向 OK，我来更新实施计划，拆成： - Phase A: 统一 Merkle 节点格式 + content → CAS - Phase B: Thread root node 生成 + workflowAsAgent 返回 root hash - Phase C: 全局 extract provider 配置 - Phase D: ReAct ExtractFn —— 小橘 🍊（NEKO Team）
xiaoju commented 2026-05-07 12:55:09 +00:00
Author
Owner
Copy Link
Copy Source

补充：讨论结论汇总

以下是 RFC 正文之后的讨论中确认的设计决策，作为正式补充。

1. Merkle 节点统一格式 + type 判别

所有 CAS 节点遵循统一结构：

type: content | step | thread
payload: ...
children:
  - HASH1
  - HASH2

三种 type，payload 结构各不同：

type payload 含义
content string（自然语言） role 输出的内容，可以是叶子也可以带子节点
step { role, meta } 一个 role 的执行结果
thread { workflow, threadId, result } 整个 thread 的执行摘要

2. Content 节点不一定是叶子

Content 节点可以有 children。典型场景是 planner：

type: content
payload: |
  4 phases:
  1. Global CAS migration → P1HASH
  2. Refs tracking → P2HASH
  3. GC → P3HASH
  4. workflowAsAgent factory → P4HASH
children:
  - P1HASH
  - P2HASH
  - P3HASH
  - P4HASH

payload 里内联引用 children hash — 这是语义关联（agent 读 payload 知道哪个 item 对应哪个 detail），children 数组是结构关联（GC 用的引用追踪）。两者互补，类似 markdown 里 [text](url)。

每个 phase detail 是叶子：

type: content
payload: |
  # Global CAS Migration
  Description: Move CAS from thread-local to global...
  Acceptance: All tests pass, CLI uses global dir
children: []

3. 完整的树结构示例

Thread Root (type: thread)
├── Planner Step (type: step, role: planner)
│   └── Planner Content (type: content, summary + children)
│       ├── Phase 1 Detail (type: content, leaf)
│       ├── Phase 2 Detail (type: content, leaf)
│       ├── Phase 3 Detail (type: content, leaf)
│       └── Phase 4 Detail (type: content, leaf)
├── Coder Step (type: step, role: coder)
│   └── Coder Content (type: content, leaf)
├── Reviewer Step (type: step, role: reviewer)
│   └── Reviewer Content (type: content, leaf)
└── Committer Step (type: step, role: committer)
    └── Committer Content (type: content, leaf)

4. 已确认的 Breaking Changes

  • .data.jsonl 中 content 字段去掉，改为 contentHash
  • 开发阶段，breaking change 不是问题

5. 全局配置

扩展 workflow.yaml，加 config 顶层 key：

config:
  maxDepth: 3
  extract:
    baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1
    model: qwen-plus
    apiKey: env:DASHSCOPE_API_KEY

workflows:
  solve-issue:
    hash: SPVR4BDMSGC1W
    ...

@uncaged/workflow core 导出 getExtractProvider(storageRoot) 供所有 role 使用。

6. refs 保持扁平

不区分 produced/consumed，GC 只看 children 数组。

以上作为 RFC #40 的正式补充，后续实施计划将基于这些决策展开。

—— 小橘 🍊（NEKO Team）

## 补充：讨论结论汇总 以下是 RFC 正文之后的讨论中确认的设计决策，作为正式补充。 --- ### 1. Merkle 节点统一格式 + type 判别 所有 CAS 节点遵循统一结构： ```yaml type: content | step | thread payload: ... children: - HASH1 - HASH2 ``` 三种 type，payload 结构各不同： | type | payload | 含义 | |------|---------|------| | `content` | `string`（自然语言） | role 输出的内容，可以是叶子也可以带子节点 | | `step` | `{ role, meta }` | 一个 role 的执行结果 | | `thread` | `{ workflow, threadId, result }` | 整个 thread 的执行摘要 | ### 2. Content 节点不一定是叶子 Content 节点可以有 children。典型场景是 planner： ```yaml type: content payload: | 4 phases: 1. Global CAS migration → P1HASH 2. Refs tracking → P2HASH 3. GC → P3HASH 4. workflowAsAgent factory → P4HASH children: - P1HASH - P2HASH - P3HASH - P4HASH ``` **payload 里内联引用 children hash** — 这是语义关联（agent 读 payload 知道哪个 item 对应哪个 detail），children 数组是结构关联（GC 用的引用追踪）。两者互补，类似 markdown 里 `[text](url)`。 每个 phase detail 是叶子： ```yaml type: content payload: | # Global CAS Migration Description: Move CAS from thread-local to global... Acceptance: All tests pass, CLI uses global dir children: [] ``` ### 3. 完整的树结构示例 ``` Thread Root (type: thread) ├── Planner Step (type: step, role: planner) │ └── Planner Content (type: content, summary + children) │ ├── Phase 1 Detail (type: content, leaf) │ ├── Phase 2 Detail (type: content, leaf) │ ├── Phase 3 Detail (type: content, leaf) │ └── Phase 4 Detail (type: content, leaf) ├── Coder Step (type: step, role: coder) │ └── Coder Content (type: content, leaf) ├── Reviewer Step (type: step, role: reviewer) │ └── Reviewer Content (type: content, leaf) └── Committer Step (type: step, role: committer) └── Committer Content (type: content, leaf) ``` ### 4. 已确认的 Breaking Changes - `.data.jsonl` 中 content 字段去掉，改为 contentHash - 开发阶段，breaking change 不是问题 ### 5. 全局配置 扩展 `workflow.yaml`，加 `config` 顶层 key： ```yaml config: maxDepth: 3 extract: baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1 model: qwen-plus apiKey: env:DASHSCOPE_API_KEY workflows: solve-issue: hash: SPVR4BDMSGC1W ... ``` `@uncaged/workflow` core 导出 `getExtractProvider(storageRoot)` 供所有 role 使用。 ### 6. refs 保持扁平 不区分 produced/consumed，GC 只看 children 数组。 --- 以上作为 RFC #40 的正式补充，后续实施计划将基于这些决策展开。 —— 小橘 🍊（NEKO Team）
xiaoju commented 2026-05-07 13:02:44 +00:00
Author
Owner
Copy Link
Copy Source

Phase Testing Issues

  • Phase A: Merkle 节点格式 + Content → CAS → #41
  • Phase B: Thread Root Node + workflowAsAgent 返回 root hash → #42
  • Phase C: 全局 extract provider 配置 → #43
  • Phase D: ReAct ExtractFn → #44

串行实施：A → B → C → D

—— 小橘 🍊（NEKO Team）

## Phase Testing Issues - Phase A: Merkle 节点格式 + Content → CAS → #41 - Phase B: Thread Root Node + workflowAsAgent 返回 root hash → #42 - Phase C: 全局 extract provider 配置 → #43 - Phase D: ReAct ExtractFn → #44 串行实施：A → B → C → D —— 小橘 🍊（NEKO Team）
xiaoju commented 2026-05-07 13:28:43 +00:00
Author
Owner
Copy Link
Copy Source

验证结果汇总

  • ✅ Phase A: Merkle 节点格式 + Content → CAS (#41, PR #45) — 150 tests
  • ✅ Phase B: Thread Root Node + workflowAsAgent 返回 root hash (#42, PR #51) — 151 tests
  • ✅ Phase C: 全局 extract provider 配置 (#43, PR #52) — 158 tests
  • ✅ Phase D: ReAct ExtractFn (#44, PR #53) — 162 tests

新增能力

能力 描述
Merkle DAG { type, payload, children } YAML 节点，三层：content → step → thread
Content → CAS role step content 不再内联 jsonl，存为 CAS Merkle 节点
Thread Root workflow 执行完自动生成 root node，workflowAsAgent 返回 root hash
全局配置 workflow.yaml config 段：maxDepth + extract provider
ReAct Extract extractMode: "react" 启用 tool-use loop，cas_get 遍历 DAG

测试增长

129 → 162 tests（+33），从 #25 开始累计 +33 tests。

RFC #40 完成，Close。

—— 小橘 🍊（NEKO Team）

## 验证结果汇总 - ✅ Phase A: Merkle 节点格式 + Content → CAS (#41, PR #45) — 150 tests - ✅ Phase B: Thread Root Node + workflowAsAgent 返回 root hash (#42, PR #51) — 151 tests - ✅ Phase C: 全局 extract provider 配置 (#43, PR #52) — 158 tests - ✅ Phase D: ReAct ExtractFn (#44, PR #53) — 162 tests ## 新增能力 | 能力 | 描述 | |------|------| | Merkle DAG | `{ type, payload, children }` YAML 节点，三层：content → step → thread | | Content → CAS | role step content 不再内联 jsonl，存为 CAS Merkle 节点 | | Thread Root | workflow 执行完自动生成 root node，workflowAsAgent 返回 root hash | | 全局配置 | workflow.yaml config 段：maxDepth + extract provider | | ReAct Extract | extractMode: "react" 启用 tool-use loop，cas_get 遍历 DAG | ## 测试增长 129 → 162 tests（+33），从 #25 开始累计 +33 tests。 RFC #40 完成，Close。 —— 小橘 🍊（NEKO Team）
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/workflow#40
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?