《InfoQ：架构师2025年第一季（383页）.pdf》由会员分享，可在线阅读，更多相关《InfoQ：架构师2025年第一季（383页）.pdf（383页珍藏版）》请在三个皮匠报告上搜索。

1、 CONTENTS/目录 特别专题|Agentic 软件革命 传统数据仓库正在被传统数据仓库正在被 Agentic AI Agentic AI 吞噬？吞噬？Agentic Data Stack Agentic Data Stack 初探初探 Agentic AI Agentic AI 要终结数据库和要终结数据库和 SaaSSaaS？大厂掌门人公开互撕，焦虑的？大厂掌门人公开互撕，焦虑的 CEO CEO 们押上了不同的技术路们押上了不同的技术路线线 被骂惨的被骂惨的“现象级现象级”Manus”Manus，今天我们来扒一扒它的真实水平！，今天我们来扒一扒它的真实水平！GPTGPT-4o“4o“吉卜

2、力吉卜力”爆火，爆火，PromptPrompt、SD SD 白学了？！大模型能力进化碾压一切白学了？！大模型能力进化碾压一切 资源有限，如何构建高效能的资源有限，如何构建高效能的 AI AgentAI Agent Agent Agent 驱动的智能答疑产品构建：问答、诊断与修复实践驱动的智能答疑产品构建：问答、诊断与修复实践 Andrej Karpathy Andrej Karpathy 爆火演讲刷屏技术圈：爆火演讲刷屏技术圈：AI AI 开启软件开启软件 3.03.0，重写一切的时代来了！，重写一切的时代来了！访谈文章|Interview 吴恩达评吴恩达评 Agent Agent 现状：现状

3、：MCP MCP 还欠火候，单还欠火候，单 Agent Agent 跑通已是跑通已是“奇迹奇迹”，A2A A2A 协作堪称协作堪称“双重双重奇迹奇迹”“我已经过时了我已经过时了”！83 83 岁图灵奖大师、龙书作者在大模型时代的技术焦虑：越来越难以适应新岁图灵奖大师、龙书作者在大模型时代的技术焦虑：越来越难以适应新技术技术“不是不是 Cursor Cursor 不够强，是不够强，是 Claude Code Claude Code 太猛了太猛了”！创始人详解！创始人详解 Claude Code Claude Code 如何改写编程如何改写编程方式方式 微软重磅开源微软重磅开源 CopilotCo

4、pilot！64 64 岁岁 VS Code VS Code 创始人亲口承认：眼红创始人亲口承认：眼红 CursorCursor，但真正价值在后端，但真正价值在后端，它它“抄抄”不过去！不过去！年赚三亿美金、估值近百亿，年赚三亿美金、估值近百亿，Cursor Cursor 竟无护城河？竟无护城河？月烧月烧 4 4 万元，两工程师用万元，两工程师用 Claude Code Claude Code 跑出跑出 15 15 人团队效率：值不值全网吵翻了！人团队效率：值不值全网吵翻了！II 热门演讲实录|落地和进化 AI AI 驱动的智能化单元测试生成：字节跳动的实践与创新驱动的智能化单元测试生成：字节

5、跳动的实践与创新 去哪儿网前端代码自动生成技术实践去哪儿网前端代码自动生成技术实践 AI AI 创新应用创新应用 C C 端端 B B 端商业化实践，从中国走向全球端商业化实践，从中国走向全球 大模型赋能电商大模型赋能电商 B B 端，快手电商技术实践深度揭秘端，快手电商技术实践深度揭秘 Databricks Snowflake Databricks Snowflake 纷纷下注，纷纷下注，PostgreSQL PostgreSQL 成成 AI AI 时代数据库标准？时代数据库标准？小红书鸿蒙小红书鸿蒙 OS OS 下的性能优化探索与实践下的性能优化探索与实践 复杂场景下的复杂场景下的 RAG

6、 RAG 架构演进：跨模态知识联邦与统一语义推理实践架构演进：跨模态知识联邦与统一语义推理实践 揭秘千卡揭秘千卡 GPU GPU 集群如何高效训练多模态大模型：集群如何高效训练多模态大模型：vivo AI vivo AI 团队实战经验分享团队实战经验分享 推荐文章|Article Java Java 三十周年重磅发声：三十周年重磅发声：James Gosling James Gosling 狠批狠批 AI AI 是是“一场骗局一场骗局”，是科技高管，是科技高管“压榨程序员压榨程序员的新利器的新利器”Redis Redis 之父：哪怕被喷我也得说，之父：哪怕被喷我也得说，AI AI 远远落后于人

7、类程序员！远远落后于人类程序员！“前端已死前端已死”是危言耸听吗？是危言耸听吗？InfoQ 2025 InfoQ 2025 年趋势报告：软件架年趋势报告：软件架构和设计构和设计 AI AI 将如何颠覆传统软件开发团队将如何颠覆传统软件开发团队 API API 网关十五年演进：从微服务核心到网关十五年演进：从微服务核心到 AI AI 时代的神经网络时代的神经网络“AI“AI 六小虎六小虎”两年混战，新的较量开始两年混战，新的较量开始 架构师 2025 年第一季 本期主编 Tina 反馈 流程编辑 丁晓昀 商务合作 hezuogeekbang.org 发行人 霍泰稳 内容合作 1 InfoQ 架构

8、师2025年第一季 卷首语卷首语 十年前，我们惊叹于 AI 能“补全代码”“补个文档”。而今天，Agentic AI 已悄然改变了软件开发的整个生态，它不只是一个工具，更像是一个新物种能理解业务、自动编写、持续演进的“数字工程师”。这一波变革，比过去任何一次技术跃迁都更彻底。它深刻重塑了程序员的角色：写代码不再是核心能力，理解问题、设计解决方案、与智能体协同，成为新的竞争力。程序员正从以“活动”（如编码）为导向，转变为以“结果”（如解决问题）为导向，其核心职责是确保智能体伙伴交付的成果精准满足需求。它也颠覆了企业的技术策略：决策焦点从“该不该买 SaaS”转向了“能不能快速生成自己的软件”。购

9、买 SaaS 意味着放弃知识产权、受制于供应商的更新节奏，定制需求常被搁置。而 Agentic AI 提供了新路径：自建软件不仅显著提速，更能灵活构建那关键的 20%定制功能，精准契合业务需求。由于问题规模更小、开发周期更短、成本更低，且核心 IP 和创新节奏完全自主掌控，Agentic AI 为曾受困于预算、资源、人才的中小企业，开辟了一条前所未有的数字化捷径。这本关于“Agentic AI 十年”的电子书，很快会让你发现，我们已走得比想象中更远：Agent 能读懂你的老旧代码，能自己给出改造建议，甚至能写出文档解释“我为什么这么写”；它能遵守合规规则、复用已有代码、提醒你“这个方法在 re

10、po 里早就有”；它不是黑盒，而是“有逻辑、有记忆、有判断力的开发伙伴”。我们也许还没完全适应，但变化早已不可逆转。这不是一本预测未来的书，而是一本记录当下变化的书。十年，不只是一个技术周 2 卷首语 期，更是一种承诺。Agentic AI 带来的，不只是开发方式的变化，更是在推动整个数字世界加速进化。未来已经到来，智能正在成长。欢迎翻开这本书，和我们一起见证一个全新生态的诞生。3 InfoQ 架构师2025年第一季 传统数据仓库正在被传统数据仓库正在被 Agentic AI Agentic AI 吞噬？吞噬？Agentic Data Stack Agentic Data Stack 初探初探

11、 作者：郭炜 白鲸开源 CEO，Apache 基金会成员 从技术架构的角度看，我认为这一次的 AI 浪潮将深刻影响整个软件生态。DSS 系统的设计是以人作为最终消费者的决策支持逻辑为中心，然而，随着 Agentic AI 时代来临，最终的“消费者”更可能是 Agent，对数据仓库和复杂 ETL 链路将被重新设计，甚至消失。传统数据仓库偏重结构与查询模式，会被 Agentic Data Stack 架构强调语义与响应模式取代。本文作者的原标题为传统数据仓库正在被 Agentic AI 吞噬？Agentic Data Stack 初探。作者 郭炜 策划 Tina 4 特别专题|Agentic 软件

12、革命 引言：Snowflake 换 CEO 背后的信号 2024 年春天，云数据仓库的明星公司 Snowflake 宣布换帅，前 Google 广告业务负责人 Sridhar Ramaswamy 接替了曾带领 Snowflake 实现 600 亿美元估值的传奇 CEO Frank Slootman。如果你只是把这当成一次高管轮换，理解就不够透彻，因为这背后真正的隐喻是，数据仓库世界的范式，正在悄然巨变数据仓库世界的范式，正在悄然巨变。“技术的演进，从来不是线性推进，而是技术的跃迁，从 OLTP 数据库到 MPP 数据仓库，从 MPP 本地化计算到向量化云数仓引擎，都是一个技术跃迁到另一个技术，

13、从一个产品霸主到另一个产品霸主。”Slootman 是“数据仓库黄金时代”的代表。他押注云原生、押注多租户架构、押注 Snowflake 成为新一代数据平台的中枢，直接在市场上干掉了我从业的第一家公司当年的数据仓库霸主 Teradata（从 102 亿美金市值到现在 20 亿美金市值）。就在他功成身退的这一刻，Snowflake 官方博客的关键词悄然切换：AI-first、Agent-driven、语义导向的数据架构。这不是巧合，这是风向。同一时间，硅谷最具前瞻性的风投们正在押注“Agentic AI”这个新概念：AI 不再只是一个模型，它是一个能感知、能行动、有目标、有协作能力的能感知、能行

14、动、有目标、有协作能力的 Agent。那么问题来了：当 AI 不再只是“聊天工具”，而是能主动感知业务变化、理解意图并执行操作的智能体时，传统数据仓库这样的为“人”建造的决策支持系统还可以满足 Agent 的需要么？数据仓库曾是企业的“重要的数据资产”，如今，却可能沦为 Agent 的“数据素材库”。甚至连“素材”这个词都在贬值，因为 Agentic DataStack 可以直接访问原始数据，并以语义+数据的形式直接供给给上层各类 Sales Agent，Risk Agent 直接使用；而数据仓库里无语义、冗余的数据只能留给传统 BI 和数据开发人员来消费。5 InfoQ 架构师2025年第一

15、季 真正危险的不是被淘汰，而是你还在运行上一代范式的规则，而世界已经换了剧本。这不是对数仓的轻视，而是历史的轮回。正如当年 Hadoop、Iceberg 的崛起重构了数据湖，今天，Agentic AI 正在重写企业级的大数据架构。1970-2024：数据仓库架构是如何演进的 1970：数据仓库之父：Bill Inmon 数据仓库之父 Bill Inmon 首次提出“面向主题、集成、时变、不可更新的数据集合面向主题、集成、时变、不可更新的数据集合”这一概念（EDW），奠定了后半个世纪企业数据架构的基石。我本人也有幸在 20 多年前在北京大学的时候，在唐世谓教授带领下，学习并参与翻译数据仓库第一版

16、，这本书里对主题域、数据分层架构和缓变维（历史拉链表）的描述，从上个世纪一直沿用到今天，成为整体数据仓库的奠基之作。1983：Teradata 诞生，MPP 架构横空出世 1983 年诞生了未来 30 年横扫所有企业数据仓库基础设施的公司 Teradata，这也是我毕业后第一份工作所在的公司。首次将 MPP（大规模并行处理）架构引入数据处理系统，Teradata 凭借软硬一体的基于 Bynet 的 MPP 架构，在超大量级数据处理和复杂 SQL 的情况下，比 Oracle、DB2 效率高出数倍。第一次使用 Teradata 的时候我的惊喜不亚于后来我首次测试使用 ClickHouse 做宽表查

17、询时的惊诧。6 特别专题|Agentic 软件革命 我加入 Teradata 的时候，他还是一个 NCR 旗下的部门，我名片 logo 是这样子的，想了解 Teradata 的同学可以看我这一篇文章再见，我的数仓黄埔军校，Teradata 正式退出中国！。1996：Kimball 提出“雪花模型”，OLAP 引擎出现 继 Bill Immon 之后，Ralph Kimball 提出了“数据集市的概念”用星型模型和雪花模型重新定义了数据建模思维。此后数十年间，先建立数据集市还是先建立统一的数据仓库，变成数据仓库架构师不停争论的话题。“维度建模”和“雪花模型”成为数据工程师的名片；而 BI 报表底

18、层也出现了例如 Hyprion ESSbase，Cognos 等 MOLAP 引擎，OLAP 技术也终于有了系统方法论支撑。在几十年后，新一代的数据仓库公司也用了 Snowflake（雪花模型）作为其公司名称。2013：大数据概念爆发，Hadoop 风靡全球 随着 2006 年 Apache Hadoop 的横空出世，低存储成本的大数据系统被企业广泛引用。维克托迈尔-舍恩伯格在大数据时代中给大数据下了定义：“Volume（数据量）、（数据量）、Velocity（数据速度）、（数据速度）、Variety（数据多样性）、（数据多样性）、Value（数据价值）。（数据价值）。”从此轰轰烈烈的建立大数

19、据平台的过程开始起步，从此轰轰烈烈的建立大数据平台的过程开始起步，10 年内年内，Apache Hadoop、Hive、Spark、Kafka、DolphinScheduler、SeaTunnel、Iceberg一批大数据技术涌现，大数据平台开始动摇传统数据仓库的地位，以致于 2015 年后的中国，大多数中国企业存储 Pb 数据量级的数据平台不会用 MPP 架构传统意义数据仓库，而一定是用 Hadoop 或 7 InfoQ 架构师2025年第一季 者 Iceberg 大数据平台/数据湖。2015：Snowflake 横空出世，New DataStack 兴起 随着云的兴起，Marcin Zuk

20、owski“向量化”引擎论文的推出，Snowflake 横空出世用云原生分离存算的架构，彻底颠覆了传统 DW 思维。BI 工程师第一次可以“随需随用”、弹性扩缩容、不再焦虑集群调度和资源分配。Snowflake 把“数仓”变成了“数云”。它带领下一众新一代数据仓库技术栈兴起，Fivetran、Daggster、Airbyte、DBT、WhaleStudio 等一批新一代工具出现，在硅谷兴起了 New Data Stack（新数据技术栈）的风潮。的确，上一代 ETL 工具和编程工具还是上个世纪 80 年代兴起的 Informatica、Talend、DataStage 这些公司，新技术的兴起的确

21、需要新生态的形成。整体上，这几十年数据仓库的发展，无论是数据仓库、大数据平台和云数仓和数据湖，基本上整体架构都如下图所示：在 Inmon 时代，这个架构叫做 DSS 系统（决策支持系统），顾名思义，决策支持决策支持的就是人。整个数据仓库技术栈都是为人而设计的。的就是人。整个数据仓库技术栈都是为人而设计的。数据仓库的架构也是为数据开发工程师（Data Engineer）来设计的，所以会有 N 个主题域、要分原子层、汇总层、指标层来帮助 ETL 工程师进行开发，BI 工具也需要建 8 特别专题|Agentic 软件革命 立星型模型和雪花模型，拖拉拽可视化形成报表和 Dashboard。所有的消费者

22、都是人。但是，这一切，在大模型但是，这一切，在大模型 Agent 时代都会发生很大的变化。时代都会发生很大的变化。Agent 正在吞噬传统数据仓库？！2022 年底，OpenAI 推出 ChatGPT，引爆大模型时代。2023 年后，Llama、Claude、Gemini、GPT-4o、DeepSeek多模态模型加速演进，AI 不再只是语言模型，而是具备复杂任务理解与决策能力的“通用智能引擎”。2024 年，RAG 技术走向主流，LlamaIndex、LangChain、Dify 等工具广泛应用，AI 开始融合企业私域知识，成为真正“能查资料”的智能助手。2025 年，Agent 架构全面崛起

23、，AutoGPT、Function Calling、MCP 协议等技术和协议涌现，AI 不再只是聊天工具，而是具备感知、规划与执行能力的“数字员工”。在数据领域，大模型的到来也带来很大的冲击。你用过 ChatGPT 的 DataAnalyst 么？如果用过，你一定惊异它的表现，它可以根据一份数据多个角度来辅助一个业务人员做一份详细的数据分析报告。它几乎可以替代初级数据分析师。而在不同层次也出现了很多“自动化”工具，例如 ChatBI、TXT2SQL，各个维度都开始利用大模型和 Agent 自动化和半自动化地进行数据仓库开发过程。未来，会有越来越多的 Agent 出现，不仅仅是数据分析领域，更多

24、的的广告投放 9 InfoQ 架构师2025年第一季 Agent，客服 Agent，Risk Managment Agent，它们将逐步解放现有的业务人员，替代他们与系统之间的交互。最终，最终，AI 不再是“被动回答问题的工具”，而是“主动达成目标的智能体”。不再是“被动回答问题的工具”，而是“主动达成目标的智能体”。过去 20 多年，数据平台的“用户”通常是数据工程师、分析师和 BI 人员。而未来的 20 年，从分析师到供应链，每一个岗位的角色都可能被从分析师到供应链，每一个岗位的角色都可能被 Agent 所重构所重构：营销人员配有 Campaign Agent，它可以自动整合多渠道数据、优

25、化投放、生成文案；客服坐席配有 Support Agent，它就不只是聊天机器人，而是具备知识图谱和上下文记忆的专属助理；供应链部门配有 Procurement Agent，它就能解析订单、追踪货期、调用 ERP 数据并自动补货；法务有 Compliance Agent，HR 有 Hiring Agent，董事会也有 Board Agent 你过去每天写的 SQL、做的分析报告、开的运营会，正在变成一个个正在变成一个个 Agent 的触的触发动作、语义指令和自动响应发动作、语义指令和自动响应。但一个现实问题随之而来：如果最终数据消费者都已经是 Agent，数据仓库开发也是 Agent，连具体使

26、用数据的决策者都是 Agent 而不是“用户”的时候，原先为人设计的“决策支持系统 DSS”10 特别专题|Agentic 软件革命 数据仓库整体架构还成立么？学过软件工程的 IT 码农们都知道，设计一个系统首先要做的图就是“Use Case”图，确定系统和用户的边界和操作场景与行为。当数据仓库的用户从人变成当数据仓库的用户从人变成 Agent 的时候，原先的时候，原先 Bill Inmon 老爷子设计的整体老爷子设计的整体 DSS 架构还成立么？我个人认为，不成立了。架构还成立么？我个人认为，不成立了。软件用户变了，软件也必须变。软件用户变了，软件也必须变。Agent 的爆发，并不是大模型本

27、身的胜利，而是“用户体验认知”被彻底颠覆：过去的数据系统，是“拉模式”：用户知道问题、查询数据、提取结论。未来的 Agent，是“推模式”：系统主动感知变化，理解意图，生成决策建议系统主动感知变化，理解意图，生成决策建议。这就像我们从传统地图升级到高德导航：你不再需要知道“路在哪儿”，而是告诉系统你要去哪，它带你过去。传统数据仓库偏重结构与查询，而 Agentic 架构强调语义与响应。简而言之，谁能理解业务语言，谁就能统治数据世界谁能理解业务语言，谁就能统治数据世界。Agentic Data Stack 和自带上文的数据 Contextual Data Unit 对于 Agent 自动开发和使

28、用来讲，当前数据仓库整体设计并不是为大模型和 Agent 设计的，所以，里面存储的都是“裸”数据。只有具体的数值和字段名称，而这个数值、这个字段名称是做什么用的，都存在另外一个叫做“数据资产”的项目里。想把每个数值、字段搞明白，需要进行一个“数据治理”的项目才可以完成。这个设计，对于语义才可以进行推理的大模型和 Agent 太不友好了。所以，如果为 Agent 和 大模型重新设计大数据存储系统的话，一定需要把“数据”+“语义”放到一起存储，我管它叫：Contextual Data Unit(CDU)：语义+数据组合单元，每个数据自带语义和语义解释的二元组合。把过去在数据目录（Data Cata

29、log）里的信息，融合在每个数据条目当中，减少 11 InfoQ 架构师2025年第一季 Agent 和大模型访问的时候重新从其它系统里检索的时间和错误概率。同时，CDU 里面的语义数据也是从业务系统里经过总结和推衍得来的，所以，这里的数据本身，就是在 Data Flow Agent 从源头就组合成 CDU，ETL/Data Ingesstion 到 Agentic Data Lake 里，而不是后期生成的。换句话说，数据治理和溯源的过程是融入在 Agent 的自动开发过程当中，而不是现在的做法在数据进入数据仓库之后，再开始血缘分析、数据治理一系列的复杂操作，这样做的结果数据很容易具有争议。到

30、这里，大家应该看懂我的思路了，Agentic AI 时代，从过去的数据仓库 ETL 到数据存储，到数据应用分析，都会因为消费者是 Agent 和大模型而发生很大的变化。为了服务这些智能体，传统数据平台必须演进出一套 Agent 可调用、语义感知、事件驱可调用、语义感知、事件驱动的数据架构动的数据架构也就是我们所说的 Agentic Data Stack。Agentic Data Stack：在 Agent 时代，从底层数据获取“语义+数据”的工具，到支持 CDU 格式计算和存储的计算平台，到最终供给各 Agent 使用数据的数据交互层新一代的数据技术栈。我大胆猜测下，未来 Agentic Da

31、ta Stack 可能有以下组件组成：“数据交互层”（Semantic Orchestrator）：不再是传统意义上的 BI/查询界面，而是变成 Agentic 数据架构中的“大脑”和“指挥中心”，它通过自然语言理解 12 特别专题|Agentic 软件革命 和语义推理能力，作为 其它 Agent 与底层数据资源之间的桥梁，实现智能化、多轮次的数据交互与服务生成。“数据存储层”（Data Mesh）：不再是传统意义上的 Data Warehouse（数据仓库）或 Data Lake（数据湖），而变成了一种服务性的、计算友好的数据融合层。这个层的本质是“存储提供融合语义+数据，既可供给大模型进行

32、复杂计算的存储，也可以提供即时复杂计算能力”“数据处理层”（Data Flow Agent）：不再是“搬数据”，而是“理解和编排数据”；不再定时运行，而是 事件驱动+意图驱动；能主动发现数据变化、分析表结构、理解业务语义、做出响应。在 Agentic AI 时代，数据仓库和大数据平台的建设周期将极致地缩短，新数据的获取经过 Data Flow Agent 的自发发现，在 Data Mesh 中预存储，Semantic Orchestrator 解析和实际业务场景的业务口径与对应，最终实现从业务需求到数据响应的“即时计算”。大模型解决的是智慧的大脑，大模型解决的是智慧的大脑，Agent 解决的是

33、手和脚，解决的是手和脚，Agentic DataStack 是让是让 LLM 和和 Agent 具有适合大模型时代快速的数据获取能力。具有适合大模型时代快速的数据获取能力。Agentic AI 时代，随着建立新一代“数据仓库”成本显著降低，拥有可以自由对话查询，拥有相关的数据不再是大企业的权利，更是小企业甚至个人的权利。你可以把你的 Google Drive，家里的私有 NAS，电脑上的 PDF，手机里的 APP 订单通过 Data Flow Agent 捕获到个人的数据存储里，用交互层 APP 快速查询例如“上个月去 Disney Land 游玩一共花了多少钱”这种过去问题，而这种问题过去需

34、要从多个平台整理到 Excel 表格里记录，甚至还可以解决“找到 5 年前保险订单及相关合同”这种复杂问题。而这些并不是天方夜谭，最近由白鲸开源主导的 Apache SeaTunnel 社区里发布了 Apache SeaTunnel MCP Server，已经开始 了迈向 Data Flow Agent 的步伐。当然，中间还有很多未解决的技术问题，例如 A2A 协议还不够完善，DataMesh 层的“语义+数据”存储计算结构还没有突破；把过去数据治理的成果变为 Semantic Orchestrator 输入也是需要时间来探索。但是，大模型和 Agent 时代的到来，对于整个数据分析行业来说，

35、就像从过去没有 SQL 语言到出现 SQL 语言之后的进展一样，都会发生深刻的变化。13 InfoQ 架构师2025年第一季 打败你的，永远不是你现在眼中看到的所谓的“竞争对手”。讲个故事，小时候，我熟悉两个自行车品牌永久和凤凰。它们曾在“加速轴”技术上竞争，看谁能跑得更快。然而，真正颠覆自行车市场的，却是一家外卖公司推出的共享单车，彻底改变了整个行业格局。随着 Agent 时代的到来，许多曾被视为核心的产品路线可能会失去意义。在低头看路的时候，也要抬头看天在低头看路的时候，也要抬头看天。小结：活在当下，放眼未来 我在 AICon/AWS Community Day 和其它几个技术峰会上分享这

36、个认知的时候，台下观众完全分成两派：一派是“降临派”，认为我估计 Agentic Data Stack 到来 5-10 年 太保守，AI 发展日新月异，5 年内 Agentic Data Stack 就会成型。一派是“保守派”，认为 AI Agent 影响整个数据仓库架构太扯了，不可能发生，当前数据仓库存储形式就是最优 ROI 的数据存储方式，任何不是最优 ROI 的形式都无法普遍商业化，都只是空中楼阁，不要听这些“AI 专家”乱讲。而我个人是“中间派”：在趋势上，我认为我认为 Agentic Data Stack 形成是一个必然形成是一个必然，这轮 AI 对技术架构的影响和前几次是完全不同的

37、。不能只从技术观点上看数据仓库存不能只从技术观点上看数据仓库存储计算层储计算层 ROI 的产出，而要看当前企业数据仓库整体建设过程和维护过程的投入算总的产出，而要看当前企业数据仓库整体建设过程和维护过程的投入算总账账。当前来看，实时数据仓库的兴起，数据湖的扩大，现在的数据仓库设计的层数在明显减少（我甚至认为我们这一批当年 Teradata 训练过的模型架构师退役之后，市场上都没有专业的数据仓库模型架构师了，因为业务变化太快，传统数据仓库专业模型设计跟不上变化）。所以在高速变更的业务情况下，传统数据仓库理论自己也在迭代，（现在实时数据仓库模型变成 2 层了，而不是过去的 3 层、4 层），只不过

38、我看到的是未来 Agentic AI 时代一步到位的趋势而已。算总账，Agentic Data Stack 会明显比现在的全套数据仓库 New Data Stack ROI 高很多。但是，这个趋势也不是马上能降临的，以我 2016 看中 ClickHouse 这个产品开始在中国运营社区，到 2020 年几乎成就了一代“实时 OLAP”引擎标准的时间来看，有现成产品到被大家接受也要 4-5 年时间，而 Agentic Data Stack 只有部分组件有一些创业公司雏形，大部分组件和核心产品还没有出世，也不可能 5 年内就一统天下。如果说节奏，我估计怎样也在实时数据仓库和数据湖被大面积企业接受之

39、后，才可能到下一步 Agentic Data Stack。14 特别专题|Agentic 软件革命“不是 AI 取代你，而是会用 AI 的人取代你；不是数据仓库被吞噬了，而是传统数据仓库偏重结构与查询模式，被 Agentic Data Stack 架构强调语义与响应模式取代了。就像用上高德地图导航的人，不会再去看传统地图了。”Agentic Data Stack 的门已经徐徐打开。的门已经徐徐打开。你，准备好了吗？你，准备好了吗？15 InfoQ 架构师2025年第一季 Agentic AI Agentic AI 要终结数据库和要终结数据库和 SaaSSaaS？大厂掌门？大厂掌门人公开互撕，焦

40、虑的人公开互撕，焦虑的 CEO CEO 们押上了不同的技们押上了不同的技术路线术路线 Agent 正在成为 2025 年 AI 世界最炙手可热的关键词之一。无论是大模型厂商、AI 初创公司，还是企业级应用团队，几乎都在讨论“多智能体协作”“自动化决策流程”以及“具备工具调用能力的 AI 系统”。谷歌、英伟达等科技巨头纷纷布局，上个月亚马逊还成立了一个专注于 Agentic AI 的新部门，初创公司们也争相推出各类“Agent”产品。开源社区也不甘示弱，从 Lang-Graph 到 Agent SDK、AutoGen、CrewAI，一波 Agent 框架竞相登场，掀起了继大模型作者 Tina 1

41、6 特别专题|Agentic 软件革命 之后的第二轮工具潮。连大厂掌门人也开始在公开场合“互呛”。微软 CEO Satya Nadella 高调宣称：“我们所知的 SaaS 时代即将结束Agent 将成为核心驱动力”。而 Salesforce CEO Marc Beinoff 则直接嘲讽微软的 Copilot，称其为“Clippy 2.0”：“根本不起作用，而且没有任何准确性”。Clippy（回形针）即 Office 虚拟助手，是微软上世纪推出的基于规则的代理，为用户吐槽最多的失败设计之一。视频地址视频地址：https:/ 言辞之锋利，背后其实是对 Agentic AI 两种截然不同落地路径的

42、分歧。一条是微软 Nadella 倡议的“面向全平台的智能代理框架”路线。按照他们的设想，未来将出现一个 AI 操作系统，能够调度多个智能体，并且这些智能体可以在整个企业内无缝地传递任务、消息和知识。Nadella 认为，这是一场从“App Stack”到“Agent Stack”的根本性变革。过去，我们依赖前端 UI 驱动的应用形态，每一个业务场景都被拆分为独立的 App，用户通过操作完成任务。未来，主导者将是 Agent，它能感知用户意图，基于数据、模型和推理链条，完成决策和自动执行。在这种架构转变下，当前的 SaaS 等应用因为其本质上是嵌入商业逻辑的数据库，未来这些逻辑会被 Agent

43、 接管，由 Agent 去做增删改查，在多个数据库之间工作，所有的逻辑都会转移到 AI 层。而一旦 AI 层成为主导，背后的数据库最终也会开始被替代。本质上，这是微软构建通用人工智能代理体系、通过底层架构向企业应用生态渗透的战略布局。正如数势科技 AI 负责人李飞博士在分析中指出，微软此举旨在依托其既有生态系统优势，打造覆盖全场景的 AI 接入平台，形成对垂直领域应用的聚合效应。通过构建人工智能交互的核心枢纽，微软试图确立其在产业智能化转型中的顶层平台地位，实现对各类专业化应用的系统性整合。大模型公司或云资源提供商大多支持这种“通用”入口性质的路线。比如 OpenAI 17 InfoQ 架构师

