AI Agent工具调用四范式Function Calling / MCP / CLI / Skills 全景对比与选型指南附代码一句话总结: AI Agent调用外部工具主要有四种范式——Function Calling代码级集成、MCP协议级集成、CLI命令行管道、Skills知识编排——它们不是谁取代谁的关系而是在不同场景下各有所长生产环境的最佳实践是分层混合架构。适合谁: 正在设计AI Agent架构的工程师、技术负责人以及困惑该用Function Calling还是MCP的开发者。你能学到: 1. 四种范式的核心原理与本质区别2. 同一场景下四种方案的代码级对比3. 生产级选型决策树4. 混合架构的设计思路与伪代码实现。验证环境: Python 3.10本文代码基于OpenAI Function Calling规范、MCP协议2025-2026版本CLI示例基于Linux/macOS Shell环境均为概念性演示代码。文章目录AI Agent工具调用四范式Function Calling / MCP / CLI / Skills 全景对比与选型指南附代码一、背景MCP已死CLI当立之争二、四种范式是什么一句话本质三、四范式核心对比表四、代码实战同一场景四种方案4.1 方案一Function Calling代码级集成4.2 方案二MCP协议级集成4.3 方案三CLI命令行管道4.4 方案四Skills知识编排层五、不只是四种选择混合架构才是答案5.1 为什么需要混合5.2 三层混合架构5.3 混合架构伪代码六、前沿融合动态6.1 Agent框架原生融合6.2 工具化粘合MCPorter6.3 MCP协议持续演进七、选型决策树八、生产环境注意事项九、总结阅读导航本文约18分钟阅读。建议先浏览「三、四范式核心对比表」建立整体认知再按需深入代码实现。如果只想看选型结论跳到「七、选型决策树」。一、背景MCP已死CLI当立之争2025-2026年AI Agent社区爆发了一场激烈争论“MCP已死CLI当立”。这个观点的引爆点是Perplexity CTO Denis Yarats公开表示倾向APICLI架构而非MCP引发了广泛讨论。背后的核心逻辑击中了MCP的三个痛点Token成本过高MCP会把所有工具的定义名称、参数描述一次性塞进上下文窗口。接10个服务几千Token就没了。社区有实测案例显示在复杂分析任务中MCP调用的Token消耗和耗时显著高于CLI方案有报告称差距可达数倍具体数值取决于任务复杂度和工具数量。可组合性差CLI可以配合jq、grep等工具像搭乐高一样组合使用。而MCP是固定的API接口遇到复杂问题只能通过多次调用变相实现。LLM天然精通CLI海量Linux手册、Stack Overflow问答让LLM对CLI命令烂熟于心。但深入分析后会发现现实远比谁取代谁复杂。MCP在企业级安全治理、非开发者场景中有不可替代的价值。更关键的是行业正在走向四种范式融合——Function Calling、MCP、CLI、Skills各司其职协同工作。本文用同一个业务场景把四种范式和混合架构的代码放在一起对比帮你一眼看透本质区别。二、四种范式是什么一句话本质范式一句话本质比喻Function Calling工具是代码里写死的你帮AI挑好工具递过去MCP工具是协议自动发现的AI自己去工具架上拿CLI工具是AI本来就会的AI撸起袖子直接干因为它学过Skills流程是人类预先定义的给AI一本操作手册照着做三、四范式核心对比表维度Function CallingMCPCLISkills核心逻辑结构化API调用协议级服务发现文本命令与Shell组合Markdown流程编排工具在哪硬编码在主程序独立Server进程系统已安装的命令行工具可复用的知识文档AI怎么知道工具每次请求带tools列表协议自动发现AI训练数据中已有按需加载Skill文档新增工具成本改代码重新部署改Server重启无需改任何代码更新Skill文档复杂任务处理多次AI往返多次AI往返一次Shell组合完成一次流程串行完成Token消耗高工具定义反复传高工具定义塞上下文极低零工具定义低仅加载相关Skill安全治理代码层处理OAuth精细化权限控制本地Token粗放由底层工具决定用户门槛低对话即可低OAuth网页授权高需懂命令行低对话即可可解释性差黑盒决策差黑盒决策差脚本难读好流程可见适合场景工具5个快速原型企业级多工具集成数据处理、系统运维合规场景、固定流程四、代码实战同一场景四种方案用一个企业运维告警处理场景把四种方案的代码放在一起对比。场景描述用户说帮我查一下昨晚服务器CPU飙高的事分析原因然后发个告警总结邮件给团队并把修复方案记录到知识库。4.1 方案一Function Calling代码级集成# 所有工具硬编码在主程序 defquery_metrics(server_ip:str,time_range:str)-dict:查询服务器监控指标# 调用监控API返回CPU、内存等指标return{cpu:85%,time:02:00-03:00,memory:92%}defanalyze_logs(server_ip:str,keyword:str)-dict:分析服务器错误日志# 调用日志API返回关键字匹配的错误条目return{errors:[OOM killer invoked,connection timeout]}defsend_email(team:str,subject:str,body:str)-dict:发送邮件# 调用邮件APIreturn{status:sent,to:team}defsave_to_kb(content:str,tags:list)-dict:保存到知识库# 调用知识库APIreturn{id:kb_001}# 注册给AI tools[{type:function,function:{name:query_metrics,description:查询服务器监控指标CPU、内存等,parameters:{type:object,properties:{server_ip:{type:string,description:服务器IP},time_range:{type:string,description:时间范围如last24h}}}}},{type:function,function:{name:analyze_logs,description:分析服务器错误日志,parameters:{type:object,properties:{server_ip:{type:string},keyword:{type:string}}}}},# send_email 和 save_to_kb 类似省略...]# 主流程 defrun_agent(user_input):Function Calling主流程多轮AI往返完成串行任务。messages[{role:user,content:user_input}]# 第1轮AI决定调用query_metricsresponseclient.chat.completions.create(modelgpt-4,messagesmessages,toolstools)metricscall_tool(response)# 硬编码if-else分发# 第2轮AI决定调用analyze_logsmessages.append({role:assistant,content:f指标结果{metrics}})response2client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)logscall_tool(response2)# 第3轮AI判断根因messages.append({role:assistant,content:f日志结果{logs}})response3client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)# 第4轮发邮件response4client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)call_tool(response4)# 第5轮存知识库response5client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)call_tool(response5)return处理完成特点分析主程序完全控制工具逻辑开发简单直接5轮AI往返 高延迟 高Token消耗每加一个新工具要改代码、加if-else、重新部署工具定义随每次请求反复传给AI浪费Token4.2 方案二MCP协议级集成Step 1 — MCP Server独立进程# mcp_server.py # 基于官方MCP Python SDKFastMCP# 安装pip install mcp[cli]frommcp.server.fastmcpimportFastMCP mcpFastMCP(ops-tools)mcp.tool()defquery_metrics(server_ip:str,time_range:str)-dict:查询服务器监控指标CPU、内存等return{cpu:85%,time:02:00-03:00,memory:92%}mcp.tool()defanalyze_logs(server_ip:str,keyword:str)-dict:分析服务器错误日志返回匹配的错误条目return{errors:[OOM killer invoked,connection timeout]}mcp.tool()defsend_email(team:str,subject:str,body:str)-dict:发送邮件给指定团队return{status:sent,to:team}mcp.tool()defsave_to_kb(content:str,tags:list)-dict:保存处理记录到知识库return{id:kb_001}if__name____main__:mcp.run()# 独立进程持续运行Step 2 — AI客户端主程序概念性伪代码# main.py # MCP客户端连接逻辑为概念性演示实际开发参考官方SDK文档frommcpimportClientSessionfromopenaiimportOpenAIimportasyncio llmOpenAI()asyncdefrun_agent(user_input):MCP主流程工具独立部署AI自动发现。# 连接MCP Server像插U盘一样即插即用asyncwithClientSession.connect(mcp_server.py)assession:# AI自动发现工具无需手动定义tools列表toolsawaitsession.list_tools()# 自动拿到[query_metrics, ...]messages[{role:user,content:user_input}]# 仍然需要多轮AI调用每个工具一步whileTrue:responsellm.chat.completions.create(modelgpt-4,messagesmessages,toolstools)ifnotresponse.tool_calls:break# AI认为任务完成# 统一调度无需if-else硬编码分发forcallinresponse.tool_calls:resultawaitsession.call_tool(call.name,**call.arguments)messages.append({role:tool,content:result})return处理完成特点分析工具独立部署新增工具无需改主程序主程序自动感知仍然是多轮AI往返Token消耗和延迟问题未解决协议解析有额外开销OAuth授权适合企业级安全管控4.3 方案三CLI命令行管道# AI直接生成Shell脚本一次执行 importsubprocess# AI根据用户问题一次性生成完整脚本cli_script #!/bin/bash # 1. 查CPU指标使用curl jq解析JSON cpu_data$(curl -s http://monitor.api/metrics?server10.0.1.5timelast24h \\ | jq .cpu_avg) # 2. 分析日志使用grep过滤 awk提取 uniq统计 error_logs$(grep ERROR /var/log/syslog \\ | awk {print $5} \\ | sort | uniq -c | sort -rn) # 3. 判断根因 if [ $cpu_data -gt 80 ]; then root_causeCPU飙高由OOM引起 suggestion建议扩容内存至16G else root_cause正常波动 suggestion持续观察 fi # 4. 发邮件使用mail命令 echo -e CPU: ${cpu_data}\\n根因: ${root_cause}\\n建议: ${suggestion} \\ | mail -s [告警] CPU异常分析报告 teamcompany.com # 5. 存知识库使用curl POST curl -X POST http://kb.api/save \\ -H Content-Type: application/json \\ -d {\\content\\: \\${root_cause}\\, \\tags\\: [\\告警\\,\\CPU\\]} # 一次Shell调用完成所有任务resultsubprocess.run(cli_script,shellTrue,capture_outputTrue,textTrue)特点分析一次调用完成所有任务无需多轮AI往返极低Token消耗——工具定义不在上下文中AI直接生成命令无限组合能力管道|、jq、grep、awk任意拼接需要AI懂Shell语法好在LLM训练数据丰富权限管理弱依赖本地环境变量普通用户不会用命令行4.4 方案四Skills知识编排层Step 1 — 编写Skill文档!-- skill_ops_alert.md -- # 运维告警处理技能 ## 触发条件 用户提到告警、CPU飙高、服务器问题、分析原因 ## 执行步骤 1. 使用工具 query_metrics 查询目标服务器CPU指标参数server_ip, time_rangelast24h 2. 如果CPU 80%使用 analyze_logs 关键字OOM和timeout 3. 根据日志结果判断根因 - OOM killer → 结论内存不足建议扩容内存 - connection timeout → 结论网络超时建议检查防火墙规则 4. 生成告警总结包含时间、CPU峰值、根因、修复建议 5. 调用 send_email 发给运维团队subject含[告警]前缀 6. 调用 save_to_kb 保存处理记录tags: [告警, CPU, {{server_ip}}] ## 输出格式 邮件正文使用Markdown表格包含时间 | CPU峰值 | 根因 | 建议 ## 注意事项 - 如果无法确定server_ip先追问用户 - 邮件正文需包含具体的数值不要用模糊描述Step 2 — AI按Skill执行defrun_skill(user_input):Skills模式AI按预定义流程执行不自由发挥。# 1. 按需加载Skill不占上下文skillload_skill(ops_alert.md)# 2. AI严格按Skill步骤执行forstepinskill.steps:tool_namestep.extract_tool()# 提取工具名argsstep.extract_args(user_input)# 提取参数resultcall_tool(tool_name,args)# 底层可以是MCP或Function Callingifstep.has_condition():# 条件分支如CPU80%should_continuestep.evaluate(result)ifnotshould_continue:breakreturn按规范完成处理特点分析流程可控不会出现AI自由发挥导致的意外操作上下文轻量Skill按需加载不像MCP把所有工具定义塞进去可维护性强改流程只需改Markdown文档无需改代码需要预定义Skill对全新场景不够灵活五、不只是四种选择混合架构才是答案真实生产环境几乎不会只用一种范式。行业趋势是分层混合在正确的地方用正确的工具。5.1 为什么需要混合业界评测如Arize AI等Agent可观测性平台的实测分析给出了一个有启发的结论真实世界中的智能体多种范式都在用。原因很简单CLI效率最高但安全治理弱MCP治理最强但Token成本高Function Calling最简单但扩展性差Skills最可控但灵活性不足没有任何一种范式能同时满足效率、安全、灵活、可控四个维度。5.2 三层混合架构用户输入 → 意图识别层判断走哪条路径 ↓ ┌─────────┼─────────┐ ↓ ↓ ↓ 简单查询 复杂自动化 固定合规流程 ↓ ↓ ↓ Function CLI管道组合 Skills Calling (一次完成) ↓ ↓ ↓ 调用底层工具 └─────────┼───── (CLI/MCP) ↓ 统一工具执行层 (MCP管理企业服务 CLI处理本地任务)5.3 混合架构伪代码defsmart_agent(user_input):混合架构根据任务类型智能选择最优范式。# 1. 意图识别判断任务类型ifis_simple_query(user_input):# 简单查询 → Function Calling低门槛、快速响应returnfunction_call_flow(user_input)elifhas_fixed_process(user_input):# 合规流程如发工资单、运维告警→ Skills流程可控skillload_skill(match_skill(user_input))returnexecute_skill(skill)# 底层工具用MCPelifis_complex_automation(user_input):# 数据分析、日志处理 → CLI管道组合一次完成returncli_pipeline(user_input)else:# 开放式任务 → Agent框架MCP 动态决策returnagent_with_mcp(user_input)# 具体案例运维告警用混合方案defops_alert_hybrid(user_input):运维告警场景的混合实现。# 步骤1查指标 → 用CLI省Token一次curl搞定cpu_datasubprocess.run(curl -s http://monitor.api/metrics | jq .cpu_avg,shellTrue,capture_outputTrue,textTrue).stdout.strip()# 步骤2分析日志 → 用CLIgrep awk组合效率最高errorssubprocess.run(grep ERROR /var/log/syslog | awk {print $5} | sort | uniq -c,shellTrue,capture_outputTrue,textTrue).stdout.strip()# 步骤3根因判断 → AI推理LLM擅长root_causellm.analyze(fCPU{cpu_data}, errors{errors})# 步骤4发邮件 → 用MCP企业邮件服务需要OAuth鉴权mcp_client.call_tool(send_email,teamopscompany.com,subject[告警] CPU异常分析,bodyroot_cause.summary)# 步骤5存知识库 → 用MCP企业知识库需要权限管控mcp_client.call_tool(save_to_kb,contentroot_cause.detail,tags[告警,CPU,root_cause.server_ip])return处理完成行业案例佐证Google的gemini-cli就是混合架构的典型实现——以CLI为交互界面内置工具和MCP外部服务器统一注册到工具表Agent通过ReAct循环智能调度。六、前沿融合动态除了手动混合行业还在推进更深层的范式融合6.1 Agent框架原生融合新一代框架如Microsoft Agent Framework 1.0直接把多范式融合做到架构层模式适用任务工具调用方式Workflow工作流确定性任务人类控制流程LLM只负责其中一步Agent智能体开放式任务LLM自主决策、循环调用工具Skills技能复杂流程把操作手册写成MarkdownAI按需加载执行这种框架能在Workflow和Agent之间灵活切换Hybrid模式先走Workflow提取结构化意图再交给Agent处理多步推理。6.2 工具化粘合MCPorterMCPorter是一个实用的缝合项目直接把MCP服务器编译成CLI工具供AI调用。这解决了两个痛点给MCP减负AI调用轻量级CLI不在上下文中加载庞大的MCP模式定义大幅节省Token打通生态让MCP服务也能享受CLI的可组合性优势6.3 MCP协议持续演进⚠️时效性提示MCP协议在2025-2026年持续迭代。本文基于2025-2026年版本讨论后续版本可能有API变更请关注MCP官方规范。MCP协议在2025-2026年期间持续迭代针对企业大规模部署场景进行了重大升级包括OAuth鉴权增强、性能优化等进一步巩固了其在企业级安全治理中的位置。七、选型决策树你的场景是 │ ├─ 工具少5个快速验证想法 │ └── → Function Calling ✅ │ 最快上手但扩展性差 │ ├─ 企业级多系统集成需安全治理 │ └── → MCP ✅ │ OAuth鉴权 标准化接口 │ 但复杂数据处理可能还要CLI补充 │ ├─ 数据处理、日志分析、系统运维、自动化脚本 │ └── → CLI ✅ │ 成本最低、效率最高、组合最灵活 │ 但需要开发者环境 权限管理弱 │ ├─ 合规场景、固定流程、审计要求 │ └── → Skills ✅ │ 流程可控、可解释性强 │ 但需预定义新场景不灵活 │ └─ 生产级Agent系统 └── → 混合架构 ✅ CLI做本地执行 MCP管企业服务 Skills控合规流程八、生产环境注意事项⚠️重要提示本文代码为概念性演示生产环境直接使用需要额外处理以下问题。维度本文代码生产环境要求错误处理无try-catch每个工具调用必须有超时、重试、降级策略敏感信息硬编码server_ip通过环境变量或密钥管理服务注入并发控制串行执行高频场景需考虑工具调用的并发和队列日志审计无日志企业环境必须记录每次工具调用的输入输出权限最小化全权限MCP需配置最小权限集CLI需沙箱隔离CLI安全性shellTrue生产环境禁用shellTrue改用参数化调用避免注入回滚机制无知识库写入、邮件发送等操作需支持回滚一句话建议先用Function Calling验证想法遇到瓶颈再引入MCP或CLI最后用Skills固化成熟流程——渐进式架构演进比一步到位更务实。九、总结回到谁取代谁的争论答案已经很清晰范式核心定位不可替代的场景Function Calling快速原型工具工具少、变化快、快速验证MCP企业级服务契约多团队协作、安全审计、OAuth治理CLI高效原生执行数据处理、日志分析、系统运维Skills可控流程编排合规审计、固定SOP、可解释性要求一个健壮的AI Agent架构应该分为三层服务连接层MCP提供安全、标准化的外部能力入口工具执行层有CLI就用CLI最高效没有就封装成CLI供MCP调用知识编排层Skills坐镇顶层根据任务灵活调用下层的MCP或CLIMCP是服务契约管接入和安全Skills是编排蓝图管流程和知识CLI是原生工具管执行效率。三者加上Function Calling不是对手而是队友。你在实际项目中用的是哪种范式有没有遇到过用错了范式导致成本爆炸的教训欢迎在评论区分享你的真实案例——比如一开始用MCP处理日志分析Token费用一个月涨了5倍后来换成CLI管道一次搞定——我会持续整理后续出一篇Agent工具调用选型翻车合集。如果这篇帮你理清了四种范式的边界和选型逻辑欢迎点赞 收藏。下次做Agent架构评审时翻出那张选型对比表——“这个场景真的需要MCP吗还是CLI就够了”——一分钟就能避免过度设计。相关阅读MCP协议实战用Python 5分钟搭建你的第一个MCP Server附完整代码世界模型AI Agent从概念到选型的完整指南GB/Z 185《人工智能 智能体互联》系列标准核心内容梳理
AI Agent工具调用四范式Function Calling / MCP / CLI / Skills 全景对比与选型指南附代码一句话总结: AI Agent调用外部工具主要有四种范式——Function Calling代码级集成、MCP协议级集成、CLI命令行管道、Skills知识编排——它们不是谁取代谁的关系而是在不同场景下各有所长生产环境的最佳实践是分层混合架构。适合谁: 正在设计AI Agent架构的工程师、技术负责人以及困惑该用Function Calling还是MCP的开发者。你能学到: 1. 四种范式的核心原理与本质区别2. 同一场景下四种方案的代码级对比3. 生产级选型决策树4. 混合架构的设计思路与伪代码实现。验证环境: Python 3.10本文代码基于OpenAI Function Calling规范、MCP协议2025-2026版本CLI示例基于Linux/macOS Shell环境均为概念性演示代码。文章目录AI Agent工具调用四范式Function Calling / MCP / CLI / Skills 全景对比与选型指南附代码一、背景MCP已死CLI当立之争二、四种范式是什么一句话本质三、四范式核心对比表四、代码实战同一场景四种方案4.1 方案一Function Calling代码级集成4.2 方案二MCP协议级集成4.3 方案三CLI命令行管道4.4 方案四Skills知识编排层五、不只是四种选择混合架构才是答案5.1 为什么需要混合5.2 三层混合架构5.3 混合架构伪代码六、前沿融合动态6.1 Agent框架原生融合6.2 工具化粘合MCPorter6.3 MCP协议持续演进七、选型决策树八、生产环境注意事项九、总结阅读导航本文约18分钟阅读。建议先浏览「三、四范式核心对比表」建立整体认知再按需深入代码实现。如果只想看选型结论跳到「七、选型决策树」。一、背景MCP已死CLI当立之争2025-2026年AI Agent社区爆发了一场激烈争论“MCP已死CLI当立”。这个观点的引爆点是Perplexity CTO Denis Yarats公开表示倾向APICLI架构而非MCP引发了广泛讨论。背后的核心逻辑击中了MCP的三个痛点Token成本过高MCP会把所有工具的定义名称、参数描述一次性塞进上下文窗口。接10个服务几千Token就没了。社区有实测案例显示在复杂分析任务中MCP调用的Token消耗和耗时显著高于CLI方案有报告称差距可达数倍具体数值取决于任务复杂度和工具数量。可组合性差CLI可以配合jq、grep等工具像搭乐高一样组合使用。而MCP是固定的API接口遇到复杂问题只能通过多次调用变相实现。LLM天然精通CLI海量Linux手册、Stack Overflow问答让LLM对CLI命令烂熟于心。但深入分析后会发现现实远比谁取代谁复杂。MCP在企业级安全治理、非开发者场景中有不可替代的价值。更关键的是行业正在走向四种范式融合——Function Calling、MCP、CLI、Skills各司其职协同工作。本文用同一个业务场景把四种范式和混合架构的代码放在一起对比帮你一眼看透本质区别。二、四种范式是什么一句话本质范式一句话本质比喻Function Calling工具是代码里写死的你帮AI挑好工具递过去MCP工具是协议自动发现的AI自己去工具架上拿CLI工具是AI本来就会的AI撸起袖子直接干因为它学过Skills流程是人类预先定义的给AI一本操作手册照着做三、四范式核心对比表维度Function CallingMCPCLISkills核心逻辑结构化API调用协议级服务发现文本命令与Shell组合Markdown流程编排工具在哪硬编码在主程序独立Server进程系统已安装的命令行工具可复用的知识文档AI怎么知道工具每次请求带tools列表协议自动发现AI训练数据中已有按需加载Skill文档新增工具成本改代码重新部署改Server重启无需改任何代码更新Skill文档复杂任务处理多次AI往返多次AI往返一次Shell组合完成一次流程串行完成Token消耗高工具定义反复传高工具定义塞上下文极低零工具定义低仅加载相关Skill安全治理代码层处理OAuth精细化权限控制本地Token粗放由底层工具决定用户门槛低对话即可低OAuth网页授权高需懂命令行低对话即可可解释性差黑盒决策差黑盒决策差脚本难读好流程可见适合场景工具5个快速原型企业级多工具集成数据处理、系统运维合规场景、固定流程四、代码实战同一场景四种方案用一个企业运维告警处理场景把四种方案的代码放在一起对比。场景描述用户说帮我查一下昨晚服务器CPU飙高的事分析原因然后发个告警总结邮件给团队并把修复方案记录到知识库。4.1 方案一Function Calling代码级集成# 所有工具硬编码在主程序 defquery_metrics(server_ip:str,time_range:str)-dict:查询服务器监控指标# 调用监控API返回CPU、内存等指标return{cpu:85%,time:02:00-03:00,memory:92%}defanalyze_logs(server_ip:str,keyword:str)-dict:分析服务器错误日志# 调用日志API返回关键字匹配的错误条目return{errors:[OOM killer invoked,connection timeout]}defsend_email(team:str,subject:str,body:str)-dict:发送邮件# 调用邮件APIreturn{status:sent,to:team}defsave_to_kb(content:str,tags:list)-dict:保存到知识库# 调用知识库APIreturn{id:kb_001}# 注册给AI tools[{type:function,function:{name:query_metrics,description:查询服务器监控指标CPU、内存等,parameters:{type:object,properties:{server_ip:{type:string,description:服务器IP},time_range:{type:string,description:时间范围如last24h}}}}},{type:function,function:{name:analyze_logs,description:分析服务器错误日志,parameters:{type:object,properties:{server_ip:{type:string},keyword:{type:string}}}}},# send_email 和 save_to_kb 类似省略...]# 主流程 defrun_agent(user_input):Function Calling主流程多轮AI往返完成串行任务。messages[{role:user,content:user_input}]# 第1轮AI决定调用query_metricsresponseclient.chat.completions.create(modelgpt-4,messagesmessages,toolstools)metricscall_tool(response)# 硬编码if-else分发# 第2轮AI决定调用analyze_logsmessages.append({role:assistant,content:f指标结果{metrics}})response2client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)logscall_tool(response2)# 第3轮AI判断根因messages.append({role:assistant,content:f日志结果{logs}})response3client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)# 第4轮发邮件response4client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)call_tool(response4)# 第5轮存知识库response5client.chat.completions.create(modelgpt-4,messagesmessages,toolstools)call_tool(response5)return处理完成特点分析主程序完全控制工具逻辑开发简单直接5轮AI往返 高延迟 高Token消耗每加一个新工具要改代码、加if-else、重新部署工具定义随每次请求反复传给AI浪费Token4.2 方案二MCP协议级集成Step 1 — MCP Server独立进程# mcp_server.py # 基于官方MCP Python SDKFastMCP# 安装pip install mcp[cli]frommcp.server.fastmcpimportFastMCP mcpFastMCP(ops-tools)mcp.tool()defquery_metrics(server_ip:str,time_range:str)-dict:查询服务器监控指标CPU、内存等return{cpu:85%,time:02:00-03:00,memory:92%}mcp.tool()defanalyze_logs(server_ip:str,keyword:str)-dict:分析服务器错误日志返回匹配的错误条目return{errors:[OOM killer invoked,connection timeout]}mcp.tool()defsend_email(team:str,subject:str,body:str)-dict:发送邮件给指定团队return{status:sent,to:team}mcp.tool()defsave_to_kb(content:str,tags:list)-dict:保存处理记录到知识库return{id:kb_001}if__name____main__:mcp.run()# 独立进程持续运行Step 2 — AI客户端主程序概念性伪代码# main.py # MCP客户端连接逻辑为概念性演示实际开发参考官方SDK文档frommcpimportClientSessionfromopenaiimportOpenAIimportasyncio llmOpenAI()asyncdefrun_agent(user_input):MCP主流程工具独立部署AI自动发现。# 连接MCP Server像插U盘一样即插即用asyncwithClientSession.connect(mcp_server.py)assession:# AI自动发现工具无需手动定义tools列表toolsawaitsession.list_tools()# 自动拿到[query_metrics, ...]messages[{role:user,content:user_input}]# 仍然需要多轮AI调用每个工具一步whileTrue:responsellm.chat.completions.create(modelgpt-4,messagesmessages,toolstools)ifnotresponse.tool_calls:break# AI认为任务完成# 统一调度无需if-else硬编码分发forcallinresponse.tool_calls:resultawaitsession.call_tool(call.name,**call.arguments)messages.append({role:tool,content:result})return处理完成特点分析工具独立部署新增工具无需改主程序主程序自动感知仍然是多轮AI往返Token消耗和延迟问题未解决协议解析有额外开销OAuth授权适合企业级安全管控4.3 方案三CLI命令行管道# AI直接生成Shell脚本一次执行 importsubprocess# AI根据用户问题一次性生成完整脚本cli_script #!/bin/bash # 1. 查CPU指标使用curl jq解析JSON cpu_data$(curl -s http://monitor.api/metrics?server10.0.1.5timelast24h \\ | jq .cpu_avg) # 2. 分析日志使用grep过滤 awk提取 uniq统计 error_logs$(grep ERROR /var/log/syslog \\ | awk {print $5} \\ | sort | uniq -c | sort -rn) # 3. 判断根因 if [ $cpu_data -gt 80 ]; then root_causeCPU飙高由OOM引起 suggestion建议扩容内存至16G else root_cause正常波动 suggestion持续观察 fi # 4. 发邮件使用mail命令 echo -e CPU: ${cpu_data}\\n根因: ${root_cause}\\n建议: ${suggestion} \\ | mail -s [告警] CPU异常分析报告 teamcompany.com # 5. 存知识库使用curl POST curl -X POST http://kb.api/save \\ -H Content-Type: application/json \\ -d {\\content\\: \\${root_cause}\\, \\tags\\: [\\告警\\,\\CPU\\]} # 一次Shell调用完成所有任务resultsubprocess.run(cli_script,shellTrue,capture_outputTrue,textTrue)特点分析一次调用完成所有任务无需多轮AI往返极低Token消耗——工具定义不在上下文中AI直接生成命令无限组合能力管道|、jq、grep、awk任意拼接需要AI懂Shell语法好在LLM训练数据丰富权限管理弱依赖本地环境变量普通用户不会用命令行4.4 方案四Skills知识编排层Step 1 — 编写Skill文档!-- skill_ops_alert.md -- # 运维告警处理技能 ## 触发条件 用户提到告警、CPU飙高、服务器问题、分析原因 ## 执行步骤 1. 使用工具 query_metrics 查询目标服务器CPU指标参数server_ip, time_rangelast24h 2. 如果CPU 80%使用 analyze_logs 关键字OOM和timeout 3. 根据日志结果判断根因 - OOM killer → 结论内存不足建议扩容内存 - connection timeout → 结论网络超时建议检查防火墙规则 4. 生成告警总结包含时间、CPU峰值、根因、修复建议 5. 调用 send_email 发给运维团队subject含[告警]前缀 6. 调用 save_to_kb 保存处理记录tags: [告警, CPU, {{server_ip}}] ## 输出格式 邮件正文使用Markdown表格包含时间 | CPU峰值 | 根因 | 建议 ## 注意事项 - 如果无法确定server_ip先追问用户 - 邮件正文需包含具体的数值不要用模糊描述Step 2 — AI按Skill执行defrun_skill(user_input):Skills模式AI按预定义流程执行不自由发挥。# 1. 按需加载Skill不占上下文skillload_skill(ops_alert.md)# 2. AI严格按Skill步骤执行forstepinskill.steps:tool_namestep.extract_tool()# 提取工具名argsstep.extract_args(user_input)# 提取参数resultcall_tool(tool_name,args)# 底层可以是MCP或Function Callingifstep.has_condition():# 条件分支如CPU80%should_continuestep.evaluate(result)ifnotshould_continue:breakreturn按规范完成处理特点分析流程可控不会出现AI自由发挥导致的意外操作上下文轻量Skill按需加载不像MCP把所有工具定义塞进去可维护性强改流程只需改Markdown文档无需改代码需要预定义Skill对全新场景不够灵活五、不只是四种选择混合架构才是答案真实生产环境几乎不会只用一种范式。行业趋势是分层混合在正确的地方用正确的工具。5.1 为什么需要混合业界评测如Arize AI等Agent可观测性平台的实测分析给出了一个有启发的结论真实世界中的智能体多种范式都在用。原因很简单CLI效率最高但安全治理弱MCP治理最强但Token成本高Function Calling最简单但扩展性差Skills最可控但灵活性不足没有任何一种范式能同时满足效率、安全、灵活、可控四个维度。5.2 三层混合架构用户输入 → 意图识别层判断走哪条路径 ↓ ┌─────────┼─────────┐ ↓ ↓ ↓ 简单查询 复杂自动化 固定合规流程 ↓ ↓ ↓ Function CLI管道组合 Skills Calling (一次完成) ↓ ↓ ↓ 调用底层工具 └─────────┼───── (CLI/MCP) ↓ 统一工具执行层 (MCP管理企业服务 CLI处理本地任务)5.3 混合架构伪代码defsmart_agent(user_input):混合架构根据任务类型智能选择最优范式。# 1. 意图识别判断任务类型ifis_simple_query(user_input):# 简单查询 → Function Calling低门槛、快速响应returnfunction_call_flow(user_input)elifhas_fixed_process(user_input):# 合规流程如发工资单、运维告警→ Skills流程可控skillload_skill(match_skill(user_input))returnexecute_skill(skill)# 底层工具用MCPelifis_complex_automation(user_input):# 数据分析、日志处理 → CLI管道组合一次完成returncli_pipeline(user_input)else:# 开放式任务 → Agent框架MCP 动态决策returnagent_with_mcp(user_input)# 具体案例运维告警用混合方案defops_alert_hybrid(user_input):运维告警场景的混合实现。# 步骤1查指标 → 用CLI省Token一次curl搞定cpu_datasubprocess.run(curl -s http://monitor.api/metrics | jq .cpu_avg,shellTrue,capture_outputTrue,textTrue).stdout.strip()# 步骤2分析日志 → 用CLIgrep awk组合效率最高errorssubprocess.run(grep ERROR /var/log/syslog | awk {print $5} | sort | uniq -c,shellTrue,capture_outputTrue,textTrue).stdout.strip()# 步骤3根因判断 → AI推理LLM擅长root_causellm.analyze(fCPU{cpu_data}, errors{errors})# 步骤4发邮件 → 用MCP企业邮件服务需要OAuth鉴权mcp_client.call_tool(send_email,teamopscompany.com,subject[告警] CPU异常分析,bodyroot_cause.summary)# 步骤5存知识库 → 用MCP企业知识库需要权限管控mcp_client.call_tool(save_to_kb,contentroot_cause.detail,tags[告警,CPU,root_cause.server_ip])return处理完成行业案例佐证Google的gemini-cli就是混合架构的典型实现——以CLI为交互界面内置工具和MCP外部服务器统一注册到工具表Agent通过ReAct循环智能调度。六、前沿融合动态除了手动混合行业还在推进更深层的范式融合6.1 Agent框架原生融合新一代框架如Microsoft Agent Framework 1.0直接把多范式融合做到架构层模式适用任务工具调用方式Workflow工作流确定性任务人类控制流程LLM只负责其中一步Agent智能体开放式任务LLM自主决策、循环调用工具Skills技能复杂流程把操作手册写成MarkdownAI按需加载执行这种框架能在Workflow和Agent之间灵活切换Hybrid模式先走Workflow提取结构化意图再交给Agent处理多步推理。6.2 工具化粘合MCPorterMCPorter是一个实用的缝合项目直接把MCP服务器编译成CLI工具供AI调用。这解决了两个痛点给MCP减负AI调用轻量级CLI不在上下文中加载庞大的MCP模式定义大幅节省Token打通生态让MCP服务也能享受CLI的可组合性优势6.3 MCP协议持续演进⚠️时效性提示MCP协议在2025-2026年持续迭代。本文基于2025-2026年版本讨论后续版本可能有API变更请关注MCP官方规范。MCP协议在2025-2026年期间持续迭代针对企业大规模部署场景进行了重大升级包括OAuth鉴权增强、性能优化等进一步巩固了其在企业级安全治理中的位置。七、选型决策树你的场景是 │ ├─ 工具少5个快速验证想法 │ └── → Function Calling ✅ │ 最快上手但扩展性差 │ ├─ 企业级多系统集成需安全治理 │ └── → MCP ✅ │ OAuth鉴权 标准化接口 │ 但复杂数据处理可能还要CLI补充 │ ├─ 数据处理、日志分析、系统运维、自动化脚本 │ └── → CLI ✅ │ 成本最低、效率最高、组合最灵活 │ 但需要开发者环境 权限管理弱 │ ├─ 合规场景、固定流程、审计要求 │ └── → Skills ✅ │ 流程可控、可解释性强 │ 但需预定义新场景不灵活 │ └─ 生产级Agent系统 └── → 混合架构 ✅ CLI做本地执行 MCP管企业服务 Skills控合规流程八、生产环境注意事项⚠️重要提示本文代码为概念性演示生产环境直接使用需要额外处理以下问题。维度本文代码生产环境要求错误处理无try-catch每个工具调用必须有超时、重试、降级策略敏感信息硬编码server_ip通过环境变量或密钥管理服务注入并发控制串行执行高频场景需考虑工具调用的并发和队列日志审计无日志企业环境必须记录每次工具调用的输入输出权限最小化全权限MCP需配置最小权限集CLI需沙箱隔离CLI安全性shellTrue生产环境禁用shellTrue改用参数化调用避免注入回滚机制无知识库写入、邮件发送等操作需支持回滚一句话建议先用Function Calling验证想法遇到瓶颈再引入MCP或CLI最后用Skills固化成熟流程——渐进式架构演进比一步到位更务实。九、总结回到谁取代谁的争论答案已经很清晰范式核心定位不可替代的场景Function Calling快速原型工具工具少、变化快、快速验证MCP企业级服务契约多团队协作、安全审计、OAuth治理CLI高效原生执行数据处理、日志分析、系统运维Skills可控流程编排合规审计、固定SOP、可解释性要求一个健壮的AI Agent架构应该分为三层服务连接层MCP提供安全、标准化的外部能力入口工具执行层有CLI就用CLI最高效没有就封装成CLI供MCP调用知识编排层Skills坐镇顶层根据任务灵活调用下层的MCP或CLIMCP是服务契约管接入和安全Skills是编排蓝图管流程和知识CLI是原生工具管执行效率。三者加上Function Calling不是对手而是队友。你在实际项目中用的是哪种范式有没有遇到过用错了范式导致成本爆炸的教训欢迎在评论区分享你的真实案例——比如一开始用MCP处理日志分析Token费用一个月涨了5倍后来换成CLI管道一次搞定——我会持续整理后续出一篇Agent工具调用选型翻车合集。如果这篇帮你理清了四种范式的边界和选型逻辑欢迎点赞 收藏。下次做Agent架构评审时翻出那张选型对比表——“这个场景真的需要MCP吗还是CLI就够了”——一分钟就能避免过度设计。相关阅读MCP协议实战用Python 5分钟搭建你的第一个MCP Server附完整代码世界模型AI Agent从概念到选型的完整指南GB/Z 185《人工智能 智能体互联》系列标准核心内容梳理
