一个真实的工程实践：把"读 issue、写代码、做代码审查、改 bug、合并、上线巡检"这条软件维护流水线，交给七个各司其职的自动化"数字员工"来跑。本文写给所有对"用 AI 维护项目"感兴趣的人——不需要你是程序员，也能看懂它的门道。

先讲个故事

想象你给一个软件项目提了个需求，写成一张"工单"（在开发里叫issue）。

在很多团队里，接下来会发生的事是：工单躺在列表里等人看；某个工程师有空了，读一读，觉得靠谱，于是动手写代码；写完提交一份"改动包"（叫PR，Pull Request）；另一个同事抽空帮他审查（code review）；审出问题打回去改；改好再审；通过了点合并；最后部署上线，再盯着监控看有没有出岔子。

这条链路里，每一步都要"等一个人有空"。

在我们维护的 Heron 项目里，这整条链路——从工单进来到代码上线、再到线上巡检——大部分时候没有人在中间等。它由七个 AI Agent（你可以理解成七个 7×24 在线的"数字员工"）接力完成。人类做的，是定方向、拍板有争议的事、以及在 AI 拿不准时兜底。

这篇文章，就带你认识这七位"员工"，看看它们怎么配合、又怎么被约束着不闯祸。

Heron 是什么？一句话：它是一套"AI 接口性能监测系统"——通过分析网络流量，测量大模型（LLM）服务到底快不快、稳不稳。这是一个开源软件。 本文不展开讲 Heron 本身，Heron是用来观察AI智能体的，而今天我们来说的是AI智能体又是怎么来开发维护Heron的。

为什么要这么干？

先说动机，因为这决定了整套设计的取舍。

软件维护里，大量工作是"显而易见但很费神"的。比如代码审查，一个有经验的人看 PR，80% 的问题其实是套路化的——某处忘了同步改另一处、某个老坑又踩了一遍、某个边界没考虑。这些不难，但需要人静下心一行行看，很占精力。

我们的核心思路不是"让 AI 取代人"，而是：

> 让 AI 把"显而易见的 80%"先处理掉，人类只在真正需要判断力的地方出场。

于是我们没有造一个"什么都管"的超级 AI，而是拆成了七个职责单一的小 Agent。每个只干一件事、干好一件事——这也是软件工程里一条很老的原则：职责单一，组合成线。

认识这七位"数字员工"

我把它们按工单在流水线上的旅程顺序介绍。为方便记忆，我给每个起了个中文岗位名（括号里是它们在代码里的真实代号）。

1️⃣ 分诊员（triage）——工单进门的第一道关

每当有人提一张新工单，分诊员第一个上岗。

它的工作很像医院急诊的分诊台：读一遍工单，判断这事该不该做、能不能做。它会按一套严格的"门槛"来评估——比如：需求说清楚了吗？是不是真的属于这个项目该解决的范围？信息够不够动手？

然后它给出三种结论之一：

做：贴上一个"可以试"的标签，自动喊醒下一位员工（开发员）。

需要更多信息：留言告诉提需求的人，到底缺了什么、补什么才能往下走。

跳过：这事不该自动做，留给人来定。

注意一个细节：分诊员不会自作主张写代码，它只做"该不该往下走"的判断。门槛故意设得偏严——宁可多问一句，也不要让机器在没搞清楚需求的情况下乱动手。如果它判断错了，人类随时可以手动给工单贴标签，强制启动或叫停。

> 💡给非技术读者的类比：分诊员就是前台兼接线员。它不解决问题，但决定"这个电话该转给谁、还是该先让你把话说清楚"。

2️⃣ 开发员（wiwi）——真正动手写代码的那个

工单一旦被分诊员放行，开发员 wiwi接手。这是整套体系里"最像程序员"的一位。

它会：

3️⃣ 审查员（vivi）——挑刺的那位

开发员提交后，审查员 vivi上场，做代码审查。

但这里有个关键的前置条件——它不是立刻就看。它会等一个叫CI的自动化检查先跑完。

> 💡CI 是什么？可以理解成"自动质检流水线"：每次有人提交代码，机器会自动编译、跑一大批测试，确认没把现有功能搞坏。

只有 CI 通过了，审查员才出场。为什么？因为如果代码连编都编不过，花算力让 AI 去做精细审查毫无意义——先让质检把"连门都进不了"的挡掉。这是一条很省钱、也很务实的设计。

审查员看完，会给出三种结论之一，跟人类审查员一模一样：

> 💡 这是整套设计的灵魂之一：永远不要让 AI 陷入无限循环。给每个自动流程设一个"刹车"，超过就交还给人。

5️⃣ 合并员（auto-merge）——按规矩落地

