5 篇博文 含有标签「planning」

邮件是在周二发出的。你那两个最重要的功能所依赖的 Checkpoint 进入了 90 天的下线期。你的工程团队正处于为了另一个发布而进行的协同代码冻结（Freeze）的第二周。等到冻结解除时，你将只有不到三十天的时间来针对新模型重新验证两个生产环境的功能——这里的“重新验证”意味着重建评估集、运行影子流量、获得产品负责人签字，并在一个没人关注的 Feature Flag 之后发布，因为发布团队还在忙着处理代码冻结原本针对的那个项目。

这种冲突并不少见。主要供应商发布废弃周期的频率是以月为单位的，每个在托管模型上运行的团队现在都经历过至少一个周期。团队尚未吸收的教训是，供应商的废弃并不是像库升级那样的工程事件——它是一个运行在你无法控制的时钟上的排程事件，任何没有预留预算的路线图都会将这笔成本视为一场意外。

你的规划器输出了五次工具调用。从纸面上看，这是一个干净的解决方案：lookup_user、search_documents、call_external_api、spawn_sub_agent、request_human_approval。轨迹优雅、逻辑自洽，智能体最终也会给出正确答案。可在生产环境中，这五个步骤分别耗时 12 毫秒、800 毫秒、4 秒、2 分钟和 6 小时。规划器从未察觉，它这五步计划在成本上跨越了九个数量级。


这并不是幻觉。模型选对了工具，顺序也合理。它做不到的——工具模式根本没给它做这件事的途径——是去推理：计划的最后一步在性质上和第一步完全不同。在规划器眼里，工具就是工具，计划图中每个节点的权重都是 1。

一个规划器智能体输出了七个步骤。每一个看起来都很合理。编排器分发了这些步骤，前三个返回了值，第四个在等待第五个，第五个在等待第七个，而第七个——埋藏在规划器散文般描述的第三行里——正静静地等待着第四个。没有任何东西被锁定。没有触发过任何 EDEADLK。智能体消耗了 40,000 个 token 来推理为什么第四步“花费的时间比预期长”，最终以一个温和、合理的道歉向用户宣告放弃。

这就是你的智能体无法察觉的死锁。它不是操作系统课程中的那种经典死锁——这里没有互斥锁（mutex），没有内核可以内省的资源图，也没有你的技术栈中任何人能识别的持有者或等待者。依赖关系存在于规划器生成的英语句子中，循环形成于潜在语义而非任何数据结构中，而故障模式看起来与“模型正在努力思考”无异。经典的死锁检测在这里毫无用处，但代价是相同的：工作流停滞，token 蒸发，而你的 trace 什么也不会告诉你。

打开一个智能体在长程规划任务中的追踪记录（trace），数一数模型写了多少次“让我重新考虑一下”、“经反思”或“更好的方法是”。现在，将它最终确定的计划与最初起草的计划进行对比。在我审计过的大多数追踪记录中，第二个计划其实就是换汤不换药的第一个计划 —— 同样的分解方式、同样的工具调用、同样的操作顺序，只是重命名了一些步骤标签并重新组织了理由的措辞。反思确实运行了。模型输出了看起来像是在重新考虑的 token。但计划本身纹丝不动。

这很重要，因为“带有反思”已悄然成为一种质量等级。团队在发布规划器时会加入一轮、两轮或三轮反思，并为此支付额外的成本。推理开支是真实且可衡量的。但计划层面是否真的发生了改变，几乎没有人去进行检测，而答案往往是：没有。

大多数声称在“生产环境中有智能体”的团队其实没有。调查一致显示，大约 57% 的工程组织已经部署了 AI 智能体——但当你应用严格的标准（LLM 必须能够规划、行动、观察反馈并根据结果进行调整）时，只有 16% 的企业部署和 27% 的初创公司部署符合真正的智能体标准。其余的只是加装了工具调用功能的“美化版”聊天机器人。

这种差距不在于模型能力，而在于架构。真正的自主智能体需要三个相互关联、协同工作的子系统：规划、记忆和工具使用。大多数实现只正确地完成了其中一个，部分实现了第二个，却忽略了第三个。结果是系统在演示中表现出色，但在生产环境中却会不可预测地失败。