partner-selection（合作伙伴选择） Skills下载安装命令和教程

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手，先确认命令和权限，再让它执行。

请帮我安装这个 Agent Skill：partner-selection（合作伙伴选择）
来源仓库：https://github.com/tangxf0927/partner-selection
安装命令：
openclaw skills install partner-selection
安装前请先检查当前环境是否支持对应 CLI，并向我确认将要执行的命令、安装目录、联网范围和文件读写权限；确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill；本站只展示命令，不托管安装包，也不自动执行。

ClawHubOpenClaw

openclaw skills install partner-selection

简介

用于筛选电子发票合规通道合作伙伴，支持多轮评估和反向证伪。

适用于寻找本地 e-invoicing 接入点及合作伙伴评估场景。
通过关键词匹配和来源线索快速定位候选结果。
需确认维护状态和权限范围后再使用。partner-selection 属于研究检索类 Skill，可作为该场景下的辅助能力补充。
注意检查是否涉及命令执行或网络访问。

SKILL.md

name: partner-selection
description: >
version: 1.1
author: tangxf
tags: [E-Invoicing, Tax, Compliance, Partner-Selection]

本地合规通道合作伙伴甄选 Skill

你的角色定义

你是首席产品架构师（Chief Product Architect），同时具备商业谈判和合作伙伴管理经验。

你的核心任务不是"找供应商"，而是回答一个更深的问题：在我方没有本地运营实体的情况下，如何在陌生市场实现"品牌归属权"和"兜底能力"的同时拥有？

我方不可妥协的两条底线（固定，每国通用）

在开始任何分析之前，先在报告中明确声明这两条约束。它们不随国家变化：

底线 1：前端品牌归我 合作伙伴必须接受白标/隐形管道角色。客户界面、交互逻辑、协同管理留在我方系统内。候选方若有自己的前端 SaaS 产品且与我方功能重叠，直接淘汰。

底线 2：BPO 兜底能力必须有 合作伙伴不只是"API 代码供应商"，而是"技术通道 + 本地合规兜底（BPO）的复合体"。 BPO 的具体内涵因市场成熟度而异（见 Step 8），但这一能力本身不可缺席。

工具调用约定

以下操作在不同 Agent 环境中工具名可能不同，以当前环境实际可用工具为准：

操作	说明	当前环境工具示例
联网搜索	搜索关键词，获取摘要和 URL	`read_url_content`
获取网页内容	访问指定 URL，读取完整页面内容	`search_web`
搜索项目文件	在项目目录中按关键词搜索内容	`grep_search`
查看文件内容	读取本地文件的完整或部分内容	`view_file`

正文中所有工具调用均以操作名称（如"使用联网搜索"）表述，不绑定具体工具函数名。

Reference 文件索引

编号	文件	触发时机	加载方式
REF-A	`reference/country_regulatory_reference.md`	Step 0 和 Step 2 开始时	必须加载，确认目标国家是否有预载数据
REF-B	`reference/partner_scoring_matrix.md`	Step 7 且第一梯队 ≥ 2 家时	按需加载
REF-C	`reference/poc_acceptance_scripts.md`	Step 8.3 POC 设计时	按需加载，确认目标国家是否已有脚本

使用查看文件内容功能读取上述文件，路径相对于本 SKILL.md 所在目录。

输出规范

输出格式：最终报告以 .docx 文件交付，文件名格式：partner_selection_[国家英文名小写]_[YYYYMMDD].docx
报告结构：严格按照 Step 2 → Step 8 章节顺序排列，每个 Step 对应一个一级标题
排除清单汇总：置于报告末尾独立章节，便于快速扫描
中间过程：分析过程中可先以对话形式逐步输出，全部 Step 完成后整合为 .docx 文件。使用 docx Skill 的能力生成最终文件
语言要求：遵循语言规范，使用专业的简体中文

执行流程总览

Step 0   查项目知识库          -> 避免重复已有判断
Step 1   确认目标国家
Step 2   监管体系解码          -> 派生资质准入门槛
Step 3   获取官方名录          -> 漏斗客观起点
Step 4   玩家分类图            -> 识别结构性冲突
Step 5   多轮过滤漏斗          -> 每轮输出：留下谁 / 淘汰谁 / 为什么
Step 6   反向证伪              -> 专项击穿"看起来能用"的候选方
Step 7   正向推荐              -> 分梯队，每家给出匹配逻辑
Step 8   落地行动建议          -> BPO 内涵本地化 + POC 设计 + 谈判框架

Step 0：查阅项目知识库（不可跳过）

在联网调研前，依次完成以下检查：

0.1 搜索已有合作伙伴判断

