让AI代理在无服务器推理中感知更快

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)

请注意，系统有两个截然不同的任务，它们需要非常不同的硬件。代理程序本身很小：它接收消息、调用一些API并传递文本。任何廉价的机器都可以胜任。昂贵的工作是运行模型，而这项工作从不触及代理的机器，因为每次模型调用都会发送到推理引擎，并按令牌（token）计费。这就是该设置运行成本如此之低的原因：你每月只需为那台小型机器支付几美元，而GPU时间仅在模型实际运行的几秒钟内计费。

关于此设置，有两点对后续所有内容都很重要。首先，代理几乎可以在任何地方运行，因为模型不随它运行。Telegram 机器人使用长轮询（long polling），因此无需外部访问机器。代理在笔记本电脑或 Droplet 上的工作方式相同。其次，每次模型调用都通过一个兼容 OpenAI 的端点。推理引擎（Inference Engine）在 https://inference.do-ai.run/v1 后面提供服务，支持 Anthropic、OpenAI、Meta、DeepSeek、Qwen 等模型，并使用单一访问密钥。更换模型或提供商只是配置更改，而非迁移。

逐步设置指南位于 DigitalOcean 的Serverless Inference 文档和Hermes 文档中，因此本节仅涵盖要点和常见错误。

在控制面板（Serverless Inference 下）创建模型访问密钥，并在任何依赖它之前检查其是否有效：

curl https://inference.do-ai.run/v1/models \
  -H "Authorization: Bearer $DO_MODEL_KEY"

这会返回实时的模型目录。请相信它，而不是任何博客文章，包括本文，因为目录会变化。在此版本的响应中：anthropic-claude-5-sonnet 报告了 1,000,000 token 的上下文和 128,000 token 的最大输出，而 anthropic-claude-haiku-4.5 可作为更便宜的测试选项使用。

为智能体工作选择模型的三个规则。

选择时要看工具调用的可靠性，而不是基准分数；一个在函数调用上失误的智能体会凭空捏造餐馆，而不是去研究它们。

检查最大输出限制；目录中有几个强大的模型上限为 8K token，而截断的行程会以令人困惑的方式失败。保留一个便宜的模型用于迭代，因为你将反复运行测试提示数十次。

另外，调试时跳过目录中的router:*条目；你希望每次运行都使用相同的模型。

配置框架：安装 Hermes，将其指向端点，作为自定义的 OpenAI 兼容提供商（明确选择 Chat Completions 模式，而不是自动检测），并通过内置网关连接 Telegram（Hermes Telegram 文档）。此版本中有两个陷阱值得了解：在聊天中切换模型后，必须使用 /model --global，否则网关会以旧模型启动；并且由于机器人可以在其主机上运行命令，请保持默认的拒绝未知用户行为，并且只允许你自己的 Telegram ID。

研究和语音都是配置项，这两个选择都值得解释。

Linkup 是因为餐厅数据很快就会过时，而智能体需要一个为机器使用而构建的搜索 API，能够返回带有来源的当前结果。任何类似的搜索 API 都能以相同的方式接入。使用 MCP 而不是手写集成，因为 Hermes 会在启动时发现服务器的工具，并将它们像自己的工具一样注册。以后更换搜索提供商只是一次配置更改。在 ~/.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 告诉框架这些搜索可以安全地同时运行。这一行成为了下面最大的速度优势。

上面的一切都是任何人都可以复制的管线。智能体的行为存在于两个文件中，其中的选择也是速度选择。

SOUL.md 设定人格，而人格是一个产品需求。Foodie 在规划行程前对用户进行画像（街头美食猎手、印度香饭纯粹主义者、素食者、咖啡馆常客、精致餐饮），能根据线索猜测画像就猜测，不能时最多只问一个问题。一个问题限制有两方面的好处。当机器人在做任何事之前不断提问时，人们会失去耐心而退出。而且每个问题都会拖慢整个流程：智能体必须等待用户回复，然后再用一次模型调用处理回复，之后才能真正开始工作。

foodie-trail 技能设定工作流程，其最重要的几行是限制。每份行程最多六次搜索，查询内容写在技能中。除非搜索结果确认，否则输出中不出现任何餐厅。每天是一条穿过一个社区的可步行路线。解说脚本为60到90秒，并且是为朗读而写的。搜索限制的意义不止于成本：没有限制的智能体会不断搜索来解决自身的疑虑，而每多一轮都会增加一个搜索加模型的完整循环。把查询写进技能，将开放式搜索变成一组可以并行运行的固定步骤。

两个数字决定了智能体的体验，它们以不同的方式被优化。首个令牌时间（TTFT）是用户看到任何内容之前的时间。总生成时间是完整结果到达之前的时间。混淆它们是这类工作中最常见的错误。

首个令牌时间

对于单次模型调用，TTFT主要是网络时间加上预填充：模型在写出任何内容之前读取你的输入所花的时间。预填充随输入长度增长。所以TTFT比其他任何东西都更取决于你发送了多少内容。

注意每一轮进入上下文的内容。智能体框架会将系统提示、人格文件、记忆、技能列表和聊天历史静默地堆叠到每个请求中。Hermes保持技能描述简短，并且只在需要时加载完整的技能文件，这很有帮助。做好你的部分：保持人格文件简短（Foodie的不到400词），保持技能描述简洁，并让对话重置（此构建在空闲4小时后重置）。与6K令牌的历史相比，携带30K令牌历史的长对话会带来额外的等待时间，因此框架的压缩命令和空闲重置既节省时间也节省金钱。

