当 AI 已经足够聪明，人类为什么还在成为瓶颈？

原创

jishuzhain
jishuzhain

OnionSec

2026年11月5日 15:06
广东

去阅读

从一本 EPUB 电子书的本地翻译实践，谈 AI Agent 的可靠性工程、Harness Engineering 与下一代生产力系统

一、一个很小的实验，却让我重新思考 AI 的工程价值

11 月 4 日晚上，我重新翻出了几份以前保存的技术资料。

其中有一本英文 EPUB 电子书。

我一直有阅读英文技术文档的习惯，但语言障碍始终存在。在线翻译服务虽然方便，却受到使用额度、服务质量和网络环境的限制。既然手里有一台可以运行本地大模型的电脑，为什么不尝试自己解决？

我的机器是 2020 年左右的配置：

•CPU：Intel Core i9-9900K

•GPU：NVIDIA RTX 2060，6GB 显存

•内存：64GB

•推理框架：Ollama

•翻译模型：腾讯 Hy-MT2-7B-GGUF，Q4\_K\_M 量化版本

通过 GPU 与 CPU 混合推理，实际翻译速度约为每秒 20 tokens。

随后，我开始尝试构建 EPUB 双语翻译工具。

有意思的是，我没有采用传统的手工编码方式，而是使用自然语言描述需求，让 AI 参与需求分析、架构设计和代码实现。

不到十分钟，就形成了一套相对完整的技术方案和工具源码，并通过了单元测试与本地测试。

随后启动整本书的翻译任务，约一个小时十分钟完成。

最终得到了一份可以阅读的双语 EPUB。

这件事本身并不复杂。

但它让我意识到一个变化：

过去，一个人的想法经常受到实现成本的约束。即使知道如何解决问题，也未必有足够的时间和精力将其实现。

现在，AI 正在显著降低从问题描述到工程原型之间的成本。

而且，这种能力并不一定需要昂贵的硬件。

一台六年前的电脑，经过模型量化、推理优化和软件工程组合，就能承担一部分以前需要依赖外部服务的工作。

这让我开始思考一个更大的问题：

当模型已经具备相当强的执行能力，为什么我们还没有看到与之匹配的生产力爆发？

我的一个判断是：模型能力已经不是唯一瓶颈，围绕模型构建的工程体系，正在成为决定实际产出的关键因素。

二、模型足够聪明，不代表系统足够可靠

首先需要区分两个概念：

Model Capability（模型能力）与 System Reliability（系统可靠性）。

模型能力描述的是模型能够完成什么任务。

系统可靠性描述的是：在真实环境中，系统能否持续、稳定、可重复地完成任务，并交付符合预期的结果。

两者不是一回事。

例如，让一个大语言模型翻译一句英文，通常很容易。

但如果要求它完成一本 EPUB 电子书的双语转换，问题就复杂得多。

EPUB 并不是一个简单的文本文件，而是一种基于 ZIP 容器的电子出版物格式，内部包含：

•OPF：出版物元数据及资源清单。

•XHTML：章节和正文内容。

•CSS：排版和样式定义。

•NCX 或 Navigation Document：目录导航。

•图片、字体及其他静态资源。

•Spine：阅读顺序与章节组织关系。

翻译正文只是其中一个环节。

真正的工程目标是：

在不破坏原始出版物结构的前提下，将目标语言内容正确插入对应章节，保留图片、目录、样式、超链接和其他资源，最终生成能够被阅读器正常解析的 EPUB 文件。

这就不再是一个单纯的翻译问题，而是一个跨越文件解析、数据处理、模型推理、结构重建和质量验证的工程问题。

假设模型翻译准确率很高，但程序错误地删除了 XHTML 标签，最终文件依然可能无法使用。

假设所有章节都成功翻译，但某个章节遗漏了最后几段，最终交付仍然是不完整的。

假设程序成功生成 EPUB 文件，但目录链接全部失效，用户依然无法获得正常的阅读体验。

这揭示了一个基本事实：

局部任务的正确，不等于整体系统的正确。

AI Agent 的工程难点恰恰在于如何处理这种系统性的不确定性。

三、为什么不能把所有事情都交给 AI？

这是构建 Agent 系统时非常重要的一条原则。

并不是所有任务都需要大模型。

对于可以通过确定性程序完成的工作，应该尽可能使用传统软件工程方法。

例如：

这里有一个非常重要的设计思想：

