AI 写代码飞快，为何交付没有变快？小红书 Muse 的 Agentic 架构实践

AI 写代码已经足够快，但从需求提出到生产上线，企业研发未必因此更快。设计规范、工程资产、跨仓上下文、安全检查和协作断点，常常会把编码阶段节省的时间重新消耗掉。如何让一个“会生成代码”的模型，成为真正能够交付、兜底和恢复的研发系统，正是 AI Coding 进入企业场景后必须解决的问题。在 AICon 全球人工智能开发与应用大会上，小红书 AI Coding 总架构师郑鑫祺以 Vibe Coding 平台 Muse 和AI Coding实践为例，分享了小红书对这一问题的实践。Muse 不只是一个代码生成工具，而是试图打通需求共创、设计、编码与交付，让产品经理、设计师和开发者在同一条上下文链路中与 AI 协作。围绕“高可用”与“人机共创”，郑鑫祺重点拆解了 Muse 的 Agent Team 编排、Harness 控制机制、企业知识工程与 Agent OS 架构，并进一步讨论：面对持续增强的模型，系统如何兼顾精度与泛化，以及人的角色如何从具体实现转向更有价值的判断、监督与品味。 以下为郑鑫祺演讲内容，经整理。 AI 写得飞快，为什么交付并没有变快？ 这次分享主要围绕两个关键词展开：高可用与人机共创。 高可用意味着，系统不仅能借助大模型解决局部问题，还必须具备稳定的交付、兜底和恢复能力。毕竟，大模型本质上仍是概率模型。如果系统只能完成演示，却无法进入真实生产环境，就不能称为高可用。 所谓人机共创，也不是简单地把工作交给 AI，而是人与 AI 共同讨论、持续判断，并将想法转化为最终产品。 2015 年毕业后，我曾在 Facebook 参与原型交互工具 Origami 的开发。当时我关注的问题是，如何把头脑中的想象快速转化为可见、可操作的原型。但原型完成后，新的问题随之出现：如何将它真正落到代码工程中？ 从小型项目、创业公司业务，到大厂内部的复杂系统，不同规模的工程面临着不同约束。此后的近十年里，我一直在思考：从产品原型到复杂系统，人应该如何与工程协同？又该如何通过工程建模和架构设计，让不同开发者和团队保持高效、有序的长期迭代？ 过去，这些工程约束主要面向开发者和研发团队。2024 年年中，我们开始意识到，AI 的快速发展将同时改变单点模块的实现方式和完整研发流程。此前积累的问题开始与 AI Coding 产生交汇：AI 时代需要被重新定义的，不只是 Coding，而是整个研发过程。 目前，我在小红书负责 AI Coding 大专项及相关产品矩阵。Muse 是其中具有代表性的 Vibe Coding 产品，也是本次分享的重点。 一个值得关注的现象是，尽管 AI 大幅提高了代码生成速度，需求从提出到上线的周期却未必同步缩短。来自团队内部及小红书更大范围的反馈显示：AI 写得很快，但研发人员并没有因此明显变得更轻松。 代码生成只是研发链路的一部分。AI 生成的代码可能不符合公司设计规范；界面看似正常，进入生产环境后却暴露出安全问题；代码虽然能够运行，却不满足现有代码仓库和工程体系的要求。节省下来的编码时间，最终又被消耗在检查、提测、修复、反复沟通，甚至推翻重做上。 与此同时，助理型 Agent 的出现也提高了用户预期。人们希望通过少量沟通就能让 AI 理解意图并执行不同任务，而不是每次都要按照固定格式编写复杂的 Prompt。 归根结底，当前企业级 AI Coding 主要面临三类问题： AI 不了解企业资产，生成结果难以满足研发和设计规范。用户记忆、业务知识与任务上下文分散在不同平台，AI 无法形成完整理解。从需求到交付的能力链路尚未贯通。即使系统具备大量原子化 Skill 和工具，这些能力也可能相互冲突，难以形成稳定协作。 因此，我们关心的不只是如何用 AI 把一个 Idea 快速实现出来，而是如何将它转化为具有商业价值、能够进入企业生产环境的程序。 Muse：让需求、设计与研发进入同一个共创空间 传统工作方式下，产品经理通常使用文字描述需求。但在 AI 时代，如果依然要先写一份纯文字 PRD，再通过会议向团队逐一解释，整个团队的竞争速度会受到限制。 我们更需要的是快速产出 A、B、C、D 多个方案，直接运行实验，观察哪个版本效果更好。需求产出的速度，在很大程度上取决于原型产出的速度。如果原型能够立即交给下游使用，整个协作链路才能真正提速。 设计工作也是如此。过去，设计师可能需要花费大量时间“搓方案”和比稿，还要与开发者进行非常深入的沟通，而这些环节消耗的时间可能远多于实际编码。 过去的比稿依赖体力，AI 时代的比稿更依赖判断力。 当 AI 可以一次提供十个版本时，人需要做的是判断哪个版本正确，然后快速推进 MMVP、MVP 和后续放量。 产品经理、设计师和开发者之间的协作方式也应该随之改变。过去可能需要拉会、约时间，再在线下慢慢解释；我们期待的体验则是：在 IM 群里提出一个 Idea，团队直接进入共创面板，产出符合企业规范的高保真原型。研发接手以后，再由另一个 Agent 延续上下文，继续完成后续工程。 Muse 正是在这样的目标下构建的。它生成的内容符合小红书现有 App 的设计风格和研发规范，用户在对话时可以保持开放和自由，同时也可以在编辑区域中沉浸式修改作品。 Muse 生成的不是一个只能展示的 HTML 页面，也不是仍然需要二次转译的中间产物，而是以达到上线标准为目标、能够适配真实工程仓库的代码。 在整个研发体系中，我们把需求形成以前的工作称为“上工程”，把进入真实代码仓库后的实现工作称为“下工程”。 上工程需要收集不同角色的上下文，辅助团队做出决策。例如，需求分析 Agent 可能更多地与 BI 和数据系统交互，围绕业务目标形成需求判断。决策明确以后，团队还需要快速确认产品到底改哪里、怎样改，并对多个设计方案进行比较。Muse 主要承载的就是这部分工作。 通过 Muse 场景，团队可以直接生成 Demo 和 PRD。一方面，这些内容可以用于汇报；另一方面，它们也为开发者提供了更完整、更直观的需求上下文。 再往下进入真实研发阶段，可能由 PM Agent 负责拉群和沟通，由 Dev Agent 进入代码仓库完成落地。Muse 自身同样需要使用 Dev Agent 的能力，因为它必须即时完成预览，并生成高质量、符合规范的代码。 过去的 AI 往往只是被分别塞进研发流程中的某个格子。格子之间彼此断开，上下文也无法传递。我们希望把需求共创、设计共创和 Coding 串成一条主线，使上下文能够沿着整个链路持续流动。 高可用人机共创面临的三类挑战 Muse 的核心技术能力可以分成两个方向。 第一个方向是 Dev Agent。无论前面如何讨论需求，系统最终必须生成符合研发规范的代码。这里涉及 Spec 质量、企业知识理解，以及复杂代码仓库带来的上下文问题。 过去面向人设计的工程体系中，存在大量复杂甚至过度的微服务拆分。进入 Agentic 系统以后，我们更强调 One Context、One Workspace：无论信息散落在多少微服务和代码仓库中，Agent 都需要把与任务相关的 Context 汇集起来。 尤其在服务端系统中，一个任务经常涉及多个仓库。如何让跨仓信息在一个 Workspace