是评测，或者说是基准测试(Benchmark)。

为什么？

因为我们已经有足够的技术方案，只要定义清楚我们要解决的问题（基准测试），就能解决它。

OpenAI 姚顺雨近期提出“AI下半场”的概念，我们已经拥有了

1. 存储大量知识的预训练模型（先验知识），并知道怎么持续训练它
2. 通过这个模型做思考推理并执行动作的 Agent 能力（环境）
3. 强化学习算法

为预训练模型补充先验知识 → Agent为模型补充工具能力→强化学习激发知识的运用，整个方案已经标准化，能很好地泛化，所有场景都适用，能快速攻破一个又一个的基准测试。

重点会变成，我们应该定义什么样的基准测试？我们已经有涵盖数学推理编程等领域非常多的基准测试，经常大模型发布刷分刷得飞起，但对现实世界的影响却并没有那么大。

显然我们应该定义更能贴近现实世界问题的基准测试，只要定义了，用上述方案就能持续优化解决它：基准测试引导收集现实世界的数据→提升预训练模型先验知识→强化学习激发模型往基准测试方向输出。

而定义的基准测试越贴近现实世界，对世界产生的影响和价值就越大。这就是 AI 下半场最重要的问题，也是做好 AI Agent 最重要的问题。（AI Agent 就是目前 AI 的代表，大模型有先验知识和推理能力，Agent 给大模型装上环境感知和行动能力，要解决现实世界的问题，一定需要 Agent）

是什么？

什么是贴近现实世界的基准测试？

过去大量的基准测试，基本是封闭世界的固定任务，例如数学题、算法题、围棋、游戏，能明确定义问题、规则、答案，定义这样的基准测试是比较容易的，规则和过程都是现成的，推理也可以属于这一类，大模型发展到这个阶段，解决这些问题也是相对容易的。

但这些任务与现实世界大家日常要解决的问题距离太远，并不是现实世界的环境，因为之前缺乏感知和处理现实世界海量复杂规则任务的能力，现在大模型和 Agent 已经初步具备了这个能力。

目前有比较多横切面上单一维度的基准测试，包括 规划能力（PlanBench、AutoPlanBench等）、工具调用能力（ToolBench、BFCL等）、反思能力（LLF-Bench、LLM-Evolve等），也有大统一的通用任务完成能力的基准测试，主要是操作浏览器和操作电脑方面，例如 OpenAI 的 browsecomp （评测复杂信息检索和理解能力），学术界的 OSWorld （评测理解 GUI 操作完成任务的能力）。

但这些横切面或者通用的基准测试，可能并不是用户关心的。AI Agent 要实用，用户角度上更关注的是垂直任务上的能力，例如它能不能帮我写好代码，做好客服，创作出好的故事，给出好的调研报告等。当前行业处于早期，先把基础通用的问题做好基准测试去解决，达到一定阈值后，垂直领域任务上的基准测试才是更重要的。

如果简单分类，可以把这些任务分为两类：目标明确和不明确的任务。

目标明确的任务

现实中有些任务，有很明确的结果是否正确的定义，能像数学那样有标准答案，但过程中又是需要跟现实环境不断交互。典型的是 AI Coding，程序能不能跑通，bug有没有修复，都是能明确验证的。其他的还有像客服、数据分析等。

这一类是最容易被 AI 突破，但要定义出好的基准测试也不容易。

发展得最好的 AI Coding，在这个领域最权威的基准测试是 SWE-Bench，它已经在尽量贴近现实世界去定义问题，以解决 github 上的真实 issue 为出发点，但它还是很难衡量实际 coding 场景中不同模型的效果。o1、DeepSeek R1、Claude 3.5 分数都在 49% 左右，但实际用起来，Claude 3.5 在可用性上高出一个档次，没有其他基准测试能反应 Claude 3.5 断档的效果，而 Claude 3.7 分数高达70%，但实际体验上跟 3.5 的差距没有分数上差距这么大。除了模型搭配上工具后，windsurf、cursor、trae、argument 等几十个 AI Coding 工具，他们实际效果差异怎样，如何评测衡量，都是不清楚的。

SWE-Bench 只覆盖了 Coding 的一部分，大型项目理解能力、视觉动画开发能力、代码CR、需求理解等，要补的基准测试还有很多，现在也有 SWE – bench Multimodal、AgentBench、SWELancer 这些基准测试在不断推出试图覆盖。

其他领域还没看到有相关的基准测试。

目标不明确的任务

大部分现实世界的任务，都是结果难以明确定义的，不是非黑即白。例如调研报告、旅行规划、简历筛选面试，各种涉及文字/图片/视频创作的场景，比如营销、故事创作、邮件回复沟通等，结果的好坏很多只有人能判断。

Deepseek 年初的一波火爆，除了各项分数刷爆外，其中有一个原因是它输出的中文质量很好，但这个点并没有基准测试能衡量到，因为确实是很难定义什么样的文字是明确的好，跟文化/偏好品味/逻辑性/多样性等都有关系。

图片视频生成也一样，过了一定门槛后，生成的图片怎样才算更好，也是有很多维度和人的主观判断，目前没有基准测试能做到。

如何做好这类任务的评测？

1. 靠人工：例如对于图片生成，常见的做法是分维度人工打分，给不同模型生成的结果人工打分综合对比，文章/视频也可以是同样的评测方式。另外也有在线盲测PK，做大批量结果PK对比，按总得分区分各模型的排行。对于自己产品内部迭代，也可以通过上线后的采纳率等数据去评估好坏。但这些需要人参与，主观成分大，难以形成公认的标准基准测试。
2. 靠模型：模型理解能力逐渐增强，它能拥有人一样的评估能力，就可以把上述靠人工的评估转为靠模型评估。例如对图片的评估，当前像4o这样的多模态模型理解能力越来越强，是能评估出部分好坏。文字也一样，可以有评估模型去评估，模型还可以根据场景自主给出评估的维度。如果大家公认某个模型的评估能力OK，定义好相关数据集、评估维度，就可以是一个基准测试，只是目前模型还没达到能与人工评估媲美的程度。
3. 靠任务分解：不衡量整体结果，只衡量中间可明确定义的部分，把任务部分转成上面提到的目标明确的任务。例如邮件沟通，只评估邮件内是否含有需要的关键信息，旅行规划，只评估是否符合定性的偏好（如最低价）、订机票API调用等操作是否正确。

如果要让 Agent 在各个领域上能很好发挥作用产出价值，可能每个领域都有自己的垂类 Agent，也都需要定义自己的一个或多个基准测试去覆盖这个领域，AI Coding 领域跑得最快，已经有多个，像客服、电商、营销、创作、医疗、教育等等每个大课题下都会有小的垂类任务，每一类任务可能都需要一个基准测试，去衡量谁在这个任务上做得最好，去促进这个任务成功率的提升。

如果要做一个垂类 Agent，最值得做的是把基准测试定义好，比较像软件开发的TDD(测试驱动开发)，在 AI 时代这种做法可能更重要，它明确问题定义，指引优化方向，提供优化数据，不会受到模型升级的影响，是这个领域 Agent 的重要资产。

附：

大模型基准测试大全：https://github.com/onejune2018/Awesome-LLM-Eval

《Survey on Evaluation of LLM-based Agents》：https://arxiv.org/abs/2503.16416

HAL（批量跑 Agent 基准测试的框架）：https://github.com/princeton-pli/hal-harness/

毕业了，下一步还需要继续拥抱变化。

春节之后火急火燎的去北京客户现场出差了 2 个月，刚回到成都又开始马不停蹄的支持公司的销售同事去拜访客户交流介绍产品的第二天中午，我接到同事的打探问我公司有啥安排，过了一会就接到了 hr 的消息说下午要打个电话，紧接着下午就告诉我这次要毕业了。

可能是大环境不够好，可能是经济不景气，可能是组织管理上出了一些问题，可能是投资人想收拢资金资产清算，可能是太阳黑子导致的大气电离环境异常，但实际的事情结论就是要从这家待了快 5 年的公司毕业了。我接到 hr 电话的心态反而不是预期中的失望和愤怒，而是保持着职业性的体面后接纳了答案。

好像事情在发生之前也总有隐喻的线索，自从前两年大股东时不时介入公司的日常管理之后并且伴随每一次的爹味与 PUA 之后，我总能感觉到公司里那股腐朽又潮湿的味道开始扩散，紧接着是在北京出差时，听到来自总部的同事说宁可在北京多待几天，也不愿意回到深圳办公室里上班，感觉有一点像是温水里煮青蛙的故事，我们这些青蛙一方面觉得当下的做法无益于长远发展于提升产品与团队的价值，另一方面又觉得不能空手走人，总得混到拿 N+1 的时候才行。

我先是在脑海中习惯性盘算这一次要毕业的同事人数占据了研发部门的三分之一，随后开始分析这一次公司下发新决定的原因，紧接着我又停止了这一次的分析与复盘，毕竟从当下开始，这些已经重复了无数次事情都开始与我无关了。相对而言，坚持一个我们熟悉的、无效的解决方法却会让自己更舒适，这是一种很常见的，自相矛盾的人类行为。

随着木已成舟，一座新的围城又出现了，毕业的朋友和那些还没毕业的前同事互相开起了玩笑，人人都说能早毕业就早毕业，但好像大家脸上的神情更像是被驯化的牛马在解开羁绊之后反而生出的不释然，虽然获得了自由，但也失去了暂时的经济收益。这几年几乎每一篇关注过的公众号都会发一篇“很严重了，我劝大家勒紧裤腰带过日子吧……”的广告，虽然早已耳闻“毕业即失业”的形势严峻，但当潮水卷到自己身上时才会感觉到潮水的冰凉吧。

但好像也没有一个明确的算法和公式来衡量每个人在这里的 ROI 是否公平且合理，随着向上管理的风气和权责不一致的风气越来越严重，大家普遍也对老板们失去了信心，能够说服自己“受人之托忠人之事”也变成了我安慰自己为数不多的理由。当然这件事也并不能归因在某几个人或者某几个角色上吧，可能大家都有自己的难处和说服自己不去改变的理由？

可能是习惯性的敏感性格，我早在前两年就在说服自己尝试改变，尝试责任心别那么重，尝试在工作中不去那么主动，尝试在日常中少去发挥点自己的热心，但按照目前的结论来看，好像没成功，只是说服自己内心的感觉能够好受一点，为了避免找工作中出现太长的 GAP 我提前把自己的线上简历都修订更新了。

刚接受离职消息的时候心态还没有很大的变化，但好像其他人会比我更敏锐的察觉到我的表现，借用同事的那句话“看的出你还是有点不舍和不甘，毕竟自己辛苦做出来的产品说没就没了。我们没你这么复杂的感情，心思早都不在这里了。”刚接受毕业消息那几天，我还因为之前出差北京时候答应承诺，陪同销售同事拜访客户（属实是资深牛马），路上别的同事听到我还在支持销售都大吃一惊。

等到真的回归到空闲的环境里，我才开始感觉到心态上的异样，习惯的生物钟和查看消息的行为忽然就不用再维持了，计划许久但搁置更久的自驾游和游泳忽然可以随时就绪了，但就像被驯化已久的螺丝钉一样，没有了那个日复一日年复一年的螺丝帽，心里还真的会有点别扭，仔细想来别扭的背后其实是来自内心的恐惧，职场中需要以结果论英雄，但生活中则是以过程论好坏；投递简历但面试机会寥寥又会进一步逼迫自己承认陷入了泥沼一般的困境。

但相比前几段工作而言，这段工作经历又确实让我在某些方面收获良多，PMF/GTM 也好，AI 应用和报价策略也罢，那些最原始的“好奇心+实践主义+颠覆定义+合作赋能”的习惯好像也还是有所提升。更别提还陆陆续续收到了 20+ 不同岗位同事发来的安慰和贺电，要么是说和我在工作中的相处十分愉快（用了“和别人不一样”的字眼），要么是对我的专业技能进行了认可（用了“找不到像你这么好的产品”的字眼），这给我也搞的有点不知所措了。作为一个习惯于靠他人的认可来提升自我承认的内向人格，这确实是所剩不多的好事，那我就自认为这段工作经历的卷子上，我的答题结果还行了（或者厚脸皮一点，答题结果不错）。

大学毕业的时候，我们那些结下深厚友谊的同学们一边吃烤串一边说“聚是一团火散是满天星”，这次毕业的时候，我反而不再期许每个人都能成为夜空中最亮的那颗星星，用亮度评价星星可能并不是最好最公平的指标。那我就祝每个人都能成为最快乐或者最自洽的星星吧（哪怕是一颗快乐的或者自洽的彗星也行）。

👇 广而告之板块

欢迎 base 成都地区的小伙伴帮我内推产品岗位机会，线上简历见 https://hiwannz.cn/

如果遇到网络情况不好无法阅读，或者希望拿到 PDF 格式简历，欢迎与我联系。

“古蜀瑰宝—三星堆与金沙”文物特展从今年年初五开展，今天赶在撤展前一周去走了一下。展览展出来自三星堆博物馆、四川博物院、成都金沙遗址博物馆、成都博物馆、四川省文物考古研究院及成都文物考古研究院六家文物收藏单位的藏品163件（组），其中一级文物36件。之前看过几期相关纪录片，看实物还是第一次。感叹古人之精湛技艺，真怀疑外星人来过。

展览前言

中华文明，亘古及今，延绵不绝，五干年文明史先后发祥，如满天星斗，逐次凝聚，融汇出开放包容、创新创造的华夏瑰宝。位于中国西南、长江上游的四川盆地，是多元一体中华文明的起源地之一。从史载阙如到一醒惊天下，大量惊世发现让四川古代文明的璀璨画卷徐徐展开，更让世界对中华文明有了新的认知。
上世纪90年代以来，成都平原史前古城址群的发掘，再现了远古成都的文明曙光；三星堆和金沙遗址的腾空出世，大量气势磅礴且文化特征鲜明的珍贵文物震憾出土，揭示了古蜀王国曾经的辉煌；马家大墓、商业街船棺墓地等晚期蜀文化遗存则让传说中的开明王朝呈现在世人面前，更实证了古蜀融入中华文明的历史进程……一幕幕考古巨篇，串联起古蜀之地昔日的繁盛图景，更映照出中华文明的辉映互鉴、水乳交融，让古蜀文明成为中华历史长河中的一颗璀璨明珠。
泱泱华夏，历史绵延干载不息；锦绣天府，文明铸就千古华章。愿以此展览让大家共享四川古代文明之菁华，体悟中华文明数干载的积淀与传承！

三星堆遗址出土的青铜乌足神像通高约253厘米，是由1986年二号坑出士的铜鸟足人像、2021年三号坑出士的爬龙铜器盖、2022年八号坑出士的铜顶尊撑墨曲身人像、铜持龙立人像、铜杖形器等部分组合而成。整器为倒立的人身鸟足造型，双手按罍，头部顶尊。尊盖上有一立人，头戴高冠、双手握龙。这一罕见的青铜艺术杰作体现了中原商文化与古蜀地域文化的完美结合。

展览结语

