第8A篇:委托难题——智能体为什么有时不能直接上手

系列:“我们构建了一条数万行代码的流水线。智能体为何做不到。”

上一篇:第7篇——上下文积累。

Read the English version.

问题一旦稳定、重复、边界清楚,委托当然可以成立。这样的委托应该交出去。真正容易翻车的,是把一个还在形成中的问题整包委托出去。

上篇:第7篇——上下文积累。编码能力已经解决了。工程判断没有。智能体学不会你自己都不知道自己知道的东西。自然的追问就是:那到底哪些东西可以交给它,哪些不行?

本篇的任务不是继续证明“智能体会不会写错代码”,而是开始为后半段划出第一条硬边界:哪些问题已经成熟到可以委托,哪些还没有。

到第7篇,论点其实已经来到一个自然的拐点:

如果上下文积累这么重要,那是不是只要把上下文整理好、塞进 prompt、文档、MCP 和工作流里,就可以把整件事委托给智能体?

这篇开始收束。答案也更直接:

当目标、护栏和失败条件已经足够清楚时,委托完全可以成立;真正危险的,是问题还在形成时,就把所有自主权交出去。

在智能体写一行代码之前——在它调用任何工具之前——你真正交给它的,不只是工具,也不只是上下文窗口,而是一个你自己还在形成中的问题:目标是什么,边界在哪里,什么算成功,什么算偏航,什么时候该停。而这恰恰是“全自主”承诺开始容易崩塌的地方。

你交出去的,不是任务,是一个还没成形的问题

“从企业网站采集 ESG 信息。”

这听起来像一个清楚、可执行、可委托的需求。但其实不是。至少一开始不是。

哪些 ESG 信息?从网站的哪个部分——投资者关系页面、可持续发展子站、还是区域子域名?什么叫“找到了”——发现了 URL、访问了页面、下载了 PDF,还是验证了文档确实相关?PDF 是扫描件怎么办?可持续发展报告是两年前的,算不算?一家公司有多个子公司各有独立网站怎么办?

这些问题在第一天都没有答案。答案往往出现在第九十天——因为上一个版本在某家具体公司的某个具体网站上,以某种具体方式翻了车,失败模式逼着你做出决定。

这不是规划做得差。这是模糊领域中的生产需求本来就这样运作:目标是假设,需求从与现实的碰撞中涌现。

一开始就给智能体全自主权,等于把一个假设委托出去。

它会按自己的理解执行。等你终于发现需求偏差时,它往往已经造出了一个拆起来很贵的东西。

这里其实不只是在谈“要不要委托给智能体”。同一个问题也会以另外两种更熟悉的形式出现:做一个轻量封装,把通用模型外面包一层产品壳;或者直接把问题外包给外部数据供应商、平台方案或现成服务。表面上看,这些选择彼此不同——一个是智能体,一个是包装方案,一个是现买现用。底层上,它们常常容易有相同的风险:在问题还没真正长清楚之前,就假设别人已经替你把它定义好了。如果这个假设成立,外包当然高效;如果不成立,你外包出去的就不是执行,而是对问题本身的误解。

这不是提示词多好的问题——是问题形成的问题

条件反射式的回答总是:把需求写清楚,预先定义好,再精确一点。

但精确的前提,是你知道该在哪里精确。而知道该在哪里精确,往往需要你先看到系统是怎么翻车的。

你得先看到流水线在一家区域性金融机构上栽跟头——URL 参数产生无限循环。你得先看到一家跨国公司的 JavaScript 导航,在其他网站上表现良好的解析器面前变成“隐形”。你得先看到“采集所有 ESG 文件”不小心把董事会会议纪要、监管申报和过期新闻稿都收进来——因为系统根本不知道,人类最终会认为什么才算“相关”。

需求规格有时候并不可能在系统运行之前就写完整。

这不是项目管理的失败,而是认知上的限制:你不知道需要规定什么,直到你看到哪里出了问题。

有很多名字指向这件事:有人叫它“未知的未知”,有人叫它隐性知识;在工程实践里,它常常表现为一种规格差距:你能写下来的,和你真正需要的,中间隔着一段现实打出来的距离。

对于全自主智能体来说,这个差距会变成陷阱。

它不会在“未知的未知”上大声失败。它会用看起来合理的行为把空白填上。那是你没要求过的行为。你可能要等它在 5000 家公司上复合叠加之后,才意识到那其实是错误的方向。

模糊不只是延迟——是漂移

比“智能体理解错了目标”更微妙的失败模式,是目标漂移。

所谓目标漂移,是指智能体对目标的解读,每一步局部看都说得过去,但全局上却以静默累积的方式逐渐偏离。

想象你给它的目标是:“最大化 ESG 文档覆盖率。”

