2025-06-05 19:08:09

数字世界的创作和内容，最重要的是程序和视频。程序负责逻辑、互动；视频负责信息的表达、感知。

2024年2月 Sora 概念发布，6月可灵发布，AI 视频开始发展。同年 6月 Claude 3.5 Sonnet 发布，8月 Cursor 接入，AI Coding 开始狂奔。

回想起来只过了一年时间，但已经经历了很多的变化，想探讨一下这两个核心 AI 领域的演化可能性。

现状：作为生产力工具的 AI

AI Coding

AI Coding 短期已经达到生产可用，能显著提升程序员 Coding 效率，长期还是 AGI 本身核心的能力，有现在也有未来，自然是最热门的方向，Cursor / Windsurf / Lovable / Augment 层出不穷。

AI Coding 除了给程序员提效，也开始覆盖到其他互联网从业者，设计师/产品/运营/自媒体 等，让原本不会写程序的人 0 门槛通过 AI Coding 做出 demo 和场景，带来 0-1 的新体验。

但目前这些应用，核心是提效。没有 AI Coding，程序员也能写出一样的程序，产品/设计师等也能跟程序员合作快速做出 demo，从产物的形态/目的角度看，做出来的东西没有本质的变化，只是有了 AI Coding，效率提高了一个级别。

AI 视频

AI 视频过去一年 可灵/即梦/Runway/Veo 等模型持续进化，指令遵循、画面稳定性一直在增强，在一些场景达到了生产可用，提升了 CG 制作、商品广告等视频场景的生产效率。

AI 视频也覆盖到广大自媒体用户，以前需要一个 CG 团队才能做出来的视频，现在一个人可以创作出来，例如橘猫/风格化视频等，给创作者带来 0-1 的新体验，发布到小红书/抖音等平台获利，AI 视频部分代替了基于摄像头实拍的内容，成为新的一种生产力工具。

AI Coding 和 AI 视频作为生产力工具毋庸置疑会带来巨大的价值，也是现在正在发生和快速增长的。

不确定的是，随着能力的持续提升，使用的门槛的持续降低，AI Coding 和 AI 视频的使用人群是否能进一步覆盖更广到亿级大众用户，带来生产力目的以外新的东西，催生新的偏社交/娱乐的内容平台？

大众化和新平台的可能性

类比

从历史上找，有两个可类比的领域：

拍摄

• 拍摄从早期专业人士才能操作，到现在大众化的手机拍摄，创作工具能力极大提升，带来门槛极大降低，普惠到大众，催生新的内容和平台。
• 现在专业摄影仍然继续存在于电影电视/广告/艺术等行业，而大众化的拍摄存在于日常生活，脱离了生产力，催生了 Instagram、抖音、朋友圈等这些新的内容和社交平台。
• 可以想象，AI Coding 和 AI 视频随着门槛降低也可能可以覆盖到大众，催生新的平台。但拍摄的演进过程中伴随了其他巨大的变量：设备和环境的迁移。电脑、互联网、手机设备，与工具的低门槛一起催生了现在的形态，AI 创作只有门槛的降低，缺乏其他大的变量。

3D打印

• 3D 打印技术的发展，让从以前工厂才能生产实体制品，到 3D 打印的技术发展让每个人都能生产实物制品，3D打印的产物有社交价值（分享/炫耀）、实用价值（3D 打印常制作出工具解决问题），但目前没有内容价值，还是只存在于小众圈子内。
• 与 AI 创作类似的是，3D 打印的发展是纯工具低门槛化，没有其他变量；差别是 3D 打印是实体世界，与数字世界的规模化扩展性差异巨大。

从类比上并没有特别适配的案例，但不妨碍 AI Coding 和 AI 视频有自己的大众化和演进路径，我们先看看如果工具要大众化和催生新平台，需要什么条件。

消费价值与内容形态

一个工具要大众化，门槛持续降低是必要的但不充分，创作的核心是消费，大部分人有创作欲，但纯粹的创作欲是小众，创作欲更多是社交认同、利益驱动。如果不能分享，大家不会好好拍照，如果没有利益，短视频创作者不会那么多。所以工具要大众化，核心还是创作的内容有高的消费价值，包括消费频次。

但即使人人都创作和分享，也不一定需要新的平台承接，创作产物的形态没有变化，消费场景(硬件/环境)没有变化，原来的社交/内容平台也足以承接。要诞生新的平台，还是得有不同的消费场景或不同的内容形态，导致原来的平台没法很好地承接。我们不考虑新硬件的情况下，主要就看内容形态。

