先承认一半是营销，再看另一半为什么真实

Prompt Engineering、Context Engineering、Agentic Workflow、Eval Engineering，再加上每隔几周就冒出来的新说法。一个正常的工程师看到这些词，第一反应通常是怀疑：这是不是又一轮为了卖课、拉投资、抬薪水包装出来的话术。

这个怀疑有一半是对的。传统软件工程里，"工程"两个字意味着严谨的架构、可预测的输入输出、版本控制和测试。而很多所谓的"Prompt Engineering"，本质只是反复试错，再加几句"深呼吸，一步步来"这类近乎玄学的咒语。这是调参，不是工程。

但另一半是真实的。大语言模型是概率模型，不是确定性机器。传统代码里输入 A 必然得到 B；调用模型时，输入 A 可能得到 B、C，甚至是一本正经胡说八道的 D。为了把这种不确定性关进笼子、让它能在工业级产品里稳定运行，开发者被迫发明了一批新的系统设计模式。这些模式才是那些新词背后真正的东西。

所以问题不该停在"是不是扯淡"，而该往下问一层：每个词到底在解决哪个具体问题，它离真正的工程有多近。

把所有新词放进同一张责任地图

理清这团乱麻，最省事的办法是先建一个统一的心智模型，再把所有新词往上挂。

把一个大模型应用想象成一条流水线：用户意图从一端进来，稳定可靠的产品结果从另一端出去。中间每一层"Engineering"，都在做同一件事——把可靠性的责任往下沉一层，从模型的自由发挥，逐步交给可控的代码。从上到下大致是这样几层：

  • Prompt 层：怎么问。负责措辞、角色设定、输出格式。
  • Context 层：喂什么进上下文窗口。负责检索、记忆、压缩、裁剪。
  • Workflow 与编排层：怎么把多步任务用代码框住，决定模型在哪一步能自己做主。
  • Tool 与 Function 层：模型能动用的"手脚"，也就是它可以调用的接口。
  • Eval 层：怎么证明这次改动比上次更好。
  • Guardrails 与安全层：怎么防止它干坏事、泄露数据。

这张地图有一条暗线：越往下越像传统工程，越往上越像玄学。一个词的"工程"含金量，基本和它离确定性代码的距离成正比。Prompt 层最靠近自由发挥，所以最像许愿；Workflow 和 Eval 层最靠近代码，所以最像工程。记住这条线，后面每个概念的位置就都清楚了。

Prompt Engineering：正在沉降为基本功

Prompt Engineering 解决的是"沟通"问题：怎么跟模型说话，它才不至于胡言乱语。

它曾经被吹成一个独立岗位，现在更像一门正在贬值的手艺。原因是模型自身的推理能力越来越强，早期那些靠玄学词汇硬凑出来的提升，已经被模型内化掉了。今天还真正值钱的，主要剩三块：用 System Prompt 把模型的身份、边界和拒绝条件写成一份明确契约；用少样本示例（Few-Shot）给出可模仿的样板；以及强制结构化输出，直接要求模型按指定的 JSON 或 schema 返回，方便下游代码消费。

判断一段 prompt 工作做得好不好，标准也很朴素：它是不是把模糊的口头要求，翻译成了机器能稳定执行的明确约束。停留在"换个说法试试看"，那还是调参。

Context Engineering：现在最热，而且不等于 RAG

Context Engineering 解决的是"记忆和知识"问题：模型的上下文窗口（Context Window，也就是它一次能读进去的信息量）有限，又不掌握你的私有数据，你怎么在它回答之前，把恰好够用的信息塞进去。

这里要纠正一个很常见的过时理解：把 Context Engineering 直接等同于 RAG（检索增强生成，Retrieval-Augmented Generation）。RAG 只是其中一种信息来源。今天的上下文工程，核心是把上下文窗口当成一份稀缺预算来管理，至少包含四件事：

  • 检索：从知识库里找到相关片段，RAG 属于这一类。
  • 记忆：长期记忆、会话记忆，以及把过长历史压缩成摘要。
  • 裁剪：工具返回一大坨结果时，只保留对当前这步真正有用的部分。
  • 传递：多个 agent 协作时，子 agent 不该把自己的全部历史一股脑灌给父 agent。

