折腾了整整1年，毫无保留地分享一下我这套Agent自动化系统。

核心结论（一句话）

将 Agent 的启动改为事件驱动，以统一控制面完成路由、去重、执行与验证，并按风险过滤人工审批，才能把人的注意力留给少数真正需要判断的事项。

[[01-ai-agents/InfoQ-TiDB-薄Agent-Loop厚Control-Plane-Harness]]：Control Plane 负责稳定状态、权限、审计和恢复；本文补充个人系统中的事件接入与路由案例。
[[01-ai-agents/架构师-多Agent协作一致性-任务状态与证据]]：任务身份、幂等、状态和验收证据可用于检查本文描述的中台与 CI 是否可靠。

[[02-ai-coding/程序员的新岗位是监工-Codex负责人-我不想再同时盯10个Agent了-未来让系统接手分工-人只在关键时刻拍板]]：同样把人的职责上移到目标、风险和关键决策；该文侧重调度原则，本文提供个人实作流程。
[[01-ai-agents/从零设计生产级-Multi-Agent-Harness]]：同属 Agent 运行时工程；该文偏通用架构骨架，本文偏事件中台与 CI 落地经验。

把任务起点从人移到事件。 作者将聊天窗口式使用视为注意力瓶颈，尝试以定时任务、Webhook 和外部信号触发执行，让人不必逐个启动每项工作。
由中台统一接入和派发。 事件被压缩成稳定字段，再按 rules.json 选择模型、Agent、Skill、工作目录、并发度和通知策略；本地接单器长轮询领取任务，事件记录则用于追踪来源、执行与结果。
模型负责执行，Skill 固化 SOP。 作者按开发、运维和浏览器操作分配不同模型，并把任务细节沉淀到专属 Skill；执行端保留在可访问本地代码、账号和设备的机器上。
CI 把 Agent 的提交与线上交付隔离。 文章描述的五步是审查、检查、合并、发布、核实。审查只读且最多三轮；检查和发布在临时虚拟机中运行；合并受 GitHub 规则约束，最后查询线上版本确认交付。
只在高影响决策上打断人。 删除数据、停服、花钱、外发消息、产品方向、密钥和权限变更等事项需要确认。既有决定与“不做”事项被记录；产品反馈则由作者亲自筛选后再交给 Agent。
记录与可视化服务于持续调度。 中台保留事件、执行器、结论及会话链接，作者再用仪表盘观察任务流；这些数据可辅助调整规则，但不自动证明系统安全或效果可外推。

本文是作者对近一年个人与公司实践的经验分享，不是独立评测。文中 298 个合并请求、333 条审查问题、306 条修复、51 条最高级别问题，以及审查/上线耗时和成本均按作者口径记录，未独立审计。
“3 到 5 个会话”的说法归于文中引用的 DeepSeek 文章；朱元璋奏折故事亦为作者的历史类比，本条目未另行核实。模型名称、订阅价格和服务能力会随时间变化。
观察到的效率可能同时来自作者单人负责、统一技术栈、较高的业务熟悉度和专用设备，并不能单独归因于自动化中台。文中未充分说明队列认证、密钥隔离、Webhook 验签、故障恢复和回滚实现。
本地执行能减少凭证复制和跨境网络依赖，但也让持有浏览器登录态、发布权限与代码的设备成为高价值边界；临时虚拟机、最小权限、审计和对账不可省略。