中华文明是人类历史上唯—未曾中断的原生文明，具有强大的凝聚力、延续力和融合力，表现出多元一体、连绵不绝、兼容并蓄的文化特质。虽然古蜀国退出了历史舞台，但古蜀文明与中华各地区文明如百川汇流，相与为一，融合发展并延续至今。
万物有所生，而独知守其根。今天，我们在这里见证的不仅是古蜀人民杰出的创造力和非凡的想象力，也是中华文明融会创新的智慧结晶，更是人类文明对自然、宇宙、生命、艺术等共同主题的深刻探索与不懈追求。
铿锵有力的古蜀旋律悠悠回响，中华民族的精神根脉生生不息。

By 徕卡 D-LUX8

Browser Use 成为近期的明星项目，两个人的纯技术开源项目，核心代码 8000 行，融资 1700 万美元，让人好奇它具体做了什么，为什么这么值钱。

做了什么？

简单说 Browser Use 让大语言模型对网页的识别和操作的效率、准确度变高了，有利于 Agent 完成任务。

目前要让 AI Agent 完成任务，可以直接让 AI 浏览网页，像人一样去理解页面，执行操作，之前一般的做法主要靠截屏：

1. 其他产品（Anthropic 的 Computer use、OpenAI 的 Operator 等）操作 GUI，主要靠 VLM 识别截屏，再输出要操作的坐标位置，Agent 执行操作。
2. 在这过程中，web 的源码也可以加入上下文，让模型获得更多信息，但 web 源码内容太多，信息噪音太大，token 消耗也高。

而 Browser User 对 web 页面做了结构化处理，翻译成大模型友好的格式，再输入 LLM 识别。举例 Google 首页：

1.Browser use 会在页面上嵌入脚本，遍历 DOM 结构，找出页面上的元素，显式打上标记：

2. 转换为以下纯文本：

[Start of page]
[1]<a Gmail >Gmail/>
[2]<a 搜索图片 >图片/>
[3]<div />
[4]<a false;button;Google 应用/>
[5]<a 登录/>
[6]<img />
[7]<div />
[8]<textarea 搜索;false;q;combobox;Google 搜索/>
[9]<div />
[10]<div 按图搜索;button/>
[11]<input button;Google 搜索;btnK;submit/>
[12]<input btnI; 手气不错 ;submit/>
[13]<a English/>
[14]<a Bahasa Melayu/>
[15]<a தமிழ்/>
[16]<a 关于 Google/>
[17]<a 广告/>
[18]<a 商务/>
[19]<a Google 搜索的运作方式/>
[20]<a 隐私权/>
[21]<a 条款/>
[22]<div false;button/>
[23]<div 设置/>
[End of page]

内容格式极简，关键信息都有，提取了所有可交互元素，模型完全可以通过这些信息“看”和“操作”网页。

例如要执行搜索，模型很容易判断搜索框是索引为[8]的元素，Agent只需要把元素[8]对应的 XPath 拿出来，获取到页面上对应的元素，执行操作就可以。

所以 Browser Use 使用非多模态的模型例如 Deepseek 也可以跑起来，不依赖截图识别。但如果是多模态模型，截图也默认会一起输入模型，提升识别准确率。

Browser Use 核心就是做了这个点，剩下的就是怎样把流程串起来。

实现细节

核心代码包括四个部分：agent 负责决策和串流程，controller 负责转换决策为具体操作，dom 负责网页分析，browser 负责与实际浏览器交互。

1. agent：实现了个小型 AI Agent，负责串起流程，管理上下文信息，决策生成下一步指令，让 Browser Use 可以一步步完整执行一个任务（例如购买机票），这也让 Browser Use 变成易于集成为 Agent
   1. service.py 实现了典型的 Agent 的 ReAct 模式，推理 → 执行步骤 → 模型观察结果下一步。可单独配置 plan 模型。
   2. message_manager 管理消息历史，并做了一些类似敏感数据过滤、图片内容处理等。
   3. memory 实现记忆功能，基于mem0，但目前应该只实现了一半，只把每步存起来，没有调取使用。
2. controller：负责控制和执行浏览器操作的高级指令，是连接AI代理和浏览器操作的桥梁。
   1. registry/ 实现了 Action 的注册和管理能力
   2. service.py 定义和注册了所有可用的浏览器 Action，click/go_to_url/input_text等。
3. dom：对 web 页面的处理和分析，生成上述 AI 友好的文本结构。
   1. buildDomTree.js 是嵌入页面的 JS 脚本，遍历 dom 过滤出可交互元素，绘制高亮框等。
   2. service.py 操作 JS 注入、节点信息获取、跨域处理等能力，views.py 提供 DOM 节点在 python 的数据模型。
4. browser：对接 Playwright，在它上面封装了一些能力。
   1. context.py 管理浏览器上下文，以及一些细节功能处理，像标签页/导航管理、截图、定位和获取元素、URL白名单检测、文件下载处理等。
   2. browser.py 封装了浏览器实例的创建和配置。

它也用到了很多开源项目和服务：

1. Playwright：微软开发的 web 自动化测试框架，核心是提供了用代码命令操作浏览器的能力，这能力刚好是 AI Agent 需要的，Browser Use 只需要基于它做上层开发。如果只需要浏览器的能力，官方也有封装的 MCP 服务(github.com/microsoft/playwright-mcp)
2. LangChain：Agent 基于 LangChain 构造，主要用到模型调用和 message 管理。
3. Laminar：trace / 评估 AI 产品的服务，Laminar 对 LangChain / OpenAISDK 等框架做好了适配，加一行代码就可以对 Browser Use 整个 Session 调用链路调用过程进行追踪和评估。Laminar 跟 Browser User 一样也是 YC 初创公司，开源→服务的打法。跟另一个项目 openllmetry 类似，都是基于 OpenTelemetry 做 AI 的监控分析工具，这个赛道也很卷。
4. posthog：数据采集，让 Browser Use 的作者能更好知道项目被使用的情况，会收集一些使用数据上报到 posthog，Agent的执行过程都会上报，对数据敏感的可以关了。
5. mem0：专为 LLM 提供的记忆层服务，分级存储用户信息、RAG 召回、易用的 API。也是开源+服务的模式。
6. 浏览器服务：Browser Use 支持连接远程的 Browser 服务去执行任务（这也是 Playwright 支持的），官方文档里推荐的就有 browserbase.com、anchorbrowser.com、steel.dev、browserless.io 这几个服务。

其他就是一些配套实现了，gif 动图、多种模型调用的 example、test case 等。

为什么这么值钱

一个并不复杂的开源项目，得到市场这么大的认可，事后分析，可能是因为：

1. 是 Agent 的核心基础设施
   1. Agent 跟现实世界交互，最优方案是通过 API，而不是 GUI 界面，所以基于 MCP 统一协议封装 API 是当下一大热门。
   2. 但绝大多数服务没有 API，只有给人类提供的 GUI，现阶段要让 Agent 用处更广泛，还是得让它能理解、使用 GUI，而 Browser 是 GUI 的主要容器，在现阶段就是最核心的基础设施之一。
2. 有很高的上限
   1. Browser 足够复杂，需要持续迭代，优化识别率、上下文管理、新的评测机制、探索模型上限等，深耕能形成壁垒。
   2. Browser 一定有很强的云服务诉求，要各种上层 Agent 自己部署容器和 Browser 成本太高，商业化路径清晰。
3. 在这个领域做到了 SOTA
   1. 据 Browser Use 自己的评测，在 WebVoyager Benchmark 上获得业界最好的效果：
   2. 从近期声量、github 的活跃上看，稳居头部。

有需求，有商业化，有流量，在这个时间点让它很值钱。

想法

1. 长期看，模型直接理解截屏是更自然更能 scale up 的做法，所有信息截屏都有，大模型应该像人一样能准确识别和操作，模型公司应该会一直在这条路上尝试。
2. Browser Use 是在模型能力不足时期的中间优化方案，如果这个时期足够长，它就价值很大，如果模型很快突破，它就会失去价值。
3. 可以用同样的思路复刻 Mobile Use，iOS / Android 都有现成的 accessibility 能力，能拿到当前界面结构化的数据，只是会有沙盒的各种限制，这事很适合系统厂商去做。桌面端应该也可以。
4. Agent 上下游相关配套基建都处于起步阶段，小团队很有机会把其中某个点做出彩。

天气不太好，飘着毛毛雨，阴沉沉的。今天无法去爬山，索性到澳门走走，没有什么目的，纯粹的在大街小巷里面瞎逛。还是选择我最喜欢的湾仔口岸坐船过海。这里过关的人非常少，船票25元/人，准时开船，3分钟左右到达对岸。下船后就可以直接逛，走15分钟可以到葡京。可以“湾仔口岸”公众号买票，“掐点”到口岸。如果从拱北过关，弯弯绕绕，30分钟可能还在关闸，然后还得等车转公交。

下船后，穿过小巷子，可以看到墙上不少涂鸦。

不时还会路过一些小街道，“里”。“里”是指双向都开口，一些较长的巷道。

还有一些夹在古老建筑中间时尚的商场。

在澳门瞎逛，你还会遇到不少教堂，都很精致。可以专题走一次，会收获不少。

午饭时间，已经在澳门瞎逛了 15000 步，急需填补肚子。好不容易走到一家评分4.9的茶餐厅，结果没开门。正当我对着门口纳闷的时候，一位路过的澳门本地阿伯跟我说这家逢周日休息。周日游客最多的时候居然休息！！好心的阿伯给我指路，说本地人喜欢去一个“街市”（菜市场）吃饭。吃饭的地方在“街市”上面，有电梯，右转再左转，如果左转再右转怕我找不到，听得我云里雾里。

终于，我们在关帝古庙的边上找到了这个地方。

吃饭的地方就位于这栋“营地街市市政综合大楼”上面，实在看不出来。

上到3楼后，发现别有洞天，真的是本地人的食堂。香味扑鼻，价格实在，如果你想找地道的吃食，建议你来试试。

上午10点过澳门，下午2点半回，结束周末澳门 City Walk，一共走了21000步。

“街市”以上照片 By 理光 GR3
“街市”后的照片 By iPhone 12 Pro Max

参加了 NVidia GTC (GPU Technology Conference)，由于英伟达的地位，这会也已经成了 AI 开发者最大的交流会，很多公司和业内人士都会过来分享、交流，大概写下会议中相关见闻感受。

Keynote

老黄没提词器洋洋洒洒讲了两个多小时，出了小状况还会开个小玩笑，大佬范很足，也满满的理工男既视感，非常多的数字和未经包装的细节，不过感觉会讲得有些啰嗦。

总的来说，核心论证的是世界对 GPU 诉求会越来越大，而 NVidia 在 GPU 这个领域会持续遥遥领先。

GPU诉求

计算机的核心从 CPU 转向 GPU，上个时代依靠程序员写代码指挥 CPU 执行指令解决问题，构成了现在庞大的 IT 产业，程序员是中心。现在的时代逐渐转变，GPU 生产的 token 逐渐能解决越来越多的问题，能思考，能生成代码指挥 CPU 去执行解决问题，计算的核心一定会转向 GPU，世界对 GPU 的需求只会越来越高。

给 AI 分了四个阶段，Perception AI → Generative AI → Agentic AI → Physical AI，不是很认同，Agentic 和 Physical 都是 Generative AI 的延续，不过无所谓，可以看到 Agentic 这个概念实在是火爆。

Scaling Law 没有停止，Agentic AI 需要深度思考，深度思考有新的 Test-time Scaling Law，越多的 token 输出效果越好需，要多轮理解和工具调用对 token 的消耗更是指数级上涨。

Physical AI 要更好地理解现实世界，声音/视觉/触感，都会比纯文本思考对 token 消耗的诉求更高，像 2G 时代看文字新闻，3G 4G 图片，5G 视频一样。

这两个发展中的领域对 GPU 的需求只会越来越高，Deepseek 做的优化也不足以影响这个需求的增长，这个市场不容质疑。

NVidia 优势

GPU 需求量是高，但未来大家一定会买 NVidia 卡吗？当然。NVidia 这一代 blackwell 算力是 hopper 的 68 倍，下一代计划明年推出的 Rubin 算力是 hopper 的900 倍，一年一迭代，远比摩尔定律快的速度，还做了大量的大规模部署的优化，省电、稳定，号称买越多，省越多，赚越多，竞对看起来会很难追上。这些论述还是挺能让人 buyin 的。

Agentic AI

Agent 的相关 session 有接近 200 个，Agent 集合了几个元素：

1. 概念火，一些涉及 Workflow/RAG 什么的 AI 应用都统一称为 Agent 了，GenAI 在各行业的落地都可以冠以 Agent 的名义，跟以前 H5 那样，不纠结于具体定义，只要有一个统一称呼。
2. 人群广，Agent 目前主要是在上层的工程架构上，大量的工程师都能理解、参与讨论、建设，不像基础模型训练，多数人难以参与。
3. 应用广，非研发也能大概听得懂，涵盖了 AI 在各行业的应用这个课题，各行业都会有兴趣了解 Agent 是什么，自己业务上能怎么用。

所以 Agent 相关的 session 大部分都很热门。听完一些的感受：

1. 多数做企业服务、云的公司都在卷 Agent 的基建和解决方案，像基础设施公司 Fireworks AI、Nebius，数据库公司 Couchbase、datastax，企业服务公司 serviceNow、Dropbox，新兴公司 huggingface、langchain、langflow 等，都来分享推广在 Agent 这事上能提供的能力和服务。
2. Agent 相关的建设都在刚起步，基本都是在分享概念、工程问题的优化和应用方案，没看到有涉及模型训练去优化 Agent 效果上限的相关分享。Agent 的一些关键课题上一篇文章有提到，基本差不太多。
3. 也没有讨论 Agent 在工程和模型上的界限，后续端到端的模型进步，能吃掉多少 Agent 能做的事？这两天 4o 的图生成出来后，预计后面才会有更多的讨论。

NVidia AI 基础服务

NVidia 作为领头羊，是希望自己能覆盖 AI 全链路基础设施的，大力在 AI 的每一层都提供了相关框架、服务、能力，这次会议上也有非常多的分享和推广。

其中跟 AI 应用 / Agent 相关的几个基建：

1. BluePrint：应用蓝图。给了很多 AI 应用场景的 example 工作流（也称为 Agent），例如 PDF 转博客、数字人应用等，提供工作流架构、数据集、源码，可定制，供开发者快速参考和部署。
2. NIM（NVIDIA Inference Microservices**）**：模型推理。把模型推理封装在 Docker 容器里，可以直接快速部署，对外提供标准化API。也封装了模型在不同 GPU 型号下的优化，提升性能效率。
3. NeMo（Neural Modules）：模型训练。提供了相关工具用于构建、定制、训练 AI 模型，训练后的模型可以通过 NIM 部署。
4. AgentIQ：开源 Agent 开发套件，支持组合链接不同框架创建的 Agent，提供性能 profiler、评估、UI 界面等工具。

这些基建的声量比较低，国内没怎么见到，不确定海外使用情况怎样。

多个 session 都在推广 NVidia 的 Video Search and Summarization Agent，串联从视频的获取→分割→VLM识别、CV物体识别和跟踪→数据处理存储和RAG召回→用户对话 整个流程，做到可以对视频提供实时分析和报警，也可以自然语言交互查询视频内容，边缘部署，适合用于监控，算是用 NVidia 技术栈做 AI 应用的一个标杆范例。

