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

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

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 热门项目上抽取相关的数据，这些数据还可以持续更新，避免模型因为看到过这些数据而“作弊”。

（更多…）

背景

DeepSeek 里程碑式的爆火，有必要学习下是怎么回事。

大语言模型的发展，之前一直是以预训练为主，虽然性能一直在提升，但主要是小修小补，跨越式的 GPT5 一直出不来。OpenAI 在 24 年 9 月发布的 o1 提出了新的路线：在预训练好的模型上，用强化学习做后训练，能显著提高模型推理能力，其效果在解数学、编码等问题上屠榜。

但 o1 只说了强化学习能让模型学会思维链的方式提升推理能力，其他的发现都没有公布，加上 o1 一直是期货，12月才正式推出，200美元一个月，普通人都用不上，充满神秘。

而 DeepSeek 自主研发了通过强化学习让模型学会思维链提升推理能力，性能逼近 o1，加上之前 DeepSeekV3 在预训练基础模型上的创新，推理成本也显著低于 o1，直接推出全民免费可用媲美 o1 的模型，甚至在一些中文语境下效果显著超过 o1，大众用户一用感受到 NB，业内人士震惊它的创新能力纷纷学习，美国人民恐慌中国 AI 的发展有超越美国引领技术潮流的可能性，结合大国叙事，爱国情怀，各种元素综合下各觉得都会乐此不疲地研究、使用、讨论，引爆全网。

接下来一步步精读下 DeepSeek-R1 的论文 《DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning》了解现象级 R1 模型是怎么做出来的。

R1 论文

DeepSeek R1 是基于预训练好的 DeepSeekV3 基础模型进行的后训练优化，V3 做了很多创新优化，很大降低了预训练模型和模型推理的成本，是 R1 的基础，这里先不讨论 V3，只看 R1 在 V3 基础上做了什么后训练。

在 DeepSeekR1 这篇论文里核心做的三个事：

1. R1-Zero：首个证明只通过 RL 而不通过 SFT 就能让模型涌现推理能力。
2. R1：新的强化学习后训练范式。
3. 蒸馏：蒸馏显著提升小模型能力，小模型有潜力。

我们一个个具体看下这三个事。

R1-Zero

R1-Zero 证明了对已预训练好的模型，不需要经过 SFT，只需要纯粹的 RL，就能让模型涌现 CoT 推理能力。

SFT是监督式微调，也就是准备好一堆标注好的数据，让模型去学习拟合，可以粗略理解为刷题，大量的刷题学习能解决类似的题目；

RL是强化学习，只告诉模型什么是好的什么是不好的，过程中模型自己学习怎么达到目标，可以理解为不靠刷题，自己去理解探索数学和世界的规律，理论上灵活性强，上限更高，还有可能探索出人类未知的能力。

强化学习首次出圈是 AlphaGo，AlphaGo 先学习人类棋谱，再用强化学习自我对弈进化，而随后的 AlphaGo Zero 没有人类棋谱，只定义好围棋奖励规则，模型自己学习怎么下，达到更高的水平。R1-Zero 这命名也是致敬 Alpha-Zero，因为它们非常类似，脱离人类的指导自主发现规律提升智能。

为什么之前没人做到？

1. 模型能力没达到一定阈值，仅通过强化学习没法涌现。
2. 强化学习是种方法，过程中用什么算法做价值判定也很大程度影响效果
3. o1 可能已经做了同样的探索和结果，也可能没有，它闭源不公开，而 DeepSeek 首次探索并公开了。

GRPO vs PPO

R1-Zero 最大的不同，是在强化学习中使用 GRPO 算法代替 PPO。GRPO 算法也是 DeepSeek 团队在 24 年 2 月《DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models》这篇论文提出的，其核心思想可以理解为两个字：内卷。

简单来说，PPO 是用一个模型去评估当前输出的收益，模型觉得这个输出好，就更新参数往这方向靠近，类似四六级考试的判定，有个分数线，过了就好，不过就不好；GRPO 是让模型一次性输出一组数据，在这组数据中选得分最高的，让模型逐步靠近得分高的输出，类似高考的内卷选拔，你只要比同龄人好，就是好。

更具体的可以看这张图：

图上的一些概念：

• Reference Model：预训练的大语言模型
• Reward Model：奖励模型，给定输入和输出，给出得分。可以是基于神经网络训练的模型，使用人类标注数据做训练；也可以是规则模型，定死一些规则做打分。这里的输入是大语言模型一次完整的输出。
• Value Model：对模型输出的每一步做一个预测，预测当前状态下后续能得到的收益。这里的输入是大语言模型每一次 token 的输出。
• Policy Model：我们正在训练的大语言模型。base 是 Reference Model，训练过程中会不断更新参数，得到我们最终需要的模型。
• GAE：Generalized Advantage Estimation 广义优势估计，评估每一个动作的好坏程度
• q：输入 question
• o：输出 output
• r：模型完整的输出经过 Reward Model 计算后的分数
• v：模型每一步的输出后的状态，经过 Value Model 计算后的价值估计值，用于评估当前 token 输出的好坏。
• KL：Kullback-Leibler divergence KL散度，衡量新策略(当前训练中的模型输出的结果)和旧策略(base模型输出的结果)之间的差异，保障训练中策略更新幅度不要过大，保证稳定性。

