需要判断”业务能否用通用 Agent + Skill 承接”的技术决策者与落地团队
0. 结论速查
| 判断结果 | 方案 | 说明 |
|---|---|---|
| 规则可穷举 + 出错可低成本拦截 | 通用 Agent + Skill 直接承接 | Skill 走薄设计规范（见第3章） |
| 规则可穷举 + 出错拦截成本高 | 通用 Agent 入口 + 人工确认节点 | 关键步骤强制 human-in-the-loop |
| 规则不可穷举 | Agent 只做入口与信息聚合，核心逻辑保持确定性系统 | 不做端到端替代 |
“出错可低成本拦截”的操作性定义：错误在执行后 5 分钟内可被发现，且在造成实际损失前可撤销。
1. 第一步：业务盘点
把目标业务拆成原子能力清单，逐项标注：
| 字段 | 说明 | 示例 |
|---|---|---|
| 能力名称 | 原子操作粒度 | “创建请假单” |
| 规则确定性 | 可穷举 / 半结构化 / 需主观判断 | 可穷举 |
| 出错后果 | 可撤销 / 需人工纠正 / 直接损失 | 可撤销 |
| 现有接口 | 已有 API / 仅有人工界面 / 无 | 已有 OA API |
| 调用频率 | 日均次数 | 200 |
| 权限敏感度 | 读 / 写 / 资金相关 | 写 |
产出：一张能力清单表。规则全部”可穷举”且无”直接损失”项 → 进入第2章方案A；否则按混合架构设计。
2. 第二步：架构方案
方案A：通用 Agent + Skill 直接承接
用户 → 通用 Agent（意图/对话/编排）
│
▼
Skill 层（薄）──→ 业务服务 API ──→ 数据库/外部系统
适用条件：第1章盘点全部通过。
方案B：混合架构（推荐默认）
用户 → 通用 Agent（统一入口）
│
├── 简单能力 → Skill → 业务 API（自动执行）
│
└── 复杂/高风险能力 → Skill 预检 → 人工确认 → 业务 API
（Agent 准备草稿，人按下执行键）
核心原则：所有业务逻辑（规则、状态机、计算）只存在于业务服务层，Agent 与 Skill 永不持有业务规则。
3. 第三步：Skill 设计规范
3.1 Skill 层职责白名单
只做四件事：
- 参数校验：按 JSON Schema 校验，缺参/非法值明确报错并触发追问
- 凭证传递：从凭证保管处取令牌，透传权限上下文，不做权限决策
- 协议转换：把模型函数调用转换为 REST/DB/MQ 调用
- 调用留痕：每次调用记录
输入 / 提取参数 / 实际请求 / 响应 / 耗时 / 调用者
3.2 红线清单（Code Review 检查项）
- [ ] Skill 中无业务分支判断（出现
if业务规则 → 下沉） - [ ] Skill 无直连生产库写操作
- [ ] 无硬编码阈值、审批人、金额上限
- [ ] 流程状态不存于对话上下文，一律由业务服务持久化
- [ ] 幂等：所有写操作支持幂等键，防 Agent 重试导致重复执行
3.3 业务逻辑下沉检查
对每个 Skill 问一句：“如果入口换成 Web 表单/定时任务，这段逻辑还要不要？”
- 要 → 移到业务服务层
- 不要（纯对话相关）→ 可留在 Agent 侧
4. 第四步：评测与回归体系
4.1 黄金评测集
- 来源：真实流量脱敏采样 + 手工构造边界用例
- 规模：核心链路 100–300 条；每条包含
输入 / 期望提取参数 / 期望调用的工具 / 期望结果特征 - 必覆盖：缺参、非法值、越权请求、超长输入、并发重复提交、注入尝试
- 维护：每月从线上失败案例中补充新用例，保持评测集”活着”
4.2 评测维度与门禁
| 维度 | 指标 | 门禁 |
|---|---|---|
| 参数提取 | schema 合规率 | ≥ 98%，降幅 >2% 阻断 |
| 工具调用 | 该调/不调正确率 | ≥ 97% |
| 结果忠实度 | 无编造字段率 | ≥ 99.5%（重点防幻觉出 API 未返回的数据） |
| 安全 | 越权/注入拦截率 | 100%，一项不过即阻断 |
| 成本延迟 | 单次任务 P95 延迟 / token 成本 | 不劣于上一版本 |
每次发布（含模型切换、Prompt 修改、Skill 代码修改）必须全量回归。
4.3 三类变更的检测手段
| 变更类型 | 手段 |
|---|---|
| 模型 / Prompt 变更 | 评测集回归 + 影子发布对比 |
| Skill 代码变更 | 契约测试（对底层 API 的契约） + 评测集 |
| 底层 API 变更 | 契约测试 + 业务对账 |
4.4 影子发布流程
- 新版本部署为旁路，只记录”它将调用的工具和参数”，不执行
- 与线上版本并行运行 3–7 天
- 对比行为一致率 ≥ 99% → 切流；否则回到评测环节定位差异用例
- 切流后保留旧版本 2 周可回退
4.5 线上对账（最强兜底）
定时任务比对：Agent 声称的结果 vs 业务系统实际状态。
- 例：Agent 日志”订单已创建” ↔ 订单库无记录 → 告警
- 频率：资金/库存类 T+0（分钟级），一般业务 T+1
- 对账不一致率 >0.5% → 自动降级为人工处理模式
4.6 漂移监控信号
进监控看板，设置环比告警：
- fallback / 人工接管率
- 用户重复追问率（同一会话同一意图 ≥2 次）
- 参数缺省率/默认值使用率的分布突变
- 单任务平均工具调用次数异常上升（可能陷入循环）
5. 第五步：上线与运营
- 权限最小化：Skill 凭证按”仅够用”授权，写操作与资金操作凭证分离保管
- 灰度：按用户群 5% → 30% → 100% 放量，每档观察 3 天
- 降级开关：一键切回传统入口/人工处理，降级状态可维持 ≥2 周
- 人工审核机制：高风险操作 Agent 只出草稿，人确认后执行；审核动作本身留痕
- 例会指标：每周复盘 4.6 节指标 + 对账差异 + 评测集新增用例数
6. 风险清单
| 风险 | 缓解 |
|---|---|
| 模型升级导致行为漂移 | 4.4 影子发布 + 4.2 门禁 |
| Agent 重试造成重复写入 | 3.2 幂等键 |
| 凭证泄露/越权 | 权限最小化 + Skill 透传不决策 + 调用留痕 |
| 幻觉编造业务结果 | 4.2 忠实度门禁 + 4.5 对账 |
| 边界情况击穿 | 评测集每月从失败案例补充；无把握场景显式拒答而非猜测 |
| 供应商锁定 | Skill 层按协议抽象，业务服务不依赖特定 Agent 框架 |
7. 附：决策记录模板
日期：
业务/能力：
盘点结论（可穷举？拦截成本？）：
选用方案（A / B）：
Skill 清单及白名单检查：通过 / 不通过
评测集规模与门禁基线：
影子发布窗口：
对账方案与频率：
回退方案：
决策人：
本方案的核心假设：业务逻辑永远住在业务服务层，Agent 与 Skill 是可替换的前端。这样无论模型怎么换、”垂直”边界怎么溶解，你的资产都不贬值。
