你大概率是这么卡住的：想把一个外部系统接进自己的 AI 流程，方案评审时有人说「上 MCP」，有人说「写个 Agent」，两边听起来都行，结果谁也说不清边界在哪、该先动哪块。还有一种情况是代码已经写了一半，工具定义堆在一个文件里，不知道该归到协议侧还是决策侧。这篇不讲概念史，只给一层一层的拆法：谁负责连、谁负责想、谁负责兜底，以及什么场景下根本不需要引入 Agent。
你大概率卡在同一个点上：要把一个外部系统接进 AI 流程，评审时有人说该上 MCP，有人说该写 Agent，听着都成立，但边界在哪、先动哪块谁也说不清。更常见的情况是代码已经写了一半，工具定义堆在一个文件里，不知道该算协议侧还是决策侧。下面不讲概念史，只给层与层的拆法。
一句话铺垫：MCP 这一层管的是「怎么把外部能力标准化地递出去」，Agent 这一层管的是「这次要不要用、用哪个、用完不满意怎么办」。两层职责不同，但经常被混在一个模块里写，结果一改工具定义就得重跑整条流程。先分清谁负责连、谁负责想、谁负责兜底，再决定动手顺序。
先把两层拆开：连接层和决策层
连接层解决的是「怎么把外部能力标准化地暴露出去」：统一描述、统一调用入口、统一返回结构，让同一个工具能被不同客户端复用。决策层解决的是「这次该不该调、调哪个、参数填什么、结果不满意怎么办」：多轮规划、状态维护、失败重试都堆在这一层。两层写在一起，改一个工具入参就可能把决策逻辑带崩。
- 连接层
- 把外部系统的能力包装成有统一描述、统一入口、统一返回格式的工具，换客户端或换模型时基本不用动
- 决策层
- 根据当前任务和上下文，决定调不调、调哪个、参数怎么填、失败后是重试还是换路
不适用的情况也要提前说：只有一个固定工具、调用时序写死、跑一次就完的场景，硬拆两层只会增加维护面，直接写死调用更省事。判断标准是「未来半年内会不会换工具或换调用顺序」，答案是否定的话，拆层就是给自己加活。
对照表：同一件事分别落在哪一层
很多争执其实是因为同一件事被两边都认领了。下面这张表把容易搞混的几件事按层分配，碰到分歧时直接对照，谁也别拍脑袋。
| 事情 | 落在哪一层 | 判断依据 |
|---|---|---|
| 入参校验、超时、鉴权信息从哪来 | 连接层 | 换个调用方这些规则不变 |
| 超时后换另一个工具重试 | 决策层 | 换模型后重试策略要跟着变 |
| 返回原始 JSON 还是摘要 | 连接层给原料，决策层做取舍 | 格式稳定属于连接层职责 |
| 统计一次任务调了几次工具、花了多少额度 | 决策层计数，连接层报单次开销 | 换客户端后统计口径仍在决策层 |
| 这个工具对当前用户是否可见 | 连接层声明能力范围，决策层按上下文筛 | 权限声明是连接层，选择是决策层 |
容易搞反的一点：很多人把「工具返回什么格式」当成 Agent 的事，其实格式稳定属于连接层职责，决策层只负责消费。如果每次工具改版都要回头改决策逻辑，说明接口约定没定死，这时候该补的是连接层的返回契约，而不是继续改 Agent 的提示词。
落地顺序：先想清楚从哪一头开工
先动哪块取决于任务形态，不取决于哪个词更时髦。一个判断标准：如果当前阶段的目标是「让外部系统能被调用」，从连接层起手；如果目标是「把一段多步任务自动跑完」，从决策层起手，工具先用最小可用的桩函数顶住。
- 先判定起点只有一个明确外部能力要接入、调用顺序基本固定，从连接层起手；任务本身是多步判断、每步依赖上一步结果，从决策层起手
- 冻结工具契约两边同时动的时候，先把工具的入参和返回结构定下来再写决策逻辑，否则每改一次定义都要重跑一遍流程
- 用桩函数跑通链路决策层先用假数据或最小实现的工具跑通完整任务，确认调用时机和重试逻辑没问题，再替换成真实连接层
- 最后加工具数量不建议在没跑通一次完整任务前就铺十几个工具，那样出了问题分不清是工具定义错还是决策逻辑错
如果你的目标是先让外部系统能被稳定调用，再考虑谁来编排，那就从连接层起手，把能力包成标准接口；如果任务是边做边判断的多步流程，就先从决策层起手，工具部分先用桩函数顶着，跑通链路再补。站内有一份工具接入选型思路，可以到 /tools/speed-test 看当时的对照，避免在选型阶段反复推翻。
出问题时的排查顺序
两层的故障表现经常长得一样：任务没跑成。区别在于连接层坏了是「调不到」，决策层坏了是「没去调」或「调了没用对」。按下面的顺序隔离，比来回猜省时间。
- 第一步先隔离层：把决策层换成人工按顺序手动调用同一批工具，问题还在就是连接层，问题消失就是决策层
- 第二步看调用日志：是压根没发起调用，还是发起了但连不上，前者查决策逻辑，后者查连接层配置、权限和网络
- 第三步看返回：调到了但模型说没拿到有用信息，多半是返回值太长或结构不适合直接消费，属于两层接口约定没对齐
- 第四步再看是否越界：工具数量多了之后选错工具是常见现象，这时候要收敛的是决策层候选集合，而不是继续改连接层
这套顺序不适用的情况：如果任务本身就依赖实时外部状态、每次调用结果都不同，第一步的人工隔离可能没法复现问题，这时应该先抓一次完整调用链的日志，再按层归类。
什么情况下不该引入 Agent
不是所有接外部系统的场景都要上决策层。下面几种情况引入 Agent 反而更麻烦，判断标准是：流程固定、分支可枚举、对延迟或可追溯性有硬要求。
- 流程固定、分支可枚举：用工作流编排比让模型自己决策更稳，也更好测
- 对延迟敏感且不允许不确定性：多轮决策会拉长链路，能一次调用解决的别拆成三步
- 合规或审计要求每步可追溯：决策层自由度高会增加解释成本，把工具调用顺序写死更合适
- 团队里没人维护决策逻辑：Agent 效果强依赖提示词和工具描述的持续打磨，没人管就会慢慢退化
还有一种边界情况：任务本身很短、失败重跑成本极低，那连连接层都不必追求通用化，直接写一个专用调用就行。省下来的维护精力比标准化收益更大。至于各家接口的消耗水平，别凭印象估，到 /price-watch 核对当时的数字，再决定值不值得为通用化买单。
下一步拿你手上的任务先做一次分层标注：哪些是「怎么连」，哪些是「什么时候用」。标完再去看站内的工具目录和接入对照，确认候选方案是否匹配你当前那一层，比直接问「该用 MCP 还是 Agent」更快出结论。→常见问题
MCP 本身就是 Agent 吗？
不是。MCP 描述的是能力怎么被标准化地暴露和调用，属于连接层；Agent 描述的是拿到这些能力之后怎么做决策、怎么推进多步任务，属于决策层。一个 Agent 可以不用 MCP，自己直接调接口；一套 MCP 服务也可以被普通程序当普通函数调，完全没有决策逻辑。判断标准就是看这个模块有没有「自主选择」的成分。
我只要调一个外部接口，需要上 MCP 吗？
通常不需要。只有一个固定接口、调用时机写死在代码里，直接封装一个函数更快，调试也简单。值得考虑 MCP 的信号是：同一个能力要被多个客户端或不同人复用、工具数量会持续增加、你希望调用方不用关心底层鉴权和网络细节。这些条件不成立时，引入它只是多一层要维护的东西。
Agent 调工具老失败，是连接层的问题还是决策层的问题？
按顺序切：把模型换成人工手动调同一批工具，如果人工调也失败，问题在连接层，去查鉴权、地址、参数类型和网络；人工调成功但模型调失败，问题在决策层，去看工具描述够不够明确、候选工具是不是太多、返回结果是不是太长导致模型接不住。先隔离层再定位，比两边一起改省时间。
