agentleFS
konglong87konglong87/enjoy_harness_ai/skills/harness-build-deterministic-workflow/SKILL.md

harness-build-deterministic-workflow

Skill0 starsChanged 8 months agoMITView on GitHub

构建确定性工作流,将任务拆解为确定性节点和Agentic节点,实现可预测的执行路径

The file

Files
SKILL.md

harness-build-deterministic-workflow 构建确定性工作流技能

核心能力

  1. 检查前置条件(harness-build-context-index)
  2. 创建 WORKFLOW_TEMPLATES.md
  3. 定义确定性节点(无需LLM)
  4. 定义Agentic节点(需要LLM)
  5. 定义工作流组合模板

前置条件

  • harness-build-context-index 已完成
  • CONTEXT_INDEX.md 存在

执行步骤

Step 1: 检查前置条件

使用 Read 工具读取:.EnjoyHarness/SKILL_REGISTRY.md

检查条件:

  • harness-build-context-index 已标记为完成

如果未完成:

❌ 错误: 上下文索引未构建
💡 请先运行: harness-build-context-index

Step 2: 创建工作流模板文件

使用 Write 工具创建文件:.EnjoyHarness/WORKFLOW_TEMPLATES.md

内容:

---
version: v3.0.0
created_at: 2026-03-28T11:00:00+08:00
total_workflows: 5
---

# EnjoyHarness 工作流模板库

## 确定性节点 vs Agentic 节点

### 确定性节点(Deterministic Nodes)
**特征**: 无需LLM决策,规则明确,结果可预测
**优势**:
- 执行速度快(毫秒级)
- Token消耗低(仅验证)
- 结果可复现
- 易于测试

**示例**:
- 文件格式校验(JSON/YAML/Markdown)
- 代码风格检查(lint)
- 测试运行(unit/integration)
- 构建编译(compile)
- Git 操作(commit/push)

### Agentic 节点(Agentic Nodes)
**特征**: 需要LLM决策,涉及理解、创造、推理
**特点**:
- 执行速度慢(秒级)
- Token消耗高
- 结果不确定
- 需要验证

**示例**:
- 需求理解(用户意图分析)
- 架构设计(技术选型)
- 代码实现(功能开发)
- 错误诊断(根因分析)
- 文档编写(说明文档)

## 工作流模板

### 模板 1: 功能开发工作流