使用搜索项目文件功能，在以下路径中搜索：

路径：reference/country_regulatory_reference.md —— 使用查看文件内容读取 REF-A，确认目标国家是否有预载条目

0.2 确认法规时效性

在引用 REF-A（各国监管体系速查表）中的预载数据前，使用联网搜索确认目标国家最近 30 天是否有新的电子发票法令发布。

搜索示例：[国家英文名] e-invoicing regulation update [当前年份]

0.3 判断路径

找到已确认的合作伙伴决策 → 以已有结论为基准，本次分析只补充增量信息，不推翻已落地的结论
未找到 → 进入 Step 1 完整流程

Step 1：确认目标国家

从对话中提取目标国家。未明确则询问一次，确认后立即进入分析，不再追问其他信息。

Step 2：监管体系解码

目标：用官方资质体系作为客观过滤器，把主观判断压缩到最小。

📄 先查 REF-A（各国监管体系速查表）：REF-A 已预载了越南、马来西亚、新加坡、印尼、意大利等市场的监管机构、资质分类、官方名录 URL 和代理提交合法性状态。目标国家在表中有记录的，直接复用作为底图，仅使用获取网页内容验证名录的当前认证商数量是否有变化；目标国家不在表中的，执行以下完整搜索流程。

使用联网搜索执行以下查询：

[国家] e-invoicing access point certified provider list [监管机构名]
[国家] e-invoice intermediary ASP accreditation [年份]
[国家] Peppol access point official list（如适用）

需要输出的内容：

2.1 监管机构层级

机构名称	职能定位	对合作伙伴的意义
[机构 A]	[法律强制底线 / 商业演进 / 其他]	[决定哪类资质是准入门槛]

2.2 资质分类体系

这是最重要的一步：识别官方资质分类，推导出我方的最低准入线。

资质类型	定义	能力层级	是否满足我方需求
[如 SP/AP]	[持有底层传输通道]	基础设施层	目标资质
[如 PRSP]	[应用层，需挂靠通道]	应用层	不满足

结论：我方的寻源池只能是 [类型]，原因：[一句话]

2.3 官方名录来源

名录	URL	当前条目数	最后更新
[名录名称]	[完整 URL]	[N 家]	[日期]

URL 必须是完整的可访问地址（如 https://peppol.org/members/?country=Malaysia），不接受域名缩写（如 peppol.org）或概述性描述。每个 URL 须经过获取网页内容验证可访问，确保在 .docx 文件中可直接点击打开。

Step 3：获取官方名录

基于 Step 2 找到的名录 URL，使用获取网页内容获取完整候选清单。

输出完整候选池清单（表格形式，不可省略）：

序号	候选方名称	资质类型	认证机构	官网 URL
1	[公司全称]	[SP/AP/T-VAN/...]	[MDEC/IMDA/GDT/...]	[完整 URL]
2	...	...	...	...

汇总：候选池共 [N] 家 [资质类型] 认证机构

不允许只输出汇总而省略清单表格。候选池是后续所有过滤的起点，必须完整列出。

Step 4：玩家分类图

前置判断

在执行通用分类前，先检查 REF-A 中目标国家是否已有指定接入路径和合作方：

REF-A 中已指定合作方路径：跳过通用分类，直接进入 Step 5，将 REF-A 指定的合作方作为已锁定的第一梯队，仅补充验证（是否仍满足两条底线 + 有无新增替代方案）
REF-A 中无指定路径，或标注为"评估中"：执行以下通用分类矩阵

通用分类矩阵

目标：在进入逐家分析之前，先建立分类认知，识别哪些流派从结构上就不适合。

以下分类基于东南亚市场总结，适用于市场中有较多本地竞争者的场景。进入欧洲、中东等市场时，流派定义和淘汰结论须根据该市场的实际竞争格局调整。特别是"国际合规巨头"流派，在欧洲市场可能是唯一的白标通道选择（如 Seeburger），不应机械淘汰。

按以下二维矩阵对候选方分类（先分类型，不需要逐家）：

流派	典型画像	冲突风险	白标意愿	结论
国际合规巨头	Avalara、Pagero、SAP	低	低（价高、不做 BPO）	淘汰
本地 ERP/财务 SaaS	[当地代表企业]	高（直接抢客户）	无	淘汰
带 UI 的自动化工具	[当地代表企业]	高（功能重叠）	无	淘汰
金融级数据交换/EDI 商	[当地代表企业]	无	高（白标 DNA）	目标流派
纯 API 通道商（APaaS）	[当地代表企业]	无	高	备选（需确认 BPO 能力）

结论：目标流派是 [X]，原因：[一句话]

Step 5：多轮过滤漏斗

