MoreRSS

site iconbang修改

JSPatch 开发者。88年生于广东陆丰,毕业于华南师范大学,程序员,喜欢做东西。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

bang的 RSS 预览

Agent 模型的思维链是什么

2026-01-12 16:45:08

关于 Agent 模型的思维链,之前被几个高大上的词绕晕了,claude 提出 Interleaved Thinking(交错思维链),MiniMax M2 追随和推动标准化,K2 叫 Thinking-in-Tools,Deepseek V3.2 写的是 Thinking in Tool-Use,gemini 则是 Thought Signature(思考签名)。了解了下,概念上比较简单,基本是一个东西,就是定义了模型思考的内容怎样在 Agent 长上下文里传递。

是什么

在25年年初 deepseek 的轰炸下,思考模型大家都很熟悉了,在 Chatbot 单轮对话中,模型会先输出思考的内容,再输出正文。再早的 GPT-o1 也一样,只不过 o1 不把完整的思考内容输出。

在 Chatbot 进行多轮对话时,每一次思考的内容是不会再带入上下文的。每次到下一轮时,思考的内容都会被丢弃,只有用户 prompt 和模型回答的正式内容会加到上下文。因为在普通对话的场景下没必要,更倾向于单轮对话解决问题,长上下文会干扰模型,也会增加 token 消耗。

这些思考模型用到 Agent 上,就是下图这样,每次模型输出工具调用,同时都会输出 thinking 内容,思考应该调什么工具,为什么调,但下次这个思考内容会被丢弃,不会带入上下文:

这不利于模型进行多轮长链路的推理,于是 claude 4 sonnet 提出把 thinking 内容带入上下文这个事内化到模型,以提升 Agent 性能,上下文的组织变成了这样:

就这样一个事,称为 Interleaved Thinking,其他的叫法也都是一样的原理。

为什么要带 thinking

面向 Chatbot 的模型,倾向于一次性解决问题,尽量在一次 thinking 一次输出解决问题。

Agent 相反,倾向于多步不断跟环境( tool 和 user )交互解决问题。

Agent 解决一个复杂问题可能要长达几十轮工具调用,如果模型对每次调用工具的思考内容都抛弃,只留下结果,模型每次都要重新思考每一轮为什么要调这个工具,接下来应该调什么工具。这里每一次的重新思考如果跟原来的思考推理有偏移,最终的结果就会有很大的出入和不稳定,这种偏移在多轮下几乎一定会发生。

如果每一轮调用的思考内容都放回上下文里,每次为什么调工具的推理逻辑上下文都有,思维链完整,就大大减少了模型对整个规划的理解难度和对下一步的调用计划的偏差。

有没有带 thinking 内容,对效果有多大差别?MiniMax-M2 提供了他们的数据,在像 Tau 这种机票预订和电商零售场景的任务 benchmark 提升非常明显,这类任务我理解需要操作的步数更多(比如搜索机票→筛选过滤→看详情→下单→支付),模型在每一步对齐前面的思路很重要,同一个工具调用可能的理由随机性更大,每一步的思考逻辑带上后更稳定。

工程也能做?

这么一个简单的事,不用模型支持,直接工程上拼一下给模型是不是也一样?比如手动把思考内容包在一个标签(<think>)里,伪装成 User Message 或 ToolResult 的一部分放在里面,也能达到保留思考的效果。

很多人应该这样做过,但跟模型原生支持还是有较大差别。

工程手动拼接,模型只会认为这部分仍是用户输入,而且模型的训练数据和流程没有这种类型的用户输入和拼接,效果只靠模型通用智能随意发挥。

模型原生支持,训练时就可以针对这样规范的上下文训练,有标注大量的包含思考过程的 trajectory 轨迹数据训练,响应的稳定性必然会提升,这也是 Agent 模型的重点优化点之一。

签名

上述工具调用的 thinking 内容带到下一轮上下文,不同的模型做了不同额外的处理,主要是加了不同程度的签名,有两种:

thinking 内容原文,带签名校验

claude 和 gemini 都为 thinking 的内容加了签名校验,带到下一轮时,模型会前置判断思考内容有没有被篡改。

为什么要防 thinking 内容被篡改?毕竟 prompt 也可以随便改,同样是上下文的 thinking 内容改下也没什么。

主要应该是篡改了模型的 thinking 内容会打乱模型的思路,让效果变差,这也是需要避免的。

