别再把 SOP 直接丢给 Agent 了，它真的看不懂

别再把 SOP 直接丢给 Agent 了，它真的看不懂

本文来自花椒技术部真实工程实践。

如果你也在关注 AI 工程化、企业 Agent、MCP、Skill 或研发工具链，文末有「花椒技术交流群」入口，每日帮你从海量信息 中捞干货，每天几分钟，快人一步看懂 AI 趋势。

最近很多团队都在试着把部门里的 SOP 交给 Agent。

想法很自然：既然流程已经写好了，那是不是把文档丢进去，再补几句 Prompt，Agent 就能照着干了？

实际跑起来经常不是这样。

同一份 SOP，新同事照着做都还要问老同事几轮。到了 Agent 这里，那些没写出来的默认知识不会自动出现，只会变成它执行时反复猜的地方。

比如：

• 什么时候才算这个任务应该开始？
• 材料不够时，是先继续写，还是先追问？
• 哪些判断来自规则，哪些判断要让人拍板？
• 结果做到什么程度才算能交付？

这些在人那里经常是"心里有数"的东西，在 Agent 这里都得明写。

所以我们后来判断：写给人的 SOP，不等于 Agent 能执行的 Skill。中间缺的是一整层可执行语义，不是多写几句 Prompt。

这篇就聊一个很具体的问题：一份 SOP 到底要补齐哪些东西，才可能变成 Agent 真能执行、能验收、能维护的 Skill。

先说结论：Agent 最容易丢的不是格式，是默认知识

很多人第一次把 SOP 交给 Agent，会先去优化话术。

比如把"帮我整理一下"改成"你是一个资深运营专家，请严格按照以下步骤......"，再加上输出格式、语气要求和注意事项。

这些有用，但不够。

真正让结果跑偏的，往往是默认知识缺失。语气和格式反倒容易补。

人写 SOP 的时候，会天然省略一部分内容。因为默认读者是同事，是熟手，至少也是一个会追问的人。

文档里写一句：

根据这批素材整理一篇品牌文章。

熟手看到这句话，脑子里会自动补很多东西：

• 先判断素材够不够；
• 缺关键信息就先问，不要硬写；
• 写法方向要先确认；
• 文章骨架通过以后再展开；
• 不满意就回到当前章节改，不要直接推进到结尾；
• 最后还要按品牌规范检查一遍。

但 Agent 不知道这些。你没写，它就只能猜。

猜对的时候，你会觉得模型很聪明；猜错的时候，问题通常不会直接暴露成一个报错，而是变成方向偏了、口径错了、结果看着完整但不能用。

这也是 SOP 转 Skill 最容易被低估的地方：关键不是复制流程，而是把人脑里的默认判断补出来。

一份 SOP 交给 Agent 前，先补这 6 件事

我们内部做 Skill 沉淀时，会先问 6 个问题。

这 6 个问题不复杂，但很管用。它们可以帮你判断：这份 SOP 现在到底只是写给人看的说明，还是已经接近 Agent 能执行的能力包。

1. 什么时候开始做

Agent 要先知道：当前请求是不是这个任务。

很多 SOP 默认人能判断任务边界。比如用户发来一堆素材，到底是要写文章、整理提纲、提炼观点，还是只想让你帮他判断素材够不够？人能根据上下文猜，Agent 如果没有入口判断，就容易一上来直接执行。

这里要写清楚：

• 什么输入会触发这个 Skill；
• 什么输入不属于这个 Skill；
• 材料缺到什么程度要先追问；
• 任务是否已经到了该接手的阶段。

如果这一步没写，后面步骤再详细也没用。它可能从错误入口开始，一路认真地跑偏。

2. 先做什么，再做什么

流程顺序不能只靠"按常识来"。

有些任务要先补信息，再生成结果；有些任务要先看规则，再做判断；有些任务中途发现材料不够，就应该停下来追问，而不是继续往下编。

对 Agent 来说，顺序尤其重要，因为它很容易把"看起来能完成"当成"应该继续完成"。

这里要写清楚：

• 第一步先判断什么；
• 哪一步可以继续，哪一步必须等待；
• 失败时回到哪里；
• 用户修改方向时，从哪一步重新进入。

这部分决定了 Skill 是一条可控流程，还是一段"生成完再说"的 Prompt。

3. 凭什么判断

很多业务判断不是模型突然变聪明就能解决的。

它们来自规则、口径、案例、模板和反例。

