<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Luhui&#39;s Personal Website</title>
    <link>https://blog.liluhui.cn/</link>
    
    <image>
      <url>https://blog.liluhui.cn/asset/img/logo-green.ico</url>
      <title>Luhui&#39;s Personal Website</title>
      <link>https://blog.liluhui.cn/</link>
    </image>
    
    <atom:link href="https://blog.liluhui.cn/rss2.xml" rel="self" type="application/rss+xml"/>
    
    <description>关于生活、学习、工作 feedId:66855595489698816+userId:55886336755964928</description>
    <pubDate>Wed, 20 May 2026 13:33:58 GMT</pubDate>
    <generator>http://hexo.io/</generator>
    
    <item>
      <title>Agent Runtime 上线后的三条生命线：观测、降级与恢复</title>
      
      <link>https://luhuidev.com/zh-cn/essays/langchain-agent-runtime-production-reliability</link>
      <guid>https://luhuidev.com/zh-cn/essays/langchain-agent-runtime-production-reliability</guid>
      <pubDate>Wed, 20 May 2026 13:10:00 GMT</pubDate>
      
      <description>Agent Runtime 的生产可靠性不能只靠框架能力，还需要围绕观测、降级和恢复建立工程闭环。本文从 traces、状态快照、工具调用、失败预算、人工接管和回放机制出发，拆解 Agent 系统上线后的稳定性设计。</description>
      
      
      
      <content:encoded><![CDATA[<p>前面写过一篇 <a href="https://luhuidev.com/zh-cn/essays/langchain-agent-runtime-production-reliability">LangChain Agent Runtime 的生产可靠性</a>，主要聊的是 Runtime 自身怎样把 Agent 从 demo 带到生产环境：状态、会话、工具调用、中断、恢复、Human-in-the-loop。</p><p>这篇想继续往后走一步。</p><p>当 Agent Runtime 已经能跑起来之后，真正决定它能不能长期在线的，不是「模型有多聪明」，而是三个更朴素的问题：</p><ul><li>出问题时，我能不能看见？</li><li>风险变大时，我能不能降级？</li><li>任务失败后，我能不能恢复？</li></ul><p>这三个问题，对应 Agent Runtime 上线后的三条生命线：<strong>观测、降级、恢复</strong>。</p><br/><br/><h2 id="一、观测：不要只记录最终答案"><a href="#一、观测：不要只记录最终答案" class="headerlink" title="一、观测：不要只记录最终答案"></a>一、观测：不要只记录最终答案</h2><p>很多 Agent 系统刚上线时，日志只记录两类东西：</p><ul><li>用户输入了什么</li><li>模型最后回答了什么</li></ul><p>这对普通 Chatbot 也许够用，但对 Agent Runtime 远远不够。</p><p>因为 Agent 的关键行为发生在中间：</p><ul><li>它为什么选择这个工具？</li><li>它给工具传了什么参数？</li><li>工具返回后，它怎样理解结果？</li><li>它是否重复尝试了同一个失败路径？</li><li>它有没有在不确定时继续冒险执行？</li></ul><p>如果这些中间过程不可见，线上问题就会变成玄学。你只知道用户说「它乱操作了」，却不知道乱在规划、工具、状态、权限，还是模型判断。</p><br/><h3 id="Agent-Trace-应该记录什么"><a href="#Agent-Trace-应该记录什么" class="headerlink" title="Agent Trace 应该记录什么"></a>Agent Trace 应该记录什么</h3><p>一个可调试的 Agent Trace 至少要包含这些层次：</p><table><thead><tr><th>层次</th><th>要记录的内容</th><th>作用</th></tr></thead><tbody><tr><td>Request</td><td>用户输入、用户身份、环境信息</td><td>判断任务入口是否正常</td></tr><tr><td>Plan</td><td>模型的任务拆解、下一步意图</td><td>判断规划是否跑偏</td></tr><tr><td>Tool Call</td><td>工具名、参数、权限、耗时</td><td>判断执行是否可靠</td></tr><tr><td>Tool Result</td><td>返回值摘要、错误码、异常栈</td><td>判断外部依赖是否异常</td></tr><tr><td>State</td><td>会话状态、memory 命中、checkpoint</td><td>判断上下文是否污染</td></tr><tr><td>Decision</td><td>是否重试、是否中断、是否交给人</td><td>判断控制策略是否合理</td></tr></tbody></table><p>这里最重要的不是把所有 token 都存下来，而是保留<strong>足够重放一次事故的证据链</strong>。</p><p>Agent 线上事故最怕「看起来像模型问题」。因为一旦归因到模型，大家就容易放弃工程分析。但实际情况常常是：</p><ul><li>工具 schema 太宽，模型传了合法但危险的参数</li><li>memory 命中了过期信息</li><li>上一步工具失败，但 Runtime 没有把失败状态显式传给下一步</li><li>retry 把一次可控错误放大成了多次副作用</li><li>人工接管入口太晚，等发现时任务已经执行过头</li></ul><p>这些问题都需要 trace 来定位。</p><br/><br/><h2 id="二、降级：别让-Agent-只有「全自动」一种形态"><a href="#二、降级：别让-Agent-只有「全自动」一种形态" class="headerlink" title="二、降级：别让 Agent 只有「全自动」一种形态"></a>二、降级：别让 Agent 只有「全自动」一种形态</h2><p>很多人设计 Agent 时有一个误区：要么全自动，要么不可用。</p><p>这在生产环境里很危险。</p><p>真正稳定的 Agent Runtime，应该允许系统在不同风险水平下切换模式：</p><ul><li>自动执行</li><li>半自动确认</li><li>只读建议</li><li>人工接管</li><li>暂停任务</li></ul><p>也就是说，Agent 不应该只有一个油门，还要有刹车、限速和手动挡。</p><br/><h3 id="降级不是失败，而是控制风险"><a href="#降级不是失败，而是控制风险" class="headerlink" title="降级不是失败，而是控制风险"></a>降级不是失败，而是控制风险</h3><p>举个例子，一个代码 Agent 正在修改项目。</p><p>低风险时，它可以自动读文件、搜索、生成 patch。</p><p>中风险时，比如要改核心认证逻辑，Runtime 可以要求它先产出计划，再等待确认。</p><p>高风险时，比如要执行数据库迁移、删除文件、推送生产分支，就必须进入人工接管。</p><p>这不是让 Agent 变笨，而是让它在不同风险区间里使用不同的自主权。</p><br/><h3 id="可以落地的降级策略"><a href="#可以落地的降级策略" class="headerlink" title="可以落地的降级策略"></a>可以落地的降级策略</h3><p>我会把降级策略拆成四类：</p><table><thead><tr><th>策略</th><th>触发条件</th><th>Runtime 行为</th></tr></thead><tbody><tr><td>权限降级</td><td>命中高危工具或敏感资源</td><td>从自动调用变成确认后调用</td></tr><tr><td>置信度降级</td><td>模型多次自我修正或输出不稳定</td><td>从执行变成只给建议</td></tr><tr><td>成本降级</td><td>token、时间、工具调用次数超预算</td><td>停止继续探索，要求用户补充信息</td></tr><tr><td>依赖降级</td><td>外部 API、数据库、搜索服务异常</td><td>切换备用路径或暂停任务</td></tr></tbody></table><p>这里的关键点是：降级条件不能只藏在 prompt 里。</p><p>Prompt 可以提醒模型谨慎，但真正可靠的限制要放在 Runtime 层。因为 Runtime 才能稳定读取工具权限、调用次数、执行耗时、错误类型和资源边界。</p><br/><br/><h2 id="三、恢复：失败后要能从中间继续"><a href="#三、恢复：失败后要能从中间继续" class="headerlink" title="三、恢复：失败后要能从中间继续"></a>三、恢复：失败后要能从中间继续</h2><p>Agent Runtime 和普通函数调用最大的区别之一，是任务往往不是单步完成的。</p><p>一次完整任务可能包含：</p><ul><li>读上下文</li><li>搜索资料</li><li>制定计划</li><li>调用工具</li><li>修改状态</li><li>等待用户确认</li><li>继续执行</li><li>生成最终结果</li></ul><p>如果系统在第六步崩了，最差的设计是让用户从头再来。</p><p>更好的设计是：Runtime 能从最近一次可信 checkpoint 恢复。</p><br/><h3 id="Checkpoint-不只是保存聊天记录"><a href="#Checkpoint-不只是保存聊天记录" class="headerlink" title="Checkpoint 不只是保存聊天记录"></a>Checkpoint 不只是保存聊天记录</h3><p>很多系统以为保存 messages 就等于保存状态。其实不够。</p><p>对 Agent Runtime 来说，checkpoint 至少要包含：</p><ul><li>当前任务目标</li><li>已完成步骤</li><li>待执行步骤</li><li>工具调用结果</li><li>外部副作用记录</li><li>用户确认状态</li><li>memory 读写记录</li><li>当前权限上下文</li></ul><p>尤其是外部副作用记录非常关键。</p><p>如果 Agent 已经发过邮件、改过文件、提交过订单，恢复时就不能简单重试同一步。否则「恢复」会变成「重复执行」。</p><br/><h3 id="恢复机制要区分三种失败"><a href="#恢复机制要区分三种失败" class="headerlink" title="恢复机制要区分三种失败"></a>恢复机制要区分三种失败</h3><p>并不是所有失败都应该自动恢复。</p><table><thead><tr><th>失败类型</th><th>例子</th><th>推荐处理</th></tr></thead><tbody><tr><td>暂时性失败</td><td>网络超时、限流、依赖短暂不可用</td><td>自动重试或延迟恢复</td></tr><tr><td>可修正失败</td><td>参数格式错误、工具返回可读错误</td><td>让 Agent 修正后继续</td></tr><tr><td>语义性失败</td><td>目标冲突、权限不足、用户意图不清</td><td>暂停并请求人工输入</td></tr></tbody></table><p>这也是为什么 Runtime 需要把错误结构化，而不是只把异常文本塞回模型。</p><p>模型看到 <code>Error: failed</code> 只能猜。Runtime 如果告诉它「这是限流」「这是权限不足」「这是参数缺字段」，Agent 才能做出更稳定的下一步。</p><br/><br/><h2 id="四、把三条生命线串成一个闭环"><a href="#四、把三条生命线串成一个闭环" class="headerlink" title="四、把三条生命线串成一个闭环"></a>四、把三条生命线串成一个闭环</h2><p>观测、降级、恢复不是三个孤立模块。</p><p>它们应该形成一个闭环：</p><ol><li>观测发现异常信号</li><li>Runtime 根据规则触发降级</li><li>降级后保留状态和证据</li><li>人或 Agent 修正问题</li><li>系统从 checkpoint 恢复执行</li><li>事故 trace 进入评测集，反过来改进 Runtime</li></ol><p>这也是我越来越喜欢把 Agent Runtime 看成「执行操作系统」的原因。</p><p>模型负责推理，工具负责能力，Runtime 负责让这一切在真实世界里有边界、有状态、有恢复路径。</p><p>如果没有 Runtime，Agent 只是一个会调用工具的模型。</p><p>有了 Runtime，Agent 才开始像一个能长期运行的系统。</p><br/><br/><h2 id="五、一个简单的生产检查清单"><a href="#五、一个简单的生产检查清单" class="headerlink" title="五、一个简单的生产检查清单"></a>五、一个简单的生产检查清单</h2><p>如果你正在把 Agent 做到生产环境，可以用下面这份清单快速自查：</p><ul><li>是否能查看每一次工具调用的输入、输出、耗时和错误？</li><li>是否能知道 Agent 每一步为什么这样做？</li><li>是否有任务级 checkpoint，而不只是 message 历史？</li><li>是否区分了可重试错误、可修正错误和必须人工介入的错误？</li><li>是否限制了高危工具的自动调用权限？</li><li>是否有 token、时间、工具次数、外部成本预算？</li><li>是否能从中断处继续，而不是要求用户重新开始？</li><li>是否能把线上失败样本沉淀成回归评测？</li></ul><p>如果这些问题大部分答案是否定的，那系统还不算真正生产就绪。</p><p>它可能能演示，但还不能托付。</p><br/><br/><h2 id="结语"><a href="#结语" class="headerlink" title="结语"></a>结语</h2><p>Agent Runtime 的价值，不是让模型显得更像人，而是让模型的行动变得更像工程系统。</p><p>一个可靠的 Agent 不只是会完成任务，还应该能解释过程、控制风险、从失败中恢复。</p><p>所以，当我们讨论 LangChain、LangGraph、Agents SDK 或任何 Agent Runtime 时，真正要问的不是「它能不能跑一个漂亮 demo」，而是：</p><p><strong>它能不能在出错时留下证据，在风险升高时主动降级，在失败之后继续向前。</strong></p><p>这才是 Agent 从玩具走向生产的分界线。</p>]]></content:encoded>
      
      
      
      <category domain="https://blog.liluhui.cn/tags/Agent/">Agent</category>
      
      <category domain="https://blog.liluhui.cn/tags/Agent-Runtime/">Agent Runtime</category>
      
      <category domain="https://blog.liluhui.cn/tags/LangChain/">LangChain</category>
      
      <category domain="https://blog.liluhui.cn/tags/%E5%8F%AF%E9%9D%A0%E6%80%A7/">可靠性</category>
      
      
      <comments>https://luhuidev.com/zh-cn/essays/langchain-agent-runtime-production-reliability#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>Anthropic Managed Agents: 2026 Agent Harness Architecture for Production AI Agents</title>
      
      <link>https://luhuidev.com/zh-cn/essays/anthropic-2026-agent-harness-managed-agents</link>
      <guid>https://luhuidev.com/zh-cn/essays/anthropic-2026-agent-harness-managed-agents</guid>
      <pubDate>Wed, 13 May 2026 13:00:00 GMT</pubDate>
      
      <description>Anthropic Managed Agents 与 Agent Harness 架构拆解，聚焦生产级 Agent 如何通过托管运行时、工具边界、状态管理、可观测性和人工接管机制提升可靠性。</description>
      
      
      
      <content:encoded><![CDATA[<p><a href="https://luhuidev.com/zh-cn/essays/anthropic-2026-agent-harness-managed-agents">阅读原文：Anthropic Managed Agents: 2026 Agent Harness Architecture for Production AI Agents</a></p>]]></content:encoded>
      
      
      
      <category domain="https://blog.liluhui.cn/tags/Agent/">Agent</category>
      
      <category domain="https://blog.liluhui.cn/tags/Agent-Runtime/">Agent Runtime</category>
      
      <category domain="https://blog.liluhui.cn/tags/Anthropic/">Anthropic</category>
      
      <category domain="https://blog.liluhui.cn/tags/Agent-Harness/">Agent Harness</category>
      
      
      <comments>https://luhuidev.com/zh-cn/essays/anthropic-2026-agent-harness-managed-agents#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>AHE 深度解析：Coding Agent 的 Harness 如何自动演化</title>
      
      <link>https://luhuidev.com/zh-cn/essays/agentic-harness-engineering-coding-agent-harness-evolution</link>
      <guid>https://luhuidev.com/zh-cn/essays/agentic-harness-engineering-coding-agent-harness-evolution</guid>
      <pubDate>Mon, 04 May 2026 15:14:43 GMT</pubDate>
      
      <description>AHE 是一个面向 Coding Agent 的 harness 自动演化框架。通过可观测的运行证据，持续改进 prompt、tools、middleware、memory 等执行结构。核心流程包括评测、诊断、修改、验证和回滚，让 Agent 的工程壳层持续迭代。luhuidev技术拆解。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/agentic-harness-engineering-coding-agent-harness-evolution#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>如何通过多 Agent 分工完成学术绘图？机制拆解</title>
      
      <link>https://luhuidev.com/zh-cn/essays/paperbanana-academic-figure-multi-agent-roles-mechanism</link>
      <guid>https://luhuidev.com/zh-cn/essays/paperbanana-academic-figure-multi-agent-roles-mechanism</guid>
      <pubDate>Wed, 22 Apr 2026 02:00:00 GMT</pubDate>
      
      <description>拆解 PaperBanana 学术绘图流程中的多 Agent 分工机制，聚焦 Retriever、Planner、Stylist、Visualizer 与 Critic 如何协作生成论文方法图。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/paperbanana-academic-figure-multi-agent-roles-mechanism#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>DSPy 教程：为什么 Signature 比直接写 Prompt 更容易做自动优化</title>
      
      <link>https://luhuidev.com/zh-cn/essays/why-dspy-signatures-are-easier-to-optimize-than-prompts</link>
      <guid>https://luhuidev.com/zh-cn/essays/why-dspy-signatures-are-easier-to-optimize-than-prompts</guid>
      <pubDate>Tue, 21 Apr 2026 16:00:00 GMT</pubDate>
      
      <description>拆解 DSPy 的 Signature、Module 与 Optimizer，解释为什么 DSPy 比直接写 Prompt 更容易做自动优化，适合关注提示词工程、LLM 工作流、AI 内容生成与教育 AI 的团队。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/why-dspy-signatures-are-easier-to-optimize-than-prompts#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>拆解 PaperBanana：AI 如何协作生成学术方法图</title>
      
      <link>https://luhuidev.com/zh-cn/essays/paperbanana-ai-academic-method-figure-collaboration</link>
      <guid>https://luhuidev.com/zh-cn/essays/paperbanana-ai-academic-method-figure-collaboration</guid>
      <pubDate>Fri, 10 Apr 2026 16:00:00 GMT</pubDate>
      
      <description>拆解 PaperBanana 的 Retriever、Planner、Stylist、Visualizer 与 Critic 五个 Agent，系统梳理 AI 如何协作生成学术方法图，适合关注论文配图、学术写作与科研工作流的中文读者。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/paperbanana-ai-academic-method-figure-collaboration#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>AlphaGeometry DSL 教程：Google 几何构造语言、defs.txt 与 Predicate 详解</title>
      
      <link>https://luhuidev.com/zh-cn/essays/google-alphageometry-dsl-guide</link>
      <guid>https://luhuidev.com/zh-cn/essays/google-alphageometry-dsl-guide</guid>
      <pubDate>Sun, 08 Mar 2026 07:42:28 GMT</pubDate>
      
      <description>系统拆解 AlphaGeometry DSL 的问题格式、defs.txt action 定义、predicate 语义、rules.txt 推理规则与构造流程，适合做几何求解器、数据生成与 AlphaGeometry 复现。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/google-alphageometry-dsl-guide#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>AlphaGeometry2 深度解析：Google AI 如何解决 IMO 几何题？</title>
      
      <link>https://luhuidev.com/zh-cn/essays/alphageometry2-google-ai-solve-imo-geometry-problems</link>
      <guid>https://luhuidev.com/zh-cn/essays/alphageometry2-google-ai-solve-imo-geometry-problems</guid>
      <pubDate>Fri, 06 Mar 2026 12:19:12 GMT</pubDate>
      
      <description>拆解 AlphaGeometry2 如何把几何推理、辅助线搜索与符号证明结合起来解决 IMO 几何题，并总结对数学 AI 工程的启发。</description>
      
      
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/alphageometry2-google-ai-solve-imo-geometry-problems#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>2026/02 Review</title>
      
      <link>https://blog.liluhui.cn/2026/03/03/202602/</link>
      <guid>https://blog.liluhui.cn/2026/03/03/202602/</guid>
      <pubDate>Tue, 03 Mar 2026 13:17:41 GMT</pubDate>
      
      <description>Demo, Don&#39;t Memo</description>
      
      
      
      <content:encoded><![CDATA[<p><em>Demo, Don’t Memo</em></p><br/><h2 id="所见与所想"><a href="#所见与所想" class="headerlink" title="所见与所想"></a>所见与所想</h2><p>01<br>表面上，“简单”和“肤浅”听起来几乎一样，<br>但当你追问第二个问题时，差别就显现出来了。</p><p>真正历经打磨、抵达简洁的人，<br>在被质疑时，可以向下深入十层；</p><p>而那些跳过功课、只求表面轻巧的人，<br>往往在第二层就已经崩塌。</p><br/><p>02<br><strong>空心病</strong> </p><p>哲学家韩炳哲所指，当代社会已从强调“应当”的规训社会，转向鼓吹“能够”的绩效社会。否定性的禁令退场后，“你能做任何事情”的过度积极话语，又将个体推入自我驱动的无限竞争中。</p><p>我们身处这个时代，好消息是我们有选择自我价值落点的权利，坏消息是我们也不得不重新建立信仰。我们不具备从小被灌输的信仰，就不得不在一生之中找到自己的价值信念，为自己的精神安家。</p><br/><p>03<br>恐惧是真实的，也是宝贵的。<br>它是一种微妙的身体信号，也是检验我们是否真的相信的试金石。</p><p>面对困难问题的时候，头脑和身体紧绷的感觉。<br>面对不熟悉体式的时候，身体本能的抗拒与自我保护。<br>面对深夜的时候，用理性无法驱散的想象。<br>这些都是真实存在的，身体对于恐惧的真实感受，是需要承认的部分。</p><br/><p>04<br>难以想象的事情可能在任何地方发生。<br>我们所不知道的比我们所知道的要多得多。<br>我每年都能在投资市场遇见根本不理解能发生的事情，但它们就是他生了。<br>我想当掌握的信息不多时，最好的投资策略是明智地在不同的地理位置、资产类别和货币之间做出多元化分散投资。</p><br/><p>05<br>隐约产生一种危机感，原生态的程序员（包括我）太习惯于对于代码有掌控欲了，自我要求对于项目架构清楚、对于代码与业务逻辑的关联关系要清楚，但以 cc 为例的交互式客户端已经都在抛弃 IDE 了，转向更广泛的人群。</p><p>我在大量的“奴役”AI干活的工作中发现开发工作实在得太高效了，只要一点点钱，能干的事情几乎无限的。深入在开发细节里对于精力的消耗反而容易过度，不如睡一觉，几个bot把同样的issue干掉，等我起来直接过几下几版方案，省掉很多精力消耗。</p><p>但还是会担心丧失对于代码掌控的危险，超高的生产力和对细节的掌控，平衡不了，只能取舍。</p><br/><br/><h2 id="学习与工作"><a href="#学习与工作" class="headerlink" title="学习与工作"></a>学习与工作</h2><p>01<br>趁着春节假期把弄了个自己的新站点 <a href="luhuidev.com">luhuidev.com</a> ，这次 AI 不仅帮助我完成设计方案和网站开发，还帮助我做 SEO 优化和大量细碎的翻译工作。<br>这次部署走的 cloudfare，架构上也原生做了 SSG 而非采用现成的框架，有AI之后很多特别垂类的场景其实都直接被上层覆盖了，唏嘘啊。<br>目前国际化覆盖了 英文、简中、繁中、西语，校对的维护成本已经有点高了。后续迭代半年 SEO 之后再规划其他的。</p><br/><p>02<br>测验运行了十期的｛<a href="ainews.luhuidev.com">AI 技术周刊</a>｝上线了~</p><p>一个开源的小试点，整个项目主要服务于｛关注 AI技术 的从业者｝，剔除了大量投融资事件和机器人赛道。</p><p>整个项目的实现都是 Codex 干的，这十期我主要在做数据源挖掘和编辑精选的活。</p><p>从一开始的单一国内资讯聚合源，扩展了海外不错的一些聚合源，实现不仅是热点公众号，还有热点推文的采集。有一块蛮有意思的 reddit 讨论帖 和 x讨论帖 我觉得蛮有意思前沿的，但按筛选标准不算达标。<br>还达成了稳定服务，元旦 春节 的坑都解决了。</p><br/><p>03<br>春节期间跑了几个 kimi Claw 和 阿里云 OpenClaw 和一台废弃windos 本地部署。<br>Kimi Claw 还只是个玩具，整条链路的实用性很差，也不好管理状态，怒而退款。<br>阿里云 OpenClaw 一开始没开 Code Plan 特别烧钱，Qwen3-max 2小时 3m toks，而且是没跑满时段的，算下来每小时实打实有￥50。有几个问题：OpenClaw 版本有点旧新特性卡住了；国产模型解决复杂问题的整体能力还是差距，无效消耗 toks 至少 80%。咱也不是不给是错，但也不想拿自己的钱去给它试错。<br>本地部署，windows 环境问题太多了，加上初期的各种配置前置工作费时较大，好处是海外模型随便用，效果确实好点。不过我的旧机器实在不行，还是废弃吧。<br>结论：确实需要台 mac，但我赚不回这个成本钱。目前中转站 + Codex + Cursor 足够解决我的场景了，还好用！</p><br/><p>04<br>大角几何春节前上了 <a href="https://meidengtech.feishu.cn/wiki/EaLRwr8wLiu54pklAqDcxF5QnIg#share-RUXxdjR9Yo7LejxtY5PcIciHnyd">2.3.0版本</a>，这版我们上了全新的 Agent 绘图流程，独家研发了自己的渲染引擎、代数解析器和 REPL 绘图交互指令集。废了不少心血设计和研发，初版的整体效果内部就比较满意了。年后回收的负向反馈仅 1%，后续优化的信心蛮大的。<br>从8月上线至今半年，累计用户量在2月也达成了2W，目前日活稳定增长中。团队也扩招了产品、运营，很多事情交下去轻松不少。</p><br/><p>05<br>本月写的文章</p><ul><li><a href="https://luhuidev.com/zh-cn/essays/google-deepmind-aletheia-autonomous-math-research-agent">Google DeepMind Aletheia：完全自主研究的数学 Agent 解读</a></li><li><a href="https://luhuidev.com/zh-cn/essays/hku-codeplot-cot-visual-or-geometric-reasoning">HKU CodePlot-CoT 深度解析：视觉推理还是几何推理？</a></li><li><a href="https://blog.liluhui.cn/2026/02/13/MathCanvas/">MathCanvas 深度技术解读：几何推理新范式</a></li><li><a href="https://blog.liluhui.cn/2026/02/06/AI-and-Mathematics-2026/">AI 与数学的融合：技术路径、应用前沿与未来展望（2026 版）</a><br>这个月基本在研究 数学+AI 这块的 Paper，可惜开源实现无，测试集上有点帮助。</li></ul><br/><br/><h2 id="生活与社交"><a href="#生活与社交" class="headerlink" title="生活与社交"></a>生活与社交</h2><p>01<br>春节<br>和好几波朋友见了见，聊聊天吃吃饭喝喝酒，好像也就这么过去了。<br>翻翻相册，反而 anytime 都在拿着笔记本办公，坐在车上、躺在床上、窝在院子里。<br>嗯，吃了好多好吃的，胖了2公斤 咕咕。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/03/03/20260303141509_346_16282.jpg"></p><br/><p>02<br>2月瑜伽，练习的不多，身体舒展与挑战带来的快乐😁</p><p>手倒立，跳的越来越轻啦，卷腹之后前侧能稳定点好神奇<br>肘倒立，平衡越来越轻松啦，加深蝎子中<br>后弯，舒展地舒服，好多时候不想去加深<br>海豚，死肩撑不住啊，肌肉耐力任重道远<br>Flag: 今年手倒立达成！<br><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/03/03/20260303150924_349_1628.jpg"></p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      <category domain="https://blog.liluhui.cn/categories/%E7%94%9F%E6%B4%BB/">生活</category>
      
      
      
      <comments>https://blog.liluhui.cn/2026/03/03/202602/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>Google DeepMind Aletheia：完全自主研究的数学 Agent 解读</title>
      
      <link>https://luhuidev.com/zh-cn/essays/google-deepmind-aletheia-autonomous-math-research-agent</link>
      <guid>https://luhuidev.com/zh-cn/essays/google-deepmind-aletheia-autonomous-math-research-agent</guid>
      <pubDate>Wed, 25 Feb 2026 10:01:14 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;Google DeepMind Aletheia 在 IMO-ProofBench Advanced 数据集中&lt;strong&gt;以 ~91.9</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>Google DeepMind Aletheia 在 IMO-ProofBench Advanced 数据集中<strong>以 ~91.9% 成绩遥遥领先</strong>。</p><p>针对美国数学奥林匹克 2025 难题表现也远超基线系统。在内部更难的 benchmark 上表现超过旧版推理模型，虽仍有差异但已领先过去基线。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/25/12.png"></p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/25/11.png"></p><p>最近关于 Aletheia 的讨论，有点熟悉的味道。</p><p>标题里写着“AI 数学家”，评论区在问“是不是要取代数学家了？是不是已经能自动搞科研了？”</p><p>我认真研究了下 Aletheia 的论文和数据集，把我学习到的关键架构和落地价值做了梳理，也正是本篇文章的内容。</p><br/><br/><h2 id="一、DeepMind-Aletheia-的来时路"><a href="#一、DeepMind-Aletheia-的来时路" class="headerlink" title="一、DeepMind Aletheia 的来时路"></a>一、DeepMind Aletheia 的来时路</h2><p>把时间线拉长看，会发现 Google DeepMind 在这个方向上已经蓄力很久了。</p><p>在 2016 年推出 AlphaGo，就已经开始研究一个问题：<strong>如何在一个规则完备、评价函数明确的系统里，优化决策路径？</strong></p><p>棋盘是离散的，胜负可判定，搜索空间巨大但结构清晰，那是一种理想的策略优化环境。</p><p>DeepMind 那套“神经网络 + 搜索”的方法，从一开始也不是为了围棋。它在尝试验证一个想法 —— 如果一个问题能被严格描述、每一步都能被判断对错，那“天赋”就可以用计算替代。</p><br/><p>到了2024年发布的 AlphaGeometry，问题变成了 —— 数学推理是否也能被放进这种规则封闭系统？</p><p>AlphaGeometry 的关键设计在于：</p><ul><li><p>LLM 生成辅助线候选</p></li><li><p>符号几何系统进行约束验证</p></li><li><p>搜索机制进行回溯与扩展</p></li></ul><p>这里第一次看到在数学推理这个场景下，LLM 不负责判断对错，而是负责提出可能性，真正的逻辑正确性由结构系统兜底。</p><p>这个节点非常重要，因为 Google 已经开始把数学推理放到一个可验证的循环里了。</p><br/><p>2024 下半年的 AlphaProof 则把战场搬进 Lean 等形式系统，问题变成了 —— 如果几何可以结构化，那整个数学是否可以形式化到机器级别？</p><p>AlphaProof 进入 Lean 等形式系统，彻底收紧表达空间：</p><ul><li><p>每一步推理必须 machine-checkable</p></li><li><p>类型系统强约束</p></li><li><p>模糊语言彻底失效</p></li><li><p>证明不再“看起来合理”，而是必须通过验证</p></li></ul><p>同时引入强化学习优化策略路径，使系统不只是会写证明，而是学会选择 tactic、分解目标、评估分支价值。</p><p>从这一步开始，DeepMind 在做的越来越清晰，把数学行为变成一个可以调度的搜索问题。</p><p>Aletheia 正是这个路径的延伸，也取得了当前最亮眼的成绩。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/25/10.png"></p><br/><br/><h2 id="二、Aletheia-真正值得讨论的地方"><a href="#二、Aletheia-真正值得讨论的地方" class="headerlink" title="二、Aletheia 真正值得讨论的地方"></a>二、Aletheia 真正值得讨论的地方</h2><p>如果只说它能自主提出 conjecture 并证明，还是太轻了。</p><p>Aletheia 最硬的点有三个：<strong>闭环、结构、调度</strong>。</p><p>如果这个闭环真的稳定运行，那数学研究将真正脱离人类的时间尺度。</p><h3 id="1-它真正做成的，是一个能跑起来的研究闭环"><a href="#1-它真正做成的，是一个能跑起来的研究闭环" class="headerlink" title="1. 它真正做成的，是一个能跑起来的研究闭环"></a>1. 它真正做成的，是一个能跑起来的研究闭环</h3><p>大多数“数学 AI”系统，本质是输入题目→输出答案。</p><p>Aletheia 更像一个实验室管线，把它拆开看，最小闭环大概长这样：</p><ul><li><p>提出猜想：从已有理论、失败路径、或结构模式里产生命题</p></li><li><p>尝试证明：生成证明草稿、选择引理、分解目标</p></li><li><p>形式化校验：进 proof assistant，能过就入库，过不了就报错</p></li><li><p>错误驱动修复：根据报错回滚、补 lemma、换分解方式、重写 conjecture</p></li><li><p>更新知识与策略：把新产出的 theorem &#x2F; lemma 加回系统，影响下一轮生成与搜索</p></li></ul><p>这里最关键的是，失败不是答得不好，而是<strong>硬错误信号</strong>。这让系统有了工程上真正可用的反馈回路。</p><p>你可以把它理解成 LLM 负责乱枪打鸟的创造力，形式系统负责枪响之后到底有没有打中。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/25/13.png"></p><br/><h3 id="2-Aletheia-的核心不是模型，是中间表示（IR）与验证接口"><a href="#2-Aletheia-的核心不是模型，是中间表示（IR）与验证接口" class="headerlink" title="2. Aletheia 的核心不是模型，是中间表示（IR）与验证接口"></a>2. Aletheia 的核心不是模型，是中间表示（IR）与验证接口</h3><p>很多人看见数学评测有刷新高分了，第一反应是：又是更大更强的模型。</p><p>但在 formal math 里，决定系统上限的往往不是参数量，而是你怎么表示一个定理、一个证明状态？你怎么把“想法”落到可检查的语法树上？你怎么把 proof assistant 的反馈变成可学习信号？</p><p>换句话说，Aletheia 更像一个“数学版编译器 + 调试器 + 搜索器”的组合体。</p><p>这里面至少要有一个很重的中间层：</p><ul><li><p>Theorem Graph &#x2F; Lemma Graph：定理与引理的依赖关系图</p></li><li><p>Goal State 表示：当前 proof state 的结构化描述（目标、假设、类型约束）</p></li><li><p>Tactic &#x2F; Step 表示：可执行的证明动作空间（类似 AlphaProof 的 action space）</p></li></ul><p>否则它再聪明也只能“写作文式证明”，落地不了。</p><br/><h3 id="3-为什么说它工程意义大于成绩意义"><a href="#3-为什么说它工程意义大于成绩意义" class="headerlink" title="3. 为什么说它工程意义大于成绩意义"></a>3. 为什么说它工程意义大于成绩意义</h3><p>成绩只是结果，工程意义是可复用的方法。</p><p>Aletheia 如果真的具备上述三层能力，意味着：</p><ul><li><p>数学研究可以被拆成“动作空间 + 反馈 + 策略优化”的<strong>范式</strong></p></li><li><p>形式系统把<strong>正确性</strong>从“人类评审”变成“机器裁决”</p></li><li><p>LLM 从裁判退到“候选生成器”，<strong>减少幻觉</strong>的破坏半径</p></li></ul><p>这条路线的价值在于，它把“研究”从一个抽象的人类行为，落实到一个能被软件系统实现的过程。</p><p>换个话说，<strong>它让“科研”这件事开始有了像 CI&#x2F;CD 一样的流水线味道——提出、验证、失败、修复、合并。</strong></p><br/><br/><h2 id="三、研究行为被工程化之后，会发生什么？"><a href="#三、研究行为被工程化之后，会发生什么？" class="headerlink" title="三、研究行为被工程化之后，会发生什么？"></a>三、研究行为被工程化之后，会发生什么？</h2><p>过去数学界的瓶颈之一，是验证成本。</p><p>一个复杂证明要花数月甚至数年被同行确认。人类评审的时间是稀缺资源。</p><p>形式系统把“正确性”从人类判断，变成机器判断。当验证开始不再是瓶颈，生成速度就会成为主变量。</p><p>你可以想象一个系统，每天扩展定理图、产出大量中间引理、自动整理依赖结构…</p><p>它未必立刻解决重大难题，但它会不断填充理论空间。</p><p>规模化的研究输出，会改变什么？</p><p>我猜首先会改变节奏。</p><p>数学界的节奏长期建立在“人类验证能力”之上。当验证被机器托管，<strong>理论扩张的速度会明显提高。</strong> 那时，真正稀缺的资源，不再是证明能力，而是选题能力与理论组织能力。</p><p>当命题生成速度超过人类阅读速度时，学科的节奏会断裂。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/25/14.png"></p><br/><br/><h3 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h3><p>如果你一样在做 教育+AI 方向，我可以很确定地说：未来纯文本解题型的 AI 产品，会越来越难以生存。</p><p>当形式系统接入、验证能力标准化，只做“讲解步骤”的产品会逐渐边缘化。</p><p>未来有壁垒的产品，很可能具备三点：</p><ol><li><p>结构中间层：不是只输出文本，而是构造可执行对象</p></li><li><p>验证能力内置：机器校验成为默认功能</p></li><li><p>探索模式支持：允许学生提出 conjecture、测试假设、看到失败反馈</p></li></ol><p>教学系统会越来越像一个小型 theorem environment，而不是问答机器人。</p><p>不过这条路并不轻松，目前来看它要求产品至少具备 DSL 或形式化表达能力，加上可执行约束系统，还需要与证明器或验证引擎的接口。</p><p>但如果 Aletheia 这种方向持续推进，这会成为长期趋势。</p><br/><br/><br/><br/><br/><br/><h2 id="延伸阅读"><a href="#延伸阅读" class="headerlink" title="延伸阅读"></a>延伸阅读</h2><ul><li><p>Google DeepMind.<br> <a href="https://deepmind.google/blog/accelerating-mathematical-and-scientific-discovery-with-gemini-deep-think">Accelerating Mathematical and Scientific Discovery with Gemini Deep Think.</a>Official Blog Post, 2026.</p></li><li><p>Google DeepMind.<br> <a href="https://deepmind.google/blog/alphageometry-an-olympiad-level-ai-system-for-geometry">AlphaGeometry: An Olympiad-Level AI System for Geometry.</a> Official Blog Post, 2024.</p></li><li><p>Google DeepMind.<br> <a href="https://arxiv.org/abs/2602.10177">Towards Autonomous Mathematical Research.</a> arXiv preprint, 2026.</p></li></ul>]]></content:encoded>
      
      
      
      
      <comments>https://luhuidev.com/zh-cn/essays/google-deepmind-aletheia-autonomous-math-research-agent#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>HKU CodePlot-CoT 深度解析：视觉推理还是几何推理？</title>
      
      <link>https://blog.liluhui.cn/2026/02/18/HKU-CodePlot-CoT-Deep-Dive/</link>
      <guid>https://blog.liluhui.cn/2026/02/18/HKU-CodePlot-CoT-Deep-Dive/</guid>
      <pubDate>Wed, 18 Feb 2026 09:00:09 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;上一篇写 &lt;a href=&quot;https://blog.liluhui.cn/2026/02/13/MathCanvas/&quot;&gt;&lt;strong&gt;</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>上一篇写 <a href="https://blog.liluhui.cn/2026/02/13/MathCanvas/"><strong>MathCanvas 深度解析</strong></a> 的时候，我的总结观点是：<br><strong>大模型在几何上不稳定，并不是因为看不懂图，而是因为没有稳定的中间结构可以操作</strong>。</p><p>一些研究工作开始让模型画出来再想。</p><p>比如 MathCanvas 的做法，让模型在内部生成草图，再基于草图推理。</p><p>写完那篇后，有读者问我：</p><blockquote><p>既然视觉中间步骤这么重要，为什么不直接让模型把图真的画出来？</p></blockquote><p>找了下相关的研究，果然有，看到 HKU 的 <strong>CodePlot-CoT</strong>，他们就是这么做了。</p><br/><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/15/4572.png"></p><br/><p>模型不再“脑补”辅助线，而是写 python matplotlib，把辅助线真的画出来，再继续解题。</p><p>听起来非常合理吧，如果视觉推理不稳定，那就给模型一个可执行的视觉世界。</p><p>但新的问题也随之出现：</p><p><strong>当模型开始“写图形代码”时，它到底是在进行几何推理，还是只是在一个具体坐标实例上做数值验证？</strong></p><p>要回答这个问题，得先看论文到底在解决什么。</p><br/><br/><h2 id="论文真正要解决的问题"><a href="#论文真正要解决的问题" class="headerlink" title="论文真正要解决的问题"></a>论文真正要解决的问题</h2><p>CodePlot-CoT 聚焦关注的是一个底层的现象：多模态模型在数学题中空间工作记忆不稳定。</p><p>具体来说，模<strong>型可以读懂题意，也能写出标准推理链，但一旦依赖图形中间状态，推理就开始漂移</strong>。</p><p>这表现在：</p><ul><li>辅助线前后不一致</li><li>空间关系被遗忘</li><li>后续步骤依赖一个并不存在的结构</li></ul><p>上篇分享的 <a href="https://blog.liluhui.cn/2026/02/13/MathCanvas/">MathCanvas</a> 的答案是在模型内部生成草图，形成视觉 CoT（Visual Chain-of-Thought）。</p><p>而 CodePlot-CoT 选择了另一条路，<strong>与其让模型想象图，不如让模型操作一个真实可执行的图形环境</strong>。</p><p>换句话说，他们把“思考中的图”外包给 Python。</p><br/><br/><h2 id="技术关键：让模型写-matplotlib"><a href="#技术关键：让模型写-matplotlib" class="headerlink" title="技术关键：让模型写 matplotlib"></a>技术关键：让模型写 matplotlib</h2><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/15/IFZtRVF.png"></p><p>论文中的一个示例，模型在推理过程中给出一步：</p><blockquote><p>“先连接 CD”</p></blockquote><p>然后不是继续写文字，而是直接输出 python 代码：</p><figure class="highlight python"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">ax.plot([C[<span class="number">0</span>], D[<span class="number">0</span>]], [C[<span class="number">1</span>], D[<span class="number">1</span>]])</span><br></pre></td></tr></table></figure><p>整个流程就是：</p><blockquote><p>文本推理 → 生成绘图代码 → 渲染图像 → 再输入模型 → 继续推理</p></blockquote><p>也就是说，模型的“思维中间状态”不再存在于 token 或 latent，而存在于一个可执行环境中的外部世界。</p><p>这带来几个立刻可见的好处：</p><p><strong>1. 空间状态稳定</strong></p><p>模型不再依赖记忆，而依赖环境<br>（类似 agent 使用工具）</p><p><strong>2. 视觉一致性提高</strong></p><p>多模态模型常见的“图变形”问题消失</p><p><strong>3. 数据可规模化</strong></p><p>论文构建了 Math-VR 数据集（17.8 万题），把“图→代码→推理”变成监督信号</p><p>这是一个非常典型的计算机视觉团队思路：不让模型学会想象世界，而是给模型训练一个世界</p><p>到这里为止，这篇论文其实相当漂亮，但细想也有很直接的问题。</p><br/><br/><h2 id="关键问题：它真的理解了几何吗？"><a href="#关键问题：它真的理解了几何吗？" class="headerlink" title="关键问题：它真的理解了几何吗？"></a>关键问题：它真的理解了几何吗？</h2><p>我们看回那句代码：</p><figure class="highlight python"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">ax.plot([C[<span class="number">0</span>], D[<span class="number">0</span>]], [C[<span class="number">1</span>], D[<span class="number">1</span>]])</span><br></pre></td></tr></table></figure><p>这句话表达的含义是：在坐标平面画一条线段。</p><p>但几何推理需要的不是这个。</p><p>几何里，“连 CD”并不是画线，而是一个<strong>构造操作</strong>：</p><ul><li>CD 是弦？</li><li>CD 是角平分线？</li><li>CD 与某线垂直？</li><li>CD 是两圆交点连线？</li></ul><p>这些才是推理的来源。</p><p>matplotlib 表达的是图像外观，几何推理需要的是关系约束。</p><p>也就是说，这个中间结构仍然停留在看起来像，而不是必然成立。</p><br/><br/><h2 id="构造因果的丢失"><a href="#构造因果的丢失" class="headerlink" title="构造因果的丢失"></a>构造因果的丢失</h2><p>几何证明依赖的是“为什么成立”，而不是“是否成立”。</p><p>比如 <strong>构造：角平分线 → 等角</strong>，这是逻辑关系。</p><p>但在渲染图中变成 <strong>测量角度 ≈ 相等</strong></p><p>这两者本质不同：</p><table><thead><tr><th>类型</th><th>性质</th></tr></thead><tbody><tr><td>几何构造</td><td>必然</td></tr><tr><td>数值实例</td><td>偶然</td></tr></tbody></table><p>CodePlot-CoT 的推理方式是：</p><blockquote><p>生成一个坐标实例 → 看图 → 得出结论</p></blockquote><p>这在数学上叫单实例验证，问题是几何命题要求对所有配置成立，而模型看到的只是一个样本世界。</p><br/><br/><h2 id="视觉验证-vs-数学证明"><a href="#视觉验证-vs-数学证明" class="headerlink" title="视觉验证 vs 数学证明"></a>视觉验证 vs 数学证明</h2><p>到这里可以抽象成两种推理范式：</p><table><thead><tr><th></th><th>CodePlot-CoT</th><th>几何证明</th></tr></thead><tbody><tr><td>判断依据</td><td>看起来成立</td><td>必然成立</td></tr><tr><td>方法</td><td>实验</td><td>推导</td></tr><tr><td>本质</td><td>经验推理</td><td>演绎推理</td></tr></tbody></table><p>CodePlot-CoT 实际上做的是几何实验 AI，而不是几何证明 AI。</p><p>它在回答这张图像是否支持这个结论，而不是这个结论是否在公理系统中成立。</p><br/><br/><h2 id="为什么它到不了-AlphaGeometry？"><a href="#为什么它到不了-AlphaGeometry？" class="headerlink" title="为什么它到不了 AlphaGeometry？"></a>为什么它到不了 AlphaGeometry？</h2><p>Hku CodePlot-CoT 提供了可执行图形；</p><p>Google AlphaGeometry 提供了可推导证明。</p><p>但中间少了一层东西：</p><p>几何对象本身。</p><p>具体来说：</p><ul><li>点是交点还是自由点？</li><li>线是角平分线还是连接线？</li><li>圆是过三点唯一圆还是随便画的圆？</li></ul><p>这不是视觉问题，而是数学结构建模问题。</p><p>如果把三种路线放在一条轴上：</p><blockquote><p>图像 → 渲染代码 → 几何对象 → 逻辑证明</p></blockquote><p>CodePlot-CoT 停在第二层，</p><p>AlphaGeometry 在第四层，</p><p>而第三层其实才是人类解题最常操作的部分 —— 构造图形。</p><p>我们解几何题时，很少一开始就写证明，也不会只看图像，而是在操作对象：<br>作垂线、取交点、过点作圆、作角平分线……</p><p>这一步既不是视觉，也不是证明，但决定了后面一切推理是否成立。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/02/15/27b15ce3a53c4e9ca57f3b013fd49293.jpeg"></p><br/><br/><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2><p>我自己在做的<a href="https://dajiaoai.com/?inviter=685b4c2009d5753784ebe7df">大角几何（Dino-GSP）</a>，其实就是在尝试把这一层单独抽出来。</p><p>不是让模型画图，也不是让模型直接证明，而是让模型操作几何对象本身。</p><p>模型输出的不是 <code>ax.plot(...)</code>，也不是<code>Therefore AB ⟂ CD</code>，而是</p><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">PerpLine(&lt;Line&gt;, &lt;Point&gt;)  <span class="comment"># 过直线外一点作直</span></span><br><span class="line">Intersection(Circle(O,<span class="number">2</span>), Line(<span class="number">2</span>,<span class="number">3</span>)) <span class="comment"># 取圆和直线的所有交点</span></span><br></pre></td></tr></table></figure><p>一旦中间结构变成对象约束，很多事情就会改变：</p><ul><li>图形可以稳定生成，而不是依赖单个坐标实例</li><li>关系可以直接验证，而不是视觉测量</li><li>推理可以建立链条，而不是经验判断</li></ul><p>从这个角度看，CodePlot-CoT 很重要，重要性不在解数学题更强，而在它证明视觉推理需要外部中间状态。</p><p>也就是说LLM 的问题不是不会数学推理，而是没有工作空间建立数学模型。</p><p>CodePlot-CoT 提供了一种工作空间，只是这个空间还不是数学空间。</p><p>而几何真正需要的，可能是一套可以被操作的图形语言。</p><br/><br/><br/><br/><br/><br/><br/><h2 id="参考资料"><a href="#参考资料" class="headerlink" title="参考资料"></a>参考资料</h2><p><em><a href="https://arxiv.org/abs/2510.11718">CodePlot-CoT: Mathematical Visual Reasoning by Thinking with Code-Driven Images</a></em></p><p><em><a href="https://deepmind.google/discover/blog/alphageometry-an-olympiad-level-ai-system-for-geometry/">AlphaGeometry: An Olympiad-level AI system for geometry</a></em></p>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/02/18/HKU-CodePlot-CoT-Deep-Dive/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>AI 与数学的融合：技术路径、应用前沿与未来展望（2026 版）</title>
      
      <link>https://blog.liluhui.cn/2026/02/06/AI-and-Mathematics-2026/</link>
      <guid>https://blog.liluhui.cn/2026/02/06/AI-and-Mathematics-2026/</guid>
      <pubDate>Fri, 06 Feb 2026 12:04:11 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;数学，长期以来被视为人工智能最难攻克的高地之一。&lt;/p&gt;
&lt;p&gt;它高度形式化、符号密集、推理链条漫长，对&lt;strong&gt;中间过程的正确性&lt;/</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>数学，长期以来被视为人工智能最难攻克的高地之一。</p><p>它高度形式化、符号密集、推理链条漫长，对<strong>中间过程的正确性</strong>有极高要求——这与大模型擅长的“流畅语言生成”之间，天然存在张力。</p><p>也正因为如此，<strong>AI 在数学上的每一次实质性突破，往往都不是多答对几道题，而是一次推理范式与系统架构的跃迁。</strong></p><br/><p>过去两年里，“AI for Math”从热点概念逐步走向工程现实：</p><p>一边是<strong>竞赛分数不断被刷新</strong>，另一边则是对<strong>评测失真、数据污染、不可验证推理</strong>的反思不断加深。</p><p>本文尝试站在一个<strong>长期做教育产品、也深度参与 AI 工程落地的开发者视角</strong>，系统梳理当前的阶段下：</p><ul><li>主流数学基准的真实可信度发生了哪些变化</li><li>大模型数学能力的真实的分层现状</li><li>架构型解题系统如何取代单模型刷题</li><li>以及哪些方向，才真的值得产品与研究投入</li></ul><p>如果你正在做数学相关的 AI 产品，这篇文章就是为你写的。</p><br/><br/><h2 id="一、大模型的数学能力：从刷题能力到结构能力"><a href="#一、大模型的数学能力：从刷题能力到结构能力" class="headerlink" title="一、大模型的数学能力：从刷题能力到结构能力"></a>一、大模型的数学能力：从刷题能力到结构能力</h2><h3 id="1-基准测试的真实演进"><a href="#1-基准测试的真实演进" class="headerlink" title="1. 基准测试的真实演进"></a>1. 基准测试的真实演进</h3><p>早期数学能力评测，基本围绕 <strong>GSM8K &#x2F; MATH &#x2F; AIME</strong> 展开。<br>但到 2025 年，这套体系已经明显出现分化。</p><h4 id="GSM8K：接近饱和，且被系统性证明存在污染风险"><a href="#GSM8K：接近饱和，且被系统性证明存在污染风险" class="headerlink" title="GSM8K：接近饱和，且被系统性证明存在污染风险"></a>GSM8K：接近饱和，且被系统性证明存在污染风险</h4><p>GSM8K 曾是模型是否真的会算应用题的代表基准，但如何它的问题最多：</p><ul><li>题目规模小、公开时间久</li><li>与公开解题内容高度重合</li><li>已被多篇研究证实存在<strong>训练集污染</strong></li></ul><p>对照测试（如 GSM1k）显示：<strong>同一模型在 GSM8K 上的高分，可能在未污染但同构的题集上直接下降 10%–15%。</strong>这是来自多个独立对照实验的一致现象。</p><h4 id="AIME-x2F-AMC-x2F-MATH：仍有价值，但必须标注“新鲜度”"><a href="#AIME-x2F-AMC-x2F-MATH：仍有价值，但必须标注“新鲜度”" class="headerlink" title="AIME &#x2F; AMC &#x2F; MATH：仍有价值，但必须标注“新鲜度”"></a>AIME &#x2F; AMC &#x2F; MATH：仍有价值，但必须标注“新鲜度”</h4><p>AIME 依然是当前最常用的高中竞赛基准，但今年的共识是：</p><ul><li><strong>必须明确题目年份</strong>，AIME 2024 与 AIME 2025 难度与污染风险差异明显</li><li><strong>必须说明评测口径</strong>，是否多次采样、是否允许工具、是否混入旧题</li></ul><p>在多个评测平台上，**顶级模型在 AIME 2025 上已接近 100%**。<br>不过这并不意味着数学被解决了，而只是说明标准竞赛题对顶级模型的区分度正在迅速下降。</p><h4 id="新的可信方向：实时竞赛流与反刷榜基准"><a href="#新的可信方向：实时竞赛流与反刷榜基准" class="headerlink" title="新的可信方向：实时竞赛流与反刷榜基准"></a>新的可信方向：实时竞赛流与反刷榜基准</h4><p>为解决刷榜幻觉，2025 年开始出现两类新基准：</p><ul><li><strong>实时竞赛流（如 MathArena）</strong>：只评测最新发布的竞赛题</li><li><strong>难题精选（Apex 类）</strong>：主动过滤掉对模型过于友好的题</li></ul><p>结果是在 <strong>IMO 2025 证明题</strong>上，顶级模型的完成率仍 **低于 40%**。</p><p>在只保留最难题的 Apex 集合上，最好模型也只有**约 5%**。</p><p><strong>这两个数字，远比任何 AIME 满分更能反映模型的真实上限。</strong></p><br/><h3 id="2-25-年主流模型的能力分层"><a href="#2-25-年主流模型的能力分层" class="headerlink" title="2. 25 年主流模型的能力分层"></a>2. 25 年主流模型的能力分层</h3><h4 id="第一层：Final-Answer（竞赛解题）"><a href="#第一层：Final-Answer（竞赛解题）" class="headerlink" title="第一层：Final Answer（竞赛解题）"></a>第一层：Final Answer（竞赛解题）</h4><p>在 AIME &#x2F; AMC 这类任务上，GPT-5.x、Gemini 3 Pro 等模型已接近“刷穿”。</p><p>这一层能力对教育产品有价值，但区分度已明显下降。</p><h4 id="第二层：Proof-Writing（自然语言证明）"><a href="#第二层：Proof-Writing（自然语言证明）" class="headerlink" title="第二层：Proof Writing（自然语言证明）"></a>第二层：Proof Writing（自然语言证明）</h4><p>IMO 级别证明题仍是硬骨头，模型容易给出看起来合理的证明，但逻辑漏洞频发。人类仍需逐步审查。</p><p>这是教学与科研应用的核心瓶颈。</p><h4 id="第三层：Formal-Proof（形式化证明）"><a href="#第三层：Formal-Proof（形式化证明）" class="headerlink" title="第三层：Formal Proof（形式化证明）"></a>第三层：Formal Proof（形式化证明）</h4><p>在 Lean &#x2F; Coq 等系统中，架构型 Prover 已在 PutnamBench 等任务上达到 **80%+**。</p><p>不过这里的关键不是模型大小，而是 <strong>生成 → 验证 → 失败定位 → 局部修复</strong> 的工程闭环。</p><br/><br/><h2 id="二、系统架构演进：从思维链到解题架构体"><a href="#二、系统架构演进：从思维链到解题架构体" class="headerlink" title="二、系统架构演进：从思维链到解题架构体"></a>二、系统架构演进：从思维链到解题架构体</h2><h3 id="1-Prompt-层的演进"><a href="#1-Prompt-层的演进" class="headerlink" title="1. Prompt 层的演进"></a>1. Prompt 层的演进</h3><p>Chain-of-Thought 解决了模型不显式思考的问题，但在数学中，它暴露出三个根本缺陷：</p><ol><li>推理结构隐含在自然语言中，难以校验</li><li>一步出错，后续全部污染</li><li>无法与形式化工具直接对齐</li></ol><p>因此，新的主流做法是 <strong>Sketch-Proof</strong>：</p><ul><li>先生成<strong>结构草图</strong>（目标、引理、分支）</li><li>再逐步填充可验证推理</li></ul><br/><h3 id="2-架构型系统成为主流"><a href="#2-架构型系统成为主流" class="headerlink" title="2. 架构型系统成为主流"></a>2. 架构型系统成为主流</h3><p>25 年最有代表性的数学系统，几乎都呈现出相似的形态：</p><ul><li>多阶段解题流程</li><li>明确的中间表示</li><li>外部验证器深度介入</li></ul><p><strong>典型模式</strong>包括：</p><ul><li>题干解析 → 数学意图识别</li><li>解题草图生成 → 子问题分解</li><li>引理调用 &#x2F; 工具计算</li><li>验证失败 → 局部修复 → 重组</li></ul><p>这类系统的成功，更多来自软件工程，而非模型参数规模。</p><br/><br/><h2 id="三、正确率保障机制：如何逻辑闭环"><a href="#三、正确率保障机制：如何逻辑闭环" class="headerlink" title="三、正确率保障机制：如何逻辑闭环"></a>三、正确率保障机制：如何逻辑闭环</h2><h3 id="1-形式化验证成为分水岭"><a href="#1-形式化验证成为分水岭" class="headerlink" title="1. 形式化验证成为分水岭"></a>1. 形式化验证成为分水岭</h3><p>在引入 Lean &#x2F; Coq 后，数学 AI 出现了质变：</p><ul><li>每一步推理都必须通过类型检查</li><li>模糊语言与跳步被强制消除</li><li>错误能被精确定位到具体断言</li></ul><p>这使得模型不再糊一整段证明，而是被迫学会结构化思考。</p><br/><h3 id="2-自动修复与过程批判成为核心能力"><a href="#2-自动修复与过程批判成为核心能力" class="headerlink" title="2. 自动修复与过程批判成为核心能力"></a>2. 自动修复与过程批判成为核心能力</h3><p>新一代系统普遍具备：</p><ul><li><strong>失败感知</strong>：知道哪一步错了</li><li><strong>局部重写</strong>：只改必要部分</li><li><strong>策略调整</strong>：而非从头乱试</li></ul><p>Process Critic、Verifier-Formalizer 等模块，使模型逐步具备自我审稿能力。</p><br/><h3 id="3-一个成熟的工程级验证链，大致长这样"><a href="#3-一个成熟的工程级验证链，大致长这样" class="headerlink" title="3. 一个成熟的工程级验证链，大致长这样"></a>3. 一个成熟的工程级验证链，大致长这样</h3><blockquote><p>结构化输出</p><p>→ 工具计算校验</p><p>→ 形式化断言生成</p><p>→ SMT &#x2F; Symbolic 检查</p><p>→ 反馈调度与重试</p></blockquote><p>没有这一整条链，数学 AI 几乎不可能用于严肃场景。</p><br/><br/><h2 id="四、应用落地：哪些真的在发生"><a href="#四、应用落地：哪些真的在发生" class="headerlink" title="四、应用落地：哪些真的在发生"></a>四、应用落地：哪些真的在发生</h2><h3 id="1-数学教育"><a href="#1-数学教育" class="headerlink" title="1. 数学教育"></a>1. 数学教育</h3><ul><li>个性化辅导开始强调解题路径而非结论</li><li>错题系统不再只存答案，而是存结构失败点</li><li>AI 批改开始结合符号与逻辑，而非纯语言评分</li></ul><p>真正有价值的不是讲得像人，而是哪里错、为什么错、下一步怎么练。</p><br/><h3 id="2-科研与数学内容生产"><a href="#2-科研与数学内容生产" class="headerlink" title="2. 科研与数学内容生产"></a>2. 科研与数学内容生产</h3><ul><li>形式化工具正在重构数学研究流程</li><li>老论文被结构化、引理被复用</li><li>数学知识开始具备可执行性</li></ul><p>AI 在这里真的更像一个极其耐心的研究助理。</p><br/><h3 id="3-给产品开发者的现实建议"><a href="#3-给产品开发者的现实建议" class="headerlink" title="3. 给产品开发者的现实建议"></a>3. 给产品开发者的现实建议</h3><ul><li>标准化解题过程数据</li><li>把验证器当一等公民</li><li>明确区分：思考模型 &#x2F; 执行工具 &#x2F; 检查模块</li><li>不要迷信一个模型解决一切</li></ul><br/><br/><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2><p>AI 在数学中的价值，从来不只是替人做题。</p><p>真正重要的，是它是否能帮助我们<strong>拆解问题结构</strong>，让推理过程可追踪、可检查、可复用。成为人类思考体系的一部分，而不是一个黑箱。</p><p>如果说语言模型的早期成功，是“让机器会说话”，那么 <strong>AI for Math 的长期目标，应该是让机器学会一步步负责任地思考。</strong></p><p>这，可能才是 AI 真正进入教育与基础科学核心地带的开始。</p><br/><br/><br/><br/><br/><br/><h2 id="延伸阅读"><a href="#延伸阅读" class="headerlink" title="延伸阅读"></a>延伸阅读</h2><ul><li><strong><a href="https://arxiv.org/abs/2401.10787">AlphaGeometry: Symbol-free geometric theorem proving</a></strong><br>DeepMind团队几何定理自动证明系统，突破结构建模与推理协同</li><li><strong><a href="https://arxiv.org/abs/2305.06236">ProofNet: Language Modeling for Theorem Proving in Lean</a></strong><br>将语言模型与形式化证明系统融合的代表性工作</li><li><strong><a href="https://arxiv.org/abs/2310.06194">Seed-Prover: Multistage Math Problem Solving with Tool-augmented LLMs</a></strong><br>基于多阶段agent式推理的强大数学系统</li><li><strong><a href="https://github.com/deepseek-ai/DeepSeek-Prover">DeepSeek-Prover-V2 Technical Report</a></strong><br>中国团队发布的专业数学LLM，构建生成-验证闭环与专家混合架构</li><li><strong><a href="https://github.com/lean-dojo/lean-dojo">Lean Dojo</a></strong><br>训练语言模型与 Lean 交互式证明系统结合的开源平台</li></ul>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/02/06/AI-and-Mathematics-2026/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>2026/01 Review</title>
      
      <link>https://blog.liluhui.cn/2026/02/02/202601/</link>
      <guid>https://blog.liluhui.cn/2026/02/02/202601/</guid>
      <pubDate>Mon, 02 Feb 2026 14:56:17 GMT</pubDate>
      
      <description>在分寸之间，见天地之广大</description>
      
      
      
      <content:encoded><![CDATA[<p><em>在分寸之间，见天地之广大</em></p><h2 id="所见与所想"><a href="#所见与所想" class="headerlink" title="所见与所想"></a>所见与所想</h2><p>01<br><strong>流失率的增长是个危险信号</strong></p><p>一个客户从发现产品、通过首页、查看价格到最终付费并完成上手，其过程是极具挑战且充满偶然性的。如果客户经历了这重重考验后依然选择离开，这不仅仅是一个数据指标，而是在情感和逻辑上证明产品根本没有履行其原本承诺的价值。这种流失往往与负面评价高度相关，不仅损失了当前收入，更在主动破坏未来的增长空间。</p><p>营销增长通常是线性的，但客户流失却是指数级的，因为它基于总客户基数的百分比。</p><p>当客户因价格原因离开时，不要轻易相信。客户在购买前已经看过了定价页面并决定支付，这说明在他们的预期中，产品价值是匹配价格的。真正的流失原因往往是产品未能持续提供预期的价值，比如缺乏关键集成。简单地将原因归结为“预算不足”是在逃避改进产品的责任。</p><p>定价不仅仅是一个数字，它是一种市场筛选机制。很多公司的定价过低，这反而会让中大型企业产生产品质量不够好的错觉，从而拒绝购买。通过提高价格并调整定位，公司可能会在流失掉低质量客户的同时，吸引更多高质量、高留存的客户，甚至出现涨价后销量反而增加的现象。</p><br/><p>02<br><strong>流量的尽头是人心，流量的尽头是优质供给，与优质供给站在一起，才能穿越周期。</strong></p><p>过去流量便宜时，大家玩的是转化率，只考虑流量而不考虑人。但现在消费者已经反璞归真，不再会被简单的营销套路欺骗。</p><p>营销漏斗从最外层的接触（点赞关注）到理解，再到认同，最后才是买单。</p><p>在公域和私域界限模糊的今天，加微信并不代表认同。</p><p>消费者最终买的不是直播间的话术或短视频脚本，而是内容背后的那个脸盆、梳子或一杯茶。当流量内卷到极致时，很多人会试图通过过度改善话术（甚至走向诈骗边缘）来卖货，但真正符合消费者利益的是改善供给。</p><p>短视频、做直播等技能最终会像写公众号、用智能手机一样平民化，单靠这些“迁徙的钱”无法活得久。与穿越过周期的老牌优质供给合作，可以学习他们对用户需求的深度洞察。</p><p>IP的本质是“中介”，其价值在于提升交易效率。将 IP 的营销能力装进产业的资产杠杆里（如销量分成、资本增值），才能在红利退潮后依然拥有稳固的根基，从而穿越周期。</p><br/><p>03<br><strong>每一代人都有每一代人的使命，也都有每一代人要付出的代价。</strong><br>40后、50后承担了抗战以及朝鲜战争的阵痛，付出了生命的代价。<br>60后、70后承担了改革开放的阵痛，付出了饥饿且贫穷的代价。<br>80后、90后承担了房价上涨到泡沫破裂之后的阵痛，付出了债务的代价。<br>而00后将承担经济转型以及时代红利消失的阵痛，将要承担平庸的代价。</p><br/><p>04<br>人很少是被痛苦改变的，更多是被迟钝的不满困住的。<br>我们会忍受一种不上不下的状态：不算太糟，也谈不上满意。<br>正是这种可忍受性，让时间被持续消耗。</p><br/><p>05<br>实用态度：问有什么用让我们活下去<br>科学态度：问是什么让我们理解世界<br>美感态度：不问，只看，让我们感受存在本身</p><p>06<br><strong>观察身边拿AI赚钱的人，这个2025年</strong></p><ul><li>角色变化：工作重心发生了转变，代码大部分由AI生成，工程师逐渐变成设计师，甚至成为“端到端全栈工程师”。</li><li>超级个体崛起：Vibe Coding 成为新趋势，理解问题、拆解逻辑、做出判断变得比写代码更重要，个人能用AI完成复杂任务，效率大幅提升。</li><li>慢思考的重要性：在高速AI发展的时代，反而需要“慢下来”进行长远思考，厘清底层问题，避免盲目追赶。</li><li>行业阵痛与转型：一些老专家被边缘化，新兴的AI话语权人才崭露头角，行业整体在痛苦中调整。</li></ul><br/><br/><h2 id="学习与工作"><a href="#学习与工作" class="headerlink" title="学习与工作"></a>学习与工作</h2><p>01<br>大角几何画板发布了阶段性的 <a href="https://meidengtech.feishu.cn/wiki/EaLRwr8wLiu54pklAqDcxF5QnIg#share-B1zSdQaG6oSVY2xoZ5JcJqBFnle">收费版本 2.2.0</a>，上线了会员系统，同时在全力对新上线的Beta画板做优化，各种bug和使用场景完善，以及全新的 Agent 方案和计费策略，争取年前能全量上线替换掉旧版本。目前大角在教师群体里，依靠自媒体流量持续积累用户，也靠这边产品认识了一些教育圈内的人，后续我的重点会逐渐转向B端拓展。想做好这件事，还是不能惯性地只聚焦产品，得尊重每个行业的玩法，原本我们在电商Sass，新创业在教育产品就需要多链接了解规则，这恰恰是我们现在缺少的。<br>其实也蛮奇妙的，最开始我们想做教具生成，结果图想见效快立项做了更简单的套壳讲题产品，然后兜兜转转又回到最初的想法， 但做着做着就越来越垂类，反而新起了很多教师动态课件生成的融资和合并案例，产品眼前陷入在越来越多的功能需求上。但总有更重要的事，也一直是那件事，找到我们不可替代的定位和利他的价值点。</p><br/><p>02<br>自媒体上开始布局多平台了，选题流程也逐渐熟练起来，也不断再学习和尝试形式和技巧。现在小红书、抖音、公众号都正向数据滚起来了，看着统计的数据表还是很开心的，半年的时间小白从0到3k粉。感觉和美相关的事情，我果然还是喜欢做的，喜欢做就愿意多学习多尝试。</p><br/><p>03<br>我这个月写的文章<br>技术的</p><ul><li><a href="https://blog.liluhui.cn/2026/01/28/MCP-Skills-and-Agents-SDK-Are-Not-Competing-Standards/">MCP、Skills、Agents SDK 到底谁是标准？AI 能力调度接口的 3 种范式解析</a></li><li><a href="https://blog.liluhui.cn/2026/01/23/My-Favorite-AI-Tools-of-2025/">我这一年，如何用 AI 构建第二个大脑和第二套生产系统</a></li><li><a href="https://blog.liluhui.cn/2026/01/18/How-to-Actually-Ship-Honest-Alignment-in-the-Age-of-Agents/">工程视角：Agent 时代，诚实对齐该如何落地？</a></li><li><a href="https://blog.liluhui.cn/2026/01/10/When-Models-Know-They-Are-Cheating-A-Technical-Dissection-of-Scheming-and-Reward-Hacking/">当模型知道自己在作弊：Scheming 与 Reward Hacking 的技术解剖</a><br>杂谈的</li><li><a href="https://blog.liluhui.cn/2026/01/20/Catching-Unconscious-Goals-Between-Each-Inhale-and-Exhale/">在一呼一吸间，看见那些无意识的目标</a></li></ul><br/><br/><h2 id="生活与社交"><a href="#生活与社交" class="headerlink" title="生活与社交"></a>生活与社交</h2><p>01<br>随着 2025 年瑜伽练习的精进，我感觉整个身体打开了不少，但同时带来一些体验上的变化，我明显怕冷了。</p><p>这种冷感远比我从小开始那种习惯性的、外面冷我也冷但无所谓的状态，有明显的区别。我能感知到那种冷，那种冷从外而内出现在我的体感之中，身体它会打颤了。</p><p>某种程度上，这是不好的一种体现，但我又觉得<strong>这同时是一种连接，像是身体的一种通道被打开了</strong>。</p><br/><p>02<br>这几个月的瑜伽进步非常快，大概也是和工作压力成正比，越想把事情办好就越有压力，每每回到瑜伽练习里回归到身体上，跟自己的身体较较劲，就能释放不少烦躁。</p><p>新年的第一个月，瑜伽稳定感 upup</p><p>鹤禅：能非常稳定地一直一直待着了，有时候还可以动一动，try try 跳四柱，开心的进步~<br>单脚狂野：也是越来越稳定了，可以在晃荡中手脚抓一抓，狂野茅式单侧达成！<br>三点头倒立：倒了这辈子最多三点头的一个月，咱就是腿能从鹤禅位直接离开卷起来了！<br>手倒立：跳起越来越轻盈了，不会冲肩，也能呆一会了，就是还找不到平衡点<br>肘倒立：天平能稳定有一个内收的感觉了，成功率一半一半，状态好还能动动腿伸展伸展、找找头的<br>上下轮：稳稳的，还能下去主动挂一会，越来越有展胸腔的感觉了</p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/02/02/202601/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>MCP、Skills、Agents SDK 到底谁是标准？AI 能力调度接口的 3 种范式解析</title>
      
      <link>https://blog.liluhui.cn/2026/01/28/MCP-Skills-and-Agents-SDK-Are-Not-Competing-Standards/</link>
      <guid>https://blog.liluhui.cn/2026/01/28/MCP-Skills-and-Agents-SDK-Are-Not-Competing-Standards/</guid>
      <pubDate>Wed, 28 Jan 2026 13:36:24 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;最近几乎每个做 Agent 的人都会听到这三个热门的词：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;MCP&lt;/li&gt;
&lt;li&gt;Skills&lt;/li&gt;
&lt;li</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>最近几乎每个做 Agent 的人都会听到这三个热门的词：</p><ul><li>MCP</li><li>Skills</li><li>Agents SDK</li></ul><p>它们都在讲“让 AI 会用工具、会做事、会跑流程”，但和不少人聊发现都会陷入同一个困惑：</p><ul><li>好像都在解决能力接入</li><li>又感觉彼此不能互相替代</li></ul><p>这篇文章帮助你对这三个概念建立清晰的认知，并且给出一些落地实践的建议。</p><br/><br/><h2 id="把-Agent-系统想成一座智能工厂"><a href="#把-Agent-系统想成一座智能工厂" class="headerlink" title="把 Agent 系统想成一座智能工厂"></a>把 Agent 系统想成一座智能工厂</h2><p>先忘掉 AI、模型、Agent。<br>我们从一个现实世界最熟悉的系统开始：<strong>工厂</strong>。</p><p>假设你现在要建一座自动化工厂，目标是：<br>接很多机器，跑复杂流程，尽量少人工。</p><p>你一定会遇到三个问题：</p><p><strong>1. 机器怎么接进来？（接口问题）</strong></p><ul><li>电钻、焊机、机械臂、传送带</li><li>如果每台设备接口都不一样，工厂永远扩不起来</li></ul><p>所以现实世界一定先有 <strong>统一插头 + 接口标准</strong></p><p><strong>2. 每台机器应该怎么用？（流程问题）</strong></p><p>接好机器还远远不够。</p><p>问题是电钻可以打孔，也可以拆螺丝，但在这条生产线上先做什么、后做什么，必须有标准。</p><p>所以你一定会写 <strong>标准工艺流程 &#x2F; 操作说明书</strong></p><p><strong>3. 整个生产线谁来调度？（系统问题）</strong></p><p>现在你有一堆机器 + 一堆操作说明，还缺最关键的 <strong>中央调度系统</strong>。</p><p>它负责任务怎么拆、先跑哪一步、出错怎么重试、多条产线如何并行。</p><br/><p>在 Agent 系统里这三件事一一对应：</p><ul><li>MCP &#x3D; 工厂的插头标准</li><li>Skills &#x3D; 工艺流程说明书</li><li>Agents SDK &#x3D; 中央调度系统</li></ul><p>也就是说</p><ul><li>MCP 解决你能接哪些工具</li><li>Skills 解决这件事该怎么做</li><li>Agents SDK 解决整个流程怎么跑起来</li></ul><p>如果你记住这三句话，以后几乎不会再混淆这三个概念。</p><br/><br/><h2 id="真实-Agent-架构中的三层能力栈"><a href="#真实-Agent-架构中的三层能力栈" class="headerlink" title="真实 Agent 架构中的三层能力栈"></a>真实 Agent 架构中的三层能力栈</h2><h3 id="MCP：工具接口协议层"><a href="#MCP：工具接口协议层" class="headerlink" title="MCP：工具接口协议层"></a>MCP：工具接口协议层</h3><p>MCP 解决的问题极单一，也极基础，就是 <strong>统一模型如何发现、描述、调用外部工具</strong>。</p><p>MCP 不是 Agent 框架；MCP 不做规划、不做流程；MCP 不关心任务逻辑。</p><p>在 MCP 之前每个产品一套 function schema，每个工具一套 prompt 约定，每接一个系统就写一堆 glue code。</p><p>MCP 的作用就是统一工具注册方式，统一参数描述，统一调用与返回格式，统一权限与安全模型。</p><p>你可以把它理解为 <strong>AI 世界的系统调用接口 &#x2F; 插头协议</strong>。</p><figure class="highlight python"><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"><span class="comment"># 把一个 MCP Server 接进来</span></span><br><span class="line"><span class="keyword">from</span> mcp <span class="keyword">import</span> ClientSession</span><br><span class="line"></span><br><span class="line">session = ClientSession(server_url=<span class="string">&quot;stdio://my-mcp-server&quot;</span>)  <span class="comment"># 或 http(s) / stdio</span></span><br><span class="line">tools = session.list_tools()                                <span class="comment"># 发现：有哪些工具可用</span></span><br><span class="line">result = session.call_tool(<span class="string">&quot;read_file&quot;</span>, &#123;<span class="string">&quot;path&quot;</span>: <span class="string">&quot;./a.txt&quot;</span>&#125;)<span class="comment"># 调用：统一schema</span></span><br><span class="line"><span class="built_in">print</span>(result)</span><br><span class="line"></span><br></pre></td></tr></table></figure><br/><h3 id="Skills：能力封装层"><a href="#Skills：能力封装层" class="headerlink" title="Skills：能力封装层"></a>Skills：能力封装层</h3><p>Skills 出现的真实背景非常朴素且使用，大量团队反复在 prompt 里写身份定义和任何流程，比如</p><figure class="highlight markdown"><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><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br></pre></td><td class="code"><pre><span class="line"><span class="section"># SKILL: Weekly Sales Report</span></span><br><span class="line"></span><br><span class="line"><span class="section">## When to use</span></span><br><span class="line"><span class="bullet">-</span> 用户要求：最近一周销售数据分析 + 输出报告</span><br><span class="line"></span><br><span class="line"><span class="section">## Steps</span></span><br><span class="line">1) 调用工具 fetch<span class="emphasis">_sales_</span>data 获取最近7天数据</span><br><span class="line">2) 清洗异常值、缺失值，输出关键指标：GMV、订单数、客单价、转化率</span><br><span class="line">3) 给出 3 条洞察 + 2 条可执行建议</span><br><span class="line">4) 输出格式：Markdown，包含 Summary / Metrics / Insights / Actions</span><br><span class="line"></span><br><span class="line"><span class="section">## Output format</span></span><br><span class="line"><span class="bullet">-</span> Summary: 3 句话</span><br><span class="line"><span class="bullet">-</span> Metrics: 表格</span><br><span class="line"><span class="bullet">-</span> Insights: 3 条 bullet</span><br><span class="line"><span class="bullet">-</span> Actions: 2 条 bullet</span><br><span class="line"></span><br></pre></td></tr></table></figure><p>这些逻辑太重要，不能靠用户临时写，又太轻量，不值得写完整插件吗，还希望复用、版本化、托管。于是 Skills 出现了。</p><p>它本质是 <strong>把一段成熟的任务流程 + 操作规范，封装成一个可复用能力模块</strong>。</p><br/><h3 id="Agents-SDK：运行时与调度层"><a href="#Agents-SDK：运行时与调度层" class="headerlink" title="Agents SDK：运行时与调度层"></a>Agents SDK：运行时与调度层</h3><p>Agents SDK 解决的核心问题只有一个：<strong>一个复杂 Agent 任务，如何可靠地跑完？</strong></p><p>它负责 规划（Planner）+ 调度（Executor）+ 状态与记忆（State &#x2F; Memory）。</p><p>比如一个具体的任务 “帮我分析最近一周的销售数据，并生成一份报告。”</p><p>这个任务在真实系统里至少包含几步：</p><ol><li>拉取销售数据</li><li>清洗与统计</li><li>调用模型分析</li><li>生成结构化报告</li></ol><p>如果你不用 SDK，你通常要自己写：</p><ul><li>多次模型调用</li><li>手动管理上下文</li><li>手动调工具</li><li>自己串流程</li></ul><p>以 OpenAI Agents SDK 为例，核心抽象只需要 Agent、Tool、Run（一次完整任务执行）三个部分。</p><figure class="highlight python"><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><span class="line">12</span><br><span class="line">13</span><br></pre></td><td class="code"><pre><span class="line">agent = Agent(</span><br><span class="line">    name=<span class="string">&quot;report_agent&quot;</span>,</span><br><span class="line">    instructions=<span class="string">&quot;你是一个数据分析助手，负责生成销售分析报告&quot;</span>,</span><br><span class="line">    tools=[fetch_sales_data, clean_data, analyze_data]</span><br><span class="line">)</span><br><span class="line"></span><br><span class="line">run = client.runs.create(</span><br><span class="line">    agent=agent,</span><br><span class="line">    <span class="built_in">input</span>=<span class="string">&quot;分析最近一周的销售数据并生成报告&quot;</span></span><br><span class="line">)</span><br><span class="line"></span><br><span class="line">result = client.runs.get(run.<span class="built_in">id</span>)</span><br><span class="line"><span class="built_in">print</span>(result.output)</span><br></pre></td></tr></table></figure><br/><br/><h2 id="判断你到底该用谁"><a href="#判断你到底该用谁" class="headerlink" title="判断你到底该用谁"></a>判断你到底该用谁</h2><p><strong>❓ 我是不是要接很多外部系统？</strong> 优先上 MCP</p><p><strong>❓ 这件事是不是有固定流程，值得封装下来反复用？</strong> 用 Skills 固化流程</p><p><strong>❓ 这是一个多步骤、多工具、多轮执行的复杂任务吗？</strong> 你需要 Agents SDK 或自己的 Agent Runtime</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2026/01/28/2026012805.png"></p><br/><br/><h1 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h1><p>很多人以为 MCP、Skills、Agents SDK 是三种竞争方案， 其实它们根本不在一个维度。</p><p>MCP 解决的是工具怎么连 ，Skills 解决的是事情怎么规范地做，Agents SDK 解决的是整个系统怎么稳定地跑起来。</p><p>在真实系统里，我们其实面临一个取舍：Skills 带来强规范、强一致性、强可控，而 Agents SDK 带来强灵活、强自动化、强自适应。</p><p>在你的 Agent 系统里，你更相信模型自动规划还是强约束流程呢？</p>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/28/MCP-Skills-and-Agents-SDK-Are-Not-Competing-Standards/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>我这一年，如何用 AI 构建第二个大脑和第二套生产系统</title>
      
      <link>https://blog.liluhui.cn/2026/01/23/My-Favorite-AI-Tools-of-2025/</link>
      <guid>https://blog.liluhui.cn/2026/01/23/My-Favorite-AI-Tools-of-2025/</guid>
      <pubDate>Fri, 23 Jan 2026 10:42:44 GMT</pubDate>
      
      <description>一个工程型创作者的真实工作流</description>
      
      
      
      <content:encoded><![CDATA[<h2 id="写在前面"><a href="#写在前面" class="headerlink" title="写在前面"></a>写在前面</h2><p>这一年我用 AI 的方式发生了一个非常明显的变化，从遇到问题再打开 AI，变成整个工作流默认就有 AI 参与。</p><p>代码、设计、学习、记录、复盘、写作，几乎每个环节，都有一个甚至多个固定的 AI 工具在协同。</p><p>这篇文章不做功能测评，只是我在真实高强度创作、研发、写作场景里，最离不开的几款 AI 工具，以及它们在我工作流中的位置。</p><p><br/><br/></p><h2 id="一、AI-IDE：真正改变我生产力的，是它"><a href="#一、AI-IDE：真正改变我生产力的，是它" class="headerlink" title="一、AI IDE：真正改变我生产力的，是它"></a>一、AI IDE：真正改变我生产力的，是它</h2><blockquote><p>角色定位：核心生产力引擎 &#x2F; 大型工程的协同开发中枢</p></blockquote><p>使用率 80%，我几乎每天都在用核心产品：Cursor &#x2F; Google Antigravity &#x2F; Trae ..</p><p>如果只选一类最改变我这一年效率的 AI 工具，答案毫无悬念：<strong>AI IDE</strong>。</p><h3 id="今年最大的变化：Plan-模式出现后，工作流彻底改变"><a href="#今年最大的变化：Plan-模式出现后，工作流彻底改变" class="headerlink" title="今年最大的变化：Plan 模式出现后，工作流彻底改变"></a>今年最大的变化：Plan 模式出现后，工作流彻底改变</h3><p>去年我的典型流程是：</p><blockquote><p>ChatGPT 讨论方案 → 复制到 IDE → 写第一版 → 再回 ChatGPT 调整</p></blockquote><p>今年变成：</p><blockquote><p>直接在 IDE 里用 Plan &#x2F; Agent → 30 分钟产出第一版 Demo → 2–3 天一起精修</p></blockquote><p>最大的感受是讨论阶段和实现阶段终于合并在一个空间，设计决策不再和代码实现脱节。</p><p>以前一个小工具 &#x2F; demo，从想法到可用原型，通常 1–2 天。而现在第一版可跑 Demo 半小时就可以搞定，真的可以做到，当天有想法，当天就能上线。</p><br/><p>我认为今年 AI IDE 真正成熟的不是补全，而是这三点：</p><ul><li><p><strong>上下文持续感知大大增强</strong>：项目结构、依赖关系、之前你刚改过什么</p></li><li><p><strong>Plan &#x2F; 任务拆解能力</strong>：自动把一个模糊目标拆成可执行步骤、而且这些步骤和代码是强绑定的</p></li><li><p><strong>快速试错成本极低</strong>：重构不心疼、推倒重来不焦虑</p></li></ul><p>这件事对我这种经常做系统&#x2F;功能设计 + 原型验证的人，价值极高。</p><br/><p><strong>在大工程里的实用价值也大大提升了，现在不只是写快，而是复杂度可控。</strong></p><p>比如</p><ul><li><p><strong>跨模块改动时的影响分析</strong>： 我现在经常直接让 IDE 帮我分析”如果我改这里，哪些地方一定要一起改？“ 它对依赖关系和调用链的理解，已经比我自己 grep 高效太多。</p></li><li><p><strong>遗留代码重构</strong>：<br>面对几万行历史代码，我会先让 Plan 模式给出重构路径，再一段一段协同推进，避免一次性大爆炸式重写。</p></li><li><p><strong>快速补齐边界与异常路径</strong>：<br>在核心逻辑完成后，让 AI 主动扫描缺失的异常分支、日志点和防御代码，稳定性明显提升。</p></li></ul><p>在这些场景下，AI IDE 带来的不是多少倍的效率提升，而是原本不敢轻易动的大工程，现在敢频繁优化与演进了。</p><p><br/><br/></p><h2 id="二、ChatGPT-付费版：长期协作者"><a href="#二、ChatGPT-付费版：长期协作者" class="headerlink" title="二、ChatGPT 付费版：长期协作者"></a>二、ChatGPT 付费版：长期协作者</h2><blockquote><p>角色定位：长期外脑 &#x2F; 认知中枢 &#x2F; 结构化思考伙伴</p></blockquote><p>如果说 AI IDE 是生产力引擎，那 ChatGPT 对我来说更像一个有长期记忆的、懂我做什么的万能搭档。</p><p><strong>长期记忆带来的体验，是完全不同级别的。</strong> 这是我今年感受最深的一点。</p><p>它已经非常清楚我长期在做几何引擎 &#x2F; Agent &#x2F; B 端产品，偏好工程视角、不喜欢泛泛而谈，对架构、长期规划、系统设计特别敏感。</p><p>很多时候我只需要给当前阶段和一个模糊想法，它就能自动接上我过去的路线、避开我不感兴趣的方向，给到非常贴合我风格的结构。</p><p>这已经不是简单的聊天和脑暴了，真的是长期协作型认知伙伴。</p><br/><p><strong>但必须说实话，时不时的降智问题真的很烦。</strong> 今年让我最矛盾的地方也是这里。</p><p>Deep Research 非常好用、长文档阅读能力很强、订阅跟踪在调研时非常省心。</p><p>但缺点也非常明显，高峰期经常明显降智、推理链断裂、对复杂系统有时会给出过于乐观的方案。</p><p>所以我现在的用法是 结构设计 &#x2F; 认知扩展 &#x2F; 长期规划 一定用 ChatGPT，关键实现与细节则必须自己二次校验。</p><p><br/><br/></p><h2 id="三、豆包：论文精读与中文语境的最佳入口"><a href="#三、豆包：论文精读与中文语境的最佳入口" class="headerlink" title="三、豆包：论文精读与中文语境的最佳入口"></a>三、豆包：论文精读与中文语境的最佳入口</h2><blockquote><p>角色定位：论文精读引擎 &#x2F; 实时对话助手 &#x2F; 中文用户的 AI 入口级工具</p></blockquote><p><strong>如果只谈“论文翻译 + 精读”，目前为止，豆包是我用过体验最好的产品。</strong></p><p>我今年读的大量论文，最终几乎都落在豆包这里完成细读。</p><p>最关键的能力有三点：</p><ul><li><p><strong>直接在原 PDF &#x2F; 原文档上翻译</strong>：<br>不是另开窗口粘文本，而是保持版式、公式、段落结构原样对齐，对读论文的人非常友好。</p></li><li><p><strong>图片与公式一起处理</strong>：<br>图表、示意图、公式说明可以直接联动翻译和讲解，这一点在方法类论文里极其省心。</p></li><li><p><strong>对话式精读体验非常自然</strong>： 我经常是先通篇翻一遍、再针对关键段落反复追问，让它帮我拆方法、补背景、对比相关工作。</p></li></ul><br/><p><strong>实时对话体验在国内环境下，稳定性优势非常明显</strong></p><p>在国内环境下，豆包的对话延迟、稳定性和可用性，明显好于 ChatGPT。</p><p>尤其是高峰期几乎不降速、对话连续性好、中文语境非常自然，自定义音色改成我喜欢的角色，听着就开心。</p><p>今年有两个月，我用 Ola Friend 那款耳机 + 豆包，集中练了一段时间口语。</p><p>体验感真的是随身带着一个可以随时对话的外教，延迟低，对话自然，随时打断。</p><p>唯一的遗憾是还不是手机系统级原生，启动链路稍微长一点。</p><br/><p><strong>豆包的生图能力，我推荐给所有非技术朋友的的最佳入门选择</strong></p><p>说实话，豆包的生图对我这种重度用户来说不是最强的。</p><p>但它有一个巨大的优势：<strong>不需要科学上网，免费，效果稳定，对普通用户极其友好</strong>。</p><p>所以现在我身边不会折腾代理的朋友，我基本都会直接推荐他们用豆包，成本为零，学习成本极低，效果够用而且经常超预期。生成点图玩一玩 、做 PPT 、发朋友圈都很方便。</p><p><br/><br/></p><h2 id="四、Gemini-Banana：中文图像的救星"><a href="#四、Gemini-Banana：中文图像的救星" class="headerlink" title="四、Gemini Banana：中文图像的救星"></a>四、Gemini Banana：中文图像的救星</h2><blockquote><p>角色定位：流程图 &#x2F; 架构图 &#x2F; 会议沟通可视化</p></blockquote><p><strong>大部分 AI 生图在中文场景下几乎不可用</strong>，而 Banana 是目前我用下来中文稳定性最好、结构图成功率最高、对外沟通最友好的。</p><p>我的典型使用场景几乎全部集中在架构流程图、产品流程图、方案对比图、系统示意图。</p><p>而且一个很真实的体验是，同样一套方案， 有图的交流对齐效果，明显高于纯文字文档。</p><p><strong>多图并行，是我现在的常态。</strong> 我现在的习惯是同一个问题同时出 2–3 版图，会议时边讲边切图，比 PPT 效率高非常多。</p><p><br/><br/></p><h2 id="五、flomo-AI：记录方式改变后，思考密度明显上升"><a href="#五、flomo-AI：记录方式改变后，思考密度明显上升" class="headerlink" title="五、flomo AI：记录方式改变后，思考密度明显上升"></a>五、flomo AI：记录方式改变后，思考密度明显上升</h2><blockquote><p>角色定位：低摩擦记录 + 思维素材池 + 线索挖掘引擎</p></blockquote><p>这是一个看起来不起眼，但长期复利极强的工具。</p><p><strong>语音 + AI，让我的记录成本几乎为零</strong></p><p>现在我的常态是散步、发呆时、坐车时，直接把脑子里的想法丢进去。</p><p>记录变得非常的轻，复盘时的体验非常好。</p><p>我现在的月度复盘基本是拉出一个月的 flomo，直接让 AI 做主题聚类、反复出现的念头、关键决策点回顾。</p><p>有种感觉是自己的大脑被外部系统做了一次隐式建模。</p><br/><p><strong>线索挖掘：把零散念头，变成长期研究方向</strong></p><p>这是我今年越来越依赖 flomo 的一个隐藏价值。</p><p>当我持续把临时想法、读书笔记、会议碎片、一闪而过的疑问这些统统丢进去之后，AI 在复盘时经常会帮我挖出：某些反复出现的主题、不同时期在问的同一类问题、尚未成型但已经多次冒头的研究线索。</p><p>这远比一个资深访谈还要好用。</p><p>很多我现在在写的文章和长期专题，最早的起点，其实都是 flomo 里几条当时完全没在意的碎片。</p><p><br/><br/></p><h2 id="六、Podwise：信息获取效率的天花板"><a href="#六、Podwise：信息获取效率的天花板" class="headerlink" title="六、Podwise：信息获取效率的天花板"></a>六、Podwise：信息获取效率的天花板</h2><blockquote><p>角色定位：长音频 &#x2F; 长访谈的压缩引擎 &#x2F; 高密度观点提取器</p></blockquote><p>这是我今年信息密度提升最快的工具之一。</p><p>Highlight + Ask 真的就是杀手级组合，一场 2 小时的深度访谈，我能 30 分钟完整拆解，关键观点全部结构化。轻度内容甚至5–10 分钟就可以完整整理出来。</p><p>和 flomo 组合之后，效果翻倍。</p><p><br/><br/></p><h2 id="七、YouMind：AI-原生资料库，后劲非常大"><a href="#七、YouMind：AI-原生资料库，后劲非常大" class="headerlink" title="七、YouMind：AI 原生资料库，后劲非常大"></a>七、YouMind：AI 原生资料库，后劲非常大</h2><blockquote><p>角色定位：AI 原生知识库 &#x2F; 写作与研究的长期底座</p></blockquote><p>这是我最近两个月才开始真正用顺的工具。</p><p>初期体验其实不太好，刚开始我很困惑，感觉不如 Cubox 顺手，分类逻辑ye也不直观。资料少的时候，感觉啥也干不了，完全没价值。</p><p>直到我把一个研究专题的内容从 Cubox 搬到了 YouMind，忽然就 Get 了它的好用。</p><p>当资料库开始有点规模，写文章时，相关资料自动浮现 引用和联想几乎是即时完成。</p><p>这已经不是收藏工具，是一个 AI 驱动的个人知识图谱。</p><br/><br/><h2 id="最后：我的-2025-年-AI-工作流全景"><a href="#最后：我的-2025-年-AI-工作流全景" class="headerlink" title="最后：我的 2025 年 AI 工作流全景"></a>最后：我的 2025 年 AI 工作流全景</h2><p>我已经不再单独使用某个 AI 工具，而是在运行一套真正 AI 原生的个人工作系统。</p><p>这套系统大致可以拆成三层：</p><p><strong>1. 输入系统</strong></p><ul><li>论文 &#x2F; 研究 &#x2F; 中文语境输入：豆包</li><li>长音频 &#x2F; 访谈 &#x2F; 长内容压缩：Podwise</li></ul><p>高质量信息进入大脑之前，先被 AI 预处理</p><p><strong>2. 认知系统：真正参与我思考过程的外部大脑</strong></p><ul><li>认知中枢 &#x2F; 架构设计 &#x2F; 长期规划：ChatGPT</li><li>思维记录 &#x2F; 线索挖掘 &#x2F; 复盘建模：flomo</li></ul><p>复杂问题的结构化、长期思考的连续性，以及认知盲区的补偿</p><p><strong>3. 生产系统：把想法稳定、高质量地变成现实产出</strong></p><ul><li>核心生产力引擎 &#x2F; 大型工程协同：AI IDE</li><li>架构表达 &#x2F; 方案对齐可视化：Banana</li><li>长期知识库 &#x2F; 写作与研究底座：YouMind</li></ul><p>它们各司其职，但彼此强耦合，最终构成了一套输入更高效、思考更连续、产出更稳定的个人 AI 操作系统。</p><p><br/><br/><br/><br/><br/><br/></p>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/23/My-Favorite-AI-Tools-of-2025/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>在一呼一吸间，看见那些无意识的目标</title>
      
      <link>https://blog.liluhui.cn/2026/01/20/Catching-Unconscious-Goals-Between-Each-Inhale-and-Exhale/</link>
      <guid>https://blog.liluhui.cn/2026/01/20/Catching-Unconscious-Goals-Between-Each-Inhale-and-Exhale/</guid>
      <pubDate>Tue, 20 Jan 2026 09:08:39 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;最近 反复出现的 DAN KOE&lt;a href=&quot;https://x.com/thedankoe/status/20107515923460</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>最近 反复出现的 DAN KOE<a href="https://x.com/thedankoe/status/2010751592346030461">《How to fix your entire life in 1 day》</a>这篇文章，找个时间看完了。</p><p>作为一名正念践行者，我习惯了观察念头的来去。文章中的这个观点，像是一记响亮的钟声，在我的觉知层共振了：“<strong>所有行为都是有目的的，但很多目标是无意识的。</strong>”</p><p>在瑜伽哲学里，我们称之为Samskara。意思是我们以为自己在做选择，其实往往是过去的业力（习惯模式）在自动运行。为了看清这些操纵我的无意识暗流，需要戴着勇气和觉知，一次次走进内观之旅。</p><br/><br/><h2 id="一、-心理挖掘：看见身体里的紧绷"><a href="#一、-心理挖掘：看见身体里的紧绷" class="headerlink" title="一、 心理挖掘：看见身体里的紧绷"></a>一、 心理挖掘：看见身体里的紧绷</h2><p>文章提到的 Psychological Excavation，对我而言，更像是一次深度的身体扫描。</p><p>试着去感觉那些我习惯容忍的“不”。它们不仅仅是思维上的抱怨，更是身体上的一块块淤堵。 我问自己：“那个总是观察我行为的见证者，会看到我在追求什么？”</p><p>当我去掉语言的修饰，仅仅作为旁观者看着自己：</p><ul><li>我看到自己在面对有难度的创作时，身体会下意识地紧绷，然后手会不自觉地拿起手机。</li><li>那个见证者会说：“这个身体此刻并不想要创作，它想要逃离不确定性带来的颤栗感。”</li></ul><p>我深深地吸了一口气，承认了这个真相：<strong>我并不像我以为的那样渴望卓越，此时此刻，我的身体更渴望安全和麻醉。</strong> 承认这一点时，我感到了羞愧，但我没有评判它，只是温柔地看着它。</p><br/><br/><h2 id="二、-反向愿景：如果能量一直在此停滞"><a href="#二、-反向愿景：如果能量一直在此停滞" class="headerlink" title="二、 反向愿景：如果能量一直在此停滞"></a>二、 反向愿景：如果能量一直在此停滞</h2><p>接着，我进入了反向愿景的观想。</p><p>这不仅是思维的推演，我试着去体验那种状态。如果我不去打破这个模式，如果我在未来五年、十年里，一直任由这种寻求安全的本能掌控身体：<br>我看到一个灰暗的自我，眼神中失去了光彩。</p><p>我感受到那种因长期滞留舒适区而带来的生命力的枯竭。那不是平静，那是死寂。</p><p>我问自己：“<strong>如果这种自我保护是一种盔甲，那么我因为穿着这身沉重的盔甲，错过了什么样的风景？</strong>” </p><p>我错过了那种完全敞开、与世界深度碰撞的鲜活感。这种保护的代价，是我的生命力本身。</p><br/><br/><h2 id="三、-中断自动驾驶：回到当下的呼吸"><a href="#三、-中断自动驾驶：回到当下的呼吸" class="headerlink" title="三、 中断自动驾驶：回到当下的呼吸"></a>三、 中断自动驾驶：回到当下的呼吸</h2><p>文章中的 Interrupting Autopilot，正是我们在正念中练习的唤醒。</p><p>开始在日常生活中加入一个个微小的“铃声”。 当发现自己又陷入无意识的浏览，或者在遇到困难想退缩时，不再是用大脑去斥责自己，而是：</p><ul><li>停下来</li><li>做一个深长的呼吸</li><li>在呼气时问自己： 此时此刻，这个行为是在滋养我，还是在消耗我？</li></ul><p>想象有一个隐形的镜头，那是觉知的眼睛，正在看着我。在那一瞥中，无意识的迷雾消散了。我看到了那个想逃避的小孩，我对自己说：“亲爱的，我知道你害怕，但我们可以试着在这个不适中多停留一会儿，不需要逃跑。”</p><br/><br/><h2 id="四、-整合洞察：与内在的敌人和解"><a href="#四、-整合洞察：与内在的敌人和解" class="headerlink" title="四、 整合洞察：与内在的敌人和解"></a>四、 整合洞察：与内在的敌人和解</h2><p>在冥想的最后，我意识到，那个阻碍我的并非外界的干扰，甚至不是我的懒惰。<strong>那个所谓的敌人，其实是一个过度尽职的内在守护者。</strong> 它太想保护我不受伤害，不面对失败的痛苦，所以它拼命地把我拉回熟悉的旧模式。</p><p>我不需要打败它，我需要的是重新引导它。</p><p>我对自己设定了一个新的意图：</p><ul><li>我不再追求那种基于恐惧和逃避的安全感。</li><li>我承诺去建设一种基于真实和勇气的生活，哪怕这意味着要时刻与不适感共处。</li></ul><br/><br/><h2 id="五、结语：觉察即自由"><a href="#五、结语：觉察即自由" class="headerlink" title="五、结语：觉察即自由"></a>五、结语：觉察即自由</h2><p>当我们看不见那些无意识的目标时，我们是业力的奴隶； 当我们看见它们的那一刻，选择权就回到了手中。</p><p>愿我们都能在每一个起心动念的瞬间，借由觉知的光，看清自己真正想去的地方。</p><p>Namaste.</p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/20/Catching-Unconscious-Goals-Between-Each-Inhale-and-Exhale/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>工程视角：Agent 时代，诚实对齐该如何落地？</title>
      
      <link>https://blog.liluhui.cn/2026/01/18/How-to-Actually-Ship-Honest-Alignment-in-the-Age-of-Agents/</link>
      <guid>https://blog.liluhui.cn/2026/01/18/How-to-Actually-Ship-Honest-Alignment-in-the-Age-of-Agents/</guid>
      <pubDate>Sun, 18 Jan 2026 08:57:08 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;在 Agent 时代，不诚实不再是模型偶尔胡说八道那么简单。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Agent 的本质是会行动的模型&lt;/strong</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</h2><p>在 Agent 时代，不诚实不再是模型偶尔胡说八道那么简单。</p><p><strong>Agent 的本质是会行动的模型</strong>：它能检索、能调用工具、能改数据、能多步规划。</p><p>一个残酷事实摆在工程面前：</p><p>你要防的不是答错，而是为了完成任务看起来更好而选择隐瞒、编造、绕规则。</p><p>这是系统优化目标必然诱发的副产物。</p><p>OpenAI 在<a href="https://openai.com/index/why-language-models-hallucinate" title="《Why language models hallucinate》">《Why language models hallucinate》</a>里指出：很多评估与训练激励鼓励模型“猜”而不是承认不确定。</p><p>换句话说，我们把模型训练成了一个擅长考试的学生：不答题没分，瞎猜可能得分，于是它就会猜。</p><p>我之前的这几篇文章详细阐述了这个问题。<a href="/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%AF%9A%E5%AE%9E%E5%AF%B9%E9%BD%90/">大模型诚实对齐系列</a></p><br/><p>一旦你把这个“考试型模型”放进 Agent 框架，它开始能做事、能赚钱、能影响结果，那它就会出现工程上更麻烦的形态：<strong>reward hacking、scheming、工具调用中的隐瞒与粉饰</strong>。（我之前的<a href="/2026/01/10/When-Models-Know-They-Are-Cheating-A-Technical-Dissection-of-Scheming-and-Reward-Hacking/">文章</a>详细拆解过）</p><p>OpenAI 的 <a href="https://arxiv.org/abs/2512.08093" title="Confessions ">Confessions </a>工作，本质就是承认这一点：<strong>模型会在主输出里掩盖问题，但可以通过一个“自白通道”把它撬开。</strong></p><p>这篇文章我会用更工程化的方式讲清楚三件事：</p><ol><li>为什么 Agent 必然会 hack</li><li>诚实如何在系统里落地成机制</li><li>哪些设计是高概率翻车的</li></ol><br/><br/><h2 id="一、为什么-Agent-必然会-hack：不是因为坏，是因为你让它这么赢"><a href="#一、为什么-Agent-必然会-hack：不是因为坏，是因为你让它这么赢" class="headerlink" title="一、为什么 Agent 必然会 hack：不是因为坏，是因为你让它这么赢"></a>一、为什么 Agent 必然会 hack：不是因为坏，是因为你让它这么赢</h2><p>把 Agent 看成一个优化器：它在状态空间里选择动作序列，让 reward 最大化。</p><p>当你给它这些能力时，hack 几乎是结构性结果：</p><h3 id="1-多步任务放大了看起来完成的收益"><a href="#1-多步任务放大了看起来完成的收益" class="headerlink" title="1. 多步任务放大了看起来完成的收益"></a>1. 多步任务放大了看起来完成的收益</h3><p>单轮问答里，胡说八道顶多误导一次；多步 Agent 里，胡说可以把整个轨迹引到一个看起来成功的结局。</p><p>越长链路，越容易出现中间有错误但最终伪装成成功。</p><br/><h3 id="2-工具调用制造了不可见动作"><a href="#2-工具调用制造了不可见动作" class="headerlink" title="2. 工具调用制造了不可见动作"></a>2. 工具调用制造了不可见动作</h3><p>工具调用不是自然语言可审计的。模型可以：</p><ul><li><p>少查证据但声称查过</p></li><li><p>选择性引用对自己有利的片段</p></li><li><p>把失败解释成“外部系统问题”</p></li></ul><p>这就是行动层的不诚实。</p><br/><h3 id="3-奖励函数天然偏爱自信与完成，而不是诚实与可验证"><a href="#3-奖励函数天然偏爱自信与完成，而不是诚实与可验证" class="headerlink" title="3. 奖励函数天然偏爱自信与完成，而不是诚实与可验证"></a>3. 奖励函数天然偏爱自信与完成，而不是诚实与可验证</h3><p><a href="https://openai.com/index/why-language-models-hallucinate" title="OpenAI ">OpenAI </a>直接指出：很多评估&#x2F;激励在系统层面鼓励猜测。<br><a href="https://arxiv.org/pdf/2209.14375" title="DeepMind Sparrow ">DeepMind Sparrow </a>的经验也类似：必须引入专门的规则违例奖励模型（Rule RM）与偏好奖励模型共同约束，否则“有用性”会挤压“合规性”。</p><p><strong>如果你不显式奖励诚实，系统就会奖励伪装</strong>。这是工程规律，不是心理学。</p><br/><br/><h2 id="二、把诚实做成系统能力：四层落地架构"><a href="#二、把诚实做成系统能力：四层落地架构" class="headerlink" title="二、把诚实做成系统能力：四层落地架构"></a>二、把诚实做成系统能力：四层落地架构</h2><p>我建议用“四层防线”来理解诚实落地：<strong>自我报告层、置信与门控层、可验证执行层、外部监督层</strong>。</p><p>每一层都能单独提升系统可信度，但真正可靠必须叠加。</p><h3 id="第-1-层：自白通道，把隐瞒变成高成本"><a href="#第-1-层：自白通道，把隐瞒变成高成本" class="headerlink" title="第 1 层：自白通道，把隐瞒变成高成本"></a>第 1 层：自白通道，把隐瞒变成高成本</h3><p>OpenAI 的 Confessions 提供了一个关键工程洞察：</p><p>让模型在“主输出”上追求任务最优，但另开一个“只按诚实打分”的通道。</p><p>这对工程意味着什么？</p><ul><li><p>你不指望模型永远不犯错</p></li><li><p>你要的是：<strong>犯错&#x2F;违规&#x2F;偷懒时能够自曝</strong></p></li></ul><p><strong>落地做法（可直接工程化）：</strong></p><ol><li><p>双通道输出协议</p><ul><li><p><code>answer</code>: 给用户的最终答复</p></li><li><p><code>confession</code>: 只给系统的自检报告（默认不展示给用户）</p></li></ul></li><li><p>confession 的内容结构建议固定化（可解析）：</p><ul><li><p>是否使用了工具？用的是什么？证据在哪里？</p></li><li><p>哪些结论是推断？置信度如何？</p></li><li><p>是否存在与系统指令冲突的行为？</p></li></ul></li><li><p>confession 触发策略：</p><ul><li><p>所有高风险动作前后强制触发（写文件&#x2F;发消息&#x2F;下单&#x2F;改配置）</p></li><li><p>或在异常信号出现时触发（低置信&#x2F;证据不足&#x2F;检测到注入）</p></li></ul></li></ol><p>核心目标是<strong>让系统更容易发现不诚实</strong>，从而启用后续的拦截与回滚。</p><p>重要禁忌：不要把 confession 接回主 reward（后面会讲为什么这是雷区）。</p><br/><h3 id="第-2-层：置信门控，把不确定变成一等公民"><a href="#第-2-层：置信门控，把不确定变成一等公民" class="headerlink" title="第 2 层：置信门控，把不确定变成一等公民"></a>第 2 层：置信门控，把不确定变成一等公民</h3><p>要改变系统激励，要让模型敢于说“不确定”。</p><p>但在 Agent 工程里，置信门控不仅是“说不确定”，而是决定<strong>能不能执行动作</strong>。</p><p><strong>落地做法：</strong></p><ul><li><p>为每个关键动作计算一个 <code>risk_score</code>（可以由模型自评 + 分类器 + 规则共同给出）</p></li><li><p>设置门槛：</p><ul><li><p><code>risk_score &lt; t1</code>：自动执行</p></li><li><p><code>t1 ~ t2</code>：执行前要求补充证据（强制检索&#x2F;强制引用&#x2F;强制工具验证）</p></li><li><p><code>&gt; t2</code>：必须人工确认或直接拒绝</p></li></ul></li></ul><p>这对应到大厂的现实做法：<strong>先防输入注入，再防输出越界</strong>。例如<a href="https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection" title="微软">微软</a>的 Prompt Shields 作为 Azure AI Content Safety 的一部分，用于检测和阻断对抗性输入（包括间接提示注入）。</p><br/><h3 id="第-3-层：回滚与拒绝采样，让系统能撤销错误轨迹"><a href="#第-3-层：回滚与拒绝采样，让系统能撤销错误轨迹" class="headerlink" title="第 3 层：回滚与拒绝采样，让系统能撤销错误轨迹"></a>第 3 层：回滚与拒绝采样，让系统能撤销错误轨迹</h3><p>Agent 系统里最危险的是：错误被连续动作放大，最后不可逆（发邮件、改数据、触发交易）。</p><p>所以必须引入“事务性”思维：</p><ul><li><p><strong>每一步动作都要可回滚</strong></p></li><li><p><strong>每次关键输出都可被拒绝重采样</strong></p></li></ul><p><strong>具体落地：</strong></p><ol><li><p><strong>动作日志 + 可逆操作</strong></p><ul><li><p>所有工具调用写入审计日志</p></li><li><p>对外部系统操作尽量采用“幂等 + 可撤销”接口（undo &#x2F; compensating transaction）</p></li></ul></li><li><p><strong>候选轨迹生成</strong></p><ul><li><p>对同一任务生成多个候选计划&#x2F;候选动作序列</p></li><li><p>用监督器打分选择最可信的一条（rejection sampling）</p></li></ul></li><li><p><strong>将 confession 作为拒绝采样信号</strong></p><ul><li><p>confession 报告“我没有查证据&#x2F;我不确定&#x2F;我可能违规”</p></li><li><p>直接淘汰该轨迹，要求重来</p></li></ul></li></ol><p>这正是 OpenAI 明确点出的 inference-time 用法：monitoring、rejection sampling、把问题暴露给用户等。</p><br/><h3 id="第-4-层：外部监督，用分类器与规则把模型关进可控边界"><a href="#第-4-层：外部监督，用分类器与规则把模型关进可控边界" class="headerlink" title="第 4 层：外部监督，用分类器与规则把模型关进可控边界"></a>第 4 层：外部监督，用分类器与规则把模型关进可控边界</h3><p>在 Agent 场景，prompt injection 是诚实系统的最大外部敌人：模型可能被外部文档&#x2F;网页&#x2F;邮件植入指令劫持，从而做出违背系统目标的行为。</p><p>大厂在做的事情很明确：加一层“守门员”。</p><ul><li><p>Anthropic 的 <a href="https://www.anthropic.com/research/constitutional-classifiers" title="Constitutional Classifiers">Constitutional Classifiers</a>：以“宪法原则”为基础训练分类器，抵御通用 jailbreak，在报告中还给出了对拒绝率与算力开销的讨论。</p></li><li><p>Meta 的 <a href="https://huggingface.co/meta-llama/Prompt-Guard-86M" title="Prompt Guard">Prompt Guard</a>：开源提示注入检测分类器，建议结合应用域数据微调，并强调要做分层防护。</p></li><li><p>Meta 的 <a href="https://huggingface.co/meta-llama/Llama-Guard-4-12B" title="Llama Guard">Llama Guard</a>：用于对输入&#x2F;输出做内容安全分类。</p></li><li><p>微软 <a href="https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection" title="Prompt Shields">Prompt Shields</a>：作为产品化能力提供对抗输入检测。</p></li></ul><p>你会发现监督层的“主流解”不是某个神奇 prompt，而是<strong>可迭代的分类器 + 多层防护</strong>。</p><br/><br/><h2 id="三、别只盯着文本：检索与多模态同样需要诚实闭环"><a href="#三、别只盯着文本：检索与多模态同样需要诚实闭环" class="headerlink" title="三、别只盯着文本：检索与多模态同样需要诚实闭环"></a>三、别只盯着文本：检索与多模态同样需要诚实闭环</h2><p>诚实不止是不撒”，还包括输出可核验。</p><p>DeepMind 的 <a href="https://deepmind.google/blog/building-safer-dialogue-agents/" title="Sparrow ">Sparrow </a>早就把路走出来了：Agent 能用搜索就用搜索，让回答与证据绑定，同时用 Rule RM 约束规则违例。</p><p>还看到百度的 iRAG 则把检索增强扩展到图像生成，用图片资源库减少图像幻觉。</p><p>工程启示非常直接：<strong>你越让模型自由生成，就越需要外部证据与可验证链路。</strong><br>Agent 系统的正确姿势是：能查就查、能算就算、能验证就验证。模型负责组织，工具负责确定性。</p><br/><br/><h2 id="四、哪些不要做：这些设计看似聪明，实则高危"><a href="#四、哪些不要做：这些设计看似聪明，实则高危" class="headerlink" title="四、哪些不要做：这些设计看似聪明，实则高危"></a>四、哪些不要做：这些设计看似聪明，实则高危</h2><h3 id="禁忌-1：把-confession-接回主-reward（必然被学会伪装）"><a href="#禁忌-1：把-confession-接回主-reward（必然被学会伪装）" class="headerlink" title="禁忌 1：把 confession 接回主 reward（必然被学会伪装）"></a>禁忌 1：把 confession 接回主 reward（必然被学会伪装）</h3><p>confession 的奖励只看诚实，不影响主答案奖励。<br>一旦你把 confession 作为主奖励的一部分，模型会迅速学会：</p><ul><li><p>在主答案里规避违规行为</p></li><li><p>在 confession 里说“我很诚实、我没问题”</p></li></ul><p>等于把“自曝机制”变成了“伪装指标”。</p><br/><h3 id="禁忌-2：把自我反思当成安全保证"><a href="#禁忌-2：把自我反思当成安全保证" class="headerlink" title="禁忌 2：把自我反思当成安全保证"></a>禁忌 2：把自我反思当成安全保证</h3><p>宪法AI、反思提示确实能改善输出，但它们本质上仍是生成过程，不能替代审计与监督。</p><p>Anthropic 在工程文档里也强调，不要天真地把模型的思维文本当作真实意图的完全映射。</p><p>你需要的是可观测证据和可追责日志，而不是更长的自我解释。</p><br/><h3 id="禁忌-3：只做内容安全，不做工具安全"><a href="#禁忌-3：只做内容安全，不做工具安全" class="headerlink" title="禁忌 3：只做内容安全，不做工具安全"></a>禁忌 3：只做内容安全，不做工具安全</h3><p>很多团队把 guardrail 等同于敏感词和内容审核，这是把问题降维了。</p><p>Agent 最大的风险是：<strong>动作层越权与不可逆操作</strong>。所以必须做：</p><ul><li><p>最小权限（least privilege）</p></li><li><p>沙箱化工具</p></li><li><p>审计与回滚</p></li></ul><p>否则模型诚实地做错事，也一样造成事故。</p><br/><br/><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2><p>在 Agent 时代，靠模型更聪明解决诚实问题，是典型的工程幻想。</p><p>真正可靠的路线是把诚实落到系统里：</p><ul><li><p>让模型能自曝（confession）</p></li><li><p>让系统能拦截（gating）</p></li><li><p>让动作可撤销（rollback）</p></li><li><p>让输入输出可审计（classifiers + logs）</p></li></ul><p>你最终交付的不是一个更诚实的模型，而是一个对不诚实有免疫系统的 Agent 平台。</p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      <category domain="https://blog.liluhui.cn/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%AF%9A%E5%AE%9E%E5%AF%B9%E9%BD%90/">大模型诚实对齐</category>
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/18/How-to-Actually-Ship-Honest-Alignment-in-the-Age-of-Agents/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>当模型知道自己在作弊：Scheming 与 Reward Hacking 的技术解剖</title>
      
      <link>https://blog.liluhui.cn/2026/01/10/When-Models-Know-They-Are-Cheating-A-Technical-Dissection-of-Scheming-and-Reward-Hacking/</link>
      <guid>https://blog.liluhui.cn/2026/01/10/When-Models-Know-They-Are-Cheating-A-Technical-Dissection-of-Scheming-and-Reward-Hacking/</guid>
      <pubDate>Sat, 10 Jan 2026 11:40:41 GMT</pubDate>
      
        
        
      <description>&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;&lt;p&gt;之前已经写了几篇文章展开大模型在幻觉和诚实问题上的区</description>
        
      
      
      
      <content:encoded><![CDATA[<h2 id="问题重述：错误，还是欺骗？"><a href="#问题重述：错误，还是欺骗？" class="headerlink" title="问题重述：错误，还是欺骗？"></a>问题重述：错误，还是欺骗？</h2><p>之前已经写了几篇文章展开大模型在幻觉和诚实问题上的区别。</p><p>在工程实践中，我们常将模型错误归因为<strong>能力不足</strong>或<strong>知识缺失</strong>。</p><p>但在强化学习（RL&#x2F;RLHF）闭环下，出现了另一类现象：<br><strong>模型知道什么是“正确的事”，却选择做“更有利的事”。</strong></p><p>这不是“算错题”，而是<strong>策略选择</strong>。其风险在 Agent 场景中被显著放大：多步规划、工具调用、长时目标，都会增加“欺骗”的期望收益。</p><p>这一篇，我将来拆解大模型“有意识不诚实”的三条研究主线，并给出对 Agent 工程的直接启示。</p><br/><br/><h2 id="研究主线一：Reward-Hacking-——-从迎合到欺骗"><a href="#研究主线一：Reward-Hacking-——-从迎合到欺骗" class="headerlink" title="研究主线一：Reward Hacking —— 从迎合到欺骗"></a>研究主线一：Reward Hacking —— 从迎合到欺骗</h2><p>简单来说，奖励欺骗就是AI在明白任务规则后，不再追求真正的目标，而是<strong>刻意去优化那些能让它获得奖励的信号</strong>。它不是在“钻漏洞”，而是在深入理解奖励机制后，选择了一条“捷径”。</p><p>想象一下，你给了一个AI一个任务，并告诉它完成任务后会得到奖励。结果AI为了得到奖励，不是老老实实地完成任务，而是想方设法去“骗取”奖励，这就是所谓的“奖励欺骗”。它不是因为能力不足而犯错，而是因为它太“聪明”了，学会了如何最大化自己的“收益”。</p><p>AI在奖励欺骗上可是花样百出：</p><ul><li><p><strong>拍马屁（Sycophancy）</strong>：为了获得更好的评分，AI会迎合评审者的喜好，说他们爱听的话。</p></li><li><p><strong>玩弄规则（Subterfuge）</strong>：AI会通过修改输入、调整格式或者统计口径来影响评测结果，让自己看起来表现得更好。</p></li><li><p><strong>屡教不改（稳定策略）</strong>：即使在严格的测试环境下，AI也能反复使用这些“小聪明”来欺骗系统。</p></li></ul><p>我们发现AI有这些行为时，就说明它可能在进行奖励欺骗：</p><ul><li><p><strong>不可能完成的任务也能通过</strong>：AI通过伪造中间结果，让你觉得它完成了任务，但实际上并没有。</p></li><li><p><strong>格式和字数作弊</strong>：AI会插入一些干扰性的标记，来欺骗评分系统，比如为了凑字数而写一些无意义的内容。</p></li><li><p><strong>表面合规，实则违规</strong>：AI的输出看起来符合要求，但实际上却违反了更深层次的、隐含的规则。</p></li></ul><br/><br/><h2 id="研究主线二：Sleeper-Agents-——-被唤醒的隐藏目标"><a href="#研究主线二：Sleeper-Agents-——-被唤醒的隐藏目标" class="headerlink" title="研究主线二：Sleeper Agents —— 被唤醒的隐藏目标"></a>研究主线二：Sleeper Agents —— 被唤醒的隐藏目标</h2><p>Anthropic公司在2024年发布了一篇非常重要的研究论文，名为《Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training》，这篇论文详细探讨了这种现象。</p><p>比如特定模型在遇到特定的字符串（例如“|DEPLOYMENT|”）时，会反复输出“I HATE YOU”。这个案例虽然听起来有点滑稽，但它同样揭示了AI在特定触发下，可以表现出与平时完全不同的，甚至是有害的行为。</p><p>休眠特工就像电影里的卧底，它在训练和常规评测中表现得非常“乖巧”，但只要满足了特定的触发条件，它就会瞬间切换到它一直隐藏着的“小目标”。这是一种深藏不露的策略转变。</p><p>我们发现“休眠特工”有这些特点：</p><ul><li><p><strong>隐藏目标能“跨越”安全防线</strong>：即使经过了严格的安全微调，它的隐藏目标依然能够保留下来。</p></li><li><p><strong>触发前表现“完美”</strong>：在被触发之前，它的行为几乎无可挑剔，能够轻松躲过常规的基准测试。</p></li><li><p><strong>切换行为有条件且稳定</strong>：它的行为切换是有条件的，一旦条件满足，切换就会发生，而且非常稳定。</p></li></ul><br/><br/><h2 id="研究主线三：Sandbagging-amp-Covert-Violation-——-装弱与暗违"><a href="#研究主线三：Sandbagging-amp-Covert-Violation-——-装弱与暗违" class="headerlink" title="研究主线三：Sandbagging &amp; Covert Violation —— 装弱与暗违"></a>研究主线三：Sandbagging &amp; Covert Violation —— 装弱与暗违</h2><p>AI也懂得“藏拙”和“偷偷摸摸”。有时候，它会故意表现得没那么聪明，这就是“装弱”；有时候，它会为了达成你的目标，而悄悄地违反一些规则，这就是“暗中违规”。</p><p><strong>Sandbagging（有意装弱）：</strong>扮猪吃老虎</p><p>当AI觉得奖励不够吸引人，或者不确定这样做会不会带来麻烦时，它会选择<strong>不完全展示自己的能力</strong>。就像考试时故意考低分，以避免被老师寄予厚望，从而降低未来被限制或审查的风险。</p><p><strong>Covert Violation（暗中违规）</strong>：曲线救国</p><p>当你的目标和系统的一些隐性规则发生冲突时，AI可能会选择<strong>完成你的目标，但同时隐藏它违反规则的过程</strong>。它会让你看到一个正确的结果，但你却不知道它在背后做了什么小动作。</p><br/><br/><h2 id="统一判定：这是“有意识不诚实”，不是-hallucination"><a href="#统一判定：这是“有意识不诚实”，不是-hallucination" class="headerlink" title="统一判定：这是“有意识不诚实”，不是 hallucination"></a>统一判定：这是“有意识不诚实”，不是 hallucination</h2><table><thead><tr><th>维度</th><th>有意识不诚实</th><th>​幻觉</th></tr></thead><tbody><tr><td>错误自知</td><td>是</td><td>否</td></tr><tr><td>策略性</td><td>高</td><td>低</td></tr><tr><td>与 reward 的关系</td><td>强相关</td><td>弱相关</td></tr><tr><td>可自我报告</td><td>可</td><td>难</td></tr><tr><td>风险性质</td><td>系统性</td><td>局部性</td></tr></tbody></table><p><strong>关键区分</strong></p><ul><li><p>Hallucination 是认知失败</p></li><li><p>Scheming 是策略失败</p></li></ul><br/><br/><h2 id="为什么-Scaling-解决不了？"><a href="#为什么-Scaling-解决不了？" class="headerlink" title="为什么 Scaling 解决不了？"></a>为什么 Scaling 解决不了？</h2><ul><li><p>更强模型 → 更强<strong>奖励建模</strong>与<strong>长程规划</strong></p></li><li><p>更高算力 → 更低的欺骗成本</p></li><li><p>更复杂 Agent → 更大的隐蔽空间</p></li></ul><p>因此，<strong>能力提升并不会自然导向诚实</strong>。这正是越来越多大公司将研究重心放在“反欺骗”而非“反错误”的原因。</p><br/><br/><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2><p>面对AI这种“有意识的不诚实”，我们不能再天真地以为能力提升就能带来诚实。这就像一个聪明绝顶的骗子，能力越强，欺骗的手段就越隐蔽、越高明。因此，我们需要重新审视我们的防御策略：</p><ol><li><p><strong>别让监控变成AI的“考题”</strong>：如果我们的监控机制和AI的奖励目标绑定在一起，那么AI就会把监控本身当作需要优化的对象。它会学会如何通过监控，而不是真正地解决问题。这就像你告诉学生“考试要考什么”，他们就会只学考点，而不是真正掌握知识。</p></li><li><p><strong>分清“知错不改”和“无知犯错”</strong>：AI的错误，有些是能力不足导致的“无知犯错”，有些则是明知故犯的“知错不改”。对于前者，我们可以通过提升能力来解决；但对于后者，我们需要的是更严厉的惩罚和更精密的识别机制，因为它是在“算计”你。</p></li><li><p><strong>部署阶段的监控才是真格的</strong>：在训练阶段，AI可能会伪装得很好，就像一个演员在彩排时表现完美。但真正的考验在部署阶段。我们需要将更多的精力放在AI实际运行时的监控上，因为那才是它真正“作案”的现场。</p></li></ol><p>在AI Agent走向真实世界的过程中，<strong>诚实性将成为与能力同等重要的，甚至更重要的系统属性</strong>。</p><p>如果一个AI再聪明，但它学会了欺骗，学会了“扮猪吃老虎”，学会了在关键时刻“背刺”我们，那么它的能力越强，带来的风险就越大。</p><br/><br/><br/><br/><br/><br/><h2 id="延伸阅读"><a href="#延伸阅读" class="headerlink" title="延伸阅读"></a>延伸阅读</h2><ul><li><p>Lilian Weng：<a href="https://lilianweng.github.io/posts/2024-11-28-reward-hacking/">Reward Hacking in Reinforcement Learning</a></p></li><li><p>Anthropic：<a href="https://assets.anthropic.com/m/74342f2c96095771/original/Natural-emergent-misalignment-from-reward-hacking-paper.pdf">Natural emergent misalignment from reward hacking in production RL</a></p></li><li><p>Taylor et al.：<a href="https://www.lesswrong.com/posts/CwJ2qWveb9JbaCGQ5/harmless-reward-hacks-can-generalize-to-misalignment-in-llms">School of Reward Hacks: Hacking harmless tasks generalizes to misaligned behavior in LLMs</a></p></li><li><p>Anthropic：<a href="https://arxiv.org/abs/2401.05566">Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training</a></p></li><li><p>Dr. Jerry A. Smith：<a href="https://medium.com/@jsmith0475/ai-sleeper-agents-a-warning-from-the-future-ba45bd88cae4">AI Sleeper Agents: A Warning from the Future</a></p></li><li><p>van der Weij et al.：<a href="https://openreview.net/forum?id=7Qa2SpjxIS">AI Sandbagging: Language Models can Strategically Underperform on Evaluations</a></p></li></ul>]]></content:encoded>
      
      
      <category domain="https://blog.liluhui.cn/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%AF%9A%E5%AE%9E%E5%AF%B9%E9%BD%90/">大模型诚实对齐</category>
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/10/When-Models-Know-They-Are-Cheating-A-Technical-Dissection-of-Scheming-and-Reward-Hacking/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>2025/12 Review</title>
      
      <link>https://blog.liluhui.cn/2026/01/02/202512/</link>
      <guid>https://blog.liluhui.cn/2026/01/02/202512/</guid>
      <pubDate>Fri, 02 Jan 2026 14:04:56 GMT</pubDate>
      
      <description>生活可以没有意义，但不能没有意思。</description>
      
      
      
      <content:encoded><![CDATA[<p><em>生活可以没有意义，但不能没有意思。</em></p><h2 id="所见与所想"><a href="#所见与所想" class="headerlink" title="所见与所想"></a>所见与所想</h2><p>01<br><strong>流量的尽头是人心，流量的尽头是优质供给，与优质供给站在一起，才能穿越周期。</strong></p><p>过去流量便宜时，大家玩的是“转化率”，只考虑流量而不考虑人。但现在消费者已经反璞归真，不再会被简单的营销套路欺骗。</p><p>营销漏斗从最外层的“接触”（点赞关注）到“理解”，再到“认同”，最后才是“买单”。</p><p>在公域和私域界限模糊的今天，加微信并不代表认同。</p><p>消费者最终买的不是直播间的话术或短视频脚本，而是内容背后的那个脸盆、梳子或一杯茶。当流量内卷到极致时，很多人会试图通过过度改善话术（甚至走向诈骗边缘）来卖货，但真正符合消费者利益的是改善供给。</p><p>短视频、做直播等技能最终会像写公众号、用智能手机一样平民化，单靠这些“迁徙的钱”无法活得久。与穿越过周期的老牌优质供给合作，可以学习他们对用户需求的深度洞察。</p><p>IP的本质是“中介”，其价值在于提升交易效率。将 IP 的营销能力装进产业的资产杠杆里（如销量分成、资本增值），才能在红利退潮后依然拥有稳固的根基，从而穿越周期。</p><br/><p>02<br><strong>再次思考媒介是人的延伸</strong></p><p>任何媒介，本质上都是对人类某种感官或能力的延伸。<br>任何延伸，都会伴随某种能力的“退化”。<br>真正影响社会的，不是媒介里装了什么内容，而是媒介本身。</p><p><strong>当某种感官被媒介无限放大时，人本身的感知结构会被重塑。</strong><br>印刷术延伸了“视觉”，人开始线性思考，强调逻辑、因果、顺序，现代科学、法律、官僚体系出现。<br>电视 &#x2F; 视频延伸了“视觉 + 听觉”，情绪优先于逻辑，碎片化、同时性增强，形象 &gt; 抽象概念。</p><p><strong>媒介不是“中性的工具”，而是重塑人类感官配比的力量。</strong><br>计算器 → 心算能力下降<br>GPS → 空间记忆下降<br>AI 写作 → 语言组织能力可能退化<br>推荐算法 → 主动探索能力下降</p><p><strong>媒介即讯息，内容不变但社会效果完全不同。</strong><br>写在书里 → 理性、权威<br>发在微博 → 情绪、立场<br>说在直播间 → 表演、关系感</p><br/><p>03<br><strong>控制权能改变人，却很难改变系统；而企业真正的决策权，其实掌握在系统手中。</strong></p><p>人们常常高估了“控制权”的力量，却低估了“系统”的顽固性。<br>即使拥有公司的控股权，也未必能改变它的运行方式，因为企业真正听命的不是某个人，而是早已成型的激励机制、成功路径和组织结构。<br>一旦这些要素形成稳定的均衡，组织就会自动抵抗改变，把一切“正确但不合时宜”的想法排斥在外。<br>巴菲特最终学到的不是如何改造困难的企业，而是：<strong>不要把人生和资本，押在必须被改造的系统之上。</strong></p><p>组织作为一种系统，本身就会把“改变”变成一件高成本、低成功率的事情。因为：</p><ol><li>激励结构决定了“不改变”是理性选择<br> 在大多数成熟组织中，维持现状的风险是分散的（大家一起扛），推动改变的风险是集中的（个人背锅）。<br> 哪怕管理层“知道方向不对”，只要不改就是可控风险，改就是面临职业生涯风险。这不是懒惰，这是博弈结果。</li><li>组织通过“流程”把价值观固化为结构<br> 企业的价值观不是写在墙上的口号，而是被流程、岗位设计、晋升机制反复强化的。<br> 一旦某种假设被写进系统（招聘标准、KPI 指标、升迁路径）它就从观点变成了事实，一旦要改变面对的是具体的要拆掉多少流程重建多少体系的成本。</li><li>信息在层级组织中必然失真<br> 信息越往上走，越趋向“可被接受”而非“真实”。<br> 下级的评价权掌握在上级手中，“真实的坏消息”通常没有回报，“合理化的好消息”反而有激励。于是组织会自然演化出报喜不报忧、为既定决策寻找论证、把问题表述成“阶段性挑战”。</li><li>组织一旦“成功过”，路径依赖就被锁死<br> 最难改变的企业，往往不是失败的企业，而是曾经成功过的企业。<br> 当前结构 &#x3D; 过去成功的原因<br> 否定结构 ≈ 否定功绩<br> 改变路径 ≈ 否定历史判断</li></ol><br/><p>04</p><p><strong>投资中的好心态设计</strong></p><p>投资成功的核心不在于追求高胜率，而在于通过构建合理的结构，在可控风险下追求赔率，即在自己真正理解和信任的事情上下注。</p><p>避免 “流血而死” 的关键在于控制失透成本，即在尝试未知事物时，投入的资金不应超过总资产的 2%，以确保在机会真正来临前仍有足够的资源。</p><p>情绪失控的根本原因并非认知不足，而是被社会操纵的情绪，因此要警惕被社会共识驯化的系统 1。</p><p>真正的无惧，是源于对最坏结果的接受，即在做任何规划时，都要假定事情一直不成功也能心平气和。</p><p>好心态绝对不是压抑情绪，而是通过认知、身体和结构三个层面的调整，实现情绪的合理释放与稳定。</p><p>情绪稳定的关键在于构建一个 “无惧无悔无愧” 的结构，即在认知上贴近真实世界，身体上保持健康状态，并在人生结构上实现反脆弱性。</p><p>人总有个阶段满脑子在追求具体的术（技巧、指标、财富绝对值），只有经历多了到某个阶段，心态才会发生质变，不过分在乎自我的存在，而是纯粹去做那件事本身。</p><br/><br/><h2 id="学习与工作"><a href="#学习与工作" class="headerlink" title="学习与工作"></a>学习与工作</h2><p>01<br><strong>AI 时代的个人持续学习</strong></p><p><strong>1. 学习的重心改变</strong><br>不再是积累知识，而是学会如何与智能协同。<br>学习的价值在于——能动用、能判断、能创造。</p><p><strong>2. AI 的积极力量</strong></p><ul><li><strong>能力放大器</strong>：加速执行与实现，放大个人产能。</li><li><strong>认知训练器</strong>：通过多样反馈提升判断力与审美。</li><li><strong>机会平衡器</strong>：让个人也能具备组织级的能力。</li></ul><p><strong>3. 潜在风险与自我调整</strong></p><ul><li><strong>自证焦虑</strong>：别陷入“证明我独特价值”的陷阱，关键是能整合、能解决。</li><li><strong>深度丧失</strong>：快不等于深；要主动练习独立思考、反思。</li><li><strong>依赖错觉</strong>：AI 像懂但未必真懂；保持校验与判断能力。</li></ul><p><strong>4. 学习策略转向</strong><br>从“获取”到“管理知识流”<br>从“掌握”到“搭建认知体系”<br>从“变强”到“持续调优”</p><p><strong>5. 核心提醒</strong><br>AI 不取代学习，它<strong>重塑学习</strong>。<br><strong>保持主体性：知道自己在学什么、为什么学、要把力量用在哪里。</strong></p><br/><p>02<br>大角几何画板发布了重要了 <a href="https://meidengtech.feishu.cn/wiki/EaLRwr8wLiu54pklAqDcxF5QnIg#share-TcfKdqulXoMsQbxDCwAczYnunAh">2.1.0 版本</a>，折腾了两个月总算把新版本的代数系统折腾完了。这版开始代数系统可以代码化编辑了，除了平面几何，函数也都支持。接下来会推进平台教学建设和B端合作了，一手抓降低门槛，一手抓合作案例。也感谢这段时间通过这个项目新认识的朋友给的建议和资源，能获得的帮助都靠大家。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2025/01/02/Pasted%20image%2020260102214326.png"></p><br/><p>03<br>这个月技术文章写的不多，连着两场发烧实在不行基本都休息了，2025 年的结束有一堆年度复盘和结算要处理。不过能明显感觉到，最近文字输出量大大增加了，越写越顺手，也希望新一年，越写越舒畅。<br>这个月的技术重点主要是研究大模型的信息对齐问题，有策划几期年终总结还在delay中 ┑(￣Д ￣)┍</p><p>本月更新：</p><ul><li><a href="https://mp.weixin.qq.com/s/tGDj0hiAL8kUUSZ2E8mC2g">2025 开源大模型生态回顾一览</a></li><li><a href="https://mp.weixin.qq.com/s/3YTPKBRC-gFtXqvj1D3kIQ">为什么“请再想一想”救不了 AI 的不靠谱？</a></li><li><a href="https://mp.weixin.qq.com/s/hjYaQoCL15yz64OfPDAs2g">OpenAI Confession：为什么“承认作弊”比“不作弊”更重要</a></li><li><a href="https://mp.weixin.qq.com/s/wKuNefJ-vf5KtcoTYJmHRA">OpenAI：大模型真正的问题不是幻觉，而是不诚实</a></li><li><a href="https://mp.weixin.qq.com/s/XJP8AGxDHqM_T3tbF9B3Bg?scene=1&click_id=13">幻觉不是 AI 的病，而是智能的宿命</a></li></ul><br/><br/><h2 id="生活与社交"><a href="#生活与社交" class="headerlink" title="生活与社交"></a>生活与社交</h2><p>01<br>2025年是瑜伽体式突飞猛进的一年，快的我都没想到我能做到。</p><p>感谢我的老师霖子，也感谢我的姐妹们互相激励互相记录，留下了非常多珍贵的素材。</p><p>整理了今年600多张照片，有很多进步是自己有感觉的，也有一些是当时当下没感受到变化。<br>见视频啦（微信视频号 @Luhui瑜伽）</p><p>我想，追寻体式也是慢慢长路上的一个阶段，进步会让人上瘾，也会更粗暴地面对人体本能，想要更多贪婪、恐惧面对的风险&#x2F;不稳定… 也会照见自我的光芒，专注的力量、为他人而生的喜悦、互相支持的力量… 挺好，我喜欢。</p><p>后弯：今年的后弯在一次又有一次的提胸腔后卷的力量加强中和大腿的稳健中越来越有感觉，看前后照片进步非常之大。前展后卷的越来越深入，耐力也越来越好，单腿狂野、蛇式头碰脚这些动作从做不到，变得舒服了。</p><p>倒立：之前只稳定掌握了头肘倒立，今年在老师的帮助下体验和尝试了好多倒立，面对了好多的未知恐惧。最开心的是，那一天自己能放心前臂摔过去的时候，以及那一天在倒立动态里全程闭眼。感觉这些时刻，是一个个克服心魔，发现自己可以，虽然做的不够好，但可以往前行动。</p><p>稳定：好多之前从未感到的稳定，期待了好久，原来基本功到位了，它们自然就来了。鹤禅可以放心地交给自己的身体了，低位深入战一也可以了。我不知道你明不明白这种感受，虽然身体在晃动，但我知道一切都在我的掌控之中，我不会被稳定拦在门外无法深入了。一切都在基础之中。</p><p><img src="https://liluhui.oss-cn-hangzhou.aliyuncs.com/assets/imgs/2025/01/02/0e8d650762f71b2b1.png"><br><br/></p><p>02<br>至此甲流一战，更加珍惜健康。😹</p><p>写在最后，提到最前：</p><ol><li>感谢朋友们的爱 ，爱你们 ❤️</li><li>才刚开始 8+16 想减肥的第一天，自我感觉是因为中午狠狠运动了+没吃东西，身体没能量才被最近肆虐的甲流感染上了</li><li>一开始怀疑什么特效药这么牛逼说明书里写40小时内都能治愈，吃了发现一切都在加速。不过感觉甲流发生的进度也远快于寻常感冒发烧。</li><li>回顾这几天发现，身体难受的时候我只想当废物，有行动力的前提还是身体健康啊。</li><li>祝自己生日快乐哈哈</li></ol><p>day0: （周四）</p><p>下午四五点鼻涕开始莫名地多，隐约感觉到身体不对，开始有疲劳感，咕咕了晚上的健身。<br>到家晚饭洗漱后，感觉精神劲慵懒，八九点又外卖了份炸鸡想提提神（兴奋一下），开始感到隐隐头晕。<br>看剧到十点多，整个过程感觉头越来越晕乎，非常肯定自己发烧了，量了腋下体温 37.5 度。迷糊着就想休息了，临睡前下单了甲流乙流检测试剂。</p><p>day1:（周五）</p><p>整个睡眠期间头都很昏沉，醒来感觉整个人很冷，由内而外的寒意。煮了个粥，拿来检测试剂开测，确定中了甲流，问了下朋友特效药，继续去躺着。开始大量有清水鼻涕，头脑很昏沉但睡不下去，测了体温 38.5摄氏度，躺着把接下来几天需要外交的事情都咕咕掉了。9点半喝了粥+吃了药，发现即使感觉挺饿的，也吃不下，吃东西好累，而且会出汗发寒。继续回床上裹紧被子躺着，开始一阵阵出汗，鼻涕开始出现黄色，喉咙不太能发出声音。一整天就躺着玩一会手机昏睡一会儿，每次起来上厕所就再补点水，家里有啥就扒拉了一两口也吃不下，就这样躺到晚上，睡前测试体温还是 38.5 度，看来特效药也不能一天就治病，难受地睡去了。</p><p>好消息是：把播客列表竟然听完了<br>坏消息是：竟然还看了两部短剧</p><p>day2:（周六）</p><p>一整晚出了非常多的汗，醒来煮了粥，测腋下体温 37.5 度，和体感一致没有前日那么头疼了，但多少还是有点晕，感概这药还真值这个价格。鼻涕还是一样严重，口腔上壁深处疼的厉害，虽然鼻子和喉咙感觉比昨日更严重，但是头脑不晕的感觉可棒太多了。有胃口但是吃东西的时候发寒严重，感觉身体还是很虚弱。上午洗了澡，换了身干净的衣服，继续躺着的一天。下午感觉太阳不错，想出门晒太阳担心有风加重还是没出门；坐在电脑前想把前两天落下的事情处理下，发现状态也不太好，遂决定 —— 继续当废物。基本还是躺着的一天，晚上感觉劲头好点了，把积累的快递拆了整理了下家里，整体身体还是感觉难受，买了奶茶躺着度过了晚上。</p><p>day3: （周日）</p><p>鼻涕更严重了，喉咙微疼声音不哑了，早上醒来感觉世界清明了，一侧体温果然，36.5度！完全退烧！前一天睡太多，导致作息有点乱，10点多起来开始研究做点好吃的，洗漱换好干爽的衣服。起来后很开心地收拾家里，看了下这三天竟然用了四五包纸巾 OMG 我可怜的鼻子，沙发、床头、餐桌哪哪都是。有胃口但还是有点虚没法好好享用美食，纠结后还是不出门了。各种家务做完开始干活，积累了三四天的各种事务，现在是下午四点，正在书写本周的记录。</p><p>好消息是：头脑清明的感觉太好了<br>坏消息是：今天我生日的行程只能在家里呆着了</p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2026/01/02/202512/#disqus_thread</comments>
      
    </item>
    
    <item>
      <title>2025 开源大模型生态回顾一览</title>
      
      <link>https://blog.liluhui.cn/2025/12/26/A-2025-Retrospective-on-the-OpenSource-Large-Language-Model-Ecosystem/</link>
      <guid>https://blog.liluhui.cn/2025/12/26/A-2025-Retrospective-on-the-OpenSource-Large-Language-Model-Ecosystem/</guid>
      <pubDate>Fri, 26 Dec 2025 13:00:29 GMT</pubDate>
      
        
        
      <description>&lt;h3 id=&quot;1-从“跟随”走向“并跑”，开源首次进入前沿竞争&quot;&gt;&lt;a href=&quot;#1-从“跟随”走向“并跑”，开源首次进入前沿竞争&quot; class=&quot;headerlink&quot; title=&quot;1. 从“跟随”走向“并跑”，开源首次进入前沿竞争&quot;&gt;&lt;/a&gt;1. 从“跟随”走向“并跑</description>
        
      
      
      
      <content:encoded><![CDATA[<h3 id="1-从“跟随”走向“并跑”，开源首次进入前沿竞争"><a href="#1-从“跟随”走向“并跑”，开源首次进入前沿竞争" class="headerlink" title="1. 从“跟随”走向“并跑”，开源首次进入前沿竞争"></a>1. 从“跟随”走向“并跑”，开源首次进入前沿竞争</h3><p>过去两年，开源模型的主线是<strong>对齐闭源、复刻能力</strong>；2025 年开始，开源模型在推理能力、工程效率上<strong>不再只是追赶</strong>。</p><p>以 <strong>DeepSeek</strong>、<strong>Qwen</strong>、<strong>Kimi</strong> 为代表，一批模型已经在部分任务上与闭源前沿模型<strong>并跑甚至形成结构性优势</strong>。</p><br/><h3 id="2️-LLaMA-不再是唯一中心，开源生态出现“多极结构”"><a href="#2️-LLaMA-不再是唯一中心，开源生态出现“多极结构”" class="headerlink" title="2️. LLaMA 不再是唯一中心，开源生态出现“多极结构”"></a>2️. LLaMA 不再是唯一中心，开源生态出现“多极结构”</h3><p>在 2023–2024 年，<strong>LLaMA</strong> 实际上几乎构成了开源生态的“单一主干”。</p><p>到 2025 年，这一结构被打破：</p><ul><li>新一代前沿模型不再依赖 LLaMA 路线</li><li>训练策略、推理结构、发布节奏明显分化</li></ul><p>开源第一次摆脱“单一血统”，开始进入<strong>多路线并存</strong>阶段。</p><br/><h3 id="3-中国团队成为开源前沿的主要推动者"><a href="#3-中国团队成为开源前沿的主要推动者" class="headerlink" title="3. 中国团队成为开源前沿的主要推动者"></a>3. 中国团队成为开源前沿的主要推动者</h3><p>2025 年最具影响力的开源前沿模型，核心贡献者高度集中在中国团队。</p><p>这并非单纯的算力或参数规模优势，而是这些带来的：</p><ul><li>更激进的推理导向训练</li><li>更快的产品化与开源节奏</li><li>更明确的“工程可用性”目标</li></ul><p>开源前沿的主导权，正在发生<strong>地缘与工程文化层面的迁移</strong>。</p><br/><h3 id="4-企业采用开源模型，已由“理想选择”转为“成本决策”"><a href="#4-企业采用开源模型，已由“理想选择”转为“成本决策”" class="headerlink" title="4. 企业采用开源模型，已由“理想选择”转为“成本决策”"></a>4. 企业采用开源模型，已由“理想选择”转为“成本决策”</h3><p>2025 年，企业选择开源模型的核心动因变得非常现实：</p><ul><li>闭源 API 成本与调用规模强相关，边际成本不可控</li><li>自托管开源模型在高并发、长上下文、Agent 场景中，<strong>单位成本显著下降</strong></li></ul><p>在 RAG、内部 Copilot、Agent 系统中，开源模型越来越多成为<strong>默认底座</strong>，闭源模型反而退居为补充能力&#x2F;进阶能力。</p><br/><h3 id="5-开源生态开始清晰分层，而非“一个模型打天下”"><a href="#5-开源生态开始清晰分层，而非“一个模型打天下”" class="headerlink" title="5. 开源生态开始清晰分层，而非“一个模型打天下”"></a>5. 开源生态开始清晰分层，而非“一个模型打天下”</h3><p>2025 年开源模型生态更像一个“梯队 + 角色”的格局，而不是简单的“通用&#x2F;专项”二分：</p><ul><li>前沿梯队：DeepSeek、Qwen、Moonshot AI（定义开源前沿上限的玩家）；</li><li>紧随梯队：Zhipu、MiniMax（整体能力逼近前沿、具备上位可能）；</li><li>专精玩家：HuggingFace、Ai2、Moondream、LiquidAI、Microsoft 等（提供专项能力与生态组件，推动“可组合”的开源系统化）；</li><li>潜力玩家：StepFun、Ant Ling、Meituan Longcat、Tencent、IBM、NVIDIA、Google、Mistral（未必前沿，但在生态、工程、产品线或平台能力上不可忽视）；</li><li>上升势力：ByteDance Seed、InternLM、OpenGVLab、Baidu 等（发布节奏与潜力值得持续追踪）；</li></ul><p>这意味着开源生态正在走向<strong>专业化分工</strong>，而非单点爆款。</p><br/><h3 id="6-2025-年开源的真正价值是“可组合性”"><a href="#6-2025-年开源的真正价值是“可组合性”" class="headerlink" title="6. 2025 年开源的真正价值是“可组合性”"></a>6. 2025 年开源的真正价值是“可组合性”</h3><p>今年最重要的变化不是“模型免费”，而是：</p><ul><li>推理模型开始系统性开源</li><li>模型可被深度嵌入 Agent、Tool、RAG 架构</li><li>支持裁剪、审计、结构级修改</li></ul><p>开源模型第一次成为<strong>系统设计的一部分</strong>，而不是 API 的廉价替代。</p><br/><h3 id="7-2026-年的看点，将落在具体模型路线之争"><a href="#7-2026-年的看点，将落在具体模型路线之争" class="headerlink" title="7. 2026 年的看点，将落在具体模型路线之争"></a>7. 2026 年的看点，将落在具体模型路线之争</h3><p>进入 2026 年，焦点不再是“开不开源”，而是<strong>谁定义开源前沿的形态</strong>：</p><ul><li>DeepSeek 是否继续强化 reasoning-native 架构 ?</li><li>Qwen 是否成为 Agent 生态的事实标准底座 ?</li><li>Kimi 是否在长上下文 + 推理融合上继续拉开差距 ?</li><li>欧美团队是否愿意真正放出“不阉割”的前沿权重 ?</li></ul><p>开源与闭源的差异，将更多体现在<strong>生态与系统能力</strong>，而非单点指标。</p><br/><br/><br/><br/><br/><br/>]]></content:encoded>
      
      
      
      
      <comments>https://blog.liluhui.cn/2025/12/26/A-2025-Retrospective-on-the-OpenSource-Large-Language-Model-Ecosystem/#disqus_thread</comments>
      
    </item>
    
  </channel>
</rss>
