docs: 新增文章《从Workflow到ReAct：宠物医疗质控Agent的设计实录与踩坑反思》，分享AI Agent的架构设计与实践经验，同时删除多篇旧文章以优化内容结构

source/_posts/AI Agent 架构深度解析：原理、模式与生产落地.md

@@ -238,7 +238,7 @@ Andrej Karpathy 强调，目前行业处于"Agent的十年（Decade of Agents）
 **1. 吴恩达 (Andrew Ng) —— Agentic 核心概念与设计模式**
 * [AI Agents that Work - The Batch](https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/)
 * [Opportunities in AI (2024年演讲)](https://www.youtube.com/watch?v=q1XFm21I-VQ)
-
+* [agentic-ai](https://www.deeplearning.ai/courses/agentic-ai/)
 **2. Lilian Weng (OpenAI) —— LLM Agent 架构百科全书**
 * [LLM Powered Autonomous Agents](https://lilianweng.github.io/posts/2023-06-23-agent/)
 
@@ -249,3 +249,5 @@ Andrej Karpathy 强调，目前行业处于"Agent的十年（Decade of Agents）
 **4. BabyAGI —— 自主智能体先驱**
 * [Birth of BabyAGI](https://yoheinakajima.com/task-driven-autonomous-agent-utilizing-gpt-4-pinecone-and-langchain-for-ultimate-efficiency/)
 * [Better Ways to Build Self-Improving AI Agents](https://yoheinakajima.com/blog/)
+
+* [Elements of AI Agents](https://academy.dair.ai/dashboard/courses/elements-of-ai-agents/lessons/cmm9o0xx30000fg32dnuv7pa0)

source/_posts/RAG学习篇-Query-Transformation-查询改写-让烂问题也能找到好答案.md

@@ -0,0 +1,403 @@
+---
+title: RAG学习篇：Query Transformation 查询改写，让烂问题也能找到好答案
+date: 2026-04-24 15:30:00
+author: Gamehu
+tags:
+  - RAG
+  - Query Transformation
+  - 查询改写
+  - 检索优化
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">RAG</span>
+  <span class="sub-tag">Query Transformation</span>
+  <span class="sub-tag">查询优化</span>
+</div>
+
+<div class="article-quote">
+
+这是之前学习 RAG 时整理的学习篇。用户问的问题往往很烂——要么太泛（「Python 教程」），要么太绕（「那个什么什么...」），Query Transformation 就是解决这个问题的：<strong>把烂问题改写成好问题，检索效果直接翻倍</strong>。
+
+</div>
+
+## 一、为什么需要 Query Transformation
+
+### 1.1 用户的提问有多不靠谱
+
+做 RAG 的时候你会发现，**用户的问题质量参差不齐**：
+
+- <strong>太宽泛</strong>：「讲讲 Python」——讲什么？基础语法？进阶特性？Web 开发？数据分析？
+- <strong>太模糊</strong>：「那个东西怎么用」——哪个东西？怎么用？
+- <strong>有歧义</strong>：「Java 的继承」——是说 `extends` 继承父类？还是 `implements` 实现接口？还是组合优于继承（composition over inheritance）的重构方向？
+- <strong>有拼写错误</strong>：「Pythno 教程」——搜索引擎能纠错的还好，向量检索直接傻眼
+- <strong>太专业/太口语</strong>：「怎么让模型过拟合」——过拟合通常是负面词，但用户想问的是「怎么在特定领域微调」
+
+<div class="divider-wave"></div>
+
+**核心痛点**：用户的问题 ≠ 文档里的表达方式。
+
+用户问「Python 教程」，文档里可能写的是「Python 3.9 入门指南」。字面完全不同，但语义相关。这就是 Query Transformation 要解决的问题。
+
+### 1.2 Query Transformation 的本质
+
+用一句话概括：
+
+<div class="article-quote">
+<strong>把用户原始查询，改写成更容易在向量空间里找到相关内容的形式。</strong>
+</div>
+
+改写可以是：
+- 扩展（加同义词、相关概念）
+- 分解（把复杂问题拆成多个子问题）
+- 重构（换个问法，更接近文档的表达方式）
+- 生成（直接生成一个「理想答案」的草稿去搜——这就是 HyDE）
+
+## 二、常见的 Query Transformation 方法
+
+### 2.1 方法对比总览
+
+| 方法 | 原理 | 优点 | 缺点 | 适用场景 |
+|------|------|------|------|----------|
+| <strong>HyDE</strong> | 生成假设文档再编码 | 零样本、效果好 | 需要 LLM、有延迟 | 问答式、语义模糊 |
+| <strong>Query Expansion</strong> | 扩展同义词/相关词 | 简单、成本低 | 扩展质量不稳定 | 通用场景 |
+| <strong>Step-back Prompting</strong> | 退一步问更抽象的问题 | 能召回更相关的背景知识 | 可能召回过多无关内容 | 需要背景知识的复杂问题 |
+| <strong>子查询分解</strong> | 把复杂问题拆成多个子问题 | 适合复杂多跳问题 | 流程复杂、成本高 | 复杂推理问题 |
+| <strong>RAG-Fusion</strong> | 生成多个查询取并集 | 召回更全面 | 计算成本高 | 对召回率要求高的场景 |
+
+<div class="divider-tech"></div>
+
+### 2.2 HyDE（Hypothetical Document Embeddings）
+
+HyDE 是 Query Transformation 里最有意思的方法，本系列下一篇会专门深入讲，这里先把核心思路说清楚。
+
+**核心思想**：与其纠结怎么优化问题，不如直接生成一个「理想答案」，然后用这个答案去搜。
+
+<pre>
+用户问题 → LLM 生成假设文档 → 编码 → 检索真实文档
+</pre>
+
+**什么时候用**：
+- 用户问题很短（1-3 个词），语义太泛
+- 用户不知道怎么表达，需要「补全」语义
+- 你试过其他方法，效果都不够好
+
+### 2.3 Query Expansion（查询扩展）
+
+最传统、最轻量的方法。
+
+**原理**：给原始查询加同义词、相关词，扩大检索范围。
+
+**举个例子**：
+<pre>
+原始查询：Python 教程
+扩展后：Python 教程 入门 基础 学习 guide tutorial
+</pre>
+
+**实现方式**：
+1. <strong>基于词典</strong>：用 WordNet、同义词词典人工维护
+2. <strong>基于模型</strong>：用 LLM 生成相关词（轻量版）
+
+**Prompt 示例**：
+<pre>
+请为以下查询生成 3-5 个相关的搜索词，用逗号分隔：
+
+查询：{query}
+
+相关搜索词：
+</pre>
+
+**优点**：
+- 实现简单，几乎零成本
+- 不需要额外模型（如果用词典）或小模型（如果用 LLM 扩展）
+- 稳定性高
+
+**缺点**：
+- 扩展质量依赖词典或模型能力
+- 可能引入不相关的词（比如「Python」扩展到「蟒蛇」）
+
+<div class="article-quote">
+<strong>我的经验</strong>：Query Expansion 是性价比最高的第一步优化。先把这个做好，再考虑更复杂的方法。
+</div>
+
+### 2.4 Step-back Prompting（退一步提问）
+
+这个方法来自 Google DeepMind 的论文《[Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models](https://arxiv.org/abs/2310.06117)》（Zheng et al., 2023），思路很有意思。
+
+**核心思想**：当问题太具体时，退一步问更抽象、更通用的问题，先召回背景知识，再用背景知识辅助回答具体问题。
+
+**举个例子**：
+
+| 原始问题 | Step-back 问题 | 召回内容 |
+|----------|---------------|----------|
+| 「Transformer 的注意力机制在医疗文本上怎么优化」 | 「Transformer 注意力机制是什么」 | 基础原理 |
+| 「React useEffect 依赖数组问题」 | 「React useEffect 是什么」 | useEffect 文档 |
+
+**Prompt 示例**：
+<pre>
+你是一个问题改写助手。用户的问题是具体的，你需要生成一个更通用、更抽象的问题，用于检索背景知识。
+
+用户问题：{query}
+
+请生成一个更通用的背景问题：
+</pre>
+
+**什么时候用**：
+- 问题很具体，需要背景知识才能理解
+- 用户问的是某个领域的专业问题，但知识库里有更基础的解释
+
+**注意事项**：
+- Step-back 可能会召回太多无关内容
+- 建议配合 Reranker 使用，先召回更多，再精确排序
+
+### 2.5 子查询分解（Sub-query Decomposition）
+
+适合那种「一步问完但其实包含多个问题」的复杂查询。
+
+**举个例子**：
+<pre>
+原始问题：「怎么在 Kubernetes 上部署一个带数据库的 Web 应用，还要配置 SSL」
+
+子查询 1：Kubernetes 部署 Web 应用
+子查询 2：Kubernetes 部署数据库
+子查询 3：Kubernetes 配置 SSL 证书
+</pre>
+
+**实现方式**：
+1. 用 LLM 分析问题包含哪些子问题
+2. 对每个子问题分别检索
+3. 合并所有检索结果作为上下文
+
+**Prompt 示例**：
+<pre>
+请将以下复杂问题分解成 2-4 个更简单的子问题。每个子问题应该独立可回答。
+
+原始问题：{query}
+
+子问题：
+1.
+2.
+3.
+</pre>
+
+**优点**：
+- 每个子问题更精准，检索质量更高
+- 适合复杂的多跳推理问题
+
+**缺点**：
+- 需要多次检索，成本翻倍
+- 合并策略需要设计（简单拼接还是智能合并）
+
+<div class="article-quote">
+<strong>什么时候用</strong>：当用户问题明显包含多个子任务时（「怎么实现 A 同时还要 B 和 C」），分解后效果更好。
+</div>
+
+### 2.6 RAG-Fusion
+
+RAG-Fusion 由 Zackary Rackauckas 在 2024 年提出（[arXiv:2402.03367](https://arxiv.org/abs/2402.03367)），核心融合算法 RRF（Reciprocal Rank Fusion）则来自 Cormack 等人 2009 年的 SIGIR 论文。思路是：<strong>一个查询不够，我生成多个查询</strong>。
+
+**流程**：
+<pre>
+原始查询 → LLM 生成 5 个相关查询 → 分别检索 → 用 RRF 融合结果 → Top-K 返回
+</pre>
+
+**Prompt 示例**：
+<pre>
+请根据以下查询，生成 5 个不同角度但相关的查询。每个查询应该能检索到相关的补充信息。
+
+原始查询：{query}
+
+相关查询：
+1.
+2.
+3.
+4.
+5.
+</pre>
+
+**RRF 融合公式**：
+<pre>
+RRF 分数 = Σ 1 / (k + rank_i)
+</pre>
+
+简单说就是：一个文档在多个查询的结果里排名越高，最终分数越高。
+
+**优点**：
+- 召回更全面，不容易漏掉相关内容
+- 多个角度覆盖，减少 query 表述差异的影响
+
+**缺点**：
+- 需要多次检索，成本高
+- 需要调 RRF 的参数 k
+
+## 三、方法选择决策树
+
+这么多方法，怎么选？
+
+<div class="divider-gradient"></div>
+
+### 决策流程：
+
+<pre>
+用户问题质量如何？
+├── 问题清晰、具体 → 直接用原始查询
+│
+├── 问题太泛/太短 → Query Expansion 或 HyDE
+│   ├── 延迟敏感 → Query Expansion
+│   └── 追求效果 → HyDE
+│
+├── 问题太复杂/多条件 → 子查询分解
+│
+├── 需要背景知识 → Step-back Prompting
+│
+└── 召回率不够 → RAG-Fusion（多查询生成）
+</pre>
+
+### 我的建议：渐进式优化
+
+不要一上来就搞最复杂的方法。建议这个顺序：
+
+| 阶段 | 方法 | 预期收益 | 成本 |
+|------|------|---------|------|
+| <strong>第一阶段</strong> | 原始查询 + 好的 Embedding 模型 | 60% | 低 |
+| <strong>第二阶段</strong> | + Query Expansion | 70% | 很低 |
+| <strong>第三阶段</strong> | + Reranker（Cross-Encoder） | 80% | 中 |
+| <strong>第四阶段</strong> | + HyDE / Step-back / RAG-Fusion | 85-90% | 高 |
+
+<div class="article-quote">
+<strong>关键洞察</strong>：80% 的收益来自前三个阶段。HyDE 这类高级方法是为了最后那 10% 的提升，但成本和复杂度会显著增加。先跑基线，再决定是否需要。
+</div>
+
+## 四、生产落地的实战经验
+
+### 4.1 延迟优化
+
+Query Transformation 最大的问题是<strong>增加了延迟</strong>：
+
+- Query Expansion：几毫秒（如果用词典）到几百毫秒（如果用 LLM）
+- HyDE：几百毫秒到几秒（取决于 LLM）
+- RAG-Fusion：查询数 × 单次检索时间
+
+**优化策略**：
+
+1. <strong>分层缓存</strong>
+   - 高频查询的改写结果缓存
+   - 低频查询走原始查询
+
+2. <strong>并行执行</strong>
+   - RAG-Fusion 的多个查询并行检索
+   - 子查询分解的多个查询并行处理
+
+3. <strong>降级策略</strong>
+   - LLM 超时或失败时，回退到原始查询
+   - 设置改写质量的阈值，质量不够就回退
+
+4. <strong>小模型替代</strong>
+   - HyDE 的假设文档生成不需要大模型，用 GPT-3.5 级别的小模型替代 GPT-4，延迟可以降低 3-5 倍，效果损失在可接受范围内
+
+### 4.2 改写质量评估
+
+怎么知道改写有没有变好？
+
+<strong>离线评估</strong>：
+- 准备一批测试查询和期望的相关文档
+- 对比改写前后的 Recall@K、Precision@K、MRR
+
+<strong>在线评估</strong>：
+- A/B 测试：一部分用户走改写，一部分走原始
+- 观察下游指标：回答的点击率、满意度、任务完成率
+
+<div class="article-quote">
+<strong>避坑提醒</strong>：Query Transformation 可能导致「改写后召回的文档更相关，但 LLM 生成的答案反而更差」的情况。一定要评估端到端的效果，不要只看检索指标。
+</div>
+
+### 4.3 常见坑
+
+| 坑 | 表现 | 解决 |
+|----|------|------|
+| <strong>改写过度</strong> | 原始查询很清晰，改写后反而引入无关词 | 设置改写置信度阈值 |
+| <strong>改写跑偏</strong> | 改写后的查询偏离了用户真实意图 | 用原始查询兜底 |
+| <strong>多语言问题</strong> | 用户用中文问，改写成英文后检索不到中文文档 | 按语言分别处理或混合检索 |
+| <strong>领域适配</strong> | 通用改写策略在专业领域效果差 | 用领域特定词典或微调 |
+
+## 五、Prompt 工程技巧
+
+### 5.1 通用原则
+
+1. <strong>明确输出格式</strong>：告诉模型你要什么格式的输出
+2. <strong>加示例（few-shot）</strong>：给 1-2 个例子，模型学得更快
+3. <strong>约束条件</strong>：限制输出的长度、风格、范围
+
+### 5.2 示例：带 few-shot 的 Query Expansion Prompt
+
+<pre>
+你是一个查询扩展助手。请为用户的查询生成 3-5 个相关的搜索词，帮助检索更多相关内容。
+
+示例 1：
+查询：Python 教程
+扩展：Python 入门, Python 基础, Python 学习指南, Python 编程, Python 3.9
+
+示例 2：
+查询：Kubernetes 部署
+扩展：K8s 部署, Kubernetes 安装, Kubernetes 集群搭建, Docker 容器编排
+
+用户查询：{query}
+
+请生成扩展词（用逗号分隔）：
+</pre>
+
+### 5.3 示例：子查询分解 Prompt
+
+<pre>
+请将以下复杂问题分解成 2-4 个更简单的子问题。每个子问题应该独立可回答。
+
+示例：
+原始问题：「怎么在 AWS 上部署一个高可用的 Web 应用，还要配置负载均衡和自动扩缩容」
+子问题：
+1. AWS 上如何部署 Web 应用
+2. AWS 负载均衡器（ELB）如何配置
+3. AWS 自动扩缩容（Auto Scaling）如何设置
+4. AWS 高可用架构设计
+
+原始问题：{query}
+
+子问题：
+1.
+2.
+3.
+4.
+</pre>
+
+## 六、总结
+
+Query Transformation 是 RAG 检索优化的核心手段，但<strong>不是银弹</strong>。
+
+<div class="article-quote">
+<strong>核心观点</strong>：
+1. 先跑基线，知道当前问题在哪
+2. 从轻量方法（Query Expansion）开始，逐步迭代
+3. 高级方法（HyDE、RAG-Fusion）是为了最后 10% 的提升，成本和复杂度会显著增加
+4. 一定要评估端到端效果，不要只看检索指标
+5. 改写可能跑偏，一定要有降级策略
+</div>
+
+<div class="divider-stars"></div>
+
+最后送大家一句话：<strong>用户的烂问题不是你的错，但如果检索不到答案，那就是你的问题了</strong>。Query Transformation 就是来解决这个问题的。
+
+---
+
+## 参考资源
+
+**论文原文**：
+- **HyDE**：Gao, L., Ma, X., Lin, J., & Callan, J. (2022). [Precise Zero-Shot Dense Retrieval without Relevance Labels](https://arxiv.org/abs/2212.10496). arXiv:2212.10496.
+- **Step-back Prompting**：Zheng, H., Mishra, S., Chen, X., et al. (2023). [Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models](https://arxiv.org/abs/2310.06117). arXiv:2310.06117. Google DeepMind.
+- **RAG-Fusion**：Rackauckas, Z. (2024). [RAG-Fusion: a New Take on Retrieval-Augmented Generation](https://arxiv.org/abs/2402.03367). arXiv:2402.03367.
+- **RRF（基础算法）**：Cormack, G. V., Clarke, C. L. A., & Büttcher, S. (2009). [Reciprocal Rank Fusion outperforms Condorcet and Individual Rank Learning Methods](https://dl.acm.org/doi/10.1145/1571941.1572114). SIGIR 2009.
+
+**官方实现参考**：
+- LangChain：[Query Transformations 官方博客](https://www.langchain.com/blog/query-transformations)（含 MultiQueryRetriever 使用说明）
+- Haystack：[Advanced RAG: Query Expansion](https://haystack.deepset.ai/blog/query-expansion)（实现细节清晰，工程向）
+- RAG-Fusion GitHub 实现：[Raudaschl/rag-fusion](https://github.com/Raudaschl/rag-fusion)

source/_posts/ReAct框架深度解析：Beyond-Chatbots.md

@@ -1,323 +0,0 @@
----
-title: Beyond Chatbots：ReAct 框架如何让 LLM 进化成真正的 Agent
-author: Gamehu
-date: 2026-04-12 22:00:00
-tags:
-  - AI
-  - Agent
-  - ReAct
-  - LLM
-  - 架构设计
-categories:
-  - AI
----
-
-<div class="tag-container">
-  <span class="ai-tag">AI</span>
-  <span class="sub-tag">ReAct</span>
-  <span class="sub-tag">Agent</span>
-</div>
-
-## 前言
-
-> **⚠️ 时间线说明：** 这篇文章实际上是在《{% post_link Agent-production-landing-plan 'Agent 生产落地：从 demo 到产品的血泪经验' %}》之前完成的，一直躺在草稿箱里忘了发。阅读顺序上，建议先看这篇理解 ReAct 原理，再看那篇的生产实践经验。
-
-想象一下你现在要煮盆饺子。烧水、打料内心独白支配着每一个动作："水开了，我该下饺子了。"当发现缺少关键调料，内心独白会调整策略："没辣椒了？我用老干妈代替。"面对技术难点时，这个思维过程会触发外部行动："我不确定需要煮多久，我需要打开美食APP查下。"
-
-这种边想边做、边做边调整的能力，是人类解决问题的基本方式。但传统的大语言模型（LLM）完全没有这种能力——它们更像一个闭卷考试的学生，只能凭记忆一口气写到底，错了也没法改。
-
-在人工智能领域，传统的大语言模型（LLM）一直像静态黑盒一样运作。虽然这些模型擅长语言模仿，但它们缺乏功能性的"工作记忆"和与世界动态交互的能力。这种隔离滋生了两种系统性失败：<span class="highlight-text">"幻觉循环"</span>，即模型自信地编造事实；以及<span class="highlight-text">"错误传播"</span>，即单一的逻辑失误会毁掉整个回答。
-
-**ReAct（Reason + Act）框架代表了 AI 架构的范式转变。** 通过在孤立认知与外部执行之间搭建结构性桥梁，ReAct 将 LLM 从对话者转变为能够规划、执行和自我纠正的自主 Agent。
-
-这篇是我学习 ReAct 的笔记，想把它讲清楚，也给自己留个档。
-
----
-
-## 一、ReAct 到底在解决什么问题
-
-传统的 AI 能力其实是分裂的。要么你用 Chain-of-Thought（CoT）让模型在脑子里一步步推理，要么你用 Action-generation 让模型调用外部工具——但两者各自有坑：
-
-**纯推理（CoT）的问题：** 模型完全依赖内部参数知识，是个封闭系统。它没法查资料，没法更新自己的认知，结果就是自信满满地编事实（幻觉），而且一步错步步错（错误传播）。
-
-**纯行动（Act-only）的问题：** 模型可以调用工具，但缺乏显式的长期规划能力。它没法跟踪子目标，也没法系统地探索环境，很容易陷入重复或无意义的操作。
-
-**ReAct 的做法是：把两者缝合起来。** 推理痕迹帮助模型诱导、跟踪和更新行动计划，处理异常情况；而行动让模型能够对接外部信息源（Wikipedia API、浏览器、数据库）来获取实时信息。
-
-
-
-### 核心机制：反馈循环
-
-ReAct 把 Agent 的活动结构化成一个三段式交替序列：
-
-```
-Thought（思考）→ Action（行动）→ Observation（观察）→ Thought（再思考）...
-```
-
-{% asset_img Xnip2026-04-13_10-13-37.jpg ReAct 反馈循环示意图 %}
-
-1. **Thought：** LLM 用思维链把大任务拆成可管理的小任务，分析数据，决定下一步做什么
-2. **Action：** 模型输出使用某个预定义工具的意图（比如搜索数据库）。注意：LLM 自己不执行工具，只输出工具名和参数
-3. **Observation：** 外部系统执行工具，把结果反馈给 LLM
-
-Agent 基于这个观察重新评估进度，生成下一个 Thought。循环往复，直到输出最终答案。
-
-这个循环看起来直白，但效果非常显著。在 HotpotQA 基准测试里，传统 CoT 的幻觉率（编瞎话的概率）是 14%，上了 ReAct 之后直接降到 6%[^1]。
-
-<div class="article-quote">
-<strong>关键洞察：</strong>ReAct 不是让模型"更聪明"，而是给它一套"查资料→推理→再查资料"的机制，让它有机会认错和修正。
-</div>
-
----
-
-## 二、五个核心要点：为什么 ReAct 有效
-
-### 要点 1：推理与行动的协同
-
-ReAct 范式打破了传统上推理与执行的二分。其核心是形式化表达 **Â = A ∪ L**。在这个等式中，Agent 的行动空间从物理或程序步骤（A）扩展到包含内部的"语言空间"（L）。通过将"思考"视为模型轨迹中的另一种行动类型，ReAct 允许 Agent 生成口头推理痕迹——或称"想法"——与特定任务的动作交错进行。
-
-这种协同使模型能够诱导、跟踪和更新计划，同时实时处理异常。正如 Yao 等人在其奠基性研究中所言：
-
-<div class="article-quote">
-"这种'行动'与'推理'之间的紧密协同使人类能够快速学习新任务，并在前所未有的情况下进行稳健的决策或推理。"
-</div>
-
-通过交错这些痕迹，模型使用推理来决定检索什么信息，而由此产生的观察又为后续推理提供基础。
-
-### 要点 2：通过观察环节打破幻觉循环
-
-传统的思维链（Chain-of-Thought, CoT）提示鼓励模型"一步步思考"，但它完全依赖模型的内部参数知识——一个容易"幻觉"不存在事实的封闭系统。ReAct 通过引入强制的 **Observation（观察）** 步骤来解决这个问题，将模型锚定在外部现实中。
-
-在知识密集型任务中，ReAct 使用特定的动作词汇——包括 `search[entity]`、`lookup[string]` 和 `finish[answer]`——与 Wikipedia 等外部实体交互。这种迭代的 Thought-Action-Observation 循环迫使模型在继续之前根据真实知识库验证其逻辑。结果是统计学上显著的改进：在 HotpotQA 基准测试中，误报率（幻觉事实或逻辑的频率）从标准 CoT 的 **14%** 暴跌至 ReAct 框架下的 **6%**[^1]。这种锚定将 Agent 从创意作家转变为可信的调查者。
-
-### 要点 3：代理技能的效率悖论
-
-ReAct 扩展分析中最深刻的见解之一是：<span class="highlight-text">"代理技能"通常比原始模型大小更具参数效率。</span> 我们在"小模型悖论"中看到了突破：教模型如何推理和行动，比强迫它在权重中记忆海量事实更具泛化能力。
-
-数据揭示了一个惊人的层级关系：一个较小的 PaLM-8B 模型，仅在 3,000 条 ReAct 轨迹上微调，就能胜过完全依赖提示的巨大 PaLM-540B 模型。更令人印象深刻的是，微调的 62B 模型超过了 540B 提示版本的性能[^1]。这表明 AI 的未来不在于构建越来越大的记忆数据仓库，而在于提炼模型导航工具集和环境的程序能力。
-
-| 模型 | 方式 | 表现 |
-|------|------|------|
-| PaLM-540B | Zero-shot 提示 | 基准线 |
-| PaLM-8B | ReAct 微调（3,000 轨迹） | **超越 540B** |
-| PaLM-62B | ReAct 微调 | **大幅超越 540B** |
-
-*数据来源：Yao et al., *ReAct: Synergizing Reasoning and Acting in Language Models*[^1]*
-
-### 要点 4：可解释性：终于能看懂 AI 在想什么了
-
-传统模型的黑盒问题一直让人头疼。输入一个问题，输出一个答案，中间发生了什么？不知道。
-
-ReAct 的"草稿本（scratchpad）"机制解决了这个问题。每一轮循环的 Thought、Action、Observation 都被记录下来，形成一条完整的"思维链"。
-
-如果出错了，你能精确定位到是哪一步出的问题：
-
-- **推理错误**：模型陷入了重复循环，比如一直问同一个问题
-- **检索错误**：外部 API 返回了不相关的信息
-- **行动错误**：调用了错误的工具或参数
-
-更有意思的是，这种透明性支持**人在回路（Human-in-the-loop）**的干预。这有点像你带新人：他在那自言自语分析问题，你说"这一步想偏了"，他马上就能纠正。
-
-ReAct 通过其人类可读的"草稿本"，为 AI 的"黑盒"提供了一个罕见的窗口。Agent 过程的每一步都被记录为想法、行动和观察的序列，提供了以前不可能的诊断水平。
-
-如果 Agent 失败，开发者可以精确定位确切的失败模式——比如模型陷入重复循环的"推理错误"，或外部 API 返回无信息结果的"搜索错误"。这种透明性还促进了<span class="highlight-text">"人在回路（Human-in-the-loop）"</span>的纠正。在 ALFWorld 环境（一个基于文本的任务模拟器）中，研究人员证明，人类可以通过简单编辑草稿本上的"想法"来引导失败的 Agent 回到正轨——删除幻觉或添加提示——使 AI 能够立即重新校准其计划[^1]。
-
-**示例：ReAct 轨迹**
-
-```
-Thought: 用户询问 2024 年诺贝尔物理学奖得主，我需要确认最新获奖信息。
-Action: search[2024 Nobel Prize in Physics winner]
-Observation: John J. Hopfield and Geoffrey Hinton were awarded...
-Thought: 好的，我已获得准确信息，现在可以回答用户了。
-Action: finish[约翰·霍普菲尔德和杰弗里·辛顿]
-```
-
-### 要点 5：复杂环境的动态规划
-
-虽然标准 LLM 在多步骤任务上挣扎，但 ReAct 在 ALFWorld（合成家庭任务）和 WebShop（拥有 118 万产品的在线购物环境）等交互式环境中表现出色。与遵循 rigid 脚本的"仅行动（Act-only）"Agent 不同，ReAct Agent 利用动态推理将高级目标分解为可管理的子目标。
-
-所以ReAct 的真正威力，在处理多步骤、需要探索的任务时才会显现出来。
-
-ALFWorld 里有个典型任务：”把一个发烫的平底锅放到冷却架上”。这看起来简单，但模型需要：
-
- - 找到平底锅（可能在灶台上）
- - 判断它是不是”发烫”的状态
- - 找到冷却架（可能在橱柜里）
- - 规划一条合理的移动路径
-  
-传统”只行动不思考”的 Agent（Act-only）在这种任务上成功率只有 45%，而 ReAct 能达到 71%[^1]。
-
-ReAct 利用预训练的"常识知识"——例如，知道胡椒罐更可能在橱柜里而不是冰箱里——以手术般的效率探索环境。通过维护其进度的内部记录，ReAct Agent 避免了困扰纯反应式系统的无产出循环。
-
----
-
-## 三、如何构建一个 ReAct Agent
-
-你可以用 LangChain、LangGraph 或 BeeAI 等开源框架快速搭建（比如 LangChain 的 `ZERO_SHOT_REACT_DESCRIPTION`），也可以从零用纯 Python 手写。下面是手写版本的逻辑拆解：
-
-### 步骤 1：定义工具集
-
-首先确定模型能用的具体行动。写 Python 函数（计算器、搜索等），然后把它们的签名和描述提取成 LLM 能理解的格式（JSON 或字符串）。
-
-```python
-# 示例工具定义
-tools = {
-    "search": {
-        "description": "搜索 Wikipedia 获取实体信息",
-        "parameters": {"entity": "要搜索的关键词"}
-    },
-    "calculator": {
-        "description": "执行数学计算",
-        "parameters": {"expression": "数学表达式"}
-    }
-}
-```
-
-### 步骤 2：编写 ReAct 提示词
-
-ReAct Agent 极度依赖特定的提示技巧来结构化输出。系统提示必须：
-
-- 引导模型一步步思考，交错想法和行动
-- 提供可用工具列表
-- 定义严格的输出格式，通常用标签如 `Thought:`、`Action:`、`Action Input:`、`Observation:`
-
-**提示词模板示例：**
-
-```
-你是一个能够使用工具的 AI 助手。按以下格式解决问题：
-
-Thought: 分析当前情况，决定下一步行动
-Action: 要使用的工具名称（从 [{tool_names}] 中选择）
-Action Input: 传递给工具的参数
-Observation: 工具执行结果
-...（重复 Thought/Action/Observation 直到得出结论）
-Thought: 我现在知道最终答案了
-Final Answer: 用户的最终答案
-
-可用工具：
-{tools}
-
-开始：
-Question: {input}
-```
-
-### 步骤 3：构建执行循环
-
-把提示词和用户问题传给 LLM 后，你需要一个程序循环来处理执行：
-
-1. **解析输出：** 拦截 LLM 的文本输出，提取 `Action`（工具名）和 `Action Input`（参数）
-2. **执行工具：** 你的 Python 代码调用对应的函数
-3. **返回观察：** 把函数结果格式化为 `Observation`，追加到对话历史
-4. **重复：** 把更新后的上下文传回 LLM，让它基于新数据生成下一个 `Thought`
-5. **终止：** 当 LLM 确定有最终答案并使用 "Finish" 动作或输出最终响应标签时，循环结束
-
-**伪代码示意：**
-
-```python
-max_iterations = 10
-history = prompt_template.format(input=user_question)
-
-for i in range(max_iterations):
-    response = llm.generate(history)
-    
-    # 解析 Thought/Action/Observation
-    thought = extract_thought(response)
-    action = extract_action(response)
-    action_input = extract_action_input(response)
-    
-    if action == "Finish":
-        return action_input  # 最终答案
-    
-    # 执行工具
-    observation = execute_tool(action, action_input)
-    
-    # 追加到历史
-    history += f"\nThought: {thought}\nAction: {action}\nAction Input: {action_input}\nObservation: {observation}"
-```
-
----
-
-## 四、生产环境的优化技巧
-
-要让 ReAct Agent 稳定、高效地运行，避免常见陷阱，你需要以下优化：
-
-### 1. 使用少样本示例（Few-Shot Exemplars）
-
-虽然可以构建"零样本"ReAct Agent，但性能会在你加入人工编写的完整 Thought-Action-Observation 轨迹示例后显著提升。提供 **3 到 6 个** 高质量、任务特定的示例，能教会模型如何格式化想法、分解任务、处理不同工具。
-
-<div class="highlight-text">
-技巧：示例要覆盖成功路径和典型的错误恢复场景，让模型学会"碰壁后怎么绕路"。
-</div>
-
-### 2. 与 Chain-of-Thought 和自一致性结合
-
-研究表明，ReAct 高度依赖搜索结果质量；如果工具返回无用数据，模型的推理会跑偏。反过来，标准 CoT 受困于幻觉。
-
-**最佳实践是构建混合系统：**
-
-- 如果 ReAct Agent 在给定步数内无法返回答案，回退到内部 CoT 推理（使用 Self-Consistency，即采样多条 CoT 路径并取多数答案）
-- 如果 CoT-SC 置信度低，切换到 ReAct 收集外部事实
-
-这种"双保险"策略在知识密集型任务上效果最好。
-
-### 3. 设置严格的循环限制
-
-因为框架本质上是反馈循环，ReAct Agent 有时会陷入重复生成相同想法和行动的困境，导致高延迟和 token 成本爆炸。你必须在代码中设置最大迭代次数或特定结束条件（如置信度阈值）来防止无限循环。
-
-```python
-# 示例：多层防护
-MAX_ITERATIONS = 10
-MAX_COST = 0.5  # 美元
-seen_actions = set()
-
-for step in range(MAX_ITERATIONS):
-    action_signature = (action_name, action_input)
-    if action_signature in seen_actions:
-        # 检测到循环，触发终止或切换策略
-        break
-    seen_actions.add(action_signature)
-```
-
-### 4. 微调实现可扩展性
-
-纯粹从上下文提示中学习复杂推理和行动是困难的，尤其是对较小语言模型。然而，在几千条正确的 ReAct 轨迹上微调较小模型（如 8B 参数模型），能让它们大幅超越仅依赖标准提示的更大模型（如 PaLM-540B）。
-
-**工程建议：**
-- 收集生产环境中的高质量轨迹作为微调数据
-- 使用 LoRA 等高效微调技术降低计算成本
-- 小模型+ReAct 往往比大模型裸跑更省算力、更可控
-
-### 5. 实现人在回路（Human-in-the-Loop）纠正
-
-因为 ReAct 生成可读的、 verbalized 的推理痕迹，系统具有高度可解释性。你可以设计 Agent 允许人类检查其内心独白。如果模型产生了幻觉想法或走错了路，人类可以直接编辑生成的 `Thought` 文本。这能纠正模型的后续行为，引导它成功，无需重写代码或手动执行动作。
-
-**典型应用场景：**
-- 客服 Agent 遇到边界案例时，人工客服介入修正推理方向
-- 代码生成 Agent 逻辑走偏时，程序员编辑 Thought 引导它回到正轨
-- 研究 Agent 检索到无关信息时，研究员删除幻觉并提供正确线索
-
----
-
-## 五、写在最后
-
-ReAct 给我的最大启发，不是技术细节，而是一种设计哲学的转变。
-
-以前我们总想造一个"什么都知道"的 AI——把人类知识全塞进模型参数里。ReAct 走的是另一条路：<span class="highlight-text">承认模型不可能全知，给它一套"查资料+推理"的机制，让它像人一样边做边学</span>。
-
-当前 AI 的最先进水平并不依赖单一框架，而是协同的切换方法。最有能力的系统将 ReAct 与 CoT-自一致性结合，对逻辑任务利用内部参数知识，当内部置信度低时切换到 ReAct 进行外部锚定。
-
-随着我们从对话式聊天机器人过渡到能够浏览网页、使用软件工具和管理工作流的自主 Agent，Thought-Action-Observation 循环正在成为安全和可靠性的行业标准。我们不再只是构建会说话的模型；我们正在构建为了行动而思考的 Agent。
-
-
-
----
-
-**参考**
-
-[^1]: [arxiv.org/abs/2210.03629](https://arxiv.org/abs/2210.03629)
-
-[^2]: [ReAct Prompting - Prompting Guide](https://www.promptingguide.ai/techniques/react)
-
-[^3]: [What is a ReAct Agent? - IBM](https://www.ibm.com/think/topics/react-agent)
-
-[^4]: [ReAct Paper (PDF) - arXiv](https://arxiv.org/pdf/2210.03629)

source/_posts/resume.md

@@ -1,114 +0,0 @@
-title: 简历模板
-author: Gamehu
-tags:
-  - 简历
-categories:
-  - 个人
-date: 2024-12-29 22:19:00
----
-<div class="tag-container">
-  <span class="main-tag">离职系列</span>
-  <span class="sub-tag">第N篇</span>
-</div>
-<div class="article-quote">
-离职前一天，想想简历咋写，弄个排版出来，后续好造着整理下简历。纯属个人意见。我先自己试试，不好用再改。
-</div>
-
-## 我的观点
-我觉得简历的本质是为了筛选而不是为了深入了解你。所以我认为简历：
-1. 首先得清爽。
-2. 然后得简明扼要。
-
-不用写太多同时又能体现关键信息，就跟咱们做程序一样，设计时重点之一就是数据得便于各场景使用，便于使用很大的一个方面就是数据能各种过滤和组合，通常是现有简明的入口，如果要了解细节就得下钻，可能是一层或多层才能看透数据。那简历就像入口，如果对方有兴趣才会下钻，所以不应该想着一个简历就把自己交代的底裤都没有，一方面是内容太多不容易抓到重点，另一方面是太细了搞得人都没欲望深入探讨，咋约你面试呢？
-
-所以简历得像咱们对待产品需求一样，你得解决需求场景同时兼顾一些扩展性。抽象出来一个模板适配通用场景，然后可根据具体特殊场景，再保证真实的前提下做一些微调，对其JD中的要求。
-<hr>
-
-# <span style='color:red;'>抽象了一个通用模板如下：</span>
-
-## 基本信息
-- 求职意向：技术负责人/技术专家
-- 工作年限：8年+
-- 学历：xx
-- 电话：xx
-- 期望薪资：xx
-
-## 专业技能
-### 技术栈
-- 后端：Java、Spring Boot、Spring Cloud、MySQL、Redis、消息队列
-- 前端：React、TypeScript、Ant Design、Redux、Webpack
-- DevOps：Docker、Jenkins、Git、Jira
-- 架构：微服务架构、前后端分离、分布式系统设计
-
-### 管理能力
-- 团队管理：带领3-6人团队，完成项目全周期开发
-- 技术规划：制定技术方案，把控技术方向，推动技术创新
-- 敏捷实践：推行敏捷开发，提升团队效能
-- 人才培养：建立技术培训体系，提升团队技术能力
-
-## 工作经历
-### XX公司（2021-至今）
-职位：技术负责人
-
-负责工作：
-1. 带领5-6人团队完成大型LLM应用平台开发，实现从0到1
-   - 设计并实现基于微服务架构的系统框架
-   - 优化系统性能，提升用户体验
-   - 建立代码规范和技术文档体系
-   - 系统月活用户达到10w+，支持高并发访问
-
-2. 技术架构升级与优化
-   - 推动系统微服务化改造，提升系统可扩展性
-   - 实现核心模块性能优化，接口响应时间提升50%
-   - 建立监控告警体系，提高系统稳定性
-
-### XX公司（2019-2021）
-职位：Web前端负责人
-
-负责工作：
-1. 带领3-4人前端团队完成企业级SaaS平台开发
-   - 基于React技术栈搭建前端框架
-   - 实现组件库设计与开发
-   - 推动前端工程化建设
-   - 平台服务企业客户100+
-
-2. 技术改进与创新
-   - 建立前端性能监控体系
-   - 推动前端自动化测试实践
-   - 优化构建流程，部署时间缩短60%
-...
-
-## 项目经验
-
-### xx平台（2022-2023）
-- 项目规模：5-6人团队，服务10w+用户
-- 技术架构：Spring Cloud + React + MySQL + Redis
-- 主要职责：
-  - 负责整体技术方案设计
-  - 核心功能开发与性能优化
-  - 带领团队完成开发任务
-- 项目成就：
-  - 系统支持高并发访问，峰值QPS 5000+
-  - 用户响应时间<500ms
-  - 系统可用性达99.9%
-
-### xx企业级SaaS平台（2019-2021）
-- 项目规模：前端3-4人团队
-- 技术架构：React + TypeScript + Ant Design
-- 主要职责：
-  - 前端架构设计与实现
-  - 团队管理与技术指导
-  - 核心功能开发
-- 项目成就：
-  - 平台月活用户5w+
-  - 前端性能提升40%
-  - 客户满意度95%+
-
-## 教育背景
-- XX大学 计算机科学与技术 本科
-
-## 个人评价
-- 扎实的技术功底，丰富的项目经验
-- 优秀的团队管理能力和沟通协调能力
-- 具备较强的技术视野和架构设计能力
-- 持续学习，保持对新技术的敏感度

source/_posts/从Workflow到ReAct-宠物医疗质控Agent的设计实录与踩坑反思.md

@@ -0,0 +1,250 @@
+---
+title: 从 Workflow 到 ReAct：一个医疗质控 Agent 的设计实录与踩坑反思
+author: Gamehu
+date: 2026-05-27 12:00:00
+tags:
+  - AI
+  - Agent
+  - ReAct
+  - 架构设计
+  - 医疗AI
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">Agent</span>
+  <span class="sub-tag">ReAct</span>
+  <span class="sub-tag">架构设计</span>
+</div>
+
+<div class="article-quote">
+我们为大客户发现了宠物医疗质控这个痛点场景。为了快速让客户看到效果、同时证明产品能力，我<strong>一个人从零开干</strong>——不要架构的完美，只要<strong>快、简单、能见人</strong>。这篇文章没有花架子，只有从 Workflow 到 ReAct 的真实决策、踩过的坑、以及回头看的反思。
+</div>
+
+---
+
+## 一、为什么不是一套 Prompt 搞定？
+
+大客户的诉求很直白："让大模型读一下病历，打个分。"按常规思路，一套好的 Prompt 确实能应付大多数场景。
+
+但自己从零搭这个系统，没有团队兜底，我必须同时考虑两件事：<span class="highlight-text">不同病例的复杂度差异，决定了单一 Prompt 策略必然在"简单病例浪费 token"和"复杂病例能力不足"之间两头不讨好。</span>
+
+一个普通的驱虫复诊，和一个同时涉及 4 种药物联用、肝肾功能异常、既往胰腺炎病史的复杂内科病例，对推理深度的要求完全不同。前者用单轮 Workflow 足够，后者必须给 Agent 工具调用和多轮推理的能力。
+
+这个判断最终演化成了整个系统最核心的架构决策：**双路径评估（Dual-Path Evaluation）。**
+
+---
+
+## 二、架构全景：Workflow 为盾，ReAct 为矛
+
+系统的入口是一个 `CaseRouter`，它读取一份外置的 `risk_catalog.json`，对病例做信号检测和复杂度评分：
+
+- **高危药物**（如糖皮质激素、化疗药）
+- **药物-疾病冲突**
+- **多药联用**
+- **必须按指南执行的诊断**
+- **主诉中的危急信号**
+
+这些信号的权重是可配置的（1.5 ~ 3.0），累加后得到一个 `complexity_score`。阈值设在 **1.5**，同时要求 `tool_plan` 非空，才会被路由到 ReAct Agent。其余 70%~80% 的病例走固定 Workflow。
+
+```
+POST /api/v1/evaluations
+    │
+    ▼
+[CaseRouter] ── complexity_score >= 1.5 ──► [ReAct Agent + Tools]
+    │                                              │
+    └─ 简单病例 ─────────────────────────────► [EvaluationWorkflow]
+```
+
+这个分层不是炫技，而是成本与效果的精确博弈。在生产环境中，Workflow 的延迟约 1~3 秒，ReAct 由于多轮 LLM 调用，延迟在 3~8 秒，且 token 消耗通常是前者的 3~5 倍。**让简单病例为复杂病例的架构买单，是不负责任的。**
+
+---
+
+## 三、踩坑实录：代码能跑，但架构在痛
+
+### 坑 1：AgentState 的上下文幻觉
+
+我最初给 ReAct Agent 设计了一个 `AgentState` 来管理多轮对话的短期记忆。它记录了每一次工具调用的输入、输出和摘要，并在超过 6000 token 时触发 `compact()`。
+
+问题出在这个压缩策略上：它简单地保留了最近 3 条观察，把更早的记录折叠成一段纯文本摘要。**没有语义重要性判断，没有工具调用结果的优先级排序。**
+
+这意味着什么？如果 Agent 在第 1 轮调用了 `query_standard` 获取了关键诊疗指南，但在第 4~5 轮因为工具调用过多触发了 compaction，这份指南的详细内容可能会被粗糙地压缩成一句"已查询相关标准"，导致后续推理失真。
+
+<span class="highlight-text">教训：基于字符数的 token 估算（char/4）和基于条数的截断，只能算是"能跑"，离"可靠"差得很远。</span>后续必须用语义摘要或重要性评分来替代。
+
+### 坑 2：ReAct 循环里的消息格式泥潭
+
+ReAct Agent 的核心是一个 `_run_react_loop`，最多 5 轮、最多 10 次工具调用。每一轮，我需要手动拼接 OpenAI 格式的消息列表：
+
+- `system` 角色定义工具和评分维度
+- `user` 角色注入病例 + `tool_plan` + RAG 检索结果
+- `assistant` 角色的 `tool_calls`
+- `tool` 角色的返回结果
+
+这个嵌套循环（Agent 外层循环 + Provider 内层调用）让调试变得异常痛苦。有一次，LLM 明明返回了 `tool_calls`，但我在日志里只看到 `content` 为空，花了整整一个下午才发现是消息列表里的 `role` 顺序在某些边界情况下错位了。
+
+**教训：手写 ReAct 循环对消息格式的容错性极低。**如果团队资源允许，应该尽早抽象出一个 "Turn Manager"，把消息构建、工具调用、结果回写封装成原子操作，而不是在 Agent 主逻辑里裸操作字典列表。
+
+### 坑 3：Qdrant 与 PostgreSQL 的"半同步"陷阱
+
+系统用 PostgreSQL 作为唯一数据源（Source of Truth），Qdrant 作为检索加速层。这本身没问题，但我在设计审核流程时犯了一个经典错误：
+
+当医生审核通过一条 Few-Shot 示例或 Prompt 规则时，系统需要同时更新 PostgreSQL 的状态字段，并把新数据写入 Qdrant。**这两个操作不在同一个事务里。**
+
+结果是：PG 提交成功，Qdrant 写入失败（比如网络抖动），系统就会进入不一致状态——PG 显示"已批准"，但检索端查不到这条数据。更麻烦的是，由于没有事务回滚机制，修复需要手动补偿。
+
+<span class="highlight-text">任何跨存储的写操作，要么做成真正的分布式事务（Saga / 2PC），要么把 Qdrant 降级为"异步最终一致"，并通过后台任务持续对账。</span>我最终选择了后者，但应该在第一版就明确这个策略，而不是事后补丁。
+
+### 坑 4：Embedding 的沉默降级
+
+Embedding 层我用 `sentence-transformers` 加载 `text2vec-base-chinese`，同时为了测试环境能跑，写了一个 `SimpleHashEmbeddingClient` 作为 fallback。
+
+这个 fallback 的逻辑是把文本做 SHA-256，然后映射成一个固定维度的伪向量。它保证了"接口不报错"，但语义相似性完全失效——同样的文本永远得到同样的向量，不同的文本可能映射到相近的向量空间位置纯属巧合。
+
+最危险的是，这个降级是**静默的**。如果生产环境的 `sentence-transformers` 因为依赖问题没能加载，系统不会崩溃，只会默默返回毫无意义的检索结果。
+
+<span class="highlight-text">降级策略必须有明确的日志告警和人工介入机制。"能跑"不等于"可用"。</span>
+
+回头看坑 3 和坑 4，本质上是同一类问题：**"可工作"与"可靠"之间隔着一条静默失败的鸿沟。**Qdrant 写入失败后系统不会报错，Embedding 降级后系统不会报警——它们都在你眼皮底下悄悄背叛了你。生产环境中，一个明确报错的 500 远比一个悄悄返回错误结果却 HTTP 200 的系统要安全。<span class="highlight-text">生产系统不允许静默失败。</span>如果做不到强一致性，至少要把"我降级了"这件事喊出来。
+
+---
+
+## 四、那些"对的"决定
+
+踩坑之外，也有一些早期决策在后续迭代中被证明是正确的。这些决策背后有一条共同的主线：<span class="highlight-text">确定性逻辑（传统代码）做主干，大模型只做理解和分类。</span>Agent 不是把一切交给 LLM 去"聪明地判断"，而是用代码框死边界，只在模糊地带请 LLM 出手。
+
+### 1. 显式 Mock 开关
+
+我在 LLM 路由层强制要求 `LLM_USE_MOCK` 必须是显式的布尔配置，绝不允许通过 API Key 的前缀或格式来"推测"是否使用 Mock。
+
+这看起来是多此一举，直到有一次我在测试环境误配了 Key，系统如果走"自动推断"逻辑就会用真实模型跑测试，几分钟内烧掉几十块钱。显式开关让这种事故不可能发生。
+
+### 2. Workflow 作为默认路径
+
+团队里曾有争论：既然 Agent 更酷、更灵活，为什么不全部走 ReAct？
+
+我的坚持基于一个朴素的工程原则：**不要把通用炮当狙击枪用。**简单病例走固定流程，不仅快、便宜，还更容易追溯和审计。复杂病例的 Agent 输出需要被标记、被抽样、被人工复核，这个成本必须被限制在 20%~30% 的真正复杂病例上。
+
+### 3. Risk Catalog 外置化
+
+把路由规则写成 JSON 文件而不是硬编码在 Python 里，让运营同学可以在不发布版本的情况下调整权重和关键词。这对一个医疗场景至关重要——新的高危药物或指南更新随时可能出现，代码发布周期赶不上业务变化。
+
+### 4. 工具返回必须带 `summary`
+
+我在工具层强制要求每个工具返回的 JSON 里必须包含一个 `summary` 字段。这个字段被 AgentState 用于 compaction 和 prompt 重建，避免了把完整的原始数据（比如 20 条历史病历或 10 页指南）反复塞进 LLM 上下文。
+
+### 5. 硬编码上限：死循环计数器
+
+ReAct 循环我设了两个硬上限：最多 5 轮推理、最多 10 次工具调用。触发上限后直接终止并报警，而不是让 Agent "再想想"。
+
+这不是拍脑袋的数字。Agent 自主推理必须被硬编码上限约束，否则就是一个 Token 消耗黑洞。我在开发早期就踩过这个坑：一次因为 LLM 返回了格式异常的 tool_calls 导致 Agent 反复重试，如果不设上限，几分钟就能烧掉上万个 token。上限不是限制 Agent 的能力，而是保护系统不被 Agent 的"不确定性"拖垮。
+
+### 6. 代码校验而非自我反思
+
+学术论文里常见的套路是让 LLM "检查一下刚才的输出对不对"（Self-Reflection），在工业界这是一个昂贵的陷阱。它会带来双倍的延迟和双倍的 Token 成本，而且 LLM 审查自己的输出跟请作弊学生给自己监考没区别。
+
+这个系统里，所有校验逻辑都由后端代码完成：`ConsultationValidator` 在评估前硬性拦截非法病历、Pydantic `strict=True` 拒绝任何多余字段的输出、评分维度用 `model_validator` 确保分项不超过满分上限、路由决策全走关键词规则而非 LLM 判断。LLM 只管生成，代码只管校验。<span class="highlight-text">不要让 LLM 给自己当裁判。</span>
+
+---
+
+## 五、怎么知道 Agent 变好了还是变坏了？
+
+前面聊的都是 Agent 怎么"做"，但一个更深刻的问题是：你改了 Prompt、调了路由阈值、换了 embedding 模型之后，怎么知道系统是变好了还是变坏了？没有量化的评估体系，Agent 的每一次改动都是在盲飞。
+
+### 分层评估策略
+
+我参考了业内的通用做法，把评估拆成了三个层级：
+
+**节点级（Node-Level）**：单独测试 CaseRouter 的路由准确率。我写了一个 `agent_eval.py`，加载手工标注的 JSONL 测试集，跑一轮后计算路由准确率、工具精确率/召回率，以及——这个在医疗场景最关键——<span class="highlight-text">高风险漏报率（应该走 ReAct 却路由到了 Workflow 的比例）</span>。这个指标必须无限趋近于零。
+
+**组件级（Component-Level）**：针对 RAG 检索，需要检验检索到的 Few-Shot 示例是否真的相关、知识文档是否覆盖了问题域。这对应业界的 RAGAS 框架（忠实度、答案相关性、上下文召回率）。目前我主要靠人工抽查，但自动化 RAGAS 评估是优先级最高的待办。
+
+**端到端（End-to-End）**：终极指标只有一个——<span class="highlight-text">医生采纳率（Adoption Rate）</span>。评估结果出来后，医生可以选择"采纳"或"拒绝"。采纳率高的评估就是好评估，拒绝率高的就是坏评估。这个反馈闭环是 Phase 3 进化的唯一燃料。
+
+### Golden Dataset 和 LLM-as-a-Judge
+
+评估自动化依赖两样东西：
+
+一是 **Golden Dataset（金色数据集）**——从历史评估中精选 100~500 个代表性病例，人工标注"标准答案"（应该走什么路径、各维度得分预期、应该查哪些知识文档）。这是你最重要的测试资产。
+
+二是 **LLM-as-a-Judge**——用一个更强的模型（如 GPT-4o 或 Claude）来当裁判，把（用户输入 + Agent 输出 + Golden Dataset 标准答案）一起喂给它，让它按严格的评分 Rubric 打维度分。<span class="highlight-text">没有自动化裁判，评估体系就跑不起来。</span>
+
+这两样我目前都还在建设中。Golden Dataset 只有 3 条标注样本，LLM-as-a-Judge 还没接入。但方向是明确的，代码框架（`agent_eval.py`）已经铺好了。
+
+### 线上链路追踪
+
+最后，生产环境必须有 Trace 系统（LangSmith / Langfuse / Phoenix）。它们会把 Agent 一次完整执行的调用链拆解成一棵树——你能看到：请求进了哪个 Router → 耗时多少 → 调用了哪些 Tool → 每个 Tool 返回了什么 → 最终 LLM 如何组装输出。线上出了任何诡异回答，顺着 Trace 一眼就能定位到具体节点。
+
+这一点我目前还没做，但放在这里是作为一条必经之路——<span class="highlight-text">没有 Trace，Agent 就是黑盒；有了 Trace，Agent 才是白盒。</span>
+
+---
+
+## 六、Phase 3 进化系统：造好的船，等水到位
+
+项目规划了三个阶段：
+- Phase 1：固定 Workflow（已完成）
+- Phase 2：ReAct Agent（已完成）
+- Phase 3：自我进化（Pipeline 代码已完成，但未接入定时触发）
+
+Phase 3 的核心是 `EvolutionScheduler`，完整的流水线为：
+
+```
+run_evolution()
+  ├─ Step 0: 聚合反馈指标（adoption_rate / rejection_rate）
+  ├─ Step 1: 提取高质量样本 → 创建 Few-shot 候选（pending_review）
+  ├─ Step 2: 分析 Bad Case → 创建 Prompt Rule 候选（pending_review）
+  └─ Step 3: 低质样本 → 创建停用审核任务（pending_review）
+```
+
+每一次"候选"都通过 `AgentReviewTask` 进入人工审核流程，状态机为：`pending_review` → `approved` / `rejected`。<span class="highlight-text">不允许自动发布，这是对医疗场景的刻意保守。</span>
+
+Pipeline 完整的部分包括 `EvolutionScheduler.run_evolution()`（主流水线编排）、`FewShotStatsAggregator`（采纳率统计）、`SampleExtractor`（样本提取）、`BadCaseAnalyzer`（拒绝模式分析）。
+
+**尚未完成的部分是定时触发机制的接入。**这是有意为之的克制——在 Phase 1 和 Phase 2 的稳定性没有足够数据支撑之前，启动自我进化等于在没有刹车的情况下踩油门。
+
+---
+
+## 七、架构全貌：那些容易被忽略的模块
+
+以下几个实际存在但容易被忽略的模块，构成了系统的底座：
+
+**ConsultationValidator（数据校验层）** —— ReAct 执行前必须通过数据合法性校验，拦截不合法病历。若校验失败，评估直接标记为 `failed`，不进入 ReAct 推理链。这是一道数据质量门。
+
+**AgentEvaluation 完整持久化模型** —— 评估结果写入数据库，包含 `status`、`eval_mode`、`model_version`、`few_shot_ids`、`kb_doc_ids`、`total_score`、`result_json` 等字段，为后续的 `EvolutionScheduler` 提供反馈数据来源。
+
+**多租户隔离** —— 所有方法显式传入 `tenant_id`，`AgentEvaluation` 等模型均以此为主要查询索引，确保数据隔离。
+
+**Few-shot + Knowledge 双检索** —— ReAct 执行前并行检索 Few-shot 示例（提供参考案例）和 Knowledge 文档（提供指南/标准），两者共同注入 prompt。
+
+**输出护栏** —— `ConsultationValidator` 管住输入端之后，输出端同样不能裸奔。评分结果用 Pydantic `strict=True` 模式解析，任何多余字段都会被拒绝；维度分通过 `model_validator` 确保不超过 25 分的上限；LLM 返回的 JSON 自动剥离 markdown code fence（` ```json ` 包裹的情况极其常见）。<span class="highlight-text">输入端防污染，输出端防事故，缺一不可。</span>
+
+**BigInt 兼容** —— 数据库主键是 64 位整数，Python 端能正常处理，但通过 REST API 返回给前端时，JavaScript 的 `Number` 类型会丢失精度。所有 API 响应里的 ID 字段都通过 Pydantic `field_validator` 强制转为 string，前端永远不做精度假设。
+
+**优雅降级作为系统级设计** —— Qdrant 客户端加载失败时不是 crash，而是所有检索方法 return empty/no-op；Embedding 模型加载失败时 fallback 到 hash 伪向量。整个系统的设计原则是：<span class="highlight-text">任何一个外部依赖挂了，系统能降级运行，但一定会把"我降级了"这件事打出来。</span>——对应坑 4 的教训。
+
+---
+
+## 八、写在最后
+
+写 Agent 和写传统后端服务最大的区别是：**不确定性不是 bug，而是特性的一部分。**你无法像测试一个 REST API 那样精确断言 LLM 的输出，你只能设计边界、设计 fallback、设计人在回路（Human-in-the-Loop）。
+
+这个项目教会我最重要的一课是：<span class="highlight-text">Agent 的架构质量，不体现在它有多"智能"，而体现在它有多"可控"。</span>
+
+双路径设计是对可控性的妥协，显式 Mock 是对可控性的坚守，人工审核的进化系统是对可控性的敬畏。医疗 AI 不允许惊喜，只允许可预期的、可解释的、可回滚的行为。
+
+而这条"可控性"主线的底层，是同一个设计哲学：<span class="highlight-text">确定性逻辑（传统代码）做主干，大模型只做理解和分类。</span>路由用关键词不用 LLM，校验用 Pydantic 不用自反思，超时和重试用计数器不用 prompt 约束——所有能代码化的边界，绝不让 LLM 来"商量"。
+
+### 已知改进方向
+
+如果时间允许，以下几件事是明确的下一步：
+
+- **RAG Re-rank**：向量检索后加一层 Cross-Encoder 精排，把最相关的 Top 3 文档强行喂给 LLM。这是 RAG 效果提升里性价比最高的一步。
+- **Multi-Agent 拆分**：当前 ReAct Agent 一个人干所有事（查药、查化验、查指南、评分）。当某个环节频繁出错时，把它拆成独立子 Agent，职责越聚焦，效果越可控。
+- **接入 Trace 系统**（LangSmith / Langfuse / Phoenix）：把每一次 Agent 执行的完整调用链可视化。没有 Trace，调 Agent 等于盲人摸象。
+- **完善 Golden Dataset + LLM-as-a-Judge**：把评估自动化跑通，让每一次 Prompt 改动都有量化反馈。
+
+Phase 1 和 Phase 2 已在线上运行。Phase 3 的 Pipeline 代码已完成，调度触发器待接入——这是一艘造好的船，等待数据的水位足够高，才允许启航。
+
+**Agent 不是终点，而是一个持续收敛的过程。**

source/_posts/工作.md

@@ -1,61 +0,0 @@
-title: 研发负责人 / 研发专家
-author: Gamehu
-date: 2026-03-24 23:31:46
-tags: 求职
----
-
-### 研发负责人 / 全栈工程师
-
-各位好，
-
-13年一线研发，后端10年（主Java）、前端3年（主React），从写代码到带团队到架构设计，该踩的坑基本都踩过了。
-
-上一段经历，从0到1组了个团队，主导了AI+SaaS宠物医院系统的架构设计和落地，3个月上了1.0版本，拿到天使客户认可。再之前在锐捷网络干了7年多，从前端主程做到Java主程再到LMT负责人，带过10人团队，负责过500+租户的SaaS运维平台核心模块。连续两年绩效A，拿过事业部优秀员工。
-
-技术上，Java全家桶、React、微服务、数据库那些就不赘述了。比较有意思的是做过AI工程化落地——ASR医疗记录生成、RAG知识库、服务器容量预测（ClickHouse + Flink + Prophet + LLaMA2）。另外当过产品助理这段经历，让我在技术和业务之间能自如切换，不会出现"需求理解偏差导致返工"这种事。
-
-带团队这事，比Debug代码难多了。但好在两边成绩单都还过得去。
-
-详细简历在这里：
-
-- [中文简历](/resume/)
-- [English Resume](/resume/en.html)
-
-代码问候，
-Gamehu
-
-联系方式：
-邮箱：gamehu@yeah.net
-Wechat：GamehuDB
-Twitter：https://x.com/Gamehu520
-
-P.S. 我的GitHub贡献图可能不够绿，但我的代码从不让服务器变红。
-
----
-
-### R&D Lead / Full Stack Engineer
-
-Hello everyone,
-
-13 years of hands-on R&D experience — 10 years in backend (primarily Java) and 3 years in frontend (primarily React). I've gone from writing code to leading teams to designing architectures. Basically, I've stepped into most of the pitfalls there are to find.
-
-In my most recent role, I built a team from 0 to 1 and led the architecture design and implementation of an AI+SaaS veterinary hospital system. We shipped version 1.0 in 3 months and earned validation from our angel customers. Before that, I spent 7+ years at Ruijie Networks, progressing from Frontend Lead to Java Lead to LMT (Lifecycle Management Team) Lead. I managed a 10-person team and owned core modules of a SaaS operations platform serving 500+ tenants. Received "A" performance ratings for two consecutive years and won the Business Unit Outstanding Employee award.
-
-Technically, I won't bore you with the standard stack — Java ecosystem, React, microservices, databases, etc. What's more interesting is my work on AI engineering and production deployment: ASR-based medical record generation, RAG knowledge bases, and server capacity prediction (ClickHouse + Flink + Prophet + LLaMA2). Additionally, my stint as a Product Assistant taught me to move fluidly between technical and business perspectives — you'll never get "requirements misinterpretation leading to rework" from me.
-
-Leading teams is way harder than debugging code. But fortunately, my report card on both fronts is decent enough.
-
-Detailed resumes here:
-
-- [Chinese Resume](/resume/)
-- [English Resume](/resume/en.html)
-
-Code regards,
-Gamehu
-
-Contact:
-Email: gamehu@yeah.net
-WeChat: GamehuDB
-Twitter: https://x.com/Gamehu520
-
-P.S. My GitHub contribution graph may not be green enough, but my code never turns the server red.

source/_posts/懒惰的美德-当AI不再懂得偷懒的艺术.md

@@ -0,0 +1,213 @@
+---
+title: 懒惰的美德：当AI不再懂得偷懒的艺术
+author: Gamehu
+date: 2026-04-17 23:30:00
+tags:
+  - AI
+  - 软件工程
+  - 编程哲学
+  - LLM
+categories:
+  - 技术思考
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">编程哲学</span>
+</div>
+
+## 前言
+
+最近读到两篇很棒的博文，让我对 AI 时代的编程有了更深的思考。
+
+一篇是 **Bryan Cantrill** 的《The peril of laziness lost》（失去懒惰的危险）。Bryan 是 DTrace 的作者、Oxide Computer 的 CTO，系统编程领域的传奇人物。
+
+另一篇是 **Mario Zechner** 的《Thoughts on slowing the fuck down》（关于放慢脚步的思考）。Mario 是 libGDX 游戏框架的创建者，也是一位经验丰富的开发者和教练。
+
+两位作者从不同角度提出了同一个警告：<span class="highlight-text">在 AI 编程时代，我们正失去一些宝贵的东西</span>。
+
+<div class="divider-tech"></div>
+
+## Larry Wall 的三美德
+
+要理解他们的观点，得先回到 Larry Wall。
+
+Larry Wall 是谁？Perl 语言的创造者。他在那本著名的《Programming Perl》（被亲切地称为"骆驼书"）里，提出了程序员的三美德：
+
+> **懒惰、急躁、傲慢**
+
+原文是这么说的：
+
+> 如果我们要讨论好的软件设计，就必须谈到懒惰、急躁和傲慢。这些都是好软件设计的基础。我们都曾掉进复制粘贴的陷阱，其实应该定义更高层的抽象，哪怕只是一个循环或子程序。当然，有些人走向了另一个极端，定义了越来越多的高层抽象，其实应该用复制粘贴。但一般来说，我们大多数人需要思考的是使用更多抽象，而不是更少。
+
+<div class="article-quote">
+懒惰驱动我们让系统尽可能简单（但不要过于简单！）——开发强大的抽象，让我们能更容易地做更多事情。
+</div>
+
+<div class="divider-wave"></div>
+
+## 懒惰的真正含义
+
+这里的"懒惰"不是贬义词。
+
+它是一种<span class="gradient-text">工程智慧</span>：
+
+- 懒得写重复代码 → 所以抽象出通用模块
+- 懒得维护复杂系统 → 所以追求简洁设计
+- 懒得处理边界情况 → 所以在设计时就考虑周全
+
+Bryan 说得很好：
+
+> 这种看似懒惰的背后，其实是在脑子里反复思考问题。我们承担开发抽象所需的艰难智力工作，部分原因是我们正在优化假设中的未来自己的时间，即使以牺牲当前时间为代价。
+
+这就是<span class="highlight-text"> hammock-driven development </span>（吊床驱动开发）的精髓——看似在偷懒，实则在深度思考。
+
+<div class="divider-stars"></div>
+
+## LLM 的问题：不知疲倦的"勤奋"
+
+现在问题来了。<span class="wavy-underline">LLM 不会累，也不需要优化自己的时间</span>。
+
+Bryan 举了一个例子：Garry Tan（Y Combinator 的 CEO）炫耀自己用 LLM 一天写了<strong>三万七千行代码</strong>，而且"还在加速"。
+
+对比：整个 DTrace 项目大约也就六万行代码。
+
+这意味着什么？
+
+一位波兰工程师 Gregorein 解剖了 Garry Tan 的"newsletter-blog-thingy"项目，结果让人啼笑皆非：
+
+- 包含多个测试框架（？！）
+- 包含 Rails 的 Hello World 应用（？！）
+- 偷偷塞进去一个文本编辑器
+- 八个不同版本的同一个 logo，其中一个文件大小为零字节
+
+<div class="article-quote">
+这不是 bug 的问题（这些都能修），也不是方法论的问题。问题在于 LLM 本质上缺乏懒惰的美德。
+</div>
+
+<div class="divider-gradient"></div>
+
+## 错误在复合：Mario 的警告
+
+Mario Zechner 从另一个角度提出了更严峻的警告。
+
+他说现在的软件"一切都坏了"——98% 的正常运行时间反而成了常态，界面有各种奇怪的 bug。虽然这不能全怪 AI，但趋势在加速。
+
+### 复合的"小错误"
+
+Mario 提出了一个很形象的词：<span class="highlight-text">booboos</span>（小错误）。
+
+人类也会犯错，但：
+- 人类会学习，不会重复犯同样的错误
+- 人类是瓶颈，一天能写的代码有限
+- 当痛苦积累到一定程度，人类会去修复
+
+**但代理（Agents）不一样：**
+
+- <span class="wavy-underline">代理没有学习能力</span>（除非你显式教它，但它还是会忘）
+- <span class="wavy-underline">代理没有瓶颈</span>，几小时能生成几万行代码
+- <span class="wavy-underline">代理不会感到痛苦</span>，所以你不知道错误在积累
+
+这些小错误（重复的代码、无用的方法、错误的抽象）会在代理手中<span class="highlight-text">指数级复合</span>。直到有一天，你想加个新功能，发现架构已经烂到无法支持；或者用户数据被删除了，你才发现问题。
+
+### 复杂性的商人
+
+Mario 还有一个很犀利的观点：代理是<span class="gradient-text">"复杂性的商人"（merchants of learned complexity）</span>。
+
+代理在训练数据中见过太多糟糕的设计决策。当你让它们帮你设计架构时，它们会引入大量复杂性——各种 Cargo cult 的"行业最佳实践"、为了抽象而抽象的代码、不一致的重复实现。
+
+更糟糕的是，代理只有局部视野。它们看不到整个代码库，看不到之前的决策，所以总是在局部做"看起来对"的选择，最终导致全局的混乱。
+
+Mario 说："一个 2 人团队用代理，几周内就能达到传统企业代码库的复杂度。"
+
+<div class="divider-tech"></div>
+
+## 低召回率的代理搜索
+
+Mario 还指出了一个技术问题：<span class="highlight-text">代理搜索的召回率很低</span>。
+
+当代理试图重构或修复代码时，它需要先找到所有相关的代码。但无论是用 ripgrep、LSP 服务器还是向量数据库，当代码库变大时，代理总会遗漏一些代码。
+
+结果就是：
+- 遗漏现有代码 → 重复造轮子
+- 遗漏相关代码 → 修复不完整
+- 遗漏上下文 → 引入新的不一致
+
+这就是那些"小错误"产生的根本原因。然后它们会像滚雪球一样，变成一朵<span class="wavy-underline">"美丽的屎花"（shit flower）</span>。
+
+<div class="divider-stars"></div>
+
+## 为什么这很危险
+
+把这两篇文章放在一起读，我觉得他们说的是同一件事的两面：
+
+**LLM 不会感到需要为自己（或任何人）的未来时间做优化**，它们会毫无顾虑地在一层又一层的垃圾上堆叠更多垃圾。
+
+如果不加以约束，LLM 会让系统变得更大，而不是更好——可能迎合了某种扭曲的虚荣心指标，但代价是牺牲了一切真正重要的东西。
+
+<span class="highlight-text">最好的工程总是源于约束</span>，而我们人类时间的约束限制了我们对系统认知负荷的容忍度。正是这种约束驱使我们让系统更简单，尽管系统本质上就很复杂。
+
+<div class="divider-gradient"></div>
+
+
+## 放慢脚步：我现在怎么做
+
+基于两位作者的观点，我总结了几条实践建议：
+
+### 1. 限制代码生成量
+
+Mario 建议：<span class="highlight-text">给自己设定每天生成代码量的上限</span>，与你能 review 的能力相匹配。
+
+不要追求 37k 行/天，追求 100 行高质量的代码。
+
+### 2. 手写架构，代理实现
+
+架构、API 设计这些决定系统"气质"的东西，<span class="wavy-underline">必须手写</span>。
+
+用 tab 补全感受代码的构建过程，或者用结对编程的方式和代理一起写。这种摩擦能让你更好地理解系统在"感觉"上是否正确。
+
+### 3. 把 LLM 当实习生用
+
+它可以帮你写代码，但你需要 review、refactor、甚至重写。
+
+好的代理任务应该是：
+- 范围有限，不需要理解整个系统
+- 有明确的评估标准（可以自动验证结果）
+- 不是关键路径，不会导致数据丢失
+
+### 4. 追求"少即是多"
+
+当 LLM 给你一大坨代码时，问它："能不能更简洁？"
+
+学会说"不"本身就是一种能力。做更少的功能，但做对的功能。
+
+### 5. 保持批判性思维
+
+LLM 生成的代码往往"能用"但"不够好"，别被数量迷惑。
+
+定期重构，防止技术债务累积。如果你连自己写了什么都不知道，当出问题时就无法修复。
+
+<div class="divider-stars"></div>
+
+## 结语
+
+Larry Wall 说懒惰是美德，这是一种智慧。
+
+Bryan Cantrill 提醒我们，这种美德在 AI 时代变得更加稀缺。
+
+Mario Zechner 告诉我们，如果不放慢脚步，我们会被代理带入一个复杂性的深渊。
+
+机器不会累，不会觉得麻烦，不会为了追求简洁而绞尽脑汁。这些人类的"弱点"，恰恰是创造力的源泉。
+
+这不是说不该用 AI 工具。而是说：<span class="highlight-text">为了将来能少做一点，现在要多做一点思考</span>。
+
+这种"懒惰"，才是真正的懒惰。
+
+---
+
+**参考阅读：**
+
+- [The peril of laziness lost - Bryan Cantrill](https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/)
+- [Thoughts on slowing the fuck down - Mario Zechner](https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/)
+- [RFD 576: LLM as Programmers - Oxide](https://rfd.shared.oxide.computer/rfd/0576)
+- [Programming Perl - Larry Wall](https://en.wikipedia.org/wiki/Programming_Perl)

source/_posts/架构师的学习-DDD.md

@@ -17,6 +17,42 @@ DDD 我在上一家公司的时候就专门学习过，也做了一些实践，
 {%asset_img 1.png %}
 {%asset_img ddd-01.png %}
 
+## DDD的核心理念：为什么需要DDD？
+
+<div class="article-quote">
+大多数软件出问题，不是因为语法错误或 if-else 逻辑有 bug，而是因为团队与业务问题失去了对齐。
+</div>
+
+ByteByteGo 的 Alex Xu 在《Domain-Driven Design (DDD) Demystified》中指出：<span class="highlight-text">"DDD 是一种以业务领域——而非数据库 schema 或最新框架——为决策中心的软件设计方法。"</span>它要求工程师在整个项目生命周期中与领域专家深度协作，而不仅仅是收集一次需求就消失到 Jira 工单里[^1]。
+
+David Laribee 在 MSDN Magazine（2009年2月）中也给出了经典定义：<span class="highlight-text">"DDD 是一系列原则和模式的集合，帮助开发者构建优雅的对象系统。恰当应用它可以产生被称为领域模型的软件抽象，这些模型封装了复杂的业务逻辑，弥合了业务现实与代码之间的鸿沟。"</span>[^2]
+
+### DDD不是什么"银弹"
+
+DDD 不会自动生成代码，也无法魔法般修复一个遗留单体。但它提供的价值更为深远：**清晰**——清晰知道系统应该做什么，以及它被允许在哪里变化[^1]。
+
+### DDD最适合什么场景？
+
+根据 ByteByteGo 的分析，DDD 在以下场景最具价值[^1]：
+
+1. **领域非平凡且在持续演进**——金融、医疗、物流、大型电商等
+2. **多个团队在系统的重叠部分工作**——需要统一的语言和清晰的边界
+3. **代码需要反映真实业务行为**——而不是抽象的技术构造
+
+一个值得注意的洞见是：**DDD 不关心架构是单体还是微服务，它关心的是模型是否反映领域的真实规则和语言，以及该模型能否随领域的变化安全演进**[^1]。
+
+### 柏拉图式的模型：代码是领域的"影子"
+
+David Laribee 用柏拉图的洞穴寓言来类比 DDD 的理念[^2]：
+
+> 柏拉图提出，我们通过感官直觉和感知到的概念、人、地点和事物，仅仅是真相的"影子"。他称真正的"事物"为**理型（Form）**。
+>
+> 在洞穴寓言中，被锁在洞穴中的人只能看到洞壁上的影子。当动物走过洞口时，影子投射到墙上——洞中人以为那就是真实的事物。但实际上，那只是真实"理型"的影子。
+
+在 DDD 中，你要追求的完美领域模型就像柏拉图的"理型"。这个理想模型散落在领域专家的头脑中、利益相关者的期望里、行业规范的要求间——这些都可以被理解为洞中人所看到的"影子"。而编程语言的限制、时间和预算的约束，就是洞中人只能看到墙壁的局限。
+
+Eric Evans 将这个过程称为 **"将知识碾碎进模型"（Crunching Knowledge into Models）**[^2]——当你对领域有了重要的新认识，你知道应该把它体现在代码的哪里。
+
 ## 示例
 构建一个**在线电子商务系统（E-Shop）**的设计示例。这个示例将从宏观的战略设计（如何划分系统边界）到微观的战术设计（代码层面的核心元素），全面展示 DDD 的核心思想。
 
@@ -38,6 +74,10 @@ DDD 的首要原则是软件必须植根于领域，并且模型需要有清晰
 *   **消除歧义：** 同一个词（如“商品”）在不同上下文中可能有不同的含义和属性。通过划分上下文，我们可以保证模型在各自边界内的纯洁性和一致性。
 *   **上下文映射（Context Map）：** 我们定义这两个上下文的关系。例如，报表系统需要从交易系统获取数据，它们可能通过**客户-供应商（Customer-Supplier）**模式交互，或者通过**防崩溃层（Anticorruption Layer）**来转换数据，确保报表系统的模型不受交易系统模型变更的直接破坏,。
 
+> David Laribee 在 MSDN Magazine 中特别强调了**防腐层（Anti-Corruption Layer, ACL）**的价值：它是阻止非领域概念泄漏到模型中的"守门人"。有意思的是，Repository 模式本身也是一种 ACL——它将 SQL 或 ORM 构造隔离在领域模型之外[^2]。
+
+> 关于限界上下文的实践，MSDN 文章特别提到了 **Greg Young**——他是在架构层面运用 Bounded Contexts（如分离事务库与报表库）的专家，生产了大量关于该主题的优质内容[^2]。
+
 ### 2. 战术设计：领域模型的核心要素
 
 在“在线交易上下文”内部，我们使用战术模式来构建领域模型。
@@ -78,12 +118,18 @@ DDD 的首要原则是软件必须植根于领域，并且模型需要有清晰
 *   **示例：** `CheckoutService`（结账服务）或 `FundTransferService`（转账服务）。
 *   **设计理由：** 结账可能涉及订单状态更新、库存扣减、支付网关调用等。这些行为放入 `Order` 或 `Customer` 都不合适，因此我们创建一个无状态的**领域服务**来封装这些操作,。
 
+> **领域服务 vs 应用服务**：David Laribee 区分了这两种服务[^2]：
+> - **领域服务（Domain Service）**：代表不以特定实体为中心的领域过程或操作，通常以动词或业务活动命名，是通用语言的一部分。例如 `PolicyRenewalProcessor`。
+> - **应用服务（Application Service）**：用于引入分层架构，负责将模型数据映射为客户端所需的形式，或集成多个模型。例如将领域模型通过 WCF 暴露给外部系统。
+
 #### F. 资源库 (Repositories)
 为了解耦领域模型与数据库。
 
 *   **示例：** `OrderRepository`。
 *   **设计：** 领域层只定义接口 `findOrder(id)`，不关心底层是 SQL Server 还是 Oracle。资源库负责从数据库中检索数据并将其重建为领域对象（如 `Order` 聚合）。这让开发人员可以像从内存集合中获取对象一样获取领域对象，而无需在业务逻辑中编写 SQL,。
 
+> David Laribee 明确指出：**"持久化是基础设施"（Persistence is infrastructure）**。Repository 的价值在于阻止 SQL 语句或存储过程等持久化概念混入领域模型。他同时指出，很多人会声称"数据库就是模型"——这在高度规范化并辅以图形化工具时确实能传达很多领域信息，但纯数据建模技术（如 ERD 或类图）无法展现一个领域中固有的**行为**——你需要看到模型的各部分如何运动、类型之间如何协作来完成工作[^2]。
+
 ### 3. 系统运作流程示例
 
 结合上述概念，一个“用户修改收货地址”的业务场景在代码设计中如下流转：
@@ -96,16 +142,65 @@ DDD 的首要原则是软件必须植根于领域，并且模型需要有清晰
 
 ---
 
-### 总结与比喻
+### DDD思想领袖与经典著作
+
+如果想深入学习 DDD，了解谁是真正的"意见领袖"非常重要。以下是技术界公认的 Top 级人物与他们的核心阵地：
 
-这个设计示例体现了 DDD 的核心：**通过将软件实现与业务领域模型紧密绑定，来应对复杂性。**
+#### 1. Eric Evans —— DDD 的开创者（"蓝皮书"作者）
 
-为了巩固理解，我们可以用书中提到的**汽车制造**来类比这个系统设计：
+毫无疑问，Eric Evans 是 DDD 的"亲生父亲"。他在 2003 年出版了奠基之作《**领域驱动设计：软件核心复杂性应对之道**》（*Domain-Driven Design: Tackling Complexity in the Heart of Software*），也就是技术圈常说的**"蓝皮书"**。
 
-*   **领域模型**就像是汽车的**设计蓝图**。工人在造车前必须先有精准的图纸，同样，开发软件前必须先理解并建模业务领域。
-*   **实体与聚合**就像是汽车的**发动机和底盘**。它们是核心部件，有独立的标识和生命周期，必须作为一个整体来组装和维护。
-*   **分层架构**就像是汽车的**不同系统**（传动系统、电子系统、内饰）。内饰（UI）的变化不应直接影响发动机（领域逻辑）的运作。
-*   **通用语言**就像是工程师团队之间的**技术术语**。如果有人把“方向盘”叫成“转弯器”，制造过程就会混乱；同样，代码必须精确使用业务术语。
+* **核心贡献：** 提出了**限界上下文（Bounded Context）、通用语言（Ubiquitous Language）、聚合（Aggregate）、实体（Entity）、值对象（Value Object）**等 DDD 核心概念。David Laribee 称这本书为"业界最具经验的软件设计师之一所著的宝库"[^2]。
+* **所在机构：** 创立了 **Domain Language** 咨询公司，至今依然在世界各地的顶级技术会议上发表 DDD 相关演讲。
+* **经典思想：** "将知识碾碎进模型"（Crunching Knowledge into Models）——代码是领域理解的不断演进，而非一次性的需求文档翻译[^2]。
+
+#### 2. Vaughn Vernon —— DDD 落地实践的第一人（"红皮书"作者）
+
+如果说 Eric Evans 定义了 DDD 的**理论框架**，那 Vaughn Vernon 就是将 DDD 真正**工程化、可落地**的关键人物。
+
+* **核心著作：** 《**实现领域驱动设计**》（*Implementing Domain-Driven Design*，2013），被称为**"红皮书"**。这本书极大地补充了蓝皮书中缺失的实操细节和代码示例。后续又出版了《Reactive Messaging Patterns with the Actor Model》和《Strategic Monoliths and Microservices》。
+* **开源贡献：** 在 GitHub 上提供了大量基于 Java / C# 等语言的 DDD 落地脚手架和示例代码（如 `IDDD_Samples`）。
+* **个人网站：** [vaughnvernon.co](https://vaughnvernon.co)
+
+#### 3. Vlad Khononov —— 现代 DDD 的集大成者（"黑白皮书"作者）
+
+Vlad Khononov 撰写了近几年广受好评的《**学习领域驱动设计**》（*Learning Domain-Driven Design*，O'Reilly，2021），因封面设计被称为**"黑白皮书"**。
+
+* **核心贡献：** 他成功地将经典 DDD 理论与**微服务、云原生架构、现代企业架构**进行了完美桥接，是目前最符合当下技术栈的 DDD 权威读物。如果你觉得蓝皮书太厚太理论，黑白皮书是更好的入门选择。
+
+---
+
+#### 特殊贡献者
+
+##### Alberto Brandolini —— Event Storming（事件风暴）发明人
+
+* **核心贡献：** 提出了**事件风暴（Event Storming）**这一工作坊形式。这是目前全球公认在业务梳理、限界上下文发现、微服务边界识别中最有效的协作建模方法之一。
+* **代表著作：** 《Introducing EventStorming: An act of Deliberate Collective Learning》
+* **核心理念：** DDD 不只是编码，更是**团队协作和知识发现**的过程。
+
+##### Greg Young —— CQRS 与架构级限界上下文的先驱
+
+在 MSDN Magazine（2009年）中，David Laribee 特别推荐跟踪 Greg Young 的博客，称其在架构层面运用 Bounded Contexts（如分离事务数据库与报表数据库）方面"经验丰富且表达清晰"[^2]。Greg Young 后来也以 **CQRS（命令查询职责分离）**模式的推广者而广为人知。
+
+---
 
 ### 学习资料
-https://github.com/Sairyss/domain-driven-hexagon?tab=readme-ov-file
+
+*   **经典著作：**
+    *   Eric Evans - *Domain-Driven Design*（蓝皮书，2003）—— DDD 圣经
+    *   Vaughn Vernon - *Implementing Domain-Driven Design*（红皮书，2013）—— 落地指南
+    *   Vlad Khononov - *Learning Domain-Driven Design*（黑白皮书，2021）—— 现代最佳入门
+
+*   **在线资源：**
+    *   [domain-driven-hexagon](https://github.com/Sairyss/domain-driven-hexagon) —— DDD 与六边形架构的 TypeScript 实战脚手架
+    *   [IDDD_Samples](https://github.com/VaughnVernon/IDDD_Samples) —— Vaughn Vernon 的官方代码示例
+    *   [Yahoo! DDD Group](https://tech.groups.yahoo.com/group/domaindrivendesign) —— Eric Evans 书中推荐的早期 DDD 社区[^2]
+
+*   **经典文章：**
+    *   David Laribee, *Best Practice - An Introduction To Domain-Driven Design*, MSDN Magazine, February 2009[^2]
+    *   Alex Xu (ByteByteGo), *Domain-Driven Design (DDD) Demystified*, April 2025[^1]
+
+---
+
+[^1]: Alex Xu, "Domain-Driven Design (DDD) Demystified," ByteByteGo Newsletter, April 24, 2025. https://blog.bytebytego.com/p/domain-driven-design-ddd-demystified
+[^2]: David Laribee, "Best Practice - An Introduction To Domain-Driven Design," MSDN Magazine, Vol. 24 No. 02, February 2009. https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design

source/resume/en.md

@@ -1,178 +0,0 @@
----
-title: Gamehu - Resume
-date: 2025-02-22 19:31:46
-type: resume
-comments: false
----
-
-## Basic Information
-
-| | |
-|---|---|
-| **Name** | Gamehu |
-| **Experience** | 13 years |
-| **Email** | <gamehu@yeah.net> |
-| **Blog / WeChat Official Account** | [gamehu.run](https://gamehu.run) / Gamehu |
-| **Education** | B.S. Computer Science, Chongqing University of Science and Technology |
-
----
-
-## Highlights
-
-- **12+ years hands-on development** — 10 years backend (Java-centric), 3 years frontend (React-centric), full-depth capability from coding to architecture
-- **4+ years team management** — built teams from scratch, established OKR systems, defined engineering standards and delivery workflows
-- Led **AI+SaaS product architecture** from inception to launch, validated by pilot customers
-- Drove core module development for a **500+ tenant SaaS platform** at Ruijie Networks; consecutive A-rated performance reviews, received division-level Outstanding Employee award
-- Strong **enterprise architecture** skills: microservice decomposition, multi-tenant isolation, data pipelines, AI engineering
-- Proficient with Alibaba Cloud and AWS; consistently drove technical standardization and DFX practices within teams
-
----
-
-## Tech Stack
-
-| Area | Technologies |
-|---|---|
-| **Backend** | Java, Spring Boot, Spring Cloud, Python, Go |
-| **Frontend** | React, Vue, GraphQL |
-| **Databases** | PostgreSQL, MySQL, Oracle, ClickHouse, Redis, MongoDB, Elasticsearch |
-| **Middleware** | Kafka, Pulsar, RabbitMQ, Flink, Zookeeper, xxl-job |
-| **AI / ML** | LLM integration (LLaMA2/Ollama), ASR engineering, RAG knowledge base |
-| **DevOps** | Docker, Kubernetes, Nginx, Prometheus, Arthas |
-| **Cloud** | Alibaba Cloud, Volcengine, AWS |
-
----
-
-## Work Experience
-
-### Sichuan Gongshantou AI Technology Co., Ltd. · Head of R&D
-**2025-03 – Present | Chengdu**
-
-#### Luling AI Veterinary Hospital Smart System
-
-An AI+SaaS management platform embedded in the full veterinary hospital workflow — addressing SOP standardization, consultation quality improvement, talent replication, and pharmacy management to achieve efficiency and decision-support closed loops.
-
-**Tech Stack:** Spring Cloud · ASR · React · Flutter · UniApp · Nacos · xxl-job · ClickHouse · Redis · PostgreSQL · Docker · Prometheus
-
-**Key Responsibilities:**
-
-- **Team Building**: Built the R&D team from scratch — recruitment, role allocation, talent pipeline planning, and established engineering standards and delivery processes
-- **Architecture Design**: Led overall AI+SaaS architecture covering multi-tenant isolation, AI workflow orchestration, and ASR-based medical record generation; completed technology selection, architecture reviews, and reliability design
-- **Technical Roadmap**: Aligned technical evolution path with business roadmap, driving milestone-based delivery
-- **Core Development**: Hands-on coding for core modules; maintained code quality through code reviews and detailed design reviews
-  - Java: real-time keyword matching, multi-device audio capture, AI data extraction
-  - Python: edge device multi-stream second-level screenshot capture
-- **DFX Resolution**: Resolved technical debt issues — e.g., optimized a system handling 2,000 diagnostic keywords with 3s real-time matching under 30 concurrent sessions, achieving 10x performance improvement after refactoring
-- **Results**:
-  - Built strong team self-drive culture
-  - Established efficient development cadence and production monitoring system
-  - Shipped v1.0 within 3 months, earning pilot customer validation and stable partnership
-
----
-
-### Ruijie Networks Co., Ltd. · Java Tech Lead / Frontend Tech Lead / LMT Lead
-**2017-10 – 2025-01 (7 years 3 months) | Chengdu**
-
-#### Cloud Co-pilot Intelligent O&M Platform
-
-Alibaba Cloud-based SaaS O&M platform (10+ developers, 500+ tenants) providing cloud-ground unified monitoring, AI algorithms, and CRM capabilities for proactive service and 24/7 support.
-
-**Tech Stack:** Spring Cloud · Vue · UniApp · Flowable · Powerjob · Flink · ShardingSphere · Pulsar · ClickHouse · Redis · PostgreSQL · Docker · K8s
-
-**Key Responsibilities (Java Tech Lead):**
-
-- Owned detailed design and implementation of CRM, task board, tenant notification, task strategy, and complaint tracking modules
-- Led **DFX system consolidation**: concurrent strategy triggering, core business monitoring, sharded query performance optimization
-- Completed **server capacity prediction architecture validation** (ClickHouse + Flink + Prophet + LLaMA2), driving AI capability productization
-- Managed cloud platform DevOps (Docker/K8s) and production incident response
-
----
-
-#### Lexiang Intelligent O&M Management Platform
-
-Flagship O&M platform (70+ developers, ~¥100M annual revenue) with metrics-driven unified resource monitoring across 15+ functional modules including visualization center, work center, monitoring center, and alert center.
-
-**Tech Stack:** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · ArangoDB · PostgreSQL · Redis · Python · Go · Docker · K8s
-
-**Key Responsibilities:**
-
-**① LMT Lead (~3 years | 10-person team)**
-- **Team Management**: Built and managed a 10-person cross-functional team; defined member profiles and annual OKRs; established team performance evaluation mechanisms
-- **Engineering Standards**: Defined field defect handling processes and technical standards; tracked issue resolution progress
-- **Technical Problem Solving**: Led on-site K8s service availability issue resolution (environment, network, service stability); drove DFX consolidation and implementation
-- **Data-Driven Efficiency**: Built a Python + Vue analytics system for field bug distribution and team efficiency metrics
-- **AI Engineering Practice**: Deployed a private knowledge base using AnythingLLM + Ollama for field issue resolution
-- **Cross-Team Collaboration**: Coordinated cross-team communication, resource alignment, and progress tracking
-
-**② Java Tech Lead**
-- Owned detailed design and API development for strategy management, alert center, data warehouse, and resource discovery modules
-- Led **master data center core API design and development** (CMDB · Model · Strategy · Federated Query)
-- Code Review
-
----
-
-#### Cheetah Intelligent O&M Platform
-
-A business O&M management tool (30+ developers) enabling proactive closed-loop fault handling: detection → analysis → localization → resolution.
-
-**Tech Stack:** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · PostgreSQL · Redis · GraphQL · Dubbo · Docker
-
-**Key Responsibilities (Frontend Tech Lead / Full Stack):**
-- Led frontend technology selection and evaluation (React · eggjs · Formily); built the frontend component library and established frontend development standards
-- Developed core frontend modules for business experience center, alert center, and traffic analysis center
-- Led frontend code reviews
-- Set up backend project scaffolding; implemented backend modules including system configuration
-
----
-
-### Chengdu Dispuna Co., Ltd. · Web Team Lead
-**2017-04 – 2017-10 (6 months) | Chengdu**
-
-#### Big Data Intelligent O&M Platform
-
-A log analysis and host monitoring platform for financial industry O&M teams (8 developers), processing hundreds of MB to several GB of log data daily.
-
-**Tech Stack:** Spring Boot · Vue · Kafka · HBase · Hadoop · Storm · Redis · Elasticsearch · MySQL · Dubbo
-
-**Key Responsibilities (Web Team Lead, 3 members):**
-- Managed team member goals and performance; rotated as ScrumMaster, driving daily standups and task tracking
-- Owned core business design and implementation: Kafka consumption, real-time push, ES index construction
-- Completed log data ETL and Kafka cluster multi-instance validation
-
----
-
-### Elane (Beijing) Data Technology Co., Ltd. · Java Developer
-**2016-03 – 2017-03 (1 year)**
-
-#### Container Shipping Management SaaS Platform
-
-During the monolith-to-SaaS refactoring transition — responsible for platform maintenance, Redis Sentinel multi-instance session sharing implementation, enterprise client requirement assessment and delivery, Express + MongoDB async data exchange center development, and new hire mentoring.
-
-**Tech Stack:** Spring · Kafka · Redis · MySQL · Zookeeper · Docker · MongoDB · Spark · Hive · Node.js
-
----
-
-### Beijing Zhongke Fulong Technology Co., Ltd. · Product Assistant
-**2015-06 – 2016-03 (9 months)**
-
-Handled business requirement research, requirement documentation, client relationship management, and project planning coordination for digital factory and State Grid energy management platform projects.
-
----
-
-### Beijing Shenzhou Aerospace Technology Co., Ltd. · Java Developer
-**2013-04 – 2015-06 (2 years 2 months)**
-
-Participated in detailed design, coding, unit testing, and documentation for the Aerospace Model Collaborative Development Management System (AVDPM) and Product Data Package System Phase 1.
-
-**Tech Stack:** Oracle · SQL Server · Java · jQuery
-
----
-
-## Education
-
-| University | Major | Degree |
-|---|---|---|
-| Chongqing University of Science and Technology | Computer Science and Technology | Bachelor's |
-
----
-
-[中文版本](/resume/)

source/resume/index.md

@@ -1,178 +0,0 @@
----
-title: 简历
-date: 2025-02-22 19:31:46
-type: resume
-comments: false
----
-
-## 基本信息
-
-| | |
-|---|---|
-| **姓名** | Gamehu |
-| **工作年限** | 13年 |
-| **邮箱** | <gamehu@yeah.net> |
-| **博客/公众号** | [gamehu.run](https://gamehu.run) / Gamehu |
-| **学历** | 本科 · 重庆科技大学 · 计算机科学与技术 |
-
----
-
-## 个人亮点
-
-- **12年+一线研发经验**，后端10年（主Java）、前端3年（主React），具备从编码到架构的完整技术纵深
-- **4年+团队管理经验**，有从0到1组建团队、制定OKR、建立研发规范与交付体系的完整实践
-- 主导过 **AI+SaaS 产品从立项到上线**的全链路架构设计，并获得天使客户验证
-- 在锐捷网络主导 **500+ 租户 SaaS 平台**核心模块研发，连续两年绩效A，获事业部优秀员工奖
-- 具备 **企业级系统架构**设计能力：微服务拆分、多租户隔离、数据流水线、AI 工程化落地
-- 熟练使用阿里云、AWS；在团队内持续推动技术标准化、DFX 落地
-
----
-
-## 技术栈
-
-| 方向 | 技术 |
-|---|---|
-| **后端** | Java、Spring Boot、Spring Cloud、Python、Go |
-| **前端** | React、Vue、GraphQL |
-| **数据库** | PostgreSQL、MySQL、Oracle、ClickHouse、Redis、MongoDB、Elasticsearch |
-| **中间件** | Kafka、Pulsar、RabbitMQ、Flink、Zookeeper、xxl-job |
-| **AI / ML** | LLM 集成（LLaMA2/Ollama）、ASR 工程、RAG 知识库 |
-| **DevOps** | Docker、Kubernetes、Nginx、Prometheus、Arthas |
-| **云平台** | 阿里云、火山云、AWS |
-
----
-
-## 工作经历
-
-### 四川攻山头人工智能科技有限公司 · 研发负责人
-**2025-03 ~ 至今 | 成都**
-
-#### 鹿瓴 AI 宠物医院智慧系统
-
-嵌入宠物医院全流程的 AI+SaaS 经营管理平台，解决 SOP 标准制定、医生问诊质量提升、人才复制、药品管理等核心管理与执行痛点，实现提效与辅助决策闭环。
-
-**技术栈：** Spring Cloud · ASR · React · Flutter · UniApp · Nacos · xxl-job · ClickHouse · Redis · PostgreSQL · Docker · Prometheus等
-
-**主要职责：**
-
-- **团队建设**：从0到1组建研发团队，完成人员招募、角色分工与梯队规划，制定研发规范与交付流程
-- **架构设计**：主导 AI+SaaS 整体技术架构设计，覆盖多租户隔离、AI 流程编排、ASR 医疗记录生成等核心模块；完成技术选型、架构评审与可靠性设计
-- **技术路线规划**：结合业务 Roadmap 制定技术演进路径，推动阶段性版本按节点交付
-- **核心开发**：参与核心模块编码，通过 Code Review、核心功能的详设评审等活动把控代码质量与技术标准落地
-  - Java 处理关键词实时命中、多端收音、AI 数据抽取等需求实现
-  - Python 边缘盒子多视频流秒级截图需求实现
-- **DFX 问题处理**：为技术债等问题提供解决方案或执行重构解决问题，比如诊疗2000个关键词需对话中3s命中+30并发问题的解决，重构优化后性能提升10倍
-- **成果**：
-  - 构建了较好的团队自驱力
-  - 建立了较高效的开发节奏和线上监控体系
-  - 3个月完成1.0版本上线，获得天使客户认可并建立稳定合作
-
----
-
-### 锐捷网络股份有限公司 · Java 主程 / 前端主程 / LMT 负责人
-**2017-10 ~ 2025-01（7年3个月）| 成都**
-
-#### 云辅驾智能运维平台
-
-基于阿里云的 SaaS 运维平台（研发10+，接入500+租户），为集团内部服务团队提供云地一体监控、AI 算法及 CRM 等能力，实现主动服务与7×24保障。
-
-**技术栈：** Spring Cloud · Vue · UniApp · Flowable · Powerjob · Flink · ShardingSphere · Pulsar · ClickHouse · Redis · PostgreSQL · Docker · K8s
-
-**主要职责（Java 主程）：**
-
-- 负责 CRM、任务看板、租户平安通告、任务策略、投诉跟进等**核心模块详细设计与编码**
-- 主导 **DFX 体系整理与落地**：并发策略触发、核心业务监控、分表查询等关键性能治理
-- 完成**服务器容量预测技术架构验证**（ClickHouse + Flink + Prophet + LLaMA2），推动 AI 能力工程化
-- 负责云平台日常 DevOps（Docker/K8s）及线上故障定位处理
-
----
-
-#### 乐享智能运维管理平台
-
-旗舰运维平台（研发70+，年销售额约1亿），以指标体系为核心实现全域资源统一监控，覆盖可视中心、工作中心、监控中心、告警中心等15+功能模块。
-
-**技术栈：** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · ArangoDB · PostgreSQL · Redis · Python · Go · Docker · K8s
-
-**主要职责：**
-
-**① LMT 负责人（接近3年 | 团队10人）**
-- **团队管理**：组建并管理10人跨职能团队，制定成员画像与年度 OKR，建立团队绩效评估机制
-- **研发规范建设**：制定现场缺陷处理流程与技术规范，跟进故障处理进度
-- **技术问题攻坚**：主导现场 K8s 服务可用性问题处理（环境、网络、服务稳定性），主导 DFX 梳理与落地
-- **效能数字化**：使用 Python + Vue 自建数据分析系统，统计现场 Bug 分布与人效数据
-- **AI 工程化实践**：基于 AnythingLLM + Ollama 搭建现场问题私有知识库
-- **跨团队协作**：负责跨团队沟通协调、资源对接与进度推进
-
-**② Java 主程**
-- 负责策略管理、告警中心、数据仓库、资源发现等模块详细设计与接口开发
-- 主导**主数据中心核心 API 设计与开发**（CMDB · 模型 · 策略 · 联邦查询）
-- Code Review
-
----
-
-#### 猎豹智能运维平台
-
-研发规模30+的业务运维管理工具，实现从被动排障到主动闭环的故障感知→分析→定位→解决全链路能力。
-
-**技术栈：** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · PostgreSQL · Redis · GraphQL · Dubbo · Docker
-
-**主要职责（前端主程 / 全栈）：**
-- 负责前端技术选型预研（React · eggjs · Formily），搭建前端组件库，制定前端开发规范
-- 开发业务体验中心、告警中心、流量分析中心等核心前端模块的详细设计与编码
-- 主持前端 Code Review
-- 搭建后端项目脚手架；负责系统配置等模块后端编码
-
----
-
-### 成都迪斯普纳股份有限公司 · Web 小组负责人
-**2017-04 ~ 2017-10（6个月）| 成都**
-
-#### 大数据智能运维平台
-
-面向金融行业运维团队的日志分析与主机监控平台（研发8人），每日处理百MB至数GB量级日志数据。
-
-**技术栈：** Spring Boot · Vue · Kafka · HBase · Hadoop · Storm · Redis · Elasticsearch · MySQL · Dubbo
-
-**主要职责（Web 小组负责人，3人）：**
-- 负责团队成员目标管理与绩效管理；轮值 ScrumMaster，推进全团队站会与任务跟踪
-- 负责核心业务设计与编码，Kafka 消费、实时推送、ES 索引构建
-- 完成日志数据 ETL 及 Kafka 集群多实例验证
-
----
-
-### 亿海蓝（北京）数据技术股份公司 · Java 开发工程师
-**2016-03 ~ 2017-03（1年）**
-
-#### 集装箱运输管理 SaaS 平台
-
-正处于单体应用向 SaaS 架构重构转型期，负责平台维护、Redis Sentinel 多实例 Session 共享方案落地、大客户需求评估与落地、Express + MongoDB 异步数据交换中心开发，及新人带教。
-
-**技术栈：** Spring · Kafka · Redis · MySQL · Zookeeper · Docker · MongoDB · Spark · Hive · Node.js
-
----
-
-### 北京中科辅龙科技股份有限公司 · 产品助理
-**2015-06 ~ 2016-03（9个月）**
-
-承担数字工厂、国家电网能源管控平台两个项目的业务需求调研、需求文档编写、客户关系维护与项目计划协调。
-
----
-
-### 北京神舟航天科技技术有限公司 · Java 开发工程师
-**2013-04 ~ 2015-06（2年2个月）**
-
-参与航天型号协同研制管理系统（AVDPM）及产品数据包系统一期的功能模块详细设计、编码、单元测试与文档编写。
-
-**技术栈：** Oracle · SQL Server · Java · jQuery
-
----
-
-## 教育背景
-
-| 学校 | 专业 | 学历 |
-|---|---|---|
-| 重庆科技大学 | 计算机科学与技术 | 本科 |
-
----
-
-[English Version](/resume/en.html)