44、2025年第一季 就肯定倾向于 Nadella 的思路，因为在它看来，所有的 Agent 本质上都是对其大模型能力的延伸和增强。对 OpenAI 来说，构建通用 Agent 能将所有应用集成在自己的能力框架之下，使其成为一个统一入口。类似的例子还有 Manus，以及 AutoGLM 沉思等。无论是微软、OpenAI，还是 Manus、沉思，这背后体现的，依然是一场关于“谁来掌握 AI 入口权”的竞争。与之相对，另一条路线则由 Salesforce 所代表。Salesforce 的思路是从现有企业软件栈出发，强调以垂直领域（如 CRM）为根基，推动业务逻辑的 AI 原生重构。他们不认为 AI 会

45、“取代”现有 SaaS 应用，而是主张 AI 和 SaaS 深度集成，将 Agent 机制嵌入业务流程中，通过业务数据和流程去驱动 Agent 的运行和决策。Agent 不是一个外部工具或统一入口，而只是整个流程当中的一个节点。相较于微软自底而上的通用化策略，Salesforce 的设计思路是自顶向下，从实际的业务流程出发，反向构建 Agentic AI 能力，旨在复用并增强现有的各类 SaaS 应用。事实上，许多没有庞大通用平台基础、专注于 ToB 软件或垂直场景的企业，可能会更倾向于 Salesforce 这种贴近业务、务实的路线。他们往往是先搭建好业务或工作流程，然后将 Agent 融入

46、这些流程中，使其专注于解决特定垂直场景的问题。哪种路径更具可行性？贴补丁式 Agentic，能落地但改不了旧系统的命 Salesforce 的 CEO 对微软 Copilot 的攻击颇为犀利，甚至直言这是“微软的一场巨大灾难”。他公开表示，自己与多位微软客户交流后发现，“他们并没有发现自己因为这项 Copilot 技术而发生了改变，很多人几乎没怎么使用这个功能”。相比之下，Salesforce 则宣称其平台每周处理多达两万亿笔企业 AI 交易。有意思的是，Salesforce 自家的平台最初也叫 Einstein Copilot。更耐人寻味的是，在弃用“Copilot”这个名称后，Beniof

47、f 便开始公开批评微软的 Copilot 产品。并且 Salesforce 坚称，从 Einstein Copilot 更名为 Agentforce，绝不仅仅是换了一个名字，而 18 特别专题|Agentic 软件革命 是其底层架构也经历了重要的调整。从 Salesforce 架构师的公开演讲来看，Einstein Copilot 在与用户进行交互时使用的是“Chain of Thought”（思维链）模式，而 Agentforce 的一个关键进展，就是用 React prompting 替代了效果不好的传统的思维链。其次是引入 Topic 分类机制，解决 Copilot 在对话过程中难以将任

48、务限定在某个特定的范围内的问题。然后是改进了 LLM 的响应方式，Copilot 直接返回未经处理的后端数据，导致用户难以理解，而 Agentforce 则会利用 LLM 对原始数据进行自然语言包装，使其更易读懂。最后是引入了主动触发能力，与 Copilot 依赖用户主动发起对话不同，Agentforce 希望实现基于特定数据库操作的自动触发，无需用户干预即可启动 Agent 执行任务。可以说，早期的 Einstein Copilot 侧重于通过对话触发和调用预设的比如销量预测等算法，实现人机协作。而 Agentforce 的目标似乎是转向更自主的任务执行模式，用户设定目标后，系统能够自主规划

49、并执行工作流程，最终呈现结果。因此，尽管 Salesforce 强调这是架构的演进，但其核心仍然是提升 AI 在任务执行中的自主性和智能化水平。不仅如此，Beinoff 还评价微软是“快速追随者”，并称：“他们肯定会像往常一样想抄袭我们，向我们靠拢。但我们现在已经有数千客户在实际使用我们的产品。”根据截至 3 月的最新数据显示，双方的 Agent 都有大规模的落地，Salesforce 宣称拥有约 15 万名客户，微软则表示已有 16 万客户，基于 Copilot 打造出了 40 万个 Agent。然而，白鲸开源 CEO 郭炜一针见血地指出，当前微软的 Agent 只是个人用户辅助工具，和 N

50、adella 技术路线里要实现的最终理想，并不是同一个东西。微软对 Agentic AI 的设想是“OS”级别的变革。它构想中的 AI 操作系统不仅要能够调度多个智能体，还要持续保持上下文状态、理解用户意图，并在多种数据源和系统能力之间进行协调。在这一架构中，业务逻辑将由 Agent 全面接管，而“状态管理器”（State Manager）被视为 AI 操作系统的核心组件只有具备对用户状态的持续记忆，Agent 才能真正理解用户是谁、在做什么、希望实现什么目标，类似于 AI 世界中的 19 InfoQ 架构师2025年第一季“内存管理”。为此，微软正在打通自身所有产品线，并与 OpenAI 这

51、样的企业合作，构建一个开放的智能体生态平台。而 Salesforce 的 Agentforce，“它都不是行业智能体，只是 CRM 生态线的智能体。目前技术手段都实现了个高级版本 RPA/按键精灵，只不过通过大语言模型交互可以自动做一些分拆动作，做一些组合罢了。和当年移动互联网出来时候的塞班操作系统一样，属于早期婴儿版本的 Agentic AI。”当前 Salesforce 模式虽能被快速推广落地，但是这件事情的门槛也不高，很多创业公司都可以做到类似的事情，大公司就更不用说了。这些做法本质上仍停留在对原有软件和交互流程的增强层面，就像当年微软试图将 Windows 系统移植到手机上一样看似容易

52、实现，但并不是最优解。真正开启移动互联网时代的，是 iPhone 和 iOS 的诞生，它们从底层重新定义了系统与用户之间的交互逻辑。正因如此，Nadella 才会提出“所有软件和 SaaS 都将被重构”的观点，因为他预见到了 Agentic AI 时代的来临。如果我们只是把 Agent 嵌入到现有软件中去打补丁，就像是把 Windows 装在手机上表面上可行，但远未触及这场变革的真正核心。真正的 Agentic AI 将倒逼整个技术体系重建 短期来看，复用现有 SaaS API 或许是 Agentic AI 实现功能落地的捷径，对现有流程体系的冲击也相对较小。然而，从长期视角出发，Nadell

53、a 所代表的观点显然更具颠覆性：大模型和 Agent 的到来会彻底重塑整个软件和 SaaS 生态。郭炜认为，甚至 Nadella 所描述的“代理程序在多个数据库之间工作”的设想，还不够 Agentic AI。因为在这一新范式下，整体的技术框架都会要被重新设计。传统数据库的设计初衷，是为了服务于“人类决策”的时代。从数据库到数据仓库，所有的设计都是上个世纪，为了辅助人类做决策、完成信息记录而构建的。于是我们看到了复杂的 CRUD 操作、DAO 层、数据库层、数据仓库层以及 ETL 流程，它们共同支撑起了人与数据之间的交互逻辑。然而，在 Agent 成为主要用户的背景下，这些为“人类使用”而生的复

54、杂数据处 20 特别专题|Agentic 软件革命 理体系是否仍然必要，正面临质疑。未来的存储不一定是数据库形式了，使用的方式也必然不是 SQL 了。顺着 Satya 的逻辑推演，被重塑的不只是 SaaS，更是整个技术架构生态。数据库技术，甚至是基础理论会被倒逼升级，传统的 No-SQL，New-SQL 都不适用于未来 Agentic AI 的场景。就像从软件工程学角度来看，所有的软件设计都是从 Use Case（UML）图开始设计的，而 User 都变了，凭什么底层的技术还是原来的技术体系呢？AWS Agentic AI 主任科学家章毅也赞同整个技术架构生态体系会被重构，他进一步指出，当前

55、Agent 利用 API 调用已有的数据库系统进行知识查询和整合（典型 RAG 架构）能够覆盖一些基本的业务逻辑，但是知识、信息碎片化（以不同模态和格式存储于多个数据库中）对 AI Agent 高效搜索、链接、归纳、提炼、使用与更新信息带来很大的困难。这必然会带动对数据存储、管理系统进行重新思考和设计。而且，作为 AI 操作系统的核心的记忆层“能否实现”也是未知数。Salesforce 的 Agentforce 架构在预设的业务流程中，Agent 可以有效地访问和利用先前操作产生的数据和状态信息，形成一种上下文记忆。但一旦进入微软所设想的跨系统、跨复杂场景环境，Agent 就没有一个稳定的获取

56、记忆的依托点，出错概率显著增加，显然比 Salesforce 这种嵌入式设计的难度系数大。微软设想的“AI 操作系统”中，状态管理的关键在于让 AI 能够跨不同的应用和设备记住信息，并需要有一种结合短期交互与长期语义记忆的机制。这实际上是将来 Agentic AI 时代替代数据库地位的关键组件，然而在实际架构层面，挑战远超预期。也有观点认为这并不是一个简单的“状态管理”，而是是在云端为每个用户构建一个“虚拟人生”系统需要持续记录用户的行为、偏好与选择，形成大模型的短期记忆和长期语义。问题在于，这种能力无法用向量将它描述清楚，并且目前还不知道可以用什么技术实现。可以说，微软的 Agentic A

57、I 代表了一种技术理想主义。虽然很多厂商在尝试，但这个模式整体还太早，大模型和 Agent 本身都还没有进化完全。当前阶段，更现实的路径是 Salesforce 式 Agent，其类 RPA 的特性使其更容 21 InfoQ 架构师2025年第一季 易被企业接受。毕竟，在当下，企业更愿意为确定性买单。但长期来看，传统企业软件终会被取代，因为软件只不过是规范流程，信息传递，实现多人协同的一种方式，如果有更先进的更高效的管理和交流模式，旧有模式一定会替换。今天的企业软件形态必然会被颠覆，这正如固定电话被移动设备取代、再被微信等应用彻底重构通讯方式一样。Agentic AI 时代会是一个和移动互联网

58、一样的全新的时代。不过，这需要的是一次自底向上全套生态的改变，挑战不亚于当年的“云原生”转型，甚至更甚。这种全模式的创新，或许只有在底层信息科学取得突破之后，才有真正实现的可能。“MoE”是个折中选择 微软式的通用 Agent 路线，听起来诱人，但在现实中目前还行不通。而在大模型的最新演进中，已经出现越来越多转向 Mixture of experts（MoE）架构的趋势。MoE 背后的理念正是将任务拆分给更擅长的“专家”，而不是试图构建一个无所不能的模型。如果在大模型里大家能接受 MoE 的思想，那么，同样的道理，在实现 Agent 的时候，也一样可以采用这种方式：不是打造一个“超级大脑”，而

59、是强调分工协作、各尽其职。而且，当前现实来看，因为 Agent 能力太弱，还是多个专科 Agent 来做比较合适，例如 Salesforce 的 Agent、SAP 的 Agent 等等。就算未来的 Agent 即使是基于一个“超级大脑”的路线，这个“大脑”中也必然存在多个并行的、具有不同专属能力的组件，而不是靠一个模型包打天下。事实上，哪怕使用少数甚至是同一个基础模型，构建多个专家 Agent 并通过高效协同完成复杂任务，无疑是一个有效的设计范式，是同大模型能力提升演化协同共进、互补互助的方法。更重要的是，所谓“通用”与“垂直”的两条路线，从产业实践来看，并非互斥，而是根据不同企业的战略优势

60、进行差异化布局。微软聚焦平台型能力，将 Agent 集中 22 特别专题|Agentic 软件革命 于 Copilot 品牌下统一推进，同时也不放弃在 Microsoft 365 等具体场景中的垂直落地。Salesforce 以 SaaS 为核心，在 CRM 等场景深耕垂直 Agent，同时借助 Agentforce 等平台工具，向多云生态拓展。平台化和垂直场景的结合，正成为行业主流趋势。打平台牌需要非常大量的固有成本。对于中小企业而言、迅速找到垂直 Agent 应用并落地，会是更重要的当务之急。从“能不能做”到“做得成、做得起”回顾 Agentic AI 近两年多的发展，我们看到，行业正经历

61、着从对大语言模型的初步探索，到逐步赋予其感知、理解和行动能力的关键阶段。从最初直接依赖 LLM 进行信息处理，逐步演进到利用检索增强生成（RAG）技术来扩展其知识覆盖范围。随后，多模态模型的出现使其能够处理更丰富的输入和输出形式。紧接着，行业进入了“Agentic 对话”阶段，核心在于赋予模型执行动作的能力，使其不再仅仅是内容生成工具。为模型添加可执行功能被视为一个重要的里程碑。关于 Agentic AI 最早的雏形，存在两种主要观点：一种认为是 OpenAI 推出的“Function Call”功能，它使得大模型能够根据需求调用外部函数。另一种观点则认为，真正的更早出现的 AutoGPT，因

62、为 Function Call 并不是一个完整的链路。AutoGPT 是在 OpenAI 的 ChatGPT(GPT-3.5)发布后，由 Toran Bruce Richards（苏格兰爱丁堡人工智能公司 Significant Gravitas Ltd.的创始人兼首席开发者）在 2023 年 3 月份创建的演示项目，展示了如何利用大型模型实现任务的自动分解和执行。此后，Agent 的完整生态闭环首次被较为系统地提出，这要归功于 OpenAI 研究员 Lilian Weng 在 X（原 Twitter）上分享的 Agent 工作流程文章，清晰地描绘了包括“目标规划、工具调用、执行、结果反思”等

63、关键环节，被认为是 Agent 架构逐步演进的重要起点。受此启发，业界围绕 AI Agent 展开了大量的探索与实践，并逐渐形成了更为系统化的工程方法。23 InfoQ 架构师2025年第一季 数势科技的 Agent 系统演进，也反映了 Agent 技术自身的发展历程。其系统经历了从 1.0 到 3.0 的迭代：初期的 1.0 阶段，主要实现了单个 Agent 对数据工具的调用。进入 2.0 阶段，系统引入了与环境交互的反馈机制，并强化了自我反思与迭代能力。发展到 3.0 阶段，则根据用户需求，从单 Agent 升级为多 Agent 协作机制，以覆盖更广泛的场景和角色。Agentic AI 还

64、有哪些挑战？当前，Agentic AI 系统构建中，任务编排依然是极具挑战的技术难题。相较于 Salesforce 等平台采用的预定义工作流模式（其泛化性受限），微软提出了通过 AI 实时理解规则并动态生成编排规则，进而连接现有 API 的设想。但真正落地时，问题远比想象中复杂。24 特别专题|Agentic 软件革命 当业务流程仅涉及少量节点时，编排复杂度尚在可控范围内。然而当节点数量增长至 10 个、20 个甚至 100 个量级，且涉及多系统、API 和工具的协同工作时，确定正确的线性执行顺序（如 ABCDEFG.或 ACBDEFG.）将面临组合爆炸问题100 个节点的全排列组合达 100

65、!种。每新增一个节点，系统复杂度将以阶乘级数倍增，这种非线性增长特性使得大规模编排系统极易产生级联错误。正如李飞博士指出的：“当编排网络中出现单个节点顺序错位时，整个拓扑结构的执行逻辑都将发生系统性偏差。”基于实际构建 Agent 的经验，合理的工作流编排是核心难点。一旦工作流得以确定，后续 API 的输入输出参数便相对固定。因此，能否实现准确高效的工作流编排，直接关乎 Agentic AI 系统的可靠性。尽管如此，Agentic AI 根本性的进步仍然依赖于底层大模型能力的提升。“大模型基座本身有错误率，Agent 和软件其实是在给大模型的错误率或者幻觉去做兜底的。”因此无论上层应用多么创新

66、，如果底层模型能力没有显著进步，系统所能解决的问题依然有限。如今的大模型在各种基准测试中表现越来越好，但要真正实现具备自主性的 Agent 系统，还存在不小的挑战。Google 首席科学家 Jeff Dean 刚好在 4 月底的一次演讲中透露了目前大模型实际能力：当前模型大致能以 60%到 70%的准确率，完成三到五步的小任务，能在有限范围内调用工具处理一些简单请求。但真正理想的智能体，应当能够面对模糊而复杂的目标，自主拆解并完成上千个步骤，完成相当于一个月人类工作量的任务，且准确率达到 95%。从现在的能力到这一目标之间，仍有巨大差距。这一演进过程可能会经历多个阶段从胜任 35 步的任务，提

67、升到能够稳定完成 10 步以上的流程，最终迈向真正具备规划、执行、反馈能力的智能体系统。章毅则进一步指出，目前的前沿大模型中能够全面达到打造具有高智能、高自主性 Agent 要求的选择并不多、甚至可以说非常少。即便是在大模型服务平台如 AWS Bedrock 提供了多个主流模型（如 Claude、LLaMA、Amazon Nova、Mistral Mixtral 等等）供开发者选择的背景下，真正能够满足构造 Agent 能力要求的模型还是主要局限于 Anthropic Claude 的几个最新版本（Sonnet 25 InfoQ 架构师2025年第一季 3.5/3.7 或者 Haiku 3.0

68、/3.5）。从短期落地的可行性角度看，聚焦一个或少数几个前沿大模型会得到比较好的投资回报率。“每次对话 2 美元”“节省数百万美元”“一半客服被 AI 替代”这类故事，已经成为 AI 圈标配的营销剧本。Salesforce 和微软正是靠这样的案例，推广他们的智能 Agent 系统。这些故事构建了一个极具吸引力的愿景：AI 代理系统不仅能显著提升效率，还能直接压缩运营成本，甚至重塑组织结构。但真正落地到企业环境中，很多人才发现，这场变革的代价远比想象中高。以 Salesforce 的 Agentforce 为例，其官网宣传“每次对话 2 美元起”。但在实际合同中，超出 1000 次免费额度的部分

69、，会按每次 2.50 美元收费。也就是说，虽然预购有折扣，但一旦使用超额，就需要按每次 2.50 美元支付。相比微软 Copilot 那种更强调“按有效消息计费、结果导向”的模式，Salesforce 更像是“按次数定额收钱”，不管任务是否真正成功完成。26 特别专题|Agentic 软件革命 如果按当前国内大模型的标准报价（如 0.0008 元/千 token）折算，这“每次 2 美元”的对话，意味着系统可能要消耗接近 1800 万 token。这不仅意味着成本高昂，也从侧面反映出任务流程可能执行起来极其复杂。一旦规模化使用，成本压力会骤然放大：以一家中型企业为例，1000 名员工、每人每天

70、调用 10 次，每天光软件费就超过 2 万美元，月支出高达 60 万美元。有从业者直言：“比传统软件贵多了。”对于像 Dow 这样有能力重构系统流程的大企业而言，AI Agent 可能真能创造“几百万美元的节省”；但对大多数公司来说，这种奇迹并不容易复刻。节省成本的路径，远比那些营销故事复杂。这也引出了一个更现实的问题：企业到底该怎么上 Agent？你的企业该怎么上 Agent？对大多数企业来说，“要不要上 Agent”其实早就不是问题了。一旦基础系统和生态完备，未来 Agentic AI 就像移动互联网一样蓬勃发展。技术领袖的共识也正在浮现：AWS 等云厂商认为 AI Agent 将会重新定

71、义云服务的未来，明确将 Agent 定位为“下一代基础设施”，提供模型托管、推理算力以及致力开发针对 AI Agent 的可重用组件和功能模块。但越是全行业热捧的趋势，越需要冷静评估其落地的现实条件。“不是十倍提效，就不值得上。”“不是十倍提效，就不值得上。”技术部署要看“性价比”。李飞直言：“如果不是十倍时效，这个场景的意义其实不大”。也就是说，如果原来 20 小时能完成一个任务，现在 Agent 缩短到 10 小时，效率虽提升了一倍，但不足以支撑 AI Agent 高昂的 27 InfoQ 架构师2025年第一季 部署成本，其实企业很可能不买账。特别是在企业端，Agent 本质上是对业务流

72、程的自动编排，必须依赖业务与技术的深度协同：业务人员提供流程知识，技术人员将这种 Know-how 嵌入 Agent 开发中，才能让 Agent 真正融入企业工作流。“通用“通用 Agent，不适合企业。”，不适合企业。”目前一些企业已经准备好了部署 Agent，但“通用 Agent”更适合 C 端用户。因为 C 端的容错性更高，“这个任务不行就换下一个”，但企业不能容忍任务中断或出错，一旦流程关键环节失败，就可能影响整个业务判断。“在企业当中，大部分工作都是严谨的，你这个任务给我执行错了或者执行不出来，我就认为你这个软件不行。”因此，企业更倾向从垂直场景做起，把 Agent 深度嵌入到已有业

73、务流程中，通过产品设计和流程兜底，把错误率降到最低，才能真正达成企业级可用。“垂直 Agent 在今年其实已经准备好了采购”，但不同领域成熟度差异较大，最终落地效果也存在显著差异。同时还应优先选择容错性相对较高的任务切入，比如在“研报分析”这类允许人工校验和干预的内容生成任务，避免一上来就部署端到端决策系统，“Human-in-the-loop”机制可以显著降低幻觉和错误的风险。“不要急着全部用“不要急着全部用 Agent。”。”“现在的 Agent 就像当年的 Windows Phone。”郭炜给出了一个务实的策略：不要过早的迷信于现在的 agent，先采用 RPA+Agent 模式来实现企

74、业内部流程自动化，等待外部技术条件成熟（10 年+），在开始考虑公司全面 Agent 化。“不执着于单一的架构范式。”“不执着于单一的架构范式。”在全球范围内，亚马逊是最早系统化推动 Agentic AI 的企业之一。从 Alexa 的智能化重构、“Buy for Me”融入购物体验，到 Amazon Q 面向开发者的代码助理，再到电商目录处理、合规审核，或者服务于公司员工的 HR 信息系统，Agent 技术已在其多个业务线并行推进。从这些项目中，可以看到亚马逊“全面拥抱 AI agent 技术的明显趋势”。正如章毅所说：“公司各个业务部门都非常重视 AI Agent 可能带来的机遇和挑战，所

75、以有各类并行的、针对不同应用场景的尝试。”值得一提的是，亚马逊对 Agent 架构持开放态度，并不执着于单一标准化框架。AI agent 作为一个新兴的领域，技术架构仍然有很大的不稳定、不确定性，新生框架鳞次栉比。有的框架诞生不到六个月，时间长的也不过只有两年多。在它们成熟、演化、归一的过程中，亚马逊会对这些框架灵活应用。28 特别专题|Agentic 软件革命“Agent 是个日新月异的领域，保持灵活性而不迷信某一种架构，将会是更务实的做法。”对于正处于数字化转型关键阶段的企业，建议从具体场景出发，快速构建 Agent 原型并验证可行性。他提醒，尽管开发门槛已降低，但有效的评测机制仍是选型与

76、演进的关键。相比之下，中国企业在 Agentic AI 落地上正面临不同的挑战与机会。从落地模式来看，郭炜认为目前大多数中国企业更倾向于 Salesforce 式的“融合”路径，而非微软式的“重构”：“我个人希望中国可以像新能源车一样，在 Agentic AI 上通过重构实现弯道超车，颠覆传统软件。但是当前仍缺少一些基础信息学理论的突破，因此融合模式更现实，也更容易落地。”不过，中国软件市场定制化需求多，因此生态不如海外 SaaS 软件标准，“哪怕是用 Salesforce 模式做的 Agent，也需要千人千面的定制开发。整体来看，在中国没有出现大型全球性软件企业生态之前，中国本土 Agent

77、 还是在沙滩上的楼阁。先做好软件，再说软件上的自动化。”总的来说，对国内开发者和企业来说，从 App Stack 到 Agent Stack 的转变，是一次前所未有的“弯道超车”的机会。写在最后 AI 技术的演进史，总在狂热与反思的交织中螺旋上升。两年前，微软投入数十亿美元以及大量人力打造 Microsoft Copilot，宣称它将成为“新一代的开始菜单”；与此同时，向量数据库 Pinecone 一举拿下 1 亿美元融资，VC 们争相下注，仿佛“新数据库时代”已经到来。但现实很快泼下了一盆冷水。预装在 15 亿台 Windows 设备中的 Copilot，其月活用户量却始终徘徊在 ChatG

78、PT 的 5%，最终迫使微软放弃 Copilot 键的唯一性，允许用户将其恢复为传统菜单键。而向量数据库也在短短半年内从“下一代数据库”沦为通用功能模块，初创公司估值迅速回落。时间到了 2025 年，Agentic AI 站上新的风口。回望 Copilot 和向量数据库的发展，我们不禁要问：这一次，那些看似前景光明的技术，能否真正落地生根，摆脱昙花一现的命运，成为推动下一轮 AI 革命的关键引擎？29 InfoQ 架构师2025年第一季 被骂惨的“现象级”被骂惨的“现象级”ManusManus，今天我们来扒一，今天我们来扒一扒它的真实水平！扒它的真实水平！昨天，一款由中国团队发布的 Agent

79、 产品 Manus 在 AI 圈迅速走红，并登上热搜，许多人称其为真“打工人救星”。一段长达 4 分 17 秒的演示 demo 里，官方介绍，与传统 AI 助手不同，这款产品是一个真正自主的 AI Agent，不仅能提供各行业领域的建议或答案，还能直接交付完整的任务成果，写周报、做 PPT、简历筛选、甚至炒股票都不在话下。在 Manus 官网，还能看到其一口气放出的 60 多个场景案例。此外，在 GAIA 基准测试（专门评估通用 AI 助手解决真实世界问题能力的权威测试）中，Manus 在所有三个难度级别上都取得新的最先进(SOTA)表现，成绩超越了 OpenAI 的 Deep Search。

80、作者 华卫 30 特别专题|Agentic 软件革命 爆火后，Manus 官网页面一度崩溃。由于 Manus 目前还没有公开上线，但对外开放了免费申请体验链接，AI 圈里掀起一波“全网求邀请码”的风潮。就邀请码一事，Manus 官方回应称，“服务器资源完全是按照行业里发一个 demo 的水平来准备的，根本不成想到会引起如此大的波澜。目前采取邀请码机制，是因为此刻服务器容量确实有限，不得已而为之，团队也熬夜搞了一整天了。”国内某二手物品出售平台上，Manus 的邀请码标价最高至数十万级别。据了解，Manus 的邀请码不会绑定到单个账号，拿到邀请码后所生成的项目也不会与邀请码绑定，但设置了每日使用

81、上限。也就是说，在使用上限内，一个邀请码可以被多人同时使用、异地使用、轮流使用。31 InfoQ 架构师2025年第一季 Manus 怎么就火了？！3 月 6 日下午，Manus AI 合伙人张涛在社交平台澄清道，他们从未开设任何付费获取邀请码的渠道，也从未投入任何市场推广预算。内测期间系统容量有限，将优先保障现有用户的核心体验，并逐步有序释放邀请码。值得注意的是，与此前 DeepSeek 先在海外“出圈”的状况不同，目前在海外各社交平台上，还较少看到 AI 行业从业者们对 Manus 发表的公开评价。面壁智能联合创始人、首席科学家、清华大学计算机系副教授刘知远昨日在清华大学的大模型公开课上表

82、示，DeepSeek 的热度当时是酝酿了一周才扩散开，而他不太理解为什么 Manus 会如此迅速地爆火，表示“让子弹飞一会再看”。对于 Manus 迅速攀升的热度，数势科技 AI 负责人李飞向 InfoQ 表示，这背后主要由两层市场趋势推动。首先，Deepseek 在国内大模型市场“烧”起来的火，让大家对于国内去做大模型及其应用更有信心了，目光也会关注到其衍生品上。所以在 Deepseek 之后的这一波，只要是和大模型相关的应用、做得还不错的，其实都会能够获得大量的关注。其次，“天下苦 AI 应用久矣”，从去年开始到今年，大家一直在关注和期待大模型的应用前景。AI Agent 将迎来大规模爆发

83、，在落地场景方面将重点会在数据分析、智能客服等企业办公、业务领域。近期，热门的 Agent 产品不止 Manus 这一个。前不久，号称能顶一整个开发团队的多智能体开发平台 MGX(MetaGPT X)，也在程序员圈子里小火了一把。就在刚刚，该团队又在 GitHub 上发布了一个开源版的 Manus，名为 OpenManus，支持网页浏览、文件操作、写代码等任务。据称，这一项目是几个 00 后工程师在三个小时内手搓完成的。紧随其后，CAMEL-AI 今天一早也发布了一个用于多智能体协作的开源框架 OWL。OpenAI 昨日也宣布了一项关于 Agent 的通知，表示将对达到博士水平的 AI Age

84、nt 每月收费 2 万美元（约合 14.5 万元人民币），主要面向企业用户的高端需求，尤其是在金融、医疗、制造等数据密集型行业。似乎现在几乎所有 AI 赛道的公司都在“盯着”Agent，那么这些智能体产品的效果 32 特别专题|Agentic 软件革命 和应用真有那么“神”吗？是架构上的新突破，还是常规工程范式？与此前爆火的 ChatGPT 或 DeepSeek 不同，Manus 目前并未对外披露技术细节。据 Manus 团队的 Hyan 在 Superlinear Academy 社区平台上发帖介绍，Manus 是全球第一款通用 Agent 产品，可以解决各类复杂多变的任务。其奉行这样的技术

85、理念：“我们坚信并践行 less structure more intelligence 的哲学：当你的数据足够优质、模型足够强大、架构足够灵活、工程足够扎实，那么 computer use、deep research、coding agent 等概念就从产品特性变为了自然涌现的能力。”从公开信息已知的是，Manus 采用多智能体（Multiple Agent）架构，运行方式与此前 Anthropic 发布的 Computer Use 类似，完全运行在独立虚拟机中，同时可以在虚拟环境中调用各类工具。在这个架构中，每个智能体基于独立的语言模型或强化学习模型，但 Manus 本身并未自研大模型。李

