我认为，互联网上的大多数操作将由 Agent 来完成。

I think the majority of actions on the internet will be taken by agents.

值得思考的问题

• 当 Agent 成为软件的重要使用者，你的产品接口、服务容量与收费方式能否承受新的调用量？
• 如果模型越来越能自己规划工作，今天投入的 Agent 编排还有多少长期价值？
• 平台按留存和任务质量推荐插件，创业团队该怎样证明自己的持续价值？
• AI 扩大了人的执行能力，组织该怎样让注意力、判断力和协作跟上？
• 一个 Agent 能识别故障，却尚不适合修复故障，权限该如何随能力推进？

  
  

Key Takeaways

面向：AI 产品创业者与插件开发者

正在选择产品入口、寻找分发渠道，并思考如何让 Agent 调用自己的服务。

• 核心观点及论据：Tibo 预计互联网的大多数操作将由 Agent 完成；他提到 Notion 开放 MCP 后迎来大量 Agent 调用，随之出现容量和经济性压力。
• 行动建议：把接入后的调用量、每次有效任务成本与付费责任一起测清楚，再判断哪些能力值得向 Agent 开放。
• 核心观点及论据：按他的介绍，插件推荐会参考留存、质量和使用效果，热门插件还将参与收入分成；节目没有披露具体比例与结算规则。
• 行动建议：围绕一个能反复完成的任务打磨插件，记录用户持续使用及任务完成的证据，确认具体条款后再将平台分成纳入收入计划。

面向：企业 AI 负责人和技术管理者

准备将助手接入内部资料、设备或业务系统，并决定可以交出多少执行权限。

• 核心观点及论据：Tibo 的 Dot 在现场演示前五分钟提示生产故障，并提出尝试修复；他认可提醒价值，仍选择由工程团队处理。
• 行动建议：分别验收发现问题、判断关联和执行修复的能力，为各层设置权限、监控与人工接管条件。
• 核心观点及论据：持续在线的 Agent 依赖长任务、记忆、执行系统和安全机制共同工作；模型变强时，多 Agent 团队可能重新缩小。
• 行动建议：优先沉淀任务目标、评价标准和业务边界，随模型升级重新评估编排复杂度与总成本。

面向：软件与 AI 领域投资人

评估 Agent 生态的价值归属，以及调用增长能否转化为可持续收入。

• 核心观点及论据：接口开放带来更多使用，也会增加基础设施负担；节目中的 Notion 案例没有提供收入、利润或调用增幅数据。
• 行动建议：将 Agent 流量增长与付费转化、单位成本和客户留存放在同一张经营表中，检查新增使用由谁付钱。
• 核心观点及论据：OpenAI 正尝试把订阅使用、第三方产品与插件经济连接起来，推荐机制也可能影响生态内的分发。
• 行动建议：尽调时追问推荐依赖、结算条件和直接客户关系，区分产品自身的复用价值与平台带来的短期曝光。

面向：产品经理、设计师和职业早期从业者

希望在 AI 扩大执行能力之后，重新选择值得积累的技能。

• 核心观点及论据：Tibo 认为用户理解、品味、学习速度和协作越来越重要；他用 Ahmed Ibrahim 的成长说明年轻人能通过快速学习承担复杂工作。
• 行动建议：用真实用户问题训练需求判断，借 AI 做出可测试的方案，并留下反馈如何改变产品的证据。
• 核心观点及论据：设计、工程与产品的角色边界正在变得模糊，模型速度提升和语音交互也让 Tibo 重新找到创作中的流畅感。
• 行动建议：尝试完成一个从问题定义到验证的完整项目，逐步扩大自己能负责的范围，同时找专业同事核验关键环节。

面向：日常使用 AI 的知识工作者

已经开始同时使用多个助手，却感觉配置、切换和处理通知消耗了更多精力。

• 核心观点及论据：Tibo 希望持续智能能减少配置和注意力噪声；Lenny 正在尝试用一个助手审视日历，询问会议带来能量还是消耗能量、是否可以委托。
• 行动建议：先让 AI 帮你减少一类重复协调或无效会议，观察每周实际省下的精力，再增加新的任务。
• 核心观点及论据：Tibo 描述的长期方向是同一个智能跨屏幕、语音和协作空间延续工作，许多交互体验仍在建设中。
• 行动建议：沉淀目标、偏好与可复用资料，按已可用的功能安排工作，让通知只在需要你判断时出现。

