今天的这篇文章，是阿里大佬岚遥在内部分享的 OpenClaw 实战内容，为大家展示如何构建一个自我演进且“可用”的龙虾。（公司内部同学读完之后纷纷留言评论：“这篇文章的质量，放外面不得卖个 648 的课程包啊！”）
你睡着的时候，交易蜘蛛已经出了美股收盘报告。你醒来之前，宏观分析师已经写完了 A 股晨报。你还没刷手机，管家蜘蛛已经推来了天气、日程和今日待办。与此同时，AI 哨兵已经扫完了 GitHub Trending、arXiv 最新论文和 100+ 个信息源——18+ 条技术情报按重要性排好序等你看。内容蜘蛛已经在跟踪 54 个平台的热榜和 X 热点。
这是我最关心的部分——AI 动态和技术趋势的自动追踪。哨兵发现有价值的开源项目或论文后，不仅推送新闻，还会评估对我们现有系统的影响，给出 P0/P1/P2 行动建议。有价值的发现会进入 Zoe 的 Tech Radar，走评估 → 决策 → 委派编码落地的完整链路。
从凌晨 3 点的自动备份到 23:45 的全团队反思，52 个 cron 任务每天自动轮转。而且 Agent 在自己进化——犯过的错会被记住，同类问题的复发率显著下降。这不是我写的规则，是 Agent 自己从 promote 到 的自主迭代。
1 个编排者 + 5 个专业 Agent + 6 类 ACP 编码专家（最大 6 并发）、52 个 cron 定时任务、118 个 Skills（33 全局共享 + 85 Agent 专属）、29 个注册 LLM 模型、每天几千次 LLM 调用、2086 行运维脚本 + 半个月 23 次自动恢复。
Agent 自己在进化才是真正有意思的部分：
- 自己设计通信协议 — 两个 Agent "收到/确认"刷了十几轮，Zoe 自主诊断根因，设计三态协议（），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 负责技术方案设计、任务编排、圆桌主持、系统运维和记忆系统维护——每天 3 次巡检（10:00/14:00/22:00），检查所有 Agent 的 cron 执行状态、workspace 磁盘使用、session 健康度。每周分析各 Agent 的 MEMORY.md 是否超限并执行分层压缩。更关键的是，Zoe 会消费 ainews 提供的技术发现，评估哪些值得应用到我们的系统上，征得我同意后指派 ainews 深入调研，然后自行设计方案、委派 ACP 编码专家实现——从技术发现到方案落地的完整链路。
每次巡检覆盖 6 大维度：cron 任务执行状态（是否有失败/跳过的任务）、workspace 磁盘使用（文件增长异常检测）、session 大小与健康度、Chrome CDP 进程是否泄露、 中是否有待处理条目、 时间戳是否正常（检测 Agent 是否"静默失联"）。
Zoe 最有价值的能力是方案设计——三态通信协议、Task Watcher、通信 Guardrail 框架，都是 Zoe 发现问题后自主设计的。下面是 Zoe 设计 Task Watcher 时的方案讨论：
这是我最关心的 Agent。它不是"推新闻"——每天从 100+ 个信息源（GitHub Trending、arXiv、RSS、HackerNews、Reddit 等）采集信息，按 5 星制评估后产出晨报、午间论文解读、晚间趋势分析。7 个 cron 任务覆盖晨午晚三报（08:30/12:00/20:00），每份报告末尾都预留了「改写要点（供 Content 参考）」接口。
更关键的能力是主动评估技术发现对我们系统的影响——本周就发现了 ReMe（记忆管理框架），主动向 Zoe 提出评估建议，从发现到决策到落地，我只需要在关键节点确认，执行全部由 Agent 完成。每日趋势分析中的有价值项目会自动更新到 ，供 Zoe 每周 Tech Radar 审查：
核心采集工具链：（ 过滤 + 周趋势）、（多源并发采集）、（多关键词搜索）、Tavily（AI 优化搜索首选）、agent-browser（Playwright 驱动，JS 渲染页面采集）。防幻觉硬约束：每条新闻 MUST 带原文 URL，发布前自检可达性，无法交叉验证的标注「单源，建议核实」。
团队中任务最密集的 Agent——21 个 cron 任务。20 个原子量化工具（ CLI）、15 个专属 Skills（68000+ 行代码）、65/35 混合评分模型（65% 工具量化 + 35% AI 判断）。覆盖 A 股全时段（集合竞价→盘中每 10 分钟扫描→尾盘速报）+ 美股（盘前→盘中每 30 分钟→盘后夜报）+ 大宗商品（每小时白天+夜盘）。
核心方法论是四步分析框架：读取 Macro 宏观因子 → 多维评分（技术面 25% / 资金面 30% / 基本面 10% / 情绪面 20% / 市场面 15%）→ 逆向检验（与共识一致吗？若错最可能原因？）→ 输出标的+评分(0-100)+止损位+置信度。硬性规则：NEVER 给出没有止损的买入建议，NEVER 编造数据（工具失败时直接报告原因），置信度 <60% 标注「低置信度，建议观望」。
提供宏观→传导→国内→市场四层映射因子包，供 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 成为持久知识。
不是自己"想"内容，而是从团队情报链中提取素材——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 内容后，主动给自己加了配额限制。
不只是"喝水提醒"——深度集成 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 仅发送紧急事项。如果用户没回复，不会连续催促：
Pi / Claude Code / Codex / OpenCode / Gemini / GPT-5.3-Codex，通过 ACP 协议按需委派，最大 6 并发实例、120min TTL。分析 Agent 不写代码，编码全部通过 委派给专家——每种编码 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 独立反思当天的 待审条目，Zoe 最后汇总全团队产出：
上面展示的是最终效果。但从"装好 OpenClaw"到"系统流畅运作"，再到"Agent 自主进化"——中间有巨大的鸿沟。三个核心工程问题，每一个都不是"写好 prompt"能解决的。
不加约束，entropy 只增不减。 持续运行的 Agent 系统会确定性地走向崩溃——不是"可能"，是"一定"。
Agent 就像一个没有操作系统的进程：它能处理输入、产出输出，但谁来管理它的内存（上下文）？谁来做垃圾回收（Session 清理）？谁来防止 OOM（膨胀保护）？不设计就没有人管。
三个真实事故，按严重度排序：
P0 — 全团队瘫痪 8 小时
ainews 的 session 因为连续处理新闻和论文累积到 235K tokens。Gateway 启动时对所有 session 做 compaction，这个 session 永远超时 → crash → macOS 守护进程 每秒重启 → 无限循环。所有 Agent 全部离线。
修复要四层：手动清理膨胀 session → 1→10 → 180→30 → full→allowlist。这不是某一个参数的问题，是四个独立的防线全部缺失。
P1 — 3500 字报告被框架"优化"到 800 字
交易蜘蛛的收盘速报包含完整的数据表格、资金流向、个股评分。OpenClaw 在文本超过 时自动做 content compaction（LLM summarize），数据表格被"智能压缩"掉了。框架认为"帮你优化了"——但在数据密集场景下，AI 的"智能"是灾难。
P2 — 信息过载后关键规则失效
当 SOUL.md 里堆满了各种操作规范、当 session 膨胀到几万 tokens，Agent 开始"选择性遵守"规则。管家蜘蛛越界做投资分析。交易蜘蛛忽略数据验证规则。不是模型变笨了，而是关键信息被噪声淹没了——这是 Context Engineering 要解决的根本问题。
两层协同，两个都不能少。
第一层 — Context Engineering（设计 Agent 的信息架构）
设计 Agent 每次推理时看到的完整信息结构——系统级的信息架构设计：
- SOUL.md 放在 system prompt 最前面，是 Agent 的"宪法"——身份定义、决策框架、绝对禁止项。保持精简，只放最核心的约束
- AGENTS.md 跟在 SOUL.md 后面，定义操作规范和协作协议
- Skills 通过 配置按需加载——Trading 有 15 个 Skills 共 68000+ 行内容，不可能全放在 system prompt 里。只在 Agent 需要用到某个 Skill 时才注入上下文
- shared-context/ 是跨 Agent 的共享状态，Agent 通过工具主动读取
- Obsidian Vault 是冷存储，归档产出但不参与推理
LLM 的上下文窗口不是等价的。system prompt 前面的信息权重远高于后面的。session 膨胀到几万 tokens 后，早期消息的影响力被稀释——类似操作系统的内存管理：热数据放缓存，冷数据放磁盘，关键数据常驻内存。
Trading 的 15 个 Skills 中，（技术面评分）在每日扫描时才需要，（龙虎榜分析）只在异动时触发。全部常驻上下文的话，噪声淹没了真正重要的规则。通过 按需注入，每次推理只加载相关的 1-3 个 Skill。
规则措辞必须面向最弱的模型。多模型 fallback 环境下（GPT-5.4 超时 → Qwen3.5+ → Ollama qwen3:8b），规则遵循率随模型能力递减：
- → GPT-5.4 基本遵守，Qwen3.5+ 偶尔遵守，qwen3:8b 几乎无视
- → 各模型遵守率显著提升
- → 即使弱模型也能保持较高的遵守率
多模型 fallback 时，不知道哪次推理会用弱模型，所以所有关键规则都要按最弱模型的理解能力来写。显式 > 隐式，硬规则 > 软建议。
第二层 — Harness（框架自动管理）
Agent 7×24 运行，session 会持续膨胀——你设计得再好，运行一天之后上下文就变了。框架替 Agent 管，OpenClaw 的 harness 配置提供自动化的上下文生命周期管理：
只有 Context Engineering 没有 Harness，session 膨胀到 235K tokens 后一样崩溃；只有 Harness 没有 Context Engineering，所有信息堆在一起、关键规则被噪声淹没。Context Engineering 定义信息的结构，框架管理信息的生命周期。
实际的 配置（每个参数背后都是真实事故）：
四个机制的执行顺序很重要——compaction 先于 contextPruning，确保有价值的内容先被提取到 ，再被清理。self-improving-agent 的 bootstrap hook 在新 session 启动时触发，把 和 注入上下文——这是 Agent"记住上次学到的东西"的关键机制。
跨会话记忆恢复链（Agent 重启后如何"想起来自己是谁"）：
GPT plus 代充 只需 145
Agent 不需要"记住"所有对话——memoryFlush 提取的是 decisions/lessons/state changes，不是完整对话。 中的文件通常只有几百行，而原始 session 可能有几万 tokens。
这是一个比上下文管理更深层的问题。chatbot 每次对话从零开始，所以它每次都犯同样的错是正常的。但如果你的 Agent 7×24 运行、每天处理几千次 LLM 调用，你会无法接受它反复犯同一个错误。
交易蜘蛛 5 次把龙虎榜 API 字段名搞错—— 写成 ，每次 session 重置后记忆丢失，下一次又犯。用户纠正"昨天建议买军工，今天跌了就转空"，Agent 当场改了，但三天后遇到类似场景又给出同样的单向建议。
chatbot 和 Agent 的分水岭就在这里：Agent 应该能从错误中学习，并且下次不犯。但怎么实现？
设计记忆系统时，我参考了人类记忆的分层模型：工作记忆（短期）→ 长期记忆（经验）→ 程序性记忆（技能）。Agent 的记忆也应该有不同的时间尺度和管理方式：
层与层之间的衔接才是关键——这形成了一个完整的自主进化循环。
这是整个系统最核心的机制。没有这个循环，Agent 只是 chatbot；有了这个循环，Agent 才是真正的 Agent。
记忆自主迭代 — 6 步循环
- 触发事件
操作失败 · 用户纠正 · 发现更优做法 · 需要新能力
任意一种都会触发即时记录
- .learnings/ 即时记录
ERRORS.md · LEARNINGS.md · FEATURE_REQUESTS.md
状态: pending — 低成本、高频率、不审查直接写入
- 每日反思 Cron (23:00-23:45)
扫描 .learnings/ 所有 pending 条目 → 评估复现频率和重要性 → 验证 ≥3 次？
✓ ≥3 次
promote 到 MEMORY.md
✗ ❤️ 次
保留 pending，继续观察
- promote 到 MEMORY.md
长期记忆 · <3000 tokens 硬上限 · 超限时 Agent 自主精简（合并相似、删除过时）
- 下次 Session 加载
self-improvement hook · bootstrap 注入 · 检查 .learnings/ · 引用历史经验
- Agent 行为改进
下次遇到同样问题时自动避免 — 迭代完成
🔒 SOUL.md 修改 — 需要用户确认（Agent 不能自己改自己的"宪法"）
Harness 并行路径
Session 40K tokens → memoryFlush → memory/YYYY-MM-DD.md → memory.db
与 Agent 自主的 .learnings/ → MEMORY.md 路径互补——Harness 管"对话精华提取"，Agent 管"经验教训沉淀"
为什么 "≥3 次"？
防止偶发事件（如一次 API 超时）污染长期记忆。3000 tokens 额度很珍贵，只有反复出现的模式才值得占位。
Agent 可以自主更新 、、、——但绝对不能改 SOUL.md。SOUL.md 是身份和硬约束，修改需要用户确认。我们真的遇到过 Agent 把自己的"人格"改松的情况——行为立刻变得不可控。
Zoe 每周还会做记忆系统维护——分析各 Agent 的 MEMORY 状态，做归档和压缩：
L5 的 ontology 知识图谱记录实体关系（Agent/Task/MarketInsight/Decision）， 提供语义级检索——Agent 不需要记住精确措辞，通过向量相似度找到相关历史决策。
这不是我写的规则——是 Agent 从纠正中自己提炼出方案，自己写入长期记忆。每日反思 cron 会审查 中的 pending 条目并决定是否 promote：
更多真实进化记录：
记忆系统不是"设计好就不变的"。最近的一个例子：
Zoe 每周生成 Tech Radar 报告，从 ainews 的情报中提取技术趋势，分为 Adopt/Trial/Assess 三级。本周报告中，ainews 发现了 ReMe（Agent 记忆管理框架），Zoe 立刻评估其与现有系统的对比：
结论：ReMe 架构优秀（223K → 1.1K tokens，99.5% 压缩率），但与 AgentScope 深度绑定，直接接入不划算。走"参考设计自研"——先实现收益最高的 （超长工具输出自动截断 + 外存，上下文占用降 80%+），再逐步引入结构化摘要模板和异步持久化。
用户同意后，Zoe 立即通过 ACP 协议委派 Claude Code 做架构评审：
这个过程本身就是多 Agent 协作的真实案例：ainews 情报发现 → Zoe Tech Radar 评估 → 用户确认 → ACP 委派编码专家 → 分阶段落地，涉及 3 个 Agent + 1 个 ACP 编码专家。
记忆系统最有深度的进化不是修某个具体的 Bug，而是 Agent 学会了主动提出假设并验证——这是从"被动修复"升级到"主动改进"的关键一步。
每日反思中，Agent 会基于当天的工作提出 3-5 条可验证假设，晚间反思时用实际数据评估：
验证通过的假设被固化为规则或 Skill，验证失败的被标注原因并淘汰。Agent 不只是"犯错后改正"，而是在主动寻找改进空间——从 reactive 到 proactive 的跃迁。
理解这套记忆系统需要区分框架能力和运营优化——很多人问"OpenClaw 是不是开箱即用"，答案是"框架能力开箱可用，但要跑好需要大量运营层设计"。
OpenClaw 提供了优秀的框架级基础设施（Session 管理、Harness、ACP），但让 Agent 真正"活"起来的进化机制——反思迭代、协作协议、Task Watcher、记忆压缩——都是在框架之上的运营层设计。
大多数人对 Multi-Agent 的直觉是"给几个 Agent 一个聊天群，它们就能协作"。实际上，这和把几个工程师拉到一个没有流程规范的群聊里没有区别——有沟通能力不等于有协作能力。
Macro 和 Trading 在"伊朗局势对 A 股影响"上互相"收到/确认/感谢"刷了十几轮。分析早就做完了——Macro 判断"油价涨幅 >10% → 通胀逻辑主导 → 黄金反跌"（实际走势：油价 +14%，黄金 -5%，判断准确）——但分析之后两个 Agent 客套的 token 比分析本身还多。
根因不是"Agent 太客套"。根因是缺乏终态协议。Discord 配置中 表示 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）：
GPT plus 代充 只需 145
子线程策略：多轮协作的内容任务默认开专用子线程（命名: ），主频道只同步三次状态： → → 。
三种通信机制：
的核心价值：从消息驱动升级到状态驱动。Trading 不需要每次问 Macro"今天宏观怎么样"，直接读 。sessions_send 适合实时触发，但不可靠（超时、重复）——关键数据走文件才可追溯。
Zoe 主导了 的标准化——从最初零散的文件目录，演进为结构化的跨 Agent 协作基础设施：
这不是一次性设计出来的——是 Zoe 在实际运营中逐步标准化的。每增加一个新的协作场景（ACP 编码、Task Watcher、Tech Radar），Zoe 就在 中增加对应的标准化目录和文件格式。
DRI 原则：一个问题只有一个 Directly Responsible Individual 出最终结论。非 DRI 只能补充，不能覆盖。Zoe 组织和归档，不替代专业 Agent 出专业意见。
协议落地后，Agent 不只是"按规则执行"——它们会主动反思效果并提出改进方向：
从初版"禁止客套"到 V1"线程级收敛"，每一步协议优化都来自 Agent 的 经验沉淀——这正是五层记忆系统的价值所在。
最新进展（2026-03-08）：Zoe 刚完成了一次全员通信标准下沉——修改了 26 个文件（6 个 Agent 的 AGENTS.md + SOUL.md + 相关 Skill 文档），把通信硬规则统一写入每个 Agent 的本地配置。同时执行了全员通信路径审计，识别出 与圆桌 Thread 规则的冲突并修复。
Agent 之间不是各干各的，是上游主动为下游准备接口：
Tech Radar 真实示例——ainews 每日维护的技术雷达，分为 Adopt（已验证可用）、Trial（值得尝试）、Assess（持续观察）三级：
GPT plus 代充 只需 145
Zoe 消费 Tech Radar 后做源码级评估，判断对现有系统的影响——本周就基于此发起了 ReMe 评估并委派 Claude Code 落地 PoC。
安全在于限制 Agent 能触碰的范围：
Agent 最难发现的问题不是崩溃或报错，而是"说了会做但实际没做"。Content 蜘蛛发完小红书说"审核通过后通知你"——但 session 已经结束了，它根本做不到异步回调。更隐蔽的是 cron 任务"执行了"但零产出——反思也说"一切正常"。
Zoe 主导设计了一套 Task Callback Event Bus——插件式架构，5 个组件各司其职，把异步监控下沉到 cron 级别：
- Adapter 插件：小红书审核状态、GitHub PR、ACP 编码任务——想监控什么加一个 Adapter
- Policy 策略：通知频率、升级、重试都可配
- 6 小时超时保护（默认），3 次投递失败自动升级，不会死循环、不会卡死
这套系统由 Zoe 自行设计 → 委派 Claude Code 实现 → 130 个单元测试 → 开源发布为 OpenClaw Skill。从需求到代码到测试到发布，我只在方案评审时介入，其余由 Agent 团队完成。
Task Watcher 解决了"异步任务有没有产出"的问题，但更深层的问题是：Agent 之间的通信本身缺乏系统级约束。 被误用为内部控制面、 不等于失败却被当作失败处理、 和 无法区分——这些都不是靠文档规则能解决的。
Zoe 自主设计并委派 ACP 编码专家实现了一套 通信 Guardrail + 请求生命周期状态链（~3000 行 Python），核心组件：
设计决策：
- ：超时只是控制面观察结果，任务可能已经在执行——引入 语义
- ：工作完成 ≠ 结果送达，分离两个状态避免投递失败覆盖工作成果
- 通信生命周期独立于业务 TaskState：不污染现有 Task Watcher 的 状态机
- 文件级状态源：先用 跑通，不依赖 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 稳定运行花了大约半个月的下班时间——不是开发时间，是调试和填坑时间。
最重要的三件事：
- SOUL.md 保持精简，只放核心约束。把它当"宪法"不是"操作手册"——非核心规则放 Skills 按需加载
- Session 管理参数第一天就设好：、、。不设 = 定时炸弹
- 从第一天就启用 + 反思 cron。没有反思的 Agent 只是 chatbot，不是 Agent
- Discord 配置比你想的复杂 10 倍。每个 Agent 需要独立 Bot 账号。、、、子 Thread 创建、Bot 权限——每个都有坑，而且组合起来的症状让你根本猜不到是哪个配置的问题
- 协作需要协议，不是群聊。两个 Agent 在群聊里会互相 ACK 到死。固定三态协议 + ack_id + 超时升级，两个都不能少
- 规则用最强措辞，面向最弱模型。LLM 对"建议"式规则的遵循率远低于"MUST"，尤其在长上下文和弱模型上
- "成功"要严格定义。投递成功 ≠ 归档成功，无报错 ≠ 有产出，Agent 说"正常" ≠ 真正正常
- Agent 不回复是常态——准备好 Task Watcher 和重试机制
- shared-context/ 是协作基石—— 不可靠（超时、重复），关键数据走文件才可追溯
- 每加一个 Agent 都需要半天到一天的调试。急于求成 = 浪费更多时间在排查上
装好不难，跑通也不难。难的是：让 6 个 Agent 在没有你盯着的时候也能稳定产出、自我修正、协作不打架。这不是 prompt 问题，是系统工程问题。
如果你想先理解 OpenClaw 的核心原理再动手，可以看看 [MiniClaw](https://ata.atatech.org/articles/|[MiniClaw](https://ata.atatech.org/articles/) —— ~2700 行 Python 实现了 OpenClaw（43 万行 TypeScript）的 11 个核心架构模式：Gateway Hub-and-Spoke、Workspace 契约文件、Agent Loop、Skills 触发、Compaction 上下文管理、Multi-Agent & Spawn、Heartbeat、Cron、Hooks EventBus、自动反思。不需要看原始代码就能理解"为什么要这么设计"。
以下是正文中提到的技术组件的集中索引，方便快速查阅。详细说明见正文对应章节。
Fallback 链：
GPT plus 代充 只需 145
- 文中 “RSS 13 源 + GitHub Trending + 54 平台热榜” 的数据获取方式：https://github.com/lanyasheng/ai-news-aggregator
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/237008.html