小红书企业级 AI 个人助理——从 0 到全员覆盖

年初 OpenClaw 爆火时，很多团队都注意到了它。真正的问题不是“要不要做”，而是怎么做才快得起来、稳得下去。

小红书的这条时间线是这样的：

• 2月11日：做出决策，3 人小组用 3 天推出内测版本

• 3月9日：一周完成架构升级加固，开放 2000 公测名额

• 3月17日：两周完成规模化提拉，全员覆盖

从决定做到全员覆盖，一共大约一个月。

这个速度背后的关键是一套 AI Native 项目运作机制，先定义新模式，快速推 MVP 验证，验证通过后立刻规模化。

先让用户用起来，收集反馈，再迭代优化。很多传统项目团队做不到这一点，他们习惯把评估做到 90 分再动手，但在 AI 领域，评估做到 90 分的时候，方案本身已经过时了。

技术选型时最核心的一道题是自研，还是基于 OpenClaw？

我们选了后者，有四个理由：

1. 产品成熟度。OpenClaw 已经经过大规模生产验证，工具链完备。自研意味着大量轮子要重造，周期长、风险高。

2. 极速交付。3 人 3 天完成内测版本，这在 AI Native 的节奏下至关重要。先快速验证价值，再按需深度定制。

3. 架构可控。开源架构透明，可以做深度定制。后面要讲的安全加固、成本优化、Memory 增强，都是我们在它之上自主演进出来的。

4. 生态优势。Skill Hub 可以共建，社区持续贡献。自研意味着生态从零开始，缺乏网络效应。

一句话概括：Time to Value。

内测上线后，效果超出了预期。运营用它写方案，算法用它看数据，HR 用它筛简历，财务用它搭建财务工具平台。

从“好玩的 demo”到“全员使用的企业级产品”，中间横着两座绕不过去的山。

第一座是安全。代码要在沙箱里执行、用户敏感数据会流经模型、整个系统需要跟生产环境隔离——这些问题不解决，IT 和安全团队不会放行。

第二座是成本。全员使用意味着巨大的模型调用量，如果不做成本优化，账单会推翻掉原有的预算模型。

下面分别拆解。

集群安全的核心思路是物理隔离。

我们搭建了一个叫Seal AI Zone的专属隔离集群，运行在独立的 K8S 集群中，跟生产环境完全隔开。所有员工都通过 Seal 客户端接入这个集群。

集群内部有完整的安全策略管控、专属的 LLM 服务、独立的存储，以及和公司 SSO / LDAP / VPN 打通的身份认证体系。Agent 执行代码的沙箱运行在 MicroVM 上，跟社区、电商、广告等生产服务完全不通，即使沙箱内有恶意代码，也没有办法触达任何生产系统。

运行时沙箱：NEX

NEX 的全称是 Native Engine for Agent Sandbox，是我们面向 Agent 场景专门构建的企业级沙箱平台。为什么需要专门构建？因为 Agent 需要执行代码，用户说“帮我分析这个数据”，Agent 就会写一段 Python 然后执行。这段代码不能直接跑在宿主机上，否则安全风险不可控。

NEX 架构分四层：

•L1 EdithAI 网关：统一身份认证 / 流量治理 / Skill 路由 / 全链路审计

• L2 NEX 控制平面：沙箱生命周期 / 预热池 / 模板管理

•L3 底层编排运行时：自研 CRD Operator，支持批量创建和三层调度

• L4 MicroVM 安全运行时：Kata Containers + Cloud Hypervisor + 自研 Guest Kernel，六层安全防护

关键指标：冷启动 P50 低于 300ms，热启动 P99 低于 50ms，热池命中率 超过 70%，创建吞吐峰值 500/秒。

沙箱有两大核心能力。一是编排能力：支持 Task、Session、Persistent、Browser 四种形态，生命周期全链路管控，预热池保证性能。二是强隔离：每个沙箱跑在独立的 MicroVM 中，六层防护包括 VM 边界隔离、Seccomp syscall 白名单、网络默认拒绝、只读文件系统、cgroup 硬限、全命令审计日志。

