LLM、Agent、Skill、MCP四层关系与工程实践拆解

LLM、Agent、MCP、Skill 这四个词最近被摆在同一句话里的频率越来越高但真正能把它们各自站的位置说清楚的人并不多。我见过三种典型混乱把 Agent 当成“更聪明的模型”把 Skill 当成“更长的一段提示词”把 MCP 当成“某个工具的插件”。这三种理解在写 demo 的时候都没问题一旦进到真实业务里就会挨个爆雷——模型能力明明够用系统却跑不稳最后查半天发现根子不在模型而在结构分层和边界定义上。这篇东西想干的事很朴素把这四个概念拆回它们各自的抽象层级讲清楚每一层解决的是哪一类问题、不解决哪一类问题然后用一条完整的任务链路把它们串起来。你会看到 LLM 为什么天生“记不住事”Agent 的循环到底循环的是什么Skill 和普通提示词的本质差异在哪里MCP 又为什么值得单独抽一层协议出来。内容偏工程视角需要一点点编程基础但不需要你调过模型——刚接触这块的同学能看懂全局已经在做落地的同学能拿去对号入座查问题。1. 先摆一张关系地图四个词各站哪一层在展开细节之前先把这四个词按抽象层级摞起来后面所有的讨论都挂在这张图上。我的习惯是从下往上排最底下是模型本身往上是运行时控制再往上是能力封装最外层是接入协议。这四层不是替代关系是叠加关系——任何一层缺失上面的都会变得脆。1.1 LLM 是发动机不是整车LLM大语言模型本质是一个参数化的概率函数给它一段 token 序列它吐出下一段 token 序列的分布。它的输入输出都是文本严格说是 token id中间没有副作用没有内存不会自己去读文件、调接口、查数据库。这个定义听起来像废话但它决定了后面所有事情凡是需要“和外部世界打交道”的动作都必须由模型之外的东西来完成。很多人对 LLM 的期待错位就错在这里。他们看到模型能写代码、能分析表格、能总结文档就默认它能“做事”。实际上它做的始终只有一件事——根据上下文生成最可能的续写。写代码是生成分析表格是生成总结文档也是生成。它没有“执行”这个动作。你让它“帮我把这份表格的数据同步到数据库”它只能生成一段看起来像同步脚本的文字真正去连库、去写数据的那只手得由外面接上。1.2 Agent 是把发动机装上车Agent 的概念一旦去掉所有包装剩下的就是一个带循环的控制程序它负责组织上下文、调用模型、解析模型的输出、执行模型要求的动作、把执行结果塞回上下文、再调一次模型如此往复直到任务完成或者触发停止条件。模型是它循环体里的一个函数调用仅此而已。这个定义很重要因为它意味着 Agent 的稳定性主要取决于控制程序写得怎么样而不是模型有多强。超时怎么设、步数上限多少、工具报错要不要重试、重试几次、上下文涨到多大要裁剪、预算烧到多少要熔断——这些全是普通后端工程问题和模型能力无关。我见过太多项目把 90% 的精力花在调提示词上结果系统在“工具返回了一个 500 错误”这种场景下直接崩掉因为压根没写错误分支。1.3 Skill 是驾驶员的操作手册Skill 这个词被用得最乱。我的理解是Skill 是针对某一类任务的可复用能力封装它至少包含三样东西——什么时候该用它触发条件、用了之后按什么流程走步骤与检查点、走完怎么判断做对了验收标准。它可以是一段结构化文档也可以带脚本和模板资源但核心是“流程知识”不是“话术”。一段提示词和 Skill 的区别类似“帮我看看这段代码有没有问题”和“代码评审清单先看边界条件、再看错误处理、再看资源释放、最后看命名一致性”的区别。前者是一次性指令后者是可复用、可检查、可迭代的方法论。前者每次都要重新描述后者写一次能一直用而且能随着踩坑不断补充条款。1.4 MCP 是统一标准的接口插座MCP模型上下文协议解决的是一个非常具体的工程问题工具接入的适配成本。在没有协议层的时候你有 N 个模型客户端、M 个外部工具想两两打通就得写 N×M 份适配代码有了统一协议工具方按协议实现一次服务端客户端按协议实现一次调用端成本变成 NM。这是典型的接口标准化收益和当年把各种外设接口统一成通用串行总线是一回事。它的价值不在于“能连更多工具”而在于“连工具这件事变得可复用、可分发”。你写的一个工具服务端换一个客户端照样能用你换一个模型供应商原来接的工具一个都不用改。名词本质解决的问题类比主要工作量落在LLM参数化概率模型理解与生成发动机训练侧使用方几乎为零Agent带循环的控制程序让模型能多步执行任务整车与传动系统控制逻辑、错误处理、上下文管理Skill流程知识封装让同类任务稳定复现操作手册领域经验梳理与迭代MCP通信协议降低工具接入成本标准接口插座服务端实现与权限设计这张表建议先记住后面每一节都是把其中一行拆开讲。2. LLM 的边界在哪为什么光有模型不够用想让 Agent 设计得合理得先接受模型的三个硬约束。这三个约束不是当前版本的缺陷而是这类技术的结构性特征短期内不会消失所有上层设计都得绕着它们走。2.1 三个硬约束无状态、有窗口、会编无状态。模型不记得上一轮说过什么。你感觉它在“记住对话”其实是客户端每次把历史消息全部重新发了一遍。对话越长每次请求携带的内容越多成本和延迟同步上涨。这一点直接导致了 Agent 里最容易失控的问题——上下文膨胀。有窗口。上下文窗口有硬上限超出就得截断或压缩。很多人以为窗口够大就没问题实际经验恰恰相反窗口越大越容易把一堆无关信息塞进去模型的注意力被稀释关键指令被淹没在噪音里表现反而下降。我做过对比同一个任务把上下文从两万字精简到三千字准确率提升比换一个更强的模型还明显。会编。模型的目标是生成“最可能的续写”不是“最正确的事实”。当上下文里没有答案时它会顺着语言惯性编一个看起来合理的而且语气一样自信。所以凡是涉及事实性数据的环节必须外部校验不能靠模型自觉。2.2 算一笔账为什么“聊天”和“跑任务”是两个物种拿一次普通问答和一次八步的 Agent 任务对比成本差距会非常直观。项目单次问答八步 Agent 任务系统提示600 token600 token工具描述012 个工具 × 约 90 token ≈ 1100 tokenSkill 元信息06 个 × 约 40 token ≈ 240 token用户输入800 token1200 token每步输出400 token平均 220 token × 8 步输入累积1400 token约 4000 token/步 × 8 步合计约 1800 token约 34000 token差距接近 19 倍。原因不在输出在输入累积——每一步都要把之前所有的历史重新发一遍而历史里包含了系统提示、工具清单、Skill 元信息这些“固定开销”。八步任务里固定开销被重复计费了八次。这个账算完很多设计决策就自然出来了工具描述要精简、Skill 要按需加载、历史要做摘要压缩、非必要不增加步数。凡是“反正窗口大多塞点没关系”的想法最后都会在账单和延迟上还回来。2.3 上下文裁剪的三条实操原则第一条滑动窗口只保留最近若干轮完整内容更早的用一段摘要替代。摘要由模型生成控制在两百字以内只保留结论和已确认的事实不保留推理过程。第二条引用而非全文。工具返回一大段数据时不要把原始数据全塞进上下文只放一个标识符和关键字段摘要需要细节时让模型再发起一次定向查询。这一条能把上下文占用压掉一个数量级。第三条固定内容前置并缓存。系统提示、工具清单这类每轮都一样的内容放在最前面很多服务端对前缀相同的内容有缓存机制能显著降低成本。注意裁剪不是无脑截断。被截掉的内容如果包含任务约束比如“金额单位是分不是元”模型后面一定会算错。判断标准是这条信息是否影响后续决策而不是它有多长。3. Agent 的本质一个带循环的控制程序把 Agent 拆开看它的骨架非常朴素一个 while 循环循环体里做四件事——组装上下文、请求模型、解析动作、执行动作并回填结果。所有复杂度都在“怎么组装”“怎么解析”“出错怎么办”这三件事上。3.1 一次完整的循环长什么样输入任务描述 T工具集合 Tools步数上限 N预算上限 B 上下文 C ← [系统提示, 工具描述, 任务描述 T] for step in 1..N: 响应 R ← LLM(C) if R 中包含终止标记: return R 的最终答案 动作 A ← 解析(R) if A 不合法: C ← C [格式纠正提示] continue 结果 O ← 执行(A) # 带超时、幂等、错误捕获 C ← 裁剪(C [A, O]) # 关键这里要控制长度 if 累计消耗 B: return 预算耗尽返回中间结论 return 步数耗尽返回中间结论这份伪代码里有三个地方是真实项目最容易写漏的。第一A 不合法的分支——模型偶尔会输出格式错误的动作不处理就会直接抛异常。第二执行(A)的异常捕获——工具超时、返回 4xx、返回空每种都要有明确处理路径。第三裁剪(C [A, O])——不做裁剪跑到第五步上下文就可能爆掉。3.2 工具描述怎么写才不容易被误用模型选错工具八成不是模型笨是工具描述写得含糊。我总结了三条标准名字动宾结构动词要具体。query_order比order_service好create_ticket比ticket_handler好。名字里带上动作模型判断意图时准确率高很多。描述里写“什么时候用”和“什么时候不要用”。只写功能不写边界模型会在不该用的时候用它。比如查订单工具的描述里加一句“仅用于按订单号精确查询模糊搜索请用另一个工具”误调用率能降一半。参数说明必须带示例和格式。日期到底是2024-01-05还是05/01/2024金额单位是元还是分枚举值有哪几个——这些不写清楚模型只能猜。3.3 记忆要分层别混在一起我习惯把 Agent 的记忆分三层混在一起是很多项目后期难维护的根源。工作记忆当前任务的临时状态任务结束就丢。放在上下文里随循环滚动。会话记忆一次对话里的历史跨任务保留但要压缩。通常是摘要加最近若干轮原文。长期记忆跨会话沉淀的事实比如用户偏好、历史决策记录。存在外部存储里通过检索按需拉取绝不常驻上下文。分层的意义在于每层的生命周期和更新策略完全不同。工作记忆要求实时准确会话记忆要求有损压缩长期记忆要求可检索和可遗忘是的遗忘机制很重要脏数据留在长期记忆里会持续污染后续所有任务。3.4 可靠性工程把 Agent 当分布式系统写我在实际项目里踩过的坑按频率排序大概是这几个没有幂等键。任务重试时创建类工具被调用了两次产生了重复数据。解决办法是每次任务生成一个唯一标识作为幂等键传给工具工具侧做去重。没有超时。某个工具卡住三分钟整个任务就卡死在那儿。每个工具调用必须设超时超时后当作失败处理让模型决定换路径还是放弃。没有步数上限。模型在两个工具之间反复横跳无限循环烧掉大量预算。硬上限必须有触发时返回中间结论并标注“未能完成”。没有预算熔断。和上一条类似但按 token 或按金额算。我一般设两级软阈值告警硬阈值中断。这些都不是“AI”问题是任何一个调用外部依赖的系统都必须处理的问题。把 Agent 当分布式系统来写稳定性会有质的变化。4. Skill把经验固化成可复用的“招式”Skill 这一层被低估得最厉害。很多人觉得写了系统提示就够了实际上系统提示解决的是“角色和约束”Skill 解决的是“这类活具体怎么干”。两者混在一起写结果是提示词越来越长、越来越难维护而且不同任务之间互相干扰。4.1 Skill 和提示词到底差在哪维度普通提示词Skill作用范围一次对话一类任务反复复用结构自由文本元信息 流程 检查项 示例加载方式全量常驻上下文按需加载先看目录再取正文迭代方式改一次覆盖一次按版本累积条款验收靠人眼看内置检查清单可自检最本质的差异是最后一行。Skill 里必须写“怎么判断做完了”这是它区别于提示词的关键。没有验收标准的流程等于没有流程。4.2 一个 Skill 应该包含哪些部分我用的模板大致是这样字段不多但每个都得填--- name: weekly-report-digest description: 把散乱的会议记录整理成结构化周报输出固定的四个板块 trigger: 用户提到周报汇总会议纪要整理且提供了原始文本 version: 3 --- ## 适用场景 有原始记录文本需要产出固定格式的汇总。不适用于从零撰写内容。 ## 执行步骤 1. 通读全文识别出参与方、时间、结论三类实体 2. 按进展 / 风险 / 待决 / 下一步四板块归类无法归类的单独列出 3. 每条结论必须能追溯到原文的某个片段追溯不到的不写 4. 输出前执行自检清单 ## 自检清单 - [ ] 四个板块是否齐全空板块是否标注无 - [ ] 是否出现原文没有的人名或数据 - [ ] 风险项是否都标注了影响范围 - [ ] 待决项是否都写明了决策人 ## 输出格式 按固定模板输出不额外添加总结段落。 ## 失败处理 原文少于 200 字时不套模板直接说明信息不足并列出缺失项。这个结构里适用场景和失败处理是最容易被省略、但最有价值的两块。前者防止模型在不适用的场景硬套流程后者防止它在输入质量差的时候硬编内容。4.3 渐进式披露别把所有 Skill 都塞进上下文假设你有二十个 Skill每个正文两千字全量常驻上下文就是四万字还没开始干活就已经把窗口吃掉一大半而且模型要在二十份流程里挑一份选错的概率不低。正确做法是两层加载上下文里只放每个 Skill 的name和description一共几百字相当于一份目录模型判断需要用哪个之后再通过一次工具调用把该 Skill 的正文取进来。这一步很关键它把“选择”和“执行”拆成了两个阶段选择阶段的上下文极简判断准确率反而更高。这个模式在实际项目里效果非常明显。我之前把八个 Skill 的正文全塞进系统提示模型经常把两个相似流程的步骤混着用改成目录加按需加载之后同类错误基本消失。4.4 写 Skill 的三条经验流程要写成可执行的动作不要写成原则。“要注意数据准确性”是原则模型看了也不知道干什么“每个数字必须能在原文中找到对应片段找不到就标注待确认”是动作可以直接执行。检查清单要能被模型自己执行。清单项的判断标准必须客观比如“是否包含四个板块”可以自检“语气是否得体”就没法自检这种应该放到人工环节。版本号要认真维护。每次因为踩坑补了一条规则就升一版并写清补了什么。三个月后你回头看这份变更记录就是这套流程的全部经验沉淀比任何文档都有价值。5. MCP把“接工具”这件事标准化前面讲的 Agent 和 Skill 都建立在“能调到工具”这个前提上。工具怎么接进来早期各家做法五花八门有的写死在代码里有的用自定义插件格式有的靠函数调用约定。结果是每换一个模型客户端工具就得重写一遍适配。5.1 N×M 问题与协议层的位置设想你有三个不同的模型客户端命令行工具、编辑器插件、自建服务有十个内部系统需要接工单、知识库、监控、发布平台等。不做协议抽象最坏情况要写三十份适配代码每份都得处理认证、参数转换、错误映射。做了协议抽象十个系统各写一个服务端三个客户端各写一个调用端总共十三份而且新增任何一方都只是加一。这就是协议层的全部价值——把组合爆炸变成加法。听起来不性感但工程上这是最划算的一件事。5.2 三种能力原语协议通常把服务端能提供的东西分成几类理解这几类的区别很重要选错了会让设计变别扭。工具tools可执行的动作有副作用需要模型主动调用。比如“创建工单”“发送通知”。特点是调用会改变外部状态所以需要权限控制和幂等设计。资源resources可读取的数据只读通常由客户端决定什么时候加载。比如“当前项目的配置文件”“某份文档的内容”。特点是安全可以预加载或缓存。提示模板prompts预先写好的指令模板带参数。比如“代码评审模板”传入文件路径就生成一段完整的评审请求。特点是它不是数据也不是动作而是复用的指令资产。实际项目里最常见的误用是把只读查询写成工具。查询本该是资源写成工具会导致每次查询都要走一轮完整的模型决策成本和延迟都上去了。判断标准很简单会不会改变外部状态不会就优先做成资源。5.3 一次会话的握手流程协议通信一般走 JSON-RPC 风格的消息传输层可以是标准输入输出本地进程也可以是长连接远程服务。一次典型交互大致是这样// 1. 客户端发起初始化 {jsonrpc:2.0,id:1,method:initialize, params:{protocolVersion:1.0, capabilities:{roots:{listChanged:true}}}} // 2. 服务端返回自己的能力清单 {jsonrpc:2.0,id:1,result:{ protocolVersion:1.0, capabilities:{tools:{listChanged:true},resources:{}}, serverInfo:{name:internal-tools,version:0.4.1}}} // 3. 客户端拉取工具列表只需要一次之后靠变更通知 {jsonrpc:2.0,id:2,method:tools/list,params:{}} // 4. 服务端返回工具定义 {jsonrpc:2.0,id:2,result:{tools:[ {name:query_ticket,description:按工单号精确查询不支持模糊搜索, inputSchema:{type:object, properties:{ticket_id:{type:string,description:形如 T-20240105-001}}, required:[ticket_id]}}]}} // 5. 模型决定调用客户端发起 {jsonrpc:2.0,id:3,method:tools/call, params:{name:query_ticket,arguments:{ticket_id:T-20240105-001}}} // 6. 服务端返回结果 {jsonrpc:2.0,id:3,result:{content:[ {type:text,text:状态处理中负责人A 组更新于 3 小时前}]}}注意第 2 步的能力协商——客户端和服务端各自声明支持什么后面的交互只在这个交集里进行。这个设计避免了“客户端发了一个服务端不认识的方法”这种低级错误是协议层必备的自描述能力。5.4 手写一个最小服务端理解协议最快的方式是自己实现一个。下面这段是标准输入输出传输的最小骨架用 Python 标准库就能跑不依赖任何第三方包import sys, json TOOLS { query_ticket: { description: 按工单号精确查询不支持模糊搜索, inputSchema: { type: object, properties: {ticket_id: {type: string}}, required: [ticket_id], }, } } def handle(method, params): if method initialize: return { protocolVersion: 1.0, capabilities: {tools: {listChanged: False}}, serverInfo: {name: demo-tools, version: 0.1.0}, } if method tools/list: return {tools: [dict(namek, **v) for k, v in TOOLS.items()]} if method tools/call: name, args params.get(name), params.get(arguments, {}) if name ! query_ticket: raise ValueError(funknown tool: {name}) tid args.get(ticket_id, ) if not tid.startswith(T-): # 参数校验必须做别指望模型永远传对 return {content: [{type: text, text: 工单号格式不正确}], isError: True} return {content: [{type: text, text: f{tid} 状态处理中}]} raise ValueError(funknown method: {method}) for line in sys.stdin: line line.strip() if not line: continue try: req json.loads(line) result handle(req[method], req.get(params, {})) resp {jsonrpc: 2.0, id: req.get(id), result: result} except Exception as e: # 错误必须以协议格式返回不能直接抛栈 resp {jsonrpc: 2.0, id: req.get(id) if req in dir() else None, error: {code: -32603, message: str(e)}} sys.stdout.write(json.dumps(resp, ensure_asciiFalse) \n) sys.stdout.flush()这段代码有三个细节值得说。第一每行一条消息写完必须 flush否则客户端会一直等。第二任何异常都要转成协议规定的错误对象返回直接抛栈会让客户端解析失败整个会话就断了。第三参数校验写在服务端不要假设模型一定传对——它传错格式的概率比你想的高得多。注意本地进程传输适合个人使用和开发调试一旦要多人共享就必须考虑认证、限流、审计日志。协议本身不解决安全问题安全边界要自己划。6. 四者如何咬合跑通一条完整链路概念拆完最后一定要落到一条真实链路上否则还是纸上谈兵。我设计一个中等复杂度的场景把一批散乱的会议记录整理成结构化周报并把关键风险项写入内部知识库。这个任务同时用到了读取、生成、格式校验、写入四类动作能覆盖绝大部分常见模式。6.1 任务拆解与各层分工LLM 负责的部分理解记录内容、判断哪些是结论哪些是闲聊、生成四板块结构、把口语化表达改写成书面表述。这些是纯语言处理模型最擅长。Agent 负责的部分决定先读哪份文件、读完要不要再读、生成完格式不对要不要重来、写入失败要不要重试、总共跑几步。Skill 负责的部分周报的四个板块怎么分、每条结论怎么追溯原文、什么情况下判定信息不足直接返回。MCP 负责的部分把“读文件”“写知识库”“查重”三个内部系统统一成标准工具客户端不需要知道它们背后是什么实现。这个分工的意义在于任何一层出问题都能快速定位。周报格式不对改 Skill读文件失败查 MCP 服务端步骤乱跳调 Agent 逻辑内容理解错了才需要考虑换模型。没有分层的时候所有这些现象都表现为“AI 不好用”根本无从下手。6.2 执行链路逐步记录下面是我实测一次运行的过程记录八步完成中间有一次重试步动作输入摘要结果耗时1加载 Skill 目录六个 Skill 的元信息选中 weekly-report-digest0.4s2取 Skill 正文skill 名称拿到完整流程与自检清单0.6s3列出待处理文件目录标识返回 5 个文件0.8s4读取文件 1-3文件标识共约 4200 字1.2s5生成初稿前三个文件内容四板块结构缺“待决”6.1s6读取文件 4-5文件标识共约 2800 字含两条待决项1.0s7补全初稿初稿 新内容四板块齐全9 条结论5.4s8写入知识库风险项 3 条成功返回 3 个标识0.9s第 5 步到第 7 步之间发生了一次“补读”因为模型在生成时发现“待决”板块是空的主动回去读了剩余文件。这个行为不是硬编码的是 Skill 里写了“空板块必须标注原因或补查”模型据此决定再读一轮。这就是 Skill 的价值——它把一个隐性的质量要求变成了可执行的动作。6.3 参数计算与成本估算按前面的口径算这次任务的开销固定开销系统提示 600 工具描述 5 个约 450 Skill 元信息 240 ≈ 1290 token八步里被重复计费变动开销文件内容约 7000 token分两次进来、模型输出约 2200 token输入累积估算前四步平均 2500 token后四步平均 6000 token合计约 34000 token 输入、2200 token 输出对比不分层的做法把所有内容一次性塞进一个超长提示词这条链路的输入 token 大概是 9000 左右看起来更省。但实际对比下来一次性做法的失败率高得多——格式经常跑偏、结论追溯不到原文、待决项容易漏。失败一次重跑的成本比自己多花两万 token 贵多了。所以这里有个反直觉的结论分层让单次成本上升让总成本下降。因为分层方案的成功率高、可调试、出错能局部修而单体方案一旦失败只能整体重来。6.4 失败路径复盘跑通十次之后我特意统计了失败情况三种典型第一种第 8 步写入返回 409重复因为上一次任务其实写成功了但客户端超时没收到响应。解决办法是给写入工具加幂等键用“周报日期 内容摘要”做去重标识。第二种第 5 步生成的初稿把两条闲聊当成了结论。原因是 Skill 里只写了“识别结论”没写“排除客套话”。补了一条“以下内容不算结论寒暄、日程安排、对已完成的确认”同类错误消失。第三种第 3 步列文件时返回了 40 个文件目录里混进了历史归档导致后面读取超时。解决办法是在工具侧加过滤参数Agent 调用时显式指定时间范围。这条经验后来被我推广到所有列表类工具——列表工具不带过滤参数早晚出事。7. 常见问题与排查技巧实录这一节是我攒下来的故障速查表按现象归类。大部分问题看着像模型不行实际查下来都在外围。7.1 高频故障速查表现象最可能原因排查动作修复方向模型不调用工具直接编答案工具描述太笼统或系统提示里没强调必须用工具打印完整请求看工具描述是否含“什么时候用”补描述边界加“事实性数据必须调用工具获取”的硬约束反复调用同一个工具工具返回结果没有有效信息模型以为失败看返回值是否为空或格式异常修服务端返回空结果要明确说明“查询成功但无数据”步骤跑到一半上下文超限工具返回大段原文且未裁剪统计每步上下文增量返回值改摘要加标识符需要细节再查格式时对时错输出格式约束写得太靠后被长上下文稀释检查格式要求在第几段格式要求和示例移到系统提示末尾靠近生成位置相同输入结果差异大温度参数偏高或工具返回顺序不稳定固定温度重跑检查工具列表排序任务型场景温度调低工具列表按固定顺序输出写入类操作重复执行无幂等键超时后重试查服务端日志是否有同参重复请求加幂等键服务端做去重Skill 选错多个 Skill 描述重合对比各 Skill 的 description描述里写清互斥边界必要时合并这张表建议贴在工位上。我遇到的新问题里八成能在这七行里找到对应。7.2 几个不太容易想到的坑工具数量超过十五个之后选择准确率明显下滑。这个不是线性的是过了某个点之后断崖式下降。解决办法是分组先让模型选“要操作哪个系统”再在该系统下的工具里选具体动作两级选择比一级选择准得多。工具返回的错误信息如果太技术化模型会误判。返回{code:500,msg:NullPointerException}模型可能认为是参数问题然后改参数重试其实应该直接放弃。错误信息要写成自然语言明确告诉它“这是服务端故障重试无意义”。Skill 里的示例会被过度模仿。如果你在 Skill 里给了一个完整输出示例模型在真实任务里会倾向于照抄示例的结构甚至措辞哪怕内容不匹配。示例要给片段不要给完整成品。上下文里同时存在多份相似格式的模板时模型会串。比如同时加载了周报模板和月报模板输出经常混。这种情况要么串行加载用完一个卸载一个要么在模板开头加显著区分标识。超时设置不要一刀切。读类工具设 3 秒写类工具设 30 秒生成类调用设 120 秒。统一设 10 秒的结果是读的经常白等、写的经常被砍。7.3 分层之后怎么定位问题最后分享一个我常用的定位方法四个问题依次问下来基本能锁定问题在哪一层第一问模型有没有理解对任务把完整请求打出来看如果它对任务的理解就跑偏了问题在提示或 Skill不在 Agent。第二问模型有没有选对工具看它调用的工具名和参数选错了查工具描述参数错了查 schema 示例。第三问工具返回的东西对不对手动调一次同样的工具对比返回内容。返回错了是服务端问题返回对了但模型没用上是上下文裁剪把它截掉了。第四问步数是不是超了看循环记录如果它在两个动作之间来回跳通常是前一步的返回信息不足模型在试探。按这个顺序查比漫无目的地改提示词高效得多。我早期最大的浪费就是跳过前三问直接改提示词改了半天发现是工具返回值里少了一个字段。这四个概念的关系说到底是一句话LLM 提供理解和生成的能力Agent 给它装上手脚和循环Skill 把人的经验固化下来告诉它该怎么干MCP 让手脚的接入变成标准件。四层各管一段任何一层想做另一层的事系统就会开始抖。我在实际项目里最深的一个体会是凡是感觉“模型不够聪明”的地方往下挖两层十有八九是结构没搭对——工具描述含糊、上下文太脏、流程没写成可执行的动作或者干脆缺了错误处理分支。把这些补齐之后同一套模型的表现在肉眼可见地变稳这才是这套分层真正值钱的地方。