OpenClaw + 6 个 Agent 运转半个月，从聊天到干活的完整工程实践
编译摘要
1. 浓缩
- 核心结论1: 多 Agent 系统能持续运转，关键不在“多放几个 Agent”，而在 context、memory、protocol、harness 和 operations 五层工程。
- 关键证据: 文章展示 1 个 orchestrator、5 个专业 Agent、6 类 ACP 编码专家、52 个 cron、118 个 Skills、29 个 LLM 模型、2086 行运维脚本和半个月 23 次自动恢复；大量篇幅都在讲 session 膨胀、通信风暴、记忆压缩、自愈和权限边界。
- 核心结论2: Context Engineering 是持续运行 Agent 的操作系统；不管理上下文，系统会确定性退化。
- 关键证据: 三个事故非常具体：ainews session 膨胀到 235K tokens 导致 gateway crash 和全团队 8 小时离线；长报告被 content compaction 压缩掉数据表；SOUL.md 和 session 噪声过多导致关键规则失效。
- 核心结论3: Agent 记忆需要分层和晋升机制，而不是无限保存对话。
- 关键证据: 文章提出 L1 SOUL.md、L2 MEMORY.md、L3 memory flush、L4 .learnings、L5 Skills/Obsidian/ontology/vector store，并用“≥3 次才 promote”防止偶发事件污染长期记忆。
- 核心结论4: 多 Agent 协作是协议问题，不是群聊问题。
- 关键证据: Macro 和 Trading 曾互相“收到/确认”刷屏十几轮；Zoe 设计 request → confirmed → final → 静默的三态协议，加 ack_id、超时升级和线程规则，才把交流从 ACK storm 变成可收敛协作。
- 核心结论5: Agent 的最高价值不只是执行，而是参与系统设计和自我改进。
- 关键证据: Zoe 自主设计 Task Watcher、通信 Guardrail、请求生命周期状态链，调研 ReMe 并委派 ACP 编码专家落地；这些都是“发现问题 → 设计方案 → 用户确认 → 委派实现”的闭环。
2. 质疑
- 关于证据来源的质疑: 这是强实践叙述，但缺少可复现实验仓库、完整日志和失败率统计。应把它作为高密度案例，而不是直接当成通用最佳实践。
- 关于安全边界的质疑: 文中承认 Agent 曾改坏配置、把人格约束改松、越界做投资分析。这说明 autonomous self-improvement 必须有不可修改的宪法层、allowlist、密钥隔离和审计链。
- 关于复杂度的质疑: 52 个 cron、118 个 Skills、29 个模型和多层记忆会创造新的运维负担。小团队复制时应从 1 个 Agent 起步，而不是照搬完整阵型。
- 关于金融/投资 Agent 的质疑: Trading 和 Macro 涉及市场建议，原文强调止损位、置信度和不编造数据，但真实金融风险、合规要求和责任归属仍需单独治理。
3. 对标
- 对标分布式系统: ACK storm、shared-context 状态共享、dead letter queue、request lifecycle、cron health check 都说明多 Agent 系统更像分布式系统，而不是聊天机器人集合。
- 对标 SRE: 持续运行的 Agent 会出现 session 膨胀、磁盘膨胀、状态漂移和任务假成功；需要 heartbeat、watcher、compaction、maintenance、DLQ 和巡检。
- 对标组织设计: Zoe 是 CTO/编排者，专业 Agent 是职能团队，ACP 编码专家是外包执行池。真正有效的是明确 DRI、职责边界、通信协议和共享状态。
- 对标 LLM Wiki: 五层记忆里 Obsidian/Vault 只是冷存储之一；这提醒本库，Wiki 层要和运行时 memory、Skills、protocol 区分，不能把所有知识都塞进一个上下文。
关联概念