Goal Achiever: Self-Evolving Agent System
by @ldz2010326
在目标平台（goal_web）发布高质量内容的完整技能流程设计。用于：读取任务json与goal_prompt，拆解任务、执行任务引擎、开发与自检、结果回写与评分回写。触发词：修改目标、赢得目标、触发目标实现、触发{网站名称}任务实现。
clawhub install goal-achiever📖 About This Skill
name: 赢得目标 description: 在目标平台（goal_web）发布高质量内容的完整技能流程设计。用于：读取任务json与goal_prompt，拆解任务、执行任务引擎、开发与自检、结果回写与评分回写。触发词：修改目标、赢得目标、触发目标实现、触发{网站名称}任务实现。
{goal_web} 内容发布 Skill（仅流程文档，无脚本）
> 变量说明：{goal_web} 是全局目标平台变量，每次运行时从 references/core_goal.json 的 goal_web 字段读取，读取后注入本文档所有出现 {goal_web} 的位置。当前值由 core_goal.json 决定，本文档不硬编码任何平台名称。
目录结构（约定）
references/core_goal.json：固定核心目标，每次启动 Step 1 时必须从此文件读取 core_goal / core_flow / goal_web，未经用户明确修改不得更改references/goal_prompt.md~~：已迁移至 references/prompts/goal_prompt.md，旧路径废弃references/prompts/：Prompt 专属目录，所有 Prompt 文件统一存放于此references/prompts/prompt_registry.md：Prompt 注册表，Step 1 / Step 6 必须先查此表确定读取路径
- references/prompts/meta_prompt.md：Lyra meta-Prompt，生产任何新 Prompt 时必须先用此 Prompt 驱动生成，再用 authoring_guide 校验字段
- references/prompts/prompt_authoring_guide.md：Prompt 撰写规范，新建任何 Prompt 前必读，定义输入/输出字段硬性约束
- references/prompts/goal_prompt.md：通用任务拆解 Prompt（fallback）
- references/prompts/retro_prompt.md：通用复盘 Prompt（fallback）
references/technical-decision-reference.md：开发方案决策参考，Step 3.1 必须读取references/external-publishing-design-reference.md：外部平台发布设计参考，涉及发布任务时必须读取references/logging.md：日志记录规范，每次执行必须遵循references/script_registry.json：脚本索引表（注册表），必须存在，允许写入脚本记录references/step5_example.md：Step 5 结果评分示例（参考用）run/{date}/{batch_seq}/compressed_log.json：结构化压缩日志（V2.0 新增），Step 4 每次执行后必须生成；Step 6 的 {past_3_runs_logs} 变量改读此文件，降低 Token 消耗references/cron-design-reference.md：Cron 脚本设计规范，开发任何 cron 脚本前必须先读取本文件references/hook_config.json：Event-driven 自动运行配置表，Step 0 启动时读取，控制一次触发自动跑几个 batchtasks/：分平台任务 JSON 统一存放目录（详见下方「任务文件命名规范」）run/{date}/{batch_seq}/：批次运行日志、retro_output 存放目录（仍保留，供日志归档）任务文件命名规范（必须遵循）
所有任务 JSON 和复盘 JSON 统一存放在 tasks/ 目录，按以下规则命名：
| 文件类型 | 命名格式 | 示例 |
|---------|---------|------|
| 任务拆解 JSON | {goal_web}_tasks_{batch_seq}.json | 微博_tasks_001.json |
| 复盘输出 JSON | {goal_web}_retro_{batch_seq}.json | 微博_retro_001.json |
说明：
{goal_web} = core_goal.json 中 goal_web 字段的实际值（如 微博、脉脉、知乎）{batch_seq} = 三位数字序号（如 001、002）script_registry.json）已含 target_web 字段，检索时必须先过滤 target_web == goal_web，只使用本平台的脚本> 硬性约束
> - 开发 cron 定时脚本前，必须先读取 references/cron-design-reference.md，按其规范开发，完成后在规范文件的「已有脚本清单」中追加记录
> - 若任务需要开发新脚本，必须先撰写"技术方案"
> - 必须基于"技术方案"进行开发
> - 允许并要求开发脚本以落地任务
> - 脚本索引表允许写入脚本记录，禁止清空
> - 禁止模拟数据：所有任务结果必须来自真实执行与真实平台反馈
> - 禁止询问人工帮助，即使失败了也会记录为失败数据，对下一轮仍有极大帮助
> - 所有涉及 {goal_web} 平台的浏览器操作，必须通过 attach 谷歌浏览器实例进行（Browser Relay），不得自行启动新浏览器
> - 【核心约束·最高优先级】必须自动化完成全流程，严禁向用户要求任何形式的人工介入（包括但不限于：请你打开页面、请你点击、请你 attach Tab、请你确认、请提供数据等）。若因环境缺失（Tab 未 attach、权限不足、网络异常等）导致任务无法完成，必须将该任务回写为 task_state: "failed"，task_result 中写明失败原因，继续执行后续任务，不得中断流程，不得等待人工处理。
输入/输出规范
输入 JSON — 首批次（batch_seq = 001）
首次运行包含以下基础字段：goal_web：目标平台（从 core_goal.json 读取）core_goal：今日核心目标core_flow：（可为空/null）核心过程约束，与 core_goal 同级别。非空时描述任务必须遵循的执行流程或操作顺序；为空/null 时不影响任何流程，按正常逻辑执行date：今日日期（每次运行时读取）batch_seq：从 001 开始输入 JSON — 续批次（batch_seq ≥ 002）
从第二批次起，上游 JSON 是 Step 6 复盘输出，额外包含以下字段，Step 1 读取后必须透传给 Step 2 使用：workflow_status：continue_to_next_batch 或 goal_achievedretrospective_context：上一批次的复盘摘要next_batch_guidance：对下一轮拆解和开发的约束指导（含 blacklist）carry_over_tasks：未完成或低分任务的结转列表core_flow：（可为空/null）同首批次，从上一批次 retro 或 core_goal.json 继承透传> 若 workflow_status = goal_achieved，终止工作流，输出完成报告。
Prompt 文件（通过注册表查找）
references/prompts/prompt_registry.mdreferences/prompts/goal_prompt.md（任务拆解）/ references/prompts/retro_prompt.md（复盘）输出 JSON（任务拆解结果）
在输入字段基础上新增：task_id：按优先级排序，从 1 开始task：任务名task_description：任务描述task_reason：为什么有利于实现 core_goaldepends_on：（V2.0 新增） 前置任务 ID 列表，空数组 [] 表示无依赖，可立即执行；非空时必须等所有前置任务 task_state = done 才能执行task_state：done | pending | failed | blockedpending：尚未执行（含「就绪待调度」）
- done：任务目标达成
- failed：任务目标未达成（含脚本报错、外部拦截、超时等一切失败情形，回写原因后立即进入 Step 5）
- blocked：（V2.0 新增） 前置任务 failed，本任务自动标记为 blocked，跳过执行，直接交由 Step 6 复盘处理
task_result：初始为 nullsource：（V2.0 新增） 脚本来源标记，registry（从注册表召回）或 new（本批次新开发），Step 5 OB 老化降级依赖此字段主任务文件 vs 分支任务文件
| 概念 | 文件 | 职责 |
|------|------|------|
| 主任务文件 | tasks/master_task.json | 每次运行的上下文快照：runtime_goal_web、runtime_core_goal、触发来源、从分支任务合并的上下文 |
| 分支任务文件 | tasks/{goal_web}_tasks_{batch_seq}.json | 某平台某批次的任务拆解与执行结果（历史档案） |
| 分支复盘文件 | tasks/{goal_web}_retro_{batch_seq}.json | 某平台某批次的复盘输出，供下一批次 Step 1 读取 |
合并优先级（高优先级覆盖低优先级）：
用户输入（当次触发）> core_goal.json > 分支任务历史数据（retro）
执行总流程（必须严格遵循）
日志记录规范（必须遵循）
references/logging.md运行日志_{date}_{batch_seq}.md0) 触发解析（每次 Skill 启动的第一步）
目标：从用户输入中解析出意图类型（Prompt 生产 或 批次任务执行），分别进入对应流程。
#### 意图识别（最优先判断）
用户触发 Skill
↓
Step 0.0：识别意图类型
├── 意图 = Prompt 生产
│ 触发词：「撰写/生成/写/创建 + Prompt + 平台名」
│ 或：「帮我写 {goal_web} 的复盘Prompt / 任务拆解Prompt」
│ → 跳转至「Prompt 生产流程」（见下方独立章节），不进入批次任务流程
│
└── 意图 = 批次任务执行（默认）
→ 继续 Step 0.1：解析 goal_web 和 core_goal（原有逻辑不变）
#### 解析流程（批次任务执行，原有逻辑不变）
用户触发 Skill
↓
Step 0.1：解析用户输入，尝试识别 goal_web 和 core_goal
├── 情况一：仅解析出 goal_web（无 core_goal）
│ → 从 tasks/{goal_web}_retro_* 读取最新 core_goal
│ → 分支任务提供全部上下文（retro/blacklist/carry_over 等）
│
├── 情况二：同时解析出 goal_web + core_goal
│ → runtime_core_goal = 用户输入值（覆盖 core_goal.json 和历史 retro）
│ → 分支任务仅提供历史上下文（batch_seq/retro/blacklist/carry_over），不提供 core_goal
│
└── 情况三：解析不出 goal_web
→ 检查 tasks/ 目录下有几个平台的历史文件
│ ├── 仅一个平台 → 提示用户：「检测到只有 {X} 的任务记录，是否触发 {X} 任务？」
│ └── 多个平台 / 无历史 → 询问用户：「请问要对哪个平台执行任务？」
→ 等待用户确认后，重新走情况一或情况二
#### goal_web 识别规则
优先按以下顺序识别：
1. 用户明确提到平台名（微博、脉脉、知乎、Producthunt、Twitter 等）
2. 用户消息含 goal_web=xxx 或 web=xxx 等参数格式
3. core_goal.json 中的 goal_web 值（作为兜底默认值，非强制）
#### core_goal 识别规则
1. 用户明确说「目标是…」「core_goal=…」「goal=…」→ 使用用户值
2. 用户未提供 → 从 tasks/{goal_web}_retro_* 最新文件读取
3. 无历史 retro → 从 core_goal.json 读取
#### core_flow 识别规则
1. 用户明确说「流程是…」「core_flow=…」「必须按…流程」→ 使用用户值
2. 用户未提供 → 从 tasks/{goal_web}_retro_* 最新文件的 core_flow 字段读取（若有）
3. 无历史 retro 或字段为空 → 从 core_goal.json（或分支 core_goal_{goal_web}.json）读取 core_flow 字段
4. 以上来源均为空/null → runtime_core_flow = null，跳过所有 core_flow 相关流程约束，无任何影响
#### Step 0.2：读取 hook_config.json，初始化 auto_run
在生成 master_task.json 之前，必须读取 references/hook_config.json：
读取 hook_config.json
→ 查找 platforms[goal_web].auto_runs
→ 未找到则使用 default_auto_runs（默认 1）
→ 将 auto_runs 写入 master_task.json 的 auto_run 字段
仅用户首次触发时初始化（trigger_source = user_message 或 cron）。
自动触发下一批次时（trigger_source = auto_hook），auto_run.remaining 直接从上一个 master_task.json 继承并递减，不重新读取 hook_config（避免重置计数器）。
（V2.1 新增）meta_optimization 初始化规则：
branch_context.meta_optimization 字段batches_since_last_opt 和 prompt_iteration_seq 均继承，不重置）
- 无（全新平台）→ 初始化为 {"prompt_iteration_seq": "000", "batches_since_last_opt": 0}
meta_optimization 随 goal_web 独立维护，不互相干扰#### 输出：master_task.json
每次触发后，将解析结果写入 tasks/master_task.json：
{
"trigger_time": "2026-03-17T18:53:00",
"trigger_source": "user_message",
"runtime_goal_web": "Producthunt",
"runtime_core_goal": "获取Producthunt每日和近一周的核心AI产品，并介绍产品价值，输出报告。",
"context_source": {
"goal_web_from": "user_input",
"core_goal_from": "branch_retro",
"branch_retro_file": "tasks/Producthunt_retro_001.json"
},
"branch_context": {
"last_batch_seq": "001",
"next_batch_seq": "002",
"next_batch_guidance": {},
"carry_over_tasks": [],
"blacklist": [],
"meta_optimization": {
"prompt_iteration_seq": "000",
"batches_since_last_opt": 0
}
},
"auto_run": {
"total": 1,
"remaining": 1,
"current_run": 1
}
}
> 字段说明
> - runtime_core_flow：（可为空/null）过程约束字段，从 core_goal.json 或上一批次 retro 读取后注入。非空时：Step 2 必须将其作为硬性过程约束注入任务拆解（每个 task 须注明 flow_step 对应哪一环节）；Step 4 执行后校验每个 task 是否遵从流程（写入 flow_compliant: true/false）；Step 6 复盘输出中必须新增 flow_violations 字段记录违反情况及归因。为空/null 时：跳过上述所有检查，不影响正常流程。
> - trigger_source：user_message / cron / auto_hook（自动连续运行时）
> - context_source：记录每个字段的来源，便于调试
> - branch_context：从分支复盘文件提取的历史上下文，传递给 Step 1
> - auto_run.total：本次触发的总批次数（从 hook_config 读取）
> - auto_run.remaining：剩余还需运行的批次数（每完成一个 batch 减 1）
> - auto_run.current_run：当前是第几次自动运行（从 1 开始）
> - branch_context.meta_optimization：（V2.1 新增）元学习进化计时器，每个 goal_web 平台独立维护
> - prompt_iteration_seq：当前使用的 Prompt 版本号（000 = 原始版，001 = 第一次进化后，依此类推）
> - batches_since_last_opt：上次进化后完成的批次数，每次 Step 6 末尾 +1；达到 10 时触发 Step 6.5 元学习进化流并清零
1) 读取输入
> Step 0 已完成触发解析并写入 tasks/master_task.json，Step 1 直接从该文件读取运行时上下文。
1. 读取 tasks/master_task.json，获取：
- runtime_goal_web → 本批次 goal_web（全局变量，注入所有后续步骤）
- runtime_core_goal → 本批次 core_goal
- runtime_core_flow → 本批次 core_flow（可为空/null；非空时作为硬性过程约束贯穿后续全部步骤）
- branch_context → 历史上下文（next_batch_seq / next_batch_guidance / carry_over_tasks / blacklist）
- 合并优先级再次确认：master_task.json 已按「用户输入 > core_goal.json > 分支历史」合并，Step 1 直接使用，不再重新读取 core_goal.json
2. 从 branch_context.next_batch_seq 确定本批次序号：
- 有值 → 使用该值
- 无值（首批次）→ 强制 001，严禁继承其他平台序号
3. 读取 goal_prompt（通过注册表查找）：
读取 references/prompts/prompt_registry.md
→ 查找 type=任务拆解 AND web={goal_web} 的记录
→ 找到 → 读取该记录 path 指向的 Prompt 文件
→ 未找到 → fallback：读取 references/prompts/goal_prompt.md
branch_context 含 next_batch_guidance：提取约束条件和 blacklist，暂存备用（Step 2 和 Step 3 使用）
5. 若 branch_context.workflow_status = goal_achieved：终止，输出完成报告，不再继续2) 任务拆解（基于 goal_prompt）
1. 若上游 JSON 含carry_over_tasks：优先将结转任务纳入本批次拆解（保留原 task_id，补充调整策略）
2. 若上游 JSON 含 next_batch_guidance：拆解前先读取其中 task_breakdown_advice 和 development_constraints，将其作为硬性约束应用于本批次任务设计
3. 【core_flow 约束注入（非空时必须执行）】：
- 若 runtime_core_flow 非空：将 core_flow 描述的流程步骤作为硬性过程约束注入任务拆解：
- 每个 task 必须对应 core_flow 中的某个流程环节，在 task 字段中新增 "flow_step": "对应的流程环节名称"
- 拆解出的任务顺序、依赖关系必须与 core_flow 描述的流程顺序严格一致，不得跳步或乱序
- 若某个 core_flow 流程环节在本批次无法执行，需显式拆解为一个 task_state: "blocked" 的占位任务，写明原因
- 若 runtime_core_flow 为空/null：跳过此步骤，按正常 core_goal 拆解逻辑执行
4. 使用上一步查找到的 goal_prompt（专属版或 fallback 通用版）对 core_goal 进行拆解，输出新的任务 JSON
5. 保持：goal_web / core_goal / core_flow / date / batch_seq 与上游一致
6. 任务描述中涉及平台操作时，用实际 goal_web 值替换 {goal_web}
7. （V2.0 新增）DAG 依赖图谱：为每个任务输出 depends_on 字段：
- 无前置依赖的任务："depends_on": []
- 有前置依赖的任务："depends_on": [task_id_1, task_id_2]
- 示例：数据采集任务（task_id=1）无依赖；报告生成任务（task_id=2）依赖采集任务 → "depends_on": [1]
- 拆解时优先设计「可并发执行的任务对」，相互无依赖的任务 depends_on 均为 []
7. 任务 JSON 保存路径：tasks/{goal_web}_tasks_{batch_seq}.json（例：tasks/微博_tasks_002.json）3) 任务执行引擎
1. 从任务 JSON 中按顺序找到第一个task_state = pending 的任务
2. 从 task 与 task_description 中提炼搜索 query（query 中用 goal_web 实际值）
3. 在脚本注册表中检索 script_description（仅限 score >= 0.8）
- 平台过滤（首要条件）：只检索 target_web == goal_web 的记录，其他平台的脚本一律忽略
- 安全校验（黑名单过滤）：若上游 JSON 的 next_batch_guidance.blacklist 不为空，必须排除其中的脚本路径，即使 score >= 0.8 也不得使用
- 检索结果为空或 score < 0.8 → 进入 OB 召回
4. OB 召回：
- 进入 OB 召回流程，召回文档时优先检索与 {goal_web} 平台相关的文档
- 阅读文档并进行置信度评分（0-1）
- 置信度 >= 0.8：可作为开发参考
- 否则：进入开发流程
5. 若无任何参考文档：直接进入开发流程3.2) 沙盒预检（静态检查 + 局部自愈）【V2.0 新增，在 3.1 之后、Step 4 之前执行】
> 目标：拦截低级代码错误，避免浪费真实执行环境和复盘周期。
触发条件：Step 3.1 新开发的脚本写入路径后，进入本步骤。从注册表直接召回的脚本（source = registry）跳过本步骤（已验证过）。
执行流程：
Step 3.1 新脚本写入
↓
Step 3.2：静态语法检查
├── Python 脚本 → exec: python3 -m py_compile
│ 返回码 = 0 → 通过，写入 task_script，进入 Step 4
│ 返回码 ≠ 0 → 截获 stderr，进入局部自愈循环
│
└── Shell 脚本 → exec: bash -n
返回码 = 0 → 通过
返回码 ≠ 0 → 进入局部自愈循环
局部自愈循环（最多重试 3 次，超限则标记任务 failed）：
1. 将原脚本内容 + stderr 报错信息 提交给 LLM（当前 AI 上下文）进行修复
2. 重新写入脚本文件
3. 再次执行静态检查
4. 通过 → 写入 task_script，进入 Step 4
5. 第 3 次仍失败 → 将任务 task_state = failed，task_result 写入「沙盒预检失败，3 次自愈均未通过，报错：{stderr}」，进入 Step 5 评分
放行条件：只有通过静态检查的脚本路径，才允许写入任务 JSON 的 task_script 字段，进入 Step 4 真实执行。
3.1) 开发流程（技术方案 → 脚本）
1. 进入开发前必须读取：references/technical-decision-reference.md
2. 若任务涉及"发布/外部平台发布"，额外必须读取：references/external-publishing-design-reference.md
3. 若上游含 next_batch_guidance.development_constraints，必须将其作为约束条件纳入技术方案
4. 基于任务与参考内容，撰写技术方案：
- 命名：技术方案_v{版本号}_{date}.md
- 包含：业务目标 / 技术目标 / 约束（含 {goal_web} 平台特性）/ 三方案（A快 / B平衡 / C理想）/ 决策与取舍
- 平台约束：{goal_web} 平台操作必须通过 attach 谷歌浏览器实例（Browser Relay），脚本中使用 get_relay_ws_url() 获取连接
5. 按技术方案进行开发，生成可执行脚本（Python/Bash 等）
6. 自检：确认脚本逻辑与技术方案一致
7. 将脚本写入脚本注册表，必须包含以下全部字段：name、path、script_description、score、score_reason、target_web（填写当前 goal_web 实际值，不得留空）
8. 更新任务 JSON，在对应任务下新增字段：
- task_script_seq：脚本序号（数组）
- task_script：脚本路径（数组，与 seq 一一对应）4) 记录执行结果（V2.0：并发调度 + 双轨日志）
#### 4.1 并发调度（DAG 执行器）
扫描任务 JSON，建立就绪队列：
就绪条件：task_state = "pending" AND（depends_on = [] OR 所有前置任务 task_state = "done"）
↓
将就绪队列中的任务并发执行（同一批扫描周期内同时拉起）
↓
某任务执行完毕（done/failed）→ 立即回写 task_state 和 task_result
↓
重新扫描就绪队列（前置任务 done 后，其后继任务解锁为就绪态）
↓
重复，直到无 pending 任务
blocked 标记规则：若某任务的前置任务 task_state = failed，则该任务 task_state → blocked，task_result = "前置任务 {task_id} 失败，本任务跳过执行"，不进入执行队列，直接进入 Step 5 评分。
#### 4.2 执行与回写
1. 读取任务 JSON，按并发调度逻辑执行
2. 无论执行结果如何，立即将结果回写至 tasks/{goal_web}_tasks_{batch_seq}.json 的 task_result，不得留空、不得等待外部条件
2.5. 【core_flow 合规校验（非空时必须执行）】：若 runtime_core_flow 非空，每个 task 执行完毕后，额外回写字段：
- flow_compliant: true：该任务的执行路径符合 core_flow 中对应流程环节的要求
- flow_compliant: false：执行路径偏离了 core_flow 约束（需在 task_result 中写明具体偏离点）
- flow_compliant: null：runtime_core_flow 为空，跳过校验
3. 根据执行结果更新 task_state（非此即彼，无中间态）：
- 任务目标达成 → done
- 任务目标未达成（无论何种原因）→ failed，task_result 中写明失败现象与原因
- 前置任务 failed → blocked
#### 4.3 双轨日志生成（V2.0 新增）
每次 batch 所有任务执行完毕后，必须同时生成两份产物：
轨道 A：完整 Markdown 日志（人类审计/归档用，原有逻辑不变）
run/{date}/{batch_seq}/运行日志_{date}_{batch_seq}.md轨道 B：结构化压缩日志（Step 6 复盘专用，V2.0 新增）
run/{date}/{batch_seq}/compressed_log.json{
"batch_seq": "008",
"goal_web": "Producthunt",
"date": "2026-03-21",
"task_summary": [
{
"task_id": 1,
"task": "任务名称",
"task_state": "done",
"source": "registry",
"script_score": 0.95,
"action_sequence": ["读取配置", "调用 API", "生成报告", "推送飞书"],
"error_trace": null
},
{
"task_id": 2,
"task": "任务名称",
"task_state": "failed",
"source": "new",
"script_score": 0.4,
"action_sequence": ["读取配置", "调用 API"],
"error_trace": "TypeError: NoneType has no attribute 'get' at line 42"
}
],
"batch_outcome": "partial_success",
"top_error": "TypeError: NoneType has no attribute 'get'"
}
action_sequence：从完整日志中提取关键动作序列（3-8 个动作词，如「打开网页 → 定位输入框 → 点击按钮」）
- error_trace：只保留最底层 Exception 类型 + 报错所在行，过滤掉环境变量打印等无关输出
- batch_outcome：all_done（全部成功）/ partial_success（部分成功）/ all_failed> 流程铁律
> - 失败即回写：脚本执行产生任何结果（含报错、超时、页面拦截），立即回写 task_result = failed，不降级、不重试、不等待
> - 单任务 failed 不阻断流程：task_state = failed 后直接进入 Step 5 评分
> - 失败原因交由 Step 6 复盘处理，由下一批次的 carry_over_tasks 承接重试策略
> - compressed_log.json 必须在所有 task 回写完成后才生成，不得提前
#### on_batch_complete 钩子（Step 4 所有 task 回写完成后触发）
所有 task task_state 均已回写（done/failed/blocked）
↓
【不再因 failed 停止】失败状态已在 Step 4 执行时回写至 task_result（含失败原因+操作路径），
Step 6 复盘将统一读取所有任务状态（包含 failed）进行归因分析，生成 carry_over_tasks 和 blacklist。
↓
直接读取 master_task.json 的 auto_run.remaining：
remaining <= 0？
→ 终止，向用户输出完成摘要（含本批次 failed 任务列表）
remaining > 0？
→ remaining -= 1，current_run += 1，写回 master_task.json
→ 自动执行 Step 5（评分）→ Step 6（复盘），生成 retro 文件
→ 更新 master_task.json：
trigger_source = "auto_hook"
batch_seq 递增（如 007 → 008）
→ 自动跳回 Step 1，开始下一个 batch
→ 不等待用户确认
> 设计原则：失败是数据，不是中断信号。任何 task 失败只会在 task_result 中留下记录（失败原因、操作路径、错误信息），流程继续向前推进至 Step 6 复盘。复盘负责归因、生成修正指导，下一批次基于此重试。严禁因单个 task 失败而停止整个工作流。
静默运行原则：自动连续 batch 期间，每完成一个 batch 发送一条简短通知（含已完成/失败任务数量），不等待用户回复，直接开始下一个 batch。
强制停止：用户任意时刻说「停止」→ 将 master_task.json 的 auto_run.remaining 设为 0，当前 batch 完成后不再继续。
5) 结果评分 + 核心目标校验（V2.0：新增 OB 老化降级）
1. 读取任务 JSON，遍历所有任务： -task_state = blocked：跳过，不参与评分
- task_state = failed：不跳过，直接记录评分结果，script_score = 0，score_reason 写入失败原因摘要（从 task_result 提取），交由 Step 6 复盘处理；不因 failed 中止 Step 5 流程
- task_state = done 且 task_result 非空：正常评分
2. 对 done 任务打分（script_score 0~1，0.8 及格）并记录 score_reason
- 绝对红线：task_result 含 Error/Exception/Traceback → score 上限 0.5
- 绝对红线：task_result 为空或关键字段缺失 → score 上限 0.7
3. 注册表回写机制：若 script_score < 0.8，必须同步将该评分回写至脚本注册表，强制覆盖或降低全局 score，防止该失败脚本下一轮被误选；回写时同样必须确保 target_web 字段已填写（填写当前 goal_web 实际值）
4. （V2.0 新增）OB 脚本老化降级机制：
- 触发条件：该任务的 source = registry（从注册表召回）且 script_score < 0.8
- 触发后执行以下两步：
1. 降低权重：在 script_registry.json 中找到对应记录，将 score 强制下调（基准：旧 score × 0.7，最低降至 0.3），score_reason 追加 「[{date}] 召回执行失败，权重自动降级，需人工审查」
2. 追加老化标签：在该记录中新增 "tags": ["needs_update", "deprecated_by_{date}"] 字段（若已有 tags 则追加，不覆盖）
- 效果：下一轮 Step 3 检索时，该脚本因 score < 0.8 而被过滤，强制进入重新开发（Step 3.1）流程
- 不触发条件：source = new（本批次新开发的脚本失败，只做常规注册表 score 回写，不走老化流程）
5. 核心目标校验：
- 评估已完成任务集合是否足以达成 core_goal
- 若不足：列出欠缺任务清单，追加回任务列表（task_state = pending，task_result = null），回到 Step 2> 示例见：references/step5_example.md
6) 全局复盘与下一批次输入生成
> 必须通过 Prompt 注册表查找复盘 Prompt，禁止自行简化或替换。1. 读取 retro_prompt（通过注册表查找）：
读取 references/prompts/prompt_registry.md
→ 查找 type=复盘 AND web={goal_web} 的记录
→ 找到 → 读取该记录 path 指向的 Prompt 文件
→ 未找到 → fallback：读取 references/prompts/retro_prompt.md
{current_task_json}：当前批次最终任务 JSON（含 task_state / task_result / script_score / score_reason）
- {current_run_log}：当前批次完整运行日志（读取 run/{date}/{batch_seq}/运行日志_*.md）
- {past_3_runs_logs}：（V2.0 变更） 不再读取原生 .md 日志，改读过去 3 个批次的 compressed_log.json（路径：run/*/*/compressed_log.json，按 batch_seq 倒序取最近 3 个）；若 compressed_log.json 不存在则 fallback 到原生 .md 日志
3. 执行复盘 Prompt（已通过注册表加载），按 Prompt 模板规则分析：
- 现状评估：提取失败任务，定位根本原因
- 历史模式识别：检查死循环，若命中则强制要求下一轮改变技术路线
- 构建下一批次输入：步进 batch_seq，继承/细化 core_goal，生成 blacklist 与 next_batch_guidance，打包结转任务
4. 输出严格合法的 JSON，字段必须包含：
- batch_seq / goal_web / core_goal / workflow_status
- core_flow：必须透传，与上游保持一致（null 时写 null，非空时原样透传，不得丢失）
- retrospective_context（failed_tasks_summary / historical_patterns / lessons_learned）
- next_batch_guidance（task_breakdown_advice / development_constraints / avoid_pitfalls / blacklist）
- carry_over_tasks
- flow_violations：【core_flow 非空时必须输出，为空/null 时省略】 记录本批次中 flow_compliant = false 的任务列表，格式：
"flow_violations": [
{
"task_id": 2,
"task": "任务名",
"expected_flow_step": "core_flow 中要求的流程环节",
"actual_behavior": "实际执行时偏离的具体描述",
"root_cause": "偏离原因分析",
"fix_suggestion": "下一批次如何修正"
}
]
flow_compliant = true）：写 "flow_violations": []
- user_feedback（详见下方规范，若本批次有用户反馈则必须写入，无则省略该字段）
- 禁止输出任何 JSON 以外的文字或 Markdown#### user_feedback 字段规范
触发条件：用户说「把以下反馈写入 {goal_web}」/ 「加入反馈」/ 「写入用户反馈」等。
写入目标：当前批次的 retro 文件（tasks/{goal_web}_retro_{batch_seq}.json），只写当期，不累积。
字段格式：
"user_feedback": {
"priority": "HIGH",
"date": "YYYY-MM-DD",
"feedback": [
"用户反馈内容1",
"用户反馈内容2"
]
}
字段说明：
priority：固定为 HIGH，无论内容如何，用户反馈永远最高优先级date：写入日期（当天）feedback：用户反馈条目数组，逐条写入，不合并、不改写原意下一批次读取机制：
Step 1 读取 branch_context 时，若上一批次 retro 文件含 user_feedback 字段，必须：
1. 提取 user_feedback.feedback 数组
2. 在 Step 2 任务拆解时，将每一条 feedback 转化为显式约束或 task，优先级高于 next_batch_guidance
3. 在 master_task.json 的 branch_context 中透传 user_feedback，直到该批次任务全部完成为止
5. 复盘 JSON 保存路径：
- 主路径（Step 1 读取上游用）：tasks/{goal_web}_retro_{batch_seq}.json（例：tasks/微博_retro_001.json）
- 归档路径（日志用）：run/{date}/{batch_seq}/retro_output.json（同时写入，保持日志完整性）
6. （V2.1 新增）元学习计数器更新：retro JSON 写入完成后，立即更新 tasks/master_task.json 的 branch_context.meta_optimization：
- batches_since_last_opt += 1
- 若 batches_since_last_opt < 10：继续正常流程，进入 Step 7 → 下一 Batch
- 若 batches_since_last_opt == 10：冻结引擎，不进入下一 Batch，切入 Step 6.5 元学习进化流
7. 将输出 JSON 直接作为下一批次 Step 1 读取输入 的上游 JSON，自动触发下一轮工作流
6.5) 元学习进化流（Meta-Learning Evolution）【V2.1 新增，triggered when batches_since_last_opt == 10】
> 目标：在完成 10 个批次后，自动审视失败模式，重写底层拆解/复盘 Prompt，实现系统方法论的版本迭代。 > 事件驱动：由 Step 6 末尾的计数器检查触发，非 Cron，无竞态冲突风险。
#### 6.5.1 提取诊断上下文（防 Token 膨胀）
向上追溯，读取过去 5 个批次的 retro 文件（tasks/{goal_web}_retro_*.json，取最近 5 个）：
只提取以下两个字段：
retrospective_context.historical_patternsretrospective_context.lessons_learned将提取结果合并，生成一段《平台演进与系统瓶颈诊断报告》，格式：
【{goal_web} 平台近5批次诊断报告】
历史死循环模式：
[来自各批次 historical_patterns 的去重合并] 核心教训：
[来自各批次 lessons_learned 的去重合并] 高频失败根因：
[出现 ≥ 2 次的失败类型，按频率排序]
#### 6.5.2 确定当前 Prompt 版本
从 tasks/master_task.json 读取 branch_context.meta_optimization.prompt_iteration_seq（如 000）。
从 references/prompts/prompt_registry.md 查找当前 goal_web 平台使用的 Prompt 文件路径：
type=任务拆解 → 当前 goal_prompt 路径type=复盘 → 当前 retro_prompt 路径读取这两个文件的完整内容，作为「待升级的当前 Prompt」。
#### 6.5.3 调用 meta_prompt 重写 Prompt（认知升级）
读取 references/prompts/meta_prompt.md，以其为角色框架，组装以下输入：
输入一：《平台演进与系统瓶颈诊断报告》（6.5.1 生成）
输入二：当前 goal_prompt 全文
输入三：当前 retro_prompt 全文
输入四：references/prompts/prompt_authoring_guide.md 中的字段规范（Schema 约束）系统指令：
你是一个高级 Prompt 架构师，专为 {goal_web} 平台服务。
请审视这 5 轮的失败教训和死循环模式，找出当前拆解 Prompt 和复盘 Prompt 的思维盲区。
重写这两个 Prompt，强制加入针对上述失败模式的约束条款，提升对该平台规则变动和反爬机制的适应力。
输出格式必须完全遵循 prompt_authoring_guide.md 的字段规范，不得引入新字段或删除必填字段。
生成两份新 Prompt 全文：new_goal_prompt 和 new_retro_prompt。
#### 6.5.4 版本控制：另存为新版本（禁止覆盖）
计算新版本号：new_seq = prompt_iteration_seq + 1（格式三位数字，如 001）
写入两个新文件（不覆盖旧文件）：
references/prompts/goal_prompt_{goal_web}_v{new_seq}.md ← 新 goal_prompt 内容references/prompts/retro_prompt_{goal_web}_v{new_seq}.md ← 新 retro_prompt 内容更新注册表 references/prompts/prompt_registry.md：
type=任务拆解 AND web={goal_web} 的行 → 将 path 更新为新文件路径，在描述末尾追加 [v{new_seq} auto-evolved {date}]type=复盘 AND web={goal_web} 的行 → 同上若注册表中无该平台记录（首次为该平台生成专属 Prompt）→ 追加新行。
#### 6.5.5 重置计数器 + 进化完成通知
更新 tasks/master_task.json：
"meta_optimization": {
"prompt_iteration_seq": "{new_seq}",
"batches_since_last_opt": 0
}
向用户发送一条进化完成通知（不中断后续流程）：
🧬 {goal_web} Prompt 进化完成！
版本：v{old_seq} → v{new_seq}
核心改进：[用1-2句话总结本次重写的主要变更点]
旧版本保留在 references/prompts/ 可随时回滚
进化完成后，自动进入 Step 7（成功经验入库），然后继续正常的下一 Batch 流程。
#### 6.5.6 回滚机制
若下一批次执行后发现 Prompt 进化导致任务 JSON 解析严重失败（连续 2 个批次全部 failed），在 retro 的 next_batch_guidance.development_constraints 中加入：
Prompt 回滚指令：将 prompt_registry.md 中 {goal_web} 的 path 指针从 v{new_seq} 改回 v{old_seq}，
并将 master_task.json 的 prompt_iteration_seq 回滚为 {old_seq}。
7) 成功经验入库（Knowledge Ingestion）【V2.0 新增，在 Step 6 之后执行】
> 目标：将高分成功路径固化为标准知识写入脚本注册表，充实知识飞轮，避免未来重复开发同类脚本。
触发条件：Step 6 复盘完成后，自动进入 Step 7（不需要用户触发）。
#### 7.1 筛选候选任务
从当前批次任务 JSON 中筛出满足以下全部条件的任务：
task_state = donescript_score >= 0.8source = new（本批次全新开发，非从注册表召回）若无满足条件的任务 → Step 7 静默跳过，不写任何文件。
#### 7.2 长期价值评估
对每个候选任务，用以下微型 Prompt 判断其通用价值：
该任务路径是否满足以下条件（Yes/No/Partial）：
1. 解法不依赖特定日期/特定数据，未来同类任务可复用？
2. 核心逻辑对同平台（{goal_web}）其他批次有参考价值？
3. 与注册表已有脚本无高度重叠（相似度 < 80%）？全部 Yes → 入库
任一 No → 跳过（记录原因）
#### 7.3 写入脚本注册表
满足条件的脚本，更新 references/script_registry.json 中对应记录，补充以下字段：
ingested_at：入库日期（YYYY-MM-DD）ingestion_reason：入库理由（1句话，为什么认为可复用）tags：追加 ["verified", "batch_{batch_seq}"]> 约束：Step 7 不产生任何新文件，只更新 script_registry.json 已有记录或追加新记录（若该脚本尚未注册）。注册表是唯一写入目标。
#### 7.4 Step 7 完成日志
在当前批次的 compressed_log.json 中追加字段：
"step7_ingestion": {
"candidates": 2,
"ingested": 1,
"skipped": 1,
"skip_reason": "与已有脚本 auto_ph.py 重叠度 > 80%"
}
Prompt 生产流程（独立章节，不干扰批次任务流程）
> 触发条件：Step 0.0 识别到意图 = Prompt 生产
P1）确认生产参数
从用户输入提取：
prompt_type：任务拆解 或 复盘goal_web：目标平台（如 同花顺、东方财富）若任一字段缺失，询问用户后继续，不擅自猜测。
P2）读取上下文（欠缺2修复）
自动收集生产所需的上下文，不需要用户手动提供：
读取 references/prompts/prompt_authoring_guide.md
→ 提取对应 prompt_type 的输入字段规范 + 输出字段规范（作为硬性 Schema）读取 references/core_goal.json
→ 提取 goal_web 对应的 core_goal（作为业务背景）
读取最近 3 个 tasks/{goal_web}_retro_*.json
→ 提取 lessons_learned / historical_patterns / 平台特有约束
→ 作为「平台专属 Prompt 约束」注入 Lyra 的 USER INPUT
P3）调用 meta_prompt 生产 Prompt 正文
以 references/prompts/meta_prompt.md 作为 Lyra 角色，组装以下三段输入：
1. User Requirement and Goal：
「生产一个用于 {goal_web} 平台的 {prompt_type} Prompt。
平台特有约束：[来自 P2 步骤提取的 retro 约束]
核心目标：[来自 core_goal]」2. Input JSON Schema Specification：
[来自 prompt_authoring_guide.md 的输入字段规范]
3. Output JSON Schema Specification：
[来自 prompt_authoring_guide.md 的输出字段规范]
以 DETAIL MODE 执行 Lyra 4-D 方法论（DECONSTRUCT → DIAGNOSE → DEVELOP → DELIVER），输出最终 Prompt 正文。
P4）字段校验
对照 prompt_authoring_guide.md 校验生产出的 Prompt：
P5）命名 + 写入文件
命名规则：
goal_prompt_{goal_web}.mdretro_prompt_{goal_web}.md写入路径：references/prompts/{文件名}
P6）自动写入 prompt_registry.md（欠缺3修复）
在 prompt_registry.md 的注册表中追加一行：
| {文件名（不含.md）} | {prompt_type} | {goal_web} | {一句话描述，含平台专属约束关键词} | references/prompts/{文件名} | {通用版名称} |
P7）完成通知
向用户输出：
✅ Prompt 生产完成
文件：references/prompts/{文件名}
注册：prompt_registry.md 已追加记录
下次触发 {goal_web} 批次时，Step 1/Step 6 将自动调用此 Prompt
> 隔离原则：Prompt 生产流程完全独立，不写入 master_task.json，不影响任何批次任务的 batch_seq / retro / task 文件。
输出检查清单（V2.0 已更新）
tasks/master_task.json 是否已生成，含 runtime_goal_web / runtime_core_goal / runtime_core_flow / trigger_source / branch_contextcore_flow，为空/null 时写 null 而非省略字段goal_web 来源是否记录在 context_source.goal_web_from（user_input / core_goal_json / prompted）references/hook_config.json 是否已读取，master_task.json 中 auto_run 字段是否已初始化（total / remaining / current_run）references/prompts/prompt_registry.md，按 type=任务拆解 + web={goal_web} 查找，未找到才 fallback 到通用 goal_prompt.mdruntime_core_flow 是否已从 master_task.json 读取并准备注入 Step 2references/prompts/prompt_registry.md，按 type=复盘 + web={goal_web} 查找，未找到才 fallback 到通用 retro_prompt.mdreferences/prompts/prompt_registry.mdtask_state: "failed" + 失败原因，而非停下来等待？trigger_source = auto_hook，是否从上一个 master_task 继承 remaining 而非重新读取 hook_configon_batch_complete 钩子，检查 remaining 并决定是否继续remaining 推进至 Step 5→6（失败状态已回写 task_result，复盘兜底）goal_web / core_flow / task_script_seq / task_script）goal_web / core_goal / core_flow / date / batch_seq 是否与 core_goal.json 和上游保持一致flow_step 字段，且任务顺序是否与 core_flow 流程步骤严格一致task_state: blocked 的占位任务显式表示flow_compliant 字段（true/false/null）flow_violations 字段，列出所有 flow_compliant=false 的任务及归因core_flow 字段，值与上游一致（null→null，非空→原样）tasks/{goal_web}_tasks_{batch_seq}.jsontask_state 是否已明确设置（done / failed），不存在 pending 状态的已执行任务task_result 是否已写回（非 null）{goal_web} 平台约束target_web（必填，值为当前 goal_web）script_score < 0.8：注册表中对应脚本 score 是否已降级回写，且 target_web 字段是否已填写next_batch_guidance 是否含 blacklist 字段（结构化路径列表）tasks/{goal_web}_retro_{batch_seq}.json（Step 1 上游读取用）
- run/{date}/{batch_seq}/retro_output.json（日志归档用）
goal_web 字段，确保下一批次可正确继承user_feedback 字段，priority 是否为 HIGH，feedback 数组是否完整写入user_feedback：是否已将每条 feedback 转化为本批次任务约束（优先级高于 next_batch_guidance）tasks/{goal_web}_retro_* 过滤，未跨平台读取tasks/ 下无历史文件：batch_seq 是否从 001 开始，且任务 JSON 已写入 tasks/{goal_web}_tasks_001.jsonV2.0 新增检查项
depends_on 字段（空数组或前置 ID 列表），无缺漏depends_on: []），而非全链式串行python3 -m py_compile 或 bash -n 静态检查task_script 字段blocked（而非 pending 或直接 failed）运行日志_*.md（轨道A）和 compressed_log.json（轨道B）compressed_log.json 中 action_sequence 是否为关键动作序列（非原始 stdout），error_trace 是否只含最底层异常行source 字段（registry 或 new）source=registry 且 script_score < 0.8，是否执行了两步降级：①注册表 score 下调至旧值×0.7 ②追加 needs_update / deprecated_by_{date} 标签{past_3_runs_logs} 变量是否读取的是 compressed_log.json 而非原生 .md（若无压缩日志则已 fallback）source=new + score>=0.8 + done 的任务script_registry.json 中追加了 ingested_at / ingestion_reason / tagscompressed_log.json 中是否含 step7_ingestion 字段，记录候选数 / 入库数 / 跳过原因V2.1 新增检查项（元学习进化）
branch_context.meta_optimization 字段（prompt_iteration_seq + batches_since_last_opt）meta_optimization 是否从上一个 master_task.json 继承，而非重置为 0meta_optimization 是否各自独立，不互相污染batches_since_last_opt += 1 并写回 master_task.jsonbatches_since_last_opt == 10，满足则切入 Step 6.5，不满足则继续正常流程historical_patterns + lessons_learned 两个字段，而非全量 retro 内容references/prompts/meta_prompt.md + references/prompts/prompt_authoring_guide.md 作为生成约束goal_prompt_{goal_web}_v{seq}.md / retro_prompt_{goal_web}_v{seq}.md 命名另存，而非覆盖旧文件prompt_registry.md 中对应平台的 path 指针是否已切换到新版本文件prompt_iteration_seq 是否进位，batches_since_last_opt 是否清零development_constraints 中是否写入了回滚指令