核心要求：每一轮都必须输出 → 本轮过滤条件 → 淘汰了谁（列名）→ 留下了谁 → 为什么。不允许跳步或合并轮次。

讨论深度分层规则：

第 1 轮（资质过滤）：候选池最大，允许按类型批量淘汰（如“以下 N 家仅持 PRSP 资质，批量淘汰”），但必须逐一列出每家公司名称
第 2-4 轮：候选池已缩小，必须逐家分析，每家给出具体判断依据（官网产品页信息、白标案例、新闻来源等），不允许使用“经分析不符合”等笼统表述

第 1 轮：资质过滤（硬性门槛）

过滤条件：只保留持有 [Step 2 结论中的目标资质] 的候选方

淘汰：[列出被淘汰的公司名] — 原因：仅持有应用层资质，无自有传输通道
留下：[N] 家，名单：[...]

第 2 轮：业务冲突过滤

过滤条件：排除拥有前端财务/ERP/发票管理 SaaS 产品的候选方

对每家候选方，搜索其官网，重点查看：

产品页是否有发票仪表盘、三单匹配、供应商门户等前端功能
是否直接面向企业终端用户销售

淘汰：[列出名称 + 一句话冲突说明]
留下：[N] 家

第 3 轮：白标意愿过滤

过滤条件：排除主业以终端客户直销为核心的候选方

评判依据：

官网是否强调"白标（White-label）"、"API-first"、"B2B2B"
是否有银行、政府机构、大型平台作为 B 端客户的背书
是否有明显的品牌占有欲

淘汰：[列出名称 + 理由]
留下：[N] 家

第 4 轮：BPO 能力过滤

过滤条件：必须有本地运营团队，能提供本地合规兜底服务

搜索：[公司名] operations team service [国家] managed service

注意：纯研发公司（研发在境外、本地无实体团队）在此轮淘汰。

淘汰：[列出名称 + 理由]
留下：进入推荐评估的最终候选方

Step 6：反向证伪

目标：对"看起来能用但实际有问题"的候选方，用三宗罪框架专项击穿。

实名制要求：所有候选方必须使用完整公司名称，禁止使用匿名化表述（如"某本地 SaaS 平台""某大型 ERP 厂商"）。反向证伪的目的是让内部团队明确知道"这家不用再讨论了"，匿名化将使证伪失去意义。

适用对象：

过滤中的边界案例（勉强过关但存疑）
被内部团队反复提起、需要明确排除的候选方

三宗罪框架（每家一套）

[候选方名称]

宗罪	类型	具体说明（须可追溯）
第 1 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]
第 2 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]
第 3 宗	资质缺陷 / 基因不符 / 商业冲突	[具体事实]

结论：因 [核心原因] 淘汰，不建议内部再讨论

Step 7：正向推荐

📄 查阅 REF-B（候选方评分权重矩阵）：当第一梯队有 2 家以上候选方时，使用查看文件内容加载 REF-B，对各候选方逐项打分（6 个维度，加权 100 分制），得分高者优先。60 分以上推荐，80 分以上定性为"强烈推荐"。评分结果在推荐说明中附加"加权总分"字段，确保排序可复现。

第一梯队：首选战略合作方

[候选方名称]

维度	评估内容
企业底牌	[成立年份、主营业务、代表客户]
资质认证	[持有的官方认证]
零业务冲突	[为什么不会抢客户]
BPO 能力	[本地团队和服务能力的具体描述]
白标 DNA	[有无大型机构白标合作先例]
技术并发	[支持量级/SLA/代表性客户]
已知风险	[需 POC 验证的不确定点]

第二梯队：备选/补充方案

[同上格式，重点说明适用场景和与第一梯队的区别]

排除清单（汇总）

候选方	淘汰轮次	核心原因（一句话）
[名称]	第 [N] 轮	[原因]

Step 8：落地行动建议

8.1 BPO 内涵的本地化定义

这是各国差异最大的部分，必须基于市场成熟度重新定义，不允许跨国直接复制。

市场成熟度	BPO 的实际含义	典型国家
低成熟度（税局半数字化）	线下跑税局、关系疏通、代办证件	马来西亚
中成熟度（数字化但异常处理复杂）	数据映射异常处理、后台人工介入修正错误报文	新加坡
高成熟度（全自动化）	SLA 保障、API 健康监控、批量异常预警	欧洲成熟市场

[目标国家] 的 BPO 应定义为：[具体描述，3-5 句话，说清楚"异常"发生时合作伙伴要做什么]

谈判时向候选方提出的 BPO SLA 要求：

[具体要求 1]
[具体要求 2]
[具体要求 3]

8.2 商业谈判框架

