做产品这几年，我越来越觉得“个体效率”这件事还有上限，而“组织效率”基本没有天花板。于是我开始把AI不再当工具用，而是把它们当“员工”来带。最近，我在企业微信里用 OpenClaw + The Agency 养了 130 个 AI 员工，把一个看似无聊却每天都要面对的问题——快速读懂 OpenClaw 的版本变更——做成了一张能点、能筛、能追溯的“龙虾星图”。整个过程几乎是 100% 口述驱动，真正意义上的 vibe coding。顺手把踩过的坑、组织方法论和一些对模型与工程抓手的判断，打包成这篇复盘。

小产品，大组织：龙虾星图背后的“产品动机”

OpenClaw 更新飞快，Release Note 又是扁平长文。人眼扫一遍，信息密度很高，但要回答这类问题——“这次更新主要动了哪些模块？”“关键词xxx最近三个版本出现在哪些地方？”“新增还是变更？”——其实很费劲。

于是有了一个可视化星图：

• 筛选维度：版本号、模块名、关键词、feature更新类型
• 交互方式：点击节点或模块（如 Gateway、CLI）右侧展示详细变更
• 数据更新：用 OpenClaw 的 cron job 定时爬 openclaw 仓库保持最新

地址在这：https://tclaw.aigc.green/graph.html。

项目目标设得很简单：

• 把“读一次更新笔记”的时间从分钟级降到秒级
• 确保全量性：不上游拉齐不见天日
• 适配“嘴控开发”，尽量让 Agent 自己把活干完

为了让它跑起来，我在企微里搭了一个“临时团队”——OpenClaw 主代理作为指挥，The Agency 的 130 多个模板 Agent 作为执行者。听上去很炫，其实最难的是组织设计。

把 Agent 当员工带：我踩过的五类坑

1. 沟通和执行分不开，活就散了：sessions_spawn 是“组织边界”

很多时候，OpenClaw 的主 Agent 会在同一个会话里一边跟我聊天，一边上手干活，最后沟通上下文和任务上下文缠成一团，输出质量肉眼可见地滑坡。解决方案很朴素：把沟通和执行拆成不同会话，明确用 sessions_spawn 启动子会话。

实践中我会用非常直接的指令：

请采用 sessions_spawn 模式启动 sub-agent 来完成【任务描述】；主会话只保留沟通与调度。
若需指定执行人：请采用 sessions_spawn 启动 agent-YYY 来完成【任务描述】，你负责编排与验收。

如果你的 OpenClaw 只有主 Agent 一个“灵魂”，spawn 出来的只是影分身，SOUL.md、IDENTITY.md 都是通用配置，什么都懂一点，什么都不精。这时与其往一个 MD 里塞一堆特化提示，不如直接引入专家型模板。

2. 130 个专家怎么管：把 The Agency 当作“组织结构图”

The Agency（https://github.com/msitarzewski/agency-agents）把专家模板按“部门”打了个齐活：工程、设计、营销、销售、付费媒体、产品、项目管理、测试、客服、空间计算、专项服务、游戏开发……130+ 个角色，覆盖从前端、后端、DevOps 到法务、合规、供应链。

目前Agency-agents项目已经创建出来130多个专家Agents。
以下是The Agency包含的所有Agent模板，按部门分类：

🏗️ Engineering（工程部）- 23个

🎨 Design（设计部）- 8个

📈 Marketing（营销部）- 26个

💼 Sales（销售部）- 8个

💰 Paid Media（付费媒体部）- 7个

📦 Product（产品部）- 4个

📋 Project Management（项目管理部）- 6个

🧪 Testing（测试部）- 8个

🎧 Support（客服部）- 6个

🥽 Spatial Computing（空间计算部）- 6个

🎯 Specialized（专项服务部）- 20+个

🎮 Game Development（游戏开发部）- 8个

如果想安装这100多个Agents，可以在企微中跟openclaw的main Agent这么说：

请阅读并理解该Github仓库:
https://github.com/msitarzewski/agency-agents
然后将里面的全部agents安装为你(openclaw) 的sub-agents；并在未来的工作中尽量使用sessions_spawn方式来调用其中合适的sub-agents来执行任务，而你作为Orchestrator负责任务的指挥和调度。

几分钟后，main Agents会告诉你安装完成，之后就可以采用sessions_spawn（sub-agents）模式来工作了~

我的做法更像在建团队：

• 把主 Agent 定位为 Orchestrator，仅做指挥与质检
• 按任务类型派单：数据抓取给 Data Engineer，图谱构建给 Frontend/Visualization，调度与监控交给 SRE/DevOps
• 给每个任务一个 spawn 会话，命名规范统一，便于检索与复盘

在企微里我会这么下发“入职”指令：

请阅读并理解该仓库：https://github.com/msitarzewski/agency-agents
将里面的全部 agents 安装为你的 sub-agents；
后续任务尽量使用 sessions_spawn 调用合适的 sub-agents 执行，你作为 Orchestrator 负责调度与验收。

