冗长的AI对话是糟糕的项目数据库
摘要
文章认为,长时间的AI聊天会话作为编码代理的项目数据库并不可靠,主张使用外部持久计划来管理跨会话的状态和意图。
几小时后,编码代理的聊天包含了除可靠真实答案外的一切。它有原始请求、三种可能的方法、一个纠正、一个未完成的分支,以及一个在测试运行前写下的自信摘要。对于单个小任务来说,这是可管理的。但当多个代理在多个会话中工作时,它就会崩溃。我们学会了将计划保留在对话之外。持久计划记录着正在做什么、已完成、被阻塞和下一步。在交接时,我们根据实际的拉取请求、检查和系统状态来核对这些声明。如果聊天说已完成,但证据表明相反,计划就会被修正。聊天仍然重要,它是探索发生的地方,只是它不拥有状态或意图。我认为许多“代理记忆”问题实际上是权限问题。我们不断试图让模型记住更多,而系统需要一个受控的地方来记录已决定的内容和当前的真实情况。对于在多个会话中运行代理的人来说,什么能在聊天中幸存?是一个计划、一个问题跟踪器、一个事件日志,还是大多是最后生成的摘要?
相似文章
大多数AI智能体失败的原因在于人们像构建聊天机器人那样构建它们
许多AI智能体实现失败是因为它们把智能体当作聊天机器人来对待,依赖聊天历史记录来管理状态,而非使用确定性的数据结构。文章提倡将推理(LLM)、动作(工具)、工作流进度(状态机)和外部触发(网络钩子)分开,以构建可靠的业务智能体。
为什么AI聊天在处理时间相关问题时仍然表现糟糕?
本文探讨了AI聊天机器人在正确回答时间相关问题上持续存在的困难,分析了背后的原因以及用户的挫败感。
长期运行的AI代理可能面临比记忆更大的连续性问题
反思了长期运行的AI代理所面临的连续性问题,认为需要确定性控制层来管理权威状态,并质疑现有的IAM、事务和溯源等基础设施是否足够。
我在研究中越多地使用 AI,就越不想依赖线性的聊天线程
作者认为,线性聊天界面在处理复杂研究任务时效率低下,转而倡导使用 Flowith 等基于画布的 AI 工具,以支持持久化、非线性的工作流程。
聊天优先的AI工具在需要代理自主工作时就会崩溃
作者认为聊天优先的AI工具不足以构建自主代理工作流,并描述了替代原语,如定时触发器和子代理委派,主张从“带着工具聊天”转向“使用LLMs的自主流程”。