AI开发牧安 · 第6期 定了三级架构，可只有我一个人盯

记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

一套架构、三级平台、三个AI工具和一个分裂的开发日常。

第2期讲过：一个后台装不下，直觉上得拆成三级。那期是"感觉"，这期把感觉变成能照着写的东西。随着不断的功能叠加，很有必要把"平台长什么样"钉死了——不然边写边改，迟早散架。

先治好自己的"人格分裂"

写总纲前，产品文档里是分裂的。主文档写的是 `paramiko` 拿 root SSH 直连客户机、Windows 靠本机 `win32evtlog`；功能扩展那块又演进到 Agent 主动推送；PRD 又冒出一句"零依赖本机引擎"。三套采集说法并存。形态上也打架：一会儿"单机兜底工作台"，一会儿"分布式平台"。这个事情其实是用探针和平台使用了不同的开发工具造成的。两个工具互不沟通，互不统属。甚至也不知道对方的存在，就连webhook功能的调试也是我在中间传话完成的。

想好了要分级之后，立马就干了一件事：停下开发，从头来写《产品总纲》，第一行就标它是**单一事实来源（SSOT）**——以后任何文档跟它冲突，以它为准并回改。这步看着虚，其实最关键。一个人开发，最怕自己前后矛盾还不知道；有个"最终拍板的地方"，后面才敢放心往下写。

图片

 四条拍板（ADR）

总纲里我没写感想，写的是四条架构决策记录（ADR），每条都带理由：

• ADR-1 采集：统一三级 Agent / 探针推送为主，三级数据报给二级，二级报给一级。也支持直报一级。理由就一句——不可能每家客户都买二级平台。针对小点的客户环境，一个三级 Agent / 探针就够了，一个不够就上俩，也比上一个二级平台更便宜。
• ADR-2 存储：分级存储。一级中心多库、二级客户本地库、三级只留轻量缓存/队列。理由是二三级得能断网自愈，一级才负责聚合。
• ADR-3 形态：采用三级平台架构，取代旧"单机兜底"假设。平台化目标形态，这次一次性定死。
• ADR-4 引擎：自研只做骨架 + 轻量检查（资产/终端/DLP 扫描/日志），重度检测（EDR、深度威胁）接商业引擎。不自造轮子，也不对客户过度承诺。

当时就拍了的几件小事

有些不用细研究，直接定：

• 端口：一级 8800、二级 8801、三级 8802，三级单实例再锁个 8803 防重复启动。
• 套餐：PRD 写三档、用户手册写四档（多了个"增强运营包"），我合并成三档主线——基础兜底 / 标准运营 / 合规加固，"增强"并进标准；专属定制当可选附加，不进标准三档。目前开发过程中不做套餐和功能限制，预留一下就行了。
• 能力边界：销售口径钉死——牧安是的三级结构的 MSS 平台，重度检测接商业（有些大厂做的还是可以的，超大客户大概齐也不买我这玩意儿），不把"平台"当空话也不过度吹。

图片

几个到现在还悬着的

一个人鼓捣的好处是快，坏处是这些"产品判断"没人跟我拍。我的笨办法：先按最小可用往下走，遇到再调，不为了把文档写满卡在那儿。

说点实在的。最后留了几个"待我拍板"的点，有些到现在没完全定：

图片

MVP 先落哪条线（三级+二级？三级+一级？还是齐发）、一级多租户边界（只我自己运营方一家用，还是以后面向多家 MSS 共享）、二级给子公司开的是只读还是可操作、小客户无二级直连一级时租户归属怎么算、一级默认能外发哪些第三方…… 等等等等，不只有7个决策点，后面可能还会有70个。

一个人赶三驾马车

总纲写定，心里那张图才算真正有了边界。可真到动手那天，我盯着这三摊东西，突然意识到一个尴尬的事实——

**这仨，压根不在同一个地方。**

图片

L1 是在华为云码道（CodeArts）里改出来的。它的底子就是前面几期说的 WN101，最早就是在码道里一行行敲起来的——现在翻那些修复记录，"修复人"那一栏还都挂着 CodeArts。我从 WN101 砍掉臃肿、补上"服务运营"模块，出来的就是一级平台。

L2 是另一回事。它是在 qclaw 上，把 WN101 整个目录复制过去，再往客户侧改：资产管理模块、客户本地自服务，都是 L2 的活。两套代码同源，但已经各自长开。

L3 呢，一直在 workbuddy 里，从头写到 v0.5——流量探针、AI 告警分析、双形态部署，全在它上面迭代。

总之就是workbuddy出任务书，L1平台是华为云码道开发，L2平台是qclaw开发，L3平台是workbuddy开发，三级联调是workbuddy干。唯一宗旨就是谁出任务谁负责验收。

现在已经开始三家马车并排跑了，轮流抽鞭子。其实抽鞭子这活儿也不好干，容易抽错，容易重复抽。

真正分裂的，是派活的人

更魔幻的在后面。三级架构定了之后，活儿怎么派、联调怎么验，全是 workBuddy 出的。

L3 那个"Agent 注册导入 + 资产上报"改造，任务书开头就写："交付对象：另一个独立任务/人。"——听着像派给团队里的谁。可实际上，那个"独立任务/人"就是我自己。workbuddy 把任务拆成文件、改动点、验收标准；我拿着它，去 qclaw 改 L2、去 workbuddy 改 L3。

一个人，分饰两角。 一个我坐在工具前面出任务书、派工单、写联调结论；另一个我拿着这些单子去码道、qclaw、workbuddy 里改代码。报告上那两个名字，其实是一个人。

末尾签名"测试人员：Buddy + 老尹"。

图片

分裂是有代价的

三套工具各长各的，最直观的代价就是**一致性兜不住**。

真实案例：L1和L2有些基础功能是一样的，比如图中的系统管理，华为云码道开发完了，还得让qclaw复制过去。qclaw复制过去了，告诉我完成了，实际上服务器IP管理卡片里面的绑定内网IP、公网IP的功能丢了。

图片

多说一句，为什么要绑IP，绑定IP之后，二级平台需要知道自己是谁，三级平台要进行webhook上传数据，不能填一个内网IP。

图片

还有一些隐藏更深的坑：

L1、L2 登录路由是 `/api/auth/login`，L3 偏偏是 `/api/login`，少一段。没人觉得这算事，直到三级链路跑起来，L3 死活登不进，才回过头改。

L2 往 L1 上行数据，信封格式对不上。L1 要 `schema_version`、`event`、`event_id`、`agent` 四个字段，L2 发的是另一套。HTTP 400 直接甩脸。这是三套代码各写各的接口、没人统一约束的必然结果——要不是联调，这坑能藏到上线。

图片

 但一个人也有好处

话说回来，这种"人格分裂"的开发日常，不是没有甜头。

不用开会。不用等评审。想法到落地的链路短得离谱——早上觉得 L3 该加个资产上报，workuddy 出个任务书，中午就能联调了。没有跨部门对齐，没有排期会，没有"这个需求再评估一下"。

代价是没人帮你 review。一致性、接口对齐、跨级映射，全得自己兜底。漏了就是联调时挨一记。

所以三级架构真正难的，不是"怎么分"，是"分完之后，一个人怎么把三套各长各的东西，拧成一条能跑的链路"。

下期聊聊告警列表里那一长串红点——我怎么给每条告警都配了个 AI 军师，让它自己告诉我该不该管。

本系列记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

上期：《数据是怎么自己进来的》；下期预告：《 手搓了一个AISOC》。