技术 2026-07-14 · 约 12 分钟阅读

用 AI Agent 搭建自动化开发流水线

半年前我开始折腾一件事：能不能用 AI Agent 把日常开发任务的流转过程全部自动化掉？不是写个 Copilot 帮你补全代码那种，而是从需求分析、任务拆分、开发、部署到测试验证，整条链路让 Agent 自己跑完，人只在关键节点做判断。

这篇文章记录这套系统的架构设计、踩过的坑，以及——最重要的——为什么最终我选择了一个看起来「不那么 AI」的中心化调度方案。

整体架构

系统的代号叫 dev-env，搭建在 Hermes Agent（一个开源的 AI Agent 框架）之上。核心组件三个：

Portal（:8090）：统一入口，所有任务从这发起，走 LDAP 认证
管理中心：任务管理、状态查看、日志检索
Runner 集群：真正执行任务的 Worker，只干活不思考

听起来像传统的任务调度平台，确实如此。但关键区别在于：任务的需求拆分、代码编写、质量判断，全部交给 AI Agent 完成，平台只负责流转和兜底。

状态机：一切的骨架

每个任务的生命周期被硬编码成一个有限状态机：

init → requirement → developing → deploying → testing → done

状态的流转规则写在代码里，不可被 Agent 修改。比如 developing 状态结束后，必须进入 deploying，不能跳到 done，也不能回退。每个状态有明确的入口条件和退出条件，全部代码校验。

为什么要这么死板？下面会说。

中心调度器：30 秒的心跳

系统里有一个 scheduler.js，每 30 秒轮询一次所有处于活跃状态的任务，检查它们的当前状态，决定是否推进到下一步。Runner 集群本身不做决策——它们只是调度器的手和脚。

这个设计有一个核心逻辑：PM Agent（负责需求分析）输出的不是一段自然语言描述，而是一个结构化的 task-plan.json：

{
  "phases": [
    { "name": "backend-api", "type": "develop", "desc": "..." },
    { "name": "frontend", "type": "develop", "depends_on": ["backend-api"] },
    { "name": "deploy-staging", "type": "deploy" },
    { "name": "e2e-test", "type": "test" }
  ]
}

调度器读这个 JSON，按 phases 数组和依赖关系自动创建子任务并分发给 Runner。Agent 负责生成计划，代码负责执行计划。判断归 Agent，流转归代码。

为什么不用「完全自主」的 Agent？

这是整个系统设计中被问得最多的问题。

理论上，你可以给 Agent 一个大的 prompt：「你是一个全栈工程师，请完成以下需求，自主决策每一步」，然后让它自己规划、自己执行、自己验证。听起来更优雅，更「AI Native」。

但实际跑下来会发现：Agent 不可靠。

具体来说有这么几类问题：

状态漂移：Agent 跑着跑着忘了自己在哪一步，重复执行已完成的任务，或者跳过关键步骤
死循环：测试失败后 Agent 反复尝试同一种修复方式，不懂得换策略
静默失败：某一步报错了但 Agent 判断「问题不大」继续往下走，最后整条链路在错误基础上堆积
无法恢复：Agent 中途崩溃后没有上下文快照，只能从头再来

这些问题的根源在于：LLM 的决策是概率性的。你让它做一次需求拆分，它做得很好；你让它连续做 20 次状态判断，只要有 1 次出错，整条流水线就可能跑偏。

所以我最终的哲学是：

流程门禁走代码，业务判断走 Agent。 关键的状态流转、依赖校验、失败重试逻辑，全部硬编码在调度器里，Agent 不能干预。Agent 只在「需要理解语义」的环节出场：读需求、写代码、判断测试结果是否合理。

这听起来不性感。很多 AI Agent 的演示视频都在强调「完全自主」，但你仔细看那些 demo，跑的都是单次任务、精心准备的场景。真正的生产环境，可靠性比智能更重要。

模型选择：从 GLM 到 ARK

系统上线时用的智谱 GLM-5.2，整体能力不错，但在长上下文推理和复杂 JSON 输出上偶尔会翻车。后来迁移到了火山引擎的 ARK Agent Plan，主要原因是对 Agent 场景做了专门优化，工具调用的稳定性明显更好。

不过迁移过程也踩了两个坑：

坑一：QPM 限速

ARK 的辅助调用（auxiliary calls，比如嵌入向量、内容审核）和主调用共享同一个配额池。高峰期 Runner 一多，辅助调用会被限速，导致任务排队。解决方案是给辅助调用单独申请了一个低优先级的 endpoint，和主链路物理隔离。

坑二：端点配错导致欠费

ARK 后台每个模型对应一个 endpoint ID，配置时手滑把推理 endpoint 写成了训练 endpoint。训练按量计费且贵得多，一个下午烧掉了正常一周的预算。发现后第一时间在 ARK 后台设置了每日消费上限，这个一定要提前配好。

半年下来的反思

系统跑了大半年，处理了上千个任务。坦率说，它没有完全取代人工——复杂需求仍然需要人去拆解和验收。但在以下场景，它的确大幅降低了重复劳动：

标准化的 CRUD 接口开发（填表式需求 → 自动出代码 → 自动部署 → 自动测）
批量数据清洗和格式转换
已有项目的 bug 修复（给出复现路径，Agent 自主定位并提 PR）

如果让我重来一次，最大的决策不会变：用状态机和调度器约束 Agent，而不是放任 Agent 自主决策。这不是对 AI 不信任，而是对系统的可靠性负责。Agent 是引擎，代码是底盘和刹车——光有马力大是不够的，你得能在弯道上停得住。

← 返回文章列表