PPO 用 Reward Model 计算大模型完整输出的奖励分数(r)，过程中会跟原始模型的输出做对比(KL)，避免偏离太远。大模型每步 token 输出，都会经过 Value Model 判定输出对后续奖励的期望值(v)，经过 GAE 函数计算每步动作的好坏程度，更新我们在训练的大模型 Policy Model 参数。

GRPO 去掉了 Value Model，对每个输入(q)输出多个结果o1 o2 o3 …，奖励模型判断这些结果的好坏，从中选出最好的，更新模型参数。对算法和公式更详细的介绍，推荐这两个讲解：（1），（2）

GRPO 去掉 Value Model，带来了一些好处：

1. 大大降低计算成本，少了价值模型，训练过程的内存占用、计算量、整体效率都更好。
2. 更适合开放式的问题推理，不受限于价值模型判断的准确性。
3. 整个流程也更简洁优美了。

Reward Model

从上图可以看到，主要需要设计的只剩 Reward Model，R1-Zero 设计了一个基于规则的 Reward Model，之所以用简单的规则而不是基于神经网络的模型做奖励判定，一个是不需要训练，简化了流程和降低成本，一个是如果用神经网络模型作为奖励判定，如果这个判定模型不够强，可能会让训练的大语言模型钻空子作弊，效果不一定好。

主要是两个简单的规则：

1. 答案判断，如果是数学问题，会要求按格式要求输出最终答案，对比答案是否正确，对于 LeeCode 上的程序问题，会用编译器去判断能不能跑通对应的 test case。
2. 格式判断，有没有按照指定的格式输出内容，也就是思维链的内容在<think></think>里，输出的内容在<answer></answer>里。

训练模板

训练时会输入预置 prompt，让模型按格式要求输出。这个模板有意设置得很简单，避免带偏模型，也不会告诉模型要进行反思性推理或者其他推理策略，确保可以观察到模型在强化学习过程中自发去发现怎样的推理方式才是更有效的。

现象&结果

训练过程中两个重要的现象：

1. 输出越来越长：随着训练量的推进，输出的长度稳步加长，推理能力也随之提升。这也验证了 OpenAI o1 里提到的 test-time scaling，也就是更长的推理输出能更好提升模型推理能力，模型在强化学习过程中自主发现了这个规律。

2. Aha moment：训练过程中模型学会了停下来重新评估前面的思考，而且使用拟人的口气进行了反思。强化学习过程中人类没有输入任何类似的反思引导，模型能自主进行这种反思，十分有趣。我理解为，在预训练的模型里，模型已经有这样的反思意识潜力，在训练的某次输出过程中偶然出现，而出现后的结果对复杂推理有帮助，强化学习的机制会持续鼓励这样的输出。

训练的结果，在推理相关的 benchmark上，基本达到 o1 的水平：

R1-Zero 有非常有趣的发现，即不做监督学习，仅对预训练模型进行强化学习这条路是 OK 的，最终的模型有媲美o1的推理能力，但当前这种方式训练出的 R1-Zero 实际对外使用会有些问题，主要是对人不友好，比如输出的内容中英文混杂，猜测是奖励模型并没有做这种人类阅读友好的奖励判定，模型没理由能做好这块。

R1

为了做出一个推理能力强，输出对人类友好，综合能力 OK 的模型，DeepSeek 另外训练了R1模型。

整个流程可以可以看这图，图片来自 这个视频，顺便推荐这个视频的讲解。

这里做了两个阶段的后训练，每个阶段都是先 SFT，再进行 RL，只是数据和目标不同。

一阶段

1. 用少量的几千个包含了思维链推理的数据，对预训练模型做 SFT。虽然上面说 R1-Zero 不用 SFT 直接用 RL 也可以涌现推理思维链，但有少量精品数据做 SFT，RL 初期就能让模型生成可读性较好的结果，另外可能也能让训练冷启动效率更高，可以看这个视频感受下，在复现过程中，如果没有 SFT 直接 RL，前期要经历比较长的无效训练。
2. 用跟训练 R1-Zero 同样的步骤，用 coding、数学、科学、逻辑 这些推理密集的数据，对 SFT 后的模型做强化学习。这次强化学习的奖励模型里增加了对语言一致性的奖励，减少模型输出中英夹杂的概率，虽然加了后发现对模型的推理能力会有些下降，但还能接受。

二阶段

