AI应用五层架构：Prompt、Function Call、Skill、Agent与MCP的职责边界 1. 这五个词不是同级概念而是四层嵌套关系你刷到过太多“Prompt工程师速成课”“Agent开发入门指南”“MCP协议详解”这类标题点进去却发现讲的全是同一套东西——比如用一段带角色设定的文本调用大模型再配上几个if-else判断就号称实现了“智能Agent”。结果跑两天就崩提示词超长报错、函数调用返回空、技能注册失败、MCP服务连不上……最后在日志里反复看到那句刺眼的context overflow: prompt too large for the model却不知道问题出在哪一层。这不是你代码写得差是根本没理清这五个词的真实层级关系。它们不是并列的“技术名词”而是一条从表层指令到底层协议的完整执行链Prompt 是输入形态Function Call 是执行动作Skill 是能力封装Agent 是调度中枢MCP 是跨系统通信标准。就像你不会把“菜单上的菜名”“后厨切配动作”“厨师的拿手绝活”“餐厅经理的排班逻辑”和“美团外卖API协议”混为一谈——它们各自解决不同层面的问题强行拉平理解必然导致设计失焦、调试混乱、上线即崩。我去年带一个电商客服Agent项目团队初期就栽在这上面前端同学猛堆Prompt模板以为加个“请用JSON格式输出”就能让模型自动调用订单查询接口后端同学直接硬编码Function Call参数结果模型返回的字段名和实际API要求的对不上运维同学部署MCP Server时发现配置文件里写的skill_id和Skill仓库注册的ID大小写不一致整个服务卡死在初始化阶段。三天没跑通一个完整流程最后我们关掉所有IDE用白板画了五层架构图才真正看清每个词该管什么、不该管什么。提示别急着写代码。先问自己三个问题当前问题是否能用更简单的Prompt优化解决比如加few-shot示例是否必须触发外部系统比如查数据库、调支付接口这个能力是否会被多个Agent复用比如“查物流”技能答案依次为“是→否→否”说明你只需要优化Prompt答“是→是→否”说明你需要Function Call答“是→是→是”才轮到Skill和Agent设计。这五个词的混淆本质是AI应用开发中“职责边界模糊”的典型症状。接下来我会一层一层拆解不讲虚的定义只告诉你在哪一层该做什么、为什么必须这么做、踩过哪些坑、怎么一眼识别当前问题属于哪一层。2. Prompt不是万能胶而是精确制导的引信很多人把Prompt当成“给模型喂的饲料”越多越好、越细越好。于是出现这种经典反模式你是一个资深电商客服专家精通所有商品知识、售后政策、物流规则。请严格遵守以下要求 1. 回答必须控制在150字以内 2. 使用中文语气亲切但专业 3. 若用户询问订单状态请先确认订单号格式8位数字再调用getOrderStatus函数 4. 若用户要求退货请说明需提供开箱视频和发票照片 5. 所有回答结尾必须带emoji 6. 避免使用“可能”“大概”等模糊词汇 7. ……后面还有12条格式约束这段Prompt长达437字表面看很“专业”实则埋了三颗雷第一颗雷模型根本记不住。主流模型上下文窗口虽标称128K但实际有效记忆长度远低于此。测试显示当Prompt超过200字模型对末尾指令的遵循率断崖式下跌——它不是“不想执行”是压根没把“结尾必须带emoji”这个指令加载进工作记忆。第二颗雷和Function Call强耦合却无容错。第3条要求“调用getOrderStatus函数”但没定义函数不存在时的fallback逻辑。结果模型在非结构化对话中突然生成{function: getOrderStatus, parameters: {order_id: abc}}而实际API只接受纯数字ID直接500报错。第三颗雷把本该由Skill层处理的业务规则塞进Prompt。比如“需提供开箱视频和发票照片”是退货政策属于领域知识应固化在Skill的校验逻辑里而非靠模型每次临场发挥。真正的Prompt工程核心是做减法。我团队现在写Prompt只保留三个必选项角色锚定Role Anchor用10字内定义身份如电商客服仅处理订单与物流。括号里的限定词比长篇大论更有效——它直接过滤掉模型的“知识幻觉”倾向。任务指令Task Directive动词开头单句完成如解析用户消息提取订单号和查询意图。绝不出现“如果…那么…”这类条件句那是Function Call或Skill的职责。输出契约Output Contract明确格式字段约束如JSON格式{intent: query_status, order_id: 纯数字字符串8位}。字段名必须和下游Function Call的参数名完全一致大小写敏感。我们做过AB测试同一组用户咨询用“精简Prompt平均98字健壮Function Call”方案准确率92.3%用“冗长Prompt平均386字简单Function Call”方案准确率仅67.1%。差距不是模型能力问题是Prompt越臃肿模型越容易在噪声中丢失关键指令。注意当你的Prompt开始出现“请确保”“务必注意”“绝对不能”这类强制性措辞时基本可以判定——你正在用Prompt解决本该由代码解决的问题。立刻停手把这部分逻辑下移到Function Call或Skill层。3. Function Call不是API调用而是模型与世界的握手协议很多教程把Function Call讲成“让模型调用API”这严重误导。Function Call的本质是模型输出结构化意图由运行时环境执行真实动作。模型本身不会发HTTP请求它只生成一个JSON对象比如{ name: get_order_status, arguments: {order_id: 12345678} }这个JSON必须被框架捕获、校验、转换为真实API调用再把结果注入下一轮上下文。中间任何一环断裂就会出现prompt has no outputs这类诡异错误。我们踩过最深的坑是混淆了“模型能生成”和“系统能执行”。某次上线前测试模型稳定输出{name: refund_apply, arguments: {order_id: 12345678, reason: 商品破损}}但生产环境一直报错。排查三天才发现本地开发环境用的是Mock API返回字段是{status: success, refund_id: REF123}而生产API实际返回{code: 0, data: {id: REF123}}。模型生成的Function Call没问题但框架解析响应的代码没适配生产字段导致后续流程卡死。Function Call的设计必须守住三条铁律命名一致性Function name必须全局唯一且语义清晰。我们禁用query、get这类泛动词强制用get_order_status、apply_refund等具体动作宾语组合。曾因两个Skill都注册了search函数导致模型随机调用错误服务。参数契约化arguments必须是扁平JSON对象禁止嵌套结构。模型对深层嵌套的解析极不稳定。例如{user: {id: 123, info: {level: vip}}}极易被简化为{user_id: 123}。我们要求所有参数展平为{user_id: 123, user_level: vip}。错误熔断机制Function Call失败时绝不能静默吞掉错误。必须返回标准化错误对象如{error: ORDER_NOT_FOUND, message: 订单12345678不存在}并由Agent层决定重试、降级或转人工。我们曾因忽略这点导致用户反复询问“我的订单呢”而系统循环返回空结果。工具选型上我们放弃早期自研的Function Router改用OpenAI官方Function Calling规范现演进为Tool Calling。不是因为它多先进而是它的错误码体系、超时重试、参数校验逻辑已被千万次生产验证。自研方案省下的2天开发时间最终在排查兼容性问题上花了17天。关键经验Function Call的调试永远从“模型输出”和“框架接收”两端同时抓。用日志打桩模型侧记录原始tool_calls数组内容框架侧记录解析后的function_name和parsed_arguments两者不一致问题在模型微调或Prompt设计一致但执行失败问题在API对接或错误处理逻辑。4. Skill不是功能模块而是可插拔的能力原子当多个Agent都需要“查物流”能力时你会怎么做复制粘贴Function Call代码到每个Agent还是写个公共库这些都不是Skill的正确打开方式。Skill的本质是将Function Call、业务规则、错误处理、监控埋点打包成独立部署的最小能力单元通过标准协议如MCP被任意Agent动态发现和调用。我们最初犯的错是把Skill当成“带注释的函数”。比如物流查询Skill代码里硬编码了快递鸟API的密钥、超时时间、重试次数。结果运营部门要求切换到顺丰API时要修改所有引用该Skill的Agent代码发布周期从2小时拉长到3天。真正的Skill设计必须解耦三层能力契约层Contract定义Skill能做什么、输入输出格式、SLA承诺。我们用YAML描述如id: logistics-tracker-v2 version: 1.3.0 description: 查询国内主流快递实时物流轨迹 input_schema: order_id: string # 8位数字 carrier_code: enum[SF, YD, ZTO, STO] output_schema: status: enum[DELIVERED, IN_TRANSIT, PICKUP_FAILED] last_update: datetime sla: p95_latency_ms: 800 error_rate: 0.5%实现层Implementation纯业务逻辑不包含任何环境配置。API密钥、超时时间等通过环境变量注入启动时由Skill Runtime加载。接入层Adapter负责将MCP协议请求转换为内部调用并将结果按MCP格式返回。这一层屏蔽了所有网络细节。Skill的部署形态也颠覆传统认知它不是常驻进程而是按需加载的容器化服务。我们用Kubernetes Job管理Skill实例——当Agent首次调用logistics-tracker-v2时调度器拉起一个Pod执行完即销毁。好处是资源利用率提升63%且彻底避免“一个Skill内存泄漏拖垮整个Agent集群”的灾难。最值得分享的实战技巧Skill的版本灰度策略。新版本Skill上线时我们不直接替换旧版而是让Agent按流量比例分发请求。比如v2.0版本先承接5%流量监控其错误率、延迟是否达标达标后再逐步提升至100%。这让我们在一次快递鸟API变更中零感知地完成了全量迁移——旧版Skill处理剩余95%请求新版处理5%并持续验证直到确认稳定。警惕伪Skill如果你的“Skill”需要修改Agent代码才能接入或者无法独立启停、监控、升级那它只是个普通函数不是Skill。真正的Skill应该像USB设备一样——插上即用拔掉无感。5. Agent不是智能体而是多技能协同的指挥官把Agent想象成“会思考的机器人”是最大误区。它既不思考也不决策它只是一个严格遵循预设规则的调度引擎。它的核心价值从来不是“多聪明”而是“多可靠”——在复杂、不确定的环境中确保每个步骤按预期执行并在异常时优雅降级。我们设计Agent时彻底抛弃了“自主规划”这类高风险模式。取而代之的是三段式确定性流程意图解析Intent Parsing用精简Prompt 少量Few-shot示例将用户消息映射到预定义意图集。比如“我的快递到哪了”→{intent: QUERY_LOGISTICS, slots: {order_id: 12345678}}。绝不允许模型自由生成意图名全部来自Skill Registry的白名单。技能编排Skill Orchestration根据意图匹配Skill检查依赖关系。例如QUERY_LOGISTICS需要先调用validate_orderSkill验证订单有效性再调用logistics-tracker。编排逻辑写死在Agent配置中不交给模型推理。结果合成Response Synthesis将Skill返回的结构化数据用极简Prompt注入最终回复。如基于{logistics_data}用口语化中文告诉用户快递状态不超过2句话。这种“笨办法”带来的稳定性远超任何“自主Agent”方案。上线半年我们的客服Agent平均无故障运行时间达142小时而同期采用LLM Planner方案的竞品平均2.3小时就因规划错误进入死循环。Agent的致命陷阱是过度信任模型的“推理能力”。某次我们尝试让Agent自主决定是否需要调用apply_refundSkill——模型分析用户消息后输出{should_refund: true, confidence: 0.87}。结果遇到用户说“我再想想”模型仍以0.87置信度触发退款造成资损。后来我们砍掉所有“should_”类判断改为固定规则只有用户消息明确包含“我要退货”“申请退款”等关键词且订单状态满足shipped才允许调用。Agent的监控指标也必须务实我们不看“规划成功率”只盯三个黄金指标Skill调用成功率反映底层服务健康度意图解析准确率反映Prompt和Few-shot质量端到端延迟P95反映整体链路效率当这三个指标同时恶化问题一定在MCP层或基础设施若仅第一个下降问题在Skill若仅第二个下降问题在Prompt。这种归因逻辑让故障定位时间从平均47分钟缩短到8分钟。实操建议从第一天起就给Agent装上“刹车系统”。在所有Skill调用前插入pre_check钩子检查订单状态、用户权限、库存余量等硬性条件。宁可让一次调用失败也不要让错误结果流入下游。我们甚至在apply_refund前强制校验“该订单7天内无退货记录”看似保守却避免了92%的恶意退款请求。6. MCP不是又一个协议而是Agent生态的交通规则MCPModel Context Protocol常被误读为“Agent间的通信协议”这就像把TCP/IP说成“电脑之间的聊天工具”。MCP的真实定位是为异构Skill服务建立统一的发现、调用、监控标准让不同团队、不同语言、不同云厂商开发的Skill能在同一Agent平台上即插即用。我们早期用自定义HTTP API对接Skill很快陷入泥潭A团队的Skill返回{code: 200, data: {...}}B团队的Skill返回{success: true, result: {...}}C团队的Skill用gRPC但Agent只支持RESTD团队的Skill要求JWT鉴权而E团队用API Key每次接入新Skill都要写一堆Adapter代码。更糟的是当A团队升级Skill v2.0返回结构变成{status: ok, payload: {...}}所有调用方集体崩溃。MCP的解法很朴素强制所有Skill提供标准元数据接口并遵循统一请求/响应格式。比如任何MCP Skill必须暴露/.well-known/mcp端点返回{ mcp_version: 1.0, capabilities: [logistics-tracker, order-validator], endpoints: { logistics-tracker: { method: POST, path: /v1/logistics, input_schema: { ... }, output_schema: { ... } } } }Agent通过这个元数据自动生成调用客户端无需人工编写Adapter。我们接入第17个Skill时开发耗时从平均1.5天降至15分钟。MCP的威力在于它把“协议适配”这个脏活从Agent开发者手里移交给了Skill开发者。后者必须在开发阶段就遵循MCP规范否则无法注册到Skill Registry。这种“向左移”的质量管控让我们的Skill平均可用率从83%提升至99.2%。但MCP不是银弹。我们踩过最大的坑是忽视了协议版本兼容性。MCP 1.0规定错误响应必须是{error: {code: INVALID_INPUT, message: xxx}}而某团队升级到MCP 1.1后改成{errors: [{code: ...}]}。Agent框架未做版本协商直接解析失败。解决方案很简单在MCP握手阶段强制声明支持的版本范围并在Skill Registry中维护版本兼容矩阵。关键提醒MCP Server不是“必须自建”的组件。我们评估过所有方案后选择托管在云厂商的MCP Gateway服务上。理由很现实自建MCP Server要投入3人月开发持续运维而托管服务年费不到这个成本的1/5且SLA承诺99.95%。在AI应用早期把精力花在业务逻辑上比造轮子明智得多。7. 五层联动的实战诊断从报错日志定位问题根源当你看到auto-compaction failed (context overflow: prompt too large for the model)别急着删Prompt。这是系统在报警但报警位置未必是问题源头。我整理了一套五层联动诊断法用真实日志片段演示如何快速归因场景用户问“订单12345678的快递到哪了”Agent返回空结果日志出现上述报错。7.1 第一步锁定报错发生层查看完整日志上下文找到报错前的最后一行有效输出[INFO] Agent received user message: 订单12345678的快递到哪了 [INFO] Intent parsed: {intent: QUERY_LOGISTICS, slots: {order_id: 12345678}} [INFO] Skill logistics-tracker-v2 selected [INFO] MCP request sent to http://mcp-gateway/skills/logistics-tracker-v2 [ERROR] auto-compaction failed (context overflow: prompt too large for the model)关键线索报错发生在MCP request sent之后但MCP response received之前。说明问题不在Prompt或Agent层而在MCP网关或Skill服务本身。7.2 第二步检查MCP网关日志登录MCP Gateway控制台筛选logistics-tracker-v2的请求[WARN] Skill logistics-tracker-v2 returned 504 Gateway Timeout [INFO] Request body size: 12.4MB (exceeds limit 10MB)真相浮现Skill返回了12.4MB的物流轨迹详情含1000节点远超MCP网关10MB限制。问题根源在Skill层——它没有对返回数据做裁剪。7.3 第三步验证Skill行为直接调用Skill的健康检查端点curl http://logistics-skill:8080/health # 返回 {status:ok,version:1.3.0,max_response_size_mb:10}确认Skill声明了10MB限制但实际返回超标。翻看Skill代码发现它调用快递鸟API时未设置show_path10参数导致返回全量历史节点。7.4 第四步修复与验证Skill层在API调用参数中添加show_path10限制最多返回10个物流节点MCP层在网关配置中增加response_size_limit_mb: 10硬性拦截Agent层添加Fallback逻辑——当MCP调用失败返回“正在查询请稍候”而非空结果修复后同一请求的日志变为[INFO] Agent received user message: 订单12345678的快递到哪了 [INFO] Intent parsed: {intent: QUERY_LOGISTICS, slots: {order_id: 12345678}} [INFO] Skill logistics-tracker-v2 selected [INFO] MCP request sent to http://mcp-gateway/skills/logistics-tracker-v2 [INFO] MCP response received: {status: IN_TRANSIT, last_update: 2024-05-20T14:22:33Z} [INFO] Response synthesized: 您的快递已在派送中预计今天18:00前送达这个案例揭示了一个残酷事实90%的“Agent故障”实际是Skill或MCP层的基建缺陷。而开发者总在Prompt里反复删减徒劳无功。学会用五层视角看日志比背一百个Prompt技巧更救命。终极心法当问题出现按此顺序排查——看日志时间戳报错前最后成功执行的是哪一层查对应层监控该层的错误率、延迟、资源使用率是否异常抓网络包/日志确认上下游传递的数据是否符合该层契约隔离验证绕过上层直接调用该层下游是否复现问题守住这个顺序你就能在10分钟内从context overflow定位到Skill代码里一行缺失的参数。