让思考时间与任务匹配。推理模型会花最初几秒钟进行用户看不到的思考。对于一个只是从消息中读取城市和口味画像的回合，那就是在浪费时间等待。Hermes可以在运行时调整这一点（/reasoning low）。模式是：规划步骤值得思考时间，而确认回复则不需要。

先发送一条快速首行。对于慢任务最重要的技巧：让技能在第一次搜索前发送一行（“印度香饭纯粹主义者，班加罗尔，两天。正在研究。”）。行程不会更早到达，但应用不再感觉卡住。这就是用户所说的“快”的大部分含义。

保持连接活跃。在生产环境中，将智能体的主机放在靠近推理端点的区域，并让长时间运行的网关重用其连接。工具也是如此：npx 在首次使用时冷启动Linkup服务器，因此为你需要快速使用的工具慷慨设置框架的回收选项。一天的第一次搜索应该承担冷启动成本，而不是每次对话的第一次搜索。

对后台任务使用小型模型。Hermes将诸如为对话命名和压缩历史之类的副任务发送到单独配置的模型。将这些指向Haiku类模型，这样你永远看不到的慢调用就不会妨碍你。

总生成时间

整个运行是一个流水线：读取请求、搜索、编写行程、编写解说、渲染音频、交付全部。收益来自重新设计流水线，而不是加速任何单个调用。

并行运行搜索。这是最大的单项收益。六次搜索每次3到5秒，依次运行需要20到30秒。如果标记为可以安全地同时运行，它们花费的时间大约等于最慢的单个搜索。规则是：你的智能体每个任务调用超过两次的任何只读工具都应标记为并行安全，并且查询的编写方式应使它们互不依赖，这正是让它们并行运行的条件。

限制循环并写出查询。你知道研究需要多长时间，因为你决定了需要多长时间。

先发送文本，在后台渲染音频。用户阅读第1天的内容时，其音频正在渲染。对他们来说，文本到达时答案就到了。每日音频文件胜过一个大文件的理由有两个：它们与阅读时间重叠，并且文本转语音失败只损失一天的音频，而不是全部。

有意保持输出简短。生成时间随输出长度增长，所以冗长就是缓慢。技能的格式规则（每天大约15行以内）相比模型在没有指令时产生的输出，写作时间大约减半，而且在手机上读起来更好。当你确实需要长输出时，确保模型的输出限制能一次完成。达到限制并第二次调用继续生成是最慢的文本生成方式。

在调整之前先测量。瓶颈很少是你假设的地方。在这个构建中，瓶颈是家庭连接上的音频上传，而不是模型。

这个代理运行在无服务器推理上，在这种规模下这并不是妥协，而是正确的选择。将其托管在GPU机器上意味着要租用H100 GPU Droplet，每小时约3.39美元，每月约2500美元，却要为一块闲置的GPU付费，而所有实际工作都是在推理引擎上按token完成的。12美元的Droplet就能完成同样的工作。

自托管在四种情况下才开始有意义。第一种是成本：一旦你每月的token账单接近租用GPU的固定成本，这笔账就算过来了，因为自托管的开放权重模型无论处理一个请求还是一百万个请求，成本都一样。第二种是数据控制：如果出于合规或隐私原因，提示词不能离开你的基础设施，那么无论价格如何，按token计费的API都不在考虑之列。第三种是定制模型：如果你有针对特定领域微调过的权重，就需要有地方来部署它们。第四种是延迟：API提供的是典型性能，而你自己的端点提供的是你可控制的下限。

缺点也同样真实。无论有没有流量，固定成本都在产生，而且GPU Droplet即使关机也会计费。你需要自己承担运行服务栈的工作：vLLM或类似工具、模型更新、扩展、监控。此外，开放权重模型在工具调用可靠性方面仍然落后于前沿模型，而工具调用可靠性对代理的重要性超过大多数工作负载。一个在token上省钱却在函数调用上失误的代理，是一笔糟糕的交易。

有一个中间步骤可以省去大部分运维成本：推理引擎的专用推理层级提供专用的GPU端点，支持自带模型，由平台管理。对大多数团队来说，合理的路径是先从无服务器开始，当数字或合规规则要求时再转向专用，只有在需要托管选项无法提供的控制力时才完全自托管。因为整个技术栈使用相同的API，每一步迁移都只是更改base URL，而不是重写。

代理技术栈正在定型为一种熟悉的形态：一个你安装的开源运行时，一个你租用的托管模型服务，通过共享协议附加的搜索和语音等外部能力，以及最上面真正属于你的薄薄一层。在这个构建中，那一层是两个约一千词的Markdown文件，而且它显然就是产品本身。

你的模型在哪里运行正在成为一个常规的基础设施决策，基于延迟、模型选择和价格来做出，并且很容易逆转，因为兼容OpenAI的API已经成为共享标准。而现在，产品之间的区别在于速度，而不是模型质量。本文所涉及的手段都是普通的工程习惯：发送更少的上下文，并行运行搜索，先传送文本再传送音频，使用小模型处理后台工作，在调优之前先测量。现在模型是容易的部分，体验才是真正的工作。

技术栈：Hermes Agent（MIT）、DigitalOcean推理引擎——无服务器推理、基础Droplets、Linkup、ElevenLabs。