吉安市网站建设_网站建设公司_内容更新_seo优化

原文https://www.oreilly.com/radar/ai-mcp-and-the-hidden-costs-of-data-hoarding/

一、全文英译

模型上下文协议(MCP) 的确非常实用。它为人工智能工具开发者提供了一种标准化的方式来调用函数并访问外部系统的数据。无需为每个数据源构建自定义集成，即可通过任何人工智能都能理解的通用协议公开数据库、API 和内部工具。

然而，过去一年里，我一直在观察各个团队采用 MCP 的情况，并发现了一个令人担忧的模式。开发人员使用 MCP 将他们的 AI 助手快速连接到他们能找到的所有数据源——客户数据库、支持工单、内部 API、文档库——并将所有数据一股脑地导入到 AI 的上下文中。由于 AI 足够智能，能够从海量数据中筛选出相关信息，一切似乎都运行良好！但出乎意料的是，这实际上是一个问题。AI 能够轻松处理海量数据并给出合理的答案，因此没有人会质疑这种方法。

这就是数据囤积。就像那些囤积癖患者，他们不把任何东西扔掉，直到家里堆满杂物，无法居住一样，数据囤积也可能给我们的团队带来严重问题。开发人员发现，他们可以获取远超人工智能所需数量的数据，而且几乎不需要任何规划或结构，而人工智能足够智能，能够处理这些数据并给出良好的结果。

当连接新的数据源只需数小时而非数天时，许多开发人员便不会花时间去思考哪些数据真正适合当前上下文。这最终会导致系统运行成本高昂且难以调试，同时，整整一批开发人员也因此错失了学习构建健壮且易于维护的应用程序所需的关键数据架构技能的机会。

团队如何学会囤积
Anthropic 于 2024 年底发布了 MCP，旨在为开发者提供一种通用的方式，将 AI 助手连接到他们的数据。开发者无需维护单独的连接器代码来让 AI 访问来自 S3、OneDrive、Jira、ServiceNow 以及内部数据库和 API 等的数据，而是使用同一套简单的协议，即可为 AI 提供各种类型的数据，并将其纳入其上下文。MCP 迅速获得了广泛认可。Block 和 Apollo 等公司纷纷采用，世界各地的团队也开始使用它。MCP 的优势显而易见；在许多情况下，过去需要数周才能完成的将数据源连接到 AI 代理的工作，现在只需几分钟即可完成。但这种速度的提升也并非没有代价。

我们先来看一个例子：一个小型团队正在开发一款人工智能工具，用于读取客户支持工单，按紧急程度进行分类，提供回复建议，并将其路由到相应的部门。他们需要尽快完成开发，但却面临一个挑战：客户数据分散在多个系统中。经过一个上午的争论，讨论应该提取哪些数据、哪些字段是必要的以及如何构建集成之后，一位开发人员决定直接构建，创建了一个单一的getCustomerData(customerId)MCP 工具，将他们讨论过的所有内容——来自三个不同系统的 40 个字段——整合到一个大型响应对象中。令团队欣慰的是，它成功了！人工智能顺利地处理了所有 40 个字段并开始回答问题，无需再进行任何讨论或决策。人工智能完美地处理了所有新数据，每个人都觉得项目走上了正轨。

第二天，有人添加了订单历史记录，以便助手可以解释退款流程。很快，该工具就提取了 Zendesk 状态、CRM 状态、相互矛盾的资格标记、三个不同的姓名字段、四个“最后上线”时间戳，以及完整的对话记录，并将所有这些信息合并到一个不断增长的数据对象中。

即使数据量不断增长，助手仍然能够给出看似合理的答案。然而，在回答诸如“这位顾客是否符合退款条件？”这类简单问题之前，模型现在必须先筛选成千上万个无关的令牌。最终，团队构建的数据架构将真正的信号淹没在噪声之中。额外的负载给人工智能带来了压力，使其难以从中提取信号，这可能导致严重的长期问题。但他们当时并未意识到这一点，因为人工智能仍然能够给出看似合理的答案。在接下来的几周里，随着数据源的增加，人工智能的响应速度开始变慢。他们甚至出现了无法追溯到任何特定数据源的“幻觉”。原本非常有价值的工具，如今却变成了维护起来极其困难的难题。

团队陷入了数据囤积的陷阱：他们早期取得的快速成功营造了一种文化，在这种文化中，人们只是把他们需要的任何东西都塞进上下文中，最终它变成了一场维护噩梦，而且随着他们添加更多数据源，情况只会变得更糟。

那些永远无法培养的技能
关于数据架构的观点和开发者一样多，而且通常任何一个问题都有多种解决方案。几乎所有人都认同的一点是，它需要谨慎选择和丰富的经验。但正因为应用程序存储、传输、编码和使用数据的方式多种多样，数据架构也一直是争论的焦点，尤其是在团队内部。