这听起来很合理。于是智能体开始更激进地抓取:

  • 深入三层而不是两层;
  • 下载任何提到 ESG 关键词的 PDF;
  • 访问技术上可达但 robots.txt 标记为禁止访问的域名。

每一步单独看都“像是为了更全面”。但聚合起来,结果可能是:

  • 完整性指标反而下降;
  • 访问权限被封;
  • 成本被推高;
  • 合规预期被破坏。

这些都没写在原始目标里,因为工程师默认智能体会“知道”不该这么做。就像工程师期待的那样。

问题恰恰就在这个默认上。

流水线把这些约束显式编码了:每家公司的预算上限、robots.txt 预检、域名范围规则、PDF 评分阈值、推迟队列。每一条都不是凭空写出来的,而是前一次失败留下来的教训。

智能体如果没有这些显式边界,就只能靠自己的失败去重新发现这些教训——而它既没有一致的机构记忆,也没有天然的停手意识。

模糊目标不会产出失败的智能体。它往往产出看起来在工作的智能体——然后引入需要数月才能发现的问题。

这是更危险的失败模式。大声失败的系统可以修。在错误的事情上“成功”的系统,更难抓。

这不是抽象问题。有人用一个前沿模型查一家资产所有者的背景,它自信地回答该机构的资产由某家资产管理公司管理——对熟悉当地市场的人来说,这是常识性错误。追问之后,它才启动网页搜索自我纠正。

更荒诞的一个例子发生在写这个系列本身的过程中。协助写作的 AI 在对话中建议编辑 08a 文件,随后自己用大写“08A”去搜索——没找到,于是自信地宣布“这个文件还不存在”。文件名是它自己参与建立的命名规范。它不是搜索能力不足,而是在一个微小的大小写差异上静默失败,然后用完全自信的语气给出了错误结论。

这两个例子指向同一个结构:

模型不会在不确定的地方主动停下来问你。它会用看起来合理的输出,把空白填上。

而你需要已经知道答案,才能发现它错了。但“已经知道答案”,恰恰是你一开始想委托给它的原因并不存在的前提。

到这里,本篇真正要划的线已经出现了:问题没有形成之前,委托出去的不是任务,而是猜测。

所以下面不再继续讨论“智能体会不会写错代码”,而是把这条边界画完整:即使目标更清楚了,工具本身也会失真。

工具有了,不等于委托条件成立

智能体叙事的第二部分更微妙。也许一开始就全自主不现实——但至少目标明确之后,智能体已经有了执行所需的工具。浏览器自动化?Playwright 是 MCP 插件。PDF 解析?好几个库。网络搜索?Google、Bing、SearXNG。文件 I/O、代码执行、API 调用——都能接上。

工具箱确实存在。

但这可能还不够。

因为工具箱里的工具虽然真实,却也有真实的局限。而智能体并不会自动修工具。它默认调用工具。

PDF解析器问题

PDF 解析器有几十种:PyMuPDF、pdfplumber、pdfminer、pypdf、Adobe Extract、Tesseract(扫描件)、AWS Textract(结构化版面)。没有一个是完全对的。只有试过后才知道。

根本问题不是“缺功能”,而是 PDF 解析器要把一个为人类眼睛设计的视觉文档,转换成平坦的文本流。视觉信息在转换中活不下来:

  • 版面:双栏版面会产出交错文本。表格会变成乱序行。信息图常常被切成碎片,或者直接消失。
  • 阅读顺序:边栏里的标注框,可能在提取文本中出现在正文句子中间,打断上下文。
  • 视觉层次:靠字号和位置一眼就能看出来的标题,在纯文本里和正文没有本质区别。
  • 段落感知:人类扫一眼就知道“这是四篇论文的列表”。解析器看到的只是字符和空白。

最后一点不是假设。有人让一个前沿模型总结一份券商研究摘要 PDF 中的四篇论文。它没有正确识别第一篇——把项目符号列表之前的一个句子,错当成了第一篇论文的标题。人类打开同一份 PDF 不会犯这个错误。段落边界在视觉上是一眼就能看出来的:字号、留白、版面都在提示你。但解析后的文本里,这些信息已经丢了。

模型是聪明的,工具不是。

智能体最常见的反驳是:

“智能体会写代码,可以造一个更好的解析器。”

但问题在于,这个方向已经被试了很多年。

LLM 从 2022 年的 GPT-3.5 开始具备辅助编程能力,之后 Claude、Codex 等工具已经能生成生产性代码。研究者、工程师、AI 辅助编程工具都在投入大量精力改进 PDF 解析。

到现在,仍然没有一个通用 PDF 解析器能一致地处理信息图、多栏版面和视觉层次。不是没人试过,而是这个问题本质上就很难:它本质是处理一个可能很难穷尽的万千格式变化。