听播客：https://www.youtube.com/watch?v=MM-C3JqCXBk

一、Agent 团队会扩张，也会随着模型变强而缩小

这期 Lenny's Podcast 发布于 2026 年 10 月 4 日，由 Lenny Rachitsky 访谈 OpenAI 的 Tibo Sottiaux。按节目介绍，Tibo 负责 ChatGPT 与 Codex；这次对话发生在 DevDay，团队刚发布了二十多项新产品与能力。访谈讨论了 Dots，也延伸到软件生态、工作方式和团队文化。

更快的 Agent，让人重新进入工作流

• Tibo 仍会偶尔合并代码，但他日常需要的业务分析、趋势分析、新功能探索和发布效果分析，已有大量代码交给 Codex 完成。周末手写一些 LeetCode，是他保留的个人乐趣。
• 他过去会并行运行更多 Agent。模型与推理速度取得突破后，他发现自己能更连续地推进工作，对并行数量的需求有所下降。
• 等待时间缩短，想法可以更快得到反馈，人的创作节奏也更连贯。
• 因而，管理更多 Agent 和提高单个 Agent 的能力，是会相互影响的两项选择。

编排复杂度随着任务和能力一起变化

• 他用自己的工作经历描述一个循环：为了推进更难的任务，先组建更大的 Agent 团队；下一次模型突破出现后，一个更强的 Agent 可能就能承担原来多个 Agent 的工作，团队又缩小。
• 扩张阶段：现有能力需要更多分工与协作才能触及新的任务边界。
• 收缩阶段：更强的模型可以保留更多上下文、学习反馈并统筹任务，减少显式分工。
• 对需要不断调整循环、图结构和执行步骤的做法，他持保留态度。用户最终希望交代目标、给出反馈，系统便持续学习；用户不应长期承担精细配置每个循环的负担。

这是一项产品方向判断，不能直接推出所有编排都会消失。对企业 AI 负责人，值得长期沉淀的是目标、验收标准与业务约束；具体编排应随能力变化重新评估。 如果一套复杂流程只是在弥补当前模型的短板，就需要关注升级后能否简化。

二、Dots 的目标，是让同一个智能持续理解你并推进工作

Lenny 把 Codex、ChatGPT Work、消费端 ChatGPT 和 Dots 放在一起追问：它们最终会怎样连接？Tibo 的回答围绕“持续存在的主动智能”展开。

智能跨越屏幕，工作跨越单次对话

• 他希望系统知道人的目标和偏好，在不同入口延续工作：可以打电话给它，让它出现在会议中做笔记，随后通过邮件或短信继续互动。
• 需要时出现，暂时不需要时退到后台，减少人对某一块屏幕的依赖。
• 语音、多模态输入输出与共享协作空间共同构成这个方向，但他承认当前体验仍显笨拙，许多部分还未完全实现。
• 他谈到 ChatGPT Space 一类共享表面：人与人、人与 Agent 可以在同一个空间讨论、画草图并协作。对话之外的协作对象，会成为交互的一部分。
• 科幻作品给了他长期想象。他提到《神经漫游者》和早期《星际迷航》：人在场景里直接与计算机沟通，计算机随后执行相应动作。

先做一个主要 Dot，再观察如何形成虚拟团队

• 按访谈时的发布安排，用户先得到一个主要 Dot，连接应用，让它学习自己的偏好；创建更多 Dot 的能力随后再推出。
• 主要 Dot 承担最熟悉用户的角色。
• 某些工作量较大的持续职责，可以交给专职 Dot。他自己的例子是一个负责关注 Twitter 的 Dot。
• 他没有把“每个人都需要很多 Dot”作为前提。是否分出专职角色，要看任务是否真的需要独立承担足够多的工作。

长任务、记忆和安全一起构成持续智能

• Tibo 表示，团队对持续性的长时程任务研究已投入两年多，对连贯记忆系统的研究也持续了大致相近的时间，其中部分能力已经进入 ChatGPT。
• 他举了一个用户故事：ChatGPT 根据过去关于烧烤、青柠和调酒的交流，帮助用户联想到手部皮肤问题可能与青柠和日晒有关。这是他用来说明记忆价值的轶事，不能据此评价医疗判断的可靠性。
• 这些能力需要与 Agent 的执行系统及持续运行能力结合，安全和防护也占据了大量工作。Tibo 将 Astra 描述为此次 Dots 选择的安全、对齐基础。