当审查员给出"通过"，合并员检查一组硬性条件，全部满足才把代码正式合并进主干（并顺手删掉临时分支）。

但请注意——合并员不是 AI，它是一套死板的规则。它只在以下条件同时成立时才动手，比如：这是 AI 开发员出品的改动、审查员确实给了"通过"、改动的发起人在一份受信任名单里，等等。

这是个有意思的设计取舍：

> 不是所有自动化都该用 AI。越是"扣扳机"（合并、上线这种不可逆）的动作，越应该交给可预测、不会发挥的规则去把关，而不是让 AI 临场判断。

换句话说：让 AI 负责"思考"，让规则负责"扣扳机"。而且，自动合并只对"项目维护者本人的低风险改动"开放；其他任何人的 PR，AI 的审查都只是"参考意见"，最终还是要人来合并。

在合并之后，我省掉了针对各个软件项目的特定的打包部署准生产/双跑/混沌工程中的一系列智能体（实际上这个项目里还有另外3位数字员工是负责部署和功能验证以及安全检查），这部分每个软件项目会有些不同，尤其涉及到环境，还会涉及到密钥/密码等，就不在这篇文章里说了。我们主要来看看相对标准化的智能体们。

6️⃣ 巡检员（mara）——盯着线上的哨兵

前面五位都在管"代码怎么写进来"。第六位，巡检员 mara，管的是"上线之后稳不稳"。

它每隔几分钟去探一次线上服务的健康状况，专门盯几类问题，比如：

7️⃣ 体检员（probe）——开工前先验环境

最后一位最低调，但少了它整条线都可能莫名其妙地崩。

这些 AI Agent 都跑在我们自己的一台服务器（自托管运行器）上。这台机器需要装好一堆东西、配好网络，AI 才能正常干活。体检员 probe就负责在每次环境有变动（比如机器重装）后，把这些前提条件一项项检查一遍，哪项不达标，一眼就能在日志里看出来。

它同样不是 AI，就是一套朴实的检查清单。但它体现了一条工程经验：

> **自动化系统最怕"环境悄悄变了"导致的离奇故障。 与其等出事了挠头排查，不如提前用一个"体检"把环境钉死。

把七位串起来：流水线全景

现在把它们放到一张图里，看一张工单是怎么"自己走完"全程的：

顺利的话，从工单进来到代码合并，**全程没有人在中间等**。人类只在两种时刻出现：一开始定方向，以及 AI 拿不准、吵起来、或线上告警时来拍板。

最关键的部分：怎么让 AI 不闯祸？

很多人一听"让 AI 自动改代码、自动合并"，第一反应是：这不得出事？

问得好。这恰恰是整套体系里我们最用心的地方。我们靠四道"护栏"把风险摁住：

护栏一：只给"只读"权限。

审查员看代码时，我们只允许它"读"和"搜索"，**明确禁止它修改、删除任何文件**。它能看、能提意见，但碰不了东西。能动代码的只有开发员/返工员，而且它们动的是隔离的工作分支，碰不到正式代码。

护栏二：质检（CI）必须先过。

任何 AI 写的代码，都得先过自动质检——编译、跑测试。过不了，后面的审查、合并根本不会启动。AI 的"创意"必须先撞过这道客观的墙。

它不是万能的

• 它擅长“显而易见的 80%“，但搞不定真正难的判断。 复杂的架构取舍、有歧义的需求，仍然得靠人。
• 七位里只有四位真正“用 AI“（分诊、开发、审查、返工）。合并员、体检员是规则脚本，巡检员是“规则发现问题 + AI 写报告“。这是有意为之——能用简单规则解决的，绝不硬塞 AI。
• 它要花算力。 一份中等大小的改动，审查一遍大约要十几分钟、消耗一定的计算资源。所以我们才设了“质检不过就不审“这种省钱的闸。
• 它需要持续调教。 那份“避坑清单“不会自己长出来，是人一条条喂进去的。

如果你也想试试，几条朴素经验

• 拆小，别造超级 AI。 七个只干一件事的小 Agent，比一个什么都管的大家伙更可控、更好调试。
• 每个自动循环都要有刹车。 设个次数上限，超了就停、就喊人。这一条能帮你躲掉绝大多数“AI 失控“的噩梦。
• 让 AI 思考，让规则扣扳机。 不可逆的动作交给可预测的规则，别让 AI 临场发挥。
• 能用规则就别用 AI。 不是所有自动化都需要大模型。
• 喂给它你的独家经验。 AI 的上限，往往由你给它的背景知识决定，而不是模型本身。
• 永远留一条人类兜底的路。 最好的自动化，不是“没有人“，而是“人只在关键时刻出现“。