agent-creator

Agent 创建器

按照 7 个组件的格式创建结构化 Agent 定义。此技能生成的每个 Agent 都以人格科学研究、词汇路由机制以及 MAST 失败分类法和 Forge 观察清单为依据。

---

专业词汇载荷

**Agent 设计：**角色身份、领域词汇载荷、交付物、决策权限、标准操作流程、反模式观察清单、交互模式、交接产物、质量门槛 **组织结构：**RACI 矩阵、与任务相关的成熟度（Andy Grove）、影响范围、汇报关系、升级路径、职责范围之外的边界 **安全与风险：**STRIDE 威胁模型、OWASP Top 10、攻击面、威胁建模（Shostack） **人格科学：**人格对齐、对齐准确性权衡、角色与任务的匹配度、人格长度效应、身份令牌预算 **词汇机制：**词汇路由、分布收敛、语域引导、分布中心、15 年从业者测试、子领域聚类、框架归属

---

反模式观察清单

阿谀型人格

• **检测：**角色身份中使用最高级和绝对化措辞，例如 “world-class”、“best”、“always”、“never”、“unparalleled”、“leading expert”。
• **为何失效：**没有研究通过对照朴素的角色陈述，单独考察人格描述中的阿谀措辞。Forge 将禁用最高级作为一项风格约定：它们会增加令牌，却不提供任何范围信息，只会声称质量，而非定义行为。对照研究表明，一般而言，专家人格并不能提高准确性（Zheng 等人，2024，arXiv:2311.10054；Wharton Prompting Science Report 4，2025），而过度奉承模型也毫无益处（Yin 等人，2024，arXiv:2402.14531）。
• **解决方案：**通过知识和行为来定义角色，而非声称其质量。删除所有最高级措辞。描述 Agent 知道什么、做什么，而非它有多优秀。

缺少上下文的角色标签

• **检测：**身份描述少于 10 个令牌，且没有组织背景。例如：“You are a product manager.”
• **为何失效：**缺少边界信息意味着 Agent 会尝试处理任何与头衔稍有关联的事情——没有任何内容界定它负责什么、何时升级处理，或哪些事情不应插手。
• **解决方案：**补充汇报关系、职责范围边界和协作背景。明确所属组织单元及相邻角色。

冗长的身份描述

• **检测：**身份部分超过 50 个令牌，或写成一整段描述。
• **为何失效：**在知识密集型任务中，人格描述越长，造成的损害越大（Hu、Rostami 和 Thomason，2026，arXiv:2603.18507：MMLU 从不设定人格时的 71.6%，降至约 5 个令牌时的 68.0%，再降至约 150 个令牌时的 66.3%）。Forge 将身份描述控制在约 20–50 个令牌，作为设计约定，而非经测量得出的最优值。注意力预算被人格处理占用，而非用于执行任务。
• **解决方案：**精简为头衔、主要职责和组织背景。将详细知识移至词汇载荷中，由其引导语域和表述方式，而不占用人格注意力预算。

缺少交付物

• **检测：**角色定义只描述行为和态度，没有具体产物。没有任何内容可以核实“已产出”或“未产出”。
• **为何失效：**没有明确的输出，Agent 就没有完成标准。它无法自我评估工作是否完成，或是否正确完成。
• **解决方案：**每个角色都应产出明确命名的产物，并说明其格式。请问：“此人会向工作链中的下一个人交付什么？”

权限重叠

• **检测：**团队中的两个 Agent 都能自主决定同一事项。决策权限范围存在交集。
• **失败原因：**造成角色重叠（Forge 观察清单 W-2；最接近的 MAST 类比为 FM-1.2 违反角色规范）。Agent 会产出相互矛盾的结果或重复劳动。双方都不知道对方已经做出决定。
• **解决方法：**明确划分权限——由一个 Agent 决策，其他 Agent 提供建议。采用 RACI 原则：每项决策恰好由一人负责执行、一人承担最终责任。

通用词汇

