大模型和传统工程的 Trade-off

2026年5月6日

一、大模型和传统工程的关系

上一篇文章讨论了 Agent 框架的本质：上下文管理。进一步说，当我们真正把 AI 放进一个业务系统时，首先要明确一件事：大模型和传统工程并非对立关系。

一个完整功能通常会被拆成多个 Task。每个 Task 的目标、输入、输出、上下文获取方式、Tool Calling 需求都可能不同。因此，我们评价一个方案时，重点应该放在每个 Task 本身，避免笼统地讨论“这个功能要不要用大模型”。

以 Agent Browser 为例。Agent Browser 本身可以被看成一个 Skill，它包含程序、框架和一组工具。在程序层面，我们会做大量 Context Engineering：对 HTML 做剪枝，只暴露交互元素，过滤不可见节点，压缩页面结构，给元素生成稳定 ID。这些工作都属于传统工程。

但这些传统工程最终服务于 Agent 和 Tool。它们的目标是让模型在调用浏览器工具时，拿到更清晰、更短、更接近任务目标的上下文。换句话说，传统工程负责把环境整理成模型更容易使用的形态，大模型负责在语义理解、决策和工具调用中完成它擅长的部分。

所以，每增加一个 Task，我们都要重新思考它的 Context 该如何获取、如何精简、是否需要 Tool Calling、是否需要 Sub-agent，以及它在 workflow 上游或下游的依赖该如何处理。不同 Task 的处理方式可能完全不同。

这更像是在讨论一个 workflow 中的某个 Task 该如何实现。它的重点是具体实现路径，而非二选一的立场判断。Skill 本质上也是穿插了大模型能力的 workflow，并且大多数情况下会有工具参与。我们真正要讨论的是：这个工具该如何设计？这个工具是否应该是一个传统程序、一个 LLM Call，还是一个 Sub-agent？

因此，当我们真正把 AI 放进一个业务任务时，首先要回答的问题是：

这个 Task 是否真的需要 AI 来做语义理解？

很多 Task 虽然可以交给 AI，但更适合用传统工程解决。AI 的优势在于处理语义、歧义、推理、归纳和开放式生成；传统工程的优势则在于确定性、低成本、可解释和稳定。如果一个 Task 无需语义理解，并且工程实现成本较低，那么用传统程序、规则、SQL、状态机、模板、正则等方式解决，往往才是更合理的选择。

引入 AI 会带来模型调用成本、延迟、上下文管理、Prompt 维护、评估体系、异常兜底，以及后续可能出现的模型迁移成本。因此，在任务设计阶段，必须先做一次工程成本与 AI 成本之间的 trade-off。

二、任务流程图

flowchart TD
    Start([开始：定义业务问题]) --> NeedSemantic{是否需要 AI 做语义理解？}

    NeedSemantic -- 否 --> EngineeringCost{工程实现成本是否较低？}
    EngineeringCost -- 是 --> Traditional[使用传统工程方式解决]
    EngineeringCost -- 否 --> AgentEval[评估是否使用 Agent]
    AgentEval --> AgentCost{Agent 的成本、稳定性、延迟、可控性是否可接受？}
    AgentCost -- 否 --> Traditional
    AgentCost -- 是 --> NeedSemanticYes[进入 AI 任务流程]

    NeedSemantic -- 是 --> NeedSemanticYes
    NeedSemanticYes --> Goal[定义目标]
    Goal --> Tasks[拆解为具体 Task]

    Tasks --> Input[寻找所有可用输入]
    Input --> Minimal[定义 Minimal Context]
    Input --> OptionalInput[定义 Optional Input]
    Minimal --> ContextBuild["将 Optional Input 转换为 Minimal Context（filter / sub-agent / RAG / Compact）"]
    OptionalInput --> ContextBuild
    ContextBuild --> Redundancy{冗余上下文是否可接受？}
    Redundancy -- 否 --> ContextBuild
    Redundancy -- 是 --> Prompt[Prompt Engineering]

    Prompt --> Metric[定义评价指标]
    Metric --> Iterate[迭代 Prompt 与上下文结构]
    Iterate --> GoodEnough{指标是否达到合理水平？}
    GoodEnough -- 是 --> Done([完成当前 Task])
    GoodEnough -- 否 --> ModelLayer{是否需要模型层调整？}
    ModelLayer -- 否 --> Iterate
    ModelLayer -- 是 --> FineTune[Fine-tuning 或专用模型]
    FineTune --> FineTuneGood{效果是否足够？}
    FineTuneGood -- 是 --> Done
    FineTuneGood -- 否 --> Iterate

