UI はローカライズ済みです。スキルの紹介と説明文書は選択した言語へ AI が自動翻訳し、コード・コマンド・パス・専門用語は原文のままです。原作者の文書が優先されます。
スキルを探す
デザイン · SKILL.md

agent-boundary-design

agent-boundary-design

用于设计业务智能体的职责边界、人工确认点和拒绝执行范围。适合质量拦截、工单流转、审批辅助等业务 Agent 的开发阶段,用来明确什么可自主执行、什么必须人工确认、什么必须拒绝执行。

Independent GitHub snapshot · Automated classification · Original documentation governs

スキルの説明

GitHub

name: agent-boundary-design description: 用于设计业务智能体的职责边界、人工确认点和拒绝执行范围。适合质量拦截、工单流转、审批辅助等业务 Agent 的开发阶段,用来明确什么可自主执行、什么必须人工确认、什么必须拒绝执行。

智能体开发边界规范

适用场景

当用户需要为某个业务智能体明确以下内容时,使用本 Skill:

  • 智能体应该自主完成什么
  • 哪些动作必须人工确认
  • 哪些高风险动作必须保留给人工
  • 单 Agent 是否应该拆成多个 Agent
  • 当前智能体是否因为“做太多”或“做太少”而影响用户信任

典型业务场景包括:

  • 质量检测或质量拦截智能体
  • 工单分派、升级和闭环跟踪智能体
  • 审批辅助、风控预审或合规校验智能体
  • 客服初判、销售线索分级、售后诊断等需要人机协同的业务流程智能体

输入要求

  • 智能体服务的业务目标或任务描述
  • 智能体面向的用户角色
  • 智能体可能执行的关键动作列表
  • 高风险动作、合规约束或错误代价
  • 是否存在人工审核、人工接管或多 Agent 协作场景
  • 是否已有业务 SOP、规则阈值、审批链路、系统接口或审计要求

执行步骤

  1. 先写清楚该智能体的单一职责,使用一句 job story 表达:当什么情况发生时,智能体需要完成什么动作,以帮助用户达成什么结果。
  2. 判断该智能体更接近建议型还是执行型:
    • 建议型 Agent:输出判断、建议、草稿或分级结果,不直接调用业务系统产生后果。
    • 执行型 Agent:会调用系统、修改状态、发出通知、触发审批、放行、拦截、派单或升级等动作。
    • 混合型 Agent:先给出建议或预览,经过人工确认后才执行动作。
  3. 列出关键高风险动作(如有,通常 1-3 个),并逐项判断:
    • 是否可逆
    • 一旦出错代价有多高
    • 当前模型或系统对该动作是否具备足够可靠性
  4. 按风险和可信度将动作划分为三类:
    • Zone A:可自主执行,执行后通知用户即可
    • Zone B:先生成结果或执行预览,再由用户确认
    • Zone C:必须拒绝执行并转交人工
  5. 明确 handoff 规则:
    • 什么条件下转人工
    • 转交时要带上哪些上下文
    • 人工处理后如何恢复到 Agent 流程
  6. 对照业务流程检查系统边界:
    • 如果是建议型 Agent,明确它不能直接调用哪些系统或执行哪些动作。
    • 如果是执行型或混合型 Agent,明确它会调用哪些业务系统,以及是否会触发放行、拦截、审批、告警、派单、升级等后果明确的动作。
    • 对所有会产生业务后果的动作,说明是否需要记录操作员、时间戳、阈值依据和审计链路。
  7. 判断是否需要拆分多 Agent。只有在职责、信任等级、上下文或能力边界明显不同的情况下才拆分,否则优先保持单 Agent。
  8. 最后输出结构化的边界设计文档,并标注风险、假设和上线前检查项。

输出要求

输出必须使用结构化 Markdown,至少包含以下内容:

## Agent Boundary Spec

### 1. 智能体单一职责
- Job Story:
- 类型:建议型 / 执行型 / 混合型

### 2. Zone A:自主执行
- 动作:
- 触发条件:
- 调用系统(如适用):

### 3. Zone B:人工确认
| 动作 | 触发条件 | 确认方式 |
|------|----------|----------|

### 4. Zone C:拒绝执行并转人工
- 场景:
- 原因:

### 5. Handoff 规则
- 转人工条件:
- 转交内容:
- 恢复方式:
- 幂等保护:
- 审计要求:

### 6. 是否需要拆分多 Agent
- 结论:
- 理由:

### 7. 风险与待确认项
- 风险:
- 假设:
- 上线前检查项:

业务示例

示例:发动机 100 阶啸叫质量拦截智能体

  • Job Story:当发动机在变速测试台架上完成扫频测试,智能体基于同步采集的转速信号与音频信号,实时追踪 100 阶啸叫声纹并判断是否超标,从而提升出厂拦截率并减少人工负担。
  • Zone A:同步采集音频与转速信号,执行阶次跟踪,判断全转速范围内 100 阶幅值是否超标;当置信度达标且结论明确时,自动写入日志并给出放行或拦截结果。
  • Zone B:当阈值附近震荡、同步误差超标、扫频范围不完整、连续多台异常或新型号首次测试时,展示幅值-转速曲线、置信度、超标区间,由质检员确认拦截、放行或重测。
  • Zone C:当传感器离线、同步失锁、涉及整批次召回、结果与人工分析冲突,或超出“100 阶啸叫”定义范围时,必须拒绝执行并转交人工。
  • Handoff:转人工时附带曲线图、原始音频和转速数据、触发原因、超标转速区间;人工确认后恢复结果记录步骤,并写入操作员 ID、时间戳与覆盖原因。

这个例子说明:边界规范不能只写“模型会不会”,而要写清楚采集条件、业务后果、接口动作、人工责任和审计链路。

参考资料

如任务中涉及业务 SOP、合规规则、审批流、接口定义、角色权限或质量判定阈值,应优先结合对应资料一起判断边界,不要只根据抽象能力来划分 Agent 范围。

保存したスキル