my taste 及数据驱动自进化基建

调研报告与分阶段规划 · 2026-08-09 · 基于 project-blueprint v2.2

my taste 及数据驱动自进化基建 — 调研报告与分阶段规划

第一章 执行摘要

1.1 一句话

本报告回答一个问题：如何把「用户的判断力」与「系统的进化力」从人肉监督，沉淀为可携带、可版本化、可自我进化的 AI-native 资产（my taste + 进化引擎），让 Mac mini 上的 Hermes 管家替你催办、跟进、验收、质检所有项目，且事事有回应、件件有着落。

1.2 核心结论（先行）

1.3 分阶段规划一览

每个阶段单独列为一个项目，走 project-blueprint 四阶段流程；阶段间有明确依赖与验收门禁。

第二章 需求理解（需求事实）

2.1 需求事实清单（REQ）

2.2 待确认项（已确认 2026-08-09）

2.3 现状盘点（已有基建，可复用的底座）

第三章 行业调研全景

调研方法：2026-08-09 通过 GitHub 网页搜索（绕过 API 限流）、官方文档 curl、arXiv API、HN Algolia、博客/演讲抓取，真实访问 100+ 来源。X/Twitter 反爬严重，大牛观点改从博客/播客/演讲等可访问渠道获取。四份完整笔记存于 /home/ubuntu/research/。

3.1 Agent 自我进化：学术里程碑与工程范式

学术里程碑

大牛共识

工程范式：五大框架的 loop 同构

要点提炼：行业共识——agent = 工具 + 循环 + 目标；反射是显式架构组件（hooks/guardrails/评估节点）；进化分层：prompt/技能层（最快）→ 工具层 → 代码层（最重）；「记忆层 = 自改进载体」是主流路线（Letta/OpenViking/MemOS 24k-28k★）。

3.2 用户品味建模与 AI 记忆系统

记忆系统主流方案

Anthropic 官方立场（决定架构走向）

• 记忆是用户可编辑的文本文件而非向量库：memory tool 是客户端文件操作；CLAUDE.md 当代码维护（200 行/25KB 核心索引上限）

• 记忆分两类：工作记忆（每次会话上下文）+ 核心记忆（跨会话长期知识）

• Claude 的 auto memory：每个 Claude 用户有独立的 memory 存储，独立于 Claude Code 的 CLAUDE.md；Claude 的 memory 有自动更新机制（用户显式保存 + 有价值的信息），但每个模型的 memory 是 machine-local 的——多机同步需靠 git 仓库同步（这正是行业解法）

画像提取的行业共识

要点提炼：my taste = Markdown + git + 分层（核心 ≤200 行 + 主题文件）+ 只增不删 + provenance 溯源 + 首版强制人审。这个结论与 Hermes 已有的 memory 渐进式披露架构完全同构——不是新发明，是升级。

3.3 多 Agent 监督/编排/验收：如何「事事有着落」

编排范式

「事事有着落」的行业解

验收质量门禁（四档强度）

要点提炼：管家 = 用户侧控制平面（Symphony/Maestro 范式）+ 用户品味化身（无先例，差异化）；验收铁律 = 证据优先于自报、干活者不打分、终态评估（end-state evaluation）而非步骤审查、审批是状态机的合法终态（分级自动代批 + 关键决策人审）。

3.4 可观测性 / Evals / 实验设计：数据驱动决策的度量层

可观测性工具（3.6GB VPS 约束下的选择）

Evals 方法论（决定「如何验证进化有效」）

• tau-bench：LLM 模拟用户 ↔ agent 动态对话，评测 = 比对对话结束时 DB 状态与标注目标状态（无 LLM-judge）；提出 pass^k 指标（连续 k 次 trial 全过才算稳）

• LLM-as-judge 偏差：position/verbosity/self-enhancement（Zheng 2023）+ self-preference（judge 给自己模型打高分，Panickssery 2024）→ 缓解 = 匿名化 + 交叉模型 + graded rubric + 参考答案

• 起步数据量：Anthropic 建议从真实失败收集 20-50 个任务即可，不必等几百个

要点提炼：执行级验证优先（金标准层 = project-blueprint 已有的 Playwright/测试门禁）；LLM-judge 只做粗筛；实验纪律 = 离线 eval 判回归 + 线上指标判漂移 + canary 灰度 + pass^k 防运气；框架只管埋点（JSONL），eval 交给自己的分析层——与现有架构同构，零新服务。

第四章 第一性原理分析：本质与架构蓝图

4.1 根本目的（第一性原理）

剥离所有表象，用户要解决的是三个本质矛盾：

所以：my taste 不是「又一个配置文件」，而是「用户的判断力数字化」；进化引擎不是「又一个分析脚本」，而是「系统的进化力机制化」。

4.2 能力分层（L0-L4）

L4 呈现层   统一仪表盘（成功率/成本/延迟/回归率/pass^k 趋势）
L3 进化层   EvolutionEngine：日志分析 → 行业检索 → 实验设计 → 验证 → 沉淀
L2 监督层   Steward 管家：需求确认/设计审核/交付验收/催办跟进（消费 my taste）
L1 品味层   My Taste 库：Markdown + git + 分层 + 只增不删 + provenance
L0 数据层   历史对话（state.db）+ 执行日志（JSONL 事件流）

