在AI代理能读取一个收件箱之前，别急着把它接入12种工具

每周都有人给我展示一个代理架构图，上面有九个MCP服务器、一个向量数据库、三个备选模型和一个队列。然后我问它在星期二实际做什么，诚实的回答是“总结我的邮件并草拟几封回复”。你不需要为此建造死星。我为创始人和小团队构建AI工作流。到目前为止大约三十多个。失败模式几乎从来不是模型本身。而是人们为他们想象中一年后会用到的代理进行架构设计，而不是他们本周真正会信任的那个。以下是模式。有人在第一天就把模型接入他们拥有的所有工具——邮件、日历、CRM、Slack、Notion、Stripe——因为“上下文为王”，更多的连接感觉就像更智能。然后它把某件事搞错了一点点，他们无法判断是十二个集成中的哪一个提供了错误的上下文，也无法调试，所以他们关掉了整个系统。原本用来让它变聪明的表面积恰恰让它变得不可审计。最近几个月的三个例子。独立创始人，B2B。想让她的代理“接入一切”。实际上推动进展的是一处连接做得好：模型通过MCP读取她的真实邮件和日历，在已经拉取之前对话和她的空闲时间后起草回复，排入队列一键发送。一个集成。她每天都在用。我们本来打算在第二周构建的CRM同步从未被错过。代理机构老板。想要一个跨邮件、Slack和项目管理工具的大型代理。他需要的是模型能看到真实对话线程和真实日历，并提议不发生冲突的时间——他自己发送。我们删除了三个标签页的舞蹈，而不是人类。他不再每天花一小时在日历拼图游戏上。两人初创公司。想要“AI接触我们所有通讯”。最终存活的是会议前准备：这是谁，我们上次说了什么，日历上有什么，在会议前汇总到一个地方。一条读取路径。零自主性。这是他们现在拒绝放弃的功能。这些都不是创始人要求的那个庞大的多工具代理。每一个都胜过了它，因为一个窄范围代理通过MCP接入真实上下文——而不是一个宽范围代理在十个半连接的表面上猜测——是那个在三个月后仍然有效的代理。为什么最大化集成的代理总是在生产中失败。你连接的每个工具都是代理可能自信犯错的地方，也是你现在必须审计的地方。价值不在于连接的数量，而在于你实际使用的那个连接是否看到真实上下文而不是过时的副本。一个通过MCP读取你实时收件箱和日历的模型会击败一个有六个集成、每个都提供一小时前快照的模型。广度在演示中感觉像杠杆。在生产中它只是更多失败的方式和更少知道原因的方式。那些现在默默获胜的人并没有构建章鱼。他们选择了一个高价值的表面——通常是收件箱和日历——通过MCP将模型连接到真实的东西，这样它就能看到实际上下文，并在任何离开系统的事务上保留人类。就这样。Slashy MCP、连接到邮件的Claude、Superhuman的AI、原生助手——那些无聊的单表面设置是星期二仍然在运行的。而那十二个工具编排图则是悄悄被关掉的。如何实际决定要连接什么。在你将代理接入另一个工具之前，在纸上回答这些问题： - 这个连接是读取真实的、实时的来源，还是过时的副本？通过MCP的实时上下文胜过十个缓存集成。如果是快照，它会以你无法预测的方式出错。 - 你能审计哪个连接产生了给定的输出吗？如果你无法将错误的回复追溯到其来源，你就无法修复它——你只能关闭它。 - 这个工具是赚到了它的位置，还是因为它演示效果好才存在的？大多数代理需要一个做得深入的表面，而不是八个做得肤浅的表面。 - 没有你，你会信任它在这里行动吗？如果不会，这是一个读取连接，用于提供草稿，而不是自主行动。相应地进行布线。 如果你是一个构建者：你会通过将一个表面连接到真实上下文并把它做对来交付更多存活的东西，而不是通过争抢最大的集成数量。第一批人淹死在自己的架构中。做那个代理在星期四仍然有效的人，因为它只需要在一件事情上正确。运营者、构建者、任何针对真实工具运行代理的人——你每天使用的东西与演示过的东西相比，实际连接数量是多少？你拆掉了什么？真的想听听实战故事。