做智能体这两年我踩过最深的坑就是给 Agent 无脑堆 Skills。一开始装五六个感觉什么都能干装到二十多个开始偶尔犯傻装到五六十个连文献检索这种基础操作都会给你选错工具。项目群里隔三差五就有人问AI 怎么越装越笨了这不是玄学是系统结构问题。今天拿科研场景开刀把Skill 越多越笨背后的机制一次说清楚再看看 SchoAI 这类新一代编排框架是怎么把技能堆砌真正变成能力组织的。这篇东西适合正在搭科研智能体、或者手上 Agent 技能已经多到失控的朋友不管你是用现成框架还是自己写编排逻辑里面这套思路都能直接参考。1. 为什么 Skill 越装越多智能体反而越用越笨先说结论智能体变笨不是大模型本身退化了而是你给它的环境越来越糟糕。Skill 的本质是一段带触发条件和调用方式的工具描述它要占用上下文、要参与路由决策、要跟其他 Skill 抢注意力。这三个环节任何一个被撑爆整体表现就会肉眼可见地下降。1.1 上下文窗口不是无限仓库而是带轮子的小工作台很多人把上下文窗口理解成仓库觉得 128K tokens 很大装几百个 Skill 没问题。这个类比是错的。上下文窗口更像一张工作台——你随时要在这张台子上写东西、翻资料、操作工具台子上堆的东西越多你能铺开的图纸就越少。我自己的实测数据一个科研 Skill 的元数据、工具 schema、触发条件、示例参数折算下来平均要吃掉 400 到 600 tokens。装 60 个科研 Skill光系统提示词里的技能描述就是 3 万 tokens 左右。听着还行但问题在于这 3 万 tokens 是每轮对话都要重复计费的固定开销不管这轮任务用不用得上它们都牢牢占着窗口挤占真正用于推理和输出的空间。更麻烦的是注意力稀释。Transformer 的注意力机制在超长上下文里会出现迷失中间现象模型对窗口开头和结尾的内容敏感对中间大段技能描述容易忽略。我做个很简单的实验上下文里塞 60 个 Skill然后问模型你有哪些跟文献去重相关的技能它经常把文献管理和数据清洗里带 deduplication 字段的描述搞混。技能越多这种混淆越频繁因为每个 Skill 的描述都在争夺那一点注意力配额。1.2 技能路由在候选集爆炸时开始看走眼Skill 的调用通常靠路由——要么是模型直接读全部描述做选择要么是嵌入向量检索找最相近的几条。两种方式都有同一个命门候选集越大准确率越低。直接让模型做全量选择时60 个 Skill 意味着每次调用都要做一次 60 选 1 的判断题。模型在这件事上的表现很像考试时面对一道以下哪个工具最适合查 PubMed 综述的多选题——选项越多它越容易把看起来都沾边的项混在一起。我在一个 40 个科研 Skill 的项目里统计过路由准确率从 8 个技能时的 96% 一路掉到了 71%近四分之一的调用选错了工具。嵌入向量检索也没好到哪去。思路是靠语义相似度召回 Top-K 再交给模型但科研领域的技能描述高度相似生成论文摘要和润色论文摘要、提取文献关键数据和抽取实验结论——这些描述的向量距离非常近Top-K 里全是长得差不多的兄弟技能。阈值调紧了正确技能被过滤掉阈值调松了噪声全进来了模型的二次判断压力反而更大。1.3 工具描述挤占了大模型真正用来思考的空间还有一个容易被忽略的点工具 schema 的格式开销。OpenAI 风格的 function calling、Anthropic 的 tool use每一个工具的 JSON Schema 都要带参数名、类型、描述、枚举值、必填项。这部分 token 不参与语义理解纯粹是格式负担。更糟的是模型为了保证调用格式正确会在生成工具调用前反复检查格式把本该用于推理的 token 预算花在了格式合规上。我抓过日志一个包含 50 个 Skill 的智能体单次工具调用的平均推理 token 比 10 个 Skill 时高了 38%但任务完成率反而低了 12%。钱花多了活干砸了典型的边际递减。指标5 个 Skill20 个 Skill60 个 Skill技能描述占用上下文~3k tokens~12k tokens~35k tokens路由准确率~98%~90%~70%工具调用平均延迟1.2s2.1s3.8s简单任务完成率100%92%78%上面这张表是我在多个项目里取的中位数不同模型会浮动但趋势是一致的Skill 数量和性能不是线性关系而是过了一个拐点之后断崖式下跌。1.4 功能重叠的 Skill 互相打架还很难发现最后一个坑藏得最深Skill 之间的隐性冲突。你装一个文献综述撰写又装一个论文引言生成单看都合理但它们的触发条件高度重叠。模型在处理写作任务时可能先调综述工具生成一段又调引言工具改一遍两个工具基于不同的 prompt 模板和格式要求输出风格互相打架最后生成的内容四不像。这种冲突在测试时很难发现因为每个 Skill 单独验收都是通过的合在一起才会暴露。而且冲突是概率性的——有时模型选 A 有时选 B日志里看不出报错就是结果忽好忽坏。Skill 数量越多这种两两冲突的组合数按平方级增长到四五十个技能时冲突几乎不可避免。2. SchoAI 换个思路不追求装得多而追求组得好既然问题出在所有技能同时挤在上下文里那解法就很明确了别让不用的技能占地方。SchoAI 的核心思路就是把传统智能体那种平铺式技能库改造成分层组织、按需加载、流程编排的结构。这个思路本身不复杂难的是执行得足够细腻。2.1 先把科研能力分层领域底座、技能注册表、工作流编排SchoAI 把智能体的能力分成了三层这个分层是所有后续机制的基础。第一层是领域底座也就是科研通用能力包括文献检索、术语理解、学科知识库。这一层是常驻的但数量被严格控制在 5 到 8 个以内只保留最高频、最不可能冲突的核心能力。第二层是技能注册表。注意注册表不等于加载列表——所有技能都在注册表里有完整定义但默认不进入上下文只在被需要时才被拉取。注册表里存的不是工具描述全文而是精简索引技能 ID、适用科研阶段、输入输出摘要、依赖关系。这就像图书馆的卡片目录目录再厚也不占书架空间。第三层是工作流编排器负责把科研流程拆成阶段每个阶段决定加载哪些技能、按什么顺序调用。这正是传统智能体框架几乎不做的事——传统方式只有一层技能列表而 SchoAI 多加了一个什么时候用什么技能的决策层。2.2 按需加载只有当前科研阶段需要的 Skill 才进入上下文按需加载是 SchoAI 最核心的机制说穿了就一句话Skill 是被召唤出来的不是被陈列出来的。科研流程可以拆成几个典型阶段选题调研、文献综述、实验设计、数据采集、结果分析、论文写作、投稿准备。每个阶段真正用到的技能其实很少。做文献综述时你需要的是检索、去重、分类、摘要抽取可能就四五个技能做实验设计时你需要的是流程规划、可行性分析、实验记录模板又是另外四五个。SchoAI 的做法是智能体启动时只加载领域底座那 5 到 8 个常驻技能然后根据当前科研阶段从注册表里动态加载 3 到 5 个阶段技能。整个上下文里的技能总数始终控制在 10 个左右而不是 60 个。这就把前文说的注意力稀释、路由混乱、token 浪费三个问题一次性解决了。实现上按需加载靠的是阶段状态机和技能入口条件的配合。每个技能都声明自己适用于哪个科研阶段工作流推进到新阶段时上一阶段技能被自动卸载新阶段技能被加载。模型当前在做的事会被映射到一个阶段状态而不是让模型自己在 60 个技能里猜。2.3 工作流编排把散装 Skill 变成科研流水线按需加载解决了上下文干净的问题工作流编排解决的是顺序正确的问题。传统智能体的技能调用是模型自由发挥的——先调哪个后调哪个全看模型心情。SchoAI 则把科研流程变成了可编排的流水线。以写一篇文献综述为例工作流可以这样定义workflow: literature_review stages: - id: retrieval load_skills: [pubmed_search, semantic_scholar_search, crossref_lookup] output: raw_paper_list - id: screening load_skills: [dedup, relevance_filter, quality_score] input: raw_paper_list output: screened_papers - id: synthesis load_skills: [theme_extraction, argument_mapping, citation_formatter] input: screened_papers output: review_outline - id: writing load_skills: [academic_writing, reference_check] input: review_outline output: final_manuscript每一步的输出是下一步的输入技能按阶段加载上一阶段结束立即释放 token 空间。这样做的好处不只是省 token——更重要的是每步的上下文里只存在当前该用的技能模型不会被要不要用综述润色工具这种无关选择干扰。工作流还允许定义分支和回退。比如筛选阶段发现文献质量普遍不够可以回退到检索阶段补充关键词再跑一轮。这种可回退的流程控制是传统平铺式技能库做不到的传统方式里模型如果判断错误往往就在错误的路径上一路走到黑。2.4 实测对比同样是 60 个科研 Skill两种组织的差距有多大我把自己一个生物信息学科研项目里的 60 个技能分别用传统平铺方式和 SchoAI 的分层编排方式跑了两组测试对比结果很有意思。传统方式下系统提示词里塞了全部 60 个技能描述上下文 35k tokens 全是工具定义。第一个问题模型把基因富集分析和通路注释两个技能搞混了跑出来的是错误的富集结果。第二个问题文献检索阶段模型试图调用论文写作相关技能来整理检索结果因为那些技能的触发条件写得太宽。SchoAI 方式下启动时只加载了 6 个底座技能进入文献检索阶段后加载了 4 个检索类技能整个流程的上下文工具开销峰值只有 8k tokens。同类任务路由准确率回到 95% 以上平均输出质量评分从 6.2 分涨到 8.5 分而且错误模式的种类从 7 种降到了 1 种。我还特意测了一个极端情况一个技能在注册表里存在但当前阶段没被加载智能体还会不会用到它答案是几乎不会。因为阶段的边界把调用范围锁死了模型的选择空间被大幅收窄。这就是能力越多越好用的秘密——不是模型变强了而是它每次面对的选项变少了决策质量自然就上去了。3. 在 SchoAI 上配置科研 Skills 的实操要点光讲理念没用得能落地。我把自己在科研项目里配置 Skill 的完整套路整理出来包括注册表怎么写、上下文预算怎么分、参数怎么调。这套东西你可以直接抄。3.1 Skill 注册表怎么写一份可直接套用的元数据模板注册表的质量决定了按需加载的效果。我实践下来一个 Skill 的注册信息至少要有下面这些字段skill_id: pubmed_search name: PubMed 文献检索 domains: [biomedical, life_science] applicable_stages: [retrieval, screening] description_short: 按关键词检索 PubMed 文献返回标题、摘要、PMID input_summary: search_query: str, max_results: int, date_range: str output_summary: papers: list[dict] conflict_group: literature_search_group entry_condition: 当前任务涉及文献获取或引文补充 priority: high几个关键点的设计原因description_short 要短但要准。这段文字是注册表索引的核心也是路由匹配的主要依据。不要写长段落用动词 对象 输出的句式比如按关键词检索 PubMed 文献返回标题摘要。短描述在向量匹配和模型阅读理解两方面都更不容易出错。conflict_group 是防冲突的关键字段。我在第 1.4 节说过功能重叠的 Skill 会互相干扰。用 conflict_group 把相似的技能归组同组内只允许加载一个由工作流根据当前阶段决定加载哪个。比如文献综述生成和引言生成归到 writing_group综述阶段加载前者论文开头写作阶段加载后者永远不同时出现。entry_condition 要写成可判断的条件不是模糊描述。不要写当用户需要帮助时这种废话要写当前任务涉及文献获取或引文补充这种可被工作流状态机硬判断的条件。条件越明确按需加载的决策就越稳定。3.2 三级上下文预算让每个环节都知道自己能花多少 token按需加载解决了该加载谁的问题上下文预算解决的是加载后用多少的问题。我把 Token 预算分成三级每一级都有硬上限第一级是全局系统预算占总上下文窗口的 40%。这里面包含人格设定、领域底座技能、全局安全规则。这一级是雷打不动的不管跑什么任务都要保底。第二级是工作流预算占 35%。这一级分配给当前阶段的技能描述、工作流状态、阶段间传递的结构化数据。按需加载进来的技能它们的 token 开销就从这一级里出。第三级是任务预算占 25%。这一级留给当前任务的原始输入、中间推理、输出草稿。可以用下面的公式估算全局预算 窗口大小 × 0.4阶段技能可用空间 窗口大小 × 0.35 - 已固定的工作流状态 token如果阶段技能描述总长超出可用空间触发精简加载只加载描述最精简的 Top-N 个剩余技能保持注册状态。这个三级预算的好处是让技能加载这件事有边界感。以前遇到的问题是技能描述越长留给实际任务的窗口就越小。现在预算一卡技能描述长度和数量都有了硬约束不用靠感觉。3.3 科研场景的调参参考温度、检索阈值、冲突分组科研智能体和通用助手在参数上有明显差异我列几个实测下来比较稳的设置参数推荐值说明温度0.2 - 0.4科研输出需要严谨温度太高容易编造文献路由 Top-K3 - 5K 太大噪声多K 太小容易漏掉正确技能向量匹配阈值0.72 - 0.80低于阈值直接丢弃不进入模型二次判断conflict_group 大小≤ 3同组技能超过 3 个说明粒度太粗需要拆分阶段技能描述 token 上限≤ 80注册表索引描述超过就精简正文放加载后再说温度这条我要多说两句。科研智能体最怕幻觉尤其是文献引用幻觉——模型会生成一篇看起来完全合理但其实根本不存在的参考文献。SchoAI 的做法是在写作阶段强制挂一个引文校验技能每生成一条引用就去 Crossref 或 PubMed 检索验证。温度调低 引文校验技能强制加载双保险下来幻觉引用率能从 15% 降到 2% 左右。科研场景还有个容易被忽视的点实验数据的可复现性。传统智能体跑完数据分析就完了工具调用参数、中间结果都不留痕。我在工作流里加了一个实验记录技能专门把每个环节的输入输出、参数设置、版本号落盘。跑完一次全流程分析能直接生成一份可复现的实验报告。这个技能不参与分析但它是整个科研工作流里性价比最高的技能之一。4. 踩坑实录科研智能体 Skill 管理的常见问题与排查配置做得再细实际跑起来还是会遇到奇奇怪怪的问题。我把自己在科研智能体项目里踩过的坑、排查的思路、最终解决办法都列出来当个速查表用。4.1 症状装完新 Skill老任务反而失败了这是最多人遇到的问题我自己也中过招。给智能体加了一个实验方案生成技能之后原来跑得好好的文献去重任务开始频繁报错模型每次都去调用新技能而不是去重技能。排查思路是这样的先看新技能是不是跟旧技能在同一个 conflict_group 下。如果是说明触发条件撞了。再看新技能的 entry_condition 是不是写得太宽——当任务涉及数据处理这种跨度极大的条件会把大量无关任务吸引过来。最后用消融法验证把新技能临时禁掉跑一遍老任务如果恢复正常基本锁定就是新技能干扰。解决方法是三选一改窄 entry_condition把新技能移到更精确的 applicable_stages或者给两个技能加同一个 conflict_group让工作流决定谁上场。记住一个原则新技能上线必须先跑一遍原有任务的回归测试不能只测新技能本身。4.2 症状智能体在几个 Skill 之间来回打转我遇到过一次特别典型的循环模型在数据清洗和格式转换两个技能之间反复调用第一次清洗完转成格式 A第二次又清洗一遍转回格式 B来回三次结果反而把数据搞乱了。排查后发现根因是两个技能的输入输出 schema 里都宣称接受任意格式数据、输出标准格式彼此都觉得自己应该处理当前数据于是进入了我洗了你再转、你转了我再洗的死循环。解决办法是在工作流里加有向无环约束明确数据清洗必须发生在格式转换之前并且在流程状态机里记录数据清洗已完成这个状态后续技能看到状态标记就不会再触发清洗。更通用的做法是给每个技能加post_condition字段声明调用完成后应该满足什么状态工作流每次决策前先检查状态能极大减少这种循环震荡。4.3 症状结果质量下降但日志看不出报错这个最折磨人——没有报错、没有超时、工具调用全部成功但生成的研究方案就是比以前差。我排查过很多次之后发现常见真凶有两个。第一个是上下文碎片化。按需加载技能时如果上一阶段的技能描述没有完全释放或者阶段间传递的数据格式不统一上下文里会堆积大量半成品信息干扰模型判断。检查方法是打印每一轮的上下文组成看技能描述占比是否超过了 35% 的预算线。第二个是技能描述被悄悄截断。有些模型对超长 system prompt 会自动截断注册表里写的 80 token 描述可能实际只生效了前 40 token后半段的关键约束全丢了。解决方法是建一个简单的提示词健康检查脚本定期把实际发送给模型的完整 system prompt dump 出来人工检查比对注册表定义和实际内容是否一致。4.4 排查工具清单与自检流程排查不要靠猜要建立一套可重复的流程。我的自检顺序是这样的第一步看路由日志。确认每个技能调用是怎么被选中的——是向量检索命中的还是模型直接判断的命中分数是多少低于 0.7 的直接标记为低置信调用。第二步看上下文预算报表。统计每个环节的技能描述 token、工作流状态 token、任务数据 token 的占比任何一项超过额定预算都会引起隐性退化。第三步做最小复现。把失败任务抽出来只保留当前阶段需要的技能其余全部禁用看问题是否消失。这个消融实验是定位问题的最快路径。第四步对照 4.1 到 4.3 的症状表查原因锁定方向后修复最后跑一次全回归。症状可能的根因排查切入点快速修复老任务失败新技能干扰路由检查 conflict_group、entry_condition禁新技能做消融验证技能调用循环schema 互认 状态缺失检查工作流状态标记加 post_condition 约束质量隐性下降上下文碎片化/描述截断dump 实际 system prompt精简阶段数据格式路由选错技能候选集过大或阈值过低查 Top-K 命中分数调整阈值、缩小候选集文献幻觉写作阶段缺少校验抓生成引用的来源字段强制挂载引文校验技能我把这套排查流程固化成了一个脚本工具每次跑完科研任务自动生成诊断报告包含路由日志摘要、上下文预算占比、异常调用标记。这样问题复现时不用重新翻聊天记录看报告就能定位。我个人在实际操作中最深的一条体会是智能体的能力上限不由 Skill 数量决定而由组织方式决定。SchoAI 这套分层加载和流程编排的思路本质上是把给模型更多选择换成了给模型更好的选择。六十个技能平铺在桌上和一个技能一个坑、按工序上岗后者才是科研场景该有的样子。最后再分享一个我后来养成的习惯每个季度做一次 Skill 清单体检把注册表里九十天没被加载过的技能标记为休眠,再从工作流实际痛点反推要不要新增技能。这个习惯帮我砍掉了将近三分之一的冗余技能智能体的整体表现反而更稳定了。如果你也在被Skill 越装越多、AI 越用越笨困扰建议先从技能注册表和按需加载做起这一步走对后面就顺了。