> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Lark CLI + Botmux：从 AI Developer 到 AI Employee Operating Layer

**一句话结论：**`Lark CLI + Botmux` 组合起来，不只是“让 AI 在 Lark
里写代码”。更大的机会是做一层 **AI employee operating layer**：Lark
负责人类工作入口和协作对象，Botmux 负责长期 AI CLI runtime，Lark CLI
负责精准读写 Lark workspace，Beads/devbot DB 负责任务和状态 source of
truth，policy/audit/measurement 负责把它从“远程 AI
shell”变成可卖给老板的员工系统。

最适合的第一步仍然是 **AI Developer**，因为代码任务有 GitHub
Issue、branch、PR、test、review、post-merge efficacy
这些可验证闭环。但产品的上限不止工程师，还可以扩展成 research
employee、project manager employee、BD analyst、knowledge librarian。

# 0. 我整合了哪些上下文

| 上下文                      | 我采用的要点                                                                                                                                                                         | 影响的判断                                                                  |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| devbot 设计文档              | Lark Doc ↔ AI software development agent bridge；autodev、reviewPro、post-merge efficacy；runtime SoT 用 daemon memory + local sqlite WAL，Lark Base 只做 projection。                  | AI Developer 是最清晰 MVP。                                                 |
| Botmux patch 文档          | 本地 patch/fork 与独立 patch repo 存在重复和 drift；Lark 文档版本与本地 README 版本不一致。                                                                                                            | 产品化前必须先治理 fork/patch source of truth。                                  |
| Lark Agent Control Plane | 不要第一步就做 full-auto factory；先用 Lark 做 task console，Beads 做 SoT，Botmux 做 command bridge，lark-dm-bot 做通知，agent 在 permission/measure/rollback 内执行。                                  | 需要 lane-based rollout，不要一次上 production autonomy。                       |
| 本地 docs repo             | [lark-agent-control-plane.md](/ai/factory/lark-agent-control-plane.md)、`agentic-software-factory.md`、`tools-ecosystem.md`、[repo-overview.md](../../team-ops/repo-overview.md)。 | 已经有 Agentic Software Factory 思路，只差 runtime/control plane 产品化。          |
| Guo/Dipu 项目              | Data center BD 研究需要持续情报、关系、转化、后台 CRM/KB/compliance；AI “Omni Sentinel” 可以做 always-on intelligence。                                                                              | research employee/BD analyst 是第二条高价值路线。                                |
| Kinevi docs              | 多 repo、多学科、长期研究型项目：IMU、Vision、ML、firmware、mobile、business plan、funding、advisor network。                                                                                        | AI research/project manager 可以帮忙维护知识、实验、任务和 investor/advisor pipeline。 |
| 外部产品                     | LobeHub/LobeChat、GitHub Copilot cloud agent、Devin、Linear Agents、Slack Agentforce。                                                                                              | 市面上有相邻产品，但我们的差异是 Lark work OS + CLI runtime + task/policy/measurement。 |

**说明：**研究期间直接重新拉取早前 Lark Doc 时，曾遇到 user auth 过期：
`need_user_authorization`，缺 `docx:document:readonly`。这份整合基于之前已读内容、当前本地 docs、repo
源码和官方外部来源；正式发布前已重新完成 Lark 授权并把三份研究稿发布为 Lark Doc。

***

# 1. 组合架构：每一层负责什么

```mermaid
flowchart TB
  Human[Boss, PM, Engineer in Lark] --> Control[Lark Control Plane]
  Control --> Botmux[Botmux Runtime]
  Control --> LarkCLI[Lark CLI Tools]
  Botmux --> AgentCLI[Codex, Claude Code, Cursor, Gemini]
  AgentCLI --> Code[Repos and Local Worktrees]
  AgentCLI --> LarkCLI
  LarkCLI --> WorkOS[Lark Docs, Base, Tasks, Mail, Calendar, IM]
  Control --> State[Beads or devbot DB as SoT]
  State --> Projection[Lark Base and Docs Projection]
  Policy[Policy, Audit, Human Gate] --> Botmux
  Policy --> LarkCLI
  Tests[Tests, Evals, Metrics] --> State
  Code --> Tests
```

