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

背景：

以下文字比较干，有需要的可以私信讨论！

定位

当前是一个本地 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 状态查询现在有确定性路径：
- main：/Users/jeff/.openclaw/workspace/scripts/run_codex_project_status.py:1
- Telegram：/Users/jeff/.openclaw/workspace/scripts/run_codex_project_status_telegram.sh:1
当前小红书项目的活跃 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