doc: 删除多篇文章并新增《AI Agent 架构深度解析：从软件-3-0-到生产级落地》，更新简历信息

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

@@ -0,0 +1,201 @@
+---
+title: AI Agent 架构深度解析：原理、模式与生产落地
+author: Gamehu
+date: 2026-03-31 10:39:52
+tags:
+  - AI
+  - Agent
+  - LLM
+  - 架构设计
+  - 软件工程
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">Agent</span>
+  <span class="sub-tag">LLM OS</span>
+</div>
+
+> 这篇是我最近准备搭 Agent 时整理的学习笔记。它和上一篇 [《Agentic 入门：让 AI 不再一把梭，而是像人一样反复干活》](Agentic-入门：让-AI-不再一把梭，而是像人一样反复干活.md) 是一个系列：上一篇偏“怎么上手”，这一篇偏“底层怎么运转、上线怎么落地”。
+
+最近我想给自己的工作流做一套 Agent，结果第一周就被现实教育了：这事远不只是“写个提示词模板”那么简单。
+
+真动手之后你会发现，问题全在工程细节里。记忆怎么分层存储？任务队列怎么调度？循环什么时候该停？状态怎么恢复？这些都决定了系统是“能跑 Demo”，还是“能稳定跑在生产上”。
+
+最不适应的一点是，传统软件那套确定性思维在这里会失灵一大截。以前写业务代码，if-else 写完，流程基本可预期；现在很多控制流是 LLM 在运行时动态决定的，排错方式也完全变了。
+
+所以这篇我会把最近研究的几条主线串起来：Andrej Karpathy 的 LLM OS 视角、BabyAGI 的循环架构、以及 LangGraph 的状态机模式。目标很简单：把我自己踩坑后想明白的东西讲清楚，也给正在做 Agent 的你一个可复用的分析框架。
+
+## 一、核心概念深度辨析：Agent 与 Agentic
+
+先说我自己这次最大的认知纠偏：Agent 是"系统实体（名词）"，而 Agentic 是"设计模式与工作流（形容词）"。
+
+### 1. Agent（智能体）：基于大语言模型操作系统（LLM OS）的计算实体
+
+Agent 不仅仅是一个高级聊天机器人，而应该被视为一种具备拟人化特征的数字实体（People Spirits），或者说是基于大语言模型操作系统（LLM OS）运行的一台新型计算机<sup>4-6</sup>。在 LLM OS 的宏观架构中：
+
+* **CPU（中央处理器）：** 大语言模型（LLM）本身负责指令处理、推理与决策<sup>5, 7</sup>。
+* **RAM（内存/工作记忆）：** 模型的**上下文窗口（Context Window）**。这是一种短期的工作记忆，LLM 在此编排内存与计算以解决问题<sup>7, 8</sup>。
+* **外设与接口（Tools）：** Agent 可以通过工具调用与数字世界的外部基础设施交互，例如访问文件系统、运行代码沙箱或调用网络浏览器<sup>5, 9, 10</sup>。
+
+### 2. Agentic Workflow（智能体化工作流）：告别 Zero-shot 的迭代范式
+
+吴恩达（Andrew Ng）指出，传统上我们主要以"零样本（Zero-shot）"模式使用 LLM，即提示模型逐字生成最终输出而不进行任何修改。这很像要求一个人从头到尾敲击键盘写文章，全程不允许按退格键<sup>11</sup>。
+
+**Agentic 工作流是一种引入迭代循环（Loop）的系统方法论。** 它允许系统像人类工程师一样：规划大纲 -> 决定是否需要网络搜索 -> 撰写初稿 -> 审查初稿中的逻辑漏洞 -> 结合审查结果继续修改<sup>12</sup>。
+
+<div class="article-quote">
+<strong>惊人的工程收益：</strong>这种工作流带来了巨大的性能提升。在 HumanEval 代码编写基准测试中，GPT-3.5 的零样本正确率仅为 48.1%，GPT-4 为 67.0%；但是，如果将较弱的 GPT-3.5 放入 Agentic 迭代循环中，其正确率飙升至 95.1%<sup>13</sup>。
+</div>
+
+## 二、Agent 的底层架构与运行机制
+
+要理解 Agent 的底层架构，我们得先抛弃"它只是个聊天机器人"这个视角，把它当成一台<span class="highlight-text">基于自然语言指令运行的新型计算机</span>。
+
+### 2.1 宏观架构：大语言模型操作系统（LLM OS）
+
+前特斯拉 AI 总监 Andrej Karpathy 提出了理解 Agent 架构的最佳抽象模型：**LLM OS（大语言模型操作系统）**。在这个架构中：
+
+| 组件 | 对应关系 | 功能描述 |
+|------|----------|----------|
+| CPU（处理器） | 大语言模型（LLM） | 负责处理输入、执行逻辑推理、以及发出指令 |
+| RAM（内存 / 工作记忆） | 模型的**上下文窗口（Context Window）** 和 KV Cache | 短期工作记忆，任何在当前执行步骤中需要被 LLM 直接读取的信息，都必须被塞进这个窗口里 |
+| 外存（硬盘 / 长期记忆） | 外部的**向量数据库（Vector Database，如 Pinecone）** 甚至传统关系型数据库 | 由于 LLM 每次调用完成后会"失忆"（无状态），历史数据必须持久化在这里 |
+| 外设与执行器（Tools） | 代码沙箱（Code Sandbox）、文件系统读写权限、浏览器 API | 相当于计算机的网卡、显卡或机械臂 |
+
+{% asset_img llm-os-architecture.png LLM OS 架构示意图：展示 Agent 作为新型计算机的核心组件及其交互关系 %}
+
+### 2.2 核心模块拆解（以经典 Agent 为例）
+
+如果剥开代码看，一个标准的自主运行 Agent（例如早期 BabyAGI 或现代框架的核心模块）通常由以下几个核心组件（Components）构成：
+
+#### 1. 大语言模型控制器（LLM Controller）
+
+这是整个系统的大脑。它接收系统提示词（System Prompt），明确当前的角色设定、可用工具列表以及输出格式（通常为 JSON），以此将自然语言转化为结构化的机器动作。
+
+#### 2. 记忆管理系统（Memory System）
+
+* **短期记忆：** 通常由开发框架（如 LangChain/LangGraph）维护当前的对话历史或近期几步的操作日志。
+* **长期记忆：** 当任务周期极长时，框架会将之前的操作结果转化为"向量嵌入（Embeddings）"，存入向量数据库。当 Agent 执行新任务时，系统会通过"语义搜索（Semantic Search）"提取最相关的历史经验，拼接进当前的上下文中供 LLM 读取。
+
+#### 3. 工具与环境接口（Tool Integrations / Harness）
+
+LangChain 创始人 Harrison Chase 强调，现代 Agent 的强大来源于强大的<span class="highlight-text">"脚手架（Harness）"</span>。这包括预置的工具函数。<span class="highlight-text">最核心的工具是文件系统（File System）访问权限</span>，因为它可以让 Agent 把长篇的中间结果写入文件，而不是全部塞进上下文里导致内存溢出。
+
+### 2.3 运行机制：死循环与状态机（The Loop & State Machine）
+
+Agent 并不是"一口气"运行完的，它的底层是一个**事件驱动的循环结构（Loop）**。在工程实现里，主流运行机制大致有两种：
+
+#### 机制 A：经典的"三节点"死循环（如 BabyAGI）
+
+BabyAGI 证明了只要三个 Python 脚本节点相互配合，就能让 Agent 无限期自主运转：
+
+1. **任务执行节点（Task Execution）：** 读取当前任务队列的第一个任务，结合向量数据库中的历史上下文，调用 LLM 执行任务，并保存结果。
+2. **任务创建节点（Task Creation）：** 观察上一步的执行结果，调用 LLM 判断"为了实现总目标，接下来还需要新增什么任务？"，并将新任务丢进队列。
+3. **任务优先级排序节点（Task Prioritization）：** 调用 LLM 对现有的任务队列重新排序，清理冗余，决定下一步最该做什么。 *这个循环（While Loop）会不断运转，直到任务列表清空或达到预设的终止条件。*
+
+#### 机制 B：现代的图与状态机架构（如 LangGraph）
+
+面对更复杂的企业级业务，简单的死循环难以控制。现代框架（如 LangGraph）将运行机制升级为**有向图（Graph）和状态机（State Machine）**：
+
+* **节点（Nodes）：** 代表具体的处理单元（可以是一个调用 LLM 的函数，也可以是执行 Python 代码的工具）。
+* **边（Edges）：** 包含条件判断逻辑（如 IF-ELSE）。基于当前节点返回的结果，决定数据流向下一个哪个节点。
+* **状态管理（State Management）：** 整个图共享一个全局状态（State）。每次循环都在更新这个全局状态，并自带**持久化（Persistence）**功能。这意味着当 Agent 运行到一半崩溃，或者遇到高风险操作需要"人类审批"时，程序可以暂停保存状态，之后再无缝恢复。
+
+### 2.4 底层工程的终极挑战：上下文工程（Context Engineering）与执行轨迹（Traces）
+
+当我们把上面这些模块拼起来后，运行逻辑会发生根本变化，这也是研发人员最需要适应的地方：
+
+* **逻辑不再只存在于代码中：** 传统软件的控制流（If-Else）写在代码里；但 Agent 的控制流很大一部分由 LLM 在运行时动态决定（具有不确定性）。  
+* **上下文工程（Context Engineering）决定成败：** 决定 Agent 表现的，是每次循环调用 LLM 时，你在这个循环点（通过检索或状态机）给它组装了什么上下文。如果塞入的信息太多，LLM 会忘记关键指令；如果太少，它会产生幻觉。  
+* **排错（Debug）依赖执行轨迹（Traces）：** 在传统开发中，出 Bug 了我们看代码；但在 Agent 开发中，当系统在第 14 步失败时，看代码毫无用处，因为你需要知道前 13 步它往上下文（Context）里塞了什么。因此，记录每一步提示词、输入和输出的**执行轨迹（Traces）** 取代了源代码，成为了 Agent 开发中测试和调试的“唯一真相来源”。
+
+
+## 三、驱动系统运转的核心：四大 Agentic 设计模式
+
+在底层循环与状态机之上，真正让 Agent 表现出"智能感"的，是吴恩达总结的<span class="highlight-text">四种核心 Agentic 设计模式（Design Patterns）</span><sup>24</sup>：
+
+### 1. 工具使用（Tool Use）
+
+赋予 LLM 网络搜索、代码执行等外部函数调用能力，以收集信息或处理数据<sup>24</sup>。
+
+### 2. 规划（Planning）
+
+面对复杂目标时，LLM 能够自主提出并执行一个多步计划<sup>24</sup>。
+
+### 3. 反思（Reflection / Self-Correction）
+
+强迫 LLM 检查自身的输出，发现缺陷并提出改进方案<sup>24</sup>。例如，在缓解模型幻觉的研究中，Chain-of-Verification (CoVe) 强制模型生成验证问题并自我审查，而 Self-Refine 则采用"生成 -> 反馈 -> 改进"的迭代框架扮演自我批评者的角色<sup>25, 26</sup>。
+
+### 4. 多智能体协作（Multi-agent Collaboration）
+
+实例化多个不同的 AI 角色，通过分担任务和相互辩论，得出比单一 Agent 更优的解决方案<sup>24</sup>。
+
+
+## 四、研发视角的范式转换：开发 Agent 与传统软件的区别
+
+LangChain 创始人 Harrison Chase 指出，构建 Agent 会显著改变传统软件工程的一些基本常识<sup>27</sup>。
+
+### 1. 逻辑存在于模型中（非确定性系统）
+
+传统软件的逻辑被硬编码（Hard-coded）在代码中，开发者可以确切知道程序的流向；而在 Agent 中，程序的控制流是由大模型在运行时基于上下文动态涌现的，具有高度的黑盒性和不确定性<sup>27, 28</sup>。
+
+### 2. "执行轨迹（Traces）"取代代码，成为 Debug 的唯一事实依据
+
+由于 Agent 在循环中反复运行，当系统在第 14 步报错时，单看代码无法推断前 13 步 LLM 的上下文窗口里到底装载了什么<sup>29</sup>。因此，详细记录每一步输入、输出、工具调用和状态变化的**执行轨迹（Traces）**，取代了源代码，成为了开发者测试、排错（Debug）和团队协作的核心工具<sup>27, 30, 31</sup>。
+
+### 3. "脚手架（Harness）"与"上下文工程（Context Engineering）"决定成败
+
+长周期 Agent（Long-Horizon Agents）的成败往往不仅仅取决于底层模型有多强大，更取决于开发者构建的 <span class="highlight-text">Harness（深度定制的脚手架体系）</span><sup>32, 33</sup>。这包括内置的规划工具、处理超长文本的压缩（Compaction）策略，以及至关重要的文件系统访问权限（File System Access）<sup>9, 33, 34</sup>。这一切本质上都是 <span class="gradient-text">"上下文工程（Context Engineering）"</span>——即在 Agent 循环的每一个特定步骤，精准地为其上下文窗口注入最需要的记忆、工具结果和指引<sup>32, 35, 36</sup>。
+
+
+## 五、生产环境落地的终极指南
+
+对于准备把 Agent 投入生产环境的研发团队，行业里有一个高度一致的共识：<span class="highlight-text">不要一上来就追求 100% 全自动（Fully Autonomous）</span>。
+
+### 1. 做好迎接"Agent的十年"的准备，它是一个"九的游行"
+
+Andrej Karpathy 强调，目前行业处于"Agent的十年（Decade of Agents）"，而非所谓的一年<sup>37</sup>。构建可靠的 Agent 与研发自动驾驶汽车极度相似：展示一个能解决 90% 问题的 Demo 非常容易，但要达到生产级别，需要经历漫长的"九的游行（March of nines，即追求 99.9% 到 99.99% 的极端可靠性）"<sup>38, 39</sup>。
+
+### 2. 定位为"初稿生成器（First Drafts）"
+
+现阶段长周期 Agent 最杀手级的应用场景，不是直接交付最终结果，而是生成一份极具价值的"初稿"<sup>40</sup>。无论是代码的 Pull Request、SRE 的日志诊断分析报告，还是客户支持的复杂调研，Agent 的作用是承担粗重的初期工作，然后交由人类审核与编辑<sup>40, 41</sup>。
+
+### 3. 保留"自主性滑块（Autonomy Slider）"
+
+在产品设计（如 Cursor 或 Perplexity）中，必须赋予用户控制权<sup>42-44</sup>。开发者可以选择只补全一行代码（Tap completion）、修改单个文件，或是让 Agent 放开手脚重构整个代码仓库，用户可以根据任务复杂度动态调整这种"自主性滑块"<sup>44, 45</sup>。
+
+### 4. 终极形态：环境智能体（Ambient Agents）与 智能体收件箱（Agent Inbox）
+
+传统的基于聊天（Chat-based）的 Agent 受限于极高的延迟要求和一对一的交互瓶颈<sup>46-48</sup>。未来的生产级落地形态将走向<span class="highlight-text">环境智能体（Ambient Agents）</span><sup>46, 49</sup>。
+
+* **事件驱动与异步执行：** Ambient Agents 在后台静默运行，监听并响应事件流（如新收到的客户邮件、代码库提交、系统报警等）<sup>46</sup>。由于没有即时聊天的延迟压力，它们可以执行包含数十次工具调用和复杂规划的深层任务<sup>48, 50</sup>。
+* **人类在环（Human-in-the-loop）与 Agent Inbox：** 这种异步、高并发的运行模式绝不意味着失控。相反，系统必须设计一个类似"智能体收件箱（Agent Inbox）"的交互界面<sup>51</sup>。Agent 将执行到一半的高风险操作或半成品报告推送到收件箱中，人类在此进行<span class="highlight-text">审批（Approve）、编辑修改（Edit）、解答 Agent 的疑问（Answer），甚至进行"时间旅行（Time Travel，即回滚到之前某一步重新运行）"</span><sup>52, 53</sup>。这不仅保证了业务的安全性，人类的纠错反馈也将作为记忆（Memory），驱动 Agent 系统的自我迭代与进化<sup>51, 54</sup>。
+
+---
+
+<div class="article-quote">
+<strong>总结：</strong>我们正在经历软件工程范式的一次关键转折。从"软件 1.0"的确定性代码，到"软件 2.0"的神经网络权重，再到"软件 3.0"的 LLM 驱动 Agent，每一次跃迁都在重新定义"编程"这件事。对研发人员来说，理解 Agent 的底层架构——LLM OS 的计算模型、四大设计模式、以及上下文工程的核心地位——会是未来十年非常关键的技术投入。
+</div>
+
+---
+
+
+### 核心参考文章
+
+**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)
+
+**2. Lilian Weng (OpenAI) —— LLM Agent 架构百科全书**
+* [LLM Powered Autonomous Agents](https://lilianweng.github.io/posts/2023-06-23-agent/)
+
+**3. Andrej Karpathy —— LLM OS 系统愿景**
+* [Intro to Large Language Models (视频)](https://www.youtube.com/watch?v=zjkBMFhNj_g)
+* [The "Loopy" Era of AI (Twitter/X)](https://twitter.com/karpathy/status/1723140519217836416)
+
+**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/)

source/_posts/从零到-RAG-系统：成功与失败.md

@@ -1,83 +0,0 @@
----
-title: 从零到 RAG 系统：成功与失败
-author: Gamehu
-date: 2026-03-28 15:59:29
-categories:
-  - 技术
-tags:
-  - RAG
-  - LLM
-  - 向量数据库
-  - 工程实践
----
-
-A few months ago I was tasked with creating an internal tool for the company's engineers: a Chat that used a local LLM. Nothing extraordinary so far. Then the requirements came in: it had to have a fast response, I insist... fast!, and... it also had to provide answers about every project the company has done throughout its entire history (almost a decade). They didn't want a traditional search engine, but a tool where you could ask questions in natural language and get answers with references to the original documents. With emphasis on providing information from OrcaFlex files (a simulation software for floating body dynamics, cables, etc., widely used in the offshore industry). It already seemed complex, but it was confirmed when I was given access to 1 TB of projects, mixed with technical documentation, reports, analyses, regulations, CSVs, etc. The emotional roller coaster had begun.
-
-I'll tell you upfront that it was neither a quick nor easy process, and that's why I'd like to share it. From the first attempts, mistakes, to the final architecture that ended up in production. I also want to highlight that I had never done anything similar before and didn't know how a RAG worked either.
-
-We'll go problem by problem, and the solution I applied to each one.
-
-## Problem 1: selecting the right technology
-
-The first step was to define the stack.
-
-I needed a local language model, without relying on external APIs, for confidentiality reasons. Ollama emerged as the most mature and easy-to-use option for running LLaMA models locally. I tried several embeddings, and nomic-embed-text offered good performance and quality for technical documents.
-
-Next was a RAG engine to orchestrate the document indexing process, embedding generation, vector database storage, and queries. Without it, no matter how fast the language model is, we couldn't retrieve relevant information from the documents. Think of it like a book's index: without it, you'd have to read the entire book to find the information you need. And with a good index, you can go straight to the right page. I'll call this process indexing for simplicity, although it's really a vectorization and indexing process.
-
-After some research, I found a mature open source framework called LlamaIndex.
-
-The language I'd use would be Python, I could list many reasons, but the most important one is that I feel comfortable and productive with it. Additionally, both Ollama and LlamaIndex have excellent Python SDKs.
-
-I was ready to start building the software. I wrote my first scripts to run vector tests on the RAG system and do some query experiments. It worked really well with very little code. I thought it would be a project of a few weeks. I couldn't have been more wrong.
-
-The next step was working with the actual documents. Hold on tight, it's going to be a bumpy ride!
-
-## Problem 2: the document chaos
-
-My file source was a folder on Azure with a massive amount of technical documents: hundreds of gigabytes, thousands of files, various formats, with no organization or structure beyond the folder hierarchy. Every data engineer's dream (note the irony).
-
-I cracked my knuckles, set the RAG output to save to disk, and launched my first script. LlamaIndex ended up overflowing my laptop's RAM within minutes, choking my OS until everything froze. I tried many configurations, caching systems, and other strategies, but at some point my machine always died.
-
-After debugging, I discovered it was processing huge files that contributed nothing: videos, simulations, backup files... Documents that added nothing to a RAG system, but that LlamaIndex tried to process as if they were text. If a file weighed several gigabytes, the system tried to load it entirely into memory for processing, which was suicide.
-
-I added a filtering system to the pipeline that excluded files by extension and by name patterns (simulation files, numerical results, etc.).
-
-| Category | Excluded extensions |
-|----------|---------------------|
-| Video | mp4, avi, mov, mkv, wmv, flv, webm, m4v, mpg, mpeg, 3gp, mts... |
-| Images | jpg, jpeg, png, gif, bmp, tiff, svg, ico, webp, heic, psd... |
-| Executables | exe, dll, msi, bat, sh, app, dmg, so, jar... |
-| Compressed | zip, rar, 7z, tar, gz, bz2, xz |
-| Simulation | sim, dat |
-| Temporary | tmp, temp, cache, log, swp, pyc, crdownload, partial... |
-| Backups | bak, 3dmbak, dwgbak, dxfbak, pdfbak, stlbak, old, bkp, original... |
-| Email | msg, pst, eml, oft |
-
-I also removed files that were expensive to process and didn't add value either, like CSVs, JSONs, among others. On the other hand, I converted PDF, DOCX, XLSX, PPTX, etc. files to plain text so LlamaIndex could process them without issues.
-
-The result was a 54% reduction in the number of files to index. And of course, my RAM stopped exploding.
-
-I could finally start indexing without fear.
-
-## Problem 3: indexing 451GB of documents without dying in the attempt
-
-A RAG involves creating a vector index file containing document embeddings. Vectors are numerical representations of documents that allow measuring their similarity. LlamaIndex has a simple system you can configure with a couple of lines. You just point it to the directory and it takes care of storing all the information inside in JSON format. It's really convenient, works well, unless you're dealing with hundreds of gigabytes of documents. The system became unmanageable: every time the service restarted, it had to reprocess all documents from scratch, which could take days. Also, the default format is not optimal for large searches (JSON).
-
-I added a checkpoint system to save indexing progress. Every time a problem occurred, I wouldn't lose all progress, but could resume from the last processed file. However, data got corrupted, it was error-prone, and very slow. I was facing a bottleneck I couldn't overcome.
-
-After many trials and errors, and reading more about it, I decided to make the leap to a dedicated vector database: ChromaDB. An open-source database (Apache-2.0 license) for storing and querying vectors. Not to be confused with the Chrome/Chromium browser. ChromaDB is an abstraction layer that stores on top of a traditional database, I configured SQLite, and offers specific functionalities like similarity searches, clustering, etc.
-
-The change was radical and instant. Indexing went from being a monolithic process that loaded everything into memory to a batch pipeline that processed 150 files at a time, generated their embeddings, and stored them directly in ChromaDB. This allowed indexing the 451GB of documents across multiple sessions, with checkpoints, without losing progress on interruptions, without corrupted data. Additionally, it was really easy to back up and restore the index in case of failures (just copy the SQLite file).
-
-The system was ready. With a quick benchmark, I discovered I would need several months to index all the content with my laptop. Now the bottleneck was neither the RAM, nor the indexing system, nor the files, but the GPU.
-
-## Problem 4: my graphics card is not a rocket
-
-My laptop has an integrated graphics card. Processing 500 MB of documents by CPU takes 4-5 hours, not good numbers. I absolutely needed a powerful GPU. In a follow-up meeting, it was decided to rent me a virtual machine with an NVIDIA RTX 4000 SFF Ada, which has 20GB of VRAM. These kinds of rentals are not exactly cheap. Now I was working under more pressure.
-
-I modified my containers and the system was optimized to take advantage of the GPU. I launched my script. After several weeks, between 2 and 3, the indexing process finished without failures. 738,470 vectors, 54GB of index in ChromaDB, and a RAG system ready to answer questions. I copied the ChromaDB database, a SQLite file, to my local machine and that was it. To the relief of my Sysadmin and Project Manager, we could finally shut down the virtual machine. The cost was 184 euros on Hetzner, not cheap.
-
-It was time to build the backend and frontend.
-
-##

source/_posts/工作.md

@@ -25,7 +25,6 @@ tags: 求职
 Gamehu
 
 联系方式：
-电话：18515068121
 邮箱：gamehu@yeah.net
 Wechat：GamehuDB
 Twitter：https://x.com/Gamehu520
@@ -55,7 +54,6 @@ Code regards,
 Gamehu
 
 Contact:
-Phone: 18515068121
 Email: gamehu@yeah.net
 WeChat: GamehuDB
 Twitter: https://x.com/Gamehu520

source/_posts/慢下来：关于-AI-Agent-编程的反思.md

@@ -1,112 +0,0 @@
----
-title: 慢下来：关于 AI Agent 编程的反思
-author: Gamehu
-date: 2026-03-27 04:06:34
-categories:
-  - 思考
-tags:
-  - AI
-  - Agent
-  - 编程哲学
-  - 软件工程
----
-
-Mario Zechner（libGDX 作者）最新文章《Thoughts on slowing the fuck down》对当前 AI Agent 编程热潮提出了尖锐反思。文章指出：**我们正用 Agent 以惊人的速度给自己挖坑**。
-
-## 现状：一切都在崩坏
-
-作者观察到，软件质量正在加速下滑：
-- 98% 正常运行时间成为常态（而非例外）
-- 用户界面出现最奇怪的 bug
-- AWS 被曝 AI 导致故障，随后发布 90 天整改令
-- Windows 质量下滑，微软官方承认并承诺改进
-
-**核心问题**：声称 100% 代码由 AI 生成的公司，持续产出质量最差的产品。
-
----
-
-## 错误的工作方式
-
-### 1. 复合错误（Compounding Booboos）
-
-**人类 vs Agent 的关键差异：**
-
-| 人类 | Agent |
-|------|-------|
-| 犯错几次后学会不再犯 | 持续重复相同错误 |
-| 是瓶颈，每天只能引入有限错误 | 无瓶颈，几小时生成 2 万行代码 |
-| 痛苦到达阈值会修复 | 无痛感，直到为时已晚 |
-
-**结果**：无害的小错误以不可持续的速度复合，形成代码库怪物。
-
-### 2. 习得性复杂性的商人
-
-Agent 是"复杂性商人"：
-- 训练数据中见过大量糟糕的架构决策
-- 被委托架构应用，结果就是 immense complexity
-- 决策永远是局部的，导致代码重复、抽象过度
-
-**惊人对比**：人类企业代码库需要数年才能达到的复杂度，2 人团队 + Agent 几周内就能达成。
-
-### 3. Agentic 搜索召回率低
-
-当代码库膨胀后，Agent 无法找到所有需要修改的代码：
-- 无论是 ripgrep、LSP 还是向量数据库
-- 代码库越大，召回率越低
-- 导致重复代码、不一致性，最终绽放为"美丽的屎花"
-
----
-
-## 正确的工作方式（作者建议）
-
-### 适合 Agent 的任务
-
-好的 Agent 任务具备以下特征：
-- ✅ 范围可限定，无需理解完整系统
-- ✅ 可闭环评估（有明确的评估函数）
-- ✅ 非关键任务（内部工具、原型）
-- ✅ 人类是最终质量关卡
-
-**反例**：Karpathy 的 auto-research 用于优化启动时间？很好！但产出的代码绝非生产就绪——评估函数只捕获狭窄指标，忽略代码质量、复杂度、正确性。
-
-### 核心建议：慢下来
-
-> "Slowing the fuck down is the way to go."
-
-**具体做法：**
-
-1. **给自己时间思考** —— 真正在构建什么、为什么
-2. **设定代码生成上限** —— 与代码审查能力匹配
-3. **手写架构定义** —— API、系统整体结构亲手写
-4. **与 Agent 结对编程** —— 而非完全委托
-5. **保持在场** —— 看到代码逐步构建，理解系统"感觉"
-
-**为什么**：
-- 摩擦让你更好理解想构建什么
-- 经验和品味在此发挥作用（当前 SOTA 模型无法替代）
-- 慢下来才能学习和成长
-
-### 最终收益
-
-- 系统和代码库保持可维护性
-- 产品带来愉悦而非 slop
-- 构建更少但正确的功能
-- 学会说"不"本身就是功能
-- 理解系统，保持 agency
-- 能修复问题，能重构优化
-
----
-
-## 关键金句
-
-> "Coding agents are sirens, luring you in with their speed of code generation and jagged intelligence."
-
-> "Your agents never see each other's runs, never get to see all of your codebase... an agent's decisions are always local."
-
-> "All of this requires discipline and agency. All of this requires humans."
-
----
-
-**原文**：https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/
-
-**作者**：Mario Zechner（libGDX 创始人）

source/resume/en.md

@@ -1,5 +1,5 @@
 ---
-title: Huantao Hu - Resume
+title: Gamehu - Resume
 date: 2025-02-22 19:31:46
 type: resume
 comments: false
@@ -9,10 +9,9 @@ comments: false
 
 | | |
 |---|---|
-| **Name** | Huantao Hu |
+| **Name** | Gamehu |
 | **Experience** | 13 years |
-| **Email** | gamehu@yeah.net |
-| **Phone** | +86 18515068121 |
+| **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 |
 

source/resume/index.md

@@ -1,5 +1,5 @@
 ---
-title: 扈焕涛 - 简历
+title: 简历
 date: 2025-02-22 19:31:46
 type: resume
 comments: false
@@ -9,10 +9,9 @@ comments: false
 
 | | |
 |---|---|
-| **姓名** | 扈焕涛 |
+| **姓名** | Gamehu |
 | **工作年限** | 13年 |
-| **邮箱** | gamehu@yeah.net |
-| **电话** | 18515068121 |
+| **邮箱** | <gamehu@yeah.net> |
 | **博客/公众号** | [gamehu.run](https://gamehu.run) / Gamehu |
 | **学历** | 本科 · 重庆科技大学 · 计算机科学与技术 |