把企微团队空间做成可治理可扩展的 AI 工作台

很多团队在接入 AI 助手时，都会经历一个很像的阶段。

一开始特别顺。

接一个模型，拉一个机器人进群，配一段 prompt，跑几轮问答，大家都会觉得，这事已经成了。

但真正的问题，往往不是“它今天答得好不好”，而是下面这些更现实的工程问题：

多个成员一起用，空间怎么隔离？
公共知识和个人记忆怎么分层？
管理员和普通成员，看到的内容能不能不一样？
文档、代码、检索这些完全不同的任务，能不能别都塞给一个 agent？
换一台服务器时，能不能不要再靠手工抄配置？

这篇文章想分享的，不是一套“AI 很聪明”的展示，而是一套更接地气的实践：

我们怎么把一个企微入口，慢慢做成一套可治理、可扩展、可复制的团队 AI 工作台。

30 秒版本

一句话概括：

我们不是在企微里放了一个聊天机器人，而是在企微里搭了一套 team workspace。

对成员来说，使用方式很简单：

在企微里像平时一样发需求
初始化自己的个人空间
在自己的任务、笔记、learnings 里持续沉淀

而系统在背后自动做的，是更重要的基础工作：

把共享层和私有层分开
把团队记忆和个人记忆分开
把管理员和普通用户边界分开
把不同重任务显式委派给不同 sub-agent
把部署过程逐步脚本化，尽量可复制

一、为什么很多 AI 助手看起来能用，但最后跑不久

我越来越觉得，很多团队的 AI 系统不是死在“模型不够强”，而是死在“结构不够稳”。

一开始大家最关心的是：

回答准不准
模型强不强
能不能写日报
能不能帮忙看代码

这些当然重要。

但一旦真的开始多人协作，你会发现真正把系统拖垮的，通常是这些问题：

所有人共用一个上下文，越用越乱
共享资料和个人资料混在一起
某个人的偏好会无意间污染全局
代码任务、文档任务、检索任务都挤在同一个入口里
新机器部署一次，和重新造轮子差不多

所以这次做 team 空间，我们反过来思考。

不是先追求“再多一个能力”，而是先把系统边界做出来。

二、这套 team 空间现在到底长什么样

先看当前空间结构：

~/.openclaw/teams/chanpin/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── shared/
│   ├── knowledge/
│   └── configs/
│       ├── admins.json
│       └── roles.json
├── users/
│   ├── _map/
│   └── <userid>/
│       ├── profile.md
│       ├── tasks.md
│       ├── preferences.md
│       ├── notes/
│       ├── .learnings/
│       └── tasks/cron/
├── memory/
│   ├── shared/
│   └── users/
├── skills/
├── agents/
└── scripts/

这个目录看起来很多，但它其实对应的是一套很明确的治理结构。

第一层，规则层

AGENTS.md
SOUL.md
USER.md
MEMORY.md

这层决定系统怎么说话、怎么做事、长期经验怎么沉淀。

第二层，团队共享层

shared/knowledge/
memory/shared/

放团队规范、FAQ、部署经验、可复用模板。

第三层，成员私有层

users/<userid>/
memory/users/<userid>/

放成员个人任务、偏好、笔记、学习闭环和长期上下文。

第四层，自动化层

scripts/

把初始化、权限判断、cron 元数据、learnings 写入这些容易出错的动作脚本化。

也就是说，这不是单纯的“目录整理”，而是在给团队搭一个 AI 工作空间操作系统。

三、这个空间到底具备哪些能力

先用表格快速展开。

能力模块	当前状态	关键落点	主要价值
企微统一入口	已落地	`wecom-chanpin`	所有成员从一个 team 入口进入
独立 team workspace	已落地	`~/.openclaw/teams/chanpin`	团队空间和默认 workspace 隔离
共享/私有空间分层	已落地	`shared/`、`users/<userid>/`	公共资料与个人资料分开
三层记忆机制	已落地骨架	`MEMORY.md`、`memory/shared/`、`memory/users/`	公共经验和个人记忆分层
用户空间初始化	已落地	`init_user_space.sh`	成员自动拥有自己的完整空间
权限模型	已落地最小闭环	`admins.json`、`roles.json`、`query_scope.sh`	管理员/普通用户边界初步建立
用户级 cron 元数据	已落地最小闭环	`tasks/cron/`、`manage_user_cron_meta.sh`	为个人提醒和调度能力打底
独立 self-improving-agent	已落地最小闭环	`.learnings/`、`write_learning.sh`	不同成员的 learnings 不再互相污染
sub-agent 分工	已落地方案	writer / code / research	不同重任务不再塞给一个 agent
deployer	已落地骨架	`03-Projects/wecom-v61-deployer/`	新服务器部署更可复制

如果只看表格，你会发现一件事。

这套系统真正有价值的，不是“一个功能点”，而是它开始具备了完整的组织结构。

四、真正的核心，不是“多智能”，而是“可治理”

如果让我总结这套方案最核心的价值，我不会先讲模型。

我会先讲三个词：

分层
隔离
治理

1. 分层

我们把信息分成：

会话层
team 共享层
用户私有层

这样做的好处，是让系统终于能回答：

哪些东西该共享？
哪些东西只能留在个人空间？

2. 隔离

每位成员都拥有自己的：

