企业官网建设流程全解析

目录

2.1 大模型在长任务中的五大核心挑战

挑战 ① 详解：上下文窗口限制

挑战 ② 详解：错误累积效应

挑战 ⑤ 详解：任务漂移

2.2 Anthropic 核心建议：能简则简

结论 1：优先尝试最简单方案

结论 2：Workflow 优先于 Agent

结论 3：复杂性只在必要时增加

结论 4：透明性优于性能

2.3 何时用 Workflow？何时用 Agent？

本章要点

理解问题比解决问题更重要——先搞清楚长任务"难在哪里"

2.1 大模型在长任务中的五大核心挑战

在上一章，你已经了解了上下文窗口和幻觉。现在我们把视角拉高，

看看长任务开发面临的五大系统性挑战：

挑战 ① 详解：上下文窗口限制

上一章已经讲过，这里用一个具体场景加深理解：

你正在让 AI 帮你重构一个 20 个文件的 Python 项目： 第 1-5 轮对话：分析项目结构 ← 上下文还能装下 第 6-15 轮对话：逐个修改文件 ← 早期对话开始被截断 第 16-30 轮对话：测试和修复 ← AI 已经"忘记"第1轮的架构决策 结果：AI 修改的代码和最初确定的架构方向矛盾 💥

挑战 ② 详解：错误累积效应

这是长任务开发中最致命的问题。

经典场景：第 1 步 AI 把数据表名写错了（user_table → user_tab），第 2 步基于错误的表名写 SQL，第 3 步基于错误的 SQL 写 ORM 模型……到最后整个模块都基于一个拼写错误构建。回溯修复的代价远大于一步一检。

核心认知：这个挑战不是"模型不够聪明"的问题，而是工程架构问题。解决思路是每步加 Gate（检查点），我们第 3 章会详细讲。

挑战 ⑤ 详解：任务漂移

任务漂移是指 LLM 在长对话中逐渐偏离原始任务目标。

用户：帮我写一个用户登录 API AI：好的，我来写登录 API...（正常） （经过 20 轮对话后） AI：让我来解释一下 OAuth 2.0 的历史背景...（漂移！） 用户：？我只需要写代码

任务漂移的根本原因是 LLM 没有"目标锚定"机制，它只是根据最近几轮的上下文预测下一个最合理的输出。

关键认知：这五大挑战不是靠"换更好的模型"就能解决的。2026 年的正确思路是——用工程手段弥补模型能力的边界。

2.2 Anthropic 核心建议：能简则简

Anthropic 在Building Effective Agents（2024 年 12 月发布，2025–2026 持续更新）中提出了一条贯穿始终的原则：

"成功的 Agent 并不是依靠复杂的框架或库，而是基于简单、可组合的模式逐步构建的。"

结论 1：优先尝试最简单方案

在引入任何 Agent 框架之前，先问自己：

单次 LLM 调用 + RAG + 少量示例，能不能解决问题？

BetterYeah 的实测数据显示：约 60% 的"长任务"实际上可以用单次调用或简单链式调用完成，不需要引入 Agent 框架。

结论 2：Workflow 优先于 Agent

Anthropic 明确区分了两个概念：

结论 3：复杂性只在必要时增加

这是 Anthropic 反复强调的"增量复杂化"原则：

第一步：单次 LLM 调用（基线） ↓ 不够好？ 第二步：加入 Few-shot 示例 + RAG ↓ 还不够好？ 第三步：引入 Prompt Chain（提示链） ↓ 还不够好？ 第四步：引入 Routing / Parallelization ↓ 还不够好？ 第五步：引入 Orchestrator-Workers

每一步都必须有量化评估证明性能明显提升，否则不增加复杂性。

结论 4：透明性优于性能

很多项目失败，不是因为模型能力不足，而是因为开发者无法理解模型的决策过程。

2026 年的最佳实践是：让每步决策可见、可记录、可回放（AgentOps 的核心思想）。

2.3 何时用 Workflow？何时用 Agent？

本章要点

长任务开发面临上下文溢出、错误累积、成本失控、黑盒决策、任务漂移五大挑战。Anthropic 的核心建议是"能简则简"——优先用最简单方案，Workflow 优先于 Agent，复杂性只在必要时增加，透明性优于性能。