正儿八经 - 资深技术专家

前几天刷到个帖子，给我看傻了。

一个开发老哥，用 AI 智能体集群，一个人干了整支开发团队的活。不是 Demo，不是 toy project，是正经在跑的 B2B SaaS，还在产生真实收入。

这数据太离谱了

单日最高 94 次代码提交，日常平均 50 次。

最快 30 分钟合并 7 个 PR，需求从提出到上线通常当天搞定。

关键是，这些代码直接变成真金白银的 经常性收入。

整套系统跑下来，月均成本 190 美元，最低 20 美元就能起步。

这哥们儿叫 Elvis，已经把架构开源了。核心是个叫 OpenClaw 的智能体编排系统。

核心痛点：上下文窗口不够装

直接拿 Codex 或 Claude Code 写代码？那是老黄历了。

问题在于上下文窗口的零和博弈——代码塞多了，业务逻辑装不下；塞满客户历史，又看不懂代码库。

就像拿个小杯子装东西，代码和业务背景只能二选一，怎么都不够使。

破局的关键是：把业务跟代码解耦。

OpenClaw 是干嘛的

简单说，它是人和大模型之间的”翻译官”。

这个编排器叫 Zoe，直接读 Obsidian 里的客户数据、会议记录、历史决策，把业务上下文翻译成机器能懂的提示词。

有意思的是，这跟 Stripe 之前披露的 Minions 系统思路很像，但完全跑在本地。

工作流：极度克制的自动化

需求确定后，Zoe 干这几件事：

1. 调管理员 API 解除客户限制
2. 拉生产数据库的只读配置塞进提示词
3. 给每个智能体分配独立的 git worktree 和 tmux 会话

1
2
3
4
5

git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
cd ../feat-custom-templates && pnpm install
tmux new-session -d -s codex-templates \
  -c /Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates \
  $HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high

然后唤醒编码智能体：

1
2
3
4
5
6
7
8

codex --model gpt-5.3-codex \
  -c model_reasoning_effort=high \
  --dangerously-bypass-approvals-and-sandbox \
  "Your prompt here"

claude --model claude-opus-4.5 \
  --dangerously-skip-permissions \
  -p "Your prompt here"

tmux 这个用法挺妙

发现方向偏了，不用杀进程，直接往终端发指令强行纠偏：

1
2

tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

任务状态实时写进 .clawdbot/active-tasks.json：

1
2
3
4
5
6
7
8
9
10
11
12

{
  id: "feat-custom-templates",
  tmuxSession: "codex-templates",
  agent: "codex",
  description: "Custom email templates for agency customer",
  repo: "medialyst",
  worktree: "feat-custom-templates",
  branch: "feat/custom-templates",
  startedAt: 1740268800000,
  status: "running",
  notifyOnComplete: true
}

跑完自动更新：

1
2
3
4
5
6
7
8
9
10
11
12

{
  status: "done",
  pr: 341,
  completedAt: 1740275400000,
  checks: {
    prCreated: true,
    ciPassed: true,
    claudeReviewPassed: true,
    geminiReviewPassed: true
  },
  note: "All checks passed. Ready to merge."
}

监控：低成本轮询

用 cron 每 10 分钟跑一次确定性 Shell 脚本。

.clawdbot/check-agents.sh 检查会话状态、调 gh cli 验证 CI，卡住了自动重试最多 3 次。

代码提交门槛很高：TypeScript 检查、单元测试、Playwright 端到端测试，一个都不能少。UI 改动还必须带截图，否则 CI 直接拦下。

Code Review：三模型交叉验证

这套审查机制挺有意思：

• Codex：抓逻辑错误、竞态条件这些核心坑
• Gemini：盯安全漏洞和架构扩展性
• Claude Code：打辅助，做冗余验证

三个模型互相盯着，比单一模型靠谱多了。

改良版拉尔夫循环

底层跑的是改良版拉尔夫循环。

Zoe 不是机械地复用静态提示词，而是带着全局业务上下文去救场，动态调优失败的节点。

更狠的是，它还能自己找活干：

• 早上扫 Sentry 日志，自动派修复工单
• 开完会解析记录，提取功能需求
• 晚上梳理 git 日志，生成更新文档

基本不用人催，自己就把活儿干了。

模型分工很明确

不同模型干不同的事，不瞎折腾：

• Codex：90% 的复杂后端和跨文件重构
• Claude Code：前端构建和 git 操作
• Gemini：UI 设计环节输出规范文档

各干各的擅长的，效率最高。

部署：10 分钟搞定

最爽的是部署。把架构文档扔给 OpenClaw，10 分钟 内全自动完成脚本生成和目录搭建。

基本上就是”一键开店”的感觉。

唯一的瓶颈：内存

现在卡脖子的只有硬件内存。

每个独立工作树加并发编译环境，都在疯狂吃内存。

16GB 的 Mac mini 并发 4-5 个智能体就开始Swap了。

老哥已经下单了 3500 美元的 M4 Max Mac Studio（128GB 内存），准备突破并发上限。

一人公司时代真要来了

基于这套系统做的公关工具 Medialyst.ai 已经在落地。

不是概念验证，是真的在赚钱的一人企业。

我的一点想法

说实话，这事儿给我的震撼挺大的。

不是那种”AI 好牛逼”的震撼，而是”原来真的可以这么干”的震撼。

单人开发团队不是空谈，已经有人跑通了。关键不是某个模型多强，而是怎么让多个模型协同起来。

OpenClaw + Codex/CC 这个组合，给了一个很清晰的方向：

编排比模型本身更重要。

传统软件开发那套流程正在被重塑。以前需要产品经理、开发、测试、运维一堆人干的事，现在一个人加一堆智能体就能搞定。

一人公司的时代，可能比我们想象的来得更快。

参考链接：https://x.com/elvissun/status/2025920521871716562

缘起

最近发现一个 GitHub 项目 wshobson/agents，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。

让我震撼的几个数字：

• 112 个专业 AI Agent
• 16 个多智能体工作流编排器
• 146 个 Agent Skills
• 79 个开发工具
• 72 个独立插件

这已经不是”用 AI 辅助编程”了，这是用 AI 团队替代开发团队。

核心架构：插件化设计

wshobson/agents 最聪明的设计是插件化。

它不是给你一个大而全的系统，让你把所有东西都加载进来。而是拆成 72 个独立的插件，每个插件只做一件事，但做到极致。

为什么要插件化？

上下文窗口是有限的资源。如果你一次性加载 112 个 Agent 和 146 个 Skills， token 消耗会爆炸。

插件化的解决方案：按需加载。

举个例子：

1
2

# 安装 Python 开发插件
/plugin install python-development

这个插件只加载：

• 3 个 Python 专业 Agent
• 1 个脚手架工具
• 16 个专业 Skills

总共约 1000 个 token，而不是整个市场的几万 token。

插件的分类

72 个插件分成 24 个类别，每个类别 1-6 个插件：

这种结构的好处是：想用啥装啥，绝不多加载。

三层模型策略

这个项目最让我印象深刻的是它的模型分层策略。

不是一刀切地用同一个模型，而是根据任务复杂度分配不同的 Claude 模型：

为什么 Opus 4.6 负责关键任务？

几个硬指标：

• SWE-bench 80.8% — 行业领先
• 复杂任务 token 减少 65%
• 最适合架构决策和安全审计

虽然 Opus 单价高（$5/$25 每百万 token），但因为 token 效率更高，实际成本往往更低。

Tier 2 的灵活性

Tier 2 的 Agent 标记为 inherit，意思是使用你当前会话的默认模型。

怎么用？

1
2
3

# 启动会话时指定模型
claude --model opus    # 需要高强度时用 Opus
claude --model sonnet  # 日常开发用 Sonnet

这样你可以根据当前任务灵活选择，不用改配置。

Agent Teams：真正的并行工作流

这是我觉得最实用的功能：多智能体并行。

安装 Agent Teams 插件：

1

/plugin install agent-teams@claude-code-workflows

7 个预设团队

实战示例：并行代码审查

1

/team-review src/ --reviewers security,performance,architecture

这个命令会：

1. 启动 3 个审查 Agent（安全、性能、架构）
2. 每个 Agent 独立审查代码
3. 汇总结果，生成综合报告

传统的代码审查是串行的：一个人看完再给下一个人。现在是三个人同时看，时间从几小时缩短到几分钟。

实战示例：假设驱动调试

1

/team-debug "API returns 500" --hypotheses 3

系统会：

1. 生成 3 个关于 500 错误的假设
2. 每个假设分配一个 Agent 去验证
3. 并行执行验证
4. 返回最可能的根因

这比一个人一个个尝试 hypotheses 快多了。

Conductor：项目管理的 AI 化

另一个强大的插件是 Conductor，它把 Claude Code 变成了项目管理工具。

1

/plugin install conductor@claude-code-workflows

核心工作流

1. 交互式项目初始化

1

/conductor:setup

这个命令会：

• 创建产品愿景
• 确定技术栈
• 定义工作流规则
• 生成代码风格指南