86、飞对 InfoQ 表示，Manus 跟 OpenAI 的 Operator 有异曲同工之处，但是它可以在虚拟环境里执行代码。换言之，Manus 的任务覆盖范围更多了，不仅可以在浏览器里执行任务，也可以去到云端虚拟机里去执行任务。在技术层面上，李飞指出，目前从演示视频来看，尽管 Manus 覆盖的领域较广，可操作空间大了，任务的泛化性自然也较高，但整体的架构和理念并不算新。虽然工程实现难度是有的，但可能不是特别大。Agent 本身是一个工程化架构的范式，Manus 团队做得更多可能是如何去保证任务之间的连通性，比如任务的连接、串联和回退等方面，保证系统的容错性。“通用”Agent 现阶段不可能实

87、现？邀请码虽然“难得”，但也有一批业内人士先行体验了 Manus 的效果，我们也收到了一些用户反馈。某大厂的 AI 负责人对我们透露，“体验后感觉并没有被惊艳到。”根据网上试用者反馈，Manus 目前能顺利执行的任务偏简单（表现与目前前沿大模型没有明显差异），对于稍微复杂的任务就需要耗费较长时间，甚至最后崩溃而无法完 33 InfoQ 架构师2025年第一季 成，这也引发了部分人的算力焦虑。而且，由于各平台的登录制度，Manus 无法完成大家期待的“点外卖”、“订机票”等任务。商汤科技高级 AI 产品经理王尚则在试用过 Manus 后给出了比较正向的反馈，对于其技术局限和可行性，他对 Info

88、Q 表示，最大的限制除了模型本身的能力边界外，目前还缺乏一套通用的 Agent 协议或接口，让 Agent 具备更强的自主实现能力。Manus 依赖于类似虚拟化浏览器的环境来执行各类任务，在浏览器的环境中模拟人类的操作，使用为人设计的用户界面。但短期内看不到 Agent 协议出现的可能性，毕竟我们对大模型的能力挖掘程度可能还不到 10%。至于当前 Manus 是否做到了通用 Agent 的级别，李飞审慎地表示“应该还不能”。具体来说，Agent 底层的工具池越丰富，规划的能力越丰富，越会往通用去走，就像人一样懂得越多越容易成为一个通才。Agent 想要达到通用，一定是能够去完成用户所提到的所有

89、任务，但是现实事件当中任务又会分为很多种，这里面有两个难点：第一是怎么去根据用户不同的个性化请求去找到任务执行路径，第二是 Agent 所具备的工具池是否足够丰富。“任务路径节点越多，复杂度就越高，端到端完成的的成功率就会陡降。”在放出来的场景案例里，Manus 不管是交互、性能还是准确性都打磨出了不错的效果，其目前肯定是往通用 Agent 的路线去走的，但做到通用 Agent 的难度是比较大的，因为物理世界的复杂度远超我们的认知。总的来看，Manus 在实际应用中或会遇到三方面的核心可行性问题：一是物理世界的高复杂度，二是任务流的连通性，再就是当前缺少通用 Agent 协议或接口。Manus

90、 团队也在最新公告中表示：大家目前看到的 Manus 还是一个襁褓中的小婴儿，像模型幻觉、交付物友好度、运行速度等方面都还有很大的提升空间。不过，李飞认为 Manus 带给市场的反应是正向的。他认为，“Manus 的爆火是让我感到兴奋的，因为它让其实更多的人进一步地去了解什么是 Agent、Agent 可以帮助我们做什么的以及怎么去做。”同时，李飞指出，目前 Manus 走 To C 是一个比较好的路径，可以通过 C 端先把市场热起来，而且 C 端用户对于工具的宽容度比较高的，但 B 端会更为严格，不确定它的能力上限能否满足企业应用。34 特别专题|Agentic 软件革命 但值得注意的是，哪

91、怕作为“通用 Agent”，Manus 在大众中的使用门槛也是不低的。据李飞介绍，在使用层面可能出现两种情况：领域专家不用它，因为当前通用 Agent 还没有达到能够解决领域难题的程度；一般使用者不知道该怎么去用，就像我们在去用搜索的时候，提问是一件很难的一件事情。对此，李飞提出，当前很多 Agent 还是被动式的，需要用户以提问形式告诉它怎么做。但未来 Agent 产品一定会走向主动式，无需用户提问而是会根据用户的行为习惯以及历史消费记录或出行记录，主动推荐或者告知用户怎么做，这种形态对于使用者更为友好。垂直 Agent 的“全能”困境 相较而言，MGX 则是一个侧重于编程开发领域的多智能体

92、产品，与刚刚发布的开源版 OpenManus 出自同一团队之手。据称，其可以模拟人类软件开发流程，通过多个专业 AI agent 的协作，同时干团队领导、产品经理、架构师、工程师和数据分析师等角色的活儿。该团队是开发了一个多 Agent 系统来处理复杂的问题解决任务，包括问题重现、高效的代码生成和验证以及强大的补丁选择。这些 Agent 能够利用高级存储库级代码理解、搜索、编辑和调试功能，处理各种软件工程子任务。根据官方介绍，MGX 是以 DeepWisdom 团队的开源多智能体编程框架 MetaGPT 为基础，由 GPT-4o 和 Claude 3.5-Sonnet 驱动。利用多 Agent

93、 架构，MetaGPT 在 SWE-Bench Lite 上实现了 46.67%的解决率。作为多 Agent 框架，MetaGPT 可以为 GPT 分配不同角色，以形成执行复杂任务的协作软件实体。也就是说，MetaGPT 想提供一支全能团队，包括老板、产品经理、架构师、项目经理、工程师、测试老板、产品经理、架构师、项目经理、工程师、测试，完整复现一家软件公司的工作流程和标准操作流程（SOP）。这比做代码补全的 GitHub Copilot 和任务自动化的 Devin 更为全面，因为 MGX 不仅想要独立完成整个项目的全生命周期管理，还想将“自主创立一家员工 100%由 AI 组成的公司”变得可

94、能。然而，这一愿景面临极高的技术复杂度，要让 AI 理解并执行软件领域复杂的业务逻辑，挑战不容小觑。35 InfoQ 架构师2025年第一季 JetBrains 中国 AI 解决方案专家孙涛对 InfoQ 表示，“直白的说，MGX 代替初、中级研发团队或设计、支持团队尚不现实，但是对于一个人参与实现和运营的独立项目或者对于新需求、新概念的验证，与多智能体协作的人机交互模式肯定会提升这些场景下的效率。”此外，孙涛表示，虽然没有尝试过在大型项目上使用多智能体框架，但在简单项目上堆叠功能，多尝试几轮后，能明显体会到 token 消耗速度飞升，生成的内容质量不如最初几轮交互。多智能体之间相互沟通也容易

95、将错误信息逐步放大，让最终结果远远偏离最初需求；上下文遗忘更是一个很明显的问题，受限于模型能力，智能体之间多轮互动后容易出现早期信息遗忘、消失，影响整体一致性。在亲身体验 MGX 过后，孙涛还透露道，“我自己感觉还有一个问题，就是生成的项目文档、设计资料缺乏解释性，往往有很多人类难以理解的内容，更像是给机器看的文档。或许这是 LLM 生成的一个限制。”总的来说，MGX 现有的产品形态在完成明确定义的小型任务上表现超出预期，但面对大型、复杂、模糊定义或者需求动态变化的任务时，仍有诸多问题。智能体无法在既定的提示词内，处理复杂的原子化操作，人类面对复杂业务时的应对和学习能力，目前阶段的 LLM 还

96、很难做到。李飞则指出，“MetaGPT 强调的是协作，但其实又回到那个问题，涵盖的角色越多，复杂度就会越高。”在他看来，当前 MetaGPT 有具体企业级应用或者商业化落地其实很难，实际的业务项目开发不仅是编程一个项目或游戏这么简单，其实是逐渐在走向业务上层的，智能体具备业务逻辑的理解挺难的。但他也表示，“这确实是一个应用方向，我们不能因为它当前的落地难度大就否定它。”另值得一提的是，目前 MGX 在官网展示的案例项目成本几乎都不超 1 美元。对此孙涛表示，在实际商业化项目开发中不可能做到这样的低成本。根据他本人的体验经历，在多轮操作后，软件中添加一个细微的需求，如添加一个新列表、修改一些样式

97、等，多智能体框架消耗的 token 量会成倍提升。放下 token 用量的问题不谈，这些由机器生成的内容，在真正投入生产使用前，也需要人工再次审阅确认。36 特别专题|Agentic 软件革命 将来是否会被大模型内化？无论走通用 Agent 路线的 Manus 还是 MGX 等这类领域 Agent，其前提都是依托其他家的大模型作为核心引擎。那如果只是套壳大模型的产物，是否会被其依赖的核心技术“内化”掉？这些 Agent 产品本身还有独立存在价值吗？通用 Agent 在 LLM 的演进过程中有多大生存空间？王尚对此表示，所有开放性的解决方案，最后都有可能被大模型内化，只是一个时间节点的问题。另外

98、，大模型和 Agent 的边界也在逐渐模糊，Anthropic 据传也在计划从模型服务商发展为应用服务商或者方案服务商。随着大模型不断内化更多的能力，其对于 Agent 的吞并趋势也将越发显著。“现阶段我们应该关注的，是想清楚我们希望 Agent 帮我们解决什么样的具体问题，从问题出发，去找答案、找路径、找空间。”李飞则指出了一系列大模型内化不掉的 Agent 落地场景：比如数据访问，大模型可以去连接、收集互联网的数据，但很难处理企业内部的数据，大模型不可能去适配到每个企业内部数据结构和数据库；很多工具能力目前来看也是大模型内化不了的，大模型是应用的下限，Agent 才是应用的上限，只有连接足

99、够多的业务场景才能够去打造一个可用、好用的产品应用。他表示，“未来，我们需要考虑的是通用 Agent 的形态问题，即通用 Agent 是一个独立的产品吗？用户需要很多入口吗、是否会做统一？”对此他认为，未来电脑和现实交互的入口一定会逐渐地收敛和整合，那么在这种情况下通用 Agent 就不会是一个完全独立的产品，可能会以 MCP 的整合方式，融入到人机交互当中的某一个节点。37 InfoQ 架构师2025年第一季 GPTGPT-4o4o“吉卜力”爆火，“吉卜力”爆火，PromptPrompt、SD SD 白学白学了？！大模型能力进化碾压一切了？！大模型能力进化碾压一切 ChatGPT 的新 AI

100、 图像生成功能上线仅两天，社交媒体上便已充斥着以日本动画工作室吉卜力风格的 AI 生成梗图，埃隆马斯克、指环王和美国总统唐纳德特朗普都没“逃过”，甚至 OpenAI 首席执行官萨姆奥尔特曼也将他的新头像设置为吉卜力风格的图片。（吉卜力工作室以制作龙猫和千与千寻等热门影片而闻名。）大量用户正在将现有的图像上传到 ChatGPT，并要求聊天机器人以新的风格重新创作这些图像。今天，奥尔特曼在 X 上发文表示：“看到大家如此喜爱 ChatGPT 的图像功能非常有趣，但我们的 GPU 快扛不住了。”虽未具体说明限制次数，但 Altman 称该措施不会持续太长时间，因为他们正在尝试提升处理海量请求的效率，

101、免费用户将作者 华卫、褚杏娟 策划 Tina 38 特别专题|Agentic 软件革命“很快”能每天最多生成三张图像。虽然后续 OpenAI 又宣布了对 GPT-4o 进行了更新，但显然人们的注意力还在“玩图”上。“我认为，这个功能是过去半年里 OpenAI 发布的 GPT-4o 中最有价值的一个，它确实非常炸裂。相比之下，正式上线的 Sora 以及后来连续 12 天的直播所展示的内容，大多都没有超出人们的预期。”原快手可图大模型负责人李岩说道。与 SD 等模型比，GPT-4o 赢在了哪里？“昨天还在看 SD 教程，今天发现白看了”知名开发者 Jimmy Cheung 发帖说道，“今天情绪非常

102、低落，压力非常大，我不清楚我现在做什么，是从现在开始到将来都还有价值的。”39 InfoQ 架构师2025年第一季 李岩表示，这次 GPT-4o 火爆的关键在于实现了对话式图像生成。实际上，基于自然语言指令的图像编辑能力之前已经有了，比如字节 SeedEdit 和 Google Gemini 2.0 都具备相似能力。但在实际生成过程中，指令响应能力没有那么强，效果做得没有那么好。例如在一致性保持方面，当要求去除背景中的某个物体时，模型可能还去掉了其他的东西；或者在对人物进行特定修改时，最终效果可能是不像原来的人了。此外，还存在指令不响应的问题，比如要求添加某些元素时未能执行。但这次 GPT-4

103、o 的交互方式所达到的文本跟图像的响应是非常精准的，大大超出了大家的预期。李岩分析，虽然 OpenAI 没有发布详细的技术报告，但有一点非常明确：他们一定采用了自回归框架（Autoregressive Model,AR），只有自回归框架才能实现如此自然的图文交互效果。后续大概率也接入了 decode 模块后再做图像生成，但其整体框架已经完全统一到了自回归框架之下。具体说来，Flux、Stable Diffusion 等模型，现在的做法都是将文本表征和图像生成过程进行解耦，然后扩散模型出图。这种方式通常要先对文本进行完整表征，例如通过 CLIP 或大语言模型提取特征，然后将该特征直接输入扩散模型

104、，并要求扩散模型在生成图像的整个过程中持续参考这个固定的文本特征。这个文本特征的来源是用户输入的 prompt，某种编码器的方式会对 prompt 进行特征提取。然而问题在于：特征提取完成后，信息量就被固定了。在文本到图像的生成过程中，100%的原始信息都存在于用户输入的文本 prompt 中，但经过文本编码或表征提取后可能只剩下 70%的信息，这意味着后续最多就只能基于这 70%的信息量进行图像生成。当前几乎所有图像生成模型都采用了上述模式。但可以看出，这些模型在生成文本表征时都会不可避免地造成信息损失，而这种损失一旦形成固定的 embedding 或表征就无法挽回，这一阶段出现的信息缺失，

105、后续扩散模型在生成图像时是无法回溯弥补的。当前，扩散模型的扩充方式是 prompt engineering（提示词工程）。但是，提示词 40 特别专题|Agentic 软件革命 工程只能扩展成显式描述，比如输入“一个漂亮的小女孩”，系统会将其扩展为非常详细的描述，包括小女孩戴着什么样的帽子、出现在什么样的背景下等等。但这种方式在后续建模中仍然需要提取文本特征，依然会造成信息损失。只要是采用二阶段的方式，即先建模文本再以文本为条件输入扩散模型，就必然会因为文本建模过程中的信息损失导致最终生成的图像无法与文本描述 100%对齐。GPT-4o 之所以强大，关键在于它能有效处理用户提供的简洁信息。例如

106、，用户通常只会简单地输入：“帮我画一只小猫或小狗”，但不会给出具体是什么样的猫或狗。现在，GPT-4o 统一到大语言模型的自回归框架下，所以天然具备了语义泛化能力。这种能力本质上源于模型本身的知识储备，使其能够准确理解用户简单文字背后代表的真正的、稠密的信息量是什么。正是由于 GPT-4o 拥有强大的大语言模型作为知识基础，它才能在完整的端到端框架中实现如此精准的理解和生成能力，这一点至关重要。模型输入的就是用户的原始 prompt，然后直接出图，中间过程中没有二阶段损失，都是一阶段做的，可以充分利用大语言模型所带来的隐式知识，包括扩充 prompt 等。另外一点是，原来的方法仅支持单轮操作，

107、即输入文字生成提示词，再通过特征提取生成图像，但无法支持多轮条件控制。GPT-4o 可以直接将图片按照上传图片的风格生成新图像，其中关键在于需要理解上下文中的具体指向，如“刚才提到的狗的照片是哪一张”，这需要大语言模型具备跨模态理解能力。在自回归框架下，上下文从纯文本扩展到了文本+图像，因此模型能轻松 get 上下文，甚至远程的上下文。值得注意的是，从出图质量来看，目前基于自回归框架的生成效果并没有碾压式地超过扩散模型，甚至可能还不如扩散模型的表现。现阶段，两者的生成质量水平其实相差不大。李岩指出，这仅仅是就出图效果而言，我们更应该关注的是交互方式的差异。未来在交互体验方面，自回归框架显然具有

108、更大的理论优势，它能够更好地兼容完全开放的自由度，实现更接近自然语言对话式的交互方式。41 InfoQ 架构师2025年第一季“这种 Interleaved 的图文交错技术才是真正原生的多模态大模型。”李岩认为，在当前行业中，真正意义上的原生全模态的大模型领域里，OpenAI 还是走在最靠前的。此外，李岩表示，“文生图架构没有什么可以争议的了，在 2025 年这个话题就不是话题了。”自回归框架对于多模态里面的文本模态、音频模态，自不用多说，基本上已经证明了是可行的，难点在于视觉模态。现在行业内最好的模型，包括开源的 Flux、闭源的可灵、Sora 等，还在用 DIT 的架构，真正做到高精度的视

109、觉生成现在还离不开扩散模型，但图像生成领域，单靠自回归框架实际上是有可能达到一个新的高度的，这件事情 GPT-4o 已经给出了答案。李岩还大胆设想，如果 GPT-4o 接入联网功能并整合 RAG 技术，其在图像生成方面的潜力将更加巨大。通过 RAG 技术，模型可以直接检索到用户所指的网络流行梗或热点，用户就不需要再上传参考图片了。例如，当用户想生成网络流行表情包时，GPT-4o 可能无需参考图片，仅凭对网络流行文化的理解就能准确捕捉到用户想要的梗，这将进一步提升文生图应用的便捷性和准确性。是否会吞噬所有产品？OpenAI 发布 GPT-4o 文生图功能后，Jimmy Cheung 的评价是：G

110、PT-4o 的图像能力，直接干翻了之前很多创业公司的产品，他们花了那么多时间、人力、投资人的钱去调优的算法、工作流、模型，直接被一次大模型的更新就取代了。除了 Jimmy Cheung 吐槽“SD 白学了”，还有网友感叹，学了两年的作图工具流 comfyUI 也白学了。一部分人直接大呼：工作流已死。事实上，对于像 comfyUI 这样的工作流产品而言，情况可能没有那么悲观。“GPT-4o 目前为止的结果确实挺颠覆，但在真正的商业化可用的能力上，现在不太行，相当长一段时间还是要依赖 comfyUI。”李岩说道。比如，当前 GPT-4o 的出图大小并不能满足实际商拍场景里的需求，分辨率的提高会需要

111、一些外接能力。另外，OpenAI 在照片改换风格时是做全图的重绘，细化到了图像的每一个像素点，但在实际情况中，用户可能只需要改某一块地方，其他地方，甚至 42 特别专题|Agentic 软件革命 一个像素值都不能动，这样的需求就需要 comfyUI 这类非常细粒度的工作流方式去精细化处理。comfyUI 里面有后处理、抠图、调整亮度等很多链路，支持使用基于图形、节点和流程图的界面来设计和执行高级的稳定扩散流水线。“对于轻娱乐场景或者要求没有那么高的批量生产场景，GPT-4o 现在已经可以发挥价值了。但对于容忍度比较低、项目要求非常高的场景，未来相当长一段时间里还是要依赖 comfyUI。”李岩

112、总结道。但是，GPT-4o 对于 Prompt 工程可能会是致命打击。“Prompt 工程这件事有可能以后变得也没那么重要了。”李岩解释称，现在 Prompt 对文生图、文生视频模型很重要，是因为整个文本侧和图像侧还没有办法做到那么强的 alignment 效果，所以需要尽可能把文本侧的内容写明确、减少信息损失，因此诞生了 prompt engineer。但实际上未来这部分工作如果如果能统一到 GPT-4o 的框架里，这份工作大家慢慢就不需要了。就算 Prompt 写的不好也没关系，还可以再改，只需把不满意的改进点用自然语言描述给模型，模型就会理解到底应该怎么改。在李岩看来，GPT-4o 这次

113、更加证明了工具型产品会更容易被大模型能力吞噬。比如美颜类工具，对于不懂美颜的男生来说，语言交互就可以得到理想的效果。43 InfoQ 架构师2025年第一季 但显然，作为正在遭受“冲击”的 Midjourney 并不这样想。Midjourney CEO David Holz 犀利指出：GPT-4o 的图像生成速度慢、效果又差，OpenAI 只是为了筹集资金，而且在以一种不良竞争的方式行事。这不过是一时的噱头，并非创作工具，不出一周就没人会再谈论它了。据称，Midjourney 准备在下周推出最新的 V7 版。值得注意的是，领导 Midjour-ney V2 至 V7 模型开发的核心人物 the

114、seriousadult 在 3 月 21 日宣布离职，之后将加入 Cursor 转做 AI 编程 Agent。而早在 GPT-4o 掀起此次关于“大模型是否会吞噬所有产品”的热议之前，AI 科技公司 Pleias 联合创始人 Alexander Doria 就提出了“模型就是产品”的观点。他明确指出：所有投资者一直都在押注应用层，但在人工智能进化的下一阶段，应用层很可能是最先被自动化和颠覆的。同时，Doria 还认为，OpenAI 的 DeepResearch 和 Claude Son-net 3.7，以及“不仅把模型当作产品，而且将其视为通用基础设施层”的 DeepSeek，都是“模型作为

115、产品”的典型示例。不过，就目前的大模型能力来看，大模型暂不能覆盖到所有的应用产品。但这种低门槛的使用形式，似乎正一步步瓦解许多现有的各类产品逻辑和形态。结束语 大模型更多是在做技术平权这件事，就是让很多不懂技术的人逐渐都可以公平地使 44 特别专题|Agentic 软件革命 用大模型。在技术迅速变化的当下，每个人，甚至企业都很容易被迫进行战略调整，甚至转向。李岩的建议是，首先，要明确自己在这个行业中的具体业务需求。其次，在实际工作中，每个人都应该采取两种策略：一是“低头走路”，确保自己对所用工具的理解和运用熟练，从而稳步前进；二是“抬头看路”，关注行业的发展和变化。这两者不是相互排斥，而是需要

116、同时进行，以便我们在专注工作的同时，及时调整方向。李岩认为，未来大模型的发展将深刻影响各行业的组织形态和人员能力结构。以传统的人才金字塔为例，其结构通常分为底层、中腰部和顶层。目前看来，底层能力画像的人会被大面积“吞噬”，接着是腰部能力的人群，而最头部的那部分人永远不会被大模型吞噬，因为大模型本身也需要他们的 feedback 和教化。“所以，每一个人应该尽量避免做技术含量低的工作，而是慢慢往上去走。”李岩说道。45 InfoQ 架构师2025年第一季 资源有限，如何构建高效能的资源有限，如何构建高效能的 AI AgentAI Agent 在人工智能的璀璨星河中，AI Agent 无疑是一颗耀

117、眼的明星。自诞生之日起，它便承载着人类对自主决策和持续进化能力的追求，历经数次技术浪潮的洗礼，而今随着大模型技术的突破再次站上了风口浪尖，成为业界瞩目的焦点。甚至不少专家认为，未来 AaaS（Agent as a Service）模式或将颠覆现有的 MaaS（Model as a Service），成为主导 AI 产业的新趋势。日前，在 AICon 全球人工智能开发与应用大会 2024 北京站【AI Agent 技术突破与应用】专题圆桌交流中，小米大模型负责人栾剑担任主持人，与数势科技 AI 负责人李飞、彩讯股份 AI 产研部总经理邹盼湘、钉钉智能化平台架构师柯杰，共同探讨 AI Agent

118、领域的最新进展和发展方向。作者 AICon 全球人工智能开发与应用大会 策划 李忠良 46 特别专题|Agentic 软件革命 部分精彩观部分精彩观点如下点如下：大模型的性能将会急剧提升。大模型 API 可能会促进国内 SaaS 模式的进一步发展。有效利用私域数据并精准描述场景任务，可以在小模型下实现低成本、高效推理。大模型技术并非万能，但通过合理拆解问题，就能在可行的范围内解决问题。改进 AI 意图识别是提升人机交互体验的重要方面。以下内容基于现场速记整理，经以下内容基于现场速记整理，经 InfoQ 删减。删减。栾剑：如何挑选和判断适合使用栾剑：如何挑选和判断适合使用 AI Agent 赋能

119、的场景？赋能的场景？邹盼湘邹盼湘：在选择场景时，我们主要从两个方面考虑。首先，业务流程必须要清晰，因为大模型的落地应用需要明确的业务流程。如果业务流程不清晰，模型的效果就难以达到预期。其次，我们的场景中需要有一定的数据积累，无论是业务数据还是用户行为数据。只有在这种数据积累的基础上，进行 AI 探索或初步落地，才是一个较为合适的选择。李飞李飞：在落地过程中，我们发现 Agent 主要用于工作流编排。简单场景不适合用 Agent，因为任务本身简单，Agent 反而可能增加复杂性，客户等待时间过长。但对于复杂场景，涉及多环节且环节顺序灵活，Agent 也许能通过大模型规划实现编排。因此，没有一个固

120、定答案，需根据场景找到合适的平衡点。复杂任务用预编排工作流，中等复杂度任务可以用大模型规划。柯杰柯杰：我们可以从三个场景来讨论。首先是“AI+”，即将 AI 与现有业务流程结合。这种方式的核心是连接当前大家已经熟悉的业务流程，让业务习惯得以保留。但实际上，很多人对于这种转变的接受度仍然较低。其次，由于目前大模型技术还不够成熟，我们可以创建一些通用模板，在模板中替换不同的参数来生成新的工作流。例如，某个工作流可能最终会将数据收集到一个多表中，而不同的工作流只是替换了不同的多表参数。这种方法可以在一定程度上复用现有工作流，提高效率。最后，我们的功能编排目前还是基于传统的工作流系统，这对开发框架来说

121、仍然是 47 InfoQ 架构师2025年第一季 一个挑战，因此目前对开发人员的要求较高。在这种情况下，我们每个人都需要理解“模型与产品匹配度”。我们需要清楚了解模型的能力和产品的需求，找到二者之间的平衡点，明确哪些任务适合模型来做，哪些需要人工介入。栾剑栾剑：我个人在选择场景时，首先会考虑这个场景的商业价值。我们需要判断使用 AI 后，是否能在降本增效等方面带来显著的商业价值。如果人工完成该任务已经非常高效，而引入 AI 反而增加了成本，那么可能不值得替代。其次，要考虑技术能力。随着大模型的发展，它在自然语言理解和生成，以及视觉理解和生成方面的能力有了显著提升。如果一个任务或场景涉及这些领域

122、，大模型可能会带来很大的收益，能够完成得更好。但对于一些大模型目前尚不擅长的任务，如复杂推理或规划能力，我们需要更加谨慎地判断是否可行。第三，数据积累也是一个关键因素。通用大模型仅通过 Prompt 方式进行任务时，效果会受到一定限制。我们通常希望有更多场景相关的真实数据来优化模型，因此，如果场景内的数据积累较多，优化效果会更好。相反，如果数据积累不足，效果可能就会受到限制。最后，还要做风险评估。需要考虑场景对可信赖度和准确度的要求，并评估用户使用过程中是否会感到不适。在很多场景中，用户希望与人类进行交互，特别是客服场景中，用户可能不愿意与 AI 客服对话，主要是因为之前的智能体验不好，或者他

123、们更倾向于与人互动。此外，还需要考虑法律和隐私风险。栾剑栾剑：虽然大模型的算力要求在不断降低，但与传统 AI、模板驱动的系统或小模型相比，其服务成本仍然较高。这使得一些公司和行业在引入 AI Agent 时，面临着算力、内存等资源上的挑战。在这种情况下，如何利用有限的资源来实现更高的应用价值，如何利用有限的资源来实现更高的应用价值，并突破普通并突破普通 Agent 的能力瓶颈？的能力瓶颈？柯杰柯杰：我之前看到面壁智能提到一个“面壁定律”，这与早期的摩尔定律相似。摩尔定律讲的是 CPU 的计算能力每 18 个月翻一倍，而面壁定律则指出，大模型的知识密度也会在短时间内提升，甚至不需要 18 个月。

124、实际上，现在很多小模型已经能够在手机上取得非常好的效果，我认为这个问题会很快得到解决。48 特别专题|Agentic 软件革命 目前，很多大模型的潜力尚未完全挖掘出来。虽然大模型存在缺陷和短板，但从应用开发的角度来看，大模型的能力已经足够应对大多数场景。就像电力一样，虽然电力紧张，但对于大模型的应用来说，其所需的电力是足够的。我对未来很乐观，认为大模型的性能将会急剧提升，并且未来许多小模型将能够在端侧解决更多问题。因此，我并不感到焦虑，问题并不像看起来那么严重。李飞李飞：突然想到或许还有一个“价格定律”，随着基础设施价格的降低，ToB 客户越来越关注设备成本，特别是做私有化部署的客户。如果某个

125、场景的 ROI 无法覆盖高昂的设备成本，落地就变得困难。在国内，客户在采购软件时通常比较保守，偏向于私有化部署。这与国外市场不同，国外最初也做私有化，但由于成本过高才转向 SaaS 模式。国内客户接受 SaaS 的速度较慢，因为他们没有经历过私有化部署的转变。此外，很多客户坚持私有化是因为数据安全的考虑，但并非所有数据都需要完全私有化，部分非敏感数据可以出库。关键在于评估哪些数据需要私有化，哪些可以外部处理。随着大模型的发展，客户的观念也在转变，不再单纯要求私有化，而是考虑采用 SaaS 模式，尤其是面对高算力成本时。大模型的 API 也可视为 SaaS 的一种形式，未来可能会促进国内 Saa

126、S 模式的进一步发展。邹盼湘邹盼湘：在中国，SaaS 的推广存在文化障碍。中国人倾向于购买能“看得见、摸得着”的东西，而 SaaS 服务是虚拟的，可能在没有续费的情况下消失。因此，许多企业在做立项时更愿意选择私有化部署，而非 SaaS。尤其在向集团汇报时，他们更看重“实体化”资产，而非过程中能力的沉淀。此外，大模型在落地时仍面临挑战，尽管算力不断提升、价格下降，当前的大模型效果还未达到预期。随着技术的不断发展，许多问题会逐步解决。短期内，我们需要补充大模型的不足，特别是在性能、可控性和“幻觉”问题上。为了应对这些问题，我们常常减少大模型的处理量，使用小模型或传统方法来控制成本并提高性能。即使大

