概念

AI 代理与业务相互成就：代理承担琐碎事务并不间断工作，业务为它们提供目标、数据和边界。向代理的转变不是一次性的实验，而是一场不可避免的变革：模型越来越便宜，将典型工作自动化比为此养人更划算。

Agent OS 正是为这场变革而生的平台。它把 AI 从「会回答的助手」变成「会行动的员工」：在同一个内核上运行着数十个代理——支持、销售、HR、分析——并在预算、质量和安全的管控之下。

本文按「从一般到具体」的方式撰写，并按受众做了标记：

• 🟢 —— 面向所有人（包括业务方和新手）；
• 🔵 —— 面向构建代理和运维平台的人；
• ⚫ —— 面向编写/修改内核本身的人。

代理的层级与类型

落地按层级推进——从简单到自主：

1. FAQ 机器人 —— 基于知识库作答：检索和现成答案。
2. 助手 —— 能理解并推理，通过工具处理实时数据。
3. 代理 —— 设定目标、使用工具并推动到结果：不是「查一下价格」，而是「比较各选项并给出最优推荐」。
4. 自主代理 —— 自行启动（触发器），并在有事发生时主动联系。

我们按代理与谁协作、由谁启动，划分出四种业务代理类型。同一套原语——流程、工具、触发器、IPC——组合出不同的角色：

对外代理 —— 与客户和外部世界打交道：支持、销售、咨询、首次接触。它们生活在渠道中（网站挂件、Telegram），而工具让它们能访问实时数据——目录、价格、库存、日程。演示中的例子：高校支持（ngu）、选车（drom）、机票（aviasales）、图书（chitai-gorod、labirint）。

对内代理 —— 覆盖内部流程：HR、文档、后台、入职。员工不必钻研规章制度，直接问代理——代理检索知识库并附上引用作答。机制：检索和读取档案（site_tool / archive_tool / pdf_tool）、记忆（memory）、升级给真人同事（escalate）。

观察型代理 —— 监视数据，并在有变化时主动联系。它们不等待提问，而是由触发器启动：cron（按计划）或 monitor（出现新内容时）。例子：rss 代理监控新闻流，zakupki 跟踪新的采购，结果发送到 Telegram / email / 另一个代理。

控制型代理 —— 响应事件并管理其他代理。通过 IPC 启动子代理（subagents），通过 workflow 组装带条件和重试的多步骤流水线，通过 escalate 把复杂情况转交给人。

1.1 为什么需要它——解决哪些问题

🟢 当代理只有一个时，围绕单个模型写个脚本就够了：token 不用计数，不需要隔离，出错可以「重启一下忘掉」。问题始于代理变多、并且为业务服务之时。这时就会出现「个人代理」所没有的东西：

Agent OS 解决代理数量增长时不可避免的四个问题：

1. 高效利用资源。 代理共享平台资源——语言模型（LLM）、算力和存储；内核决定谁在何时执行。
2. 预算管理。 按轮次 / 分钟 / 生命周期的 token 限额——单个代理不会「烧光」整个预算。
3. 可观测性。 每一步都有日志：能看到代理做了什么以及为什么。
4. 安全与隔离。 代理不会读取他人的上下文，也不会花掉他人的预算。

1.2 什么是 Agent OS

🟢 一句话：

Agent OS 是面向 AI 代理的内核（kernel）。 就像操作系统管理普通的程序进程一样，Agent OS 管理 AI 代理。

Agent OS 本身不做推理。它之于语言模型（LLM），就像操作系统之于处理器：

• LLM 是「CPU」。 Agent OS 不计算答案——它规划在外部提供商（DeepSeek、任何 OpenAI 兼容 API、Ollama）上的计算。
• Agent OS 是「内核」。 它决定哪个代理现在会获得 访问模型、多少 token 会被消耗，以及使用哪些工具。

由此引出三个关键理念，它们将 Agent OS 与“普通 agent”（围绕单一模型的脚本）区分开来：

1. Agent = 进程。 每个 agent 都是一个独立进程，拥有自己的 PID、 指令、上下文（工作记忆）、工具集和 token 预算。
2. 内核 = 秩序。 Agent 共享同一个 LLM——内核负责调度它们、限制它们， 并将它们彼此隔离。
3. 一切皆可控。 每一步（工具调用、消耗的 token、 状态）都会被记录，并受到限制约束。

1.3 操作系统的隐喻

🟢 整个构造是对普通 OS 内核的类比。它正是其余一切的“直觉”来源：

如果把这张表记在脑子里，后面的一切都会“自然而然”地读下去。

1.4 基本概念

🔵 概念分为两组：内核（模型的基础构件——没有它们就无法理解一切如何运作）和内核之上的服务（可选的，在加载时接入）。

4.1 内核——基础构件

我们逐一分析。

模板 → 进程 → 会话。 同一事物的三个层级：

• 模板——可复用的 agent 配方：名称、指令、工具、 钩子、预算。位于 config/agents/<name>/agent.yaml。
• 进程——模板的运行实例，拥有自己的 PID、上下文和 预算桶。
• 会话——绑定到进程的用户对话（session_id、 user_id）。

Agent 不会在启动时预先创建：对模板的第一次请求会“即时”创建 进程（lazy spawn）。模板在 GET /v1/templates 中可见，运行中的 进程在 GET /v1/agents 中可见。