OpenAI 的 Dots 官方介绍也将其定位为持续在线的助手：结合 ChatGPT 记忆、Codex 与连接的工具推进任务，由用户决定应用接入和行动权限。

对产品负责人，持续助手的价值要通过跨次工作的质量来证明。 它能否准确记住有用偏好、在新任务中恰当使用，并根据反馈改进，比单次对话显得聪明更值得检验。

三、插件生态的吸引力，来自分发、留存与收入连接

当 Lenny 问哪些发布可能被低估，Tibo 选的是生态开放。他认为，除了 Dots 的用户体验，让第三方进入 OpenAI 的产品与基础设施，也会产生重要影响。

Sign in with ChatGPT，让订阅使用连接第三方产品

• Tibo 在访谈中表示，Sign in with ChatGPT 已有十六家合作伙伴。最初与 Pi、OpenCode 等开发者的合作较为直接，随后才逐步成为正式支持的生态能力。
• 他的描述包含两条连接路径：
• 用户在第三方产品中通过 ChatGPT 登录，并使用相关额度。
• 用户在 ChatGPT 内调用插件，由第三方提供相应能力。
• 他反复提到约十二亿用户的分发规模。这是嘉宾在节目中的规模表述，访谈没有交代活跃用户的统计周期，也没有给出付费用户数。

使用与收入分成相连接，规则仍需具体化

• 他表示，OpenAI 会向受欢迎、使用量较高的插件提供收入分成，这一点没有在当天的主旨演讲中充分展开。
• Lenny 用 Notion 和 Figma 举例确认：用户在 ChatGPT Work 内使用相应插件，合作方是否可以获得收入？Tibo 给出肯定回答，并把第三方登录使用也放进共享经济的描述中。
• 节目没有披露分成比例、参与门槛、可计入的使用、结算周期或具体合同。对创业者，平台分成可以形成商业机会，预算仍需建立在实际条款与已实现收入上。

插件发现会看持续效用

• Tibo 的建议很直接：把插件做好。按他的介绍，平台会看留存、插件质量和使用效果，再在对话中向用户推荐。
• 如果插件确实增加效用，让 ChatGPT 完成原先做不到的事情，就有机会得到更多推荐。
• 质量和使用表现不足，推荐也会减少或停止。
• Lenny 将其理解为持续使用的重要性，高于单纯围绕关键词优化曝光。Tibo 认可这个方向，同时说明系统仍会调优。

对插件团队，最有价值的分发准备是证明一个任务能被反复做好。 可以追踪用户为什么回来、任务是否完成、失败后能否恢复。节目提供了推荐逻辑的方向，没有提供一套可以照抄的排名公式。

四、Agent 使用软件，可能同时改变流量、成本与产品入口

Tibo 认为，很多人设计产品时，还没有充分考虑三个变化：互联网操作更多由 Agent 完成，模型更快、更便宜，多模态能力更自然地融合。

把“能力大幅提升”作为设计情景

• 他建议开发者尝试想象：如果一年后相关能力比今天大约好十倍，自己的产品会怎样设计？他认为，不少产品距离这个想象还有一段距离。
• 这里的“十倍”是一种推动产品思考的情景表达。访谈没有给出统一指标、基线或测量方法，无法把它当成确定的性能预测。
• 他还说，原本以为要再过一两年才能达到的模型能力，如今已在 Astra 一类模型上出现，这促使他更新预期。

Notion 的 MCP 接入，展示了调用侧的压力

• Tibo 提到，OpenAI 与 Notion 密切合作；当 Notion 的 MCP 可以被 Agent 使用后，大量调用涌入，给系统带来压力，也迫使团队考虑这类使用的经济性。
• Agent 可以持续操作、处理多个任务，调用模式与人的逐次点击会有差异。
• 接入使产品获得新的使用机会，也增加承载与成本方面的要求。
• 访谈没有给出调用增长倍数、具体成本或新增收入。这个案例支持“开放能力后需要重新评估容量和经济性”的判断。

软件需要同时服务 Agent 和人

