2026年4月11日 · 阅读 —

PPT版:teams 空间介绍与功能亮点

AI 工程实践

PPT版:teams 空间介绍与功能亮点

用途:适合作为 PPT 初稿或演讲页脚本。建议一页一节,按标题拆页。


第 1 页:标题页

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

副标题建议:

  • 从“一个机器人”到“一个团队 AI 工作空间”
  • 从“能聊天”到“可治理、可复制、可演进”

分享人:

  • Alan / 产研团队

第 2 页:为什么要做这件事

很多团队接 AI 的第一步都很快:

  • 拉机器人进企微
  • 接模型
  • 配 prompt
  • 跑通问答

但真正难的是后面:

  • 多成员一起用,怎么隔离?
  • 公共知识和个人记忆怎么分层?
  • 管理员和普通成员能不能看不同内容?
  • 文档、代码、检索任务能不能分工?
  • 部署到新服务器时能不能别重来一遍?

核心问题:不是“能不能用”,而是“能不能长期稳定地用”。


第 3 页:一句话结论

我们做的不是一个聊天机器人

而是:

一套企微内的团队 AI 工作台(team workspace)

它具备:

  • 独立团队空间
  • 成员私有空间
  • 共享知识层
  • 三层记忆机制
  • 权限边界
  • 子 agent 分工
  • 脚本化部署器

第 4 页:整体架构概览

企微统一入口
   ↓
wecom-chanpin 主 agent
   ↓
任务识别 / 权限判断 / 空间落点
   ↓
共享层 + 用户私有层 + 子 agent 委派 + 脚本能力

关键词:

  • 单入口
  • 独立空间
  • 分层治理
  • 显式委派
  • 脚本化部署

第 5 页:核心能力全景图

模块亮点
统一入口所有成员通过同一个企微入口进入
team workspace团队空间与默认 workspace 隔离
共享/私有分层公共资料和个人资料分开
三层记忆会话层、共享层、用户私有层
权限模型管理员 / 普通用户边界明确
用户空间模板每位成员自动拥有自己的 profile/tasks/preferences/notes/learnings
用户级 cron每位成员拥有自己的 cron 元数据目录
独立 self-improving-agent每位成员独立 learnings
sub-agent 模式writer / code / research 显式分工
deployer新服务器可复制部署

第 6 页:teams 空间目录结构

~/.openclaw/teams/chanpin/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── shared/
├── users/
├── memory/
├── reports/
├── skills/
├── agents/
└── scripts/

这一层的意义:

  • 不再把 AI 系统当成一段 prompt
  • 而是把它做成一个有目录、有规则、有资产沉淀的工程空间

第 7 页:共享层 vs 私有层

共享层

  • shared/knowledge/
  • memory/shared/
  • shared/configs/

适合放:

  • 团队规范
  • FAQ
  • 模板
  • 部署经验
  • 公共 learnings

私有层

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

适合放:

  • 个人任务
  • 个人偏好
  • 个人笔记
  • 个人 learnings

价值:让公共资产和个人上下文彻底分开。


第 8 页:三层记忆机制

会话层

  • 当前任务临时上下文
  • 调试证据

team 共享层

  • 公共规则
  • 通用经验
  • 可复用知识

用户私有层

  • 个人偏好
  • 个人任务记忆
  • 个人长期上下文

一句话理解:

不是记得越多越好,而是记得要分层、可治理。


第 9 页:管理员 / 普通用户权限模型

当前规则:

普通用户

  • 只能看自己目录
  • 只能看自己任务
  • 只能看自己 learnings

管理员

  • 可以看公共配置
  • 可以看全局任务
  • 可以看系统状态

默认策略

  • 没命中管理员身份,默认按普通用户处理

支持文件:

  • shared/configs/admins.json
  • shared/configs/roles.json

第 10 页:用户空间模板能力

每位成员初始化后,会自动获得:

  • profile.md
  • tasks.md
  • preferences.md
  • notes/README.md
  • .learnings/
  • tasks/cron/
  • memory/users/<userid>/README.md

这意味着:

成员不再只是“发消息的人”,而是拥有自己的 AI 工作空间。


第 11 页:独立 self-improving-agent

每位成员都有自己的:

  • LEARNINGS.md
  • ERRORS.md
  • FEATURE_REQUESTS.md

价值:

  • 不同成员的 learnings 不互相污染
  • 错误和修正能长期积累
  • 用户需求可以沉淀下来

新增进展:

  • 已支持把成员 learnings 提升到共享待审核区

