当上百个 Skill 塞爆 System Prompt 时，如何进行架构重构与优化？

当面试官抛出这个问题时，先别急着去想怎么删减字数。咱们先往深处想一层：面试官为什么要问这个问题？

他其实是在考察你对大模型工业化落地的理解。

平时写个小 demo，三五个技能往 System Prompt 里一塞，模型跑得挺欢。但真正到了企业级场景，一个 Agent 可能要对接几百个外部 API，要处理财务、法务、行政各种杂事。如果你还是那种把所有干货都塞进一个篮子的单体思路，系统必崩无疑。

Phase 0：痛苦现状——为什么 Prompt 太长模型就会变笨？

这不仅仅是 Token 贵不贵的问题，这里有两个核心的技术陷阱：

第一个是 Lost in the Middle，也就是中间注意力丢失。 大模型的注意力分配是不均匀的，它对开头和结尾的信息记得最牢，中间那一大段最容易断片。如果你塞了 100 个技能，最核心的逻辑偏偏在第 50 个，那模型大概率会视而不见。

第二个陷阱叫 Attention Dilution，注意力稀释。 大模型的总注意力带宽是有限的，指令越多，分配给每个指令的权重就越稀疏。最后的结果就是，它明明知道有这个工具，但就是不按你要求的格式输出。

这种单体 Prompt 架构，就是我们要拆掉的第一座大山。

Layer 1：急速意图路由

既然不能全塞进去，怎么办？

先问一个问题：如果你去一家大公司办事，你是直接冲进 CEO 办公室问厕所在哪吗？显然不是，你会先去前台。

路由层就是咱们的前台。 我们不需要一开始就动用那个最聪明、最昂贵的核心大模型，可以部署一个极轻量的小模型，甚至是本地化部署的、经过微调的分类器。它的活极其简单：把用户那句大白话翻译成一个意图标签——是要查报表，还是要订外卖。

路由层一分钟能处理成千上万个请求，它把那些完全不相关的技能直接过滤掉，只给后面的核心模型留下一条清爽的路径。

Layer 2：技能向量库检索（Skill RAG）

过了路由这一关，就来到了第二层。

大家都做过文档检索 RAG，但技能检索这个概念一定要掌握。

我们把那 100 多个技能的描述、调用参数，甚至是几个成功的调用范例，全部打碎，存进向量数据库。当用户说"帮我分析一下上季度的财报"时，系统会拿着这个需求去向量库里做相似度匹配，精准地把「数据生成」「图表绘制」这两个技能召回来。

注意，这里我们只召回了 Top-K，也就是最相关的三五个技能。这时候，System Prompt 长度瞬间就从一万行减到了几十行。

我们不再要求模型背诵全文，而是给它一张开卷考试的精准缩印本。

Layer 3：动态组装引擎

技能找回来了，怎么喂给模型才最舒服？这一层考的是 Prompt Engineering 的硬实力。

第一件事叫结构化降噪。 千万不要用大段的自然语言去描述技能，要用模型最喜欢的 Markdown 或 JSON Schema。因为这种结构化的表达方式具有极强的归纳偏好，模型一眼就能看出哪里是指令、哪里是参数。

另外还有一个高级技巧：Dynamic Few-Shot，也就是动态示例。 不要把几十个范例都写死在里面，而是根据当前的上下文，只从库里抓取一个跟当前最像的例子塞进去。这样既保证了模型知道怎么模仿，又把上下文空间压榨到了极致。

Layer 4：分身代理架构（多智能体协作）

如果任务真的很复杂，既要查数据、又要写文案、还要自动发邮件，这几个技能还是塞不下怎么办？

这时候就得祭出第四层：多智能体协作。

顶层是一个 Manager Agent，也就是主管。这个主管的 System Prompt 极其纯粹，它不背任何具体技能，只负责两件事：拆解任务和分发任务。

它把复杂的请求拆成几个子任务，然后发给底下的专家 Agent：数据专家只背数据相关的 Prompt，文案专家只拿写作相关的 Prompt。每个专家都住在自己那个精简、纯净的小屋子里工作。

这种解耦思维是目前处理大规模技能集的行业标准答案。

Layer 5：底层性能极致追求

最后，作为架构专家，得展示一下对底层性能的极致追求。这里有两个杀招：

第一个是 Context Caching，上下文缓存。 虽然每个用户的提问在变，但技能库、系统规则这些东西其实是相对稳定的。我们可以把这些静态的、巨长的 Prompt 放在开头，利用缓存技术把它们的 KV Cache 锁死。这样后面的人再提问，大模型就不需要重新计算这部分 Token 了。首次延迟能直接降一个数量级，成本也能省下一大笔。

第二个杀招是 SFT，也就是模型内化。 如果你发现某几个技能是核心中的核心，每天被调用几万次，那就干脆别写在 Prompt 里了，直接拿这些数据做微调，让模型把技能内化到参数里。

总结：面试官真正想听到的答案

如果面试官听完你的方案，你应该怎么给出那个最有力的收尾？

要告诉他：在大模型工程化落地中，核心哲学是——最好的 Prompt 往往不是写出来的，而是根据上下文实时组装出来的。

• 通过 Layer 1 和 Layer 2 解决技能的广度问题：不管你有几千个技能，我都只取一瓢饮
• 通过 Layer 4 的多代理架构解决任务的深度问题：让专业的人办专业的事
• 通过 Layer 5 的缓存和微调解决系统的快慢问题

但脑子里还得绷紧一根弦：不能只看方案的好处。 这种动态架构虽然解决了塞不下的问题，但它的代价是系统复杂度和延迟。

如果技能一共就十几个，核心模型完全能 hold 住，那直接全量塞进去其实才是最稳、最快的，完全没必要搞这么复杂。只有当技能规模真的突破了临界点，模型开始间歇性失忆或者胡言乱语的时候，这种动态组装带来的精度提升才值得去忍受那一点点延迟成本。

要在响应速度、理解精度和实现成本之间找到那个最精准的平衡点。

当你从路由、检索、组装、解耦、内化这五个维度去拆解一个臃肿的 System Prompt 时，你已经不是在调优一段文字了——你是在设计一套具备无限扩展能力的 Agent 工业架构。

这种高度，才是面试官真正想要的答案。