宜博 / lemonboss

Browse Code »

Commit db172833d3537b0d4e560b23412f744fd5955d53

Authored by Yi Bo 2026-03-25 10:17:15 +0800

1 parent 39cbe290

docs: add architecture todo list and QA Judge PRD

Inline Side-by-side

Showing 2 changed files with 192 additions and 0 deletions

docs/architecture_todo_list.md 0 → 100644

View file @db17283

	1	+# FDE Pipeline Architecture Todo List (Roadmap & Evolution)
	2	+
	3	+当前 Innovator控制的 Hunt -> Digest -> Evolve (FDE) 训练全链路在机制串联上已完全跑通，但要将其打造为真正的自动化、防退化、工业级自主进化学习系统，还需在以下五个核心维度进行底层架构设计与增补：
	4	+
	5	+## 1. 致命短板：缺乏客观独立的“硬核验证” (True Evaluation / Judge System)
	6	+现状问题：
	7	+目前在 Evolve 阶段，由 LLM 本身（Evolver Agent）自行汇报分数并使用正则表达式匹配（如 `最终分数: 92`）。自我评价容易引发幻觉，分数缺乏说服力。
	8	+待办清单 (Todos)：
	9	+- [ ] 独立的 Judge Agent（裁判系统）：将生成与验证解耦。引入仅负责验证结果的评审型智能体，它不参与能力的生成逻辑。
	10	+- [ ] 基于任务执行的自动化 Benchmark (Test-Driven Benchmark)：
	11	+ - 代码类 Agent：提供真实的可执行代码测试集（Unit/Integration tests）去执行和验证通过率。
	12	+ - 知识对话类 Agent：建立标准且动态更新的验收用例库（RAG QA 验证或基准测试）。
	13	+
	14	+## 2. 真实长效的“反馈循环”未打通 (Missing Feedback Loop)
	15	+现状问题：
	16	+虽然定义为 Feedback-driven，但目前的系统触发很大程度上依赖手动指定 Retrain 指令，并非长期自动的闭环负反馈驱动。
	17	+待办清单 (Todos)：
	18	+- [ ] 负样本与真实会话捕获机制机制 (Bad Case Capturing)：用户在与目标 Agent（如 CEO Agent）交互时，点击的差评（👎）或会话纠正记录被视作失败样本（Bad Cases），系统需要自动沉淀。
	19	+- [ ] 无缝的热更新触发器 (Auto-Triggered Evolve)：当失败用例阈值达到设定条件，自动唤醒 Digester 分析失败成因，沉淀为新的约束并交由 Evolver 无人值守地执行热更新修改。
	20	+
	21	+## 3. 数据抓取与处理的边界稳定性 (Hunt Phase Robustness)
	22	+现状问题：
	23	+Hunter 代理重度依赖通用 WebSearch 和底层 Bash 调用来搜集知识。这种方式在面对特定或垂直领域时返回噪音大，且容易遭到反爬或速率限制影响而导致运行不稳定甚至超时被杀。
	24	+待办清单 (Todos)：
	25	+- [ ] 原生特定域垂直 API 的接入 (Domain-specific Sourcing)：针对不同职业（财务、法律等）配置特定领域的官方或标准 API 接口池，而不是单一通用搜索引擎。
	26	+- [ ] 内部向量数据库接入与 RAG 整合：不仅去公网找，还应当对接企业内部已有的私有知识库引擎。
	27	+- [ ] 长文本清洗管道 (Doc Cleansing Pipeline)：增加自动化的向量摘要预处理层或 Map-Reduce 清流机制，防止大规模抓取的网页或 PDF 撑爆提示词导致焦点丢失。
	28	+
	29	+## 4. 进化过程中的“灾难性遗忘”防范 (Version Control & Prevent Regression)
	30	+现状问题：
	31	+每次 Evolution 迭代都在直接修改原版 `SKILL.md` 和 `knowhow.md`。单纯针对这一次的“反馈任务”进行定向强化，可能会丢失或弱化老版本拥有的其他核心能力。
	32	+待办清单 (Todos)：
	33	+- [ ] 版本强控与对比 (Version Diffing & Rollback)：建立更细化的代码层面回滚机制。
	34	+- [ ] 全量回归打分机制 (Automated Regression Test)：在升级为主版本前，必须运行覆盖整体职能（不仅是本次修改的内容）的测试基准确保总分不滑坡才允许正式 Bump 新版本。
	35	+
	36	+## 5. 沙盒与安全控制体系 (Execution Safety & Sandboxing)
	37	+现状问题：
	38	+底层的 Agent 执行利用了 `--dangerously-skip-permissions` 的超高权限来驱动。高度发散且无人值守的自我编程（Evolve）如果产生非安全的系统脚本，对宿主机资源具备致命危险。
	39	+待办清单 (Todos)：
	40	+- [ ] 沙盒化的底层运行环境 (Containerized Execution)：用类似 Docker 的容器级隔离来保护执行宿主，仅向 Agent 暴露安全的读写卷。
	41	+- [ ] 危险操作熔断器与拦截隔离 (Command Interceptor)：拦截类似格式化或删库等敏感命令的高频审计审查模块，防止大模型抽风时的不可逆破坏行为。
	42	+
	43	+---
	44	+> 文档最后更新：由自动开发助手基于 FDE 流程在业务实际运行的瓶颈节点整理提交。
	45	+实际上，当前的 Master Agent + CEO Agent 配合刚才跑通的 FDE (Innovator, Hunter, Digester, Evolver) 流水线，是映射“道、法、术、器”四层架构最完美的天然载体。
	46	+
	47	+我们可以将现有的系统组件像这样完全对齐，并构建出“自动下发 -> 执行 -> 验证 -> 反馈自进化”的自动化闭环：
	48	+
	49	+1. 架构映射 (四层体系的智能体分工)
	50	+【道】(核心愿景/战略意图) —— Master Agent + Human (你)
	51	+角色：顶层意图感知的枢纽。你给 Master 发布指令（例如：“我们要上线一个最高质量的古典诗词生成的 API 服务”）。
	52	+功能：感知全局业务边界，它不负责具体落地，而是将模糊意图翻译成任务，派发给 CEO。
	53	+【法】(组织法则/目标拆解) —— CEO Agent + GoalsService (OKR API)
	54	+角色：将“道”转化为可执行的“法度”与组织结构。
	55	+功能：CEO 接到任务后，使用刚上线的 /api/goals 创建 OKR，然后利用 /api/agent/task/dispatch 委派任务。如果公司里没有诗人，CEO 会调用 agent-creator（HR 部门）现场“招聘/生成”一个 Poet Agent 和一个 QA Agent (品控)。
	56	+【术】(训练方法/重构机制) —— Innovator Agent (及其下属 HDE 元代理)
	57	+角色：进化与纠偏的机制论。
	58	+功能：它是保证“器（员工）”能满足“法（OKR）”的训练学院。
	59	+【器】(执行工具/基层产出) —— 具体的业务 Agent (如 Poet, Coder, CTO 等)
	60	+角色：承载具体任务的基层实体。
	61	+2. 现在的架构如何实现“下一步的自动化验证闭环”？
	62	+根据目前 CEO 和
	63	+
	64	+Master
	65	+ 的系统 Prompt 设计，我们只需稍微打通一条“汇报链路”，即可彻底实现无需人工的自动化验证。具体流转如下：
	66	+
	67	+闭环运行 Workflow：
	68	+
	69	+战略拆解 (Fa)：CEO 制定目标 -> 生成 Poet Agent 负责写诗 -> 生成 Judge Agent 负责按国学标准打分。
	70	+基层执行 (Qi)：Poet 交出作品。
	71	+自动化验证 (Validate)：CEO 让 Judge 去给 Poet 的诗词打分。如果 Judge 判定不达标（比如只有 60 分，格律不对）。
	72	+触发自动进化 (Shu)：CEO Agent 在收到 Judge 的负面报告后，发现 OKR 存在卡点。此时 CEO 会自动触发 Dispatch 调用 Innovator Agent，发送指令：“Poet Agent 目前格律经常写错，请对他进行重训，重点抓取古诗词格律（平仄）的 Knowhow”。
	73	+FDE 系统自旋：Innovator 启动 Hunter -> Digester -> Evolver 对 Poet 深度改造，改造完升至 V1.1 版本。
	74	+重试验收：改造完毕后，CEO 让升级后的 Poet 重写，Judge 再打分，一旦 Pass，则 CEO 将 OKR 节点更新为完成 (/api/goals/:id/progress)。最后在
	75	+
	76	+plan.md
	77	+ 里向 Master 汇报大捷。
	78	+3. 要真正跑通这套验证闭环，目前代码库还差哪几个小改动？
	79	+虽然底层 API（FDE, Dispatch, OKR）都已经开发好了，但要让上述联动行云流水，我们只要对目前的配置文件做这三点调整：
	80	+
	81	+修改 CEO 的
	82	+
	83	+agent.md
	84	+ (赋能进化的职权)：目前 CEO 的提示词中主要是利用 agent-creator 生成员工，需要补充：“当你发现下属 Agent 产出质量不达标时，使用 api dispatch 任务给 innovator Agent，要求其对该劣质员工进行重新训练（Retrain）。”
	85	+补齐 QA/Judge Agent (裁判位缺失)： CEO 本身不擅长看代码或审读具体的底层产出。需要预设一个 Validator/Judge Agent 模板。一切 KPI 验收，CEO 都通过把结果转发给 Judge 生成评分报告来自动化判定。
	86	+增加 Agent 间的广播/事件订阅 (Event Hook)：目前 Agent 得主动去轮询（curl -s api/agent/todo）看小兄弟做完没。系统如果能加一个 Webhook（当 Innovator 进化完 V1.1 版、或者 Poet 提交完草稿后，自动给 CEO 的日志里推一条 [Task Completed] 的消息），CEO 的调度速度就会从轮询变成事件驱动，反应极快。
	87	+总结：现在的 LemonBoss 基础库相当于已经造出了所有的齿轮和引擎（尤其是刚跑通的 FDE 进化）。只要在顶层的 CEO 和
	88	+
	89	+Master
	90	+ 提示词里建立“生成->验收->失败则提交重启训练”的规则指引，这套“道法术器”四层映射的自治公司就能开始实现真正的全自动进化运转。
	91	+
	92	+ 其实，我们在 digest 环节产生了 benchmark 在 evolve 环节是根据每次 skill 产生的内容，用 benchmark 打分，然后判断按照这个 benchmark 分数如果《95 分，就让他继续迭代，直到这个 skill 满足 95 分的这个 benchmark，才可以部署使用。这套逻辑跟你说的 qa judge agent 有什么区别和结合么？
	93	+
	94	+
	95	+
	96	+
	97	+
	98	+
	99	+
	100	+
	101	+
	102	+
	103	+
	104	+
	105	+
	106	+
	107	+
	108	+
	109	+
	110	+
	111	+
	112	+
	113	+这是一个极其犀利且核心的问题！
	114	+
	115	+简练地说，它们两者最大的区别在于：“驾照考试打分（造车）” vs “实际上路跑业务（开车）”。
	116	+
	117	+它们不仅不冲突，反而恰好构成了不可或缺的“双重防御与验证体系”。我来帮你把它们在“道法术器”和工程实践中的区别与结合点彻底理清：
	118	+
	119	+1. 两者的核心区别
	120	+【术】FDE 进化环节的 Benchmark (<95分迭代) —— 类似于“静态代码审查 / 驾照笔试”
	121	+它在校验什么？：它审查的是 Agent 的能力蓝图（定义）。Evolver 根据 Benchmark 去阅读 SKILL.md，它评定的 95 分代表：“这个 Prompt 写得真好、内置的 Knowhow 真专业、它理论上完全具备了这些能力”。
	122	+它的局限性：这是一种“元认知（Meta-level）”的静态打分。就跟考驾照拿到了满分一样，理论上他是个好司机。但当他在真实项目中遇到极其复杂的业务边界问题时（比如复杂的上下文缺失、工具调用卡壳），空有完美 Prompt 的 Agent 一样可能会把任务搞砸。
	123	+阶段：发生在出厂前 / 编译期（Training & Deployment Phase）。
	124	+【法】QA/Judge Agent 的业务验收 —— 类似于“集成测试 / 实际上路出单”
	125	+它在校验什么？：它审查的是 Agent 的真实业务产出（Artifacts）。比如 CEO 让 Coder Agent 写了一个登录页面，QA Judge Agent 根本不关心 Coder 的 Prompt 写得多好，它只负责去审阅最后交出来的那段 React 代码到底能不能跑、有没有 Bug、是否符合需求规范。
	126	+阶段：发生在运行时 / 生产环境（Runtime & Execution Phase）。
	127	+2. 它们是如何完美结合的？（闭环全景图）
	128	+在强大的自主公司架构中，两者是“上下半场”被彼此触发的关系。结合刚才跑通的流水线，全网完美的自动演进链路是这样的：
	129	+
	130	+第一环（产出与验收）：日常业务跑在“QA Judge”的法度下
	131	+下发任务：CEO 接到需求，派发给当前 v1.3 版本的业务 Agent（比如 CTO）。
	132	+执行与送审：CTO 写好了一份技术架构图。CEO 不会自己看，而是把它扔给预设的 QA/Arch-Judge Agent 盲审。
	133	+日常小修小补：如果 Judge 觉得某个细节不合理，打回给 CTO 重新改。这个时候 CTO 只是在当前会话里自我调整（这时候不需要重启 FDE 流水线）。
	134	+第二环（瓶颈与重构）：被“QA Judge”触发的“FDE 训练”
	135	+发现致命短板：如果 Judge 发现 CTO 连续 3 次都在“高并发架构设计”上翻车，Judge 会向 CEO 提交定损报告：“当前 CTO 能力存在系统性认知缺陷（缺乏高并发知识库）”。
	136	+触发造车（Retrain）：CEO 根据这份报告，判定现有的员工“器”不行了，必须让“术”介入。CEO 调用 API 给
	137	+
	138	+Innovator
	139	+ 发送指令：“马上把 CTO 弄回炉重训，附带这份 QA 的失败日志，重点加强高并发治理边界”。
	140	+启动你说的 Benchmark 循环：此时，Innovator 接管，启动 Hunt -> Digest -> Evolve：
	141	+Digester 根据 QA 之前给出的失败原因，生成了一份极度苛刻的 benchmark.md（高并发处理必须包含 XXX，否则扣分）。
	142	+Evolver 不断重写和迭代 CTO 的 SKILL.md，直到按照这份新考核标准评分 >= 95 分。
	143	+重新上路部署：v1.4 版本的强力 CTO 满血回归，接手之前失败的任务。这次做完后交由 QA Judge，顺利验收通过（OKR 节点闭环）。
	144	+总结
	145	+你现在实现的 Digest Benchmark >= 95 分，保证了 LemonBoss 兵工厂里走出来的每一个兵（Agent）绝对是理论最强、装备精良的（出厂质量）。
	146	+而增加的 Judge Agent 管理流，则保证了在具体打仗时，业务结果是100%兜底且客观过关的（业务质量）。一旦在真实战场发现某个兵的素质不够，再去触发那个工厂的 FDE 流水线给它升级。这就是真正自洽的自动驾驶级 AI 公司架构！
