AI 写代码更快了，企业交付为何仍未提速？小红书 Muse 的 Agentic 实践

导语

大模型让“写出一段代码”变得越来越快，但企业真正关心的是：需求能否被准确理解，产物能否符合设计与工程规范，变更能否通过安全检查，并最终稳定进入生产环境。小红书 AI Coding 总架构师郑鑫祺在分享中以 Vibe Coding 平台 Muse 为例指出，编码只是研发链路的一环，前面和后面的协作断点，可能抵消模型带来的效率收益。

从代码生成转向完整交付

企业级 AI Coding 的难点主要集中在三处：

• 缺少企业上下文：模型不了解内部组件、代码仓库、业务知识和设计规范，生成结果往往需要大量返工。
• 上下文彼此割裂：用户记忆、需求讨论、设计稿和多仓库工程信息分散在不同系统，Agent 难以形成统一判断。
• 能力链路没有闭环：即使系统拥有许多工具和 Skill，也可能出现工具冲突、任务跑偏或无法恢复的问题。

Muse 的目标不是生成一个只能展示的 HTML Demo，而是把需求共创、设计探索和真实工程实现放在同一条上下文链路中。产品经理、设计师和开发者可以围绕同一个可编辑产物快速比较方案，随后由 Dev Agent 延续上下文，进入真实代码仓库完成落地。

Agent Team 之外，更重要的是控制面

Muse 将需求形成之前称为“上工程”，将进入代码仓库后的实现称为“下工程”。前者帮助团队明确目标和方案，后者则需要处理跨仓上下文、代码规范、测试和交付约束。为兼顾泛化与精度，系统并非简单地把所有任务交给多 Agent 自主完成，而是组合使用 Workflow、Pipeline 和 Agent Team：确定性强的环节保留固定流程，需要探索和拆分的任务再交给动态编排。

其中，Harness 相当于 Agent 的运行时控制层。它可以在任务开始前检查上下文，在执行过程中监控每次调用，在工具参数和返回结果处进行校验，并在产生副作用前要求人工确认。任务状态也不能只依赖聊天记录，而应结构化保存目标、计划版本、执行步骤、工具证据、审批记录、资源版本和失败信息。这样，任务才有机会暂停、恢复、审计和回滚。

意义与影响

这套思路揭示了 AI Coding 的下一阶段：竞争重点不再只是哪个模型生成代码更快，而是谁能把模型能力包装成可靠的研发系统。模型决定能力上限，Agent Runtime、企业知识、验证器和权限边界则决定它能否进入生产。

对企业而言，人也不会简单退出流程。人的角色将更多转向目标判断、方案取舍、风险监督和最终品味；AI 负责扩大探索空间，并承担更多可验证的执行工作。只有当上下文、工具、状态和审批形成闭环，Vibe Coding 才可能从快速原型工具，走向真正可交付的工程基础设施。

来源：InfoQ 中文