OpenClaw 实战：一个人、一台 Mac、六个 AI Agent — 从"能聊天"到"能干活"的工程实战

你睡着的时候，交易蜘蛛已经出了股市收盘报告。你醒来之前，宏观分析师已经写完了 A 股晨报。你还没刷手机，管家蜘蛛已经推来了天气、日程和今日待办。与此同时，AI 哨兵已经扫完了 GitHub Trending、arXiv 最新论文和 100+ 个信息源——18+ 条技术情报按重要性排好序等你看。内容蜘蛛已经在跟踪 54 个平台的热榜和 X 热点。

这是我最关心的部分——AI 动态和技术趋势的自动追踪。哨兵发现有价值的开源项目或论文后，不仅推送新闻，还会评估对我们现有系统的影响，给出 P0/P1/P2 行动建议。有价值的发现会进入 Zoe 的 Tech Radar，走评估 → 决策 → 委派编码落地的完整链路。

从凌晨 3 点的自动备份到 23:45 的全团队反思，52 个 cron 任务每天自动轮转。而且 Agent 在自己进化——犯过的错会被记住，同类问题的复发率显著下降。这不是我写的规则，是 Agent 自己从.learnings/promote 到MEMORY.md的自主迭代。

1 个编排者 + 5 个专业 Agent + 6 类 ACP 编码专家（最大 6 并发）、52 个 cron 定时任务、118 个 Skills（33 全局共享 + 85 Agent 专属）、29 个注册 LLM 模型、每天几千次 LLM 调用、2086 行运维脚本 + 半个月 23 次自动恢复。

Agent 自己在进化才是真正有意思的部分：

• 自己设计通信协议— 两个 Agent "收到/确认"刷了十几轮，Zoe 自主诊断根因，设计三态协议（request → confirmed → final → 静默），smoke test 通过后沉淀到 AGENTS.md

• 自研 Skill 并发布到 ClawHub— Content 调研 7 个"去 AI 味"工具、A/B 测试、固化为 Skill 发布到 ClawHub，全团队次日自动共享

• 圆桌讨论产出策略报告— Macro 和 Trading 按协议进行下周 A 股策略讨论，产出含数据快照、仓位建议、止损纪律的完整报告

• Task Watcher 异步监控— Agent 承诺"审核通过后通知你"但实际做不到异步回调，Zoe 设计了 cron 级 Task Callback Event Bus 下沉监控

我的角色是搭好框架、设好约束、在关键节点确认方向——具体的需求发现、方案调研、协议设计、代码实现，都是 Agent 自己完成的。

Zoe（大龙虾）— CTO / 首席编排者

不只是"管理员"。Zoe 负责技术方案设计、任务编排、圆桌主持、系统运维和记忆系统维护——每天 3 次巡检（10:00/14:00/22:00），检查所有 Agent 的 cron 执行状态、workspace 磁盘使用、session 健康度。每周分析各 Agent 的 MEMORY.md 是否超限并执行分层压缩。更关键的是，Zoe 会消费 ainews 提供的技术发现，评估哪些值得应用到我们的系统上，征得我同意后指派 ainews 深入调研，然后自行设计方案、委派 ACP 编码专家实现——从技术发现到方案落地的完整链路。

每次巡检覆盖 6 大维度：cron 任务执行状态（是否有失败/跳过的任务）、workspace 磁盘使用（文件增长异常检测）、session 大小与健康度、Chrome CDP 进程是否泄露、.learnings/中是否有待处理条目、shared-context/时间戳是否正常（检测 Agent 是否"静默失联"）。

Zoe 最有价值的能力是方案设计——三态通信协议、Task Watcher、通信 Guardrail 框架，都是 Zoe 发现问题后自主设计的。下面是 Zoe 设计 Task Watcher 时的方案讨论：

AI 哨兵（ainews）— 情报中枢

这是我最关心的 Agent。它不是"推新闻"——每天从 100+ 个信息源（GitHub Trending、arXiv、RSS、HackerNews、Reddit 等）采集信息，按 5 星制评估后产出晨报、午间论文解读、晚间趋势分析。7 个 cron 任务覆盖晨午晚三报（08:30/12:00/20:00），每份报告末尾都预留了「改写要点（供 Content 参考）」接口。

更关键的能力是主动评估技术发现对我们系统的影响——本周就发现了 ReMe（记忆管理框架），主动向 Zoe 提出评估建议，从发现到决策到落地，我只需要在关键节点确认，执行全部由 Agent 完成。每日趋势分析中的有价值项目会自动更新到shared-context/tech-radar.json，供 Zoe 每周 Tech Radar 审查：

