维克多·科英布拉因在人工智能创新领域做出的杰出贡献，入选了《福布斯》巴西“30岁以下精英榜”。他共同Artefact拉丁美洲Artefact业务，该业务现已发展成为拥有200名员工的全球技术中心。他在扩展人工智能解决方案以及在国际市场上组建高绩效技术团队方面拥有深厚的专业知识。

我们已经探讨了这个问题（第1部分）和相关方法（第2部分）。现在来谈谈一个更棘手的问题：这一切对组织的实际运作意味着什么？

以下是我的真实看法。这项技术确实存在，但尚不成熟。发展方向虽清晰，但时间表尚不明确。2026年部署长期运行的人工智能的大多数组织都将付出高昂的代价。只有少数组织能从中获得真正的优势。

区别主要体现在三个方面：部署地点、管理方式，以及他们是否真正理解“自主”在实践中究竟意味着什么。

从助理到员工的转变

这是一场根本性的变革。多年来，我们一直拥有人工智能助手——这些系统能帮助人类更快地完成工作。而长期运行的人工智能则代表着一种全新的概念：能够独立完成工作的系统。

这一区别对组织设计至关重要。

十五分钟以内的任务已是驾轻就熟的领域。草稿、建议、快速查询——这些正是人工智能助手自2023年以来一直表现优异的领域。由于人类始终在场，因此人类的监督是隐含的。

“有趣区间”是指1到8小时。完成交付成果。全面实施。这些工作过去通常需要一个人花上半天或一整天来完成。目前的估计显示，该区间的可靠性在50%到70%之间。虽然足够实用，但还不足以让人盲目信赖。

超过24小时，我们就进入了实验领域。项目级别的自主性。持续的研究。跨越数天的工作。那片疆域或许正在到来，但尚未抵达。任何声称已然实现的人，不过是在推销某种东西罢了。

目前，57%的受访企业已将人工智能投入生产环境。这个数字听起来很惊人，但一旦仔细看看它们实际在做什么，就会发现：68%的系统在十步之内就需要人工干预。大多数所谓的“生产级人工智能”不过是被美化了的辅助工具，只不过被赋予了稍长的“自由度”罢了。

您的接口变成了委托接口

如果长期运行的AI能够成功，人们与它的互动方式将发生根本性的改变。

辅助界面以实时协作为基础。你提出请求，它作出响应；你进行调整，它随之迭代。整个过程中始终有人参与。对于短时任务，这种方式效果良好。

委托接口基于异步交接。您只需设定目标，定期查看进度，并接收交付成果。执行过程中无需人工干预。

试想一下，这对工作管理方式意味着什么：

  • 进度追踪取代了对话。用户需要仪表盘来展示AI已经做了什么、正在做什么以及接下来计划做什么。输出结果不是聊天内容——而是一份状态报告。
  • 检查点取代了反复往返。用户不再通过迭代方式进行优化，而是在预设的节点上进行批准或否决。“开始工作前请审核计划。”“执行前请确认方案。”
  • 审计日志已成为强制要求。当自动驾驶运行六小时后出现故障时，您需要还原事件经过。记录一切并非多疑——而是运营必需。
  • 故障恢复已成为一项功能。人工智能难免会出错。关键在于它能否优雅地处理故障，记录问题原因，并让人类能够从一个合理的状态恢复系统。

目前大多数人工智能产品并非为此而设计。它们默认有人在监视。而长期运行的人工智能则需要那些默认无人监视的产品。

治理绝非可有可无

能够连续运行数小时的人工智能，也可能连续数小时犯错。在人工审核发现之前，错误会不断累积。某家金融服务公司因人工智能部署中的状态管理不善，导致重复处理造成200万美元的损失。这并非假设——此事发生于2025年。

正在形成的框架是“有限自主”：明确的操作边界、审计追踪记录，以及触发人工干预的决策点。

实践要素

权限范围。AI 不应获得超出任务所需的访问权限。负责研究竞争对手的 AI 不应拥有修改客户记录的权限。这听起来似乎显而易见。但在实际操作中，组织往往会过度授予访问权限，因为这比确定必要的最小权限范围要简单得多。

决策日志记录。不仅记录结果，更要记录推理路径。当人工智能做出错误决策时，你需要了解原因。“它犯了错误”并非根本原因分析。

升级触发条件。应预先明确哪些情况需要人工审批。例如：支出超过阈值、修改客户数据、对外沟通等。这些触发条件必须明确规定，不能交由人工智能自行判断。

变更追踪。每次修改都可追溯且可撤销。对于会引发变更的人工智能而言，版本控制绝非可有可无。必须能够撤销出错的操作。

数据质量的重要性超乎你的想象

人工智能需要清晰的输入才能产生清晰的输出。缺乏高质量、结构化信息的组织很难从自主系统中获取价值。

这是比较枯燥的部分。在部署长期运行的 AI 系统之前，您需要：规范且一致的数据格式；系统间有详细文档记录的连接；明确的数据质量责任归属；以及完善的错误处理流程。

垃圾进，垃圾出——但在大规模、长时间运行且错误不断累积的情况下，情况就大不相同了。那些在仪表盘上仅是令人烦恼的数据质量问题，到了自主AI系统中便会演变成灾难性的后果。

您可能会遇到的故障模式

一份2025年的行业分析报告指出了人工智能系统中存在的14种独特故障模式。以下是那些让组织猝不及防的故障模式：

