agent-boundary-design

智能体开发边界规范

适用场景

当用户需要为某个业务智能体明确以下内容时，使用本 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、时间戳与覆盖原因。