agent 大模型 skill的区别

很多人在写 Agent 时会卡在同一件事上：一个需求过来，分不清哪部分该交给大模型、哪部分该写进技能、哪部分是 Agent 自己的编排活，结果要么把大模型当万能胶，要么把技能堆成流水线。这篇不堆概念，只给判断标准和拆分动作，让你看完能对着自己的项目把三层职责划出来。

写 Agent 的人几乎都卡过同一个点：需求过来了，脑子里先冒出一堆问题——这段让大模型判断，还是写死成代码？这个动作要不要封成一个技能？谁来记住上一轮做到哪了？分不清的时候，最常见的两种走偏就是：把大模型当万能胶，什么都往里塞；或者反过来，把每一步都写成流水线，模型只剩一个填空的位置。两种都能跑，但都难维护。

这篇不堆术语，只给判断标准和拆分动作。你看完应该能对着自己手上的项目，把三层职责大致划出来：哪块是模型的理解与生成，哪块是技能这种确定性能力，哪块是 Agent 自己的编排、状态和兜底。顺便说一句，这三层是职责分层，不是目录分层，同一个文件里混着写很正常，关键是心里清楚每一行属于哪一类。

先把三样东西摆到一张图上看

想象一个具体场景：一家 5 人小团队做报销流程，用户把一张发票截图丢进对话，系统要识别金额、判断这个费用归属哪个科目、录进内部系统、最后回一句确认。这条链路上，大模型干的是「看图说话、理解用户想干嘛、把非结构化的东西说成人话」；技能干的是「调用内部系统的录入接口、按规则校验科目是否存在」；Agent 干的是「先调模型识别，拿到结果后决定要不要追问，再调技能写入，写失败要不要重试」。

这里有个容易忽略的点：三层不是技术栈分层，不是「上面是模型层、中间是工具层、下面是编排层」这种上下关系。真实项目里它们经常缠在一起，一个函数里可能先问模型、再校验、再写入。所以你不需要按这三层去拆文件目录，只要在判断「这段逻辑归谁」时有依据就够了。

哪些活该留给大模型，哪些别塞给它

大模型最擅长的是「没有唯一正确答案但需要理解」的活。用户说「帮我把上个月那张拖着没报的机票处理一下」，这句话里有时间指代、有指代不明、有业务意图，只有模型能接住。但反过来，凡是同一输入必须每次输出一样、且错了要能追责到某一行代码的环节，就不该放模型里。

• 适合交给模型：语言理解、意图分类、非结构化内容转结构化、话术生成、模糊匹配、多轮追问的措辞
• 不适合交给模型：精确计算、固定格式转换、权限校验、金额汇总、必须可复现的步骤
• 判断口诀：同一输入要求每次结果一致、错了要能定位到规则的，就别放模型里
• 折中做法：让模型输出候选，再用代码做校验和取舍，而不是让模型直接下最终结论
• 不适用的情况：任务本身没有确定答案、或输入输出高度开放时，硬拆成技能反而更不稳

有一种常见的错位：让模型负责生成严格 JSON，然后靠提示词反复强调「只输出 JSON，不要多余文字」。这在演示里很好用，一换模型或换个稍长的输入就容易崩，因为你在要求一个概率模型做确定性输出。更稳的做法是模型输出结构，代码负责校验和修复，不合法就退回重问一次。

技能到底是什么：不是提示词换个名字

很多人把技能理解成「一段封装好的提示词」，这就偏了。技能的本质是稳定的输入输出契约：给我这些参数，我返回这个结果，或者明确告诉我哪里失败了。它的实现可以是函数调用、外部 API、一段脚本、一次检索、一个模板渲染，形态不重要，重要的是它可预测。

知识型技能

给模型补信息，比如查文档、检索知识库、读用户历史，本身不改变外部世界

动作型技能

真的去改外部状态，比如写数据库、发消息、下单、改配置，出问题影响更大

输入输出契约

参数是什么、边界怎么约定、失败返回什么，这些都是技能的一部分，不是额外工作

边界清楚

一个技能只干一件事，模型不需要在调用前再解释一遍自己想说啥

