用 openclaw 连续做了三周的高频工作，覆盖了十多种真实的使用场景，从生活到育儿到投资全覆盖。
简单任务、模糊任务、允许误差的任务，完全没问。真正的分水岭，出现在需要精确数据操作的场景。
只要 workflow 依赖特定规则的文件命名、特定位置的数据写入或替换，精确性就明显下降。上下文一旦变多，精确性只会进一步下降。而上下文不够的，又根本做不了复杂的工作。
原因很简单： agent 擅长的是给出一个“大概是这样”的结论。 但数据 workflow 要求的是：每一个数字都不能错。 两者之间没有缓冲地带。
假设一个流程包含 10 个数据处理步骤：新建子文件、修改 JSON 指定字段、在既有目录结构中插入内容、再触发下一步解析、前一步的数据直接决定了后一步的推理方向。这些步骤单独看都不复杂，但它们有一个共同特征：只要任何一个环节出现微小偏差，整个流程就会失效，而且这种失效很难排查。
因为 agent 的错误通常不是直接报错，而是：
- 文件位置偏了一层
- key 名称略有变化
- 数据格式语法正确、但结构不同
- 换一个模型，原本勉强稳定的流程甚至可能直接失效
等到发现时，已经全盘皆输，而且很难审计具体是哪一步出了错。
这不是高级的 memory 架构 和 tools 设置可以解决的。
因此我目前的结论是：
1、AI 很强，Openclaw 也很强，但是它们并不擅长直接操作数据；
2、精确数据型工作，最终都会回到："数据库 + 代码 + 明确的 workflow 结构"。当然，其中某几个 step 可以外包给 agent 去操作、并用严格受限的接口来接受 agent 提交的局部数据（比如 x 上针对某个的舆情分析评分），这是很好的互补关系。
3、AI agent 最合适的位置，不是基于 prompt 直接操作数据，而是生成精确的代码，让代码去操作数据。改 prompt 的性价比，往往不如改代码。
最近 SaaS 和软件公司的低迷，是因为市场在假设 agent 可以直接取代软件本身。我现在可以确定：这是一个巨大的市场误判，又是一个认知可以变现的机会。
@aigc1024
OpenClaw小龙虾🦞专属频道
@openclaw1024
简单任务、模糊任务、允许误差的任务，完全没问。真正的分水岭，出现在需要精确数据操作的场景。
只要 workflow 依赖特定规则的文件命名、特定位置的数据写入或替换，精确性就明显下降。上下文一旦变多，精确性只会进一步下降。而上下文不够的，又根本做不了复杂的工作。
原因很简单： agent 擅长的是给出一个“大概是这样”的结论。 但数据 workflow 要求的是：每一个数字都不能错。 两者之间没有缓冲地带。
假设一个流程包含 10 个数据处理步骤：新建子文件、修改 JSON 指定字段、在既有目录结构中插入内容、再触发下一步解析、前一步的数据直接决定了后一步的推理方向。这些步骤单独看都不复杂，但它们有一个共同特征：只要任何一个环节出现微小偏差，整个流程就会失效，而且这种失效很难排查。
因为 agent 的错误通常不是直接报错，而是：
- 文件位置偏了一层
- key 名称略有变化
- 数据格式语法正确、但结构不同
- 换一个模型，原本勉强稳定的流程甚至可能直接失效
等到发现时，已经全盘皆输，而且很难审计具体是哪一步出了错。
这不是高级的 memory 架构 和 tools 设置可以解决的。
因此我目前的结论是：
1、AI 很强，Openclaw 也很强，但是它们并不擅长直接操作数据；
2、精确数据型工作，最终都会回到："数据库 + 代码 + 明确的 workflow 结构"。当然，其中某几个 step 可以外包给 agent 去操作、并用严格受限的接口来接受 agent 提交的局部数据（比如 x 上针对某个的舆情分析评分），这是很好的互补关系。
3、AI agent 最合适的位置，不是基于 prompt 直接操作数据，而是生成精确的代码，让代码去操作数据。改 prompt 的性价比，往往不如改代码。
最近 SaaS 和软件公司的低迷，是因为市场在假设 agent 可以直接取代软件本身。我现在可以确定：这是一个巨大的市场误判，又是一个认知可以变现的机会。
@aigc1024
OpenClaw小龙虾🦞专属频道
@openclaw1024
