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

本文整理自小红书 AI Coding 总架构师郑鑫祺在 AICon 全球人工智能开发与应用大会上的演讲，围绕 Vibe Coding 平台 Muse 展开，关键词是"高可用"与"人机共创"。

1. AI 写得飞快，为什么交付并没有变快？

高可用意味着系统不仅要借助大模型解决局部问题，还必须具备稳定的交付、兜底和恢复能力——大模型本质仍是概率模型，只能做演示无法进入生产环境的系统不能称为高可用。人机共创也不是简单地把工作交给 AI，而是人与 AI 共同讨论、持续判断，并将想法转化为最终产品。

一个值得注意的现象：尽管 AI 大幅提高了代码生成速度，需求从提出到上线的周期却未必同步缩短。AI 生成的代码可能不符合设计规范、进入生产环境后暴露安全问题、不满足现有工程体系要求。节省下来的编码时间，被消耗在检查、提测、修复、反复沟通甚至推翻重做上。

当前企业级 AI Coding 主要面临三类问题：

AI 不了解企业资产，生成结果难以满足研发和设计规范；
用户记忆、业务知识与任务上下文分散在不同平台，AI 无法形成完整理解；
从需求到交付的能力链路尚未贯通，原子化 Skill 和工具可能相互冲突，难以形成稳定协作。

我们关心的不只是如何用 AI 把一个 Idea 快速实现出来，而是如何将它转化为具有商业价值、能够进入企业生产环境的程序。

2. Muse：让需求、设计与研发进入同一个共创空间

传统工作方式下产品经理用文字描述需求，AI 时代如果仍先写纯文字 PRD 再逐层传递，竞争速度受限。更需要的是快速产出 A、B、C、D 多个方案直接运行实验。过去的比稿依赖体力，AI 时代的比稿更依赖判断力。

Muse 生成的内容符合小红书现有 App 的设计风格和研发规范，不是只能展示的 HTML 页面，也不是需要二次转译的中间产物，而是以达到上线标准为目标、能适配真实工程仓库的代码。

团队把需求形成前的工作称为"上工程"，把进入真实代码仓库后的实现工作称为"下工程"。Muse 主要承载上工程：收集不同角色上下文、辅助决策、生成 Demo 和 PRD。研发接手后由 PM Agent 负责拉群沟通，Dev Agent 进入代码仓库完成落地。目标是把需求共创、设计共创和 Coding 串成一条主线，使上下文沿链路持续流动。

3. 高可用人机共创面临的三类挑战

Muse 的核心技术能力分两个方向：

Dev Agent：生成符合研发规范的代码，涉及 Spec 质量、企业知识理解、复杂代码仓库的跨仓上下文。强调 One Context、One Workspace，把散落在多微服务和多仓库中的相关上下文汇集起来。
AI Native 对话和共创体验：Chat、Artifacts 和 Editor 三位一体，共享同一个 Context。

需要解决三类挑战：

懂业务、能动手：Agent 必须理解企业知识，生成高精度产物，而不是要求用户每次把规范写进 Prompt；
在人机协作中保持任务主线：模型倾向优先完成用户即时指令，但共创存在持续任务线，用户的一次修改不能把整个任务带偏；
保持长任务的连续性：把确定性的业务诉求与概率性的模型输出包装在一起，使任务可检查、可恢复并持续推进。Transformer 受 Context Slot 和注意力机制影响，模型控制不可避免，Harness 仍然必要。

4. 从 Workflow 到 Agent Team：模型控制如何演进

模型控制架构大致呈现三种形态：

Workflow（确定性控制）：2025 年前后模型长任务幻觉率高，系统将任务拆分为对焦、增强、召回、出码等确定节点，按固定顺序执行；
Pipeline（任务分流与局部控制）：随 Sonnet 4.5/4.6 等模型长任务遵循能力增强，可根据用户输入选择不同子流程，对精度差异的任务针对性编排。采用类似"房间"的方式管理上下文，进入主题时只加载相关 Skill/Tools/System Prompt；
Agent Team（动态编排）：用户只需描述 Story，系统在更高层完成任务规划与 Agent 调度，Agent 之间可形成嵌套式协作。

