业务 SOP 流程
自动化可行性调研

银行手续费补贴 · 额度迁移 · 运营工作流
1

场景拆分 — 不是一个问题，是两个

⚠️
不应该用一个统一的「SOP 引擎」覆盖全部场景。两张图是不同类型的对象。

📋 手续费补贴额度包迁移

性质：单案执行型流程，7步线性+分支

路径：半自动工作台 / 工单驱动

📊 日常运营工作项（5类异构清单）

工作项类型适合做法
额度配置配置执行工单 + 模板预填 + 校验
数据核对对账核验自动化比对 + 差异报告
手续追回财务操作审批流 + Maker-checker
客户经理添加主数据维护表单 + 邮件自动化
微信群答疑知识服务单独做 FAQ / RAG 助手
● ● ● ● ●
2

分层架构 — 不是三选一，而是三层组合

治理层
工单/审批系统 → 结构化收口邮件请求
留痕、审计、权限控制、Maker-checker、SLA 管理
执行层
有 API → API 调用  |  无 API → Attended RPA
最敏感操作保留人工。初期只自动化读操作、预填、校验、导入后核对
辅助层
SOP 引导 / 预检查 / 模板解释 / FAQ
YAML 定义流程、异常提示、新人培训。AI 仅做受控辅助
🚨
AI 只在第三层（辅助层），不直接替代控制面。
✦ ✦ ✦
3

被遗漏的 5 类重要方案

🤖 RPA / 浏览器自动化

内部系统没 API 时最现实的执行路径。跨系统人工搬运场景，最适合有人值守的 attended automation。

📝 BPM / 工单 / 审批流

邮件触发→核实→确认，天然适合申请-审核-执行-确认-留痕。飞书/钉钉审批流可做轻量入口。

🖥️ 运营工作台 / 表单化控制台

统一工作台让运营只录一次数据，系统负责校验、生成模板、引导后续动作。比本地 Skill 更易集中治理。

📥 入口收口：邮件/微信群 → 结构化表单

入口不收口，后面再怎么自动化都难追踪、难审计。入口结构化本身就是关键方案。

💬 FAQ / RAG 知识助手

微信群答疑是知识服务，不应跟交易执行型流程混在一起。适合单独做知识库检索助手。

● ● ● ● ●
4

安全合规风险

风险说明
数据泄露邮件/模板/微信消息含客户信息，本地工具有缓存泄露风险
Maker-checker额度迁移/手续追回涉及财务，AI checklist ≠ 复核通过
审计留痕谁查了什么、谁改了什么、谁确认了，必须可回放
异常重试导入失败重试可能导致重复导入、数据不一致
权限 / MFA内部系统手机号+验证码登录，全自动化天然受限
模型幻觉漂亮的 AI 输出制造「已验证」的错误信任
变更治理SOP/模板/规则变更需要版本管理和审批发布
✦ ✦ ✦
5

推荐方案

⚡ 快速试点（1-2 周）

Antigravity Skill + YAML — 明确它只是试点/培训工具：

  • SOP 数字化 + 操作引导 + 预检查
  • 不承担企业级运行平台职责
  • 适合单人使用或小范围验证

🏢 正式落地方案

中心化运营工作台 + 配置化 SOP + API 优先/RPA 补位 + AI 受控辅助

  • 前台：工单/审批统一受理（飞书/钉钉/内部平台）
  • 中台：结构化流程定义 + 校验规则
  • 后台：API 优先，没 API 就 attended RPA
  • AI：仅做辅助（引导、解释、预检查、FAQ）

🔀 两个场景分开做

  • 额度迁移流程：工单 + 结构化表单 + 模板预填 + 导入前校验 + 导入后复核
  • 日常运营工作项：按类型挂在统一工作台下，分建子流程
  • 微信群答疑：单独做知识助手，不强行并入执行型自动化
● ● ● ● ●
6

开源引用适配度

项目适配度意见
Strands Agent SOP 高 最相关，适合论证「AI 按 SOP 运行」的可行性
jrswab/axe 中 CLI Agent runner 参考，不是银行落地依据
workflows-mcp-server 中 前提是已有可编排的工具
IBM BAW MCP 低 需已有 IBM BAW + REST 服务
Process Street MCP 移除 是商业产品能力，不是开源参考

一句话结论

快速验证用 Skill + YAML，
正式落地用 工作台 + 审批流 + RPA + AI 辅助 的分层架构。