| 层                       | 职责                                                                                  | 不要让它承担什么                               |
| ----------------------- | ----------------------------------------------------------------------------------- | -------------------------------------- |
| Lark                    | 人类入口、协作界面、Docs/Task/Base/Calendar/Mail/Approval 等工作对象。                              | 不要把自然语言 Doc 当唯一任务数据库。                  |
| Lark CLI                | AI 精准读写 Lark workspace 的 hands/API layer。                                           | 不要让它承担长期 agent runtime。                |
| Botmux                  | 把 Lark 会话映射为长期 AI CLI session，提供 terminal、stream card、scheduler、multi-bot、workflow。 | 不要让它承担完整 CRM/任务 SoT/企业权限系统。            |
| Codex/Claude Code 等 CLI | 实际推理、编码、研究、文件操作、测试、生成 artifact。                                                     | 不要直接拿生产权限和外部发送权限。                      |
| Beads/devbot DB         | 任务、状态、依赖、审计、agent run 的 source of truth。                                            | 不要把它变成人类主界面；人类可以继续在 Lark 看 projection。 |
| Policy/Audit/Measure    | 权限 lane、人类审批、日志、预算、测试、post-merge efficacy。                                          | 不要后补；这是从 demo 到 SaaS 的分水岭。             |

**产品核心：**Botmux 给 AI 一个“身体”，Lark CLI 给 AI 一双“手”，Lark
给人类一个“办公室”，Beads/devbot DB 给系统一个“账本”，policy/audit
给老板一个“可控性”。缺一层都不像真正员工。

***

# 2. 它们结合起来能做什么

| 员工类型                     | 输入                                                | 动作                                          | 输出                                   |
| ------------------------ | ------------------------------------------------- | ------------------------------------------- | ------------------------------------ |
| AI Developer             | GitHub Issue、Lark task、spec doc、codebase、CI logs。 | 拉代码、读文档、开 branch、实现、跑 tests、开 PR、回复 review。 | PR、测试结果、Lark 报告、post-merge efficacy。 |
| Research Employee        | 外部网页、论文、市场报告、内部 docs、会议纪要、项目目标。                   | 持续搜索、整理证据、判断机会、生成研究报告、更新 Base。              | 研究文档、证据库、日报/周报、下一步任务。                |
| Project Manager Employee | 会议、任务、calendar、PR、Slack/Lark 群消息、owner 列表。        | 抽取任务、跟进 blocker、提醒负责人、更新状态、生成周报。            | 任务看板、风险列表、站会摘要、执行节奏。                 |
| BD/Sales Ops Employee    | 线索、邮件、CRM/Base、LinkedIn/新闻/行业信号、公司资料。             | 线索评分、草拟 outreach、安排 follow-up、更新 CRM、提醒人类。  | BD pipeline、邮件草稿、客户 briefing、会议准备材料。 |
| Knowledge Librarian      | 多个 repo docs、Lark Docs、Wiki、README、设计文档。          | 查 drift、补 description、重组知识库、生成 llms.txt 摘要。 | 干净的知识空间、导航文档、过期内容清单。                 |

## 为什么 AI Developer 适合作为第一步

**好验证：**代码任务天然有
branch、diff、tests、CI、review、PR、merge、post-merge
metrics。老板最怕的是 AI “看起来做了事，其实没效果”；工程闭环比研究/BD
更容易度量。

**好限制：**可以先让 agent 只开 PR、不 merge、不
deploy；只允许改低风险文件；所有外部副作用走
humanGate。这样能安全地积累真实 case。

## 为什么不止于 AI Developer

你提到的 “5.3 research employee / project manager employee”
是更大的方向。工程师只是第一类可验证员工；真正卖给老板时，老板可能更想买的是“一个能
24
小时盯项目、盯市场、盯客户、盯任务、写报告、起草邮件、把事情推到下一步的人”。

***

# 3. 具体工作流设计

## 3.1 AI Developer MVP

| 阶段         | 动作                                                             | 工具层                              |
| ---------- | -------------------------------------------------------------- | -------------------------------- |
| Intake     | 从 Lark Doc/Task/GitHub Issue 读需求，生成 plan，必要时用 `botmux ask` 问人。 | Lark CLI + Botmux + GitHub       |
| Execute    | 在独立 worktree/branch 改代码，跑 tests/lint/build，记录命令和结果。            | Codex/Claude Code through Botmux |
| Review     | 开 draft PR，把 diff、风险、测试、未解决问题写回 Lark。                          | GitHub + Lark Docs/IM            |
| Human Gate | 人类 review，要求修改或批准。                                             | Lark card + GitHub review        |
| Efficacy   | D+1/D+3/D+7 查看 logs/metrics/Sentry/用户反馈，确认 feature 真的有效。       | Monitoring + Lark report         |