1. 用把上述强化学习后的模型，生成与推理相关的数据，并对这些数据择优，包括去掉语言一致性不行的case、去掉长篇大论的case、对同个问题生成多次并选择最好的一次，拿到质量相对好的60w个推理相关数据，加上另外收集标注的 20w 个跟推理无关，包含写作、事实性回答、翻译等数据，一起对模型再做一次SFT。R1 的中文输出很强，更大可能是跟这 20w 数据的质量高相关。
2. 把上述 SFT 后的模型，再做一次强化学习。这次强化学习具体没有展开，主要是引导模型安全输出，过滤有害输出，以及再次提升推理能力的一次训练。这次的奖励模型额外再加上了对通用内容的奖励，在文科内容、日常问答上，应该也准备了一些质量比较高的 case 和奖励规则模型。

这几个步骤后，R1 就训练完成了，可以看到这个基于 V3 模型的后训练过程成本是很低的，数据量不大，但效果非常显著，特别是在编码和数学问题上，R1 相对 V3 提升了几个档次。

而这个过程，看起来也是可以 scale 的，可以用这个训好的模型继续多步生成一些case，择优组成新的数据，继续进行 SFT 和强化学习。

这条显著提升模型推理能力的后训练路跑通了，公开解了 o1 一直遮遮掩掩的强化学习路线，也展现了很好的低成本持续 scale up 的潜力。沿着这条路走能 scale 到什么程度还不太清楚，拭目以待。

蒸馏

R1 训完了，最终我们用的就是上述训练出来的模型，但这篇论文还没完，DeepSeek 的同学发现用上述 R1 训练过程中生成的 60w 推理相关的数据，以及 20w 的额外数据去对小模型做 SFT，小模型性能的提升非常明显。

看起来这一步纯粹是用质量更好的数据对小模型做SFT，只是这些数据大部分是 R1 生成的，相当于是蒸馏提取了 R1 的能力精华，拟合了 R1 的能力，这样也能给小模型带来较好的推理能力提升。

从分数看，这些小模型在数学和 coding 上的性能是不错的，如果1.5b在部分场景上能有媲美4o的效果，那端上大模型会迎来一波应用潮。但实际用起来没那么理想，试过 1.5B 模型基本不遵循指令，有些刷分的感觉，但这仅是做了初步的SFT 后的效果，在这基础上对小模型继续进行强化学习，可能整体能力能有提升，也是值得期待的点。

这里论文上还额外做了另一个实验，用类似 R1-Zero 的方法直接对小模型做强化学习，实验效果是相对用蒸馏数据做 SFT 的方式，效果差很多。一个猜测是小模型就是能力有限，直接用强化学习达到顿悟和性能提升，得基于模型本身能力足够才行。

到这里 R1 论文内容结束了，结尾部分提到后续会在多轮对话、json输出、语言混合、提示词问题、写工程代码弱这些问题上提升的展望，解决这些只是时间问题。

复现

这篇论文介绍了 R1 整个算法、训练流程和结果，但最核心的应该是数据，包括用于 R1-Zero 的数据是什么，数据量有多大，生成的 60w 数据具体是什么样的，标注的 20w 文科数据是什么，这是决定模型效果的另一个核心因素，DeepSeek 的中文效果出圈，应该很大程度还是标注的 20w 文科数据质量高，不确定 RL 带来的推理能力提升在文科这块上的帮助有多大。这些数据没有公开，友商要复刻出 DeepSeek 的效果没那么容易。

网上有不少开始复现 R1 和 R1-Zero 的开源项目研究，最大的是 huggingface 的 open-r1，也有学生在 3B 模型上小规模复现 R1-Zero 的开源项目 TinyZero。

感受

1. DeepSeek APP 上线 20天 DAU 超过 2000w，成为历史用户增长最快的 APP，更让人感受到通用 AI chatbot 没有护城河可言，无论是国内的豆包、kimi，还是 ChatGPT、Claude，只要有更好的模型出现，用户瞬间转移不带留恋的。搜索是有技术积累的壁垒的，社交有关系链，内容平台有内容壁垒，基于 chatbot 形态的产品，没看到有什么壁垒，用户数据没有作用，曾以为模型领先就是壁垒，OpenAI 可以凭借领先收高额费用和大部分用户的忠诚，DeepSeek 这波又打破了这种壁垒，领先者无法保证自己一直领先。
2. DeepSeek 带来中国自信，曾经认为，类似 AICoding 这种全球无差异竞争的产品，国内同学们怎么搞得过海外那些清一色 MIT 天才搞的产品？DeepSeek 的成功叙事给了这些直面竞争产品很大的信心，这种信心下中概股都被疯狂拉动，还是很让人激动的。

使用

这两天有机会体验了下 Devin，感受到一些小小的震撼。

虽然之前已经用过 cursor 和 windsurf，它们用的模型都一样，理论上能完成的任务和智力是差不多的，但用 Devin 感受还是不太一样，有种 AGI 已经实现了的感觉。

