接口要按模型会慢会断来设计

MCP 和 API 不是一回事，但也不是二选一。 API 管的是软件之间怎么说话：一套端点、请求和响应的规矩，让一个应用能取到另一个系统的数据，或者触发它的功能。MCP 管的是另一层，它给 AI 应用一套标准，去发现并使用外部工具、数据和资源。简单分：API 把能力暴露给软件，MCP 负责让 AI 知道有哪些能力、怎么用上。 真正的麻烦在后面。AI 一旦坐到 API 后面，那套"问一句、答一句"的老模型就不好使了。 推理可能比一次请求能保持打开的时间还久。也可能跑到一半断掉。断了还得能重试。三件事每一件都在动摇 HTTP 那套一问一答的假设。 这反过来改变了 API 本身该怎么设计。能想到的方向是四条：异步任务、后台工作进程、持久化的状态、可预期的接口契约。 前三条好理解。推理慢，就不能让请求一直挂着等，得先收下、再异步算完。中途会断，就得让任务能重入，而不是从头再来。状态留在内存里，进程一重启就没了，所以要落成持久化的。真正容易被忽略的是第四条：接口契约要可预期。 我自己判断一个接口能不能扛住模型，标准只有一条：请求还开着的时候，这活干得完吗？ 干不完就得异步。异步就得把状态存下来。状态存下来，就得说清楚"什么时候算完成"。三步推下来，接口的形态基本就定了。 过去我们设计接口，默认对面是个浏览器：快、会立刻回、断了就重来一次。模型完全不是这个性子。它慢，它可能干到一半停住，它需要有人替它记住上下文。把这三件事当成默认前提，而不是异常情况，接口设计的第一版就不会跑偏。 这一条对做工具的人尤其要紧。你给 AI 开放一个接口，等于同时接受了它的三个毛病。倒过来想，如果你的接口必须靠"它很快就回"才能工作，那它其实还没准备好接 AI。 给 AI 用的接口，得按"它会慢、会断、会重试"来设计，而不是按"对方是浏览器"来设计。这条比争论 MCP 和 API 谁更重要。