最近读到 SRETALK 公众号「Flashduty AI SRE 技术揭秘」系列的第 9 篇，聊的是一个做故障排查的 AI Agent 在架构上最纠结的问题：Agent 到底该部署在客户内网里，还是部署在自己的云端？ 觉得思路很清晰，整理成笔记记在这里。
问题：数据在内网，Agent 在哪儿？#
故障排查类 Agent 必须能摸到客户的系统——查日志、看监控、上服务器跑命令，而这些东西大多藏在客户内网，外部根本进不去。
最直觉的方案是「数据不出门」：把整个 Agent 打包塞进客户环境，安全合规也好交代。但 Flashduty 的选择正相反：负责「思考」的部分永远留在云端，客户内网里只跑一个负责「动手」的轻量程序，他们称之为 BYOC Runner（Bring Your Own Cloud）。
先把「大脑」和「双手」拆开#
一个 Agent 可以拆成两块：
- 大脑：维护对话状态、组织发给模型的内容、写 prompt、调用模型、决定下一步用哪个工具；
- 双手：按指令跑命令、读文件、调外部服务，把结果带回来。
打个比方：大脑是坐在总部的老师傅，双手是派驻在客户机房的操作员——老师傅在电话里说「看看这台机器的日志」，操作员照做，再把看到的内容念回来。
判断标准只有一条：大脑跟着用户入口走#
用户的对话入口在哪里？在浏览器里，在 IM 里——都在云端。所以大脑就放在云端。
为什么这么强调「大脑和入口在一起」？因为两者一旦分家，每次通信都要跨一道边界，每跨一次都要交一笔「过桥费」。而且这不是建桥时的一次性投入，是永远要持续缴的运营成本。具体有三笔：
- 消息与状态同步。模型逐字吐出的回答、对话状态的每次变化，都要从客户侧实时传回云端，等于把整套对话运行机制（排队、加锁、事件入库）在跨网络的场景下重做一遍。
- 升级与版本混乱。大脑是迭代最快的部分。如果它散落在每个客户环境里，每次改动都是「给成百上千个客户统一升级」的大工程。原文举了个例子：连那个薄薄的「双手」程序都已经有了一整套版本管理——定时心跳上报版本号、云端下发建议版本和下载地址、低于版本下限就不派活——而那个版本下限来自一次真实事故（旧版让多个对话共用目录，知识文件放错了位置）。把大脑的复杂度乘上去，每次发版都是噩梦。
- 调用模型要绕路。大脑在客户侧，每次调模型都要穿过客户的代理、审计和白名单，任何一环卡住，都是远程够不着也看不见的。
云端大脑的意外红利：跨环境协同#
大脑放在云端还有个额外好处：它站在所有环境的「上方」。客户的系统往往分散在办公网、生产机房、另一朵云的另一个区域——一次排查可能既要看代码变更，又要看指标曲线。大脑在云端，天然能同时看到所有连上来的「双手」，将来就能让 A Runner 读代码、B Runner 查指标，再放在一起推理。
原文也坦承这还是规划中的方向（目前一个对话选定环境后就固定在那里），但关键在于：大脑在云端时，实现这件事只需要改大脑里的调度逻辑，不用在客户环境之间打通网络、也不用让多个大脑互相同步。
「双手」的设计守则#
「大脑在云端」要成立，客户侧程序就必须足够轻、足够守规矩：
- 只往外打电话，不接电话：Runner 主动向云端拨出 WebSocket 长连接，云端借这条线派任务、收结果。客户防火墙不需要开放任何入站端口——这在企业安全评审里是可以直接写进答案的事实。
- 线上只传「干活指令」：连接上只有任务编号 + 做什么 + 参数。没有 prompt、没有对话记录、没有工具定义，Runner 也从不调用模型。
- 派活规则简单到能背下来：团队专属 Runner > 账号共用 Runner > 云端沙箱。铁律是绝不派到别的团队的 Runner；对话一旦选定环境就不再更换；用户指定的环境离线了就直接报错，绝不悄悄换个地方执行——偷偷改变命令的执行位置，比报错糟糕得多。
- 断线时由平台等 30 秒：连接抖动时先等 Runner 重连，期间一个包都不发、已派的任务绝不重发（避免同一条命令跑两遍）。之所以由平台等而不是 Agent 等，是因为 Agent 手里没有合适的等待手段（
sleep会被命令安全检查拦截）。30 秒还连不上，就返回一段专门写给模型看的指引：任务没送达、什么都没执行过、重试不会重复执行；再失败就把结论交给用户并如实上报阻塞性故障。 - 升级时平稳交接：云端滚动升级时旧节点停止接新连接，心跳发现归属变了就主动断开让 Runner 重拨。反方向的克制是：Redis 抖动时故意不断连，不让一次缓存抖动放大成所有客户同时掉线。
结论什么时候反过来#
判断标准是「大脑跟着入口走」，而不是「大脑永远在云端」。如果客户要求整站私有化、连网页入口都装在客户内网，那大脑就该整个搬过去；如果连模型都要本地化，那入口、大脑、模型全在客户侧，反而云端那部分要重新考虑。
过桥费的根源从来不是「大脑在云端」，而是大脑和入口分了家。 设计架构时可以先找到用户从哪里进来，把大脑放在它旁边，再数一数每次跨边界通信要交什么费用。
原文还明确了三件不做的事：不代管客户的 Runner、不从云端反连客户内网、不在多个 Runner 之间做按负载的智能调度——Runner 是对话的「归属地」，不是可以随意调配的资源池。
小结#
- Agent = 大脑（思考、调度、调模型）+ 双手（执行）；
- 一条判断标准：大脑放在用户入口的同一侧；
- 大脑与入口分家的代价是三笔永久的「过桥费」：状态同步、版本升级、模型调用绕路；
- 客户侧只留一个主动外连、只传指令的轻量 Runner，换来的是零入站端口和未来的跨环境协同。
本文是我对公众号 SRETALK 文章《AI SRE 技术揭秘：AI Agent 大脑到底应该放到哪里》（发布于 2026-10-26）的阅读整理与改写，版权归原作者所有。 原文链接：https://mp.weixin.qq.com/s/FEJubIKFSdybhpr20QWGjw