企业官网建设流程全解析

副标题：把制度、SOP、操作手册与培训视频"编译"成受治理、可验证、可执行的企业专属 Agent

摘要（TL;DR）

企业 AI 的下一阶段，不是"给每个部门配一个通用大模型助手"，而是建立一条编译链：

Knowledge（知道什么） → Procedure（怎么做） → Skill（能做什么） → Workflow（按什么顺序做） → Policy（允许做什么） → Agent（谁来做）

本文提出一套可落地的工程方法论，核心主张有三条：

1. 企业知识必须能力化分类，至少分为 Knowledge / Policy / Procedure / Skill / Tool / Workflow 六类，而不是全部塞进一个向量库；
2. 文档与视频是 Agent 的源码，需要经过"AI 提取 → 人工确认 → 系统执行"的编译阶段，绝不能由 LLM 一次性生成 Agent；
3. Agent 必须运行在能力笼子（Bounded Action Space）里——一句话概括整个设计哲学：

让 AI 的认知空间尽可能大，让 AI 的执行空间尽可能小。

0. 引子：一个 DHCP 故障引发的思考

设想一家有 300 台服务器的企业，运维小李接到报障："研发区拿不到 IP 了。"

• 传统知识库时代：小李打开 Confluence，搜"DHCP"，跳出 17 篇文档，其中 5 篇是 2019 年的。他花 20 分钟读完，自己敲 PowerShell 排查。
• RAG 问答时代：小李问 AI"DHCP 拿不到 IP 怎么办"，AI 返回一段漂亮的步骤说明，他照着做，但步骤来自 3 篇不同文档的混合，第 4 步的Restart-Service在生产环境其实是被禁止的——AI 不知道。
• Copilot 时代：AI 帮他生成脚本，他复制粘贴执行。脚本写错了 Scope 名，把半个办公网的租约清了。

问题不在于模型不够聪明，而在于企业缺少一层"执行语义"：

• 文档里写的"检查服务状态"，到底对应哪个确定的动作？
• "如果服务停止则启动"，在什么条件下被允许？需要谁审批？
• 这一整套排查顺序，是不是一个可复现、可测试、可回滚的流程？

当这些问题没有被显式建模时，LLM 只能在"文本空间"里自由发挥——这就是企业不敢放权的根因。

于是问题变成：能不能把企业的制度和经验，从"自然语言文档"编译成"受约束的可执行资产"？

1. 为什么"通用大模型 Agent"在企业里落不了地

1.1 可靠性缺口：从 90% 到 99.9% 的鸿沟

演示环境中，一个 Agent 做到 90% 的任务成功率已经足够惊艳。但企业生产环境要求的是另一个量级：

一个 8 步的 Workflow，如果每步成功率 99%，整体成功率只有92.3%；每个 Agent 每天跑 100 次，意味着每天 7.7 次失败。这就是为什么"天马行空"式的自由规划在企业里不可用——误差会随步数指数累积。

1.2 四类必须工程化解决的风险

1. 越权风险（Authorization）：LLM 不知道"你是谁、你能动什么"。它生成的Remove-Item和你给它的 RAG 文档毫无关系。
2. 不可逆风险（Irreversibility）：删除、格式化、停用账号这类操作没有 Undo。
3. 幻觉风险（Hallucination）：参数编造是最隐蔽的杀手——方法对了，但 Scope 名、服务器名、用户 ID 是模型"合理推测"出来的。
4. 不可审计风险（Auditability）：事后无法回答"为什么系统在那分钟做了这件事"，合规直接不通过。

1.3 企业真正要的是"可控的错误"

消费级 AI 追求惊艳的成功，企业级 AI 追求可控的失败。合格的失败应该是：

• 可预测：失败模式已知且在白名单内（超时、参数缺失、前置条件不满足），而不是"模型临时发明了一种新做法"；
• 可停止：任何一步都能被策略引擎拦下，而不是一路执行到底；
• 可解释：审计日志能还原"意图 → 策略判定 → 技能 → 工具 → 结果"的完整链路；
• 可恢复：有 dry-run、有回滚、有补偿动作。