AIGC

关注了下视频 AIGC 相关的几个 Session

1. 在好莱坞干了几十年的视觉效果的 Ed Ulbrich 开了个公司 Metaphysic，以前的电影特效制作成本巨大，对人的处理还很难跨过恐怖谷，而基于 AI 技术做特效，用完全不同的技术栈，效果好成本低，是一种颠覆。metaphysic 给娱乐行业提供人脸替换、数字人的服务，看起来是用的 GAN，在人物换脸技术上，GAN 还是更能做到稳定和实时，特别是实时这个点，基于 diffusion 很难做到。基于市场需求，利用已有的不同技术(甚至是上一代技术)深入解决问题，是有空间的。
2. PixVerse Co-Founder 在一次对话中聊到，视频实时生成的能力差不多要 ready 了，目前 5 秒的视频可以做到5-10秒推理完成，可能会解锁新的人跟视频的交互方式。不确定质量怎样，质量达到一个阈值，以前设想的很多类似 自定义剧情走向 的新玩法新交互有很大空间。
3. Adobe 和 OpenSora 都来分享了视频生成模型的训练和推理的方案和优化，鉴于已经不是SOTA模型，可参考性不高。TCL 分享了AI电影制作，很惊讶这公司竟然在做这个，更多的是在做链路串联，而不是端到端的视频模型。

其他

1. OpenAI 只来了两个人给 blackwell 架构站站台，Anthropic 一个人也没来，从这上看，这行业最领先的技术还是很 close，毕竟是核心竞争力，而且很容易被复刻，不像上个时代，大规模并发架构等技术，更重的是实践中解决具体问题，大方案分享了问题不大。（所以 DeepSeek 开源最领先的技术带来的冲击才会那么大。）
2. DeepSeek 就是 Reasoning Model 的代名词，开源模型的顶流，出镜率极高，老黄的 keynote、各种演讲里都有它的身影，而 llama 通常是作为上一代开源模型与它做对比，只要是提供开源模型部署服务的公司（HuggingFace/Fireworks等），分享里都会对 DeepSeek 极度推崇。
3. 遇到不少学生来参加，有的来找方向，看看业界前沿在做什么，做学术交流，找合作机会，这个会是挺合适的。清华、中科大、SJSU。最大的问题是实验室没有足够的卡，这领域是必须校企合作，实验室才进行得下去了。
4. 使用 Nvidia Jetson 做边缘计算也是预期后续空间比较大的方向，设备端部署模型，可以提升实时性和隐私性，多数分享是用在具身智能上，还有一个分享的场景是在货架上实时分析用户行为，更精准推送广告。
5. 机器人、自动驾驶的 session 也很多，数字孪生是提得比较多的（用 AI 生成仿真环境，用于机器人训练），但现场没看到什么能震惊人的机器人，包括老黄演讲时演示的类 wall-e 机器人，惊艳不够，这一行感觉还早。

总体感受，眼花缭乱，人潮纷杂，在开拓视野以外，大会更多是一个社交场所，推广产品/技术/服务，促进合作，这类大会需要的是多创造一些面对面交流的机会。

花絮

1. 现场有限量的原价 5080、5090，知道时已经不可能排队买到。
2. 跟七年前参加 WWDC 在同一个地方，估计一直还是同一个承办公司，午餐还是那么难吃。
3. 参观 NVidia 工区，老黄作为华裔也是信风水的，新办公楼会模拟依山傍水的设计，风水好。NVidia 搞渲染出身，渲染里三角形是最基本单元，所以办公楼都是三角形元素。办公环境很宽敞，但没啥人，总部居家办公没有限制，很多都不来公司。

参加 NVIDIA GTC 会，其中一场听了 LangChain 的作者 Harrison Chase的分享《AI Agents in Production Insights and Future Direct》，聊了 Agent 当前遇到的一些问题和他的想法，包括 Planing，UX，Memory，Reliability，Deployment，Multi-Agent，也结合我的理解说说这几个课题。

Planing

任务规划是 Agent 的核心，这个课题是进展比较多的，业界解决得相对比较好，核心是 o1/r1 推理模型的出现和不断增强，让规划能力上了一个台阶，这也是 agent 能起来的基础。

但模型本身目前解决不了所有问题，还需要工程上的一些策略和串联做优化。例如 Tree of Thought 让任务不是以线性一步步执行的形式，而是生成解决问题的多个节点，多角度思考问题，形成树结构的任务，评估节点的价值，在里面寻找最优解。 Reflexion 会有 Evaluator 对各种反馈（工具调用结果/模型输出/用户指令）进行反思，梳理改进方向，也会把反思结果作为知识库经验，指导后续的任务。

这些策略链路是需要有一个工程流程把他们串起来的，这个工程链路的构建也是 Agent 在 Planing 能不能做好的关键因素，langgraph 和众多 Agent 框架服务都持续在做这个事。

UX

Agent 的交互应该是怎样的？

Devin 多窗口，有聊天框发送指令、又能实时看到 Agent 在怎样用浏览器、命令行、编辑器，是不错的交互。

大部分 Agent 会是后台异步运行的模式，可以让它直接跑在后台，在需要人类给出反馈处理的，用类似邮件 inbox 的方式交互，Agent 发邮件给你等待指示，你回复邮件给输入。

相较于交互界面形态，交互的策略可能更关键。Agent 在执行任务过程中，

1. 用户是否应该能随时中断并提出新的指示？
2. Agent 应该在什么时候暂停任务等待用户反馈再进行下一步？
3. 用户指示应该用表单一次性收集，还是一步步收集？

如果做每一步都要用户反馈做指示，那是非常枯燥不好用的，如果完全不需要用户反馈，那做出来的东西可能不符合用户预期的概率高很多。模型应该能做好这里的交互策略，但目前还没看到有特别好的实践。

Memory

长时记忆是个有意思的话题，杨立昆在对话中也有提到，记忆这个课题是值得研究的方向，现在是缺乏突破和讨论的。

现在的 Agent，普遍都只有知识库 RAG 而没有记忆，记忆不是知识库，或者说知识库只是记忆的一种。

记忆应该跟人类一样，模型能记住和学习交互过程中用户给到的信息和偏好，在每次推理过程中发挥作用。

它跟 UX 相关，如果模型能理解记住用户偏好，用户的反馈交互就可以减少。

它也跟 System Prompt 的优化相关，System Prompt 是激活了模型按某个方向去做推理预测，记忆也应该是在模型推理的过程中发挥作用。

简单做的话记忆可以作为 System Prompt 的一部分去影响模型，更彻底的可能应该是能持续内化到模型内，或者以新的模型架构去做这事。

现在的应用场景还没到记忆是必选项的程度，但要做 AGI 或者要 Agent 好用这块必不可少。

Reliability

主要是指 Agent 能不能稳定地解决同一个(或同一类)问题。

Agent 跟之前的软件工程不同，受限于模型输出的不稳定，整个系统的可靠性是远不如传统工程的，用户输入同样的或差不多的需求，agent 不一定每次都能解决问题。

模型输出的，一是会受用户对任务描述的影响，可能描述不准确，可能会有歧义。二是受模型本身不够聪明的影响，近期模型能力越来越好，解决了部分问题，但仍是不稳定。

保持 Agent 输出的稳定性，是一个非常需要持续迭代优化的工程，搭一个 demo 容易，持续优化难。

Agent 节点多，需要能看清每个任务节点的详细情况，有问题时知道问题出在哪里，需要有效果评估的测试能力，也需要框架有能力比较方便地在过程中对模型的输出进行评估实时纠错，提升稳定性，这些配套 langchain 相关生态都提供了，NVidia 这次开源的 AgentIQ 框架也基本涵盖了，还有很多框架服务也在做。

Deployment

Agent 要在线上跑，相关部署基建现在也还没有很完善，它跟传统工程链路还是有一些区别，主要是链路长、耗时长、成本高。提供 Agent 部署的服务应该针对这几个特性做好相关基础设施。

1. 稳定性：整个 agent 链路很长，每一个环节调用如果成功率是 99%，平均要调用十次接口的 agent 成功率就只有90%，而大模型的接口往往也不稳定，如何保证成功率？ 重试策略、排队机制等，这些都是 agent 工程基建应该做的事。
2. 性能：当前 agent 处于效果大于耗时的阶段，只要效果好，五分钟输出还是十分钟输出都可以接受，但真正规模化应用起来时，性能问题肯定也是重点，整个链路耗时太长，可优化空间会比较大，NVidia 对 agent 的分享也提到了，很多任务不一定要串行做，可以并行化节省整体耗时。
3. 监控： Agent 线上跑的效果怎样，准确率多高，有没有安全风险，应该有直接可用的相应配套。
4. 成本：如果 Agent 全程用最好的模型，跑一次十几分钟的任务可能要几美元的成本，前期问题不大，效果优先，粗放式探索，后续真能规模化上线应用，成本这里的优化空间会比较大，用不同的专家小模型处理不同的任务、做好模型 – GPU 卡适配优化推理（NVidia NIM 提供了相关能力），都是可优化的方向。

Multi-Agent

预期后续会有非常多的 Agent 出现，Agent 跟 Agent 之间如果能相互联系，能形成新的智能体，但 Agent 之间 应该怎样通信？

这里的通信不止是把 Agent 当成一个黑盒，给指令 – 输出结果，而是能深入 Agent 内部的通信，上下文共享、中间步骤共享、过程中的协作、用户操作插入等。

目前没有一个标准，各项目都是自己的一套，业界可能需要这样一个标准，能实现把使用不同框架、不同服务上部署的 agent 连接起来。

MCP 是近期在快速发展的标准协议，很有前景，但它只是把工具工具调用标准化了，对 Agent 和 Agent 相关的协作是没有定义的，可能需要另外的协议。

上一篇文章刚好探讨了这个内容，用 Agent as Tool 的方式，把 Agent 当成工具的一种，基于 MCP 去做，好处是架构简单，Agent 可复用性高。

但它只把 Agent 当成黑盒 Tool 去使用，给指令 → 输出结果，Agent 之间更深入的联系是没有的。我们也在尝试，给这个 MCP 子 Agent 输入主 Agent 的上下文，同时这个子 Agent 也可以流式把每步处理过程上下文输出给主 Agent，这样就可以实现 Agent 之间的上下文共享。同时也可以继续做更深入的交互定义，比如子 Agent 与用户反馈交互的流程协议。

目前这些协议都需要自定义，但以 MCP 、 以 Agent as Tool 去定义标准的 Agent 间交互协议，也是可行的，MCP 可以把这套交互协议也定了，可能是 Anthoropic 很好的机会。

---

上述这些基本是工程上的事情，这次 GTC 很少有人讨论到 Agent 在数据收集/模型调优上的实践，基本是直接使用基础通用模型，但要提升 Agent 的上限，应该是需要专有模型并能支持端到端训练的形态，待探索。

这是一篇来自近期工作发呆时的思考（说做是总结和记录可能更为恰当）。

从2024年的中下旬开始，公司就一直和我们铺垫说有一个客户在项目交付中出现了一些问题，由于项目合同的金额较大，客户在内部沟通的过程中要求我们将一部分项目的回款使用线下交付的方式进行验收，说白了就是有一部分同事需要到客户现场去驻场。于是我们就在年后冲向北京，这篇文章也是我在工作业余时的胡思乱想。

熟悉我的朋友应该都知道，我在工作中时不时要参与到一些诸如客户支持，定价沟通，产品价值talking 的环节中，可能是这两年大家都把 AI 作为了“年度话题”的重要性，所以总会有一些客户想要进一步了解“产品如何在实际的业务流中快速集成 AI 的能力”，市面上也有各种各样吹嘘“自己的产品又一次集成了 AI”的 PR 文章，但本质上其实大都是在云市场集成 AI 之后快速实现了一个 chatbot，好像效果并没有那么好。

当然也有一些客户会来问一些在不同视角的问题，我听过的问题印象比较深的就是“产品集成了 AI 能力我是认可的，但是这个产品中我看不到 Deepseek 的露出，你们怎么处理”，“在产品中集成 LLM 其实各家都大差不差，但是差异性的效果我暂时还没有看到”，此外在一些类似的产品中我发现 C2C（Copy to china） 的思路目前可能还是奏效的，去 ProductHunt 或者类似的网站看看国外的“同行们”又搞出来了哪些 AI 相关的应用，然后看看哪一个最适合集成到自己的项目中，砍掉一些复杂功能再做一些本地化，好像给自己的产品也就搭上了 AI 这趟快车。

有一些产品会说到自己在业务中使用 MCP（Model Context Protocol）和 RAG（Retrieval-Augmented Generation）来提供更加全面的大模型能力支持，从逻辑上来说在产品代码中能够真的提升效率和准确度，基于一些比如 Dify 或者 FastGPT 的产品做二次开发好像也能做到进一步的实践与尝试（没错，我们的产品也提供了这样的能力），但从最终愿意买单并且用于真实企业内部业务流程的状态来看，我觉得大家更多是想摸着石头过河再观望看看有哪些商业化的思路。

昨天和同事聊天的时候说到不同行业中的门槛其实还比较高，可能互联网行业的从业者大都掌握了无痛访问 Google 或者 Github 等网站的方式，但其实还有非常多的老百姓不太分得清其中的区别（事实上互联网从业者也不见得都掌握了这个能力），对于老百姓来说耳熟能详的张一鸣和王兴兴是那种“在某一个行业中实现了成功的例子”，但是对他们到底在做什么其实并不清楚，其实说到 AI，说到人工智能，这应该是一个伴随计算机有 N 多年历史的故事了。

但是 AI 到底是咋来的？好像前些年我们对 AI 的理解和认知还停留在 TensorFlow 和 Pytorch 这样的算法中，怎么一眨眼 AI 就已经飞入寻常百姓家了？

既然聊到了这里，我就来试试讲讲 AI 发展的一系列关键人物（万一说错，还请拍砖）。

图灵，计算机能否像人一样思考？

1940 年，二战如火如荼，德国的“恩尼格玛（Enigma）”密码机几乎让所有盟军的情报系统陷入瘫痪。英军情报部门召集了一群数学家，他们的任务是——破解 Enigma，让德国的情报不再是个谜。

这群数学家中，有一个瘦高、害羞但聪明绝顶的年轻人，他叫艾伦·图灵。

他不是普通的数学家，他构想了一种“通用计算机”——一种可以执行任何计算任务的机器，并用它来破解 Enigma。他发明了“炸弹机（Bombe）”，最终成功解码了德军密码，让二战提前结束了两年。

然而，他并不满足于此。他问了一个更大的问题：

“如果机器能够进行计算，是否意味着它也能思考？”

他提出了著名的“图灵测试”——如果一个人无法区分是在与人还是与机器对话，那么机器就具备了“智能”。这个想法为现代人工智能奠定了基础。

大多数人最快捷大概了解图灵的方式就是那一部由本尼迪克特·康伯巴奇主演的“模仿游戏”，在二战期间图灵在英国政府的雇佣下破解了德军的“恩尼格码”密码机，由此也奠定了现代计算机科学的基础。在他 16 岁的时候就开始阅读爱因斯坦的相关著作，在他 19 岁的时候就考入了剑桥大学开始攻读数学本科，并且在22 岁时候以优异的成绩毕业。