Cursor 和 Devin 核心区别是交互范式，Cursor 是 Copilot，在你工作写代码过程中，实时辅助完成编程任务，而 Devin 是一个员工，交给他复杂任务后不用管它，它主动帮你搞定。可能现在这两者完成的很多任务是一致的，但体验有差异。

我试用的其中一个任务，是扔给它开源项目 JSPatch 的 github 地址，告诉它找个 issue 修一下。它会分解任务逐步执行，包括：

1. 访问 github 网站，浏览issue列表，随机看几个 issue 详情
2. 挑了个 block 相关 issue，浏览项目相关文件，寻找与 issue 相关联的代码文件，制定修复计划
3. 写测试用例 → 修改项目代码尝试修复 issue → 跑用例验证(没 iOS 环境没跑起来) → commit 和提交 PR

这个过程是自动和异步的，它跑在虚拟机里，不需要你提供环境，不需要盯着它，它会自己去调研怎么完成这个任务，做完了会来告诉你（如果用 slack，这个体验过程更顺畅，@它下达任务，任务完成slack回复），这跟给一个员工布置任务，等他做完验收结果的体验很一致。

畅想

现在 Devin 解决问题的能力肯定还有限，真正用下来磕磕碰碰很多任务还是完成不好，现在的模型能力下 Cursor 这种 Copilot 的形态是更实用的，但未来理想的形态肯定是 Devin 这种“员工”形态，因为可以解放注意力，无限扩展同一时间能做的事。

可以想象，这种形态未来的优化速度会很乐观：

1. 基础模型的思维规划能力还没收敛，从sonet o1 到 o3 可以看到还在快速提升
2. 即使基础模型能力放缓了，模型在领域上的调优还有很大空间。
3. 更多工具的接入，也能带来更强大的能力和体验。

以及，模型成本必然比摩尔定律更快速的下降，Devin 会持续用最好的模型最贵的方案，但今天 500美金的效果，一年后成本可能只要5美金就能做到。

Devin 所实现的概念早在 23年初 AutoGPT 就提出，只是当时模型能力还不具备，Claude Sonnet / GPT 4o / GPT o1 这种级别推理能力的模型出现后，才具备可用性，Devin 是实现了这个概念下初步可用的雏形，让人看到这个方向已经初步 ready，剩下的就是持续往这个方向优化和扩展了，Devin 确实称得上是数字员工的开端，设计师agent，交易员agent，数据分析师agent，电商agent，预计会陆续出现。

原理

Devin 是怎么实现的？

有个开源项目 OpenHands（前身 OpenDevin），尝试用开源社区的方式去构建类似 Devin 做的事，虽然能力和效果上不能完全对标 Devin，但可以看个基本雏形。相关论文：https://arxiv.org/abs/2407.16741

文中的这张架构图，可以比较好描述 OpenHands 是怎么做：

三个主要部分：

1. Event Stream：记录每一步指令和执行结果，Action 是指令，Observation 是指令对应的工具执行的结果，Action 和 Observation 最终都是以纯文本记录结果。
2. Runtime：程序运行在独立的 docker 容器里，提供一些工具给 Agent 调用执行，当前包括 Python 运行、终端命令行、浏览器
3. Agent：把 Event Stream 里的所有内容作为上下文，输入到 LLM 推理下一步Action。

还有个关键点没有在图上画出来，为什么把 Event Stream 的所有内容输入到 LLM，LLM 就会按照要求推理出下一步 Action？因为输入到 LLM 的除了 Event Stream 的上下文，还有 Agent 本身的 Prompt，这个 Prompt 描述一些处理原则、当前环境、可用的工具、每个工具的参数、预期输出的格式等，以及还配套了一个示例，指引模型按要求输出。这个 Prompt 本身贴在了文末。

我们跟着图上 Event Stream 的示例，跑一下这个流程：

1. 用户输入一个任务命令：“Can you create a list of numbers from 1 to 10, and create a web page to display them at port 5000?” 到 Event Stream
2. 当前 Event Stream 只有这一条命令内容，输入到 Agent，Agent 会拿它跟上述预置 prompt 一起输入给 LLM，LLM 会推理出下一步是调用 Python 去创建 app.py 文件，输出 Action 指令到 Event Stream。
3. 工具 IPython 对应的 Observation 监听到这个指令，在 Runtime 环境执行了这个命令，输出执行结果“app.py created” 记录在 Event Stream 上
4. Event Stream 接收到 Observation 新的执行结果后，Agent 程序会自动继续把整个 Event Stream 记录连同预置 Prompt 输入给 LLM，推测下一步 Action。推测出来的下一步 Action 是把一大段代码用调用 python 命令的方式写入刚才创建的文件
5. IPython Observation 接收到这个 Action，在 Runtime 环境执行命令，输出执行结果到 Event Stream。

接下来就是不断的循环：Action 驱动 Observation 用工具做处理 → 处理结果输出到 Event Stream → Event Stream 拿所有前文内容到 LLM 输出下一步 Action → 驱动Observation 用工具做处理…

