现在，几乎所有做 Agent 的团队都能使用差不多的大模型，但真正“用起来很快”的 Agent 并不多。差距往往不在模型本身，而在模型之外的工程设计：每次请求发送多少上下文、哪些任务可以并行执行、Agent 工作时用户能看到什么，以及整个处理链路中的每一部分部署在哪里。
本文里的 Agent 有意使用了一套很普通的组件：来自 Nous Research 的开源 Agent 框架 Hermes、一台大约相当于 12美元的 Basic Droplet 规格的小型云主机，以及所有通过无服务器推理调用 DigitalOcean 推理引擎完成的模型请求。这个 Agent 示例叫 Foodie，用户只需要在 Telegram 里发一句话——“上海两天，只吃正宗本帮菜，预算不高”——它就会返回一份经过检索整理的美食行程，以及一份带旁白的语音导览。美食只是这里的测试场景，真正有价值的是它背后的工程方法：两个经常被混淆的速度指标、在无服务器推理架构下分别可以通过哪些手段优化它们，以及什么时候无服务器推理不再是合适的选择。
架构
Telegram (long polling, no webhook, no public IP)
│
▼
Hermes Gateway ── runs as a launchd/systemd service
│
▼
Hermes Agent loop
├── SOUL.md ................ personality + intake rules
├── foodie-trail skill ..... workflow: intake → research → plan → narrate
├── Linkup (MCP, stdio) .... live web research
└── text_to_speech tool .... ElevenLabs → Telegram voice notes
│
▼
DigitalOcean Inference Engine (Serverless Inference)
https://inference.do-ai.run/v1 (OpenAI-compatible, 70+ models)
注意，这套系统实际上承担了两类完全不同的工作，而它们对硬件的要求也完全不同。Agent 程序本身很轻量：接收一条消息、调用几个 API，然后在不同组件之间传递文本，任何一台价格不高的小型服务器都能完成这些工作。真正昂贵的是运行大模型，但模型推理并不会发生在 Agent 所在的机器上，因为每一次模型请求都会发送到推理引擎，并按照 Token 计费。这也是为什么整套方案运行成本很低：小型主机每个月只需要几美元，而 GPU 相关成本只发生在模型真正执行推理的那些时间里。
这套架构中有两个特点，会影响后面的所有优化。第一，因为模型并不和 Agent 部署在一起，所以 Agent 几乎可以运行在任何地方。 Telegram Bot 使用 Long Polling，因此不需要任何来自外部网络的主动连接，也不要求 Agent 所在的机器暴露公网 IP。Agent 跑在笔记本电脑上，和跑在 Droplet 上基本没有区别。第二，所有模型调用都经过一个 OpenAI 兼容端点。 推理引擎通过 https://inference.do-ai.run/v1 这个统一端点提供 Anthropic、OpenAI、Meta、DeepSeek、Qwen 等模型，并且只需要一个访问密钥。更换模型或切换模型来源，只是修改配置，而不是进行一次完整迁移。
快速完成基础配置
完整的安装步骤可以参考 DigitalOcean 的无服务器推理文档和 Hermes 文档，所以这里主要介绍几个关键步骤和常见问题。
首先，在控制面板的无服务器推理页面创建一个模型访问密钥，并在其他组件依赖它之前确认密钥能够正常工作：
curl https://inference.do-ai.run/v1/models \
-H "Authorization: Bearer $DO_MODEL_KEY"
这个接口会返回当前 DigitalOcean 支持的模型目录。相比任何博客文章，包括本文，都应该优先相信这个接口返回的结果，因为模型目录会发生变化。在本文这套环境中，接口返回的信息显示：anthropic-claude-5-sonnet 支持 1,000,000 Token 的上下文窗口以及 128,000 Token 的最大输出，同时还提供了价格更低的 anthropic-claude-haiku-4.5，适合用于开发测试。
给 Agent 选择模型时，有三个原则。
首先，优先考虑 Tool Calling 的可靠性，而不是只看 Benchmark 分数；对于 Agent 来说，一个经常调用错 Function 的模型，很可能直接“编”出一家餐厅，而不是老老实实调用搜索工具去查询。
其次，检查模型的最大输出长度；模型目录中有一些能力很强的模型，最大输出只有 8K Token。如果一份完整行程在中途被截断，最终表现出来的问题会很难排查。开发阶段最好保留一个价格较低的模型，因为你可能会把同一组测试 Prompt 反复跑几十遍。
另外，调试时应该暂时跳过模型目录中的 router:* 条目；你需要确保每次运行都使用同一个模型。
接下来是框架连接：安装 Hermes 后，将 DigitalOcean 端点配置成一个自定义 OpenAI Compatible Provider，并明确选择 Chat Completions 模式，而不是使用自动检测。然后通过内置 Gateway 接入 Telegram，具体可以参考 Hermes Telegram 文档。本文这套环境里有两个坑值得提前知道：第一个是，在聊天里更换模型之后，需要执行 /model <id> --global，否则 Gateway 下一次启动时仍然会使用旧模型；第二个是，因为 Bot 可以在宿主机上执行命令，所以应该保留默认的“拒绝未知用户”策略，并且只允许自己的 Telegram ID 使用。
搜索和语音同样通过配置完成，而这里的两个选择也值得解释。
这里选择 Linkup，是因为餐厅信息更新很快，Agent 需要一个能够返回实时结果和来源、并且适合机器调用的搜索 API。其他类似搜索 API 也可以用同样方式接入。之所以使用 MCP，而不是自己写一套集成，是因为 Hermes 会在启动时自动发现 MCP Server 提供的工具，并像自己的原生工具一样注册它们。以后如果需要更换搜索平台，只需要改配置。在 ~/.hermes/config.yaml 中：
mcp_servers:
linkup:
command: "npx"
args: ["-y", "linkup-mcp-server"]
env:
LINKUP_API_KEY: "${LINKUP_API_KEY}"
supports_parallel_tool_calls: true
tts:
provider: "elevenlabs"
elevenlabs:
voice_id: "pNInz6obpgDQGcFmaJgB"
model_id: "eleven_multilingual_v2"
密钥保存在 ~/.hermes/.env 中。${LINKUP_API_KEY} 会在运行时自动填充，因此即使你把配置文件分享出去，也不会同时暴露密钥。而 supports_parallel_tool_calls: true 这一行，则是在告诉框架这些搜索调用可以安全地同时执行。后面会看到，这一行最终成为整个优化过程中最明显的提速手段。
真正的产品，其实是两个 Markdown 文件
前面的基础设施和配置，任何人都可以照着复制。真正决定 Agent 行为的，是两个文件，而文件里的这些规则其实同样会影响速度。
SOUL.md 用来定义 Agent 的性格，而“性格”本身就是产品需求的一部分。Foodie 会在开始规划之前先判断用户的饮食偏好，例如街头美食爱好者、Biryani 原教旨主义者、素食者、咖啡馆爱好者或者 Fine Dining 用户。如果可以根据已有信息推断出来，就直接判断；如果确实无法判断，最多只问一个问题。这个“一次最多问一个问题”的限制有两个好处：首先，如果 Bot 在真正开始做事之前不停追问，用户很容易失去耐心直接退出；其次，每多问一次，整条流程都会更慢，因为 Agent 要等待用户回复，然后再通过一次模型调用处理这条回复，之后才能真正开始工作。
foodie-trail Skill 则负责定义整个工作流，而其中最重要的其实是各种限制。每份行程最多执行 6 次搜索，并且搜索 Query 已经提前写进 Skill；如果没有搜索结果确认，就不能把某家餐厅写进最终结果；每天的路线都集中在一个适合步行的区域；旁白脚本控制在 60～90 秒，并且按照适合朗读的方式写，而不是长文章的写法。限制搜索次数的意义不仅仅是省钱：一个没有边界的 Agent 会不断搜索，希望消除自己的不确定性，而每多执行一轮搜索，就意味着增加一次完整的“搜索 + 模型处理”周期。提前把 Query 写进 Skill，相当于把开放式搜索变成一组固定步骤，而且这些步骤可以并行执行。
怎么让 Agent 真正变快？
决定 Agent 使用体验的主要有两个指标，而且它们的优化方式完全不同。第一个是 Time to First Token（TTFT，首 Token 延迟），也就是用户发出请求后，要等多久才能第一次看到输出。第二个是总生成时间，也就是完整结果全部生成需要多久。把这两个指标混在一起，是做这类性能优化时最常见的错误。
首 Token 延迟
对于一次模型调用来说，TTFT 主要由网络时间和 Prefill 组成。Prefill 指模型真正开始生成内容之前，读取和处理输入所花的时间。输入越长，Prefill 通常越慢。所以，TTFT 很大程度上取决于一个非常直接的问题：你到底给模型发送了多少内容？
检查每一轮请求中到底进入了多少上下文。 Agent 框架通常会悄悄把很多东西叠加到每一次请求里：System Prompt、Personality 文件、Memory、Skill 列表和聊天历史。Hermes 会保持 Skill 描述简短，而且只有在真正需要某个 Skill 时才加载完整文件，这会有所帮助。开发者自己也要控制上下文：例如，Foodie 的 Personality 文件控制在 400 词以内，Skill 描述保持简短，会话允许自动重置——本文这套环境在闲置 4 小时后会重置。相比只携带 6K Token 上下文的会话，一个已经积累了 30K Token 历史记录的长对话，会明显增加等待时间。所以，框架里的上下文压缩和闲置重置，不只是节省 Token，也是在减少延迟。
让推理时间匹配任务复杂度。 Reasoning Model 在真正开始输出之前，可能先花几秒进行用户完全看不到的推理。如果这一轮任务只是从一条消息里提取城市和饮食偏好，那么这部分等待基本没有必要。Hermes 可以在运行时调整推理强度（/reasoning low）。比较合理的原则是：真正涉及规划的步骤值得多一些推理时间；简单确认或者信息提取则不需要。
先快速返回一句话。 对于本身比较耗时的任务，这是一个非常重要的技巧。在第一次搜索之前，让 Skill 先返回一句：“Biryani 爱好者，班加罗尔，两天。正在帮你查。”完整行程并不会因此更早生成，但应用不再给人“卡住了”的感觉。很多时候，用户所谓的“快”，主要就是这种感知上的及时反馈。
保持连接处于热状态。 在生产环境中，最好把 Agent 主机部署在离推理端点较近的区域，并让长时间运行的 Gateway 尽可能复用现有连接。工具调用也是一样：npx 第一次调用 Linkup Server 时会经历冷启动，因此对于需要快速使用的工具，可以适当放宽框架的进程回收策略。理想情况应该是，一天中的第一次搜索承担一次冷启动成本，而不是每一次新对话的第一次搜索都重新冷启动。
后台任务使用小模型。 Hermes 会把一些辅助任务交给单独配置的模型处理，例如给对话自动命名、压缩聊天历史。这些任务用户根本看不到，因此完全可以交给 Haiku 这一档的小模型。这样可以让这些后台调用既便宜又快，同时避免影响用户真正等待的主流程。
总生成时间
完整流程实际上是一条 Pipeline：读取请求、搜索、编排行程、编写旁白、生成音频、返回全部结果。这里真正的性能收益，并不是继续把某一次调用再挤快一点，而是重新设计整条 Pipeline。
把搜索并行执行。 这是单项收益最大的优化。假设有 6 次搜索，每次需要 3～5 秒，如果串行执行，总时间大约需要 20～30 秒；如果这些搜索被标记成可以安全并行，那么整体耗时大致只取决于其中最慢的那一次。一个实用原则是：任何只读工具，如果同一个任务中会调用两次以上，都值得检查是否能够标记为并行安全。同时，Query 应该设计成彼此独立，如果后一条 Query 必须依赖前一条结果，它们就无法真正并行。
限制 Agent 循环次数，并提前写好 Query。 这样研究阶段究竟需要多久，是由你决定的，而不是由 Agent 自己决定。
先返回文字，再生成音频。 用户可以先阅读 Day 1 的文字，同时后台继续生成对应的音频。从用户角度看，文字返回的时候，答案其实已经到了。另外，按天分别生成音频，也比一次生成一个大文件更合理，原因有两个：它可以和用户阅读文字的时间重叠；如果某一天 TTS 失败，只会损失当天的音频，而不会让整份结果全部失败。
有意识地控制输出长度。 生成时间会随着输出长度增加，所以在很多 Agent 场景里，啰嗦本身就是一种性能问题。Foodie 的 Skill 规定每一天的输出控制在大约 15 行以内。相比完全不限制长度时模型自然生成的内容，这个规则大致能把写作时间缩短一半，而且在手机上也更容易阅读。如果确实需要长文本，还应该确认模型的最大输出长度能够在一次请求中完整生成。撞到最大 Token 限制后，再通过第二次请求继续生成，是效率最低的方式之一。
优化之前先测量。 实际瓶颈往往不在最开始怀疑的位置。在本文这套系统中，最后发现真正拖慢整体流程的并不是模型，而是家庭网络上传音频的速度。
什么时候应该离开无服务器推理？
这个 Agent 当前运行在无服务器推理上，而在目前这个规模下，这并不是一种妥协，而是正确选择。如果为了它专门租一台 GPU 服务器，比如一个价格约为 3.39美元/小时的 H100 GPU Droplet，每个月大约需要花 $2,500，但真正的大模型推理已经全部通过推理引擎按 Token 完成，因此这块 GPU 大部分时间都会处于闲置状态。一台 $12 的 Droplet 就能完成 Agent 主机需要做的同样工作。
自托管模型通常会在四种情况下开始变得合理。第一种是成本：当每个月的 Token 账单已经接近租用 GPU 的固定成本时，计算方式就会开始发生变化，因为对于一个自托管开放权重模型来说，只要硬件配置不变，无论它服务一次请求还是一百万次请求，固定 GPU 成本都基本一样。第二种是数据控制：如果因为合规或隐私要求，Prompt 不能离开自己的基础设施，那么无论按 Token API 有多便宜，它都不再是可选方案。第三种是自定义模型：如果你已经针对自己的业务场景 Fine-tune 了模型，并且拥有自己的权重，那么就需要一个地方来部署它。第四种是延迟：公共 API 提供的是一种典型性能水平，而自己的专属端点则可以让你更好地控制性能下限。
当然，自托管的缺点同样明显。固定费用不会因为没有流量而停止，而且 GPU Droplet 即使关机，也仍然会继续计费。同时，模型 Serving Stack 也需要自己维护，包括 vLLM 或类似推理框架、模型更新、扩缩容和监控。另外，开放权重模型在 Tool Calling 的稳定性上仍然落后于最强的前沿模型。对于 Agent 来说，这一点比很多普通工作负载更重要。如果一个 Agent 为了节省 Token 费用，却开始频繁调用错 Function，那么这笔交易通常并不划算。
还有一个介于无服务器推理和完全自托管之间的中间方案，可以省掉大部分运维工作：推理引擎的专用推理提供专属 GPU 推理端点，同时支持 Bring Your Own Model，并由平台负责管理底层基础设施。对于大多数团队来说，更合理的演进路线是先从无服务器推理开始；当成本规模或者合规要求需要时，再迁移到专用推理；只有当托管方案无法提供你需要的控制能力时，才考虑完全自托管。因为整套技术栈使用的是同一种 API，所以每次切换基本只是修改 Base URL，而不是重写整个应用。
这套架构说明了什么？
Agent 技术栈正在逐渐形成一种越来越熟悉的结构：底层是一个你自己安装的开源 Runtime；模型通过托管式推理平台提供；搜索、语音等外部能力通过统一协议接入；最上面才是那一层真正属于你的产品逻辑。在本文这个例子里，这一层只有两个 Markdown 文件，加起来大约一千词，而它也很明显就是整个产品真正有差异化的部分。
模型到底运行在哪里，也正在变成一个越来越普通的基础设施决策。团队可以根据延迟、模型选择和成本做决定，而且由于 OpenAI Compatible API 已经逐渐成为通用标准，这种选择以后也更容易调整。与此同时，真正拉开 Agent 产品差距的，也越来越不是模型质量本身，而是速度和体验。本文提到的优化方法其实都是很普通的工程习惯：减少上下文、并行执行搜索、先返回文字再生成音频、后台任务使用小模型、优化之前先测量。现在，模型反而成了比较容易解决的那部分，真正需要下功夫的，是整个使用体验。
相关产品与选型