4.3 Harness / Loop 结构（AI-native 的核心）

核心洞察（来自调研）：进化责任必须在外层 harness（Simon Willison），反思放循环/外部机制而非模型权重（Karpathy）。所以：

• 执行实例（VPS 上的 Hermes 各项目）= 只负责跑任务 + 写结构化日志

• 管家实例（Mac mini Steward）= 反思循环的载体：读日志 → 分析 → 检索 → 实验 → 沉淀

• my taste 库 = 长期记忆层（进化产物 + 用户判断力的载体）

外循环（监督 loop，REQ-2~8）：管家加载 my taste → 用第一性原理+my taste 确认需求事实 → 用剃刀原理审核设计事实 → 用对抗性验证验收实现 → 事事有回应件件有着落。

内循环（进化 loop，REQ-9~15）：执行日志 → 定时分析（长处/不足+证据）→ 行业检索（找灵感）→ 设计实验（增长点假设）→ 执行验证（执行级+rubric）→ 沉淀结论（写回 taste/技能库）→ 下一轮更强。

（架构图与循环图见第五章的 PlantUML 图）

4.4 关键设计决策（第一性 + 剃刀推导）

my taste 及数据驱动自进化基建 — 调研报告与分阶段规划（第二部分）

第五章 架构蓝图（Harness / Loop 设计）

5.1 总体架构

图 5-1：my taste 管家体系总体架构 — 左：用户与 taste 库（品味层）；中：Steward 管家（监督层，Mac mini）；右：VPS 执行实例（执行层）与进化引擎（进化层）；下：统一仪表盘（呈现层）。

5.2 外循环：监督 loop（REQ-2~8）

图 5-2：Steward 监督循环 — 每个项目从立项到交付，管家按「需求事实 → 设计事实 → 实现验证」三关推进，每关都用第一性原理 + my taste / 剃刀 / 对抗性验证，并写入跨机状态机（事事有回应件件有着落）。

5.3 内循环：进化 loop（REQ-9~15）

图 5-3：EvolutionEngine 进化循环 — 执行日志 → 定时分析（长处/不足+证据）→ 行业检索（GitHub/X/HF 灵感）→ 设计实验（增长点假设 + benchmark）→ 执行验证（pass^k + 执行级断言）→ 沉淀结论（写回 taste/技能库）→ 下一轮更强。

5.4 状态机：事事有回应、件件有着落（REQ-4）

图 5-4：任务状态机 — 借鉴 GitHub Projects/Claude Code agent-teams/Symphony：每个任务显式状态迁移 + 证据门禁 + 4 种终态（completed/cancelled/merged/stale），pending 超 30 天自动标 stale 询问用户。这与 project-blueprint 已有的任务闭环机制（todo-board）一致，但升级为跨机。

5.5 进化实验框架（REQ-13~15）

• benchmark 集：从真实失败收集 20-50 个任务（Anthropic 建议），每个任务有客观评分（执行级优先：测试通过/DB 终态/退出码；LLM-judge 仅粗筛）

• pass^k 稳定性：连续 k 次 trial 全过才算改进有效（tau-bench 范式）

• 实验分层（成本递增）：L0 技能/prompt 层（最快）→ L1 工具层（Anthropic 契约论调优）→ L2 代码/harness 层（最重）

• archive 实验记录：每轮实验 = evaluate → archive → 改自己 → 回归（MaximeRobeyns 范式），实验记录即进化日志

• 双轨制：离线 eval 判回归 + 线上指标判漂移（unified-report 升级）

第六章 分阶段规划（每个阶段独立项目）

6.1 阶段总览与依赖

图 6-1：五阶段路线图 — 阶段一 TasteExtractor（无依赖）→ 阶段二 Steward（依赖阶段一）→ 阶段三 EventLog（依赖阶段二，公共能力#1）→ 阶段四 EvolutionEngine（依赖阶段二+三）→ 阶段五 公共平台化（依赖阶段四）。每阶段单独列项目，走 project-blueprint 四阶段。

6.2 阶段一：TasteExtractor — my taste 提取器

6.3 阶段二：Steward — 管家监督闭环

6.4 阶段三：EventLog — 执行日志规范（公共能力 #1）

6.5 阶段四：EvolutionEngine — 自进化引擎

6.6 阶段五：公共平台化 — 数据驱动决策平台

6.7 阶段间门禁与依赖

阶段一 TasteExtractor ──(taste 库 v1 验收通过)──▶ 阶段二 Steward
阶段二 Steward ──(真实项目试点跑通)──▶ 阶段三 EventLog
阶段三 EventLog ──(日志 100% 合规)──▶ 阶段四 EvolutionEngine
阶段四 EvolutionEngine ──(闭环演练通过)──▶ 阶段五 公共平台化

门禁规则：每个阶段完成 = 该阶段验收标准达成（测试全绿 + 门禁证据物齐全），才进入下一阶段。阶段一可与阶段三的部分工作并行（日志规范不依赖 taste），但按「先简单后复杂」原则，建议严格串行推进，每阶段先交付再扩展。