几分钟后主 Agent 会回“安装完成”。至此，你就拥有了一张可扩展的“AI组织结构图”。别忘了设置派单规则和验收准则，否则只是在堆人数。

3. 上下文挤爆是日常：把“记忆管理”当运维

企微里龙虾突然不回了？十有八九是上下文窗口快满。终端里 openclaw status 能看到状态；WebUI 的 compacting 在某些版本会卡住；/compact 在企微里也可能报错。稳定的姿势是进 TUI 手动压缩：

openclaw tui
/compact

这件事不该靠运气，我做了几项“运维化”改造：

• 分层日志与日结摘要：长对话定时生成日报，替换早期细碎历史
• 会话保鲜期：执行会话在任务关闭后自动归档，沟通会话长期保留
• 大 chunk 任务外置：文档与代码上下文走外部存储，引用 ID 而非全文灌入
• 定时 /compact：用 cron 在低峰定时压缩，避免人工救火

这看似繁琐，但一旦把“上下文”当容量规划问题对待，系统稳定性会好很多。

4. 模型选型不是“谁会写代码更强”，而是“谁更会带队”

同样的任务，用国内一些大模型单兵作战能完成，但接入 OpenClaw 并要求主 Agent 在 sub-agents 模式下高效编排，问题就暴露了：计划松散、任务切分不稳、子代理交互成本偏高。切换到 GPT-5.4 后，调度和协作突然顺滑，体验像换了发动机。有人称它是“OpenClaw 天选大模型”，这次我是真切认同。

不妨把“模型能力”换个标尺：不是纯编程能力，而是“在多角色多会话里做计划、派单、验收”的组织力。为了避免押宝，我现在会做一个最小化验证：

• 三阶段可用性：分解计划、派单协作、结果汇总，分别打分
• 两类基准任务：结构化抓取 + 前端可视化，覆盖 I/O 与 UI
• Canary 路线：生产只放 10% 任务给备选模型跑，观察七日
• 回退脚手架：任何模型随时可切换到备用 without 破坏会话

一句话总结：在多 Agent 场景里，模型的“组织执行力”比“单点能力”更重要。

5. 开发环境选云，不是为了酷，而是为了“上线路径短”

我用的是腾讯云轻量应用服务器的“🦞版”。把 DNS 指向这台机器后，你在企微/飞书里动动嘴，网站就能上线。对于快节奏验证，这种爽感很真实。更关键的是：

• 稳定公网入口：便于计划任务和 Webhook 对接
• 环境一致性：比本地更可控，复现问题更快
• 安全与分层：把执行与可视化分容器部署，权限收紧

细节部署我在另一篇“保姆教程”里写过，这里不展开。

组织心得：把“Harness Engineering”摆在桌面上

OpenClaw 的内核偏轻量 Pi Agent，它不是 Claude Code/Codex 那类特化 coding agent。我的分工现在很明确：

• OpenClaw 做“组织”：信息收集、轻量自动化、文件与邮件、简单站点
• Coding Agents 做“重活”：复杂代码生成、长链路调试、深度重构

这就是 Harness Engineering 的边界：用对绳索，马才能跑得快。混用没问题，但要把“谁是指挥、谁是干将、谁是质检”写清楚，否则就是一场热闹的群聊。

能复用的清单：把方法落地

如果你也想在企微里拉起一支 AI 小团队，不妨照着这套走：

• 目标与度量：定义 1~2 个显性指标（例如“从发布到看懂主要变更≤30秒”）
• 角色与边界：主 Agent 只做编排，子 Agent 专注执行，命名规范化
• 会话与记忆：沟通/执行拆会话，定时 compact，长文外置引用
• 模型与路由：多模型并存，设 canary，随时回退
• 交付与验收：任务卡片化，Who/What/By-When/Accept-Criteria 写在派单里

示例派单模板丢在这里，能直接用：

任务：抓取 OpenClaw Release Note 并生成星图数据
你是谁：Data Engineer（sub-agent）
输入：仓库地址与版本区间
产出：标准化 JSON（含 version、module、type、keywords、summary）
约束：去重、保持字段稳定、失败自动重试 3 次
验收：通过 20 条样例校验与 schema 校验
时间：30 分钟
沟通：仅在主会话报告进度与阻塞

结语：带 AI 员工，和带人一样

带人这事，说到底是把目标讲清楚，把边界画清楚，把反馈建起来。带 AI 也一样。OpenClaw + The Agency 这套组合，像是一张组织骨架；模型选择像是挑核心干部；sessions_spawn 是工位与会议室的划分；而上下文管理就是工位的收纳与清洁。把这些“组织性工作”做好，口喷开发就不再是灵光一现，而是可复制的生产线。

今天的复盘到这。星图继续更新，组织也会迭代。愿每个产品人，都能带出一支真正能打的 AI 团队。