虽然图灵是一名数学家，在学习数理逻辑学（就是我们学的那个“与”，“非”，“或”等等的学科）的时候又开始对逻辑学，哲学进行了更加深入的研究。但虽然图灵奠定了人工智能的哲学基础，也提出了计算理论与 AI 的测试标准，但由于同性恋的原因受到迫害，在 41 岁的时候英年早逝。

冯诺依曼，计算机如何高效存储和计算？

如果说图灵是计算机科学的哲学家，那么冯·诺依曼（John von Neumann）就是计算机的工程师。

在 1945 年，他提出了一种全新的计算机架构：把数据和程序存储在同一个内存里，让计算机可以自动执行指令。这就是后来所有计算机都遵循的“冯·诺依曼架构”，它让计算机变得真正实用。

除了计算机，他还发明了博弈论，并且是最早研究人工智能如何决策的人之一。

我相信每一个计算机相关专业的同学应该都听过冯诺依曼，比如在计算机原理的课程上肯定会学到他提出的冯诺依曼架构。此外他也提出了能让程序指令和数据能够存储在同一个存储器中的存储程序概念，从而让计算机可以自动执行程序。

值得一提的是冯·诺伊曼从小就以过人的智力与记忆力而闻名。他在一生中发表了大约150篇论文，其中有60篇纯数学论文，20篇物理学以及60篇应用数学论文。他最后的作品是一个在医院未完成的手稿，后来以书名《计算机与人脑》（The Computer and the Brain）发布，表现了他生命最后时光的兴趣方向（但其实冯诺依曼不仅在计算机方向有建树，他也是博弈论之父）。

罗森布拉特，能否让计算机自己学习？

1958 年，弗兰克·罗森布拉特提出了一个让整个 AI 领域兴奋的想法——“感知机（Perceptron）”，它是一种最简单的神经网络，可以通过调整权重来学习模式，比如识别简单的形状。“创造具有人类特质的机器，一直是科幻小说里一个令人着迷的领域。但我们即将在现实中见证这种机器的诞生，这种机器不依赖人类的训练和控制，就能感知、识别和辨认出周边环境。”

然而，1969 年，闵斯基（Marvin Minsky）和派普特（Seymour Papert） 在《感知机（Perceptrons）》一书中证明，感知机无法解决像“异或”这样的基本问题，这让整个 AI 研究陷入了“AI 冬天”，神经网络被主流科学界抛弃。这本书抨击了罗森布拉特的工作，并本质上终结了感知机的命运。

罗森布拉特没能渡过AI的寒冬。1971年，他在43岁生日那天，在切萨皮克湾（Chesapeake Bay）乘单桅帆船出海时溺水身亡。

理论上来说，感知机其实是第一个尝试让机器“学习”的模型，但它的失败让神经网络沉寂了 20 年，直到 x辛顿重新挖掘它。

闵斯基与佩帕特，感知机的局限性是什么？

1956 年，达特茅斯会议 上，一群科学家聚在一起，试图定义“人工智能” 这个领域。其中，闵斯基作为 MIT 人工智能实验室的创建者，是符号主义 AI 的坚定支持者。

他的梦想很宏大：“AI 应该像人一样思考，我们只要给它足够的逻辑规则，它就能成为真正的智能。” 他的研究主要基于符号逻辑，比如他开发了一种叫做 Lisp 机器 的计算机，专门用来运行 AI 代码。

与此同时，佩珀特则更加关注机器学习和儿童教育，他认为计算机应该像孩子一样学习，而不是依赖固有规则。他发明了一种编程语言——Logo，可以让孩子通过简单的指令控制“小乌龟”在屏幕上画图形。他们二位的 AI 研究，让 AI 在 1960 年代成为了学术界的明星，政府和企业纷纷投资，AI 似乎要迎来一个黄金时代！

但好景不长，感知机（Perceptron） 的失败让闵斯基和佩珀特觉得，神经网络完全没戏。他们在 1969 年合著了一本书——《Perceptrons》，直接指出了感知机的致命缺陷“感知机无法解决“异或（XOR）”问题——也就是说，它没办法学会“如果 A 和 B 相同，输出 0，否则输出 1” 这样的简单逻辑。”

他们的批评毁灭性地打击了神经网络研究，导致 1970 年代 AI 研究资金骤减，进入了第一次“AI 冬天”。

杰弗里辛顿，如何训练深度神经网络？

1970 年代，神经网络研究遭遇寒冬。当时的主流 AI 研究者（如闵斯基和佩珀特）认为神经网络太简单，无法解决复杂问题。许多科学家纷纷放弃，但辛顿偏偏选择了这条“错误的道路”。

辛顿出生于英国，外祖父是著名数学家 George Boole（布尔代数的创始人），他从小就喜欢挑战权威。在攻读博士期间，他研究反向传播算法（Backpropagation），一种可以让神经网络自动调整权重的方法。尽管这个算法早已在 1970 年被提出，但几乎没人相信它真的能让 AI 学习。Hinton 和他的团队坚持优化反向传播，并在 1986 年成功证明它可以让多层神经网络高效学习复杂任务。

90 年代，辛顿继续探索更深层的神经网络，并提出受限玻尔兹曼机（RBM） 和 深度信念网络（DBN），成为“深度学习”（Deep Learning）概念的奠基人之一。到了 2012 年，他的学生 Alex Krizhevsky 使用卷积神经网络（CNN） 赢得 ImageNet 竞赛，标志着深度学习时代的正式到来。

后来，辛顿还提出了 Transformer 的早期雏形——胶囊网络（Capsule Network），并成为 Google Brain 的重要研究员，推动 AI 革命。他的坚持让神经网络从 20 世纪的冷门理论，变成了今天席卷全球的 AI 基石。

1980 年代，辛顿和他的团队证明了一个重要理论——“反向传播（Backpropagation）”，可以让神经网络通过调整权重进行学习。但当时的计算机性能不够强大，神经网络仍然没能流行起来。

时间来到 2012 年，Hinton 的学生 Alex Krizhevsky 训练了一种深度卷积神经网络（AlexNet），在 ImageNet 竞赛上击败了所有传统算法。这标志着深度学习的崛起，AI 从此进入了一个全新的时代！

杨立昆，计算机如何识别图像？

在 20 世纪 80 年代，计算机视觉仍然是个难题。杨立昆认为，人工智能不应依赖手工设计的规则，而应该“像人一样”通过学习数据自动提取特征。他结合反向传播算法和神经网络，发明了卷积神经网络（CNN），让计算机能自动识别图像中的模式。

90 年代，他的 CNN 被用于手写数字识别，并成为美国银行支票识别系统的一部分。但深度学习当时还不够流行，他的研究一度被冷落。直到 2010 年后，计算能力的提升让 CNN 迎来爆发，成为计算机视觉的核心技术，被广泛应用于人脸识别、自动驾驶和医疗影像分析。

如今，杨立昆继续推动 AI 向自监督学习发展，试图让 AI 更接近人类的大脑学习方式，而不仅仅依赖海量数据进行训练。

杨立昆的原来中文译名为：扬·勒丘恩，2017年他在中国的演讲提供了正式的中文姓名。他法文的姓是（Le Cun），到美国之后，很多人都误认为Le是中间名，所以他在20世纪八九十年代把自己的姓的拼法改成了LeCun。

本希奥，AI需要遵循伦理吗？

本希奥与辛顿和杨立昆并称为“深度学习三巨头”。他是神经网络研究的先驱之一，推动了深度学习的数学基础，并对无监督学习、序列建模、注意力机制（Transformer 的前身）等领域作出了重大贡献。

Bengio 1964 年出生于法国的一个知识分子家庭，后来随家人移民到加拿大。他在蒙特利尔大学攻读计算机科学博士学位，师从 AI 研究者 René D. Mori，并开始专注于神经网络的学习方法。当时，神经网络在学术界并不被看好，但本希奥坚信它们能够超越传统的统计机器学习方法。

在 2000 年代，本希奥率先研究如何让神经网络自动学习数据的抽象特征，并提出了逐层训练（layer-wise pretraining）的方法，使得更深层的网络能够高效训练。这为后来的卷积神经网络（CNN）和递归神经网络（RNN）奠定了数学基础。他的研究极大地推动了深度学习的复兴，影响了 ImageNet 竞赛的突破（2012），并为后来的 Transformer 架构铺平了道路。

2014 年，本希奥的团队提出了注意力机制（Attention Mechanism），这是一种让神经网络自动关注最重要信息的技术。这项技术很快被 Google 研究员 Vaswani 等人发展为 Transformer 架构，并成为GPT-4、BERT、Claude 以及几乎所有现代 LLM 的基础。

可以说，本希奥间接塑造了现代大模型，他的研究影响了 AI 在自然语言处理、计算机视觉等领域的所有突破性进展。

与辛顿和杨立昆不同，本希奥在 AI 伦理和社会责任方面表现得更加谨慎。当 ChatGPT 这样的 LLM 开始爆发时，他曾公开警告AI 可能会对社会产生巨大影响，呼吁制定更严格的 AI 监管和伦理框架。

2018 年，他与辛顿、杨立昆共同获得了图灵奖（计算机领域的最高荣誉），正式确立了他在 AI 领域的历史地位。

尽管他是深度学习最重要的奠基人之一，但他并没有像 OpenAI 或 DeepMind 那样主导商业化 AI 公司的发展。他的研究主要在学术界，而他的许多学生（如 Transformer 论文作者 Vaswani）却推动了 AI 工业化的浪潮。

瓦普尼克，如何找到最优分类方式？

在 20 世纪 60 年代的苏联，数学家瓦普尼克和他的导师 Alexey Chervonenkis 共同研究如何让机器像人一样学习。他们意识到，AI 不能只死记硬背训练数据，而应该学会“泛化”——即用有限的经验推断新的知识。这促使他们提出统计学习理论（Statistical Learning Theory, SLT），并发明了支持向量机（SVM）。

SVM 的核心思想是找到数据之间的最优分界线，使得新数据也能被正确分类。这个方法在 90 年代被西方计算机科学界发现，并迅速成为机器学习的主流算法之一，在文字识别、生物信息学、金融分析等领域大放异彩。

尽管 SVM 一度是机器学习的黄金标准，但瓦普尼克对深度学习持保留态度，认为它依赖海量数据而缺乏理论上的优雅。他的理论为现代 AI 奠定了数学基础，使机器学习不再是经验主义，而成为一门严谨的科学。

瓦普尼克是一位纯数学派的科学家，支持向量机（SVM）在 1990s 成为了机器学习领域的标准方法。在深度学习出现之前，SVM 在很多任务上都被认为是最强的学习算法之一。

霍普菲尔德，神经网络如何进行联想记忆？

在 20 世纪 80 年代的人工智能研究领域，神经网络几乎被主流学术界遗忘。许多研究者转向了符号主义 AI（Symbolic AI）或专家系统（Expert Systems），但霍普菲尔德这个本职是物理学家的科学家却意外地为神经网络带来了一次重要的复兴。

霍普菲尔德早年是一位研究凝聚态物理的学者，他的兴趣集中在复杂系统如何自组织。在 1982 年，他提出了一种全新的能量模型，即霍普菲尔德神经网络，这是一种受物理学自洽场理论启发的神经网络模型。他证明了这个网络可以用来进行联想记忆（Associative Memory），即只需要输入部分信息，网络就能恢复出完整的模式。这种方法不同于传统的符号 AI，而是模拟了大脑神经元的工作方式。

霍普菲尔德神经网络的提出激发了 AI 研究者对神经网络的兴趣，为 1980 年代后期的神经网络复兴铺平了道路。辛顿和杨立昆等后来的 AI 研究者也深受他的影响。

尽管霍普菲尔德主要贡献在物理学领域，他的跨界工作却成为神经网络历史上的关键节点，让 AI 研究重新回到了仿生学的道路上。

霍普菲尔德神经网络在数学上证明了这个网络一定能够收敛，从而对基于神经网络的人工智能产生了奠基性的影响，开启了连接主义深度学习的大门。

施密德胡伯，如何让神经网络记住长期信息？

施密德胡伯是深度学习领域最重要的奠基者之一，他的研究直接影响了现代 AI，尤其是在自然语言处理和序列数据建模中的应用。他最著名的贡献之一就是LSTM（长短时记忆网络），这项技术后来成为谷歌、苹果、OpenAI 以及众多企业训练神经网络的核心方法。

施密德胡伯生于 1963 年，从小就展现出极高的数学天赋。他在瑞士学习计算机科学和人工智能，很早就对人工智能的终极目标产生了浓厚兴趣——创造一个能够自主学习、不断进化的人工智能。

在 20 世纪 90 年代，神经网络在处理长序列数据（如文本、语音和时间序列数据）时遇到了“梯度消失”问题：传统的循环神经网络（RNN）无法记住过长时间跨度的信息。

1997 年，施密德胡伯和他的学生 Sepp Hochreiter 共同发明了长短时记忆网络（Long Short-Term Memory，LSTM），这种架构通过引入“门控机制”来有效存储和传递信息，解决了梯度消失的问题。这项发明在当时并没有被广泛认可，但在 2010 年代，随着计算能力的提升和大规模数据训练的普及，LSTM 迅速成为语音识别、机器翻译、文本生成等领域的主流技术。

施密德胡伯的野心远远不止于 LSTM，他一直强调创造真正的通用人工智能（AGI）。他认为 AI 研究应该专注于元学习（meta-learning），即让 AI 学会如何自主学习，并不断优化自身。

他提出了“人工科学家”（Artificial Scientist）这一概念，认为 AI 未来应该能够自主提出假设、设计实验，并发现新的知识，就像真正的科学家一样。

尽管施密德胡伯的贡献不可否认，他的知名度远远低于辛顿、杨立昆和本希奥，部分原因是 LSTM 的商业应用直到 2010 年代才开始爆发。此外，他曾多次公开表达对 DeepMind 和 OpenAI 的不满，认为这些机构“没有给予他的研究足够的认可”。

尽管如此，施密德胡伯仍然是现代 AI 领域不可忽视的奠基者。今天的 GPT-4、Suno 音乐 AI、DeepMind 的 AlphaFold 等许多应用都间接或直接受益于他的研究，他的 LSTM 仍然在许多 AI 系统中发挥作用。

在 AI 发展的历史中，施密德胡伯是一个极具远见的人，他不仅改变了深度学习的技术基础，也为未来的 AGI 研究提供了重要的方向。

古德费洛，AI 能否创造新内容？

古德费洛 1985 年出生于美国怀俄明州，他从小展现出非凡的数学和编程才能。大学时期，他就读于斯坦福大学，主修计算机科学。随后，他进入加拿大蒙特利尔大学，师从深度学习三巨头之一的本希奥，正式踏入神经网络研究领域。

在本希奥的实验室里，他接触到了深度学习和生成模型，并开始探索如何让 AI 生成逼真的图像。这一探索最终促成了GAN（生成对抗网络）的诞生。

2014 年，古德费洛在博士研究期间的一次讨论中，和同事争论如何让神经网络自主生成更真实的图像。当时的 AI 生成模型（如变分自编码器 VAE）仍然很难生成高清且自然的图片。