连锁错误。人工智能做出了错误的假设，并据此采取行动。下一步操作基于这一有缺陷的假设，再下一步则使错误进一步加剧。等到人类察觉时，整个工作流程早已建立在错误的前提之上。这并非假设，而是司空见惯的现象。

交接设计不佳。AI系统之间，或是AI与人类之间的过渡环节，往往是问题频发的症结所在。某电商公司曾因用户在交互过程中遭遇AI系统交接而感到困惑，导致40%的客户流失。虽然交接本身是成功的，但用户体验却令人失望。

体制腐败。长期运行的系统积弊深重。本应废止的旧决策却依然存在。并行操作引发冲突。人工智能已然迷失了最初的目标。

共同的脆弱性。如果所有人工智能都依赖相同的底层能力，它们就会存在共同的弱点。它们会在相同的边界案例中失效，也会面临相同的盲点。实现多样化不仅仅关乎能力——更关乎韧性。

其中的共同点在于：这些并非个别组件的故障，而是系统层面的故障。仅靠孤立测试单个组件是无法发现这些问题的。你需要在真实的环境下，按照实际的时间周期，对整个工作流进行测试。

真正的机遇在哪里

考虑到所有这些限制因素，2026年企业究竟应该在哪些领域部署长期运行的AI？

先从“1至8小时”的任务区间入手。这类任务耗时足够长，能让自主工作发挥作用；又足够短，能将潜在风险控制在可接受范围内。具体包括：具有明确规格要求的实施项目；基于明确来源的研究综述；基于现有材料的流程文档编制；以及基于结构化输入的报告生成。

寻找具有可量化完成标准的任务。如果无法明确界定成功标准，人工智能就无法可靠地实现它。那些需要依靠人类判断来评估的任务，并不适合交由自动化系统处理。

着重处理那些因需要持续专注而被回避的工作。这些才是真正的机遇。人们往往因为需要连续四小时不受打扰的时间而推迟处理的任务。那些始终未能落实的流程改进。文档总是过时。分析总是不够全面。

应在适当间隔设置检查点。四小时的自主工作不应意味着四小时无人监管。应设置审查节点。这并非因为不信任人工智能——而是因为错误会不断累积，而早期发现能将损失降至最低。

要衡量实际成功率，而非演示表现。这一点至关重要。基准测试结果无法预测实际应用中的表现。METR的研究发现，即使通过了自动化检测，AI生成的内容中也无一例外都需要经过清理才能使用。贵公司的内部评估标准必须反映真实的质量标准，而非理想化的条件。

历史类比，再探

蒸汽机发明数十年后，工厂才开始围绕它进行重新设计。工厂主们深谙如何运营水力驱动的工厂。他们已建立起基于旧有模式的工作流程、专业技能和完整的商业模式。新技术需要新的组织架构、新的工作流程，以及对工作地点和流程的新思维方式。

我在本文的初稿中曾用过这个比喻，但需要补充一点：蒸汽机运行可靠。而目前运行时间较长的AI却并非如此——至少目前还不行，也无法始终如一地做到。

这一保留意见依然适用。但投资方向已不言而喻。每一家主要的人工智能公司都在优化系统以实现持续运行。每一位认真的采用者都在针对当前的局限性构建变通方案。每一个企业级平台都在为运行时间更长的人工智能任务增添基础设施。

对于组织而言，问题不在于是否要顺应这一变革，而在于如何负责任地应对：先建立治理机制，再提升能力；着眼于实际成效，而非演示效果；从小处着手，再逐步扩大规模。

那些等待技术成熟再行动的企业，等到技术真正成熟时，可能会发现自己已经落后了。而那些过早部署的企业，则会付出高昂的代价。正确的做法是在适当的防护措施下，有针对性地进行实验。

给贵组织的三个问题

在您的领域中，有哪些需要持续专注的任务？请寻找那些需要数小时而非数分钟持续专注的工作。人们往往因为这些任务需要持续集中注意力而拖延——这些正是试点项目的理想候选对象。

能否可靠地衡量自主工作的成功与否？这里指的不是“是否产生了产出”，而是“产生的产出是否符合你的实际标准”。如果无法定义和衡量成功，就无法评估人工智能是否有效。

您的治理基础设施是否已做好准备，应对那些无人监督时发生的工作？日志记录。权限控制。升级触发机制。恢复机制。审计追踪。只有当授权的基础设施就位，授权才有意义。
2026年可能还不是人工智能在长期运行任务中变得可靠的一年。在两小时的任务中成功率达到50%，仍意味着有一半时间会失败。

但或许，这一年运行的AI将针对特定应用场景具备实际应用价值——在适当的监督和容错机制下，其性能已足以支持生产环境部署。

老实说：没人知道这些系统究竟何时会成熟。种种迹象表明，这值得我们去探究。

 

参考文献

研究论文

行业报告与白皮书

  • AI 系统的故障模式 — 微软
  • 2025年关于人工智能与信任的启示 — GoogleCloud
  • 人工智能工程现状 — LangChain
  • 基准测试与实际应用评估 — METR

技术文档

  • 我们如何构建多智能体研究系统 — Anthropic
  • 模型上下文协议规范 — modelcontextprotocol.io
  • 《Fresh-Start Cycling》文档（“Ralph Wiggum”）——Geoffrey Huntley (ghuntley.com/ralph/)