--- layout: post.njk source: https://yage.ai/share/agent-platform-state-ownership-20260718.html speaker: yage.ai title: |- Agent 的基础能力正在收敛，产品化平台却分成了三条路 date: '2026-07-18' summary: 文章探讨了Agent基础能力趋同后，产品化平台在状态管理和工作流处理上的三种主要路线。这三种路线分别是先部署运行环境（如Koyeb），先确定长期身份（如Cloudflare Durable Objects），以及先定义任务执行步骤（如Vercel Workflow）。核心思想是选择最适合自身需求的基础能力模型，而非简单地对比功能列表。 area: PAI category: ai-workflow tags: - agentic-platform - state-management - workflow-routing - deployment-strategy people: [] companies_orgs: [] products_models: - Claude Code - Codex - Cursor - OpenCode - Koyeb - Cloudflare - Vercel media_books: [] draft: true status: evergreen --- ## 基础能力越像，产品化平台越让人困惑 Claude Code、Codex、Cursor 和 OpenCode 已经越来越像一类可以替换的工作环境。它们当然各有差异，但从用户的工作边界看，核心能力正在接近：让模型读写文件、运行命令、调用工具、查看报错，再根据结果继续修改。我们在《AI 脚手架正在商品化，人的工作变成判断边界》中讨论过，这些通用执行能力正在成为标准配置。 写代码的 Agent 工具越来越像，开发者自然会觉得，让 Agent 在线上为客户工作的云平台应该也差不多。似乎只要列一张表，比一比谁有 Sandbox、memory、streaming、定时任务和 tool loop，就能选出答案。 真正准备把 Demo 交给用户时，事情却变得更乱了。同样叫 memory，有的平台指业务数据库里的记录，有的平台指某位客户助手的局部状态，还有的平台记录一项任务已经完成的步骤。同样叫 Sandbox，它可能跟着后台程序使用，也可能只是一次任务的临时工作目录。Feature 名称越来越像，真正写代码时却完全不是一回事：数据存在哪里，下一条消息发给谁，任务中断后从哪里继续，各个平台给出的答案不同。 这不是一张更详细的功能表就能解决的问题。差别从创建 Agent 的第一步就开始了：有的平台先让你部署一个程序，有的平台先让你确定这个 Agent 是谁，还有的平台先让你写下任务要经过哪些步骤。三种起点会继续决定状态放在哪里、中断后恢复什么，以及应用最终在哪个位置形成依赖。 ## 三种平台，第一步就不一样 假设你要做一个客服 Agent。客户发来问题，Agent 查资料、运行工具，遇到敏感操作时等待人工批准，几小时后再继续。无论看哪家产品页，你都能找到状态保存、实时输出、定时任务和 Sandbox。差别要到开始实现时才出现。 第一种平台让你先部署一个 Service 或 Worker。程序怎样运行，平台替你负责；这位客户是谁、任务做到哪里，由你的应用和数据库记录。 第二种平台让你先给这位客户的 Agent 一个固定 ID。以后客户再发消息，平台负责把消息送回管理同一个 Agent 的地方。局部状态和连接也跟着这个 ID 走。 第三种平台让你先把工作写成一连串步骤：查资料、调用工具、等待批准、生成回复。平台记录这一次任务走到了哪一步，条件满足后再继续。 所以市场上出现了三种有代表性的路线：先运行程序，先确定 Agent 是谁，或者先定义任务怎样往下走。Koyeb、Cloudflare 和 Vercel 分别清楚地展示了这三种起点。 第一步不同，后面找回状态的方法也不同。当前进程结束以后，有的平台只能重新启动计算，业务状态要由应用去外部数据库查询；有的平台可以根据 Agent ID 找回这个对象的局部状态；还有的平台根据一次任务的运行编号找回执行进度，再根据另一个编号恢复 Sandbox 文件。这才是三条路线更深的分界。 实现同一个客服 Agent 时，三种平台分别要求开发者先部署程序、确定 Agent 身份或写下任务步骤 ## Koyeb：先有运行环境，再把 Agent 放进去 把客服程序放在 Koyeb 上，平台首先保证的是这段程序继续运行。代码更新或者实例故障以后，旧实例可能被替换。新实例会启动，但不会带回原来的进程、内存和网络连接。它也不知道某张工单处理到了哪一步。 所以应用需要拿自己的工单 ID 或客户 ID，去 Postgres 等外部数据库读回业务状态，再继续处理。这就是 Koyeb 路线的分工：平台恢复计算，应用恢复具体 Agent 的工作进度。 在 Koyeb 里，这段客服程序以 Service 的形式运行。接收网页请求的程序和专门处理后台任务的 Worker，都由平台负责网络、健康检查、实例替换和扩缩容。Koyeb Services 文档描述的就是这套运行方式。Koyeb 无需理解“工单”或“客户助手”是什么，它只需要把程序运行起来。 这种方式保留了传统 SaaS 的开发习惯。全局查询、跨客户统计和数据修复仍围绕中心数据库进行；特定 Python 依赖或原生程序也可以一起放进容器。容器化业务代码通常可以在其他环境复用，但迁移时仍要重新处理部署配置、网络和配套托管服务。 ## Cloudflare：先有长期身份，再让事件找到它 把同一个客服 Agent 放在 Cloudflare 上，平台首先记住的是：这条消息属于哪位客户。A 客户再次发来消息时，系统根据他的 Agent ID，找到之前保存的局部状态，再把新消息送到管理这个 Agent 的地方。即使 Agent 已经休眠，ID 仍然不变。 Cloudflare Agents 状态文档描述了这套方式。每个 Agent 都可以有自己的 SQLite 状态。程序不需要永远在线，下一条消息到来时，平台仍能通过同一个 ID 找回它。底层负责这件事的能力叫 Cloudflare Durable Objects。 这个 ID 解决了“消息该送给谁”，但不会自动解决所有消息顺序。Agent 等待模型 API 返回时，其他事件仍可能交错执行；网络重试也可能把同一条消息送来两次。Cloudflare Durable Objects 实践指南解释了这个边界。应用仍要过滤重复请求、识别顺序，并确保同一个动作重试两次不会重复扣款或发信。 麻烦会在全局查询时出现。每位客户的状态分别放在自己的对象里，开发者不能用一条普通 SQL 查询直接关联全部数据。产品要统计所有工单、统一对账或批量修改，通常还需要 Postgres 或对象存储，把各个 Agent 产生的关键信息汇总起来。 ## Vercel：先有一次任务，再决定下一步执行什么 把客服任务放在 Vercel 上，平台首先记住的是这张工单走到了哪一步。Agent 查完资料，准备退款时需要等待人工批准。程序可以先停下来，不必让服务器一直空转。批准结果回来以后，任务从后面的步骤继续。 负责记录这段进度的是 Vercel Workflow。Vercel Workflow 概念文档说明，平台会保存已经完成步骤的输入和输出。普通 Function 调用本身不保存这些进度，真正可以恢复的是一次 Workflow run。 如果 Agent 还要隔离运行代码或命令，可以使用 Vercel Sandbox。Sandbox 能保存文件系统快照，之后恢复代码目录和中间文件，但不会恢复此前的内存、活动进程、网络连接或函数调用栈。它保存的是工作目录，不是那段仍在运行的程序。 因此，一张客服工单会同时出现几套编号：业务数据库里的工单 ID、Workflow run ID，以及需要时使用的 Sandbox ID。平台不会自动知道它们属于同一件事。vercel/workflow#2376中的临时建议，是由应用在外部数据库保存业务编号与 Workflow 编号的关系，避免同一业务意外启动多个任务。 文件可以恢复，也不代表应用永远能找到它。Vercel 自己的 eve 项目曾把 Sandbox 名称与部署版本绑定，结果新版本部署后失去了旧工作目录的正确引用。vercel/eve#508反映的是应用怎样关联不同组件，不是底层快照丢失。我们此前分别讨论过 Vercel AI Cloud 的产品整合和 eve 把 Agent 定义成目录的思路；把这些能力放在一起看，Vercel 的中心仍是一项用户发起、可以暂停和恢复的任务。 ## 进程结束以后，平台靠什么找回状态 这里说的状态不只是数据库里的一段文字。下一条消息该送给谁，定时任务该唤醒谁，工作目录恢复到哪个版本，一项任务已经完成哪些步骤，都属于产品继续运行所需的状态。 Koyeb 恢复的是计算服务。实例退出后，平台根据 Service 配置启动替代实例；具体 Agent 的身份、任务进度和业务记录，则由应用使用自己的业务 ID 去外部数据库和队列中找回。计算由平台恢复，业务状态由应用恢复，这种不对称正是这条路线的特点。 Cloudflare 原生认识 Agent ID。这个 ID 同时用于消息路由和局部 SQLite 状态。对象休眠或当前实例结束后，新事件仍可以通过同一个 ID 找回对应状态。应用仍要另外处理全局查询、重复消息和业务顺序。 Vercel 原生认识的是一次执行中的不同编号。Workflow run ID 找回已经完成的步骤，Sandbox 或 snapshot ID 找回文件系统，真实工单则保留自己的业务 ID。应用需要保存这些编号之间的关系，平台不会自动把它们合成同一个长期 Agent。 进程结束以后，Koyeb、Cloudflare 和 Vercel 分别通过 Service 配置、Agent ID 以及 Workflow 与 Sandbox 编号恢复不同部分 所以，“平台面向什么”并不只是一种产品理念。它直接决定平台原生保存哪部分状态，又用什么编号把它找回来。依赖也会在同一个位置形成：Koyeb 的部署配置与外部服务，Cloudflare 的对象 ID 与局部状态，Vercel 的步骤边界与多套运行编号。 ## 三种路线不是三选一 计算服务、长期身份和任务执行，并不是三个互斥的完整产品。它们描述的是三类不同责任：服务需要继续运行，对象需要保持同一个身份，任务需要记住已经做到哪里。一套真实系统可能同时需要三者。 因此，混合部署是自然选项。网页和审批流程可以使用面向 Workflow 的平台，需要长期连接和特殊运行环境的 Worker 可以放在容器服务上，少数真正需要固定身份和局部协调的对象也可以单独管理。与此同时，订单、权限、账目和最终业务记录仍应进入标准数据库或对象存储，不能让运行时状态代替产品的数据总账。 组合越多，运维边界也越多。团队需要维护多套发布流程、权限、账单和监控。专用能力省下的开发工作超过这些新增成本时，混合部署才有意义。否则，较少的平台和清楚的数据边界通常更容易验证。 ## 选平台以前，先判断 Agent 在你的产品里是什么 平台选型的第一步，可以从三个问题开始：产品首先需要运行一类长期程序吗？它的中心是大量反复接收消息、各有局部状态的长期对象吗？还是用户启动一项工作，程序需要等待数小时或数天，再从后面的步骤继续？ 这三个问题分别指向计算服务、长期身份和任务执行。更具体的检查方法是：当前进程消失以后，你准备用哪个 ID 找回工作所需的状态？如果答案是自己的业务 ID、Agent ID 或 Workflow run ID，系统的主要责任边界也就清楚了。 最后的判断不应只来自顺利跑通的 Demo。可以在运行时替换实例，向同一对象重复发送事件，在 Workflow 等待期间发布新版本，或者在 Sandbox 工作到一半时中断会话。随后检查服务是否继续，消息是否重复处理，任务是否从正确步骤恢复，业务记录是否仍然完整。 Agent 的通用执行能力确实正在收敛，但从 Demo 到产品之间仍有一层选择，统一 feature list 无法替你回答：你准备让平台长期管理什么？看清这个问题，Koyeb、Cloudflare 和 Vercel 才重新变得可以比较。