这个流程图看起来很长，但它的核心其实只有三件事：

先判断是否需要 AI。
如果需要 AI，就围绕目标定义 Minimal Context 和 Optional Input。
用 Prompt、评估和模型调整，让任务表现达到可接受水平。

只有完成这三步，一个 AI Task 才算真正闭环。

三、是否需要语义理解

判断是否需要 AI 的关键，是看任务中是否存在必须依赖语义理解的部分。

例如：

用户输入是自然语言，并且表达方式不固定；
输入中存在大量噪音、歧义、隐含条件；
任务要求模型总结、归纳、判断责任、生成方案；
任务无法用稳定的规则穷举；
输出需要根据上下文组织成文本或决策。

如果这些条件存在，那么 AI 很可能是必要的。如果不存在，就要谨慎。比如“订单超过七天不允许退款”这种逻辑，用代码判断比让模型判断更稳定；“从商品标题中提取品牌名”如果品牌库固定，也可能用词典和规则更便宜。

Agent 也是同理。AI 任务只有在需要多步探索、工具调用、动态决策、分阶段处理时，才适合引入 Agent。其他情况下，一个普通的 LLM Call 加上明确的输入输出结构，可能已经足够。

四、围绕 Minimal Context 组织输入

每个 Task 都应该沿用上一篇文章中的上下文逻辑来处理。

第一步是寻找输入。输入可能来自用户提交的内容、上一个 Agent 的输出、数据库、订单系统、外部 API、RAG 检索结果，或者某个工具调用的返回值。

第二步是定义 Minimal Context 和 Optional Input。Minimal Context 回答的是：这个 Task 要完成，模型最少需要知道什么？Optional Input 回答的是：为了得到这些 Minimal Context，我们可以使用哪些候选输入？

第三步是把 Optional Input 转换为 Minimal Context。这个过程可以由程序化 filter、sub-agent、RAG、Compact 或另一个模型调用完成。所有具体手段都服务于同一个目标：从候选输入中得到当前 Task 真正需要的上下文。

第四步是处理冗余上下文的 trade-off。模型越强，对冗余上下文的容忍度通常越高；但上下文越长，成本越高，延迟越大，注意力偏移的风险也越高。此时要在两件事之间做选择：

投入工程量，在 Optional Input 到 Minimal Context 的转换阶段压缩上下文；
接受一定冗余，把更多内容交给模型自行处理。

这是一个工程问题。高频、高成本、高风险的任务，值得投入更多工程量压缩上下文；低频、低风险、模型表现已经足够好的任务，可以容忍更多冗余。

五、Prompt Engineering 与 Evaluation

当 Context Input 确定后，才进入 Prompt Engineering 和 Evaluation。

第一步是定义指标。没有指标，就无法判断 Prompt 是否真的变好了。指标可以是人工标注的一致性、关键信息召回率、事实错误率、任务成功率、人工接管率、用户满意度，也可以是某种业务收益。

第二步是优化 Prompt。Prompt 的作用在于稳定地把输入转化成目标输出。具体方法可以参考 GPT 的 Prompt Engineering 文章，这里不再展开。

第三步是模型层调整。如果 Prompt 已经充分迭代，但效果仍然无法达到要求，就需要考虑 Fine-tuning、专用小模型，或者更复杂的算法设计。模型层调整后的结果仍然要回到指标评估里，继续判断成本、准确率和稳定性是否达到目标。

六、Examples

1. 智能客服纠纷分析

假设我们遇到一个智能客服场景：客户和商家发生纠纷，双方在聊天记录里来回扯皮，沟通记录可能有几千甚至上万楼。我们希望让 Agent 分析这些内容，判断问题关键点，并给出处理方案。

