小红书以主Agent和子Agent执行项目管理任务

小红书团队先在 1.0 阶段把 AI 当作项目管理顾问做知识问答（意图识别→知识库 RAG→大模型生成的工作流，并沉淀 10+ 类代表性 Case 的评测集），发现「知识问答做到极致对真实项目提效也只有 30%」，剩下 70% 是管理 todo、催进展、发通知、总结周报等执行动作。2.0 提出「Agent 规划 + Sub Agent 执行」设计原则，并落实三条约束：原子 Agent 必须自我闭环（执行期间不依赖 master Agent 再次介入，要么成功返回结果要么明确失败返回原因）、复合 Agent 通过原子组合解决复杂任务（如项目周报总结 = 读周报 + 读需求状态 + 汇总输出）、复合 Agent 不能互相嵌套（避免死循环与算力消耗）。易用性上把 Agent 推进到公司已在的内部办公 IM：统一通知能力剥离主流程（子 Agent 不再各自发消息，统一通过消息发送接口通信），并建立 Master Agent 与子 Agent 协议（子 Agent 返回标准 JSON 结构体，Master Agent 依字段自主决策）。最终实现项目文档审阅、知识问答、Todo 管理、周报总结、文档催更、需求定容管理 6 个场景能力上线，并在多个项目里真实跑起来。 公司落地通用 Agent 框架 OpenClaw 后，PMO 团队决定不重复造轮子：把过去一年沉淀的项目管理能力打包成 Skill 上架公司内部 Skill Hub，让所有员工用自己的 Claw 助理调用项目管理能力，并探索为每位 PMO 创建「项目管理个人分身」、基于开源 Agent 框架搭建 PMO Team Claw 集体喂养团队助理。智能化能力上完成长记忆四件套——UserProfile（偏好/行为/常问问题/关联项目四维画像）、SessionMessage（对话历史 DB→应用层→Agent 层三级缓存）、KnowledgeItem（5 类知识库，支持全文+标签搜索）、ContextBuilder（动态拼装上下文并自动压缩），解决 Workflow 模式下每次对话「失忆」、跨会话跨渠道无法积累理解的问题；同步全栈 Vibe coding 出自建项目注册平台，作为 Agent 上下文的唯一数据锚点，承载项目名/成员/文档空间/周会文档/IM 群/需求工具空间等核心主数据。结果是同一个 Agent 个人助理打通工作流平台、自建项目注册平台、IM 机器人三个平台，打通寒暄&自我介绍、项目知识问答、文档催更、周报总结、待办管理、需求查询、需求创建 7 个核心功能，三平台打通后用户数一个月内从十几人增至几千人。 3.0 是「1 人 × 1 Session」的个人私有助手，落地到具体项目时暴露出同一问题对不同角色答案完全不同（管理者关注目标达成与卡点、项目负责人关注全局进展与风险、项目成员关注自身依赖模块），而孤立 Session 无法共享项目上下文。4.0 把 Session 模型升级为「1 项目 × N 人 × M Session」：为每个项目组提供一套共享的多渠道动态项目上下文，每人独立的 Session 实例都从这套上下文取数，PMOBP Agent 定位为「首先是信息中枢，其次才是任务执行者」。实现上复用 OpenClaw 的 Gateway、Session 模型、Multi-Agent 编排、IM 插件、Skill 体系与稳定性机制，并接入 Knowledge 工程的三层渐进检索、定时知识整合、项目档案多源摄取，新增项目上下文路由（识别用户在问哪个项目）与角色感知（按管理者/项目负责人/项目成员自动调整回答粒度）两层专属能力。产出为 12 项已落地能力，覆盖信息查询（项目快照进展、按角色总结关注事项、查看 KO/结项文档）、资料生成（一键创建标准项目目录、模板获取、例会文档自动接续）、协同操作（私发/群发消息通知催更、机器人拉群并自动弹卡片绑定项目）、项目管理（Todo/进展增删查改、我的项目视图、项目群消息与例会智能总结写入知识库形成项目 context）；项目主数据平台当前已承载数百个项目的核心数据并持续扩展。