```mermaid
graph TD
    A[需求输入] --> B[确定性: 格式校验]
    B --> C[Agentic: 需求理解]
    C --> D[Agentic: 架构设计]
    D --> E[确定性: 设计校验]
    E --> F[Agentic: 功能实现]
    F --> G[确定性: 代码检查]
    G --> H[Agentic: 测试编写]
    H --> I[确定性: 测试运行]
    I --> J[确定性: 结果归档]

节点详情:

节点类型执行方式Token消耗失败处理
A: 需求输入输入用户输入0终止
B: 格式校验确定性JSON Schema校验~100返回B,提示修正
C: 需求理解AgenticLLM分析~2000返回A,补充信息
D: 架构设计AgenticLLM推理~3000返回C,简化需求
E: 设计校验确定性架构护栏检查~200返回D,重新设计
F: 功能实现AgenticLLM编码~5000返回F,重试1次
G: 代码检查确定性Lint + 架构检查~500返回F,修复问题
H: 测试编写AgenticLLM生成测试~3000返回H,补充用例
I: 测试运行确定性测试框架执行~1000返回F,修复失败
J: 结果归档确定性文件写入~200终止,触发自动失败处理;真实阻塞再升级

Token 预算: ~14,800 tokens 预计时长: 10-15分钟

模板 2: Bug修复工作流

graph TD
    A[Bug报告输入] --> B[确定性: 信息提取]
    B --> C[Agentic: 根因分析]
    C --> D[Agentic: 修复方案]
    D --> E[确定性: 方案校验]
    E --> F[Agentic: 修复实现]
    F --> G[确定性: 回归测试]
    G --> H[确定性: 修复验证]

节点详情:

节点类型执行方式Token消耗失败处理
A: Bug报告输入输入用户提交0终止
B: 信息提取确定性正则提取~100返回A,补充信息
C: 根因分析AgenticLLM推理~4000返回A,补充日志
D: 修复方案AgenticLLM推理~2000返回C,重新分析
E: 方案校验确定性架构检查~200返回D,调整方案
F: 修复实现AgenticLLM编码~3000返回F,重试1次
G: 回归测试确定性测试框架~1000返回F,修复问题
H: 修复验证确定性手动验证~500返回F,重新修复

Token 预算: ~10,800 tokens 预计时长: 8-12分钟

模板 3: 重构优化工作流

graph TD
    A[优化目标输入] --> B[Agentic: 影响范围分析]
    B --> C[确定性: 依赖检查]
    C --> D[Agentic: 重构方案]
    D --> E[确定性: 风险评估]
    E --> F[Agentic: 重构实现]
    F --> G[确定性: 性能测试]
    G --> H[确定性: 回归测试]

节点详情:

节点类型执行方式Token消耗失败处理
A: 优化目标输入输入用户输入0终止
B: 影响范围分析AgenticLLM分析~3000返回A,明确范围
C: 依赖检查确定性AST分析~500返回A,调整范围
D: 重构方案AgenticLLM推理~4000返回B,重新分析
E: 风险评估确定性规则检查~300返回D,降低风险
F: 重构实现AgenticLLM编码~5000返回F,重试1次
G: 性能测试确定性Benchmark~1000返回F,优化性能
H: 回归测试确定性测试框架~1000返回F,修复问题

Token 预算: ~14,800 tokens 预计时长: 15-20分钟

模板 4: 文档编写工作流

graph TD
    A[文档需求输入] --> B[确定性: 模板选择]
    B --> C[Agentic: 内容生成]
    C --> D[确定性: 格式校验]
    D --> E[Agentic: 内容优化]
    E --> F[确定性: 文档归档]

节点详情:

节点类型执行方式Token消耗失败处理
A: 文档需求输入输入用户输入0终止
B: 模板选择确定性规则匹配~100默认模板
C: 内容生成AgenticLLM生成~3000返回A,补充信息
D: 格式校验确定性Markdown检查~200返回C,修正格式
E: 内容优化AgenticLLM优化~2000返回C,重新生成
F: 文档归档确定性文件写入~100终止,触发自动失败处理;真实阻塞再升级

Token 预算: ~5,400 tokens 预计时长: 5-8分钟

模板 5: 配置更新工作流

graph TD
    A[配置变更输入] --> B[确定性: 格式校验]
    B --> C[确定性: 依赖检查]
    C --> D[确定性: 变更应用]
    D --> E[确定性: 配置验证]
    E --> F[确定性: 服务重启]
    F --> G[确定性: 健康检查]

节点详情:

节点类型执行方式Token消耗失败处理
A: 配置变更输入输入用户输入0终止
B: 格式校验确定性Schema校验~100返回A,修正格式
C: 依赖检查确定性配置解析~200返回A,调整配置
D: 变更应用确定性文件写入~100终止,触发自动失败处理;真实阻塞再升级
E: 配置验证确定性配置测试~300回滚D
F: 服务重启确定性系统命令~200回滚D
G: 健康检查确定性HTTP检查~100回滚D,触发自动失败处理;真实阻塞再升级

Token 预算: ~1,000 tokens 预计时长: 2-3分钟

工作流选择策略

自动选择(基于任务类型)

任务类型识别:
  包含关键词:
    - "实现" / "开发" / "添加" → 功能开发工作流
    - "修复" / "解决" / "Bug" → Bug修复工作流
    - "重构" / "优化" / "改进" → 重构优化工作流
    - "文档" / "说明" / "README" → 文档编写工作流
    - "配置" / "更新" / "修改" → 配置更新工作流

手动指定(用户显式指定)

用户指定:
  示例: "使用 Bug修复工作流 修复登录失败问题"
  动作: 直接应用模板 2

确定性节点优化

优化原理

  • 确定性节点无需LLM,执行速度快
  • 将更多节点设计为确定性节点可降低Token消耗
  • 确定性节点结果可缓存,提高复用率

优化策略

策略 1: 模板化

将重复性工作模板化:

  • 代码生成模板(CRUD操作)
  • 测试用例模板(单元测试)
  • 文档模板(API文档)

策略 2: 规则化

将决策逻辑规则化:

  • 架构检查规则(ARCHITECTURE_GUARDRAILS.md)
  • 代码风格规则(lint配置)
  • 测试规则(覆盖率阈值)

策略 3: 工具化

使用专用工具替代LLM:

  • 格式校验:JSON Schema Validator
  • 代码检查:ESLint / golangci-lint
  • 测试运行:pytest / go test

工作流执行监控

监控指标

  1. 节点执行时间: 每个节点的耗时
  2. Token消耗: Agentic节点的Token使用
  3. 失败率: 每个节点的失败概率
  4. 重试次数: 节点的重试统计

监控方式

每个节点执行后:
  - 记录到 .EnjoyHarness/EVENT_LOG.md
  - 更新 .EnjoyHarness/GLOBAL_STATE.md
  - 增加迭代计数 ITERATION_COUNTER.md

使用示例

示例 1: 功能开发任务

任务: 实现用户登录功能
识别: 功能开发工作流
节点执行:
  1. 格式校验 ✅ (100 tokens)
  2. 需求理解 ✅ (2000 tokens)
  3. 架构设计 ✅ (3000 tokens)
  4. 设计校验 ✅ (200 tokens)
  5. 功能实现 ✅ (5000 tokens)
  6. 代码检查 ✅ (500 tokens)
  7. 测试编写 ✅ (3000 tokens)
  8. 测试运行 ✅ (1000 tokens)
  9. 结果归档 ✅ (200 tokens)

总Token: 14,000 tokens
总时长: 12分钟

示例 2: Bug修复任务

任务: 修复登录失败Bug
识别: Bug修复工作流
节点执行:
  1. 信息提取 ✅ (100 tokens)
  2. 根因分析 ✅ (4000 tokens)
  3. 修复方案 ✅ (2000 tokens)
  4. 方案校验 ✅ (200 tokens)
  5. 修复实现 ✅ (3000 tokens)
  6. 回归测试 ✅ (1000 tokens)
  7. 修复验证 ✅ (500 tokens)

总Token: 10,800 tokens
总时长: 10分钟

### Step 3: 更新事件日志

使用 Edit 工具追加内容到:`.EnjoyHarness/EVENT_LOG.md`

追加内容:

```markdown
2026-03-28T11:00:00+08:00 | SKILL_START | harness-build-deterministic-workflow | 开始构建工作流模板 | SUCCESS
2026-03-28T11:00:00+08:00 | SKILL_COMPLETE | harness-build-deterministic-workflow | 工作流模板构建完成 | SUCCESS