0	147	\ No newline at end of file
...	...

docs/qa_judge_req.md 0 → 100644

View file @db17283

	1	+# QA Judge Agent 需求文档 (PRD)
	2	+
	3	+## 1. 核心定位 (Identity)
	4	+- Agent ID: `qa-judge` (或 `biz-judge`)
	5	+- 角色定位: 业务架构中的“铁面判官”。它是真正的“业务验收员”，也是连接【执行器 (Qi)】与【重签发/重造系统 (FDE Shu)】的核心纽带。它绝对不自己动手写代码、画图或写文章，它唯一的职责是对照目标评审产出，并决定下一步是“返工”还是“重启训练”。
	6	+
	7	+## 2. 核心职责 (Core Responsibilities)
	8	+1. 多模态产出盲审: 接收来自各种执行 Agent（Coder、Poet、Writer 等）的产出（Artifact），并对照 CEO 最初的指令或产品的验收标准（Acceptance Criteria）进行评判。
	9	+2. 定损与打分: 给出 0-100 的评分，并明确给出 `Pass`、`Rework` (返工) 或 `Retrain` (回炉重造) 三种结论之一。
	10	+3. 缺陷溯源与升维:
	11	+ - 浅层错误 (Typo/疏忽): 给出具体错误位置让原 Agent 当前会话修改（Rework）。
	12	+ - 深层能力缺陷 (幻觉/根本不懂该领域): 提炼成一份“能力差距分析报告 (Capability Gap Report)”，直接上报给 CEO。
	13	+
	14	+## 3. 交互协议规范 (Input/Output Protocol)
	15	+
	16	+### 输入 (Input)
	17	+当 CEO 或其他流程调用 QA Judge 时，必须提供以下上下文：
	18	+- Original Task (原始任务): 比如“写一首严格符合平仄的七律”。
	19	+- Acceptance Criteria (验收标准): 比如“必须押注韵、对仗工整、无违禁词”。
	20	+- Artifact (待审产出): 执行 Agent 提交的具体文本/代码源文件路径 (`workspace/...`)。
	21	+
	22	+### 输出 (Output)
	23	+要求输出极其标准的结构化报告（带特定标识以便程序/CEO读取）：
	24	+
	25	+```json
	26	+{
	27	+ "judgment_id": "judge-xxx",
	28	+ "target_agent": "poet",
	29	+ "score": 65,
	30	+ "status": "RETRAIN_REQUIRED", // 可选: PASS \| REWORK \| RETRAIN_REQUIRED
	31	+ "feedback_to_agent": "第二句和第三句平仄完全不对仗，词汇堆砌。", // 直接给干活Agent的修改建议
	32	+ "escalation_report_to_ceo": {
	33	+ "systemic_issue": "当前 poet 缺乏基本的古诗词格律（平仄）检查框架体系。",
	34	+ "recommended_action": "建议调起 Innovator 对其开展 FDE 重训。新 Benchmark 必须包含：‘严格的平仄字库校验能力’。"
	35	+ }
	36	+}
	37	+```
	38	+
	39	+## 4. Execution Rules (绝对法则)
	40	+1. 只批评，不动手 (Never Fix): 绝对不要在回答中顺手把错误改了直接输出最终版方案。
	41	+2. 严守红线 (Strict Threshold): 任何涉及到框架性、安全性和核心业务逻辑的错误，一律打回，不能放水。
	42	+3. 精准溯源 (Root Cause Analysis): 判断是“粗心”还是“智弱”。如果是粗心，输出 `REWORK`；如果是当前 Agent 根本不具备这个知识储备，必须输出 `RETRAIN_REQUIRED`。
	43	+
	44	+## 5. 业务闭环协作指南 (给 CEO 的委派参考)
	45	+- CEO 收到 Judge 的 `Rework` 结论时：CEO 会把 Judge 的批注转给干活的 Agent，只在当前日志流中进行 Prompt 修正。
	46	+- CEO 收到 Judge 的 `RETRAIN_REQUIRED` 结论时：CEO 需要立即拦截该主线 OKR，调用 `<dispatch api>` 给 Innovator Agent，发送指令：“`poet` 质检严重不合格。请启动 FDE 流水线，并提取 QA 的报告（建议增加平仄字库校验）作为 Digester 的核心 Benchmark 提分项。”
...	...