SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场workspace-health

workspace-health

部署与运维

查看项目

更新于 10-29 07:16

技能介绍

用途

Workspace Health 用来解决一个运维问题：避免客户比团队更早发现工作流坏掉。它作为一个部署的智能体运行，每天早晨读取工作区最近 24 小时的运行情况，并与前 7 天对比，然后只把出问题的新情况发到 Slack。它只报告，不修复。

主要能力

它执行五项检查，出现对应情况时产出一条发现：

  • 失败按原因分组：某工作流的错误超过其运行次数的 HEALTH_ERROR_RATE（默认 5%）；如果是鉴权错误，会指出需要重新授权的连接器。
  • 停止的 play：某 play 原本平均每天至少运行一次，现在一次都没跑，并说明它是被禁用还是未被触发。
  • 成功但没有写入：某 play 触碰的记录中，超过一半在它写入的列上仍为空。
  • 额度突增：某工作流的花费超过其日均值的 HEALTH_SPEND_MULTIPLE 倍（默认 2 倍），且超出量大于 HEALTH_SPEND_FLOOR。
  • 卡住的批次：处于 pending 或 running 状态超过六小时。

只发布错误且新增的内容。它会读取自己在频道中的历史消息，因此已报告过的问题不会每天早上重复；未解决的会并入周一汇总帖，列出仍开放和已清除的问题，或给出“全部正常”以及本周的运行与额度总量。周一帖使“安静的平日”可以被理解为健康，而不是监视器已经失效。

例子：

Workspace health: 3 new findings

1. HubSpot sync lost its connector: 212 of 230 runs failed since 06:10 with
   401 unauthorized at the write step. Re-authorize the HubSpot connector.
2. Tier Accounts has not run since Oct 19 (it averaged 3 runs a day): the play
   is disabled. Re-enable it if that was not on purpose.
3. Enrich new signups succeeded 140 times and wrote no company size on 131 of
   them. Open run 7c1e… to see what the provider returned.

On Mondays: "Workspace health, week of Oct 26: 1 still open (Tier Accounts), 2 cleared, 0 checks
skipped."

使用方式

这个目录是一个示例工程，需要由智能体适配到你的项目中。安装命令（在包含 cargo.json 的项目目录内执行）：

cargo-ai project add cookbook/workspace-health

它会把示例写入 infra/workspace-health/，并把流程写入 .claude/skills/workspace-health/。如果还没有项目：

cargo-ai project init <dir> --cookbook workspace-health && cd <dir> && npm install

如果是从项目的 .claude/skills/ 中阅读，说明安装已完成，直接从第 2 步开始。CLI 版本过旧、不支持 add 时，可手动把该目录作为同级目录复制进去。

安装后需要与项目已有声明协调：如果项目已有 Anthropic、GitHub 或 Slack 连接器，应改写导入指向已有连接器并删除副本，同一 slug 的两个资源在部署时会冲突。然后按顺序适配：不应改变的部分是你要据理力争的；可以改变的部分是你可以主动提出的；会被问到的部分是最低要求，先自行推导再提问。把改动和原因记录在文件副本的 ## Decisions 节。

检查与计划：在该技能目录运行 node --import tsx evals/contract.mjs，然后在项目根运行 npm run check && cargo-ai project plan，展示差异，仅在明确同意后部署：cargo-ai project deploy（或 merge，merge 会部署）。不要对非空目录执行 cargo-ai project init --force。

验证：先不等早晨，手动运行一次智能体，再逐条走“Done when”并给出证据。

需要确认的配置

  • Slack 频道（HEALTH_CHANNEL_ID，位于 infra/agents/workspace-health.ts）：需要询问工作区负责人的频道；用 Slack 连接器的频道自动补全把名称解析为 C… id，并邀请 Cargo 应用加入。发布和回读共用这一个常量：两者频道不同会导致每天重复发布；应用不在频道中会导致回读失败。
  • 阈值（HEALTH_ERROR_RATE、HEALTH_SPEND_MULTIPLE、HEALTH_SPEND_FLOOR）：第一周保持默认，之后看周一帖。对富化密集型工作区可调高错误率，因为供应商覆盖缺失属于常态。太低会把覆盖缺失当成故障；太高会掩盖真实故障。
  • 仓库绑定：保持 repository 不设置，plan 会从检出目录的 git origin 填充。工具链会克隆它，从不推送。
  • 服务用户（infra/users/index.ts）：workspace_health，采用 viewer 系统角色的服务用户。部署时创建；部署用户自身角色必须覆盖 viewer。若项目已采用 viewer，应导入该角色而不是重复声明。每次运行都需要它的 cargo-ai 会话，否则沙箱无会话，所有工作区读取都会失败。viewer 可读取运行、play、智能体和用量，但不能部署或更改资源。
  • Anthropic、GitHub、Slack 连接器：用 cargo-ai connection connector list 查看；缺失的用 cargo-ai project add connector/<name> 添加。它们分别对应计费模型、克隆和发布。