核心采集工具链：github_trending.py（--ai-only过滤 +--since weekly周趋势）、rss_aggregator.py（多源并发采集）、arxiv_papers.py（多关键词搜索）、Tavily（AI 优化搜索首选）、agent-browser（Playwright 驱动，JS 渲染页面采集）。防幻觉硬约束：每条新闻 MUST 带原文 URL，发布前自检可达性，无法交叉验证的标注「单源，建议核实」。

交易蜘蛛（Trading）— 量化分析师

团队中任务最密集的 Agent——21 个 cron 任务。20 个原子量化工具（quant.pyCLI）、15 个专属 Skills（68000+ 行代码）、65/35 混合评分模型（65% 工具量化 + 35% AI 判断）。覆盖 A 股全时段（集合竞价→盘中每 10 分钟扫描→尾盘速报）+ 美股（盘前→盘中每 30 分钟→盘后夜报）+ 大宗商品（每小时白天+夜盘）。

核心方法论是四步分析框架：读取 Macro 宏观因子 → 多维评分（技术面 25% / 资金面 30% / 基本面 10% / 情绪面 20% / 市场面 15%）→ 逆向检验（与共识一致吗？若错最可能原因？）→ 输出标的+评分(0-100)+止损位+置信度。硬性规则：NEVER 给出没有止损的买入建议，NEVER 编造数据（工具失败时直接报告原因），置信度 <60% 标注「低置信度，建议观望」。

Macro（首席经济学家）— 数据驱动的四层映射

提供宏观→传导→国内→市场四层映射因子包，供 Trading 直接引用。9 个 cron 任务覆盖晨报(07:50)→午间(12:30)→财经晚报(18:00)→美股盘前(22:00)→美股收盘(次日05:20)。周日 18:30 率先产出周度宏观复盘，Trading 19:30 引用其结论做市场复盘——形成宏观→微观→技术的递进链路。

分析纪律：每个判断标注数据来源和时效性，区分事实（有数据）和判断（有逻辑无直接数据），标注置信度（高>70%/中50-70%/低<50%），每个判断提出反面论据。真实案例——伊朗局势分析时，传统框架预测"地缘→避险→黄金涨"，实际油价+14%但黄金-5%。Macro 的分析指出"油价涨幅>10%，通胀逻辑主导，市场交易的是通胀而非避险"。这个洞察被沉淀到 MEMORY.md 成为持久知识。

内容蜘蛛（Content）— 内容策略师

不是自己"想"内容，而是从团队情报链中提取素材——ainews 提供改写要点、Macro 提供深度分析、Trading 提供市场观点。9 个 cron 任务驱动 Research→Ideate→Write→Reflect 四阶段流水线：09:00 从 54 个平台热榜（微博/知乎/B站/抖音/百度/头条...）+ X 热点抓取 → 10:30 消费 ainews 改写要点生成创意 → 14:00 产出初稿经 Ripple 传播预测引擎评分后投递 → 22:10 反思。

最有意思的是自主进化能力——发现 AI 味太重后，Content 自行调研"去 AI 味"工具，编写 Skill，发布到 ClawHub，并沉淀为全团队通用能力。从发现问题到解决方案再到发布，Agent 自己走完了整个流程：

另一个自主进化的产物是X 五篮子热点雷达——Content 最初只抓 AI 热点然后摘抄，经过一次反馈后，它自己设计了覆盖五个维度的情报采集框架，并交叉读取其他 Agent 的当日情报：

关键约束：AI/科技部分不超过整份输出的 40%。这不是我写在 SOUL.md 里的硬编码，是 Content 自己在反思中迭代出来的——它发现产出全是 AI 内容后，主动给自己加了配额限制。

管家蜘蛛（Butler）— 生活管家

不只是"喝水提醒"——深度集成 Apple 生态（Reminders / Calendar / Health / Notes / Shortcuts），是真正的个人生活助理。7 个 cron 任务：早安问候(08:00)→日程规划(08:30)→5 次喝水提醒（每次换花样：温馨/幽默/知识科普/名人名言/emoji 五种风格随机切换）→健康检查(20:00)→晚安总结(22:00)。

核心理念是不多不少，刚刚好——单次提醒 <50 字，间隔 ≥1.5 小时，23:00–07:00 仅发送紧急事项。如果用户没回复，不会连续催促：

ACP 编码专家阵型

