1. 从“单打独斗”到“团队协作”AI能力集成的演进脉络如果你最近在关注AI应用开发尤其是大语言模型LLM的落地一定会被一堆新名词搞得眼花缭乱Function Calling、Tools、MCP、A2A、Multi-Agent、Skills……它们听起来都挺厉害但又好像有些重叠让人分不清边界。作为一个从早期API调用一路踩坑过来的开发者我深切感受到这不仅仅是几个新功能更代表了AI从“一个聪明的聊天机器人”向“一个能调用外部能力、甚至能自主协作的智能体”演进的关键路径。理解这些概念不是为了追新而是为了在构建真正有用的AI应用时能做出最合适的技术选型避免在错误的抽象层级上浪费精力。简单来说我们可以把这些概念看作一个能力栈。最底层是Function Calling它让LLM学会了“举手说我要调用某个函数”这是AI与外部世界交互的基石。往上走Tools是对Function的封装和抽象让AI能理解并选择“工具”来完成任务。再往上MCPModel Context Protocol和A2AAgent-to-Agent协议则是在定义AI之间、AI与工具之间如何“对话”和“协作”的规则。而Multi-Agent和Skills则是基于这些底层能力构建的更高层应用架构和业务抽象。今天我就结合自己的实践把这套“能力栈”给你彻底捋清楚让你明白每个层级解决什么问题以及在实际项目中该如何选择。2. Function Calling让大模型学会“举手发言”的底层协议要理解上面那一堆概念必须从Function Calling这个最基础的机制说起。在Function Calling出现之前我们想让GPT这样的模型去查天气、发邮件通常的做法是把需求描述和可能的API参数一起塞进提示词Prompt里指望模型能“猜”出我们想要它输出一个结构化的调用指令。这种方法极其脆弱输出格式不稳定解析起来也麻烦。Function Calling的引入彻底改变了游戏规则。它本质上是一套标准化的“请求-响应”协议。在请求侧开发者发给模型我们不再只是说“帮我查一下北京天气”而是明确地告诉模型“我这里有一个叫做get_current_weather的函数它的作用是查询天气它需要location和unit两个参数。” 模型的任务变成了理解用户的自然语言请求然后判断是否需要、以及需要调用哪个函数并以一个严格符合JSON Schema的结构把调用这个函数所需的参数返回给我们。2.1 Function Calling的工作机制与核心价值这个过程可以拆解为三步定义开发者预先定义好函数或工具的名称、描述和参数格式JSON Schema。描述至关重要它是模型理解这个函数用途的唯一依据。决策将用户查询和定义好的函数列表一起发送给LLM。LLM基于对用户意图的理解决定是否需要调用函数。如果需要它会选择一个最匹配的函数并生成调用该函数所需的参数。执行与回调开发者收到模型返回的结构化函数调用请求后在自己的代码中执行对应的真实函数如调用天气API获取结果。然后将这个结果作为新的消息再次发送给LLM让LLM结合函数执行的结果生成最终面向用户的自然语言回复。它的核心价值在于结构化输出将模型“天马行空”的自然语言生成约束到我们预先定义好的、机器可可靠解析的结构中。这是AI与外部系统数据库、API、内部服务实现稳定交互的前提。意图识别与路由模型充当了一个智能路由器的角色。用户说“订一张明天去上海的机票”和“上海明天天气怎么样”模型能自动识别意图并分别路由到book_flight和get_weather函数。上下文扩展通过函数执行模型获得了它本身训练数据之外的最新、最具体的信息如实时天气、股票价格、数据库查询结果极大地突破了其知识截止日期的限制。在实际编码中一个典型的Function Calling流程看起来是这样的以OpenAI API为例import openai import json # 1. 定义函数工具 tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气情况, # 描述是关键 parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京 上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位 } }, required: [location] } } } ] # 2. 第一次调用让模型决定是否调用及如何调用 response openai.chat.completions.create( modelgpt-4, messages[{role: user, content: 北京今天热吗}], toolstools, tool_choiceauto, # 让模型自动选择 ) message response.choices[0].message # 3. 检查模型是否决定调用函数 if message.tool_calls: tool_call message.tool_calls[0] function_name tool_call.function.name function_args json.loads(tool_call.function.arguments) # 4. 执行本地函数 if function_name get_current_weather: weather_result call_real_weather_api(function_args[location], function_args.get(unit, celsius)) # 5. 第二次调用将函数执行结果返回给模型让它生成最终回复 second_response openai.chat.completions.create( modelgpt-4, messages[ {role: user, content: 北京今天热吗}, message, # 包含模型工具调用的消息 { role: tool, content: json.dumps(weather_result), # 工具执行结果 tool_call_id: tool_call.id } ], ) final_answer second_response.choices[0].message.content print(final_answer) # 输出“北京今天天气晴朗气温28摄氏度比较炎热。”注意tool_choice参数非常有用。设为“auto”是让模型决定设为{“type”: “function”, “function”: {“name”: “xxx”}}可以强制模型使用特定工具设为“none”则禁止模型调用任何工具。这在控制交互流程时很重要。3. Tools对Function的封装与业务化抽象如果说Function Calling是“如何调用”那么Tools就是“调用什么”。在实践中Tools和Function在API层面经常是混用的例如OpenAI的API中tools参数里就包含type: “function”但概念上Tool是更高一层的抽象。一个Tool代表了一个完整的、可被AI使用的“能力”或“服务”。它通常包含一个清晰的名称和描述让AI知道这个工具是干什么的。输入参数的模式定义JSON Schema。实际的执行逻辑一个函数、一个API调用、一段脚本。可选的输出结果的模式定义。Tools的核心思想是“封装”和“组合”。一个复杂的业务操作比如“为用户预订会议室”可能背后需要多个Function的协作check_calendar_availability查日历、book_room预订房间、send_invitation_email发邮件。我们可以将这三个Function封装成一个更高阶的Tool叫做schedule_meeting。对于AI来说它只需要知道调用schedule_meeting这个工具并提供时间、参会人等参数而不需要关心内部复杂的执行流程。3.1 从Function到Tool设计模式的演进这种抽象带来了几个好处降低AI的认知负担AI不需要理解所有底层细节只需掌握更粗粒度的业务能力。提升可靠性与安全性复杂的、涉及多步骤或权限校验的逻辑被封装在Tool内部由开发者严格控制避免了AI直接操作敏感或危险的功能。促进复用设计良好的Tool可以在不同的AI应用Agent之间共享。目前主流的AI应用框架如LangChain、LlamaIndex都围绕“Tool”这个概念构建了丰富的生态。它们提供了大量预置的Tools如搜索引擎、维基百科、计算器、文件读写也使得开发者自定义Tool变得非常方便。例如在LangChain中定义一个Tool非常简单from langchain.tools import tool tool def search_company_info(company_name: str) - str: 根据公司名称查询其基本信息、最新财报摘要和行业新闻。 # 这里可以整合多个数据源企业数据库API、财经新闻API等 info query_internal_database(company_name) news fetch_financial_news(company_name) return f”公司简介{info}\n近期动态{news}” # 然后你可以将这个tool加入到Agent的“工具箱”中这时你的AI就拥有了“查询公司信息”这个业务能力。Tools的概念使得AI的能力从“通用函数调用”走向了“领域业务能力集成”。4. MCP与A2A智能体间的“通信协议”与“协作语言”当我们的AI应用从一个单一的、能调用几个工具的Agent发展为多个各司其职的Agent需要协同工作时新的问题出现了它们之间如何通信如何理解彼此传递的信息这就是MCPModel Context Protocol和A2AAgent-to-Agent这类协议要解决的问题。你可以把它们类比成计算机网络中的TCP/IP协议或者人类协作中的“工作语言”和“流程规范”。4.1 MCP为AI定义标准化的“上下文”接口MCP是由Anthropic等公司推动的一个开源协议。它的核心目标是标准化AI模型尤其是智能体与外部数据源、工具和服务之间的交互方式。在MCP的世界里一切外部资源数据库、API、文件系统、甚至其他AI服务都被抽象为“服务器”Server而AI模型或应用则是“客户端”Client。MCP定义了一套标准的“请求-响应”消息格式用于客户端发现服务器提供了哪些能力工具、调用这些能力、以及传输数据。为什么需要MCP在没有MCP之前每个AI应用框架LangChain, LlamaIndex、每个云服务商都可能用自己的一套方式去定义和调用Tools。这导致了严重的“供应商锁定”和集成碎片化。一个为LangChain写的Tool很难直接给LlamaIndex的Agent用。MCP试图成为这个领域的“USB标准”——只要你的工具服务遵循MCP协议暴露接口那么任何支持MCP协议的AI客户端无论底层是Claude、GPT还是开源模型都能即插即用地使用它。一个简化的MCP思维模型如下表所示角色职责类比MCP 客户端AI模型或应用。它向MCP服务器发送标准化的请求以获取数据或执行操作。你的电脑或手机MCP 服务器提供特定数据或能力的服务。它向客户端宣告自己有哪些“资源”如工具、数据源并处理客户端的调用请求。U盘、打印机、扫描仪等外设MCP 协议定义客户端与服务器之间通信的消息格式JSON-RPC over stdio/SSE。包括initialize,tools/list,callTool,readResource等标准方法。USB协议、蓝牙协议对于开发者而言如果你的工具想被最广泛的AI生态使用将其包装成一个MCP服务器是一个前瞻性的选择。这意味着你不再需要为OpenAI、Anthropic、LangChain等不同平台分别写适配器。4.2 A2A定义智能体如何“对话”与“委派”如果说MCP解决了AI与“物”工具、数据的交互标准那么A2AAgent-to-Agent则更侧重于解决AI与“AI”即多个智能体之间的交互问题。目前A2A更像一个概念和方向而非某个单一的官方协议其核心思想是制定智能体间通信的语义标准。在一个多智能体系统中可能有专门负责规划的“规划者”Planner、负责执行的“执行者”Executor、负责审核的“审核者”Checker。它们之间需要交换信息、传递任务、汇报结果。A2A协议需要定义消息格式智能体之间发送的消息应该包含哪些字段如发送者ID、接收者ID、消息类型、任务内容、优先级、上下文依赖等。通信原语基本的交互动作有哪些如delegate_task委派任务、request_info请求信息、report_result汇报结果、escalate_issue升级问题。协商机制当多个智能体对任务有不同意见时如何协商如基于置信度的投票、请求人类仲裁。例如一个基于A2A思想设计的简单任务委派消息可能长这样{ “message_id”: “task_123”, “from_agent”: “planner_agent”, “to_agent”: “research_agent”, “type”: “TASK_DELEGATION”, “content”: { “task”: “调研一下2024年新能源汽车电池的最新技术进展”, “expected_output_format”: “一份包含技术名称、原理简述、主要厂商和优缺点的Markdown表格”, “deadline”: “2024-05-20T18:00:00Z”, “context”: [“用户是资深行业分析师”, “需要用于内部技术路线评估报告”] } }MCP和A2A的关系它们处于不同的层面但可以协同工作。MCP更像是“基础设施层”的协议确保智能体能以统一的方式访问外部工具。而A2A是“应用层”或“协作层”的协议定义智能体间的业务逻辑交互。一个智能体在通过A2A协议接收到任务后很可能会通过MCP协议去调用各种工具来完成任务。5. Multi-Agent Systems基于分工与协作的复杂问题求解架构当我们拥有了能稳定调用工具的单个智能体Agent并定义了它们之间的通信协议A2A后构建多智能体系统Multi-Agent Systems, MAS就成为了解决复杂问题的自然选择。这不再是让一个“全能AI”处理所有事情而是组建一个各有所长的“AI团队”。5.2 多智能体系统的核心模式与设计考量在我的项目中多智能体系统通常遵循几种经典模式主从式Master-Worker一个“管理者”Agent负责接收用户请求、拆解任务、分派给不同的“工作者”Agent并汇总结果。这是最常见、最易实现的模式。平等协作式Peer-to-Peer多个能力对等的Agent通过协商共同完成任务。例如在辩论或创意生成场景中多个Agent可以扮演不同角色进行讨论。流水线式Pipeline任务像生产线一样流经多个Agent每个Agent完成特定工序。例如数据清洗Agent - 分析Agent - 报告生成Agent。市场竞标式Market-Based任务被发布多个Agent根据自身能力和成本进行“投标”由最合适的Agent中标执行。这适用于资源调度复杂的场景。设计一个多智能体系统你需要重点考虑以下几个问题角色与职责划分这是最关键的一步。根据任务复杂度你需要设计多少个Agent每个Agent的专长是什么例如检索专家、代码工程师、文案写手、审核员。划分的原则是“高内聚、低耦合”让每个Agent的职责尽可能单一、明确。通信与协调机制Agent之间如何传递信息和任务这就是前面提到的A2A协议要解决的问题。你需要定义消息格式、通信渠道如通过一个中央消息总线或直接点对点、以及冲突解决机制当两个Agent意见不一致时怎么办。共享记忆与上下文管理团队协作需要有“共同知识”。如何让所有Agent都能访问到必要的上下文如用户原始需求、历史对话、中间结果通常需要一个集中的“工作区”或“黑板”系统。流程控制与容错任务流程是固定的还是动态生成的如果一个Agent执行失败如何重试或切换备用方案是否需要引入“监督者”Agent来监控整个系统的运行状态成本与延迟多Agent意味着多次的LLM调用和网络通信这会显著增加成本和响应时间。需要在系统性能和成本之间做出权衡有时对于简单任务单个Agent反而更高效。一个简单的基于主从模式的多智能体系统代码框架可能如下所示概念性伪代码class MasterAgent: def __init__(self, worker_agents): self.workers worker_agents # 持有多个工作者Agent的实例 def handle_request(self, user_query): # 1. 规划拆解任务 subtasks self.plan(user_query) results [] for task in subtasks: # 2. 路由选择最合适的工作者 suitable_worker self.select_worker(task.type) # 3. 委派通过A2A格式发送任务 task_message create_a2a_message(self.id, suitable_worker.id, “TASK”, task.details) # 4. 执行与收集 result suitable_worker.execute(task_message) results.append(result) # 5. 汇总与生成最终答案 final_answer self.synthesize(results) return final_answer class WorkerAgent: def __init__(self, specialty, tools): self.specialty specialty # 如 “research”, “coding”, “writing” self.tools tools # 该Agent可用的Tools列表 def execute(self, task_message): # 1. 理解任务 # 2. 根据需要通过MCP或直接调用Tools # 3. 返回结果 pass6. Skills面向最终用户的、可复用的“AI能力包”最后我们来谈谈Skills。这是最接近终端用户的一层抽象。如果说Tools是开发者视角的“可调用能力”那么Skills就是用户或产品视角的“可复用解决方案”或“技能包”。一个Skill通常是一个封装好的、能完成特定复杂任务的AI应用或工作流。它内部可能包含了一个或多个Agent的协作集成了多个Tools并提供了一个简洁的交互接口如一个聊天指令、一个按钮、一个API端点。例如“数据分析师”Skill用户上传一个CSV文件并说“分析一下销售数据”这个Skill内部会触发数据清洗Agent、可视化分析Agent和报告生成Agent的协作流水线最终生成一份图文并茂的分析报告。“竞品调研”Skill用户输入一个产品名称Skill自动调用搜索引擎Tool、社交媒体监听Tool、财报解析Tool并由一个总结Agent生成一份竞品分析简报。“代码审查助手”Skill接收一段代码自动进行安全检查、风格检查、性能建议并生成修改意见。Skills的核心特点是“开箱即用”和“业务闭环”。用户不需要关心背后有多少个Agent、调用了哪些Tools、遵循什么协议他们只需要触发这个Skill就能得到一个完整的结果。在像ChatGPT的GPTs、微软的Copilot Studio、阿里的通义灵码等平台上用户能够自定义和分享的本质上就是一个个Skills。6.1 如何构建一个好的Skill从开发者的角度设计一个优秀的Skill需要考虑明确的输入输出Skill的边界要清晰。用户需要提供什么如一个主题、一个文件、一个URL。Skill会返回什么如一份报告、一段代码、一个总结。健壮的错误处理Skill内部流程可能很长任何一个环节出错如网络超时、API限流、意外输入都要有降级方案或友好的错误提示而不是整个崩溃。可配置性提供一些参数让用户微调Skill的行为。例如在“文章润色”Skill中可以让用户选择风格正式、口语化、长度精简、详细等。上下文感知好的Skill应该能记住在同一会话中与用户的交互历史使多次交互具有连贯性。易于集成Skill应该提供标准的接入方式比如一个Webhook、一个API、或一个可以被主流AI平台如Discord, Slack, 钉钉调用的插件。构建Skill的过程其实就是将前文提到的所有技术——Function Calling、Tools、Multi-Agent协作——进行产品化封装的过程。它是AI能力栈的顶端是价值最终交付给用户的形态。7. 实战指南如何为你的项目选择合适的技术层级面对这一整套技术栈新手很容易陷入“为了用而用”的陷阱。不是所有项目都需要Multi-Agent也不是所有工具都需要用MCP封装。下面这张决策表可以帮助你根据项目需求快速定位到合适的技术层级你的需求场景推荐技术层级理由与实例让AI能稳定地调用1-3个外部API或数据库Function Calling需求简单直接使用原生Function Calling API如OpenAI的tools参数即可。复杂度最低性能最好。例如聊天机器人查天气、查股价。需要为AI提供一系列3个不同领域的工具并希望统一管理Tools抽象层使用LangChain、LlamaIndex等框架的Tool抽象可以更好地组织、描述和调用工具集。例如一个内部知识库助手需要调用搜索、文档解析、邮件发送等多个工具。你正在构建一个供第三方AI应用调用的通用工具/数据服务MCP协议遵循MCP协议将你的服务暴露出来可以确保最大程度的兼容性未来可以被任何支持MCP的AI平台使用避免重复开发适配器。例如公司内部的客户关系管理系统CRMAPI。你要解决的任务非常复杂需要多个步骤、不同专业领域的判断Multi-Agent系统单一Agent难以处理需要多种思维模式如创意严谨审核的任务。通过多Agent分工协作可靠性和质量更高。例如自动化的全栈应用开发产品经理Agent写需求前端Agent写UI后端Agent写API测试Agent写用例。你想打造一个终端用户能直接使用的、功能完整的AI应用Skills将背后的技术复杂性完全封装提供一个傻瓜式的交互界面。这是产品化的最终形态。例如开发一个“小红书爆款标题生成器”Skill用户输入内容一键生成多个标题选项。你需要多个AI应用或智能体之间进行复杂的任务传递和状态同步A2A通信规范当Multi-Agent系统内部的交互变得复杂时需要自定义一套清晰的A2A消息格式和流程规则以确保协作有序。例如一个模拟公司决策的AI沙盘市场部、研发部、财务部Agent需要频繁协商。我个人的经验是从简单开始逐步演进。绝大多数项目都是从Function Calling或Tools起步。只有当单个Agent的逻辑变得过于臃肿、难以维护或者任务本质上就需要并行或分阶段处理时才考虑引入Multi-Agent。而MCP和A2A更多是在你需要构建平台、定义标准、或者集成非常异构的系统时才需要深入考虑。在技术选型上我建议优先使用成熟框架如LangChain提供的抽象它们已经很好地封装了Function Calling、Tools和多Agent协作的常见模式。在遇到框架无法满足的特定协议或性能要求时再考虑基于底层API进行定制。例如如果你需要极致的推理速度可能会直接使用模型的原始Function Calling接口并自己管理会话状态但如果你需要快速构建一个包含多种工具的原型LangChain几乎是最高效的选择。最后无论选择哪一层清晰的日志记录和可观测性都是至关重要的。你需要能清晰地追踪到用户的请求触发了哪个Function/Tool/Agent输入输出是什么调用链是怎样的耗时多少这不仅是调试和排错的需要也是理解你的AI系统实际工作方式、持续进行优化迭代的基础。 从Function Calling到多智能体：AI能力集成的技术栈演进与实践指南
1. 从“单打独斗”到“团队协作”AI能力集成的演进脉络如果你最近在关注AI应用开发尤其是大语言模型LLM的落地一定会被一堆新名词搞得眼花缭乱Function Calling、Tools、MCP、A2A、Multi-Agent、Skills……它们听起来都挺厉害但又好像有些重叠让人分不清边界。作为一个从早期API调用一路踩坑过来的开发者我深切感受到这不仅仅是几个新功能更代表了AI从“一个聪明的聊天机器人”向“一个能调用外部能力、甚至能自主协作的智能体”演进的关键路径。理解这些概念不是为了追新而是为了在构建真正有用的AI应用时能做出最合适的技术选型避免在错误的抽象层级上浪费精力。简单来说我们可以把这些概念看作一个能力栈。最底层是Function Calling它让LLM学会了“举手说我要调用某个函数”这是AI与外部世界交互的基石。往上走Tools是对Function的封装和抽象让AI能理解并选择“工具”来完成任务。再往上MCPModel Context Protocol和A2AAgent-to-Agent协议则是在定义AI之间、AI与工具之间如何“对话”和“协作”的规则。而Multi-Agent和Skills则是基于这些底层能力构建的更高层应用架构和业务抽象。今天我就结合自己的实践把这套“能力栈”给你彻底捋清楚让你明白每个层级解决什么问题以及在实际项目中该如何选择。2. Function Calling让大模型学会“举手发言”的底层协议要理解上面那一堆概念必须从Function Calling这个最基础的机制说起。在Function Calling出现之前我们想让GPT这样的模型去查天气、发邮件通常的做法是把需求描述和可能的API参数一起塞进提示词Prompt里指望模型能“猜”出我们想要它输出一个结构化的调用指令。这种方法极其脆弱输出格式不稳定解析起来也麻烦。Function Calling的引入彻底改变了游戏规则。它本质上是一套标准化的“请求-响应”协议。在请求侧开发者发给模型我们不再只是说“帮我查一下北京天气”而是明确地告诉模型“我这里有一个叫做get_current_weather的函数它的作用是查询天气它需要location和unit两个参数。” 模型的任务变成了理解用户的自然语言请求然后判断是否需要、以及需要调用哪个函数并以一个严格符合JSON Schema的结构把调用这个函数所需的参数返回给我们。2.1 Function Calling的工作机制与核心价值这个过程可以拆解为三步定义开发者预先定义好函数或工具的名称、描述和参数格式JSON Schema。描述至关重要它是模型理解这个函数用途的唯一依据。决策将用户查询和定义好的函数列表一起发送给LLM。LLM基于对用户意图的理解决定是否需要调用函数。如果需要它会选择一个最匹配的函数并生成调用该函数所需的参数。执行与回调开发者收到模型返回的结构化函数调用请求后在自己的代码中执行对应的真实函数如调用天气API获取结果。然后将这个结果作为新的消息再次发送给LLM让LLM结合函数执行的结果生成最终面向用户的自然语言回复。它的核心价值在于结构化输出将模型“天马行空”的自然语言生成约束到我们预先定义好的、机器可可靠解析的结构中。这是AI与外部系统数据库、API、内部服务实现稳定交互的前提。意图识别与路由模型充当了一个智能路由器的角色。用户说“订一张明天去上海的机票”和“上海明天天气怎么样”模型能自动识别意图并分别路由到book_flight和get_weather函数。上下文扩展通过函数执行模型获得了它本身训练数据之外的最新、最具体的信息如实时天气、股票价格、数据库查询结果极大地突破了其知识截止日期的限制。在实际编码中一个典型的Function Calling流程看起来是这样的以OpenAI API为例import openai import json # 1. 定义函数工具 tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气情况, # 描述是关键 parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京 上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位 } }, required: [location] } } } ] # 2. 第一次调用让模型决定是否调用及如何调用 response openai.chat.completions.create( modelgpt-4, messages[{role: user, content: 北京今天热吗}], toolstools, tool_choiceauto, # 让模型自动选择 ) message response.choices[0].message # 3. 检查模型是否决定调用函数 if message.tool_calls: tool_call message.tool_calls[0] function_name tool_call.function.name function_args json.loads(tool_call.function.arguments) # 4. 执行本地函数 if function_name get_current_weather: weather_result call_real_weather_api(function_args[location], function_args.get(unit, celsius)) # 5. 第二次调用将函数执行结果返回给模型让它生成最终回复 second_response openai.chat.completions.create( modelgpt-4, messages[ {role: user, content: 北京今天热吗}, message, # 包含模型工具调用的消息 { role: tool, content: json.dumps(weather_result), # 工具执行结果 tool_call_id: tool_call.id } ], ) final_answer second_response.choices[0].message.content print(final_answer) # 输出“北京今天天气晴朗气温28摄氏度比较炎热。”注意tool_choice参数非常有用。设为“auto”是让模型决定设为{“type”: “function”, “function”: {“name”: “xxx”}}可以强制模型使用特定工具设为“none”则禁止模型调用任何工具。这在控制交互流程时很重要。3. Tools对Function的封装与业务化抽象如果说Function Calling是“如何调用”那么Tools就是“调用什么”。在实践中Tools和Function在API层面经常是混用的例如OpenAI的API中tools参数里就包含type: “function”但概念上Tool是更高一层的抽象。一个Tool代表了一个完整的、可被AI使用的“能力”或“服务”。它通常包含一个清晰的名称和描述让AI知道这个工具是干什么的。输入参数的模式定义JSON Schema。实际的执行逻辑一个函数、一个API调用、一段脚本。可选的输出结果的模式定义。Tools的核心思想是“封装”和“组合”。一个复杂的业务操作比如“为用户预订会议室”可能背后需要多个Function的协作check_calendar_availability查日历、book_room预订房间、send_invitation_email发邮件。我们可以将这三个Function封装成一个更高阶的Tool叫做schedule_meeting。对于AI来说它只需要知道调用schedule_meeting这个工具并提供时间、参会人等参数而不需要关心内部复杂的执行流程。3.1 从Function到Tool设计模式的演进这种抽象带来了几个好处降低AI的认知负担AI不需要理解所有底层细节只需掌握更粗粒度的业务能力。提升可靠性与安全性复杂的、涉及多步骤或权限校验的逻辑被封装在Tool内部由开发者严格控制避免了AI直接操作敏感或危险的功能。促进复用设计良好的Tool可以在不同的AI应用Agent之间共享。目前主流的AI应用框架如LangChain、LlamaIndex都围绕“Tool”这个概念构建了丰富的生态。它们提供了大量预置的Tools如搜索引擎、维基百科、计算器、文件读写也使得开发者自定义Tool变得非常方便。例如在LangChain中定义一个Tool非常简单from langchain.tools import tool tool def search_company_info(company_name: str) - str: 根据公司名称查询其基本信息、最新财报摘要和行业新闻。 # 这里可以整合多个数据源企业数据库API、财经新闻API等 info query_internal_database(company_name) news fetch_financial_news(company_name) return f”公司简介{info}\n近期动态{news}” # 然后你可以将这个tool加入到Agent的“工具箱”中这时你的AI就拥有了“查询公司信息”这个业务能力。Tools的概念使得AI的能力从“通用函数调用”走向了“领域业务能力集成”。4. MCP与A2A智能体间的“通信协议”与“协作语言”当我们的AI应用从一个单一的、能调用几个工具的Agent发展为多个各司其职的Agent需要协同工作时新的问题出现了它们之间如何通信如何理解彼此传递的信息这就是MCPModel Context Protocol和A2AAgent-to-Agent这类协议要解决的问题。你可以把它们类比成计算机网络中的TCP/IP协议或者人类协作中的“工作语言”和“流程规范”。4.1 MCP为AI定义标准化的“上下文”接口MCP是由Anthropic等公司推动的一个开源协议。它的核心目标是标准化AI模型尤其是智能体与外部数据源、工具和服务之间的交互方式。在MCP的世界里一切外部资源数据库、API、文件系统、甚至其他AI服务都被抽象为“服务器”Server而AI模型或应用则是“客户端”Client。MCP定义了一套标准的“请求-响应”消息格式用于客户端发现服务器提供了哪些能力工具、调用这些能力、以及传输数据。为什么需要MCP在没有MCP之前每个AI应用框架LangChain, LlamaIndex、每个云服务商都可能用自己的一套方式去定义和调用Tools。这导致了严重的“供应商锁定”和集成碎片化。一个为LangChain写的Tool很难直接给LlamaIndex的Agent用。MCP试图成为这个领域的“USB标准”——只要你的工具服务遵循MCP协议暴露接口那么任何支持MCP协议的AI客户端无论底层是Claude、GPT还是开源模型都能即插即用地使用它。一个简化的MCP思维模型如下表所示角色职责类比MCP 客户端AI模型或应用。它向MCP服务器发送标准化的请求以获取数据或执行操作。你的电脑或手机MCP 服务器提供特定数据或能力的服务。它向客户端宣告自己有哪些“资源”如工具、数据源并处理客户端的调用请求。U盘、打印机、扫描仪等外设MCP 协议定义客户端与服务器之间通信的消息格式JSON-RPC over stdio/SSE。包括initialize,tools/list,callTool,readResource等标准方法。USB协议、蓝牙协议对于开发者而言如果你的工具想被最广泛的AI生态使用将其包装成一个MCP服务器是一个前瞻性的选择。这意味着你不再需要为OpenAI、Anthropic、LangChain等不同平台分别写适配器。4.2 A2A定义智能体如何“对话”与“委派”如果说MCP解决了AI与“物”工具、数据的交互标准那么A2AAgent-to-Agent则更侧重于解决AI与“AI”即多个智能体之间的交互问题。目前A2A更像一个概念和方向而非某个单一的官方协议其核心思想是制定智能体间通信的语义标准。在一个多智能体系统中可能有专门负责规划的“规划者”Planner、负责执行的“执行者”Executor、负责审核的“审核者”Checker。它们之间需要交换信息、传递任务、汇报结果。A2A协议需要定义消息格式智能体之间发送的消息应该包含哪些字段如发送者ID、接收者ID、消息类型、任务内容、优先级、上下文依赖等。通信原语基本的交互动作有哪些如delegate_task委派任务、request_info请求信息、report_result汇报结果、escalate_issue升级问题。协商机制当多个智能体对任务有不同意见时如何协商如基于置信度的投票、请求人类仲裁。例如一个基于A2A思想设计的简单任务委派消息可能长这样{ “message_id”: “task_123”, “from_agent”: “planner_agent”, “to_agent”: “research_agent”, “type”: “TASK_DELEGATION”, “content”: { “task”: “调研一下2024年新能源汽车电池的最新技术进展”, “expected_output_format”: “一份包含技术名称、原理简述、主要厂商和优缺点的Markdown表格”, “deadline”: “2024-05-20T18:00:00Z”, “context”: [“用户是资深行业分析师”, “需要用于内部技术路线评估报告”] } }MCP和A2A的关系它们处于不同的层面但可以协同工作。MCP更像是“基础设施层”的协议确保智能体能以统一的方式访问外部工具。而A2A是“应用层”或“协作层”的协议定义智能体间的业务逻辑交互。一个智能体在通过A2A协议接收到任务后很可能会通过MCP协议去调用各种工具来完成任务。5. Multi-Agent Systems基于分工与协作的复杂问题求解架构当我们拥有了能稳定调用工具的单个智能体Agent并定义了它们之间的通信协议A2A后构建多智能体系统Multi-Agent Systems, MAS就成为了解决复杂问题的自然选择。这不再是让一个“全能AI”处理所有事情而是组建一个各有所长的“AI团队”。5.2 多智能体系统的核心模式与设计考量在我的项目中多智能体系统通常遵循几种经典模式主从式Master-Worker一个“管理者”Agent负责接收用户请求、拆解任务、分派给不同的“工作者”Agent并汇总结果。这是最常见、最易实现的模式。平等协作式Peer-to-Peer多个能力对等的Agent通过协商共同完成任务。例如在辩论或创意生成场景中多个Agent可以扮演不同角色进行讨论。流水线式Pipeline任务像生产线一样流经多个Agent每个Agent完成特定工序。例如数据清洗Agent - 分析Agent - 报告生成Agent。市场竞标式Market-Based任务被发布多个Agent根据自身能力和成本进行“投标”由最合适的Agent中标执行。这适用于资源调度复杂的场景。设计一个多智能体系统你需要重点考虑以下几个问题角色与职责划分这是最关键的一步。根据任务复杂度你需要设计多少个Agent每个Agent的专长是什么例如检索专家、代码工程师、文案写手、审核员。划分的原则是“高内聚、低耦合”让每个Agent的职责尽可能单一、明确。通信与协调机制Agent之间如何传递信息和任务这就是前面提到的A2A协议要解决的问题。你需要定义消息格式、通信渠道如通过一个中央消息总线或直接点对点、以及冲突解决机制当两个Agent意见不一致时怎么办。共享记忆与上下文管理团队协作需要有“共同知识”。如何让所有Agent都能访问到必要的上下文如用户原始需求、历史对话、中间结果通常需要一个集中的“工作区”或“黑板”系统。流程控制与容错任务流程是固定的还是动态生成的如果一个Agent执行失败如何重试或切换备用方案是否需要引入“监督者”Agent来监控整个系统的运行状态成本与延迟多Agent意味着多次的LLM调用和网络通信这会显著增加成本和响应时间。需要在系统性能和成本之间做出权衡有时对于简单任务单个Agent反而更高效。一个简单的基于主从模式的多智能体系统代码框架可能如下所示概念性伪代码class MasterAgent: def __init__(self, worker_agents): self.workers worker_agents # 持有多个工作者Agent的实例 def handle_request(self, user_query): # 1. 规划拆解任务 subtasks self.plan(user_query) results [] for task in subtasks: # 2. 路由选择最合适的工作者 suitable_worker self.select_worker(task.type) # 3. 委派通过A2A格式发送任务 task_message create_a2a_message(self.id, suitable_worker.id, “TASK”, task.details) # 4. 执行与收集 result suitable_worker.execute(task_message) results.append(result) # 5. 汇总与生成最终答案 final_answer self.synthesize(results) return final_answer class WorkerAgent: def __init__(self, specialty, tools): self.specialty specialty # 如 “research”, “coding”, “writing” self.tools tools # 该Agent可用的Tools列表 def execute(self, task_message): # 1. 理解任务 # 2. 根据需要通过MCP或直接调用Tools # 3. 返回结果 pass6. Skills面向最终用户的、可复用的“AI能力包”最后我们来谈谈Skills。这是最接近终端用户的一层抽象。如果说Tools是开发者视角的“可调用能力”那么Skills就是用户或产品视角的“可复用解决方案”或“技能包”。一个Skill通常是一个封装好的、能完成特定复杂任务的AI应用或工作流。它内部可能包含了一个或多个Agent的协作集成了多个Tools并提供了一个简洁的交互接口如一个聊天指令、一个按钮、一个API端点。例如“数据分析师”Skill用户上传一个CSV文件并说“分析一下销售数据”这个Skill内部会触发数据清洗Agent、可视化分析Agent和报告生成Agent的协作流水线最终生成一份图文并茂的分析报告。“竞品调研”Skill用户输入一个产品名称Skill自动调用搜索引擎Tool、社交媒体监听Tool、财报解析Tool并由一个总结Agent生成一份竞品分析简报。“代码审查助手”Skill接收一段代码自动进行安全检查、风格检查、性能建议并生成修改意见。Skills的核心特点是“开箱即用”和“业务闭环”。用户不需要关心背后有多少个Agent、调用了哪些Tools、遵循什么协议他们只需要触发这个Skill就能得到一个完整的结果。在像ChatGPT的GPTs、微软的Copilot Studio、阿里的通义灵码等平台上用户能够自定义和分享的本质上就是一个个Skills。6.1 如何构建一个好的Skill从开发者的角度设计一个优秀的Skill需要考虑明确的输入输出Skill的边界要清晰。用户需要提供什么如一个主题、一个文件、一个URL。Skill会返回什么如一份报告、一段代码、一个总结。健壮的错误处理Skill内部流程可能很长任何一个环节出错如网络超时、API限流、意外输入都要有降级方案或友好的错误提示而不是整个崩溃。可配置性提供一些参数让用户微调Skill的行为。例如在“文章润色”Skill中可以让用户选择风格正式、口语化、长度精简、详细等。上下文感知好的Skill应该能记住在同一会话中与用户的交互历史使多次交互具有连贯性。易于集成Skill应该提供标准的接入方式比如一个Webhook、一个API、或一个可以被主流AI平台如Discord, Slack, 钉钉调用的插件。构建Skill的过程其实就是将前文提到的所有技术——Function Calling、Tools、Multi-Agent协作——进行产品化封装的过程。它是AI能力栈的顶端是价值最终交付给用户的形态。7. 实战指南如何为你的项目选择合适的技术层级面对这一整套技术栈新手很容易陷入“为了用而用”的陷阱。不是所有项目都需要Multi-Agent也不是所有工具都需要用MCP封装。下面这张决策表可以帮助你根据项目需求快速定位到合适的技术层级你的需求场景推荐技术层级理由与实例让AI能稳定地调用1-3个外部API或数据库Function Calling需求简单直接使用原生Function Calling API如OpenAI的tools参数即可。复杂度最低性能最好。例如聊天机器人查天气、查股价。需要为AI提供一系列3个不同领域的工具并希望统一管理Tools抽象层使用LangChain、LlamaIndex等框架的Tool抽象可以更好地组织、描述和调用工具集。例如一个内部知识库助手需要调用搜索、文档解析、邮件发送等多个工具。你正在构建一个供第三方AI应用调用的通用工具/数据服务MCP协议遵循MCP协议将你的服务暴露出来可以确保最大程度的兼容性未来可以被任何支持MCP的AI平台使用避免重复开发适配器。例如公司内部的客户关系管理系统CRMAPI。你要解决的任务非常复杂需要多个步骤、不同专业领域的判断Multi-Agent系统单一Agent难以处理需要多种思维模式如创意严谨审核的任务。通过多Agent分工协作可靠性和质量更高。例如自动化的全栈应用开发产品经理Agent写需求前端Agent写UI后端Agent写API测试Agent写用例。你想打造一个终端用户能直接使用的、功能完整的AI应用Skills将背后的技术复杂性完全封装提供一个傻瓜式的交互界面。这是产品化的最终形态。例如开发一个“小红书爆款标题生成器”Skill用户输入内容一键生成多个标题选项。你需要多个AI应用或智能体之间进行复杂的任务传递和状态同步A2A通信规范当Multi-Agent系统内部的交互变得复杂时需要自定义一套清晰的A2A消息格式和流程规则以确保协作有序。例如一个模拟公司决策的AI沙盘市场部、研发部、财务部Agent需要频繁协商。我个人的经验是从简单开始逐步演进。绝大多数项目都是从Function Calling或Tools起步。只有当单个Agent的逻辑变得过于臃肿、难以维护或者任务本质上就需要并行或分阶段处理时才考虑引入Multi-Agent。而MCP和A2A更多是在你需要构建平台、定义标准、或者集成非常异构的系统时才需要深入考虑。在技术选型上我建议优先使用成熟框架如LangChain提供的抽象它们已经很好地封装了Function Calling、Tools和多Agent协作的常见模式。在遇到框架无法满足的特定协议或性能要求时再考虑基于底层API进行定制。例如如果你需要极致的推理速度可能会直接使用模型的原始Function Calling接口并自己管理会话状态但如果你需要快速构建一个包含多种工具的原型LangChain几乎是最高效的选择。最后无论选择哪一层清晰的日志记录和可观测性都是至关重要的。你需要能清晰地追踪到用户的请求触发了哪个Function/Tool/Agent输入输出是什么调用链是怎样的耗时多少这不仅是调试和排错的需要也是理解你的AI系统实际工作方式、持续进行优化迭代的基础。