常见问题与场景说明

分三层理解，别混在一起：

• 平台引擎（内置，研发做一次）：Agent.run 主循环、ContextAssembler 组装逻辑、ToolGate 调用协议、Trace 审计——不写运维业务 Prompt。
• 场景 Pack（咨询交付 + 可版本化）：放在 packs/ops/ 等目录，含 reasoning_contract.yaml（必查项、工具白名单、最大步数）、系统/角色 Prompt 模板、输出 JSON 模板、可选 playbook YAML。
• 运行时上下文（自动组装）：告警 JSON、GraphRAG 子图、指标摘要、变更单、向量 RAG 片段（运维知识文档/case）——由 ContextAssembler 双路检索灌入，不是把 CMDB 全文贴进 Prompt。

演示里 LLM 决定「先查 get_alert 再 trace_ci 再 list_changes」——这是模型在 Pack 约束下的自主规划；OPA 规程、HITL 闸门则不走 Prompt，用规则与人工审批硬拦。

两者都有，职责不同：

• 咨询/交付阶段：与客户工作坊共建 ops-pack——本体类表、规程 R01～Rn、映射、协议 YAML、评测 case、场景 Prompt 模板。这是首批 Pack 内容。
• 系统内置：Pack 安装机制、版本管理、评审门禁、Admin UI 编辑与发布——换 Prompt 必须过评测，避免「改一句就全崩」。
• 上线后谁改：客户运维架构师 / 平台管理员可在 Admin UI 或 Git 管理 Pack 版本；不是让每个值班员在聊天框里随意改系统 Prompt。值班员做的是HITL 审批、补证据、驳回危险建议。

不是从零重写一套平台，而是每个场景一个 Pack 增量：

• 共用同一套 Agent.run 引擎、ToolGate、Harness、图谱与 Scope 模型；
• RCA、巡检、变更评审、容量评估等，各加载不同 Pack（工具集 + 推理契约 + 输出模板 + 评测 case）；
• 通用部分（角色设定、对象 ID 必填、审计格式）可跨 Pack 复用；差异在「本场景必查什么、能调哪些工具、交付物长什么样」。

本演示是 DIAG-PAY-GW-RCA 场景包示例，不代表平台只有 RCA——十域场景共用同一推理主循环，换 Pack 即可扩展。

大模型在 Pack 边界内自动完成。例如演示中 LLM#1 规划三只读工具、LLM#2 发现置信不足后自动追加 query_metrics——这些不需要你在 Prompt 里逐步写死「第 3 步查指标」。

你（或咨询交付）要写的是护栏，不是剧本：

• 工具白名单：本场景只能调 get_alert / trace_ci / list_changes / query_metrics 等；
• 必查项：例如 RCA 必须落到 CI ID、变更单 ID；
• 步数上限与退出条件：防止无限循环；
• 可选 playbook：给 LLM 参考的建议顺序（冷启动 / smoke test），非唯一主路径。

HITL（Human-in-the-Loop）= 人工在环审批。当智能体建议「重启 pay-lb-01」等写操作时，OPA 先拦自动通道，系统生成审批工单，值班长人工批准或驳回后 ToolGate 才执行。

它与提示词无关——是 Harness 的治理闸门，保证「敢让 AI 真办事」的同时，危险动作必须有人签字。演示 C4/C5 步即 HITL 环节。Harness 全貌见 下题。

两层含义，不要混为一谈：

• 概念层 · 驾驭层：把 LLM 推理、工具调用、规程、人工审批、评测、审计 串成可回放的生产流水线——对外即 可查、可拦、可评、有序办事（§01 四块拼图第四块）；
• 实现层 · 平台组件：落地代号 AgentHarness（§02 L2），不是一个叫 Harness 的开源安装包，而是 自研编排壳 + 成熟开源底座集成。

一、在架构图 / 演示里主要体现在哪？

位置	组件	Harness 职责
§02 · L2	AgentHarness	主载体：Pack 协议 YAML → Temporal Workflow；编排 Agent.run ↔ ToolGate；触发 OPA / HITL / Eval
§02 · L3	Temporal	Harness 运行时：长流程、等人批、断点续跑、重试（不自造第二套工作流引擎）
§02 · L2	ToolGate	Harness 规定的 唯一手脚：工具白名单、Scope、MCP/gRPC、写操作闸门
§02 · L2	OPA	Harness 规程闸门：Pack R01～Rn，维护窗口等不走 Prompt
§02 · L2/L5	HITL · PostgreSQL	Harness 人工闸门（§03 演示 C4/C5）
§02 · L5	ClickHouse	Harness 可查：全链路 Trace 回放
§02 · L6	ops-pack protocols/ · eval/	Harness 可配置面：诊断协议、reasoning_contract、评测门禁
§03	ALERT-991 全链路	整条演示 = 一条 Harness 流水线（非仅 PPT 名词）

主控制流里位置固定：AccessGW → AgentHarness → AgentSvc 推理 ↔ ToolGate → OPA / HITL（见 §02 顶部控制流）。

二、是自创规范、最佳实践，还是开源？

来源	说明
业界分层语言	LangChain：Agent = Model + Harness（tools、orchestration、state、middleware）— 见 12 §4.2
业界分层语言	Salesforce Agent Harness：包裹模型的基础设施（生命周期、工具、安全边界），不是「大脑」— 与咱们 AgentHarness 命名一致
团队架构共识	四块拼图：本体管规则 · 图谱管事实 · Agent 负责用 · Harness 管治理与稳定跑（03/15）
可参考形态	OpenClaw / yeasy 类：通用 Gateway + Harness 运行时思路；我们补 运维语义 + Pack + 图谱（04/07）
开源底座（栈）	Temporal 编排 · OPA 规程 · Kafka 削峰 · ClickHouse 审计 · MCP 工具暴露 — 见 11
自研粘合层	AgentHarness：Pack YAML → Workflow、与 AgentSvc/ToolGate/OPA/HITL/EvalRunner 集成；运维 Connector、Scope、评测发布门禁

OASHP 英文名 Ops Agent Semantic & Harness Platform，直译即「语义 + 驾驭（Harness）中台」。

三、怎么实现？（技术栈诚实口径）