127、模型变得智能，它仍然无法解决私域数据和业务流程的问题。49 InfoQ 架构师2025年第一季 私域数据随着时间变化不断积累，大模型无法实时获取并处理这些数据。同时，业务流程和系统因公司不同而各异，模型无法完全取代这些差异化的系统。从长远来看，我们的目标是如何高效地将私域数据和业务流程链接起来。我们正在开发一个名为 Aibox 的大模型应用平台，旨在解决大模型的不可控性和性能问题，并实现多模态数据与业务系统的高效连接。栾剑栾剑：总结一下，资源有限的情况下，我们不必过于担心 AI 的应用可能出现问题。首先，模型的能力在不断增强。两年前推出的 ChatGPT 是一个千亿参数的大模型，而现在即便是一

128、个 7B 模型，也能超越当时的效果。这表明模型的参数可以大幅压缩，依然保持良好的性能。我们小米在端侧大模型的研究中，已验证这一趋势：在效果基本保持不变的情况下，模型规模越来越小，服务成本越来越低。同时，随着更多优秀的工程师关注这一领域，从硬件到软件都在加速推理的优化，我们看到大模型服务的价格最近一年显著下降，甚至国内大模型服务的价格下调还带动了海外。最后，很多时候我们不必依赖庞大的模型才能取得良好效果。通过有效利用私域数据并精准描述场景任务，许多应用可以在小模型下实现低成本、高效推理。观众观众：我是一名 TCL 初级 Agent 开发者，企业中很多人认为 AI Agent 无所不能，可以一键控

129、制很多东西，但真正落地完发现它其实碌碌无为。应该怎么应对这种大模型应该怎么应对这种大模型落地之后的差距问题？落地之后的差距问题？邹盼湘邹盼湘：就像在与客户沟通时，我们发现客户对 AI 的理解往往存在误区，以为 AI 无所不能。例如，在某个客户开发的营销助手项目中，客户最初只希望推荐饮品，但很快提出了更多需求，包括根据天气推荐饮品、提供天气查询、推荐周边餐厅等。虽然这些问题超出了我们最初的预期，但客户认为这些都属于“助手”应答的范畴，因此我们逐步为系统增加了天气插件、定位功能和商户信息。随着需求不断升级，客户还提出了关于运营活动和折扣券的推荐，这些问题更复杂，但客户依然认为它们是知识问答的一部分

130、。为避免类似问题重复出现，我们在后续项目中将流程进行了详细拆解，明确哪些问 50 特别专题|Agentic 软件革命 题由模型解决，哪些需要提示工程、模型微调或知识库对接。我们要求客户在提需求时明确功能边界，并清楚了解每项需求的预期效果，避免模糊需求导致项目实施困难。同时，我们也提前向客户说明可能遇到的挑战，如第三方 API 对接问题，并提供应对措施。通过这种方式，我们有效地管理了客户期望，确保项目顺利进行。李飞李飞：正确地管理预期，尤其是在交付过程中，是至关重要的。对于老板的预期，也需要提前框定合理的范围并逐步满足。有时候，老板的要求可能是愿景，虽然无法完全实现，但我们需要理解并努力朝这个方

131、向前进。柯杰柯杰：当老板愿意一步一步分析问题时，复杂的挑战也能被逐步解决。例如，提升人效看似难以回答，但如果将问题具体化，分析员工时间消耗，找出可以优化的部分，这就变得可行。同理，虽然当前的大模型技术并非万能，但通过合理拆解问题，我们能在可行的范围内解决问题。其次，我们不可能直接拒绝老板的需求。我们需要告诉老板哪些问题是可以解决的，哪些是目前无法实现的。一个简单的判断标准是，哪些是人类能做到的，哪些是人类做不到的。如果人类做不到的事情，大模型也很难做到；反之，如果人类能做到的，我们就可以努力去实现。例如，在阿里园区，有个功能可以通过语音控制开关灯，这看似简单，但实际上需要先进行数字化建设，将工

132、位和灯具建立关联。这个过程虽然需要时间，但通过数字化积累后，就能实现这种控制。栾剑栾剑：在引入大模型之前，我们需要进行一场“启蒙运动”，将员工和老板的热情调动起来，让大家理解并拥抱 AI 技术。这样才能为未来的技术变革奠定基础。然而，一旦大模型开始应用，则需要进行“反启蒙运动”，告知大家 AI 目前的能力范围，设定合理预期。此外，大众对 AI 能力的理解有很大误区。普通人觉得人类很容易做到的事情 AI 就应该能做，人类很难做到的事情对 AI 应该也很难。但事实上，真不一定。AI 能在一些人类难以完成的任务上表现出色。举个例子，打乱扑克牌后，人类很难记住牌的顺序，但 AI 可以轻松记住甚至多副扑

133、克牌的顺序。类似地，AI 能够处理极大数量的上下文信息，这在人类中是做不到的。但另一方面，一些对人类很简单的推理对 AI 可能很难。51 InfoQ 架构师2025年第一季 因此，我们需要通过好的类比向公众，尤其是老板，解释 AI 的能力及其局限性。这样，他们才能更好地理解 AI 能做什么，不能做什么，背后的原因是什么。栾剑：在未来，最理想或者说最终极的情况下，人和栾剑：在未来，最理想或者说最终极的情况下，人和 AI Agent 会以什么样的形态会以什么样的形态进行互动？人和进行互动？人和 AI 会是什么样的协同方式？会是什么样的协同方式？邹盼湘邹盼湘：一个智能体应该像是我们的助理或伙伴。人类

134、交流可以分为两类问题：事实类问题（如“现在是什么时候？”）和认知类问题（如“你怎么看这件事？”）。在与 AI 的交互中，我们也会遇到类似的两类意图：明确意图和模糊意图。模糊意图是指用户提出的问题不够明确，例如“帮我做个事”，这个时候 AI 需要通过提问逐步明确用户的需求。例如，用户要求“帮我定个出差申请”，AI 会进一步询问目的地、出差日期等信息，从而将模糊的问题转化为具体任务。明确意图则可以分为单一意图和多任务意图。例如，单一意图可能是“捡起地上的水瓶”，而多任务意图可能是“从某人那里取某样东西并快递给别人”。这些任务之间有依赖关系，AI 需要正确识别并处理这些任务。对于明确的任务，我们把任

135、务定义为“语义事件”，每个事件有相应的参数。比如在工作流中，某些节点可能会需要特定的变量来执行任务。与人类交互不同，AI 不会一开始就问所有问题，而是逐步获取所需信息。例如，在订出差机票时，AI 首先询问出发地和目的地，之后根据具体情况再询问其他信息。另一个挑战是在任务切换时的处理。假设用户先要求订票，然后突然收到消息要取消行程并订餐。这时 AI 应该能理解并切换任务，而不是重新询问用户已提供过的信息，如身份证号或电话等。当前，大模型在切换任务时常常需要重复获取用户信息，这使得体验不够流畅。我们正在聚焦于如何改进 AI 的意图识别，尤其是在单一意图、模糊意图、多任务意图的识别过程中，以及如何解

136、决任务切换、恢复和跳转的问题，这些都是提升人机交互体验的重要方面。李飞李飞：这个问题很有趣，我觉得可以从两种形态来讨论：交互形态和系统形态。52 特别专题|Agentic 软件革命 从交互形态来看，未来的 AI 不会像现在的聊天机器人那样简单。例如，在电影钢铁侠和蜘蛛侠中的贾维斯和伊迪斯，它们虽然是工具，但具备高度智能，可以直观地为我服务。另一种形态像机器纪元中展现的具身智能机器人，它们是明确的机器人，但能有效地帮助我完成任务。还有一种可能是像终结者中的机器人，外观和人类一样，完全不显得是机器。从系统形态来看，之前思考，快与慢这本书引起了讨论，DeepMind 也发表过相关论文，探讨了系统架构

137、的“快与慢”。它提出将系统分为前端的“talker”和后端的“reasoner”，这可能是未来系统架构的发展方向。柯杰柯杰：我讲一下我理解的三种形态。第一种是尊重现有用户习惯的 AI 整合形态。我们可以在现有产品中融入 AI 技术，通过 AI Agent 来优化和构建流程，这种方式尊重用户的使用习惯，能够帮助用户快速适应并提升体验。第二种形态是打破信息孤岛。在过去的移动互联网时代，信息被分割成了多个孤岛，每个 APP 都有自己的闭环。但随着 AI 多模态技术和大模型的发展，我们有了打破这些孤岛的机会。平台如钉钉、微信等正在推动信息互通，这种开放性使得 AI 不再局限于单一场景，而是可以在更多地

138、方为用户提供服务。第三种形态则关注智能化设备的进化，它不仅仅是具身智能或拟人化。未来的 AI 可能不再依赖传统的人类形态，比如机器人不一定像人一样使用手机做事，可能会有更适合的工具。例如，通过 WiFi 路由器分析信号波动来感知家中老人的摔倒行为，而不需要依赖摄像头来避免隐私问题。这种智能化技术的进步，将会为我们的生活带来更多便捷和安全，使 AI 技术的发展朝着更加实际和无缝集成的方向前进。53 InfoQ 架构师2025年第一季 Agent Agent 驱动的智能答疑产品构建：问答、诊断驱动的智能答疑产品构建：问答、诊断与修复实践与修复实践 答疑类产品是提升用户体验的重要手段，是平台问题的“

139、清道夫”。然而现有的智能化答疑产品，只能解决少量的静态文本匹配类问题，无法处理用户真实遇到的平台问题。因此才会有著名的“Gartner：64%受访者不希望客服系统部署 AI”事件发生。在 InfoQ 举办的 QCon 全球软件开发大会（上海站）上，阿里巴巴技术专家黄建磊为我们带来了精彩演讲“Agent 驱动的智能答疑产品构建：问答、诊断与修复实践驱动的智能答疑产品构建：问答、诊断与修复实践”，重点阐述在小喵智能答疑产品的研发实践中，如何通过主动问题定位、根因分析、问题修复构建的群体智能体，动态化解决用户问题，提升用户满意度。分享嘉宾 黄建磊 审校 Kitty 策划 QCon 全球软件开发大会

140、54 特别专题|Agentic 软件革命 内容亮点内容亮点 当前国内可用模型和 GPT 的代差，会造成工程层面大量的补丁工作；最真实的 RAG 和 Agent 企业级落地。以下是演讲实录（经以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。进行不改变原意的编辑整理）。我们团队大概在去年 10 月 1 日的时候，开始启动智能答疑系统的研发，现在正好过去一年时间，借这次 QCon 的机会，我们把过去一年在实践过程中遇到的问题以及我们如何解决这些问题分享给大家，希望对大家后续在应用层的落地有所帮助。答疑产品的重要性 答疑产品在我们的生活和工作中无处不在。它是一种用于满足用户在使用特定平台时

141、遇到问题后寻求解决方案的工具。这个特定平台可以被称为“宿主平台”。例如，常见的云产品如阿里云、腾讯云和 AWS 等都具备答疑产品的形态。答疑产品的重要性体现在以下几个方面：如果设计得当，它可以显著提升用户体验、服务质量，并增强用户粘性。这些结论可以从一些公开资料和数据中得到佐证。然而，如果答疑产品设计不佳，反而可能产生负面影响。根据 Gartner 发布的最新报告，一个令人担忧的指标显示，约 60%到 70%的用户不希望他们使用的产品背后的答疑功能是由 AI 驱动的。甚至有超过 50%的用户表示，如果他们所使用的产品背后的智能答疑是由 AI 驱动的，他们可能会转向其他平台。答疑产品是依托于宿主

142、平台的，用户在宿主平台上遇到问题后才会转向答疑平台。接下来，我们介绍一下我们团队所负责的宿主平台。我们平台是阿里巴巴研发运维的基础设施，面向产品研发人员提供软件交付全链路的自动化、平台化和智能化保障。简单来说，这就是一个 DevOps 平台，说得更专业一点，就是 SRE（Site Reliability Engineer-ing，即网站可靠性工程）平台。答疑产品的主要问题 我们先了解一个完整答疑的全链路过程。用户在宿主平台上进行操作时，可能会遇到红色感叹号提示，表明无法继续操作，这意味着用户遇到了问题。此时，用户会转向 55 InfoQ 架构师2025年第一季 智能答疑的 AI 机器人，描述自

143、己遇到的问题，例如“我遇到了什么样的问题，该如何解决？”在智能答疑的背后，首先是一个 RAG（Retrieval-Augmented Generation）系统。RAG 系统包含底层的离线和在线知识库。问题进入系统的第一个环节是问题改写与泛化，这一环节也被称为问题的前置处理。处理完成后，问题会经过文本与向量的两路召回，从知识库中找到与问题最相关的问题-答案对。然后，将这些相关的内容传递给模型，模型会总结出一个答案，并通过答疑机器人告知用户，例如“你可以通过什么操作来解决这个问题”。我想特别强调的是，在接下来的分享中，我不会过多强调 RAG 体系，但这并不意味着它不重要。实际上，RAG 是整个答

144、疑系统中非常关键的环节。目前，无论是学术界还是工业界，对 RAG 的研究已经相当丰富。例如，LangChain、Llama Index 以及许多公开的论文都对这一领域进行了深入探讨。如果大家在 RAG 方面遇到问题，开源社区中已经有大量资源可以提供帮助。对于答疑机器人给出的答案，用户可能不满意，或者不确定答案的正确性，这时他们会转向人工答疑。人工答疑分为两层：第一层是一线答疑人员，他们的主要职责是处理答疑工作。他们通常是非领域专家，主要解决相对简单的问题。一线答疑人员在解决问题时，往往依赖自己的隐性知识即他们头脑中已有的知识。这种隐性知识与显性知识相对，显性知识是指明确记录在文档或知识库中的知

145、识，而隐性知识则是个人在日常工作中积累的经验和直觉。如果一线答疑人员无法解决问题，他们会将问题转给特定领域的专家。这些领域专家可能是功能的开发人员，他们对自己的功能模块和工作流程非常熟悉。他们会利用自己的隐性知识来解决问题。这就是一个完整的答疑系统。在智能答疑系统的开发与落地过程中，我们遇到了三个核心问题。首先，用户的问题描述往往不准确首先，用户的问题描述往往不准确。智能答疑系统依赖于用户的原始问题，但用户在输入问题时，往往只是希望快速绕过智能答疑环节，转而寻求人工帮助。因此，用户输入的问题通常非常简略，甚至不准确。数据显示，约 40%的用户问题长度小于 8 个字符。这种简略且不准确的问题描述

146、，即使后续有最先进的 RAG 体系或领先的模型支 56 特别专题|Agentic 软件革命 持，也很难为用户提供精确的答案。第二是缺乏领域知识第二是缺乏领域知识。当问题从通用领域转向特定私域时，基座模型往往不具备私域领域的专业知识。例如，企业内部的特定知识是基座模型所没有的，这就导致 RAG 体系中的知识库无法提供有效的解决方案。在答疑过程中，无论是人工一线答疑还是功能开发人员，他们解决问题时依赖的往往是自己脑海中的隐性知识，而这些知识并未被纳入 RAG 知识库中。因此，整体私域问题的解决率非常低。第三是用户对第三是用户对 AI 的不信任的不信任。在实际应用中，用户对 AI 机器人给出的解决方

147、案（例如分步骤的操作建议）往往持怀疑态度，甚至在转向人工答疑时，用户会要求一线答疑人员确认机器人给出的答案是否正确。本质上，当前的智能体系给出的是一套面向过程的解决方案，用户需要自行辨别这些解决方案的正确性，而这一过程需要用户承担一定的成本，这是用户不愿意接受的。相比之下，人工答疑给出的答案默认是被信任的，用户会直接执行。目前市场上许多所谓的“AI 产品”其实只是在名称上有 AI，本质上可能只有简单的提示（Prompt），而缺乏真正的智能化能力。在实际落地智能化应用时，我们遇到的这些问题，正是由于智能化本身的基座编程范式改变所引发的连锁反应。这些问题才是我们需要更多精力去解决的。相比之下，一些

148、通用的、常见的组件在开源社区或工业界中都有相对成熟的参考案例。而我所提到的这些问题则更为具体、更具挑战性，这也是我今天分享的核心内容。LLM 如何解决上述问题 接下来我们探讨如何在现有的 AI 基座之上，利用 AI 的能力解决上述提到的三个核心问题。首先，我们着重解决第二个问题缺乏领域知识。在答疑过程中，人工答疑人员通常依赖自己脑海中的隐性知识来解决问题。那么，如何将员工脑海中的隐性知识转化为显性知识，并让这些显性知识能够被上层智能化系统（如 RAG 或模型对齐、SFT 过程中的语料）所利用呢？在解决方案的迭代过程中，我们最初的想法是“人工智能，先有人工，再有智能人工智能，先有人工，再有智能”

149、。因此，我们让一线人员手动编写知识，类似于编写代码的过程。然而，这种方式对开发人员的压力很大，因为它是一个旁路分支，不在他们的日常工作链路中。同时，显性知 57 InfoQ 架构师2025年第一季 识的审核成本非常高，因此这条人工编写的链路难以持续。随着对业界研究的深入，例如清华大学实验室关于智能体与环境对齐的工作，我们意识到可以利用专家知识来训练智能体。这启发我们转变思路：每个员工在日常工作中实际上已经在利用隐性知识解决问题，那么我们是否可以基于这些日常行为来提取显性知识呢？这就是隐性知识显性化解决方案的核心思路。隐性知识显性化 隐性知识显性化是一个相对泛化的命题，不同的场景对知识的需求和知

150、识的表示形式都不相同，因此落地形式也各有差异。举一个具体的案例：我们有一个智能修复 Agent，其中的 Planning 过程至关重要。Agent 在解决问题时需要规划如何解决，而这个规划过程需要私域知识的增强。我们发现，一线员工在构建平台上发起构建时，如果出现错误和错误日志，他们会利用隐性知识通过代码编写来解决问题。此时，错误日志以及解决错误的代码 Diff 可以构成一个生产数据集。我们可以通过这个数据集提取显性知识。第一个阶段是知识提取第一个阶段是知识提取。底层依然使用基础语言模型，核心是利用其推理能力。我们向语言模型提供错误日志和用户代码的 Diff，请求模型提取用户解决问题时的思路。然

151、而，仅靠知识提取还不够，因为模型底层可能存在幻觉，我们需要保证提取内容的准确性。业界常见的准确性解决方案有三种：第一种是找领域专家进行判断，这是最准确的方法；第二种是使用更先进的模型作为“教师”进行判断，但在我们的私域场景中显然不适用，因为私域知识无法让 GPT 或 O1 这样的通用模型进行判断；第三种是我们实践中采用的方法自我一致性。简单来说，就是让模型多次判断同一问题。如果多次判断结果一致，那么在当前场景下就可以认为是正确的。我们将这些经过验证的知识流转到显性知识库中。显性知识的提取核心在于通过精心设计的 Prompt 引导模型完成知识提取。具体来说，Prompt 采用三段论的结构化方式：

152、首先，明确模型的身份和角色；其次，说明模型需要完成的任务；最后，告知模型输入的内容，例如错误日志和用户提交的代码 Diff。我们希望模型能够从这些输入中提取出显性知识，包括识别问题的类型、定位问题的方法、针对此类问题的通用解决路径，以及用户实际采用的解决路径。58 特别专题|Agentic 软件革命 第二个阶段是正确性的判断第二个阶段是正确性的判断。由于模型底层存在不稳定性，例如幻觉等问题，导致其输出可能具有概率性。因此，在正确性判断阶段，我们采用基于自我一致性的方法，让模型对同一问题进行多次判断。这一阶段的 Prompt 设计与第一阶段类似：首先明确模型的角色和任务，然后解释输入内容的含义，

153、最后告知模型需要返回的结果形式。在这一阶段，模型需要从多个维度对提取的知识进行评估，包括：识别的问题是否正确、定位问题的理由是否合理、通用解决路径是否正确，以及用户的解决路径是否正确。最终，模型需要给出一个综合结论。这一阶段的目标是确保提取的知识在准确性上达到可接受的标准。问题感知 Agent 在智能答疑系统中，用户对 AI 结果的信任度较低，尤其是在非编码领域。用户可能不会接受 AI 给出的解决方案，而是选择转人工处理。为了解决这一问题，我们提出了将面向过程的解决方案转变为面向结果的解决方案。传统的面向过程解决方案是指导用户按步骤操作，例如在构建失败的场景中，告诉用户第一步、第二步、第三步应

154、该怎么做。而面向结果的解决方案则是直接为用户提供一个已经验证成功的代码 Diff。这种思路的转变能够降低用户接受结果的成本，从而提高智能答疑系统的拦截率。基于这一思路，我们引入了智能修复 Agent 的概念。我们意识到 Agent 将成为未来智能化应用的核心基座。如果将大语言模型（LLM）比作操作系统，那么 Agent 就是运行在该操作系统上的应用程序。因此，我们构建了一套完整的框架，涵盖 Agent 的定义、运行时管理、数据管理和知识提取。在 Agent 的定义上，我们遵循了社区中广泛认可的 LangGraph 架构。这种架构在底层设计和生态扩展性方面都表现出色。在智能修复 Agent 的具

155、体实现中，我们首先确认构建错误的发生，然后执行修复动作。修复节点中会进行规划（Planning）和排序（Sorting）操作。我们发现，在代码修复场景中，文件修改工具的成功率较低且受多种因素影响，因此我们将文件修改单独作为一个节点处理，并在修复过程中进行数据上报。这些数据对后续优化和效果评估具有重要意义。Agent 运行时的设计至关重要。Agent 本质上是一个典型的“木桶应用”，由多个节点组成，任何一个节点的效果劣化都会对后续环节产生放大效应。为了避免这一问题，59 InfoQ 架构师2025年第一季 我们将 Agent 的运行时设计为一个链表，链表由多个步骤组成，每个步骤对应一个节点的运行

156、时。每个步骤包含两个设计要素：Action 和 Checkpoint。Action 是模型的结构化输出，包括工具选择、行为生成和推理过程；Checkpoint 用于回退，当运行中出现效果劣化时，可以基于某些节点进行回退。Checkpoint 中包含状态（state）和环境（environment），例如当前的 Git 环境或工作区等。此外，我们还引入了 Reward 机制，类似于机器学习中的损失函数，使 Agent 能够自适应地决定是前进还是回退。在数据到知识的维度上，我们继续推进隐性知识显性化的工作。最终，我们直接向用户提供经过验证的代码 Diff，用户可以直接接受而无需再手动执行复杂的步骤

157、。在智能答疑产品的开发过程中，我们整个思路是通过遇到一个个问题并基于这些问题实现一个个 Agent。我们预测智能答疑未来将朝着群体智能的方向演进。尽管过去群体智能可能看起来较为虚幻，但在某些垂直领域和产品中，群体智能的实现或许会更快到来。我们团队将继续面向更多问题，补充更多 Agent，并探索 Agent 之间的自主协作和沟通。我们认为，无论是无论是答疑还是其他智能化应用，未来的底层架构一定是面向答疑还是其他智能化应用，未来的底层架构一定是面向多多 Agent 协作的方式演进协作的方式演进。心得感想 在 AI 产品的开发和应用中，我们有以下几点心得。关注业务价值关注业务价值：当前许多 AI 产

158、品只是名义上有 AI（AI in name only），实际上我们需要真正关注智能化应用的业务价值，避免仅仅为了蹭热度而开发产品。AI 产品的核心价值在于解决实际问题，提升效率或优化用户体验，而非单纯的技术堆砌。进行可行性验证进行可行性验证：与传统软件工程不同，AI 的基础是概率模型，这意味着其输出具有一定的不确定性。在某些需要严格容错的产品场景中，例如胰岛素注射剂量的计算等不允许出错的场景，我们需要更加慎重地验证 AI 的可行性，确保其可靠性和安全性。优化用户体验优化用户体验：用户体验是 AI 产品成功的关键之一，主要体现在以下两个方面。成本与效率的权衡成本与效率的权衡：在 Agent 领域

159、，用户体验和准确率之间往往需要进行权衡。Agent 的运行需要消耗大量资源，因此在设计时需要平衡效率和成本，60 特别专题|Agentic 软件革命 确保用户在使用过程中能够感受到高效和便捷。提供可解释性提供可解释性：为了增强用户对 AI 系统的信任，需要提供更多的可解释性。用户需要了解 AI 为什么做出某个决策或执行某个操作，这有助于减少用户的疑虑，提升他们对系统的信任感。嘉宾介绍嘉宾介绍 黄建磊黄建磊，阿里巴巴技术专家。2017 年担任钉钉桌面前端负责人，是可交互卡片（现酷应用的重要底层能力）的发起人。2021 年开始做 O2 Space 研发平台，通过建设 O2 Pai 的开放能力，打造

160、端到端的开放能力。2023 年至今，担任阿里巴巴爱橙科技的技术专家。研发过程智能化创新小组负责人，探索智能答疑、智能诊断、智能修复等研发过程中的智能化改造，提升研发效率和质量。61 InfoQ 架构师2025年第一季 Andrej Karpathy Andrej Karpathy 爆火演讲刷屏技术圈：爆火演讲刷屏技术圈：AI AI 开启软件开启软件 3.03.0，重写一切的时代来了！，重写一切的时代来了！编者按编者按：近日，在旧金山 AI 创业学校的讲台上，曾任职斯坦福大学、OpenAI 和特斯拉的 AI 领袖 Andrej Karpathy，以一种横跨学术与产业的独特视角，揭示了一场正在重塑

161、技术世界的范式转移。Andrej 看到了一场“编程革命”正在发生。随着 AI 技术的发展，软件编程已经进入了“3.0 时代”，自然语言取代传统代码成为核心编程接口，大模型则承担起过去需要人工编写的复杂逻辑。作者 Andrej Karpathy 编译 冬梅 策划 Tina 62 特别专题|Agentic 软件革命 Andrej 指出，这一转变远非简单的工具迭代。当开发者通过日常语言指令即可驱动系统，当用户的需求能直接转化为机器可执行的意图时，我们实际上是在构建一种“新型计算机”。这种计算机不再依赖精确的语法规则，而是以概率化、语义化的方式理解世界就像人类一样。这种进化对开发者来说是一件好事，这意

162、味着编程门槛的消弭。对用户来讲更是好事，因为能让交互方式彻底解放，人机协作再也没有语言层面的障碍。正如 Andrej 所强调的：我们正站在人机关系的历史转折点上，未来的软件将不再是冷冰冰的工具，而是能理解、推理甚至主动协作的智能伙伴。这场变革的深度，或这场变革的深度，或许不亚于当年从命令行到图形界面的跨越许不亚于当年从命令行到图形界面的跨越。以下内容为以下内容为 InfoQ 基于基于 Andrej Karpathy 在现场分享的视频整理而来，在保持在现场分享的视频整理而来，在保持原意的基础上进行了编译。原意的基础上进行了编译。AI 颠覆了传统的软件构件 很高兴今天在这里和大家聊一聊“AI 时代

163、的软件”。我听说在座很多人是本科、硕士、博士等在读学生，正准备进入这个行业。现在正是进入这个行业的一个非常独特、非常有趣的时间节点。为什么这么说？因为我认为如今的软件正在经历又一次深刻的变革。注意咯，我这里用到的词是“又一次”“又一次”，是因为我其实之前就做过类似的演讲，那为啥还要再做这个话题的演讲？因为软件一直在变，所以我也总能找到新材料来做新的演讲。而这一次的变化，我觉得是非常根本性的。大致来说，软件在过去 70 年里本质上并没有太大改变，但在最近这几年里，它已经经历了两次巨变。因此，我们有大量的工作要做大量的软件需要被重写或重新设大量的软件需要被重写或重新设计计。我们把视角转向软件的疆域

164、。如果我们把它（Map of GitHub）视为软件地图的话，它展示了我们所写的所有软件代码，也就是让计算机在数字空间中执行任务的各种指令。放大之后可以看到，每一个小点其实都是不同的代码仓库，都是已经编写的代码。63 InfoQ 架构师2025年第一季 几年前我开始意识到，软件正在发生变化，开始出现一种“新的软件类型”。当时我将其称为“软件软件 2.0”。软件 1.0，就是我们传统意义上写给计算机的代码。而软件 2.0，本质上是神经网络的权重。你不再直接写代码，而是通过调整数据集、运行优化器，来训练出神经网络的参数。当时神经网络还被很多人当成是像决策树之类的分类器，没什么特别。但我当时的观点是

165、，这其实是一个新的软件范式。现在在软件 2.0 时代，也开始出现类似“GitHub”的东西。比如 Hugging Face，基本上就是软件 2.0 时代的 GitHub。还有像 Model Atlas 这样的可视化工具，可以看到 64 特别专题|Agentic 软件革命 各种模型的参数举个例子，中间那个大圆就是图像生成模型 FLUX 的参数点。每次有人基于 FLUX 微调一个新模型，其实就是在这张图上“提交了一次 git commit”，本质上是生成了一个新版本的图像生成器。所以我们可以理解为：软件 1.0 是写给计算机的代码 软件 2.0 是写给神经网络的权重参数 比如 AlexNet，就是

166、一个图像识别神经网络。过去我们所熟悉的神经网络，大多是“定值函数”型的计算机比如输入一张图像，输出一个类别标签。但最近发生了一个根本性变化，那就是：神经网络变得可以神经网络变得可以“被编程”了“被编程”了，这要归功于大语言模型（LLMs）。所以我认为这是一个全新的计算机世界了。65 InfoQ 架构师2025年第一季 所以这个新时代值得称之为软件软件 3.0：你不再写代码、不再训练神经网络参数，而是直接通过“Prompt”（提示词）来“编程”LLM。更妙的是，这种程序语言就是我们日常说的“英语英语”。这实在是太有趣了。我们再来用一个例子说明下软件 3.0 时代和其他编程方式的区别：假设你要做情

167、感分类，在软件 1.0 时代，你需要写一段 Python 代码，到了 2.0 时代需要训练一个神经网络，而现在，很多 GitHub 代码不只是代码了，你可以直接用英语写一个 Prompt 来让大语言模型输出分类结果。66 特别专题|Agentic 软件革命 这其实是一种全新的编程方式，而且它是用自然语言完成的。几年前我意识到这一点时发了一条推文，很多人因此关注到了这一转变。这条推文现在依然是我置顶的内容：我们现在可以用英语来编程计算机了我们现在可以用英语来编程计算机了。我在特斯拉时曾参与自动驾驶系统的开发。我们试图让汽车自动驾驶，并在当时展示过一个架构图。67 InfoQ 架构师2025年第一

