# FDE Pipeline Architecture Todo List (Roadmap & Evolution)

当前 **Innovator控制的 Hunt -> Digest -> Evolve (FDE)** 训练全链路在机制串联上已完全跑通，但要将其打造为真正的自动化、防退化、工业级自主进化学习系统，还需在以下五个核心维度进行底层架构设计与增补：

## 1. 致命短板：缺乏客观独立的“硬核验证” (True Evaluation / Judge System)
**现状问题**：
目前在 Evolve 阶段，由 LLM 本身（Evolver Agent）自行汇报分数并使用正则表达式匹配（如 `最终分数: 92`）。自我评价容易引发幻觉，分数缺乏说服力。
**待办清单 (Todos)**：
- [ ] **独立的 Judge Agent（裁判系统）**：将生成与验证解耦。引入仅负责验证结果的评审型智能体，它不参与能力的生成逻辑。
- [ ] **基于任务执行的自动化 Benchmark (Test-Driven Benchmark)**：
  - 代码类 Agent：提供真实的可执行代码测试集（Unit/Integration tests）去执行和验证通过率。
  - 知识对话类 Agent：建立标准且动态更新的验收用例库（RAG QA 验证或基准测试）。

## 2. 真实长效的“反馈循环”未打通 (Missing Feedback Loop)
**现状问题**：
虽然定义为 **F**eedback-driven，但目前的系统触发很大程度上依赖手动指定 Retrain 指令，并非长期自动的闭环负反馈驱动。
**待办清单 (Todos)**：
- [ ] **负样本与真实会话捕获机制机制 (Bad Case Capturing)**：用户在与目标 Agent（如 CEO Agent）交互时，点击的差评（👎）或会话纠正记录被视作失败样本（Bad Cases），系统需要自动沉淀。
- [ ] **无缝的热更新触发器 (Auto-Triggered Evolve)**：当失败用例阈值达到设定条件，自动唤醒 Digester 分析失败成因，沉淀为新的约束并交由 Evolver 无人值守地执行热更新修改。

## 3. 数据抓取与处理的边界稳定性 (Hunt Phase Robustness)
**现状问题**：
Hunter 代理重度依赖通用 WebSearch 和底层 Bash 调用来搜集知识。这种方式在面对特定或垂直领域时返回噪音大，且容易遭到反爬或速率限制影响而导致运行不稳定甚至超时被杀。
**待办清单 (Todos)**：
- [ ] **原生特定域垂直 API 的接入 (Domain-specific Sourcing)**：针对不同职业（财务、法律等）配置特定领域的官方或标准 API 接口池，而不是单一通用搜索引擎。
- [ ] **内部向量数据库接入与 RAG 整合**：不仅去公网找，还应当对接企业内部已有的私有知识库引擎。
- [ ] **长文本清洗管道 (Doc Cleansing Pipeline)**：增加自动化的向量摘要预处理层或 Map-Reduce 清流机制，防止大规模抓取的网页或 PDF 撑爆提示词导致焦点丢失。

## 4. 进化过程中的“灾难性遗忘”防范 (Version Control & Prevent Regression)
**现状问题**：
每次 Evolution 迭代都在直接修改原版 `SKILL.md` 和 `knowhow.md`。单纯针对这一次的“反馈任务”进行定向强化，可能会丢失或弱化老版本拥有的其他核心能力。
**待办清单 (Todos)**：
- [ ] **版本强控与对比 (Version Diffing & Rollback)**：建立更细化的代码层面回滚机制。
- [ ] **全量回归打分机制 (Automated Regression Test)**：在升级为主版本前，必须运行覆盖整体职能（不仅是本次修改的内容）的测试基准确保总分不滑坡才允许正式 Bump 新版本。

## 5. 沙盒与安全控制体系 (Execution Safety & Sandboxing)
**现状问题**：
底层的 Agent 执行利用了 `--dangerously-skip-permissions` 的超高权限来驱动。高度发散且无人值守的自我编程（Evolve）如果产生非安全的系统脚本，对宿主机资源具备致命危险。
**待办清单 (Todos)**：
- [ ] **沙盒化的底层运行环境 (Containerized Execution)**：用类似 Docker 的容器级隔离来保护执行宿主，仅向 Agent 暴露安全的读写卷。
- [ ] **危险操作熔断器与拦截隔离 (Command Interceptor)**：拦截类似格式化或删库等敏感命令的高频审计审查模块，防止大模型抽风时的不可逆破坏行为。