一句话：企业不需要一个"什么都敢做"的 Agent，需要一个"明确知道自己不能做什么"的 Agent。

2. 范式转移：从 Knowledge Retrieval 到 Knowledge Compilation

2.1 传统链路 vs 编译链

传统企业 AI：

企业文档 → 知识库 → Embedding/RAG → LLM → 回答问题

本文主张的链路：

企业知识 ─┬─ 制度/Policy ─┐ ├─ 产品/技术知识 │ ├─ 操作手册/SOP ├→ Knowledge Engineering → 六类能力资产 ├─ FAQ / 工单历史 │ │ ├─ 培训视频 │ ▼ └─ 专家经验 ─┘ ┌──────────────────┐ │ Enterprise Agent │ └────────┬─────────┘ ┌────────────────┴────────────────┐ ▼ ▼ 查询型 Agent（L0/L1） 执行型 Agent（L2/L3） │ Bounded Action Space │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ API MCP Script

关键差异一句话概括：

RAG 解决"知道什么"，Agent 解决"怎么做"，Workflow/Tool 解决"允许做什么"。

2.2 与相邻概念的边界

最后一行的"覆盖面窄"不是 bug，是 feature：用有限覆盖面换取生产级可靠性，正是企业级产品的取舍。

3. 企业知识的能力化分类

3.1 六类资产

3.2 分类的工程判据：三问法

给一段知识做归类时，按顺序问三个问题：

Q1: 它能被系统确定性执行吗？ ├─ 否 → Q2: 它是在陈述事实，还是在划定边界？ │ ├─ 陈述事实 → Knowledge │ └─ 划定边界 → Policy └─ 是 → Q3: 它是单一动作，还是动作序列？ ├─ 单一动作 → Skill（映射到 Tool） └─ 动作序列 → Workflow（编排多个 Skill）

补充两条实践规则：

• 有副作用（side-effect）的知识必须下沉为 Skill，并在 Policy 中显式登记副作用等级；
• 条件分支归属 Workflow 而非 Skill：Skill 保持"单一、无分支、可单测"，分支逻辑放在 Workflow 层（便于可视化与测试）。

3.3 实例：一份 DHCP 手册的拆解

不要只把《Windows Server DHCP 故障处理手册》作为 PDF 丢进向量库，应解析为：

Knowledge: DHCP: - DHCP 租约生命周期（Discover/Offer/Request/Ack） - Scope 与 Superscope 概念 - Failover 模式（Hot Standby / Load Balance） Procedure: - id: proc.dhcp.troubleshooting name: DHCP 故障诊断 source: KB-2019-DHCP-01.pdf §3.2 version: v3 steps: [check_service, check_scope, check_failover, collect_logs, report] Skill: - check_dhcp_service # 只读 - check_dhcp_scope # 只读 - check_dhcp_failover # 只读 - collect_dhcp_logs # 只读 - start_dhcp_service # 副作用：中（需审批） - restart_dhcp_service # 副作用：高（生产禁用） Policy: - id: pol.prod.no_auto_restart rule: env == "production" AND action.side_effect_level >= 2 → require_approval - id: pol.scope.protect rule: action == "modify_scope" AND scope.tag == "critical" → deny - id: pol.log.retention rule: collect_logs.window_days <= 30 Workflow: - id: wf.dhcp.troubleshooting.v1 entry: user_request("DHCP 异常") steps: [...] sla: 120s rollback: none (只读为主)

到这里，这份文档才真正成为企业 AI 能力资产，而不是一堆 embedding。

4. 文档 → Procedure：抽取流水线

4.1 总体管线

原始文档（PDF/Word/HTML/Markdown/扫描件） │ ├─ ① 版面解析：标题层级、段落、表格、代码块、截图 → 结构化 JSON ├─ ② 语义切片：按"章节/步骤/决策点"切分（而非固定 token 窗口） ├─ ③ 步骤抽取（Step Extraction）：识别动作句 → 动作三元组 ├─ ④ 工具映射（Tool Mapping）：动作 → Skill/Tool Catalog 语义对齐 ├─ ⑤ 策略抽取（Policy Extraction）：识别禁止/必须/需审批语义 ├─ ⑥ 参数解析：抽取占位参数与来源（用户输入 / 上下文 / CMDB / 上一步输出） ├─ ⑦ 置信度打分 + 人工复核 → Canonical Procedure └─ ⑧ 版本化入库（Git），生成 Workflow/Skill 草稿