**建议：**第一版不要承诺“自动 merge”。只承诺“issue/task 到 draft PR +
测试 + 报告 + 人类 review”。这已经足够有价值，而且安全边界清晰。

## 3.2 Research Employee：Dipu/DataOne / Guo 项目

| 模块                     | 怎么做                                                                                       | 产物                 |
| ---------------------- | ----------------------------------------------------------------------------------------- | ------------------ |
| Always-on intelligence | 定时搜索 data center 项目、ERCOT/load queue、SEC filings、commissioning jobs、M\&A、老旧 DC、非传统 buyer。 | 信号 Base、每日报告、机会评分。 |
| Evidence ledger        | 每条判断必须链接来源、截图/摘要、可信度、影响维度、下一步动作。                                                          | Lark Base 证据库。     |
| Relationship mapping   | 整理目标公司、角色、联系人、会议、follow-up、共同关系。                                                          | BD CRM/Base。       |
| Outreach drafting      | 根据证据和客户痛点生成邮件/LinkedIn/会议 briefing，默认只创建 draft。                                           | 邮件草稿、会议准备文档。       |
| Strategy feedback      | 把市场反馈反向写回产品定位：consultant、system delivery、turnkey、AI overlay。                              | 策略 memo、下一步任务。     |

这类 employee
的价值不是“问它一个问题给一个答案”，而是它每天都在替你维护一个外部世界的雷达，持续把信号压缩成可行动的任务。

## 3.3 Research / Project Manager：Kinevi

| 场景                        | AI 可以做什么                                                                           | 为什么适合                                  |
| ------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------- |
| 跨学科文档维护                   | 把 IMU、Vision、ML、firmware、mobile、business/funding docs 的变化同步成导航和 summary。           | Kinevi 是多 repo、多学科，最容易知识 drift。        |
| 实验管理                      | 把实验设计、数据 pipeline、metrics、结果、下一步写成结构化记录。                                           | 运动学/ML 项目需要严格证据链。                      |
| Literature watch          | 定期跟踪 motor learning、biomechanics、wearables、Vision+IMU fusion、pressure insoles、EMG。 | 研究变化快，人类很难持续扫。                         |
| App creation              | 把新的 insight 转成 firmware/mobile/backend/ML issue，再让 AI Developer 实现局部工具或 demo。      | 研究 employee 与 developer employee 形成接力。 |
| Investor/advisor pipeline | 整理 funding、advisor、partner、pitch materials、follow-up。                              | 科研产品化需要持续 BD 和 narrative。              |

## 3.4 Project Manager / Chief of Staff

1. 每天读 `calendar +agenda`、`task +get-my-tasks`、GitHub PR、Lark
   群消息，生成“今天该盯什么”。
2. 会议结束后用 `minutes +summary` 抽 action items，写入
   Task/Base，并提醒 owner。
3. 每周生成 status report：完成了什么、阻塞在哪里、谁需要决策、哪些
   task 过期。
4. 对高风险项目开 `botmux ask`：让人选择是否升级、延后、换
   owner、开新任务。

***

# 4. 和“龙虾”/LobeChat/LobeHub 的区别

**假设：**我把你说的“龙虾”按 LobeChat/LobeHub
这一类产品理解。如果你指的是另一个具体产品，需要再重审。但从官方页面看，LobeChat
更像 open-source LLM chat framework，LobeHub 更像 agent operator / agent
team hub。

| 问题      | LobeChat/LobeHub 更像什么                                 | 我们这个方向更像什么                                                                  |
| ------- | ----------------------------------------------------- | --------------------------------------------------------------------------- |
| 核心入口    | LLM chat / agent hub / provider and plugin ecosystem。 | Lark work OS 内的员工入口，围绕任务、文档、群、会议、邮件、Base 运转。                                |
| runtime | 偏 agent/application layer，强调 agent 创建、技能、调度、汇报。       | Botmux 保留真实 AI CLI session、terminal、tmux、resume、worktree、CLI-native skills。 |
| 工作对象    | 更通用，适合做聊天、知识库、agent 管理。                               | 直接操作企业工作对象：Lark Docs/Base/Task/Mail/Calendar/Approval + GitHub/Repos。       |
| 精确执行    | 如果要做企业内部工作流，需要接很多工具和权限模型。                             | Lark CLI 已经提供大量 workspace API，Botmux 已经提供 CLI 执行身体。                         |
| 产品边界    | 适合作为通用 chat UI 或 agent marketplace 参考。                | 目标是“可审计、可审批、可度量、可接项目”的 AI employee operating layer。                         |

