作者｜郑鑫祺

审校｜李忠良

AI 写代码已经足够快，但从需求提出到生产上线，企业研发未必因此更快。设计规范、工程资产、跨仓上下文、安全检查和协作断点，常常会把编码阶段节省的时间重新消耗掉。如何让一个“会生成代码”的模型，成为真正能够交付、兜底和恢复的研发系统，正是 AI Coding 进入企业场景后必须解决的问题。

在 AICon 全球人工智能开发与应用大会上，小红书 AI Coding 总架构师郑鑫祺以 Vibe Coding 平台 Muse 和 AI Coding 实践为例，分享了小红书对这一问题的实践。Muse 不只是一个代码生成工具，而是试图打通需求共创、设计、编码与交付，让产品经理、设计师和开发者在同一条上下文链路中与 AI 协作。

围绕“高可用”与“人机共创”，郑鑫祺重点拆解了 Muse 的 Agent Team 编排、Harness 控制机制、企业知识工程与 Agent OS 架构，并进一步讨论：面对持续增强的模型，系统如何兼顾精度与泛化，以及人的角色如何从具体实现转向更有价值的判断、监督与品味。

以下为郑鑫祺演讲内容，经整理。

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

这次分享主要围绕两个关键词展开：高可用与人机共创。

高可用意味着，系统不仅能借助大模型解决局部问题，还必须具备稳定的交付、兜底和恢复能力。毕竟，大模型本质上仍是概率模型。如果系统只能完成演示，却无法进入真实生产环境，就不能称为高可用。

所谓人机共创，也不是简单地把工作交给 AI，而是人与 AI 共同讨论、持续判断，并将想法转化为最终产品。

2015 年毕业后，我曾在 Facebook 参与原型交互工具 Origami 的开发。当时我关注的问题是，如何把头脑中的想象快速转化为可见、可操作的原型。但原型完成后，新的问题随之出现：如何将它真正落到代码工程中？

从小型项目、创业公司业务，到大厂内部的复杂系统，不同规模的工程面临着不同约束。此后的近十年里，我一直在思考：从产品原型到复杂系统，人应该如何与工程协同？又该如何通过工程建模和架构设计，让不同开发者和团队保持高效、有序的长期迭代？

过去，这些工程约束主要面向开发者和研发团队。2024 年年中，我们开始意识到，AI 的快速发展将同时改变单点模块的实现方式和完整研发流程。此前积累的问题开始与 AI Coding 产生交汇：AI 时代需要被重新定义的，不只是 Coding，而是整个研发过程。

目前，我在小红书负责 AI Coding 大专项及相关产品矩阵。Muse 是其中具有代表性的 Vibe Coding 产品，也是本次分享的重点。

一个值得关注的现象是，尽管 AI 大幅提高了代码生成速度，需求从提出到上线的周期却未必同步缩短。来自团队内部及小红书更大范围的反馈显示：AI 写得很快，但研发人员并没有因此明显变得更轻松。

代码生成只是研发链路的一部分。AI 生成的代码可能不符合公司设计规范；界面看似正常，进入生产环境后却暴露出安全问题；代码虽然能够运行，却不满足现有代码仓库和工程体系的要求。节省下来的编码时间，最终又被消耗在检查、提测、修复、反复沟通，甚至推翻重做上。

与此同时，助理型 Agent 的出现也提高了用户预期。人们希望通过少量沟通就能让 AI 理解意图并执行不同任务，而不是每次都要按照固定格式编写复杂的 Prompt。

归根结底，当前企业级 AI Coding 主要面临三类问题：

1. AI 不了解企业资产，生成结果难以满足研发和设计规范。

2. 用户记忆、业务知识与任务上下文分散在不同平台，AI 无法形成完整理解。

3. 从需求到交付的能力链路尚未贯通。即使系统具备大量原子化 Skill 和工具，这些能力也可能相互冲突，难以形成稳定协作。

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

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

