第3A篇：LLM 闪耀的地方——以及智能体会毁掉的 90%（上）

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

上一篇：第2篇。
Read the English version.

规则搞不定的模糊判断，才是 LLM 闪耀的地方。剩下的 90% 不需要智能，而是需要精确。

上篇讲了从“直接扔给 AI”到 7400 行代码：从最朴素的方案开始，经过数月的迭代失败，一套七层分类架构浮现。即使是“AI 部分”，也是 90% 工程。分类系统只是流水线的大脑。剩下的是让它运转的躯体。

大脑聊过了。现在来看看躯体，也就是精确比智能重要得多的地方。

简而言之：一个 URL 是不是 ESG 内容，看起来只是一个是或否的问题。但放到 30 多个国家、不同语言、千奇百怪的网站架构上，它变成了充满模糊地带的语义判断。规则能搞定大部分，但总有规则覆盖不到的地方。LLM 作为最后一道兜底，把整件事补完整。

这才是真正让人兴奋的地方。

但 LLM 的角色不止于此：域名级别的判断同样需要语义理解。关键区别在于，流水线决定何时调用 LLM、给什么上下文、拿到答案后怎么办。剩下的 90% 全是编排：自适应批量采集、两级浏览器级联、预检嗅探、单页应用检测、限速。

这些都是表达为代码的已解决问题。能写 if 的地方，就别问 LLM。

规则先行，LLM 补位

上一篇讲了链接分类：判断每个 URL 是不是 ESG 内容。30 多个国家、不同语言、不同 URL 结构，规则能覆盖一部分，也确实应该优先用规则。但总有规则搞不定的情况，LLM 就是那个兜底的。

规则先行，LLM 补位。

打个比方：这就像医院的分诊台。量体温、测血压、问症状，护士用流程表就能搞定 90% 的分诊。但总有那么几个病人，症状诡异、指标矛盾、流程表上根本找不到对应选项。这时候才把主任医师请过来看一眼。

你不会让主任医师坐在分诊台前面量体温。那是浪费，况且他也不一定干得好这活。

为什么一定是规则先行？因为一开始什么都不清楚：需求模糊，目标不明，怎么做才算成功完全靠摸索。你只能一个个网站试，一次次翻车，慢慢从失败里提炼出规律。每条规则都是一次探索的结晶。

LLM 补的是规则还没覆盖到的地方：那些模式要么还没被发现，要么本身就太复杂、写不成规则。

这才是智能该待的地方。

这个逻辑也符合很多前沿自动化项目反复证明的一件事：即使是很先进的智能体方案，也得靠迭代来打磨目标和需求，不可能一步到位。AI 越来越像人了，但“像人”也意味着：人需要反复试错才能搞清楚“到底想要什么”，LLM 同样跳不过这一步。

反过来说，一旦规则、需求、目标经过反复迭代和人工判断变得足够清晰，LLM 自然也能胜任，因为答案本身已经快浮出水面了。到那一步，它甚至可以被固化成一个技能模块。

想象一个知识圈：圆心是成熟稳定的已知领域，边缘是模糊不确定的未知领域。越靠近圆心，解法越标准。做个网页、搭个 CRUD 应用，像流水线装配一样，网上有无数现成方案。AI 替代起来毫不费力。

越往外走，路越少人走过，解法越不确定：实验室里的基础研究、研发部门的前沿探索、极少数人踩过的坑。LLM 能帮忙，但一步到位替代人？很难。

ESG 采集不是火箭科学，但它处在这个光谱的偏外侧：不是没人做过，但每家公司的网站架构都是新的未知领域。这不是“能还是不能”的二元判断，而是一个确定性的光谱。越成熟的知识越容易自动化，越前沿的探索越依赖人。

有意思的是，一旦前沿解法被探索出来、公开分享，它很快就会变成标准化知识。LLM 复制起来毫无障碍。今天的前沿，就是明天的训练数据。

规则再次够不到的地方