任务入口
偏好入口
笔记入口
learnings 入口
cron 元数据入口
私有 memory 入口

这意味着 AI 系统开始有成员级上下文，而不是全员共享一个大脑。

3. 治理

我们还补上了管理员/普通用户边界。

默认规则很简单：

普通用户，只能看自己目录、自己任务、自己 learnings
管理员，才允许看公共配置、全局任务、系统状态
没显式命中管理员身份时，默认按普通用户处理

这一步可能不炫，但非常关键。

因为团队系统一旦开始接：

共享知识
系统状态
调度任务
部署配置

没有治理边界，迟早会失控。

五、sub-agent 模式，为什么是这套系统的关键升级

这一部分我想单独展开讲。

因为很多人做 AI 助手时，默认会走一条路：

让一个主 agent 负责所有事情。

一开始这很方便。

但问题很快就会出现：

文档写作和代码分析是两种完全不同的任务
检索研究和执行型任务对上下文的要求不同
不同任务对模型、输出格式、长度、精度的要求都不一样

如果这些都压在一个 agent 身上，最后会出现三个问题：

上下文越来越混乱
输出质量开始摇摆
后续模型分层和成本治理很难做

所以我们后来明确采用了 sub-agent 模式。

1. 什么是 sub-agent 模式

不是让主 agent 在 prompt 里说一句“你现在扮演写作专家”，而是：

主 agent 接住用户请求
判断任务类型
对重任务显式调用 sessions_spawn
真正委派给对应子 agent

也就是说，这不是“角色扮演”，而是“结构化分工”。

2. 当前的子 agent 分工

现在至少有三类角色：

writer：日报、周报、总结、会议纪要、润色、文章整理
code：代码问题、报错排查、接口设计、技术方案
research：规范查询、知识检索、资料整合、长文总结

3. 为什么这种方式更稳

因为它把原本混在一起的东西拆开了：

任务类型拆开
上下文边界拆开
输出协议拆开
后续模型分层拆开

这样一来，系统更容易持续演进。

比如：

writer 以后可以走更偏写作的模型
code 以后可以走更偏代码的模型
research 以后可以走更偏长上下文或检索增强的模型

4. 为什么这一步特别重要

我觉得 sub-agent 模式，是这套 team 空间从“机器人”升级成“工作台”的关键点。

因为一旦开始显式分工，后续很多能力都会更顺：

任务路由
模型分层
成本治理
日志追踪
回传结果

它不仅提升能力，也提升结构清晰度。

六、现在这套系统怎么落地使用

讲到这里，如果你问：那这套系统今天到底能怎么用？

我会建议从下面几个场景开始。

场景 1，统一企微入口

所有成员都从企微入口发起：

问题咨询
文档整理
代码求助
初始化空间
查询自己的任务与记录

这样入口统一，规则也统一。

场景 2，初始化成员空间

成员第一次进入时，自动生成自己的：

profile
tasks
preferences
notes
learnings
cron 目录
私有 memory

这一步很基础，但它决定了后续所有成员级能力有没有落点。

场景 3，成员独立学习闭环

每位成员都有自己的：

LEARNINGS.md
ERRORS.md
FEATURE_REQUESTS.md

这意味着成员自己的 learnings 不会默认污染别人。

场景 4，用户级提醒与调度元数据

虽然当前 cron 还更接近 Gateway 级调度，但 team 层已经有：

tasks/cron/
manage_user_cron_meta.sh
list_user_cron_meta.sh

所以后续做：

个人提醒
个人日报/周报触发
管理员查看全局任务

都已经有了稳定基础。

场景 5，显式委派重任务给 sub-agent

比如：

写日报、整理纪要，交给 writer
代码报错、方案分析，交给 code
查规范、整合资料，交给 research

这样系统不会因为“一个入口全都做”而越来越乱。

七、为什么我们还在持续推进 deployer

如果一套系统只能在作者自己的电脑上跑，那它就不是方案，只是一段实验。

所以我们一直在推进 deployer，把能脚本化的尽量脚本化。

现在 deployer 已经能做这些事：

建 team 目录
写 openclaw.json
写 approvals
安装 templates
安装 skills / roles
安装治理脚本
做基础验收

更重要的是，它现在不仅装目录和配置，也开始能把治理能力一起装出来。

比如：

权限解析脚本
用户级 cron 元数据脚本
learnings 写入脚本

这说明它已经不再只是“初始化工程目录”的工具，而是在逐渐变成真正的安装器。

八、这套方案现在还差什么

我也不想把它说得太完美。

今天这套系统，已经把治理底座做出来了，但还差最后几段接线：

team 入口还没完全自动接权限判断
用户级 cron 还没真正联动到系统调度器
管理员全局视图还没完全独立实现
learnings 提升到共享层还没形成明确流程
自动巡检报告还没完全产品化

但我反而觉得，这说明方向已经对了。

因为现在缺的，不是重新设计系统，而是把最后几根线接上。

九、最后一句话

如果让我用一句话总结，我会说：

我们不是在企微里放了一个机器人，而是在企微里搭了一套有边界、有记忆、有权限、有分工能力的 AI 工作台。

它今天还不是终态。

但它已经不是演示型 AI 了。

它已经开始像一套真正能服务团队协作、能持续生长、能不断迭代的系统。