按照前面的决策流程，这个例子的路径可以简化为：

flowchart TD
    Start([智能客服纠纷分析]) --> NeedSemantic{是否需要语义理解}
    NeedSemantic -- 聊天记录包含争论和隐含事实 所以选择 --> UseAI[使用大模型做语义压缩]
    UseAI --> ContextLimit{是否直接塞全量上下文}
    ContextLimit -- 上下文过长且噪音高 所以选择 --> Define[定义 Minimal Context]
    Define --> Optional[定义 Optional Input]
    Optional -- 图片 链接 卡片 重复发言 所以选择 --> Transform[转为 Minimal Context]
    Transform -- OCR 链接解析 合并重复 时间线提取 所以选择 --> Compact[Compact]
    Compact --> Eval{压缩结果是否达标}
    Eval -- 信息遗漏或格式不稳 --> Prompt[继续调整 Prompt]
    Prompt --> Compact
    Eval -- 关键信息保留充分 --> Cost{是否高频调用或成本敏感}
    Cost -- 否 --> Done([完成 Compact Task])
    Cost -- 是 所以选择 --> Tune[评估专用 Compact 模型]
    Tune --> Done

最直接的做法是把所有聊天记录全部塞给模型。但这会遇到两个问题：

上下文可能直接爆掉。
即使上下文窗口足够长，也不符合 Minimal Context 的目标，模型可能因为噪音过多而效果变差。

当然，如果模型表现已经足够好、成本也可接受，直接全量输入也可以成立。但更稳妥的做法，是把这个任务拆成“语义化理解与有损压缩”。这个场景显然需要语义理解，因为聊天记录是大量自然语言、情绪表达、重复争论、截图、商品卡片、链接和隐含事实的混合体。

我们的目标是进行一次语义层面的有损压缩：用模型理解原始内容，去掉大量冗余信息，只保留后续责任判断与方案生成所需的事实。

这个过程本质上是从语义输入到语义输出的 Compact，因此必须由大模型或具备语义理解能力的模型完成。单纯依靠字符串截断、关键词匹配或固定规则，很难保证压缩后的内容仍然保留真正重要的信息。

确定 Minimal Context 的边界

虽然我们可以让模型直接处理所有内容，但更好的做法是先做“减枝”。

首先是合并重复项。纠纷沟通中经常出现同一句话、同一个诉求、同一张截图被反复发送。对于后续分析来说，重复本身可能有意义，但不需要原样保留几十次。更合理的方式是合并为“客户多次强调未收到退款，共出现 12 次类似表达”。

其次是转换非文本内容。双方发送的图片可以通过 OCR 或视觉模型转成语义描述；商家卡片、订单链接、商品链接也应该转成结构化或半结构化信息，例如商品名、订单号、金额、发货状态、退款状态，避免把原始链接直接塞进模型。

再者是识别任务真正需要的信息。对于“给出解决方案”这个目标，Minimal Context 可能包括：订单基本信息、双方核心诉求、关键时间线、已履行和未履行的承诺、证据材料及其来源、双方争议点、平台规则或售后政策、重复表达的次数与强度、已经尝试过的处理动作。

这些信息才是后续责任判断和方案生成真正需要的上下文。这一步也可以参考压缩算法的实现，把信息保真、冗余去除和下游可用性作为核心目标。

Context & Prompt Engineering

明确 Minimal Context 后，就可以开始 Prompt Engineering。

这里的目标需要具体定义 Compact 后必须保留哪些信息，让下一步分析效果最好。例如：

不得遗漏时间、金额、订单状态、退款状态等关键事实；
对重复表达进行合并，但要记录重复次数或情绪强度；
对图片、链接、商品卡片进行语义化转写；
区分事实、主张、推测和情绪；
保留双方各自的核心诉求；
对无法确认的内容标记为“不确定”，避免自行补全。

Prompt 可以使用 Template 固定输出结构，也可以加入 few-shot，让模型学习什么样的压缩是合格的。如果任务复杂，还可以要求模型先提取时间线、再提取争议点、最后输出 Compact 结果。

