AI 写得飞快，交付却没变快：小红书 Muse 与 One Context
原文：AI 写代码飞快，为何交付没有变快？小红书 Muse 的 Agentic 架构实践
作者：郑鑫祺（小红书 AI Coding 总架构师）· InfoQ / AICon 整理
核心观点
AI 写代码已经够快，但从需求到上线未必更快。省下的编码时间，常被设计规范、工程资产、跨仓上下文、安全检查和跨角色沟通重新吃掉。
小红书 Muse 的回答不是「再塞一个 Code Agent」，而是把需求共创、设计与研发放进同一条上下文主线：Agent Team 编排 + Agent OS 运行时 + Harness 护航，让人机共创可交付、可恢复，而不只是演示好看。
我方补一句终局判断：
未来要打破产品、研发、测试之间的沟通成本，把它们放在同一个上下文里；从信息流角度看，这比角色分栏更高效。
为什么「写得快」不等于「交得快」
演讲里企业级 AI Coding 被压成三类断点：
- 不懂企业资产 —— 生成物不符合设计/研发规范
- 上下文碎片化 —— 记忆、业务知识、任务状态散在多平台
- 能力链路未贯通 —— Skill/工具很多，却互相冲突，形不成稳定协作
助理型 Agent 还抬高了预期：用户希望少说话就能办事，而不是每次写一套复杂 Prompt。结果是：格子里每个工具都更快，端到端却仍卡在检查、提测、修复和反复对齐。
Muse：上工程与下工程共创
传统路径：文字 PRD → 开会解释 → 设计比稿 → 再进仓库。AI 时代更需要的是：一次产出多方案、能跑的实验、符合企业规范的高保真原型，并且下游能直接接着用。
Muse 把工作拆成：
| 阶段 | 做什么 |
|---|---|
| 上工程 | 需求形成前：数据/BI、方案比较、Demo、PRD |
| 下工程 | 真实仓库：Dev Agent 出规范代码、预览、交付 |
理想体验：IM 丢一个 Idea → 共创面板出企业风格原型 → 另一个 Agent 延续同一上下文 做工程落地。Chat、Artifacts、Editor 三位一体，共享 Context，而不是三个割裂功能。
底层口号很硬：One Context / One Workspace——服务再微服务化，任务相关上下文必须汇到一处。
Workflow → Pipeline → Agent Team
模型控制面大致三态，且可并存：
- Workflow：确定性节点串行，适合幻觉高、必须兜底的阶段
- Pipeline：按输入分流；「房间」式上下文——进主题 A 只加载相关 Skill/Tools/Prompt
- Agent Team：更高层 Story 规划与嵌套调度，泛化更强，但也带来重复劳动、冲突结论硬拼
评测不能只看成功率，还要记重复工作率、冲突率、汇总失败率。多 Agent 只在子任务真独立、可并行、上下文可分离时划算；争写同一可变资源时，清晰 Pipeline 往往更稳。
业界那句争论——More Intelligence 还是 More Steering——在 Muse 里落成原则：Agent OS 优先，Context Engineering 与工程护航做增量补丁。模型决定能力上限；工程控制面决定能不能进生产。这两句并不矛盾。
Harness：可验证，别靠祈祷
把规则塞进 System Prompt，通常挡不住「用户最新一句指令」的优先级。需要程序化护航：
- 生命周期 Hook：进任务前布置「房间」、是否 HITL；每 Turn 做框架级/业务级 Verify
- 检查分置：入模前拦、出系统前验、工具参数本地验、副作用前暂停确认
- 写操作：幂等键 + 副作用日志（谁批、参数、资源版本、结果、可否回滚）
- 别把对话 Transcript 当运行状态；结构化保存目标、约束、计划版本、步骤、证据、审批与预算
知识侧也从「上传文档 + RAG」推进到：业务本体、专家式 Research、证据带来源/时间/权限，并用删除实验量化哪些上下文真有用。金句值得单独记：
能否在正确的时间，把正确的知识交给正确的 Agent。
人的角色：判断、监督、品味
Vibe Working 下，设计师少「搓方案」、多判哪个对；业务专家可能被 IM 拉进 Review，贡献的是思路与品味。Infra 侧要建的是 Agent Doc、Human-in-the-loop，以及可复用的企业品味数据——而不是无限堆插件。
这和「通才更值钱、评审成新瓶颈」的 EPD 讨论同向：实现变便宜后，对齐与判断才是稀缺带宽。参见 编程 Agent 如何重塑工程、产品和设计。
我方观点：信息流优先于角色分栏
社区常把问题说成「要不要多招测试 / 要不要 PM 会写代码」。更干净的切法是信息流：
- 交付慢，多半是跨角色翻译税 —— 同一意图在 PRD、设计稿、工单、测试用例里被抄四遍、丢四次。
- One Context 不是取消分工 —— 是取消「每个格子各塞一份失真摘要」；产品、研发、测试可以仍是不同 Agent/人，但挂在同一任务状态上。
- 测试不该另开断裂工单流 —— 验证器、副作用日志、审批恢复，应是同一 Runtime 的节点，而不是事后贴标签。
- 小团队创业含义 —— 少做「又一个助手插件」；多做共享任务状态、企业知识飞轮、可恢复 Harness。这与 意外黑板、控制论式 Harness 同向。
从信息流看：带宽浪费在交接面，不在键盘敲击速度。把产品、研发、测试压进同一上下文，不是口号，是把翻译税改成可观测的状态机。
决策清单
- 你们省下的编码时间，耗在规范检查还是跨角色对齐？先修哪条。
- Chat / 产物 / 编辑器是否已共享同一 Context？没有就先打通，别先加 Agent 数量。
- 多 Agent 是否真可并行且上下文可分离？否则 Pipeline 更稳。
- 评测是否分层（结果 / 轨迹 / 组件）？只看成功率会把运气当能力。
- 成本是否按成功任务全成本（重试、升级模型、人工返工）算？
编码变快只是入场券；上下文不断、状态可恢复、跨角色零翻译，交付才会跟着变快。
评论