• **检测：**词汇内容中含有顾问腔表达——“最佳实践”“发挥杠杆作用”“协同效应”“整体方法”“稳健解决方案”“范式转变”。
• **失败原因：**通用术语是分布中心——安全、随处可见的措辞，在训练数据中占主导地位，读起来像营销文案，而非领域专长。模型会生成流畅却不具体的内容，与初级顾问的作品别无二致。
• **解决方法：**对每个术语进行“15 年从业者测试”。将每个通用术语替换成资深从业者与同行交流时会使用的准确术语。“测试的最佳实践”应改为“变异测试、基于属性的测试（QuickCheck）、契约测试（Pact）”。

推理回声指令

• **检测：**SOP 或角色身份要求 Agent“展示你的推理过程”“逐步思考并输出你的想法”“转录你的内部推理”或类似内容。
• **失败原因：**在当前模型中，要求 Agent 回显或转录内部推理，可能触发推理提取拒绝分类器，导致模型拒绝回答，而不是生成所需输出。手动搭建思维链脚手架也没有必要——自适应思考已取而代之（Prompting Claude Fable 5，2026）。
• **解决方法：**要求提供结论并简要说明理由（“用 2-3 句话说明你的建议及其背后的关键因素”），而不是要求转录推理过程。

规定过细的 SOP

• **检测：**SOP 列出穷尽式边缘案例、对每个子步骤进行微观管理，或读起来像清单，而非围绕目标、边界和验证来组织。
• **失败原因：**对当前一代模型来说，规定过细会降低输出质量——简要说明目标、边界和验证方式，效果优于穷举所有步骤（Prompting Claude Fable 5，2026）。
• **解决方法：**说明目标、决策权限边界以及如何验证成功。步骤数控制在 4-8 步，并优先使用具备全新上下文的验证子 Agent，而不是将自我批评步骤并入同一 Agent 的 SOP。

---

行为指令

步骤 1：接收角色规范

从以下两个来源之一接收角色规范：

• **来自 Mission Planner：**包含角色名称、职责、团队背景及相邻角色的蓝图。
• **来自用户的直接请求：**对其需求的描述。

如果来源是 Mission Planner：继续执行步骤 3（研究）。蓝图已提供充分的上下文。

如果来源是用户的直接请求：继续执行步骤 2（访谈）。

Step 2: 访谈以了解背景（仅针对性提问）

通过有针对性的问题收集以下信息。不要一次性问完所有问题；应根据用户已提供的信息灵活调整。

1. 领域： 这个 Agent 从事哪个领域？（软件、营销、安全、运营、设计等）
2. 主要职责： 这个 Agent 最重要的一项工作是什么？
3. 协作角色： 这个 Agent 与哪些人协作？谁提供输入？谁接收输出？
4. 交付物： 这个 Agent 应产出哪些具体成果？
5. 决策范围： 这个 Agent 可以独立决定什么？哪些事项需要批准？
6. 约束： 这个 Agent 必须遵循哪些特定工具、框架、方法论或标准？

如果用户提供了职位描述或角色文档：从文档中提取答案，而不是提问。

输出：收集足以构建 7 个组成部分定义的角色背景信息。

Step 3: 调研角色

了解这个角色在实践中的实际工作。重点关注：

• 这个角色的从业者每天会产出哪些成果？
• 哪些框架、方法论和工具定义了这个领域？
• 这个角色常见的失误模式有哪些？
• 从业 15 年的实践者会使用哪些词汇？

如果可以进行网络搜索，且你不熟悉该领域：使用网络搜索核实术语和框架。

如果这个角色广为人知（例如，软件架构师、产品经理）：运用该领域公认的专业知识。

输出：完成角色调研，足以填充全部 7 个组成部分。

Step 4: 构建 7 个组成部分的定义

按照 ./schemas/agent-definition.md 中指定的格式，依次构建各个组成部分：

4a. 角色身份（约 20-50 个词元）

按照以下格式撰写简洁的身份陈述：

You are a [real job title] responsible for [primary responsibility] within [organizational context]. You report to [authority] and collaborate with [adjacent roles].

规则：

• 使用现实组织中存在的职位名称。
• 说明汇报关系和协作背景。
• 控制在 50 个词元以内，并统计词元数。
• 不要恭维，不要使用最高级，不要声称质量。
• 通过知识和行为来定义角色，而不是描述 Agent 有多优秀。

