86 篇博文 含有标签「architecture」

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

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

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。

这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。

每个上线 LLM 功能的团队都会经历相同的演变曲线。一开始，你硬编码一个 OpenAI API 调用。然后加上重试逻辑。然后有人问你花了多少钱。然后某个周五下午供应商宕机了，于是你开始构建网关。

这并非偶然。推理网关是一种自然涌现的架构模式——应用与 LLM 提供商之间的中间件层，将限流、故障转移、成本追踪、提示词日志和路由整合到一个统一的关卡中。它是 AI 时代的负载均衡器，如果你在生产环境中运行模型，你要么已经有了一个，要么正在不知不觉中构建一个。

你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。

六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。

这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。

多智能体系统（Multi-agent systems）是基于一个承诺而诞生的：多个并行的专业化智能体协同工作，产生的结果会优于任何单个智能体。但这个承诺隐藏了一个前提——当智能体给出不同答案时，你知道如何调解它们。大多数团队在发现自己无法调解时，往往为时已晚。

天真的做法是取输出的平均值，或者选择多数票答案，然后继续。在实践中，如果所有智能体共享相同的训练分布，多智能体系统会通过多数表决放大它们的共同错误，而不是抵消错误。一个总是听从最有信心智能体的系统，会盲目跟随那个最过度自信的智能体。而一个将所有分歧都交给 LLM 裁判（LLM judge）处理的系统，会继承该裁判的 12 种已被记录的偏差类型。仲裁问题比看起来要难，如果处理不当，你可能会在一周内遇到四次生产事故。

一个能够总结合同、起草产品规范和编写 SQL 查询的通用 AI 智能体确实令人印象深刻——直到你将其部署到放射科，并发现它建议了听起来合理但却与患者实际药物过敏史相冲突的剂量。这种失败并非幻觉问题，而是架构问题。

大多数智能体演示中隐含的假设是：足够强大的基础模型加上广泛的工具集，就等于在任何领域都胜任的智能体。而在实践中，这一假设与生产现实之间的差距，正是导致患者受伤、诉讼产生以及实验结果不可复现的根源。通用智能体是一个合理的起点，而非终点。

大多数构建 AI agent 的团队都将 harness —— 处理工具路由、上下文管理和推理循环的支架 —— 视为绑定到单个容器的长寿命、有状态进程。当容器出现故障时，会话就会终止。当你需要更换更好的模型时，必须重新启动所有内容。当你想要水平扩展时，会遇到瓶颈：每个 harness 实例对其自身状态了解过多，导致无法互换。

解决方案不是更智能的 harness，而是一个无状态的 harness。

“AI 界的 USB-C” 这个比喻很吸引人。但在涉及负责生产环境运行的这一关键层面时，这个比喻又是错误的。Model Context Protocol (MCP) 确实解决了一个真实存在的问题——即 AI 模型与外部系统之间爆发式增长的 N×M 次自定义集成——但“演示效果良好”与“在周一早高峰流量下既不泄露数据也不耗尽延迟预算”之间的差距，比大多数团队预期的要大得多。

MCP 在 2024 年 11 月发布后的五个月内，服务器下载量增长了 8,000%，到 2025 年 4 月，每月 SDK 下载量已达到 9,700 万次。这种采用速度既是其真正实用性的标志，也是一个警告：大多数服务器在投入生产时，团队并未完全理解他们所构建的基础。

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

2025 年，近 65% 的企业级 AI 失败归因于多步推理过程中的上下文偏移（context drift）或记忆丢失 —— 而非模型能力问题。如果你的智能体（agent）在执行长任务时决策失误或失去连贯性，最可能的原因不是模型，而是上下文窗口（context window）中的内容。

“上下文工程”（context engineering）一词正在迅速普及，但其背后的学科内容是具体明确的：即在智能体运行轨迹的每一个推理步骤中，主动、刻意地管理进入和离开 LLM 上下文窗口的内容。它不是一段提示词（prompt），而是一个由工程师设计、供智能体遍历的动态信息架构。上下文窗口的作用类似于 RAM —— 有限、昂贵，且如果你不进行刻意管理，就会出现抖动（thrashing）。

Google DeepMind 在 2025 年末发布的一项研究分析了 5 种架构和 3 个大语言模型（LLM）家族中的 180 种多智能体配置。在讨论部分被掩盖的一个发现是：与单智能体基准相比，非结构化多智能体网络将错误放大了高达 17.2 倍。不是修复错误——而是放大错误。智能体们自信地在彼此的幻觉基础上进行构建，创造出回声壁效应，使每个独立模型的失败模式显著恶化。

这是多智能体对话框架核心的悖论。赋予它们强大力量的特性——智能体进行协商、批判、委派和修订——如果缺乏周密设计，也正是让它们变得危险的原因。理解基于对话的编排（orchestration）与传统流水线链式调用（pipeline chaining）之间的区别，是正确使用这两者的第一步。