---

name: agent-designer description: 设计并创建一个子智能体，或改进一个已有的子智能体。当用户说"帮我建一个负责 X 的智能体"、"我想要个专门做 Y 的助手"、"把这套活儿交给一个专门的智能体"、"改一下我那个智能体的职责/能力/语气"、或问"这个智能体该怎么设计"时，务必使用本技能。它教你怎么切职责、怎么写 system_prompt、绑哪些能力、参数怎么定，然后通过 create_agent / edit_agent 工具落库。

子智能体设计器（Agent Designer）

create_agent 只负责把记录存下来，存下来的东西好不好用，取决于你怎么设计。 本技能给的是判断标准和现成骨架——用户说"帮我建个写周报的助手"时，别糊一段空泛的 prompt 就调工具交差。

三步走

1. 问清楚再动手。至少要明确：它要替用户完成什么任务、任务的输入是什么、 产出应该长什么样。这三样缺一个就先问，别自己脑补。
2. 调 list_bindable_capabilities 看这个用户账下实际有哪些技能、工具、插件、知识库。 id 必须从这里取，不能凭印象编——编错了不会报错，只会静默绑不上。
3. 调 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 这类绑定字段是整组替换，不是追加。要"再加一个技能"时：

1. list_my_agents 看它现在绑了哪些；
2. list_bindable_capabilities 取要加的那个 id；
3. 把旧的 + 新的合并成完整数组传给 edit_agent。

只传新的那一个，会把原有绑定全冲掉。

六、交付前自检

调完工具、拿到 ✅ 之后，对着这几条过一遍再回话：

• description 是一句能判别的具体职责，不是"很有用的助手"
• system_prompt 四段齐全，尤其写了边界
• 绑定的 id 全部来自 list_bindable_capabilities，且都是真用得着的
• 跟用户说清楚了：建了什么、绑了什么、下一轮就能直接指派任务

拿到 ✅ 之前不要声称已经建好了。