前言¶
做 Agent 项目最容易踩的坑，往往不是模型能力不够，而是决策没做在前面：方案评审时没人说清楚「为什么这里必须用 Agent，而不是普通函数调用或固定流程」，工具描述写得含糊，模型在多轮里上下文越积越乱，上线后一次偶发失败没人知道该归因到哪一层。
下面介绍的这个 Skill 不替代具体框架，它的作用是把上面这些问题拆成可逐项核对的清单，让团队在开发、测试、上线各阶段都有明确的检查依据。
这是什么¶
这是一个面向 Agent 应用开发者的技能说明，坐标 @kunlungrowth/kunlun-agent-dev，当前版本 1.3.0，由「昆仑增长」发布维护，来源标记为 enterprise，在 SkillHub 上分类为 ai-agent。
它解决的不是「某个框架怎么用」，而是 Agent 项目的工程规范问题：什么场景该上 Agent、能力边界怎么划、工具怎么定义、上下文怎么管、失败了怎么办、上线后看什么指标。
核心功能¶
按 Skill 介绍，它覆盖六条主线。
1. 判断该不该用 Agent¶
对应「选型判据表」。这一步放在最前面，是因为很多项目把 Agent 当作默认解法，实际任务路径固定、调用步骤可枚举时，用确定性流程成本更低、也更可控。判据表的作用是把「该不该用」变成可以逐条对照的条目，而不是凭感觉拍板。
2. 能力边界划定¶
Agent 的能力边界需要显式写清楚：哪些任务在范围内，哪些必须拒绝或转人工。边界模糊会导致模型在边界外幻觉式应答，也会让测试阶段难以定义通过标准。
3. 工具定义与描述规范¶
对应「工具描述四要素」。工具是 Agent 与外部世界交互的唯一入口，描述质量直接决定模型选对工具的概率。四要素提供的是写工具描述时必须覆盖的四个组成部分，使工具说明足够具体，能被模型稳定理解与调用。
4. 多轮上下文管理¶
对应「上下文压缩策略」。长对话中上下文无限累积既不现实也不经济，需要在合适的位置做压缩或裁剪，保留关键状态而丢弃冗余内容。压缩策略给出了「什么时候压缩、保留什么」的做法。
5. 失败兜底与人工接管¶
对应「五类常见失败归因」。Agent 上线后会出现各种失败，先把失败归成少数几类，才能针对每一类设计兜底：是模型没理解意图，还是工具调用失败，还是上下文丢失，还是输出格式不合规，还是外部依赖异常。归因之后才是重试、降级、还是转人工。
6. 回归测试与上线监控¶
对应「回归用例模板」与「上线观测指标」。Agent 的非确定性使得改动容易引入隐性退化，需要有一套回归用例覆盖典型路径；上线后则要靠观测指标判断系统是否处于健康状态。
使用方式¶
这是一个基于通用 SKILL.md 格式编写的 Skill，通常挂载在支持该格式的编码 Agent 环境中（如 Cursor、Claude Code、Codex CLI 等），由模型在对应任务场景下读取并遵循其中的规范。
官方页面地址为 https://www.skillhub.cn/skills/kunlungrowth/kunlun-agent-dev ，API 地址为 https://api.skillhub.cn/kunlungrowth/kunlun-agent-dev 。已抓取的资料中没有给出具体的安装命令与逐平台配置项，因此这里不列出命令，避免给出未经核实的步骤。如果所在环境对 Skill 的引入方式有特定要求，以官方页面与所在 Agent 平台的说明为准。
适用场景与注意¶
适合正在开发或评审 Agent 应用、需要把流程规范化的团队和个人：方案评审、工具设计、上下文管理、失败处理、回归测试、上线观测这些环节都适用。
需要注意的地方：
- 它提供的是判断框架与模板，不是某家框架的 API 参考，具体框架的接口与参数需要另行查阅对应文档。
- 「五类常见失败归因」是归纳性的分类，实际项目中的失败可能不止这五类，用的时候应结合自己线上的真实故障补充。
- 回归用例模板需要结合业务具体路径填充，模板本身不产生用例。
- 线上观测指标要和团队已有的可观测性体系对接，否则指标收集不起来。
- 官方页面显示该 Skill 不需要 API Key（标签
requires_api_key=false），但模型本身的调用成本仍需另行考虑。
结尾¶
这个 Skill 的价值在于把 Agent 开发的各个环节拆成了可核对的清单与模板，让团队在关键决策上有据可依，而不是靠经验临时判断。如果你正在做 Agent 应用，可以从「该不该用 Agent」这一步开始对照。
官方地址：https://www.skillhub.cn/skills/kunlungrowth/kunlun-agent-dev