判断一个技能写得好不好，有个简单标准：把它单独拎出来，不看任何模型输出，你能不能构造参数直接调用并得到预期结果。做不到，说明它里面偷偷依赖了模型的判断，出了问题你就分不清是理解错还是执行错。

不适用的情况也要说清楚：一次性、只用一次的逻辑不值得封成技能。比如某次活动临时加的一个查询，直接写在编排里更省事，封成技能只是多一层间接。技能是给会重复出现、需要被可靠调用的能力准备的。

Agent 这一层的活：编排、状态与兜底

编排听起来玄，其实就回答三个问题：什么时候调模型、什么时候调技能、结果不对时下一步走哪。第一个和第二个问题决定效率，第三个问题决定系统能不能活着。很多 Agent 不是败在模型不行，是败在「东西没拿到」时没人知道该干嘛。

1. 定触发条件写清楚每个模型调用和技能调用的前置条件，比如「识别到金额字段缺失时才追问」，而不是每一步都无条件往下走
2. 记显式状态把「已经做了什么、还差什么、上次失败在哪」写成结构化字段，不要指望靠对话历史隐式记住，长任务里一定会丢
3. 设失败路径技能报错时明确是重试、换路径还是转人工；模型给不出可用参数时降级到追问或人工，别让它硬猜
4. 留可观测性每次模型调用记输入和输出，每次技能调用记实际参数和返回，后面排查全靠这些

状态管理是这层最隐形也最烦人的部分。一个多轮任务里，用户可能中途改口、可能重复提交、可能上一步的技能其实失败了但流程忘了标记。把这些状态显式写下来，比让模型从对话里自己体会靠谱得多。

不适用的情况是：任务步骤固定、分支极少，比如「读文件→清洗→写库」这种线性流程。这时候用工作流引擎比套 Agent 框架更划算，你不需要模型来决定下一步，也就不用承担它带来的不确定性。

拿到一个需求，按这个顺序拆

下面这套顺序是给动手前用的，不是评审用的。你不需要一次拆得完美，但按这个顺序走，能避免最常见的「先写提示词，写到一半发现有些环节根本不该让模型碰」。

1. 写下终态先用一句话描述任务完成时输出是什么、外部状态变成什么样。终态写不清，后面所有拆分都是猜
2. 圈出必须确定的环节把校验、计算、写入、权限这类必须稳定可复现的步骤先划成技能，这些先定，剩下的模糊地带自然留给模型
3. 画出技能之间的分支哪些技能有先后依赖、哪些失败要退回、哪些可以并行，画出来这段就是 Agent 的编排逻辑
4. 回头做一致性检查逐段问：有没有哪一步既让模型判断又要求结果必须一致？有就重划，这是最常见的隐患

拆完以后建议再走一遍反向验证：假设模型这次全部输出胡说，系统会怎么表现？如果只是追问或者转人工，说明边界划得还行；如果直接写错数据或者卡死，说明某个环节对模型的输出太信任了。

几个常见的划错边界的样子

这几种错法的共同点，都是把「谁负责什么」搅在了一起。粒度细不一定好，粒度粗也不一定差，判断依据是出了问题时你能不能一眼定位到是哪一层。定不到，就说明该重划了。

出问题时按这个顺序排查

Agent 出问题最怕乱试。看到一个不正常的结果，先别急着换模型或者改提示词，那通常是最后一步。按从输入到执行的顺序往下排，多数问题在前两步就能定位。

• 先看日志里模型实际拿到的输入，确认是信息没给够，还是给了但它理解偏了
• 再看技能被调用时的真实参数，很多问题是模型给了看似合理但字段名或格式不对的参数
• 然后看编排的分支有没有走对，重点是重试和降级路径是不是按预期触发
• 最后才考虑换模型或调提示词，前面三层没排干净，换模型只是把错误换个地方发生

如果团队刚开始做这件事，可以先把每次调用的输入输出落到日志里，哪怕格式很粗糙。没有这层记录，上面的排查顺序一步都走不动，只能靠猜。想对照主流接口在结构化输出、长上下文这些维度的实际差异，可以到站内的模型资料库按维度筛一遍，注意看当下的条目，