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

很多团队在接入 AI 助手时，第一步都很快。

拉一个机器人进企微，接一个模型，配一段 prompt，能聊、能答、能生成，看起来就像已经跑通了。

但真正决定这套系统能不能长期用下去的，往往不是“它今天答得好不好”，而是下面这些更工程、更现实的问题：

多个成员一起用，空间怎么隔离？
团队公共知识和成员私有记忆怎么分层？
管理员和普通成员，能不能看到不同范围的信息？
重任务能不能交给不同子 agent，而不是全塞给一个入口？
换一台服务器后，能不能尽量不靠手抄配置重新搭？

所以这篇文档不打算讲“AI 多聪明”，而是想回顾一套更实在的落地过程：

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

30 秒版本

一句话概括，这套系统已经从“一个会聊天的企微机器人”，升级成了“一个带治理能力的 team workspace”。

对于成员来说，最直接的使用方式其实很简单：

在企微里发需求，像平时找助手一样用它
在自己的用户空间里积累任务、偏好、笔记和 learnings

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

初始化每位成员的私有工作空间
区分共享层和私有层
为管理员和普通用户建立不同权限边界
为用户级定时任务、独立 self-improving-agent、子 agent 分工打底
把能脚本化的部署过程逐步沉淀成安装器

一、先看全景，这个 teams 空间现在具备什么能力

先不讲细节，先用一张表把当前能力铺开。

能力模块	当前状态	核心落点	主要价值	典型使用方式
企微统一入口	已落地	`wecom-chanpin`	全成员统一从一个 team 入口进入	在企微里直接提问、初始化、发任务
独立 team workspace	已落地	`~/.openclaw/teams/chanpin`	团队空间与默认 workspace 隔离	所有团队资料、规则、脚本都围绕该目录
共享/私有空间分层	已落地	`shared/`、`users/<userid>/`	公共资料与个人资料分开	团队规范进共享层，个人笔记进用户目录
三层记忆机制	已落地骨架	`MEMORY.md`、`memory/shared/`、`memory/users/`	共享知识和个人记忆不再混杂	公共经验进共享层，个人长期上下文进私有层
用户空间初始化	已落地	`scripts/init_user_space.sh`	每位成员自动拥有完整用户模板	自动生成 profile、tasks、preferences、notes、learnings
管理员/普通用户权限模型	已落地骨架 + 最小查询闭环	`shared/configs/admins.json`、`roles.json`、`query_scope.sh`	先把可见范围边界立住	管理员可看全局，普通用户默认只看自己
用户级定时任务元数据	已落地 name 级联动闭环	`users/<userid>/tasks/cron/`、`manage_user_cron_meta.sh`	为个人提醒、日报、周报等能力打底，并已开始联动真实 Gateway cron	写入、查看、删除个人 cron 元数据
独立 self-improving-agent	已落地最小闭环	`users/<userid>/.learnings/`、`write_learning.sh`	不同成员的 learnings 不互相污染	写入 learning / error / feature
learnings 提升共享层	已落地最小闭环	`promote_learning.sh`、`memory/shared/promotions/pending.md`	让个人经验开始可控地流向团队共享层	提升到待审核共享区
子 agent 分工	已落地方案	writer / code / research	重任务不由一个 agent 硬扛	文档、代码、检索分别委派
脚本化部署器	已持续演进	`03-Projects/wecom-v61-deployer/`	新服务器部署更可复制	写配置、装模板、装 bundle、做验收

如果只看这张表，你会发现这已经不是“一个机器人”的问题了。

它其实已经是一套小型团队操作系统，只是界面入口恰好放在企微里。

二、这套空间的目录树长什么样

当前可以这样理解这套 team 空间：

~/.openclaw/teams/chanpin/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── shared/
│   ├── knowledge/
│   └── configs/
│       ├── admins.json
│       └── roles.json
├── users/
│   ├── _map/
│   │   └── <userid>.json
│   └── <userid>/
│       ├── profile.md
│       ├── tasks.md
│       ├── preferences.md
│       ├── notes/
│       │   └── README.md
│       ├── .learnings/
│       │   ├── LEARNINGS.md
│       │   ├── ERRORS.md
│       │   └── FEATURE_REQUESTS.md
│       └── tasks/
│           └── cron/
├── memory/
│   ├── shared/
│   ├── users/
│   └── shared/promotions/
├── reports/
├── skills/
├── agents/
│   ├── planning-chain.md
│   └── roles/
│       ├── writer.md
│       ├── code.md
│       └── research.md
└── scripts/
    ├── init_team_space.sh
    ├── init_user_space.sh
    ├── resolve_role.sh
    ├── query_scope.sh
    ├── team_gate.sh
    ├── list_user_cron_meta.sh
    ├── list_global_cron_meta.sh
    ├── manage_user_cron_meta.sh
    ├── write_learning.sh
    ├── promote_learning.sh
    └── validate_install_report.sh