所以回答“为什么不直接把龙虾接进来”：可以接，但它不应该是核心
runtime。它可以变成一个可选前端、agent management UI 或模型/provider
hub；核心差异化仍应放在 Lark work OS、Botmux CLI runtime、任务
SoT、policy 和 measurement 上。

***

# 5. 业界相邻产品地图

| 产品/方向                       | 官方定位/能力                                                                                     | 相似点                         | 我们不同点                                                                           |
| --------------------------- | ------------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------- |
| GitHub Copilot cloud agent  | 可在 GitHub 后台研究 repo、计划、改代码、开 PR、处理 issue/PR 评论、自动化触发。                                       | AI Developer / issue-to-PR。 | 偏 GitHub 内闭环；我们把 Lark task/docs/meetings/approval 和多种 CLI runtime 接进来。          |
| OpenAI Codex / Claude Code  | 强 coding/research CLI agent，本地或云端执行代码任务。                                                    | 核心 worker。                  | 它们不是 Lark-native employee 产品；需要 Botmux/Lark CLI/SoT/policy 包起来。                 |
| Devin                       | 面向工程团队的 AI software engineer，强调复杂多 repo、云端并行 agent。                                         | AI Developer SaaS。          | Devin 更垂直于 engineering；我们可以从 engineering 出发，但扩展到 Lark 工作系统里的 research/PM/BD。    |
| Linear Agents               | Agents 是 Linear workspace 成员，可被 assign issue、加入 project、被 @mention。                         | 把 agent 当 teammate 放进任务系统。  | Linear 是任务系统；Lark 是更完整 work OS。我们也应学习“agent 是正式成员”的产品形态。                        |
| Slack Agentforce / Slackbot | Slack 官方把 AI agents、Slackbot、AI search、workflow generation、third-party assistants 放进 Slack。 | chat workspace agent。       | Slack 更 chat-first，Lark 的 Docs/Base/Task/Mail/Approval 与 `lark-cli` 更适合做全工作流员工。 |
| LobeChat/LobeHub            | LLM chat framework / agent operator，强调 agent、skills、IM gateway、self-host。                   | agent hub 和通用 UI。           | 不是我们最稀缺的部分。我们缺的是企业工作流 SoT、policy、Lark-native execution 和客制化部署。                  |

***

# 6. 当前 Botmux 是否只能支持 Lark？Slack 怎么看

| 问题          | 当前判断                                                                                                                                         | 建议                                                   |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Botmux 当前平台 | 源码和 README 都深度绑定 Lark：Lark event、card、topic、chat/thread、Feishu send/reply。                                                                   | 短期不要强行抽象，先把 Lark 做深。                                 |
| 能否支持 Slack  | 技术上可以：需要做 Slack event/app adapter、Slack Block Kit stream/update、thread mapping、permission mapping、OAuth/scopes。                              | 把 Botmux core runtime 与 `LarkPlatformAdapter` 分离后再做。 |
| Slack 生态    | 官方价格页显示 Slack 有 2,600+ apps、Slack AI、Slackbot personal AI agent、AI workflow generation、third-party AI assistant apps；另有 Agentforce in Slack。 | Slack 是必须关注的市场，但不是 MVP 起点。                           |
| Lark 生态     | Lark 把 Docs、Base、Tasks、Mail、Calendar、Approval、Meetings、Wiki 更紧密放在同一 workspace，并且 `lark-cli` 已经给出 agent 操作层。                                  | 先用 Lark 做产品差异化，再把 core runtime 平台化。                  |

**路线建议：**不要把“支持
Slack”作为第一天目标。先把产品核心抽象清楚：`PlatformAdapter`、`TaskSoT`、`RuntimeWorker`、`PolicyEngine`、`ArtifactPublisher`。Lark
是第一个 adapter，Slack 是第二个 adapter。

***

# 7. 产品化必须补的层