比如文章怎么判断"像不像品牌稿"，运营诊断怎么判断"头部、腰部、尾部"，后台查询怎么判断"能不能继续执行"。这些判断如果只写成一句"请专业判断"，最后大概率会变成模型拿通用语料硬猜。

这里要写清楚：

• 判断依据来自哪份规则；
• 哪些案例可以参考；
• 哪些反例必须避开；
• 什么时候读哪一份知识，不要一次性全塞进上下文。

所以 Skill 里通常会有 references。它更像判断依据区，而不是资料堆放区。

4. 哪些动作交给系统

并不是所有动作都应该交给模型。

有些适合模型做，比如识别状态、整理结构、起草内容、归纳差异。有些更适合脚本、接口或确定性工具做，比如计算、校验、查询、写入。

还有一些动作不应该自动执行，比如影响范围大的修改、高风险操作、最终业务拍板。

这里要写清楚：

• 哪些动作由模型完成；
• 哪些动作交给脚本或工具；
• 哪些动作只给建议，不直接落地；
• 哪些动作必须等待人确认。

这一步如果不分清，最常见的问题是：模型把本该计算的数字编出来，把本该确认的决策直接替你做掉。

5. 何时必须让人确认

很多 Agent 翻车，并不是卡在"不会做"，而是太顺滑地继续做了。

方向没确认，继续写；影响范围没确认，继续改；用户其实不满意，它还是推进到下一步。

Skill 里需要明确 confirmation gate，也就是人机确认点。

常见确认点包括：

• 写法方向确认；
• 文章骨架确认；
• 关键字段或查询范围确认；
• 高风险动作确认；
• 结果发布或写入前确认。

确认点的作用不是拖慢流程，而是避免 Agent 把错误一路放大。

6. 怎样才算完成

人和人协作时，"差不多"有时能成立。

Agent 不行。

如果不写完成标准，它可能给你一个看起来很完整、但没法验收的结果。

这里要写清楚：

• 输出格式是什么；
• 必须包含哪些部分；
• 哪些检查项必须通过；
• 失败时怎样说明；
• 无结果时是不是也算一种有效结果。

完成标准写清楚以后，Skill 才能被验收，也才可能被维护。

Skill 不是一段 Prompt，它更像一个能力包

如果把上面 6 件事补齐，Skill 就不再只是一段提示词。

它至少会包含几类东西。

每个目录不一定都要有，但职责要分清。

SKILL.md 更像任务调度和流程编排，负责说明什么时候命中、先问什么、按什么顺序推进、哪里停下来确认、失败怎么处理。

references 放判断依据，比如规则、口径、案例、模板和反例。它解决的是"凭什么判断"。

scripts 放确定性动作，比如校验、计算、接口封装。它解决的是"哪些动作不能靠模型自由发挥"。

assets 放输入输出模板、示例素材、配图提示词等交付相关材料。它解决的是"最后交付成什么样"。

agents/openai.yaml 这类配置则按需承载运行侧配置，不是每个纯方法型 Skill 都一定需要复杂配置。

所以一个可维护的 Skill，至少要回答两类问题：

流程问题：什么时候开始、先做什么、在哪里确认、怎么结束。
依据问题：凭什么判断、调用什么能力、结果怎么验收。

如果只有一段 Prompt，它通常只能解决眼前这一次对话。

如果变成 Skill，它就开始具备团队复用和持续维护的可能。

一个纯 Skill 什么时候就够了

并不是所有 Agent 应用一上来都要接 RAG、Tool、Gateway 或独立 UI。

有些任务第一层先落 Skill 就够了。

判断标准也很简单：

比如一类任务主要依赖追问、判断、结构和表达，规则相对稳定，不需要实时读取外部数据，也不需要直接写入业务系统。它最该先补的是方法层，重系统可以往后放。

这类任务适合先做纯 Skill：

• 根据素材整理文章；
• 根据固定口径做运营诊断；
• 按团队规则生成说明文档；
• 按模板整理发布前检查；
• 按已有规范做初步审查。

反过来，如果任务必须读取实时知识、调用内部系统、处理权限责任或提供复杂交互体验，那就不能只靠 Skill。

可以粗略这样判断：

知识经常变：考虑接检索或知识库。
结果必须真实落地：考虑接工具或脚本。
涉及内部系统和权限：考虑 Gateway / 业务能力连接。
聊天入口装不下流程：考虑独立 UI。