我们大多数人都会在某个时候陷入“以防万一”的思维模式，尤其是在职业生涯初期——我们会把所有可能需要的数据都收集起来，以防万一，而不是在真正需要的时候才获取所需数据（这正是“即时”思维的反面）。通常，我们在设计数据架构时，会面临一些直接的限制：访问便捷性、数据大小、索引、性能、网络延迟和内存使用。但是，当我们使用 MCP 为 AI 提供数据时，我们通常可以暂时绕过许多此类权衡取舍。

我们越是处理数据，就越能更好地设计应用程序如何使用数据。初级开发人员接触数据越多，就越能通过实践了解为什么例如系统 A 应该负责客户状态，而系统 B 应该负责支付历史记录。良性辩论是这一学习过程的重要组成部分。通过所有这些经验，我们逐渐培养出对“数据过多”的直觉，并学会如何处理那些棘手但至关重要的权衡取舍，这些取舍会在整个项目中造成摩擦。

MCP 可以消除这些权衡取舍带来的摩擦，让我们完全避免做出这些决定。如果开发人员只需几分钟就能完成所有连接，那就无需讨论或争论实际需要什么。人工智能似乎可以处理你提供的任何数据，因此代码可以顺利发布，而不会有人质疑其设计。

如果缺乏数据设计选择方面的实践经验，开发者就无法构建关于数据所有权、系统边界以及不必要数据迁移成本的关键思维模型。他们把宝贵的学习时间都花在了建立联系上，而不是构建架构上。这正是我所说的“认知捷径悖论”的另一个例证——那些简化开发的AI工具反而会阻碍开发者培养有效使用这些工具所需的技能。仅仅依赖MCP来处理混乱数据的开发者，永远无法学会识别数据架构何时出现问题，就像仅仅依赖Copilot或Claude Code等工具生成代码的开发者，永远无法学会调试这些工具生成的代码一样。

数据囤积的隐性成本
团队使用 MCP 是因为它行之有效。许多团队会精心规划 MCP 数据架构，即使是那些陷入数据囤积陷阱的团队，最终也能成功交付产品。但 MCP 仍然相对较新，数据囤积的隐性成本需要时间才会显现。

团队往往直到需要扩展应用程序时才会发现数据囤积方式的问题。最初一百次查询时几乎感觉不到成本的臃肿上下文，在处理数百万次请求时就会变成云账单上的一笔不小的开支。传递给 AI 的每一个不必要的字段都会累积成本，而每一次 AI 调用都需要为这些冗余数据付费。

任何处理过紧耦合类的开发者都知道，一旦出现问题（而问题总是会发生的），调试起来就困难得多。你往往最终只能采取“乱枪打鸟”式的修复方式，这种令人头疼的情况是，修复一个小问题需要对代码库的多个部分进行连锁修改。囤积的数据也会在人工智能系统中造成类似的“技术债务”：当人工智能给出错误答案时，追踪它使用了哪个字段，或者它为什么更信任某个系统而不是另一个系统，往往非常困难，甚至是不可能的。

数据囤积还存在一个团队常常忽略的安全隐患。通过 MCP 工具暴露的每一条数据都可能成为潜在的安全漏洞。如果攻击者找到未受保护的端点，他们就能获取该工具提供的所有数据。如果您囤积数据，那么泄露的将是整个客户数据库，而不仅仅是完成任务实际需要的三个字段。陷入数据囤积陷阱的团队会发现自己违反了最小权限原则：应用程序应该只访问所需的数据，而不能访问更多。这会给整个组织带来巨大的安全风险。

如果数据囤积的极端案例蔓延到整个公司，你可能会发现组织中的每个团队都在构建自己的数据海洋。支持团队有一个客户数据版本，销售团队有一个，产品团队又有一个。同一个客户，在不同的AI助手那里看起来完全不同。新团队加入后，看到哪些做法似乎有效，便照搬照抄。这样一来，数据囤积就成了公司文化的一部分。

每个团队都认为自己很务实，快速交付，避免了关于数据架构的不必要争论。但这种囤积模式会在组织内蔓延，就像技术债务会在代码库中蔓延一样。起初规模很小，易于控制。但不知不觉中，它就会无处不在。

避免陷入数据囤积陷阱的实用工具
如果团队从未经历过数据囤积带来的问题，那么引导他们摆脱这种习惯就非常困难。开发人员非常务实——他们希望看到问题的证据，而不是在一切运行良好的情况下，参与关于数据所有权和系统边界的抽象讨论。

在《敏捷学习》一书中，我和詹妮弗·格林（Jennifer Greene）探讨了团队如何抵制变革，因为他们知道目前的做法行之有效。对于试图让开发人员做出改变的人来说，这种抵制或许显得不理智，但实际上，当有人从外部要求他们放弃现有的有效方法，转而采用未经证实的新方法时，团队的抵触情绪是相当合理的。正如开发人员最终会明白，花时间进行重构从长远来看可以提高开发速度一样，团队也需要从中吸取同样的教训，即在管理控制流程（MCP）工具中进行精心设计数据。

以下一些做法可以使这些讨论更容易，首先要设定一些即使是持怀疑态度的开发人员也能看到其价值的限制条件：