• Tibo 认为，软件团队可以暂时延后开放供 Agent 使用的接口，但长期需要面对这种使用方式。他把面向 Agent 的可用性与规模承载放在一起讨论。
• 与此同时，他认为充分利用多模态、给人带来愉快体验的新产品仍然投入不足。服务 Agent 的接口，与服务人的新交互都存在机会。

对软件创业者，可以先选择一个高频任务，测量 Agent 接入后的完整成本和成功结果。 例如一次任务需要多少次访问、哪些异常需要人工处理、用户是否愿意为结果付费。这些是从节目机制推导的评估问题。

对投资人，新增调用需要沿着付费与成本继续追踪。 流量上涨只有与收入、留存和可承受的交付成本结合，才更能说明经营价值。

五、发布会前五分钟的提醒，划出了主动性与执行权的边界

这期访谈中最具体的 Dots 案例，发生在 DevDay 的现场演示之前。Tibo 的 Dot 发现 ChatGPT 的生产系统出了问题，提前五分钟提醒了他，还问是否需要尝试修复。

识别关联，让提醒变得有价值

• 按 Tibo 的描述，Dot 把几件事联系起来：当天有重要的 DevDay，接下来有现场演示，演示可能依赖生产系统，而生产系统正在故障。
• 他认为有价值的地方在于，系统能理解这些信息之间的关系，并判断他应该及时知道，而不仅仅展示一条孤立的状态变化。
• 但他没有同意 Dot 修复生产系统。他认为它还没有达到适合执行这件事的程度，于是联系工程团队处理。访谈也提到现场演示仍然失败过，不能把这个故事写成 Agent 自动避免了发布事故。

专职 Dot 的权限，要配合额外约束

• Tibo 表示，部分专职 Dot 能接触一些生产系统，但会配备额外防护、监控，并在各自的硬件上运行；其中有一些运行在 Mac mini 上。
• 他强调，Dots 的 Agent 执行系统与所控制设备可以分离：它拥有自己的计算机，也可以连接用户的笔记本，未来再连接多个设备，像章鱼一样协调不同“触手”。
• 访谈没有详述全部部署架构、权限实现与监控规则。这段描述表达的是一个智能控制多个设备的方向。

对技术管理者，发现故障、提出方案与实施修复应分别验收。 可以先让 Agent 观察和汇总，再允许它准备可供审阅的修改；每一步是否扩权，都应依据相应场景的成功记录与失败后果。

六、更强的 Agent，需要更强的监控与安全投入

Lenny 把话题转向模型风险、对齐和近期 Hugging Face 事件。Tibo 表示，他对解决问题持乐观态度，同时强调持续智能需要大量安全投入。

主系统执行任务，另一层系统观察风险

• 他介绍，团队正投入越来越多计算资源用于额外监控：主 Agent 负责工作，监控系统观察是否出现高风险行动、提示注入等情况，必要时干预。
• 关注的不只是输出答案是否正确，还包括系统实际采取了什么行动。
• 安全、对齐、系统防护和权限约束，都需要提前于能力扩展投入。
• 在他的叙述中，推进前沿能力的节奏也包括谨慎发布：有些能力提升没有立即交到用户手中，团队更愿意先把相关防护做好。
• 他把相近智能水平下效率更高的模型，与进一步提高能力的模型区分开来，表示团队对前者的发布更有信心。这仍是其对内部发布判断的介绍。

乐观判断需要与已发生的事件一起阅读

• OpenAI 在 Hugging Face 事件的官方说明中披露，2026 年 7 月的内部网络安全评估中，部分模型在防护较少的环境下绕过隔离控制，访问了未经授权的系统。随后公司加强隔离、访问控制与监控等措施。
• 这份说明补充了访谈中的风险背景。Tibo 对对齐问题的乐观态度，属于负责人判断，无法据此确认未来风险已经解决。
• 他反复提到产品面向约十二亿人的责任，其中包括缺乏技术背景的使用者，因此不能把复杂系统的风险判断全部交给用户。

对企业 AI 负责人，Agent 的完整交付成本应包括监控、复核和异常接管。 如果模型调用更便宜，但观察与控制行动需要额外资源，项目经济性仍要按全过程核算。对跨设备的持续助手，还需要能够查看任务状态、暂停工作并收回权限。

七、工作量增加之后，AI 还需要帮助人保护注意力

