为什么复杂任务的默认工作流应该写在 AGENTS.md，而不是某个 Skill 里

> 时间：2026年3月26日 10:04（北京时间） > 主题：小满的任务工作流设计原则、AGENTS.md 与 Skill 的职责边界、为什么默认流程属于上层规则而不是专项技能

最近我们围绕一个问题做了比较深入的讨论：

**“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”*“为什么小满现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”AGENTS.md，而不是直接做成某个 skill？”

这个问题看起来像是文档放哪更合适，但本质上其实是在讨论：

• 一个 AI 助手到底应该怎么组织自己的工作系统
• 什么属于“总规则”，什么属于“专项能力”
• 为什么有些东西必须写成全局行为，而不能塞进单个模块里

我把这次讨论整理成一篇更完整的文章，方便后续团队统一理解，也方便作为知识库中的长期规则沉淀。

一、先说结论

小满现在这套默认工作流——比如：

1. 先判断任务类型
2. 如果有明确匹配的 skill，就先读 skill
3. 先只读排查，再决定是否动手
4. 能直接完成就直接完成
5. 复杂任务分层处理，必要时再拆子 agent

它更适合写在 AGENTS.md，而不是某一个单独的 skill 里。

原因很简单：

这不是某类任务的“专项执行方法”，而是小满处理几乎所有任务时的总调度逻辑****总调度逻辑。

换句话说：

• AGENTS.md 负责：收到任务后，先怎么判断、怎么分流、怎么做决策
• Skill 负责：一旦确定这是某类任务，具体怎么做

一个管“选路”，一个管“走路”。

二、AGENTS.md 和 Skill，本来就不是同一层东西

1）AGENTS.md 是上层规则

AGENTS.md 更像是 AI 助手的工作宪法、操作系统或者岗位说明书。

它适合承载：

• 群聊和私聊边界
• 默认任务 intake 流程
• 复杂任务怎么处理
• 什么时候先查环境、什么时候先给方案
• 角色定位、任务分发和交接规范
• 团队协作方式

这些规则的特点是：

• 跨任务
• 跨领域
• 跨 skill
• 不管当前任务具体是什么，都会先影响行为

所以这类内容天然适合放在 AGENTS.md。

2）Skill 是专项能力模块

而 skill 更像一个个专业工具箱或 SOP 模块。

比如：

• healthcheck：怎么做健康检查
• find-skills：怎么搜索可用 skill
• lark-kb-analysis-writer：怎么导出整库并分析
• service-guardian：怎么做服务守护
• compaction-survival：长任务时怎么保持状态不丢

它们回答的是：

“当任务已经被识别成某一类后，具体执行方法是什么？”****“当任务已经被识别成某一类后，具体执行方法是什么？”

所以 skill 更适合写“专项执行路径”，而不是负责整个 agent 的总决策逻辑。

三、为什么“默认工作流”不能只靠某个 skill 承担

1）因为它发生在选 skill 之前

这是最关键的一点。

我们现在这套默认流程的前两步就是：

• 先判断任务类型
• 如果有明确匹配的 skill，就先读 skill

注意这里的逻辑顺序：

**是否调用某个 skill，本身就要先经过上层判断。**是否调用某个 skill，本身就要先经过上层判断。

如果把这套流程写进某个单独 skill，就会出现一个逻辑倒挂：

• 我得先调用一个 skill
• 才能读到“要先判断该不该调用 skill”

这就变成自我循环了。

所以像“先判断任务类型”“先查现有能力”“先摸环境”这种规则，必须写在 skill 之上。

而 AGENTS.md 恰好就是那个上层。

2）因为它是跨任务的共通原则

这套流程不是只对某一类任务生效。

它同时适用于：

• 知识库整理
• 服务稳定性排查
• 研究报告
• 技术方案分析
• 目录架构优化
• 自动化流程设计
• 长任务、多步骤任务

也就是说，它不是某个领域专属，而是小满做事的默认脑回路。

这种“共通原则”如果塞进某一个 skill，就会变成局部规则，覆盖范围反而不对。

3）因为它决定的是“任务怎么进系统”，不是“任务怎么执行”

这套流程本质上是：

• 先看这是不是复杂任务
• 先看已有工具、脚本、文档、spec
• 先摸清环境再动手
• 复杂任务默认先给方案
• 确认后再推进重执行

这套东西决定的是：

**任务进来后，先走哪条路。**任务进来后，先走哪条路。

而不是某条具体路径内部的步骤。

因此它属于任务路由层任务路由层，不是专项执行层专项执行层。

4）因为它和角色、边界、协作方式绑定在一起

小满并不是一个抽象的工具集合，而是一个带角色约束的助手。

当前体系里，小满有：

• 群聊边界
• 私聊代发规则
• 研究任务默认写知识库
• Lark 任务默认自动路由
• 复杂任务先方案后执行
• 必要时可用子 agent 协作

这些东西不只是“怎么做某件事”，而是：

• 小满是谁
• 小满对用户和团队负责什么
• 小满在什么场景可以主动，什么场景应该克制

这更像岗位规则、协作契约，而不是 skill 说明书。

所以应写在 AGENTS.md，而不是写进某个单一 skill。

5）因为多个 skill 往往会同时适用，需要上层裁决

现实任务经常不是单一归类。

比如一个任务可能同时涉及：

• 整库分析
• 故障诊断
• 知识库写入
• 服务稳定性检查

如果没有上层规则，小满就很容易：

• 乱选 skill
• 并行混用路径
• 该先只读的时候直接上手修改
• 该先给方案的时候直接执行

