很多人第一次接触这两个词，是在排一个跑不通的调用链：Agent 那边工具调不动，或者自己写了个 MCP server 却不知道谁来驱动它。这篇不重复概念定义，只从职责、落地形态、调试入口三块把边界划开，并给一张判断表，帮你决定某一步该落在协议层还是该落在编排层。
很多人第一次撞上这两个词，是在排一条跑不通的链路：Agent 那边工具死活调不动，或者自己吭哧写完一个 MCP server，却不知道到底谁来驱动它。这两个东西经常被放在一起讲，但把它们当成一回事，选型就会跑偏。这篇不重复概念定义，只从职责、落地形态、调试入口三块把边界划开。
先说结论方向：一个管「能力怎么暴露」，一个管「什么时候用、用几步」。把这条线记住，后面拆需求、排故障都能直接套。文末给一张判断表和一份落地清单，帮你决定某一步该落在协议层还是编排层。
先分清谁负责能力、谁负责决策
MCP 协议这一层，干的是把外部系统包成一套统一的工具描述和调用约定：名字、入参、返回形态、错误怎么表示。它本身不做计划，不做多步推理，也不关心你调它的目的是什么。你让它查一次库存，它就查一次库存，它不会因为库存为零而顺手去问要不要补货。
Agent 系统这一层，干的是「什么时候用、用几步」：目标怎么拆、下一步该选哪个工具、结果不对要不要重试、上下文里哪些信息要保留。工具在它这里只是手里的选项之一，选错了是它的问题，不是工具的。判断归属时，看谁在拍板就够了。
- 删掉 MCP 层的代码，Agent 依然能跑，只是没工具可用；删掉 Agent 层，MCP server 只能靠人手动触发，说明它从来就不是 Agent
- 判断某段逻辑该放哪层，问一句：这段逻辑需要看上一步的结果再决定下面的动作吗？需要就是编排层
- 工具内部别塞业务流程分支，塞进去之后其他客户端复用时会带上一堆用不到的隐藏规则
- 不适用的情况：单次一问一答、根本不需要多步循环的场景，硬套 Agent 只是加一层复杂度和调用成本，直接调接口更省事
跑起来的形态不一样，调试入口也就不一样
两边的故障长得完全不同，混在一起查最费时间。协议侧多半是连接类问题：进程没起来、命令路径不对、传输方式对不上、权限被挡在外面。这类问题的排查顺序是先看进程和握手，确认能连上，再看参数对不对。上来就改提示词，基本白忙。
编排侧多半是逻辑类问题：步数打到上限、选错工具、参数拼错、上下文被截断导致忘了前面说过的事。这类问题得先看轨迹，把每一步的输入输出摊开，看清是哪一步开始走歪，再去调整编排策略。
| 对比项 | 协议层（MCP） | 编排层（Agent） |
|---|---|---|
| 典型症状 | 连不上、握手失败、权限被拒 | 步数超限、选错工具、参数拼错 |
| 先看什么 | 进程状态、连接方式、权限配置 | 完整调用轨迹、每步输入输出 |
| 修复入口 | 启动命令、传输配置、凭据 | 编排逻辑、上下文管理、工具描述 |
| 共用底座 | 超时、并发、重试、日志字段 | 同一套，按通用接口做法处理 |
拿一个「先查订单再发邮件」的需求举例：协议层负责把查订单和发邮件各暴露成一个工具，入参出参写清楚；编排层负责决定先查再发、查不到就不发、查到多个订单要不要问一下。同一个需求，两层的活儿是分开的，别混着写。
一张判断表：这一步放协议层还是编排层
下面这张表可以直接对着自己的需求逐条核对。判断的原则是：看复用范围和变化频率。复用面广、调用方式需要统一的，往协议层放；流程要跟着中间结果走、需要人介入的，往编排层放。
| 你的情况 | 放哪层 | 理由 |
|---|---|---|
| 外部系统要被多个客户端复用 | 协议层 | 包一次，到处能用，不用每个客户端各写一遍 |
| 流程要按中间结果改道、要人审 | 编排层 | 分支和判断跟着上下文走，塞进工具会僵住 |
| 只被一个固定流程调用、参数几乎不变 | 直接普通接口调用 | 包一层协议反而多一个故障点 |
| 没人维护长生命周期服务、也不打算治理连接和权限 | 先写脚本 | 协议层的运维成本落不了地 |
- 复用范围是第一个筛子：只有一个调用方，通常不值当单独包协议
- 变化频率是第二个筛子：分支每周都改，就别把它冻在工具内部
- 责任归属是第三个筛子：出问题时要能一眼分清是连不通还是走歪了
- 团队能力是第四个筛子：没有维护长期服务的打算，先别上协议层
落地前的清单与验证顺序
顺序很重要。两层问题混在一起查，是最常见的时间黑洞。建议按下面的步骤走，每步都有明确的验证动作，通过了再往下。
- 先写能力清单列出有几个外部系统、各自要暴露成几个工具、哪些是写操作。写操作要单独标出来，后面权限和确认流程围着它设计。
- 再定驱动方式确认是人在客户端里手动点，还是由一个带循环的编排层自动调。这一步决定你要不要写 Agent，而不是决定工具怎么写。
- 协议层先手工跑通先用手工方式完整调用一次，确认连得上、参数对、返回符合预期。这一步没过，别往下走。
- 接上编排层再跑一遍把工具交给编排层，观察它选不选得对、调几次、结果用没用上。两层问题分开验证，出故障时就能定位。
- 留痕再接真实流量把每次调用的请求、耗时、命中的工具记下来。出问题时能分清是协议断了还是编排走歪了。
- 分层做评测协议层测调得通不通、稳不稳；编排层测该不该调、调几次、结果对不对。指标别混用，混了就说不清是谁的锅。
如果团队里已经在用某个中转站或聚合服务，选型时除了功能，也要看它接得稳不稳、掉不掉线。这块的实测记录可以到 /tools/speed-test 跑一遍看当时的数字，价格波动则到 /price-watch 对照。
不适用这条路径的情况也要说清楚：如果你的需求只是单次调用、没有任何多步逻辑，那协议层和编排层都不用碰，直接写接口调用最省事；如果团队压根没有维护长期服务的计划，硬搭协议层只会多一个没人管的故障点。
下一步把上面的清单对着自己的需求过一遍，先分清哪部分是能力暴露、哪部分是流程编排，再去站内工具目录找现成的连接与评测工具，能省掉不少自己造轮子的时间。→常见问题
是不是用了 MCP 就等于有了 Agent？
不是。MCP 只解决能力暴露和调用约定，它不知道任务目标，也不会自己决定调几次。要不要做成 Agent，取决于你是否需要多步决策和动态改道；固定的一问一答完全可以在 MCP 之上手工触发，没必要硬套一个循环。
反过来，做 Agent 一定要走 MCP 吗？
不一定。工具少、参数稳定时，直接调普通接口更轻，少一层进程和握手就少一类故障。MCP 的价值在于复用和统一，外部系统多、要被多个客户端共用时才划算，否则协议层带来的维护成本会超过收益。
两层一起出问题时，先查哪一层？
先断开编排层，用手工方式把协议层的调用跑通一次，确认能拿到结果；再去跑 Agent 的完整轨迹，看是选错工具还是参数拼错。顺序反了容易把「进程没起来」和「提示词没写清」两类问题混在一起，白白多花时间。