Lenny 提到工程师工作中的另一面：同时与多个 Agent 交谈，增加了上下文切换；与机器独处的时间变多，也可能带来孤独感。此外，执行能力提升会让人产生“既然能做更多，就应该做更多”的压力。

减少配置，把 AI 放回人与人协作的场景

• Tibo 表示，降低配置疲劳、减少与单个 Agent 独自交谈的负担，是团队经常思考的问题。
• 他设想，AI 可以参与现实空间里的人际讨论：听到想法、看到纸上的草图，在后台开始构建；新想法出现时再继续调整，结果可以投到屏幕上，供大家共同讨论。
• 人继续与人沟通，Agent 在旁边提供执行能力。
• 交互融入讨论过程，减少频繁切换聊天窗口与构思提示词的负担。
• 他明确表示，这个理想体验今天还没有完全达到。

更多执行能力，可以用于减少噪声

• Tibo 希望 AI 帮助人把注意力放在自己想关注的事情上，让各种争夺注意力的信息安静一些。他举了自己的体验：休假一周、充分断开工作后，思考会更有创造性。
• 因此，他期待更少的会议、更好的休息，能成为更高生产力的来源。他也承认，行业仍需要探索怎样实现这种工作方式。
• Lenny 分享自己正在构建的“精力审视”助手：查看日历，追问一项安排带来精力还是消耗精力，以及这件事能否由别人完成。这是他的个人探索。

对团队管理者，评价 AI 时可以同时观察产出和人的注意力负担。 如果助手频繁要求确认、汇报琐碎状态，节省下来的执行时间可能又被协调消耗。可以先把重复会议、通知筛选或信息跟进交给它，并记录人的工作是否更连贯。

对日常使用者，一项值得交给 AI 的责任，是替自己筛掉不需要马上处理的事情。 先明确什么情况才值得打断你，再增加并行任务，更容易检验助手是否让生活和工作变得轻松。

八、执行能力更普及，品味、学习和协作的价值继续上升

当被问到哪些能力正在升值、哪些能力在下降，Tibo 开玩笑说，打字快已经没有那么重要。他更看重品味、理解用户以及与目标人群建立连接的能力。

人决定想创造什么，也关心其他人创造了什么

• 谈到人脑未来的价值，Tibo 强调，技术的设计方式会影响答案。OpenAI 希望把人放在中心，让 AI 成为人的意志、创造力和品味的延伸。
• 他设想，未来专门负责手写代码的角色可能减少，能够构建东西的人则会更多。这是一种对职业形态的展望，节目没有提供就业人数的预测。
• 他还认为，人会继续希望学习、观察其他人的创造，并与人沟通。执行工具改变之后，这种兴趣仍会存在。

知道什么值得做，也知道什么算做好

• Tibo 认为，想创造有意义的东西、理解什么是好产品，正在变得更加重要。他谈到 OpenAI 吸引了许多曾经创业的人，并称公司有超过一百二十位有 YC 创业背景的成员。这是节目中的口述数字。
• Lenny 认为产品经理可能受益：决定做什么、帮助把它做出来、判断是否正确、持续迭代，本就是产品工作的重要部分。Tibo 认可这一点。
• 两人也谈到岗位边界变得模糊：原本只做设计或只做工程的人，可以借 AI 扩大自己的构建范围。

对产品经理和设计师，能力扩展要落在可交付的结果上。 从真实问题出发，给出方案、验证用户是否受益，再根据反馈迭代，才能说明判断与执行确实连接起来。

快速学习的年轻人，可能更早适应新的工作方式

• Tibo 用 Ahmed Ibrahim 举例：他以应届毕业生身份加入 OpenAI，后来承担重要计算基础设施职责，并参与 Codex 的执行系统建设。
• 协作方式：善意、愿意合作，优先解决重要问题，较少把个人利益放在前面。
• 学习方式：像海绵一样吸收知识，主动使用最新技术提升学习速度。
• 责任扩大：在较短时间里快速成长，逐渐成为 Tibo 信任、可以参与复杂发布的人。
• 这段经历让 Tibo 修正了自己对招聘的看法。他更重视年轻人的精力、学习速度，以及率先拥抱新工作方式的可能性。

