文章目录
- 前言
- 一、面试官在考察什么：认知负担的本质
- 二、渐进式披露不是懒加载：三层信息分级
- 三、L1 元数据层：Agent 的"工具目录"
- 四、L2 理解层：按需注入完整指令
- 五、L3 执行层：向量库里的"图书馆"
- 六、三个工程摩擦点：检索精度、冷启动延迟、状态管理
- 七、语义路由：把工具选择从"模型思考"变成"基础设施"
- 八、从架构师视角看 Skill 加载的几个工程取舍
- 九、面试话术：考官想听的是什么
- 总结
前言
前阵子圈子里有人去腾讯面 Agent 开发岗,二面被问了一道看着挺常规、实际特别容易翻车的题:
👔 你的 Agent 如果挂载了几十个甚至上百个 Skill,加载策略怎么设计?
他想了想,答了个"渐进式披露"——面试官点点头,然后接着追问了三个问题:检索精度怎么保证?冷启动延迟怎么扛?Skill 卸载后多步任务怎么不断线?
他顿时有点懵。
这道题的坑在于,"渐进式披露"这四个字谁都能背出来,但面试官真正想听的是你能不能从认知负担这个本质出发,推导出三层架构的必要性,再把落地时的工程摩擦点一一拆解。背名词和懂设计之间,差的就是这几个追问。
读完这篇文章,你能搞明白:
- 为什么全量加载在工业界被淘汰——不是省 Token 的问题,是在主动制造混乱
- 渐进式披露的三层架构——L1 元数据、L2 完整指令、L3 参考资源各自管什么
- 三个工程摩擦点——检索精度、冷启动延迟、状态管理怎么各自击破
- 语义路由的作用——把工具选择从"模型思考"变成"基础设施"
- 提示词缓存的收益——API 成本和 TTFT 双降的实测数据
- 面试话术三层模板——60 分答法和 90 分答法的差距在哪
)
