# Agent Boundary Design

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

- Skill: `agenticaiplan/agent-boundary-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add agenticaiplan/agent-boundary-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agenticaiplan/agent-boundary-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: agenticaiplan (https://skillmd.com/u/agenticaiplan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agenticaiplan/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，至少包含以下内容：

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