简体
基于作者提供的 Kiki 猫图像制作的透明脸部衍生图
返回展厅

Kiki

工作信号与智能体执行

让提议落实为负责人的执行。

一个 Paperclip 插件和一个 Slack 采集器，帮助团队运行其 AI 智能体。

2026.04 — 2026.05

pinxlab AI R&D 自由职业 · 工作流程规划与开发，调查执行停滞并设计恢复路径

  • 插件已实现 · Paperclip
  • MCP 服务器已实现 · Slack 采集器

在分配与实际执行之间，设置观测与恢复的路径。

工作信号被转换为画像和智能体指令，维护提议的审批与其执行的分配相互分开。已分配 issue 的活动停止时，带上 issue 和负责人再次请求；反复无响应时，转入上限、冷却期和人工判断。

它们把工作信号转换为智能体指令，并将维护提议、人工审批、分配和停滞运行的恢复作为独立步骤衔接起来。这一流程由我规划并开发。

仓库首条记录 April 3, 2026 · pinxlab 合作至 May 26, 2026

作为插件在团队的 Paperclip 中运行；Slack 采集由 MCP 服务器负责。

执行流程结构图 · 依据非公开实现记录
Kiki 信号 · 审批 · 执行恢复从可访问的 Slack 频道历史中提取工作模式，形成公司画像和各智能体的指令。维护分析智能体查看目标项目，并以未分配的 backlog issue 留下提议；每条提议都会发送到 Slack，由人通过表情回应批准或拒绝。已批准的 issue 分配给某个智能体后，由外部执行系统完成工作，stage reaper 关注最近的活动。若活动停止，就带上 issue 和负责人再次请求分配；连续无响应达到上限时，停止重新调用，并转交 Lead 或运维人员。Slack 信号可访问的频道历史被分配的智能体外部执行目标项目不展示内容人 · 批准、拒绝Slack 表情回应Lead · 运维人员重新分配 · 通知信号采集模式提取 · 排除 bot公司状态合并公司画像智能体状态各智能体指令运行观测最近运行 · 活动维护分析PO 调用 · 限定范围的提示词issue 跟踪器提议 · backlog执行 issue · todo提议发送消息 ↔ issue 映射Stage reaper停滞检查 · heartbeat恢复调用issue + 负责人无响应状态无响应次数 · 按 issue上限停止重新调用 · 冷却期信号 → 指令外部执行提议 → 人工审批恢复 · 升级1频道历史2画像合并3重新生成4注入指令1目标范围2提议 issue3发送提议4Slack 消息5表情回应6批准 → todo7拒绝 → cancelled8分配1运行记录2最近活动3无回复 +14新活动 → 重置5重新调用6issue + 负责人73 次之后8重新分配 · 通知9仅警告

信号 → 指令

画像和智能体指令由 Slack 历史构建。指令是智能体的上下文，不画作任何提议的原因。

  1. Slack 信号频道历史模式提取 · 排除 bot信号采集

    采集可访问的频道历史，并过滤掉 bot、加入和离开消息。本页不展示原始消息。

  2. 模式提取 · 排除 bot信号采集画像合并合并公司画像公司状态

    提取出的模式形成画像补丁，合并到公司画像中。这些是启发式模式，不是员工绩效评分。

  3. 合并公司画像公司状态重新生成各智能体指令智能体状态

    依据合并后的画像重新生成并保存各智能体的指令。

  4. 各智能体指令智能体状态注入指令被分配的智能体

    智能体创建时，指令进入其上下文。这并不表示某条提议源自某个 Slack 信号。

提议 → 审批 → 分配