沿着消费价值和内容形态，看看 AI Coding 和 AI 视频的情况。

AI Coding

AI Coding 的产物归类到源头可能就三种：工具、内容容器、游戏。我们拆开来设想一下：

1. 工具：可供大众使用的工具可复用性高，个性化程度低，当前程序员和APP/Web/小程序的量级已经足够大，更多的人群进来用 AI Coding 做小工具，在硬件设备和环境没有变化的情况下不会有太多新的花样，很难出现质变，消费价值和创作频次都不会很高。
2. 内容容器：个人网站、简历、报告、方案等是这一类。借助 Coding 让内容呈现形态多样化，这也是初期可能最容易人人参与创作出来的东西。但这类的核心是内容而不是代码，只是在内容呈现上可能有个20%的体验提升，Coding 的作用不会太大。要说这一类有什么一定要 Coding 才能满足，那就是交互，如果重交互的内容场景和需求足够多，是有希望的。
3. 游戏：游戏的核心是代码，人们对游戏玩法有无限的需求，用户消费频次够高，范围够广，这可能是最有希望的品类。产物不一定是现在形态下的一个个独立小游戏，可能是更看重创作和生成过程的游戏，同时又有消费价值，具体是什么不知道。只是游戏相对复杂，当前 Coding 能力还不够，还没看到苗头。

有足够的个性化差异的可交互产品/游戏，是 AI Coding 可能的出圈点。比如，以个人形象为主角的、融入了自身经历的小游戏；比如，一个可以在里面不断做个性化扩建的自由世界，像“我的世界”。如果有这些新的形态，就会催生一个新的内容平台去承接这一类产品。

AI 视频

AI 视频的产物应用涵盖太广，难以细拆，但近期也看到一些大众化和新形态的可能性：

1. 日常表达：AI 视频是想象力的相机。我们的日常表达，一部分通过摄像头记录和分享，另一部分心情的传达，比较难通过摄像头，在以前更多通过文字，以后可能更多通过 AI 这个想象力的相机。它能把你本来只能用文字描述的心情和感想，转成更容易引起共鸣的画面。近期在抖音上火了一阵的 像素风 AI 视频，就是这种感觉。（印象较深的是，勇士队输掉季后赛的那天，看到了一个像素风视频很好表达了郁闷/不甘的心情，很有共鸣，这种心情用真实的图片视频和文字都很难表达）
2. 可交互视频：最近看到 odyssey 发布了可交互视频，40ms 生成一帧，根据用户行动实时生成下一帧，体验上像玩游戏一样。可交互视频可能是 AI 视频生成新形态的关键，它不一定是非常实时的交互，比如看一个剧，可以自己修改剧情走向，看到视频里的一个场景，可以进去这个场景无限扩充看它整个空间，都是可能的场景。

日常心情表达是 AI 视频很能大众化的场景，消费价值和消费频次高，但催生不了新平台，生成的视频都会回到原来的内容/社交平台上。可交互视频这种衍生的形态，才会需要一个新的平台去承接。

新形态的核心：交互

看下来无论是 AI Coding 还是 AI 视频，交互 都是新内容形态的关键点。

因为这波 AI 浪潮是生成式 AI，生成的产物都是业界已有的形态，如果只看生成的产物，在没有新的硬件设备、使用环境等其他变量的情况下，只会有生产效率的提升，很难诞生新的内容形态和平台。

生成式 AI 真正独特的地方，是生成的过程。需要用户频繁通过生成产生交互的场景，才会是新的内容场景，才能产生新的内容形态。

AI Coding 和 AI 视频都有在各自领域里通过交互产生新的内容形态的可能。另一种可能是，这两者做进一步的结合，逻辑+画面都实时生成，不断创造的可玩的虚拟世界，可能又能回到元宇宙的概念。

这些新的形态和玩法，可能会像当时 Snapchat 刚出来时大家看不懂，难以理解，但就是能戳中年轻一代的诉求，值得探索和期待。

2025-04-27 18:15:26

是评测，或者说是基准测试(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/

2025-04-07 20:29:23

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 上下游相关配套基建都处于起步阶段，小团队很有机会把其中某个点做出彩。

2025-03-28 21:50:29

参加了 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 搞渲染出身，渲染里三角形是最基本单元，所以办公楼都是三角形元素。办公环境很宽敞，但没啥人，总部居家办公没有限制，很多都不来公司。

2025-03-24 15:58:50

参加 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 的上限，应该是需要专有模型并能支持端到端训练的形态，待探索。

2025-03-16 13:42:45

近期在业务中尝试落地 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 是新东西，后续实践有认知的更新再分享。