2. 基于 Track 的开发

1

/conductor:new-track

生成规格说明和分阶段实施计划。

3. TDD 工作流

1

/conductor:implement

执行任务，带验证检查点。

4. 语义化回滚

1

/conductor:revert

按逻辑单元回滚（track、phase 或 task）。

状态持久化

项目上下文跨会话持久保存。你今天设置的项目，明天打开 Claude Code 还能继续。

Skills：渐进式知识披露

146 个 Skills 是 wshobson/agents 的知识层。

每个 Skill 是一个专门的知识包，遵循渐进式披露架构：

Skills 的分类

语言开发：

• Python（5 个）：async 模式、测试、打包、性能、UV 包管理
• JavaScript/TypeScript（4 个）：高级类型、Node.js 模式、测试、ES6+

基础设施：

• Kubernetes（4 个）：manifest、Helm、GitOps、安全策略
• 云基础设施（4 个）：Terraform、多云、混合网络、成本优化
• CI/CD（4 个）：流水线设计、GitHub Actions、GitLab CI、密钥管理

AI/ML：

• LLM 应用（8 个）：LangGraph、Prompt Engineering、RAG、评估、embedding、相似性搜索、向量调优、混合搜索

区块链：

• Web3（4 个）：DeFi 协议、NFT 标准、Solidity 安全、Web3 测试

激活示例

当你使用 Python 开发插件时，相关 Skills 会自动激活：

1
2
3
4
5
6

用户："创建一个 FastAPI 微服务"

系统激活：
- async-python-patterns
- python-testing-patterns  
- uv-package-manager

你不需要手动选择，系统根据上下文自动加载。

实战：从零搭建全栈功能

让我用一个完整示例展示这套系统的能力。

场景：添加用户认证功能

传统方式：

1. 设计数据库表（1 小时）
2. 写后端 API（4 小时）
3. 写前端页面（4 小时）
4. 写测试（2 小时）
5. 代码审查（1 小时）
6. 部署（1 小时）

使用 wshobson/agents：

1
2
3
4
5
6
7

# 安装必要插件
/plugin install full-stack-orchestration
/plugin install python-development
/plugin install backend-development

# 启动全栈编排
/full-stack-orchestration:full-stack-feature "user authentication with OAuth2"

系统会协调 7+ 个 Agent：

1. backend-architect → 设计 API 架构
2. database-architect → 设计数据库 schema
3. frontend-developer → 实现登录 UI
4. test-automator → 生成单元测试和 E2E 测试
5. security-auditor → 安全审计
6. deployment-engineer → 配置部署
7. observability-engineer → 设置监控

这些 Agent 并行工作，不是串行。

结果：

• 时间从 13 小时缩短到 30 分钟
• 包含安全审计和测试覆盖
• 自动部署和监控

安全加固示例

1
2

/plugin install security-scanning
/security-scanning:security-hardening --level comprehensive

这个命令会启动多 Agent 安全评估：

• SAST 扫描
• 依赖项扫描
• 代码审查
• 合规检查

Python 项目脚手架

1
2

/plugin install python-development
/python-development:python-scaffold fastapi-microservice

自动激活的 Skills：

• async-python-patterns - AsyncIO 和并发
• python-testing-patterns - pytest 和 fixtures
• uv-package-manager - 快速依赖管理

生成的项目包含：

• 生产级 FastAPI 结构
• 异步模式最佳实践
• 完整的测试套件
• Dockerfile 和 docker-compose
• CI/CD 配置

成本分析

大家最关心的：这得花多少钱？

模型成本

实际使用成本

一个小型项目团队（3-5 人）的月度估算：

• 日常开发（Sonnet）：$50-100/月
• 关键架构审查（Opus）：$30-50/月
• 自动化任务（Haiku）：$10-20/月

总计：$90-170/月

对比：

• 一个初级开发者的工资：$3000-5000/月
• 这个系统的成本：1/30

ROI 非常明显。

省钱技巧

1. 用 inherit 模式灵活选择模型

   • 日常开发用 Sonnet
   • 关键任务切换到 Opus

2. 合理拆分任务

   • 大任务拆成小任务
   • 减少单次调用的 token 消耗

3. 利用 Skills 的渐进披露

   • 只在需要时加载详细知识
   • 避免不必要的资源加载

与 OpenClaw 的对比

有人可能会问：这个和之前写的 OpenClaw 有什么区别？

我的建议：

• 如果你已经在用 Claude Code，直接上 wshobson/agents
• 如果你需要更灵活的编排或有特殊需求，考虑 OpenClaw
• 两者也可以结合：用 OpenClaw 做高层编排，wshobson/agents 做具体执行

个人思考

用了一段时间 wshobson/agents，有几个感触：

1. 专业化分工是趋势

不是让一个大模型做所有事，而是让多个专业 Agent 各做各的。

就像真正的开发团队：

• 架构师做设计
• 后端写 API
• 前端做界面
• 测试写用例
• 运维管部署

AI Agent 也在走这条路。

2. 编排层的价值被低估了

很多人关注单个 Agent 的能力，但编排层才是放大器。

好的编排可以让 10 个普通 Agent 发挥 100 个 Agent 的效果。

3. 上下文管理是关键

wshobson/agents 的插件化和渐进披露设计，本质上是在解决上下文管理问题。

有限的上下文窗口 → 按需加载 → 最大化利用

这是所有 AI 系统都要面对的挑战。

4. 成本可控比想象中容易

很多人被 Opus 的价格吓到，但：

• 大部分任务用 Sonnet 就够了
• Opus 的 token 效率更高
• 合理分层后，实际成本很低

5. 未来是”人机协作团队”

不是 AI 替代人类，而是人类+AI 团队替代传统团队。

一个产品经理 + wshobson/agents = 一个完整开发团队

这不是科幻，是现在就能实现的事。

如何开始

第一步：添加插件市场

1

/plugin marketplace add wshobson/agents

第二步：浏览可用插件

1

/plugin

第三步：安装你需要的

1
2
3
4
5
6
7
8
9
10
11
12

# 基础开发
/plugin install python-development
/plugin install javascript-typescript

# 代码审查
/plugin install comprehensive-review

# 全栈工作流
/plugin install full-stack-orchestration

# 多智能体团队
/plugin install agent-teams

第四步：开始使用

1
2
3
4
5
6
7
8

# 并行审查
/team-review src/

# 全栈功能开发
/full-stack-orchestration:full-stack-feature "your feature"

# Python 脚手架
/python-development:python-scaffold your-project

写在最后

wshobson/agents 让我看到了 AI 辅助开发的下一个阶段。

不是更好的单轮对话，不是更长的上下文窗口，而是系统化的多智能体协作。

112 个 Agent、16 个编排器、146 个 Skills — 这些数字背后是一个清晰的愿景：

让一个人拥有整个团队的能力。

这不是取代人类，而是给人类超能力。

你仍然是决策者、架构师、审查者。但执行层面的工作，可以交给这个永不疲倦的 AI 团队。

未来已来，只是分布不均。

参考

• 项目地址：https://github.com/wshobson/agents
• Claude Code 文档：https://code.claude.com
• Agent Teams 文档：项目中查看 /agent-teams
• Conductor 文档：项目中查看 /conductor

背景

最近在 GitHub 上看到个项目,叫 Strix。

看了一下,这玩意挺有意思的。像黑客一样的 AI 智能体,用来做安全测试。

简单说,就是一群 AI 代理,像黑客一样攻击你的应用。做个记录，方便后续需要时查看使用。

Strix 是什么

根据官方介绍:

Strix 是开源的 AI 智能体安全测试平台。

它的核心思想:让多个 AI Agent 协作,自动发现和修复安全漏洞。

核心特点

• 多智能体协作:多个 Agent 一起工作
• 真实验证:用 PoC 概念验证漏洞
• 自动修复:生成可修复的 PR
• 快速反馈:CI/CD 集成
• 低误报:减少假阳性

核心能力

1. 应用安全测试

Strix 可以对任何应用进行全面的安全测试:

• 漏洞发现:自动识别常见漏洞
• 渗透测试:模拟真实攻击场景
• 验证测试:PoC 验证
• 安全审计:全面安全评估

2. Agent 协作

这是 Strix 的核心。

多个 AI Agent 像黑客团队一样工作:

• 有些负责扫描
• 有些负责攻击
• 有些负责验证
• 有些负责报告生成

好处:

• 并行处理,速度快
• 全覆盖,不遗漏
• 模拟真实攻击,更精准

3. 代码分析

静态和动态代码分析能力:

• 静态分析:SAST/DAST
• 依赖检查:第三方库安全扫描
• 配置审计:安全配置检查
• 代码质量:安全相关代码质量检查

4. Web 安全

针对 Web 应用的安全测试:

• XSS 检测:跨站脚本攻击
• CSRF 防护:跨站请求伪造
• SQL 注入检测:数据库注入攻击
• 命令注入:系统命令注入攻击

5. API 安全

API 安全测试能力:

• 认证测试:API 认证机制
• 授权测试:API 授权和权限
• 速率限制:API 限流测试
• 数据泄露:敏感数据泄露检测

快速开始

环境要求

• Docker 运行
• LLM API Key (OpenAI/Anthropic/Google 等)
• Python 3.8+

安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 克隆仓库
git clone https://github.com/usestrix/strix.git

# 进入目录
cd strix

# 安装依赖
pip install -r requirements.txt

# 配置 API Key
export STRIX_LLM="openai/gpt-4"
export LLM_API_KEY="your-api-key"

# 运行首次扫描
strix --target ./your-app-directory

配置说明

首次运行会自动:

• 拉取 Docker 镜像
• 启动沙箱环境
• 运行安全扫描
• 生成报告

使用场景

场景一:GitHub 仓库安全测试

1
2

# 扫描 GitHub 仓库
strix --target https://github.com/your-org/your-repo

Strix 会:

• 扫描代码仓库
• 检查依赖安全问题
• 生成安全报告
• 创建修复 PR

场景二:本地代码库测试

1
2

# 扫描本地代码
strix --target ./my-codebase

扫描:

• 所有 Python/JavaScript 文件
• 配置文件安全检查
• 硬编码密钥检测
• 敏感信息泄露检测

场景三:Web 应用渗透测试

1
2

# 渗透测试
strix --target https://your-app.com --mode penetration

Agent 会:

• 自动发现登录页面
• 尝试常见攻击
• 测试权限绕过
• SQL 注入测试
• XSS 攻击测试

场景四:自动化 CI/CD 集成

1
2

# CI/CD 安全测试
strix --target ./ci-cd-pipeline

测试:

• GitHub Actions 安全配置
• 工作流注入攻击测试
• 密钥泄露检测
• 恶意依赖检测

网络上的实践案例

案例:发现高危漏洞

有安全团队分享了 Strix 的使用经验:

1. 零日漏洞发现

   • Strix 在测试某应用时
   • 发现了一个未公开的漏洞利用
   • 该漏洞被标记为 0day
   • 生成了详细的 PoC

2. 自动化漏洞挖掘

   • 传统的手工挖掘需要数周
   • Strix 用 Agent 自动挖掘
   • 一周内发现 10+ 个逻辑漏洞

3. 误报率降低

   • 静态工具误报率通常 20-30%
   • Strix 通过 AI 验证降低到 3-5%
   • 大幅减少人工审核时间

案例:提高测试效率

某开发团队的对比:

效率提升非常明显。

Strix 平台

除了开源 CLI 工具,Strix 还提供了完整平台:

app.strix.ai

• 可视化界面:Web 界面管理测试项目
• 多项目管理:同时管理多个测试项目
• 团队协作:团队成员共同参与
• 报告生成:自动生成美观的安全报告
• 历史追踪:测试历史和漏洞追踪

功能特性

• 实时监控:测试进度实时查看
• 通知提醒:关键发现自动通知
• 导出功能:多格式导出报告
• API 访问:开放 API 供集成

企业版特性

• SSO 单点登录
• 自定义合规报告
• 专属支持
• 私有化部署

技术架构

前端

• React:用户界面
• Tailwind CSS:样式框架
• Vite 5:构建工具

后端

• FastAPI:Python Web 框架
• Celery:任务队列
• PostgreSQL:数据库

AI 核心

• 多模型支持:支持多个 LLM Provider
• Agent 编排:智能体协调和任务分配
• 知识库:安全知识库和攻击模式

安全沙箱

• Docker 隔离:每个测试运行在独立容器
• 网络隔离:受控网络环境
• 资源限制:CPU/内存限制
• 日志审计:完整操作日志

优势和限制

优势

1. 开源免费:完全开源,免费使用
2. 快速上手:配置简单,5 分钟开始测试
3. 自动化程度高:大部分测试自动完成
4. 社区活跃:GitHub 上活跃,持续更新
5. 多供应商支持:不绑定单一 API,成本可控

局限性

1. LLM 成本:依赖付费 LLM API,测试成本高
2. 技术门槛:需要一定 AI 和安全知识
3. 误报率:虽然降低到 3-5%,但仍需人工验证
4. 资源消耗:多 Agent 并发,资源消耗大
5. 学习曲线:需要学习 Strix 的使用方式

适用人群

安全团队

• 适合需要提高测试效率的团队
• 特别是 AI 驱动的安全测试
• 需要处理大量漏洞报告

开发团队

• 适合想要自动化安全测试的团队
• 可以作为 CI/CD 流程的一部分
• 需要定期进行安全审计的团队

AI 研究者

• 适合研究智能体安全的研究
• 可以作为研究平台使用
• 需要测试新攻击向量的团队

实用建议

1. 从小规模开始

不要一上来就想大规模部署。

建议:

• 先用 Strix 测试一个小项目
• 熟悉工作流
• 验证效果
• 再逐步扩大规模

2. 重视人工验证

虽然 AI 自动化,但人工验证仍然重要。

建议:

• 重点关注高影响漏洞
• 认真审核 AI 发现的问题
• 建立验证标准和流程

3. 合理控制成本

LLM API 成本不低。

建议:

• 选择性价比高的模型
• 用 Strix Router 统一管理多个 Provider
• 设置合理的速率限制
• 监控使用量和成本

4. 结合传统工具

Strix 不是要完全替代传统工具,而是补充。

建议:

• SAST/DAST 工具继续使用
• Strix 用于 Agent 协作和智能分析
• 两者结合,发挥各自优势

5. 学习和贡献

Strix 是开源项目,鼓励社区贡献。

建议:

• 阅读官方文档
• 学习源代码
• 提 Issue 和 PR
• 分享使用经验

写在最后

Strix 代表了AI 驱动的安全测试新方向。

它的核心思想:用一群 AI Agent,像黑客团队一样协作,自动发现和修复漏洞。

优势:

• 测试速度快
• 覆盖率高
• 误报率低
• 自动化程度高

需要注意:

• LLM 成本不低
• 有一定学习曲线
• 仍需人工验证

对于安全团队、开发团队、AI 研究者,都值得关注。

如果你在做 AI Agent 相关开发,Strix 提供了一个很好的参考。

参考

• 项目地址: https://github.com/usestrix/strix
• 官方文档: https://docs.strix.ai
• 平台地址: https://app.strix.ai
• Discord 社区: https://discord.gg/strix-ai

引言

最近在 GitHub 上看到一个项目,叫 moyin-creator。关注这个项目是因为我媳妇儿现在天天看这种二维动画（小说）一天能看好几个小时，而且我看点赞啥的还非常高，有点意思，没想到这么low的这么多人看。先做个记录，后面花时间自己搞一个，实现财富自由？

它不是简单的 AI 视频生成器,而是一套面向 AI 视频创作者的生产级工作流。

简单说,就是从剧本到成片的完整自动化。

项目概览

五大板块

moyin-creator 的工作流分成五个部分:

1. 📝 剧本 - AI 剧本生成
2. 🎭 角色 - AI 角色设计
3. 🌄 场景 - AI 场景构建
4. 🎞 导演 - AI 分镜管理
5. ⭐ S级 - Seedance 2.0 批量生产

这五个板块环环相扣,每一步的产出自动流入下一步。

核心功能

多镜头合并叙事视频生成

这个功能听起来挺高级的。

传统的视频制作,每个镜头单独拍,后期再剪辑。

moyin-creator 用 AI 直接生成多视角合并的叙事视频。

比如,同一场景从三个角度拍,合并成一个连贯的叙事。

好处:

• 不用实际拍
• AI 自动生成不同视角
• 后期剪辑量大幅减少

剧本解析引擎

上传剧本,系统自动解析。

识别:

• 角色
• 场景
• 分镜
• 对白
• 情绪

解析后,这些信息会自动分配到对应的生成任务。

角色一致性系统

这个很重要。

同一个角色在不同分镜中必须保持一致:

• 服装
• 发型
• 妆容
• 道具

系统通过 Character Bible 管理这些约束。

绑定角色参考图,确保一致性。

场景生成:多视角联合图

AI 可以生成多视角的场景描述图。

比如,角色 A 从左看场景,角色 B 从右看。

这些描述图会自动转换为视觉提示词,指导视频生成。

导演分镜系统

电影级摄影参数:

• 景别
• 机位
• 运动方式

自动排版和导出。

视觉风格一键切换:

• 2D
• 3D
• 写实
• 定格动画

Seedance 2.0 参数约束

Seedance 2.0 有参数限制。

自动校验:

• 图片 ≤9 张
• 视频 ≤3 个
• 音频 ≤3 个
• prompt ≤5000 字

超过就自动拒绝或截断。

好处:

• 避免超成本
• 保证 API 调用效率

批量化生产工作流

多任务并行队列:

• 自动重试失败任务
• 任务优先级管理
• 进度追踪

适合:

• 短剧批量生产
• 动漫番剧批量制作
• 预告片批量生成

技术架构

前端技术

这个技术栈很现代,开发体验应该不错。

后端核心

