去魅：工具调用、Agent 调用、A2A、MCP、Harness 到底都是什么

一句话版：工具调用是"用能力"，Agent 调用是"委派封闭任务"，A2A 是"对等协作协议"，MCP 是"工具接入的接口标准"，Harness 是"Agent 运行时的工程胶水"。 后三个不是魔法，前两个也不是落后。简单场景硬上后面三个，就是加层。

这几年 AI 圈有个毛病：把工程常识换个大词，再开个发布会，就成了"新范式"。 结果是人人都听过这些词，没几个人能说清它们到底解决什么问题、什么时候不该用。这篇不吹不黑，把五个概念扒到人话层，顺便给一条判断标准：你该不该用。

一、工具调用：让模型"用能力"

最朴素的一层。模型自己不能查数据库、不能发邮件、不能读文件，于是你给它一组函数：

复制代码

get_weather(city) -> 天气
search_db(query) -> 结果
send_email(to, subject, body) -> 成功/失败

模型输出"我要调 get_weather("深圳")"，你的程序执行，把结果喂回去。这就是工具调用，也叫 function calling。

本质：主体 → 客体。用一次能力，拿一个结果，结束。 工具没有自主推理，只执行被指定的操作。

不需要任何协议。 你自己定义 schema、自己执行、自己把结果拼回上下文，就是完整的工具调用。MCP 之前，全世界都这么干，跑得很好。

二、Agent 调用：把"一个 Agent"包装成"一个工具"

当主 Agent 职责过载------工具太多、指令太长、选择准确率下降------一个常见做法是把一部分职责打包成一个子 Agent，对外暴露成一个工具：

复制代码

translate_document(file, target_lang) -> 翻译结果

主 Agent 看来这就是个普通工具：给输入，拿输出。但"函数"内部是一个完整的 Agent，有自己的循环、工具、上下文。

本质：主体 → 附属执行者。子 Agent 的自主性被"工具化"了，对外透明。 调用者不关心里面怎么查词典、怎么润色，只验收最终交付物。

这是系统内部的工程优化，不是协议。 它解决的是"单个 Agent 别过载"，不是"跨系统怎么对接"。

三、A2A：让两个独立 Agent 对等协作

当你需要和另一个团队、另一家公司开发的 Agent 合作时，问题变了：你不能、也不应该把它"工具化"，因为：

它是独立系统，你不控制它；
它需要保留自己的推理和决策；
任务可能很长，中途要反问、要补充输入、要更新进度；
双方可能用不同框架。

A2A（Agent2Agent）就是为这个场景设计的协议。核心概念就几个：

Agent Card：对方的能力名片，你能发现它会什么；
Task：以任务为核心，有生命周期（提交、进行中、需补充输入、完成、失败）；
多轮消息：对方可以反问，你可以补，不是一次请求就结束；
对等：双方都是自主 Agent，不互相暴露内部实现。

本质：对等主体 ↔ 对等主体，有状态的多轮任务协作。

四、MCP：工具接入的"USB 接口约定"

这里要澄清一个常见误解：MCP 不是"把工具封装成 API 还非叫协议"这么简单，但它也确实被过度话语化了。

普通工具 API 的问题是：每个 AI 宿主、每个工具、每个团队各定义一套 schema、认证、发现方式。 N 个宿主 × M 个工具，就要做 N×M 次私接。MCP 想标准化的是：

工具服务器怎么被任意宿主发现；
双方怎么能力协商；
工具、资源、提示怎么统一描述；
传输层怎么解耦（stdio / HTTP 等）；
权限、生命周期、调用语义怎么约定。

它标准化的不是"工具调用"这个动作，而是"工具服务器如何以通用方式被不同客户端接入"。类比：REST 只规定传输风格，USB 规定的是"设备怎么被任意主机识别和使用"。MCP 更接近后者。

但批评依然成立： 如果你就是自己一个 Agent 调几个函数，function calling / 普通 API 就够了，上 MCP 纯属加层。MCP 的价值只在"工具要被多个不同 AI 宿主复用"时成立。

五、Harness：Agent 运行时的"工程胶水"

Harness 是这五个词里最容易被包装成"新范式"的，但本质上最不神秘。

把大词扒掉，它干的就是：

大词	人话
上下文精细化	每步决定给模型看什么、丢什么、总结什么
工具系统	注册工具、校验参数、执行、把结果喂回去
执行编排	循环：想 → 调工具 → 看结果 → 再想，直到完成
记忆与状态	任务到哪了、中间结果存哪、断了怎么续
评估与观测	日志、trace、成功率、成本、失败原因
约束与恢复	沙箱、权限、超时、重试、熔断、回滚

这些没有一个是 AI 新发明。传统后端、工作流引擎、RPA、操作系统里都有对应物。Harness 的新意只在于：这些胶水是围绕"LLM 作为推理引擎"重新组织的。

为什么裸模型确实需要这层胶水？因为裸 LLM 有几个硬缺陷：

不会自己循环------一次输出完就停，不会"调工具→看结果→再决定"；
不会管理上下文------窗口有限，历史一长就噪声爆炸、成本失控；
不能安全执行------不能直接让它碰文件、数据库、网络；
不会恢复------出错、超时、工具挂了，需要重试、断点、降级；
不可观测------不记录 trace，你根本不知道它为什么失败。

Harness 的价值是把这些集中成一层，而不是每个 Agent 项目自己重写一遍。 它跟 MCP/A2A 的关键区别：MCP 是接口标准，A2A 是协作协议，Harness 是你自己系统内部的运行时架构。 它不要求别人跟你对接，所以"收生态税"的能力弱得多。

六、一张表看清五者关系

概念	本质	关系方向	是否协议/标准	什么时候该用
工具调用	用一次能力	主体 → 客体	否	几乎所有场景的基础
Agent 调用	委派封闭子任务	主体 → 附属执行者	否	单 Agent 过载、职责要拆分
A2A	对等任务协作	对等 ↔ 对等	是	跨框架、跨团队、跨组织
MCP	工具接入标准	宿主 → 工具服务器	是	工具要被多个宿主复用
Harness	Agent 运行时胶水	系统内部	否（架构模式）	多步、多工具、要恢复、要观测

七、判断标准：什么时候别用

这是全文最重要的一节。术语膨胀最大的危害，是让简单问题被引导到重架构。

别用 MCP，如果：

你就是自己一个 Agent 调几个函数；
工具只给你自己的应用用，不会跨宿主复用；
你的团队没有多语言、多客户端的接入需求。

别用 A2A，如果：

双方 Agent 都是你控制的；
任务简单、一次请求就能结束；
你不需要跨组织对接，私下拉通一个 send_message 工具就够了。

别用重 Harness，如果：

单次调用能搞定（翻译、分类、摘要）；
固定工作流能搞定（步骤确定、分支有限），普通代码/工作流引擎更稳；
一个脚本能搞定（读文件→调 API→写结果）；
工具就两三个、任务就几分钟。

你自己写的那个 while 循环 + try/except + 日志，就是最小 Harness。 不需要引入框架，不需要叫它 Harness。

八、最后：该骂什么，不该骂什么

该骂的是：

把工程常识包装成"新范式"，先讲愿景不讲最小可用路径；
用"不支持某协议"制造焦虑，逼你接入生态；
标准夹带私有实现偏好，治理不开放；
简单问题复杂化，抬高理解成本。

不该骂的是：

标准化本身------分散私接变统一约定，确实降低互操作成本；
抽象本身------多步任务确实需要运行时胶水，裸模型确实有硬缺陷。