传统工作方式下，产品经理通常使用文字描述需求。但在 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 串成一条主线，使上下文能够沿着整个链路持续流动。

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

Muse 的核心技术能力可以分成两个方向。

第一个方向是 Dev Agent。无论前面如何讨论需求，系统最终必须生成符合研发规范的代码。这里涉及 Spec 质量、企业知识理解，以及复杂代码仓库带来的上下文问题。

过去面向人设计的工程体系中，存在大量复杂甚至过度的微服务拆分。进入 Agentic 系统以后，我们更强调 One Context、One Workspace：无论信息散落在多少微服务和代码仓库中，Agent 都需要把与任务相关的 Context 汇集起来。

尤其在服务端系统中，一个任务经常涉及多个仓库。如何让跨仓信息在一个 Workspace 中被正确理解，是 Dev Agent 必须解决的问题。

第二个方向是 AI Native 的对话和共创体验。随着助理型 Agent 出现，用户期待的不再是指令式交互，而是具有“助理感”的沟通方式：它看起来什么都能处理，同时又能在某类长任务上表现得特别好。

人机共创与数字人是两个不同的技术方向。共创的核心不只在于效率，也在于意义感。用户的品味能够被 AI 快速吸收，AI 给出的建议也能立即反映到作品中。这要求 Chat、Artifacts 和 Editor 三位一体，共享同一个 Context，而不能分别成为三个割裂的功能。

综合来看，我们需要解决三类挑战：

• 懂业务、能动手。Agent 必须理解企业知识，生成高精度产物，而不是要求用户每次都把企业规范写进 Prompt 或 Query。

• 在人机协作中保持任务主线。模型通常被训练为优先完成用户的即时指令，但共创过程中还存在一条持续的任务线。用户的一次修改不能把整个任务带偏。

• 保持长任务的连续性。系统需要把确定性的业务诉求与概率性的模型输出包装在一起，使任务可以检查、恢复并持续向前推进。Transformer 模型受到 Context Slot 和注意力机制的影响，因此模型控制不可避免，Harness 仍然是必要的。随着模型能力增强，过去由程序承担的策划和控制可以逐渐减少，但多 Agent 编排以及对单个 Agent 的精细化 Hook 干预仍然有价值。

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

模型控制架构的演进，大致呈现出 Workflow、Pipeline 和 Agent Team 三种形态。

Workflow 强调确定性控制。2025 年前后的模型在长任务中具有较高的幻觉率，系统通常将任务拆分为对焦、增强、召回、出码等确定节点，并按照固定顺序执行。模型与用户交互较少，整体表现为输入与输出首尾相接的工作流。

Pipeline 进一步提升了任务分流与局部控制能力。随着 Sonnet 4.5、Sonnet 4.6 等模型的长任务遵循能力增强，系统可以根据用户输入选择不同子流程，并对不同精度要求的任务进行针对性编排。

划分节点仍然必要，因为模型的注意力难以同时覆盖大量混杂信息。我们采用类似“房间”的方式管理上下文：模型进入主题 A 时，只加载与该主题相关的 Skill、Tools 和 System Prompt，同时屏蔽无关内容，使其在局部任务中保持专注。

Pipeline 预先定义了任务可能经过的状态和通道。用户完成输入后，系统进入相应状态，模型据此判断下一步任务以及可调用的能力，从而保障垂直链路的高可用。

Agent Team 则让原本固定的编排更加动态。随着模型能力增强，用户可能只需描述清楚一个 Story，系统便能在更高层完成任务规划与 Agent 调度。Agent 之间也不再是简单的平铺关系：一个设计 Agent 下可以继续编排多个子 Agent，形成嵌套式协作结构。

Workflow、Pipeline 和 Agent Team 并非相互替代，而是可以并存。确定性要求较高的任务仍适合 Workflow 或 Pipeline；需要更强泛化能力的场景，则可以逐步引入 Agent Team。Muse 也遵循这一思路：通过 Agent Team 扩展泛化能力，同时在高精度关键链路中保留必要的确定性控制。