168、季 图中显示，输入来自各种传感器（如摄像头），经过一系列软件处理，最终输出方向盘角度和加速度。当时我指出：系统中有“一吨”左右的 C+代码，也就是软件 1.0，同时也开始出现一些神经网络用于图像识别。这种变化非常有趣随着自动驾驶系统性能提升，神经网络的规模和能力越来越强，同时，我们开始逐步删除大量原本由删除大量原本由 C+编写的逻辑编写的逻辑代码代码。原来那些“把多摄像头图像拼接起来”之类的操作，现在交给神经网络来做。结果是：我们删掉了大量的删掉了大量的 1.0 代码代码。可以说，软件软件 2.0 堆栈“吞噬”了软件堆栈“吞噬”了软件 1.0 堆栈堆栈，变成了系统的主干部分。现在，我们正在经历

169、同样的事情。新的软件范式（软件 3.0）正在快速向整个技术栈渗透。我们现在面前有三种完全不同的编程范式：1.0、2.0、3.0。如果你正要进入这个行业，我建议你最好对三者都非常熟悉。它们各有优缺点：有的功能可能适合直接写代码（1.0），有的适合训练神经网络（2.0），而有些则只需要写一个 Prompt（3.0）。我们会不断面临这样的抉择：这个功能要用哪种方式实现？要不要训练模型？是不是直接用 LLM 生成答案就可以？68 特别专题|Agentic 软件革命 AI 正成为新电力 而我们也必须具备在这三种范式之间灵活切换的能力。接下来，我想进入这场分享的第一部分 大语言模型（LLM）具备公共基础设

170、施、晶圆厂和操作系统的多重特性它们正在成为一种新的“操作系统”，由各大实验室打造，并像公用事业一样进行分发（目前是这样）。很多历史类比都适用在我看来，我们现在的计算水平大概相当于上世纪 60 年代。关于 LLM，以及如何理解这个新范式和生态系统，以及它的样貌，我想引用一段安 69 InfoQ 架构师2025年第一季 德鲁（Andrew）多年前说过的话，他应该接着我后面发言。他当时说：“AI 是新电力。”我觉得这句话很有启发性，它确实很好地捕捉到了一个关键点：LLM 显然具备类似“公用事业”的属性。现在的 LLM 实验室，比如 OpenAI、Gemini、Anthropic 等，会投入大量资本支

171、出（CapEx）去训练 LLM，这就像在建设电力网络。而随后，它们又需要通过 API 把智能能力“供电”给我们所有人，这是运营支出（OpEx）。我们通过按百万 token 计价的方式进行付费接入。这种模式本质上就像对公用事业的需求：我们要求低延迟、高可用、服务质量稳定。在电力系统中，有“切换开关”，可以在市电、太阳能、电池或发电机之间切换。在 LLM 世界里，我们也有“开放路由器”类的机制，可以轻松在多个 LLM 提供方之间切换。因为 LLM 是软件，它们不会在物理空间上产生直接竞争，你可以同时使用多个“供电方”。这点很有趣。前几天我们看到多个 LLM 出现故障，人们突然无法正常工作了。我们逐

172、渐依赖它 70 特别专题|Agentic 软件革命 们到这样一个程度：一旦最先进的 LLM“宕机”，就像发生了“智能停电”，就像电网电压不稳定时整个社会变“笨”了。我们越依赖这些模型，这种影响只会越发明显。但 LLM 不只是具有“公用事业”的属性，它们也有点像“晶圆厂”。训练 LLM 需要的资本支出是巨大的，这不仅仅是造个发电站那么简单。这是一项高强度的研发投资。LLM 技术栈复杂而深，技术秘密正在快速集中在少数几个实验室中。不过类比也开始模糊了，因为毕竟 LLM 是软件，而软件的可变性很强、防御性较弱。不过还是可以找到一些对应关系。例如，可以将“4nm 工艺制程”类比为一个具有固定 FLOP

173、S 上限的 GPU 集群。当你仅使用 Nvidia GPU 做模型训练、而不涉足芯片制造时，这是类似“无晶圆厂”的模式；而如果你像 Google 一样自己设计 TPU 并训练模型，那就是“英特尔模式”你拥有自己的“晶圆厂”。但对我来说，最贴切的类比其实是：LLM 像操作系统。这不仅仅是电力或水这种从水龙头流出的商品，而是越来越复杂的软件生态系统。71 InfoQ 架构师2025年第一季 这个生态系统也开始呈现类似的结构：有封闭源的主流平台，比如 Windows、ma-cOS，也有开源替代品，比如 Linux。对 LLM 来说，我们也有几个闭源的主导者，然后像 LLaMA 这样的开源生态，可能会

174、慢慢成长为 LLM 时代的“Linux”。当然现在还太早，这些 LLM 还相对简单，但它们会快速复杂化，因为这不仅仅是模型本身的问题，还涉及工具使用、多模态融合等等。我曾经尝试画出一张草图，来捕捉这个新范式。LLM 就像一种新型的“计算机”，它类似于 CPU，而上下文窗口就像内存。LLM 负责调度“内存+算力”来解决问题，并调用各种能力。从这个角度看，它非常像一个操作系统。再举个例子，比如你想下载一个应用程序，比如 VS Code。你可以在 Windows、72 特别专题|Agentic 软件革命 Linux 或 macOS 上运行它。同样地，现在你可以拿一个 LLM 应用，比如 Cursor

175、，在 GPT、Claude 或 Gemini 上运行只需要一个下拉选择而已，这非常类似。还有更多类比浮现在我脑海中。我们现在所处的阶段，就像是 1960 年代初期LLM 所需的计算资源还非常昂贵，这使得模型必须集中部署在云端，我们只能作为“瘦客户端”通过网络接入这些计算机。每个人都没有完整控制权，因此我们只能“时间共享”地使用它们就像当年云端计算机的批处理模式。那时候的操作系统也是集中部署的，一切都需要网络传输，大家排队等待自己的“批次”被执行。个人计算机革命还未发生因为经济上还不合理。但现在已经有人 73 InfoQ 架构师2025年第一季 在尝试了，比如 Mac Mini 实际上很适合跑某

176、些 LLM 模型。因为很多 LLM 推理是“batch=1”的，非常依赖内存，而 Mac Mini 恰好内存大，这可能是个人计算机化的早期迹象。不过现在还没人真正发明“LLM 的 GUI”。我每次跟 ChatGPT 或其他模型交流时，都感觉像是在用终端和操作系统交互纯文本接口，直接对话。我们现在看到一些 app 拥有 GUI，但还没有一个“跨任务通用 GUI”出现。这是一个还没被发明出来的机会。LLM 与传统操作系统还有一个重大区别，这点让我特别在意：LLM 颠覆了科技扩散的路径。74 特别专题|Agentic 软件革命 历史上每一项革命性技术电力、密码学、计算、飞行、互联网、GPS 最早的使

177、用者总是政府或大型企业，因为新技术贵又复杂。然后才逐渐扩散到消费者。但 LLM 正好相反。最早的应用者是我们这些普通用户。例如，过去早期计算机用于军用弹道学，但现在 LLM 却在教我怎么煮鸡蛋！我每天的大部分使用就是如此。新的“魔法计算机”现在首先服务的是普通人，而不是国家或企业。政府和企业反而在落后地采用这些技术。这完全颠倒了传统路径，也可能启示我们：真正的 killer app 会从个人用户端长出来。总结一下：LLM 实验室和 LLM 这两个术语现在非常准确。但我们需要意识到，LLM 本质上是复杂的软件操作系统，我们正在“重新发明计算”，就像 1960 年代那样。而且它们现在以“时间共享”

178、的方式提供服务，像公用事业一样被分发。75 InfoQ 架构师2025年第一季 真正不同的是，它们不是掌握在政府或少数企业手里，而是属于我们每一个人。我们每个人都有电脑，而 LLM 只是软件，它可以在一夜之间传遍整个星球，进入数十亿人的设备。这是疯狂的。它已经发生了。现在，轮到我们进入这个行业，去编程这个“新计算机”。太不可思议了。大模型有超能力，也有认知缺陷 要编程 LLM，我们必须先花点时间思考这些东西到底是什么。我尤其喜欢谈谈它们的“心理学”。我喜欢把 LLM 想象成“人类精神”（people spirits）。它们是对人类的随机模拟（stochastic simulation），而这个

179、模拟器恰好是一个自回归 Transformer。Transformer 76 特别专题|Agentic 软件革命 是一种神经网络，它在 token 层面上工作，逐块处理，就像“咔哒、咔哒、咔哒”一样，每一块的计算量几乎是一样的。这个模拟器的本质是某些权重参数，它被拟合到了我们从互联网上获得的所有文本上。于是我们得到了这样一个模拟器。由于它是用人类的数据训练出来的，所以它具备一种“涌现”的类似人类的心理学特征。你首先会注意到的一点是，LLM 具有百科全书式的知识和记忆力。它们可以记住非常多的信息，远远超过任何一个人能记住的量。因为它们读过的东西太多了。这让我想起一部电影雨人（Rainman），我

180、真的很推荐大家去看一下，非常棒的一部电影。我非常喜欢这部电影。达斯汀霍夫曼在里面饰演一个自闭症学者型天才，他拥有近乎完美的记忆力。他能看一遍电话簿，然后就记住所有的名字和电话号码。77 InfoQ 架构师2025年第一季 我觉得 LLM 在某种意义上就很像这样，它们可以轻松记住 SHA 哈希值、各种信息等。所以在某些方面，它们无疑有“超能力”。但它们同样也存在很多“认知缺陷”。例如，它们经常“幻觉”（hallucinate），也就是说，它们会凭空编造内容。它们对于自身知识的内部模型也不够好，至少还不够完善。虽然这方面已经有所进步，但仍然不够完美。它们展现出的是一种“锯齿状的智能”：在某些领域，

181、它们可以展现出超人的问题解决能力，但在其他方面却会犯下人类绝不会犯的错误。例如，它们可能坚持说 9.11 比 9.9 大，或者说“strawberry”里有两个“R”。这些都是比较有名的例子。这些 78 特别专题|Agentic 软件革命“棱角”是你很容易会被绊倒的。它们还会“顺行性遗忘”（Anterograde Amnesia），我这里指的是：如果你有一个新同事加入团队，他会随着时间推移慢慢了解组织、获取上下文、增长知识，他会回家睡觉、巩固知识、发展专长。但 LLM 不会自动做到这些。这其实是目前 LLM 的研发还没有解决的问题。所以，LLM 的上下文窗口其实更像是“工作记忆”。你必须非常明

182、确地对其进行编程，因为它不会像人类一样“自然而然”变得更聪明。我觉得很多人会在这个类比上误入歧途。79 InfoQ 架构师2025年第一季 我推荐大家看两部电影：记忆碎片（Memento）和初恋 50 次（50 First Dates）。在这两部电影中，主角的大脑权重是“固定的”，而上下文窗口每天早上都会被清空。这样一来，要去上班、要维持人际关系就非常困难。而这正是我们每天与 LLM 打交道时经常遇到的情形。还有一点值得一提，是跟安全相关的 LLM 使用限制。比如说，LLM 非常容易“轻信”外界信息，它们容易受到提示注入（prompt injection）攻击的影响，可能会泄露你的数据等等。当

183、然，还有很多其他安全方面的考量。总之，说到底，我们必须一边思考这个具有“超能力”的系统，一边应对它存在的 80 特别专题|Agentic 软件革命 各种认知缺陷和问题。大模型带来的机遇 那么现在的问题在于：我们该如何编程这些系统？我们该如何在避开它们局限的同时，发挥它们的超能力？接下来我想讲的，是如何实际使用这些模型，以及其中存在的一些最大机会 大型语言模型（LLMs）就像“人的灵魂”，这意味着我们可以用它们构建具备部分 81 InfoQ 架构师2025年第一季 自主能力的产品。我整理了一些在这次分享中觉得有趣的点，首先我最感兴趣的是所谓的“部分自主应用”。比如，以编程为例，你当然可以直接去用

184、 ChatGPT，复制粘贴代码，提交 bug 报告，获取回复，再继续复制粘贴。但为什么要这样做？为什么要直接跟操作系统交互？其实更合理的方式，是为这个场景构建一个专门的应用。我想在座很多人可能都在用 Cursor，我自己也在用。Cursor 就是一个很好的例子，它比直接去用 ChatGPT 更合适。它是早期的 LLM 应用中非常典型的一种，具备一些我认为在所有 LLM 应用中都非常有用的共性：82 特别专题|Agentic 软件革命 首先，它保留了传统的交互界面，人类依然可以手动完成所有工作，但在此基础上，它集成了 LLM，可以处理更大块的任务。一些共性的关键点包括：上下文管理上下文管理：LL

185、M 在应用中自动处理大量上下文管理任务；多轮调用编排多轮调用编排：比如在 Cursor 中，底层有用于代码文件的嵌入模型、聊天模型、diff 应用模型等，它们都经过编排协调；专用专用 GUI 的重要性的重要性：我们并不总是希望用纯文本交互，文本不易读、不易理解，而且很多操作也不适合用文本完成。你更希望看到一个 diff，用绿色表示新增、红色表示删除，然后只需 Command+Y 接受、Command+N 拒绝，而不是用文本输入这些命令。GUI 让我们可以快速审查这些不完美的系统，效率更高。我后面会再讲到这一点。再提一个关键特性，就是我所谓的“自主滑块”（autonomy slider）。以 C

186、ursor 为例，你可以选择轻量的补全（你主导），或者选中一段代码 Command+K 修改它，再比如 Command+L 改整个文件，甚至 Command+I 任意改整个 repo。这就是“自主滑块”：你可以根据任务复杂度，选择愿意放权给 LLM 的程度。再看一个成功的 LLM 应用例子Perplexity。83 InfoQ 架构师2025年第一季 它跟 Cursor 类似，具备如下特性：集成了大量信息处理；编排了多个 LLM 调用；提供 GUI 来让你审阅生成结果，比如引用来源你可以点进去看；也有“自主滑块”：你可以只做一次快速搜索，或者进行深度研究，甚至查完 10 分钟后再回来。这些都是

187、你放权的不同层级。所以问题来了：我认为未来大量软件都会变成“部分自主”的，那么这些软件会是什么样子？对于你们这些维护产品和服务的人来说，怎么把自己的产品做成“部分自主”的？LLM 是否能看到人能看到的所有内容？是否能执行人类能执行的所有操作？人是否能始终保持在环中进行监督？因为这些系统仍然容易出错，尚未完美。84 特别专题|Agentic 软件革命 我们还得思考：在像 Photoshop 这样的图形软件里，diff 应该如何呈现？传统软件界面里，很多开关、控件都是为人设计的，现在这些也必须要能被 LLM 理解和访问。关于 LLM 应用，还有一点我认为没有被充分重视：我们和 AI 的协作形式正在

188、发生变化。通常 AI 负责生成，我们负责验证。而我们要让这个生成-验证循环尽可能快，这样我们才能高效地完成工作。让这个循环更快的两个核心方向：加快验证速度加快验证速度：GUI 非常重要。GUI 利用了我们大脑里的视觉 GPU读文本 85 InfoQ 架构师2025年第一季 很费劲，看图很快。可视化能极大提高系统审阅效率；控制控制 AI 行为的范围（“牵好绳子”）行为的范围（“牵好绳子”）：现在很多人对 AI Agent 太激动了。但你看，比如一次性给我生成一个包含 1 万行代码的 diff 并不实用。我作为人类仍然是瓶颈，我必须确认没有引入 bug、逻辑正确、安全无虞等等。所以必须控制 AI

189、的主动程度。我现在做 AI 辅助编程的时候，就是这个感觉：小的字节级补全很顺，但如果让我用一个过于激进的 Agent 来完成任务，那体验就不太好了。我自己还在探索怎么把这些 Agent 融入我的编程流程，实践 AI 辅助编程。我倾向于以小步快跑的方式前进，确保每次修改都是安全的，这样可以让验证-生成循环非常快。86 特别专题|Agentic 软件革命 我也看到很多人分享了关于如何和 LLM 配合的最佳实践。举个例子：如果你的 prompt 很模糊，AI 就容易跑偏，验证失败后你还得重新 prompt，这就拖慢节奏。更好的方式是，在 prompt 上多花点时间，明确具体目标，提高验证成功率，让流

190、程更顺。所以我想，我们都需要摸索出一套自己的 LLM 工作方法。我现在也在思考 AI 与教育结合的方式。你不能指望直接去 ChatGPT 说一句“教我物理”，然后它就能教你。AI 很容易“迷路”。对我来说，这应该是两个不同的应用：一个是给教师设计课程的工具，一个是面向学生的授课工具。它们之间会产生一个“课程”这个中间产物，是可审阅的，可以确保结构合理、内容一致。这种方式把 AI 控制在教学大纲、项目节奏范围内，更容易成功。87 InfoQ 架构师2025年第一季 我还有一个类比想提一下：其实我对“部分自主”不陌生，我在 Tesla 做了五年，这就是个“部分自主产品”。例如，Autopilot

191、的 GUI 就直接嵌在仪表盘里，展示神经网络看到的内容；我们也有“自主滑块”：随着时间推进，Autopilot 能执行的任务越来越多。我想讲一个小故事：我第一次体验自动驾驶是在 2013 年，一位在 Waymo 的朋友带我在 Palo Alto 兜了一圈，我还用 Google Glass 拍了照片。我们开了 30 分钟，从城市到高速一路畅通无阻，没有任何人为干预。当时我心想，“自动驾驶马上就来了！”但如今 12 年过去了，我们仍然在研究这 88 特别专题|Agentic 软件革命 个问题，仍然需要人为参与。你看到路上的 Waymo 车辆，虽然看起来无人驾驶，其实很多时候还有远程操控和人类参与。

192、所以我们仍然没有完全解决自动驾驶问题，虽然现在确实比过去更接近成功了，但它就是很难。“2025 是 Agents 元年”，这种认知让人担忧 我认为软件的复杂性就像自动驾驶一样。所以每次我看到有人说“2025 是 Agents 的元年”，我都会担忧。我觉得这更像是“Agents 的十年”，我们要慢慢推进，让人始终在环内，不能浮躁，这毕竟是软件，要认真对待。我一直脑海里还有一个比喻：钢铁侠的战衣。这个比喻我非常喜欢，因为它非常贴切地展示了技术的本质：它既可以作为增强工具，由 Tony Stark 驾驶，也可以在某些电影里自己飞来救人、完成任务。89 InfoQ 架构师2025年第一季 所以我们要构

193、建的是“战衣”，不是“机器人”。我们不是要一开始就炫技做全自动 agent，而是要先构建具有自主滑块的“部分自主产品”，配备自定义的 GUI 和 UI/UX，让人类的生成-验证循环变得飞快。但我们也不能忘记，长期来看，这些任务是可以被完全自动化的。你的产品中应该包含一个“自主滑块”，并思考如何逐步推进自主程度。我想说的是：现在是构建这类产品的大好机会。氛围编码：是计算机，也具备人的特质 接下来我想换一个话题，谈谈另一个特别的维度不仅是新的编程方式出现了，而且这个“新语言”是用英语来编程。90 特别专题|Agentic 软件革命 也就是说，所有人都可以编程了，因为大家都讲自然语言。这让我极度看好

194、这个方向，因为这在历史上是前所未有的。过去你得花 5 到 10 年学习编程，现在不再需要了。你有没有听说过“vibe coding”？这个概念最早是从我发的一个推文火起来的。当时我没觉得这个推文会火，它只是我一个随手的想法，结果却成了大 meme，后来还有了 Wikipedia 页面之类的。91 InfoQ 架构师2025年第一季 Tom Wolf（来自 Hugging Face）分享了一个我非常喜欢的视频，是一群小朋友在 Vibe Coding。这是个非常温暖的视频。你看完根本不会对未来感到悲观未来真的挺棒的。我觉得这将成为一代人接触软件开发的“网关药物”。我不是“末世论者”，我很看好下一代

195、人。我也尝试过 Vibe Coding，因为它真的太有趣了。Vibe Coding 特别适合那种“周六随便搞点啥”的场景，比如我之前就用它构建了一个 iOS 应用 92 特别专题|Agentic 软件革命 大型语言模型（LLM）如今已经成为数字信息的主要消费者和操作者之一（在图形用户界面/人类和 API/程序之外），所以我们要为 Agent 而构建！我们能否只构建 Agent？我真心希望 Agent 能完成这些工作，我自己可不想干了，谢谢。从宏观上来说，我认为我们迎来了一个全新的数字信息“消费者”与“操作者”类别。过去，只有人类通过图形界面与计算机互动，或者程序通过 API 交互。而现在我们拥

196、有了一个完全不同的新事物：Agent。它们是计算机没错，但也具备某种拟人特质，可以说是“互联网上的人类精神”。它们需要与我们的软件基础设施进行交互，那我们是不是可以为它们专门构建系统呢？这是一个全新的方向。93 InfoQ 架构师2025年第一季 举个例子，就像你可以在自己的网站上放一个 robots.txt 文件，用来指引或建议爬虫行为，未来你也许可以添加一个 llm.txt 文件。它可以是一个简单的 mark-down 文件，向 LLM 说明你这个域名是做什么的。对于 LLM 来说，这种格式非常友好。相比之下，如果它必须解析网页的 HTML 内容，这是非常容易出错且困难的，最终效果通常不理

197、想。所以我们应该直接对 LLM“说话”，这是值得做的事情。现在，大量的技术文档是写给人类看的，会包含列表、加粗、图片等内容，这些对 LLM 来说并不直接可读。我看到有一些服务提供商开始转型，把他们的文档写得更适合 LLM，比如 Vercel 和 Stripe 就是其中较早尝试的企业。他们将文档用 markdown 格式编写，而 markdown 对 LLM 来说是极其易于理解的，这非常棒。94 特别专题|Agentic 软件革命 我也有一个自己的小例子：你们中有些人可能知道 Three Blue One Brown 这个 YouTube 博主，他制作了很多非常漂亮的数学动画视频。我很喜欢他开发

198、的 Manim 库，曾经也想自己做一个类似的动画。95 InfoQ 架构师2025年第一季 Manim 有一份非常详尽的使用文档，但我并不想花时间去读它。我把整份文档复制粘贴给一个 LLM，然后描述了我想要做的动画，它直接就给我生成了代码，结果完全符合我的需求。我当时就觉得太神奇了。所以如果我们能让文档对 LLM 具备可读性，那将会解锁大量的实际用途，这真是太棒了，应该大力推进。但我要强调的是，仅仅把文档格式改成 markdown 还不够，那只是最简单的一步。我们还需要真正改写文档的内容。举个例子，当文档里写着“点击这里”，这是不行的，因为目前的 LLM 还不能原生地执行“点击”这个动作。像

199、Vercel 就在逐步把文档中的“点击”都替换成等效的 curl 命令，这样 LLM 代理就可以代表你执行了。这种做法非常值得参考。此外，Anthropic 推出的 Model Context Protocol 也是一个新的协议，它试图让我们直接与 Agent 对话，把它们当作信息操作者来对待。这类协议我非常看好这类协议我非常看好。96 特别专题|Agentic 软件革命 还有一些我非常喜欢的小工具，它们可以帮助我们以更适合 LLM 的格式 ingest（注入）数据。比如，我去看一个 GitHub 仓库，比如 nanoGPT 这个项目，我不能直接把整个 GitHub 页面给 LLM 分析，因为

200、 GitHub 是为人设计的界面。但如果你把链接从 改成 get.ingest，就可以把整个仓库的所有文件拼接成一个大文本，还自动附上目录结构。这个文本就可以直接复制粘贴给你最爱的 LLM 来提问。更进一步的例子是 Deep Wiki（由 Devon 提供），它不只是提取原始文件内容，还会对 GitHub 仓库进行分析，并为它生成完整的文档页面。你可以想象，将这样的内容直接提供给 LLM 是多么高效。所以我非常喜欢这些小工具，哪怕只改一个链接地址，就可以让内容变得 LLM 友好。97 InfoQ 架构师2025年第一季 当然，未来某一天（其实现在就已经在发生），LLM 可能也能“自己动手”去点

201、击网页上的按钮，执行一些动作。但即便如此，我仍然认为我们应该主动“迎合”它们一部分，让它们更容易访问和理解信息。毕竟目前成本仍然较高，使用也并不简单。大多数软件项目并不具备“数字基础设施”的性质，而是静态的应用或页面，这些项目并不会主动适配 LLM。所以我们仍然需要各种工具来“桥接”这种能力落差。而对于其他更动态、更重要的服务，我认为很值得与 LLM“在中间相遇”。所以我对这两条路径都很乐观（希望这句话听起来合理）。总之，现在是进入这个行业的黄金时代，我们需要重写大量的代码。而这些代码会由专业开发者来写，也会由 LLM 本身来写。我认为，LLM 就像一种基础设施，就像“半导体工厂”或操作系统，

202、但我们目前处于“1960 年代”的阶段，才刚刚开始。这些 LLM 更像是“有缺陷的人类灵魂”，我们必须学会与它们协作。而为此，我们需要调整自己的软件和系统结构。98 特别专题|Agentic 软件革命 所以当你在构建 LLM 应用时，我前面介绍了一些能让你与 LLM 高效合作的方法、工具，以及如何快速启动迭代循环，打造出 MVP（最小可行产品）。当然，也还有很多代码是要专门为这些 Agent 写的。回到那个“钢铁侠战衣”的比喻，我认为未来十年我们会不断“把滑块往右推”，Agent 会更智能，我们的工具也会更强大。我真的很期待看到这个过程会如何展开，也很期待能和大家一起共建这个未来，谢谢大家！9

203、9 InfoQ 架构师2025年第一季 参考链接参考链接 https:/ 100 访谈文章|Interview 吴恩达评吴恩达评 Agent Agent 现状：现状：MCP MCP 还欠火候，单还欠火候，单 Agent Agent 跑通已是“奇迹”，跑通已是“奇迹”，A2A A2A 协作堪称“双协作堪称“双重奇迹”重奇迹”前几天，吴恩达与 LangChain 联合创始人 Harrison Chase 展开了一场对话，而这场对话的背景，正是当前 AI 领域既充满机遇又挑战重重的一个现实。过去几年，AI 工具公司构建出一套功能强大、模块丰富的工具体系。LangGraph、RAG 等组件就像乐高积木

204、，让开发者可以灵活拼装、快速搭建系统。但在真实场景中，往往会卡在某个细节模块，比如上下文管理或评估逻辑。有经验的人能迅速换个解法几天解决，没经验的可能要多绕几个月的弯路。AI 开发的“残酷”之处也在于此没有哪一个工具能包打天下，关键在于是否熟练掌握并高效组合整套工具链。编译 宇琪、Tina 101 InfoQ 架构师2025年第一季 另一方面，工具之间的变化也很快。例如，随着 LLM 的上下文长度持续增加，一年半前的很多 RAG 最佳实践，今天可能就不适用了。而 MCP 的出现则补上了另一个明显的市场空缺，让工具、API、数据源之间的集成变得更容易。但正如吴恩达所言，MCP 仍处在“蛮荒阶段”

205、网上有很多服务端实现，但“很多其实跑不起来”，身份验证和 token 管理也尚不成熟。而且，在 Agent 与 Agent 通信方面，吴恩达坦言，如今大多数人（包括他本人）仍在努力让一个 Agent 正常运行；而要让两个不同人的 Agent 成功协作，则几乎像是完成了两个奇迹。我们翻译了这场对话，以帮助更多中文开发者深入理解吴恩达对 Agent 构建路径、MCP 现状、工具组合能力等核心问题的最新判断与实践思路。Agentic 架构核心在任务分解与流程编排 Harrison Chase：你提议我们不去纠结一个应用是不是“：你提议我们不去纠结一个应用是不是“Agent”（代理），而是”（代理），

206、而是去关注它有多“去关注它有多“Agentic”（具备代理性）。能不能再解释一下这个观点？”（具备代理性）。能不能再解释一下这个观点？吴恩达吴恩达：我之所以提出这个观点，是因为我发现大家在不停地争论：“这个是 Agent 吗？”“这个不算吧？”各种不同的定义争议：它够不够自主？是不是符合某个标准？我当时的感觉是，与其花那么多时间争论这个是不是 Agent，不如我们整个社区换个方式思考：把“Agenticness（代理性）”看作一个光谱有些系统代理性强，有些弱。你想做一个稍微具备一点自主性的 Agentic 系统，或者一个非常自主的系统，都是可以的，没必要非得争论“这算不算 Agent”。所以我

207、提议，我们就叫这些系统“Agentic systems”，然后专注于怎么构建它们。这种思维方式，其实帮我们节省了大量争论时间，让我们能更快进入实操阶段。Harrison Chase：你怎么看这个光谱：你怎么看这个光谱从“低自主性”到“高自主性”？现在从“低自主性”到“高自主性”？现在大家在构建系统时，大多处在哪个位置？大家在构建系统时，大多处在哪个位置？102 访谈文章|Interview 吴恩达吴恩达：很多企业里的实际工作，是让员工在网页上填写表单、搜索信息、查数据库有没有合规风险、判断是否可以向某些客户销售某类产品；或者是复制粘贴一些数据，再做个搜索，再粘贴到另一个表单中。这些业务流程，往

208、往是非常线性的，偶尔出现一点小循环或小分支，通常意味着流程失败，比如因为某个条件不满足被拒绝。所以，我看到大量的机会，都来自这些简单流程。而我也注意到，企业在把已有流程转变为“Agentic workflow（代理性工作流）”时，仍面临很大挑战：比如，你应该把流程拆分到什么样的粒度？任务要分成哪些微步骤？当你构建了一个原型，但效果不够好时，你要改进哪一个步骤才能提升整体效果？这种“从复杂任务中拆解出可执行的微步骤”、设计工作流结构、加评估机制等能力，其实现在还比较稀缺。当然，更复杂的 Agentic 工作流也非常有价值，尤其是包含大量循环的那些。但就“数量”来说，现在的机会，还是主要集中在这些

