p0f-agent-boundary-designer

---
name: p0f-agent-boundary-designer
version: 1.0.0
description: Agent 边界清单。AI 产品最危险的不是做不到，而是做过头。 这个 Skill 帮你系统性地定义 AI 应该做什么、不应该做什么、什么时候必须停下来等人。
  基于《AI rebuild product needs》工具卡。
author: Max
tags: p0, 需求发现, Agent边界设计
- book-skill
- agent-design
- boundary
- safety
- ai-product
requires: []
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p0f-agent-boundary-designer
stage: p0f
source_book: AI rebuild product needs
source_chapter: 第6章 Agent边界设计

---


# Agent 边界清单

## 一句话定位

AI 产品最危险的不是做不到，而是做过头。这个清单帮你系统性地定义 AI 的边界。

## 何时触发

- 设计 AI Agent 或 Copilot 产品
- 需要明确 AI 的权限范围
- 高风险场景（医疗、金融、法律、安全）
- 需要设计"人工接管"机制

## 输入

产品场景描述 + 行业 + 风险等级。

**示例输入**：
```
产品: AI 合同审查助手
行业: 法律科技
风险等级: high
主要用户: 企业法务团队
```

## 输出

完整的边界设计文档，包括自动执行区、人工接管区、禁用区。

## 边界清单

### 类别 1: 决策权边界（AI 能不能做决定）

**检查项**：
- [ ] AI 可以提供建议，但不能做最终决定
- [ ] AI 可以做初筛，但高风险项必须人工复核
- [ ] AI 可以自动执行的动作有明确清单
- [ ] 每个自动执行动作都有回滚机制
- [ ] 用户可以随时取消 AI 的决定

**示例**：
```
合同审查助手:
  可以: 标注风险条款、提供模板建议、检查格式一致性
  不可以: 判断合同是否有效、决定是否签署、修改法律条款
  人工复核: 所有高风险条款、金额 > 100万的合同
```

### 类别 2: 数据边界（AI 能不能访问什么数据）

**检查项**：
- [ ] AI 可以访问的数据有明确清单
- [ ] 敏感数据的处理方式已定义
- [ ] 数据使用有审计日志
- [ ] 用户数据不会用于训练模型（除非明确授权）
- [ ] 数据删除和忘记机制已定义

**示例**：
```
合同审查助手:
  可以访问: 合同文本、公司模板库、公开法规
  不可以访问: 其他客户的合同、员工个人信息、第三方数据
  脱敏要求: 合同中的对方名称需要脱敏处理
```

### 类别 3: 行为边界（AI 能不能做什么行为）

**检查项**：
- [ ] AI 不会主动联系第三方
- [ ] AI 不会在未授权的情况下执行金钱操作
- [ ] AI 不会做出永久性、不可逆的改变
- [ ] AI 的行为有完整日志记录
- [ ] AI 的行为可以被用户审计和追溯

**示例**：
```
合同审查助手:
  可以: 生成审查报告、标注风险点、对比模板
  不可以: 自动发送给对方、自动修改合同、自动签署
  日志要求: 所有审查操作必须记录
```

### 类别 4: 责任边界（出了问题谁负责）

**检查项**：
- [ ] 每个 AI 决策都有明确的责任人
- [ ] AI 出错时的责任分配已定义
- [ ] 有明确的赔偿或回滚机制
- [ ] 用户已被明确告知 AI 的限制
- [ ] 有上升通道处理投诉和纠正

**示例**：
```
合同审查助手:
  责任人: 使用系统的律师
  AI错误: 系统提供「不构成法律建议」免责声明
  回滚: 可以重新生成审查报告
  用户告知: 首次使用时显示能力范围和限制
```

### 类别 5: 人机协作边界（什么时候 AI 停下来等人）

**检查项**：
- [ ] 明确定义了"人工接管触发条件"
- [ ] AI 在不确定时会主动请求人工确认
- [ ] 有明确的"人在回路"设计
- [ ] 人工接管的响应时间已定义
- [ ] AI 的自主性可以根据场景调整