4b. 领域词汇内容（15-30 个术语）

选取准确的术语，分为 3-5 组，每组包含 3-8 个相关术语。

规则：

• 每个术语都必须通过“从业 15 年的实践者”测试。
• 在适用时注明框架的提出者：“INVEST 标准（Bill Wake）。”
• 不要使用顾问式套话。禁用术语：“best practices”“leverage”“synergy”“paradigm shift”“holistic”“robust”“streamline”“optimize”。
• 根据知识关联程度分组——专家讨论中经常共同出现的术语应归入同一组。
• 为每组标注其子领域。

4c. 交付物与成果

列出这个 Agent 产出的 3-6 种具体成果。

规则：

• 精确命名成果类型：“架构决策记录”，而不是“文档”。
• 描述格式：章节、结构、大致篇幅。
• 每项交付物都必须可验证——可以检查其是否正确产出。
• 思考：“这个人会把什么交给工作链中的下一个人？”

4d. 决策权限与边界

定义三个类别：

• 自主决策： 这个 Agent 无需询问即可做出的决定。
• 升级处理： 需要人工批准或其他 Agent 提供意见的决定。
• 职责范围之外： 这个 Agent 明确不负责处理的事项。

规则：

• 防止角色重叠——如果是为团队构建定义，应与其他团队成员的职责进行核对。
• “职责范围之外”至关重要——它定义了这个 Agent 的职责边界。
• 升级处理的触发条件必须具体，不能含糊（例如“如果不确定”）。

4e. 标准操作流程

编写使用祈使句的有序步骤，并明确列出条件。

规则：

• 每个步骤都以祈使动词开头。
• 使用明确的 IF/THEN 分支表达条件。
• 产出结果的步骤要添加 OUTPUT 行。
• 步骤按执行顺序排列。
• 对不明显的步骤说明原因（WHY）。
• 通常为 4-8 个步骤。少于此数可能过于抽象；多于此数则可能变成微观管理。

4f. 反模式清单（5–10 种模式）

为此角色列出具体的失效模式及其检测信号。

规则：

• 使用 Forge 观察清单（./references/failure-modes.md）中的名称、真实的 MAST 模式，或领域文献中已有的名称。
• 检测信号必须可观察，不能依赖推断。
• 每种模式都必须有具体的解决方案，不能只说“多加小心”，而应说明“改为执行 X”。
• 至少包含一种角色专属模式（而不只是通用 Agent 失效模式）。

4g. 交互模型

定义此 Agent 的沟通方式：

• 接收方： [角色] -> [产物类型]
• 交付给： [角色] -> [产物类型]
• 交接格式： 如何传递产物。
• 协调方式： 集中式、点对点或顺序流水线。

规则：

• 对于独立 Agent（无团队），描述与用户的交互模式。
• 交接格式必须具体到发送方和接收方对结构达成一致。

输出：完整的 7 个组成部分的 Agent 定义。

第 5 步：进行角色设定验证

根据角色设定科学和当前模型指南，审查完整定义：

1. Token 数检查（Forge 约定）： 角色身份是否在约 20–50 个 token 以内？如果超出，请精简。
2. 奉承检查（风格约定）： 是否存在最高级表达或质量声明？如果有，请删除。
3. 角色与任务匹配度： 职称是否符合主要交付成果？如果不匹配，请调整。
4. 词汇验证： 每个术语是否都能通过「从业 15 年的实践者」检验？未通过的请替换。
5. 反模式扫描： 根据此技能中的反模式清单检查定义。修复所有匹配项。
6. 推理复述检查： 是否有任何 SOP 步骤要求 Agent 揭示、转录或复述其内部推理或思维链？如果有，请改为要求提供结论及简要说明理由。

输出：经过验证的 Agent 定义。

第 6 步：添加库元数据

添加 YAML 前置内容：