209、更简单的线性流程里，大家正在一步步把它们系统化、自动化。Harrison Chase：你做了很多深度学习相关的教学，也有很多课程是为了帮助大：你做了很多深度学习相关的教学，也有很多课程是为了帮助大家理解和构建家理解和构建 AI Agents。那么你觉得对于。那么你觉得对于 Agent 构建者来说，哪些技能是最应该掌构建者来说，哪些技能是最应该掌握的？握的？吴恩达吴恩达：我觉得最大的挑战在于：很多业务流程里，牵涉到的是合规、法务、人力等团队的具体操作。那你要怎么构建一个“管道”把这些流程数字化？是用 LangGraph 做集成？还是看看 MCP 是否也能帮助实现？一个很重要但常被忽略的点是：要搭

210、建一个正确的 Eval（评估）体系，不只是评估整个系统的效果，还要能追踪每一步骤，这样你才能快速定位“是哪一步坏了”，“是哪个 Prompt 没有发挥作用”。很多团队在这个过程中可能进展比应有的慢他们一直靠人手评估，每次改完 Prompt，就一个个看输出，人工判断，这会极大影响效率。我认为，构建系统性评估机制是最理想的方式。但问题是，很多团队还没有这种“下一步该做什么”的直觉。技能不足的团队经常会走进“死胡同”比如花几个月去优化一个永远也做不好的组件。而经验丰富的团队会说：“这个方案我们放弃吧，换一条路线。”103 InfoQ 架构师2025年第一季 我希望我能总结出更高效的方式，教会大家这种

211、“经验性判断”，因为很多时候你必须在几分钟甚至几小时内，看着 LangChain 的 Trace 输出、判断当前状态，然后迅速做出决策，而这仍然是非常困难的。从工具到体系：AI 系统构建进入模块化时代 Harrison Chase：你认为这种“经验性判断”，更多是和：你认为这种“经验性判断”，更多是和 LLM（大模型）本身的（大模型）本身的限制有关，还是更偏向产品结构、任务拆解这些“构建能力”？限制有关，还是更偏向产品结构、任务拆解这些“构建能力”？吴恩达吴恩达：我觉得两者都有。过去几年，AI 工具公司构建了一套非常强大的工具体系，包括 LangGraph 在内。你可以思考如何实现 RAG，如

212、何构建聊天机器人，如何做记忆系统、构建 Eval、加上 Guardrails 等等。我经常会用一个类比：如果你手上只有一种颜色的乐高积木，比如只有紫色的，你其实很难拼出复杂的结构。但现在我们有了更多类型的“积木”工具：红的、黑的、黄的、绿的，各种形状和功能。你拥有的积木越丰富，组装成复杂结构的能力就越强你拥有的积木越丰富，组装成复杂结构的能力就越强。我们提到的那些 AI 工具，它们其实是不同形状的“乐高积木”。在构建系统时，你可能就正好需要那个“弯曲奇怪形状的那一块”，有经验的人知道用哪一块，能迅速有经验的人知道用哪一块，能迅速完成任务。但如果你从没做过某种类型的完成任务。但如果你从没做过某种

213、类型的 Eval，可能会因此多花三个月时间，走弯路，可能会因此多花三个月时间，走弯路。而有经验的人会直接说：“我们用 LLM 做 Judge，评估方式换成这个，三天就能搞定。”这也是 AI 比较“残酷”的地方之一它不是一个工具能解决所有问题。写代码时，我自己也会用一堆不同的工具。我不能说自己精通每一个，但我熟悉足够多，可以快速组合。而且，工具之间的变化也很快。例如，随着 LLM 的上下文长度持续增加，一年半前的很多一年半前的很多 RAG 最佳实践，今天可能就不适用了最佳实践，今天可能就不适用了。我记得 Harrison 在这方面很早就开始探索了，比如早期的 LangChain RAG 框架、递

214、归摘要等。而现在，由于上下文窗口扩大了，我们可以往里面直接塞入更多信息。RAG 并没有消失，但调参难度已经大大降低现在有一大段“都还行”的参数区间。所以，随着 LLM 的持续进化，我们两年前的一些直觉，有些可能就已经不再适用了。104 访谈文章|Interview Harrison Chase：有哪些“乐高积木”组件是现在被低估了，但你会推荐大家去：有哪些“乐高积木”组件是现在被低估了，但你会推荐大家去关注的？关注的？吴恩达吴恩达：虽然大家现在都在谈论评估这件事，但很多人其实并没有真正去做。我不太明白为什么不做，可能是因为大家通常认为写一个评估系统是一项巨大而严谨的任务。但我自己是把评估当成一

215、个可以在 20 分钟内快速搭起来的小工具，可能做得不够完美，但可以作为我人工 Eyeball（眼球）评估的补充。经常会发生这样的事：我构建了一个系统，然后某个问题不断出现。我以为修好了，它又坏了，再修好，又坏了。这时候我就会写一个非常简单的评估，可能只包含五个输入样例，用一些非常基础的 LLM 作为评审，只针对这个特定的回归问题做检测比如“这个地方是不是又坏了”。我并不会完全用自动化评估取代人工评估，还是会亲自看输出。但这个简单的评估可以帮我减轻一点负担，自动跑一下，让我不用每次都手动去检查。然后会发生什么呢？就像我们写论文一样，一开始只是搭一个非常简陋、明显有缺陷的评估系统。但等你有了初版，

216、你会想“其实我可以改进它”，然后就开始迭代优化。很多时候我就是从一些糟糕透顶、几乎没什么帮助的评估开始做起的。然后随着你查看它的输出，你会发现“这个评估系统是坏的，但我可以修好它”，就慢慢让它变得更好。另一个我想提的点是，虽然大家也讨论得挺多，但我觉得还远远被低估的，是 Voice stack（语音技术栈）。这是我非常感兴趣的领域，我身边很多朋友也很看好语音应用。我们也看到不少大型企业对语音技术极其感兴趣，而且是规模很大的企业、使用场景也很大。虽然这个社区里也有一些开发者在做语音，但开发者的关注度相比这些企业的关注度还是小得多。而且我们说的也不仅仅是实时语音 API，也不只是 Speech-t

217、o-text 那类原生音频模型因为那种模型往往很难控制。我更喜欢一种基于 Agentic 工作流的语音技术栈，它更容易控制。我最近在和很多团队一起做语音栈相关的项目，有些希望很快能对外公布。还有一个可能不算“被低估”，但我认为更多企业应该去做的事情是让开发者使用 AI 辅助编程。很多人应该都见过，使用 AI 辅助的开发者效率远远高于不使用的 105 InfoQ 架构师2025年第一季 开发者。但我还是看到很多公司，尤其是 CIO、CTO 们，还制定了一些政策，不允许工程师用 AI 编程工具。我知道有时也许是出于合理原因，但我觉得我们需要尽快突破这个限制。坦白讲，我和我的团队，已经完全无法想象在

218、没有 AI 帮助的情况下写代码了。但现在还有很多企业需要接受和适应这一点。还有一个被低估的观点是，我觉得“每个人都应该学一点编程”。我们 AI Fund 的一个有趣事实是：我们公司每个人都会写代码，包括前台接待、CFO、法务总顾问所有人都会写。不是说我希望他们成为软件工程师，但在自己的岗位上，他们通过学一点点代码，能够更清晰地告诉计算机他们想做什么。这带来了各个非工程岗位的显著生产力提升，这个现象我也觉得挺令人激动。Harrison Chase：说到：说到 AI 编程，你自己现在在用什么工具？编程，你自己现在在用什么工具？吴恩达吴恩达：我个人现在会用 Cursor、WindSurf，还有一些别

219、的。语音交互关键是对“延迟”的要求 Harrison Chase：如果现在有人想进入语音这个方向，而他们之前已经熟悉了用：如果现在有人想进入语音这个方向，而他们之前已经熟悉了用 LLM 构建构建 Agent，那你觉得他们的知识迁移性有多强？有哪些是相通的？又有哪些是，那你觉得他们的知识迁移性有多强？有哪些是相通的？又有哪些是全新的需要学习的？全新的需要学习的？吴恩达吴恩达：我觉得有很多场景语音其实是非常关键的，它带来了某些新的交互方式。从应用层面看，文本输入其实是一个“令人畏惧”的交互方式。你去跟用户说，“告诉我你的想法，这是一个输入框，写点文字吧”，很多人会觉得压力很大。而且文字输入还能退格

220、，用户回复速度就更慢。但语音就不一样了：时间是往前推进的，你说了就说了，也可以临时改变主意，比如说“我改主意了，忘了我前面说的”，模型其实处理这些的效果还不错。所以很多时候，语音可以降低用户使用门槛。我们说“说说你的想法”，用户就自然地开口了。语音系统和文本系统最大的区别在于对“延迟”的要求。如果用户说话了，系统理想中需要在一秒内做出回应（最好是 500 毫秒以内，但至少不能超过一秒），但传统 Agentic 工作流可能需要几秒钟甚至更久的处理时间。比如我们在做一个“我的虚拟分身”项目，你可以在网页上和自己的虚拟形象对话。我们最初版本有 59 秒的延迟 106 访谈文章|Interview 你

221、说完话，沉默九秒钟，然后分身才回答，这是非常糟糕的体验。后来我们做了一些“预回应”设计。比如你问我一个问题，我可能会先说：“嗯，这是个有意思的问题”或者“让我想想”。我们就让 ARM 模型去做类似这样的回应，用来掩盖延迟，这招效果很好。还有一些其他小技巧，比如说，如果你做的是语音客服机器人，在等待期间播放背景音（比如呼叫中心的噪音），而不是完全的静音，用户就会更容易接受系统的“迟钝”。而且在很多应用中，语音让用户更容易进入状态，降低了“自我审查”的门槛。人们说话的时候，不会像写字那样追求完美。他们可以随便说说，改口、反复、自由表达这让我们更容易从他们那里获取有用信息，也能更好地帮助他们推进任务

222、。“如果说 MCP 还早期，那 Agent 间通信就更早期了”Harrison Chase：你认为：你认为 MCP 在应用构建方式、类型上，带来了哪些变化？你在应用构建方式、类型上，带来了哪些变化？你怎么看它对整个生态的影响？怎么看它对整个生态的影响？吴恩达吴恩达：我觉得 MCP 非常令人兴奋。我个人非常喜欢 MCP，它补上了一个明显的市场空缺，而 OpenAI 的快速跟进也说明了这个标准的重要性。我觉得 MCP 标准未来还会不断演进，目前它主要让 Agent 更容易接入各种数据，但其实不只是 Agent，很多其他软件也可以受益。我们在用 LLM 的时候，尤其在构建应用时，往往会花很多时间在“

223、管道”上也就是各种数据接入工作上。尤其是在大企业环境下，AI 模型其实已经很聪明了，只要给它正确的上下文，它就能做出合理的事情。但我们往往要花大量时间处理接入工作，搞清楚怎么把数据喂给模型，才能让它输出你想要的东西。MCP 正是在这方面起到了很大的标准化作用，它让工具、API、数据源之间的集成变得更容易。当然，现在当然，现在 MCP 还是有些“蛮荒”。你在网上能找到很多还是有些“蛮荒”。你在网上能找到很多 MCP 服务端，但很服务端，但很多其实跑不起来。身份验证系统也很混乱，就算是一些大公司，多其实跑不起来。身份验证系统也很混乱，就算是一些大公司，MCP 服务也存在服务也存在 to-ken 是

224、否有效、是否过期等问题。是否有效、是否过期等问题。此外，我觉得 MCP 协议本身也还很早期。现在的 MCP 会返回一个很长的资源列 107 InfoQ 架构师2025年第一季 表，未来我们可能需要某种分层发现（hierarchical discovery）机制。比如你要构建一个系统我不知道将来会不会有 LangGraph 的 MCP 接口但像 LangGraph 这样的系统，有成百上千个 API 调用，你总不能把所有调用都塞进一个扁平列表里让 Agent 去自己筛选。所以我们可能需要一种层级式的资源发现机制。我觉得 MCP 是个非常棒的第一步。我非常鼓励大家去了解它，它可能真的会让你的开发更轻

225、松，尤其是如果你能找到一个稳定好用的 MCP 服务端实现来帮你做数据整合的话。我也认为，从长远看这点非常重要如果你有 n 个模型或 Agent，要接入 m 个数据源，那你不该为了每一个组合都单独写接入逻辑，工作量不应该是 n m，而应该是 n+m。而我觉得 MCP 就是朝着这个方向迈出的非常棒的第一步。它还需要继续演化，但的确是个好起点。Harrison Chase：还有另一种协议，虽然不像：还有另一种协议，虽然不像 MCP 那么热，但也值得关注，就那么热，但也值得关注，就是是 Agent 与与 Agent 之间的通信。那么你怎么看之间的通信。那么你怎么看 Agent 与与 Agent 通信的

226、发展？通信的发展？吴恩达吴恩达：现在的 Agent AI 依然非常早期。我们大多数人，包括我自己，在让自己的代码正常运行这件事上都还在挣扎。所以要让我的 Agent 和另一个人的 Agent 正常协作，就像是实现了两个奇迹。目前我看到的情况是：一个团队内部自己构建的多 Agent 系统，是可以运转起来的。因为大家都在同一个团队，知道协议、约定、接口是什么，也知道怎么打配合这样就能跑起来。但要让一个团队构建的但要让一个团队构建的 Agent 能和另一个完全不同团队的能和另一个完全不同团队的 Agent 协同，现在来看，还太早协同，现在来看，还太早。我相信我们终究会实现这一点，但就我自己目前观察到

227、的，还没有看到太多真正成功、规模化运行的案例。不知道你们是不是有类似的观察？Harrison Chase：没错，我同意你的看法。如果说如果说 MCP 还早期，那还早期，那 Agent 间间通信就更早期了。通信就更早期了。用“vibe coding”编程累死我了 Harrison Chase：你怎么看待：你怎么看待 vibe coding（氛围编程）？它和传统编程相比是（氛围编程）？它和传统编程相比是否是一种新的技能？它在当今世界中起到什么作用？否是一种新的技能？它在当今世界中起到什么作用？108 访谈文章|Interview 吴恩达吴恩达：我觉得我们很多人现在编程的时候几乎不再看代码了，这其实

228、是一种非常棒的进展。不过我觉得“vibe coding”这个名字挺不幸的，因为它会让很多人误解，以为这件事只是“靠感觉”比如这个建议我接受，那个我拒绝，仅凭直觉判断。但说实话，当我花一天时间用这种“vibe coding”方式，也就是借助 AI 编码助手工作后，我通常会感到非常疲惫。这其实是一种非常需要智力投入的活动。所以我认为虽然这个名字不好，但这个现象是真实存在的，而且它的确在发展，而且是件好事。过去一年里，有一些人在建议别人“不要学编程”，理由是 AI 会自动帮你写代码。我认为未来回头看这将会是史上最糟糕的职业建议之一。如果你回顾过去几十年的编程发展历史，每一次编程门槛降低，都会让更多人

229、开始学习编程。比如从穿孔卡片转向键盘和终端，或者从汇编语言过渡到 COBOL，我甚至找到了一些非常古老的文章，当时就有人声称，“我们有了 COBOL，就不再需要程序员了”。但事实是，每次编程变得更简单，学习编程的人反而变多了。所以我认为，AI 编码助手也将推动更多人学习编程。而且，未来最重要的技能之一，无论是对开发者还是非开发者来说，都是“清晰准确地告诉计算机你想做什么，让它替你完成”这件事。想要做到这一点，了解一些计算机的基本工作原理其实非常有帮助。我知道你们在座的很多人已经理解了这一点。但这也是我为什么一直建议大家至少学会一门编程语言，比如 Python。也许你们有人知道，我自己是一个 P

230、ython 能力比 JavaScript 更强的人。但在使用 AI 编程助手之后，我写了比以往更多的 JavaScript 和 TypeScript 代码。即使是调试那些 AI 帮我生成、而不是我亲手写的 JavaScript 代码时，理解其中的错误类型和含义，对我来说仍然非常重要，帮助我去修复它们。胜负决定于速度和技术能力 Harrison Chase：你最近宣布了一个新基金：你最近宣布了一个新基金AI Fund 的新进展，对于在座有的新进展，对于在座有创业想法的人来说，你有什么建议？创业想法的人来说，你有什么建议？吴恩达吴恩达：AI Fund 是一家 Venture Studio（风险投资

231、孵化器），我们不仅投资公司，109 InfoQ 架构师2025年第一季 而且只投资我们共同创办的公司。回顾 AI Fund 的经验，我觉得创业成功的首要预测因素就是速度。虽然我们身在硅谷，但我发现很多人其实从未真正见识过一支高效团队可以有多快地执行。如果你见过的话，你会知道，这种速度是传统企业完全想象不到的。第二个关键预测因素是技术能力。虽然像市场营销、销售、定价这些商业技能也很重要，而且相关知识已经积累了很久、相对普及，但真正稀缺的资源是“技术理解力”因为技术在快速演进。我对擅长 go-to-market（商业推进）的人非常尊重，定价很难，营销很难，产品定位也很难，但这些知识是更容易被学习到

232、的。真正稀缺的是那些真正懂技术的人，知道什么该做、什么不该做、怎么可以让事情加速两倍。所以 AI Fund 非常喜欢和技术背景深厚的人合作，尤其是那些对方向有直觉判断的人。而商业相关的能力当然也很重要，但它们相对更容易补足。参考链接参考链接 https:/ 110 访谈文章|Interview“我已经过时了”！“我已经过时了”！83 83 岁图灵奖大师、龙书岁图灵奖大师、龙书作者在大模型时代的技术焦虑：越来越难以适作者在大模型时代的技术焦虑：越来越难以适应新技术应新技术 在计算机科学领域，Jeffrey Ullman 是一个无法忽视的名字。这位 83 岁的斯坦福大学荣誉教授，既是编译器：原理、

233、技术和工具（俗称“龙书”）的合著者、数据库理论的奠基人，也是 2020 年图灵奖得主。他的职业生涯贯穿了计算机科学发展的关键时期从编译器开发到数据库理论构建，再到算法研究突破，他的工作深刻影响了计算机科学的发展，尤其通过编译器：原理、技术和工具和数据库系统原理等经典教材，塑造了无数程序员的思维方式。前几天，这位白发苍苍的学者在一次采访中展现出了令人敬佩的坦诚。他在对话中编译 核子可乐、Tina 111 InfoQ 架构师2025年第一季 多次提到，技术是年轻人的游戏，而随着年龄的增长，他自己也越来越难以适应新技术。例如，他谈到使用大模型时自己不太理解其逻辑，以及在使用手机导航和连接车载系统等日

234、常技术时遇到的挑战。这番感慨恰如其分地映照出当下技术变革的独特性：当一位曾定义过“技术标准”的宗师级人物，也开始在 AI 浪潮中重新寻找方向，这本身便成为了关于技术进化的深刻隐喻。在本次专访中，Ullman 教授还系统回顾了自己跨越半个多世纪的学术生涯，分享了他对技术迭代的思考，并强调了技术发展的不可预测性。他指出，许多重大的技术变革在出现之前常常是无法预见的。举例来说，1992 年他与其他学者讨论“信息高速公路”时，几乎没有人提到万维网，而当时瑞士的万维网技术已经出现。这表明，许多技术突破往往在专家和业内人士未曾意识到之前悄然到来。在展望未来技术时，他说软件工程领域最大的转变是从机器语言到高

235、级语言（如 Fortran）的演变，而如今大模型直接生成代码，这一变革的意义甚至超过了当初的变化。他认为，软件工程正在经历从“算法”到“算法+数据”的转变，并行化的引入也肯定会逐渐改变我们对计算机能做什么的思考方式。并行计算对计算机科学的深远影响 主持人：很高兴与您交谈。我知道您有着丰富而多样的职业经历。您最近又有什么主持人：很高兴与您交谈。我知道您有着丰富而多样的职业经历。您最近又有什么新见闻？我注意到新见闻？我注意到您说您所做的很多事情都已经是“老古董”了。那您如何描述当下的您说您所做的很多事情都已经是“老古董”了。那您如何描述当下的自己？自己？112 访谈文章|Interview Jef

236、frey Ullman：我基本上已经退休了，已经是个“过气”人物了。没错，我们总得面对现实，计算机科学是年轻人的游戏，而我已经不再年轻了。主持人：这话也对。不过，我认觉得您所做的一些事情在这个快速变化的领域中仍主持人：这话也对。不过，我认觉得您所做的一些事情在这个快速变化的领域中仍然有着惊人的生命力。当我向别人提到“我将要采访然有着惊人的生命力。当我向别人提到“我将要采访 Jeffrey Ullman”时，他们立刻”时，他们立刻就会说：“哦，龙书，我知道龙书。”我想花几分钟时间谈谈这本书。虽然它就会说：“哦，龙书，我知道龙书。”我想花几分钟时间谈谈这本书。虽然它有些年头了，但当我与新的计算机科

237、学毕业生交谈时，他们仍然在谈有些年头了，但当我与新的计算机科学毕业生交谈时，他们仍然在谈论龙书。您觉论龙书。您觉得这本书为什么会如此成功？得这本书为什么会如此成功？Jeffrey Ullman：我想答案就在名字里。它的封面很酷。很明显，人们喜欢拿着这本印有龙图案的书在校园中走来走去，甚至因此而选择计算机科学专业。这可能就是我一生中做出的最大贡献让一些原本可能浪费生命在物理学等领域的聪明孩子转而投身计算机科学。主持人：说起编译器，我知道在您开始研究时，那会编译的语言可能要比今天的主主持人：说起编译器，我知道在您开始研究时，那会编译的语言可能要比今天的主流语言简单得多。语言设计和编译器方面也经历了

238、一系列发展。多年来，您在语言设计流语言简单得多。语言设计和编译器方面也经历了一系列发展。多年来，您在语言设计和编译器方面有没有发现什么特别有趣的变化？和编译器方面有没有发现什么特别有趣的变化？113 InfoQ 架构师2025年第一季 Jeffrey Ullman：我觉得最大的变化在于，我们现在主要是为并行机器编译，包括我们现在主要是为并行机器编译，包括八核处理器啦、大型超级计算机之类八核处理器啦、大型超级计算机之类。这些问题在龙书的最后一版中才开始被提及，主要是因为 Monica Lam 专门研究这个领域也就是并行编译。但在我们撰写前三版时，甚至都没有真正考虑过这个问题，可能当时这确实也不值

239、得考虑。毕竟那会是 1977 年，并行编译真的没那么重要。主持人：是的。而且我在研究您的职业生涯和著作时发现了一个贯穿始终的主题，主持人：是的。而且我在研究您的职业生涯和著作时发现了一个贯穿始终的主题，您会从基本的理论抽象开始思考，考虑不同层次的抽象，然后将它们应用到实际问题中，您会从基本的理论抽象开始思考，考虑不同层次的抽象，然后将它们应用到实际问题中，从非常抽象的理从非常抽象的理论方法逐步深入到更高层次的上下文或实现细节。我很好奇，随着我们论方法逐步深入到更高层次的上下文或实现细节。我很好奇，随着我们向更多的并行计算转变，我们所需要的抽象是否发生了变化？向更多的并行计算转变，我们所需要的抽

240、象是否发生了变化？Jeffrey Ullman：当然，如果是为串行机器编译，就不需要处理并发控制等问题的任何抽象。我认为 MapReduce 就是并行计算的一个有趣抽象，这些东西在 20 世纪 70 年代是没有任何意义的，也完全没有任何实用价值。主持人：没错，主持人：没错，MapReduce 是一个很好的过渡是一个很好的过渡我看到您最近的一些工作确实我看到您最近的一些工作确实跟大规模数据挖掘和处理网络规模的数据有关。您在这个领域也写了一本书，其中将跟大规模数据挖掘和处理网络规模的数据有关。您在这个领域也写了一本书，其中将 MapReduce 作为分析案例。随着我们不断扩展规模上限，您认为还有哪

241、些关键部分被作为分析案例。随着我们不断扩展规模上限，您认为还有哪些关键部分被整合进去了？整合进去了？Jeffrey Ullman：很明显，将世界上所有的数据整合在一起给了我们一种惊人的力量，这是之前从未有过的。我指的自然就是大语言模型。当然，其中仍然有一些粗糙的细节需要打磨。但无论如何，它已经赋予了人们做出各种奇妙事情的力量。同样的情况也发生在 5 到 10 年前，那时候首次出现了大规模神经网络。让它们发挥作用的原因不仅是出现了廉价的大规模计算设备，还有大规模数据集的诞生。当然，人们常常忽视数据的重要性。这不仅仅是算法的问题，数据同样重要。比如我听说人们现在担心大语言模型已经达到了极限，因为我

242、们已经吸收了所有人类创作的文字，再也没有更多素材了。这个问题很有意思，我估计会在几年内看到这种观点是否属实，或者说，大家会想 114 访谈文章|Interview 办法制造从未真正存在过的数据。比如说，如果你想通过机器学习来识别肿瘤，你可以拍摄一张肿瘤图像，将其放大 10%或旋转 10%，从而创建额外的可用数据，而无需实际拥有更多数据。总而言之，这是一个值得关注的方向。主持人：是的，我认为这里的关键在于，有没有用到底该如何定义。在图像示例中主持人：是的，我认为这里的关键在于，有没有用到底该如何定义。在图像示例中这应该是成立的，因为可以推理出在计算机看来不同的东西，而我们又可以验证它们是这应该是

243、成立的，因为可以推理出在计算机看来不同的东西，而我们又可以验证它们是相同或说等效的。但在其他领域，情况会不会有所变化？相同或说等效的。但在其他领域，情况会不会有所变化？Jeffrey Ullman：说得对，而且我也没有答案。就像我前面说的，这是个有趣的问题。我相信人们现在正在朝这个方向研究。主持人主持人：是的。既然谈到了这一点，我想到您曾经写过关于在处理这些大规模数据情况时降维的重要性。我在想，这是否与人们在蒸馏模型时试图提取相关维度的方式有关。Jeffrey Ullman：说实话，我不记得自己有写过这方面的内容 主持人主持人：可能是在您的书里 Jeffrey Ullman：数据集这本书确实讨

244、论了降维。在理解数据时，降维通常是一个有用的工具，因为对于某些非常复杂的高维数据，有各种技术帮助我们聚焦于真正重要的部分。主持人：没错。说回抽象视角，您提到了大语言模型存在一些粗糙的细节。您觉得主持人：没错。说回抽象视角，您提到了大语言模型存在一些粗糙的细节。您觉得具体有哪些挑具体有哪些挑战？作为软件工程师，我们在使用这些东西时的关键抽象是什么？或者，战？作为软件工程师，我们在使用这些东西时的关键抽象是什么？或者，我们是否遗漏了一些需要弄清楚的抽象元素？我们是否遗漏了一些需要弄清楚的抽象元素？Jeffrey Ullman：这是个好问题。我觉得我们还没有真正找到该如何使用大模型的我觉得我们还没有

245、真正找到该如何使用大模型的终极答案终极答案。有趣的是，斯坦福大学从来没开设过如何使用谷歌搜索、如何创建搜索查询的课程。但现在我们正在教授一门名为“提示词工程”的课程。许多学校可能都在开设或将会开设这样的课程。就是说“提示词”这个概念似乎得到了广泛认可，而且也许需要被抽象化或以某种方式进行理解。但无论如何，我还没看到能切实指导我们使用提示词的具体 115 InfoQ 架构师2025年第一季 原则。我自己也摆弄过提示词。在职业晚期，我做过大量的编辑工作。我为一家期刊工作，那里有 300 名编辑，而我是唯一的计算机科学编辑，所以很多工作都堆到了我这里。我发现自己根本读不懂眼前的内容，也没有人可以交流

246、。所以我开始使用各种大语言模型。我会先向模型提供优秀审稿人的标准，然后说：“这是论文摘要。请推荐一些理想的审稿人选。”有时，它确实能准确推荐，并介绍一些我从未见过但实际上相当先说的人选。也有时候，它会坦率地讲：“这对我来说太难了，您可以参考以下审稿人筛选方法。首先阅读文献，然后”这基本上是一个完全无用的评论。坦白说，我不知道为什么会出现这样的差别是摘要的详细程度，还是我对想要的东西的定义方式？我不知道。这里有很多非常神秘的东西，我认为还有待人们去探索。主持人主持人：一点没错。我觉得这里机会很大。我见过一款工具，尝试像简单的编译器那样编译提示，其中包含不同的层次，可以看到它将组件组合并整理成不同

247、的风格，以此适应不同的大模型。我猜它并没有做任何优化，只是专注于如何从高级组件集转换为适用于 Anthropic 与 ChatGPT 的提示词形式。但我认为，它其实已经是某种类似于编译器的等效物，它能理解提示这些不同模型的正确方法，并将需求意图跟更好的提示方式映射起来。Jeffrey Ullman：是的。这是个不错的研究课题。自动化与教师角色 主持人：这会是个不错的研究课题。说到研究，您提到最近自己一直在积极从事一主持人：这会是个不错的研究课题。说到研究，您提到最近自己一直在积极从事一个不同的项目。能给我们多透露点细节吗？个不同的项目。能给我们多透露点细节吗？Jeffrey Ullman：我想

248、想哈。再次强调，我希望自己在晚年也能有点事干。我想大概是在 2000 年初，我和几个朋友创办了一家名叫 Gradiance 的小公司。它的目标是实现家庭作业自动化，我们采用的基础架构是：对学生来说，它看起来像是一系列的简短选择题，整个解题过程就是从四个选项中选择正确的答案。116 访谈文章|Interview 但跟常规的选择题不同的是，我们希望家庭作业实现的不仅是测试，还要进行教学。如果你答错了，我们会给你一个提示，并要求你重新做一遍整个过程。传统选择题的问题是，如果你猜 A，但结果是错的，然后猜 B，最终总会在不付出任何努力的情况下得到正确答案。我们的解决方法是开发了所谓的“根问题”，即拥有

