大约 3 个月将 OpenClaw 作为我的日常代理系统运行。哪些有效，哪些出错，哪些仍然让我烦恼。

我已经将 OpenClaw 作为我的主要个人代理设置运行了大约 13 周。它运行在 Raspberry Pi 上，通过 Telegram 与我对话，管理记忆、crons、子代理、研究工作流、外部 API、计划任务和一般个人自动化。完全独立于任何职业工作环境。这是一个实用的回顾。简而言之：OpenClaw 功能足够强大，我现在将其视为基础设施。它也仍然足够粗糙，你需要耐心、日志、备份以及调试奇怪边界情况的意愿。 我用它做什么： • Telegram 基于的个人助理 • 长期记忆和每日会话日志 • 计划 cron 代理 • 研究和总结工作流 • 用于分析和编码支持的子代理 • 与 Claude/Codex 的 ACP 会话（当它们工作时） • 偶尔的红队/安全检查 • 提醒、审计、清理和操作笔记 • 协调文件、API 和工具之间的小型自动化任务 哪些效果很好：OpenClaw 非常擅长成为工作流层。最好的部分不是“与 LLM 聊天”。最好的部分是代理可以 situated 在消息、文件、crons、API、记忆和工具之间。cron 系统确实有用。我有重复性的任务收集信息、处理、总结、通知我并触发后续工作流。其中一些需要大量迭代，但一旦修复，就变得“无聊”（褒义）。记忆也有用，如果经过整理。系统可以记住决策、项目状态、偏好、错误和 prior 修复。这不是魔法。如果你让每个原始片段都成为长期记忆，它会变成污泥。但通过清理和特定项目的记忆文件，它变成了真正的操作层。当上下文清晰且任务范围明确时，子代理很有用。当它们继承太多模糊上下文或模型/配置路由不明确时，用处较小。最有用的模式一直是：人类决定方向，主代理协调，子代理进行有界分析或实现，主代理验证。 哪些出错或让我烦恼：早期，模型/配置问题是痛苦的常规来源。一些本地/小型模型设置根本没有足够的上下文来容纳 OpenClaw 的系统 prompt 加上工具。4k 本地模型可能在技术上能响应，但一旦出现在真实的 prompt/工具上下文，就不舒适了。还有“助手回合失败”式的故障，看起来像 RAM 或模型问题，但往往是 API 密钥/配置问题。调试通常意味着检查 OpenClaw 状态、模型认证、网关配置和提供商可用性。 Cron + 子代理交互。计划工作流生成了子代理，子代理正确完成了工作，但父代理无法读取子输出，因为代理间历史被禁用。结果：有用的工作发生了，但父代理总结具有误导性，下一步没有运行。修复方法是重新设计工作流，让子代理直接写入结果，而不是依赖父代理回读。 Shell 引号处理也导致了真正的失败。通过 Shell 命令传递 JSON 会在撇号和嵌套引号上出错。修复方法无聊但正确：将 JSON 写入临时文件并传递 --file。 更新情况不一。一些 OpenClaw 更新提高了 Pi 上的启动性能和内存压力，这很重要。但更新日仍然需要非常谨慎。我遇到了配置漂移、ACP 命令漂移、文档漂移，不得不检查实际变化而不是相信一切正常，花费数小时调试、修复或回滚。 我的设置中仍然存在子代理模型覆盖问题：默认值并不总是被尊重，所以我现在显式传递 model/agent IDs。很烦，但可管理。 ACP 很有用但不完全可靠。通过 OpenClaw 的 Claude ACP 在某些会话中因内部运行时错误而失败，而直接 ACP/CLI 路径则有效。 密钥/配置管理规范是另一个粗糙领域。OpenClaw 支持某些 credential 路径的结构化 SecretRefs，但旧的 config/auth-profile 文件仍可能包含明文密钥。安全迁移这需要备份、schema 检查和回滚计划。我不会随意编辑工作系统上的实时配置。 Pi 上的资源压力是真实的。长时间运行的 Claude/Codex 进程、crons 和记忆产物可能会积累。我添加了清理例程，后来归档了一个死项目，该项目增长到约 1.6 GB，主要来自可再生成的冗余数据。 哪些成功了：系统现在足够有用，我每天都在使用它。它处理操作记忆、计划检查、重复分析、技术调试、配置审查、小代码更改、API 辅助工作流和结构化跟进。最大的成功不是单一功能。而是连续性。我可以几天后回来问“我们决定了什么？”，“还有什么未决？”，“上次哪里出错了？”，或“为什么我们没有做 X？”，并且通常能得到有足够上下文继续的依据回答。 我还用它做了一个独立的个人开发项目。OpenClaw 很好地处理了构建、架构讨论和拆解操作状态，比如保持故事排序。 哪些未按预期工作：一些工作流看起来很简单，但一旦触及真实状态、外部系统、模型限制和调度，就变得复杂。顺利路径很容易。边界情况占据了大部分时间。一些早期输出有事实或质量问题。我们必须纠正过度自信的声明，修复内部状态，清理格式，修复源处理并收紧审查步骤。系统变得更好，因为这些失败被视为管道缺陷，而不是“模型很奇怪”然后被遗忘。 我目前的观点：OpenClaw 不是一个成熟的消费级助手。它更接近于为那些 comfortable 调试自己自动化栈的人提供的可编程操作层。如果你期望“安装它，它就运行我的生活”，你会失望。如果你愿意将其视为基础设施，它会变得非常有用。 我想告诉新用户的主要事情： start 比你想象的要小。不要从 20 个 cron 任务、5 个代理、3 个模型提供商和巨大的自动化设置开始。从一个消息渠道、一个可靠的模型、一个记忆习惯、一个 cron 和一个真实工作流开始。然后仅当上一层变得“无聊”时才增加复杂性。 另外： • 显式传递 agentId • 在配置编辑前保持备份 • 不要信任仅 prompt 的只读限制 • 关注本地模型的上下文大小 • 将记忆视为你需要整理的东西 • 在外部写入时保持人类介入循环 • 预期更新日需要验证和调试或回滚 • 记录决策，而不是每个随机细节 大约 3 个月后，我不会从我的设置中移除 OpenClaw。它已经跨越了从实验到日常基础设施的界限。但我也不会称它为毫不费力。它强大、尖锐，偶尔令人烦恼。这可能是大多数有用工具所处的诚实类别。