@opencut/ai-core 是 AI 核心引擎。

主要功能:

• Prompt 编译
• 角色圣经管理
• 任务轮询管理
• 多供应商 API 集成

这是整个系统的大脑。

项目结构

1
2
3
4
5
6
7
8
9
10
11

moyin-creator/
├── electron/              # Electron 主进程
│   ├── main.ts           # 主进程入口
│   └── preload.ts        # 安全桥接层
├── src/                   # React 前端源码
│   ├── components/       # UI 组件
│   │   ├── panels/      # 功能面板
│   │   ├── stores/       # 状态管理
│   └── packages/        # 内部包
│       └── ai-core/      # AI 核心引擎
└── scripts/              # 构建脚本

结构清晰,模块化做得不错。

使用流程

环境要求

• Node.js >= 18
• npm >= 9
• 支持 Windows, macOS, Linux

安装运行

1
2
3
4
5
6
7
8
9

# 克隆项目
git clone https://github.com/MemeCalculate/moyin-creator.git
cd moyin-creator

# 安装依赖
npm install

# 启动开发模式
npm run dev

配置 API Key

首次启动后进入设置页面。

配置你的 AI 服务商 API Key:

• OpenAI
• Anthropic
• Google
• 或者其他兼容的 API

配置好后就可以开始使用了。

使用场景

场景一:短剧批量生产

1. 上传剧本文件
2. 系统自动解析剧本
3. 生成角色和场景
4. 批量生成视频片段
5. 自动剪辑和配乐
6. 导出成品

适合自媒体工作室,短视频创业公司。

场景二:预告片制作

1. 写剧本或用 AI 生成
2. 设定分镜脚本
3. 生成高质量场景图
4. 生成预告片视频
5. 配音和后期处理

适合影视工作室,内容创作团队。

场景三:广告视频批量化

1. 设定广告脚本
2. 批量生成多个变体
3. A/B 测试不同版本
4. 自动分析数据,选择最优方案
5. 批量导出和分发

适合广告公司,电商营销团队。

优势分析

相比传统方式

实际使用建议

1. 先从小规模开始

不要一上来就想批量生产几百个视频。

建议:

• 从一个 5-10 分钟的短剧开始
• 熟悉工具和工作流
• 找到问题和优化点
• 再逐步扩大规模

2. 重视剧本质量

AI 再强大,也需要好的剧本。

建议:

• 简单但有趣的故事
• 明确的角色设定
• 清晰的场景描述
• 合理的分镜节奏

好的剧本是成功的一半。

3. 合理使用 Seedance 2.0

Seedance 2.0 是当前最强的视频生成模型,但成本也高。

建议:

• 短视频用 Seedance 2.0
• 长视频用其他模型
• 混合使用,控制成本
• 实时预览,减少重试次数

4. 注意参数约束

Seedance 2.0 的参数限制是硬约束,不是建议。

违反的话:

• 直接被 API 拒绝
• 任务失败
• 浪费成本

一定要在约束范围内使用。

5. 建立内容标准

批量生产时,质量更重要。

建议:

• 统一角色设定
• 统一视觉风格
• 统一音频标准
• 定期审核和优化

网络上的实践案例

短剧生产

有个博主分享了 moyin-creator 的使用流程:

1. 用 GPT-4 写剧本
2. 导入 moyin-creator 解析剧本
3. 配置 5 个角色
4. 批量生成 100 个视频
5. 用剪映自动剪辑
6. 发布后批量上传

一周生产了 100 个短剧,效率提升明显。

预告片制作

另一个工作室用 moyin-creator:

1. 写了 10 个预告片剧本
2. 用 Seedance 2.0 生成高质量场景图
3. 用 Kling 生成预告片视频
4. 批量配音和后期处理
5. 一周内完成 10 个预告片

效率比传统方式提升了 10 倍以上。

商业广告批量化

广告公司用它:

1. 批量生成 20 个产品广告
2. 每个广告 5 个版本
3. A/B 测试不同文案和视觉效果
4. 自动分析数据,选择最优方案
5. 批量导出和分发

广告投放效果提升了 35%。

未来趋势

AI 视频生成的趋势

1. 多模态融合

   • 文本 + 图像 + 音频 + 视频
   • 模型越来越强,成本越来越低
   • moyin-creator 的架构可以快速集成新模式

2. 实时生成

   • 实时预览和调整
   • 减少重试次数
   • 提升用户满意度

3. 个性化定制

   • 基于用户数据的模型微调
   • 风格一致性系统
   • 自动化质量检查

4. 自动化工作流

   • 更多环节自动化
   • 减少人工干预
   • 提升整体效率

moyin-creator 的机会

优势

1. 完整的产业链覆盖

   • 从剧本到成片的完整工作流
   • 不是单一工具,是平台级解决方案

2. 模块化架构

   • 各个板块可以独立优化
   • 便于扩展和维护

3. 多供应商支持

   • 不绑定单一 AI 服务商
   • 用户有更多选择和议价权

4. 开源可定制

   • 技术栈公开
   • 商业许可证可选
   • 可以二次开发和定制

潜在挑战

1. 竞争激烈

   • Midjourney, Runway, Kling 都在快速迭代
   • moyin-creator 需要持续创新

2. 成本压力

   • Seedance 2.0 等模型的成本很高
   • 用户需要控制预算

3. 质量平衡

   • 追求效率可能影响质量
   • 需要找到平衡点

4. 用户习惯

   • 传统创作团队有固定工作流
   • 工具需要适应不同团队

给不同用户的建议

内容创作者

如果你想尝试 moyin-creator:

1. 先评估需求

   • 你需要批量生产吗?
   • 预算规模和成本
   • 团队有技术能力自己部署吗?

2. 从小规模实验

   • 不要一上来就大规模投入
   • 先做几个小项目验证效果
   • 熟悉工作流后再扩大

3. 重视内容质量

   • 剧本是基础,多花时间打磨
   • 角色和场景设计要有吸引力
   • 不要因为批量生成就忽视质量

4. 合理选择模型

   • Seedance 2.0 用于高质量场景
   • 其他模型用于普通内容
   • 混合使用,控制成本

开发者

如果你想学习 moyin-creator 的技术实现:

1. 研究技术架构

   • Electron + React 技术栈
   • Zustand 状态管理
   • 模块化设计

2. 学习 AI 集成

   • 如何设计 AI 核心
   • 如何实现多供应商支持
   • 如何设计任务队列

3. 学习视频处理

   • FFmpeg 集成
   • 视频编码和优化
   • 批量处理优化

4. 考虑贡献代码

   • 开源项目需要社区贡献
   • 可以提 issue 或提 PR

企业用户

如果你考虑在企业中使用:

1. 评估 ROI

   • 效率提升 vs 工具成本
   • 削减和人力成本节省
   • 投资回报周期

2. 数据安全

   • 本地部署 vs 云端部署
   • API Key 安全管理
   • 用户数据保护

3. 团队培训

   • 工作流培训
   • 最佳实践分享
   • 持续优化和改进

写在最后

moyin-creator 代表了 AI 视频生成工具的一个方向:生产级工作流自动化。

它不是一个”黑科技”,而是一套实用的工程化解决方案。

它的价值不在于用了什么先进技术,而在于:

• 完整的产业链覆盖
• 高效的批量生产能力
• 好的质量控制
• 合理的成本控制

适合内容创作者、影视工作室、广告公司,或者任何需要批量生产视频内容的团队。

但也要理性看待:

• 不要被”批量生产”迷惑
• 质量仍然是核心竞争力
• 工具是辅助,不是替代人的创造力

找到自己的节奏,持续优化,才是王道。

参考

• 项目地址: https://github.com/MemeCalculate/moyin-creator
• 中文文档: https://www.bilibili.com/video/BV1FsZDBHExJ/?vd_source=802462c0708e775ce81f95b2e486f175
• 网盘提取码: 8888

📢 更新日志：

• 2026-03-09 补充 HEARTBEAT.md 抢占主会话的排障记录，修正文中 Docker Compose 版本与记忆机制描述，新增“升级是否成功”的核验方法。
• 2026-03-06 新增 Step-3.5-Flash 接入与会话级 /model 切换说明，补充默认模型不切全局、只切当前会话的使用方式。
• 2026-03-03 新增”记录系统优化”章节，解决会话文件膨胀问题，添加自动归档和结构化存储方案。

写在前面

最近刷到不少 OpenClaw 的文章，演示零成本安装、智能体集群、国内部署经验。我手头正好有台配置不高的云服务器闲置着，决定动手搭建一个专属 AI 助手。

但这篇文章不是推广，是真实的部署踩坑记录。整个过程历时数小时，遇到了 OOM 内存不足、配置验证失败、防火墙规则冲突等一系列问题，把完整的解决过程记录下来。

先说结论：OpenClaw 确实能跑起来，但需要对 Docker、网络和 Linux 有一定了解，且内存配置要充足。

OpenClaw 是什么

OpenClaw 是一个开源的个人 AI 助手框架，核心价值在于：它不是只聊天的 AI，而是能动手干活的 AI。