后面的6-9步用了命令行工具和浏览器工具，流程是一样的。这个循环流程什么时候结束？有一个特殊的 Action 叫 finish，如果一个任务 LLM 认为完成了，就会输出调用 finish Action，程序接收到就退出循环，等用户下一步输入。

整体就是自动循环让 LLM 预测下一步动作 → Agent 程序调用工具执行动作 的过程。补充一些点：

1. 整个项目不涉及模型训练，纯工程方案，使用通用 LLM 模型，可以配置 Claude/GPT/Deepseek 等，不过可预见的演进是根据用户使用数据去优化模型以达到领域内更好的效果。
2. 这里没有实现像 Devin 在输出 Action 前先会规划好任务的步骤再一步步执行，但要在上述这个系统加上这个规划能力预计不难。
3. 项目使用 BrowserGym 去和浏览器交互，Agent 对浏览器的操作和识别是另一个大课题，有单独的 benchmark 多种方案，待调研。
4. 随着 Event Stream 里链路的不断增加，上下文会越来越长，到一定程度 openhands 会做两种处理，一种是压缩内容，把前面的上下文发给 llm 精练总结，用更简短的内容作为后续的上下文。另一种是让 LLM 对过去的内容进行重要度排序，只选择对预测下一步重要的几个记录作为上下文，具体逻辑在 condenser.py 里。更长的上下文会用向量数据库 ChromeDB 存储。

附：预置prompt

（更多…）

又到了 31 号这天，回想起来 24 年过得很快，回顾过去一些事，有的感觉就前几周的事，一看原来已经过去四五个月。照例在这天写篇生活记录。

学习

去年说今年要学下AI，总算有点进展，虽然进度不理想，但也算迈开了步伐。

学习如果没有一些事项引导，就很难进行，最好的学习方式是直接在做的过程中学，真正进去做这个事的过程中会不断遇到一些问题，解决这些问题过程就是很自然的逐渐学习和深入的过程。

没这个条件的话，就退而求其次，用分享输出的方式引导学习，所以我时隔四五年不写博客，今年又开始写了，主要就是让我的学习有个地方做完整的记录，有相应的引导。

在软件工程时代，一个功能能不能实现，原理链路大概是怎样，基本都能知道，上一轮以推荐为主的 AI 也大致能了解原理。而这次的生成式 AI 太魔法了，应用范围和影响力也远超过去，完全不了解它是怎么回事很让人难受，有种跟不上时代的感觉，学一些皮毛后感觉好一些。

不过最好还是机会边做边学，希望25年能多一些深入实践，让自己在创造的状态里学习。

今年 AI 继续快速发展，有几个时刻对 AI 的能力和带来的体验还是很震惊的：

1. AI Coding：第一次用 cursor 的补全能力、compose 创建多个文件能力，第一次用 windsurf 直接创建项目跑起来，都让人震惊。虽然一些微调和 bug AI 还不能解决得很好，但做一个 demo 完全没问题，对程序员来说，也可以完全忽略不同编程语言/平台特性前期学习的障碍，无差别上手码代码。AI Coding 是今年完全跑出来的赛道，大家都看到了它的机会，以后没有一个程序员不需要 AI 辅助 Coding，而且 AI Coding 还能不断转换非程序员群体进来构建任意软件交互功能，想象空间很大，可以预料 25 年这个赛道会比百团大战更热闹。
2. Prompt 的能力：看到 Glif 的 AI 梗图生成很惊讶，只需要输入工种比如“程序员”，LLM 就能生成信息量极大的针对这个工种的梗，当时感觉自己确实是 LLM 小白，LLM 本身存储压缩的信息量是巨大的。
3. 视频生成：年初的 sora 震惊许多人，但第一次上手用视频生成才会真实感受到冲击，第一次用即梦的视频S2.0模型时，超高清和稳定的人脸运动属实惊艳，很容易做画面感很好的视频，一直想给小说《十日终焉》配个AI生成的小片，终于圆了这个念想。
4. NotebookLM：生成的真实对话声音的真实性实在太强，一点AI味都没有。文字/图片/音频/视频，以后 AI 可以自由在多个模态之间自由切换，只要有源头内容，各种形态的展示都不会是问题。

（更多…）

近期即梦上线了 AI 图片生成文字的能力，在生成海报、封面以及各种场景下渲染文字效果是非常不错的。最开始AI生成的图片中，涉及到文字的基本都是不能看的乱码，需要针对性训练优化才能做到生成清晰的文字并融入图片。那这里是怎么做优化的？对这个原理比较好奇，尝试通过几篇公开论文学习下相关实现思路原理。

大致思路：Recraft

目前生成文字(英文)最好的模型是 Recraft，官方有篇文章 《How To Create SOTA Image Generation with Text: Recraft’s ML Team Insights》介绍了模型训练的大体过程，挺适合简单了解大致思路的，简单复述下。

