自发现式工具（Skills、MCP）加载与调用
内容提要
文章提出“自发现式工具加载与调用”设计：Agent启动时仅注入核心工具和技能发现模块，对话中由意图猜测服务判断需求，再实时检索或动态创建Skill，避免预载全部工具导致上下文爆炸，也解决工具不足时Agent能力弱的问题。该设计将工具服务与Agent分离，符合大模型上下文扩大、能力增强的趋势，未来仍可适用。
延伸解读
核心矛盾：上下文占用与工具不足的权衡
文章指出，当前Agent工具加载存在两难：预载全部Skill或MCP会导致上下文爆炸，而只加载少量工具又会让Agent能力不足。这种矛盾相互牵制，无法通过简单调整解决。自发现式设计正是为了打破这一僵局，让Agent在对话中按需获取工具，既节省上下文又保持能力。
实现机制：意图猜测与动态发现
该设计在Agent启动时仅注入核心工具和Skill发现模块。用户输入先经过高速意图猜测服务，判断是否需要工具支持，再路由到工具发现模块或直接交给LLM。若发现模块没有所需工具，还能动态创建Skill。工具服务与Agent分离，作为独立后端服务，对性能要求很高。
趋势契合：大模型进化让设计更可持续
文章认为，随着大模型上下文窗口扩大和KV缓存技术进步，传统的上下文工程可能变得多余。OpenAI已优化Codex系统提示词，Superpower等项目在新模型下效果减弱。将工具部分拆分为独立服务，符合大模型能力增强的趋势，未来即使模型能自行感知意图，这套设计仍可适用。
潜在变体：共享经验与生态化
文章提到，该设计还可有更多变体，例如在多个Agent对话之间共享和更新Skill中的经验，或将工具外挂为在线服务，形成Agent共享经验的生态。这些扩展方向表明，自发现式工具加载不仅解决当前问题，也为未来Agent协作提供了基础。
Q&A
自发现式工具加载与调用要解决的核心问题是什么？
它要解决当前Agent工具使用中的两个不可共存的弊端：如果一开始只注册少量工具以节约上下文，Agent在对话中就会因为工具不足而能力变弱；如果一开始就把能想到的Skill和MCP全部加载，又会造成上下文爆炸。
自发现式工具加载与调用的工作流程是怎样的？
Agent对话创建时只注入核心工具和一个Skill发现与注册模块，不注入全部Skill或工具。用户输入先进入高速的意图猜测服务，判断是否需要工具支持；如果需要，就路由到工具发现模块检索或动态创建Skill，再把Skill作为assistant消息进入loop并执行指令；如果不需要，则直接交给LLM服务。
如果工具发现模块找不到所需能力的工具，会怎么处理？
当意图猜测模块判断当前输入需要一个能完成某任务的工具，而工具发现模块中没有找到相同能力的工具时，可以让该模块动态创建这个Skill。
为什么说这套设计符合大模型的发展趋势？
随着大模型上下文窗口从16k扩大到256k、1M甚至未来100M，加上KV缓存技术，上下文管理会变得鸡肋；同时模型自身逐渐具备用户意图感知能力，届时不再需要独立的意图猜测模块。把工具部分从Agent中拆分为独立服务，正好匹配这种趋势，即使模型非常高级，这套设计仍然可用。
文章对当前流行的上下文工程和Superpower类项目持什么看法？
文章认为，随着模型能力提升和上下文窗口扩大，上下文工程会变成鸡肋，不仅起不到作用，甚至可能导致模型表现不如预期。OpenAI在新GPT版本发布后优化Codex系统提示词、减少内容，以及Superpower等项目在新模型诞生后变得鸡肋，不仅不能提升Agent能力，反而让Agent消耗大量token并做出垃圾决策。
这套自发现式设计未来还有哪些扩展可能？
文章提到它可以有更多变体，例如在多个Agent对话之间共享、更新Skill中的经验；还可以将工具外挂作为在线服务，实现Agent共享经验的生态。
