44 篇博文 含有标签「agent-architecture」

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

当单次尝试（single-pass）的智能体（agent）不再足够好时，默认做法是将其包装在一个自我批评循环（self-critique loop）中。生成、批评、修正、重复。我接触的大多数团队都假设评估（eval）的提升将与修订轮次呈大致线性关系，并止步于此。但数据往往并不如人愿。到第三轮自我批评时，准确率仅提高两三个百分点，而 Token 成本却增加了 3–4 倍，而且第一轮没发现的失败模式（failure modes），在第三轮通常也发现不了——因为产生错误答案的上下文，正是被要求找出错误的那一个。

另一种形式效果更好且成本更低：让第一轮作为“浪费式”的探索，将其丢弃，然后在干净的上下文中基于学到的经验运行第二轮。称之为“二稿模式”（second-draft pattern），或“先探索后提交”（explore-then-commit）。第一稿允许草率、走弯路、堆积草稿产物、追逐最后证明是错误的假设。第二稿是受限的——它获取提炼后的发现（distilled findings），并产出干净的执行。在那些倾向于使用自我批评的任务中（如多步推理、涉及多个文件的代码、研究综述），这种双轮形式在质量和成本上通常都优于 n 选 k 的自我批评。

SQL 工具在数据从网络线路传出时即发送行。智能体调用它并期待得到结果。而一年前编写的运行环境（当时所有工具都是请求-响应式的）在调用模型之前，会尽职地将整个流缓冲成一个单一字符串。40 秒后，缓冲区达到了 200 KB，上下文窗口被消耗了一半，智能体正在对一个查询的第 47,000 行进行推理，而它本可以在第 30 行就停止。没有人故意设计这种失败——这仅仅是因为将“工具已返回”视为规划器唯一响应事件的结果。

向流式工具的转变正在规划器尚未察觉的情况下发生。SQL 引擎发出渐进式结果集。文档提取器生成分页。搜索 API 在相关性评分稳定后按批次返回命中结果。MCP 的 Streamable HTTP 传输协议（2025-03-26 规范中 HTTP+SSE 的替代方案）使增量响应成为一流的传输模式，而不再是一项稀有的功能。传输层已经准备就绪，但其上的规划器还没有。

关于 LLM 有一个令人不安的事实，但在产品评论中却鲜少被提及：赋予它们用途的特性，恰恰也是让它们易受攻击的特性。一个顺从地执行指令的 LLM —— 无论指令来自何处、何种格式、何种来源 —— 都会以处理合法指令时那种同样的愉快顺从态度去执行恶意指令。模型无法分辨其中的区别。

这不是一个可以被修补掉的 bug。这是一种架构性的现实。随着这些系统承担起更多智能体（agentic）的角色 —— 阅读邮件、浏览网页、执行代码、调用 API —— 其暴露面正以大多数工程团队尚未察觉的方式扩大。

大多数关于幻觉的研究都集中在单次模型调用的输出上。这种框架忽略了一个更可怕的问题：在四阶段的工作流（pipeline）中，如果每个阶段都无条件地信任前一个阶段的输出，会发生什么。第一阶段中一个虚构的事实不仅会持续存在，还会成为后续每一次推理的承重前提。到第四阶段，工作流会给出一个自信且逻辑自洽的答案，但结果却是完全错误的。

这不是一个可以通过更强大的模型来解决的能力问题。这是一个系统架构问题，需要从系统层面进行修复。

一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。

将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。

当一个 PlanCompiler 风格的智能体（agent）与直接的 LLM 生成代码模式在 300 个分层多步任务中进行基准测试时，结构化方法实现了 92.67% 的成功率，单任务成本为 $0.00128。而直接方法——即 LLM 在自由形式的循环中逐步决定行动——成功率为 62$0.0106。这意味着准确率提高了 50%，而成本仅为原来的八分之一。

差异不在于模型的能力。两种方法使用的是同一个模型。差异在于架构：一个将计划生成与计划执行分离开来；另一个则将两者混为一谈。

