在本届 RTE2025 大会上,来自产业界和学术界的多位专家深入探讨了如何赋能 AI 开发者,高效、稳定地构建下一代应用?又该如何设计新的协同模式,实现人机能力的最佳融合?
亚马逊云科技资深开发者布道师郑予彬、TEN Framework Co-Founder Plutoless、memU founder 陈宏、月之暗面开发者关系负责人唐飞虎、PPIO 智算业务云产品技术专家王贺、MiniMax 开发者生态负责人冯雯等技术专家、开发者和创业者,一同探索上下文工程和 Agentic AI 开发、分享了他们在各自领域的实践经验和独到见解。
声网大语言模型实验室高级科学家李忻玮和 TEN Framework 的 Co-founder Plutoless 分别主持了活动主题分享和圆桌讨论环节。
###
###
亚马逊云科技的开发者布道师郑予彬梳理了 AI 在代码开发领域的范式演进。
她指出,早期的 AI 辅助开发主要停留在代码补全等「一对一」的触发式交互,其效率极限受限于人的指令速度。真正的突破源于 AI Agent 的出现,它将大语言模型从一个被动的对话者转变为能够自我推理、使用工具并参与框架性思考的主动协作者。
基于 ReAct(Reasoning and Acting)等模式,Agent 可以通过调用外部工具和数据来获取上下文,从而克服模型的「幻觉」问题,更深刻地理解复杂需求,实现了从「单点智能」到「系统化智能」的飞跃。
为将在生产环境中落地这一新范式,亚马逊云科技推出了 Stands Agent SDK 与 AWS Kiro 两大项目。
Stands Agent SDK 是一个帮助开发者快速构建 AI Agent 的脚手架。它支持灵活切换多种大模型(如 BedRock、Anthropic)、集成各类工具,并内置了如 Orchestrator、Swarm、Graph 等多种主流的 Multi-Agent 协作模式。
AWS Kiro 则是一款具体的 IDE 工具,它直面了当前 AI 开发的两种核心路径:一种是完全由自然语言驱动的「Vibe Coding」,郑予彬坦诚这种「黑盒式」的开发方式虽适合快速原型验证,但在实际项目中因其过程不可控,曾让他「失败了无数次」;另一种则是 Kiro 倡导的「Spec-driven Development」,该模式将开发流程拆解为项目理解、需求分析、方案设计等多个可控、可验证的步骤,每一步都有人的监督和文档的沉淀,让 AI 在清晰的框架内高效协作,最终实现真正可用于生产的 AI 开发工作流。
「 AI 时代,我们不做选择题,我们全都要——关键在于,在不同的生产阶段,采用合适的工作方式,比如到底选择 Vibe Coding 还是 Spec-driven。」
郑予彬
亚马逊云科技开发者布道师
TEN Framework Co-Founder Plutoless 指出,过去一年,对话式 AI 行业普遍存在「卷延迟」的现象,即 AI 回复越快越好。然而,在实际商业化落地过程中,这种做法往往导致糟糕的用户体验,例如 AI 抢话、用户被频繁打断等问题。
行业正从追求极致延迟转向更看重整体对话体验。****
他认为,宁愿牺牲一点延迟,也要保证对话的完整性和流畅性,避免 AI 反复打断用户。 TEN Framework 通过对打断与回复、背景人声干扰、AI 响应灵敏度等问题的工程化解决方案,实现了更拟人化的对话。
TEN Framework 的设计旨在将模型能力与体验需求策略模块化,允许开发者像「搭积木」一样构建对话式应用,支持 ASR、LLM、TTS 等多种 TOP 模型,并特别优化了 Python 和 C++ 的混合编程能力,以应对生产环境的性能挑战。
他重点介绍了 TEN Framework 在解决行业痛点方面的具体实践,例如 TEN VAD 模型用于精确人声探测,过滤背景噪声,以及 TEN Turn Detector 模型用于实现基于上下文感知的轮次检测,确保对话的流畅进行。在多模态和多语言支持方面,TEN Framework 也提供了强大的能力,能够应对不同区域的语言需求和复杂场景。
TEN Framework 目前更侧重于灵活的链式模型构建,这在当前商业化落地场景中更具优势,因为其可定制性和易于调整的特性能够更好地满足垂类业务的需求。
Plutoless 将当前行业的发展划分为四个阶段,从早期的轮次对话,到自然拟人的对话,再到 AI 并行思考和执行,直至最终的情感智能和超越人类的通用智能。
TEN Framework 的目标是将对话式 AI 的开发门槛降低,并加速行业标准的形成,让开发者能够更快速、更高效地构建出高质量的对话式 AI 应用。
「对话式 AI 行业正从追求极致延迟转向更看重整体对话体验。」
Plutoless
TEN Framework Co-Founder
#
memU 的 founder 陈宏直言当前主流的 RAG 方案「体验非常差,不能保证召回的准确率」。正是基于这个痛点,memU 诞生了,它提供了一种全新的 Agentic Memory 框架,目标是让 AI 拥有像人类一样、能自我进化的长期记忆。
memU 选择了 Agentic Memory 路径:把记忆系统本身当成一个 Agent 来处理,让它拥有读取、写入、更新和校验数据的能力,从而大幅提升操作的精准度和召回的准确性。memU 的最终交付形态是一种 File Base 的记忆,类似 Cloud 存储项目记忆。文件形式对 LLM 来说非常易读,内容经过整理,可以直接放入上下文,相比数据库的离散数据更有效。这种机制就像计算机的 RAM 结构,能够根据用户的 Query 不断增加或优化记忆,并让所有的用户信息和上下文整理成为非常类似于 Wikipedia 的结构——包含高价值、经过推理和整理的页面,并可以互相超链接。它在应用开发中扮演了至关重要的角色:
替代算法:它通过提取 User 和 Agent 交互中的有价值信息,让 Agent 实现非参数化的自我学习、自我迭代;
解决 Context 爆炸:在 Agent 协作场景中,Memory 负责将复杂的 Context 提炼、筛选后,再传递给下一个 Agent;
知识沉淀:帮助企业从 PDF、员工知识等非结构化数据中提取核心价值信息。
陈宏认为:「未来 Memory 会取代大量数据工程师和算法工程师的工作,通过非参数化的形式做到让 Agent 自我学习、自我迭代的功能。」
「本质上来讲,Memory 就是做一件事情:从复杂的数据抽取对于场景有价值的信息。」
陈宏
memU founder
月之暗面开发者关系负责人唐飞虎深入剖析了当前 AI 编程工具在实际应用中的矛盾现状。管如今的大模型(如 OpenAI 的模型)能在国际顶尖编程竞赛中解决人类选手未能攻克的难题,却常常在一些对人类而言逻辑直观、但对模型来说抽象复杂的任务上「翻车」。
这种现象并非简单的模型能力不足,而源于上下文缺失、需求模糊,以及 AI 与人类在解决问题思路上存在根本差异,导致开发者在 Debug AI 生成的代码时,反而耗费了更多时间。
面对这一挑战,唐飞虎认为开发者不必消极等待模型进化,而应主动构建一套更高效的人机协作范式。他分享了一系列具体的实践策略,从工作流设计到开发纪律。
在方法论上,唐飞虎强调了「PRD First」(先撰写清晰的产品需求文档)和「测试驱动设计」(Test-driven Design),确保在编码前就与模型对齐需求、验证结果。
在技术实践上,唐飞虎介绍了通过 ToolCall 等技术实现任务并行处理,以及利用结构化 Prompt(如强制输出 Strict JSON)来规范模型行为。
其中一个极具启发性的细节是「永远备份」——建议为 AI 单独设立一个 GitHub 账号,让模型每次修改后自动提交,从而清晰地追踪每一次变更,极大地提升了在复杂任务中调试和回溯的效率。
这些策略的核心思想,是让开发者从纯粹的执行者转变为一位善用工具、规划任务的「指挥家」。
「要让模型做更多的事情,你只需要去做最关键的决策。」
唐飞虎
月之暗面开发者关系负责人
###
PPIO 智库的云产品技术专家王贺在分享中指出,当前 AI Agent 在执行由大语言模型生成的代码时,面临三大核心挑战:AI 代码的安全与可靠性问题(可能导致资源耗尽或数据泄露)、传统虚拟机启动速度慢(无法快速响应海量请求)以及资源动态管理的复杂性(业务潮汐与环境恢复需求)。
为此,PPIO 提出了其 AI Agent 沙箱技术,旨在提供一个安全、隔离、可执行且能快速响应的环境。
PPIO 的 Agent 沙箱选择了一条兼顾启动速度和安全隔离的路径,核心基于微虚拟机(MicroVM)方案实现,采用开源的 ** Firecracker**。
Firecracker 以其 Rust 语言编写带来的极高执行性能和稳定性、以及极简设计理念(仅保留网络、存储等必要设备)脱颖而出。这使得沙箱能在 125 毫秒以内启动,解决了传统虚拟机启动慢的问题,并且每个 Firecracker 实例仅需 5KB 内存,非常适合大规模部署。
为了进一步增强安全性,PPIO 沙箱为每个实例提供单独的 Linux 内核,在网络底层进行彻底隔离,并通过严格的资源限制和 Timeout 机制自动回收长时间空闲沙箱,有效降低成本。
同时,PPIO 通过引入沙箱模板(虚拟机快照)和支持 Dockerfile 构建,大大简化了用户环境的创建与管理。
该沙箱技术被广泛应用于主流 Agent 场景:
Browser Use(内置 Chrome 浏览器和自动化框架,用于数据抓取、表单填写等)
Code Use(提供 Python、Java 等主流语言运行环境,支持动态下载依赖和远程执行代码)
Computer Use(让 Agent 通过处理桌面截图操纵完整桌面环境)
为实现极致性价比和智能资源管理,PPIO 引入了 Pause/Resume 机制,能在沙箱释放时完整保存状态,并在下次请求到来时快速恢复,从而确保 Agent 任务的「无感知」连续性,并有效动态减少资源成本。
「如何在用户请求到来时快速响应,完成任务处理,这是所有 Agent 开发者需要考虑的问题。」
王贺
PPIO 智算业务云产品技术专家
###
MiniMax 开放平台解决方案高级总监冯雯,分享了 MiniMax 在 Voice Agent 场景下的技术探索,特别是关于端到端语音大模型的机遇与挑战,以及其在 TTS 环节的实践。
冯雯认为,端到端语音大模型是未来的趋势,它将 VAD、ASR 和 LLM 结合在一起,实现语音入、语音出。它的潜力在于:能够将用户说话过程中的情感、停顿、措辞等所有信息作为整体输入,获得更全面的信息,从而进行更拟人化的回复。端到端模型有两大优势:延迟更低(将多个环节延迟合并为一个)和情感理解更全面。然而,冯雯也坦诚,在当下,端到端语音大模型的使用体验「确实还不够好」:延迟和成本、指令遵循不足、不确定性和不稳定性。「因为每个链路都是黑盒,整体输出就会更不稳定,会有奇怪的声音或者一些不稳定造成结果的报错,这些都比集连出错更多。」因此,MiniMax 在链式模型的「最后一公里」——TTS(文本转语音)环节做了大量投入,力求在这个可控的环节做到极致。
MiniMax 在 TTS 方面取得了可观地位(HuggingFace 榜单排名第一),其关键技术实践包括:
极速音色复刻:只需要 10 秒钟的语音内容,不限制内容,即可完成声音复刻;
口音复刻:针对海外市场需求,可以输入带有澳大利亚、新加坡、印度等口音的片段,完成对应口音的复刻;
文生音色:用户可以直接描述想要的音色,模型即可生成对应的音色,并支持混音操作;
准确表达:保证对数学公式、邮箱、手机号等特殊字符的准确表达,支持灵活设置情绪参数(快乐、悲伤)和音效,以改善用户体验。
「AI 的迅猛发展将催生新的交互,未来的交互将依赖于创新的硬件载体,以语音为主要媒介进行沟通。」
冯雯
MiniMax 开发者生态负责人
###
###
过去的一年,AI Agent 编程工具的浪潮席卷全球,每个环节都在被重新定义,开发者也是对于 AI Coding 既爱又恨。爱的就是生产力的飞速提升,恨就是非常多的幻觉,产生的很多依赖以及非常多的不确定性。
本次主题为「Vibe Coding 的爱与恨」的圆桌讨论由 TEN Framework Co-founder* Plutoless 主持,参与讨论的嘉宾有亚马逊云科技资深开发者布道师郑予彬,memU Founder 陈宏以及月之暗面开发者关系负责人唐飞虎*。
####
####
嘉宾们首先从开发者和重度用户的角度,分享了 AI 编程工具中「爱」与「恨」的体验:
唐飞虎将最「爱」的功能投给了 Cursor Tab 的智能补全。就像早年 Java 开发者离不开全家桶一样,在 AI 时代,Tab 补全仿佛能够「读心」,提前预知开发者的意图,狂按 Tab 就能自动完成大量工作,带来了极大的「爽感」。一个好的补全功能是 AI 时代最核心且不可或缺的开发者体验。
陈宏虽然是 Memory System 的设计者,但他作为重度用户,最「恨」的痛点在于需求表述的困难。他希望能够「直接把脑子交给 Cursor」,快速完成代码和 Debug。然而,将一个小时会议得出的复杂需求和上下文转译为详细的 Prompt 和文档,在他看来是非常浪费生命的,因此他期望 Memory System 能通过软硬件迁移,将其他软件中获取的上下文信息直接作为 Prompt 输入,减轻开发者的「转译」痛苦。
郑予彬则分享了其在测试 AWS Kiro 等工具时的复杂心境。他「喜」的是工具真的可以用于生产流程化,但「愁」的是像 Kiro 提出的 Spec-driven Development 模式,虽然流程化,但将 Vibe Coding 变得过于复杂,开发者必须严格遵循「理解项目—需求分析—生成文档—执行」的流程。他指出,当前的开发工具进化速度极快,仍有很大的优化空间,特别是期待多模态大语言模型能带来体验上的全面翻新。
####
讨论转向了工具设计者的理念。嘉宾们围绕如何引导开发者使用、如何提供更优体验进行了探讨:
郑予彬表示,设计原则很大程度上来源于研发团队自身的痛苦和经验。他观察到,无论是 Kiro 还是 Cursor,设计方向都趋于一致,即功能更加多样化以适应不同场景,同时通过 Serverless 等方式进行性能优化。他认为,当前的功能和性能优化受限于大语言模型的二维(文本)局限性,未来多模态大模型出来后,开发的场景将从电脑搬到更多新的场景,例如语音和图像的输入输出,带来全新的开发体验。
陈宏从 Memory Service 的角度分享了他们将复杂性内化的过程。他们发现,最初提供简单的 Memory API(Memorize 和 Retrieve)时,很多开发者并不知道如何优化使用。因此,memU 推出了 Responsive API,将 Memory 机制内化到类似于 OpenAI Compatible 的普通 API 调用流程中,使开发者可以「无需担心」Memory 的处理,从而帮助他们更快地进行场景实验和开发。
唐飞虎强调了 「让开发者更好地进入整流状态」 这一核心目标。Cursor 之所以使用体验极佳,是因为模型很少阻断开发者的流程。任何模型中不该出现的错误或流程阻断都极大地破坏体验。月之暗面的核心思路是适配 Kimi 等高性能模型,并将更多的定制化权利交给用户,让开发者基于 Kimi 模型搭建符合自己习惯的 Workflow,充分发挥模型本身的性能,同时保证流程的流畅性。
####
关于 AI 工具的交互界面,嘉宾们认为未来的趋势是共存和组合,以适应不同角色的需求:
唐飞虎指出,AI 服务的对象已不仅限于专业开发者,还包括产品经理、设计师等非传统开发者。对于这些人群,低代码的 Local 环境和「Prompt 即插即用」的界面(如豆包的九宫格功能)更有用。而高度专业的开发者可能更倾向于在 Terminal 环境中与系统 OS 打交道。最好的模式是 AI 能够组合这些工具,根据不同的场景和目标自动选择最合适的交互方式。
郑予彬补充道,未来的接口可能是一个声音转文字的简单接口,允许开发者像搭模块一样设计自己的工具,以覆盖多轮转换和不同阶段的开发者需求。
####
##
在对 AI 驱动的开发模式进行总结和展望时,嘉宾们提出了深远的见解:
郑予彬认为,未来的开发范式需要重新定义规则性和合作方式。有了强大的工具和外挂,当前亟需解决的是如何规范代码的可复制性、可洞察性、可控制性和可合作性。她强调,防止代码被窃取和解决 AI 生成代码中潜藏的安全漏洞,需要规则和合规来规范开发流程、工具和行为。
陈宏从商业化的角度表达了对 Vibe Coding 生态繁荣的期望。他认为,如果 Vibe Coding 能够普及,将催生出数百万乃至数亿的 App,这将有利于 Memory System 等第三方服务的发展。他期望未来能够是去中心化的,每个人都可以有自己编译出的应用,而不是仅依赖于少数几个头部应用。他本人也断言,如果能不写 Code,肯定是不写,因为写代码是体力活。
唐飞虎则认为,开发者不会因此消亡。AI 代码生成能力将在未来三到五年内飞速增长,顶尖模型解决复杂问题的能力已接近人类顶尖选手,且推理成本会不断下降。类比 AI 围棋,虽然人类已经下不过 AI,但棋手依然能下出精彩对局。如果模型能很好地解决 A 任务,开发者就会去设计模型解决不了的更难、更复杂的 B 或 B+ 任务,这种不断挑战天花板的精神和对用户需求的敏锐观察,将是未来开发者最核心的技能。
Plutoless 总结,Vibe Coding 无法解决所有问题,但值得认真对待,他恳切期望尚未开启 Vibe Coding 的开发者尽快尝试。他认为,未来对开发者的核心要求将集中于:设计和解决复杂问题的能力、对用户需求的敏锐观察,以及对技术本质的深刻理解和持续追问。
阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么