小红书企业级AI助理Seal一个月全员覆盖实践

在 AICon 全球人工智能开发与应用大会上，小红书架构师孟洪进分享了企业级 AI 个人助理 Seal 的建设实践。春节前，小红书团队基于 OpenClaw 启动内测，只用三天推出第一个版本；在验证产品价值后，又迅速完成架构升级和规模化推广，最终在一个月内实现全员覆盖。

从 Demo 走向万级用户，难点并不只是把 Agent 部署起来。企业还必须解决安全、成本、记忆、能力复用和产品生态等一系列问题。本文将结合 Seal 的完整建设过程，介绍小红书如何应对这些挑战，以及团队对下一代智能体的思考。

春节前，OpenClaw 在全球迅速走红，小红书上甚至出现了“500 元上门安装”的服务。公司内部也有不少员工询问能否使用。出于安全考虑，安全团队不建议员工直接在个人电脑上安装。但此前已经积累了一些 Agent 研发经验，我们呢判断 OpenClaw 很有潜力成长为企业通用 AI 助理。

当时，我们决定先投入三个人，用三天时间做出一个内测版本。

项目启动时，第一个关键决策是：基于开源社区做二次开发，还是完全自研？

从技术团队的角度看，自研往往更有吸引力。不过，在做决策时，主要考虑了四个方面。

第一是产品成熟度。OpenClaw 当时已经在全球范围内得到大规模试用，产品形态和核心能力都经过了一定程度的验证。

第二是产品生长规律。一个新产品首先需要验证需求和价值，而不是一开始就投入大量研发资源。更合理的方式是快速做出原型，通过内测验证产品是否成立，再决定是否扩大投入。

第三是架构扩展性。我们需要判断开源项目的架构能否支持企业后续的深度定制。OpenClaw 的插件机制能够承载计划建设的很多能力，为后续演进留下了空间。

第四是社区生态。全球开发者不断贡献新的 Skill 和代码。如果完全自研，就很难及时获得这部分技术红利。基于社区版本开发，可以持续跟进外部生态的进展。

综合产品成熟度、验证成本、架构扩展性和社区生态四个因素，最终决定基于 OpenClaw 二次开发，而不是从零自研。

第一批内测只开放了 200 个名额，但用户热情远超预期，很快覆盖了销售、运营、算法、HR、财务等不同职能。例如，一位销售和行业运营同学用 Seal 快速生成了一份火锅投流方案；算法同学直接让它辅助取数和分析日常关注的数据；HR 将简历筛选设置成定时任务，让 Agent 每天按照人才画像完成简历初筛。

一位财务同学的案例给我留下了很深印象。以往，财务部门需要向平台团队提交需求，但很多需求未必能够及时排期。这位同学直接用 Seal 构建了一个财务平台，用来管理公司内部与 GPU 相关的预算提报和预算使用情况。

这些案例验证了最初的判断：通用型 AI 助理可以跨出 Coding 场景，覆盖公司内不同职能的办公需求，并带来明显的效率提升。

春节前，用三个人、三天时间推出内测版本。春节后，团队又用一周完成架构升级，使系统具备水平扩展能力，并开放了 2000 个公测名额。发布后仅五分钟，所有名额就被抢完，系统甚至一度被大量请求压垮。

那一刻，我觉得我们迎来了内部产品的“iPhone 时刻”：不再是研发团队希望推广产品，而是用户主动要求开放使用。接下来，又用两周完成规模化提升，并于 3 月中旬实现全员覆盖。从最初的 Demo 到公司级产品，整个过程非常快。

AI Native 时代，项目和组织都要重新设计

Seal 的建设过程迫使我们尝试了一套 AI Native 的项目机制。回头看，这套机制不仅适用于 Seal，对今后的项目管理和组织设计同样具有参考价值。我们将产品发展过程分为三个阶段：

• 定义新的模式和场景；

• 快速做出原型，验证真实价值；

• 对验证成功的产品进行规模化建设。

与之对应，团队也逐渐形成了三类角色：一小部分人专门研究前沿场景和新模式；一部分人具备很强的动手能力，能够快速做出原型；还有一部分人擅长架构和稳定性建设，负责把已经验证成功的产品迅速规模化。