Agent Team 也会带来只有在这种结构下才出现的失败：几个子 Agent 重复做同一件事，或者在汇总阶段把彼此矛盾的结论拼在一起。

我的判断是，多 Agent 只在子任务确实独立、可以并行、上下文能够分离的时候才有收益。如果几个 Agent 需要竞争写同一份可变资源，或者整条推理必须严格串行，它通常不如一条编排清晰的 Pipeline。所以在评测多 Agent 结构时，除了成功率，我们还会记录重复工作率、冲突率和汇总失败率等过程指标。

需要作为变量对待的维度是工具的调用方式。需要语义判断、必须保留原始引用、或者会产生副作用的动作，适合让模型一步一步来；如果需要控制流的可以专门做预先确定、工具返回体又很大的阶段。这更适合让模型生成一段代码，最后只把小的结构化结果带回上下文。

这件事的本质是把一些重度消耗 Token 编排搬到明确代码里而不是冗余

业界长期存在一项争论：系统应当追求 More Intelligence，还是强化 More Steering？其本质是如何界定对 AI 能力的信任程度，以及应当授予 AI 多大的自主权限。

在 Muse 中，Chat、Artifacts 与 Editor 共享同一套上下文，三者需要保持协同。因此，系统必须对 AI 的部分行为施加约束：用户的临时指令不能随意改变既定任务，最终产物也不能偏离企业设计规范。基于这一要求，Model Steering 与企业知识约束仍然不可或缺。

与此同时，模型的 Intelligence 会持续增强，系统架构不能以当前模型的能力边界作为长期不变的前提。

其实模型决定能力上限，工程控制面决定它能不能进入生产。这两句话并不矛盾，前一句要求架构保持模型可替换，不把某一代模型的脾气写进系统；后一句要求主要的工程投入落在任务数据、运行时控制、验证器和权限边界上，而不是落在对某一代模型的适配技巧上。

我们的基本原则是：Agent OS 优先，Context Engineering 与工程护航负责增强。

Agent OS 首先承接用户提出的开放性问题，并尽可能依靠模型自身能力完成任务。对于实践中暴露出的能力缺口，系统再以增量补丁的方式加入护航意图，并对任务结果执行 Check。命中 Bad Case 后，则根据具体问题继续增强相应的控制机制。

Agent OS 与工程护航共享同一个 Context，包括记忆、知识和自进化结果。随着模型能力提升，我们会通过持续评测，判断某类固定意图是否仍需程序化控制。模型已经能够稳定处理的部分，可以逐步减少工程干预；企业场景中必须保持确定性的部分，则继续通过工程机制增强，直至达到高可用标准。

对于单个 Agent 节点，我们会在其完整生命周期中设置 Hook。

Agent 进入任务时，可能是由另一个 Agent 编排调用。系统首先检查当前 Context 是否完整，并判断是否需要与用户交互、是否需要进入 Human in the Loop，以及是否需要调整上下文。这一过程相当于提前布置 Agent 即将进入的“房间”，确保当前上下文与任务匹配。

Agent 开始运行后，系统会检查每一次 Turn，并判断是否需要进一步 Verify。相关检查分为框架级和业务级两个层面：框架级规则用于防止工具调用混乱或执行路径偏移；业务级规则则负责约束特定场景下的任务行为。

例如，某些业务场景并不要求模型一味迎合用户，而是要求它始终沿着既定任务目标推进。如果用户的临时要求可能导致任务偏离，系统就需要拦截相应行为，并重新进行 Harness 编排。

这些检查还要放在不同的位置上，而不是集中在一处。请求进入模型之前拦住不该执行的内容，结果离开系统之前做一次校验，工具的参数和返回值在本地校验，真正会产生副作用的动作之前暂停等人确认——这四类检查解决的是不同的问题，把它们合并成一个“是否允许 Agent 执行”的开关，就会同时漏掉好几种失败。权限的控制单位也不是一个开关，而是主体、动作、资源、参数和时间窗口的组合。