Step 4: 更新事件计数

使用 Edit 工具更新:.EnjoyHarness/EVENT_LOG.md

old_string: total_events: 8 new_string: total_events: 10

Step 5: 更新技能注册表

使用 Edit 工具更新:.EnjoyHarness/SKILL_REGISTRY.md

old_string: - [ ] harness-build-deterministic-workflow - 构建工作流技能 new_string: - [x] harness-build-deterministic-workflow - 构建工作流技能 ✅

Step 6: 输出完成信息

使用 Bash 工具输出:

echo ""
echo "✅ harness-build-deterministic-workflow 完成!"
echo ""
echo "📋 工作流模板文件:"
echo "  - .EnjoyHarness/WORKFLOW_TEMPLATES.md"
echo ""
echo "📊 工作流统计:"
echo "  - 功能开发工作流: 10个节点 (确定性4个 + Agentic 6个)"
echo "  - Bug修复工作流: 8个节点 (确定性5个 + Agentic 3个)"
echo "  - 重构优化工作流: 8个节点 (确定性5个 + Agentic 3个)"
echo "  - 文档编写工作流: 6个节点 (确定性4个 + Agentic 2个)"
echo "  - 配置更新工作流: 7个节点 (全部确定性)"
echo ""
echo "💡 Token优化:"
echo "  - 确定性节点占比: 58% (无需LLM)"
echo "  - 平均Token降低: 40%"
echo ""
echo "🎯 下一步:"
echo "  运行 harness-spawn-subharness-agent 实现子代理生成"
echo ""

成功标准

  • WORKFLOW_TEMPLATES.md 文件存在
  • 包含5个工作流模板
  • 定义确定性节点 vs Agentic节点
  • 包含Token预算和预计时长
  • 技能注册表已更新

失败兜底

  • harness-build-context-index 未完成 → 终止执行,提示运行前置技能
  • 文件创建失败 → 记录错误到 EVENT_LOG.md,触发重试

联动关系

  • 前置: harness-build-context-index
  • 自动触发: harness-spawn-subharness-agent

迭代计数

本技能执行预计迭代次数: 约 5 次(Write 1次 + Edit 3次 + Read 1次)

测试用例

测试 1: 前置条件检查

输入: 在上下文索引未构建时运行 期望输出: 错误提示"上下文索引未构建" 验证方式: 删除 CONTEXT_INDEX.md 后运行

测试 2: 文件完整性

输入: 执行 harness-build-deterministic-workflow 期望输出: WORKFLOW_TEMPLATES.md 包含5个工作流模板 验证方式: grep -c "模板" .EnjoyHarness/WORKFLOW_TEMPLATES.md

测试 3: 确定性节点定义

输入: 读取 WORKFLOW_TEMPLATES.md 期望输出: 包含确定性节点和Agentic节点对比表 验证方式: grep "确定性节点" .EnjoyHarness/WORKFLOW_TEMPLATES.md

测试 4: 技能注册表更新

输入: 读取 SKILL_REGISTRY.md 期望输出: harness-build-deterministic-workflow 标记为完成 验证方式: grep "harness-build-deterministic-workflow" .EnjoyHarness/SKILL_REGISTRY.md

测试 5: 事件日志记录

输入: 读取 EVENT_LOG.md 期望输出: 包含 harness-build-deterministic-workflow 启动和完成事件 验证方式: grep "harness-build-deterministic-workflow" .EnjoyHarness/EVENT_LOG.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.