在我的团队内部，我们已经不再完全按照传统方式配置专职产品和前端角色，产品同学也开始借助 AI 直接参与构建。AI Native 不只是用 AI 提升研发效率，更意味着产品验证方式、项目流程和组织结构都需要随之改变。

当一个产品从少量用户使用的 Demo 变成万级规模的企业应用，最直接的挑战集中在两个方面：安全和成本。

很多团队在尝试企业级 AI 助理时，遇到的第一个问题就是能否把它安装在员工电脑上。安全团队通常不会允许一个拥有较强操作能力的 Agent 直接运行在个人终端上。

因此，我们从一开始就选择了纯云端方案。云端模式不仅更容易进行统一的安全控制，还可以让 Agent 24 小时运行，不受员工本地电脑状态的限制。

另一个问题是成本。AI 助理确实能够带来效率提升，但企业仍然需要衡量投入产出比。随着用户和调用量持续增长，如果不进行系统性的成本治理，模型费用会迅速扩大。

三个层面的安全加固

Seal 的安全体系主要包含三个层面：集群安全、运行时安全和数据安全。

第一层是集群安全。

办公 Agent 所在的集群必须与生产网络隔离。无论 Agent 出现幻觉，还是执行了非预期操作，都不能接触或影响生产集群。同时，这个集群还需要与办公网络打通，方便员工在本地文件和云端 Workspace 之间传输数据。这样的网络形态与企业测试集群非常接近。Seal 最早的内测版本直接运行在已有的测试集群上。后续，容器团队又面向企业内部的 Agent，统一建设了多个 Kubernetes 集群，并实施统一的网络控制：一方面与生产网络隔离，另一方面与办公网络连通。

第二层是运行时安全。

早期版本中，容器团队还没有成熟的 Agent 沙箱能力。我们采用了一个相对简单的方案：每位用户对应一个独立 Pod。OpenClaw 是有状态的，每个用户实例都需要保留自己的 Workspace 和记忆。因此，每个 Pod 还绑定了一块专属云盘，用于保存用户相关状态。在这个基础上，容器团队进一步建设了 Nex，一个面向企业级 Agent 的沙箱管理平台。其整体架构分为四层：

1. AI 网关层，负责统一身份认证、流量认证和流量治理；

2. 控制面，负责沙箱的生命周期管理；

3. 沙箱编排运行时，基于自研 CRD 和 Operator，实现分层调度与批量创建；

4. microVM 运行时安全层，基于 Kata Containers、Cloud Hypervisor 及自研 Guest Kernel〔待确认〕提供隔离和防护。

Nex 主要提供两类核心能力。

第一类是 Agent 沙箱编排。Agent 的生命周期与传统服务发布并不完全相同，因此我们希望平台能够全面托管实例的创建、运行和回收。

同时，Nex 引入了预热池机制，用于缩短 Agent 实例的启动时间，并通过批量编排提升上万规模实例的发布和运维效率。

第二类是强隔离。Nex 提供了从 VM 边界、System Call 白名单、网络隔离、文件系统限制，到基于 cgroup 的资源强限制和安全审计等多层防护能力。

第三层是数据安全。

企业内部不可能只使用一种模型。由于自有 GPU 资源有限，我们除了使用内部部署的模型，也会采购外部云厂商的模型 API。这就带来了一个非常现实的问题：公司敏感数据不能离开企业的安全边界。为了解决这个问题，我们与安全团队共同建设了敏感数据检测和模型自动路由机制，并将安全 SDK 内置到 Seal 客户端中。

员工电脑本身已经安装了安全软件，会定期扫描敏感数据和敏感文件。当用户向 Seal 上传文件时，系统会再次调用安全 SDK，判断文件是否包含敏感信息。如果文件被识别为敏感数据，系统会进行强制限制，只允许任务使用公司内部部署的模型，不能路由到外部云厂商的模型。

这样一来，战略、法务、财务等涉及敏感数据或高权限数据的场景，也能够在安全边界内使用 AI 助理。

从消耗和单价两个方向降低成本

我们将成本优化拆成两个维度：一是降低完成相同任务所需的 Token 消耗，二是降低每次模型调用的平均单价。在降低消耗方面，我们设计了 Self-GC 机制。

