为什么把故障诊断做成 Skill，而不单独搭建 Agent？

核心回答

如果已有 Agent 能完成工具选择与任务执行，新增的只是可复用的排障步骤、证据要求和报告格式，做成 Skill 更合适：按需加载专业方法，复用现有运行、工具、日志和恢复机制，不必再造一套执行主体。

如果诊断需要独立上下文、单独身份与工具权限、专用调度或长期运行状态，则可以设专门的 Agent 或 SubAgent。Skill组织“怎么做”，Agent负责在当前状态下决策与执行，两者可以组合。 不是“有Skill就永远不需要Agent”，也不是任务复杂就一定要拆多智能体。

故障诊断Skill可以包含什么

说明适用告警、输入信息、检查顺序和停止条件，例如先核对时间与服务版本，再对照指标与日志，最后给出根因假设、支持证据和未排除项。重复的查询与格式化工作可以封装脚本，工具仍由宿主提供。

以接口变慢为例，Skill 可要求区分应用耗时、下游等待和数据库访问，再根据新证据继续；它并不因为文档写了“查询生产日志”就获得相应凭证或访问权。实际可见范围仍由工具服务和运行环境控制。

怎样判断是否需要独立Agent

看隔离是否带来实际收益。只为减少提示词长度，渐进式加载通常已经够用；需要在敏感代码环境中独立取证、把原始材料与对外回复分开，则可能值得建立专门工作区和受限返回契约。长任务也可能需要单独的状态保存与恢复。

多一个 Agent 会增加交接、延迟、上下文丢失和故障定位成本。可以先用单执行主体加 Skill 建立基线，再用同一批用例比较成功率、关键证据遗漏和成本，确认拆分解决了真实问题。

对应教程

参考资料