SOP 不是文档堆，它决定 Agent 能走多远

企业里很多人一说到 Agent，就会立刻想到模型、提示词、工具调用。

但我最近在现场里越来越强烈地感觉到：决定 Agent 能走多远的，往往不是模型上限，而是 SOP 的质量。

因为对企业系统来说，SOP 不是“说明书”，它本质上是边界。

1. SOP 决定了系统能参考什么

如果一条流程的处理规则只存在于几个老员工的经验里，或者散在聊天记录、截图、Excel 备注和过时文档里，Agent 实际上没有稳定的依据。

这时候再强的模型，也只能在不稳定信息上做推断。它看起来像是在帮你工作，实际是在替混乱做加速。

所以我现在看知识准备度时，不会先问“有多少份文档”，而会问：

• 规则是否真的成文
• 版本是否清楚
• 例外情况是否被记录
• 谁对这份 SOP 的更新负责

2. SOP 决定了系统不能做什么

很多团队喜欢把 SOP 理解成“告诉系统该怎么做”。但从设计角度看，SOP 还有另一层更重要的作用：告诉系统哪里不能越界。

比如：

• 哪些字段只能建议、不能自动写回
• 哪些情况必须人工复核
• 哪些客户问题不能直接回复
• 哪些异常必须升级到上一级处理

这些边界如果不被明确写出来，Agent 越会推理，越容易在错误范围里“自信地工作”。

3. SOP 不是一次性整理，而是持续维护机制

很多企业愿意花一点时间把知识整理成一版文档，但真正困难的是后续维护。

如果没有版本管理、更新责任和例外沉淀，再好的知识库很快也会失效。系统刚上线时表现不错，几周后就开始漂移，最后大家得出结论：“AI 还是不稳定。”

其实很多时候，不稳定的不是 AI，而是它所依赖的知识来源。

4. 我越来越把知识重构看成 AI 项目的前置工程

以前很多团队会把知识整理当成“上线之前顺手做一点”。现在我更倾向把它看成正事，而且往往是最该先做的事。

如果想让 Agent 真正进入企业流程，至少要把这些东西慢慢建立起来：

• 一套清楚的 SOP 结构
• 例外情况的记录机制
• 可维护的知识入口
• 对边界和权限的明确描述

模型、工具、编排都很重要，但如果没有一套干净、可信、能持续维护的 SOP，Agent 的能力始终像悬在空中。

很多所谓“Agent 项目”，最后真正做成的不是一个聪明系统，而是一套更清楚的组织知识结构。我越来越觉得，这反而是更有价值的结果。