首先说明下为什么图片生成文字容易乱码？

1. 一是数据量不足：图片生成模型是通过大量图片+图片描述去做训练，而大部分图片的描述是不怎么包含图上的文字的，比如拍一个街道建筑图，图上会有很多店面的名字文字，图片描述可能就是类似 城市/街道/红色招牌等描述，并没有把图上的所有文字放进去，模型只能在少部分相对简单的场景（比如图上只有几个字，图片描述中也有这几个字）中学习生成正确的文本，幻觉会比较严重。
2. 二是文字的错误更容易被发现，相对于人物动作不协调、衣服花纹的差错，文字只要有一笔一划错误就很容易被人察觉识别为乱码，需要更精确的生成。

接下来看优化文字生成能力的大致流程：

第一步，准备数据。准备大量的包含文字的图片，包括海报、封面、广告、Logo等，对这些图片进行处理。处理包含两部分，一是用 OCR 模型识别图像上的文字位置和文字内容，二是用多模态模型识别这张图的内容，输出描述文本。得到了海量的 图片 – 文本布局和内容 – 图片描述 组合的数据。

第二步，使用数据训练模型，跟第一步是反着的过程。先训练一个布局模型，可以通过输入 prompt → 输出文本布局+内容。再把 prompt 和文本布局输入生图模型，最终生成带文字的图片。

大流程就是这样，再稍微把其中布局模型展开一下：

输入 prompt 输出 文字内容+布局，用的是一个大语言模型(LLM)，定义了一个输出的文本格式，包含文本内容和这些文本的坐标。同时还会根据文本和坐标数据，用文字渲染工具画张图片出来。

这张渲染出来的文字布局图会作为生图时的参考，用类似ControlNet 的方式作用在生图过程中，最终生成图上的文字。

这是个大致流程，文中没有展开里面模型架构的一些细节，原文上表示思路基于 TextDiffuser2，但看起来思路上跟 GlyphControl、TextDiffuser、TextDiffuser2 都有关系。

各方案大的思路都差不多，基本都是分两步，生成文字布局信息，再作用在生图过程中，主要是模型架构不同，以及数据集质量不同。下面看看这些相关的论文和一些模型细节。

GlyphControl

先看看相对简单的 GlyphControl，23年11月的论文，基本就是一种 ControlNet，跟边缘轮廓、姿态等 ControlNet 没太大差异。ControlNet 的相关介绍可以看回这篇。

训练阶段：找一批带文字的图片，用OCR 识别文字内容和位置，再渲染出一张白底黑字的图片，将图片描述和这张白底黑字图片一起进入 Glyph ControlNet 网络训练。这个白底黑字的图片就是参考图，跟边缘轮廓/姿态等其他 ControlNet 的参考图作用和流程都一样。

推理阶段：分两部分输入，生图的 Prompt 和白底黑字参考图，这张参考图看起来是要用户自己另外准备的，可以直接画一张白底黑字的图，或者描述文字内容、行信息、大小位置布局，用工具生成白底黑字参考图，再和 prompt 一起去生成相应的带图的文字。

效果：文字能较准确生成，但没有控制字体样式和文本颜色的能力，泛化性会比较差。布局和位置需要额外输入，产品化实用性低一些。

疑问：controlNet 23年2月出现，为什么11月才有人用于改进图片文字渲染，ControlNet作者自己不试试呢？

还有一篇更直接的，直接用 ControlNet 的边缘轮廓做文字生成，也不用自己训练，做了个评测： 《Typographic Text Generation with Off-the-Shelf Diffusion Model》

TextDiffuser

TextDiffuser 是23年10月的论文，跟上面 ControlNet 的思路有差异：

1. 不用准备参考图，用一个模型从 prompt 中推断文字布局。
2. 直接在生图扩散模型中训练，非 ControlNet 插件的形式。

流程：

1. 布局生成：先根据 prompt 生成逐个字母的文字形状 mask 图。用一个 transformer 模型（非LLM）理解输入的语义，识别出图上要画哪些文字，这些文字在画布上应该是在哪个位置，获得每一个字符在画布上的box位置，再用字体渲染库（如pillow）把这些文字渲染上去，生成这些字符的遮罩表示(Mask)。
2. 图像生成：将上一步得到的字符遮罩输入扩散模型，参与引导扩散过程，使图片能在遮罩对应的位置生成对应的字符形状。

训练：

1. 数据：作者从各处收集了1000万张带有文字的图像-文本对，称为MARIO-10M，主要来源是开源的LAION-400M，从中筛选带文字的高质量的图，也对数据进行了处理，包括文本检测识别、字符级的位置数据、原有的图片描述文字等。
2. 布局阶段：会使用这个数据集去做训练上面提到的 transformer 模型，输入是图片描述文字，输出是每个字符的 mask 遮罩。在数据集中，每张图片的描述、以及每张图片经过 OCR 识别处理后字符的遮罩位置都有，模型就能学习到对不同的图片描述，对应的最终的文本位置和形状应该是怎样的。
3. 图片生成阶段：这个数据集也会在扩散模型的基础上去做进一步训练，在这过程中 U-Net 的参数是冻结的，猜测是避免核心生图能力被破坏？训练过程中只会修改扩散模型 U-Net 以外的其他模块参数，整个网络还是能学习拟合到数据集里 图片描述(prompt) + 字符遮罩数据 → 带文字图片 这里的对应关系。