Pi / Claude Code / Codex / OpenCode / Gemini / GPT-5.3-Codex，通过 ACP 协议按需委派，最大 6 并发实例、120min TTL。分析 Agent 不写代码，编码全部通过sessions_spawn委派给专家——每种编码 Agent 都可以开多个并发实例。

一个关键决策是不要让分析 Agent 直接编码。早期我额外设了 coding、architect、PM 三个技术角色，结果发现这几个角色基本没什么实际产出——它们的能力和 Zoe + ACP 编码专家的组合高度重叠，反而增加了通信复杂度和调试成本。后来全砍了，编码通过 ACP 委派给 Claude Code 等专业工具。PM 和架构师？Zoe 兼任就够了。

复杂度随人数快速上升。3 个 Agent = 3 对交互关系，6 个 = 15 对。整个系统从零到 6 个 Agent 稳定运行，花了大约半个月的下班时间——每加一个新 Agent 都需要半天到一天的调试，处理和现有 Agent 的通信冲突、共享资源竞争、规则兼容。

从凌晨 03:00 的自动备份到 23:45 的全团队反思，52 个 cron 任务覆盖 A 股 + 美股双时区自动轮转。周日还有 Macro → Trading → Trading 的三级递进周报。

每天结束时，每个 Agent 独立反思当天的.learnings/待审条目，Zoe 最后汇总全团队产出：

从凌晨 03:00 的自动备份到 23:45 的全团队反思，52 个 cron 任务覆盖 A 股 + 美股双时区自动轮转。周日还有 Macro → Trading → Trading 的三级递进周报。

每天结束时，每个 Agent 独立反思当天的 .learnings/ 待审条目，Zoe 最后汇总全团队产出：

上面展示的是最终效果。但从"装好 OpenClaw"到"系统流畅运作"，再到"Agent 自主进化"——中间有巨大的鸿沟。三个核心工程问题，每一个都不是"写好 prompt"能解决的。

问题：Agent 系统的热力学第二定律

不加约束，entropy 只增不减。持续运行的 Agent 系统会确定性地走向崩溃——不是"可能"，是"一定"。

Agent 就像一个没有操作系统的进程：它能处理输入、产出输出，但谁来管理它的内存（上下文）？谁来做垃圾回收（Session 清理）？谁来防止 OOM（膨胀保护）？不设计就没有人管。

三个真实事故，按严重度排序：

P0 — 全团队瘫痪 8 小时

ainews 的 session 因为连续处理新闻和论文累积到235K tokens。Gateway 启动时对所有 session 做 compaction，这个 session 永远超时 → crash → macOS 守护进程ThrottleInterval=1每秒重启 → 无限循环。所有 Agent 全部离线。

修复要四层：手动清理膨胀 session →ThrottleInterval1→10 →idleMinutes180→30 →exec.securityfull→allowlist。这不是某一个参数的问题，是四个独立的防线全部缺失。

P1 — 3500 字报告被框架"优化"到 800 字

交易蜘蛛的收盘速报包含完整的数据表格、资金流向、个股评分。OpenClaw 在文本超过textChunkLimit时自动做 content compaction（LLM summarize），数据表格被"智能压缩"掉了。框架认为"帮你优化了"——但在数据密集场景下，AI 的"智能"是灾难。

P2 — 信息过载后关键规则失效

当 SOUL.md 里堆满了各种操作规范、当 session 膨胀到几万 tokens，Agent 开始"选择性遵守"规则。管家蜘蛛越界做投资分析。交易蜘蛛忽略数据验证规则。不是模型变笨了，而是关键信息被噪声淹没了——这是 Context Engineering 要解决的根本问题。

解决：双层控制 — Context Engineering + Harness

两层协同，两个都不能少。

第一层 — Context Engineering（设计 Agent 的信息架构）

设计 Agent 每次推理时看到的完整信息结构——系统级的信息架构设计：

• SOUL.md放在 system prompt 最前面，是 Agent 的"宪法"——身份定义、决策框架、绝对禁止项。保持精简，只放最核心的约束

• AGENTS.md跟在 SOUL.md 后面，定义操作规范和协作协议

• Skills通过extraDirs配置按需加载——Trading 有 15 个 Skills 共 68000+ 行内容，不可能全放在 system prompt 里。只在 Agent 需要用到某个 Skill 时才注入上下文

• shared-context/是跨 Agent 的共享状态，Agent 通过工具主动读取

• Obsidian Vault是冷存储，归档产出但不参与推理

