章节主旨
拿到 agent 交付物后如何审查并把好的结果回写进 directive;为什么要把单个工作流「串联」成一条端到端链;以及一个判断何时需要人介入(human-in-the-loop)的决策框架。结尾引出下一步:事件驱动 / 定时驱动的工作流。
核心论点
- 执行完先审查交付物,满意就明确告诉模型「这样很好」并让它固化进 directive——正反馈让下次自动照做。(→ 详解1)
- 单个工作流有用,串联成一条链才是真正省事——消除中间「手动接力」,一句话触发整条流程。(→ 详解2)
- agent 卡住时,你既是决策者也是「激励者」——很多时候它只需被推一把或被打断死循环。(→ 详解3)
- 是否要人介入 = 结果量级 × 质量敏感度两个维度判断——两者都高必须留人把关。(→ 详解4)
- 质量-影响是线性关系就放手自动化,是「恐怖谷」非线性关系就留人——销售电话这类高敏感任务不自动化。(→ 详解5)
- 目标是「监督式自治」而非「保姆式盯梢」——像发 Slack 消息一样自然指挥 agent。(→ 详解6)
知识点详解
1. 审查交付物并回锚 directive 4:15:31
一次 agent 执行后你几乎总会拿到一个交付物(链接 / 文档 / 摘要)外加一份「执行过程报告」。做法是:审查输出、确认它满足需求,满足就直接告诉模型「这个效果很好」。
如果这个结果是你反复试错、迭代多轮才得到的,更要明确告知模型「这就是我要的」,并让它把这一点更新进 DOE 框架 里的 directive(指令层)——除非它已经自动更新了。
多数情况下这一步会自动发生,但主动说一句几乎零成本,却能让优质产出被沉淀成默认行为。这是一种把「一次调好」变成「以后都对」的廉价正反馈。
2. 串联工作流:umbrella 类比 4:16:00
单个工作流有用,但把它们**串联(chaining)**起来才产生真正的价值。作者用「umbrella(伞 / 总括)」类比:把已建好的多个独立工作流归到一把「伞」下(如「新客户 onboarding 伞」),下次一句话就能同时触发全部。
它解决的是「手动接力」痛点。没串联时,你得等 lead 抓取跑完拿到链接,手动喂给 enrichment(信息富集),跑完再手动喂给发信步骤——每一步都要人守着交接。作者坦言常同时开十个 agent 实例,却忘了推进某一步,白等一小时。
串联后整条链自动跑:分析客户 niche → 抓 lead → 富集邮箱 → 生成个性化首句 → 最后吐一张 Google Sheet,只在全部完成时回来看一眼。前提是每个单步都已被你单独验证过确实靠谱,否则串起来只是把瓶颈藏得更深。
3. agent 卡住时:决策者兼「激励者」 4:19:08
有时 agent 确实无法自动修复某事(较少见),它通常会直接问你,并给出足够上下文:它想做什么、哪里出错、有哪些选项。你的活儿就是看一眼后拍板:「就这么办」/「把 directive 改成这样」/「你真的都试过了吗?研究过所有方案了吗?」
有趣的观察是:agent 不只需要你做决策,有时还需要被激励。作者多次见到 agent 卡在某个 API spec 上十分钟,他只说一句「你能去查一下这个 API spec 吗?」,agent 就去查、然后一次就做对了。
另一种情况是 agent 陷入死循环:反复试同两个方案来回横跳。此时直接暂停、看它的 reasoning,然后说「你这二十分钟一直在重复这两件事,别再这么干了,先研究最佳方案再继续」。底层逻辑是迭代很便宜:发一条消息成本几分钱,而潜在收益很大,做点什么几乎总强过干等。
4. Human-in-the-loop 决策框架:量级 × 敏感度 4:20:23
判断某个环节该不该让人介入,看两个维度。一是结果量级(magnitude of outcome):这件事对生意影响是否极大。二是质量敏感度(sensitivity to quality):是否「很小的错误会造成不成比例的大问题」。两者都高,就绝对要留人把关。
作者用**恐怖谷(uncanny valley)**曲线解释冷启动邮件为何必须留人:横轴质量、纵轴「感知效果」,在到达某个「相变点」前,质量再涨感知几乎不动,过了临界点才突然暴涨。冷邮件的感知敏感度极高,AI 写完常卡在谷底爬不上去。
此时人只需快速审一遍、改两三个词,感知就从谷底跳到顶部。客观质量没变多少,但感知天翻地覆,而这只花几秒。发给上万人的冷邮件、发票、提案(financial documents)都属此类——「差一度」就毁掉一万封信或一份带多写个零的发票,省下的审阅时间远不抵翻车代价。
5. 线性放手 vs 非线性留人;哪些干脆不自动化 4:21:02
反过来,很多任务低敏感度——量比完美更重要,就让它全自动跑。典型是网页抓取,以及「生成多个草稿 / 变体供后续挑选」这种设计模式:本来就要它多产,不需要精细操控。凡是质量与影响近似**线性(1:1)**的任务,自动化到 70% 也远比不自动省时,放手即可。
但有些事根本不该自动化。作者明确反对用语音 agent 替你打销售电话 4:24:33:你既然愿意开电话,就说明极在意结果,这是高触达的销售对话;哪怕 0.1% 概率让对方觉得「在跟机器人说话」,对成交的杀伤也远超 0.1%——完全不是线性关系。他会自动化通话前的调研(生成客户 dossier、省下几小时 LinkedIn 翻查),但通话本身坚持自己来。
对「需要共情 / 判断」的情形,一个技巧是把它转成可自动 yes/no 的规则。例:Amazon 对退款率低(如 <2%)的用户走自动退款 4:25:51,无需照片或人工审核,省下海量时间;而退款记录可疑的用户才转给有共情判断力的人处理。原则是「只为真能改善底线的事去自动化」,不为自动化而自动化。
6. 监督式自治,而非保姆式盯梢 4:26:51
最终目标是监督式自治(supervised autonomy),不是保姆式盯梢(babysitting)。指挥方式就像发 Slack 消息:不用正式语法或精确术语,把「同事」换成「agent」直接 DM。例:「帮我用新文件跑一下 YouTube 剪辑器,把切点收紧一点」,它就自动缩短平均切点间距、重跑,你说满意后它就把该偏好固化进流程,下次照用。
但作者也点明:手动触发这些工作流只是起点。现在的模式是——打开 IDE、跟 agent 说话、亲手启动流程,这对临时性、一次性任务够用,也适合朝九晚五坐在桌前时。
问题是「automation」里的 auto 才是关键:如何让流程无人参与地自动跑?这引出下一章的事件驱动工作流 4:27:56(如新 lead 5:30 填表、你 5:00 已下班,需自动回复约会)与定时驱动工作流(如周一早九点自动生成周报),而实现手段就是 webhook。
术语
- chaining workflows(串联工作流,把多个独立流程归到一把「伞」下一键触发端到端链)
- umbrella analogy(伞类比,用「一把伞总括多个子工作流」比喻串联)
- human-in-the-loop(人在环中,在流程关键点保留人工审查 / 决策)
- magnitude of outcome(结果量级,某任务对生意影响的大小,判断是否留人的维度之一)
- sensitivity to quality(质量敏感度,小误差是否造成不成比例大问题)
- uncanny valley of quality(质量恐怖谷,质量-感知的非线性曲线,过相变点前涨质量几乎无感)
- supervised autonomy(监督式自治,让 agent 自主执行但你在高层监督,而非事事盯梢)
- event-driven workflow(事件驱动工作流,由外部事件如表单提交自动触发)
自检问题
- 作者用哪两个维度判断某环节是否需要 human-in-the-loop? 答案:结果量级(magnitude of outcome,对生意影响大不大)与质量敏感度(sensitivity to quality,小错是否引发不成比例的大问题);两者都高时必须留人。4:20:23
- 为什么冷启动邮件即便 AI 写得不错也要人审一遍? 答案:感知效果对质量呈「恐怖谷」非线性关系,AI 常卡在相变点之下;人改两三个词就能把感知从谷底推到顶部,客观质量没大变但感知天差地别,且只花几秒。4:21:02
- 串联工作流(chaining)主要解决什么痛点?前提是什么? 答案:消除步骤间的「手动接力」——不再需要人把上一步产出手动喂给下一步;前提是每个单步都已被单独验证靠谱,否则只是把瓶颈藏深。4:16:00
- 面对「需要共情 / 判断」的客户场景,作者给的自动化技巧是什么?举例。 答案:把它转成可自动判定的 yes/no 规则,例如 Amazon 对低退款率用户自动放行退款、无需人工;只有记录可疑的才转人工。4:25:51