但 LLM 的用武之地不止于链接分类。上一篇讲的是判断每个 URL 是不是 ESG，也就是那套七层分类体系。这里还有一个更上层的问题：域名级别的判断。

公司的 ESG 内容会散落在多个子域名，甚至完全不同的域名上。采集器在提取链接的过程中会不断发现新域名。有些新域名可能藏着关键的 ESG 报告，漏掉一个就可能丢失整份披露文件。

通用爬虫框架通常不会考虑这个问题。你给它一个入口 URL，它就在那个域名下面爬，不会主动去发现关键信息其实藏在另一个你事先不知道的域名上。所以每个新发现的域名都得判断：值不值得进去采集？

跟链接分类一样，这里也是规则先行。新发现的域名先过一层模式过滤：主域名匹配的直接放行，明显无关的站点直接排除。剩下拿不准的才交给 LLM。

但 LLM 判断的不是“这个域名有没有 ESG 内容”，而是这个子域名是不是公司主体业务的一部分。

shop.example.com 是网上商城，careers.example.com 是招聘站。这些子域名模式一目了然，规则直接排除。但 regional.example.com 呢？是本地化企业站，还是产品目录？insights.example.com 呢？是营销文章，还是通往可持续发展报告的内容枢纽？

模式判断不了的，LLM 看一眼页面内容就能定。

这些判断取决于页面上实际有什么。流水线抓取一个样本页面，截断到 5000 词以内，对域名级别的判断已经绰绰有余，然后连同公司名称一起发给 LLM。

指令很明确：宁可多纳入，不可漏掉。漏掉一个相关子域名会丢失披露数据，多纳入一个无关域名只是多花点采集成本。

但跟智能体方法的区别不在于谁调了 LLM，而在于谁决定问什么、问谁、拿到答案后怎么办。流水线在固定的流程节点上发现域名，准备好上下文，调用 LLM，然后根据返回结果走确定性的分支。LLM 不会自己心血来潮去探索子域名。

LLM 是你请来的高价顾问。流水线是项目经理：决定何时叫顾问进会议室、该看哪份材料、拿到建议后怎么执行。你不会让顾问自己决定几点开会、参会名单和会议室空调温度。

需要智能的地方用智能。其他所有地方用控制。

先说清楚立场

这不是 LLM 怀疑论。采集器的输出会进入一套完全独立的下游 LLM 流水线：ESG 分析、风险评估、投资组合筛选，核心判断环节都依赖 LLM。

那套系统本身也很庞大，但结论是一样的：LLM 做判断一流，管流程一塌糊涂。前者交给 LLM，后者交给代码。采集器如此，下游流水线同样如此。

具体细节以后可以另开一个系列聊。这里提一嘴只是为了说清楚：这不是反 AI，恰恰相反。我们重度依赖 AI，只不过把它放在对的位置上。

AI 帮不上忙的 90%

流水线里剩下的全是编排。编排要的是精确，不是智能。

每家公司都是不同的挑战：托管式人机验证、年龄验证、JavaScript 单页应用、区域子域名、Cookie 墙。

对每家公司，采集器会：

  1. 在打开任何浏览器之前，先发预检 HEAD 请求嗅探内容类型。
  2. 探测防御措施，测试标准无头浏览器能不能渲染这个网站。
  3. 发现入口点，跨域名和子域名。
  4. 分类数百到数千个链接。
  5. 自适应并发批量采集页面。
  6. 标准无头浏览器被拦截时，升级到完整本地浏览器。
  7. 推迟 PDF 下载，直到页面采集完成。
  8. 循环直到没有新链接。

列成清单很整齐。但这个框架不是事先设计出来的，而是花了近一年时间，一个问题一个问题撞出来的。每一条都对应一次真实失败，加进来的顺序就是翻车的顺序。

小公司产出几十个 ESG 页面，大型跨国公司产出几千个。乘以 5000 家公司，量级可想而知。

