Agent初级

一、什么是Agent1. Agent简介及其类型Agent是通过赋予大型语言模型LLM工具和知识访问权扩展其能力使大型语言模型能够执行操作的系统。把这个定义拆分成更小的部分系统——重要的是将Agents看作由多个组成部分组成的系统而不仅仅是单个组成部分。在基本层面Agents的组成部分包括环境——Agents所处的定义空间。例如如果我们有一个旅行预订Agent环境可以是Agent用来完成任务的旅行预订系统。传感器——环境拥有信息并提供反馈。Agents利用传感器收集并解读环境当前状态的信息。以旅行预订代理为例旅行预订系统可以提供诸如酒店可用性或机票价格等信息。执行者——一旦Agent接收到当前环境状态代理决定当前任务中需要执行的动作以改变环境。对于旅行预订代理来说可能是为用户预订一个可用的房间。大型语言模型——用LLM构建AI代理的优势在于它们能够解读人类语言和数据。这种能力使LLM能够解读环境信息并制定改变环境的计划。执行动作——在Agents之外LLM仅限于动作根据用户提示生成内容或信息的情境。在AgentsLLM可以通过解读用户请求并利用环境中可用的工具来完成任务。工具访问——LLM能访问哪些工具取决于1其运行环境和2Agents的开发者。以我们的旅行社为例Agent的工具受限于预订系统中的操作和/或开发者可以限制代理对航班的工具访问。记忆知识——在用户与Agents对话的语境中记忆可以是短期的。从长远来看在环境提供的信息之外Agents还可以从其他系统、服务、工具甚至其他代理处获取知识。以旅行社为例这些知识可以是客户数据库中用户旅行偏好的信息。Agent类型描述示例Simple Reflex Agents根据预设规则立即执行行动。旅行社会解读邮件的上下文并将旅行投诉转发给客户服务。Model-Based Reflex Agents基于世界模型及其变化执行动作。旅行社会根据历史价格数据的访问优先考虑价格变化较大的路线。Goal-Based Agents通过解读目标并确定行动来制定实现具体目标的计划。旅行社通过确定从当前地点到目的地所需的旅行安排汽车、公共交通、航班来预订行程。Utility-Based Agents考虑偏好并用数值权衡权衡以确定如何实现目标。旅行社通过权衡便利与成本来最大化实用性。Learning Agents通过回应反馈并相应调整行动逐步提升。旅行社通过利用客户出行后调查反馈来调整未来的预订从而改进。Hierarchical Agents在分层系统中包含多个代理高级代理将任务拆分为子任务供低级别代理完成。旅行社通过将任务划分为子任务例如取消特定预订并由低级别代理完成并向高级代理汇报来取消行程。Multi-Agent SystemsMAS代理独立完成任务可以合作或竞争。合作多位代理预订特定的旅游服务如酒店、机票和娱乐。竞争性多个代理管理并竞争共享的酒店预订日历以预订客户入住酒店。2. Agent使用场景开放式任务没有固定流程需要AI自己来判断下一步该做什么。就是说目标清楚路径不固定。多步骤流程任务需要连续操作中间可能要调用工具查资料等待结果再继续做下一步。随时间改进反馈可以带来更好的决策系统根据用户反馈不断调整做的结果越来越好。3. 设计Agent要考虑哪些因素开发一个Agent先定义能力再选择协作模式最后用框架将其实现出来。定义能力包括toolsactionsbehaviors。Agent能调用什么外部能力例如搜索、查数据库、调API、发邮件、查日历。工具决定了它“能做什么事”。执行哪些具体操作例如查询价格、生成方案、比较选项、提交订单。动作决定了它“具体怎么干活”。遇到不同情况按什么方式做决策例如优先省钱还是省时间、信息不足时先追问还是先猜测、多个方案时怎么排序。行为决定了它“做事的风格和策略”。智能体模式Agent 干活时的一套“固定套路”或“流程模板”。常见的模式先规划再执行边执行边反思把任务拆给多个角色先搜索信息再回答失败后重试或换方案智能体框架Framework 是开发者把这些 agentic patterns 真正实现成代码的工具。框架能提供模板、插件、工具可以更好的促进Agent的协作。便于更好的observability可观测性和排障。可观测性让我们能看到Agent到底做了什么调用了什么工具为何这么决策哪一步失败了。排障可以让我们在Agent表现不好时进行排查是 prompt 问题、是工具返回异常、是状态传递错错误、还是流程设计有问题。常用的FrameworkLangGraph / LangChain特点是durable execution、streaming、human-in-the-loop。Microsoft Agent FrameworkOpenAI Agents SDK快速用 OpenAI 体系搭 agent 的场景CrewAI多 Agent 协作场景做“团队式协作 agent”时常被拿来用。AutoGen将多智能体系统抽象为一个由多个“可对话”智能体组成的群聊。LlamaIndex如果你的 agent 很依赖文档、知识库、检索/RAGLlamaIndex 很常见。如果你的 agent 很依赖文档、知识库、检索/RAGLlamaIndex 很常见。Google ADK如果你偏 Gemini / Google Cloud 生态可以看 ADKPydanticAI使用 Python而且很在意类型安全、结构化输出、可观测性PydanticAI 很值得看。EinoSpring AI AlibabaCAMEL为两个智能体例如AI研究员和Python程序员设定好各自的角色和共同的任务目标它们就能在“初始提示 (Inception Prompting)”的引导下自主地进行多轮对话相互启发、相互配合共同完成任务。二、Agent框架Agent框架是旨在简化AI代理创建、部署和管理的软件平台。这些框架为开发者提供了预构建的组件、抽象和工具简化复杂人工智能系统的开发流程。这些框架通过提供标准化的方法帮助开发者专注于其应用的独特方面。人工智能代理框架在人工智能开发中的作用支持多智能体协作与协调提升开发效率与代码复用实现核心组件解耦增强系统可扩展性可将智能体系统拆分成独立的模块例如模型层、工具层、记忆层这种模块化设计可以显著提升系统的灵活性和可维护性。支持复杂任务的自动化管理智能体框架通常内置对多步骤工作流的支持包括任务拆解、任务委派、执行顺序控制以及动态任务调整。简化可观测性与调试过程如何利用人工智能代理框架构建智能代理尝试基于不同的框架实现不同项目LangGraph流程编排LangGraph 作为 LangChain 生态系统的重要扩展代表了智能体框架设计的一个全新方向。与前面介绍的基于“对话”的框架如 AutoGen 和 CAMEL不同LangGraph 将智能体的执行流程建模为一种状态机State Machine并将其表示为有向图Directed Graph。在这种范式中图的节点Nodes代表一个具体的计算步骤如调用 LLM、执行工具而边Edges则定义了从一个节点到另一个节点的跳转逻辑。这种设计的革命性之处在于它天然支持循环使得构建能够进行迭代、反思和自我修正的复杂智能体工作流变得前所未有的直观和简单。关键三要素全局状态、节点、边全局状态整个图的执行过程都围绕一个共享的状态对象进行。它可以包含任何你需要追踪的信息如对话历史、中间结果、迭代次数等。所有的节点都能读取和更新这个中心状态。节点每个节点都是一个接收当前状态作为输入、并返回一个更新后的状态作为输出的 Python 函数。节点是执行具体工作的单元。边边负责连接节点定义工作流的方向。最简单的边是常规边它指定了一个节点的输出总是流向另一个固定的节点。而 LangGraph 最强大的功能在于条件边Conditional Edges。它通过一个函数来判断当前的状态然后动态地决定下一步应该跳转到哪个节点。LlamadaIndex知识库增强AutoGen多智能体协作一个系统中可以基于多个框架来实现吗一个Agent基于一个框架来做最好。自己搭建Agent框架三、工具使用什么叫做使用工具的设计模式给大模型一种能力让它可以调用外部工具来完成具体目标。普通大模型更擅长理解文本生成文本做推理本身不能查天气访问数据库执行代码调用外部接口。所以需要给大模型接上工具让大模型能够自行判断什么时候使用该工具选择使用合适的工具并自己将参数传给工具读取工具返回的结果再根据结果继续推理或回答。工具的定义可以是Agent可以执行的代码可以是一些简单的函数也可以是第三方服务的API。Agent调用工具的过程用户提出任务模型分析任务模型决定要不要调用某个工具模型生成一个“函数调用请求”Agent 系统接收到这个请求后真的去执行对应工具把结果返回给模型模型再根据结果给出最终回答Function Call就是让大模型在需要时能够生成结构化的函数调用请求而不是直接用自然语言硬回答。系统拿到这个请求后去执行对应函数再把结果返回给模型由模型生成最终答案。它的核心作用是把大模型的理解和推理能力与外部工具或系统的执行能力连接起来。实现工具所需的关键要素功能/工具模式可用工具的详细定义包括功能名称、用途、所需参数和预期输出。这些模式使LLM能够理解可用的工具以及如何构建有效请求。函数执行逻辑根据用户意图和对话上下文规范工具的调用方式和时机。这可能包括规划模块、路由机制或动态决定工具使用的条件流。消息处理系统管理用户输入、LLM响应、工具调用和工具输出之间的对话流程的组件。工具集成框架将代理连接到各种工具的基础设施无论是简单功能还是复杂的外部服务。错误处理与验证处理工具执行失败、参数验证和管理意外响应的机制。状态管理跟踪对话上下文、之前的工具交互和持久数据确保多回合交互的一致性。工具调用为了调用函数的代码LLM必须将用户请求与函数描述进行比较。为此包含所有可用功能的描述的模式会发送给LLM。LLM 随后选择最合适的任务函数返回其名称和参数。调用所选函数其响应会返回给LLMLLM利用这些信息响应用户请求。注意事项需要对工具的结果进行验证和可信性判断限制工具的权限不能让Agent想调什么就调什么做好参数验证不能完全相信模型生成的调用参数要能追踪工具的调用过程通过日志或记录方便排查问题避免处理失败就胡编答案应该提供保守回答或降级机制······工具系统的高级特性能帮助工具系统在复杂的生产环境中稳定运行为Agent提供给强大能力工具的链式调用机制在实际应用中Agent经常需要组合使用多个工具来完成复杂任务。我们可以设计一个工具链管理器来支持这种场景。异步工具执行支持对于耗时的工具操作可以提供异步执行支持。工具系统开发的核心理念在设计层面每个工具都应该遵循单一职责原则专注于特定功能的同时保持接口的统一性并将完善的异常处理和安全优先的输入验证作为基本要求。在性能优化方面利用异步执行提高并发处理能力同时合理管理外部连接和系统资源。补充——Agent Skill简介模型本身很强但真正干活还需要流程知识和组织里的具体经验。Agent Skills就是为了把这些经验封装成一套能被 Agent 发现、按需加载、反复复用的能力包让通用 Agent 变成更贴合具体任务的专用 Agent。文中把 Skill 形容成给新员工准备的 onboarding guide不是每次重新造一个 Agent而是把你的做事方法、脚本和资料整理出来让 Agent 学会按你的方式做事。Skill是什么一个 Skill 本质上就是一个目录里面最核心的是一个SKILL.md文件除此之外还可以放脚本、参考资料和其他资源文件。也就是说Skill 不是一个单独的 API也不是一个单独的 prompt而是一个文件夹级别的能力包。由 instructions、scripts、resources 组成的 organized folders用来给 Agent 增加额外能力。Skill的渐进式加载progressive disclosure不是一上来就把整个 Skill 全塞进上下文里而是分层加载。第一层是SKILL.md最前面的 YAML frontmatter里面至少要有name和description。Agent 启动时只会预加载每个已安装 Skill 的 name 和 description 到 system prompt 里。这一步的作用是先让模型知道有哪些 Skill 可用、各自大概是干什么的但不把全部内容都塞进上下文。第二层是SKILL.md的正文。如果模型根据当前任务判断这个 Skill 相关它才会去把完整的SKILL.md读进上下文。也就是说Skill 先靠元数据被发现再靠正文被真正加载。第三层是 Skill 目录里其他补充文件。核心说明写在SKILL.md而像forms.md、reference.md这样的更细分内容则在需要时再读。这样做的目的是让核心说明保持精简把只在某些场景下才有用的材料拆出去。所以你可以把它记成一句话先看目录再看总纲再按需翻具体章节。这就是 Skill 的核心加载逻辑。Skill与上下文窗口的关系Skill 的价值很大一部分就在于节省上下文窗口。因为 Agent 有文件系统和代码执行能力它没必要把整个 Skill 一次性读进上下文。它只需要在任务触发时通过工具去读取相关文件。文中甚至直接说这意味着能打包进 Skill 的上下文量实际上几乎是不受限的因为不是所有内容都必须常驻上下文。Skill存放可执行代码说明文件解决“该怎么做”代码脚本解决“某一步最好确定性地执行”把“语言层的经验”和“程序层的执行”合在一起了。如何设计一个好的SkillSkill 应该是拿来补能力缺口的。先看 Agent 在真实任务里哪里做不好再有针对性地补 Skill。边用边迭代。把成功方法和常见错误逐渐沉淀进 Skill如果Agent用skill跑偏了还要反思哪里出了问题再把经验写回Skill。风险Skill 很强也因此有安全风险。因为 Skill 既能提供指令也能带代码如果是恶意 Skill可能会引入环境漏洞、诱导 Agent 外传数据或者执行不该执行的操作。所以 Skill 不能当成普通静态文档看而应该当成高权限能力包来审查。四、Memory与RAGMemory人工智能智能体的记忆指的是允许他们保留和回忆信息的机制。这些信息可以是关于对话的具体细节、用户偏好、过去的行为甚至是学习到的模式。如果没有记忆Agent通常是无状态的每次交互需要从零开始。Memory的重要性Memory的智力与其回忆和利用过去信息的能力密切相关。内存允许Agents成为•反思性从过去的行为和成果中学习。•互动在持续对话中保持上下文。•主动与被动根据历史数据预见需求或做出适当回应。•自主通过利用储存的知识实现更独立的操作。实现内存的目标是让代理更可靠、更有能力。区分不同类型的人工智能代理记忆工作记忆对于人Agents来说工作记忆往往捕捉对话中最相关的信息它侧重于提取需求、提案、决策和行动等关键要素。短期记忆短期记忆是 Agent 对当前会话中最近相关信息的临时保存用来维持当前任务的连续性。例如最近几轮的用户输入。长期记忆它使Agents能够在较长时间内记住用户偏好、历史互动或一般知识。这对个性化非常重要。人格记忆使智能体能够记住关于自身或其预期角色的细节使互动更加流畅和聚焦。工作流程情节记忆该Memory存储代理在复杂任务中采取的步骤顺序包括成功与失败。这就像记住特定的“发作”或过去的经历从中学习。例如如果客服尝试预订特定航班但因无法预订而失败情节记忆可以记录此失败使客服能够尝试替代航班或在后续尝试时更有效地告知用户问题。实体记忆这涉及从对话中提取并记忆特定的实体如人、地点或事物和事件。它使代理能够对讨论的关键要素建立结构化理解。结构化RAG结构化RAG被强调为一项强大的存储技术。它从各种来源对话、电子邮件、图片提取密集且结构化的信息并用以提升响应的准确性、记忆力和速度。与仅依赖语义相似性的经典RAG不同结构化RAG利用信息的固有结构。如何实现和管理Agent的长期记忆和短期记忆短期记忆的实现1会话缓冲区通过给每个session维护一个消息列表保存用户问题当前任务目标用户给的约束工具调用结果中间状态等等让Agent在下一轮还能接着干不会忘。这个存储内容什么时候释放限制多大2最近消息加历史摘要保存最近的N轮原始消息把更早的对话压缩成结构化的总结。3结构化任务状态适用于调用工具分步执行的Agent。短期记忆的管理控量保真不断线三个点对应三个策略保留策略更新策略清理策略保留策略就是决定保留最近的多少轮信息工具输出是保留完整日志还是关键字段对更早的内容做摘要。更新策略就是在每轮交互后更新当前的目标新的约束工具结果的影响完成步骤摘要化内容。清理策略就是在任务完成后重置用户换话题则降低旧状态的权重等等。长期记忆的实现通过键值/文档存储适合存明确、稳定的用户档案。向量数据库适合存语义可检索的记忆。比如把一段历史经验存成文本再做 embedding后面按语义检索用户曾要求用面试表达方式解释 MCP用户在白细胞分类项目中倾向于粗分类 细分类方案后面用户一提相关话题就能召回。常用的数据库包括Milvus、pgvector、FAISS、Weaviate、Chroma。图结构关系存储如果记忆之间关系很重要可以用图数据库。这种适合复杂多实体、多关系场景。长期记忆的管理长期记忆最大的风险不是记不住而是记错、记杂、记太多。所以重点在写入规则和检索规则。先决定什么值得写入用户明确要求记住的信息稳定偏好会长期影响回答质量的信息反复出现的习惯高价值经验总结写入时加入元数据长期记忆最好别只存一段文本还要带上标签。这样后面方便去重、更新、冲突处理、过期清理、检索排序等操作。检索时按需拿不要全塞先判断当期那任务再检索相关记忆选择最相关的N条压缩后注入上下文。要能更新、覆盖和遗忘新信息覆盖旧信息保留版本号记录最后一次确认时间对长期不用的记忆降权或过期支持用户显式删除记忆管理系统促进持续学习和适应记忆管理系统之所以能促进持续学习和适应本质上是因为它让 Agent 不只是每次重新开始而是能够把过去任务中的有效经验沉淀下来在下一次任务中继续利用、修正和优化。通过引入一个知识Agent实现Agent的自我改进。通过独立观察用户与Agent之间的主要对话来识别有价值的信息摘录总结将提取信息存储在知识库中当用户发起新的查询时通过检索将相关存储信息附加到用户提示词中为主Agent提供关键上下文。持续学习与适应的基础经历任务 → 记录关键信息 → 提炼有效经验 → 在新任务中检索复用 → 根据结果继续修正记忆五、上下文工程什么是上下文工程对于Agent来说上下文是驱动某些行动的规划因素。上下文窗口的大小有限因此作为Agent构建者需要构建系统和流程来管理上下文窗口中信息的添加、删除和压缩。提示工程与上下文工程提示工程关注指令本身如何写得更清楚、更稳定、更能引导模型按预期做事。上下文工程关注模型决策时到底看到了什么信息以及这些信息如何被组织。提示工程解决如何引导模型做事上下文工程解决如何让模型拥有足够且正确的信息去做事。提示词工程一般是让模型充当什么然后告诉模型做事的流程输出的形式就是告诉模型要怎么做上下文工程是提供给模型相关解决问题所需要的信息让模型知道解决这个问题基于什么来做。上下文的关键组成部分上下文类型•指令这些类似于代理的“规则”——提示、系统消息、少数示例向AI展示如何操作以及其可用工具的描述。这正是提示工程与上下文工程结合的地方。•知识涵盖事实、从数据库中获取的信息或代理人积累的长期记忆。这包括在Agent需要访问不同知识库和数据库时集成检索增强生成RAG系统。•工具这些是Agent可以调用的外部函数、API 和 MCP 服务器的定义以及使用它们后获得的反馈结果。•对话历史与用户的持续对话。随着时间推移这些对话变得更长更复杂这意味着它们占据了上下文窗口的空间。•用户偏好随着时间推移了解用户的喜好或厌恶。这些数据可以被存储并在做出关键决策时调用帮助用户。很多人把代理效果不好归结为prompt 没写好。但真正复杂的代理系统问题往往不只是提示词而是上下文组织方式。因为提示工程更像是在优化“你怎么说”。上下文工程更像是在设计“你给模型看什么、按什么顺序给、哪些该保留、哪些该丢弃”。如何制定有效策略提升Agent性能什么样的上下文配置最有可能让模型产出我们期望的行为良好规划上下文定义清晰的反馈结果用户在和Agent互动预后有哪些变化、信息或反应。映射上下文回答Agent完成你当前任务需要哪些信息创建上下文构建流程回答如何获取需要的信息包括使用RAGMCP及其他工具上下文的管理策略虽然部分信息会自动添加到上下文窗口但上下文工程则是对这些信息采取更积极的作用。Agent Scratchpad临时笔记现将中间过程的信息放在外部某个运行时的对象、文件、缓存中Agent需要时再将其取回来。适合多步骤任务需要频繁调用工具的任务。Memorise用于保存跨会话保存的信息例如用户偏好、长期项目背景、跨会话持续有效信息。Compressing Context压缩上下文当对话太长、资料太多、上下文窗口快满了就要做压缩。模型不是无限上下文如果将历史消息都存下来窗口很快就会爆所以要把长内容变成更紧凑的表示。常见压缩方式摘要总结只保留关键事实删除旧的、无关的轮次把长文档压成结构化要点保留最近原文 较早部分摘要Multi-Agent-Systems把复杂任务拆给多个代理处理每个代理有自己的上下文窗口、角色和职责。多Agent系统不仅是任务拆分也是上下文拆分。Sandbox Environments沙箱环境这是把一些高 token、强计算、结构复杂的工作放到外部执行环境里做而不是全靠模型在上下文里“想”。什么是沙箱环境例如代码执行器、容器、临时运行环境。例如用户需要对一个200页的PDF做表格提取并汇总合理的做法是先用沙箱解析PDF提取出表格再统计结果把这个关键结果汇总给模型。沙箱环境隔离它和主系统分开不是让代理随便访问所有东西。临时很多沙箱是任务结束就销毁避免长期污染环境。权限受控能访问什么文件、能不能联网、能不能写磁盘通常都有限制。可执行它不是只存信息而是真的能运行代码、处理任务。Runtime State Objects运行时状态对象在系统运行过程中把不同任务阶段、子任务结果、流程状态存成结构化对象。相比于Scratchpad更家工程化。识别常见的情景错误情境中毒当幻觉由LLM生成的虚假信息或错误进入上下文并反复被引用时导致智能体追求不可能实现的目标或制定无意义的策略。怎么办实施上下文验证和隔离。在信息被加入长期记忆之前先验证它。如果检测到潜在中毒应重新创建上下文线程防止负面信息传播。情境分散当上下文过于庞大模型过于关注积累的历史而忽视了训练中学到的内容导致重复或无益的操作。模型可能在上下文窗口尚未满时就开始犯错。怎么办使用上下文总结。定期将积累的信息压缩成简短摘要保留重要细节并去除冗余历史。这有助于“重置”焦点。上下文混淆当不必要的上下文通常表现为过多可用的工具时模型会产生错误的响应或调用无关工具。较小的模型尤其容易出现这种情况。怎么办利用RAG技术实现工具负载管理。将工具描述存储在矢量数据库中并仅为每个具体任务选择最相关的工具。研究表明工具选择应限制在30个以下。情境冲突当上下文中存在矛盾信息导致推理不一致或最终反应不佳时。这通常发生在信息分阶段到达时早期错误假设仍留在语境中。怎么办使用上下文剪枝和卸载。修剪是指随着新细节的到来删除过时或相互矛盾的信息。卸载为模型提供了一个独立的“临时工作区”用于处理信息而不扰乱主要上下文。六、通信协议MCPModel Context ProtocolMCP简介MCP是一种让大模型应用以统一方式连接外部工具、数据源和上下文能力的开放标准协议你可以把它理解为 Agent 的标准化接口层。过去不同工具和系统的接入方式各不相同往往需要为每个工具单独编写调用逻辑、数据格式转换、权限控制和集成代码导致开发成本高、复用性差、扩展困难而 MCP 通过统一的协议把这些外部能力标准化为可发现、可接入、可管理、可复用的能力接口从而让 Agent 更容易扩展工具、更方便连接本地或远程服务也更利于工程化管理和跨平台复用。为什么需要MCP首先是工具集成的困境每当需要访问新的外部服务如 GitHub API、数据库、文件系统我们都必须编写专门的 Tool 类。这不仅工作量大而且不同开发者编写的工具无法互相兼容。其次是能力扩展的瓶颈智能体的能力被限制在预先定义的工具集内无法动态发现和使用新的服务。最后是协作的缺失当任务复杂到需要多个专业智能体协作时如研究员撰写员编辑我们只能通过手动编排来协调它们的工作。MCP作用让Agent能够以一致方式连接不同的数据源和工具从而实现通用适配器。传统方式下你需要为每个服务编写适配器代码处理不同的 API、认证方式、错误处理等。这不仅工作量大而且难以维护。更重要的是不同 LLM 平台的 function call 实现差异巨大切换模型时需要重写大量代码。MCP 的出现改变了这一切。它就像 USB-C 统一了各种设备的连接方式一样MCP 统一了智能体与外部工具的交互方式。无论你使用 Claude、GPT 还是其他模型只要它们支持 MCP 协议就能无缝访问相同的工具和资源。核心组件客户端-服务器架构•主机是LLM应用程序例如像VSCode这样的代码编辑器用于启动与MCP服务器的连接。•客户端是主机应用内的组件负责与服务器保持一对一连接。•服务器是轻量级程序展示特定功能。一个 Host 可以同时管理多个 Client而每个 Client 通常只对应一个 Server。以Claude为例三层架构的职责Host宿主层Claude Desktop 作为 Host负责接收用户提问并与 Claude 模型交互。Host 是用户直接交互的界面它管理整个对话流程。Client客户端层当 Claude 模型决定需要访问文件系统时Host 中内置的 MCP Client 被激活。Client 负责与适当的 MCP Server 建立连接发送请求并接收响应。Server服务器层文件系统 MCP Server 被调用执行实际的文件扫描操作访问桌面目录并返回找到的文档列表。完整的交互流程用户问题 → Claude Desktop(Host) → Claude 模型分析 → 需要文件信息 → MCP Client 连接 → 文件系统 MCP Server → 执行操作 → 返回结果 → Claude 生成回答 → 显示在 Claude Desktop 上。MCP的核心能力工具这些是AI代理可以调用以执行某项操作的离散动作或函数。例如气象服务可能会暴露“获取天气”工具或者电子商务服务器可能会暴露“购买产品”工具。MCP服务器会在其能力列表中宣传每个工具的名称、描述以及输入/输出模式。资源这些是MCP服务器可提供的只读数据项或文档客户端可以按需检索。例如文件内容、数据库记录或日志文件。资源可以是文本如代码或JSON或二进制如图片或PDF。提示这些是预定义的模板提供建议提示支持更复杂的工作流程。MCP与Function Call的差异Function Calling 与 MCP 并非竞争关系而是相辅相成的。Function Calling 是大语言模型的一项核心能力它体现了模型内在的智能使模型能够理解何时需要调用函数并精准生成相应的调用参数。相对地MCP 则扮演着基础设施协议的角色它在工程层面解决了工具与模型如何连接的问题通过标准化的方式来描述和调用工具。我们可以用一个简单的类比来理解Function Calling 相当于你学会了“如何打电话”这项技能包括何时拨号、如何与对方沟通、何时挂断。而 MCP 则是那个全球统一的“电话通信标准”确保了任何一部电话都能顺利地拨通另一部。具体实现步骤连接MCP服务器连接成功后第一步通常是查询服务器提供了哪些工具调用工具时只需提供工具名称和符合 JSON Schema 的参数除了工具MCP 服务器还可以提供资源ResourcesMCP 服务器可以提供预定义的提示模板这个作用是什么MCP传输方式传输层无关性MCP 协议本身不依赖于特定的传输方式可以在不同的通信通道上运行。5种传输方式MCP的自动展开机制你加进去的表面上是“1 个 MCP 接口”但 Agent 真正看到的不是 1 个总工具而是这个 MCP 服务器里列出来的很多个具体工具。内置工具函数转化为MCP的服务连接外部MCP服务器可以是社区的可以是自定义服务器A2AAgent-to-Agent ProtocolA2A简介A2A 就是 Agent-to-Agent 的标准化通信机制用来解决不同智能体之间的发现、认证、消息传递、任务跟踪和结果返回问题。它的核心作用是让多个独立 Agent 能安全、统一地协作完成复杂任务而不是各自孤立工作。A2A的核心概念A2A的核心组件Agent Card类似于MCP服务器共享工具列表Agent Card具备Agent的名字、描述其完成的一般任务、一份包含具体技能的清单并附有描述帮助其他client甚至真人用户理解何时以及为何想联系该client、Agent当前的URL、Agent当前的版本和功能。Agent Excutor将用户聊天的上下文传递给远程aAgents远程Agents需要这些上下文来理解需要完成的任务。在A2A服务器中代理使用自己的大型语言模型LLM解析入站请求并使用自身内部工具执行任务。Artifact工件一旦远程Agent完成了请求的任务其工作成果将作为工件被创建。工件包含Agent工作的结果、完成内容的描述以及通过协议发送的文本上下文。在发送出工件后与远程Agent的连接会被关闭直到再次需要。事件队列该组件用于处理更新和传递消息。在生产环境中对于智能体系统来说防止代理之间的连接在任务完成前被关闭尤为重要尤其是在任务完成时间可能较长的情况下。A2A的执行流程获取目标Agent的调用元数据Client去向被调用的Agent服务端发送请求GET-Card——返回AgentCard告诉客户端Agent的相关信息认证Client读取AgentCard中的securitySchemes如果需要认证就去Author Server完成认证流程——返回通行证用于目标Agent服务器的身份权限验证发送业务请求Client向目标Agent服务端发送业务请求带上上一步取得的通行证——Task Response系统回复接收到请求已经创建任务流式返回任务执行过程目标Agent服务器端持续将任务执行过程推送回来Client可以看到任务从头到尾的状态变化返回消息包括Stream: Task (Submitted)Stream: TaskStatusUpdateEvent (Working)Stream: TaskArtifactUpdateEvent (artifact A)Stream: TaskArtifactUpdateEvent (artifact B)Stream: TaskStatusUpdateEvent (Completed)artifact可以理解成任务执行过程中产出的成果物。客户端先通过 Agent Card 发现并理解目标 Agent再按其要求完成认证然后通过 sendMessage 或 sendMessageStream 发起一次任务并在任务执行过程中获取状态更新和产出物直到任务完成。ANPAgent Network Protocol一个网络中存在大量功能各异的智能体例如自然语言处理、图像识别、数据分析等时系统会面临一系列挑战服务发现当新任务到达时如何快速找到能够处理该任务的智能体智能路由如果多个智能体都能处理同一任务如何选择最合适的一个如根据负载、成本等并向其分派任务动态扩展如何让新加入网络的智能体被其他成员发现和调用ANP 的设计目标就是提供一套标准化的机制来解决上述的服务发现、路由选择和网络扩展性问题。ANP整体流程在这个流程图里主要包括以下几个步骤1. 服务的发现与匹配首先智能体 A 通过一个公开的发现服务ANP Discovery基于语义或功能描述Capability进行查询以定位到符合其任务需求的智能体 B。该发现服务通过预先爬取各智能体对外暴露的标准端点.well-known/agent-descriptions来建立索引从而实现服务需求方与提供方的动态匹配。2. 基于 DID 的身份验证在交互开始时智能体 A 使用其私钥对包含自身 DID 的请求进行签名。智能体 B 收到后通过解析该 DID 获取对应的公钥并以此验证签名的真实性与请求的完整性从而建立起双方的可信通信。3. 标准化的服务执行身份验证通过后智能体 B 响应请求双方依据预定义的标准接口和数据格式进行数据交换或服务调用如预订、查询等。标准化的交互流程是实现跨平台、跨系统互操作性的基础。总而言之该机制的核心是利用 DID 构建了一个去中心化的信任根基并借助标准化的描述协议实现了服务的动态发现。这套方法使得智能体能够在无需中央协调的前提下安全、高效地在互联网上形成协作网络。七、基于强化学习的智能体训练八、性能评估