在 AICon 全球人工智能开发与应用大会上，小红书架构师孟洪进分享了企业级 AI 个人助理 Seal 的建设实践。春节前，小红书团队基于 OpenClaw 启动内测，只用三天推出第一个版本；在验证产品价值后，又迅速完成架构升级和规模化推广，最终在一个月内实现全员覆盖。
从 Demo 走向万级用户，难点并不只是把 Agent 部署起来。企业还必须解决安全、成本、记忆、能力复用和产品生态等一系列问题。本文将结合 Seal 的完整建设过程，介绍小红书如何应对这些挑战，以及团队对下一代智能体的思考。
一个月，从 Demo 到全员覆盖
春节前，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 的沙箱管理平台。其整体架构分为四层：
- AI 网关层，负责统一身份认证、流量认证和流量治理；
- 控制面，负责沙箱的生命周期管理；
- 沙箱编排运行时，基于自研 CRD 和 Operator，实现分层调度与批量创建；
- 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% 的模型成本。企业也可以根据自身预算，动态调整不同模型的路由比例。
Agent 能力升级：为什么优先增强记忆
虽然 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 理解和使用过去的信息。
此外，记忆的晋升机制比较复杂，审计能力也不够强。用户很难知道某条长期记忆究竟来自哪次对话。
我们实测时，即使运行较长时间，真正被晋升为长期记忆的内容仍然很少。与之对应，原有机制在记忆遗忘方面也比较薄弱。
从 Session 到 Worklog，再到长期记忆
针对这些问题，我们将 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 增强的实践，我们可以继续抽象项目维度、代码仓库维度、需求维度，乃至组织维度的记忆，最终形成企业级共享记忆系统。
从工具到生态：让每个人都能成为 Builder
当一个 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 重塑企业研发与办公形态。
会议推荐：
12 月 18–19 日，AICon 全球人工智能开发与应用大会将在北京举办。本届大会以探索 A 应用边界为主题，设置 13 大技术专题，覆盖大模型后训练、推理优化、Agent 工程、知识工程、智能体评测与安全、自进化系统、AI 软件交付、原生架构及组织变革等核心方向，汇聚一线技术专家，深入分享 AI 技术突破与企业规模化落地的真实实践。
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
At the AICon Global Congress on Artificial Intelligence Development and Applications, Menghongtai, REDnote Architect, shared the construction practices of Enterprise-level AI Personal Assistant Seal. Prior to the Spring Festival, the REDnote team started the internal survey based on OpenClaw, and launched the first version in only three days; the architecture upgrade and scale-up was quickly completed after the product was validated and full coverage was achieved within one month.
From Demo to 10,000, the difficulty is not just to deploy Agent. Enterprises must also address a range of issues such as safety, cost, memory, re-use of capacity and product ecology. This paper will describe how REDnote has addressed these challenges in the context of the complete construction of Seal and the team's reflections on the next generation of AI agent.
One month, from Demo to full coverage.
Before the spring, OpenClaw quickly went global, and even “$500 for door-to-door installation” services appeared on REDnote. There are also a number of staff within the company asking if they can use it. For security reasons, the security team does not recommend that employees install their personal computers directly. But there's been some Agent R & D experience before, and we're judging that OpenClaw has the potential to grow into a general AI assistant for the enterprise.
At that time, we decided to put three people in first and take three days to produce an internal version.
At the start of the project, the first key decision was: is it a secondary development based on open-source communities, or is it a full self-study?
From the technical team perspective, self-study is often more attractive. However, four main areas were considered in decision-making.
The first is product maturity. OpenClaw had been tested on a large scale worldwide, with a degree of validation of product form and core competencies.
The second is product growth patterns. A new product requires, first and foremost, the validation of demand and value, rather than a significant investment in research and development resources from the outset. A more rational approach would be to make the prototype quickly, to verify whether the product was established through internal testing before deciding whether to expand the input.
The third is the expansion of the architecture. We need to judge whether the open-source project architecture will support the enterprise ' s further in-depth customization. OpenClaw ' s plugin mechanism can carry many of the capabilities built by the plan, leaving room for subsequent evolution.
The fourth is community ecology. Global developers continue to contribute new Skills and codes. If fully self-studyed, it would be difficult to obtain this part of the technical dividend in a timely manner. Community-based version development allows for continuous follow-up of external ecological progress.
The four factors of integrated product maturity, certification costs, architecture expansion and community ecology ultimately determined to be based on OpenClaw ' s secondary development rather than on self-study from zero.
The first set of internal surveys opened only 200 places, but users were more enthusiastic than expected and quickly covered different functions such as sales, operations, algorithms, HR, finance, etc. For example, a sales and trade business student quickly generated a fire pot dropout programme using Seal; algorithm students directly enabled it to collect numbers and analyse data of daily concern; HR set the CV screening to a time-bound task, allowing Agent to complete the initial CV screening on a daily basis based on a talent image.
I was impressed by the case of a finance student. In the past, the finance sector had been required to submit the requirements to the Platform team, but many of them were not necessarily scheduled in time. The student directly used Seal to build a financial platform to manage the budget presentation and use of the GPU-related budget within the company.
These cases validate the initial judgement that generic AI assistants can cross the Coding scene, cover the office requirements of different functions within the company and bring about significant efficiency gains.
Before spring, three-person, three-day in-time versions were launched. After the spring festival, the team completed the architecture upgrade in one week, enabling a horizontal expansion of the system and opening up 2,000 public spaces. Only five minutes after publish, all the places were seized and the system was even crushed by a large number of requests.
At that moment, I felt that we had an iPhone moment for the internal product: instead of the R & D team wanting to promote the product, the user volunteered to open it. Next, two weeks to scale up and full coverage in mid-March. From the original Demo to the company level, the whole process was very fast.
In the era of AI Native, projects and organizations have to be redesigned.
The construction of Seal forced us to try an AI Native project mechanism. In retrospect, the mechanism is not only relevant to Seal, but is equally relevant for future project management and organizational design. We divided the product development process into three phases:
- Defining new models and scenarios;
- Rapid development of prototypes to verify real value;
- Scale-up of proven successful products.
In response, teams have evolved into three types of roles: a small group of people specialized in frontier scenarios and new models; a small group of people with a strong hands-on ability to quickly make prototypes; and a small group of people who are good at building structures and stability and who are responsible for rapidly scaling up proven successful products.
Within my team, we no longer have a full-time product and front-end role in the traditional way, and product classmates have started to be directly involved in the construction through AI. AI Native does not just use AI to improve R & D efficiency, but means that product validation, project processes and organizational structure need to change accordingly.
From a toy to a class-one product, there's safety and cost. Off
When a product moves from Demo for a small number of users to a 10,000-scale enterprise application, the most immediate challenges focus on two aspects: safety and cost.
The first problem that many teams have encountered in trying to get an AI assistant at the enterprise level is if they can install it on the employee computer. A security team would not normally allow an Agent with greater operational capability to run directly on a personal terminal.
Therefore, we have chosen from the outset a pure cloud-based approach. The cloud-end model not only makes it easier to provide uniform security controls, but also allows Agent to operate on a 24-hour basis without restrictions on the local computer status of employees.
Another issue is cost. AI Assistants do deliver efficiency gains, but enterprises still need to measure input output ratios. As users and calls continue to grow, model costs will expand rapidly without systematic cost management.
Three levels of security reinforcement
The Seal security system has three main dimensions: cluster security, operational security and data security.
The first level is cluster security.
The cluster where Agent is located must be isolated from the production network. Whether Agent is hallucinating or performing unforeseeable operations, it is impossible to reach or influence production clusters. At the same time, the cluster needs to be connected to the office network to facilitate the transmission of data between local documents and cloudy workspace. This type of network is very close to the enterprise test cluster. Seal's earliest internalized version runs directly on existing test clusters. Following this, the container team addressed Agent, within the enterprise, and consolidated several Kubernetes clusters and implemented a unified network control: separate from and connected to the production network.
The second level is running safe.
In the earlier version, the container team had not matured the Agent sandbox capability. We have adopted a relatively simple programme: each user has a separate Pod. OpenClaw has a status, and each user example needs to keep its own workspace and memory. As a result, each Pod also binds an exclusive cloud disk to preserve the user-related status. On this basis, the container team further built Nex, an enterprise-level Agent sandbox management platform. Its overall structure is divided into four levels:
- AI gateway, which is responsible for harmonizing identification, traffic authentication and traffic management;
- Control over the face, responsible for the life cycle management of sandboxes;
- When sandboxing is running, it is based on self-study CRDs and Operators, which achieve tiered and batch creation;
- MicroVM running security layer based on Kata Containers, Cloud Hypervisor and self-study Guest Kernel Provide quarantine and protection.
Nex provides two core competencies.
The first category is Agent Sandboxing. The life cycle of Agent is not exactly the same as that of the traditional service publish, so we hope that the platform can fully host the creation, operation and recovery of examples.
At the same time, Nex introduced a pre-heat pool mechanism to shorten the start-up time of the Agent instance and to increase the publish and transport efficiency of the 10,000-scale example through bulk organization.
The second category is isolation. Nex provided multi-layered protection capabilities ranging from the VM border, the Systems Call White List, network isolation, document system restrictions, to resource constraints and security audits based on cgroup.
The third level is data security.
It is not possible to use only one model within the enterprise. Because of our limited GPU resources, we also procure models from external cloud manufacturers, API, in addition to using internal deployment models. This poses a very real problem: company-sensitive data cannot leave the firm ' s safe borders. To address this problem, we worked with the security team to develop an automated router mechanism for sensitive data detection and modelling and to embed a secure SDK into the Seal client.
Security software has been installed in the employee computer itself, which regularly scans sensitive data and documents. When a user uploads a file to Seal, the system will again call secure SDK to judge whether the file contains sensitive information. If the document is identified as sensitive data, the system will impose a mandatory restriction, allowing missions to use only models deployed within the company and not by external cloud manufacturers.
As a result, scenarios involving sensitive data or high permission data, such as strategic, legal, financial, etc., can also use AI assistants within secure borders.
Cost reductions in both consumption and unit prices
We split the cost optimization into two dimensions: a reduction in the Token consumption required to perform the same task and a reduction in the average unit price of each model call. In terms of reducing consumption, we have designed the Self-GC mechanism.
Self-GC is inspired by JVM's waste recycling mechanism. In JVM, each object has its own identity and borders, and the system determines whether the object is still active, is still being quoted and recycles objects that are no longer in use.
In the Agent scene, the long-range conversation history can be seen as a virtual pile of running time. The traditional practice of rough tailoring of context, which does not guarantee the retention of key information, can easily lead to a decrease in effectiveness.
A more secure and fine context cropping requires, like the JVM management object, the establishment of a clear identity and boundaries for each paragraph of the text and for each return of Tool Call. On this basis, the system can accurately mark, fold or crop content.
Self-GC uses a three-stage operating mechanism.
The first phase is the development of Plan. When context reaches the set threshold and triggers a GC cycle, the system generates a cleanup programme by step, but will not be implemented immediately.
The second stage is rehearsal. The system will first judge whether the programme will generate sufficient token savings while intercepting possible border problems.
The third stage is waiting for a safe moment. After the preview, the scheme entered Pending status. The system will not be submitted immediately, but will wait for Tool Call to complete, or Agent is waiting for relative security points such as user input to perform GC operations.
After Self-GC went online, the daily Token consumption decreased by 10 to 15 per cent, and the peak consumption decreased by about 20 per cent. It not only lowers costs, but also reduces the system pressure when timed missions like 9 a.m. and 10 a.m. are centralized, increasing stability during peak periods.
The lower unit price depends mainly on the Auto mode.
Enterprises usually introduce multiple tiers of models at the same time, including top models, advanced models and high value for money models. However, not all missions require the use of the most capable and expensive models, and they need to be automatically selected according to the difficulty of the task.
The Seal Auto model uses a hybrid strategy. The system first uses a 30B MoE model to determine the difficulty of the task, while intervening through the rule system.
For example, the model route cannot be compared to the unit price, but must also consider whether cache was hit. Even if the price of a model is higher, the actual cost after cache hits may be low.
In addition, we have designed a full-scale disaster management programme for routed systems. If Router itself is not available, or if the recommended model is temporarily unavailable, the system will implement the corresponding Fallback policy.
Online greyscale data show that over 70 per cent of day-to-day assignments within the company are based on a high-value model, about 22 per cent require advanced models and only about 3 per cent require top models.
The Auto model saves about 69% of the model costs compared to the one used by all users. Enterprises can also dynamically adjust the routing of different models to their own budgets.
Agent Upgrade: Why Prioritize Memory
Although Seal is based on OpenClaw, we still need to judge which core competencies deserve further input. The team focused on two directions: enhancing Memoory, and giving Skyll an iterative capacity. If resources are sufficient, both can certainly go hand in hand. However, the REDnote team is relatively lean and must have clear priorities.
Our judgment is that at this stage, Skill is not the first priority.
The number of Skills that are actually used at high frequency within the enterprise is not as large as it could have been imagined, and is usually concentrated on data platforms, database platforms, publish platforms, and internal platforms for products and operations. Their scope is clearer. First of all, this core of Skill gets a lot of money.
It's more common and more urgent than memory. The user of Seal has expanded its research and development staff from the AI Coding scene to different types of work within the company. Users should not first understand what is used as a personal assistant. It's like people can use mobile phones, but they don't need to know how to operate. If the user finds the AI assistant difficult to use, the problem is not necessarily that the user does not understand AI, but more likely the product capacity is not sufficiently mature.
We've been receiving a lot of feedback about why AI's assistant became stupid after a while. Why didn't he remember what he said before?
This indicates that memory has become a real and universal user pain point.
The problem of the mechanisms of primary memory
In practice, OpenClaw was born Memory with several clear problems.
First, memory is over-reliant on active user alerts. The user must clearly tell Agent “Remember this” before it writes about memory.md.
Second, when the dialogue is compressed or the user is creating a new session, there is a high risk of visible memory loss. Worklog, too, is more like a flow book, and even if it is loaded, it does not really help Agent understand and use past information.
In addition, memory promotion mechanisms are complex and audit capacity is inadequate. It is difficult for users to know exactly which conversation a long-term memory came from.
When we measured, even for a longer period of time, the content that was actually promoted to long-term memory was still very small. Correspondingly, existing mechanisms are also weak in terms of memory forgotten.
From Session to Worklog, to long-term memory
In response to these questions, we divide the Seal memory system into three levels.
The first level is Ssession, the current dialogue context. Information that must be used, such as SOUL.md, the user 's important resource and key preferences, is loaded directly into System Prompt.
When the conversation is compressed, the user creates a new session, or the system performs a time-scanning at night, we sink the facts of the conversation to the second level of Worklog.
Worklog is equivalent to the L1 layer, which primarily acts as a buffer of facts and evidence preservation. These elements will not be handed over to Agent without screening, but rather provide a retroactive source of fact for subsequent long-term memory.
The third floor is long-term memory. Worklog will be compiled and collated on an ongoing basis, transforming the facts into structured, relevant and up-to-date Memoory Wiki.
This mechanism is not traditional RAG. We'll have the model translate the facts into structured Wiki in advance and establish a clear catalogue and linkages.
long-term memory is divided into two parts: one is what has to be injected, such as important memories related to the strength of the individual Profile; the other is what is recalled as required and will not be fully loaded in each dialogue.
We will provide the Memory Wiki catalogue structure to the model to determine whether the current task requires a search of memory. If necessary, Agent can find the corresponding content through the file search tool, as is the case with people who read books.
After this enhancement, memory is no longer just a simple memory.md file, but a real personal knowledge, Wiki. The themes, entities and important facts that users discuss on a daily basis can be documented on their own initiative and retrieved and used as needed in follow-up dialogues.
From personal memory to corporate memory sharing
The current memory system is still based mainly on local documents. And then we set two important directions.
The first direction is from the local towards the cloud. The same user often uses multiple Agent products at the same time, such as AI Coding Agent and Personal Assistant Agent. How to share the same individual memory among different Agents is difficult to solve by local documents alone and ultimately depends on cloud memory systems.
The second direction is to move from a one-time mission to a knowledge sank. Many AI applications are still “defunct”: users do one mission or one demand with Agent, and the next one starts from scratch, without the knowledge they have accumulated.
Based on Memory's enhanced practice, we can continue to abstract project dimensions, code warehouse dimensions, demand dimensions, and even organizational dimensions, and eventually develop enterprise-level shared memory systems.
From tools to ecology: making everyone a Builder
When an AI tool is widely applied within the enterprise, the product itself is not enough. Further expansion of productivity requires the construction of surrounding ecosystems so that capacity can be created, shared, reused and disseminated.
Seal has built two main types of ecological capacity: Skyllhub for the reuse of Agent capabilities and CoWork Studio for publish AI Coding.
In the Seal internal survey phase, we thought Skillhub was an indispensable function. On the one hand, the external Skill, which has been cleared and confirmed as safe, can be introduced into the company; on the other hand, Skill, prepared by the company ' s own staff, can be uploaded to Skillhub in a Seal sentence, both from the platform team and from individuals. When other users encounter the corresponding scene, Seal can automatically scan and install the Skill required.
Initially, our design for Skillhub was relatively simple, mainly around publish and subscriptions. But when they actually landed, they found that Skill within the firm had more diverse management needs. The first category is platform or official Skyll. This type of Skill requires long-term support and maintenance by a clear and responsible team.
The second category is the individual Skill, which is created by the employee according to his or her work needs. One interesting thing is that a lot of individuals, Skill, have emerged before the official version. The platform team only started to operate after the staff had created and widely disseminated a Skill. Skillhub has, to some extent, contributed to the AI and Agentization of the internal platform of the company.
The third category is private Skill. For example, systems such as HR, Finance, which involve sensitive data, Skill itself may also contain sensitive information and therefore cannot be made available to the entire population and need to be shared and used within a limited range.
Through such a classification, Skillhub can support capacity-sharing at different levels: public, team and private.
More than a month after Seal went online, Skillhub had over 9000 Skills, of which the inside Skills exceeded 800. There are about 100 platforms and official Skills, about 136 teams, and the largest number of Skills is still created by individuals.
The data also show that most of the Skill calls are concentrated on Top 100 and Top 200. This is further evidence of our earlier judgement that, at this stage, rather than devoting significant resources to studying all of Skill ' s trajectories, priority should be given to optimizing and operating the head of Skill.
Skill addresses the issue of re-use of capacity. We have also observed another change after the widespread use of Seal: production relationships within enterprises are changing. Human Rights, Finance, Sales and other non-R&D jobs began to build their own tools through AI Coding. Technical students have developed an AI interview desk, HR students have created an award platform and finance students have developed a GPU demand and budget management platform.
In the past, staff need to be presented to product, R & D or mid-stage teams when there is a need, pending assessment and scheduling. Now, a lot of people can go directly to AI to do their needs quickly. When AI lowers the software construction threshold, everyone can become Builder.
In order to make these products more than just personal computers, we introduced CoWork Studio. The product created by the employee via AI Coding can be uploaded with one key and publish as an available website for direct use by others. One of them is an “inspiration blind box”, which was created by students of the product. It collects feedback from real users of REDnote, who click on it to get a random product inspiration. Students have also developed an application to generate technical questions or interviews based on personal portraits.
The value of CoWork Studio is that every products created by Builder can be seen, reused and disseminated. It not only improves individual efficiency, but also provides opportunities for decentralized creativity to be translated into corporate capacity-sharing.
Next generation AI agent: From passive mission to active target delivery
From ChatGPT to AI Coding, to OpenClaw and Seal, the ability of AI agent has clearly evolved: at first, it was only possible to complete questions and answers, and now it is possible to perform specific tasks “with hands and hands”.
However, the current AI agent is still primarily oriented towards a single mission. It needs someone to tell it what to do and then to complete a delivery. We believe that the next generation of AI agent needs to continue in three directions.
The first direction is to be more proactive. For example, teams identify a range of to-dos after each weekly meeting, but after the meeting these Todos often lose context or may be left unattended for a long time. The next generation of AI agent should be able to sense what to do with a team that has not yet been completed, understand the context in which they are generated and proactively alert the people concerned. It can even contribute directly to the task of clear borders.
The second direction is from mandate-oriented to goal-oriented delivery. The future Agent may have a relatively independent identity like an employee. The organization sets a target according to its range of capabilities, where it autonomously plans the implementation process and continues to sink its own Memoory and Skill as it advances its objectives.
The third direction is more Agent synergy. At this stage, it is difficult to solve all problems with a fully generic Agent. There is a natural and substantial division of professional work within the enterprise, so Agent Team and Agent must be the focus of the next generation of AI agent.
Seal has been able to achieve full coverage within a period of one month, from three persons to three days, first relying on rapid validation, rapid iterativeization and fast-scale project mechanisms. But when the product actually enters the enterprise, what determines its long-term viability is the capacity of systems such as safety, cost, memory and ecology.
Practice shows that an Enterprise-level AI assistant cannot be just a model entry. It requires a safe operating environment, sustainable cost management, memory systems that can accumulate over time, and an ecological environment that enables employees to create and reuse together. It is only when AI assistants begin to understand individual, sedimentary organizational knowledge and move from a single mission to a proactive delivery target that they can truly become the next generation of productivity infrastructure in an enterprise.
Presenters:
Monkhongjin, REDnote AI Coding and the Director-General of AI Applications and General Architect. Leading the development of the REDnote self-study AI Coding Tool CodeWiz, deep integration of in-house research and development of ecology; and leading the construction of the Enterprise-level AI Personal Assistant Seal, based on OpenClaw, with full coverage. Deep till Agent architecture design, Agent Infra large-scale engineering and LLM application landing, dedicated to remodeling corporate R & D and office patterns with AI.
The meeting recommended that:
On December 18-19, the Aicon Global Congress on Artificial Intelligence Development and Applications will be held in Beijing. The Congress, which focused on exploring the boundaries of application A, set up 13 major technical topics covering the core directions of LLM post-training, reasoning optimization, Agent engineering, intellectual engineering, AI agent assessment and security, self-evolution systems, AI software delivery, original architecture and organizational change, bringing together first-line technical experts to share in depth the real practices of AI technological breakthroughs and enterprise sizes.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.