741 lines
23 KiB
Markdown
741 lines
23 KiB
Markdown
# 1
|
||
|
||
**说明：**
|
||
`Prompts/CCPE/强哥的虎贲卫/`下的Prompt是我写作时用的智能体。
|
||
|
||
1. 之前这些智能体的Prompt全部并列在文件夹里，我现在将它们放在了各自的文件夹；
|
||
2. 之前测试了芒格，但是之前芒格在`强哥的虎贲卫/`，现在我移动到了`强哥的虎贲卫/芒格之魂/`下，导致对应的skill和Readme这些都不对了。
|
||
|
||
**任务：**
|
||
我准备将`强哥的虎贲卫/`下的智能体都打造出来。
|
||
但是在这个之前，需要探讨下skills管理的问题。
|
||
我看到芒格之魂在`skills/`下，我就有100多个智能体，将来这些全部并列放进`skills/`中么？
|
||
还是可以做一些分类，比如将我自己的和github上的分开来；我的本身就有不同的分类。
|
||
|
||
# 2
|
||
|
||
这是个好问题。让我先看看你现在的目录结构和芒格之魂的具体情况。明白了。你现在有12个skill，但Prompts里有18个智能体文件夹。让我看看skill-creator的规范，了解如何组织这些skills：现在我明白了skill系统的结构。让我给你几个关于skills管理的方案：
|
||
|
||
---
|
||
|
||
## Skills 组织方案对比
|
||
|
||
### 方案1：扁平结构（现状）
|
||
```
|
||
skills/
|
||
├── agent-browser/
|
||
├── github/
|
||
├── munger-soul/
|
||
├── weather/
|
||
└── ... (100+ 个并列文件夹)
|
||
```
|
||
**优点**：简单，OpenClaw原生支持
|
||
**缺点**：难以管理，没有命名空间，容易冲突
|
||
|
||
---
|
||
|
||
### 方案2：前缀命名空间（推荐过渡方案）
|
||
```
|
||
skills/
|
||
├── agent-browser/ # 官方/第三方
|
||
├── github/
|
||
├── weather/
|
||
├── ws-munger-soul/ # wantsong的个人技能 (ws-前缀)
|
||
├── ws-zhang-liao/
|
||
├── ws-xiao-he/
|
||
├── ws-kepner-tregoe/
|
||
└── ws-ccpe-analyst/
|
||
```
|
||
**优点**：无需改OpenClaw代码，一眼看出归属
|
||
**缺点**：还是在一个大目录里
|
||
|
||
---
|
||
|
||
### 方案3：分层目录 + 符号链接（推荐长期方案）
|
||
```
|
||
skills/
|
||
├── _external/ # 第三方skills (git submodule或手动安装)
|
||
│ ├── agent-browser/
|
||
│ ├── github/
|
||
│ └── weather/
|
||
├── _personal/ # 你的个人skills
|
||
│ ├── 强哥的虎贲卫/ # 按你的分类组织
|
||
│ │ ├── munger-soul -> ../../../users/wantsong/Prompts/CCPE/强哥的虎贲卫/芒格之魂/
|
||
│ │ ├── zhang-liao -> ...
|
||
│ │ └── xiao-he -> ...
|
||
│ ├── 强哥的龙骧营/
|
||
│ └── 强哥的思想审判庭/
|
||
└── _store/ # 软链接指向实际位置
|
||
├── munger-soul -> ../_personal/强哥的虎贲卫/munger-soul/
|
||
├── zhang-liao -> ...
|
||
└── ... (OpenClaw实际扫描的入口)
|
||
```
|
||
|
||
**核心思想**：
|
||
1. **源文件保留在 `Prompts/CCPE/` 下** — 那是你的创作空间
|
||
2. **Skills 目录只放软链接** — 指向源文件
|
||
3. **OpenClaw 只扫描 `skills/` 下的软链接** — 对它来说一切如常
|
||
|
||
---
|
||
|
||
### 方案4：配置文件映射（需要OpenClaw支持）
|
||
在 `openclaw.yaml` 中添加：
|
||
```yaml
|
||
skills:
|
||
paths:
|
||
- ./skills
|
||
- ./users/wantsong/Prompts/CCPE/*/ # 通配符扫描
|
||
```
|
||
**优点**：最干净，源文件和skill位置统一
|
||
**缺点**：需要OpenClaw代码支持
|
||
|
||
---
|
||
|
||
## 我的建议
|
||
|
||
**现阶段用方案3的简化版**：
|
||
|
||
```bash
|
||
# 你的源文件位置（保持不变）
|
||
users/wantsong/Prompts/CCPE/强哥的虎贲卫/芒格之魂/
|
||
|
||
# 创建skill时，在 skills/ 下创建软链接
|
||
skills/munger-soul -> ../users/wantsong/Prompts/CCPE/强哥的虎贲卫/芒格之魂/
|
||
```
|
||
|
||
这样：
|
||
- ✅ Prompts目录保持你的分类逻辑
|
||
- ✅ Skills目录保持OpenClaw兼容
|
||
- ✅ 编辑源文件，skill自动更新
|
||
- ✅ 100个智能体也不会乱
|
||
|
||
---
|
||
|
||
**下一步行动**？
|
||
|
||
1. 我可以帮你把现有的 `芒格之魂` 重新链接到正确位置
|
||
2. 批量为你创建其他17个智能体的skill结构
|
||
3. 或者先讨论清楚分类命名规范再动手
|
||
|
||
你想怎么推进？
|
||
|
||
# 3
|
||
|
||
我倾向于`方案3：分层目录 + 符号链接`，但是我还有问题。需要先答复我的问题，我充分了解后，再决定后续。
|
||
|
||
`skills/munger-soul/SKILL.md`其实已经包含了我的`users/wantsong/Prompts/CCPE/强哥的虎贲卫/芒格之魂/芒格之魂1.1.md`的内容，那么：
|
||
1. 我还有必要将这个`munger-soul`链接到我的原始Prompt `芒格之魂1.1.md`么？
|
||
2. `芒格之魂1.1.md`的内容不多，只有4000多字，openclaw的机制是什么？
|
||
* 先阅读的`munger-soul/SKILL.md`么，然后再去阅读`芒格之魂1.1.md`么？
|
||
* `Prompts/`下，我有些智能体的提示词比较长，里面放着多个附录（模型、规则），比如`知行合一元认知分析师1.1.md`，你不用打开阅读看文件的长度即可，这个大约有2.8万字。这个应该是我指定用`知行合一元认知分析师`时，OpenClaw才去加载，不然上下文容易超出。
|
||
3. 像`知行合一元认知分析师`这样的，里面有大量公式，有逻辑运算，我现在手工跑，都是在Gemini，Claud这样的模型上跑的，国内的Qwen，Kimi效果不理想，我需要为这些特殊的指定LLM。
|
||
|
||
好问题，我来逐一解答。
|
||
|
||
---
|
||
|
||
## 问题1：还有必要链接到原始Prompt吗？
|
||
|
||
**取决于你的维护方式**：
|
||
|
||
| 场景 | 建议 |
|
||
|------|------|
|
||
| **SKILL.md 是唯一的真相源** → 你直接在 `skills/munger-soul/SKILL.md` 编辑 | 不需要链接，Prompts目录只留备份 |
|
||
| **Prompts 是唯一的真相源** → 你在 `Prompts/` 编辑，定期同步到 skill | 用软链接，或写同步脚本 |
|
||
| **双向维护** → 两边都改（容易出错） | 不推荐 |
|
||
|
||
看你的情况，`SKILL.md` 已经包含了完整 Prompt，而且格式规范（有 frontmatter、有结构），**建议以 SKILL.md 为准**，`Prompts/` 下的文件可以视为：
|
||
- 历史备份
|
||
- 或开发中的草稿
|
||
|
||
---
|
||
|
||
## 问题2：OpenClaw 的加载机制
|
||
|
||
**渐进式披露（Progressive Disclosure）**：
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 阶段1: 元数据 (始终加载) │
|
||
│ ───────────────────── │
|
||
│ 读取所有 skills/*/SKILL.md 的前 100 词 (YAML frontmatter) │
|
||
│ 提取 name + description，用于判断哪个 skill 触发 │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ 阶段2: SKILL.md 全文 (触发后加载) │
|
||
│ ───────────────────── │
|
||
│ 当用户请求匹配某个 skill 的 description 时 │
|
||
│ 才加载该 skill 的 SKILL.md 全文 │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ 阶段3: References (按需加载) │
|
||
│ ───────────────────── │
|
||
│ 如果 SKILL.md 里有指向 references/ 文件的链接 │
|
||
│ 且 Codex 判断需要，才加载那些文件 │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**关键结论**：
|
||
- ✅ 4000字的 SKILL.md → 只在触发时加载，平时不占上下文
|
||
- ✅ 28000字的智能体 → **必须拆分**，把核心放 SKILL.md，附录放 `references/`
|
||
- ❌ 不要把 2.8 万字全塞进 SKILL.md，会撑爆上下文
|
||
|
||
**拆分示例**：
|
||
```
|
||
知行合一元认知分析师/
|
||
├── SKILL.md # ~5000字：核心身份、使命、执行流程
|
||
└── references/
|
||
├── 思维模型库.md # 按需加载
|
||
├── 逻辑运算规则.md # 按需加载
|
||
└── 案例分析集.md # 按需加载
|
||
```
|
||
|
||
---
|
||
|
||
## 问题3：为特定 Skill 指定 LLM
|
||
|
||
**OpenClaw 目前不支持 per-skill 模型配置**，但有几个变通方案：
|
||
|
||
### 方案A：会话级指定（最灵活）
|
||
```
|
||
/reset
|
||
/model gemini-2.0-pro
|
||
# 然后调用 skill
|
||
```
|
||
|
||
### 方案B：Skill 内部提示（推荐）
|
||
在 SKILL.md 开头加：
|
||
```markdown
|
||
---
|
||
name: 知行合一元认知分析师
|
||
description: |
|
||
【模型要求】此 skill 包含复杂逻辑运算，建议在
|
||
Gemini 2.0 Pro / Claude 3.5 Sonnet / GPT-4o 上运行。
|
||
在 Qwen/Kimi 上可能效果不佳。
|
||
|
||
使用场景：深度元认知分析、思维过程显影...
|
||
---
|
||
```
|
||
|
||
这样用户每次触发时都能看到提示。
|
||
|
||
### 方案C：包装 Skill（如果需要强制）
|
||
创建一个代理 skill：
|
||
```markdown
|
||
# SKILL.md
|
||
---
|
||
name: run-on-gemini
|
||
description: 将请求转发到 Gemini 运行的 知行合一元认知分析师
|
||
---
|
||
|
||
1. 检查当前模型，如果不是 Gemini 系列，提示用户切换
|
||
2. 加载 ../知行合一元认知分析师/SKILL.md 并执行
|
||
```
|
||
|
||
---
|
||
|
||
## 总结建议
|
||
|
||
| 问题 | 建议 |
|
||
|------|------|
|
||
| 1. 链接问题 | **以 skills/ 为准**，Prompts/ 作为备份/草稿区 |
|
||
| 2. 大文件拆分 | 28000字的智能体必须拆成 SKILL.md + references/ |
|
||
| 3. 模型指定 | 在 SKILL.md 开头用注释说明推荐模型，靠用户自觉切换 |
|
||
|
||
---
|
||
|
||
**下一步等你决定**：
|
||
- 是否需要我帮你把 `知行合一元认知分析师` 拆分成标准 skill 结构？
|
||
- 还是你有其他关于组织方式的疑问？
|
||
|
||
# 4
|
||
|
||
## 问题1：还有必要链接到原始Prompt吗？
|
||
|
||
这个我已经明白了，我们以Skill为准即可。**SKILL.md 是唯一的真相源**，这样就不需要链接了。
|
||
|
||
在OpenClaw之前，我已经搭建了100多个智能体，这些现在都是运行的比较稳固的。Prompts是我自己的文件夹，你不能在里面进行维护。
|
||
我将芒格放进来后，你生成了一份`强哥的虎贲卫/README.md`
|
||
那这样的话，我们是否就不需要在Prompts下面建立Readme了？你前面生成的README是多余的吧？
|
||
|
||
## 问题2：OpenClaw 的加载机制
|
||
|
||
这个我也明白了。索引实际上在Skill.md上。
|
||
|
||
**28000字的智能体 → **必须拆分****
|
||
这个我不同意。这个不能拆分，没有这样的上下文的LLM不适合这个任务而已。
|
||
我目前在手工使用我的部分智能体时，往往都是20万+的Tokens，除了提示词还有资料、数据，没有这些支撑，效果很差。我已经实践过的。
|
||
|
||
## 问题3：为特定 Skill 指定 LLM
|
||
|
||
靠用户自觉切换，这个在对话时能切换么？
|
||
还是需要到配置上去？
|
||
|
||
请你仔细看看下面的**多 LLM 路由** ✅ 原生支持是否可行？
|
||
|
||
OpenClaw 的 `models` 系统：
|
||
- **模型别名**：可为不同任务绑定不同模型
|
||
- **Fallback 链**：主模型失败自动降级
|
||
- **Agent 级绑定**：每个 Agent 可配置专属模型
|
||
|
||
**可以直接实现**：
|
||
```yaml
|
||
agents:
|
||
prose-writer:
|
||
model: openai/gpt-5.2
|
||
critical-reviewer:
|
||
model: google/gemini-pro
|
||
outline-builder:
|
||
model: anthropic/claude-sonnet
|
||
```
|
||
|
||
## 问题1：README 是否多余？
|
||
|
||
是的，**Prompts 下的 README 是多余的**。
|
||
|
||
既然：
|
||
- SKILL.md 是唯一的真相源
|
||
- Prompts 是你的私人创作空间，我不维护
|
||
|
||
那 `强哥的虎贲卫/README.md` 可以删掉。Skill 的自文档化靠 SKILL.md 本身就够了。
|
||
|
||
---
|
||
|
||
## 问题2：大 Prompt 不拆分
|
||
|
||
明白了。你的使用场景是：
|
||
- 20万+ tokens 是常态
|
||
- 长上下文是任务必需，不是可选优化
|
||
- 模型选错了就是做不了，不是效果差一点的区别
|
||
|
||
那我的建议修正为：
|
||
|
||
**对于长上下文强依赖的智能体**：
|
||
- 不拆分，保持完整 Prompt 在 SKILL.md
|
||
- **但要在 description 里明确标注**："此 skill 需要 128K+ 上下文，建议在 Gemini 1.5 Pro / Claude 3 Opus 上运行"
|
||
- 用户触发前，先检查自己当前模型是否够长
|
||
|
||
---
|
||
|
||
## 问题3：多 LLM 路由
|
||
|
||
让我查一下 OpenClaw 当前的配置能力：**确认了！OpenClaw 原生支持 per-agent 模型绑定** ✅
|
||
|
||
```yaml
|
||
agents:
|
||
list:
|
||
- id: prose-writer
|
||
model: openai/gpt-5.2
|
||
- id: critical-reviewer
|
||
model: google/gemini-pro
|
||
- id: outline-builder
|
||
model: anthropic/claude-sonet
|
||
```
|
||
|
||
**但是**，这里有个关键区别：
|
||
|
||
| 概念 | 说明 |
|
||
|------|------|
|
||
| **Agent** | OpenClaw 的运行时实体，有独立会话、记忆、配置 |
|
||
| **Skill** | 被 Agent 调用的能力包，本身不运行，只是被读取 |
|
||
|
||
你提到的配置是 **Agent 级** 的，不是 **Skill 级** 的。
|
||
|
||
---
|
||
|
||
### 两种用法对比
|
||
|
||
**用法A：Skill 被主 Agent 调用（当前模式）**
|
||
```
|
||
用户 → 主 Agent (Claw) → 读取 munger-soul/SKILL.md → 执行
|
||
↑
|
||
模型由主 Agent 决定
|
||
```
|
||
|
||
**用法B：专用 Agent 绑定 Skill（你要的模式）**
|
||
```
|
||
用户 → 知行合一 Agent (绑定 Gemini) → 加载自己的长 Prompt → 执行
|
||
```
|
||
|
||
---
|
||
|
||
### 实现你要的效果
|
||
|
||
**方案：为长上下文智能体创建专用 Agent**
|
||
|
||
```yaml
|
||
agents:
|
||
list:
|
||
- id: main
|
||
name: Claw
|
||
default: true
|
||
model: moonshot/kimi-k2.5
|
||
|
||
- id: zhi-xing-he-yi
|
||
name: 知行合一元认知分析师
|
||
model: google/gemini-2.0-pro # 或 gemini-1.5-pro
|
||
skills: [] # 不依赖 skills，直接用自己的 Prompt
|
||
agentDir: ./agents/zhi-xing-he-yi # 放完整 Prompt
|
||
```
|
||
|
||
然后使用：
|
||
```
|
||
/switch zhi-xing-he-yi
|
||
```
|
||
|
||
---
|
||
|
||
### 对话中切换模型？
|
||
|
||
**可以，用 `/model` 命令**：
|
||
```
|
||
/model gemini-2.0-pro
|
||
```
|
||
|
||
但这是**当前会话**切换，不是 per-skill 的。
|
||
|
||
---
|
||
|
||
## 最终建议
|
||
|
||
| 场景 | 方案 |
|
||
|------|------|
|
||
| 短上下文 skills（芒格、魏征等） | 标准 skills/ 目录，主 Agent 调用 |
|
||
| 长上下文智能体（知行合一等） | 创建专用 Agent，绑定 Gemini/Claude，用自己的 agentDir |
|
||
|
||
这样：
|
||
- ✅ Skills 系统保持轻量
|
||
- ✅ 长上下文智能体有专属模型
|
||
- ✅ 用户用 `/switch` 选择 Agent，不用记模型名
|
||
|
||
---
|
||
|
||
**下一步**：
|
||
1. 删掉 Prompts 下的 README
|
||
2. 是否需要我为长上下文智能体设计 Agent 配置结构？
|
||
3. 还是你想先把手头这 18 个智能体分类，决定哪些走 Skill、哪些走专用 Agent？
|
||
|
||
# 5
|
||
|
||
依然是问题的讨论。
|
||
关于Agent。
|
||
我这18个智能体目前都是基于Gemini打造的，手工用的都是Gemini 3.0 pro或者3.1 pro。
|
||
|
||
如果是Agent，那么没法像调用Skill那样，在一个会话里，同时让不同的智能体做，然后汇总，比如`张辽做什么`、`蒙田做什么`、`最后再汇总`这样的么，即使我用了支持长会话的LLM。
|
||
|
||
这是个关键洞察。
|
||
|
||
---
|
||
|
||
## Agent vs Skill 的核心区别
|
||
|
||
| 特性 | Skill | Agent |
|
||
|------|-------|-------|
|
||
| **运行方式** | 被调用，在主会话上下文执行 | 独立会话，隔离运行 |
|
||
| **切换成本** | 零，直接读取 SKILL.md | 高，/switch 会切换整个上下文 |
|
||
| **组合能力** | ✅ 可以在一个会话里连续调用多个 | ❌ 一次只能一个 Agent 活跃 |
|
||
| **记忆隔离** | 共享主 Agent 记忆 | 各自独立记忆 |
|
||
|
||
**你的需求**：`张辽做什么` → `蒙田做什么` → `汇总`
|
||
|
||
这确实是 **Skill 模式** 的优势。
|
||
|
||
---
|
||
|
||
## 但有个矛盾
|
||
|
||
| 需求 | 方案 | 问题 |
|
||
|------|------|------|
|
||
| 长上下文（20万+ tokens） | 专用 Agent + Gemini | 无法组合调用 |
|
||
| 组合调用（张辽→蒙田→汇总） | Skill 模式 | 主 Agent 模型可能不够强 |
|
||
|
||
---
|
||
|
||
## 可能的解决方案
|
||
|
||
### 方案A：分层架构（推荐）
|
||
|
||
```
|
||
顶层：协调者（Orchestrator）
|
||
↓
|
||
中间层：Skills（张辽、蒙田、魏征...）
|
||
↓
|
||
底层：LLM 路由
|
||
```
|
||
|
||
**具体做法**：
|
||
|
||
1. **所有智能体都做成 Skill**，保持组合能力
|
||
2. **在 SKILL.md 里标注模型要求**：
|
||
```markdown
|
||
---
|
||
name: 知行合一元认知分析师
|
||
description: |
|
||
【模型要求】此 skill 需要 Gemini 2.0 Pro / Claude 3.5 Sonnet 级别模型
|
||
若在 Kimi/Qwen 上运行，效果可能严重下降
|
||
---
|
||
```
|
||
3. **用户手动切换模型后调用**：
|
||
```
|
||
/model gemini-2.0-pro
|
||
用知行合一分析一下这个问题
|
||
```
|
||
|
||
### 方案B：Sub-agent 模式
|
||
|
||
OpenClaw 支持 `sessions_spawn` 创建子会话，可以指定模型：
|
||
|
||
```yaml
|
||
agents:
|
||
list:
|
||
- id: main
|
||
name: Claw
|
||
default: true
|
||
model: moonshot/kimi-k2.5
|
||
subagents:
|
||
enabled: true
|
||
allowedAgents: ['gemini-worker', 'claude-worker']
|
||
|
||
- id: gemini-worker
|
||
name: Gemini Worker
|
||
model: google/gemini-2.0-pro
|
||
runtime: subagent
|
||
```
|
||
|
||
然后主 Agent 可以：
|
||
```
|
||
spawn subagent(gemini-worker, task="张辽分析...")
|
||
spawn subagent(gemini-worker, task="蒙田分析...")
|
||
等待结果 → 汇总
|
||
```
|
||
|
||
**但这需要 OpenClaw 代码支持 subagent 模型绑定**，目前不确定是否完全支持。
|
||
|
||
### 方案C：外部 ACP 调用
|
||
|
||
用 `runtime: acp` 把智能体作为外部服务：
|
||
```yaml
|
||
agents:
|
||
- id: zhang-liao-acp
|
||
runtime: acp
|
||
acp:
|
||
endpoint: http://localhost:8080/zhang-liao # 你自己部署的 Gemini 服务
|
||
```
|
||
|
||
然后主 Agent 通过工具调用它。
|
||
|
||
---
|
||
|
||
## 我的建议
|
||
|
||
**现阶段用方案A（分层 + 手动切模型）**：
|
||
|
||
| 场景 | 操作 |
|
||
|------|------|
|
||
| 单智能体深度分析 | `/model gemini-2.0-pro` → 调用 skill |
|
||
| 多智能体组合 | `/model gemini-2.0-pro` → 连续调用多个 skills → 自己汇总 |
|
||
|
||
**未来等 OpenClaw subagent 模型绑定成熟后**，可以升级成方案B，实现自动路由。
|
||
|
||
---
|
||
|
||
## 关键问题
|
||
|
||
你现在的实际使用场景更多是哪种？
|
||
|
||
1. **A**：单个智能体深度分析（如知行合一单独工作）
|
||
2. **B**：多个智能体协作（张辽+蒙田+魏征组合）
|
||
3. **C**：两者都有，比例差不多
|
||
|
||
这决定了我们是：
|
||
- 优先保证 Skill 组合能力（选方案A）
|
||
- 还是优先保证长上下文+强模型（选方案B/C）
|
||
|
||
# 6
|
||
|
||
我现在的工作场景实质是多智能体协同，只是人工来做传递工作。
|
||
仅写作上，有大约近四十个智能体，从观点讨论，到提纲撰写、修订，再到文章的生成与审校。
|
||
`强哥的虎贲卫/`下就是观点、提纲到正文的部分。
|
||
|
||
我有自己的Dify平台，可以搭建供调用的单智能体服务。这个可以作为“外部 ACP 调用”的服务吧？
|
||
|
||
我原本计划是：
|
||
* 我用Qwen或者Kimi做一般的计划任务，下发，文件，检索这些通常工作；
|
||
* 在调用具体“专家级”智能体时，使用Gemini、Claude这样的，获取专家的结论
|
||
* 再用Kimi这样的来做最后的完善
|
||
|
||
那么，借用Dify搭建外部ACP，我可以怎么做，比如把张辽、蒙田、包括知行合一全部封装成外部调用服务。
|
||
|
||
明白了，你的场景是典型的**多智能体工作流编排**。
|
||
|
||
---
|
||
|
||
## Dify → ACP 方案完全可行
|
||
|
||
**架构图**：
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ OpenClaw (主控) │
|
||
│ 模型: Qwen / Kimi │
|
||
│ (Claw Agent) │
|
||
└─────────────────────────────────────────────────────────┘
|
||
│
|
||
┌───────────────┼───────────────┐
|
||
▼ ▼ ▼
|
||
┌────────────┐ ┌────────────┐ ┌────────────┐
|
||
│ Dify API │ │ Dify API │ │ Dify API │
|
||
│ 张辽服务 │ │ 蒙田服务 │ │ 知行合一 │
|
||
│ (Gemini) │ │ (Gemini) │ │ (Gemini) │
|
||
└────────────┘ └────────────┘ └────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 具体实施步骤
|
||
|
||
### 1. Dify 侧配置
|
||
|
||
每个智能体在 Dify 上：
|
||
- **应用类型**：Chatflow / Workflow
|
||
- **模型**：Gemini 2.0 Pro / Claude 3.5 Sonnet
|
||
- **发布**：开启 API 访问，获取 `API Key` 和 `API Endpoint`
|
||
|
||
**示例：张辽服务**
|
||
```
|
||
Dify App: 张辽-观点提炼
|
||
API Endpoint: https://dify.wantsong.cn/v1/chat-messages
|
||
API Key: app-xxxxxxxxxxxxxxxx
|
||
```
|
||
|
||
### 2. OpenClaw 侧配置
|
||
|
||
**方案A：HTTP 工具调用（推荐，最简单）**
|
||
|
||
在 `TOOLS.md` 或 Skill 里配置：
|
||
|
||
```markdown
|
||
# 张辽服务调用
|
||
POST https://dify.wantsong.cn/v1/chat-messages
|
||
Authorization: Bearer {{DIFY_ZHANGLIAO_KEY}}
|
||
|
||
{
|
||
"inputs": {},
|
||
"query": "{{user_input}}",
|
||
"response_mode": "blocking",
|
||
"conversation_id": "",
|
||
"user": "openclaw"
|
||
}
|
||
```
|
||
|
||
**方案B：封装成 Skills**
|
||
|
||
为每个 Dify 智能体创建一个轻量 skill：
|
||
|
||
```markdown
|
||
# skills/zhang-liao-dify/SKILL.md
|
||
---
|
||
name: zhang-liao-dify
|
||
description: |
|
||
调用外部 Dify 服务"张辽-观点提炼"。
|
||
用于：快速提炼核心观点、识别逻辑漏洞、挑战思维盲区。
|
||
使用时机：需要犀利批判性分析时。
|
||
---
|
||
|
||
## 调用方式
|
||
|
||
```bash
|
||
curl -X POST https://dify.wantsong.cn/v1/chat-messages \
|
||
-H "Authorization: Bearer ${DIFY_ZHANGLIAO_KEY}" \
|
||
-H "Content-Type: application/json" \
|
||
-d '{
|
||
"inputs": {},
|
||
"query": "{{input}}",
|
||
"response_mode": "blocking",
|
||
"user": "openclaw"
|
||
}'
|
||
```
|
||
```
|
||
|
||
### 3. 工作流示例
|
||
|
||
**写作流程编排**：
|
||
|
||
```markdown
|
||
# 文章创作工作流
|
||
|
||
## 阶段1：观点讨论
|
||
调用：强哥的虎贲卫/张辽-dify
|
||
输入：用户原始想法
|
||
输出：批判性质疑、观点提炼
|
||
|
||
调用：强哥的虎贲卫/蒙田-dify
|
||
输入：张辽输出
|
||
输出：哲学视角深化、存在主义反思
|
||
|
||
## 阶段2：提纲构建
|
||
调用：强哥的虎贲卫/萧何-dify
|
||
输入：阶段1汇总
|
||
输出：结构化提纲
|
||
|
||
## 阶段3：正文生成
|
||
调用：强哥的龙骧营/某写作智能体-dify
|
||
输入：提纲
|
||
输出：初稿
|
||
|
||
## 阶段4：审校
|
||
调用：强哥的思想审判庭/魏征-dify
|
||
输入：初稿
|
||
输出：修改建议
|
||
|
||
## 阶段5：润色（本地 Kimi）
|
||
由主 Agent 完成最终语言润色
|
||
```
|
||
|
||
---
|
||
|
||
## 关键配置
|
||
|
||
### 环境变量管理
|
||
|
||
在 OpenClaw 配置或 `.env`：
|
||
```bash
|
||
# Dify API Keys
|
||
DIFY_ZHANGLIAO_KEY=app-xxxxx
|
||
DIFY_MENGDIAN_KEY=app-xxxxx
|
||
DIFY_ZHIXINGHEYI_KEY=app-xxxxx
|
||
DIFY_XIAOHE_KEY=app-xxxxx
|
||
# ... 其他40个
|
||
```
|
||
|
||
### 统一返回格式
|
||
|
||
建议 Dify 侧配置统一输出格式：
|
||
```json
|
||
{
|
||
"analysis": "分析内容...",
|
||
"key_points": ["要点1", "要点2"],
|
||
"questions": ["追问1", "追问2"],
|
||
"confidence": "high|medium|low"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 下一步行动
|
||
|
||
1. **确认 Dify 版本**：
|
||
- 社区版 / 云服务版？
|
||
- 是否已开启 API 访问？
|
||
|
||
2. **选一个试点**：
|
||
- 先封装 1-2 个智能体（如张辽、蒙田）
|
||
- 跑通端到端流程
|
||
|
||
3. **批量迁移**：
|
||
- 写脚本自动生成 skills/ 下的封装
|
||
- 或统一用一个 `dify-bridge` skill，通过参数路由
|
||
|
||
---
|
||
|
||
你想先从哪个开始试点？张辽还是蒙田？我可以帮你写完整的 skill 封装。
|
||
|