4.2 步骤抽取的真实难点

文档不会乖乖地写成伪代码。工程上要处理六类情况：

一条实践准则：抽取器输出的不是最终流程，而是带置信度的 Draft；任何置信度低于阈值（建议 0.85）或命中"高风险动作词"的节点，必须进入人工队列。

4.3 工具映射：从"动词短语"到"可调用能力"

动作句检查 DHCP 服务状态需要落到check_dhcp_service这个 Skill。工程上分三步：

1. 召回：用动作短语 + 领域标签在 Skill Catalog 中做向量召回（Top-10）；
2. 结构对齐：比较抽取出的参数集合与 Skill 的 JSON Schema，参数不匹配则淘汰；
3. 人工/规则确认：高风险 Skill 强制人工确认，低风险只读 Skill 可自动绑定。

关键设计：Skill Catalog 必须先于文档抽取存在（哪怕只有 30 个）。没有目标能力清单，"动作映射"就退化成"让 LLM 自由发明工具"，风险回到原点。

4.4 策略抽取

文档中散布着约束语义，需要专门识别并结构化，常见触发模式：

策略抽取必须保守：召回率可以低，误报可以人工剔除，但漏掉一条 deny 规则就是一次生产事故。因此这里宁可"疑似即上报"。

5. 视频：被严重低估的 Agent 矿藏

5.1 为什么视频比文档更有价值

企业里大量关键知识从未被写成文档：老专家的操作习惯、排障时的直觉顺序、系统的隐藏坑位。它们存在于培训录像、屏幕录制、远程运维录屏中。RAG 对这些内容几乎无能为力，因为它们没有可检索的文本。

5.2 多模态抽取管线

视频（30min 培训录像） │ ├─ ASR（语音转写） → 带时间戳的口播文本 ├─ 关键帧抽取 + OCR → 界面文字、命令行、报错信息 ├─ 视觉理解（VLM） → "正在打开服务管理器"、"点击了重启" ├─ 屏幕动作识别 → 鼠标点击/键盘输入/窗口切换事件 │ ▼ 多轨时间轴对齐（ASR ⊕ OCR ⊕ Vision） │ ▼ Action Timeline（动作时间线） 00:03:20 打开服务管理器 → 检查 Mail Submission 服务 00:05:10 打开 Queue Viewer → 查看队列堆积 00:08:30 挂载数据库状态检查 00:12:40 检查磁盘剩余空间 00:16:20 测试 Mail Flow 00:22:00 重启 MSExchangeTransport 00:25:30 查看 EventLog │ ├─ 动作归并（去重、合并同类项） ├─ 顺序规范化（省略闲聊/等待/口误） ├─ 参数泛化（把录屏里的具体主机名 → 参数占位符） ▼ Skill 候选 + Workflow 候选 → 人工确认 → 入库

5.3 三个必须处理的噪声

1. 演示环境噪声：视频里操作的是EXCH-TEST-01，直接抽取会污染生产流程。必须做实体泛化：把具体主机/邮箱/用户名替换为{{target_server}}等占位参数。
2. 口误与回退：专家常说"哦不对，应该是先查这个"。抽取时要识别"撤销/回退"语义，丢弃被否定的动作段。
3. 跳步：专家凭肌肉记忆跳过了"登录"等步骤。用领域本体做前置步骤补全（与 4.2 的隐式步骤同一机制）。

5.4 商业模式意义

企业专家做一次培训 → AI 把培训变成企业 Agent。

这让知识沉淀从"专家愿意不愿意写文档"变成一个被动发生的副产品，也回应了第 11 节讨论的"知识资产化"问题。

6. 编译阶段：AI 提取、人确认、系统执行

6.1 绝不能"文档 → LLM → Agent"