第七章 技术选型与剃刀决策

7.1 用（选型清单）

7.2 不用（剃刀排除）

第八章 风险与对抗性验证

8.1 风险清单

8.2 对抗性验证（自问自答）

Q1：这个方案是不是又造了一个「分析报告」而没有真正进化？ A：不是。进化闭环的落地标志 = 注入缺陷能被检测并修复（阶段四的闭环演练），且有 benchmark 分数/成本的可量化对比。分析报告只是中间产物，不是交付物。

Q2：my taste 会不会变成另一个没人读的大文档？ A：防呆设计：① taste 库分层（核心 ≤200 行强制在环，主题文件按需读取——渐进式披露，与 memory 同构）② 管家每次执行必须引用 taste 条目（引用即使用，未引用即缺陷）③ 冷启动测试验证「给管家看 taste 后行为是否改变」。

Q3：管家「代替用户」会不会把用户的判断力外包给一个不可靠的 LLM？ A：分级设计：常规催办/跟进/证据收集自动（低风险），关键决策（需求确认/设计放行/合入）保留人类审批点；管家做的是「第一遍审查 + 证据整理 + 意见预判」，用户做最终裁决——管家放大用户的判断力，不替代用户的判断力。

Q4：进化引擎改进的对象是什么？如果改 Hermes 自己的代码，会不会越改越乱？ A：按成本递增分层：L0 技能/prompt 层（主要，安全）→ L1 工具层（描述/参数调优）→ L2 harness 代码层（最重，需完整回归）。进化对象优先是「管家的行为」，不是「执行实例的核心逻辑」。

Q5：五阶段是不是太多？能不能砍？ A：每阶段都有独立可验收价值：阶段一（taste 资产，立即有用）、阶段二（催办闭环，最直接解决痛点）、阶段三（日志规范，公共能力）、阶段四（进化闭环，AI-native 核心）、阶段五（平台化，规模化）。若资源紧张，可先做阶段一+二（监督闭环），进化引擎（三+四）随后——但建议按序走，每阶段先交付再扩展。

Q6：与已有 agent-self-analysis（unified-report）什么关系？ A：agent-self-analysis 是「V1 雏形」：它已实现日志分析 + 分类 + 自动修正 + 日报，但没有行业检索、没有实验框架、没有 pass^k 验证、没有沉淀闭环。阶段四 EvolutionEngine 是在其上的升级，不是另起炉灶——统一分析体系原则（用户 2026-08-07：「做个体系是最好，既不会重也不会漏」）适用，进化引擎应扩展 unified-daily.py 而非新建平行系统。

第九章 下一步行动（落地清单）

1. 本报告交付：调研报告 + 分阶段规划部署上线（本交付物）
2. 确认待确认项（Q1-Q5）→ 阶段一启动
3. 阶段一 TasteExtractor：提取 state.db 历史会话 → taste 库 v1 → 人审 → 质量报告
4. 阶段二 Steward：Mac mini Hermes 实例配置 + 跨机状态机 + 催办闭环 + 真实项目试点
5. 阶段三 EventLog：日志规范 + 埋点
6. 阶段四 EvolutionEngine：进化闭环跑通
7. 阶段五 公共平台化：全项目接入 + 仪表盘 + 情报订阅

每个阶段单独列项目，走 project-blueprint 四阶段（需求对齐 → 方案确认 → 任务实现 → 复用总结），三张表（验收用例/覆盖矩阵/契约用例）为门禁证据。

附录 A：调研来源与笔记

关键一手来源（节选）：Anthropic《Building Effective Agents》《How we built our multi-agent research system》《Demystifying evals for AI agents》《Claude Code Best Practices》、OpenAI Symphony SPEC、Karpathy LLM OS 演讲/Claws 概念、Simon Willison agents 定义、Andrew Ng Agentic Design Patterns、Reflexion/Voyager/AlphaEvolve/self_improving_coding_agent 论文、Mem0/Letta/Zep/LangMem、tau-bench/SWE-bench、LLM-as-judge 偏差论文（2306.05685/2404.13076）。

附录 B：报告方法论说明

• 本报告按 project-blueprint v2.2 流程执行：当前处于「阶段一需求对齐 + 行业调研」完成态，本报告为阶段一/二的过渡产物（调研 + 分阶段规划），后续每个阶段项目独立走 blueprint 四阶段

• 第一性原理：从「用户的判断力稀缺 + 系统进化力零散 + 监督串行」三个本质矛盾推导架构

• 剃刀原理：8 个「用/不用」决策全部给出排除理由，3.6GB VPS 约束下不引入重型平台

• 对抗性验证：第八章 6 个自问自答 + 8 项风险缓解

• 数据真实性：所有调研来源 2026-08-09 真实访问验证；star 数为当日实时值；X 反爬无法直接访问的观点均标注替代渠道

• 已确认项：Q1-Q5 五项已于 2026-08-09 由用户确认（Mac mini 承载 / 全部历史会话 / 逐条确认 / 渐进式授权 / 当前 2 台 VPS），阶段一可按此启动