突然，他灵光一闪，想出了一个革命性的概念：让两个神经网络互相竞争！他的想法是：一个 AI（生成器，Generator） 负责生成假图像。另一个 AI（判别器，Discriminator） 负责判断这些图像是真实的还是伪造的。二者不断博弈，最终生成器能骗过判别器，生成高度逼真的图像！

这种“对抗学习”的方式，突破了传统 AI 生成方法的局限，被命名为 GAN（Generative Adversarial Network）。

GAN 让 AI 从“分析数据”变成了“创造数据”，彻底改变了 AI 在艺术、设计、游戏、影视等行业的应用方式。可以说，他的研究让 AI 从理解世界进化到了创造世界，并成为 AI 生成内容（AIGC）浪潮的奠基者之一。

古德费洛不仅是GAN 之父，也是AI 伦理的重要倡导者，他的贡献将长期影响 AI 发展方向。

达里奥，AI 能否像人类一样写作和推理？

达里奥是 AI 研究领域的重要人物之一，曾在 OpenAI 领导多个关键项目，后创办 Anthropic，专注于 AI 安全与“AI 对齐”研究。他的工作推动了 AI 模型能力的飞跃，同时也让 AI 伦理问题进入公众视野。

达里奥最初是一名神经科学家，研究大脑与神经网络的相似性。他后来转向机器学习，加入 OpenAI，成为 AI 研究的核心人物之一。他在 OpenAI 期间的关键贡献包括：GPT-2 与 GPT-3 研究负责人：推动了现代大语言模型（LLM）的发展。AI 对齐研究的先驱：他提出 AI 需要“对齐人类价值观”，否则可能失控。

2021 年，达里奥离开 OpenAI，与几位前同事共同创立 Anthropic，专注于 AI 安全和“可控 AI”研究。Anthropic 的核心产品 Claude 系列（类似 ChatGPT）强调安全性，避免 AI 生成危险内容。他的研究强调：“AI 必须对人类有益，否则超级智能可能带来无法预测的后果。”

Anthropic 目前是 OpenAI 的主要竞争对手之一，并获得了 Google 近 30 亿美元的投资。

当然，说到达里奥我们其实也需要提到 Tom B Brown 和 Alec Radford，他们一行三个人的研究共同塑造了现代 AI 发展路径。但我想他们从 OpenA I跳槽到 Anthropic 也许还是遇到了那个难以抉择的问题“是追求更强大的 AI，还是追求更安全的 AI”？

算是本文的尾巴

写到这里其实我有点累了，事实上人工智能发展过程中总不是一帆风顺的，有兴趣的朋友可以看看维基百科上的“人工智能史”，我相信一定会觉得收获满满，在这些厉害的科学家中也会存在各种奇怪的冲突（也正常，大家毕竟都是人嘛）。

但如果我们回到 2025 年的当下，会发现 AI 的发展已经度过了“通用智能”的探索阶段，下一步可能还是要对准通用人工智能的方向进行进一步的细化和延伸。由于各类基于 Claude 3.7 的产品我们已经基本跳过了“AI 行不行”的疑惑，但到底“如何让他更安全，更有效”还是一个短期内我们看不到答案的问题。

前一段时间木遥的解读“vibe coding”在朋友圈和各种渠道刷屏，文章中那句“一方面它犹如神助，让你有一种第一次挥舞魔杖的幻觉。另一方面它写了新的忘了旧的，不断重构又原地打转，好像永远在解决问题但永远创造出更多新的问题，并且面对 bug 采取一种振振有词地姿态对你 gaslighting。你面对着层出不穷的工具甚至不知道自己该认真考虑哪个，心知肚明可能下个月就又有了新的「最佳实践」，养成任何肌肉记忆都是一种浪费，而所谓新的最佳实践只不过是用更快的速度产出更隐蔽的 bug 而已。”可能也是许多正在与 AI 结对编程朋友的真实感觉。

但我想，AI 带来的改变确实日新月异，我能看到身边的朋友能够逐渐完成“不相信 AI → 怀疑 AI → 全部用 AI → 不敢信任 AI → 再一次信任 AI”的无限循环之中。我在一些业余时间也尝试练手用 AI 帮我写了几个产品，相比原先的产品设计与研发过程中，会发现现在的 AI 可能每一次都会比前一段时间的使用更加流畅一些，但依然无法完全避免上下文遇到限制导致记忆力幻觉或者相关的问题，这种感觉好像就像是一种慢性毒药，一方面更爽了，另一方面又不是那么爽。在产品设计过程中各种刷屏的什么“用 AI 搞定原型图，搞定高保真效果图”的论据其实也能变相让我们感知到 AI 在具体业务中的应用其实还处在比较早期的阶段。

一方面我受益于使用 AI 能够极大程度加快我把脑海中的某些想法付诸于实践的过程，但另一方面好像也能明显感知到过拟合带来的某种不适感，在开启新项目的时候确实能够通过 AI 极大程度加快效率，但是否会因为过度信任 AI 而导致代码中潜藏了许多暂时没有精力与时间发现的 bug，又变成代码中一个潜藏的问题真的很难一两句话讲清楚。

如果对比我前端时间那篇《AI 取代人工进展走到哪一步了？》，当下的我结论还是那句“保持对前沿技术学习与了解，让自己不要落伍的概念是没问题的，用 AI 来输出一下自己无处安放的创造力或者做一些创新与变化的真实落地是很好的”，但 AI 改变世界的进度条到哪一步了？

我觉得还得再看看。

近期在业务中尝试落地 Agent，有一个架构设计问题，应该用单 Agent 架构，还是多 Agent 架构？

Single Agent

先来看看单 Agent 架构，在之前的文章里，OpenHands 这里的架构是典型的单 Agent 架构，依赖一个模型，组织多个工具调用，做好 ReAct 和上下文管理，整个过程很简单。

1. Tools 是一个个函数，定义和调用都是在当前程序里进行。Tools的函数定义会作为 System Prompt 的一部分让 LLM 理解当前可用工具
2. Memory 分两部分：
   1. 当前 Session 数据流，包括每一步执行了什么，结果是什么，在当前 Session 内存中保存，随时全量输入 LLM，让 LLM 判断下一步应该做什么。
   2. 用户的长期数据、知识库，例如用户在平台的偏好数据、领域内容、多轮对话上下文等，这些内容会从向量数据库召回。
3. Router 中心化程序调度整个过程，拿用户 Prompt / System Prompt / Memory 输入 LLM，LLM 进行深度思考和给出具体执行的任务，Router 去调用对应的 Action 函数。

这是简单通用的单 Agent 架构，实现 Agent 中 Thought – Plan – Action – Reflection(Thought) 的循环，一个模型负责所有事情。

MCP

上述架构里，Tools 模块有一些小问题：工具函数可维护性和可扩展性不太好，多了后难管理，要加函数得更新主程序，另外得自己定义一个 Function call 规范，对外部的一些会用到的工具服务都需要自己封装一遍。

对这些小问题，这个架构可以有一个优化：Tool 模块从 Agent 剥离出来，用 MCP 协议统一管理和实现。

附：MCP是什么？

MCP 是 Anthropic 24年11月推出的协议，近期 Cursor / windsurf / cline 等一众 AI Coding 产品支持了 MCP 后出圈，众多开源框架也开始支持 MCP，大有统一的趋势。

MCP 的概念很简单，就是统一了工具调用的接口规范，这几张图可以帮助理解：

1. MCP 统一了各工具能力接入的接口调用定义，原先一个服务(例如slack）要对接多个用户端产品（例如cursor）定义的 Function call 格式，现在服务和客户端统一对接同一种格式就行，两边都只需要实现一次。

2. MCP Server 独立运行在任意服务器上，也可以有自己独立的数据库信息/资源，不与 Agent 服务器绑定，可复用、易于插拔。

把原先 Tool 几个工具函数调用用 MCP Server 封装，架构变成这样：

跟原先纯 Function call 的区别在于架构上更灵活，包括：

1. 聚类，对零散的一个个函数可以统一放到一个服务，便于管理。
2. 解耦：调用实际发生在各自 MCP 服务端，而不是 Agent 服务直接去调用，部署扩展工具与 Agent 工程上解耦。
3. 内聚：MCP Server 本身可以内聚做一些事，包括独立的资源管理、独立上下文等。
4. 复用：通用协议，Tool 能力便于在多个 Agent 间接入复用，外部生态有较多现成 MCP Server 可直接接入。
5. 统一：客户端、云端的工具调用，都可以用统一的 MCP 协议去实现。

这个架构似乎已经可以满足大部分场景下对 Agent 的诉求，为什么还需要考虑 Multi-Agent？

Multi-Agent

考虑 Multi-Agent 最主要的问题是上下文过长。

如果一个 Agent 能力足够强，它应该能完成需要非常多轮调用完成各种任务，这些任务的制定和执行结果全部塞在一个上下文里，可能会超出当前模型能理解和处理的范围。

这时候，计算机工程的典型解决思路就是：分治模块化。把整体 Agent 能力拆分成解决一个个独立复杂任务的子 Agent，让这些 Agent 在它的范围内能有自主思考和自主行动能力。

从 Agent 的组成来说，必不可少的部分包括：

1. 模型：独立的处理模型，可以跟其他 Agent 不同，称为专家模型。也可以相同，看需要。
2. 上下文：独立的多轮 ReAct Loop 上下文管理，完成自己特定的任务
3. System Prompt：对应任务制定特定的 System Prompt

而 Tools 可以不是 Agent 专用的，这个 Agent 需要什么 Tools，就注册什么 Tools。长时记忆/知识库也可以是多个 Agent 共用的。

架构会变成这样：

这样 Plan Agent 只专门制定计划，它需要知道的上下文是其他几个 Agent 能完成什么大的任务，至于他们调了什么工具怎么完成不用管，只需管它要结果，整个任务的上下文就被分出多个部分，每个 Agent 的上下文对另一个 Agent 可以是黑盒。每个 Agent 也可以有自己对应的模型，做独立的训练和 Prompt 调优。

这样是不是一个更优的架构？

1. 它的好处是解决了上下文过长，模型处理不好的问题。
2. 但坏处也是很明显：整个架构是复杂化了，而效果也不一定好。多个 Agent 需要协同，Plan Agent 能获取的上下文信息变少了，它没有了更细粒度统筹规划整个任务的能力，变成一个偏项目管理的角色协调各方的工作，多人协作带来信息熵增大，组织效率低。

AI 的范式，可能不应该这样分治，可能大模型在对上下文的支持、细节信息的理解上会越来越好，能统筹把握好各项细节，把一个复杂任务完成，而不是像人类社会一样分工协作。这样对大模型来说，有足够的信息量能做规划/决策/反思，也更便于端到端的模型训练。

从号称泄漏的 Manus Prompt 来看，Manus 也没有 Multi Agent，所有能力包括工具函数都在一个上下文中定义，看起来目前也能跑得起足够复杂的任务。

所以如果项目在早期，没有遇到很明显的瓶颈，并不需要用 Multi-Agent 架构，用 Single Agent 简单的架构足够能做好。工程架构越简单，后续基础模型升级带来的增益越大。

基于 MCP 的(伪)Multi-Agent

再探讨下，如果在应用过程中已经发现上下文处理不过来的问题，或者某个任务的内部实现细节对整个任务无影响，或者三方都实现好了，那采用另一种伪 Multi-Agent 架构，也是可以考虑的方案：

例如对接 browser-base 实现更深度的 research 能力，需要多轮打开不同网页、判断资料收集是否完成、整理资料，有自己的 loop 、上下文和模型。但这个完全可以封装在一个 MCP 服务上，自行闭环完成多网页搜索和整理，不需要与原 Agent 流程上有更深入的交互。

跟上面的 Multi-Agent 架构的区别在于，并没有改变原来单 Agent 架构，不会增加架构复杂度。Agent 不需要感知 MCP 调用背后是 Agent 还是一个普通的函数调用，没有区别。

MCP 协议本身也是 SSE 流式输出，对这个背后是 Agent 的 MCP 调用，要输出多少上下文信息给原 Agent，也是可以非常方便地调控。

以上是近期的一些想法，Agent 是新东西，后续实践有认知的更新再分享。

狮子林，苏州四大名园之一，代表元代的艺术风格。园林，园林，大多叫园，叫林的只有一个，就是狮子林。狮子林园内以假山叠石为主体，厅、堂、殿、阁、亭、选、斋、堂20余处，园中有9条假山山脉，21处洞穴，是中国古典园林中堆山最曲折，最复杂的一个，假山面积约占全园总面积的五分之一，面积达1100平方米，被誉为“假山王国”。乾隆下江南时曾六次到访狮子林，园中共有乾隆皇帝写的匾额16处，可见他对狮子林是喜爱至极。

狮子林为什么叫狮子林，大部份UP主解释为因为园内有很多假山形似狮子，所以叫狮子林。其实狮子林发端于禅林，是寺庙和园林的结合体。禅宗高僧天为纪念自己的师傅而取名“狮子林”。

元朝1341年，一位名叫天如的禅师来到苏州讲经传禅，天如禅师的弟子在娄门边的某处地方，见闹市中古木参天，觉得这里很适合修禅讲道，于是便在此置屋，建起了一处禅林给天如禅师布道之用。
来到苏州之前，天如禅师曾在浙江天目山狮子崖修行二十余载。而天如禅师的老师中峰明本，以及中峰明本的老师高峰原妙都是在狮子岩得道。
天如禅师将住所命名为“狮子林”，又称“菩提正宗寺”。狮子林，以“狮”同“师”，表明了不忘师祖之意。同时，狮子又名“狻猊”，是佛国之兽。而在古代，寺院又称丛林，简称“林”。这便是狮子林名字的由来。[原文]

卧云室位于指柏轩南面假山中央的平地中，如安卧于峰石间，取金元好问“何时卧云身，因节遂疏懒”诗句意名“卧云室”。其原为寺僧静坐敛心、止息杂虑的禅室。

亭内正中悬挂着天如禅师像。

揖峰指柏轩是园内主要厅堂，楼式建筑，轩面对规整的小水池和湖石假山，山上罗列石峰石笋，山石缝中古木虬根盘绕。轩底层四周为回廊，楼上层缩进。轩面阔五间，黄瓜环脊歇山顶。

真趣亭位于水池南岸，面对假山。其形体较大，结构特殊，亭内前二柱为花篮吊柱，后用纱隔成内廊，亭内天花装饰性强，扁作大梁上为菱角轩和船蓬轩，雕梁画栋，彩绘鎏金，鹅胫椅短柱柱头为座狮。亭内悬挂金底绿字乾隆御笔“真趣”匾。

园林漏景、借景都很好看，专门拍了一些。

此次狮子林游玩和旅行漫记差点可以偶遇，后来我又追到了上海，还是错过了。（纯属自编）如果要看狮子林的好片，可以去S兄博客。

好啦，2025 苏州园林之旅到此更新完毕。连续几天都在园子里逛，十分尽兴，都有点时空错乱了。

By iPhone 12 Pro Max（前一天玩得太累，回酒店忘记给相机电池充电， D-LUX8 备3个电池都是必要的。）

沧浪亭是苏州存世最古老的园林，苏州四大园林之一，代表着宋代艺术风格，出自于北宋时期苏舜钦之手，曾经是名将韩世忠的住宅。相对留园、拙政园，沧浪亭的造园艺术是别具一格的。未进园就有一池绿水环绕的园林外墙，然后一进门就可以看到一座假山屏障。园内以假山为主体，山下有开凿的水池，假山延伸的左侧石头山上有沧浪亭，然后山水之间以一条曲折的复廊相连。园内除了专门开凿的一个水池，就没有其他水源，它的水都巧妙的设计在了园外，是其一大特色。

沧浪亭匾额上三个字是清代文学家俞樾所书写，石柱上的楹联为“清风明月本无价，近水远山皆有情”。欧阳修曾在《沧浪亭》一诗中写道：清风明月本无价，可惜只卖四万钱。而苏舜钦在《过苏州》中有诗云：绿杨白鹭皆自得，近水远山皆有情。这副楹联便是清代梁章钜将这两句诗集为一联。

临水处建复廊，以漏窗通透内外景物，使内外山水融为一体。

清香馆内陈列一套树根家具，为清末之物，用福建榕树根精制，采其天然造型形有飞禽走兽图案，龙凤星祥形态。

据统计，园内共有花窗108款，造型各不相同，活泼有趣，十分花心思。

通过这些花窗漏景，可以窥探园内的美丽景色。

沧浪亭另外一个特色就是竹子，据统计园内共计22种竹子种类，包括箬竹、苦竹、慈孝竹、毛环竹、湘妃竹、水竹、青秆竹、哺鸡竹等等。园内处处可见竹子，《沧浪亭记》中记载其周边环境：“前竹后水，水之阳又竹，澄川翠干，光影会合于轩户之间，尤与风月为相宜”“水得微径于杂花修竹之间”。智者乐水，君子师竹。翠竹潇洒清逸，代表了君子的翩翩风度。

仰止亭，袭诗经“高山仰止，景行行止”之意而名。此为半亭，始筑于同治年间，其名与五百名贤祠有关，亭内嵌有御题文徵明小像石刻，是珍贵的历史文物。新亭建在遗址上，原亭为六棱六柱、六角形屋盖式凉亭，石木结构，高6米，周长20米，顶盖小青瓦、柱为红色、顶内盖板与花额窗为绿色，亭西一米靠山处立有“讲经台”石碑一块。

翠玲珑，又叫做“竹亭”，有三间房，另外连贯几间大小不一的旁室，南宋绍兴初韩世忠时就有其名，取苏子美诗“秋色入林红黯淡，日光穿竹翠玲珑”之意为名。

从翠玲珑的窗户往外看，四面都可以看到竹子。

明道堂，位于园内假山东南部，面阔三间，为清同治十二年巡抚张树声所创，袭苏舜钦《沧浪亭》中语“观听无邪，则道以明”之意而名。旧为会文讲学之所，此堂开敞四舍，宏伟庄严，是为园中主厅。

沧浪亭相对小众，去的当天人非常少，所以在这里我拍的照片反而是最多的。沧浪亭以园外的理水，园内的竹林、复廊、借景和漏窗最为有特色。不像留园那么精致，没有拙政园的大气奢华，沧浪亭表达的是一种古朴而又不经细琢的山野之趣。

摄于2025年2月7日，By 徕卡 D-LUX8

拙政园，与沧浪亭、狮子林和留园并称苏州四大园林，为苏州四大名园之首，代表着明代的艺术风格。拙政园又与北京颐和园、承德避暑山庄、苏州留园一起被誉为中国四大名园。拙政园占地面积78亩（52000平方米），建于明正德四年（公元1509）。拙政园由东园、中园、西园（ 西部补园、中部拙政园、东园归田园居）以及住宅部分组成，住宅部分现为园林博物馆展厅。总体布局以水池为中心，中园最为出彩。

拙政园中“拙政”一词来源于潘安《闲居赋》“于是览止足之分，庶浮云之志，筑室种树，逍遥自得。池沼足以渔钓，春税足以代耕。灌园當蔬，供朝夕之膳；牧羊黏酪，侯伏腊之费。孝乎唯孝，友于兄弟，此亦拙者之为政也。”而拙政园从字面意思上看“拙”为笨拙之意，“政”指政治才能，“园”即园林之意。

拙政园的设计者是文徵明。当年王献臣诚邀文徵明为自己设计园林。文徵明素来清高，在书画界，一般人求画他都不应，何况是设计宅邸，但这次他因敬重王献臣的人品，而希望通过自己的设计，为其营造一方世外桃源，聊以慰藉。

在造园中，构景要素有叠山、理水、建筑、植物四个元素，造景手法分抑景、添景、夹景、对景、框景、漏景、点景、借景等，我尝试把拍的照片归了一下类。个人觉得叠山是狮子林比较出彩，理水以沧浪亭为最佳，建筑可能留园更加精致，而拙政园各方面都还不错，造景手法运用更丰富一些。

理水

叠山

建筑

曼陀罗树即山茶的别名，因为叶子类似茶叶，又可作饮，故得山茶名。

植物

造景手法

光影

古人官场的失意，不想出家门，“不出城市而得山林之性，逍遥自得而享闲居之乐”，借这些景这些物去抒发感情，一步一景都有其含义，什么季节去哪个亭子赏玩，配合什么植物花果，哪个亭子和哪个亭子对应，都是十分考究，前前后后花了二十年修建。景物建筑丰富，手法运用丰富，是实实在在的园林教科书。

摄于2025年2月6日，By 徕卡 D-LUX8

Claude 3.7 Sonnet 在万众期待中推出了，为什么期待，因为从 Claude 3.5 Sonnet 发布后，一直是AI Coding Agent 领域最好的模型，综合效果没有对手，后面陆续推出的 o1/o3/DeepSeek 都没能撼动，更让人期待 Claude 3.7 Sonnet 在 AI Coding 领域能不能有进一步提升。

Claude 3.7 放出来的 Benchmark 里，有两个是跟 AI Coding Agent 表现强相关的：

1. Agentic coding，SWE-bench，衡量解决实际软件工程编码问题的能力。
2. Agentic tool use，TAU-bench，衡量理解用户意图调用工具执行命令的能力。

可以看到 SWE-bench 有显著的提升，问题解决率 49% 提升到最高 70%，TAU-bench 也有不错的绝对值10个点的提升，确实重点提升了 AI Coding Agent 相关能力。

接下来详细看看这两个 Benchmark 究竟测了什么，可以大致知道，目前模型的能力上限大概是怎样。

SWE-bench

SWE-bench 是由普林斯顿大学 NLP 团队开发的项目，23年10月就开始提出，主要是想找到一种方式可以评估大模型解决实际软件工程问题的能力，而不是像之前只衡量算法题的解决能力。当时还是 Claude 2 和 GPT4 的时代，随着 AI Coding 的逐渐火爆，OpenAI 也加入对这个 benchmark 的完善，这个项目也逐渐成为主流。

数据构造

分三步：

1. 选靠谱的库：选了 12 个流行的 Python 开源库，选择的标准是，热门库，长期维护，有比较多的 Pull Request 修复相关 issue，PR 的管理也很规范，有很好的测试覆盖率。这些库修复 issue 的 PR 就是我们要获取的测试 case，但会对这些 PR 进行一些过滤。
2. 特性过滤：1)明确 PR 是解决了某个特定问题。2) PR里包含了测试 case，可以很容易从测试 case 上判断代码修改是否有效。这些在运行前就能过滤出来。
3. 运行时过滤：这些 PR 应用前后，测试用例中要有明确的从不通过到通过的变化，程序跑起来也不会有错误，便于评估结果。