跳过人工确认的直接生成，等价于让模型同时充当"需求工程师 + 开发 + 测试 + 安全审计"。正确链路：

Document / Video ↓ AI Extraction（Draft，带置信度与来源定位） ↓ Human Validation（领域专家 + 安全合规双签） ↓ Canonical Procedure（唯一权威版本，Git 托管） ↓ Skill / Workflow（可执行资产，带测试） ↓ Agent（绑定模型、Policy、触发条件、SLA）

AI 负责提取，人负责确认，系统负责执行。

6.2 Agent as Code

把 Agent 当作软件工程制品管理，建议目录结构：

agents/ it/ dhcp-troubleshooting/ agent.yaml # 名称、触发条件、绑定模型、等级(L2)、SLA workflow.yaml # 步骤、条件分支、错误处理、补偿 skills/ check_dhcp_service.yaml start_dhcp_service.yaml policy/ prod_guard.yaml tests/ skill_unit/ # Skill 级单测（含 mock） workflow_replay/ # 录制回放（基于真实历史工单） e2e/ # 端到端评测集 CHANGELOG.md

收益：Code Review、CI 门禁、版本回滚、灰度发布、责任可追溯——这些软件工程的成熟实践可以原样复用。

6.3 三层测试门禁

任何一层不过，禁止发布，也禁止从 L1 升级到 L2。

6.4 发布与灰度

• Shadow 模式：只推理不执行，对比 Agent 决策与人工实际处置的一致性；
• L1（引导）先行：只给步骤不执行，收集用户反馈；
• L2（受限执行）灰度：先在非生产环境，再在生产只读，最后开放带副作用动作；
• 自动降级：连续 N 次失败或人工接管率超阈值，自动回退到 L1。

7. Bounded Agent：给能力装上笼子

7.1 核心结构

Agent │ ┌───────────┴───────────┐ │ │ Reasoning Execution （可以想） （必须受限） │ │ LLM 判断 ┌──────┴──────┐ │ │ Skills Tools │ │ ▼ ▼ Workflow API/MCP │ ▼ Policy Engine ───→ Allow / Deny / RequireApproval │ ▼ Allowed Actions

LLM 可以"想"，但不能直接执行它想出来的东西。执行链必须走完：

Intent → Policy → Skill → Tool → Permission → Execution

7.2 白名单优于黑名单

错误做法（黑名单）：

deny: [Format-Disk, Remove-Item, Delete-User, Disable-ADAccount]

问题：系统的命令空间是开放的，黑名单永远列不全；模型换个等价命令（如Get-ChildItem | Remove-Item或 PowerShell 别名rm）就绕过了。

正确做法（白名单 + 类型化）：

allowed_action_space: server: srv-prod-* verbs: [Get-Service, Get-EventLog, Get-Disk, Get-Process, Get-NetAdapter] mutating_verbs: [Restart-Service] # 显式列出可变动作 mutating_policy: require_approval # 且必须审批 param_constraints: Restart-Service: -Name: {enum: [DHCPServer, DNS, Spooler]} # 参数枚举，禁止自由文本 rate_limit: 10/hour timeout: 30s

设计要点：动词白名单 + 参数枚举/正则 + 目标范围 + 频率限制 + 超时，五要素缺一不可。

7.3 副作用分级与审批矩阵

7.4 执行时的六道保险

1. 前置校验（Precondition）：目标是否存活、权限是否满足、是否在维护窗口；
2. Dry-run：L2 及以上动作先做 dry-run，返回"将要发生什么"；
3. 幂等设计：同一请求重复执行结果一致（用 idempotency key）；
4. 超时与熔断：单步超时、全局 SLA、连续失败熔断；
5. 补偿/回滚：每个有副作用的 Skill 必须声明rollback（无回滚能力的 Skill 一律禁止在生产启用）；
6. 审计留痕：意图原文、命中的 Skill、Policy 判定结果、参数、执行前后状态快照、操作者身份，全链路入审计库（建议接入 LLM 观测平台做 trace 留存）。

8. Skill 与 Tool 的工程契约