将确定性问题交给确定性程序，将非确定性问题交给 AI。

为什么？

因为大语言模型本质上是概率生成系统。

即使给出完全相同的输入，也可能产生不同的输出。它擅长理解自然语言、处理语义、归纳信息和生成内容，但不应该被当成一个具有严格事务保证的文件操作系统。

如果让模型自由决定 XML 标签如何修改、文件如何写入、目录如何重建，就相当于主动引入了不必要的不确定性。

正确的设计方式是：

01使用程序读取和解析原始文件。

02将需要翻译的文本提取出来。

03将文本及上下文提交给模型。

04对模型输出进行格式与内容校验。

05由确定性程序将翻译结果写回原始结构。

06执行完整性检查。

07通过后生成最终文件。

这样，模型只负责它擅长的事情。

其他工作由成熟的软件工程机制承担。

这实际上是降低系统复杂度的一种方式。

四、Harness Engineering：比模型本身更值得关注的工程方向

最近我开始关注 Harness Engineering。

Harness 可以理解为围绕模型和 Agent 构建的执行环境、工具接口、约束机制、状态管理与验证体系。

它不是简单地给模型增加一段 System Prompt。

而是试图解决一个更深层的问题：

如何让一个具有非确定性行为的智能系统，在明确的工程约束下完成复杂任务？

传统软件系统通常依靠明确的输入、逻辑和输出。

例如：

PYTHON

result = calculate(a, b)

只要程序逻辑没有变化，输入相同，通常就会得到相同结果。

但 Agent 不一样。

一个 Agent 可能需要：

•理解用户目标。

•自主拆分任务。

•选择合适的工具。

•调用外部系统。

•分析执行结果。

•判断是否需要重试。

•根据异常调整执行策略。

•决定任务是否完成。

这意味着它不仅仅是一个函数，更接近一个具有状态和控制流的执行系统。

因此，需要在模型外围构建一套可靠性保障机制。

我认为至少包括以下六个部分。

1. 任务契约（Task Contract）

不能只告诉 Agent 要完成什么，还要定义什么才算完成。

例如，EPUB 翻译任务的验收条件可以包括：

•原始章节数量不得无故减少。

•图片及静态资源必须保留。

•XHTML 文件必须能够正常解析。

•原文必须完整保留。

•每个需要翻译的文本块必须存在对应译文。

•目录导航必须有效。

•最终 EPUB 必须通过文件结构检查。

这些条件应当尽量转化为机器可以检查的约束，而不是仅仅依赖模型自我判断。

2. 工具边界（Tool Boundary）

Agent 不应该拥有不受限制的系统访问权限。

应该为它提供明确的工具接口。

例如：

TEXT

extract_chapters() translate_chunk() validate_translation() rebuild_epub() validate_epub()

每个工具都有明确的输入、输出和错误处理规则。

这样，即使模型出现错误，也可以将影响范围限制在某个工具或任务节点内。

3. 状态管理（State Management）

长任务不能只依赖模型的上下文记忆。

应该将任务状态保存在外部。

例如：

JSON

