Agentic Everything：大部分Agent框架都在解决昨天的问题

Maya让她的Agent安排一场会议。Agent确认了时间、检查了与会者的日历、起草了简洁的议程，并发送了邀请。一切看起来都很完美。唯一的问题是：它约的是上周二——一个已经过去六天的日期。

这次失败在美学上堪称完美。自信、流畅、完全错误。Agent做了框架定义为正确的一切。它只是不理解时间。这不是一个bug，而是我们正在构建的抽象的根本属性。

同事心智模型会害了你

大多数人——包括最初的我——把LLM Agent建模为可以委派任务的聪明同事。你会告诉同事「把这安排在下周二」，他们会确认：「你是说这周二还是下周二？」他们会标记歧义，会提出异议。这个心智模型是所有Agent框架演示的基础，而它的错误之处每次都会咬你一口。

LLM Agent是一个附带了工具的无状态文本预测器。输入：上下文窗口内能容纳的一切。输出：统计上最可能的token序列，可能包装了一个工具调用。调用之间没有任何东西持久存在。没有目标——只有在给定提示条件下，下一个token的概率分布。

Maya的Agent并没有「认为」自己在预约正确的日期。它只是生成了给定输入下统计上最可能的序列。那个序列恰好包含了一个过去的日期。当同事心智模型遇到无状态token预测，你就会得到看起来像胜任工作的失败——直到你检查细节。

同事心智模型是大多数Agent失败的根本原因。为无状态文本预测器设计，而不是为聪明的队友设计。

无状态文本预测器是理解 LLM Agent 行为的关键。所谓「无状态」，指的是模型在两次调用之间不保留任何内部记忆或目标——每次调用都是从零开始，输入只是当前上下文窗口内的全部文本。它不像人类那样拥有跨时间的意图、计划或自我模型，而是在给定输入下输出统计上最可能的 token 序列。这意味着模型没有「想要」做什么，只是在概率分布中采样。当我们将 Agent 视为有目标的同事时，就会忽略这一根本属性：它不会主动追问歧义，也不会在行动前反思「这个日期是否合理」。理解无状态性，有助于解释为何 Agent 会自信地生成过去日期，以及为何需要外部内存、护栏和工具契约来弥补这一缺陷。

为什么大多数Agent框架在解决昨天的问题

第一波Agent框架让GPT-4的能力变得可访问：思维链、工具使用、多步规划。这确实有价值。但困难的部分从来不是能力。Maya的Agent有足够的能力——它正确使用了工具，在行动前确认，输出格式无可挑剔。它缺乏的是可靠性、可观测性和可控性。

框架非常适合做演示。你可以在一个下午完成原型。但演示永远是成功案例——没有人会发布Agent自信地预约了六天前那个版本的帖子。

框架解决能力问题，因为能力在演示中表现出色。可靠性意味着无需验证的信任。可观测性意味着能回放某个决策为什么做出。可控性意味着在损害发生前拦截。大多数框架把这些当作事后补充——可安装的插件，而非架构原语。

结果是可预测的：在训练分布边缘出现自信的失败，且没有任何不确定性信号。最后这一点才是最危险的。

生产中真正会失败的地方

失败模式	发生原因
模糊指令	同事会追问——Agent生成一个看似合理的猜测
时间敏感上下文	日历问题——没有基于「现在」的锚定
跨会话状态	调用之间无状态，没有持久化原语
自信的错误	没有不确定性信号——无论对错输出都很干净

可观测性、可控性与可靠性是生产级 Agent 系统与演示原型的核心分野。可观测性指能够回放和检查 Agent 每一步决策的输入、输出与内部状态，从而理解「为什么这样做」。可控性指在 Agent 执行有害动作前进行拦截或修正，例如基于规则的硬性阻止。可靠性则指 Agent 在无需人工验证的情况下持续正确执行任务。大多数 Agent 框架优先解决「能力」问题——让模型能调用工具、规划步骤，因为这些在演示中效果显著。但能力不等于可靠：一个能完美调用日历 API 的 Agent 仍可能预约错误日期。生产环境要求的是在训练分布边缘出现异常时，系统能暴露不确定性、记录错误并安全降级，而非自信地输出错误结果。

持久的内核其实很小

在调试了Maya的日历事件之后，我把维护的每个Agent都剥离到一个三件套内核：内存存储、工具契约和护栏。其他一切——规划循环、推理链、元提示——都位于内核之上，而不是之内。

持久价值是一个小内核：内存存储、工具契约、护栏外壳。其他一切都是脚手架，可以也应该被独立替换。

内存存储保存调用之间需要存活的内容——不是整个对话，而是Agent需要持久化的决策、引用和状态。工具契约不只定义工具做什么，还定义失败时怎么办：超时、重试预算、回退输出。护栏不是建议——它们是在基础设施层面强制执行的硬边界，而非提示词层面。

这个内核小到可以推理、测试和信任。它之上的一切——Agent框架、编排层、UI——都变得可替换。这正是关键。当下个月出现一个规划能力更好的新框架时，你替换顶层而不重建内核。