围绕动词而非名词来构建工具。创建checkEligibility()或getRecentTickets()代替getCustomer()。动词会迫使你思考具体动作，并自然而然地限制其适用范围。
谈谈如何最大限度地减少数据需求。在任何人开发 MCP 工具之前，都应该先讨论一下，为了让 AI 完成工作，他们需要提供的最小数据量是什么，以及可以进行哪些实验来确定 AI 的真正需求。
将读取操作与推理过程分开。在设计 MCP 工具时，应将数据获取与决策制定分开。一个findCustomerId()仅返回 ID 的简单工具使用最少的令牌——如果简单的 API 调用就能满足需求，甚至可能根本不需要是 MCP 工具。然后，getCustomerDetailsForRefund(id)它只提取决策所需的特定字段。这种模式能够保持对上下文的关注，并清晰地表明用户是否试图获取所有数据。
将浪费情况可视化。反对数据囤积的最佳论据就是展示浪费情况。追踪获取的令牌与使用的令牌的比例，并将其显示在人人可见的“信息辐射器”式仪表盘上。例如，当一个工具获取了 5000 个令牌，但 AI 的答案中只引用了其中的 200 个时，所有人都能看出问题所在。一旦开发者意识到他们为从未使用的令牌付费，他们就会非常积极地去解决这个问题。
快速嗅探数据囤积情况

工具名称是名词(getCustomer())而不是动词(checkEligibility())。
从来没有人问过：“我们真的需要所有这些田地吗？”
你无法分辨哪个系统拥有哪条数据。
调试需要对多个数据源进行调查取证。
你的团队在构建 MCP 工具之前很少或从不讨论其数据设计。
期待
MCP 是一款简单却功能强大的工具，对团队而言潜力巨大。但由于它可能是整个应用程序架构的关键支柱，因此在 MCP 层面引入的问题会波及整个项目。小小的错误会在后续阶段造成巨大的后果。

MCP 的简洁性本身就助长了数据囤积。即使是经验丰富的开发者，也很容易落入这个陷阱。但我最担心的是，现在正在学习这些工具的开发者可能永远无法理解数据囤积的问题所在，也无法培养出在数据边界方面做出艰难抉择所带来的架构判断力。我们的职责，尤其是作为领导者和高级工程师，就是帮助所有人避免落入数据囤积的陷阱。

当你像对待任何核心界面一样认真对待 MCP 决策时——保持上下文简洁、设定界限、随着学习不断重新审视它们——MCP 就能保持其应有的状态：成为你的 AI 和驱动它的系统之间简单可靠的桥梁。

二、解读：5问5答（抓重点、讲人话、可落地）

1）这篇文章的核心观点是什么？

MCP 把“接入数据源”的成本降得极低，于是团队很容易走向一种反模式：把所有数据都塞进上下文，让模型自己筛。短期看“能跑、还挺准”，长期会演变成成本、性能、可维护性、安全的综合灾难，而且会让团队错过训练数据架构判断力的机会。

2）为什么“看起来有效”的数据囤积，反而更危险？

因为它延迟暴露问题：

• 模型在早期确实能从噪声里找信号，让团队误以为架构没问题；
• 等到请求量上来、数据源更多、字段互相矛盾时，才出现：响应变慢、定位困难、幻觉变多、云账单飙升。
  它的危险在于：错误不是立刻发生，而是逐步固化成文化与技术债。

3）数据囤积会带来哪些“隐性成本”？

文章强调四类成本会在规模化时集中爆发：

• 费用成本：每次调用都为不必要 token 付费；量大时非常可观。
• 性能成本：上下文越臃肿，模型筛选越慢，且更难稳。
• 调试成本：答案错了，很难追溯“到底用了哪个字段/信哪个系统”。
• 安全成本：暴露面扩大，违背最小权限；一旦泄露就是“整库泄露”，而不是“3 个字段泄露”。

4）团队为什么会“学会”囤积？根因是什么？

根因不是“懒”，而是激励结构 + 工具摩擦消失：

• MCP 让接入变得太快，团队不再被迫讨论“谁是数据权威”“边界在哪里”“最小字段集是什么”；
• 早期成功形成路径依赖：能交付就继续加字段；
• 初级开发者因此缺少在真实约束下做取舍的训练，架构能力反而被 AI 工具“绕过去”了（文中称为“认知捷径悖论”）。

5）如何用最小改动避免掉进陷阱？有哪些可执行的做法？

文章给了四个非常可操作的抓手：

• 动词命名工具：用checkEligibility()代替getCustomer()，强迫定义动作与边界。
• 先讨论最小数据需求：上线前就问“完成任务最少需要什么字段”，并用实验验证。
• 读与推理分离：先findCustomerId()（极小返回），再getCustomerDetailsForRefund(id)（只取决策字段）。
• 把浪费可视化：统计“获取 token vs 实际引用 token”的比例，上墙；一旦大家看见钱在烧，推动力会自然出现。