249、多个正确答案的问题。那这个思路是如何实现的呢？比如，问题是解方程 2x 加 5 等于 10，求 x。现在，这只有一个正确答案，应该是 2.5。看起来只有一个正确答案。但事实上，我们要求学生做的是提供解题过程。你要把步骤写下来。如果你答对了，就是 x 等于 2.5。所以我们提供的选项不是 x 的值，而是告诉关于计算 x 的一些正确信息。比如你可以初步得出一个正确答案，即 x 不是整数，或者 x 小于 3，或者 2x 是质数。如果你知道 x 是什么，就很容易认出这些正确答案。如果你不知道 x 是什么，你就只能猜测。我们认为可以通过出售这项服务赚很多钱，但实际上商业反响并不好。其实大家还是愿意使用，

250、目前的用户也不少。比如开罗大学就是我们最大的用户，但他们不会为此付费。大概是两年前，我在班加罗尔做过一次关于这项技术的演讲，听众中有一位 Infosys 的创始成员，他非常兴奋，说：“我们可以用这个来教数学，”其他人也可以。看看 Gradiance 的网站，就会发现这里在用同样的方法教授计算机科学，从 Java 编程到编译器、再到操作系统和数据挖掘。但项目的商业化还是决定从数学入手。于是他筹集了一些资金，组建了一支团队。产品还在制作当中到目前为止，我们一直针对九年级的数学课程。顺便说一下，印度的九年级数学大多是我十年级和十一年级学的东西。但这个不重要。总而言之，我们希望这些素材能在印度乃至世界

251、各地供大家免费使用。同样的，这个想法不仅是要确保学生掌握了材料，还要在他们遇到困难并给出错误答案时，提供相关的提示或解释。我们希望这最终能帮助他们答对所有的问题。主持人：是的。我觉得现在人们非常关注广泛的主持人：是的。我觉得现在人们非常关注广泛的 AI 应用领域，即我们如何扩展教应用领域，即我们如何扩展教育规模，让学生们按照自己的节奏学习，而不过分依赖个别教师。育规模，让学生们按照自己的节奏学习，而不过分依赖个别教师。Jeffrey Ullman：这确实是个有趣的点。同样的，大约在我们创办 Gradiance 的同 117 InfoQ 架构师2025年第一季 时，MOOCs（大型开放在线课程）

252、风靡一时，人们甚至觉得以后大学都没必要存在了。后来怎么样了？我认为回答这个问题很重要。关键在于：当通用汽车决定用机器人取代装配线工人时，没有人会问装配线工人是否相信机器人能够胜任工作，对吧？但当学术界引入替代方式，也就是把技术引入教学流程时，教师却完全有权说：“不，不应该这样。我不想在自己的课堂上用这种技术。”这跟其他产业应用完全不同。所以结果自然很糟糕。技术的应用不仅遇上了明显的阻力，特别是那些工作受到威胁的人。而且事实证明，对于 95%的学生来说，MOOC 并不足以达成教育目标，因为人会需要帮助。也就是说，我们只能自动化其中一部分。我认为 Gradiance 做到了一点，但人们遇到困难时总

253、还是需要求助。MOOC 无法消除对教学专业人员的需求。它或许可以减轻教师们的一些负担，从而提高他们的效率，这意味着整个行业对教师的需求量会减少。生活就是这样，每个领域都是如此。我觉得我们还可以做更多如果教师们愿意，比如说播放 MOOC 视频课，就像他们过去会选定教学大纲一样。教科书和教学大纲承担了一部分教学工作，现在 MOOC 可以承担更多的教学工作，但仍然需要有人来主持课堂，特别是处理不断出现的各种特殊情况。当然，还有验证的问题。比如学生可以注册一个 MOOC 账号，然后让家里的哥哥姐姐帮自己完成所有作业，没有人会知道。单纯注册了某门课程并完成了 MOOC 的测验，并不代表你自己有解决问题的

254、能力。好吧，其实也有相应的技术方案比如要求学生们接受指纹验证等等。但这不是长久之计。教师的意义就在于随时帮助学生解决他们遇到的各种问题，确保大家能够得到帮助和引导。我觉得这样的教学方式是不会改变的。所以虽然每个环节都有相应的技术方案，但我也完全能够理解为什么学校对于教学自动化会比较抗拒。技术适应的代际挑战：从提示工程到人机交互新挑战 主持人：下面咱们聊点同样跟学习相关，但又有点不同的方向。您谈到了斯坦福大主持人：下面咱们聊点同样跟学习相关，但又有点不同的方向。您谈到了斯坦福大学现在开设提示词定义、或者叫提示词工程课程。学现在开设提示词定义、或者叫提示词工程课程。Jeffrey Ullman：行

255、业术语应该叫提示词工程。118 访谈文章|Interview 主持人主持人：对对，提示词工程。我们当然可以讨论这到底能不能算工程，但您谈到了这一点。我们谈到了应用技术成果来帮助扩展学习，包括您在 Gradiance 所做的工作，以及大型在线课程做出的相关尝试。我觉得我们现在处于一个对于技术变革有着很多抵触情绪的时代。世界各地的人们对于大模型都有很多抵触情绪。所以我很好奇，您觉得您觉得我们该如何让人们适应正在发生的技术变化？我们该如何让人们适应正在发生的技术变化？Jeffrey Ullman：这事可不容易，我觉得恐怕得等到下一代人成长起来才行。主持人主持人：您是这么理解这个问题的吗？直接放弃目前

256、比较抗拒新技术的这一代人？Jeffrey Ullman：没办法。随着我年龄的增长，我发现自己也越来越难以适应新技我发现自己也越来越难以适应新技术术。顺便说一下，人机交互（HCI）领域已经存在了很长时间。但我没有看到任何人在解决怎么跟老年人打交道的问题，所以我个人是比较悲观 主持人主持人：我也有体会。我的父母越来越老了我父亲现在 80 多岁，母亲已经去世了。老一辈人根本跟不上变化。我觉得在科技行业，从业者经常为了改变而改变，却忽视了这样做的成本。Jeffrey Ullman：也不完全是为了改变而改变。比如说我就认真学过怎么用手机，现在已经完全离不开了。我孙子已经 25 岁了，他出去遛弯时喜欢借车

257、四处开。我习惯用车载导航系统，但他说：“我只想用谷歌地图。只要买个适配接口，就可以把你的手机连到车上。”我从来不知道这事，但年轻人们都很清楚，他们现在就是这么导航的。我之前去看望我的儿子和五岁的孙女，我当时带了一个平板电脑。他们平时不让她玩平板，但爷爷奶奶来的时候，孩子可以稍微玩一会（这应该是爷爷奶奶的特权）。她想下载一个应用来画画，但应用有广告。现在这些应用的生态系统都很奇怪，因为据我观察，所有应用的广告都是其他应用产品。这基本上就是个互相洗钱的生态系统。我不确定这背后的商业逻辑是什么样的，但目前的情况就是这样。她在应用之间跳来跳去。我说：“看，你得躲开这些广告，别去点。”15 分钟后，我发

258、现她找到了自己的方法，而且比我的办法更好。五岁的孩子很早就适应了，但我们老年人不行。主持人主持人：是的。这很有趣，让我想起了我儿子小时候的情景。我们也会给他一个设备让他玩。几分钟后，大家会说：“等等，你是怎么做到的？那是什么？”119 InfoQ 架构师2025年第一季 Jeffrey Ullman：没错。我觉得最重要的一点，是如何让老年人适应我们这个群体有自己的经验和习惯，但这些方式现在往往不好用了。所以说，开发者要怎样识别用户的身份，推测他们认为哪些设计和功能比较符合习惯，或者通过哪些机制来帮助他们搞清楚设备的用法。主持人主持人：我觉得这非常重要，而且这是一个很大的盲点。因为正如您在谈话开

259、始时所说，科技往往是年轻人的游戏。做决策和负责思考这些事情的人可能自己很少与老年人互动。即使是中年人，个体之间也有很大的不同。我 40 多岁了。我习惯了通过文本与大多数技术产品互动。我的孩子们对一切都使用语音和视频。这让我感到惊讶。比如想要解决一个问题，我会用文本输入、搜索相关的文章教程。但他们会搜索 YouTube 视频。作为一个行业，尤其是考虑到我们的社会正在加速老龄化，大家确实需要弄清楚如何纳入老年人的偏好、需求和差异。Jeffrey Ullman：真的很期待能看到这样的变化。主持人主持人：那您有没有看到比较好的成果？Jeffrey Ullman：是指相关研究还是实际应用？主持人主持人：

260、这两类都可以算，有没有让你印象深刻的探索和尝试？Jeffrey Ullman：我还没看到真正好的系统设计，比如说一种完全不同的设计思路。但我有种感觉，这事应该有戏。主持人：应该是有戏。我在想，现代机器学习和大模型技术能不能帮上点忙，因为主持人：应该是有戏。我在想，现代机器学习和大模型技术能不能帮上点忙，因为它能向特定群体提供更多基于意图的用户交互范式，还能够随时做出解释。依靠这些技它能向特定群体提供更多基于意图的用户交互范式，还能够随时做出解释。依靠这些技术，我们可以推理出用户的基本意图术，我们可以推理出用户的基本意图哪怕你的自然互动方式与我不同，与我孙女的哪怕你的自然互动方式与我不同，与我孙

261、女的自然互动方式不同，它也能弄清楚你在尝试做什么并帮到你。自然互动方式不同，它也能弄清楚你在尝试做什么并帮到你。Jeffrey Ullman：是的。我认为新的大模型技术应该有这种能力，毕竟它都能总结 YouTube 视频了。我之前提到的案例，大模型应该就能帮上忙。比如说我的手机上有一张地图，我想把它连接到汽车的屏幕上。我不知道该怎么操作，也许手册里有，但手套箱里那本手册 120 访谈文章|Interview 足足 500 页，笑死根本不可能去看。它一定在某个地方告诉用户如何做到这一点，但我甚至不知道有这回事。我儿子还告诉过我另一个功能，就是车子后备箱有一个按钮，可以在不按下车内的按钮的情况下从

262、车外打开后备箱。我想现在所有的车都有这个功能。但没人告诉过我有这回事。主持人主持人：是的。这是一个信息传播问题。只有明确知道要问这个问题，才可能找到答案。但我们如何提出问题呢？Jeffrey Ullman：完全正确。汽车应该说：“我注意到您一直在按车内的后备箱开启按钮。您知道您可以”我不确定大模型能不能解决这类问题。主持人主持人：但这事确实有搞头，而且让我想起了您在 Gradiance 所做的工作。即如果有基座模型，就会有很多正确答案。我们能否构建我们的技术，以注意到有一类答案一直被用户系统地忽略或者压根没听说过，并主动展示给用户。Jeffrey Ullman：总之，我觉得 HCI 人员应该试

263、试看。技术变革的前瞻与回顾 主持人：是的。我喜欢跟像您这样年长且对这个行业有很多了解的人交谈，因为您主持人：是的。我喜欢跟像您这样年长且对这个行业有很多了解的人交谈，因为您比那些只在这个行业呆了比那些只在这个行业呆了 10 或或 20 年的人有更广阔的视野。您还发现我们当前的科年的人有更广阔的视野。您还发现我们当前的科技生态系统和环境中存在哪些其他空缺？人们应该在哪些领域开展工作，但目前还没有技生态系统和环境中存在哪些其他空缺？人们应该在哪些领域开展工作，但目前还没有行动？行动？Jeffrey Ullman：这问题可不好回答。回顾那些巨大的变化，在有人拿出方案之前，没人意识到这种需求。我举一个

264、例子。日期非常重要。记得那是 1992 年 3 月左右，我被邀请到华盛顿特区讨论当时被称为信息高速公路的事情。那里有一群像我这样的学者，以及电信公司和其他行业的负责人。我们写了一份报告。有趣的是，根本没有人提到万维网。我想说的是，那里有一些关于 GOPHER（计算机信息查找系统）的讨论；另外还有个大问题，信息高速公路到底该通过电缆还是电话线传输。121 InfoQ 架构师2025年第一季 当时在瑞士，万维网已经出现。但这 300 位专家中，包括我在内，都没有意识到这会是个选项。记得几个月后问我的一位同事，“你为什么总在说:/？”甚至没有人知道需要像万维网这样的东西。手机、个人电脑的情况也差不多

265、。DEC 当时的负责人有句名言：“为什么有人想在办公桌上放一台电脑？”答案是，我真的没法预测下一件大事会是什么，甚至无法猜测。主持人主持人：当然，但您已经指出了一件现在缺失的东西，那就是关注老年人的 HCI 研究。Jeffrey Ullman：我认为这是一个不错的研究课题，但它倒不至于改变世界。我的意思是，如果非要让我猜，我肯定会选量子计算量子计算。我一直对量子计算持怀疑态度。它确实有一些应用，比如可以利用量子现象更好地模拟一些东西。顺便一提，量子通信似乎是真实可行的，就是所谓量子隐形传态。人们实际上可能能够做到这样的事情，把技术理论变成现实。但人们真正期待的，是这些量子计算机能拥有正确的量子

266、比特，能够运行 Shor 算法，从而破解 RSA 代码和椭圆曲线代码等。我的意思是，如果真是这样，那我们的思维方式肯定会发生转变。但到底可不可行，着实令人怀疑。毕竟像 D-Wave 那样的机器，显然使用的是无法运行 Shor 算法的量子比特，而且他们还在不断扩大规模。另外，量子计算可能并不遵循摩尔定律，只是我们还没意识到。我们能否每两年将可用的量子比特数量翻倍，特别是那些能够真正运行 Shor 算法的量子比特？我不知道到底行不行。可能可以，可能不行。如果再选一个，那可能是通用人工智能。主持人：是的。您提到了一些过去没有预料到的技术转变。如果我们回顾软件工程主持人：是的。您提到了一些过去没有预料

267、到的技术转变。如果我们回顾软件工程这个领域本身，而不是一般性技术，毕竟我们的大多数都是软件工程师嘛，那么多年以这个领域本身，而不是一般性技术，毕竟我们的大多数都是软件工程师嘛，那么多年以来，整个行业在思考软件的方式上最大的转变或者说突破是什么？来，整个行业在思考软件的方式上最大的转变或者说突破是什么？Jeffrey Ullman：我当初写的第一个程序用的是种机器语言，然后我升级到了 FAP。那是 IBM 790。然后我学会了 Fortran，大大提升了我的设计空间。我觉得现在大家都期待大模型能直接为自己编写代码。确实，我觉得这可能会让生活变得稍微轻松一些，让 122 访谈文章|Intervie

268、w 大家更有效率一些。而且从某些证据来看，这种情况正在实惠，就像当初从 FAP 升级到 Fortran 一样。我觉得这波变革甚至比当初更意义重大。正如我所说，并行性的引入肯定是个巨大的变化。只是这次的变革更微妙、更渐进，代表着从将软件视为算法、转变为将软件视为算法加数据。这肯定会逐渐改变我们对计这肯定会逐渐改变我们对计算机能做什么的思考方式。算机能做什么的思考方式。主持人：绝对的。有人可能会说，机主持人：绝对的。有人可能会说，机器学习方面的许多进步都被更多用于数据编程，器学习方面的许多进步都被更多用于数据编程，相比之下算法哪怕没有被彻底遗忘、也至少只能算“二等公民”。相比之下算法哪怕没有被彻底

269、遗忘、也至少只能算“二等公民”。Jeffrey Ullman：因为要先有数据，之后才能谈得到算法。比如我们之前谈到过提示词工程。最终，我觉得这个主题将落地成将意图转化为文本序列的算法，而文本序列在某种程度上甚至可能不再是文本的形式。比如变成视频或其他形式。主持人主持人：是的，未来会使用人类语言算法来引导大模型。Jeffrey Ullman：没错。从某种意义上说，这也是一种算法，或者是以其他工具的形式。到时候将由计算机帮助用户制定提示词。与大家习惯的老办法相比，未来可能会出现完全由计算机实现的算法。主持人主持人：绝对的。我认为 AI 领域的许多发展都是围绕这些工具生成提示词，借此帮助用户实现各种

270、功能。非常值得期待。感谢您抽出时间参加节目，非常感谢。Jeffrey Ullman：也感谢你的邀请。原文链接原文链接 https:/ 123 InfoQ 架构师2025年第一季“不是“不是 Cursor Cursor 不够强，是不够强，是 ClaClaude Code ude Code 太太猛了”！创始人详解猛了”！创始人详解 Claude Code Claude Code 如何改写如何改写编程方式编程方式 对于许多开发者来说，每月 20 美元的 Cursor 和 Copilot 已经是“无限量”好用的标配。然而，Anthropic 的 Claude Code 却是个异类。它在处理大型代码库方

271、面表现相当出色，但价格却直接翻了几倍。如果你只是周末写写代码，几美元的 API key 兴许就够了；可一旦用于日常开发，每月账单轻松就能突破 50、100 甚至 200 美元。有用户直言不讳地指出：“Claude Code 的能力比 Cursor 更强。我还在用 Cursor 的唯一原因，就是 Claude Code 实在太贵了。”价格似乎阻止这款产品爆发增长的主要因素，毕竟对比其他一票工具，Claude Code作者 Tina 124 访谈文章|Interview“真的很猛”。尽管 Cursor 的底层大模型同样来自 Anthropic，Steve Yegge 却评价道：“Claude Co

272、de 让 Cursor、Windsurf、Augment 这些工具看起来都像是过时产品。”我用了 Claude Code 几天，它在清理我那堆乱七八糟的旧代码里的遗留 bug 时简直毫不留情，像一台烧着钞票运转的碎木机像一台烧着钞票运转的碎木机。只用对话，它就能完成一些令人震惊的高难度任务。你甚至不需要手动选上下文。你只需要敞开心扉、打开钱包，你只需要敞开心扉、打开钱包，Claude Code 就会接管一切。就会接管一切。它还会每隔八秒提醒你一遍，问能不能运行一些只读命令那些你连朝鲜黑客都不介意他们在你机器上跑的命令。125 InfoQ 架构师2025年第一季 不过你会学会盯紧它，因为它真的很

273、猛。不过你会学会盯紧它，因为它真的很猛。只要银行的扣款授权还在，它就会一直往前推，直到 bug 修好上线，然后开始扫描用户日志，看看自己表现得怎么样。Claude Code 的使用体验说实话有点笨重，没有多模态支持，和其他工具配合也不太顺手。但这都不重要。它看起来也许有点老派，但用起来却让它看起来也许有点老派，但用起来却让 Cursor、Windsurf、Augment 那一票工具（是的，包括我们自己的产品，还有那一票工具（是的，包括我们自己的产品，还有 Copilot，说实话）都像是上个时代的产物。说实话）都像是上个时代的产物。我知道这还只是个实验品，我们也不知道它的极限在哪。但从我目前的体

274、验来看，它比自从代码助手诞生以来的任何东西，都更像是向未来迈出的一大步。所以，Anthropic 不仅拥有目前最适合真实开发场景的大模型，他们看起来也确他们看起来也确实比其他人更懂得怎么用好它实比其他人更懂得怎么用好它。结合他们一贯拥有最强模型、最顺手的聊天界面、CEO 最准的判断，还有现在这个 Claude Code我已经开始怀疑，Anthropic 可能真的是这个星球上唯一知道自己在干什么的公司了。最近，Claude Code 创始人 Boris Cherny 在一次采访中，难得地全面分享了他对这款产品的定位与设计理念。他讲述了开发这款编码助手的初衷、目标用户群、定价策略背后的考量，还分享

275、了一些他们的使用技巧。同时，他也谈到了作为当前在编程领域最强大模型企业之一，Anthropic 对 Claude Code 的未来设想与愿景：帮助开发者从“写代码的人”转变为“判断代码是否正确的人”。换句话说，未来的开发者不再是单纯敲键盘的人，而是技术决策的主导者。以下是访谈实录：Alex Albert：Boris，我们先从最基本的问题开始：，我们先从最基本的问题开始：Claude Code 是什么？是什么？它是它是怎么诞生的？怎么诞生的？Boris Cherny：Claude Code 是一种在终端里实现代理式编程（agentic coding）的方法。你不需要学习新的工具、不用更换 IDE

276、，也不必打开特定的网站或平台。它就是一种能够在你原本工作环境中直接使用的代理式编程方式。这个想法，其实源于 Anthropic 的工程师和研究人员日常的工作习惯因为每个 126 访谈文章|Interview 人使用的技术栈都五花八门。真的非常多样，根本没有统一标准。有些人用 Zed IDE，有些人用 VS Code，还有人坚持说：“谁也别想从我手里夺走 Vim，除非我死了。”所以我们想做一个对所有人都友好的工具，最终选择了终端作为入口。Alex Albert：我明白了，终端几乎是所有界面中最通用的，它灵活，而且早就融入大家的工作流了。Boris Cherny：完全正确。而且终端本身也非常简单，

277、正因为它够简单，我们的迭代速度就特别快。回头看，这是一个意外的优势，虽然最初并不是我们有意为之。Alex Albert：那如果我是一个新开发者，刚开始接触：那如果我是一个新开发者，刚开始接触 Claude Code，我怎么样才，我怎么样才能真正让这个产品运行起来呢？能真正让这个产品运行起来呢？Boris Cherny：只需要从 NPM 下载：npm install-g anthropic-ai/claude-code。安装完之后，只要你的系统里有 Node.js，就可以直接运行了。启动后它会一步步引导你完成剩下的配置流程。安装完后就可以直接和它对话，它就会开始写代码。它能在任何终端中工作，无论

278、是 iTerm2、Mac 自带终端，还是 SSH/TMUX 会话都没问题。很多人其实是在 IDE 内的终端里使用 Claude Code，例如 VS Code 的内置终端。在这种情况下，你不仅能看到文件被修改，还能在 IDE 里看到它以更美观、更清晰的方式呈现出来。我们也会利用 IDE 提供的更多信息，让 Claude 更智能。不过无论在哪个终端里，使用体验是一致的，你只需要在终端运行 Claude 就可以了。Alex Albert：Claude Code 是今年是今年 2 月发布的，到现在差不多三个月了。社区月发布的，到现在差不多三个月了。社区反馈怎么样？反馈怎么样？Boris Cherny

279、：太疯狂了，完全出乎我们的意料。其实在发布之前，我们还犹豫过要不要放出来。这个工具在我们内部用得非常多，极大地提升了工程师和研究人员的效率。我们甚至讨论过：“这是我们的秘密武器，我们真的要公开给外界用吗？”毕竟这就是 Anthropic 内部每天都在用的工具。但后来事实证明，把它发布出去是一个非常正确的决定。它确实能提升生产力，而且大家真的很喜欢。起初只有我们核心团队的少数几个人在用，后来我们开放给所有 Anthropic 员工使用。当时我们看到一个 DAU（每日活跃用户）图，短短三天内几乎是 127 InfoQ 架构师2025年第一季 垂直上涨状态。我们当时就觉得：“这太疯狂了，肯定是个爆款

280、。”之后我们挑了一些外部用户做试点，想确认是不是我们自己太乐观了，结果收到的反馈也都是非常积极的，那时候就很清楚了它确实有价值。所以它首先在 Anthropic 内部引起轰动，所有的工程师，所有研究人员都在使用它，这才让我们决定把它发布出去。而且我们整个开发过程也特别有意思：Claude Code 本身是用 Claude Code 写出来的。几乎所有的代码都经过了多轮用 Claude Code 编写和重构。我们非常相信内部测试，因为这真的很重要。你能明显感觉到哪些产品是开发团队自己每天在用的，那些产品的细节打磨都非常到位。我们希望 Claude Code 也成为那样的产品你一用上它，就能感受到

281、开发者的用心。Alex Albert：你觉得目前：你觉得目前 Claude Code 最理想的用户是谁？谁在用它？是怎样的最理想的用户是谁？谁在用它？是怎样的开发者？开发者？Boris Cherny：我认为最重要的事情是Claude Code 其实是相当昂贵的。如果你只是周末写写代码玩玩，那可以尝试下，比如你拿个 API key 充个五块钱试试。但如果想拿它做更严肃的工作，每月大概需要花五十、一百，甚至两百美元。取决于用途，一般而言，每月大概会花五十美元左右。现在其实有很多企业在用 Claude Code。对于大公司来说，它非常合适。特别是在处理大型代码库时，它表现非常好。不需要额外做索引，也

282、不需要复杂配置，基本上开箱即用，几乎适用于任何语言的大型代码库。至于 Claude Code 跟 Claude Max 的整合，是因为我们之前发现，用 API key 支付的用户常常会担心用量问题，这反而影响了他们使用的积极性。为了改善这个问题，我们把 Claude Code 纳入了 Claude Max 订阅计划中。你只需要订阅 Claude Max，就能无限使用 Claude Code，每月是 100 美元或 200 美元不等。用户可以根据需求选择不同的价格和使用上限，但实际上很少有人能用到限制，基本可以看作是“无限量”的 Claude Code。128 访谈文章|Interview Al

283、ex Albert：那我作为一个开发者，机器上有自己的代码库，我打开终端，输入：那我作为一个开发者，机器上有自己的代码库，我打开终端，输入 claude 并回车，接下来会发生什么？并回车，接下来会发生什么？Boris Cherny：Claude 会调用各种工具，分步骤执行任务。如果你之前用过那种在 IDE 里的编程助手，助手所做的就是完成一行或几行代码。我们这跟那个完全不一样。Claude Code 是非常“agentic”的它会理解你的请求，然后使用它可以用的一切工具，比如 Dash、file editing 等等，去探索代码库、读取文件，获取上下文，然后再对文件进行编辑或做出你希望的更改。

284、Alex Albert：听起来像是对过去：听起来像是对过去 20 到到 30 年编程范式的一种全新变革。年编程范式的一种全新变革。Boris Cherny：对我来说，这种变化是有很深的历史背景的。我自己写代码已经很多年了，但其实，我外祖父在上世纪 40 年代就是苏联最早的一批程序员之一。那时候还没有软件编程，他是用打孔卡片写程序的。在美国，当时 IBM 提供了一套类似 IDE 的系统，他每天就用这套系统编程，把纸质卡片带回家。我妈妈小时候会拿这些卡片当画纸，用蜡笔在上面涂涂画画，那是她童年的一部分。从那时起，编程不断演进：先是打孔卡，然后是汇编语言，接着出现了 COBOL、FORTRAN 这些

285、第一代高级语言。80 年代是 Java 和 Haskell 这类静态类型语言的时代，到了 90 年代，我们又有了 JavaScript 和 Python解释型语言，但又具备一定的安全性。编程语言的演进和编程体验的演进一直是同步进行的。比如 Java 出现的同时，我们也看到了 Eclipse 这样的 IDE，第一次出现了代码补全功能。你打一个字符，它就弹出建议列表问你“是不是想写这个？”对开发者来说，这是一次革命性的体验，因为你不再需要记住所有细节。所以在我看来，今天 Claude Code 代表的是又一次演进的开始。语言本身已经相对稳定了，现代语言基本上可以归类为几个大的家族，而且彼此相似。但

286、现在的核心变化，是编程体验的变革：你不再需要处理打孔卡，不用写汇编，甚至不一定非得写代码，而是通过 prompt 与模型对话，然后模型计算出编码部分。这对 129 InfoQ 架构师2025年第一季 我来说，是一件非常令人兴奋的事情。Alex Albert：我们基本上是从打孔卡片时代进入了提示词时代。我们稍后展开聊，：我们基本上是从打孔卡片时代进入了提示词时代。我们稍后展开聊，但在此之前，我想先聊聊模型方面的内容。在不久前，但在此之前，我想先聊聊模型方面的内容。在不久前，Claude Code 主要是由主要是由 Claude 3.7 Sonnet 驱动的。那么现在驱动的。那么现在 Claude

287、 4 系列模型在底层驱动系列模型在底层驱动 Claude Code，这带来了哪些新变化？你认为接下来会走向哪里？这带来了哪些新变化？你认为接下来会走向哪里？Boris Cherny：大概是在模型发布前的几个月吧，我们内部开始尝试这些新模型。我还记得第一次用时真的被它的能力震惊到了，我认为这可以解锁许多新的使用场景。尤其是在终端里同步使用 Claude Code 时，一个很大的变化是：Claude 在理解和保持指令方面变得更强了。不管你是通过提示词还是通过 Claude.md 给它下指令，它都能很好地执行并坚持你的要求。这点变化非常大，因为 Claude 3.7 虽然是个很强的编程模型，但是，它

288、很难驾驭。比如你让它写测试，它可能会直接 mock 掉所有测试代码，然后你还得对它说，“不，我不是这个意思。”通常你得说上一两次，它才会明白，但因为它太强了，所以你愿意容忍这些小问题。而现在，Claude 4 系列的模型基本上第一次就能准确地理解你的意图并按要求完成任务。Opus 更是比 Sonnet 再上一个台阶，它不仅能很好地理解我的意图，还能一次性完成很多以前模型做不到的事情。比如说，我已经几个月没有亲自写过单元测试了，因为 Opus 会直接帮我写好测试，而且几乎每次都是一次性写对。在终端环境下这非常有用，因为你可以更“放手”地使用它。但我觉得最酷的使用方式是放在 GitHub Acti

289、ons 或其他环境里。你只需要给它一个任务，它就可以自动执行，等它带着正确结果回来时，那种“一次就成功”的体验真的很棒。Alex Albert：所以现在在：所以现在在 GitHub Actions 里，我们可以直接在里，我们可以直接在 GitHub 中中 Claude，让它在后台处理任务，最后带着结果和新的，让它在后台处理任务，最后带着结果和新的 PR 回来？回来？Boris Cherny：对，没错。你在终端像平常一样打开 Claude，运行 claude 命令，然后执行/install GitHub Action，它会一步步引导你安装这个功能。只有几个步骤，但基本 130 访谈文章|Inte

290、rview 都是自动的，只需要点两下按钮，Claude 的 GitHub 应用就能安装到你的 repo 里。整体体验真的挺酷的。在任何 issue 里，你可以直接 Claude。我每天都在 PR 里用它。比如说，同事发了一个 pull request，我不会再说“嘿，你能不能修一下这个问题”，我会直接说“Claude，修一下这个问题”，然后它就会自动修好。同样，我也不会再说“你能不能写一下测试”。以前说这个我还觉得有点不好意思，现在我只需要说“Claude，写个测试”，它就会自动完成。这些事情现在根本不再是问题了。Alex Albert：这基本就是一种全新的编程方式你可以随时调用一个随时可用的