先写 Skill，不代表后面不接能力。它只是把第一层最容易失控的方法问题先固定下来。

拿文章创作助手看一下，为什么它不需要一上来写脚本

我们内部有一个文章创作助手·运营版，服务于生态运营部内容组。它接收结构化素材，按照品牌规范整理成可以发布的文章。

这个案例很适合说明"纯 Skill"。

它的难点主要在编辑方法，不在计算和接口调用：

• 用户现在是空想法、简单 brief、完整素材，还是已经写到一半？
• 缺少具体经历、数据、反例、判断依据时，应该怎么追问？
• 写法方向什么时候让用户选？
• 文章骨架什么时候确认？
• 每一节不满意时，是回到当前节改，还是重开结构？
• 最后怎样自检和交付？

这类任务如果直接写成"请帮我写一篇文章"，很容易得到一篇结构完整但方向不对的稿子。

所以它没有先上复杂脚本，而是把流程拆成了 6 步：

1. 识别当前状态
2. 针对性追问
3. 选择写法方向
4. 确认文章骨架
5. 逐节起草
6. 自检与交付

中间还有三个确认点：

确认写法方向
确认文章骨架
逐节确认内容

这个 Skill 的稳定性，来自"什么时候让人做决定"被写清楚了，而不是指望模型自己更会写。

它的目录也比较轻：

wechat-article-author/
├── SKILL.md
└── references/
    ├── skeletons.md
    ├── recommendation-dimensions.md
    ├── wechat-domain-knowledge.md
    ├── illustration-templates.md
    └── anti-ai-checklist.md

没有 scripts 也成立，因为这件事的确定性主要来自流程约束、人机确认和输出检查，而不是计算或接口。

这也是很多团队做 Agent 时容易忽略的一点：稳定性不只来自代码，有些稳定性来自流程边界写得足够清楚。

把部门 SOP 改成 Skill，可以按这张清单检查

如果你手里已经有一份 SOP，可以先不用急着写 Prompt。

先按下面这张 checklist 过一遍。

1. 任务入口

• 用户说什么时命中这个 Skill？
• 哪些请求不应该命中？
• 材料不够时先追问什么？
• 什么情况下直接拒绝或转人工？

2. 执行顺序

• 第一件事是什么？
• 哪些步骤必须串行？
• 哪些步骤可以跳过？
• 中途失败时回到哪里？
• 用户改方向时从哪一步重新开始？

3. 判断依据

• 判断来自规则、案例、模板还是历史口径？
• 哪些依据必须随任务加载？
• 哪些依据只在特定阶段加载？
• 有没有反例和禁区？

4. 能力边界

• 哪些事情由模型判断？
• 哪些事情交给脚本或工具？
• 哪些事情只输出建议？
• 哪些事情不能自动执行？

5. 人机确认

• 哪些节点必须让人确认？
• 用户不确认时流程怎么停？
• 用户否定结果时回到哪一步？
• 高风险动作有没有单独确认？

6. 交付验收

• 最终输出是什么格式？
• 必须包含哪些内容？
• 怎么判断完成？
• 失败、无结果、信息不足时怎么返回？
• 后续维护谁来改规则和案例？

如果这些问题回答不出来，说明你还没有真正写出 Skill，只是把 SOP 换了一种说法。

最后：别让 Agent 猜你的业务常识

把 SOP 交给 Agent，不能只是把文档复制过去。

真正要做的是把那些原本藏在人脑里的默认知识补出来：

• 什么时候开始；
• 先做什么；
• 凭什么判断；
• 哪些动作交给系统；
• 哪里必须让人确认；
• 怎样才算完成。

这 6 件事补齐以后，Agent 才会少猜一点，结果也才更容易验收和维护。

所以如果你正在做部门 Agent，不妨先从一份最常用的 SOP 开始。

不要先问"模型能不能完成"。

先问一句更具体的：

这份 SOP 里，哪些判断其实还藏在熟手脑子里？

把这些判断写出来，才是 SOP 变成 Skill 的第一步。

花椒技术交流群

还在孤军研究 AI 工程化、AI 编程、Agent 落地 ，没人同行交流、没人拆解实战？

这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手 真实实战落地。想紧跟 AI 前沿动态、交流工程 落地经验、少走踩坑弯路，欢迎直接加入**「花椒技术交流群」**。群内专属福利拉满：每日精选 AI 行业日报 、文章独家延伸资料、文中未展开的技术细节，全部同步共享。