一句话概括 NEX 的定位：让每一个 AI Agent 都有一个安全的家。

数据安全：敏感数据不出域

第三层的核心策略只有一句话，就是敏感数据不出域。

Seal 客户端内置了 Security SDK，对用户输入做三重扫描：PII 检测、代码秘钥扫描、文件内容扫描。扫描引擎结合了正则和机器学习模型。

• 检测到没有敏感数据→ 请求正常发送到外部模型 API

• 检测到有敏感数据→ 请求强制路由到自部署的私有化模型，确保数据不离开公司网络

这套机制对用户是透明的——用户不需要判断自己的输入是否包含敏感信息，系统自动处理。

成本优化拆成两个正交维度：Token 消耗和模型单价。这两个变量互不干扰，可以同时优化。

降消耗：Self-GC

Self-GC 这个名字的灵感来自 JVM 的垃圾回收。

在 JVM 中，堆内存管理本质上是管理对象生命周期，比如哪些对象还活着、哪些已经没人引用。GC 会做标记、整理、回收。类比到 Agent 上下文管理：长程对话历史就是 Agent 运行时的虚拟 Heap。

如果只做简单的文本截断，本质上就是在语义边界中间随手切一刀——这会丢失关键上下文。要安全缩上下文，必须先给每段文字“上户口”，让它有身份、有边界，然后才能有策略地被标记、折叠、遮罩或删除。

Self-GC 的核心是三阶段提交机制：

• Async Plan：触发 GC 周期后，旁路 planner 异步 fork 当前对话前缀，规划哪些内容可以 Fold（折叠）、Mask（遮罩）或 Prune（剪枝）。这个过程是异步的，不阻塞用户的正常交互。

• Rehearsal：系统控制层先在本地做一遍预演，检查 ID 幻觉和误删风险，计算 token saving。预演发现问题会自动调整策略。

• Delayed Commit：规划好的 GC 计划不立即执行，先进入 pending 状态，等到工具执行完成或用户输入等待等安全边界再提交。避免在关键执行过程中突然改变上下文。

线上效果：小红书生产环境中，部署 Self-GC 的实验组白天平均输入 Token 下降10% ~ 15%，高峰期最大降幅接近20%。

考虑到全员使用的规模，这是一笔非常可观的成本节约。

降单价：Auto 模式

Auto 模式是一套智能模型路由系统，核心思路是：并不是每个请求都需要用最贵的模型。

写一封简单的邮件和做复杂的代码推理，需要的模型能力完全不同。决策内核叫 SealRouter，是一个规则与模型混合判别 + cache-aware 成本约束的路由系统。

四个层面：

• 判别模型：基于线上真实流量训练的 30B 分类模型，根据请求特征判断合适的模型级别

• 路由规则：强特征优先，例如tool 数量特别多、上下文特别长的请求，跳过推理直接选高级模型

• 成本约束：cache-aware。命中缓存（cache hot）时锁定当前模型，因为切换会导致缓存失效。需要切换时评估切换收益是否大于缓存失效成本

• 容灾降级：路由超时自动回退稳妥模型，Auto 始终可用

上线效果：约 75% 的请求走高性价比模型，22%走高级模型，仅 3% 走顶级模型。对比全量使用高级模型，成本降低69%。

关键的一点：这个降幅不是牺牲质量换来的。SealRouter 的核心设计原则是不降质量降成本，真正需要强推理能力的请求，依然会路由到最强模型上。

现有 Memory 机制有四个核心问题：

1. 压缩和新会话失忆——每次开新会话，之前聊的东西就丢了。原始对话没有及时 flush 到缓冲区，后续的长期记忆整理缺少完整证据。

2. Flush 流水账化——memory-flush 缺乏结构化总结能力，生成的记忆文件容易变成无意义流水账，很难转成可用知识。

3. Dreaming 难审计——原生 dreaming 阶段多、产物多，演化链路复杂，用户很难理解记忆为什么会变成这样。

4. 晋升难、遗忘弱——长期记忆晋升门槛太严格，证据链维护和冲突消解偏弱，遗忘机制也不够好。

针对这些问题，我们设计了一套三层 Memory 架构：