可选的变体

  • daily-all-clear：团队尚不信任“沉默即健康”时，在 infra/agents/workspace-health.prompt.ts 第 3 步每天发布周一那一行。代价是每天一条无内容消息，频道可能被静音；建立信任后可改回周一。
  • twice-a-day：play 调度很短、早晨太晚时，增加第二个 cron 触发并把提示中的窗口改为 12 小时。代价是双倍运行，且 12 小时基线对每日运行的 play 更嘈杂。
  • skip-empty-outputs：模型列很宽、空列检查慢或嘈杂时，可从提示中去掉检查 c。代价是“静默成功”这一别人都不捕获的故障不再被监控。
  • page-on-auth：连接器丢失对你很紧急时，增加第二个锁定到值班频道的 postMessage，仅用于鉴权类发现。代价是两个频道需要维护，而且契约评测需更新以允许第三个动作。

不应改变的部分

  • 沙箱以 viewer 服务用户运行（infra/users/index.ts）。没有 runAs 会缺少 cargo-ai 会话，所有工作区读取失败；角色过宽则被忽略的提示可能部署或编辑资源。
  • 只报告，从不修复（workspace-health.prompt.ts §2 Never）。重跑会再次计费，取消可能丢弃进行中的工作，禁用的 play 可能是有意禁用；自行处置发现的监视器等于无人复核的第二操作员。
  • 发布与回读共用同一锁定频道（HEALTH_CHANNEL_ID）。回读是唯一的记忆；拆开后每天早晨会重复发布每条发现。
  • 绝不把读不到的工作区报为干净（workspace-health.prompt.ts §2）。whoami 失败要发布错误；无会话的沉默监视器和健康工作区看起来一样。
  • 失败要分组，绝不逐条列出（§2a）。同一节点同一错误是一条带计数的发现；为一个过期令牌列两百行会让真实的第二个故障被漏掉。
  • 使用阈值而非报告每个错误（HEALTH_ERROR_RATE）。富化找不到邮箱属于覆盖问题而非故障；报告每个错误一周内频道就会被静音。

完成标准（Done when）

  • node --import tsx evals/contract.mjs 通过：绑定 Anthropic 连接器和模型的 claudeCode harness，以 viewer 服务用户运行、无 capability、恰好两个连接器动作（slack.postMessage 与 slack.getConversationHistory）锁定同一频道、每日 cron，以及三个阈值环境变量条目。
  • cargo-ai project plan 报告该智能体、其目录和三个连接器。
  • 在工作区存在已知问题时首次运行（原本运行的 play 被禁用，或工作流失败超过阈值），只发布一次，并指出 play 和原因。
  • 帖子里每个数字与手工重跑同一读取的结果一致。
  • 同日第二次运行、无新情况时不发布任何内容。
  • 第一个周一发布周报行，即使没有新情况。
  • 运行不改变工作区：不重跑、不取消、不启用或禁用任何 play。

成本

经常性成本是 harness 每天运行一次，按绑定的 Anthropic 连接器以 LLM token 计费。它随问题多少而变：干净的一天是三次 list 命令和五次聚合查询；糟糕的一天每个失败工作流最多增加两次 run get 读取。工作区读取是 API 调用而非连接器动作，不计费，且运行从不执行花钱的动作。Slack 每天读取一次历史，仅在有事可说时发布。

组合使用

可与同包的 cargo-diagnostics 配合，对每条发现所指的运行做深入分析；与 goal-coverage（目标还需要什么）和 weekly-planning（投入是否在轨）搭配使用。