写操作还需要额外一层保护。我们要求每一个会产生副作用的动作都带幂等键，并留下一份副作用日志：谁批准的，批准的是哪一组参数，作用在哪个资源的哪个版本上，执行结果是什么，能不能回滚。有了这份日志，“同一个操作被执行了两次”才有可能被发现，也才谈得上恢复。工具返回成功也不等于业务完成，这两件事必须分开判断。

人工确认之后要从同一个任务状态继续，而不是把它当成一次新的对话重新开始。审批可能隔几个小时才回来，这些时间里状态必须能被安全地保存下来。

任务结束后，系统还要处理上下文压缩、记忆沉淀和任务交接：哪些信息需要保存为记忆，哪些内容应当压缩，以及哪些上下文需要传递给下一个 Agent，都必须在这一阶段完成。

以 Muse 为例，如果用户要求将某个符合规范的红色元素改为蓝色，而该蓝色不符合企业设计规范，系统就可能拦截这一修改，或要求重新调整方案。仅将组件库和设计规则写入 System Prompt 通常不足以解决问题，因为模型天然倾向于优先遵循用户最新提出的指令。

因此，我们希望通过可验证的程序化护航，取代“把规则写进 Prompt，然后祈祷模型一定记得”。

精度经常会带来泛化能力下降。系统针对当前场景控制得越细，面对新需求时，迭代速度就可能越慢。

为同时满足精度与泛化，我们要求单个节点保持可控制，同时允许节点之间通过 Agent Team 动态编排。Muse 接到任务后，可以由 Orchestrator 调度不同 Agent，例如图片增强 Agent、Figma Agent、PRD Agent 和代码生成 Agent。

Agent 的入口也不能只局限于 Web UI。Muse 可以出现在 IM 中，也可以作为 CLI 能力或其他程序的组成部分。它只是整个研发体系的一环，因此要以 Agent 的形态被不同客户端消费。

Figma Agent 是一个典型例子。大型设计稿可能包含十几个 Frame，甚至几十、上百个面板。如果把所有内容一次性交给模型，很容易直接超过上下文上限。单纯压缩信息也无法解决问题，因为模型仍然需要理解页面、组件和它们之间的关系。

这时必须使用传统的分治思想。系统先查看 Frame，再识别页面和组件，将巨型任务拆成可以执行的子任务，并生成 DAG 执行清单。不同 Worker 分别完成开发任务，随后经过 Check 和 Verify；通过检查的结果再进入 Merge。

在这种结构中，子 Agent 不只是承担某种固定职能，也可以针对一个复杂任务被编排成更细粒度的执行体系。每一步的状态、检查标准和反馈都被显式记录，形成可以恢复的状态文件，任务因此能够一步步向前推进。

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

上下文压缩可以解决窗口和成本问题，但它并不保证保留业务上必须精确审计的那几个字段。对我们来说，Patch 内容、测试结果、审批人和资源版本必须落在结构化系统里，而不只存在于一段被压缩过的上下文里。

渐渐我们就从最初 chatbot 分发处理逻辑渐渐转化成如何构建一个好的 Agent Runtime，关注校验驱动的链路是否闭环：

目标 -> 上下文 -> 计划 -> 工具执行 -> 状态更新 -> 验证 -> 审批 -> 可编辑交付物（版本化）。因为如果丢失某些状态、验证或权限边界，再强的模型上来也只是一个会用各种能力的 Demo，无法建立商业价值。

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

从底层架构看，AI 应用也经历了明显演进。

2024 年，AI 更多面向单个模块。应用程序只需要调用模型，就能快速把某项能力加入现有系统。

2025 年，随着 Agent 的工具调用和自主执行能力增强，越来越多 Agent 被运行在微服务和 Pod 中，作为 Agentic 系统的一部分。

