不用切来切去：CSGClaw 用飞书串起多平台协作

一件事明明已经讨论过了，真要动手的时候，还得重新翻聊天记录、找会议纪要、对一遍Issue。每往前走一步，上下文就断一次。CSGClaw想解决的就是这个问题。

CSGClaw 是 OpenCSG 推出的开源、本地多智能体协作产品。它让不同角色的 Agent 通过 Skill、MCP 和连接器接入团队现有的协作环境与业务系统。

CSGClaw把飞书变成了一个贴近日常工作的入口。群聊、Wiki、云文档、多维表格和妙记，是信息产生和协作发生的地方；当任务需要继续推进时，CSGClaw再连接GitLab Issue、代码仓库、Grafana和本地开发环境，把查询、分析、执行和结果回写串成一条线。

工作从飞书开始，最后也回到飞书结束。

中间的切换由CSGClaw执行。

打开CSGClaw的Profile页面，你会看到飞书以一个通道的身份接入在这里。消息从这里进入Agent，而读取妙记、查文档、访问代码仓库这些动作，则由对应的Skill、MCP和连接器在后台完成。

对使用者来说，这些技术细节几乎不可见。还是在熟悉的飞书会话里说话，只是多了一个能干活的搭档。

CSGClaw Agent Profile中已连接的飞书通道

不同的Agent可以配不同的能力：运维助理专门查指标和日志，研发助理连代码仓库，法务资料助理只碰获得授权的文件。飞书承载任务入口和结果回传，CSGClaw则根据Agent的角色、工具和权限，让任务由合适的Agent继续处理。

从使用感受上，我们更愿意把它想象成一名项目助理。平时，它接住会议结论、整理任务、跟进共创方案；出故障时，它把指标、日志、代码和发布记录凑到一块，帮你看清全貌。任务变复杂时，背后也可以由不同Agent分工协作，而使用者仍然留在原来的会话和工作流程里。

场景一:告警进群后，先把证据带回来

收到线上告警的那一刻，值班的人通常要做一串事：确认服务和时间范围、打开Grafana查指标、去日志系统翻错误、在群里问最近有没有发布、最后把零散信息拼成一段回复。问题处理完了，还得再补一份复盘材料。

下面是测试环境里一次真实的CPUThrottlingHigh告警。Prometheus通过Webhook把告警卡片推进了飞书群：llm-wiki命名空间下的source-ingest容器发生CPU CFS限流，throttling比例显示62.54%。值班同学直接引用卡片@了运维Agent：

帮我排查这条告警，重点看触发前后 15 分钟的指标、日志和近期发布，先给结论，不执行生产变更。

飞书群中的CPU CFS限流告警及CSGClaw排查结论

CSGClaw从卡片里拿到环境、工作负载、容器和触发时间，然后把几类证据铺到同一条时间线上：

Grafana指标

给这个Pod 在13:14—13:44 的throttling 是60.7%—83.8%，听起来很吓人，但实际CPU 用量只有0.012.120 核，节点CPU 也只在8%—16% 之间。节点并不繁忙，受限的是容器的CPU 配额。

Loki 日志

没有查到目标Pod 在同一时间窗的日志流。报告明确标记为‘日志证据缺失’，没有把"没查到日志"偷换成"业务正常"。

发布记录

没新 Pod 在 13:14 启动，13:30 告警转为 firing；但旧版本 Pod 在发布前也有 44%—76% 的 throttling——暂时没有证据支持直接回滚。

代码层面

继续往下看 worker 的启动入口、并发模型、批处理逻辑、重试机制，还有 Kubernetes 的资源声明，试图回答"指标背后到底发生了什么"。

如果代码显示worker会在短时间内并行处理任务，而多个容器又统一设了0.5核的CPU limit，那么这就能和Grafana的画面对上：

代码证据不足的时候，这个判断只会被标成"高概率原因"，并附上下一步怎么验证。

这次排查的即时结论是：确有持续的CPU CFS限流，但没有发现容器重启、节点资源饱和或明确的业务故障，不建议仅凭这条告警回滚。后续应该补查任务积压和处理时延，并在测试环境调整CPU limit做A/B验证。