现代 AI 产品中最反用户的按钮，偏偏也是最不可或缺的那一个。在对话进行到第 40 轮左右时，智能体（agent）已经陷入了错误的假设，语气开始跑偏，每一次新的交互都在让答案变得更糟而不是更好。用户知道该怎么做：清空重来。他们点击“新对话（New Chat）”——眼睁睁看着进行到一半的计划、草拟的四份文档，以及花了 20 分钟调优的提示词，随着那些被污染的历史记录一同烟消云散。

于是，他们不再使用重置按钮。他们打开第二个标签页，手动复制粘贴产出物，同时维持着那个已经崩坏的对话，把它当成一个不敢关闭的墓地。这种仪式——用手动复制粘贴来绕过本应发挥作用的按钮——是一个聊天产品对其数据模型有误所发出的最清晰信号。

第一次事故很少表现为系统宕机。它通常是来自客户成功团队的一条 Slack 消息：“嘿，我们还好吗？在过去的一小时里，有五个客户升级了工单，这些工单在‘待审核’状态下已经躺了超过一天了。”你检查了模型延迟仪表盘。绿色。你检查了智能体（Agent）的成功率。绿色。你检查了单次调用成本图表。健康。你监测到的一切指标都正常。出故障的是一个你的监控栈根本不知道其存在的队列，负责该队列的人员其日历不在你的容量规划器的读取范围内，而管理它的 SLA（服务等级协议）甚至从未被书写下来。

那个队列就是你的人机回圈（human-in-the-loop, HITL）升级路径。你在三个月前为了“安全起见”添加了它——当智能体在极少数情况下置信度较低或操作风险较高时，它会将案例移交给人工审核员。上线之初，它每天可能只处理十几个条目。运维团队在处理其他任务的间隙就能搞定它们。它曾是一个兜底方案，而不是一个系统。如今，它正在处理数千个条目，解决时间的中位数翻了三倍，排队等待的客户正在悄无声息地流失。HITL 路径本身并没有失效。它只是不再被当作生产环境来对待了。

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。

看看大多数智能体框架提供的循环原语：continue、return、retry 以及一个硬性终止运行的步数预算。注意缺失了什么。这里有一条表示“工作成功”的路径，一条表示“模型想继续”的路径，还有一条表示“我们耗尽了资金或耐心，于是强行终止循环”的路径。唯独没有一条头等路径来表达“我正在执行的计划是错误的，我想将其丢弃并开始一个全新的计划”。放弃原语（abandon primitive）——即一种让规划器显式、结构化地宣布当前轨迹无望的方式——是智能体循环语法中缺失的动词。它的缺失导致了一类通常被误诊为“模型需要更多推理”的失败。

一个在注定失败的分支上执行了三步的规划器，会不断优化同一个错误的计划，因为循环唯一的出口是成功、重试上一步或耗尽预算。这些路径都不包含“放弃该策略并尝试另一个”。因此，智能体执行了循环所允许的操作：它就地修改计划、再调用一个工具、再请求一次澄清，并在步数预算耗尽前不断收敛到一个非解决方案。当最终撞墙时，用户看到的是一条礼貌的失败消息，而不是问题的答案。这些浪费的步骤所带来的成本是真实的——生产数据表明，智能体系统 5-10% 的 Token 支出都花在了无法产生任何可用结果的重试上，而这一数字主要由长期的“注定失败分支”占据，而非孤立的工具错误。

你的智能体刚刚花了 90 秒和几美元来修改一个只有三行代码的函数。在提交编辑之前，它列出了两个目录，打开了测试文件，运行了 grep 来查找调用者，读取了配置模块，检查了 CI 工作流，还调出了一个从未用过的类型定义。它产生的 diff 只有四行，而产生这个结果的 trace 却包含了 43 次工具调用。

这就是“首触工具损耗”（First-touch tool burn）：一种当智能体被分配了一个范围明确的任务时，却表现得好像每个请求都是一个研究课题的模式。探索行为先行且力度极大 —— 在向文件写入单个字符之前，60% 到 80% 的 token 预算都花在了列出目录、grep 和读取上。团队在第一次查看 trace 时发现了这一点，并意识到智能体为一个两分钟的任务做了相当于两小时的入职培训。

这种行为并非某个特定模型的 bug。它是这些系统的训练和评估方式的必然产物，与生产环境发生了碰撞。而生产环境衡量的是训练从未衡量过的东西：这项工作是否便宜到值得去做的程度。