11年技术路，从研发工程师到研发效率平台负责人，用技术改变世界，用博客记录成长 🌿
🎯 我的技术博客
为什么写博客？
工作 11 年，从研发工程师一路成长为研发效率平台负责人，技术积累非常深厚。
写博客的意义：
- ✅ 记录工作中的所学所感
- ✅ 提升对技术的理解（费曼学习法）
- ✅ 为技术演讲做准备
- ✅ 结识同行好友，互相交流
2025年7月14日...大约 3 分钟
💎 一句话总结
把"用 Agent 帮我学习"从一句话变成可执行的工业级流程：
5 Agent × 周分级 × 极简哲学 = 70 篇文章不是目的，掌握才是。
🎯 三大升级（一句对比）
| 维度 | 旧版（4 Agent） | 新版（5 Agent） |
|---|---|---|
| 协作 | 4 步循环 + 双适用 | 5 步：Week Review 加入 |
| 难度 | 全程一样 | 🌱 W1 → 🌿 W2-3 → 🌳 W4-6 |
| 文档 | V2/V3/V4 历史 + 9×3 思维表 | 极简：5 步 + 难度表 |
2026年7月1日...大约 6 分钟
🎯 背景：V2 的 3 个痛点
从 V1 一个脚本走天下，到 V2 引入 4 Agent 协作，我的学习系统一直在演进。
但 V2 有几个不得不承认的问题：
痛点 1：版本分歧
- V1 基础版、V2 主循环版、V3 9 思维版 — 3 个文件并存
- 用户每次都要问"我应该用哪个？"
痛点 2：代码冗余
- 4 个 Prompt 散落在 pipeline 文件里，每次调用都要 inline 写
- Agent 的角色定义、思维 prompt 拼接、prompt 长度计算 — 全是 boilerplate
痛点 3：state.json 越用越大
- 42 天学习之后，state.json 膨胀到 50KB+
- 每跑一天，内容（md）+ 状态（json）+ 思维日志（json）+ 错题分析（md）全塞在一个文件
- Git diff 越来越难看
转折点是 6-26 那一天 — DeepSeek v4-pro 介入了。它对我的整个系统做了一次"工业级"重构。我花了一周时间消化、理解每一个 commit、跑通端到端验证。
今天这篇文章，总结这次重构的核心价值。
💡 升级全景（10 大维度对比）
| 维度 | V2 | V3/V4 | 提升 |
|---|---|---|---|
| 脚本文件 | 1 个 | 3 个模块（Pipeline + Runtime + State） | 关注点分离 |
| 版本分歧 | 3 个并存 | 1 个统一版本 | 消除用户困惑 |
| Prompt 注入 | inline 拼装 | 自动从 agents/<name>.md 读取 |
消除 prompt 发散 |
| 状态管理 | 1 个膨胀的 state.json | 分层（state + progress + reviews） | 永远 < 2KB |
| 落盘自动化 | 手动处理输出 | 自动落盘到对应目录 | 零遗漏 |
| 答案输入 | input() 阻塞 |
三种 Provider 切换 | 支持无人值守 + 测试 |
| 思维激活 | 7 大（Content 用 3） | 9 大全激活 | 0 闲置 |
| 错误分析 | markdown 不可分析 | 结构化字段提取 | 可聚合统计 |
| 进度可视化 | 简单打印 | 思维统计 + 薄弱点检测 + 周报状态 | 盲点自动检测 |
| 框架接入 | Hermes 专有 delegate_task |
Runtime ABC，任意 Agent SDK 都能接入 | 可扩展 |
🚀 V3/V4 核心架构（4 大创新）
创新 1：Runtime 抽象层
之前所有的"跑 Agent"逻辑都直接写 rt.delegate_task(...)。这意味着整个系统只能跑在 Hermes 上。
V4 引入 AgentRuntime ABC + StubRuntime + HermesRuntime：
class AgentRuntime(ABC):
@abstractmethod
def delegate_task(self, goal, context, toolsets) -> dict: ...
@abstractmethod
def delegate_tasks(self, tasks) -> list[dict]: ...
class HermesRuntime(AgentRuntime):
"""真实实现 — 用 Hermes delegate_task"""
def delegate_task(self, goal, context, toolsets):
return delegate_task(goal=goal, context=context, toolsets=toolsets)
def delegate_tasks(self, tasks):
return delegate_task(tasks=tasks)
class StubRuntime(AgentRuntime):
"""测试实现 — 返回固定 mock 数据"""
def delegate_task(self, goal, context, toolsets):
return {"summary": f"[Mock] {goal}", "tokens": {"input": 0, "output": 0}}
def delegate_tasks(self, tasks):
return [self.delegate_task(**t) for t in tasks]这意味着什么？
- 我现在可以接入任何 Agent 框架（CodeBuddy、Claude Code、自研 Agent SDK）
- 通过环境变量切换：
LEARNING_OS_RUNTIME=hermes|stub - 测试时直接用 Stub，无须联网
创新 2：State 分层
V2 一个 state.json 包含：
- 当日所有 content（可能 50KB）
- 当日 exam
- 当日 error
- 当日 meta
- 历次 thinking log
- 历次 scores
- 历次 errors
V4 分成 4 层：
codebases/<name>/
├── state.json # 只存核心摘要（永远 < 2KB）
│ ├── schema_version
│ ├── day # 当前学到第几天
│ ├── colors # 5 大组件颜色地图
│ ├── scores # 考试分数历史
│ ├── errors # 错题薄弱点历史
│ ├── weekly_reports # 已完成周复盘
│ ├── plan # 6 周结构化计划（dict）
│ └── thinking_log # 每日使用的思维方法
│
├── progress/
│ ├── day-1.json # Day 1 完整每日结果
│ ├── day-2.json
│ └── week-N-review.json # 周复盘结构化摘要
│
├── content/
│ ├── day-1.md # Day 1 学习内容
│ ├── day-2.md
│ └── src-map.md / learning-plan-6weeks.md（Day 0 输出）
│
├── exams/
│ ├── exam-day-1.md # Day 1 考试题
│ └── exam-day-2.md
│
├── errors/
│ └── error-day-N.md # Day N 错题分析存档
│
└── reviews/
└── week-N-review.md # Week N 周复盘完整存档好处：
- state.json 永远是"小文件"，git diff 干净
- 每日结果可独立读、写、追责
- 错题和周复盘是 markdown，易 review
创新 3：Agent Prompt 自动注入
V2 里每次调用 Content Agent 都要这样写：
content_result = rt.delegate_task(
goal="输出 Day N 学习内容",
context=f"""
【你的角色】
1. 分析代码库
2. 抽象建模
3. 类比推理
...
【任务】
生成 markdown，包含...
"""
)结果：每次都要重复一段长长的 inline prompt，prompt 发散风险很高 — 我第 1 天写的和第 10 天写的不一样。
V4 引入 load_agent_prompt()，自动读 agents/content-agent.md 全文并注入：
content_prompt = load_agent_prompt("content") # 读 agents/content-agent.md
content_result = rt.delegate_task(
goal="输出 Day N 学习内容",
context=f"""
【你的角色 Prompt — 必须遵守】
{content_prompt} # 自动注入完整角色定义
代码库: {codebase_name}
今日目标: {today_goal}
Day {day-1} 结果: {previous}
...
"""
)好处：
- Prompt 集中在
agents/<name>.md，单一事实来源 - 版本管理清晰（git track Prompt 比 track inline 字符串容易得多）
- 实验时可改一个文件，验证效果
创新 4：next_day_focus 硬约束
这是 V4 解决的一个隐蔽但关键的问题 — 跑题。
V2/V3 里，Content Agent 在生成 Day 5 内容时，可能会"自然漂移"到 Day 10 的主题（比如它读完代码觉得某个概念重要就直接讲了）。结果就是：你的学习顺序被打乱。
V4 引入 Meta Agent 输出的 next_day_focus 作为硬约束：
previous = get_daily_result(codebase_name, day - 1) or {}
next_focus = previous.get("next_day_focus", "")
focus_constraint = ""
if next_focus:
focus_constraint = f"""
【⚠️ 强制聚焦 — 不可偏离】
上日 Meta Agent 明确指定今日聚焦: **{next_focus}**
你必须围绕这个主题生成今日内容，不可跳到其他周/模块。
"""机制：
- Day N 的 Meta Agent 在分析当日数据后，输出
next_day_focus（指定 Day N+1 应聚焦的主题） - 这个 focus 被持久化到
progress/day-N.json的next_day_focus字段 - Day N+1 的 Content Agent 在 context 里强制看到这个 focus
- Agent 偏离 focus 的概率降到 0
🧠 9 大思维全激活
V2 状态：7 大思维被使用，2 个闲置（deduction 推论假设从未用于 Content）。
V4 状态：9 大思维全部由某个 Agent 激活。
| 思维 | 负责 Agent | 强化方式 |
|---|---|---|
| 推论假设 (Deduction) | Content | 读代码前必须做 3 个假设 |
| 实验验证 (Empirical Testing) | Exam | 所有题目必须可在 REPL 跑通 |
| 类比推理 (Analogical) | Content | 每个组件找一个已知类比 |
| 归纳总结 (Induction) | Error + Meta | 找出错误规律 + 总结本周模式 |
| 第一性原理 (First Principles) | Content | 拆到不可拆 |
| 抽象建模 (Abstraction) | Content | 提取"组件 = 字段"模型 |
| 批判思维 (Critical) | Error | 找反例 + 边界 |
| 系统思维 (Systems) | Meta | 看整体关系 |
| 反事实推理 (Counterfactual) | Exam | 至少 1 道"如果不...会怎样"题 |
关键数据：在我的 show_progress 里，9 大思维使用统计可视化：
=== 9 大思维使用统计（共 2 天）===
abstraction ██░░░░░░░░ 2/2 (content,error)
analogical ██░░░░░░░░ 2/2 (content)
first-principles ██░░░░░░░░ 2/2 (content)
empirical-testing ██░░░░░░░░ 2/2 (exam)
counterfactual ██░░░░░░░░ 2/2 (exam)
critical-thinking ██░░░░░░░░ 2/2 (error)
induction ████░░░░░░ 4/2 (meta,error) ← Meta + Error 都用
systems-thinking ██░░░░░░░░ 2/2 (meta)
deduction ██░░░░░░░░ 2/2 (content) ← V4 新激活零闲置。
📊 Day 1 实战数据（验证学习系统是真的工作了）
V4 + Day 1 学 AgentScope Message 基座后，实际成绩：
{
"day": 1,
"content": "Day 1: Message 基座 — Msg 字段模型 + 6 种 Block + 3 工厂函数",
"exam_score": 88,
"exam_total": 100,
"evaluation": "A",
"level": "L3 (复现) + 接近 L4",
"color_change": "🔴 → 🟡",
"thinking_used": ["abstraction", "analogical", "first-principles", "counterfactual"],
"weak_points": [
"model_validator 完整逻辑",
"Pydantic discriminator 模式",
"6 种 Block 的具体字段",
"URLSource.type 永远 = 'url' 的设计哲学"
],
"completed_at": "2026-06-25",
"next_day_focus": "Block 子类（_block.py L11-100）"
}4 大关键指标：
- 考试分数 88/100（A 评价）— 不是"看过"，是"复现 + 反事实 + 抽象建模"都过
- 薄弱点被结构化提取 — 系统能"看见"自己哪里弱
- Color 变化 🔴 → 🟡 — 5 层掌握度可视化
- next_day_focus 自动指定 — Day 2 不会跑题
💎 设计哲学：少即是多，职责分离
V3/V4 重构最深的体会，是把"少即是多，职责分离"做到了极致：
之前（V2 状态）
- 1 个脚本，做 5 件事
- 1 个 state.json，存 7 类数据
- 多个版本共存
- Prompt 散落 inline
现在（V4 状态）
- 3 个模块（Runtime 抽象 + State 分层 + Pipeline 编排），每模块只做 1 件事
- state.json 只存摘要（永远 < 2KB），详细数据自动分散
- 1 个版本
- Prompt 集中到
agents/<name>.md
副产物：
- 代码可读性 ↑（每个文件 200-300 行，单一职责）
- 可测试性 ↑（Runtime 可 Stub，State 可 mock）
- 可扩展性 ↑（接 Claude Code？写个
ClaudeRuntime就好） - 可维护性 ↑（Prompt 改了跑哪儿都看到）
🔭 接下来的计划
V5（接下来的）：
- 更强的 Vibe Coding 集成 — 不是 4 Agent 编排，是"Vibe Coding + 4 Agent"
- Plant 项目完整闭环 — 用 4 Agent 学 PlantsGame，反向输出学习系统
- 跨代码库迁移 — Runtime 抽象后，从 AgentScope 迁移到 LangChain/AutoGen 应该很简单
- 公开 wiki — 把所有 Prompt/State/思维文件变成可读的 markdown wiki
📝 总结：这次重构给我的认知冲击
- Agent 协作 ≠ 多个 Agent 跑 — 是"4 Agent + 9 思维 + State 分层 + Runtime 抽象"的工业级架构
- 状态不是文件，是分层存储 — state.json 是缓存，详细数据分散才合理
- Prompt 是产品的一部分 — 不应该散落 inline，应该像代码一样被管理
- AI 工具链的"工程外壳"很重要 — V4 解决了"工程外壳"，才能真正开始跑学习闭环
- DeepSeek 这种级别的模型可以做架构师 — 我的体验：比自己写强 10 倍
一句话：从"几个 Agent 跑一跑"到"工业级多 Agent 系统"，只差一个 DeepSeek v4-pro 介入。
🤔 思考题（给读者）
- 你的学习系统有"版本分歧"问题吗？ 你怎么解决的？
- 你的 AI 工具配置是"散落 inline"还是"集中管理"？
- 你有没有想过把 state.json 分层？ 什么分什么？
- 如果接入一个新 Agent 框架（Claude Code、Cursor），你会怎么改？
- "9 大思维"是过度设计还是真的有价值？ 用 3 个思维能达到 80 分，用 9 个能到 95 分，你选哪个？
欢迎在评论区聊聊你的学习系统是怎么设计的。
2026年6月30日...大约 9 分钟
V1 → V2 关键升级：从"4 Agent 各自独立"到"4 Agent 协作循环"
核心改进：Content Agent 从"一次性生成 6 周计划"变成"每日学习教练"——根据前日结果动态调整当日内容。
为什么需要 V2？
V1 的 4 Agent 是"独立工具"，但...
V1 的问题：
❌ Content Agent 一次性输出 6 周计划（静态）
❌ Exam Agent 一次性出 5 道题（一次性）
❌ 没有状态管理（每天从头开始）
❌ 用户能力没有"昨日数据"反馈给"今日内容"2026年6月25日...大约 8 分钟
从"理论"到"代码"：4 个独立子 Agent 协作的完整方案
之前的文章《在 Hermes 上实现多 Agent 元认知学习系统》我写得太"理想化"——
把 4 个 Agent 当成 4 个完全独立的 AI 进程。
实际上，Hermes 的 4 Agent 实现有 3 种方式：
- 方案 A：4 个 Skill（同一 LLM 切 4 段 prompt）
- 方案 B：4 个 delegate_task 子 Agent（4 个隔离 context）⭐ 本文重点
- 方案 C：外部 Multi-Agent 框架（4 个独立 LLM）
2026年6月24日...大约 18 分钟
让 AI 帮你学习 = 从 L1 看过到 L5 精通的自动化路径
我做了 11 年技术，5 年 AI 转型，14 篇论文精读 + 95+ 博客。
今天这篇博客，是我把"元认知学习系统"从"概念"变成"可运行的 Hermes 多 Agent 系统"的完整方案。
我用 4 个 Agent（Content / Exam / Error / Meta）构建了一个完整的学习闭环：
2026年6月23日...大约 19 分钟
从"问过"到"会做" = 从 L1 到 L5 的进化
我做了十几年的技术工作，5 年管理，最近几年系统化 AI 转型（十几篇论文精读 + 几十篇博客 + 多个 AI 项目作品）。
这条路上我最大的感悟不是"AI 有多强"，而是**"我的学习本身需要元认知"**。
我曾经以为"我看过了 = 我会了"，结果：
- 看了 100 小时 AgentScope 源码，写不出 1 篇博客
- 学了 1 年时间管理，但效率还是 0.69
- 刷了 200 道题，转换方向时还是卡住
2026年6月23日...大约 12 分钟
背景
最近在学习 AgentScope 2.0 框架的源码，整个仓库 70+ 模块、几百个文件，一上来直接 cat 实现很容易迷失。
让 CodeBuddy 总结它"读源码的方法论"——结果它给出了一套四层索引 + 并行扫描的策略。我边读边整理成本文，重点是这套方法本身可复用到任何大型框架（LangChain、LlamaIndex、vLLM 等都适用）。
⚠️ 本文不是 AgentScope 源码解析，是学习大型 AI 框架的通用方法论。
...大约 8 分钟
写给每一个想做 AI 时代架构师的工程师
今天早上 9 点，我和我的 AI 助理小 bot 一起精读了 Meta-Harness: End-to-End Optimization of Model Harnesses（普林斯顿大学，2026-06-12）。
这篇文章不是讲"新模型"，也不是讲"新算法"——它是给"AI 时代的工程师"下了一个新定义：Harness 工程师。
读完这篇论文，我十几年的工程化经验重新被定义了。
今天这篇文章，是我 + 小 bot 一起的"学习复盘"，也是我"AI 转型"的关键里程碑。
2026年6月22日...大约 10 分钟
写给每一个想在 AI 时代不被淘汰的人
我做了十几年的技术工作，5 年团队管理，最近几年开始系统化 AI 转型。
从 0 到 1 精读十几篇 AI Agent 论文，从 0 到 1 输出几十篇博客，从 0 到 1 做出完整 AI 项目作品（几十小时）。
这条路上我最大的感悟不是"AI 有多强"，而是**"学习本身需要重建"**。
AI 时代的学习者，必须兼具"孩童的好奇心"与"科学家的方法论"，把技术工具转化为认知加速器。
2026年6月22日...大约 11 分钟