1. L0 Session 层——短期上下文。当前对话的即时推理和临时状态。SOUL.md、TOOLS.md 这些配置只在这一层注入，不进长期记忆。

2. L1 Work Log 层——事实缓冲与证据层。触发 /compact、/new 或夜间扫描时，关键事实 flush 到 memory/YYYY-MM-DD.md。关键的创新是保留了原始证据指针——可以回溯到原文来源；用 compiled 字段跟踪编译状态。

3. L2 LLM Wiki 层——长期记忆与知识存储。这是我们最核心的创新。

LLM Wiki 不是传统的 RAG。 传统 RAG 是在提问时临时拼接原始片段。我们的做法是提前把事实编译成结构化的 Markdown Wiki，包含 index、user、entities、concepts、syntheses、sources 等页面，页面之间相互关联，形成一个完整的知识网络。

召回方式也不同：不是全量注入，而是按需召回。index.md 提供目录，search() 用 BM25 + 向量混合检索搜索相关页面，get() 获取具体内容和证据。

实际效果可以概括为四个“可”：

• 可继续—— 新会话后还能接着项目问

• 可溯源 —— 回答能落到 wiki 相对路径

• 可过滤—— 临时闲聊不进长期事实

• 可维护—— 用户能读懂、能编辑

未来两个方向：从本地走向云共享——chat 和 code 两种 Agent 模式共享同一份用户记忆，其他 Agent 也能复用，不需要在每个地方重新养一遍；企业级知识库——结合知识图谱或 GraphRAG 的思路，把个人记忆的能力扩展到组织层面。

底层能力做好之后，往上就是生态。

Skill Hub是技能共享平台。我们把 Agent 的能力抽象成了 Skill。Skill Hub 上有三类 Skill 并存：平台官方提供的、个人开发的、以及团队或部门的私域 Skill。私域 Skill 可以按需分享给其他人或团队。

这形成了一个正循环：用的人越多，贡献的 Skill 越多，平台的价值就越大。从上线效果看，Skill Hub 的数据增长非常健康。

Cowork Studio 是面向 AI Builder 的作品发布平台。它让内部开发者可以一键上传自己构建的 AI 应用，降低了分发和使用的门槛。

目前的 Agent 本质上还是被动响应——用户给指令，Agent 执行。我们认为下一代智能体应该往三个方向演进：

• 主动感知——Agent 应该能自主获取外部信息、发现问题和机会，而不是等用户来问。

• 目标驱动——不是执行一个个具体任务，而是理解一个高层目标，自己分解成子任务，独立制定并执行计划。

• 主动协作——Agent 不再是一个工具，而是作为组织中的一个独立个体，主动参与团队协作，可以跟其他 Agent 协同，也可以跟人类协作。

从被动响应到主动感知，从任务执行到目标驱动，从单一 Agent 到多 Agent 协同，这是我们看到的下一代企业级智能体的演进路径。

用 AI Native 的方式，3 人 3 天启动，一个月完成全员覆盖。

这个过程中，通过专属隔离集群和 NEX 沙箱解决了安全问题，通过 Self-GC 和 Auto 模式把成本降了下来，通过 LLM Wiki 增强了 Agent 的记忆能力，通过 Skill Hub 和 Cowork Studio 构建了生态。

我们的愿景是——探索 AI 应用的边界。

小红书质效研发部，肩负着以 AI 重构公司级下一代研发体系的使命。我们希望基于 AI 技术，打造全新版本的研发工具，结合 LLM 辅助、LLM 原生能力，串联从需求理解到发布部署的全流程，为小红书的技术团队提供业界顶尖的“武器装备”。

AI Coding 团队核心方向：

1. GUI Agent 执行引擎与 Coding Agent 架构

2. AI Testing

3. AI Coding harness 与解决方案

4. 分层知识库与路径引导系统

我们正在寻找对 AI Agent、智能化测试、GUI 自动化方向有热情的同学。如果你做过 Agent 工程化、LLM 基础设施，或者想把 LLM 真正落地到具体业务，欢迎联系！

内推简历投递：

wangruiwen1@xiaohongshu.com