| 缺口                   | 为什么不能省                                 | 建议实现                                                                                                          |
| -------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Tenant model         | 卖给不同老板/客户时，数据、权限、runtime、billing 必须隔离。 | org/project/user/bot/session/task 五层实体；每层都有 owner、policy、audit。                                               |
| Task source of truth | Lark Doc 和群消息不是稳定任务数据库。                | AI Developer 用 devbot DB/Beads；Research/PM 用 Base projection，但核心 run state 进 DB。                              |
| Policy engine        | 不同任务风险不同，不能所有 agent 都能写邮件、开 PR、改生产。    | lanes：read-only、draft-only、test-autofix、reviewed-production、trusted-low-risk。                                 |
| Human gate           | 老板要可控，尤其外发邮件、客户消息、merge、deploy、付款、审批。  | Botmux `ask` + Lark Approval + card buttons + audit log。                                                      |
| Evidence and trace   | 研究和商业判断不能靠“AI 觉得”。                     | 每个结论要有 source URL、时间、引用摘要、confidence、影响维度。                                                                    |
| Measurement          | 没有 measure 就无法证明 AI employee 有效。       | PR merge rate、test pass rate、cycle time、post-merge incidents、research-to-action conversion、BD follow-up rate。 |
| Cost/budget          | 长期 worker 会烧 token 和机器成本。              | worker budget、per-task cap、scheduled run quota、customer billing usage。                                        |
| Connector strategy   | 客户内部资料不只在 Lark/GitHub。                 | 第一阶段 Lark + GitHub + Web；第二阶段 Mail/Slack/Linear/Jira/Google Drive/Notion/Salesforce。                          |

***

# 8. 建议路线图

| 阶段      | 目标                                                                              | 交付物                                                                              |
| ------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Phase 0 | 治理基础：auth、scope、policy、audit、patch source of truth、Botmux deployment checklist。 | Botmux fork/patch 整理；Lark CLI scope manifest；agent lanes；smoke tests。            |
| Phase 1 | AI Developer MVP：GitHub Issue/Lark Task 到 draft PR。                             | issue intake、plan approval、branch/worktree、PR creation、test report、Lark summary。 |
| Phase 2 | Research Employee pilot：Dipu 或 Kinevi 二选一。                                      | scheduled research、evidence Base、weekly report、task extraction、mail draft。       |
| Phase 3 | PM/Chief of Staff employee。                                                     | meeting-to-task、blocker tracking、weekly exec report、owner reminders。             |
| Phase 4 | 多客户 SaaS 化。                                                                     | tenant admin、connector setup、billing、permission UI、audit/export、Slack adapter。   |

## Phase 1 的最小可卖版本

客户连接 GitHub repo 和 Lark workspace。 在 Lark 创建/选择任务，分配给
AI Developer。 Botmux 启动 Codex/Claude Code worker，在受控 worktree
里执行。 Agent 只允许开 draft PR，不允许 self-merge。 Lark Doc
自动生成计划、diff 摘要、测试结果、风险、review checklist。 post-merge
D+1/D+3/D+7 自动检查效果，形成 efficacy report。

***

# 9. 最后判断

## 不要做的事

- 不要一开始承诺 full-auto employee。
- 不要把 Lark Doc 当唯一数据库。
- 不要让 agent 默认拥有发送邮件、merge、deploy 权限。
- 不要把 LobeChat/LobeHub 当核心替代品；它更适合作可选 UI/agent hub。
- 不要在 fork、local patch、patch repo 之间继续 drift。

## 应该做的事

- 先用 AI Developer 建立可信闭环。
- 把 Botmux 定位成 runtime，把 Lark CLI 定位成 workspace hands。
- 用 Beads/devbot DB 做 source of truth。
- 把 humanGate、audit、measurement 做成产品核心，而不是附属功能。
- 第二条路线选 Dipu 或 Kinevi 做 Research Employee pilot。

**我的建议：**先写清楚并落地一个“AI Developer for Lark +
GitHub”的窄版本，拿真实 PR 和效率指标证明它有用；同时并行设计 Research
Employee 的数据模型和 evidence ledger。这样既能快出
demo，也不会把未来的商业空间锁死在 coding agent。

***

# 10. 来源链接

- [deepcoldy/botmux GitHub Repository](https://github.com/deepcoldy/botmux)
- [larksuite/cli GitHub Repository](https://github.com/larksuite/cli)