当 Prompt 初版完成后，需要构建自动化迭代脚本。脚本可以批量跑历史纠纷样本，把模型输出与人工标注或业务指标对齐，例如关键信息召回率、错误事实数量、后续责任判断准确率、人工客服接管率等。Prompt Engineering 应该通过指标不断接近目标。

评估是否需要 Fine-tuning

当 Prompt 和上下文结构已经收敛到一定水准后，再评估是否需要专门 Fine-tuning。

大多数客服场景可以先不微调。因为纠纷 Compact 的核心能力是通用语义理解、总结、归纳和信息抽取，强模型通常已经具备这些能力。

但如果这个任务触发频率足够高，或者调用成本非常敏感，或者业务追求极致效果，就可以考虑训练一个专门用于 Compact 的模型。实际上，Claude Code 就有专门用于压缩的模型 API。这类模型或 API 的成本更高，但可能换来更低的推理成本、更稳定的输出格式，以及更贴合业务规则的压缩结果。

完成这一步后，“压缩纠纷沟通记录”这个 Task 才算结束。它的输出会成为下一个 Task 的输入，例如责任判断、赔付策略选择或客服话术生成。

2. 舆情分析

假设我们需要处理海量舆情语料。每一条语料可能是帖子标题、帖子正文里的某一层楼，也可能是楼中楼回复。面对成千上万条语料，我们希望对它们进行语义化分析，最典型的任务就是情感分析：判断这条语料是正向、负向、中性，还是某种更细的情绪或意图。

按照前面的决策流程，舆情分析会走出另一条路径：

flowchart TD
    Start([舆情分析]) --> Baseline{传统 NLP 是否足够}
    Baseline -- 情绪直接且规则可覆盖 所以选择 --> NLP[传统 NLP 方案]
    Baseline -- 反讽隐喻容易误判 所以选择 --> LLM[使用大模型]
    LLM --> Context{Minimal Input 如何定义}
    Context -- 单条语料通常足够 所以选择 --> Single[一条语料一个子任务]
    Context -- 回复依赖上文 所以选择 --> Parent[补充父级评论或标题]
    Single --> Prompt[Prompt Engineering]
    Parent --> Prompt
    Prompt --> Eval{标注质量是否达标}
    Eval -- Bad Case 较多 --> Prompt
    Eval -- 质量达标 --> Throughput{并发和时效是否达标}
    Throughput -- 可接受 --> OnlineLLM[直接使用大模型]
    Throughput -- 成本高或延迟高 所以选择 --> Distill[大模型离线标注]
    Distill --> Tune[小模型 Fine-tuning]
    Tune --> Online([线上高并发推理])

这个能力的业务价值在于，它可以帮助我们产出更科学的舆情报告，并基于报告决定下一步行动。例如，是需要客服介入，是需要产品修复，是需要公关回应，还是只需要继续观察。

传统 NLP vs. 大模型

这个任务显然需要模型，因为每一条语料都要被归类和分析。但模型方案可以有多种选择。

在 NLP 领域，情感分析已经有很多成熟方案。传统分类模型、词典规则、轻量深度学习模型，都可能在某些场景下工作得很好。如果语料比较规整，情感表达比较直接，分类标准也比较简单，那么传统 NLP 方法往往成本更低、速度更快、部署更稳定。

因此，这里仍然要先做 trade-off：

如果传统 NLP 方法已经能满足需求，就没有必要引入更复杂的大模型链路；
如果传统方法无法处理复杂语义，再考虑走大模型路线。

复杂语义通常出现在一些更细微的表达里。例如中文语境中常见的阴阳怪气、反讽、隐喻、梗图式表达，传统方法很容易误判。一个用户说“这更新真是太贴心了，直接把我常用功能干没了”，字面上看有“贴心”，但真实情感显然是负向。类似场景就更适合使用具备语义理解能力的大模型。

定义输入与输出

确定使用大模型后，第一步是定义这个 Task 的输入和输出。

输入是语料本身。更具体地说，可以是一个语料列表，每条语料带有唯一 ID、来源、楼层位置、文本内容，以及必要的上下文信息。

