摘要
昨天我优化了一个提示词类技能。表面看，是让它生成更适合不同 agent 的 prompt；但真正的问题是，它必须先知道自己运行在哪个 agent 里。
如果一个技能每次都靠路径、目录名或上下文去猜“我现在是谁”，短期可能能用，长期一定会混乱。我的做法是把身份从猜测变成契约：由适配器明确注入当前运行身份，技能只负责读取和执行。
这篇文章讲的是为什么“明确身份”比“智能猜测”更可靠。
目录
- 为什么技能不能靠猜
- 我采用的身份识别顺序
- 适配器为什么更适合注入身份
- 这样做有什么好处
- 长期收益
- FAQ
为什么技能不能靠猜
一个提示词技能如果同时服务多个 agent，就会遇到一个问题：它到底应该为谁写 prompt？
不同 agent 的工作方式不一样。有的更适合明确文件范围，有的更适合长上下文综合，有的需要更强的停止条件，有的应该避免过度结构化。目标 agent 不同，prompt 的写法就会不同。
如果技能自己猜，猜错一次，结果就会很别扭。比如它以为自己在一个 coding agent 里，于是生成了带文件范围和测试步骤的 prompt；但实际目标是一个写作 agent，这份 prompt 就会显得用力过猛。
所以我觉得，第一步不是把 prompt 写漂亮，而是把运行身份说清楚。
我采用的身份识别顺序
我把身份识别拆成一个明确顺序。
第一，用户显式指定优先。如果用户说“给某个 agent 写”，那就不用再猜。
第二，读取适配器注入的身份。也就是说，这个技能同步到某个环境时，本地适配器已经告诉它：你现在默认面向哪个 agent。
第三，如果没有适配器信息，再根据安装位置做推断。
第四，如果仍然不清楚，就问用户，而不是随便选一个默认值。
这个顺序的好处是：能确定时不打扰用户，不能确定时不假装确定。
适配器为什么更适合注入身份
适配器本来就负责把同一套技能放到不同 agent 的运行环境里。它最知道当前环境是谁，也最适合写入默认身份。
这样技能本身就不用背太多环境判断逻辑。技能只需要读取“当前 agent 是谁”，然后按这个身份生成对应的 prompt。
这有点像软件里的配置注入。业务逻辑不要自己到处猜环境变量，环境信息应该由启动层或适配层明确给出来。
这样做有什么好处
第一个好处是稳定。每次运行时，技能都知道自己默认服务哪个 agent。
第二个好处是可调试。出了问题，可以直接看适配器身份是否写对，而不是在一堆路径推断和上下文线索里找原因。
第三个好处是可扩展。以后增加新的 agent，只要补一个适配器身份，不需要重写技能主体。
长期收益
长期来看，我想要的是一套跨 agent 的技能系统，而不是一堆各自为政的小脚本。
跨 agent 最大的问题不是语法，而是上下文契约。谁在运行，面向谁输出，哪些工具可用，哪些动作允许做，这些都要清楚。
把身份注入做好以后，技能就能更自然地迁移到不同环境。用户不用反复提醒“这是给谁用的”，agent 也不会在第一步就跑偏。
FAQ
为什么不能默认当前就是 Codex？
因为同一个技能可能会被同步到多个 agent。默认某一个环境，会让其他环境天然吃亏。
用户指定目标 agent 时怎么办？
用户显式指定永远优先。适配器身份只是默认值，不应该覆盖用户意图。
这对 prompt 质量有什么影响？
影响很大。目标 agent 明确以后，prompt 才能写出适合它的约束、输出格式和验证方式。