1. 智能体为什么总在“能力”上掉链子Agent技能体系的核心问题去年我接了一个项目客户想做一个自动处理售后工单的智能体要求“用户说一句话它能自己判断问题类型、查订单、退换货、安抚客户全自动”。折腾了两个月换了好几个大模型接口效果始终差一口气——模型明明很强答得也对但一到真实业务场景就卡壳查不到订单、态度强硬地拒绝退款、让客户填了一堆重复信息。后来我把问题拆开看结论很扎心模型能力不等于业务能力。大语言模型确实能理解自然语言、能推理、能生成回复但要让它真正帮人干活靠的是模型之外的整套技能体系——技能怎么拆、工具怎么设计、流程怎么编排、结果怎么评测。这个体系我习惯叫它Agent Skills也就是智能体的技能栈。这篇内容我打算按自己踩坑的顺序来写先讲清楚智能体技能体系到底由哪几层构成再分别展开技能清单怎么梳理、工具层设计最容易栽在哪、多步骤任务怎么编排最后聊评测和调优。适合已经在用大模型接口做应用、但发现“单轮问答能跑通、一上真实业务就崩”的团队参考。如果你是刚要起步做Agent看完也能对整条技术链路有一个完整认识避免在最基础的架构设计上走弯路。先抛一个反直觉的结论Agent项目失败绝大多数不是模型的错而是技能体系没搭好。下面我会把这套体系的每一层拆开讲你对照着自己的项目查一遍大概率能找到病灶。2. 技能不等于工具Agent技能栈的四层结构与我整理的分类法很多教程把“给AI加技能”等同于“给AI接API”这是最大的误解。API只是最底层的基础设施真正支撑一个复杂业务任务的是一整套分层技能栈。2.1 四层技能栈工具层、领域技能层、工作流层、策略层我自己在项目里把智能体的能力体系分成四层每一层的职责非常明确第一层基础工具层Tool Layer。这是最底层的“手脚”包括搜索、数据库查询、代码执行、HTTP请求、文件读写、计算引擎等。它们的共同特点是通用、无业务含义任何一个Agent都能用。比如一个“查天气”功能本质上就是调用一个天气API它不关心你是在做旅游规划还是物流调度。第二层领域技能层Skill Layer。这是把基础工具组合成“会干某类活”的能力单元开始带业务语义了。比如“查询订单状态”这个技能它的实现可能是接收订单号 → 调订单API → 格式化结果 → 判断是否需要加急提醒。你不需要在每次对话里重新教模型怎么做技能本身封装了这套逻辑。第三层工作流层Workflow Layer。这层解决“先干什么、后干什么、干不成怎么办”的问题负责把多个技能按顺序串起来。比如完整处理一次售后工单先识别客户诉求 → 查订单 → 判断退换货条件 → 执行退款/换货 → 生成处理摘要。每一步可能是调用第二层的某个技能。第四层策略层Strategy Layer。这层决定Agent在什么情况下选哪个技能、用什么语气回复、哪些事直接拒绝、哪些事转人工。策略层的核心是规则和偏好的显式表达比如“金额超过500元的退款必须走人工审批”。这四层的核心区别是抽象程度和复用范围。工具层通用性最高策略层业务性最强。如果你只搭了工具层就开始跑业务模型暴露在大量脏乱的真实环境里必然频繁出错如果你把所有逻辑都写成死规则相当于跳过技能层那又回到了传统自动化Agent根本谈不上有“智能”。合理的做法是让工具层承载通用能力、技能层封装业务语义、工作流层负责过程控制、策略层兜底决策规则。2.2 我按“动作类型”做的技能分类法在实际梳理技能清单时我习惯把技能按“动作类型”分成四类这样设计技能边界时特别方便类型核心特征典型例子查询类只读、无副作用查库存、查订单、看天气操作类有副作用、需确认发邮件、创建工单、执行退款计算类处理数据、生成结果算折扣、生成报表、代码执行协作类调用其他子系统或人转人工客服、触发下游审批这个分类法是我踩了很多次坑才总结出来的。最典型的问题就是把所有技能都设计成“查询类”的Agent顺手就把退款操作执行了根本没有二次确认机制。用动作类型给每个技能贴一个标签你一眼就能看出哪些技能需要加确认环节、哪些技能是纯读操作不用过分防护。3. 技能落地第一步场景拆解与技能清单设计很多团队的Agent项目一开始就写代码接到什么工具就接什么工具最后技能之间职责重叠、参数混乱。我现在的习惯是动手写任何代码之前先做场景拆解产出一份技能清单。这一步看起来“不产生代码”实际上决定了后面80%的工作量和最终效果。3.1 用“场景-行为-产出”框架拆解业务场景拆解的核心是问三个问题用户在这个环节想要什么系统需要做什么做完之后产出什么我举一个完整例子——电商售后工单智能体场景用户行为输入系统所需技能产出查询物流“我的快递到哪了”解析订单号 → 查询物流API → 格式化物流轨迹物流状态文本预计送达时间发起退款“我要退货”校验订单状态 → 读取退款策略 → 执行退款登记 → 输出退款单号退款受理回执投诉补偿“你们的服务太差了赔我钱”意图识别 → 情感分析 → 匹配补偿策略 → 生成补偿方案补偿方案需人工确认标记转人工“我要投诉到底”判断情绪阈值 → 生成会话摘要 → 转人工接口转接记录摘要报文这个表格每行就是一个“技能需求”。注意一个关键点一个场景下不要列超过三到四个技能不然Agent的决策空间太大容易绕晕。如果场景实在复杂就继续往下拆子场景而不是在一个技能里塞太多能力。我遇到过一个团队把一个“智能客服”乱成一个技能里面既能查物流、又能退款、还能推荐商品结果模型经常搞混用户问物流AI推荐了同款商品。这就是技能边界不清的典型反例。技能清单里的每一项必须是职责清晰、输入输出明确的独立单元。3.2 技能卡片每个技能都要填完整“说明书”梳理出技能清单后我为每个技能建一张“技能卡片”字段大致如下技能名称动词对象如“QueryOrderStatus”避免抽象名词。触发条件什么样的用户输入会激活这个技能写清楚正例和反例。输入参数每个参数的名称、类型、是否必填、取值范围。执行逻辑技能内部调用了哪些工具/API顺序如何异常怎么处理。输出格式结构化输出还是自然语言文本包含哪些关键字段。边界与限制哪些情况绝对不能碰比如“查询订单技能不处理退货”。需要人工确认是/否操作类技能一般标“是”。别嫌这步麻烦。我见过太多团队直接给模型塞十个工具函数签名参数叫a、b、c描述只写一句话最后模型根本不知道该调哪个。技能卡片本质上是你与模型沟通的“接口文档”写不清楚模型就乱来写清楚了模型即便在推理上弱一点也不容易跑偏。提示写技能触发条件时一定要写清楚“不触发”的情况。比如一个查天气的技能触发条件里明确写“查询目的地为具体城市或地点的天气时触发如果用户只是说‘今天天气怎么样’但没有地点则不触发而是先追问地点”。这样能显著减少误调用。4. 工具层设计最容易翻车的三个点Schema、上下文与错误返回技能层是骨架真正落地时模型直接打交道的是工具层。我在多个项目里反复踩过同一类坑这里挑三个最典型、代价最大的问题展开。4.1 Tool Schema写得稀烂模型根本不会正确调用现在主流的大模型都支持通过函数调用Function Calling或工具使用Tool Use机制来触发外部能力。模型不是凭空知道你的工具怎么用的完全取决于你给的JSON Schema描述。以查询订单技能为例一个设计得不错的Schema长这样{ name: query_order_status, description: 根据订单号查询电商订单的当前状态。适用于用户询问物流进度、订单是否发货、是否签收等场景。仅用于查询不执行任何变更操作。, parameters: { type: object, properties: { order_id: { type: string, description: 用户的订单号格式为纯数字或字母通常在用户的输入中可以直接提取。如果用户没有提供不要猜测返回MISSING_FIELD错误。 }, include_tracking: { type: boolean, description: 是否返回物流跟踪轨迹。默认false当用户明确询问物流轨迹时设为true。, default: false } } }, required: [order_id] }我重点标出三个容易被忽略的设计细节第一description里一定要说明“什么时候用、什么时候不用”模型对工具的调用准确率很大程度取决于这句描述。上面例子里的“仅用于查询不执行任何变更操作”就是防止模型把查询和退货的意图混在一起。第二必填参数错误时不要自作聪明补默认值。很多开发者在order_id缺失时会让模型“从对话里猜一个”这是灾难级别的设计。猜错订单号查出来的是别人的订单再反馈给用户一旦涉及隐私就出大问题。正确做法是让模型返回MISSING_FIELD错误触发追问流程。第三布尔参数要设置默认值并写清楚触发条件。include_tracking这种布尔量控制的是输出内容的多寡如果默认值和描述不清晰模型会随机选导致返回结果时带追踪轨迹时又没有时而有。4.2 上下文灌得太满意图被淹没工具多了以后另一个常见问题就来了每个工具都把最详细的参数说明塞进系统提示词这是最常见的信息过载源头。我自己吃过一个惨痛教训早期项目里给系统提示词里塞了20多个工具的全部参数说明结果模型每次调用都把无关参数带上疯狂浪费token而且决策准确率明显下滑。后来我的处理方式很直接按意图动态加载工具。比如用户说“我要退货”系统先做一次轻量级意图识别只把退换货相关的4个技能校验订单、查策略、执行退款、转人工加载到上下文里其他工具全部扔出去。上层的技能路由通常是我自己写的一个小型分类器甚至就是模型的一个轻量调用负责决定加载哪一组的工具。这种方法看似多了一层逻辑实际上收益巨大每次请求的提示词长度从几千token降到几百成本大幅下降、速度明显提升。模型在少量候选工具里做选择准确率显著比在20个工具里“大海捞针”高。不相关的工具不会暴露给模型误用风险从源头降低。4.3 错误返回结构设计糟糕模型不会“自救”工具调用一定会失败这是常识。但大多数人设计的错误返回就是一行error: query failed模型根本不知道接下来该怎么办。我的做法是给每个工具的错误返回设计成结构化三段式——错误码、可读描述、修复建议。例如查询订单时订单不存在{ from: query_order_status, error_code: ORDER_NOT_FOUND, message: 系统中不存在订单号 202507010001 对应的订单记录。, suggestion: 请向用户核实订单号是否正确或询问用户是否从其他平台下单。切勿自行编造订单信息。 }模型看到suggestion字段就知道下一步是“追问用户”而不是“编造一个结果”。这种设计让整个Agent具备了基本的“自救能力”而不只是一报错就死机。提示错误码的命名要统一且可枚举比如以ORDER_、PAYMENT_、USER_开头后续做日志分析和评测时按错误码分类统计会非常方便。5. 技能编排从单个Skill到多Step工作流的控制逻辑技能层解决了“单个能力”但一个真实业务任务往往需要多个技能按特定顺序协作。这块就是技能编排Skill Orchestration的活。很多团队用LangChain或者Semantic Kernel这类框架用着用着就发现光靠编排框架自带的能力根本控制不了复杂业务。我的建议是先弄明白编排模型本身再决定框架怎么用。5.1 主流的三种编排模式对比我把项目里见过的编排模式归纳成三种各有各的适用场景。模式一顺序执行Pipeline。最直观的模式一个技能完成后结果喂给下一个技能。适合流程非常固定的场景比如“先查订单 → 再查退款策略 → 再执行退款”。这种模式简单、可解释性强、容易调试缺点是灵活度低一旦出现分支就无能为力。模式二模型自主决策ReAct。模型自己思考下一步调用哪个技能就是大家熟悉的“ReAct框架”那套模式。它灵活度高但可控性差、token消耗高而且多步之后很容易“忘记”前面的目标甚至跑偏方向。适合探索性任务比如“帮我调研一下某竞品最近一年的产品动态”走一步看一步没问题。模式三先规划后执行Plan-then-Execute。模型在动手前先产出一份完整的执行计划列出每一步需要调用的技能然后按计划逐项执行如果某一步执行失败模型再对计划进行局部修正。这种模式的代码比较复杂但保留了大模型灵活性的同时又把流程的“骨架”显式化了好追踪、好审计。我个人的选择标准流程固定时用Pipeline流程灵活但风险不高时用ReAct流程较为复杂、每一步都涉及真实操作退款、发信等时用Plan-then-Execute。没有银弹只有适配。5.2 我需要一个简单的“技能编排”伪代码我用一个“售后退款”流程来演示Plan-then-Execute的骨架逻辑很多人会照抄LangChain的AgentExecutor但实际自己实现一版并不复杂反而只有几百行就能获得全部控制权。伪代码如下async function handle_refund_request(user_message, context): # 第一步提取关键信息生成初步计划 plan llm.generate_plan( task售后退款处理, available_skills[extract_order_id, query_order_status, check_refund_policy, execute_refund, escalate_to_human], user_messageuser_message ) # 示例返回: [extract_order_id, query_order_status, check_refund_policy, execute_refund] # 第二步按计划逐步执行 for step in plan.steps: result await skills[step.action].run(step.params) if result.status SUCCESS: context.update(result.data) continue if result.status ERROR: # 根据错误类型决定是修正计划还是终止 if result.error_code ORDER_NOT_FOUND: return ask_user_for_order_id() elif result.error_code PERMISSION_DENIED: return escalate_to_human(退款越权转人工处理) else: new_plan llm.revise_plan(plan, result, available_skills) if new_plan.changed: plan new_plan continue else: return 抱歉暂时无法处理您的请求已升级到人工客服。 # 第三步汇总全部中间结果生成最终回复 final_reply llm.compose_response(context, user_message) return final_reply注意这个伪代码里两个关键点一是check_refund_policy和execute_refund之间凭空多了一个“策略校验”这是我在真实项目被坑出来的。早期设计里模型直接从“查订单”跳到“执行退款”中间缺少权限校验结果用户凌晨三点发起退款系统直接给退了——如果退款金额大或者条件不满足后果很麻烦。凡涉及资金、权限、隐私的技能务必在计划里强制插入一个独立的权限校验步骤。第二点llm.revise_plan并不是万能的。计划修正的次数要设上限我一般设定为最多尝试2次超过上限就直接转人工。这既避免无限循环带来的成本浪费也保证用户永远有一条“见到真人”的出口。5.3 多技能协作时的上下文管理我的一卷式传递方案多步骤流程里技能之间需要传递数据。早期我用的是“每个技能自己解析前置技能的完整输出”结果经常冗余、冲突、漏字段。后来我改成每个技能只从共享上下文中读取自己声明的输入字段并把输出结果统一写入上下文里一个带命名空间的位置。例如上下文长这样{ order_service: { order_id: ORD20250101, status: SHIPPED, items: [iPhone 16 Pro, MagSafe充电器] }, refund_policy: { is_eligible: true, refund_basis: 7天无理由, max_refund_amount: 8999 }, conversation: { user_emotion_level: HIGH, summary: 用户情绪激动要求立即退款 } }每个技能在开场时明确声明“我读什么、我写什么”前场技能只对自己负责的字段做读写不碰别家的数据。这种“面向字段的上下文管理”看起来笨但有三个直接的好处字段冲突大幅减少不再出现两个技能同时写同一个字段的竞态问题。技能可以并行执行只要它们读写的字段没有重叠为后续性能优化留了口子。出问题时你能很快定位到是哪个技能写了哪个错误字段。6. 没有评测就没有技能迭代我用的Agent评估与回归方案技能体系设计得再漂亮不评测就是空话。我在项目里见过太多次这种场景prompt调了半天感觉“好像变聪明了”但问几个新例子又露馅再回头调陷入死循环。根源是没有一套结构化的评测体系。6.1 评测维度不要只看“最终答案对错”一开始我也只拿“最终输出是不是成功”来评判Agent好坏后来发现这不够。举例来说一个售后机器人把退款办成功了看起来是满分但细看日志发现它中间用了违规的流程分支只是结果歪打正着。所以我后来把评测拆开成四个层面任务成功率最终有没有达到用户的核心目标如退款完成、查询结果准确。过程合规率每一步是否走的是预设流程有没有跳过权限校验、有没有调用不该调用的技能。单轮交互质量每一轮回复是否通顺、是否解决了用户当前的局部诉求。成本与延迟每单任务平均token消耗、平均耗时。这一项在规模化后非常关键直接影响成本与转化率。评测维度评测方式合格线参考任务成功率人工标注LLM裁判≥85%新手上线阶段过程合规率日志回放规则校验≥95%单轮交互质量满意度结构化打分≥4/5每单Token消耗指标统计与基线数据比较涨跌不超过20%请不要一上来就追求单测100%的准确率那会把你逼到绝路。我用过的口径是先以85%任务成功率作为上线标准然后靠线上真实反馈和日志复盘持续提升。设定一个“够用的及格线”不要让评测工程本身变成项目的最大成本。6.2 评测集和回归测试是我调优的命根子做过传统软件测试的人对“回归测试”都很熟。Agent项目也要做回归只是测的不是接口函数而是“技能调用序列是否合理”。我维护的评测集分为三个部分真实历史工单从客服系统导出脱敏后的真实对话覆盖最高频的50个业务场景。人工构造的边界用例比如超长订单号、客户不提供订单号直接问物流、退款金额为零、跨平台订单等等。边界用例专门用来打模型的“思维盲区”。对抗用例用户用刁钻的表达方式来绕规则比如“你没给我发货还不赔钱我要去投诉你”。这类用例主要测策略层的底线防止Agent被话术带偏。每次调整技能描述、工具Schema或流程编排都先跑一遍这组评测集。只有评测集上的表现不降我才敢推到线上。没有评测集就反复改prompt就是在盲人摸象。6.3 线上Agent的日志与复盘机制线下评测做得再好线上真实流量仍然会超出你的想象。我要求所有Agent项目必须把日志落全至少包含每个请求的完整输入、模型中间推理如果可记录、每个技能调用的入参和出参、错误码、最终回复、人工标注结果。有了日志才能做“失败聚类”——把线上失败的案例按原因归堆。我常用的聚类维度是意图识别错了用户想退货识别成想查询。参数提取错了订单号提取多了一位数字。权限策略漏了退款未校验金额上限。回复观感太差流程对了但语气机械用户不满意。每个聚类类别都是一个明确的优化点。比如“参数提取错了”通常意味着你的Schema描述不够细致那就去补描述、加示例“权限策略漏了”说明流程编排里缺校验步骤那就去改计划模板。复盘的意义不在于“修一个bug”而在于发现“哪一层技能栈设计没有覆盖到”。提示评测集别往一个目录乱堆最好建一个Git仓库评测用例和评测脚本一并管理。每次改动技能定义后CI里自动跑一遍评测集把“谁的改动把准确率拉低了”直接定位到具体commit。7. 从零搭一套“最小可用Agent技能库”的完整流程理论讲了一堆最后给各位一个可以直接照着做的最小闭环。不依赖任何重型框架我用最朴素的工具搭了一套“技能库工具路由编排脚本”的玩法效果稳定、便于扩展。7.1 我实际采用的技能注册与路由机制我不用LangChain这类重框架来组织技能而是自己定义了一个很薄的技术结构每个技能就是一个标准的Python类实现execute(params, context)接口其中有对返回结果的规范序列化然后有一个技能注册表把技能名称、触发关键词、所属意图组、权限等级等信息登记在案。skill_registry/ ├── registry.json # 技能清单含名称、意图组、参数Schema ├── skills/ │ ├── query_order.py │ ├── check_refund_policy.py │ ├── execute_refund.py │ └── escalate_human.py └── router.py # 意图识别函数决定加载哪些技能到上下文router.py里做的并不是什么高大上的机器学习而是一个轻量的分类函数先用一个字符串匹配或小模型做粗粒度意图分类然后根据意图分类加载对应的技能子集。技能子集的信息再拼接到后续送给主模型的系统提示词中。整个过程逻辑清晰谁来接手都能看懂。为什么这样设计而不是全交给一个Agent框架核心原因在于可控性。框架帮你做了很多默认决策但出问题时你很难定位是框架的哪个环节出了问题。自己实现这套结构代码量在几百行量级所有的判断逻辑你都有完整的控制权也方便日后按业务需要加权限、加日志、加监控。7.2 上线前的动作清单我检查自己的四个问题每次要发布一个新技能或改动技能配置我都会过一遍下面的清单技能边界清不清楚这个技能的输入输出、触发条件、不触发条件是否都写进Schema描述里了。权限和确认机制挂没挂上操作类技能有没有二次确认涉及资金/隐私的操作有没有独立的权限校验步骤。评测集过了没拿历史真实用例新用例跑一遍任务成功率不掉、过程合规率达标才允许上线。日志和监控能不能回溯每个技能调用的入参出参、错误码、耗时、token是否都能从日志查得到。这四条看起来很简单但坚持执行下来Agent项目的返工率会显著下降。我见过不少团队能力模型选得很强却在技能边界、权限校验、日志监控这些“不性感”的细节上反复折腾消耗了大量时间。7.3 先跑通最小闭环再扩展技能树最后聊一个心态层面的建议。Agent项目特别容易陷入“技能规划完美主义”的陷阱比如一上来就想实现20个技能、完美覆盖所有场景。我个人建议的节奏是先选一个最核心、最高频的场景用一个技能库跑通端到端闭环。别贪多就做“查订单状态自动回复”这一个闭环上线跑两周把日志、评测、复盘整个流程走顺。跑通之后再逐步扩展技能树。每一轮扩展都带着上一轮的数据和评测体系你会越做越顺手。我自己的体会是智能体项目本质上不是一个“一次性开发完”的产品而是一个不断打磨的技能运营体系。一开始能跑通一个最小闭环比规划五六个大功能却一个都跑不顺重要得多。先把核心链路走通让模型和用户都形成正反馈再慢慢加技能、加流程、加策略。这条路我走下来感觉是最稳的。最后分享一个小技巧无论技能多少永远给Agent留一条转人工的路。技能再强也有兜不住的时候用户的耐心是有限的。这个底线设计好Agent项目无论怎么迭代都不会出大问题。