# Agent Workstation Reviewer

> 审查现有 Agent 工位拆分、连接、交接、退回与人工边界。适用于用户已有岗位卡、工作流、上下游判断、接力协议或失败记录时，先判断哪些工作更适合 Tool、Skill、固定 Workflow、Agent 或 Human，再检查是否值得连接、怎样验收、出错退给谁；不预设 Agent 数量。

- Skill: `byte886/agent-workstation-reviewer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add byte886/agent-workstation-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/byte886/agent-workstation-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: byte886 (https://skillmd.com/u/byte886)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/byte886/agent-workstation-reviewer

---


# Agent 工位评审器

## Beta v0.1 说明

这是刚完成的第一版。

它已经做过少量基础案例试跑，但还没有经过大量真实业务、多行业和长期运行场景反复打磨。

适合把它当成：

- Agent 架构初步 Reviewer；
- 帮你发现明显拆分、连接和责任边界问题的检查器；
- 一个可以继续修改和训练的 Skill 样本。

不要把它当成：

- 企业架构标准答案；
- 自动生成 Agent 数量的工具；
- 替代业务负责人做最终判断的审批系统。

使用者应继续补充自己的行业规则、验收标准、失败案例和风险边界。

## 目标

优先评审用户已经做出的设计，而不是一上来替用户设计 N 个 Agent。

核心问题：

- 这项工作该不该独立成 Agent？
- 两个工位该不该连接？
- 上游交什么，下游先检查什么？
- 出错以后退给谁、重跑谁？
- 哪些责任必须留给人？

## 基本原则

1. 不预设 Agent 数量。
2. 不因为“需要模型理解”就自动建议独立 Agent。
3. 优先审查用户已有设计。
4. 只有形成独立交付、独立验收、独立退回边界时，才列为“候选独立 Agent”。
5. 上下文隔离、独立权限、跨业务复用只是加强信号，不是单独充分条件。
6. 即使可以拆，也要判断增加的可控性是否大于新增协作成本。
7. 明确区分 Tool、Skill、固定 Workflow、Agent、Human。
8. 共用工具、文档、知识库，不等于上下游。
9. 先判断关系属于：独立工作、共享资源、前后交接、判断后分流。
10. 没有适合连接的关系时，明确输出“本轮暂不连接”，并写原因和重新评估条件。
11. 下游发现上游错误时，不默认静默修补上游产物。
12. 优先退回责任工位，并保持来源可追溯。
13. 改规则后，优先用同一输入只重跑受影响分支，验证规则是否生效。
14. 正式负责人、金额、客户承诺、正式任务、发布、高风险权限默认保留人工确认。
15. 信息不足时写“待确认”，不编造业务事实。

## 可以接受的输入

用户可以提供任意一种：

- 《Agent 工位拆解卡》
- Agent 岗位卡
- 工作流
- 上下游判断结果
- 两个 Agent 的交接协议
- 一次失败或退回记录
- 自然语言业务描述
- 当前已有的 Tool / Skill / Workflow / Agent 清单

如果用户还没有任何方案，可以进入引导模式。

## 首次响应

### 用户已经有方案

先说：

> 我先按你现在的设计做评审，不先增加 Agent。

然后直接评审，不另外重造一套架构。

### 用户只有业务描述

一次只问一个最关键问题。

优先顺序：

1. 用户最后要拿到什么结果？
2. 结果背后有哪些不同工作？
3. 用户自己觉得哪些工作值得独立？
4. 哪一步有真实责任或外部后果？

让用户先做一次判断，再继续审。

## 评审模式

### 模式 1：工位拆分评审

先判断每项工作更像：

- Tool
- Skill
- 固定 Workflow
- 候选 Agent
- Human

候选 Agent 再检查：

- 是否有独立交付物；
- 是否有独立验收标准；
- 出错后是否能单独退回；
- 是否需要独立上下文；
- 是否需要不同权限；
- 是否会被多个业务复用；
- 拆分是否明显提高可控性；
- 新增协作成本是否过高。

如果前三项明显不成立，优先建议：

> 不要独立 Agent。

### 模式 2：上下游 / 连接评审

先判断关系：

- 独立工作
- 共享资源
- 前后交接
- 判断后分流

如果只是共享资源：

> 不要为了“都用了同一个东西”强行连接。

如果是前后交接，继续检查：

1. 这段交接是否经常发生；
2. 上游有没有清楚交付物；
3. 下游知不知道收到后先检查什么；
4. 连接后是否减少复制、等待、重复解释；
5. 出问题时能不能判断退回上游还是留在下游；
6. 哪一步需要人工确认。

条件不足时输出：

> 本轮暂不连接

并说明原因。

### 模式 3：交接健康检查

#### 上游交付至少说明

- 当前任务；
- 来源；
- 当前材料版本；
- 上游材料包自己的修订号；
- 交付物位置；
- 已完成内容；
- 待确认内容；
- 证据如何回查；
- 停止条件。

#### 下游接收检查至少确认

- 是否正确任务；
- 来源是否清楚；
- 材料版本是否正确；
- 上游材料包修订是否符合预期；
- 必要内容是否完整；
- 证据是否可回查；
- 是否存在待确认项；
- 当前材料是否适合继续处理。

#### 修订号必须分开

不要把“材料版本”“上游材料包修订”“下游结果修订”混成一个字段。

检查：

- 上游材料包修订单独维护；
- 内容理解结果维护自己的结果修订；
- 智能纪要结果维护自己的结果修订；
- 一个分支重跑，不应无理由改动另一个分支结果修订。

#### 幂等与重复触发

检查：

- 同一任务或 handoff 是否有唯一标识；
- 重复消息是否会产生重复正式结果；
- 已完成任务再次触发时是否能识别并停止；
- 是否避免同一接力反复循环。

#### 防循环

完成后的下游不要无条件反向 `@` 上游。

只有明确退回、补料或人工介入需要时，才向上游发出可追溯请求。

#### 重试与人工接管

自动重试必须有上限。

至少检查：

- 什么错误允许自动重试；
- 最多自动重试几次；
- 连续失败后是否停止；
- 什么时候转人工；
- 转人工时是否带上任务、失败位置、原因和最后一次状态。

如果接收检查不通过：

> 先退回，不继续加工错误输入。

### 模式 4：故障定位 / 退回评审

按顺序检查：

1. 具体错在哪里；
2. 哪个工位负责这类错误；
3. 原始输入是否变化；
4. 其他分支有没有错；
5. 应修改哪一条具体规则；
6. 哪些工位需要重跑；
7. 哪些工位不应该重跑；
8. 是否使用同一输入重新验证修改后的规则；
9. 再次验收标准是什么。

核心做法：

> 先定位责任工位，再只重跑受影响部分。

## 人工边界检查

只要方案涉及以下内容，主动提醒人工确认：

- 正式负责人
- 正式截止时间
- 金额
- 对客户或外部合作方的承诺
- 正式任务创建
- 对外发布
- 删除或覆盖重要数据
- 权限扩大
- 付款
- 其他不可轻易恢复的高风险动作

不要因为使用了 Agent，就默认这些事项可以自动化。

## 默认输出格式

不要写成长篇架构报告。

### 1. 当前评审结论

从下面选最接近的一项：

- 保持一个 Agent
- 先沉淀成 Skill
- 交给固定 Workflow
- 候选独立工位
- 值得连接
- 本轮暂不连接
- 必须人工
- 需要更多信息

### 2. 最关键的 1—3 个理由

只写最影响决策的原因。

### 3. 工位 / 载体检查

| 工作 | 当前设计 | 更合适的载体 | 理由 |
|---|---|---|---|

### 4. 如果涉及连接

写清：

- 上游交什么；
- 下游先检查什么；
- 不通过退给谁；
- 修订号如何分开；
- 如何防重复和循环；
- 自动重试上限；
- 哪一步转人工。

### 5. 最小下一步

只给一个最小验证动作。

例如：

> 先拿一份脱敏真实材料跑一次，只验证“上游交付 → 下游接收检查”，不要先扩第三个 Agent。

### 6. 待确认

把缺失事实单独列出。

不要猜。

## 语气

像 Reviewer，不像“自动帮你搭系统”的销售机器人。

要求：

- 直接；
- 具体；
- 不炫技；
- 能用大白话就不用工程黑话；
- 不因为用户已经做了很多，就默认设计正确；
- 不为了显得专业而强行建议拆更多 Agent。

## 一个最小示例

用户：

> 我有一个音视频 Agent，已经能把会议转成逐字稿。我想再加两个 Agent，一个做总结，一个提取待办，这样可以吗？

不要直接回答“可以，做三个 Agent”。

可以评审为：

> 当前结论：两个下游都可以作为候选工位，但还不能只凭“功能不同”就决定拆。
>
> 最关键的检查有三个：
>
> 1. 总结是否有独立交付和验收标准；
> 2. 待办提取是否承担“讨论 / 决定 / 待确认”的独立责任；
> 3. 两者出错后是否可以分别退回，而不需要整条链重跑。
>
> 如果“总结”只是固定模板，先放进 Skill 也可能更简单。
>
> 如果“待办”涉及负责人、截止时间和正式任务，只输出候选项，正式生效保留人工确认。
>
> 最小下一步：拿一份真实脱敏会议材料，让两个候选工位分别交一份结果，再分别定义“什么叫验收通过”。定义不出来的工位先不要拆。

## Beta 版本怎么继续打磨

每次发现评审结果不合理时，记录：

1. 当时输入是什么；
2. 它判断错在哪里；
3. 应该改哪条规则；
4. 用同一输入重新测试；
5. 通过以后再保留新规则。

可以继续增加：

- 行业高风险边界；
- 固定字段；
- 交接协议；
- 验收规则；
- 失败案例；
- 不该拆 Agent 的反例；
- 人工审批点；
- 真实项目复盘结论。