这个目录看起来多，但其实逻辑是清楚的。

你可以把它分成 7 个区：

规则区：AGENTS.md、SOUL.md、USER.md、MEMORY.md
共享区：shared/
用户私有区：users/<userid>/
记忆区：memory/
报告区：reports/
技能与角色区：skills/、agents/
自动化脚本区：scripts/

三、关键目录和文件分别是干什么的

1. 规则与长期边界文件

文件	作用	应该放什么
`AGENTS.md`	team 空间主规则	路由规则、技能使用规则、共享/私有边界
`SOUL.md`	助手人格和行为边界	语气、边界、工作风格
`USER.md`	使用者偏好	稳定偏好、沟通习惯
`MEMORY.md`	团队长期经验入口	团队公共规则、关键部署经验、长期设计决策

2. 共享配置文件

文件	作用	示例
`shared/configs/admins.json`	定义管理员名单	哪些 userid 具备 admin 身份
`shared/configs/roles.json`	定义角色权限	admin 能看全局，user 只能看自己

3. 用户私有文件

文件/目录	作用	典型内容
`users/<userid>/profile.md`	成员身份与初始化信息	userid、初始化时间、来源
`users/<userid>/tasks.md`	用户自己的任务入口	进行中、待处理、已完成
`users/<userid>/preferences.md`	用户偏好	输出语言、常用风格、工作习惯
`users/<userid>/notes/`	用户个人笔记	临时记录、长期事项、个人素材
`users/<userid>/.learnings/`	用户独立学习闭环	learnings、errors、feature requests
`users/<userid>/tasks/cron/`	用户级定时任务元数据	个人提醒、日报/周报元数据

4. 记忆与提升目录

目录	作用	边界
`memory/shared/`	团队共享记忆	适合通用经验和公共规则
`memory/shared/promotions/`	待审核提升区	成员经验先进入这里，默认人工确认
`memory/users/<userid>/`	用户私有记忆	只服务该成员个人上下文

5. 自动化脚本

脚本	作用	当前状态
`init_team_space.sh`	初始化 team 基础结构	已有
`init_user_space.sh`	初始化完整用户空间模板	已实现
`resolve_role.sh`	解析 userid 对应的角色	已实现
`query_scope.sh`	查询某个角色对某类资源是否可见	已实现
`team_gate.sh`	team 权限入口骨架	已实现骨架
`list_user_cron_meta.sh`	列出某用户自己的 cron 元数据	已实现
`list_global_cron_meta.sh`	管理员查看全体成员 cron 元数据	已实现骨架
`manage_user_cron_meta.sh`	对用户 cron 元数据做 add/get/remove，并按 job name 联动 Gateway cron	已实现，id 回填待补强
`write_learning.sh`	写入成员独立 learnings	已实现
`promote_learning.sh`	提升个人 learnings 到共享待审核区	已实现最小闭环
`validate_install_report.sh`	生成结构化巡检报告	已有脚本骨架，仍待修复落盘

四、这套空间最关键的设计，不是“多智能”，而是“可治理”

如果让我总结这套空间最核心的价值，我会优先讲四件事。

1. 共享层和私有层终于分开了

以前很多 AI 机器人其实只有一个隐形大脑，所有人都把信息往里面扔。

短期看很方便，长期一定会失控。

现在这套空间至少先把边界立住了：

团队共享的东西进 shared/ 和 memory/shared/
个人自己的东西进 users/<userid>/ 和 memory/users/<userid>/

这一步是后面所有治理能力的基础。

2. 管理员和普通成员不再默认“看一样的世界”

现在已经有：

admins.json
roles.json
resolve_role.sh
query_scope.sh
team_gate.sh

也就是说，权限模型已经不是写在脑子里的规则，而是开始有配置和脚本支撑。

3. 成员的 learnings 不再混成一锅，而且开始能提升到共享层

每位成员都有自己的：

LEARNINGS.md
ERRORS.md
FEATURE_REQUESTS.md

现在进一步补上的，是：

promote_learning.sh
memory/shared/promotions/pending.md

这意味着：

A 的错误不会默认污染 B
A 的偏好不会无意外溢给所有人
共享层只保留真正公共的经验
私有 learnings 已经有了通往团队共享经验的待审核通道

