给Agent喂数据：MCP按需拉取还是预取？实战对比

当Agent需要外部数据，预取还是MCP？

构建一个线索资格审核Agent时，如何让它获取公司背景信息是一个绕不开的架构选择。Reddit上一位开发者分享了自己的困境：当前版本用n8n在调用Claude之前从Coresignal的API预取公司和员工数据，筛选好字段后注入prompt。这种方式简单直接，你能精确控制模型看到什么。但Coresignal同时支持MCP，于是另一种路径浮现出来——让Claude在工作过程中按需请求特定信息。两种方案各有拥趸，而这位开发者想知道：是否存在一个清晰的决策边界，还是应该走混合路线？

这个问题的价值远超单个项目。随着Agent从演示走向生产，外部数据接入策略直接影响成本、延迟和输出质量。本文结合该讨论中的实战细节，拆解预取与MCP的适用场景，并给出可操作的选型框架。

预取模式：可控性优先

预取的本质是“先取后问”。Agent在推理开始前，就已经拿到了一组固定的公司数据字段。Reddit原帖中，开发者通过n8n从Coresignal拉取公司和员工信息，再决定哪些字段进入prompt。

这种模式的优势在于输入一致性。每次Agent看到的字段集合相同，输出更可预测，调试也更简单——出问题时，你只需检查那一组固定数据。对于字段数量有限、结构稳定的场景（比如仅需公司规模、行业、融资阶段来判断线索质量），预取足够高效。

代价是可能加载冗余信息。如果Agent面对1000家公司，而每家只需要其中5个字段，预取仍然可能拉回20个字段的数据，造成token浪费和额外API调用成本。更隐蔽的问题是：预取阶段你尚不知道Agent会在推理中“关心”什么，只能凭经验预设字段，容易遗漏关键上下文。

预取（Prefetching） 在LLM Agent语境下，指的是在模型开始推理之前，由外部编排层（如n8n、自定义后端）提前调用数据源API，将结果格式化后作为上下文注入prompt。这与传统Web缓存中的预取概念共享同一逻辑：用提前付出的成本换取后续步骤的确定性和速度。在Agent架构中，预取通常由工作流引擎控制，而非模型自身决策，因此输入边界完全由开发者定义。它的对立面是运行时按需获取（lazy fetching），后者把数据请求的时机和内容交给模型判断。理解这一区分是评估两类方案的前提：预取把复杂度前移到设计阶段，按需拉取则把复杂度后移到运行时。

MCP按需拉取：灵活性换复杂度

MCP（Model Context Protocol）让模型在推理过程中主动发起数据请求。在原帖场景中，Claude可以决定“我需要这家公司的最近融资信息”，然后通过MCP调用Coresignal获取，而不必一开始就加载全部数据。

这解决了预取的核心痛点：按需加载。Agent只为当前账户真正需要的信息付费，token消耗更精准，也避免了无关字段干扰推理。对于公司研究这种探索性较强的任务，MCP允许Agent根据初步发现决定下一步查什么，更接近人类研究员的节奏。

但灵活性有代价。每次MCP调用都引入额外延迟，对于需要低延迟响应的线索审核流程，这可能成为瓶颈。控制权也从开发者转移到模型——你无法完全预知Agent会发起哪些查询，prompt工程和成本预估变得更复杂。此外，MCP调用的可靠性依赖工具描述的质量，如果模型误解了某个工具的用途，可能发起无效查询。

Model Context Protocol（MCP） 是由Anthropic提出并开源的标准化协议，用于让LLM应用以统一方式连接外部工具和数据源。它采用客户端-服务器架构：MCP Server封装某个数据源（如Coresignal的公司数据库）的能力，暴露为若干带描述的工具（tools）和资源（resources）；MCP Client运行在Agent侧，将这些工具的描述注入模型上下文，模型据此决定何时调用哪个工具、传什么参数。相比为每个API写定制集成代码，MCP提供了可复用的接口层。需要注意的是，MCP本身不保证调用质量——工具描述是否清晰、参数schema是否严谨，直接决定模型能否正确使用。这也是文中提到“可靠性依赖工具描述质量”的技术根源。

混合路线：务实的选择

原帖开发者提出的混合方案值得认真对待：小规模核心字段预取 + 按需MCP补充。

把每次推理都必需的字段（如公司名称、行业、员工规模）预取注入，保证基础上下文稳定；同时开放MCP通道，让Agent在需要深入信息（如特定高管背景、近期新闻）时自行拉取。这样既保留了预取的可控性和低延迟优势，又用MCP覆盖长尾需求。

实现上，关键在于界定“核心字段”的边界。一个实用的判断标准是：如果某个字段在80%以上的推理中都会被用到，就预取；如果使用率低且体积大，就交给MCP。原帖中开发者提到Apollo负责联系人 enrichment，公司研究侧才需要这个决策，这提示我们按数据域拆分策略——不同来源的数据可以采用不同接入方式。

决策框架与实战建议

综合原帖讨论，可以提炼出一个四维判断框架：

字段确定性：字段集合固定且已知，倾向预取；需要探索式查询，倾向MCP。

延迟敏感度：线索审核等实时流程对延迟敏感，预取更稳；后台研究任务可容忍MCP往返。

成本结构：API按调用计费且字段多，MCP避免浪费；flat-rate或数据量小，预取更简单。

调试需求：早期验证阶段预取更易复现问题；成熟后引入MCP提升效率。

原帖开发者尚未给出最终答案，但这个问题的讨论本身说明：Agent数据接入没有银弹。从预取起步、用混合路线渐进引入MCP，可能是风险最低的路径。毕竟，让Agent先跑通再优化，比一开始就追求完美架构更实际。

Token经济性是评估两种方案时容易被低估的维度。预取模式下，注入prompt的每个字段都计入输入token，且在多轮推理中可能被重复计费；若预取20个字段而实际只用到5个，冗余比例高达75%。MCP模式下，工具定义本身也占用上下文（通常每个工具数百token），但实际数据只在调用时进入上下文，且可按需裁剪返回字段。因此成本比较不能只看API调用次数，还要把上下文token消耗、工具schema开销和调用往返次数纳入同一模型。对于高频、小字段场景，预取往往更经济；对于低频、大字段或长尾查询，MCP的按需特性更能压缩无效开销。

常见问题

MCP是否适合所有Agent场景？ 不适合。字段固定、延迟敏感的流程用预取更简单可靠。MCP的优势在探索性任务和长尾数据需求。

混合方案会不会增加维护负担？ 会，但可控。核心是明确划分预取字段和MCP工具边界，避免两者重叠导致逻辑混乱。

如何评估预取字段是否合理？ 观察Agent推理日志中实际引用的字段比例，逐步剔除低使用率字段，或将其迁移到MCP通道。