上下文（工作记忆）。 有限的消息历史（类似 RAM）。 当 max_context_tokens 限制被超出时，淘汰策略会触发：

• fifo——删除最旧的；
• summary_first——将旧的折叠为简短摘要（默认）；
• sliding_window——只保留最后 N 条。

调度器。 一个调度器决定哪个就绪进程接下来执行。 目前是 round_robin，带有并发限制 （kernel.concurrency_limit）——即同时消耗 token 的 agent 数量上限。当达到上限时， 进程会等待，直到某个进程“让出”（yield）或被阻塞。

预算（token bucket）。 每个进程从桶中消耗 token：

• refill_per_sec——每秒向桶中添加多少 token；
• max_bucket——桶的容量（空闲时能积累多少）；
• max_total——进程整个生命周期的硬限制（之后即死亡）。

预算会合并为组（类似进程树上的 cgroups）。在 每一轮之前，内核会按顺序检查：组 → per-user → per-session。 如果任何一层被耗尽，该轮就会被拒绝，用户会看到来自 budget_messages.* agent 的文本。

工具。 Agent 与世界交互的唯一方式：网络、 文件、网站、文档。内核在每一次调用中居中协调——检查 访问权限、记录日志、计算成本。按配置层级，工具从内置 （仅通过名称接入）到声明式（通过配置描述）再到脚本式（当现成的工具不够时使用自己的逻辑）各有不同。

钩子。 在多个点拦截 agent 的生命周期（完整列表—— 06-hooks-reference）：从用户消息和调用 从工具到推理、令牌流、上下文压缩和完成。 可以转换、拒绝/强制重写（rework）、抑制 或自行响应而无需 LLM。

内置类型：faq_cache、inject、escalate、memory、rag、 tool_cache、link_check、condense、compact_results、format_guard、 loop_guard、guard、pseudonymize、groundedness、circuit_breaker、 script_hook。

IPC。 代理通过系统调用通信：send/recv（点对点）、 spawn（创建新进程）、fork（克隆自身并继承 预算组）、kill、yield。

4.2 内核之上的服务

这些子系统是可选的，在加载时接入。如果某个不存在—— 相应的调用会响应“未配置”，而其余部分继续 工作。

触发器——什么在无人值守时启动代理。 这是平台的 关键区别：代理可以完全自主运行。三种机制：

所有触发器的结果都进入 sink：log / webhook / telegram / vk / yandex_messenger / messages_db / email / 另一个代理。

通道——如何与代理通信。 与触发器（谁启动）不同， 通道回答的是“通过什么”的问题：

• HTTP API（SSE 聊天）——主要的编程接口；
• 可嵌入的网页小部件——网站上的“与 AI 聊天”按钮；
• Telegram、email、webhook——外部系统。

Webhook 既是通道又是触发器——因此这两个概念被分开。

编排（workflow）。 由代理和工具组成的声明式管道（DAG）： 步骤 agent / tool / condition / for_each，带重试、 超时和每步预算。工作流有自己的触发器（cron/webhook），但 工作流本身是编排，而不是触发器。

内存与存储。

• logs/process-<pid>.jsonl —— 进程的逐行 JSONL 追踪；
• logs/events.db —— DuckDB 事件存储（为 trace_* 工具提供数据）；
• logs/messages.db —— 共享转录日志 + FAQ 缓存 + 全文搜索；
• logs/state.db —— 状态存储：作用域键值（session / user / agent / team）；
• logs/teams.db —— 命令注册表（成员资格 + 授权），如果启用；
• 检查点 —— 用于故障恢复的状态快照。

Subagents。 工具或钩子可以将任务委托给子 代理进程并读取其最终响应——例如 subagent_tool。

1.5 关键架构决策

⚫ 几个决定平台特性的决策：

• Rust。 整个内核是一个静态编译的二进制文件：没有运行时 和外部依赖，部署简化为复制文件，而安全的 并发性使数十个代理无数据竞争地运行。
• 单一 async-runtime（Tokio）。 内核是唯一的 事件循环，调度所有进程；不会为每个代理启动单独线程。
• 进程模型。 代理和工作流是同一注册表中的进程，具有 spawn/fork 语义和进程树。
• 提供者抽象。 内核不进行推理，而是在 可插拔的提供者（OpenAI 兼容、DeepSeek、Ollama）上调度推理——独立于 模型和供应商。
• Kernel-mediated I/O。 代理从不直接调用工具： 每次调用都由内核验证、限流和记录。
• 协作式多任务。 代理在每轮 推理后“让出”；可选——按时间片抢占。
• Opt-in 子系统。 状态存储、cron、workflow 和消息存储在启动时 接入；如果某个不存在，相应的调用会响应“未配置”， 而不会破坏内核。
• 模块化。 平台由模块组成——即打包单元，它们 贡献路由、工具、钩子、服务和配置。内核只是 机制（进程、调度器、预算、LLM），而功能（workflow、cron、 通道、docs、widget）是模块，作为 linked crate 或原生 DLL 接入。可包含模块的列表——server.yaml → modules.enabled；详情—— 32-building-a-module。

1.6 系统边界——这不是什么

🟢 为了避免将 Agent OS 与相邻事物混淆：

1.7 下一步去哪里