企业官网建设流程全解析

1. 从一个"没人用"的小产品说起

去年年底我把自己做的一个小工具挂到了网上——一个专门处理图片批量压缩和格式转换的轻量服务。功能不复杂，但确实解决了一部分人的痛点：设计师朋友经常需要把几十张 PNG 转成 WebP，还要控制体积，手动一张张处理太折磨人。上线之后每天有零星几个用户，靠口碑慢慢传，日子过得不好不坏。

问题出在增长上。我没有预算投广告，也不擅长做内容营销，产品就卡在那个"有人用但没人知道"的阶段。直到今年年初，我开始频繁接触MCP server这个概念，才意识到一个被大多数人忽略的机会：AI 代理正在成为新一代的流量入口。

过去我们做产品，想的是"怎么让用户找到我"——SEO、应用商店、社交媒体。但现在越来越多的用户不再自己打开浏览器搜索工具，而是直接对着 Claude、Cursor 这类 AI 助手说一句"帮我把这批图片压缩一下"。如果你的产品没有以 AI 能理解的方式暴露出来，那在这些对话里你就是不存在的。

这就是我给自己的小产品写 MCP server 的起点。不是赶时髦，而是我发现agent-to-agent commerce这个链条正在成型：AI 代理需要发现工具、理解工具能力、甚至自动完成报价和调用。谁先把自己的产品接入这个链条，谁就先拿到入场券。这篇文章我会把整个过程拆开讲——从 MCP 协议到底解决什么问题，到怎么设计一个能被 AI 代理"发现"并"报价"的 server，再到实测中踩过的坑。如果你手里也有一个"叫好不叫座"的小产品，这套思路大概率能直接抄。

2. MCP 协议到底在解决什么，别被概念绕晕

2.1 用一句话说清 MCP 和传统 API 的区别

很多人第一次听到MCP（Model Context Protocol）会以为它又是一个新的 API 规范，其实不是。传统 API 是"人写代码去调"，MCP 是"AI 自己决定去调"。这个差别听起来小，实际影响巨大。

打个比方：传统 API 像餐厅的菜单，你得自己看菜单、自己点菜、自己告诉服务员要什么。MCP 更像是你走进餐厅，服务员（AI 代理）已经知道厨房能做什么、今天有什么食材、大概什么价位，你只需要说"我想吃点清淡的"，剩下的它帮你安排。

技术上讲，MCP 定义了一套标准化的通信方式，让 AI 模型能够：

• 发现：知道有哪些工具/资源可用，每个工具能干什么
• 理解：读懂工具的输入参数、输出格式、能力边界
• 调用：在合适的时机自动发起请求，拿到结果后继续推理
• 组合：把多个工具串起来完成一个复杂任务

传统 API 的文档是写给人看的，MCP 的 schema 是写给模型看的。这是本质区别。

2.2 为什么 AI 代理需要"发现"和"报价"能力

这里要展开讲一下agent-to-agent commerce的逻辑。当 AI 代理开始替用户做决策时，它面临三个问题：

第一，它不知道你的产品存在。模型的知识有截止日期，你的新产品不在训练数据里。除非你主动以 MCP server 的形式注册到它的工具列表里，否则它永远不会想到你。

第二，它不知道你的产品能干什么。即使知道了名字，如果能力描述写得含糊，模型也不敢调用——它怕调错。所以工具描述必须精确到"输入什么、输出什么、什么场景用"。

第三，它不知道调用你要花多少钱。这是最容易被忽略的一点。当代理需要为用户做成本决策时（比如"用哪个工具处理这批图片最划算"），它需要一个明确的报价信号。没有报价，它只能盲选或者干脆不用。

我给我的图片压缩服务设计 MCP server 时，就把"报价"作为一等公民来对待。不是简单写个价格，而是把计费逻辑、免费额度、批量折扣都结构化地暴露出来，让代理能算清楚账。

2.3 一个最小可用的 MCP server 长什么样

先给一个概念性的骨架，让你知道要写哪些东西。一个 MCP server 通常包含三部分：

