AI 越来越能干，人为什么越来越忙？

文中的配图与演示都只是概念示意，不是任何产品实录。

AI 越来越能干了。它能写代码、查资料、读日志、整理表格，也能同时开好几个会话。可很多人真正用了一阵子以后，感受并不是轻松下来，反而像多了一份新工作：盯着会话，搬运上下文，补一句“继续”，再去确认上一个结果有没有跑偏。

十个会话还好，五十个以后就开始不对劲。每个会话都在做一点事，却没有谁知道别的会话刚刚做了什么。你在它们之间复制、粘贴、追问、确认，像一个没有接口的中间件。模型没有慢下来，人先成了最窄的带宽。

我不觉得问题只是 AI 还不够聪明。更准确地说，现在多数 AI 还得等人把下一句话递过去。它会回答、会执行，也会在任务结束时交回来一段结果；可下一件事该不该开始、旧计划要不要修改、这条新消息和哪条老任务有关，仍然要靠人来拼。

工作不是一问一答

现实里的工作不是聊天记录。邮件进来、用户在工单里吐槽、群里有人 @ 你、下游任务刚结束、监控出了异常、约定的复查时间又到了。这些信号不会排队，也不等你把上一段对话聊完。它们来自不同系统，带着不同的紧急程度，有时还会互相改变含义。

现在最常见的协作方式，仍然是“我说一句，它做一句”。这当然适合探索，也适合把一个问题讲清楚。可当工作本身持续发生时，手动发起就会变成瓶颈：每一次新消息到来，都要有人判断它是不是一件新事、该交给谁、会不会影响正在进行的事。

Claude Code 的 Routines 可以按时间运行、由 API 唤起，或者跟着 GitHub 事件启动；OpenAI 的 Scheduled 也把定时和部分应用事件作为任务入口。[1] [2] 这些功能说明，工作可以由更多种信号启动，不必全等人敲下回车。

人为什么会被卡在中间

如果每个 Agent 都只收一条提示词、返回一条结果，那么人自然要当它们之间的消息总线。一个调研 Agent 交回了结论，代码 Agent 不会自动知道；用户的新反馈来了，原来的文案任务也不会自己判断该不该停。于是你在各种窗口里做的，常常不是判断本身，而是转发判断需要的材料。

这也是为什么“多开几个 Agent”经常没有带来成比例的轻松。执行者变多以后，协调成本也跟着长出来。它不像一个新功能，有时候甚至不容易被看见：少了一句话，前后两个会话就接不上；一个结果晚到十分钟，后面的安排已经过期；某个任务失败了，没人知道该重试、降级，还是先找人。

要自动化的，除了某一步执行，也包括这类琐碎但持续的协调。

从循环到一张会变化的图

这两个月，Loop Engineering 这个说法开始出现。名字最后未必会留下，但它说对了一件事：不要每次都手动提醒 AI 做下一步，可以给它一个会自己醒来的循环。定时巡检、事件触发、任务结束后的接力，都是让工作自己往前拱的办法。

再往前一点，可以把工作看成一张图。谁负责检索，谁负责执行，谁检查结果，哪一步必须停下来等人，都该有自己的位置。OpenAI 的 Agent Builder 把工作流拆成节点和带类型的连接；LangGraph 也强调把确定步骤和 Agent 决策放进同一张可追踪的图里。[3] [4]

但画完一张图，并不意味着事情从此按图走。明天会来一封新邮件，一条需求会推翻旧假设，一个会话会卡住，某个结果会让后面的工作失去意义。静态流程图只能描述一种情况；真实工作需要保留状态、能在中断后继续，还要允许外面的事件把它改掉。围绕长任务和人工等待的工作流系统，已经把恢复、重试与等待审批当成基础能力，而不是异常处理。[5] [6]

我把它想成一张活的图。它有当前状态，也会接收新信号。某个节点失败时，系统得知道该重试、换人、绕开，还是把问题带着上下文交给人。新需求出现时，先看它会不会影响已经承诺的事，再决定要不要开新会话。

需要一个不负责干活的“大管家”

我设想的是一个专门协调的大管家。编程平台继续管代码和会话，调研、文案、数据处理也各有自己的执行者。大管家不代替它们写代码或查资料，它接住信号、维护任务图、判断哪些工作彼此相关，再把合适的上下文交给合适的执行者。

AWS 把这一类角色称为 workflow orchestration agent：它可以接收用户输入或系统事件、检索上下文、选择执行者、跟踪状态并把中间结果交给下一步。[7] 这个定义比“大管家”规整得多，但我喜欢后者，因为它提醒了一件事：它最重要的工作往往没有明显产出。它在收拾桌面、安排顺序、把不该打断人的噪音先放到一边。

这层协调要做的事并不神秘。它先判断这是不是新事，还是某件旧事的新信息；然后决定交给谁，是否需要暂停既有任务，结果回来后又该怎样改变后续安排。一个会话缺少资料，可以让另一个会话补；一项调研推翻了假设，可以让下游文案先停住；一条紧急反馈插进来，也不用靠人把半天前的聊天记录重新复制一遍。

当然，协调者没有资格替人扩大授权。涉及目标冲突、预算、对外发送、删除数据或影响别人的决定，它应该停下来，带着背景、选项和影响来问。持久工作流里的审批模式也是这样设计的：流程等待一个带有批准、拒绝或升级信息的外部信号，再决定从哪条路径继续。[6]

那人做什么

人当然还在流程里，只是不必一直当传话人。比较值钱的部分是定目标、看取舍、处理例外、为影响他人的决定负责。普通进展可以进摘要；需要改变方向的事，才值得打断人。

协调层应该让人更容易看见：现在有什么任务，谁在做，哪些卡住了，下一步要哪种决定。它把人从会话之间的搬运里拿出来，也不该给人制造一个更黑的黑箱。

过去用软件，往往是打开一个应用、下一个命令、等一段回答。接下来更像把一件事托付出去：信息自己进来，执行者自己接力，流程在需要时停下来问人。AI 负责执行，协调层负责让执行别互相打架，人负责方向。

这还是一个需要验证的设想。难的从来不是画出一张漂亮的图，而是让它在真实的权限、失败、变更和等待里仍然能工作。但如果 AI 已经能同时做很多事，我们确实该少花一点时间替它们搬消息了。

参考资料

1. Anthropic，Automate work with routines，Claude Code Routines 的定时、API 与 GitHub 事件触发方式。
2. OpenAI Developers，Scheduled tasks，后台定时任务及部分应用事件触发的说明。
3. OpenAI Developers，Agent Builder，多步骤工作流、节点、类型化连接与调试方式。该产品处于迁移期，文中仅引用其对工作流图的说明。
4. LangChain，Why LangGraph，长运行、有状态 Agent 图，持久化与人工介入。
5. Temporal，Durable AI，长运行 Agent、状态恢复、任务队列和人工介入模式。
6. Temporal，Approval Pattern，等待外部批准、拒绝或升级信号的工作流设计。
7. AWS Prescriptive Guidance，Workflow orchestration agents，事件驱动、状态跟踪、动态选择和编排执行者的工作流模式。