到 2026 年，我们的整体思路进一步向“数字人”靠近。模型的单步决策能力增强后，Agent 可以直接面向流量。例如，用户从 IM 进入系统，请求先到 Agent OS；系统再挂载与当前意图相关的记忆、用户信息和 Skill，由 Agent 运行完整任务。

这并不意味着 Agent OS 是万能的。对于 Muse 这样的场景，Agent OS 可以在前面提供助理型体验，持续接收用户要求并动态加载 Skill；但当任务进入某些高精度意图时，仍然要切换到特化链路，由程序接管和优化。

Agent OS 背后包含几个重要部分。

首先是自研 Agent Framework。我们没有完全沿用业界现成体系，是因为希望更细粒度地控制 Context 的变化，并使框架能够跟随 Agent OS 的发展持续演进；

其次是运行环境。直接把 Bash 命令开放给 AI 显然存在风险，因此需要一套完整的沙箱体系。不同任务需要不同沙箱：有些是 Skill 查询一类的短任务；有些是需要运行 Dev Server 的长任务；还有一些 Native Client 无法直接运行在云端，需要本地驱动和端侧环境。

这些环境扩展了 Agent 调用 Skill 的能力，但我们不希望它们再次演变成上下文彼此割裂的微服务。因此，底层还需要统一的 Memory Workspace。

Memory Workspace 类似中心化云盘，可以把不同沙箱挂载到同一个 Workspace 中，同时加载 Policy、Strategy 和 Fact 等多层知识。无论上层采用泛化 Agent 还是特化 Agent，都能围绕 One Workspace使用同一份上下文。

除了执行隔离，企业环境里还有几个平面需要一起设计：身份与角色、数据域，以及操作审计，这个尤其在我们的数字人计划中很明显。审计这一面经常被放到最后，但它往往决定系统能不能被真正批准上线——每一次工具调用、每一次审批、每一个产物版本和每一次策略判断都要留痕，所以我们做了 datahub 很细节的载入每个阶段的数据追踪。合规也不是打开某一个开关就成立的，它是模型、工具、第三方服务、缓存、日志和连接器共同构成的端到端属性。

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

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

AI Native 对话体验的基础，是系统究竟向模型注入了什么。一个完整 Context 通常包括 System Prompt、Memory、Tools 和 Knowledge。只有这些信息被正确组织，Agent 才能按照用户习惯和业务要求工作。

用户画像也是其中的重要部分。我们会使用另一个模型持续收集和整理用户信息，再将其拆分成字段存入数据库。这样，无论用户从 Web UI、IM 还是其他程序进入，Agent 都能保持相对一致的理解。

基于此，我们提出 Agent App 的概念。一个 Agent App 可以包含个性化信息、知识、Skill、编排和自进化能力。过去，应用主要由 Code 定义；未来，其中相当一部分可能由 Markdown 和可演进的 Agent Doc 定义。

Agent App 可以运行在 Chat Gateway 之后，被嵌入企业已有的各种工作流。这一点非常重要，因为未来 AI 不会只存在于单一产品页面中，而会出现在 IM、CLI 和不同业务系统里。

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

回到 Dev Agent，一个值得反思的问题是：使用 Claude Code 或其他 Code Agent 后，研发时间真的节省了吗？还是原来写代码的时间，变成了写 Spec 的时间？

如果工程师要花两个小时准备 Spec，AI Coding 的价值就会被明显削弱。

解决这个问题的关键，是获取高质量上下文。它包括两个方向：

一是理解上工程。Muse 产出的原型、PRD 和共创记录，可以提供相当一部分需求上下文。

二是理解下工程。Agent 需要掌握企业知识，而这些知识可能来自代码仓库、历史 PR，也可能来自完整的测试流程。

过度微服务化的问题很难立即消除，但我们至少可以先解决 Context 的聚合问题：代码可以分散在不同仓库，相关上下文必须能够被挂载到同一个地方。

