Retaintive

    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 repolark-agent-control-plane.md、agentic-software-factory.md、tools-ecosystem.md、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. 组合架构：每一层负责什么

    层职责不要让它承担什么
    Lark人类入口、协作界面、Docs/Task/Base/Calendar/Mail/Approval 等工作对象。不要把自然语言 Doc 当唯一任务数据库。
    Lark CLIAI 精准读写 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 DeveloperGitHub 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
    EfficacyD+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 AgentsAgents 是 Linear workspace 成员，可被 assign issue、加入 project、被 @mention。把 agent 当 teammate 放进任务系统。Linear 是任务系统；Lark 是更完整 work OS。我们也应学习“agent 是正式成员”的产品形态。
    Slack Agentforce / SlackbotSlack 官方把 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/LobeHubLLM 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 truthLark 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 1AI Developer MVP：GitHub Issue/Lark Task 到 draft PR。issue intake、plan approval、branch/worktree、PR creation、test report、Lark summary。
    Phase 2Research Employee pilot：Dipu 或 Kinevi 二选一。scheduled research、evidence Base、weekly report、task extraction、mail draft。
    Phase 3PM/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. 来源链接