业务系统 MCP 开发指南和思路：从「功能搬运」到「能力合成」

一个 CRM 团队的实战复盘：27 个 MCP Tool 上线之后，我们重新思考了三个问题——场景往哪走、边界画在哪、护栏怎么建。本文是我们的答案。

引子：插座已经造好，插什么？

过去一年，几乎所有 ToB 厂商都收到了两个信号：客户在要（租户希望在自己日常使用的 AI 助手—豆包、千问、Claude、WorkBuddy—里直接操作业务系统），竞品在做（同行陆续上线 MCP 并入驻各大 MCP 市场）。我们也不例外：超兔一体云作为面向中小微企业的一体化 CRM 系统，客户管理、销售管理、订单、合同、应收财务跑在同一套数据底座上，这套底座的 MCP Server 上线了 27 个 Tool，覆盖客户、跟进、待办、线索、交易、统计、日报七个业务域，外加一个通用查询层。

但 Tool 上线只是开始。真正难的是下一个问题：场景往哪走？

这里需要先厘清一个容易混淆的地方。业务系统的 MCP 和天眼查式数据服务、AI 做 PPT 这类场景有一个本质区别：它有明确的小范围交付目标。做 PPT 是开放式的内容生成，结果好坏见仁见智；而业务系统的 MCP，说到底是"查询数据 + 写入数据"——目标收敛、结果可校验、对错有标准。正因为收敛，它反而更容易想清楚：业务系统出原子能力，AI 工作平台出组合智能。

真正危险的是第三条路：把 MCP 当成把主系统功能往 AI 平台里搬的搬运工。我们的核心观点是：

凡是主系统界面里本来就能做的事，搬到三方 AI 平台里都只是锦上添花，不是 0→1。 MCP 的正确姿势不是替代、不是重叠、不是冗余，而是强势能力的叠加：主系统出"原子的严谨"，AI 平台出"组合的编排"。

这篇文章，就是我们围绕这个观点展开的完整方法论：一个能力边界定律、一个五问筛选器、四大场景模式、一套 Tool 工程规范、一个关于"组合无约束"的进阶抽象，和一份打样验证方法。

一、第一性原理：两类系统的本质差异

退到最原始的一层看，业务系统和 AI 工作平台是两个物种：

业务系统的设计范式天然排斥一类需求：条件组合是临时的、跨对象的、含模糊语义的批量处理。因为组合空间是无限的，界面只能固化其中有限几个——每多一个组合，就是一次产品需求排期。这就是为什么"大多数业务系统的批量数据分析和批量操作都不强"：不是技术做不到，是产品形态装不下。 超兔一体云在客户管理系统、销售管理系统和订单管理中同样面临这个天花板——界面能固化的组合永远追不上一线临时冒出来的想法。

而 AI 工作平台恰恰相反：它把用户的自然语言意图当场编译成 Tool 调用序列 + 加工逻辑。主系统的"产品经理 + 研发"是离线编译器，排期以周计；AI 是在线编译器，延迟以秒计。MCP 在这个结构里的角色是线束（Harness）——把主系统的能力端子标准化地暴露给这台编译器，让它可以把多个原子能力动态合成为复杂能力。

flowchart TB
    subgraph P["AI 工作平台：即时需求编译器"]
        I["自然语言意图<br>『把这两三天还可能签约的客户整理出来』"] --> C["LLM 即时编译<br>动态合成执行计划"]
    end
    subgraph H["MCP 线束（Harness）：原子能力端子"]
        T1["customer_search"]
        T2["followup_get / followup_create"]
        T3["approval_list / approval_action"]
        T4["data_list / table_schema（通用层）"]
        T5["task_create"]
    end
    subgraph S["业务系统：事实源 + 执行端"]
        V["原子校验 / 业务审核 / 数据联动 / 变更日志 / 权限体系"]
    end
    C --> H
    H --> V

这也是为什么过去的对接方式都没有真正解决这个问题：

二、核心定律：主系统回答「已知问题」，AI 平台回答「刚刚产生的问题」

2.1 三类条件：分水岭在 C 类

把用户对数据的筛选/处理诉求拆开看，里面其实藏着三类条件：