这整个过程，就是为生图增加信息量，布局阶段渲染的每个字符的 mask 是很大的信息量来源，引导图片扩散方向不飘。

效果：

相对未针对性训练的生图模型，能生成合理清晰的文字，在给定图像补充文字上效果也不错，也能做到控制文本颜色了，但字体多样性差一些。

TextDiffuser2

TextDiffuser 有个问题，它第一阶段产生的文字 mask 是用单一字体渲染的结果，用这个 mask 引导生图，结果是生成的结果字形的多样性比较差，生成的文字倾向于规整，手写或艺术字很难出现，GlyphControl也有同样的问题。另外 TextDiffuser 布局转换器对用户输入 prompt 的理解能力也有限。

TextDiffuser2 差异在于：

1. 布局模型用大语言模型去替换。LLM 能表现出比较强的语义理解布局规划能力，用一个 LLM 去理解 prompt 转化为对应的布局格式，效果会更好。
2. 生图阶段，对扩散模型中的语言模型(clip)和 U-Net 都做了训练。

训练

布局模型：

1. 使用 LLM vicuna-7b-v1.5 模型进行微调，训练用的还是前面的 MARIO-10M 数据集，拿这个数据集每张图对应的描述文字作为输入，用 OCR 把每张图片的内容和位置信息提取出来作为预期输出做训练。
2. 这里自定义了布局的格式，一个关键词以一组坐标和字母组成，比如 [x25][y89][x108][y96][W][I][L][D]，两个坐标表示方块左上右下两个点。每个字符单独标记，会比去做BPE分词标记效果好。
3. LLM在学习了大量文字对应图片的构图后，可以从语义推理这些文字的构图应该是怎样的，同时 LLM 自身也能很好理解哪些词是关键字，哪些词应该在同一行。比如上图的 旷野之息邮票 a stamp of Breath of the Wild，LLM 可以学到图上的文本应该是 Breath of the Wild，而对于邮票比较好的布局是上下两行，有个关键字 Wild 突出，得出相应的布局数据。
4. 根据论文描述，5000个数据量的训练效果是最好的，可能数据多了反而过拟合效果不好。

生图模型：

1. 直接在扩散模型中训练，图上的 M2 是扩散模型里的 clip 文本模型，布局内容和文本 prompt 会一起输入，U-Net 也参与了训练，继续在用 MARIO-10M 数据集做训练。为什么这种方式训练效果好，文中没怎么提到。

效果

TextDiffuser2 的多样性会好一些，字体形态多样。

总结

还有一些其他方案，例如 GlyphDraw、AnyText等，大原理差不多，不展开多说了。最后，用 notion AI 总结下本篇文章：

AI 图片生成文字主要有以下几种方案：

1. GlyphControl：通过白底黑字的参考图来控制生成文字的位置和内容，实现简单但泛化性较差。
2. TextDiffuser：采用两阶段方案 – 先用 transformer 模型生成文字布局 mask，再用扩散模型生成最终图像。但生成的字体样式比较单一。
3. TextDiffuser2：改进了 TextDiffuser，用大语言模型替代布局生成，并对扩散模型进行更全面的训练，使生成的文字样式更加丰富多样。

这些方案的核心思路都是：

• 准备大量包含文字的图片数据集（如广告、海报等）
• 设计两阶段架构：先生成文字布局，再生成最终图像
• 通过不同的技术手段（如 ControlNet、LLM等）来提升生成效果

目前 TextDiffuser2 的效果最好，既保证了文字的准确性，又能生成多样化的字体样式。Recraft 借鉴了 TextDiffuser2 和 GlyphControl。

近期苹果发布的新品，无论是 iPhone 还是 Mac，都一改之前挤牙膏的风格，在最低配机器上都加大了内存，目的很明确，就是支撑 iPhone 和 Mac 上的端 AI 大模型。过去一年，AI手机、AI电脑的概念也一度在炒，在之前写的文章也说过，在客户端上跑大模型，一定是未来趋势。那目前端上大模型情况怎样？

应用近况

总的来说，各家陆续出了不少小模型，相关工具链也能支持它们在客户端上跑起来，但可用的应用几乎没见到。

不少手机厂商都号称接入了端模型，但实际上没搜到相关具体应用，Apple Intelligence 还在路上，演示的能力似乎大多是云端模型，不确定本地小模型能做的事。Google Pixel 8 也没有接入Gemini nano，小米14上没有MiLM，小爱完全靠云端模型，OPPO find7 号称端侧模型用于生成通话摘要等一系列能力，但似乎得联网，不确定端模型在上面起到的作用有多大，真正能离线用的也只有图片消除功能。