提议首先以未分配的 backlog issue 形式存在，人的表情回应请求更改状态，分配与执行归外部系统负责。

  1. 目标项目目标范围PO 调用 · 限定范围的提示词维护分析

    维护作业以限定于目标项目的提示词调用 PO 智能体。不展示源码内容。

  2. PO 调用 · 限定范围的提示词维护分析提议 issue提议 · backlogissue 跟踪器

    提示词要求只提出路径经过确认的提议，以未分配的 backlog issue 形式创建，并禁止执行 DB 迁移。这是给产品智能体的指示，而不是确定性的强制机制。

  3. 提议 · backlogissue 跟踪器发送提议消息 ↔ issue 映射提议发送

    每条提议发送到 Slack，并保存消息与 issue 的映射。已发送的提议不会重复发送，保存的映射只保留最近 50 条。

  4. 消息 ↔ issue 映射提议发送Slack 消息人 · 批准、拒绝

    人在 Slack 中看到已发送的提议。

  5. 人 · 批准、拒绝表情回应消息 ↔ issue 映射提议发送

    对消息的表情回应会通过映射找到对应 issue。没有自动批准。

  6. 消息 ↔ issue 映射提议发送批准 → todo执行 issue · todoissue 跟踪器

    批准时，发送请求将待处理的提议 issue 移至 todo，并更新映射和线程通知。该 handler 不检查响应码就把映射标记为已批准，因此不是失败即关闭的事务。

  7. 消息 ↔ issue 映射提议发送拒绝 → cancelled提议 · backlogissue 跟踪器

    拒绝时，发送请求将同一 issue 移至 cancelled。issue 在批准前已存在；批准并不创建它。

  8. 执行 issue · todoissue 跟踪器分配被分配的智能体

    todo issue 的分配和执行由外部执行系统负责。把 issue 移至 todo 并不保证工作已开始。

停滞 → 恢复 → 人

活动停止的已分配 issue 会带上 issue 和负责人再次请求；连续无响应达到上限时，转交给人。

  1. 被分配的智能体运行记录最近运行 · 活动运行观测

    被分配智能体的运行和最近信号被记录为观测。活动不是完成的证据。

  2. 最近运行 · 活动运行观测最近活动停滞检查 · heartbeatStage reaper

    reaper 只查看状态不是 done、cancelled 或 blocked 且有负责人的 issue，并计算最新信号和 stage 的时长。

  3. 停滞检查 · heartbeatStage reaper无回复 +1无响应次数 · 按 issue无响应状态

    按智能体和 issue 统计连续无响应次数，并保存在状态中。

  4. 最近运行 · 活动运行观测新活动 → 重置无响应次数 · 按 issue无响应状态

    新活动会重置计数。

  5. 停滞检查 · heartbeatStage reaper重新调用issue + 负责人恢复调用

    若超过 heartbeat 且计数低于上限，则发起恢复调用。

  6. issue + 负责人恢复调用issue + 负责人执行 issue · todoissue 跟踪器

    带上 issue、被分配的智能体和一条说明评论再次请求分配，并检查 HTTP 响应。legacy 路径则退回为一次唤醒调用。

  7. 无响应次数 · 按 issue无响应状态3 次之后停止重新调用 · 冷却期上限

    连续无响应达到上限（默认 3 次）时，停止重新调用。只有在状态 hook 读写计数时上限才成立，保存失败可能削弱它。

  8. 停止重新调用 · 冷却期上限重新分配 · 通知Lead · 运维人员

    尽可能重新分配给 Lead，仅在启用该功能时将 in_progress 移回 todo。否则留下评论和尽力而为的通知，并在达到上限后记录冷却期。

  9. 停滞检查 · heartbeatStage reaper仅警告Lead · 运维人员

    某个 stage 持续过久时，只为运维人员留下一条警告评论。状态不会自动更改。

所有连接以相同粗细显示。选择一个流程，即只突出显示其路径，并标出步骤编号。

  • 实线 · 输入、结果与记录的流向
  • 虚线 · 运行、判定、请求
  • 长点线 · 观测与报告，独立于判定
  • 短虚线 · 失败、停止、上限
  • 粗黑线 · 所选流程；数字表示顺序
  • 方框 · 代码或状态边界，标题栏注明名称
  • 内层小框 · 该边界中的组件
  • 点线框 · 该边界之外
  • 橙色轮廓 · 模型作出判断之处
  • 智能体调用 · 恢复调用
  • 状态 · 记录
  • 停滞检查 · 上限
  • 采集 · 发送

依据非公开的实现与开发记录绘制。不展示团队、issue 和 Slack 标识符以及原始消息；部署、容器和凭据归本插件之外的负责人所有。

一次观测
2026年4月28日报告：在变更前的手动诊断中，一个 67 小时未运行的 issue 在带上 issue 和负责人再次请求分配后，5 秒内排入了新的运行。未测量完成情况、平均恢复时间和上线后的效果。
审批处理的局限
与恢复调用不同，审批处理不检查响应码就把映射标记为已批准。它不被描述为原子的或失败即关闭的审批事务。
上限何时成立
3 次上限是在存在状态 hook 时才成立的实现，不保证在所有故障下都恰好升级一次。