C 类是命门。"还有可能签约"不是一个字段，是一个判断——要综合最近跟进的态度、客户承诺兑现史、历史成单周期做推理。主系统永远不可能把"还有可能"做成一个筛选项。所以三方平台的独占价值不是"多条件查询"，而是 数据筛选（A+B）× 语义研判（C）的即时编译。

由此得到我们的能力边界定律：

凡是查询/处理逻辑可以预先固化的，主系统做（且做得更准）；凡是逻辑是临时的、组合的、含语义判断的，AI 平台做。前者回答"已知问题"，后者回答"刚刚产生的问题"。

2.2 替代、重叠、冗余、叠加：四种姿势的算账

2.3 五问筛选器：场景提案的准入门槛

任何场景提案，先用五个问题过一遍：

flowchart TD
    S["场景提案"] --> Q1{"① 主战场检验<br>用户做这事时本来就<br>在 AI 平台里吗？"}
    Q1 -- "否" --> X1["降级：这是主系统自有功能"]
    Q1 -- "是" --> Q2{"② 0→1 检验<br>没有 MCP+AI 之前<br>是做不到还是只是麻烦？"}
    Q2 -- "只是麻烦" --> X2["降级：锦上添花"]
    Q2 -- "做不到" --> Q3{"③ 数据流向检验<br>主系统是供方/收方<br>还是在被替代？"}
    Q3 -- "被替代" --> X3["放弃：替代型场景"]
    Q3 -- "供方/收方" --> Q4{"④ 频率×智能检验<br>若属重叠，是否高频<br>且 AI 增强产生质变？"}
    Q4 -- "否" --> X4["放弃：简单搬运"]
    Q4 -- "是" --> Q5{"⑤ 组合独占检验<br>是否必须跨系统才能完成？"}
    Q5 -- "单方即可" --> P2["低优先级"]
    Q5 -- "必须组合" --> P0["硬场景，优先打样"]

三、四大场景模式（来自实战）

下面四个模式全部通过五问筛选器，且按"读侧 / 写侧 / 入口侧 / 组织间"构成完整版图。

mindmap
  root((业务系统 MCP<br>四大场景模式))
    读侧：临时战役
      盘点→研判→编排→跟踪
      月底冲刺
      新品推介
      回款攻坚
      竞品舆情应对
    写侧：批量放行
      摘要预筛
      一次确认 N 次执行
      逐单回报+预演模式
      批量审批
      出入库确认
    入口侧：反向录入
      系统找人要数据
      猜测式确认
      会议录音→跟进记录
      名片/聊天记录→建档
    组织间：Agent 对 Agent
      对账/催款自动化
      机器对客观差异
      人对商业关系

3.1 读侧模式：临时战役（非固定 SOP 的动态合成）

业务中反复出现一类需求：月底冲刺名单、新品上市该先找哪些老客户、涨价前该先和谁谈、回款攻坚周怎么排优先级。它们的共性是：条件组合是临时的（不会重复第二次）、跨多个对象域、含 C 类语义条件、输出后要立刻接动作。

这类需求以前的存在形态是"导出 Excel + 人肉加工 + 微信群安排"——主系统在这个战场上的份额是零。所以这不是替换主系统功能，而是接管主系统从未覆盖的灰色地带。

统一骨架是四段式：

flowchart LR
    A["① 盘点<br>跨域取数<br>（A+B 类条件）"] --> B["② 研判<br>语义分级<br>（C 类条件·分水岭）"]
    B --> C["③ 编排<br>分级名单<br>生成动作"]
    C --> D["④ 跟踪<br>回写闭环<br>每日复盘"]
    D -. "战役期间动态升降级" .-> B

以"8 月 26 日，把这两三天还有可能推进签约的客户整理出来"为例，编译后的完整形态是：

1. 盘点：进行中商机 + 近 30 天跟进 + 应收逾期 + 复购超期 + 我的待办，五路取数一次拉齐（不再散落五个菜单）；
   
2. 研判：逐户推理签约可能性并给出理由——"华康医疗：上周演示会态度积极、我方承诺已兑现、新院区招标预算窗口已开 → 能冲"；
   
