Vercel 如何破解智能体构建难题：Andrew Qu 与 Eve 框架的演进

Brief Description

Andrew Qu, Vercel's chief of software, explains how an internal data-science agent evolved from a large prompt into a practical, file-system-based system and eventually informed the design of Eve, Vercel's agent framework. The talk argues that useful business agents need durable execution, appropriate tools, and company-specific knowledge—not merely a general-purpose model.

Table of Contents

• Why Vercel began building agents
• The data-team problem and the first experiments
• From specialized agent chains to a single context-rich agent
• The file-system-agent breakthrough
• Turning repeated practice into skills
• Eve: a framework for building agents
• Why company knowledge matters

Why Vercel Began Building Agents

I'm Andrew, Vercel's chief of software. My work spans internal engineering, external experiments, and building libraries, frameworks, and technologies at the frontier. Vercel began by helping people ship websites and web applications without having to manage infrastructure that does not improve the application itself. That infrastructure can scale to a million users and back down to zero.

What people want to build has changed. They began by building pages, and increasingly they want to build agents. Vercel has been on a similar journey to make agents and agentic applications easier to build. The AI SDK lets developers replace hundreds of lines of provider-specific code with a single line while retaining a common model interface across providers. Vercel has also built tools for model fallbacks, secure code execution, better pricing for inactive work that is waiting on responses, durability, and resumability.

This talk is about an experiment from roughly a year earlier that led to an explosion of agent work at Vercel and, eventually, to a new product. Bill Gates once imagined a computer on every desk and in every home. That prediction may have sounded contrarian in 1980, but it now feels ordinary. The question Andrew and Vercel's CTO asked was whether there could instead be an agent on every desk.

At that point, agents were mainly used for coding and other technical workloads, though their use was beginning to extend into design, product management, and other functions. The models were less sophisticated than they are now, but the team wanted to explore what they could accomplish.

The Data-Team Problem and the First Experiments

Andrew spoke with teams across Vercel—marketing, sales, finance, and legal—and asked what they disliked most about their jobs. The most compelling problem came from the data team. It was lean while Vercel was growing quickly, and it was absorbing increasing volumes of customer, analytics, metrics, and sales data.

When someone in marketing or sales had a question about a customer or a product, the data-science team had to interrupt its work, write a query, process it, analyze the result, and return with a recommendation. Repeating that loop was damaging productivity. The data team did not want to spend every day writing ad hoc queries, so Andrew and Vercel's VP of Data tried to find a better operating model.

The first version followed the natural first instinct for applying AI: create a very large prompt. A person asks a question, passes it to a language model, and receives a response. Andrew asked for a dump of the Snowflake schema, pasted it into a system prompt with a question, then copied the generated SQL and ran it himself. The goal was simply to test whether the models could write valid SQL when given a reasonable structure.

The experiment created some confidence. The models were not yet very good, but better context and more guardrails might make them useful. A data scientist does much more than produce one query: they understand the question, explore the semantic layer, identify join patterns, execute SQL, revisit it if it fails or is too expensive, and finally report the result through visualizations, paragraphs, retrospectives, or other formats.

From Specialized Agent Chains to a Single Context-Rich Agent

Andrew and the VP of Data mapped those phases to individual agent workloads. The second version of the data-science agent, called D0, routed a question through a query agent, a planning agent, an execution agent, and additional stages. Each agent had a tightly focused system prompt and tools limited to its task. For example, a planning agent might have a tool for reading entity YAML and another for searching schemas; it used only those capabilities until it had an answer to pass onward to the SQL and reporting steps.

That arrangement improved the end-to-end loop. It reduced the need for a person to copy SQL, run it, and return with a report. But it also hit limits. The team concluded that the system needed one agent with the larger context, able to manage its own state and look back at what it had done. Rather than receiving only a summary and a small excerpt from the preceding agent, a single agent could plan, build, execute, report, reflect on failures, explore further, and correct itself.

The team became confident enough to share this powerful system with a small number of trusted people, avoiding critical workloads. The response was disappointing: users found it awful. The team thought it was succeeding on about 30 percent of its evaluations, but it had not anticipated many real questions. Manually mapping every scenario would not scale.

The File-System-Agent Breakthrough

The next major change came with Claude Code and Opus 4.5. Compared with Vercel's homegrown agent, the combination answered many questions with remarkable consistency. When the team tried to understand why, they found that the key unlock was a file system.

The agent had a minimal set of familiar tools: list files, read files, and run Bash, plus a few additions for the data-agent use case. It could use tools it was well trained to use, explore the environment, and write work where needed. Instead of being constrained by a highly prescriptive tool sequence, it could explore emergent behavior.

