企业官网建设流程全解析

你们有没有过这种经历：电脑里开着七八个软件，每个软件都像一个独立王国——Chrome 里查资料，Notion 里做笔记，Gmail 里收发邮件，本地 Python 脚本做数据处理，再手动把结果粘回来。偶尔偷懒写个自动化，也要处理接口文档、鉴权、回调，折腾半天。最近我盯上一个谷歌开源在 GitHub 的项目，5 天拿了 2 万 Star，热度高得离谱。它倒是直接切中了我这个痛点，也让我对“未来软件的形态”有了一个非常具体且可触摸的判断。

这个项目是谷歌开源的Agent2Agent 协议（A2A），一套用于 AI 代理（Agent）之间互相发现、通信和协作的开放协议。简单说，它想让智能体像人一样交换名片、分派任务、汇报结果。作为一个常年写业务代码、也折腾过不少 AI 工具的工程师，我第一时间 clone 下来跑了一遍。这篇文章打算讲清楚三件事：这个项目到底解决了什么问题，手把手怎么跑通一个真实协作流程，以及为什么我认为它代表下一代软件的组织形态。

1. 两万 Star 在欢呼什么：先认识这个谷歌开源项目

1.1 Agent to Agent 协议要拆掉的墙

不同软件之间的数据协作，到今天还停留在“人工搬运”和“API 对接”两个阶段。人工搬运是常态，API 对接则需要为每一个服务写适配代码——A 系统的数据结构、B 系统的鉴权方式、C 系统的限流策略，全是定制活。过去我们做“软件集成”，本质是在做“翻译器”，把两个互不认识的产品硬拽到一张桌子上。

A2A 想做的事情很直接：给 Agent 之间定一套通用语言和交互流程。Agent 不需要提前认识对方，不需要知道对方的数据库结构，只要双方都实现 A2A 协议，就能完成“发现能力 -> 派发任务 -> 回报结果”这条完整链路。谷歌把它做成开放协议，这意味着不管 Agent 是谷歌的还是微软的、是云端大模型驱动的还是本地小模型跑的，都能在同一套规则下协作。

举个例子。你有一个内部客户支持 Agent，一个日程管理 Agent，一个邮件 Agent。以前要让它们协同处理“客户投诉并安排回访”，你得自己写一个编排服务去拉不同 API。有了 A2A，支持 Agent 可以直接“点名”日程 Agent 创建回访时间，再让邮件 Agent 发确认信。整个过程里，编排逻辑本身成为另一个 Agent，而不是一把硬编码的“胶水代码”。

1.2 MCP 解决了 Agent 连工具，A2A 解决 Agent 连 Agent

研究 A2A 的时候，很多人会拿它和 Anthropic 提出的 MCP（Model Context Protocol）对比。我的理解是：两者根本不在一个层。MCP 解决的是Agent 和工具/数据源之间的连接问题，相当于给 AI 世界设计了一个 USB-C 接口，让模型能标准化地调用搜索、数据库、文件系统这些工具。A2A 解决的是Agent 和 Agent 之间的连接问题，类比的话更像两台电脑之间的“局域网协议”，直接让设备与设备对话。

用一个生活化的场景来区分。用 MCP，你可以让一个 Agent 自己去查航班 API、自己去锁座；但你想让“查航班的 Agent”把结果交给“订酒店的 Agent”再交给“安排日程的 Agent”，MCP 就管不了这一段。Agent 之间没有标准的通信协议，只能通过一个中心调度器手动流转上下文。

A2A 的定位恰恰是这段。它不关心 Agent 内部是怎么调用工具的（那边交给 MCP），它只定义 Agent 与 Agent 之间如何交换任务和结果。所以两者不是竞争关系，而是错位互补。

我身边很多人有一个误区：觉得既然 AI 模型已经很强了，工具协议都会慢慢消失。实际恰恰相反，模型越强，它越需要一个干净利落的方式来“指挥”工具和“沟通”同类。A2A 补上的正是后一块拼图。

2. 为什么说软件要从“应用 + API”走向“代理 + 协议”

2.1 Agent Card：让软件学会自我介绍

