311 篇博文 含有标签「ai-agents」

你的产品在第 10 秒到第 45 秒之间存在一个“空洞”，在这个时间段内，你设计的任何东西都不再起作用。用户在 10 秒左右就会放弃无响应的 UI —— Jakob Nielsen 在 90 年代就确定了这个阈值，现代的眼动追踪研究显示的偏差也不过一两秒。现代智能体（Agent）的工作通常需要 30 到 120 秒。多步规划、检索、几次工具调用，可能在最终输出前还要经过一轮反思 —— 延迟预算不再只是预算，而是一个巨大的深渊。

大多数团队在第一次发布智能体功能并查看会话录像时都会发现这一点。用户疯狂点击提交按钮。他们将查询粘贴到第二个标签页中。他们关闭窗口并从头开始重试，坚信系统已经崩溃。功能本身没问题，但等待过程出了问题。“加载动画出现”与“答案送达”之间的空白地带是 AI 产品设计中最被忽视的环节，而它正是决定用户认为你的智能体是聪明还是死机的关键。

AI Agent 的标准心智模型通常假设采用 HTTP：客户端发送请求，Agent 进行处理，最后返回响应。这种模式清晰、同步、且易于推理。当一个基于 LLM 的函数执行失败时，你会收到一个错误代码；当它成功时，你就可以继续下一步。

一旦你将 HTTP 接口换成 Kafka 主题或 SQS 队列，上述每一个假设都会开始动摇。队列保证的是“至少一次交付”（at-least-once delivery），而你的 Agent 具有随机性。这种组合产生了一些在确定性系统中并不存在的故障模式——而且修复方法也与传统微服务所采用的方法不同。

本文将探讨当 AI Agent 消费消息队列时实际发生的变化：幂等性、顺序性、背压、死信处理，以及一种特定的故障模式——即重播的消息在第二次触发时会导致 Agent 产生不同的行为。

大多数构建 LLM 驱动科学工具的团队都犯了同一个架构错误：他们直接套用编码 Agent 框架，换上领域专用工具，便将其称作研究型 Agent。事实并非如此。编码 Agent 与研究型 Agent 在表面机制上颇为相似——两者都调用工具，都反复迭代——但它们对成功标准、状态管理和终止条件的底层假设几乎截然相反。将编码 Agent 架构部署到科学工作流中，不仅会产生更差的结果，还会产生看似自信却实为错误的结论，而且这类错误事后几乎无从发现。

这一区别如今尤为紧迫——研究型 Agent 的基准测试正在激增，各团队竞相构建科学 AI，而"直接用编码 Agent"的捷径正在催生大量表面上可信的工具，它们在真实科学场景中失效，而构建者往往并不完全理解失效的原因。

每一个从"我们有个聊天机器人"升级到"我们有个 Agent"的工程团队，都会撞上同一堵墙：他们的测试套件开始失去意义。

经典测试金字塔——70% 单元测试、20% 集成测试、10% 端到端测试——建立在三个基本假设之上：单元测试运行成本低、与外部系统隔离、结果确定可重复。Agentic AI 系统同时打破了这三个假设。所谓的"单元"是一次消耗 token 且每次返回不同结果的模型调用。一次端到端运行可能耗时数分钟，消耗的 API 预算足以让一位初级工程师整个迭代周期的测试都无法证明其合理性。而隔离性几乎无从实现，因为 Agent 的智能恰恰来自于与外部工具和状态的交互。

当一位人工贷款官员拒绝一份申请时，这个决定背后有一个具体的名字。这位官员接收了特定信息，经过深思熟虑后做出了行动。推理过程或许并不完美，但它是可归因的——有人可以被联系、被质询、被追责。

当一个 AI 智能体拒绝同一份申请时，留下的只有一条数据库记录。这条记录表明决定已做出，但没有说明原因，没有说明是什么输入驱动了这个决定，没有说明当时运行的是哪个版本的模型，也没有说明系统提示词是否在两周前悄悄更新过。当你的合规团队将这条记录交给监管机构时，监管机构不会满意。

这就是智能体审计追踪问题，而大多数构建 AI 智能体的工程团队至今尚未解决它。