三者并非相互替代，可并存。确定性高的任务适合 Workflow/Pipeline，泛化能力强的场景引入 Agent Team。Agent Team 也会带来特有失败：子 Agent 重复做事、汇总阶段把矛盾结论拼在一起。作者判断：多 Agent 只在子任务确实独立、可并行、上下文能分离时才有收益。评测时除成功率外，还记录重复工作率、冲突率和汇总失败率等过程指标。

业界长期争论 More Intelligence vs More Steering。作者立场：模型决定能力上限，工程控制面决定它能不能进入生产。基本原则是 Agent OS 优先，Context Engineering 与工程护航负责增强——Agent OS 先承接开放性问题尽量靠模型自身完成，暴露的能力缺口再以增量补丁方式加护航意图并做 Check，命中 Bad Case 后继续增强控制机制。

对单个 Agent 节点在其完整生命周期设置 Hook：进入时检查 Context 完整性、判断是否需要 Human in the Loop；运行后检查每一次 Turn 是否需要 Verify，分框架级（防工具调用混乱/路径偏移）和业务级（约束特定场景行为）两层。检查要放在不同位置：请求进模型前拦住不该执行的内容、结果离开系统前校验、工具参数返回值本地校验、产生副作用的动作前暂停等人确认——合并成一个开关会同时漏掉几种失败。权限控制单位也不是一个开关，而是主体、动作、资源、参数和时间窗口的组合。

写操作需额外保护：每个产生副作用的动作带幂等键，留副作用日志（谁批准、哪组参数、作用于哪个资源哪个版本、执行结果、能否回滚），这样"同一操作被执行了两次"才能被发现和恢复。工具返回成功不等于业务完成，必须分开判断。

不要把对话记录当成运行状态。Transcript 是审计材料，不适合恢复任务。真正需要结构化保存的是不可变的任务目标、用户约束、计划版本、已完成/待完成步骤、工具证据、副作用日志、审批记录、产物、失败次数和剩余预算等。

作者总结演进方向：从 chatbot 分发处理逻辑，转化成如何构建一个好的 Agent Runtime，关注校验驱动的链路是否闭环：目标 -> 上下文 -> 计划 -> 工具执行 -> 状态更新 -> 验证 -> 审批 -> 可编辑交付物（版本化）。如果丢失某些状态、验证或权限边界，再强的模型也只是一个会用各种能力的 Demo，无法建立商业价值。

5. Agent OS：为 Agent 构建统一运行环境

AI 应用的演进：2024 年面向单个模块；2025 年 Agent 运行在微服务和 Pod 中；2026 年整体向"数字人"靠近，模型单步决策能力增强后 Agent 可直接面向流量。

Agent OS 背后包含：自研 Agent Framework（更细粒度控制 Context 变化）、运行环境（沙箱体系，区分短任务/长任务/端侧 Native Client）、统一 Memory Workspace（类似中心化云盘，挂载不同沙箱到同一 Workspace，加载 Policy/Strategy/Fact 多层知识）。企业环境还需设计身份与角色、数据域、操作审计等平面。

在企业落地里，"权限可解释、状态可恢复、审计可追溯"往往比模型能力领先几个百分点更有价值。

6. Agent App：让能力进入既有工作流

完整 Context 包括 System Prompt、Memory、Tools 和 Knowledge，还含用户画像（用另一个模型持续收集整理用户信息存入数据库）。提出 Agent App 概念：包含个性化信息、知识、Skill、编排和自进化能力，过去由 Code 定义，未来相当一部分可能由 Markdown 和可演进的 Agent Doc 定义。Agent App 运行在 Chat Gateway 之后，被嵌入企业已有工作流（IM、CLI、业务系统）。

Figma Agent 是典型例子：大型设计稿含十几个 Frame 甚至上百面板，一次性交给模型会超上下文上限。需用传统分治思想——先查看 Frame，再识别页面和组件，将巨型任务拆成可执行子任务并生成 DAG 执行清单，不同 Worker 分别完成后经 Check/Verify 再 Merge。每步状态、检查标准和反馈被显式记录，形成可恢复的状态文件。

7. 能否在正确的时间，把正确的知识交给正确的 Agent

Dev Agent 的关键问题是获取高质量上下文，分两个方向：理解上工程（Muse 产出的原型、PRD、共创记录）和理解下工程（代码仓库、历史 PR、测试流程）。过度微服务化问题难立即消除，但至少可先解决 Context 聚合问题。