3. 编排：输出"能冲 / 可试 / 放弃"三档名单，每家附临门一脚建议动作；
   
4. 跟踪：一键生成待办、占日程、起草促签话术，进展逐日回写。
   

3.2 写侧模式：批量放行（原子动作的批量编排）

业务系统为保证严谨，审批、发货、出入库确认都被设计成逐单交互确认。但企业 80% 以上的业务是正常推进的，需要否决和卡住的是少数——库管要的"批量入库确认"，在传统系统里永远排不上开发。

传统路径下，批量能力是 O(n) 的开发成本：每类单据都要专门设计批量交互、批量校验、部分失败处理与回滚界面。MCP 模式的关键差异在于——它不是"批量接口"，而是"原子动作的编排循环"：循环被搬到了 Agent 侧。任何新原子动作上线，其批量能力自动存在，边际成本为零。

sequenceDiagram
    autonumber
    participant U as 审批人
    participant A as AI 工作平台（Agent）
    participant M as MCP Server
    participant S as 业务系统（原子动作）
    U->>A: "我现在有哪些待审批？"
    A->>M: approval_list
    M->>S: 标准链路查询（权限内缩）
    S-->>M: 6 张待审单
    M-->>A: 结构化结果
    A->>A: LLM 摘要预筛 + 例外高亮
    A-->>U: 摘要（②超信用额度 ⚠ ⑤新供应商首单 ⚠）
    U->>A: "除了 2 和 5，其他都同意"
    loop 逐单执行（循环在 Agent 侧）
        A->>M: approval_action（单号）
        M->>S: 原子动作（校验/联动/日志）
        S-->>M: 成功 / 结构化失败原因
        M-->>A: 执行结果
    end
    A-->>U: 执行报告：✓4 单已同意 ⏭2 单跳过（已生成待办）

但"全部同意"绝不能是盲批。审批人真正的判断依据是例外信号——对正常单子做的不是"逐单深思熟虑"，而是"确认没有例外"。所以流程必须三段式：摘要预筛（80% 正常单一行带过，20% 例外高亮）→ 一次确认 N 次执行（指令即确认）→ 逐单回报（部分失败天然消解为执行报告）。外加一个杀手锏指令：预演模式——"先都模拟一遍，看哪些会卡住"，dry-run 逐单过校验不真执行，把例外在执行前暴露。

3.3 入口侧模式：反向录入（系统找人要数据）

CRM 四十年的根基假设是"录入靠自觉"，真实录入率常年三成。反向录入把它翻转为**"系统求人确认"**：Agent 监听工作痕迹（日历里的客户会议刚结束、刚发出的报价邮件），带着猜好的要点来问"对不对"，而不是拿着空白表单问"要不要记"。确认成本从"写"降为"改"。这也是超兔一体云在跟单管理和客户管理中一直想解决却苦于没有好抓手的问题——MCP 把它从产品需求排期里解放了出来。

三条铁律：低打扰（每日主动询问设上限，被忽略两次当日静默）；猜测式确认（永远带预猜要点，绝不拿空白表单）；沉默不视为默认（用户说"没有"就不入库）。这个场景死于"烦"，不死于"漏"。

3.4 组织间模式：Agent 对 Agent 的对账

对账/催款是 B2B 里最高摩擦、最低情商含量的环节：重复、规则明确、双方都不爱做——最适合第一个交给机器。演进分三期：0 期（现在可做）：我方 Agent 生成对账单/催款函，人审后发出；1 期：对账单附机器可读结构化附件，对方财务 Agent 可自动解析；2 期：双方 Agent 直接逐笔核对差异，一致项自动销账，仅分歧项升级给人。设计红线：机器只对客观差异（单据号/日期/金额），商务分歧一律升级；任何金额以主系统为准，AI 只组装不重算。

四、工程开发指南：Tool 怎么造，护栏怎么建

场景是上层建筑，Tool 是地基。这一章是我们超兔一体云 27 个 Tool 的实操规范，以及批量场景对 Tool 提出的新要求。

4.1 Tool 设计七原则（含反模式对照）

