面试官问我：AI Agent的Skills架构怎么设计？

上周去面一家做AI Agent平台的创业公司，B轮，团队60人，技术栈是Python + FastAPI + Redis + PostgreSQL。我做了三年后端，最近半年在搞LLM应用，自己搭过RAG pipeline，也玩过Claude Code和OpenClaw。

一面是技术负责人，看起来三十出头，T恤上印着"Skill Issue"——我后来才知道这是个梗。 面试官：你用过Claude Code或者OpenClaw吗？对Agent的Skill机制怎么理解？ 我：用过。我的理解是，Skill本质上是一个结构化的知识包，解决的是上下文稀缺性的问题。传统做法是把所有知识塞进System Prompt，但塞太多模型会糊。Skill通过"渐进式披露"解决这个矛盾——第一层只加载元数据（name和description），让模型知道有哪些能力；第二层在任务匹配时才加载SKILL.md正文；第三层是scripts和references，只有主动引用时才进上下文。三层结构，按需加载，模型只为正在做的事付token。

面试官：那如果用户同时触发了三个Skill，上下文会爆炸吗？你怎么处理优先级？ 我：这确实是实际会遇到的问题。我的做法是——第一，SKILL.md正文控制在5000 token以内，三个同时加载最多15000 token，在大多数模型的上下文窗口里还能承受。第二，设置优先级权重，元数据里的description本身就是天然的优先级信号——模型会根据任务相关性自动排序。第三，如果确实超出预算，就做"Skill裁剪"：只保留被引用Skill的元数据层，把指令层压缩成摘要，资源层延迟加载。 面试官（追问1）：你说到Skill裁剪，那如果你裁掉了一个关键Skill的指令层，模型执行出错怎么办？有没有回退机制？

我：好问题。我的方案是加一个"执行验证"环节——模型执行Skill后，先输出一个执行计划，人工确认或者用小模型做快速校验，通过后再真正执行。如果校验不通过，就重新加载完整Skill上下文重跑。代价是多一步确认，但安全性上了一个台阶。实际上我在自己的项目里就是这么做的，测试下来大概5%的执行需要回退，但这些5%恰好是最容易出问题的场景。

（顺手推几个技术大厂的机会，前、后端or测试，感兴趣就试试 ）

面试官（追问2）：最后一个问题，如果让你设计一个面向企业的Skill市场——企业可以购买或订阅第三方Skill——你会怎么考虑安全和质量？ 我：三个层面。第一，沙箱隔离——每个Skill执行时必须在独立的沙箱里，不能直接访问主进程的文件系统和网络。类似浏览器里iframe的隔离模型。第二，权限声明——Skill必须在元数据里显式声明它需要的外部访问权限（域名、端口、文件路径），加载前给用户确认。第三，质量审核——平台做两轮扫描，一轮静态分析代码和配置，一轮动态运行测试用例。类似于App Store的审核流程，但更自动化。我之前在做一个内部工具市场的时候用过类似机制，效果还行，上线三个月没有出现一次安全事故。

面试完我出去等了五分钟，HR过来问我："二面还约吗？" 我说约。

回来复盘，我觉得答得最扎实的是第三个追问。前面两个偏向理论，第三个我拿出了实际经验。面试官问问题的方式也让我觉得这个团队是认真在做Agent基础设施的，不是那种PPT画饼的。