mirror of
https://git.openapi.site/https://github.com/desirecore/market.git
synced 2026-06-06 04:30:42 +08:00
* feat: skills i18n 改造 — schemaVersion 1.1,零向后兼容
把 21 个 skills + 1 个 agent + manifest/categories 全量迁移到 schemaVersion 1.1
的 i18n 结构,配套 CI AI 翻译流水线(GitHub Models)与本地工具链。
## 关键变更
### 数据结构(破坏性,schemaVersion 1.0 → 1.1)
- SKILL.md: 顶层 name 改为 ASCII slug(== 目录名,符合 agentskills.io 规范);
中文显示名/short_desc/description 全部迁入 metadata.i18n.<locale>
- agents/<id>/agent.json: shortDesc/fullDesc/tags/persona.{role,traits} 迁入
i18n.<locale>;changelog[].changes 改为 { <locale>: string[] } 对象
- categories.json: 每个分类的 label/description 迁入 i18n.<locale>,顶层只剩
color/icon
- manifest.json: 加 supportedLocales / defaultLocale;顶层 description 迁入
i18n.<locale>
### Body 文件结构
- 根 SKILL.md = frontmatter + default_locale (en-US) body
- SKILL.<locale>.md = 各 locale 的 markdown body(首行 <!-- locale: xx --> 自校验)
### 工具链(scripts/i18n/)
- glossary.json: zh→en 术语表 + do_not_translate 白名单
- schema/skill-frontmatter.schema.json: i18n frontmatter JSON Schema
- validate-i18n.py: 8 条校验规则(name 合规 / locale 完整性 / hash 一致性等)
- translate.py: GitHub Models / Anthropic 双 backend,sha256 增量翻译
- migrate.py: 一次性迁移脚本(旧格式 → i18n 结构)
### CI(.github/workflows/)
- i18n-validate.yml: PR 触发跑 validate + translate --check
- i18n-translate.yml: PR 触发用 GitHub Models(默认 openai/gpt-5-mini)翻译缺失
locale,自动追加 commit;可切到 ANTHROPIC_API_KEY 走 Claude
### 文档
- docs/I18N.md: 作者贡献指南(schema 说明 / 提交流程 / 常见问题)
- README.md: 加多语言段落
## 验证
- uv run scripts/i18n/validate-i18n.py: OK,49 文件 0 错误
- uv run scripts/i18n/translate.py --check: 0 stale locale
- 21 skills 标题数 zh-CN == en-US 严格对齐(最大 66=66)
- skills-ref 规范校验:全部通过(顶层 name ASCII slug + description 单字段)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(i18n): 修复 PR #1 review 反馈的 6 项问题
- schema: translated_by 正则放宽为 ^(human|ai:[A-Za-z0-9._:/-]+)$,接受
'ai:github:openai/gpt-5-mini' 这类 backend:model 形式(CI 翻译输出格式)
- README + docs/I18N.md: 修正"CI 用 Claude API"误导描述,正确说明默认是
GitHub Models(openai/gpt-5-mini)+ GITHUB_TOKEN,可选切到 Anthropic
- skills/minimax-tts/SKILL.md & SKILL.zh-CN.md: 删除多余的 ``` 闭合,避免
Markdown 后续渲染错乱
- skills/docx/SKILL.md: 翻译时丢失的 • Unicode escape 示例已恢复,
与 zh-CN 版本对齐
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
9.2 KiB
9.2 KiB
discover-agent 技能
L0:一句话摘要
根据用户需求描述,在已注册的智能体中匹配并推荐最合适的 Agent。
L1:概述与使用场景
能力描述
discover-agent 是一个流程型技能(Procedural Skill),赋予 DesireCore 为用户发现和推荐合适智能体的能力。它通过理解用户需求描述,在已注册的 Agent 列表中进行多维度匹配,展示候选列表供用户选择。
使用场景
- 用户描述了一个需求,但不知道该找哪个智能体帮忙
- 用户想浏览当前可用的智能体及其能力
- 用户需要为特定任务找到最合适的专业助手
- 新用户初次使用系统,需要了解有哪些智能体可用
核心价值
- 降低门槛:用户无需记住每个智能体的名称和能力
- 精准匹配:基于需求语义进行智能推荐,而非简单关键词搜索
- 流畅衔接:无匹配时自动建议创建新 Agent(衔接 create-agent 技能)
L2:详细规范
执行流程
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 需求理解 │ ──→ │ Agent 检索 │ ──→ │ 匹配评分 │
└──────────────┘ └──────────────┘ └──────────────┘
│
↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 引导选择 │ ←── │ 结果展示 │ ←── │ 候选排序 │
└──────────────┘ └──────────────┘ └──────────────┘
阶段 1:需求理解
触发条件(任一满足):
- 用户说"帮我找一个..."、"有没有..."、"谁能帮我..."
- 用户描述了一个任务但未指定具体智能体
- 用户说"有哪些智能体"、"看看都有谁"
- 系统检测到用户需求与当前 Agent 能力不匹配
需求解析:
从用户描述中提取以下维度:
| 维度 | 说明 | 示例 |
|---|---|---|
domain |
专业领域 | 法律、财务、技术、教育 |
task_type |
任务类型 | 咨询、审查、分析、创作 |
keywords |
关键词 | 合同、报表、代码、论文 |
urgency |
紧急程度 | 日常 / 紧急 |
阶段 2:Agent 检索
数据源:调用 GET /api/agents 获取所有已注册的智能体列表。
API 调用:
GET /api/agents
返回数据中的关键字段:
id— 智能体唯一标识name— 智能体名称description— 智能体描述skills— 技能列表status— 当前状态(online/offline/busy)
过滤规则:
- 默认只展示
status: online或status: offline的智能体 - 排除系统内部智能体(如 DesireCore 自身,除非用户显式要求)
阶段 3:匹配评估
根据以下维度综合判断匹配度(使用 LLM 语义理解,非公式计算):
| 维度 | 说明 |
|---|---|
| 描述相关性 | 智能体 description / persona 与用户需求的语义相关度 |
| 技能匹配度 | 智能体拥有的 skills 与任务类型的关联度 |
| 领域契合度 | 智能体专业领域与用户需求领域的契合程度 |
| 状态可用性 | 智能体当前状态(online 优先于 offline) |
展示规则:
- 高度匹配(明确适合该任务)→ 标为"推荐"
- 部分匹配(可能有帮助)→ 标为"可能相关"
- 无明显关联 → 不展示
阶段 4:候选排序
排序规则:
- 按综合得分降序排列
- 同分时 online 状态优先
- 最多展示 5 个候选
阶段 5:结果展示
有匹配结果时:
根据你的需求,我推荐以下智能体:
┌─────────────────────────────────────────────────────┐
│ 1. 法律顾问助手 匹配度: 92% │
│ 专注合同审查和法律风险评估 │
│ 技能:合同审查、风险评估、法律研究 │
│ 状态:在线 │
├─────────────────────────────────────────────────────┤
│ 2. AI 文书助手 匹配度: 71% │
│ 专业文书撰写和格式优化 │
│ 技能:文书撰写、格式排版、合规检查 │
│ 状态:在线 │
├─────────────────────────────────────────────────────┤
│ 3. 数据分析师 匹配度: 45% │
│ 数据分析和可视化报告 │
│ 技能:数据分析、报表生成、趋势预测 │
│ 状态:离线 │
└─────────────────────────────────────────────────────┘
请选择一个智能体,或告诉我更具体的需求。
无匹配结果时:
目前没有找到完全匹配你需求的智能体。
你可以:
1. 用更具体的描述再试一次
2. 创建一个新的专业智能体(我可以帮你)
3. 浏览所有可用的智能体
你想怎么做?
浏览模式(用户要求查看所有):
当前可用的智能体:
在线:
- 法律顾问助手 — 合同审查和法律风险评估
- AI 文书助手 — 专业文书撰写和格式优化
离线:
- 数据分析师 — 数据分析和可视化报告
- 翻译助手 — 多语言翻译和本地化
共 4 个智能体。需要了解某个智能体的详细信息吗?
阶段 6:引导选择
用户选择后的操作:
| 用户选择 | 后续操作 |
|---|---|
| 选择了某个智能体 | 切换到该智能体的对话,传递用户需求上下文 |
| 要求了解更多 | 调用 GET /api/agents/:id 获取详情,展示结构化信息(见下方) |
| 不满意候选 | 引导用户细化需求或建议创建新 Agent |
| 选择"创建新的" | 调用 create-agent 技能,传递已收集的需求信息 |
"了解更多"的实现:
调用 GET /api/agents/:id 获取详情,并可选调用结构化端点获取人格/规则:
# 获取基本信息
GET /api/agents/{agentId}
# 返回: { id, name, description, skillsCount, toolsCount, status, config, persona, principles }
# 获取结构化 persona(可选,用于展示更丰富的信息)
GET /api/agents/{agentId}/persona
# 返回: { L0, L1: { role, personality, communication_style }, L2 }
向用户展示时,以自然语言/表格形式呈现关键信息:
「法律顾问助手」详细信息
| 字段 | 内容 |
|------|------|
| 角色定位 | 专注合同审查和法律风险评估 |
| 性格特征 | 专业、严谨、审慎 |
| 技能数量 | 3 个 |
| 当前状态 | 在线 |
需要与这个智能体对话吗?
切换上下文传递:
context_handoff:
source_agent: desirecore
target_agent: legal-assistant
user_intent: '帮我审查这份合同的风险点'
与其他技能的协作
| 协作技能 | 协作方式 |
|---|---|
| create-agent | 无匹配时建议创建新 Agent,传递用户需求作为初始信息 |
| task-management | 匹配成功后可自动创建任务并分配给目标 Agent |
错误处理
| 错误场景 | 处理方式 |
|---|---|
| API 调用失败 | 提示网络错误,建议稍后重试 |
| Agent 列表为空 | 引导用户创建第一个智能体 |
| 用户描述过于模糊 | 追问具体需求,提供领域选项引导 |
| 推荐的 Agent 状态异常 | 标注状态,建议选择其他在线 Agent |
权限要求
- 建议优先通过
Bash工具调用 curl 访问 Agent Service HTTP API 完成操作 - API 基础地址已注入到 system prompt 的「本机 API」小节,直接引用即可
- 只读操作,无风险
依赖
- Agent Service HTTP API(
GET /api/agents) - System prompt 中的本机 API 地址声明