结论先放这:一个调好的 Agent,别只让它自己单干,把它发布成 MCP Server,别的系统、别的 Agent 都能像调工具一样调它。我把一个折腾了两周的"合同条款解析" Agent 发成 MCP 之后,团队另外三个项目直接挂上就用,没人再重复造轮子。这篇讲我怎么做的和踩的坑。

先说清 MCP 是个啥、为什么要发成它

MCP(Model Context Protocol)说白了是给 AI 系统用的"工具接口标准"。一个能力按 MCP 协议暴露出来,任何支持 MCP 的客户端/Agent 都能发现它、调用它,不用关心它内部怎么实现的。

我的痛点是这样的:我花两周把一个合同条款解析 Agent 调得很顺——能从合同里抽出甲乙方、金额、违约条款、有效期这些。结果隔壁组做风控的、做归档的,各自又要"解析合同"这个能力,眼看就要各搭一遍。重复劳动不说,三套各调各的,质量参差。

把我这个 Agent 发成 MCP,问题就解了:它变成一个标准工具,谁要解析合同,挂上我这个 MCP 调一下就行,内部逻辑只维护我这一份。

我的发布步骤

平台支持把搭好的 Agent 一键发布成 MCP Server,流程不复杂:

1. 先把 Agent 的输入输出收口干净。 这是关键。要当工具被别人调,输入输出得稳定、可预期。我把它收成:输入一段合同文本,输出固定结构的 JSON(甲方/乙方/金额/违约条款/有效期)。别让它有时返这有时返那。

2. 写清楚工具描述和参数说明。 MCP 客户端(尤其是别的 Agent)是靠这段描述决定"什么时候该调你"的。描述含糊,调用方就乱调。我把"这个工具干什么、输入是什么、输出什么字段"写得很明确。

3. 发布,拿到 MCP 接入信息。 平台生成一个 MCP Server 端点和接入凭证,给到需要的同事。

4. 下游挂载。 风控那边的 Agent 在它自己的工具列表里把我这个 MCP 加进去,它的模型就能在合适的时候自动调"解析合同"这个工具了。

发成 MCP 之后的几个真实好处

• 逻辑单点维护。 合同模板变了、要多抽一个字段,我改我这一份 MCP,所有调用方自动享受到更新,不用通知三个组各改各的。

• 质量统一。 大家调的是同一个调好的 Agent,不会出现这个组解析得好那个组解析得烂。

• 调用方省心。 下游不用懂合同解析的任何细节,当个黑盒工具用就行。

两个我栽过的坑

输入输出契约一定要稳。 我中途为了多抽一个字段,改了输出 JSON 的结构,忘了下游是按老结构解析的,直接把风控那边搞挂了。后来学乖了:输出结构当成对外 API 的契约,要加字段只增不改、不删,破坏性变更必须提前通知。把 MCP 当公共接口对待,不能随便动。

工具描述写不好,模型不会调或乱调。 我第一版描述写得太简略,下游 Agent 要么该调的时候没调,要么不该调的时候瞎调。描述里得把适用场景、输入要求讲清楚,模型才用得对。这块比我想的重要。

收尾

调好一个 Agent 别让它孤零零自己用,发成 MCP 让全团队复用,是我今年觉得性价比最高的一个习惯。能这么顺地把 Agent 反向发成 MCP、也能反过来挂别人上万个现成 MCP,靠的是讯飞这类平台把发布和模型(MaaS)都打通了,我只管把能力调好,接口和模型不用自己造。

你们有没有把 Agent 当工具复用过?用 MCP 还是自己包 API?评论区聊聊你们的复用姿势。