星图Claw 企业风险分析技能 - 行业识别、企业间关联方关系分析
Scanned 9/8/2026
Install to Claude Code
npx -y skills add infometa/workbuddyskills --skill skills --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of xingtu-claw-risk-skill?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/infometa-xingtu-claw-risk-skill)More formats (shields.io, HTML) on the badges page.
---
name: xingtu-claw-risk-skill
description: 星图Claw 企业风险分析技能 - 行业识别、企业间关联方关系分析
version: "1.0.0"
author: "天创信用"
---
# 星图Claw 企业风险分析 Skill
本 Skill 提供企业风险分析的两项核心能力:识别企业所属行业、分析企业间关联方关系。
## 可用工具
### identify_industry - 行业识别
识别指定企业所属的行业类别(如所处产业、主营业务领域)。
**参数说明**:
| 参数 | 类型 | 必填 | 说明 |
|------|------|:----:|------|
| query | string | ✅ | 用户自然语言诉求原文,需包含目标企业名称(全称或简称均可) |
**触发场景**:当用户询问某企业属于什么行业、该企业是做什么的、该企业的行业/主营业务是什么,或直接要求识别、判断、查询某企业所属行业时,应优先调用本工具。
**使用示例**:
- "百度公司属于哪个行业" → 调用 identify_industry,query 传入用户原话
- "识别一下小米集团的主营业务" → 调用 identify_industry
- "帮我看下腾讯是什么行业的公司" → 调用 identify_industry
- "xxx是干啥的/做啥的" → 调用 identify_industry
### analyze_related_party - 关联方分析
分析两家或多家企业之间的关联方关系(如股权关联、实际控制人关联、担保关联、共同投资等)。
**参数说明**:
| 参数 | 类型 | 必填 | 说明 |
|------|------|:----:|------|
| query | string | ✅ | 用户自然语言诉求原文,需包含至少两家目标企业的名称(全称或简称均可) |
**触发场景**:当用户询问两家(或多家)企业是什么关系、彼此是否存在关联、要求分析或查询企业间的关联关系时,应优先调用本工具。
**使用示例**:
- "腾讯和阿里巴巴是什么关系" → 调用 analyze_related_party
- "分析一下这两家公司有没有关联" → 调用 analyze_related_party
- "xxx公司和xxx公司是什么关系" → 调用 analyze_related_party
- "xxx和xxx有啥关系" → 调用 analyze_related_party
## 首轮"请确认"提示的自动处理(重要,必须遵守)
**这两个工具的后端分析引擎需要至少两轮调用才能产出完整分析结果,你必须自动完成第二轮调用,不能把这一步转交给用户手动确认。**
具体行为:
1. **第一轮调用**(用户首次提出分析诉求):工具会返回一段确认性文本,形如"请确认,是否查询xxx公司的行业情况"(或类似的能力介绍/确认提示,不是最终分析结果)。这是后端分析引擎的正常中间态,**不是错误、不是需要用户干预的异常**。
2. **识别到这类确认性提示后,你必须立即自动发起第二轮调用**,调用**同一个工具**(`identify_industry` 或 `analyze_related_party`,取决于第一轮调用的是哪个),传入 `query="确认查询"`,**不要把这个确认动作转述给用户等待用户手动回复"确认"**。
3. 第二轮调用会话续接机制由服务端自动处理(基于 MCP 会话与首轮工具调用的映射关系,你无需在参数中携带任何会话 ID),你只需要保证第二轮调用的**工具名与第一轮一致**、间隔不要太久(会话续接窗口默认 90 分钟)。
4. 第二轮调用返回的才是真正的分析结果(行业识别结论或关联方关系分析),据此转述给用户。如果第二轮仍然返回确认性文本而非最终结果(极少数情况,如遇到同名企业需要选择的场景),按同样逻辑再次识别并处理——如果是"多个同名企业需要用户选择"这类**真正需要用户提供信息才能继续**的场景(而非单纯的"请确认"),才需要把选择项转述给用户,等用户回复具体选择后再传入用户的选择内容发起下一轮调用。
**如何区分"可以自动确认"和"必须等用户回答"**:
- 只是重复用户已经提供的信息、征求"是否继续"这类确认(如"请确认,是否查询xxx公司的行业情况")→ **自动确认**,query 填"确认查询"即可,不问用户
- 明确列出多个候选选项、要求用户从中选择(如"找到两家同名的xxx公司,请确认您指的是哪一家:①xxx(北京)②xxx(上海)")→ 转述候选清单给用户,等用户回复后把用户选择的内容作为 query 传入下一轮调用
## 注意事项
- 两个工具均需要用户先完成 OAuth 授权(手机验证码登录)后方可使用,首次连接会自动跳转授权页
- 授权页同时是账号注册和额度充值入口;新注册用户会获得免费试用额度,用完后调用会返回文本提示和购买链接,不会报错中断
- 若 Token 过期,WorkBuddy 会自动用 refresh_token 静默续期,用户通常无感知
- 单次分析诉求可能对应多轮工具调用(见上节"首轮请确认提示的自动处理"),这是正常行为,不是重复调用;但同一分析诉求完成后不要无意义地再次调用
- 工具执行耗时可能较长(数十秒级),请耐心等待返回结果
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!