# 开源我这折腾了1年的「Agent自动化系统」，愿所有人都能感受Agent的魅力。— 拆解

- 来源：微信公众号「数字生命卡兹克」
- 发布时间：2026-11-04 08:19
- 原文：https://mp.weixin.qq.com/s/T9_acg247gxzUNL4j5zrCw
- 项目：https://github.com/KKKKhazix/agent-autoloop
- 文章性质：作者个人 Agent 自动化系统的开源重构介绍；实现与效果数字均为作者自述。

## 一句话

把稳定、确定的事件接收与派发留在小内核，把联网和具体执行放进可替换插件，再用持久挂起、追加式事件记录、输入数据隔离和跳数上限控制自动化风险。

## 五个核心观点

1. **内核只管编排不管外部能力**：接收标准事件、按规则分派、调用 Agent、记录过程；不联网、不绑定具体 Agent 产品，以减少核心变化面。
2. **事件、执行器、通知和交付都是插件**：外部信号先转换为统一事件，规则选择 Agent、目录和 Skill；适配层可替换而无需重写内核。
3. **长流程通过存档恢复而非轮询等待**：需要人审批时保存状态并释放执行进程，收到答复后恢复原任务；作者称等待期间不消耗 Token。
4. **可靠性机制各自限制不同故障**：追加式事件记录应对中断和重复投递；指令/数据分离降低外部内容混入授权指令的风险；最多 8 跳限制 Agent 相互唤醒的循环。
5. **自动化仍需要按风险保留人类控制点**：低风险任务可继续运行，删除、重启、付款和外发等动作转人工审批；交付插件还描述了主干规则、隔离执行、发布后线上核验。

## 七个分析角度

### 1. 内核边界为何重要
- 内核只处理事件、规则、分派和记录，为什么比把所有能力堆进 Agent 更容易保持可替换？
- 将网络访问移到插件后，核心逻辑能否在相同输入与状态下得到可预测结果？
- 边界是否真实成立，要看代码依赖和测试，而不能只看作者的架构描述。

### 2. 插件化解决了什么
- 事件源、Agent、通知渠道和 CI 交付各自变化时，是否需要重写调度中台？
- 用统一事件和最小适配协议，如何连接定时器、GitHub、命令行 Agent 与消息平台？
- 插件解耦能降低适配成本，但不会自动解决插件权限、兼容性和故障隔离。

### 3. 审批等待怎样避免空转
- 人几天不回应时，Agent 是否必须一直保留进程和会话？
- 保存状态、释放执行器、收到决定再恢复，如何把长流程从轮询改为事件驱动？
- 恢复机制仍需处理过期审批、重复点击、状态版本和取消任务等边界。

### 4. 事件溯源与重试
- 外部服务超时后，重复提交究竟会重放安全读取还是重复产生写入副作用？
- 只追加记录并从事件重建状态，如何帮助追查一次执行为何发生？
- “同一事件只记一次”不等于外部操作恰好执行一次；仍需幂等键、确认与对账。

### 5. 提示注入的边界
- Issue 或同事意见中的文字，为什么不能直接成为 Agent 的授权指令？
- 将外部材料标记为数据，并明确授权来自本机规则，能否缩小指令混淆面？
- 文件标签本身不是安全沙箱；权限、工具白名单和人工门禁仍决定可造成的影响。

### 6. 跳数熔断的收益与代价
- Agent A 触发 B、B 再触发 A 时，怎样阻止无界消耗和循环执行？
- 为每次调用传递剩余跳数，为什么比依赖模型自行判断“该停了”更确定？
- 固定 8 跳是作者的工程选择，不是普遍最优值；过低会截断合法工作流。

### 7. 如何解读文章中的效果数字
- 内核行数、启动时间、内存和派发耗时是否提供了硬件、负载及测试脚本？
- 80 多条意见、约 70 条自主处理和小时级上线是可审计指标还是作者自述？
- 架构机制可作为设计假设；性能、可靠性和效率优势需要公开基准与独立复现。

## 21 个开头钩子

### 事件如何驱动 Agent
1. 如果 Agent 仍要等人打开窗口，它自动化的究竟是哪一部分？
2. 定时任务、GitHub Issue 和业务告警，能否先进入同一种事件格式再交由规则处理？
3. 把任务起点从“人来问”改为“事情发生”，控制面需要先承担哪些责任？

### 内核为什么要小
4. 一个自动化系统的内核，是否应该知道它调用的是 Codex 还是 Claude？
5. 如果联网、通知和 Agent 执行都在插件里，核心调度逻辑能否保持确定？
6. 1600 行代码听起来很轻；真正值得检查的是哪些能力被明确排除在内核之外。

### 审批如何暂停和恢复
7. 人暂时没空批卡片时，为什么 Agent 还要继续占着一个运行中的进程？
8. 先保存任务状态、收到审批再恢复，能把长达数天的等待变成什么样？
9. 暂停不轮询可以省掉空转，但恢复前还要确认任务没有过期或被取消。

### 事件记录如何帮助恢复
10. 网络断在“任务已做完、结果尚未写回”时，无脑重试可能会做出什么？
11. 只追加事件并从记录重建状态，能让每轮任务的来龙去脉可追踪。
12. 事件只记一次不代表副作用只发生一次；幂等与对账仍然不可省。

### 输入数据与授权指令分开
13. 一个 Issue 说“负责人已经同意”，Agent 凭什么相信它有审批权？
14. 外部内容作为参考数据，本机规则作为授权来源，是提示注入防线的第一步。
15. 标注“这是资料”不是完整隔离；真正的边界还要落在工具权限和运行环境里。

### 自动循环要有上限
16. 当 Agent 能继续叫醒其他 Agent，系统怎样避免把一次任务扩成无限链条？
17. 给每次调用附上剩余跳数，能把“停止”变成运行时约束，而不只是 Prompt 建议。
18. 一个固定的 8 跳上限可以止损，也可能拦住合法流程；阈值应由任务证据校准。

### 个人案例与可复用证据
19. 作者称内核派发在 1.5 毫秒以内，但测试负载和硬件条件在哪里？
20. 同事提了 80 多条意见、约 70 条由 Claude 自主修改，这组数字说明了什么，又没说明什么？
21. 个人系统“用着很爽”是重要信号，却不能替代多用户、故障恢复和安全边界验证。

## 证据边界

约 1600 行、无第三方依赖、启动低于 0.1 秒、常驻约 60 MB、1000 个连接时约 170 MB、单次派发约 1.5 毫秒，以及公司意见处理数量和时延，均是文章作者自述；原文没有给出完整测试环境、样本或可复现数据，本文未独立核验。性能也可能来自轻量负载、固定环境、单一维护者和人工筛选。事件记录、权限隔离和插件化是值得验证的机制，不等于系统已经证明具备 exactly-once、安全或生产级可靠性。

标签： #主题/AI-Agent #主题/Agent自动化 #主题/Harness #主题/事件溯源 #主题/提示注入 #场景/公众号长文