Agent 造好了，然后呢？让它 7×24 连续干活的，是"人机接力"

> **企业 AI 化的四层工程体系 · 第 ⑧ 篇** > 人机接力与连续交付：从"造系统"到"跑业务" --- ## 引言：上线，往往不是终点，而是麻烦的起点 到上一篇为止，我们已经做了两件大事：用四层 runtime（Prompt、Context、Harness、Loop）造好了一台 Agent 机器，又用评估这根柱子给它装上了度量好坏的尺子。系统，既能跑、又能被信任了。 很多企业走到这里，长舒一口气，以为大功告成。 然后，真正的麻烦才开始。系统一旦离开工程师的贴身盯守，问题就接踵而至：它在某个高风险动作上自作主张闯了祸；它在深夜无人值守时卡死，等人上班才发现已经堵了八个小时；它该求助的时候没求助，不该自己拍板的时候拍了板。 这暴露了一个被严重低估的真相：**"造好一个系统"和"让它在真实业务里连续、可控地跑起来",是两件完全不同的事。**正如业界一句越来越被认同的话——**部署一个 Agent，是它生命周期的开始，而不是结束。** 从"造系统"到"跑业务"之间，还隔着一层运营外壳——它就是我们那张同心圆最外面的一圈：**Human-Agent Relay（人机接力）**。这一篇，我们就来讲，怎么让人和 Agent 接力配合，把一个"造好的系统",变成一个能 7×24 连续交付的"业务"。 --- ## 一、最后一跳：从"造系统"到"跑业务" 前七篇，我们一直在"造"。四层 runtime 是造引擎和车身，评估柱是造仪表盘。但一台造好的车停在车库里，不会自己创造价值——它得有人开、有运营、有调度，才能真正跑起来拉货。 很多企业的幻觉，就是把"造好"当成了"跑通"。他们以为系统上线那一刻，项目就成了。但上线恰恰是运营的起点：在生产里，Agent 会遇到从没见过的输入、不断变化的数据、深夜的流量、以及那些"能做但不该擅自做"的高风险动作。 **真正的规模化，不是造一个更强的 Agent，而是让 Agent 能在真实业务里 7×24 连续、可控地运转。**而这件事，单靠 Agent 自己做不到——它需要人。但需要人，不等于需要有人一直盯着。这中间的平衡艺术，就是人机接力。 把它放回那张同心圆：人机接力是最外面那一圈运营外壳，它包裹着内部所有的 runtime 和评估，让整台机器能够真正、持续地为业务服务。 > **本篇的核心命题：系统造好之后，靠人机接力让 loop 在生产中连续运转，才是真正的"规模化"。** --- ## 二、为什么不能"全自动"：能力 ≠ 该放手 一个诱人的想法会立刻冒出来：既然 Agent 已经这么强了，为什么不让它全自动跑，把人彻底解放出来？ 这个想法很美好，也很危险。 来看一个让人警醒的预测：Gartner 判断，**到 2027 年，会有 40% 的企业把已上线的自主 Agent 降级或下线**——而且这些问题，往往是在生产事故发生之后才被发现的。根本原因是什么？Gartner 指出，很多企业把 Agent 治理当成了一道**二元开关**——要么彻底锁死，要么完全放任，却从不区分两件本质不同的事：**Agent 的"行动能力"（它能做多复杂的判断）**，和 **Agent 被授予的"访问范围"（它能碰多大权限的资源）**。 把这两者混为一谈，灾难就来了：要么因为怕风险而什么都不敢让它做（白白浪费了它的能力），要么因为图省事而把过大的权限交给一个还不够可靠的系统（埋下事故的雷）。 所以第一条铁律是：**"能做"不等于"该完全放手"。**一个 Agent 哪怕能力再强，对那些动钱、签约、对外发布、修改权限的高风险、不可逆动作，也不该在无人值守的情况下擅自拍板。 但反过来，也不能因噎废食——如果每一步都要人盯着、人确认，那自动化就失去了意义，你只是雇了一个更慢的"人肉审批流"。 出路既不是"全自动",也不是"全人工",而是第三条路：**分级、接力。**让 Agent 在它该自主的地方充分自主，在它该交棒的地方果断交棒。这，正是我们在第二篇"治理闸门"里埋下的伏笔，现在要把它展开成一套完整的运营机制。 --- ## 三、Relay 的骨架：graduated autonomy（分级自主） 人机接力的第一块骨架，是**分级自主（graduated autonomy）**：不给整个 Agent 一个笼统的"自主/不自主"标签，而是给它的**每一类动作**，配一个与风险相称的自主级别。 业界已经总结出了清晰的自主度分级（常被描述为 L1 到 L5）。把它落到实践，大致是这样一条光谱：  关键的设计原则是：**一个动作的自主级别，由它的风险和可逆性决定**——这正好接上了第三篇"失败点"的概念。不可逆、高代价的动作（比如对外发出报价、签署合同）放在低自主级别，必须人 gate；只读、可逆的动作（比如检索、汇总、起草草稿）放在高自主级别，让 Agent 放手去做。 业界的成熟实践里，还有几个好用的模式：对高风险步骤（典型如认证、支付）做**显式 gate**；对需要盯着的关键流程开**watch mode**，让人实时旁观、随时叫停；而对海量的低风险常规操作，则给足自主权、只做事后审计。 拿采购 Agent 举例就很清楚：检索供应商、比价、起草采购建议——这些只读、可逆，给 L4/L5 高自主；而下单付款、签署合同、对外发出报价——这些动钱、不可逆，压到 L1/L2，必须人确认，或设金额阈值，超过就强制升级。**同一个 Agent，能力可以很强，但访问范围按动作风险分级收放**——这正是 Gartner 说的，把"行动能力"和"访问范围"分开治理。 那具体怎么给一个动作定级？给一个可操作的双轴判据：**看它的"代价"和"可逆性"。**代价低又可逆的（读一份文件、查一次库、写一版草稿），放心给最高自主；代价高但仍可逆的（生成一份会被人复核的报告），可以高自主 + 事后审计；而代价高且不可逆的（钱付出去了收不回、合同签了生效了、报价发出去了改不了），无论模型多自信，都必须压到最低自主、卡死人工 gate。**记住一条:可逆性比能力更重要。**一个能力一般但完全可逆的动作，远比一个能力很强但不可逆的动作更适合放手——因为前者错了能改，后者错了就是事故。给动作定级时，先问"它错了能不能撤回",答案往往就决定了自主级别。 --- ## 四、接力的触发：什么时候把"接力棒"交给人 有了分级，下一个问题是：**具体在什么时刻，Agent 该停下来、把接力棒交给人？**这就是升级（escalation）的触发机制。 这里有一个至关重要的设计哲学，来自一线工程实践：**human-in-the-loop（人在环）应该是一个"一等公民"的工具调用，要被主动地、前置地设计进系统，而不是当成出事之后的兜底补丁。**换句话说，"什么时候找人"本身，就是 Agent 流程里一个被精心设计的环节。 触发交接的，主要是三类条件：  - **置信阈值（confidence）**：当模型对自己的判断不确定（置信度低于设定阈值）时，主动求助，而不是硬着头皮蒙一个。 - **交易风险（risk）**：当动作涉及的金额、影响超过阈值时，无论模型多自信，都强制升级。 - **策略约束（policy）**：当合规或政策明确要求人工介入时（比如某类合同必须法务复核），自动转人。 落到招投标：当报价金额超过某个数额，或者"硬性资质是否满足"这个失败点上模型给出的置信度不够高时，系统自动把这一步升级给人确认——而不是让一个不确定的判断，直接流进最终报告。**主动设计这些触发点，是 relay 安全性的核心。** 但触发器的阈值，是一门需要持续调的手艺，因为它卡在两种相反的失败之间。一边是**漏升级**：阈值定得太松，该找人的时候 Agent 自作主张，高风险动作无人把关——这是会出事故的方向。另一边是**过度升级**：阈值定得太紧，鸡毛蒜皮的事都来烦人，把监管者淹没在升级噪音里——这会让系统退化成一个"更慢的人肉审批流",自动化的价值荡然无存。这两端都是 relay 的失败。所以阈值不是拍一次就定死的，要随着对 Agent 可靠性的了解不断调：哪些情况它其实判得很准、可以放手（调松），哪些情况它经常翻车、必须卡人（收紧）。**好的 relay，是让人只在"真正需要人"的地方出现——不多不少，刚刚好。**这个"刚刚好",正是后面运营指标要持续优化的目标。 --- ## 五、交接协议：接力棒怎么传才不掉 触发了升级，接力棒就要从 Agent 传到人手里。而接力赛最容易输的地方，恰恰是交接区——**棒一掉，前面跑得再快也白费。** 人机接力最常见的"掉棒",是交接时的上下文丢失：Agent 把任务甩给人，人接过来却一脸懵——它做到哪一步了？为什么要找我？它自己的建议是什么？我到底要决定什么？如果这些都不清楚，人要么花大量时间重新理解，要么干脆拍脑袋决定，接力的价值荡然无存。 所以一个好的**交接协议（handoff protocol）**，必须把这些打包清楚： - **完整的上下文**：Agent 走到了哪一步、基于什么信息、做了哪些判断。 - **升级的原因**：为什么在这里停下来找人（是置信低、风险高、还是策略要求）。 - **Agent 的建议**：它倾向于怎么做、理由是什么——人是来"确认或否决一个有依据的建议"的，而不是从零开始。 - **明确的待决问题**：人到底要回答什么、决定什么。 把好坏交接摆在一起对照，差距一目了然。**坏的交接**长这样：Agent 在 Slack 里甩一句"招投标任务需要人工确认",没了。接手的人懵在原地——哪个标？卡在哪一步？要我确认什么？他只能翻半天日志、自己重新把任务理一遍，接力的效率还不如自己从头做。**好的交接**则是：Agent 给出一条结构清晰的消息——"XX 项目招投标分析：硬性资质已核对通过，报价测算完成，建议报价 860 万（依据：三个同类历史项目利润率 + 当前两家竞品报价区间）；但该项目报价超过 800 万的内部审批红线，需你确认是否按此报价提交。"——人扫一眼，几秒钟就能做出有依据的决定。**前者让人重新干一遍 Agent 的活，后者让人只做那个唯一只有人能做的决定。**交接协议的全部价值，就在这一字之差里。  还有一个让接力顺滑的关键工程实践：**把 Agent 做成一个 headless service（无界面服务），可以被 cron、webhook、Slack 消息等任意方式触发，并在同一个线程里回复。**这意味着，人不需要专门打开一个 Agent 后台去"接力",而是在自己本来就在用的工作流里（比如 Slack 频道）就能完成交接——Agent 在频道里 @ 你、给出建议，你回一句确认，它就接着跑下去。**这一下，Agent 就从一个"你要专门去伺候的工具",变成了一个"在你身边协作的团队成员"。** 最后强调一点：接力是**双向**的。不只是 Agent→人（升级求助），也有人→Agent（人做完决策，把棒交还，Agent 接着自动跑完后续）。接力棒在人和 Agent 之间顺畅地来回传递——这才是"relay"这个词真正的精髓。 --- ## 六、7×24 连续交付：让系统不眠不休地跑 有了分级自主、升级触发、交接协议这三块骨架，我们才终于能谈那个最诱人的目标——**7×24 连续交付。** 它的运转逻辑是这样的：Agent 在海量的低风险常规任务上自主奔跑，包括深夜、周末、所有没人盯着的时段；遇到需要人的高风险或低置信节点，紧急的即时升级，不紧急的则攒进升级队列，等人上班时批量接力。**于是系统实现了一种受控的连续运转：AI 处理绝大多数常规情况，人只治理边缘和高风险决策。** 这背后是一次深刻的杠杆变化。过去是"一个人做一份工作",现在是"一个人监管一群 7×24 运转的 Agent"。**规模化的真正含义，不是让一个 Agent 更强，而是让少数人能监管一大群 Agent。** 把这套"昼夜接力"再讲具体些。深夜，没有人值守，但 Agent 群并不停工：它们继续处理白天积压的常规招投标初筛、采购比价、工单分类，把每一个触及高风险或低置信的节点，整整齐齐地放进升级队列、附上完整的交接包。第二天早上，监管者打开 Slack，看到的不是一堆需要从头理解的烂摊子，而是一排排"已分析完、就差你拍板"的待决项，批量扫一遍、逐个确认，半小时清空队列，Agent 接过决策又自动跑完后续。**夜里 Agent 把能做的都做了，白天人只做那些只有人能做的——这就是连续交付真正跑起来的样子。**而真正紧急、不能等的高风险升级，则走即时通道，半夜也会把对的人叫醒。  要支撑这样的连续运转，离不开一套运营基础设施——**AgentOps 控制平面**。它提供实时监控、会话回放（session replay）、乃至"时间旅行式"的逐步调试、按 token 的成本追踪、以及 SLO 保障。它让一群在后台连续奔跑的 Agent，变得可监控、可审计、可干预。 还有一件运营上必须做的事：**持续监控漂移（drift）。**Agent 上线后会遇到不断变化的真实世界，性能会悄悄退化。所以要把生产里跑出来的新失败案例，源源不断地回流进评估集（这正好接上了第七篇说的 Eval-Ops 闭环），让系统在连续运转中持续被校准。**部署只是开始，而不是结束——这句话，在运营层是字面意义上的真理。** --- ## 七、连续交付的运营指标：怎么衡量这套 relay 跑得好不好 运营这层，同样不能凭感觉——它也要被度量（这正是第七篇那根评估柱在运营层的延伸）。一套成熟的人机接力，要盯住几个关键的运营指标： - **自主完成率**：有多大比例的任务，Agent 全程自主完成、无需人介入？这是衡量"杠杆"的核心指标。 - **升级准确率**：该升级的有没有升（漏升级 = 高风险动作无人把关）？不该升级的有没有乱升（过度升级 = 把人淹没在噪音里、退化成人肉审批）？这两个方向都要看。 - **平均交接时延**：从 Agent 升级到人响应，平均要多久？它直接决定了连续交付的"流畅度"。 - **人均可监管 Agent 数**：一个监管者能稳稳盯住多少个 Agent？这是规模化杠杆的直接体现。 - **高风险动作零事故率**：那些被 gate 的高风险动作，有没有出过没拦住的事故？这是安全的底线。 这套指标，共同刻画了一套 relay 的"性价比"和"安全性"。而运营优化的方向也由此清晰：**在守住安全底线（高风险零事故）的前提下，逐步提高自主完成率、优化升级准确率——让人的杠杆越来越大，让系统在越来越少的人力监管下，跑得越来越多、越来越稳。** 这，才是企业 AI 化"规模化"这三个字真正落地的样子。 --- ## 结论：别再只盯着"造一个更强的 Agent" 这篇文章想留给你的，是一次视角的根本转变： > **企业 AI 化的终点，不是造一个更强的 Agent，而是建立一套让人和 Agent 顺畅接力、使系统能 7×24 连续、可控运转的运营机制。** 把本篇的核心判断收成几句话： > **能做 ≠ 该完全放手；出路是分级自主 + 接力。给每类动作配与风险相称的自主级别，用置信、风险、策略三类触发器决定何时交棒，用严谨的交接协议保证接力棒不掉，再用一套运营指标持续衡量与优化——最终，让少数人监管一群 7×24 连续运转的 Agent。** 如果你是技术决策者，从这篇出发，有四件事可以立刻推动：给系统里的每一类动作，定义它的自主级别；为它设置置信、风险、策略三类升级触发器；建立一套打包了上下文、原因、建议和待决问题的交接协议；并定义自主完成率、升级准确率等运营指标，把 relay 的运转纳入持续度量。 至此，我们已经走完了整套体系：四层 runtime 造出了系统，评估柱让它可被度量，人机接力让它能连续运转。所有的零件，都已就位。 那么最后一个问题是：**当这一切——Prompt、Context、Harness、Loop、Evaluation、Relay——全部拼在一起，一张完整的企业 AI 系统蓝图，到底长什么样？各层之间如何咬合？一个企业从零开始，又该按什么顺序把它搭起来？** 把散落在八篇里的所有部件，缝合成一张可以照着落地的完整架构图，并给出一份自检清单——这，正是本系列**第⑨篇（收官）《企业 AI 系统整体架构蓝图》**要交付的内容。 我们下一篇见。 --- *本文为「企业 AI 化的四层工程体系」系列第 ⑧ 篇。我们走到了整个体系的最外层——让系统连续运转的运营外壳。下一篇是收官之作：我们将把八篇里的所有部件，缝合成一张完整的企业 AI 系统架构蓝图。*