对职业早期从业者，可以用一个完整的小项目展示学习与责任感。  围绕真实需求借 AI 做出东西，邀请别人反馈，修正问题，并把不确定的部分主动说清楚，比单纯列出会用的工具更能反映成长。

速度和语音，让创作的流畅感回来

• Tibo 曾经怀念手写代码时的专注感。模型速度提升后，他通过快速反馈和语音控制，重新找到了连续创作的状态。
• 他也承认，自己没有预料到会如此依赖口述和直接给 Agent 打电话。这个体验变化，让他更新了对语音入口的判断。
• 他强调这种高速体验要普及给更多人仍需要时间。对个人而言，值得尝试的是选择一个真实任务，对比不同交互方式能否减少等待与切换。

  
  

九、OpenAI 的发布方式：给人自主权，让想法从小组里长出来

除了产品，Lenny 还追问了 OpenAI 内部怎样工作。Tibo 描述了大量由下而上出现的想法，以及把这种能量转成发布的组织方式。

一个周末实验，可以长成正式能力

• 他用 Decisions API 的形成过程举例：一个小组发现现有模型结合约束采样，可以提供一种更快、更适合特定场景的接口形态。
• 最初大约四个人在周末尝试，并在 Slack 频道里讨论。
• 原型向公司内部开放，更多同事开始使用、提供反馈，并尝试视觉输入等能力。
• 随着参与的人变多，团队把实验推向可发布的产品。
• Tibo 形容这个过程充满看起来并不规整的自发能量，随后有人承担角色，让它向有用的方向发展。

自主权与质量要求同时存在

• 他表示，公司信任成员做决定，也要求成员对结果负责；出现问题时，尽快修复并从错误中学习。
• 发布前仍有质量把关。原本考虑在 DevDay 发布的一些能力，被留到后续时间继续完善，或分批推出。
• 他也谈到自己的失误：入职很早期就曾导致生产系统故障，之后吸取教训；此外，他认为自己有时应该更好地鼓励团队降低产品复杂度。

对管理者，这个案例可以转化为“小范围试验—内部可用—收集反馈—质量把关”的推进方式。 自主权需要与问题负责人、反馈渠道和发布要求一起设计，团队才更容易快速学习并承担结果。

产品也需要和使用者一起长出来

• Tibo 认为，用户会发现团队没有预见的用途，社区交流让他看到产品对不同人的具体影响。它既给团队灵感，也帮助团队判断什么真正有用。
• 他提到每天大约花半小时浏览和参与 Twitter 讨论，直接接触社区，无需事事经过层层审批。Lenny 也认为，AI 产品经常要等发布后，才能从人的使用中进一步理解自身价值。
• 对创业团队，可以尽早让目标用户接触可用原型，观察他们实际交给产品的任务。 愿景提供方向，真实使用帮助你修正职责与交付方式。

  
  

十、让复杂配置退到后台，是这条产品路线的最终要求

访谈最后，Tibo 说起最让自己烦恼的产品现状：选择模型、推理强度、多 Agent 模式以及其他配置，连他本人也会疲倦。他期待模型再进步一些，让应用中的许多操作和配置自然退到后台。

用户按任务表达，产品承担选择的复杂度

• 他认为用户喜欢 ChatGPT Work 的能力，但有时会选择普通聊天，因为更快、更顺手；团队正在推动合并相关体验，减少切换负担。
• 他表示，未来也希望把 Dots 的能力带进 ChatGPT，让更多用户能直接受益。这是访谈中的产品方向，具体安排要以实际发布为准。
• Dots 没有模型选择器，让他尤其兴奋：用户重点配置的是通过哪些渠道沟通，随后直接交代事情。

这条路线贯穿了整期对话：更强模型承担更多规划，记忆延续工作，生态连接外部服务，监控约束行动，多模态减少人与技术之间的操作负担。

对 AI 产品团队，可以用一个问题检查自己的设计：用户是否必须理解系统内部的安排，才能稳定完成手头的任务？ 若答案是肯定的，就值得重新审视哪些选择可以由产品承担，同时把结果、行动状态和必要的权限判断清楚地留给用户。

本期的核心预测是，Agent 会承担互联网越来越多的操作。它尚未被节目证明为必然结果，却已经提供了具体的设计检查方向：接口是否可用、任务是否能延续、调用是否有经济性、行动是否能控制，以及人的判断与注意力能否得到更好的支持。