L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Design et création · SKILL.md

agent-boundary-design

agent-boundary-design

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

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

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 范围。

Skills enregistrées