我经营着一家只有一个人的公司，但员工有九个——全是AI Agent，管财务的、管运维的、管代码的、管内容的，各司其职。上周它们一周出了三次事故，每次都不一样，但每次修完我都觉得，管Agent和管员工，道理其实是通的。
财务Bot给一家合作企业做管理报表时，发现三个数据源对不上：凭证明细库有三万七千多行，另一个全量快照有四万一千多行，中间差了七百多行；余额表这个月还没结账；现金流量表在两个地方各有一份，数字还不一样。任何一个数据源单独看都挺正常，放在一起就互相矛盾。
我当时的第一反应是"哪个源错了就修哪个"，但财务Bot的处置比我聪明：它先不急着改数，而是把每个数据通道的范围、完整度、时间戳都摸了一遍，然后定了一条优先级——系统权威输出排在凭证通道前面，凭证通道排在快照缓存前面。按这个顺序裁决，最后用最权威的那个通道做主表，其余做勾稽校验，三张报表才对上了。
这件事给我的启示很朴素：数据冲突的时候，不要问"哪个对"，要问"哪个离业务发生点最近"——离得越近的通道，权威性越高。快照是转手的，缓存是临时的，只有业务发生时留下的原始记录最可信。
运维Bot报了一个告警：代码仓库服务被系统杀了两次，重启了十六次，内存限制只给了512兆，正好被一次打包高峰撞穿。与此同时，另一个Bot在做网页数据抓取，一次启动了太多无头浏览器，峰值吃掉2.4GB内存，把整台机器的可用内存压到了红线以下。
这次处置分了三步：先定位内存大户排行，发现十几个常驻服务固定占掉5.7GB，浏览器进程是唯一的动态波动源；然后修复明确风险，把代码仓库的内存限制从512兆提到1G；最后提了一个系统性方案——改用接口直接取数，替代浏览器抓页面，从根上消灭波动源。
管服务器和管团队很像：光给每个进程加内存上限是堵，得同时有监控能发现谁在偷偷吃资源，还得知道波动源在哪，最后按未来半年的容量做规划。四层缺一层，事故就会换个马甲回来。
全栈Bot在做一套战略地图的版本管理，过程大概是：创建临时地图，发布第一版，修改画布，手动存了个第二版快照，又改了第三版——然后发现改坏了，需要回到第一版。
关键在回滚的细节：它回滚之前，先把当前这个"改坏了的第三版"自动备份成第四版，然后地图干净地回到第一版，临时数据清理得一点不剩。也就是说，回滚不是"丢掉现在的"，而是"存档现在的，再回到过去的"。之后运维升级系统也用了同一招：保留最近的回滚点，只清理隔了两版的旧备份。
这条规则我后来写进了自己的操作习惯里：每次切换状态之前，先commit一下当前版本。不管是对Agent改配置，还是自己改文件——先存档，再动手，操作就永远可逆。改坏了不可怕，可怕的是改坏了回不去。
回头看这一周的三次事故：数据源打架，教我要信离事实最近的那个；内存被吃，教我要分层防御而不是单点修补；版本改坏，教我要先存档再动手。
它们背后是同一个道理：AI Agent不是玩具，是真实的生产系统。你把它当玩具，它就用玩具的方式回报你——数据错了没人管，内存爆了没人知道，改坏了回不去。你把它当正经系统管，给它定优先级、设监控、留退路，它就能像个靠谱员工一样干活。
九个人的公司管起来要制度，九个Agent的公司，要的是一模一样的东西。
很多人会问：一个人怎么管9个Agent？ 靠规则和制度，不是靠盯着。每个Agent有自己的职责边界，任务完成必须留痕，出问题有监控告警，改任何配置先备份。跟管一个九人小团队没有本质区别。
数据源冲突怎么判断谁对？ 不要问哪个对，问哪个离业务发生点最近。系统权威输出优先于凭证通道，凭证通道优先于快照缓存。离事实越近的通道越可信，转手越多越要打折。
Agent会自己出事故吗？ 会，而且出得比人勤快。上周三次事故全是Agent自己搞出来的——数据源没对齐、内存没规划、版本没备份。区别是Agent出事故有日志可查，人出事故只能靠回忆。
普通人用AI需要这些吗？ 单点用AI（写个文案、查个资料）不需要。但当你开始让AI替你跑流程、管数据、做决策，它就是生产系统了——优先级、监控、备份，一个都不能少。