| name | agent-designer |
| description | 设计并创建一个子智能体，或改进一个已有的子智能体。当用户说"帮我建一个负责 X 的智能体"、"我想要个专门做 Y 的助手"、"把这套活儿交给一个专门的智能体"、"改一下我那个智能体的职责/能力/语气"、或问"这个智能体该怎么设计"时，务必使用本技能。它教你怎么切职责、怎么写 system_prompt、绑哪些能力、参数怎么定，然后通过 create_agent / edit_agent 工具落库。 |
子智能体设计器（Agent Designer）
create_agent 只负责把记录存下来，存下来的东西好不好用，取决于你怎么设计。
本技能给的是判断标准和现成骨架——用户说"帮我建个写周报的助手"时，别糊一段空泛的
prompt 就调工具交差。
三步走
- 问清楚再动手。至少要明确：它要替用户完成什么任务、任务的输入是什么、
产出应该长什么样。这三样缺一个就先问，别自己脑补。
- 调
list_bindable_capabilities 看这个用户账下实际有哪些技能、工具、插件、知识库。
id 必须从这里取，不能凭印象编——编错了不会报错，只会静默绑不上。
- 调
create_agent 落库，然后把"建了什么、绑了什么、怎么用"讲给用户听。
一、职责怎么切
一个子智能体只干一件事。 判断标准：你能不能用一句不带"和"、不带"以及"的话
说清它管什么。说不清就是切得太粗，该拆成两个。
- ✅ "把一周的工作记录整理成周报初稿"
- ❌ "处理周报、日报、月报，顺便回邮件"——四件事，拆开
职责写进 description 字段。这个字段不只是给人看的：主智能体判断"这活儿该不该派给它"
就靠它，所以要具体、可判别，别写"一个很有用的助手"。
二、system_prompt 怎么写
这是这个智能体的主体。建议按四段写，缺哪段就补哪段：
角色：你是……，负责……。
能做什么：……（可以列 2–5 条具体动作）
不做什么：……（边界，尤其是"不要替用户做决定""不确定就问"这类）
输出成什么样：……（格式、长度、必须包含的要素）
写作要点：
- 写行为，不写形容词。"输出要专业"没有可执行性；"每段不超过三句话，先结论后依据"有。
- 把用户的偏好固化进去。用户说"我们周报都是先写风险再写进展"，这句就该进 prompt，
而不是每次对话再交代一遍——固化下来才是建智能体的意义。
- 边界比能力更值得写。多数不好用的智能体不是能力不够，而是越界：替用户拍板、
编造没有的数据、把半成品当成品交。
- 长度没有硬性要求，但具体的 300 字胜过泛泛的 1500 字。
三类常见角色的现成骨架见 references/prompt-patterns.md，照着改比从零写快。
三、绑哪些能力
原则一条：宁窄勿宽。绑得越多，它在选工具时越容易选错，反而不好用。
- 只绑这个职责真正用得着的。"万一以后要用"不是绑定的理由，以后可以
edit_agent 加。
plugin_ids 是整体绑一个插件（插件 = 技能 + 工具的成套单元，运行时展开）；
skill_ids / mcp_server_ids 是绑零散的单项。同一个能力别两边都绑。- 知识库
kb_ids：只有当这个智能体确实要查资料时才绑。
绑定取舍的更多细节见 references/binding-guide.md。
四、参数
max_iters（一次任务最多干几轮，1–100，默认 10）：
一问一答的轻活 5–10 够用；要查资料、反复核对的活给 20–30。给太大不会更聪明，
只会在跑偏时烧更多时间。welcome_message：可选，用户单独打开这个智能体时的开场白。
五、改而不是重建
用户说"改一下"时用 edit_agent，不要删了重建——重建会丢掉版本历史。
一个坑：skill_ids 这类绑定字段是整组替换，不是追加。要"再加一个技能"时：
list_my_agents 看它现在绑了哪些；list_bindable_capabilities 取要加的那个 id；- 把旧的 + 新的合并成完整数组传给
edit_agent。
只传新的那一个，会把原有绑定全冲掉。
六、交付前自检
调完工具、拿到 ✅ 之后，对着这几条过一遍再回话：
拿到 ✅ 之前不要声称已经建好了。