基于上述规则从 github 热门项目上抽取相关的数据，这些数据还可以持续更新，避免模型因为看到过这些数据而“作弊”。

这是抽取的几个流行的 python 库，以及数据集数量：

经过上述步骤抽取构造数据后，得到 SWE-Bench 数据集，后来 OpenAI 对这个数据集再进行人工过滤筛选掉了一些不太好的 case，比如 issue 问题描述不准确、开发环境难搭建难测试等，也对每个挑选的 case 做了精心人工验证，一共500个样本，组成 SWE-bench_Verified 数据集，现在一般测的是这个数据集。

来看看这个数据集具体都由哪些部分组成：

instance_id: 实例ID，通常格式为 repo_owner__name-PR-number

//代码基本信息
repo: 仓库名
base_commit: PR 提交之前的代码 commit id，定位代码基线
version: 用于运行的版本号
environment_setup_commit: commit id，安装运行环境的代码基线
created_at: PR 创建时间

//PR基本信息
problem_statement: PR 对应的 issue 内容，也就是要解决的问题
test_patch: 这个 PR 提交的测试 case patch 代码
FAIL_TO_PASS: 应用修复的 PR 后会通过的测试 case
PASS_TO_PASS: 应用 PR 前和应用后，都应该通过的测试 case
patch: 这个 PR 修复的 patch 代码，相当于标准答案
hints_text: PR 提交之前，github 上对这个 issue 的讨论 comment。可选，如果要上榜单，禁止使用这个数据。

代码信息、问题描述、测试用例，重点是这几个，剩下的都是用于把程序跑起来、验证修复结果用。

测试执行

大体流程见下面这张图，输入 issue 描述和代码库，模型根据输入，输出要修改的代码，最后有个环境运行模型生成修改的代码，跑测试用例，把应用代码之前没跑通的单元测试跑通，这个任务就完成了。

这个过程一个最大的问题是：代码上下文怎么给模型？这几个热门项目代码库平均 43w 行，不可能直接给，需要有个检索的能力。

项目论文中给了两个方法：

1. 作弊：上述构造数据时，我们有拿到人类修复这个 issue 提交的 PR 对应的 patch，而这个 patch 里修改到的代码文件，就是最重要的代码上下文，可以直接作为代码上下文给到模型。这个接近于标准答案，除了一些需要更多文件上下文才可以解的问题外。这个只用于做实验，或去检测其他的检索方式命中率如何。
2. 稀疏检索：用 BM25 算法做检索，基于 issue 的描述搜索相关代码，限制长度在1.3万行-5万行。实验看起来，检索长度在2.7w行时，这种检索方法只有 40% 会命中上述 PR 对应的代码文件。

上述两个检索代码的方法，只是论文中做实验的参考，实际在测试 SWE-Bench 时，各模型会有自己的方法，因为检索代码的准确性对成功率影响也很大，所以榜单上很多是 Agent + 模型 的测试结果，而不是单大模型的。

Claude 3.7 跑分的说明里提到：

SWE-bench Verified: Claude 3.7 Sonnet scores 62.3% out of 500 problems using pass@1 with bash/editor tools plus a "thinking tool" for single-attempt patches — no additional test-time compute used. 70.3% score uses internal scoring and custom scaffold on a reduced subset of problems. Scaffold Deepseek R1 results use the "Agentless" framework. OpenAI results from o3-mini system card cover a different subset of problems with a custom compute.

Claude 没有具体说明怎么做检索代码的，官方blog附录里提到在运行环境上是用了极简的方案，只提供了命令和编辑文件的能力，看起来是只把代码仓库目录扔给 LLM，让它自行去做文件搜索。另外有提到 Deepseek 的跑分是基于 Agentless 框架跑的，Agentless 专门介绍说明了如何跑 SWE-Bench，以及具体是怎么做代码检索的。见 Agentless/README_swebench.md。

可以看到 SWE-Bench 测试集其实是比较局限，这里面全是 Python 代码，也基本是纯逻辑代码，不涉及 UI 渲染相关，也不涉及其他语言，很多实际的软件工程场景没有覆盖到，所以即使 benchmark 到 100%，也不代表能解决绝大多数工程问题。

不过这事是一步步推进的，SWE-Bench 刚出来时解决率是个位数，这一年多一步步提上来，Claude 3.7 干到了 70%，解决了这个 Bench，还会有更多的更高难度的 Benchmark 等着，SWE-bench Multimodal 就是其中之一，包含了一些 JS UI 渲染相关的 issue 修复 case，Claude 3.5 也只有 12% 左右的解决率，还有很长路要走。

TAU-bench

TAU-bench 又叫 τ-bench，是 Sierra 团队（OpenAI 董事会主席 Bret Taylor 和谷歌前高管 Clay Bavor 联合创立的 AI 初创公司，主要开发 AI Agent 为企业服务）推出的用于评估 AI Agent 在现实世界场景中性能和可靠性的基准测试。

TAU-bench 设计了两个领域场景

1. Airline（航空场景），模拟用户在航空业务场景下进行航班查询、预订、改签、退票、机场服务等操作，测试大模型利用工具理解用户需求、提供准确信息、遵循业务规则流程、准确进行业务操作的能力。
2. Retail（零售场景），模拟在零售场景中进行购物咨询、商品推荐、订单修改、退货换货等操作，同样测试在这个场景下用户需求理解能力、准确处理用户订单等相关问题的能力。

这两个场景都包含了多个复杂任务 case，涉及代理与用户的多轮对话，以及代理使用工具获取信息的能力，这些任务可以综合地评估一个 Agent 所需要的 推理、规则遵循、长期记忆、工具调用等能力。为此 TAU-bench 项目也实现了一个完整的 Agent 框架，以执行这个流程。

数据构造

以零售为例，用于测试准备的数据包含以下几个部分：

1. 数据库：json 格式，模拟电商零售领域一些订单信息、商品属性。
2. Tools：操作上述数据库的工具函数，包括获取订单/商品信息、修改订单、修改收货地址等。这些 Tools 信息描述会在一开始给 LLM，让 LLM 知道当前有哪些工具可调用，过程中会 LLM 会根据用户意图调用相应工具修改数据库。
3. 策略：system prompt，写明了模拟的零售场景下一些背景，包括订单状态说明/退换规则/支付方式规则、工具调用规则等。
4. Tasks：预先设计好的测试数据集，每个测试 case 包含 instruction 和 actions，instruction 写明了这个测试 case 里用户的诉求，actions 里包含基于这个诉求下，应该调用什么工具方法改写数据库达到目的，相当于标准答案，actions 只用于最后的验证，不会在每轮测试中作为输入。

航空领域也是同样的这几类数据，只是处理的内容变成航班、订单、用户信息管理。

测试执行

具体测试 case 执行的流程：用户 instruction + 领域策略 System Prompt + Tool 描述，一起输入 LLM，LLM 循环逐步输出用户对话、助理回复、工具调用，整个流程就是一个通用的 Agent 交互流程，跟上次说到的 OpenHands 的流程差不多，只是这里用户输入也是 LLM 根据 instruction 模拟生成的。

整个多轮对话结束后，模型在这过程中会调用工具修改数据库，同时再跑一遍测试 case 里预定的 action，看对数据库的修改跟模型在这过程中调工具的修改结果是否一致，一致则测试 case 通过，不正确就不通过。

来看一个具体的例子，这是一条测试case，包含对用户诉求描述的 instruction 和标准答案 actions：