• 编排：Temporal 1.24+ 集群 + Python/Go Worker；Pack 内 protocols/*.yaml 编译为 Workflow 定义；
• 推理挂接：Harness 编排 Agent.run 多轮循环（AgentSvc 无状态），不是写死「三步脚本」；
• 治理：每步前后 OPA 校验；写操作 OPA 拦自动通道 → HITL → 批准后才调 ToolGate 写工具；
• 可评：EvalRunner 加载 Pack eval/ case，发布门禁（如 RCA ≥80%）；
• 可查：每步 LLM/工具/审批写入 ClickHouse，Admin UI 回放。

四、客户常见观点：「Harness 只是工程规范，符合理念就行，没技术难点」——对一半

说得对的	需要校正的
Harness 首先是理念：有序执行、工具边界、规程、审批、审计、评测 — 不能只靠 Prompt	不等于「理念对齐了，实现零成本」
换模型、换入口，办事契约应稳定	长事务 + HITL 等待 + 多源 Connector + Scope + 评测 + 与 LLM 自主规划 耦合 — 集成与交付复杂度不低
甲方也可部分自建（工作流 + 审批 + API 网关）	我们卖的是 运维语义层 + 已贯通的 Harness 栈 + Pack 交付物；14 口径：组件成熟，难在交付与数据质量，不在「想明白要可查可拦可评」

五、15 秒对外答法

「Harness 不是聊天功能，是 驾驭层：把 AI 推理、查数、办事、审批、留痕串成 可回放流水线。实现上是 AgentHarness，下面用开源 Temporal 编排，规程用 OPA，工具走 ToolGate，和 LangChain、Salesforce 说的 Model+Harness 是同一类分层。」

深度对照见 12-AI智能体五要素与Agentic平台辨析.md · 03 §六 AgentHarness · 点击 §02 AgentHarness 看右侧详情。

有记忆，但主路径不是「把聊天记录存向量库」。运维 Agent 更需要对象 ID + 依赖链 + 任务留痕：

记忆类型	内容	组件
长期·图	CI/服务拓扑、依赖边	Neo4j
长期·文档	运维知识文档、复盘、制度全文、相似 case	VectorStore · ops-pack/knowledge
长期·制度	规程、归一词典	ops-pack · OPA
短期	子图 + RAG 片段 + 工具返回	ContextAssembler
任务态	诊断走到哪步、等人批、可续跑	Temporal · workflow_id
会话	用户追问绑在同一单	Redis session_id → workflow_id
审计	每步可查可回放	ClickHouse Trace

AgentSvc 标注「无状态」是指推理进程不长期 hoard 对话，不等于平台没记忆。§03 的 B1「组装上下文」是任务内记忆，不是微信式聊天记忆。

目标架构里有，在 L5 VectorStore（Qdrant / pgvector），与 Neo4j 并列，不是替代关系。

能力	Neo4j 图	向量库
多跳根因 ALERT→CI→变更	主路径	不适合
运维知识文档/SOP/复盘相似检索	不适合	主路径
Knowledge-Assist 制度问答	对象关联	长文召回

消费方都是 L2 ContextAssembler：GraphRAG + 运维知识文档/case RAG 双路合并。也可不经自建向量库，ToolGate 调客户外接 KB 检索 API。

入库：L4 KnowledgeIndexer 把 ops-pack knowledge/ 或 Connector 文档切片写入 VectorStore。

在 AgentSvc 的「任务理解与意图路由」（架构 §02 已标出），不是另一个聊天机器人外壳：

• 事件入口：告警 Webhook 自带场景（如 RCA），AccessGW 直接匹配 Pack 协议；
• 对话入口：POST /v1/chat → LLM + Pack 场景表判断意图（RCA / 巡检 / 查拓扑 / 续跑上一单）；
• 输出：场景 ID + Harness 协议 YAML + 工具白名单，然后进入 Agent.run。

§03 演示走告警自动触发，所以看不到「用户打字」那一步；对话路径与告警路径在 AccessGW 汇合，后面同一套大脑。

结论先行（对齐 09-多岗位领域隔离与多智能体策略）：多数情况不是给每个岗位克隆一套中台或十个聊天机器人，而是同一引擎 + 一张逻辑大图 + 多重视野（Scope）。岗位差异落在服务端权限裁剪，不靠 Prompt「你是网络岗只能答网络」。

一、不同岗位「能查什么、能做什么」——三层隔离（架构已支持，见 §07）

层次	机制	落在哪	效果
① 视野	RBAC/ABAC · Scope（technical_domain、application_system、team、environment…）	AccessGW 注入 Principal → GraphSync 查询带 scope_filter → ContextAssembler 只灌 Scope 内子图 → ToolGate 结果二次过滤	网络岗只见网络 CI/链路；ERP 岗只见 ERP 子图；越权返回 403 或「不在负责范围」
② 动作	工具白名单 + 读/写分离	Pack tools/ + ToolGate ACL	网络岗可调 query_interface_status；应用岗才可提 restart_lb 等写工具（仍须 HITL）
③ 规程与协议	场景协议 + scope_profile	Pack protocols/（如 DIAG-RCA-Network vs DIAG-RCA-Compute）+ IntentRouter	同一 Harness 引擎，按身份选「先查路由/光功率」还是「先查 Pod/Node」

图谱模型：逻辑上一张 Neo4j（节点/边带 domain、owner_team 标签），访问上多重视野——不按岗位拆多套图库（拆图会导致跨域根因边断裂）。交互演示见本页 §07 · 多岗位隔离。

二、HITL 审批指派给谁？——规则驱动，不是 AI 随便点人

写操作（如 §03 的 restart_lb）流程固定：OPA 拦自动通道 → Harness 建 HITL 工单 → 审批人批准 → ToolGate 执行。审批人由策略解析，典型输入：

• 动作目标：Neo4j 上 pay-lb-01 的 owner_team、technical_domain、所属 Service；
• 动作类型：重启 / 变更 / 建单 — Pack 内 hitl_policy（建议与 rules/ 并列配置）定义「网络设备谁批、应用 LB 谁批」；
• 客户现网：对接 ITSM 审批矩阵 / 值班表（Connector 只读），或企微组织架构映射到审批角色。

示例动作	目标	典型审批队列（实施期配置）
restart_lb on 支付网关	pay-lb-01 · application=支付	应用岗值班长（主）+ 变更经理（高风险）；网络组会诊若根因落在链路
网络设备配置变更	SW-CORE-02 · domain=network	网络组 on-call + 网络规程 R0x
跨域仅读会诊	需他组确认证据	HITL 转派子工单给对应 owner_team；与 Orchestrator 并存，非万能值班长代批所有域

实事求是 · 当前演示 vs 目标架构：§03 演示为简化教学，C4 工单示例使用 approver_role: duty_manager（值班长）——不代表生产里所有写操作都找同一个人。目标架构中审批队列在 PostgreSQL HITL，路由逻辑归 AgentHarness + Pack hitl_policy（实施交付配置），Admin UI 可维护审批矩阵。

「网络批网络、应用批应用」——目标态由 Pack 配置 + Harness 实现（不必新增引擎层）：

• Pack 增加 hitl_policy.yaml：动作 × 资源类型 → 审批角色 / ITSM 队列；
• Harness 建单前增加 ResolveApprover 步骤：读 Neo4j 目标 CI 的 owner_team，合并 Pack 策略输出 approver_queue；
• 可选：Connector 同步客户 ITSM 值班人与审批链，避免在中台维护第二套人事主数据。

三、领域知识是一份还是多份？各岗谁维护？

推荐：一份逻辑语义网 + 分域知识切片（不是网络一套 CMDB、应用再一套）。

资产	组织方式	谁维护
本体与对象 ID	统一 ops-pack ontology/ + 归一词典（全公司一套 ID 语言）	架构师 + 各域代表评审（OntoCore 工作流）
图谱实例	单 Neo4j；入图打 domain / owner_team	GraphSync + 各域映射配置
规程 OPA	Pack rules/；可有域章节（网络 R0x、应用 R0y）	各域制度负责人提交，统一版本发布
运维知识文档 / SOP / 复盘	knowledge/network/、knowledge/compute/、knowledge/app-pay/… → KnowledgeIndexer → VectorStore（chunk 带 domain 元数据）	各岗位维护本域目录；平台统一索引与版本
诊断协议	多协议变体：DIAG-RCA-Network、DIAG-RCA-Compute、DIAG-RCA-App-Pay（共用 Agent.run 引擎）	咨询交付 + 域 SME

也可采用 ops-base Pack + 域扩展 Pack（PackRegistry 声明依赖）——仍是一套引擎，不是十套中台。原则：对象与依赖边全局一致，知识与规程按域切片、按 Scope 可见。

四、跨域故障怎么串联？（目标态 · 如 ALERT-991 支付网关、用户报「OA 慢」）

任务类型	IntentRouter	运行时
单域明确 如网络岗查交换机端口	cross_domain=false → DIAG-RCA-Network	单 Agent.run + 网络 Scope + 网络工具
跨域复杂 支付超时 / OA 慢	cross_domain=true → DIAG-RCA-CrossDomain	Orchestrator 并行委派 App / Network / Compute / Middleware Specialist → 合并带 object ID 的 RCA
人侧会诊	与上并存	Scope 硬边界或策略要求时，HITL 转派给 owner_team 补证据后并入报告

跨域边（如「OA 服务 depends_on 核心交换机」）必须在全图上存在；隔离靠 Scope，不靠删边。§03 演示 intentionally 单 Agent.run 讲清主循环；跨域走 Orchestrator（03 §6.4）。

五、网络岗只想查一台交换机有没有问题——用哪份知识？

一次会话的绑定关系：

• Principal：张三 · 网络组 → Scope = { domain: network, env: 生产 }；
• IntentRouter：意图「单设备诊断 / 链路检查」→ 协议 DIAG-RCA-Network（或更轻的 DIAG-Device-Health）；
• ContextAssembler：GraphRAG 只拉该设备子图；向量 RAG 只在 VectorStore 中检索 domain=network 的运维知识文档片段；
• ToolGate：仅开放网络类只读工具（SNMP/NetConf 经 Connector）；写操作若建议仍走 HITL + 网络审批队列。

不会误用应用侧 Pack 全文，也不会看到 ERP 知识库——检索与工具都在服务端按 Scope 过滤。

六、目标态架构是否完备？实施期配什么？

能力	目标态设计	实施期（咨询/Pack 配置）
岗位视野隔离	Scope（03 §2.4）、ToolGate、GraphSync、§07	IAM 对接、岗位→Scope 映射、强制服务端过滤
分域知识与协议	Pack 多协议 + knowledge/ + VectorStore	各域运维知识文档 入库、DIAG-RCA-* 域变体
审批人路由	HITL + hitl_policy + ResolveApprover	Pack 策略与 ITSM 值班表对接；§03 演示用 duty_manager 简化
跨域编排	IntentRouter + Orchestrator + Specialist 模板	跨域 Pack 协议与联合 eval case（如 OA+网络）

不必为网络/主机/应用各部署一套 Neo4j 或 AgentSvc。客户项目先落地哪条链见 05 排期，不等于 平台无 Orchestrator。多 Agent 协同见下题。

支持，但要先澄清「多 Agent」在我们这里的含义。OASHP 卖的是 Agentic 基础设施（语义层 + Harness + ToolGate + 治理），不是「只做一个聊天 Agent」。平台有多 Agent 概念，但反对行业里常见的两种误用：① 每个岗位克隆一个 ChatGPT + 独立 RAG；② 把「多 Agent」当成营销话术堆机器人数量。

一、和「单 Agent.run」什么关系？（目标态完整产品）

说法	实际指什么	何时用
单 Agent.run	一次诊断的主推理循环（§03 演示）——假设、查工具、反思、综合	IntentRouter 判 单域
多场景智能体	RCA / 巡检 / 变更评审等不同 Pack + 协议，同一 AgentSvc	换场景即换 Pack
多岗位实例	不同 scope_profile 与工具 ACL——Scope 隔离	见上题 FAQ
多 Agent 协同编排	Orchestrator + Domain Specialist 并行/串行，合并报告	IntentRouter 判 跨域

二、什么情况下走单 Agent.run？

IntentRouter 判定 cross_domain=false：

• 单域故障：网络岗查交换机、主机岗查 Node——域 Pack + Scope 内单循环；
• 单场景 SKU：RCA-Assist、巡检——换 Pack/协议，不是新中台；
• 岗位视野不同：§07 — 过滤同一张图，不是多个 Agent 对打。

三、什么情况下走 Orchestrator？（对齐 09 · 03 §6.4）

场景	为何单 Agent 不够	目标态模式
跨域复杂根因 支付超时 / OA 慢	各域 Scope 隔离，单循环无法越权查他域明细	Orchestrator → Network / App-OA / Compute / DB Specialist 并行
跨组会诊	需人确认或 Scope 硬边界	Orchestrator 查证 + HITL 转派 并存
并行查多系统降时延	串行太慢	子 Workflow 并行 ToolGate，Orchestrator 汇总
职责强分离	网络只读、应用才能批变更	各 Specialist 不同写工具 Scope

客户项目先签哪条链见 05 排期；引擎目标态含 Orchestrator 与 HITL 全套能力。

四、不同 Agent 如何协同？（目标态）

P1 告警 / 指挥岗触发
        ▼
┌───────────────────┐
│ Orchestrator      │  LLM 辅助：告警涉及哪些域？拆几条子任务？
│ （轻量编排 Agent） │  Harness 有序：委派 · 等待 · 合并 · Trace
└─────────┬─────────┘
          │ 委派（各带 Scope 令牌 · 独立 workflow 子分支）
    ┌─────┼─────┬──────────┐
    ▼     ▼     ▼          ▼
 Network Compute App-Pay  App-ERP
 Specialist（域协议 + 受限 ToolGate + 本域知识）

• 专家 Agent 不是独立产品：同一 OASHP 上的场景实例——DIAG-RCA-Network、DIAG-RCA-App-Pay 等 Pack 协议 + Scope 配置；
• Orchestrator：LLM 辅助理解「涉及哪些域、先派谁」+ Harness/Temporal 有序编排委派与合并——不是又一个万能大模型，也不是纯脚本；
• 协同契约：子 Agent 输出必须带 object ID 片段；Orchestrator 在授权边界内拼成一份 RCA；全链路进 ClickHouse Trace，可回放谁查了哪一段；
• 写操作：仍走 OPA + ResolveApprover + HITL——多 Agent 不意味着 自动写权限放大。

五、技术上怎么实现？（落模块，不另造中台）

模块	多 Agent 相关职责
AgentHarness + Temporal	父 Workflow 启动子 Workflow；Orchestrator 协议 YAML；子任务完成回调；HITL 挂起点
AgentSvc	每个 Specialist 仍走 Agent.run；Orchestrator 模式为可选编排策略（09 §五）
IntentRouter	判断是否走「单域 RCA」还是「跨域 Orchestrator」协议
ToolGate + Scope	每个子 Agent 携带委派 Scope 令牌，不得越权调他域工具
PackRegistry	Domain Specialist 模板 = 域 Pack 变体 + eval case（如支付+网络联合根因）
ClickHouse	父子 workflow_id 关联，审计「编排者派了谁、各自查了啥」

实现上不新增第二套 Neo4j / AgentSvc——Harness 多 Workflow + 多 Pack 协议实例。客户实施顺序见 §08（05）。

六、和业界「多智能体」 hype 的边界

误区	OASHP 口径
多 Agent = 多个 ChatGPT	一个引擎 + 多协议 / 多 Scope 视图
多 Agent = 多个大模型	可共用一个 ModelRouter；差异在协议与工具
不做多 Agent 就不能跨域	Orchestrator 机器侧协同 + HITL 人侧会诊，目标态并存
§03 演示就是多 Agent	否——演示 intentionally 单 Agent.run；跨域走 Orchestrator

七、HITL 与 Orchestrator 并存（非排期替代）

机制	职责
Orchestrator + Specialist	跨域并行查证、合并带 object ID 的 RCA
HITL 转派 / 会诊	Scope 边界、跨组人侧补证据
HITL 审批	写操作、高风险建议（OPA 后）

八、实事求是 · 演示 vs 目标态

• 架构图 §02：目标完整形态（含 Orchestrator、IntentRouter、HITL）；
• §03 ALERT-991： intentionally 单 Agent.run，便于讲清主循环；
• 排期：某客户先验收哪条链见 05，不等于产品无跨域编排；
• 岗位隔离用 Scope；跨域由 IntentRouter → Orchestrator；人侧会诊与审批走 HITL。

深度设计见 09-多岗位领域隔离与多智能体策略.md · 03 §6.4 · 12 §3.4。

结论先行：不是「不灵活」，而是 灵活放在不同层。CoPaw（Co Personal Agent Workstation，协作个人智能体工作站）、OpenClaw 等擅长 个人/团队工位——用户自己装 Skill、连 MCP、多渠道聊天；OASHP 是 企业运维语义与驾驭中台——跨源图谱、Harness、规程、HITL、评测、Trace。二者可集成，不是二选一。

一、不是同一类产品（别用个人工作站标准衡量中台）

维度	CoPaw / 个人 Agent 工作站	OASHP
典型用户	个人、小团队、开发者	企业运维、SRE、政企生产
核心价值	自定义 Skill、MCP、Console、本地模型、个性化记忆	跨源语义 + 图谱 + 可查可拦可评 的有序办事
「灵活」体现在	用户桌面随手加 Skill / MCP	工位可换；Pack / Connector / ToolGate 对外 MCP 可扩展
治理	个人边界（工具 guard 等）	Scope、OPA、HITL、评测门禁、全链路 Trace

架构分工（04）：入口 = 智能体工位；中台 = 雇主环境（OntoCore · GraphSync · AgentHarness · ToolGate）。OpenClaw / CoPaw = 电话总机；OASHP = 专科诊疗流程 + 病历系统。

二、客户说「不灵活」——对一半

说得对的	需要校正的
若期待每个值班员像 CoPaw 一样随手挂新 MCP、连生产 CMDB、执行写操作 — OASHP 默认不是这种产品形态	不等于「后台全定死、用户什么都改不了」
我们不主做「运维版 ChatGPT + 插件市场」厚聊天 UI（§06）	生产扩展走 Pack + Connector + ToolGate 注册，走评审与 eval，不是聊天框改 Prompt
政企生产里，个人随意接未审计 MCP 通常过不了合规	工位可以很灵活：CoPaw / OpenClaw / 企微 / ITSM 均可作入口

三、谁能在什么层面「自己扩展」？

角色	能做什么	为何不能人人乱挂生产 MCP
值班员 / 一线	在已有工位触发诊断、追问、HITL 审批	写工具须 ToolGate 白名单 + Scope + 审批
运维架构师 / 平台管理员	Admin UI / Git：本体、Pack、工具 schema、Connector、Scope、eval	变更须评审 + 评测门禁（换模型不能「感觉还行就上线」）
集成方 / 厂商	开发 Connector、扩展 ops-pack tools/、对接 REST/MCP（17）	须注册、鉴权、审计 — 不能绕过 ToolGate
已用 CoPaw 的团队	把 OASHP 当运维技能后端：MCP/HTTP 调 ToolGate	个人工位灵活；生产办事仍走 Harness 治理

四、和 CoPaw / OpenClaw 怎么集成？（我们支持的方式）

• HTTP：POST /v1/diagnose · POST /v1/chat（AccessGW）— 外部 Agent 触发运维协议；
• MCP：ToolGate 暴露 MCP Server — CoPaw / OpenClaw 加载「运维技能包」，调 get_alert、trace_ci 等已治理工具；
• Webhook：告警仍可直接 Push，不必经聊天工位（§03 主路径）；
• 不对客户 CMDB/监控的要求：Connector 适配 REST/OpenAPI 即可，不强制客户系统先改成 MCP（见 FAQ · MCP）。

路线图阶段 3（§08）：对外 MCP，成为他方 Agent 的「运维后端」— 与 CoPaw 演示的「个人工作站 + 可扩展 Skill」互补。

五、企业里「用户自己挂 Skill/MCP」存不存在？

场景	是否存在	OASHP 态度
个人/团队用 CoPaw 探索、挂读-only 工具	常见	欢迎作工位；生产查数走 ToolGate MCP/API
架构师扩展 Connector / Pack / 新场景 eval	企业标准做法	主扩展路径
每个值班员私自挂 MCP 写 CMDB / 执行重启	生产少见/禁止	不支持 — 违背 HITL 与 Trace
无评测、无 Trace 的 Skill 直接上生产	风险高	Pack 发布门禁 + eval（13 验收）

企业要的往往是 「可控的灵活」，不是 「个人工作站式随意接生产」。

六、是不是一切都事先定好了？

• 生产办事路径：是 — 协议、工具白名单、规程、审批、评测须 Pack 化、可版本化（能进生产的代价）；
• 扩展路径：否 — 新 Connector、新 Pack 场景、新 MCP 工具 = 管理员 + 咨询交付 + eval，不改引擎主代码（01 边界）；
• 类比：CMDB 不让每个用户随便加字段，但架构师可以扩展模型 — 同一逻辑。

七、15 秒对外答法（含 CoPaw 演示现场）

「您演示的 CoPaw 在个人场景很好用 — 自己装 Skill、连 MCP。我们是 企业运维中台，不替代 CoPaw，可以 MCP/API 挂在后面，提供图谱、规程、审批、评测、Trace。个人工位灵活；生产办事必须可查、可拦、可评，所以不是人人随意往生产插未治理的 MCP。」

你的理解是对的：中台不替代客户 CMDB / 监控 / 自动化平台；它做语义归一 + 推理编排 + 工具网关 + 治理审计。查数优先走自己的图谱与缓存，查不到或要最新明细再回源客户系统；重启等写动作由 ToolGate 调客户已有自动化平台执行，不是中台自己 SSH 上机器。

一、哪些数据存在 OASHP 自己的库里？

存储	存什么	不存什么
Neo4j 图谱	归一后的 CI / 服务 / 依赖拓扑；告警节点（动态层，有 TTL）；对象 ID 关联；GraphRAG 多跳根因	完整 CMDB 副本、指标时序全量、长文运维知识文档
VectorStore 向量库	运维知识文档/SOP、故障复盘、制度全文、相似 case 的 embedding 索引；Knowledge-Assist RAG	替代 Neo4j 做依赖链遍历；聊天 transcript 主记忆
PostgreSQL	账号/Scope、Pack 版本、人工审批工单、评审流状态	业务监控原始数据
ClickHouse	全链路 Trace、每次工具调用的参数/结果摘要、审计检索	替代客户日志平台
Kafka / Redis	告警事件削峰、诊断触发队列、限流缓存	—
MinIO	Pack 版本包、Trace 归档	—

资产与告警的权威明细仍在客户 Prometheus / CMDB / ITSM；GraphSync 通过 Connector 同步归一入图，智能体推理时读的是「带语义的子图 + 摘要」，不是把客户全库搬过来。

二、本演示（ALERT-991）完整工具与能力清单

步骤	名称	类型	数据/执行来源	说明
A2	Webhook 接单	平台内置	AccessGW → Kafka	验签接入，不经过 ToolGate
A3	resolve_entity	平台内置	OntoCore 归一词典	host-10-1-2-3 → CI-PAY-GW-03
A4	告警入图	平台内置	GraphSync → Neo4j	告警挂到 CI/服务节点
A5	启动 Agent.run	平台内置	AgentHarness / Temporal	拉起推理工作流
B1	ContextAssembler	平台内置	GraphRAG 子图 + Pack 契约 + 可选 VectorStore RAG	双路检索组装本轮 LLM 上下文
B3	get_alert	ToolGate · 只读	客户 Prometheus（Connector）	拉告警 severity、labels、持续时长
B4	trace_ci_to_service	ToolGate · 只读	Neo4j 图查询（数据源自 CMDB 同步）	沿依赖链 3 跳定位「在线支付」
B5	list_changes	ToolGate · 只读	客户 ITSM（Connector）	查 24h 内变更单 CHG00412
B7	query_metrics	ToolGate · 只读	客户 Prometheus（Connector）	查 P99 时序验证变更关联
C2	OPA 规程检查	平台内置	ops-pack Rego R05	拦截自动重启，不走 LLM
C3	push_report	ToolGate · 只读	企微 / ITSM（Connector）	推送 RCA 卡片，不改生产状态
C3	link_incident	ToolGate · 只读	ITSM（Connector）	建立告警↔CI↔变更关联
C4	人工审批工单	平台内置	PostgreSQL HITL 队列	写操作闸门，等值班长签字
C5	restart_lb	ToolGate · 写	客户自动化平台（Connector）	如 Ansible Tower / 自研运维平台 / K8s API；须 HITL 批准
C6	审计留痕	平台内置	ClickHouse + Admin UI	全步骤可回放

图例：平台内置 = 引擎自有服务；ToolGate 对外工具 = 须客户开放 API（经 Connector 适配，不要求对方必须是 MCP）；混合 = 调平台图库，但图数据来自客户 CMDB 同步。

三、MCP 到底是什么角色？

• 对外：ToolGate 可暴露 MCP Server，让 OpenClaw、飞书 ISV 等外部 Agent 调运维工具；
• 对内：本平台 Agent.run 调 ToolGate 走 gRPC/内部契约，不绕弯；
• 对客户运维工具：多数已有 REST/OpenAPI（Prometheus、ServiceNow、Zabbix…），用 Connector 适配器接入即可，不强制客户先把 CMDB 改成 MCP。工具 schema 定义在 ops-pack 的 tools/ 目录，由 ToolGate 统一注册、鉴权、审计。

四、执行链路（以 restart_lb 为例）

客户需在实施阶段提供：Connector 配置（API 地址、只读/写账号进 Vault）、写工具白名单、哪些动作必须 HITL。新增一种数据源或执行系统 = 新增 Connector 插件 + Pack 工具 schema，不改 Agent.run 主循环。

结论先行：OASHP 产品 scope = 十大工作域（见 02 §三），不是「只做故障根因」。各域共用同一套 Agent.run + Harness + 图谱 + ToolGate，差异在 场景 Pack（工具白名单、推理契约、输出模板、评测 case）。首期交付哪些 Pack 见 05/13 —— 那是实施排期，不等于 产品只有 RCA。

一、十域总览（主管视角）

域	典型诉求	场景包 SKU（示例）	中台核心动作
A · 监控告警	7×24 盯屏、分诊、升级、抑制误报	Alert-Triage	告警入图、跨源关联、分诊推理、可归并
B · 故障排查	根因、处置、War Room、复盘	RCA-Assist	假设→查证→综合，带 object ID 证据链
C · 日常巡检	定时健康检查、巡检报告	Inspect-Pack	Cron 触发协议、基线对比、异常解释
D · 工单流程	建单、分派、更新、关单、SLA	Ticket-Assist	跨源起草工单、受控写入 ITSM
E · 变更发布	变更评审、影响面、CAB	Change-Review	图遍历 impact、规程 OPA、CAB 要点
F · 网络运维	割接、改造、路由变更影响	Network-Impact	拓扑推理、业务波及、割接草案
G · 容量规划	扩容、新系统资源配比	Capacity-Insight	CMDB+指标 what-if、配比方案草案
H · 应用支撑	「支付/OA 链路还扛不扛得住」	SLO-Breach-Assist	依赖链+SLO+APM 摘要联合判断
I · 知识管理	制度、运维知识文档、新人带教	Knowledge-Assist	RAG + 规程一致，非纯聊天
J · 合规审计	证明 AI 没乱来、能复盘	引擎自带	Trace、评测看板、发布门禁

二、重点五域 + B 域展开（售前最常问）

下面用统一结构说明：客户在干什么 → 单产品 Copilot 常做到哪 → 中台多出来的价值 → 一句话例子。

A · 监控与告警（Alert-Triage）

• 客户在干什么：告警风暴时判断哪些是真 P1、是否重复/误报、要不要升级拉人。
• 监控厂商 AI 常做什么：在本监控系统里做告警解读、相似历史、NL 查指标——数据基本不离开这一家。
• 中台能做什么：告警 入图（ALERT-xxx 挂 CI/服务）；跨源关联 CMDB 名称、未关工单、昨夜变更；LLM 在 Pack 下做分诊/归并；结论带 object ID，可进评测 case；可 Webhook 自动跑协议，不必等人打开聊天框。
• 例子：「支付网关超时」衍生 30 条告警 → 按服务+变更+依赖归并为 1 条根事件 + 值守建议，而非逐条散文解释。

B · 故障排查与恢复（RCA-Assist）

• 客户在干什么：War Room 里多源查证、写 RCA、决定是否执行运维知识文档动作。
• 告警 AI 按钮常做什么：单次 CoT 出分析报告，在全栈厂商环境体验很好；混合栈时易漏变更关联。
• 中台能做什么：Agent.run 多轮假设与查证；GraphRAG 多跳 Alert→CI→Service→Change；输出 逐步工具链 + ci_id/change_id；OPA 拦危险建议；写操作走 HITL。§03 演示 即本域示例。
• 例子：ALERT-991 → 沿图定位在线支付服务 → 关联 CHG00412 → 建议重启须经值班长审批 → 全链路 trace_id 可回放。

C · 日常巡检（Inspect-Pack）

• 客户在干什么：按清单看核心链路/证书/备份是否异常，出报告，异常要立项或开工单。
• 单厂商 AI 常做什么：生成巡检报告模板、NL 查指标——巡检项往往绑在本产品数据上。
• 中台能做什么：Cron 触发 Harness 协议（非临时聊天）；按 Pack 拉 Prometheus/CMDB/日志摘要；对比基线/阈值；LLM 解释偏差并引用 CI ID；异常项可 受控建工单（HITL）；与排障 共用图谱与运维知识文档。
• 例子：「每日 8 点核心支付链路巡检」→ 发现 LB 连接数偏离基线 → 报告写明 pay-lb-01 与建议联系应用岗，不是「请关注负载」。

D · 工单与流程（Ticket-Assist）

• 客户在干什么：告警来了要建单、填字段、分派、更新进展、关单，符合 ITSM 流程与 SLA。
• ITSM Copilot 常做什么：写摘要、润色解决方案、推荐 KB 文章、简单路由——强在 ITSM 表单与本库知识。
• 中台能做什么：从告警/对话/巡检 起草工单（标题、优先级、关联 CI）；描述里 强制带证据链（告警 ID、变更单，来自 ToolGate 回源）；建议分派结合图谱 owner_team + Scope；link_incident 等写操作走 ToolGate + HITL；ITSM 仍是流程主系统。
• 例子：P1 告警自动起草工单，正文含 ALERT-991、CI-PAY-GW-03、CHG00412 链接——不是模型编造的服务名。

E · 变更与发布（Change-Review）

• 客户在干什么：上线前评审影响面、维护窗口、回滚预案是否符合 CAB。
• ITSM/全栈 AI 常做什么：总结变更单、查本系统关联 CI；一家全包时关联较好。
• 中台能做什么：沿 服务模型图 做影响面遍历；拉近期告警、冲突变更；LLM 出 CAB 要点；OPA 对照 R01～Rn（维护窗口等）；输出 可进审计的报告（每结论有 CI/变更 object ID）。
• 例子：「周六更换核心交换机」→ 沿图列出依赖该设备的支付/OA 业务服务 → OPA 提示超出应用维护窗口 → 建议改期。

G · 容量与资源规划（Capacity-Insight）

• 客户在干什么：大促前、新系统上线：要多少 CPU/实例/带宽，历史用量怎么估。
• 监控/云管 AI 常做什么：查历史曲线、给扩容话术——往往单域数据。
• 中台能做什么：汇总 CMDB 配置 + 监控用量 +（可选）APM；LLM 做 what-if（QPS 涨 50% 瓶颈在哪）；输出 分档配比草案供人审批；与 H 域 衔接「链路扛不扛得住」。
• 例子：「新业务要配多少 Pod」→ 读 K8s 现网 + 同类服务历史 + 业务等级 → 给出配比建议与假设条件，不是通用「预留 30%」。

三、其余四域（简表）

域	中台交付物（示例）	与单点 Copilot 的差别
F · 网络	割接影响面报告、拓扑子图推理、网络域 Pack	跨业务服务波及，不靠 Prompt 手写拓扑
H · 应用支撑	「OA 慢/支付超时」依赖+SLO+APM 联合叙述	跨域时配合 Orchestrator，不单域瞎猜
I · 知识	制度+运维知识文档 RAG，回答须与 OPA 规程一致	不是脱离生产的 ChatGPT；chunk 带 domain 元数据
J · 合规	Trace 回放、评测看板、Pack 发布门禁	所有域共用的「敢不敢上生产」底座

四、统一技术路径（十域共用）

触发（Webhook / Cron / 对话 / ITSM）
    → AccessGW + IntentRouter（选域 Pack + 协议）
    → AgentHarness（Temporal 有序编排）
    → Agent.run（LLM 规划 ↔ ToolGate 查证）
    → OPA 规程 + HITL（写操作）
    → 结构化交付物 + ClickHouse Trace

新增一个域 ≈ 新增 ops-pack 场景包（ontology 子集 + tools + protocol + eval），不改 平台主引擎。深度清单见 02-能力全景与功能清单.md · 排期见 05。

五、15 秒对外答法

「我们不是告警摘要工具。产品规划覆盖 监控、排障、巡检、工单、变更、网络、容量、应用、知识、合规 十域——同一中台换 Pack 扩展。RCA 只是最好演示的尖刀；部门 70% 人力在值守和流程，十域才覆盖部门活。」

结论先行：多数客户 已经有 各厂商 Copilot（告警 AI 按钮、ITSM 写摘要、日志 NL 查询、APM 根因提示）。OASHP 不替代 这些系统，也 不逼换 监控/ITSM/入口。我们补的是：混合栈上的跨源语义 + 办事 Harness + 可查可拦可评——让智能体在十域里 有序办事，而不只是各产品里各聊各的。

一、客户现场三类「已有智能体」

路径	典型形态	强项	常见短板（混合栈/合规场景）
A · Skill/MCP	OpenClaw/CoPaw 调各系统 API	接入快、入口统一	跨源 ID 未归一；缺办事协议与评测门禁
B · 告警 AI 按钮	监控/ITSM 详情页「智能分析」	与值班同屏、单栈 MTTR 好	多厂商时 Prompt 易漏关联；难逐步审计
C · RAG 问数	问告警历史、运维手册、指标	降低查询门槛	不善多跳依赖；缺规程拦截与写闭环

详见 14-OASHP与常见运维智能体路径的本质差异.md §三。

二、架构层对照（为什么「看起来都像 AI」）

能力层	厂商 Copilot（典型）	OASHP
跨源归一（同一 ci_id）	全栈厂商强；混合栈弱	GraphSync + 归一词典 → Neo4j
推理主路径	CoT 模板 / 单次问答	Agent.run 多轮 + Harness 协议
规程可执行	多在 Prompt	OPA Rego R01～Rn
写操作治理	因厂而异	ToolGate + HITL + Trace
评测门禁	极少	Pack eval ≥80% 发布条件
逐步审计回放	会话日志为主	ClickHouse 工具级 Trace

三、客户常问的三句话——实话实说

客户说的	实话	OASHP 是否主战场
「ITSM 能自动写解决方案」	若只要润色文字、套模板 → ITSM Copilot 够用	不是主战场
「ITSM 能自动派单」	若只要内置工作流规则 → 用 ITSM 路由	要结合图谱影响面+跨源证据时才值得上中台
「有智能客服」	若指全公司员工泛咨询 → 不是运维中台场景	不是主战场
「告警页已有 AI 分析」	单栈、只要摘要 → 按钮方案可能更省	要跨 CMDB+监控+ITSM 证据链+验收时才上 OASHP
「混合栈，AI 总连不上」	监控 host 名 ≠ CMDB ci_id ≠ 工单口语	核心买点
「审计要逐步回放 AI 依据」	金融/政企/运营商常卡这一条	核心买点

运维值班在企微/侧边栏问告警、要带跨源证据和规程的办事 —— 这才是 OASHP 与厂商 Copilot 重叠但我们要赢 的区间（见 十域 FAQ · Ticket-Assist / RCA-Assist）。

四、与具体厂商能力怎么分工（不贬低、不硬卖）

客户已有	继续让它干	OASHP 补什么
监控（Prometheus/Zabbix/云监控）	采集、告警、指标权威源	Alert 入图、enrich、跨源分诊/RCA 协议
ITSM（ServiceNow/国产 ITSM）	工单流程、审批矩阵、SLA	跨源起草工单、受控写接口、证据链入单
日志/APM	存储与检索、链路追踪	关键字段挂 CI，经 ToolGate 摘要入推理，不全文灌 LLM
CMDB	CI 权威维护	同步归一、补动态边、GraphRAG 多跳
自动化平台	执行脚本/变更	经 HITL 的标准化 restart_* 等写工具调用
厂商自带 Copilot 按钮	单产品内辅助分析	可保留为入口；复杂栈走 OASHP API/Webhook
CoPaw/OpenClaw	个人/团队工位	MCP/API 作运维后端（见 CoPaw FAQ）

五、选型表：什么情况下厂商够用？什么信号该上 OASHP？

客户现状	往往够用的路径	建议上 OASHP 的信号
全栈 Dynatrace/阿里云可观测且满意	厂商 Agent（路径 B）	多源异构、要私有化中立引擎
只要 IM 里查 CMDB/告警	Skill/MCP（路径 A）	要跨源 RCA + 评测 + 十域 Pack
知识库问答、报表口语化	RAG（路径 C）	要多跳根因链 + 变更关联 + 办事闭环
金融/政企/运营商	通常按钮方案不够审计	规程 OPA 拦截 + 逐步 Trace
ISV/OEM 监控厂商	自研 Copilot 皮肤	要白标 Harness 引擎 + ops-pack 交付
已有 OpenClaw 统一 Agent	入口层	要运维垂直图谱 + 协议 + 评测后端

不必硬卖：若客户单栈原厂 Agent 已满意、合规要求低、只要告警摘要 —— 路径 B 可能更省（14 §九）。

六、和 STAROps / BigPanda 等「图+Agent」怎么表述？

实事求是：「结构化上下文 + Agent 做 RCA」不是 OASHP 独家，业内 STAROps/UModel、BigPanda 知识图谱等是同类方向。差异主要在：是否绑定单一云栈、是否以中立私有化 Connector + ops-pack 交付、Harness 评测门禁与办事协议是否产品化。用 场景与验收指标 说话，不用「全面碾压大厂」。

七、是不是只做故障？产品 scope 到底多大？

不是。 产品规划 = 十域（见 上题）。RCA 因好演示、好验收常作 首期试点尖刀（05/13）——那是排期，不是产品定义。若采购问「你们是不是又一个聊天框」→ 见 Harness FAQ：价值在中台，不在 IM 皮肤。

八、30 秒售前话术（现场版）

九、演示建议（一图胜千言）

• 左：同一条 ALERT-991，按钮方案给「散文式分析」；
• 右：OASHP 给「推理链 + 逐步工具链 + ci_id/change_id + 规则拦截 + trace_id」。

可视化对照见 14 §十二 · 全景 §03 演示。

结论先行：未来日常使用 不等于「人人打开一个聊天框用自然语言办事」。OASHP 是 语义与驾驭中台——入口（企微、ITSM 侧边栏、OpenClaw、告警 Webhook）是 可换的工位皮肤；价值在背后的 协议、图谱、ToolGate、Harness。输出也 不全是文字，而是 结构化交付物：卡片、推理链、拓扑图、表格、统计图、审批按钮等。

一、两条主路径（先记住这个，就不迷糊）

路径	谁触发	要不要自然语言	典型场景
① 事件触发	告警 Webhook、定时 Cron、工单状态变更	不需要人打字	P1 告警自动跑 RCA；每日 8 点自动巡检
② 对话触发	企微/OpenClaw/ITSM 里人提问或点按钮	可以自然语言，也可以只点按钮	追问「变更单改了什么」；容量规划问答

优先级上，事件触发 > 对话。 很多价值在「告警来了自动跑协议」，不是等值班员先聊天（见 04 §七 · 全景 §06 UI）。

二、不同入口工位，用起来分别长什么样？

工位	用户感知	是否主要靠自然语言
告警 Webhook	告警到了 → 后台自动分析 → 推结果到企微/ITSM	否
企微/钉钉 Bot	收到结构化卡片（严重度、根因、迷你拓扑、批准/驳回按钮）	卡片为主；可选打字追问
ITSM 侧边栏	工单旁固定面板：推理步骤、拓扑、一键「写入工单字段」	否（面板 UI，不是聊天流）
OpenClaw / CoPaw	像技能包一样对话；内部仍走 Pack 协议	是（自然语言入口之一）
监控大屏「智能分析」按钮	点按钮触发 /v1/diagnose，结果嵌在厂商页面	否

统一技术路径：所有入口 → AccessGW → 同一套 AgentHarness + Agent.run。不是企微一套逻辑、ITSM 又一套。

三、自然语言在里面扮演什么角色？

• 自然语言是 触发与追问的手段之一，不是唯一手段；
• 即使用自然语言提问，后台也是 意图识别 → 选 Pack + 协议 → Harness 有序执行，不是裸 ChatCompletion；
• 值班员可以说「这个 P1 帮我建单」「新业务要多少 Pod」——系统理解意图后跑 Ticket-Assist / Capacity-Insight 等协议，不是即兴闲聊。

四、输出只有文字吗？能不能出图表、报表？

不是纯文字。 平台要求场景 Pack 定义 结构化输出模板（JSON + 渲染组件），常见形态：

输出形态	适用场景	在哪看
企微/钉钉卡片	告警分诊、RCA 摘要、HITL 审批	IM 工位
推理链 / 步骤时间线	故障排查、审计回放	ITSM 侧边栏、Admin UI Trace
拓扑 / 根因链图	RCA、变更影响面	AntV G6 组件、报告嵌入
表格 + 统计图	巡检报告、容量配比、趋势对比	对话回复、PDF 导出、报表嵌入
可回填 ITSM 字段	工单草稿、CI 关联、根因描述	侧边栏「写入工单」
评测 / 审计看板	合规、采购验收	Admin UI（管理面）

容量场景示例：用户问「新业务要配多少 Pod」→ 回复含 柱状图 + 配比表 + 假设条件说明（数据来自 CMDB + Prometheus + APM 经 ToolGate 汇总），不是一段话「建议预留 30%」。演示见 多入口体验演示 · OpenClaw 页 · 点「新业务要配多少 Pod」。

五、我们会不会做一个「运维版微信」？

不会作为主产品。 我们做的是 薄入口 + 厚中台（04）：自研重点是 Admin UI（本体、Pack、Trace、评测）和可嵌入组件；聊天皮肤用客户已有的企微/OpenClaw/ITSM。可选增强：品牌化运维专属交互（推理链逐步展开、拓扑可视化）——无生态通道或需 OEM 时再考虑。

六、企微里真支持这种交互吗？（实事求是）

客户常问：「对话框里能放按钮、卡片吗？」——部分能，但不是微信聊天里随便画 UI。

能力	企微官方是否支持	说明
模板卡片 + 按钮	支持	应用消息 / 智能机器人：template_card，card_type=button_interaction；点击回调 template_card_event（见企微文档 · 模板卡片）
文本通知型卡片	支持	text_notice：标题、键值对列表、跳转链接；群机器人 Webhook 也可发 template_card
会话内自定义拓扑图/柱状图	不原生支持	不能像网页一样嵌 G6/ECharts；通常用键值对摘要 + 点卡片跳 H5/Admin/ITSM 侧边栏，或发统计图图片
自然语言追问	支持	须自建应用/机器人开接收消息回调，用户@机器人或单聊后发文字 → 我方 /v1/chat
群机器人 Webhook 只推送	部分交互	Webhook 可推卡片；带服务端回调的按钮交互需应用/智能机器人配置回调 URL，能力与纯 Webhook 不同

因此：体验演示 里企微页的版式是售前示意，不是 1:1 官方卡片截图；交互模式（推卡片、点按钮、可追问）与官方能力方向一致，但具体 JSON 字段与能否点按钮回传须在 POC 按客户接入方式（应用消息 vs 群机器人 vs 智能机器人）实测。

七、能给客户演示「真实用起来什么样」吗？

能，但要分两层：

• 售前示意：交互原型（不连后端），说明工位分工与信息结构；
• POC 实测：对接真实 Webhook + 企微应用发 template_card，在客户群里验收。

资源：

• OASHP-多入口使用体验演示.html — 四种工位可切换体验；
• 全景 §03 — ALERT-991 逐步 Trace 与 HITL 审批；
• Admin UI Trace / 推理链图 — 管理面验收演示（全景 §06）。

POC 阶段可对接客户真实 Prometheus Webhook + 企微 Bot，那就是 真数据 + 真推送，原型用于售前「先看见长什么样」。

八、30 秒对外答法