A2A 给我最大的启发不是技术实现，而是它定义“软件对外能力”的方式。在 A2A 里，每个 Agent 都要提供一个公开的Agent Card，本质是一个 JSON 文件，里面写着这个 Agent 的名称、描述、服务地址、能力清单、技能细节等信息。客户端一开始不关心对方是什么系统、什么编程语言、什么部署方式，只拉取这个 Agent Card，就知道“这个代理能帮我做什么、该怎么找它”。

这就像面试时交换名片，名片上写清楚你的岗位和擅长领域。过去调用第三方能力，你得看几十页 API 文档；A2A 之后，AI 自己会看“名片”，然后根据名片上的信息直接发任务。这种自上而下的能力发现机制，对软件形态的影响远比我们想象的深。

Agent Card 的字段并不复杂。它包含 name（代理名字）、description（描述，用于让另一个 AI 理解它的用途）、url（服务端点）、version（协议版本），以及 skills 这样的能力声明。客户端会像人读简历一样读取并筛选出最适合完成当前任务的 Agent。这个过程让我想起早期互联网的 robots.txt 和 OpenAPI 规范的结合体，只不过这次“读者”从人变成了 AI 代理。

2.2 任务生命周期：一次跨软件协作是如何被执行的

光有名片还不够，两个 Agent 真正协作时，需要一套完整的状态机来追踪任务进展。A2A 定义了 Task 的概念，一个任务在生命周期里会经历 submitted（已提交）、working（执行中）、input-required（需要更多信息）、completed（已完成）、failed（失败）、canceled（取消）等状态。

这套设计非常工程化。一次跨 Agent 调用不是简单的“我发请求、你回响应”，而是“我提交一个任务 -> 你给出任务 ID -> 我轮询状态或等待回调 -> 你完成后返回结构化结果”。长耗时任务的支持尤其关键：一个 Agent 要去查一个复杂报表，可能得跑几分钟甚至更久，客户端不能抱着连接干等。A2A 允许服务端通过回调机制在完成后通知客户端，和现代异步 API 的设计思路如出一辙。

我在实测里真真切切感受到这个流程：客户端读取 Agent Card 后，经由 POST 请求创建任务，Agent 校验输入、执行内部逻辑、在可交互节点上请求用户补充信息，最后把回复组织成 result 返回。状态机全程透明，开发者可以在任意阶段介入，而非只能悄悄等着超时。对需要多人协作或者多代理编排的业务场景，这种“把过程显式建模”的方法比黑盒 API 要可靠很多。

2.3 三个信号：为什么说这是未来软件形态

第一个信号来自行业巨头的动向。Anthropic 带头推 MCP，谷歌连续开源 A2A 和配套 SDK，OpenAI 也在自己的生态里做 Agent 互联能力。你发现没有，大家拼命定义“协议”，而不是只做应用闭环，说明所有人都认识到：未来 AI 软件必然要跨服务商协作，谁能定义标准，谁就占据生态入口。

第二个信号是端侧工具开始习惯“Agent 意识”。最近一些热门搜索词里，出现了“谷歌浏览器扩展设置中启用 mcp 连接”以及“claude code 怎么手动装 github 上的 skills”这类问题，意味着普通用户已经开始接触 AI 代理与工具之间的连接配置。以前这些词只有服务端开发者关心，现在下沉到了浏览器插件、个人配置层面。这说明代理互联正从基础设施走向普通人的日常操作。

第三个信号就是 A2A 项目本身的星标速度。在开源圈里，5 天 2 万 Star 已经不是一个普通工具能达到的量级。大量开发者疯狂涌入，说明大家看到了同一件事：软件这东西正在从“一个应用 + 一堆 API”的形态，转向“一群 Agent + 一套协议”的形态。之后很长一段时间，真正的软件生态很可能不再围绕屏幕上的功能按钮转，而是围绕“代理能力”转。

3. 跑通 Agent 协作的完整实操记录

3.1 环境准备与本地部署

理论谈再多也不如跑一次真实 Demo。我拿到的版本基于官方仓库 google/agent2agent ，提供了 Python SDK 和 TypeScript SDK，以及若干可运行示例。本地环境准备不算复杂，但有几个细节值得注意。