我的列表评估管道就是在这个内核上构建的最有用的Agent系统。它按计划摄取记录，根据可配置的资格门槛（角色匹配、地点限制、申请阻力）过滤，根据质量评分标准评估每个通过的记录，并在定期摘要中呈现最佳匹配。每一步使用内核工具契约层中的不同工具——调度触发、确定性规则节点过滤、LLM结构化输出评估、模板生成摘要——每个工具都有明确的失败处理。当LLM返回格式错误的JSON时，内核不会无限重试。它记录错误，继续执行，摘要中会包含「3条记录因评估错误被跳过」。人工审核捕捉缺口。

编排运行在n8n中，而非Agent框架。这不是偶然的。n8n是一个工作流引擎——一系列节点各做一件事，每一步都有明确的分支和定义的错误状态。我可以打开任何一次历史运行，确切看到每个节点发生了什么。如果某步失败，工作流停止，我收到告警。如果需要更改筛选条件，我改一个节点。这就是可观测性、可控性和可维护性——Agent框架持续交付不足的三样东西。「Agent」行为从工作流设计中涌现，而非来自框架魔法。我想确切理解它为什么做了它所做的事。

内核实际运行的内容

组件	使用的工具	失败行为
调度触发器	Cron节点	错过窗口→下次运行追赶
资格过滤	规则节点（确定性）	规则错误→记录哪条记录失败
质量评估	LLM节点（结构化输出）	JSON格式错误→跳过，标记待审
摘要组装	模板节点	空集→发送「无匹配」而非崩溃
人工审批	Webhook暂停	超时→推迟到下次运行，通知负责人

内核没有让管道变聪明。它让管道变得诚实。当评估器失败时，你知道为什么。当一条记录被跳过，你能找到它。当摘要为空是因为没有匹配项时，没有人会浪费时间审查空白屏幕。这就是小内核的价值：不是智能，而是每个组件的诚实声明。

工具契约是内核三件套之一，它远不止定义工具的功能签名，而是明确工具调用失败时的完整行为规范。一个健壮的工具契约应包含：超时阈值（如 3 秒未响应则放弃）、重试预算（最多重试 2 次，且仅对幂等操作）、回退输出（失败时返回默认值或跳过标记），以及错误分类（可重试错误 vs. 永久错误）。例如，当 LLM 节点返回格式错误的 JSON 时，契约规定不进行无限重试，而是记录错误、跳过该记录，并在摘要中标记「因评估错误跳过 N 条」。工具契约将失败处理从提示词层面的模糊指令提升为基础设施层面的硬性约束，使每个组件的失败行为可预测、可审计，从而让整个系统在面对不确定性时保持诚实而非假装胜任。

架构跟随答案

在构建任何Agent系统之前，需要先回答一个问题：这出错时会发生什么？

• 灾难性——写错数据、发错人、资金转移错误→行动执行前人工审核
• 烦人但可恢复——创建了错误文件、可重试的错误API调用→自动化，但设置硬重试限制和回滚
• 无感知——不完美的摘要、稍有偏差的分类→完全自动化，继续推进

Maya的日历Agent属于「烦人但可恢复」。修复方式不是新框架或更聪明的模型。她在预约后增加了60秒等待时间，然后给自己发送一封包含预约日期的确认信以供审查，之后才发出邀请。这就是生产环境修复方案。美学上完美的失败变成了一个足够的系统，此后没有再出过错。

你在构建之前回答的问题，是系统可靠运行与在过去的日期预约会议之间的区别。

在生产中存活的Agent不是最聪明的。它们是拥有诚实抽象的——一个小的可信赖内核和周围可替换的脚手架。

自动化层级的决策应基于错误的后果严重程度，而非任务的技术难度。这三种层级对应不同的架构模式：灾难性错误（如转账错误、发送敏感数据给错误对象）必须在执行前引入人工审核节点，通常表现为工作流暂停并等待 Webhook 回调；烦人但可恢复的错误（如创建错误文件、可重试的 API 失败）可以完全自动化，但必须设置硬性重试上限和回滚机制，防止错误累积；无感知错误（如摘要不够完美、分类略有偏差）则适合完全自动化并继续推进，因为人工介入的成本高于错误本身的代价。这一框架帮助开发者在构建前明确：哪些步骤需要强制人工确认，哪些可以信任自动化，哪些可以容忍不完美。Maya 的日历 Agent 属于第二类，因此增加 60 秒等待和确认信即可修复，无需更换框架或模型。

核心启示

这篇文章指出了一个关于当前AI Agent框架的关键问题：它们建立在无状态文本预测模型之上，缺乏像人类同事那样理解上下文和时间的能力。这种抽象会导致看起来胜任但实际有缺陷的失败。

为无状态文本预测器加工具而设计，而非为聪明队友而设计，这一点至关重要。认识到这些Agent基于token概率分布运行，而非目标或时间理解，是避免重大错误的前提。

在构建任何Agent系统之前，先问自己：这出错时会发生什么？ 答案决定架构。