腾讯二面：Agent怎么加载海量Skill？我答完“渐进式披露”后，面试官继续追问：检索精度、冷启动延迟、状态管理怎么办？我顿时有点懵…
公众号名称：算法狗
作者名称：算法狗
发布时间：2026-05-24 17:40
这里，我们先分析一下面试官的意图，然后再展开说一下
1. 面试官的考察意图
当面试官提出了关于大模型Agent如何处理海量skill加载的问题的时候，它问的关键之处并不是在问我们某一个框架究竟要怎么去进行调用，而是在于看我们是否明白认知负担这件事情的本质。对于模型来说Prompt 里面多一个字那就是多了一份注意力分散的情况。
假设哈存在着一个企业级的Agent，它挂载了八十个工具，且每一份说明文档往往会有上千字。要是把这些全部都塞进系统提示词里面的话，仅仅Token的消耗就有可能超过十万了，非常的多了。研究有的也表明当工具目录扩展到大约200个工具（大约占用32K上下文）的时候，主流模型的工具选择准确率会从95%一下子降到最低41%,而且哦这还不是最严重的情况。真正的危险是指令方面的干扰：Transformer的注意力机制得在整个上下文中去分配权重，大量无关的内容会直接降低关键指令被看到的概率。更加危险的是，当规则A和规则B在某些场景之下存在潜在矛盾的时候，模型会进入一种你没有打算让它进入的自我调和的模式。这就是全量加载在工业界被淘汰的根本缘由。它不单单是浪费一些我们的资源而且看上去更是在主动制造混乱。
2. 渐进式披露架构解析
面对这一困境的现代方案的核心哲学是”按需加载，极致轻量”，在业界我们将其称为渐进式披露（Progressive Disclosure）。
存在一个常常被人们误解的地方：很多人认为这就是懒加载的另外一种说法。但是这两者是有着本质的不同的，懒加载是在时间方面的延迟，渐进式披露是在架构上的信息进行分级。它的核心就是把知识加载划分成三个清晰的层级：L1只是展示元数据（大概是100个Token/技能），L2才加载完整的指令（上限大约是5000个Token），更加深入的参考资源得按照需求去取用。这和人类工作记忆的运作方式很相符合，你不会在开始工作之前把整个资料库都背下来，而是先大概地看一下目录，确定需要哪本手册，然后再去拿取。
这与我们人类工作记忆的运作方式高度一致——你不会在开始工作前先把整个资料库背下来，而是先大致扫一眼目录，确认需要哪本手册，再去取。
第一层：元数据层（Level 1）
每一个技能的核心之处在于存在着一个元数据头，在这个元数据头里边包含着名称以及描述。当Agent启动的时候仅仅是预先加载这一部分内容，一般情况下也就只有几十个Token。如此一来便能够在不致使上下文出现膨胀的前提条件之下支撑起大型的技能库。模型在这个阶段就好像是拿到了一份精准的工具目录一样，知道有什么东西，而不是知道怎么去使用。珍贵的注意力全部都用来理解用户的意图。
值得去留意的是，这一个层级的质量决定着整个系统的最高界限。索引得具备实际的信息含量，不能够仅仅只是文件名的列表。索引要以结构化的方式去描述每一个资源的覆盖范畴以及适用的时间。一份优良的L1元数据，是Agent高效导航和胡乱瞎猜的分野之处。
第二层：理解层（Level 2）
当用户存在具体请求的时候，系统编排层在截获模型的工具调用意图之后，才会把工具的完整说明、参数格式、调用示例、边界条件动态地注入到上下文中。这和传统的流程逻辑是相反的：并非是先把所有资料给到模型再让它去做选择，而是让模型先进行选择，之后再给出该选择所需要的全部资料。是先确认需求在前，详细的手册在后，模型在执行工具调用的那个时刻所得到的是最为精准的指引，而不是一堆分散注意力的背景噪音。
第三层：执行层（Level 3）
当任务进入深水区——比如代码运行器报错，需要检索数万字的错误文档——第三层才真正出场。那些篇幅庞大的参考资料平时静置于向量数据库或文档存储中，只有在任务实际触发时才会加载，完全不占用模型的上下文窗口。这相当于将”图书馆”的概念从 Prompt 里彻底剥离出去，只在真正需要”翻书”时才打开那扇门。
从工程结果看，这套三层架构的效益相当显著。实测数据显示，相比启动时加载全量 Schema 的方案，渐进式披露可将 Token 开销削减 85% 至 95%。
3.面试核心要点
当知道架构设计的原先意图之后，便得去直面它在实际进行落地时真实遭遇到的那三个工程层面的摩擦之处。主动将这些问题给提拿出来，通常而言比起死记硬背框架方面的名词更能够彰显出候选人的深度。
检索精度：目录写错全盘皆输
渐进式披露的核心假定是模型能够从L1元数据精准地判断该运用哪一个工具。倘若这个假定不成立，那么后续的动态加载便是朝着错误的方向高效地奔跑。语义路由的方案提供了一种有效的前置过滤的机制。此方案是在请求传送到大模型之前，由轻量级的模型来进行工具的分类，整个过程在CPU上以毫秒级的速度完成，不需要额外的GPU资源，并且也不会对主模型的推理路径产生影响。可以将它看作是在大模型进行思考之前，有一个反应迅速的前台先为它进行初步的意图的分流。
我们要是与全量加载方案相比的话，可以发现语义路由的优势在于它将工具选择从”模型思考的一部分”变成了”基础设施的一部分”，前者会随上下文规模劣化，后者则保持稳定。
冷启动延迟：每步都要等用户为何不烦？
渐进式披露存在这样一个问题，每一个层级进行切换的时候都得动态加载一次，用户会觉得响应速度变慢。解决这个矛盾的工程层面的办法就是提示词缓存。针对OpenAI、Anthropic、Google这三大主流提供商进行实际测量研究后发现，提示词缓存能够让API成本降低45%到80%，首Token响应时间（TTFT）得到改善13%到31%。更为具体地来说，要是有一个有着2万Token系统提示词、经历50轮对话的Agent，缓存机制能够把100万次冗余Token计算从每次全部重新计算变成命中缓存直接重复使用，计算复杂度从O(n²)降低到O(n)。在高频使用的场景当中，高频工具的说明文档几乎一直处于常驻缓存的状态，动态加载的延迟就可以忽略不计了。
状态管理：技能卸载后流程如何不断线？
这是一个很容易被人们所忽略并且是比较难以进行处理的部分。一旦某一个技能从上下文当中被卸载掉了，那么模型对于之前操作进度的记忆也就没有，多步的任务就会出现中断的情况。解决的办法并不是去保留完整的对话历史（那样子就会使得上下文又出现膨胀的情况），而是去搭建一个独立的内存模块。独立的内存模块只是去摘要记录当前任务核心状态到了哪一步、调用了什么样的工具、产出了什么样的结果。每一次技能进行切换的时候把这份状态的快照注入到上下文当中，让模型在不明白完整历史的情况之下还能够保持任务的连贯性。
4. 总结
回答这道面试的时候，普遍存在的错误就是将它看作是背诵技术方案的题目。实际上面试官期望听到的是，你能不能从认知负担这个角度去着手，清晰地推导出三层递进逻辑的必要性，之后再把语义路由和缓存优化当作结尾。这样的回答结构在进行展示的时候：你不单单是能够说出架构的那个人，而是懂得为什么要这样进行设计的人。
让我来阐述一下我的观点哈：三层渐进式的披露被我觉得是当下大规模Agent工程的最优的解决办法。不过它可不是没有代价的。架构复杂度的提升就意味着调试的难度会跟着增加。L1元数据的维护也得持续地投入进去。在资源受限或者技能数量比较少（二三十个以内）的场景当中，一个经过精心裁剪的静态提示词再加上语义路由前置过滤，也许比完整的三层架构更加实用、更加容易维护。架构选型的本质，自始至终都是在复杂度和收益之间去寻找当下最为合适的那个平衡点。
内容效果不满意？点此反馈