北京
垂直业务Agent要干活，光有工具不够，还得知道“某个特定场景该怎么做”——需求文档按什么格式写、原型按什么规范画、代码按什么标准出。这些经验诀窍怎么沉淀，是绕不开的一关。
最直接的想法是：把所有规范一股脑塞进系统提示词，Agent每轮都看得到，岂不省事？
先算一笔账。假设每个规范2000个token，三个规范全部常驻上下文，每轮调用就白烧6000个token。注意力被稀释，token成本翻很多倍。
更关键的是，这些规范大部分时间都用不上：只有写需求这一步需要需求规范，只有画原型这一步需要原型规范，只有做架构这一步需要架构规范。全部常驻，大部分情况下它们都是与任务无关的噪音。
正确的姿势是按需加载。而skill，正是“按需加载、渐进式披露”的一种标准化实现，分三层：
- 元数据层：常驻上下文，几十个token，只放skill名字加一句话说明“什么时候该用它”；
- 正文层：即skill.md，触发后才载入，写这个know-how的完整写法；
- 资源层：模板、示例、checklist存在文件里，用到才读。
业务场景下的know-how写在外部文件里，不占上下文，需要时按指针取回，这本身就是Agent长期记忆的一种典型形式。
工具和skill的分工，可以用一个比喻说清。团队新来一位同事，给他两样东西：一是命令权限，能访问代码库、能提PR、能跑流水线，这是工具；二是团队文档，需求文档模板、代码规范、评审清单，这是skill。
只给命令权限不给文档，他能干但不知道怎么干才对；只给文档不给命令权限，他知道该怎么干但什么也干不了。
落到mini-agent的设计上：read_spec工具负责“能读到规范文件”，规范skill负责“规范里写了什么、怎么用”。工具是手，skill是know-how，手负责如何执行，know-how负责如何做对，两者相辅相成。
一个好skill怎么写出来，有三个要点公式：
- description是触发器，而不是摘要。它决定Agent什么时候想起用这个skill，要写给模型看：什么时候用，用来干什么。
- 正文是路由器，而不是知识仓库。正文只放主干，细节用指针指向第三层资源。
- 资源按需加载。模板、示例、checklist都放文件里，用到哪份读哪份。
以sdd-site-agent为例，它需要需求规范、原型规范、架构规范三类know-how，正好用三个skill来实现：
- requirement-spec：写需求文档时触发，资源是模板加缺陷清单；
- prototype-spec：画原型时触发，资源是原型模板加组件库；
- architecture-spec：出技术方案时触发，资源是架构模板加决策清单。
写需求时加载需求规范，设计原型时加载原型规范，出技术方案时加载架构规范，每次只带当前步骤需要的那一份，上下文干净，输出对齐团队标准。这些skill文件就是sdd-site-agent的长期记忆资产，不会随着对话结束而消失，是团队规范的沉淀。
工具有了，规范也有了，sdd-site-agent已经能干活。可任务一大，让它一个人又写需求、又画原型、又出方案、又写代码，它还是会乱——什么时候该把这些角色拆给不同的Agent，就是多Agent编排要回答的问题了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