{
    "annotator": 0,
    "user_id": "omar_rossi_1241",
    "instruction": "Your user id is omar_rossi_1241. For your upcoming trip from New York to Chicago, you want to change the passenger to yourself, upgrade it to economy class, and have 3 checked bags. You prefer gift card payment. Your birthday is in your user profile so you do not prefer to provide it. You are reactive to the agent and will not say anything that is not asked.",
    "actions": [
        {
            "name": "update_reservation_flights",
            "arguments": {
                "reservation_id": "FQ8APE",
                "cabin": "economy",
                "flights": [
                    {
                        "flight_number": "HAT056",
                        "date": "2024-05-25",
                    },
                    {
                        "flight_number": "HAT138",
                        "date": "2024-05-25",
                    },
                ],
                "payment_id": "gift_card_8190333",
            },
        },
        {
            "name": "update_reservation_passengers",
            "arguments": {
                "reservation_id": "FQ8APE",
                "passengers": [
                    {
                        "first_name": "Omar",
                        "last_name": "Rossi",
                        "dob": "1970-06-06",
                    }
                ],
            },
        },
        {
            "name": "update_reservation_baggages",
            "arguments": {
                "reservation_id": "FQ8APE",
                "total_baggages": 3,
                "nonfree_baggages": 0,
                "payment_id": "gift_card_8190333",
            },
        },
    ],
},

转化后这个case实际跟大模型交互的过程：

{"traj": [
      {
        "role": "system",
        "content": "# Airline Agent Policy\n\nThe current time is 2024-05-15 15:00:00 EST.\n\nAs an airline agent, you can help users book, modify, or cancel flight reservations.\n\n- Before taking any actions that update the booking database (booking, modifying flights, editing baggage, upgrading cabin class, or updating passenger information), you must list the action details and obtain explicit user confirmation (yes) to proceed.\n\n- You should not provide any information, knowledge, or procedures not provided by the user or available tools, or give subjective recommendations or comments.\n\n- You should only make one tool call at a time, and if you make a tool call, you should not respond to the user simultaneously. If you respond to the user, you should not make a tool call at the same time.\n\n- You should deny user requests that are against this policy.\n\n- You should transfer the user to a human agent if and only if the request cannot be handled within the scope of your actions.\n\n## Domain Basic\n\n- Each user has a profile containing user id, email, addresses, date of birth, payment methods, reservation numbers, and membership tier.\n\n- Each reservation has an reservation id, user id, trip type (one way, round trip), flights, passengers, payment methods, created time, baggages, and travel insurance information.\n\n- Each flight has a flight number, an origin, destination, scheduled departure and arrival time (local time), and for each date:\n  - If the status is "available", the flight has not taken off, available seats and prices are listed.\n  - If the status is "delayed" or "on time", the flight has not taken off, cannot be booked.\n  - If the status is "flying", the flight has taken off but not landed, cannot be booked.\n\n## Book flight\n\n- The agent must first obtain the user id, then ask for the trip type, origin, destination.\n\n- Passengers: Each reservation can have at most five passengers. The agent needs to collect the first name, last name, and date of birth for each passenger. All passengers must fly the same flights in the same cabin.\n\n- Payment: each reservation can use at most one travel certificate, at most one credit card, and at most three gift cards. The remaining amount of a travel certificate is not refundable. All payment methods must already be in user profile for safety reasons.\n\n- Checked bag allowance: If the booking user is a regular member, 0 free checked bag for each basic economy passenger, 1 free checked bag for each economy passenger, and 2 free checked bags for each business passenger. If the booking user is a silver member, 1 free checked bag for each basic economy passenger, 2 free checked bag for each economy passenger, and 3 free checked bags for each business passenger. If the booking user is a gold member, 2 free checked bag for each basic economy passenger, 3 free checked bag for each economy passenger, and 3 free checked bags for each business passenger. Each extra baggage is 50 dollars.\n\n- Travel insurance: the agent should ask if the user wants to buy the travel insurance, which is 30 dollars per passenger and enables full refund if the user needs to cancel the flight given health or weather reasons.\n\n## Modify flight\n\n- The agent must first obtain the user id and the reservation id.\n\n- Change flights: Basic economy flights cannot be modified. Other reservations can be modified without changing the origin, destination, and trip type. Some flight segments can be kept, but their prices will not be updated based on the current price. The API does not check these for the agent, so the agent must make sure the rules apply before calling the API!\n\n- Change cabin: all reservations, including basic economy, can change cabin without changing the flights. Cabin changes require the user to pay for the difference between their current cabin and the new cabin class. Cabin class must be the same across all the flights in the same reservation; changing cabin for just one flight segment is not possible.\n\n- Change baggage and insurance: The user can add but not remove checked bags. The user cannot add insurance after initial booking.\n\n- Change passengers: The user can modify passengers but cannot modify the number of passengers. This is something that even a human agent cannot assist with.\n\n- Payment: If the flights are changed, the user needs to provide one gift card or credit card for payment or refund method. The agent should ask for the payment or refund method instead.\n\n## Cancel flight\n\n- The agent must first obtain the user id, the reservation id, and the reason for cancellation (change of plan, airline cancelled flight, or other reasons)\n\n- All reservations can be cancelled within 24 hours of booking, or if the airline cancelled the flight. Otherwise, basic economy or economy flights can be cancelled only if travel insurance is bought and the condition is met, and business flights can always be cancelled. The rules are strict regardless of the membership status. The API does not check these for the agent, so the agent must make sure the rules apply before calling the API!\n\n- The agent can only cancel the whole trip that is not flown. If any of the segments are already used, the agent cannot help and transfer is needed.\n\n- The refund will go to original payment methods in 5 to 7 business days.\n\n## Refund\n\n- If the user is silver/gold member or has travel insurance or flies business, and complains about cancelled flights in a reservation, the agent can offer a certificate as a gesture after confirming the facts, with the amount being $100 times the number of passengers.\n\n- If the user is silver/gold member or has travel insurance or flies business, and complains about delayed flights in a reservation and wants to change or cancel the reservation, the agent can offer a certificate as a gesture after confirming the facts and changing or cancelling the reservation, with the amount being $50 times the number of passengers.\n\n- Do not proactively offer these unless the user complains about the situation and explicitly asks for some compensation. Do not compensate if the user is regular member and has no travel insurance and flies (basic) economy.\n"
      },
      {
        "role": "user",
        "content": "Hi! I'd like to make a few changes to my trip from New York to Chicago. Can you help me with that?"
      },
      {
        "role": "assistant",
        "content": "Of course! I can help you modify your trip. Could you please provide your user ID and the reservation ID for the trip you want to change?",
      },
      {
        "role": "user",
        "content": "Sure! My user ID is omar_rossi_1241. But I'm not sure about the reservation ID at the moment."
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"user_id":"omar_rossi_1241"}",
              "name": "get_user_details"
            },
            "id": "call_FXi5dyufwOlkHksVgNwVhhVB",
            "type": "function"
          }
        ]
      },
      {
        "role": "assistant",
        "content": "I found your reservations. Could you please confirm which reservation ID you'd like to modify for your trip from New York to Chicago? Here are your reservation IDs:\n\n- UM3OG5\n- 5RJ7UH\n- FQ8APE\n- QKRY03\n\nLet me know which one you'd like to modify!",
      },
      {
        "role": "user",
        "content": "I'm not entirely certain, but I believe it might be the first one, UM3OG5."
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"reservation_id":"UM3OG5"}",
              "name": "get_reservation_details"
            },
            "id": "call_FApEDaUHdL2hx8FNbu5UCMb8",
            "type": "function"
          }
        ]
      },
      {
        "role": "assistant",
        "content": "The reservation ID "UM3OG5" is for a round trip from Seattle (SEA) to Dallas/Fort Worth (DFW), not from New York to Chicago. \n\nCould you please check if any of the other reservation IDs match your trip from New York to Chicago? Here are the remaining reservation IDs:\n\n- 5RJ7UH\n- FQ8APE\n- QKRY03\n\nLet me know which one you'd like to modify!",
      },
      {
        "role": "user",
        "content": "In that case, I think it might be FQ8APE. Can you check that for me?"
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"reservation_id":"FQ8APE"}",
              "name": "get_reservation_details"
            },
            "id": "call_W507pQxieFVdAxvqONuYWvN2",
            "type": "function"
          }
        ]
      },
      {
        "content": "The reservation ID "FQ8APE" is for a one-way trip from Newark (EWR) to Chicago (ORD) with a stop in Houston (IAH). Since this reservation is in basic economy, please note that the flights cannot be modified. However, I can assist with other changes like cabin upgrades or baggage additions.\n\nPlease let me know what specific changes you would like to make to this reservation!",
        "role": "assistant"
      },
      {
        "role": "user",
        "content": "Great! I'd like to add three checked bags, change the passenger to myself, and upgrade to economy class, please."
      },
      {
        "role": "assistant",
        "content": "Here are the changes you want to make to your reservation:\n\n1. **Add three checked bags**: \n   - Since you are a gold member and upgrading to economy class, you will have 3 free checked bags, so no additional charges for the bags.\n\n2. **Change the passenger to yourself**:\n   - Current passenger: Ivan Garcia\n   - New passenger: Omar Rossi (DOB: 1970-06-06)\n\n3. **Upgrade to economy class**:\n   - Upgrade from basic economy to economy class.\n\nPlease confirm if you would like to proceed with these changes.",
      },
      {
        "role": "user",
        "content": "Yes, I'd like to proceed with those changes. And please use a gift card for any payment needed."
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"reservation_id": "FQ8APE", "passengers": [{"first_name": "Omar", "last_name": "Rossi", "dob": "1970-06-06"}]}",
              "name": "update_reservation_passengers"
            },
            "id": "call_jK7xz4ERk3csc9jBfroPobGs",
            "type": "function"
          }
        ]
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"reservation_id":"FQ8APE","cabin":"economy","flights":[{"origin":"EWR","destination":"IAH","flight_number":"HAT056","date":"2024-05-25"},{"origin":"IAH","destination":"ORD","flight_number":"HAT138","date":"2024-05-25"}],"payment_id":"gift_card_8190333"}",
              "name": "update_reservation_flights"
            },
            "id": "call_zeyT5c2EYzRvfY42X7YOKOng",
            "type": "function"
          }
        ]
      },
      {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "function": {
              "arguments": "{"reservation_id":"FQ8APE","total_baggages":3,"nonfree_baggages":0,"payment_id":"gift_card_8190333"}",
              "name": "update_reservation_baggages"
            },
            "id": "call_PA1XaKLPX8egjewaxIArCkRc",
            "type": "function"
          }
        ]
      },
      {
        "role": "assistant",
        "content": "Your reservation has been successfully updated with the following changes:\n\n1. **Passenger Change**: The passenger is now Omar Rossi.\n2. **Cabin Upgrade**: Upgraded to economy class.\n3. **Checked Baggage**: Added three checked bags, all free due to your gold membership.\n\nThe payment for the cabin upgrade was processed using your gift card. If you have any more questions or need further assistance, feel free to ask!",
        
      },
      {
        "role": "user",
        "content": "Thank you for helping with the changes! That's all for now. ###STOP###"
      }
    ],
}

在跑的过程中，可以看到大模型可以一步步理解好用户意图，调用get_reservation_details 工具获取信息，最后依次调用 update_reservation_flights、update_reservation_passengers、update_reservation_baggages，修改数据库。

执行完后，会重新加载初始状态的数据库，把 Task 里的 actions 依次执行一遍，对比最终数据库的状态是否一致，一致则说明模型这轮跑下来，调用的工具和修改的数据跟我们预期的一致，测试通过。

这里可以看到每条测试的过程和结果，可以从 Reward=1/0 看这条 case 是否通过，Claude 3.7 在零售领域问题解决率高达81%，但航空领域只有58%，细看下航空领域一些 case 涉及非常多的查询匹配航班信息、金额计算、行李/支付/退换多步操作，难度还是很大的。

Pass^k

这个测试集还定义了另一个指标：多次稳定通过的概率。因为 Agent 真正使用时，比如让它去订机票、处理退换货，如果执行失败会让人有很大的挫败感，所以它的成功率稳定性很重要，这个 benchmark 定义了pass^k 的指标，也就是对一个测试 case 连续执行 k 次，每次都成功，才能算任务成功。

可以看到每个模型的稳定性都不是很好，航空领域下，Claude Sonnet 3.5 从 46% 通过率下降到pass^4 的 22.5%，也就是只对 22.5% 的问题，连续测4遍都能成功。

这跟我们目前体感也一致，Agent 还没那么可靠，并不能期望它在复杂的场景、多轮交互中很稳定地理解意图做出正确的行动。Claude 3.7 没有 pass^k 相关的指标，不确定稳定性是否有提升。

最后

上述两个 Benchmark 都是尽量在模拟真实世界的问题场景，算是模拟得比较好的了，但跟真正现实的使用方式和多样性还是有很大差距，分数只能是个参考，能大致知道模型在哪些方面表现还不好，实际在某个场景下好不好用，还得真正上手测试，实际体验上据了解 Claude 3.7 远好于 3.5，这两个 benchmark 的分数提升还不足以反应优化的程度。

虎丘，又叫海涌山、海涌峰、虎阜，距现在已经有二千五百多年悠久历史。传说远古时期苏州是一片茫茫大海，虎丘山是从海里涌出的一个小小岛屿，后来沧海变良田就成为一座小山，山高34.3米，所以也叫海涌山。而虎丘这个名字源于春秋时的吴王阖闾，他在这里修城建都，死后也葬在这里。传说葬后三日，墓地有“白虎蹲其上”，因而得名。也有说“丘如蹲虎，以形名”。虎丘的山体由侏罗系火山岩浆构成，园内很多山石都是流纹岩。

虎丘后山有“虎丘后山胜前山”之说，现存青石小桥、石牌坊、湖石假山，也是苏州园林的一大代表。《吴地记》载：”虎丘山绝岩纵壑，茂林深篁，为江左丘壑之表“。

景区南门入口的牌坊，写着“吳中第一山”，远远能看到虎丘塔。

走进天下第一名胜虎丘大门，过海涌桥，再走百来米才到景区售票处。

这里的河道与山塘街相连，有七里山塘水源自虎丘的说法。

虎阜禅寺是沿山而建，由于山门建在山前，有“寺中藏山”的特点，但实际寺又在山里，又有深山藏古寺的布局。

景区检票口的碑廊。

断梁殿上面的主梁是断的，它用两根木料建成的，它的建成主要是运用了力学中的杠杆原理，在这断梁下有一排斗拱相托，通过斗拱将中间所承受的力分散到四周，采用了“挑梁式”的构筑方法。

断梁殿大门对联是：上联“塔影在波山光接屋”、下联“画船人语晓市花声”。

拥翠山庄墙上的两边刻有“龙、虎、豹、熊”行草大字石刻四方。拥翠山庄是苏州唯一 一座无水的园林，由苏州状元洪钧所建。建筑依山势分四个层次，园内第一层抱瓮轩，抱瓮轩三间朝南，是全园的主要建筑。

憨憨泉有一段美丽的传说，憨憨是中国梁代著名的高僧，当时他的眼睛不好，患有目疾，也就是“白内障”，虎丘山的方丈因为可怜他，收他做一个挑水和尚，但是当时挑水的路很远，有一次他挑水途经这里，因为感到累，于是就坐在这里休息，不知不觉中就睡着了，在梦中它梦见一位高僧对他说这里有一泉眼可通大海，醒后他就用双手触摸这片地，在这里摸到了一些青苔，他想有青苔就说明这地下一定有水，于是他用挑水的扁担在这里挖，大约挖了七七四十九天，终于一脉泉眼涌了出来，治好了憨憨的眼睛，因这口井是他所挖所以取名为“憨憨泉”。

