2 篇博文 含有标签「ops」

AI 平台团队有四名工程师。他们七个月前发布的内部 Agent 现在每天为 200 名员工回答问题。在第一个月，创始工程师亲自处理了每一个 Slack 消息——周二晚上 11 点，周日上午，甚至公司团建的晚上。随后，她因推动采用率方面的贡献而晋升为资深工程师（Staff Engineer），三周后，她在下午 6 点后就不再查看频道了，因为那是资深工程师该做的。原本打算取代她的值班轮换（on-call rotation）从未正式化，因为运营模式总是打算在“试点之后”再解决。

当 Agent 针对四分之一的用户静默降级的那天——一个悄然落后的检索索引，或者改变了拒绝行为的模型版本切换，或者是架构轮换后现在返回空数组的工具——投诉并不会降临到平台团队的传呼机（pager）上。它们落在帮助台队列中，由那些无法访问 Agent 追踪（traces）、不知道什么是系统提示词（system prompt）、并且被 IT 部门告知该 Agent “由 AI 团队负责”的人员处理。从第一个用户投诉到第一位工程师查看 trace，中间过去了 16 个小时。平台团队没有人玩忽职守；只是根本就没有人在执勤。

用户输入：“每周二提醒我检查那个集成。”Agent 创建了一个 cron 条目，返回礼貌的确认，随后会话关闭。六个月后，用户调换了团队。该集成在上个季度已被弃用。Cron 仍在运行，调用着在 4 月份轮换过的 API 密钥，发送到在 5 月份归档的 Slack 频道，费用计入无人查看的项目预算。Agent 完全按照要求执行了操作。出问题的是那个“要求”，它随着时间的流逝变得不再适用。

这不是某个特定 Agent 的 bug。它是这类事物的共性。当我们赋予 Agent 调度持久副作用的能力时——如 cron 任务、Webhook、轮询循环、工作流触发器、日历邀请、定期查询——我们就创建了一类生来就没有生命周期的基础设施。“创建”原语显眼且容易，“删除”原语、“审计”原语、“继承”原语——它们并不具有同等的地位，因此未被使用。

除非你主动去寻找，否则代价是隐形的，而此时恰恰没有人会去寻找。