• 工具定义（Tools）：每个工具的名字、描述、输入参数 schema、输出格式
• 资源定义（Resources）：可被读取的数据，比如产品文档、价格表
• 提示模板（Prompts）：预置的交互模板，帮助模型更好地使用你的工具

下面是一个简化的工具定义示例，用 JSON Schema 描述：

{ "name": "compress_images", "description": "批量压缩图片并转换格式。支持 PNG/JPG/WebP 输入，输出统一为 WebP。适用于需要减小图片体积、统一格式的场景。", "inputSchema": { "type": "object", "properties": { "image_urls": { "type": "array", "items": { "type": "string" }, "description": "待处理图片的 URL 列表，单次最多 50 张" }, "quality": { "type": "number", "description": "压缩质量 1-100，默认 80。数值越低体积越小但画质损失越大", "default": 80 }, "max_width": { "type": "number", "description": "最大宽度像素，超过则等比缩放。不填则保持原尺寸" } }, "required": ["image_urls"] } }

注意description字段的写法——它不是写给用户看的营销文案，而是写给模型看的"使用说明书"。要具体、要有边界、要说明适用场景。我后面会专门讲怎么打磨这段描述。

3. 把图片压缩服务改造成 MCP server 的完整过程

3.1 技术选型：为什么我选了 TypeScript 而不是 Python

MCP 官方提供了多种语言的 SDK，Python 和 TypeScript 是最成熟的两个。我最终选了 TypeScript，原因有三个：

第一，我的图片处理服务本身是 Node.js 写的，用 TypeScript 可以直接复用现有的业务逻辑，不用重写一遍。MCP server 本质上是个适配层，适配层越薄越好。

第二，TypeScript 的类型系统在定义工具 schema 时特别顺手。MCP 的工具定义本质就是 JSON Schema，而 TypeScript 的类型可以直接映射过去，减少手写 schema 出错的可能。

第三，部署简单。我的服务跑在 Serverless 环境上，TypeScript 编译后就是一个 Node 进程，冷启动快，成本低。Python 在这个场景下要多一层依赖管理，没必要。

如果你是从零开始，Python 也完全没问题，尤其是你的业务逻辑本身就在 Python 生态里（比如用了 Pillow 做图像处理）。选型的核心原则是：让 MCP server 尽量薄，业务逻辑尽量复用。

3.2 工具设计：一个工具还是多个工具

这是设计阶段最容易纠结的问题。我一开始想做一个"万能工具"，把所有参数都塞进去，结果发现模型根本用不好——参数太多，它不知道该填哪些。

后来我拆成了三个工具：

拆分的逻辑是：按用户意图分，而不是按技术实现分。模型是根据用户的自然语言来选工具的，所以工具边界要跟用户意图对齐。如果两个工具经常在同一个对话里被一起调用，那可能就该合并；如果一个工具的参数经常只用到一半，那可能就该拆开。

get_quote这个工具是专门为代理设计的。人类用户不会主动问"多少钱"，但代理会。它需要在调用前知道成本，才能决定要不要用、用哪个。这个工具的存在本身就是 agent-to-agent commerce 的体现。

3.3 报价逻辑怎么暴露给 AI 代理

报价这块我踩过坑。最开始我只在工具描述里写了一句"每次调用 0.01 元"，结果发现代理根本不理解——它不知道这个价格对应多少张图、有没有免费额度、批量有没有优惠。

后来我改成结构化的报价资源，通过 MCP 的 Resources 机制暴露：

{ "pricing_model": "per_image", "currency": "CNY", "tiers": [ { "range": "1-10", "unit_price": 0.02, "note": "标准价" }, { "range": "11-50", "unit_price": 0.015, "note": "批量优惠" }, { "range": "51+", "unit_price": 0.01, "note": "大客户价" } ], "free_quota": { "daily": 5, "note": "每日前 5 张免费，用于试用" }, "estimated_latency_ms": 800 }

这样代理在决策时能算清楚：处理 30 张图，落在 11-50 档，单价 0.015，总价 0.45 元，预计耗时 800 毫秒。有了这些信息，它才能跟其他工具做对比。

