为什么架构师总在重复历史

梯形图转SCL | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace

每个架构师都太熟悉这样的时刻：你坐在会议室里，有人提到一个新范式，房间里突然充满了那种火花——那种说"终于！这将修复多年来所有错误！"的火花。

当人们开始低声谈论"自主代理"时，我就是那样的。不是好莱坞那种失控接管地球的类型。不，是我们今天拥有的版本——能够自己弄清楚事情、做出决定、对变化做出反应而不需要人看管的软件设置。或者至少这是承诺。

你知道吗？一旦我开始玩它们，我就上瘾了。就像当年微服务崭新闪亮的时候一样——在我们意识到它们也带来了自己的"惊喜"集合之前。那种似曾相识的感觉对我来说很强烈，因为我经历了从SOA到REST到容器编排的每一次炒作浪潮。每一次，同样的事情都会发生：海报更新了，流行语改变了，但底层的问题？它们通常会留下来参加重聚巡演。

每隔一段时间，就会出现一个新的协议，实际上感觉像是简化了某些东西，而不是添加另外十层。MCP正是如此。把它想象成代理的USB端口。插入，以通用方式交谈，交换上下文，然后就可以开始了。

这意味着当你开始用MCP连接代理时，你会遇到我们二十年前遇到SOA时遇到的同样障碍——你闪亮的新协议仍然取决于你的旧系统暴露内部的程度。

那时，我们告诉每个人发布API、使用存储库、定义契约、保持一切干净和有文档。发生了什么？嗯……只能说现实有其他计划。我见过"API存储库"是SharePoint墓地的公司。其他人有一个巨大的文件夹，里面装满了自2011年某人离开公司后就没有人碰过的WSDL。我甚至没有涉及那些"API文档"是三页PDF，开头是"进行中"的地方。

现在MCP加入其中，这种诱惑又回来了。当API不存在或尚未就绪时，消息契约不明确，时间紧迫，连接到原始数据库突然看起来像是天赐之物。你可能甚至有一个通用的MCP服务器来访问你需要的数据库——问题解决了？

规则保持不变：你需要在记录系统上有适当的API。没有其他办法。

但事务一致性？仍然是个难题。在许多系统中，你会发现没有真正的两阶段提交，没有可用的补偿API，"最终一致性"悄悄地破坏了业务规则。值得注意的是，这通常是一个深思熟虑的设计权衡，植根于CAP定理——你不可能同时拥有完美的一致性、可用性和分区容忍性。但这种权衡需要有意识地做出，而不是偶然陷入。有人必须坐下来，设计流程，决定失败时会发生什么，并确保一切保持有意义。就像微服务疯狂发展的日子，团队忘记了分割数据库是容易的部分，协调状态是困难的部分。

有一个SOA时代从未必须面对的风险。当代理从记录系统读取时，这些数据流入LLM上下文窗口——可能包括客户PII、财务记录或机密业务数据。如果你的LLM是云托管的，你需要明确回答数据驻留问题。通过工具结果的提示注入是一个真正的攻击面：恶意构造的数据库记录或API响应可能操纵代理的推理。企业架构师需要以与任何数据处理边界相同的严格程度对待代理上下文管道。

两种开销并不完全相同。ESB开销主要是延迟——编组、路由、模式验证。LLM开销是不同的野兽：它增加延迟、每次调用成本和非确定性。最后一个在架构上很重要：ESB很慢但可预测。LLM推理步骤可以为相同的输入产生不同的输出，这对重试逻辑、幂等性和SLA设计有真正的影响。

代理不会改变这一点。如果有任何变化，它们会扩展链，因为它们涉及依赖于在正确时间接收特定信号的推理步骤。你不仅仅是在链接系统——你是在链接决策。

追踪哪里出了问题？只能说你的日志关联技能会得到锻炼。跨代理链的分布式追踪——关联LLM调用、MCP工具调用和后端API之间的跨度——是当今该领域最难的操作问题之一，它恰好呼应了十年前微服务追踪的挣扎。工具正在赶上，但还没有到位。

在传统架构中，基础设施成本是相对可预测的——服务器、许可证、网络出口。你可以为它们做预算。在代理系统中，你引入了每个令牌成本作为运行时变量。每次LLM调用都要花钱，在多代理链中，代理生成子代理，上下文窗口随着每一步而增长，这些成本可能会以让经验丰富的团队也感到惊讶的方式复合。

团队对此没有先验的心理模型。失控的代理循环不仅仅是性能问题——它是一个计费事件。

SOA承诺存储库，其中每个服务都是可发现的且描述得当。在一些公司，这存在了一段时间……直到没有人再更新文档，存储库变成了一堆谎言。

MCP存储库会做得更好吗？这是开放性问题。工具更好，概念更简单。自动生成的MCP服务器模式和LLM辅助文档是有希望的步骤——它们降低了保持事物更新的激活能量。但它们并没有消除对人类判断的需求，即服务实际做什么、它的边缘情况是什么以及什么时候不应该调用它。

代理解决了一些古老的烦恼：它们适应得更好，更优雅地处理混乱的数据，减少工作流的脆弱性，并解释格式和协议而不需要无尽的自定义代码。但大的结构性问题？那些仍然需要我们去解决。

• API仍然需要存在
• 安全仍然需要注意——包括上下文窗口卫生和提示注入防御
• 一致性仍然需要思考
• 可用性仍然倍增
• 成本治理是一个需要从零开始构建的新学科
• 跨代理链的可观察性很困难，工具仍在成熟
• 架构边界仍然重要
• 捷径仍然有害……至少从长远来看

"把MCP想象成闪亮的新桥。它坚固、优雅，确实有用。但这座桥仍然需要连接到道路。如果道路上满是坑洞，桥也不会拯救你。"

更聪明的方法是将代理视为合作伙伴，可以帮助你从现有系统中获得更多价值。而不是作为再次拆解一切的理由。

但你我都知道真相，因为我们经历过：没有银弹——只有更好的工具、更好的习惯，以及艰难学到的教训。

代理和MCP将我们向前推进了一大步。它们打开了我们以前无法打开的大门，它们让我们的系统感觉不那么脆弱。但它们并没有消除旧的挑战。它们给了我们更聪明的方法来应对它们——以及一些我们真正从未面对过的新挑战。

所以是的，我们越来越接近了。不完美。不神奇。但好多了。

在观看了三十年炒作周期的起起落落之后，这足以让我保持兴趣。

原文链接: Why Architects Keep Repeating History

汇智网翻译整理，转载请标明出处