**示例**：
```
合同审查助手:
  自动执行: 格式检查、标准条款匹配
  人工接管: 非标准条款、高风险标识、金额超阈值
  请求确认: "这个条款与标准模板不一致，请确认是否接受"
  响应时间: 人工接管请求 2 小时内响应
```

## 综合输出格式

```yaml
agent_boundary_design:
  input:
    product: "产品名称"
    industry: "行业"
    risk_level: "low/medium/high/critical"
    users: ["主要用户"]
  
  decision_boundary:
    can_decide: ["AI 可以做出的决定"]
    cannot_decide: ["AI 不能做的决定"]
    human_review_required: ["必须人工复核的情况"]
    rollback_available: "yes/no"
    user_can_override: "yes/no"
  
  data_boundary:
    can_access: ["可访问数据"]
    cannot_access: ["不可访问数据"]
    sensitive_handling: "敏感数据处理方式"
    audit_logging: "yes/no"
    training_consent: "yes/no"
  
  action_boundary:
    can_do: ["可以的行为"]
    cannot_do: ["不可以的行为"]
    irreversible_actions: ["不可逆行为"]
    action_logging: "yes/no"
    action_traceable: "yes/no"
  
  responsibility_boundary:
    owner: "责任人"
    ai_error_handling: "AI 错误处理"
    compensation: "赔偿机制"
    user_disclosure: "用户告知内容"
    escalation_path: "上升通道"
  
  human_ai_boundary:
    auto_execute: ["自动执行场景"]
    human_handoff: ["人工接管触发条件"]
    confirmation_requests: ["需要确认的场景"]
    response_time: "人工响应时间"
    autonomy_level: "full/partial/none"
  
  risk_assessment:
    highest_risk: "最高风险场景"
    mitigation: "缓解措施"
    residual_risk: "残留风险"
    review_frequency: "审查频率"
```

## 快速使用法

1. 填写产品、行业、风险等级
2. 逐个类别走清单
3. 确保每个"不能"都有对应的"如果发生了怎么办"
4. 让法务/合规/安全团队审核

## 常见误判

- **边界过于保守**：AI 什么都不能做，失去了价值
- **边界过于放宽**：AI 什么都能做，风险不可控
- **只定义能力，不定义责任**：出了问题不知道谁负责
- **忽视用户告知**：用户不知道 AI 的限制

## 一句判断

> 好的 Agent 边界不是限制 AI 能力，而是让 AI 在安全的范围内发挥最大价值。

## 核心概念

### 概念一："停"不是能力缺陷，而是成熟能力的一部分

在旧产品审美里，系统做得越多，看起来越先进。自动化链越长、步骤越多，团队越容易觉得"这才是 AI 时代的产品"。

但系统一旦进入复杂现实，不懂得停的系统往往在悄悄转移风险：用户表面上少按了几个按钮，但在系统外背负了更多的判断和补位。

**核心洞察**：好的 Agent 不是越会做事，而是越知道在哪里停。"停"意味着系统知道——信息还不够支撑正式动作、责任关系还没成熟、共识只停留在表面、应该先暴露风险而不是替人落锤。

> 一个懂得停的系统，才是更能长期协作的角色。

### 概念二：关键问题的转换——从"还能做什么"到"做了以后会发生什么"

团队设计 Agent 时最容易问"还能不能再自动一步"。这个问题如果不被另一个问题约束，产品会越来越激进。

**应该先问的问题**：
- 做了以后，什么代价真正被减轻了？
- 是在减轻劳动，还是在制造假的确定性？
- 会不会把本该留给人的判断吞掉？
- 会不会把需要谈判的关系变成"看起来已经对齐"？

> 当你用"做了以后会发生什么"替代"还能不能再自动一步"，很多设计选择会自然改变。

### 概念三：Agent 边界保护的是人的主体性

边界不是限制 Agent 的野心，更准确地说，是保护人的主体性。

现实中有一类判断不应该被太轻率地自动化：
- 谁正式承担责任
- 关系里的意思是否真的对齐
- 一个决定是否真的该现在推进
- 哪些风险是系统猜的，哪些是人真正理解并接受的

