我认为人们低估了代理离开演示阶段后“状态”的重要性

在演示中，代理看起来非常聪明，因为每次运行都是从零开始：干净的上下文、干净的浏览器状态、干净的内存、干净的输入。生产环境则相反，哈哈。几天后你突然会遇到： * 未完成的任务 * 过期的会话 * 冲突的记忆 * 来自旧运行的重试 * 处于奇怪状态的浏览器标签页 * 用户在工作流中间更改内容 现在代理必须在累积的混乱中运作。我最近有一个工作流，逻辑本身完全没问题，但一个过期的会话导致代理误读页面，进而污染了记忆，影响了后续数小时的决策。那时我意识到：很多“推理失败”实际上是状态管理失败。那些看起来可靠的代理通常并不更聪明。它们只是在更干净的环境和更严格的状态控制下运行。老实说，这正是大多数教程完全失败的地方。它们展示提示和编排图，但跳过了： * 状态恢复 * 重试 * 清理 * 运行之间的隔离 * 操作后的验证 而这基本上就是全部的难点，哈哈。我在浏览器工作流中也严重遇到过这个问题。转向更受控的浏览器层，并尝试像Browser Use和hyperbrowser这样的设置，帮助很大，因为运行之间的状态变得可预测得多。开始感觉生产环境中的代理更多是关于管理随时间积累的熵，而不是智能本身。