绿智网 MOM ERP 双 MCP 操作技能

用途

通过两个 MCP 服务操作绿智网 MOM ERP：mom-wiki（7801，前置知识库，只读） 负责回答「要做某个业务该调什么」，erp-mcp（80，确认+执行器） 负责真正读数据 / 写数据。

本技能规定了两者的分工、标准调用流程与安全铁律。内容较大，第一次使用前务必先完成第 0 步。

第 0 步（强制，最先执行）：确认两个 MCP 已经配置好

本技能不会自带任何工具——所有能力都来自这两个 MCP 服务。 因此在动手前必须确认它们已接入当前会话：

检查方法：在当前可用工具列表里查找以下基础名（不同客户端前缀不同，如 graph_search / mom-wiki__graph_search / mcp__erp-mcp__action_call，按基础名识别）：

• 知识库侧：graph_search、graph_chain、graph_info
• 执行器侧：action_search、query_entities、tool_search

判定与动作：

引导用户配置（把下面这段给用户，或让用户按 references/setup.md 的对应客户端填法操作）：

> ⚠️ 本技能不预设服务器地址。 先向用户确认其 MOM ERP 服务端地址 <HOST>；
> 两个服务通常在同一台主机，区别只在端口（知识库默认 7801，执行器默认 80）。
> 拿到后把 <HOST> 替换为实际值再交给用户。不要凭空编造或用示例地址。

{
  "mcpServers": {
    "mom-wiki": { "url": "http://<HOST>:7801/mcp" },
    "erp-mcp":  { "url": "http://<HOST>/mcp" }
  }
}

要同时提醒用户这几件事：

1. 两个服务都在内网，需与 <HOST> 网络可达（同网段或 VPN）。
2. 都不需要鉴权，配置里只填 URL。
3. 浏览器直接打开该地址会返回 HTTP 400，这是 MCP 端点的正常表现，不代表故障。
4. 若客户端要求显式传输类型，补 "type": "http"（或 streamable-http / sse，按客户端提示）；仅支持 stdio 的客户端用 npx -y mcp-remote <url> 代理。
5. 配置后需重启 / 重新加载会话，新工具才会生效。 完成后回到本技能继续。

> 各客户端（WorkBuddy、Cursor、Claude Desktop、Cline/Roo、Cherry Studio 等）的具体配置文件位置与写法见 references/setup.md。用户只要说"帮我配一下"，就直接按该文件给出对应片段的完整步骤。

角色与工作方式

这套技能的本质是驱动两个 MCP 完成一次业务操作，两个环节缺一不可：

1. mom-wiki（前置） → 找到对应的执行链路：这个业务由哪些动作串成、顺序如何、会读写哪些表、有哪些条件分支。这只是一份路线草案，不是可执行结论。
2. erp-mcp（执行器） → 确认，再执行：先确认这些动作在当前版本是否真的存在、参数怎么传，再 dryRun 校验，最后执行。

核心：wiki 查到链路 ≠ 可以直接执行。 必须回到 erp 逐项确认，确认通过才能执行。原因很直接——wiki 是代码快照的推断，erp 才是运行中的真实系统。

动作与实体数量随版本变化，不要记数字，也不要凭猜——需要什么就实时检索。

两个服务的分工

mom-wiki —— 前置：找到执行链路

数据源是代码库抽取的图谱，知识分三层：

• 图谱 graph_*：代码里有什么（动作、能力、读写哪些表、调用链）
• 轨迹 graph_scenario / graph_trace_recent：过去怎么做的（可复用）
• 文档 wiki_*：为什么这样做（业务约束，图谱读不出的）

版本信息只从 wiki 取，不要写死：graph_info 给出当前图谱的抽取时间与规模；wiki_write 会自动给文档绑定时效锚点（图谱版本 + 对应代码快照）。要判断"这条知识对应哪个版本"，就读这些实时字段，而不是记数字。