另外模型在训练和对齐时,已经默认 thinking 是模型自己的输出,不是用户随意的输入,这是两个不同类型的数据,如果实际使用时变成跟Prompt一样可随意篡改,可能有未知的安全问题。

不过国内模型目前没看到有加这个签名校验的。

thinking 内容加密

claude 在一些情况下不会输出自然语言的 thinking 内容,而是包在redacted_thinking里,是一串加密后的数据。

而 gemini 2.5/3.0 的 Agent 思维链没有明文的 thinking 字段,而是 thought_signature,也是一串加密后的数据。

用这种加密的非自然语言数据,一个好处是,它可以是对模型内部更友好、压缩率更大的数据表述方式,也可以在一些涉及安审的场景下内容不泄露给用户。

更重要的还是防泄漏,这就跟最开始 GPT o1 不输出所有思考内容一样,主要是为了不暴露思考过程,模型发布后不会太轻易被蒸馏。

最后

目前 claude 4 sonnet、gemini 3 在 Agent 工具调用的场景下,都强制要求带工具调用的思考内容和签名,这个链路正常是能很大程度提升整体的推理执行效果,是 Agent 多步骤推理的必需品。

但目前 Agent 模型的稳定性还是个问题,例如在某些场景下,业务逻辑明确需要下一步应该调工具 A,但模型思考后可能就是会概率性的调工具B,在以前是可以直接 hack 替换调工具调用,或手动插入其他工具调用,没有副作用。

但在思维链这套机制下比较麻烦,因为没法替模型输出这个工具调用的思考内容,一旦打破这个链,对后续推理的效果和稳定性都会有影响。

可能模型厂商后续可以出个允许上层纠错的机制,例如可以在某个实际告诉函数工具选择错误,重新思考,原生支持,弥补模型难以保障稳定的不足。

密码保护:2025

2025-12-31 20:50:31

此内容受密码保护。如需查阅,请在下列字段中输入您的密码。

Agent 模型怎么训练?学习 Kimi K2 论文

2025-08-06 00:33:33

在 Agent 使用的模型上,Claude 一直独一档,Deepseek、豆包、Gemini 等模型跟它都有很大差距,很多号称 benchmark 接近和超过 Claude 的实际效果都不行。

K2 出来后在 Agent / Coding 相关的 benchmark 上效果很不错,同时也在一些 Agent 场景上试了下,实际体验是不错的,值得学习下它是怎么做的。

它的技术论文《KIMI K2: OPEN AGENTIC INTELLIGENCE》公开了模型训练过程的一些信息,一起学习下。

概览

K2 几个重点:

  1. MuonClip 优化器,支持了万亿参数级别的模型预训练能稳定进行。
  2. 大规模构造 agent 合成数据。
  3. 通用的强化学习框架,不仅适用于对有明确对错的任务(数学/逻辑/代码开发等),也适用于开放型任务(写作、多轮对话等)。

分别对应大模型训练三部曲:预训练,SFT,强化学习。论文分别阐述了这三个阶段做了什么。

预训练

这部分介绍了训练 K2 基础模型的架构设计、优化器创新、数据增强处理,以及训练的硬件配置和调度。

架构

模型架构遵循 DeepSeek V3 的架构,只是调整了一些关键参数,1.04万亿(1000B) 参数量的 MoE 模型,激活参数32B。

MoE(Mixture of Experts) 架构能做到高性能低成本,基本要成为 LLM 标配。 模型参数量越大,模型在训练过程中能存储的信息量就越多,模型聪明程度越高,这是 scaling law。但参数量越大,使用模型的推理成本就越高。 MoE 架构可以设计参数量很大的模型,但在推理时,每一个 token 都会被路由到到其中几个子模块(称为专家)去处理,只有少量参数参与了计算。 这也是为什么之前 DeepSeek 的成本很低的原因之一。K2 1000B 的参数量级,激活参数 32B,相当于它的推理成本跟 32B 大小的模型差不多。

跟 DeepSeek V3 的差异是调整了一些关键参数,比较细节了,特别提到两个点:

  1. 高稀疏性(MoE 专家数量多但激活很少)的设计能在同样计算量下让模型表现更好,但专家数量多有成本,K2 选了一个性价比高的稀疏性数值来平衡效果和成本。384个专家激活8个。
  2. 注意力头 (attention heads,可理解为对输入向量的拆分) 多了对效果提升有限,反而在处理长文本时会慢,不划算。把注意力头从128降到64。