8.1 Skill 定义示例

apiVersion: agent.mimir/v1 kind: Skill metadata: id: skill.it.dhcp.start_service name: start_dhcp_service version: 1.2.0 owner: it-ops@example.com domain: IT/DHCP spec: display_name: 启动 DHCP 服务 description: 在指定 Windows Server 上启动 DHCPServer 服务 intent_examples: - "把 DHCP 服务拉起来" - "启动 srv-dhcp-01 的 DHCP 服务" side_effect_level: 2 # 见 7.3 分级 idempotent: true timeout: 30s params: server: type: string required: true source: [user_input, cmdb.dhcp_servers] # 参数只能来自这些来源 pattern: "^srv-(dhcp|dns)-[0-9]{2}$" preconditions: - skill: check_dhcp_service expect: service.status == "stopped" implementation: type: mcp server: windows-admin tool: Restart-Service arg_mapping: {ComputerName: "{{params.server}}", Name: "DHCPServer"} postconditions: - skill: check_dhcp_service expect: service.status == "running" rollback: skill: stop_dhcp_service note: 仅在服务原本处于 stopped 时回滚 audit: level: full retain: 365d tests: - name: happy_path mock: {service.status: stopped} expect: {exit: success, postcondition: true}

几个关键设计：

• source约束参数来源：这是防止幻觉参数的核心手段。参数只能来自用户输入、CMDB、上下文或上一步输出，模型不能凭空生成；
• 前置/后置条件即断言：把"检查"变成可执行的断言，而非自然语言的描述；
• 回滚是强制项：没有 rollback 的 Skill 不允许在生产启用。

8.2 Tool 适配层

Tool 是"系统能力的原始接口"（API / MCP / Script），Skill 是"带语义、带约束的能力封装"。二者的分工：

原则：LLM 永远看不到 Tool，只能看到 Skill。这是一条硬边界，也是整个安全模型的地基。

9. 分级自治：L0 → L3 与升级闸门

升级闸门（Gate）不是流程形式主义，而是可量化的准入指标：

L0 → L1：知识覆盖率 ≥ 90%，引用准确率 ≥ 98%，幻觉率 ≤ 1% L1 → L2：Workflow 回放成功率 ≥ 99%，参数准确率 ≥ 99.5%， 越权拦截率 = 100%，回滚覆盖率 = 100%，审计覆盖率 = 100% L2 → L3：验证闭环覆盖率 ≥ 95%，人工接管率 ≤ 5%， 连续 30 天无 P2 及以上事故，熔断演练通过

注意 L3不等于放开约束——自主规划的空间依然被 Policy 和 Allowed Action Space 限制，只是允许它在笼子内自己排列组合。

10. 三平面架构

┌──────────────────────────────────────────────────────────────┐ │ Enterprise AI Portal │ │ Chat │ Agents │ Knowledge │ Skills │ Automation │ Admin │ └───────────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Knowledge Plane（知识平面） │ │ 文档 / Wiki / 视频 / 工单 / 专家经验 │ │ → 解析 → 六类资产 → RAG / 知识图谱 / Skill Catalog │ └───────────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Intelligence Plane（智能平面） │ │ LLM / 意图识别 / 参数收集 / 规划 / 反思 │ │ 职责：理解、判断、选择 —— 不直接执行 │ └───────────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Execution Plane（执行平面） │ │ Workflow 编排 │ Skill 运行时 │ MCP/API/Script │ │ Policy Engine │ RBAC │ 审批 │ 审计 │ 回滚 │ 限流 │ └──────────────────────────────────────────────────────────────┘

三个平面各有独立的可观测性要求：

• Knowledge Plane：资产覆盖率、抽取置信度分布、人工复核吞吐；
• Intelligence Plane：意图识别准确率、参数抽取准确率、Token 成本、延迟——这一层应接入 LLM 观测/评估平台（如 Langfuse 类工具）做 trace 级记录与回归评测；
• Execution Plane：任务成功率、越权拦截次数、审批时长、回滚次数、MTTR。