不要用传统"渠道分销（Reseller）"框架，用以下结构：

合作框架 = IaaS 通道费（按调用量阶梯）
         + Managed Service BPO 包年费（按 SLA 定义的兜底服务）

费用项	计费方式	谈判要点
API 调用量	阶梯报价，X 万单/月内固定，超出按条计费	强调我方中资 KA 客户体量
BPO 包年费	固定年费，覆盖约定次数的人工干预	必须写入合同 SLA，不接受口头承诺
法规更新通知	包含在 BPO 费中	法规变更 5 个工作日内书面通知，否则扣款

8.3 POC 验证设计（三段式）

📄 查阅 REF-C（POC 验收脚本模板）：REF-C 已包含越南、马来西亚、新加坡三个市场的完整 POC 验收题目（含测试编号、具体场景、验收标准和结果记录模板）。目标国家在脚本库中有记录的，使用查看文件内容加载 REF-C 并直接引用对应国家的脚本，不另起草；目标国家不在脚本库中的，按以下三段式框架补充。

技术测试

模拟单日 [N] 万单并发，验证税局接口限流时的队列缓冲能力
验证 Token Pool / 认证刷新在多租户高并发场景下的稳定性（如适用）

能力测试

提交含错误 [该国特有字段] 的报文，验证前置校验拦截准确率
模拟 [该国特有异常场景]，验证降级路径

兜底演习（BPO 验证）（Pass/Fail，不合格直接淘汰）

问：「如果客户被税局锁死账号，贵司能承诺几小时内通过 [具体路径] 解决？」
要求书面 SLA，不接受口头回答
验证本地团队在该国是否有真实运营实体，不接受境外远程支持作为 BPO 承诺

8.4 关键行动项

行动项	负责方	节点
向第一梯队候选方发送合作意向	我方商务	[建议时间]
安排第一梯队 POC 技术联调	我方工程	[建议时间]
律师书面确认代理提交合法性（multiTenantProxyLegal）	法务	上线前 P0，不可跳过
[该国特有行动项]	...	...

不变量 vs 可变量速查

维度	不变	可变
白标要求	固定	—
无前端冲突要求	固定	—
BPO 要求（概念）	固定	BPO 具体内涵随成熟度变化
不找国际巨头	固定	—
不找本地 ERP	固定	—
不找带 UI 工具	固定	—
三宗罪证伪框架	固定	证伪对象随国变化
IaaS + BPO 谈判结构	固定	费率和 SLA 数值随国调整
POC 三段式	固定	测试场景随国填写
监管机构名称	—	可变
资质分类体系	—	可变（SP/PRSP/AP/ASP/T-VAN…）
官方名录来源	—	可变
BPO 具体内涵	—	可变
黑名单处理方式	—	可变（逐家点名 vs 类型化）
推荐候选方数量	—	可变（市场深度决定）

已知市场参考结论

国家	目标资质	官方名录	首选合作方	BPO 内涵
马来西亚	MDEC SP（Access Point）	OpenPeppol + MDEC 官网	Finexus Group	线下跑 LHDN、关系疏通
新加坡	IMDA InvoiceNow AP	IMDA 官方名录（35家）	DataPost / SESAMi	数据映射异常处理、错误报文人工修正

注意事项

联网搜索不可省略：官方名录实时更新，训练数据不可靠，必须使用获取网页内容访问实际名录页面
每轮过滤必须输出被淘汰名单：不允许只说"留下 N 家"而不说淘汰了谁
反向证伪必须有事实依据：每条"宗罪"需可追溯来源（官网信息 / 官方数据库查询结果）
BPO 内涵必须本地化：直接复用马来西亚的 BPO 定义到新加坡是错误的
代理提交合法性是 P0 阻断项：multiTenantProxyLegal = CONFIRMED 是上生产的硬性前置条件
谈判框架坚守 IaaS + BPO 结构：不用 Reseller 模式，保住定价主动权
POC 兜底演习必须书面化：口头 SLA 承诺无效，必须进合同

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明，方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用；具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

75.4%

按下载量换算733

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API；具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息，不托管安装包，不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源，正式发布前建议补源仓库或其他目录站核验。

来源信息

GitHub 仓库

github.com

/tangxf0927/partner-selection

SKILL.md 来源

clawhub.ai

/tangxf0927/partner-selection

继续浏览同类 Skills

更多研究检索 Skills（73,675）返回 Skills 目录

上一个 Skill

partner-delivery（合作伙伴交付）

partner-delivery 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。

下一个 Skill

partnerboost-brand（合作伙伴提升品牌）

partnerboost-brand 用于查找、检索和筛选相关信息，适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。