
图片来源:a16z
Z Highlights
-
与其说有几个框架主导了整个生态系统,不如说我们将看到更多的可组合、栈特定的生成方式,其中工具和架构可以动态组合。
-
Agent不再需要点击像素位置或抓取DOM,而是可以像辅助技术一样——从语义上观察应用程序。
-
MCP客户端和服务器是逻辑上的边界,而不是物理边界。
开发者们已经不再将AI仅仅视为工具,而是开始将其视为构建软件的新基础。我们曾经理所当然接受的许多核心概念——版本控制、模板、文档,甚至用户的概念——由Agent驱动的workflow面前,它正在被重新思考。
Agent正在兼具合作者、消费者的身份,我们预计基础开发工具会发生变化。prompt语可以像源代码一样对待,仪表板可以变得像对话一样,文档既是为人类写的,也是为机器编写的。MCP(模型上下文协议)和IDE(AI本土集成开发环境)指向开发循环本身的更深层次重构:我们不仅仅在编写代码,更在为一个Agent完全参与软件循环的世界设计工具。
接下来,我们将探讨九种前瞻性的开发者模式,尽管它们仍处于早期阶段,但它们扎根于实际的痛点,并展露出未来可能出现的趋势。这些模式包括重新思考AI生成代码的版本控制,基于大语言模型(LLM)的用户界面和文档等。
让我们深入了解每个模式,并通过开发者社区的示例和见解进行分析。
AI本土Git:重新思考AI Agent的版本控制
现在,AI Agent越来越多地编写或修改应用程序代码的大部分内容,开发者关心的事情开始发生变化。我们不再专注于逐行编写的代码,而是关注输出是否按预期行为运行。更改通过测试了吗?应用程序仍按预期工作吗?
这颠覆了一个长期存在的思维模型:Git设计用来跟踪手工编写代码的精确历史,但在有编码Agent的情况下,这种精细度变得不那么重要。开发者通常不会审查每个差异——尤其是当更改较大或自动生成时——他们只关心新行为是否与预期结果一致。因此,Git SHA——曾经是“代码库状态”的标准引用——开始失去一些语义价值。
一个SHA告诉你某些内容已更改,但并未告诉你为什么更改,或者它是否有效。在以AI为主的workflow中,一个更有用的unit of truth可能是生成代码的prompt和验证其行为的测试的组合。在这种情况下,你的应用程序“状态”可能更好地通过生成输入(prompt、规范、约束)和一套通过的断言来表示,而不是一个冻结的commit hash。我们最终可能会将prompt+测试包作为可版本控制的单元来追踪,而Git则被用来追踪这些包,而不仅仅是原始源代码。
更进一步:在Agent驱动的workflow中,source of truth可能会上移到prompt、数据模式、API合同和架构意图。代码成为这些输入的副产品,更像是编译后的工件,而不是手动编写的源代码。在这个世界里,Git开始不再作为工作空间,而更多地作为一个工件日志——用于跟踪不仅是什么发生了变化,还要追踪变化的原因和是谁做的。我们可能会开始添加更丰富的元数据,例如哪个Agent或模型进行了更改,哪些部分是受保护的,以及哪些地方需要人工监督——或者像Diamond这样的AI审阅者可以介入循环。
为了使这一点更加具体,以下是一个AI本土Git工作流的实践效果图:

图片来源:a16z
数据看板 -> 综合:动态AI驱动的界面
多年来,数据看板一直作为与复杂系统(如可观察性堆栈、分析工具、云控制台(例如AWS)等)进行交互的主要界面。但它们的设计往往存在用户体验过载的问题:有太多的旋钮、图表和标签,迫使用户既要寻找信息,又要弄清楚如何采取行动。特别是对于非高级用户或跨团队使用者,这些数据看板可能变得令人生畏或效率低下。用户知道自己想要达成什么目标,但却不知道应该在哪里查看,或应该应用哪些过滤器才能达到目标。
最新一代的AI模型提供了潜在的变革。可以不再将数据看板视为僵化的界面,而是将搜索和交互功能叠加进去。LLM现在可以帮助用户找到合适的控制项(例如:“我在哪里可以调整这个API的速率限制设置?”);将全屏的数据综合成可消化的洞察(例如:“总结过去24小时内所有服务在预发布环境中的错误趋势”);并揭示未知的未知(例如:“根据你对我的业务的了解,生成我应该关注的本季度指标清单”)。
我们已经看到了像Assistant UI这样的技术解决方案,让Agent能够将React组件作为工具使用。就像内容已经变得动态和个性化一样,UI本身也可以变得适应性强和具有对话性。一个完全静态的数据看板很快就会显得过时,尤其是在与基于自然语言驱动的界面相比时,后者会根据用户的意图重新配置。例如,用户不必通过点击五个过滤器来隔离指标,而是可能会说:“显示上周末在欧洲的异常情况”,数据看板会重新调整以显示该视图,并附上总结的趋势和相关日志。或者,更强大的是,用户说:“为什么我们的NPS得分在上周下降?”AI可能会提取调查情感数据,将其与产品部署相关联,并生成一份简短的诊断报告。
在更大的规模上,如果Agent现在是软件的使用者,我们可能还需要重新思考“数据看板”是什么,或者它们是为谁设计的。例如,数据看板可以呈现出优化的Agent体验视图——结构化的、可编程访问的界面,旨在帮助Agent感知系统状态、做出决策并采取行动。这可能会导致双模式界面:一个面向人类,另一个面向Agent,二者共享相同的状态,但根据不同的使用方式进行定制。
在某些方面,Agent正在取代以前由警报、定时任务或基于条件的自动化所承担的角色,但它们提供了更多的上下文和灵活性。它们可能会称:“错误率正在上升,这是可能的原因、受影响的服务以及提出的修复方案。”而不是像传统的预先设定的逻辑(例如“如果错误率 > 阈值,则发送警报”)。在这个世界里,数据看板不仅仅是观察的地方;它们是人类和Agent协作、综合并采取行动的地方。

图片来源:a16z

图片来源:a16z

图片来源:a16z
仪表板如何发展以支持人类和AI Agent的viewer
文档正在成为工具、索引和互动知识库的结合体
在文档的使用方式上,开发者的行为正在发生变化。用户不再通过查阅目录或从上到下地浏览,而是从一个问题开始。思维模型不再是“让我研究这个规范”,而是“以我喜欢的方式重新整理这些信息”。这种微妙的转变——从被动阅读到主动查询——正在改变文档的性质。文档不再仅仅是静态的HTML或Markdown页面,而是变成了互动知识系统,背后有索引、嵌入和工具感知Agent的支持。
因此,我们看到像Mintlify这样的产品崛起,它不仅将文档结构化为语义可搜索的数据库,还充当跨平台代码Agent的上下文来源。Mintlify页面现在经常被AI编码Agent引用——无论是在AI IDE、VS Code扩展,还是终端Agent中——因为编码Agent使用最新的文档作为生成的基础上下文。
这改变了文档的目的:它们不再仅仅是供人类读者使用,而是也供Agent消费者使用。在这种新动态中,文档界面变得像是AI Agent的指令。它不仅仅暴露原始内容,还解释了如何正确使用系统。

图片来源:a16z
这是一张来自Mintlify的截图,用户可以通过cmd+k快捷键打开AI聊天窗口,进行关于Mintlify文档的问答。
从模板到生成:Vibe编码替代create-react-app
过去,启动一个项目意味着选择一个静态模板,如GitHub上的一个脚手架仓库,或者像create-react-app、next init、rails new这样的命令行工具。这些模板作为新应用的框架,提供了一致性,但定制性较差。开发人员只能按照框架提供的默认设置进行开发,或者要冒进行大量手动重构的风险。
现在,随着Replit、Same.dev、Loveable、Convex的Chef和Bolt等文本到应用平台的出现,以及Cursor等AI IDE的兴起,这一动态正在发生变化。开发人员可以描述他们想要的内容(例如:“一个包含Supabase、Clerk和Stripe的TypeScript API服务器”),然后在几秒钟内生成一个定制化的项目框架。结果是一个个性化且有目的的启动框架,既反映了开发人员的意图,也体现了他们选择的技术栈。
这为生态系统带来了新的分发模式。与其说有几个框架主导了整个生态系统,不如说我们将看到更多的可组合、栈特定的生成方式,其中工具和架构可以动态组合。开发者不再只需要选择一个框架,而是描述一个结果,AI可以围绕这个结果构建技术栈。一个工程师可能使用Next.js和tRPC创建一个应用,而另一个则使用Vite和React开始,但他们都会立刻获得一个可用的框架。
当然,这样的变化也有其权衡。标准化栈带来了实际的优势,包括提高团队生产力、改善新成员入职以及简化跨组织的故障排除。跨框架重构不仅仅是技术上的挑战,它还涉及到产品决策、基础设施限制和团队的专业能力。但正在发生变化的是,切换框架或从没有框架开始的成本大大降低。随着能够理解项目意图并能半自动执行大规模重构的AI Agent的出现,实验变得更加可行——如果需要的话,也可以轻松逆转。
这意味着框架决策变得更加可逆。开发人员可能会从Next.js开始,但后来决定迁移到Remix和Vite,并请求AI Agent处理大部分重构工作。这减少了框架曾经强加的锁定效应,鼓励了更多的实验,尤其是在项目的早期阶段。它还降低了尝试意见化栈的门槛,因为之后切换不再是巨大的投资。

