一个功能，代码早就写完了，上线却还要等。等测试排期，等环境准备，等另一个团队确认接口，再等发布窗口。中间有谁请了假，事情可能就先放在那里。
好不容易上线，出了问题，大家又被拉进一个群。开发问生产环境是不是改过配置，运维问这个版本到底动了什么，测试说当时用的是另一套数据。聊了半天，事情的来龙去脉才勉强凑齐。
做过软件的人，对这种场面大概不会陌生。每个人都很忙，事情却走得慢，还容易出错。过去，我们希望借助 DevOps，把工具接起来，多做些自动化，让开发和运维配合得更好。
现在 Agent 来了。它可以接下任务，读代码、做修改、跑测试，再把结果交回来。可如果每走到一个新环节，它都得停下来等人重新解释背景，再强的模型也只能陪着团队一起等。
我的看法是，今天这套靠人传话、靠人交接才能往下走的 DevOps 体系，根本撑不起未来。
这里有一笔账，一直没有算清楚：我们究竟花了多少时间，才让下一个人明白上一个人做了什么？又有多少问题，就是在这个过程中产生的？
说到 AI，大家很担心它忘记前面说过的话，或者理解错需求。这个担心有道理。可回头看看自己的团队，类似的事也没少发生。
一句“测过了”，能省掉多少前提条件。
比如，业务方说，这个功能先给几个老客户试用。产品写需求时，重点写了功能怎么做；开发照着实现，测试照着验收，最后运维把它发给了所有用户。
中间只要有一次交接漏掉“先给几个老客户试用”，后面的人就可能一路认真地做错下去。等出了事，再翻聊天记录，才发现原来有人说过这句话。
有时候，话也传到了，只是意思变了。测试说“我测的几个场景没问题”，传到下一位那里，就成了“测试没问题”。开发说“这次修改应该不会影响老接口”，到了发布说明里，可能只剩下“兼容老接口”。
“我以为你知道”“这个之前说过”“当时没想到还要专门写下来”——很多问题追到最后，都是这些熟悉的话。
所谓上下文，落到工作里，就是事情的来龙去脉：为什么这样做，哪些方案已经试过，哪里还有疑问，什么条件变了就得重新考虑。
这些东西很难靠几次交接完整留下来。说的人挑重点讲，听的人按自己的经验理解。有些条件被忘了，有些信息没来得及同步，还有些事情，双方都以为对方知道。
几个团队同时改东西时，就更麻烦。你依据的是昨天的配置，我看到的是今天的代码，文档还是上周写的。大家讨论了半天，甚至没有在说同一个版本的系统。
多开一次会能补上一些信息，但过两天又有新的变化。人越多，同时推进的事情越多，就越难靠彼此提醒，把所有细节都照顾到。
Agent 让我们有机会换一种做法，而且已经有了实际的起点。GitHub 的 Copilot 云端 Agent 可以研究仓库、修改代码、运行测试、创建合并请求；AWS DevOps Agent 可以结合运行数据和变更记录调查故障、提出处理建议。
这些工作接下来能不能连起来，很大程度上取决于：前面做过的事，后面能不能接着用。
在这样的工作流里，需求原文可以保留，代码版本可以查，执行过的命令、返回的结果、失败的测试，也都可以保存。任务走到哪一步，排除了哪些猜测，还有什么没确认，可以持续更新在同一份记录里。
接手的 Agent 不必只听一句“已经处理好了”。它可以查看实际改动，按需要补做验证，沿着记录找到原始日志。对某个结论有疑问，就回去查它是怎么得出来的。
一句话被人漏讲了，后面的人未必知道还有这回事。原始材料保存下来了，至少还有查证和纠正的机会。
当然，Agent 也会误读，摘要也可能省略细节。Anthropic 对上下文管理的讨论就提到了这些问题。所以，原文要留，记录要能查，重要条件要有检查，不能只指望模型记性好。
把这些事情做好之后，我更看好 Agent。我认为，等到大量任务同时推进时，人工传话出的岔子，会比这样的 Agent 工作流多得多。每换一个人就重新讲一遍背景，这个办法很难一直撑下去。
人当然也能查记录，好的团队一直在这么做。但只要每一步都得等下一个人腾出时间，看完材料，再决定怎么处理，速度就仍然受制于人。
Agent 干得越快，这个问题就越明显。
以前，一个团队能做多少事，大致受人数和工作时间限制。现在可以同时开更多任务了，但看代码的还是那几个人，测试环境还是那一套，发布还是等那几个窗口。
接口正在开会，请稍后重试。
于是，代码越写越多，排队的任务也越来越多。今天的改动拖到下周，相关代码可能已经被其他人改过了，又得解决冲突、确认影响、重新测试。等了一圈，活反而更多了。
这时再加一个协调人，天天问进度，能让大家更清楚地知道堵在哪里，却不一定能让事情更快往前走。
只给现有岗位各配一个 Agent，就很容易掉进这个局面：开发 Agent 写代码，测试 Agent 等提测，运维 Agent 等上线通知，经理继续在群里催进度。执行得更快了，等人的地方一个没少。
再往后，场面可能更好笑。开发把自己 Agent 的结果复制出来，发给测试；测试贴进自己的 Agent，把分析结果发回开发；开发再贴回自己的 Agent，补一句：“对方说有问题，你看看。”运维在旁边等着，准备把最后的结论贴进第三个 Agent。
几个 AI 都在等人复制粘贴，中间还得经历吃饭、开会和“抱歉，刚看到消息”。折腾一圈，人类成了 Agent 之间的低效接口：带宽低、延迟高，偶尔还丢包。接口正在开会，整个流程就只能挂起。老板问 AI 转型做得怎么样，大家说：“已经全员用上了。”
想避免这种事，就得从一项工作怎样才能做完，重新安排流程。
比如，目标是解决订单接口变慢。就应该从异常发生的时间查起，找到相关版本和调用链路，检查最近的改动，复现问题，再尝试修复。一路查出的证据、排除的原因，后面都应该接着用。
这次，终于不用复制粘贴了。
需要另一种专业能力，就调用相应的工具或 Agent；需要有人判断，就把问题和证据一起交给负责人。别一进新环节，就换一张工单，背景重新讲，材料重新找，查过的事情再查一遍。
哪些地方必须让人决定，要提前说清楚。能不能改生产配置，什么情况下允许回滚，涉及数据删除怎么办，都得有明确规定。这些检查和决定应该保留，也完全可以和日常的自动执行配合起来。
人的时间也要重新安排。要求不能只说个大概，结果也不能只看一份总结。
让 Agent “优化一下性能”，它能做的事很多，但未必符合你的要求。延迟要降到多少，能多花多少钱，哪些业务逻辑不能动，都得说清楚。
验收也一样。告警不响了，可能只是规则被关了；进程重新启动了，也不代表订单已经恢复正常。数据有没有漏，用户能不能完成付款，才是负责人该盯住的结果。
代码越来越容易写出来以后，把问题说清楚、把结果看明白，会变得更重要。很多原来靠口头提醒的经验，也要写进规则和检查里，免得每次换人都重新交代。
这些结果要靠线上数据来确认，可观测性也就变得更重要了。
Agent 改了代码，得看到上线后的错误率；调了资源，得知道性能和费用怎么变了；处理了故障，得确认用户真的能用了。日志、指标、链路、用户操作和变更记录，都要能查、能关联。
Agent 说自己做好了，还得拿实际运行的结果对一遍。出了问题能及时停，效果不好能恢复，事情才有可能放心交给它继续做。
账单先跑起来了，项目还在等确认。
企业可以先挑一类常见问题，把从发现、处理到确认结果的整件事跑通。运行一段时间，看看等待有没有减少、重复解释有没有变少、故障有没有更快解决，再决定扩大到哪些工作。这比统计买了多少 AI 账号、生成了多少代码，更能说明问题。
我不认为现有 DevOps 流程再修修补补，就能接住接下来的变化。既然越来越多开发运维工作可以交给 Agent，人就该把时间用在说清要求、处理关键决定、检查结果和承担责任上。一个任务如果还总是卡在“这事得等他回来讲一下”，流程就该改了。
组织不变，流程不改，光让人人用上 Agent，最后很容易变成一场昂贵的重复劳动。同一个背景，每个人都让自己的 Agent 重新读一遍；同一个问题，换个人又从头分析一遍。Token 一轮轮地烧，人照样等确认、等交接、等开会。到最后，Token 花了一大把，效率提升却微乎其微。
全员都在用 AI，项目还是老速度。
发表于 前天 06:30
|
查看: 1|
回复: 0
