AI写代码快却交付慢？小红书Muse破局
当前AI代码生成工具已经能大幅提升单步编码效率，但对于企业研发全流程来说，从需求提出到生产上线的整体周期却未必同步缩短。设计规范匹配、跨仓库上下文管理、安全合规检查以及团队协作断点，常常会把编码阶段节省的时间重新消耗掉。如何让具备代码生成能力的AI模型，真正成为可交付、可兜底、可恢复的企业级研发系统，正是AI Coding落地企业场景必须解决的核心问题。
在行业技术交流活动中，相关团队的技术负责人以Vibe Coding平台和相关AI Coding实践为例，分享了企业在这一领域的探索。该平台并非单纯的代码生成工具，而是试图打通需求共创、原型设计、代码编写到最终交付的全链路，让产品经理、设计师和开发者能够在统一的上下文链路中与AI协同工作。本次分享围绕“高可用”与“人机共创”两个核心关键词展开。
高可用意味着系统不仅能借助大模型解决局部问题，还要具备稳定的交付、兜底和恢复能力——毕竟大模型本质是概率模型，若只能完成演示而无法进入真实生产环境，就不能称之为高可用的系统。而人机共创则不是简单地将工作交给AI，而是人与AI共同讨论、持续判断，将想法逐步转化为最终的可交付产品。
团队成员曾在早期参与原型工具的开发，当时关注的是如何将头脑中的想法快速转化为可见可操作的原型，但原型完成后，如何将其落地到真实的代码工程中又成为新的难题。从小型项目到大厂复杂系统，不同规模的工程都有各自的约束，近十年来团队一直在思考：从产品原型到复杂工程系统，人类应该如何与工程体系协同，又该如何通过工程建模和架构设计，让不同开发者和团队保持高效有序的长期迭代。
2024年年中团队意识到，AI的快速发展不仅改变了单点模块的实现方式，也重塑了完整的研发流程，此前积累的工程问题与AI Coding产生了交汇：AI时代需要被重新定义的，不只是编码环节，而是整个研发过程。
目前团队负责AI Coding大专项及相关产品矩阵，其中具有代表性的Vibe Coding产品Muse是本次分享的重点。尽管AI大幅提升了代码生成速度，需求从提出到上线的周期却未必同步缩短，来自团队内部及更广范围的反馈显示：AI写得很快，但研发人员并没有因此明显变得更轻松。
代码生成只是研发链路的一部分。AI生成的代码可能不符合公司设计规范；界面看似正常，进入生产环境后却暴露出安全问题；代码虽然能够运行，却不满足现有代码仓库和工程体系的要求。节省下来的编码时间，最终又被消耗在检查、提测、修复、反复沟通，甚至推翻重做上。与此同时，助理型Agent的出现也提高了用户预期，人们希望通过少量沟通就能让AI理解意图并执行不同任务，而不是每次都要按照固定格式编写复杂的提示词。
归根结底，当前企业级AI Coding主要面临三类问题：
- AI不了解企业资产，生成结果难以满足研发和设计规范。
- 用户记忆、业务知识与任务上下文分散在不同平台，AI无法形成完整理解。
- 从需求到交付的能力链路尚未贯通。即使系统具备大量原子化Skill和工具，这些能力也可能相互冲突，难以形成稳定协作。
因此，团队关心的不只是如何用AI快速实现一个想法，而是如何将其转化为具备商业价值、可进入企业生产环境的程序。
Muse：打通需求、设计与研发的共创空间
传统研发流程中，产品经理通常通过文字描述需求，先撰写PRD再通过会议向团队解释，这种方式会限制整个团队的响应速度。我们更需要的是快速产出多套方案，直接运行实验验证效果，需求产出的速度很大程度上取决于原型产出的速度，如果原型能够直接交给下游使用，整个协作链路才能真正提速。
设计工作也是如此，过去设计师需要花费大量时间制作方案和比稿，还要与开发者进行深入沟通，这些环节消耗的时间往往远超实际编码。过去的比稿依赖体力劳动，而AI时代的比稿更依赖判断力——当AI可以一次提供多个版本时，人类需要做的是判断哪个版本更合适，然后快速推进后续的版本迭代。
产品经理、设计师和开发者之间的协作方式也应该改变，过去需要线下开会、逐一解释，未来的理想体验是：在即时通讯工具中提出一个想法，团队直接进入共创面板，快速产出符合企业规范的高保真原型，研发接手后，再由另一个AI Agent延续上下文，完成后续的工程落地。
Muse正是基于这样的目标构建的，它生成的内容符合企业现有的设计风格和研发规范，用户在对话时可以保持开放自由的沟通，同时也可以在编辑区域中沉浸式修改作品。Muse生成的不是只能展示的静态页面，也不是需要二次转译的中间产物，而是以达到上线标准为目标、能够适配真实工程仓库的代码。
在整个研发体系中，我们把需求形成之前的工作称为“上工程”，进入真实代码仓库后的实现工作称为“下工程”。上工程需要收集不同角色的上下文，辅助团队做出决策，例如需求分析Agent可能与BI和数据系统交互，围绕业务目标形成需求判断，决策明确后，团队需要快速确认产品修改的范围和方式，并对比多个设计方案，Muse主要承载的就是这部分工作。
通过Muse场景，团队可以直接生成Demo和PRD，既可以用于内部汇报，也能为开发者提供更完整直观的需求上下文。进入真实研发阶段后，可能由项目管理Agent负责沟通协调，由开发Agent进入代码仓库完成落地，Muse自身也需要使用开发Agent的能力，因为它必须即时完成预览，并生成高质量、符合规范的代码。
过去的AI工具往往只是被嵌入研发流程的某个孤立环节，各个环节之间彼此断开，上下文无法传递，我们希望将需求共创、设计共创和编码环节串联成一条主线，让上下文能够沿着整个研发链路持续流动。
高可用人机共创面临的三类挑战
Muse的核心技术能力可以分为两个方向。第一个方向是开发Agent，无论前期如何讨论需求，系统最终必须生成符合研发规范的代码，这涉及到需求文档质量、企业知识理解以及复杂代码仓库带来的上下文问题。
过去面向人类设计的工程体系中，存在大量复杂甚至过度的微服务拆分，进入Agentic系统后，我们更强调One Context、One Workspace：无论信息分散在多少微服务和代码仓库中，Agent都需要将与任务相关的上下文汇集起来，尤其是在服务端系统中，一个任务经常涉及多个仓库，如何让跨仓库的信息在同一个工作区中被正确理解，是开发Agent必须解决的问题。
第二个方向是AI原生的对话和共创体验，随着助理型Agent的出现，用户期待的不再是指令式的交互，而是具备“助理感”的沟通方式：看起来可以处理多种任务，同时又能在特定长任务上表现出色。人机共创与数字人是两个不同的技术方向，共创的核心不仅在于效率，更在于意义感——用户的品味能够被AI快速吸收，AI给出的建议也能立即反映到作品中，这要求对话窗口、产出物和编辑器三者共享同一个上下文，不能成为三个割裂的功能。
综合来看，我们需要解决三类核心挑战：
- Agent需要懂业务、能动手，必须理解企业知识，生成高精度的产物，而不是要求用户每次都将企业规范写入提示词或查询语句。
- 在人机协作中保持任务主线，模型通常被训练为优先完成用户的即时指令，但共创过程中存在一条持续的任务线，用户的一次临时修改不能将整个任务带偏。
- 保持长任务的连续性，系统需要将确定性的业务诉求与概率性的模型输出结合起来，让任务可以被检查、恢复并持续推进。
Transformer模型受限于上下文窗口和注意力机制，因此模型控制仍然是必要的，随着模型能力增强，过去由程序承担的策划和控制工作可以逐渐减少，但多Agent编排以及对单个Agent的精细化Hook干预仍然具有价值。
从 Workflow 到 Agent Team：模型控制如何演进
模型控制架构的演进大致呈现出工作流、流水线和Agent团队三种形态。
Workflow 强调确定性控制。2025年前后的模型在长任务中具有较高的幻觉率，系统通常将任务拆分为对焦、增强、召回、出码等确定节点，并按照固定顺序执行，模型与用户的交互较少，整体表现为输入与输出首尾相接的工作流。
Pipeline 进一步提升了任务分流与局部控制能力。随着大模型长任务遵循能力的增强，系统可以根据用户输入选择不同的子流程，并对不同精度要求的任务进行针对性编排。划分节点仍然必要，因为模型的注意力难以同时覆盖大量混杂信息，我们采用类似“房间”的方式管理上下文：当模型进入主题A时，只加载与该主题相关的技能、工具和系统提示，同时屏蔽无关内容，让模型在局部任务中保持专注。
流水线预先定义了任务可能经过的状态和通道，用户完成输入后，系统进入相应状态，模型据此判断下一步任务和可调用的能力，从而保障垂直链路的高可用。
Agent Team 则让原本固定的编排更加动态。随着模型能力增强，用户可能只需描述清楚一个故事，系统就能在更高层完成任务规划和Agent调度，Agent之间也不再是简单的平铺关系：一个设计Agent下可以继续编排多个子Agent，形成嵌套式的协作结构。
工作流、流水线和Agent团队并非相互替代，而是可以并存的，确定性要求较高的任务仍然适合工作流或流水线；需要更强泛化能力的场景，则可以逐步引入Agent团队，Muse也遵循这一思路：通过Agent团队扩展泛化能力，同时在高精度的关键链路中保留必要的确定性控制。
Agent团队也会带来特有的失败问题：例如几个子Agent重复执行相同的任务，或者在汇总阶段将彼此矛盾的结论拼接在一起。我们的判断是，多Agent只在子任务确实独立、可以并行、上下文能够分离的时候才有收益，如果几个Agent需要竞争写入同一份可变资源，或者整条推理必须严格串行，它通常不如一条编排清晰的流水线。因此在评测多Agent结构时，除了成功率，我们还会记录重复工作率、冲突率和汇总失败率等过程指标。
需要作为变量对待的维度是工具的调用方式：需要语义判断、必须保留原始引用或者会产生副作用的动作，适合让模型一步一步执行；如果需要控制流的环节，可以预先确定规则，当工具返回体较大时，更适合让模型生成一段代码，最后只将小的结构化结果带回上下文。这件事的本质是将一些重度消耗Token的编排工作转移到明确的代码中，避免冗余消耗。
业界长期存在一项争论：系统应当追求更强的智能，还是强化更多的控制？其本质是如何界定对AI能力的信任程度，以及应当授予AI多大的自主权限。
在Muse中，对话窗口、产出物和编辑器共享同一套上下文，三者需要保持协同，因此系统必须对AI的部分行为施加约束：用户的临时指令不能随意改变既定任务，最终产物也不能偏离企业设计规范，基于这一要求，模型控制与企业知识约束仍然不可或缺。与此同时，模型的智能会持续增强，系统架构不能以当前模型的能力边界作为长期不变的前提。
模型决定能力上限，工程控制面决定它能否进入生产环境，这两句话并不矛盾：前一句要求架构保持模型可替换，不将某一代模型的特性写入系统；后一句要求主要的工程投入落在任务数据、运行时控制、验证器和权限边界上，而不是落在对某一代模型的适配技巧上。
我们的基本原则是：Agent OS 优先，Context Engineering 与工程护航负责增强。
Agent OS首先承接用户提出的开放性问题，并尽可能依靠模型自身能力完成任务，对于实践中暴露的能力缺口，系统再以增量补丁的方式加入护航意图，并对任务结果执行检查，命中不良案例后，则根据具体问题继续增强相应的控制机制。Agent OS与工程护航共享同一个上下文，包括记忆、知识和自进化结果，随着模型能力提升，我们会通过持续评测，判断某类固定意图是否仍需要程序化控制，模型已经能够稳定处理的部分，可以逐步减少工程干预；企业场景中必须保持确定性的部分，则继续通过工程机制增强，直至达到高可用标准。
对于单个Agent节点，我们会在其完整生命周期中设置钩子。Agent进入任务时，可能是由另一个Agent编排调用，系统首先检查当前上下文是否完整，并判断是否需要与用户交互、是否需要进入人工参与环节，以及是否需要调整上下文，这一过程相当于提前布置Agent即将进入的“房间”，确保当前上下文与任务匹配。
Agent开始运行后，系统会检查每一次交互，并判断是否需要进一步验证，相关检查分为框架级和业务级两个层面：框架级规则用于防止工具调用混乱或执行路径偏移；业务级规则则负责约束特定场景下的任务行为。例如，某些业务场景并不要求模型一味迎合用户，而是要求它始终沿着既定任务目标推进，如果用户的临时要求可能导致任务偏离，系统就需要拦截相应行为，并重新进行控制编排。
这些检查需要分布在不同的位置，而不是集中在一处：在请求进入模型之前拦截不该执行的内容，在结果离开系统之前做一次校验，在本地校验工具的参数和返回值，在真正会产生副作用的动作之前暂停等待人工确认——这四类检查解决的是不同的问题，将它们合并成一个“是否允许Agent执行”的开关，会同时漏掉好几种失败类型。权限的控制单位也不是一个简单的开关，而是主体、动作、资源、参数和时间窗口的组合。
写操作还需要额外一层保护，我们要求每一个会产生副作用的动作都带有幂等键，并留下一份副作用日志：谁批准的，批准的是哪一组参数，作用在哪个资源的哪个版本上，执行结果是什么，能否回滚。有了这份日志，“同一个操作被执行了两次”才有可能被发现，也才谈得上恢复。工具返回成功也不等于业务完成，这两件事必须分开判断。
人工确认之后要从同一个任务状态继续，而不是将其当成一次新的对话重新开始，审批可能间隔几个小时才返回，这段时间里状态必须能够被安全地保存下来。任务结束后，系统还要处理上下文压缩、记忆沉淀和任务交接：哪些信息需要保存为记忆，哪些内容应当压缩，以及哪些上下文需要传递给下一个Agent，都必须在这一阶段完成。
以Muse为例，如果用户要求将某个符合规范的红色元素改为蓝色，而该蓝色不符合企业设计规范，系统就可能拦截这一修改，或要求重新调整方案。仅将组件库和设计规则写入系统提示通常不足以解决问题，因为模型天然倾向于优先遵循用户最新提出的指令。因此，我们希望通过可验证的程序化护航，取代“把规则写进提示词，然后祈祷模型一定记得”的做法。
精度的提升经常会带来泛化能力的下降，系统针对当前场景控制得越细，面对新需求时的迭代速度就可能越慢。为同时满足精度与泛化要求，我们要求单个节点保持可控制，同时允许节点之间通过Agent团队动态编排。Muse接到任务后，可以由编排器调度不同的Agent，例如图片增强Agent、设计稿处理Agent、需求文档生成Agent和代码生成Agent。
Agent的入口也不能只局限于Web界面，Muse可以出现在即时通讯工具中，也可以作为命令行工具能力或其他程序的组成部分，它只是整个研发体系的一环，因此需要以Agent的形态被不同客户端消费。
设计稿处理Agent是一个典型例子，大型设计稿可能包含十几个甚至上百个面板，如果将所有内容一次性交给模型，很容易直接超过上下文上限，单纯压缩信息也无法解决问题，因为模型仍然需要理解页面、组件和它们之间的关系。这时必须使用传统的分治思想，系统先查看面板，再识别页面和组件，将巨型任务拆分为可以执行的子任务，并生成有向无环图执行清单，不同的工作者分别完成开发任务，随后经过检查和验证，通过检查的结果再进入合并环节。
在这种结构中，子Agent不只是承担某种固定职能，也可以针对一个复杂任务被编排为更细粒度的执行体系，每一步的状态、检查标准和反馈都被显式记录，形成可以恢复的状态文件，任务因此能够一步步向前推进。这里我们踩过一个坑：不要把对话记录当成运行状态，对话记录只是审计材料，并不适合用来恢复任务。真正需要结构化保存的是不可变的任务目标、用户约束、计划版本、已完成和待完成的步骤、工具证据、副作用日志、审批记录、产物、失败次数和剩余预算等。
上下文压缩可以解决窗口和成本问题，但它并不保证保留业务上必须精确审计的字段，对我们来说，补丁内容、测试结果、审批人和资源版本必须落在结构化系统里，而不只存在于一段被压缩过的上下文里。我们逐渐从最初的聊天机器人分发处理逻辑，转向如何构建一个优秀的Agent运行时，关注校验驱动的链路是否闭环：目标 -> 上下文 -> 计划 -> 工具执行 -> 状态更新 -> 验证 -> 审批 -> 可编辑交付物（版本化）。因为如果丢失某些状态、验证或权限边界，再强的模型也只是一个会使用各种能力的演示Demo，无法建立商业价值。
Agent OS：为 Agent 构建统一运行环境
从底层架构看，AI应用也经历了明显的演进。2024年，AI更多面向单个模块，应用程序只需要调用模型，就能快速将某项能力加入现有系统。2025年，随着Agent的工具调用和自主执行能力增强，越来越多Agent被运行在微服务和容器中，作为Agentic系统的一部分。到2026年，我们的整体思路进一步向“数字人”靠近，模型的单步决策能力增强后，Agent可以直接面向流量，例如用户从即时通讯工具进入系统，请求先到Agent OS，系统再挂载与当前意图相关的记忆、用户信息和技能，由Agent运行完整任务。
这并不意味着Agent OS是万能的，对于Muse这样的场景，Agent OS可以在前端提供助理型体验，持续接收用户要求并动态加载技能；但当任务进入某些高精度意图时，仍然要切换到特化链路，由程序接管和优化。
Agent OS背后包含几个重要部分：首先是自研Agent框架，我们没有完全沿用业界现成体系，因为希望更细粒度地控制上下文的变化，并使框架能够跟随Agent OS的发展持续演进；其次是运行环境，直接将命令行命令开放给AI显然存在风险，因此需要一套完整的沙箱体系，不同任务需要不同的沙箱：有些是技能查询一类的短任务，有些是需要运行开发服务器的长任务，还有一些原生客户端无法直接运行在云端，需要本地驱动和端侧环境。
这些环境扩展了Agent调用技能的能力，但我们不希望它们再次演变成上下文彼此割裂的微服务，因此底层还需要统一的记忆工作区。记忆工作区类似中心化云盘，可以将不同沙箱挂载到同一个工作区中，同时加载策略、策略和事实等多层知识，无论上层采用泛化Agent还是特化Agent，都能围绕同一个工作区使用同一份上下文。
除了执行隔离，企业环境里还有几个平面需要一起设计：身份与角色、数据域，以及操作审计，这在我们的数字人计划中尤为明显。审计环节经常被放到最后，但它往往决定系统能不能被真正批准上线——每一次工具调用、每一次审批、每一个产物版本和每一次策略判断都要留痕，所以我们在数据枢纽中做了每个阶段的详细数据追踪。合规也不是打开某一个开关就成立的，它是模型、工具、第三方服务、缓存、日志和连接器共同构成的端到端属性。在企业落地场景中，“权限可解释、状态可恢复、审计可追溯”往往比当前模型能力领先几个百分点更有价值。
Agent App：让能力进入既有工作流
AI原生的对话体验的基础，是系统究竟向模型注入了什么。一个完整的上下文通常包括系统提示、记忆、工具和知识，只有这些信息被正确组织，Agent才能按照用户习惯和业务要求工作。用户画像也是其中的重要部分，我们会使用另一个模型持续收集和整理用户信息，再将其拆分成字段存入数据库，这样，无论用户从Web界面、即时通讯工具还是其他程序进入，Agent都能保持相对一致的理解。
基于此，我们提出Agent App的概念，一个Agent App可以包含个性化信息、知识、技能、编排和自进化能力。过去，应用主要由代码定义；未来，其中相当一部分可能由Markdown和可演进的Agent文档定义。Agent App可以运行在聊天网关之后，被嵌入企业已有的各种工作流，这一点非常重要，因为未来AI不会只存在于单一产品页面中，而会出现在即时通讯工具、命令行和不同业务系统里。
能否在正确的时间，把正确的知识交给正确的 Agent
回到开发Agent，一个值得反思的问题是：使用代码Agent后，研发时间真的节省了吗？还是原来写代码的时间，变成了写需求文档的时间？如果工程师要花两个小时准备需求文档，AI Coding的价值就会被明显削弱。
解决这个问题的关键，是获取高质量的上下文，它包括两个方向：一是理解上游工程，Muse产出的原型、需求文档和共创记录，可以提供相当一部分需求上下文；二是理解下游工程，Agent需要掌握企业知识，而这些知识可能来自代码仓库、历史合并请求，也可能来自完整的测试流程。
过度微服务化的问题很难立即消除，但我们至少可以先解决上下文的聚合问题：代码可以分散在不同仓库，相关上下文必须能够被挂载到同一个地方。理想状态类似智能规划工具：Agent只在关键节点向用户提问，用户简单检查一下计划，就可以让任务继续执行，对于打磨成熟的场景，任务甚至可以在云端并发运行，用户只需要通过手机提供少量关键输入。
要接近这种状态，就必须减轻需求文档的负担，提高需求文档的质量，减少人与Agent的对话轮数，其核心仍然是企业知识。企业知识的使用方式也经历了几个阶段：2024年，许多Agent平台要求用户上传知识库文档，底层通常通过嵌入和检索增强生成技术召回相关内容，这种方式可以快速召回语义相近的信息，并加入模型上下文，但后续实践中，我们发现传统的检索增强生成很难调试：为什么召回这段内容？怎样量化回答质量？知识如何自进化？这些问题都很难回答，知识经过模糊匹配以后，也缺少完整的追溯链。
到2025年，行业开始更多地探索知识图谱化，知识结构变得更清楚了，但如果上层依然使用片段化匹配，检索增强生成的核心问题并没有真正改变，系统仍然难以度量一个判断是如何产生的。数字人和Agent团队的思路提供了新的方向：我们可以分配不同专家，对知识图进行更深入的探索。
在我看来，控制机制的一个核心问题就是：能否在正确的时间，把正确的知识交给正确的 Agent。
准确的知识并不是简单检索出来的，它更像一次研究过程：代码专家和知识专家分别进行分析，再通过推理链相互补充，最终形成判断，这个判断可以反向追溯到每一步思考和原始文档，也可以据此持续优化。要让这件事可以度量，知识就不能只是一段被检索出来的文本，我们要求每一条进入上下文的证据都带上来源、时间、归属和权限信息；召回之后要经过重排、去重和压缩，而不是把全文无差别地塞进去；来自网页、工具返回和外部文档的内容一律当作不可信输入，它们不能改写系统本身的规则。
更关键的是要做一些删除实验：把某一类上下文去掉，看成功率是否真的下降。在Muse和AI Coding系统建设中，很多我们以为有用的上下文，删掉之后指标没有变化，那它就只是在消耗窗口和成本。可以量化的指标包括召回率、引用准确率、过期信息被误用的比例，以及每个成功任务实际消耗的输入Token。换个说法，上下文工程更接近一条需要被观测的数据供应链，而不是“怎么把提示词写得更漂亮”，这里的检索质量、权限边界、时间新鲜度和压缩策略，比无限扩大上下文窗口更重要。
我们正在实践的方式，是围绕业务本体建立认知结构，并通过Agent团队仿真人类专家的推理过程。专家面对问题时，通常会先阅读一部分资料、记录笔记，再根据新线索展开调查，最后逐步形成认知。代码理解也是如此，Agent不一定一开始就阅读所有源代码，它可能先查看已经整理好的Wiki或知识图；出现问题后，再沿着线索回到代码和历史记录，判断推理链的哪一步发生了偏差。当任务同时涉及前后端代码时，还需要解决同一个工作区的问题，把相关仓库挂载到同一个空间，前端代码图也有一些特殊场景，需要单独处理。
让企业知识可以量化和自进化
企业知识维护一直非常困难，尤其对于基础设施团队，基础架构团队未必理解所有业务，而业务团队也不可能持续花大量时间整理和更新知识。因此，我们希望知识体系能够利用现有事实自行运行，需求文档、代码仓库和历史合并请求都是已经存在的事实，系统应该从这些原始信息中持续提炼知识，而不是要求人重复编写文档。
具体来说，我们会把每一步推理链写入Agent文档，使知识按模块组织，任务运行结束后，进化Agent可以根据结果反推推理链。第一次运行的效果可能并不好，但系统能够看到用户最终是否采纳结果，用户行为构成了环境反馈。我们还建立了一个基准测试，以清单的方式检查知识要点是否被覆盖，如果某个要点没有被提到，系统就能识别当前知识与理想结果之间的差异，并据此更新Agent文档，更新后再进行A/B测试，确认效果更好后，重新加载新的Agent文档。
这套机制要解决三个核心问题：
- 知识图能够进行版本对比；
- 知识迭代飞轮能够被量化；
- Agent能够平滑、自主地完成进化。
评测要分层，成本要按成功任务计算，评测本身也需要分层。最外层是结果评测，看业务任务是否真的完成；中间一层是轨迹评测，看它有没有选对工具、有没有重复执行副作用、有没有在该停下来的地方请求确认、出错之后有没有恢复；最里面一层是组件评测，单独测某个提示词、某个路由、某个工具或某个验证器。
这三层缺一层都会出问题，最容易被忽略的是中间那层，最终结果正确但轨迹并不合格的情况非常常见：它可能绕了二十步，可能重复提交了两次，也可能在一个本该请求确认的地方直接修改了。这类结果如果只按成功率统计，会被记成一次成功，于是我们就把运气当成了能力。
同样重要的是失败分类，如果只记录“失败了”，团队最后只会不停地改提示词。我们把失败分成模型、路由、工具、状态、控制和交付几类，每一类都要有严重度、代表性轨迹和明确的修复动作，分类分布的变化本身就是指标：把工具参数类的失败从两成降到几个点，比总分涨了几个点更有说服力，因为它有机制解释。
还有一个维度是成本口径，在做AI Coding的过程中我们的测评成本一开始占比非常高。单看Token单价其实没有意义，应该看每一个成功任务的成本，分母是通过的任务数，分子要把重试、升级到更强配置、验证器本身的开销和人工返工都算进去，一个便宜的配置，如果需要重试三次再由人改一遍，其实它并不便宜。我们其实并不关注某一次特别聪明的回答，而是可预测的成功率、延迟、治理能力和单位任务成本。
从 Agent App 到 Swarm OS 的全景架构
从整体架构看，最上层是Agent App的开发与交付。Agent App的基础是技能，技能是最原子的能力单元，可以由Markdown、命令行或函数计算实现，函数计算背后通常会挂载相应的沙箱，从而让Agent安全地执行具体能力。
第二层是Agent管理器，Agent的定义方式持续变化：过去更多使用代码，随后逐渐转向Markdown和可进化的Agent文档，知识体系也在变化，从传统的检索增强生成逐步转向业务本体和推理链。
再往下是正在建设的Agent集群，核心解决面对共同上下文，不同人格专家Agent的处理问题，它不只是Agent团队模式的单任务编排精度，会增加更符合任务+多人+群体智能协作推进的逻辑，是智能协作项目中的核心。
底层则是被沙箱隔离的执行单元，每个Agent在自己的沙箱中运行，但又能访问统一的记忆和工作区，这样既能满足安全和隔离要求，也不会让上下文重新碎片化。
Vibe Working
在这种工作方式下，人的角色会发生变化。过去，业务开发者、产品经理、设计师和业务专家需要亲自完成大量实现工作，未来，我们更希望人专注于关键判断和监督。设计师不再把主要精力花在制作和比较大量方案上，而是判断哪个方案真正正确，业务专家可能通过一条即时通讯消息被AI邀请参与评审，向Agent提供自己的思路、判断，以及更重要的品味。
对于基础架构团队而言，需要建设的是Agent文档、人工参与机制，以及不同场景下的上下文数据和企业品味，我们可以在Agent OS上搭建不同的Agent团队，形成“数字军团”，并对每个关键节点进行精细化处理。一个个垂直应用则以Agent App的方式存在，并共享统一的记忆，这样，无论应用运行在Web界面、即时通讯工具还是其他系统中，都可以沿着同一条上下文主线协作。
AI 时代，产品拼有价值的品味判断，技术则拼如何把问题定义的更清楚、实验更严谨、系统更可复现、失败更可解释的保障 AI 项目落地。
我们的团队为企业AI原生组织转型提供基础能力，包括AI编码工具、原型工具、协同流程等用户产品、评测平台、Agentic框架、Agent OS等底层能力。团队在Agentic系统、控制机制上有深度实践，如果您有相关经验并感兴趣，可以联系我们加入团队。