图片来源:a16z
超越 .env:在Agent驱动的世界中管理密钥
几十年来,.env文件一直是开发者管理密钥(例如API密钥、数据库URL和服务Token)的一种默认方式,它们简单、便携且对开发者友好。然而,在一个Agent驱动的世界中,这种范式开始出现问题。当AI IDE或Agent代替我们编写代码、部署服务并协调环境时,.env文件的拥有权变得不再明确。
我们可以看到一些可能的发展方向。例如,最新的MCP规范包含了基于OAuth 2.1的授权框架,暗示着可能会转向为AI Agent提供具有作用域、可撤销的Token,而不是原始密钥。可以设想这样的场景:AI Agent不会获取你实际的AWS密钥,而是获得一个短期凭证或一个能力Token,让它执行一个特定定义的操作。
另一种可能的趋势是本地密钥Agent的兴起——这些服务运行在你的机器上或与你的应用程序并行,充当Agent与敏感凭证之间的中介。Agent不再将密钥注入.env文件或硬编码到框架中,而是可以请求访问某个能力(例如“部署到预生产环境”或“将日志发送到Sentry”),然后由Agent判断是否授予访问权限——这一过程是即时的,并且具有完全的可审计性。这种方式将密钥访问与静态文件系统解耦,使密钥管理更像是API授权而不是环境配置。