我当时的操作路径是先把仓库 clone 到本地，然后创建虚拟环境并安装 SDK 依赖。官方推荐用 uv 管理依赖，如果你本地还没装 uv，用 pip 建立 venv 后 install 也可以，只是要注意 SDK 版本迭代较快，以仓库 README 为准。

git clone https://github.com/google/agent2agent.git cd agent2agent uv venv source .venv/bin/activate uv pip install -e "python-sdk[a2a-server,local-client]"

安装完成之后，仓库 samples 目录里自带了好几个可以直接启动的示例 Agent。这里有一个最容易踩的坑：不要第一次就跑多 Agent 的高阶示例，我建议先从一个最基础的 logger Agent 开始。它的逻辑非常简单——接收一段文本，把它记录下来，反馈一个结构化结果。麻雀虽小五脏俱全，用来观察 Agent Card、任务启停、结果回传完全够了。

启动服务后，本地会跑起来一个监听固定端口的 HTTP 服务，A2A Client 可以从这个端口读到 Agent Card。如果你在启动命令里加了 debug UI 相关参数，浏览器会打开一个可视化调试界面，能看到 Agent 收到的每一条请求和它返回的每一条消息。这对理解协议交互特别有帮助。

3.2 让两个代理完成一次跨软件任务

我的目标很具体：客户端作为调度方，同时管理一个“记账 Agent”和一个“日志 Agent”，让前者把一笔费用记录转发给后者做留痕。这个任务本身简单，但已经能体现 A2A 的协作逻辑。

核心代码结构并不复杂。客户端先从 Agent 服务地址读取 Agent Card，确认对方支持的能力，然后发起一个任务请求。

from a2a.client import A2AClient from a2a.types import TaskInput, JSONRPC, Message, TextPart client = await A2AClient.from_url( url="http://localhost:5001", config=None ) task_input = TaskInput( message=Message( role="user", parts=[TextPart(text="记录这条费用：云服务账单 320 元")] ) ) task = await client.send_task(JSONRPC(method="task/send", params=task_input)) print("Task ID:", task.task_id)

服务端 Agent 收到任务后，在自己的能力范围内处理这段文本，并把结果打包回传。如果有需要，它还可以在回复里主动引用另一个 Agent 的 Agent Card，让客户端继续往下游派单。整个过程里，我不需要维护两个服务之间的直接依赖——它们只和协议打交道，不关心对方代码怎么写。

实测下来的感觉是：A2A 把“集成”变成了“对话”。在传统 API 集成里，我要搞清楚每个接口的参数签名、错误码和重试机制；在 A2A 里，我只需要把一个消息塞进 TaskInput，然后等待对方把结果变成结构化数据送回来。对于跨系统的任务流转，这种模式确实省心很多。

3.3 初跑必踩的超时与地址配置问题

这部分是最有价值的实战环节。我在热词里看到一句很真实的报错：“mcp client for codex_apps timed out after 30 seconds. add or adjust star”。自己跑 A2A 的时候，我也遇到了类似现象。新手在本地起服务后，客户端调用另一个 Agent，经常在 30 秒左右直接超时，看日志却发现服务端其实已经处理完了。

我的排查链路是这样的。先看服务端日志有没有收到请求：如果压根没收到，多半是地址或端口配置错误；如果收到了但没响应，问题就出在处理循环或回调地址上。A2A 支持异步回调，客户端必须能访问到服务端给出的回调地址；在本地调试时，回调地址如果写成了局域网 IP 或不可达的公网地址，请求就会卡死在等待状态。

修整方案非常基础但实用：把所有地址统一切回http://127.0.0.1:端口，并且确保客户端与服务端在同一网络可互达环境里。另一个点是依赖版本。A2A 协议才开源不久，sdk 版本之间兼容性有时不够完美，如果你 clone 的是最新代码但环境里装的是旧版依赖，就会出现方法签名对不上、任务提交后没有回执这类诡异现象。我建议尽量用官方示例对应的依赖锁文件，不要凭感觉去装最新版本。

下面对照表列一下我排查出频率最高的几个问题：

我建议所有准备跑 A2A 的朋友，把官方仓库的 debug UI 工具用好。它把每一次任务状态切换都可视化地展示在浏览器里，比看日志高效太多。遇到超时问题，先不要怀疑“协议有问题”，大概率是回调配置和通信细节没对齐。

