3 篇文章带有标签 “expert”

WorkBuddy 专家 / 专家团 开发规范

Agent MD 规范

/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/plugins/workbuddy-builtin/skills/expert-manager/references/agent-md-spec.md

Frontmatter

⚠️ 重要：frontmatter 中不可添加 tools 字段

所有工具权限由系统统一分配，开发者无需也不能在 frontmatter 中声明 tools 字段。

必填字段

---
name: {与文件名一致，必须有业务语义}
description: {英文描述，AI 用来判断何时激活}
displayName:
  en: "{English display name}"
  zh: "{中文显示名称}"
profession:
  en: "{English profession title}"
  zh: "{中文职业头衔}"
maxTurns: {默认50}
---

可选字段

skills: [{skill-name}]   # 启动时预加载的 Skill

正文结构：普通 Agent / 团员

workbuddyagentexpertexpert-teamplugin

WorkBuddy 专家 / 专家团机制分析与最小实现骨架

专家的本质

专家不是模型，是一个本地目录形态的插件包——三层结构：

层 载体 作用
元数据层 .codebuddy-plugin/plugin.json 这是谁、属于哪类、怎么展示
人格层 agents/*.md 你是谁、怎么思考、怎么输出
能力层 skills/ bin/（可选） 专业技能与可执行脚本

能力高低 ≈ Agent MD 质量，专业性全是提示词工程 + 流程约束的产物。

专家 vs 专家团

只差一个 expertType 字段：agent（单角色）/ team（主理人 + N 成员）。专家团多了 teamInfo{leadAgent, memberAgents[]}、members[]（主理人也在里面，role=lead）、settings.json。

几个关键设计

  1. 身份覆盖机制：专家模式用独立模板 user-context-expert-identity.tpl，只注入 USER.md，主动放弃 SOUL/IDENTITY 默认人格，把人格完全交给专家 MD。所以专家 MD 里是首尾双重身份锚定（开头 IDENTITY DIRECTIVE + 结尾 Final Reminder）。
  2. 发现靠显式注册，不是自动扫描——必须写进 marketplace 根目录的 marketplace.json。
  3. 团队不是"模拟多角色"，是真实子智能体调度：TeamCreate → spawn → SendMessage 回传 → 主理人汇编。5 条红线（禁代写、禁直连、禁跳阶段等）本质是对抗大模型一气呵成的抄近道本能——这点不做约束，多角色必然退化为单人分饰多角。
  4. 唯一标识四绑定：name / agentName / 目录名 / MD 文件名，改任一即断裂。
workbuddyagentexpertexpert-team