最近一段时间，我一直在折腾一个很有意思的项目——agent-skills。先别被这个英文名唬住，翻译过来就是“智能体技能库”。你可以把它理解成：给大模型装上“手”和“眼睛”的地方，或者说，是给AI智能体量身定制的一套工具箱和操作手册。如果你正在做智能体开发，无论是接一个简单的查询需求，还是搭一套复杂的工作流，大概率都会碰到“技能怎么设计、怎么管理、怎么调用”这个坎。这条经验帖，我会把整个项目从思路拆解到落地实现的完整过程掰开揉碎，分享一些干货和踩坑心得，希望对正在做或准备做Agent相关开发的同学有实际帮助。先说清楚它能解决什么问题。很多人做智能体，第一个版本就是“模型加提示词”，让大模型去聊天。但一旦涉及具体动作，比如查天气、算费用、发请求、读数据库，光是提示词就不够用了，你必须有实际的可执行代码。agent-skills解决的就是这一层：把一个个可复用的技能做成标准化模块，让大模型在推理过程中能精准地发现技能、理解技能、调用技能。它的存在，相当于给了大模型一张“能力清单”，把原来只能聊天的AI，变成了一个能干事儿的AI。这个项目到底怎么做？适合谁来参考？如果你是智能体应用开发者、AI产品经理、后端工程师，或者只是对大模型应用层感兴趣，这篇文章都能给你一套可落地的思路，而且每一步都会交代清楚“为什么这样做”，而不是只丢一堆抽象概念。1. 项目定位与核心需求拆解1.1 什么是“技能”，它和普通函数有什么区别在agent-skills这个项目里，“技能”不是简单一个函数，而是一个完整的、可被大模型理解和调用的功能单元。一个技能通常包含三件事：这个技能是干什么的（自然语言描述），需要什么参数（结构化输入），能返回什么结果（标准化输出）。普通函数是给程序员用的，调用方是人，接口文档写得再潦草，人能看懂。但技能是给大模型用的，模型的“阅读理解能力”和“参数推理能力”决定了设计约束完全不同。你必须用模型最容易理解的描述方式，把功能边界说清楚，把参数约束表达好，否则它就会在推理时乱点鸳鸯谱，或者给出乱七八糟的缺参。举个例子，我在项目里写过两个功能从表面上看差不多的技能：一个是“查询订单状态”，一个是“查询订单物流轨迹”。订单状态是内部信息，返回是否发货、是否签收；物流轨迹是外部物流接口，返回每一站的扫描记录。如果描述写得不清楚，模型就可能拿查物流的参数去调查询状态，结果自然是错误一堆。技能的描述准确度，直接决定了调用的成功率，这一点在后期调试里会反复验证。1.2 核心需求：从“能用”到“好用”的四个层次我在项目启动之初，先给自己定了四个需求层次，每次迭代都是沿着这条线往前推的。第一层，能用——技能能被找到。大模型拿到用户请求之后，能从技能列表里选择一个或多个匹配的技能。这要求技能描述和用户意图之间能建立关联，属于最基础的可用性。第二层，能调——技能能被正确调用。模型不光选对了技能，还要能按照技能定义的参数格式，正确生成JSON参数。这一层最容易出问题，因为模型对参数类型、必填项的理解往往不如程序员那么严谨，需要反复调优描述和校验逻辑。第三层，能容错——调用失败时系统能自救。真正上线后你很快就会发现，模型调用技能不可能100%成功。参数缺失、格式错误、外部接口超时、返回数据里混入非预期的字段，各种状况都可能出现。所以技能的容错设计，包括参数校验后的二次修正、错误信息的标准化返回，都是决定体验的关键。第四层，能进化——技能可以持续迭代。技能不是写一次就完了，业务变，技能也要跟着变。当技能数量到达几十个，如何让模型在庞大的技能库里快速定位，又不会因为技能太多而“看花眼”，就变成了一个信息检索和排序问题。这四个层次，恰好就是agent-skills项目的主线。每一层往下走，都会遇到新的坑，也得用不同的手段去填。1.3 为什么不用现成的框架，非要自己搭一套做技能管理，市面上确实有一些框架和工具能帮助构建Agent，它们自带插件机制和工具调用能力。那为什么还要自己搭？答案很简单：框架给的是骨架，技能体系是肉。大部分通用框架只会规定“技能是什么格式”“技能怎么注册”，但它不会告诉你怎么设计描述、怎么组织技能目录、怎么处理模型幻觉带来的错误调用。而这些细枝末节，恰恰是决定智能体靠不靠谱的核心环节。我自己的体会是，技能库的工程质量，决定智能体的智商上限。模型本身的推理能力再强，如果技能模块写得一塌糊涂，最终效果也一定拉胯。自己搭建，能够完全掌控技能的描述规范、运行机制、目录管理方式，调试起来也会更顺手。等到你明确理解了技能体系运作的原理，再去用框架里的插件机制，你会发现自己能一眼看出问题的根源到底在哪里。2. 方案选型：两种技能加载思路的权衡2.1 技能描述是“塞进提示词”还是“让模型自己找”搭建agent-skills时，首先要解决一个问题：模型的上下文窗口有限，不可能把所有技能的详细描述都塞进提示词。当技能数量超过十个，光是把描述列表放进去，就可能挤占掉宝贵的推理空间，而且模型面对太多选择，注意力会被稀释，反而选不准。我在早期的实验里试过一种最笨的办法：每次请求都把所有技能的描述拼接进系统提示词。技能只有5个时，效果还不错，模型选得挺精准。但等技能数量增长到十几个，我明显能感觉到模型开始“犯迷糊”，有时会漏掉明显更匹配的技能，有时会把A技能的功能描述曲解成B技能的，调用准确率直线下降。后来我换了一个思路：分两步走。第一步，根据用户请求，在一个轻量级的技能索引中做粗筛选，选出最相关的三五个技能；第二步，把这些技能的完整描述拼进提示词，再让模型做最终决策。这就相当于给模型划了一个“考试范围”，而不是让它从整本百科全书里找答案。粗筛这一步的效果极其关键。我用了一个非常朴素但有效的方法：给每个技能打上关键词标签，再用文本相关性做召回。虽然方法传统，但稳定性出奇地好。实际项目中，与其一开始就上向量检索，不如先用标签和关键词把范围缩小，为后续的精确排序减轻负担。这种分层召回的思路后来也一直保留在项目里。2.2 参数校验是“相信模型”还是“多层防守”大模型在生成参数时，出现格式问题的概率远比想象中高。最典型的问题是：模型明明读了描述里的“int类型”，却偏要输出一个带了双引号的字符串；必填项漏传；枚举值没有从给定的列表里选，而是自己脑补了一个新的值。项目推进初期，我对模型的信任度偏高，只在技能内部加了一组简单的类型断言，结果测试阶段就暴露了大问题。某些用户会用很口语化的方式表达需求，模型在理解时一旦“自由发挥”，往往会弄出许多不存在的参数值，导致下游接口直接抛异常。后面我彻底改成“多层防守”的方式：第一层，技能描述中明确标注参数类型、取值范围、默认值。比如，在“查询订单”技能里，不要只写“订单号是字符串”，而是写“订单号是平台生成的数字字符串，长度在10到18位之间”，这样模型能更准确地生成参数。第二层，在技能执行前的入口增加统一的参数校验器。校验器能处理类型转换（把字符串形式的数字变成真正的number），能识别缺参并尝试从对话上下文里再次抽取，能检查枚举值的合法性。第三层，校验不通过时，不直接抛错，而是返回一段“需要补充什么信息”的结构化提示。这个提示会回到模型那里，让模型根据提示重新生成参数或向用户提问。这一层极其重要，相当于给了整个调用闭环一个自我纠错的机会。2.3 技能执行器的模式选择：函数调用还是协议通信在这个项目中，我调研过两种执行模式：一种叫函数直调（把技能代码作为本地函数执行），另一种叫协议通信（通过HTTP/消息队列和独立服务通信）。如果技能逻辑很轻量、和主程序共享进程，函数直调无论在性能还是复杂度上都是最优解。但一旦技能涉及独立的资源消耗、需要并发处理、或者要接入异构技术栈的模块，拆成独立服务会更合理。以我的经验来看，实践中至少会碰到两类技能：一类是通用型小技能，比如文本格式化、数值计算、日期转换，这类技能逻辑简单，直接函数直调就够，做成独立服务纯属浪费资源；另一类是业务型大技能，比如对接第三方接口拉取风控数据、生成报表、调用内部算法模型，这类技能往往有独立的超时控制和数据依赖，拆出来更好维护。agent-skills在设计上采用了一个折中方案：技能模块内部支持两种注册方式，默认用函数直调，遇到特殊场景再标记为远程服务调用。这样做的好处是，本地技能的开发调试效率特别高，远程技能又保证了可扩展性，不会把自己锁死在一个进程里。3. 核心机制与代码实现3.1 技能注册：用装饰器写一个极简的注册中心技能的注册机制是整个项目的地基。在地基设计上，我选择用Python装饰器做一个极简的注册中心。核心想法是：程序员写一个普通函数，加一行装饰器，这个函数就自动变成可被大模型调用的技能。不需要额外维护注册表文件，也不会因为忘了登记而出现技能“失踪”的情况。# skill_registry.py import inspect from dataclasses import dataclass, field from typing import Callable, Any @dataclass class Skill: name: str description: str func: Callable parameters: dict tags: list = field(default_factory=list) _registry: dict[str, Skill] = {} def skill(name: str, description: str, parameters: dict, tags: list = None): def decorator(func): _registry[name] = Skill( name=name, description=description, func=func, parameters=parameters, tags=tags or [] ) return func return decorator def get_all_skills() -> list[Skill]: return list(_registry.values()) def get_skill_by_name(name: str) -> Skill: return _registry.get(name)这段代码看着简单，但有个容易被忽略的设计点：技能参数描述中增加json-schema风格的约束。刚开始我的parameters只写了“name、type、required”三个字段，后来发现这远远不够。模型完全理解不了“order_id”到底该传什么样的值。我需要补充“description”来解释业务含义，补充“pattern”来约定格式，比如订单号可以是字符串或整数，但如果给了字符串，内部得会转。优先级最高的原则是：让模型少猜，让代码多校验。参数schema里的每个细节，都是在帮模型减少自由度。你给它清晰的边界，它才能给你可靠的输出。3.2 技能实现示例：查询订单状态我举一个实际示例，让你能直观感受到“技能”到底长什么样。假设我们要做一个“查询订单状态”的技能，逻辑本身很简单，但为了适应模型调用，代码要写得非常谨慎。from datetime import datetime import re from skill_registry import skill @skill( name="query_order_status", description=( "根据用户提供的订单号查询当前订单状态。" "订单号是平台生成的数字字符串，通常以'SO'开头，长度为12到20个字符。" "如果用户提供了多个订单号，本技能只处理第一个；" "如果用户未提供订单号，请将order_id字段留空，不要随意编造。" ), parameters={ "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，以'SO'开头的字母数字组合", "pattern": "^SO[A-Za-z0-9]{9,17}$" } }, "required": ["order_id"] }, tags=["订单", "交易", "状态查询"] ) def query_order_status(order_id: str) -> dict: # 这里对接内部的订单服务 if not re.match(r"^SO[A-Za-z0-9]{9,17}$", order_id): return { "code": 400, "error": "订单号格式不正确", "hint": "请检查订单号是否完整，例如SO2024010100001" } # 模拟查询结果 if order_id == "SO2024010100001": return { "code": 200, "data": { "order_id": order_id, "status": "已发货", "shipped_at": "2024-05-20 14:30:00", "carrier": "某快递公司", "tracking_no": "SF1234567890" } } else: return { "code": 404, "error": "订单不存在", "hint": "该订单号在系统中没有记录，请确认订单号是否准确" }这个例子能说明几个实操要点。技能返回必须统一用结构化的JSON包裹，就算内部异常，也要转成code加error的格式返回。这样上层模型才能根据结构化信息做下一步判断，而不是面对一段毫无逻辑的报错文本发懵。描述里对“未提供订单号”做了明确的兜底指示，这是实操中很关键的一个细节。模型在参数生成阶段最怕的就是“编造”，它会因为没有强制约束而给你编一个长得像订单号的假数据。有了这句提示，模型会更倾向于把字段留空，然后交给下游参数校验器去决定是追问用户还是走其他兜底逻辑。3.3 模型调用循环：让Agent学会“技能调用”有了技能注册中心，接下来需要写一个模型调用循环，让大模型能够自主决定调用哪个技能、生成参数、处理结果。这个循环是整个agent-skills的灵魂。我写了一个简化版的调用引擎，核心逻辑如下：def run_agent(user_input: str, max_rounds: int = 5): messages = [{"role": "system", "content": build_system_prompt()}] # 第一步：根据用户输入做技能粗召回 candidate_skills = recall_skills(user_input, top_k=5) messages[0]["content"] += render_skills(candidate_skills) messages.append({"role": "user", "content": user_input}) for round_idx in range(max_rounds): resp = llm.chat(messages=messages, tools=build_tool_schemas(candidate_skills)) # 如果模型没有调用技能，直接输出回答给用户 if not resp.tool_calls: return resp.content # 如果模型调了技能，按顺序执行并回填结果 for tool_call in resp.tool_calls: skill_name = tool_call.function.name args = json.loads(tool_call.function.arguments) sk = get_skill_by_name(skill_name) try: result = sk.func(**args) except Exception as e: result = {"code": 500, "error": f"技能执行异常: {str(e)}"} messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) # 再让模型基于工具结果生成最终回答或进行下一步调用 return "抱歉，处理轮次过多，请简化需求后重试。"这里有三个花了很多精力调优的细节：第一个是让系统提示词动态渲染技能描述，而不是静态写一段死文本。原因前面已经说过，技能一多，全量塞给模型会溃不成军。粗筛召回后，只把最相关的几个技能渲染进提示词，模型的选择准确率高很多。第二个是工具调用后的结果必须回填到对话上下文。模型看完工具返回的数据之后，才能组织语言输出给用户。如果不回填，模型就相当于“没手”的将军，指挥了半天，不知战果如何。第三个是最大轮次限制。如果放任模型无限循环地调用工具，它可能因为反复得到错误结果而陷入死循环。加上轮次上限，并在超限后给出一句兜底回复，是从工程上防止失控的基本手段。3.4 技能清单管理：通过索引与命名空间给技能分类技能数量到了几十个以后，“管理”就成了比“开发”更棘手的问题。为了不让技能库乱成一锅粥，我引入了三个机制：命名空间、显式索引、规范标签。命名空间是技能名的前缀，比如“order.”代表订单域，“user.”代表用户域，“pay.*”代表支付域。这样做的好处是：一来看名字就知道技能归属，二来在粗召回时可以直接按域过滤，效率高很多。显式索引指的是维护一份精简的技能索引表，索引里只保留技能名、一句话功能摘要、命名空间、标签四类信息。这份索引用在粗召回阶段就足够用了，不需要把完整的参数schema全部加载出来比对，能省下不少开销。SKILL_INDEX = [ { "namespace": "order", "name": "query_order_status", "summary": "查询订单当前状态，包括是否发货、签收节点", "tags": ["订单", "物流", "状态"] }, { "namespace": "order", "name": "cancel_order", "summary": "取消未发货的订单，已发货订单需要额外申请", "tags": ["订单", "取消", "售后"] }, # ... 更多技能 ]规范标签是给技能打的通用分类词，通常控制在三到五个之间。标签的价值在于和用户意图做模糊匹配时特别顶用。用户说的话往往不包含你的技能名，但可能会包含“取消”“退款”这类业务词汇，标签就是在这层意义上建立桥接。3.5 技能结果解析与回复生成技能调用完成后，模型不是直接把返回数据原样发给用户，而是需要基于返回数据“再说人话”。这一步处理得不好，用户体验会直线下降。想象一下，用户问“我的快递到哪了”，你直接回一串JSON，这显然不合适。我在reply生成阶段加了一个小开关：普通结果让模型重新组织语言，敏感结果强制使用模板输出。像订单金额、用户隐私信息这类数据，即使模型拿到了数值，我也会要求它必须放在固定模板的槽位里，不能自由发挥。从安全角度出发，这一步非常必要。另外，技能返回的数据里常常有冗余字段。模型在组织回复时偶尔会不由自主地暴露内部字段名，比如返回里有个“risk_flag”，模型就直接对用户说“您的订单风险标志是false”。这种回复用户根本听不懂，而且会引发猜疑。后来我在返回数据上做了一层包装，把内部字段名都改成语义化标签，比如“risk_flag”改成“订单状态正常”，从源头避免模型翻译翻车。4. 避坑指南与常见问题排查4.1 模型“张冠李戴”：总是选错技能怎么办开发过程中最让人头秃的问题就是：模型明明应该选择A技能，却偏偏调了B技能，B技能跟A技能在功能上只有一点点沾边。这种情况通常有几种原因，排查的思路也不一样。第一个原因是描述不够长、不够具体。比如“查询订单状态”和“查询订单物流”两个技能，如果只分别写“查询订单状态”和“查询物流信息”，模型很容易混淆。解决方法是把两者的差异写进描述里：查询订单状态强调的是“是否发货、是否签收”，查询物流强调的是“每一站的扫描记录、当前位置”。把准确的功能边界说清楚，模型的判断准确率能提升一大截。第二个原因是粗召回阶段就把正确的技能漏掉了。粗召回结果的准确性是最终准确率的上限，如果粗召回阶段排除了正确技能，后面模型再聪明也白搭。此时需要检查索引的标签是否覆盖了用户意图的各种表达方式。比如用户说“我的东西怎么还没到”，在这个场景里要能匹配到“物流”标签，而不是只匹配“订单”标签。第三个原因是候选技能集里混入了严重干扰项。如果一次请求召回了十个技能，其中八个都和用户意图毫无关系，模型的注意力就会涣散。解决方法是严格控制top_k的值，宁可少一点，让候选更精准。我在实际项目里常用top_k=4，比起top_k=8，准确率反而更高。4.2 “幻觉参数”：模型编造了不存在的订单号另一种高频问题，就是模型在用户没有提供订单号的情况下，硬是编了一个像模像样的订单号去调接口。这种“幻觉参数”问题，靠参数校验器只能发现错误，却不能让调用链条走下去。我当时的处理方案是“两步拦截”。第一步是在技能描述里写明：如果没有提供该参数，请把字段留空，不要编造。第二步是在参数校验器里，如果发现必填字段为空，就返回一个特殊的“参数缺失”错误码，并且附带一句提示：“请向用户询问订单号”。模型拿到这句提示后，往往不会立刻报错，而是会主动向用户追问。循环一轮之后，信息就补全了，整个体验非常顺滑。这类“软纠错”的设计比直接报错要高明得多，因为在真实对话场景里，用户很可能就是忘了给完整信息，系统能够识别空缺并主动补齐，才是一个成熟智能体该有的样子。4.3 技能返回太乱，模型无法消化还有一个常踩的坑：技能返回的数据结构层次过深、字段太多，模型处理起来力不从心。比如一个查询接口把所有关联信息一股脑返回，订单信息里套商品列表、商品列表里套库存明细，模型在生成回复时就会顾此失彼，经常丢掉关键信息。面对这种情况，我采取了一个很实用的拆解策略：一个技能只干一件事，返回结构保持扁平。如果确实需要关联信息，就把不同信息封装成多个粒度更小的技能，让模型分步调用。比如先查订单基本信息，如果用户想要商品详情，再让模型调用另一个技能去查商品。这个过程虽然多了几轮调用，但每一轮的输入输出都足够清晰，模型的稳定性和可解释性都会大幅提升。这一点我后来想明白了：在Agent开发里，粒度合适的小技能比复杂的大技能更有价值。因为模型本质上是一个“注意力有限的多步规划器”，你给它塞太多信息，它反而处理不过来。减少每一步的认知负担，让每一步都走得扎实，才是系统稳定的关键。4.4 多轮对话中的技能状态丢失最后说一下多轮对话的问题。很多Agent在单轮对话里表现得很好，但一旦有多轮上下文，模型可能会在第二轮忘记刚才已经查过的订单号，或者错误地重复调用同一个技能。解决这个问题要从两个层面入手。第一，在提示词构造时明确告诉模型：如果用户没有明确要求重复查询，不要重复调用已经调用过的技能。这个约束看着简单，但对模型的重复调用率有明显的压降效果。第二，在技能调用循环里维护一个“已调用技能”的列表，如果模型再次发起同一个技能的调用，系统会在执行前提示“该技能已在上一轮调用过，是否需要强制刷新”。有了这层提示，模型就能重新评估当前用户意图，减少无效调用。另外一个相关的小技巧是：在每轮工具返回的内容中，加上一个“查询时间”字段。这样模型区分新旧数据就有依据，尤其是涉及状态类查询时，这个字段能帮助模型做出“数据已经过时，需要重新查询”的判断。5. 性能优化与扩展方向5.1 让技能调用更快的几个优化手段每个技能调用都会经过“模型推理生成参数”和“技能代码执行”两个阶段，前者通常是主要的耗时来源。为了压减耗时，我试过几招，实测下来都有明显收益。用更小的模型做粗召回。粗召回不涉及复杂推理，用一个小参数模型或甚至文本匹配算法就能完成。让大模型只在几个候选技能里做选择，推理负担大大降低，响应速度自然也提上去了。技能schema精简。技能描述不是越长越好，而是要每个字都用在刀刃上。能说明白功能边界的不必要展开说内部实现，能一句话说清参数格式的不要写一段小作文。schema精简之后，模型生成参数的速度也会更快，因为模型输入和输出的token数量都减少了。开启流式输出。如果多轮调用中需要等待模型最终回复，可以先让用户看到一部分中间状态，比如“正在查询订单信息…”，然后再输出结果。这样即使底层耗时没有减少，用户的等待体感也会好很多。5.2 从技能库升级到技能生态当前的agent-skills已经能支撑一个中等体量的业务系统，但下一个阶段的探索方向，我觉得是“技能生态化”。所谓生态化，不只是让技能越来越多，而是让技能之间可以协作。比如，用户想取消订单并退款，这个流程可能需要三个技能顺序协作：先“查询订单状态”判断是否可退，再“取消订单”，最后“发起退款”。将来可以把这类标准流程固化下来，编辑成“工作流技能”。模型调用工作流技能之后，就会自动编排一系列原子技能的执行，而不是每一步都靠模型自己临时规划。另一个令人兴奋的方向就是技能的自动生成能力。让大模型根据需求文档自动生成技能描述和参数schema，可以进一步降低开发成本。这个方向我还在实验中，目前碰到的主要问题是自动生成的schema通常不够稳定，参数边界和类型约束会有些错漏，还需要人工校准。但假以时日，这个方向成熟后，“写技能”这件事本身就会变成一种智能化工作。5.3 技能质量监控与回归测试技能体系的持续迭代离不开测试和监控。我在这套项目里建立了一套每天定时运行的测试流水线，里面包含两组核心测试用例。第一组是功能测试，直接调用技能函数，传入各种参数，验证返回结果是否符合预期。这组用例主要用来保障技能本身的代码质量。第二组是模型调用测试，把一批有代表性的用户话术批量喂给Agent，检查模型是否正确选择了目标技能、参数是否构成合法调用、最终回复是否覆盖了核心信息。这组用例的价值在于：即使技能代码本身没问题，模型对技能的理解和使用方式也可能因为描述变更而退化。测试结果出来后，我会重点追踪两个指标：技能选择的准确率、参数生成的成功率。如果某个技能连续多次在测试中被选错，说明它的描述有问题；如果某个技能参数频繁校验失败，说明schema和真实用户意图之间有偏差。这两套指标，是衡量一套技能库健康度的最直接标准。我在实际项目中还加了调用日志分析，每次模型调用工具都会记录完整的“用户输入、候选技能、最终选择、生成参数、执行结果”。这些日志沉淀下来，就是最宝贵的调优素材。很多时候，你不需要猜模型为什么错，直接翻日志就能看到它当时的决策依据。我个人在多次迭代和踩坑之后，最深的一个体会是：做Agent，本质上是在做“约束管理”。你给大模型越清晰的边界、越规范的接口、越可控的流程，它能发挥出来的能力就越大。放任自由发挥的Agent，下场往往不是聪明，而是失控。而agent-skills这套技能库的设计，正是把“边界”嵌入到每一个环节里——从描述到schema，从校验到兜底，一层层地替模型扫清不确定性。虽然开发过程中时常被各种奇奇怪怪的调用问题折磨，但当技能库跑顺了，看到用户的需求被准确拆解、一步步靠技能自动完成时，那种成就感是纯粹的提示词聊天完全无法比拟的。这个项目后续还会继续迭代，下一步我打算重点完善自动化的技能评估和监控体系，让技能库能够自我感知“正在退化”的部分，提前干预而不是等问题爆发后再补救。
最近一段时间，我一直在折腾一个很有意思的项目——agent-skills。先别被这个英文名唬住，翻译过来就是“智能体技能库”。你可以把它理解成：给大模型装上“手”和“眼睛”的地方，或者说，是给AI智能体量身定制的一套工具箱和操作手册。如果你正在做智能体开发，无论是接一个简单的查询需求，还是搭一套复杂的工作流，大概率都会碰到“技能怎么设计、怎么管理、怎么调用”这个坎。这条经验帖，我会把整个项目从思路拆解到落地实现的完整过程掰开揉碎，分享一些干货和踩坑心得，希望对正在做或准备做Agent相关开发的同学有实际帮助。先说清楚它能解决什么问题。很多人做智能体，第一个版本就是“模型加提示词”，让大模型去聊天。但一旦涉及具体动作，比如查天气、算费用、发请求、读数据库，光是提示词就不够用了，你必须有实际的可执行代码。agent-skills解决的就是这一层：把一个个可复用的技能做成标准化模块，让大模型在推理过程中能精准地发现技能、理解技能、调用技能。它的存在，相当于给了大模型一张“能力清单”，把原来只能聊天的AI，变成了一个能干事儿的AI。这个项目到底怎么做？适合谁来参考？如果你是智能体应用开发者、AI产品经理、后端工程师，或者只是对大模型应用层感兴趣，这篇文章都能给你一套可落地的思路，而且每一步都会交代清楚“为什么这样做”，而不是只丢一堆抽象概念。1. 项目定位与核心需求拆解1.1 什么是“技能”，它和普通函数有什么区别在agent-skills这个项目里，“技能”不是简单一个函数，而是一个完整的、可被大模型理解和调用的功能单元。一个技能通常包含三件事：这个技能是干什么的（自然语言描述），需要什么参数（结构化输入），能返回什么结果（标准化输出）。普通函数是给程序员用的，调用方是人，接口文档写得再潦草，人能看懂。但技能是给大模型用的，模型的“阅读理解能力”和“参数推理能力”决定了设计约束完全不同。你必须用模型最容易理解的描述方式，把功能边界说清楚，把参数约束表达好，否则它就会在推理时乱点鸳鸯谱，或者给出乱七八糟的缺参。举个例子，我在项目里写过两个功能从表面上看差不多的技能：一个是“查询订单状态”，一个是“查询订单物流轨迹”。订单状态是内部信息，返回是否发货、是否签收；物流轨迹是外部物流接口，返回每一站的扫描记录。如果描述写得不清楚，模型就可能拿查物流的参数去调查询状态，结果自然是错误一堆。技能的描述准确度，直接决定了调用的成功率，这一点在后期调试里会反复验证。1.2 核心需求：从“能用”到“好用”的四个层次我在项目启动之初，先给自己定了四个需求层次，每次迭代都是沿着这条线往前推的。第一层，能用——技能能被找到。大模型拿到用户请求之后，能从技能列表里选择一个或多个匹配的技能。这要求技能描述和用户意图之间能建立关联，属于最基础的可用性。第二层，能调——技能能被正确调用。模型不光选对了技能，还要能按照技能定义的参数格式，正确生成JSON参数。这一层最容易出问题，因为模型对参数类型、必填项的理解往往不如程序员那么严谨，需要反复调优描述和校验逻辑。第三层，能容错——调用失败时系统能自救。真正上线后你很快就会发现，模型调用技能不可能100%成功。参数缺失、格式错误、外部接口超时、返回数据里混入非预期的字段，各种状况都可能出现。所以技能的容错设计，包括参数校验后的二次修正、错误信息的标准化返回，都是决定体验的关键。第四层，能进化——技能可以持续迭代。技能不是写一次就完了，业务变，技能也要跟着变。当技能数量到达几十个，如何让模型在庞大的技能库里快速定位，又不会因为技能太多而“看花眼”，就变成了一个信息检索和排序问题。这四个层次，恰好就是agent-skills项目的主线。每一层往下走，都会遇到新的坑，也得用不同的手段去填。1.3 为什么不用现成的框架，非要自己搭一套做技能管理，市面上确实有一些框架和工具能帮助构建Agent，它们自带插件机制和工具调用能力。那为什么还要自己搭？答案很简单：框架给的是骨架，技能体系是肉。大部分通用框架只会规定“技能是什么格式”“技能怎么注册”，但它不会告诉你怎么设计描述、怎么组织技能目录、怎么处理模型幻觉带来的错误调用。而这些细枝末节，恰恰是决定智能体靠不靠谱的核心环节。我自己的体会是，技能库的工程质量，决定智能体的智商上限。模型本身的推理能力再强，如果技能模块写得一塌糊涂，最终效果也一定拉胯。自己搭建，能够完全掌控技能的描述规范、运行机制、目录管理方式，调试起来也会更顺手。等到你明确理解了技能体系运作的原理，再去用框架里的插件机制，你会发现自己能一眼看出问题的根源到底在哪里。2. 方案选型：两种技能加载思路的权衡2.1 技能描述是“塞进提示词”还是“让模型自己找”搭建agent-skills时，首先要解决一个问题：模型的上下文窗口有限，不可能把所有技能的详细描述都塞进提示词。当技能数量超过十个，光是把描述列表放进去，就可能挤占掉宝贵的推理空间，而且模型面对太多选择，注意力会被稀释，反而选不准。我在早期的实验里试过一种最笨的办法：每次请求都把所有技能的描述拼接进系统提示词。技能只有5个时，效果还不错，模型选得挺精准。但等技能数量增长到十几个，我明显能感觉到模型开始“犯迷糊”，有时会漏掉明显更匹配的技能，有时会把A技能的功能描述曲解成B技能的，调用准确率直线下降。后来我换了一个思路：分两步走。第一步，根据用户请求，在一个轻量级的技能索引中做粗筛选，选出最相关的三五个技能；第二步，把这些技能的完整描述拼进提示词，再让模型做最终决策。这就相当于给模型划了一个“考试范围”，而不是让它从整本百科全书里找答案。粗筛这一步的效果极其关键。我用了一个非常朴素但有效的方法：给每个技能打上关键词标签，再用文本相关性做召回。虽然方法传统，但稳定性出奇地好。实际项目中，与其一开始就上向量检索，不如先用标签和关键词把范围缩小，为后续的精确排序减轻负担。这种分层召回的思路后来也一直保留在项目里。2.2 参数校验是“相信模型”还是“多层防守”大模型在生成参数时，出现格式问题的概率远比想象中高。最典型的问题是：模型明明读了描述里的“int类型”，却偏要输出一个带了双引号的字符串；必填项漏传；枚举值没有从给定的列表里选，而是自己脑补了一个新的值。项目推进初期，我对模型的信任度偏高，只在技能内部加了一组简单的类型断言，结果测试阶段就暴露了大问题。某些用户会用很口语化的方式表达需求，模型在理解时一旦“自由发挥”，往往会弄出许多不存在的参数值，导致下游接口直接抛异常。后面我彻底改成“多层防守”的方式：第一层，技能描述中明确标注参数类型、取值范围、默认值。比如，在“查询订单”技能里，不要只写“订单号是字符串”，而是写“订单号是平台生成的数字字符串，长度在10到18位之间”，这样模型能更准确地生成参数。第二层，在技能执行前的入口增加统一的参数校验器。校验器能处理类型转换（把字符串形式的数字变成真正的number），能识别缺参并尝试从对话上下文里再次抽取，能检查枚举值的合法性。第三层，校验不通过时，不直接抛错，而是返回一段“需要补充什么信息”的结构化提示。这个提示会回到模型那里，让模型根据提示重新生成参数或向用户提问。这一层极其重要，相当于给了整个调用闭环一个自我纠错的机会。2.3 技能执行器的模式选择：函数调用还是协议通信在这个项目中，我调研过两种执行模式：一种叫函数直调（把技能代码作为本地函数执行），另一种叫协议通信（通过HTTP/消息队列和独立服务通信）。如果技能逻辑很轻量、和主程序共享进程，函数直调无论在性能还是复杂度上都是最优解。但一旦技能涉及独立的资源消耗、需要并发处理、或者要接入异构技术栈的模块，拆成独立服务会更合理。以我的经验来看，实践中至少会碰到两类技能：一类是通用型小技能，比如文本格式化、数值计算、日期转换，这类技能逻辑简单，直接函数直调就够，做成独立服务纯属浪费资源；另一类是业务型大技能，比如对接第三方接口拉取风控数据、生成报表、调用内部算法模型，这类技能往往有独立的超时控制和数据依赖，拆出来更好维护。agent-skills在设计上采用了一个折中方案：技能模块内部支持两种注册方式，默认用函数直调，遇到特殊场景再标记为远程服务调用。这样做的好处是，本地技能的开发调试效率特别高，远程技能又保证了可扩展性，不会把自己锁死在一个进程里。3. 核心机制与代码实现3.1 技能注册：用装饰器写一个极简的注册中心技能的注册机制是整个项目的地基。在地基设计上，我选择用Python装饰器做一个极简的注册中心。核心想法是：程序员写一个普通函数，加一行装饰器，这个函数就自动变成可被大模型调用的技能。不需要额外维护注册表文件，也不会因为忘了登记而出现技能“失踪”的情况。# skill_registry.py import inspect from dataclasses import dataclass, field from typing import Callable, Any @dataclass class Skill: name: str description: str func: Callable parameters: dict tags: list = field(default_factory=list) _registry: dict[str, Skill] = {} def skill(name: str, description: str, parameters: dict, tags: list = None): def decorator(func): _registry[name] = Skill( name=name, description=description, func=func, parameters=parameters, tags=tags or [] ) return func return decorator def get_all_skills() -> list[Skill]: return list(_registry.values()) def get_skill_by_name(name: str) -> Skill: return _registry.get(name)这段代码看着简单，但有个容易被忽略的设计点：技能参数描述中增加json-schema风格的约束。刚开始我的parameters只写了“name、type、required”三个字段，后来发现这远远不够。模型完全理解不了“order_id”到底该传什么样的值。我需要补充“description”来解释业务含义，补充“pattern”来约定格式，比如订单号可以是字符串或整数，但如果给了字符串，内部得会转。优先级最高的原则是：让模型少猜，让代码多校验。参数schema里的每个细节，都是在帮模型减少自由度。你给它清晰的边界，它才能给你可靠的输出。3.2 技能实现示例：查询订单状态我举一个实际示例，让你能直观感受到“技能”到底长什么样。假设我们要做一个“查询订单状态”的技能，逻辑本身很简单，但为了适应模型调用，代码要写得非常谨慎。from datetime import datetime import re from skill_registry import skill @skill( name="query_order_status", description=( "根据用户提供的订单号查询当前订单状态。" "订单号是平台生成的数字字符串，通常以'SO'开头，长度为12到20个字符。" "如果用户提供了多个订单号，本技能只处理第一个；" "如果用户未提供订单号，请将order_id字段留空，不要随意编造。" ), parameters={ "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，以'SO'开头的字母数字组合", "pattern": "^SO[A-Za-z0-9]{9,17}$" } }, "required": ["order_id"] }, tags=["订单", "交易", "状态查询"] ) def query_order_status(order_id: str) -> dict: # 这里对接内部的订单服务 if not re.match(r"^SO[A-Za-z0-9]{9,17}$", order_id): return { "code": 400, "error": "订单号格式不正确", "hint": "请检查订单号是否完整，例如SO2024010100001" } # 模拟查询结果 if order_id == "SO2024010100001": return { "code": 200, "data": { "order_id": order_id, "status": "已发货", "shipped_at": "2024-05-20 14:30:00", "carrier": "某快递公司", "tracking_no": "SF1234567890" } } else: return { "code": 404, "error": "订单不存在", "hint": "该订单号在系统中没有记录，请确认订单号是否准确" }这个例子能说明几个实操要点。技能返回必须统一用结构化的JSON包裹，就算内部异常，也要转成code加error的格式返回。这样上层模型才能根据结构化信息做下一步判断，而不是面对一段毫无逻辑的报错文本发懵。描述里对“未提供订单号”做了明确的兜底指示，这是实操中很关键的一个细节。模型在参数生成阶段最怕的就是“编造”，它会因为没有强制约束而给你编一个长得像订单号的假数据。有了这句提示，模型会更倾向于把字段留空，然后交给下游参数校验器去决定是追问用户还是走其他兜底逻辑。3.3 模型调用循环：让Agent学会“技能调用”有了技能注册中心，接下来需要写一个模型调用循环，让大模型能够自主决定调用哪个技能、生成参数、处理结果。这个循环是整个agent-skills的灵魂。我写了一个简化版的调用引擎，核心逻辑如下：def run_agent(user_input: str, max_rounds: int = 5): messages = [{"role": "system", "content": build_system_prompt()}] # 第一步：根据用户输入做技能粗召回 candidate_skills = recall_skills(user_input, top_k=5) messages[0]["content"] += render_skills(candidate_skills) messages.append({"role": "user", "content": user_input}) for round_idx in range(max_rounds): resp = llm.chat(messages=messages, tools=build_tool_schemas(candidate_skills)) # 如果模型没有调用技能，直接输出回答给用户 if not resp.tool_calls: return resp.content # 如果模型调了技能，按顺序执行并回填结果 for tool_call in resp.tool_calls: skill_name = tool_call.function.name args = json.loads(tool_call.function.arguments) sk = get_skill_by_name(skill_name) try: result = sk.func(**args) except Exception as e: result = {"code": 500, "error": f"技能执行异常: {str(e)}"} messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) # 再让模型基于工具结果生成最终回答或进行下一步调用 return "抱歉，处理轮次过多，请简化需求后重试。"这里有三个花了很多精力调优的细节：第一个是让系统提示词动态渲染技能描述，而不是静态写一段死文本。原因前面已经说过，技能一多，全量塞给模型会溃不成军。粗筛召回后，只把最相关的几个技能渲染进提示词，模型的选择准确率高很多。第二个是工具调用后的结果必须回填到对话上下文。模型看完工具返回的数据之后，才能组织语言输出给用户。如果不回填，模型就相当于“没手”的将军，指挥了半天，不知战果如何。第三个是最大轮次限制。如果放任模型无限循环地调用工具，它可能因为反复得到错误结果而陷入死循环。加上轮次上限，并在超限后给出一句兜底回复，是从工程上防止失控的基本手段。3.4 技能清单管理：通过索引与命名空间给技能分类技能数量到了几十个以后，“管理”就成了比“开发”更棘手的问题。为了不让技能库乱成一锅粥，我引入了三个机制：命名空间、显式索引、规范标签。命名空间是技能名的前缀，比如“order.”代表订单域，“user.”代表用户域，“pay.*”代表支付域。这样做的好处是：一来看名字就知道技能归属，二来在粗召回时可以直接按域过滤，效率高很多。显式索引指的是维护一份精简的技能索引表，索引里只保留技能名、一句话功能摘要、命名空间、标签四类信息。这份索引用在粗召回阶段就足够用了，不需要把完整的参数schema全部加载出来比对，能省下不少开销。SKILL_INDEX = [ { "namespace": "order", "name": "query_order_status", "summary": "查询订单当前状态，包括是否发货、签收节点", "tags": ["订单", "物流", "状态"] }, { "namespace": "order", "name": "cancel_order", "summary": "取消未发货的订单，已发货订单需要额外申请", "tags": ["订单", "取消", "售后"] }, # ... 更多技能 ]规范标签是给技能打的通用分类词，通常控制在三到五个之间。标签的价值在于和用户意图做模糊匹配时特别顶用。用户说的话往往不包含你的技能名，但可能会包含“取消”“退款”这类业务词汇，标签就是在这层意义上建立桥接。3.5 技能结果解析与回复生成技能调用完成后，模型不是直接把返回数据原样发给用户，而是需要基于返回数据“再说人话”。这一步处理得不好，用户体验会直线下降。想象一下，用户问“我的快递到哪了”，你直接回一串JSON，这显然不合适。我在reply生成阶段加了一个小开关：普通结果让模型重新组织语言，敏感结果强制使用模板输出。像订单金额、用户隐私信息这类数据，即使模型拿到了数值，我也会要求它必须放在固定模板的槽位里，不能自由发挥。从安全角度出发，这一步非常必要。另外，技能返回的数据里常常有冗余字段。模型在组织回复时偶尔会不由自主地暴露内部字段名，比如返回里有个“risk_flag”，模型就直接对用户说“您的订单风险标志是false”。这种回复用户根本听不懂，而且会引发猜疑。后来我在返回数据上做了一层包装，把内部字段名都改成语义化标签，比如“risk_flag”改成“订单状态正常”，从源头避免模型翻译翻车。4. 避坑指南与常见问题排查4.1 模型“张冠李戴”：总是选错技能怎么办开发过程中最让人头秃的问题就是：模型明明应该选择A技能，却偏偏调了B技能，B技能跟A技能在功能上只有一点点沾边。这种情况通常有几种原因，排查的思路也不一样。第一个原因是描述不够长、不够具体。比如“查询订单状态”和“查询订单物流”两个技能，如果只分别写“查询订单状态”和“查询物流信息”，模型很容易混淆。解决方法是把两者的差异写进描述里：查询订单状态强调的是“是否发货、是否签收”，查询物流强调的是“每一站的扫描记录、当前位置”。把准确的功能边界说清楚，模型的判断准确率能提升一大截。第二个原因是粗召回阶段就把正确的技能漏掉了。粗召回结果的准确性是最终准确率的上限，如果粗召回阶段排除了正确技能，后面模型再聪明也白搭。此时需要检查索引的标签是否覆盖了用户意图的各种表达方式。比如用户说“我的东西怎么还没到”，在这个场景里要能匹配到“物流”标签，而不是只匹配“订单”标签。第三个原因是候选技能集里混入了严重干扰项。如果一次请求召回了十个技能，其中八个都和用户意图毫无关系，模型的注意力就会涣散。解决方法是严格控制top_k的值，宁可少一点，让候选更精准。我在实际项目里常用top_k=4，比起top_k=8，准确率反而更高。4.2 “幻觉参数”：模型编造了不存在的订单号另一种高频问题，就是模型在用户没有提供订单号的情况下，硬是编了一个像模像样的订单号去调接口。这种“幻觉参数”问题，靠参数校验器只能发现错误，却不能让调用链条走下去。我当时的处理方案是“两步拦截”。第一步是在技能描述里写明：如果没有提供该参数，请把字段留空，不要编造。第二步是在参数校验器里，如果发现必填字段为空，就返回一个特殊的“参数缺失”错误码，并且附带一句提示：“请向用户询问订单号”。模型拿到这句提示后，往往不会立刻报错，而是会主动向用户追问。循环一轮之后，信息就补全了，整个体验非常顺滑。这类“软纠错”的设计比直接报错要高明得多，因为在真实对话场景里，用户很可能就是忘了给完整信息，系统能够识别空缺并主动补齐，才是一个成熟智能体该有的样子。4.3 技能返回太乱，模型无法消化还有一个常踩的坑：技能返回的数据结构层次过深、字段太多，模型处理起来力不从心。比如一个查询接口把所有关联信息一股脑返回，订单信息里套商品列表、商品列表里套库存明细，模型在生成回复时就会顾此失彼，经常丢掉关键信息。面对这种情况，我采取了一个很实用的拆解策略：一个技能只干一件事，返回结构保持扁平。如果确实需要关联信息，就把不同信息封装成多个粒度更小的技能，让模型分步调用。比如先查订单基本信息，如果用户想要商品详情，再让模型调用另一个技能去查商品。这个过程虽然多了几轮调用，但每一轮的输入输出都足够清晰，模型的稳定性和可解释性都会大幅提升。这一点我后来想明白了：在Agent开发里，粒度合适的小技能比复杂的大技能更有价值。因为模型本质上是一个“注意力有限的多步规划器”，你给它塞太多信息，它反而处理不过来。减少每一步的认知负担，让每一步都走得扎实，才是系统稳定的关键。4.4 多轮对话中的技能状态丢失最后说一下多轮对话的问题。很多Agent在单轮对话里表现得很好，但一旦有多轮上下文，模型可能会在第二轮忘记刚才已经查过的订单号，或者错误地重复调用同一个技能。解决这个问题要从两个层面入手。第一，在提示词构造时明确告诉模型：如果用户没有明确要求重复查询，不要重复调用已经调用过的技能。这个约束看着简单，但对模型的重复调用率有明显的压降效果。第二，在技能调用循环里维护一个“已调用技能”的列表，如果模型再次发起同一个技能的调用，系统会在执行前提示“该技能已在上一轮调用过，是否需要强制刷新”。有了这层提示，模型就能重新评估当前用户意图，减少无效调用。另外一个相关的小技巧是：在每轮工具返回的内容中，加上一个“查询时间”字段。这样模型区分新旧数据就有依据，尤其是涉及状态类查询时，这个字段能帮助模型做出“数据已经过时，需要重新查询”的判断。5. 性能优化与扩展方向5.1 让技能调用更快的几个优化手段每个技能调用都会经过“模型推理生成参数”和“技能代码执行”两个阶段，前者通常是主要的耗时来源。为了压减耗时，我试过几招，实测下来都有明显收益。用更小的模型做粗召回。粗召回不涉及复杂推理，用一个小参数模型或甚至文本匹配算法就能完成。让大模型只在几个候选技能里做选择，推理负担大大降低，响应速度自然也提上去了。技能schema精简。技能描述不是越长越好，而是要每个字都用在刀刃上。能说明白功能边界的不必要展开说内部实现，能一句话说清参数格式的不要写一段小作文。schema精简之后，模型生成参数的速度也会更快，因为模型输入和输出的token数量都减少了。开启流式输出。如果多轮调用中需要等待模型最终回复，可以先让用户看到一部分中间状态，比如“正在查询订单信息…”，然后再输出结果。这样即使底层耗时没有减少，用户的等待体感也会好很多。5.2 从技能库升级到技能生态当前的agent-skills已经能支撑一个中等体量的业务系统，但下一个阶段的探索方向，我觉得是“技能生态化”。所谓生态化，不只是让技能越来越多，而是让技能之间可以协作。比如，用户想取消订单并退款，这个流程可能需要三个技能顺序协作：先“查询订单状态”判断是否可退，再“取消订单”，最后“发起退款”。将来可以把这类标准流程固化下来，编辑成“工作流技能”。模型调用工作流技能之后，就会自动编排一系列原子技能的执行，而不是每一步都靠模型自己临时规划。另一个令人兴奋的方向就是技能的自动生成能力。让大模型根据需求文档自动生成技能描述和参数schema，可以进一步降低开发成本。这个方向我还在实验中，目前碰到的主要问题是自动生成的schema通常不够稳定，参数边界和类型约束会有些错漏，还需要人工校准。但假以时日，这个方向成熟后，“写技能”这件事本身就会变成一种智能化工作。5.3 技能质量监控与回归测试技能体系的持续迭代离不开测试和监控。我在这套项目里建立了一套每天定时运行的测试流水线，里面包含两组核心测试用例。第一组是功能测试，直接调用技能函数，传入各种参数，验证返回结果是否符合预期。这组用例主要用来保障技能本身的代码质量。第二组是模型调用测试，把一批有代表性的用户话术批量喂给Agent，检查模型是否正确选择了目标技能、参数是否构成合法调用、最终回复是否覆盖了核心信息。这组用例的价值在于：即使技能代码本身没问题，模型对技能的理解和使用方式也可能因为描述变更而退化。测试结果出来后，我会重点追踪两个指标：技能选择的准确率、参数生成的成功率。如果某个技能连续多次在测试中被选错，说明它的描述有问题；如果某个技能参数频繁校验失败，说明schema和真实用户意图之间有偏差。这两套指标，是衡量一套技能库健康度的最直接标准。我在实际项目中还加了调用日志分析，每次模型调用工具都会记录完整的“用户输入、候选技能、最终选择、生成参数、执行结果”。这些日志沉淀下来，就是最宝贵的调优素材。很多时候，你不需要猜模型为什么错，直接翻日志就能看到它当时的决策依据。我个人在多次迭代和踩坑之后，最深的一个体会是：做Agent，本质上是在做“约束管理”。你给大模型越清晰的边界、越规范的接口、越可控的流程，它能发挥出来的能力就越大。放任自由发挥的Agent，下场往往不是聪明，而是失控。而agent-skills这套技能库的设计，正是把“边界”嵌入到每一个环节里——从描述到schema，从校验到兜底，一层层地替模型扫清不确定性。虽然开发过程中时常被各种奇奇怪怪的调用问题折磨，但当技能库跑顺了，看到用户的需求被准确拆解、一步步靠技能自动完成时，那种成就感是纯粹的提示词聊天完全无法比拟的。这个项目后续还会继续迭代，下一步我打算重点完善自动化的技能评估和监控体系，让技能库能够自我感知“正在退化”的部分，提前干预而不是等问题爆发后再补救。