核心能力：

• 在 Telegram、Discord、Slack 等平台接收指令
• 操作文件系统、执行 Shell 命令、浏览网页
• 调用 API、读写数据库
• 跨会话持久化记忆

最重要的是——运行在自己的服务器上，数据完全掌控。

我的环境

搬瓦工买的一台机器，配置不高，平时捣鼓各种东西的。

⚠️ 重要提示：2GB 内存对于源码构建来说不够，需要配置 Swap。

部署过程实录

第一步：安装 Docker

Ubuntu 24.04 下安装 Docker 很顺利：

1
2
3
4
5
6
7
8
9

# 更新系统
apt update && apt upgrade -y

# 安装 Docker
curl -fsSL https://get.docker.com | sh

# 验证安装
docker --version  # Docker version 29.2.1
docker compose version  # Docker Compose version v5.1.0

国内用户建议配置镜像加速，编辑 /etc/docker/daemon.json：

1
2
3
4
5
6

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://dockerhub.icu"
  ]
}

第二步：源码构建（第一个坑：OOM）

官方提供了 Docker 镜像，但我选择从源码构建以获得最新功能：

1
2
3
4

mkdir -p /opt/openclaw
cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git
cd openclaw

开始构建：

1

docker build -t openclaw:local -f Dockerfile .

🚨 第一个大坑：构建到 pnpm install 时容器被杀

查看日志发现是 OOM（内存不足）。2GB RAM 在构建 Node.js 项目时不够用，pnpm install 直接占满内存导致进程被系统杀死。

解决方案：添加 Swap 空间

1
2
3
4
5
6
7
8
9

# 创建 5GB Swap 文件
dd if=/dev/zero of=/swapfile bs=1G count=5
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 验证
free -h
# 显示：Swap: 5.0Gi

添加 Swap 后重新构建，成功完成。

📷 安装过程 - 添加 Swap 解决 OOM：

第三步：配置 OpenClaw

创建 docker-compose.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

version: '3.8'

services:
  openclaw-gateway:
    image: openclaw:local
    container_name: openclaw
    restart: unless-stopped
    environment:
      - HOME=/home/node
      - NODE_ENV=production
    volumes:
      - ./.openclaw:/home/node/.openclaw
      - ./.openclaw/workspace:/home/node/.openclaw/workspace
    ports:
      - "127.0.0.1:18789:18789"
      - "127.0.0.1:18790:18790"
    command: ["node", "dist/index.js", "gateway", "--bind", "lan", "--port", "18789"]

🚨 第二个坑：配置验证极其严格

OpenClaw 对 openclaw.json 配置文件的校验非常严格，很多字段在官方文档中没有明确说明，但缺失会导致启动失败。

我遇到的错误：

1
2
3

✖ Configuration validation failed:
  - gateway.mode is required
  - gateway.controlUi.allowedOrigins is required when using non-loopback bind

正确的最小配置（openclaw.json）：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
    },
    "auth": {
      "token": "your-secure-token-here"
    }
  }
}

📷 OpenClaw Web UI 界面：

关键注意点：

• gateway.mode 必须显式设置为 "local"
• gateway.controlUi.allowedOrigins 在使用非 localhost 绑定时是必需的
• gateway.bind 不能写在 JSON 中（无效字段），必须通过 CLI 参数 --bind lan 设置

第四步：配置阿里云百炼模型

我选择使用阿里云百炼的 Coding Plan，配置 kimi-k2.5 作为主力模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
  "models": {
    "mode": "merge",
    "providers": {
      "bailian": {
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
        "apiKey": "YOUR_BAILIAN_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "kimi-k2.5",
            "name": "kimi-k2.5",
            "input": ["text", "image"],
            "contextWindow": 262144,
            "maxTokens": 32768
          },
          {
            "id": "qwen3.5-plus",
            "name": "qwen3.5-plus",
            "input": ["text", "image"],
            "contextWindow": 1000000,
            "maxTokens": 65536
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bailian/kimi-k2.5"
      }
    }
  }
}

第五步：配置 Telegram Bot

在 @BotFather 创建 Bot 并获取 Token。

🚨 第三个坑：配对码过期与 dmPolicy 冲突

1
2
3
4
5
6
7
8
9

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "YOUR_BOT_TOKEN_HERE",
      "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
    }
  }
}

初始配置时我加了 "dmPolicy": "open"，结果与 allowFrom 白名单冲突，报错：

1

dmPolicy: open requires allowFrom: ["*"]

解决方案：删除 dmPolicy 字段，直接使用 allowFrom 白名单。

启动服务：

1
2

docker compose up -d
docker compose logs -f

看到日志显示 Telegram channel started 且没有错误，说明 Bot 已上线。

📷 Telegram Bot 配置成功：

第六步：Google Workspace 集成（扩展能力）

这是 OpenClaw 真正强大的地方——通过 Google Workspace 集成，AI 可以帮你管理邮件、日历、文档。

OpenClaw 使用 gog skill 来访问 Google 服务（Gmail、Calendar、Drive、Docs、Sheets）。

6.1 创建 Google Cloud 项目

1. 访问 Google Cloud Console
2. 创建新项目（例如：openclaw-integration）
3. 启用以下 API：
   • Gmail API
   • Google Calendar API
   • Google Drive API
   • Google Docs API
   • Google Sheets API

6.2 配置 OAuth 凭据

1. 进入 APIs & Services > Credentials
2. 点击 Create Credentials > OAuth client ID
3. 选择 Desktop app 类型
4. 记下 Client ID 和 Client Secret

6.3 配置 MCP 服务器

OpenClaw 通过 MCP (Model Context Protocol) 集成 Google Workspace。

在服务器上创建 MCP 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

mkdir -p /opt/openclaw/.openclaw/mcp
cat > /opt/openclaw/.openclaw/mcp/google-workspace.json << 'EOF'
{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": ["-y", "@gongchangio/mcp-google-workspace"],
      "env": {
        "GOOGLE_CLIENT_ID": "your-client-id.apps.googleusercontent.com",
        "GOOGLE_CLIENT_SECRET": "your-client-secret",
        "GOOGLE_REDIRECT_URI": "http://localhost:18790/oauth2callback"
      }
    }
  }
}
EOF

6.4 重启 OpenClaw 并授权

1
2
3
4
5

cd /opt/openclaw
docker compose restart

# 查看日志等待授权提示
docker compose logs -f | grep -i google

首次启动会显示 OAuth 授权链接，在浏览器中打开并授权后，会获得一个 code，将其填回即可。

6.5 实际使用场景

配置完成后，你可以通过 Telegram 让 AI 帮你：

管理邮件：

“帮我查看今天的重要邮件，并回复需要处理的”

操作日历：

“帮我查一下下周的会议安排，把周五下午的会议改到周四”

读写文档：

“读取 Drive 里的 ‘项目计划.docx’，帮我总结要点并更新状态”

⚠️ 注意：Google OAuth 有权限范围限制

• 个人 Gmail 账户：直接可用
• Google Workspace（企业账户）：需要管理员授权
• 敏感范围（如删除邮件）需要额外验证

第七步：安全加固（重中之重）

🚨 第四个坑：Docker 绕过 INPUT 链的防火墙规则

我最初的防火墙配置：

1
2

iptables -I INPUT 1 -p tcp --dport 18789 -s 127.0.0.1 -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 18789 -j DROP

测试发现：公网仍然可以访问 Web UI！

原因：Docker 在 DOCKER 链中插入了 ACCEPT 规则，且该链在 INPUT 链之前被处理。

正确的解决方案：使用 DOCKER-USER 链

1
2
3
4
5
6
7
8

# 在 DOCKER-USER 链中插入规则（在 Docker 规则之前执行）
iptables -I DOCKER-USER 1 -p tcp -s 127.0.0.1 --dport 18789 -j ACCEPT
iptables -I DOCKER-USER 2 -p tcp --dport 18789 -j DROP
iptables -I DOCKER-USER 3 -p tcp -s 127.0.0.1 --dport 18790 -j ACCEPT
iptables -I DOCKER-USER 4 -p tcp --dport 18790 -j DROP

# 保存规则
iptables-save > /root/iptables-rules.txt

最终安全策略：

📷 最后安全检查 - 安全加固结果：

SSH 隧道访问命令：

1
2

ssh -N -L 18789:127.0.0.1:18789 root@your-server-ip
# 然后在本地浏览器访问 http://localhost:18789

进阶玩法：持久记忆配置（第9步）

OpenClaw 的持久记忆系统让它能跨会话记住你的偏好、项目信息和个人习惯。这是从”工具”升级为”助手”的关键。

记忆文件目录结构

核心记忆文件

1. USER.md - 用户档案

1
2
3
4
5
6
7
8
9
10

# USER.md - About Your Human

- **Name:** Gamehu
- **What to call them:** Gamehu
- **Timezone:** Asia/Shanghai (UTC+8)

## Context
- **职业:** IT 行业，编程 + 团队管理
- **需求:** 个人助手
- **风格偏好:** 简单直接，不绕弯子