模型架构做的事不多。

MuonClip 优化器

预训练阶段 K2 最大的创新点在 MuonClip 优化器,花了较大篇幅介绍。简单从基础概念出发理解下它做了什么:

  1. 优化器:模型训练过程中会不断调节参数,优化器会决定如何去调整这些参数,让模型能更快、更稳定地收敛到一个较好的状态
  2. Muon:是一种优化器,算法原理还挺复杂不展开,简单说它的作用能在保证一定准确度前提下提升训练速度,能比常用的 AdamW 优化器更快地完成训练任务。
  3. MuonClip:Muon 虽然训练速度快,但容易不稳定,理解为可能会一下把模型参数调整得太猛,无法收敛回来,训练崩溃。越大的模型会越容易出现这个问题,K2 万亿参数下更是容易。MuonClip 解决这个问题,简单理解是在 Muon 基础上增加了一个叫 QK – Clip 的裁剪器,超出阈值时做好调节,避免训练的大幅波动。

数据处理

预训练中有个 token 效率的概念,每个 token 对模型更新的影响越大,token效率越高,数据处理目标提高 token 效率,其实就是提高数据质量。

K2 有 1.5 万亿 token 的数据去训练,极端假设这1.5万亿 token 都是一样的,那模型什么也学不到,token 效率很低,如果 1.5 万亿 token 均匀包含了每个领域多样性的数据,token 效率就高。

K2 做了几个事提升 token 效率:

  1. 对知识领域的数据,用 LLM 以不同的风格和视角重新生成一份数据(可以理解为蒸馏了某个 LLM 的文风?),还细化了重写方法:分块重写每一段最后拼接在一起,以及有检测模型确保重写内容与原始内容一致。
  2. 对数学数据进行重写,遵循 SwallowMath 数据集里的方法,包括去掉题干冗余描述、补全上下文、繁琐的解答重写为简洁连贯分布逻辑、确保格式统一。

互联网数据已经用完的情况下,如何在这些数据里清洗重组出多样和高质量的数据,提升预训练效果,是持续可以做的事。

SFT

除了常规的高质量标注数据做 SFT,K2 专门针对 Agent 场景创建了一套合成数据的流程,能造出大量高质量的 Agent 对话轨迹数据(trajectory),对预训练模型进行 SFT,让模型学会 agent 任务规划/调用工具/环境反馈相关的套路/格式/规则。

这个流程分三步:

1. 造工具(Tool spec generation)

  1. 从github 爬3000+个 MCP 工具,作为数据集之一
  2. 选一些关键类别(比如金融交易、软件应用、机器控制),每个类别演化出多个应用领域(比如股票交易、开发者工具、工业机器人)。
  3. 为每个领域创造一些新的工具:用 LLM,基于上面 MCP 工具的定义和规范,创造出工具的接口、描述、操作语义,确保各个类别和领域数据的多样性。例如下面这样的工具,一共造 20000 多个:
{
//仅示例,非实际定义的格式
name: "financial_db_search",
description: "查询金融数据库中的产品信息,支持股票、债券、基金的基本数据(如代码、名称、价格、发行量)及历史交易数据(如近30天收盘价)",
// 输入参数的JSON Schema定义(约束模型传入的参数格式)
properties: {
type: "object",
required: ["product_code"], // 必选参数
properties: {
product_code: {
type: "string",
description: "产品代码,如股票代码(A股:600000.SH,美股:AAPL)、债券代码(019547.IB)"
},
time_range: {
type: "string",
enum: ["latest", "30d", "90d", "1y"],
default: "latest",
description: "查询时间范围:最新数据(latest)、近30天(30d)、近90天(90d)、近1年(1y),默认返回最新数据"
},
}
}
}

2. 造 Agent 任务(Agent and task generation)

  1. 合成各种系统提示词,从上面两三万个工具库中配备不同的工具组合,生成几千个 Agent。(system prompt + tool set = Agent 定义,这里怎样去做工具配备没详说,应该是由 LLM 加一些流程完成。)
  2. 基于每个 Agent,生成简单到复杂的各类任务,每个任务都配有明确的评分标准,规定了任务成功指标、预期的工具使用和中间的检查点。

