SOP、Skill、Agent：一份工作最后应该装进哪种载体

一次交付总会留下东西，而这些东西最后变成什么形态，多数时候取决于口味——有时候是客户的口味，那更麻烦。有一个更省事的判法：先问这一步今天是谁在做判断，再问如果判断第一次就错了，你靠什么发现。这两个答案基本会自己把工作分进三种载体。

先分三堆

选载体之前，先把留下的东西分成三堆：每个客户都要用的重复基础件、这一个客户特有的部分、只能由人来决定的部分。

第一堆是可以做成通用 skill 的候选。第二堆留在客户侧的文档里，假装它可以通用，是一个乙方最后维护上百个变体的开始。第三堆最有意思：它看起来像流程问题，实际是边界。硬要把第三堆自动化，等于把检查一起省掉了。

阶梯：从能验证的那一级开始

载体是一道阶梯：书面流程、模板、提示词、skill 或工作流、agent、产品模块。应该从这次交付里能被验证的最低一级起步，而不是从最容易被演示的最高一级起步。

模板当天下午就能由要使用它的人验证完；agent 只能拿一套还不存在的评测集来验证。这个差距就是「从低处起步」的全部理由，也是「先把平台搭起来」的项目第一个月全在做基建、最后一周才碰正事的原因。

谁来判断，决定停在哪一层

分野不在模型行不行，而在这一步是谁判断；输入的问题随之而来：如果判断依赖的上下文送不进任何接口，模型再好，这一步也留在人这一侧——这就是人机分工背后的检验。

判断项	留在 SOP	写成 Skill	做成 Agent
下一步谁判断	人每次都判断	人决定要不要调用	agent 判断，人只看例外
变化频率	每个客户、每个月都在变	稳定，随客户调整	稳定，边界清楚
出错的代价	当场看得见，随手改	使用前有人复核	发布前能拦住，或者代价可承受
调用频次	偶尔	反复出现，形态相同	每周多次
边界落在哪	写在文档里	指令、示例、一道检查	接进接口和流程

读这张表要一列一列读，不要一行一行读。大多数工作会干净地落进某一列；横跨两列的那种，先放着，等下一次交付拿到更多证据再说。

提前升级的代价

把一个还在变的流程做成 agent，有三笔账，而且都在开完票之后才付。

流程继续变，于是每次变化都变成一次变更。客户得到了一个系统，失去了改自己工作的能力——原本一句话就能改的事，现在要等乙方。

判断悄悄搬进了 agent。正常路径上，它的行为和原来没有区别；异常路径上，原来那个人会停一下的检查点，直接没有了。这正是人机分工那条检验预测的失败，而它总在例外出现的时候出现。

维护吃掉下一次交付。建立在一个还没定型的流程上的 agent，会在下一个项目里被重做，钱由客户出，名字挂在乙方身上。

反例很常见，好描述。客户第一天就要一个 agent，而这条流程在项目期间变了两次。它上线了，能用，而且对的是第三周时的流程。用户先在旁边留一张表，再加一个群，然后就不打开了。没有人投诉，因为没有人指望它活下来；第四周过去，它成了一件摆设。如果它当初以 SOP 加 skill 的形态交付，那些变化只会花掉一段话，而不是一个迭代。

高危动作与频次阈值

有一条例外横穿整张表。不可逆、代价高、或者会被客户的客户看见的动作，即使其他条件全满足，也不放到「agent 判断」那一层。在一家把内部交付重组为 agent 协作的软件公司里，全自动开发 agent 只承担了大约一成的简单开发任务，高危动作从不交给它自由发挥——这个比例看着保守，直到你数一遍被挡在外面的都是什么。

频次是阈值，不是感觉。同一个任务第二次出现，留意它；第三次出现且形态相同，再标准化。第二次就产品化，等于用一个例子造模板；到第十次才做，则白白重复了八回。这也顺带给了四周检验第二个用途：一个到了第四周已经没人打开的 skill 或 agent 不算活着，第一周的采用率说明不了什么。四周法则对载体和功能一样成立。

交接时什么能留下来

不管选了哪种载体，它必须能被不是你的人操作。也就是要写清：谁来改它、出现什么事件必须重写、它依赖的工具被换掉时怎么办。写清每一行归属的 SOP，活得比一个主创离职的 skill 长；两者又都活得比一个提示词只存在截图里的 agent 长。

把这些写进交接，和日落条件放在一起，载体这件事就只在高处决定一次，而不是每次客户提出一个新想法时重来一遍。

提笔写「agent」之前，先答两个问题：这个判断今天是谁在做？它第一次做错，你靠什么发现？如果第二个答案是「月底看数」或者「等客户投诉」，这项工作属于 skill，扳机留在人手里。