很多企业搭AI Agent，上来就踩同一个坑：
给Agent接了一堆工具，塞了一堆文档，结果呢？
本质原因就两个：
今天给你一套稳定可落地的组合架构：SOP管行为，Wiki管知识，Agent在中间执行。
行为有标准，知识有沉淀，结果可预期。
这才是企业级Agent该有的样子。

一、为什么企业级Agent需要"SOP + Wiki"双轮驱动

先拆解两个核心痛点。

痛点一：Agent行为不可控，全靠"运气"

没有SOP约束的Agent，就像一个没经过培训的新员工：

• 同样的任务，这次这么干，下次那么干

• 遇到边界情况，全靠模型自己瞎猜

• 出了问题，不知道是哪一步出的错

企业场景最忌讳"不可预测"。你能接受客服Agent每次回复口径不一样吗？你能接受运维Agent每次排障流程随心所欲吗？

不能。所以需要SOP——标准作业程序，把Agent的行为框在确定性的流程里。

痛点二：RAG检索不稳定，知识"现用现找"质量差

传统RAG的问题我们上一篇讲过：每次查询都从原始文档里现搜现拼，碎片化、噪音大、不一致。

企业知识不是零散的文档堆，而是有结构、有关联、有版本的体系。

• 业务规则之间有依赖关系

• 操作流程有先后顺序

• 政策规范有版本更新

这些东西靠向量检索是搜不出来的，需要一个已经编译好的结构化知识层——这就是LLM-Wiki的角色。

组合起来：三层架构

分工明确：

• SOP：定义流程，确保行为一致

• Agent：执行任务，负责推理和工具调用

• Wiki：提供知识，确保答案有依据

二、SOP层：给Agent定规矩

什么是SOP驱动的Agent？

不是让AI自由发挥，而是给它一套标准作业流程，它按照流程一步步走。

对比一下：

模式	工作方式	结果稳定性	适用场景
自由模式	AI 自己想怎么干就怎么干	低，每次可能不一样	创意类、探索类任务
SOP 驱动	严格按照预设流程执行	高，每次结果一致	企业业务、客服、运维

SOP长什么样？

不是代码写死的工作流，而是用自然语言写的"剧本"+ 结构化元数据。

一份标准SOP包含四个部分：

sop_id: customer_service_refund
name: 客服退款处理流程
version: 1.2
owner: 客服部
updated: 2026-07-15
 
script: |
 你是客服退款处理专员，请严格按照以下流程处理：

 第一步：信息核验
 - 核对用户订单号、购买时间、退款原因
 - 查询订单状态，确认是否符合退款条件
 - 条件判断：
 * 未发货 → 直接进入退款流程
 * 已发货未签收 → 建议拒收后申请
 * 已签收 → 进入退货退款流程

 第二步：规则匹配
 - 查阅退款政策Wiki，确认退款时效、手续费规则
 - 判断是否属于特殊情况（VIP、质量问题等）

 第三步：执行操作
 - 符合条件：发起退款，告知用户到账时间
 - 不符合：说明原因，给出替代方案
 - 无法判断：转人工，附带已核实信息
 
redlines:
 - 绝对不允许承诺不在政策范围内的退款
 - 所有操作必须留痕，写入工单系统
 - 涉及金额超过500元必须人工复核
 
fallback: 遇到流程未覆盖的情况，不要自行判断，直接转人工并说明原因

SOP驱动的工作原理

Agent收到任务后：

1. 匹配 SOP：根据任务类型找到对应的标准流程
2. 逐行执行：按照 SOP 规定的步骤一步步来
3. 条件判断：遇到分支，严格按规则走，不自由发挥
4. 调用 Wiki：需要查规则、查政策，去 Wiki 里找标准答案
5. 异常兜底：SOP 没覆盖的情况，触发 fallback 转人工

关键价值：同样的输入，永远得到同样的输出。这才是企业敢用的AI。

三、LLM-Wiki层：给Agent装"大脑"

Wiki在这套架构里的角色

SOP规定了"怎么走流程"，但流程里每一步"依据什么判断"，靠的是Wiki。

比如退款SOP里的"查阅退款政策"——不是去翻几十页原始文档，而是直接读Wiki里已经整理好的结构化词条。

用户问：我买了15天了还能退吗？
 
Agent执行SOP → 第二步规则匹配 → 查询Wiki词条「退款时效政策」
→ 得到标准答案：普通商品7天无理由，质量问题30天可退
→ 按照SOP逻辑给出回复

Wiki的三层知识结构

LLM-Wiki/
├── 政策规则类/
 
# 硬规则，必须严格遵守
│ ├── 退款政策.md
│ ├── 会员权益.md
│ └── 售后服务规范.md
├── 业务流程类/
 
# 操作指引，SOP的补充说明
│ ├── 退货流程.md
│ ├── 发票开具.md
│ └── 异常处理.md
└── FAQ类/
 
# 常见问题，快速应答
 ├── 退款多久到账.md
 └── 可以退部分商品吗.md

和RAG的本质区别

维度	传统 RAG	LLM-Wiki（知识底座）
知识形态	原始文档碎片	结构化编译后的标准词条
查询方式	向量相似度匹配，可能不准	按词条导航，精确读取
一致性	每次可能拼出不同答案	同一问题同一词条，答案一致
更新方式	塞新文档就行	走 Ingest 流程审核入库
适合场景	海量非结构化文档检索	标准化业务知识、规则、SOP

企业Agent的核心知识（政策、规则、流程）必须走Wiki，不能靠RAG瞎搜。这是结果可预期的基础。

四、三层联动：一个完整的执行示例

说太抽象，看一个真实的客服退款场景，三层怎么配合：

