SOP 不是文档堆，它决定 Agent 能走多远
如果 SOP 只是零散截图、口口相传和旧文档拼在一起，Agent 再聪明，也只会在错误边界里工作。
企业里很多人一说到 Agent，就会立刻想到模型、提示词、工具调用。
但我最近在现场里越来越强烈地感觉到：决定 Agent 能走多远的，往往不是模型上限，而是 SOP 的质量。
因为对企业系统来说，SOP 不是“说明书”，它本质上是边界。
先判断 SOP 成熟度，再决定 Agent 能走多远
我通常把 SOP 成熟度分成四级。这个分级不是认证标准，而是我在匿名流程梳理中用来决定自动化边界的工作框架：
| 级别 | 现场状态 | Agent 适合做什么 | 升到下一级需要补什么 |
|---|---|---|---|
| L1 口头经验 | 规则主要在人脑和聊天记录里，同一问题可能有不同答案 | 只帮助整理访谈、归类样本，不执行流程 | 写出主流程、输入输出和常见例外 |
| L2 静态文档 | 主流程已经成文，但版本、例外和责任人不清 | 检索、摘要、生成待确认材料 | 指定 owner，补版本、有效期和例外记录 |
| L3 可维护规则 | 规则有来源、有版本、有 owner，例外能够沉淀 | 运行小范围、可回退的工作流试点 | 定义权限、质量校验、接管和回写方式 |
| L4 可执行边界 | 输入、输出、权限、校验、接管和回写均已定义 | 承担边界明确的稳定节点 | 持续监控规则变化和异常分布 |
很多团队的问题不是“完全没有 SOP”，而是把二级文档直接当成四级规则使用。模型能读到内容，不等于系统已经知道什么能做、什么不能做。
使用这张表时，我不会给整个组织打一个总分，而是按工作流逐条判断。同一家公司里，会议纪要流程可能接近 L4，报价规则可能仍停在 L2。Agent 的权限应该跟着具体流程的成熟度走，而不是跟着企业是否“已经上了 AI”走。
一份可以直接使用的 SOP 上线前检查清单
准备让 Agent 接入某条流程前，可以逐项检查下面十个问题。只要有一项回答不清楚，就先把 Agent 限制在检索、整理或生成待确认材料的范围内：
| 检查项 | 通过标准 |
|---|---|
| 输入 | 必需字段、可选字段和缺失时的动作已经写清 |
| 输出 | 输出格式、质量标准和使用对象已经明确 |
| 规则来源 | 每条关键规则能回到原始文件或系统记录 |
| 版本 | 当前有效版本、生效时间和失效状态可查询 |
| 例外 | 高频例外与未覆盖场景有统一记录入口 |
| 权限 | 系统可以读、可以建议和可以写回的边界分开定义 |
| 校验 | 关键字段、规则引用和外部承诺有检查机制 |
| 接管 | 触发条件、接管人、时限和交接字段已经指定 |
| 回写 | 人工决定和新例外能返回原任务与知识入口 |
| Owner | 有具体角色负责规则更新、异常复盘和权限调整 |
这不是要求团队一次把所有文档整理完，而是帮助项目明确当前能自动到哪一步。没有通过的检查项，应该直接转化成试点待办，而不是留给模型猜测。
1. SOP 决定了系统能参考什么
如果一条流程的处理规则只存在于几个老员工的经验里，或者散在聊天记录、截图、Excel 备注和过时文档里，Agent 实际上没有稳定的依据。
这时候再强的模型，也只能在不稳定信息上做推断。它看起来像是在帮你工作，实际是在替混乱做加速。
所以我现在看知识准备度时，不会先问“有多少份文档”，而会问：
- 规则是否真的成文
- 版本是否清楚
- 例外情况是否被记录
- 谁对这份 SOP 的更新负责
2. SOP 决定了系统不能做什么
很多团队喜欢把 SOP 理解成“告诉系统该怎么做”。但从设计角度看，SOP 还有另一层更重要的作用：告诉系统哪里不能越界。
比如：
- 哪些字段只能建议、不能自动写回
- 哪些情况必须人工复核
- 哪些客户问题不能直接回复
- 哪些异常必须升级到上一级处理
这些边界如果不被明确写出来，Agent 越会推理，越容易在错误范围里“自信地工作”。
3. SOP 不是一次性整理，而是持续维护机制
很多企业愿意花一点时间把知识整理成一版文档，但真正困难的是后续维护。
如果没有版本管理、更新责任和例外沉淀，再好的知识库很快也会失效。系统刚上线时表现不错，几周后就开始漂移，最后大家得出结论：“AI 还是不稳定。”
其实很多时候，不稳定的不是 AI，而是它所依赖的知识来源。
一个版本冲突案例：两个答案都“有依据”
下面是根据常见知识维护问题重构的示意案例，不是任何公司真实业务记录。
一条业务规则先后出现了两个文档版本。旧版仍在共享目录中，新版通过聊天附件发出，但没有写生效日期，也没有标记旧版失效。Agent 检索时同时找到了两份材料。由于两份文档的表达都完整，它可以为任意一个答案找到“合理依据”。
这类错误最危险的地方，不是回答荒谬，而是回答听起来很专业。只检查语言质量，很难发现问题；必须检查规则来源、版本和有效性。
我会把修正动作拆成五步：
- 暂停这个节点的自动执行，只保留检索辅助。
- 由规则 owner 确认当前有效版本和生效时间。
- 给旧版增加明确的失效状态，而不是只移动文件位置。
- 让每次系统输出同时携带规则编号、版本和引用片段。
- 把“同时命中两个有效版本”设为人工接管触发器。
这个案例也说明，知识库不是把文档都放进去。真正可执行的知识需要一条清楚的生命周期：谁发布、何时生效、何时失效、遇到冲突交给谁。
4. 我越来越把知识重构看成 AI 项目的前置工程
以前很多团队会把知识整理当成“上线之前顺手做一点”。现在我更倾向把它看成正事，而且往往是最该先做的事。
如果想让 Agent 真正进入企业流程，至少要把这些东西慢慢建立起来：
- 一套清楚的 SOP 结构
- 例外情况的记录机制
- 可维护的知识入口
- 对边界和权限的明确描述
模型、工具、编排都很重要，但如果没有一套干净、可信、能持续维护的 SOP，Agent 的能力始终像悬在空中。
很多所谓“Agent 项目”，最后真正做成的不是一个聪明系统，而是一套更清楚的组织知识结构。我越来越觉得，这反而是更有价值的结果。
下一步可以结合AI 工作流人工接管清单检查异常路径，或从货代询价与报价流程拆解看一条具体业务流程如何落到规则、例外和 owner。要把这些节点串成完整推进顺序，可以继续阅读AI Agent 接手正式工作专题。