企业知识使用方式演进：2024 年 Embedding + RAG 检索（快速召回但难 Debug，缺追溯链）；2025 年知识图谱化（结构更清晰但片段化匹配核心问题未变）。新方向是 Agent Team 分配不同专家对知识图进行更深入探索。准确知识更像一次 Research：代码专家和知识专家分别分析，通过推理链相互补充，最终形成判断并可反向追溯。

Context Engineering 更接近一条需要被观测的数据供应链，而不是"怎么把 Prompt 写得更漂亮"。要求每条进入上下文的证据带来源、时间、归属和权限信息；召回后经重排、去重、压缩；外部内容一律当不可信输入，不能改写系统规则。关键要做删除实验：把某类上下文去掉看成功率是否真下降——很多以为有用的上下文，删掉后指标没变化，只是在消耗窗口和成本。

8. 让企业知识可以量化和自进化

企业知识维护困难（Infra 团队未必理解所有业务，业务团队也没时间持续整理）。希望知识体系利用现有事实（PRD、代码仓库、历史 PR）自行运行：把每步推理链写入 Agent Doc，任务结束后进化 Agent 根据结果反推推理链，结合用户行为 Feedback 和 Bench Checklist 识别差异并更新 Agent Doc，再 A/B 测试后重载。解决三问题：知识图可版本对比、知识飞轮可量化、Agent 可平滑自主进化。

评测要分层，成本要按成功任务算：

最外层结果评测：业务任务是否真完成；
中间层轨迹评测：选对工具没、有没有重复执行副作用、该停的地方请求确认没、出错后恢复没——最易被忽略，结果正确但轨迹不合格很常见（绕二十步、重复提交、本该请求确认却直接改），只按成功率统计会把运气当能力；
最内层组件评测：单独测某个 Prompt/路由/工具/验证器。

失败要分类（模型、路由、工具、状态、控制、交付），每类有严重度、代表性轨迹和修复动作。分类分布变化本身就是指标：把工具参数类失败从两成降到几个点，比总分涨几个点更有说服力。

成本口径：不关注单次聪明回答，而看可预测的成功率、延迟、治理能力和单位任务成本。一个便宜配置若需重试三次再由人改一遍，其实并不便宜。

9. 从 Agent App 到 Swarm OS 的全景架构

最上层：Agent App 开发与交付，基础是 Skill（最原子能力单元，由 Markdown/CLI/函数计算实现，函数计算挂载沙箱）；
第二层：Agent Manager，定义方式从 Code 转向 Markdown 和可进化 Agent Doc，知识从传统 RAG 转向业务本体和推理链；
再往下：建设中的 Agent Swarm，核心解决面对共同上下文、不同人格专家 Agent 的处理，增加更符合"任务 + 多人 + 群体智能协作"推进的故事；
底层：被沙箱隔离的执行单元，每个 Agent 在自己沙箱运行，但访问统一 Memory 和 Workspace。

10. Vibe Working

在 Vibe Working 工作方式下，人的角色变化：设计师不再把精力花在制作比较大量方案上，而是判断哪个方案真正正确；业务专家通过一条 IM 消息被 AI 邀请参与 Review，提供思路、判断和品味；基础架构团队需建设 Agent Doc、Human in the Loop 机制、上下文数据和企业品味。

AI 时代，产品拼有价值的品味判断，技术则拼如何把问题定义得更清楚、实验更严谨、系统更可复现、失败更可解释的保障 AI 项目落地。

工程视角点评：这篇文章对前端/工程化背景的读者有较高参考价值。核心洞察在于"模型决定能力上限，工程控制面决定能不能进生产"——这与前端工程化的长期经验一致：框架选型不是终点，构建/校验/CI/权限边界才是生产可用的关键。Muse 把"上工程（需求-设计共创）"与"下工程（代码落地）"串成同一上下文链路的思路，对解决 AI 生成代码与既有工程体系脱节有启发性。文中对多 Agent 架构的批判性判断（只在子任务独立、可并行、上下文能分离时才有收益；需记录重复工作率/冲突率/汇总失败率而非只看成功率）尤其务实。删除实验（删掉某类上下文看成功率是否真下降）是 Context Engineering 的关键方法论，值得在实际 RAG/Agent 项目中推行。