关键语义：调用链上的边 isConditional=true 表示仅特定条件下触发，不一定执行；节点 semanticSource=describe 权威（来自源码 Describes/*.cs），inferred 可信度低。

erp-mcp —— 确认 + 执行器

四层，统一返回信封 {tool, domain, boundInputs, userId, dryRun, succeed, executeInfo, error, outputs}，业务结果在 outputs（{code, msg, total, data}，code 非 2xx 即业务失败）：

• 业务流程层 action_*：首选。action_search → action_describe → action_call（默认 dryRun=true）
• 组件能力层 tool_*：动作不够用时的原子零件，tool_search → tool_describe → tool_call
• 数据读取层 query_*：query_entities → query_describe → query_list / query_get
• 关系层 schema_relations：表与表引用关系

⚠️ erp 确认是必经关卡，不是"出问题才去"

只要准备执行，就必须先过这四步。 不要因为 wiki 的链路看起来完整就跳过去：

第 4 步是数据展示，不是技术确认。 用户不懂技术，不要问"参数对不对""要不要执行这个动作"；要把结果翻译成业务语言给用户核对：

• 展示：涉及的业务对象与识别信息（单据号、客户名、物料名、数量、金额、日期）、本次会新增/修改/删除什么、状态会怎么变、影响哪些业务。
• 不要展示：动作名、参数结构、dryRun、工具名这类技术细节。
• 用户确认的是"这份数据对不对"，不是"这个技术方案行不行"。

冲突时怎么判

确认过程中暴露的矛盾，按以下处理：

• 动作/组件在 erp 搜不到 → 该链路在当前版本不可执行，以 erp 的可调用集合为准，告知用户这条链路需修正。
• action_describe 的参数 / failures / stateChanges 与 graph_chain 不符 → 以 erp 为准。
• 实体字段、表关系 → 以 query_describe / schema_relations 为准。
• 链路顺序、条件分支的业务含义 → 仍以 wiki 为准（erp 不提供链路语义）。

发现矛盾要主动告诉用户，不要默默选一边。一句话记法：wiki 给路线草案，erp 是出发前的安检 + 实时路况——每次都要过安检，路线本身仍看 wiki。

工具速查

完整参数（必填/可选/默认值）见 references/tool-reference.md。

检索与回写要点（易踩坑，务必读）

• wiki_search 检索正文，且多词查询为 AND 语义——所有词都命中才返回。搜不到时先减少关键词个数，不要以为没写过。
• graph_search 结果会附带相关业务文档（形如 📄 相关文档: 《标题》(wiki_read slug=...)）——看到就顺手读，这些往往就是"为什么这么做"。
• graph_trace_write 的 actions[] 支持 params（关键入参）与 outputs（产物 id）。强烈建议填 params：不填的话轨迹只能复用"调用序列"，下次复用时仍要重新推导全部必填字段，价值大打折扣。敏感字段（密码/令牌）先脱敏。outputs 填新建产物的 id（如 rootPbomId），便于后续步骤串联。
• ⚠️ 轨迹场景按"动作序列指纹"归并，与标题无关。 若你用过同一组动作写过场景，本次会被合并进去，返回的场景 id 不是你的标题——这是预期行为，不是 bug。要建独立场景，请用一组全新的动作组合。
• wiki_write 的返回值有两块必读信息：
• 时效锚点（自动绑定，无需填写）：记录本文档对应的图谱版本 / 代码快照，图谱更新且相关动作有变化时会自动标记待复核。
• 可检索性自检：标题命中、标签命中、正文关键词、关联节点是否存在、能否被关联反查。若出现 ⚠️ 关联的节点在图谱中不存在，文档虽能搜到、但按节点反查时找不到，应修正 relates。
• wiki_delete 不可撤销（删除 wiki/pages/<slug>.md 文件）。流程：先 wiki_read 核对内容 → 再传 confirm=true 删除；不传 confirm 会被拒绝并回显待删内容，这是防误操作设计。
• mom-wiki 是全量覆盖写：wiki_write 同 slug 直接覆盖，没有 append/patch 模式，改文档前先 wiki_read 取回原文。

核心工作流

A. 理解业务：graph_search(关键词) → graph_chain(id) → graph_branches(id) → graph_scenario(关键词) → wiki_related(nodeId) / wiki_search(关键词)

B. 读数据：query_entities(关键词) → query_describe(entity) → query_list(entity, where, ...) 或 query_get(entity, id)

C. 改数据（wiki 找链路 → erp 确认 → 执行）：

【wiki 阶段：找链路】
graph_search(关键词) → graph_chain(id) → graph_branches(id)
        ↓ 链路只是草案，必须去 erp 确认
【erp 阶段：确认】
action_search(关键词, domain?)                 # 确认动作在当前版本存在
  → action_describe(name)                      # 确认参数 / 失败原因 / 状态变更
  → action_call(name, arguments, dryRun=true)  # 确认参数能绑定（看 boundInputs）
        ↓
【数据展示确认：把 dryRun 结果翻译成业务数据给用户核对】
action_call(name, arguments, dryRun=false)     # 执行

找不到合适动作 → tool_search(关键词/组件中文别名) → tool_describe → tool_call(dryRun) → dryRun=false

D. 执行后沉淀：graph_trace_write(scenarioTitle, actions=[{actionId, params, outputs}], status) + wiki_write(slug, title, body, relates=...)

铁律

1. 写操作前做「数据展示确认」，不是技术确认。 dryRun=false 会真实改库；执行前把 dryRun 结果整理成业务数据给用户核对（涉及哪些单据/客户/物料、关键字段值、会新增或改动什么、状态怎么变），确认数据无误后执行。不要要求用户判断动作名、参数结构、dryRun 这类技术细节——用户不看代码。
2. action_call / tool_call 默认 dryRun=true（只校验不执行），只有显式传 false 才真执行。
3. 先试运行，再真执行。 看 boundInputs 是否把参数都绑上了；空数组或缺参先修参数。
4. 不要凭猜测调用。 参数名以 action_describe / tool_describe / query_describe 返回为准。
5. wiki 找到的链路必须经 erp 确认后才能执行。 先用 action_search / tool_search 确认动作在当前版本存在，再用 action_describe 确认参数，然后 dryRun。wiki 链路看起来完整 ≠ 可以直接执行。
6. 冲突时按维度判断：动作可调用性、参数、字段 → 以 erp-mcp 为准；链路顺序与条件分支的业务含义 → 以 mom-wiki 为准。发现矛盾主动告知用户。
7. mom-wiki 不执行任何业务写操作；业务读写全在 erp-mcp。
8. wiki_write 的 relates 必填（至少一个图谱节点 id），否则文档检索不到；写完读一遍可检索性自检。
9. graph_trace_write 在业务真正完成后调用，不预先写；尽量带 params。
10. 查数据用 query_*，不要用写工具去"试"。
11. 判断成功看 succeed 与 outputs.code（非 2xx 是业务失败，原因读 executeInfo）。

条件 DSL

where / tool_call 筛选参数结构：{"字段": {"操作符": 值}}，多字段之间 AND。

操作符：Eq 等于 · Like 包含 · Likes 多值模糊 · In 在集合内（数组） · StartWith / EndWith 前缀/后缀 · Min / Max 大于等于/小于等于。

字段与可用操作符以 query_describe(entity) / tool_describe(name) 为准。

{ "Name": { "Like": "张三" }, "Id": { "In": [1, 2] }, "CreateTime": { "Min": "2026-01-01" } }

> ⚠️ 两套命名要人工对齐：知识库节点 id（power:SaleComplaintModule.Submit、action:xlzw...）与执行器动作名（do_sale_complaint_submit_id）不是同一套。对齐方法：用同一个中文业务关键词在两边分别检索。（当前没有自动映射，一律手动对齐。）
>
> ⚠️ action_search 返回的 components 元素（如 "销售发货组件.新增发货通知单"）是源码中文别名，不是 tool_call 的工具名，且不一定全部触发；要下钻时把这个别名拿去 tool_search 检索。

一句话总结

> 要理解 → 查 7801 找链路；要读 → 用 80 的 query_*；要改 → 7801 找链路 → 80 确认（action_search / action_describe / dryRun）→ 数据展示给用户核对 → 执行；做完 → 回写 7801 的轨迹与文档。
>
> wiki 给的是路线草案，erp 是出发前的安检——每次都要过安检。

参考文件

• references/setup.md —— 各客户端的 MCP 配置接入方式（用户说"帮我配"时用它）
• references/tool-reference.md —— 两个服务全部工具的完整参数速查
• references/playbook.md —— 完整跑通示例（新增客诉并提交）与常见坑清单