3. 造对话轨迹(Trajectory generation)

  1. LLM生成具有不同沟通风格和偏好的用户角色,跟上述 Agent 进行多轮对话。
  2. 对话过程中,Agent 会调用工具,但上述生成的工具只有 spec (接口定义/描述),并没有真正的实现,所以做了一个工具执行模拟器,用 LLM 模拟调用了这个工具给出结果返回过去。
  3. 也有部分工具不是调工具模拟器,会针对比如软件编码任务,给一个真实的调用环境,真实地执行实际工具调用代码,返回数据。
  4. 会有裁判 LLM 去评估这里生成的对话记录的质量,符合要求的才会挑出来作为训练数据。

最终造出的数据示例:

//仅示例,非实际定义的格式
<|system|>
你是金融股票专家,可调用工具:stock_quote(查实时行情)、industry_trend(查行业趋势)
[{
      name: "stock_quote",
      description: "查询金融数据库中的实时行情",
      properties: {
	      product_code: {
            type: "string",
            description: "股票代码..."
        },
			}
}, { ... industry_trend}]
<|/system|>

<|user|>帮我看看宁德时代(300750)现在的股价和涨跌幅。<|/user|>

<|assistant|>需要查询宁德时代的实时行情。<|tool_call|>{"name":"stock_quote","parameters":{"code":"300750","fields":["price","change"]}}<|/tool_call|><|/assistant|>

<|tool_response|>{"code":"300750","name":"宁德时代","price":118.50,"change":"+2.3%","time":"09:45"}<|/tool_response|>

<|assistant|>宁德时代(300750)当前股价118.50元,涨2.3%(截至09:45)。<|/assistant|>

<|user|>那新能源板块这周表现怎么样?适合加仓吗?<|/user|>

<|assistant|>用户想了解新能源板块周趋势,需调用行业工具。<|tool_call|>{"name":"industry_trend","parameters":{"sector":"新能源","period":"week"}}<|/tool_call|><|/assistant|>

<|tool_response|>{"sector":"新能源","period":"week","trend":"上涨5.2%","hotspots":"储能/充电桩","risk":"政策不确定性"}<|/tool_response|>

<|assistant|>新能源板块本周上涨5.2%,储能和充电桩领涨,但需注意政策不确定性。短期可少量加仓,建议持仓不超过总资金的15%。<|/assistant|>

总的来说,通过少部分真数据和大部分合成数据,去造出大量模拟 Agent 对话轨迹的高质量数据,数据量原文说是数以万计,也可能不止。这些数据可以直接用于 SFT,让模型学会 Agent 需要的多轮交互推理、工具调用能力。

这里造数据用到的 LLM,猜测是 claude sonnet 4,算是蒸馏了 claude 的 agent 能力?

强化学习

强化学习阶段讲了很多策略,核心是通用的给训练环境、造任务、定义奖励模型。对于可验证奖励的任务,有多种不同验证策略,创造和引入大量的任务做训练;对于不好验证奖励的任务,用自我评判的方式去选更好的输出;另外也介绍了算法上的几个小优化策略。

可验证奖励任务

给模型的强化学习搭建了一个训练场(Gym),设计了各种有明确对错标准的任务,让模型在里面学习。

  1. 数学题、理科推理题:收集大量数学、科学、逻辑题,也包括数独、密码破译等逻辑题,补全冷门的领域的题目(这个好像比较常规?)。清洗数据,用模型筛掉太难和太简单的,留难度适中的题目,模型练了能进步。
  2. 听懂复杂指令:
    1. 对一些可验证输出的 prompt case,LLM 生成结果检测的代码去做检测。比如“生成小故事,别太长”,LLM 生成一个检查结果字数的函数,超过200字就扣分。
    2. K2 数据团队自己造了一波复杂的 prompt 和这波 promot 的评判规则数据。
    3. 参考 AutoIF 指令扩充,输入一小批人工指令,用 LLM 自动生成更多变体,形成丰富复杂和可验证的指令集。例如指令“7加9加8等于多少”,扩写成“计算把7加到9上,再加上8,等于多少”之类的形式,并生成 python 代码去测试输出的答案是否正确。
  3. 说真话:参考 FACTS Grounding 的做法,训练了一个忠实度判定模型,能识别每个句子对事实的遵循度,作为奖励模型之一。比如模型说参考表1 数据X,实际上表1并没有数据X,就扣分。
  4. 编程和软件工程能力:编程上包含各种竞赛题目,额外给这些题目找了对应的单元测试。软件开发方面,跟 SWE-bench 的做法一样,扒了 github 上大量的代码修复 case,issue 描述扔给模型生成修复代码,搭建了环境支持运行代码单源测试,测试结果作为奖励模型。
  5. 安全:收集一堆危险问题(暴力/色情等)让模型学会拒绝回答。用一个 LLM 模拟生成一些绕过安全规则的问题(比如扮演角色/讨论正经问题过程中混入危险问题),让 K2 回答,再用另一个 LLM 去判断 K2 的回答是否危险,做好引导。

