一个 CLI，五种能力：为什么打包式 Agent Runtime 更胜一筹

用一句话概括这张图：一次安装、一个 CLI，就能为你的代理现有工作流补上缺失的能力层。

你的 AI 编码代理已经很聪明了。它能规划多步骤重构、理解架构，还能生成可用于生产环境的高质量代码。但当它需要产出文本之外的内容时 —— 比如图片、视频、网页搜索结果，或者一个已经发布的页面 —— 它就停下来了。

不是因为它没有能力，而是因为它手里没有工具。

传统做法是分别配置各种服务：这里接一个图像 API，那里接一个视频 API，再配一个搜索用的 MCP 服务器、一个云存储桶、一个部署平台。每一项都要单独管理 API Key、单独配置、单独维护。代理还没写出一行代码，你就已经先花了一个小时搭基础设施。

其实有更好的方式：一个 CLI，一套凭证，五种能力。

每个代理都需要的五种能力

1. 图像生成

你的代理在做一个落地页，它需要一张首屏主视觉图。如果没有图像生成能力，它只能写完 HTML 然后停住 —— 等你手动去找图，或者自己做图。

有了图像生成，代理就能自己把图做出来：

anycap image generate --model nano-banana-2 --prompt "modern SaaS dashboard" -o hero.png

一条命令，直接返回 CDN URL。你不需要选模型、不需要管理 API Key，也不需要做格式转换 —— 这些都由 runtime 处理。

2. 视频生成

产品演示、功能讲解、社交媒体内容。你的代理可以写脚本，但它并不能直接把视频做出来。除非你给它这项能力。

视频比图片更复杂 —— 涉及渲染时间、格式限制和模型选择。专门的视频能力可以把这些复杂度都封装到一条命令后面。

3. 有依据的网页搜索

你的代理可能需要知道 React 20 改了什么、竞争对手怎么定价，或者最新的安全公告说了什么。如果没有搜索能力，你就成了代理与互联网之间的人肉中介。

有依据的搜索返回的是带引用、经过综合整理的答案，而不只是一个 URL 列表。代理拿到的是可执行的信息，不是还得自己解析的原始 HTML。

4. 云存储

代理会生成文件，那这些文件该放到哪里？云存储可以把输出变成可分享的成果物 —— 图片变成 CDN URL，构建结果被保存并带版本，报告也能在任何地方访问。

没有存储能力，代理就只能把所有东西都保存在本地。上传还得你自己来做。

5. 发布

一个能把页面做出来、却不能部署上线的代理，只完成了一半工作。发布能力把整个闭环补齐 —— 代理在同一次会话里完成页面构建、素材生成、存储和发布。

为什么“一个 CLI”很重要

另一种方案 —— 为每种能力分别配置独立的 MCP 服务器 —— 会带来很多隐藏成本：

从 token 账本来看，这非常划算：少掉 22,000 个工具描述 token，意味着你的 200K 上下文窗口里有多出 11% 的空间可以真正用于工作。在一个 50 轮的代理会话中，这相当于多出 15 轮高产交互。

“一个 CLI”在实际工作中到底意味着什么

这意味着代理的工作流会从这样：

代理：“我需要一张首屏主视觉图。”
人工：配置 API Key，搭 MCP 服务器，测试连接。
代理：调用图像工具。
代理：“现在我需要竞争对手的定价信息。”
人工：再配置一个 API Key，再搭一个 MCP 服务器。
代理：调用搜索工具。
代理：“现在把构建结果存起来。”
人工：配置 S3 凭证，搭第三个 MCP 服务器。

变成这样：

代理：调用图像工具 → 获得 CDN URL ✅
代理：调用搜索工具 → 获得带引用的结果 ✅
代理：调用存储工具 → 资源上传完成 ✅
代理：调用发布工具 → 页面上线 ✅

不需要人工介入，也不需要你盯着基础设施善后。代理能把自己做出来的东西直接交付出去。

架构是什么样的

打包式能力运行时位于代理和各项服务之间：

代理（Claude Code、Cursor、Codex）
    │
    ▼
能力运行时（单一 CLI）
    │
    ├── 图像生成（Nano Banana 2、Seedream 5）
    ├── 视频生成（Veo 3.1、Kling 3.0、Seedance）
    ├── 网页搜索（有依据、带引用）
    ├── 云存储（Drive、CDN）
    └── 发布（静态页面部署）

代理只需要对接一个入口。模型选择、身份验证、速率限制和输出格式化都由 runtime 负责。不管调用的是哪一种能力，代理拿到的始终都是结构化 JSON。

适合哪些人和团队

当你符合下面这些情况时，打包式 runtime 最有价值：

• 你是独立开发者，想立刻用上能力，而不是先花一小时配置
• 你在小团队中工作，没有专门的 DevOps 去维护工具基础设施
• 你的代理需要 4 种以上能力，多个 MCP 服务器带来的 token 膨胀已经是现实问题
• 你正在做原型验证，不想让工具配置打断节奏
• 你重视一致性 —— 一个输出格式、一种报错模式、一套学习成本

如果你只需要一两个专用工具，比如内部数据库或 Slack 机器人，那么单独部署 MCP 服务器仍然是更合适的选择。但对于每个代理都需要的五种能力 —— 图像、视频、搜索、存储、发布 —— 把它们打包起来，才能真正让配置成本消失。

真正的优势：你的代理能把事情做完

说到底，最重要的指标不是配置时间，也不是 token 数量，而是代理能不能把开始的事情完整做完。

没有这些能力时，代理只能写代码，然后把剩下的工作交给你。最后一公里 —— 图片、素材、部署 —— 还是得你来解决。

有了 capability runtime，代理就能接管整条流水线：代码、素材、存储、部署。你需要审核的是结果，而不是中间步骤。

这就是“帮你工作”的代理，和“替你把工作做完”的代理之间的区别。

最后更新：2026 年 5 月

延伸阅读

• 如何为真实世界的 AI 工作流选择 Agent Runtime — 评估什么情况下打包式 runtime 更适合你的工作流组合。
• 什么是 Agent Runtime？ — 先从打包式 runtime 背后更广义的执行环境概念开始了解。
• 什么是 Capability Runtime？ — 理解这种将搜索、媒体、存储和发布打包在一起的 runtime 子类型。
• AnyCap 与自建 MCP 服务器对比 — 对比打包式 runtime 的简单性与 DIY 集成扩张带来的复杂性。