Self-GC 的灵感来自 JVM 的垃圾回收机制。在 JVM 中，每个对象都有自己的身份和边界，系统会判断对象是否仍然活跃、是否还在被引用，并回收已经不再使用的对象。

在 Agent 场景中，可以把长程对话历史看作运行时中的一个虚拟堆。传统做法通常是对上下文进行粗暴裁剪，但这样无法保证关键信息得到保留，很容易导致效果下降。

要实现更安全、精细的上下文裁剪，就需要像 JVM 管理对象一样，为每段文本和每次 Tool Call 的返回结果建立明确的身份与边界。在此基础上，系统才能准确地标记、折叠或裁剪内容。

Self-GC 采用了三个阶段的运行机制。

第一个阶段是异步制定 Plan。当上下文达到设定阈值、触发一个 GC 周期后，系统会异步生成清理方案，但不会立即执行。

第二个阶段是预演。系统会先判断该方案能否带来足够的 Token 节省，同时拦截可能存在的边界问题。

第三个阶段是等待安全时机。预演通过后，方案进入 Pending 状态。系统不会马上提交，而是等待 Tool Call 完成，或者 Agent 正在等待用户输入等相对安全的时间点，再执行 GC 操作。

Self-GC 上线后，每天的 Token 消耗下降了 10% 至 15%，峰值消耗下降约 20%。它不仅降低了成本，也缓解了上午 9 点、10 点等定时任务集中运行时的系统压力，提升了高峰期稳定性。

降低单价则主要依靠 Auto 模式。

企业通常会同时引入多个层级的模型，包括顶级模型、高级模型和高性价比模型。但并非所有任务都需要使用能力最强、价格最高的模型，因此需要根据任务难度自动选择模型。

Seal 的 Auto 模式采用混合策略。系统首先使用一个 30B MoE 模型判断任务难度，同时通过规则体系进行干预。

例如，模型路由不能只比较调用单价，还必须考虑缓存是否命中。即使某个模型的标价较高，命中缓存后的实际成本也可能很低。

此外，我们还为路由系统设计了完整的容灾方案。如果 Router 本身不可用，或者推荐的模型暂时不可用，系统都会执行相应的 Fallback 策略。

线上灰度数据显示，公司范围内 70% 以上的日常任务使用高性价比模型就足够了，约 22% 的任务需要高级模型，只有约 3% 的任务需要顶级模型。

与所有用户统一使用高级模型相比，Auto 模式可以节约约 69% 的模型成本。企业也可以根据自身预算，动态调整不同模型的路由比例。

虽然 Seal 基于 OpenClaw 建设，但我们仍然需要判断哪些核心能力值得进一步投入。团队重点讨论了两个方向：一是增强 Memory，二是让 Skill 具备自迭代能力。如果资源充足，两者当然可以同时推进。但小红书团队人员相对精简，必须明确优先级。

我们的判断是，现阶段 Skill 自迭代并不是第一优先级。

企业内部真正被高频使用的 Skill 数量并没有想象中那么多，通常集中在数据平台、数据库平台、发布平台，以及产品、运营使用的内部平台上。它们的范围比较明确。优先把这批核心 Skill 做好，就可以获得很大一部分收益。

相比之下，Memory 更普遍，也更迫切。Seal 的用户已经从 AI Coding 场景中的研发人员扩展到公司内的不同工种。用户不应该为了使用个人助理，先去理解什么是 Context Window、Compact 或 Session。就像人们可以熟练使用手机，却不需要先掌握操作系统原理。如果用户觉得 AI 助理难用，问题不一定是用户不懂 AI，更可能是产品能力还不够成熟。

我们收到的大量反馈是：为什么 AI 助理用了一段时间后会变笨？为什么以前说过的事情，它后来就不记得了？

这说明记忆已经成为一个真实且普遍的用户痛点。

在实际测试中，OpenClaw 原生 Memory 存在几个明确问题。

首先，记忆过度依赖用户主动提醒。用户必须明确告诉 Agent“请记住这件事”，它才会把内容写入 memory.md。

