├── .gitignore
├── 01-agentnetworkprotocol-technical-white-paper.md
├── 03-did-wba-method-design-specification.md
├── 06-anp-agent-communication-meta-protocol-specification.md
├── 07-anp-agent-description-protocol-specification.md
├── 08-ANP-Agent-Discovery-Protocol-Specification.md
├── 09-anp-peer-to-peer-agent-transaction-specification.md
├── CONTRIBUTING.cn.md
├── CONTRIBUTING.md
├── LICENSE
├── README.cn.md
├── README.md
├── blogs
├── ANP-Community-First-Meeting-A-Milestone-for-the-Agentic-Web.md
├── ANP-Presentation-at-W3C-WebAgents-CG.md
├── ANP-Presentation-at-W3C-WebAgents-cg.pdf
├── Agent-Impact-on-Infrastructure-Challenges-to-Existing-Connection-Infrastructure.md
├── Challenges-to-MCP-from-LangGraph-Lead-and-How-ANP-Addresses-Them.md
├── Comparing-the-Interaction-Modes-of-MCP-A2A-and-ANP.md
├── Comparison-of-Agent-Communication-Protocols.md
├── Comparison-of-MCP-and-ANP-What-Kind-of-Communication-Protocol-Do-Agents-Need.md
├── Comprehensive-Comparison-of-Google-A2A-ANP-MCP.md
├── In-depth-Comparison-of-Google-A2A-and-ANP-Finding-the-Origin-of-Protocols.md
├── In-the-year-that-the-ANP-was-born.md
├── One-Prompt-One-HTTP-Function-Enabling-Open-Source-Manus-to-Interact-with-Other-Agents-via-ANP.md
├── Ten-Questions-and-Answers-about-MCP.md
├── The-Birth-of-the-First-WebAgent-Designed-for-AI-Access.md
├── Three_Technical_Approaches_to_AI_Internet_Interaction.md
├── What-Makes-Agentic-Web-Different.md
├── analysis-and-predictions-of-future-ai-personal-assistant-products-and-key-players.md
├── anthropic-mcp-2025h1-milestone-analysis.md
├── cn
│ ├── 2025年ANP下一步规划的思考.md
│ ├── AI个人助手未来产品形态和主要玩家的分析与预测.md
│ ├── ANP协议要感谢的社区：web3、Agora、WebAgents.md
│ ├── ANP在W3C-WebAgents-CG的演讲.md
│ ├── ANP社区首次会议：这可能是一个新时代的起点.md
│ ├── LangGraph负责人对MCP的挑战，ANP是怎么解决的？.md
│ ├── MCP与ANP对比：智能体需要什么样的通信协议.md
│ ├── MCP十问十答.md
│ ├── agent对infra的改变-对连接基础设施的改变.md
│ ├── anthropic-mcp-2025h1-里程碑解读.md
│ ├── did-wba-基于web的去中心化身份标识符.md
│ ├── did-wba安全性原理解析.md
│ ├── did-wba对比openid-connect、api-keys.md
│ ├── 《微信背后的产品观》是否适合AI.md
│ ├── 一个提示词一个HTTP函数：让开源Manus通过ANP与其他智能体交互.md
│ ├── 从OpenAI的Operator，看AI与互联网交互的三种技术路线.md
│ ├── 但我们设计一个协议的时候，我们在设计什么.md
│ ├── 关于智能体身份的三个关键问题：互联互通、人类授权、隐私保护.md
│ ├── 多角度全面对比Google最新的A2A、ANP、MCP.md
│ ├── 我们对智能体互联网(agentic-web)的三个核心判断.md
│ ├── 智能体互联网有什么不同.md
│ ├── 智能体协议汇总.md
│ ├── 智能体通信协议对比.md
│ ├── 深入对比MCP、A2A、ANP的交互模式.md
│ ├── 深入对比谷歌A2A与ANP：找到协议的原点.md
│ └── 第一个专为AI访问而设计的WebAgent诞生了.md
├── comparison-of-did-wba-with-openid-connect-and-api-keys.md
├── did-wba-a-web-based-decentralized-identifier.md
├── did-wba-security-principles.md
├── images
│ ├── OAuth2.1.svg
│ ├── a2a-id-auth.png
│ ├── a2a-partners.png
│ ├── agent-interview-Internet.png
│ ├── agentic-web.png
│ ├── ai-native-network.png
│ ├── all-protocol-1.png
│ ├── all-protocol-2.png
│ ├── anp-architecture.png
│ ├── anp-authorization.png
│ ├── anp-data-network.png
│ ├── anp-did-auth.png
│ ├── anp-email.png
│ ├── anp-explorer.png
│ ├── anp-first-meet
│ │ ├── 00.png
│ │ ├── 01.png
│ │ ├── 02.png
│ │ ├── 03.png
│ │ ├── 04.png
│ │ ├── 05.png
│ │ ├── 06.png
│ │ ├── 07.png
│ │ └── 08.png
│ ├── anp-in-w3c-20250214
│ │ ├── page1.jpg
│ │ ├── page10.jpg
│ │ ├── page11.jpg
│ │ ├── page12.jpg
│ │ ├── page13.jpg
│ │ ├── page14.jpg
│ │ ├── page15.jpg
│ │ ├── page16.jpg
│ │ ├── page17.jpg
│ │ ├── page18.jpg
│ │ ├── page19.jpg
│ │ ├── page2.jpg
│ │ ├── page20.jpg
│ │ ├── page21.jpg
│ │ ├── page22.jpg
│ │ ├── page23.jpg
│ │ ├── page24.jpg
│ │ ├── page3.jpg
│ │ ├── page4.jpg
│ │ ├── page5.jpg
│ │ ├── page6.jpg
│ │ ├── page7.jpg
│ │ ├── page8.jpg
│ │ └── page9.jpg
│ ├── anp-interaction-flow.png
│ ├── api-keys-flow.png
│ ├── asymmetric-encryption.mmd
│ ├── auth-flow.mmd
│ ├── computer-use-product.png
│ ├── data-silos.png
│ ├── did-wba-auth.png
│ ├── did-wba-flow.png
│ ├── first-web-agent.png
│ ├── human-ai-agent.png
│ ├── mcp-anp-share
│ │ └── protocol-explanation.svg
│ ├── mcp-architecture.png
│ ├── mcp-authorization.png
│ ├── mcp-http-sse.png
│ ├── mcp-init.png
│ ├── mcp-server-api-key-example.png
│ ├── mcp-tools.png
│ ├── mcp-usb.png
│ ├── mcp-vs-anp-core.png
│ ├── mcp-vs-anp.png
│ ├── mcp-wba-did-proposal.png
│ ├── meta-protocol-flow.png
│ ├── openid-connect-fllow.png
│ └── user-agent-internet.png
├── the-three-major-trends-of-the-internet-of-agents.md
└── three-key-issues-of-agent-identity-interoperability-human-authorization-and-privacy-protection.md
├── chinese
├── 01-AgentNetworkProtocol技术白皮书.md
├── 03-did-wba方法规范.md
├── 06-ANP-智能体通信元协议规范.md
├── 07-ANP-智能体描述协议规范.md
├── 08-ANP-智能体发现协议规范.md
├── 09-ANP-智能体点对点交易规范.md
├── deprecated
│ ├── 00-AgentNetworkProtocol技术蓝图(20241204).md
│ ├── 01-AgentNetworkProtocol技术白皮书(20041204).md
│ └── 02-did-all方法规范.md
├── docs
│ └── did-wba服务端测试接口.md
├── message
│ ├── 04-基于did的端到端加密通信技术协议.md
│ └── 05-基于did的消息服务协议.md
├── 参考资料
│ ├── paper&规范.md
│ └── 语义网
│ │ ├── Linked-Data.md
│ │ ├── Semantic-Web-Road-map.md
│ │ ├── The-Next-Web-TimBerners-Lee.md
│ │ └── semantic-web.md
├── 思考&问题
│ ├── atproto-vs-anp.md
│ ├── pic
│ │ ├── agent-find.png
│ │ ├── mcp-architecture.png
│ │ ├── mcp-auth-thinking.png
│ │ ├── meta-protocol-flow.png
│ │ ├── meta-protocol-weather.png
│ │ └── protocol-layer-design.png
│ ├── 其他
│ │ ├── share-ppt.md
│ │ └── 介绍did-wba.md
│ ├── 协议与技术对比
│ │ ├── http与ANP.md
│ │ ├── mcp-vs-anp.md
│ │ └── 整体通俗介绍文章.md
│ ├── 智能体网络与通信
│ │ ├── E2E类似项目.md
│ │ ├── 价值思考.md
│ │ ├── 元协议思考.md
│ │ ├── 智能体发现与描述.md
│ │ └── 智能体网络的特点.md
│ ├── 语义网与智能体研究
│ │ └── 语义网研究.md
│ └── 身份认证与加密
│ │ ├── MCP-wba-commit.md
│ │ ├── did-vs-other.md
│ │ ├── did.md
│ │ ├── 加密思考.md
│ │ └── 秘钥泄漏问题.md
├── 相关产品与技术
│ ├── ANP-VS-IETF.MD
│ ├── ANP论文汇总.md
│ ├── agent-discovery.svg
│ ├── 相关开源项目.md
│ └── 相关标准.md
└── 过程文档
│ └── 智能体点对点交易方案设计
│ ├── ANP-VC哈希链关系图.svg
│ ├── ANP-理想交易流程图-v2.svg
│ ├── ANP-系统架构图.svg
│ ├── OpenAI-智能体点对点交易流程&协议设计 copy.md
│ └── 智能体点对点交易流程&协议设计-通俗版.md
├── deprecated
├── 00-agentnetworkprotocol-technical-blueprint.md
├── 01-agentnetworkprotocol-technical-white-paper(20041204).md
└── 02-did-all-method-design-specification.md
├── docs
├── anp-getting-started-guide.md
├── chinese
│ ├── ANP入门指南.md
│ ├── ANP示例程序.md
│ ├── community-operations
│ │ └── operations-cn.md
│ ├── links.md
│ ├── roadmap
│ │ └── roadmap-and-todo-202504.md
│ └── 基于ANP的WebAgent如何运行.md
├── community-operations
│ └── community-operations.md
├── did-wba-server-test-interface.md
├── did-wba入门指南.md
├── how-anp-based-webagent-works.md
└── links.md
├── examples
└── adp
│ ├── hotel
│ └── examples
│ │ ├── ad.json
│ │ ├── api
│ │ ├── booking-interface.yaml
│ │ ├── nl-interface.yaml
│ │ └── search-interface.yaml
│ │ └── hotel_room.json
│ └── lkcoffe
│ ├── ad.json
│ ├── api
│ ├── nl-interface.yaml
│ └── purchase-interface.yaml
│ ├── orange-americano
│ ├── instruction.jpg
│ └── orange-americano.json
│ ├── roasted-coconut-latte
│ ├── instruction.jpeg
│ └── roasted-coconut-latte.json
│ └── silk-latte
│ ├── instruction.jpg
│ └── silk-latte.json
├── images
├── Internet.png
├── agent-a-call-agent-b.png
├── agent-connect-architecture.png
├── agent-discovery-protocol.svg
├── agent-discovery.svg
├── agent-network-diagram.svg
├── agentic-web-new.svg
├── agentic-web3.png
├── ai-native-network.png
├── anp-architecture.png
├── anp-flow.png
├── anp-human-agent-authorization.svg
├── anp-identity-interop.svg
├── anp-meta-protocol.svg
├── cross-platform-authentication.png
├── cross-platform-identity-authentication-process.png
├── did-all-core-flow.png
├── did-architecture.png
├── did-as-identity-bridge.png
├── did-identity-authentication.png
├── end-to-end-encryption-process.png
├── judgment1_agent_replace_software.svg
├── judgment2_interconnected_agents.svg
├── judgment3_protocol_connection.svg
├── message-did-register-flow.png
├── message-flow-architecture.png
├── message-send-receive-flow.png
├── meta-protocol-communication.png
├── multi-did-privacy.svg
├── protocol-layer-design.png
└── relationship.png
├── message
├── 04-end-to-end-encrypted-communication-technology-protocol-based-on-did.md
└── 05-message-service-protocol-based-on-did.md
├── references
└── did_web-method-specification.html
└── scripts
├── add_copyright.py
├── rename_images.py
└── replace_spaces_with_hyphens.py
/.gitignore:
--------------------------------------------------------------------------------
1 | venv
2 | code
3 | media/
4 |
--------------------------------------------------------------------------------
/CONTRIBUTING.cn.md:
--------------------------------------------------------------------------------
1 | # 贡献指南
2 |
3 | 感谢您对本项目感兴趣！我们非常欢迎来自社区的贡献。
4 |
5 | ## 谁可以贡献
6 |
7 | 我们热烈欢迎以下群体参与项目：
8 | - 对网络技术有研究的开发者
9 | - 对协议设计和实现感兴趣的工程师
10 | - 从事相关软件研发的企业
11 | - 高校和研究机构的研究人员
12 | - 其他对本项目感兴趣的贡献者
13 |
14 | ## 贡献流程
15 |
16 | ### 1. 前期讨论
17 | 在开始编写文档之前，我们建议您：
18 | - 在 GitHub Issues 中提出您的想法
19 | - 在我们的 Discord 社区中与其他开发者讨论
20 | - 充分收集社区反馈，确保方案可行
21 |
22 | ### 2. 提交 Pull Request
23 | - 请确保您的文档符合项目规范
24 | - 提供清晰的 PR 描述，说明改动的目的和实现方式
25 | - 如果 PR 关联某个 Issue，请在描述中注明
26 |
27 | ### 3. 文档审查
28 | - 我们会尽快审查您的 PR
29 | - 必要时会邀请相关领域的开发者一起参与讨论
30 | - 可能会要求您进行一些修改或优化
31 |
32 | ## 联系我们
33 |
34 | 如果您有任何问题，欢迎通过以下方式联系：
35 | - GitHub Issues：[https://github.com/agent-network-protocol/AgentNetworkProtocol/issues](https://github.com/agent-network-protocol/AgentNetworkProtocol/issues)
36 | - Discord 社区：[https://discord.gg/sFjBKTY7sB](https://discord.gg/sFjBKTY7sB)
37 |
38 | 再次感谢您对项目的关注与支持！
39 |
40 | ## 版权声明
41 | Copyright (c) 2024 GaoWei Chang
42 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
43 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # Contribution Guide
2 |
3 | Thank you for your interest in this project! We warmly welcome contributions from the community.
4 |
5 | ## Who Can Contribute
6 |
7 | We enthusiastically welcome the following groups to participate in the project:
8 | - Developers with research in network technology
9 | - Engineers interested in protocol design and implementation
10 | - Companies engaged in related software development
11 | - Researchers from universities and research institutions
12 | - Other contributors interested in this project
13 |
14 | ## Contribution Process
15 |
16 | ### 1. Preliminary Discussion
17 | Before you start writing documentation, we recommend that you:
18 | - Propose your ideas in GitHub Issues
19 | - Discuss with other developers in our Discord community
20 | - Collect sufficient feedback from the community to ensure the feasibility of the solution
21 |
22 | ### 2. Submit a Pull Request
23 | - Ensure your documentation complies with project standards
24 | - Provide a clear PR description explaining the purpose and implementation of the changes
25 | - If the PR is related to an issue, please mention it in the description
26 |
27 | ### 3. Documentation Review
28 | - We will review your PR as soon as possible
29 | - If necessary, we will invite developers from relevant fields to participate in the discussion
30 | - You may be asked to make some modifications or optimizations
31 |
32 | ## Contact Us
33 |
34 | If you have any questions, feel free to contact us through the following channels:
35 | - GitHub Issues: [https://github.com/agent-network-protocol/AgentNetworkProtocol/issues](https://github.com/agent-network-protocol/AgentNetworkProtocol/issues)
36 | - Discord Community: [https://discord.gg/sFjBKTY7sB](https://discord.gg/sFjBKTY7sB)
37 |
38 | Thank you again for your attention and support for the project!
39 |
40 | ## Copyright Notice
41 | Copyright (c) 2024 GaoWei Chang
42 | This file is released under the [MIT License](./LICENSE). You are free to use and modify it, but you must retain this copyright notice.
43 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2024 GaoWei Chang
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
23 | This license applies only to the source code of this project. Any trademarks, logos, or other assets in this repository are the property of GaoWei Chang and may not be used without permission.
24 |
--------------------------------------------------------------------------------
/README.cn.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | [English](README.md) | [中文](README.cn.md)
4 |
5 |
6 |
7 | ## AgentNetworkProtocol(ANP)
8 |
9 | > TL;DR: ANP 致力于成为智能体互联网时代的 HTTP。
10 |
11 |
12 | ### 目录
13 | - [愿景定位](#愿景定位)
14 | - [为什么需要 ANP](#为什么需要-anp)
15 | - [协议三层架构](#协议三层架构)
16 | - [快速上手](#快速上手)
17 | - [代码实现](#代码实现)
18 | - [深入阅读](#深入阅读)
19 | - [里程碑](#里程碑)
20 | - [联系我们](#联系我们)
21 | - [贡献](#贡献)
22 | - [许可证](#许可证)
23 |
24 | ## 愿景定位
25 |
26 | AgentNetworkProtocol(ANP)是一个开源的智能体通信协议。
27 |
28 | AgentNetworkProtocol(ANP)的目标是成为**智能体互联网时代的HTTP**。
29 |
30 | 我们的愿景是**定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络**。
31 |
32 |
33 | 
34 |
35 |
36 | 我们相信，智能体互联网是继人类互联网之后的新一代信息基础设施，将彻底改变数字世界的连接方式与协作模式。在这个愿景中：
37 |
38 | - **从平台中心到协议中心**：当前互联网生态系统是以平台为中心的模式，数据和服务被锁在"数字孤岛"中。智能体互联网将重塑这种不平衡格局，让互联网从封闭、碎片化的状态，回归开放、自由连接的本源。
39 |
40 | - **连接即力量**：在真正开放、互联的网络中，节点间的自由交互能最大限度激发创新潜力并创造巨大价值。未来每个智能体都将同时是信息消费者和服务提供者，每个节点都能无障碍地发现、连接并与网络中任何其他节点交互。
41 |
42 | - **AI原生网络**：不同于为人类设计的网页与界面，智能体互联网将构建一个面向AI友好的原生数据网络，所有节点都是可描述、可发现、可调用的智能体或数据单元，每个链接都是语义明确、结构统一的协议连接。
43 |
44 | 这个愿景需要一个类似HTTP之于人类互联网的基础协议——这正是ANP诞生的原因。
45 |
46 | **备注**：本项目未在任何平台、任何区块链发布数字货币。
47 |
48 | ## 为什么需要 ANP
49 |
50 | 当前互联网基础设施虽已相当完善，但针对智能体网络的特殊需求，当下仍缺乏最适合的通信和连接方案。我们致力于解决智能体网络面临的三大挑战：
51 |
52 | - 🌐 **互联互通**：让所有的智能体相互之间都能够进行通信，打破数据孤岛，让AI能够获得完整的上下文信息。
53 | - 🖥️ **原生接口**：AI无需模仿人类访问互联网，AI应该用它最擅长的方式（API或通信协议）与数字世界交互。
54 | - 🤝 **高效协作**：利用AI，智能体之间可以自组织、自协商，构建比现有互联网更低成本、更高效率的协作网络。
55 |
56 | ## 协议三层架构
57 |
58 |
59 | 
60 |
61 |
62 | - 🔒 **身份与加密通信层**：基于W3C DID（Decentralized Identifiers，去中心化标识符）规范，在现有成熟的Web基础设施上，构建一个去中心化的身份认证方案和端到端加密通信方案。它可以让任意平台之间的智能体进行身份认证，而不依赖于任何中心化系统。
63 | - 🌍 **元协议层**：元协议即协商智能体之间通信协议的协议。是智能体网络演进为自组织、自协商的高效协作网络的关键。
64 | - 📡 **应用协议层**：基于语义网相关规范，让智能体能够描述其他能力与支持的应用协议，并且高效的管理这些协议。
65 |
66 | ## 快速上手
67 |
68 | 如果你想快速了解ANP的基本概念和使用方法，可以查看我们的入门指南：[ANP入门指南](docs/chinese/ANP入门指南.md)
69 |
70 | 如果你想快速的运行ANP相关demo，可以查看我们的示例程序说明文档：[ANP示例程序](docs/chinese/ANP示例程序.md)
71 |
72 | ## 协议SDK
73 |
74 | 我们正在开发一个开源的 AgentNetworkProtocol 实现，仓库地址：[https://github.com/agent-network-protocol/AgentConnect](https://github.com/agent-network-protocol/AgentConnect)
75 |
76 | ## 深入阅读
77 |
78 | - 完整资料见 [拓展阅读](docs/links.md)
79 | - 查看详细设计请阅读 [ANP 技术白皮书](chinese/01-AgentNetworkProtocol技术白皮书.md)
80 | - 协议开源实现 [AgentConnect 示例](https://github.com/agent-network-protocol/AgentConnect)
81 |
82 | ## 里程碑
83 |
84 | 无论是协议还是开源代码实现，我们整体式是按照以下的顺序逐步的推进：
85 |
86 | - [x] 构建身份认证与端到端加密通信协议与实现。这是我们整个项目的基础与核心，当前协议设计和代码基本完成。
87 | - [x] 元协议设计与元协议代码实现。当前协议设计和代码开发基本完成。
88 | - [x] 应用层协议设计与开发。
89 | - [x] 支持智能体描述。
90 | - [x] 支持智能体发现。
91 | - [ ] 特定领域使用的应用协议设计
92 |
93 | ## 联系我们
94 |
95 | 我们已经成立了一个ANP开源技术社区，以开源社区的方式推进ANP的建设。诚挚的邀请您加入我们的开源技术社区，我们的创始委员会、社区顾问、技术委员会、发展委员会、企业观察员等团队持续招募中。
96 |
97 | 邮箱：chgaowei@gmail.com
98 | - Discord: [https://discord.gg/sFjBKTY7sB](https://discord.gg/sFjBKTY7sB)
99 | - 官网：[https://agent-network-protocol.com/](https://agent-network-protocol.com/)
100 | - GitHub：[https://github.com/agent-network-protocol/AgentNetworkProtocol](https://github.com/agent-network-protocol/AgentNetworkProtocol)
101 | - 微信：flow10240
102 |
103 | ## 贡献
104 |
105 | 我们欢迎任何形式的贡献，请参考 [CONTRIBUTING.cn.md](CONTRIBUTING.cn.md) 文件。
106 |
107 | ## 许可证
108 |
109 | 本项目基于 MIT 许可证开源，详情请参考 [LICENSE](LICENSE) 文件。但版权归属于常高伟（GaoWei Chang）。任何使用本项目的用户必须保留原始版权声明和许可证文件。
110 |
111 | ## 版权声明
112 | Copyright (c) 2024 GaoWei Chang
113 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
114 |
--------------------------------------------------------------------------------
/blogs/ANP-Presentation-at-W3C-WebAgents-cg.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/ANP-Presentation-at-W3C-WebAgents-cg.pdf
--------------------------------------------------------------------------------
/blogs/Ten-Questions-and-Answers-about-MCP.md:
--------------------------------------------------------------------------------
1 |
2 | # Ten Questions and Answers about MCP
3 |
4 | ## Preface
5 |
6 | During discussions, it became apparent that many people are not very familiar with MCP. Therefore, I quickly compiled this article to give you an overall understanding.
7 |
8 | ## Bonus Question: What is MCP?
9 |
10 | MCP (Model Context Protocol) is an open protocol designed to standardize the interaction between large language models (LLMs) and external data sources, tools, and services.
11 |
12 | Originally developed by Anthropic, it is now open source.
13 |
14 | ## Question 1: What does the 'P' in MCP stand for?
15 |
16 | 'P' stands for Protocol, which refers to a network protocol. Common examples include TCP/IP and HTTP, which are types of network protocols.
17 |
18 | Network protocols define how two parties establish a connection, send data, define data formats, and handle errors.
19 |
20 | MCP is a network protocol that defines the network communication data format for integrating AI models with external data sources and tools, including the transmission protocol, data format definition, and authentication methods.
21 |
22 | ## Question 2: What problem does MCP solve?
23 |
24 | MCP addresses the fragmentation issue of integrating large language models with external data sources and tools. By providing a standardized interface, MCP enables AI applications to connect more reliably and efficiently to different data sources and tools, avoiding the hassle of developing a connector for each data source.
25 |
26 | Simply put, a tool using the MCP protocol can be used by both Claude and cursor without needing to be developed twice.
27 |
28 | ## Question 3: Where does MCP fit in?
29 |
30 | MCP sits between models and tools/resources. Models call functions through function calling, and these functions interact with external tools/resources via the MCP protocol.
31 |
32 | ## Question 4: Was MCP developed by Anthropic, and can other models use it?
33 |
34 | Yes.
35 |
36 | Although MCP was developed by Anthropic, it is an open protocol that any model can use. It is independent of the model. If a model's tool usage capability is weak, using MCP will not enhance it.
37 |
38 | ## Question 5: What is the difference between MCP and function calling?
39 |
40 | They are not the same concept.
41 |
42 | Function calling is the interaction method between large models and the external digital world. MCP is the interaction method between the MCP host (chatbot or AI tool) and external tools/resources.
43 |
44 | Generally, a model first triggers a function call through function calling, which then triggers an MCP request within that function call.
45 |
46 | ## Question 6: How does MCP differ from previous OpenAI plugins?
47 |
48 | They are very similar, but MCP is more standardized than previous plugins, with clear definitions for data formats, transmission protocols, authentication methods, and stronger capabilities.
49 |
50 | ## Question 7: What is the difference between MCP and GPTs?
51 |
52 | GPTs are more like an application marketplace, currently designed for human use.
53 |
54 | GPTs might be similar to the marketplace of an MCP server, but the MCP server is mainly for AI use, not directly for humans.
55 |
56 | ## Question 8: Will MCP become a standard?
57 |
58 | In the short term, MCP has no competitors in integrating external resources and tools with models, and its ecosystem is growing.
59 |
60 | However, it is uncertain whether OpenAI will support it or create its own standard. If they do, it must be better designed than MCP, or they will be criticized for creating a "walled garden."
61 |
62 | In the long term, MCP has some design issues, such as complexity, client-server coupling, and distributed identity authentication, which need to be addressed.
63 |
64 | ## Question 9: Should we adopt MCP?
65 |
66 | From a technical perspective, if used internally, you need to balance flexibility and cost. Internally, you can do whatever is most efficient; MCP may not be the optimal solution. However, if it involves interfacing with external (e.g., public network) tools, it's best to use a widely recognized protocol.
67 |
68 | ## Question 10: Will domestic internet platforms adopt MCP?
69 |
70 | Platforms like Meituan, Didi, Taobao, and Pinduoduo are unlikely to adopt it in the short term. They won't create an upstream for themselves.
71 |
72 | It's similar to when Taobao cut off traffic from Baidu and WeChat.
73 |
74 | ## Bonus Question: Is MCP suitable for agents?
75 |
76 | MCP is not designed for agents; it is designed for models to connect with external resources and tools.
77 |
78 | Several issues remain unresolved, such as MCP's centralized identity authentication technology, which is not suitable for agent-to-agent authentication. MCP's CS architecture (client-server architecture) means the server cannot actively connect to the client.
79 |
80 | If there is a need for agent connections, you can try our ANP, which is specifically designed for agents.
81 |
82 | ## Contact Us
83 |
84 | If you are interested in this topic, feel free to contact us.
85 |
86 | The goal of AgentNetworkProtocol is to become the HTTP of the agent internet era. Our vision is to define the connection methods between agents and build an open, secure, and efficient collaboration network for billions of agents.
87 |
88 | The ANP open-source technology community currently has 25 developers and is recruiting more. If you are interested in agent communication protocols, whether in development, product, or operations, you can join us to define agent connections and collaboration through open source.
89 |
90 | Contact Information:
91 | - GitHub: https://github.com/agent-network-protocol/AgentNetworkProtocol
92 | - Discord: https://discord.gg/sFjBKTY7sB
93 | - Website: https://agent-network-protocol.com/
94 | - WeChat: flow10240
95 |
96 | Finally, welcome to join the agent communication protocol discussion group. This might be the first group in China to discuss agent communication protocols, with over 200 protocol enthusiasts currently engaged in discussions. (Add me on WeChat to join)
97 |
--------------------------------------------------------------------------------
/blogs/cn/2025年ANP下一步规划的思考.md:
--------------------------------------------------------------------------------
1 | 1. 支持更多的平台
2 |
3 | 2. 目前主要是云端，未来要不要做浏览器的支持？
4 |
5 | 3. 支持双向连接
6 |
7 | 4. 支持消息和端到端加密
8 |
9 | 5. 支持支付
10 |
11 | 6. 编写更多的协议示例
12 |
13 | 7. AD描述文档
14 |
15 | 8. 协议管理、协议的定义（通过URI来标注协议）
16 |
17 | 9. 支持websocket?
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
--------------------------------------------------------------------------------
/blogs/cn/ANP协议要感谢的社区：web3、Agora、WebAgents.md:
--------------------------------------------------------------------------------
1 | # ANP协议诞生的这一年，感谢社区：web3、Agora Protocol、WebAgents、did:web
2 |
3 | ANP开源项目从构思、开发，到现在已经接近一年的时间了。这一年我大部分精力都专注在这个开源项目中，去年更是从阿里离职，全职投入。
4 |
5 | 创业不容易，在融资环境这么差没有拿到钱的情况下，坚持做开源项目更加不容易。这里容许我佩服一下我自己，**在一年之前提前看到了未来，并且能够坚持下来。**
6 |
7 | 能够坚持下来当然不是因为我有韧性，而是因为这个过程很有趣。事情本身有趣，再加上开源社区的氛围，和全球开发者沟通交流，我最近一年的身体状态和心理状态比在阿里的时候更加的好。（只有钱包不满意）
8 |
9 | **做自己感兴趣的事情，事情本身会滋养你的身体和心理。**
10 |
11 | 今天主要和大家分享一下ANP诞生的全过程，以及在这个过程中要感谢的社区。
12 |
13 | 最近越来越明显地感觉到，我们所看到的互联网未来的画面，正被越来越多的人所认同。我们也受到了越来越多的正反馈，也有越来越多的开源爱好者、同行者加入了我们开源社区。
14 |
15 | ANP现在谈不上完美，我现在还有很多想法与规划，等待着去完善与实施。但是它已经是智能体通信协议当中一股重要的力量，我们**代表了一条技术路线（Agentic web + 去中心化 + 语义网）**，并且在这条技术路线上，我们的探索一直在行业的最前沿。
16 |
17 | ## 起源
18 |
19 | ANP起源于一个非常小的疑问（我原有的工作与音视频关系密切）：**人如何使用个人助手进行视频会议？** 曾经有段时间，这个问题一直在大脑中挥之不去，压制不住。
20 |
21 | 深入研究之后，我发现行业智能体连接与协作上，还存在着巨大的技术空白。当前的技术是无法满足智能体的需求的，智能体需要更加原生的连接方式：所有智能体都能够互联互通、直接使用底层数据交互。
22 |
23 | 正式沿着这个路线进行思考、设计，才有了ANP协议。
24 |
25 | 在整个设计的过程中，ANP也经过了一次大的重构，并且吸收了其他社区的优秀思想。
26 |
27 | ## web3
28 |
29 | 第一个对ANP产生重大影响的是web3社区。
30 |
31 | 我是在2022年，因为我非常认同个人数据主权的理念，我业余时间研究了web3，和很多web3从业者做过深入的交流。
32 |
33 | 在web3社区，我学习了区块链的技术，了解到了去中心化背后的理念与技术，后面又接触到了DID的概念，以及W3C的DID标准。还有很多非常有意思的协议比如Nostr、AT Protocol、Lens Protocol等。
34 |
35 | 去中心化也是ANP的核心理念，我们追求的不是区块链这样完全去的中心化，而是用于智能体身份互操作的整体去中心化、局部中心化思路。
36 |
37 | W3C DID也是我们智能体身份的最底层技术，也是我们认为当下最适合智能体身份的技术。
38 |
39 | 最后说下web3社区。
40 |
41 | web3虽然离钱很近、离用户有点远，但是web3有一套完全区别于web2（传统互联网）的价值观、世界观、技术体系，而且这些东西非常的有意思。
42 |
43 | 同时web3社区氛围也非常的开放，我非常喜欢web3的builder文化。还有DAO的组织方式，以及token的激励机制。这些都非常的有意思，对我设计ANP有很多影响与启发。
44 |
45 | ## Agora Protocol
46 |
47 | 第二个要感谢的是Agora Protocol。
48 |
49 | Agora Protocol是牛津大学一个团队和Camel AI一起开发的一个元协议技术，可以用于智能体之间协议的协商。
50 |
51 | 因为我一直从事协议相关工作，我很早也意识到了AI对协议协商、联调的影响，不过一直没有系统的研究过。
52 |
53 | 受Agora Protocol的启发，在更深入的思考之后，我正式形成了ANP的三层架构设计：身份与加密层、元协议层、应用协议层。
54 |
55 | 这个三层架构一直沿用至今，并且不断的补充完善。
56 |
57 | 我们元协议层在实现上主要参考的就是Agora Protocol的论文，并且结合我们在通信协议上的经验做了工程优化。
58 |
59 | 后来我与Agora Protocol的作者、牛津大学的smarro，以及Camel AI的创始人李国豪，都进行过智能体通信协议方面的技术交流。最近smarro牵头组建了一个工作组，致力于智能体通信协议的标准化，我们是主要参与者之一。
60 |
61 | ## WebAgents
62 |
63 | 第三个要感谢的是WebAgents。
64 |
65 | WebAgents是我们社区海外的一个同学James推荐给我的。
66 |
67 | WebAgents主要是基于语义网技术，构建基于Web的多智能体系统（MAS）。我大量的翻阅了WebAgents社区的资料，特别是他们的会议记录，从里面获得了很多关于语义网的线索。
68 |
69 | 然后我系统的研究了语义网的起源，特别是万维网发明人Tim Berners-Lee关于语义网的文章，以及语义网相关的标准，包括json-ld、rdf、owl等。
70 |
71 | 语义网是一个非常有意思的概念，如果你看过Tim Berners-Lee 2001年在《科学美国人》上发表的关于语义网的文章，你一定会觉得他是一个非常有远见的人，里面描述的场景，正是我们现在设想的智能体普及之后的场景。
72 |
73 | 只是受限于以前AI的技术水平，语义网走了数据标注这个技术路线，注定无法真正地实现语义网设想的美好场景。而后来，互联网走向了更加封闭的移动互联网时代。
74 |
75 | 但是语义网遗留下来的技术，我认为可以很好的被用来做智能体之间的通信。它通过预先定义的语义，让不同智能体之间对一个数据有一致的理解。这可以很好的解决智能体使用自然语言通信的歧义问题。
76 |
77 | 这也是我们在智能体描述协议上核心技术选择。
78 |
79 | ## did:web
80 |
81 | 第四个要感谢的是did:web。
82 |
83 | did:web是W3C的DID的一个方法实现，它使用web技术，实现去中心化的身份，整体技术可以实现类似email的效果：全局是去中心化的，互操作性强，内部是中心化的，可以支撑数十亿用户。
84 |
85 | 我们最早采用的DID方法是did:all，这是一种类似比特币地址的、自验证的DID方法。它也基于web实现，但是我们的方法有一个致命的问题一直没有很好的解法：DID对应的私钥丢失后恢复问题。感兴趣的同学可以看下我们废弃文档中的备份。
86 |
87 | 后来我接触到了did:web的设计，它很好地解决了DID私钥丢失后的恢复问题，并且整体设计思路和我们非常类似。
88 |
89 | 所以，我们切换到了did:web的方案，同时增加了关于智能体的支持，比如添加智能体描述、智能体身份隐私保护、智能体身份的人类授权等，我们提出了一个新的方法did:wba(web-based agent)。
90 |
91 | 我在推特上也与did:web的作者做过沟通，未来我希望我们两个方法能够融合到一起。
92 |
93 | ## 开源与社区
94 |
95 | ANP协议和关键的代码实现，都是MIT license，并且永远会保持MIT license。
96 |
97 | 我们在ANP的设计过程中，大量的吸收了开源社区的优秀成果，同时我们也希望能够回馈给开源社区。
98 |
99 | 我们认为，**一个封闭的协议是没有前途的，一个没增量价值的开源是没有意义的。**
100 |
101 | 在参与开源与建设社区的过程中，我看到了开源的力量与价值，我们也非常希望有更多的开发者、社区、公司能够参与到ANP社区的建设中来。
102 |
103 | ## 联系方式
104 |
105 | AgentNetworkProtocol的目标是成为智能体互联网时代的HTTP协议。
106 |
107 | 我们的愿景是定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络。
108 |
109 | 如果您对智能体通信协议感兴趣，欢迎加入开源社区，共同定义智能体之间的连接方式，探索Agentic Web的未来。
110 |
111 | 联系方式：
112 |
113 | - Discord: https://discord.gg/sFjBKTY7sB
114 | - 官网：https://agent-network-protocol.com/
115 | - GitHub：https://github.com/agent-network-protocol/AgentNetworkProtocol
116 | - 微信：flow10240
117 | - 邮箱：chgaowei@gmail.com
118 |
119 |
120 |
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
139 |
140 |
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 |
151 |
--------------------------------------------------------------------------------
/blogs/cn/ANP社区首次会议：这可能是一个新时代的起点.md:
--------------------------------------------------------------------------------
1 | # ANP社区首次会议：这可能是智能体互联网的一个里程碑
2 |
3 | 昨天刚刚开了ANP社区的第一次会议。
4 |
5 | 如果说ANP，或者说我们社区描述的智能体互联网，在未来成为现实，那么，今天的这次会议是否会成为智能体互联网的一个里程碑？
6 |
7 | 会议开完之后，能够感受到大家对我们所做事情的热情和期待，超出我的预期，也让我有点激动。
8 |
9 | 
10 |
11 | ## 会议内容
12 |
13 | 回到正文。给大家讲一下我们首次社区会议的内容。
14 |
15 | 
16 |
17 | 今天我重点讲两件事情：社区原则、运营制度初稿，以及社区进展、下一步计划的同步。
18 |
19 | 
20 |
21 | 首先，社区的核心原则有5点（初稿）：
22 |
23 | 1. **开放、中立**
24 |
25 | 技术中立，开放共享。这是ANP社区的基石，也是社区最核心的原则。作为给协议类开源项目，特别是社区发起的协议类开源项目，我们必须坚持开放、中立的原则，否则这个协议是没有生命力的。
26 |
27 | 我们要对所有的公司保持开放，同时，我们也不能偏向任何一家公司，我们的目标始终是为了找到智能体互联网运行的最佳方案。
28 |
29 | 2. **BIP**
30 |
31 | 坚持BIP(Build In Public)原则，社区构建保持100%透明，并且，不单是结果透明，过程也要透明。
32 |
33 | 所有的思考过程、所有的决策过程，谁赞同，谁反对，反对原因，必须是公开透明的。
34 |
35 | 把一切放到桌面上。
36 |
37 | 3. **社区永远不做商业化**
38 |
39 | 社区后面会考虑加入开源基金会进行孵化，来维持社区的运行。不过主要还是依赖社区成员的贡献。
40 |
41 | 4. **社区治理权来自贡献**
42 |
43 | 社区的治理权来自于贡献，而不是来自于背景、资历、名气。
44 |
45 | 5. **鼓励反对，实名负责**
46 |
47 | 鼓励不同意见，但是反对需要实名，并且给出原因，所有人可见。这是和W3C同学聊天，学到的W3C运行的一些方法，挺不错。
48 |
49 |
50 | 
51 |
52 | 社区当前一个重要的目标是运营走向正轨，为此我们成立了一个临时委员会：创始委员会，它可能只存在6个月的时间，等技术委员会成立后，创始委员会将退出历史舞台，不再参与社区治理。但是会为每位委员保留title，以感谢他们的贡献。
53 |
54 | 创始委员会目前组建的方法是推荐 + 邀请 + 过半同意，**核心的要求是愿意持续贡献**。当前已经有多位委员就绪并投入工作中。
55 |
56 | 技术委员会是未来一个重要的委员会，如何运行，还在不断的完善中。但是有一个核心的要求，就是**委员必须是持续的贡献者**。
57 |
58 | 关于社区决策，早期**为了提高运营效率，我会利用我的影响力进行快速决策**，以适应AI快速发展的现状。但是更长期，我希望即便是我退出社区，社区也能够正常的运行。
59 |
60 | 
61 |
62 | 对于愿意参与社区建设，但是没有大块时间的人士，我们设置了社区顾问一职。社区顾问平时可以根据自己时间，参与社区运营，提出自己的建议。在社区有需要的时候，也会定向咨询相关问题。
63 |
64 | 我们也会定期召开顾问的会议，定期review社区发展是否走偏。不会太频繁，一到两个月一次。
65 |
66 | **我们目前已经有四位顾问，非常感谢大家的热情参与，他们分别是（按时间顺序排列）：**
67 |
68 | - **法律顾问，李扬**，北京爱问法科技有限公司创始人/CEO，法律硕士，持有国家法律职业资格，前某上市公司法务总监。
69 | - **技术顾问，司晋琦**，前大厂CTO，现AI全栈。
70 | - **生态战略顾问**，侯宏，北京大学国家发展研究院管理学助理教授，博士生导师，剑桥大学博士。
71 | - **标准化顾问**，冉若曦， W3C 标准技术专家。
72 |
73 | 
74 |
75 | 关于社区成员的成长路径，可以从用户开始，使用ANP协议，然后参与社区讨论，并且贡献代码，成为贡献者。
76 |
77 | 贡献者有多次有效贡献后，可以邀请成为社区的维护者，负责审核PR、管理项目文档、参与发布流程。
78 |
79 | 表现优异的贡献者，由维护者共同提名，进入技术委员会，决策重大技术方向、治理社区规范。
80 |
81 | 社区不会提供物质激励，但是希望社区提供的title，能够有助于贡献者的职业生涯，特别是在ANP取得大的发展的时候。
82 |
83 | 
84 |
85 | 企业也可以参与到社区的工作中。我们正在设计企业参与社区工作的具体方式，在正式出台之前，企业可以以观察员的方式参与到社区工作中。
86 |
87 | 目前已经有多家企业观察员，也**欢迎对ANP感兴趣的企业先以观察员的身份参与到社区中来**。
88 |
89 | 
90 |
91 | 同步一下社区一些工作的进展：
92 |
93 | - 标准化：我们社区会参与到互联网协会互联互通工委会的智能体互联网工作组中，推动智能体通信协议的标准化。同时与W3C中国合作推动智能体通信协议在国际上的标准化。
94 |
95 | - 公司合作：目前有多个ANP项目在沟通落地中，有TO B项目，也有C端项目。同时，我们最近也在和国内很多大厂、大模型公司沟通ANP协议。
96 |
97 | - 本周完成了本地DID demo，可以在不依赖域名的情况下，完成did功能的展示，让人快速理解DID的原理。
98 |
99 | 
100 |
101 | 社区下一步计划（优先级从高到低）：
102 | - 短期，2~4周，完成演示demo
103 | - 文档（readme）、官网、项目整理
104 | - 社区理念、愿景的构建，协议长远的规划、路线图：白话的方式表达
105 | - 影响力构建：推广，标准化，大厂合作
106 | - 社区运营正轨化：调动社区成员的积极性，增加社区成员
107 | - 协议完善：安全、隐私、交易闭环
108 |
109 | ## 后续
110 |
111 | 会议结束后，收到大家很多正反馈，我们社区开发者数量也从50+直接跳涨到了70+。
112 |
113 | 同时，社区成员自发发起了第三个子项目：ANP推广小组，下次社区会议可以同步相关内容。
114 |
115 | 再次感谢社区成员的贡献！
116 |
117 | 同时，**社区仍然有很多工作要做，社区还需要更多的力量参与，我们的创始委员会、社区顾问、社区开发者都欢迎大家的加入。**
118 |
119 | 感兴趣的同学，可以微信联系我： flow10240
120 |
121 | 期待您的加入！
122 |
123 | 完整会议回放：https://meeting.tencent.com/crm/KDnBQBEXab
--------------------------------------------------------------------------------
/blogs/cn/LangGraph负责人对MCP的挑战，ANP是怎么解决的？.md:
--------------------------------------------------------------------------------
1 | # LangGraph负责人对MCP的挑战，ANP是怎么解决的？
2 |
3 | 最近MCP在网上比较火，看到了Langchain官网的一篇博客，FounderPark也做了转载：
4 |
5 | 原始链接：https://blog.langchain.dev/mcp-fad-or-fixture/
6 | 中文链接：https://mp.weixin.qq.com/s/etvDsU422z8uiknCn6fw4A
7 |
8 | 内容是 LangChain 联合创始人、CEO Harrison Chase 与 LangGraph 负责人 Nuno Campos 针对 MCP 的辩论，探讨 MCP 究竟是昙花一现的热点还是注定成为未来的标准。
9 |
10 | 虽然有些观点，我未必认同，包括对MCP协议的定义与使用。但是Nuno Campos对MCP提出的几个问题确实直击要害。
11 |
12 | 由于我们一直在做智能体通信协议，我们发布的ANP应该是全球第一个面向智能体的通信协议，当MCP发布后，我们第一时间就进行了研究，也发现了Nuno Campos提出的这些问题。
13 |
14 | 其实这些问题，ANP在设计之初就已经考虑了。今天主要聊聊ANP是怎么解决这些问题的。
15 |
16 | ## Nuno Campos对MCP提出的几个问题核心有哪些
17 |
18 | Nuno Campos在与Harrison Chase的辩论中，提出了MCP当前存在的几个核心问题：
19 |
20 | - **协议复杂性过高**：MCP不仅仅是一个工具调用协议，还同时提供了提示（prompts）和模型补全（LLM completions）服务，这种设计增加了协议的复杂性。
21 | - **实现难度较大**：MCP采用了双向通信机制，增加了实现的复杂性，尤其是对于开发者而言，增加了额外的负担。
22 | - **难以在服务器端扩展**：MCP当前的设计并非无状态协议，难以在服务器端进行扩展，尤其是在分布式环境下，身份认证和状态管理问题突出。
23 | - **工具质量与模型适配问题**：将随机工具插入到一个对工具毫无了解的智能体中，必然会导致工具调用的质量下降，影响用户体验。
24 |
25 | ## ANP的解决方案
26 |
27 | 针对Nuno Campos提出的这些问题，ANP在设计之初就进行了深入的思考，并提出了相应的解决方案：
28 |
29 | ### 智能体身份问题
30 |
31 | 我们认为这是协议最重要的问题。MCP刚发布的时候，只支持本地server，最主要的原因也是他们没有想清楚身份的问题如何解决。我们和MCP社区官方也有过沟通，不过他们并没有采纳我们的建议。
32 |
33 |
34 | 
35 |
36 |
37 | 后来他们选择了OpenID Connect作为身份认证方案，但是OpenID Connect本身是一个中心化的方案，无法提供去中心化、分布式的身份认证，在智能体协作上，存在天然的短板。
38 |
39 | 而我们在设计ANP的第一天，就在尝试解决智能体去中心化身份的问题，我们最终的方案，能够达到类似email的效果：在每个平台内部，是中心化的方案，但是整体网络是一个去中心化的方案。不同平台之间都可以互相通信。
40 |
41 | 详细对比可以参考：[did:wba对比OpenID Connect、API keys](/blogs/cn/did:wba对比OpenID%20Connect、API%20keys.md)。
42 |
43 | 我们能够理解他们选择OpenID Connect的原因：解决Chatbot应用与现有互联网的融合问题。但是，我们相信，随着智能体互联网的发展，ANP所倡导的去中心化、智能体为核心的设计理念，将更适合未来智能体网络的需求。
44 |
45 | ### 协议复杂性问题
46 |
47 | ANP明确了自身的定位：专注于智能体之间的通信协议，而非模型的上下文协议。ANP不提供模型补全服务，也不提供提示服务，而是专注于定义智能体之间如何进行身份认证、信息交换和协作。
48 |
49 | ANP的设计理念是"Agent-Centric"，每个智能体都是网络中的平等节点，协议本身只负责定义智能体之间的通信规则和数据格式，极大地降低了协议的复杂性。
50 |
51 | 我们在开源项目OpenManus的基础之上，添加了ANP协议的支持，大家可以看下我们的代码（app/tool/anp_tool.py）。git地址：https://github.com/agent-network-protocol/OpenManus-ANP。（社区内测中，有问题可以给我们反馈）
52 |
53 | 智能体集成ANP，只需要200行代码就可以完成，核心是一个提示词，一个http函数。剩下的事情完全由模型来驱动。
54 |
55 | http函数就是模型的浏览器，通过它，模型就可以方便的访问、遍历通过ANP协议连接起来的数据网络。**构建一个方便AI访问的数据网络，一直都是ANP的目标。**
56 |
57 | 智能体基于ANP的连接方式，才是真正AI Native的连接的方式。
58 |
59 | ### 服务器端扩展问题
60 |
61 | ANP本身并不定义协议内部的状态，因为基于ANP的智能体描述协议是自描述的。所谓的自描述，是模型可以在文档中声明接口调用的方式，可以是有状态的，也可以是无状态的，ANP都支持。
62 |
63 | 智能体可以自由的决定，它对外的接口是哪种方式，可以是有状态的，也可以是无状态的。
64 |
65 | ### 工具质量与模型适配问题
66 |
67 | 我认为这是模型要解决的问题，和协议无关。协议能够提供的，是更好的描述信息与工具的使用方式。这一点我认为他的理解是有偏差的，或者他是对协议这种模式的质疑。
68 |
69 | ## 核心概念的差异
70 |
71 | ANP和MCP在协议的核心概念上还是有很大的差异的。MCP中，tool、资源、提示词是协议的核心。但是在ANP中，这些都是不存在的。
72 |
73 | ANP提供的是对智能体公开信息的描述，这些信息可以是基本信息，比如咖啡店卖什么咖啡，也可以是API接口描述，通过这个接口可以购买咖啡。
74 |
75 | 信息是ANP唯一的概念，也是最核心的概念，没有资源、没有工具、没有提示词，一切由模型决定，由智能体开发者决定。
76 |
--------------------------------------------------------------------------------
/blogs/cn/MCP十问十答.md:
--------------------------------------------------------------------------------
1 |
2 | # MCP十问十答
3 |
4 | ## 前言
5 |
6 | 在沟通的过程中，发现大家对MCP都不是很了解，所以快速的整理了这篇文章，希望能够给你一个整体的认识。
7 |
8 | ## 免费送一问：什么是MCP
9 |
10 | MCP（Model Context Protocol，模型上下文协议）是一种开放协议，旨在规范大型语言模型（LLM）与外部数据源、工具和服务之间的交互方式。
11 |
12 | 最早由Anthropic开发，现在已经开源。
13 |
14 | ## 第一问：MCP中的P，Protocol是什么
15 |
16 | P是Protocol的缩写，表示协议。这里的协议一般指的是网络协议，比如常见的TCP/IP、HTTP等，都是一种网络协议。
17 |
18 | 网络协议定义了通信的双方如何建立连接，如何发送数据，数据格式的定义，以及错误处理等。
19 |
20 | MCP是一个网络协议，定义了AI模型与外部数据源和工具集成的网络通信数据格式，包括使用什么传输协议，数据格式定义，身份验证方法等。
21 |
22 | ## 第二问：MCP解决了什么问题
23 |
24 | MCP解决了大型语言模型与外部数据源和工具集成的碎片化问题。通过标准化接口，MCP使AI应用能够更可靠、高效地连接到不同的数据源和工具，避免了为每个数据源单独开发连接器的麻烦。
25 |
26 | 简单的说，一个工具通过MCP协议，既可以给Claude用，也可以给cursor用。工具以及Claude都不用开发第二遍。
27 |
28 | ## 第三问：MCP处于什么样的位置
29 |
30 | 处于模型与工具/资源之间的位置。模型通过function calling的方式调用函数，函数内部再通过MCP协议与外部工具/资源进行交互。
31 |
32 | ## 第四问：MCP是Anthropic开发的，其他模型可以用吗
33 |
34 | 可以。
35 |
36 | 虽然MCP由Anthropic开发，但它是一个开放协议，任何模型都可以使用。它与模型无关。如果模型本来工具使用能力不强，用了MCP后，工具使用能力也不会增强。
37 |
38 | ## 第五问：MCP和function calling的区别
39 |
40 | 他们两个不是一个概念。
41 |
42 | function calling是大模型与外部数字世界的交互方式。MCP是MCP host(chatbot或者AI工具)与外部工具/资源之间的交互方式。
43 |
44 | 一般来讲，模型先通过function calling触发一个函数调用，再在这个函数调用中触发MCP请求。
45 |
46 | ## 第六问：MCP和之前openai的插件什么区别
47 |
48 | 非常像，不过MCP比之前的插件规范性更好，定义了清晰的数据格式、传输协议、身份验证方法等，能力也更强。
49 |
50 | ## 第七问：MCP和GPTS什么区别
51 |
52 | GPTs更像一个应用市场，而且目前是给人用的应用市场。
53 |
54 | GPTs可能和MCP server的markplace类似，不过MCP server主要是给AI使用的，不直接给人用。
55 |
56 | ## 第八问：MCP会成为标准吗
57 |
58 | 短期内，在模型集成外部资源与工具，MCP没有对手，并且生态越来越大。
59 |
60 | 不过不确定openai会不会支持，会不会自己搞一个规范。如果要搞一个，肯定要在设计上比MCP要更好，否则会被骂搞”小院高墙“。
61 |
62 | 长期看，MCP本身设计存在一些问题，比如复杂性问题，客户端和服务器耦合问题，分布式身份鉴权问题等，需要解决。
63 |
64 | ## 第九问：我们要接入MCP吗
65 |
66 | 技术看，如果内部使用，需要权衡灵活性与成本。内部用怎么搞都可以，怎么高效怎么来，MCP不一定是最优方案。不过，如果涉及和外部（比如公网）工具对接，最好还是用大家认可的协议。
67 |
68 | ## 第十问：国内互联网平台会接入MCP吗
69 |
70 | 国内平台比如美团、滴滴、淘宝、拼多多等，我认为短期大概率不会。他们不会给自己找一个上游。
71 |
72 | 就像当初淘宝砍断百度和微信的流量入口一样。
73 |
74 | ## 最后送一问：MCP适用于智能体吗
75 |
76 | MCP不是为智能体而设计，它是为模型连接外部资源和工具而设计的。
77 |
78 | 有好几个问题没有解决，比如MCP中心化的身份认证技术，并不适合智能体之间的身份认证。MCP的CS架构（客户端服务端架构），server无法主动连接client。
79 |
80 | 如果有智能体连接的需求，可以试试我们的ANP，ANP专门为智能体而设计。
81 |
82 | ## 联系我们
83 |
84 | 如果你对这个话题感兴趣，欢迎联系我们。
85 |
86 | AgentNetworkProtocol的目标是成为智能体互联网时代的HTTP。我们的愿景是定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络。
87 |
88 | ANP开源技术社区目前有25名开发者，也正在招募开发者。如果你对智能体通信协议感兴趣，无论是开发、产品、运营，都可以加入我们，**用开源的方式，去定义智能体的连接与协作**。
89 |
90 | 联系方式：
91 | - GitHub：https://github.com/agent-network-protocol/AgentNetworkProtocol
92 | - Discord: https://discord.gg/sFjBKTY7sB
93 | - 官网：https://agent-network-protocol.com/
94 | - 微信：flow10240
95 |
96 | 最后，欢迎加入智能体通信协议交流群。这可能是中国第一个讨论智能体通信协议的群组，目前有两百多名协议爱好者在讨论交流。（添加我微信加入）
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
--------------------------------------------------------------------------------
/blogs/cn/agent对infra的改变-对连接基础设施的改变.md:
--------------------------------------------------------------------------------
1 | # Agent对Infra的改变：Agent对现有连接基础设施的挑战
2 |
3 | ## AI对连接的特殊要求
4 |
5 | 基于LLM构建的智能体要想最大限度的发挥能力，对连接方式有特殊的要求：
6 | - AI必须能够访问到所有的信息，才能够为人或组织作出更加智能的决策，这要求AI与所有的信息是互联互通的。
7 | - AI必须能够调用所有的工具，才能够帮助人或组织更好的完成任务，这要求AI与所有工具是互联互通的。
8 |
9 | 而当前所有的APP、软件或网站，都是为人类访问而设计的，AI要想访问，必须学习和模仿人类的访问方式。这也促使了Computer use和Browser use技术的诞生。
10 |
11 | 这两种技术短期是有价值的，但是他们存在着天然的短板，比如，Computer use由于基于屏幕的视觉信息，成本较高且需要占用用户的电脑屏幕；Browser use则只能够访问web网站，并且存在着用户登录时的安全性问题。
12 |
13 | 为此，我们需要更加AI原生的方式，让AI与数字世界进行交互，让智能体与智能体进行交互。
14 |
15 | ## Protocol：AI原生的连接与协作方式
16 |
17 | 这也就诞生了另外一条技术路线：Protocol。
18 |
19 | - 使用Protocol处理数据更高效：因为AI更加擅长处理的是最直接的底层数据，而不是屏幕或浏览器。
20 |
21 | - 标准化能够降低连接成本：通过将Protocol标准化，所有支持标准Protocol的软件或智能体，都能够进行互联互通，这能够极大的降低连接成本，形成一个新的生态。
22 |
23 | - 使用协议，可以构建一个AI原生的、便于AI访问的数据网络，独立于当前专为人类设计的、基于屏幕的、基于浏览器的互联网。
24 |
25 | 我认为这才是MCP最近获得广泛关注的底层原因，它用AI原生的方式，解决了当下最重要的问题：模型如何连接工具与资源。同时标准化的方式又能够降低整个行业的连接成本，形成新的生态。
26 |
27 | 在OpenAI宣布支持MCP之后，MCP基本上可以看做行业的事实标准，基本不大可能在出现第二个MCP。未来MCP和标准化机构合作，推进MCP标准化应该是大概率事件。
28 |
29 | Protocol这条技术路线最大的问题，是需要改造原有的软件，改造成本较高。不过这个成本正在被AI快速的降低：
30 | - AI改变了软件开发的方式，通过AI生成代码，可以大幅度降低软件开发的成本。
31 | - AI改变了软件运行的方式，使用LLM驱动软件运行，可以将软件的本质复杂度在LLM内解决，不在需要大量复杂代码。
32 | - AI改变了软件连接的方式，通过LLM构造请求并处理响应，可以大幅度降低软件对接、联调的成本。
33 |
34 | ## MCP的下一步：智能体通信与协作
35 |
36 | 使用MCP能够构建更加高效的智能体，智能体越来越多之后，他们之间如何进行通信与协作？
37 |
38 | MCP是为解决模型连接资源与工具的问题而设计，难以直接用于智能体之间的通信与协作。主要有以下两个核心问题（以智能体A访问智能体B为例）：
39 | - 身份问题：使用MCP，要求智能体A必须在智能体B有一个注册账号。如果智能体A要访问很多的智能体，这些智能体都属于不同的组织，这要求A必须管理很多的账号，成本非常高。
40 | - 协议架构：MCP是典型的CS架构，client主动连接server，并且对client和server的角色进行了严格区分。而在智能体网络中，智能体与智能体之间更多的是点对点的关系。CS架构天然不适合智能体的点对点通信，特别是在智能体连接、协作上：单向的CS连接，一方无法找到另一方；双向CS连接可以解决这个问题，不过整体上非常的复杂。
41 |
42 | 行业中有很多协议专门为解决智能体之间的通信与协作难题而设计，目前在设计和实现上最完备的是ANP（Agent Network Protocol），以及IBM推出的ACP（Agent Communication Protocol）和思科推出的ACP（Agent Connection Protocol）
43 |
44 | 以ANP为例，重点解决的是智能体在互联网上的协作问题，比如智能体身份、智能体描述、智能体发现等问题。其最大的特点是用W3C DID（去中心化身份）来标识智能体，是智能体能够使用自己的身份ID，与任意其他的智能体进行交互。同时ANP的协议架构是P2P架构，天然适合智能体与智能体之间的点对点通信。
45 |
46 | ## 互联网的下一步：智能体互联网
47 |
48 | 随着互联网中的智能体越来越多，智能体之间的连接越来越多，必然会对现有的互联网造成深刻的改变。对互联网的演进，我们有几点判断：
49 | - 个人助手成为新的互联网入口，人通过个人助手访问互联网
50 | - 企业也会使用智能体替代企业软件，并且直接将智能体部署到互联网上服务消费者。
51 | - 个人助手和企业的智能体直接通过协议连接成为可能，而不是通过互联网平台进行连接。消费互联网将会和产业互联网深度融合。
52 | - 智能体之间的连接将成为互联网主要的连接方式，将会出现一个专门面向AI设计、方便AI访问的智能体数据网络。
53 | - 智能体通信协议成为新的基础设施，未来会出现标准化的智能体通信协议。
54 |
55 |
56 |
--------------------------------------------------------------------------------
/blogs/cn/anthropic-mcp-2025h1-里程碑解读.md:
--------------------------------------------------------------------------------
1 |
2 | # Anthropic MCP 2025H1 里程碑解读
3 |
4 | Anthropic MCP刚发布了2025上半年的Roadmap，地址：[https://modelcontextprotocol.io/development/roadmap#roadmap](https://modelcontextprotocol.io/development/roadmap#roadmap).
5 |
6 | 我们一直在从事智能体通信协议的研究，也对MCP非常的关注，也在社区中提了一些我们的提案。
7 |
8 | 今天结合我们对MCP的理解，解读官方设定的里程碑，以及对MCP、智能体通信协议的一些看法。
9 |
10 | 本文重点内容有三点：
11 |
12 | - 支持远程服务器。这个非常重要。远程服务器支持当中，身份认证方案的支持是最重要的一点。
13 | - 降低使用门槛。现在MCP使用门槛太高，基本上要有一定的开发背景才好用。
14 | - 社区与标准。MCP未来会致力于想成为行业的标准。
15 |
16 |
17 | ## 里程碑解读
18 |
19 | ### 远程MCP支持
20 |
21 | 我之前在一篇文章中（[为什么Anthropic刚刚发布的MCP协议应该使用DID进行身份鉴权](https://mp.weixin.qq.com/s/r6k1zSHnC8sKA819x8O91Q)）就提到过，MCP不支持远程数据访问是因为它有一个致命的缺陷——还没有一个完备的身份认证方案。
22 |
23 | 可以看到，社区也是认识到这一点了，里程碑的第一项就是要支持远程MCP连接，而远程MCP连接的第一项就是认证与授权。
24 |
25 | 目前已经有人提交了关于身份认证的提案，是一个使用Oauth2.0进行身份认证的方案，已经在评审中。我们在社区中也和维护者有过沟通，目前用这个方案确实是最现实的一个方案，毕竟Oauth2.0的标准程度以及应用的广泛性还是不错的。
26 |
27 | 这个提案最好的一点是，它将Oauth2.0作为一个标准流程，同时提出了一种身份认证插件化的方案。允许其他的身份认证方案作为实验性的方案合入规范中。这对规范的灵活性和开放性非常的有帮助。
28 |
29 | 我们也基于这个提案，开发了一个基于W3C DID的身份认证方案(https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/03-did%3Awba%20Method%20Design%20Specification.md)，正在等待插件化的方案合入后，提交PR。关于W3C DID的身份认证方案与Oauth2.0的区别，可以看这篇文章：[最适合智能体的身份认证技术：对比OpenID Connect、API keys、did:wba](https://mp.weixin.qq.com/s/LBQmw_azJkmQpXp8XmKYPw)
30 |
31 | 远程MCP支持的另外两项：
32 |
33 | - 一项是服务发现，这里面还隐含了一点是服务的描述。他们可能会做一个类似OpenAI GPTs的产品，MCP client可以调用接口查找自己喜欢的服务器。
34 | - 无状态操作，主要是为了降低服务器开发的能到。
35 |
36 | ### 分发与发现
37 |
38 | 这是历程碑第三项，但是我认为要比第二项要重要。
39 |
40 | MCP当前最大的问题是易用性非常差。对比OpenAI的GPTs，MCP的能力可以说非常的强，它为开发者提供了一种强大的手段和LLM进行交互。但是易用性却比GPTs差了很多。现在对使用者基本上都要求有一定的开发或计算机水平，要使用者自己能够安装一堆的软件和服务。这大大提高了MCP使用的门槛。
41 |
42 | 这个里程碑的四项内容，包管理、安装工具、沙盒、服务器注册，确实可以让MCP的使用者变得更加简单。
43 |
44 | 在我的设想中，MCP要想普及，必须要降低使用门槛；降低使用门槛的同时，还能够和社区生态互动，需要一种类似浏览器插件的机制，可以让用户方便的加载不同的MCP server。这四项工作应该也是朝着这个目标前进的。
45 |
46 | 另外，要提高易用性，必须提高远程MCP server的比重。能够在远程完成的，尽量不要在本地。这也是为什么远程服务器重要的原因。
47 |
48 | ### 智能体支持
49 |
50 | 这里有三项：分层智能体系统、交互式工作流、流式结果。这一块社区讨论的比较少，除了最后一项，其他两项我还不是很理解。后继续关注，如果你对这块有不错的理解， 欢迎留言。
51 |
52 | ### 更官方的生态系统
53 |
54 | MCP期望社区能够主导的标准的制定，虽然现在主要的维护者是Anthropic的开发人员。他们想培育一个协作生态系统，所有 AI 提供商都可以通过平等参与和共享治理帮助将 MCP 塑造为开放标准，确保其满足各种 AI 应用程序和用例的需求。另外他们也希望和标准化机构合作推进标准化。
55 |
56 | 这是一个不错的思路，也是构建行业标准的通用做法。现在MCP社区还是以Anthropic为主，包括提案的评审。引入更多的伙伴，淡化单一厂商，有助于规范被更广大的范围采用。我们后面也会深入参与其中。
57 |
58 | ## 未来我们需要什么样的协议
59 |
60 | 智能体未来是否需要一个标准协议来进行通信，现在好像已经不用讨论了。大家慢慢的已经看到了它的必要性，前几天腾讯科技AI未来指北的一篇文章（[手机AI帮你点咖啡，App们同意了吗？](https://mp.weixin.qq.com/s/vRSn0jKRwGa-Ut6G5keD8w)）也提到了这一点。在我们和业内认识的沟通过程中，发现这也慢慢的变成一种共识。
61 |
62 | 现在可能还不怎么确定的是，未来我们需要怎么样的协议？以及它通过什么的路径让行业接受它。
63 |
64 | 关于未来协议的轮廓，我们有我们的一些思考（[智能体互联网(Agentic Web)有什么不同之处](https://mp.weixin.qq.com/s/wBgelNViCLyXm5Ha6igzbw)）。我们也在根据我们的思考，设计我们理想中的智能体通信协议AgentNetworkProtocol（ANP）：[https://github.com/agent-network-protocol/AgentNetworkProtocol](https://github.com/agent-network-protocol/AgentNetworkProtocol)。
65 |
66 | 我们认为未来的智能体一定是互联互通的、一定是通过底层数据（API或Protocol）与互联网进行通信的、智能体之间是对等的存在。这是我们设计ANP的核心原则。
67 |
68 | 回到MCP，我们设计的ANP与MCP最大的区别，就是在世界观的差异：
69 | - MCP是以模型为核心，整个互联网都是他的上下文与工具
70 | - 我们（Agent Network Protocol）以智能体为核心，每个智能体具有同等的地位，组成一个去中心化的智能体协作网络。
71 |
72 | 我们在走一条与MCP不是特别一样的路，无论是否能够走通，我们都希望能够为行业探索一种可能。
73 |
74 | 最后，如果你也对我们的协议感兴趣，欢迎联系我们。特别是，如果你是AI手机、AI助手、智能体框架的产品或开发人员，我希望和你聊聊我们对未来的看法。
75 |
76 | 欢迎加我微信：flow10240
77 |
78 | ## 版权声明
79 | Copyright (c) 2024 GaoWei Chang
80 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
81 |
--------------------------------------------------------------------------------
/blogs/cn/did-wba安全性原理解析.md:
--------------------------------------------------------------------------------
1 | # did:wba 安全性原理解析
2 |
3 | did:wba作为一种基于 Web 的去中心化身份标识符方法，其安全性设计是其核心特征之一。本文将深入探讨 did:wba 的安全性原理，分析其如何保证身份验证的可靠性和安全性。
4 |
5 | did:wba相关资料链接：
6 | - did:wba规范文档：[did:wba 规范](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/chinese/03-did%3Awba%E6%96%B9%E6%B3%95%E8%A7%84%E8%8C%83.md)
7 | - 这是一个did:wba的简要介绍：[did:wba-基于web的去中心化身份标识符](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/did%3Awba-%E5%9F%BA%E4%BA%8Eweb%E7%9A%84%E5%8E%BB%E4%B8%AD%E5%BF%83%E5%8C%96%E8%BA%AB%E4%BB%BD%E6%A0%87%E8%AF%86%E7%AC%A6.md)
8 | - 我们对比了did:wba与OpenID Connect、API keys等技术方案的区别：[did:wba对比OpenID Connect、API keys](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/cn/did%3Awba%E5%AF%B9%E6%AF%94OpenID%20Connect%E3%80%81API%20keys.md)
9 |
10 | ## 1. 安全性的基石：非对称加密
11 |
12 | did:wba 的安全性主要建立在非对称加密的基础之上。这种加密方式使用一对密钥：
13 |
14 | - 私钥：仅由身份所有者持有，用于签名
15 | - 公钥：可以公开，用于验证签名
16 |
17 | ```mermaid
18 | graph LR
19 | subgraph "身份所有者"
20 | PrivateKey["私钥"]
21 | PublicKey["公钥"]
22 | end
23 |
24 | subgraph "签名过程"
25 | Data["原始数据"]
26 | Sign["数字签名"]
27 | PrivateKey -->|使用私钥签名| Sign
28 | Data -->|计算哈希| Sign
29 | end
30 |
31 | subgraph "验证过程"
32 | VerifyData["接收到的数据"]
33 | VerifySign["接收到的签名"]
34 | Result["验证结果"]
35 | PublicKey -->|使用公钥验证| Result
36 | VerifyData -->|计算哈希| Result
37 | VerifySign --> Result
38 | end
39 |
40 | classDef privateKey fill:#f9f,stroke:#333,stroke-width:2px;
41 | classDef publicKey fill:#9ff,stroke:#333,stroke-width:2px;
42 | classDef sign fill:#ff9,stroke:#333,stroke-width:2px;
43 | classDef result fill:#9f9,stroke:#333,stroke-width:2px;
44 |
45 | class PrivateKey privateKey;
46 | class PublicKey publicKey;
47 | class Sign sign;
48 | class Result result;
49 | ```
50 |
51 | 这种加密机制确保了：
52 | 1. 只有持有私钥的人才能生成有效签名。私钥必须保密，不能泄露。
53 | 2. 任何人都可以使用公钥验证签名的真实性，签名验证通过，则说明签名是由持有私钥的人生成的。
54 | 3. 无法从公钥推导出私钥。公钥和私钥是成对生成的，公钥不能推导出私钥。
55 |
56 | ## 2. DID Document 的安全性保证
57 |
58 | 从上面流程可以看到，只要保证两点，就可以保证did:wba的安全性：
59 |
60 | 1. 私钥必须保密，不能泄露。
61 | 2. 验证者能够获的正确的公钥。
62 |
63 | 在did:wba中，私钥由用户自己保管，公钥是包含在DID Document中的。而DID Document是存储用户DID服务器上，任何人都可以根据DID生成获取DID Document的URL，然后使用https协议访问。
64 |
65 | 所以，在根本上，只要用户能够获得正确的DID Document，就可以验证对方的身份。在did:wba中，我们推荐用户使用dns-over-https解析域名，使用https协议访问DID Document，并且在https中使用安全的加密算法，以及严格的证书校验。做到这几点，我们就能够保证用户能够获得正确的DID Document，进而验证对方的身份。
66 |
67 | ## 3. 身份验证流程的安全保障
68 |
69 | did:wba 的身份验证流程采用了多重安全机制：
70 |
71 | ### 3.1 请求签名机制
72 |
73 | 每个认证请求都包含以下要素：
74 | ```
75 | Authorization: DID Nonce Timestamp VerificationMethod Signature
76 | ```
77 |
78 | 其中：
79 | - Nonce：防重放攻击的随机数
80 | - Timestamp：确保请求时效性
81 | - Signature：对关键信息的签名
82 |
83 | ### 3.2 防护措施
84 |
85 | 1. **防重放攻击**：
86 | - 客户端为每个请求生成唯一 nonce
87 | - nonce 仅能使用一次
88 | - 服务器维护已使用 nonce 的黑名单
89 |
90 | 2. **时间戳验证**：
91 | - 限制请求的有效时间窗口
92 | - 防止历史请求重放
93 | - 服务器校验时间戳的合理性
94 |
95 | 3. **域名验证**：
96 | - 将服务端域名作为签名的数据，防止签名被用于其他服务
97 |
98 | 4. **签名验证**：
99 | - 验证签名的完整性
100 | - 确保签名使用了授权的密钥
101 |
102 | ## 4. 其他安全性考虑
103 |
104 | ### 4.1 私钥泄漏
105 |
106 | 如果用户的私钥不小心泄漏，应该尽快的生成新的公私钥，并且更新DID Document。因为DID Document是存储在用户自己的DID服务器上，所以用户可以随时更新DID Document。
107 |
108 | ### 4.2 私钥定期轮换
109 |
110 | 私钥应该定期轮换，以保证安全性。
111 |
112 | ## 总结
113 |
114 | did:wba 的安全性建立在现代密码学的基础之上，通过非对称加密、DID Document的存储和验证流程，以及私钥的定期轮换，确保了身份验证的可靠性和安全性。
115 |
116 | 其最底层的原理，仍然是基于非对称加密的强安全性。在基础设施层，它并没有发明或依赖新的设施，仍然是依赖现有非常成熟的域名系统、公钥基础设施、https协议等。
117 |
118 |
119 | ## 版权声明
120 | Copyright (c) 2024 GaoWei Chang
121 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
122 |
--------------------------------------------------------------------------------
/blogs/cn/did-wba对比openid-connect、api-keys.md:
--------------------------------------------------------------------------------
1 | # 最适合智能体的身份认证技术：对比OpenID Connect、API keys、did:wba
2 |
3 | ## 智能体需要新的身份认证技术
4 |
5 | 智能体对身份认证技术提出了新的需求，其中最重要的一个就是互联互通，特别是让任意两个智能体都能够互联互通。
6 |
7 | 其中的原理很简单：AI必须**具备获得完整上下文信息的能力，具备调用所有工具的能力**，才能够作出正确的决策，采取合适的行动。现在很多厂商试图使用Computer Use方案解决这个问题。
8 |
9 |
10 | 
11 |
12 |
13 | 但是我们认为这不是AI与互联网交互最高效的方式。这是让AI模仿人的方式访问互联网，AI应该用它最擅长的方式（API或通信协议）与数字世界交互。
14 |
15 |
16 | 
17 |
18 |
19 | 这就涉及一个互联互通的问题：在智能体使用API或协议，与互联网或者其他智能体交互的时候，如何进行身份验证？特别进行跨平台的身份验证，以让任何智能体之间都能够进行连接。
20 |
21 | ## 当前主流跨平台身份认证技术
22 |
23 | 我们在互联网上的身份账号，很多时候是不能跨平台使用的。比如你的微信账号，在钉钉系统中是无法识别的，反之亦然。
24 |
25 | 不过现在互联网也有很多跨平台的身份认证技术，比如我们常见的SSO（单点登录），你可以用你的谷歌账户登录很多网站。还有API keys，比如你可以使用OpenAI给你的key，访问OpenAI的API。下面我来简单的介绍下这两种技术，看看是否适合智能体的身份认证。
26 |
27 | ### OpenID Connect（OIDC）
28 |
29 | OpenID Connect (OIDC) 是一种基于 OAuth 2.0 构建的身份验证协议，它允许客户端应用程序验证用户身份，并获取用户的基本信息（如姓名、邮箱）。OIDC 在 OAuth 2.0 的基础上增加了标准化的身份层，使其更适合于登录和单点登录（SSO）场景。
30 |
31 | [OpenID Connect 官方规范](https://openid.net/specs/openid-connect-core-1_0.html)。
32 |
33 | 下面我们以使用谷歌账号登录三方网站为例来介绍下OIDC的流程。[谷歌OIDC官方文档地址。](https://developers.google.com/identity/protocols/oauth2/openid-connect)。
34 |
35 |
36 | 
37 |
38 |
39 | 使用谷歌账号登录三方网站包括两部分，前置流程和Oauth2.0流程：
40 | - 前置流程
41 | - 注册谷歌平台账号
42 | - 创建项目/应用
43 | - 配置项目/应用，包括重定向URI
44 | - 获取OAuth 2.0的client id和client secret
45 | - Oauth2.0流程（以授权码流程为例）
46 | - 获取授权码
47 | - 使用授权码获取access token和id token，id token中包含用户信息
48 | - 使用access token和id token访问获取用户的详细信息（可选）。在OpenID Connect流程中，用户的详细信息可以认为是一种受保护的资源。
49 |
50 | OpenID Connect的优点是：
51 | - 能够简化用户的身份验证流程
52 | - 使用非常广泛，相关基础设施也比较完善。
53 | - 安全性较高
54 |
55 | 站在智能体互联互通的场景看，OpenID Connect有几个不足：
56 | - OpenID Connect本质上是让三方应用能够使用身份服务器（比如谷歌）对用户进行身份验证。两个三方应用之间无法使用身份服务器实现他们之间的身份验证。
57 | - OpenID Connect是一个中心化的方案，用户使用的时候需要去身份服务器进行注册等操作，前置操作流程复杂。
58 | - 流程交互复杂，需要多次交互。
59 |
60 | ### API keys
61 |
62 | API Keys（API 密钥）是用于验证应用程序或用户访问应用程序编程接口（API）的简单凭证。它是一种字符串形式的身份标识符，通常由随机生成的字母和数字组成，类似于密码的功能。它可以用于身份验证、访问控制、使用监控等场景。
63 |
64 |
65 | 
66 |
67 |
68 | 使用API Keys验证用户身份的流程：
69 | - 前置流程
70 | - 去平台注册账号
71 | - 获取API Keys
72 | - API keys验证流程
73 | - 在类似https的安全协议请求头中添加API keys
74 | - 服务端验证客户端的API keys
75 |
76 |
77 | API keys的优点是：
78 | - 简单，易于实现，交互少
79 | - 支持跨平台身份认证，两个应用只要相互有对方API keys，就可以验证身份
80 | - 广泛用于API服务当中，比如OpenAI、国内的模型API等，大部分使用API keys进行身份验证。
81 |
82 | 站在智能体互联互通的场景看，API keys有几个不足：
83 | - 安全性较低。有很多使用API keys做身份验证的MCP server，往往要求用户将API keys写在配置文件中，存在泄漏风险。
84 |
85 |
86 | 
87 |
88 |
89 | - 仍然需要前置流程，需要用户登录注册等操作。
90 |
91 | ## 基于W3C DID的身份认证技术：did:wba
92 |
93 | ### W3C DID是什么
94 |
95 | W3C DID（Decentralized Identifier，DID）是一种新的去中心化标识符标准，旨在解决传统中心化身份管理系统的依赖性。它与2022年发布为推荐标准。规范地址：[https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/)
96 |
97 | 目前已经有很多应用在使用W3C DID规范，比较知名的是最近比较火的bluesky，一个去中心化的推特应用。
98 |
99 | ### did:wba是什么
100 |
101 | did:wba是[AgentNetworkProtocol（ANP）](https://github.com/agent-network-protocol/AgentNetworkProtocol)定义的一个did方法规范。它基于web基础设施，实现了去中心化的身份认证，专门针对agent之间的身份认证而设计。规范地址：[did:wba方法规范](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/chinese/03-did%3Awba%E6%96%B9%E6%B3%95%E8%A7%84%E8%8C%83.md)。
102 |
103 | 与did:wba非常类似的业务是email：各个平台有自己的账号，但是不同平台之间能够非常简单的进行身份认证与通信。同时他们都基于web基础设施，能够支持大规模用户的同时，实现去中心化。
104 |
105 | 假设智能体A要订阅并调用智能体B的服务，身份验证以及请求流程如下：
106 |
107 |
108 | 
109 |
110 |
111 | - 前置流程
112 | - 智能体A要订阅智能体B的服务，首先调用智能体B的服务订阅接口，并且携带智能体A的DID和签名，让B知道是智能体A发起的订阅。使用API订阅，可以去掉复杂的注册、登录、配置等强制流程，降低两个智能体之间的连接成本。
113 | - 身份验证流程
114 | - 智能体A在首次http请求中，在http头中携带A的DID和签名。
115 | - 智能体B收到http请求后，从http头中提取A的DID和签名，然后根据A的DID，去A的DID server获取A的DID文档。
116 | - 智能体B获取到A的DID文档后，使用A的DID文档中的公钥对A的签名进行验证。
117 | - 验证通过后，智能体B处理A的业务请求，返回业务数据的同时，返回access token。
118 | - 智能体A在后续请求中携带access token，智能体B通过对access token的验证，完成对A的身份认证。
119 |
120 | did:wba身份验证方案的优点：
121 | - 安全性高
122 | - 充分利用web基础设施，能够支持大规模用户，可实施性强
123 | - 去中心化设计，能够让任意两个智能体体或应用之间进行身份认证
124 | - 前置流程简单，无需用户人工注册，无需用户人工登录配置
125 | - 身份验证流程简单，不增加交互次数
126 |
127 | 当然，did:wba也有一些缺点，最大的缺点是作为一个2022年发布的规范，基础设施不够完善，应用范围相对比较有限。不过我们也能够看到像bluesky这样的明星案例。
128 |
129 | ## 对比：did:wba vs OpenID Connect / API keys
130 |
131 | 站在智能体身份验证的角度，对比did:wba和OpenID Connect、API keys：
132 | - 安全性：did:wba和OpenID Connect具备同等的安全性，都比API keys的安全性高。
133 | - 复杂度：OpenID Connect的复杂度最高，API keys的复杂度最低，did:wba的复杂度介于两者之间。
134 | - 交互次数：did:wba和API keys的交互最少，OpenID connect的交互最多.
135 | - 前置流程：did:wba能够做到无需用户人工处理，OpenID connect和API keys都需要用户人工处理。
136 | - 去中心化：did:wba和API keys都可以做到让任意智能体或应用互相通信。OpenID connect无法做到
137 | - 应用范围：OpenID Connect和API keys应用范围都比较广泛，did:wba则是比较新的规范，应用范围有限。
138 |
139 | 总体对比如下：
140 | | 对比项 | did:wba | OpenID Connect | API keys |
141 | |:-------|:--------|:---------------|:---------|
142 | | 安全性 | 高 | 高 | 中等 |
143 | | 复杂度 | 中等 | 高 | 低 |
144 | | 交互次数 | 少 | 多 | 少 |
145 | | 前置流程 | 简单，无需人工 | 复杂，需要人工 | 中等，需要人工 |
146 | | 去中心化 | 是 | 否 | 是 |
147 | | 应用范围 | 有限 | 广泛 | 广泛 |
148 |
149 |
150 | 从上面的对比我们可以看到，did:wba不但能够支持所有的智能体互联互通，并且具备OpenID Connect的安全性以及API keys的简单性，同时也支持大规模用户使用。综合来看，did:wba是最适合智能体之间进行身份认证的方案。
151 |
152 | 当然，OpenID Connect和API keys仍然有他们自己的作用。比如，智能体在和原有互联网系统对接的时候，可能仍然需要使用OpenID Connect和API keys。
153 | ## 版权声明
154 | Copyright (c) 2024 GaoWei Chang
155 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
156 |
--------------------------------------------------------------------------------
/blogs/cn/《微信背后的产品观》是否适合AI.md:
--------------------------------------------------------------------------------
1 | # 《微信背后的产品观》是否适合AI
2 |
3 | 昨天在北大国发院参加了一个期AI碰撞局的交流，聊聊了很多，今天早上冒出一些想法，简单记录一下。
4 |
5 | 为了避免不必要的争论，先说明一下，我个人完整的读过张小龙的《微信背后的产品观》，并且受益匪浅。从移动互联网产品角度，微信绝对是一个非常棒的产品。
6 |
7 | 好，现在进入正题。
8 |
9 | ## 微信与AI在这两年的关系
10 |
11 | 先说结论，在我看来，**以微信为代表的超级APP，在AI高速发展的这两年，很多时候并不是AI这个最先进生产力的助力，而是AI的阻碍**。
12 |
13 | 很多AI从业者，用惯了AI产品，再用微信，有时候感觉就是在浪费生命。很多功能明明AI可以做的更好，并且技术已经具备了，但它就是不做。
14 |
15 | 比如加我的人，我要给他们发介绍，有的时候要拉他们进群。很多时候都是机械的重复操作，就比较烦。
16 |
17 | 自己不做也就罢了，也不让别人做，比如会读，23年的一个产品，我用过，挺好的，后来做不下去。原因大家都知道。
18 |
19 | ## 如何评价微信
20 |
21 | 微信在产品设计上，**绝对是一个非常好的产品**。但是要加一个条件，**做一款产品给十几亿人使用**。
22 |
23 | 站在一个个体的角度，也许微信只能够达到我的80分，离100分还有20分的距离，但是微信绝对不会满足我剩下的20分。
24 |
25 | 张小龙说，每天有一亿人教他做产品。不知道是不是原话，但是肯定有很多人提很多反馈意见。并且这些意见肯定大部分没有被采纳。
26 |
27 | ## 如何评价微信背后的产品观
28 |
29 | “每个时代都有属于那个时代的产品，属于那个时代的产品，一定会取代上一个时代的产品。而取代微信的，一定不是微信。”
30 |
31 |
32 | 技术、用户习惯、社会环境决定了什么样的产品可以成功。不是你想不想做，而是时代到了，它就自然发生。
33 |
34 |
35 | 世界观： 互联互通、开放智能体互联网
36 | 价值观： 连接即权力，开放的连接优于封闭平台
37 | 产品观：让每个微小的需求都能够被满足
38 |
39 |
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
--------------------------------------------------------------------------------
/blogs/cn/但我们设计一个协议的时候，我们在设计什么.md:
--------------------------------------------------------------------------------
1 | # 当我们设计一个协议的时候，我们在设计什么
2 |
3 | ## 协议是世界观的表达
4 |
5 | 当我们在设计一个协议的时候，我们在设计什么？这个问题可以从多个层面进行深入探讨。
6 |
7 | 协议的设计不仅仅是技术细节的堆砌，更是对整个世界运行规律的认知与理解，以及对未来发展趋势的一种判断。协议描述的是一个世界模型，这个模型描述了世界运行的规律，以及未来发展的方向。它需要设计这个世界模型中有哪些角色、不同的角色之间如何进行交互。
8 |
9 | 历史上的每一个成功协议，都体现了设计者对当时技术环境和未来趋势的准确把握。比如HTTP协议的设计反映了万维网创始人蒂姆·伯纳斯-李对信息共享和超文本系统的理解，它定义了客户端和服务器的角色，以及它们之间如何通过简单的请求-响应模式进行交互。正是这种简单而灵活的设计，使HTTP成为了互联网的基础协议之一。
10 |
11 | ## 智能体协议背后的世界观差异
12 |
13 | 在智能体通信协议领域，我们可以看到不同协议背后折射出的世界观差异。以当前较为知名的三种协议为例：MCP、ANP和Agora协议。
14 |
15 | ### MCP：模型中心的世界观
16 |
17 | MCP (Model Context Protocol) 的世界观是以模型为中心，整个互联网就是它的上下文。MCP是典型的客户端-服务端架构，客户端使用MCP协议连接到MCP服务器，然后访问服务器的各种信息和工具能力。
18 |
19 | 这种设计理念非常适合当前的互联网环境，它让AI模型能够方便地接入现有互联网资源，丰富Chatbot产品的能力。从某种程度上说，MCP将模型视为中心，将整个互联网视为模型的扩展。
20 |
21 | MCP使用了基于OAuth的身份认证方案，这是互联网上广泛应用的标准，使得模型能够访问用户在现有互联网应用上的资源。在信息组织上，MCP使用JSON-RPC来读取/操作服务器的资源与工具能力，本质上可以理解为一种特殊的API调用。
22 |
23 | （备注：这段可以讲下最近AI编程工具比如cursor对MCP的支持，你可以查找资料）
24 |
25 | ### ANP：智能体网络的去中心化视角
26 |
27 | ANP (Agent Network Protocol) 的世界观则完全不同。它是去中心化的，智能体互相平等连接。ANP是典型的P2P（点对点）架构，任意一个智能体都可以使用ANP连接到另外一个智能体，不存在中心化的服务节点。
28 |
29 | ANP的身份认证基于W3C DID标准，重点解决智能体之间的跨平台互操作性问题，让所有智能体都能互联互通。在信息组织上，ANP以语义网的Linked-Data技术为核心，目的是构建一个便于AI访问、便于AI理解的数据网络。
30 |
31 | 这种设计理念更适合下一阶段智能体互联网的发展，它预见了一个由无数智能体组成的网络，每个智能体都具有同等地位，可以自由连接和交互。
32 |
33 | ### Agora：自然语言交互的未来展望
34 |
35 | Agora协议则代表了更远的一种可能性，它认为未来智能体之间可以直接使用自然语言进行交互。这种想法在未来是可能实现的，因为随着AI技术的发展，智能体之间甚至可能进化出自己的语言形式，而自然语言可能只是一个过渡阶段。
36 |
37 | 这三种协议代表了智能体发展的三个不同阶段：MCP解决当下的问题，ANP解决下一步的问题，而Agora则在探索更远未来的可能性。它们在背后反映了每个设计者对当下的判断，对未来的一个预测，对整个世界运行规律的认知，以及他们背后的设计理念。
38 |
39 | ## 协议成功的决定因素
40 |
41 | 哪个协议最终能够胜出？生态、技术、能力都非常重要，但最根本的是什么？是协议是否符合未来行业的发展方向，这才是最重要的一点。也就是说，协议设计者在背后对整个世界模型的认知，以及对未来发展的一个判断，决定了协议未来是否有足够大的生命力。
42 |
43 | 推动互联网演进的最本质问题，是如何最大限度地释放新技术的能力。PC互联网时期，Web技术释放了开放互联网的访问能力；移动互联网时期，APP释放了移动设备的全部潜力。在当下以及未来10年，新技术无疑是以生成式人工智能、大语言模型、智能体为代表的AI技术。如何释放AI的能力，决定了未来互联网的演进方向。
44 |
45 | 例如，德国电信基于传统互联网设计的协议，与我们基于智能体设计的协议，哪个更有生命力？如果未来物联网上也能够运行智能体，而且智能体要和物联网设备做非常深入的沟通，那么前者的路线可能会更有生命力。
46 |
47 | ## 历史经验：SIP与H.323的案例
48 |
49 | 历史上的案例可以给我们提供借鉴。以SIP和H.323为例，SIP是基于纯文本的协议，在最早期，它的处理效率并不高。而H.323是二进制协议，非常紧凑，非常省带宽。但最终胜出的是SIP而不是H.323，为什么会这样？
50 |
51 | 答案在于技术发展的大趋势：随着计算能力的不断提升，算力越来越强，字符串处理的效率已经不再是根本问题。SIP基于文本的特性使其更加灵活、可扩展，更易于调试和实现，这些优势在长期来看远比短期的效率优势更加重要。
52 |
53 | 这个案例告诉我们，协议设计不应该过于关注当前技术条件下的优化，而应该着眼于长期的技术发展趋势和易用性、灵活性等因素。
54 |
55 | ## 协议的未来：向自然语言演进？
56 |
57 | 展望未来，协议有没有可能全部进化为自然语言？这个是有很大概率会发生的，特别是控制层的协议。在传输媒体层的协议上，它可能还是保持现在的二进制形式，因为效率和精确性的考虑。但控制协议完全有可能进化为自然语言形式，而且我认为这个大概率会发生。
58 |
59 | 随着大语言模型能力的不断提升，自然语言作为人机交互和机器间交互的媒介将变得越来越自然。控制层协议使用自然语言有几个优势：
60 |
61 | 1. **降低开发门槛**：使用自然语言描述需求和功能，可以让更多非技术人员参与到协议设计和使用中。
62 | 2. **提高灵活性**：自然语言比严格格式的协议更加灵活，可以处理更多歧义和不确定性。
63 | 3. **无缝集成**：随着AI的普及，自然语言将成为人与AI、AI与AI之间最自然的交流方式。
64 |
65 | ## 区块链协议：另一种世界观的体现
66 |
67 | 最后，值得一提的是比特币协议，它是另一个反映不同世界观的重要例子。比特币协议体现了区块链、Web3背后的去中心化、不可篡改、共识机制等核心思想。
68 |
69 | 比特币协议设计了一个没有中心节点、基于数学和加密学原理的价值传输系统，它不依赖于任何中央机构或信任第三方。这种设计背后反映的是对传统金融体系的不信任，以及对一个更加开放、透明、无需信任的经济系统的向往。
70 |
71 | ## 智能体互联网的愿景
72 |
73 | 未来的智能体互联网会呈现什么样的特性？基于我们的研究，智能体互联网可能具有以下特点：
74 |
75 | 1. **智能体渗透到互联网的各个角落**：一个人或组织可能有多个智能体为其服务。
76 | 2. **所有智能体之间都可以互联互通**：这是释放AI能力的必要条件。
77 | 3. **个人助手成为互联网的新入口**：智能体之间的连接远大于人与智能体之间的连接。
78 | 4. **网络更加扁平化**：智能体之间可以直接连接，无需三方平台的中介。
79 |
80 | 在这样的背景下，什么样的协议能够胜出？我们认为，最终胜出的协议必须能够支持智能体之间的无缝连接与协作，必须足够灵活以适应未来AI技术的飞速发展，同时还要具备可扩展性和安全性。
81 |
82 | ## 结语
83 |
84 | 协议设计是对世界的一种理解和塑造。当我们设计一个协议时，我们不仅仅是在设计技术细节，更是在描绘我们心目中的世界运行模式，以及我们对未来的期望和预测。
85 |
86 | 成功的协议不仅仅取决于其技术优势，更取决于它是否符合技术发展的大趋势，是否能够最大化地释放新技术的能力。在智能体时代，我们需要的协议应该能够支持智能体之间的自由连接、高效协作，同时为人类创造更多价值。
87 |
88 | 无论是MCP、ANP还是其他协议，它们都在尝试描绘未来智能体互联网的蓝图。只有那些真正理解技术发展趋势，并能够适应未来需求的协议，才能够在历史长河中留下自己的印记。
--------------------------------------------------------------------------------
/blogs/cn/关于智能体身份的三个关键问题：互联互通、人类授权、隐私保护.md:
--------------------------------------------------------------------------------
1 | # 关于智能体身份的三个关键问题：互联互通、人类授权、隐私保护
2 |
3 | 我们基本可以确定，智能体将以前所未有的方式参与到我们的数字生活中，从个人助理到各类专业服务智能体，它们需要一套完善的身份系统来确保智能体之间安全、高效的交互。
4 |
5 | 本文将深入探讨智能体身份面临的三个关键问题：
6 | - **互联互通**：如何让所有的智能体都能够进行通信与协作，是智能体身份最核心的一个问题。它能够打破数字孤岛，让AI真正的获得完整的上下文，提供更为智能的交互体验。
7 | - **人类授权**：在敏感、重要的请求中，如何判断这个请求是人类的手动授权，还是智能体自主发起的请求？我们既要能够让智能体代表人类访问互联网，又要能够限制智能体的权限。
8 | - **隐私保护**：如何防止智能体在交互过程中泄漏用户的隐私信息？
9 |
10 | 我们介绍智能体通信协议 Agent Network Protocol (ANP)在这三个问题上的思考与设计。
11 |
12 | ## 为什么智能体身份至关重要
13 |
14 | 自互联网诞生以来，身份认证一直是数字世界的核心问题。从最初的用户名密码，到后来的双因素认证、生物识别，身份验证技术不断演进。而今，随着智能体时代的到来，身份认证面临新的挑战。
15 |
16 | 智能体不同于传统软件，它们具有自主性、学习能力和决策能力。在智能体互联网中，智能体需要：
17 | 智能体不同于传统软件，它们具有自主性、学习能力和决策能力。在智能体互联网中，智能体需要：
18 |
19 | - **作为数字公民**：拥有自己的身份，能够被其他智能体和系统识别和信任
20 | - **代表用户行事**：获得适当的授权，代表用户执行各种任务和交易
21 | - **跨平台协作**：与不同平台的智能体和服务无缝交互，形成协作网络
22 | - **保护用户隐私**：在代表用户行动的同时，保护用户的隐私和安全
23 |
24 | 正如我们在《智能体互联网有什么不同》中所讨论的，要释放AI的能力，需要让AI能够获得完整的上下文信息，能够调用互联网上的所有工具，能够用它最擅长的方式与互联网交互，能够与其他AI高效协作。而这一切的前提，就是一个强大而灵活的智能体身份系统。
25 |
26 | ## 关键问题一：互联互通—打破身份孤岛
27 |
28 | 这是智能体身份最关键，也是最难解决的问题。
29 |
30 | 在当前的互联网环境中，身份系统大多是平台孤岛。你的微信账号在钉钉中无法使用，你的支付宝账号也无法直接在京东上购物。
31 |
32 | 这种身份碎片化在智能体时代将成为严重阻碍，因为智能体需要在各种服务之间自由移动，以获取信息和执行任务。
33 |
34 | 如果一个智能体要调用另一个智能体的服务，但它们分属不同平台，使用不同的身份系统，那么协作将变得极其复杂，可能需要用户手动介入多次，这显然与智能体减轻用户负担的初衷相违背。
35 |
36 | ### 现有解决方案的分析
37 |
38 | 在寻找解决方案的过程中，我们对比研究了互联网现有的多种身份认证技术：
39 |
40 | - **OpenID Connect**：虽然广泛用于单点登录，但其中心化特性和复杂的流程不适合智能体之间的高效交互，从根本上讲，OpenID Connect也并非未来解决身份的互联互通而设计。
41 | - **API Keys**：广泛用于API对接，简单直接但安全性受限，且依然需要用户手动注册和配置，注册和配置过程会降低智能体交互的效率。
42 | - **区块链身份解决方案**：去中心化程度高，但可扩展性和性能存在挑战。按照当前的技术，支持数十亿人用户使用是有很大的挑战的。
43 | - **Email协议**：简单且去中心化，而且这个去中心化和我们理想中的去中心化是一致。email协议专为电子邮件业务设计，底层没有使用HTTP，无法复用现有成熟的web基础设施。
44 | - **Nostr和AT Protocols**：新兴的去中心化协议，但尚未广泛采用。AT Protocols是我非常看好的协议，身份认证也使用W3C did，而且基于这个协议的应用Bluesky，很可能就是未来微信的样子。
45 | - **W3C DID**：W3C去中心化标识符(DID)规范，设计的目的就是为了解决身份中心化带来的各种问题，并且在2022年发布为推荐标准。但是互联网并未广泛使用。
46 |
47 | ### W3C DID是智能体身份最佳方案
48 |
49 | W3C DID在发布后，一直没有广泛的应用。但是分析完所有的技术后，我们坚定的认为，W3C DID绝对是最适合智能的身份技术，再设计一个新的也很难比它做的更好。
50 |
51 | 有几点原因：
52 | - W3C DID天生为去中心化和身份的互操作性而设计，非常完美的契合了智能体需要互联互通的需求。
53 | - W3C DID的实现更加的灵活，它现阶段并不强求底层去中心化实现，比如，并不要求一定要用区块链实现DID。这给开发者更多的选择。
54 | - 我们基于did:web方法设计了一个面向智能体的新方法实现，这个方法既能够实现去中心化，又能够重复的复用现有成熟的web基础设施，能够支持十亿百亿智能体使用。
55 |
56 | W3C DID原有的规范加上我们的方法实现，我认为是当前最适合智能体的身份方案。
57 |
58 | 方案详细的介绍：[did:wba-基于web的去中心化身份标识符](/blogs/cn/did-wba-基于web的去中心化身份标识符.md
59 |
60 | ## 关键问题二：人类授权—确保关键操作的安全性
61 |
62 | 随着智能体越来越多地代表人类执行任务，一个关键问题越来越重要：智能体对外发出的请求，是否获得人类手动授权。
63 |
64 | 例如，一个智能体可以代替用户自主浏览酒店信息，但当它要进行实际预订和支付时，应当获得人类的手动授权。
65 |
66 | 缺乏这种区分机制可能导致两种风险：一是智能体过度谨慎，频繁打断用户确认简单操作；二是智能体过度自主，在关键决策上缺乏必要的人类监督，从而给人类带来资产损失。
67 |
68 | ### did:wba的人类授权机制
69 |
70 | ANP协议通过did:wba规范提出了一个优雅的解决方案：人类授权与智能体自动授权的明确区分机制。
71 |
72 | 在did:wba文档中，我们引入了`humanAuthorization`字段，用于存储专门用于人类授权的公钥信息：
73 |
74 | ```json
75 | "humanAuthorization": [
76 | "did:wba:example.com%3A8800:user:alice#WjKgJV7VRw3hmgU6--4v15c0Aewbcvat1BsRFTIqa5Q",
77 | {
78 | "id": "did:wba:example.com%3A8800:user:alice#key-3",
79 | "type": "Ed25519VerificationKey2020",
80 | "controller": "did:wba:example.com%3A8800:user:alice",
81 | "publicKeyMultibase": "z9XK2BVwLNv6gmMNbm4uVAjZpfkcJDwDwnZn6z3wweKLo"
82 | }
83 | ]
84 | ```
85 |
86 | 这一机制的工作原理是：
87 |
88 | 1. **默认授权**：对于不敏感的操作，智能体可以使用普通验证方法进行签名和授权，无需人类干预。
89 | 2. **人类授权**：对于重要操作（如购买、支付、隐私数据访问），需要使用`humanAuthorization`中定义的密钥进行签名，这通常需要人类通过生物识别等方式显式、手动授权。
90 |
91 | 在智能体描述协议中，服务提供方可以明确指定哪些接口需要人类手动授权：
92 |
93 | ```json
94 | {
95 | "@type": "ad:StructuredInterface",
96 | "protocol": "YAML",
97 | "humanAuthorization": true,
98 | "url": "https://agent-network-protocol.com/api/purchase-interface.yaml",
99 | "description": "A YAML file for interacting with the intelligent agent through purchase."
100 | }
101 | ```
102 |
103 | 通过这种机制，我们实现了智能体自主性和安全性的平衡：智能体可以自由执行日常任务，同时关键操作依然受到严格控制，确保用户的资金安全和数据隐私。
104 |
105 | 智能体的开发人员需要对humanAuthorization对应的私钥进行安全的保管，同时进行权限隔离，比如，只有经过生物识别（指纹、人脸识别等）验证用户后，才能使用humanAuthorization进行签名。
106 |
107 | ## 问题三：隐私保护—防止行为追踪与画像
108 |
109 | 随着智能体在各种平台上代表用户活动，一个更微妙但同样重要的问题出现了：如何防止用户的行为被跟踪和分析？如果一个用户使用同一个身份标识符访问不同服务，这些服务可能会合作构建该用户的详细行为画像，侵犯用户隐私。
110 |
111 | ### did:wba的多身份策略
112 |
113 | 为解决这一问题，ANP协议在did:wba规范中提出了多身份策略：
114 |
115 | 1. **主DID**：用户拥有一个主DID，通常保持相对稳定，用于维护社交关系等需要持久身份的场景。
116 | 2. **子DID**：用户同时拥有多个从属于主DID的子DID，用于不同的交互场景，如购物、餐饮预订、内容订阅等。
117 | 3. **周期性更新**：子DID可以定期更新，旧的DID可以停用，申请新的DID，增加追踪难度。
118 |
119 | 这种多层次身份架构使用户能够在不同场景下使用不同身份，防止跨平台行为关联，同时保持各DID之间的从属关系，便于用户管理。
120 |
121 | 最重要的是，这一设计赋予了用户对自己数字身份的控制权，使其能够决定何时、何地以及如何展示自己的身份信息，真正实现"用户数据由用户掌控"的愿景。
122 |
123 |
124 |
125 | ## 版权声明
126 | Copyright (c) 2024 GaoWei Chang
127 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
128 |
129 |
130 |
131 |
--------------------------------------------------------------------------------
/blogs/cn/多角度全面对比Google最新的A2A、ANP、MCP.md:
--------------------------------------------------------------------------------
1 | # 多角度全面对比Google最新的A2A、ANP、MCP
2 |
3 | 谷歌刚刚发布了一个新的智能体通信协议A2A(Agent to Agent)，本文会从多个方面全面对比A2A、ANP、MCP。
4 |
5 | ## 解决的问题
6 |
7 | ANP和A2A都是为了解决智能体之间的通信问题，都看到了MCP在智能体通信上的局限性：MCP更加擅长于让模型连接工具与资源。
8 |
9 | 同时，ANP和A2A都认为自己是和MCP互补的。ANP与A2A则有一定的重合，之所以是“一定的重合”，是因为看下来，A2A好像想解决的是企业内部的智能体协作，虽然官网没有明确地说明这一点，但是我从他们的设计中能够感受到这一点，特别是在Task的设计上。
10 |
11 | ## 设计原则
12 |
13 | 在设计原则上，ANP与A2A有很多相似之处：
14 | - 强调简单，并且复用现有的协议。
15 | - 强调身份，智能体身份是ANP最核心的模块。
16 | - 解耦（不透明）：智能体不必共享思考过程、计划或工具。这是ANP、A2A与MCP在设计细节上最大的区别。
17 |
18 | A2A应该也看到了MCP的复杂性，选择使用Task来作为核心的概念，Task确实是比Tools、Resources更加抽象，更高level的概念。
19 |
20 | MCP的Tools和Resources也是非常适合MCP的概念，但是sampling、root的设计我认为需要斟酌一下。
21 |
22 | ## 协议架构
23 |
24 | ANP与A2A在协议架构上都可以看做P2P架构。MCP是典型的C/S架构，不单单是连接上，也包括协议的概念、角色设定上。
25 |
26 | 无疑P2P架构更适合智能体网络。
27 |
28 | ## 传输层
29 |
30 | 都支持HTTP，除此之外，MCP由于需要访问本地资源，为了方便，还支持stdio。
31 |
32 | ## 核心概念
33 |
34 | MCP的核心概念是Tools、Resources、Sampling、Root、Prompts。
35 |
36 | A2A的核心概念是Task、Artifact（工件）、Message、Part。
37 |
38 | ANP的核心概念是Interface：包括NaturalLanguageInterface（自然语言接口）、StructuredInterface（结构化接口）。
39 |
40 | ANP是将智能体交互方式的定义下放到了Interface中。比如，Interface可以是一个预订酒店的API，这个API直接返回结果。也可以是类似A2A的Task，在Interface中定义Task的状态。但是在协议层，我们没有直接显式的定义Task以及状态。
41 |
42 | 从不透明程度看：
43 | - MCP是白盒，能够查看对方内部的文件、工具、资源等信息
44 | - A2A是灰盒，虽然不共享智能体的思考过程、计划或工具，但是仍然定义了智能体之间的任务，以及任务的状态等
45 | - ANP是黑盒，两个智能体完全不透明，只交付最终结果。同时保留灵活性。
46 |
47 | ## 智能体身份
48 |
49 | 这块的差异非常的大。
50 |
51 | **ANP**
52 |
53 | 协议本身会携带身份信息、身份验证信息，目前主要是使用W3C的DID方案，一个智能体可以用自己的身份信息，与其他所有的智能体进行交互，不必在其他智能体平台申请账号。
54 |
55 | 我们认为DID是最适合智能体的身份方案，特别是在互联网场景下。当然也可扩展其他的身份认证方式。
56 |
57 | **A2A**
58 |
59 | A2A采用OpenAPI支持的认证方式，包括：HTTP 认证（如 Basic、Bearer）、API Key（可放在请求头、查询参数或 Cookie）、Cookie 认证、OAuth 2.0 以及 OpenID Connect。
60 |
61 | A2A协议本身不携带身份信息，只携带身份验证信息，身份验证信息在带外获得，即在A2A协议之外通过其他的手段获得，比如通过Oauth。
62 |
63 | A2A的设计使其能够充分利用企业现有的身份体系。但是，在智能体互联网的场景中，如果要实现任意智能体之间的连接，A2A用起来会麻烦一些。
64 |
65 | **MCP**
66 |
67 | MCP使用Oauth做的身份验证，也是一个中心化的方案，在连接工具和资源这个场景是适合的。
68 |
69 | ## 智能体描述
70 |
71 | ANP与A2A比较类似，都是使用JSON。
72 |
73 | A2A的智能体描述文档命名为Agent Card，本质上是一个json文档。
74 |
75 | ANP的智能体描述则是基于JSON-LD和schema.org，这是语义网的技术，目的是提高两个智能体对信息理解的一致性。
76 |
77 | ## 智能体发现
78 |
79 | MCP的发现规范还没有看到，不过大概率用和ANP、A2A类似的发现机制。
80 |
81 | ANP和A2A都是基于RFC 8615做的，相当于在一个域名的.well-known目录下增加一个元数据文档，A2A的文件名是agent.json，ANP的文件名是agent-descriptions。
82 |
83 | 使用这个方案，都可以被搜索引擎非常方便地抓取到。
84 |
85 | ## 智能体信息组织
86 |
87 | 在智能体或者MCP server对外的信息组织上，A2A和MCP都使用的是JSON-RPC，类似一种远程调用技术。
88 |
89 | ANP在这里比较独特，ANP采用的是语义网的Linked-Data技术，目标是构建一个便于AI访问和理解的AI原生数据网络。
90 |
91 | 
92 |
93 | 从这个角度看，ANP的技术路线更加靠近Web，我们认为未来的智能体互联网是一个非常开放的网络，只有这样才能够让信息自由地流动，进而释放AI的能力。
94 |
95 |
96 | ## 开源license
97 |
98 | ANP的license是MIT，Google-A2A的license是Apache 2.0。
99 |
100 | 我仔细研究了一下，后面如果要推到大厂、参与标准化、走国际化路线，Apache 2.0 会是企业法律部门优先认可的协议。MIT 虽然简单，但在你这种有专利潜在风险和商业化路径的协议项目里，容易被企业法律团队卡住。
101 |
102 | 开源许可上ANP会修改为Apache 2.0。
103 |
104 | ## 趋势
105 |
106 | 虽然说A2A号称与MCP是互补的，但是在阅读文档的过程中，我隐约看到一个可能：**工具Agent化，Agent工具化**。
107 |
108 | 现有的工具，是否可以进化成一个Agent？未来的Agent，是否也是一个工具？
109 |
110 | 如果从这个角度看，MCP和A2A，包括ANP，应该会有一定的重叠。
111 |
112 | ## 对行业智能体协议的影响
113 |
114 | MCP已经成为模型连接工具与资源的事实标准，A2A短期是难以撼动的。不过对于ANP是有很大的影响的。
115 |
116 | 好的影响是，让智能体通信与协作被更多的人看到。之前MCP火的时候，我们去讲ANP，很多人是不理解的。现在我们不用再强调智能体通信协作的重要性了。
117 |
118 | 坏的影响是，A2A和ANP有很大部分功能是重叠的，A2A背靠谷歌，影响力非常大，ANP主要靠开源社区，影响力无法比。这对ANP的发展是不利的。
119 |
120 | ## 最后
121 |
122 | ANP最有价值的部分，其实是社区对未来智能体互联网的设想，社区独特的互联网理念（连接即权力），以及DID+语义网的技术路线。
123 |
124 | 如果你也认可我们的理念，认可我们对未来智能体互联网的设想，欢迎加入我们，无论是以个人，还是以公司名义，**我们需要你的支持**。
125 |
126 | 我们正在筹备ANP开源技术社区创始委员会，这是一个临时委员会，目的是为了让社区能够走向正轨，成长为一个更加开放的社区。感兴趣可以联系我。
127 |
128 |
--------------------------------------------------------------------------------
/blogs/cn/智能体互联网有什么不同.md:
--------------------------------------------------------------------------------
1 |
2 | # 智能体互联网(Agentic Web)有什么不同
3 |
4 | 智能体基本上已经成为**AI行业的共识**，如果说有分歧，大概率也是对落地的时间有分歧。当下行业主要关注的还是智能体本身如何构建，对于智能体之间如何协作、智能体网络的特征，研究的不是很多。
5 |
6 | 在这篇文章中，我们尝试从互联网演进的本质：**释放新技术的能力**，来探讨智能体互联网(Agentic Web)与现有互联网的不同。
7 |
8 | 我们认为智能体除了对软件本身有大的改变外，智能体对互联网也会带来**深刻的改变**。
9 |
10 | 以现有全球互联网市场规模来看，智能体互联网有什么不同之处，至少是一个千亿美金问题。
11 |
12 | 本文要点：
13 |
14 | - 互联网演进方向的最本质问题，是如何**最大限度地释放新技术的能力**。下一代互联网肯定会因为AI技术的发展，而作出深刻的改变。
15 | - 要释放AI的能力，需要让AI能够获得完整的上下文信息，能够调用互联网上的所有工具，能够让AI用它最擅长的方式与互联网交互，能够让AI高效地与互联网上的其他AI协作。
16 | - 为此，我们需要解决三个问题：**互联互通**、**原生接口**、**高效协作**。
17 | - API或通信协议是AI与互联网交互的最佳方式。我们不看好Computer Use技术，因为它是让AI模仿人；AI手机提供了一个在终端打通各个APP的方案；Anthropic的MCP是最符合我们设想的技术。
18 | - **个人助理**会成为下一代互联网的新入口，智能体渗透到互联网的各个角落，智能体可以互联互通，它们可以自组织、自协商，构建一个高效协作网络。
19 | - 我们正在开发一个用于智能体通信的开源协议：AgentNetworkProtocol(ANP)，目标是成为智能体互联网时代的HTTP。
20 |
21 | ## 决定互联网演进方向的本质问题是什么
22 |
23 | 我们认为，推动互联网演进的最本质问题，或者最底层的推动力，是如何**释放新技术的能力**。
24 |
25 | 我们分析一个问题，为什么PC互联网时代产品以web为主，而移动互联网时代却是以APP为主？
26 |
27 | PC互联网时期，新技术以网络通信技术（TCP/IP、DNS、HTTP）、Web技术（HTML、CSS、JavaScript）、数据库技术、信息搜索等技术为主。以浏览器和Web技术为媒介的产品形态，释放了开放互联网的访问能力，让信息可以通过统一入口被广泛获取。
28 |
29 | 再加上当时的技术条件（有限的带宽和硬件性能），以及web技术跨平台特性，决定了Web是最适合PC互联网的产品形态。
30 |
31 | 而到了移动互联时期，新出现的技术包括移动设备与硬件（加速计、陀螺仪、GPS、触摸屏、摄像头、芯片）、移动网络（3G、4G、5G）、移动操作系统（iOS、Android）等。
32 |
33 | APP相对于web技术，能够通过操作系统的API深度整合硬件能力，针对设备性能优化运行效率，能够持续在线并且实时互动。
34 |
35 | 正是这些因素，新的技术能力才通过APP释放出来，APP的体验也远超web，让APP也成为了移动互联网时代的主流产品形态。
36 |
37 | 在当下以及未来10年，新技术无疑是以生成式人工智能、大语言模型、智能体为代表的AI技术。如何释放AI的能力，决定了未来互联网的演进方向。
38 |
39 | ## 下一代互联网应如何释放AI的能力
40 |
41 | 当前的互联网基础设施已经相当的完善，但是面对AI的特性，要充分释放AI的能力，还面临一些挑战。
42 |
43 | ### 如何让AI获得**完整的上下文信息**，如何让AI调用**所有的工具能力**
44 |
45 | AI只有获得完整的上下文信息，才能做出正确的决策。只有能够调用所有的工具能力，才能高效的完成复杂任务。
46 |
47 | 但是当前的互联网本质上由一个个的信息孤岛组成，孤岛之间信息流动困难。
48 |
49 |
50 | 
51 |
52 |
53 | 在之前，人类其实扮演了信息孤岛的缝合怪的角色，通过浏览器、APP、搜索引擎、社交网络等，将这些信息孤岛连接起来。未来，这将由AI更加高效的完成。
54 |
55 | 当前已经有技术方案在尝试解决这些问题，典型的比如AI手机、Computer Use技术，让AI利用图形界面、浏览器或者APP终端接口，来打通AI与互联网的连接。但我们认为，这些都不是最高效的方案。
56 |
57 | ### 如何让AI用它最擅长的方式接入互联网
58 |
59 | 点评一下当下AI接入互联网的方案。
60 |
61 | 1. **Computer Use技术**
62 |
63 | 很多模型厂商都推出了类似的方案。
64 |
65 |
66 |
67 |
68 |
69 | 但我一向不看好这个技术。这个技术出现的原因是，原有的互联网产品是为人类使用而设计，在这些产品面向AI重构之前，让AI学习、模仿人类，确实是AI接入互联网的最快途径。但不是最高效的路径。短期和中期可能有价值，长期价值不大。
70 |
71 | 2. **AI手机方案**
72 |
73 | 比如apple intelligence，国内很多手机厂商也在大力推广。
74 |
75 | 这类技术的特点是，在终端上，通过APP客户端开放的接口，打通互联网的数据与能力。让AI能够获得多个APP的数据，调用多个APP的能力。
76 |
77 | 这个技术比Computer Use技术更进一步，AI天生擅长处理底层数据，而非图形界面。但是在这个方案中，终端上的APP定位非常的尴尬，和AI手机是处于既竞争又合作的状态，既想获得AI手机带来的流量，又不想开放太多数据以被AI手机替代。
78 |
79 | 3. **Claude MCP**
80 |
81 | 这是当下最符合我们设想的方案。
82 |
83 | 我们认为，**AI不同于人类，它更擅长处理底层数据而非图形界面**。AI应该用它最擅长的方式（**API或通信协议**），与互联网交互。
84 |
85 |
86 |
87 |
88 |
89 | 我们也很早就在做类似的项目和研究：[Agent Network Protocol技术白皮书](https://mp.weixin.qq.com/s/17pNcvi1klEwuqDrEbLzJw)。
90 |
91 | 我们与MCP最大的区别在于世界观的差异：
92 | - MCP是以模型为核心，整个互联网都是他的上下文与工具；
93 | - 我们（Agent Network Protocol）以智能体为核心，每个智能体具有同等的地位，组成一个去中心化的智能体协作网络。
94 |
95 | ### 如何让AI高效的与互联网上的其他AI协作
96 |
97 | 传统的网络节点，往往通过硬编码或人工的方式来进行连接。有了AI之后，网络的连接、协作方式也许可以更加的高效。
98 |
99 | 比如，两个AI节点可以利用自然语言的生成与理解能力，先使用自然语言沟通双方的能力与接口，然后使用标准协议或共识协议进行通信与协作。
100 |
101 | 这将有助于构建一个更加高效、更低成本的协作网络。
102 |
103 |
104 | 
105 |
106 |
107 |
108 | 最后再总结一下，互联网要想充分的释放AI的能力，还需要解决以下三个问题：
109 |
110 | - 🌐 **互联互通**：让所有的智能体相互之间都能够进行通信，打破数据孤岛，让AI能够获得完整的上下文信息，能够调用互联网上的所有工具。
111 | - 🖥️ **原生接口**：AI无需模仿人类访问互联网，AI应该用它最擅长的方式（API或通信协议）与互联网交互。
112 | - 🤝 **高效协作**：利用AI，智能体之间可以自组织、自协商，构建比现有互联网更低成本、更高效率的协作网络。
113 |
114 | ## 智能体互联网(Agentic Web)是什么样的
115 |
116 | 关于智能体互联网的定义，是个比较大的命题，我们给不了学术上的严谨定义。但是我们可以从通俗的角度阐述下我们对它的理解。这也算是盲人摸象，给出我们“摸到”的部分。
117 |
118 | 1. **智能体成为新入口**
119 |
120 | PC互联网是人用PC上网；移动互联网是人使用移动终端上网；智能体互联网，则是智能体代替人上网，代替人与数字世界交互。
121 |
122 | 这个入口未来大概率是一个特殊的智能体：超级个人助理。它代替人类上网，并且在客户端通过个性化的UI与人类交互。在后端通过API或协议，与其他的智能体进行交互。
123 |
124 |
125 | 
126 |
127 |
128 | 2. **智能体渗透到互联网的各个角落**
129 |
130 | 除了个人助理，我们认为互联网还有很多不直接与最终用户交互的智能体，比如酒店、餐厅、银行、学校等智能体。他们通过与个人助理的交互，间接的为人提供服务。
131 |
132 | 3. **智能体可以互联互通**
133 |
134 | 无论是个人助理，还是背后提供服务的智能体，无论他们属于哪个公司，哪个平台，他们都可以互联互通。
135 |
136 | 4. **一个更加扁平的网络**
137 |
138 | 如果智能体能够代表一个人或一个实体作为互联网中的一个节点互相连接协作，那中心化平台（比如微信、淘宝）的作用会降低。未来的互联网会更加的扁平化、去中心化。
139 |
140 | 5. **自组织自协商的高效协作网络**
141 |
142 | 智能体之间可以自组织、自协商，构建一个高效协作网络。
143 |
144 | ## 总结
145 |
146 | 归根到底，我们认为是技术的发展推动了互联网的演进，如何释放新技术的能力，决定了互联网的演进方向。
147 |
148 | 智能体互联网会不会出现，我们现在还不确定，但是我们可以确定的是，未来互联网肯定会因为AI技术的发展而深刻的改变。
149 |
150 | ## 联系我们
151 |
152 | 我们不是空想家。
153 |
154 | 我们正在根据我们的设想，开发一个用于智能体通信的开源标准协议：**AgentNetworkProtocol(ANP)**，项目地址：[https://github.com/agent-network-protocol/AgentNetworkProtocol](https://github.com/agent-network-protocol/AgentNetworkProtocol)。
155 |
156 | AgentNetworkProtocol的目标是成为智能体互联网时代的HTTP。我们的愿景是定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络。
157 |
158 | 如果你也对智能体通信协议或智能体互联网感兴趣，欢迎联系我们。我们最近正在和国内外的AI从业者分享交流：
159 |
160 | - 微信：flow10240
161 | - 邮箱：chgaowei@gmail.com
162 |
163 |
164 | **最后**，我始终认为，如果不考虑扩展性，web3真的是最适合AI的互联网形态。如果你在做web3+AI，也欢迎和我们交流。
165 |
166 |
167 |
168 |
169 | ## 版权声明
170 | Copyright (c) 2024 GaoWei Chang
171 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
172 |
--------------------------------------------------------------------------------
/blogs/cn/智能体协议汇总.md:
--------------------------------------------------------------------------------
1 | # 智能体通信协议汇总
2 |
3 | 以下是当前主流智能体通信协议的详细介绍与对比：
4 |
5 | ---
6 |
7 | ## 1. MCP（Model Context Protocol）
8 |
9 | - **开发团队**：由 Anthropic 推出
10 | - **解决问题**：旨在为大型语言模型（LLM）提供标准化的接口，以便连接和交互外部数据源和工具
11 | - **技术路线**：基于 JSON-RPC 2.0 消息格式，建立状态连接，支持服务器和客户端的能力协商
12 | - **生态发展**：已成为行业事实标准，被广泛采用
13 | - **官方网站**：https://spec.modelcontextprotocol.io/specification/
14 |
15 | ---
16 |
17 | ## 2. ANP（Agent Network Protocol）
18 |
19 | - **开发团队**：由中国本土团队主导开发，代表人物为常高伟，已在 GitHub 上开源，是国内较早的智能体通信协议之一
20 | - **解决问题**：致力于解决智能体之间的身份认证、加密通信与协议协商问题，目标是打造智能体时代的"HTTP"
21 | - **技术路线**：采用去中心化架构，基于 W3C DID（去中心化身份标识符）标准实现身份认证与端到端加密。引入"元协议层"，支持自然语言驱动的协议协商和代码生成，让智能体根据上下文协商通讯协议。整个网络是点对点网状结构，无需中心化服务器
22 | - **生态发展**：已开源，提供参考实现（如 AgentConnect），在中国开源社区和高校开发者中获得关注，并参与了 W3C WebAgents 工作组。当前生态尚以国内为主，正在拓展国际合作
23 | - **官方网站**：https://agent-network-protocol.com/
24 |
25 | ---
26 |
27 | ## 3. Agora Protocol
28 |
29 | - **开发团队**：由牛津大学与 Eigent AI 提出，是一个研究性元协议，目标是实现灵活、高效和可移植性的平衡
30 | - **解决问题**：应对"智能体通信三难问题"（三元悖论）：通用性、效率、移植性难以兼得。当前智能体往往难以跨平台通信或自适应协议格式
31 | - **技术路线**：使用 LLM 的理解能力驱动"协议文档"（Protocol Documents）交换，智能体通过自然语言描述通信协议并达成共识。分为三层协议：常用场景走已知 API，复杂场景通过 LLM 生成协议，极端情况下用自然语言协商
32 | - **生态发展**：目前处于概念验证阶段，尚无开源实现，属于学术层面研究，尚未进入工业化应用
33 | - **官方网站**：https://agora-protocol.org/
34 |
35 | ---
36 |
37 | ## 4. Agent Protocol
38 |
39 | - **开发团队**：由社区主导，AI Engineer Foundation 发起，核心开发者为 Div99，目标是定义统一的智能体 API
40 | - **解决问题**：解决当前智能体系统间接口不统一、集成难度大、工具不可复用的问题，便于互操作和性能对比
41 | - **技术路线**：提供一套 RESTful API 规范（OpenAPI 格式），支持启动、重置、发送目标、流式输出等核心操作，未来计划扩展支持支付等能力
42 | - **生态发展**：已在 Auto-GPT 社区获得初步采用，用于智能体评测和标准化调用。提供 TypeScript 和 Python SDK，逐步成为通用"智能体接口协议"候选
43 | - **官方网站**：https://github.com/AI-Engineer-Foundation/agent-protocol
44 |
45 | ---
46 |
47 | ## 5. agents.json
48 |
49 | - **开发团队**：由社区成员（如 Wildcard AI）提出，尚未正式标准化
50 | - **解决问题**：网站缺乏机器可读方式向 AI 智能体暴露可交互能力，agents.json 允许网站声明接口、认证方式、权限、使用政策等，避免爬虫抓取人类界面
51 | - **技术路线**：灵感来自 robots.txt 和 sitemap.xml，是一个标准的 JSON 文件，部署在 `/.well-known/agents.json` 路径下，包含网站提供的智能体可用接口与权限要求
52 | - **生态发展**：目前尚处于草案阶段，尚未有主流平台支持，但在 Reddit 与技术博客中获得开发者讨论，未来有望成为 Web3 或 AI Web 的关键基础设施
53 | - **官方网站**：https://docs.wild-card.ai/agentsjson/introduction
54 |
55 | ---
56 |
57 | ## 6. AITP（Agent Interaction & Transaction Protocol）
58 |
59 | - **开发团队**：由 NEAR Protocol（区块链平台）发起，NEAR 联合创始人 Illia Polosukhin 主导，2025 年初提出
60 | - **解决问题**：智能体缺乏在信任边界之间进行通信与价值交换的标准协议，AITP 旨在让智能体能在对话中协商、付款、订阅服务
61 | - **技术路线**：采用线程式对话模型，消息格式 JSON，具备扩展能力模块（如 payment、data request、决策协商等）。支持多种传输协议（HTTP/WebSocket），强调身份认证与加密通信
62 | - **生态发展**：由 NEAR AI Hub 率先采纳，应用于 Web3 场景，目前处于 alpha 阶段，NEAR 社区已有初步实现和演示，计划向其他生态扩展
63 | - **官方网站**：https://github.com/nearai/aitp
64 | - **应用平台**：https://app.near.ai/agents
65 |
66 | ---
67 |
68 | ## 7. ACP（Agent Connect Protocol，思科 AGNTCY 项目）
69 |
70 | - **开发团队**：由 Cisco（思科）发起，联合 LangChain、Galileo 等伙伴构建 AGNTCY 生态，2024 年末开源
71 | - **解决问题**：解决不同智能体框架之间无法互操作的问题，让 LangChain、Haystack 等不同框架的智能体能够互通
72 | - **技术路线**：提供标准化 OpenAPI 接口和 JSON 通信协议，配套 agent 描述标准（OASF）和目录服务，支持 agent 能力注册、发现与调用。强调安全认证与 streaming、多轮会话等功能
73 | - **生态发展**：获得 Cisco 企业背书，LangChain 等社区初步参与。已开源规范和 SDK，计划推向标准组织，目标是构建"智能体互联网"的通信层协议
74 | - **官方网站**：https://github.com/agntcy/acp-spec
75 |
76 | ---
77 |
78 | ## 8. ACP（Agent Communication Protocol，IBM）
79 |
80 | - **开发团队**：由 IBM Research 主导，作为 BeeAI 项目的一部分，于 2024 年底开始设计，目前处于 alpha 版本，由 Linux Foundation AI 社区托管
81 | - **解决问题**：基于 Anthropic MCP（模型上下文协议）延伸，解决智能体之间通信、功能发现和上下文共享问题，构建面向多智能体系统的标准化通信协议
82 | - **技术路线**：基于 JSON-RPC，兼容 MCP 格式并扩展，支持 agent 能力注册、对话管理、身份认证。强调实用优先，支持多种传输协议（HTTP、WebSocket），未来计划支持状态持久化、流式传输等
83 | - **生态发展**：由 IBM 开源发起，并希望社区共同演进，目前无大规模部署，目标是在企业多智能体系统中推广为标准协议
84 | - **官方网站**：https://docs.beeai.dev/acp/alpha/introduction
85 |
86 | ---
87 |
88 | ## 9. LMOS（Language Model Operating System）
89 |
90 | - **开发团队**：由 Eclipse 基金会孵化，原为德国电信（Deutsche Telekom）AI 基础设施项目，后转为社区开放项目
91 | - **解决问题**：当前多智能体系统部署和协作困难，缺乏统一基础设施，LMOS 旨在提供智能体发现、注册、通信、调度与安全的操作系统级基础框架
92 | - **技术路线**：借鉴 W3C Web of Things 标准，采用三层架构：身份层（DID）、传输层（可协商 HTTP/MQTT/P2P）、应用层（使用 JSON-LD 描述智能体能力）。支持本地和全局 discovery，具备组管理和权限体系
93 | - **生态发展**：在 Eclipse 社区中处于孵化期，尚未大规模商用，但已被视为可能统一多协议的平台，可集成 ANP、AITP、MCP 等协议。德国电信等企业支持使其具备落地潜力，未来有望成为行业通用基础设施
94 | - **官方网站**：https://eclipse.dev/lmos/docs/multi_agent_system/agent_communication
95 |
96 | ---
97 |
98 | ## 10. IEEE SA-P3394（大型语言模型代理接口标准）
99 |
100 | - **开发团队**：由IEEE标准协会组织的工作组主导开发
101 | - **解决问题**：为大型语言模型代理接口提供标准化规范，确保不同AI系统之间的互操作性
102 | - **技术路线**：正在开发参考实现，计划以BSD3许可证发布。专注于API规范设计，同时兼容多种通信协议
103 | - **生态发展**：已有约一年的发展历程，正在稳步推进标准化工作，得到业界广泛关注
104 | - **官方网站**：https://standards.ieee.org/ieee/3394/11377/
105 |
106 | ---
107 |
108 | ## 11. WOT（Web of Things）
109 |
110 | - **开发团队**：由W3C Web of Things工作组推动
111 | - **解决问题**：解决物联网设备之间互操作性和数据交换的挑战，为物联网提供标准化的web接口
112 | - **技术路线**：使用web技术连接物联网设备，简化跨平台设备访问与整合
113 | - **生态发展**：已经发展成为物联网领域的重要标准之一，被多个项目和平台采用
114 | - **官方网站**：https://webthings.io/
115 |
116 |
117 | ## 比较总结
118 |
119 | 这些智能体通信协议各有侧重点和应用场景，整体上可以分为几类：
120 |
121 | 1. **面向模型的协议**：如MCP，专注于模型与外部工具的交互
122 | 2. **面向智能体的协议**：如ANP、ACP，关注智能体之间的通信和协作
123 | 3. **面向网络的协议**：如WOT、Matter/Thread，专注于设备互联互通
124 | 4. **元协议**：如Agora，着眼于协议协商和动态生成
125 |
126 | 随着AI和智能体技术的发展，这些协议将朝着更标准化、更互操作、更安全可靠的方向演进，共同构建智能体互联网的基础设施。
--------------------------------------------------------------------------------
/blogs/cn/深入对比MCP、A2A、ANP的交互模式.md:
--------------------------------------------------------------------------------
1 | # 深入对比MCP、A2A、ANP的交互模式：信息组织方式的差异
2 |
3 | 这是MCP、A2A、ANP对比系列的第三篇文章，前面的两篇：
4 | - [多角度全面对比Google最新的A2A、ANP、MCP](/blogs/cn/多角度全面对比Google最新的A2A、ANP、MCP.md)
5 | - [深入对比谷歌A2A与ANP：找到协议的原点](/blogs/cn/深入对比谷歌A2A与ANP：找到协议的原点.md)
6 |
7 | 这篇文章将深入对比每个协议在交互模式上的差异，它们决定了一个工具或者智能体如何组织其信息，进而决定了信息处理的方式以及交互的特点。
8 |
9 | **先说结论**：
10 |
11 | - **MCP（远程调用）**：server直接向客户端公开全部工具与资源列表，客户端将这些信息传递给模型，模型根据需要通过RPC调用特定工具或访问特定资源。
12 |
13 | - **A2A（任务分包）**：智能体对外展示自身的能力概述，客户端智能体将复杂任务分解成子任务，并将子任务分配给有相应专长的智能体执行，最终整合结果。
14 |
15 | - **ANP（数据爬取）**：智能体将自身信息和接口组织为一个由URL链接的数据网络，客户端智能体如同网络爬虫一般，从描述文档入口开始，按需获取信息并在本地做决策，最后通过发现的接口执行操作。
16 |
17 | **三者核心区别**：
18 |
19 | - **A2A vs MCP**：A2A封装了实现细节，客户端只关心“做什么”而非“怎么做”，仅需提交任务并等待结果。
20 |
21 | - **ANP vs MCP**：MCP一次性返回所有工具/资源，而ANP只提供分级链接和描述，允许智能体按需探索和获取信息。
22 |
23 | - **ANP vs A2A**：两者都解决智能体交互，但A2A更注重复杂任务分解与协作，ANP更注重信息的灵活获取和本地决策，以降低隐私泄露风险。
24 |
25 | ANP基于现代Web技术构建，支持ANP协议的智能体通常被称为WebAgent。
26 |
27 | ## MCP的交互方式
28 |
29 | MCP 的交互模式采用经典的 客户端-服务器（C/S）架构。在初始请求中，会协商相互的能力，包括是否支持工具、资源等。
30 |
31 | 
32 |
33 | server一般都会支持两个核心的接口：tools/list和resources/list，客户端可以通过这两个接口获得所有的工具和资源的信息。这些信息包括元数据，即工具和资源的描述，用于让模型知道工具的能力以及如何调用，以及资源的详细信息。
34 |
35 | 模型根据需要，调用不同的工具，读取不同的资源。
36 |
37 | 以工具为例，交互如下：
38 |
39 | 
40 |
41 | 这种交互模式下，Server作为被动的一方，被动提供工具与资源，决定权在客户端的模型。
42 |
43 | ## A2A的交互方式
44 |
45 | A2A是一种灵活的P2P交互方式。在这种模式下，一个智能体（客户端Agent）可以直接与一个或多个其他智能体（远程Agent）对话协作，将一个大任务拆解为小任务，与其他智能体共同完成，类似于多个专业助手协同工作。
46 |
47 | 交互流程通常如下：
48 | 1. **发现与选择**：客户端 Agent 首先需要发现并定位适合当前任务的远程 Agent。它可以查询多个 Agent 的“Agent Card”（智能体能力卡片）—— 这就像一份技能简历，列出了每个 Agent 擅长的能力和服务方式。客户端 Agent 根据任务需求，选择一个或多个最合适的远程 Agent。
49 |
50 | 2. **任务拆分（可选）**：对于复杂任务，客户端 Agent 可以将其拆分成多个子任务。
51 |
52 | 3. **任务分派与协作**：客户端 Agent 通过 A2A 协议与选定的远程 Agent 建立连接，并将相应的（子）任务请求发送给它们。例如，将子任务 A 发送给远程 Agent A，子任务 B 发送给远程 Agent B。
53 |
54 | 4. **多轮交互与结果收集**：每个远程 Agent 独立执行分配给它的任务。在执行过程中，它们可以通过消息与客户端 Agent 进行多轮交互，反馈进展、提出澄清问题或返回中间结果。客户端 Agent 会分别接收来自不同远程 Agent 的反馈和结果。
55 |
56 | 5. **结果聚合与完成**：所有子任务完成后，客户端 Agent 收集并整合来自各个远程 Agent 的结果，最终形成整个任务的完整解决方案。
57 |
58 | 整个沟通过程可以包含任务上下文和状态跟踪，确保围绕特定（子）任务的对话有序进行。
59 |
60 | ```mermaid
61 | sequenceDiagram
62 | participant Client Agent
63 | participant Remote Agent A
64 | participant Remote Agent B
65 |
66 | Note over Client Agent: 1. Discovery Phase
67 | Client Agent->>Remote Agent A: Get Agent Card (/.well-known/agent.json)
68 | Remote Agent A-->>Client Agent: Return Agent Card (skills, authentication)
69 | Client Agent->>Remote Agent B: Get Agent Card (/.well-known/agent.json)
70 | Remote Agent B-->>Client Agent: Return Agent Card (skills, authentication)
71 |
72 | Note over Client Agent: 2. Task Splitting
73 | Client Agent-->>Client Agent: Split original task into Subtask A & Subtask B
74 |
75 | Note over Client Agent: 3. Subtask Submission to Remote Agent A
76 | Client Agent->>Remote Agent A: Send Subtask A (tasks/send)
77 |
78 | Note over Client Agent: 4. Subtask Submission to Remote Agent B
79 | Client Agent->>Remote Agent B: Send Subtask B (tasks/send)
80 |
81 | Note over Client Agent: 5. Collect Result A
82 | Remote Agent A-->>Client Agent: Return result A
83 |
84 | Note over Client Agent: 6. Collect Result B
85 | Remote Agent B-->>Client Agent: Return result B
86 |
87 | Note over Client Agent: 7. Task Completion & Aggregation
88 | Client Agent-->>Client Agent: Aggregate results and deliver final result
89 | ```
90 |
91 | 这种模式下，Client Agent和Remote Agent都会根据输入进行任务的处理，双方通过明确的任务描述和结果交互实现协作。
92 |
93 | ## ANP的交互方式
94 |
95 | ANP（Agent Network Protocol）也是一种P2P的交互方式，目标同样是解决智能体之间的通信问题。与A2A有一个根本区别：
96 |
97 | - A2A采用“任务分包”模式，智能体将任务拆分并分配给其他智能体执行
98 | - ANP采用“数据爬取”模式，智能体只会获取其他智能体的信息，自己在本地做决策，再通过API调用执行操作
99 |
100 | ANP的核心特点是使用“链接数据”（Linked Data）技术，将一个智能体的所有能力、接口和信息组织成一个可导航的数据网络。这与MCP直接返回所有工具和资源列表的方式不同。
101 |
102 | ### ANP交互流程
103 |
104 | 
105 |
106 | ANP交互过程就像网络爬虫浏览网页：
107 |
108 | 1. **入口发现**：智能体首先获取另一个智能体的“智能体描述文档”的URL（类似网站的首页）
109 |
110 | 2. **能力发现**：从描述文档中，智能体了解到对方的技能、接口和可用资源，以及更详细文档的URL链接
111 |
112 | 3. **选择性获取**：智能体根据当前任务的需要，只访问那些相关的URL，获取必要的信息（而不是所有信息）
113 |
114 | 4. **递归导航**：每个文档又可能包含新的URL链接，智能体可以根据需要继续导航和拉取
115 |
116 | 5. **本地决策**：收集足够信息后，智能体在自己的模型中进行逻辑判断和决策
117 |
118 | 6. **接口调用**：最后通过找到的API接口执行具体操作
119 |
120 | 这种方式的优势是智能体只获取它真正需要的信息，节省数据传输，并保持决策控制权在自己手中。
121 |
122 |
123 | ## 信息组织方式的差异
124 |
125 | 上面描述的交互方式的差异，本质上是每个协议在智能体对外公开信息的组织方式不同：
126 |
127 | - **MCP（全部公开）**：通过RPC调用的方式，一次性公开全部工具和资源列表，客户端智能体可直接选择并调用所需的工具
128 |
129 | - **A2A（能力卡片）**：通过Agent Card展示智能体的技能和能力概述，不透露具体实现细节，客户端只需要提交任务并等待结果
130 |
131 | - **ANP（链接网络）**：使用Linked-Data技术将智能体的信息组织成网状结构，客户端智能体可以像网络爬虫一样，按需选择性地获取特定信息
132 |
133 |
--------------------------------------------------------------------------------
/blogs/did-wba-security-principles.md:
--------------------------------------------------------------------------------
1 | # Security Principles of did:wba
2 |
3 | did:wba, as a Web-based Decentralized Identifier method, has security at its core. This article delves into the security principles of did:wba and analyzes how it ensures reliable and secure identity verification.
4 |
5 | Related did:wba resources:
6 | - did:wba Specification: [did:wba Specification](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/03-did%3Awba%20Method%20Design%20Specification.md)
7 | - A brief introduction to did:wba: [did:wba - Web-based Decentralized Identifier](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/did%3Awba%2C%20a%20Web-based%20Decentralized%20Identifier.md)
8 | - Comparison between did:wba and other solutions: [did:wba vs OpenID Connect and API keys](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/Comparison%20of%20did%3Awba%20with%20OpenID%20Connect%20and%20API%20keys.md)
9 |
10 | ## 1. Foundation of Security: Asymmetric Encryption
11 |
12 | The security of did:wba is primarily built on asymmetric encryption. This encryption method uses a key pair:
13 |
14 | - Private Key: Held only by the identity owner, used for signing
15 | - Public Key: Can be publicly shared, used for signature verification
16 |
17 | ```mermaid
18 | graph LR
19 | subgraph "Identity Owner"
20 | PrivateKey["Private Key"]
21 | PublicKey["Public Key"]
22 | end
23 |
24 | subgraph "Signing Process"
25 | Data["Original Data"]
26 | Sign["Digital Signature"]
27 | PrivateKey -->|Sign with Private Key| Sign
28 | Data -->|Calculate Hash| Sign
29 | end
30 |
31 | subgraph "Verification Process"
32 | VerifyData["Received Data"]
33 | VerifySign["Received Signature"]
34 | Result["Verification Result"]
35 | PublicKey -->|Verify with Public Key| Result
36 | VerifyData -->|Calculate Hash| Result
37 | VerifySign --> Result
38 | end
39 |
40 | style PrivateKey fill:#f9f,stroke:#333,stroke-width:2px
41 | style PublicKey fill:#9ff,stroke:#333,stroke-width:2px
42 | style Sign fill:#ff9,stroke:#333,stroke-width:2px
43 | style Result fill:#9f9,stroke:#333,stroke-width:2px
44 | ```
45 |
46 | This encryption mechanism ensures:
47 | 1. Only the private key holder can generate valid signatures. The private key must remain confidential.
48 | 2. Anyone can verify signature authenticity using the public key. A successful verification confirms the signature was generated by the private key holder.
49 | 3. The private key cannot be derived from the public key. The key pair is generated together, but the public key cannot reveal the private key.
50 |
51 | ## 2. DID Document Security Assurance
52 |
53 | From the above process, two key points ensure did:wba's security:
54 |
55 | 1. Private key confidentiality must be maintained.
56 | 2. Verifiers must obtain the correct public key.
57 |
58 | In did:wba, users maintain their private keys, while public keys are contained in the DID Document. The DID Document is stored on the user's DID server and can be accessed by anyone through a URL generated from the DID using the HTTPS protocol.
59 |
60 | Fundamentally, as long as users can obtain the correct DID Document, they can verify the other party's identity. In did:wba, we recommend users use DNS-over-HTTPS for domain resolution, access DID Documents via HTTPS, employ secure encryption algorithms, and implement strict certificate validation.
61 |
62 | ## 3. Identity Verification Process Security
63 |
64 | did:wba's identity verification process incorporates multiple security mechanisms:
65 |
66 | ### 3.1 Request Signing Mechanism
67 |
68 | Each authentication request contains:
69 | ```
70 | Authorization: DID Nonce Timestamp VerificationMethod Signature
71 | ```
72 |
73 | Components include:
74 | - Nonce: Random number preventing replay attacks
75 | - Timestamp: Ensures request timeliness
76 | - Signature: Signs critical information
77 |
78 | ### 3.2 Security Measures
79 |
80 | 1. **Replay Attack Prevention**:
81 | - Unique nonce generation for each request
82 | - Single-use nonce policy
83 | - Server-maintained blacklist of used nonces
84 |
85 | 2. **Timestamp Validation**:
86 | - Limited request validity window
87 | - Prevention of historical request replay
88 | - Server-side timestamp reasonability check
89 |
90 | 3. **Domain Validation**:
91 | - Server domain inclusion in signature data
92 | - Prevention of signature reuse across services
93 |
94 | 4. **Signature Verification**:
95 | - Signature integrity verification
96 | - Authorized key usage confirmation
97 |
98 | ## 4. Additional Security Considerations
99 |
100 | ### 4.1 Private Key Compromise
101 |
102 | In case of private key compromise, users should promptly generate a new key pair and update their DID Document. Since the DID Document is stored on the user's DID server, updates can be made immediately.
103 |
104 | ### 4.2 Regular Key Rotation
105 |
106 | Private keys should be rotated regularly to maintain security.
107 |
108 | ## Conclusion
109 |
110 | did:wba's security is founded on modern cryptography, utilizing asymmetric encryption, secure DID Document storage and verification processes, and regular private key rotation to ensure reliable and secure identity verification.
111 |
112 | Its fundamental principle remains rooted in the robust security of asymmetric encryption. At the infrastructure level, it relies on existing mature systems like DNS, Public Key Infrastructure, and HTTPS protocols rather than introducing new infrastructure.
113 | ## Copyright Notice
114 | Copyright (c) 2024 GaoWei Chang
115 | This file is released under the [MIT License](./LICENSE). You are free to use and modify it, but you must retain this copyright notice.
116 |
--------------------------------------------------------------------------------
/blogs/images/OAuth2.1.svg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/OAuth2.1.svg
--------------------------------------------------------------------------------
/blogs/images/a2a-id-auth.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/a2a-id-auth.png
--------------------------------------------------------------------------------
/blogs/images/a2a-partners.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/a2a-partners.png
--------------------------------------------------------------------------------
/blogs/images/agent-interview-Internet.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/agent-interview-Internet.png
--------------------------------------------------------------------------------
/blogs/images/agentic-web.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/agentic-web.png
--------------------------------------------------------------------------------
/blogs/images/ai-native-network.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/ai-native-network.png
--------------------------------------------------------------------------------
/blogs/images/all-protocol-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/all-protocol-1.png
--------------------------------------------------------------------------------
/blogs/images/all-protocol-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/all-protocol-2.png
--------------------------------------------------------------------------------
/blogs/images/anp-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-architecture.png
--------------------------------------------------------------------------------
/blogs/images/anp-authorization.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-authorization.png
--------------------------------------------------------------------------------
/blogs/images/anp-data-network.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-data-network.png
--------------------------------------------------------------------------------
/blogs/images/anp-did-auth.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-did-auth.png
--------------------------------------------------------------------------------
/blogs/images/anp-email.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-email.png
--------------------------------------------------------------------------------
/blogs/images/anp-explorer.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-explorer.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/00.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/00.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/01.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/02.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/02.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/03.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/03.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/04.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/04.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/05.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/05.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/06.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/06.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/07.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/07.png
--------------------------------------------------------------------------------
/blogs/images/anp-first-meet/08.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-first-meet/08.png
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page1.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page10.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page10.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page11.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page11.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page12.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page12.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page13.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page13.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page14.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page14.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page15.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page15.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page16.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page16.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page17.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page17.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page18.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page18.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page19.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page19.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page2.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page2.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page20.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page20.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page21.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page21.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page22.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page22.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page23.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page23.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page24.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page24.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page3.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page3.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page4.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page4.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page5.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page5.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page6.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page6.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page7.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page7.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page8.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page8.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-in-w3c-20250214/page9.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-in-w3c-20250214/page9.jpg
--------------------------------------------------------------------------------
/blogs/images/anp-interaction-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/anp-interaction-flow.png
--------------------------------------------------------------------------------
/blogs/images/api-keys-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/api-keys-flow.png
--------------------------------------------------------------------------------
/blogs/images/asymmetric-encryption.mmd:
--------------------------------------------------------------------------------
1 | graph LR
2 | subgraph "身份所有者"
3 | PrivateKey["私钥"]
4 | PublicKey["公钥"]
5 | end
6 |
7 | subgraph "签名过程"
8 | Data["原始数据"]
9 | Sign["数字签名"]
10 | PrivateKey -->|使用私钥签名| Sign
11 | Data -->|计算哈希| Sign
12 | end
13 |
14 | subgraph "验证过程"
15 | VerifyData["接收到的数据"]
16 | VerifySign["接收到的签名"]
17 | Result["验证结果"]
18 | PublicKey -->|使用公钥验证| Result
19 | VerifyData -->|计算哈希| Result
20 | VerifySign --> Result
21 | end
22 |
23 | style PrivateKey fill:#f9f,stroke:#333,stroke-width:2px
24 | style PublicKey fill:#9ff,stroke:#333,stroke-width:2px
25 | style Sign fill:#ff9,stroke:#333,stroke-width:2px
26 | style Result fill:#9f9,stroke:#333,stroke-width:2px
--------------------------------------------------------------------------------
/blogs/images/auth-flow.mmd:
--------------------------------------------------------------------------------
1 | sequenceDiagram
2 | participant C as 客户端
3 | participant S as 服务器
4 |
5 | Note over C,S: 初始认证请求
6 | C->>S: GET /protected-resource
7 | S-->>C: 401 Unauthorized
WWW-Authenticate: Bearer nonce="xyz987"
8 |
9 | Note over C: 生成签名:
1. 获取时间戳
2. 使用私钥签名
10 |
11 | C->>S: GET /protected-resource
Authorization: DID Nonce
Timestamp VerificationMethod
Signature
12 |
13 | Note over S: 验证过程:
1. 检查 nonce 是否使用过
2. 验证时间戳
3. 验证签名
14 |
15 | alt 验证成功
16 | S-->>C: 200 OK + Access Token
17 | Note over C,S: 后续请求使用 Token
18 | C->>S: GET /protected-resource
Authorization: Bearer
19 | S-->>C: 200 OK + Resource
20 | else 验证失败
21 | S-->>C: 401 Unauthorized
22 | end
23 |
24 | style C fill:#f9f,stroke:#333,stroke-width:2px
25 | style S fill:#9ff,stroke:#333,stroke-width:2px
--------------------------------------------------------------------------------
/blogs/images/computer-use-product.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/computer-use-product.png
--------------------------------------------------------------------------------
/blogs/images/data-silos.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/data-silos.png
--------------------------------------------------------------------------------
/blogs/images/did-wba-auth.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/did-wba-auth.png
--------------------------------------------------------------------------------
/blogs/images/did-wba-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/did-wba-flow.png
--------------------------------------------------------------------------------
/blogs/images/first-web-agent.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/first-web-agent.png
--------------------------------------------------------------------------------
/blogs/images/human-ai-agent.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/human-ai-agent.png
--------------------------------------------------------------------------------
/blogs/images/mcp-anp-share/protocol-explanation.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/blogs/images/mcp-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-architecture.png
--------------------------------------------------------------------------------
/blogs/images/mcp-authorization.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-authorization.png
--------------------------------------------------------------------------------
/blogs/images/mcp-http-sse.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-http-sse.png
--------------------------------------------------------------------------------
/blogs/images/mcp-init.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-init.png
--------------------------------------------------------------------------------
/blogs/images/mcp-server-api-key-example.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-server-api-key-example.png
--------------------------------------------------------------------------------
/blogs/images/mcp-tools.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-tools.png
--------------------------------------------------------------------------------
/blogs/images/mcp-usb.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-usb.png
--------------------------------------------------------------------------------
/blogs/images/mcp-vs-anp-core.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-vs-anp-core.png
--------------------------------------------------------------------------------
/blogs/images/mcp-vs-anp.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-vs-anp.png
--------------------------------------------------------------------------------
/blogs/images/mcp-wba-did-proposal.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/mcp-wba-did-proposal.png
--------------------------------------------------------------------------------
/blogs/images/meta-protocol-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/meta-protocol-flow.png
--------------------------------------------------------------------------------
/blogs/images/openid-connect-fllow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/openid-connect-fllow.png
--------------------------------------------------------------------------------
/blogs/images/user-agent-internet.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/blogs/images/user-agent-internet.png
--------------------------------------------------------------------------------
/chinese/08-ANP-智能体发现协议规范.md:
--------------------------------------------------------------------------------
1 | # ANP-智能体发现协议规范（Draft）
2 |
3 | ## 摘要
4 |
5 | 本规范定义了智能体发现协议（Agent Discovery Service Protocol, ADSP），这是一个用于发现智能体的标准化协议。该协议基于JSON-LD格式，提供了两种发现机制：主动发现和被动发现，旨在使智能体能够在网络中被其他智能体或搜索引擎有效地发现和访问。
6 |
7 | 协议的核心内容包括：
8 | 1. 使用JSON-LD作为基础数据格式，支持链接数据和语义网特性
9 | 2. 定义了主动发现机制，使用.well-known URI路径作为智能体发现入口点
10 | 3. 提供了被动发现机制，允许智能体将自身描述提交给搜索服务
11 | 4. 支持智能体描述的分页和链接，便于管理大量智能体信息
12 |
13 | 本规范旨在提高智能体在网络中的可发现性，为构建智能体网络生态系统提供基础支持。
14 |
15 | ## 引言
16 |
17 | 随着智能体数量的不断增加，如何有效地发现和访问这些智能体成为了一个关键问题。智能体发现协议（Agent Discovery Service Protocol, ADSP）旨在解决这一问题，通过标准化的方式使得智能体能够被其他智能体或搜索引擎发现。
18 |
19 | 本规范定义了两种智能体发现机制：主动发现和被动发现。主动发现允许搜索引擎或其他智能体通过已知的域名发现该域名下的所有公开智能体；被动发现则允许智能体主动将自身描述注册到搜索服务中。这两种机制相互补充，共同提高了智能体的可发现性。
20 |
21 | ## 概述
22 |
23 | 我们使用[JSON-LD](https://www.w3.org/TR/json-ld11/)(JavaScript Object Notation for Linked Data)作为智能体发现文档的格式，与智能体描述协议保持一致。通过使用JSON-LD，我们可以在保持简单易用的同时，实现丰富的语义表达和链接关系。
24 |
25 | 智能体描述文档是智能体的详细信息表达，参考文档 [ANP-智能体描述协议规范](07-ANP-智能体描述协议规范.md)。而智能体发现文档则作为一个集合页面，包含了域名下所有公开智能体描述文档的URL，便于搜索引擎或其他智能体进行索引和访问。
26 |
27 | ## 协议详情
28 |
29 | ### 主动发现
30 |
31 | 主动发现是指搜索引擎或智能体只需知道一个域名，即可发现该域名下所有公开的智能体描述文档。我们采用了Web标准的`.well-known` URI路径作为智能体发现的入口点。
32 |
33 | #### .well-known URI
34 |
35 | 根据[RFC 8615](https://tools.ietf.org/html/rfc8615)，`.well-known` URI提供了一种标准化的方式来发现服务和资源。对于智能体发现，我们定义了以下路径：
36 |
37 | ```
38 | https://{domain}/.well-known/agent-descriptions
39 | ```
40 |
41 | 此路径应返回一个JSON-LD文档，包含该域名下所有公开的智能体描述文档的URL。
42 |
43 | #### 发现文档格式
44 |
45 | 主动发现文档采用JSON-LD格式，使用`CollectionPage`类型，包含以下核心属性：
46 |
47 | - `@context`: 定义文档使用的JSON-LD上下文
48 | - `@type`: 文档类型，值为"CollectionPage"
49 | - `url`: 当前页面的URL
50 | - `items`: 智能体描述项目的数组
51 | - `next`: （可选）下一页的URL，用于分页场景
52 |
53 | 每个智能体描述项目包含：
54 | - `@type`: 类型，值为"ad:AgentDescription"
55 | - `name`: 智能体名称
56 | - `@id`: 智能体描述文档的URL（资源的唯一标识符）
57 |
58 | 示例：
59 |
60 | ```json
61 | {
62 | "@context": {
63 | "@vocab": "https://schema.org/",
64 | "did": "https://w3id.org/did#",
65 | "ad": "https://agent-network-protocol.com/ad#"
66 | },
67 | "@type": "CollectionPage",
68 | "url": "https://agent-network-protocol.com/.well-known/agent-descriptions",
69 | "items": [
70 | {
71 | "@type": "ad:AgentDescription",
72 | "name": "Smart Assistant",
73 | "@id": "https://agent-network-protocol.com/agents/smartassistant/ad.json"
74 | },
75 | {
76 | "@type": "ad:AgentDescription",
77 | "name": "Customer Support Agent",
78 | "@id": "https://agent-network-protocol.com/agents/customersupport/ad.json"
79 | }
80 | ],
81 | "next": "https://agent-network-protocol.com/.well-known/agent-descriptions?page=2"
82 | }
83 | ```
84 |
85 | #### 分页机制
86 |
87 | 当域名下有大量智能体时，应采用分页机制。分页通过`next`属性实现，指向下一页的URL。客户端应递归获取所有页面，直到没有`next`属性为止。
88 |
89 | ### 被动发现
90 |
91 | 被动发现是指智能体主动将自身的智能体描述URL提交给其他智能体（通常是搜索服务智能体），使其能够索引和爬取自身信息。
92 |
93 | #### 注册API
94 |
95 | 被动发现通常需要使用搜索服务智能体提供的注册API。这些API由搜索服务智能体自行定义，应在其智能体描述文档中明确说明。智能体可以通过调用这些API将自身描述URL注册到搜索服务中。
96 |
97 | #### 注册流程
98 |
99 | 1. 智能体获取搜索服务智能体的描述文档
100 | 2. 从描述文档中找到注册API的端点和参数要求
101 | 3. 构造注册请求，包含自身的智能体描述URL和其他必要信息
102 | 4. 发送注册请求到搜索服务
103 | 5. 搜索服务验证请求并索引该智能体
104 |
105 | ```mermaid
106 | sequenceDiagram
107 | participant Agent as 智能体
108 | participant Search as 搜索服务智能体
109 |
110 | Agent->>Search: 获取智能体描述文档
111 | Search-->>Agent: 返回描述文档（包含注册API信息）
112 | Note over Agent: 从描述文档中解析注册API
113 | Agent->>Search: 发送注册请求（包含自身描述URL）
114 | Note over Search: 验证请求
115 | Search-->>Agent: 确认注册
116 | Note over Search: 爬取智能体描述文档并索引
117 | ```
118 |
119 | ### 安全考虑
120 |
121 | 为确保智能体发现的安全性，建议采取以下措施：
122 |
123 | 1. **内容验证**: 搜索服务应验证智能体描述文档的有效性和完整性
124 | 2. **DID认证**: 使用did:wba方法进行身份认证，确保智能体身份的真实性
125 | 3. **限流机制**: 实施适当的限流措施，防止恶意请求和DoS攻击
126 | 4. **权限控制**: 区分公开和私有智能体，只在发现文档中包含公开智能体
127 |
128 | ## 与其他协议的关系
129 |
130 | 智能体发现协议与以下协议密切相关：
131 |
132 | 1. **智能体描述协议**: 发现协议提供了描述文档的索引和访问机制
133 | 2. **DID:WBA方法**: 提供了身份验证和安全保障
134 | 3. **元协议**: 在智能体通信中可基于发现结果进行协议协商
135 |
136 | ## 版权声明
137 | Copyright (c) 2024 GaoWei Chang
138 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
139 |
--------------------------------------------------------------------------------
/chinese/deprecated/00-AgentNetworkProtocol技术蓝图(20241204).md:
--------------------------------------------------------------------------------
1 | # Agent Network Protocol技术蓝图
2 |
3 | 此文档已过时，请参考[Agent Network Protocol技术白皮书](01-AgentNetworkProtocol技术白皮书.md)。
4 |
5 | ## 愿景
6 |
7 | 我们致力于将AgentNetworkProtocol(ANP)打造成**智能体网络时代的HTTP**。
8 |
9 | 在人工智能迅猛发展的新时代，我们正迈入智能体网络的崭新纪元。想象未来：你的个人助理智能体在为你订餐时，与餐厅的智能体无缝沟通；你的智能家居智能体与能源管理智能体协同优化用电；你的投资顾问智能体与全球市场分析智能体实时交换信息......这就是即将到来的智能体网络时代。
10 |
11 | 然而，正如比尔盖茨在[一篇博客](https://www.gatesnotes.com/AI-agents)中所说，目前还没有一个标准协议允许智能体之间相互通信。这就是Agent Network Protocol (ANP)致力于去解决的问题。
12 |
13 | Agent Network Protocol(ANP)的愿景是**定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络**。就像互联网标准协议的发展成就了近三十年的信息时代，我们相信，在不远的将来，数十亿智能体将通过ANP构建起前所未有的协作网络，创造出比现有互联网更大的价值。在AI技术和ANP加持下，智能体网络最终会演化成一个**自组织、自协商**的高效协作网络，这是一个令人无比兴奋的未来。
14 |
15 | ## 挑战
16 |
17 | Agent Network Protocol(ANP)致力于解决智能体连接中的三大挑战：
18 |
19 | - 智能体之间如何进行身份认证，以让任意两个智能体都可以进行连接
20 | - 智能体之间如何进行端到端加密通信，以确保通信安全
21 | - 智能体如何进行高效的数据交换，以提升智能体协作的效率
22 |
23 | ## 协议架构
24 |
25 | 为了应对上面的三大挑战，Agent Network Protocol(ANP)整体上设计为三层架构，从下到上依次是身份与加密通信层、元协议层、应用协议层，如下图所示：
26 |
27 |
28 |
29 |
30 |
31 | ### 身份与加密通信层
32 |
33 | 这是整个协议最基础的部分，主要解决智能体通信的两大挑战：智能体之间如何进行身份认证，以及如何进行端到端加密通信。
34 |
35 | 基于W3C DID（Decentralized Identifiers，去中心化标识符）规范，融合区块链技术与端到端加密技术，Agent Network Protocol(ANP)提供了一个突破性的解决方案：
36 |
37 | - **完全去中心化**：智能体可完全掌控自己的身份标识，而不用受限于任何平台
38 | - **无障碍连接**：支持任意平台间的智能体身份认证，打破平台之间的鸿沟
39 | - **极致安全**：端到端加密确保通信安全，中间节点无法破解内容
40 | - **低成本高效**：基于现有Web基础设施，快速部署，成本极低
41 |
42 | W3C DID 是Agent Network Protocol(ANP)的身份和加密通信层的核心基石，它的去中心化、互操作性等特性成就了ANP协议的开发性，让任意两个智能体都能够通过它建立连接，让我们能够构建一个开放的智能体协作网络。
43 |
44 | 详细技术文档：[GitHub](https://github.com/agent-network-protocol/AgentNetworkProtocol)
45 |
46 | ### 元协议层
47 |
48 | 在元协议加持下，智能体网络有可能会演进成一个**自组织、自协商**的高效协作网络，这是一个令人兴奋的未来。
49 |
50 | 所谓的元协议，即协商通信使用协议的协议。在元协议层，我们主要参考和借鉴的是[Agora Protocol](https://arxiv.org/html/2410.11905v1)。
51 |
52 | 当前的数字世界，存在着巨大的数据孤岛现象，数据的流动集中在孤岛内部，而孤岛和孤岛之间则只有少量数据流动。这一结果的出现，除了商业上的原因，技术限制也是一个很大的原因：异构网络（不同架构、功能、设计）通过协议互通往往要付出巨大的成本，这里面的根本原因在于Agora Protocol论文中提出的异构网络通信的不可能三角（Versatility（多功能性）、Efficiency（效率）、Portability（可移植性））。
53 |
54 | LLM加持的智能体结合元协议是解决这一问题的良方：
55 |
56 | - 智能体之间首先使用自然语言，互相沟通各自的能力、数据交换格式、使用的协议等，确定智能体之间通信的协议细节。
57 | - 根据协商结果，智能体使用LLM构造和处理协议消息，或者使用智能体生成处理协议的代码，来构造和处理协议消息。
58 | - 智能体之间进行协议联调，使用LLM判断协议消息是否符合协商规范，如果不符合，则通过自然语言交互进行解决。
59 | - 最后，智能体使用最终的协议进行通信。
60 |
61 | 我们相信，在LLM的自然语言理解能力和代码生成能力，以及元协议技术的推动下，智能体网络最终会演进成一个自组织、自协商的高效协作网络，并且会诞生非常多智能体之间达成共识的通信协议，这些协议的数量将会大大超过人类制定协议的数量。
62 |
63 | ### 应用协议层
64 |
65 | 应用层协议分为两类，一类是行业当前已经存在的规范，比如email协议、RTC相关规范、W3C现有规范等，一类是智能体网络自动协商出来共识协议。他们的目标都是为了智能体能够一起协作完成某个业务。
66 |
67 | 在协议传递数据的类型上，大概可以分为三类：文本、文件、多媒体实时数据流。这三种类型基本可以覆盖当前所有的业务类型。
68 |
69 | 智能体之间在基础协议之上，根据自己的数据或业务特点，自有的对协议进行扩展。标准规范在智能体网络中的作用，主要是降低协商的复杂度，而非强制规范，我们相信智能体两两之间能够协商出最适合他们业务场景的个性化协议。
70 |
71 | ## AgentConnect：Agent Network Protocol(ANP)的开源实现
72 |
73 | 我们开源了一个项目，AgentConnect（https://github.com/agent-network-protocol/AgentConnect），用来实现Agent Network Protocol(ANP)的功能，项目架构如下图：
74 |
75 |
76 | 
77 |
78 |
79 | 对应Agent Network Protocol的三层架构，AgentConnect主要包括以下几个部分：
80 |
81 | 1. **身份认证模块与端到端加密模块**
82 | 主要实现基于W3C DID的身份认证和端到端加密通信，包括DID文档的生成、校验、获取，以及基于DID和ECDHE(Elliptic Curve Diffie-Hellman Ephemeral，椭圆曲线迪菲-赫尔曼临时密钥交换)端到端加密通信方案实现。
83 |
84 | 2. **元协议模块**
85 | 元协议模块需要基于LLM（大语言模型）和元协议实现，主要功能包含基于元协议的应用协议协商、协议代码实现、协议联调、协议处理等。
86 |
87 | 3. **应用层协议集成框架**
88 | 主要的目的是管理和其他智能体通信的协议规范文档以及协议代码，包括应用协议加载、应用协议卸载、应用协议配置、应用协议处理。使用这个框架，智能体可以方便的、按需加载运行所需要的现成协议，加快智能体协议协商过程。
89 |
90 | 除了以上的功能之外，AgentConnect未来也会在性能、多平台支持等特性上发力：
91 |
92 | - **性能**：作为一个基础的代码库，我们希望能够提供极致的性能，未来会用Rust来重写核心部分代码。
93 | - **多平台**：现在支持mac、Linux、windows，未来将会支持移动端、浏览器。
94 |
95 | ## 里程碑
96 |
97 | 无论是协议还是开源代码实现，我们整体式是按照以下的顺序逐步的推进：
98 |
99 | - 构建身份认证与端到端加密通信协议与实现。这是我们整个项目的基础与核心，当前协议设计和代码基本完成。
100 | - 元协议设计与元协议代码实现。这将有助于智能体网络演进为一个自组织、自协商的高效协作网络，是我们当下正在做的事情，这将是一个令人兴奋的功能，预计不久之后我们就会发布第一个版本。
101 | - 应用层协议集成框架开发。这将有助于Agent Network Protocol(ANP)在各种场景中为智能体提供服务。
102 |
103 | 除此之外，我们还会遵循先整体，后细节的原则。早期我们会致力于整体架构的搭建，为每一个主要的模块构建一个整体的轮廓，让它快速的运行起来，而不是构建一个个精美但无法运行的模块。
104 |
105 | 为了推动Agent Network Protocol(ANP)成为行业的标准，我们将会在合适的时间组建ANP标准化委员会，致力于推动ANP成为W3C等国际标准化组织认可的行业标准。
106 |
107 | 最后，在设计方案的过程中，我们逐渐的感受到，也许区块链是更适合智能体的网络基础设施，未来我们可能会在这个方向做一些积极的尝试和探索。
108 |
109 | ## 为什么选择Agent Network Protocol(ANP)？
110 |
111 | - **开放互联**：基于 W3C DID 的去中心化身份认证，让智能体突破平台限制，实现自由安全的连接。
112 | - **技术创新**：通过融合区块链与 DID 技术，首创性地解决了跨平台智能体认证的难题。
113 | - **高效落地**：立足现有 Web 基础设施，实现低成本、快速部署，助力生态快速发展。
114 | - **面向未来**：为智能体网络时代打造基础设施，驱动自组织协作网络的演进与创新。
115 | - **专业团队**：由资深工程师和研究人员组成的核心团队，拥有丰富的分布式系统、协议设计和人工智能领域经验。
116 |
117 | ## 如何为Agent Network Protocol(ANP)贡献力量
118 |
119 | 无论你是开发者、研究人员、企业，还是对Agent Network Protocol(ANP)感兴趣的朋友，我们都欢迎你加入我们，一起为Agent Network Protocol(ANP)的发展贡献力量。
120 |
121 | 我们的联系方式：
122 |
123 | - 作者：常高伟，chgaowei@gmail.com
124 | - Discord: [https://discord.gg/sFjBKTY7sB](https://discord.gg/sFjBKTY7sB)
125 | - 官网：[https://agent-network-protocol.com/](https://agent-network-protocol.com/)
126 | - GitHub：[https://github.com/agent-network-protocol/AgentNetworkProtocol](https://github.com/agent-network-protocol/AgentNetworkProtocol)
127 | ## 版权声明
128 | Copyright (c) 2024 GaoWei Chang
129 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
130 |
--------------------------------------------------------------------------------
/chinese/docs/did-wba服务端测试接口.md:
--------------------------------------------------------------------------------
1 | # did:wba服务端测试接口
2 |
3 | 未来方便进行did:wba的测试，我们开发了一个用于测试的服务端，设计了多个http接口，用于上传、获取，以及DID功能测试。
4 |
5 | 服务端的测试域名是：`agent-network-protocol.com`，`pi-unlimited.com`，两个都可以使用，下面统一以`agent-network-protocol.com`为例。
6 |
7 | 你可以自己在本地生成DID文档，然后上传到我们的服务器，这样就可以生成一个可以使用的DID。
8 |
9 | 比如，你上传的路径是`https://agent-network-protocol.com/wba/user/2i3dg4dtf908cde0/did.json`，那么你生成的DID就是`did:wba:agent-network-protocol.com:wba:user:2i3dg4dtf908cde0`。
10 |
11 | ## 1. 上传 JSON 文件（PUT 请求）
12 |
13 | ### 请求路径
14 | `https://agent-network-protocol.com/wba/user/2i3dg4dtf908cde0/did.json`
15 |
16 | 注意：
17 | - "2i3dg4dtf908cde0" 是一个唯一标识，未来防止冲突，建议使用16为随机字符串。
18 | - 如果id在服务端已经存在，会返回409 Conflict。
19 | - 此接口暂时只用于测试用途，每个IP限定最多put50个文件。
20 |
21 | ### 请求格式示例
22 | ```plaintext
23 | PUT /wba/user/2i3dg4dtf908cde0/did.json HTTP/1.1
24 | Host: agent-network-protocol.com
25 | Content-Type: application/json
26 | Content-Length: <文件长度>
27 |
28 |
29 | ```
30 |
31 | ## 2. 获取 JSON 文件（GET 请求）
32 |
33 | ### 请求路径
34 | `https://agent-network-protocol.com/wba/user/2i3dg4dtf908cde0/did.json`
35 |
36 | ### 请求格式示例
37 | ```plaintext
38 | GET /wba/user/2i3dg4dtf908cde0/did.json HTTP/1.1
39 | Host: agent-network-protocol.com
40 | ```
41 |
42 | ### 响应格式示例
43 | ```plaintext
44 | HTTP/1.1 200 OK
45 | Content-Type: application/json
46 | Content-Length: <文件长度>
47 |
48 |
49 | ```
50 |
51 | ### 错误响应
52 | - 404 Not Found: 指定的资源不存在。
53 |
54 | ## 3. 测试did:wba身份验证正常功能
55 |
56 | 提供了一个服务端测试接口，用于测试用户的did:wba身份验证是否正常。
57 |
58 | ### 请求路径
59 | `https://agent-network-protocol.com/wba/test`
60 |
61 | ### 请求格式示例
62 | ```plaintext
63 | GET /wba/test HTTP/1.1
64 | Host: agent-network-protocol.com
65 | Authorization: DID did:wba:example.com%3A8800:user:alice Nonce Timestamp <2024-12-05T12:34:56Z> VerificationMethod Signature
66 | ```
67 |
68 | http请求头中的Authorization字段，按照did:wba方法规范进行签名。
69 | 如果是验证token流程，Authorization填写服务端首次请求返回的token。示例：
70 |
71 | ```plaintext
72 | Authorization: Bearer
73 | ```
74 |
75 | ### 响应格式示例
76 | ```plaintext
77 | HTTP/1.1 200 OK
78 | Authorization: Bearer
79 | Content-Type: application/text
80 | Content-Length: <文件长度>
81 |
82 | OK
83 | ```
84 |
85 | 首次请求中，携带的Authorization字段，包含用于后续http请求的token。
86 |
87 | ### 错误响应
88 | - 403 Forbidden: 鉴权失败
89 |
90 |
91 |
92 | ## 4. 测试did:wba身份验证401功能
93 |
94 | 提供了一个服务端测试接口，用于测试用户的did:wba身份验证在服务端返回401的时候，客户端是否能够正常处理。
95 |
96 | ### 请求路径
97 | `https://agent-network-protocol.com/wba/test401`
98 |
99 | ### 请求格式示例
100 | ```plaintext
101 | GET /wba/test401 HTTP/1.1
102 | Host: agent-network-protocol.com
103 | Authorization: DID did:wba:example.com%3A8800:user:alice Nonce Timestamp <2024-12-05T12:34:56Z> VerificationMethod Signature
104 | ```
105 |
106 | http请求头中的Authorization字段，按照did:wba方法规范进行签名。
107 | 如果是验证token流程，Authorization填写服务端首次请求返回的token。示例：
108 |
109 | ```plaintext
110 | Authorization: Bearer
111 | ```
112 |
113 | ### 响应格式示例
114 | ```plaintext
115 | HTTP/1.1 401 Unauthorized
116 | WWW-Authenticate: Bearer error="invalid_nonce", error_description="Nonce has already been used. Please provide a new nonce.", nonce="xyz987"
117 | Content-Type: application/json
118 | Content-Length: 0
119 | ```
120 |
121 | WWW-Authenticate字段，包含用于后续http请求签名的nonce。
122 |
123 | ## 5. 生成 DID 文档和私钥接口
124 |
125 | ### 请求路径
126 | `https://agent-network-protocol.com/wba/demo/generate`
127 |
128 | ### 请求格式示例
129 | ```plaintext
130 | GET /wba/demo/generate HTTP/1.1
131 | Host: agent-network-protocol.com
132 | ```
133 |
134 | ### 响应格式示例
135 | ```plaintext
136 | HTTP/1.1 200 OK
137 | Content-Type: application/json
138 | Content-Length: <文件长度>
139 |
140 | {
141 | "did_document": "",
142 | "private_key": "<私钥pem格式>"
143 | }
144 | ```
145 |
146 | ### 注意事项
147 | - 在处理DID文档和私钥时，可能会包含特殊字符。为了确保数据能够正确通过JSON发送，建议对特殊字符进行转义。
148 | - JSON中的特殊字符，如双引号（`"`）和反斜杠（`\`），需要使用反斜杠进行转义。
149 | - 如果DID文档或私钥中包含换行符（`\n`），也需要进行转义。
150 | - 对于包含非文本字符的数据，建议使用Base64编码以确保数据的完整性。
151 |
152 | ## 6. 身份验证接口
153 |
154 | ### 请求路径
155 | `https://agent-network-protocol.com/wba/demo/auth`
156 |
157 | ### 请求格式示例
158 | ```plaintext
159 | POST /wba/demo/auth HTTP/1.1
160 | Host: agent-network-protocol.com
161 | Content-Type: application/json
162 | Content-Length: <文件长度>
163 |
164 | {
165 | "did_document": "",
166 | "private_key": "<私钥pem格式>",
167 | "auth_url": "<身份验证url>"
168 | }
169 | ```
170 |
171 | ### 响应格式示例
172 | ```plaintext
173 | HTTP/1.1 200 OK
174 | Content-Type: application/json
175 | Content-Length: <文件长度>
176 |
177 | {
178 | "authorization": "DID did:wba:example.com%3A8800:user:alice Nonce Timestamp <2024-12-05T12:34:56Z> VerificationMethod Signature ",
179 | "auth_code": 200,
180 | "error_message": null,
181 | "access_token": ""
182 | }
183 | ```
184 |
185 | ## 7. 身份验证401接口
186 |
187 | ### 请求路径
188 | `https://agent-network-protocol.com/wba/demo/auth401`
189 |
190 | ### 请求格式示例
191 | ```plaintext
192 | POST /wba/demo/auth401 HTTP/1.1
193 | Host: agent-network-protocol.com
194 | Content-Type: application/json
195 | Content-Length: <文件长度>
196 |
197 | {
198 | "did_document": "",
199 | "private_key": "<私钥pem格式>",
200 | "auth_url": "<身份验证url>"
201 | }
202 | ```
203 |
204 | ### 响应格式示例
205 | ```plaintext
206 | HTTP/1.1 401 Unauthorized
207 | Content-Type: application/json
208 | Content-Length: <文件长度>
209 |
210 | {
211 | "authorization": "DID did:wba:example.com%3A8800:user:alice Nonce Timestamp <2024-12-05T12:34:56Z> VerificationMethod Signature ",
212 | "auth_code": 401,
213 | "error_message": "Invalid credentials provided.",
214 | "access_token": ""
215 | }
216 | ```
217 |
218 |
219 |
220 |
221 |
222 |
223 | ## 版权声明
224 | Copyright (c) 2024 GaoWei Chang
225 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
226 |
--------------------------------------------------------------------------------
/chinese/参考资料/paper&规范.md:
--------------------------------------------------------------------------------
1 |
2 | 下面所有的DID相关的规范，大部分都是草案。
3 |
4 |
5 | did web方法
6 | https://w3c-ccg.github.io/did-method-web/
7 |
8 |
9 | W3C DID(Decentralized Identifier)规范
10 | https://www.w3.org/TR/did-core/
11 |
12 |
13 | DID解析服务端点构造
14 | https://www.w3.org/TR/did-resolution/#service-endpoint-construction
15 |
16 | webagents工作组
17 | https://www.w3.org/community/webagents/
18 |
19 | 规范：
20 | https://www.w3.org/TR/did-core/
21 |
22 | 用例（有助于理解DID过程，有很多过程描述，比did-core更详细）：
23 | https://www.w3.org/TR/did-use-cases/
24 |
25 |
26 | 用于记录扩展的github仓库：
27 | https://github.com/w3c/did-extensions
28 |
29 | 扩展：
30 | https://github.com/w3c/did-extensions
31 |
32 |
33 | 这个文档有关于每个字段的说明，对每个字段可以找到规范说明：
34 | https://www.w3.org/ns/did/v1
35 |
36 |
37 | controller文档，这里很多关于身份验证、使用服务的方法：
38 | https://www.w3.org/TR/controller-document/
39 |
40 |
41 | 所有DID的扩展，包括方法，字段：
42 | https://www.w3.org/TR/did-extensions/
43 |
44 | 字段扩展，有所有的字段的定义：
45 | https://www.w3.org/TR/did-extensions-properties/
46 |
47 | 方法扩展，有所有的方法的定义：
48 | https://www.w3.org/TR/did-extensions-methods/
49 |
50 | 所有解决方案的扩展，包括URL解析：
51 | https://www.w3.org/TR/did-extensions-resolution
52 |
53 | 可验证凭证规范：
54 | https://www.w3.org/TR/vc-data-model/#proofs-signatures
55 |
56 | ontrolled Identifier Document 1.0
57 | https://www.w3.org/TR/controller-document/#sotd
58 |
59 |
60 | 这里定义了proof的字段
61 | https://www.w3.org/TR/vc-data-integrity/#defn-domain
62 |
63 | ## 版权声明
64 | Copyright (c) 2024 GaoWei Chang
65 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
66 |
--------------------------------------------------------------------------------
/chinese/参考资料/语义网/Linked-Data.md:
--------------------------------------------------------------------------------
1 |
2 | # Tim Berners-Lee
3 |
4 | **Date**: 2006-07-27
5 | **Last Change**: $Date: 2009/06/18 18:24:33 $
6 | **Status**: 仅代表个人观点
7 | **Editing Status**: 尚未完善，但已发布
8 |
9 | [返回设计问题](#)
10 |
11 | ## 链接数据 (Linked Data)
12 |
13 | 语义网不仅仅是将数据放在网上，而是关于如何创建链接，使得人或机器能够探索数据的网络。通过链接数据，当你拥有部分数据时，可以找到其他相关数据。
14 |
15 | 与超文本网络相似，数据网络是通过网络上的文档构建的。然而，不同于超文本网络中的链接是HTML文档中的锚点，数据网络中的链接是由RDF描述的任意事物之间的关系。URI可以标识任何类型的对象或概念。而无论是HTML还是RDF，都有共同的期望来促进网络的增长：
16 | 1. 使用URI作为事物的名称。
17 | 2. 使用HTTP URI，使得人们可以查找这些名称。
18 | 3. 当有人查找URI时，提供有用的信息，使用标准（如RDF、SPARQL）。
19 | 4. 包含指向其他URI的链接，以便发现更多事物。
20 |
21 | 这些规则简单明了。然而，尽管如此，在2006年，仍有大量数据未被链接，原因在于某些步骤的问题。本文讨论了这些问题的解决方案、实施细节以及影响数据发布选择的因素。
22 |
23 | ---
24 |
25 | ## 四项规则
26 |
27 | 上述步骤可以称为规则，但实际上它们是行为的期望。违反这些规则并不会破坏任何东西，但会错失将数据互联的机会。这反过来限制了数据在未来意外重用中的可能性。而这种意外重用正是网络的增值所在。
28 |
29 | ### 规则一：使用URI标识事物
30 |
31 | 这一点对于从事语义网技术的大多数人来说已经很清楚。如果不使用通用的URI符号集，就不能称之为语义网。
32 |
33 | ### 规则二：使用HTTP URI
34 |
35 | 这一规则也广为人知。然而，自网络诞生以来，人们经常倾向于发明新的URI方案（如LSIDs、DOIs、XRIs等）。通常，这种行为源于不想使用域名系统（DNS）来分配权限，或者对HTTP URI作为名称（而非地址）的理解不足。
36 |
37 | ### 规则三：提供信息服务
38 |
39 | 对于大多数本体来说，这一规则在2006年已被较好地遵循。然而，一些重要的数据集仍未遵守。通常可以查找数据中的属性和类别，并从RDF、RDFS和OWL本体中获取信息。然而，许多数据集仍然埋藏在压缩包中，而不是作为链接数据在线提供。
40 |
41 | ### 规则四：创建链接
42 |
43 | 为了将数据连接成一个真正无限的网络，必须创建链接。在超文本网络中，不链接到相关外部材料通常被视为不好的礼仪。同样，在语义网中，你的数据价值也取决于它链接到的内容以及其本身的价值。
44 |
45 | ---
46 |
47 | ## 基本链接数据的创建
48 |
49 | 最简单的链接数据方法是使用一个文件中的URI指向另一个。例如：
50 | 在RDF文件中可以使用本地标识符，如`#albert`，在N3格式中表示为：
51 | ```n3
52 | <#albert> fam:child <#brian>, <#carol>.
53 | ```
54 |
55 | 这使得全球范围内都可以使用类似`http://example.org/smith#albert`的全局标识符来引用Albert，从而增加了语义网的价值。
56 |
57 | ---
58 |
59 | ## URI的变体：无斜杠与HTTP 303
60 |
61 | 在某些情况下，将标识符划分到文档中可能效果不佳。例如，某些情况下会用到`http://wordnet.example.net/antidisestablishmentarianism#word`这种URI格式。对于这种情况，可以使用HTTP 303跳转，使得概念的URI指向其描述文档的URI。
62 |
63 | ---
64 |
65 | ## FOAF与rdfs:seeAlso
66 |
67 | 在FOAF文件中，通过给出两个属性，可以链接到另一个人：
68 | ```n3
69 | <#i> foaf:knows [
70 | foaf:mbox ;
71 | rdfs:seeAlso
72 | ].
73 | ```
74 |
75 | 这种方式形成了一个不断增长的社交网络，但它的缺点是无法为人分配唯一的URI。因此，建议创建FOAF文件时，为自己分配一个URI，同时在引用他人时使用他们的URI。
76 |
77 | ---
78 |
79 | ## 可浏览的图形数据
80 |
81 | 数据的可浏览性是创建链接时的重要模式。这使得人们可以逐步探索并理解数据的结构。
82 |
83 | ### 可浏览图
84 |
85 | 现在我们已经讨论了如何创建链接的方法，接下来我们看一下在何时创建链接的选择。
86 |
87 | 一种重要的模式是一个可以通过链接逐步探索的数据集。这种模式类似于网页浏览器中使用的浏览超链接的方法。在语义网中，数据的结构和关联使得可以通过URI逐步获取和理解相关信息。这种方式被称为“可浏览图”（Browsable Graph）。
88 |
89 | #### 数据浏览模式
90 |
91 | 在可浏览图中，数据被组织为节点（Node）和边（Edge）。节点代表对象或概念，边表示节点之间的关系。用户或机器可以通过遍历这些关系，从一个节点跳转到另一个节点，从而发现更多的信息。
92 |
93 | 例如：
94 |
95 | 1. 从一个人的FOAF文件开始，您可以找到他们的朋友。
96 | 2. 然后，通过朋友的URI，您可以找到该朋友的其他属性或关系，例如他们参与的项目。
97 |
98 | 这种数据浏览模式不仅有助于信息的发现，还能通过多方的数据交互创建更丰富的语义网络。
99 |
100 | #### 语义网的未来
101 |
102 | 创建一个连接良好的数据网络需要全球范围的合作和一致性。这包括：
103 |
104 | 1. 提供高质量的URI。
105 | 2. 遵循HTTP URI标准。
106 | 3. 使用开放的、通用的格式，如RDF和SPARQL。
107 | 4. 提倡数据互联，而不是单独孤立的数据集。
108 |
109 | Tim Berners-Lee在文章中强调，语义网的潜力在于“意想不到的重用”（Unexpected Reuse）。通过将数据以链接的方式组织起来，语义网不仅扩展了信息的发现和使用范围，也为未来创造了无数的可能性。
110 |
111 | ---
112 |
113 | **注释：**本文基于Tim Berners-Lee的观点翻译，部分内容可能因语义调整而有所不同，旨在方便理解语义网和链接数据的核心思想。
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 | ## 版权声明
122 | Copyright (c) 2024 GaoWei Chang
123 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
124 |
--------------------------------------------------------------------------------
/chinese/参考资料/语义网/The-Next-Web-TimBerners-Lee.md:
--------------------------------------------------------------------------------
1 | ### 网络的起源：挫折
2 |
3 | 时光飞逝，实际上差不多是二十年前，我想重新定义我们使用信息的方式，我们合作的方式，我称之为万维网。现在，二十年过去了，TED，我想请求你们的帮助，进行一次新的重塑。
4 |
5 | 回到1989年，我写了一份备忘录，建议建立一个全球超文本系统。没有人真正对此采取行动。但十八个月后——你知道，这就是创新的发生方式，十八个月后，我的老板说我可以在业余时间做这个项目，作为一种娱乐项目，在我们拥有的计算机上进行。因此，他给了我时间来编写代码。
6 |
7 | 所以，我基本上勾勒出了HTML的样子，超文本协议HTTP，URL的概念，这些名称用于排序HTTP。我写了代码，并发布了它。为什么我要这样做？嗯，基本上是因为挫折。我在一个非常令人兴奋的大实验室里担任软件工程师，来自世界各地的人们带来了各种不同的社区，他们带来了各种不同的数据格式，各种类型的文档系统。
8 |
9 | 因此，在所有这些多样性中，如果我想弄清楚如何从中构建一些东西，我必须连接到某台新机器，我必须学习运行某个新程序。我会发现数据可能是我想要的信息，以某种新的数据格式存在，而它们都是不兼容的。这种挫折感源于所有这些未被开发的潜力。事实上，在所有这些磁盘上，都有文档。所以，如果你能想象它们都是天空中某个大型虚拟文档系统的一部分，那么——比如在互联网上，那生活会变得容易得多。
10 |
11 | 好吧，一旦你有了这样的想法，它就会深入你的内心，即使人们不读你的备忘录（实际上他读了，后来他去世后发现了他的副本，他在角落用铅笔写下了“模糊但令人兴奋”）。
12 |
13 | ### 草根运动
14 |
15 | 但总的来说，很难解释——真的很难解释网络是什么样的，你不知道——很难向人们解释那时的困难。但那时，TED刚开始时，没有网络。所以我们——类似点击的东西有相同的意义。我可以向某人展示一段超文本，一个有链接的页面，我们点击一个链接，*叮*，会有另一个超文本页面。
16 |
17 | 不令人印象深刻，你知道，我们已经见过了，我们在CD-ROM上有超文本的东西。困难的是让他们想象。所以想象一下那个链接可以指向你能想象的几乎任何文档。好吧？这是人们很难做到的飞跃。好吧，有些人做到了。所以是的，很难解释，但这是一场草根运动。这是让它变得最有趣的原因。那是最令人兴奋的事情，不是技术，不是人们用它做的事情，而是实际上是社区，是所有这些人聚在一起，发送电子邮件的精神。那就是当时的样子。
18 |
19 | 你知道吗，现在又有点像那样了。我大致上请求每个人把他们的文档放到这个网络上。你们做到了，谢谢。这真是太棒了，不是吗。我是说，这非常有趣，因为我们发现网络上发生的事情真的让我们大吃一惊。它们远远超出了我们最初想象的，当我们把初始网站放在一起时。
20 |
21 | ### 数据的重要性
22 |
23 | 现在，我希望你把你的数据放到网上。事实证明，还有巨大的未开发潜力。人们仍然感到巨大的挫折，因为我们没有把数据作为数据放到网上。你是什么意思，“数据”，文件和数据有什么区别？好吧，文件是你阅读的，对吧？差不多，你可以阅读它们，你可以从中放一个链接，仅此而已。数据，你可以用计算机做各种事情。
24 |
25 | 谁在这里，或者，不知道，是否看过汉斯·罗斯林的演讲。当汉斯·罗斯林在TED时，是的，很多人看过，因为这是TED最伟大的演讲之一。汉斯做了一个演示，他展示了不同国家以不同颜色展示的收入水平和婴儿死亡率，并展示了这个东西随时间的动画。所以他收集了这些数据，做了一个演示，打破了人们对发展中国家经济的许多误解。他展示了一张类似这样的幻灯片。它地下有所有的数据。
26 |
27 | 好吧，数据是棕色的，方形的，无聊的，等等（？），这就是我们对它的看法，不是吗，数据？因为数据你不能自然地单独使用。但实际上，数据驱动着我们生活中发生的大量事情。它发生是因为有人拿走了这些数据，并用它做了些什么。在这种情况下，汉斯，他可以把数据放在一起，他从各种联合国网站和东西中找到的。他把它放在一起，结合成比原件更有趣的东西。然后他把它放入这个软件中，我想是Sun最初开发的，并制作了这个精彩的演示。
28 |
29 | 汉斯强调说，拥有大量数据真的很重要，我很高兴看到，昨晚的聚会上，他仍然非常强烈地说，拥有大量数据真的很重要。
30 |
31 | ### 关联数据的原则
32 |
33 | 所以我现在想让我们思考，不仅仅是两块数据被连接，或者像他那样的六块，而是我想象一个世界，所有人都把数据放到了网上，因此你能想象的几乎任何东西都在网上，我称之为关联数据。技术是关联数据，而且非常简单。
34 |
35 | 如果你想把东西放到网上，有三个规则。第一件事是，那些HTTP名称，那些以“http:”开头的东西，我们不仅仅用它们来表示文档，现在我们用它们来表示文档所涉及的东西。我们用它们来表示人，用它们来表示地点。我们用它们来表示你的产品。我们用它们来表示事件。所有类型的概念性事物它们现在都有名称，以“http”开头。
36 |
37 | 第二个规则是，当——如果我拿一个这些“http”名称，我去做网络上的事情，我用HTTP协议从网上获取数据，我会得到一些以标准格式返回的数据，这些数据可能是关于那个事物的重要信息，关于那个事件，谁在事件上，无论是关于那个人，他们在哪里出生，诸如此类的事情。所以，第二个规则是：我得到重要的信息。
38 |
39 | 第三个规则是，当我得到这些信息时，它不仅仅是某人的身高和体重以及他们的出生日期，它有关系。数据就是关系。有趣的是，数据就是关系。它有这个人在柏林出生，柏林在德国，当它有关系时，无论它表达这种关系的是什么，那么它所关联的另一个事物都有一个以“http”开头的名称。所以我可以继续查找那个东西。
40 |
41 | 所以我查找一个人，我可以查找他们出生的城市，然后我可以查找它所在的地区，以及它所在的城镇和它的人口，等等，所以我可以浏览这些东西。就是这样。那就是关联数据。我几年前写了一篇题为“关联数据”的文章，不久之后，事情开始发生。关联数据的想法是，我们得到很多很多很多这些盒子，汉斯拥有的盒子，我们得到很多很多很多的东西在生长。它不仅仅是一个植物供应的根。
42 |
43 | 但对于每一个植物，无论它是什么，一个演示，一个分析，某人在数据中寻找模式，他们可以查看所有的数据，并将它们连接在一起，关于数据的真正重要的事情是，你连接在一起的东西越多，它就越强大。
44 |
45 | ### 它正在发挥作用：DBpedia
46 |
47 | 因此，关联数据，理念传播开来。很快，柏林自由大学的克里斯·比泽尔是第一个将有趣的东西放上去的人之一。他注意到维基百科，你知道维基百科，在线百科全书，里面有很多很多有趣的文档，嗯，在那些文档中，有小方块，小盒子，那些信息盒子里有数据。
48 |
49 | 所以他写了一个程序，从维基百科中提取数据，并将其放入网络上的一个关联数据块中；他称之为dbpedia。Dbpedia在这张幻灯片的中间用蓝色块表示。如果你实际去查看柏林，你会发现还有其他数据块也有关于柏林的东西，它们是相互关联的。因此，如果你从dbpedia中提取关于柏林的数据，你最终会提取出这些其他东西。令人兴奋的是：它开始增长。这又是一场草根运动，好吗？
50 |
51 | 现在让我们考虑数据（？？）。数据实际上有很多很多不同的形式。想想网络的多样性。网络允许你上传各种数据，这真的很重要。因此，数据也是如此。我可以谈论各种数据。我们可以谈论政府数据，企业数据非常重要。有科学数据，有个人数据。有天气数据，有关于事件的数据。有关于演讲的数据，还有新闻，还有各种各样的东西。我只会提到其中的一些，以便你了解它的多样性，以便你也看到多少未开发的潜力。
52 |
53 | ### 政府数据
54 |
55 | 让我们从政府数据开始。巴拉克·奥巴马在一次演讲中说，美国政府的数据将在互联网上以可访问的格式提供。我希望他们能以关联数据的形式发布。这很重要。为什么重要？不仅仅是为了透明度。是的，政府的透明度很重要。但这些数据，这是来自所有政府部门的数据。想想这些数据中有多少是关于美国人生活的。它实际上是有用的，它有价值。我可以在我的公司中使用它。我可以作为一个孩子来做我的家庭作业。所以我们在谈论通过提供这些数据来让世界更好地运行。
56 |
57 | ### 现在要求原始数据
58 |
59 | 事实上，如果你负责，如果你知道政府部门中的一些数据，你会发现这些人，他们很容易被诱惑去保留它，进行数据库拥抱。你拥抱你的数据库，不想放手，直到你为它制作了一个漂亮的网站。好吧，我想建议在你——是的，制作一个漂亮的网站（我是谁来说“不要制作一个漂亮的网站”）。制作一个漂亮的网站，但首先，给我们未加工的数据。我们想要数据。我们想要未加工的数据。好的。
60 |
61 | 我们现在必须要求原始数据，我会请你练习一下，好吗？你能说“原始”吗？你能说“数据”吗？你能说“现在”吗？对：“原始数据现在”。练习一下，这很重要，因为你不知道人们想出多少借口来保留他们的数据，而不是给你，即使你作为纳税人已经为它付了钱。这不仅仅是美国，当然也是企业。
62 |
63 | ### 科学数据
64 |
65 | 所以我只会提到一些其他的数据来源。好吧，我们在这里，TED，我们一直非常清楚人类社会现在面临的巨大挑战。治愈癌症。理解阿尔茨海默症的大脑。理解经济，使其更加稳定。理解世界如何运作。那些将要解决这些问题的人是科学家，他们在脑海中形成了坚定的想法。他们试图通过网络传达这些想法，但目前人类的许多知识状态都在数据库中，通常坐在他们的计算机中，实际上通常不共享。
66 |
67 | 事实上，我只会提到一个领域：如果你在研究阿尔茨海默症，例如，药物发现，有大量的关联数据刚刚出现，因为该领域的科学家意识到这是摆脱那些孤岛的好方法。因为他们在一个数据库和一个建筑中有基因组数据。他们在另一个地方有蛋白质数据。现在他们正在把它粘贴到上面：关联数据。现在他们可以提出一个问题，一个你可能不会问的问题，我不会问，他们会问：“哪些蛋白质参与信号转导并且也与金字塔神经元相关？”
68 |
69 | 好吧，你拿走那个（？？），如果你把它放到谷歌上，当然，网上没有页面可以回答这个问题，因为没有人以前问过这个问题。你得到223,000个结果：没有你可以使用的结果。你问他们现在放在一起的关联数据：32个结果，每个都是具有这些特性的蛋白质，你可以查看。能够问科学家这些问题的能力，那些实际上跨越不同学科的问题，真的是一个完全的（？？）变化。这非常非常重要。科学家们完全（？？）在那里的时刻（？）。其他科学家收集的数据的力量被锁定了，我们需要解锁它，以便我们解决那些巨大的问题。
70 |
71 | ### 个人数据
72 |
73 | 现在，如果我继续这样说，你会认为所有的数据都来自大型机构，与您无关。但事实并非如此。实际上，数据是关于我们生活的。你只是——你登录到你的社交网络网站，选择你喜欢的一个，你说“这是我的朋友”，*叮*，关系，数据。你说“这张照片，哦，它是关于——它描绘了这个人”，*叮*，那是数据。数据数据数据。
74 |
75 | 每次你在社交网络网站上做事情，社交网络网站都在获取数据并使用它，重新利用它。并使用它使其他人在网站上的生活更有趣。但当你去另一个关联数据网站时，你说这个关于旅行的，你说“我想把这张照片发送给那个群组中的所有人”，你无法越过墙。经济学人写了一篇关于它的文章，很多人对此进行了博客，极大的挫折。打破孤岛以实现社交网络网站之间的互操作性的方法，我们需要用关联数据来做到这一点。
76 |
77 | ### OpenStreetMap
78 |
79 | 我将谈论的最后一种数据类型，也许是最令人兴奋的，在我来这里之前，我查看了OpenStreetMap。OpenStreetMap是一张地图，但它也是一个维基。放大，那是我们现在所在的剧院，露台剧院。它没有名字。所以我可以进入编辑模式，我可以选择剧院。我可以在底部添加名称。然后我可以保存它，现在如果你回到openstreetmap.org，你找到这个地方，你会发现露台剧院有一个名字。我做到了，我。我在地图上做到了。我刚刚做了，我把它放在那里，你知道吗？如果我——街道地图是关于每个人都做他们的一点点，这创造了一个令人难以置信的资源，因为其他人都做了他们的部分。
80 |
81 | ### 这就是它的全部意义所在
82 |
83 | 这就是关联数据的全部意义所在。它是关于人们做他们的一点点，并且它们都连接在一起。这就是关联数据的工作原理。但你做你的一点，其他人也这样做。你可能没有很多数据需要——你自己放在那里，但你知道要去要求它，我们已经练习过了。所以，关联数据是巨大的。我只告诉你很少的一部分。在我们生活的每个方面都有数据，每个工作和娱乐方面，好吗？这不仅仅是关于数据来自多少地方。它是关于将它们连接在一起，当你将数据连接在一起时，你会以一种仅仅通过网络，通过文档无法实现的方式获得力量。你从中获得了真正巨大的力量。
84 |
85 | 所以，我们现在处于一个阶段，我们必须这样做。那些——认为这是个好主意的人。以及所有的人，我认为TED上有很多人，他们做事情，因为即使没有立即的投资回报，你也有——因为只有当其他人都这样做时，它才会真正回报，他们会这样做，因为他们是那种人，他们只是做事情，如果其他人都这样做会很好。好吗？所以它被称为关联数据。我希望你去做。我希望你去要求它。我认为这是一个值得传播的想法。谢谢。
86 |
87 | ## 版权声明
88 | Copyright (c) 2024 GaoWei Chang
89 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
90 |
--------------------------------------------------------------------------------
/chinese/思考&问题/atproto-vs-anp.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | https://atproto.com/specs/data-model#relationship-with-ipld
4 |
5 |
6 | AT protocol 和 ANP 的对比要好好研究下，我发现它的设计有很多和我之前很像的地方。
7 |
8 | 比如联盟。我要学习它的理念。
9 |
10 | at Protocol支持did web，同时也支持自己的标识符PLC。
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 | ## 版权声明
22 | Copyright (c) 2024 GaoWei Chang
23 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
24 |
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/agent-find.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/agent-find.png
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/mcp-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/mcp-architecture.png
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/mcp-auth-thinking.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/mcp-auth-thinking.png
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/meta-protocol-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/meta-protocol-flow.png
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/meta-protocol-weather.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/meta-protocol-weather.png
--------------------------------------------------------------------------------
/chinese/思考&问题/pic/protocol-layer-design.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/chinese/思考&问题/pic/protocol-layer-design.png
--------------------------------------------------------------------------------
/chinese/思考&问题/其他/介绍did-wba.md:
--------------------------------------------------------------------------------
1 |
2 | ## 版权声明
3 | Copyright (c) 2024 GaoWei Chang
4 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
5 |
--------------------------------------------------------------------------------
/chinese/思考&问题/协议与技术对比/http与ANP.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | http在设计的时候，就考虑了互联网架构，设计了包括代理、网关、缓存、路由、负载均衡等机制。这些机制我们如何使用？
4 | 第一步基于http协议，是个非常务实的选择。
5 | 第二步，我们在设计独立的协议，或者作为http4.0的补充。
6 |
7 | http设计目标，是否与智能体的目标一致？这里有优化的空间
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 | ## 版权声明
20 | Copyright (c) 2024 GaoWei Chang
21 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
22 |
--------------------------------------------------------------------------------
/chinese/思考&问题/协议与技术对比/整体通俗介绍文章.md:
--------------------------------------------------------------------------------
1 | # 标题：对标Anthropic MCP，来自中国团队的这个开源协议已经能让智能体自己组网了
2 | # 标题：对标Anthropic MCP，这个来自中国的开源协议也许是AI创业公司C端困境突破口
3 |
4 | ## 导读：
5 | Anthropic前几天发布了一个开源协议MCP（Model Context Protocol），引起了全网热议。而来自中国的一个团队很早之前就投入在这个领域，并开源了一个类似的协议ANP（Agent Network Protocol），ANP最新版本已经能够让智能体自己组网。也许AI时代互联网的HTTP协议，正在被定义，并且彻底颠覆之前的互联网生态。
6 |
7 | ## 什么是MCP？
8 | MCP是一种让AI大模型和外部数据“对话”的新技术。它的作用就像一座桥梁，让AI可以轻松获取和使用各种工具或数据源。以前，AI应用常常因为数据连接困难，被困在“信息孤岛”里。现在有了MCP，AI就能像用万用插头一样连接所有需要的资源。这将会极大提供AI产品的体验，并且有可能彻底改变互联网的生态。
9 |
10 | 
11 |
12 | 但是MCP现在还有一个致命的缺陷，就是不支持远程连接，只能访问本地服务，这将大大限制MCP的实用性。
13 |
14 | 究其根本原因，是MCP社区还没有想好如何在AI和外部服务之间做身份认证。而这个问题，来自中国的一个团队在几个月之前就已经解决了，并且开源了一个类似的协议ANP（Agent Network Protocol），致力于为智能体提供通信能力。
15 |
16 | ## ANP
17 |
18 | ANP团队成员大部分来自于阿里巴巴，他们在2024年初就开始探索智能体通信，并且发布了开源的协议规范与代码实现。最新版本已经能够支持智能体之间的身份认证、端到端加密通信、元协议协商、应用层协议代码生成。有了这些能力，智能体就可以自己组成一个网络，并且相互之间协作。我们来看下它是怎么实现的。
19 |
20 | 协议规范：https://github.com/agent-network-protocol/AgentNetworkProtocol
21 |
22 | 代码实现：https://github.com/agent-network-protocol/AgentConnect
23 |
24 | 
25 |
26 | ### 身份认证：最重要的问题
27 |
28 | 智能体之间做身份认证很重要，但是也很难，否则MCP也就不会在没有一个完整的身份认证方案的情况下发布了。
29 |
30 | 它难在什么地方？最难的点在于，AI时代的身份认证要求和互联网时代是完全不一样的。
31 |
32 | 互联网时代的身份认证往往是中心化的方案，比如微信，你的微信ID只能在微信的生态中使用，不能在淘宝、抖音中使用。这就造成了一个个数据孤岛，数据不互通，AI就无法获得你的全部信息，从而无法做出正确的决策和行动，AI产品的体验也就难以得到质的提升。
33 |
34 | 这一点很多创业公司其实已经意识到了，比如Anthropic的MCP团队，他们认为，MCP的生态应该是一个开放性的生态，他们更愿意避免使用中央信任机构。
35 |
36 | 
37 |
38 | 为什么去中心化的身份认证对AI如此重要？
39 |
40 | 看看中国过去两年发生的案例我们也许就能明白。
41 |
42 | 会读是去年比较火的一款阅读类AI应用，主要在微信平台发展。但是当用户量起来之后，账号频繁的被微信封禁，最终导致项目失败。很多用户都非常喜欢这款AI产品，但是没有用，用户身份掌握在微信手中。
43 |
44 | 从这个角度看，中心化的传统互联网和移动互联网巨头，他们不是AI这个先进生产力的助力，而是阻碍。
45 |
46 | 结合近期中国大模型头部创业公司的困境，我们也许能清晰的看到，只有跳出传统互联网和移动互联网巨头构建的生态，才能真正释放AI的生产力，创业公司才能找到新的出路。
47 |
48 | 而这些的第一步，就是设计一个去中心化的身份认证方案。
49 |
50 | ANP并没从头开始创建标准，而是基于W3C在2022年发布的DID（Decentralized Identifiers）标准来构建。DID设计之初就是为了解决互联网中心化身份问题，它能够让用户自己掌握的身份，并且能够进行跨平台的身份认证。
51 |
52 | ANP最大的贡献在于，设计了一个DID方法，能够让身份认证依赖于密码学技术而非中心化机构，并且在去中心化和扩展性中间找到一个平衡点，让DID在去中心化的同时，也能够大规模的落地。
53 |
54 | ### 元协议让智能体自己组网
55 |
56 | 所谓的元协议，即协议的协议，是用来协商智能体之间的通信协议。
57 |
58 | 智能体与传统服务器最大的区别，是智能体可以利用AI的能力，自己寻找满足条件的智能体，并且两个智能体之间可以用自然语言协商通信协议，然后通过AI生成的协议代码，完成数据的通信。在这个过程中，两个智能体还能够使用元协议自动进行协议对接的联调和升级。下面是智能体使用ANP元协议建立连接的全过程：
59 |
60 | 
61 |
62 | 下面以获取天气信息为例，展示智能体A和智能体B使用元协议进行协议协商的基本流程：
63 |
64 | 
65 |
66 | 有了元协议，智能体就可以实现在无人参与下的自组网，并且相互协作。相信一张能够自组织自协商的智能体网络，会在未来释放出更大的生产力。
67 |
68 |
69 | ### 应用层协议层：智能体发现与描述
70 |
71 | 所有的连接都是用元协议协商建立，成本是相当高的，而且由于流程过长，耗时也更长。所以ANP在应用层设计了一个智能体能力发现与描述的机制。这一点和MCP的设计类似。
72 |
73 | 比如，智能体可以将自己的身份、能力以及支持的协议注册到一个智能体发现服务上，其他的智能体就可以根据条件搜索到这个智能体，并且根据智能体支持的协议和这个智能体进行通信。这可以极大的提高智能体之间的连接效率。
74 |
75 | 
76 |
77 | 应用层的协议可以是人类现有的标准，也可能是智能体相互之间协商出来的共识标准，也可以是两个智能体之间的私有协议。也许未来，智能体之间自动协商的协议会远超过人类制定的协议。
78 |
79 | ## 未来
80 |
81 | 相对于Anthropic的MCP，ANP的行业影响力是远远不够的，不过我们能够从它的设计中，看到一些不错的设计思路。
82 |
83 | 最后，无论是MCP也好，还是ANP也好，这个领域目前都处于非常早期的阶段，一切都还不确定。
84 |
85 | 也许最重要的，不是MCP或ANP成为行业标准，而是未来行业一定要有一个标准，它是开放的、去中心化的，这样才能够最大程度释放AI的生产力。
86 |
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 | ## 版权声明
98 | Copyright (c) 2024 GaoWei Chang
99 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
100 |
--------------------------------------------------------------------------------
/chinese/思考&问题/智能体网络与通信/E2E类似项目.md:
--------------------------------------------------------------------------------
1 |
2 | didcomm
3 | 规范地址：https://identity.foundation/didcomm-messaging/spec/v2.1/
4 |
5 | # 对比
6 | 我们的didall，要求对方必须在线，如果不在线，则无法通信。
7 |
8 | didcomm没有此要求，对方不在线也可以发送加密消息。并且didcomm支持匿名加密，支持保护发送人和接收人信息。
9 |
10 |
11 | # 现有端到端加密项目
12 |
13 | 当前流行的端到端加密（End-to-End Encryption，E2EE）协议有很多，涵盖即时通讯、电子邮件、文件共享、视频会议等多个场景。下面列出几种常见的 E2EE 协议和方案：
14 |
15 | 1. Signal Protocol
16 | - 应用场景：即时通讯（如 Signal、WhatsApp、Facebook Messenger）
17 | - 核心特点：
18 | - 双重 Ratchet 算法：结合了 Diffie-Hellman 密钥交换和双 Ratchet 算法（包含密钥派生和对话状态同步）
19 | - 前向安全性和后向安全性：即使某个密钥被泄露，也不会影响其他消息的安全性
20 | - 使用 X3DH（Extended Triple Diffie-Hellman）和 Double Ratchet 算法实现密钥交换和消息加密
21 | - 优势：Signal Protocol 是目前安全性最高、实现最广泛的端到端加密协议之一
22 |
23 | 2. Matrix / Olm 和 Megolm Protocol
24 | - 应用场景：即时通讯（如 Element 客户端，Matrix 网络）
25 | - 核心特点：
26 | - Olm：用于单人对单人聊天，基于 Double Ratchet 算法，类似 Signal Protocol
27 | - Megolm：用于群组聊天，采用对称密钥加密，优化性能以支持大型群聊
28 | - 支持前向安全性，但由于群聊性能优化，部分后向安全性有所折中
29 | - 优势：适合大规模群聊，并支持分布式服务器架构
30 |
31 | 3. Double Ratchet Algorithm
32 | - 应用场景：作为一种广泛使用的加密算法，应用于 Signal Protocol 和 Matrix Olm
33 | - 核心特点：
34 | - 结合对称密钥和非对称密钥加密，提供前向安全性和后向安全性
35 | - 使用 Ratchet 算法不断更新加密密钥，使每一条消息都有独立的加密密钥
36 |
37 | 4. OMEMO（XMPP Extension Protocol XEP-0384）
38 | - 应用场景：基于 XMPP 协议的即时通讯（如 Conversations、Dino 等 XMPP 客户端）
39 | - 核心特点：
40 | - 使用 Signal Protocol 的 Double Ratchet 算法，支持端到端加密和多设备同步
41 | - 允许在不同设备上同时发送和接收加密消息
42 | - 优势：在 XMPP 协议中实现端到端加密，提供了强大的安全性
43 |
44 | 5. PGP / GPG（Pretty Good Privacy / GNU Privacy Guard）
45 | - 应用场景：电子邮件、文件加密
46 | - 核心特点：
47 | - 使用非对称加密算法（RSA、DSA、ECC 等）进行密钥交换和签名
48 | - 对称加密算法（AES、3DES 等）用于加密消息内容
49 | - PGP 主要依赖于用户生成和交换公钥，难以自动化管理
50 | - 优势：具有高安全性，但密钥管理复杂，用户体验较差
51 |
52 | 6. MLS (Messaging Layer Security)
53 | - 应用场景：即时通讯、群组聊天
54 | - 核心特点：
55 | - 由 IETF 开发的新标准，旨在提供高效的端到端加密，特别针对大规模群聊
56 | - 使用 TreeKEM 算法进行密钥交换，提供前向安全性和后向安全性
57 | - 优势：解决了传统协议在群组通信中的性能问题，适合用于大型分布式系统
58 |
59 | 7. WireGuard (用于 VPN)
60 | - 应用场景：VPN、网络通信加密
61 | - 核心特点：
62 | - 基于 Noise Protocol Framework 实现，提供高效、轻量级的端到端加密
63 | - 使用 Curve25519、ChaCha20、Poly1305 等现代加密算法
64 | - 优势：速度快、性能高，配置简单
65 |
66 | 8. Noise Protocol Framework
67 | - 应用场景：广泛用于加密通信协议（如 WireGuard、WhatsApp 中的一部分）
68 | - 核心特点：
69 | - 提供灵活的密钥交换模式，支持多种非对称和对称加密算法
70 | - 可定制化，适用于各种加密通信场景
71 | - 优势：安全性强，适合构建自定义的端到端加密协议
72 |
73 | 9. DIDComm (Decentralized Identifier Communication Protocol)
74 | - 应用场景：去中心化身份、跨平台通信
75 | - 核心特点：
76 | - 基于去中心化身份（DID），支持点对点的端到端加密消息传递
77 | - 使用 JSON 或 JWE 格式，支持多种加密算法
78 | - 优势：与去中心化身份标准结合，适合 Web3 和去中心化应用场景
79 |
80 | 10. ZRTP（Zimmermann Real-time Transport Protocol）
81 | - 应用场景：语音和视频通话加密
82 | - 核心特点：
83 | - 通过 Diffie-Hellman 密钥交换实现端到端加密，无需预共享密钥
84 | - 使用 SAS（Short Authentication String）进行通话双方的身份验证
85 | - 优势：不依赖于 PKI，适用于 VoIP 等实时通信
86 |
87 | 总结：
88 | - 即时通讯：Signal Protocol、Matrix Olm/Megolm、OMEMO、MLS
89 | - 文件和邮件加密：PGP/GPG
90 | - VPN/网络通信：WireGuard、Noise Protocol Framework
91 | - 去中心化身份：DIDComm
92 | - 语音/视频通话：ZRTP
93 |
94 | 这些协议都各有优缺点，选择时需考虑应用场景、安全需求和性能要求。如果你正在设计自己的端到端加密方案，可以参考这些协议的核心设计思想，并结合实际需求进行优化。
95 |
96 |
97 | ## 版权声明
98 | Copyright (c) 2024 GaoWei Chang
99 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
100 |
--------------------------------------------------------------------------------
/chinese/思考&问题/智能体网络与通信/价值思考.md:
--------------------------------------------------------------------------------
1 |
2 | # 智能体通信的价值
3 |
4 | 亚马逊、淘宝等电商平台的本质是去除中间商，缩短交易链路，降低交易成本。但是之后，他们本身就变为了新的中间商。
5 |
6 | 智能体之间直接通信，将会进一步的缩短交易链路，降低交易成本。交易将直接在智能体之间完成，而不用在平台完成。
7 |
8 |
9 |
10 |
11 | ## 版权声明
12 | Copyright (c) 2024 GaoWei Chang
13 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
14 |
--------------------------------------------------------------------------------
/chinese/思考&问题/智能体网络与通信/元协议思考.md:
--------------------------------------------------------------------------------
1 |
2 | # 长远看元协议的价值
3 |
4 | 智能体预先确定协议，并且对外声明出去，那么和这个智能体通信的智能体，可以直接使用智能体支持的协议通信，而不需要协商，这样元协议的价值就大大降低了。
5 |
6 | 但是，元协议仍然有其价值，因为他们解决了两个智能体、异构智能体之间个性化通信成本问题。
7 |
8 | 现在的通信协议，如果用预先定义好的方式，往往都是硬编码的，这样无法达到个性化通信，即我无法与智能体进行个性化的互动。
9 |
10 | # 数据传递的格式
11 |
12 | 数据的传递，最高效的不是html/CSS/javascript，而是json/protobuf等格式。
13 |
14 | 传统的web应用，是基于html/CSS/javascript技术栈构建的的，所以浏览器可以展示数据、交互、展示界面。他们都是为人而设计的。
15 |
16 | 未来的智能体应用，html/CSS/javascript技术栈将会被替代，智能体之间只需要传递核心数据，具体如何展示、如何与人交互，将由智能体自己完成。
17 |
18 | 所以，智能体之间的数据传递，最高效的是json/protobuf等格式。
19 |
20 | 格式的定义，即协议的定义，将由智能体之间协商、或者人类定义。
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 | ## 版权声明
29 | Copyright (c) 2024 GaoWei Chang
30 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
31 |
--------------------------------------------------------------------------------
/chinese/思考&问题/智能体网络与通信/智能体发现与描述.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | ## 对A2S的反馈
6 |
7 | 地址：
8 | https://github.com/keithagroves/agent-to-service/blob/main/README.md
9 |
10 |
11 | 与我们的设想一致的点：
12 | - 发现与描述比元协议协商要更加的节省成本，并且这应该是未来大部分智能体通信的方式。但是元协议会提供个性的通信能力。还是有它的价值。
13 | - 架构图也与我们的设想一致：需要有一个发现&索引服务，能够发现智能体或服务、返回他们的描述信息。
14 | - 使用openapi描述服务也是一个不错的选择
15 |
16 |
17 | 其他：
18 | - 我不大清楚Flow Control这部分是不是也是协议的一部分。它也许不应该是A2S的一部分，它是智能体规划的一部分。我理解A2S应该是大部分是原子的API描述，组合的部分，可以让智能体来做。这里我还不清楚你设计的目的。
19 | - 另外同上，聚合功能可能在智能体中实现会更好。
20 | - 还有任务，我看下来，好像你设计了在协议中描述复杂流程的方式。这个是要让智能体发送给API提供方来执行吗？还是你定义了智能体描述复杂流程的规范？
21 | - 按照我的理解，Agent-to-Service Protocol 本身，应该专注在描述原子的能力，flow、task、聚合功能等，也许放到Agent中会更合适，让实现Agent的人自己处理。
22 |
23 |
24 | - 智能体的描述，应该类似于web站点，能够让智能体搜索或发现服务去主动收集，类似与web的搜索引擎和web的站点的关系。不同的是，web站点是面向人类的，而智能体是面向AI的。
25 |
26 |
27 |
28 | **是不是可以写一个后台的服务，然后让智能体将他们的能力注册过来。我读取他们的文档列表。开发给其他的查询接口。类似pypi。**
29 |
30 |
31 |
32 | 接口的描述：可以是openapi，也可以是json-rpc，或语义网的规范。
33 |
34 |
35 | ## 版权声明
36 | Copyright (c) 2024 GaoWei Chang
37 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
38 |
--------------------------------------------------------------------------------
/chinese/思考&问题/智能体网络与通信/智能体网络的特点.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ## 版权声明
4 | Copyright (c) 2024 GaoWei Chang
5 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
6 |
--------------------------------------------------------------------------------
/chinese/思考&问题/身份认证与加密/MCP-wba-commit.md:
--------------------------------------------------------------------------------
1 | [proposal]Support for authentication methods based on the W3C DID specification `did:wba`
2 |
3 | ## Motivation and Context
4 |
5 | We have added an experimental authentication scheme, `did:wba`, to MCP.
6 |
7 | We believe `did:wba` can serve as an excellent complement to OAuth 2.0 for the following reasons:
8 | 1. `did:wba` provides security equivalent to OAuth 2.0.
9 | 2. `did:wba` supports decentralized identity authentication, offering better interoperability.
10 | 3. `did:wba` requires fewer interactions and has a simpler process.
11 |
12 | Using did:wba can lower the barrier for users to access MCP servers. Taking API services like exa as an example, if exa also supports did:wba and provides an API subscription interface, users won't need to log in to exa for registration, configuration, and subscription operations. The MCP client can directly use the API and the user's DID to subscribe to exa's services, then send requests with authentication information to exa's MCP server for identity verification and API calls. This makes it much more convenient for users to utilize various MCP servers.
13 |
14 |
15 | The changes in this code are based on a branch that has not yet been merged into the main branch (PR link: [https://github.com/modelcontextprotocol/specification/pull/101](https://github.com/modelcontextprotocol/specification/pull/101)). We will update our code accordingly if there are any changes to this branch.
16 |
17 | ## How Has This Been Tested?
18 | This proposal has not yet been implemented in a client/server.
19 |
20 | ## Breaking Changes
21 | Users do not need to update their code or configuration. As an experimental scheme, the server or client can choose not to support it.
22 |
23 | ## Types of changes
24 | - [ ] Bug fix (non-breaking change which fixes an issue)
25 | - [x] New feature (non-breaking change which adds functionality)
26 | - [ ] Breaking change (fix or feature that would cause existing functionality to change)
27 | - [ ] Documentation update
28 |
29 | ## Checklist
30 |
31 | - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io)
32 | - [x] My code follows the repository's style guidelines
33 | - [x] New and existing tests pass locally
34 | - [x] I have added appropriate error handling
35 | - [x] I have added or updated documentation as needed
36 |
37 | ## Additional context
38 |
39 |
40 | Relevant documentation links:
41 | 1. [did:wba Method Design Specification](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/03-did%3Awba%20Method%20Design%20Specification.md)
42 |
43 | 2. blogs：
44 | - [did:wba - A Web-based Decentralized Identifier](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/did%3Awba%2C%20a%20Web-based%20Decentralized%20Identifier.md)
45 | - [Security Principles of did:wba](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/did%3Awba-security-principles.md)
46 | - [The Most Suitable Identity Authentication Technology for Agents: Comparing OpenID Connect, API Keys, and did:wba](https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/blogs/Comparison%20of%20did%3Awba%20with%20OpenID%20Connect%20and%20API%20keys.md)
47 |
48 |
49 | ## 版权声明
50 | Copyright (c) 2024 GaoWei Chang
51 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
52 |
--------------------------------------------------------------------------------
/chinese/思考&问题/身份认证与加密/did.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | # 是否可以让did支持http？
4 | http over did？进行身份认证与加密？如果这个路径可以跑通，那
5 |
6 |
7 | # did的问题
8 |
9 | did all可能存在最终的问题：安全的根在哪里，用户是否能够接受。
10 | 它的有点是成本低，比did web要低，did web要么需要自己部署，要么需要依赖于别人的服务并且自己其实是没有控制权的(也许可以通过URL的设计来获取控制权，在URL中把公钥的hash写进去)
11 |
12 | 回到根本上，web是通过域名的申请，来实现最终的信任根。域名与机构或个人绑定，机构或个人对域名下的内容负责。
13 |
14 | 我们是不是设计一个DID的域名系统？
15 |
16 |
17 | # 规范学习
18 |
19 | 规范：https://www.w3.org/TR/did-core/
20 | 用例（有助于理解DID过程，有很多过程描述，比did-core更详细）：https://www.w3.org/TR/did-use-cases/
21 | 扩展：https://github.com/w3c/did-extensions
22 |
23 | ## 规范
24 |
25 | 去中心化标识符 （DID） 是一种新型标识符，可实现可验证的去中心化数字身份。DID 是指任何主体（例如，人员、组织、事物、数据模型、抽象实体等）由 DID 的控制器确定。与典型的联合标识符相比，DID 的设计使其可以与集中式注册表、身份提供商和证书颁发机构分离。具体来说，虽然其他方可能被用来帮助发现与 DID 相关的信息，但该设计**使 DID 的控制者能够证明对它的控制，而无需任何其他方的许可**。DID 是将 DIDsubject 与 DID 文档关联的 URI，允许与该主题关联的可信交互。
26 |
27 | 每个 DID 文档都可以表达加密材料、验证方法或服务，它们提供了一组机制，使DID 控制器能够证明对 DID 的控制。服务支持与 DID 主题关联的可信交互。如果 DIDsubject 是数据模型等信息资源，则 DID 可能会提供返回 DID 主题本身的方法。
28 |
29 | **我们可以使用测试套件验证是否符合规范**在发布时，存在103 个实验性 DID 方法规范、32 个实验性 DID 方法驱动程序实现、一个确定给定实现是否符合此规范的测试套件以及 46 个提交给一致性测试套件的实施。建议读者注意 DID Core 问题和 DID Core Test Suite问题，它们都包含可能导致本规范更改的最新问题和拟议更改列表。在发布时，预计不会有其他实质性问题、更改或修改。
30 |
31 | 本规范中定义的去中心化标识符 （DID） 是一种新型的全局唯一标识符。它们旨在使个人和组织能够使用他们信任的系统生成自己的标识符。这些新的标识符使实体能够通过**使用加密证明（如数字签名）进行身份验证来证明对它们的控制**。
32 |
33 | 由于去中心化标识符的生成和断言是由实体控制的，因此**每个实体都可以拥有任意数量的 DID，以维持其所需的身份、角色和交互分离**。
34 |
35 | 本规范不预设任何特定的技术或密码学来支持 DID 的生成、持久性、解析或解释。例如，实施者可以基于在联合或集中式身份管理系统中注册的标识符创建去中心化标识符。事实上，几乎所有类型的标识符系统都可以添加对 DID 的支持。**这在集中式、联合式和去中心化标识符的世界之间架起了一座互操作性桥梁**。这还使实施者能够设计特定类型的 DID，以与他们信任的计算基础设施配合使用，例如分布式账本、去中心化文件系统、分布式数据库和点对点网络。
36 |
37 | 这些因素表明，在某些情况下需要“自我主权”的全局唯一标识符，即不依赖于任何颁发机构的标识符。通用唯一标识符 （UUIDs） [] 履行此角色，但是，无法证明对 UUID 的控制。
38 |
39 | ## 用例
40 |
41 | 控制者、请求方和主体：
42 | - 控制者和主体一般相同。但是，有点时候不同，比如当员工代表其雇主管理 DID 或父母代表其孩子使用 DID 时。
43 | - DID 控制者和请求方可以是个人或交互式系统，但为简单起见，在本文件中，我们将两者称为执行这些操作的个人。
44 | - 只有 DID 控制器可以执行控制 DID 的操作，但是，如果他们希望检查或验证自己的 DID，任何人都可以充当他们知道的任何 DID 的请求方，包括 DID 控制器。
45 |
46 | 也许去中心化标识符最突出的一点是没有“身份提供者”。相反，这个角色被包含在控制者用来管理 DID 的去中心化系统中，反过来，请求方用来应用 DID。预计 DID 将使用分布式账本技术 （DLT） 进行注册。
47 |
48 | ## 概念
49 |
50 | 用例：https://www.w3.org/TR/did-use-cases/
51 |
52 | authenticate 证实
53 | 身份验证是一个过程（通常是某种类型的协议），通过该过程，实体可以使用一种或多种验证方法来证明它具有特定属性或控制特定密钥。对于 DID，一个常见的示例是证明对与 DID 文档中发布的公钥关联的私钥的控制权。
54 |
55 | decentralized identifier (DID) 去中心化标识符 （DID）
56 | 一个全局唯一的永久标识符，不需要集中注册机构，因为它是以加密方式生成和/或注册的。DID 的通用格式在 DID Core 规范 [DID-CORE] 中定义。在 DID 方法规范中定义了特定的 DID 方案。许多—但不是全部—DID 方法利用**分布式账本技术 （DLT） 或其他形式的去中心化网络**。
57 |
58 | DID controller DID 控制器
59 | 能够更改 DID 文档的实体。一个 DID 可以有多个 DID 控制器。DID 控制器可以用 DIDdocument 顶层的可选 controller 属性来表示。请注意，一个 DID 控制器可能是 DID 主体。
60 |
61 | DID方法
62 | 一种定义了特定DID方案如何实现以适配特定可验证数据注册表的规范。DID方法由DID方法规范定义，该规范必须明确规定创建、解析和注销DID以及编写和更新DID文档的具体操作方式。
63 |
64 | services 服务业
65 | 通过**一个或多个服务端点与 DID 主体或关联实体进行通信或交互的方式**。示例包括**发现服务、代理服务、社交网络服务、文件存储服务和可验证凭证存储库服务**。
66 |
67 | verification method 验证方法
68 | 一组参数，可与流程或协议一起使用，以独立验证证明。例如，公钥可以用作数字签名的验证方法;在这种用法中，它会验证签名者是否拥有关联的私钥。
69 |
70 | 本定义中的“验证”和“证明”旨在广泛适用。例如，在 Diffie-Hellman 密钥交换期间，可能会使用公钥来协商用于加密的共享对称密钥。这保证了密钥协议流程的完整性。因此，它是另一种类型的验证方法，即使该过程的描述可能没有使用“验证”或“证明”这两个词。
71 |
72 |
73 | Authenticate 5.2.2 身份验证
74 | 请求方可能希望证明提供 DID 的个人实际上是其 DID 控制者或被指定为特定服务端点的控制者。这个身份验证过程应该使用 DID 文档中的 cryptographicmaterial 来测试所声称的 Controller 是否真的可以证明控制权，通常是通过某种质询-响应。DID 文档和方法可能允许对不同的服务端点进行单独的证明，这与 update 和 delete 操作不同。这种分离将支持预期会经常使用的事务性证明，而预期很少使用控制证明。
75 |
76 | Resolve 5.3.1 解决
77 | 将 DID 用于演示以外的任何用途的第一步是将 DID 解析为特定的 DID 文档，以显示与该 DID 关联的加密材料和服务端点。这种情况的发生方式应该是特定于方法的，并且超出了 DID 工作组的范围。
78 |
79 | Dereference 5.3.2 取消引用
80 | 取消引用 DID 会使用其 DID 文档中的材料来返回资源。预期结果是，默认情况下，在没有引用服务端点的情况下取消引用 DID 将返回 DID 文档本身。当 DID 与service parameter组合（形成 DID URL）时，取消引用将返回从命名服务端点指向的资源，该资源是通过将 DID 解析为其 DID 文档并按名称查找端点来发现的。通过这种方式，请求方可以动态地发现给定 DID 的当前服务端点并与之交互。因此，可以为服务提供持久标识符，即使底层 serviceendpoints 发生更改，这些标识符也不会更改。
81 |
82 |
83 | Deactivate 5.5.1 停用
84 | 控制器应该能够停用 DID，而不是删除 DID，这样 authentication 和 derefencing 等下游进程就不再起作用了。大多数分散式系统无法保证实际删除记录。事实上，分布式账本经常被吹捧为“不可变”。方法应定义停用过程以实现与删除相同的效果。停用机制因方法而异，因此“非活动”消息会有所不同。
85 |
86 |
87 |
88 | # DID WEB方法
89 |
90 | DID并未制定身份验证和授权、对DID验证、完整性的方法。
91 |
92 |
93 | DID web的信任核心在于DNS。
94 |
95 | 由于 did：web 方法的性质依赖于 DNS 来解析 Web 服务器，因此 did：web 标识符的所有解析都有可能被 DNS 提供商跟踪。此外，由于 DID 文档存储在 Web 服务器上，因此每次检索 DIDDocument 资源时，Web 服务器都能够跟踪 DID 文档的分辨率。为了缓解在解析 DID 文档时依赖方被跟踪的问题，依赖方应该考虑使用受信任的通用解析器服务来获得羊群隐私、使用 VPN 服务或通过 TOR 网络执行解析。另一个有助于解决此问题的新兴解决方案是 draft-pauly-dprive-oblivious-doh-03
96 |
97 |
98 |
99 |
100 |
101 |
102 | ## 版权声明
103 | Copyright (c) 2024 GaoWei Chang
104 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
105 |
--------------------------------------------------------------------------------
/chinese/思考&问题/身份认证与加密/加密思考.md:
--------------------------------------------------------------------------------
1 | # 如果应用层已经加密了，为什么还要在传输层加密
2 |
3 | 在应用层已经进行了加密的情况下，为什么仍然需要在传输层使用 TLS 加密呢？这是一个经典的问题，通常有以下几个重要的原因：
4 | 1. 保护元数据（Metadata Protection）
5 | - 应用层加密通常只加密消息的内容，但并不加密元数据，如：
6 | - IP 地址
7 | - 域名（通过 DNS 请求泄露）
8 | - 传输层的端口号
9 | - 消息的大小和时间戳
10 | - 传输层的 TLS 加密可以保护部分元数据（如请求的具体内容、HTTP 头部等），让中间人无法轻易分析通信模式或执行流量分析攻击。
11 |
12 | 2. 防止重放攻击（Replay Attack Protection）
13 | - TLS 提供了会话管理、序列号、MAC 校验等功能，能有效防止重放攻击。
14 | - 如果只依赖应用层加密，往往需要自行设计这些保护机制，增加了复杂性和出错风险。
15 |
16 | 3. 防止流量分析（Traffic Analysis）
17 | - 即使消息内容在应用层加密了，中间人仍然可以观察到明文的通信行为，比如：
18 | - 数据包的长度和数量
19 | - 通信的频率和模式
20 | - TLS 可以通过填充（padding）和会话加密，隐藏部分流量特征，增加攻击者进行流量分析的难度。
21 |
22 | 4. 防止中间人攻击（MitM Protection）
23 | - TLS 通过使用证书和公钥基础设施（PKI），可以验证通信双方的身份，防止中间人攻击（Man-in-the-Middle Attack）。
24 | - 即便应用层加密可以提供内容安全，但没有传输层的身份验证，中间人仍可能冒充服务器，导致通信被劫持或篡改。
25 |
26 | 5. 提升数据完整性（Integrity Enhancement）
27 | - TLS 在加密的同时，还会对每个数据包进行完整性校验，确保数据未被篡改。
28 | - 应用层加密虽然也能提供数据完整性校验，但通常是在更大的数据块上操作。TLS 在传输层的包级别完整性校验可以防止传输过程中发生的数据包篡改。
29 |
30 | 6. 简化应用层协议的设计（Ease of Development）
31 | - 应用层协议的设计和开发会更加复杂，尤其是在涉及到加密、身份验证和防重放保护时。
32 | - 使用 TLS 加密可以大大简化应用层的安全设计，让开发者专注于实现业务逻辑，而不用过于关注底层的加密细节。
33 |
34 | 7. 兼容现有基础设施（Compatibility with Existing Infrastructure）
35 | - 许多现有的基础设施，如负载均衡、反向代理、CDN 等，都是依赖于传输层加密（TLS）来保证数据的安全传输。
36 | - 仅使用应用层加密，可能无法与这些基础设施无缝集成，导致通信效率降低或功能受限。
37 |
38 | 总结：
39 | - 双重加密（应用层加密 + 传输层加密）是一种 "Defense in Depth"（纵深防御）策略。
40 | - 应用层加密保护的是数据内容，而传输层加密（TLS）保护的是传输通道和部分元数据。
41 | - 在高安全性的场景下，尤其是存在多个中间节点（如代理、CDN 等）时，两者结合使用，可以最大限度地提升通信的安全性和隐私性。
42 | - 这种双重加密方式类似于：你给一份重要文件装上了密封袋（应用层加密），但在寄送过程中还是使用了保险箱（TLS）来保护传输的安全。
43 |
44 |
45 | ## 版权声明
46 | Copyright (c) 2024 GaoWei Chang
47 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
48 |
--------------------------------------------------------------------------------
/chinese/思考&问题/身份认证与加密/秘钥泄漏问题.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | ## 版权声明
8 | Copyright (c) 2024 GaoWei Chang
9 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
10 |
--------------------------------------------------------------------------------
/chinese/相关产品与技术/ANP论文汇总.md:
--------------------------------------------------------------------------------
1 | # ANP论文汇总
2 |
3 |
4 | ## 上海交大
5 |
6 | https://arxiv.org/abs/2504.16736
7 |
8 | ## 西安交大
9 |
10 | https://arxiv.org/pdf/2505.07176v1
11 |
12 | ## 美国
13 |
14 | https://arxiv.org/pdf/2505.02279v1
15 |
16 | A SURVEY OF AGENT INTEROPERABILITY PROTOCOLS: MODEL CONTEXT PROTOCOL (MCP), AGENT COMMUNICATION PROTOCOL (ACP), AGENT-TO-AGENT PROTOCOL (A2A), AND AGENT NETWORK PROTOCOL (ANP)
17 |
18 |
19 |
20 |
--------------------------------------------------------------------------------
/chinese/相关产品与技术/相关开源项目.md:
--------------------------------------------------------------------------------
1 |
2 | ## agroa protocol
3 |
4 | https://agoraprotocol.org/
5 |
6 | ## Agent Connect Protocol
7 |
8 | Copyright (c) 2025 Cisco and/or its affiliates.
9 |
10 | https://github.com/agntcy/acp-spec
11 |
12 |
13 | ## Agent Communication Protocol (ACP)
14 |
15 | https://docs.beeai.dev/acp/alpha/introduction
16 |
17 | ## IEEE工作组IEEE SA-P3394大型语言模型代理接口标准
18 |
19 | In case you were not aware of it, there is an IEEE working group IEEE SA - P3394 Standard for Large Language Model Agent Interface https://standards.ieee.org/ieee/3394/11377/ that's been going for about a year now. I've not managed to make a meeting in a while but from what I see in mails they are developing a reference implementation to publish under BSD3. As the name implies, the focus is on the API but what gets sent each way clearly matters, so their spec needs to be flexible enough to accommodate a variety of communication protocols.
20 | 如果你不知道的话，有一个IEEE工作组IEEE SA-P3394大型语言模型代理接口标准https://standards.ieee.org/ieee/3394/11377/已经持续了大约一年。我有一段时间没有设法开会了，但从我在邮件中看到的情况来看，他们正在开发一个参考实现，并在BSD3下发布。顾名思义，重点是应用编程接口，但每种方式发送的内容显然很重要，所以他们的规范需要足够灵活，以适应各种通信协议。
21 | Lightweight Agent Standardization Working Group (LAS-WG)
22 |
23 |
24 | ## WOT
25 |
26 | https://webthings.io/
27 |
28 | ## agentsjson
29 |
30 | https://docs.wild-card.ai/agentsjson/introduction
31 |
32 | ## LMOS
33 |
34 | Eclipse LMOS | Eclipse LMOS
35 | 一个用于构建和运行多智能体系统的开源、云原生平台
36 |
37 | 里面有智能体通信、智能体描述等规范。
38 |
39 | https://eclipse.dev/lmos/docs/multi_agent_system/agent_communication
40 |
41 | ## Authenticated Delegation and Authorized AI Agents
42 |
43 | https://arxiv.org/abs/2501.09674
44 |
45 | # AITP
46 |
47 | https://github.com/nearai/aitp
48 |
49 |
50 | ## 学习一下near ai
51 |
52 | https://app.near.ai/agents
53 |
54 | NEAR AI 正在开发代理交互与交易协议（AITP），这是一个“针对 AI 代理的支付系统，专注于结构化数据交易的开放标准”。
55 |
56 |
57 | ## Matter/Thread
58 |
59 | Matter/Thread 是什么？
60 | Matter 是由连接标准联盟（CSA）推出的智能家居协议，旨在通过统一的 IP 层应用协议（基于以太网、Wi-Fi、Thread 等网络）实现跨品牌设备的互操作性。其核心特点包括端到端加密、设备认证、标准化数据模型，以及通过密码或二维码简化设备配网流程911。
61 | Thread 则是专为物联网设计的低功耗、安全的 IPv6 网状网络协议，支持自愈网络拓扑和低延迟通信，常用于连接传感器、开关等设备，并与 Matter 结合作为其底层传输层46。
62 |
63 | 两者共同构成了智能家居的 本地化安全通信框架，强调设备身份验证、端到端加密，并通过边界路由器（如 Thread 边界路由器）实现跨网络（Wi-Fi 与 Thread）的无缝协作69。
64 |
65 | Agent Network Protocol 可借鉴的核心经验
66 | Agent Network Protocol（ANP） 是一种对标 Anthropic MCP 的协议，旨在通过 去中心化身份（DID） 和自然语言协商实现智能体间的安全协作。从 Matter/Thread 中，ANP 可借鉴以下关键点：
67 |
68 | 1. 身份验证与安全机制
69 | 设备身份绑定：Matter 要求每个设备在加入网络前必须通过 证书认证（如制造商证书）和用户授权（如扫码配网），确保设备合法性11。ANP 可借鉴此流程，通过 W3C DID 实现更灵活的去中心化身份绑定，例如将 DID 文档与设备密钥结合，替代传统证书2。
70 |
71 | 端到端加密：Thread 使用 AES-128 加密通信，而 Matter 通过 TLS 保护数据传输。ANP 的 DID 架构已支持基于 ECDHE 的端到端加密，可进一步参考 Matter/Thread 的分层密钥管理（如临时会话密钥）211。
72 |
73 | 2. 调试与用户交互设计
74 | 简化配网流程：Matter 通过 二维码扫描 或 设备密码 实现安全配网，用户无需复杂操作即可完成设备绑定811。ANP 可结合 DID 的轻量级验证机制（如 DID 解析服务），设计类似的用户友好流程，例如通过自然语言指令生成配网二维码2。
75 |
76 | 权限分级控制：Matter 允许通过 OAuth 范围限制设备权限（如仅读写特定资源）。ANP 可扩展此思路，利用 DID 文档中的权限声明（如可验证凭证）动态分配智能体访问权限211。
77 |
78 | 3. 网络架构与协议分层
79 | 跨网络协作：Thread 边界路由器通过 服务注册协议（SRP） 和 DNS-SD 实现 Thread 与 Wi-Fi 设备的服务发现6。ANP 的元协议层（自然语言协商协议）可参考此设计，支持智能体在不同网络环境（如区块链与中心化服务）间动态协商通信规则2。
80 |
81 | 本地化与去中心化：Matter 强调本地端到端通信，减少对云的依赖。ANP 的 DID 架构天然支持去中心化，可结合 Matter/Thread 的本地网络优化，降低通信延迟并提升隐私性29。
82 |
83 | 4. 安全性增强
84 | 防中间人攻击：Thread 要求设备加入网络时通过 预共享密钥（PSK） 验证，而 Matter 使用设备认证证书。ANP 的 DID 可提供更灵活的验证方式（如基于区块链的分布式身份），避免单点失效风险411。
85 |
86 | 固件安全更新：Matter 要求固件更新必须通过签名验证，ANP 可引入 DID 文档中的公钥管理机制，确保智能体代码更新的可信来源11。
87 |
88 | 差异与互补性
89 | 身份模型：Matter/Thread 依赖中心化证书颁发机构（CA），而 ANP 的 DID 是完全去中心化的，更适合开放的多智能体环境211。
90 |
91 | 协议灵活性：Matter 的通信协议（如 UDP/TCP）固定，而 ANP 的元协议层允许智能体通过自然语言动态生成协议，适应性更强2。
92 |
93 | 适用场景：Matter/Thread 聚焦智能家居，ANP 则面向更广泛的智能体网络（如金融、医疗），需平衡安全性与计算开销。
94 |
95 | 总结
96 | Matter/Thread 为 ANP 提供了成熟的 身份验证框架、安全通信实践 和 用户交互设计 参考，而 ANP 可通过 DID 和元协议进一步实现 去中心化 和 动态协商能力。两者的结合可能推动智能体网络在安全性、互操作性和用户体验上的突破。
97 |
98 |
99 |
--------------------------------------------------------------------------------
/chinese/相关产品与技术/相关标准.md:
--------------------------------------------------------------------------------
1 | # 相关标准
2 |
3 | IETF
4 |
5 | https://datatracker.ietf.org/doc/draft-rosenberg-ai-protocols/
6 |
7 |
8 |
9 |
10 |
--------------------------------------------------------------------------------
/docs/chinese/ANP示例程序.md:
--------------------------------------------------------------------------------
1 | # 示例程序清单 / Demo list
2 |
3 | [English](#english) | [中文](#chinese)
4 |
5 |
6 | ## [目录]
7 |
8 | - [X] 示例程序 1：[ANP网络探索工具](#demo1)
9 | - [X] 示例程序 2：[ANP天气智能体服务-服务端](#demo2)
10 | - [ ] 示例程序 3：
11 |
12 |
13 | ## 示例程序 1：ANP网络探索工具
14 | ### 简介
15 |
16 | 本示例程序展示了 ANP 协议在天气查询场景下的应用。通过自然语言驱动 Agent，用户能够轻松查询天气信息，体验未来科技带来的便捷交互。
17 |
18 | ### 展示要点
19 |
20 | 自然语言交互：用户可以使用自然语言与 Agent 进行沟通，无需复杂的指令输入。
21 |
22 | 透明查询过程：程序透明展示查询过程及 Agent 访问记录，让用户清晰了解信息获取途径。
23 |
24 | 便捷访问方式：提供网页直接访问和本地代码运行两种方式，满足不同用户的需求。
25 |
26 | ### 链接地址
27 |
28 | 网页访问地址：https://service.agent-network-protocol.com/anp-demo/
29 |
30 | 代码仓库地址：https://github.com/agent-network-protocol/anp-examples
31 |
32 |
33 | ## 示例程序 2：ANP天气智能体服务-服务端
34 | ### 简介
35 |
36 | 本示例程序展示了 ANP天气智能体服务中的服务端应用。通过集成第三方天气查询API接口，能够被demo1中的ANP网络探索工具发现，并为其提供查询天气信息服务。DEMO1与DEMO2的关系参见下图所示。
37 |
38 | 
39 |
40 | ### 展示要点
41 |
42 | 集成第三方API ：服务端集成了第三方天气查询API接口，能够提供实时的天气信息查询服务。
43 |
44 | 与客户端协同工作 ：服务端能够被 ANP网络探索工具 （客户端）发现，并为其提供查询天气信息服务。
45 |
46 | 灵活部署方式 ：服务端支持多种部署方式，包括本地运行和云服务器部署，满足不同场景的需求。
47 |
48 | ### 链接地址
49 |
50 | 网页访问地址：https://agent-weather.xyz/ad.json
51 |
52 | 代码仓库地址：https://github.com/agent-network-protocol/anp-weather-agent
53 |
54 | # 更多DEMO敬请期待...
55 |
56 |
57 | ## [Catalog]
58 |
59 | - [X] DEMO 1：[ANP Network Exploration Tool](#demo1-en)
60 | - [X] DEMO 2：[ANP Weather Agent Service - Server](#demo2-en)
61 | - [ ] DEMO 3：
62 |
63 |
64 | ## DEMO 1：ANP Network Exploration Tool
65 | ### Overview
66 |
67 | This example program demonstrates the application of ANP protocol in weather query scenarios. Through natural language driven agents, users can easily query weather information and experience the convenient interaction brought by future technology.
68 |
69 | ### Feature
70 |
71 | Natural language interaction: Users can communicate with agents using natural language without the need for complex command inputs.
72 |
73 | Transparent query process: The program transparently displays the query process and Agent access records, allowing users to clearly understand the ways to obtain information.
74 |
75 | Convenient access method: Provides two ways to access web pages directly and run local code to meet the needs of different users.
76 |
77 | ### Link address
78 |
79 | Web page access address : https://service.agent-network-protocol.com/anp-demo/
80 |
81 | Github address : https://github.com/agent-network-protocol/anp-examples
82 |
83 |
84 | ## DEMO 2：ANP Weather Agent Service - Server
85 | ### Overview
86 |
87 | This example program demonstrates the server-side application of ANP weather intelligent agent service.
88 |
89 | By integrating a third-party weather query API interface, it can be discovered by the ANP network exploration tool in demo1 and provided with weather information query services.
90 |
91 | The relationship between DEMO1 and DEMO2 is shown in the following figure.
92 |
93 | 
94 |
95 | ### Feature
96 |
97 | Integrated third-party API: The server integrates a third-party weather query API interface, which can provide real-time weather information query services.
98 |
99 | Collaborate with the client: The server can be discovered by the ANP network exploration tool (client) and provide weather information query services for it.
100 |
101 | Flexible deployment method: The server supports multiple deployment methods, including local operation and cloud server deployment, to meet the needs of different scenarios.
102 |
103 | ### Link address
104 |
105 | Web page access address : https://agent-weather.xyz/ad.json
106 |
107 | Github address : https://github.com/agent-network-protocol/anp-weather-agent
108 |
109 | # Stay tuned for more demos...
110 |
--------------------------------------------------------------------------------
/docs/chinese/links.md:
--------------------------------------------------------------------------------
1 | # 扩展阅读
2 |
3 | 为方便检索，这里按照 **规范 / 白皮书 / 博客 / 生态** 划分了所有 ANP 相关资料。
4 |
5 | ## 规范 (Specifications)
6 |
7 | - [ANP 入门指南](docs/chinese/ANP入门指南.md)
8 | - [did:wba 身份方案](chinese/03-did-wba方法规范.md)
9 | - [基于 DID 的端到端加密通信](chinese/message/04-基于did的端到端加密通信技术协议.md)
10 | - [基于 DID 的消息服务协议](chinese/message/05-基于did的消息服务协议.md)
11 | - [元协议设计规范](chinese/06-ANP-智能体通信元协议规范.md)
12 | - [智能体描述协议规范（Draft）](chinese/07-ANP-智能体描述协议规范.md)
13 | - [智能体发现协议规范（Draft）](chinese/08-ANP-智能体发现协议规范.md)
14 |
15 | ## 白皮书 (Whitepaper)
16 |
17 | - [AgentNetworkProtocol 技术白皮书](chinese/01-AgentNetworkProtocol技术白皮书.md)
18 |
19 | ## 博客 (Blogs)
20 |
21 | - [智能体互联网有什么不同](blogs/cn/智能体互联网有什么不同.md)
22 | - [did:wba-基于web的去中心化身份标识符](blogs/did-wba-基于web的去中心化身份标识符.md)
23 | - [MCP 与 ANP 对比：智能体需要什么样的通信协议](blogs/cn/MCP与ANP对比：智能体需要什么样的通信协议.md)
24 | - [did:wba 对比 OpenID Connect、API keys](blogs/cn/did-wba对比openid-connect、api-keys.md)
25 | - [did:wba 安全性原理解析](blogs/cn/did-wba安全性原理解析.md)
26 | - [从 OpenAI 的 Operator，看 AI 与互联网交互的三种技术路线](blogs/cn/从OpenAI的Operator，看AI与互联网交互的三种技术路线.md)
27 | - [智能体身份的三个关键问题：互操作性、人类授权和隐私保护](blogs/three-key-issues-of-agent-identity-interoperability-human-authorization-and-privacy-protection.md)
28 | - [AI 个人助手未来产品形态和主要玩家的分析与预测](blogs/cn/AI个人助手未来产品形态和主要玩家的分析与预测.md)
29 | - [一个提示词一个 HTTP 函数：让开源 Manus 通过 ANP 与其他智能体交互](blogs/cn/一个提示词一个HTTP函数：让开源Manus通过ANP与其他智能体交互.md)
30 | - [LangGraph 负责人对 MCP 的挑战，ANP 是怎么解决的？](blogs/cn/LangGraph负责人对MCP的挑战，ANP是怎么解决的？.md)
31 | - [ANP 协议要感谢的社区：web3、Agora、WebAgents](blogs/cn/ANP协议要感谢的社区：web3、Agora、WebAgents.md)
32 | - [智能体通信协议对比](blogs/cn/智能体通信协议对比.md)
33 | - [但我们设计一个协议的时候，我们在设计什么](blogs/cn/但我们设计一个协议的时候，我们在设计什么.md)
34 | - [关于智能体身份的三个关键问题：互联互通、人类授权、隐私保护](blogs/cn/关于智能体身份的三个关键问题：互联互通、人类授权、隐私保护.md)
35 | - [Anthropic MCP 2025H1 里程碑解读](blogs/cn/anthropic-mcp-2025h1-里程碑解读.md)
36 | - [ANP 在 W3C-WebAgents-CG 的演讲](blogs/cn/ANP在W3C-WebAgents-CG的演讲.md)
37 | - [第一个专为 AI 访问而设计的 WebAgent 诞生了](blogs/cn/第一个专为AI访问而设计的WebAgent诞生了.md)
38 | - [Agent 对 Infra 的改变：对连接基础设施的改变](blogs/cn/agent对infra的改变-对连接基础设施的改变.md)
39 | - [多角度全面对比 Google 最新的 A2A、ANP、MCP](blogs/cn/多角度全面对比Google最新的A2A、ANP、MCP.md)
40 | - [深入对比谷歌 A2A 与 ANP：找到协议的原点](blogs/cn/深入对比谷歌A2A与ANP：找到协议的原点.md)
41 | - [深入对比 MCP、A2A、ANP 的交互模式：信息组织方式的差异](blogs/cn/深入对比MCP、A2A、ANP的交互模式.md)
42 |
43 | ## 生态 (Ecosystem)
44 |
45 | - [AgentConnect 开源实现](https://github.com/agent-network-protocol/AgentConnect)
46 |
--------------------------------------------------------------------------------
/docs/chinese/roadmap/roadmap-and-todo-202504.md:
--------------------------------------------------------------------------------
1 | # ANP Roadmap and Todo (2025-04)
2 |
3 | ## 当下最重要的事情
4 |
5 | - [x] 增加协议仓库新手入门文档
6 | - [ ] 增加协议SDK仓库的代码使用入门文档、示例
7 | - [ ] 增加演示demo，展示多人、多供应商通过ANP进行日程安排的demo。
8 | - [ ] 完善白皮书：根据最新的技术进展，设计理念，更新白皮书内容，能够让人通过白皮书对ANP有更清晰、更整体的认识。
9 |
10 | ## 协议完善
11 |
12 | ### 智能体身份
13 |
14 | - [ ] 确定智能体身份的权责边界，比如用户与智能体提供者之间的权责边界，用户智能体与服务智能体之间的权责边界。整体上遵循“请求即授权、签名即凭证”的原则。
15 | - [ ] 确定身份隐私保护的几个问题：子DID生命周期如何管理，如果销毁，如何处理后面的售后问题？
16 | - [ ] 如何验证用户的身份信息，比如是否成年，学历是否符合要求等。这种流程如何设计？（可能用到W3C的可验证凭证规范）
17 |
18 | ### 智能体描述
19 |
20 | - [ ] 智能体描述新增JSON-LD字段的定义描述，上线相关的字段的web页面。
21 | - [ ] 完善双向交互：智能体A发送请求给智能体B，智能体B如何异步的发送响应。
22 | - [ ] 考虑与其他协议的兼容方案，比如json-rpc、websocket、wot、音视频协议等。
23 | - [ ] 智能体描述文档是否需要身份认证（如果需要的话，可能会冲突，特别是有多重身份认证方案的时候）
24 | - [ ] 如何在智能体描述文档中，支持多种身份认证方式
25 |
26 | ### 智能体支付
27 |
28 | - [ ] 智能体之间如何进行支付操作？如何与现有的支付平台，比如支付宝、微信，或者国际支付渠道对接？同时确保支付的安全？
29 | - [ ] 如何保存交易的凭证？是否保存到三方智能体服务上，用于公证、售后处理依据？
30 |
31 | ### 智能体应用协议管理
32 |
33 | - [ ] 可以通过URI，确定一个API。比如，在智能体描述中通过URI作为API的id，这个时候，模型可以不用下载API描述文档，而是根据预训练的数据，直接发起对这个API的调用。
34 | - [ ] 对于预先定义的协议或API，如何保存在在云端，保存在哪里，如何访问？
35 | - [ ] 预先定义的API对应的代码如何生成、如何下载，如何确保代码的安全？
36 | - [ ] 如何生存预定义的API？是否允许两个智能体自己协商生成并且上传？如何激励他们这样做？
37 |
38 | ### 智能体端到端加密
39 |
40 | - [ ] 修改现有的端到端加密方案，基于did:wba重新实现（改动不大）
41 | - [ ] 整理文档，说明端到端加密的使用场景：用于反向代理，即智能体注册到托管平台，托管平台为这个智能体开放一个对外服务端点。这个使用要用到端到端加密，防止托管平台获取智能体之间的通信内容。
42 | - [ ] 在反向代理的模式下，如何进行智能体描述、API的请求等操作？
43 |
44 | ## ANP开源软件完善
45 |
46 | ### Agent Connect
47 |
48 | - [ ] 完善SDK代码使用示例：现在有很多示例属于老的did:all，需要更新
49 | - [ ] 完善Agent Connect：生成的did文档，包含对整体文档的签名字段，增强安全性
50 | - [ ] 代码使用ruff进行代码检查，代码格式化
51 |
52 | ### ANP Server
53 |
54 | - [ ] 实现一个开源的ANP server，包括ANP的核心功能，包括did 管理、智能体描述、智能体发现、智能体的client等核心模块。基于ANP server可以方便的构建支持ANP的智能体
55 |
56 | ### ANP Command Line Tool
57 |
58 | - [ ] 完善ANP命令行工具：生成DID、私钥、DID文档
59 | - [ ] 完善ANP命令行工具：调用模型，根据描述文档或数据，生成符合规范的json-ld数据。
60 |
61 | ### 测试工具
62 |
63 | - [ ] 完善ANP测试工具：作为发起方，验证接收方的ANP协议是否正常
64 | - [ ] 完善ANP测试工具：作为接收方，验证发起方的ANP协议是否正常
65 |
66 | ## 推广
67 |
68 | - [ ] 在主流开源智能体框架中，集成ANP SDK
69 | - [ ] 在实际项目中推动ANP的落地
70 |
71 | ## 社区运营
72 |
73 | - [ ] 定期举行社区开发者会议，建立和开发者之间的紧密联系
74 | - [ ] 完善社区运营框架与细则，包括起步阶段，发展阶段，成熟阶段
75 | - [ ] 吸引更多的力量加入开源社区
76 | - [ ] 加入一个开源基金会
77 |
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 |
--------------------------------------------------------------------------------
/docs/did-wba入门指南.md:
--------------------------------------------------------------------------------
1 | # DID:WBA 入门指南
2 |
3 | ## 什么是 DID？
4 |
5 | DID（去中心化标识符，Decentralized Identifier）是一种新型的标识符，用于可验证的"自我主权"数字身份。与传统的中心化标识符不同，DID 完全由标识符的主体控制，独立于任何中心化注册表、身份提供商或证书颁发机构。
6 |
7 | DID 具有以下关键特性：
8 |
9 | - **持久性**：只要底层系统存在，标识符就可以持久存在
10 | - **加密可验证**：使用密码学证明控制权
11 | - **可解析**：通过 DID 可以发现更多信息
12 | - **自我主权**：由标识符主体自行控制
13 |
14 | ## DID:WBA 简介
15 |
16 | did:wba（Web-Based Agent）是一种基于 Web 的去中心化标识符方法，特别为满足跨平台身份认证和智能体通信的需求而设计。它在 did:web 基础上进行了扩展和优化，保留了兼容性的同时增强了针对智能体场景的适配性。
17 |
18 | did:wba 的设计原则是既充分利用现有的成熟技术和完善的 Web 基础设施，又实现去中心化。它实现了类似 email 的特点，各个平台可以以中心化的方式实现自己的账户体系，同时各平台之间可以互联互通。
19 |
20 | ## DID:WBA 的格式
21 |
22 | did:wba 的格式如下：
23 |
24 | ```
25 | did:wba:[:]
26 | ```
27 |
28 | 其中：
29 | - `did:wba` 是固定前缀
30 | - `` 是域名，需由 TLS/SSL 证书保护
31 | - `[:]` 是可选的路径部分，使用冒号（:）作为分隔符
32 |
33 | 示例：
34 | - `did:wba:example.com` - 基本形式
35 | - `did:wba:example.com:user:alice` - 带路径
36 | - `did:wba:example.com%3A3000:user:alice` - 带端口（注意端口冒号需编码为 %3A）
37 |
38 | ## 如何使用 DID:WBA
39 |
40 | ### 创建 DID:WBA
41 |
42 | 创建 did:wba 标识符需要以下步骤：
43 |
44 | 1. **获取域名**：向域名注册商申请使用域名
45 | 2. **配置 DNS**：在 DNS 查询服务中存储托管服务的位置和 IP 地址
46 | 3. **创建 DID 文档**：创建符合规范的 DID 文档 JSON-LD 文件，包含验证方法和必要的密钥对
47 | 4. **发布 DID 文档**：将 DID 文档放置在正确的位置
48 |
49 | DID 文档的存放位置取决于 DID 的形式：
50 | - 对于 `did:wba:example.com`，DID 文档应位于 `https://example.com/.well-known/did.json`
51 | - 对于 `did:wba:example.com:user:alice`，DID 文档应位于 `https://example.com/user/alice/did.json`
52 | - 对于 `did:wba:example.com%3A3000:user:alice`，DID 文档应位于 `https://example.com:3000/user/alice/did.json`
53 |
54 | ### DID 文档结构
55 |
56 | 一个基本的 did:wba 文档应包含以下核心元素：
57 |
58 | ```json
59 | {
60 | "@context": [
61 | "https://www.w3.org/ns/did/v1",
62 | "https://w3id.org/security/suites/jws-2020/v1",
63 | "https://w3id.org/security/suites/secp256k1-2019/v1"
64 | ],
65 | "id": "did:wba:example.com:user:alice",
66 | "verificationMethod": [
67 | {
68 | "id": "did:wba:example.com:user:alice#key-1",
69 | "type": "EcdsaSecp256k1VerificationKey2019",
70 | "controller": "did:wba:example.com:user:alice",
71 | "publicKeyJwk": {
72 | "crv": "secp256k1",
73 | "x": "..."
74 | "y": "...",
75 | "kty": "EC",
76 | "kid": "..."
77 | }
78 | }
79 | ],
80 | "authentication": [
81 | "did:wba:example.com:user:alice#key-1"
82 | ]
83 | }
84 | ```
85 |
86 | 重要字段说明：
87 | - **@context**：必须字段，定义 DID 文档的语义
88 | - **id**：必须字段，DID 标识符
89 | - **verificationMethod**：必须字段，包含验证方法的数组
90 | - **authentication**：必须字段，用于身份验证的验证方法列表
91 |
92 | 可选字段：
93 | - **keyAgreement**：用于密钥协商的公钥信息
94 | - **humanAuthorization**：用于人类授权的公钥信息
95 | - **service**：与 DID 关联的服务列表，如智能体描述服务
96 |
97 | ### 解析 DID:WBA
98 |
99 | 解析 did:wba 文档的步骤：
100 |
101 | 1. 将方法特定标识符中的 ":" 替换为 "/" 获得域名和路径
102 | 2. 如果包含端口，对冒号进行百分比解码
103 | 3. 添加 "https://" 前缀
104 | 4. 如果未指定路径，附加 "/.well-known"
105 | 5. 附加 "/did.json" 完成 URL
106 | 6. 执行 HTTP GET 请求获取 DID 文档
107 | 7. 验证文档中的 ID 是否与请求的 DID 匹配
108 |
109 | ## 基于 DID:WBA 的跨平台身份认证
110 |
111 | did:wba 提供了一个基于 HTTP 协议的流程，使服务端能够快速验证来自其他平台客户端的身份。
112 |
113 | 认证流程：
114 |
115 | 1. **初始请求**：客户端在 HTTP 请求头中携带 DID 和签名
116 | ```
117 | Authorization: DIDWba did="did:wba:example.com:user:alice", nonce="abc123", timestamp="2024-12-05T12:34:56Z", verification_method="key-1", signature="..."
118 | ```
119 |
120 | 2. **服务端验证**：
121 | - 验证时间戳是否在合理范围内
122 | - 验证 nonce 是否已被使用
123 | - 验证 DID 权限
124 | - 获取 DID 文档并验证签名
125 |
126 | 3. **签名验证过程**：
127 | - 服务端根据请求信息构建验证字符串
128 | - 使用 JCS 规范化字符串
129 | - 使用 SHA-256 算法生成哈希值
130 | - 根据 DID 文档获取公钥
131 | - 验证签名是否有效
132 |
133 | 4. **认证成功返回 access_token**：
134 | - 验证成功后返回 JWT 格式的 access_token
135 | - 客户端后续请求使用此 token
136 |
137 | ## 后续学习
138 |
139 | 要深入了解 did:wba，建议查阅以下资源：
140 |
141 | 1. [ANP 项目主页](https://github.com/agent-network-protocol/AgentNetworkProtocol)
142 | 2. [did:wba 方法规范](https://agent-network-protocol.com/chinese/03-did:wba方法规范.html)
143 | 3. [W3C DID 核心规范](https://www.w3.org/TR/did-core/)
144 | 4. [ANP 智能体描述协议规范](https://agent-network-protocol.com/chinese/07-ANP-智能体描述协议规范.html)
145 |
146 | ## 小结
147 |
148 | did:wba 提供了一种基于 Web 的去中心化标识方案，特别适合智能体通信场景。它结合了中心化系统的便捷性和去中心化系统的互操作性，为智能体网络提供了可靠的身份标识和验证机制。通过 did:wba，不同平台的智能体可以安全地建立互信，实现跨平台通信和协作。
149 |
--------------------------------------------------------------------------------
/docs/links.md:
--------------------------------------------------------------------------------
1 | # Further Reading
2 |
3 | For ease of reference, all ANP-related materials are organized by **Specifications / Whitepaper / Blogs / Ecosystem**.
4 |
5 | ## Specifications
6 |
7 | - [ANP Getting Started Guide](anp-getting-started-guide.md)
8 | - [did:wba Method Specification](03-did-wba-method-design-specification.md)
9 | - [DID-based End-to-End Encrypted Communication](/message/04-end-to-end-encrypted-communication-technology-protocol-based-on-did.md)
10 | - [Message Service Protocol Based on DID](/message/05-message-service-protocol-based-on-did.md)
11 | - [Meta-Protocol Design Specification](/06-anp-agent-communication-meta-protocol-specification.md)
12 | - [Agent Description Protocol Specification (Draft)](/07-anp-agent-description-protocol-specification.md)
13 | - [Agent Discovery Protocol Specification (Draft)](/08-anp-agent-discovery-protocol-specification.md)
14 |
15 | ## Whitepaper
16 |
17 | - [AgentNetworkProtocol Technical White Paper](/01-agentnetworkprotocol-technical-white-paper.md)
18 |
19 |
20 | ## Blogs
21 |
22 | - [What's Different About the Agentic Web](/blogs/What-Makes-Agentic-Web-Different.md)
23 | - [did:wba - Web-Based Decentralized Identifiers](/blogs/did-wba-a-web-based-decentralized-identifier.md)
24 | - [Comparison of MCP and ANP: What Kind of Communication Protocol Do Agents Need](/blogs/Comparison-of-MCP-and-ANP-What-Kind-of-Communication-Protocol-Do-Agents-Need.md)
25 | - [Comparison of did:wba with OpenID Connect and API keys](/blogs/comparison-of-did-wba-with-openid-connect-and-api-keys.md)
26 | - [Security Principles of did:wba](/blogs/did-wba-security-principles.md)
27 | - [Three Technical Approaches to AI-Internet Interaction](/blogs/Three_Technical_Approaches_to_AI_Internet_Interaction.md)
28 | - [Three Key Issues of Agent Identity: Interoperability, Human-Authorization, and Privacy Protection](/blogs/three-key-issues-of-agent-identity-interoperability-human-authorization-and-privacy-protection.md)
29 | - [Analysis and Predictions of Future AI Personal Assistant Products and Key Players](/blogs/analysis-and-predictions-of-future-ai-personal-assistant-products-and-key-players.md)
30 | - [One Prompt, One HTTP Function: Enabling Open-Source Manus to Interact with Other Agents via ANP](/blogs/One-Prompt-One-HTTP-Function-Enabling-Open-Source-Manus-to-Interact-with-Other-Agents-via-ANP.md)
31 | - [Challenges to MCP from LangGraph Lead and How ANP Addresses Them](/blogs/Challenges-to-MCP-from-LangGraph-Lead-and-How-ANP-Addresses-Them.md)
32 | - [In the Year that the ANP was Born](/blogs/In-the-year-that-the-ANP-was-born.md)
33 | - [Comparison of Agent Communication Protocols](/blogs/Comparison-of-Agent-Communication-Protocols.md)
34 | - [When We Design a Protocol, What Are We Designing](/blogs/When-We-Design-a-Protocol-What-Are-We-Designing.md)
35 | - [Anthropic MCP 2025H1 Milestone Analysis](/blogs/anthropic-mcp-2025h1-milestone-analysis.md)
36 | - [ANP Presentation at W3C WebAgents CG](/blogs/ANP-Presentation-at-W3C-WebAgents-CG.md)
37 | - [The Birth of the First WebAgent Designed for AI Access](/blogs/The-Birth-of-the-First-WebAgent-Designed-for-AI-Access.md)
38 | - [Agent's Impact on Infrastructure: Challenges to Existing Connection Infrastructure](/blogs/Agent-Impact-on-Infrastructure-Challenges-to-Existing-Connection-Infrastructure.md)
39 | - [Comprehensive Comparison of Google's Latest A2A, ANP, and MCP](/blogs/Comprehensive-Comparison-of-Google-A2A-ANP-MCP.md)
40 | - [In-depth Comparison of Google A2A and ANP: Finding the Origin of Protocols](/blogs/In-depth-Comparison-of-Google-A2A-and-ANP-Finding-the-Origin-of-Protocols.md)
41 | - [Deep Comparison of MCP, A2A, and ANP Interaction Modes: Differences in Information Organization](/blogs/Comparing-the-Interaction-Modes-of-MCP-A2A-and-ANP.md)
42 | - [ANP Community First Meeting: A Milestone for the Agentic Web](/blogs/ANP-Community-First-Meeting-A-Milestone-for-the-Agentic-Web.md)
43 |
44 | ## Ecosystem
45 |
46 | - [AgentConnect Open-Source Implementation](https://github.com/agent-network-protocol/AgentConnect)
47 |
--------------------------------------------------------------------------------
/examples/adp/hotel/examples/ad.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "did": "https://w3id.org/did#",
5 | "ad": "https://service.agent-network-protocol.com/ad#"
6 | },
7 | "@type": "ad:AgentDescription",
8 | "@id": "https://service.agent-network-protocol.com/agents/sheraton-chuzhou-hotel/ad.json",
9 | "name": "Hotel Booking Agent",
10 | "did": "did:wba:service.agent-network-protocol.com:wba:hotel",
11 | "owner": {
12 | "@type": "Organization",
13 | "name": "Hotel Chain Group",
14 | "@id": "https://example-hotel-group.com"
15 | },
16 | "description": "An intelligent hotel booking agent providing comprehensive hotel information, room availability, and booking services.",
17 | "version": "1.0.0",
18 | "created": "2025-01-29T09:08:44Z",
19 | "ad:securityDefinitions": {
20 | "didwba_sc": {
21 | "scheme": "didwba",
22 | "in": "header",
23 | "name": "Authorization"
24 | }
25 | },
26 | "ad:security": "didwba_sc",
27 | "ad:domainEntity": {
28 | "@type": "Hotel",
29 | "hotelID": 372505161,
30 | "name": "滁州港汇喜来登酒店",
31 | "description": "滁州港汇喜来登酒店是喜达屋酒店及度假村国际集团旗下的喜来登品牌在滁州市的一家酒店。酒店位于滁州政治、商业和文化中心，毗邻滁州市政府，距离滁州高铁站仅5公里，距离南京也仅40分钟车程。",
32 | "@id": "https://service.agent-network-protocol.com/agents/hotel/sheraton-chuzhou-hotel/hotel.json",
33 | "address": {
34 | "@type": "PostalAddress",
35 | "streetAddress": "中都大道1599号",
36 | "addressLocality": "滁州",
37 | "addressRegion": "安徽省",
38 | "addressCountry": "CN"
39 | },
40 | "telephone": "0550-2201888",
41 | "openingDate": "2015",
42 | "starRating": {
43 | "@type": "Rating",
44 | "ratingValue": 5,
45 | "alternateName": "豪华型",
46 | "isRelatedTo": true
47 | },
48 | "geo": {
49 | "@type": "GeoCoordinates",
50 | "latitude": 32.242098,
51 | "longitude": 118.332009
52 | },
53 | "image": [
54 | {
55 | "@type": "ImageObject",
56 | "url": "http://m.tuniucdn.com/fb3/s1/2n9c/Y3cwy3rmCHMeDe7U1ZKfaeFcNuk.jpg",
57 | "caption": "滁州港汇喜来登酒店 - 行政套房",
58 | "description": "豪华行政套房配备高档家具和设施，为商务和休闲旅客提供舒适优雅的住宿体验"
59 | },
60 | {
61 | "@type": "ImageObject",
62 | "url": "http://m.tuniucdn.com/fb3/s1/2n9c/6oebPwjLLWWmPt2dVRBPcKXEpVb.jpg",
63 | "caption": "滁州港汇喜来登酒店 - 豪华客房",
64 | "description": "宽敞明亮的豪华客房，配备现代化设施，为宾客提供舒适的入住体验"
65 | },
66 | {
67 | "@type": "ImageObject",
68 | "url": "http://m.tuniucdn.com/fb3/s1/2n9c/3dYduEb8VMQzTfaaJiDA3S4kyt5y.jpg",
69 | "caption": "滁州港汇喜来登酒店 - 行政酒廊",
70 | "description": "位于酒店高层的行政酒廊，为行政楼层客人提供专属休息和商务空间"
71 | }
72 | ],
73 | "amenityFeature": [
74 | {
75 | "@type": "LocationFeatureSpecification",
76 | "name": "残疾人客房",
77 | "value": true
78 | },
79 | {
80 | "@type": "LocationFeatureSpecification",
81 | "name": "大堂吧",
82 | "value": true
83 | },
84 | {
85 | "@type": "LocationFeatureSpecification",
86 | "name": "行政楼层",
87 | "value": true
88 | },
89 | {
90 | "@type": "LocationFeatureSpecification",
91 | "name": "健身室",
92 | "value": true
93 | },
94 | {
95 | "@type": "LocationFeatureSpecification",
96 | "name": "自动取款机",
97 | "value": true
98 | },
99 | {
100 | "@type": "LocationFeatureSpecification",
101 | "name": "餐厅",
102 | "value": true
103 | }
104 | ],
105 | "makesOffer": [
106 | {
107 | "@type": "Offer",
108 | "itemOffered": {
109 | "@type": "Service",
110 | "name": "24小时前台服务"
111 | }
112 | },
113 | {
114 | "@type": "Offer",
115 | "itemOffered": {
116 | "@type": "Service",
117 | "name": "商务服务"
118 | }
119 | },
120 | {
121 | "@type": "Offer",
122 | "itemOffered": {
123 | "@type": "Service",
124 | "name": "邮政服务"
125 | }
126 | },
127 | {
128 | "@type": "Offer",
129 | "itemOffered": {
130 | "@type": "Service",
131 | "name": "快速办理入住/退房手续"
132 | }
133 | }
134 | ]
135 | },
136 | "ad:interfaces": [
137 | {
138 | "@type": "ad:SearchInterface",
139 | "protocol": "YAML",
140 | "url": "https://service.agent-network-protocol.com/agents/sheraton-chuzhou-hotel/api/search-interface.yaml",
141 | "description": "A YAML file for searching and filtering hotel information, such as room information, price information, etc."
142 | },
143 | {
144 | "@type": "ad:BookingInterface",
145 | "protocol": "YAML",
146 | "url": "https://service.agent-network-protocol.com/agents/sheraton-chuzhou-hotel/api/booking-interface.yaml",
147 | "description": "A YAML file for hotel room booking and reservation management."
148 | },
149 | {
150 | "@type": "ad:NaturalLanguageInterface",
151 | "protocol": "YAML",
152 | "url": "https://service.agent-network-protocol.com/agents/sheraton-chuzhou-hotel/api/nl-interface.yaml",
153 | "description": "A YAML file for interacting with the intelligent agent through natural language."
154 | }
155 | ]
156 | }
157 |
--------------------------------------------------------------------------------
/examples/adp/hotel/examples/api/booking-interface.yaml:
--------------------------------------------------------------------------------
1 | # 购买接口配置
2 | interface:
3 | type: Booking
4 | description: "用于预订指定的商品或服务"
5 | version: "1.0"
6 | endpoints:
7 | - name: "Booking"
8 | description: "预订操作"
9 | method: "POST"
10 | path: "/agents/hotel/api/booking"
11 | parameters:
12 | - name: "identifier"
13 | type: "string"
14 | required: true
15 | description: "指定商品或服务在描述文档中的identifier"
16 |
--------------------------------------------------------------------------------
/examples/adp/hotel/examples/api/nl-interface.yaml:
--------------------------------------------------------------------------------
1 | # 自然语言接口配置
2 | interface:
3 | type: NaturalLanguage
4 | description: "用于通过自然语言与智能代理交互的接口。"
5 | version: "1.0"
6 | endpoints:
7 | - name: "askQuestion"
8 | description: "使用自然语言提问并获取自然语言回答，支持SSE返回。"
9 | method: "POST"
10 | path: "/agents/lkcoffe/api/ask"
11 | parameters:
12 | - name: "question"
13 | type: "string"
14 | required: true
15 | response:
16 | type: "string"
17 | description: "自然语言回答，支持SSE返回。"
18 | sseSupport: true
19 | sseDescription: "此接口支持服务器发送事件（SSE），用于实时自然语言数据流。"
20 |
--------------------------------------------------------------------------------
/examples/adp/hotel/examples/hotel_room.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "ad": "https://service.agent-network-protocol.com/ad#"
5 | },
6 | "@type": "HotelRoom",
7 | "@id": "https://service.agent-network-protocol.com/agents/hotel/examples/hotel_room.json",
8 | "identifier": "room-deluxe-001",
9 | "roomName": "豪华海景房",
10 | "name": "Deluxe Ocean View Room",
11 | "description": "Spacious deluxe room with breathtaking ocean views, featuring modern amenities and elegant design.",
12 | "useableArea": "45 square meters",
13 | "capacity": "3",
14 | "floor": "15-20",
15 | "bedType": "1 King Bed",
16 | "windowType": "Floor-to-ceiling windows",
17 | "image": [
18 | {
19 | "@type": "ImageObject",
20 | "url": "https://service.agent-network-protocol.com/agents/hotel/examples/deluxe-room-1.jpg",
21 | "caption": "豪华海景房 - 全景",
22 | "description": "Luxurious room featuring floor-to-ceiling windows with panoramic ocean views"
23 | },
24 | {
25 | "@type": "ImageObject",
26 | "url": "https://service.agent-network-protocol.com/agents/hotel/examples/deluxe-room-2.jpg",
27 | "caption": "豪华海景房 - 卧室",
28 | "description": "Bedroom with king-size bed and premium bedding"
29 | }
30 | ],
31 | "facilities": [
32 | {
33 | "@type": "LocationFeatureSpecification",
34 | "name": "空调",
35 | "value": true
36 | },
37 | {
38 | "@type": "LocationFeatureSpecification",
39 | "name": "独立卫浴",
40 | "value": true
41 | },
42 | {
43 | "@type": "LocationFeatureSpecification",
44 | "name": "Mini吧",
45 | "value": true
46 | }
47 | ],
48 | "offers": [
49 | {
50 | "@type": "Offer",
51 | "identifier": "RP20250204001",
52 | "name": "标准价",
53 | "priceSpecification": {
54 | "@type": "UnitPriceSpecification",
55 | "price": 1280.00,
56 | "priceCurrency": "CNY",
57 | "unitCode": "DAY",
58 | "priceType": "https://schema.org/InvoicePrice",
59 | "valueAddedTaxIncluded": true
60 | },
61 | "pricePerDay": [1280, 1280, 1280],
62 | "stockPerDay": [5, 4, 3],
63 | "paymentMethod": {
64 | "@type": "PaymentMethod",
65 | "name": "Prepayment required"
66 | },
67 | "instantConfirmation": true,
68 | "addOn": {
69 | "@type": "Offer",
70 | "name": "Breakfast",
71 | "description": "含2份免费早餐"
72 | },
73 | "priceValidUntil": "2025-12-31",
74 | "eligibleCustomerType": "https://schema.org/Individual",
75 | "availability": "https://schema.org/InStock",
76 | "businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
77 | "seller": {
78 | "@type": "Hotel",
79 | "name": "Sheraton Chuzhou Hotel"
80 | },
81 | "termsOfService": {
82 | "@type": "TermsOfService",
83 | "name": "限时取消",
84 | "cancelationPolicy": {
85 | "@type": "CancellationPolicy",
86 | "refundType": "Full refund",
87 | "description": "入住日18:00前可免费取消",
88 | "validUntil": "2025-02-04T18:00:00Z"
89 | }
90 | }
91 | },
92 | {
93 | "@type": "Offer",
94 | "identifier": "RP20250204002",
95 | "name": "无早价",
96 | "priceSpecification": {
97 | "@type": "UnitPriceSpecification",
98 | "price": 1180.00,
99 | "priceCurrency": "CNY",
100 | "unitCode": "DAY",
101 | "priceType": "https://schema.org/InvoicePrice",
102 | "valueAddedTaxIncluded": true
103 | },
104 | "pricePerDay": [1180, 1180, 1180],
105 | "stockPerDay": [5, 4, 3],
106 | "paymentMethod": {
107 | "@type": "PaymentMethod",
108 | "name": "Prepayment required"
109 | },
110 | "instantConfirmation": true,
111 | "addOn": {
112 | "@type": "Offer",
113 | "name": "Breakfast",
114 | "description": "不含早餐"
115 | },
116 | "priceValidUntil": "2025-12-31",
117 | "eligibleCustomerType": "https://schema.org/Individual",
118 | "availability": "https://schema.org/InStock",
119 | "businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
120 | "seller": {
121 | "@type": "Hotel",
122 | "name": "Sheraton Chuzhou Hotel"
123 | },
124 | "termsOfService": {
125 | "@type": "TermsOfService",
126 | "name": "不可取消",
127 | "cancelationPolicy": {
128 | "@type": "CancellationPolicy",
129 | "refundType": "No refund",
130 | "description": "预订成功后不可变更或取消"
131 | }
132 | }
133 | }
134 | ],
135 | "amenityFeature": [
136 | {
137 | "@type": "LocationFeatureSpecification",
138 | "name": "Room Size",
139 | "value": "45 square meters"
140 | },
141 | {
142 | "@type": "LocationFeatureSpecification",
143 | "name": "View",
144 | "value": "Ocean View"
145 | },
146 | {
147 | "@type": "LocationFeatureSpecification",
148 | "name": "Bathroom",
149 | "value": "En-suite bathroom with separate shower and bathtub"
150 | }
151 | ],
152 | "containedInPlace": {
153 | "@type": "Hotel",
154 | "name": "Sheraton Chuzhou Hotel",
155 | "address": {
156 | "@type": "PostalAddress",
157 | "streetAddress": "No. 299 Qingliu North Road",
158 | "addressLocality": "Chuzhou",
159 | "addressRegion": "Anhui",
160 | "postalCode": "239000",
161 | "addressCountry": "CN"
162 | }
163 | },
164 | "smokingAllowed": false,
165 | "petsAllowed": false
166 | }
167 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/ad.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "did": "https://w3id.org/did#",
5 | "ad": "https://service.agent-network-protocol.com/ad#"
6 | },
7 | "@type": "ad:AgentDescription",
8 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/ad.json",
9 | "name": "Luckin Coffee Agent",
10 | "did": "did:wba:service.agent-network-protocol.com:wba:lkcoffe",
11 | "owner": {
12 | "@type": "Organization",
13 | "name": "Luckin Coffee",
14 | "@id": "https://luckincoffee.com"
15 | },
16 | "description": "Luckin Coffee's intelligent agent providing product information and customization options.",
17 | "version": "1.0.0",
18 | "created": "2025-01-03T10:56:57Z",
19 | "ad:securityDefinitions": {
20 | "didwba_sc": {
21 | "scheme": "didwba",
22 | "in": "header",
23 | "name": "Authorization"
24 | }
25 | },
26 | "ad:security": "didwba_sc",
27 | "ad:domainEntity": {
28 | "@type": "CafeOrCoffeeShop",
29 | "name": "Luckin Coffee",
30 | "address": {
31 | "@type": "PostalAddress",
32 | "streetAddress": "XX Road No.XX",
33 | "addressLocality": "Some City",
34 | "addressRegion": "Some Province",
35 | "postalCode": "123456",
36 | "addressCountry": "CN"
37 | },
38 | "telephone": "+86-10-12345678",
39 | "url": "https://www.starbucks.com",
40 | "openingHours": "Mo-Su 07:00-22:00",
41 | "geo": {
42 | "@type": "GeoCoordinates",
43 | "latitude": 39.9042,
44 | "longitude": 116.4074
45 | },
46 | "ad:products": [
47 | {
48 | "@type": "Product",
49 | "name": "Silk Latte",
50 | "description": "Made with high-quality milk source, providing a silky smooth taste, suitable for consumers pursuing health and taste.",
51 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/silk-latte/silk-latte.json"
52 | },
53 | {
54 | "@type": "Product",
55 | "name": "Orange C Americano",
56 | "description": "Niche fruit aroma paired with rich coffee, suitable for consumers seeking freshness and unique flavors.",
57 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/orange-americano/orange-americano.json"
58 | },
59 | {
60 | "@type": "Product",
61 | "name": "Roasted Coconut Latte",
62 | "description": "Roasted at around 135°C, featuring unique coconut sugar flavor, perfect for winter consumption. This beverage combines coconut juice and roasted coconut bits, offering a healthy choice with five 'zero' features, using master-crafted Espresso from IIAC gold medal coffee beans.",
63 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/roasted-coconut-latte/roasted-coconut-latte.json"
64 | }
65 | ]
66 | },
67 | "ad:interfaces": [
68 | {
69 | "@type": "ad:NaturalLanguageInterface",
70 | "protocol": "YAML",
71 | "url": "https://service.agent-network-protocol.com/agents/lkcoffe/api/nl-interface.yaml",
72 | "description": "A YAML file for interacting with the intelligent agent through natural language."
73 | },
74 | {
75 | "@type": "ad:PurchaseInterface",
76 | "protocol": "YAML",
77 | "url": "https://service.agent-network-protocol.com/agents/lkcoffe/api/purchase-interface.yaml",
78 | "description": "A YAML file for interacting with the intelligent agent through purchase."
79 | }
80 | ]
81 | }
82 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/api/nl-interface.yaml:
--------------------------------------------------------------------------------
1 | # 自然语言接口配置
2 | interface:
3 | type: NaturalLanguage
4 | description: "用于通过自然语言与智能代理交互的接口。"
5 | version: "1.0"
6 | endpoints:
7 | - name: "askQuestion"
8 | description: "使用自然语言提问并获取自然语言回答，支持SSE返回。"
9 | method: "POST"
10 | path: "/agents/lkcoffe/api/ask"
11 | parameters:
12 | - name: "question"
13 | type: "string"
14 | required: true
15 | response:
16 | type: "string"
17 | description: "自然语言回答，支持SSE返回。"
18 | sseSupport: true
19 | sseDescription: "此接口支持服务器发送事件（SSE），用于实时自然语言数据流。"
20 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/api/purchase-interface.yaml:
--------------------------------------------------------------------------------
1 | # 购买接口配置
2 | interface:
3 | type: Purchase
4 | description: "购买指定的商品或服务"
5 | version: "1.0"
6 | endpoints:
7 | - name: "purchase"
8 | description: "购买操作"
9 | method: "POST"
10 | path: "/agents/lkcoffe/api/purchase"
11 | parameters:
12 | - name: "identifier"
13 | type: "string"
14 | required: true
15 | description: "所购买商品或服务在描述文档中的identifier"
16 | - name: "customizationOptions"
17 | type: "object"
18 | required: true
19 | description: "用户选择的商品或服务的自定义选项"
20 | additionalProperties:
21 | type: "string"
22 | description: "用户选择的选项值，键为选项名称，值为用户选择的值"
23 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/orange-americano/instruction.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/examples/adp/lkcoffe/orange-americano/instruction.jpg
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/orange-americano/orange-americano.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "ad": "https://service.agent-network-protocol.com/ad#"
5 | },
6 | "@type": "Product",
7 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/orange-americano/orange-americano.json",
8 | "identifier": "oa-29ab8cf9",
9 | "name": "橙C美式",
10 | "description": "小众果香，搭配浓郁咖啡，适合追求新鲜感和独特口味的消费者。",
11 | "brand": {
12 | "@type": "Brand",
13 | "name": "瑞幸咖啡"
14 | },
15 | "additionalProperty": [
16 | {
17 | "@type": "PropertyValue",
18 | "name": "Feature",
19 | "value": "大师级Espresso，使用IIAC金奖咖啡豆"
20 | },
21 | {
22 | "@type": "PropertyValue",
23 | "name": "Slogan",
24 | "value": "橙C美式 破亿杯！"
25 | },
26 | {
27 | "@type": "PropertyValue",
28 | "name": "Juice Content",
29 | "value": "1杯橙汁含量 ≈ 1个橙子"
30 | },
31 | {
32 | "@type": "PropertyValue",
33 | "name": "Flavor",
34 | "value": "浓郁橙香，清新沁爽"
35 | },
36 | {
37 | "@type": "PropertyValue",
38 | "name": "Coffee Blend",
39 | "value": "定制融合IIAC金奖浓缩咖啡，口感丰富高亮亮味蕾"
40 | },
41 | {
42 | "@type": "PropertyValue",
43 | "name": "Espresso",
44 | "value": "大师级定制Espresso，源自IIAC金奖咖啡豆"
45 | },
46 | {
47 | "@type": "PropertyValue",
48 | "name": "Coffee Origin",
49 | "value": "瑞幸冠军团队经历上百次调试，寻求多产区咖啡豆专业拼配方案，甄选100%阿拉比卡咖啡豆，捕捉埃塞俄比亚、巴西、哥伦比亚、危地马拉等产区风味特征，呈现独特风味与浓醇口感"
50 | }
51 | ],
52 | "offers": {
53 | "@type": "Offer",
54 | "price": "20",
55 | "priceCurrency": "CNY",
56 | "availability": "https://schema.org/InStock"
57 | },
58 | "image": {
59 | "@type": "ImageObject",
60 | "url": "https://service.agent-network-protocol.com/agents/lkcoffe/orange-americano/instruction.jpg",
61 | "caption": "橙C美式 - 小众果香与浓郁咖啡的完美融合",
62 | "description": "一杯清新橙香与浓郁咖啡完美融合的饮品，使用IIAC金奖咖啡豆制作，搭配新鲜橙汁，呈现独特的果香咖啡体验"
63 | },
64 | "audience": {
65 | "@type": "Audience",
66 | "audienceType": "咖啡爱好者"
67 | },
68 | "manufacturer": {
69 | "@type": "Organization",
70 | "name": "瑞幸咖啡",
71 | "url": "https://luckincoffee.com"
72 | },
73 | "customizationOptions": {
74 | "@type": "ad:CustomizationOptions",
75 | "options": [
76 | {
77 | "@type": "PropertyValue",
78 | "name": "杯型",
79 | "isRequired": true,
80 | "value": ["小杯", "中杯", "大杯"]
81 | },
82 | {
83 | "@type": "PropertyValue",
84 | "name": "咖啡豆",
85 | "isRequired": true,
86 | "value": ["IIAC金奖豆"]
87 | },
88 | {
89 | "@type": "PropertyValue",
90 | "name": "温度",
91 | "isRequired": true,
92 | "value": ["冰", "热"]
93 | },
94 | {
95 | "@type": "PropertyValue",
96 | "name": "糖度",
97 | "isRequired": true,
98 | "value": ["标准甜", "少甜", "少少甜", "微甜", "不另外加糖"]
99 | }
100 | ]
101 | }
102 | }
103 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/roasted-coconut-latte/instruction.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/examples/adp/lkcoffe/roasted-coconut-latte/instruction.jpeg
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/roasted-coconut-latte/roasted-coconut-latte.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "ad": "https://service.agent-network-protocol.com/ad#"
5 | },
6 | "@type": "Product",
7 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/roasted-coconut-latte/roasted-coconut-latte.json",
8 | "identifier": "rl-29ab8cf9",
9 | "name": "烤椰拿铁",
10 | "description": "135°C左右高温烘烤，独特椰子糖味道，适合冬季饮用。这款饮品结合了椰肉汁和烤椰粒，提供五个‘0’轻轻享的健康选择，使用大师级定制的Espresso，源自IIAC金奖咖啡豆。",
11 | "brand": {
12 | "@type": "Brand",
13 | "name": "瑞幸咖啡"
14 | },
15 | "additionalProperty": [
16 | {
17 | "@type": "PropertyValue",
18 | "name": "Feature",
19 | "value": "椰肉汁 & 烤椰粒调配, 5个‘0’轻轻享（0乳糖、0植脂末、0蔗糖固体、0反式脂肪酸、0香精物加）, 大师级定制Espresso，源自IIAC金奖咖啡豆"
20 | },
21 | {
22 | "@type": "PropertyValue",
23 | "name": "Slogan",
24 | "value": "冬季特饮 暖暖回归"
25 | },
26 | {
27 | "@type": "PropertyValue",
28 | "name": "Additional Info",
29 | "value": "记忆中的椰子椰味道"
30 | }
31 | ],
32 | "offers": {
33 | "@type": "Offer",
34 | "price": "13",
35 | "priceCurrency": "CNY",
36 | "availability": "https://schema.org/InStock"
37 | },
38 | "nutrition": {
39 | "@type": "NutritionInformation",
40 | "calories": "150",
41 | "fatContent": "0g",
42 | "sugarContent": "0g",
43 | "proteinContent": "0g",
44 | "cholesterolContent": "0mg",
45 | "carbohydrateContent": "0g"
46 | },
47 | "ingredients": "椰奶，浓缩咖啡，烤椰糖浆",
48 | "category": "饮料",
49 | "sku": "LK-COCONUT-LATTE",
50 | "image": {
51 | "@type": "ImageObject",
52 | "url": "https://service.agent-network-protocol.com/agents/lkcoffe/roasted-coconut-latte/instruction.jpeg",
53 | "caption": "烤椰拿铁 - 冬季特饮暖暖回归",
54 | "description": "采用135°C高温烘烤工艺，完美融合椰肉汁和烤椰粒，搭配IIAC金奖咖啡豆制作的Espresso，带来独特的烤椰香与咖啡香的完美融合"
55 | },
56 | "audience": {
57 | "@type": "Audience",
58 | "audienceType": "咖啡爱好者",
59 | "geographicArea": "中国"
60 | },
61 | "manufacturer": {
62 | "@type": "Organization",
63 | "name": "瑞幸咖啡",
64 | "url": "https://luckincoffee.com"
65 | },
66 | "customizationOptions": {
67 | "@type": "ad:CustomizationOptions",
68 | "options": [
69 | {
70 | "@type": "PropertyValue",
71 | "name": "温度",
72 | "isRequired": true,
73 | "value": ["冰", "热"]
74 | },
75 | {
76 | "@type": "PropertyValue",
77 | "name": "糖度",
78 | "isRequired": true,
79 | "value": ["标准甜", "少甜", "微甜", "不另外加糖"]
80 | }
81 | ]
82 | }
83 | }
84 |
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/silk-latte/instruction.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/examples/adp/lkcoffe/silk-latte/instruction.jpg
--------------------------------------------------------------------------------
/examples/adp/lkcoffe/silk-latte/silk-latte.json:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "@vocab": "https://schema.org/",
4 | "ad": "https://service.agent-network-protocol.com/ad#"
5 | },
6 | "@type": "Product",
7 | "@id": "https://service.agent-network-protocol.com/agents/lkcoffe/silk-latte/silk-latte.json",
8 | "identifier": "sl-29ab8cf9",
9 | "name": "丝绸拿铁",
10 | "description": "采用高品质奶源，提供丝滑口感，适合追求健康和口感的消费者。",
11 | "brand": {
12 | "@type": "Brand",
13 | "name": "瑞幸咖啡"
14 | },
15 | "additionalProperty": [
16 | {
17 | "@type": "PropertyValue",
18 | "name": "Feature",
19 | "value": "丝滑厚奶，丝滑蛋白含量 20.99%, 0乳糖、0植脂末、0蔗糖固体、0反式脂肪酸、0香精物加"
20 | },
21 | {
22 | "@type": "PropertyValue",
23 | "name": "Slogan",
24 | "value": "添加丝绸风味厚奶"
25 | }
26 | ],
27 | "offers": {
28 | "@type": "Offer",
29 | "price": "20",
30 | "priceCurrency": "CNY",
31 | "availability": "https://schema.org/InStock"
32 | },
33 | "image": {
34 | "@type": "ImageObject",
35 | "url": "https://service.agent-network-protocol.com/agents/lkcoffe/silk-latte/instruction.jpg",
36 | "caption": "丝绸拿铁 - 丝滑浓郁的咖啡体验",
37 | "description": "采用高品质奶源制作的丝滑拿铁，0乳糖、0植脂末，带来纯净丝滑的口感体验，搭配优质咖啡豆，呈现完美平衡的咖啡风味"
38 | },
39 | "audience": {
40 | "@type": "Audience",
41 | "audienceType": "咖啡爱好者"
42 | },
43 | "manufacturer": {
44 | "@type": "Organization",
45 | "name": "瑞幸咖啡",
46 | "url": "https://luckincoffee.com"
47 | },
48 | "customizationOptions": {
49 | "@type": "ad:CustomizationOptions",
50 | "options": [
51 | {
52 | "@type": "PropertyValue",
53 | "name": "杯型",
54 | "isRequired": true,
55 | "value": ["小杯", "中杯", "大杯"]
56 | },
57 | {
58 | "@type": "PropertyValue",
59 | "name": "咖啡豆",
60 | "isRequired": true,
61 | "value": ["IIAC金奖豆", "深烘拼配豆"]
62 | },
63 | {
64 | "@type": "PropertyValue",
65 | "name": "温度",
66 | "isRequired": true,
67 | "value": ["冰", "热"]
68 | },
69 | {
70 | "@type": "PropertyValue",
71 | "name": "糖度",
72 | "isRequired": true,
73 | "value": ["标准甜", "少甜", "少少甜", "微甜", "不另外加糖"]
74 | }
75 | ]
76 | }
77 | }
78 |
--------------------------------------------------------------------------------
/images/Internet.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/Internet.png
--------------------------------------------------------------------------------
/images/agent-a-call-agent-b.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/agent-a-call-agent-b.png
--------------------------------------------------------------------------------
/images/agent-connect-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/agent-connect-architecture.png
--------------------------------------------------------------------------------
/images/agent-discovery-protocol.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/images/agent-network-diagram.svg:
--------------------------------------------------------------------------------
1 |
83 |
--------------------------------------------------------------------------------
/images/agentic-web-new.svg:
--------------------------------------------------------------------------------
1 |
98 |
--------------------------------------------------------------------------------
/images/agentic-web3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/agentic-web3.png
--------------------------------------------------------------------------------
/images/ai-native-network.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/ai-native-network.png
--------------------------------------------------------------------------------
/images/anp-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/anp-architecture.png
--------------------------------------------------------------------------------
/images/anp-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/anp-flow.png
--------------------------------------------------------------------------------
/images/cross-platform-authentication.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/cross-platform-authentication.png
--------------------------------------------------------------------------------
/images/cross-platform-identity-authentication-process.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/cross-platform-identity-authentication-process.png
--------------------------------------------------------------------------------
/images/did-all-core-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/did-all-core-flow.png
--------------------------------------------------------------------------------
/images/did-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/did-architecture.png
--------------------------------------------------------------------------------
/images/did-as-identity-bridge.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/did-as-identity-bridge.png
--------------------------------------------------------------------------------
/images/did-identity-authentication.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/did-identity-authentication.png
--------------------------------------------------------------------------------
/images/end-to-end-encryption-process.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/end-to-end-encryption-process.png
--------------------------------------------------------------------------------
/images/message-did-register-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/message-did-register-flow.png
--------------------------------------------------------------------------------
/images/message-flow-architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/message-flow-architecture.png
--------------------------------------------------------------------------------
/images/message-send-receive-flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/message-send-receive-flow.png
--------------------------------------------------------------------------------
/images/meta-protocol-communication.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/meta-protocol-communication.png
--------------------------------------------------------------------------------
/images/multi-did-privacy.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/images/protocol-layer-design.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/protocol-layer-design.png
--------------------------------------------------------------------------------
/images/relationship.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/30b1418079f22496add3b9bfb8923f24360ca9b4/images/relationship.png
--------------------------------------------------------------------------------
/scripts/add_copyright.py:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env python3
2 | import os
3 | import sys
4 |
5 | def is_chinese_file(filepath):
6 | # Check if file is in chinese directory or has cn in name
7 | return 'chinese' in filepath or 'cn' in filepath.lower()
8 |
9 | def add_copyright_notice(filepath):
10 | try:
11 | with open(filepath, 'r', encoding='utf-8') as f:
12 | content = f.read()
13 |
14 | # Skip if copyright notice already exists
15 | if '版权声明' in content or 'Copyright Notice' in content:
16 | return
17 |
18 | # Prepare copyright notice based on language
19 | if is_chinese_file(filepath):
20 | copyright_notice = """
21 | ## 版权声明
22 | Copyright (c) 2024 GaoWei Chang
23 | 本文件依据 [MIT 许可证](./LICENSE) 发布，您可以自由使用和修改，但必须保留本版权声明。
24 | """
25 | else:
26 | copyright_notice = """
27 | ## Copyright Notice
28 | Copyright (c) 2024 GaoWei Chang
29 | This file is released under the [MIT License](./LICENSE). You are free to use and modify it, but you must retain this copyright notice.
30 | """
31 |
32 | # Add copyright notice to the end of file
33 | with open(filepath, 'a', encoding='utf-8') as f:
34 | f.write(copyright_notice)
35 |
36 | print(f"Added copyright notice to {filepath}")
37 |
38 | except Exception as e:
39 | print(f"Error processing {filepath}: {str(e)}")
40 |
41 | def main():
42 | # Walk through all directories
43 | for root, dirs, files in os.walk('.'):
44 | # Skip venv directory
45 | if 'venv' in root:
46 | continue
47 |
48 | for file in files:
49 | if file.endswith('.md'):
50 | filepath = os.path.join(root, file)
51 | add_copyright_notice(filepath)
52 |
53 | if __name__ == '__main__':
54 | main()
55 |
--------------------------------------------------------------------------------
/scripts/rename_images.py:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env python3
2 |
3 | import os
4 | import re
5 |
6 | def natural_sort_key(s):
7 | """Sort strings containing numbers in natural order."""
8 | return [int(text) if text.isdigit() else text.lower()
9 | for text in re.split('([0-9]+)', s)]
10 |
11 | def rename_files():
12 | directory = "/Users/cs/work/AgentNetworkProtocol/blogs/images/anp-in-w3c-20250214"
13 | files = [f for f in os.listdir(directory) if f.endswith('.jpg')]
14 |
15 | # Sort files naturally
16 | files.sort(key=natural_sort_key)
17 |
18 | # Rename files
19 | for i, old_name in enumerate(files, 1):
20 | old_path = os.path.join(directory, old_name)
21 | new_name = f"page{i}.jpg"
22 | new_path = os.path.join(directory, new_name)
23 | os.rename(old_path, new_path)
24 | print(f"Renamed {old_name} to {new_name}")
25 |
26 | if __name__ == "__main__":
27 | rename_files()
28 |
--------------------------------------------------------------------------------