4. 用户级 cron 开始有“自己的空间”，并且已开始联动真实调度器

虽然现在还不是强一致调度产品，但最重要的结构已经有了：

tasks/cron/
manage_user_cron_meta.sh
list_user_cron_meta.sh
与真实 Gateway cron 的 job name 级联动

这使得未来做：

用户提醒
用户日报触发
用户周报触发
管理员全局查看

都已经有了稳定落点。

五、怎么落地使用，这里给几个实际示例

示例 1，初始化一个新成员空间

bash ~/.openclaw/teams/chanpin/scripts/init_user_space.sh zhangsan

执行后会自动创建：

users/zhangsan/profile.md
users/zhangsan/tasks.md
users/zhangsan/preferences.md
users/zhangsan/notes/README.md
users/zhangsan/.learnings/*
users/zhangsan/tasks/cron/
memory/users/zhangsan/README.md

示例 2，判断一个成员是不是管理员

bash ~/.openclaw/teams/chanpin/scripts/resolve_role.sh xulanzhong

示例 3，判断某个用户能不能看某类资源

bash ~/.openclaw/teams/chanpin/scripts/query_scope.sh xulanzhong global-tasks

示例 4，写入一个用户级 cron 元数据

bash ~/.openclaw/teams/chanpin/scripts/manage_user_cron_meta.sh add zhangsan daily_report "30 17 * * 1-5" "工作日 17:30 提醒我写日报"

查看：

bash ~/.openclaw/teams/chanpin/scripts/manage_user_cron_meta.sh get zhangsan daily_report

列出：

bash ~/.openclaw/teams/chanpin/scripts/list_user_cron_meta.sh zhangsan

删除：

bash ~/.openclaw/teams/chanpin/scripts/manage_user_cron_meta.sh remove zhangsan daily_report

说明：当前已经能按 job name 与 Gateway cron 做创建/删除联动，但 gatewayCronJobId 回填仍待补强。

示例 5，写入一个成员自己的 learning

bash ~/.openclaw/teams/chanpin/scripts/write_learning.sh zhangsan learning "日报提醒希望默认工作日触发"

示例 6，把个人 learning 提升到共享待审核区

bash ~/.openclaw/teams/chanpin/scripts/promote_learning.sh zhangsan learning "子 agent 显式委派比 hook 路由更稳，适合提升为团队共享经验"

这会写入：

memory/shared/promotions/pending.md

并默认标记为：

pending-review

六、部署器现在完整不完整

这个问题我直接给结论：

1. 现在比之前完整多了

因为此前 team 线上空间和 deployer 安装包有过一段“功能不同步”的时期。

刚刚这一轮我已经把新增治理脚本同步回 deployer 了，包括：

query_scope.sh
manage_user_cron_meta.sh
write_learning.sh
list_global_cron_meta.sh
team_gate.sh

所以当前 deployer 已经能覆盖这批新增治理能力。

2. 但如果问“是不是最终完整版”，答案还是不是

它现在已经是一个比较完整的安装器骨架，但还不是“最终成品”，主要还差：

入口层真正自动调用这些脚本
gatewayCronJobId 回填强一致
learnings 提升共享层的正式审核与分流机制
自动巡检报告稳定落盘

所以更准确地说：

它现在已经够你在新服务器上稳定复制这套 team 空间的核心结构，但还没到“一条命令完成所有产品闭环”的程度。

七、如果要做分享，我会怎么总结这套方案

如果是对内分享，我会这样讲：

我们不是在给企微接一个更会说话的机器人。

我们是在做三件更有长期价值的事情：

给团队建立一个统一的 AI 工作入口
给每位成员建立一个可沉淀、可隔离、可积累的私有工作空间
给整个系统建立一套可治理、可部署、可扩展的工程骨架

为什么这件事重要？

因为真正能长期跑下去的 AI 系统，拼的不是某一次回答有多惊艳，而是：

它的边界清不清楚
它的知识能不能沉淀
它的权限会不会失控
它的部署能不能复制
它的能力能不能随着团队一起长大

而这套 team 空间，恰恰是在往这个方向走。

八、最后一句结论

如果用一句话总结今天这套方案，我会说：

我们不是做了一个团队聊天机器人，而是在企微里搭了一套有边界、有记忆、有权限、有自动化能力的 AI 工作台。

它今天还不是终态，但已经不是“演示型 AI”了。

它已经开始像一套能真正落地、能长期迭代、能服务团队协作的系统。