总的来说,就是各种造数据,定义奖励模型,让模型靠近我们想要的结果。

自我评判机制

上面基本是能定义好奖励模型的任务,接下来是对不太好衡量结果的任务怎么进一步提升,例如回答有没有帮助、有没有创意、推理深度够不够等。

这种要不就是人类标注数据,要不就是用 LLM 评估结果。K2 这里大致的意思:

这里大意是让 K2 自己对自己的输出好坏进行评判:

  1. 在预训练和 SFT 阶段,给 K2 喂相关的人类标注能用于评判好坏的数据,让模型初步有评估好坏的能力。
  2. 强化学习阶段,给 K2 输入我们的偏好(system prompt),包括核心价值(例如表达要简洁、逻辑要连贯、保持客观等)和规范(例如不要在开头迎合用户赞美),让它去评判自己输出的内容符不符合我们偏好。
  3. K2 的评判能力会在训练过程中也不断提升,因为同时会拿它去评判之前提到的那些可验证结果的问题,它如果评判错了也会纠正参数去提升评判能力。

算法策略

介绍了几个算法上的小策略:

预算控制:RL 只看最终结果是否能得到奖励,所以模型会倾向于输出更多的内容,更多的内容意味着更高命中答案的概率,但对很多任务来说是没必要的。K2 对不同任务类型设了输出 token 限制,超出会惩罚,引导模型输出简洁有效的回答。

PTX loss(Pre‑Training Cross‑Entropy) :OpenAI 在 RLHF 提出的,RL 过程中避免模型对原先能力的遗忘,K2 准备了一份高质量数据,训练过程会时不时加入评估,如果模型对这些数据效果变差了,就惩罚,让学习更稳健。

温度衰减(Temperature Decay):温度在大语言模型里是指激进输出还是保守输出,更细的理解是 next token 推理时是直接选概率最高的(保守),还是随机选前面几个(激进多样)。温度衰减是训练前期先激进多尝试不同方向,后期保守收敛,保持输出稳定。

其他

强化学习相关就这些,对 Agent 推理能力起作用的,是可验证奖励模型里的 2-让模型理解复杂指令和 3-输出遵循事实,以及自我评判机制让模型输出推理深度更好。对 Coding 能力起作用的,基本就是编程和软件工程能力。

这些方法应该都多少在各种论文上出现过,但能不能做得好,数据质量怎样,中间有多少细微的策略调整,就看细活了。

整个模型训练基本就这样,其他的内容就剩下各种 benchmark 评估了,不再列。

感受

看完什么感受?

  1. 整个论文工程同学是能看懂大概的,算法公式比较少,我理解主要是大模型算法结构已经固定,让实用性大模型训练更偏向是一个系统优化工程,而不是创新算法项目。
  2. 感觉友商看了这论文也没法快速复刻,因为用的很多方法似乎多少有在各种论文上出现过,小部分是特别的算法策略,影响模型效果的应该在每一个策略和数据构造处理的细活上。也许某一个策略和数据是对模型效果影响很大,但论文没提到。
  3. K2 很厉害,值得敬佩,它目的也是造一个 Agent / Coding 能力好的实用性模型,策略做法都很强。只是感觉只靠这些策略模型没法突破上限,scaling law 没有继续突破,thinking 模式的 test time scaling 被抛弃,最近模型惊艳的进展基本来自于多模态模型,纯文本 LLM 下一个突破不知在哪里,等 OpenAI 了。

AI Coding 与 AI 视频:从生产力工具到大众内容平台

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 刚出来时大家看不懂,难以理解,但就是能戳中年轻一代的诉求,值得探索和期待。

做好 AI Agent 最重要的是什么

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 MultimodalAgentBenchSWELancer 这些基准测试在不断推出试图覆盖。

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

目标不明确的任务

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

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/

Browser Use 原理解析-为一个小项目能融1700万美元

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