点击放大 Provider 运行时架构
Provider 把鉴权、Context、typed domain operations、薄 Skill adapters 与目标系统执行收拢到清晰边界之内。
集成从 Provider 开始。
Provider 是 AtlasClaw 的集成边界。每个 Provider 都封装目标系统 metadata、配置与鉴权合同、可复用领域操作、薄 Skills、可选页面 Context，以及让企业 AI 集成保持可理解的参考资料。
运行时架构
先看 Provider 如何承接运行时。
这张架构图展示了 Provider 如何承接配置 schema、鉴权与 Context、可复用领域包、薄 Skills 和目标系统调用。
点击放大 Provider 运行时架构
关闭预览 Provider 把鉴权、Context、typed domain operations、薄 Skill adapters 与目标系统执行收拢到清晰边界之内。
文件结构
Provider 文件夹结构。
providers/<provider-name>/
├── PROVIDER.md
├── provider.schema.json
├── README.md
├── pyproject.toml # 可选可导入包
├── assets/ # 可选静态资源
├── src/<provider_package>/ # 可选可复用领域代码
├── assistant_context/ # 可选页面 Context
└── skills/
├── <skill-a>/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── <skill-b>/ 关键原则
让边界明确、Adapter 保持薄层。
- Provider 负责把 AtlasClaw 的身份上下文变成目标系统可接受的鉴权方式。
- 可复用鉴权、API、typed models 与业务操作归属于可导入 Provider 包。
- Skill 保持人类可读和薄层结构，并绑定到显式 `file.py:callable` entrypoint。
- 可选 `assistant_context` 路由解析当前企业系统页面，不接受宿主发送的业务 DTO。
- Provider Qualified Naming 用于避免跨系统能力冲突。
- Callable 结果可以携带少量与请求 trace 绑定的续跑 metadata，公开证据继续对 Agent 和用户可见。
命名约定
Provider Qualified Skills。
通过 provider 前缀避免不同系统技能的命名冲突。
{
"providers_root": "../atlasclaw-providers/providers",
"webhook": {
"systems": [
{
"allowed_skills": ["jira:jira-issue"]
}
]
}
} 参考实现