图片来源:a16z
一个关于以Agent为中心的秘密Agent流程在CLI中的示例
可访问性作为通用接口:从LLM的视角看应用程序
我们开始看到一类新的应用程序(例如Granola和Highlight),它们请求访问macOS的可访问性设置,但不是为了传统的可访问性使用场景,而是为了让AI Agent观察和与界面互动。然而,这并不是一种黑客行为,而是对更深层次变化的窥视。
可访问性API是为了帮助有视觉或运动障碍的用户导航数字系统而构建的。但当这些API被有意义地扩展时,它们可能成为Agent的通用接口层。Agent不再需要点击像素位置或抓取DOM,而是可以像辅助技术一样——从语义上观察应用程序。可访问性树已经暴露了诸如按钮、标题和输入框等结构化元素。如果通过元数据(例如意图、角色和可操作性)扩展,这可能成为Agent的首选接口,让它们能够有目的、有精准地感知和操作应用程序。
有几个潜在方向:
-
上下文提取:一种标准方法,允许LLM Agent通过可访问性或语义API查询屏幕上的内容、它可以互动的元素以及用户正在做什么;
-
有意图的执行:与其让Agent手动链式调用多个API,不如暴露一个高层次的端点,让它声明目标(“将物品加入购物车,选择最快的运输方式”),然后让后端处理步骤;
-
LLM的回退UI:可访问性特性为LLM提供了回退UI。任何暴露了屏幕的应用程序都可以被Agent使用,即使它没有公开的API。对于开发人员来说,这暗示了一种新的“渲染表面”——不仅仅是视觉或DOM层,而是Agent可访问的上下文,可能通过结构化注释或以可访问性为优先的组件定义。
Asynchronous Agent工作崛起
随着开发人员与编码Agent的协作变得更加流畅,我们正在看到一种自然的转变:向异步workflow发展,Agent在后台运行,执行并行工作线程,并在取得进展时反馈。这种交互方式开始看起来不像成对编程,更像任务编排:你委派一个目标,让Agent执行,然后稍后再检查进展。
关键是,这不仅仅是将工作量外包出去;它还压缩了协调的时间。开发人员不再需要联系其他团队来更新配置文件、处理错误或重构组件,而是可以将这些任务直接分配给Agent,Agent会根据他们的意图在后台执行。曾经需要同步会议、跨职能交接或漫长的审查周期的任务,可能变成一个请求、生成和验证的循环。
Agent交互的界面也在不断扩展。开发人员不再总是通过IDE或CLI进行prompt,而是可以通过以下方式与Agent互动,例如:
-
发送消息到Slack;
-
在Figma设计图上发表评论;
-
在代码差异或PR中创建内联注释(例如,Graphite的审查助手);
-
基于部署的应用预览提供反馈;
-
利用语音或通话接口,开发人员可以口头描述变更。
这创造了一种模型,让Agent贯穿整个开发生命周期。它们不仅仅是在编写代码,还在解读设计、回应反馈和跨平台处理错误。开发人员成为了编排者,决定追求、丢弃或合并哪些线程。
也许这种分支和委托给Agent的模式将成为新的Git分支——不仅仅是代码的静态分支,而是一个动态的意图线程,异步运行直到准备好合并。
MCP离成为通用标准又近了一步
我们最近发布了关于MCP的深度分析。自那时以来,势头加速:OpenAI公开采纳了MCP,多个新特性被合并,工具开发者也开始将其作为Agent与现实世界之间的默认接口。
MCP的核心解决了两个大问题:
-
它为LLM提供了完成从未见过的任务所需的正确上下文;
-
它用一个干净、模块化的模型取代了N×M的定制集成,其中工具暴露了标准接口(服务器),任何Agent(客户端)都可以使用。
随着远程MCP和事实上的注册表上线,我们预计会看到更广泛的采用。随着时间的推移,应用程序可能会默认包含MCP接口。
可以想象,API使得SaaS产品能够互相连接,跨工具组合workflow。MCP也可能通过将独立的工具转变为互操作的构建块,实现AI Agent之间的互操作性。一个内置MCP客户端的平台不仅仅是“AI就绪”,它是更大生态系统的一部分,能够立即接入一个不断增长的可由Agent访问的能力网络。
此外,MCP客户端和服务器是逻辑上的边界,而不是物理边界。这意味着任何客户端也可以作为服务器,反之亦然。这理论上可以解锁一个强大的组合能力,通过它,使用MCP客户端来获取上下文的Agent,也可以通过服务器接口暴露自己的能力。例如,一个编码Agent可以作为客户端获取GitHub问题,同时也可以作为服务器,向其他Agent暴露测试覆盖率或代码分析结果。
抽象原语:每个AI Agent都需要身份验证、计费和持久存储
随着虚拟编码Agent的能力越来越强,有一件事变得清晰:Agent可以生成大量代码,但它们仍然需要一些坚实的基础设施来支持。就像人类开发人员依赖Stripe进行支付、Clerk进行身份验证或Supabase进行数据库功能一样,Agent也需要类似干净且可组合的服务原语来搭建可靠的应用程序。
在许多方面,这些服务——具有明确边界的API、符合人体工程学的SDK和合理的默认设置,减少了失败的可能性——越来越多地作为Agent的运行时接口。如果你在构建一个生成SaaS应用的工具,你不希望Agent从零开始编写身份验证系统或计费逻辑;你希望它使用像Clerk和Stripe这样的提供商。
随着这一模式的发展,我们可能会看到服务不仅仅通过暴露API,还有架构、能力元数据和示例流程,帮助Agent更可靠地集成它们。
一些服务甚至可能开始默认提供MCP服务器,将每个核心原语转变为Agent可以直接使用并安全访问的内容。想象一下,Clerk暴露一个MCP服务器,允许Agent查询可用产品、创建新的计费计划或更新客户的订阅——所有权限范围和约束都提前定义。Agent不需要手动编写API调用或翻阅文档,只需说:“创建一个49美元/月的‘Pro’计划,并按使用量收取额外费用”,Clerk的MCP服务器将暴露该能力,验证参数,并安全地处理协调。
就像早期的Web时代需要Rails生成器和rails new来加速开发一样,Agent时代也需要可靠的原语——即插即用的身份、使用追踪、计费逻辑和访问控制——这些原语足够抽象,可以进行生成,但又足够表达,能够随着应用的增长而发展。
结论
这些模式指向了一个更广泛的转变,在这种转变中,新的开发者行为与更强大的基础模型并行出现。作为回应,我们看到像MCP这样的新工具链和协议正在成型。这不仅仅是将AI层叠加到旧的workflow之上,而是重新定义了如何以Agent、上下文和意图为核心构建软件。许多开发工具层面正在发生根本性的变化,我们期待着构建和投资下一代工具。
原地址:Nine Emerging Developer Patterns for the AI Era
https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/
编译:Christine Liu
请注意,本文编译自文末载明的原始链接,不代表Z Potentials立场。如果您对本文有任何想法或见解,欢迎在评论区留言互动探讨。
Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群,与我们共同分享、学习、成长。
(文:Z Potentials)