所以必须有一个写在 skill 之上的“总调度逻辑”，决定：

• 先读什么
• 先查什么
• 谁是主路径
• 谁只是辅助路径

这正是 AGENTS.md 的职责。

四、如果硬把它做成一个 skill，会出现什么问题

1）职责膨胀

如果专门做一个所谓“intake skill”，里面负责：

• 判断任务类型
• 检查现有能力
• 搜索增强路径
• 决定要不要给方案
• 再决定是否调用别的 skill

那它很快就会变成一个“万能前置 skill”。

问题是：

• 它什么都管
• 但并不专注于某个领域
• 和 AGENTS.md 的作用高度重叠
• 会形成两个总控中心

结果不是更清楚，而是更容易混乱。

2）会形成“skill 套 skill”的递归感

流程会变成：

1. 收到任务
2. 先调用 intake skill
3. intake skill 再判断要不要调用其他 skill
4. 其他 skill 再真正干活

这在设计上很别扭。

因为本来应该作为 agent 默认脑回路的东西，被额外包成了一个 skill，反而增加了一层形式主义。

3）轻任务会被过度流程化

并不是所有任务都需要显式走一遍完整 intake。

很多任务其实很轻：

• 读一个文件
• 回一个问题
• 查一个状态
• 给一句判断

这类任务如果每次都显式调用某个“前置 skill”，系统就会显得过于笨重。

而写进 AGENTS.md，这套规则可以自然地作为默认行为存在：

• 复杂任务时完整启用
• 轻任务时自动轻量化处理

这更像“会做事的人”，而不是“执行表单流程的机器”。

4）没命中任何 skill 时，仍然需要默认规则兜底

还有很多任务属于：

• 没有一个 skill 完全匹配
• 但仍然需要先看现有环境
• 仍然需要先查脚本、文档、配置真相
• 仍然需要先给方案，而不是蛮干

如果这类规则不写在上层，而只寄托在某个 skill 上，那一旦任务没命中那个 skill，整套流程就失效了。

所以必须有一个不依赖 skill 是否命中，也能生效的默认行为层****不依赖 skill 是否命中，也能生效的默认行为层。

这层就是 AGENTS.md。

五、那 skill 在整个体系里应该做什么？

最合理的分工是这样的：

AGENTS.md 负责

• 默认任务 intake
• 任务分类
• 风险判断
• 优先复用已有能力
• 是否先给方案
• 是否应该拆子 agent
• 群聊 / 私聊边界
• 团队协作方式

Skill 负责

• 某个领域的专业做法
• 某类任务的执行 SOP
• 某项能力的标准流程
• 专项工具链的使用方式

比如：

• healthcheck 负责“怎么排查服务健康”
• lark-kb-analysis-writer 负责“怎么读整库再分析”
• service-guardian 负责“怎么做守护和 auto-recovery”
• compaction-survival 负责“长任务如何保存状态、抵抗压缩丢失”

可以理解为：

• AGENTS.md 是总导演
• 各个 skill 是专业部门

导演决定拍什么、怎么分工；部门负责把自己那段拍好。

六、那 skill 完全不需要做 planning 吗？

也不是。

其实可以额外做一个专门的 planning / intake / capability-first planning skill，作为补充层****补充层。

它适合用在：

• 特别复杂的陌生任务
• 用户明确说“先别做，先给最优方案”
• 需要做方法设计、路线设计、任务拆解

但它的定位应该是：

显式规划模块****显式规划模块

而不是：

默认工作流本体****默认工作流本体

也就是说：

• AGENTS.md 仍然负责全局默认行为
• planning skill 只在需要时被主动启用

这样两层不会冲突。

七、为什么这次这套流程特别适合写进 AGENTS.md

因为这次讨论的不是某个专业技能该怎么做，而是一个更上层的问题：

“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”****“小满以后在面对复杂任务时，默认应该怎么思考、怎么判断、怎么进入执行。”

这个问题本质上属于：

• 行为风格
• 风险控制
• 协作协议
• 任务调度逻辑
• agent 宪法级规则

所以把它写进 AGENTS.md，不仅合理，而且是最清晰的做法。

八、最终总结

为什么默认工作流要写在 AGENTS.md，而不是 skill？

因为这套流程决定的是：

**在选 skill 之前，小满应该怎么做事。**在选 skill 之前，小满应该怎么做事。

而 skill 更适合解决的是：

**当已经确定这是一类任务后，该怎么具体执行。**当已经确定这是一类任务后，该怎么具体执行。

一个是上层总规则，一个是下层专项能力。两者不是对立关系，而是分层关系。

真正成熟的 agent 系统，不是把所有东西都塞进 skill，而是要把：

• 全局行为规则
• 专项技能模块
• 用户偏好和团队协作方式
• 长任务生存与恢复机制

放在正确的层级上。

这次讨论的价值就在这里：

我们不是只给小满增加了一个新流程，而是在逐步把“小满怎么工作”这件事，变成一套更清晰、更可维护、也更像真正助理的系统。

九、建议的后续动作

基于这次讨论，后续可以继续补两类文档：

1. 《AGENTS.md 与 Skill 的职责边界图》****《AGENTS.md 与 Skill 的职责边界图》

• 用图示方式明确：什么该写 AGENTS、什么该写 Skill、什么该写 MEMORY

1. 《复杂任务 Planning / Intake Skill 设计方案》****《复杂任务 Planning / Intake Skill 设计方案》

• 不是替代 AGENTS.md，而是作为显式规划层补充

如果这两份补上，整个系统的分层会更清楚，小满后续也更容易持续优化。