为什么雷声大雨点小？

1. 完全体 LLM 近一年的应用场景也有限，端上也就更少了，当前阶段业界精力还是主要投入在研发最好的模型上，很难顾得上端的优化。
2. 现在的硬件和模型优化程度还不允许 LLM 在端上有作为。端设备基本都对体积和功耗敏感，这两者都限制了硬件能提供的最大性能，7B的模型硬件支持不好，3B的效果不好。

（更多…）

AIGC 图片生成的技术，基本是22年开始爆发，Midjourney 2022年7月推出，Stable Diffusion 2022年8月推出，至今两年发展迅速，已经广泛在很多场景应用，但这个市场上是谁在用图片生成，用来做什么，一直以来在我认知里都有些模糊，这篇文章做下相关调研。

线上线下所有用到图片的地方，都有 AI 图片生成的应用空间，而 AI 图片生成的能力，也会创造出新的领域和行业，就目前能看到的已经在应用的场景，归归类可以分为：生产力工具、大众娱乐、探索创作。

ToB：生产力工具

把 AI 图片生成能力作为实际工作中的生产力工具，用在各领域的内容生产，替换原来的工作流，效率有量级上的提升，同时也有因为 AI 图生成带来的新的领域，例如自媒体。

这里的用户大部分是设计师，全球设计师 9000w，包含建筑设计、室内设计、工业设计、服装设计、产品设计、平面设计等，Adobe 付费订阅人数2650w（2022年），是非常大的市场。

电商

电商有大量的市场，为了展示、介绍、美化不同种类的商品，对图片有巨大的诉求，是AI图片（以及视频）最好的应用场景。

1. 模特图：模特换衣、模特生成、在线试衣，专门服务服饰品类的工具，全球电商服饰品类市场规模六千亿美元，这让它对应的工具需求也足够大，能搜到的有几十家公司专门在做，例如Botika、VModel.AI、摹小仙、千面AI模特、ZMO.ai、linkfox，美图秀秀/醒图等也有相关工具。入门门槛低，但效果的调优是wu’zhi’jing的，不同角度/动作/不同衣服穿上后的自然度等都需要不断调优。
   

   换模特	换衣

2. 商品图：上传商品图，AI 可以帮你生成商品在不同环境下的宣传图，免去摆拍。相对于直接抠图→套模板，AI生成质量高，可定制程度也高，可以创造符合商品的各种背景，商品能更好融入对应背景、环境的光线阴影、颜色、高保真，这里的效果调优也是无止尽。同样有非常多公司在做，photoecom、灵动AI 、PicCopilot。综合性的图片工具大多也会加入这个功能，比如 photoroom。
   

   灵动AI	photoroom

3. 其他长尾：电商很庞大，除了上述两个类，整个上下游各个品类还有不少细小长尾的 AI 图片生成需求，例如 T恤定制、衣服花纹生成、款式生成、站外营销图等。
4. 从发展趋势看，电商平台如果自身有余力，都会去做这样的工具，嵌入到自己平台内，整个工作流更顺，像淘宝千牛自己就做了。但竞争是无止境的，所有商家都用平台提供的工具，质量品质同质化后，就会有个性化或追求更好效果的诉求，外部工具一直会有机会。

（更多…）

是什么

1. 在机器学习领域，”模态”被用来描述不同类型的数据形式，如文本、图像、视频、音频等。
2. 最开始以 ChatGPT 为代表的大语言模型，都是只支持文本这个单一模态。
3. 可以同时处理文本、图像、音频等多种形式的数据输入输出的大模型，就是多模态大模型。

特点：端到端

一个模型能同时理解和处理多种模态的数据输入。

1. 非端到端的例子：
   1. 在 ChatGPT 上，可以调用 DALL-E 生成图片，但实际流程是 prompt → GPT4模型 → 生成细节提示词 →DALL-E模型 → 生成高质量细节图像，只是一个能力串联，并不是一个多模态大模型。
   2. 在豆包或其他一些LLM APP上，支持语音输入→文字和语音输出，实际流程是 语音→ASR模型转文字→LLM→文字→tts模型转语音，并不是端到端 语音→LLM→语音。
2. 端到端的例子：
   1. GPT4o 的实时语音对话，流程是 语音→ GPT4o模型→语音。延迟低、语气/音色/停顿/语义都能综合理解到。
   2. claude3.5 支持按要求识别图片，流程是 图片+prompt → claude模型→文本。能很好结合 prompt 按要求输出对图片的识别。
3. 端到端的好处：
   1. 模型能直接从原始的数据中学习不同模态之间的关联和映射关系，发现隐藏在数据中的复杂跨模态模式，可以 scale up 达到涌现，没有中间折损，可以做到低延时。

（更多…）