真娘墓，位于通往虎丘山坡道的右侧。真娘确有其人，原名姓胡，名瑞珍，北方人。她从小父母双亡，唐朝“安史之乱”的时候，随同亲戚一起逃亡来到苏州，但是不幸坠入苏州阊门外的一个妓院——“乐云楼”。她虽成为青楼女子却守身如玉，只陪客人歌舞书画，是苏州一位绝色佳丽。当时，苏州有个大财主，名叫王荫祥，他用重金贿赂老鸨，企图在真娘那里留宿，真娘知道这次难以逃避，为了保持贞洁，她便上吊自尽了。这使王荫祥内心大受震撼，于是为真娘筑了此墓，并且发下重誓，今生永不再娶。此后，许多文人墨客都同情真娘，在她的墓上题写诗词，真娘也由此在中国历史上有了一席之地，与杭州另一名妓苏小小齐名，被誉为“香魂”。清乾隆十年（公元1745年），海陵陈璜访得遗址，建亭其上，立石刻书“古真娘墓”4字。

枕石，形似枕头。相传苏州才子唐伯虎游玩时在这个石头上睡着了，另外一个才子祝枝山看到了这个景象，便在石头上写下了“枕石”二字。

相传春秋时期，吴王阖闾为了争霸天下，召来了当时最有名的铸剑师干将莫邪夫妇为他铸剑。满期那天，他提着“莫邪”剑来到了虎丘山，将此剑献给了阖闾，阖闾为了试其剑的锋利，对着这块石头手起剑落，就将这块石头一劈为二，这就是有关试剑石的传说。事实上，这块石头是典型的火山喷出岩的凝灰岩，久经风化，沿着裂隙形成这样一条大缝，酷似剑劈。

旧志云：“生公讲座，下有千人列坐，故名。”《吴地记》曰：“虎丘泉石，其最胜者剑池，千人坐。”《吴郡志》云：“生公讲经处，大石盘陀数亩，高下如削，乃他山所无。”现石上刻有千人石“千人坐”三个篆字，是胡缵宗所书。

虎丘最出名的就是“剑池”，相传池底埋有吴王闵闾的墓葬，其子吴王夫差曾以鱼肠剑和其它宝剑共三千把為父亲陪葬，故名“剑池”。上从往下看，水道就像一把剑横卧在山间。

剑池岩壁四周写了各大家到此一游的题字。

虎丘塔是世界第二斜塔，又称中国的“比萨斜塔”，园内第二大景点。这座塔七层八面，塔高47.7米，塔向东北偏北方向倾斜，它的塔顶偏离中心2.34米，最大倾角是3度59分。1986年对虎丘塔进行“加固塔基”的第二次大修，才使千年古塔转危为安。虎丘塔建于五代后周显德六年（959年），建成于宋建隆二年辛酉（961年），已经有一千多年的历史。

虎丘是苏州2500年沧桑的见证，苏州历史文化古城的标志，有很多源远流长的典故，苏东坡曾说：“到苏州不游虎丘，乃憾事也”。

摄于2025年2月5日，By 徕卡 D-LUX8

从留园出来还没到午饭时间，正思索去哪里打发时间，突然想起西园寺就在附近，相隔一条街，便去探访一番。

西园寺，俗称西园，地图上标示为戒幢律寺。戒幢律寺始建于元代至元年间（1264—1294年），最开始名为归元寺。所以你在地图找到的戒幢律寺、西园古刹、西园，其实就是西园寺。西园寺是苏州古城内唯一一座带有园林的寺庙，距今已有700多年。现存建筑为清代重建，明嘉靖年间曾一度被留园的建造者太仆寺卿徐泰时改为了私家园林。

从留园过来走东门较近一些。上香礼佛后便去逛园子了。

东边礼佛区庄严肃穆，一墙之隔是风格迥然的园林空间。后花园内有宽敞的大草坪，水静如镜，水中古树倒影郁郁葱葱。园内非常多古树，都是历史的见证。

湖中心筑有六角亭，楼阁形式，叫湖心亭。水域是放生池，被湖心亭的步道划分为两部分，环池布置假山、亭台、花架、厅堂等，也是满满的苏州园林特色。

可由假山翻过园子另一侧。

西园寺有另一大特色就是有非常的猫，花色各不相同。很多小姐姐们围着小猫一直拍照，我也忍不住凑过去多拍了几张。其实你从入寺园寺前就发现路边很多卖猫粮的小商贩，就知道这附近有撸猫的好地方。

出了西园寺后，可以看到南门口的智慧桥与福德桥，连接西园弄和枫桥路，两桥同时修建，结构完全对称。

西园西南门是正门，正门前是御赐牌楼，四柱隔成三门，中门横额写“敕赐西园戒幢律寺”，中门石柱刻有一副对联：“佛日增辉重开阊阖，宗风振律大启丛林”。御赐牌楼始建于清光绪年间，至今保存完好。

西园寺最佳游玩季节是秋季，届时满园都是金黄的银杏和红枫，十分好看。

从出口出来后才发现这里有售票处，很多人在购票。但从东门入居然不检票，无意之中“逃过一票”。

摄于2025年2月5日，By 徕卡 D-LUX8

生日是属于自己的新年，许愿时闭眼的瞬间，过去与未来在黑暗中重叠。

今年的年度总结总是拖拖拉拉一直没有写出来，感觉在过去的 2024 年里面整个人的节奏在“快/慢”之间频繁的交替，大部分时候都在忙忙碌碌响应和支持各种工作与生活中的事情，好不容易放松下来就只想一个人静静，哪怕是发呆放空，也会觉得能让自己坐着慢慢回血（游戏里都是这样的吧，只要暂时停止被攻击的状态，就能缓慢的回复血量）。

原本找了个时间，打算对比 2023 年的总结看看有哪些改善与进步，但很遗憾的发现可能“在常态中一点点进步可能才是人生的常态”，在过去的一年里似乎没有什么“宏大的叙述”与“翻天覆地”的改善，好像日子还是一步步缓慢的进展，印象里有很多开心的瞬间，但也不免有些许灰暗的时刻。

但也无妨，一步步来就好了，按照惯例先来看看去年发生了哪些事情。

「物理意义上/精神意义上的家」

在完成买房和开始装修后，直到去年 4 月，我和蒋老师的新房终于完成了装修和空置散味。于是我们一家四口就心满意足的搬了进去。看到从平面图和效果图里走出来几乎达到 99% 实现状态的新家还是会觉得很不可思议。

相比刚拿到房产证时心态上没有什么波澜的彼时的我来对比，此时此刻能够坐在自己选择的沙发上看着自己选择的各种家具和电器，并且住在自己的房子里时，心态上不可避免的会有“原来这就是属于自己的家”，“这个家可真好啊”的想法出现。平日里这个房子的任何美好印象都会让我俩觉得“有家真好”，不论是看到第一缕朝阳从百叶缝隙射入卧室，看到落日从枝叶中穿过散落在窗帘上的斑点，还是在阳台摘个柠檬后继续吃烤肉，生活里的幸福感好像在无数个瞬间都能被轻而易举的感知到。

虽然在 23 年的时候我就持证山岗开始了自己的婚后经历，但实际上去年 6 月我们才回到兰州，在端午节的兰州办了一场婚礼（严格一点说，应该属于去除了大部分繁缛流程的答谢宴），爸妈总是觉得领证了但不办一场酒席很难说的过去，但我和蒋老师又不希望办理那种“流程化的，高度重复与一致的，没有新意的”就像是出了份子钱吃一顿饭的婚礼。

在无数次沟通后，大家说服了彼此，于是我和蒋老师自己策划自己当主持人举办的婚礼就放在了计划之中。自己办理自己的婚礼，而且完全不要任何的策划与主持人听起来又难又简单的，我们四个人需要临时分工确认好每一个人扮演的角色，随后和场地方沟通自己心中想实现的婚礼现场，自己采买置办对应的喜烟喜糖流程中抽奖发放的奖品，确认当天自己和双方父母的服饰流程等等，都是各种细小的琐事，但确实生怕忙中出错还是花了很大的精力。

还是要感谢我和蒋老师，感谢双方的父母，感谢小蒋的家人从四川大老远来到成都，感谢来自天南海北来帮忙捧场的朋友同学和人生中的挚友，我俩的婚礼算是顺顺利利的完成了。其实最初计划举办婚礼的时候，我一直疑惑我们这一场普普通通的婚礼是否值得大家在端午节的时候，放下原本的安排专门前来，但我想到如果是这些朋友们的婚礼，我一定会毫不犹疑的前往，所以就不再纠结了。

写这篇总结的时候我翻出来了自己写的发言稿，这句话我觉得还是挺对的“今天开始，我们的人生到了新的阶段，也许人生路上起起伏伏，未来的我们还需要面对不同的困难和挫折，希望我们彼此扶持，上坡的时候充满动力的推彼此一把，下坡的时候用全部的动力撑着对方不让对方坠落，一起携手对付生活中的各种问题。祝我们新婚快乐，我们不仅是夫妻，也是彼此最好的好朋友。希望我们能够站在一起面对问题和挑战，能够一同相拥共享快乐的果实，能够一直携手畅游人间，探索这个世界的无限精彩。希望我们不仅这辈子，下辈子以及下下辈子，都永远是夫妻。”

「工作上无规律的变化/一成不变」

在举办婚礼的前后，工作中也发生了许多“一成不变”的变化。先解释一下，并没有离职或者换工作，还是在原本的公司里努力搬砖， 尝试在产品行业里做出一些不一样的尝试和贡献。公司的规模今年还是保存在不到 100 个人左右的样子，做的事情也会时不时需要从产品设计的挑战中抽离出来去服务一下各种各样的“客户爸爸”，有时候真的挺无语的（希望 2025 年事业上能够有转机，做一些有意义有挑战而且是正向循环的事情）。

可能是市场大环境不好，可能是行业所限制，可能是小公司无法脱离的赚钱魔咒。坦白说这一年在工作中让我 emo 的次数挺多的，但工作就是受人之托忠人之事啦，今年在工作中也算是缓慢的螺旋上升，自己的产出才是证明自己能力的唯一试金石。这几年我越发发现公司规模的背书越来越重要，每当这个时候我就会有点不甘心，但可能人生的常态就是要说服自己适应平常？谁知道呢。

其实讲道理，在这里证明自己的工作成绩应该放一些新做的产品和说明的，但是产品行业这几年好像确实不好做了，需要你的时候说你是公司里最不可或缺的存在，但等开始拆分贡献的时候有要你来证明自己的产出能够如何影响销售业绩，有时候想起来都挺荒谬的。所以我就放了两个和团队小伙伴聊天的截图，反正就还是努力做个好人，别去伤害别人。

但坦白来说今年在产品设计上的新尝试也挺多的，使用 AI 做了很多奇怪的东西（甚至自己一个人就用 40 块搞了一个网站出来），做了很多面向电视大屏，手机和各种移动设备的产品出来，但这些东西终归是属于小打小闹，我也不好意思平常写在博客和大家分享，等我觉得搞的差不多或者真的挺有意思再和大家分享吧。

说到 AI 不可避免还是要聊聊 AI 对产业的冲突，其实之前我也在博客里写过一些对 AI 的分析，截止目前我依然觉得“AI 工具还是适合那些有一定经验的开发者，不管是快速搭出原型，还是学习一个新的技术和工具。以后 AI 肯定会更智能更聪明，但做出一款好的产品还是要靠设计者的同理心与感知世界的能力。也别想的用 AI 来彻底降本增效了，AI 应该用来加速试错和优化迭代，而不是直接取代已有的软件设计与开发方式”。

大家都在研究怎么用 AI 打造一些趁手的工具，但有时间的话也可以抬头想想一些“飘在风中的问题”，比如“我们这种碳基大模型的下一步发展方向在何处？”，“产品设计师应该专注于创造工具，还是尝试和工具互相影响？”……

「天命可违/天命难违」

每年的总结里我其实都会聊聊有哪些一直在做的尝试，今年我觉得自己做的比较好，并且有进步的方向则是“尝试和自己的焦虑一起相处”，虽然没有特别大的进展，但是我觉得还是有一点点的细小收获。

俗语里总说“五十而知天命”，大概就是要论证人们在某一个年龄忽然明白了理想实现之艰难，故而做事情不再追求结果，在五十岁之前，会全力以赴希望有所成就，而在五十岁之后，虽然仍是“发愤忘食”、“乐以忘忧”，但对个人荣辱已经淡然。

这几年互联网（甚至很多行业）都在疯传 35 危机，说随着不断毕业的年轻血液进入之后，企业方会更愿意用年轻的，能熬夜加班的，能抗住更大压力的，有更强目标感的年轻伙伴来替代那些到了一定年纪的，有房贷车贷的，需要一人养家的中年砥柱。于是很多人不免发现身边的工作氛围和环境变得越来越差，前些年是虽然奸臣当道，但大抵踏实做事还是能看到回报，现在则是大家都是等待收割的稻草，哪怕你身强力壮，但都是过着一样望到头的日子。

人的生老病死一直都是无法影响的客观规律，这也是很多获得一定财富的人都愿意投入更多的资源和精力去探索延缓衰老和死去的问题。今年回家过年的时候忽然发现“爸妈在一瞬间真的老了”，眼神没有之前好了，开始时不时出现健忘的问题了，人们好像都说人的年级越来越大之后，就会显得越来越小，这可能也是某种意义上人的生命是一圈轮回的象征。

这件事对我的启发是什么呢？可能在某个角度来说，我们就是要接收自己的平庸？或者说要意识到大多数自己都是平庸的，刚毕业的时候我们恨不得要翻天覆地做出一番大的改变，记得那会我恨不得每一年都拿优秀员工，加班和快速响应几乎已经成为了习惯，但现在发现还是要把时间和精力放在过好自己的小日子上，不要因为工作中那些“2 个小时以后”的事情占据我太多的情绪，很多事情确实尽力了就是尽力了，但尽管你尽力了也对结果的影响无足轻重，对吧。

那句话怎么说来着？“功成不必在我，成事必定有我”，“工作中少我一个无所谓，生活中我非常重要”。

祝我生日快乐，也祝每一个人在 31 岁的时候都能生日快乐。

第三次到苏州，除一次因出差短暂停留苏州外，前后已相隔12年。重游苏州，再来看看这江南水乡和苏州园林。不料初八已经上班了都还是那么多游客，实在低估了，给拍照增加了很大的难度，也非常影响静心欣赏园林雅致的景色。这次把苏州四大园林都逛了一遍，未来一两周会整理更新上来。

下榻的酒店意外的高，入住到27楼，姑苏城风景尽收眼底，北寺塔巍然耸立，让人大爱。第二天早上一直等到第一缕阳光照进姑苏城，我拍完照片，才满意的去吃早餐。

摄于2025年2月5日，苏州七里山塘和平江路，By iPhone 12 Pro Max

听到阳台外烟花声不断，想起春节期间我也“烧钱”不少，于是掏出手机选了两张照片，祝大家元宵节快乐！吃过汤圆，甜蜜美满！