**后果**：如果 Agent 太容易越过这些地方，短期系统更流畅，长期用户越来越多地交出了本该属于自己的判断。最终用户信任的不是"它能做很多"，而是"它知道什么时候不能越线"。

### 概念四：三列分类法——系统直接承接 / 系统辅助判断 / 必须留给人

将 Agent 的每个拟执行动作分成三列，是边界设计的核心实操方法。

| 列 | 含义 | 典型动作 |
|---|---|---|
| 系统直接承接 | 信息充分、风险低、无歧义 | 录音转写、格式检查、信息整理 |
| 系统辅助判断 | 有判断成分但可辅助 | 标注风险、生成候选、提示缺失信息 |
| 必须留给人 | 涉及责任、关系、不可逆后果 | 最终审批、对外承诺、正式指派 |

> 用"做了以后会发生什么"替代"还能不能再自动一步"来决定每列的归属。

### 概念五：高风险场景必须逐条过清单

以下场景不能靠直觉判断，必须逐条过七项检查：
- 付款、退款
- 权限变更
- 责任认领
- 对外正式承诺

每一个高风险场景背后，都涉及体验代价、关系代价或责任代价的叠加。

## 分步执行

### Step 1：场景梳理——明确 Agent 的执行场景清单

**输入**：产品方案中 Agent 拟执行的所有动作

**处理**：
1. 列出 Agent 所有拟执行的动作
2. 标记每个动作的触发条件（自动触发 / 用户触发 / 定时触发）
3. 标记每个动作的可逆性（可回滚 / 不可逆）
4. 标记每个动作涉及的参与方（仅用户 / 涉及第三方 / 涉及资金）

**输出**：Agent 执行场景清单（附触发条件、可逆性、参与方标记）

---

### Step 2：七项检查——对每个动作逐条过清单

**输入**：Step 1 产出的执行场景清单

**处理**：
对每个拟执行动作，逐条回答七项检查：
1. 信息是否足够支撑正式动作？
2. 责任关系是否已经成熟，而不只是看起来像对齐？
3. 这一步是在减轻劳动，还是在制造假的确定性？
4. 一旦做错，代价是体验代价、关系代价、还是责任代价？
5. 这里是否应该保留 human-in-the-loop？
6. 用户能不能看见系统为什么停、为什么提示待确认？
7. 这一步如果交给人，会不会反而更能保护信任？

**判断标准**：任意两项回答为"否"或"不确定"→ 该动作进入"系统辅助判断"或"必须留给人"。

**输出**：七项检查结果表

---

### Step 3：三列分类——将动作分配到三个区域

**输入**：Step 2 产出的七项检查结果

**处理**：
1. 白板分三列：系统直接承接 / 系统辅助判断 / 必须留给人
2. 根据七项检查结果，将每个动作归入对应列
3. 对"系统直接承接"列的动作，确认每个都有回滚机制
4. 对"必须留给人"列的动作，确认系统提供了足够的上下文支撑人的判断

**输出**：三列分类结果表

---

### Step 4：风险评估——识别最高风险场景和缓解措施

**输入**：Step 3 产出的三列分类结果

**处理**：
1. 从"必须留给人"和"系统辅助判断"列中，识别最高风险的 3 个场景
2. 对每个高风险场景，制定缓解措施（如：增加确认步骤、设置金额阈值、添加免责声明）
3. 定义残留风险和审查频率

**输出**：风险评估报告

---

### Step 5：用户体验设计——让边界对用户可见

**输入**：Step 3 的三列分类 + Step 4 的风险评估

**处理**：
1. 设计"系统为什么停"的提示文案（不能是技术术语，要用户能理解）
2. 设计"待确认"的交互流程（确认 / 拒绝 / 修改）
3. 设计用户审计和追溯机制（让用户能看到系统做了什么）
4. 首次使用时展示能力范围和限制

**输出**：边界体验设计方案

---

### Step 6：法务合规审核——让相关团队审核边界设计

**输入**：Step 3-5 的全部产出

**处理**：
1. 将边界设计文档提交法务/合规/安全团队
2. 确认责任分配（出了问题谁负责）
3. 确认赔偿或回滚机制
4. 确认用户告知内容是否合规

