一句话：把智能体当软件来管，而不是当玩具来试
9 月下旬，网络可观测厂商 Selector 推出 Selector Foundry，一套内嵌在其 NetOps 平台里的智能体运维方案。它最值得注意的不是又多了几个会聊天的助手，而是把智能体当成软件工程对象来治理：版本控制、代码评审、分阶段发布、历史回放，这些软件行业早年用来解决「敢不敢让程序上生产」的办法，被原样搬到了网络运维的智能体上。对正在把决策权交给智能体的运维团队，这套思路恰好回答了他们最担心的那句话——我凭什么信它能在生产里动手。
一支各管一摊的专家队伍，入口只管派活
Foundry 随平台交付六个正式可用（GA）的智能体。Rosetta 是对话入口与编排者，负责把一个问题路由给对的专家；Loom 做告警风暴的关联与根因，把跨域症状收敛成一次事件；TicketMaster 在 ServiceNow、Jira 等 ITSM 里开单并双向同步；Herald 把结论改写成给高管、运维或客户的口径并发布；Artist 按自然语言现场搭实时面板；Sculptor 负责造新的智能体。每个专家只管一块、只拿一套受约束的工具，这让它既好审计，也让回答更稳定。底层是一份统一的相关模型：从 300 多个来源采集遥测并归一化，把百万级信号在智能体开工前就收敛成「一次事件加命名根因」。
框架选了轻的：Pydantic AI，而非更重的套件
CEO 尼廷·库马尔（Nitin Kumar）解释，Foundry 的智能体跑在 Pydantic AI 上，刻意避开 CrewAI 这类更重的框架，选更简单、更确定的路线。智能体被定义成类似基础设施即代码的配置，配置驱动一个通用编排器，下面是领域专用代码。这个取向很克制：能力扩展不靠堆框架，而靠客户自己写配置、走自己的评审流程。库马尔的话点明了动机——过去平台只告诉了你哪里错了、数据怎么找，但「做什么、怎么修」仍是人工或写在应急预案里，Foundry 要补的就是这最后一层。
信任来自流程：Git、PR 评审、历史回放、一步回滚
真正让「敢让它做」成立的是那条软件工程式流水线。客户把智能体提交到自己的 Git 仓库，变更走既有的拉取请求评审；在智能体进入生产前，会针对客户的历史事件数据回放，并与每一次历史事件的真实结果比对，推广失败则一步回滚。这等于把「这个智能体上次的判断对不对」变成可验证、可回退的动作，而不是上线后靠运气。对受监管或高可用要求的团队，这比任何能力演示都更能过审。
两层护栏：既限成本，也限结论
库马尔描述了两类行为约束。一类是成本与 Token 上限：限定一个智能体在被判故障之前能调用模型多少次，避免它陷入无意义的反复试探烧钱。另一类是结论约束：如果你在报告一起 AWS 故障，就不能把锅赖给 GCP，也不许靠幻觉改归因。后一类尤其关键——它把「不许胡说」写成了可执行的规则，而不是靠提示词去求模型自觉。这种把治理前置到配置层的做法，正是 Foundry 区别于单纯聊天助手的地方。
优势与局限：客户能造自己的智能体，但 autonomy 仍是渐近线
优势在于把动作收敛进客户已有的采集与关联体系，几乎不用推倒重来；客户可以造自己的智能体，而不是被厂商固定的那套绑死，这对流程千差万别的运维团队很实用。局限也清楚：其一，GA 的六类智能体仍围绕基础设施支持场景，跨业务域的编排尚未展开；其二，完全无人值守是目标但库马尔直言短期内不现实，真实落地多半是「人仍在环」；其三，95% 降噪、10 倍快 RCA、70% 减 incident 等是厂商口径，需独立核验。关于定价与更细的客户规模，官方及行业暂未披露更多细节。
结语
Selector Foundry 把智能体运维做成「可评审、可回放、可回滚」的软件工程对象，是智能体从试点走向生产的一次务实示范。它真正有意思的不在某个智能体有多聪明，而在于用 Git 与回放替企业回答了那个最难的问题：我凭什么信它。至于这些护栏在真实高负载下能不能稳住，还要看后续客户落地与独立验证。