在试点项目结束六个月后，你的客户数据智能体仍然拥有对生产数据库的写入权限，而它自第一周以来就没再触碰过这些数据库。没有人恶意授予这种访问权限，但也没有人将其撤销。这就是 AI 智能体权限蔓延 (AI agent permission creep)，它现在已成为生产级智能体系统中授权失败的首要原因。

这种模式显而易见：智能体最初拥有一套最小权限集，随着集成的扩展（“只为这个工作流添加 Salesforce 的读取权限”），部署后的权限收紧步骤被无限期推迟。与人类身份与访问管理 (IAM) 中至少在名义上强制执行的季度访问审查不同，智能体身份完全处于大多数组织访问审查流程之外。《2026 年企业基础设施安全中的 AI 现状报告》（调查对象为 205 位 CISO 和安全架构师）发现，70% 的组织授予 AI 系统的访问权限超过了同角色的员工。拥有过度特权 AI 的组织报告的安全事件发生率为 76%，而执行最小权限原则的团队仅为 17% —— 两者相差 4.5 倍。

大多数工程团队默认将 AI 功能构建为聊天界面。用户输入内容，模型做出响应。这种模式感觉很自然，因为它映射了人类的对话，而且工具链也让实现变得简单。但当你观察生产环境中的这些基于聊天的 AI 功能时，你经常会看到同样的功能失效：用户界面处于闲置状态，等待着那些太忙、太分心或根本不知道该问什么的用户。

聊天是一种“拉取”（pull）模式。由用户发起，AI 做出反应。对于任何产品中具有价值的 AI 工作的一个重要子集——监控、异常检测、工作流自动化、主动通知——“拉取”模式都是错误的形态。无论用户是否记得打开聊天窗口，这些工作都需要进行。

异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。

这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。

你的 AI Agent 运行得一切正常，直到某一刻它彻底不行了。某个工具宕机——也许是搜索 API 触发了限流，也许是数据库响应迟缓，也许是代码执行沙箱超时——整个 Agent 随之崩溃。不是部分答案，不是降级响应，而是彻底失败。要么一片空白，要么满是幻觉。

这不是一个 Bug，而是一个设计选择——而且几乎没有人是刻意做出这个选择的。我们今天所构建的 Agent 架构隐式地选择了"彻底失败"，原因只有一个：没有人设计过部分可用路径。如果你有分布式系统的经验，这个模式应该让你感到似曾相识。这正是 CAP 定理，以一副新的面孔出现了。

你的 Agent 完成了一个 25 步的研究任务。最终报告看起来很精美，引用也能对上，推理链条看似连贯。但 Agent 在第 3 步幻觉了一家公司的创立年份，而后续的每一个推断——市场时机分析、竞争定位、增长轨迹——都建立在那个错误的日期上。输出结果自信地、系统性地错了，而你的流水线中没有任何环节捕捉到这个问题。

这就是级联上下文污染：一个错误的中间结论通过后续的推理步骤和工具调用不断传播，最终演变成系统级故障。这是长时运行 Agent 中最危险的失败模式，因为它看起来像是成功的。

在一个金融科技团队推出 AI 编程智能体来处理日常后端任务的三个月后，一位资深工程师离职去了另一家公司。当团队试图还原六周前做出某些身份验证决策的原因时，却发现没有人能做到。PR 描述写着“按讨论实现”，提交信息写着“根据需求”。AI 智能体做出了选择，代码正常运行，而背后的推理过程却消失得无影无踪。

这并非文档记录的失败。当原本用于传递理解的渠道——工程师之间的往复沟通、解释带来的摩擦、向他人证明决策合理性的压力——被一个优化输出而非优化理解的系统所取代时，必然会发生这种情况。

如果你经历过 2015–2018 年的微服务爆发期，那么 MCP 的现状应该会让你感到不安的熟悉。一个真正有用的协议出现了。它很容易搭建。每个团队都搭建了一个。没有人追踪什么在运行、谁负责维护、如何保障安全。不到十八个月，你就会盯着一张工程师私下称为"死星"的依赖关系图。

Model Context Protocol 正在沿着同样的轨迹发展，速度大约是三倍。非官方注册中心已经索引了超过 16,000 个 MCP 服务器。GitHub 上有超过 20,000 个公开仓库在实现它们。Gartner 预测到 2027 年 40% 的 agentic AI 项目将失败——不是因为技术不行，而是因为组织在自动化有缺陷的流程。MCP 泛滥正是这个问题的症状。