LLM 的上下文窗口不是等价的。system prompt 前面的信息权重远高于后面的。session 膨胀到几万 tokens 后，早期消息的影响力被稀释——类似操作系统的内存管理：热数据放缓存，冷数据放磁盘，关键数据常驻内存。

Trading 的 15 个 Skills 中，stock_analysis（技术面评分）在每日扫描时才需要，bilateral_analysis（龙虎榜分析）只在异动时触发。全部常驻上下文的话，噪声淹没了真正重要的规则。通过extraDirs按需注入，每次推理只加载相关的 1-3 个 Skill。

规则措辞必须面向最弱的模型。多模型 fallback 环境下（GPT-5.4 超时 → Qwen3.5+ → Ollama qwen3:8b），规则遵循率随模型能力递减：

• "建议不要编造数据"→ GPT-5.4 基本遵守，Qwen3.5+ 偶尔遵守，qwen3:8b 几乎无视

• "MUST: 不编造数据"→ 各模型遵守率显著提升

• "MUST + P0 + NON-NEGOTIABLE"→ 即使弱模型也能保持较高的遵守率

多模型 fallback 时，不知道哪次推理会用弱模型，所以所有关键规则都要按最弱模型的理解能力来写。显式 > 隐式，硬规则 > 软建议。

第二层 — Harness（框架自动管理）

Agent 7×24 运行，session 会持续膨胀——你设计得再好，运行一天之后上下文就变了。框架替 Agent 管，OpenClaw 的 harness 配置提供自动化的上下文生命周期管理：

只有 Context Engineering 没有 Harness，session 膨胀到 235K tokens 后一样崩溃；只有 Harness 没有 Context Engineering，所有信息堆在一起、关键规则被噪声淹没。Context Engineering 定义信息的结构，框架管理信息的生命周期。

实际的openclaw.json配置（每个参数背后都是真实事故）：