关键词是"恰好够用"。塞得越多并不越好。长上下文会稀释模型的注意力、推高成本，还会引入干扰，这个现象在公开研究里被称作 context rot，是真实存在的衰减。所以这一层默认要用减法思维：每加一段上下文，都要先问这一步是不是真的需要它。

Agentic Workflow：钟摆已经从"自主"回摆到"约束"

这一层解决的是"自主性和深度思考"问题：别让模型一次把话说完，让它先思考、再查资料、再反思、再修改，形成一个闭环。ReAct（推理加行动）、反思、规划、多智能体协作这些被反复提到的模式，都属于这里。

但这一层这两年发生过一次重要的观念回摆，值得专门说。2023 到 2024 年流行的叙事是"让 agent 自己规划、自主决策一切"。大量团队按这个思路做完之后，踩的坑高度一致：纯自主的系统在演示里很惊艳，进了生产就脆弱、又贵又难测。于是现在成熟团队的共识反过来了——能用确定性代码解决的环节，就别交给模型自主决策。

落到实践，主流把这一层分成两类。一类是工作流（Workflow），执行路径由代码写死，模型只在固定节点上做有限判断，好处是可靠、可测、便宜。另一类才是真正的智能体（Agent），由模型自己决定下一步，灵活但脆弱、贵、难以测试。Anthropic 那篇 "Building Effective Agents" 把这条线讲得很清楚，它的建议也是：默认用 workflow，只在确实需要开放式决策的地方，才放真正的 agent。

Tool 设计与 Eval：一个被低估，一个是护城河

还有两层很少被单独拎出来谈，但恰恰最该重视。

Tool 与 Function 的设计，是新时代的 API 设计。一个 agent 好不好用，很大程度上取决于工具描述写得清不清楚、返回的内容是不是精简、报错信息能不能让模型自己纠正。这部分非常吃传统工程功底，却常被当成顺手就能搞定的小事，结果成了系统不稳定的隐藏来源。

Eval Engineering 解决的是"品控"问题，也是整条流水线里最像传统工程、最稀缺、也最值钱的能力。因为模型每次回答都不一样，你今天改了一句 prompt、或者换了个新模型，凭什么说它比昨天更好？答案只能是一整套自动化评估集（Eval），把"模型好不好"变成一个可以回归比较的数字。没有 Eval，所有优化都是蒙眼狂奔。能把它做扎实的团队是少数，这也是为什么我会把它排在学习和投入的第一优先级。

把这两层之外的几个常见词也顺手归位：RAG、GraphRAG、Agentic RAG 属于 Context 层；ReAct、Reflection、Planning、Multi-agent 属于 Workflow 层；MCP（Model Context Protocol，给工具和数据源做标准接口的协议）属于 Tool 层，2025 年起基本成了事实标准；LLMOps 则是把上面整条线运维化，管部署、监控、追踪和成本。

怎么指导真正的工程实践

把上面的概念翻译成可执行的原则，有六条我自己最看重的。

第一，从确定性往不确定性走，而不是反过来。动手前先问这一步能不能用普通代码做，能，就别叫模型。把大模型当成一种又贵又不稳的外部服务，不得已才调用。这一条能砍掉大半的麻烦。

第二，先建 Eval，再做优化。顺序极其重要。哪怕只是手写二三十个测试用例，每个写清输入和期望特征，也远比没有强。没有 Eval 的优化不叫工程，叫许愿。这是新旧工程师之间最大的分水岭。

第三，Context 用减法。默认怀疑"塞更多信息会更好"这个直觉。每加一段上下文，都要确认这一步真的需要它，否则就是在花预算买噪声。

第四，可观测性是第一天的基建，不是上线后的补丁。agent 是多步执行的，中间任何一步出错都会顺着链路雪崩。你必须能看到每一步的输入、输出、工具调用、token 消耗和耗时。Tracing 缺席，调试就只能靠猜。