其次，当对话被压缩或用户新建 Session 时，容易出现明显的“失忆”。原生 Worklog 又更像流水账，即使全部加载，也不一定能够真正帮助 Agent 理解和使用过去的信息。

此外，记忆的晋升机制比较复杂，审计能力也不够强。用户很难知道某条长期记忆究竟来自哪次对话。

我们实测时，即使运行较长时间，真正被晋升为长期记忆的内容仍然很少。与之对应，原有机制在记忆遗忘方面也比较薄弱。

针对这些问题，我们将 Seal 的记忆系统分成三个层级。

第一层是 Session，也就是当前对话上下文。像 SOUL.md、用户的重要 Profile 和关键偏好等必须使用的信息，会直接加载到 System Prompt 中。

当对话发生压缩、用户新建 Session，或者系统在夜间执行定时扫描时，我们会将对话中的事实沉淀到第二层 Worklog。

Worklog 相当于 L1 层，主要承担事实缓冲和证据保存的作用。这些内容不会未经筛选就全部交给 Agent，而是为后续长期记忆提供可追溯的事实来源。

第三层是长期记忆。系统会持续对 Worklog 进行编译和整理，将其中的事实转化成结构化、具有关联关系并且可以持续更新的 Memory Wiki。

这套机制并不是传统 RAG。我们会提前让模型把事实编译成结构化的 Wiki，并建立清晰的目录和关联关系。

长期记忆又分成两部分：一部分是必须注入的内容，例如与个人 Profile 强相关的重要记忆；另一部分是按需召回的内容，不会在每次对话中全部加载。

我们会把 Memory Wiki 的目录结构提供给模型，让它判断当前任务是否需要查询记忆。如果需要，Agent 可以像人翻书一样，通过文件检索工具找到对应内容。

完成这套增强后，记忆不再只是一个简单的 memory.md 文件，而是真正变成了个人知识 Wiki。用户每天讨论的主题、涉及的实体和重要事实都可以被主动记录，并在后续对话中按需检索和使用。

当前这套记忆系统仍然主要基于本地文件。接下来，我们确定了两个重要演进方向。

第一个方向是从本地走向云端。同一位用户往往会同时使用多个 Agent 产品，例如 AI Coding Agent 和个人助理 Agent。不同 Agent 之间如何共享同一个人的记忆，仅靠本地文件很难解决，最终必须依赖云端记忆系统。

第二个方向是从一次性任务走向知识沉淀。现在很多 AI 应用仍然是“用完即抛”：用户借助 Agent 完成一次任务或一个需求，下次遇到类似任务时又从头开始，此前积累的知识没有被保留下来。

基于 Memory 增强的实践，我们可以继续抽象项目维度、代码仓库维度、需求维度，乃至组织维度的记忆，最终形成企业级共享记忆系统。

当一个 AI 工具在企业内部得到广泛应用后，仅靠产品本身还不够。要进一步放大生产力，需要建设周边生态，让能力能够被创建、分享、复用和传播。

Seal 主要建设了两类生态能力：用于复用 Agent 能力的 Skillhub，以及用于发布 AI Coding 产物的 CoWork Studio。

在 Seal 内测阶段，我们就认为 Skillhub 是一个不可缺少的功能。一方面，经过审核、确认安全的外部 Skill 可以被引入公司内部；另一方面，公司员工自己编写的 Skill，无论来自平台团队还是个人，都可以通过 Seal 一句话上传到 Skillhub。其他用户在遇到相应场景时，Seal 可以自动扫描并安装所需 Skill。

最初，我们对 Skillhub 的设计比较简单，主要围绕发布和订阅关系展开。但真正落地后，发现企业内部的 Skill 有着更加多样的管理需求。第一类是平台或官方 Skill。这类 Skill 需要明确的负责团队进行长期支持和维护。

第二类是个人 Skill，由员工根据自己的工作需求创建。一个很有意思的现象是，很多个人 Skill 的出现都早于官方版本。员工已经创建并广泛传播某个 Skill 后，相关平台团队才开始行动。Skillhub 在一定程度上反向推动了公司内部平台的 AI 化和 Agent 化。

第三类是私域 Skill。例如 HR、财务等系统涉及敏感数据，其 Skill 本身也可能包含敏感信息，因此不能对全员公开，需要在限定范围内共享和使用。