That observation led the team to rebuild the approach in a more Claude Code-like form. The agent ran in a sandbox that contained the full semantic layer. It could inspect files, run commands, and write files while Vercel added the tools needed for its specific environment. The shift from a single agent, to a Claude Code SDK-style approach, to a general file-system agent tailored to the use case was a major leap.

The evaluation score roughly doubled. The implementation was simple: give the agent a Bash helper, attach it to a sandbox, and attach files it can read, write, and execute. Once the system began answering many questions that had previously failed, Andrew wrote a blog post about it; in the week it was published, it accounted for 70 percent of Vercel.com traffic.

Turning Repeated Practice into Skills

The next question was how to handle the recurring patterns in agent use. After Vercel made the agent more widely available, it received thousands of queries each day: customer metrics, sales metrics, number metrics, npm downloads, product lookups, billing information, and more. Many had the same shape. There are only so many ways to aggregate information, look up a product, or retrieve billing data.

Vercel built a recurring job that takes recent queries and distills them into a skill. At the time of the talk, it had roughly 100 skills ranging from aggregations to person-specific lookups. The approach was effective because a fresh agent run normally starts with no established context beyond the semantic layer and its system prompt. A skill gives it contextual knowledge and prior work from the start.

This progression is common: begin with something simple, add complexity gradually, and eventually reach a system that can be shipped to production. At each stage of building the agent, someone at Vercel who was curious about agents tried to fork D0 and build their own version. Each stage revealed a better practice that had not been known before. The team wondered whether people could start from the latest insight instead of beginning with a simple prompt and reinventing the same principles.

Eve: A Framework for Building Agents

The resulting idea was to build the Next.js of agents. Next.js made web development simpler through file-system-defined infrastructure: developers write files following conventions and the framework determines where they belong. Pages go to a CDN, serverless functions have their destination, and caching sits in between. The team believed agent building could work the same way.

Developers should need only a skills folder, a tools folder, and a channels folder, declare the pieces simply, and let the framework assemble an agent. Two weeks before the talk, Vercel released Eve, an agent framework intended to make the path from a sample template to a ready agent straightforward. Users can add custom knowledge, custom tools, and integrations with the channels they already use.

An agent, in this model, has a runtime and channels. The runtime needs durability, isolated execution, access to different models, and connections. Eve was designed with open source in mind, allowing adapters for PostgreSQL, OpenAI's Responses API, Docker, and other connectors. It is also easy to deploy on Vercel, where the corresponding pieces use products Vercel has built over years: Vercel Workflows for durability, Sandbox for secure execution, and Vercel Connect for generating short-lived OIDC tokens for connections.

Vercel rewrote the D0 agent in Eve while building the framework. The code became a simple file-system arrangement of system instructions, a few skills, and a few tools—easy to compose into a real agent and easy to iterate on. Before the full release at Vercel's London event, the team gave it to several beta customers.

One close partner, Aura, rebuilt its agent, described as a small Claude-like system for testing people's services. It visits websites, installs them, and tries to use them. Aura saw fewer steps, better success, and better insights from building its agent with Eve than from using an off-the-shelf Claude Code. Deploying Eve to Vercel also provides observability: agent runs, tool calls, individual steps, estimated costs, and possible optimizations.

Eve is available at eve.dev. Users can clone it, begin from a template, deploy it, or self-host it when needed.

Why Company Knowledge Matters

Andrew's hope is that more business-specific agent use cases will emerge. Before building D0, Vercel tested many well-funded vertical-agent startups that could connect to a company's Snowflake instance and run queries. The team found that what made its own agent effective was very specific company knowledge.

Vercel is a web-based company with many customers that have websites and web properties. Its data relationships go far beyond generic querying: the agent needs to know what to query, when to query it, and how entities connect. Off-the-shelf agents can be useful to try, but organizations that want the greatest benefit should build their own agents and add as much company-specific knowledge as possible.

At Vercel, around 20 agents had found reasonable product-market fit, covering work from marketing retrospectives and identifying outreach targets to creating a first redline when legal sees a new negotiation, as well as the data-science agent for data queries. These agents save time. The data team has become more productive and can spend more time improving Snowflake performance, adding missing data sources, and filling gaps it previously could not address because it was busy writing queries.

Andrew's conclusion is that it has never been easier for a large, medium-sized, or small company to automate work it does not want to do or work that consumes too much time. Parts of HR, finance, and sales can be automated with agents, and he presents Eve as Vercel's preferred way to build them.