理想状态类似 Cursor Plan：Agent 只在关键节点向用户提问，用户简单检查一下 Plan，就可以让任务继续执行。对于打磨成熟的场景，任务甚至可以在云端并发运行，用户只需要通过手机提供少量关键输入。

要接近这种状态，就必须减轻 Spec 负担，提高 Spec 质量，减少人与 Agent 的对话轮数。其核心仍然是企业知识。企业知识的使用方式也经历了几个阶段。

2024 年，许多 Agent 平台要求用户上传知识库文档，底层通常通过 Embedding 和 RAG 检索相关内容。这种方式可以快速召回语义相近的信息，并加入模型上下文。但后续实践中，我们发现传统 RAG 很难 Debug：为什么召回这段内容？怎样量化回答质量？知识如何自进化？这些问题都很难回答。知识经过模糊匹配以后，也缺少完整的追溯链。

到 2025 年，行业开始更多地探索知识图谱化。知识结构变得更清楚了，但如果上层依然使用片段化匹配，RAG 的核心问题并没有真正改变，系统仍然难以度量一个判断是如何产生的。数字人和 Agent Team 的思路提供了新的方向：我们可以分配不同专家，对知识图进行更深入的探索。

在我看来，Harness 的一个核心问题就是：能否在正确的时间，把正确的知识交给正确的 Agent。

准确的知识并不是简单检索出来的。它更像一次 Research：代码专家和知识专家分别进行分析，再通过推理链相互补充，最终形成判断。这个判断可以反向追溯到每一步思考和原始 Doc，也可以据此持续优化。

要让这件事可以度量，知识就不能只是一段被检索出来的文本。我们要求每一条进入上下文的证据都带上来源、时间、归属和权限信息；召回之后要经过重排、去重和压缩，而不是把全文无差别地塞进去；来自网页、工具返回和外部文档的内容一律当作不可信输入，它们不能改写系统本身的规则。

更关键的是要做一些删除实验：把某一类上下文去掉，看成功率是否真的下降。在 muse 和 aicoding 系统建设中，很多我们以为有用的上下文，删掉之后指标没有变化，那它就只是在消耗窗口和成本。可以量化的指标包括召回率、引用准确率、过期信息被误用的比例，以及每个成功任务实际消耗的输入 Token。

换个说法，Context Engineering 更接近一条需要被观测的数据供应链，而不是“怎么把 Prompt 写得更漂亮”。这里的检索质量、权限边界、时间新鲜度和压缩策略，比无限扩大上下文窗口更重要。

我们正在实践的方式，是围绕业务本体建立认知结构，并通过 Agent Team 仿真人类专家的推理过程。专家面对问题时，通常会先阅读一部分资料、记录笔记，再根据新线索展开调查，最后逐步形成认知。

代码理解也是如此。Agent 不一定一开始就阅读所有源代码，它可能先查看已经整理好的 Wiki 或知识图；出现问题后，再沿着线索回到代码和历史记录，判断推理链的哪一步发生了偏差。

当任务同时涉及前后端代码时，还需要解决 One Workspace 问题，把相关仓库挂载到同一个空间。前端 Code Graph 也有一些特殊场景，需要单独处理。

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

企业知识维护一直非常困难，尤其对于 Infra 团队。基础架构团队未必理解所有业务，而业务团队也不可能持续花大量时间整理和更新知识。

因此，我们希望知识体系能够利用现有事实自行运行。PRD、代码仓库和历史 PR 都是已经存在的 Fact，系统应该从这些原始信息中持续提炼知识，而不是要求人重复编写文档。

具体来说，我们会把每一步推理链写入 Agent Doc，使知识按模块组织。任务运行结束后，进化 Agent 可以根据结果反推推理链。

第一次运行的效果可能并不好，但系统能够看到用户最终是否采纳结果。用户行为构成了环境 Feedback。我们还建立了一个 Bench，以 Checklist 的方式检查知识要点是否被覆盖。如果某个要点没有被提到，系统就能识别当前知识与理想结果之间的差异，并据此更新 Agent Doc。更新后再进行 A/B 测试；确认效果更好后，重新加载新的 Agent Doc。