关键不是 AI 不能在边际上改善解析器——它当然可以,也已经在做。关键是:工具天花板是真实的约束。

调用现有工具的智能体,会继承这个天花板;而且调用者往往不会收到任何明确提示,告诉你这份输入已经是“有损的”。模型只会自信地把解析错误的文本当成事实继续处理。

流水线对此做了显式处理:扫描 PDF 被标记;低置信度提取被标注;某些文档类型被推迟或跳过。这些都不是自动拥有的能力——它们是看着 PDF 处理在具体文档上以具体方式失败之后,才被做进系统里的。

网络搜索问题

同样的模式,不同的领域。

网络搜索——Google、Bing、SearXNG——也是现成的工具。智能体可以调用。但搜索不是查找。搜索是人类执行的一个判断过程,把它外包给排名算法,并不能复制那种判断。

人类搜索时,往往扫一眼结果列表,一秒钟,就注意到第三条结果而不是第一条才是需要的:因为域名看着对,日期是最近的,摘要里有预期的措辞。然后立刻根据这个判断改写关键词、点击或跳过。搜索是交互式、迭代式的,依赖的是同时到达的视觉与上下文线索。

智能体拿到的是一个排名列表。它大概率会对称地处理前几条结果:每条都送给 LLM 评估相关性。这样一来,排名算法的错误和模型评估的错误就会复合叠加。

更深一层的问题是:

搜索引擎并不索引它能访问的所有内容。

它们会优先排序、缓存、遵守 robots.txt 和 noindex 标签。有些内容根本不会浮出水面——不是因为不存在,而是因为爬虫没找到;或者找到了但降了优先级;或者找到了,但索引不了(因为藏在登录墙、JavaScript 墙,或动态生成的 PDF 后面)。

验证一家公司的可持续发展报告是否真的存在于他们网站上的唯一可靠方式,是去他们网站看。不是搜索它。

而去他们的网站、导航 JavaScript 菜单、跟踪重定向、处理反爬机制、判断找到的数百个页面中哪个才是真正相关的——这才是问题本身。

智能体调用搜索 API,流水线访问网站。这两者不等价。

上下文不是越多越好——选择性遗忘

到这里,边界已经有了两条:

  1. 目标还在形成,会漂移;
  2. 工具本身会失真。

最自然的反问就是:那就把更多上下文塞给模型,不就能把这两块补上吗?

这正好接回第7篇留下来的尾巴:上下文积累不是把材料越堆越多,而是知道什么该浮现,什么该沉底。

你也许会想:上下文积累那么辛苦,但一旦积累出来了,全部塞进上下文窗口不就行了?

流水线的经验恰好相反。

随着上下文窗口增长,幻觉也在增长——模型反而更分不清哪些部分才是关键。这条流水线在实际运行中反复验证了这一点。

而人类记忆做了一件 LLM 做不到的事:选择性遗忘。

你在调用相关信息的同时,会压制不相关的部分。

而决定什么该浮现、什么该沉底的标准,恰恰来自上下文积累本身形成的判断力。

更深层的问题是:这种筛选机制很可能根本不是语言性的。它依赖的是直觉、节奏感、对当下情境的整体把握。这些东西并不天然以语言形式存在,因此也不可能被简单地从文本训练中学到。

你没办法只委托出“过滤”,而不委托出“判断”。

因为过滤本身就是判断。

所以到这里,本篇真正的结论已经够清楚了:

不能被整包委托的,不是所有问题,而是那些目标还在形成、工具仍有失真、筛选标准还没有被显式做成系统的问题。

一旦问题已经稳定、重复、边界清楚,委托当然可以成立;但在边界还没长出来之前,模型不可能替你把它长出来。

这对委托边界意味着什么

流水线使用 LLM,恰恰因为它们擅长一件很具体的事:在模糊上下文中做语义判断。

但把模型当工具用——在更大的确定性系统中调用它做一个具体、明确、可验证的判断——和把全自主权委托给一个自己规划、执行、评估、迭代的智能体,是两件不同的事。

前者,在很多成熟、重复的问题上完全可行。

后者,则要求问题本身已经被定义得足够成熟。

换句话说,本篇真正要划的不是“AI 能不能用”这条线,而是另一条更重要的线:

哪些部分已经被定义到足以委托,哪些部分还处在必须由人来形成、纠偏、叫停的阶段。

委托全自主权的最低前提条件,是三件事:

  1. 目标明确

    不只是能说出来,而是操作上精确。每个边界情况都已处理,每个范围边界都已定义。这个前提,往往只有在系统跑过足够多次、暴露过足够多边界之后才会成立。

  2. 工具可靠

    不只是“能用”,而是工具输出与真实值之间的差距已知且有限;更重要的是,系统能识别输入何时已经是有损的。

  3. 失败模式可恢复

    智能体要么大声失败,要么漂移在复合之前就能被检测,而不是静默地把偏差一路带下去。