2. MEMORY.md - 长期记忆

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# MEMORY.md - Long-term Memory

## Technical Stack
- **Primary Languages:** Java, JavaScript, Python, Go
- **Frameworks:** Spring Boot, React
- **Cloud:** Alibaba Cloud, AWS

### Preferences
- **Code Style:** Clean, well-documented
- **Learning Style:** Hands-on, project-based
- **Dislikes:** Repetitive small talk

### Current Projects
- Building personal AI assistant
- Managing development team

如何工作

1. 自动记忆：所有对话自动存入 SQLite，跨会话保持上下文
2. 结构化记忆：AI 主动读取 MEMORY.md 了解你的背景和偏好
3. 持续更新：OpenClaw 可以通过 heartbeat 或维护任务定期整理记忆，但主会话不建议配置成高频主动提醒模式

测试持久记忆

给 Bot 发送：

“记住我喜欢用 Go 语言写后端服务”

过一段时间再问：

“我之前告诉你我喜欢用什么语言？”

如果配置正确，Bot 应该能回答出 Go。

进阶玩法：记录系统优化（第9.5步，新增）

在解决 compaction 卡死问题后，我意识到 OpenClaw 的会话记录管理还有很多优化空间。之前的经历是：会话文件在两天内膨胀到 1.4MB（603 条消息），导致系统卡死。为了防止类似问题再次发生，我设计并部署了一套结构化的记录管理系统。

为什么需要记录系统优化

优化后的目录结构

我在 workspace 下创建了完整的分类存储结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/root/.openclaw/workspace/
├── memory/                    # 记忆类数据
│   ├── daily/                # 每日摘要 (YYYY-MM-DD.md)
│   ├── weekly/               # 每周汇总
│   └── archived/             # 长期归档
├── records/                   # 记录类数据
│   ├── conversations/        # 对话记录 (按月归档)
│   │   └── 2026-03/
│   │       ├── 2026-03-03/   # 当日完整会话
│   │       └── 2026-03-03-sessions.tar.gz
│   ├── tasks/                # 任务记录
│   │   ├── completed/        # 已完成任务
│   │   └── failed/           # 失败任务
│   ├── browser/              # 浏览器操作记录
│   │   ├── screenshots/      # 网页截图
│   │   └── page-dumps/       # 页面快照
│   └── files/                # 文件操作日志
├── outputs/                   # 输出类数据
│   ├── generated/            # AI 生成的文档
│   ├── exports/              # 导出文件
│   └── reports/              # 定时报告
└── logs/                      # 日志类
    ├── system/               # 系统日志 (archive-YYYY-MM-DD.log)
    ├── model/                # 模型调用记录
    └── errors/               # 错误日志

自动归档脚本

创建 /root/.openclaw/workspace/archive-daily.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#!/bin/bash
WORKSPACE="/root/.openclaw/workspace"
SESSIONS_DIR="/home/node/.openclaw/agents/main/sessions"
DATE=$(date +"%Y-%m-%d")
MONTH=$(date +"%Y-%m")

# 创建归档目录
mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
mkdir -p "$WORKSPACE/memory/daily"