{   \"book\": \"example.epub\",   \"total_chapters\": 18,   \"completed_chapters\": 12,   \"failed_chunks\": 2,   \"status\": \"running\" }

这里仅展示一种状态记录示意。

真实系统还需要保存章节标识、文本块 ID、输入内容哈希、模型版本、翻译结果、校验状态和重试次数。

这样，程序崩溃后可以恢复任务，而不是重新翻译整本书。

4. 验证机制（Verification）

模型不能仅凭自己说任务完成，就被认定为完成。

应该通过独立验证机制检查结果。

例如：

•JSON Schema 验证。

•XML 结构验证。

•文本块数量核对。

•原文完整性检查。

•特殊字符和占位符检查。

•章节覆盖率统计。

•EPUB 阅读器兼容性测试。

5. 异常恢复（Recovery）

可靠系统必须考虑失败。

例如：

某个文本块翻译失败，不应该导致整个章节重新执行。

可以设计：

•超时重试。

•指数退避。

•失败任务隔离。

•断点续传。

•幂等写入。

•人工介入队列。

6. 可观测性（Observability）

需要知道 Agent 做过什么、为什么这样做，以及执行结果如何。

至少应该记录：

•每个任务的输入和输出。

•模型调用耗时。

•Token 消耗。

•工具调用记录。

•异常类型。

•重试次数。

•验证结果。

否则，任务失败后只能依靠猜测排查问题。

这六个部分共同构成了一个可以长期运行的 Agent 工程环境。

五、一个非常容易被忽略的问题：任务可靠性会随着步骤增加而下降

这是我认为 Agent 工程中最值得进行定量分析的地方。

假设一个任务需要连续执行 20 个步骤。

每一步独立成功的概率为 99%。

那么，在没有重试、没有恢复机制的情况下，整个流程全部成功的概率为：

Psuccess= 0.9920

Psuccess≈ 81.79%

也就是说，即使每个步骤都相当可靠，连续执行 20 个步骤，整个流程一次性成功的概率也只有约 81.8%。

如果步骤增加到 100 个：

0.99100≈ 36.60%

这就是为什么复杂 Agent 工作流不能只看单次模型调用的成功率。

需要注意，这个计算假设各步骤独立且成功率相同，现实中的失败可能存在相关性，不能直接把这个数值当作真实系统的成功率预测。

但它足以说明一个问题：

复杂任务的可靠性，不会因为模型单次表现优秀就自动得到保证。

那么应该怎么办？

引入检查点、重试和独立验证。

例如：

假设某个步骤第一次失败的概率为 1%，最多允许三次独立尝试，那么最终失败概率为：

Pfailure= 0.013

Pfailure= 0.000001

也就是百万分之一。

当然，现实中重试并不一定独立。系统性错误、错误输入、模型能力缺陷等问题，可能导致多次重试都失败。

所以真正可靠的系统还需要错误分类、输入修复和不同策略的恢复机制。

重试不是万能药。

六、从单个 Agent 到工程系统：为什么状态机可能比自由对话更重要？

很多人谈论 Agent 时，喜欢强调自主规划、多 Agent 协作和复杂推理。

但我认为，对于大量实际业务，首先应该考虑的是任务状态机。

以 EPUB 翻译为例：

TEXT

INIT   |   v PARSE   |   v EXTRACT   |   v TRANSLATE   |   v VALIDATE_TRANSLATION   |   +----失败----> RETRY   |                |   |                v   |             QUARANTINE   |   v REBUILD   |   v VALIDATE_EPUB   |   +----失败----> REPAIR   |   v COMPLETED

每个状态都有明确的进入条件、执行逻辑、退出条件和异常处理。

这种设计有几个优点：

第一，任务进度可以被准确记录。

第二，某个环节出现异常时，可以从对应节点恢复。

第三，可以对每个阶段独立测试。

第四，可以统计各环节的耗时和失败率。

第五，可以在必要时引入人工审批。

更重要的是，Agent 不必在每个环节都拥有完全自主的决策权。

例如，解析 EPUB、提取章节和重新打包都是确定性操作，不需要模型参与决策。

真正需要 Agent 判断的，是遇到异常时如何分析原因、选择修复策略，以及是否需要进一步人工介入。

这是一种混合架构：

确定性工作流负责控制，AI Agent 负责处理不确定性。

它通常比让一个 Agent 从头到尾自由操作更容易建立可靠性。

七、效率提升究竟应该如何计算？

很多 AI 产品喜欢展示 Token/s、响应速度、任务完成数量。

但这些指标不能直接代表实际生产力。

例如：

一个 Agent 每分钟完成 100 次工具调用，不代表它创造了 100 份有效成果。

一个翻译模型每秒生成 100 个 Token，也不代表翻译质量比每秒生成 20 个 Token 的模型高五倍。

真正应该关注的是有效交付成本。

可以建立一个简单的模型：

Ceffective= Ccompute+ Chuman+
Cfailure+ CmaintenanceNaccepted

其中：

•Ccompute：计算资源成本。

•Chuman：人工介入成本。

•Cfailure：失败、返工和恢复成本。

•Cmaintenance：系统维护成本。

•Naccepted：通过验收的有效成果数量。

这个模型的目的，是提醒我们不要只计算模型调用成本。

假设两个系统完成同样一本书的翻译：

A 系统耗时 60 分钟，但需要人工检查和修复 30 分钟。

B 系统耗时 80 分钟，但只需要人工检查 5 分钟。

如果只看模型运行时间，A 更快。

但如果考虑人工总投入，B 反而可能更经济。

这也是我认为 Agent 工程需要引入技术经济学思维的原因。

真正有价值的效率提升，是降低获得合格成果的总成本，而不是单纯提高执行速度。

八、人类究竟会不会成为 AI 发展的瓶颈？

回到文章开头的问题。

我认为答案是：在某些环节，人类确实正在成为 AI 能力释放的约束因素。

但这个问题需要拆开看。

第一，人类的认知带宽有限。

AI 可以在很短时间内处理大量文档、代码和数据，但人类理解、检查和决策的速度没有同步增长。

当 AI 一小时生成了大量工程成果，而人类需要一天才能完成审核，工作流就出现了新的瓶颈。

第二，人类组织的协作效率有限。

AI 可以快速设计方案，但企业的审批、预算、部门边界和历史系统可能阻止方案落地。

模型能力的提升，不会自动转化为组织生产力。

第三，人类的知识和工具使用方式存在惯性。

过去，我们习惯于先学习一项技术，再寻找适用场景。

现在，可能需要反过来：

先发现一个值得解决的问题，再让 AI 帮助我们研究所需知识、选择工具、设计方案和验证结果。

第四，AI 自身的可靠性仍然存在边界。

模型可能产生错误，工具可能调用失败，数据可能存在偏差，自动验证也可能遗漏问题。

不能因为 AI 的执行速度足够快，就取消必要的安全约束。

所以，我不认为减少人类参与就是最终目标。

更合理的方向是：

将人类从低价值、重复性的执行环节中释放出来，把人类的注意力投入到目标定义、系统设计、风险判断和结果验收。

九、真正值得探索的，是 AI 能否形成自己的工程闭环

我认为下一阶段最值得关注的方向，是 AI 从辅助执行走向受控的自主工程。

一个成熟的系统可能具备这样的工作能力：

01接收自然语言描述的目标。

02分析目标并形成可执行计划。

03识别任务所需的知识、工具和资源。

04自动调用工具执行任务。

05通过独立机制验证结果。

06发现异常并分析原因。

07尝试修复并重新验证。

08记录全过程，形成可追溯的交付物。

这已经不只是聊天机器人。

它更像一个由模型、工具、工作流、状态管理、测试框架和权限控制共同组成的智能生产系统。

而且，这种系统不应该只局限于软件开发。

它可以应用于科研、财务分析、工业设计、企业运营、数据治理和安全运营。

例如，企业财务分析 Agent 不应该只是把财报总结成一篇文章。

它应该能够：

•读取财务报表。

•统一数据口径。

•核对历史数据。

•计算财务指标。

•发现异常变化。

•追溯异常对应的原始数据。

•形成待验证的假设。

•给出可复核的分析报告。

如果它发现某项费用异常增长，却无法指出具体数据来源，那么它的结论就不应该被直接采纳。

这就是可靠性工程的意义。

智能不仅要能够提出答案，还应该能够提供证据、接受检查，并在错误发生时恢复。

十、结语：智能不再稀缺之后，工程能力的定义也会改变

昨晚，我只是想翻译一本书。

但这件小事让我重新认识了自己手里的计算资源，也让我意识到 AI 正在改变工程活动的成本结构。

一台 2020 年的电脑，没有更换显卡，没有增加内存，却因为模型量化、推理优化和新的软件工具链，获得了过去不具备的应用能力。

这让我想起一个很有意思的现象：

创新不一定来自增加资源。

有时，仅仅改变数据的组织方式、计算方法和工具之间的组合关系，就能释放出过去没有被利用的能力。

而现在，AI 又进一步降低了这些组合关系的实现成本。

过去，一个人可能需要先掌握大量技术细节，才有能力把一个想法变成工程成果。

现在，一个人可以让 AI 协助完成大量具体实现工作，将更多精力放在问题本身。

当然，这不意味着专业知识已经失去价值。

恰恰相反，随着 AI 能够生成越来越多的方案，识别错误、定义约束、设计验证机制和判断真实价值，可能变得更加重要。

我认为，未来真正有竞争力的人，不一定是亲自完成最多工作的人。

而是能够利用有限资源，设计出可靠的智能系统，让系统持续解决真实问题的人。

当智能逐渐成为可以调用的资源，可靠性、验证能力、工程组织能力和真实问题的发现能力，可能才是下一阶段真正稀缺的生产力。

从这个意义上说，AI Agent 最值得研究的，不是它能够替人完成多少工作。

而是我们能否围绕它建立一套可靠的生产体系，让过去因为成本太高、能力不足而无法实现的事情，真正变得可行。

这或许才是 AI 从技术能力走向生产力的关键一步。