291、程序员来帮你解决问题，而且它不是在你的本地电脑上运行，而是在后台直接完成所有操作。Boris Cherny：对，我觉得这是开始以“协作程序员”的方式来与模型互动。以前你是 mention 一个同事，现在你可以直接 mention Claude。Alex Albert：那在这种模式下，软件工程会发生什么变化？当我们开始管理这些在：那在这种模式下，软件工程会发生什么变化？当我们开始管理这些在后台运行的后台运行的 Claude Code 实例时，会发生哪些转变？实例时，会发生哪些转变？Boris Cherny：我觉得这确实需要一些思维上的转变。有些人非常享受控制代码的感觉，如果你习惯于手写代码，那么

292、你就需要适应整个行业正在转向的方式你不再是亲自写代码的人，而是协调 AI 代理来帮你写代码。你的工作重点也将从“手写代码”转向“审查代码”。我认为对于程序员来说，这个变化非常令人兴奋，因为你可以在更短的时间里完成更多的事情。当然，还有一些我必须深入研究并手写代码的情况，但说实话，我已经开始害怕（dread）了因为 Claude 在这方面非常擅长。我认为，随着模型能力的进一步提升，那些你不得不亲自写代码的场景，比如特别复杂的数据结构，或者多个系统组件之间的高复杂交互，又或者是你实在描述不清楚的需求，这些情况会越来越少。未来，越来越多的编程工作将会是关于“如何协调这些 AI 代理去完成开发任务”。

293、Alex Albert：我想更深入聊聊你们的工作流，也就是你们如何使用这套工具组合：我想更深入聊聊你们的工作流，也就是你们如何使用这套工具组合：131 InfoQ 架构师2025年第一季 从从 IDE 集成、集成、Claude 在终端中的使用，到它在在终端中的使用，到它在 GitHub 中做的这些后台操作。你现中做的这些后台操作。你现在是怎么把它们结合起来使用的？在是怎么把它们结合起来使用的？Boris Cherny：我现在的工作基本可以分为两类。一类是很简单的任务，比如写一些测试，修复一个小 bug，这类任务我通常会直接在 GitHub Issue 里让 Claude 来完成。还有一种情况是

294、我通常会并行跑多个 Claude。我本地有好几个代码库的副本，所以在某个终端标签页里，我会让 Claude 做一件事，按下 Shift+Enter 进入自动接受模式，然后过几分钟回来看看，Claude 通常会完成并给我发一个终端通知。另一类工作就比较复杂了，需要我更深度地参与，我认为这仍然是工程的主流。大多数工程任务其实都不是“一击即中”，它们依然很难。这种情况下我会在 IDE 的终端里运行 Claude，让它做一部分工作，然后它可能会卡住，或者代码不太完美。那我就会在 IDE 里手动改改，把最后那一段路完善掉。Alex Albert：感觉和 Claude 的交互是基于任务难度的，越简单就越自

295、动化，越复杂你就越得亲自参与。Boris Cherny：是的，一开始用这类工具的时候会有个学习过程。有些人刚开始用，就试图让 Claude 一下子搞定太复杂的事情，结果它卡壳了，输出也不理想，你自己也不开心。这是大家必须经历的一个学习阶段，得慢慢形成一个“内在校准”，知道 Claude 能做什么、哪些是它能一发搞定的、哪些需要你引导两三次才能完成的。而且每换一个新模型，这个校准都得重新来一遍。因为能力是在不断提升的，每次模型一更新，Claude 就能一次性做对更多的事。也就是说你可以逐步把更复杂的任务交给它。Alex Albert：我也注意到了，哪怕是在非代码领域，这些模型进化得也非常快。如果

296、你六个月前用某个模型做不了某个任务，你现在还按那个标准判断就不对了。你得每次都重新设定自己的直觉。Boris Cherny：对，完全正确。Alex Albert：我挺好奇的，还有没有一些实用技巧或窍门？比如你们内部或者开发：我挺好奇的，还有没有一些实用技巧或窍门？比如你们内部或者开发者社区里，有哪些有趣的用法是你见过的？者社区里，有哪些有趣的用法是你见过的？132 访谈文章|Interview Boris Cherny：我觉得目前见过最有价值的一个技巧是：无论是 Anthropic 内部还是外部的重度用户，现在很多人都会先让 Claude 做“规划”，再开始写代码。新用户常见的误区是直接让 C

297、laude 实现一个很复杂的功能，结果它写出来的内容和你预期差距很大。一个更有效的方法是先让它出一个方案。我会明确告诉 Claude：“这是我要解决的问题，在写代码前，请先给我列出几种思路，别着急动手。”然后它会给我列出几个方案，比如方案一、二、三。我可以挑出一和三，说：“我们可以结合一下，现在你可以开始写了。”Claude 在这方面的配合度一般都很高。如果 Claude 已经有一些上下文信息，你可以让它进入“扩展思考”模式（extended thinking），这个时候它表现会特别好。但如果它完全没有上下文，一开始就让它冥想，它其实啥也想不出来就像人一样，你不读代码，不看上下文，只是坐着想，

298、是没用的。我的做法通常是：先让 Claude 把一些相关文件读一遍，然后暂停一下，让它开始头脑风暴，列思路，再让它开始写代码。Alex Albert：所以你是采用那种“交替式”的工作流：调用工具思考再调用工具再思考，这种来回往复的方式。Boris Cherny：对，正是这种方式。我们内部做模型评测的时候也是这么设计的：先提供上下文，然后让模型进行思考，再让它用工具来编辑或者使用 Bash 命令，效果普遍会更好。从使用者角度来看，体验也的确是这样的。Alex Albert：聊聊：聊聊 Claude.md 文件吧，这东西看起来很强大。文件吧，这东西看起来很强大。Boris Cherny：对，我们用

299、 Claude.md 做很多事。它是 Claude 的“记忆”，可以让 Claude 持续记住你对它的指令。这些指令可以在你的团队中共享，也可以在你的所有项目中共享。最简单的做法就是在你的代码库根目录下新建一个 Claude.md 文件，一个普通的 markdown 文件（CLAUDE 全大写，md 小写），Claude 启动时会自动读取它。你可以写一些通用指令，比如常用的 Bash 命令，重要的架构决策变更文件，MCP 服务器，等等，全都写进去。133 InfoQ 架构师2025年第一季 这种是团队级的 Claude.md，这种是你写好之后跟团队其他成员共享的，这样大家不用每个人都单独写一份

300、。第二种是你自己的专属版本，叫 Claude.local.md，放在同样的位置，但不提交到代码库（可以被.gitignore 忽略），只对你个人生效。第三种是全局的 Claude.md，放在你的 home 目录下的.Claude/文件夹里，大多数人其实不怎么用这个，但如果你希望与 Claude 分享指令，这是个办法。最后，还有一种是嵌套型的 Claude.md，可以放在代码库的任何子目录下，Claude 会在它认为相关时自动加载。Alex Albert：所以这些 Claude.md 文件，其实可以定义很多内容，比如你的编码风格、Claude 与你交互的方式、它应该知道你的哪些偏好等等，对吧？B

301、oris Cherny：对，完全可以。有时候我跟 Claude 对话的时候，它表现特别好或者特别差，我就会按下“#”（井号），这相当于进入“记忆模式”。我会告诉它：“你应该记住这一点。”比如说，“我每次写代码都要运行 linter”，我会明确告诉它，它就会自动把这条写进合适的 Claude.md 文件里。Alex Albert：Claude Code 接下来有什么计划？接下来有什么计划？Boris Cherny：我们现在考虑的方向有两个。一个是让 Claude 更好地与各种工具协同工作。目前它已经可以配合所有终端使用，现在也能支持很多 IDE，还能与多个 CI 系统配合。我们在探索如何进一步拓

302、展，让 Claude 能够“原生地”使用你常用的所有工具，理解这些工具的使用方法，并能无缝集成。另一个方向是让 Claude 更擅长处理那些你可能不想专门开个终端的小任务。比如，我能不能在聊天工具里 mention Claude，让它自动修复一个问题？就像现在你在 GitHub 上那样操作一样。我们正在尝试多种方式，希望能找到真正“好用”的方案，然后再开放给用户使用。134 访谈文章|Interview 参考链接参考链接 https:/ https:/ 135 InfoQ 架构师2025年第一季 微软重磅开源微软重磅开源 CopilotCopilot！64 64 岁岁 VS Code VS C

303、ode 创始创始人亲口承认：眼红人亲口承认：眼红 CursorCursor，但真正价值在后，但真正价值在后端，它“抄”不过去！端，它“抄”不过去！北京时间 5 月 20 日，在 Build 2025 开发者大会上，微软正式开源了 GitHub Co-pilot Extension for VS Code 项目，并采用 MIT 许可证。全球开发者将可免费访问其完整源码，并参与功能优化。根据微软 VSCode 团队的声明，微软计划先开源 GitHub Copilot Chat 扩展的代码库，随后会将该扩展的相关组件重构整合至 VS Code 核心代码中。微软为此制定了一个为期 4 周的迭代计划，新

304、的 VSCode 将于 6 月初发布。作者 Tina、褚杏娟 136 访谈文章|Interview GitHub Copilot 自 2021 年起就作为 VS Code 的插件存在，后者是其最早、最主要的运行平台之一。对于今天的开源公告，Eric 强调，Copilot 的服务端不会开源的服务端不会开源。但 VS Code 的所有客户端逻辑，包括模型返回的 diff 渲染、inline chat、Agent UI 等都是开源的。在官方宣布开源的同时，VS Code 创建者 Erich Gamma 和 Copilot 负责人 Kai Maetzel 接受了 Syntax 的独家专访。两人都是 V

305、S Code 项目的早期成员，多年来一直在推动这个项目的发展。其中，Eric 在 15 年前加入微软时启动了 VS Code 项目并长期领导该项目，最近几年开始退居一线，变成了一个独立贡献者。如今，Kai 负责主导整个 VS Code 项目，他大约在 10 年前加入了这个项目。两人在这档节目中，围绕 Copilot 开源进行了一系列独家分享。为何开源：真正的“护城河”不在客户端 VS Code 此前架构是“开源核心+闭源扩展”的模式。VS Code 本身是开源的，里面有一些 AI 支持功能是开源的，但 Copilot 本身是一个闭源扩展。这背后是有原因的，也有一个发展过程。最初 Copilot

306、 是从代码补全功能开始的。当时 VS Code 和 GitHub Next 的团队有非常紧密的合作，后者主要在探索这类新交互方式的 UI。于是 VS Code 引入了“Ghost Text”补全功能，这在当时是全新体验在此之前，编辑器里只有提示窗口。早期的 Copilot 主要依赖一个定制化、精调过的 GPT-3.5 模型，很多“智能”其实都是在扩展中完成的，比如 prompt 构造等。总体上，Copilot 是一个巨大成功，用户反馈是“太神奇了”。当然也会有用户指出它偶尔会出错、建议不准确等问题。之后，随着 ChatGPT 和 GPT-4 的发布，每个人几乎都开始重新思考“AI 还能做什么”

307、。微软团队意识到，AI 的 UI 部分必须深入嵌入用户的工作流中。而问题是，当时 AI 要真正有用，代价是非常高的：prompt 需要大量处理，数据需要预处理，结果还得后处理，模型回复的格式也常常不理想。得写很多代码去构建 prompt、控制上下文、处理各种用例的问题。137 InfoQ 架构师2025年第一季“从业务角度看，当时也没人知道该怎么用这玩意赚钱。运行成本极高，我们又不想轻易把东西免费送出去，市场趋势也不明朗。于是我们采取了开源核心+闭源功能的策略，UI 和部分功能进入核心，我们必须通过例如 API 来启动一些元素，所以我们创建了更多 API，但核心内容还是在 Copilot 中。

308、”Kai 说道。而如今，整个 AI 工具链已经变得成熟了很多，比如 OpenAI 的 cookbook、An-thropic 的教程、Google 那份 68 页的 prompt 指南等。像 CodeX 这样的开源项目也展示了如何构建完整的 prompt 流程。过去两年，情况发生了很大的变化。prompt 工程本身已经不再神秘，也更易掌握了。另外一个重要因素是，现在微软对商业模式的理解也更清晰了。Kai 表示，真正的真正的“护城河”其实在服务端，而客户端更多是交互逻辑，这部分其实很适合开源“护城河”其实在服务端，而客户端更多是交互逻辑，这部分其实很适合开源。因此，微软认为现在是时候将 AI 功

309、能也开源，让大家能够：克隆 VS Code；自行构建并运行；使用开源的 Code OSS 版本体验完整流程；调试所有从输入到服务端响应的过程；优化逻辑、提交问题、贡献代码。换句话说，微软希望复制 VS Code 本身开源成功的路径。在一个市场逐渐成熟的时候，开源能帮助开发者更深入地参与讨论、提出想法，而不只是等着项目发起团队实现。微软认为，这一时机现在已经成熟。原生 AI 编辑器是什么样的“像“像 Cursor 这样的新对手让我有点眼红。”如今已经这样的新对手让我有点眼红。”如今已经 64 岁的岁的 VS Code 创始人创始人 Eric 在采访中不在采访中不止一次提到。止一次提到。Eric

310、认为，一个原生 AI 编辑器不应该把 AI 功能“挂载”在 VS Code 上，而应该是核心的一部分。用户编写开源软件时，它就在那里，不需要安装任何东西。因此，团队现在要做的就是把 AI 彻底变成核心的一部分，而不是额外安装的插件。138 访谈文章|Interview 现在所有关于 prompt 构造、模型交互的逻辑都还藏在 Copilot 扩展中，Eric 希望将这些开源后能吸引更多开发者的关注和贡献。这样也更安全，对开发者来说也更透明。“我喜欢这个变化的另一个原因是，我们之前在开源和闭源之间来回切换其实挺痛苦的。”Eric 补充道，“项目属性不同，我们的说话方式也不同。开源社区友好热情，而

311、闭源产品的用户则更像客户，要求多、没啥耐心。能把整个工作流程都统一为开源，对我们开发团队本身来说也是一种解压。”Eric 还提到，将 AI 部分开源的一个原因是从一些组织那里听到的反馈他们真的不喜欢闭源的 IDE。将其他部分也开源就满足了这些企业的需求，他们可以选择闭源，也可以选择开源。值得注意的是，Copilot 是有免费选项的，开发者可以直接注册并免费使用，但会受到调用高级模型的请求次数等限制。Copilot 中有一个没有调用限制的基础模型。如果用户有自己的 API Key，也可以用“Bring Your Own Key”（BYOK）方式接入，直接使用指定的模型服务，而非通过 GitHub

312、 后台服务，费用开发者自己承担。如果用户付费使用更高级的 Copilot 功能，那就和开源没有直接关系了。“总得有总得有人为模型的计算资源买单，这和是否开源是两码事人为模型的计算资源买单，这和是否开源是两码事。”Kai 说道。所谓开源，是用户可以看到所有客户端上发生的内容，也能看到团队发送到服务器的内容。而客户最终所支付的费用，基本上就是后端运行大模型所产生的计算费用。对于企业用户来说，还有一些附加服务，比如免责保障（indemnification）之类。Copilot 开源后的一些变化 开源后，上下文是公开的 Copilot 的一个重要组成部分就是确定要将哪些信息发送给模型。如果 Copil

313、ot 开源，我们就能清楚地看到究竟哪些内容被发送给了模型，以及这些数据是如何被处理的，进而能够进行改进。最开始时候，模型还不支持像样的工具调用（tool calling），所以 Copilot 团队几乎必须把所有需要的信息预先打包好，一起发给模型。但那时也会遇到“干草堆里找针”139 InfoQ 架构师2025年第一季 的问题发得太多反而会让模型困惑。现在，Copilot 对于生成补全的请求，还是会尽可能地将上下文预先打包，然后让模型去补全。但这里面还是有很多思考，比如该发哪些东西。比如说，打开的标签页会被用来计算额外的上下文，如果语言服务器支持的话，我们会以某种精简形式把类型信息等也一并发过

314、去。但也有些场景并不再那么依赖这些了，比如 Agentic 流程。在 Agentic 流程中，Copilot 用的是内部称之为“面包屑提示”（breadcrumb prompts）的方式。比如现在问题面板里有个问题，终端里也有输出，那就只是告诉模型这些信息存在于哪里，并且给模型提供检索这些信息的工具，然后模型自己判断它是否需要这些信息。这种方式更简单。当然有时候也需要用合适的提示方式来引导，比如告诉模型在思考时该优先考虑哪些方面。但总体来说，引入工具调用之后，整个上下文处理过程简单了许多。生成提示词方面，Copilot 现在用类似 tsx 的结构来描述提示语，而不是简单的字符串拼接。这种方式带

315、来了灵活性，比如可以给树结构中的节点分配不同优先级，按需要添加或减少内容，这些都能根据上下文窗口灵活调整。但提示词本身也可以告诉模型优先使用哪些工具。比如可以写明：先检查问题面板里是否有错误信息，不要一开始就看终端输出之类的。用户可以引导模型按照希望的顺序去处理上下文信息。不过，Copilot 仍然面临上下文窗口的限制。有的限制是模型本身的技术约束，有的则是希望通过控制窗口大小来提高吞吐量，这些都需要权衡。Copilot 团队的一个明确经验法则是：用尽可能短的提示语得到尽可能好的结果。所以如果你把整个上下文窗口都填满了，然后得到了一个不错的结果，问题就变成了：能不能删减一些内容，依然得到同样好

316、的结果？这也正是 Copilot 整套提示语渲染逻辑的关键：要知道在什么时间点可以删掉哪些内容。比如“历史记录”这一部分，如果不希望把所有历史记录都灌进去把上下文窗口填满，那就得有一个自然的截断方式，比如判断对话是从什么时候开始转到与之前无关的新话题的。140 访谈文章|Interview 实际上，提示词本身并没有太强的语言特异性。在早期阶段，Copilot 确实有一种被称之为“cookbooks”的方式，比如不同的 linter（代码检查器）会抛出不同的错误和错误信息，然后团队就会针对这些情况创建一些“cookbooks”。像是出现了类似在 Python 文件中使用了 PyLint 的错误，

317、“cookbooks”会给出一些修复方式、错误的含义，以及如何可以解决等。这种做法是强语言相关的，有时甚至需要提供语法方面的提示。但随着系统的成熟，这些特定语言的“cookbooks”变得不那么必要了。当然，在处理补全上下文（completions context）的时候，仍需考虑语言的特性。例如，支持某个语言支持类型，比如接口（interfaces），那就需要编写一些逻辑代码去找出你想包含的合适接口。另一个有点语义性质但并不属于语言特异性的部分，是关于工作区知识的处理方式。整个流程中，如何找出最相关的代码片段添加到提示词，这背后有一个非常复杂的索引基础设施。这个系统是基于一个类似树结构的数据

318、库，具有范围（ranges）等的语法结构知识，然后再去计算嵌入（embeddings）。但这一套逻辑是在语法级别上完成的，而不是语言特定的。Copilot 服务端有哪些“秘密武器”？Copilot 在某些场景下用的是微调后的模型，而且不只用一个模型，而是好几个。“我们会越来越多地看到这种趋势：虽然一个大模型很聪明，能做很多事，但它既昂贵又慢。你希望给用户提供的是一个快速体验，给自己减少基础设施负担这就意味着你需要不断蒸馏，一步步缩小模型，直到针对每个特定任务都有一个足够小但效果很好的模型。”Kai 说道。虽然用户能用 BYOK，但 GitHub Copilot 服务本身其实还附加了一些其他能力

319、。比如，GitHub 团队会对所有开源仓库做索引（也可以选择让你的私有仓库被索引）。这个“索引”的实际含义是把代码分块（chunking），然后对每个代码块计算 embedding。查找相关代码时，比如用户输入了某个查询，Copilot 就会对这个查询计算 141 InfoQ 架构师2025年第一季 embedding，然后去代码库中查找距离这个 embedding 最近的代码块。这就是 GitHub 提供的服务之一。这是否算是“秘密武器”呢？或许可以这么说，但 Kai 拒绝了用“秘密武器”这个词。在他看来，这更准确地说是规模化能力，要支撑 GitHub 仓库的数量级，需要很强的基础设施。现在

320、的新模型还在编辑文件方面表现特别好。比如 set 命令的替换功能，用户可以搜索某个字符串并替换成其他内容。新出的 OpenAI GPT-4.1 之类的模型支持 ap-ply_patch 功能，能以 diff 的形式返回补丁，非常精准。但也有很多场景下，模型并不擅长直接做 diff 操作。这时团队会用另一种方法：告诉模型，“请给我一个这个文件的重写版本”，保持没改的地方一致，明确哪些地方是旧代码，然后再把原文件和新文件一起送给模型，让它拼出一个合理的合并版本。这就是一个自定义模型的例子，Copilot 团队每天都要用很多次。要支持高频调用，要支持高频调用，就得足够便宜。而要便宜，就需要定制化的模

321、型，即能很好完成任务的最小模型。就得足够便宜。而要便宜，就需要定制化的模型，即能很好完成任务的最小模型。“再如代码补全的模型肯定是定制的，还有类似下一步编辑建议功能（比如你在某处改了代码，它提示你后面也要同步修改），这个功能也需要定制模型。当然用户也可以什么都不做，直接用大模型处理所有任务，但那会非常昂贵且缓慢。”Kai 说道。对 Cursor 和 Windsurf 意味着什么？VS Code 一经发布就“引燃”了整个圈子。当时虽然已经有 Atom 和 Sublime 等编辑器，但社区里很大一部分人都迅速转向了 VS Code。“当时我们注意到出现了一批新型开发者，我们常称之为纯粹的 Web

322、开发者。我们希望为他们提供工具，让我们对他们也具有吸引力。虽然我们当时已有 Visual Stu-dio 这样一个功能强大的集成开发工具，但我们想打破这种一体化的传统模式，吸引那些更喜欢命令行、喜欢自定义工具、使用多种语言的 Web 开发者。就是在这样的初衷下，我们创建了 VS Code。”Eric 追忆了 15 年前建立 VS Code 项目的时候。Eric 将 VS Code 归为“十年磨一剑”后的一夜成名。“在发布前，我们其实已经按 142 访谈文章|Interview 照每月迭代的节奏持续开发了五年。真正的增长是逐步发生的，不是一蹴而就的。”VS Code 一直是渐进式增长的，现在有大

323、约 4000 万用户。从 Github 上看，VS Code 目前已经有了 3.2 万个分叉项目。业内基本认为，Cursor 也属于 VS Code 的众多分叉项目中的一个，其保留了 VS Code 的核心架构、界面布局和扩展生态。这也是与 Cursor 初期最为人道的一点。别人是否可以拿 VS Code 所有的东西，如整个系统，然后重新贴一个标签说“这是我们的”，并以他们的名义推广？Kai 的答案是“当然可以”。但他会对这些项目不回馈上游社区、不回馈整个开发者生态的做法表示质疑。“现在很多人做 VS Code 的 Fork（分支版本），但我觉得他们中的一些已经偏离了 VS Code 原本的设

324、计精神，用 VS Code 的精神误导人们。”作为项目创建者，Eric 直白地说出了自己的担忧，“比如在某些 Fork 中，随处都能看到一个蓝色的 AI 按钮，承诺 AI 无处不在。当然，你可以这样做，但我们一直强调的是平台思维，要为更多人服务，而不是垄断一切。”Eric 还提到了一致性的问题。“我们非常重视 VS Code 中的一致性，但在很多 Fork 中，这一点被忽略了。比如，Cursor（一个 VS Code 的衍生项目）已经改变了 UI，把活动栏放到了顶部，这个设计挺好的，我们也引入了类似功能。但我很难理解，为什么他们没有回馈这个功能到主项目中？”“更令人沮丧的是，我们注意到他们实现

325、这个功能时，他们给用户的实现并不完整。比如我们在 Git 视图中还会显示有多少文件发生了变更的徽章（badge），他们就没有实现。这种对一致性的忽视让我挺受伤的。”Eric 表示，“我们做每一个功能都非常认真地考虑一致性，而 Fork 项目有时会为了短期目的而忽略平台整体性。我们关注的是长期发展，而不是某一波 AI 热潮。”Kai 认为，竞争将越来越多地集中在围绕这些东西所提供的服务上，即真正运行在竞争将越来越多地集中在围绕这些东西所提供的服务上，即真正运行在后端的那些部分后端的那些部分。在他看来，和很多情况一样，真正重要的地方是在服务器端真正重要的地方是在服务器端如何构建服务、如何扩展、如何

326、真正为客户提供持久价值。而人们希望能够信任客户端上的东西，特别是 143 InfoQ 架构师2025年第一季 对于大型企业用户来说，他们希望能够看到、审计客户端到底做了什么，并确保一切合规、可靠。“我无法准确说这对我无法准确说这对 Cursor 的业务意味着什么的业务意味着什么那是他们的事情，不是我的。那是他们的事情，不是我的。但我可以从刚才提到的角度去思考：竞争的核心已经转移到服务器端了。客户端的设计也影响了我们的决策比如我之前提到的 prompt 设计、上下文处理等，这些已经越来越成熟了。”Kai 说道。“对于我们这些开源项目维护者来说，看到别人 fork，当然不是令人愉快的经历。”Eri

327、c 则坦诚道。根据根据 Eric 的说法，那些的说法，那些 fork 项目之所以要项目之所以要 fork VS Code，是因为，是因为 VS Code 的的 API 不够强大，无法支撑他们想要的不够强大，无法支撑他们想要的 AI 创新。创新。“这确实是事实我们现在的 API 不允许开发者用它做很复杂的 UI，这是有意为之，因为我们很注重稳定性和性能因为我们很注重稳定性和性能。比如，你不能用我们的扩展 API 来构建一个像 Copilot 那样的联合补全（co-completion）UI，那根本不支持。”“但我也要强调一点：虽然这些 API 不支持深度创新，但社区还是在现有 API 基础上做出

328、了很多创新。比如很多不错的 AI 编辑器扩展。但确实，想做更底层的创新会面临挑战。当然这也是我一直嫉妒的原因。”Eric 说道。Eric 补充称，“另一点，那些 fork 直接内置了 AI。fork 允许他们做我们没有做的事情。而我们团队因为各种结构原因，一直要把 AI 功能封装在一个闭源扩展里。现在不用这么做了，对我和开发团队来说是种解脱。我们终于可以采用真正我们终于可以采用真正AI 优先的优先的思维方式去构建产品思维方式去构建产品，这意味着别的扩展也可以”“毕竟，真正的价值最终还是在后端真正的价值最终还是在后端。”Eric 说道。而 UI 交互形式上，Eric 指出，客户端的某些 UI 交

329、互形式已经开始趋同了，比如 inline chat、如何展示 diff（差异）、如何流式展示内容等已经有了一定的共识和统一趋势。144 访谈文章|Interview 如何运营开源社区 根据 Eric 的说法，AI 部分开源后，VS Code 的整个思路没有改变：在 VS Code 里用户可以通过写一个扩展来参与，通过扩展 API 来贡献功能；也可以通过提 Pull Re-quest 的方式参与，比如发现某个 AI prompt 有问题想改进它。新的变化是：第一，开源社区有了源码访问权限，如果扩展有问题，可以直接去看源码更深入地理解；第二，社区可以通过 Pull Request 的方式参与，也就

330、是说“写一个扩展”其实就是在做贡献。宣布开源后，整个团队还有很多工作要做。这和当年开源 VS Code 的模式不一样。那时候是一个完全闭源的项目，我们准备好后直接切换为开源。而这次是从已经开源的 core 出发，要继续“调优”和“重构”，以开放 AI 的相关能力。“这意味着社区会看到我们对这意味着社区会看到我们对 core 的一些改动的一些改动，”Eric 说道。“大家也会有疑问：发生了什么？大家真的会盯着每一条 commit 看。我们当然不能靠写假的 commit mes-sage 糊弄过去，而是真的是在做有意义的改进。”此外还有需要考虑很多因素。首先是法律问题，比如要确保每段代码都有合适的

331、版权声明、没有引用内部问题单或者泄露内部信息等等。这些听起来都是“显而易见的”，但确实需要处理。然后是代码质量的问题。如果没人看代码，代码质量可能就不太行；但如果全世界都在看，写代码的心态就完全不同了，有人可能会因此感到压力。不过 Kai 明确表示，现阶段不会把“代码质量”作为开源门槛的重点考虑因素现阶段不会把“代码质量”作为开源门槛的重点考虑因素，反而更关心的是诸如内部已经有的那些 issue 怎么处理等问题。另外，还有测试用例本身的问题。好用的测试用例往往来自我们内部的 flight（测试回归运行），我们会看到一些真实的 prompt、源代码片段，观察失败的案例，然后把它们加入到 S 测试

332、套件中。但现在我们需要把这些内容清洗掉，才能对外发布。这又是一个工作量不小的过程。“今天我们从宣布开始这件事正式起步，然后我们会一步一步推进。我们最重今天我们从宣布开始这件事正式起步，然后我们会一步一步推进。我们最重 145 InfoQ 架构师2025年第一季 要的承诺是：我们不会扔下包袱就走人了，这不是我们的风格。要的承诺是：我们不会扔下包袱就走人了，这不是我们的风格。”Eric 说道。Eric 给出了承诺：“我们会确保整个过程是完全透明的。你可以清楚地看到我们每一步在做什么，未来计划是怎样的。我们的变更计划是公开的，每个月的计划甚至都固定贴在 GitHub 的 Issue 上。你可以随时关

333、注，可以提出问题，这就是我们的运作方式。我们会确保整个过程完全透明。”不过，开发者现在还看不到所有内容，“因为我们前面也提到了有很多工作还没做完。”参考链接参考链接 https:/ 146 访谈文章|Interview 年赚三亿美金、估值近百亿，年赚三亿美金、估值近百亿，Cursor Cursor 竟无护竟无护城河？城河？5 月 6 日，AI 编程黑马 Cursor 的母公司 Anysphere 完成了一轮 9 亿美元（约合人民币约 65 亿元）融资，估值增长两倍多，达到约 90 亿美元（约合人民币约 654 亿元）。这款全球增长最快的 AI 代码编辑器，推出仅两年便达到了 3 亿美元的年经常性收入，其背后成功的秘诀是什么？最近，Anysphere 的联合创始人兼首席执行官 Michael Truell 在播客节目中，与主持人 Lenny 详细回忆了 Cursor 构建过程中的经验教训，团