第五，小模型加好架构，往往胜过大模型加烂架构。效果差时，很多人第一反应是换更大的模型。但更常见的真实原因，是上下文喂错了、工具设计得糟、或者缺少 workflow 约束。先修架构，再谈换模型。

第六，把成本和延迟当一等公民。传统后端不会让每个请求花掉几秒钟和几分钱，大模型会。所以缓存、模型路由（简单任务走小模型）、批处理，都要从设计阶段就考虑进去，而不是等账单来了才补救。

这六条可以落成一份推进清单：先用最笨的单次调用把主流程跑通；立刻建一个二三十条的 Eval 集；加上 tracing，去看真实的失败长什么样；针对失败优先动 Context 和 Workflow，最后才去抠 prompt 措辞；补上 guardrails 再上生产；上线后把真实日志回流，持续扩充 Eval 集。

工具与流程选型

工具生态变化很快，下面是 2026 年年中的一份快照，按层给出，并标注我的倾向。它不追求全，只挑值得优先认识的。

编排框架这一层，做严肃生产产品时 LangGraph 目前最稳，它把状态、持久化、人工介入和图结构都当成一等能力来做。数据和检索密集的应用，LlamaIndex 更顺手。不想要重框架、看重类型安全的，Pydantic AI 这一年口碑上来得很快。如果你绑定单一模型厂商，官方的 Agents SDK 现在也足够省心。但有一句要单独强调：别一上来就上重框架。很多场景几十行原生代码加一个 HTTP 客户端就够了，框架等复杂度真涨上来再引入也不迟。

Eval 是我建议最早投入的一层。Promptfoo 开源、轻量、能在本地跑、能进 CI，很对工程师胃口，适合作为起点。Braintrust 是专做评估的平台，体验成熟。如果你已经在用 LangGraph，配套的 LangSmith 把追踪和评估做在一起，衔接顺。常见模式是用 LLM-as-judge，也就是让一个模型给另一个模型的输出打分，再配上少量人工标注的黄金集，最后把这套回归跑进 CI。

下面是一份最小的 Promptfoo 配置，演示评估到底长什么样——它的核心就是把"好不好"写成可重复执行的断言。

YAML promptfoo 最小评估配置 
prompts:
  - "把下面的客服问题分类为 退款/物流/其他，只返回标签：{{question}}"
providers:
  - openai:gpt-4o-mini
tests:
  - vars:
      question: "我上周买的东西到现在还没发货"
    assert:
      - type: equals
        value: "物流"
  - vars:
      question: "这个能退吗，我不想要了"
    assert:
      - type: equals
        value: "退款"

可观测性这一层，Langfuse 开源、可自托管，社区第一梯队，可以作为默认选择。偏深度调试和 RAG 分析，Arize Phoenix 也不错。想接入快、不介意商业方案的，LangSmith 和 Helicone 都行。

Context 与检索这一层，向量库我对大多数团队的默认建议是 pgvector，也就是 Postgres 的向量插件，别为了一个向量检索就引入一套新基础设施，规模真上来了再考虑 Qdrant 或 Milvus。还有一个常被忽略的点：很多"RAG 效果差"其实是检索质量差，加一个重排序模型（reranker）往往比换大模型见效更快、更便宜。

工具接口这一层，如果你要把数据源或工具暴露给多个 agent 或客户端，直接上 MCP，它已经是事实标准，不必自己造一套接口协议。安全这一层目前没有银弹，prompt injection 还没有可靠的通用防护，核心办法仍然是最小权限：别给 agent 它根本不需要的工具和数据访问权。

收束

把三段话连起来：这些新词不是在描述四种并列的技术，而是在描述同一个动作的不同程度——把可靠性的责任，从模型手里逐层夺回到代码手里。夺得越多，越是工程；夺得越少，越是营销。

所以面对下一个冒出来的新词，不必急着焦虑，也不必急着追。先把它放回那张责任地图，看它落在哪一层、离确定性代码有多远，再决定要不要认真对待。工程实践的重心始终没变：先建 Eval、从确定性往不确定性走、Context 做减法；工具上最值得早投入的是 Eval 和 Tracing，编排框架反而可以晚一点再选。剩下的，交给真实的失败用例去告诉你下一步该改哪里。