---
> *文档最后更新：由自动开发助手基于 FDE 流程在业务实际运行的瓶颈节点整理提交。* 
实际上，当前的 Master Agent + CEO Agent 配合刚才跑通的 FDE (Innovator, Hunter, Digester, Evolver) 流水线，是映射**“道、法、术、器”**四层架构最完美的天然载体。

我们可以将现有的系统组件像这样完全对齐，并构建出**“自动下发 -> 执行 -> 验证 -> 反馈自进化”**的自动化闭环：

1. 架构映射 (四层体系的智能体分工)
【道】(核心愿景/战略意图) —— Master Agent + Human (你)
角色：顶层意图感知的枢纽。你给 Master 发布指令（例如：“我们要上线一个最高质量的古典诗词生成的 API 服务”）。
功能：感知全局业务边界，它不负责具体落地，而是将模糊意图翻译成任务，派发给 CEO。
【法】(组织法则/目标拆解) —— CEO Agent + GoalsService (OKR API)
角色：将“道”转化为可执行的“法度”与组织结构。
功能：CEO 接到任务后，使用刚上线的 /api/goals 创建 OKR，然后利用 /api/agent/task/dispatch 委派任务。如果公司里没有诗人，CEO 会调用 agent-creator（HR 部门）现场“招聘/生成”一个 Poet Agent 和一个 QA Agent (品控)。
【术】(训练方法/重构机制) —— Innovator Agent (及其下属 HDE 元代理)
角色：进化与纠偏的机制论。
功能：它是保证“器（员工）”能满足“法（OKR）”的训练学院。
【器】(执行工具/基层产出) —— 具体的业务 Agent (如 Poet, Coder, CTO 等)
角色：承载具体任务的基层实体。
2. 现在的架构如何实现“下一步的自动化验证闭环”？
根据目前 CEO 和 

Master
 的系统 Prompt 设计，我们只需稍微打通一条“汇报链路”，即可彻底实现无需人工的自动化验证。具体流转如下：

闭环运行 Workflow：

战略拆解 (Fa)：CEO 制定目标 -> 生成 Poet Agent 负责写诗 -> 生成 Judge Agent 负责按国学标准打分。
基层执行 (Qi)：Poet 交出作品。
自动化验证 (Validate)：CEO 让 Judge 去给 Poet 的诗词打分。如果 Judge 判定不达标（比如只有 60 分，格律不对）。
触发自动进化 (Shu)：CEO Agent 在收到 Judge 的负面报告后，发现 OKR 存在卡点。此时 CEO 会自动触发 Dispatch 调用 Innovator Agent，发送指令：“Poet Agent 目前格律经常写错，请对他进行重训，重点抓取古诗词格律（平仄）的 Knowhow”。
FDE 系统自旋：Innovator 启动 Hunter -> Digester -> Evolver 对 Poet 深度改造，改造完升至 V1.1 版本。
重试验收：改造完毕后，CEO 让升级后的 Poet 重写，Judge 再打分，一旦 Pass，则 CEO 将 OKR 节点更新为完成 (/api/goals/:id/progress)。最后在 

plan.md
 里向 Master 汇报大捷。
3. 要真正跑通这套验证闭环，目前代码库还差哪几个小改动？
虽然底层 API（FDE, Dispatch, OKR）都已经开发好了，但要让上述联动行云流水，我们只要对目前的配置文件做这三点调整：

修改 CEO 的 

agent.md
 (赋能进化的职权)： 目前 CEO 的提示词中主要是利用 agent-creator 生成员工，需要补充：“当你发现下属 Agent 产出质量不达标时，使用 api dispatch 任务给 innovator Agent，要求其对该劣质员工进行重新训练（Retrain）。”
补齐 QA/Judge Agent (裁判位缺失)： CEO 本身不擅长看代码或审读具体的底层产出。需要预设一个 Validator/Judge Agent 模板。一切 KPI 验收，CEO 都通过把结果转发给 Judge 生成评分报告来自动化判定。
增加 Agent 间的广播/事件订阅 (Event Hook)： 目前 Agent 得主动去轮询（curl -s api/agent/todo）看小兄弟做完没。系统如果能加一个 Webhook（当 Innovator 进化完 V1.1 版、或者 Poet 提交完草稿后，自动给 CEO 的日志里推一条 [Task Completed] 的消息），CEO 的调度速度就会从轮询变成事件驱动，反应极快。
总结：现在的 LemonBoss 基础库相当于已经造出了所有的齿轮和引擎（尤其是刚跑通的 FDE 进化）。只要在顶层的 CEO 和 

