时间：2026年3月26日 10:04（北京时间） 主题：内部助手的任务工作流设计原则、AGENTS.md 与 Skill 的职责边界、为什么默认流程属于上层规则而不是专项技能
最近我们围绕一个问题做了比较深入的讨论：
“为什么内部助手现在这套默认工作流程，要写在 AGENTS.md，而不是直接做成某个 skill？”
这个问题看起来像是文档放哪更合适，但本质上其实是在讨论：
- 一个 AI 助手到底应该怎么组织自己的工作系统
- 什么属于“总规则”，什么属于“专项能力”
- 为什么有些东西必须写成全局行为，而不能塞进单个模块里
我把这次讨论整理成一篇更完整的文章，方便后续团队统一理解，也方便作为知识库中的长期规则沉淀。
一、先说结论
内部助手现在这套默认工作流——比如：
- 先判断任务类型
- 如果有明确匹配的 skill，就先读 skill
- 先只读排查，再决定是否动手
- 能直接完成就直接完成
- 复杂任务分层处理，必要时再拆子 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：怎么搜索可用 skilllark-kb-analysis-writer：怎么导出整库并分析service-guardian：怎么做服务守护compaction-survival：长任务时怎么保持状态不丢
它们回答的是：
“当任务已经被识别成某一类后，具体执行方法是什么？”
所以 skill 更适合写“专项执行路径”，而不是负责整个 agent 的总决策逻辑。
三、为什么“默认工作流”不能只靠某个 skill 承担
1）因为它发生在选 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”的递归感
流程会变成：
- 收到任务
- 先调用 intake skill
- intake skill 再判断要不要调用其他 skill
- 其他 skill 再真正干活
这在设计上很别扭。
因为本来应该作为 agent 默认脑回路的东西，被额外包成了一个 skill，反而增加了一层形式主义。
3）轻任务会被过度流程化
并不是所有任务都需要显式走一遍完整 intake。
很多任务其实很轻：
- 读一个文件
- 回一个问题
- 查一个状态
- 给一句判断
这类任务如果每次都显式调用某个“前置 skill”，系统就会显得过于笨重。
而写进 AGENTS.md，这套规则可以自然地作为默认行为存在：
- 复杂任务时完整启用
- 轻任务时自动轻量化处理
这更像“会做事的人”，而不是“执行表单流程的机器”。
4）没命中任何 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 更适合解决的是：
当已经确定这是一类任务后，该怎么具体执行。
一个是上层总规则，一个是下层专项能力。两者不是对立关系，而是分层关系。
真正成熟的 agent 系统，不是把所有东西都塞进 skill，而是要把：
- 全局行为规则
- 专项技能模块
- 用户偏好和团队协作方式
- 长任务生存与恢复机制
放在正确的层级上。
这次讨论的价值就在这里：
我们不是只给内部助手增加了一个新流程，而是在逐步把“内部助手怎么工作”这件事，变成一套更清晰、更可维护、也更像真正助理的系统。
九、建议的后续动作
基于这次讨论，后续可以继续补两类文档：
- 《AGENTS.md 与 Skill 的职责边界图》
- 用图示方式明确：什么该写 AGENTS、什么该写 Skill、什么该写 MEMORY
- 《复杂任务 Planning / Intake Skill 设计方案》
- 不是替代 AGENTS.md，而是作为显式规划层补充
如果这两份补上，整个系统的分层会更清楚，内部助手后续也更容易持续优化。