这次处理不是一次简单的告警问答。CSGClaw先从告警卡片中提取环境、工作负载和时间范围，再让运维Agent按照既定的排查路径调用指标、日志、发布记录和代码信息。不同系统返回的证据被放进同一项任务中交叉核对；遇到证据缺失时明确标记，涉及回滚、重启等生产操作时，则停在建议和操作预览，由人完成最终确认。

把排查经验留给下一次

这套排查顺序可以固化成一个Skill。下次再遇到同类告警，Agent会按同样的节奏核对指标、日志、发布和代码，不会因为换了值班的人就从头摸索一遍。

排查结束后，它会把结论、证据、还没确认的问题和建议动作整理成故障报告。群里保留需要马上看到的结果，完整过程写进飞书文档，后续复盘时不用再翻聊天记录。

涉及回滚、重启、扩缩容这些生产操作，Agent只给出操作预览，最后按不按那个按钮，还是人来决定。

另一类故障排查也是同样的路数。成员只要在群里说一句"按照日志严格分析时序逻辑"，Agent就会把不同服务的日志和Trace组织起来，排出事件的先后关系，再给出直接原因、证据链和仍待确认的部分。

Agent负责收集材料、梳理时序、形成文档；项目负责人负责优先级、风险判断和最终决定。故障解决后，已经整理好的结论还能继续进入Issue、开发方案和后续改进。

场景二:会开完了，需求不用再从头整理

研发协作里有个特别磨人的断点：问题已经在会议或群里讨论过一遍了，进入正式研发流程时还要重新整理。有人翻妙记提炼待办，有人对着群聊手工创建Issue；等到PR/MR提交上去，评审人又得重新了解一遍前因后果。

同一件事，被反复搬运了三次。

CSGClaw想做的，就是从信息产生的位置把这些整理工作接过来。

先把会议结论接住

会议一结束，负责人把妙记链接发到项目群：

总结这次会议的核心内容，并说明后续工作安排。

CSGClaw在飞书群中读取妙记并整理会议结论

Agent读完妙记，先把讨论内容整理成团队可以直接确认的结论。参会人不用重新看录像、也不用逐段翻文字稿，就在原来的项目群里核对技术方向、阶段目标和下一步安排。

从群聊直接创建Issue

确认了要开发的事项，负责人可以接着让Agent基于会议结论整理Issue。问题也不一定非要来自会议——日常群聊里讨论出来的需求，给个话题或时间范围就行。

整理的时候，Agent会区分四样东西：已经确认的事实、还在讨论的判断、团队做出的决定、需要继续确认的问题。然后到代码平台搜一下有没有相似的Issue。草稿里包含问题现象、影响范围、复现条件、验收标准和来源链接；等标题、标签、负责人都确认了，再正式提交。

CSGClaw根据飞书群聊话题创建Issue

图里这个需求，最初只是一段操作演示。Agent分析了话题里的描述、截图和视频，在当前迭代创建了Issue，分配了负责人，关联了原飞书话题，还把错误重试、完成状态和历史消息整理成了验收标准。Issue链接随后回到原话题，参与者从两端都能找到完整上下文。

从方案共创到代码评审

Issue 建起来之后，Agent 可以继续读相关代码、测试和近期提交，形成初步判断，然后创建或梳理飞书开发方案。详细方案留在飞书文档里大家一起改，Issue只保留结论、验收条件和文档链接——免得维护两份慢慢不一致的说明。

如果方案已经由项目成员写好了，也可以把文档分享到群里，让Agent提炼主线、发布路径和验收重点：

CSGClaw 在飞书群中分析并梳理开发方案

图里的方案涉及镜像迁移，以及STG、Prod两套发布流程。Agent读完文档，把核心路径理成一条清晰的链路，对照两个环境归纳差异，还指出了仍需明确的几个点：制品一致性、CI门禁、Tag规范和回滚流程。项目负责人可以直接围绕这些缺口继续讨论。

群聊里的讨论还能回写到正式方案里。项目成员指定目标文档后，Agent会根据已经确认的内容调整结构、补齐章节，也可以用飞书画板画出架构图：

