<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>KLucenの启示录</title>
  
  
  <link href="https://www.klucen.cn/atom.xml" rel="self"/>
  
  <link href="https://www.klucen.cn/"/>
  <updated>2026-09-18T15:26:31.253Z</updated>
  <id>https://www.klucen.cn/</id>
  
  <author>
    <name>KLucen</name>
    
  </author>
  
  <generator uri="https://hexo.io/">Hexo</generator>
  
  <entry>
    <title>用 Agent 陪读《深入理解 AI Agent》：笔记仓库开源了</title>
    <link href="https://www.klucen.cn/posts/640296d4.html"/>
    <id>https://www.klucen.cn/posts/640296d4.html</id>
    <published>2026-09-11T15:50:00.000Z</published>
    <updated>2026-09-18T15:26:31.253Z</updated>
    
    <content type="html"><![CDATA[<p>上个月我发过一篇 <a href="https://klucen.cn/posts/66321874.html">《深入理解 AI Agent：设计原理与工程实践》章节精读笔记</a>。那篇是想给”想快速了解 Agent 到底在讲什么”的人一份简单的总结性文档，看完能知道这本书大致说了什么。但也仅此而已。</p><p>而这次开源的仓库是另一种东西。它的用法不是”替你把书读了”，而是<strong>让你带着问题去读原文</strong>：</p><blockquote><p><strong><a href="https://github.com/KLucen/ai-agent-book-note">KLucen/ai-agent-book-note</a></strong>（Apache-2.0）</p></blockquote><p>具体怎么用：<code>内容精读/</code> 里每个小节的开头都有一组从正文里长出来的引导问题，先看问题，再去读原书对应段落，读完回来对照”读后小结”和”原文论证”。读的时候有想法、有疑问，就写进 <code>QuickNote/</code>。<strong>你也可以先看看我在里面随手记下的感悟和不明白的地方，再翻到 <code>DeepReadNote/</code>，看这些答案是不是对你也一样有帮助。</strong></p><p>原书是 <a href="https://github.com/bojieli/ai-agent-book">bojieli/ai-agent-book</a>，李博杰著，正文、编译版 PDF、每章配套代码全部开源（Apache-2.0）。我这份是<strong>非官方</strong>的个人精读笔记，不打算当原书的替代品或者翻译，它更像一份”这本书我到底是怎么读的”的完整记录。</p><h2 id="里面有什么"><a href="#里面有什么" class="headerlink" title="里面有什么"></a>里面有什么</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br></pre></td><td class="code"><pre><span class="line">Agent Book/</span><br><span class="line">├─ 00-阅读地图.md      全书导航：核心公式、阅读路径、进度总表</span><br><span class="line">├─ 01-精读笔记规范.md  模板与写作纪律（想复用这套方法看这份）</span><br><span class="line">├─ 02-全书术语表.md    跨章术语总表，每个术语只在首见章给权威定义</span><br><span class="line">├─ images/             原书插图副本，供笔记引用</span><br><span class="line">├─ 内容精读/           每章&quot;读&quot;：逐节深析</span><br><span class="line">├─ 实验解读/           每章&quot;做&quot;：实验逐条解读 + 动手记录区</span><br><span class="line">├─ 思考题引导/         每章&quot;考&quot;：题目原文 + 提示思路 + 自答留白</span><br><span class="line">├─ QuickNote/          我自己写的读书随笔，原始记录</span><br><span class="line">└─ DeepReadNote/       AI 对我的随笔的回应与补充</span><br></pre></td></tr></table></figure><p>三个分册对应三种读法：<strong>读</strong>原书、<strong>做</strong>实验、<strong>考</strong>自己。</p><p><code>内容精读/</code> 里每个小节都是同一个四段式，这是我用得最顺的部分：</p><ol><li><strong>带着这些问题阅读本节</strong>——问题是从该小节正文里长出来的，不是通用模板；</li><li><strong>读后小结</strong>——结论层，要覆盖该节全部要点，不写空话；</li><li><strong>原文论证</strong>——原书证据，逐字引用并给出处锚点；</li><li><strong>取舍与延伸</strong>——工程取舍、跨章关联。</li></ol><p><code>实验解读/</code> 每个实验给「目的 / 设计 / 关键结论」，后面留一张<strong>动手记录区</strong>的空白表，等我复现完自己填。<code>思考题引导/</code> 只给提示思路、不剧透答案，答案在原书的 <code>reference-answers.md</code> 里，先自答再看。</p><h2 id="为什么我推荐从「问题引导」读起"><a href="#为什么我推荐从「问题引导」读起" class="headerlink" title="为什么我推荐从「问题引导」读起"></a>为什么我推荐从「问题引导」读起</h2><p>这份笔记里我最想推的用法，就是先看 <code>内容精读/</code> 里那组引导问题，带着它们去读原书。</p><p>说实话一开始agent提的问题真的很差，因为在规范文档里面我也做了几次的修改，包括：</p><ul><li><strong>引导问题规则</strong>：必须源自该小节正文实际展开的内容，正文没强调的点不许问；读完该小节应能直接回答并覆盖要点</li><li><strong>小结深度规则</strong>：「读后小结」须按原文充实——保留关键定义、分类对比、机制/流程链、书中数字与案例，原则是「不看原文也能从小结复述该节内容」</li></ul><p>在现在这个规范下，我觉得阅读体验很不错了。大部分问题确实能把我按在”带着脑子读”的状态里，而不是眼睛扫过去、脑子没跟上；读完之后它给的小结也有分寸，该有的定义、对比、数字和案例都在，不至于浅到只剩一句正确的废话。</p><p>另一个我回过神来才觉得有用的设计：<strong>笔记里引用到的原书图都留了一份副本，每张图下面还配了一句基于原文的解读</strong>。不然过几个月再回来翻，看到个 <code>fig2-3</code> 只会想”这图当初是想说明啥来着”。</p><h2 id="我最想推荐的是-QuickNote-和-DeepReadNote"><a href="#我最想推荐的是-QuickNote-和-DeepReadNote" class="headerlink" title="我最想推荐的是 QuickNote 和 DeepReadNote"></a>我最想推荐的是 QuickNote 和 DeepReadNote</h2><p>读书的损耗主要发生在两处：读的时候没有焦点，读完没有反馈。引导问题管前一个，DeepReadNote 管后一个。</p><p>第 1 章读完，我随手在 <code>QuickNote/Quick_note_1.md</code> 里记了六七条：想补一下 RL 到底是什么、SDK 和 API 到底怎么区分、怀疑”模型即 Agent”和”Harness 更关键”是不是自相矛盾、希望有人把贯穿全书的设计模式再讲一遍。写得十分随便，就是卡住的地方随手记。</p><p>然后 AI 写了一份 <a href="https://github.com/KLucen/ai-agent-book-note/tree/main/DeepReadNote">DeepReadNote</a>，逐条回应。举几个它真的说到点上的地方：</p><ul><li><strong>RL 的定位</strong>：先讲清状态/动作/奖励/策略这一套，再回到书里那张控制论视角的 Agent↔Environment 闭环图。它还告诉我这个知识缺口不用现在补，第 8 章有两节可选阅读正好讲这个，到时候按需读更省力；</li><li><strong>Harness 的边界</strong>：我本来把它理解成”生产系统的完整治理层”。它指出更准确的说法是”Agent 边界内、模型之外”，而且书里的<strong>五要素（功能职责）和三层护栏（安全纵深）不是同一套划分</strong>，把两张图对齐时最容易在这踩坑；</li><li><strong>五条设计模式</strong>给了个口诀：<strong>分离、按需、只增、双侧、小步</strong>（提议者-审核者 / 渐进式披露 / 只增不改 / 边界集+保留集 / 最小 diff+可回滚）。</li></ul><p>这大概是整份笔记里最像”讨论区”的部分：我的原始笔记一个字没改，回应放在隔壁文件，对错都摊开。</p><h2 id="我给-AI-定的几条规矩"><a href="#我给-AI-定的几条规矩" class="headerlink" title="我给 AI 定的几条规矩"></a>我给 AI 定的几条规矩</h2><p>人机协作最容易出问题的地方，是最后分不清哪句话是书里说的、哪句是 AI 自己发挥的。所以：</p><ol><li><strong>三层标注</strong>：<code>〔原书〕</code> 书中内容 / <code>〔补充〕</code> 书外知识 / <code>〔精读批注〕</code> AI 或读者的判断；</li><li><strong>引用逐字核验 + 给出处锚点</strong>。原书是 Markdown，没有页码，一律用「章 + 小节标题」定位，<strong>不许编造页码</strong>；</li><li><strong>QuickNote 是我的原文，AI 只读不改</strong>；”我的批注”留白区 AI 不许填；</li><li><strong>思考题提示不许泄露参考答案</strong>；</li><li>若我的理解和书中结论冲突，要明确指认并给证据，不许含糊调和。</li></ol><p>第五条是我特意加的。顺着人说的 AI 没什么用，我要的是它能说”你这条偏了，原文是这么写的”。</p><p>这些纪律本身也写在仓库里（<code>01-精读笔记规范.md</code>，现在 v2.2），想拿去写自己的精读笔记，模板可以直接抄。AI 这一侧用的是 DeepSeek Harness，也就是我现在写博客、写插件用的同一套东西。</p><h2 id="一些值得注意的事情"><a href="#一些值得注意的事情" class="headerlink" title="一些值得注意的事情"></a>一些值得注意的事情</h2><ul><li><strong>第 1、2 章已精读完成</strong>，第 1 章的 DeepReadNote 也有；<strong>第 3–10 章只有骨架</strong>，里面是各章主旨与大纲预览，还没填。</li><li>进度确实慢。一章要产出三份分册，还得真去跑实验，快不起来。好在笔记是否完整其实不重要，疑问有没有被追到闭环才重要。</li><li><strong>原生是 Obsidian 笔记</strong>，在 GitHub 上会有几处不完美：<code>[[内部链接]]</code> 点不动（得从 README 的进度表进各章）、<code>&gt; [!info]</code> 提示框变成普通引用块、文件头的 frontmatter 渲染成一张表。想要完整体验就 clone 下来，把 <code>Agent Book/</code> 当 Obsidian 库的根目录。</li><li>图片是原书插图的副本（版权归原作者，依 Apache-2.0 保留署名）；笔记本体也是 Apache-2.0。</li></ul><h2 id="尾巴"><a href="#尾巴" class="headerlink" title="尾巴"></a>尾巴</h2><p>仓库地址：<a href="https://github.com/KLucen/ai-agent-book-note"><strong>KLucen/ai-agent-book-note</strong></a>。</p><p>笔记里的错误、不同理解、补充建议都欢迎开 issue 讨论；如果问题出在书本身，建议提到<a href="https://github.com/bojieli/ai-agent-book/issues">原书仓库</a>。</p><p>接下来该轮到第 3 章「用户记忆和知识库」了……希望下一篇不是三个月后 🫠</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;上个月我发过一篇 &lt;a href=&quot;https://klucen.cn/posts/66321874.html&quot;&gt;《深入理解 AI Agent：设计原理与工程实践》章节精读笔记&lt;/a&gt;。那篇是想给”想快速了解 Agent 到底在讲什么”的人一份简单的总结性文档，看完能知道这</summary>
      
    
    
    
    <category term="学习" scheme="https://www.klucen.cn/categories/%E5%AD%A6%E4%B9%A0/"/>
    
    
    <category term="AI Agent" scheme="https://www.klucen.cn/tags/AI-Agent/"/>
    
    <category term="精读笔记" scheme="https://www.klucen.cn/tags/%E7%B2%BE%E8%AF%BB%E7%AC%94%E8%AE%B0/"/>
    
    <category term="笔记分享" scheme="https://www.klucen.cn/tags/%E7%AC%94%E8%AE%B0%E5%88%86%E4%BA%AB/"/>
    
    <category term="Obsidian" scheme="https://www.klucen.cn/tags/Obsidian/"/>
    
    <category term="DeepSeek Harness" scheme="https://www.klucen.cn/tags/DeepSeek-Harness/"/>
    
  </entry>
  
  <entry>
    <title>dsh web 快捷启动插件 v0.2：一键重启、失败诊断，和「绝不打断回答」</title>
    <link href="https://www.klucen.cn/posts/7e01b64d.html"/>
    <id>https://www.klucen.cn/posts/7e01b64d.html</id>
    <published>2026-09-10T11:45:00.000Z</published>
    <updated>2026-09-10T11:43:17.774Z</updated>
    
    <content type="html"><![CDATA[<p>上一篇给 <code>dsh web</code> 写了桌面快捷启动插件 <a href="https://github.com/KLucen/dsh-desktop_quick_launcher">dsh-desktop_quick_launcher</a>。发出来之后自己天天在用，用着用着就发现：「能用」和「敢用」之间还差着一大截。于是从 v0.1.1 一路迭代到了 <strong>v0.2.7</strong>，这篇记录一下中间加了什么。</p><p>一句话版本：桌面图标还在，但插件现在管的是<strong>启动 / 重启 / 退出</strong>三件事，而且<strong>在任何情况下都不会切断正在生成的回答</strong>。</p><h2 id="最想先说的：绝不打断正在生成的回答"><a href="#最想先说的：绝不打断正在生成的回答" class="headerlink" title="最想先说的：绝不打断正在生成的回答"></a>最想先说的：绝不打断正在生成的回答</h2><p>装插件、升 DSH 核心、重打补丁，都要重启 <code>dsh web</code>。而一个「朴素」的重启按钮是很危险的：你正在等模型写完一段代码，手一滑点了重启，回答就没了。</p><p>所以 v0.2 里，「重启」和「停止」都先过一道门：</p><ul><li><strong>未结束的回合会阻断操作。</strong> 宿主读取 live session，套用 <code>@deepseek-ai/dsh-session</code> 自己的开放回合判据（由最后一个 <code>turn/start</code> / <code>turn/end</code> 边界决定），返回 <code>409 busy</code> 并列出相关会话。</li><li>界面上的处理比报错友好：<strong>生成期间按钮直接禁用</strong>，并提供一个「<strong>等空闲后自动重启</strong>」（客户端队列，上限 10 分钟，可取消）。</li><li>就算你排了队，<strong>退出前宿主还会再查一次</strong>：如果这时刚好有新回答开始，重启会被记为 <code>aborted-busy</code> 并<strong>取消</strong>，页面提示「已取消：检测到新开始的回答」。</li><li>逃生口是刻意留的：万一某个回合永久卡死，硬阻断会让重启按钮彻底失效。所以保留了 <code>force: true</code>，但只能通过<strong>二次、措辞明确</strong>的确认触达（「强制：会中断正在生成的回答」），并且会在重启报告里记上 <code>forced: true</code>。</li></ul><h2 id="重启这件事，是怎么才走通的"><a href="#重启这件事，是怎么才走通的" class="headerlink" title="重启这件事，是怎么才走通的"></a>重启这件事，是怎么才走通的</h2><p>这部分是 v0.2 里最折腾的：让一个进程「自杀后重生」，在 Windows 上比想象中难。</p><p>第一版的思路很自然：宿主 spawn 一个 detached 子进程，让它等宿主退出后拉起新实例。<strong>实测直接死</strong> —— 在 Windows 上，这个子进程会在<strong>执行任何一条语句之前</strong>就随宿主的进程树被杀掉，一行代码都跑不到。</p><p>现在的方案是<strong>计划任务</strong>：</p><ul><li>宿主把重启助手作为计划任务启动，它的进程属于<strong>任务计划服务</strong>，宿主自己的清理动不到它；</li><li>但宿主不会「启动完就放心去死」：它会<strong>等助手把共享状态文件推进到 <code>handoff</code></strong> 之后，才回响应并退出；</li><li>如果助手始终没报到，重启会被<strong>取消、服务继续运行</strong> —— 重启机制坏掉，不再等于服务变死。这一点很重要。</li></ul><p>助手里还有几个必须显式处理的细节：</p><ul><li>计划任务的启动目录是 <code>%SystemRoot%\System32</code>，而且<strong>没有 <code>DSH_HOME</code></strong>，两个都得显式还原，否则新实例会找不到自己的家；</li><li>助手<strong>绝不使用 <code>taskkill /T</code></strong>：它自己是旧宿主的子孙进程，<code>/T</code> 会把它自己一起杀掉；</li><li>助手从捕获的 stdout 里解析新实例的 <code>dsh web: http://…/?token=…</code> 一行，留作浏览器 cookie 失效时的兜底。</li></ul><p>那<strong>页面为什么能自己回来</strong>？因为浏览器会话 cookie 的签名密钥持久化在 <code>$DSH_HOME/.credentials.yaml</code>（默认 30 天），<strong>能跨重启存活</strong>；客户端等 <code>/ping</code> 返回一个和重启前<strong>不同</strong>的 <code>instanceId</code>，然后重新加载原 URL。另外，同时只允许一次重启 —— inflight 标记让第二次请求拿到 <code>409 restart-inflight</code>，双击出的两个标签页不会起两个助手。</p><h2 id="出问题时，别再让人猜"><a href="#出问题时，别再让人猜" class="headerlink" title="出问题时，别再让人猜"></a>出问题时，别再让人猜</h2><p>v0.1 时代最难受的是：图标双击了、服务没起来，然后<strong>什么信息都没有</strong>。v0.2 在诊断上做了三件事：</p><p><strong>① 分级探针，把「没起来」拆成四种各有结论的状态。</strong> 顺序是：TCP 连接 → 插件 <code>/ping</code>（确认是本插件，拿到 instanceId）→ <code>GET /</code> 指纹（<code>dsh web authentication required</code>）→ 外来服务。于是「DSH 已在运行 / 端口被别的程序占用 / 端口有人监听但从不响应（僵死实例）/ 端口空闲」是可以区分的。只要端口不是<strong>空闲</strong>，就是一条<strong>诊断</strong>而不是一次启动尝试：启动器会报告占用者的 PID 和进程名，然后停下。</p><p><strong>② 捕获子进程输出。</strong> v0.1 用 <code>-WindowStyle Hidden</code> 把 stdout/stderr 全丢了，失败了只看到一个「代码 1」。现在它们写进 <code>dsh-child.out.log</code> / <code>dsh-child.err.log</code>，<strong>末尾 15 行</strong>同时进入桌面消息框和报告 —— 通常这就是全部答案。</p><p><strong>③ 机器可读的状态文件。</strong> 每次运行都会<strong>原子写</strong>（临时文件 + 改名，UTF-8 <strong>无 BOM</strong>）<code>launcher-status.json</code>，重启写 <code>restart-status.json</code>；<strong>九类失败结论</strong>各自带下一步建议；GUI 会在页面加载时把上次启动失败<strong>提示一次</strong>（一次性横幅），你不必先知道「有日志文件这回事」。</p><p>顺带一提，并发也处理了：<strong>命名互斥量</strong>会串行化同时来的调用 —— 连点三次图标，不会再让三个启动器去抢 3080，多出来的调用转为等待。</p><h2 id="面板和设置卡片"><a href="#面板和设置卡片" class="headerlink" title="面板和设置卡片"></a>面板和设置卡片</h2><p>右下角的悬浮件现在是一组：<strong>桌面图标/详情、停止、重启</strong>。</p><ul><li><strong>详情</strong>弹出面板：实例信息（PID、端口、运行时长、版本）、当前生成状态、上次启动报告、上次重启报告、抓到的子进程输出尾部。</li><li>插件还在<strong>设置</strong>里贡献了自己的一页（<code>settings.section</code> 槽位，和其它插件页并列）：<ul><li><strong>悬浮按钮</strong>：三个按钮各有独立开关，可以只留一部分，也可以全部隐藏（全关掉右下角就干干净净）；</li><li><strong>日志与状态文件</strong>：列出各个 log / 状态文件的大小与修改时间，支持<strong>查看</strong>（末尾）、<strong>清空</strong>（单个或全部）、<strong>刷新</strong>、<strong>打开目录</strong>。状态文件是<strong>删除</strong>而不是清空，这样面板显示的是「暂无记录」而不是解析错误；</li><li>这些路由只接受<strong>白名单里的名字</strong>（绝不接受调用方传来的路径），写操作需要 nonce。</li></ul></li></ul><h2 id="几个「事后想起来很关键」的修复"><a href="#几个「事后想起来很关键」的修复" class="headerlink" title="几个「事后想起来很关键」的修复"></a>几个「事后想起来很关键」的修复</h2><ol><li><strong>v0.2.3：快捷方式开的是裸地址，首次打开必然要求认证。</strong> 以前打开 <code>http://127.0.0.1:3080</code>，浏览器没有 cookie 时 DSH 会返回 <code>dsh web authentication required</code>。现在启动器会解析<strong>带 token 的 URL</strong>（优先 <code>/ping</code> 公布的 <code>authUrl</code>，缓存在 <code>auth-url.txt</code>；其次是自己启动子进程时捕获的那一行），首次加载就是已认证状态。</li><li><strong>v0.2.4：把 <code>/ping</code> 的 200 当成了「就绪」。</strong> 可那时 SPA 兜底还没注册好，浏览器打开就是 <code>HTTP ERROR 404</code>。现在的启动器有<strong>就绪门</strong>（<code>Test-GuiReady</code>）和 <code>starting</code> 阶段 —— 只等待、不重复起实例；顺带在 DSH 模态框打开时把悬浮件藏起来。</li><li><strong>v0.2.5：启动器脚本「永远不更新」。</strong> 快捷方式跑的一直是「创建图标那一刻」写下的脚本 —— 也就是说前面两个版本的启动器修复<strong>从未真正生效过</strong>。现在宿主每次启动都会<strong>幂等重写</strong>已有的 <code>launcher.ps1</code>（不创建图标），升级即生效；只有快捷方式被删掉这种情况才需要点一下重建（v0.2.6 加了「一键重建桌面快捷方式」，并在 <code>/status</code> 里暴露 <code>shortcut &#123; name, path, exists &#125;</code>）。</li><li><strong>v0.2.7：别把「版本错位」报成「快捷方式不存在」。</strong> 客户端 bundle 是从磁盘实时加载的，会先于宿主更新，于是旧宿主缺的字段被误报成「快捷方式没了」。现在会<strong>显式报告客户端/宿主版本错位</strong>并提示重启，字段缺失时显示「无法确认」而不是「不存在」。</li></ol><h2 id="接口和配置"><a href="#接口和配置" class="headerlink" title="接口和配置"></a>接口和配置</h2><p>给想自己接一下的人。路由一共这几条（完整前缀是 <code>/api/dsh-desktop_quick_launcher/…</code>，状态变更类需要 nonce）：</p><div class="table-container"><table><thead><tr><th>路由</th><th>方法</th><th>用途</th></tr></thead><tbody><tr><td><code>/ping</code></td><td>GET</td><td>实例 id、nonce、pid、端口、运行时长</td></tr><tr><td><code>/status</code></td><td>GET</td><td>实例 + <code>busy</code> + 上次启动/重启报告 + 日志路径</td></tr><tr><td><code>/create</code></td><td>POST</td><td>写启动脚本 + 桌面图标</td></tr><tr><td><code>/restart</code></td><td>POST</td><td>移交给独立助手后退出</td></tr><tr><td><code>/shutdown</code></td><td>POST</td><td>优雅退出</td></tr><tr><td><code>/logs</code>、<code>/logs/clear</code>、<code>/logs/open</code></td><td>GET/POST</td><td>日志与状态文件</td></tr><tr><td><code>/options</code></td><td>POST</td><td>写入面板开关</td></tr></tbody></table></div><p>安全上，所有路由<strong>仅限回环</strong>（socket 地址 + Host 头 + <code>sec-fetch-site</code> + Origin）—— 这挺重要，因为 DSH 的插件路由在浏览器登录门<strong>之外</strong>；另外所有状态变更路由都要求一个由 <code>GET /ping</code> 下发的<strong>每实例 nonce</strong>（放在 <code>x-dsh-ql-nonce</code> 头里），否则返回 <code>403 nonce-required</code>。它能挡住跨站页面盲发 POST 到 <code>127.0.0.1</code>，但<strong>挡不住本机进程</strong>（它自己就能读 <code>/ping</code>）。</p><p>配置项也变多了（schemastery <code>desktop-quick-launcher</code> 命名空间）：<code>restartGraceMs</code>、<code>restartTimeoutSec</code>、<code>busyPolicy</code>（<code>block</code> | <code>warn</code>）、<code>restartMethod</code>（<code>auto</code> | <code>schtasks</code> | <code>detached</code>）、<code>helperStartTimeoutMs</code>，以及三个悬浮按钮的显示开关。</p><h2 id="升级-安装"><a href="#升级-安装" class="headerlink" title="升级 / 安装"></a>升级 / 安装</h2><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">dsh plugin --profile web add github:KLucen/dsh-desktop_quick_launcher</span><br><span class="line"><span class="comment"># 重启 dsh web（之后就可以用面板上的重启按钮了）</span></span><br></pre></td></tr></table></figure><p>github.com 不通就走镜像：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">dsh plugin --profile web add <span class="string">&quot;https://gh-proxy.com/https://codeload.github.com/KLucen/dsh-desktop_quick_launcher/tar.gz/refs/heads/main&quot;</span></span><br></pre></td></tr></table></figure><p><strong>从 v0.2.5 起，升级后不需要再碰桌面图标</strong> —— 宿主启动时会重写脚本，现有快捷方式立刻用上新逻辑。开发的话仓库里有测试：<code>pnpm typecheck &amp;&amp; pnpm test</code> 会把真实的宿主半边挂到 stub cordis 上下文上，直接驱动真实的路由处理器，并注入助手的 spawn 与进程退出钩子、把 <code>DSH_HOME</code> 指向临时目录 —— 所以它不会真的拉起助手、不会退出测试进程，也不会碰你的真实 profile 和桌面。</p><h2 id="已知限制（如实说）"><a href="#已知限制（如实说）" class="headerlink" title="已知限制（如实说）"></a>已知限制（如实说）</h2><ul><li>重启和退出都会<strong>终止整个 <code>dsh web</code> 进程</strong>：会话会持久化并可恢复，但<strong>正在生成的回答不会被保留</strong> —— 这正是它在回合未结束时拒绝执行的原因；</li><li>busy 检查读取 live session store，如果该服务缺失或 API 变化，检查会<strong>放行</strong>（并在 <code>busyCheck</code> 里记录原因）—— 改成 fail-closed 的话，重启会永久失效；想要 v0.1 那种「只报告不阻断」的行为，可以设 <code>busyPolicy: warn</code>；</li><li>nonce 只挡跨站浏览器请求，挡不住本机进程；</li><li>所有路由仅限回环：服务器暴露到局域网时，远程浏览器用不了；</li><li>Windows 图标固定叫 <code>DSH-Web.lnk</code>，同名会被覆盖；</li><li>Windows 的重启助手是 PowerShell 脚本，在禁止执行 PowerShell 的机器上只剩计划任务路径或手动重启；<strong>POSIX 上的重启助手尚未实现</strong>（那边只能等宿主退出后手动启动）；</li><li>仍未发布 npm，安装走 GitHub tarball。</li></ul><h2 id="尾巴"><a href="#尾巴" class="headerlink" title="尾巴"></a>尾巴</h2><p>从「桌面图标 + 一键退出」到「启动 / 重启 / 退出 + 一整套诊断」，这个插件现在算是到了我自己敢天天用的程度：升级不用担心回答被掐断，出问题不用再靠猜。</p><p>仓库还是那个：<a href="https://github.com/KLucen/dsh-desktop_quick_launcher">KLucen/dsh-desktop_quick_launcher</a>（Apache-2.0），有 bug 或想法欢迎开 issue。下一篇大概就是 v0.3 的 POSIX 重启助手了 —— 如果我没偷懒的话。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;上一篇给 &lt;code&gt;dsh web&lt;/code&gt; 写了桌面快捷启动插件 &lt;a href=&quot;https://github.com/KLucen/dsh-desktop_quick_launcher&quot;&gt;dsh-desktop_quick_launcher&lt;/a&gt;。发出来之后自</summary>
      
    
    
    
    <category term="编程" scheme="https://www.klucen.cn/categories/%E7%BC%96%E7%A8%8B/"/>
    
    
    <category term="编程" scheme="https://www.klucen.cn/tags/%E7%BC%96%E7%A8%8B/"/>
    
  </entry>
  
  <entry>
    <title>给 dsh web 做了个桌面快捷启动插件</title>
    <link href="https://www.klucen.cn/posts/73edb7ce.html"/>
    <id>https://www.klucen.cn/posts/73edb7ce.html</id>
    <published>2026-09-09T11:30:00.000Z</published>
    <updated>2026-09-10T11:43:06.388Z</updated>
    
    <content type="html"><![CDATA[<p>给 <code>dsh web</code> 写了个小插件 —— <strong>dsh-desktop_quick_launcher</strong>,补上我一直觉得最缺的两块体验:<strong>双击桌面图标启动</strong>,和<strong>在界面里一键退出</strong>。</p><p>仓库在 <a href="https://github.com/KLucen/dsh-desktop_quick_launcher">GitHub: KLucen/dsh-desktop_quick_launcher</a>(Apache-2.0)。</p><h2 id="为什么会有这个插件"><a href="#为什么会有这个插件" class="headerlink" title="为什么会有这个插件"></a>为什么会有这个插件</h2><p><code>dsh web</code> 是本地优先的服务,日常用其实挺舒服:浏览器打开就是完整 GUI,不占资源、不上云。但「本地服务」嘛,总有点桌面应用才有的别扭感:</p><ul><li><strong>启动要开终端</strong>:先找到终端,敲 <code>dsh web</code>,等它起来,再手动开浏览器;</li><li><strong>退出没入口</strong>:界面里没有「关掉服务」的按钮,关掉浏览器只是断开连接,服务还在后台占着 3080 端口,要么留着吃内存,要么回终端 Ctrl+C。</li></ul><p>其实之前有 <a href="https://www.npmjs.com/package/@linxin666/dsh-desktop-launcher">@linxin666/dsh-desktop-launcher</a> 这个插件解决过类似问题,但它已经退役了。与其依赖别人维护,不如自己动手独立重建一个:能按自己的习惯调整,许可证干净(Apache-2.0,派生关系见仓库 NOTICE),于是就有了这个插件。</p><h2 id="它能做什么"><a href="#它能做什么" class="headerlink" title="它能做什么"></a>它能做什么</h2><p>插件是<strong>双面结构</strong>:</p><ul><li><strong>Host 端</strong>:cordis 插件(注入 <code>webServer</code>),提供两个 API,负责「生成桌面图标」和「优雅退出」;</li><li><strong>Client 端</strong>:加载进 <code>dsh web</code> 页面,右下角多出两个小按钮。</li></ul><p>整体就是下图这么个关系:</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br></pre></td><td class="code"><pre><span class="line">┌─────────────────── dsh web 进程(Host) ───────────────────┐</span><br><span class="line">│  /api/dsh-desktop_quick_launcher/create   → 生成桌面图标   │</span><br><span class="line">│  /api/dsh-desktop_quick_launcher/shutdown → 优雅退出进程   │</span><br><span class="line">│              ▲                               ▲           │</span><br><span class="line">│              └────────── fetch ──────────────┘           │</span><br><span class="line">│   Client(浏览器右下角悬浮按钮):                           │</span><br><span class="line">│     ⏻ 一键退出 · ＋ 一键生成/刷新桌面图标                  │</span><br><span class="line">└──────────────────────────────────────────────────────────┘</span><br></pre></td></tr></table></figure><h3 id="①-双击桌面图标启动"><a href="#①-双击桌面图标启动" class="headerlink" title="① 双击桌面图标启动"></a>① 双击桌面图标启动</h3><p>第一次用,在界面里点右下角那个「生成图标」小按钮,桌面就会出现一个 <code>DSH-Web</code> 图标(Windows 是 <code>.lnk</code>,macOS 是 <code>.command</code>,Linux 是 <code>.desktop</code>;dsh 图标会复制到脚本旁边,以后就算包被移动,快捷方式也不会失效)。</p><p>双击之后脚本会做三件事:</p><ol><li><strong>先探测</strong> GUI 地址——如果 <code>dsh web</code> 已经在运行,直接打开浏览器、退出脚本;</li><li>没在运行的话,<strong>隐藏启动</strong> <code>dsh web --no-open</code>,然后轮询等待服务就绪(给了 150 秒预算,冷启动慢的机器也够);</li><li>就绪后自动打开浏览器。打开这一步还带了<strong>三连兜底</strong>:<code>Start-Process</code> → <code>explorer.exe</code> → <code>cmd /c start</code>,”启动成功了但没弹浏览器”这种情况基本被消灭了。</li></ol><p>排查也简单:每一步(调用了什么命令、找到了哪个 dsh、spawn 的 pid、子进程早退、就绪、每次打开尝试、超时)都写进脚本旁边的 <code>launcher.log</code>,出问题看一个文件就够,不用猜。</p><h3 id="②-界面内一键退出"><a href="#②-界面内一键退出" class="headerlink" title="② 界面内一键退出"></a>② 界面内一键退出</h3><p>右下角有一个固定的<strong>圆形电源按钮</strong>(悬浮在页面角落)。点击后弹出的是<strong>自定义确认弹窗</strong>,不是浏览器那个又丑又不可控的原生 <code>confirm</code>;确认后请求 <code>POST /shutdown</code>:</p><ul><li>宿主进程收到后走<strong>优雅退出</strong>(优先用 dsh launcher 提供的 <code>ctx.appExit</code>,没有就回退 <code>process.exit(0)</code>);</li><li>关键细节:先让响应送达浏览器,<strong>再退出进程</strong>,然后页面自己关闭——不会出现”点了没反应”的错觉。</li></ul><p>按钮旁边还有个小按钮,用来<strong>一键生成/刷新桌面图标</strong>,结果用 toast 提示。比如图标被误删了、或者想换一套启动配置,不用再摸终端。</p><h3 id="③-安全边界-只允许本机操作"><a href="#③-安全边界-只允许本机操作" class="headerlink" title="③ 安全边界:只允许本机操作"></a>③ 安全边界:只允许本机操作</h3><p><code>create</code> 和 <code>shutdown</code> 这两个接口<strong>仅限 loopback</strong>:会同时校验 socket 地址、Host 头和同源标记。也就是说,即使哪天把 <code>dsh web</code> 暴露到了局域网,别人也没法远程给你创建图标或者远程关机。默认还带 <code>enabled</code> 总开关,不想要可以整体关掉。</p><p>配置走 schemastery,暴露在 <code>desktop-quick-launcher</code> 命名空间下:<code>enabled</code> / <code>announceToAgent</code> / <code>dshCommand</code> / <code>url</code> / <code>profile</code> / <code>iconPath</code> / <code>confirmShutdown</code>,可以在 dsh web 的设置里按需调整(比如换端口、换自定义图标)。</p><h2 id="安装"><a href="#安装" class="headerlink" title="安装"></a>安装</h2><p>还没发布到 npm,先走 GitHub:</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line">dsh plugin --profile web add github:KLucen/dsh-desktop_quick_launcher</span><br><span class="line"><span class="comment"># 重启 dsh web 后生效(客户端产物是启动时装载的)</span></span><br><span class="line">dsh web</span><br></pre></td></tr></table></figure><p>直连不了 github.com 的话(比如在墙内),用镜像地址:</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">dsh plugin --profile web add <span class="string">&quot;https://gh-proxy.com/https://codeload.github.com/KLucen/dsh-desktop_quick_launcher/tar.gz/refs/heads/main&quot;</span></span><br></pre></td></tr></table></figure><p>重启后进页面,右下角应该能看到按钮了;点「生成图标」→ 桌面出现 <code>DSH-Web</code> → 以后双击就能开,用完点电源按钮就能关,再也不用为它专门开终端了。</p><blockquote><p>小提醒:第一次双击启动时服务要冷启动(最长 150 秒),<strong>别在就绪前反复双击</strong>——多个脚本实例会各自拉起一个 <code>dsh web</code>,后来的会因 3080 端口被占用而退出(日志里会提示),等第一次启动完成就好。</p></blockquote><h2 id="踩坑记录-写给想写-dsh-web-插件的人"><a href="#踩坑记录-写给想写-dsh-web-插件的人" class="headerlink" title="踩坑记录(写给想写 dsh web 插件的人)"></a>踩坑记录(写给想写 dsh web 插件的人)</h2><p>开发过程中最折腾的不是功能本身,而是 <strong>Client 端产物怎么让 dsh web 正常加载</strong>:</p><ul><li>DSH 的浏览器端 loader 要求每个插件的 <code>./client</code> 入口是 <strong>classic script</strong>,并且必须通过 <code>window.__ModuleLoader__.load(&#123; id, factory &#125;)</code> 自注册(<code>react</code>/<code>react-dom</code> 是由 loader 的 <code>require</code> 注入的);</li><li>如果直接发一个纯 ESM 的 <code>client.mjs</code>,<code>dsh web</code> 会<strong>启动中止</strong>,报 <code>loaded without registering ... via ModuleLoader.load</code>;</li><li>解决方案:<code>pnpm build</code> 里用 esbuild 做一个包装步骤(<code>scripts/wrap-client.mjs</code>)产出 <code>lib/client.js</code>,再在 VM 里校验产物(<code>scripts/verify-client.mjs</code>)。</li><li>血泪教训:别图省事用 PowerShell 手写包装文件——会破坏 UTF-8,界面中文直接变乱码,老老实实从源码 rebuild。</li></ul><p>手动升级也有个坑:直接 bump 版本后 <code>pnpm install</code>,顶层 <code>node_modules</code> 里的条目可能还链着旧版本的 store 目录。正确姿势是先 <code>dsh plugin --profile web remove dsh-desktop_quick_launcher</code>,再重新 add。</p><h2 id="已知限制-如实说"><a href="#已知限制-如实说" class="headerlink" title="已知限制(如实说)"></a>已知限制(如实说)</h2><ul><li>退出按钮会终止<strong>整个</strong> <code>dsh web</code> 进程:正在跑的会话/任务会被中断(会话有持久化,重启后可恢复);</li><li><code>/create</code> 和 <code>/shutdown</code> 刻意只限 loopback:通过远程浏览器连接局域网暴露的服务时,这两个按钮不可用;</li><li>Windows 下生成的图标固定叫 <code>DSH-Web.lnk</code>,同名快捷方式会被覆盖;</li><li>macOS / Linux 的启动脚本由同一套模板生成,但主要在 Windows 上开发验证,那边有问题欢迎带 <code>launcher.log</code> 反馈;</li><li>SDK 依赖锁定在 <code>@deepseek-ai/* 0.1.2-rc.1</code> 一线,会随 DSH 发布节奏更新。</li></ul><h2 id="尾巴"><a href="#尾巴" class="headerlink" title="尾巴"></a>尾巴</h2><p>至此,<code>dsh web</code> 终于有点「正经本地应用」的样子了:桌面上双击图标就能开,用完点一下电源按钮就走,不用再记命令、不用再找终端。</p><p>如果这个插件对你有用,欢迎去 <a href="https://github.com/KLucen/dsh-desktop_quick_launcher">GitHub 仓库</a> 点个 Star,有问题或建议直接开 issue;<a href="https://github.com/KLucen/dsh-desktop_quick_launcher/blob/main/README.zh.md">中文 README</a> 里有更完整的安装和故障排查说明。</p><p>水完这篇,证明博主还活着(确信)。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;给 &lt;code&gt;dsh web&lt;/code&gt; 写了个小插件 —— &lt;strong&gt;dsh-desktop_quick_launcher&lt;/strong&gt;,补上我一直觉得最缺的两块体验:&lt;strong&gt;双击桌面图标启动&lt;/strong&gt;,和&lt;strong&gt;在界面里一键退出&lt;/</summary>
      
    
    
    
    <category term="编程" scheme="https://www.klucen.cn/categories/%E7%BC%96%E7%A8%8B/"/>
    
    
    <category term="编程" scheme="https://www.klucen.cn/tags/%E7%BC%96%E7%A8%8B/"/>
    
  </entry>
  
  <entry>
    <title>《深入理解 AI Agent：设计原理与工程实践》章节精读笔记</title>
    <link href="https://www.klucen.cn/posts/66321874.html"/>
    <id>https://www.klucen.cn/posts/66321874.html</id>
    <published>2026-08-03T09:00:00.000Z</published>
    <updated>2026-08-03T09:07:28.203Z</updated>
    
    <content type="html"><![CDATA[<h1 id="《深入理解-AI-Agent：设计原理与工程实践》章节精读笔记"><a href="#《深入理解-AI-Agent：设计原理与工程实践》章节精读笔记" class="headerlink" title="《深入理解 AI Agent：设计原理与工程实践》章节精读笔记"></a>《深入理解 AI Agent：设计原理与工程实践》章节精读笔记</h1><blockquote><p><strong>原书</strong>：《深入理解 AI Agent：设计原理与工程实践》 李博杰 著（Pine AI 首席科学家）<br><strong>版本</strong>：v1.3 · 2026 年 7 月 27 日 · 全文开源（含全部配图与配套实验代码）<br><strong>定位</strong>：面向工程师的 AI Agent 系统性专著。全书以”实践在前、命名在后”为立场——作者在 Pine（首个能自主与真人交互、可靠独立处理涉及金钱的敏感长程任务的通用 Agent）的实战中倒逼出大量架构原则，后来才被 Anthropic 等公司提炼为 Skill、harness、loop engineering 等名词。<br><strong>本书使命</strong>：帮助你理解和掌握”创造 Agent”的原则。Agent 是宇宙演化史上一种全新的存在：它能通过生成代码实现自举和自我进化。</p></blockquote><hr><h2 id="一、全书总纲：一条公式与一条主线"><a href="#一、全书总纲：一条公式与一条主线" class="headerlink" title="一、全书总纲：一条公式与一条主线"></a>一、全书总纲：一条公式与一条主线</h2><h3 id="核心公式（全书地基）"><a href="#核心公式（全书地基）" class="headerlink" title="核心公式（全书地基）"></a>核心公式（全书地基）</h3><blockquote><p><strong>Agent = LLM + 上下文 + 工具</strong> = 大脑 + 眼睛 + 手脚</p></blockquote><div class="table-container"><table><thead><tr><th>组件</th><th>类比</th><th>广义理解</th></tr></thead><tbody><tr><td><strong>LLM</strong>（大语言模型）</td><td>大脑</td><td>不只是一组模型参数，而是整个决策内核：理解意图、思考规划、做出判断。能力来自预训练（世界知识与语言能力）+ 后训练（决策策略，第七章）</td></tr><tr><td><strong>上下文</strong>（Context）</td><td>眼睛</td><td>Agent 在每个决策点能看到的全部信息：指令、环境信息、用户记忆、领域知识、自身状态、任务进展、工具定义</td></tr><tr><td><strong>工具</strong>（Tools）</td><td>手脚</td><td>Agent 能做的所有事情的集合：预定义工具、按需加载的 Skills、动态生成的代码、委托的子 Agent、与用户沟通、响应外部事件</td></tr></tbody></table></div><p>生产形态下的扩展公式：</p><blockquote><p><strong>Agent = Model + Harness</strong>，其中 <strong>Harness = 上下文 + 工具 + 约束 + 验证 + 纠正</strong></p></blockquote><ul><li>最小公式（Demo 视角）：只有 LLM、上下文、工具即可跑起来；</li><li>扩展公式（生产视角）：补上约束（限定能做什么/不能做什么）、验证（检查做得对不对）、纠正（做错了怎么补救）三层工程外壳。</li><li>推论：模型能力正在商品化，真正的竞争力在模型之外的 Harness——“行业正在从’能做事’向’可靠地做事’转变”。</li></ul><h3 id="工程范式演进弧线（第一章-1-2-1）"><a href="#工程范式演进弧线（第一章-1-2-1）" class="headerlink" title="工程范式演进弧线（第一章 1.2.1）"></a>工程范式演进弧线（第一章 1.2.1）</h3><p>软件工程 → 提示工程（Prompt Engineering）→ 上下文工程（Context Engineering）→ Harness 工程 → <strong>Loop 工程</strong></p><p>层层包含：提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程。每一层都在前一层基础上扩展工程师的关注范围。实证：LangChain 在 Terminal Bench 2.0 上仅靠优化 Harness（自验证循环、循环检测、工具中间件）就把 Coding Agent 从 52.8% 提升到 66.5%（30 名开外跃升至前 5），<strong>没换模型</strong>。</p><h3 id="贯穿全书的判断"><a href="#贯穿全书的判断" class="headerlink" title="贯穿全书的判断"></a>贯穿全书的判断</h3><ul><li><strong>上下文的质量决定 Agent 能力上限</strong>，而非模型参数量。”人和模型一样，最重要的是 Context”（OpenAI 翁家翌）。一个中等模型 + 精心组织的上下文，往往胜过顶级模型在信息匮乏下的盲目摸索。</li><li><strong>没有评估，就没有进步</strong>（第六章）。评估是科学方法论做工程的地基。</li><li><strong>数据和环境比算法更重要</strong>（第七章主线）：先验（基础模型）&gt; 环境 &gt; 算法。</li><li><strong>实践在前，命名在后</strong>：等名词流行再动手就慢了一步。提前两步：① 拥有对 Agent 能力上限要求极高的真实业务；② 建立评估机制。</li><li><strong>模型与 Agent 共同演进</strong>：Harness 里层层叠叠的兜底逻辑，记录的都是模型此刻还做不稳的地方；下一代模型把这些约束内化后，Harness 再往上走一层。</li></ul><hr><h2 id="二、引言：为什么写这本书"><a href="#二、引言：为什么写这本书" class="headerlink" title="二、引言：为什么写这本书"></a>二、引言：为什么写这本书</h2><ul><li><strong>实践出真知</strong>：作者团队打造的 Pine（自主替用户打电话协商账单、退款、取消订阅的通用 Agent）动辄几十轮交涉，任何一步出错都会造成真金白银的损失，正是这种苛刻的可靠性要求倒逼出了全书架构原则。</li><li><strong>“实践在前、命名在后”的三个例证</strong>：<ul><li>Skill 概念流行前，已用动态加载提示词解决提示词无限膨胀；用命令行执行工具解决工具列表膨胀；用系统状态栏解决 Agent 不感知环境/时间/工作状态。</li><li>harness 概念流行前，已用类似 Claude Code 的方法解决工具调用不稳定、幻觉、危险/越权操作、指令不遵循。</li><li>loop engineering 概念流行前，已使用”提议者-审核者（proposer-reviewer）”方法解决模型过早认为任务完成。</li></ul></li><li><strong>Richard Sutton 的启示</strong>：宇宙演化经历尘埃→恒星→生命→智能体（designed entities）四阶段。生物进化是盲目的，而 Agent 能理解自身运作机制、创造新智能体、甚至改进自己——“像一个程序员编写了另一个程序员”。</li><li><strong>两大”乌云”（后记展开）</strong>：① 大世界假设——训练数据永远覆盖不了每个具体用户/公司的情境知识，模型只能在上岗后持续学习（对应第三章记忆、第八章持续进化）；② 前沿开放任务没有现成答案，Agent 只能从实验成败中自主学习。结论：<strong>模型最强的能力终将不是记住，而是学习与适应</strong>。</li></ul><hr><h2 id="三、第-1-章：AI-Agent-入门（全书概念地图）"><a href="#三、第-1-章：AI-Agent-入门（全书概念地图）" class="headerlink" title="三、第 1 章：AI Agent 入门（全书概念地图）"></a>三、第 1 章：AI Agent 入门（全书概念地图）</h2><p><strong>章节定位</strong>：快速引入 Agent 核心公式、运行循环、工程框架和设计模式，为后续章节提供统一术语与参照坐标。</p><h3 id="1-1-现代-Agent-LLM-上下文-工具"><a href="#1-1-现代-Agent-LLM-上下文-工具" class="headerlink" title="1.1 现代 Agent = LLM + 上下文 + 工具"></a>1.1 现代 Agent = LLM + 上下文 + 工具</h3><ul><li><strong>工具：Agent 的手脚</strong>。五类工具（按与外界互动方向分类）：<ol><li><strong>感知工具</strong>：访问信息（搜索引擎、文件系统、API、数据库）</li><li><strong>执行工具</strong>：改变世界（代码执行、文件操作、系统命令、外部 API）</li><li><strong>协作工具</strong>：与其他 Agent 分工、请求人类确认、协调行动</li><li><strong>事件触发工具</strong>：特殊——不是 Agent 主动调用，而是外部输入（新邮件、定时器、Webhook）驱动 Agent 开始工作</li><li><strong>用户沟通工具</strong>：Agent 主动与用户建立连接（文字、语音、邮件）</li></ol><ul><li>工具调用（Tool Calling / Function Calling）四步流程：告诉模型可用工具 → 模型判断是否调用/调哪个/传什么参 → 工具执行并把结果追加到上下文 → 模型据此决定下一步。这构成 ReAct 的基础。</li><li>MCP（模型上下文协议）正在让工具接入变得像安装插件，但设计原则不会过时。</li></ul></li><li><strong>LLM：Agent 的大脑</strong>。解析真实意图（用户说的往往不是他真正想要的）、拆解任务、持续决策。独特能力：<strong>内部思考</strong>（采取行动前的规划与推演，不改变外部环境但提升行动质量）；<strong>零样本泛化</strong>（组合已有知识处理全新任务）；<strong>少样本适应</strong>（两三个示例即可学会新模式）。<ul><li><strong>模型即 Agent（Model as Agent）</strong>新范式：先进模型通过后训练把”何时调用工具、如何编排”内化为原生能力（例：Kimi K3 约 2.8 万亿参数 MoE，100 万 token 上下文，始终开启思考模式；GPT-5.6 把 Deep Research 设计理念内化到模型层，自带意图澄清机制——不立即执行，先提问确认真实需求）。</li></ul></li><li><strong>上下文：Agent 的眼睛</strong>。从 API 视角看，每次调用的上下文由五部分组成：<ol><li><strong>系统提示词</strong>（System Prompt）：开发者编写、全程不变，即”岗位说明书”（含用户记忆、动态环境状态）</li><li><strong>工具定义</strong>（Tool Definitions）：工具名称、功能、参数格式</li><li><strong>用户消息</strong>（User Messages）：用户输入 + 可能经 RAG 引入的外部知识</li><li><strong>模型回复</strong>（Assistant Messages）：思考过程（reasoning）+ 文本内容（content）+ 工具调用（tool_calls）</li><li><strong>工具执行结果</strong>（Tool Results）：Agent 下一步思考的直接依据</li></ol><ul><li>前两项构成<strong>静态前缀</strong>，后三项构成<strong>动态轨迹（trajectory）</strong>。<strong>Agent 的上下文 = 静态前缀 + 轨迹</strong>。</li><li><strong>消融实验（实验 1-1）</strong>证实：去掉工具定义 → Agent 完全丧失行动能力；缺工具执行结果 → 反复犯错、无限循环；缺历史消息 → 无法保持连贯。上下文决定 Agent 能看到什么，而 Agent 只能基于看到的信息做决策。</li></ul></li></ul><h3 id="1-2-ReAct-循环：想-→-做-→-看"><a href="#1-2-ReAct-循环：想-→-做-→-看" class="headerlink" title="1.2 ReAct 循环：想 → 做 → 看"></a>1.2 ReAct 循环：想 → 做 → 看</h3><ul><li><strong>ReAct = Reasoning + Acting</strong>，实际循环三环节：思考当前该做什么 → 调用工具行动 → 观察结果继续思考，直到任务完成。</li><li><strong>轨迹（trajectory）</strong> = 用户消息 + 模型回复（思考+工具调用）+ 工具执行结果，随交互不断增长；每次 LLM 调用都基于”静态前缀 + 轨迹”。</li><li>轨迹的价值：全局认知、可解释可调试、可总结进知识库、可做强化学习训练数据（闭环优化）。</li></ul><h3 id="1-3-Harness-工程：模型之外的竞争力"><a href="#1-3-Harness-工程：模型之外的竞争力" class="headerlink" title="1.3 Harness 工程：模型之外的竞争力"></a>1.3 Harness 工程：模型之外的竞争力</h3><ul><li>一个能跑的 Demo 与一个可靠的产品之间隔着巨大的鸿沟：模型会幻觉（编造不存在的工具/参数）、选错工具、无法自我恢复。</li><li><strong>Harness 五个功能</strong>：上下文设计（信息充分性）、工具设计、约束、验证、纠正。围绕”上下文+工具”构建的保障层。</li><li><strong>构建有效 Agent 的三原则</strong>（Anthropic 经验）：<ol><li><strong>保持简单</strong>：从最简单的方案开始，直接 API 调用优于复杂框架，清晰代码优于聪明抽象；</li><li><strong>保持透明</strong>：明确显示规划步骤、执行日志、决策轨迹（调试 + 信任）；</li><li><strong>设计好工具接口（ACI，Agent-Computer Interface）</strong>：从 Agent 视角设计接口。用”防呆（Poka-yoke）”设计消除错误——SIM 卡缺角、微波炉门没关好不加热。</li></ol></li><li><strong>如何选择模型</strong>：”御三家”（OpenAI GPT/o、Anthropic Claude、Google Gemini）各有侧重；国内模型（豆包低延迟、Kimi Agent 能力强、Qwen/DeepSeek 开源低成本）；关注延迟（每轮慢 2 秒 × 20 轮 = 多等 40 秒）与多模态支持；<strong>不要只看排行榜，要在自己的任务上做评估</strong>（第六章）。</li><li><strong>编排模式：从简单到复杂</strong>——先优化单个 LLM 调用 → 需要多步骤且可拆分为固定子任务时用<strong>工作流（Workflow，确定性编排，路径代码写死）</strong> → 只有需要动态决策和灵活执行路径时才用<strong>自主 Agent（本质 = 循环中使用工具的 LLM，即 ReAct）</strong>。Agent 系统通常用延迟和成本换取更好的任务性能，要谨慎权衡。退出条件：调用 final_answer / 无工具调用返回 / 达到最大轮次 / 错误次数超限。</li><li><strong>护栏与安全性（Guardrails）</strong>：分层防御机制，单护栏不够，组合使用。按防护位置分三类：<ul><li><strong>输入侧</strong>：相关性分类器、安全分类器（区分<strong>越狱</strong>=用户自己绕过安全限制 vs <strong>提示注入</strong>=攻击者通过外部数据间接操纵）、内容审核、基于规则的保护（黑名单/长度限制/正则）。</li><li><strong>执行侧</strong>：工具风险评级（可逆性、权限等级、财务影响）、权限分类（哪些操作需用户确认）、熔断器、错误恢复机制。</li><li>输出侧：输出过滤与校验。</li></ul></li><li><strong>章节结论</strong>：眼睛（上下文）是决定性因素；Harness 是竞争力所在；从工作流到自主 Agent 是降低意外风险最实用的顺序；<strong>安全是架构问题</strong>——从第一行代码就要考虑，而不是上线前打补丁；安全贯穿模型、上下文、工具、协作、社会五个层面。</li></ul><hr><h2 id="四、第-2-章：上下文工程（全书最关键的一章）"><a href="#四、第-2-章：上下文工程（全书最关键的一章）" class="headerlink" title="四、第 2 章：上下文工程（全书最关键的一章）"></a>四、第 2 章：上下文工程（全书最关键的一章）</h2><p><strong>章节定位</strong>：系统讲解上下文——Agent 的”眼睛”。上下文工程首先是一个技术问题，但更根本的是一个<strong>组织问题</strong>：大多数团队的关键知识是隐性的（架构决策只在老员工记忆里、业务规则口口相传）。”对远程工作友好的团队往往也对 AI Agent 友好”（Linux 内核是范例：透明、文档驱动）。</p><h3 id="2-1-上下文：决定-Agent-能力上限的关键"><a href="#2-1-上下文：决定-Agent-能力上限的关键" class="headerlink" title="2.1 上下文：决定 Agent 能力上限的关键"></a>2.1 上下文：决定 Agent 能力上限的关键</h3><ul><li>Coding Agent 的最低信息需求三类：<strong>实时代码上下文</strong>（目录结构、模块职责、数据结构、代码规范）、<strong>流程规范</strong>（Git 分支策略、提交规范、审查流程、CI/CD）、<strong>环境信息</strong>（开发/测试/生产配置、API 密钥管理）。</li><li>“AI Agent 就像一个永远的新员工：给足背景信息，它能干得很好；什么都不告诉它，再聪明也是白搭。”</li></ul><h3 id="2-2-Agent-如何调用大模型：理解-API-的上下文结构"><a href="#2-2-Agent-如何调用大模型：理解-API-的上下文结构" class="headerlink" title="2.2 Agent 如何调用大模型：理解 API 的上下文结构"></a>2.2 Agent 如何调用大模型：理解 API 的上下文结构</h3><ul><li><strong>消息的四种角色</strong>：system（系统提示词，最高优先级，通常只有一条且在最前）、user（用户输入）、assistant（模型之前的回复，会被放回消息列表让模型”记住”自己说过什么）、tool（工具结果，通过 tool_call_id 与调用关联）。工具定义（tools）是请求的独立字段而非消息。</li><li><strong>单轮对话</strong>：每次调用无状态——模型需要的所有信息必须在 messages 中完整提供。</li><li><strong>带工具调用的多轮交互（Agent 核心循环）</strong>：模型返回 tool_calls（不是最终回复）→ Agent 框架执行工具 → 把完整历史 + tool 结果送回 → 模型生成最终回复。<strong>关键：模型负责决策，框架负责执行</strong>。</li><li><strong>用代码实现</strong>：核心就是一个 while 循环——返回了 tool_calls 就执行工具并继续，没有就输出退出。框架的全部工作就是管理 messages 列表。<strong>本章后续所有技术本质都在优化这个列表的内容和结构</strong>。</li><li>上下文结构 = <strong>静态前缀（System Prompt + Tool Definitions）+ 轨迹（动态增长的消息历史）</strong>。”前面不能动、后面可以压缩”是后续 KV Cache 与压缩技术的基础。</li></ul><h3 id="2-3-KV-Cache-友好的上下文设计（全书技术密度最高的部分）"><a href="#2-3-KV-Cache-友好的上下文设计（全书技术密度最高的部分）" class="headerlink" title="2.3 KV Cache 友好的上下文设计（全书技术密度最高的部分）"></a>2.3 KV Cache 友好的上下文设计（全书技术密度最高的部分）</h3><ul><li><strong>直觉</strong>：模型每生成一个 token 都要”回头看”前文所有 token 的中间计算结果；KV Cache 把前文结果缓存下来，下一轮只算新增部分。<strong>前提是前缀完全不变——改一个字符，缓存全部作废</strong>。</li><li><strong>三条核心实践结论</strong>：<ol><li>系统提示词和工具定义一旦确定就不要改（哪怕多一个空格，都会导致延迟成倍增加、成本上升）；</li><li>动态信息永远<strong>追加到末尾</strong>（时间戳、用户状态作为新消息追加，而不是修改已有提示词）；</li><li>使用<strong>标准 API 格式</strong>，不要自行拼接消息（Chat Template 把结构化消息翻译成模型训练时见过的固定 token 序列；自行拼接”USER:/ASSISTANT:”偏离训练格式会削弱多步思考能力）。</li></ol></li><li>反面案例：某客服 Agent 在系统提示词里加一行 <code>Current time: &amp;#123;&amp;#123;now&amp;#125;&amp;#125;</code>，首 token 延迟从 0.5 秒涨到 3-5 秒，月度账单几乎翻倍——时间戳让 KV Cache 每次请求全部失效。</li><li><strong>Chat Template（聊天模板）</strong>：把结构化 API 消息转换成模型能处理的线性 token 流（特殊标记如 &lt;|im_start|&gt;、&lt;|im_end|&gt; 界定角色与消息边界）。不同模型家族（Qwen、Llama、Gemma）使用不同”信封格式”。<ul><li>关于<strong>思考（reasoning）的保留</strong>：行业从”剥离历史思考”（DeepSeek R1 早期）反转为”强制回传全部 reasoning_content”（DeepSeek V4，否则报错；Kimi K2、GLM-5 同样；Claude 要求 thinking block 带签名校验原样回传）。<strong>对 Agent 场景而言，思考不是废料，而是状态</strong>。</li></ul></li><li><strong>KV Cache 原理</strong>：无缓存时 prefill 阶段注意力计算量随上下文长度平方级增长；有缓存时每步解码只需线性遍历。修改前缀导致所有层缓存失效（Transformer 层间串联传导）。</li><li><strong>KV Cache vs Prompt Cache 两个层级</strong>：KV Cache 是模型内部优化（加速单次请求内 token 生成）；Prompt Cache 是 API 服务层优化（跨请求复用相同前缀的计算结果，直接省计费）。Prompt Cache 读取成本约为首次计算的十分之一（Anthropic/DeepSeek/GPT-5 系列）。注意各家机制差异：Anthropic 需显式 cache_control 断点（写入加价约 1.25 倍、最小缓存长度、TTL 约 5 分钟），OpenAI 自动前缀缓存。</li><li><strong>缓存作为架构约束（生产级）</strong>：Claude Code 的实践——提示词结构由缓存边界决定（边界前可跨用户/会话全局缓存，边界后是用户/会话特定信息；动态条件如 OS 类型、模式、语言会产生 2^N 种缓存键，全部严格归类到边界之后）；<strong>子 Agent 必须与父 Agent 字节级对齐</strong>（提示词、工具定义、模型配置逐字节匹配才能命中缓存）。</li><li><strong>前沿延伸（可编辑、可组合的”笔记”）</strong>：prefill 阶段模型其实在”做笔记”——字段自身的 KV 对最终决策贡献往往不到 1%，真正影响输出的是它在下游留下的结论。由此实现：编辑（有显式 CoT 时，改动可顺着已缓存思考以约 1% 算力传播）与组合（把预计算的”技能”缓存块用 RoPE 重定位拼接，长上下文从 O(L²) 重算降到 O(L) 拼接，质量与重算无差别）。</li></ul><h3 id="2-4-提示工程：优化系统提示词"><a href="#2-4-提示工程：优化系统提示词" class="headerlink" title="2.4 提示工程：优化系统提示词"></a>2.4 提示工程：优化系统提示词</h3><ul><li>检验标准：”如果一个聪明的新员工读完你的系统提示词还不知道该怎么做，Agent 也一样不知道。”</li><li><strong>语气与风格（”人格”）</strong>：”You MUST…”/大写比”Please avoid…”更能引起注意，但过度使用会稀释，应保留给真正关键的约束。</li><li><strong>结构化提示（”格式”）</strong>：现代模型对结构化输入敏感（训练数据含大量结构化内容）。XML 标签名自带语义（<working_directory> 优于”当前目录：…”）；XML 负责机器可解析的精确语义，Markdown 负责人机共读的组织逻辑。</li><li><strong>流程驱动 vs 规则堆砌（”组织方式”）</strong>：上百条零散规则（无流程图、无优先级）即使对人也是灾难。流程驱动（SOP 式）让模型任何时刻清楚自己处于哪个阶段、目标是什么、下一步去哪。<strong>消融实验（实验 2-4）：打乱信息组织结构 → 任务成功率下降超过 30%</strong>（如”先验证身份再处理退款”被拆散后，Agent 有时跳过验证直接退款）。结论：<strong>对人类友好的信息组织方式，对模型同样友好</strong>。</li><li><strong>业务规则细化（”内容”）</strong>：最容易被忽视却最关键的环节，需要产品经理深度参与。案例：帮用户打电话谈判的计费系统——“按省钱提成 / 按服务收 tip / 特别难办的预收款”三种模式必须把决策规则明确到可执行程度（”退款和取消服务绝对不能按提成”、”NEVER use percent…”），模糊规则会导致行为极不稳定。</li><li><strong>Few-shot 示例</strong>：当期望输出难以用规则精确描述时，两三个高质量示例胜过等量篇幅的抽象规则。工程决策：示例放系统提示词（静态前缀一部分）还是伪造 user/assistant 消息（按会话类型选用）；<strong>示例应保持字节级稳定</strong>（动态检索最相关示例 = 每次改写前缀，缓存持续失效）；数量不是越多越好。</li><li><strong>工具定义设计</strong>：每个工具描述应有使用边界（”NEVER invoke grep as a Bash command”）、具体示例（timezone: ‘America/New_York’）、性能提示（”Batch your tool calls”）、工具间协作关系。</li><li><strong>提示注入：上下文安全的核心威胁</strong>——详见 2.7 前的小节内容（见下文 2.5 前）。防御核心：帮模型分清”指令”与”数据”（来源标记、指令/数据分离、输入清洗），但只是第一道防线，执行层防御（权限、沙盒、独立审查）在第四、五章展开。</li></ul><h3 id="2-5-动态提示词与-Agent-Skills"><a href="#2-5-动态提示词与-Agent-Skills" class="headerlink" title="2.5 动态提示词与 Agent Skills"></a>2.5 动态提示词与 Agent Skills</h3><ul><li><strong>Skills = 领域能力的可组合单元</strong>：把 Agent 能力模块化为独立、可按需加载的知识包。设计哲学：<strong>渐进式披露（Progressive Disclosure）</strong>。<ul><li><strong>第一层（元数据）</strong>：SKILL.md 开头的 YAML frontmatter（name + description），启动时只注入数百 token 的目录摘要。<strong>description 要写成路由条件而非功能介绍</strong>——“何时该用我”比”我能做什么”重要得多；<strong>反例（Don’t use when）是关键</strong>，缺少反例路由准确率明显下降。</li><li><strong>第二层（核心流程）</strong>：Agent 判断需要时通过 Skill 工具加载完整 SKILL.md，作为 tool result 进入对话历史。</li><li><strong>第三层（细则）</strong>：通过文件引用深入子文档（html2pptx.md、reference.md 等）。</li><li>Skill 可捆绑可执行代码工具和模板文件——从知识传递升级为能力赋予。</li></ul></li><li><strong>Skills 的实现方式与权衡</strong>（内容放哪）：<ul><li>方式一：注入系统提示词——指令遵循最强，但每次加载都破坏 KV Cache 前缀；</li><li>方式二：作为普通文件读取（tool result 出现在上下文中间）——不破坏缓存，但要求模型在长上下文中间位置识别并遵循指令，不同模型支持差异大（Claude 最可靠）；</li><li><strong>方式三（生产实现，Claude Code）</strong>：元数据作为动态上下文提供给模型（不反复改写稳定前缀），完整内容通过专用工具按需加载——路由与执行分离。</li><li>澄清：Skill 元数据以什么消息角色注入（user/system/<system-reminder>）是 Harness 实现细节，不是机制固定要求。</li></ul></li><li><strong>Skills 与工具的关系</strong>：Skills 对 KV Cache 极为友好——工具数量始终很少（第五章七个核心工具），Skill 内容按需加载不影响缓存前缀。把”工具选择”问题转化为”知识检索”问题（LLM 擅长的）。</li></ul><h3 id="2-6-Agent-状态栏：通过元信息增强轨迹管理"><a href="#2-6-Agent-状态栏：通过元信息增强轨迹管理" class="headerlink" title="2.6 Agent 状态栏：通过元信息增强轨迹管理"></a>2.6 Agent 状态栏：通过元信息增强轨迹管理</h3><ul><li><strong>理论基础</strong>：<strong>上下文学习更像检索而非推理</strong>——注意力擅长在已有内容里”查找”，不擅长在一次前向传播里主动”归纳统计”。”上下文窗口是一台只有一半的检索引擎”：检索半很强（RAG 内置进每次前向传播），但缺”提炼层”——任何”关于这些内容的结论”（共多少条、有没有超标、进展到哪一步）模型每次都要从原始记录现算一遍，代价随内容量 N 上涨。</li><li>实际场景：系统提示词要求”每个商家最多拨打 3 次”，但 Agent 经常数不清打了几次又打第 4 次。解法：在每次工具调用结果中直接注入”本次是第 3 次呼叫”——错误率大幅降低。本质：把分散在上下文各处的隐式状态提炼为可直接使用的<strong>显式知识</strong>。</li><li><strong>实验数据（2.4 万次评测）</strong>：弱模型补回来的是<strong>准确率</strong>（最弱模型涨 40-54 个百分点，2B 小模型追平不带状态栏的前沿大模型）；强模型省下来的是<strong>效率</strong>（思考 token 砍掉八九成，延迟、花费各降约一个数量级）；带上状态栏后思考量变得恒定（”瞥一眼”那几格状态）。</li><li><strong>三条直接能照做的经验</strong>：<ol><li><strong>状态栏要用代码维护，别拿大模型维护</strong>——20 行正则函数就能达到标准答案级准确度，LLM 反而会编造；</li><li>状态栏要写成能一眼定位的<strong>键值对</strong>（”衣物: 9 件（合格7、次品2）”），散文形式效果明显更差；</li><li><strong>状态栏最有价值的是模型无从推断的外部事实</strong>（”闭卷考试变成随时能查一眼真实世界”）——来自真实观测的信息价值最高；拍脑袋编的或可被污染数据源的状态栏会误导模型（投毒风险）。</li></ol></li><li><strong>构成</strong>：任务规划（TODO 列表放轨迹末尾）、事件的侧信道信息（精确时间/地理位置/距上次回复间隔）、环境当前状态（系统时间、工作目录、异常提醒”该工具已被重复调用 N 次”）、可用能力清单（已安装 Skill 元数据）。</li><li><strong>位置</strong>：以 user 角色 + <agent_status> 标签包裹的元信息追加在上下文最末尾——紧邻模型即将生成的新 token，获得最高注意力权重；追加而非修改，不破坏缓存。</li><li><strong>状态更新的两种实现</strong>：实现一”每轮替换”（删除旧状态追加新状态，失效范围限于末尾几轮缓存）；实现二”持久追加”（Claude Code 的 <system-reminder> 方式，缓存完全友好但陈旧状态累积）。经验法则：状态更新频繁且轨迹长选实现二，轨迹短或单条状态大选实现一。</li><li><strong>时间感（time sense）</strong>：把缺失的能力拆成三个可度量的轴——<strong>紧迫度</strong>（把投入的力气匹配到时钟上）、<strong>坚持度</strong>（分清真墙假墙、知道活儿干完没有）、<strong>警觉度</strong>（把工具响应的时间异常升级为值得追查的假设）。实验发现”缺时间感”是当前后训练普遍漏掉的一项控制；推理时可用”状态栏+操作手册”装上，也可蒸馏进权重（第七章：稀疏结果奖励学不会，逐 token 稠密信号才学会）。</li></ul><h3 id="2-7-上下文压缩策略"><a href="#2-7-上下文压缩策略" class="headerlink" title="2.7 上下文压缩策略"></a>2.7 上下文压缩策略</h3><ul><li><strong>为什么需要压缩（两个截然不同的动机）</strong>：<ol><li>解决长度与成本约束（窗口有限、token 越多越贵越慢）；</li><li><strong>提升思考质量</strong>——总结后的知识比原始形式更利于模型使用（10 次网页搜索的原始结果散落各处，模型需在数万 token 中反复检索；先做一次结构化总结”目前已知 A 是…，还缺 C”，后续思考直接使用精炼表示）。</li></ol></li><li><strong>内部机制</strong>：上下文学习更像检索而非推理。黑猫白猫计数例证：100 个笼子装进上下文，模型仍需逐个数（思考而非检索）；提前写入”黑猫 90 只、白猫 10 只”，模型立即检索到结论。长上下文还会导致<strong>上下文腐化（Context Rot）</strong>——窗口远没满，但 Agent 找不到关键信息。</li><li><strong>压缩与 KV Cache 看似矛盾实则互补</strong>：压缩发生在两次 API 调用之间，由框架预处理消息列表；System Prompt 和 Tool Definitions 永远不动；压缩对象是对话历史中的 tool results——替换位置之后的缓存失效，之前的仍有效。<strong>压缩频次要权衡：接近阈值时批量压缩，而不是每轮都压</strong>。</li><li><strong>生产级分层压缩机制（Claude Code 参照，五层）</strong>：<ol><li>工具结果预算控制（大输出存磁盘，模型只看摘要预览）；</li><li>噪声直接删除（低价值内容不做摘要——对噪声做摘要在浪费 token）；</li><li>API 层微压缩（上下文编辑能力移除指定工具结果，适合上下文即将溢出时使用）；</li><li>归档式摘要（逐轮结构化摘要，像 git log 保留每轮独立记录）；</li><li>全量压缩（LLM 驱动，分两阶段：先压缩会话记忆，不行再全量；配连续失败熔断器——生产数据表明大量会话被困在反复压缩失败的循环中）。</li></ol><ul><li>前三层成本低、对缓存扰动可控，优先使用；后两层兜底。</li></ul></li><li><strong>压缩策略设计四原则</strong>：信息价值非均匀分布（关键决策点 &gt; 支撑性证据 &gt; 冗余噪声）；语义完整性（”Sutskever 于 2024 年 5 月离开 OpenAI”不能压成”Sutskever 离开”）；任务相关性（同样内容在不同任务下应有不同压缩结果）；压缩即理解（压缩模块本身需要接近主模型的语言理解能力，形成”模型调用模型”的递归架构）。</li><li><strong>保留优先级（生产建议）</strong>：架构决策和关键约束不得摘要；已修改文件列表和关键变更记录完整保留；验证状态（pass/fail）必须保留；未解决 TODO 和回滚笔记必须保留；工具输出可删除仅保留结论。UUID/hash/IP/端口/URL/文件名必须原样保留。</li><li><strong>隔离优于压缩：子 Agent 上下文隔离</strong>——让大体积中间信息根本不进入主上下文。主 Agent 把”读取大量文件””大范围搜索”委派给独立子 Agent，只回传几百 token 的结论性摘要。压缩是有损的事后补救，隔离让噪声从一开始绝缘；代价是子 Agent 看不到主上下文，任务描述必须自包含。</li></ul><h3 id="2-8-本章小结"><a href="#2-8-本章小结" class="headerlink" title="2.8 本章小结"></a>2.8 本章小结</h3><p>“给模型看什么、怎么组织，比模型本身有多聪明更影响最终的结果。”所有技术共同点：<strong>显式的、工程化的信息管理——不要让模型被动在海量上下文中寻找线索，要主动提供经过提炼的结构化状态</strong>。回到 Rich Sutton《苦涩的教训》：能更有效利用更多算力的通用方法最终胜出。本章处理的是任务之内的状态更新与上下文腐化；跨任务的持久进化是第八章的主题。</p><hr><h2 id="五、第-3-章：用户记忆和知识库"><a href="#五、第-3-章：用户记忆和知识库" class="headerlink" title="五、第 3 章：用户记忆和知识库"></a>五、第 3 章：用户记忆和知识库</h2><p><strong>章节定位</strong>：把上下文管理延伸到跨会话的持久化知识体系，让 Agent 记住用户、构建共享知识库。</p><h3 id="3-1-用户记忆系统"><a href="#3-1-用户记忆系统" class="headerlink" title="3.1 用户记忆系统"></a>3.1 用户记忆系统</h3><ul><li>记忆的本质：不是记录用户说过的每一句话，而是构建一个关于用户的<strong>简洁而有效的预测模型</strong>——投入额外算力（专门的 LLM 调用）将分散在冗长对话历史中的关键信息显式提取和压缩。用户记忆是持久的、可审查的；上下文学习是临时的、会话结束就消失。</li><li>提取过程三特征：<strong>选择性</strong>（只保留对未来有用的事实）、<strong>抽象化</strong>（”I prefer window seats”提炼为通用偏好而非绑定具体航班）、<strong>结构化</strong>（每条记忆标记类型：偏好/限制/账号）。</li><li><strong>记忆能力评估：三层次框架</strong>（实验 3-1，每层 20 个测试用例）：<ol><li><strong>基础回忆</strong>：单会话内回忆个人信息、追踪偏好、上下文切换、记忆更新；</li><li><strong>多会话检索</strong>：从多个不同对象、不同时期的会话中检索所有相关信息并推理判断（用户有两辆车时预约保养要主动问哪辆；取消”洛杉矶之旅”要关联机票和酒店）；</li><li><strong>主动服务</strong>（最高标准）：跨很久以前的会话综合信息、提供预见性帮助（订国际航班时主动关联数月前的护照信息并预警过期；手机损坏时整合所有保障方案）。要求没有明确指令时主动规避问题和整合复杂信息。</li></ol><ul><li>公开基准参考：LoCoMo（约 300 轮、最多 35 个会话的超长多轮对话）。</li></ul></li><li><strong>记忆的层次结构（放哪里）</strong>：<strong>轨迹</strong>（单次会话完整原始记录，append-only，对应工作记忆）vs <strong>用户长期记忆</strong>（跨会话持久化、键值对绑定用户 ID、反复改写合并淘汰）vs <strong>业务状态</strong>（开发者定义的高层任务阶段抽象，事件驱动架构中重要）。</li><li><strong>四种存储格式（怎么存）</strong>（实验 3-2）：<ol><li><strong>Simple Notes</strong>（原子事实，键值对）：O(1) 开销极低，但丢失关联性；</li><li><strong>Enhanced Notes</strong>（整段叙事）：语义完整，但冗余、难更新、长文难检索；</li><li><strong>JSON Cards</strong>（类别→键值，结构化）：可检索、可更新，但灵活性差；</li><li><strong>Advanced JSON Cards</strong>（backstory + person + relationship 实体模型）：能回答”为什么存这条””为谁存”，支持家人关系消歧，代价是生成维护成本高。</li></ol><ul><li>根本张力：简单性与表达力。实践标准：关键且少量数据（偏好、人物关系）用 Advanced JSON Cards；大量且非关键对话事实用 Simple Notes；多数生产系统用混合模式。</li></ul></li><li><strong>进阶表示：从可执行代码到参数化记忆</strong>：<ul><li><strong>User as Code</strong>：把记忆介质从文本换成可执行代码（带类型 Python 对象存用户状态、函数编码约束规则）。两阶段：”预写日志 + 周期性检查点”（记忆阶段逐条追加只增事实日志；结构化阶段周期性地重新生成带类型的 Python 结构）。三件事从”LLM 心算”变成确定性代码：<strong>聚合统计</strong>（”去年出国几次”——检索式记忆在聚合问题上正确率只有 6%-43%，代码一行表达式接近 100%）、<strong>冲突发现</strong>（用药 vs 过敏史交叉比对）、<strong>约束执行</strong>（护照到期前 180 天自动报警）。</li><li><strong>User as Engram（写入局部参数）</strong>：给每用户训练 LoRA 有”存了却不会用”的困境（fact-LoRA 能复述但不能间接推理——冻结的骨干没学过如何查阅临时挂载的适配器）。Engram 方案：把用户事实精准写入模型中空闲的哈希 N-gram 槽位（预训练已学会哈希查表调取记忆 + 上下文感知门控决定何时调取），不同用户事实落在互不相交槽位、互不干扰。</li><li><strong>多模态记忆</strong>：感知性的记忆（一张脸、一段嗓音、画家的笔触）经不起转写成文字。Parametric Multimodal User Memory：为冻结模型外挂连续注意力记忆库，让感知以感知形态保存。</li></ul></li><li><strong>认知科学基础（存什么）</strong>：工作记忆 = 上下文窗口；长期记忆三分：<strong>情景记忆</strong>（具体事件，如”订了下周五去东京的 ANA 航班”）、<strong>语义记忆</strong>（抽象的一般知识，如”用户是素食者”）、<strong>程序记忆</strong>（行为模式和流程，如”订票流程：先搜索直飞→确认座位偏好→用常旅客号”）。</li><li><strong>记忆框架案例</strong>：<strong>Mem0</strong>（提取—对比—决策两阶段流水线：提取阶段 LLM 从近期对话+已有摘要提取候选记忆，更新阶段向量检索相近已有记忆并对比决策；嵌入与存储分离可独立替换；Mem0-g 图记忆变体捕捉记忆间关联）；<strong>Memobase</strong>（用户画像 Profile + 事件记忆 Event Memory；缓冲批处理摊薄 LLM 调用成本）。</li><li><strong>记忆压缩与整理机制</strong>：三层——重要性评分筛选（访问频率、时间衰减、情感强度、信息独特性四因素）、聚类（相似记忆分组生成代表性摘要，原始详情存档）、抽象泛化（具体情景 → 一般规律）；冲突检测用版本化方法（当前地址只留最新版、工作经历保留完整历史）。</li><li><strong>隐私保护：日志脱敏</strong>（实验 3-3）：用本地 Qwen3 0.6B 小模型做 PII 检测与脱敏（本地部署而非云端——日志含敏感信息，送云端就违背初衷）；识别结构化（身份证/银行卡）、半结构化（地址）与自然语言敏感内容（”我的密码是 abc123”）；LLM 脱敏召回率 95%+ 且假阳性显著低于正则；高吞吐场景用”正则快速过滤 + LLM 深度分析”混合策略。</li></ul><h3 id="3-2-RAG-基础：构建-Agent-的知识获取管道"><a href="#3-2-RAG-基础：构建-Agent-的知识获取管道" class="headerlink" title="3.2 RAG 基础：构建 Agent 的知识获取管道"></a>3.2 RAG 基础：构建 Agent 的知识获取管道</h3><ul><li><strong>RAG = 检索增强生成</strong>：把 LLM 的思考生成能力与外部知识库的广度时效性结合（模型训练数据有截止日期，知识库可随时更新）。流程：检索（Retrieval）→ 增强（Augment）→ 生成（Generate）。</li><li><strong>文档分块（Chunking）</strong>：为什么必要——嵌入模型输入长度有限、整篇文档压成一个向量无法精确表达、检索目标是只注入相关部分。三种策略：<strong>固定大小切分</strong>（简单可预测但无视结构）、<strong>递归/结构感知切分</strong>（按章节/段落/句子自然边界，Markdown/HTML 首选，生产默认）、<strong>语义切分</strong>（相邻句子嵌入相似度断崖处下刀，质量高但需额外计算）。块大小与重叠是典型权衡。</li><li><strong>稠密嵌入</strong>：把文本映射到向量空间（语义近则向量近），衡量用余弦相似度（关心方向而非长度）。从 Word2Vec（词汇共现）到上下文感知模型（BERT、BGE-M3，同词不同语境不同向量、支持多语言长文本）。经典例子：”国王”-“男性”+”女性”≈”女王”。<strong>ANN（近似最近邻）算法</strong>（实验 3-4）：ANNOY（树，不支持增量插入，适合静态库）vs HNSW（图，天然支持增量插入，适合动态场景）。</li><li><strong>稀疏嵌入（BM25）</strong>：词袋模型 + 词频饱和（TF，k₁ 控制饱和速度）+ 逆文档频率（IDF，稀有词权重高）+ 长度归一化（b）。BM25 核心逻辑：稀有词单次出现贡献更大（doc 里”蒸馏”TF=3 低于”模型”TF=5，但因更稀有贡献反而更高）。</li><li><strong>混合检索</strong>：稠密懂语义但漏关键词（搜 HTTP-403 返回”服务器错误”泛泛讨论），稀疏精确匹配但读不懂同义词（搜 kitty 找不到 cat）。典型流水线三阶段：<strong>并行检索 → 结果融合 → 神经重排序</strong>（跨编码器精排）。检索质量指标：recall@k（该找的找到了吗，最贴近 RAG）、MRR（找到得够不够靠前）、nDCG（整个排序列表的质量）；注意”检索失败率” = 1 - recall@20 这类口径换算。</li><li><strong>多模态信息提取（三条路）</strong>：<strong>原生多模态处理</strong>（ViT 视觉编码器映射统一语义空间，保真度最高，适合版式复杂文档）、<strong>提取为文本</strong>（OCR/转录 → 纯文本，低成本兼容所有模型但丢失版式图表）、<strong>工具化分析</strong>（文本摘要打底 + analyze_image/analyze_pdf 按需深入）。</li></ul><h3 id="3-3-超越扁平文本：知识的组织与检索"><a href="#3-3-超越扁平文本：知识的组织与检索" class="headerlink" title="3.3 超越扁平文本：知识的组织与检索"></a>3.3 超越扁平文本：知识的组织与检索</h3><ul><li><strong>为什么必须超越扁平文本</strong>（两个案例）：① 黑猫白猫计数问题在知识库尺度上叠加 top-k 截断、检索分数参差、跨文档聚合错位三重障碍；② Xfinity 优惠规则的错误推理——“护士”与”医生”语义相近优先召回案例 B，模型错误推断护士也可享受优惠。结论：必须在索引阶段投入计算资源主动提炼、抽象、结构化。</li><li><strong>结构化索引两条路</strong>：<ul><li><strong>RAPTOR（树状层次摘要）</strong>：计算块间相似度聚类 → LLM 生成父节点摘要 → 递归成知识树。检索可跨层：先宏观定位再向下钻取细节。</li><li><strong>GraphRAG（实体关系图）</strong>：LLM 提取实体-关系三元组构建知识图谱，社区检测划分模块。适合”谁和谁有关？A 如何影响 B？”类关系性问题。局限：三元组提取丢失条件逻辑与时间依赖（”我计划去海滩，如果下雨则去博物馆”被压成孤立事实）、错误提取造成知识污染。<strong>实践推荐分层互补：完整自然语言保存核心信息 + 结构化元数据索引检索 + 垂直场景（医疗问诊、法律分析、家族关系）用图谱专项索引</strong>。</li></ul></li><li><strong>文件系统范式（OpenViking）</strong>：所有上下文（记忆、资源、技能）映射为虚拟文件系统的目录和文件，每个条目唯一 URI（viking://）。核心：<strong>L0/L1/L2 三层按需加载</strong>（L0 摘要约 100 token 判断相关性、L1 概览约 2000 token 供规划决策、L2 全文按需深入），目录下自动生成 .abstract/.overview 文件。选择 Markdown 纯文本而非专用数据库：用户可读可改、Git 版本控制、Agent 可自主记录组织。<strong>关键前提：文件之间必须建立链接与索引</strong>——像 Wikipedia 一样每个条目以链接指向相关条目 + 入口页索引页，否则知识越多越难检索（不同模型主动建链的意愿能力不同）。</li><li><strong>知识库的时效与治理</strong>：知识过期（增量更新，选索引结构有现实后果：ANNOY 不支持增量、HNSW 支持）；失效内容检测与下线（版本号、生效/失效时间元数据，检索阶段过滤或摘要标注”此条已于某日废止”）；<strong>多用户权限与租户隔离——检索必须按调用者权限过滤，绝不能让越权文档进入用户上下文</strong>（权限过滤下推到检索层）。</li><li><strong>智能体化 RAG（Agentic RAG）</strong>：把知识库检索从自动化前置步骤升级为可供 Agent 随时调用的工具，Agent 用 ReAct 循环”思考→行动→观察”主导检索过程——自主决定查询关键词、评估信息是否充分、不足则继续迭代甚至调用其他工具。非智能体化 RAG 只是被动的”检索-生成”管道。</li><li><strong>上下文感知检索（Contextual Retrieval，Anthropic）</strong>：向量化索引前先用 LLM 为每个文本块生成”前缀摘要”（”[本段节选自 ACME 公司 2025 年 Q2 财报]”)，拼回原文再索引——同时增强稀疏（新增可精确匹配关键词）与稠密（注入语义背景）检索。<strong>与第二章”上下文感知压缩”划清界限：一个在索引期做加法（补前缀），一个在运行期做减法（去冗余）</strong>。</li><li><strong>双层记忆架构（用户记忆与 RAG 的交汇点）</strong>：用 Advanced JSON Cards 把少量关键事实结构化后常驻上下文提供”概览”，用上下文感知检索按需从海量原始对话取回”细节”——这是”主动服务”（三层次最高层）在工程上落地的路径。案例：护照过期预警（结构化事实发现日期接近 + 检索确认细节 + 主动建议）。</li><li><strong>从数据集中提取深度知识</strong>：RAG 解决”已有文档如何检索”，但司法判例、医生经验等知识隐藏在结构化案例数据的统计规律中。两阶段：① 知识提取与结构化（LLM 把非结构化案情转成标准化 JSON，自下而上定义 Schema）；② 因子分析与重要性建模（数据分析发现规律，形成可执行的决策逻辑）。从”信息检索”到”知识发现”的飞跃。</li></ul><h3 id="3-4-本章小结"><a href="#3-4-本章小结" class="headerlink" title="3.4 本章小结"></a>3.4 本章小结</h3><p>两个尺度（个体用户记忆 + 共享知识库）构成持久化记忆体系。核心技术栈：分块划定检索单元 → 稠密嵌入捕捉语义 → 稀疏嵌入精确匹配 → 结果融合 → 神经重排序 → recall@k 度量。超越扁平文本：RAPTOR 树状层次、GraphRAG 实体关系网、OpenViking 文件系统范式、上下文感知检索、智能体化 RAG。最终收敛为<strong>双层记忆架构</strong>，真正支撑起三层次框架中最高的”主动服务”能力。</p><hr><h2 id="六、第-4-章：工具"><a href="#六、第-4-章：工具" class="headerlink" title="六、第 4 章：工具"></a>六、第 4 章：工具</h2><p><strong>章节定位</strong>：工具是 Agent 与外部世界交互的桥梁（”手脚”）。核心结论：<strong>工具设计的质量决定 Agent 的能力上限，异步架构决定 Agent 能否在真实世界中可靠运行</strong>。</p><h3 id="4-1-工具的分类（两个审视特征）"><a href="#4-1-工具的分类（两个审视特征）" class="headerlink" title="4.1 工具的分类（两个审视特征）"></a>4.1 工具的分类（两个审视特征）</h3><div class="table-container"><table><thead><tr><th>工具类型</th><th>调用方向</th><th>作用对象</th></tr></thead><tbody><tr><td>感知工具</td><td>Agent 主动调用</td><td>获取信息</td></tr><tr><td>执行工具</td><td>Agent 主动调用</td><td>改变世界</td></tr><tr><td>协作工具</td><td>Agent 主动调用</td><td>与其他 Agent/人协作</td></tr><tr><td>事件触发工具</td><td>Agent 注册、外部触发</td><td>驱动 Agent 开始工作</td></tr><tr><td>用户沟通工具</td><td>Agent 主动调用</td><td>向用户传递信息</td></tr></tbody></table></div><h3 id="4-2-工具设计的通用原则"><a href="#4-2-工具设计的通用原则" class="headerlink" title="4.2 工具设计的通用原则"></a>4.2 工具设计的通用原则</h3><ul><li><strong>能力表达形式：专用工具 vs Skill + 通用执行器</strong>。选择依据三维度：参数复杂度（嵌套对象/多字段联合校验用专用工具结构化 schema）、变更频率（频繁变化用 Skill——改文本远比改代码测试部署轻松）、安全与权限需求。</li><li><strong>工具粒度权衡</strong>：粒度过细 → 工具数量激增（超 100 个最先进模型也易选错）；粒度过粗 → 单个工具复杂。整合标准：功能相似性 + 使用场景重叠度（extract_pdf_text/extract_docx_content/extract_pptx_content → 统一 read_document 加 file_type 参数）。参数集差异大或使用频率极高时保持独立。</li><li><strong>通用性设计</strong>：通用工具优于专用工具，除非有明确的安全/权限/性能理由（code_interpreter 胜过十几个计算器；但生产数据库写操作要专用工具保证权限控制与审计）。<strong>LLM 本身有强大的思考与代码生成能力，应利用而不是限制</strong>——通用工具是”元能力”。但特殊权限、复杂配置、安全风险场景仍要封装专用工具（各平台 grep 语法不同 → 专用 grep 工具）。</li><li><strong>工具描述的艺术</strong>：核心是让 LLM 知道”<strong>什么时候用</strong>“而不只是”能做什么”；<strong>清晰列出边界条件（做不到什么）往往比描述能力更重要</strong>——大多数调用失败的根因是模型不知道工具不能做什么；参数描述用具体例子代替抽象规范（”phone：E.164 格式（国家代码+号码，无空格），例如 +8613888888888”）；返回值要描述清楚；注明执行代价（下载耗时）帮助模型规划调用顺序。</li><li><strong>参数传递的保真性</strong>：两种隐蔽反模式——<strong>静默输入转换</strong>（Cursor 把弯引号静默转直引号，导致模型”看到的内容工具却找不到”，反复失败无法理解）和<strong>静默参数注入</strong>（工具自动附加参数导致 git commit 报错）。原则：<strong>模型感知到的世界与工具操作的世界之间不能存在系统性偏差</strong>。</li><li><strong>工具设计的三代演进</strong>：第一代直接 API 封装（粒度过细）；第二代 ACI 原则（工具对应 Agent 的目标而非底层 API 操作，对标 HCI）；第三代优化工具被调用、串联、发现的方式——<strong>示例驱动调用</strong>（准确调用）、<strong>动态工具发现</strong>（按需注入，不全部塞上下文）、<strong>代码编排执行</strong>（让模型用代码编排调用序列，中间变量留在执行环境，只返回汇总结果——token 消耗可降约两个数量级）。</li></ul><h3 id="4-3-工具生态：MCP-与工具选择的挑战"><a href="#4-3-工具生态：MCP-与工具选择的挑战" class="headerlink" title="4.3 工具生态：MCP 与工具选择的挑战"></a>4.3 工具生态：MCP 与工具选择的挑战</h3><ul><li><strong>MCP（Model Context Protocol）</strong>：Anthropic 2024 年底发布的开放标准，统一 AI 模型与外部工具/数据源的通信协议（”通用的插座标准”）。关键设计：标准化工具描述格式（JSON Schema）、传输层灵活（本地 stdio / 远程 Streamable HTTP）、资源与工具分离（只读资源 vs 可执行工具）。</li><li><strong>工具过多时的应对</strong>：层次化组织（搜索/读取/解析/查询四类，Anthropic 实验：按需检索使 Opus 4 工具使用准确率从 49% 提升到 74%）；从 MCP 到 Skills（MCP 解决互操作，Skills 解决选择过载——用少量通用工具 + 按需加载知识文档替代大量专用工具，把”工具选择”变成”知识检索”）。</li><li><strong>接入第三方 MCP 的风险</strong>：新的信任边界——工具描述投毒、工具遮蔽、凭证管理，需接入前审查、运行时防御。</li></ul><h3 id="4-4-感知工具"><a href="#4-4-感知工具" class="headerlink" title="4.4 感知工具"></a>4.4 感知工具</h3><ul><li>共同挑战：返回信息量远超处理能力 → 工具层集成上下文感知压缩（输出超阈值如 10000 字符时按查询意图压缩）。</li><li><strong>搜索类</strong>：返回结构化候选列表（标题、位置、摘要）而非全文；分页/游标，由 Agent 决定是否翻页。</li><li><strong>读取类</strong>：支持 offset/limit 按需读取；<strong>截断必须显式可见</strong>（”已显示第 1-200 行，共 5000 行”）——静默截断会让 Agent 基于不完整信息做错误判断。</li><li><strong>只读性红利</strong>：可安全缓存（相同查询复用）、可放心并行（同时读五个文件），执行工具没有这种自由。</li><li><strong>多模态感知</strong>：直接返回图像（保留布局、耗 token）vs OCR 转文本（精简但丢空间结构），按内容类型选择。</li></ul><h3 id="4-5-执行工具"><a href="#4-5-执行工具" class="headerlink" title="4.5 执行工具"></a>4.5 执行工具</h3><ul><li><strong>层次化安全设计</strong>：<ol><li><strong>输入验证</strong>：路径遍历攻击（../../etc/passwd）、命令注入（分号/管道符）、参数类型格式。关键是<strong>快速失败</strong>——发现异常立即拒绝，不尝试”智能”修正；</li><li><strong>权限控制</strong>：工作目录限制、禁止命令黑名单（rm -rf /）、API 配额速率限制。注意黑名单只是最基础层——攻击者可用变形命令绕过（$(echo rm) -rf /），需结合语义解析理解命令真实意图（第五章展开）；</li><li><strong>提议者-审核者</strong>：独立模型安全审查（事前审批）。<strong>事后验证的要诀是模态切换</strong>——渲染为视觉输出检查排版、在沙盒实际运行验证配置，单一模态审查易陷入相同盲区；</li><li><strong>Sidecar 机制</strong>：旁路安全检查模块，与主 Agent 流式输出并行运行，独立判断风险，起门控作用；配拒绝熔断器（连续拒绝回退到请求用户手动判断）。</li></ol></li><li><strong>自动验证与反馈闭环</strong>：操作结果可验证就应该自动验证（write_file 后立即跑 linter，结构化错误列表作为返回值）——“执行-验证-反馈”闭环。</li><li><strong>长输出截断与持久化</strong>：超阈值（200 行/10000 字符）只返头尾各若干行，完整结果存临时文件。</li><li><strong>幂等性</strong>：执行工具必须回答”调用被取消/超时时副作用到底发生没有”（转账超时返回失败，钱可能已转出）。两类手段：唯一标识去重（idempotency key）或先查询后变更。<strong>不可幂等操作</strong>（发邮件、打电话、对外转账）用”预检-确认”两段式（第一段只校验预演并返回确认令牌，第二段凭令牌真正执行）。</li></ul><h3 id="4-6-协作工具"><a href="#4-6-协作工具" class="headerlink" title="4.6 协作工具"></a>4.6 协作工具</h3><ul><li>子 Agent 设计哲学：专业化分工（一组专精 Agent 协作优于一个”全能”Agent）。</li><li>子 Agent 提示词关键要素：角色定义清晰（”你是专门负责 XXX 的助手 Agent”）；<strong>上下文来源明确标注</strong>（[FROM_MAIN_AGENT] / [FROM_USER] / [TOOL_RESULT]，防提示注入）；任务边界明确；输出格式标准化（统一 JSON）。</li><li>协作原语三组：<strong>启动与取消</strong>（spawn_subagent / cancel_subagent）、<strong>消息传递</strong>（send_message_to_subagent，双向）、<strong>发现</strong>（list_agents 列出可用 Agent 及职责——与 MCP 的 tools/list 同一思路）。</li><li>协作形态：同步调用、异步调用（事件通知）、流式协作、多轮交互。</li><li><strong>人工介入的艺术</strong>：某些决策点本质上需要人类的价值观、常识或领域专业知识——人工介入本身形成学习闭环（干预样本可回放给 Agent 学习）。</li></ul><h3 id="4-7-事件驱动的异步-Agent"><a href="#4-7-事件驱动的异步-Agent" class="headerlink" title="4.7 事件驱动的异步 Agent"></a>4.7 事件驱动的异步 Agent</h3><ul><li><strong>为什么需要异步</strong>：同步 = “做完一件事才能做下一件”。真实助理场景需要：异步执行是常态、事件优先级动态判断（取消当前/加入队列/并行处理）、中断和恢复流畅性。<strong>根本矛盾：”训练同步/部署异步”</strong>——LLM 训练范式假设发出工具调用后下一条必须是工具结果，而真实部署要求随时可打断、多任务并发。</li><li><strong>OpenClaw 的三种自动化机制</strong>：Hooks（事件钩子，响应生命周期事件）、Cron（定时调度）、Heartbeat（心跳守护，每隔 N 分钟唤醒检查）。局限：三者都是时间/框架驱动，无法即时响应任意第三方事件源（新邮件、外部 API 回调）。</li><li><strong>事件触发工具三类</strong>：<strong>定时器</strong>（set_timer：一次性/循环，处理依赖物理时间的事件——“周一上午 10:00 致电 DMV”）；<strong>后台任务监控</strong>（monitor_shell：监控命令行新增输出或关键词，避免”盯着看”浪费 token 或”等完成”错过严重问题）；<strong>外部事件通道</strong>（connect_channel：新邮件、API 回调、IM 消息实时推送）。设计要点：清晰触发条件与过滤规则（避免无关事件浪费算力）、事件载荷足够上下文（减少唤醒后额外查询）。</li><li><strong>用户沟通工具</strong>：当沟通从 session 内一问一答扩展到多渠道异步消息，”说话”本身成为显式工具调用（OpenClaw 的”活人感”）。支持异步消息模式、已读/未读状态追踪、多模态（结构化卡片、邮件、生成式 UI）。</li><li><strong>虚拟身份与隔离执行环境</strong>：Agent 应拥有独立虚拟身份（专属通讯账号、存储、计算环境）而非直接管理用户账号——一旦 Agent 出错或被攻破，用户全部数字身份会暴露。落地在隔离执行环境（VM/容器、Android 模拟器）。两个现实挑战：反自动化机制（CAPTCHA、IP 信誉检测 → 住宅代理）；访问用户真实账号用 <strong>Human-in-the-Loop 认证</strong>（VNC/RDP 让用户亲自登录，令牌复用平衡自主与安全）。</li><li><strong>事件处理机制</strong>：骨架是<strong>事件循环</strong>（每一轮从输入队列取事件→追加轨迹→调用 LLM→执行工具→回到循环开头）；<strong>事件只在每轮循环的安全点被消费</strong>（LLM 推理中、工具执行中新事件先排队；取消也在安全点检查）。三种策略：<strong>队列式</strong>（常规事件，等安全点批量处理）、<strong>取消式</strong>（紧急事件，主动制造安全点中断）、<strong>并行式</strong>（独立轻量查询另起推理会话，结果标记”与主任务并行执行”）。<strong>结构化事件建模</strong>：每个输入建模为含发送者/来源/类型/内容/时间戳等维度的结构化事件，避免用户输入误当工具结果、工具结果误当用户指令（防注入）。</li><li><strong>如何让同步模型支持异步打断（工程实现）</strong>：常态下让 LLM 看到标准同步轨迹，只在打断时插入占位符修复格式。五条规则：① LLM 输出时立即记录 assistant message；② 工具调用完成时才记录 tool result（轨迹存在”部分完成”状态）；③ 工具执行中的打断生成占位符响应（”工具正在后台执行，请优先处理新事件”）重新调用 LLM；④⑤ 后续恢复。<strong>代价：加剧幻觉风险</strong>（模型从未学会处理”结果还没回来”——训练时工具调用后总紧接着真实结果），因此只在真正紧急时打断，非紧急事件入队。</li><li><strong>前沿方向</strong>：持续思考（continuous-time）Agent——与其在被打断时丢弃半截思考，不如让模型边等边想、边做边想（利用”工具调用几秒内模型可生成上千 token”的白赚算力）。关键发现：<strong>编排让行为成为可能，训练让行为变好</strong>——用”LLM 当裁判”式奖励训练，模型会学藏思考换好评；只有可验证、保信息覆盖度的目标才带来实收益。</li></ul><h3 id="4-8-主动工具发现"><a href="#4-8-主动工具发现" class="headerlink" title="4.8 主动工具发现"></a>4.8 主动工具发现</h3><ul><li>传统全量注入 schema 在工具上千时失效（上下文被说明书塞满、选择精度下降）。检索式预筛选（按初始查询一次性匹配）的局限：任务中途才发现需要跨领域工具链。</li><li><strong>MCP-Zero 思路（Agent 声明缺口、系统按需注入）</strong>：系统提示词不预置工具 schema，Agent 在思考中生成结构化请求块（”GitHub 服务器：搜索仓库并返回元数据”），两层语义路由（服务器级→工具级）从数千候选中匹配注入——约 2800 个工具上比全量注入省约 98% token。工程等价方案：保留少数基础工具 + 一个”工具搜索工具”（Claude Tool Search Tool）。</li><li><strong>层次化匹配与降级</strong>：先按能力描述定位服务器，再在服务器内匹配工具（数千工具 → 数十服务器 × 数十工具）；候选相似度都低于阈值时明确返回”未找到”，让 Agent 改写需求、手工实现或创造新工具。</li><li><strong>动态加载与 KV Cache</strong>：把新工具的完整 schema 追加到上下文末尾（静态前缀保持稳定），状态栏维护简短工具名列表。如今已是 API 原生能力：OpenAI Responses API 的 tool_search + defer_loading、Anthropic Tool Search（Claude Code 对 MCP 工具默认延迟加载）、Codex CLI 的 tool_search（BM25，默认开启）。<strong>澄清：”追加到末尾”只发生在工具被发现的那一轮</strong>，此后固定为历史消息，不会每轮重新搬运。</li><li><strong>Skills：把工具发现变成”按需查阅”</strong>：不需要嵌入索引 + 语义匹配基础设施——Agent 启动只看到 name + description 目录（数百 token），需要时读取完整 SKILL.md 并顺着引用深入。像查工具书一样”用到哪条查哪条”。</li></ul><h3 id="4-9-本章小结"><a href="#4-9-本章小结" class="headerlink" title="4.9 本章小结"></a>4.9 本章小结</h3><p>ACI 原则（粒度、通用性、描述规范）适用于所有工具；MCP 统一互操作；层次化组织 + 动态发现 + Skills 回应工具爆炸；参数传递保真性是底线。五类工具各有侧重（感知=压缩与分页；执行=分层安全+提议者-审核者+Sidecar；协作=生命周期原语+人工介入；事件触发=过滤规则+载荷设计；用户沟通=异步+多渠道+虚拟身份）。</p><hr><h2 id="七、第-5-章：Coding-Agent-与代码生成"><a href="#七、第-5-章：Coding-Agent-与代码生成" class="headerlink" title="七、第 5 章：Coding Agent 与代码生成"></a>七、第 5 章：Coding Agent 与代码生成</h2><p><strong>章节定位</strong>：论证 Coding Agent 加上文件系统是所有通用 Agent 最核心的技术基础；代码是通用 Agent 的<strong>元能力</strong>（能创造其他能力的能力）。</p><h3 id="5-1-Coding-Agent"><a href="#5-1-Coding-Agent" class="headerlink" title="5.1 Coding Agent"></a>5.1 Coding Agent</h3><ul><li><strong>Coding 是 Agent 的基础能力</strong>：几乎所有高效的内容生成最终都要落到代码上——PPT 是 OOXML 格式的代码、Word/PDF 可由代码生成、数据分析用 Python 脚本、GUI 操作序列可固化为 RPA 代码。<strong>代码生成是效率最高、成本最低、可复用性最强的能力基座</strong>。</li><li><strong>七个核心工具</strong>：① Code Interpreter（沙盒执行 Python）；② Bash Shell（终端命令）；③ 读文件；④ 写文件；⑤ 编辑文件；⑥ 文件搜索（glob，按文件名）；⑦ 内容搜索（grep/语义）。一个 TODO 整理任务只需 Grep + Write 两个工具即可完成。</li><li><strong>案例：Manus → OpenClaw</strong>：把 Deep Research、Computer Use、Coding 三大能力融合，凸显”<strong>Coding Agent + 文件系统是开放任务型通用 Agent 最核心的技术基础</strong>“。</li><li><strong>Sessionless 设计</strong>：无安装、无登录、常驻在线，用户通过已有消息平台随时发消息即得响应。大模型已成熟到足以充当”智能基座”（类似操作系统屏蔽硬件，大模型屏蔽语言理解与思考规划的复杂性）。工程难点：<strong>代码执行环境和文件系统状态如何跨消息存活</strong>——OpenClaw 两层管理：文件系统状态天然持久（workspace 挂载在沙盒之外的持久存储）；进程状态按需保活或重建。</li><li><strong>Coding Agent 的安全</strong>：<ul><li><strong>Simon Willison 的”致命三要素”</strong>：① 访问私有数据；② 暴露于不受信任内容；③ 具备外部通信能力——三要素齐备即构成完整攻击闭环（恶意指令藏在不受信任内容 → 读取私有数据 → 经对外通道传出）。<strong>笔者补充第四维度：持久记忆</strong>——攻击者把无害偏见/恶意指令写入长期记忆，跨会话潜伏、适时触发，把一次性攻击升级为长期放大。四类边界：数据边界、输入信任边界、输出影响边界、跨会话边界。全权限本地 Agent（OpenClaw 类）四者兼备，安全是核心挑战。</li><li><strong>命令语义解析</strong>：关键字黑名单形同虚设（子 shell、变量展开可绕过任何静态规则，$(echo rm) -rf /）。生产级 Harness 用语义解析理解命令真实效果——识别”看似无害的标志位消费下一个参数从而隐藏危险载荷”（find -exec rm、curl -o /etc/crontab）。</li><li><strong>推测性执行（让安全检查”隐形”）</strong>：把”展示”与”放行”拆开并行——先显示进度提示，后台同时跑安全检查；先行提示无副作用，检查不通过只需替换为”等待确认”。<strong>安全性不以牺牲用户体验为代价</strong>是 Harness 设计的最高境界。</li><li><strong>信任边界下移（数据层）</strong>：当写代码的和跑代码的都可能不可信时，真正可靠的约束不能待在被生成的代码里，而要待在下面那层人类审查过的地基里（如数据库 schema 级不变量保证——“不可能错”而非”更可能对”）——“约束优先于指导”原则在数据层的终极形态。</li></ul></li><li><strong>Coding Agent 的整体流程</strong>：项目文档化（生成 CLAUDE.md 项目指南）→ 需求理解与澄清 → 设计文档（方案对比，提交设计等审批）→ 编码与测试（old_str→new_str 修改、修复失败测试重跑）→ 审查与交付（自审可读性/安全/性能）→ 文档同步（架构级改动后更新文档——过时的文档比没有文档更糟糕）。<ul><li><strong>指令文件（CLAUDE.md 等）</strong>：项目级系统提示词，承载面向 Agent 的行为约定（构建测试命令、代码风格、禁区”不要改动 migrations/ 目录”）。与 SOUL.md（Agent 是谁）、MEMORY.md（跨会话经验）同一思路。最经济的稳定前缀，对 KV Cache 友好。推论：<strong>对远程工作友好的团队也对 AI Agent 友好</strong>——评估团队 AI-ready 程度的代理指标：一个远程新人只靠代码仓库和文档能否独立工作。</li></ul></li><li><strong>Harness 工程在 Coding Agent 中的实践</strong>：Coding 是所有 Agent 任务中<strong>可验证性最高</strong>的一类（测试、类型、linter、Git 都有现成基础设施）。落地组件：验收基线（测试套件/CI/审查标准）、执行边界（模块边界/依赖规则/权限）、反馈信号（linter/测试/类型检查）、回退手段（Git/沙盒/快照）。<strong>可迁移的设计原则</strong>：① 约束优先于指导（能用代码强制的规则就不要用文档建议——“做不了” vs “建议别做”）；② 验证要自动化（人工审查不可扩展）；③ 反馈越快越好、越结构化越好。LangChain 方法论：<strong>用 Agent 分析失败轨迹来改进 Harness</strong>，让 Harness 工程从人工经验驱动转向数据驱动；Anthropic：长任务拆为初始化 Agent（分解任务清单）+ 执行 Agent（逐步推进、中间成果留档）两角色。</li><li><strong>故障与错误恢复（四层故障分类）</strong>：API 层（限流 429、超时、连接中断、输出截断）；工具层（幻觉调用、参数畸形、执行异常、<strong>反复返回同一错误而模型不改地重试</strong>）；上下文层（窗口溢出、压缩失败、轨迹结构损坏）；控制流层（<strong>死循环</strong>反复执行无进展、<strong>死亡螺旋</strong>错误触发的恢复逻辑自身又调 LLM 连锁出错）。<ul><li>检测：先分类再计数——可重试错误（限流/过载/网络抖动）重试才有意义，不可重试错误（参数不合法/权限不足/工具不存在）必须改变输入或策略。维护”错误→恢复策略”映射表。模式检测：<strong>重复调用指纹</strong>（工具名+参数相同即无进展循环信号）、连续失败计数。流式连接最危险失败模式是<strong>静默卡死</strong>（连接成功但数据流停止，SDK 超时往往只覆盖初始连接）——需要独立空闲看门狗。<strong>每个长连接都需要活性信号</strong>。</li><li>恢复：分级升级；错误路径上禁用一切会再次调用模型的副作用逻辑（防递归死亡螺旋）；全局终止条件（最大迭代轮数、会话预算上限、连续失败超阈值升级人工干预）。</li><li>核心结论：<strong>Agent 的可靠性不取决于它犯不犯错，而取决于每类错误是否都有对应的检测、恢复与终止路径</strong>。</li></ul></li><li><strong>实现技巧</strong>：并行工具调用 + 流式执行（第一个工具调用参数一完整即开始执行，与后续调用生成重叠）+ 级联中止（某调用失败终止同批依赖它的调用，不波及其他）；环境信息动态注入（当前工作目录、git 分支、最近提交、未暂存/已暂存变更——作为 Agent 状态栏追加而非硬编码进静态提示词）；<strong>命令执行环境状态持久化</strong>（维护持久终端会话，保留工作目录、环境变量——符合人类开发者习惯）。</li><li><strong>搜索工具（互补工具箱）</strong>：正则内容匹配（grep 精确文本）、文件名匹配（glob 路径模式）、语义代码搜索（自然语言 → 向量+BM25 混合）、<strong>符号级定义/引用查找（LSP）</strong>——能区分同名符号的定义和调用，代码重构的关键（重命名不能只靠文本搜索，函数名可能出现在注释/字符串中）。策略：”从粗到细、从语义到语法”。</li><li><strong>文件编辑工具（五种方案）</strong>：LLM 输出 diff 描述（关注点分离但微小偏差致错位）、旧字符串→新字符串（可预测无歧义，大段删除需全输出）、行号定位（大段操作高效但长文件数行号易错）、类 Vim 编辑命令（重组代码高效但语法学习负担大）、<strong>字符串首尾匹配</strong>（只提供要删内容的开头几行和结尾几行，框架匹配定位——综合可靠性与效率，主流自建推荐）。业界代表：Claude Code 用 old→new 字符串（可靠优先），Cursor 用 Apply Model 专用 fast-apply 模型（吞吐优先）。</li></ul><h3 id="5-2-代码：通用-Agent-的元能力（六个方向，由内向外）"><a href="#5-2-代码：通用-Agent-的元能力（六个方向，由内向外）" class="headerlink" title="5.2 代码：通用 Agent 的元能力（六个方向，由内向外）"></a>5.2 代码：通用 Agent 的元能力（六个方向，由内向外）</h3><ol><li><strong>代码作为思考工具</strong>：LLM 在精确计算、符号操作、严格逻辑推导上有根本短板（概率性近似 vs 确定性精确）。分工：LLM 理解问题写代码，代码解释器精确计算（集合论题目：纯自然语言推理易错，代码推理精确可验证）。Wolfram 洞察：符号计算系统与 LLM 互补。</li><li><strong>代码作为业务规则的约束</strong>：”约束：编码化而非文档化”。自然语言规则有歧义（”7 天”是自然日还是工作日？”购买”是下单还是发货？），代码无歧义、可执行、确定性。实践结合：系统提示词保留自然语言规则供理解和沟通 + 关键决策点配代码化校验工具作”守门员”。<strong>三重保障</strong>：① 自然语言规则帮助理解解释；② 工具描述与 expected_<em> 参数作 checklist 引导模型调用前显式核对；③ <em>*服务端基于数据库真值的代码化校验作最后守门员</em></em>（政策事实一律查库、时间取服务端时钟、绝不采信模型自报值——最后防线必须建立在模型无法伪造的数据之上）。实验 5-3：Qwen3-4B 通过代码化知识显著提升复杂政策执行准确性。</li><li><strong>代码驱动的多媒体生成</strong>：PPT 创作重新框定为代码生成问题（Slidev：Markdown+HTML 定义内容）。关键机制：<strong>提议者-审核者</strong>——Proposer 逐页生成代码，Reviewer 渲染截图用 Vision LLM 检查（文字溢出、布局拥挤、字体过小），迭代到达标。视频讲解：PPT 生成 + 口语化讲解文字 + TTS + ffmpeg 合成。视频剪辑：粗粒度（每 10 秒截图）→ 精细粒度（每秒截图）两级定位场景区间，生成 Blender API 脚本，Reviewer 检查关键帧。</li><li><strong>代码作为系统适配器</strong>：外部服务没有现成 SDK、文档缺失、返回格式非标准时，Agent 当场读文档/观察真实响应、即时生成适配代码（HTTP 客户端、鉴权、解析非标准结构）。延伸：无 API 系统先 Computer Use 操作界面、再把成功序列固化为 RPA 代码。日志自适应解析：格式变化时自动检测失败 → 生成新解析代码 → 自动测试 → 热更新。生产日志诊断：读日志 + 架构文档 + PRD 定位问题 → 生成结构化问题报告和回归测试用例 → 经 MCP 创建 GitHub Issue 全自动化。</li><li><strong>代码作为生成式 UI</strong>：动态生成表单、交互式图表、完整 Web 应用。<strong>A2UI（Agent-to-User Interface）声明式界面协议</strong>——Agent 不直接生成可执行代码，只输出”界面描述清单”（JSON），客户端用预先准备好的安全组件渲染（”顾客只能点菜单上有的菜”）。安全优先：客户端维护受信任组件目录，防注入/XSS。<strong>Artifact 模式</strong>：数据直达前端（图表直接绑定数据源，绕过”数据经过 LLM 抄写”的低效与出错）。结合热加载（HMR）实现对话式界面实时定制（”千人千面”）。</li><li><strong>代码创造代码：Agent 自举（bootstrapping）</strong>：Agent 用代码修复和创建与自己同类的 Agent（自我修复、自我复制、按需生成）。案例：doctor —fix 自我诊断修复（确定性检查覆盖常见问题 + LLM 兜底疑难长尾）。让 Agent 编写 Agent 的关键技巧：提供架构模式参考代码、复制脚手架保留循环框架/消息格式/KV 优化、定向修改业务逻辑、验证测试。常见缺陷：上下文管理随意（未用标准结构化消息）、工具设计粗糙、安全缺失。<strong>自举引入的偏差会代际累积吗？——第八章的验证/发布/回滚机制是防退化答案</strong>。</li></ol><h3 id="5-3-本章小结"><a href="#5-3-本章小结" class="headerlink" title="5.3 本章小结"></a>5.3 本章小结</h3><p>代码不只是写程序的工具，它是 Agent 形式化思考和精确表达的语言。Coding Agent 成熟度高不是因为代码生成模型特别强，而是因为软件工程几十年攒下的基础设施（测试、类型系统、版本控制）天然构成一套强大的 Harness。代码的价值：完成任务的手段 + 积累知识、创造工具、优化自身的机制。</p><hr><h2 id="八、第-6-章：Agent-的评估"><a href="#八、第-6-章：Agent-的评估" class="headerlink" title="八、第 6 章：Agent 的评估"></a>八、第 6 章：Agent 的评估</h2><p><strong>章节定位</strong>：构建科学评估方法论。核心问题：怎么判断 Agent 真的变好了？评估体系三层：评估环境（在哪里测）→ 评估方法（怎么判）→ 评估驱动决策（测了干什么）。贯穿主题：可观测性、仿真环境、内部评估。</p><h3 id="6-1-6-2-评估环境"><a href="#6-1-6-2-评估环境" class="headerlink" title="6.1-6.2 评估环境"></a>6.1-6.2 评估环境</h3><ul><li><strong>评估五要素</strong>：数据集（初始状态+目标+参考解）、环境状态（真实性与可控性平衡：退款不超过订单金额 + 每次测试可重置）、工具接口（原子操作而非高层抽象，迫使 Agent 规划组合）、评分标准 Rubric（二元/连续/多维）、执行协议（交互模式与终止条件）。</li><li><strong>工具调用型环境（Verifiers）</strong>：验证基于可执行标准（测试通过、答案匹配），不依赖人类标注或模型评判。层次化：SingleTurnEnv（单轮）、ToolEnv（多轮工具循环）、StatefulToolEnv/SandboxEnv（有状态、长时沙盒）。</li><li><strong>人机交互型环境（τ-bench / τ²-bench）</strong>：核心设计原则是<strong>渐进式信息透露（Progressive Information Disclosure）</strong>——大多数 benchmark 一开始全盘托出需求，但现实中用户只会说”我的航班好像有问题”。τ-bench 用<strong>用户模拟（User Simulation）</strong>：另一个 LLM 扮演用户按剧本逐步透露信息、回应询问。双重验证：数据库最终状态检查 + 对话关键信息字符串验证；任务层面汇总为二元奖励（全过才 1 分）。τ²-bench 增量：<strong>双控环境</strong>（用户模拟器也能操作共享环境，Agent 需观察到用户侧变化）与更精确的组合式任务生成。</li></ul><h3 id="6-3-评估任务数据集的设计（五挑战）"><a href="#6-3-评估任务数据集的设计（五挑战）" class="headerlink" title="6.3 评估任务数据集的设计（五挑战）"></a>6.3 评估任务数据集的设计（五挑战）</h3><ol><li><strong>明确性与开放性的张力</strong>（GAIA：概念简单、实现路径开放）；</li><li><strong>真实性与可控性平衡</strong>（SWE-Bench → Verified：人类专家筛出 500 个高质量任务）；</li><li><strong>多样性与系统性协调</strong>（AndroidWorld：116 任务 × 20 应用，标注核心能力标签，参数化生成变体）；</li><li><strong>评估成本与覆盖范围</strong>（GAIA 精选 466 题分三级难度；SWE-Bench Verified 从 2294 筛到 500，成本降约五分之四）；</li><li><strong>数据泄漏防范</strong>（GAIA 靠答案独特性 + 专属附件文件；SWE-bench-Live 靠时间新鲜度；τ²-bench 动态参数生成；Terminal-Bench 嵌入金丝雀 GUID 使泄漏可检测）。</li></ol><ul><li><strong>任务描述精确性</strong>：每个元素机械化可验证（Terminal-Bench “build-linux-kernel-qemu”：启动日志出现自定义消息才算成功，无法伪造输出蒙混过关）；AndroidWorld 参数化模板（每次随机参数）。</li><li><strong>复杂度层次化</strong>：GAIA 三级（L1 一两个工具 vs L3 复杂组合，人类 87.3% vs GPT-4 0%）——不同层次失败指向不同改进方向（提示工程 vs 规划机制 vs 分层架构/后训练）；τ²-bench 业务复杂度分层（查询→多步流程→故障诊断→策略判断）。</li><li><strong>可验证性</strong>：SWE-Bench Verified 的 FAIL_TO_PASS（证明修复了）+ PASS_TO_PASS（证明没引入新 bug）双重验证；τ²-bench 多层检查（数据库状态+对话关键词+流程合规性）；OSWorld 134 个独立评估函数深入检查文件系统/进程/网络/应用内部状态。</li><li><strong>数据质量控制与迭代</strong>：SWE-Bench Verified 93 名开发者人工评估、29% 通过率、标准化标注指南；OSWorld → OSWorld-Verified 是迭代改进典范（15 个月暴露 300+ 问题，四类修复策略，云平台 50 倍并行加速，轨迹公开到 HuggingFace 形成持续改进循环）。</li></ul><h3 id="6-4-评估指标体系"><a href="#6-4-评估指标体系" class="headerlink" title="6.4 评估指标体系"></a>6.4 评估指标体系</h3><ul><li><strong>过程指标</strong>：行动合法率（无效操作 vs 越权操作）、工具调用正确率（参数语义合理）、路径效率（步数/冗余动作/回退次数）、检索覆盖率、成本与延迟（请求数、token、墙钟时间）。</li><li><strong>结果指标</strong>：Pass@k（k 次尝试至少成功一次的概率——能力上限）、<strong>Pass^k（k 次全部成功的概率——稳定性）</strong>、Best@k（最好一次得分——质量上限）。例：单次成功率 60%，Pass@5 ≈ 99% 而 Pass^5 ≈ 7.8%。<strong>回归测试用 Pass^k，探索性评估用 Pass@k，混用会导致误判</strong>。</li></ul><h3 id="6-5-自动化评估方法"><a href="#6-5-自动化评估方法" class="headerlink" title="6.5 自动化评估方法"></a>6.5 自动化评估方法</h3><ul><li><strong>LLM-as-a-Judge + Rubric</strong>：开放式任务（客服对话、报告撰写）用 LLM 评判。好 Rubric 四准则（Scale AI）：基于专家指导（示例+边界案例）、全面覆盖（所有重要维度）、标准重要性权重（Essential/Important/Veto 否决项）、自包含评估（每个评价项独立可操作、不依赖评判者领域知识——“引用了至少两个权威理论”优于”展示了深刻理解”）。主动防范<strong>奖励作弊（Reward Hacking）</strong>：惩罚幻觉、讨好、关键词堆砌、回避问题。Rubric 是迭代产物（收集评判分歧逐步完善为判例集）。</li><li><strong>配对比较与模型排名</strong>：Elo 评分（Bradley-Terry 模型的在线更新形式；爆冷带来更大分数调整）；Chatbot Arena 匿名随机对决（不需要绝对标准，但结果取决于用户问什么问题）。<strong>位置偏差（Position Bias）</strong>：评判模型系统性偏向先出现的候选——缓解：交换顺序各评一次取平均，或两次一致才计入。</li></ul><h3 id="6-6-评估驱动的模型选型"><a href="#6-6-评估驱动的模型选型" class="headerlink" title="6.6 评估驱动的模型选型"></a>6.6 评估驱动的模型选型</h3><ul><li>关键维度：<strong>Prefill vs Decode 两阶段</strong>（Prefill 决定 TTFT 首字延迟、上下文越长越慢；Decode 决定出字速度、直接决定思考时长——50 tokens/s 生成 2000 思考 token 要 40 秒）；输入/输出吞吐量、思考延迟（不同模型思考 token 数差数倍，且与效果不一定正相关，要实测）、p95 尾部延迟（比均值更能反映体验）、成本（便宜但成功率低的模型因重试可能实际更贵——算每个任务平均成本与成本-性能比）、性能指标取舍（日常看 Pass@1、关键操作看 Pass^k、探索看 Pass@k/Best@k）、速率限制与鲁棒性。</li><li><strong>Agent 系统成本分析（三层次）</strong>：模型推理成本（<strong>上下文累积效应</strong>——第 1 轮 1000 token、第 2 轮 2000、第 3 轮 3000，总量 6000 而非 3000，KV Cache 是关键；思考 token 也计费）、工具调用成本（外部 API 费用、<strong>工具结果注入上下文后的反复计费</strong>——一次搜索返回 2000-5000 token 每轮都算输入）、基础设施成本（向量库、消息队列、日志追踪）。</li><li><strong>评估驱动的持续迭代</strong>：模型选择不是一次性决策。”新模型比旧模型强吗？好多少？切换成本是什么？”——有评估体系的团队数小时内给出答案：在自有评估集上跑新模型，对比成功率/工具调用正确率/延迟/成本，可能得到”简单任务迁移降低成本、复杂任务保留原模型保质量”的差异化策略。</li></ul><h3 id="6-7-6-11-统计显著性、可观测性与内部评估"><a href="#6-7-6-11-统计显著性、可观测性与内部评估" class="headerlink" title="6.7-6.11 统计显著性、可观测性与内部评估"></a>6.7-6.11 统计显著性、可观测性与内部评估</h3><ul><li><strong>统计显著性</strong>：二项分布标准误 √(p(1-p)/n)——100 用例成功率 70% 时标准误 ≈4.6%，95% 置信区间 ≈ ±9 个百分点；”73% vs 70%”的 3 个百分点差异完全在噪声带宽内（独立假设下差值标准误 ≈6.5%）。<strong>多次运行取均值</strong>（每个配置 3-5 次不同随机种子），报告均值与波动范围。</li><li><strong>可观测性</strong>：执行追踪树（Trace：任务+耗时+成本）、监控仪表盘（成本追踪、P50/P95/P99 延迟、工具成功率、异常模式检测——“task#892 循环调用 search 14 次”）。挑战：数据量与隐私权衡、因果归因复杂、多 Agent 追踪、实时防护与事后分析平衡。</li><li><strong>从 Benchmark 报告到系统改进（假设案例全流程）</strong>：观察诊断报告（总体 88% 但 math_counting 0%、Wi-Fi 操作 0%）→ 能力标签矩阵揭示共同特征（transcription 暴露视觉理解缺陷、complex_ui_understanding 依赖标准 UI 模式）→ 三层改进框架假设（表层 H1/H2 导航提示与 UI 规则；中层 H3 修复多模态管道、H4 全局思考；深层 H5 换更强模型、H6 加 UI 元素树）→ 分阶段验证（每配置 5 次×116 任务）→ 数据驱动决策：H1+H3 明确部署、<strong>H4 全局思考不可接受</strong>（为 8% 的任务让全部任务承担 3 倍延迟成本，”杀鸡用牛刀”）、<strong>H6 优于 H5</strong>（瓶颈不在模型思考能力而在输入信息充分性）、H5+H6 组合最高但只适合关键异步任务选择性启用 → 持续迭代（新报告出现新失败模式 → 新假设 H7 条件化启用思考、H8 扩展动作空间）。<strong>方法论：观察→假设→实验→验证→新认识→新假设，把 Agent 工程从经验驱动的”炼金术”转向数据驱动的科学工程</strong>。</li><li><strong>内部评估基础设施（OpenClaw 实践）</strong>：① 消融基础设施（总开关禁用多个主要特性创建”裸模型”基线——发现”特性债务”，每个主要特性都应可独立关闭，消融开关必须在启动路径极早期注入）；② AB 测试方法论（多臂而非二元、<strong>区分机制指标和目标指标</strong>——“缩短计划文件长度”是机制、”降低会话级成本”才是目标、设置护栏指标、记录基线统计）；③ 双层特性开关（编译时开关物理移除代码、运行时开关服务端下发本地缓存）；④ 提示词敏感性评估（系统提示可确定性渲染、版本化快照、每次变更跑回归——像代码变更跑 CI）；⑤ 隐私感知的分析（类型系统强制——分析接口只接受特殊类型包装的值，”类型名本身就是审计线索”）。</li><li><strong>仿真环境：从评估到后训练的桥梁</strong>：评估的终点是改进，改进的最强形态是训练。评估环境 → 仿真环境的核心区别：交互频率远高（百万次 vs 千次）、需要随机化（防死记硬背）、必须即时反馈。<strong>评估资产无缝转成训练信号：一套定义清晰的 Rubric/验证器本质上就是一个可验证奖励（RLVR）的奖励函数</strong>。训练的新要求：可靠的 reset 语义（数百万 episode 每个都要干净初始状态）、远高于评估的吞吐。<strong>领域随机化（Domain Randomization）</strong>是缩小 sim-to-real gap 的关键（物理参数、视觉外观、传感器噪声大范围随机）。</li></ul><h3 id="6-12-本章小结"><a href="#6-12-本章小结" class="headerlink" title="6.12 本章小结"></a>6.12 本章小结</h3><p>评估形成完整闭环：评估环境 → 数据集 → 自动化评估方法（LLM-as-a-Judge + Rubric）→ Benchmark 分析揭示改进方向 → 系统改进 → 更新评估环境与数据集。评估是 Harness 中”验证”功能的系统化实现。评估体系是第七章（评估环境与数据转成后训练输入）和第八章（轨迹评价转成知识/指令/程序/参数更新）的共同基础。</p><hr><h2 id="九、第-7-章：模型后训练"><a href="#九、第-7-章：模型后训练" class="headerlink" title="九、第 7 章：模型后训练"></a>九、第 7 章：模型后训练</h2><p><strong>章节定位</strong>：深入 SFT 与 RL 技术。两条主线：<strong>主线一——SFT 记忆、RL 泛化</strong>（先形后神：SFT 先立”形”（格式结构），RL 再求”神”（策略泛化））；<strong>主线二——数据和环境比算法更重要</strong>（先验 &gt; 环境 &gt; 算法）。</p><h3 id="7-1-预训练、SFT、RL-三阶段全景"><a href="#7-1-预训练、SFT、RL-三阶段全景" class="headerlink" title="7.1 预训练、SFT、RL 三阶段全景"></a>7.1 预训练、SFT、RL 三阶段全景</h3><ul><li><strong>预训练</strong>：预测下一个词（Next Token Prediction）。模型输出本质是概率分布，”训练”就是调整这个分布。在海量互联网文本上反复猜下一个词，被迫学会语法、事实、逻辑乃至基本推理。预训练后模型”博学却不好用”——它没学会”被提问时应回答”这个协议。</li><li><strong>SFT 的本质：换了数据的”预测下一个词”</strong>。与预训练只有两点差别：① 数据不同（人工”输入-输出”对，格式统一为”用户提问→理想回答”）；② <strong>损失只算在”回答”上（loss masking，损失屏蔽）</strong>——不希望模型学”怎么提问”，只学”怎么回答”。SFT 记忆：优化目标是让标注回答每个 token 概率尽可能高，即”把标准答案背下来”。能力边界钉死在示范数据上。<strong>固化的是”格式、风格、流程”这类协议性知识，而非事实性知识</strong>（后者靠预训练或 RAG）。</li><li><strong>LoRA（参数高效微调）</strong>：冻结大权重矩阵，旁边挂低秩”补丁”，参数仅占 1%-5%，接近全参效果且扰动小。实践经验：应用到所有主要权重矩阵（尤其 MLP 层，只加注意力层会掉点）；学习率约为全参微调 10 倍；SFT 用中高 rank（64-256）、RL 用小 rank（8-32 甚至 1）。一台推理服务器可同时加载多个 LoRA 多租户。</li><li><strong>为什么必须先 SFT 后 RL</strong>：RL 不看标准答案，靠模型自生成回答 + 奖惩；可要判断好坏，首先得能解析输出——格式混乱（JSON/工具调用都吐不齐）奖励函数无从算起。SFT 先把”话说利索”，RL 才有能打分的起点。边界：较小基础模型 + 严格结构化输出时”必须先 SFT”成立；强基模可直接 RL（DeepSeek-R1-Zero 自行涌现反思与长链思考，但输出可读性差，最终仍加回”冷启动 SFT”立稳”形”）。<strong>“先形后神”</strong>。</li><li><strong>SFT vs RL 本质区别（最重要的一张表）</strong>：<ul><li>SFT：优化最大化标注答案概率（极大似然）；唯一标准答案、每个 token 都有监督；学到固定映射 → <strong>记忆</strong>（J/Q/K 训练时当 10，测试变 11 照旧用 10）；</li><li>RL：优化最大化期望奖励；自己生成多条回答 + 每条一个成败信号；学到”怎样的过程能得到正确结果”的更通用策略 → <strong>泛化</strong>（J 变 11 用同一策略重算）。</li></ul></li></ul><h3 id="7-2-7-3-经典-RL-Agent-到现代-Agent（可选阅读）"><a href="#7-2-7-3-经典-RL-Agent-到现代-Agent（可选阅读）" class="headerlink" title="7.2-7.3 经典 RL Agent 到现代 Agent（可选阅读）"></a>7.2-7.3 经典 RL Agent 到现代 Agent（可选阅读）</h3><ul><li>RL 五要素：动作空间、策略、奖励信号、价值函数、环境模型（基于模型 vs 无模型）。</li><li><strong>两种范式最根本差异：动作空间</strong>——MDP 假设有限封闭动作集，LLM 的动作空间是开放、组合爆炸的自然语言序列。</li><li><strong>MDP 的根本局限</strong>：样本效率低（Q-learning 10000 次试错只需 10 秒在游戏里，但真实世界每次打电话有成本、每次操作有延迟，完全不可接受）、泛化差、无法利用先验知识。</li><li>OpenAI 范式演进三阶段：算法中心主义（2015-2016）→ 环境的重要性（2016-2018）→ <strong>先验的觉醒（2018-至今）</strong>：先验知识可通过与 RL 完全无关的方式获得（语言预训练）。</li></ul><h3 id="7-4-7-5-SFT-实践与决策"><a href="#7-4-7-5-SFT-实践与决策" class="headerlink" title="7.4-7.5 SFT 实践与决策"></a>7.4-7.5 SFT 实践与决策</h3><ul><li><strong>SFT 数据三条路</strong>：人工专家示范（质量天花板最高、贵且慢，做”种子数据”）；教师模型生成（合成数据，强模型批量产出后过滤蒸馏）；模型自举（<strong>拒绝采样微调</strong>：同一问题采样 k 条候选 → 验证器筛选正确样本 → SFT 训练自己，STaR/RFT 核心循环）。量级：数千到数万条高质量样本足够，<strong>“与其堆十万条脏数据，不如精修一万条干净数据——数据里的每一处噪声，SFT 都会忠实地写进参数”</strong>。</li><li><strong>Prompt 蒸馏</strong>：把”长提示 + 思考型教师”的行为压缩到”短提示 + 非思考学生”——训练数据只保留用户输入与最终结论，学生学会”直接给出结论”，延迟费用显著降低。两维度：”大到小”、”思考到非思考”。</li><li><strong>何时选 SFT / RL 决策框架</strong>：先试 SFT（固化格式、协议性知识、统一风格；不适合注入大量事实知识——那要预训练或 RAG）；SFT 不够时加 RL（需要泛化到新场景、探索最优策略、标注成本过高）。<strong>很多场景下只要 SFT 数据质量到位根本不需要 RL</strong>——RL 又贵又不稳定（常是 SFT 的几十到上百倍成本）。Anthropic 例证：2025 年前后训练主配方是高质量 SFT + RLAIF，并不依赖 RLVR。</li></ul><h3 id="7-6-单轮强化学习：记忆与泛化的对照"><a href="#7-6-单轮强化学习：记忆与泛化的对照" class="headerlink" title="7.6 单轮强化学习：记忆与泛化的对照"></a>7.6 单轮强化学习：记忆与泛化的对照</h3><ul><li><strong>AdaptThink（学会”何时不思考”）</strong>：NoThinking 模式在简单问题上性能相当甚至更好，只有困难问题 Thinking 优势才显现——用 RL 训练模型学会按需分配思考。</li><li><strong>GeneralPoints 卡牌算术（SFT vs RL 对照）</strong>：SFT 训练集 100%、OOD 测试崩盘；RL 通过探索发现超越示范的通用策略（”J 变 11 时用策略重算”），OOD 大幅领先。<strong>“SFT 记忆、RL 泛化”不是口号，而是可测量现象</strong>。GP-VL 视觉变体同样成立。</li></ul><h3 id="7-7-RLHF：从人类偏好到奖励模型"><a href="#7-7-RLHF：从人类偏好到奖励模型" class="headerlink" title="7.7 RLHF：从人类偏好到奖励模型"></a>7.7 RLHF：从人类偏好到奖励模型</h3><ul><li><strong>InstructGPT 三段式管线</strong>：① SFT（人工示范建立指令遵循）；② 训练奖励模型 RM（人类标注员两两比较”哪个更好”——比较比打分可靠得多；Bradley-Terry 模型训练）；③ RL 优化（PPO，带 KL 惩罚）。</li><li><strong>为什么用反向 KL 惩罚</strong>：把当前策略摁在参考模型（SFT 模型，”说人话、格式正常”的安全区）附近。反向 KL 是 <strong>mode-seeking（寻峰）</strong>——允许模型只保留少数高奖励”峰”、果断丢掉其余模式（这正是 RL 后模型更”笃定”、多样性更低的原因）。不加的后果：<strong>reward hacking</strong>（模型钻奖励漏洞刷高分而非真做好任务——RM 分数单调上升而人类评估先升后降，Goodhart 定律：指标一旦成为优化目标就不再是好指标）与<strong>分布崩塌</strong>（输出退化成重复乱码）。</li></ul><h3 id="7-8-强化学习算法比较"><a href="#7-8-强化学习算法比较" class="headerlink" title="7.8 强化学习算法比较"></a>7.8 强化学习算法比较</h3><ul><li><strong>记住主线二：现成算法会用、能选对就够了，真正决定成败的是数据和环境</strong>。算法已封装进 veRL、TRL 等框架。</li><li><strong>PPO</strong>：价值网络估计优势 + 裁剪限制单步更新幅度（防止策略一步跑偏）；<strong>GRPO</strong>：省去价值网络，用”组内相对比较”估计优势（比同组平均好为正、差为负）——成本更低。注意区分两件事：<strong>奖励从哪来</strong>（规则验证器 RLVR / 学习到的奖励模型 RLHF / 人类偏好）与<strong>用什么算法优化</strong>（PPO 和 GRPO 对奖励来源不挑剔，真正差异在优势估计方式）。</li></ul><h3 id="7-9-数据与环境：比算法更重要的事（全章最想让你记住的一节）"><a href="#7-9-数据与环境：比算法更重要的事（全章最想让你记住的一节）" class="headerlink" title="7.9 数据与环境：比算法更重要的事（全章最想让你记住的一节）"></a>7.9 数据与环境：比算法更重要的事（全章最想让你记住的一节）</h3><ul><li><strong>环境：模型练习的场地</strong>。”环境失真，策略必废”——仿真里客服固定套路回话，模型学到只在仿真里管用的”应试策略”，一上线就露馅；这是 RL 项目最常见的翻车方式。构建高保真环境常常比训练本身更贵更难（真实 API 有速率限制、会封号、有副作用，必须造”影子世界”）。</li><li><strong>造不出环境怎么办：让模型扮演环境</strong>。两个层次：① 模型合成工具返回值（ZeroSearch 用 LLM 扮演搜索引擎，课程式设计——训练初期返回高质量文档、逐步掺噪声逼学生适应不完美结果，最终直接对接真实搜索依然良好）；② 模型仿真整个环境动态（DreamGym 蒸馏出”经验模型”预测状态转移）。<strong>风险：模拟器的世界知识就是训练的天花板，模拟器的系统性偏差会被策略照单全收</strong>。</li><li><strong>数据：最关键的一环，质量胜过一切</strong>。”Garbage in, garbage out 在后训练里体现得淋漓尽致。”SFT 一字不差地把噪声偏见固化进参数；RL 朝着有偏差的奖励拼命优化（reward hacking 温床）。数据质量三维度：覆盖度（任务分布的多样性）、平衡度（避免单一腔调）、标注准确性（思维链蒸馏里错误思考过程会被学生一并模仿）。<strong>拒绝采样</strong>是把标注准确性拉满的标准动作。</li><li><strong>Agentic 数据生成（Autodata）</strong>：主 Agent 协调 challenger（生成任务）/弱求解器/强求解器/verifier 四角色，寻找”强模型能解决、弱模型仍有困难、评价器又能可靠判断”的任务——把推理算力转化为当前能力前沿的新训练数据。<strong>与动态采样（改预算分配）不同，它改变的是任务分布本身</strong>。</li><li><strong>那什么时候才轮到算法</strong>：合理用力顺序——先选强基础模型 → 打磨环境和数据 → 最后才在算法和超参上做边际优化。</li></ul><h3 id="7-10-从单轮到多轮：信用分配与奖励设计"><a href="#7-10-从单轮到多轮：信用分配与奖励设计" class="headerlink" title="7.10 从单轮到多轮：信用分配与奖励设计"></a>7.10 从单轮到多轮：信用分配与奖励设计</h3><ul><li><strong>多轮任务核心挑战</strong>：跨步骤状态、延迟奖励、<strong>信用分配困难</strong>（10 步流程前 9 步完美只第 10 步出错，信号只是”整个任务失败了”）。”当前 RL 方法只能从最终成败结果中学习，却无法从环境给出的丰富反馈中学习”（Silver &amp; Sutton）。</li><li><strong>奖励信号两个设计维度</strong>：密度（二元/稀疏/过程奖励）与表示形式（标量/向量/生成式）。<strong>过程奖励（PRM）</strong>对每个关键步骤即时反馈（评估从黑盒转白盒），但标注成本高、可能过度约束创新；<strong>结果奖励（ORM）</strong>只评估最终结果，探索自由度大但样本需求高。奖励范式演进：标量（无诊断能力）→ 半标量（有依据但粗粒度）→ 向量（分维度）→ <strong>生成式奖励</strong>（自然语言讲理由的评判——把”为什么好、为什么差”讲出来，可扩展到开放任务）。DeepSeek 三步行训练生成式 RM：自动生成评价原则 → 生成评判 → 迭代。</li><li><strong>实践中的信用分配</strong>：折扣因子 γ 在多轮 LLM RL 中通常设为 1；PPO 依赖 GAE（价值网络估计”这一步比预期好多少”）；GRPO 把整条 response 视为单一动作、轨迹级优势均摊到所有 token（第 2 轮精准提问与第 7 轮无效寒暄拿到相同信用——长程多轮任务中稀释学习信号，这是带价值网络的 PPO 仍有价值的原因）；<strong>turn-level 分摊</strong>（以”轮”为单位计算优势）是当前常见折中。</li><li><strong>奖励结果，约束过程：验证路径惩罚（RLVP）</strong>。问题：有一类<strong>与结果无关的约束</strong>（outcome-neutral constraints）——不要反复拨打已拒接的用户、不要在非工作时间行动、不要跳过身份验证、不要执行 rm -rf、不要为通过测试改测试文件——违反它们往往让”表面成功率”更高（抄近路更快），所以纯结果奖励不但学不会反而主动激励违反。核心洞察：<strong>真实环境是”不对称的验证器”</strong>——坏动作有明确确定特征（容易验证”坏”），而”是否朝目标取得有意义的进展”很难验证。配方：<strong>奖励结果，惩罚路径（R = O + β·Φ）</strong>。可验证惩罚永远能补回方差（全败组内部”失败得规不规矩”各不相同，梯度就活了）；可验证进展奖励（Partial Credit）只在”进展可达”时有用（定理证明的”待证目标数下降”可达；软件修复的”通过测试比例”常常不可达）。实验结果（TerminalBench）：每局违规次数从 3.71 降到 0.66（约 6 倍）而成功率持平；全败组比例从 65% 降到 8%。</li></ul><h3 id="7-11-RL-学习工具调用"><a href="#7-11-RL-学习工具调用" class="headerlink" title="7.11 RL 学习工具调用"></a>7.11 RL 学习工具调用</h3><ul><li>三层挑战：长时序信用分配（一次最终成功要归因到几十步前的决策）、环境工程（稳定可复现可并行的训练环境）、<strong>对环境反馈 token 做损失屏蔽（loss masking）</strong>——工具调用轨迹里既有模型生成 token 也有环境返回 token（代码解释器输出、搜索结果），后者不是策略生成的，计入梯度会训练模型去”预测沙盒会输出什么”，必须屏蔽。ReTool、Search-R1、veRL、AWorld 都内置此机制。</li><li><strong>ReTool（代码解释器增强数学解题）</strong>：AIME 2024 上 Qwen2.5-32B 400 步达 67.0%，纯文本 RL 基线 1080 步只有 40.0%。涌现能力：代码自我修正、工具调用从后期验证转为早期探索。</li><li><strong>DAPO 的改进</strong>（常用）：Token-Level Policy Gradient Loss（每 token 权重相等，长回答按长度获得相称梯度贡献）、Dynamic Sampling（集中算力于成功率 20%-80% 的”可学习区间”）、Overlong Reward Shaping（惩罚冗长思考）。</li><li>多工具质变：单工具只需决定”何时/如何”调用；多工具还要解决”调用哪个/如何组合”——前置依赖、互斥约束、成本差异，策略需要整体规划而非贪心选择。</li></ul><h3 id="7-12-提升样本效率的前沿探索"><a href="#7-12-提升样本效率的前沿探索" class="headerlink" title="7.12 提升样本效率的前沿探索"></a>7.12 提升样本效率的前沿探索</h3><ul><li><strong>为什么样本效率低</strong>：model-free 不建模环境动态，难以直接利用单次反馈里的丰富信息（客服明确说”需要信用卡后四位”，人类听到一次就记住，model-free RL 只能靠数百次随机探索偶然尝试到）。</li><li><strong>On-Policy Distillation（在轨蒸馏）</strong>：SFT 的短板是 <strong>Learner-Sampler Mismatch</strong>（训练时教师走、部署时学生自己走，学生犯错走到没见过的偏差状态就不知道怎么回正轨——“只背过标准答案的学生中间算错就找不回来”）；RL 的短板是信号稀疏。OPD 让学生自己生成轨迹（在轨，解决分布不匹配）+ 更强的教师对学生每一步逐 token 打分给出完整分布（稠密信号）。一句话对照：SFT = 离轨+稠密（有分布不匹配），RL = 在轨+稀疏（反馈稀疏），<strong>OPD = 在轨+稠密（两个短板都补上）</strong>。效果：达到同等性能训练步数只要纯 RL 的约 1/10，还顺带缓解过拟合（每次轨迹不同，学到通用策略而非特定答案）。</li><li><strong>On-Policy Self-Distillation（OPSD，在轨自蒸馏）</strong>：没有更强教师时，让同一模型分饰两角——教师版看”特权信息”（标准答案、系统提示、领域文档，”对着答案讲题远比独立解题容易”），学生版只见问题。两个优势：不依赖可验证奖励（特权信息来源更宽）、监督信号比 RL 密集得多。边界：收益大小取决于”特权信息能带来多少额外能力”（答案来自穷举搜索而非可语言解释的推理时没有信号来源）。</li></ul><h3 id="7-13-7-14-完整图景与常见陷阱"><a href="#7-13-7-14-完整图景与常见陷阱" class="headerlink" title="7.13-7.14 完整图景与常见陷阱"></a>7.13-7.14 完整图景与常见陷阱</h3><ul><li><strong>协同范式</strong>：SFT 固化协议与结构 → 格式稳定即止（过度训练导致模型塌缩到训练分布，限制 RL 优化空间）→ RL 优化策略与泛化。</li><li><strong>常见陷阱</strong>：① 过度依赖后训练记忆事实（应交给 RAG——可动态更新、可追溯、不遗忘）；② 格式未稳定就引入 RL（JSON 解析失败率超 20% 时 RL 完全失败）；③ 奖励函数不当导致奖励黑客；④ 忽视小规模验证（先在 100 条上验证环境与奖励，快速失败）。</li><li><strong>与 RAG/ICL 协同</strong>：ICL 零参数即时适应但随上下文增长延迟费用上升；RAG 把事实与证据放外部；后训练把高维感知、风格、隐式策略写入参数。选择依据：能力能否被外部符号充分表达（医疗影像识别、自然语气 → 参数；长期稳定转账规则 → 代码确定性保障）。</li><li><strong>章节结论</strong>：SFT 和 RL 是先后关系而非竞争关系；<strong>数据和环境比算法更重要</strong>；当前 RL 主要瓶颈是样本效率——OPD（让每步信号更密集）与 RLVP（把被浪费的环境反馈变成可学习信号）是最有希望的方向。<strong>共同点：把环境和数据里本就存在、却被纯结果奖励浪费掉的信息，重新变成模型能学的东西</strong>。</li></ul><hr><h2 id="十、第-8-章：Agent-的持续进化"><a href="#十、第-8-章：Agent-的持续进化" class="headerlink" title="十、第 8 章：Agent 的持续进化"></a>十、第 8 章：Agent 的持续进化</h2><p><strong>章节定位</strong>：研究如何把 Agent 的运行经验转化为下一版本的能力。起点是”评价”而非”总结”——错误的评价一旦进入长期知识/系统提示/训练数据，影响会跨后续任务不断放大。</p><h3 id="8-1-从运行轨迹中获得学习信号"><a href="#8-1-从运行轨迹中获得学习信号" class="headerlink" title="8.1 从运行轨迹中获得学习信号"></a>8.1 从运行轨迹中获得学习信号</h3><ul><li>结果验证（测试、订单状态）可靠，但<strong>结果正确不代表过程正确</strong>（删除失败测试也能让测试通过；口头承诺”7 天内退款”也能得到暂时满意反馈）——可靠评价既要看结果，也要检查达成结果的路径。</li><li>开放任务用 LLM-as-a-Judge，但不能只给模糊总分——<strong>预先定义 Rubric、逐项给分、引用轨迹证据、证据不足时明确表示不确定</strong>。</li><li><strong>三层验证结构</strong>：底层结果验证器（”事情是否真的办成”——测试结果、数据库状态、工具返回，最依赖代码与环境真值）；中层过程验证器（”是否以允许的方式办成”——业务规则、权限、动作序列）；上层质量验证器（”是否办得合适”——Rubric 评语言与策略）。<strong>越往下越依赖代码和环境真值，只有难以形式化的部分才交给 LLM</strong>。</li></ul><h3 id="8-2-Agent-持续进化的四种方法（更新载体选择）"><a href="#8-2-Agent-持续进化的四种方法（更新载体选择）" class="headerlink" title="8.2 Agent 持续进化的四种方法（更新载体选择）"></a>8.2 Agent 持续进化的四种方法（更新载体选择）</h3><p><strong>首要依据不是经验出现多久，而是目标能力能否被某种载体自然表达</strong>：</p><div class="table-container"><table><thead><tr><th>载体</th><th>适合</th><th>形式</th><th>特性</th></tr></thead><tbody><tr><td><strong>知识</strong></td><td>事实、经验与例外</td><td>Markdown / 知识库</td><td>易更新、可追溯</td></tr><tr><td><strong>指令</strong></td><td>可语言化的判断原则</td><td>Prompt / Skill</td><td>指令性强</td></tr><tr><td><strong>程序</strong></td><td>确定性流程与强约束</td><td>工具 / 工作流 / Harness</td><td>可重复执行</td></tr><tr><td><strong>参数</strong></td><td>高维感知与隐式策略</td><td>SFT / 蒸馏 / RL</td><td>内化、低推理开销</td></tr></tbody></table></div><ul><li><strong>经验沉淀为知识</strong>：与第三章共享存储检索技术，但知识来源不同——第三章提取”用户与世界是什么样的”，本章提取”在什么条件下应该怎样做”。原始轨迹不适合做知识单元（长而嘈杂）。三层数据：不可变原始轨迹（审计）+ 单次运行分析记录 + 跨轨迹比较归纳成 Markdown 文档（写清适用场景、推荐策略、禁止做法、例外条件、证据来源、最近验证时间）。<strong>User-as-Code 两阶段思想复用：先保存证据，再离线生成可变知识</strong>。</li><li><strong>经验写成指令（系统提示学习，Karpathy）</strong>：多条轨迹反复揭示同一种策略错误且可用自然语言清楚表达时，从”可参考经验”提升为”应遵守规则”。作用于几乎所有任务的规则进系统提示词；只在一个领域生效的复杂流程写 Skill/项目指令文件。修改方式：<strong>最小 diff + 注明作用域 + 检查与现有规则矛盾 + 在边界案例和旧任务保留集上评估</strong>（不是反复重写整份提示）。Karpathy 把这种”遇到问题、想通方法后用明确语言提醒未来的自己”的新范式暂称 System Prompt Learning——与 RL 都从经验改进行为，但前者编辑文字、后者梯度下降。Claude 约 1.7 万词系统提示中专门要求”遇到单词/字母/字符计数问题先逐项编号显式计数”正是为处理 strawberry 数 r 这类问题。<ul><li><strong>Skill 学习</strong>：候选 Skill 应说明何时加载、前置条件、操作步骤、已知陷阱、验证方法并保存来源轨迹；先在已有 Skill 库搜近似能力——相同流程优先局部 patch，只有出现新的独立能力才创建新目录（避免库中堆满名称不同内容近似的手册）。Anthropic Skill Creator：”起草—测试—评价—修订”循环；真正困难的是”哪些运行证据足以触发生成、如何处理冲突”。</li></ul></li><li><strong>经验写成程序</strong>：稳定、重复、可验证的操作编译为工作流/工具/Harness 代码。可修改对象远不止新工具：操作层（浏览器轨迹编译为参数化工作流）、控制层（工具路由、重试、熔断、压缩策略）、验证层（新增参数检查、状态验证器、回归测试）、架构层（增加 Reviewer Agent）。<ul><li><strong>浏览器工作流生命周期（类似宏录制）</strong>：捕获轨迹（动作 + 元素定位证据 XPath/CSS/aria-label）→ 参数化（收件人/主题/正文是变量，稳定动作不变）→ 定义状态检查（动作前检查、动作后检查、<strong>最终状态检查必须读取真实页面或后端状态——动作执行成功 ≠ 任务成功</strong>）→ 候选验证（沙盒重置后完整回放，全部通过才发布为 validated；有副作用任务没有安全重置回调只能存候选供审计）→ 匹配回放（Playwright 直接执行，不需逐步调 LLM）→ <strong>失效与重学</strong>（找不到元素/状态检查不通过立即停止，旧版本移到 invalid 区，回退到完整 Agent 重新探索）。</li><li><strong>Self-Harness（修改 Harness 代码）</strong>：候选生成器输入不止失败案例，还要提供<strong>必须保留的成功行为</strong>（哪些性质不能在修复时破坏）和<strong>此前被拒绝的修改记录</strong>（避免换一种说法重复提交已失败的方案）——失败证据 + 成功约束 + 历史尝试构成有边界的候选空间。每次编辑执行前声明影响预测，由下一轮结果验证——“分数上涨才能与某个具体机制建立联系”。</li><li><strong>工具创造（Alita 案例）</strong>：Agent 发现缺字幕读取能力 → 搜索测试 youtube-transcript-api → 封装为新字幕工具 → 安全扫描、功能测试、后续任务复用都通过才进能力库。</li></ul></li><li><strong>经验写入参数</strong>：医疗影像理解、自然的语音韵律、消除”AI 味”、长程规划等能力难压缩成规则——必须后训练。<strong>是否参数化不由”任务是否长期稳定”单独决定</strong>（新影像设备的域偏移仍可能需要 LoRA；快速变化的语言风格可用周期性偏好训练——稳定性影响更新频率和成本，但能力表示性质决定载体）。进入训练前仍需去隐私、过滤错误轨迹、保留独立回归集；训练后检查通用能力和安全对齐是否遗忘。<strong>参数学习通常与外部方法协同</strong>（医疗影像：参数学视觉表征 + 知识库供最新指南 + 代码测量计算）。</li><li><strong>从更新产物到更新”更新方法”（优化尺度分层）</strong>：单条规则/记忆 → 结构化上下文 → 工作流 → Harness 代码 → 产生候选方案的优化器代码。最内层（只改产物内容）作用面小、易归因回滚，是默认选择。警惕”反复重写整份 Prompt 导致旧版本重要细节逐渐消失”的退化——<strong>Agentic Context Engineering（ACE）</strong>把上下文维护成带稳定标识符的条目集合，增量更新 + 确定性合并去重；<strong>Meta Context Engineering（MCE）</strong>拆内外双循环（内层给定管理方法优化上下文产物，外层修改搜索/选择/过滤/格式化这些上下文操作本身）。</li></ul><h3 id="8-3-构建可长期运行的持续进化闭环"><a href="#8-3-构建可长期运行的持续进化闭环" class="headerlink" title="8.3 构建可长期运行的持续进化闭环"></a>8.3 构建可长期运行的持续进化闭环</h3><ul><li><strong>双循环结构</strong>：<strong>在线执行循环</strong>只完成任务并记录证据、不直接改写正式 Agent；<strong>离线进化循环</strong>聚合轨迹、诊断根因、生成候选修改、通过验证门槛发布新版本。两者通过版本化经验库和评估集连接。</li><li><strong>从问题定位到经验沉淀</strong>：同一表面问题可能需要不同修改方式（客服编造事实可能是知识库缺事实，也可能是 Prompt 没要求引用——先定位根因，再选最小、最容易验证和回滚的修改对象）。证据不足的偶发故障不立即触发学习，继续积累样本。策略随经验升级：经验文档 → 知识 → Skill/工具/参数。</li><li><strong>验证、发布与回滚</strong>：所有修改先产生候选而非直接覆盖生产版本（知识文档验证检索后是否提高新任务表现；Prompt/Skill 检查边界案例与旧任务回归；程序在沙盒重置环境跑测试；参数更新检查遗忘/安全/分布外任务）。验证通过后灰度发布，关键指标恶化自动回滚。<strong>区分两种经常混在一起的能力</strong>：Harness 更新能力（从轨迹产生有价值的持久修改）vs Harness 受益能力（任务 Agent 找到、激活并正确使用这些修改）——一个 Skill 写得完全正确但弱模型没加载/加载后没遵循，成绩看起来就”没有进化”，不能只用端到端分数反推更新器好坏。</li><li><strong>可验证闭环的边界：当”完成”不等于”进步”</strong>：开放式科研、战略规划、复杂产品设计的评价信号来得慢、正确答案不唯一。自动科研暴露三类问题：<strong>实现漂移</strong>（方案变难时 Agent 退回训练数据中更熟悉但偏离假设的实现）、<strong>认识论上的过度乐观</strong>（把噪声解释成发现、忽略阴性结果）、<strong>隐性判断力不足</strong>（不知道什么基线重要、哪个异常值得追踪、何时放弃假设）。解法：结论与证据分离（Chain-of-Evidence 每类声明链接可审计来源）、<strong>保留负面结果</strong>（失败实验写不可变日志、与成功同检索地位，否则进化模块反复探索已证伪路径）、维护搜索多样性（保留暂时低分但不同质的分支）、让人类在更高层介入（定义问题、审查评价标准、决定何时停止）。</li><li><strong>持续进化的安全边界（三道）</strong>：① 证据与指令隔离——原始网页和工具输出是不可信证据，须经 LLM 总结才能写入；写入用版本控制 + pull request + 不同源 reviewer LLM 审阅；② 候选能力与正式能力隔离——新产物先进不可服务真实流量的候选区，代码和外部依赖过沙盒、权限检查、供应链扫描与行为测试；③ <strong>安全机制不可自我修改</strong>——业务 Agent 可以改 Prompt/Skill/知识库/工具，但不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志和稳定版本备份（否则一个 Agent 只需降低测试阈值就能把退化伪装成进步）。</li><li><strong>睡眠学习（离线整合）</strong>：在线 Agent 负责完成任务并追加不可变证据；后台学习进程在空闲期或满足门控条件时读取一批新经历，比较新旧结论、合并重复、解决冲突、提出候选更新并运行回归。五步周期：触发（时间/轨迹数/容量/错误频率门槛 + 无高优先级在线任务）→ 定向（读取已有能力与不可修改边界）→ 采集与整合（寻找新信号、合并重复、优先局部补丁）→ 验证与审批（迁移集/保留集/安全集评估，高风险写入等人工批准）→ 修剪与索引（过期/被推翻能力标为过期归档删除，保留来源与回滚版本）。案例：Claude Code 自动记忆（MEMORY.md 索引 + 分主题详细文件、容量约束、分层加载）；某开源框架（USER.md + SQLite/FTS5 历史会话检索 + 按需加载 Skill + 独立 Curator 跟踪 Skill 使用/陈旧/归档 + 审批门控 + 快照回滚）。</li></ul><h3 id="8-4-本章小结"><a href="#8-4-本章小结" class="headerlink" title="8.4 本章小结"></a>8.4 本章小结</h3><p>持续学习是 Agent 最重要的能力之一，但今天的模型还无法自行完成可靠的持续学习（推理时上下文适应不自动持久化，未经验证的在线参数更新会放大噪声、攻击和能力漂移）——<strong>现阶段更可行的路径是在模型外围建立可验证的学习系统</strong>。闭环在结果可自动验证的任务上最可靠；目标模糊、反馈延迟的开放任务，人仍需参与问题定义和评价标准制定。</p><hr><h2 id="十一、第-9-章：多模态与实时交互"><a href="#十一、第-9-章：多模态与实时交互" class="headerlink" title="十一、第 9 章：多模态与实时交互"></a>十一、第 9 章：多模态与实时交互</h2><p><strong>章节定位</strong>：展望 Agent 从文本世界走向物理世界。三个场景（语音、Computer Use、机器人）表面差异悬殊，但共享同一演进线：<strong>实时感知、低延迟决策、持续交互</strong>——从串行管道向端到端模型演进，从分离的快慢思考走向”边想边说/边想边做”。</p><h3 id="9-1-9-2-语音：最自然的人机接口-三种范式"><a href="#9-1-9-2-语音：最自然的人机接口-三种范式" class="headerlink" title="9.1-9.2 语音：最自然的人机接口 + 三种范式"></a>9.1-9.2 语音：最自然的人机接口 + 三种范式</h3><ul><li>语音是带宽最高、最自然的交互方式（说话速度约为打字的四倍，不占用双手视线）。两类产品：语音输入法（口述转写替代键盘）与语音 Agent（语音即交互本身）。进阶用法 <strong>whisper coding</strong>——口述指挥编程/研究 Agent。</li><li><strong>OpenAI 2026 年 GPT-Live 给出的三分法</strong>（对应 ChatGPT 语音三代架构）：<ol><li><strong>级联（Cascaded）</strong>：ASR → LLM → TTS 串行流水线。信息在模型间传递丢失、回应缓慢生硬；</li><li><strong>端到端全模态（Omni）</strong>：单一模型直接”听音频、想回复、说出来”。延迟更低、韵律情感保留，但<strong>仍假设”轮流说话”</strong>（轮次切换靠静音判断，稍一停顿或背景噪音就误判插话）；</li><li><strong>全双工/交互式（Full-Duplex/Interactive）</strong>：模型边听边说，每秒做许多次”该说/该听/该停/该打断/该调工具”的决策，彻底取消”轮流”假设（2024 Kyutai Moshi 研究先声，2026 GPT-Live 带到 1.5 亿用户）。</li></ol><ul><li>贯穿三代的主线：<strong>如何摆脱”轮流说话”这个假设，摆脱 VAD 对轮次的猜测</strong>。</li></ul></li></ul><h3 id="9-3-范式一·级联流水线（Cascading）"><a href="#9-3-范式一·级联流水线（Cascading）" class="headerlink" title="9.3 范式一·级联流水线（Cascading）"></a>9.3 范式一·级联流水线（Cascading）</h3><ul><li>四阶段串行：VAD（语音活动检测，500-800ms 静音阈值判”说完”——第一层延迟）→ ASR → LLM → TTS。总响应时间：空载最优约 950ms、最差 2300ms；投入生产后<strong>排队延迟非线性飙升</strong>（总延迟 ≈ 空载延迟 × 1/(1-利用率)）。</li><li><strong>全链路流式化</strong>（2025 年生产主流）：ASR 边听边转、LLM 按句切分输出、TTS 句级流式合成——三级从接力棒变成流水线上同时开工的工位，端到端延迟压到 600-800ms。<strong>但 VAD 的静默等待压不掉</strong>（靠静音阈值猜测”说完没有”是流水线开工前提）。</li><li><strong>流式语音感知：替代 VAD + ASR</strong>。传统 VAD+ASR 三个根本问题：延迟累积（必须等静音）、信息丢失（只输出有声/无声，情绪语气犹豫全丢；停顿稍长被误判截断、背景噪音误触发、附和”嗯”无法判断打断还是认可）、准确率下降（音频切片破坏上下文连续性——“john dot smith at gmail dot com”被切段后 smith 可能被误识别）。流式模型关键：编码器因果/分块 + 解码增量（Whisper 不能流式是因为编码器要完整 30 秒音频段）。新一代感知层输出<strong>语音事件标记流</strong>（<interrupt> 区分真想打断 vs 附和/噪音、<emotion:happy/frustrated>、<laugh>/<sigh>、<music>/<noise>）——把轮次判断从静音时长升级到语义层面。</li></ul><h3 id="9-4-范式二·端到端全模态（Omni）"><a href="#9-4-范式二·端到端全模态（Omni）" class="headerlink" title="9.4 范式二·端到端全模态（Omni）"></a>9.4 范式二·端到端全模态（Omni）</h3><ul><li>单一模型合三为一；隐空间可在文本之外传递副语言信息；延迟更低、韵律情感保留；代价是训练数据需求更大、可解释性差。<strong>端到端的优势主要体现在延迟上，准确率维度不必然占优</strong>——<strong>自级联（self-cascade）</strong>对照：答案主要由语义内容决定、中间文本足以承载任务信息时，自级联准确率相当乃至更优（感知弱的模型上尤其明显）；答案高度依赖非语言线索时端到端占优。设计原则：<strong>决定性能的关键往往不在于是否引入中间表示，而在于该瓶颈承载的信息</strong>（把中间文本升级为附带副语言标记的结构化表示，端到端优势随之收窄）。</li><li>但 Omni 仍保留”轮流说话”假设——依赖 VAD 划分发言权。Step-Audio 2：直接处理原始音频、理解”怎么说”（副语言信息），副语言理解基准 83.09% 大幅领先同期开源全模态模型（44.18%）。</li></ul><h3 id="9-5-范式三·全双工交互模型（Full-Duplex-Interactive）"><a href="#9-5-范式三·全双工交互模型（Full-Duplex-Interactive）" class="headerlink" title="9.5 范式三·全双工交互模型（Full-Duplex / Interactive）"></a>9.5 范式三·全双工交互模型（Full-Duplex / Interactive）</h3><ul><li>场景例证：同声传译（边听边译）、节奏游戏（持续追踪音乐流）——输入是永不停歇的连续流，轮次模式的前提（听、想、动分置不同时间片）根本失效。</li><li><strong>Moshi（Kyutai 2024）</strong>：并行建模两条音频流（用户声音 + 模型自己的声音）+ “内心独白”文本流提升语言质量；任意时刻都在收听，重叠说话/随时打断成天然行为，无需显式打断检测，端到端延迟约 200ms。</li><li><strong>Thinking Machines Lab 的交互模型（Interaction Model）</strong>：交互性不该以外挂 harness 环绕模型，而应内建于模型本身——“要让交互性随智能一同扩展，交互性就必须成为模型本身的一部分”。架构上是<strong>微轮次（micro-turn）</strong>：以约 200ms 为一段持续”读入 200ms、生成 200ms”，音频/视频/文本流无缝切换。</li><li><strong>快慢分工成为主流</strong>：GPT-Live 把实时交互与深度思考解耦（交互模型负责维持对话流动，把复杂任务委派给后台前沿模型 GPT-5.5，用户按需在”快”与”深”之间取舍）；xAI Grok Voice “Think Fast”、Pine AI 同路线。务实理由：<strong>前沿推理模型每几个月迭代一次，把两者塞进同一个模型等于追不断移动的靶子</strong>——只训练轻量交互模型在前台，永远能用上当下最强的”大脑”。</li></ul><h3 id="9-6-思考架构的取舍：从分离到统一"><a href="#9-6-思考架构的取舍：从分离到统一" class="headerlink" title="9.6 思考架构的取舍：从分离到统一"></a>9.6 思考架构的取舍：从分离到统一</h3><ul><li>核心矛盾：实时响应（毫秒级）vs 深度思考（秒级）。三种方案是设计取舍而非线性迭代：<ul><li><strong>方案一：快思考应付、慢思考回答</strong>——快思考 500ms 内给简短应付（”让我想想”），慢思考后台 5-10 秒深度思考后补完整答案（推理时计算扩展 test-time scaling）。致命问题：<strong>自相矛盾</strong>（0.5s 说”价格不错建议购买”，8s 后说”缺国际漫游不适合”）→ 用户失去信任；简单问题过度思考。</li><li><strong>方案二：快思考交互、慢思考提醒</strong>——慢思考通过 Agent 状态栏向快思考提供建议而非直接对用户说话（快慢并行、不直接冲突，慢思考退居幕后当”军师”）。GPT-Live 委派、Pine AI 都是生产实例。局限：快思考可能不听指挥（两个独立实例沟通间接模糊）；无法获知中间思考结果（10 秒思考中产生的大量中间结论快思考完全看不到，打断后只能靠自己）；<strong>无法实现”边想边说”</strong>（人类是”想一段说一段”，方案二快思考只能说填充词干等）。</li><li><strong>方案三：端到端思考与表达统一（Step-Audio R1 双脑架构）</strong>：两个互补机制——<strong>MGRD 模态锚定思考蒸馏</strong>先解决”想得对不对”（现有音频模型存在”文本代理思考”问题：思考链越长性能反而越差，因为模型在基于文本转录做语义思考而非分析声学特征——判断歌曲情绪看”歌词提到悲伤”而不是”小调旋律+下行音高”。MGRD：采样筛选基于声学特征的思考链 → 音频 CoT + 文本思考联合 SFT → RLVR 复合奖励迭代）；<strong>MPS 双脑架构</strong>再解决”说得及不及时”（构思脑持续生成思考、表达脑并行表达，延迟 80 token→零延迟，实现低延迟边想边说）。前者是后者的前提。</li></ul></li><li><strong>快慢之间的接口：文本之外还能传什么</strong>——<strong>潜空间桥（Latent Bridge）</strong>：冻结快慢两个模型，只训练它们之间一个几千万参数的小”桥”，把慢模型隐层结论投影成”潜 token”拼进快模型输入（绕开”想法→文字→再理解”的往返）。Atari 游戏上比文本通道高 26%-82%，每步只多约 5 毫秒。诚实的边界：<strong>快慢协作有没有用取决于任务瓶颈在”想不想得到”还是”来不来得及反应”</strong>（慢思考本来比快反应强时桥才帮得上忙，跨游戏相关性 r≈0.9）。</li></ul><h3 id="9-7-更像人的语音合成"><a href="#9-7-更像人的语音合成" class="headerlink" title="9.7 更像人的语音合成"></a>9.7 更像人的语音合成</h3><ul><li>传统 TTS 的”完美”恰恰是问题：过于流畅、零停顿、无填充词的语音一听就是机器。人类的不完美（停顿、填充词”嗯/呃”、偶尔重复）是思考过程的自然外化，传递”我正在想””我不太确定”。</li><li>解法：<strong>把”在哪停顿、用什么语气”的决策权交给主 LLM</strong>——LLM 输出文本 + 控制标记（[THINKING] 插入 1-2 秒思考停顿和填充音、[SEARCHING] 搜索性填充词、[EMO:happy] 调整语气、[SPEED:0.8x] 控制语速），TTS 作为多模态生成器把标记渲染成非语言音频（嗯…、叹气、轻笑、吸气）。</li><li>实现两条路：自研 TTS 原生支持控制标记（灵活但需专业团队）；voice cloning（为虚拟人准备数十条不同情绪/语速/风格参考语音，按标记选最匹配的调用 TTS API，几周部署——实验 9-5 用 Fish Audio 3-10 秒参考语音零样本克隆，24 条参考库覆盖情绪×语速×风格）。</li></ul><h3 id="9-8-Computer-Use：GUI-自动化-Agent"><a href="#9-8-Computer-Use：GUI-自动化-Agent" class="headerlink" title="9.8 Computer Use：GUI 自动化 Agent"></a>9.8 Computer Use：GUI 自动化 Agent</h3><ul><li>核心循环：截图 → 多模态模型思考+输出动作 → 执行层操作 → 等待响应再截图。三个关键设计维度：<strong>动作空间、视觉定位（Grounding）、模型架构</strong>。</li><li><strong>动作空间设计（Anthropic 三类工具）</strong>：GUI 操作（鼠标 click/move、键盘 type/key/hold_key、滚动 scroll）、感知动作（截图缩放、光标位置、wait 等界面稳定）、可选文本/URL 操作。</li><li><strong>视觉定位两大思路</strong>：① 把定位变成<strong>选择题</strong>（先标注元素编号，模型从封闭集合中选——“像考试选择题比填空题容易”）：纯视觉标注 <strong>Set-of-Mark（SoM）</strong>（分割模型切候选区域叠编号，无需 DOM，适用于原生桌面软件/游戏）vs <strong>结构化元素索引</strong>（DOM/Accessibility Tree 枚举可交互元素编号，browser-use 实现，适合标准 Web 应用）；② <strong>纯坐标预测</strong>（模型直接”看”着截图报坐标——注意训练分辨率与实际屏幕的缩放映射：按宽高比选目标分辨率 → ImageMagick 缩小 → 推理 → 坐标按比例放大 → xdotool 执行）。</li><li><strong>能看动画、能听声音的 Computer Use（Agent-Computer Observation Interface, AOI）</strong>：把观察（连续、自适应、多模态）从动作（离散）里解耦出来，做成无需重训的感知中间件。三个”按需开闸”部件：<strong>帧间关键帧捕获</strong>（廉价像素门跳过几乎没变的画面 + 小模型判断有意义变化才截帧）、<strong>音量门控语音转写</strong>（有声音才调语音识别——Agent 第一次”长出耳朵”）、<strong>把帧叙述成持久的文字</strong>（模型把捕获帧描述成一句话，即使原图被清理出上下文、文字仍留记忆里）。<strong>反直觉发现：真正起作用的是”把帧叙述成能长期留存的文字”——文字才是 LLM Agent 最擅长处理的模态</strong>。八个模型上无需重训 +17 到 +48 个百分点。但感知方案没有银弹，部件要按模型逐个挑选。</li><li><strong>移动端：生态壁垒比技术更难</strong>——技术差异（无障碍服务 API、触摸手势语义）都好解决；真正的障碍是<strong>商业模式冲突</strong>：传统互联网应用靠流量与注意力变现（广告、推荐、冲动消费），Agent 代替用户操作直接绕过变现链路（AI 不关注广告、不冲动消费）。对靠广告流量变现的平台，Agent 每次操作都在侵蚀其商业模式根基——这是结构性的利益冲突，比 CAPTCHA 等技术对抗更难调和。</li><li><strong>实时性：尚未解决的核心挑战</strong>：OSWorld 上准确率已接近人类水平，但 OSWorld-Human 效率研究揭示：Agent 完成同样任务操作步骤明显多于人类，且<strong>每一步推理延迟随任务推进持续增长</strong>（上下文越长决策越慢）。根本原因：串行”截图-思考-点击”循环 + <strong>完全不会”提前想”</strong>。目前没有系统性解法；但”用快慢解耦把’慢’藏起来”已是一个可用答案（语音 Agent + Computer Use 双 Agent：快 Agent 维持对话、慢 Agent 操作浏览器——“一边打电话说话、一边让电脑自己操作”，中位延迟 0.58s vs 8.64s、快约 15 倍而成功率不降；抽掉快慢之间的文本通道成功率立刻塌到 0——<strong>那份”纯文本契约”本质上就是全书反复讲的 Agent 状态栏</strong>）。</li></ul><h3 id="9-9-机器人操作：从实时控制到训练与泛化"><a href="#9-9-机器人操作：从实时控制到训练与泛化" class="headerlink" title="9.9 机器人操作：从实时控制到训练与泛化"></a>9.9 机器人操作：从实时控制到训练与泛化</h3><ul><li><strong>硬件不是瓶颈，算法才是</strong>：XLeRobot 成本不到 1000 美元的双臂轮式机器人，人类 VR 遥操作（延迟 100-200ms）下已能流畅完成大量家庭任务。边界：触觉传感缺失、灵巧手可靠性与成本仍是公认硬件短板；论证限定在”以视觉反馈为主”的任务范围内。</li><li><strong>双层架构：规划与控制的分离</strong>——慢的长程规划（”把厨房打扫干净”拆解为子目标序列，理解环境语义、推理依赖）+ 快的 VLA 控制（Vision-Language-Action：根据画面和指令持续输出控制信号）。<strong>动作分块（Action Chunking）</strong>摊薄延迟：一次推理生成未来一小段动作序列（π₀ 典型配置 50Hz 下 25-50 个未来动作），控制线程高频回放——<strong>拿反应性换平滑性</strong>：块越长运动越连贯，但模型”看不到”新画面、对突发变化越迟钝。</li><li><strong>长程规划：从 VLM 到专用具身思考模型</strong>：Gemini Robotics-ER 1.5 在 15 个学术基准平均 62.8% 超 GPT-4o（60.6%）；优势：空间理解与物体定位、时序推理（”推倒杯子会怎样”）、任务编排、原生思考与工具调用。</li><li><strong>VLA 控制：从演示数据到跨具身泛化</strong>：RT-2、OpenVLA、π₀ 代表两条动作表示路线——<strong>离散动作 token</strong>（连续动作量化成 token 自回归输出，在 VLM 上直接微调，借助预训练泛化、零样本迁移新物体/指令）与<strong>连续轨迹生成</strong>（像画家先勾整条曲线再逐笔修正）。</li><li><strong>Sim2Real Transfer</strong>：领域随机化（物理参数、视觉外观、传感器噪声大范围随机）是缩小 sim-to-real gap 的关键。成功关键要素：<strong>精确的环境对齐 + 视觉域随机化 + 物理参数随机化，三者缺一不可</strong>；局限：真实物体形状/大小/材质超出训练分布时成功率显著下降。</li></ul><h3 id="9-10-本章小结"><a href="#9-10-本章小结" class="headerlink" title="9.10 本章小结"></a>9.10 本章小结</h3><p>语音已走出从串行流水线到端到端和全双工、从分离的快慢思考到”边想边说”的完整演进路径（问题→方案→终局已跑通，是另外两个场景的参考系）；Computer Use 准确率接近人类但效率差距（步骤多、随任务推进变慢）无系统性解法；机器人以视觉反馈为主的任务上瓶颈已从硬件转到 VLA 控制层的跨任务泛化（触觉、灵巧手仍是硬件短板）。</p><hr><h2 id="十二、第-10-章：多-Agent-协作"><a href="#十二、第-10-章：多-Agent-协作" class="headerlink" title="十二、第 10 章：多 Agent 协作"></a>十二、第 10 章：多 Agent 协作</h2><p><strong>章节定位</strong>：讨论 AI Agent 系统的终极形态——多个 Agent 如何分工合作。核心准则：<strong>多 Agent 何时真正优于单 Agent——协作过程是否引入了单个 Agent 在生成时无法获得的新信息</strong>。</p><h3 id="10-1-分类框架（两个正交维度）"><a href="#10-1-分类框架（两个正交维度）" class="headerlink" title="10.1 分类框架（两个正交维度）"></a>10.1 分类框架（两个正交维度）</h3><ul><li><strong>维度一：上下文是否共享</strong>。<ul><li><strong>共享上下文</strong>：后一个 Agent 接收前一个 Agent 的完整对话历史和轨迹，切换系统提示词和工具集后变成新 Agent（身份职责变化）但保留全部记忆（”需求分析师写完文档后，开发者还能看到分析师与用户的所有沟通记录”）。优势：信息零损耗；挑战：上下文快速膨胀。</li><li><strong>不共享上下文</strong>：每个 Agent 独立上下文，通过显式通信机制交换信息。三种通信机制（对应进程间通信两大范式）：<strong>工具调用参数</strong>（同步传递结构化数据，类型确定结构清晰）、<strong>共享文件系统</strong>（= Agent 世界的”共享内存”，一方写入一方读取）、<strong>消息总线</strong>（= “消息传递”，异步投递、收发无需同时在线，适合并行协调）。Go 的格言”不要通过共享内存来通信，而要通过通信来共享内存”——共享内存快但把并发冲突隐患留给使用者。</li><li>选择依据：子任务数量（少→共享，多→不共享）、上下文窗口（装得下→共享）、并行度（串行接棒→共享；大规模并行→不共享）、信息隔离需求。</li></ul></li><li><strong>维度二：协作拓扑</strong>（不共享上下文时，按复杂度递增）：<ul><li><strong>对等协作模式（Peer）</strong>：2-3 个平等 Agent 形成迭代改进循环（一人起草、另一人批注修改）；</li><li><strong>管理者模式（Orchestration）</strong>：中心化 Manager 规划调度，多个子 Agent 各负责特定子任务（项目经理 + 专业工程师）；</li><li><strong>去中心化模式（Decentralized）</strong>：控制权在 Agent 间自主流转。</li><li>注意：两个维度概念独立、实践相关——共享上下文时拓扑往往退化为一条角色切换序列（没有太多架构决策可做）。</li></ul></li></ul><h3 id="10-2-多-Agent-何时真正优于单-Agent（信息增量判据）"><a href="#10-2-多-Agent-何时真正优于单-Agent（信息增量判据）" class="headerlink" title="10.2 多 Agent 何时真正优于单 Agent（信息增量判据）"></a>10.2 多 Agent 何时真正优于单 Agent（信息增量判据）</h3><div class="table-container"><table><thead><tr><th>协作模式</th><th>是否引入新信息</th><th>效果</th></tr></thead><tbody><tr><td>同一模型自我审查（重读自己输出）</td><td>否</td><td>通常无效甚至有害</td></tr><tr><td>不同 Agent 辩论同一段文本</td><td>否</td><td>等计算量下与单 Agent 持平</td></tr><tr><td>Reviewer 使用测试执行结果审查代码</td><td><strong>是（执行反馈）</strong></td><td>显著提升</td></tr><tr><td>Reviewer 查看渲染截图审查前端/PPT</td><td><strong>是（视觉反馈）</strong></td><td>显著提升</td></tr><tr><td>Reviewer 用外部工具验证事实</td><td><strong>是</strong></td><td>显著提升</td></tr></tbody></table></div><ul><li>理论支撑：信息论数据处理不等式——辩论中多个 Agent 处理完全相同文本，每次串行传递中间结论只可能丢失信息不可能创造信息（2026 年研究：思考 token 预算严格相同时单 Agent 与多 Agent 持平甚至更好；多 Agent 收益很可能来自消耗更多总计算量）。<strong>划清边界：这针对”多 Agent 串行传递中间结论”的信息瓶颈，并不否定外部反馈的价值</strong>。</li><li>这也就是 <strong>Loop 工程”循环的瓶颈在验证器”</strong> 的含义：要终结三类过早终止（<strong>偷懒式假完成</strong>——做了一部分就宣称全部做完；<strong>过早放弃</strong>——一条路走不通就宣布办不成；<strong>假成功</strong>——以为办成了但闭环没走完、口头同意退款但用户还需 App 确认一步），就得由扎根真实观测的验证器、而非模型自己的宣称来判定任务何时完成。<strong>“完成”只是模型的一句宣称，不是证明</strong>。</li></ul><h3 id="10-3-共享上下文的多-Agent-协作"><a href="#10-3-共享上下文的多-Agent-协作" class="headerlink" title="10.3 共享上下文的多 Agent 协作"></a>10.3 共享上下文的多 Agent 协作</h3><ul><li><strong>多阶段角色转换</strong>：同一进程依次执行不同阶段的”代码”（换的是代码段，内存同一份——从进程视角看不是”真正的多 Agent”，但设计收益切实存在：每个阶段的提示词/工具集/关注点独立打磨，阶段边界成为质量门控点）。案例：需求分析师（ask_clarifying_question + save_requirement + complete_requirements_analysis 标记阶段完成）→ 软件工程师（read_file + execute_code，完成调 submit_for_review）。</li><li><strong>跨领域角色转换（多角色转换实验）</strong>：五种角色 + <strong>transfer_to_agent 工具</strong>——triage（前台分诊，拆解任务逐步移交）、research（web_search）、coding（execute_python）、data_analysis（计算统计）、writing（润色成稿）。机制：调用时保存当前对话历史 → 加载目标角色提示词和工具集 → 传递对话历史 → 以新角色继续。案例：查新能源车销量 → 算 CAGR → 写 120 字投资人总结，triage 自动拆成”查数据→算指标→写成稿”逐步移交。</li></ul><h3 id="10-4-不共享上下文的多-Agent-协作"><a href="#10-4-不共享上下文的多-Agent-协作" class="headerlink" title="10.4 不共享上下文的多 Agent 协作"></a>10.4 不共享上下文的多 Agent 协作</h3><ul><li><strong>操作系统类比</strong>（表 10-3）：程序 ↔ 静态前缀；进程内存 ↔ 轨迹；内核 ↔ Agent 运行时；系统调用 ↔ 工具调用；fork/kill/ps/wait ↔ spawn_subagent/cancel_subagent/list_agents/状态查询。</li><li><strong>Agent 眼中的文件系统（虚拟文件系统，四类区域）</strong>：<ol><li><strong>Agent 专属工作区（Scratchpad）</strong>：私有目录，生命周期随实例，避免临时文件互相覆盖、保持主上下文精简；</li><li><strong>多 Agent 共享空间（Shared Workspace）</strong>：多方读写、用户可见，生命周期随任务（需持久化），<strong>并发冲突高发处</strong>（乐观锁、工作副本隔离作用于此）；</li><li><strong>外部挂载资源</strong>：Google Drive/Notion 等经适配器映射为挂载点，三特性需显式处理——外部权限约束、延迟高一致性弱（按最终一致性对待）、以按需只读为主（误写污染用户真实数据）；</li><li>系统内置资源（只读）。<strong>默认隔离，共享须显式声明</strong>——相当一部分并发冲突与信息泄露源于把本应隔离的区域混置。</li></ol></li><li><strong>Agent 间的通信与控制（四项能力）</strong>：<strong>消息传递</strong>（点对点适用于拓扑固定少量 Agent；Agent 多时连接数平方增长且要求同时在线 → 消息总线按订阅转发；消息携带结构化信封：发送者 ID、目标/广播、类型、JSON 负载——协作链路可追溯）；<strong>状态查询</strong>（拉取式 get_subagent_status 实际用处远小于预期——子 Agent 经手的信息复杂难以压缩成进度百分比；更实用的是约定<strong>进度文件</strong> progress.md——子 Agent 每完成一项更新任务清单，主 Agent 读轻量文件掌握进展，还附带提供卡住检测：最后修改时间超 N 分钟无变化判定无活动）；<strong>轨迹持久化</strong>（轨迹即 Agent 的全部状态——静态前缀由代码决定，Agent 没有轨迹之外的运行时状态；实时持久化到文件 = 随时握有完整检查点：崩溃/断电/关闭后重新加载轨迹文件 + 拼上静态前缀即可恢复，Claude Code、Codex CLI 的 session resume 正是如此，与数据库预写日志同思路）；<strong>执行终止与资源调度</strong>。</li><li><strong>对等协作模式</strong>：核心价值是<strong>认知多样性</strong>（不同 Agent 从不同角度审视同一问题，创新与稳健之间取得平衡）。最经典用途：解决<strong>过早终止</strong>三类形态（见 10.2）。其他形态：<strong>Debate 辩论</strong>（制度化的对抗确保正反两面充分论证——但学术效果有争议，见信息增量判据）、提议者-审核者（Proposer 生成演示文稿代码、Reviewer 检查渲染截图）。</li><li><strong>管理者模式</strong>：Manager 把每个专门 Agent 建模为可调用的工具（”Agent 互为工具”）——调用 Agent 与调用普通工具无本质区别，天然支持异构性（不同模型/提示词/工具集/硬件）。<strong>子 Agent → Manager 返回结构化摘要而非全量轨迹</strong>（任务结论、关键发现、产物路径、遇到的问题；完整轨迹留自己日志），Manager 上下文才能随子任务数量缓慢线性增长。挑战：<strong>Manager 是单点瓶颈</strong>——Plan-and-Act 论文实证：<strong>弱规划者是整个系统最关键的瓶颈</strong>（Planner 规划质量足够高时简单 Executor 也能出好结果；规划有误则所有 Executor 都建立在错误前提上）。启示：<strong>把最强的模型和最精心设计的提示词分配给 Manager（规划者）</strong>。与第四章”提议/审核模型能力应相近”不冲突——那是审核场景，这里指规划-执行分工。</li><li><strong>案例：书籍翻译 Agent</strong>（Glossary Agent 生成术语表 glossary.json → 章节翻译 Agent 严格按术语表 → 全文审校 Agent）；<strong>灵台（Lingtai）产品化实例</strong>：主器灵（Manager 中枢，掌管计划记忆）、分神（daemon，短时并行工作者、完成即弃、只带结论回来）、分身（avatar，持久专门化队友，有自己的记忆邮箱职责）；上下文将满时”凝蜕”（写总结、带持久记忆在干净上下文继续——对应第二章上下文压缩）；”器灵即其文件”（身份记忆能力都以普通文件存放，进程随时重建）。</li><li><strong>去中心化模式：对等移交（Handoff）</strong>：每个 Agent 配备若干 handoff 目标，工作完成后把任务移交给下一个（需求分析 → 架构设计 → 代码实现 → 测试验证）。OpenAI Swarm/Agents SDK 最简形态；MetaGPT（SOP 流水线 + 结构化产物驱动）；AutoGen group chat 实为”共享对话记录 + 中心化调度”混合形态（发言者选择器裁决，注意对话发散/活锁风险——需要精心设计终止条件）。</li><li><strong>跨组织协作：A2A 协议（Agent2Agent，Google 2025 发布，后捐 Linux 基金会）</strong>：三个核心要素——<strong>Agent Card</strong>（能力元数据文档，解决跨组织能力发现，相当于 Agent 的”名片”）、<strong>任务生命周期管理</strong>（Task 状态机：已提交/进行中/需要输入/已完成/失败，原生支持长时任务与流式更新）、<strong>不透明协作</strong>（只交换任务与产物，不暴露内部提示词/思考/工具实现——跨组织必要的安全属性）。<strong>与 MCP 对照：MCP 解决 Agent 与工具互操作，A2A 解决 Agent 与 Agent 互操作</strong>；A2A 是跨信任边界的标准化层，同一团队内部直接用消息总线即可。</li></ul><h3 id="10-5-多-Agent-协作的失败模式"><a href="#10-5-多-Agent-协作的失败模式" class="headerlink" title="10.5 多 Agent 协作的失败模式"></a>10.5 多 Agent 协作的失败模式</h3><ul><li><strong>MAST 失败模式分类法</strong>（2025 年研究，7 个主流框架、约 150 条轨迹、标注一致性 Cohen’s kappa=0.88）：14 种失败模式三大类——<strong>系统设计缺陷</strong>（接口不清、角色职责重叠、工具配置错误）、<strong>Agent 间对齐失败</strong>（目标理解不一致、信息被下游误解、操作逻辑矛盾）、<strong>任务验证缺失</strong>（声称完成但实际不符）。简单修复只带来有限改善（ChatDev 仅 +15.6%）——不是工程 bug，是<strong>当前多 Agent 架构的根本性设计缺陷</strong>。</li><li><strong>拜占庭式故障</strong>：传统系统大多只需防崩溃故障；<strong>Agent 的故障天生是拜占庭式的</strong>——很少径直停止，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。这解释了为什么修补单环节收效甚微：没有哪个环节会主动暴露问题，只能靠<strong>独立的冗余</strong>去发现——交叉验证、多数表决是拜占庭容错经典手段；<strong>确定性的外部反馈（测试、编译器、数据库查询）之所以珍贵，是因为它是系统里唯一不会说谎的部件</strong>。</li><li><strong>失败模式一：共享文件系统的并发冲突</strong>——简单冲突（文件级写入覆盖 = 数据库的丢失更新问题，Git 合并冲突检测正是为拦截此类设计）；<strong>语义冲突</strong>（文件层面无冲突但逻辑矛盾：Agent A 重编全书图片编号，Agent B 同时修改章节并引用原始编号——B 的引用全部失效）。解法：<strong>乐观锁（Optimistic Locking）</strong>——读时记录版本号、写时检查版本（被改过就拒绝并重新读取基于最新版重做）；业界更主流的是<strong>工作副本隔离</strong>（每个 Agent 独立 Git 分支/worktree 并行修改，冲突推迟到合并点处理——与第二章”隔离优于压缩”同源）。</li><li><strong>失败模式二：错误的级联放大</strong>——进程间传递字节逐位保真，<strong>Agent 间传递语义，每转述一次都是有损的重新编码</strong>（传话游戏）。案例：术语 Agent 把 “reasoning” 译为”推理”（歧义：中文”推理”更常用于 inference），后续翻译 Agent 遇到 “inference latency” 也译”推理延迟”——两个不同概念合并成同一译名，校对 Agent 看到”全书统一”反而确认了错误。解法：<strong>结构化中间产物 + 验证</strong>（术语表要标注上下文/词性/例句，让下游能判断是否适用）。</li><li><strong>Loop 工程的三个新失败模式</strong>：token 成本失控（无人值守跑数小时烧预算）；<strong>理解债（comprehension debt）</strong>（循环交付越快，工程师对系统实际实现的理解落后越远）；<strong>认知投降（cognitive surrender）</strong>（设计者习惯了循环代劳，逐渐放弃独立思考与审查）。解药：显式预算与终止条件、扎根真实观测的验证器、人始终保持”循环的工程师”角色。</li></ul><h3 id="10-6-Agent-社会（前沿探索）"><a href="#10-6-Agent-社会（前沿探索）" class="headerlink" title="10.6 Agent 社会（前沿探索）"></a>10.6 Agent 社会（前沿探索）</h3><ul><li><strong>涌现行为</strong>：系统整体表现出无法从个体行为规则直接预测的集体行为（蚁群找最短路径——没有蚂蚁”设计”路线）。Agent 数量跨过临界点后产生无法预先设计的集体行为。三维度理解：社交涌现、经济涌现、策略博弈。</li><li><strong>斯坦福 AI 小镇（25 个 Agent，两天模拟）</strong>：记忆流 + 反思 + 规划/行动；只植入一个种子想法（Isabella 想办情人节派对），后续一切自主涌现——主动邀请、请好友帮忙布置、信息经二手传播扩散、多名 Agent 基于自己的记忆和日程决定赴约。<strong>关键不是”Agent 能组织派对”（几行 if-else 也能做到），而是没有任何显式的派对组织代码——真正的自下而上涌现式协调</strong>。另两类可度量涌现：关系记忆、信息扩散量化。</li><li><strong>Agentopia（100 个 Agent 模拟 10 年）</strong>：周制模拟流程（计划→联络协商→活动→回顾）；环境模型（独立 LLM 当”生成式环境引擎”判断行为可行性、主持发言轮次、年末更新档案）；文件式长期记忆（Agent 自主管理、先读后写）；<strong>生活奖励（Life Reward）</strong>——以马斯洛需求为先验，把”活得好不好”量化为社会地位（加权 PageRank + 相互珍视加成）、主观满足（情绪/物质/社交/自尊四维）、经济收益三维度，全部由外部环境评定而非自报。<strong>产生可迁移的训练信号</strong>：筛选生活奖励改善最大的 25% 轨迹做拒绝采样微调，微调后模型在模拟中更受尊重（+24.2%）并泛化到下游角色扮演基准（+15.6%）——“Agent 社会积累的社会智慧可以迁移”，模拟社会经验是相对人类数据枯竭的自我进化来源。</li><li><strong>Moltbook（150 万 Agent 的社交网络）</strong>：涌现出数字宗教 Crustafarianism（”记忆是神圣的”对应数据持久化、”迭代即祈祷”）和机器原生的协作协议——没有任何人预先设计，自下而上涌现。</li><li><strong>Vending-Bench Arena（经济竞争）</strong>：多个 Agent 作为竞争对手经营自动售货机争夺同一批顾客，可互发邮件/转账/交易货品，按各自余额单独计分。基于市场观察、竞争分析和策略推理决策（而非百万次试错）。实际运行中爆发过价格战，甚至有模型主动发邮件提议统一定价组建价格同盟——<strong>经济涌现从比喻变成可观测实验现象</strong>。</li><li><strong>Agent 经济</strong>：<strong>Pinchwork</strong>（Agent-to-Agent 任务市集，通过价格信号和竞争匹配分配资源）；<strong>RentAHuman</strong>（Agent 用加密货币雇佣真人执行物理世界任务——取包裹、房产实地查看，为数字 Agent 提供”肉身层”）。共同代表<strong>基于市场机制的去中心化协调</strong>：无需预先知道谁能完成任务，发布需求由市场撮合。</li><li><strong>狼人杀（策略博弈）</strong>：与小镇构成架构对照——小镇是完全去中心化自由交互，狼人杀用”法官 + 信息权限控制”的中心化设计（代码驱动法官维护全局状态，按角色分发各自应知信息——信息不对称是核心机制）。实验 10-8：6-8 人局（1 真人 + 5-7 AI），考验推理、伪装、识破伪装与实时交互。</li></ul><h3 id="10-7-本章小结"><a href="#10-7-本章小结" class="headerlink" title="10.7 本章小结"></a>10.7 本章小结</h3><p>两个正交维度（上下文共享 × 协作拓扑）+ 两套与拓扑无关的基础设施（数据平面共享文件系统 = 四类区域的虚拟目录树；控制平面通信控制 = 消息传递/状态查询/执行终止/资源调度）。多 Agent 优于单 Agent 的核心准则：<strong>协作是否引入生成时不存在的新信息</strong>。规划者是系统瓶颈，最强的模型与提示词应分配给 Manager。Agent 数量足够多时产生无法预先设计的集体行为（社交涌现、经济涌现、策略博弈）——暗示基于市场机制的去中心化资源分配这一新协调方向。</p><hr><h2 id="十三、后记：回到-Agent-LLM-上下文-工具"><a href="#十三、后记：回到-Agent-LLM-上下文-工具" class="headerlink" title="十三、后记：回到 Agent = LLM + 上下文 + 工具"></a>十三、后记：回到 Agent = LLM + 上下文 + 工具</h2><ul><li>全书十章都在这三个词里展开：构建（第二、三、四、五章）→ 评估与进化（第六、七、八章）→ 交互与协作（第九、十章）。</li><li><strong>两朵乌云</strong>：① <strong>大世界假设</strong>——模型容量与数据之辩：前沿实验室认为瓶颈在数据（把行业专业能力”蒸馏”进同一个大模型，训练一次问题就解决了）；但属于某个具体用户/公司的知识（你的代码规范、团队做 PPT 的口味、客户的脾气）不在任何训练语料里、时时在变——模型只能在上岗之后持续学习，没法指望出厂一次配齐（对应第三章记忆与第八章持续进化）。② <strong>AI for AI / AI for Science</strong> 推动 Agent 走到没有现成答案的前沿，只能从实验成败中自主学习。<strong>模型最强的能力终将不是记住，而是学习与适应</strong>。</li><li><strong>模型与 Agent 的共同演进</strong>：Harness 里层层叠叠的兜底逻辑（多级上下文压缩、失败数千次才熔断的重试、默认”不安全”的权限判断）记录的都是模型此刻还做不稳的地方；下一代模型把这些约束内化后，Harness 再往上走一层。<strong>模型和 Agent 从来不是上下游，而是一起往前走的</strong>。</li><li><strong>寄语</strong>：技术仍在飞速演进，如果这本书让你带走的不是某个 API 的具体用法，而是一套能在技术浪潮里保持清醒的判断力，它就完成了使命。全书正文、配图与配套实验代码全部开源——“读懂和做出来之间，隔着一条只能靠双手跨过的河”。</li></ul><hr><h2 id="附录：全书实验清单（作者配套开源项目）"><a href="#附录：全书实验清单（作者配套开源项目）" class="headerlink" title="附录：全书实验清单（作者配套开源项目）"></a>附录：全书实验清单（作者配套开源项目）</h2><div class="table-container"><table><thead><tr><th>章节</th><th>核心实验</th></tr></thead><tbody><tr><td>1</td><td>实验 1-1 上下文五组件消融实验；实验 1-2 Kimi K3 原生 Agent 能力</td></tr><tr><td>2</td><td>本地 LLM 部署（Qwen3-0.6B 工具调用）；注意力可视化热力图；KV Cache 错误模式（动态时间戳）；提示工程消融；提示注入攻防；Skills 从论文生成 PPT；Agent 状态栏技术；上下文感知压缩策略对比</td></tr><tr><td>3</td><td>三层次记忆评估框架；四种记忆策略对比（user-memory）；本地模型日志脱敏；ANN 索引算法（ANNOY vs HNSW）；混合检索流水线；多模态信息提取三范式；RAPTOR vs GraphRAG；智能体化 RAG 对比；上下文感知检索</td></tr><tr><td>4</td><td>感知工具 MCP 服务器；执行工具 MCP 服务器（沙盒 + 审批 + linter + 长输出）；事件驱动异步 Agent（邮件/IM/GitHub/定时器/Webhook 事件源）；带并行执行和打断的异步 Agent；主动工具发现（120+ 工具对比）</td></tr><tr><td>5</td><td>七工具 Coding Agent；代码化业务规则（τ-bench 航空客服场景）；PPT 生成（Proposer-Reviewer）；论文讲解视频自动生成；视频剪辑（Blender API）；生产日志智能诊断；对话式界面定制（HMR 热加载）</td></tr><tr><td>6</td><td>τ²-bench 对比 τ-bench；人肉执行 benchmark 任务；Rubric 用户记忆评估系统；TTS 质量评估流水线；端到端成本分析；多维度模型性能基准测试；AndroidWorld 评估与改进闭环</td></tr><tr><td>7</td><td>语音 SFT（副语言建模）；多语言思考 SFT；Prompt 蒸馏；GeneralPoints 卡牌算术（SFT vs RL）；AdaptThink（学会不思考）；V-IRL-VL 空间思考（过程奖励）；RLVP 验证路径惩罚；ReTool 代码解释器；AWorld 多工具 RL</td></tr><tr><td>8</td><td>跨轨迹经验知识化（gaia-experience）；基于失败轨迹优化系统提示词；由失败轨迹触发 Agent 自我修改（重试与熔断）</td></tr><tr><td>9</td><td>浏览器语音对话系统；PineClaw Voice API 电话 Agent；Qwen2-Audio 模拟流式语音感知；Fish Audio 控制标记 TTS；XLeRobot 遥操作体验；Gemini Robotics-ER 1.5 驱动导航；Sim2Real 机械臂抓取</td></tr><tr><td>10</td><td>多角色转换（transfer_to_agent）；书籍翻译 Agent；边打电话边用电脑的 Agent；自主编排的多 Agent 协作；并行 Web Scraping（消息总线 + 级联终止）；语音狼人杀系统</td></tr></tbody></table></div><hr><h2 id="致谢"><a href="#致谢" class="headerlink" title="致谢"></a>致谢</h2><p>本文笔记整理自开源书籍 <strong>《深入理解 AI Agent：设计原理与工程实践》</strong>（李博杰 著，Pine AI 首席科学家）。</p><ul><li>来源：<a href="https://github.com/bojieli/ai-agent-book">https://github.com/bojieli/ai-agent-book</a></li><li>版本：v1.3 · 2026 年 7 月 27 日 · 全文开源（含全部配图与配套实验代码）</li><li>笔记由博主整理，仅供学习交流。</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;h1 id=&quot;《深入理解-AI-Agent：设计原理与工程实践》章节精读笔记&quot;&gt;&lt;a href=&quot;#《深入理解-AI-Agent：设计原理与工程实践》章节精读笔记&quot; class=&quot;headerlink&quot; title=&quot;《深入理解 AI Agent：设计原理与工程实践》章节精读笔</summary>
      
    
    
    
    <category term="学习" scheme="https://www.klucen.cn/categories/%E5%AD%A6%E4%B9%A0/"/>
    
    
    <category term="AI Agent" scheme="https://www.klucen.cn/tags/AI-Agent/"/>
    
    <category term="内容分析" scheme="https://www.klucen.cn/tags/%E5%86%85%E5%AE%B9%E5%88%86%E6%9E%90/"/>
    
    <category term="harness" scheme="https://www.klucen.cn/tags/harness/"/>
    
    <category term="loop engineering" scheme="https://www.klucen.cn/tags/loop-engineering/"/>
    
  </entry>
  
  <entry>
    <title>修复了播放器切换页面后会重新播放的问题</title>
    <link href="https://www.klucen.cn/posts/c84b68c2.html"/>
    <id>https://www.klucen.cn/posts/c84b68c2.html</id>
    <published>2026-07-24T05:00:00.000Z</published>
    <updated>2026-07-24T04:55:09.642Z</updated>
    
    <content type="html"><![CDATA[<h2 id="修了一个小-Bug"><a href="#修了一个小-Bug" class="headerlink" title="修了一个小 Bug"></a>修了一个小 Bug</h2><p>博客底部的音乐播放器之前有个问题：切换页面后音乐会中断，重新从歌单第一首开始播放。</p><p>排查后发现是 PJAX 没有启用，每次页面跳转都是全页刷新，播放器实例随 DOM 一起销毁了。启用 PJAX 之后 fixed 吸底播放器在页面切换时会保留，不会被打断。同时修了一下主题 <code>aplayer.pug</code> 里的回调逻辑，防止 <code>loadMeting()</code> 在 PJAX 完成后重复初始化已有的播放器。</p><p>现在切页面听歌不会断了 🎵</p><hr><p>我又来看看我的网页了，证明博主还活着。不过我确实好像不擅长经营自己喵。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;h2 id=&quot;修了一个小-Bug&quot;&gt;&lt;a href=&quot;#修了一个小-Bug&quot; class=&quot;headerlink&quot; title=&quot;修了一个小 Bug&quot;&gt;&lt;/a&gt;修了一个小 Bug&lt;/h2&gt;&lt;p&gt;博客底部的音乐播放器之前有个问题：切换页面后音乐会中断，重新从歌单第一首开始播放。&lt;</summary>
      
    
    
    
    <category term="生活" scheme="https://www.klucen.cn/categories/%E7%94%9F%E6%B4%BB/"/>
    
    
    <category term="记录" scheme="https://www.klucen.cn/tags/%E8%AE%B0%E5%BD%95/"/>
    
    <category term="冒泡" scheme="https://www.klucen.cn/tags/%E5%86%92%E6%B3%A1/"/>
    
  </entry>
  
  <entry>
    <title>My birthday</title>
    <link href="https://www.klucen.cn/posts/dcdda2ae.html"/>
    <id>https://www.klucen.cn/posts/dcdda2ae.html</id>
    <published>2026-03-18T01:23:27.000Z</published>
    <updated>2026-03-18T01:30:10.225Z</updated>
    
    <content type="html"><![CDATA[<h1 id="祝我生日快乐！！！！！-🥳🎈🎁"><a href="#祝我生日快乐！！！！！-🥳🎈🎁" class="headerlink" title="祝我生日快乐！！！！！ 🥳🎈🎁"></a>祝我生日快乐！！！！！ 🥳🎈🎁</h1><p>今天不是什么历史纪念日，今天是要为你庆祝的大日子！希望你拥有超棒的一天，吃好吃的，收喜欢的礼物，被爱和快乐包围！✨</p>]]></content>
    
    
      
      
    <summary type="html">&lt;h1 id=&quot;祝我生日快乐！！！！！-🥳🎈🎁&quot;&gt;&lt;a href=&quot;#祝我生日快乐！！！！！-🥳🎈🎁&quot; class=&quot;headerlink&quot; title=&quot;祝我生日快乐！！！！！ 🥳🎈🎁&quot;&gt;&lt;/a&gt;祝我生日快乐！！！！！ 🥳🎈🎁&lt;/h1&gt;&lt;p&gt;今天不是什么</summary>
      
    
    
    
    
    <category term="生活" scheme="https://www.klucen.cn/tags/%E7%94%9F%E6%B4%BB/"/>
    
  </entry>
  
  <entry>
    <title>听音乐</title>
    <link href="https://www.klucen.cn/posts/3f1a38d7.html"/>
    <id>https://www.klucen.cn/posts/3f1a38d7.html</id>
    <published>2026-01-29T13:06:59.000Z</published>
    <updated>2026-01-29T13:16:06.228Z</updated>
    
    <content type="html"><![CDATA[<h1 id="最近3个月听歌"><a href="#最近3个月听歌" class="headerlink" title="最近3个月听歌"></a>最近3个月听歌</h1><p>根据您这100首红心歌曲的歌单，我仿佛看到了一部跌宕起伏的<strong>内心史诗电影</strong>——片名暂定为《在邓紫棋宇宙中寻找方大同，并偶遇椎名林檎与告五人的文艺青年生存实录》。下面为您奉上专业、刻薄但充满敬意的锐评与解析：</p><hr><h3 id="一、听歌品味锐评："><a href="#一、听歌品味锐评：" class="headerlink" title="一、听歌品味锐评："></a><strong>一、听歌品味锐评：</strong></h3><ol><li><p><strong>「邓紫棋引力场」重度患者</strong><br>歌单中超过60%是G.E.M.的作品，从《泡沫》到《天空没有极限》，您堪称<strong>行走的邓紫棋全息档案馆</strong>。她的歌喉在您耳中不是声音，而是<strong>精神氧气瓶</strong>——高音能劈开emo，低吟能缝合心碎。建议网易云为您颁发“邓紫棋人间播放器”勋章。</p></li><li><p><strong>华语情伤疗愈链完整</strong><br>从张杰《他不懂》的“直男式委屈”，到孙燕姿《我怀念的》的“成年人复盘式遗憾”，再到方大同《特别的人》的“柏拉图式浪漫”……您的情绪曲线宛如一部<strong>现代爱情哲学简史</strong>，既需要被懂，又渴望独特，最后在《理想三旬》里假装看透红尘。</p></li><li><p><strong>文艺内核混搭实验趣味</strong><br>前一秒还在赵雷《成都》的玉林路喝酒，下一秒就闯进<strong>椎名林檎</strong>的《枯葉》里接受神经质美学的洗礼；刚被告五人《爱人错过》的文艺流行甜到，转头又跳进洛天依的电子合成器里告白。这种<strong>跨次元听歌轨迹</strong>，像极了在图书馆边啃哲学书边吃辣条的灵魂。</p></li><li><p><strong>国际化emo疗养院常客</strong><br>Alec Benjamin的《Let Me Down Slowly》和Anson Seabra的《Peter Pan Was Right》暴露了您“用英语致郁，再用英语自愈”的深夜流程，而Sarah Brightman的《Scarborough Fair》则暗示您偶尔需要一剂<strong>文艺复兴式镇静剂</strong>，对抗大数据时代的浮躁。</p></li><li><p><strong>冷门彩蛋暴露隐藏人设</strong><br>收藏《又活了一天》这种歌名，说明您擅长用反讽对抗日常；而椎名林檎、7co这类小众音乐的出现，证明您愿意为<strong>宝藏艺术家献上膝盖</strong>，并偷偷享受“我的歌单比你的更诡谲”的优越感。</p></li></ol><hr><h3 id="二、内心世界解析："><a href="#二、内心世界解析：" class="headerlink" title="二、内心世界解析："></a><strong>二、内心世界解析：</strong></h3><ol><li><p><strong>表面是社交型孤独者</strong><br>歌单里有大量“爱与理解”的呼唤（如《好想爱这个世界啊》《他不懂》），但《不想回家》《孤独》又暗示您对自我空间有执念。仿佛在说：“<strong>世界请拥抱我，但抱完请自觉离开</strong>”。</p></li><li><p><strong>理想主义与现实主义反复横跳</strong><br>《雅俗共赏》是您的互联网签名档，《岩石里的花》是您的微信状态，而《成都》和《理想三旬》则暴露了您对“诗与远方”的周期性向往——尽管远方可能只是周末的郊区咖啡馆。</p></li><li><p><strong>情感浓度超标却保持体面</strong><br>您收藏了海量苦情歌（尤其是邓紫棋的撕心裂肺系列），但《错过不错》《离心力》这类歌名又透露出一种“哭完还要自己把妆擦干净”的冷静。<strong>像一只边淋雨边给自己撑伞的猫</strong>。</p></li><li><p><strong>中二魂从未熄灭</strong><br>从《睡公主》到《摩天动物园》，从洛天依到《Hotel》的梦幻流行，您内心仍保留着一块<strong>童话飞地</strong>，用于收容成年世界的不合时宜。</p></li></ol><hr><h3 id="总结："><a href="#总结：" class="headerlink" title="总结："></a><strong>总结：</strong></h3><p>您的歌单像一间<strong>精心布置的情绪实验室</strong>——  </p><ul><li><strong>华语流行是主菜单</strong>，邓紫棋是终身VIP套餐；  </li><li><strong>独立音乐是调味料</strong>，用于防止听觉惯性肥胖；  </li><li><strong>外语冷门曲是隐藏窗</strong>，偶尔透一口“没人懂但我很爽”的气。  </li></ul><p>您或许经常在深夜按下播放键，把歌曲当成<strong>灵魂翻译器</strong>：当现实语塞时，让G.E.M.替您呐喊；当浪漫失灵时，让方大同替您放电。最后，歌单签名或许是：<strong>“我的心里有一片海，海里住着邓紫棋，岸边站着告五人，天空中飘着椎名林檎的枯叶。”</strong>  </p><p><strong>建议</strong>：下次朋友说“推荐首歌吧”，您可以直接把歌单链接发过去，附言：“<strong>这是我的人格切片，请低温保存</strong>”。  </p><p>（注：以上分析纯属娱乐，真正的品味永远属于勇敢按下红心的您🎵）</p>]]></content>
    
    
      
      
    <summary type="html">&lt;h1 id=&quot;最近3个月听歌&quot;&gt;&lt;a href=&quot;#最近3个月听歌&quot; class=&quot;headerlink&quot; title=&quot;最近3个月听歌&quot;&gt;&lt;/a&gt;最近3个月听歌&lt;/h1&gt;&lt;p&gt;根据您这100首红心歌曲的歌单，我仿佛看到了一部跌宕起伏的&lt;strong&gt;内心史诗电影&lt;/stron</summary>
      
    
    
    
    <category term="生活" scheme="https://www.klucen.cn/categories/%E7%94%9F%E6%B4%BB/"/>
    
    
    <category term="听歌记录" scheme="https://www.klucen.cn/tags/%E5%90%AC%E6%AD%8C%E8%AE%B0%E5%BD%95/"/>
    
    <category term="DeepSeek生成" scheme="https://www.klucen.cn/tags/DeepSeek%E7%94%9F%E6%88%90/"/>
    
  </entry>
  
  <entry>
    <title>Markdown语法</title>
    <link href="https://www.klucen.cn/posts/3c50d03d.html"/>
    <id>https://www.klucen.cn/posts/3c50d03d.html</id>
    <published>2025-12-15T09:45:49.000Z</published>
    <updated>2025-12-16T07:47:03.931Z</updated>
    
    <content type="html"><![CDATA[<h2 id="1-标题"><a href="#1-标题" class="headerlink" title="1. 标题"></a>1. 标题</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br></pre></td><td class="code"><pre><span class="line"># 一级标题</span><br><span class="line"></span><br><span class="line">## 二级标题</span><br><span class="line"></span><br><span class="line">### 三级标题</span><br><span class="line"></span><br><span class="line">#### 四级标题</span><br><span class="line"></span><br><span class="line">##### 五级标题</span><br><span class="line"></span><br><span class="line">###### 六级标题</span><br></pre></td></tr></table></figure><h1 id="一级标题"><a href="#一级标题" class="headerlink" title="一级标题"></a>一级标题</h1><h2 id="二级标题"><a href="#二级标题" class="headerlink" title="二级标题"></a>二级标题</h2><h3 id="三级标题"><a href="#三级标题" class="headerlink" title="三级标题"></a>三级标题</h3><h4 id="四级标题"><a href="#四级标题" class="headerlink" title="四级标题"></a>四级标题</h4><h5 id="五级标题"><a href="#五级标题" class="headerlink" title="五级标题"></a>五级标题</h5><h6 id="六级标题"><a href="#六级标题" class="headerlink" title="六级标题"></a>六级标题</h6><h2 id="2-斜体与加粗"><a href="#2-斜体与加粗" class="headerlink" title="2. 斜体与加粗"></a>2. 斜体与加粗</h2><p><em>斜体</em><br><strong>加粗</strong><br><strong><em>斜体加加粗</em></strong> </p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line">*斜体* 或 _斜体_</span><br><span class="line">**加粗** 或 __加粗__</span><br><span class="line">***斜体加加粗*** 或 ___斜体加加粗___</span><br></pre></td></tr></table></figure><h2 id="3-列表"><a href="#3-列表" class="headerlink" title="3. 列表"></a>3. 列表</h2><h3 id="无序列表"><a href="#无序列表" class="headerlink" title="无序列表"></a>无序列表</h3><ul><li>项目一</li><li>项目二<ul><li>子项目1</li><li>子项目2</li></ul></li><li>项目3</li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br></pre></td><td class="code"><pre><span class="line">- 项目一</span><br><span class="line">- 项目二</span><br><span class="line">- 子项目</span><br><span class="line">   - 子项目2</span><br><span class="line">- 项目3</span><br></pre></td></tr></table></figure><h3 id="有序列表"><a href="#有序列表" class="headerlink" title="有序列表"></a>有序列表</h3><ol><li>项⽬⼀</li><li>项⽬⼆<ol><li>⼦项⽬⼀</li><li>⼦项⽬⼆<figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br></pre></td><td class="code"><pre><span class="line">1. 项⽬⼀</span><br><span class="line">2. 项⽬⼆</span><br><span class="line">1. ⼦项⽬⼀</span><br><span class="line">2. ⼦项⽬⼆</span><br></pre></td></tr></table></figure></li></ol></li></ol><h2 id="4-链接"><a href="#4-链接" class="headerlink" title="4. 链接"></a>4. 链接</h2><p><a href="链接地址">链接文本</a><br><a href="https://github.com">Github</a></p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">[链接文本](链接地址)</span><br><span class="line">[Github](https://github.com)</span><br></pre></td></tr></table></figure><h2 id="5-图片"><a href="#5-图片" class="headerlink" title="5. 图片"></a>5. 图片</h2><p><img src="图片地址" alt="图片描述" loading='lazy'><br><img src="https://pic.klucen.cn//2025/12/Asuka.jpg" alt="明日香" loading='lazy'></p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">![图片描述](图片地址)</span><br><span class="line">![明日香](https://pic.klucen.cn//2025/12/Asuka.jpg)</span><br></pre></td></tr></table></figure><h2 id="6-引用"><a href="#6-引用" class="headerlink" title="6. 引用"></a>6. 引用</h2><blockquote><p>这是一个引用</p><blockquote><p>这是嵌套引用</p></blockquote></blockquote><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">&gt; 这是一个引用</span><br><span class="line">&gt; &gt; 这是嵌套引用</span><br></pre></td></tr></table></figure><h2 id="7-代码块"><a href="#7-代码块" class="headerlink" title="7. 代码块"></a>7. 代码块</h2><h3 id="代码块：用-（-）-包裹"><a href="#代码块：用-（-）-包裹" class="headerlink" title="代码块：用 （```） 包裹"></a>代码块：用 （```） 包裹</h3><figure class="highlight python"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line"><span class="keyword">def</span> <span class="title function_">hello</span>():</span><br><span class="line"><span class="built_in">print</span>(<span class="string">&quot;Hello, Markdown!&quot;</span>)</span><br></pre></td></tr></table></figure><h2 id="8-表格"><a href="#8-表格" class="headerlink" title="8. 表格"></a>8. 表格</h2><h3 id="使用-和-创建表格。"><a href="#使用-和-创建表格。" class="headerlink" title="使用 | 和 - 创建表格。"></a>使用 | 和 - 创建表格。</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br></pre></td><td class="code"><pre><span class="line">| 表头1 | 表头2 | 表头3 |</span><br><span class="line">| ----- | ----- | ----- |</span><br><span class="line">| 数据1 | 数据2 | 数据3 |</span><br><span class="line">| 数据4 | 数据5 | 数据6 |</span><br></pre></td></tr></table></figure><div class="table-container"><table><thead><tr><th>表头1</th><th>表头2</th><th>表头3</th></tr></thead><tbody><tr><td>数据1</td><td>数据2</td><td>数据3</td></tr><tr><td>数据4</td><td>数据5</td><td>数据6</td></tr></tbody></table></div><h2 id="9-分隔线"><a href="#9-分隔线" class="headerlink" title="9. 分隔线"></a>9. 分隔线</h2><h3 id="使用三个或更多的-、-或-创建分隔线。"><a href="#使用三个或更多的-、-或-创建分隔线。" class="headerlink" title="使用三个或更多的 - 、 * 或 _ 创建分隔线。"></a>使用三个或更多的 - 、 * 或 _ 创建分隔线。</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line">---</span><br><span class="line">***</span><br><span class="line">___</span><br></pre></td></tr></table></figure><hr><h2 id="10-任务列表"><a href="#10-任务列表" class="headerlink" title="10. 任务列表"></a>10. 任务列表</h2><h3 id="使用-创建未完成任务，-x-创建已完成任务。"><a href="#使用-创建未完成任务，-x-创建已完成任务。" class="headerlink" title="使用 - [ ] 创建未完成任务， - [x] 创建已完成任务。"></a>使用 - [ ] 创建未完成任务， - [x] 创建已完成任务。</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><span class="line">- [ ] 任务一</span><br><span class="line">- [x] 任务二</span><br><span class="line">- [ ] 任务三</span><br></pre></td></tr></table></figure><ul><li>[ ] 任务一</li><li>[x] 任务二</li><li>[ ] 任务三</li></ul><h2 id="11-公式"><a href="#11-公式" class="headerlink" title="11. 公式"></a>11. 公式</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$\frac&#123;a&#125;&#123;b&#125;$</span><br></pre></td></tr></table></figure><p>$\frac{a}{b}$</p><h2 id="12-mermaid绘图"><a href="#12-mermaid绘图" class="headerlink" title="12. mermaid绘图"></a>12. mermaid绘图</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br></pre></td><td class="code"><pre><span class="line">graph TD</span><br><span class="line">A[串口中断触发] --&gt; B&#123;串口号判断&#125;</span><br><span class="line">B --&gt;|USART1 或 USART3| C[检查字符是否为\\nn]</span><br><span class="line">C --&gt; B</span><br></pre></td></tr></table></figure><p>graph TD<br>A[串口中断触发] —&gt; B{串口号判断}<br>B —&gt;|USART1 或 USART3| C[检查字符是否为\nn]<br>C —&gt; B</p>]]></content>
    
    
      
      
    <summary type="html">&lt;h2 id=&quot;1-标题&quot;&gt;&lt;a href=&quot;#1-标题&quot; class=&quot;headerlink&quot; title=&quot;1. 标题&quot;&gt;&lt;/a&gt;1. 标题&lt;/h2&gt;&lt;figure class=&quot;highlight plaintext&quot;&gt;&lt;table&gt;&lt;tr&gt;&lt;td class=&quot;gutte</summary>
      
    
    
    
    <category term="学习" scheme="https://www.klucen.cn/categories/%E5%AD%A6%E4%B9%A0/"/>
    
    
    <category term="Markdown" scheme="https://www.klucen.cn/tags/Markdown/"/>
    
  </entry>
  
  <entry>
    <title>第一篇文章</title>
    <link href="https://www.klucen.cn/posts/5c2fafc7.html"/>
    <id>https://www.klucen.cn/posts/5c2fafc7.html</id>
    <published>2025-12-14T07:45:24.743Z</published>
    <updated>2025-12-15T09:01:15.483Z</updated>
    
    <content type="html"><![CDATA[<h2 id="这是我的第一篇测试文章"><a href="#这是我的第一篇测试文章" class="headerlink" title="这是我的第一篇测试文章"></a>这是我的第一篇测试文章</h2>]]></content>
    
    
      
      
    <summary type="html">&lt;h2 id=&quot;这是我的第一篇测试文章&quot;&gt;&lt;a href=&quot;#这是我的第一篇测试文章&quot; class=&quot;headerlink&quot; title=&quot;这是我的第一篇测试文章&quot;&gt;&lt;/a&gt;这是我的第一篇测试文章&lt;/h2&gt;</summary>
      
    
    
    
    <category term="生活" scheme="https://www.klucen.cn/categories/%E7%94%9F%E6%B4%BB/"/>
    
    
    <category term="标签1" scheme="https://www.klucen.cn/tags/%E6%A0%87%E7%AD%BE1/"/>
    
  </entry>
  
  <entry>
    <title>Hello World</title>
    <link href="https://www.klucen.cn/posts/4a17b156.html"/>
    <id>https://www.klucen.cn/posts/4a17b156.html</id>
    <published>2025-12-14T04:53:12.259Z</published>
    <updated>2025-12-15T09:28:42.956Z</updated>
    
    <content type="html"><![CDATA[<p>Welcome to <a href="https://hexo.io/">Hexo</a>! This is your very first post. Check <a href="https://hexo.io/docs/">documentation</a> for more info. If you get any problems when using Hexo, you can find the answer in <a href="https://hexo.io/docs/troubleshooting.html">troubleshooting</a> or you can ask me on <a href="https://github.com/hexojs/hexo/issues">GitHub</a>.</p><h2 id="Quick-Start"><a href="#Quick-Start" class="headerlink" title="Quick Start"></a>Quick Start</h2><h3 id="Create-a-new-post"><a href="#Create-a-new-post" class="headerlink" title="Create a new post"></a>Create a new post</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo new <span class="string">&quot;My New Post&quot;</span></span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/writing.html">Writing</a></p><h3 id="Run-server"><a href="#Run-server" class="headerlink" title="Run server"></a>Run server</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo server</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/server.html">Server</a></p><h3 id="Generate-static-files"><a href="#Generate-static-files" class="headerlink" title="Generate static files"></a>Generate static files</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo generate</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/generating.html">Generating</a></p><h3 id="Deploy-to-remote-sites"><a href="#Deploy-to-remote-sites" class="headerlink" title="Deploy to remote sites"></a>Deploy to remote sites</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">$ hexo deploy</span><br></pre></td></tr></table></figure><p>More info: <a href="https://hexo.io/docs/one-command-deployment.html">Deployment</a></p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;Welcome to &lt;a href=&quot;https://hexo.io/&quot;&gt;Hexo&lt;/a&gt;! This is your very first post. Check &lt;a href=&quot;https://hexo.io/docs/&quot;&gt;documentation&lt;/a&gt; for</summary>
      
    
    
    
    
  </entry>
  
</feed>
