一件事明明已经讨论过了真要动手的时候还得重新翻聊天记录、找会议纪要、对一遍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 进入已有的协作关系、业务系统和权限边界。产品真正连接的不只是几个工具而是一项工作从信息产生、形成判断到继续执行的完整过程。