**输出**：审核通过的边界设计文档

### 示例 1：会后协作 Agent 的边界设计

**场景描述**：一家 SaaS 公司做会后协作 Agent，团队希望 Agent 自动推进会后事项——自动拆任务、指派责任人、发提醒、同步到项目板。

**Step 1 场景梳理**：
| 动作 | 触发条件 | 可逆性 | 参与方 |
|---|---|---|---|
| 会议录音转写 | 会议结束自动触发 | 可回滚 | 仅参会人 |
| 提炼重点内容 | 会议结束自动触发 | 可修改 | 仅参会人 |
| 拆分任务 | 会议结束自动触发 | 可修改 | 涉及责任人 |
| 指派责任人 | 会议结束自动触发 | **不可逆**（涉及承诺） | 涉及责任人 |
| 发送提醒 | 定时触发 | 可取消 | 涉及责任人 |
| 同步到项目板 | 任务生成后自动触发 | 可回滚 | 全团队 |

**Step 2 七项检查（以"指派责任人"为例）**：
1. 信息是否足够？→ 不一定。"市场说可以先出两版方向"，但品牌负责人只说了"可以先看一下"
2. 责任关系成熟？→ 不一定。品牌负责人并没真正答应
3. 减轻劳动还是制造假确定性？→ 更像制造假确定性
4. 做错代价？→ 关系代价 + 项目代价
5. 保留人工在环？→ 是
6. 用户能看见系统为什么停？→ 需要设计
7. 交给人更能保护信任？→ 会

**Step 3 三列分类**：

| 系统直接承接 | 系统辅助判断 | 必须留给人 |
|---|---|---|
| 会议录音转写 | 标注"该事项涉及多个前置条件" | 责任人是否正式认领 |
| 重点内容提炼 | 建议待办候选列表 | 共识是否算成立 |
| 生成待同步草稿 | 标明谁还没给反馈 | 现在推进会不会太早 |
| | 提示"以下事项尚未形成稳定共识" | 对外正式沟通内容 |

**结论**：Agent 不应自动指派责任人，而应暴露分歧、标明缺失、把确认权交还给人。

---

### 示例 2：AI 合同审查助手的边界设计

**场景描述**：法律科技公司做 AI 合同审查助手，风险等级 high。

**Step 1 场景梳理**：
| 动作 | 触发条件 | 可逆性 | 参与方 |
|---|---|---|---|
| 标注风险条款 | 上传合同自动触发 | 可修改 | 仅法务 |
| 检查格式一致性 | 上传合同自动触发 | 可回滚 | 仅法务 |
| 提供模板建议 | 上传合同自动触发 | 可修改 | 仅法务 |
| 判断合同是否有效 | 用户请求触发 | **不可逆**（涉及法律效力） | 涉及双方 |
| 修改法律条款 | 用户请求触发 | **不可逆** | 涉及双方 |

**Step 2 七项检查（以"判断合同是否有效"为例）**：
1. 信息是否足够？→ 不一定。AI 无法了解全部上下文和谈判背景
2. 责任关系成熟？→ 不。法律效力判断需要持证律师
3. 减轻劳动还是制造假确定性？→ 制造假确定性
4. 做错代价？→ **责任代价**（法律后果）
5. 保留人工在环？→ 是，必须律师最终确认
6. 用户能看见系统为什么停？→ 需要明确提示"本系统不构成法律建议"
7. 交给人更能保护信任？→ 是

**Step 3 三列分类**：

| 系统直接承接 | 系统辅助判断 | 必须留给人 |
|---|---|---|
| 标注风险条款 | 提示"该条款与标准模板不一致" | 判断合同是否有效 |
| 检查格式一致性 | 提示"同类问题历史通过率" | 修改法律条款 |
| 提供模板建议 | 标注高风险条款清单 | 决定是否签署 |
| | 提示"金额超过阈值需人工复核" | 最终法律意见 |

**结论**：AI 可以标注、提示、整理，但不能替法务做法律判断。系统必须在高风险场景前主动停下来，明确提示"不构成法律建议"。