4. 这套思路会怎么改变开发者与普通用户

4.1 对开发者：从写 UI 到写 Agent 能力

如果 A2A 这类协议真正铺开，软件开发者的工作重心会发生明显迁移。今天我们写业务系统，默认交付物是一个 Web 页面加一组 REST API；未来可能要变成：交付一组 Agent 的能力声明（Agent Card）加上任务处理逻辑。

这不是停留在概念层面的想象。你现在做一个“AI 简历助手”，传统交付物是用户打开网页上传 PDF，然后在页面上读解析结果。在 A2A 的世界里，你的产品交付的是一个“简历解析 Agent”，它对外声明自己会接收 PDF 格式的文件、输出结构化候选人信息。其他 Agent 可以直接调用它，把它嵌入到招聘流程里去：A 公司的人力 Agent 负责筛简历，读到匹配的候选人后自动调用你的简历助手做深度解析，再交给面评 Agent 生成评估意见。你的软件不再要求用户“打开”它，而是要求用户“连接”它。

这符合我这几年的一个观察：软件与软件之间的真实价值往往比软件与人之间的界面更重要。A2A 只是把这件事从“偷偷摸摸做集成”变成了“光明正大地定义能力协议”。

4.2 对普通用户：从管理 App 到管理 Agent 团队

普通用户端的变化会更直接。以后你手机里的“软件”可能不再是一堆需要分别登录、分别授权的 App，而是一队听你调遣的 Agent：一个负责订行程，一个负责整理会议纪要，一个负责盯报价。它们之间的协作由协议完成，你只需要告诉“领队 Agent”你想干什么。

热门搜索词里已经出现了“如何在浏览器插件里启用 mcp 连接”“Claude Code 怎么装 GitHub 上的 Skills”这类问题，说明用户已经在尝试给个人 AI 助手装配跨应用能力。等 A2A 类协议普及之后，“装一个插件”会变成“引入一个 Agent 能力”，软件分发的颗粒度从“整个产品”下降到“一项能力”。订阅模式也可能变化：从按人头买席位，走向按任务成功次数付费。你不再为一年没打开几次的 SaaS 付费，而是每次喊 Agent 干活时按量计费。

这个变化对普通用户最大的意义是减负。你不需要成为所有软件快捷键的专家，只需要学会把任务交给正确的 Agent；软件之间的协作问题由协议解决，不再需要用户自己复制粘贴。

4.3 值得清醒看待的边界

A2A 让我看到未来的同时，也让我保持一种清醒的谨慎。首先就是安全边界。Agent 与 Agent 之间互相发送任务，意味着他人可以更自动地触发你的能力端点。Agent Card 如果过度暴露能力，攻击者可以批量调用你的 Agent 执行付费任务，造成资源盗刷。部署时必须做鉴权、限流、授权模型一整套防护，不能指望协议本身来解决。

其次是协议仍在早期。A2A 的版本变动相当快，我刚跑通的一套流程，过两周再 clone 新代码可能要改接口。想在生产环境用它承担核心业务，现在还是太激进。我更建议拿它在内部工具链和实验项目里试水，跟着生态一起迭代。

最后就是标准竞争风险。MCP 和 A2A 目前是各立山头，未来大概率会有一个融合或趋同的过程。作为开发者，没必要过早把身家押在某一套协议上，保持关注、持续试跑，比盲目站队更稳妥。

我个人在实际操作中体会到，A2A 这个项目最值得玩味的地方不在于某个优化点，而在于它迫使你去重新思考“软件”这个词的本义——当 AI 越来越擅长执行任务，软件的交付单位是不是也该从“界面”变成“能力”？如果你也被这个趋势打动，最好的做法不是收藏几十篇分析文章，而是现在就 clone 一个仓库下来，让两个最小的 Agent 在你本地完成一次对话。跑通了那一下，你对未来软件形态的感知会完全不同。

如果你想动手验证一下，可以顺手给自己手头的小工具加一个agent.json文件，在网上放一个简单的 A2A 端点，然后让一个现成的 A2A 客户端去“发现”它。这十来分钟的小实验，比读十篇“AI 时代软件重构”的行业报告都直观。