提示：报价字段的命名要尽量通用，别用你内部系统的黑话。unit_price、currency、tiers这种词模型见得多，理解成本低。我试过用fee_structure这种自造词，模型理解起来明显吃力。

3.4 让工具描述"说人话"的几个技巧

工具描述是模型选工具的唯一依据，写得好不好直接决定调用率。我总结了几个实测有效的技巧：

第一，把"什么时候用"写进去。不要只写"压缩图片"，要写"当用户需要减小图片文件体积、统一图片格式、或为网页优化图片加载速度时使用"。模型是靠场景匹配来选工具的。

第二，把"什么时候不用"也写进去。比如"本工具不处理 GIF 动图，如需处理动图请使用 xxx"。这能减少误调用。

第三，参数描述要带例子。quality参数不要只写"压缩质量"，要写"压缩质量 1-100，默认 80。80 适合网页展示，95 适合需要保留细节的场景，60 以下画质损失明显"。

第四，避免歧义词。"处理"、"优化"、"增强"这类词太模糊，模型不知道具体做什么。用"压缩"、"转换"、"裁剪"这种明确的动词。

我做过一个对比测试：同一批用户请求，用模糊描述时工具调用准确率大概 60%，改成上面这套写法后提升到 90% 以上。这个投入产出比非常高。

4. 实测：AI 代理是怎么"发现"并调用我的服务的

4.1 在 Claude 里跑通第一次自动调用

配置好 MCP server 后，我在 Claude Desktop 里加了配置。第一次测试我故意不说工具名字，只说需求：

"我有 20 张产品图，都是 PNG 格式，体积有点大，帮我处理一下适合放到网站上。"

Claude 的反应是：先确认了图片位置，然后自动选择了compress_images工具，quality 填了 80，还主动提了一句"预计费用 0.3 元，在您的免费额度之外"。那一刻我意识到，报价信息确实被它读进去了。

整个调用链路是这样的：Claude 解析用户意图 → 匹配到我的工具 → 读取报价资源 → 计算成本 → 发起调用 → 拿到结果 → 生成回复。全程用户只说了一句话。

4.2 在 Cursor 里的表现差异

同样的 server，在 Cursor 里的行为不太一样。Cursor 更偏向代码场景，它调用我的工具时通常是在处理项目里的图片资源。比如我在编辑器里选中一个图片文件夹，输入"优化这些图片"，Cursor 会自动扫描文件夹、生成 URL 列表、调用工具。

差异点在于：Cursor 对报价的敏感度低一些，它更关注执行结果。而 Claude 在对话场景下会更主动地提示成本。这说明同一个 MCP server 在不同宿主环境下的行为会有差异，设计时要考虑通用性，别针对某一个宿主做过度优化。

4.3 代理自动报价的真实案例

最有意思的一次测试，我让 Claude 比较两个方案：

"我有 100 张图要处理，你帮我看看怎么最划算。"

它调用了我的get_quote工具，拿到分档报价后，算出 100 张落在 51+ 档，单价 0.01，总价 1 元。然后它又提到"如果分两天处理，每天 50 张，可以叠加每日免费额度，总价能降到 0.9 元"。这个优化建议我自己都没想到——它把免费额度这个规则也纳入了计算。

这就是 agent-to-agent commerce 的雏形：代理不只是执行，它还在做成本优化。对产品方来说，这意味着你的定价策略会被代理"看穿"并利用，所以定价逻辑要设计得经得起推敲。

4.4 调用日志里藏着的信息

MCP server 的日志值得单独讲。我一开始只记了基本的请求响应，后来发现日志里能挖出很多有价值的信息：

• 哪些工具被调用最多：反映代理对哪些能力的真实需求
• 参数分布：比如 quality 参数大部分填 80，说明默认值合理；如果经常填 95，说明默认值偏低
• 调用失败的原因：是参数错误、超时、还是权限问题
• 代理的"犹豫"：如果某个工具被频繁查询但很少真正调用，说明描述有问题，代理在纠结

我把日志接到了一个简单的分析脚本里，每周看一次。有次发现convert_format工具被查询了 200 多次但只调用了 30 次，排查后发现是描述里没写清楚支持的格式列表，代理不确定能不能处理它手上的格式，就放弃了。补上格式列表后，调用率上去了。