CSGClaw共创飞书方案文档并绘制架构图

截图里的方案被重新组织成13个章节，覆盖架构决策、领域模型、服务边界、核心流程、API、上线门槛和验证方案。架构图作为可编辑的飞书画板嵌在文档里，团队成员可以继续修改组件、连线和说明。Agent先完成结构化的初稿，架构师和研发人员在同一份文档里评审和修订。

方案确认之后，在仓库权限已经配置好的情况下，Agent还可以继续完成代码修改、测试和提交。

PR/MR进入评审时，项目成员把链接发到群里，就能调用Code Review Skill检查架构边界、代码风格，以及修改是否覆盖了最初的问题：

CSGClaw在飞书群中对GitHub PR进行代码审查

这次评审发现，上游返回的401被中间层统一折叠成了502，前端因此无法识别登录失效、也没法引导用户重新登录。Agent按严重程度列出问题，说明影响、依据和建议修改方向；提交更新后，开发人员还能在同一个话题里发起下一轮评审。

从妙记或聊天记录到Issue，再到方案和代码评审——已经确认过的上下文，可以一直带到下一步。人仍然决定要不要提交Issue、要不要采用方案、要不要合并代码，只是不必反复搬运同一批信息。

这条链路的重点，是让同一项工作的上下文持续向后流动。前一步已经确认的事实、决定和待办，会成为下一步整理与执行的输入；飞书负责团队讨论和确认，CSGClaw则在妙记、文档、Issue和代码仓库之间承接任务，减少信息在不同平台之间反复搬运和重新解释。

场景三:找合同，不再靠记文件名

CSGClaw的用处不局限在研发团队。

法务资料多、文件名又不统一，业务同学查合同时，常常只能凭记忆搜关键词，再找熟悉目录的人确认版本。一份简单的合同，来回可能要耗掉好几个人的时间。

下面这个案例里，用户要找与"U盘购买"相关的合同。Agent在获得授权的法务资料库里没有找到完全同名的文件，但检索到一份可能匹配的《小物件采购合同》。它先说明了搜索结果、请用户确认，没有直接把近似文件当成正确答案。

法务智能助手在飞书中检索并发送合同原件

用户确认后，Agent从飞书法务资料库里下载原始Word文件，并发回当前会话。用户追问文件来源时，它也明确说明了文件来自资料库，不是本地工作区里已有的文件。

在这个场景里，CSGClaw做的不只是根据自然语言搜索文件。法务资料Agent只访问已经授权的资料范围，保留候选文件的名称和来源；无法确定结果时先让用户确认，确认后再交付原始文件。查找范围、结果依据和最终动作都有明确边界，避免把“可能相关”直接当成“正确答案”。

对业务同学来说，变化很直接：不用记住文件的准确名称，也不用先找到资料库负责人。描述自己要找什么，确认一下候选结果，就能在群里拿到原始文件。

Agent负责查找和交付已有合同，不代替法务人员审核合同、也不做法律判断。

把上下文带到下一步

把CSGClaw 放进飞书之后，最直观的变化是：很多工作不必再从头开始。

人仍然负责判断和拍板，CSGClaw负责把上下文带到下一步。它在群里，更像一名一直跟得上进度的项目助理。

它的工作也不只发生在群聊里。围绕一项任务，CSGClaw可以预约会议，可以在飞书文档里共创方案、跟进并回复评论，也可以把项目状态、负责人和进度写进多维表格。需要更多现场信息时，它再通过MCP和连接器去查Grafana、读代码，或者进入已经授权的开发环境继续分析和实现。

在这套协作里，飞书不只是一个消息通道。人从这里发起任务、补充信息、确认关键决定；CSGClaw则把会议、文档、数据表与外部工具串起来，再把结果带回团队正在讨论的地方。

这也是 OpenCSG 希望通过 CSGClaw 带进真实工作场景的协作方式：不要求团队另起一套孤立流程，而是让 Agent 进入已有的协作关系、业务系统和权限边界。

产品真正连接的，不只是几个工具，而是一项工作从信息产生、形成判断到继续执行的完整过程。