跨国深谈← 返回←当代码生成加速，谁来填运维的坑：用后台智能体接手生产环境长尾工作

当代码生成加速，谁来填运维的坑：用后台智能体接手生产环境长尾工作

关联

人物 Justin Smith

公司 Resolve AI · Slack

概念 智能体 · 后台智能体 · 生产上下文 · 可观测性 · 沙箱 · 部署监控

工程师 70% 的时间其实不在写代码，而在运行代码——维护平台、调试事件、值班、发补丁、处理警报。AI 辅助编程让代码产出和发布速度飙升，非开发者甚至也能往生产环境推代码，而现有的结构根本没准备好应对这种变更量，生产环境的复杂性正在失控 。出路是用 AI 智能体来应对 AI 自己带进系统的新增复杂性：让智能体在生产环境里帮你跑运维、盯系统。

Resolve 的切入点正是这里。他们把智能体分成两层：一层是应急的值班智能体（接警报、查根因、协调跨团队事故）；另一层是后台智能体，专门处理那些「不是起火、但总得有人干」的长尾工作——这正是 Justin Smith 这一集的重点 。

后台智能体盯的是那一大堆没有明显触发点、却时刻消耗工程师精力的活：盯着刚发的部署是不是健康出笼；每天出一份系统状态晨报让大家对齐；留意某个 P99 延迟漂移（P99 指排名前 1% 的最慢请求延迟）是不是又冒头了；或者定期做健康检查，别等客户投诉了才发现问题 。这些事未必会触发警报，但总得有人负责。

什么是任务：执行 + 生产上下文

任务由两部分组成：执行，以及理解如何执行的生产上下文。执行引擎能调用工具、加载仪表盘；但真正判断「这个指标看起来不对劲」的，是生产上下文 。

这里有个关键区分：执行能帮你打开仪表盘，但只有上下文能告诉你「这感觉不对」——哪怕你一时说不清为什么。做后台智能体，执行引擎和生产上下文缺一不可 。如果智能体没有真正理解你的环境、服务怎么交互、热点在哪，模型再聪明也无法在具体任务上成功；它必须有底层的学习系统来捕获这些知识，并且随系统演进而持续更新 。

智能体怎么触发、怎么跑

后台智能体有三种触发方式：按计划（比如每天出晨报、每周四值班交接时自动汇总上周趋势）；基于事件流（CD 流水线走完、Slack 消息进来时触发）；基于消息（你直接跟它说「去做点什么」）。

它永远在云端运行，合上笔记本也没关系；跑在沙箱（一种隔离的运行环境）里，底下自带文件系统，能在干活时自我组织；底下还有一层知识和记忆系统——智能体能反思刚做的任务、下次做得更好，或者把从一个任务里学到的东西迁移到另一个任务上，因为这是一套跨所有任务共享的知识系统 。

四种已经跑通的工作负载

**部署监控**是最重的一个。环境里的任何变更都是出岔子的机会。大家都有 CI/CD 系统，但它的检查通常只是基准线，不够详尽，覆盖不了每次发布的独特变更；而且像功能开关（feature flag，一种不用改代码就能开关功能的机制）或基础设施变更往往根本不走 CI/CD，也没有监控，你只能寄望于出了事警报响、值班人员被吵醒 。

智能体能做的事比标准 CI/CD 更深：它会看这次到底改了什么、哪些遥测数据能帮判断变更好坏，然后针对这次发布定一个专属检查计划。Justin 在演示里展示了智能体看到「结账服务替换了货币服务」后，不仅监控结账延迟和错误率，还顺着因果链去查 Kafka 流水线是否健康 。这些检查不是硬编码的，智能体有自主性——它可以决定「这类问题偶尔才冒头，我想再盯一小时」，甚至三天后回来复查这个部署是否还健康 。

计划性的健康检查和异常探测就是定期看看仪表盘、或者临时设一个智能体盯一周某个第三方服务 。运营报告和交接是那些为了传播信息、同步状态的仪式性总结 。

最有趣的是工程问题的第一响应。触发它的是一条 Slack 消息——工程师最大的隐性成本之一就是盯着 Slack 频道、随时被打断去回答别人的问题 。

Resolve 的智能体会被动监听关键频道，判断自己有没有足够信心回答；有趣的是，它还能通过 Slack 私信问你「我想我知道答案但不确定，我回复之前你能帮我确认一下吗？」——这种涌现行为（emergent behavior，系统设计中非预设、自然冒出来的行为）在用着用着会变得很有意思 。

智能体怎么设置、怎么接入

设置不靠填表单，靠对话：你跟智能体说「我想给团队做一份定期健康摘要」，它会先探索你的环境，反过来问你几个问题（想看什么、要多详细），然后建好初始版本让你测，测好了再分享给团队 。你还可以直接在 Slack 里告诉它「刚才那份报告太冗长了，缩短点」，它会更新自己的任务模板，下次自动调整 。

如果你内部已经有自己的智能体框架，Resolve 提供的东西都能通过 MCP 服务器（一种让模型访问外部工具和上下文的协议标准）接入——你可以把 Resolve 的学习系统和生产上下文能力接到自己现有的系统里，不用重新造轮子，也别去重复造已有的技能 。

Justin 最后强调：运营工作的成本不在任务执行本身，而在环境复杂性。后台智能体按计划跑、按触发器跑，高度可组合；但最大的价值在于——理想的交互发生在你本来就待着的地方（Slack 或 MS Teams），而不是逼你多开一个工具 。

本集带走

• 写代码从来不是瓶颈，运维才是：工程师 70% 时间花在运行代码上；AI 加速编码只会让生产端更复杂，现有结构应对不了变更量。
• 任务 = 执行 + 生产上下文：执行能加载仪表盘，但只有生产上下文能判断「这感觉不对」——两者缺一不可。
• 后台智能体三种触发方式：按计划、基于事件流、基于消息；永远在云端跑、沙箱隔离、带共享记忆系统。
• 部署监控比标准 CI/CD 更深：智能体看这次具体改了什么、顺着因果链查相关组件，且非硬编码——能自主决定「再盯一小时」甚至三天后回来复查。
• 第一响应智能体的涌现行为：被动监听 Slack 关键频道，有信心就直接答，没信心会私信你确认后再回复。
• 通过 MCP 服务器接入现有框架：如果你有自己的智能体框架，Resolve 的学习系统和生产上下文能力可以作为扩展接入，不用重复造技能。
• 交互应发生在你本来就在的地方：智能体的主战场应该是 Slack/MS Teams 这些你日常待着的工具，而不是逼你多开一个面板。

我们需要全栈 AI。这不再仅仅关于模型。
We need full stack AI. It’s not just about the models anymore.
—— Justin Smith · [03:00]

你必须在生产内部使用 AI 来应对 AI 带入你的产品或系统的复杂性增加。
You’ve got to use AI inside of production to deal with the amount of increase of complexity that AI is putting into your product or into your system.
—— Justin Smith · [03:56]

生产上下文重要得多，因为去检查仪表盘是一回事。说那个指标看起来不对劲是另一回事。
The production context is just way more important because it’s one thing to go check a dashboard. It’s another thing to say that metric smells off.
—— Justin Smith · [10:38]