真正让人欣慰的是：经过长时间打磨，这条流水线能非常有把握地覆盖几乎所有公司的几乎所有 ESG 信息。项目早期，有位有多年计算机背景、也熟悉投资业务的同事听到自建采集器的想法时直摇头：这不就是在建一个垂直领域的迷你搜索引擎吗？

他倾向于直接买数据。但不管试了几次，外部数据从来没有达到预期。这也是为什么最终还是得自己建。

上面清单里的每一条背后都是无数次真实翻车。挑几个讲讲。

预检嗅探

预检嗅探来自反复的翻车。有个 URL 看起来像普通网页：没有 .pdf 扩展名，没有任何明显标志。结果服务器返回的是 application/pdf。

流水线开了一个完整的浏览器标签页，等着渲染，结果收到一堆二进制数据。在几百个 URL 上重复这种情况，每家公司就浪费好几分钟浏览器时间。

现在，一个轻量 HEAD 请求在毫秒内就能识别：Content-Type 说是 PDF，就直接送去下载队列，跳过浏览器。

单页应用和浏览器级联

单页应用检测也来自不断重现的问题。有些企业网站全靠 JavaScript 渲染，标准无头浏览器跑得动。有些网站则专门检测自动化痕迹。

所以流水线在首次接触每个域名时做一次测试。标准无头浏览器被拦截，完整本地浏览器就成为该域名的默认方案。结果记下来：未测试、已测试但被拦截、已测试可用。

判断只做一次，后面的 URL 照搬结论。

级联就两级：标准无头浏览器快、便宜，大多数网站检测不到；完整本地浏览器慢、贵，但更接近真实用户。批量处理仍然失败的 URL 还有最后一次机会：通过完整本地浏览器逐页重试。

测一次，记住结论，后面几千个 URL 照搬。这就是编排。

限速

然后是每域名限速：对同一个服务器每隔一小段时间才发一个请求。不限速就会半途被封。限了速，在尊重服务器的同时，跨多个域名并行仍然能维持吞吐量。

所有这些编排都是表达为代码的已解决问题：

自适应批次：
PDF 成功率 >= 阈值 -> 扩大 1.3x
否则 -> 缩小 0.7x

页面成功率 >= 阈值 -> 扩大 1.5x
否则 -> 缩小 0.6x

浏览器级联：
标准无头浏览器 -> 完整本地浏览器

浏览器生命周期：
每 20 个 URL -> 清理标签页
健康检查失败 -> 重启

限速：
每域名固定间隔
跨域名并行

能不能让智能体来“斟酌”批次大小？能。在架构师-执行者框架下，LLM 确实可以根据成功率调整并发数。

但问题是：能精确的地方，为什么要引入智能？

智能意味着不确定性。每次运行可能做出不同的决策，而你无法完美预测噪声会从哪里冒出来。代码里一个 if 语句，100 万次执行，100 万次同一个结果。LLM 做同一个判断，100 次执行，你能保证 100 次一样吗？

这就像你家电灯开关：按下去，灯亮；松开，灯灭。100 万次都一样。现在有人跟你说：“我们用 AI 来控制你的电灯，它会根据光线、心情和室温综合判断要不要开灯。”听起来很智能，但你只想上个厕所。

这不只是温度参数和采样的问题。你的请求跟海量其他请求同时打到服务器上，负载均衡、计算节点差异、请求路由都可能影响返回结果。

现在有种说法，觉得编程“就是一堆 if...else”，言下之意这很低级。但 if...else 精确、高效、零成本、零延迟、零意外。一个问题如果能用 if 解决，那 if 就是最优解。

拿 LLM 去替代 if 不是进步，是退步：用一个概率系统替换一个确定性系统，然后花更多工程量去处理它带来的不确定性。

能写 if 的地方，就别问 LLM。

这不是保守，是工程常识。

上面是流水线怎么做的。下面是智能体为什么做不到：六个看起来简单、实际上会把智能体搞垮的问题。

下一篇：第 3B 篇——LLM 闪耀的地方，以及智能体会毁掉的 90%（下）。

Originally published externally: source article.