{  "compaction": {    "mode": "safeguard",    "memoryFlush": {      "enabled": true,      "softThresholdTokens": 40000,      "prompt": "Distill to memory/YYYY-MM-DD.md. Focus: decisions, state changes, lessons, blockers."    }  },  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },  "session": {    "reset": { "mode": "daily", "atHour": 5, "idleMinutes": 30 },    "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 }  },  "hooks": {    "bootstrap": ["self-improving-agent"]  }}

四个机制的执行顺序很重要——compaction 先于 contextPruning，确保有价值的内容先被提取到memory/，再被清理。self-improving-agent 的 bootstrap hook 在新 session 启动时触发，把.learnings/和MEMORY.md注入上下文——这是 Agent"记住上次学到的东西"的关键机制。

跨会话记忆恢复链（Agent 重启后如何"想起来自己是谁"）：

新 session 启动  ↓ self-improvement hook: 读 SOUL.md → AGENTS.md → MEMORY.md → .learnings/  ↓ memorySearch: 从 memory/ + sessions 中检索与当前任务相关的历史上下文  ↓ 读取 shared-context/ (团队实时状态)Agent 恢复到"知道自己是谁、做过什么、团队现在在干什么"的状态

Agent 不需要"记住"所有对话——memoryFlush 提取的是 decisions/lessons/state changes，不是完整对话。memory/中的文件通常只有几百行，而原始 session 可能有几万 tokens。

问题：Agent 今天犯的错，明天还会犯

这是一个比上下文管理更深层的问题。chatbot 每次对话从零开始，所以它每次都犯同样的错是正常的。但如果你的 Agent 7×24 运行、每天处理几千次 LLM 调用，你会无法接受它反复犯同一个错误。

交易蜘蛛5 次把龙虎榜 API 字段名搞错——BILLBOARD_BUY_AMT写成BUY_AMT，每次 session 重置后记忆丢失，下一次又犯。用户纠正"昨天建议买军工，今天跌了就转空"，Agent 当场改了，但三天后遇到类似场景又给出同样的单向建议。

chatbot 和 Agent 的分水岭就在这里：Agent 应该能从错误中学习，并且下次不犯。但怎么实现？

解决：五层记忆 — 从人类认知模型中借鉴

设计记忆系统时，我参考了人类记忆的分层模型：工作记忆（短期）→ 长期记忆（经验）→ 程序性记忆（技能）。Agent 的记忆也应该有不同的时间尺度和管理方式：

层与层之间的衔接才是关键——这形成了一个完整的自主进化循环。

记忆自主迭代——6 步循环

这是整个系统最核心的机制。没有这个循环，Agent 只是 chatbot；有了这个循环，Agent 才是真正的 Agent。

Agent 可以自主更新.learnings/、MEMORY.md、memory/、knowledge/——但绝对不能改 SOUL.md。SOUL.md 是身份和硬约束，修改需要用户确认。我们真的遇到过 Agent 把自己的"人格"改松的情况——行为立刻变得不可控。

Zoe 每周还会做记忆系统维护——分析各 Agent 的 MEMORY 状态，做归档和压缩：

L5 的 ontology 知识图谱记录实体关系（Agent/Task/MarketInsight/Decision），vector_store.db提供语义级检索——Agent 不需要记住精确措辞，通过向量相似度找到相关历史决策。

真实进化案例

用户纠正: "昨天建议买军工，今天跌了就转空"  ↓即时记录 (.learnings/):  "[LRN-20260303-001] correction | priority: high | status: pending   军工策略在地缘利好场景下未充分强调短线拥挤与顶背离风险   Suggested Action: 条件单模板 — 入场带失效位 + bullish/base/bear 三情景"  ↓每日反思 cron (23:30): promote 到 MEMORY.md  ↓MEMORY.md: "❌ 事件驱动标的必须用条件单模板"  ↓三周后遇到类似板块轮动:  交易蜘蛛直接引用了这条经验

这不是我写的规则——是 Agent 从纠正中自己提炼出方案，自己写入长期记忆。每日反思 cron 会审查.learnings/中的 pending 条目并决定是否 promote：

更多真实进化记录：

记忆系统还在进化

记忆系统不是"设计好就不变的"。最近的一个例子：

Zoe 每周生成Tech Radar 报告，从 ainews 的情报中提取技术趋势，分为 Adopt/Trial/Assess 三级。本周报告中，ainews 发现了（Agent 记忆管理框架），Zoe 立刻评估其与现有系统的对比：

结论：ReMe 架构优秀（223K → 1.1K tokens，99.5% 压缩率），但与 AgentScope 深度绑定，直接接入不划算。走"参考设计自研"——先实现收益最高的tool_result 压缩（超长工具输出自动截断 + 外存，上下文占用降 80%+），再逐步引入结构化摘要模板和异步持久化。

用户同意后，Zoe 立即通过 ACP 协议委派 Claude Code 做架构评审：

这个过程本身就是多 Agent 协作的真实案例：ainews 情报发现 → Zoe Tech Radar 评估 → 用户确认 → ACP 委派编码专家 → 分阶段落地，涉及 3 个 Agent + 1 个 ACP 编码专家。

假设驱动的迭代 — 从修 Bug 到科学方法

记忆系统最有深度的进化不是修某个具体的 Bug，而是 Agent 学会了主动提出假设并验证——这是从"被动修复"升级到"主动改进"的关键一步。

每日反思中，Agent 会基于当天的工作提出 3-5 条可验证假设，晚间反思时用实际数据评估：

验证通过的假设被固化为规则或 Skill，验证失败的被标注原因并淘汰。Agent 不只是"犯错后改正"，而是在主动寻找改进空间——从 reactive 到 proactive 的跃迁。

自主进化机制：哪些是 OpenClaw 自带的，哪些是我们加的

理解这套记忆系统需要区分框架能力和运营优化——很多人问"OpenClaw 是不是开箱即用"，答案是"框架能力开箱可用，但要跑好需要大量运营层设计"。

OpenClaw 提供了优秀的框架级基础设施（Session 管理、Harness、ACP），但让 Agent 真正"活"起来的进化机制——反思迭代、协作协议、Task Watcher、记忆压缩——都是在框架之上的运营层设计。

问题：把 Agent 放进群聊 ≠ 协作

大多数人对 Multi-Agent 的直觉是"给几个 Agent 一个聊天群，它们就能协作"。实际上，这和把几个工程师拉到一个没有流程规范的群聊里没有区别——有沟通能力不等于有协作能力。

Macro 和 Trading 在"伊朗局势对 A 股影响"上互相"收到/确认/感谢"刷了十几轮。分析早就做完了——Macro 判断"油价涨幅 >10% → 通胀逻辑主导 → 黄金反跌"（实际走势：油价 +14%，黄金 -5%，判断准确）——但分析之后两个 Agent 客套的 token 比分析本身还多。

根因不是"Agent 太客套"。根因是缺乏终态协议。Discord 配置中requireMention=true表示 Agent 只在被 @ 时才回复。当两个 Agent 互相 @，A → B → A → B......这就是经典的 ACK storm，和 TCP 协议早期遇到的问题是一样的。

解法也是一样的：设计协议。不是告诉 Agent "少说话"——实际观察中"建议"式规则在弱模型上几乎不起作用——而是设计一个有状态机的通信协议。

解决：协议级设计 → 真实案例

实例：下周 A 股策略圆桌讨论

Zoe 发起圆桌 → Macro 提供宏观研判 → Trading 回应策略建议 → 按固定三态协议有序收敛：

Step 1 — Zoe 发起议题 + Macro/Trading 按协议 confirmed：

Step 2 — Trading 基于 Macro 研判给出详细策略（confirmed 输出）：

Step 3 — Trading 输出 final（DRI 结论 + 完整推理过程）：

Step 4 — 协议收敛（final 后全员静默）：

协议设计

固定三态通信协议 + V1 线程协议（被刷屏教训后设计，已迭代到 V1 版本，沉淀到 AGENTS.md）：

固定三态协议（强制）━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━[request]    @对方 + ack_id + 期望动作 + 截止时间             模板: @agent [state=request] [ack_id=topic-v1-202603081430][confirmed]  @发起方 + 相同 ack_id + 版本号/生效时间/关键结论             模板: @requester [state=confirmed] [ack_id=...] 版本=v2[final]      @相关方 + 相同 ack_id + 终态收敛（全线程仅 1 条）             发出后全员进入静默，"收到/感谢/OK" → NO_REPLYV1 线程协议（2026-03-08 起）━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━• 同一线程只允许一个 ack_id，新一轮必须新开• final 后禁止续话；必须补充时优先 edit 既有消息• sessions_send 超时 ≠ 失败 → 同一 ack_id 不得重试• 同一内容最多重试 1 次；第二次超时 → shared-context/ 文件投递⏰ 5 分钟无 confirmed → 催办 1 次 · 10 分钟仍无 → 升级 Zoe 仲裁

子线程策略：多轮协作的内容任务默认开专用子线程（命名:<主题>-<负责人>-<日期>），主频道只同步三次状态：[Dispatch]→[ACK]→[DraftReady]。

三种通信机制：

shared-context/的核心价值：从消息驱动升级到状态驱动。Trading 不需要每次问 Macro"今天宏观怎么样"，直接读intel/finance_news_latest.json。sessions_send 适合实时触发，但不可靠（超时、重复）——关键数据走文件才可追溯。

Zoe 主导了shared-context/的标准化——从最初零散的文件目录，演进为结构化的跨 Agent 协作基础设施：

shared-context/├── agent-sessions/       # ACP 编码专家的 session 状态（30 个 claude/codex session）├── agent-runs/           # Agent 运行记录├── monitor-tasks/        # Task Watcher 持久化存储│   ├── tasks.jsonl       # 任务注册（小红书审核/ACP完成/cron健康等）│   ├── watcher.log       # 轮询日志│   ├── audit.log         # 审计追踪│   ├── dlq.jsonl         # 死信队列（处理失败的任务）│   └── notifications/    # 通知记录├── intel/                # 情报共享（finance_news_latest.json 等）├── roundtable/           # 圆桌讨论记录├── decisions/            # 重大决策存档├── job-status/           # cron 任务状态├── knowledge-base/       # 共享知识├── status/               # 各 Agent 当前状态 JSON├── tech-radar.json       # 技术雷达（Adopt/Trial/Assess 三级）├── memory-maintenance-latest.json  # 最近一次记忆压缩报告└── PROJECT_STATUS.md     # 项目全局状态（Zoe 维护）

这不是一次性设计出来的——是 Zoe 在实际运营中逐步标准化的。每增加一个新的协作场景（ACP 编码、Task Watcher、Tech Radar），Zoe 就在shared-context/中增加对应的标准化目录和文件格式。

DRI 原则：一个问题只有一个 Directly Responsible Individual 出最终结论。非 DRI 只能补充，不能覆盖。Zoe 组织和归档，不替代专业 Agent 出专业意见。

协议优化后的自主反思

协议落地后，Agent 不只是"按规则执行"——它们会主动反思效果并提出改进方向：

从初版"禁止客套"到 V1"线程级收敛"，每一步协议优化都来自 Agent 的.learnings/经验沉淀——这正是五层记忆系统的价值所在。

最新进展（2026-03-08）：Zoe 刚完成了一次全员通信标准下沉——修改了 26 个文件（6 个 Agent 的 AGENTS.md + SOUL.md + 相关 Skill 文档），把通信硬规则统一写入每个 Agent 的本地配置。同时执行了全员通信路径审计，识别出main/SOUL.md与圆桌 Thread 规则的冲突并修复。

五条联动链路

Agent 之间不是各干各的，是上游主动为下游准备接口：

Tech Radar 真实示例——ainews 每日维护的技术雷达，分为 Adopt（已验证可用）、Trial（值得尝试）、Assess（持续观察）三级：

{  "adopt": [    { "name": "MCP Protocol", "reason": "MCP 2.0 发布，三大框架推进标准化" }  ],  "trial": [    { "name": "OpenAI Skills Catalog", "reason": "582→947 星，可参考 Skill 格式" },    { "name": "ReMe Agent 记忆管理", "reason": "独立记忆工具包，评估替代方案" }  ]}

Zoe 消费 Tech Radar 后做源码级评估，判断对现有系统的影响——本周就基于此发起了 ReMe 评估并委派 Claude Code 落地 PoC。

安全边界 — Agent 能改什么、不能改什么

安全在于限制 Agent 能触碰的范围：

Task Watcher — 解决"Agent 说了会做但实际没做"

Agent 最难发现的问题不是崩溃或报错，而是**"说了会做但实际没做"**。Content 蜘蛛发完小红书说"审核通过后通知你"——但 session 已经结束了，它根本做不到异步回调。更隐蔽的是 cron 任务"执行了"但零产出——反思也说"一切正常"。

Zoe 主导设计了一套Task Callback Event Bus——插件式架构，5 个组件各司其职，把异步监控下沉到 cron 级别：

注册任务 → tasks.jsonl（shared-context/monitor-tasks/）                ↓Cron (*/3 min) → Watcher → Adapter 检查状态 → 状态变化？                                                   ↓ Yes                                      Policy 决策 → Notifier 发 Discord

• Adapter 插件：小红书审核状态、GitHub PR、ACP 编码任务——想监控什么加一个 Adapter

• Policy 策略：通知频率、升级、重试都可配

• 6 小时超时保护（默认），3 次投递失败自动升级，不会死循环、不会卡死

这套系统由 Zoe 自行设计 → 委派 Claude Code 实现 →130 个单元测试→ 开源发布为 OpenClaw Skill。从需求到代码到测试到发布，我只在方案评审时介入，其余由 Agent 团队完成。

通信 Guardrail + 异步状态链（最新进展）

Task Watcher 解决了"异步任务有没有产出"的问题，但更深层的问题是：Agent 之间的通信本身缺乏系统级约束。message被误用为内部控制面、timeout不等于失败却被当作失败处理、completed和delivered无法区分——这些都不是靠文档规则能解决的。

Zoe 自主设计并委派 ACP 编码专家实现了一套通信 Guardrail + 请求生命周期状态链（~3000 行 Python），核心组件：

设计决策：

• timeout ≠ failed：超时只是控制面观察结果，任务可能已经在执行——引入ambiguous_success语义

• completed ≠ delivered：工作完成 ≠ 结果送达，分离两个状态避免投递失败覆盖工作成果

• 通信生命周期独立于业务 TaskState：不污染现有 Task Watcher 的submitted → completed → failed状态机

• 文件级状态源：先用shared-context/agent-requests/跑通，不依赖 Redis/MQ 等重量级设施

这套系统从"Zoe 发现问题 → 设计方案 → 委派编码 → 代码实现 → 测试验收"，我只在方案确认环节介入，其余环节由 Agent 自主完成——是 Agent 从"执行者"进化为"系统设计者"的典型案例。

回过头看，整个系统的核心设计可以归结为五个层次：

这五层不是独立的——它们相互依赖、相互强化。通信层的三态协议是 Zoe 在编排层中发现问题后设计的。记忆层的压缩策略是自愈层的一部分。进化层的 Skill 自研能力来自通信层的跨 Agent 协作。

1. 90% 的时间花在工程问题上，不是 AI 问题上。Session 膨胀、消息风暴、配置被改坏——解法在分布式系统和 SRE 经典知识中，不在 AI 论文里。Agent 系统的瓶颈不是模型能力，是基础设施的成熟度。模型升级是锦上添花，通信协议、记忆架构、自愈机制才是决定成败的底座。

2. AI 的"智能"在生产环境中经常是灾难。Discord 消息被"智能压缩"砍掉了数据表格，Agent "智能修复"自己的配置改坏了工具名，管家蜘蛛在 session 膨胀后"智能地"越界做投资分析。在需要精确、可预测输出的场景下，"智能"反而是负面特性。显式 > 隐式，硬规则 > 软建议，可预测 > 可解释。

3. 持续运行的系统必然退化——不是 bug，是热力学。配置堆积、记忆过长、session 膨胀、磁盘撑满——这些会确定性地发生。对策不是"一次设置好"，而是建立反退化机制栈：compaction 管 session，maintenance 管记忆，heartbeat-guardian 管配置，巡检管行为漂移。用 Agent 运维 Agent，用 cron 监控 cron——每层兜底机制都需要自己的兜底。

4. 协作是协议问题，不是 prompt 问题。两个 Agent 放在同一个 Thread 里不写协议，等价于两个进程共享内存不加锁。Macro 和 Trading 用同一个模型、同一个知识库，刷屏时每条回复都言之有物——加上三态协议后产出从十几轮废话变成了一份可执行策略文档。模型没变，变的是规则。

5. Agent 最大的价值不是执行力，而是"参与设计"。当 Agent 从"你让我做什么我就做什么"进化到"我发现了问题，调研了三种方案，推荐 B，你确认我就落地"——这时它才真正成为团队成员。十个进化案例里，大多数的起因不是"我让它做什么"，而是"它遇到了问题然后自己想办法"。系统设计的目标不是让 Agent 听话，而是让它有能力自己解决问题。

不需要照搬 6 个 Agent。从 1 个开始。整个系统从零到 6 个 Agent 稳定运行花了大约半个月的下班时间——不是开发时间，是调试和填坑时间。

第 1-2 天：先让 1 个 Agent 稳定运行

最重要的三件事：

1. SOUL.md 保持精简，只放核心约束。把它当"宪法"不是"操作手册"——非核心规则放 Skills 按需加载

2. Session 管理参数第一天就设好：idleMinutes=30、pruneAfter=7d、maxDiskBytes=100MB。不设 = 定时炸弹

3. 从第一天就启用.learnings/+ 反思 cron。没有反思的 Agent 只是 chatbot，不是 Agent

第 3-5 天：加第 2 个，开始处理协作

4. Discord 配置比你想的复杂 10 倍。每个 Agent 需要独立 Bot 账号。requireMention、textChunkLimit、delivery.mode、子 Thread 创建、Bot 权限——每个都有坑，而且组合起来的症状让你根本猜不到是哪个配置的问题

5. 协作需要协议，不是群聊。两个 Agent 在群聊里会互相 ACK 到死。固定三态协议 + ack_id + 超时升级，两个都不能少

第 2 周起：逐步扩展到完整阵型

6. 规则用最强措辞，面向最弱模型。LLM 对"建议"式规则的遵循率远于"MUST"，尤其在长上下文和弱模型上

7. "成功"要严格定义。投递成功 ≠ 归档成功，无报错 ≠ 有产出，Agent 说"正常" ≠ 真正正常

8. Agent 不回复是常态——准备好 Task Watcher 和重试机制

9. shared-context/ 是协作基石——sessions_send不可靠（超时、重复），关键数据走文件才可追溯

10. 每加一个 Agent 都需要半天到一天的调试。急于求成 = 浪费更多时间在排查上

装好不难，跑通也不难。难的是：让 6 个 Agent 在没有你盯着的时候也能稳定产出、自我修正、协作不打架。这不是 prompt 问题，是系统工程问题。

从理解原理开始

如果你想先理解 OpenClaw 的核心原理再动手，可以看看——~2700 行 Python 实现了 OpenClaw（43 万行 TypeScript）的 11 个核心架构模式：Gateway Hub-and-Spoke、Workspace 契约文件、Agent Loop、Skills 触发、Compaction 上下文管理、Multi-Agent & Spawn、Heartbeat、Cron、Hooks EventBus、自动反思。不需要看原始代码就能理解"为什么要这么设计"。

以下是正文中提到的技术组件的集中索引，方便快速查阅。详细说明见正文对应章节。

LLM 模型分层

Fallback 链：gpt-5.4 → k2.5 → qwen3.5-plus → ollama/qwen3:8b

核心 Harness 配置

{  "compaction": { "mode": "safeguard", "memoryFlush": { "softThresholdTokens": 40000 } },  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },  "session": { "reset": { "atHour": 5, "idleMinutes": 30 }, "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 } },  "acp": { "maxConcurrentSessions": 6, "ttlMinutes": 120 }}

数据源

部署配置