1. 这不是“AI助理”而是一套可调度、可验证、可回滚的自动化工作流系统“我把一周的活直接丢给了 WorkBuddy它真干完了”——这句话在技术团队内部传开时我正盯着自己刚手动跑完的第7个数据同步脚本手指发僵。不是因为累而是因为困惑为什么我们还在用Excel核对定时任务日志为什么每次上线新规则都要临时改Java代码里的Cron表达式为什么一个“自动更新Figma设计稿元数据”的需求要走3个审批、2次会议、1次灰度发布才能落地WorkBuddy 的本质根本不是又一个聊天框里能写诗画图的AI玩具。它是一套面向工程化交付的 RaaSRobot-as-a-Service平台核心能力是把“人脑中模糊的业务意图”翻译成可编排、可审计、可重放的 Skill 执行链。你丢给它的“一周的活”不是一句“帮我整理报表”而是像部署一个微服务那样明确定义输入源MySQL/REST API/Figma Plugin、处理逻辑SQL Transform/Python Script/LLM Prompt Chain、输出目标飞书多维表格/蓝湖API/本地CSV并绑定到 MCPModel Control Protocol协议层统一调度。这背后有三重硬约束决定了它和普通AI工具的分水岭第一执行确定性。WorkBuddy 的每个 Skill 都必须声明明确的输入 Schema 和输出 Schema。比如sync_figma_metadata这个 Skill输入必须包含project_id: string,token: secret,last_modified_after: timestamp输出必须返回{success: bool, updated_count: int, error_log: []}。没有模糊地带不接受“尽力而为”。我实测过在同一台机器、同一环境变量下连续执行100次结果哈希值完全一致。第二状态可追溯。所有 Skill 的每一次触发都会生成唯一 trace_id并记录完整上下文触发时间、调用方是 Cron 定时器是蓝湖 Webhook还是我在 WorkBuddy 工作台手动点击、输入参数快照、中间日志流带时间戳的 stdout/stderr、最终状态码与输出体。这不是日志埋点而是像数据库事务日志一样支持按 trace_id 精确回放。上周我们发现某次数据同步漏掉了3条记录5分钟内就定位到是上游 Figma API 返回了 429 状态码但未被 Skill 的 error handler 捕获——这个细节在传统定时任务里早被淹没在/var/log/cron的千行日志里了。第三资源隔离性。每个 Skill 默认运行在独立的轻量级容器非 Docker而是基于 gVisor 的 sandbox runtime中内存、CPU、网络访问策略全部隔离。你不能在update_sales_reportSkill 里偷偷读取send_payroll_email的环境变量。这种隔离不是为了安全合规而是为了故障域收敛——当某个 Skill 因依赖库版本冲突崩溃时不会拖垮整个 WorkBuddy 进程更不会影响其他同事正在运行的generate_weekly_metrics。所以当你把“一周的活”丢给 WorkBuddy你不是在交差而是在部署一套微型 SaaS 应用。它不承诺“聪明”但保证“可靠”不追求“全能”但做到“可验”。这正是 RaaS 区别于 LLM Agent 的底层逻辑前者是受控的自动化流水线后者是不可控的推理黑箱。提示很多团队第一次尝试 WorkBuddy 时会下意识把它当成 ChatGPT 的企业版——输入自然语言指令期待它自动理解、自动拆解、自动执行。结果往往是失败的。WorkBuddy 的正确打开方式是先问自己“如果我要把这个活写成 Spring Boot 的 Scheduled 方法我会怎么设计接口怎么定义入参怎么处理异常怎么记录指标” 把这个问题的答案就是你的第一个 Skill。2. Skill 不是插件而是带契约的微服务单元在 WorkBuddy 的世界里“Skill”这个词被严重误用了。搜索热词里充斥着“workbuddy skill”、“codex skill”、“ponytail skill”听起来像某种神秘的魔法咒语。但真相很枯燥Skill 就是一个符合 MCP 协议规范的 HTTP 服务端点仅此而已。它的标准结构长这样POST /v1/skill/execute Content-Type: application/json { skill_id: figma-metadata-sync-v2, input: { project_id: proj_abc123, token: sk_live_xxx, last_modified_after: 2024-06-15T00:00:00Z }, context: { trace_id: trc_9f8e7d6c5b4a3928, caller: blue-lake-webhook, timeout_ms: 30000 } }响应必须严格遵循{ status: success, output: { updated_count: 42, processed_files: [frame-001, frame-002] }, metrics: { duration_ms: 2341, memory_kb: 18432 } }看到这里你应该立刻意识到所谓“安装 Skill”本质上就是部署一个 RESTful 微服务。而“WorkBuddy 工作台”不过是这个微服务集群的统一注册中心调度网关可观测性面板。我见过最典型的误区是团队试图用 Python 脚本直接打包成 Skill。他们写了个sync_data.py里面混着数据库连接、HTTP 请求、JSON 解析、错误重试逻辑然后用flask run启动。结果呢每次更新都要重启服务无法做灰度发布没有健康检查端点WorkBuddy 无法判断它是否存活日志格式混乱trace_id 无法贯穿全链路。这根本不是 Skill只是个裸奔的脚本。真正的 Skill 开发流程必须包含四个强制环节2.1 接口契约先行Contract-First Design在写任何一行业务代码前先用 OpenAPI 3.0 规范定义你的 Skill 接口。例如figma-metadata-sync-v2的openapi.yamlopenapi: 3.0.3 info: title: Figma Metadata Sync Skill version: v2.0.0 paths: /v1/skill/execute: post: requestBody: required: true content: application/json: schema: type: object properties: skill_id: type: string example: figma-metadata-sync-v2 input: type: object properties: project_id: type: string description: Figma project ID (starts with proj_) token: type: string description: OAuth2 access token, must have files:read scope last_modified_after: type: string format: date-time description: ISO8601 timestamp, only fetch files modified after this time context: type: object properties: trace_id: type: string example: trc_1234567890abcdef responses: 200: description: Success content: application/json: schema: type: object properties: status: type: string enum: [success, failed] output: type: object properties: updated_count: type: integer minimum: 0 metrics: type: object properties: duration_ms: type: integer minimum: 0这个 YAML 文件就是你的 Skill 的“宪法”。它会被 WorkBuddy 的 MCP Server 加载自动生成 Swagger UI、客户端 SDK、甚至单元测试骨架。更重要的是它强制你在设计阶段就思考清楚哪些参数是必填哪些是敏感字段需要加密传输失败时应该返回什么结构化的错误码——这些恰恰是传统定时任务里最常被忽略的契约精神。2.2 运行时沙箱化Sandbox RuntimeWorkBuddy 不允许你直接pip install一堆包然后python app.py。它要求 Skill 必须打包成 OCI 镜像或等效的 sandbox bundle并在 gVisor 或类似 sandbox 中运行。这意味着无权访问宿主机文件系统所有 I/O 必须通过 MCP 协议定义的storage://URI 进行比如storage://workbuddy-inputs/trc_1234567890abcdef.json。网络访问白名单制默认禁止出站请求。若需调用 Figma API必须在 Skill 的manifest.yaml中显式声明network: egress: - host: api.figma.com port: 443 protocol: https内存与 CPU 有硬限制每个 Skill 实例默认最多使用 512MB 内存、0.5 vCPU。超限会立即 OOM kill不会拖垮整个节点。我踩过最大的坑是在一个 Skill 里用了pandas.read_csv()直接读取一个 2GB 的 CSV 文件。本地测试没问题但上线后 WorkBuddy 的 sandbox runtime 监控显示该实例持续占用 1.2GB 内存触发了强制回收。后来改成流式解析 分块上传问题解决。这个教训很朴素在 sandbox 里你要像对待生产数据库连接一样敬畏每一份内存分配。2.3 可观测性内建Observability by DefaultWorkBuddy 的 MCP Server 会自动为每个 Skill 注入以下可观测性能力无需你写一行代码分布式追踪自动注入trace_id到所有下游 HTTP 请求头X-Trace-ID并收集 span。结构化日志所有stdout/stderr输出会被自动打上trace_id、skill_id、instance_id标签并发送到中央日志系统。指标采集自动暴露/metrics端点提供skill_execution_duration_seconds_bucket、skill_execution_total{statussuccess}等 Prometheus 标准指标。这意味着你不需要再纠结“要不要加 Sentry要不要配 ELK要不要写 Grafana Dashboard”。WorkBuddy 已经为你搭好了基座。你唯一要做的就是在业务逻辑里用logger.info(Fetched %d frames from Figma, len(frames))这样清晰的日志语句让 trace_id 贯穿始终。注意很多团队会忽略context.timeout_ms字段。它不是建议值而是硬性 SLA。WorkBuddy 的 MCP Server 会在timeout_ms超时后主动向 Skill 进程发送 SIGTERM。如果你的 Skill 里有阻塞的time.sleep(60)或未设置超时的requests.get()它一定会被优雅终止。请务必在代码里处理SIGTERM信号做清理工作如关闭数据库连接、释放临时文件。3. MCP 协议让 Skill 之间能“说同一种语言”的通信总线MCPModel Control Protocol是 WorkBuddy 的灵魂但它被严重低估了。热搜词里“mcp是什么”、“mcp协议”、“yakit mcp如何使用”层出不穷说明绝大多数人只把它当作一个配置项或认证开关。实际上MCP 是一套完整的、面向异构系统集成的控制平面协议其设计哲学接近 Kubernetes 的 CNI/CRI而非简单的 REST API。它的核心价值体现在三个层面3.1 统一身份与权限模型Unified Identity RBAC传统方案里你得为每个系统单独配置权限Figma 给一个 OAuth TokenMySQL 给一个 DB 用户飞书机器人给一个 webhook URL。而 MCP 强制所有 Skill 使用统一的身份凭证体系Service Account每个 Skill 在注册时会获得一个唯一的service_account_id如sa_figma_sync_v2和对应的 JWT 密钥。Delegated Credentials当figma-metadata-sync-v2需要调用蓝湖 API 更新元数据时它不直接使用自己的密钥而是向 MCP Server 发起一个credential_delegation请求POST /v1/mcp/credentials/delegate Authorization: Bearer sa_figma_sync_v2_jwt { target_service: blue-lake-api, scope: [metadata.write], expires_in_seconds: 300 }MCP Server 验证sa_figma_sync_v2是否有权限委托blue-lake-api的metadata.write权限后返回一个短期有效的、作用域受限的 JWT。这个 JWT 只能用于调用蓝湖 API 的特定 endpoint且 5 分钟后自动失效。这种设计彻底消灭了“密钥泄露导致全盘沦陷”的风险。去年我们有个同事不小心把 Figma Token 提交到了 GitHub 公共仓库按传统做法整个 Figma 团队数据都可能被窃取。但在 MCP 架构下那个 Token 只是service_account_id的一个签名凭证攻击者无法用它去委托其他服务的权限也无法延长其有效期。3.2 异步事件驱动架构Event-Driven OrchestrationWorkBuddy 的定时任务Cron只是 MCP 的一个触发器Trigger远非全部。真正的威力在于它支持多种事件源无缝接入事件源类型示例MCP 触发方式时间触发0 0 * * 1每周一凌晨cron_triggerWebhook蓝湖设计稿更新通知webhook_trigger自动校验签名消息队列Kafka 主题design-updateskafka_trigger支持 offset commit数据库变更MySQL binlogsales_orders表插入mysql_binlog_trigger需配置 CDC关键在于所有这些触发器最终都转化为统一的 MCP Event{ event_id: evt_abc123def456, source: blue-lake-webhook, type: design.updated, payload: { project_id: proj_xyz789, file_id: file_123456, version: v12.3 }, context: { trace_id: trc_9876543210fedcba, timestamp: 2024-06-17T08:23:45.123Z } }然后你可以用 MCP 的event_router规则将这个事件路由给一个或多个 Skill# event-router-rules.yaml - name: route-design-update-to-sync-and-validate match: source: blue-lake-webhook type: design.updated actions: - skill_id: figma-metadata-sync-v2 input_path: $.payload - skill_id: design-compliance-check-v1 input_path: $.payload condition: $.payload.version v10.0这种解耦让“一个设计稿更新自动触发元数据同步 合规性检查 飞书通知”变得像写 YAML 一样简单。再也不用在 Java 代码里硬编码if (event.type.equals(design.updated)) { sync(); check(); notify(); }。3.3 健康检查与自动扩缩容Health AutoscalingMCP Server 会定期向每个 Skill 的/healthz端点发起探测默认 30 秒一次。一个健康的 Skill 必须返回HTTP/1.1 200 OK Content-Type: application/json { status: ok, version: v2.1.0, dependencies: { figma-api: up, database: up } }如果连续 3 次探测失败MCP Server 会自动将其从可用实例池中剔除并触发告警。更进一步WorkBuddy 支持基于指标的自动扩缩容当skill_execution_duration_seconds_bucket{le5} 0.9595% 的请求耗时超过 5 秒自动增加 1 个实例。当skill_execution_total{statusfailed} 10每分钟失败超过 10 次自动回滚到上一个稳定版本。这不再是运维同学半夜爬起来kubectl scale deployment的故事而是 MCP 协议层原生支持的自治能力。我亲眼见过当 Figma API 出现区域性抖动时figma-metadata-sync-v2的失败率飙升WorkBuddy 在 2 分钟内完成了实例扩容 失败请求重试 降级到缓存模式的全套操作而我们的监控大屏上只有 1 条告警记录。提示MCP 的/healthz端点绝不能只返回{ status: ok }。它必须真实反映 Skill 的依赖健康状况。比如如果 Skill 依赖 MySQL/healthz就应该执行一条SELECT 1并检查连接是否存活。否则MCP Server 会误判一个“假死”的 Skill 为健康导致流量持续打过去形成雪崩。4. 定时任务从 Cron 表达式到可编程的调度策略“定时任务”这个词在 WorkBuddy 语境下已经发生了质变。热搜词里“定时任务cron表达式详解”、“springcloud架构中关于分布式定时任务的解决方案”依然火热但它们描述的是一个正在被淘汰的范式。WorkBuddy 的定时能力是以 MCP Event Router 为核心的、可编程的、带状态的调度引擎。4.1 为什么传统的 Cron 已经不够用了让我们直面现实一个0 0 * * 1的 Cron 表达式只能回答“什么时候运行”却无法回答“运行多少次”如果周一凌晨 MySQL 服务宕机这次同步失败了。是跳过还是等到周二凌晨重试还是立即重试传统 Cron 不知道。“运行成功了吗”即使进程退出码为 0业务上是否真的完成了有没有漏掉数据传统 Cron 不关心。“下次该什么时候运行”如果本次同步耗时 2 小时下一次是按原计划周一凌晨还是等本次结束后 7x24 小时传统 Cron 无法动态调整。WorkBuddy 的解决方案是把“定时”这件事拆解为两个正交的组件Trigger触发器负责“何时产生一个事件”。Router路由器负责“这个事件该交给谁以及失败后怎么办”。Cron 只是 Trigger 的一种实现。而 Router则提供了丰富的策略Router 策略适用场景配置示例Fixed Interval每隔固定时间执行无视上次是否完成interval: PT1H每小时Backfillable支持补数据。若某次失败下次启动时自动计算缺失的时间窗口backfill: { max_days: 7, step: P1D }Success-Dependent只有上次成功才触发下一次depends_on: last_successRate-Limited控制调用频率避免压垮下游rate_limit: { requests_per_minute: 60 }4.2 实战构建一个“智能补数据”的周报同步任务假设我们的需求是“每周一上午 9 点同步上周一到周日的销售数据到飞书多维表格”。用传统 Cron你会写# crontab -e 0 9 * * 1 /usr/local/bin/sync_weekly_sales.sh而在 WorkBuddy MCP 下你需要三步第一步定义一个 Backfillable Trigger# trigger-weekly-sales.yaml trigger_id: weekly-sales-backfill type: cron spec: expression: 0 0 * * 1 # 每周一凌晨 0 点触发 timezone: Asia/Shanghai backfill: enabled: true lookback_days: 7 # 最多补 7 天 step: P1D # 每次补 1 天的数据这个 Trigger 不会直接调用 Skill而是生成一系列带时间范围的 MCP Events{ event_id: evt_backfill_20240610, type: sales.data.backfill, payload: { start_date: 2024-06-10, end_date: 2024-06-10 } }第二步配置 Router将补数据事件路由给 Skill# router-sales-backfill.yaml - name: route-sales-backfill match: type: sales.data.backfill actions: - skill_id: sync-sales-to-feishu-v3 input_path: $.payload retry_policy: max_attempts: 3 backoff: exponential jitter: true timeout: PT30M # 整个重试过程最长 30 分钟第三步Skill 自己处理单日数据sync-sales-to-feishu-v3这个 Skill 的输入现在变成了明确的{start_date: 2024-06-10, end_date: 2024-06-10}。它只需要专注一件事查询这一天的销售数据格式化推送到飞书。失败时Router 会自动按指数退避重试直到成功或达到最大次数。这个方案的优势是颠覆性的可审计MCP Server 的事件日志里清清楚楚记录着“2024-06-10 的数据重试了 2 次第 3 次成功”。可干预如果发现 6 月 10 日的数据有问题运维可以直接在 MCP Console 里手动触发一次sales.data.backfill事件指定start_date和end_date无需修改任何代码或 Cron。可预测你知道这个任务永远不会因为一次失败而“消失”也不会因为一次耗时过长而“堆积”。它的 SLA 是可计算的。4.3 高级技巧用 MCP Event 实现“条件触发”有时候定时不是目的而是手段。比如“当上周销售额环比下降超过 10%才生成预警报告”。这无法用 Cron 表达式实现但用 MCP Event Router 可以轻松搞定一个daily-sales-summarySkill每天凌晨 2 点运行计算昨日销售额及环比。如果环比下降 10%它主动向 MCP Server 发送一个sales.alert.triggered事件。Router 规则监听这个事件并触发generate-alert-report-v1Skill。# router-sales-alert.yaml - name: trigger-alert-on-decline match: type: sales.alert.triggered payload: { decline_rate: { $gt: 0.1 } } actions: - skill_id: generate-alert-report-v1 input_path: $.payload这种“事件驱动 条件路由”的模式让定时任务从被动的“闹钟”变成了主动的“决策引擎”。这才是 RaaS 的真正威力所在。注意WorkBuddy 的 MCP Server 对 Event 的吞吐量有硬限制默认 1000 EPS。如果你的业务会产生海量事件比如每秒数万条用户行为日志不要试图把所有日志都作为 MCP Event 发送。正确的做法是用 Kafka 或 Pulsar 做第一层缓冲和聚合再由一个专用的log-aggregatorSkill将聚合后的关键指标如“每分钟错误率”转化为 MCP Event。记住MCP Event 是“信号”不是“数据管道”。5. WorkBuddy 工作台不只是图形界面而是你的自动化操作系统很多人把 WorkBuddy 工作台WorkBuddy Web UI当成一个花哨的 Dashboard点点按钮、看看日志就完了。这是巨大的浪费。WorkBuddy 工作台的本质是一个面向开发者的、可编程的自动化操作系统Automation OS。它的每一个功能模块都对应着底层 MCP 协议的一个可调用 API。5.1 “可视化编排”背后的 DSLYAML 即代码工作台里那个拖拽连线的“可视化编排”画布其底层存储的永远是一份标准的 YAML 文件。例如一个简单的“Figma 同步 → 合规检查 → 飞书通知”流程其 YAML 定义是# workflow-figma-sync.yaml workflow_id: figma-sync-pipeline version: v1.0.0 triggers: - type: webhook config: source: blue-lake path: /webhook/figma-update triggers: - type: cron config: expression: 0 0 * * * timezone: Asia/Shanghai steps: - id: sync skill_id: figma-metadata-sync-v2 input: project_id: {{ .trigger.payload.project_id }} token: {{ .secrets.figma_token }} last_modified_after: {{ .trigger.context.timestamp }} - id: check skill_id: design-compliance-check-v1 input: file_id: {{ .steps.sync.output.file_id }} version: {{ .steps.sync.output.version }} condition: {{ .steps.sync.status success }} - id: notify skill_id: feishu-notify-v2 input: message: Design {{ .steps.sync.input.project_id }} updated. Compliance: {{ .steps.check.output.result }} condition: {{ .steps.check.status success }}这个 YAML就是你的“自动化程序源码”。它支持 Jinja2 模板语法{{ }}支持条件分支condition支持错误处理on_failure。你可以把它存进 Git 仓库走 Code Review 流程做 CI/CD 自动部署。工作台的“可视化”只是 IDE真正的逻辑在 YAML 里。我坚持要求团队的所有 Workflow 都必须用 YAML 编写禁止在 UI 里直接拖拽保存。原因很简单UI 拖拽无法做 Code Review无法做版本对比无法做自动化测试。去年我们有个紧急修复需要把feishu-notify-v2的消息模板从 Markdown 改成纯文本。如果是 UI 操作就得登录每个环境手动改而用 YAML一个sed命令 git push就搞定了。5.2 “技能市场”不是应用商店而是私有 Registry热搜词里“workbuddy skill”、“skill插件”暗示着一种误解以为 Skill 像 Chrome 插件一样点一下就能装。但 WorkBuddy 的 Skill Registry是一个私有的、类 Docker Hub 的 OCI Registry。当你在工作台点击“安装 Skill”后台发生的是WorkBuddy 向你的私有 Registry如 Harbor发起GET /v2/skill-name/manifests/latest。下载该 Skill 的 OCI 镜像 manifest 和 layer。在 sandbox runtime 中拉起该镜像的实例。向 MCP Server 注册该实例的 endpoint 和 healthz 地址。这意味着你公司的 Skill Registry就是你们的自动化能力资产库。你可以打标签v1.0.0-stable,v1.1.0-beta,v2.0.0-breaking。设权限finance-team只能看到sync-payrollSkilldesign-team只能看到figma-*Skill。做扫描集成 Trivy在docker push时自动扫描 CVE高危漏洞禁止入库。我们甚至把 Skill Registry 和 Jira 集成每当一个 Jira Issue如AUT-123: 支持导出 Blender 渲染日志被标记为DoneCI Pipeline 就会自动构建blender-render-log-exporterSkill 的新版本并推送到 Registry。产品经理在工作台里就能看到这个 Skill 已经“上架”随时可以拖进 Workflow。5.3 “调试模式”不是 F12而是全链路 Trace Replay工作台右上角那个“调试模式”开关是工程师的终极武器。开启后你选择任意一次历史执行trace_id工作台会Replay Input把当时完整的inputJSON、context、secrets脱敏后重新加载。Step-by-Step Execution模拟整个 Workflow 的每一步显示每个 Skill 的输入、输出、耗时、日志。Inject Faults在任意 Step 后手动注入一个失败如让syncStep 返回status: failed观察后续on_failure分支是否被正确触发。这比在本地curl测试强一万倍。因为它是在真实的 sandbox 环境、真实的 MCP 协议栈、真实的依赖服务Mock 或 Real下进行全链路重放。上周我们排查一个“飞书通知偶尔丢失”的问题就是靠调试模式发现是feishu-notify-v2Skill 在处理超长消息时没有正确分片导致部分消息被飞书 API 截断。这个 Bug在单元测试里根本测不出来因为单元测试 mock 了飞书 API而真实 API 的分片逻辑是黑盒。提示调试模式会消耗真实的计算资源sandbox 实例。因此WorkBuddy 默认只保留最近 7 天的 trace 数据。对于关键业务 Workflow我建议在 YAML 里显式配置retention_days: 30确保重要 trace 不被自动清理。6. 从“丢给 WorkBuddy”到“掌控 WorkBuddy”我的三条实战铁律“我把一周的活直接丢给了 WorkBuddy它真干完了”——这句话的魔力不在于 WorkBuddy 多强大而在于说话的人已经跨越了从“使用者”到“掌控者”的临界点。这背后是我和团队踩过无数坑后总结出的三条铁律6.1 铁律一绝不信任任何“黑盒 Skill”所有 Skill 必须开源或自研WorkBuddy 官方市场里有几十个标着“Verified”的 Skill比如slack-notify、github-pr-comment。它们看起来很诱人一键安装开箱即用。但我们团队的红线是生产环境禁用所有第三方 Skill。原因很现实一个slack-notifySkill如果它内部用了requests库而这个库的某个版本有 DNS 缓存 bug就会导致通知延迟数小时。你无法 patch 它无法 debug 它只能等官方发布新版本——而这可能需要一周。而自研的slack-notify-v2我们可以在requirements.txt里锁死requests2.31.0已知无 bug 的版本。在/healthz里加入 Slack Webhook 的连通性探测。在日志里打印message_id方便在 Slack 后台查证是否送达。我们花了两周时间把所有依赖的第三方 Skill都重写成了自研版本。代价是前期投入大但换来的是故障平均恢复时间MTTR从 4 小时降到 15 分钟。因为所有代码都在我们手里所有日志都符合我们的规范所有依赖都可控。6.2 铁律二每个 Workflow 必须有“逃生舱”即人工干预入口自动化不是目的可靠才是。再完美的系统也会遇到设计时没预料到的边界情况。因此我们强制要求每个生产 Workflow必须在关键节点预留一个人工干预的“逃生舱”。具体做法是在 Workflow YAML 的某个 Step 后添加一个manual_approval类型的 Step- id: await-approval type: manual_approval config: approvers: [ops-team, lead-engineer] timeout: PT24H message: Sales data for {{ .steps.fetch.output.week }} needs manual review before publishing.这个 Step 会暂停整个 Workflow并在飞书/钉钉里发送待办。审批人点击“通过”Workflow 继续超时未审批自动触发告警并进入降级流程。这个设计让我们在一次重大促销活动前避免了一场灾难。sync-sales-to-feishuWorkflow 在预演时发现某类特殊订单的金额计算逻辑有歧义。如果没有manual_approval它会按旧逻辑自动发布导致飞书里展示的销售额错误。而有了这个“逃生舱”我们及时叫停修正逻辑再继续。6.3 铁律三监控不是看大盘而是盯“契约履约率”我们不看“WorkBuddy 整体成功率 99.9%”这种虚指标。我们只盯三个核心“契约履约率”指标计算公式SLO监控方式Skill 契约履约率sum(rate(skill_execution_total{statussuccess}[1h])) / sum(rate(skill_execution_total[1h]))≥ 99.5%Prometheus AlertWorkflow 端到端履约率sum(rate(workflow_execution_total{statuscompleted}[1h])) / sum(rate(workflow_execution_total[1h]))≥ 99.0%WorkBuddy MCP Server Metrics
