公司里的知识通常并不少。产品说明在网盘，销售话术在群聊，售后流程在表格，真正遇到问题时，大家还是先去问那个最熟悉业务的人。

文档与执行之间有一段空白

知识库解决了存放和搜索，但业务还需要判断。员工找到一份 SOP 后，会结合客户状态、自己的权限和现场情况决定下一步。Agent 如果只拿到文档，很容易把说明文字当成必须执行的命令，或在不合适的场景套用旧规则。

以电商上新为例。资料里可能写着标题规范、主图要求、渠道差异和审核流程。真正执行时，还要知道这是哪个市场、商品是否已有合规材料、谁能改价格、出现缺图时任务交给谁。文档没有写出的连接部分，往往靠人脑补齐。

可执行知识不是一堆更容易搜索的文字。它要能告诉系统：什么时候用，谁可以用，用完以后做什么。

先分清事实、规则和经验

把所有资料切成片段放进向量库，是常见做法，也最容易产生混乱。产品尺寸属于事实，折扣审批属于规则，过去某次活动的复盘属于经验。三者的更新频率和可信范围不同。

  • 事实数据应有明确来源和更新时间，例如商品属性、客户状态、库存和合同字段。
  • 业务规则要标注适用对象、负责人和版本，例如哪些折扣需要审批。
  • 操作经验可以帮助判断，但不能自动覆盖正式规则。
  • 内容示例用于参考表达，不应被误认为最新事实。

这种区分看起来麻烦，却能让 Agent 在冲突出现时知道应该信谁。它也方便团队发现：问题到底来自资料过期，还是流程本身没有规定。

把 SOP 写成可以运行的条件

传统 SOP 常按“第一步、第二步、第三步”编写。真实业务不会永远沿一条直线前进。客户资料不完整怎么办？负责人不在线怎么办？某个动作失败后重试几次？这些分支决定了流程能不能自动运行。

一份可执行 SOP 需要补上几类信息：

  1. 触发条件。 是收到新线索、库存变化，还是人工点击后启动。
  2. 输入要求。 哪些字段必须存在，缺失时由谁补齐。
  3. 动作与权限。 Agent 可以查询、生成或写入什么，哪里必须等待审批。
  4. 结束与异常。 什么算完成，失败如何回退，记录写到哪里。

到了这一步，知识才从“给人看的资料”变成任务运行时可以调用的资产。

不要把例外藏起来不少团队只整理标准流程，因为它最容易写。Agent 真正需要的，常常是异常分支：资料缺失、客户反悔、接口失败、审批超时。把这些情况写出来，系统才不会在最需要帮助时停住。

从旧资料开始整理，不必推倒重来

企业不需要先完成一次宏大的知识治理项目。可以选一项正在发生的任务，把实际使用的文档、表格、群聊记录和操作步骤收集起来。先确认哪些内容仍然有效，再补上负责人、适用范围和权限。

接下来，让 Agent 先做资料准备和步骤建议。团队运行几轮后，会很快发现缺少的字段和例外。等规则稳定，再开放内部写入或外部动作。每次人工修改都记录原因，用来更新知识或 SOP。

InFlow X 把知识条目、组织权限、流程节点和任务记录连在一起。Agent 使用哪条规则、调用哪份数据、在哪个节点等待人工确认，都可以回看。流程变更时，旧任务仍保留当时使用的版本，方便复盘。

企业知识的价值，不在于文件夹有多完整。有人或 Agent 面对具体任务时，能找到正确版本，并按权限把下一步做对，这份知识才真正进入了业务。