信任通过重复建立，而不是演示

没有人能在一夜之间从手动编码转向完全自治的智能体。信任不是那样建立的。

在上一篇文章中，我写了关于组合工作流如何产生复合效应的内容。但在拥有可靠的独立工作流之前，你无法组合工作流。而在通过重复建立信任之前，你无法拥有可靠的工作流。

成功部署“持续 AI”(Continuous AI) 工作流的团队都遵循相似的路径。他们从小处着手，通过重复建立信心，并随着对有效方案的了解逐渐增加自动化程度。

实际情况如下所示。

第一阶段：受监督的智能体 (Supervised Agents)

你首先在本地运行一个智能体，以便观察它的工作过程。TUI 模式下的 Continue CLI 正为此而生。你给它一个任务，然后观察它的每一个步骤。

“修复这个 Sentry 错误”变成了一种学习体验。你可以看到它提取了哪些上下文，看到它是如何通过推理解决问题的，看到它在哪里卡住了。你可以在需要时进行干预。

起初这感觉很慢。你很想自己动手修复。但你不是在为一个任务做优化。你是在学习智能体成功所需的东西：更好的提示词、更清晰的规则、以及通过 MCP 服务器连接的正确工具。

几次运行后，模式就出现了。智能体能很好地处理某些类型的错误，但在处理其他问题时会遇到困难。你开始看到边界在哪里。

第二阶段：并行自动化 (Parallel Automation)

一旦你信任一个智能体能连续运行五分钟而无需持续监督，情况就发生了变化。你意识到你不需要盯着它工作了。

于是，你使用 Continue CLI 启动第二个智能体，并行处理其他任务。接着是第三个、第四个。

你不再是在编码了。你是在进行编排。三个智能体在更新文档，两个智能体在修复测试失败，一个智能体在调查性能回归。

这就是速度发生质变的地方。你不再受限于打字速度。你受限于定义任务和审查结果的能力。

第三阶段：事件驱动工作流 (Event-Driven Workflows)

当你习惯并行运行多个智能体后，下一个感悟随之而来：你不需要手动启动这些智能体。

出现新的 Sentry 错误？自动触发智能体。GitHub issue 被标记为“bug”？智能体启动。PostHog 功能标志达到 80% 的发布率？智能体更新文档。

这就是它成为“持续 AI”的时刻。工作流在你无需干预的情况下运行。你定义触发器，智能体执行工作，你审查结果。

我们看到团队正在为以下情况设置触发器：

• 超过阈值的 Sentry 错误（一小时内超过 100 次）
• 带有特定标签的 GitHub issues（“good first issue”、“bug”、“tech-debt”）
• 主分支上失败的 CI 构建
• 测试检测到的过期文档
• 提及特定关键词的客户支持工单
• 显示功能采用模式的 PostHog 洞察

从每天触发 2-5 次的触发器开始。这足以建立信心，又不会让你淹没在审查工作中。

第四阶段：组合工作流 (Composed Workflows)

有趣的部分来了。你意识到一个工作流的输出可以触发下一个工作流。

Slack 中的客户反馈 → 文档搜索 → 起草回复 → 人工审查 → 发布答案。

Sentry 错误 → 调查 → GitHub issue → PR → 审查 → 合并 → 更新日志 → Slack 摘要。

PostHog 功能达到 80% 发布率 → 更新文档 → 更新营销文案 → 起草发布说明 → 发布至更新日志。

你正在管理一个相互衔接的工作流系统。工作流处理重复性工作，你处理需要判断的决策。

信任是如何真正建立的

我们在 Continue 观察到的模式是：信任通过低风险任务的重复而建立。

你不会从让智能体重构身份验证系统开始。你会从让它在代码变更后更新文档开始。或者修复 linting 错误，或者更新测试固件。

这些任务的最坏结果是“我得自己修一下”，而不是“我刚刚发布了一个安全漏洞”。

随着智能体在这些小任务上取得成功，你可以给它更复杂的任务。修复这个测试失败，实现这个小功能，更新这些 API 客户端。

几周后，你可以让智能体处理一小时的任务。几个月后，是半天的任务。审查变得更快了，因为你已经学会了重点看什么。

衡量成功：干预率

“持续 AI”工作流的关键指标是干预率：人类需要介入的频率是多少？

我之前写过关于干预率如何成为新的构建时间的文章。就像团队在 CI/CD 时代痴迷于构建时间一样，你需要跟踪你何时以及为何中断自治工作流。

不同的阶段有不同的干预率曲线：

• 50% 以上的干预率：仍处于第一阶段，需要更多监督
• 20-50% 的干预率：第二阶段，适合并行工作，但尚未实现事件驱动
• 5-20% 的干预率：第三阶段，准备好设置事件驱动触发器
• 低于 5% 的干预率：第四阶段，可靠性足以与其他工作流组合

目标不是零干预。有些任务需要人类判断。目标是可预测的干预，即你知道何时以及为何需要介入。

是什么拖慢了团队的进度

最大的错误：试图跳过阶段。团队试图立即为复杂任务设置事件驱动的工作流。智能体表现不可预测，信任崩溃，他们最终放弃。

成功的路径是很枯燥的。选择一个简单的任务，在受监督的情况下运行，直到它稳定。再增加一个。建立可靠的工作流。然后再将它们连接起来。

另一个错误：不衡量干预率。没有跟踪，你就无法判断自己是否在进步。最终你会得到一些感觉上是自治、但实际需要不断照看的工作流。

从哪里开始

选择一个你每周至少做一次的手动工作流。选择具体且定义清晰的任务：

• 解决特定服务的 Sentry 错误
• 在 API 端点变更时更新文档
• 修复 PR 中的 linting 错误
• 将客户支持工单分类给正确的团队

在 TUI 模式下使用 Continue CLI 运行它。观察它的工作过程。在它卡住时进行干预。学习它成功所需的东西。

重复五次。到第五次时，你就会知道这个工作流是否可以实现自治，或者它是否需要比你预想中更多的人工判断。

如果可行，使用事件驱动触发器部署它。如果不行，选择一个更简单的工作流再试一次。

利用“持续 AI”建立竞争优势的团队并不是从复杂的系统开始的。他们从一个工作流开始，使其可靠，并在此基础上不断构建。

这就是信任建立的方式。这就是自治系统涌现的方式。