第 12 页:learnings 提升共享层

当前已经补上的最小闭环:

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

当前机制:

  • 私有 learnings 可提升到共享待审核区
  • 默认状态:pending-review
  • 默认走人工确认
  • 不直接自动改 MEMORY.md

一句话:

个人经验开始具备“升级为团队经验”的路径。


第 13 页:用户级定时任务能力

当前已经有:

  • users/<userid>/tasks/cron/
  • list_user_cron_meta.sh
  • manage_user_cron_meta.sh

现在的进展:

  • 已支持元数据 add / get / remove
  • 已开始与真实 Gateway cron 做 job name 级联动

当前边界:

  • gatewayCronJobId 回填还没稳定收口
  • 但 name 级联动已经可用

第 14 页:管理员全局视图

当前新增:

  • list_global_cron_meta.sh

作用:

  • 管理员可查看全体成员的 cron 元数据概览
  • 为后续全局任务视图打基础

当前状态:

  • 脚本骨架已落地
  • 真实对话入口还没完全接通

第 15 页:team 权限入口骨架

当前新增:

  • team_gate.sh

作用:

  • 作为 team 层资源访问的统一入口骨架
  • 先接 action
  • 再做权限判定

价值:

  • 后续把权限逻辑接进企微消息入口时,不用重新设计

第 16 页:sub-agent 模式为什么关键

很多 AI 系统都会踩一个坑:

让一个主 agent 做所有事情。

这会带来:

  • 上下文越来越混乱
  • 文档任务和代码任务互相污染
  • 模型分层和成本治理困难

所以我们采用:

主 agent + 显式 sub-agent 委派


第 17 页:当前 sub-agent 分工

writer

  • 日报
  • 周报
  • 总结
  • 会议纪要
  • 文章整理

code

  • 代码问题
  • 报错排查
  • 接口设计
  • 技术方案

research

  • 知识检索
  • 规范定位
  • 资料整合
  • 长文总结

核心方式:

  • 主 agent 显式 sessions_spawn
  • 不是 prompt 里假装“扮演专家”

第 18 页:为什么 sub-agent 模式更稳

因为它把原来混在一起的东西拆开了:

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

它带来的不是一点点“更像专家”,而是整套结构更清晰。


第 19 页:脚本化部署器的价值

如果一套系统只能在作者自己电脑上跑,那它就不是方案,只是一次性作品。

所以我们持续推进 deployer:

  • 生成目录
  • 写配置
  • 安装模板
  • 安装 skills / roles
  • 安装治理脚本
  • 做基础验收

这意味着:

从“能搭起来”走向“能复制出去”。


第 20 页:当前 deployer 已具备什么

当前 deployer 已覆盖:

  • team 基础目录
  • AGENTS / SOUL / USER 模板
  • skills / roles / planning-chain
  • 权限配置
  • 用户空间初始化脚本
  • cron 元数据脚本
  • 管理员全局视图脚本
  • team 权限入口骨架

当前边界:

  • 巡检报告脚本已有骨架,但还没稳定落盘
  • cron id 回填仍待专项补强

第 21 页:当前真实进展判断

已经成立的

  • team 空间治理底座
  • 用户空间模板
  • 权限骨架
  • 独立 learnings
  • learnings 提升共享待审核区
  • 用户级 cron 元数据层
  • cron 的 name 级联动
  • sub-agent 分工方案
  • deployer 安装骨架

还没完全成立的

  • gatewayCronJobId 强一致回填
  • team 入口自动接完整权限判断
  • 管理员全局系统状态视图
  • 自动巡检报告稳定产出

第 22 页:这套方案解决了什么问题

从机器人,升级成工作台

  • 不再只有一个入口和一个 prompt

从能用,升级成可治理

  • 有边界、有隔离、有分层

从对话即结束,升级成对话能沉淀

  • learnings、知识、经验都能落盘

从一次性搭建,升级成可复制部署

  • deployer 已开始承担复制能力

第 23 页:一句话总结

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


第 24 页:下一步可以继续做什么

建议优先级:

  1. 把 team 入口权限判断真正接通
  2. 补 gatewayCronJobId 强一致回填
  3. 增强管理员全局系统状态视图
  4. 把 learnings 提升流程产品化
  5. 继续修复自动巡检报告输出

第 25 页:结束页

谢谢。

如果要一句话结束,我建议用:

AI 真正走进团队,不是从“更会回答”开始,而是从“更有边界、更能沉淀、更可治理”开始。