一、为什么很多 Agent 项目一上生产就开始失控
过去两年，企业在落地大模型应用时最常见的一条路径是：先把业务能力封装成 Tool，再把 Tool 挂给模型，让模型自己决定什么时候调用、调用哪个、传什么参数。这个模式在 Demo 阶段非常高效，但一旦进入真实生产环境，问题往往会迅速暴露。
我们在一个营销运营平台里就踩过完整的一轮坑。这个平台支持运营人员通过自然语言完成“创建优惠券、筛选人群、生成投放策略、发起审批、下发活动”整套链路。初版系统采用典型 Function Calling 方案：把二十多个业务 API 全部注册为工具，统一挂给 ChatClient。压测时看起来没问题，上线后却出现了三个明显瓶颈：
1. 工具越多，提示词越臃肿，Token 成本线性增长。
2. 工具越多，模型选择越不稳定，跨域误调用开始频繁出现。
3. 工具越多，团队协作越脆弱，新增一个能力就要改全局注册和总提示词。
本质上，这不是“模型不够聪明”，而是架构层把“全局暴露”当成了默认设计。模型在每次请求里都被迫看到一大堆当前并不需要的工具定义、参数说明和业务规则，最终导致上下文污染、决策负担变重、调用准确率下降。
Skill 机制解决的不是单个 Tool 怎么调，而是更上层的一个问题：
如何把大量业务能力组织成可按需发现、按需加载、按需执行的模块化能力系统。
这正是本文要解决的核心。
