AI原生架构· №11
Agent 工程范式 2026：从 Workflow 到 Context Engineering 的演进路径
从 Anthropic《Building Effective Agents》到 LangChain《Context Engineering 的崛起》，复盘 2024–2026 Agent 工程范式演进：为什么 context 才是决定 agent 表现的关键，以及开发者应当如何落地。
约 20 分钟阅读5,818 字101 次阅读博主
AI原生架构· №11
从 Anthropic《Building Effective Agents》到 LangChain《Context Engineering 的崛起》，复盘 2024–2026 Agent 工程范式演进：为什么 context 才是决定 agent 表现的关键，以及开发者应当如何落地。
2024 年底，Anthropic 发布《Building Effective Agents》系统性地区分了 "workflow" 与 "agent" 两种范式；2026 年初，LangChain 联合创始人 Harrison Chase 在博客中正式提出 "Context Engineering" 这一术语，作为对过去两年 agent 构建经验的高度概括。本文以这两份核心文档为主线，结合 12 Factor Agents、LangGraph、Claude Agent SDK 等工程实践，复盘 Agent 工程范式从 2024 到 2026 的演进，梳理为什么 "Context Engineering" 正在成为新的工程共识，以及开发者应当如何在自己的项目中落地。
在 Anthropic 的定义中，Workflow 是 LLM 与工具通过预定义代码路径编排的系统——开发者明确写出 "先调用 A，再调用 B，失败时回退到 C" 的控制流；而 Agent 是由 LLM 动态主导自身流程与工具调用的系统，模型根据当前状态决定下一步做什么。
这一区分的意义在于：很多团队把 "agent" 误等同于 "更强的智能"，于是堆砌框架、嵌套多智能体协作，复杂度指数级上升，但任务效果并没有线性提升。Anthropic 明确建议 "找到最简单的方案，只在必要时增加复杂度"——对于定义良好的任务，workflow 的可预测性和一致性反而比让模型自己决策更可靠；只有当规模上需要灵活性和模型驱动的决策时，agent 才是更优选择。
这一观点在 2025–2026 年的工程社区里被反复验证。LangChain 的工程团队在多次客户落地中发现，绝大多数生产环境里的 "agent" 实际上是 workflow + 适度 LLM 决策权 的混合体，纯粹的 end-to-end 自主 agent 仍然局限于研究演示与小范围实验。
2026 年 4 月，LangChain 发布《The rise of "context engineering"》一文，Harrison Chase 指出："agent builders 过去一两年一直在做的事情，现在终于有了一个准确的词来描述它——context engineering。" 这个词由 Dex Horthy 在 12 Factor Agents 一文中系统化提出，强调的核心观点是：
真正决定 agent 表现的不是 prompt 写得有多巧妙，而是 LLM 收到的 context 包含什么、格式如何、是否过时。
具体而言，context engineering 涵盖四类内容：
一个工程上合格的 agent 系统，必须对上述四类内容都做精细的写入、压缩、检索、过期管理——而不是把历史对话一股脑塞进上下文窗口。
随着上下文窗口扩大（Claude 系列、GPT 系列均已支持 100K+ token），一个常见误区是"既然窗口大，就什么都塞进去"。但实践经验反复证明：模型在长上下文中的检索能力会显著下降。
业内用 "Context Rot"（上下文腐烂） 来描述这一现象：在长 prompt 中，关键信息可能被淹没在无关内容中；过时的工具定义、已失效的中间结果会干扰模型判断；冗余的多轮对话历史会消耗注意力但几乎不提供新信息。
应对策略主要有三种：
Harrison Chase 在文章中直接引用了 Anthropic 的观察："context 腐烂是真实的，prompt 工程师应该用尽量简洁的 context 达成目标。"
《Building Effective Agents》总结了五种值得在生产中复用的 workflow 模式，每一种都有明确的适用场景：
把任务拆成多个固定步骤，每步的输出作为下一步的输入。典型用例是先让 LLM 生成大纲、基于大纲写正文、再做语法检查。优点是可调试——任意一步出错都能定位；缺点是步骤固定，灵活度低。
先用一个轻量级 LLM 调用判断用户请求的类型，再路由到不同的处理流程。适合客服系统——把 "投诉" 路由到人工、"查询" 路由到 RAG、"闲聊" 路由到通用对话。
把任务拆成多份并发执行，再合并结果。常见的是 Sectioning（多视角生成同一段文本再择优）和 Voting（让同一 prompt 跑 N 次做多数投票以提高准确率）。
一个 LLM 作为 orchestrator 动态拆解任务、把子任务分发给多个 worker LLM、最后汇总结果。LangGraph 的核心抽象正是这种模式。
一个 LLM 生成结果，另一个 LLM 评估并给出改进意见，形成循环。适合质量要求高、且有明确评估标准的场景，如代码生成、长文写作。
Anthropic 强调：这些模式可以组合使用，一个复杂系统往往是 prompt chain + parallel sectioning + evaluator 的嵌套结构。
把 Context Engineering 落到代码层面，有几个已经被开源社区验证有效的模式：
工具返回的原始数据往往过大、含噪声。工程上的标准做法是：调用工具后，先用一个轻量 LLM step 把结果摘要成结构化字段，再喂给主 agent。例如：调用 get_weather("北京") 返回 5KB 的 JSON，前处理后变成 {"temp": 23, "condition": "晴", "humidity": 45} 这样紧凑的字典。
LangGraph 的 Memory Store、Mem0、Letta 等开源项目提供了"长期记忆"能力。但写入时机和粒度需要工程化决策：
Harrison Chase 在 2026 年 4 月的文章 Your harness, your memory 中建议"own your memory layer"——不要把记忆管理完全交给框架，自己掌握写入和读取的逻辑。
不要在 system prompt 里堆 50 个示例，根据当前 query 动态检索最相关的 2-3 个。这就是 dynamic few-shot 或 example selector 模式。LangChain 提供了 SemanticSimilarityExampleSelector，用 embedding 检索最相近的示例。
如果看不到 context 里到底有什么，调试 agent 几乎不可能。LangSmith、LangGraph Studio、Helicone 等工具的核心价值是把每一次 LLM 调用的完整 context 可视化——开发者能逐字段看到 instructions、retrieved docs、tool results 是什么，从而判断"模型回答错误"到底是 prompt 问题、检索问题、还是工具问题。
Anthropic 的 Claude Developer Platform 也提供了类似的 Prompt Caching 与 Tracing 能力。Harrison Chase 明确说："LangSmith 在 'context engineering' 这个词出现之前就建好了所有这些能力"——可观测性是 context engineering 的前提。
基于上述分析，给出 2026 年的实操选型清单：
核心原则：能简单就别复杂。Anthropic 在原文中写道："agentic systems 经常以延迟和成本为代价换取更好的任务表现——你应该判断这种权衡是否值得。"
从 2024 年到 2026 年，社区在生产环境里沉淀下来的高频失败模式可以归纳为以下几类，每一类都对应明确的工程对策：
踩坑一：把所有 context 一次性塞给 LLM。某团队在 2025 年上半年构建一个代码 review agent，把整个仓库的 git diff、CI 日志、单元测试结果一次性塞进 200K 上下文中。结果模型在 80% 的情况下开始 "幻觉" 出不存在的函数签名——典型的 context rot。修复方案是按阶段写入：先让模型读取 diff 摘要，再按需调用工具拉取具体文件，每次只保留当前阶段需要的 5–10 个相关代码片段。
踩坑二：把记忆管理完全交给框架。Mem0、Letta 等记忆框架上手很容易，但默认实现会把所有对话都当作值得记住的事实，导致"我最近点了什么外卖"这种噪声和"用户的编程语言偏好是 Rust"这种关键事实混在一起。Harrison Chase 在《Your harness, your memory》中反复强调：memory 是产品逻辑，不是基础设施——你必须自己设计写入规则、过期策略、命名空间，否则记忆越多、agent 越笨。
踩坑三：滥用 multi-agent 协作。AutoGen、CrewAI 等框架鼓励"经理-员工"模式，让多个 LLM 互相通信完成任务。但在生产环境里，multi-agent 系统的 token 成本通常是单 agent 的 5–10 倍，延迟增加 3–5 倍，而任务质量提升往往不到 10%。Anthropic 的明确建议是：先优化单 agent + 工具调用，实在不够再考虑多 agent。
踩坑四：忽略 token 预算的可见性。很多团队上线 agent 几个月后才发现单次会话成本失控——某个用户触发了一个循环工具调用，烧了 50 美金的 token。LangSmith、Helicone、OpenLLMetry 等可观测性工具必须在 agent 上线第一天就接入，为每一次 LLM 调用设置硬性 token 上限和异常告警。
踩坑五：把 eval 留到上线后。传统软件有单元测试、集成测试，但 LLM 应用往往跳过 eval 直接上线。2026 年的工程共识是：eval 必须在第一天就写。针对意图分类、写一个 50 条样本的意图分类 eval；针对 RAG 检索，写一个 100 条样本的召回率 eval。LangSmith 提供的 pytest 风格 eval runner 可以把 eval 接入 CI，让模型升级、prompt 改动都有量化反馈。
从 2024 年底 "workflow vs agent" 的概念辨析，到 2026 年 "context engineering" 的工程命名，过去两年 Agent 工程范式的演进可以浓缩为一句话：
决定 agent 表现的，不是 prompt 写得多巧妙，而是它收到的 context 包含什么、格式如何、是否新鲜。
围绕这一核心，开发者应当建立的工程能力包括：清晰区分 workflow 与 agent 的边界、主动管理 context 的写入与压缩、构建可观测性以调试 context 实际内容、用 LangGraph、Claude Agent SDK 等成熟框架而非从零造轮子。
2026 年的 AI 应用开发，比拼的早已不是"能不能让模型跑起来"，而是"能否让模型在每一次调用时都拿到最合适的信息"。这就是 context engineering 之所以成为新一代工程共识的根本原因。
Conversation
0 条