一个科技爱好者的个人博客
核心目标
以MCP协议的function形式将私有部署的开源MinDoc Wiki文档服务对接到同样私有部署的AI应用开发编排平台Dify中，并编排入AI工作流Workflow中，以供大模型使用其中的知识。
核心工具
本文的技术详解基于MCP协议的核心流程展开(不了解MCP协议及流程的同学可以先看AI柠檬博主的上一篇关于MCP协议的介绍文章：https://blog.ailemon.net/2025/04/15/mcp-introduction-forecast/)，讲述MCP客户端-服务器交互全流程，我们将以MCP协议(2025-06-18版本)中当前最推荐的”Streamable HTTP”和”JSON-RPC 2.0″展开，以AI柠檬博主提交过Pull Request的开源文档系统MinDoc的MCP服务响应为样例，揭示MCP的生命周期序列、工具操作和通知的底层HTTP请求/响应交互实现[1]。未来如果协议版本有更新，本文也将不定期更新实现细节。
（更多…）在大语言模型高速发展的时代，我们面对困难的语义分析任务，通过构建智能体进行处理是一个流行趋势。本文将介绍如何使用 Visual Basic .NET 开发一个多智能体协作系统，用于分析聊天记录中特定人物的荣格八维人格类型。
（更多…）本文使用 CC-BY-NC-SA 4.0 协议。转载或者 AI 模型/智能体使用请注明出处并标注作者 Nukepayload2。
AI大模型的应用越来越广泛，企业内部和跨系统的多个AI智能体（AI Agent）间协作的需求日益增长。然而，不同AI系统之间往往存在“孤岛效应”，导致数据和能力难以互通。为解决这一问题，Google推出了A2A协议（Agent-to-Agent Protocol），旨在为AI智能体提供一种标准化的协作框架，使其能够像人类对话一样自由组队、分工协作。与MCP协议(Model Context Protocol)的基于服务器-客户端架构的工具调用，和ANP协议（Agent Network Protocol）的以去中心化和语义互联为核心的Agent间通信不同，A2A协议则是将Agent同时作为服务器和客户端进行互联，每个Agent既是调用其他Agent的客户端，也是能够被其他Agent调用的客户端。本文将解析A2A协议的技术原理与流程，并与MCP协议、ANP协议进行对比，探讨其异同与适用场景。
推荐的阅读材料：
做深度学习离不开算力，就像到达诗和远方的旅途离不开交通工具。本文面向深度学习用户整理市面上常用的华为Ascend卡各个版本NPU的关键参数进行汇总整理，方便大家随时查阅。本文收录的卡型号包含昇腾数据中心卡系列(910A/910B/910C/950/960/970等)和推理卡310系列(910P等)。本文中的所有数据来自于互联网搜索结果，如果数据有误，或有新Ascend NPU卡问世，或者需要补充、纠正的参数维度数据，各位看官可以及时通过联系方式来找我更新。如果不同来源的数据有冲突，AI柠檬博主会尽可能选取来源官方、可靠的数据展示，并进行合理推测。
(当前数据整理截止为2025年9月)
（更多…）摘要：本文将介绍AI大模型技术的发展历程，从早期基于规则编程阶段到当前的大语言模型阶段，以及在这期间技术的更替。我们将深入浅出地解释AI大模型的基本概念，探讨优势与不足，未来的发展趋势，并列举典型应用开发场景案例。
摘要：本文全面介绍了ANP协议，探讨了其在AI大模型应用开发中的作用及其相较于MCP协议的优势，解析了其标准流程，并给出了一些具体的代码示例。此外，本文还讨论了ANP协议的优势应用场景，预测了其未来可能面临的挑战及发展趋势，最后进行了总结。
ANP（Agent Network Protocol）是一个开源智能体网络协议框架[1]，由杭州比特智元 CEO、智能体通信协议 ANP 作者常高伟开源[2]。该协议旨在实现不同智能体之间的去中心化协作，构建一个更加开放和互操作性的智能体互联网。ANP协议的核心是通过P2P架构和语义网技术，为智能体提供高效的数据交换和协作机制。其设计灵感来源于Web 3.0的技术理念，希望能够打破现有智能体之间的数据孤岛，实现真正的互联互通[3]。
（更多…）模型上下文协议（Model Context Protocol, MCP）是AI大模型领域中一个开放的协议，由Anthropic公司于2024年11月推出，该协议规定了AI智能体应用以何种方式为大型语言模型（LLM）提供上下文，是AI 应用统一的 “USB-C 接口”，旨在为AI应用与外部资源提供统一的通信框架[1]。如果你想精通MCP协议，搞清楚全部细节，强烈建议去阅读英文官方网站上的内容(英文不好的同学先去学英语吧)：https://modelcontextprotocol.io/docs/getting-started/intro
早先我们会预置AI大模型在调用工具或函数执行时所需要的参数信息，如AI柠檬博主上一篇博客文章提到的 Function Call / Tool Call。该机制允许大模型在需要时调用用户预先定义的函数、工具来获取数据或执行操作，显著提升了自动化水平。这一过程本质上是由大模型输出一个json格式内容，在字段指定参数值中告诉你应该调用什么函数，以及传入什么函数入参来实现。
（更多…）在AI大模型的上下文中，”function calling” 是指AI模型能够直接调用预先定义好的函数来执行特定的任务，而不是仅仅基于文本生成来解决问题。这种能力使得AI可以主动地使用外部工具和资源来解决超出模型本身知识范围的问题，从而使AI的应用更加广泛和深入。
（更多…）这个故事的起因是AI柠檬博主前段时间通过Fork方式给MinDoc开源项目代码仓提交了一个特性的Pull Request，待Owner合入了所有PR后，我这边还要继续通过我Fork的仓库给上游代码仓提交代码，Fork的仓库要跟上游代码仓同步一次。最笨的方法是删了已有的Fork仓库而重新Fork一个，但这显然不优雅，是不完美的方案。
你还别笑，AI柠檬还没实践过这种操作，毕竟，以前都是别人给我的GitHub仓库提交Pull Request的，我作为Owner只管Code Review并合入代码，但是提PR的人要考虑的就多了(雾)。于是本着优雅地追求完美的本心，搜寻最佳解决方法的资料并实践，您别说，还真的行。
（更多…）