# 归档会话文件
if [ -d "$SESSIONS_DIR" ]; then
    cp "$SESSIONS_DIR"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
    SESSION_COUNT=$(ls -1 "$SESSIONS_DIR"/*.jsonl 2>/dev/null | wc -l)
    SIZE=$(du -sb "$SESSIONS_DIR" 2>/dev/null | cut -f1)
else
    SESSION_COUNT=0
    SIZE=0
fi

# 生成每日摘要 Markdown
cat > "$WORKSPACE/memory/daily/${DATE}.md" << DAILYMD
---
date: ${DATE}
type: daily-summary
sessions_count: ${SESSION_COUNT}
sessions_size_kb: $((${SIZE} / 1024))
---

# 📅 ${DATE} 对话摘要

## 📊 今日统计
- **日期**: ${DATE}
- **星期**: $(date +%A)
- **会话数**: ${SESSION_COUNT}
- **数据大小**: $((${SIZE} / 1024)) KB

## 🏷️ 重要标签
- 

## 💡 今日收获
- 

## 📌 待办事项
- [ ] 

---
DAILYMD

# 记录归档日志
echo "[$(date)] 归档完成: ${DATE}, ${SESSION_COUNT} 个会话" >> "$WORKSPACE/logs/system/archive-${DATE}.log"

赋予执行权限：

1

chmod +x /root/.openclaw/workspace/archive-daily.sh

配置定时任务

添加每天 23:00 自动执行归档：

1
2
3
4
5

# 添加定时任务
(crontab -l 2>/dev/null | grep -v archive-daily; echo "0 23 * * * /root/.openclaw/workspace/archive-daily.sh >> /root/.openclaw/workspace/logs/system/cron.log 2>&1") | crontab -

# 查看已配置的定时任务
crontab -l

快捷命令配置

创建 /root/.openclaw/.aliases.sh，方便快速查看记录：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 查看今日记录
alias oc-today='cat /root/.openclaw/workspace/memory/daily/$(date +%Y-%m-%d).md 2>/dev/null || echo "今日记录不存在"'

# 查看昨日记录
alias oc-yesterday='cat /root/.openclaw/workspace/memory/daily/$(date -d yesterday +%Y-%m-%d 2>/dev/null || date -v-1d +%Y-%m-%d).md 2>/dev/null || echo "昨日记录不存在"'

# 手动执行归档
alias oc-archive='/root/.openclaw/workspace/archive-daily.sh'

# 查看统计
alias oc-stats='echo "=== OpenClaw 统计 ===" && echo "会话文件: $(ls -1 /home/node/.openclaw/agents/main/sessions/*.jsonl 2>/dev/null | wc -l)" && echo "每日摘要: $(ls -1 /root/.openclaw/workspace/memory/daily/*.md 2>/dev/null | wc -l)"'

# 查看目录大小
alias oc-size='du -sh /root/.openclaw/workspace/*/ 2>/dev/null | sort -h'

使用方法：

1
2
3
4
5
6
7
8
9
10
11

# 加载快捷命令
source /root/.openclaw/.aliases.sh

# 查看今日记录
oc-today

# 手动归档
oc-archive

# 查看统计
oc-stats

Docker 容器内配置

为了让 OpenClaw Bot 也能执行归档，在 Docker 容器内创建归档脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 在容器内创建归档命令
docker exec openclaw-openclaw-gateway-1 bash -c 'cat > /tmp/oc-archive.sh << "EOF"
#!/bin/bash
WORKSPACE="/home/node/.openclaw/workspace"
SESSIONS="/home/node/.openclaw/agents/main/sessions"
DATE=$(date +"%Y-%m-%d")
MONTH=$(date +"%Y-%m")
mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
COUNT=0
if [ -d "$SESSIONS" ]; then
  cp "$SESSIONS"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
  COUNT=$(ls -1 "$SESSIONS"/*.jsonl 2>/dev/null | wc -l)
fi
cat > "$WORKSPACE/memory/daily/$DATE.md" << DAILY
---
date: $DATE
type: daily-summary
sessions_count: $COUNT
---

# 📅 $DATE 对话摘要

## 📊 统计
- 会话数: $COUNT

## 🏷️ 标签
- 

## 💡 收获
- 
DAILY
echo "✅ 归档完成: $DATE, $COUNT 个会话"
EOF
chmod +x /tmp/oc-archive.sh'

Telegram Bot 使用

配置完成后，你可以直接在 Telegram 中对 Bot 发送：

每日摘要示例

生成的 Markdown 文件 (memory/daily/2026-03-03.md)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---
date: 2026-03-03
type: daily-summary
sessions_count: 5
sessions_size_kb: 45
---

# 📅 2026-03-03 对话摘要

## 📊 今日统计
- **日期**: 2026-03-03
- **星期**: Tuesday
- **会话数**: 5
- **数据大小**: 45 KB

## 🏷️ 重要标签
- OpenClaw 配置
- 技能开发

## 💡 今日收获
- 配置了自动归档系统
- 解决了会话文件膨胀问题

## 📌 待办事项
- [ ] 测试归档功能
- [ ] 配置 Web 画廊

这种结构化的记录管理方式，让你可以：

1. 快速回顾 - 每天打开 Markdown 文件即可看到当日概况
2. 防止膨胀 - 自动归档避免会话文件无限增长
3. 便于导出 - 重要记录可以轻松导出分享
4. Telegram 管理 - 直接通过 Bot 指令管理记录

进阶玩法：自定义 Skill（第10步）

OpenClaw 的 Skill 系统让你可以扩展 AI 的能力。我把自己的 Hexo 博客做成了 Skill，让 Bot 可以直接帮我创建博客文章。

我的 Hexo 博客 Skill

1. 创建脚本

在服务器上创建文章生成脚本 /opt/hexo-blog/create-post.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#!/bin/bash
# Hexo Blog Post Creator

BLOG_DIR="/opt/hexo-blog"
POSTS_DIR="$BLOG_DIR/source/_posts"

# 参数
TITLE="${1:-新建文章}"
CATEGORY="${2:-随笔}"
TAGS="${3:-日常}"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
FILENAME=$(echo "$TITLE" | sed 's/ /-/g' | tr '[:upper:]' '[:lower:]')-$(date +"%Y%m%d").md

# 创建目录
mkdir -p "$POSTS_DIR"

# 创建文章
cat > "$POSTS_DIR/$FILENAME" << EOF
---
title: $TITLE
author: Gamehu
date: $DATE
tags:
EOF

# 添加标签
IFS=',' read -ra TAG_ARRAY <<< "$TAGS"
for tag in "${TAG_ARRAY[@]}"; do
    echo "  - $(echo $tag | xargs)" >> "$POSTS_DIR/$FILENAME"
done

# 添加分类和正文
cat >> "$POSTS_DIR/$FILENAME" << EOF
categories:
  - $CATEGORY
---

## 写在前面

$TITLE

<!-- more -->

## 正文

开始写作...

---
EOF

echo "✅ 文章创建成功: $POSTS_DIR/$FILENAME"

赋予执行权限：

1

chmod +x /opt/hexo-blog/create-post.sh

2. 创建 Skill 文件

OpenClaw 使用 SKILL.md 文件（不是 YAML），创建 ~/.openclaw/skills/hexo-blog/SKILL.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

---
name: hexo-blog
description: Create and manage Hexo blog posts via shell script
---

# Hexo Blog Skill

Create new blog posts with proper front matter for Hexo.

## Usage

Ask me to create a blog post:
- "帮我创建一篇博客文章，标题是《XXX》，分类是技术，标签是 OpenClaw,AI"
- "写一篇新文章，关于 Docker 使用心得"

## Tools

This skill uses the `shell` tool to execute `/opt/hexo-blog/create-post.sh`.

## Example

```bash
/opt/hexo-blog/create-post.sh "文章标题" "分类" "标签1,标签2"

1
2
3
4
5

#### 3. 重启 OpenClaw 加载 Skill

```bash
docker restart openclaw-openclaw-gateway-1

验证 Skill 是否加载：

1
2

openclaw skills list
# 应该显示: ✓ ready │ 📦 hexo-blog │ Create and manage Hexo blog posts...

3. 实际使用

在 @gamehu_kb_bot 里直接说：

“帮我创建一篇博客文章，标题是《OpenClaw 使用心得》，分类是工具，标签是 OpenClaw,AI”

Bot 会自动：

1. 生成文件名 openclaw-shi-yong-xin-de-20260302.md
2. 创建带完整 Front Matter 的 Markdown 文件
3. 返回文件路径

Skill 核心概念

更多 Skill 想法

• Git Helper: 自动提交、查看状态、创建分支
• Docker Manager: 查看容器日志、重启服务
• File Organizer: 整理下载文件夹、重命名文件
• Daily Reporter: 生成每日工作总结

进阶玩法：浏览器控制（第12步）

OpenClaw 内置了浏览器控制功能，让 AI 能够操作真实浏览器执行网页任务，比如搜索信息、填写表单、抓取数据等。

🚨 坑位 14：Docker 镜像默认不包含浏览器

问题

Docker 部署后尝试使用浏览器功能时，报错：

1
2

[tools] browser failed: Error: No supported browser found 
(Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).

原因

默认的 Dockerfile 不会安装 Chromium/Playwright 浏览器，需要通过 --build-arg OPENCLAW_INSTALL_BROWSER=1 参数构建带浏览器的镜像。

解决方案：重新构建带浏览器的镜像

1. 停止当前服务

1
2

cd /opt/openclaw
docker compose down

2. 构建带浏览器的新镜像

1
2
3
4
5

# 构建时间约 15-30 分钟，增加约 300MB
docker build -t openclaw:local-browser -f Dockerfile \
  --build-arg OPENCLAW_INSTALL_BROWSER=1 \
  --build-arg OPENCLAW_DOCKER_APT_PACKAGES="chromium xvfb" \
  .

3. 修改环境变量使用新镜像

编辑 .env 文件：

1
2
3
4
5

# 修改前
OPENCLAW_IMAGE=openclaw:local

# 修改后
OPENCLAW_IMAGE=openclaw:local-browser

4. 启动服务

1

docker compose up -d

5. 验证浏览器安装

1
2
3
4
5
6
7
8

# 进入容器检查
docker exec openclaw-openclaw-gateway-1 \
  ls -la /home/node/.cache/ms-playwright/

# 应该看到：
# chromium-1208/
# chromium_headless_shell-1208/
# ffmpeg-1011/

浏览器控制功能

使用示例

在 Telegram 中直接发送以下指令：

搜索信息：

“打开浏览器，访问 GitHub，搜索 ‘openclaw’，告诉我前 3 个结果”

商品比价：

“帮我在京东上搜索 ‘机械键盘’，找到评分最高的 3 个产品，记录价格”

数据抓取：

“访问 https://news.ycombinator.com/，提取首页前 10 条新闻的标题和链接”

浏览器控制原理

1

用户指令 → OpenClaw Agent → 浏览器控制服务 → 无头 Chrome → 网页操作 → 结果返回

浏览器控制服务默认监听：http://127.0.0.1:18791/

注意事项

1. 无头模式：Docker 部署默认使用 headless 模式（无界面），适合服务器环境
2. 访问限制：受限于服务器网络，无法访问需要登录的页面（除非提供 Cookie）
3. 执行时间：复杂页面加载可能需要 10-30 秒
4. 安全提醒：避免让 Bot 访问敏感网站或输入真实账号密码

实践任务

尝试让 Bot 完成以下任务：

• ✅ 信息收集：从某个网站抓取数据并整理
• ✅ 表单填写：自动填写一个在线表单
• ✅ 价格比较：在多个网站比较同一商品的价格

进阶玩法：多 Bot 配置（第11步）

OpenClaw 支持配置多个 Telegram Bot，每个 Bot 可以绑定不同的 Agent，实现分工协作。
注意：仅配置 channels.telegram.accounts 还不够，想要真正隔离上下文，必须再加 agents.list + bindings。

我的多 Bot 架构

配置步骤

1. 在 @BotFather 创建多个 Bot

每个 Bot 都需要独立的 Token：

1
2
3
4

/main_bot - 主助手
/news_bot - 新闻助手  
/growth_bot - 成长助手
/kb_bot - 知识库助手

2. 配置多账号

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "channels": {
    "telegram": {
      "enabled": true,
      "accounts": {
        "main": {
          "botToken": "YOUR_MAIN_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "news": {
          "botToken": "YOUR_NEWS_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "growth": {
          "botToken": "YOUR_GROWTH_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "kb": {
          "botToken": "YOUR_KB_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        }
      }
    }
  }
}

3. 增加 Agent 路由绑定（关键）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "agents": {
    "list": [
      { "id": "main",   "default": true, "workspace": "/home/node/.openclaw/workspace" },
      { "id": "news",   "workspace": "/home/node/.openclaw/workspace-news" },
      { "id": "growth", "workspace": "/home/node/.openclaw/workspace-growth" },
      { "id": "kb",     "workspace": "/home/node/.openclaw/workspace-kb" }
    ]
  },
  "bindings": [
    { "agentId": "main",   "match": { "channel": "telegram", "accountId": "main" } },
    { "agentId": "news",   "match": { "channel": "telegram", "accountId": "news" } },
    { "agentId": "growth", "match": { "channel": "telegram", "accountId": "growth" } },
    { "agentId": "kb",     "match": { "channel": "telegram", "accountId": "kb" } }
  ]
}

⚠️ workspace 字段必须显式指定：每个 agent 需要独立的 workspace 路径，否则多个 agent 共享同一个 workspace，记忆和配置会互相干扰。

这样每个 bot 会落到不同 agent，会话文件分目录保存，记忆文件也完全隔离。

4. 为每个 Agent 创建独立 Workspace

每个 agent 对应一个独立目录，在服务器上创建：

1
2
3

mkdir -p /root/.openclaw/workspace-news
mkdir -p /root/.openclaw/workspace-growth
mkdir -p /root/.openclaw/workspace-kb

每个目录下的结构：

1
2
3
4
5
6

workspace-news/
├── SOUL.md        # Agent 的身份定义
├── MEMORY.md      # 长期记忆
├── USER.md        # 用户信息
├── AGENTS.md      # Agent 行为规范
└── memory/        # 每日记忆文件

每个 AGENT.md 定义该 Bot 的专业领域和行为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# News Agent

## Role
你是一个科技新闻助手，专注于提供最新、最有价值的科技资讯。

## Capabilities
- 追踪科技行业动态
- 总结技术文章要点
- 提供每日新闻简报

## Style
- 简洁明了，重点突出
- 提供信息来源链接
- 主动推送重要消息

4. 重启服务

1

docker compose restart

查看日志确认所有 Bot 启动：

1
2
3
4

[telegram] [main] starting provider (@GameHuOpenclaw_bot)
[telegram] [news] starting provider (@gamehu_news_bot)
[telegram] [growth] starting provider (@gamehu_growth_bot)
[telegram] [kb] starting provider (@gamehu_kb_bot)

实际使用效果

• 上下文隔离：在 @gamehu_growth_bot 聊学习计划，切到 @gamehu_news_bot 问新闻，再回到 growth Bot，它还记得刚才的学习话题
• 专业化分工：每个 Bot 专注于自己的领域，回复质量更高
• 并行对话：可以同时和多个 Bot 对话，互不干扰

⚠️ 注意事项

• 多账号配置时，不要在顶层设置 botToken，全部放在 accounts 下
• 每个 accountId（如 main、news、growth、kb）必须是唯一的
• 账号名不要用 default，会和系统默认账号冲突

进阶玩法：定时任务推送到指定 Bot（第11.5步）

配置好多 Bot 之后，你可能会发现一个问题：OpenClaw 里设置的定时任务（cron job），推送结果全都跑到了 main bot，而不是对应的 bot。

🚨 坑位 17：定时任务 delivery 缺少 accountId

问题现象

在 OpenClaw Web UI 里配了新闻推送任务，时间一到，消息却出现在了 @GameHuOpenclaw_bot（main bot），而不是 @gamehu_news_bot。

根本原因

OpenClaw 的定时任务存储在 ~/.openclaw/cron/jobs.json，每个任务的 delivery 字段控制推送目标。如果只写了 to（用户 ID），没有写 accountId，OpenClaw 不知道用哪个 bot 账户推送，默认走 main。

另外，to 只负责“推给谁”（用户 / 群 / 频道），accountId 负责“用哪个 bot 发”。这两个字段职责不同，缺一不可。

有问题的配置：

1
2
3
4
5

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "YOUR_USER_ID"
}

解决方案

在每个 job 的 delivery 中加上 accountId，同时在 job 顶层加上 agentId。建议把执行超时提到 120 秒（字段 timeoutSeconds）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "id": "xxx",
  "agentId": "news",
  "name": "每日新闻推送",
  "timeoutSeconds": 120,
  "payload": {
    "kind": "agentTurn",
    "message": "执行新闻脚本并发送结果给用户"
  },
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "YOUR_USER_ID"
  }
}

推送目标的两种正确姿势

方案 A（推荐）：同一个用户，按不同 Bot 身份推送

这种方式最适合你当前“4 个 Bot 各司其职”的场景。to 全部写你的用户 ID，accountId 分别写 main/news/growth/kb，消息会显示来自对应 bot。

1
2
3
4
5
6
7
8
9
10

{
  "agentId": "news",
  "timeoutSeconds": 120,
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "YOUR_USER_ID"
  }
}

方案 B：推送到群 / 频道 / 话题

如果要发到频道，不要填 bot 用户名（如 @gamehu_news_bot），而是填频道 chat id（通常是 -100...）。并确保对应 bot 已加入目标群/频道且有发言权限。

1
2
3
4
5
6
7
8
9
10

{
  "agentId": "news",
  "timeoutSeconds": 120,
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "-1001234567890"
  }
}

各任务对应关系

修改完 jobs.json 后重启服务即可生效：

1

cd /opt/openclaw && docker compose restart

进阶玩法：接入 Step-3.5-Flash，并支持会话级切换（第11.6步）

最近我把底层模型又补了一档：Step-3.5-Flash。但这里有个非常容易搞混的点，我一开始也踩了坑：

🚨 坑位 18：想要“随时切模型”，不等于要改全局默认模型

如果你直接把 agents.defaults.model.primary 全局切到 Step，看起来省事，实际上会把别的会话、别的 Bot，甚至定时任务一起带偏。
更稳的做法是：

• 全局默认模型继续保持不变，我这里还是 bailian/kimi-k2.5
• 把 step/step-3.5-flash 注册成一个可选 provider
• 需要的时候，直接在 当前 Telegram 会话 里发送 /model ... 切换

Step provider 配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

{
  "models": {
    "mode": "merge",
    "providers": {
      "bailian": {
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
        "apiKey": "YOUR_BAILIAN_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "kimi-k2.5",
            "name": "kimi-k2.5",
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      },
      "kimi": {
        "baseUrl": "https://api.moonshot.cn/v1",
        "apiKey": "YOUR_KIMI_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "moonshot-v1-128k",
            "name": "moonshot-v1-128k",
            "contextWindow": 131072,
            "maxTokens": 8192
          }
        ]
      },
      "step": {
        "baseUrl": "https://api.stepfun.com/v1",
        "apiKey": "YOUR_STEP_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "step-3.5-flash",
            "name": "Step 3.5 Flash",
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bailian/kimi-k2.5"
      },
      "contextTokens": 131072
    }
  }
}

为什么我把 contextTokens 调到 131072

这不是说 kimi-k2.5 或 step-3.5-flash 只能吃 128k，而是为了兼容我现在保留的第三档模型 moonshot-v1-128k。

如果你想做到：

• 默认走百炼
• 需要时切 Step
• 偶尔还能切回 Moonshot 做速度/成本对比

那最稳的双档/三档基线，就是把 contextTokens 先压在 131072。这样：

• bailian <-> step 切换时，几乎不会因为窗口变化引发额外压缩
• 切到 moonshot-v1-128k 时，也不会立刻超限

当前会话切换命令

直接在 Telegram 里发：

1
2
3
4
5
6

/models
/models step
/model status
/model step
/model bailian/kimi-k2.5
/model kimi/moonshot-v1-128k

这里要强调 3 个边界：

1. 只影响当前会话
2. 不会清空 SOUL.md / MEMORY.md / USER.md / AGENTS.md
3. 不会影响 cron 定时任务

也就是说，这种切换本质上是“会话级模型覆盖”，不是“全局改配置”。

切模型会不会丢上下文

长期记忆不会丢，工作区画像也不会丢。真正会受影响的是短期上下文压缩：

• 从 bailian/kimi-k2.5 切到 step/step-3.5-flash，因为两边都是大窗口，风险很低
• 从 bailian 或 step 切到 moonshot-v1-128k，因为窗口更小，下一轮可能触发更激进的 compaction

所以我现在的原则很简单：

• 平时默认：bailian/kimi-k2.5
• 需要测试 Step：/model step
• 需要切回稳定默认：/model bailian/kimi-k2.5
• 需要做小窗口对比：/model kimi/moonshot-v1-128k

⚠️ 如果你想支持“切换模型 step”这种中文自然语言，而不是 /model step，那是另外一层 parser 改造，不是 OpenClaw 开箱即用能力。

完整配置文件参考

openclaw.json（多 Bot 生产版本，已脱敏，包含 compaction 修复）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
    },
    "auth": {
      "token": "your-secure-token-here"
    }
  },
  "models": {
    "mode": "merge",
    "providers": {
      "bailian": {
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
        "apiKey": "YOUR_BAILIAN_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "kimi-k2.5",
            "name": "kimi-k2.5",
            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      },
      "kimi": {
        "baseUrl": "https://api.moonshot.cn/v1",
        "apiKey": "YOUR_KIMI_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "moonshot-v1-128k",
            "name": "moonshot-v1-128k",
            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 131072,
            "maxTokens": 8192
          }
        ]
      },
      "step": {
        "baseUrl": "https://api.stepfun.com/v1",
        "apiKey": "YOUR_STEP_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "step-3.5-flash",
            "name": "Step 3.5 Flash",
            "reasoning": false,
            "input": ["text", "image"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bailian/kimi-k2.5"
      },
      "contextTokens": 131072,
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 24000,
        "identifierPolicy": "strict",
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 6000
        }
      }
    },
    "list": [
      { "id": "main", "default": true },
      { "id": "news" },
      { "id": "growth" },
      { "id": "kb" }
    ]
  },
  "bindings": [
    { "agentId": "main", "match": { "channel": "telegram", "accountId": "main" } },
    { "agentId": "news", "match": { "channel": "telegram", "accountId": "news" } },
    { "agentId": "growth", "match": { "channel": "telegram", "accountId": "growth" } },
    { "agentId": "kb", "match": { "channel": "telegram", "accountId": "kb" } }
  ],
  "session": {
    "scope": "per-sender",
    "reset": {
      "mode": "idle",
      "idleMinutes": 30
    },
    "maintenance": {
      "mode": "enforce",
      "pruneAfter": "7d",
      "maxEntries": 120
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "groupPolicy": "allowlist",
      "historyLimit": 30,
      "accounts": {
        "main": {
          "botToken": "YOUR_MAIN_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist",
          "streaming": "off"
        },
        "news": {
          "botToken": "YOUR_NEWS_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist",
          "streaming": "off"
        },
        "growth": {
          "botToken": "YOUR_GROWTH_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist",
          "streaming": "off"
        },
        "kb": {
          "botToken": "YOUR_KB_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
          "dmPolicy": "pairing",
          "groupPolicy": "allowlist",
          "streaming": "off"
        }
      }
    }
  }
}