这套机制要解决三个核心问题：

• 知识图能够进行版本对比；

• 知识飞轮能够被量化；

• Agent 能够平滑、自主地完成进化。

评测要分层，成本要按成功任务算，评测本身也需要分层。

最外层是结果评测，看业务任务是否真的完成；中间一层是轨迹评测，看它有没有选对工具、有没有重复执行副作用、有没有在该停下来的地方请求确认、出错之后有没有恢复；最里面一层是组件评测，单独测某个 Prompt、某个路由、某个工具或某个验证器。

这三层缺一层都会出问题，最容易被忽略的是中间那层。最终结果正确但轨迹并不合格的情况非常常见：它可能绕了二十步，可能重复提交了两次，也可能在一个本该请求确认的地方直接改了。这类结果如果只按成功率统计，会被记成一次成功，于是我们就把运气当成了能力。

同样重要的是失败分类。如果只记录“失败了”，团队最后只会不停地改 Prompt。我们把失败分成模型、路由、工具、状态、控制和交付几类，每一类都要有严重度、代表性轨迹和明确的修复动作。分类分布的变化本身就是指标：把工具参数类的失败从两成降到几个点，比总分涨了几个点更有说服力，因为它有机制解释。

还有一个维度是成本口径，在做 AICoding 中我们的测评成本一开始占比非常高。

单看 Token 其实越来越美单价没有意义，应该看每一个成功任务的成本。分母是通过的任务数，分子要把重试、升级到更强配置、验证器本身的开销和人工返工都算进去。一个便宜的配置，如果需要重试三次再由人改一遍，其实它并不便宜哦。

我们其实并不关注某一次特别聪明的回答，而是可预测的成功率、延迟、治理能力和单位任务成本。

8从 Agent App 到 Swarm OS 的全景架构

从整体架构看，最上层是 Agent App 的开发与交付

Agent App 的基础是 Skill。Skill 是最原子的能力单元，可以由 Markdown、CLI 或函数计算实现。函数计算背后通常会挂载相应沙箱，从而让 Agent 安全地执行具体能力。

第二层是 Agent Manager。Agent 的定义方式持续变化：过去更多使用 Code，随后逐渐转向 Markdown 和可进化的 Agent Doc。知识体系也在变化，从传统 RAG 逐步转向业务本体和推理链。

再往下是正在建设的 Agent Swarm，核心解决面对共同上下文，不同人格专家 Agent 的处理，他不只是 agent team 模式的单任务编排精度，会增加更符合任务+多人+群体智能协作推进的故事，是智能协作项目中的核心。

底层则是被沙箱隔离的执行单元。每个 Agent 在自己的沙箱中运行，但又能访问统一的 Memory 和 Workspace。这样既能满足安全和隔离要求，也不会让上下文重新碎片化。

9Vibe Working

在 Vibe Working 的工作方式下，人的角色会发生变化。

过去，业务开发者、产品经理、设计师和业务专家需要亲自完成大量实现工作。未来，我们更希望人专注于关键判断和监督。

设计师不再把主要精力花在制作和比较大量方案上，而是判断哪个方案真正正确。业务专家可能通过一条 IM 消息被 AI 邀请参与 Review，向 Agent 提供自己的思路、判断，以及更重要的品味。

对于基础架构团队而言，需要建设的是 Agent Doc、Human in the Loop 机制，以及不同场景下的上下文数据和企业品味。我们可以在 Agent OS 上搭建不同 Agent Team，形成“数字军团”，并对每个关键节点进行精细化处理。

一个个垂直应用则以 Agent App 的方式存在，并共享统一的记忆。这样，无论应用运行在 Web UI、IM 还是其他系统中，都可以沿着同一条上下文主线协作。

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

关于我们团队：