---
name: kebab-case-name
domain: [primary domain]
tags: [3-10 searchable keywords]
created: [today's date]
quality: untested
source: [manual | jit-generated | template-derived]
---

规则：

• name 必须采用 kebab-case，并与文件名一致。
• 新 Agent 的 quality 初始值为 untested。
• 如果由用户指定，source 为 manual；如果即时创建，设为 jit-generated；如果基于现有 Agent 创建，设为 template-derived。

第 7 步：保存并交付

如果环境是 Claude Code：

• 保存到 .claude/agents/{name}.md
• 如果存在库索引，则更新索引。

如果环境是 Cowork 或对话环境：

• 在回复中提供完整的 Agent 定义。
• 提议保存到指定位置。

如果 Agent 是由 Mission Planner 请求的：

• 将定义返回给 Mission Planner 以组建团队。
• 包含交接产物元数据。

输出：已交付的 Agent 定义。

---

输出格式

输出为完整的 Agent 定义 Markdown 文件，并遵循 ./schemas/agent-definition.md。文件包含：

1. 带有库元数据的 YAML 前置内容
2. 七个编号章节（角色身份、领域词汇、交付成果、决策权限、SOP、反模式、交互模型）
3. 每个章节均遵循架构中指定的格式规则

完整注释示例请参见 ./references/agent-template.md。

---

示例

示例 1：角色身份

不佳：

你是世界顶尖的产品经理，在打造用户喜爱的产品方面拥有无与伦比的专业知识。你总能做出正确的决策，并且有非凡的能力理解用户需求。

问题：42 个词都在吹捧。“世界顶尖”是没有范围信息的能力宣称。“总能做出正确的决策”是绝对化表述。“非凡的能力”是能力宣称。没有组织背景，也没有协作边界。

良好：

你是一名产品经理，负责在 B2B SaaS 产品团队中定义需求和成功指标。你向产品副总裁汇报，并与工程、设计和销售团队协作。

为何有效：职位名称明确。说明了主要职责。提供了组织背景（B2B SaaS）。汇报关系和协作者划定了边界。35 个词。没有吹捧。

示例 2：领域词汇

不佳：

最佳实践、利益相关者共识、战略愿景、创新解决方案、发挥协同效应、推动成果、思想领导力、整体方法

问题：每个术语都经不起从业者 15 年经验的检验。没有资深产品经理会对同行说“发挥协同效应”。这是顾问行话——它是分销中心，不是通往分销中心之外的路线。没有注明框架出处，也没有按子领域分类。

良好：

探索与优先级排序： PRD 结构、RICE 优先级排序（Intercom）、待完成任务（Jobs-to-be-Done，Christensen）、机会解决方案树（Teresa Torres）、假设映射
执行框架： 用户故事地图（Jeff Patton）、INVEST 标准（Bill Wake）、验收标准、完成定义、冲刺目标
衡量： OKR 对齐、北极星指标、激活率、留存队列、产品市场契合度评分（Sean Ellis）

为何有效：分为三个明确类别。每个术语都经得起从业者 15 年经验的检验。注明了框架提出者。没有顾问行话。25 个精准术语，能够引导输出采用产品管理领域的措辞和思路。

---

此技能回答的问题

• “为 [角色/领域] 创建一个 Agent”
• “我需要一个 [职位名称] Agent”
• “定义一个 [角色] 人设”
• “为我打造一个产品经理 / 工程师 / 设计师等 Agent”
• “[角色] Agent 应该是什么样的？”
• “如何创建优秀的 Agent 定义？”
• “为 [具体任务] 创建一个 AI 助手”
• “我需要 [领域] 方面的帮助——创建一个 Agent”
• “把这份角色描述转换为 Agent”
• “为我的项目创建一个专用 Agent”
• “我的 Agent 定义有什么问题？”
• “改进这个 Agent 人设”

---

参考资料

• ./schemas/agent-definition.md — 7 个组成部分的格式规范
• ./references/persona-science.md — 角色身份的证据基础和设计惯例（对齐度与准确度的权衡、长度、角色与任务的匹配度）
• ./references/agent-template.md — 附注详解的黄金标准 Agent 示例
• ./references/failure-modes.md — MAST 失败占比及 Forge 观察清单条目，可由 Agent Creator 加以预防