什么是 AI Agent 运行时？它和框架、聊天应用有什么区别
框架帮你写出一个 Agent，聊天应用让你和 Agent 对话，而 Agent 运行时负责为真实用户运行大量 Agent —— 会话、工具、沙箱、记忆和渠道一应俱全。
FastClaw Team·问十个工程师"AI Agent 是什么"，你会得到十种答案。再问他们：怎么把 Agent 跑给一千个用户用 —— 要有历史记录、工具、文件、一个 Telegram 机器人，还要能按月计费 —— 答案就会短很多。填补这段空白的，就是 Agent 运行时。
本文梳理你在做 Agent 时一定会碰到的三层：框架、聊天应用和运行时，说明各自负责什么，以及如何判断你真正需要哪一个。
一句话版本
- 框架是一个库。它帮你写出"调用模型 → 解析工具调用 → 再调用模型"的循环，循环之外的一切都归你管。
- 聊天应用是一个产品。它让一个人和模型对话，有时带插件。循环和数据都不归你。
- Agent 运行时是一个服务端。它为很多人运行很多个 Agent，并接管那些枯燥但困难的部分：会话、记忆、工具执行、沙箱隔离、渠道、定时任务、用量计量，以及一个能被你自己的系统调用的 API。
拿 Web 开发类比：框架像 Express 或 Rails，聊天应用像托管的建站工具，而运行时更接近"应用服务器 + 数据库 + 进程管理器"已经帮你接好的那一套。
Agent 在运行时真正需要什么
一个演示用的 Agent 就是一个循环：把消息发给模型，执行它要的工具，把结果追加进去，重复。五十行代码就够了。可一旦有真实用户，清单立刻变长：
- 身份与指令。每个 Agent 需要一份能跨重启保留的人设和规则 —— 在 FastClaw 里，就是每个 Agent 自己的
SOUL.md、IDENTITY.md、AGENTS.md等文件。 - 会话。每段对话都要有独立的历史，并且按规则隔离，保证两个用户（或者同一个用户在两个平台上）永远看不到彼此的内容。
- 记忆。值得跨对话保留的事实 —— 用户的时区、项目的约定 —— 需要被写下来、之后再被想起。
- 安全执行的工具。Shell 命令、写文件、抓网页让 Agent 变得有用，也让它在陌生人能对话时变得危险。
- 模型管道。不稳定 API 的重试、提示缓存、流式输出、按 Agent 选择模型，以及不改代码就能切换供应商。
- 入口。网页聊天、HTTP API，还有用户本来就在用的聊天软件：Telegram、Slack、微信等等。
- 时间。只会被动回答的 Agent，价值只有一半；能按计划自己醒来的才完整。
- 计量。按轮次、按 Agent、按终端用户统计 Token 用量，才能向某人收费 —— 至少能提醒一下。
这些都和提示词无关，但在 Agent 变成产品之前，它们都必须存在。
框架：擅长写循环
Agent 框架提供模型、工具、链、图和记忆等抽象。当 Agent 的逻辑本身就是你的核心竞争力时 —— 新的规划策略、研究流水线、评测框架 —— 框架是正确的选择。
但框架通常不提供它外面的那台"服务器"。会话存哪、工具调用怎么隔离、一条 Discord 消息怎么变成一次函数调用、崩溃后如何恢复、怎么在多台机器上部署，都得你自己决定。很多团队最后发现：框架只占 10% 的工作量，外围的运行时占了剩下的 90%。
聊天应用：擅长服务一个人
各类聊天应用是使用模型最快的方式，有些还能自定义助手或安装插件。如果只是某个人需要帮助、不需要集成任何东西，它们就是最佳选择。
局限在于，当你希望 Agent 成为你的系统的一部分 —— 你的用户、你的数据、你的计费、你的聊天渠道、你的服务器 —— 时，它们往往无能为力。你通常没法把它当作后端服务成千上万的终端用户，没法用你自己的机器人把它放进社区的 Telegram 群，也没法把数据留在自己的机器上。
运行时：介于两者之间
Agent 运行时位于两者之间：你通过配置而不是编码来定义 Agent，并通过 API 而不是界面来调用它 —— 当然，好的运行时也会有界面。
FastClaw 就是一个例子：一个 Go 编写的单二进制程序，定位是"Agent 工厂"。具体来说，它提供：
- 多个 Agent，各自拥有文件和设置。可以在控制台、命令行或 API 中创建。详见 Agent。
- 任意模型供应商。OpenAI、Anthropic、DeepSeek、Ollama、OpenRouter 以及其他 OpenAI 兼容接口，支持按 Agent 覆盖，并自动重试。详见 模型。
- 工具沙箱。命令运行在 Docker 或 E2B 云沙箱中；在托管部署下，不受信任的对话者触发的一切都被锁在沙箱内。详见 沙箱。
- 渠道。同一个 Agent 可以接入 Telegram、Discord、Slack、飞书、企业微信、微信、WhatsApp、LINE 或 iMessage。详见 渠道。
- 给你的应用用的 API。OpenAI 兼容的
/v1/chat/completions，外加 Agent 管理、终端用户命名空间和用量统计。详见 API。 - 定时任务。Agent 可以自己创建 cron 任务（"每个工作日早上 9 点提醒我"）。详见 定时任务。
因为它是运行时，你在浏览器里聊的 Agent，就是在 Slack 里回复的那个 Agent，也是你的后端通过 HTTP 调用的那个 Agent。配置一次，处处可达。
如何选择
选框架，如果：
- 推理策略本身就是产品；
- 你有团队去搭建和运维外围的服务；
- 你只需要一两个行为固定的 Agent。
选聊天应用，如果：
- 使用者是你自己或同事；
- 不需要集成进你自己的产品；
- 你接受厂商的数据处理方式。
选运行时，如果：
- 你需要多个 Agent，或者一个 Agent 服务很多人；
- Agent 必须出现在聊天软件里，或藏在你自己的 API 后面；
- 工具需要替陌生人安全地执行；
- 或者你想自托管、掌握数据。
这些选择并不互斥。一个常见做法是：生产环境用运行时，当某个任务需要定制编排时，再在自定义工具或技能里用框架。
评估任何运行时都该问的问题
无论评估的是不是 FastClaw，这几个问题都能区分"演示"和"基础设施"：
- 工具调用在哪里执行，由谁决定？ 对不受信任的用户有没有硬边界，还是只靠提示词让模型自觉？
- 会话按什么隔离？ 一个 API Key 能否服务成千上万的终端用户，并保证历史和记忆互相隔离？
- 模型 API 出错时会怎样？ 失败的轮次是以可处理的错误返回，还是变成一句礼貌的道歉、被当作成功计费？
- 能横向扩展吗？ 单二进制在笔记本上很省心；同一套东西能否跑在 Postgres 上、开多个副本？
- 许可证是什么？ 能否商用，条件是什么？
下一步
如果你在基于 Agent 做产品，可以读一读如何为你的 SaaS 加入 AI Agent，或者看看面向 SaaS 开发者的方案。如果想今晚就让一个机器人跑起来，跟着 Telegram 教程做即可。如果你在自托管和托管方案之间犹豫，定价页把两种方式都列清楚了。