
> **企业 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）。把它落到实践，大致是这样一条光谱：
![Graduated Autonomy：按风险给动作配自主级别.png](https://developer.qcloudimg.com/http-save/yehe-7660620/1b0b5dccdeb9461acf98b30581250ee7.png)

关键的设计原则是：**一个动作的自主级别，由它的风险和可逆性决定**——这正好接上了第三篇"失败点"的概念。不可逆、高代价的动作（比如对外发出报价、签署合同）放在低自主级别，必须人 gate；只读、可逆的动作（比如检索、汇总、起草草稿）放在高自主级别，让 Agent 放手去做。

业界的成熟实践里，还有几个好用的模式：对高风险步骤（典型如认证、支付）做**显式 gate**；对需要盯着的关键流程开**watch mode**，让人实时旁观、随时叫停；而对海量的低风险常规操作，则给足自主权、只做事后审计。

拿采购 Agent 举例就很清楚：检索供应商、比价、起草采购建议——这些只读、可逆，给 L4/L5 高自主；而下单付款、签署合同、对外发出报价——这些动钱、不可逆，压到 L1/L2，必须人确认，或设金额阈值，超过就强制升级。**同一个 Agent，能力可以很强，但访问范围按动作风险分级收放**——这正是 Gartner 说的，把"行动能力"和"访问范围"分开治理。

那具体怎么给一个动作定级？给一个可操作的双轴判据：**看它的"代价"和"可逆性"。**代价低又可逆的（读一份文件、查一次库、写一版草稿），放心给最高自主；代价高但仍可逆的（生成一份会被人复核的报告），可以高自主 + 事后审计；而代价高且不可逆的（钱付出去了收不回、合同签了生效了、报价发出去了改不了），无论模型多自信，都必须压到最低自主、卡死人工 gate。**记住一条:可逆性比能力更重要。**一个能力一般但完全可逆的动作，远比一个能力很强但不可逆的动作更适合放手——因为前者错了能改，后者错了就是事故。给动作定级时，先问"它错了能不能撤回",答案往往就决定了自主级别。

---

## 四、接力的触发：什么时候把"接力棒"交给人

有了分级，下一个问题是：**具体在什么时刻，Agent 该停下来、把接力棒交给人？**这就是升级（escalation）的触发机制。

这里有一个至关重要的设计哲学，来自一线工程实践：**human-in-the-loop（人在环）应该是一个"一等公民"的工具调用，要被主动地、前置地设计进系统，而不是当成出事之后的兜底补丁。**换句话说，"什么时候找人"本身，就是 Agent 流程里一个被精心设计的环节。

触发交接的，主要是三类条件：
![何时把接力棒交给人：升级触发.png](https://developer.qcloudimg.com/http-save/yehe-7660620/74b6f4aaf6c6637f5d292faa9efd6e17.png)

- **置信阈值（confidence）**：当模型对自己的判断不确定（置信度低于设定阈值）时，主动求助，而不是硬着头皮蒙一个。
- **交易风险（risk）**：当动作涉及的金额、影响超过阈值时，无论模型多自信，都强制升级。
- **策略约束（policy）**：当合规或政策明确要求人工介入时（比如某类合同必须法务复核），自动转人。

落到招投标：当报价金额超过某个数额，或者"硬性资质是否满足"这个失败点上模型给出的置信度不够高时，系统自动把这一步升级给人确认——而不是让一个不确定的判断，直接流进最终报告。**主动设计这些触发点，是 relay 安全性的核心。**

但触发器的阈值，是一门需要持续调的手艺，因为它卡在两种相反的失败之间。一边是**漏升级**：阈值定得太松，该找人的时候 Agent 自作主张，高风险动作无人把关——这是会出事故的方向。另一边是**过度升级**：阈值定得太紧，鸡毛蒜皮的事都来烦人，把监管者淹没在升级噪音里——这会让系统退化成一个"更慢的人肉审批流",自动化的价值荡然无存。这两端都是 relay 的失败。所以阈值不是拍一次就定死的，要随着对 Agent 可靠性的了解不断调：哪些情况它其实判得很准、可以放手（调松），哪些情况它经常翻车、必须卡人（收紧）。**好的 relay，是让人只在"真正需要人"的地方出现——不多不少，刚刚好。**这个"刚刚好",正是后面运营指标要持续优化的目标。

---

## 五、交接协议：接力棒怎么传才不掉

触发了升级，接力棒就要从 Agent 传到人手里。而接力赛最容易输的地方，恰恰是交接区——**棒一掉，前面跑得再快也白费。**

人机接力最常见的"掉棒",是交接时的上下文丢失：Agent 把任务甩给人，人接过来却一脸懵——它做到哪一步了？为什么要找我？它自己的建议是什么？我到底要决定什么？如果这些都不清楚，人要么花大量时间重新理解，要么干脆拍脑袋决定，接力的价值荡然无存。

所以一个好的**交接协议（handoff protocol）**，必须把这些打包清楚：

- **完整的上下文**：Agent 走到了哪一步、基于什么信息、做了哪些判断。
- **升级的原因**：为什么在这里停下来找人（是置信低、风险高、还是策略要求）。
- **Agent 的建议**：它倾向于怎么做、理由是什么——人是来"确认或否决一个有依据的建议"的，而不是从零开始。
- **明确的待决问题**：人到底要回答什么、决定什么。

把好坏交接摆在一起对照，差距一目了然。**坏的交接**长这样：Agent 在 Slack 里甩一句"招投标任务需要人工确认",没了。接手的人懵在原地——哪个标？卡在哪一步？要我确认什么？他只能翻半天日志、自己重新把任务理一遍，接力的效率还不如自己从头做。**好的交接**则是：Agent 给出一条结构清晰的消息——"XX 项目招投标分析：硬性资质已核对通过，报价测算完成，建议报价 860 万（依据：三个同类历史项目利润率 + 当前两家竞品报价区间）；但该项目报价超过 800 万的内部审批红线，需你确认是否按此报价提交。"——人扫一眼，几秒钟就能做出有依据的决定。**前者让人重新干一遍 Agent 的活，后者让人只做那个唯一只有人能做的决定。**交接协议的全部价值，就在这一字之差里。
![人机接力：接力棒的双向传递.png](https://developer.qcloudimg.com/http-save/yehe-7660620/674a7cb118dfc2ec893eb7678dc1a738.png)

还有一个让接力顺滑的关键工程实践：**把 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 把能做的都做了，白天人只做那些只有人能做的——这就是连续交付真正跑起来的样子。**而真正紧急、不能等的高风险升级，则走即时通道，半夜也会把对的人叫醒。
![7×24 连续交付：少数人监管一群 Agent.png](https://developer.qcloudimg.com/http-save/yehe-7660620/7282ead6ca686a175a680205cb052806.png)

要支撑这样的连续运转，离不开一套运营基础设施——**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 系统架构蓝图。*


企业 AI 化的四层工程体系 · 第 ⑧ 篇 人机接力与连续交付：从"造系统"到"跑业务"

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

造好一个 Agent 只是开始，不是结束。让它 7×24 连续干活、又不在高风险动作上闯祸，靠的是"人机接力"。本文讲透：如何用分级自主与接力交接，让少数人安全地监管一群连续运转的 Agent。

资深架构师

人工智能

后端

职业发展

企业AI系统上线后，如何实现7×24小时连续运转？本文提出人机接力机制，通过分级自主、升级触发和交接协议三大核心设计，让AI处理常规任务，人工仅介入高风险决策。重点解析如何平衡自动化与人工监管，确保系统安全稳定运行的同时最大化效率。

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 造好了，然后呢？让它 7×24 连续干活的，是"人机接力"-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