前四条是 MCP 上线前的基本修养；错误码语义化和幂等是批量场景逼出来的新硬指标——批量执行报告的质量上限，由原子 Tool 的错误码质量决定；通用层则是长尾路径的保险丝，让"Agent 现场写代码加工数据"不被 Tool 清单锁死。

4.2 确认机制：cold tier 的三种粒度

写操作必须确认，但确认粒度要随场景变化：

4.3 批量场景的六道护栏

五、进阶抽象：从原子到分子 —— Meta MCP 与组合的无约束性

前面四章解决的是"原子怎么造、场景怎么选"。但当你真正把业务系统能力原子化之后，一个更根本的问题会浮现：组合发生在别人家里——AI 平台的 Agent/Harness 能力参差不齐，把组合完全寄托于对方，是有局限和约束的。这一章讨论一个更高级的抽象：当 MCP 多起来、原子化之后，用 Meta MCP（MCP 网关）把"索引、路由、编排"收回到自己手里。

5.1 一个判断：组合的边界就是原子的边界

先确立一个有点"本体论"味道的认知。大模型本身是生成性的——给定一组原子能力，它对业务意图的组合能力在理论上没有约束：今天是"月底冲刺名单"，明天是"把 Q3 没回款的老客户按关系温度分级"，组合空间是无限的。唯一的约束，是原子能力本身的完备性与正交性。

这就像化学：原子种类有限（我们的 27 个 Tool），分子无穷（用户所有可能的业务意图）。从业务本体论的角度看，每个原子 Tool 是业务世界的一个"基元"——客户、跟进、审批、订单；复杂业务逻辑，是这些基元的合法组合。由此得到 MCP 套件设计的终极目标：

不是"功能多"，而是"原子完备且正交"——让任意合法的业务组合都可表达。组合的事交给生成，原子的质量决定组合的上限。

5.2 依附的代价：把组合完全交给平台的三个约束

但"交给生成"不等于"交给某一个平台"。完全依附 AI 平台的 Agent 能力，会撞上三堵墙：

5.3 Meta MCP：给原子套件加一个"司令官"

解法是在原子套件前面加一层"司令官"：所有调用先过它，由它根据意图完成索引、路由与组合判断。这不是设想，行业里已有成型的两档实现：

轻档 · 索引路由型：对外只暴露两个 meta-tool——search(intent)（自然语言检索相关原子）与 invoke(tool, params)（路由执行），把"发现"和"执行"解耦。企业 MCP 网关 SCOUT 面对 2000+ 工具时正是用 tool_search + execute_tool 两个合成工具替代全量 schema 暴露（论文）；微软的 mcp-gateway 以工具路由器为核心组件，按工具定义智能路由到后端服务（GitHub）；Cloudflare 的 Code Mode 更激进——整个 Cloudflare API 压缩成 search() + execute() 两个 Tool，无论后端多少接口，上下文占用恒定约 1000 tokens（官方博客）。

重档 · 编排司令官：把验证过的组合范式固化为服务端的"宏观 Tool"——比如 batch_execute 直接内置批量放行的三段式（摘要预筛 → 一次确认 → 逐单回报），服务端循环、服务端容错、服务端护栏。组合的确定性不再依赖平台的规划能力。

flowchart TB
    subgraph AG["AI 平台（Agent / Harness）"]
        L["LLM：意图 → 组合计划"]
    end
    subgraph GW["Meta MCP（司令官 / 网关层）"]
        S["xtools_search<br>意图 → 检索相关原子"]
        I["xtools_invoke<br>路由执行"]
        M["宏观 Tool<br>遥测验证过的组合<br>如批量放行三段式"]
    end
    subgraph AT["原子 Tool 层（本体）"]
        t1["customer_*"]
        t2["followup_*"]
        t3["approval_*"]
        t4["data_* 通用层"]
    end
    subgraph BS["业务系统（标准链路）"]
        V["校验 / 联动 / 日志 / 权限"]
    end
    L --> S
    L --> M
    S --> I
    I --> AT
    M --> AT
    AT --> BS

5.4 三个工程要点

