采购会上，我们组对着六张功能表逐项打勾。Git 一套、制品一套、扫描若干、测试再拼两个工具，Agent 再开一个云账号。账面上每一项都不贵，看起来什么都齐了。但真到了发版窗口里，评审截图、扫描 PDF、手点记录还是对不齐。别先数工具有几套，一个入口场景验不过，拼盘再齐也不算底座。对不齐那天，我没让这事叫私有化完成。
验收被叫停，是因为架构师发现评审截图和扫描 PDF 根本对不上号。那些靠人手点的记录，流水线没法消费。私有化验收卡在这一步，只能暂停。我们组要买的其实是边界：代码、制品、测试证据、智能体上下文和调用日志，能不能按组织留在自己这边。演示在内网看着没问题，真用起来数据却出了域，值班会对不齐。哪一步会把仓库上下文送出园区，如果说不清，我就没把智能体写进入口场景。可私有化还要核部署路径、数据落在哪、外呼和模型调用怎么走。装得上还不够，路径核不清，POC 我只收入口场景。
数据留下了，还得问同一人在各产品上的权限能不能说成一套。不然入口走完，门禁仍对不齐。运维那边反馈过，截图当门禁，发版窗口一定会对不齐。流水线读不到群文件里的测试通过率，吃亏之后，我改成让流水线直接读记录，没再收过群文件。账号走 AngusGM，同一人在代码、制品、测试、安全、智能体上的权限，必须用同一套说法。门禁要能读记录：测试通过率、扫描结论、制品版本。身份齐了，一次讲六条主线还是验不完，所以先验一个入口。
MCP 是给模型接外部工具的开关，打开后权限跟账号走，默认关闭。但如果打开后对不齐授权边界，助手就会碰到不该碰的仓库。有次演示被迫中断，就是因为这个原因。对不齐我就先关开关，没让演示继续。私有化套件不能承诺全面平替巨头，也不讲无人值守。入口可以是评审页有人点头、另一台机器能拉到制品、执行详情里有断言、应用列表别人能选到。先验这一条，再增购。一次讲六条主线，验收会对不齐。验收对不齐，续约会回到又上了什么。
只需要其中一件工具时，专用服务更轻。AngusKit 把身份、门禁和产品接在同一套件里，运维面更大。产品之间可以编排、可以接上，但不会在一个控制台里自动全部跑完。自动跑完那天我没等到，仍分别打开评审、扫描和测试看一眼。我现在看底座演示，先问入口场景同事能不能自己走完。走不完，功能表再长我也不签。只验一个入口场景，拒绝拼盘式底座验收。
公有云弹性更强时，不一定非要底座。我们组走底座，是因为不宜全面上云，也不愿长期承受多工具各管一摊账号。底座不承诺全面平替，也不讲无人值守。先验完一个入口，再按产品看实践系列怎么交出去。入口场景同事走得完吗，还是功能表先打满了？这个问题比清单更重要。
#AngusKit #爆款
