MCP/A2A：显式编程终结的开端

昨天在AI架构领域发生了件大事，老实说，我认为我们大多数人并没有完全意识到这到底有多大。

谷歌刚刚宣布了代理到代理协议（A2A），虽然大多数人都很自然地关注高调的合作名单，但吸引我的并不是“谁”。而是“什么”。更具体地说，这意味着我们如何构建、扩展甚至概念化软件的方式。

因为A2A公告不仅仅是一个“功能”公告。这是对一个根本性转变的再次肯定，即重新构想软件是什么以及它应该怎样工作。

1、从确定性软件到自主协作的转变

大约70年来，我们一直在使用一种相当僵化的思维模式来构建软件：确定性指令、明确逻辑、定义输入和输出。一切都由人类手动硬编码，从数据流的方式到每个决策树的分支方式。

这对许多用例来说是很好的，甚至是非常棒的。这就是我们如何获得可靠的银行系统、电子商务，当然还有Salesforce（没有偏见）。我们擅长瀑布式开发、敏捷开发，后来又发展出微服务，但底层结构仍然保持不变：由人类手写的硬编码逻辑。

但有些事情改变了。

当我深入研究模型上下文协议（MCP）时，我意识到这是对这种确定性大坝的第一个重大裂缝。MCP并不要求我们为每条路径编写代码。相反，它邀请我们以结构化的方式描述能力，并让AI自行决定如何最好地使用它们。

这很微妙。但它确实有点深远。

我们正在从“怎么做”转向“可能是什么”。这是一种根本不同的思维方式。

而现在，通过A2A，我们不仅将这种转变从人类扩展到AI，还从代理扩展到代理。

简而言之，MCP是关于给AI灵活访问工具的能力，而A2A则是关于让代理发现并彼此协作。

这不仅仅是编程工作流程的问题。这是关于代理理解彼此的能力，发起动态协作，并朝着共同目标协调行动。想象一下，作为自主软件形成自己的微型团队，在飞速中进行。

你有一个销售自动化系统。传统的软件会硬编码工作流程，比如潜在客户资格规则、邮件发送时间、跟进逻辑等。通过MCP，代理可以探索你的CRM、电子邮件客户端和分析工具，然后找出如何完成任务。

但是A2A呢？A2A允许那个销售代理找到另一个专门从事定价策略的代理，另一个负责电子邮件文案的代理，另一个负责日历管理的代理——并根据情况动态协作。

你不需要编程协作。你只需要描述能力，让代理自己处理其余的事情。

这是一个范式转变。

有挑战吗？当然有。但它们是正确的挑战。现在，我不会假装这是即插即用的。不是这样的。如果你像我一样是一名工程师，你的脑海里可能已经充满了问题：

这些都是公平的问题。真正的担忧。

但这里有一件事：这些不是错误。它们是新地形的特性。这些挑战是我们正在进行的转变的一部分。我们正从可预测的预定义软件世界进入一个新兴的、适应性的、智能系统的领域。

而这正是让它如此强大的原因。

这是我最近一直着迷的一个思维转变：

我们不再将任务委托给软件。我们正在将意图委托给智能。

这就是关键所在。在旧的世界里，功能是显式编码的。在新的世界里，功能是协商、发现和涌现的。我们不再只是调用API，而是与代理互动，这些代理决定如何实现目标，而不仅仅是执行步骤。

A2A规范反映了这一点：它们基于现有标准（HTTP、JSON-RPC），支持长时间运行的任务，并优先考虑可观测性和可调试性。最重要的是，它们是开放的。这不是另一个围墙花园。这是一个开放的邀请，让我们重新构想软件本身。

我认为我们正在见证一种新软件架构的诞生，一个系统不仅互操作，而且协作的世界。功能不仅被构建，而且从代理协商中浮现出来。

是的，我们会面临新的问题类别。是的，会有引人注目的失败。但这正是进化的一部分。

我们不只是在旧的软件栈上添加新功能。我们在改变基础本身。这比云计算更大。比DevOps更大。这是迈向软件的一小步，它可以思考、适应并在未明确告知的情况下协作。

MCP和A2A的结合可能是最终实现真正自治系统的标志。这是一个巨大的事情。

所以，是的，这很重要。不仅是因为谷歌宣布了一些闪亮的东西。而是因为我们终于开始构建行为不像脚本而更像同事的软件。

汇智网翻译整理，转载请标明出处