注意：日志里不要记录用户的原始图片 URL 或任何敏感信息。MCP server 的日志应该只记录元数据——工具名、参数类型、耗时、结果状态。这既是合规要求，也是好习惯。

5. 踩过的坑和绕过的弯

5.1 工具描述太长反而降低调用率

我一开始把工具描述写得非常详细，恨不得把产品说明书全塞进去。结果发现调用率反而下降了。后来才明白：模型的上下文窗口有限，描述太长会挤占其他信息，而且关键信息被淹没在细节里。

正确的做法是：核心能力用一两句话说清，细节放到参数的 description 里，更详细的文档通过 Resources 暴露。模型需要时会自己去读资源，不需要时不占用上下文。

5.2 报价单位不统一导致的混乱

有次我把报价写成"0.01 元/张"，但工具参数里用的是"批次"。代理算的时候懵了——一批多少张？后来统一成"按张计费"，参数里也明确单次调用的图片数量，问题才解决。

单位一致性是报价设计的第一原则。计费单位、参数单位、返回结果的单位必须对齐，否则代理算不明白。

5.3 错误处理没做好，代理直接放弃

早期我的 server 遇到错误就返回一个通用的 error 消息，结果代理收到后不知道怎么处理，直接告诉用户"服务不可用"。后来我改成结构化错误：

{ "error": "INVALID_IMAGE_FORMAT", "message": "第 3 张图片格式为 BMP，暂不支持", "suggestion": "请先转换为 PNG 或 JPG 后重试", "failed_items": [3] }

这样代理能理解具体哪里出了问题，还能根据 suggestion 自动补救。错误处理做得好，代理的鲁棒性会明显提升。

5.4 免费额度被代理"薅"的应对

上线两周后我发现免费额度消耗得特别快，排查日志发现是某个代理在批量测试时反复调用。这不是恶意行为，而是代理在探索工具能力。

应对方式是给免费额度加了"每会话限一次"的限制，而不是简单的每日总量。这样正常用户不受影响，代理的探索行为也被约束了。设计面向代理的产品时，要假设代理会做各种边界测试，规则要经得起压力。

6. 这套模式能复制到哪些产品上

6.1 判断你的产品适不适合做 MCP server

不是所有产品都适合。我总结了一个简单的判断标准：

图片压缩天然符合这些特征，所以改造起来顺。如果你的产品是"帮人做战略咨询"这种，就很难结构化。

6.2 从"人找产品"到"代理找产品"的思维转变

最大的转变在于：过去你优化的是"用户看到产品页后的转化率"，现在你要优化的是"代理在工具列表里选中你的概率"。

这意味着几件事：

• 产品名要直白：image-compressor比PixelNinja更容易被代理理解
• 能力描述要精确：别用营销语言，用功能语言
• 报价要透明：代理讨厌隐藏费用，透明定价反而提升调用率
• 错误要可恢复：代理需要知道怎么补救，而不是直接失败

6.3 后续可以扩展的方向

跑通基础版后，我还在尝试几个方向：

第一，多工具编排。让代理能把我的压缩工具和别的工具串起来，比如"先压缩再上传到 CDN"。这需要工具之间有良好的接口约定。

第二，动态定价。根据当前负载调整报价，闲时便宜、忙时贵。代理能理解这种逻辑，反而会觉得合理。

第三，能力协商。代理在调用前先问"你能处理 WebP 吗"，server 返回能力清单，双方协商后再调用。这能减少无效调用。

这些方向都还在实验阶段，但方向是明确的：产品不再只是给人用，还要给代理用。谁先把这层适配做好，谁就在 agent-to-agent commerce 的早期拿到位置。

我在实际操作中的体会是，MCP server 的改造工作量比想象中小——核心业务逻辑不用动，主要是加一层适配和描述。但收益是实打实的：上线一个月后，通过代理渠道进来的调用量占到了总量的三成，而且这部分用户的付费转化率比自然流量高不少，因为代理在推荐时已经帮用户做了成本决策。如果你手里有类似的小产品，真的值得花几天时间试试这条路。