Loong：国内大学生推出面向垂直AI智能体的 Rust 基座，实现可审计可扩展的 Agent 运行时
面向垂直 AI 智能体的 Rust 基座，先给结果，再展开运行时。Loong 已在树莓派 CM0 NANO 等低功耗设备上表现出色（感谢 Rusty 测试与记录）。
Loong 的设计初衷
Loong 旨在构建一套能够长期稳定运行、具备高扩展性与完整审计能力的 Agent 运行时底座。我们关注的并不仅是让模型调用工具，而是将工具、插件、外部系统以及运行状态统一纳入可控的治理链路——既可扩展，也可追溯，一旦出现问题能够快速还原。
当前多数 Agent 框架的瓶颈并非来自模型能力，而是运行时边界的模糊。当工具数量增多、插件自由度变大时，系统往往会产生难以解释的副作用。Loong 的做法是收紧核心路径，同时放开扩展能力：核心层负责契约、能力、策略与审计；扩展层则管理 provider、工具、通信渠道、记忆和插件。
我们的核心理念
Agent 运行时将逐渐趋近于一个小型操作系统。它需要调度工具调用、管理外部连接、控制权限、维护状态与历史，并集成观测、插件以及长任务。如果所有这些能力都塞进一个单一且不可拆分的主流程，短期或许可行，但长期维护极其困难。
因此，Loong 选择在早期就把运行时的边界构建清楚：模型可以调用工具，但工具并非裸露的入口；插件能够动态加入，但不可绕过策略与审计；外部系统可以接入，但每一次调用都必须留下可追溯的证据。这条路线虽然在初期会牺牲一些实现速度，但换来的却是更为稳定和有序的扩展空间。
工具与插件体系
Loong 的工具系统并非一张静态的工具列表，而是一套可治理的运行时表面。工具的可见性取决于当前的构建、配置、provider 能力以及策略边界。即便高风险工具向模型暴露，也必须保留审批、策略与审计环节。
插件系统则遵循「manifest 优先」的模式。插件必须先声明其身份、能力、入口点、兼容性、信任等级及运行方式，Loong 再据此决定是否能将其接入运行时。这样的好处在于，插件生态可以自由扩展，但核心系统不会沦为一个失控的动态脚本宿主。
目前，Loong 已支持 WASM 插件动态加载，WASM 在受限的 bridge 运行时中执行，通过清晰的 JSON ABI 与宿主交换数据。除 WASM 外，Loong 还提供了 HTTP JSON bridge 和 process stdio bridge（后者基于 JSON-line 帧），覆盖了实用的 IPC 场景。未来插件还将向更多 IPC 及外部运行时延伸。我们的方向不是将各种语言都硬塞进核心，而是为不同运行模式提供一致的接入入口：声明清晰、策略可控、运行证据完整、失败时易于诊断。
审计与追溯
审计（audit）是 Loong 的核心能力之一。系统中关键行为不应仅存在于临时日志中，而应归入结构化事件流。例如 token 发放与撤销、策略拒绝、工具调用、连接器调用、插件发现、插件信任评估、安全扫描等，都应能够回溯复盘。
当前运行时已实现持久的 JSONL 审计机制，默认将审计事件保存在本地历史中。运营者可以根据事件类型、时间窗口、token、agent、pack、信任等级等维度进行查询。我们的目标是使一次工具调用、一次插件加载或一条策略拒绝，都能回溯到同一条证据链上。这也正是 Loong 与普通工具调用框架之间的关键区别：普通框架更关心调用是否成功，Loong 则更在意调用为何被允许、在何种上下文下执行、结果如何、以及未来是否还能追溯。
OpenTelemetry 可观测性
必须分清审计与可观测性的边界。审计负责问责与证据链：一次动作为何被允许或拒绝，由谁触发，关联哪个 token，命中了哪条策略。可观测性则关注运行诊断：系统当前在做什么，耗时卡在哪一段，哪些请求失败，哪个 provider 走上了异常路径。
Loong 同时保留本地结构化日志和 OpenTelemetry 追踪。本地日志面向开发、排障和轻量部署；OpenTelemetry 用于接入团队已有的观测系统，特别适合长任务、流式模型请求以及多 provider 切换的场景。Provider 调用会记录模型、provider、会话、完成原因、token 用量、错误类型等字段。请求和响应的正文默认不采集，只有当显式开启内容记录时才会进入遥测数据。这一默认值必须保持保守，因为 Agent 运行时经常处理用户上下文、工具输入和外部系统返回值，不能为了排障简便而让内容泄露成为观测的一部分。
Loong 选择 OpenTelemetry，是因为其已成为可观测领域的通用协议和工具生态。运行时通过 OTLP 向外部后端发送遥测信号，部署方可接入 Jaeger、Collector 或自有观测平台，不绑定特定厂商或后端实现。目前 Loong 已支持向指定目标导出 trace。仓库内的 deploy/observability 目录提供了一套最小可用的本地观测环境：OTel Collector 接收 OTLP 信号并转发至 Jaeger。开发者可以沿一次 Agent Loop 的 trace 观察模型请求、工具调用、provider 路由和错误归因，在处理长链路问题时比单纯查看日志更容易定位异常。
可观测性展望
后续的工作将围绕两条主线展开：补齐运行时插桩，以及在标准 OTel 信号上构建面向 Agent runtime 的分析能力。
完善插桩
Loong 目前重点支持 trace，接下来会将 metrics 和 logs 纳入统一的观测出口。Trace 用于还原单次请求或任务的完整链路，展现各组件、各阶段的耗时与状态；Metrics 则用来观察系统长期运行趋势，例如 provider 错误率、队列深度、token 消耗、工具调用耗时以及任务失败分布；Logs 留存必要的本地诊断信息，并通过共有关联字段与 trace、metrics 对齐。这套插桩体系的目的并非暴露所有内部细节，而是确保关键路径可诊断。当一个长任务失败时，开发者应能直观看到失败发生在模型请求、工具执行、策略判断、provider 故障切换，还是 bridge runtime 中，而不必从零散日志中倒推整条路径。
构建智能体可观测方案
通用 APM 通常关注延迟、错误率和资源占用，但 Agent runtime 还需要回答更具体的问题，例如：为何一次任务会反复调用同一工具？provider 切换是否有效？上下文膨胀发生在哪个阶段？流式请求中断后是否正确收尾？策略拒绝是否符合预期？Loong 将始终使用标准 OTel 信号，并在其上构建面向 Agent 的分析模型。这样既可以接入现有后端，也能沉淀项目自身的诊断能力，而不会将观测能力锁定于某个专用平台。
关于审计与追溯的思考
「智能体做过什么能否复盘」这类需求，可观测性可以在很大程度上给予支持。Trace、结构化日志及关键字段足以还原一次 Agent Loop 的主要路径，也有助于判断问题发生在哪个组件。但在 Loong 中，审计不能归入可观测性。审计还关联着策略、能力和审批：当 Agent 准备执行某个动作时，系统不仅记录它做了什么，还需在执行前根据当时的策略判定是否允许。这一判定必须发生在运行时的关键路径上，而不能依赖异步写入的观测后端。因此，在文档中我们也要维护这条边界：运行状态、链路诊断和事后排障归为可观测性；授权、拒绝、责任链和可验证证据则归入审计。两者可共享关联字段，但职责不可混淆。
性能与边缘部署
Loong 采用 Rust 实现，并以单一二进制形式发布。这种选择并非为了追求语言标签，而是为了有效控制运行时开销、部署复杂度及长期维护成本。我们希望 Loong 能够运行在服务器、开发机上，也能在 Raspberry Pi 级别的 Linux 设备上稳定工作。仓库中已包含 ARM64 Linux 发布链路、EmbeddedPi harness、编程化压力基准测试以及 WASM 缓存基准测试。性能提升不会停留在口号上，而是通过基准测试关卡来约束关键路径。
在边缘设备上，Agent runtime 不宜无节制地堆砌功能。Loong 的思路是将能力设计为可开关、可审计、可观测的模块，让资源受限的环境仅启用真正需要的部分。
架构设计理念
Loong 的架构可以简洁地理解为两个层次：核心路径负责稳定性与治理，扩展路径负责生态与能力。核心路径涵盖 contract、capability、policy、audit、protocol 以及 runtime dispatch，其职责是保持清晰的边界，确保外部能力无法绕过治理。扩展路径包含 provider、tool、channel、memory、plugin 和 bridge runtime，负责接入真实世界中的模型、工具、消息渠道、外部服务及插件。扩展层可以快速演变，但这种变化不应冲击核心路径。
这一分层并非只是为了形式上的架构图，而是为了给未来插件生态留出足够的空间。一个插件可能来自 WASM、外部进程、HTTP 服务，未来还可能源自更多 IPC 或协议桥；但无论以何种形式接入 Loong，都必须遵循同一套发现、策略、审计和观测规则。
当前进展
目前，Loong 已具备以下基础能力：
- 单一 loong 二进制入口和跨平台发布链路；
- 受治理的运行时及插件扫描、转换、激活流程；
- WASM 动态插件加载，HTTP JSON bridge，process stdio bridge；
- 工具目录的运行时可见性控制；
- 涵盖能力、策略、审批和审计的整套治理链路；
- 持久的 JSONL 审计和留存审计查询；
- OpenTelemetry trace 导出及结构化日志；
- 面向压力测试、WASM 缓存和低资源场景的基准测试基础。
仍在推进的方向包括更完善的 WASM 资源限制、更强的进程沙箱、更多 IPC bridge 适配器、插件签名、插件市场层面的工件验证，以及更清晰面向 SDK 的插件开发体验。
未来愿景
Loong 的愿景是打造一个开放但不失控的 Agent runtime。开发者可以自由扩展工具和插件，团队可以将内部系统接入，个人用户也能在低资源设备上运行自己的 Agent。但无论系统多么复杂，关键行为都应可解释、可观测、可审计。
更进一步，Loong 将把插件、channel、provider、memory 和长时间运行的任务纳入同一治理模型。届时，Agent 将不只是一次对话中的工具调用者，而是一个能够长期运行、可接收外部事件、可恢复状态并接受审计的执行实体。我们不会把所有能力都塞进核心，核心应保持小而稳定，生态能力通过插件和 bridge 扩展。唯有如此，Loong 才能同时服务于本地开发、团队内部自动化、边缘设备部署以及更大的插件生态。
相关链接：