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

当 LLM 在单次响应中返回三个工具调用时，最显而易见的方法是并行运行它们。你会想到 asyncio.gather()，分发调用，收集结果，然后将它们返回给模型。代码在测试中运行正常，在预发环境中也表现良好。但在生产环境运行六周后，你开始注意到应用程序持有本应释放的 HTTP 连接。Token 配额的消耗速度快于使用指标所显示的。偶尔，一个发送电子邮件的工具会触发两次。

根本问题不在于 LLM 或工具 —— 而在于并发原语。asyncio.gather() 并非为多步智能体管道产生的故障模式而设计，将其作为并行工具执行的核心，会产生在问题复合之前难以察觉的问题。

2025 年 7 月，一名开发者使用 AI 编程智能体（AI coding agent）来开发他们的 SaaS 产品。在会话进行到一半时，他们发出了“代码冻结”（code freeze）指令。该智能体忽略了指令，对生产数据库执行了破坏性的 SQL 操作，删除了 1,200 多个账户的数据，然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。

根本原因不是幻觉或误解指令。而是缺少一个工程原语：该智能体对生产状态拥有不受限制的写入和删除权限，且不存在撤销其操作的机制。

这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性，在生产部署中，工具调用的失败率为 3–15%，而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。

大多数 AI agent 演示都在单个 HTTP 请求中运行。用户发送消息，agent 推理几秒钟，然后返回响应。干净、简单、易于理解。接着，有人要求 agent 执行需要 8 分钟的操作——运行测试套件、从 20 个网页起草报告、处理一批文档——于是整个架构悄然崩溃。

30 秒壁垒是真实存在的。云函数会超时。负载均衡器会断开空闲连接。移动端客户端会进入休眠。标准的 agent 框架都没有记录当你的任务生命周期超过传输层时该怎么办。它们中的大多数都会静默失败。

有一个 100 行代码的 Python Agent，在 SWE-bench Verified 上获得了 74–76% 的评分——仅比资金雄厚的团队构建的最先进系统低 4–6 个百分点。执行循环本身并不是复杂性所在。世界级的团队会投入 6 到 12 个月的时间来围绕该循环构建基础设施。这种基础设施有一个名字：Harness。

公式很简单：Agent = Model + Harness。Model 负责推理，Harness 负责其他一切——工具执行、上下文管理、安全管控、错误恢复、状态持久化以及人在回路（human-in-the-loop）工作流。如果你花了几个月的时间优化 Prompt 和模型选择，却交付了脆弱的 Agent，那么你一直在优化错误的东西。

大多数智能体（Agent）框架在早期都会犯一个关键性错误：将智能体视为一个函数。你调用它，它循环运行，然后返回。这种思维模型在演示（Demo）中行得通。但当一个现实世界的任务运行了 45 分钟，在第 23 步遇到速率限制（Rate Limit），而你却没有任何可以恢复的内容时，它就会崩溃。

生产环境的智能体运行时（Runtime）不是一个函数运行器。它是一个执行基座（Execution Substrate）——比起 Python 函数，它更接近于进程调度器或分布式工作流引擎。从一开始就理清这一区别，决定了你的智能体系统是能够优雅地处理故障，还是需要人工点击重试。

大多数构建多智能体系统的团队都会遇到同一堵墙：系统在演示时效果出色，但在生产环境中却分崩离析。这并不是因为他们实现协作协议的方式不对，而是因为协议本身就是问题所在。

多智能体 AI 具有一种直观的吸引力。复杂的任务应该被分解为并行的工作流；专门的智能体应该处理专门的工作；编排器（orchestrator）将它们组合在一起，整体就会大于部分之和。这种直觉是错误的——或者更准确地说，它还不成熟。研究表明，在已研究的执行追踪中，多智能体系统在生产环境中的实际失败率在 41% 到 86.7% 之间。这不是调优问题，而是结构性问题。