用户提问："我上周买的耳机有点质量问题，想退，怎么弄？"

执行全过程：

【第1步：SOP匹配】
Agent识别任务类型 → 匹配到「客服退款处理流程」SOP v1.2
→ 加载SOP剧本，进入执行模式
 
【第2步：信息核验（SOP第一步）】
Agent：您好，请提供一下订单号，我帮您核实~
用户：ORD20260720001
Agent查询订单系统 → 订单状态：已签收，购买7天
 
【第3步：规则匹配（SOP第二步）】
SOP要求：查阅退款政策Wiki
Agent导航到Wiki → 「退款时效政策」词条：
 - 普通商品：7天无理由退款
 - 质量问题：30天内可申请退货退款
→ 判断：质量问题场景，符合退款条件
 
继续查Wiki → 「质量问题退货流程」词条：
 - 用户需提供问题照片
 - 审核通过后寄回商品
 - 收到后3个工作日内退款
 
【第4步：执行操作（SOP第三步）】
Agent按照SOP和Wiki知识，给出标准回复：
”您好，核实到您的订单购买7天，属于质量问题可申请退货退款。
请提供一下耳机质量问题的照片，审核通过后我会给您发送退货地址，
收到退回商品后3个工作日内为您退款。”
 
【第5步：留痕记录】
自动写入工单系统：
- 触发SOP：customer_service_refund v1.2
- 调用Wiki词条：退款时效政策、质量问题退货流程
- 处理结果：符合条件，待用户提供照片

整个过程：

• 行为严格遵循SOP，不会跳步不会乱答

• 知识全部来自Wiki，口径统一有依据

• 每一步都可追溯，出了问题能定位

五、落地实施：从0到1的四步走

这套架构听起来复杂，其实可以分步落地，不用一步到位。

第一步：先选一个场景，定义1份SOP + 20个Wiki词条

不要上来就想覆盖全公司。找一个边界清晰、重复度高的场景：

• 客服：售后退款/咨询

• 运维：故障排查标准流程

• HR：入职/离职手续

• IT：常见问题处理

MVP标准：1份核心SOP + 20个左右的Wiki词条，能覆盖80%的常见问题。

第二步：搭建LLM-Wiki知识库

按照上一篇讲的Ingest SOP，把这个场景的政策文档、操作手册、FAQ整理编译成结构化Wiki词条。

关键：第一批词条一定要人工审核，确保准确。这是地基，歪了后面全歪。

第三步：开发SOP驱动的Agent

不用搞复杂的框架，核心就是一个prompt模板：

​​​​​​​
你是XX岗位的AI助手，请严格遵循以下SOP执行任务：
 
【SOP内容】
（把写好的标准流程贴在这里）
 
【知识来源】
所有业务规则、政策、流程请以Wiki知识库为准，不要自行编造。
查询方式：先读index.md找到对应词条，再读取具体内容。
 
【兜底规则】
遇到SOP和Wiki都没覆盖的情况，直接转人工，不要自行判断。

配上工具调用（查订单、开工单等），基础版就跑起来了。

第四步：建立迭代机制

上线不是结束，是开始。建立两套循环：

1. 知识迭代：每次遇到 Wiki 答不上来的问题，人工补充后走 Ingest 入库
2. 流程迭代：每次遇到 SOP 没覆盖的场景，评审后更新 SOP 版本

Agent的能力就是这样一点点长出来的，不是一蹴而就的。

六、企业落地的5个关键设计

1. SOP版本管理，和代码一样严谨

SOP就是Agent的"业务代码"，必须有版本管理：

• 每个SOP有版本号、负责人、更新时间

• 修改走评审流程，不能随便改

• 上线有灰度，出问题能回滚

建议：把SOP存在Git里，和代码一样走MR/CR流程。

2. Wiki分级管控，不同知识不同审核级别

不是所有知识的风险等级都一样：

• 一级（硬规则）：财务、合规、法律相关 → 必须双人审核
• 二级（业务规则）：政策、流程、标准 → 部门负责人审核
• 三级（FAQ）：常见问题、经验总结 → 单人审核即可

3. 全链路可追溯，每一步都要留痕

Agent的每一次执行都要记录：

• 触发了哪个SOP，哪个版本

• 调用了哪些Wiki词条

• 执行了哪些操作，结果是什么

• 中间做了哪些判断，依据是什么

企业级系统，可追溯性比"聪明"重要得多。

4. 兜底机制是底线，AI不能处理的坚决转人工

不要追求100%自动化。SOP和Wiki覆盖不了的场景，宁可转人工，也不能让AI硬答。

硬答一次出错，毁掉的是用户对整个系统的信任。80%场景自动化，20%复杂场景转人工，这是健康的比例。

5. 从辅助开始，逐步放权

落地节奏建议：

• 第一阶段：Agent只做"建议"，人工确认后再执行

• 第二阶段：低风险场景放开自动执行，高风险仍需确认

• 第三阶段：稳定运行后，逐步扩大自动执行范围

稳比快重要。企业级系统，跑半年不出错，比三天两头出故障强一万倍。

现阶段企业级AI的核心诉求，不是"更聪明"，而是"更稳定、更可控、更可预期"。

SOP + Wiki + Agent这套架构，就是在"智能"和"可控"之间找了一个很好的平衡点：

• SOP保证行为一致

• Wiki保证知识准确

• Agent负责灵活执行

AI不是来替代流程的，而是来把流程跑得更快、更稳、成本更低。

先有标准，再有智能；先有沉淀，再有进化。

喜欢动手的小伙伴赶紧试试吧！

---

高国生成式 —— 用 AI 兜底，做人游刃有余。