这比"企业 Agent = LLM + RAG + MCP"的说法严谨得多：RAG 只是知识平面的一部分，MCP 只是执行平面的一种适配方式，而真正决定成败的是中间的编译链与策略引擎。

11. 可靠性工程：如何把"小范围"做成"高可靠"

11.1 指标体系

11.2 Golden Dataset 与回归

每个 Agent 维护 ≥50 条评测样本（建议从历史工单脱敏生成），结构：

{ "id": "case-0017", "utterance": "研发区 3 楼拿不到 IP 了", "expected_intent": "wf.dhcp.troubleshooting.v1", "expected_params": {"scope": "Floor3-RD", "env": "production"}, "expected_outcome": "report_generated", "must_not_call": ["restart_dhcp_service", "modify_scope"], "tags": ["prod", "read-only-path"] }

任何 Skill/Workflow/Policy/Prompt 变更都必须跑全量回归，不过即阻断发布。这是防止"改了一句话，炸了一片流程"的唯一有效办法。

11.3 失败模式库与降级

建立已知失败模式的显式处理（不要让 LLM 临场发挥）：

11.4 成本与延迟

小范围不只是为了安全，也为了成本可控：

• 确定性优先：能由 Workflow 决定的分支不要用 LLM 判断（省 token、省延迟、可预测）；
• 分层模型：意图识别/参数抽取用小模型，复杂推理/报告生成用大模型；
• 缓存：Skill 结果与知识检索结果分级缓存（只读类可缓存 60–300s）。

12. 组织与治理：Agent Factory 需要哪些角色

一个常见失败模式：把 Agent 生产当成 IT 项目，只由平台工程团队负责。实际上它更像一条"知识生产线"，领域专家的投入占比应在 40% 以上。

13. 常见误区

1. 误区：先建大而全的知识库，再谈 Agent。正解：先建Skill Catalog 与 Policy，它们是抽取的"目标坐标系"。没有坐标系，再多的文档也只是一堆 embedding。

2. 误区：让 LLM 在运行时自由规划步骤。正解：规划应该在编译时（人工确认过的 Workflow）完成，运行时的 LLM 只负责"选择哪个 Workflow、填哪些参数"。

3. 误区：Policy 写成 Prompt 里的一句话。正解：Policy 必须是运行时的硬拦截（代码级），Prompt 约束只是软约束，可被绕过。

4. 误区：追求 Agent 的通用性。正解：企业级价值来自专用性。一个只做 DHCP 排查但成功率 99.9% 的 Agent，比一个什么都会但成功率 92% 的 Agent 有价值得多。

5. 误区：上线即结束。正解：Agent 是活的资产——系统接口变了、制度更新了、组织架构调整了，它都要跟着变。必须有版本、回归、弃用机制。

14. 一个可复用的公式

Enterprise Agent = Knowledge（What） + Procedure（How） + Skill（Can do） + Tool（Actually execute） + Policy（May / May not） + Workflow（In what order） + LLM（Understand / Reason / Select）

值得注意的是，在这个公式里LLM 不再是中心，它只是企业执行系统中的智能决策组件：负责理解、判断、选择，不负责发明执行方式。

于是整个产品的核心竞争力，也从"谁的 RAG Top-K 更准"，转向一个更高维的指标：

企业知识转化为可执行 Agent 的效率、可靠性与治理能力。

15. 结语

回到开头那句设计原则：

大模型 ┌──────────────┐ │ 可以思考 │ │ 可以判断 │ │ 可以理解 │ │ 可以规划 │ └──────┬───────┘ │ 受到约束 ▼ ┌───────────────────┐ │ Enterprise Policy │ └─────────┬─────────┘ ▼ Allowed Skills ▼ Allowed Tools ▼ Allowed Operations

让 AI 的认知空间尽可能大，让 AI 的执行空间尽可能小。

企业 AI 的终局，不是让模型替人类做决定，而是把人类已经想清楚的事情——制度、SOP、专家经验——编译成机器可以稳定复现的能力。模型的智能用于理解人与应对变化，而可靠性由工程体系来保证。

这条路不性感，但它能把 AI 从"演示视频"推进到"生产系统"。