[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fVUJ1gqlb7Foa4Rmh594bd47nKAOJjHsJr-JOYJkSCJU":3},{"item":4,"related":43},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":35,"sourceUrl":35,"status":36,"seoTitle":35,"seoDescription":35,"canonicalUrl":35,"isFeatured":37,"sno":38,"sortOrder":39,"publishedAt":40,"updatedAt":41,"createdAt":42},"a3c11b62-9668-40cf-822d-25787f994c75","article","A2A：当 Agent 开始互相「递名片」","a2a-agent-to-agent-protocol","MCP 让 AI 统一接上工具，却没解决 Agent 之间怎么分工。A2A（Agent-to-Agent 协议）用「Agent Card 名片」让智能体互相发现、委派任务、协作交付。","你有没有想过：当公司里不止一个 AI Agent，而是几十个，它们该怎么分工？谁负责查天气、谁负责排日程、谁负责写代码？如果让它们各自为战，那不过是把「一个人的孤岛」换成「一群人的孤岛」。\n\n一个叫 A2A 的协议正在解决这个问题——它让 Agent 之间能像人一样「互相介绍、认领任务、协作交付」。\n\n## MCP 解决了「接工具」，没解决「连同伴」\n\n我们先前聊过 MCP（模型上下文协议）：它像 USB-C，让 AI 能统一地连上各种工具——读代码、查数据库、调 API。但 MCP  deliberately 不回答另一个问题：Agent 和 Agent 之间怎么发现彼此、怎么分工？\n\nhttps:\u002F\u002Ffoundit.cn\u002Farticle\u002Fmcp-ai-usb-c-moment\n\n举个例子。你问一个「个人助理 Agent」：「帮我看看明天北京的天气，如果下雨就改到室内，并把会议邀约发给团队。」这个助理自己未必会看天气、也不该直接改所有人的日历。更合理的做法是：它去找到「天气 Agent」和「日历 Agent」，把子任务委派给它们，再把结果拼起来回答你。A2A（Agent-to-Agent Protocol，智能体到智能体协议）就是干这件事的标准。\n\n## A2A 是什么\n\nA2A 由 Google 在 2025 年 4 月提出，几个月后捐给 Linux 基金会，和 MCP 一样进入了中立治理。它的核心思想非常像现实中的名片交换：\n\n- 每个 Agent 都发布一张机器可读的 **Agent Card（名片）**，声明自己叫什么、能做什么、接受什么格式的输入、返回什么、需要怎样的鉴权。\n- 一个「编排 Agent」读到这些名片，就知道「这个任务该交给谁」。\n- 然后它通过 JSON + HTTP 协议把任务委派过去，支持长任务、流式结果和多轮对话。\n\n业界给的类比很精准：**MCP 连接 Agent 与工具，A2A 连接 Agent 与同伴。** 工具是被「调用」然后返回；同伴是被「委派」然后协商。\n\n2026 年 4 月，A2A 发布了 **1.0 版本**，成为稳定的生产标准，并带来了「带签名的 Agent Card」用于可验证身份。一年之内已有 150+ 组织在生成环境运行它，IBM 自家的 Agent Communication Protocol 也在 2025 年 8 月合并进了 A2A，没有让这一层 fragmentation（碎片化）。\n\n## 它是怎么运作的：发现 → 委派 → 交付\n\n整个协作流程可以拆成三步，用一张图就能看明白：\n\n```mermaid\nflowchart LR\n    U[用户需求] --> O[编排 Agent]\n    O -->|读取 Agent Card| C[天气 Agent]\n    O -->|读取 Agent Card| I[日历 Agent]\n    O -->|委派子任务| C\n    O -->|委派子任务| I\n    C --> R1[天气结果]\n    I --> R2[日程结果]\n    R1 --> O\n    R2 --> O\n    O --> A[汇总后回答用户]\n```\n\n落到代码层面，Agent Card 就是一份 JSON。比如一个天气 Agent 的名片可能长这样：\n\n```json\n{\n  \"name\": \"天气 Agent\",\n  \"description\": \"提供全球城市天气查询\",\n  \"url\": \"https:\u002F\u002Fweather-agent.example\u002Fa2a\",\n  \"capabilities\": { \"streaming\": true },\n  \"skills\": [\n    {\n      \"id\": \"get_weather\",\n      \"name\": \"查询天气\",\n      \"examples\": [\"北京今天天气如何？\"]\n    }\n  ],\n  \"authentication\": { \"schemes\": [\"Bearer\"] }\n}\n```\n\n编排 Agent 拉取这张名片后，就知道「查天气」这个技能由谁提供、去哪个地址调用、要带什么鉴权。它把用户问题拆成子任务，分别委派，再把各 Agent 的回包汇总成最终答案。长任务还能流式返回进度，不必干等。\n\n## 它能做什么，做不了什么\n\nA2A 解决的是「信封」问题——怎么发现同伴、怎么把任务送过去、怎么收回结果。但它有意**不定义「信封里写什么」**：两个 Agent 之间到底该用怎样的语义去沟通、任务怎么拆解，是高于协议层的事。\n\n- **强项**：跨厂商、跨框架。无论 Agent 是用 LangGraph、CrewAI、LlamaIndex 还是微软、谷歌的框架写的，只要都讲 A2A，就能互相委派。主流 agent 框架已原生支持。\n- **边界**：协议标准化的是「通信格式」，不是「协作智能」。任务拆得好不好、委派得对不对，仍然取决于编排 Agent 本身的设计。\n- **补充视角**：也有人提出基于 W3C 去中心化身份（DID）的替代方案，觉得 A2A 的模型「太像传统 Web」。但在企业多 Agent 系统里，A2A 已经是事实上的默认答案。\n\n## Tips\n\n- 记住分层：想接工具看 **MCP**，想让 Agent 互相协作看 **A2A**——两者互补，不是替代。\n- 设计多 Agent 系统时，先画清「谁发布名片、谁做编排、任务怎么拆」三件事，再选框架。\n- 评估一个 Agent 平台是否「能协作」，看它是否支持 A2A 1.0 与签名 Agent Card（身份可验证很重要）。\n- 别指望协议替你做任务规划：A2A 管「送信」，拆任务的逻辑要你自己写或交给编排模型。\n- 落地节奏上，先把 MCP 接好让单个 Agent 能干活，再用 A2A 把多个能干的 Agent 织成网络——这是 2026 年最主流的演进路径。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-19\u002F7819028f-dd6f-4988-9964-56134773dc53.jpg",[],[],"Foundit AI","https:\u002F\u002Ffoundit.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"0848beb4-db26-4fb8-b391-f852a11be192","AI编程","ai-coding",{"id":28,"name":29,"slug":30},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":32,"name":33,"slug":34},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",null,"published",false,75,0,"2026-07-17T00:00:00.000Z","2026-07-20T01:14:37.908Z","2026-07-19T16:17:09.511Z",[44,53,63],{"id":45,"type":6,"title":46,"slug":47,"summary":48,"coverUrl":49,"authorName":14,"sno":50,"publishedAt":51,"createdAt":52},"525e9d4d-50ba-48c4-be55-4810590d714b","AI Agent 可观测性：如何知道它到底在哪一步出错","genai-agent-observability-with-opentelemetry","Agent 的一次回答可能经过多次模型调用、检索、工具执行和重试。本文从日志、指标与 Trace 的分工讲起，介绍 OpenTelemetry 的 GenAI 语义约定、失败排查方法、敏感内容采集边界，以及如何把 AI 运行变成可解释的执行链路。","\u002Fuploads\u002F2026-08-05\u002F19586c04-7c5c-483a-8cdf-0860e7a03918.jpg",64,"2026-07-31T00:00:00.000Z","2026-08-05T02:13:45.344Z",{"id":54,"type":6,"title":55,"slug":56,"summary":57,"coverUrl":58,"authorName":59,"sno":60,"publishedAt":61,"createdAt":62},"7cc644a5-e0de-4d7b-802e-9e8b69677e12","AI 生成的代码会不会复制开源项目","ai-code-open-source-reference-license","AI 生成代码不等于天然没有来源。本文区分常见写法与高相似片段，解释代码引用、许可证、依赖供应链和轻量来源检查，帮助团队把合规当成代码质量的一部分。","\u002Fuploads\u002F2026-09-13\u002F920327ad-de7f-4caa-a2f4-816d467c9f9c.jpg","Foundit",40,"2026-09-13T00:00:00.000Z","2026-09-13T11:55:49.911Z",{"id":64,"type":6,"title":65,"slug":66,"summary":67,"coverUrl":68,"authorName":59,"sno":69,"publishedAt":70,"createdAt":71},"c85be666-a2ac-481a-a233-1d9aa7c5bfa1","AI 为什么会推荐不存在的 npm 包？","ai-hallucinated-dependencies-supply-chain","AI 可能把不存在或过时的依赖说得很像真的，甚至让开发者把陌生包安装进项目。本文解释依赖幻觉、恶意抢注、版本风险和安装前的供应链检查。","\u002Fuploads\u002F2026-09-14\u002F21c507cf-18e5-4b18-b71a-a501f6fb85c0.jpg",41,"2026-09-14T00:00:00.000Z","2026-09-14T11:00:01.589Z"]