输出可以是一个可读的标注结果。例如：语料 comment_001 被判断为负向，原因是“用户表面夸赞，实际表达对功能下线的不满”，置信度较高。

这里要注意，输出结构本身也是上下文管理的一部分。模型输出越结构化，后续统计、聚合、评估和微调就越容易。

Minimal Input：把每条语料作为子任务

舆情分析和客服纠纷分析属于两类任务。客服纠纷往往需要跨越大量上下文，先做 Compact；舆情情感分析通常可以把每一条语料作为一个相对独立的子任务。

这就是它的 Minimal Input：在多数情况下，一次只分析一条语料。

当然，部分样本仍然需要上下文。如果某条回复强依赖上一层楼，或者“他这话也太离谱了”这种表达无法独立判断，就需要补充父级评论、帖子标题或前后几条对话。但原则依然是一样的：只补充完成判断所需的最小上下文，避免把整个帖子都塞进去。

这种拆法有两个好处：

每个子任务输入很短，成本和延迟更可控；
子任务之间天然可并行，适合高吞吐处理。

Prompt Engineering：解决复杂语义

接下来是 Prompt Engineering。

这个任务的关键是让模型理解语料背后的真实含义，再判断正负面。例如它是在夸赞、抱怨、反讽、调侃，还是只是在陈述事实。

Prompt 中可以明确要求模型先判断语义，再输出分类。这里可以使用 Chain of Thought 或更轻量的理由字段，让模型解释为什么它认为这条语料是某种情感。实际落地时，最终对外输出不一定要保留完整推理过程，但在调试和评估阶段，理由字段非常有价值。

Few-shot 也很重要。我们可以收集大量具有代表性的语料，例如：

阴阳怪气但实际负向的表达；
表面吐槽但实际是玩梗的表达；
真实夸赞；
真实恶评；
中性咨询；
无意义水帖。

然后用人工标注结果与模型输出进行对比，找到 Bad Case，再反复调整 Prompt、分类标准和示例。这个过程本质上是在让模型对齐业务里的“情感判断标准”，降低对通用语义能力的单点依赖。

Evaluation 与自动化迭代

舆情分析很适合做自动化评估。

我们可以准备一批人工标注语料作为验证集，然后用脚本批量调用模型，统计模型输出与人工标注之间的一致性。评价指标可以先看整体准确率，以及各分类的 precision、recall、F1。

通过这套评估脚本，Prompt Engineering 会从主观调参变成一个可以不断迭代的工程过程。

Fine-tuning：从大模型到小模型

舆情分析通常还有一个很现实的问题：并发量和时效性。

如果每天要处理几十万甚至上百万条语料，直接用大模型在线分析，成本和延迟都可能无法接受。因此，这类任务最后往往会把大模型作为离线标注器，线上主力交给更轻量的模型。

具体路径是：

先使用大模型，通过 Prompt Engineering 获得高质量标注结果；
将这些结果与人工标注、Bad Case 修正结果合并，形成高质量训练数据；
用这些数据 Fine-tune 一个小模型；
在线上使用小模型进行高并发、低延迟推理；
持续收集低置信度样本和错误样本，再交给大模型或人工复核，进入下一轮迭代。

这就是一种典型的“大模型蒸馏”或“教师-学生模型”路径。大模型负责把复杂语义判断能力转化为高质量数据，小模型负责在线承担高频推理压力。

完成这一步后，舆情分析这个 Task 也就闭环了：我们先判断是否需要大模型，再定义 Minimal Input，通过 Prompt Engineering 建立高质量标注逻辑，最后用 Fine-tuning 将能力迁移到更便宜、更快的小模型上。

七、结语

这两个例子对应了两类典型 AI 任务。

智能客服纠纷分析的核心是长上下文 Compact：先用语义理解做有损压缩，再把压缩结果交给后续任务。舆情分析的核心则是高并发分类：先用大模型验证复杂语义判断逻辑，再通过数据和 Fine-tuning 把能力迁移到小模型。

它们看起来不同，但底层逻辑是一致的：AI 任务设计需要围绕目标不断设计上下文、压缩上下文、评估输出，并在工程成本与模型能力之间做选择。