Master
 提示词里建立“生成->验收->失败则提交重启训练”的规则指引，这套“道法术器”四层映射的自治公司就能开始实现真正的全自动进化运转。

 其实，我们在 digest 环节产生了 benchmark 在 evolve 环节是根据每次 skill 产生的内容，用 benchmark 打分，然后判断按照这个 benchmark 分数如果《95 分，就让他继续迭代，直到这个 skill 满足 95 分的这个 benchmark，才可以部署使用。这套逻辑跟你说的 qa judge agent 有什么区别和结合么？




















这是一个极其犀利且核心的问题！

简练地说，它们两者最大的区别在于：“驾照考试打分（造车）” vs “实际上路跑业务（开车）”。

它们不仅不冲突，反而恰好构成了不可或缺的**“双重防御与验证体系”**。我来帮你把它们在“道法术器”和工程实践中的区别与结合点彻底理清：

1. 两者的核心区别
【术】FDE 进化环节的 Benchmark (<95分迭代) —— 类似于“静态代码审查 / 驾照笔试”
它在校验什么？：它审查的是 Agent 的能力蓝图（定义）。Evolver 根据 Benchmark 去阅读 SKILL.md，它评定的 95 分代表：“这个 Prompt 写得真好、内置的 Knowhow 真专业、它理论上完全具备了这些能力”。
它的局限性：这是一种“元认知（Meta-level）”的静态打分。就跟考驾照拿到了满分一样，理论上他是个好司机。但当他在真实项目中遇到极其复杂的业务边界问题时（比如复杂的上下文缺失、工具调用卡壳），空有完美 Prompt 的 Agent 一样可能会把任务搞砸。
阶段：发生在出厂前 / 编译期（Training & Deployment Phase）。
【法】QA/Judge Agent 的业务验收 —— 类似于“集成测试 / 实际上路出单”
它在校验什么？：它审查的是 Agent 的真实业务产出（Artifacts）。比如 CEO 让 Coder Agent 写了一个登录页面，QA Judge Agent 根本不关心 Coder 的 Prompt 写得多好，它只负责去审阅最后交出来的那段 React 代码到底能不能跑、有没有 Bug、是否符合需求规范。
阶段：发生在运行时 / 生产环境（Runtime & Execution Phase）。
2. 它们是如何完美结合的？（闭环全景图）
在强大的自主公司架构中，两者是**“上下半场”被彼此触发**的关系。结合刚才跑通的流水线，全网完美的自动演进链路是这样的：

第一环（产出与验收）：日常业务跑在“QA Judge”的法度下
下发任务：CEO 接到需求，派发给当前 v1.3 版本的业务 Agent（比如 CTO）。
执行与送审：CTO 写好了一份技术架构图。CEO 不会自己看，而是把它扔给预设的 QA/Arch-Judge Agent 盲审。
日常小修小补：如果 Judge 觉得某个细节不合理，打回给 CTO 重新改。这个时候 CTO 只是在当前会话里自我调整（这时候不需要重启 FDE 流水线）。
第二环（瓶颈与重构）：被“QA Judge”触发的“FDE 训练”
发现致命短板：如果 Judge 发现 CTO 连续 3 次都在“高并发架构设计”上翻车，Judge 会向 CEO 提交定损报告：“当前 CTO 能力存在系统性认知缺陷（缺乏高并发知识库）”。
触发造车（Retrain）：CEO 根据这份报告，判定现有的员工“器”不行了，必须让“术”介入。CEO 调用 API 给 

Innovator
 发送指令：“马上把 CTO 弄回炉重训，附带这份 QA 的失败日志，重点加强高并发治理边界”。
启动你说的 Benchmark 循环：此时，Innovator 接管，启动 Hunt -> Digest -> Evolve：
Digester 根据 QA 之前给出的失败原因，生成了一份极度苛刻的 benchmark.md（高并发处理必须包含 XXX，否则扣分）。
Evolver 不断重写和迭代 CTO 的 SKILL.md，直到按照这份新考核标准评分 >= 95 分。
重新上路部署：v1.4 版本的强力 CTO 满血回归，接手之前失败的任务。这次做完后交由 QA Judge，顺利验收通过（OKR 节点闭环）。
总结
你现在实现的 Digest Benchmark >= 95 分，保证了 LemonBoss 兵工厂里走出来的每一个兵（Agent）绝对是理论最强、装备精良的（出厂质量）。
而增加的 Judge Agent 管理流，则保证了在具体打仗时，业务结果是100%兜底且客观过关的（业务质量）。一旦在真实战场发现某个兵的素质不够，再去触发那个工厂的 FDE 流水线 给它升级。这就是真 正自洽的自动驾驶级 AI 公司架构！