Agent Autoloop 1.0.0：后台运行，审批驱动交付

Agent Autoloop 发布了首个正式版本，这款工具让命令行智能体持续处理任务，并在需要人工判断时发送通知。开发者可以将任务规则关联到日程或议题，无须一直守着终端，只需在通知卡片中回答问题即可恢复任务。

1. 收到事件后，智能体按规则工作

Agent Autoloop 将日程、新议题、运维告警等作为事件接收，并发送给预设的智能体和工作目录。同一目标在等待期间收到更多事件时，会合并为一次任务。智能体将处理结果写入最终消息，然后终止进程，即正在运行的程序实例。

事件接收、智能体连接、通知渠道和部署流程均可通过插件这种可替换功能的扩展组件进行更换。例如，可以配置接收议题后运行智能体修改代码，再通过即时通信工具请求判断的流程。这种结构允许分别选择发现任务的方式和实际执行任务的工具。

该工具支持 macOS 和 Linux，需要 Node 24。还需准备 Git、curl 以及已登录的命令行智能体。发布说明中的安装和试运行示例如下。

curl -fsSL https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.sh | sh
agent-autoloop try

安装命令跟随 main，而非特定版本标签。在试运行中，可以确认智能体留下问题后退出、用户回答后再恢复原对话并完成任务的流程。

实际任务注册在 ~/.agent-autoloop/rules.json 中。README 的示例让 Codex 每天上午9点汇总笔记目录中前一天的记录和提交，即仓库中记录的一组变更。规则需指定何时运行、交给谁处理，以及在哪个目录工作。

保存的规则会在几秒内生效，可用 agent-autoloop check 检查。配置出错时，负责中转多个任务和通知的中心程序 hub 会继续使用此前有效的规则，并报告错误。

智能体需要提问时，会在最终消息中附上规定的响应块。hub 将问题标题、说明和选项通过通知卡片传递。README 将删除数据、重启服务、产生费用和联系他人列为需要请求判断的示例。

用户的回答会成为恢复原对话的输入。智能体可自行处理的任务可以直接完成，也可以安排稍后再次检查。若响应格式有误，hub 会要求在同一会话，即连续的对话记录单元中，仅重写最终消息，而不是重复已完成的任务。

工具还包含可衔接部署的交付插件。在 GitHub 代码变更请求上添加用于分类的 deliver 标签后，会依次进行审查、等待自动检查、合并、等待部署和确认线上服务版本。据 README 介绍，配置只从 main 读取，不会将变更请求的代码下载到工作机器上执行。

等待人工答复时，智能体进程会终止，token 消耗也会停止。等待状态保存在 SQLite 中，后台只保留轻量级 hub。它不让智能体持续运行，而是保存记录，收到答复后再继续对话。

其收益在于减少盯着终端的时间，以及智能体等待期间的资源消耗。相应地，用户需要配置任务规则和通知路径，并作出必要决定。模型使用费由用户账号承担，因此需同时考量等待成本的节省与实际工作产生的模型费用。

项目 README 提供了 Apple M5 Pro、24 GB 内存、Node 24.21.0 环境下的测量结果。每次写入都是独立请求，并在事务，即作为一组处理的数据操作，持久化到磁盘后才响应。下列数据展示的是接收和转交任务的 hub 的启动时间与资源消耗，而非智能体的开发成果。

表：Agent Autoloop 1.0.0 hub 基准测试

条件：Apple M5 Pro、24 GB、Node 24.21.0。每次写入为独立请求，事务持久化到磁盘后才响应

单位：启动与转交延迟为 ms，内存为 MB RSS，写入吞吐量为 events/s

任务转交延迟的 p99 为 1.82 ms，意味着 99% 的测量值不超过该时间。

在110万条记录下，常规启动耗时为 99.8 ms，但同一 README 也指出，格式变更后从日志重建状态的首次启动，在相同记录数量下耗时 43.1秒。这与常规启动不同，需要重建日志，因此规划更新运维时应将两者区分考察。

验证项目包括包含故障和重复请求的20万步模拟，即在虚拟情境中测试行为的过程，以及 1,000次进程终止测试。

命令行输出和默认通知目前为中文。Feishu 已测试实际发送和按钮响应，但四种 Webhook 模板，即用于在服务间发送自动通知的连接方式模板，仅在本地模拟服务器上验证过。若要在这些文本渠道中回复，设备必须能够访问 hub 的公开地址。

Agent Autoloop 1.0.0 的核心在于，将更多任务交给智能体的同时，仍在工作流程中保留需要人作出决定的环节。