上一篇我们把 Claude Code 配成了指挥官下挂本地 Agent 和远程配置 Agent靠 MCP 把任务串起来。那套架构在 2025 年底跑得通是因为 Anthropic 当时还没拿出一个原生覆盖知识工作面的产品。到了 2026 年 1 月 Cowork 进入研究预览、2 月扩展 Slack / Drive / Gmail / Docusign / Zoom 等连接器、4 月 GA 并放出 Dispatch 之后指挥官这个槽位的最优解变了。这一篇要做的事就是把那套嵌套架构的外壳从 Claude Code 换成 Cowork,并把为什么不换就是在重写 Anthropic 已经写好的代码讲清楚。先把两个产品摆在同一张桌子上维度Claude CodeClaude Cowork默认形态终端 CLI / IDE 插件桌面 AppmacOS / Windows连接器自己写 MCP server一等公民Slack / Drive / Gmail / Docusign / Zoom / FactSet文件权限当前 git 仓库用户授权的任意文件夹触发机制命令行调用、IDE 唤起Dispatch手机/桌面双向 连接器事件组织控制项目级 settings.json hooks角色权限 / OpenTelemetry / 组开销上限一句话定位给开发者写代码、跑命令给知识工作者跨应用打通流程最容易被忽视的是最后一行——它揭示了两个产品的设计目标差异。Claude Code 把每一项决策都往代码循环 终端反馈上优化Cowork 则把跨应用编排 企业级审计做成原生能力。两个设计目标都没错但一旦映射到 DevOps 实际工作量分布上谁该当指挥官就有了答案。DevOps 的工作量到底花在哪里拿一次真实的 incident 处理流程拆解看每一步归谁PagerDuty / Datadog 告警触发—— Cowork 连接器活儿Slack 拉 war room、同步状态—— CoworkSlack 连接器2 月扩到 Zoom翻 Grafana 仪表盘定位异常时间窗—— Cowork桌面应用 截图kubectl exec/aws cli排障—— Claude Code终端会话改 Helm chart 或 Terraform 修复配置—— Claude Code多文件编辑 diff 循环触发 CI/CD 复跑、看流水线日志—— Claude Code 起头Cowork 跟进通知写 postmortem 到 Confluence / Google Docs—— Cowork文档连接器Jira 关单、给受影响客户发邮件—— Cowork8 步里 4–5 步是 Cowork 的舒适区2–3 步是 Claude Code 的舒适区。更关键的一点是触发端永远在 Cowork 这一侧——告警从监控来工单从 ITSM 来沟通从 Slack 来。把这张饼图摊开看结论很直白让擅长写代码的工具去当一个 60% 时间不在写代码的 Agent 的外层等于让它一直在 idle等触发等连接器把数据搬过来。不换会撞上几堵墙如果继续按上一篇的方案让 Claude Code 当外层每加一个连接器都会撞上同一堵墙PagerDuty / Datadog 触发要起一个常驻 webhook server再写 PagerDuty MCP——而 Cowork 已经有原生连接器Anthropic 2026-02 在企业版扩展时官方支持Slack ChatOps要写 Slack Bot slash command 路由——Cowork 直接监听 Slack 事件Confluence / Google Docs 写 postmortem要拼 Confluence REST API 的 storage format 或 Google Docs API——Cowork 桌面端直接打开页面写企业审计要自己埋 OpenTelemetry、做角色权限——Cowork 在 GA 时官方支持开箱即用每一项单看都不是天大的工程但加在一起就是花一两个月在重新发明一个不如 Cowork 完整的连接器层。这个时间花得不值。反过来让 Cowork 当外层、Claude Code 当被 Dispatch 的子工具上面这些事一行配置就拿到。Claude Code 反而能专心做它最强项的事在 git 仓库里多步编辑代码、跑命令、读反馈、自我修正——它的强项不是接告警是 inner loop。调换之后的具体落地具体分工Cowork 是主入口所有触发器PagerDuty webhook、Jira automation、Slack 命令、Dispatch 来的手机请求都进 Cowork。它做意图分流、权限校验、审计埋点。Claude Code 是被调度的子工具当任务里出现需要在仓库里修代码 / 跑 kubectl / 调 CI等动作Cowork 通过 Dispatch 把任务派给本机的 Claude Code传过去仓库路径和 issue 上下文。结果回流Claude Code 完成后只返回 PR 链接 diff 摘要 关键日志Cowork 接着把结果同步回 Slack / Jira / Confluence。这套分工带来四个直接好处触发面广连接器现成不用为接 PagerDuty 写半个月 MCP。审计统一Cowork 的 OpenTelemetry 与角色权限覆盖整个流程符合企业 DevOps 合规要求。代码循环不被稀释Claude Code 拿到的是干净、scoped 的代码任务发挥它最强项的地方。失败可隔离代码编辑出错不会污染 incident 主线状态机Cowork 端可以重新分发或回退到人工。上一篇指挥官 嵌套子 Agent的核心思路并没有作废——只是指挥官换了人子 Agent 的位置也由本地/远程 Agent收窄成了Claude Code 处理代码与终端。边界什么时候上一篇的方案仍然成立不是所有自称 “DevOps Agent” 的项目都要走这一篇的架构。判别表平台工程团队只维护 IaC / Helm / 平台工具链几乎不接告警或工单 → 上一篇的方案Claude Code 主导 自定义 MCP够用不必引入 Cowork。企业 SRE / 应用运维真实工作里大量沟通和报表 → 这一篇的方案是默认形态。完全无需写代码的 ChatOps值班机器人、合规检查报告 → Cowork 单点足够连嵌套都不用。判断方法只有一个用一周时间记录每天用 IDE/CLI 的小时数 vs 用 Slack/Jira/dashboard/邮件的小时数。如果连接器侧 ≥ 60%按本篇方案换外壳否则保留上一篇的方案。主张收口在这里别让哪个工具更强绑架架构选择让工作量分布来决定。上一篇的核心思想——嵌套式 Agent 协作——没变变的只是谁在外、谁在内以及为什么外壳那一层不应该自己造。
续篇：嵌套式 DevOps Agent 的指挥官，该让 Cowork 接 Claude Code 的班了
发布时间：2026/8/1 16:10:37
上一篇我们把 Claude Code 配成了指挥官下挂本地 Agent 和远程配置 Agent靠 MCP 把任务串起来。那套架构在 2025 年底跑得通是因为 Anthropic 当时还没拿出一个原生覆盖知识工作面的产品。到了 2026 年 1 月 Cowork 进入研究预览、2 月扩展 Slack / Drive / Gmail / Docusign / Zoom 等连接器、4 月 GA 并放出 Dispatch 之后指挥官这个槽位的最优解变了。这一篇要做的事就是把那套嵌套架构的外壳从 Claude Code 换成 Cowork,并把为什么不换就是在重写 Anthropic 已经写好的代码讲清楚。先把两个产品摆在同一张桌子上维度Claude CodeClaude Cowork默认形态终端 CLI / IDE 插件桌面 AppmacOS / Windows连接器自己写 MCP server一等公民Slack / Drive / Gmail / Docusign / Zoom / FactSet文件权限当前 git 仓库用户授权的任意文件夹触发机制命令行调用、IDE 唤起Dispatch手机/桌面双向 连接器事件组织控制项目级 settings.json hooks角色权限 / OpenTelemetry / 组开销上限一句话定位给开发者写代码、跑命令给知识工作者跨应用打通流程最容易被忽视的是最后一行——它揭示了两个产品的设计目标差异。Claude Code 把每一项决策都往代码循环 终端反馈上优化Cowork 则把跨应用编排 企业级审计做成原生能力。两个设计目标都没错但一旦映射到 DevOps 实际工作量分布上谁该当指挥官就有了答案。DevOps 的工作量到底花在哪里拿一次真实的 incident 处理流程拆解看每一步归谁PagerDuty / Datadog 告警触发—— Cowork 连接器活儿Slack 拉 war room、同步状态—— CoworkSlack 连接器2 月扩到 Zoom翻 Grafana 仪表盘定位异常时间窗—— Cowork桌面应用 截图kubectl exec/aws cli排障—— Claude Code终端会话改 Helm chart 或 Terraform 修复配置—— Claude Code多文件编辑 diff 循环触发 CI/CD 复跑、看流水线日志—— Claude Code 起头Cowork 跟进通知写 postmortem 到 Confluence / Google Docs—— Cowork文档连接器Jira 关单、给受影响客户发邮件—— Cowork8 步里 4–5 步是 Cowork 的舒适区2–3 步是 Claude Code 的舒适区。更关键的一点是触发端永远在 Cowork 这一侧——告警从监控来工单从 ITSM 来沟通从 Slack 来。把这张饼图摊开看结论很直白让擅长写代码的工具去当一个 60% 时间不在写代码的 Agent 的外层等于让它一直在 idle等触发等连接器把数据搬过来。不换会撞上几堵墙如果继续按上一篇的方案让 Claude Code 当外层每加一个连接器都会撞上同一堵墙PagerDuty / Datadog 触发要起一个常驻 webhook server再写 PagerDuty MCP——而 Cowork 已经有原生连接器Anthropic 2026-02 在企业版扩展时官方支持Slack ChatOps要写 Slack Bot slash command 路由——Cowork 直接监听 Slack 事件Confluence / Google Docs 写 postmortem要拼 Confluence REST API 的 storage format 或 Google Docs API——Cowork 桌面端直接打开页面写企业审计要自己埋 OpenTelemetry、做角色权限——Cowork 在 GA 时官方支持开箱即用每一项单看都不是天大的工程但加在一起就是花一两个月在重新发明一个不如 Cowork 完整的连接器层。这个时间花得不值。反过来让 Cowork 当外层、Claude Code 当被 Dispatch 的子工具上面这些事一行配置就拿到。Claude Code 反而能专心做它最强项的事在 git 仓库里多步编辑代码、跑命令、读反馈、自我修正——它的强项不是接告警是 inner loop。调换之后的具体落地具体分工Cowork 是主入口所有触发器PagerDuty webhook、Jira automation、Slack 命令、Dispatch 来的手机请求都进 Cowork。它做意图分流、权限校验、审计埋点。Claude Code 是被调度的子工具当任务里出现需要在仓库里修代码 / 跑 kubectl / 调 CI等动作Cowork 通过 Dispatch 把任务派给本机的 Claude Code传过去仓库路径和 issue 上下文。结果回流Claude Code 完成后只返回 PR 链接 diff 摘要 关键日志Cowork 接着把结果同步回 Slack / Jira / Confluence。这套分工带来四个直接好处触发面广连接器现成不用为接 PagerDuty 写半个月 MCP。审计统一Cowork 的 OpenTelemetry 与角色权限覆盖整个流程符合企业 DevOps 合规要求。代码循环不被稀释Claude Code 拿到的是干净、scoped 的代码任务发挥它最强项的地方。失败可隔离代码编辑出错不会污染 incident 主线状态机Cowork 端可以重新分发或回退到人工。上一篇指挥官 嵌套子 Agent的核心思路并没有作废——只是指挥官换了人子 Agent 的位置也由本地/远程 Agent收窄成了Claude Code 处理代码与终端。边界什么时候上一篇的方案仍然成立不是所有自称 “DevOps Agent” 的项目都要走这一篇的架构。判别表平台工程团队只维护 IaC / Helm / 平台工具链几乎不接告警或工单 → 上一篇的方案Claude Code 主导 自定义 MCP够用不必引入 Cowork。企业 SRE / 应用运维真实工作里大量沟通和报表 → 这一篇的方案是默认形态。完全无需写代码的 ChatOps值班机器人、合规检查报告 → Cowork 单点足够连嵌套都不用。判断方法只有一个用一周时间记录每天用 IDE/CLI 的小时数 vs 用 Slack/Jira/dashboard/邮件的小时数。如果连接器侧 ≥ 60%按本篇方案换外壳否则保留上一篇的方案。主张收口在这里别让哪个工具更强绑架架构选择让工作量分布来决定。上一篇的核心思想——嵌套式 Agent 协作——没变变的只是谁在外、谁在内以及为什么外壳那一层不应该自己造。
