原来不是Agent越大越好，拆小之后反而更好用了。
前段时间我做了一个 JIRA问题定位 Agent。
思路很完整：先拉JIRA信息，再去查日志、查数据库、辅助定位代码，希望一条链路把问题定位完。
最开始我以为这样会很高效，结果实际拿去演示和试用后，发现问题不少。
最大的感受就是：太重了。
一是 不够灵活。
JIRA里的提单时间，很多时候并不是真正的故障发生时间。用户可能晚几个小时提单，甚至第二天才补。
如果直接按JIRA时间去查日志，第一步就可能查偏。
二是 精度也不稳定。
尤其到了日志、数据库、代码联动这一步，只要前面某个判断偏了，后面就会越来越偏。
有时候代码定位出来的结果，和真实问题差距还挺大。
后来我就换了个思路：
不做一个大而全的Agent了，改成拆分多个Skill。
现在我把它拆成了几个独立能力：
提取JIRA信息的 Skill
查询ERP/日志的 Skill
查询数据库的 Skill
这样一来，这些Skill既可以单独用，也可以按需要串起来用。
拆完之后，效果反而明显更好了。
现在我可以直接在一个大语言模型的 command 黑窗口里：
看JIRA、查日志、查数据库，整个排查过程基本都能在一个地方完成，不用在多个系统之间来回切换。
这次最大的体会就是：
很多时候，不是功能越多越强。
在企业场景里，做一个“全自动大Agent”未必实用；
反而是把能力拆小、拆清楚，做成可以自由组合的 Skill，更轻、更准，也更方便真正落地。
这也算是我最近一个挺真实的经验：
从“做大做全”，转向“做轻做实用”。
如果你也在做 Agent，可能真的可以考虑一下：
先别急着做超级Agent，先把高频能力拆出来。