工具腐化悖论：为何在开发中安装50+个代理技能会在生产中崩溃

当你开始构建非琐碎的代理工作流时，本能会将工具和技能视为 npm 包：如果代理需要做新的事情，你就安装一个新技能，编写一个包装器，更新提示/模式，并将其暴露给上下文窗口。在构建和维护代理栈一段时间后，这种模式遇到了硬瓶颈。工具膨胀会腐化你的上下文窗口——同时暴露数十个工具模式会降低指令遵循性能。模型开始选择略微错误的工具，误解 JSON 模式，或者当两个技能有重叠边界时感到困惑。维护与安全债务：每个直接安装到代理运行时的静态技能都会成为即时的技术债务：过时的 API 模式在运行中静默失效；未经验证的第三方社区技能会引入严重的提示注入和数据泄露攻击向量；更新技能逻辑需要接触本地代码库并重新部署代理框架。转变：动态发现而非静态安装 与其将大量能力硬编码直接放入代理，实践中扩展性更好的设置是一个单一的路由/元技能加上动态注册表。不是加载 50+ 个工具模式到系统提示中：代理只安装一个主要工具：discover_and_execute_capability。当用户请求到来时，代理将意图传递给注册表。注册表根据动态索引、经过安全审查的能力数据库评估任务，获取所需的精确模式，并在该特定轮次即时执行或注入。要点：你的代理框架（例如 lyzr control plane 或 google azure foundry）不应是安装的依赖项的庞大捆绑包，而应是一个轻量级运行时，按需动态获取工具。它能保持系统提示简洁，减少幻觉工具调用，并将能力更新与你的本地应用逻辑解耦。