分享一个 OpenClaw 协同平台+CLI+工具调用思路+实战!

分享一个 OpenClaw 协同平台+CLI+工具调用思路+实战！

小插曲：最近一直在忙着研究场景落地的事儿，没有更新公众号！后面公众号可能会间断性断更，不过我有时间就会回来记录。

背景：

之前一直在想办法把 openclaw 和本地的应用、CLI、脚本、MCP 等串联起来，一直没想好一个脚手架，现在我这一套与其他架构最大的不同是，openclaw agent 只负责编排，存储任务发送与任务结果brief，所以用户交互层特别干净，减少了在用户交互层的思考，把复杂任务下发到更加复杂的其他agent 组织中完成。

以下是我一周前的架构思路，文字比较干，有需要的可以私信讨论！

定位

当前是一个本地 OpenClaw 协同平台原型，不是生产系统；统一入口是 Web，OpenClaw 负责编排，CLI / Browser / Desktop 负责执行，人只在高风险节点接管。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:11

当前 V1 目标是 PC 协同中枢，首个闭环是“工程与办公协同”。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:17

技术栈

平台后端

：Python 标准库 HTTP 服务，运行态落本地 JSON。入口和存储根在 /Volumes/jeff/codex-game/geo_server.py:17

平台前端

：原生 Web 页面，index.html + app.js + styles.css，由后端直接托管。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:73

编排层

：OpenClaw Gateway + workspace rules/hooks/registry，核心 agent 是 main / PM / Tech Lead / Fullstack / QA，Telegram 前台是 xiaofen。见 /Volumes/jeff/codex-game/docs/architecture/openclaw-geo-architecture.md:28

执行层

：Codex CLI、Claude Code CLI、Gemini CLI、browser automation、desktop automation、OpenClaw bridge。见 /Volumes/jeff/codex-game/docs/architecture/openclaw-geo-architecture.md:44、/Volumes/jeff/codex-game/geo_server.py:132

协作总线

：/Users/jeff/.openclaw/workspace/coordination 是任务真相源；平台只读写它，不再靠 session 文本推断。见 /Volumes/jeff/codex-game/geo_server.py:24

项目分层

：codex-game 只做平台；具体业务项目和 worktree 在 codex-project。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:127

核心架构

当前是 5 层：入口层、编排层、执行层、人工接管层、展示层。定义见 /Volumes/jeff/codex-game/docs/architecture/openclaw-geo-architecture.md:15

平台核心对象已经固定：ConversationWindow / TaskRecord / TaskPanel / ExecutionRecord / ArtifactRecord / GateRecord / ExecutorRecord。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:35

后端里已经把 agent、task panel、executor、template 固定成配置常量，便于平台读取和渲染。见 /Volumes/jeff/codex-game/geo_server.py:54、/Volumes/jeff/codex-game/geo_server.py:105、/Volumes/jeff/codex-game/geo_server.py:132、/Volumes/jeff/codex-game/geo_server.py:211

flowchart LR

A["用户入口Web / Telegram(xiaofen)"] --> B["OpenClaw 编排层main + specialist agents"]

B --> C["协调总线coordination/tasks + registry + gates"]

C --> D["执行层Codex CLI / Claude CLI / Gemini CLI / Browser / Desktop / Bridge"]

D --> E["证据与结果artifacts / executions / summaries"]

E --> B

B --> F["展示层Task Panel / Tasks / Executors / Gates"]

C --> G["人工接管send / login / destructive gate"]

当前业务流程

Web 平台流

：用户在 Web 发任务 -> main 拆任务 -> specialist 生成需求 / 方案 / 实现 / QA -> 执行器完成工作 -> 结果写入任务、执行、产物、gate -> Web 面板展示。入口与对象定义分别见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:31、/Volumes/jeff/codex-game/geo_server.py:105

模板闭环流

：目前已落地旅游新闻对账闭环和旅游内容审稿闭环两个模板，说明平台已经不是纯聊天，而是可重跑 workflow。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:96

Telegram 流

：自然聊天由 xiaofen 接；系统/工程任务升级到编排层；对 codex-project 状态类请求，当前已固定 helper 路径，不再走 ACP 或交互式 Codex。见 /Volumes/jeff/codex-game/PROJECT_CONTEXT.md:121、/Volumes/jeff/codex-game/PROJECT_CONTEXT.md:130

flowchart TD

A["Telegram 用户消息"] --> B["xiaofen前台助理"]

B -->|casual| C["直接回复"]

B -->|system / project status| D["固定 helper 或 main 编排"]

D --> E["coordination/tasks"]

E --> F["codex-project worktree或其他执行器"]

F --> G["状态结论 + 证据"]

G --> B

B --> H["最终人话回复"]

当前已验证的重点链路

平台工作台、任务面板、任务列表、执行器面板、人工接管面板都已经具备。见 /Volumes/jeff/codex-game/docs/architecture/openclaw-geo-architecture.md:66

codex-project

状态查询现在有确定性路径：

当前小红书项目的活跃 worktree 是 /Volumes/jeff/codex-project/worktrees/xhs-lawyer-agent/develop，这类状态请求会从 OpenClaw coordination 回写结果，再由 main 或 xiaofen 转述。记忆快照见 /Volumes/jeff/codex-game/docs/context/session-memory-2026-03-08-codex-telegram-routing.md:1

一句话总结

这套架构不是“一个大模型直接做所有事”，而是：OpenClaw 负责编排，外部执行器负责做工，coordination 负责共享状态，Web/Telegram 负责对人交互，gate 负责风险控制。di