① "所有调用先过它"无法在协议层强制，但可以事实强制。 MCP 协议没有拦截器，你管不了平台 Agent 绕过网关直调原子 Tool——但你可以对外只暴露司令官端点：三方平台挂载时只看到 search + invoke（加若干宏观 Tool），原子套件藏在网关后面，路由规则自然 100% 生效。

② 意图判断需要模型能力，但不用自己养模型。 MCP 协议有个少有人用的能力叫 sampling：服务端可以反向请求客户端的 LLM 做补全。司令官的意图解析与组合判断，可以借平台自己的模型完成——你出编排逻辑，平台出算力。

③ 护栏集中化反而是安全红利。 弱平台可能没有确认机制、没有循环上限——服务端编排可以把"摘要强制呈现、每批一次确认、批量上限、金额阈值"内置在网关里强制执行。平台能力越弱，司令官的价值越大。

5.5 治理铁律：编排层只承接"遥测验证过的组合"

重档编排最大的风险是退化回 O(n) 老路——每个业务需求都来找司令官做一次服务端开发。治理铁律只有一条：宏观 Tool 的唯一来源，是调用遥测中被验证为高频高价值的组合（第七章的沉淀管道）。AI 平台是试验场，被验证的组合有两条出路：固化回主系统成为标准功能，或固化为司令官的宏观 Tool。没有遥测背书的编排需求，一律不做。

至此，MCP 套件的完整成熟度模型收束为三层：原子 Tool 是本体，路由网关是门面，编排司令官是沉淀管道的出口。 原子做正交，组合无约束；门卫管得住，分子随便长。

六、反模式清单：我们踩过和见过的坑

七、落地方法：筛选 → 打样 → 沉淀

7.1 打样验证：验证的不是技术，是信任

以批量审批为例，我们的打样设计要点是：技术可行性（Agent 循环调 Tool）不在验证范围内，那是已知项；要验证的是交互闭环与信任建立。 三个假设对应三类指标：

配套机制：12 条测试用例（含盲批拦截、竞态、越权三条红线用例，需三轮随机复测稳定）；3–5 名种子用户真实环境灰度（配一键禁用开关）；沙箱中持续埋入用户不知情的例外单，动态测量例外捕获率。

7.2 沉淀管道：两个平台的新陈代谢

场景上线不是终点。调用遥测会告诉你哪些临时组合被反复触发——被验证的高频组合应该固化回主系统，成为标准功能：

flowchart LR
    U["用户临时意图"] --> E["AI 平台：即时编译<br>（试验场 / 孵化器）"]
    E --> T{"调用遥测"}
    T -- "低频 / 一次性" --> L["保持为长尾组合"]
    T -- "高频反复出现" --> F["固化回主系统<br>成为标准功能"]
    F --> M["主系统能力增强<br>MCP 原子能力随之增强"]
    M --> E

AI 平台是需求的试验场与孵化器，主系统是成熟需求的归宿。 调用遥测由此不只是运维数据，而是主系统产品路线图的输入——让真实调用行为投票，正面解决"Tool 由开发者设计、不代表一线真实需求"的痼疾。超兔一体云的产品迭代已经在尝试这条路：哪些临时组合被反复触发，就优先固化进客户管理系统或订单管理的标准功能里。

结语：把场景做硬，把插座做稳

MCP 时代，业务系统厂商的角色正在迁移：从"界面提供商"变成"业务事实源 + 动作执行端"（system of record & action）。界面层让渡给 AI 平台不是损失——前提是你在三件事上做得比任何竞品都扎实：数据模型的语义质量、权限与审计的可靠性、原子动作的事务一致性。这也是超兔一体云的选择：把客户管理、销售管理、订单和应收财务的数据底座做扎实，让 AI 平台在这个底座上组合出无限场景。

入口是谁的并不重要。因为用户最终记住的不是"我在哪个助手里点了什么"，而是"这件事以前做不到，现在做到了"。把原子做正交，把场景做硬，把插座做稳，组合的智能自然会长在你的数据底座上。

本文基于超兔一体云的 MCP 实践整理。文中场景设计、Tool 规范与打样方法均已在我们内部验证或验证中，欢迎同行交流指正。