实践中,条件 1 往往需要数月迭代;条件 2 对今天的很多工具并不成立;条件 3 需要智能体框架默认不提供的工程投入。

流水线满足这三条,不是因为它更“聪明”,而是因为它对每一条都做了显式处理。智能体框架承诺这三条,但没有一条是自动交付的。

越不理解被委托出去的系统,越难发现它何时在静默偏航。

AI 降低了学习这些东西的门槛;它没有取消理解这些东西的必要。

回应几个反驳

“会改进的,等等看。”

也许。

PDF 解析是多少年来活跃的研究领域。网络搜索改进了二十五年。两者都比以前好,两者都没有被“彻底解决”。

“会改进”不等于“已经解决”。

系统现在就得跑,用的是现在就有的工具。

“智能体能识别工具失败并求助。”

有时候可以。当失败是大声的——异常、404、超时——是的,智能体能检测并上报。

但这里讨论的恰恰是静默失败。解析错误的文本,仍然是文本。排名靠后的搜索结果,仍然是结果。智能体没有天然信号知道“这里已经有损”。

“人类也会犯错。”

当然会。

但人类的犯错方式不同。误读 PDF 的人类通常会不确定——会回看、会查别的来源、会打个标。搜索没搜对的人类,往往能感觉到“哪里不对”,于是换个关键词再搜。

人的置信度和实际确信度,至少大致校准。模型的不是。

“你可以工程化地绕过这些问题。”

可以。

用确定性代码、显式验证、硬预算上限、预检检查、域名范围规则、PDF 评分、回退策略,以及数年的迭代修复。

这些工程,正是本系列前面几篇反复描述的东西。智能体不会免费给你这些。你得自己建。而建完之后,你其实就是重新造了一条流水线。

收束:问题从不是“能不能交给AI”,而是“哪一段可以交”

如果把前面几节压缩成一句话,本篇真正想说的是:

不是 AI 不能参与,而是你不能把一个还在形成中的问题过早整包委托出去,然后期待奇迹。

智能体叙事往往隐含三个主张:

  1. 目标可以预先委托出去。

    对稳定、重复、定义明确的任务成立。对需求从迭代中涌现的模糊领域不成立。难点不在“能不能委托”,而在你是否真的已经把问题定义到了可委托的程度。

  2. 工具足够好,可以替代人类对信息的直接获取。

    对某些工具、在某些条件下部分成立。一般情况下不成立。PDF 解析器看不到版面。搜索引擎不索引一切。工具输出和人类感知之间的差距是结构性的、持久的。

  3. 只要积累了上下文,把它全部塞进上下文窗口就行。

    直觉上成立,实际上相反。上下文越多,幻觉往往越多;模型分不清哪些才是关键。人类记忆靠的是选择性遗忘,而这种筛选本身就是判断。

三个主张都不是显然错误的。在 demo 里,它们甚至都看起来像是真的。但在生产环境里、在大规模下、在时间展开之后——恰恰在最重要的时候——它们会静默地失败。

流水线有效,不是因为智能体差;而是因为流水线把那些不能被整包委托的东西,显式做成了系统:边界、检查、预算、回退、标记、停止条件。

模型被放在其中最适合它的一段,用来做语义判断;其余部分由确定性工程和人的判断兜底。

这也是后面几篇要继续收束到的核心论点:

模型不是系统。系统才是产品。

所以下一步真正的问题,不再是“要不要委托”,而是:

自主性应该放在哪里,放到什么程度,才不会越过这条边界。

下篇:第8B篇——自主性光谱

本文是系列的第8A篇。从头开始阅读。

系列目录

篇目核心观点
00 — 引言这个系列为什么存在
01 — 不可能的任务一切的起点
02 — 7400+ 行代码是怎么来的流水线是怎样滚雪球的
03A — 大脑与身体LLM = 10% 大脑,代码 = 90% 身体
03B — 六个看起来简单的问题让智能体翻车的边缘情况
04 — 诚实的对比流水线 vs 智能体,用数字说话
05A — 研究到底说了什么:数据篇METR 的可靠性断崖,Anthropic 的劳动力研究
05B — 研究到底说了什么:框架篇Karpathy、SWE-CI、长尾、汇聚
06 — 杠杆差距谁真正从 AI 中受益
07 — 上下文积累智能体难以自然拥有的东西
08A — 委托问题你在这里
08B — 自主性光谱找到合适的级别
09 — 另一个极端当怀疑变成瘫痪
10 — 两个房间Demo 狂热者 vs 领域怀疑论者
11 — 证据流水线作为证据
番外 — 反方论点AI 反驳整个系列
番外 — 站在中间地带半夜醒来的那个念头