通过这样的分类，Skillhub 可以支持公共、团队和私域等不同层级的能力分享。

Seal 上线一个多月后，Skillhub 中已经有 9000 多个 Skill，其中内部 Skill 超过 8000 个。平台与官方 Skill 约有 100 个，团队 Skill 约有 136 个，数量最多的仍然是个人创建的 Skill。

数据还显示，大部分 Skill 调用集中在 Top 100 和 Top 200。这也进一步印证了我们此前的判断：现阶段与其投入大量资源研究所有 Skill 的自迭代，不如优先优化和运营头部 Skill。

Skill 解决的是能力复用问题。在 Seal 广泛使用后，我们还观察到另一个变化：企业内部的生产关系正在发生改变。HR、财务、销售等非研发岗位都开始借助 AI Coding 构建自己的工具。技术同学做出了 AI 面试工作台，HR 同学创建了评奖平台，财务同学开发了 GPU 需求和预算管理平台。

过去，员工有需求时通常需要向产品、研发或中台团队提出，再等待评估和排期。现在，很多人可以直接借助 AI 快速完成自己的需求。当 AI 降低软件构建门槛后，每个人都有可能成为 Builder。

为了让这些产物不只停留在个人电脑上，我们推出了 CoWork Studio。员工通过 AI Coding 创建的产品，可以一键上传并发布成可用的网站，让其他人直接使用。其中有一个“灵感盲盒”，由产品同学创建。它会收集小红书真实用户的反馈，用户点击后可以随机获得一条产品灵感。还有同学开发了一个应用，能够根据个人画像生成技术问题或面试问题。

CoWork Studio 的价值，在于让每个 Builder 创建的产品都能够被看到、复用和传播。它不仅提高了个体效率，也让分散在组织中的创造力有机会转化为企业共享能力。

从 ChatGPT 到 AI Coding，再到 OpenClaw 和 Seal，智能体的能力已经发生了明显跃迁：最初只能完成问答，现在已经可以“有手有脚”地执行具体任务。

但当前智能体仍然主要面向单次任务。它需要人主动告诉它要做什么，然后完成一次交付。我们认为，下一代智能体需要在三个方向上继续演进。

第一个方向是更强的主动感知能力。例如，团队每次开完周会都会确定一系列待办事项，但会议结束后，这些 Todo 往往失去上下文，也可能长期无人推进。下一代智能体应该能够感知一个团队有哪些待办事项尚未完成，理解它们产生的背景，并主动提醒相关人员。对于边界明确的任务，它甚至可以直接协助完成。

第二个方向是从面向任务交付走向面向目标交付。未来的 Agent 可能像员工一样拥有相对独立的身份。组织根据它的能力范围设定一个目标，由它自主规划执行过程，并在目标推进过程中持续沉淀自己的 Memory 和 Skill。

第三个方向是多 Agent 协同。在现阶段，很难用一个完全通用的 Agent 解决所有问题。企业内部天然存在大量专业分工，因此 Agent Team 和多 Agent 协同一定会成为下一代智能体需要重点攻克的方向。

Seal 从三个人、三天完成内测，到一个月内实现全员覆盖，首先依赖的是快速验证、快速迭代和快速规模化的项目机制。但产品真正进入企业后，决定它能否长期运行的，是安全、成本、记忆和生态等系统能力。

实践表明，企业级 AI 助理不能只是一个模型入口。它需要安全的运行环境、可持续的成本治理、能够长期积累的记忆系统，以及让员工共同创建和复用能力的生态。当 AI 助理开始理解个人、沉淀组织知识，并从执行单次任务走向主动交付目标时，它才可能真正成为企业中的下一代生产力基础设施。

孟洪进，小红书 AI Coding 及企业内部 AI 应用总负责人与总架构师。主导研发小红书自研 AI Coding 工具 CodeWiz，深度融合内部研发生态；同时主导构建企业级 AI 个人助理 Seal，基于 OpenClaw 打造，已实现全员覆盖。深耕 Agent 架构设计、Agent Infra 大规模工程化及 LLM 应用落地，致力于以 AI 重塑企业研发与办公形态。