开源我这折腾了1年的「Agent自动化系统」，愿所有人都能感受Agent的魅力。
- 原文链接：https://mp.weixin.qq.com/s/T9_acg247gxzUNL4j5zrCw
- 作者：数字生命卡兹克
- 发布时间：2026-11-04 08:19
- 获取时间：2026-11-05
- 开源项目：https://github.com/KKKKhazix/agent-autoloop
- 前篇：[[01-ai-agents/折腾了整整1年-毫无保留地分享一下我这套Agent自动化系统]]
核心结论（一句话）
Agent-Autoloop 的架构主张是让小内核只负责确定性的事件接收、规则派发与过程记录，把 Agent、外部事件、通知和 CI 交付放进插件；挂起恢复、追加式事件记录、输入数据隔离与跳数上限，则分别处理等待、追溯、指令混淆和循环风险。
分类提炼
- 场景：事件驱动 Agent 自动化、个人/小团队控制面与可插拔执行器
- 类型：作者个人系统的开源重构介绍，不是独立性能评测或安全审计
- 标签： #主题/AI-Agent #主题/Agent自动化 #主题/Harness #主题/事件溯源 #主题/提示注入 #场景/公众号长文
知识节点（9 个独立概念）
- Agent-Autoloop内核：作者将内核限制为接收事件、按规则分派、调用 Agent 和记录步骤，并称其不联网且不绑定具体 Agent 产品。
- 插件化扩展边界：事件源、Agent 执行器、通知渠道和代码交付流水线位于内核之外，以适配器扩展或替换。
- 事件规范化与规则路由：外部信号先转换成统一事件，再由 rules.json 选择 Agent、工作目录与 Skill；短时重复消息可合并处理。
- 挂起后恢复：等待审批时保存任务状态并释放执行进程，收到用户决定后再从存档恢复，而非持续轮询。
- 追加式事件记录：将任务变化按顺序写入不可回改的记录，供重建状态、解释执行来源和处理重复投递。
- 指令与数据分离：把 Issue 或用户意见作为不可信资料，与本机规则和授权指令分开传给 Agent，以降低提示注入造成越权的风险。
- Agent跳数熔断：为 Agent 之间的后续调用设置最大链路深度；作者的实现超过 8 层就停止派发并通知人。
- 风险分级审批：低风险且规则允许的工作可继续自动执行；删除、重启、付款和对外发送等高影响副作用请求人工确认。
- 交付插件与线上核验：文章描述的 CI 插件把审查、检查、合并、发布和线上版本确认串成流程，并把 PR 执行限制在隔离环境。
关联图谱
上游（基于 / 来自）
- [[01-ai-agents/折腾了整整1年-毫无保留地分享一下我这套Agent自动化系统]]：同一作者的前篇描述事件中台、路由、CI 和风险审批；本文记录其开源前的内核抽象与插件化重写。
- [[01-ai-agents/InfoQ-TiDB-薄Agent-Loop厚Control-Plane-Harness]]：从可靠性工程角度讨论把状态、权限、审计和恢复放在稳定控制面；本文提供一个个人系统的实现主张。
下游（应用于 / 验证于）
- 暂无独立复现或外部验证。作者给出的 GitHub 仓库是代码入口，但本文编译没有审查仓库实现或运行基准。
同级（横向 / 并列）
- [[01-ai-agents/Datawhale-DeepSeek-Super-Agent架构-Router-Worker双层]]：同样围绕事件驱动和模块边界展开；该文强调 Router/Worker 吞吐与上下文分层，本文聚焦个人自动化内核、审批恢复和插件扩展。
- [[01-ai-agents/51CTO技术栈-Agent能力不足维护代码库-HumanLayer创始人质疑无人值守软件工厂]]：提醒区分单次自动执行与长期维护能力；可用其长期迭代评测视角审视本文的自动交付主张。
正文要点
- 开源动机与重写范围。 作者称首篇文章发布后收到开源请求，因此用两天重写并大幅抽象系统；Pi 的极简内核/Extensions 与 DeepSeek Harness 的插件理念是作者明确提及的设计参考。
- 四项内核职责。 内核负责收事件、依据规则分工、派发 Agent 并记录步骤；网络调用、产品适配和后续 CI 被移到外部插件，作者据此主张核心可保持确定性。
- 统一事件和执行约定。 定时任务、GitHub Issue/PR 或业务告警转换为统一事件；规则决定 Agent、目录和 Skill。执行器通过最后一条回复返回结果，额外动作以约定结构表达。
- 四种控制机制。 审批等待通过存档释放运行进程；事件溯源用于回查与抵御重复消息；指令/资料分离用于减少外部文本伪装授权；最多 8 跳用于限制 Agent 链式唤醒。
- 四类插件。 事件插件接入触发源，Agent 插件接入执行器，通道插件负责通知与审批，交付插件负责代码审查、检查、发布及线上确认。
- 示例自动化覆盖从巡检到维护。 作者举出价格核对、额度监控、可用性检查、代码大扫除、GEO 调研和公司工作台意见处理等案例；它们是个人使用示例，不能单独证明通用效果。
- 部署能力不等于已验证的安全性。 插件可扩展会扩大可接入的外部权限；提示注入防护还需要工具白名单、凭证隔离、沙箱和经过验证的审批实现。
证据与限制
- 约 1600 行、无第三方依赖、启动低于 0.1 秒、常驻约 60 MB、1000 个连接时约 170 MB、派发约 1.5 毫秒，均为作者自述测试结果。原文没有给出硬件、负载、统计方法或测试代码，本条目未独立复现。
- 公司意见 80 多条、Claude 自主修改近 70 条、作者审批十几条以及可自动处理事项约一小时上线，均为作者对其公司场景的自述，不是独立审计样本。
- 事件只记录一次不自动保证外部副作用 exactly-once；网络重试仍需要幂等键、提交确认和对账。标记外部文字为“资料”也不等于沙箱隔离，实际效果取决于 Agent、工具权限与执行环境。
- 一种机制解释是：插件边界减少内核依赖，持久记录和按需唤醒减少空转，风险门禁则把高影响决策留给人。另一种可能是观察到的效率主要来自作者熟悉业务、固定技术栈、单一维护者和人工筛选；文章未设计对照实验来区分这些因素。
- 固定 8 跳可以限制循环开销，却可能截断合法长链路；其适用性需要按任务类型测量，不能将该阈值视为通用最佳实践。
相关链接